PROSES-PROSES PERANGKAT LUNAK

1. PROSES-PROSES PERANGKAT LUNAK STMIK BANDUNG

2. Serangkaiankegiatandanhasil yang berhubungandengannya, yang menujupadadihasilkannyaprodukperangkatlunak. • Kegiatan-kegiatanmendasarygumumbagisemuaprosesPerangkatLunak : • SpesifikikasiPerangkatLunak Fungsionalitasperangkatlunakdanbatasankemampuanoperasinyaharusdidefinisikan. • Pengembangan (PerancangandanImplementasi) PerangkatLunak Perangkatlunak yang memenuhispesifikasiharusdiproduksi • ValidasiPerangkatLunak  Perangkatlunakharusdivalidasiuntukmenjaminbahwaperangkatlunakbekerjasesuaidenganapa yang diinginkanolehpelanggan. • EvolusiPerangkatLunak Perangkatlunakharusberkembanguntukmemenuhikebutuhanpelanggan. PROSES PERANGKAT LUNAK

3. Model air terjun (waterfall)  Biasa juga disebut siklus hidup perangkat lunak. Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya. Model Proses Perangkat Lunak

4. Analisis dan Definisi Persyaratan  Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user sistem. • Perancangan sistem dan Perangkat Lunak  Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras atau perangkat lunak. Menentukan arsitektur sistem secara keseluruhan. • Implementasi dan pengujian unit  Perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.

5. Integrasi dan Pengujian Sistem  Unit program atau program individual diintegrasikan dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah pengujian sistem, PL dikirim ke User. • Operasi dan Pemeliharaan  Biasanya merupakan fase siklus yg paling lama (walaupun tidak seharusnya). Sistem diinstall dan di pakai. Pemeliharaan mencakup koreksi dan berbagai error yg tdk ditemukan pada tahap2 sebelumnya, perbaikan atas implementasi unit sistem dan pengembangan pelayanan sistem.

6. Gambar model waterfall

7. Fase-fase Waterfall menurut Pressman

8. Terjadinyapembagianproyekmenjaditahap-tahap yang tidakfleksibel, karenakomitmenharusdilakukanpadatahapawalproses. • Hal inimengakibatkansulitnyauntukmeresponperubahankebutuhanpengguna(user). • Model air terjunharusdigunakanhanyaketikapersyaratandipahamidenganbaik. Masalahdengan model waterfall

9. PengembanganEvolusioner Berdasarkanpadaideuntukmengembangkanimplementasiawal, memperlihatkannyakepadauseruntukdikomentari, danmemperbaikinyaversidemiversisampaisistem yang memenuhipersyaratandiperoleh. Tidakadakegiatanspesifikasi, pengembangan, danvalidasi yang terpisah. Kegiatan2 inidilakukanpadasaat yang bersamaandenganumpanbalik yang cepatuntuk masing2 kegiatan.

10. Gambar model PengembanganEvolusioner

11. PengembanganEksplotari Tujuanprosesiniadalahbekerjadenganpelangganuntukmenyelidikipersyaratanmerekadanmengirimkansistemakhir. Harusnyadiawalidengankebutuhan yang sudahdimengerti. • Prototipe yang dapatdibuang(throw-away)  Berkonsentrasipadaeksperimen, denganpersyaratanpelanggan yang tidakdipahamidenganbaik. Ada 2 jenispengembanganevolusioner :

12. Lebih efektif dari pendekatan air terjun dalam menghasilkan sistem yang memenuhi kebutuhan langsung dari pelanggan. • Sementara user mendapat pemahaman yang lebih baik dari masalah mereka, sistem perangkat lunak dapat merefleksikannya. Kelebihan model PengembanganEvolusioner

13. C. Model PengembanganSistem Formal • ProsespengembanganPerangkatLunakdidasarkanpadatransformasimatematisdarispesifikasisistemmenjadi program yang dapatdijalankan.

14. Kurangnyavisibilitasproses Jikasistemdikembangkandengancepat, tidaklahefektifdarisegibiayajikadihasilkandokumen yang merefleksikansetiapversisistem. • Sistemseringkalimemilikistruktur yang buruk  Perubahan yang terus-meneruscenderungmerusakstrukturperangkatlunak. Penyesuaianperubahanmenjadikiansulitdanmahal. • Membutuhkankemampuankhusus. Masalahpada model PengembanganEvolusioner

15. Memerlukan keahlian khusus dan pelatihan untuk mengaplikasikannya • Untuk sebagian besar sistem, metode ini tidak memberikan keuntungan biaya atau kualitas yang signifikan dibandingkan dengan pendekatan yang lain. MasalahdalamPengembanganMetode Formal

16. Bergantung pada sejumlah besar komponen perangkat lunak yang dapat dipakai ulang, yang bisa didapat, dan berapa kerangka kerja integrasi untuk komponen-komponen ini. • Komponen-komponen ini dapat juga sistem yang disebut COTS (Commercial Off-The-Shelf Systems/Sistem Siap Beli Komersial) yang dapat digunakan untuk memberikan fungsionalitas khusus seperti format teks, perhitungan numerik,dll. D. Model PengembanganBerorientasiPemakaianUlang(Re-Usable)

17. Gambar Model PengembanganBerorientasiPemakaianUlang(Re-Usable)

