chapter 7 Integrating quality activities in the project life cycle 7.1 Metodologi Pengembangan Perangkat Lunak Classic dan Lainnya Empat model proses pengembangan perangkat lunak akan dibahas dalam bagian ini: Model Pengembangan Perangkat Lunak Life Cycle (Model SDLC) Model prototyping Model spiral Model berorientasi objek. Model Pengembangan Perangkat Lunak Life Cycle (model SDLC) adalah model klasik (masih berlaku saat ini), tetapi memberikan gambaran yang paling komprehensif dari proses yang tersedia. Model ini menampilkan blok bangunan utama untuk seluruh proses pengembangan, digambarkan sebagai urutan linier. Dalam fase awal dari proses pengembangan perangkat lunak, dokumen desain produk disiapkan, dengan versi pertama dari program komputer selesai dan disajikan untuk evaluasi pada tahap akhir dari proses. Model SDLC dapat berfungsi sebagai kerangka kerja di mana model-model lain yang disajikan. Model prototyping adalah didasarkan pada penggantian satu atau lebih fase model SDLC melalui proses evolusi, di mana prototipe perangkat lunak yang digunakan sebagai bahan komunikasi antara pengembang dan pengguna atau pelanggan. Prototip disampaikan kepada perwakilan pengguna untuk dievaluasi. Pengembang kemudian berlanjut pengembangan prototipe yang lebih canggih, yang juga diajukan untuk dievaluasi. Proses evolusi terus berlangsung sampai proyek software selesai atau prototipe perangkat lunak telah mencapai tahap yang diinginkan. Dalam hal ini, sisa dari proses pengembangan dapat dilakukan sesuai dengan metodologi yang berbeda, misalnya model SDLC klasik. Model spiral memberikan metodologi untuk menjamin kinerja yang efektif pada setiap tahap Model SDLC. Ini melibatkan proses iteratif yang mengintegrasikan komentar pelanggan dan persyaratan perubahan, analisis risiko dan resolusi, dan sistem perencanaan perangkat lunak dan kegiatan rekayasa. Satu atau lebih iterasi dari model spiral mungkin diperlukan untuk menyelesaikan setiap tahapan SDLC proyek. Tugas rekayasa yang terkait dapat dilakukan sesuai dengan salah satu model atau kombinasi dari mereka. Model berorientasi objek menggabungkan skala besar penggunaan kembali perangkat lunak dengan mengintegrasikan modul yang dapat digunakan kembali ke dalam sistem perangkat lunak baru. Dalam kasus di mana tidak ada modul perangkat lunak dapat digunakan kembali (disebut objek atau komponen) yang tersedia, pengembang dapat melakukan prototipe atau proses SDLC untuk melengkapi sistem perangkat lunak yang baru dikembangkan. 7.1.1 Model Pengembangan perangkat lunak siklus hidup (model SDLC) Pengembangan Perangkat Lunak Siklus Hidup klasik (SDLC) model adalah model sekuensial linier yang diawali dengan definisi persyaratan dan berakhir dengan sistem operasi rutin dan
pemeliharaan. Ilustrasi yang paling umum dari model SDLC adalah model air terjun, yang ditunjukkan pada Gambar 7.1. Model yang ditunjukkan pada Gambar 7.1 menyajikan proses tujuh fase, sebagai berikut: Definisi persyaratan. Untuk fungsi sistem perangkat lunak yang akan dikembangkan, pelanggan harus mendefinisikan kebutuhan mereka. Dalam banyak kasus sistem perangkat lunak adalah bagian dari sistem yang lebih besar. Informasi tentang bagian-bagian lain dari sistem diperluas membantu menjalin kerjasama antara tim dan mengembangkan komponen interface. Analisis. Upaya utama di sini adalah untuk menganalisis implikasi persyaratan untuk membentuk model perangkat lunak sistem awal. Desain. Tahap ini melibatkan definisi rinci dari output, input dan prosedur pengolahan, termasuk struktur data dan database, struktur perangkat lunak, dll Coding. Pada tahap ini, desain diterjemahkan ke dalam kode. Dalam coding diperlukan kegiatan jaminan kualitas seperti inspeksi, tes unit dan tes integrasi. Sistem tes. Tes sistem dilakukan setelah tahap pengkodean selesai. Tujuan utama dari pengujian adalah untuk menemukan kesalahan perangkat lunak sebanyak mungkin sehingga mencapai tingkat yang dapat diterima dari kualitas perangkat lunak. Sistem tes yang dilakukan oleh pengembang perangkat lunak sebelum perangkat lunak diberikan kepada pelanggan. Dalam banyak kasus pelanggan melakukan tes perangkat lunak independen untuk meyakinkan dirinya sendiri bahwa pengembang telah memenuhi
semua komitmen dan bahwa tidak ada reaksi perangkat lunak yang tidak diduga atau salah diantisipasi. Hal ini sangat umum bagi pelanggan untuk meminta pengembang untuk ikut serta dalam melakukan tes sistem bersama. Instalasi dan konversi. Setelah sistem perangkat lunak disetujui, sistem diinstal untuk yang berfungsi sebagai firmware, yaitu, sebagai bagian dari sistem informasi yang merupakan komponen utama dari sistem yang lebih luas. Jika sistem informasi yang baru untuk menggantikan sistem yang ada, proses software konversi harus dilakukan untuk memastikan bahwa kegiatan organisasi tak terganggu selama fase konversi. Operasional rutin dan pemeliharaan. Operasi software rutin dimulai setelah instalasi dan konversi telah selesai. Selama masa operasi rutin, yang biasanya berlangsung selama beberapa tahun atau sampai generasi perangkat lunak baru muncul, maka pemeliharaan diperlukan. Pemeliharaan menggabungkan tiga jenis layanan: perbaikan - perbaikan kesalahan perangkat lunak yang diidentifikasikan oleh pengguna selama operasi; adaptif - menggunakan fitur perangkat lunak yang ada untuk memenuhi persyaratan baru, dan perfektif - menambahkan fitur kecil baru untuk meningkatkan kinerja perangkat lunak. 7.1.2 Model Prototyping Model prototyping memanfaatkan (a) perkembangan teknologi informasi, yaitu, generator aplikasi canggih yang memungkinkan untuk pengembangan cepat dan mudah prototipe perangkat lunak, dikombinasikan dengan (b) partisipasi aktif dalam proses pengembangan dengan pelanggan dan pengguna mampu memeriksa dan mengevaluasi prototipe. Ketika menerapkan metodologi prototyping, calon pengguna diperlukan dalam mengomentari berbagai versi prototipe perangkat lunak yang disiapkan oleh pengembang. Dalam menanggapi komentar pelanggan dan pengguna, pengembang membetulkan prototipe untuk ditambahkan pada bagian sistem generasi atau versi berikutnya. Proses ini diulang sampai tujuan tercapai atau prototipe sistem perangkat lunak selesai. Sebuah model prototyping adalah ditunjukkan pada Gambar 7.2.
Prototyping dapat diterapkan dalam kombinasi dengan metodologi lain atau sebagai metodologi "berdiri sendiri". Dengan kata lain, tingkat prototipe dapat bervariasi, dari penggantian satu fase SDLC (atau metodologi lain) hingga untuk menyelesaikan prototipe seluruh sistem perangkat lunak. Prototyping sebagai metodologi pengembangan perangkat lunak yang telah ditemukan untuk menjadi efisien dan efektif terutama untuk proyek pengembangan perangkat lunak sekala kecil-menengah. Prototyping lawan metodologi SDLC - keuntungan dan kerugian (terutama untuk proyekproyek kecil hingga menengah) Keuntungan dari prototipe: Proses pengembangan yang lebih pendek Secara substansial dapat menghemat sumber daya pengembangan Lebih cocok untuk kebutuhan pelanggan dan mengurangi risiko kegagalan proyek Pemahaman pengguna terhadap sistem baru lebih mudah dan lebih cepat Kekurangan dari prototipe: Fleksibilitas dan kemampuan beradaptasi terhadap perubahan dan penambahan menurun
Mengurangi persiapan untuk kasus kegagalan tak terduga 7.1.3 Model spiral Model spiral, yang telah direvisi oleh Boehm (1988, 1998), menawarkan metodologi yang telah ditingkatkan untuk mengawasi proyek-proyek pengembangan besar dan lebih kompleks yang notabene dapat menghasilkan kegagalan yang lebih tinggi. Ini menggabungkan model iteratif yang memperkenalkan dan menekankan analisis risiko dan partisipasi pelanggan menjadi unsur-unsur utama dari SDLC dan metodologi prototyping. Menurut model spiral, yang ditunjukkan pada Gambar 7.3, pengembangan perangkat lunak dianggap menjadi proses berulang-ulang, pada setiap iterasi, kegiatan berikut dilakukan: Perencanaan Analisis risiko dan resolusi Rekayasa kegiatan sesuai dengan tahapan proyek: desain, coding, pengujian, instalasi dan release Evaluasi oleh pelanggan, termasuk komentar, perubahan dan persyaratan tambahan, dll
Sebuah model spiral canggih, Win-Win Spiral Model (Boehm, 1998), meningkatkan model Spiral (Boehm, 1988) lebih jauh. Model canggih memberikan penekanan ekstra pada komunikasi dan negosiasi antara pelanggan dan pengembang. Dengan demikian, dalam model spiral canggih, yang ditunjukkan pada Gambar 7.4, enam kegiatan berikut yang dilakukan dalam setiap iterasi: Persyaratan spesifikasi nasabah, komentar dan tuntutan perubahan Aktifitas perencanaan oleh pengembang Analisis dan resolusi risiko oleh pengembang Kegiatan desain oleh pengembang Kegiatan konstruksi oleh pengembang yang berkaitan dengan pengkodean, pengujian, instalasi dan release Evaluasi dari pelanggan 7.1.4 Model berorientasi objek Model berorientasi objek berbeda dari model-model lain dengan penggunaan kembali secara intensif dari komponen perangkat lunak. Metodologi ini ditandai dengan integrasi yang mudah dari modul perangkat lunak yang ada (komponen) ke dalam sistem perangkat lunak yang baru dikembangkan. Sekumpulan komponen perangkat lunak melayani tujuan ini dengan menyediakan komponen perangkat lunak untuk digunakan kembali.
Jadi, menurut model berorientasi objek seperti yang ditunjukkan pada Gambar 7.5, proses pengembangan dimulai dengan sebuah urutan analisis dan desain yang berorientasi objek. Tahap desain diikuti oleh memanfaatkan komponen yang sesuai dari kumpulan perangkat lunak (library) yang dapat digunakan kembali, bila tersedia. Salinan dari komponen software yang baru dikembangkan ini kemudian dimasukan ke library perangkat lunak untuk dapat digunakan kembali di masa depan. Diharapkan bahwa kumpulan komponen perangkat lunak yang semakin bertambah dalam library perangkat lunak yang dapat digunakan kembali dan meningkatkan perangkat lunak secara substansial, adalah sebuah tren yang akan memungkinkan dapat meningkatkan keuntungan lebih besar dari sumber daya sebagai berikut: Ekonomi - Biaya mengintegrasikan komponen perangkat lunak yang dapat digunakan kembali jauh lebih rendah dibandingkan biaya pengembangan komponen baru. Peningkatan kualitas - komponen software yang dapat digunakan kembali diharapkan lebih sedikit mengandung cacat dibanding komponen perangkat lunak yang baru dikembangkan, karena deteksi kesalahan sudah dilakukan oleh pengguna sebelumnya. Waktu pengembangan yang lebih pendek - Integrasi dari komponen software yang dapat digunakan kembali mengurangi tekanan terhadap penjadwalan. Dengan demikian, menguntungkan dari metodologi berorientasi objek dibanding metodologi lainnya adalah akan tumbuhnya jumlah perangkat lunak yang dapat digunakan kembali di masa depan.
7.2 Faktor yang secara intensif dapat mempengaruhi kegiatan jaminan kualitas dalam proses pengembangan Kegiatan jaminan kualitas siklus hidup proyek adalah berorientasi proses, dengan kata lain, terkait dengan penyelesaian sebuah fase proyek, penyelesaian tonggak proyek, dan sebagainya. Kegiatan jaminan kualitas akan diintegrasikan ke dalam rencana pengembangan yang mengimplementasikan satu atau lebih model pengembangan perangkat lunak - air terjun, prototyping, spiral, berorientasi objek atau model lainnya. Perencana jaminan kualitas untuk sebuah proyek diperlukan untuk menentukan: Daftar kegiatan jaminan kualitas yang diperlukan untuk sebuah proyek. Untuk setiap kegiatan jaminan kualitas: o Waktu o Jenis kegiatan jaminan kualitas yang akan diterapkan o Siapa yang melakukan kegiatan dan sumber daya yang diperlukan. o Sumber daya yang diperlukan untuk menghilangkan cacat dan perubahan. Faktor-faktor yang mempengaruhi intensitas keperluan dalam kegiatan jaminan kualitas faktor Proyek: Besaran proyek kompleksitas dan kesulitan Teknis Kuantitas komponen perangkat lunak yang dapat digunakan kembali Tingkat keparahan hasil akibat kegagalan proyek Tim faktor: Profesional kualifikasi anggota tim Tim kenalan dengan proyek dan pengalaman di daerah tersebut Ketersediaan anggota staf yang profesional dapat mendukung tim Keakraban dengan anggota tim, dengan kata lain persentase anggota staf baru dalam tim 7.3 Verifikasi, validasi dan kualifikasi Tiga aspek lain jaminan kualitas produk perangkat lunak adalah verifikasi, validasi dan kualifikasi. IEEE Std 610,12-1.990 (IEEE, 1990) mendefinisikan aspek-aspek sebagai berikut: "Verifikasi - Proses evaluasi sistem atau komponen untuk menentukan apakah produk dari tahap pengembangan yang diberikan memenuhi kondisi yang ditentukan pada awal fase itu." "Validasi - Proses evaluasi sistem atau komponen selama atau pada akhir dari proses pengembangan untuk menentukan apakah itu memenuhi persyaratan yang ditentukan."
"Kualifikasi - Proses yang digunakan untuk menentukan apakah sistem atau komponen cocok untuk penggunaan operasional." Sesuai dengan definisi IEEE, verifkasi memeriksa konsistensi dari produk yang akan dibangun dengan produk yang sudah dibangun pada fase sebelumnya. Validasi mewakili kepentingan pelanggan dengan cara memeriksa tingkat konsistensi terhadap persyaratan/keinginan asli mereka. Ulasan validasi yang komprehensif cenderung untuk meningkatkan kepuasan pelanggan terhadap sistem. Kualifikasi berfokus pada aspek operasional, di mana pemeliharaan adalah suatu masalah utama. Sebuah komponen perangkat lunak yang telah dikembangkan dan didokumentasikan sesuai dengan standar profesional dan gaya dan prosedur konvensi diharapkan akan jauh mempermudah propses perawatan/maintenance dibanding satu sistem yang memberikan improvisasi kode mengagumkan namun tidak mengikuti prosedur dan gaya pengkodean yang tidak dikenal dan sebagainya. Perencana yang diperlukan untuk menentukan aspek-aspek harus diperiksa dalam setiap kegiatan jaminan kualitas. 7.4 Sebuah model untuk efektivitas penghapusan cacat dan biaya SQA Model ini berkaitan dengan dua aspek kuantitatif dari rencana SQA terdiri dari beberapa kegiatan deteksi cacat: (1) Total rencana keefektifan dalam menghilangkan cacat proyek. (2) Biaya total penghapusan cacat proyek. Rencana itu sendiri adalah untuk diintegrasikan dalam proses pengembangan proyek. 7.4.1 Data Penerapan model ini didasarkan pada tiga jenis data, dijelaskan di bawah judul berikut. Distribusi Asal Cacat Cacat asal (fase di mana cacat diperkenalkan) didistribusikan di seluruh proses pengembangan, dari inisiasi proyek sampai selesai. Survei yang dilakukan oleh pengembang perangkat lunak besar, seperti IBM dan TRW, diringkas oleh Boehm (1981, Bab 24) dan Jones (1996, Bab 3), mengungkapkan pola yang sama dalam distribusi cacat. Pengembangan perangkat lunak profesional percaya bahwa pola ini tidak berubah secara substansial pada dua dekade terakhir. Sebuah distribusi karakteristik asal-usul cacat perangkat lunak, berdasarkan Boehm (1981) dan Jones (1996), ditunjukkan pada Tabel 7.3.
Efektivitas Penghapusan Cacat Hal ini diasumsikan bahwa setiap aktivitas jaminan kualitas memfilter sejumlah persentase tertentu dari cacat yang ada. Perlu dicatat bahwa dalam kebanyakan kasus, persentase penghapusan cacat agak lebih rendah dari persentase cacat yang terdeteksi. Cacat yang terdeteksi dan tidak terkoreksi, akan dibawah ke tahap pengembangan berikutnya. Biaya Penghapusan Cacat Data yang dikumpulkan tentang biaya pengembangan proyek menunjukkan bahwa biaya penghapusan cacat yang terdeteksi bervariasi menurut tahap pengembangan, sedangkan biaya perbaikan terus meningkat secara substansial sebagai hasil proses pengembangan. Misalnya, penghapusan cacat desain yang terdeteksi dalam tahap desain selama 2,5 hari kerja; proses penghapusan cacat tersebut mungkin memerlukan waktu 40 hari kerja ketiak tes dilakukan saat penerimaan. Rata-rata biaya penghapausan cacat, berdasarkan Boehm (1981) dan Pressman (2000, Bab 8), ditunjukkan pada Tabel 7.5.
7.4.2 Model Model ini didasarkan pada asumsi sebagai berikut: Proses pengembangan linear dan sekuensial, mengikuti model air terjun. Sejumlah cacat "baru" muncul dalam setiap tahap pengembangan. Lihat Tabel 7.3. Review dan kegiatan uji jaminan kualitas perangkat lunak berfungsi sebagai filter, menghapus beberapa persentase dari cacat yang ada dan membiarkan sisanya masuk ke fase perkembangan berikutnya. Ditunjukkan pada Tabel 7.4. Pada setiap fase, cacat masuk adalah jumlah cacat tidak dihapus oleh kegiatan jaminan mutu pada fase sebelumnya dengan cacat "baru" yang ditimbulkan pada tahap pengembangan yang sedang berlangsung. Biaya penghapusan cacat dihitung untuk setiap kegiatan jaminan kualitas dengan mengalikan jumlah cacat yang dihapus dengan biaya relatif untuk menghilangkan cacat (lihat Tabel 7.5). Cacat yang tersisa dan tidak diperbaiki, seterusnya akan ditemukan oleh pelanggan. Dalam situasi ini, penghapusan penuh terhadap cacat akan memerlukan biaya yang lebih mahal.