- Sejarah
- Penciptaan
- Alternatif model air terjun
- Fitur model spiral
- Pengendalian resiko
- Deskripsi spiral
- Umum
- Fleksibel
- Metamodel
- Tahapan
- Tentukan tujuan, alternatif dan kendala
- Evaluasi risiko
- Pengembangan dan pengujian
- Merencanakan siklus berikutnya
- Contoh
- Keuntungan
- Struktur siklus
- Manajemen risiko
- Partisipasi dan umpan balik pelanggan
- Ideal untuk proyek besar
- Kekurangan
- Mahal
- Cukup rumit
- Manajemen waktu
- Banyak langkah
- Referensi
Model spiral adalah pola dasar dari proses pengembangan aplikasi. Hal ini didasarkan pada hipotesis bahwa pengembangan perangkat lunak merupakan siklus berulang yang diulang hingga tujuan yang telah ditetapkan tercapai. Ia memiliki kemampuan untuk menangani sejumlah besar risiko yang dapat terjadi saat mengembangkan perangkat lunak apa pun.
Ini adalah salah satu model terpenting untuk mendukung manajemen risiko. Seperti namanya, model ini ditampilkan dalam bentuk spiral, di mana berbagai tahapan model didistribusikan dalam siklus yang berbeda. Jumlah siklus dalam model tidak tetap dan dapat bervariasi dari proyek ke proyek.
Analisis, evaluasi, perencanaan dan pengembangan. Spiral Pengembangan Perangkat Lunak Sumber: Beao commons.wikimedia.org
Sejarah
Penciptaan
Model spiral didefinisikan oleh matematikawan Amerika dan profesor teknik perangkat lunak Barry Boehm. Setelah mempresentasikan konsepnya pada tahun 1986 untuk pengembangan aplikasi yang kompleks, ia menerbitkan modelnya pada tahun 1988 dalam kerangka yang lebih komprehensif dalam artikelnya "A Spiral Model of Software Development and Improvement".
Bagian dari publikasi tahun 1988 ini secara grafis menggambarkan model spiral, menunjukkan secara komprehensif seperti apa proses pengembangan perangkat lunak secara spiral dan didukung oleh siklus.
Boehm dikenal atas banyak kontribusinya pada rekayasa perangkat lunak, seperti model biaya konstruktif (COCOMO), model spiral proses perangkat lunak, pendekatan G-Theory (menang-menang) untuk penentuan dan manajemen persyaratan. dari perangkat lunak.
Alternatif model air terjun
Dalam publikasinya, Boehm mendeskripsikan model spiral sebagai alternatif yang mungkin dari model air terjun yang sudah ada sebelumnya, yang juga menjadi dasar praktiknya.
Model spiral bukanlah yang pertama membahas perkembangan siklis, tetapi model pertama yang menjelaskan mengapa iterasi itu penting. Seperti yang direncanakan semula, telah ditargetkan pada proyek besar dan kompleks yang iterasinya biasanya berkisar dari 6 bulan hingga 2 tahun.
Model ini tidak mengasumsikan bahwa tugas pengembangan perangkat lunak dirancang secara linier, tidak seperti model air terjun, tetapi melihatnya sebagai tugas yang berulang.
Model siklus ini mempengaruhi Model Based Software Engineering Architecture (MBASE) dan pemrograman ekstrim.
Fitur model spiral
Pengendalian resiko
Apa yang sangat membedakan model ini dari model proses perangkat lunak lainnya adalah bahwa model ini secara eksplisit mengenali risiko. Dengan demikian, ini sangat mengurangi kegagalan proyek perangkat lunak besar dengan menilai risiko berulang kali dan memverifikasi produk yang sedang dikembangkan setiap kali.
Model komputer ini berisi komponen dari hampir semua model siklus hidup perangkat lunak, seperti model air terjun, model prototyping, model iteratif, model evolusioner, dan sebagainya.
Karena itu, ia mampu menangani hampir semua jenis risiko yang umumnya tidak ditangani oleh model lain. Namun, karena memiliki banyak komponen, model ini jauh lebih kompleks daripada model pengembangan perangkat lunak lainnya.
Deskripsi spiral
Setiap putaran spiral mewakili satu siklus lengkap, yang selalu dilalui empat kuadran, mewakili empat tahapan model.
Ketika ukuran spiral bertambah, begitu pula kemajuan yang dicapai. Oleh karena itu, tahapan tidak dilakukan hanya sekali, tetapi beberapa kali, secara spiral.
Meskipun pengulangan siklus ini membuat proyek perlahan mendekati tujuan yang ditetapkan, risiko kegagalan proses pengembangan sangat diminimalkan.
Umum
Keempat tahapan tersebut hanya mengimplementasikan tujuan dasar dari sebuah siklus, tetapi tidak harus dimanifestasikan dalam setiap siklus.
Urutan setiap siklus juga tidak ditentukan secara ketat. Sebab, model tersebut sewaktu-waktu dapat dipadukan dengan model lain.
Fleksibel
Ini cukup fleksibel, karena melaksanakan definisi tujuan, analisis risiko, pengembangan dan proses perencanaan secara terpisah untuk setiap fase proyek.
Metamodel
Ini dianggap sebagai metamodel karena termasuk model lainnya. Misalnya, jika spiral adalah satu siklus, itu akan mewakili model air terjun, karena ini menggabungkan pendekatan bertahap dari model klasik ini.
Ia juga menggunakan pendekatan model prototyping, karena di setiap awal siklus ia menyusun prototipe untuk mengelola risiko.
Lebih jauh, ini kompatibel dengan model evolusi, karena iterasi spiral dapat dianggap sebagai tingkat evolusi, yang melaluinya sistem akhir dibangun.
Tahapan
Tentukan tujuan, alternatif dan kendala
Persyaratan sistem didefinisikan sedetail mungkin, termasuk kinerja, antarmuka perangkat keras / perangkat lunak, indikator kunci keberhasilan, dll. dan tujuan apa yang harus dikaitkan dengan siklus pembangunan saat ini dipertimbangkan.
Selain itu, berbagai alternatif untuk implementasinya diperiksa, seperti build vs. membeli, menggunakan kembali komponen atau outsourcing yang ada, dll.
Demikian juga, pembatasan seperti biaya, jadwal dan antarmuka, konsumsi waktu, dll. Ditentukan.
Evaluasi risiko
Semua alternatif yang diusulkan dievaluasi. Tujuan dan kendala menjadi acuan penentu untuk memilih solusi terbaik.
Selain itu, risiko yang dapat menghambat keberhasilan proyek diidentifikasi, seperti kurangnya pengalaman, teknologi baru, jadwal yang ketat, proses yang buruk, dll., Menerapkan strategi yang paling menguntungkan dengan risiko terendah.
Akhirnya, metode seperti pembuatan prototipe, simulasi, model analitis, dan survei pengguna digunakan.
Pengembangan dan pengujian
Semua pengembangan yang diperlukan dilakukan, menggunakan teknologi dan solusi terpilih. Dengan setiap iterasi, versi aplikasi yang lebih baik dibuat.
Kode sebenarnya ditulis dan diuji beberapa kali hingga hasil yang diinginkan tercapai, yang kemudian akan menjadi dasar untuk langkah pengembangan di masa mendatang.
Merencanakan siklus berikutnya
Setelah menyelesaikan satu siklus, perencanaan untuk siklus berikutnya dimulai. Perencanaan ini dapat melanjutkan proyek secara normal jika tujuan siklus tercapai, dengan mempertimbangkan definisi tujuan berikutnya.
Bisa juga untuk mencari solusi lain, jika tahap pengembangan sebelumnya terbukti salah. Strategi yang ada dapat diganti dengan salah satu alternatif yang telah ditetapkan sebelumnya atau yang baru. Dengan ini, upaya baru untuk mencapai tujuan tertentu akan dimulai.
Contoh
Militer Amerika Serikat mengadopsi model spiral untuk pengembangan dan peningkatan program modernisasi Future Fighting Systems (SCF).
Secara resmi diluncurkan pada tahun 2003, SCF diharapkan untuk melengkapi pasukan dengan kendaraan yang terhubung secara real time ke jaringan medan perang yang sangat cepat dan fleksibel.
Proyek ini dibagi menjadi empat spiral pengembangan masing-masing sekitar dua tahun. Spiral 1 dijadwalkan untuk dimulai pada tahun 2008 dan mengirimkan prototipe untuk digunakan dan dievaluasi.
Setelah spiral 1 selesai, spiral 2 dijadwalkan akan dimulai pada 2010. Pengembangan produk akhir dijadwalkan akan diserahkan pada 2015.
Pada bulan Agustus 2005, Boeing mengumumkan penyelesaian tonggak penting pertama proyek, yang merupakan perbaikan fungsional sistem. Boeing dan Science Applications International Corporation adalah co-leader proyek tersebut.
Namun, untuk Oktober 2005 Pentagon merekomendasikan penundaan proyek karena dampak tinggi pada biaya dari perang Irak dan bantuan dari Badai Katrina.
Proyek tersebut dibatalkan pada tahun 2009 setelah pemotongan anggaran muncul, tanpa dapat membuktikan manfaat model spiral dalam misi ini
Keuntungan
Struktur siklus
Karena jenis struktur ini, masalah antara desain dan persyaratan teknis perangkat lunak secara diam-diam dihilangkan, berkat pemeriksaan berkala.
Manajemen risiko
Risiko dianalisis pada setiap tahap produk sebelum melangkah lebih jauh. Ini membantu untuk mengatasi atau mengurangi potensi risiko.
Semua karyawan mendapat manfaat dari pentingnya analisis risiko dalam model ini, mungkin mewakili keunggulan terbesar mereka dibandingkan model proses lainnya.
Penilaian risiko reguler sangat berharga saat menggunakan lingkungan teknis baru, yang umumnya terkait dengan potensi risiko tertentu karena tidak adanya nilai empiris.
Partisipasi dan umpan balik pelanggan
Pelanggan dilibatkan dalam setiap tahap proyek, hingga proyek selesai. Oleh karena itu, umpan balik yang berbeda dapat dikumpulkan untuk meningkatkan versi proyek berikutnya.
Juga, umpan balik dapat diperoleh kapan saja karena gerak maju berbentuk spiral. Dengan demikian, pelanggan dan pengguna dapat terintegrasi sejak awal dalam proses pembangunan.
Ideal untuk proyek besar
Ini sangat populer dan menonjol untuk proyek besar dan kompleks, di mana kontrol anggaran menjadi prioritas bagi klien dan pengembang. Anda memiliki kendali maksimum atas biaya, sumber daya, dan kualitas proyek perangkat lunak.
Kekurangan
Mahal
Biayanya bisa sangat mahal, karena memerlukan keahlian tingkat tinggi untuk analisis risiko. Selain itu, proyek membutuhkan banyak waktu untuk dikembangkan, yang dapat meningkatkan overhead.
Cukup rumit
Diperlukan manajemen proyek sebelumnya yang sangat aktif dan kompleks, di mana setiap siklus dikontrol dan didokumentasikan secara terus menerus dan cermat.
Model ini secara komparatif lebih kompleks daripada model lainnya, karena terdapat banyak siklus, masing-masing melalui tahapan yang berbeda, sehingga meningkatkan upaya proses dokumentasi.
Pengetahuan tentang analisis dan manajemen risiko, yang seringkali tidak tersedia, sangat penting.
Manajemen waktu
Waktu sulit untuk diatur karena jumlah siklusnya tidak diketahui. Selain itu, proses pengembangan dapat tertunda sewaktu-waktu jika keputusan penting harus dibuat dalam satu siklus atau dengan tindakan tambahan saat merencanakan siklus berikutnya.
Banyak langkah
Mengambil banyak langkah dalam pengembangan perangkat lunak tidak selalu menguntungkan karena, terlepas dari keserbagunaan pengujian, bagian program yang belum selesai dapat mencapai sistem yang sudah selesai.
Akibatnya, selalu ada bahaya bahwa kesalahan atau ketidakkonsistenan konseptual akan mempengaruhi produk akhir.
Referensi
- Victor Font Jr (2019). Model Spiral. Panduan Utama untuk SDLC. Diambil dari: ultimatesdlc.com.
- Ionos (2019). Model spiral: model proses pengembangan perangkat lunak berbasis risiko. Diambil dari: ionos.com.
- Techuz (2018). Apa itu Model Spiral? Penjelasan Sederhana Siklus Hidup Pengembangan Perangkat Lunak Spiral (SDLC). Diambil dari: techuz.com.
- One Stop Testing (2020). Model Spiral. Diambil dari: onestoptesting.com.
- Geeks for Geeks (2020). Rekayasa Perangkat Lunak - Model Spiral. Diambil dari: geeksforgeeks.org.
- Chandu (2019). Model Spiral dalam Rekayasa Perangkat Lunak. Diambil dari: medium.com.