Pengertian software

1
Materi Kuliah SE 2

• Pengertian software
• Kriteria software
• Aktivitas proses software
• SDLC standard
• Waterfall
• Iterative
• Component based
• RUP
• RAD
• Tugas mandiri

2
Definisi SE

• Disiplin ilmu yang membahas secara detail
  bagaimana cara pembuatan suatu software dilihat
  dari berbagai aspek
• Spesifikasi ? Pemeliharaan
• Cakupan SE
• Proses teknis pengembangan software
• Manajemen proyek software
• Penggunaan alat bantu
• Metode dan teori yg mendukung produksi software

3
Pengertian Software

• Software ? Program komputer
• Software tidak hanya sekedar program, tetapi
  harus mencakup juga
• File-file konfigurasi data terkait supaya program
  bisa berjalan sebagai sebuah aplikasi
  sebagaimana yang diharapkan
• Dokumentasi yang menjelaskan cara penggunaan
  sistem
• Situs web sebagai sumber informasi tentang produk
  software terbaru

4
Kriteria software yang baik

• Maintainability (dapat dipelihara)
• Software bisa menangani perubahan spek kebutuhan
• Dependability (dapat diandalkan)
• Aman, selamat, tidak menyebabkan keruksakan fisik
• Efficiency (Efisien)
• Software mampu mengoptimalkan resource
• Acceptability (Kemampupakaian)
• Software bisa diterima user sebagaimana
  rancangan. Mudah dimengerti, digunakan and
  compatible dengan sistem yang lain

5
Produk Software

• Generik (terbuka utk siapapun) DBMS, Word
  Processor, Sistem Operasi, Adobe Photoshop,
  CorelDraw, MsProject, dll
• Spek hanya dikontrol oleh sendiri oleh Vendor
  Software
• Pesanan (disesuaikan dgn kebutuhan pelanggan
  tertentu saja)
• Berdasarkan kontrak kerja, tender, dll
• Spek dikontrol oleh pelanggan tertentu

6
Software Process

• Serangkaian kegiatan dan hasil-hasilnya yang
  diperlukan untuk menghasilkan aplikasi tertentu.

7
Spesifikasi

• Untuk menetapkan layanan/fungsi apa yang dituntut
  dari sistem, dan mendefinisikan batasan
  operasinya.
• Istilah lainnya Rekayasa Persyaratan
• Tahapan Rekayasa Persyaratan
• Studi kelayakan
• Elisitasi dan analisis persyaratan
• Spesifikasi persyaratan
• Validasi persyaratan

8
Spesifikasi Software

• Studi kelayakan
• Memperkirakan apakah user yang diidentifikasi
  puas menggunakan software dan teknologi hardware
  saat ini
• Memutuskan apakah sistem yang diusulkan efektif
  dalam hal biaya dari sudut pandang bisnis
• Memutuskan apakah sistem dapat dikembangkan
  dengan anggaran yang tersedia
• Studi ini harus bersifat murah dan cepat

9
Spesifikasi Software

• Elisitasi dan analisis persyaratan
• Penurunan persyaratan sistem melalui observasi
  sistem yang ada, diskusi dengan user yang akan
  memakai dan yang mengadakan, analisis pekerjaan,.
• Melibatkan pengembangan satu atau lebih model dan
  prototipe sistem.
• Hasil fase ini akan membantu analis memahami
  sistem yang akan dispesifikasi.

10
Spesifikasi Software

• Spesifikasi persyaratan
• Menerjemahkan informasi hasil kegiatan analisis
  menjadi dokumen yang mendefinisikan serangkaian
  persyaratan
• Persyaratan user merupakan abstraksi dari
  persyaratan sistem untuk pelanggan dan end user
  sistem
• Deskripsi rinci tentang fungsionalitas yang akan
  diberikan

11
Spesifikasi Software

• Validasi persyaratan
• Memeriksa apakah persyaratan dapat
  direalisasiskan, konsisten, dan lengkap.
• Pada proses ini, kesalahan pada dokumen
  persyaratan pada akhirnya dapat ditemukan.
• Kesalahan ini akan dimodifikasi untuk
  menyelesaikan masalah.

12
Proses Rekayasa Persyaratan
13
Perancangan Implementasi

