SDLC - Panduan Cepat

Siklus Hidup Pengembangan Perangkat Lunak (SDLC) adalah proses yang digunakan oleh industri perangkat lunak untuk merancang, mengembangkan, dan menguji perangkat lunak berkualitas tinggi. SDLC bertujuan untuk menghasilkan perangkat lunak berkualitas tinggi yang memenuhi atau melebihi harapan pelanggan, mencapai penyelesaian dalam waktu dan perkiraan biaya.

SDLC adalah singkatan dari Software Development Life Cycle.
Ini juga disebut sebagai Proses Pengembangan Perangkat Lunak.
SDLC adalah kerangka kerja yang mendefinisikan tugas yang dilakukan pada setiap langkah dalam proses pengembangan perangkat lunak.
ISO / IEC 12207 adalah standar internasional untuk proses siklus hidup perangkat lunak. Ini bertujuan untuk menjadi standar yang mendefinisikan semua tugas yang diperlukan untuk mengembangkan dan memelihara perangkat lunak.

Apa itu SDLC?

SDLC adalah proses yang diikuti untuk proyek perangkat lunak, dalam organisasi perangkat lunak. Ini terdiri dari rencana terperinci yang menjelaskan cara mengembangkan, memelihara, mengganti, dan mengubah atau meningkatkan perangkat lunak tertentu. Siklus hidup mendefinisikan metodologi untuk meningkatkan kualitas perangkat lunak dan proses pengembangan secara keseluruhan.

Gambar berikut adalah representasi grafis dari berbagai tahapan SDLC tipikal.

Siklus Hidup Pengembangan Perangkat Lunak biasanya terdiri dari tahapan berikut -

Tahap 1: Analisis Perencanaan dan Kebutuhan

Analisis kebutuhan adalah tahap terpenting dan fundamental dalam SDLC. Ini dilakukan oleh anggota senior tim dengan masukan dari pelanggan, departemen penjualan, survei pasar, dan pakar domain di industri. Informasi ini kemudian digunakan untuk merencanakan pendekatan proyek dasar dan untuk melakukan studi kelayakan produk di bidang ekonomi, operasional dan teknis.

Perencanaan persyaratan jaminan kualitas dan identifikasi risiko yang terkait dengan proyek juga dilakukan pada tahap perencanaan. Hasil dari studi kelayakan teknis adalah untuk menentukan berbagai pendekatan teknis yang dapat diikuti untuk melaksanakan proyek dengan sukses dengan risiko minimum.

Tahap 2: Menentukan Persyaratan

Setelah analisis persyaratan dilakukan, langkah selanjutnya adalah dengan jelas mendefinisikan dan mendokumentasikan persyaratan produk dan mendapatkan persetujuan dari pelanggan atau analis pasar. Ini dilakukan melaluiSRS (Software Requirement Specification) dokumen yang terdiri dari semua persyaratan produk yang akan dirancang dan dikembangkan selama siklus hidup proyek.

Tahap 3: Mendesain Arsitektur Produk

SRS menjadi acuan bagi arsitek produk untuk menghasilkan arsitektur terbaik bagi produk yang akan dikembangkan. Berdasarkan persyaratan yang ditentukan dalam SRS, biasanya lebih dari satu pendekatan desain untuk arsitektur produk diusulkan dan didokumentasikan dalam DDS - Spesifikasi Dokumen Desain.

DDS ini ditinjau oleh semua pemangku kepentingan penting dan berdasarkan berbagai parameter seperti penilaian risiko, ketahanan produk, modularitas desain, batasan anggaran dan waktu, pendekatan desain terbaik dipilih untuk produk.

Pendekatan desain dengan jelas mendefinisikan semua modul arsitektur produk bersama dengan komunikasi dan representasi aliran datanya dengan modul eksternal dan pihak ketiga (jika ada). Desain internal dari semua modul dari arsitektur yang diusulkan harus didefinisikan secara jelas dengan detail terkecil di DDS.

Tahap 4: Membangun atau Mengembangkan Produk

Dalam tahap SDLC ini pengembangan yang sebenarnya dimulai dan produk dibangun. Kode pemrograman dibuat sesuai DDS selama tahap ini. Jika desain dilakukan secara rinci dan teratur, pembuatan kode dapat dilakukan tanpa banyak kerumitan.

Pengembang harus mengikuti pedoman pengkodean yang ditentukan oleh organisasi mereka dan alat pemrograman seperti kompiler, juru bahasa, debugger, dll. Digunakan untuk menghasilkan kode. Bahasa pemrograman tingkat tinggi yang berbeda seperti C, C ++, Pascal, Java dan PHP digunakan untuk pengkodean. Bahasa pemrograman dipilih sehubungan dengan jenis perangkat lunak yang dikembangkan.

Tahap 5: Menguji Produk

Tahapan ini biasanya merupakan bagian dari semua tahapan seperti dalam model SDLC modern, aktivitas pengujian sebagian besar terlibat dalam semua tahapan SDLC. Namun, tahap ini mengacu pada tahap pengujian saja dari produk di mana cacat produk dilaporkan, dilacak, diperbaiki dan diuji ulang, hingga produk mencapai standar kualitas yang ditentukan dalam SRS.

Tahap 6: Penyebaran di Pasar dan Pemeliharaan

Setelah produk diuji dan siap digunakan, produk itu dirilis secara resmi di pasar yang sesuai. Terkadang penyebaran produk terjadi secara bertahap sesuai dengan strategi bisnis organisasi itu. Produk mungkin pertama kali dirilis dalam segmen terbatas dan diuji di lingkungan bisnis nyata (UAT- Pengujian penerimaan pengguna).

Kemudian berdasarkan umpan balik tersebut, produk dapat dirilis apa adanya atau dengan peningkatan yang disarankan di segmen pasar sasaran. Setelah produk dirilis di pasar, pemeliharaannya dilakukan untuk basis pelanggan yang ada.

Model SDLC

Ada berbagai model siklus hidup pengembangan perangkat lunak yang ditentukan dan dirancang yang diikuti selama proses pengembangan perangkat lunak. Model ini juga disebut sebagai Model Proses Pengembangan Perangkat Lunak ". Setiap model proses mengikuti serangkaian langkah unik untuk jenisnya untuk memastikan keberhasilan dalam proses pengembangan perangkat lunak.

Berikut adalah model SDLC paling penting dan populer yang diikuti di industri -

Model Air Terjun
Model Iteratif
Model Spiral
V-Model
Model Big Bang

Metodologi terkait lainnya adalah Model Agile, Model RAD, Pengembangan Aplikasi Cepat dan Model Prototyping.

Model Air Terjun adalah Model Proses pertama yang diperkenalkan. Ini juga disebut sebagai alinear-sequential life cycle model. Ini sangat sederhana untuk dipahami dan digunakan. Dalam model air terjun, setiap fase harus diselesaikan sebelum fase berikutnya dapat dimulai dan tidak ada fase yang tumpang tindih.

Model Waterfall adalah pendekatan SDLC paling awal yang digunakan untuk pengembangan perangkat lunak.

