Awalnya, Prescriptive process models diajukan untuk mengatur kekacauan dalam pengembangan perangkat lunak. Meskipun model tradisional ini telah memberikan beberapa struktur yang berguna bagi pekerjaan rekayasa perangkat lunak dan peta jalan yang cukup efektif bagi tim pengembang, namun pekerjaan dan produk yang dihasilkan tetap berada di "the edge of chaos".
Dalam sebuah artikel yang menarik tentang keterkaitan yang tidak lazim antara keteraturan dan kekacauan di dalam lingkup perangkat lunak, Nogueira beserta timnya menyampaikan pendapat mereka:
Konsep "The edge of chaos" dapat diartikan sebagai kondisi alami yang berada di antara keteraturan dan kekacauan, mencakup kompromi penting antara struktur dan kejutan seperti yang telah didefinisikan oleh Kauffman. Tepi kekacauan dapat diilustrasikan sebagai keadaan yang tidak stabil dan sebagian terstruktur, dimana kestabilannya selalu tergantung pada keseimbangan antara arus keteraturan dan kekacauan yang terus berubah.
Terkadang kita cenderung beranggapan bahwa keteraturan adalah keadaan alami yang paling ideal, namun pandangan ini mungkin tidak sepenuhnya tepat. Dalam penelitian yang dilakukan oleh Roos dan rekan-rekannya, didukung teori bahwa operasi jauh dari keseimbangan dapat menghasilkan kreativitas, proses yang teratur dengan sendirinya, dan hasil yang lebih baik. Keteraturan absolut dapat berarti tidak ada variasi, yang dapat menguntungkan dalam situasi lingkungan yang tidak dapat diprediksi. Namun, perubahan hanya dapat terjadi ketika ada beberapa struktur yang memungkinkan pengaturan perubahan, tetapi tidak terlalu kaku sehingga tidak ada ruang untuk perubahan sama sekali. Di sisi lain, terlalu banyak kekacauan dapat menghambat koordinasi dan koherensi. Jadi, kurangnya struktur tidak selalu berarti kekacauan.
Konsekuensi filosofis dari argumen ini sangat penting dalam konteks rekayasa perangkat lunak. Jika model proses preskriptif berusaha untuk mencapai keteraturan dan struktur, maka apakah model ini masih relevan untuk dunia perangkat lunak yang selalu berubah dengan cepat? Di sisi lain, jika kita menolak model proses tradisional (dan urutannya) dan menggantinya dengan sesuatu yang kurang terstruktur, apakah hal ini akan membuat koordinasi dan koherensi menjadi mustahil dalam pekerjaan rekayasa perangkat lunak?
Tidak ada solusi yang mudah untuk pertanyaan ini, namun ada alternatif yang tersedia bagi para insinyur perangkat lunak. Pada bagian berikutnya, saya akan memeriksa pendekatan model proses preskriptif, di mana keteraturan dan konsistensi proyek menjadi isu utama. Saya menyebutnya sebagai "prescriptive" karena mereka menerapkan serangkaian aktivitas, kerangka kerja, elemen proses, tindakan rekayasa perangkat lunak, tugas, produk kerja, jaminan kualitas, dan mekanisme kontrol perubahan untuk setiap proyek. Setiap model proses juga menentukan alur proses (juga dikenal sebagai work flow) atau cara di mana elemen proses saling berhubungan.
Setiap model proses perangkat lunak dapat melibatkan aktivitas kerangka kerja yang generik seperti yang dijelaskan di bagian sebelumnya, namun setiap model memiliki fokus yang berbeda pada aktivitas tersebut dan menentukan aliran proses yang memanggil setiap aktivitas kerangka kerja (serta tindakan dan tugas rekayasa perangkat lunak) dengan cara yang berbeda.
1.1 The Waterfall Model
Terkadang diperlukan pemahaman yang baik terhadap persyaratan suatu masalah, terutama ketika pekerjaan berlangsung secara linier dari communication hingga deployment. Kondisi semacam ini sering terjadi ketika dilakukan adaptasi atau peningkatan pada sistem yang telah terdefinisi dengan baik, seperti penyesuaian pada perangkat lunak akuntansi akibat perubahan regulasi pemerintah. Namun, situasi semacam ini juga dapat terjadi pada sejumlah upaya pengembangan baru, tetapi hanya jika persyaratan telah didefinisikan dengan baik dan relatif stabil.
The waterfall model, juga dikenal sebagai classic life cycle, menggambarkan pendekatan terstruktur dan berurutan untuk mengembangkan perangkat lunak yang dimulai dengan memahami kebutuhan pelanggan, lalu melalui tahap perencanaan, pemodelan, konstruksi, dan penerapan, hingga akhirnya dukungan berkelanjutan untuk perangkat lunak yang selesai (lihat Gambar 2.3).
Dalam rekayasa perangkat lunak, variasi dari model air terjun yang biasa digunakan disebut model-V. Model ini menggambarkan pendekatan sistematis dan berurutan dalam pengembangan perangkat lunak yang dimulai dari spesifikasi kebutuhan dan berlanjut melalui tahap perencanaan, pemodelan, konstruksi, dan penerapan, hingga pada tahap dukungan berkelanjutan untuk perangkat lunak yang telah selesai. Seperti yang ditunjukkan dalam Gambar 2.4, model-V mencakup tindakan penjaminan mutu yang terkait dengan aktivitas komunikasi, pemodelan, dan konstruksi awal. Pada tahap awal, tim perangkat lunak memperbaiki dan mengubah persyaratan masalah dasar menjadi representasi yang lebih detail dan teknis. Setelah kode dihasilkan, tim perangkat lunak melakukan serangkaian pengujian untuk memvalidasi setiap model yang dibuat pada tahap sebelumnya. Model-V sebenarnya tidak memiliki perbedaan mendasar dengan model air terjun klasik, namun memberikan cara yang lebih jelas dan tervisualisasi dalam menerapkan tindakan verifikasi dan validasi pada pekerjaan rekayasa sebelumnya.
Paradigma tertua dalam rekayasa perangkat lunak adalah waterfall model. Meskipun begitu, dalam tiga dekade terakhir, terdapat kritik terhadap model proses ini yang menyebabkan bahkan para pendukungnya meragukan keefektifannya. Beberapa masalah yang sering terjadi ketika waterfall model digunakan antara lain:
- Dalam kenyataannya, proyek perangkat lunak sering tidak mengikuti urutan linear yang diusulkan oleh model proses tertentu. Meskipun model-model linier dapat mencakup iterasi, namun secara tidak langsung. Oleh karena itu, perubahan dalam proyek dapat menyebabkan ketidakjelasan dalam pengembangan oleh tim proyek.
- Terkadang, pelanggan mengalami kesulitan dalam menyatakan semua persyaratan secara eksplisit pada awal proyek. Hal ini dapat menyulitkan penerapan waterfall model, yang membutuhkan persyaratan yang jelas, dan mungkin mengalami kesulitan dalam menangani ketidakpastian awal yang sering terjadi dalam banyak proyek.
- Diperlukan kesabaran dari pelanggan karena versi fungsional dari program tidak akan tersedia sampai akhir dari periode proyek. Kegagalan besar yang tidak terdeteksi hingga program diperiksa dapat berdampak buruk.
Dalam analisis proyek aktual yang menarik, Bradac menemukan bahwa sifat linear dari classic life cycle dapat menyebabkan "blocking states" di mana beberapa anggota tim proyek harus menunggu anggota tim lain menyelesaikan tugas tergantung mereka. Bahkan, waktu yang dihabiskan untuk menunggu bisa lebih lama daripada waktu yang dihabiskan untuk bekerja produktif. Keadaan pemblokiran cenderung terjadi pada awal dan akhir proses sekuensial linier.
Pada saat ini, pekerjaan pengembangan perangkat lunak dituntut untuk dilakukan secara cepat dan selalu mengikuti aliran perubahan yang tak kunjung berakhir, terutama terkait dengan fitur, fungsi, dan konten informasi. Oleh karena itu, waterfall model cenderung tidak cocok untuk jenis pekerjaan seperti itu. Namun, model tersebut masih dapat digunakan sebagai model proses yang efektif dalam situasi di mana persyaratan harus ditetapkan dan pekerjaan harus dilakukan secara linier.
1.2 Incremental Process Models
Kalimat tersebut dapat diparafrase menjadi "Ada banyak situasi di mana persyaratan perangkat lunak awal terdefinisi dengan baik, namun kebutuhan pengembangan menyebabkan proses yang tidak dapat dijalankan secara linier. Terkadang, terdapat kebutuhan mendesak untuk menyediakan sejumlah fungsionalitas terbatas dari perangkat lunak kepada pengguna dengan cepat, dan kemudian meningkatkan dan memperluas fungsionalitas dalam rilis selanjutnya. Dalam kasus tersebut, model proses yang dirancang untuk menghasilkan perangkat lunak secara bertahap dapat dipilih.
Dalam incremental model, terdapat kombinasi antara aliran proses linier dan paralel seperti yang telah dibahas di bagian sebelumnya. Seperti yang dijelaskan dalam Gambar 2.5, model ini mengikuti urutan linier dengan cara yang terputus-putus seiring berjalannya waktu. Setiap urutan linier menghasilkan "increments" pada perangkat lunak yang dapat diterapkan dengan cara yang serupa dengan peningkatan pada aliran proses evolusi seperti yang dibahas di bagian selanjutnya.
Contohnya, sebuah perangkat lunak pengolah kata yang dikembangkan menggunakan incremental model mungkin menyediakan manajemen file dasar, fungsi pengeditan, dan produksi dokumen pada tahap awal; kemudian menambahkan kemampuan pengeditan dan produksi dokumen yang lebih canggih pada tahap berikutnya; menambahkan pemeriksaan ejaan dan tata bahasa pada tahap selanjutnya; dan akhirnya menambahkan kemampuan tata letak halaman yang lebih lanjut pada tahap terakhir peningkatan. Perlu dicatat bahwa setiap peningkatan dalam aliran proses dapat menggabungkan paradigma prototyping.
Ketika incremental model digunakan, inkremen pertama seringkali merupakan produk inti. Artinya, persyaratan dasar sudah dipenuhi tetapi banyak fitur tambahan (beberapa diketahui, yang lain tidak diketahui) tetap tidak terkirim. Produk inti digunakan oleh pelanggan (atau mengalami evaluasi terperinci). Sebagai hasil dari penggunaan dan/atau evaluasi, rencana dikembangkan untuk penambahan berikutnya. Rencana tersebut membahas modifikasi produk inti untuk memenuhi kebutuhan pelanggan dengan lebih baik dan penyampaian fitur dan fungsionalitas tambahan. Proses ini diulang mengikuti pengiriman setiap penambahan, sampai produk lengkap diproduksi.
Incremental process model berfokus pada pengiriman produk yang dapat dioperasikan pada setiap peningkatan. Pada awal peningkatan, versi akhir produk yang telah dipangkas disediakan, yang menyediakan kemampuan yang berguna bagi pengguna dan juga menyediakan platform untuk evaluasi oleh pengguna.
Incremental development menjadi pilihan yang bermanfaat ketika sumber daya manusia tidak tersedia untuk implementasi proyek secara keseluruhan sesuai dengan tenggat waktu bisnis yang telah ditetapkan. Inkremen awal dapat diterapkan dengan lebih sedikit sumber daya manusia. Jika produk inti mendapat tanggapan yang baik, maka sumber daya manusia tambahan dapat ditambahkan jika diperlukan untuk mengimplementasikan peningkatan berikutnya. Selain itu, peningkatan dapat direncanakan untuk mengelola risiko teknis seperti keterbatasan perangkat keras yang baru dikembangkan dan tanggal pengirimannya tidak jelas. Dengan merencanakan peningkatan awal secara cermat, fungsionalitas dapat dikirimkan secara parsial ke pengguna akhir tanpa penundaan yang berlebihan.
1.3 Evolutionary Process Models
Perangkat lunak, seperti semua sistem yang kompleks, berkembang selama periode waktu tertentu. Persyaratan bisnis dan produk sering berubah seiring dengan perkembangan, membuat jalur lurus menuju produk akhir menjadi tidak realistis; tenggat waktu pasar yang ketat membuat penyelesaian produk perangkat lunak yang komprehensif menjadi tidak mungkin, tetapi versi terbatas harus diperkenalkan untuk memenuhi tekanan persaingan atau bisnis; satu set produk inti atau persyaratan sistem dipahami dengan baik, tetapi detail produk atau ekstensi sistem belum ditentukan. Dalam situasi ini dan yang serupa, Anda memerlukan model proses yang telah dirancang secara eksplisit untuk mengakomodasi produk yang berkembang dari waktu ke waktu.
Evolutionary model adalah model yang bersifat iteratif, dimana Anda dapat mengembangkan versi perangkat lunak yang semakin lengkap. Dalam paragraf berikutnya, akan dijelaskan dua model proses evolusi yang sering digunakan.
Prototyping. Banyak pelanggan yang hanya menentukan tujuan umum untuk perangkat lunak tanpa memberikan persyaratan rinci untuk fungsi dan fiturnya. Sementara itu, pengembang mungkin tidak yakin tentang efisiensi algoritme, kemampuan sistem operasi untuk beradaptasi, atau bentuk interaksi manusia-mesin yang sebaiknya digunakan. Dalam berbagai situasi semacam ini, pendekatan prototyping mungkin menjadi solusi terbaik.
Walaupun prototyping bisa digunakan sebagai model proses utama, lebih sering digunakan sebagai teknik yang dimasukkan ke dalam salah satu model proses yang dibahas dalam bab ini. Dalam situasi di mana persyaratan tidak jelas, paradigma prototyping dapat membantu dalam memperoleh pemahaman yang lebih baik tentang produk yang akan dikembangkan, baik bagi Anda maupun para pemangku kepentingan.
Anda dapat memulai paradigma prototyping (lihat Gambar 2.6) dengan melakukan komunikasi dengan pemangku kepentingan lainnya. Pertemuan ini bertujuan untuk menetapkan tujuan umum perangkat lunak, mengidentifikasi persyaratan yang diketahui, dan menggarisbawahi area yang perlu didefinisikan lebih lanjut. Pembuatan prototipe dilakukan dengan iterasi yang cepat, dan dilakukan pemodelan dengan menggunakan "quick design". Quick design fokus pada representasi aspek perangkat lunak yang akan dilihat oleh pengguna akhir, seperti tampilan antarmuka manusia atau format keluaran. Prototipe kemudian dibangun dengan mengikuti desain cepat, dan dievaluasi oleh pemangku kepentingan. Feedback dari pemangku kepentingan digunakan untuk menyempurnakan persyaratan lebih lanjut. Dalam iterasi selanjutnya, prototipe akan disesuaikan untuk memenuhi kebutuhan berbagai pemangku kepentingan, sehingga membantu Anda memahami dengan lebih baik apa yang perlu dilakukan.
Secara optimal, prototipe berperan dalam mengidentifikasi persyaratan perangkat lunak yang dibutuhkan. Jika ada rencana untuk membangun prototipe yang berfungsi, Anda bisa menggunakan fragmen program yang sudah ada atau memanfaatkan alat-alat tertentu (seperti pembuat laporan dan pengelola jendela) untuk mempercepat pembuatan program kerja.
Satu pertanyaan yang sering muncul adalah apa yang harus dilakukan dengan prototipe setelah mencapai tujuan awal yang telah dijelaskan sebelumnya? Brooks memberikan saran terkait hal ini:
Pada kebanyakan proyek, sistem awal yang dibangun seringkali tidak dapat digunakan. Hal ini mungkin disebabkan karena sistem tersebut terlalu lambat, terlalu besar, atau sulit digunakan. Oleh karena itu, satu-satunya pilihan adalah memulai kembali dan membangun versi yang lebih baik, yang dirancang ulang untuk mengatasi masalah-masalah tersebut.
Anda dapat mempertimbangkan prototipe sebagai bentuk "the first system", yang menurut Brooks sebaiknya dibuang. Namun, pandangan tersebut mungkin terlalu idealis. Beberapa prototipe dibangun sebagai satu kali penggunaan saja, sementara yang lain berkembang secara evolusioner, dan akhirnya menjadi sistem yang sebenarnya.
Para pemangku kepentingan dan insinyur perangkat lunak umumnya menyambut positif paradigma prototyping karena pengguna dapat mengalami sistem yang sebenarnya dan pengembang dapat langsung membangun sesuatu. Namun, ada beberapa alasan mengapa pembuatan prototipe bisa menjadi sulit:
- Dalam beberapa kasus, pemangku kepentingan dapat melihat prototipe sebagai versi perangkat lunak yang berfungsi tanpa menyadari bahwa prototipe dibangun dengan cara yang sembarangan dan tanpa mempertimbangkan kualitas perangkat lunak secara keseluruhan atau pemeliharaan jangka panjang. Jika kemudian para pemangku kepentingan diberitahu bahwa produk harus dibangun kembali untuk mempertahankan tingkat kualitas yang tinggi, mereka mungkin merasa kecewa dan menuntut perbaikan cepat untuk membuat prototipe menjadi produk yang berfungsi. Terlalu sering, manajemen pengembangan perangkat lunak menyerah pada tuntutan ini.
- Sebagai seorang insinyur perangkat lunak, Anda seringkali harus melakukan pengorbanan dalam implementasi untuk memastikan prototipe dapat bekerja dengan cepat. Terkadang, Anda mungkin menggunakan sistem operasi atau bahasa pemrograman yang tidak ideal hanya karena ketersediaannya dan familiaritasnya, atau mengimplementasikan algoritma yang kurang efisien hanya untuk menunjukkan kemampuan prototipe. Seiring berjalannya waktu, Anda mungkin akan merasa nyaman dengan pilihan-pilihan tersebut dan melupakan alasan mengapa sebenarnya pilihan tersebut tidak optimal. Akibatnya, pilihan kurang ideal tersebut akan menjadi bagian integral dari sistem.
Meskipun terdapat risiko masalah yang muncul, pembuatan prototipe tetap bisa menjadi paradigma yang efektif dalam rekayasa perangkat lunak. Namun, penting untuk menetapkan aturan yang jelas di awal, yaitu semua pemangku kepentingan harus sepakat bahwa prototipe hanya digunakan sebagai alat untuk menentukan kebutuhan perangkat lunak. Setelah itu, prototipe harus dibuang (setidaknya sebagian), dan perangkat lunak yang sebenarnya direkayasa dengan memperhatikan kualitas yang diinginkan.
The Spiral Model. Model spiral, yang pertama kali diusulkan oleh Barry Boehm, adalah suatu model pengembangan perangkat lunak yang menggabungkan pendekatan iteratif dalam pembuatan prototipe dengan fitur yang terstruktur dan sistematis dari model air terjun. Model ini memungkinkan pengembangan perangkat lunak secara cepat dengan versi yang semakin lengkap. Boehm menjelaskan model spiral tersebut sebagai berikut:
Model spiral merupakan suatu model proses pengembangan perangkat lunak yang dibangun berdasarkan analisis risiko untuk memandu proses rekayasa perangkat lunak yang melibatkan beberapa pihak-pihak yang memiliki kepentingan dalam sistem perangkat lunak yang kompleks. Dua fitur utama dari model ini adalah pendekatan siklus untuk secara bertahap meningkatkan tingkat definisi dan implementasi sistem sambil mengurangi risiko dan rangkaian titik jangkar yang digunakan untuk memastikan komitmen semua pihak terhadap solusi sistem yang memuaskan dan sesuai.
Dalam pengembangan perangkat lunak menggunakan model spiral, dirancang serangkaian rilis yang terus berkembang. Pada tahap awal iterasi, rilis mungkin berupa model atau prototipe. Sementara pada tahap iterasi selanjutnya, sistem yang direkayasa akan menghasilkan versi yang lebih lengkap. Hal ini dilakukan secara bertahap untuk mencapai sistem yang lebih sempurna.
Tim rekayasa perangkat lunak membagi model spiral ke dalam serangkaian kegiatan kerangka kerja yang telah ditentukan. Sebagai contoh, penulis menggunakan kegiatan kerangka umum yang telah dijelaskan sebelumnya. Setiap kegiatan kerangka tersebut mewakili satu segmen dari jalur spiral seperti yang ditunjukkan pada Gambar 2.7. Tim perangkat lunak kemudian melakukan aktivitas sepanjang jalur spiral searah jarum jam, dimulai dari pusat, ketika proses evolusi dimulai. Selama setiap revolusi, tim mempertimbangkan risiko yang terkait. Untuk setiap lintasan evolusi, titik tonggak yang dicapai - yaitu kombinasi kondisi dan produk kerja - dicatat.
Tim perangkat lunak dapat menggunakan sirkuit pertama sekitar spiral untuk mengembangkan spesifikasi produk, sedangkan sirkuit berikutnya dapat digunakan untuk membuat prototipe dan versi perangkat lunak yang lebih canggih. Setiap kali melintasi wilayah perencanaan, perubahan dilakukan pada rencana proyek sesuai kebutuhan. Biaya dan jadwal proyek disesuaikan berdasarkan umpan balik dari pelanggan setelah pengiriman. Selain itu, manajer proyek dapat menyesuaikan jumlah iterasi yang direncanakan yang diperlukan untuk menyelesaikan pengembangan perangkat lunak.
Model spiral berbeda dengan model proses lain yang berakhir ketika perangkat lunak dikirimkan, karena model spiral dapat diadaptasi untuk digunakan sepanjang masa hidup perangkat lunak komputer. Dalam hal ini, sirkuit pertama sekitar spiral mungkin mewakili "concept development project" yang dimulai dari inti spiral dan berlanjut selama beberapa iterasi hingga pengembangan konsep selesai. Jika konsep tersebut akan dikembangkan menjadi produk aktual, prosesnya akan berlanjut ke luar spiral dan "new product development project" akan dimulai. Produk baru akan mengalami sejumlah iterasi di sekitar spiral. Selanjutnya, sirkuit di sekitar spiral dapat digunakan untuk mewakili "proyek peningkatan produk". Secara umum, model spiral terus beroperasi hingga perangkat lunak dihentikan, meskipun ada saat-saat ketika proses tidak aktif. Namun setiap kali perubahan dimulai, proses dimulai pada titik masuk yang sesuai (seperti pada proses peningkatan produk).
Pendekatan pengembangan sistem dan perangkat lunak yang realistis dapat dilakukan dengan menggunakan model spiral pada skala besar. Dalam pengembangan perangkat lunak, semakin berkembangnya proses, semakin memahami dan merespons risiko oleh pengembang dan pelanggan pada setiap tingkat evolusinya. Model spiral menggunakan prototyping sebagai pengurang risiko, namun yang lebih penting lagi adalah, model ini memungkinkan penerapan pendekatan prototyping pada setiap tahap evolusi produk. Dengan cara ini, pendekatan bertahap sistematis yang disarankan oleh siklus hidup klasik tetap dipertahankan namun diintegrasikan ke dalam kerangka berulang yang mencerminkan dunia nyata secara lebih realistis. Model spiral menuntut pemikiran langsung pada risiko teknis pada semua tahapan proyek dan jika digunakan dengan benar, harus mengurangi risiko sebelum menjadi masalah yang lebih besar.
Tetapi seperti model paradigma lainnya, model spiral tidak dapat menjamin kesuksesan proyek secara instan. Mungkin sulit untuk meyakinkan pelanggan (terutama dalam situasi kontrak) bahwa pendekatan evolusi dapat diatur. Hal ini memerlukan keahlian yang cukup besar dalam mengevaluasi risiko dan keberhasilan bergantung pada kemampuan ini. Jika risiko utama tidak diidentifikasi dan ditangani dengan baik, masalah pasti akan muncul.
1.4 Concurrent Models
Concurrent development model, yang juga dikenal sebagai concurrent engineering, memungkinkan tim perangkat lunak untuk menggabungkan elemen iteratif dan bersamaan dari berbagai model proses pengembangan yang telah dijelaskan sebelumnya. Dalam hal model spiral, aktivitas pemodelan ditangani melalui beberapa tindakan rekayasa perangkat lunak seperti prototyping, analysis, dan design.
Dalam bab ini, terdapat gambaran skematis tentang aktivitas rekayasa perangkat lunak dalam model pemodelan konkuren. Gambar 2.8 menunjukkan bahwa aktivitas modeling dapat berada dalam berbagai kondisi yang dicatat pada waktu tertentu. Selain itu, aktivitas lain seperti communication atau construction juga dapat direpresentasikan dalam cara yang sama. Semua aktivitas rekayasa perangkat lunak ada secara bersamaan, tetapi berada di negara bagian yang berbeda.
Sebagai contoh, pada awal proyek, aktivitas komunikasi telah menyelesaikan iterasi pertamanya dan saat ini sedang awaiting changes. Aktivitas pemodelan, yang sebelumnya dalam keadaan inactive setelah selesainya aktivitas komunikasi, kini sedang dalam under development. Namun, jika pelanggan memerlukan perubahan persyaratan, aktivitas pemodelan akan beralih dari status under development ke status awaiting changes.
Untuk menggunakan pendekatan concurrent modeling, suatu model proses perangkat lunak membutuhkan definisi peristiwa yang memicu perubahan status dari aktivitas rekayasa perangkat lunak. Sebagai contoh, dalam tahap desain awal, mungkin terdapat ketidaksesuaian dalam model persyaratan yang akan menghasilkan koreksi dalam model analisis. Peristiwa ini kemudian akan memicu tindakan analisis persyaratan untuk berpindah dari status done ke status awaiting changes. Pemodelan konkuren juga diterapkan untuk aktivitas lain seperti komunikasi atau konstruksi dan memiliki rangkaian peristiwa yang khusus untuk setiap aktivitas.
Concurrent modeling dapat digunakan pada pengembangan perangkat lunak apa pun dan memberikan gambaran yang akurat tentang status proyek saat ini. Tidak seperti model pengembangan linier yang membatasi aktivitas, tindakan, dan tugas rekayasa perangkat lunak ke dalam urutan peristiwa, model pengembangan bersamaan mendefinisikan jaringan proses yang memungkinkan setiap aktivitas, tindakan, atau tugas berjalan secara bersamaan dengan yang lainnya. Peristiwa yang terjadi pada satu titik dalam proses jaringan akan memicu transisi antara status yang berbeda.
1.5 A Final Word on Evolutionary Processes
Saya telah mengamati bahwa perangkat lunak komputer modern ditandai dengan perubahan yang terus-menerus, tenggat waktu yang sangat ketat, serta kebutuhan yang jelas untuk memuaskan pelanggan atau pengguna. Terkadang, waktu yang diperlukan untuk mencapai pasar adalah persyaratan manajemen yang paling krusial. Apabila kesempatan tersebut terlewatkan, maka proyek perangkat lunak tersebut mungkin tidak memiliki makna.
Tujuan dibuatnya model evolutionary process adalah untuk mengatasi masalah yang dihadapi pada perangkat lunak yang selalu berubah, namun sebagai salah satu model proses yang umum digunakan, model ini memiliki kelemahan yang teridentifikasi oleh Nogueira dan koleganya:
Meskipun ada keuntungan yang jelas dari penggunaan proses evolusi dalam pengembangan perangkat lunak, namun ada beberapa kekhawatiran yang perlu dipertimbangkan. Salah satu kekhawatiran utama adalah bahwa penggunaan pembuatan prototipe [dan proses evolusi lain yang lebih canggih] dapat menyebabkan masalah dalam perencanaan proyek karena jumlah siklus yang tidak pasti yang dibutuhkan untuk menghasilkan produk. Banyak manajemen proyek dan estimasi teknik didasarkan pada tata letak aktivitas linier, sehingga kurang cocok untuk penggunaan proses evolusi.
Dalam proses perangkat lunak evolusioner, terdapat kekhawatiran terkait kecepatan evolusi yang tidak diatur secara maksimal. Jika evolusi terjadi terlalu cepat tanpa waktu relaksasi, maka prosesnya akan menjadi kacau. Di sisi lain, jika kecepatannya terlalu lambat, produktivitas bisa terpengaruh.
Ketiga, fokus proses pengembangan perangkat lunak harus dipindahkan ke fleksibilitas dan ekstensibilitas, bukan kualitas tinggi. Meskipun terdengar menakutkan, prioritas harus diberikan pada kecepatan pengembangan daripada mencoba untuk mencapai nol cacat. Memperluas pengembangan untuk mencapai kualitas tinggi bisa berakibat pada pengiriman produk yang terlambat, ketika peluang pasar telah hilang. Persaingan ketat di industri software saat ini memaksa untuk mengadopsi paradigma baru ini.
Memprioritaskan fleksibilitas, ekstensibilitas, dan kecepatan pengembangan dengan kualitas tinggi dalam proses pengembangan perangkat lunak memang terdengar menakutkan. Namun, para ahli rekayasa perangkat lunak yang terhormat, seperti [You95] dan [Bac97], telah mengusulkan ide tersebut.
Dalam model evolusioner, tujuannya adalah menghasilkan perangkat lunak berkualitas tinggi melalui proses iteratif atau inkremental. Akan tetapi, proses evolusioner juga dapat digunakan untuk menekankan fleksibilitas, ekstensibilitas, dan kecepatan pengembangan. Tantangan utama bagi tim pengembang dan manajernya adalah menemukan keseimbangan yang tepat antara proyek kritis ini, parameter produk, dan kepuasan pelanggan sebagai penentu utama kualitas perangkat lunak.
Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.
Comments
Post a Comment