• Proses pengubahan spesifikasi sistem menjadi
  sistem aplikasi yang bisa dijalankan.
• Mencakup
• Perancangan
• Design a software structure that realises the
  specification
• Pemrograman/coding
• Translate this structure into an executable
  program
• The activities of design and implementation are
  closely related and may be inter-leaved.

14
Kegiatan Proses Perancangan

• Perancangan arsitektural
• Spesifikasi abstrak
• Perancangan interface
• Perancangan komponen
• Perancangan struktur data
• Perancangan algoritma

15
Proses Perancangan Software
16
Metode Perancangan

• Systematic approaches to developing a software
  design.
• The design is usually documented as a set of
  graphical models.
• Possible models
• Object model
• Sequence model
• State transition model
• Structural model
• Data-flow model.

17
Implementasi Pemrograman

• Mengubah hasil perancangan menjadi program
  komputer yang bisa dijalankan.
• Programming is a personal activity - there is no
  generic programming process.
• Programmer melakukan pengujian terhadap
  programnya masing-masing, dan melakukan debug
  yaitu proses mencari lokasi error program dan
  menghilangkannya.

18
Proses Debug
19
Validasi

• Istilah lain Verification validation (V V)
• Menunjukkan bahwa sistem telah sesuai dengan
  spesifikasinya, dan memenuhi harapa pelanggannya.
• Involves checking and review processes and system
  testing.
• System testing involves executing the system with
  test cases that are derived from the
  specification of the real data to be processed by
  the system.

20
Proses Ujicoba

• Component or unit testing
• Individual components are tested independently
• Components may be functions or objects or
  coherent groupings of these entities.
• System testing
• Testing of the system as a whole. Testing of
  emergent properties is particularly important.
• Acceptance testing
• Testing with customer data to check that the
  system meets the customers needs.

21
Proses Ujicoba
Penerimaan
Unit
Sistem
22
Fase Ujicoba
23
Evolusi

• Software is inherently flexible and can change.
• As requirements change through changing business
  circumstances, the software that supports the
  business must also evolve and change.
• Although there has been a demarcation between
  development and evolution (maintenance) this is
  increasingly irrelevant as fewer and fewer
  systems are completely new.

24
System evolution
25
Pendukung Proses Software

• Computer-Aided Software Engineering (CASE) tool
• Pendukung kegiatan otomatisasi proses software
  dari mulai spesifikasi s/d pengujian, evolusi
  software.
• Otomatisasi kegiatan
• Graphical editors for system model development
• Data dictionary to manage design entities
• Graphical UI builder for user interface
  construction
• Debuggers to support program fault finding
• Automated translators to generate new versions of
  a program.

26
CASE technology

• Case technology has led to significant
  improvements in the software process.
• However, these are not the order of magnitude
  improvements that were once predicted
• Software engineering requires creative thought -
  this is not readily automated
• Software engineering is a team activity and, for
  large projects, much time is spent in team
  interactions. CASE technology does not really
  support these.

27
Model Proses Software
28
Model Proses Software

• Sequence Linear pengembangan yang bersifat
  linear dari mulai spesifikasi s/d pemeliharaan.
• Evolutionere/Iterative pendekatan pengulangan
  kegiatan spesifikasi, pengembangan, dan validasi.
  
• Sistem sejak awal dikembangkan dengan cepat
  berdasarkan spesifikasi abstrak,
• lalu disempurnakan secara bertahap berdasarkan
  masukan dari pelanggan/pengguna sampai sistem
  dapat memenuhi kebutuhan pelanggan/pengguna.
• Component-based pengembangan dengan cara
  menggunakan komponen yang dapat dipakai ulang.

29
Model Waterfall
30
Analisis Waterfall

• Kelebihan
• Sudah terbukti handal dan paling lama digunakan
• Digunakan untuk rekayasa sistem software
  berukuran besar (TRON)
• dimana proyek dikerjakan di beberapa tempat
  berlainan, dan terbagi menjadi beberapa bagian
  sub-proyek.
• Cocok untuk pengembangan software yang bersifat
  generik
• Prosesnya sudah benar-benar jelas dan tidak
  berubah-ubah

31
Analisis Waterfall