Model air terjun menggambarkan proses pengembangan perangkat lunak dalam aliran sekuensial linier. Ini berarti bahwa setiap fase dalam proses pengembangan dimulai hanya jika fase sebelumnya telah selesai. Dalam model air terjun ini, tahapan tidak tumpang tindih.

Model Air Terjun - Desain

Pendekatan air terjun adalah Model SDLC pertama yang digunakan secara luas dalam Rekayasa Perangkat Lunak untuk memastikan keberhasilan proyek. Dalam pendekatan "Air Terjun", seluruh proses pengembangan perangkat lunak dibagi menjadi beberapa tahap terpisah. Dalam model Waterfall ini, biasanya, hasil dari satu fase bertindak sebagai masukan untuk fase berikutnya secara berurutan.

Ilustrasi berikut adalah representasi dari tahapan yang berbeda dari Model Waterfall.

Fase sekuensial dalam model Waterfall adalah -

Requirement Gathering and analysis - Semua kemungkinan persyaratan sistem yang akan dikembangkan ditangkap dalam fase ini dan didokumentasikan dalam dokumen spesifikasi persyaratan.
System Design- Spesifikasi kebutuhan dari tahap pertama dipelajari dalam tahap ini dan desain sistem disiapkan. Desain sistem ini membantu dalam menentukan perangkat keras dan persyaratan sistem dan membantu dalam mendefinisikan arsitektur sistem secara keseluruhan.
Implementation- Dengan masukan dari desain sistem, sistem pertama kali dikembangkan dalam program kecil yang disebut unit, yang diintegrasikan pada tahap berikutnya. Setiap unit dikembangkan dan diuji fungsinya, yang disebut Pengujian Unit.
Integration and Testing- Semua unit yang dikembangkan pada tahap implementasi diintegrasikan ke dalam sistem setelah pengujian setiap unit. Integrasi pasca, seluruh sistem diuji untuk setiap kesalahan dan kegagalan.
Deployment of system- Setelah pengujian fungsional dan non-fungsional selesai; produk disebarkan di lingkungan pelanggan atau dilepas ke pasar.
Maintenance- Ada beberapa masalah yang muncul di lingkungan klien. Untuk memperbaiki masalah tersebut, patch dirilis. Juga untuk meningkatkan produk beberapa versi yang lebih baik dirilis. Pemeliharaan dilakukan untuk menyampaikan perubahan ini di lingkungan pelanggan.

Semua fase ini mengalir satu sama lain di mana kemajuan terlihat mengalir dengan mantap ke bawah (seperti air terjun) melalui fase-fase tersebut. Fase berikutnya dimulai hanya setelah serangkaian tujuan yang ditentukan tercapai untuk fase sebelumnya dan itu ditandatangani, jadi nama "Model Air Terjun". Dalam model ini, fase tidak tumpang tindih.

Model Air Terjun - Aplikasi

Setiap perangkat lunak yang dikembangkan berbeda dan membutuhkan pendekatan SDLC yang sesuai untuk diikuti berdasarkan faktor internal dan eksternal. Beberapa situasi di mana penggunaan model Waterfall paling tepat adalah -

Persyaratan didokumentasikan dengan sangat baik, jelas dan tetap.
Definisi produk stabil.
Teknologi dipahami dan tidak dinamis.
Tidak ada persyaratan yang ambigu.
Sumber daya yang cukup dengan keahlian yang dibutuhkan tersedia untuk mendukung produk.
Proyeknya singkat.

Model Air Terjun - Keuntungan

Keuntungan dari pengembangan air terjun adalah memungkinkan adanya departementalisasi dan kontrol. Jadwal dapat diatur dengan tenggat waktu untuk setiap tahap pengembangan dan produk dapat dilanjutkan melalui tahap model proses pengembangan satu per satu.

Pengembangan bergerak dari konsep, melalui desain, implementasi, pengujian, instalasi, pemecahan masalah, dan berakhir pada pengoperasian dan pemeliharaan. Setiap fase perkembangan berlangsung dalam urutan yang ketat.

Beberapa keunggulan utama Model Air Terjun adalah sebagai berikut -

Sederhana dan mudah dimengerti dan digunakan
Mudah dikelola karena modelnya yang kaku. Setiap fase memiliki kiriman khusus dan proses peninjauan.
Tahapan diproses dan diselesaikan satu per satu.
Bekerja dengan baik untuk proyek yang lebih kecil di mana persyaratannya dipahami dengan sangat baik.
Tahapan yang didefinisikan dengan jelas.
Tonggak yang dipahami dengan baik.
Mudah untuk mengatur tugas.
Proses dan hasil didokumentasikan dengan baik.

Model Air Terjun - Kekurangan

Kerugian pembangunan air terjun adalah tidak memungkinkan banyak refleksi atau revisi. Setelah aplikasi berada dalam tahap pengujian, sangat sulit untuk kembali dan mengubah sesuatu yang tidak didokumentasikan atau dipikirkan dengan baik dalam tahap konsep.

Kerugian utama dari Model Air Terjun adalah sebagai berikut -

Tidak ada perangkat lunak yang berfungsi diproduksi hingga akhir selama siklus hidup.
Resiko dan ketidakpastian yang tinggi.
Bukan model yang baik untuk proyek yang kompleks dan berorientasi objek.
Model yang buruk untuk proyek yang panjang dan berkelanjutan.
Tidak cocok untuk proyek yang persyaratannya berisiko tinggi untuk berubah. Jadi, risiko dan ketidakpastian tinggi dengan model proses ini.
Sulit untuk mengukur kemajuan dalam beberapa tahap.
Tidak dapat mengakomodasi persyaratan yang berubah.
Menyesuaikan ruang lingkup selama siklus hidup dapat mengakhiri proyek.
Integrasi dilakukan sebagai "ledakan besar. Di bagian paling akhir, yang tidak memungkinkan untuk mengidentifikasi hambatan atau tantangan teknologi atau bisnis apa pun secara dini.

Dalam model Iteratif, proses iteratif dimulai dengan implementasi sederhana dari sekumpulan kecil persyaratan perangkat lunak dan secara berulang meningkatkan versi yang berkembang hingga sistem lengkap diimplementasikan dan siap untuk digunakan.

Model siklus hidup berulang tidak mencoba untuk memulai dengan spesifikasi persyaratan yang lengkap. Sebaliknya, pengembangan dimulai dengan menentukan dan menerapkan hanya sebagian dari perangkat lunak, yang kemudian ditinjau untuk mengidentifikasi persyaratan lebih lanjut. Proses ini kemudian diulangi, menghasilkan versi baru perangkat lunak di akhir setiap iterasi model.

Model Iteratif - Desain

Proses berulang dimulai dengan implementasi sederhana dari subset dari persyaratan perangkat lunak dan secara berulang meningkatkan versi yang berkembang sampai sistem penuh diimplementasikan. Pada setiap iterasi, modifikasi desain dibuat dan kemampuan fungsional baru ditambahkan. Ide dasar di balik metode ini adalah mengembangkan sistem melalui siklus berulang (berulang) dan dalam porsi yang lebih kecil pada satu waktu (inkremental).

Ilustrasi berikut adalah representasi dari model Iterative dan Incremental -

