Rekayasa Perangkat Lunak Kuliah - 3

1. Rekayasa Perangkat LunakKuliah - 3 Rianto Teknik Informatika - Universitas Siliwangi

2. Model Proses Perangkat Lunak Penerapansebuahstrategioleh software engineer atautim engineer yang mencakupproses, metode, danpirantimemecahkanpersoalandalamlingkupindustri. Strategiiniseringdisebutsebagai model prosesatau paradigmarekayasaperangkatlunak.

3. Pengembanganperangkatlunakdapatdicirikansebagaiiterasiprosespemecahanpersoalan (problem solving loop)

4. Status quo merepresentasikan status perkerjaan yang sedang dilakukan yang merupakan bagian perkerjaan dari keseluruhan iterasi. • Pendefinisian persoalan mendefinisikan persolan yang sedang dihadapi dan akan dicarikan pemecahannya. • Pengembangan teknis memecahkan masalah melalui penerapan beberapa teknologi • Integrasi solusi menyampaikan hasil solusi (dokumen, program, data, fungsi bisnis baru, produk baru) ke pemesan.

5. Model Proses Perangkat Lunak • Linear Sequential Model Model proses ini sering disebut sebagai Waterfall atau Classic Life Cycle Model. Metode Linear Sequential Model menyarankan pendekatan yang sistematis dan sekuensial dalam pengembangan perangkat lunak yang dimulai pada level sistem dan bergerak maju mulai tahap analisis, desain, coding, testing, dan support.

6. Linear Sequensial Model Gambar Linear Sequential Model

7. Rekayasa dan pemodelan sistem/informasi (System/information engineering). Dikarenakan perangkat lunak selalu merupakan bagian dari sistem atau bisnis yang lebih besar, kegiatan proses perangkat lunak dimulai dengan melakukan indentifikasi kebutuhan (requirements) dari seluruh elemen sistem lalu memetakan bagian dari kebutuhan tersebuat sebagai kebutuhan perangkat lunak. Pandangan secara sistem ini sangat dibutuhkan ketika perangkat lunak harus berinterakasi dengan elemen-elemen yang lain seperti perangkat keras, manusia, dan basisdata. Identifikasi dan pengumpulan kebutuhan dilakukan dalam level strategi bisnis dan level manajerial.

8. Analisis kebutuhan perangkat lunak (Software requirements analysis). Proses identifikasi dan pengumpulan kebutuhan sistem difokeskan pada kebutuhan perangkat lunak. Untuk memahami program-program yang akan dibangun, analis harus memahami domain dan lingkup perangkat lunak yang akan dibangun, termasuk didalamnya fungsi, tingkah laku perangkat lunak, performansi, dan antarmuka. Kebutuhan sistem dan perangkat lunak didokumentasikan dan dikonfirmasikan dengan customer.

9. Desain (Design) Proses desain perangkat lunak fokus kepada sturktur data, arsitektur perangkat lunak, representasi antarmuka, dan algoritma detil proses. Desain merupakan representasi kebutuhan yang akan dijadikan pedoman dalam pengkodean program. Desain didokumentasikan dan menjadi bagian dari manajemen konfigurasi perangkat lunak. • Pengkodean (Code generation) Desain yang telah dibuat, ditranslasikan ke dalam suatu bahasa pemrograman tertentu.

10. Pengujian (Testing). Setelah kode program dibangun, program diuji untuk memastikan bahwa semua kebutuhan dan persoalan dapat diselesaikan dan benar. Proses pengujian fokus pada logika perangkat lunak. Memastikan bahwa dari proses input, pemrosesan, hingga output benar dan sesuai dengan yang diinginkan. • Support. Perangkat lunak sangat memungkinkan untuk berubah. Perubahan dapat terjadi karena ditemukannya kesalahan, perangkat lunak harus diadaptasikan kepada sistem yang baru, customer menginginkan peningkatan fungsional dan performansi perangkat lunak, dan perawatan perangkat lunak.

11. Keunggulan Waterfall • Programmer jarang diinterupsi pekerjaanya dengan perubahan kebutuhan, sehingga programmer dapat lebih konsentrasi. • Bila proses yang dilakukan telah jelas dan pasti, model ini akan memberikan efisiensi dan efektivitas yang tinggi. • Dituntut bekerja secara disiplin • Dokumennya lengkap • Maintenance mudah karena memiliki dokumen yang lengkap • Selalu dalam kontrol SQA (Software Quality Assurance)