• Sistematis,
• Titik transisi yang jelas pada setiap
  tahapan/proses
• akan memudahkan tim pengembang software dalam
• memonitor penjadwalan proyek,
• menetapkan tanggung jawab,
• dan akuntabilitas peran personal dalam proyek
  perangkat lunak.

32
Analisis Waterfallub

• The main drawback !!!
• Sulit/adanya kendala dalam mengakomodasi
  perubahan speksifikasi ketika proses sedang
  berlangsung
• Fase sebelumnya harus lengkap dan selesai sebelum
  memasuki tahap berikutnya.

33
Analisis Waterfall

• Inflexible partitioning of the project into
  distinct stages makes it difficult to respond to
  changing customer requirements.
• Therefore,
• this model is only appropriate when the
  requirements are well-understood,
• and changes will be fairly limited during the
  design process.
• Few business systems have stable requirements.

34
Model I Alternative Waterfall
35
Evolutionary Development

• Exploratory development
• Objective is to work with customers and to evolve
  a final system from an initial outline
  specification. Should start with well-understood
  requirements and add new features as proposed by
  the customer.
• Throw-away prototyping
• Objective is to understand the system
  requirements. Should start with poorly understood
  requirements to clarify what is really needed.

36
Model II Evolutionary/Iterative
37
Analisis Model Evolutionary

• Keuntungan
• Spesifikasi dapat dikembangkan secara inkremental
• Sementara pengguna mendapat pemahaman yang lebih
  baik dari masalah mereka
• Sistem software dapat merefleksikannya
• Penerapan
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user
  interface)
• For short-lifetime systems.

38
Analisis Model Evolutionary

• Kelemahan
• Lack of process visibility
• Proses tidak terlihat, memerlukan alat ukur
  kemajuan secara reguler
• Systems are often poorly structured
• Perubahan yang sering meruksak struktur software,
  penyesuaian perubahan semakin sulit dan mahal
• Special skills (e.g. in languages for rapid
  prototyping) may be required.
• Memerlukan keahlian yang lebih mapan

39
Spiral Development

• Tidak merepresentasikan rangkaian kegiatan dengan
  penelusuran balik (backtracking).
• Berbentuk spiral, dimana software dikembangkan
  dengan prinsip incremental versions
• Setiap untai pada spiral menunjukkan fase proses
  perangkat lunak
• Tidak ada fase-fase yang tetap seperti
  spesifikasi atau perancangan.
• Mencakup model yang lain (prototipe, waterfall)
• Perbedaannya dengan model lainnya, model spiral
  mempertimbangkan resiko secara eksplisit

40
Spiral model of the software process
41
Model Evolutinary (Spiral)
42
Empat Sektor Pada Model Spiral

• Objective setting/Penentuan tujuan
• Mendefinisikan tujuan spesifik untuk setiap fase
  proyek
• Risk assessment reduction/Penilaian
  Pengurangan Resiko
• Identifikasi resiko proyek dan meminimalisir
  resiko. Example jika ada resiko persyaratan yang
  tidak sesuai diperlukan prototipe
• Development validation/Pengembangan validasi
• Memilih model pengembangan yang cocok. Jika
  resiko interface dipilih model prototipe
  evolusioner. Jika resiko integrasi subsistem
  dipilih model waterfall
• Planning/Perencanaan
• The project is reviewed and the next phase of the
  spiral is planned.

43
Model Spiral
44
Makna Setiap Untaian Spiral
45
Model Incremental
46
Model III Component-based

• Based on systematic reuse where systems are
  integrated from existing components or COTS
  (Commercial-off-the-shelf) systems.
• This approach is becoming increasingly used as
  component standards have emerged.
• Process stages
• Component analysis
• Requirements modification
• System design with reuse
• Development and integration.

47
Model Component-based
48
Model Component-based
49
Teknologi Penunjang Component-based
50
Model Rational Unified Process

• A modern process model derived from the work on
  the UML and associated process.

51
RUP phases

• Inception
• Establish the business case for the system.
• Elaboration
• Develop an understanding of the problem domain
  and the system architecture.
• Construction
• System design, programming and testing.
• Transition
• Deploy the system in its operating environment.

52
RUP good practice

• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Verify software quality
• Control changes to software