Pengembangan Iteratif dan Inkremental adalah kombinasi dari desain iteratif atau metode iteratif dan model build inkremental untuk pengembangan. "Selama pengembangan perangkat lunak, lebih dari satu iterasi siklus pengembangan perangkat lunak mungkin sedang berlangsung pada waktu yang sama." Proses ini dapat digambarkan sebagai pendekatan "akuisisi evolusioner" atau "pembangunan bertahap".

Dalam model inkremental ini, seluruh persyaratan dibagi menjadi berbagai build. Selama setiap iterasi, modul pengembangan melewati fase persyaratan, desain, implementasi, dan pengujian. Setiap rilis modul berikutnya menambahkan fungsi ke rilis sebelumnya. Proses berlanjut sampai sistem lengkap siap sesuai kebutuhan.

Kunci keberhasilan penggunaan siklus pengembangan perangkat lunak yang berulang adalah validasi persyaratan yang ketat, dan verifikasi & pengujian setiap versi perangkat lunak terhadap persyaratan tersebut dalam setiap siklus model. Karena perangkat lunak berkembang melalui siklus yang berurutan, pengujian harus diulang dan diperpanjang untuk memverifikasi setiap versi perangkat lunak.

Model Iteratif - Aplikasi

Seperti model SDLC lainnya, pengembangan berulang dan inkremental memiliki beberapa aplikasi khusus dalam industri perangkat lunak. Model ini paling sering digunakan dalam skenario berikut -

Persyaratan sistem lengkap didefinisikan dan dipahami dengan jelas.
Persyaratan utama harus ditentukan; namun, beberapa fungsi atau peningkatan yang diminta dapat berkembang seiring waktu.
Ada waktu untuk kendala pasar.
Teknologi baru sedang digunakan dan dipelajari oleh tim pengembangan saat mengerjakan proyek.
Sumber daya dengan keahlian yang dibutuhkan tidak tersedia dan direncanakan untuk digunakan berdasarkan kontrak untuk iterasi tertentu.
Ada beberapa fitur dan sasaran berisiko tinggi yang dapat berubah di masa depan.

Model Iteratif - Pro dan Kontra

Keuntungan dari model ini adalah adanya model kerja sistem pada tahap paling awal pengembangan, yang memudahkan untuk menemukan kekurangan fungsional atau desain. Menemukan masalah pada tahap awal pengembangan memungkinkan untuk mengambil tindakan korektif dalam anggaran yang terbatas.

Kerugian dengan model SDLC ini adalah bahwa model ini hanya berlaku untuk proyek pengembangan perangkat lunak yang besar dan besar. Ini karena sulit untuk memecah sistem perangkat lunak kecil menjadi tambahan / modul kecil yang dapat diservis.

Keuntungan dari Model SDLC Iteratif dan Inkremental adalah sebagai berikut -

Beberapa fungsi kerja dapat dikembangkan dengan cepat dan di awal siklus hidup.
Hasil diperoleh secara dini dan berkala.
Pengembangan paralel dapat direncanakan.
Kemajuan bisa diukur.
Lebih murah untuk mengubah ruang lingkup / persyaratan.
Menguji dan men-debug selama iterasi yang lebih kecil itu mudah.
Risiko diidentifikasi dan diselesaikan selama iterasi; dan setiap iterasi merupakan pencapaian yang mudah dikelola.
Lebih mudah mengelola risiko - Bagian berisiko tinggi dilakukan terlebih dahulu.
Dengan setiap kenaikan, produk operasional dikirim.
Masalah, tantangan, dan risiko yang diidentifikasi dari setiap kenaikan dapat dimanfaatkan / diterapkan untuk kenaikan berikutnya.
Analisis risiko lebih baik.
Ini mendukung persyaratan yang berubah.
Waktu Pengoperasian Awal lebih singkat.
Lebih cocok untuk proyek besar dan penting.
Selama siklus hidup, perangkat lunak diproduksi lebih awal yang memfasilitasi evaluasi dan umpan balik pelanggan.

Kerugian dari Model SDLC Iteratif dan Inkremental adalah sebagai berikut -

Lebih banyak sumber daya mungkin diperlukan.
Meskipun biaya perubahan lebih rendah, tetapi itu tidak terlalu cocok untuk mengubah persyaratan.
Diperlukan lebih banyak perhatian manajemen.
Masalah arsitektur atau desain sistem dapat muncul karena tidak semua persyaratan dikumpulkan di awal seluruh siklus hidup.
Menentukan kenaikan mungkin memerlukan definisi sistem lengkap.
Tidak cocok untuk proyek kecil.
Kompleksitas manajemen lebih.
Akhir proyek mungkin tidak diketahui yang merupakan risiko.
Sumber daya yang sangat terampil diperlukan untuk analisis risiko.
Kemajuan proyek sangat tergantung pada tahap analisis risiko.

Model spiral menggabungkan gagasan pengembangan berulang dengan aspek sistematis dan terkontrol dari model air terjun. Model Spiral ini merupakan kombinasi dari model proses pengembangan iteratif dan model pengembangan linier sekuensial yaitu model waterfall dengan penekanan yang sangat tinggi pada analisis risiko. Hal ini memungkinkan pelepasan produk secara bertahap atau perbaikan tambahan melalui setiap iterasi di sekitar spiral.

Model Spiral - Desain

Model spiral memiliki empat fase. Sebuah proyek perangkat lunak berulang kali melewati fase-fase ini dalam iterasi yang disebut Spiral.

Identifikasi

Fase ini dimulai dengan mengumpulkan persyaratan bisnis dalam spiral baseline. Pada spiral berikutnya saat produk matang, identifikasi persyaratan sistem, persyaratan subsistem, dan persyaratan unit semuanya dilakukan dalam fase ini.

Fase ini juga termasuk memahami persyaratan sistem dengan komunikasi terus menerus antara pelanggan dan analis sistem. Di ujung spiral, produk digunakan di pasar yang teridentifikasi.

Rancangan

Fase Desain dimulai dengan desain konseptual pada spiral dasar dan melibatkan desain arsitektur, desain logis modul, desain produk fisik, dan desain akhir pada spiral berikutnya.

Bangun atau Bangun

Fase Construct mengacu pada produksi produk perangkat lunak aktual di setiap spiral. Dalam spiral dasar, ketika produk baru saja dipikirkan dan desain sedang dikembangkan, POC (Bukti Konsep) dikembangkan dalam fase ini untuk mendapatkan umpan balik pelanggan.

Kemudian pada spiral berikutnya dengan kejelasan yang lebih tinggi tentang persyaratan dan detail desain, model kerja perangkat lunak yang disebut build diproduksi dengan nomor versi. Bangunan ini dikirim ke pelanggan untuk mendapatkan umpan balik.

Evaluasi dan Analisis Risiko

Analisis Risiko termasuk mengidentifikasi, memperkirakan dan memantau kelayakan teknis dan risiko manajemen, seperti selip jadwal dan kelebihan biaya. Setelah menguji build, pada akhir iterasi pertama, pelanggan mengevaluasi perangkat lunak dan memberikan umpan balik.

Ilustrasi berikut adalah representasi dari Model Spiral, daftar kegiatan di setiap fase.