12. Kekurangan Waterfall • Umumnya customer kurang bisa menyampaikan seluruh kebutuhan yang diinginkannya dalam tahan pendefinisian, sehingga dalam proses pengembangan perangkat lunak sering customer menginginkan perubahan atau tambahan kebutuhan. Model waterfall sulit mengakomodasi perubahan ini. • Kesalahan yang dibuat akan dibawa ke tahap berikutnya. Pada tahap pengujian (testing) bila kesalahan tersebut ditemukan, kesalahan tersebut telah terakumulasi dan berinteraksi dengan proses-proses lain, sehingga biaya (waktu, uang, sumber daya lain) dan usaha harus dikeluarkan dalam jumlah yang besar.

13. Keterlibatan customer sangat minim. Customer harus sabar menunggu hingga semua program selesai dibangun. • Konsumen sulit membaca dokumen menyebabkan komunikasi juga menjadi sulit • Alur pengerjaan yang linier menyebabkan proses menjadi lambat • Personil tidak bekerja optimal karena ada waktu tunggu atau jeda setiap tahapan.

14. Prototyping Model Sering customer dalam memesan perangkat lunak tidak dapat mengidentifikasi input, proses, dan permintaan output secara detil. Kasus lain, yaitu pengembang tidak yakin terhadap efisiensi algoritma yang digunakan terhadap permasalahan yangdihadapi customer, kemampuan adaptasi terhadap sistem operasi, atau bentuk interaksi manusia -perangkat lunak yang akan diterapkan. Pada kasus-kasus ini, paradigma prototyping memberikan pendekatan yang lebih baik.

15. Gambar Prototyping Model

16. Aktivitas Prototyping Model • Pengumpulan kebutuhan. Aktivitas dimulai dengan pengumpulan kebutuhan (requirements). Pengembang dan customer bertemu untuk menentukan tujuan keseluruhan dan global perangkat lunak, mengidentifikasi kebutuhan yang telah diketahui, lalu mendefinisikan area dan lingkup pengembangan. • Desain. Proses desain dilakukan dengan sangat cepat. Desain difokuskan kepada aspek-aspek desain yang nampak kepada customer/user (contoh: interface, pendekatan input, format output). Hasil desain inilah yang disebut sebagai prototipe.

17. Aktivitas Prototyping Model-2 • Evaluasi Prototipe. Prototipe yang dihasilkan, direview oleh customer. Hasil evaluasi ini dijadikan bahan untuk perubahan dan pengembangan selanjutnya. Iterasi terus dilakukan hingga memenuhi keinginan customer, sementara pada saat yang sama, memungkinkan pengembang untuk dapat lebih memahami kebutuhan perangkat lunak.

18. Keunggulan • Dapat segera memahami kebutuhan customer. • Dapat segera menemukan kesalahan program atau kesalahan interpretasi kebutuhan perangkat lunak. • Customer atau user dapat segera memahami dan mempunyai gambaran terhadap sistem (PL) yang akan dibangun.

19. Kelemahan • Biasanya customer setelah melihat prototipe terakhir yang telah disepakati bersama, customer ingin segera memilikinya. Tidak peduli efisiensi algoritma yang digunakan, dokumentasi, dan aspek-aspek rekayasa perangkat lunak lain. Hal ini dapat menyebabkan kualitas perangkat lunak menjadi rendah. • Programmer akan sering diinterupsi oleh perubahan. Sedangkan sifat alamiah perubahan adalah mengganggu.

20. Metode Analisis dan Perancangan Perangkat Lunak Terlepas dari paradigma pengembangan perangkat lunak yang dijelaskan di atas, ada dua pendekatan yang bisa dilakukan dalam Analisa dan Perancangan Perangkat Lunak, yaitu: Pendekatan Berorientasi Data (Data Oriented Approach) / Terstruktur • Data Flow Oriented • Data Structured Oriented

21. Metode Analisis dan Perancangan Perangkat Lunak Pendekatan Berorientasi Objek (Object Oriented Approach) / Objek • Shlaer/Mellor Method [Shlaer-1988] • Coad/Yourdan Method [Coad-1991] • Booch Method [Booch-1991] / OOAD • OMT Method [Rumbaugh-1991] • Wirfs-Brock Method [Wirfs-Brock-1990] • OOSE Objectory Method [Jacobson-1992] • UML (Unified Modeling Language) [UML-1997]

22. Terima Kasih Rianto