18. Analisis Komponen  Spesifikasi persyaratan telah diketahui, komponen2 untuk implementasi spesifikasi tersebut akan dicari. Biasanya, tidak ada kesesuaian yang tepat dan komponen yang dapat dipakai hanya memberikan sebagian dari fungsionaliyas yang dibutuhkan. • Modifikasi Persyaratan  Persyaratan dianalisis menggunakan informasi tentang komponen yang didapat, kemudian dimodifikasi untuk merefleksikan komponen yang ada. Jika modifikasi tidak mungkin dilakukan, maka kegiatan analisis komponen bisa diulang untuk mencari solusi alternatif. Tahap-tahap Re-Usable

19. Perancangan sistem dengan pemakaian ulang  Kerangka kerja sistem dirancang, atau kerangka kerja yang telah ada dipakai ulang. • Pengembangan dan Integrasi  Perangkat Lunak yang tidak dapat dibeli akan dikembangkan dan komponen dan sistem COTS diintegrasikan untuk membantu sistem.

20. Mengurangi besarnya perangkat lunak yang akan dikembangkan • Memperkecil biaya dan resiko • Memungkinkan penyelesaian perangkat lunak dengan cepat Keuntungan Model Re-Usable

21. Digunakanuntukkebanyakansistembesar • Perludigunakanberbagaipendekatanuntukberbagaibagiansistem, sehinggaharusdigunakan model HIBRID  bagianprosesdiulang, sementarapersyaratansistemberubah. • Terdapat 2 model iterasi : • PengembanganInkremental • Pengembangan Spiral ITERASI PROSES

22. Pengembangan sistem berdasarkan model sistem yang dipecah sehingga model pengembangannya secara increment/bertahap. • Kebutuhan pengguna diprioritaskan dan prioritas tertinggi dimasukkan dalam awal increment A. Pengembangan Inkremental

24. Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan. • Element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna. • Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan. • Mampu mengakomodasi perubahan secara fleksibel. • Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar. Penjelasan model Inkremen Pressman

25. Model Increment Sommerville

26. B. SPIRAL MODEL

27. Proses digambarkan sebagai spiral. • Setiap loop mewakili satu fase dari software process. • Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya

28. Objective settings (menentukan tujuan): menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan. • Risk assessment and reduction (Penanganan dan pengurangan resiko): setiap resiko dianalisis secara detil pada sektor ini. Langkah-langkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan. Setiap Loop dibagimenjadibeberapasektor :

29. Development and Validation (Pembangunan dan pengujian): Setelah evaluasi resiko, maka model pengembangan sistem dipilih. • Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. • Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, • Jika masalahnya adalah integrasi sistem model waterfall lebih cocok.

30. Planning : Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya. • Pada model spiral, resiko sangat dipertimbangkan. • Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. • Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. • Pengguna dan pembangun (Perekayasa) bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. • Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.

31. RAD adalah model prosespembangunan PL yang incremental. • RAD menekankanpadasikluspembangunan yang pendek/singkat. • RAD mengadopsi model waterfall danpembangunandalamwaktusingkatdicapaidenganmenerapkan component based construction. • Waktu yang singkatadalahbatasan yang pentinguntuk model ini. • Jikakebutuhanlengkapdanjelasmakawaktu yang dibutuhkanuntukmenyelesaikansecarakomplit software yang dibuatadalahmisalnya 60 sampai 90 hari. RAD (Rapid Application Development)

32. Tidak cocok untuk proyek skala besar • Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi • Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini • Resiko teknis yang tinggi juga kurang cocok untuk model ini Kelemahan dalam model ini:

33. Gambar Model RAD

34. Fase-fase di atas menggambarkan proses dalam model RAD. • Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir bersamaan dalam batasan waktu yang sudah ditentukan. • Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi?  kebutuhan dari sistem • Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut  analisis kebutuhan dan data • Process Modelling : objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis. • Application Generation: RAD menggunakan component program yang sudah ada atau membuat component yang bisa digunakan lagi, selama diperlukan. • Testing and Turnover: karena menggunakan component yang sudah ada, maka kebanyakan component sudah melalui uji atau testing. Namun component baru dan interface harus tetap diuji.

35. Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. • Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. • Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software. Prototyping Model

36. Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan • Perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype. • Evaluasi prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software. Prosespada model prototyping yang bisadijelaskansebagaiberikut:

37. Gambar model Prototype

38. Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. • Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. • Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan. • Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari prototype , membantu mendapatkan kebutuhan detil lebih baik namun demikian prototype juga menimbulkan masalah.

39. Dalammembuat prototype banyakhal yang diabaikansepertiefisiensi, kualitas, kemudahandipelihara/dikembangkan, dankecocokandenganlingkungan yang sebenarnya. Jikaklienmerasacocokdengan prototype yang disajikandanberkerasterhadapproduktersebut, maka developer haruskerjakerasuntukmewujudkanproduktersebutmenjadilebihbaik, sesuaikualitas yang seharusnya. • developer biasanyamelakukankompromidalambeberapahalkarenaharusmembuat prototype dalamwaktusingkat. Mungkinsistemoperasi yang tidaksesuai, bahasapemrograman yang berbeda, ataualgoritma yang lebihsederhana. Masalahygadapada Prototype Model :

40. Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.