Berdasarkan evaluasi pelanggan, proses pengembangan perangkat lunak memasuki iterasi berikutnya dan selanjutnya mengikuti pendekatan linier untuk mengimplementasikan umpan balik yang disarankan oleh pelanggan. Proses iterasi sepanjang spiral terus berlanjut selama masa pakai perangkat lunak.

Aplikasi Model Spiral

Model Spiral banyak digunakan dalam industri perangkat lunak karena sinkron dengan proses pengembangan alami dari produk apa pun, yaitu pembelajaran dengan kematangan yang melibatkan risiko minimum bagi pelanggan serta perusahaan pengembangan.

Petunjuk berikut menjelaskan penggunaan tipikal Model Spiral -

Jika ada kendala anggaran dan evaluasi risiko menjadi penting.
Untuk proyek berisiko menengah hingga tinggi.
Komitmen proyek jangka panjang karena potensi perubahan pada prioritas ekonomi karena persyaratan berubah seiring waktu.
Pelanggan tidak yakin dengan persyaratan mereka yang biasanya terjadi.
Persyaratannya kompleks dan perlu evaluasi untuk mendapatkan kejelasan.
Lini produk baru yang harus dirilis secara bertahap untuk mendapatkan umpan balik pelanggan yang cukup.
Perubahan signifikan diharapkan pada produk selama siklus pengembangan.

Model Spiral - Pro dan Kontra

Keuntungan dari model siklus hidup spiral adalah memungkinkan elemen produk ditambahkan, saat mereka tersedia atau diketahui. Ini memastikan bahwa tidak ada konflik dengan persyaratan dan desain sebelumnya.

Metode ini konsisten dengan pendekatan yang memiliki beberapa build dan rilis perangkat lunak yang memungkinkan melakukan transisi yang teratur ke aktivitas pemeliharaan. Aspek positif lain dari metode ini adalah bahwa model spiral memaksa keterlibatan pengguna awal dalam upaya pengembangan sistem.

Di sisi lain, dibutuhkan manajemen yang sangat ketat untuk menyelesaikan produk semacam itu dan ada risiko menjalankan spiral dalam putaran tak terbatas. Jadi, disiplin perubahan dan tingkat pengambilan permintaan perubahan sangat penting untuk mengembangkan dan menerapkan produk dengan sukses.

Kelebihan Model Spiral SDLC adalah sebagai berikut -

Persyaratan yang berubah dapat diakomodasi.
Memungkinkan penggunaan prototipe secara ekstensif.
Persyaratan bisa ditangkap dengan lebih akurat.
Pengguna melihat sistem lebih awal.
Pengembangan dapat dibagi menjadi bagian-bagian yang lebih kecil dan bagian yang berisiko dapat dikembangkan lebih awal yang membantu dalam manajemen risiko yang lebih baik.

Kerugian dari Spiral SDLC Model adalah sebagai berikut -

Manajemen lebih kompleks.
Akhir proyek mungkin tidak diketahui lebih awal.
Tidak cocok untuk proyek kecil atau berisiko rendah dan bisa mahal untuk proyek kecil.
Proses itu rumit
Spiral mungkin terus berlanjut tanpa batas.
Sejumlah besar tahap menengah membutuhkan dokumentasi yang berlebihan.

Model V adalah model SDLC di mana eksekusi proses terjadi secara berurutan dalam bentuk V. Itu juga dikenal sebagaiVerification and Validation model.

Model-V adalah perpanjangan dari model air terjun dan didasarkan pada asosiasi fase pengujian untuk setiap tahap pengembangan yang sesuai. Ini berarti bahwa untuk setiap fase dalam siklus pengembangan, ada fase pengujian yang terkait langsung. Ini adalah model yang sangat disiplin dan fase berikutnya dimulai hanya setelah menyelesaikan fase sebelumnya.

V-Model - Desain

Di bawah V-Model, fase pengujian yang sesuai dari fase pengembangan direncanakan secara paralel. Jadi, ada fase Verifikasi di satu sisi dari fase 'V' dan fase Validasi di sisi lain. Fase Coding menggabungkan dua sisi Model-V.

Ilustrasi berikut menggambarkan fase yang berbeda dalam Model-V SDLC.

V-Model - Tahapan Verifikasi

Ada beberapa tahapan Verifikasi dalam Model-V, masing-masing dijelaskan secara rinci di bawah ini.

Analisis Kebutuhan Bisnis

Ini adalah fase pertama dalam siklus pengembangan di mana persyaratan produk dipahami dari perspektif pelanggan. Fase ini melibatkan komunikasi terperinci dengan pelanggan untuk memahami ekspektasi dan kebutuhan tepatnya. Ini adalah aktivitas yang sangat penting dan perlu dikelola dengan baik, karena sebagian besar pelanggan tidak yakin tentang apa yang sebenarnya mereka butuhkan. Ituacceptance test design planning dilakukan pada tahap ini karena kebutuhan bisnis dapat digunakan sebagai masukan untuk pengujian penerimaan.

Desain sistem

Setelah Anda memiliki persyaratan produk yang jelas dan terperinci, sekarang saatnya merancang sistem yang lengkap. Desain sistem akan memiliki pemahaman dan perincian perangkat keras lengkap dan pengaturan komunikasi untuk produk yang sedang dikembangkan. Rencana pengujian sistem dikembangkan berdasarkan desain sistem. Melakukan ini pada tahap sebelumnya menyisakan lebih banyak waktu untuk eksekusi tes yang sebenarnya nanti.

Desain arsitektur

Spesifikasi arsitektur dipahami dan dirancang dalam fase ini. Biasanya lebih dari satu pendekatan teknis diusulkan dan berdasarkan kelayakan teknis dan finansial keputusan akhir diambil. Desain sistem dipecah lebih jauh menjadi modul-modul yang menggunakan berbagai fungsi. Ini juga disebut sebagaiHigh Level Design (HLD).

Transfer data dan komunikasi antara modul internal dan dengan dunia luar (sistem lain) dipahami dan didefinisikan dengan jelas dalam tahap ini. Dengan informasi ini, pengujian integrasi dapat dirancang dan didokumentasikan selama tahap ini.

Desain Modul

Dalam fase ini, desain internal terperinci untuk semua modul sistem ditentukan, disebut sebagai Low Level Design (LLD). Penting agar desainnya kompatibel dengan modul lain dalam arsitektur sistem dan sistem eksternal lainnya. Tes unit adalah bagian penting dari setiap proses pengembangan dan membantu menghilangkan kesalahan dan kesalahan maksimum pada tahap yang sangat awal. Tes unit ini dapat dirancang pada tahap ini berdasarkan desain modul internal.

Fase Pengkodean

Pengkodean sebenarnya dari modul sistem yang dirancang dalam fase desain diambil dalam fase Pengodean. Bahasa pemrograman yang paling cocok ditentukan berdasarkan persyaratan sistem dan arsitektur.

Pengkodean dilakukan berdasarkan pedoman dan standar pengkodean. Kode melewati banyak tinjauan kode dan dioptimalkan untuk kinerja terbaik sebelum build akhir diperiksa ke dalam repositori.

Tahapan Validasi

