Model Prototipe
Model prototipe mensyaratkan bahwa sebelum melakukan pengembangan perangkat lunak yang sebenarnya, sebuah prototipe sistem yang berfungsi harus dibangun. Sebuah prototipe adalah implementasi sederhana dari sistem. Sebuah prototipe biasanya menjadi versi yang sangat kasar dari sistem yang sebenarnya, mungkin memiliki kemampuan fungsional yang terbatas, reliabilitas rendah, dan kinerja yang tidak efisien dibandingkan dengan perangkat lunak yang sebenarnya. Dalam banyak kasus, klien hanya memiliki pandangan umum tentang apa yang diharapkan dari produk perangkat lunak. Dalam skenario di mana tidak ada informasi detail tentang masukan ke sistem, kebutuhan pemrosesan, dan kebutuhan keluaran, model prototyping dapat digunakan. Langkah-langkah Model Prototipe Keuntungan Model Prototipe Kerugian Model Prototipe Model Proses Evolusioner Model proses evolusioner menyerupai model perbaikan berulang. Tahap-tahap yang sama seperti pada model waterfall terjadi di sini secara berulang. Model ini berbeda dari model perbaikan berulang dalam hal ini tidak memerlukan produk yang bermanfaat di akhir setiap siklus. Dalam pengembangan evolusioner, persyaratan diimplementasikan berdasarkan kategori daripada berdasarkan prioritas. Misalnya, dalam aplikasi database sederhana, satu siklus dapat mengimplementasikan antarmuka pengguna grafis (GUI), manipulasi file lainnya, kueri lainnya, dan pembaruan lainnya. Keempat siklus tersebut harus selesai sebelum ada produk yang berfungsi tersedia. GUI memungkinkan pengguna berinteraksi dengan sistem, manipulasi file memungkinkan data disimpan dan diambil kembali, kueri memungkinkan pengguna keluar dari sistem, dan pembaruan memungkinkan pengguna memasukkan data ke dalam sistem. Manfaat Model Proses Evolusioner //TC ref : [1][2]
Model Big Bang
Dalam model ini, pengembang tidak mengikuti proses tertentu yang spesifik. Pengembangan dimulai dengan dana dan upaya yang diperlukan dalam bentuk input. Dan hasilnya mungkin atau mungkin tidak sesuai dengan kebutuhan pelanggan, karena dalam model ini, bahkan persyaratan pelanggan tidak didefinisikan. Model ini ideal untuk proyek-proyek kecil seperti proyek akademis atau praktis. Satu atau dua pengembang dapat bekerja sama dalam model ini. Kapan Menggunakan Model Big Bang? Seperti yang telah kita diskusikan sebelumnya, model ini diperlukan ketika proyek tersebut kecil seperti proyek akademis atau proyek praktis. Metode ini juga digunakan ketika tim pengembang kecil dan ketika persyaratan tidak didefinisikan, dan tanggal rilis tidak dikonfirmasi atau diberikan oleh pelanggan. Keuntungan (Pros) Model Big Bang: Kekurangan (Cons) Model Big Bang: //TC ref : [1][2]
Model Iteratif
Dalam Model ini, Anda dapat memulai dengan beberapa spesifikasi perangkat lunak dan mengembangkan versi pertama perangkat lunak. Setelah versi pertama, jika ada kebutuhan untuk mengubah perangkat lunak, maka versi baru dari perangkat lunak dibuat dengan iterasi baru. Setiap rilis dari Model Iteratif selesai dalam periode yang tepat dan tetap yang disebut iterasi. Model Iteratif memungkinkan akses ke fase-fase sebelumnya, di mana variasi dilakukan secara berturut-turut. Output akhir proyek diperbaharui pada akhir proses Siklus Hidup Pengembangan Perangkat Lunak (SDLC). Tahapan-tahapan Model Iteratif: Berikut adalah tahapan dalam Model Iteratif: Kapan Menggunakan Model Iteratif? Keuntungan Model Iteratif: Kekurangan Model Iteratif: //TC ref : [1][2]
Model Agile
Arti dari Agile adalah cepat atau serbaguna. “Model proses Agile” mengacu pada pendekatan pengembangan perangkat lunak berbasis pengembangan iteratif. Metode Agile memecah tugas menjadi iterasi atau bagian yang lebih kecil yang tidak melibatkan perencanaan jangka panjang secara langsung. Lingkup proyek dan persyaratan ditetapkan di awal proses pengembangan. Rencana mengenai jumlah iterasi, durasi, dan lingkup masing-masing iterasi didefinisikan dengan jelas sebelumnya. Setiap iterasi dianggap sebagai “rangka waktu” singkat dalam model proses Agile, yang umumnya berlangsung dari satu hingga empat minggu. Pembagian seluruh proyek menjadi bagian-bagian lebih kecil membantu meminimalkan risiko proyek dan mengurangi persyaratan waktu pengiriman proyek secara keseluruhan. Setiap iterasi melibatkan tim yang bekerja melalui siklus hidup pengembangan perangkat lunak lengkap termasuk perencanaan, analisis persyaratan, desain, pengkodean, dan pengujian sebelum produk yang bekerja ditunjukkan kepada klien. Tahapan-tahapan Model Agile: Berikut adalah tahapan dalam model Agile: Metode Pengujian Agile: Kapan Menggunakan Model Agile? Keuntungan Model Agile: Kekurangan Model Agile: //TC ref : [1][2]
Model Incremental
Model Incremental adalah proses pengembangan perangkat lunak di mana persyaratan dibagi menjadi beberapa modul mandiri dari siklus pengembangan perangkat lunak. Dalam model ini, setiap modul melalui fase persyaratan, desain, implementasi, dan pengujian. Setiap rilis berikutnya dari modul menambahkan fungsi ke rilis sebelumnya. Proses ini berlanjut sampai sistem lengkap tercapai. Tahapan-tahapan model incremental adalah sebagai berikut: Kapan Menggunakan Model Incremental? Keuntungan Model Incremental Kekurangan Model Incremental //TC ref : [1][2]
Model V
Model V, juga disebut sebagai Model Verifikasi dan Validasi. Dalam model ini, setiap fase dari SDLC harus diselesaikan sebelum fase berikutnya dimulai. Ini mengikuti proses desain sekuensial yang sama dengan model air terjun. Pengujian perangkat direncanakan secara paralel dengan tahap pengembangan yang sesuai. Verifikasi: Validasi: Model V mengandung fase Verifikasi di satu sisi dan fase Validasi di sisi lainnya. Proses Verifikasi dan Validasi dihubungkan oleh fase pengkodean dalam bentuk huruf V. Oleh karena itu, dikenal sebagai Model V. Fase Verifikasi Model V: Fase Validasi Model V: Kapan Menggunakan Model V? Keuntungan Model V: Kekurangan Model V: //TC ref : [1][2]
Model Spiral
Model spiral, yang awalnya diusulkan oleh Boehm, adalah model proses perangkat lunak evolusioner yang menggabungkan fitur iteratif prototyping dengan aspek linear dan sistematis dari model sekuensial linear. Ini mengimplementasikan potensi pengembangan cepat versi baru perangkat lunak. Dengan menggunakan model spiral, perangkat lunak dikembangkan dalam serangkaian rilis inkremental. Selama iterasi awal, rilis tambahan mungkin berupa model kertas atau prototipe. Selama iterasi selanjutnya, versi sistem yang lebih lengkap diproduksi. Model Spiral terdiri dari empat bagian: Fase pengembangan tergantung pada risiko yang tersisa. Misalnya, jika risiko kinerja atau antarmuka pengguna lebih penting daripada risiko pengembangan program, fase berikutnya mungkin adalah pengembangan evolusioner yang mencakup pengembangan prototipe yang lebih rinci untuk menyelesaikan risiko tersebut. Fitur yang didorong oleh risiko dari model spiral memungkinkannya untuk menampung campuran apa pun dari pendekatan berorientasi spesifikasi, berorientasi prototipe, berorientasi simulasi, atau jenis pendekatan lainnya. Unsur penting dari model ini adalah bahwa setiap periode spiral diselesaikan dengan review yang mencakup semua produk yang dikembangkan selama siklus tersebut, termasuk rencana untuk siklus berikutnya. Model spiral dapat digunakan untuk pengembangan maupun proyek perbaikan. Kapan Menggunakan Model Spiral? Keuntungan Kekurangan //TC ref : [1][2]
Model Pengembangan Aplikasi Cepat (RAD)
Model RAD adalah model pengembangan perangkat lunak linear yang menekankan siklus pengembangan yang ringkas dengan pendekatan konstruksi berbasis elemen. Jika persyaratan dipahami dan dijelaskan dengan baik, dan cakupan proyek menjadi kendala, proses RAD memungkinkan tim pengembangan untuk menciptakan sistem yang sepenuhnya fungsional dalam periode waktu yang singkat. Konsep RAD: Fase-fase RAD: Kapan Menggunakan Model RAD? Keuntungan Model RAD Kekurangan Model RAD //TC ref : [1][2]
Waterfall Model
Winston Royce memperkenalkan Model Air Terjun pada tahun 1970. Model ini memiliki lima fase: analisis dan spesifikasi persyaratan, desain, implementasi dan pengujian unit, integrasi dan pengujian sistem, serta operasi dan pemeliharaan. Langkah-langkah selalu mengikuti urutan ini dan tidak tumpang tindih. Pengembang harus menyelesaikan setiap fase sebelum fase berikutnya dimulai. Model ini dinamai “Model Air Terjun”, karena representasinya secara diagramatik menyerupai air terjun. 1. Fase Analisis dan Spesifikasi Persyaratan Tujuan dari fase ini adalah memahami persyaratan yang tepat dari pelanggan dan mendokumentasikannya dengan baik. Baik pelanggan maupun pengembang perangkat lunak bekerja sama untuk mendokumentasikan semua fungsi, kinerja, dan persyaratan antarmuka perangkat lunak. Ini menjelaskan “apa” dari sistem yang akan diproduksi dan bukan “bagaimana”. Dalam fase ini, dokumen besar yang disebut Dokumen Spesifikasi Persyaratan Perangkat Lunak (SRS) dibuat yang berisi deskripsi rinci tentang apa yang akan dilakukan sistem dalam bahasa umum. 2. Fase Desain Fase ini bertujuan untuk mentransformasikan persyaratan yang terkumpul dalam SRS ke dalam bentuk yang sesuai yang memungkinkan pengkodean lebih lanjut dalam bahasa pemrograman. Ini menentukan arsitektur perangkat lunak secara keseluruhan bersama dengan desain tingkat tinggi dan rinci. Semua pekerjaan ini didokumentasikan sebagai Dokumen Desain Perangkat Lunak (SDD). 3. Implementasi dan Pengujian Unit Selama fase ini, desain diimplementasikan. Jika SDD lengkap, fase implementasi atau pengkodean berjalan lancar, karena semua informasi yang dibutuhkan oleh pengembang perangkat lunak terdapat dalam SDD. Pada saat pengujian, kode diperiksa dan dimodifikasi dengan cermat. Modul-modul kecil diuji secara terisolasi pada awalnya. Setelah itu, modul-modul ini diuji dengan menulis beberapa kode tambahan untuk memeriksa interaksi antara modul-modul ini dan aliran keluaran intermediat. 4. Integrasi dan Pengujian Sistem Fase ini sangat penting karena kualitas produk akhir ditentukan oleh efektivitas pengujian yang dilakukan. Hasil yang lebih baik akan menghasilkan pelanggan yang puas, biaya pemeliharaan yang lebih rendah, dan hasil yang akurat. Pengujian unit menentukan efisiensi modul individu. Namun, dalam fase ini, modul-modul diuji untuk interaksi mereka satu sama lain dan dengan sistem. 5. Fase Operasi dan Pemeliharaan Pemeliharaan adalah tugas yang dilakukan oleh setiap pengguna setelah perangkat lunak telah disampaikan kepada pelanggan, diinstal, dan operasional. Kapan Menggunakan Model Air Terjun SDLC? Beberapa Keadaan di mana penggunaan model Air Terjun paling cocok adalah: Keuntungan Model Air Terjun Model ini sederhana untuk diimplementasikan dan jumlah sumber daya yang diperlukan untuk itu minimal. Persyaratan sederhana dan dijelaskan secara eksplisit; mereka tetap tidak berubah selama seluruh pengembangan proyek. Titik awal dan akhir untuk setiap fase ditetapkan, yang membuatnya mudah untuk melacak kemajuan. Tanggal rilis untuk produk lengkap, serta biaya akhirnya, dapat ditentukan sebelum pengembangan. Memberikan kontrol yang mudah dan kejelasan bagi pelanggan karena sistem pelaporan yang ketat. Kekurangan Model Air Terjun Dalam model ini, faktor risiko lebih tinggi, sehingga model ini tidak cocok untuk proyek yang lebih besar dan kompleks. Model ini tidak dapat menerima perubahan persyaratan selama pengembangan. Menjadi sulit untuk kembali ke fase sebelumnya. Sebagai contoh, jika aplikasi sudah beralih ke fase pengkodean, dan ada perubahan persyaratan, menjadi sulit untuk kembali dan mengubahnya. Karena pengujian dilakukan pada tahap yang lebih lanjut, tidak memungkinkan untuk mengidentifikasi tantangan dan risiko pada fase sebelumnya, sehingga strategi pengurangan risiko sulit disiapkan. //TC ref : [1][2]
Rekayasa Persyaratan (Requirement Engineering)
Rekayasa persyaratan (RE) merujuk pada proses mendefinisikan, mendokumentasikan, dan memelihara persyaratan dalam proses desain rekayasa. Rekayasa persyaratan menyediakan mekanisme yang sesuai untuk memahami apa yang diinginkan oleh pelanggan, menganalisis kebutuhan, menilai kelayakan, bernegosiasi solusi yang masuk akal, menyatakan solusi dengan jelas, memvalidasi spesifikasi, dan mengelola persyaratan saat mereka diubah menjadi sistem yang berfungsi. Dengan demikian, rekayasa persyaratan adalah penerapan disiplin dari prinsip-prinsip, metode, alat, dan notasi terbukti untuk menggambarkan perilaku yang diinginkan dari sistem yang diusulkan dan batasan yang terkait dengannya. Proses Rekayasa Persyaratan Manajemen Persyaratan Perangkat Lunak: Manajemen persyaratan adalah proses mengelola perubahan persyaratan selama proses rekayasa persyaratan dan pengembangan sistem. Persyaratan Prasyarat: Pengumpulan persyaratan perangkat lunak adalah dasar dari seluruh proyek pengembangan perangkat lunak. Oleh karena itu, mereka harus jelas, benar, dan terdefinisi dengan baik. Sebuah Dokumen Spesifikasi Persyaratan Perangkat Lunak yang lengkap harus: Persyaratan Perangkat Lunak: Persyaratan perangkat lunak sebagian besar harus dikategorikan menjadi dua kategori: Persyaratan non-fungsional dibagi menjadi dua kategori utama: //TC ref : [1][2]