53
Rapid Application Development/RAD

• Metodologi ini melakukan beberapa penyesuaian
  terhadap SDLC pada beberapa bagian sehingga lebih
  cepat untuk sampai ke tangan pengguna. metodologi
  ini biasanya mensyaratkan beberapa teknik dan
  alat2 khusus agar proses bisa cepat, misalnya
  melakukan sesi joint application development
  (JAD), penggunaan alat-alat computer aided
  software engineering (CASE Tools), kode generator
  dan lain-lain.

54
Model RAD
55
Model RAD

• Requires sufficient human resources to create the
  right number of RAD teams.
• Tidak semua tipe aplikasi bisa, harus yang
  tingkat modularisasinya tinggi
• Tidak cocok jika tingkat resiko teknisnya tinggi,
  terutama jika banyak menggunakan teknologi
  terbaru yang mungkin tidak cocok dengan program
  yang ada

56
Model Prototype
Melakukan analisis, desain dan implementasi
secara bersamaan, kemudian dilakukan secara
berulang-ulang untuk mendapatkan review dari
pengguna sampai semua kebutuhan tercapai.
57
Model Prototype
58
Problematika Prototype

• Developer sering melakukan kompromi agar
  prototype bisa cepat selesai.
• Bisa saja menggunakan algoritma yang kurang/tidak
  efisien, karena dikejar waktu harus cepat jadi.
• Menggunakan sistem operasi atau bahasa
  pemrograman yang kurang tepat

59
Throw-away Prototype
Hampir sama dengan metodologi Prototyping, tetapi
analisis dilakukan lebih mendalam lagi.
60
Komparasi Metodologi
61
Bagaimana Memilih Metodologi

• Kejelasan kebutuhan pengguna
• Jika pada suatu saat kita dihadapkan pada kondisi
  ketidakjelasan kebutuhan pengguna, maka
  metodologi RAD berbasis prototipe dan prototipe
  sekali pakai (throwaway prototyping) merupakan
  salah satu metodologi yang tepat untuk digunakan.
• Penguasaan teknologi
• Penguasaan teknologi merupakan satu bagian yang
  vital untuk dipertimbangkan dalam menentukan
  sebuah metodologi. Familiaritas terhadap
  teknologi dasar yang tidak memadai akan
  menimbulkan pembengkakan waktu dan biaya.

62
Bagaimana Memilih Metodologi

•   Tingkat kerumitan sistem yang akan dibangun
• Sistem yang kompleks membutuhkan analisis dan
  desain yang sangat hati-hati. Oleh karena itu
  methodologi agile dan prototyping dipandang
  kurang begitu baik diterapkan jika tingkat
  kerumitan sistem sangat tinggi.

63
Bagaimana Memilih Metodologi

• Tingkat kehandalan sistem
• Kehandalan sistem biasanya merupakan faktor
  penting dalam pengembangan sistem. Metodologi
  berbasis prototipe umumnya bukan pilihan yang
  baik karena mereka kurang berhati-hati tahap
  analisis dan desain.
• Waktu pelaksanaan pengembangan
• Metodologi berbasis RAD cocok untuk proyek-proyek
  dengan jadwal waktu singkat yang membutuhkan
  kecepatan deliverables. metodologi berbasis
  waterfall adalah pilihan terburuk ketika waktu
  adalah penting karena tidak memungkinkan untuk
  memudahkan perubahan jadwal.

64
Bagaimana Memilih Metodologi

• Visibilitas jadwal pelaksanaan
• Metodologi berbasis RAD banyak bergerak dari
  keputusan2 penting sehingga metodologi ini paling
  cocok diterapkan jika manager proyek mengenali
  dan memberikan perhatian lebih bagi tahapan yang
  mempunyai faktor resiko dan ekspetasi yang tinggi.

65
Tugas SE I

• Amatilah kegiatan di tempat anda masing-masing
  yang kira-kira business prosess apa yang
  potensial untuk dikomputerisasikan dalam bentuk
  aplikasi software.
• Metodologi apa yang tepat
• Buatlah paper sederhana presentasikan
• Daftar isi paper
• Abstrak
• Pendahuluan
• Tinjauan pustaka
• Objek penilitian Pembahasan
• Kesimpulan