Fase Validasi yang berbeda dalam Model-V dijelaskan secara rinci di bawah ini.

Pengujian Unit

Pengujian unit yang dirancang dalam fase desain modul dijalankan pada kode selama fase validasi ini. Pengujian unit adalah pengujian pada tingkat kode dan membantu menghilangkan bug pada tahap awal, meskipun semua kerusakan tidak dapat ditemukan dengan pengujian unit.

Tes integrasi

Pengujian integrasi dikaitkan dengan fase desain arsitektur. Tes integrasi dilakukan untuk menguji koeksistensi dan komunikasi modul internal di dalam sistem.

Pengujian Sistem

Pengujian sistem secara langsung dikaitkan dengan fase desain sistem. Pengujian sistem memeriksa keseluruhan fungsionalitas sistem dan komunikasi sistem yang sedang dikembangkan dengan sistem eksternal. Sebagian besar masalah kompatibilitas perangkat lunak dan perangkat keras dapat ditemukan selama pelaksanaan pengujian sistem ini.

Ujian penerimaan

Pengujian penerimaan dikaitkan dengan fase analisis kebutuhan bisnis dan melibatkan pengujian produk di lingkungan pengguna. Tes penerimaan mengungkap masalah kompatibilitas dengan sistem lain yang tersedia di lingkungan pengguna. Ini juga menemukan masalah non-fungsional seperti cacat beban dan kinerja di lingkungan pengguna yang sebenarnya.

V- Model ─ Aplikasi

Aplikasi model V hampir sama dengan model air terjun, karena kedua model tersebut memiliki tipe sekuensial. Persyaratan harus sangat jelas sebelum proyek dimulai, karena biasanya mahal untuk kembali dan membuat perubahan. Model ini digunakan dalam bidang pengembangan medis, karena merupakan domain yang sangat disiplin.

Petunjuk berikut adalah beberapa skenario yang paling cocok untuk menggunakan aplikasi V-Model.

Persyaratan didefinisikan dengan baik, didokumentasikan dengan jelas, dan diperbaiki.
Definisi produk stabil.
Teknologi tidak dinamis dan dipahami dengan baik oleh tim proyek.
Tidak ada persyaratan yang ambigu atau tidak ditentukan.
Proyeknya singkat.

V-Model - Pro dan Kontra

Keunggulan metode V-Model adalah sangat mudah dipahami dan diterapkan. Kesederhanaan model ini juga memudahkan pengelolaan. Kerugiannya adalah modelnya tidak fleksibel terhadap perubahan dan kalau-kalau ada perubahan persyaratan, yang sangat umum dalam dunia dinamis saat ini, menjadi sangat mahal untuk melakukan perubahan.

Kelebihan metode V-Model adalah sebagai berikut -

Ini adalah model yang sangat disiplin dan Tahapan diselesaikan satu per satu.
Bekerja dengan baik untuk proyek yang lebih kecil di mana persyaratannya dipahami dengan sangat baik.
Sederhana dan mudah dimengerti dan digunakan.
Mudah dikelola karena modelnya yang kaku. Setiap fase memiliki kiriman khusus dan proses peninjauan.

Kerugian dari metode V-Model adalah sebagai berikut -

Resiko tinggi dan ketidakpastian.
Bukan model yang baik untuk proyek yang kompleks dan berorientasi objek.
Model yang buruk untuk proyek yang panjang dan berkelanjutan.
Tidak cocok untuk proyek yang persyaratannya berisiko tinggi untuk berubah.
Setelah aplikasi berada dalam tahap pengujian, sulit untuk kembali dan mengubah fungsionalitas.
Tidak ada perangkat lunak yang berfungsi diproduksi hingga akhir selama siklus hidup.

Model Big Bang adalah model SDLC di mana kami tidak mengikuti proses tertentu. Pengembangan hanya dimulai dengan uang dan upaya yang diperlukan sebagai input, dan outputnya adalah perangkat lunak yang dikembangkan yang mungkin atau mungkin tidak sesuai dengan kebutuhan pelanggan. Model Big Bang ini tidak mengikuti proses / prosedur dan hanya membutuhkan sedikit perencanaan. Bahkan pelanggan tidak yakin tentang apa yang sebenarnya dia inginkan dan persyaratan diterapkan dengan cepat tanpa banyak analisis.

Biasanya model ini diikuti untuk proyek kecil di mana tim pengembangannya sangat kecil.

Model Big Bang ─ Desain dan Aplikasi

Model Big Bang terdiri dari pemfokusan semua sumber daya yang mungkin dalam pengembangan perangkat lunak dan pengkodean, dengan sangat sedikit atau tanpa perencanaan. Persyaratan dipahami dan diterapkan saat mereka datang. Setiap perubahan yang diperlukan mungkin atau mungkin tidak perlu mengubah perangkat lunak lengkap.

Model ini sangat ideal untuk proyek kecil dengan satu atau dua pengembang bekerja sama dan juga berguna untuk proyek akademis atau praktik. Ini adalah model ideal untuk produk di mana persyaratan tidak dipahami dengan baik dan tanggal rilis final tidak diberikan.

Big Bang Model - Pro dan Kontra

Keuntungan dari Model Big Bang ini adalah sangat sederhana dan membutuhkan sangat sedikit atau tanpa perencanaan. Mudah dikelola dan tidak diperlukan prosedur formal.

Namun, Model Big Bang adalah model berisiko sangat tinggi dan perubahan dalam persyaratan atau persyaratan yang disalahpahami bahkan dapat menyebabkan pembalikan total atau pengikisan proyek. Ini sangat ideal untuk proyek berulang atau kecil dengan risiko minimum.

Keunggulan Model Big Bang adalah sebagai berikut -

Ini adalah model yang sangat sederhana
Sedikit atau tidak ada perencanaan yang dibutuhkan
Mudah dikelola
Sangat sedikit sumber daya yang dibutuhkan
Memberikan fleksibilitas kepada pengembang
Ini adalah alat bantu belajar yang baik untuk pendatang atau siswa baru.

Kerugian dari Model Big Bang adalah sebagai berikut -

Resiko dan ketidakpastian yang sangat tinggi.
Bukan model yang baik untuk proyek yang kompleks dan berorientasi objek.
Model yang buruk untuk proyek yang panjang dan berkelanjutan.
Bisa menjadi sangat mahal jika persyaratannya disalahpahami.

Model Agile SDLC adalah kombinasi dari model proses iteratif dan inkremental dengan fokus pada adaptasi proses dan kepuasan pelanggan dengan pengiriman cepat produk perangkat lunak yang berfungsi. Agile Methods memecah produk menjadi beberapa build tambahan kecil. Build ini disediakan dalam iterasi. Setiap iterasi biasanya berlangsung dari sekitar satu hingga tiga minggu. Setiap iterasi melibatkan tim lintas fungsi yang bekerja secara bersamaan di berbagai area seperti -

Planning
Analisa Kebutuhan
Design
Coding
Pengujian Unit dan
Ujian penerimaan.

Di akhir iterasi, produk yang berfungsi ditampilkan kepada pelanggan dan pemangku kepentingan penting.

Apa itu Agile?

