MODEL SIKLUS HIDUP PERANGKAT LUNAK
2.1 BEBERAPA KONSEP DASAR
BAB 2
Siklus hidup setiap perangkat lunak dimulai dengan permintaan oleh satu atau lebih pelanggan. Pada tahap ini, pelanggan biasanya tidak jelas tentang semua fitur yang akan dibutuhkan, mereka juga tidak dapat sepenuhnya menggambarkan fitur yang diidentifikasi secara konkret, dan hanya dapat secara samar menggambarkan apa yang dibutuhkan. Tahap ini di mana pelanggan merasakan kebutuhan akan perangkat lunak dan membentuk gagasan kasar tentang fitur yang diperlukan dikenal sebagai tahap awal. Dimulai dengan tahap awal, perangkat lunak berkembang melalui serangkaian tahap yang dapat diidentifikasi (juga disebut fase) karena aktivitas pengembangan yang dilakukan oleh pengembang, hingga sepenuhnya dikembangkan dan dirilis ke pelanggan.
Setelah diinstal dan tersedia untuk digunakan, pengguna mulai menggunakan perangkat lunak. Ini menandakan dimulainya fase operasi (juga disebut pemeliharaan). Saat pengguna menggunakan perangkat lunak, mereka tidak hanya meminta untuk memperbaiki kegagalan yang mungkin mereka temui, tetapi mereka juga terus menyarankan beberapa perbaikan dan modifikasi pada perangkat lunak. Dengan demikian, fase pemeliharaan biasanya melibatkan terus-menerus membuat perubahan pada perangkat lunak untuk mengakomodasi perbaikan bug dan permintaan perubahan dari pengguna. Fase operasi biasanya yang terpanjang dari semua fase dan merupakan masa manfaat perangkat lunak.
Akhirnya perangkat lunak dihentikan, ketika pengguna tidak merasa berguna lagi karena alasan seperti skenario bisnis yang berubah, ketersediaan perangkat lunak baru yang memiliki fitur dan kerja yang lebih baik, platform komputasi yang berubah, dll. Ini membentuk inti dari siklus hidup dari setiap perangkat lunak. Berdasarkan uraian tersebut, kita dapat mendefinisikan siklus hidup perangkat lunak sebagai berikut:
Siklus hidup perangkat lunak mewakili serangkaian tahapan yang dapat diidentifikasi di mana ia berkembang selama masa hidupnya. Dengan pengetahuan tentang siklus hidup perangkat lunak ini, konsep model siklus hidup perangkat lunak dan mengeksplorasi mengapa perlu mengikuti model siklus hidup dalam lingkungan pengembangan perangkat lunak profesional.
Model siklus hidup pengembangan perangkat lunak (SDLC)
Dalam skenario pengembangan perangkat lunak yang sistematis, aktivitas tertentu yang terdefinisi dengan baik perlu dilakukan oleh tim pengembangan dan mungkin juga oleh pelanggan, agar perangkat lunak berkembang dari satu tahap dalam siklus hidupnya ke tahap berikutnya. Misalnya, agar perangkat lunak berkembang dari tahap spesifikasi persyaratan ke tahap desain, developer perlu memperoleh persyaratan dari pelanggan, menganalisis persyaratan tersebut, dan secara formal mendokumentasikan persyaratan dalam bentuk dokumen SRS.
Model siklus hidup pengembangan perangkat lunak (SDLC) (juga disebut model siklus hidup perangkat lunak dan model proses pengembangan perangkat lunak) menjelaskan berbagai aktivitas yang perlu dilakukan agar perangkat lunak berkembang dalam siklus hidupnya. Sepanjang diskusi kita, kita akan menggunakan istilah siklus hidup pengembangan perangkat lunak (SDLC) dan proses pengembangan perangkat lunak secara bergantian.
Namun, beberapa penulis membedakan SDLC dari proses pengembangan perangkat lunak.
Dalam penggunaannya, proses pengembangan perangkat lunak menggambarkan aktivitas siklus hidup lebih tepat dan rumit, dibandingkan dengan SDLC. Juga, proses pengembangan mungkin tidak hanya menggambarkan berbagai kegiatan yang dilakukan selama siklus hidup, tetapi juga menentukan metodologi khusus untuk melaksanakan kegiatan, dan juga merekomendasikan dokumen spesifik dan artefak lain yang harus dihasilkan pada akhir setiap fase. Dalam pengertian ini, istilah SDLC dapat dianggap sebagai istilah yang lebih umum,
dibandingkan dengan proses pengembangan dan beberapa proses pengembangan mungkin cocok dengan SDLC yang sama.
SDLC direpresentasikan secara grafis dengan menggambar berbagai tahapan siklus hidup dan menunjukkan transisi antar fase. Model grafis ini biasanya disertai dengan deskripsi tekstual dari berbagai kegiatan yang perlu dilakukan selama fase sebelum fase itu dapat dianggap selesai. Dengan kata sederhana, kita dapat mendefinisikan SDLC sebagai berikut:
SDLC secara grafis menggambarkan fase-fase yang berbeda di mana perangkat lunak berkembang. Biasanya disertai dengan deskripsi tekstual tentang berbagai kegiatan yang perlu dilakukan selama setiap fase.
Proses versus metodologi
Meskipun istilah proses dan metodologi kadang-kadang digunakan secara bergantian, ada perbedaan tipis antara keduanya. Pertama, istilah proses memiliki cakupan yang lebih luas dan membahas semua aktivitas yang terjadi selama pengembangan perangkat lunak, atau aktivitas tertentu yang kasar seperti desain (misalnya proses desain), pengujian (proses pengujian), dll. Selanjutnya, proses perangkat lunak tidak hanya mengidentifikasi aktivitas spesifik yang perlu dilakukan, tetapi juga dapat menentukan metodologi tertentu untuk melaksanakan setiap aktivitas. Misalnya, proses desain dapat merekomendasikan bahwa pada tahap desain, aktivitas desain tingkat tinggi dilakukan menggunakan analisis terstruktur dan metodologi desain Hatley dan Pirbhai.
Metodologi, di sisi lain, mengatur serangkaian langkah untuk melakukan aktivitas siklus hidup tertentu. Ini juga dapat mencakup alasan dan asumsi filosofis di balik serangkaian langkah-langkah di mana aktivitas tersebut dicapai. Proses pengembangan perangkat lunak memiliki cakupan yang jauh lebih luas dibandingkan dengan metodologi pengembangan perangkat lunak. Sebuah proses biasanya menggambarkan semua aktivitas mulai dari awal perangkat lunak hingga tahap pemeliharaan dan penghentiannya, atau setidaknya sebagian aktivitas dalam siklus hidup. Ini juga merekomendasikan metodologi khusus untuk melaksanakan setiap kegiatan. Metodologi, sebaliknya, menggambarkan langkah-langkah untuk melakukan hanya satu atau paling banyak beberapa kegiatan.
Mengapa menggunakan proses pengembangan?
Keuntungan utama menggunakan proses pengembangan adalah mendorong pengembangan perangkat lunak secara sistematis dan disiplin. Mengikuti suatu proses sangat penting untuk pengembangan perangkat lunak profesional yang membutuhkan upaya tim.
Ketika perangkat lunak dikembangkan oleh tim daripada oleh programmer individu, penggunaan model siklus hidup menjadi sangat diperlukan untuk keberhasilan penyelesaian proyek. Organisasi pengembangan perangkat lunak telah menyadari bahwa kepatuhan terhadap model siklus hidup yang sesuai membantu menghasilkan perangkat lunak berkualitas baik dan membantu meminimalkan kemungkinan pembengkakan waktu dan biaya.
Misalkan seorang programmer tunggal sedang mengembangkan sebuah program kecil. Misalnya, seorang mahasiswa mungkin mengembangkan kode untuk tugas ruang kelas.
mahasiswa mungkin berhasil bahkan ketika dia tidak secara ketat mengikuti proses pengembangan tertentu dan mengadopsi gaya pengembangan dan perbaikan. Namun, ini adalah permainan bola yang berbeda ketika perangkat lunak profesional sedang dikembangkan oleh tim pemrogram. Sekarang mari kita memahami kesulitan yang mungkin timbul jika tim tidak menggunakan proses pengembangan apa pun, dan anggota tim diberikan kebebasan penuh untuk mengembangkan bagian perangkat lunak yang ditugaskan sesuai dengan kebijaksanaan mereka sendiri.
Beberapa jenis masalah mungkin muncul. Salah satu masalah digambarkan melalui contoh. Misalkan, masalah pengembangan perangkat lunak telah dibagi menjadi beberapa bagian dan bagian-bagian ini ditugaskan ke anggota tim. Sejak saat itu, anggaplah anggota tim diberi kebebasan untuk mengembangkan bagian-bagian yang ditugaskan kepada mereka dengan cara apa pun yang mereka suka. Ada kemungkinan bahwa satu anggota mungkin mulai menulis kode untuk bagiannya sambil membuat asumsi tentang hasil input yang diperlukan dari bagian lain, yang lain mungkin memutuskan untuk menyiapkan dokumen uji terlebih dahulu, dan beberapa developer lain mungkin mulai melaksanakan desain untuk bagian tersebut. bagian yang diberikan kepadanya. Dalam hal ini, masalah berat dapat muncul dalam menghubungkan bagian-bagian yang berbeda dan dalam mengelola pembangunan secara keseluruhan. Oleh karena itu, pengembangan ad hoc ternyata merupakan cara yang pasti untuk mendapatkan proyek yang gagal. Percaya atau tidak, inilah yang menyebabkan banyak proyek gagal di masa lalu!
Ketika sebuah perangkat lunak dikembangkan oleh sebuah tim, penting untuk memiliki pemahaman yang tepat di antara anggota tim tentang—kapan melakukan apa. Dengan tidak adanya pemahaman seperti itu, jika setiap anggota setiap saat akan melakukan aktivitas apa pun yang dia ingin lakukan. Ini akan menjadi undangan terbuka untuk kekacauan perkembangan dan kegagalan proyek. Penggunaan model siklus hidup yang sesuai sangat penting untuk keberhasilan penyelesaian proyek pengembangan berbasis tim. Namun, apakah kita memerlukan model SDLC untuk mengembangkan program kecil. Dalam konteks ini, kita perlu membedakan antara programming-in-the-small dan programming-in-the-large.
Pemrograman-dalam-kecil mengacu pada pengembangan program mainan oleh seorang programmer tunggal. Sedangkan programming-in-the-large mengacu pada pengembangan perangkat lunak profesional melalui upaya tim. Sementara pengembangan perangkat lunak dari tipe sebelumnya dapat berhasil bahkan ketika seorang programmer individu menggunakan gaya pengembangan dan perbaikan, penggunaan SDLC yang sesuai sangat penting untuk proyek pengembangan perangkat lunak profesional yang melibatkan upaya tim untuk berhasil.
Mengapa mendokumentasikan proses pengembangan?
Tidaklah cukup bagi sebuah organisasi untuk hanya memiliki proses pengembangan yang terdefinisi dengan baik, tetapi proses pengembangan perlu didokumentasikan dengan baik. Untuk memahami alasannya, mari kita pertimbangkan bahwa organisasi pengembangan tidak mendokumentasikan proses pengembangannya. Dalam hal ini, pengembangnya hanya mengembangkan pemahaman informal tentang proses pengembangan. Pemahaman informal tentang proses pengembangan di antara anggota tim dapat menimbulkan beberapa masalah selama pengembangan. Ientifikasi beberapa masalah penting yang mungkin muncul ketika proses pengembangan tidak didokumentasikan secara memadai. Masalah-masalah tersebut adalah sebagai berikut:
• Model proses terdokumentasi memastikan bahwa setiap aktivitas dalam siklus hidup didefinisikan secara akurat. Juga, di mana diperlukan metodologi untuk melaksanakan kegiatan masing-masing dijelaskan. Tanpa dokumentasi, aktivitas dan urutannya cenderung didefinisikan secara longgar, yang menyebabkan kebingungan dan salah tafsir oleh tim yang berbeda dalam organisasi. Misalnya, tinjauan kode dapat dilakukan secara informal dan tidak memadai karena tidak ada metodologi yang terdokumentasi tentang bagaimana tinjauan kode harus dilakukan. Kesulitan lain adalah bahwa untuk aktivitas yang didefinisikan secara longgar, developer cenderung menggunakan penilaian subjektif mereka. Sebagai contoh, kecuali jika ditentukan secara eksplisit, anggota tim akan secara subyektif memutuskan apakah kasus uji harus dirancang tepat setelah fase persyaratan,
setelah fase desain, atau setelah fase pengkodean. Juga, mereka akan memperdebatkan apakah kasus uji harus didokumentasikan sama sekali dan ketelitiannya harus didokumentasikan.
• Proses yang tidak terdokumentasi memberikan indikasi yang jelas kepada anggota tim pengembangan tentang kurangnya keseriusan pihak manajemen organisasi untuk mengikuti proses tersebut. Oleh karena itu, proses yang tidak berdokumen berfungsi sebagai petunjuk bagi developer untuk mengikuti proses secara longgar. Gejala dari proses yang tidak terdokumentasi mudah terlihat—desain dilakukan dengan lusuh, tinjauan tidak dilakukan secara ketat, dll.
• Sebuah tim proyek mungkin sering harus menyesuaikan model proses standar untuk digunakan dalam proyek tertentu. Lebih mudah untuk menyesuaikan model proses yang terdokumentasi, ketika diperlukan untuk memodifikasi aktivitas atau fase tertentu dari siklus hidup. Misalnya, pertimbangkan situasi proyek yang mengharuskan aktivitas pengujian dialihdayakan ke organisasi lain. Pada kasus ini,
• Model proses yang terdokumentasi akan membantu mengidentifikasi di mana tepatnya penyesuaian yang diperlukan harus dilakukan. Model proses terdokumentasi merupakan persyaratan wajib standar jaminan kualitas modern seperti ISO 9000 dan SEI CMM. Ini berarti bahwa kecuali organisasi perangkat lunak memiliki proses terdokumentasi, itu tidak akan memenuhi syarat untuk akreditasi dengan standar kualitas apa pun. Dengan tidak adanya sertifikasi mutu untuk organisasi, pelanggan akan curiga terhadap kemampuannya dalam mengembangkan perangkat lunak berkualitas dan organisasi mungkin akan kesulitan memenangkan tender untuk pengembangan perangkat lunak.
Proses pengembangan yang terdokumentasi membentuk pemahaman umum tentang kegiatan yang akan dilakukan di antara para developer perangkat lunak dan membantu mereka mengembangkan perangkat lunak secara sistematis dan disiplin. Model proses pengembangan yang terdokumentasi, selain mencegah salah tafsir yang mungkin terjadi ketika proses pengembangan tidak didokumentasikan secara memadai, juga membantu mengidentifikasi inkonsistensi, redundansi, dan kelalaian dalam proses pengembangan. Saat ini, organisasi pengembangan perangkat lunak yang baik biasanya mendokumentasikan proses pengembangan mereka dalam bentuk buklet. Mereka mengharapkan para developer yang baru direkrut untuk organisasi mereka untuk terlebih dahulu menguasai proses pengembangan perangkat lunak mereka selama pelatihan induksi singkat yang harus mereka jalani.
Kriteria masuk dan keluar fase
SDLC yang baik selain secara jelas mengidentifikasi fase-fase yang berbeda dalam siklus hidup, harus secara jelas mendefinisikan kriteria masuk dan keluar untuk setiap fase. Kriteria masuk (atau keluar) fase biasanya dinyatakan sebagai serangkaian kondisi yang harus dipenuhi agar fase dapat dimulai (atau diselesaikan). Sebagai contoh, kriteria keluar fase untuk fase spesifikasi kebutuhan perangkat lunak, dapat berupa dokumen spesifikasi persyaratan perangkat lunak (SRS) sudah siap, telah ditinjau secara internal, dan juga telah ditinjau dan disetujui oleh pelanggan. Hanya setelah kriteria ini terpenuhi, fase berikutnya dapat dimulai.
Jika kriteria masuk dan keluar untuk berbagai fase tidak didefinisikan dengan baik, maka itu akan meninggalkan ruang yang cukup untuk ambiguitas dalam memulai dan mengakhiri berbagai fase, dan menyebabkan banyak kebingungan di antara para pengembang. Kadang-kadang mereka mungkin menghentikan aktivitas dalam suatu fase sebelum waktunya, dan di lain waktu mereka mungkin terus mengerjakan suatu fase jauh setelah fase itu seharusnya berakhir. Keputusan mengenai apakah suatu fase selesai atau tidak menjadi subyektif dan menjadi sulit bagi manajer proyek untuk secara akurat
mengatakan berapa banyak perkembangan telah berkembang. Ketika kriteria masuk dan keluar fase tidak didefinisikan dengan baik, developer mungkin menutup aktivitas fase jauh sebelum mereka benar-benar selesai, memberikan kesan palsu tentang kemajuan pesat.
Dalam hal ini, menjadi sangat sulit bagi manajer proyek untuk menentukan status pasti pengembangan dan melacak kemajuan proyek. Ini biasanya mengarah pada masalah yang biasanya diidentifikasi sebagai sindrom lengkap 99 persen. Sindrom ini muncul ketika manajer proyek perangkat lunak tidak memiliki cara yang pasti untuk menilai kemajuan suatu proyek, anggota tim yang optimis merasa bahwa pekerjaan mereka 99 persen selesai bahkan ketika pekerjaan mereka jauh dari penyelesaian—membuat semua proyeksi yang dibuat oleh proyek. manajer tentang waktu penyelesaian proyek menjadi sangat tidak akurat.