Model Agile percaya bahwa setiap proyek perlu ditangani secara berbeda dan metode yang ada perlu disesuaikan agar paling sesuai dengan persyaratan proyek. Di Agile, tugas dibagi ke kotak waktu (kerangka waktu kecil) untuk memberikan fitur spesifik untuk rilis.

Pendekatan berulang diambil dan pembuatan perangkat lunak yang berfungsi dikirimkan setelah setiap iterasi. Setiap build bersifat inkremental dalam hal fitur; build terakhir menampung semua fitur yang dibutuhkan oleh pelanggan.

Berikut adalah ilustrasi grafis dari Model Agile -

Proses pemikiran Agile telah dimulai pada awal pengembangan perangkat lunak dan mulai menjadi populer seiring waktu karena fleksibilitas dan adaptasinya.

Metode Agile yang paling populer termasuk Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, dan Dynamic Systems Development Method (DSDM) (1995). Ini sekarang secara kolektif disebut sebagaiAgile Methodologies, setelah Agile Manifesto diterbitkan pada tahun 2001.

Berikut adalah prinsip-prinsip Agile Manifesto -

Individuals and interactions - Dalam pengembangan Agile, pengorganisasian diri dan motivasi itu penting, begitu juga interaksi seperti pemrograman bersama dan berpasangan.
Working software - Perangkat lunak yang berfungsi demo dianggap sebagai sarana komunikasi terbaik dengan pelanggan untuk memahami kebutuhan mereka, bukan hanya bergantung pada dokumentasi.
Customer collaboration - Karena persyaratan tidak dapat dikumpulkan sepenuhnya di awal proyek karena berbagai faktor, interaksi pelanggan yang berkelanjutan sangat penting untuk mendapatkan persyaratan produk yang tepat.
Responding to change - Pengembangan Agile difokuskan pada respons cepat terhadap perubahan dan pengembangan berkelanjutan.

Model SDLC Agile Vs Tradisional

Agile didasarkan pada adaptive software development methods, sedangkan model SDLC tradisional seperti model air terjun didasarkan pada pendekatan prediktif. Tim prediktif dalam model SDLC tradisional biasanya bekerja dengan perencanaan terperinci dan memiliki perkiraan lengkap tentang tugas dan fitur yang akan dikirimkan dalam beberapa bulan ke depan atau selama siklus hidup produk.

Metode prediksi sepenuhnya bergantung pada requirement analysis and planningdilakukan pada awal siklus. Setiap perubahan yang akan dimasukkan melalui manajemen dan prioritas kontrol perubahan yang ketat.

Agile menggunakan adaptive approachdi mana tidak ada perencanaan rinci dan ada kejelasan tentang tugas-tugas masa depan hanya dalam hal fitur apa yang perlu dikembangkan. Ada pengembangan yang didorong fitur dan tim menyesuaikan dengan persyaratan produk yang berubah secara dinamis. Produk ini sangat sering diuji, melalui iterasi rilis, meminimalkan risiko kegagalan besar di masa mendatang.

Customer Interactionadalah tulang punggung metodologi Agile ini, dan komunikasi terbuka dengan dokumentasi minimum adalah fitur khas lingkungan pengembangan Agile. Tim tangkas bekerja sama erat satu sama lain dan paling sering berada di lokasi geografis yang sama.

Agile Model - Pro dan Kontra

Metode tangkas diterima secara luas di dunia perangkat lunak baru-baru ini. Namun, metode ini mungkin tidak selalu cocok untuk semua produk. Berikut beberapa pro dan kontra dari model Agile.

Keunggulan Model Agile adalah sebagai berikut -

Merupakan pendekatan yang sangat realistis untuk pengembangan perangkat lunak.
Mempromosikan kerja tim dan pelatihan silang.
Fungsionalitas dapat dikembangkan dan ditunjukkan dengan cepat.
Persyaratan sumber daya minimal.
Cocok untuk persyaratan tetap atau berubah
Memberikan solusi kerja parsial awal.
Model yang baik untuk lingkungan yang terus berubah.
Aturan minimal, dokumentasi mudah digunakan.
Memungkinkan pengembangan dan pengiriman bersamaan dalam konteks yang direncanakan secara keseluruhan.
Sedikit atau tidak ada perencanaan yang dibutuhkan.
Mudah dikelola.
Memberikan fleksibilitas kepada pengembang.

Kekurangan Model Agile adalah sebagai berikut -

Tidak cocok untuk menangani dependensi yang kompleks.
Lebih banyak risiko keberlanjutan, pemeliharaan, dan perpanjangan.
Rencana keseluruhan, pemimpin yang gesit, dan praktik PM yang gesit adalah suatu keharusan yang tanpanya rencana itu tidak akan berhasil.
Manajemen pengiriman yang ketat menentukan cakupan, fungsionalitas yang akan dikirimkan, dan penyesuaian untuk memenuhi tenggat waktu.
Sangat bergantung pada interaksi pelanggan, jadi jika pelanggan tidak jelas, tim dapat diarahkan ke arah yang salah.
Ada ketergantungan individu yang sangat tinggi, karena dokumentasi minimum yang dihasilkan.
Transfer teknologi ke anggota tim baru mungkin cukup menantang karena kurangnya dokumentasi.

Itu RAD (Rapid Application Development)model didasarkan pada pembuatan prototipe dan pengembangan berulang tanpa melibatkan perencanaan khusus. Proses penulisan perangkat lunak itu sendiri melibatkan perencanaan yang diperlukan untuk mengembangkan produk.

Rapid Application Development berfokus pada pengumpulan kebutuhan pelanggan melalui lokakarya atau grup fokus, pengujian awal prototipe oleh pelanggan menggunakan konsep berulang, penggunaan kembali prototipe (komponen) yang ada, integrasi berkelanjutan dan pengiriman cepat.

Apa itu RAD?

Pengembangan aplikasi cepat adalah metodologi pengembangan perangkat lunak yang menggunakan perencanaan minimal untuk pembuatan prototipe cepat. Prototipe adalah model kerja yang secara fungsional setara dengan komponen produk.

Dalam model RAD, modul fungsional dikembangkan secara paralel sebagai prototipe dan diintegrasikan untuk membuat produk lengkap untuk pengiriman produk lebih cepat. Karena tidak ada perencanaan awal yang mendetail, ini mempermudah untuk memasukkan perubahan dalam proses pengembangan.

Proyek RAD mengikuti model iteratif dan inkremental dan memiliki tim kecil yang terdiri dari pengembang, pakar domain, perwakilan pelanggan, dan sumber daya TI lainnya yang bekerja secara progresif pada komponen atau prototipe mereka.

Aspek terpenting agar model ini berhasil adalah memastikan bahwa prototipe yang dikembangkan dapat digunakan kembali.

Desain Model RAD

Model RAD mendistribusikan fase analisis, desain, pembuatan, dan pengujian ke dalam serangkaian siklus pengembangan yang singkat dan berulang.

Berikut adalah berbagai tahapan Model RAD -

Pemodelan Bisnis

Model bisnis untuk produk yang sedang dikembangkan dirancang dalam kaitannya dengan arus informasi dan distribusi informasi antara berbagai saluran bisnis. Analisis bisnis yang lengkap dilakukan untuk menemukan informasi penting untuk bisnis, bagaimana informasi tersebut dapat diperoleh, bagaimana dan kapan informasi tersebut diproses, dan faktor apa saja yang mendorong aliran informasi yang berhasil.

Pemodelan Data

Informasi yang dikumpulkan dalam fase Pemodelan Bisnis ditinjau dan dianalisis untuk membentuk kumpulan objek data yang penting untuk bisnis. Atribut semua kumpulan data diidentifikasi dan ditentukan. Relasi antara objek data ini ditetapkan dan didefinisikan secara rinci dalam relevansinya dengan model bisnis.

Pemodelan Proses

Kumpulan objek data yang ditentukan dalam fase Pemodelan Data diubah untuk menetapkan aliran informasi bisnis yang diperlukan untuk mencapai tujuan bisnis tertentu sesuai model bisnis. Model proses untuk setiap perubahan atau peningkatan pada kumpulan objek data ditentukan dalam fase ini. Deskripsi proses untuk menambahkan, menghapus, mengambil atau memodifikasi objek data diberikan.

Pembuatan Aplikasi

Sistem aktual dibangun dan pengkodean dilakukan dengan menggunakan alat otomasi untuk mengubah proses dan model data menjadi prototipe aktual.

Pengujian dan Pergantian

Waktu pengujian keseluruhan berkurang dalam model RAD karena prototipe diuji secara independen selama setiap iterasi. Namun, aliran data dan antarmuka antara semua komponen perlu diuji secara menyeluruh dengan cakupan pengujian yang lengkap. Karena sebagian besar komponen pemrograman telah diuji, ini mengurangi risiko masalah besar apa pun.

Ilustrasi berikut menjelaskan Model RAD secara rinci.

Model RAD Vs SDLC Tradisional

SDLC tradisional mengikuti model proses yang kaku dengan penekanan tinggi pada analisis kebutuhan dan pengumpulan sebelum pengkodean dimulai. Ini memberi tekanan pada pelanggan untuk menandatangani persyaratan sebelum proyek dimulai dan pelanggan tidak merasakan produk karena tidak ada bangunan kerja yang tersedia untuk waktu yang lama.

Pelanggan mungkin memerlukan beberapa perubahan setelah dia melihat perangkat lunak tersebut. Namun, proses perubahannya cukup kaku dan mungkin tidak mungkin untuk memasukkan perubahan besar dalam produk ke dalam SDLC tradisional.

Model RAD berfokus pada pengiriman model kerja berulang dan inkremental kepada pelanggan. Hal ini menghasilkan pengiriman yang cepat ke pelanggan dan keterlibatan pelanggan selama siklus pengembangan lengkap produk yang mengurangi risiko ketidaksesuaian dengan persyaratan pengguna yang sebenarnya.

Model RAD - Aplikasi

Model RAD dapat berhasil diterapkan ke proyek yang memungkinkan adanya modularisasi yang jelas. Jika proyek tidak dapat dipecah menjadi modul, RAD mungkin gagal.

Petunjuk berikut menjelaskan skenario umum di mana RAD dapat digunakan -

RAD harus digunakan hanya jika sistem dapat dimodulasi untuk dikirim secara bertahap.
Ini harus digunakan jika ada ketersediaan tinggi desainer untuk Pemodelan.
Ini harus digunakan hanya jika anggaran mengizinkan penggunaan alat penghasil kode otomatis.
Model RAD SDLC harus dipilih hanya jika ahli domain tersedia dengan pengetahuan bisnis yang relevan.
Harus digunakan di mana persyaratan berubah selama proyek dan prototipe kerja akan disajikan kepada pelanggan dalam iterasi kecil 2-3 bulan.

Model RAD - Pro dan Kontra

Model RAD memungkinkan pengiriman cepat karena mengurangi waktu pengembangan secara keseluruhan karena komponen dapat digunakan kembali dan pengembangan paralel. RAD bekerja dengan baik hanya jika tersedia insinyur berketerampilan tinggi dan pelanggan juga berkomitmen untuk mencapai prototipe yang ditargetkan dalam kerangka waktu tertentu. Jika ada komitmen yang kurang di kedua sisi, model tersebut mungkin gagal.

Keuntungan Model RAD adalah sebagai berikut -

Persyaratan yang berubah dapat diakomodasi.
Kemajuan bisa diukur.
Waktu iterasi bisa menjadi singkat dengan menggunakan alat RAD yang kuat.
Produktivitas dengan lebih sedikit orang dalam waktu singkat.
Mengurangi waktu pengembangan.
Meningkatkan kegunaan kembali komponen.
Peninjauan awal yang cepat terjadi.
Mendorong umpan balik pelanggan.
Integrasi sejak awal memecahkan banyak masalah integrasi.

Kerugian dari Model RAD adalah sebagai berikut -

Ketergantungan pada anggota tim yang kuat secara teknis untuk mengidentifikasi persyaratan bisnis.
Hanya sistem yang dapat dimodulasi yang dapat dibangun menggunakan RAD.
Membutuhkan pengembang / desainer yang sangat terampil.
Ketergantungan tinggi pada keterampilan Modeling.
Tidak dapat diterapkan pada proyek yang lebih murah karena biaya Pemodelan dan pembuatan kode otomatis sangat tinggi.
Kompleksitas manajemen lebih.
Cocok untuk sistem yang berbasis komponen dan dapat diskalakan.
Membutuhkan keterlibatan pengguna sepanjang siklus hidup.
Cocok untuk proyek yang membutuhkan waktu pengembangan yang lebih singkat.

Pembuatan Prototipe Perangkat Lunak mengacu pada pembuatan prototipe aplikasi perangkat lunak yang menampilkan fungsionalitas produk yang sedang dikembangkan, tetapi mungkin tidak benar-benar memiliki logika yang tepat dari perangkat lunak asli.

Pembuatan prototipe perangkat lunak menjadi sangat populer sebagai model pengembangan perangkat lunak, karena memungkinkan untuk memahami kebutuhan pelanggan pada tahap awal pengembangan. Ini membantu mendapatkan umpan balik yang berharga dari pelanggan dan membantu perancang dan pengembang perangkat lunak memahami tentang apa sebenarnya yang diharapkan dari produk yang sedang dikembangkan.

Apa itu Prototipe Perangkat Lunak?

Prototipe adalah model kerja perangkat lunak dengan beberapa fungsi terbatas. Prototipe tidak selalu memiliki logika yang tepat yang digunakan dalam aplikasi perangkat lunak yang sebenarnya dan merupakan upaya ekstra untuk dipertimbangkan dalam perkiraan upaya.

Prototipe digunakan untuk memungkinkan pengguna mengevaluasi proposal pengembang dan mencobanya sebelum implementasi. Ini juga membantu memahami persyaratan yang spesifik untuk pengguna dan mungkin belum dipertimbangkan oleh pengembang selama desain produk.

Berikut adalah pendekatan bertahap yang dijelaskan untuk merancang prototipe perangkat lunak.

Identifikasi Persyaratan Dasar

Langkah ini melibatkan pemahaman persyaratan produk yang sangat dasar terutama dalam hal antarmuka pengguna. Detail yang lebih rumit dari desain internal dan aspek eksternal seperti kinerja dan keamanan dapat diabaikan pada tahap ini.

Mengembangkan Prototipe awal

Prototipe awal dikembangkan dalam tahap ini, di mana persyaratan paling dasar dipamerkan dan antarmuka pengguna disediakan. Fitur-fitur ini mungkin tidak bekerja dengan cara yang sama secara internal dalam perangkat lunak sebenarnya yang dikembangkan. Sementara, solusi digunakan untuk memberikan tampilan dan nuansa yang sama kepada pelanggan dalam prototipe yang dikembangkan.

Review dari Prototipe

Prototipe yang dikembangkan kemudian disajikan kepada pelanggan dan pemangku kepentingan penting lainnya dalam proyek tersebut. Umpan balik dikumpulkan secara terorganisir dan digunakan untuk peningkatan lebih lanjut dalam produk yang sedang dikembangkan.

Merevisi dan Meningkatkan Prototipe

Umpan balik dan komentar tinjauan dibahas selama tahap ini dan beberapa negosiasi terjadi dengan pelanggan berdasarkan faktor-faktor seperti - kendala waktu dan anggaran dan kelayakan teknis dari implementasi yang sebenarnya. Perubahan yang diterima sekali lagi dimasukkan dalam Prototipe baru yang dikembangkan dan siklus berulang sampai harapan pelanggan terpenuhi.

Prototipe dapat memiliki dimensi horizontal atau vertikal. Prototipe horizontal menampilkan antarmuka pengguna untuk produk dan memberikan pandangan yang lebih luas tentang keseluruhan sistem, tanpa berkonsentrasi pada fungsi internal. Prototipe Vertikal di sisi lain adalah penjabaran rinci dari fungsi tertentu atau sub sistem dalam produk.

Tujuan dari prototipe horizontal dan vertikal berbeda. Prototipe horizontal digunakan untuk mendapatkan lebih banyak informasi tentang tingkat antarmuka pengguna dan persyaratan bisnis. Bahkan dapat disajikan dalam demo penjualan untuk mendapatkan bisnis di pasar. Prototipe vertikal bersifat teknis dan digunakan untuk mendapatkan rincian fungsi yang tepat dari sub sistem. Misalnya, persyaratan database, interaksi dan pemrosesan data dimuat dalam sub sistem tertentu.

Pembuatan Prototipe Perangkat Lunak - Jenis

Ada berbagai jenis prototipe perangkat lunak yang digunakan dalam industri. Berikut adalah jenis prototipe perangkat lunak utama yang digunakan secara luas -

Throwaway / Rapid Prototyping

Pembuatan prototipe sekali pakai juga disebut sebagai prototipe cepat atau tertutup. Jenis prototipe ini menggunakan sedikit usaha dengan analisis kebutuhan minimum untuk membangun prototipe. Setelah persyaratan aktual dipahami, prototipe tersebut dibuang dan sistem aktual dikembangkan dengan pemahaman yang lebih jelas tentang persyaratan pengguna.

Pembuatan Prototipe Evolusioner

Prototipe evolusioner juga disebut sebagai prototipe papan tempat memotong roti didasarkan pada pembuatan prototipe fungsional aktual dengan fungsionalitas minimal pada awalnya. Prototipe yang dikembangkan membentuk inti dari prototipe masa depan yang di atasnya seluruh sistem dibangun. Dengan menggunakan prototipe evolusioner, persyaratan yang dipahami dengan baik dimasukkan ke dalam prototipe dan persyaratan tersebut ditambahkan saat dan saat persyaratan tersebut dipahami.

Pembuatan Prototipe Bertambah

Prototipe inkremental mengacu pada pembangunan beberapa prototipe fungsional dari berbagai sub-sistem dan kemudian mengintegrasikan semua prototipe yang tersedia untuk membentuk sistem yang lengkap.

Pembuatan Prototipe Ekstrim

Prototipe ekstrim digunakan dalam domain pengembangan web. Ini terdiri dari tiga fase berurutan. Pertama, prototipe dasar dengan semua halaman yang ada disajikan dalam format HTML. Kemudian pengolahan data disimulasikan menggunakan prototype services layer. Akhirnya, layanan diimplementasikan dan diintegrasikan ke prototipe akhir. Proses ini disebut Prototipe Ekstrim yang digunakan untuk menarik perhatian ke tahap kedua dari proses, di mana UI yang berfungsi penuh dikembangkan dengan sangat sedikit memperhatikan layanan yang sebenarnya.

Pembuatan Prototipe Perangkat Lunak - Aplikasi

Prototipe Perangkat Lunak paling berguna dalam pengembangan sistem yang memiliki tingkat interaksi pengguna yang tinggi seperti sistem online. Sistem yang membutuhkan pengguna untuk mengisi formulir atau melalui berbagai layar sebelum data diproses dapat menggunakan prototyping dengan sangat efektif untuk memberikan tampilan dan nuansa yang tepat bahkan sebelum perangkat lunak yang sebenarnya dikembangkan.

Perangkat lunak yang melibatkan terlalu banyak pemrosesan data dan sebagian besar fungsionalitas internal dengan antarmuka pengguna yang sangat sedikit biasanya tidak mendapat manfaat dari pembuatan prototipe. Pengembangan prototipe bisa menjadi biaya tambahan dalam proyek semacam itu dan mungkin membutuhkan banyak upaya ekstra.

Pembuatan Prototipe Perangkat Lunak - Pro dan Kontra

Prototipe perangkat lunak digunakan dalam kasus-kasus khusus dan keputusan harus diambil dengan sangat hati-hati sehingga upaya yang dilakukan dalam membangun prototipe menambah nilai yang cukup besar pada perangkat lunak akhir yang dikembangkan. Model memiliki pro dan kontra tersendiri yang dibahas sebagai berikut.

Kelebihan Model Prototyping adalah sebagai berikut -

Peningkatan keterlibatan pengguna dalam produk bahkan sebelum penerapannya.
Sejak model kerja dari sistem ditampilkan, pengguna mendapatkan pemahaman yang lebih baik tentang sistem yang dikembangkan.
Mengurangi waktu dan biaya karena cacat dapat dideteksi lebih awal.
Umpan balik pengguna yang lebih cepat tersedia untuk menghasilkan solusi yang lebih baik.
Fungsionalitas yang hilang dapat diidentifikasi dengan mudah.
Fungsi yang membingungkan atau sulit dapat diidentifikasi.

Kekurangan Model Prototyping adalah sebagai berikut -

Risiko analisis kebutuhan yang tidak memadai karena terlalu banyak ketergantungan pada prototipe.
Pengguna mungkin bingung dengan prototipe dan sistem sebenarnya.
Secara praktis, metodologi ini dapat meningkatkan kompleksitas sistem karena ruang lingkup sistem dapat berkembang melampaui rencana awal.
Pengembang dapat mencoba menggunakan kembali prototipe yang ada untuk membangun sistem yang sebenarnya, meskipun secara teknis tidak memungkinkan.
Upaya yang diinvestasikan dalam membangun prototipe mungkin terlalu banyak jika tidak dipantau dengan baik.