Rekayasa perangkat lunak pendekatan yang dijelaskan dalam buku ini bekerja ke arahsatu tujuan: untuk menghasilkan software yang berkualitas tinggi. Namun banyak pembaca akanditantang oleh pertanyaan: "Apakah kualitas perangkat lunak?"Philip Crosby [CRO79], dalam buku monumentalnya pada kualitas, menyediakan jawaban yang masampertanyaan ini:Masalah manajemen mutu adalah bukan apa yang orang tidak tahu tentang hal itu. Themasalahnya adalah apa yang mereka pikir mereka tahu. . .Dalam hal ini, kualitas memiliki banyak kesamaan dengan seks. Semua orang untuk itu. (Di bawahkondisi tertentu, tentu saja.) Setiap orang merasa mereka memahaminya. (Bahkan meskipun merekatidak ingin menjelaskannya) Setiap orang berpikir eksekusi. adalah hanya soal berikutkecenderungan alami. (Setelah semua, kita bergaul entah bagaimana.) Dan, tentu saja, kebanyakan orangmerasa bahwa masalah-masalah di wilayah tersebut yang disebabkan oleh orang lain. (Kalau saja mereka akanmeluangkan waktu untuk melakukan hal yang benar.)Beberapa pengembang perangkat lunak tetap percaya bahwa kualitas perangkat lunak adalah sesuatuAnda mulai khawatir setelah kode telah dihasilkan. Tidak ada yang bisalebih jauh dari kebenaran! Perangkat Lunak jaminan kualitas (SQA) merupakan kegiatan payung(Bab 2) yang diterapkan selama proses perangkat lunak.

Apa itu? Ini tidak cukup untukbicara bicara dengan mengatakan perangkat lunak yangkualitas adalah penting, Andaharus (1) secara eksplisit mendefinisikan apa yang dimaksud ketikaAnda mengatakan "kualitas perangkat lunak," (2) membuat setkegiatan yang akan membantu memastikan bahwa setiap perangkat lunakrekayasa pameran produk yang tinggi bekerjakualitas, (3) melakukan kegiatan jaminan kualitaspada setiap proyek software, (4) menggunakan metrik untukmengembangkan strategi untuk meningkatkan perangkat lunak Andaproses dan, sebagai konsekuensinya, kualitasproduk akhir.Siapa yang melakukan itu? Setiap orang yang terlibat dalam rekayasa perangkat lunakProses bertanggung jawab atas kualitas.Mengapa itu penting? Anda dapat melakukannya dengan benar, atau Anda dapatmelakukannya lagi. Jika tim software menekankan kualitasdalam semua kegiatan rekayasa perangkat lunak, mengurangijumlah pengerjaan ulang yang harus dilakukan. Bahwa hasilbiaya yang lebih rendah, dan yang lebih penting, peningkatanwaktu-ke-pasar.

Quick lookApa langkah-langkah? Sebelum jaminan kualitas perangkat lunakkegiatan dapat dimulai, penting untukdefine 'kualitas perangkat lunak' di sejumlah yang berbedatingkat abstraksi. Setelah Anda memahami apa yangkualitas, tim perangkat lunak harus mengidentifikasi satu setSQA kegiatan yang akan menyaring kesalahan dari produk kerjasebelum mereka meninggal dunia.Apakah produk kerja? Sebuah Jaminan Kualitas Perangkat LunakRencana dibuat untuk mendefinisikan sebuah tim softwareSQA strategi. Selama analisis, desain, dan kodegenerasi, produk SQA pekerjaan utama adalahformal review teknis ringkasan laporan. Selama pengujian,menguji rencana dan prosedurdiproduksi. Pekerjaan lain produkterkait dengan prosesperbaikan juga dapat dihasilkan.Bagaimana saya memastikan bahwa saya telah melakukan dengan benar? Carikesalahan sebelum mereka menjadi cacat! Artinya, bekerja untukmeningkatkan efisiensi cacat penghapusan Anda (Bab4 dan 7), sehingga mengurangi jumlah ulangbahwa tim perangkat lunak Anda harus melakukan

SQA meliputi (1) pendekatan manajemen mutu, (2) rekayasa perangkat lunak yang efektifteknologi (metode dan alat-alat), (3) formal teknis review yang diterapkanselama proses perangkat lunak, (4) strategi pengujian multitier, (5) kontrol perangkat lunakdokumentasi dan perubahan yang dibuat untuk itu, (6) prosedur untuk memastikan kepatuhandengan standar pengembangan perangkat lunak (bila ada), dan (7) pengukurandan mekanisme pelaporan.Dalam bab ini, kita fokus pada isu-isu manajemen dan proses kegiatan khususyang memungkinkan sebuah organisasi perangkat lunak untuk memastikan bahwa hal itu "hal yang benar padawaktu yang tepat dengan cara yang benar. "

8.1 KUALITAS CONCEPTS1Dikatakan bahwa tidak ada dua kepingan salju yang sama. Tentu saja ketika kita menonton saljujatuh sulit untuk membayangkan bahwa kepingan salju berbeda sama sekali, apalagi yang menyerpih masing-masing memilikistruktur yang unik. Dalam rangka untuk mengetahui perbedaan antara kepingan salju, kita

harus memeriksa spesimen erat, mungkin menggunakan kaca pembesar. Bahkan,lebih dekat kita melihat, perbedaan semakin kita dapat mengamati.Fenomena ini, variasi antara sampel, berlaku untuk semua produk manusia sebagaiserta penciptaan alam. Sebagai contoh, jika dua "identik" papan sirkuit diperiksadekat cukup, kita boleh mengamati bahwa jalur tembaga pada papan sedikit berbedadalam geometri, penempatan, dan ketebalan. Selain itu, lokasi dan diameterdibor lubang di papan bervariasi juga.Semua bagian rekayasa dan diproduksi menunjukkan variasi. Variasi antarasampel tidak mungkin jelas tanpa bantuan peralatan yang tepat untuk mengukurgeometri, listrik karakteristik, atau atribut lain dari bagian-bagian. Namun, denganinstrumen cukup sensitif, kita mungkin akan sampai pada kesimpulan bahwa tidak ada duasampel barang apapun yang persis sama.Variasi kontrol adalah jantung dari kontrol kualitas. Produsen A ingin meminimalkanvariasi di antara produk yang dihasilkan, bahkan ketika melakukan sesuatu yang relatifsederhana seperti menduplikasi disket. Tentunya, ini tidak dapat menjadi masalah-duplicattesting,menguji rencana dan prosedurdiproduksi. Pekerjaan lain produkterkait dengan prosesperbaikan juga dapat dihasilkan.Bagaimana saya memastikan bahwa saya telah melakukan dengan benar? Carikesalahan sebelum mereka menjadi cacat! Artinya, bekerja untukmeningkatkan efisiensi cacat penghapusan Anda (Bab4 dan 7), sehingga mengurangi jumlah ulangbahwa tim perangkat lunak Anda harus melakukan.

ing disket adalah operasi manufaktur sepele, dan kita bisa menjamin bahwa tepatduplikat dari perangkat lunak selalu dibuat.Atau bisa kita? Kita perlu memastikan trek ditempatkan pada disket dalamtoleransi ditetapkan sehingga mayoritas disk drive yang dapat membacadisket. Selain itu, kita perlu memastikan fluks magnet untuk membedakan noldari satu adalah cukup untuk membaca / menulis kepala untuk dideteksi. Disk duplikasi mesin inidapat, dan lakukan, keausan dan keluar dari toleransi. Jadi, bahkan sebuah "sederhana " proses seperti diskduplikasi dapat mengalami masalah karena variasi antara sampel.Tapi bagaimana ini berlaku untuk bekerja software? Bagaimana mungkin sebuah pengembangan perangkat lunakorganisasi perlu mengendalikan variasi? Dari satu proyek ke yang lain, kami ingin meminimalkanperbedaan antara sumber daya yang diperkirakan diperlukan untuk menyelesaikan sebuah proyekdan sumber daya aktual yang digunakan, termasuk staf, peralatan, dan waktu kalender. Secara umum,kami ingin pastikan program kami uji mencakup persentase diketahuiperangkat lunak, dari satu rilis ke rilis lain. Bukan hanya kita ingin meminimalkan

jumlah cacat yang dilepaskan ke lapangan, kami ingin memastikan bahwa variansjumlah bug juga diminimalkan dari satu rilis ke rilis lain. (kami pelanggankemungkinan akan marah jika rilis ketiga produk memiliki sepuluh kali cacat sebanyakrilis sebelumnya) Kami. ingin meminimalkan perbedaan dalam kecepatan dan ketepatantanggapan hotline kami dukungan terhadap permasalahan pelanggan. Daftar ini berjalan dan terus.

8.1.1 KualitasThe American Heritage Dictionary mendefinisikan kualitas sebagai "karakteristik atau atribut darisesuatu "Sebagai atribut item., kualitas mengacu pada karakteristik terukur-hal yang kita dapat dibandingkan dengan standar yang dikenal seperti panjang, warna, listriksifat, dan kelenturan. Namun, perangkat lunak, sebagian besar entitas intelektual, lebihmenantang untuk ciri dari benda-benda fisik.Namun demikian, pengukuran karakteristik suatu program memang ada. Properti initermasuk cyclomatic kompleksitas, kohesi, jumlah titik fungsi, baris kode,dan banyak lainnya, dibahas dalam Bab 19 dan 24. Ketika kita memeriksa item berdasarkankarakteristik terukur, dua jenis kualitas mungkin ditemui: kualitasdesain dan kualitas kesesuaian.Kualitas desain mengacu pada karakteristik yang desainer menentukan untuk item. Thegrade spesifikasi bahan, toleransi, dan kinerja semua berkontribusi terhadapkualitas desain. Sebagai bahan-kelas yang lebih tinggi digunakan toleransi, lebih kencang dan lebih besartingkat kinerja ditentukan, kualitas desain produk meningkat, jikaproduk diproduksi sesuai dengan spesifikasi.Kualitas kesesuaian adalah tingkat dimana spesifikasi desain diikutiselama manufaktur. Sekali lagi, semakin besar tingkat kesesuaian, makin tinggiadalah tingkat kualitas kesesuaian.Dalam pengembangan perangkat lunak, kualitas desain mencakup persyaratan, spesifikasi,dan desain dari sistem. Kualitas kesesuaian adalah masalah fokus

terutama pada implementasi. Jika implementasi mengikuti desain dan yang dihasilkansistem memenuhi persyaratan dan tujuan kinerja, kualitas kesesuaian adalahtinggi.Tapi apakah kualitas desain dan kualitas kesesuaian hanya masalah perangkat lunakinsinyur harus mempertimbangkan? Robert Glass [GLA98] berpendapat bahwa lebih "intuitif" hubunganadalah dalam rangka:Pengguna kepuasan = kualitas produk + baik compliant +pengiriman dalam anggaran dan jadwalDi bottom line, Glass berpendapat kualitas yang penting, tetapi jika pengguna tidak puas,ada lagi yang benar-benar penting. DeMarco [DEM99] memperkuat pandangan ini ketika ia

menyatakan: "mutu A produk adalah fungsi dari berapa mengubah dunia untuklebih baik. "berpendapat Pandangan kualitas yang jika produk perangkat lunak menyediakan substansialmanfaat untuk-pengguna akhir, mereka mungkin bersedia untuk mentolerir keandalan sesekali atau kinerjamasalah.8.1.2 Pengendalian MutuVariasi kontrol mungkin disamakan dengan kontrol kualitas. Tetapi bagaimana kita mencapai kualitaskontrol? Kontrol kualitas melibatkan serangkaian inspeksi, review, dan tes yang digunakanseluruh proses software untuk memastikan setiap produk memenuhi persyaratan kerjaditempatkan di atasnya. Kontrol kualitas mencakup loop umpan balik kepada proses yangmenciptakan produk kerja. Kombinasi pengukuran dan umpan balik memungkinkan kitauntuk menyempurnakan proses ketika produk kerja yang diciptakan gagal untuk memenuhi spesifikasi mereka.Pendekatan ini pandangan kendali mutu sebagai bagian dari proses manufaktur.kegiatan pengendalian Kualitas mungkin sepenuhnya otomatis, seluruhnya manual, atau kombinasialat otomatis dan interaksi manusia. Sebuah konsep kunci dari pengendalian kualitas adalahbahwa semua produk kerja telah menetapkan, spesifikasi terukur yang kita dapat membandingkanoutput dari setiap proses. Loop umpan balik sangat penting untuk meminimalkancacat yang dihasilkan.8.1.3 Jaminan KualitasJaminan kualitas terdiri dari audit dan fungsi pelaporan manajemen.Tujuan jaminan kualitas adalah untuk memberikan manajemen dengan data yang diperlukan untukinformasi akan tentang kualitas produk, sehingga memperoleh wawasan dan keyakinan bahwa produkkualitas pertemuan tujuannya. Tentu saja, jika data yang diberikan melalui jaminan kualitasmengidentifikasi masalah, adalah tanggung jawab manajemen untuk mengatasi masalahdan menerapkan sumber daya yang diperlukan untuk menyelesaikan masalah kualitas.8.1.4 Biaya KualitasBiaya kualitas meliputi seluruh biaya yang terjadi dalam mengejar kualitas atau dalam menjalankankualitas kegiatan terkait. Biaya studi kualitas dilakukan untuk memberikan baris untuk biaya saat ini kualitas, mengidentifikasi peluang untuk mengurangi biaya kualitas,dan memberikan dasar perbandingan normal. Dasar normalisasihampir selalu dolar. Setelah kami telah dinormalisasi biaya kualitas secara dolar, kitamemiliki data yang diperlukan untuk mengevaluasi di mana kesempatan berbohong untuk memperbaiki kamiproses. Selanjutnya, kita dapat mengevaluasi pengaruh perubahan dalam dolar berbasis.Kualitas biaya dapat dibagi menjadi biaya yang terkait dengan pencegahan, penilaian, dankegagalan. Biaya Pencegahan meliputi• perencanaan mutu• tinjauan teknis formal• alat uji• PelatihanBiaya Penilaian meliputi kegiatan untuk mendapatkan wawasan tentang kondisi produk waktu "pertama

melalui "setiap proses. Contoh biaya penilaian termasuk• dalam proses dan inspeksi interprocess• peralatan kalibrasi dan pemeliharaan• pengujianBiaya Kegagalan adalah mereka yang akan hilang jika tidak ada cacat muncul sebelum pengapalanproduk kepada pelanggan. Biaya Kegagalan dapat dibagi menjadi biaya kegagalan internal danBiaya kegagalan eksternal. Biaya kegagalan internal terjadi ketika kita mendeteksi cacatproduk kami sebelum pengiriman. Biaya kegagalan internal meliputi• ulang• perbaikan• Analisis mode kegagalanBiaya kegagalan eksternal berhubungan dengan cacat yang ditemukan setelah produk telahdikirim ke pelanggan. Contoh biaya kegagalan eksternal adalah• Resolusi keluhan• Produk kembali dan penggantian• membantu garis dukungan• Garansi kerjaSeperti yang diharapkan, biaya relatif untuk menemukan dan memperbaiki cacat meningkat secara dramatis karenakita pergi dari pencegahan untuk mendeteksi kegagalan internal untuk biaya kegagalan eksternal. Gambar8.1, berdasarkan data yang dikumpulkan oleh Boehm [BOE81] dan lain-lain, menggambarkan fenomena ini.Data anekdotal dilaporkan oleh Kaplan, Clark, dan Tang [KAP95] memperkuat sebelumnya biayaStatistik dan didasarkan pada pekerjaan di fasilitas pengembangan IBM Rochester

8.2 GERAKAN KUALITASHari ini, manajer senior di perusahaan industri di seluruh dunia mengakuiyang menerjemahkan produk berkualitas tinggi dengan biaya tabungan dan garis bawah ditingkatkan.Namun, ini tidak selalu terjadi. Gerakan kualitas dimulai pada tahun 1940-andengan pekerjaan seminalis W. Edwards Deming [DEM86] dan telah uji pertama benar diJepang. Menggunakan ide-ide Deming sebagai suatu landasan, Jepang mengembangkan sistematispendekatan penghapusan akar penyebab cacat produk. Sepanjang 1970-an dan 1980-an, pekerjaan mereka bermigrasi ke dunia barat dan diberi nama seperti "manajemen mutu total" (TQM) .2 Meskipun terminologi berbeda antar berbagai perusahaan dan penulis, sebuah perkembangan empat langkah dasar biasanya dihadapi dan bentuk-bentuk dasar dari setiap program TQM yang baik. Langkah pertama, yang disebut kaizen, mengacu pada sistem proses perbaikan yang berkesinambungan.

Tujuan kaizen adalah untuk mengembangkan proses (dalam hal ini, proses perangkat lunak) yang terlihat, diulang, dan terukur. Langkah kedua, dipanggil hanya setelah kaizen telah dicapai, disebut atarimae hinshitsu. Langkah ini membahas berwujud yang mempengaruhi proses dan bekerja untuk mengoptimalkan dampaknya pada proses. Sebagai contoh, proses perangkat lunak mungkin akan terpengaruh oleh pergantian staf tinggi, yang itu sendiri disebabkan oleh reorganisasi konstan dalam perusahaan. Mungkin struktur organisasi yang stabil bisa berbuat banyak untuk meningkatkan kualitas perangkat lunak. hinshitsu Atarimae akan menyebabkan manajemen untuk menyarankan perubahan dalam cara reorganisasi terjadi. Sementara dua langkah pertama fokus pada proses, langkah berikutnya, yang disebut Kansei (diterjemahkan sebagai "panca indera"), berkonsentrasi pada pengguna produk (dalam hal ini, perangkat lunak). Pada intinya, dengan memeriksa cara pengguna menerapkan Kansei produk mengarah ke perbaikan dalam produk itu sendiri dan, berpotensi, untuk proses yang menciptakannya. Akhirnya, langkah yang disebut hinshitsu miryokuteki memperluas perhatian manajemen luar produk langsung. Ini adalah langkah berorientasi bisnis yang mencari peluang bidang yang terkait diidentifikasi dengan mengamati penggunaan produk di pasar. Dalam dunia perangkat lunak, hinshitsu miryokuteki mungkin dipandang sebagai upaya untuk mengungkap baru dan menguntungkan produk atau aplikasi yang merupakan perkembangan dari yang ada sistem berbasis komputer. Bagi kebanyakan perusahaan kaizen harus menjadi perhatian segera. Sampai perangkat lunak dewasa proses (Bab 2) telah tercapai, tidak ada gunanya di pindah ke berikutnya langkah. 8.3 JAMINAN KUALITAS PERANGKAT LUNAK Bahkan pengembang perangkat lunak yang paling letih akan setuju bahwa software yang berkualitas tinggi adalah penting tujuan. Tapi bagaimana kita mendefinisikan kualitas? mengipaskan Seorang pernah berkata, "Setiap program tidak sesuatu yang benar, itu hanya mungkin bukan hal yang kita inginkan. " Banyak definisi kualitas perangkat lunak telah diusulkan dalam literatur. Untuk kami tujuan, kualitas perangkat lunak didefinisikan sebagai Kesesuaian untuk secara eksplisit dinyatakan persyaratan fungsional dan kinerja, secara eksplisit didokumentasikan pengembangan standar, dan karakteristik implisit yang diharapkan dari semua profesional mengembangkan perangkat lunak. 199 2 Lihat [ART92] untuk pembahasan yang komprehensif TQM dan penggunaannya

Ada sedikit pertanyaan bahwa definisi ini dapat diubah atau diperpanjang. Bahkan, sebuahdefinisi definitif kualitas perangkat lunak bisa diperdebatkan tanpa henti. Untuk tujuanbuku ini, definisi yang berfungsi untuk menekankan tiga poin penting:1. Persyaratan Perangkat Lunak adalah fondasi dari mana kualitas diukur.Kurangnya kesesuaian dengan persyaratan adalah kurangnya kualitas.2. standar Ditentukan mendefinisikan seperangkat kriteria pembangunan yang menjadi pedoman cara yangdi mana perangkat lunak direkayasa. Jika kriteria tersebut tidak diikuti, kurangnyakualitas akan hampir pasti terjadi.3. Satu set persyaratan implisit sering berjalan tidak disebutkan (misalnya, keinginan untukkemudahan penggunaan dan rawatan yang baik). Jika perangkat lunak sesuai dengan eksplisitpersyaratan, namun gagal untuk memenuhi persyaratan implisit, kualitas perangkat lunak adalah tersangka.8.3.1 Latar Belakang MasalahJaminan Mutu adalah kegiatan penting untuk setiap bisnis yang memproduksi produk untukdigunakan oleh orang lain. Sebelum abad kedua puluh, jaminan kualitas adalah satu-satunyatanggung jawab perajin yang membangun suatu produk. Jaminan kualitas pertama formaldan fungsi kontrol diperkenalkan di Bell Labs pada 1916 dan menyebar dengan cepatseluruh dunia manufaktur. Selama tahun 1940-an, lebih formal pendekatan untukkontrol kualitas yang disarankan. Ini didasarkan pada pengukuran dan proses yang berkesinambunganperbaikan sebagai elemen kunci dari manajemen mutu.Saat ini, setiap perusahaan memiliki mekanisme untuk menjamin mutu produk-produknya. Bahkan,laporan eksplisit perhatian perusahaan untuk kualitas telah menjadi taktik pemasaranselama beberapa dekade terakhir.Sejarah jaminan mutu dalam pengembangan perangkat lunak sejajar dengan sejarahkualitas di bidang manufaktur hardware. Selama hari-hari awal komputasi (1950-an dan1960), kualitas adalah tanggung jawab programmer. Standar kualitasjaminan untuk perangkat lunak diperkenalkan dalam pengembangan perangkat lunak kontrak militerselama 1970-an dan telah menyebar dengan cepat ke dalam pengembangan perangkat lunak di komersialdunia [IEE94]. Memperluas definisi yang disajikan sebelumnya, kualitas perangkat lunakjaminan adalah "pola yang terencana dan sistematis tindakan" [SCH98] yang diperlukanuntuk memastikan kualitas tinggi dalam perangkat lunak. Ruang lingkup tanggung jawab jaminan mutu mungkinterbaik akan ditandai dengan parafrase komersial mobil sekali-populer: "KualitasApakah Ayub # 1. "Implikasi untuk perangkat lunak adalah bahwa berbagai konstituen banyakjaminan kualitas perangkat lunak tanggung jawab-perangkat lunak insinyur, manajer proyek,pelanggan, tenaga penjual, dan individu yang melayani dalam grup SQA.Kelompok SQA berfungsi sebagai perwakilan di-rumah pelanggan. Artinya, orang-orangyang melakukan SQA harus melihat perangkat lunak dari titik pandang pelanggan.Apakah perangkat lunak cukup memenuhi faktor kualitas mencatat dalam Bab 19?

Software pembangunan dilakukan sesuai dengan standar yang ditetapkan sebelumnya? Memilikidisiplin teknis dilakukan dengan benar peran mereka sebagai bagian dari aktivitas SQA? Theupaya kelompok SQA untuk menjawab ini dan pertanyaan lain untuk memastikan perangkat lunak yangmutu dipelihara.8.3.2 Aktivitas SQASoftware jaminan kualitas terdiri dari berbagai tugas yang berhubungan dengan dua yang berbedakonstituen-perangkat lunak insinyur yang melakukan pekerjaan teknis dan SQAkelompok yang memiliki tanggung jawab untuk perencanaan jaminan kualitas, pengawasan, pencatatan,analisis, dan pelaporan.insinyur Perangkat Lunak alamat kualitas (dan melaksanakan jaminan kualitas dan kualitaspengendalian kegiatan) dengan menerapkan metode teknis yang solid dan tindakan, melakukan formaltinjauan teknis, dan melakukan pengujian perangkat lunak yang terencana dengan baik. Hanya reviewdibahas dalam bab ini. Teknologi topik yang dibahas di Bagian Tiga melaluiLima dari buku ini.Piagam dari kelompok SQA adalah untuk membantu tim software dalam mencapai suatu highqualityproduk akhir. Rekayasa Perangkat Lunak Institut [PAU93] merekomendasikan menetapkanaktivitas SQA yang membahas perencanaan jaminan kualitas, pengawasan, pencatatan,analisis, dan pelaporan. Kegiatan ini dilakukan (atau difasilitasi) oleh seorang independenSQA kelompok yang:Menyiapkan rencana SQA untuk sebuah proyek. Program ini dikembangkan selama perencanaan proyekdan direview oleh semua pihak yang berkepentingan. kegiatan jaminan mutu yang dilakukanoleh tim rekayasa perangkat lunak dan kelompok SQA diatur oleh rencana. Themengidentifikasi rencana• evaluasi yang dilakukan• audit dan review yang akan dilakukan• standar yang berlaku untuk proyek• prosedur pelaporan dan pelacakan kesalahan• Dokumen yang dihasilkan oleh kelompok SQA• Jumlah umpan balik yang diberikan kepada tim proyek perangkat lunakBerpartisipasi dalam pengembangan deskripsi proses proyek perangkat lunak.Tim perangkat lunak memilih proses untuk pekerjaan yang akan dilakukan. The SQAreview grup deskripsi proses untuk kesesuaian dengan kebijakan organisasi,standar perangkat lunak internal, eksternal dikenakan standar (misalnya, ISO-9001), dan lainnyabagian dari rencana proyek perangkat lunak.kegiatan rekayasa perangkat lunak Tinjauan untuk memverifikasi sesuai dengan yang ditetapkanproses software. Kelompok SQA mengidentifikasi, dokumen, dan trek penyimpangan dariproses dan memverifikasi bahwa koreksi telah dibuat.

Audit produk perangkat lunak yang ditunjuk bekerja untuk memverifikasi kepatuhan terhadap didefinisikan sebagai bagian dari proses perangkat lunak. Kelompok SQA review pekerjaan yang dipilih

produk; mengidentifikasi, dokumen, dan trek penyimpangan; memverifikasi bahwa koreksi telah telah dibuat, dan secara berkala melaporkan hasil kerja kepada manajer proyek. Memastikan bahwa penyimpangan dalam pekerjaan perangkat lunak dan produk kerja didokumentasikan dan ditangani sesuai dengan prosedur yang terdokumentasi. Penyimpangan mungkin ditemui dalam rencana proyek, uraian proses, standar yang berlaku, atau pekerjaan teknis produk. Records setiap ketidakpatuhan dan laporan kepada manajemen senior. Ketidakpatuhan item dilacak sampai mereka diselesaikan. Selain kegiatan tersebut, kelompok SQA mengkoordinasikan DNS dan manajemen perubahan (Bab 9) dan membantu untuk mengumpulkan dan menganalisis metrik perangkat lunak. 8.4 SOFTWARE ULASAN ulasan Perangkat lunak adalah "filter" bagi proses rekayasa perangkat lunak. Artinya, tinjauan diterapkan pada berbagai titik selama pengembangan perangkat lunak dan berfungsi untuk mengungkap kesalahan dan cacat yang kemudian dapat dihapus. Software review "memurnikan" rekayasa perangkat lunak kegiatan yang kita sebut analisis, desain, dan coding. Freedman dan Weinberg [FRE90] mendiskusikan kebutuhan untuk review seperti ini: pekerjaan Teknis meninjau kebutuhan untuk alasan yang sama yang perlu penghapus pensil: Melakukan kesalahan adalah manusia. Alasan kedua yang kita butuhkan tinjauan teknis adalah bahwa walaupun orang pandai penangkapan beberapa kesalahan mereka sendiri, kelas besar kesalahan melarikan diri originator lebih mudah dari mereka melarikan diri orang lain. Proses review tersebut, oleh karena itu, jawaban doa Robert Burns: O gumpalan beberapa kekuatan giftie memberi kami untuk melihat diri kita sebagai lain melihat kami Review-review apapun-adalah cara menggunakan keragaman dari sekelompok orang untuk: 1. Jelaskan diperlukan perbaikan dalam produk satu orang atau tim; 2. Konfirmasi bagian-bagian dari produk di mana perbaikan yang baik tidak diinginkan atau tidak dibutuhkan; 3. Mencapai pekerjaan teknis yang lebih seragam, atau setidaknya lebih diprediksi, kualitas daripada yang dapat dicapai tanpa review, dalam rangka untuk membuat pekerjaan teknis lebih mudah ditangani. Banyak jenis review dapat dilakukan sebagai bagian dari rekayasa perangkat lunak. Masing-masing memiliki tempatnya. Sebuah pertemuan informal di sekitar mesin kopi merupakan bentuk review, jika masalah teknis yang dibahas. Sebuah presentasi formal perancangan perangkat lunak kepada para pelanggan, manajemen, dan staf teknis juga merupakan bentuk review. Dalam buku ini, bagaimanapun, kami fokus pada kajian teknis formal, kadang-kadangdisebut sebagai panduan atau inspeksi. Sebuah tinjauan teknis formal yang paling efektiffilter dari sudut pandang jaminan kualitas. Dilakukan oleh para insinyur perangkat lunak (dan

lainnya) untuk perangkat lunak insinyur, FTR merupakan cara yang efektif untuk meningkatkan perangkat lunakkualitas.8.4.1 Biaya Dampak Kerusakan SoftwareStandar IEEE Kamus Istilah Listrik dan Elektronika (IEEE 100 Standard -1992) mendefinisikan cacat sebagai "produk anomali." Definisi untuk kesalahan dalam perangkat keraskonteks dapat ditemukan dalam Standar IEEE 610,12-1.990:(A) cacat dalam sebuah perangkat keras atau komponen, misalnya, sebuah sirkuit pendek atau rusakkawat. (B) tahapan proses, salah, atau definisi data dalam program komputer. Catatan: IniDefinisi ini digunakan terutama oleh disiplin toleransi kesalahan. Dalam penggunaan umum, istilah"Kesalahan" dan "bug" digunakan untuk mengungkapkan makna ini. Lihat juga: kesalahan data-sensitif; programsensitivekesalahan, kesalahan setara; masking kesalahan, kesalahan berselang.Dalam konteks proses perangkat lunak, istilah cacat dan kesalahan adalah sama.Keduanya menyiratkan masalah kualitas yang ditemukan setelah perangkat lunak telahdirilis ke pengguna akhir (atau kegiatan lain dalam proses perangkat lunak). Dalam bab-bab sebelumnya,kita menggunakan istilah kesalahan untuk menggambarkan masalah kualitas yang ditemukan oleh perangkat lunakinsinyur (atau lainnya) sebelum perangkat lunak dilepas ke pengguna akhir (atau keaktivitas dalam proses perangkat lunak).Tujuan utama dari tinjauan teknis formal adalah untuk menemukan kesalahan selama prosessehingga mereka tidak menjadi cacat setelah merilis perangkat lunak. Manfaat jelastinjauan teknis formal adalah penemuan awal kesalahan sehingga mereka tidak menyebarkanke langkah berikutnya dalam proses perangkat lunak.Sejumlah penelitian industri (oleh TRW, Nippon Electric, Mitre Corp, antara lain)menunjukkan bahwa kegiatan desain memperkenalkan persen antara 50 dan 65 dari semua kesalahan(Dan akhirnya, semua cacat) selama proses perangkat lunak. Namun, teknik tinjauan resmitelah terbukti sampai 75 persen efektif [JON86] dalam mengungkap desainkekurangan. Dengan mendeteksi dan menghapus sebagian besar kesalahan ini, proses peninjauansecara substansial mengurangi biaya langkah-langkah berikutnya dalam pengembangan dan dukunganfase.Untuk menggambarkan dampak biaya deteksi dini kesalahan, kami mempertimbangkan serangkaian relatifbiaya yang didasarkan pada data biaya aktual yang dikumpulkan untuk proyek software besar[IBM81] .3 Asumsikan bahwa kesalahan ditemukan selama desain akan biaya 1,0 satuan mata uanguntuk memperbaiki. Sehubungan dengan biaya ini, kesalahan yang sama ditemukan tepat sebelum pengujian dimulaiakan biaya 6,5 unit; selama pengujian, 15 unit, dan setelah rilis, antara 60 dan100 unit.

8.4.2 Cacat Amplifikasi dan PenghapusanSebuah model amplifikasi cacat [IBM81] dapat digunakan untuk menggambarkan generasi dandeteksi kesalahan selama desain awal, perancangan detail, dan langkah-langkah codingdari proses rekayasa perangkat lunak. Model ini diilustrasikan pada Gambar skematis8.2. Sebuah kotak merupakan langkah pengembangan perangkat lunak. Selama langkah ini, mungkin kesalahansecara tidak sengaja dihasilkan. Review mungkin gagal untuk menemukan kesalahan yang baru dibuat dankesalahan dari langkah sebelumnya, sehingga beberapa nomor kesalahan yang lewat.Dalam beberapa kasus, kesalahan melewati dari langkah sebelumnya diperkuat (amplifikasifaktor, x) dengan pekerjaan saat ini. Subdivisi kotak mewakili masing-masing karakteristikdan persen efisiensi untuk mendeteksi kesalahan, fungsi dari ketelitian yangtinjauan.Gambar 8.3 mengilustrasikan sebuah contoh hipotetis amplifikasi cacat untuk perangkat lunakproses pembangunan di mana tidak ada review dilakukan. Mengacu pada gambar, masing-masinglangkah uji diasumsikan untuk mengungkap dan benar 50 persen dari semua kesalahan yang masuk tanpamemperkenalkan kesalahan baru (asumsi optimis). Sepuluh desain awalcacat diperkuat untuk 94 kesalahan sebelum pengujian dimulai. Dua belas kesalahan laten yangdirilis ke lapangan. Gambar 8.4 mempertimbangkan kondisi yang sama, kecuali desain itu danUlasan kode dilakukan sebagai bagian dari setiap langkah pembangunan. Dalam hal ini, sepuluh awalkesalahan desain awal yang diperkuat dengan 24 error sebelum pengujian dimulai.Hanya tiga kesalahan laten ada. Mengingat biaya relatif yang terkait dengan penemuandan koreksi kesalahan, biaya keseluruhan (dengan dan tanpa ulasan untuk hipotetis kamimisalnya) dapat dibentuk. Jumlah kesalahan ditemukan pada setiaplangkah-langkah dicatat dalam Angka 8,3 dan 8,4 dikalikan dengan biaya untuk menghapus kesalahan(Unit biaya 1,5 untuk desain, unit biaya 6,5 sebelum ujian, unit biaya 15 selama pengujian, dan 67biaya unit setelah rilis). Dengan menggunakan data tersebut, total biaya untuk pengembangan dan pemeliharaansaat review dilakukan adalah 783 unit biaya. Bila tidak ada review yang dilakukan,total biaya adalah 2177 unit-hampir tiga kali lebih mahal.Untuk melakukan review, software engineer harus mengeluarkan waktu dan usaha danpengembangan organisasi harus mengeluarkan uang. Namun, hasil sebelumnyacontoh meninggalkan sedikit keraguan bahwa kita bisa membayar sekarang atau membayar jauh lebih kemudian.

8,5 TEKNIS ULASAN FORMALSebuah tinjauan teknis formal adalah jaminan kualitas perangkat lunak kegiatan yang dilakukan oleh perangkat lunak

insinyur (dan lainnya). Tujuan FTR adalah (1) untuk mengungkap kesalahan dalamfungsi, logika, atau implementasi untuk setiap representasi dari perangkat lunak; (2) untuk memverifikasi bahwa perangkat lunak yang sedang diperiksa memenuhi persyaratan tersebut; (3) untuk memastikan bahwa perangkat lunaktelah diwakili sesuai dengan standar yang telah ditetapkan, (4) untuk mencapai perangkat lunak yangdikembangkan secara seragam, dan (5) untuk membuat proyek lebih mudah dikelola. Selain itu,FTR berfungsi sebagai tempat pelatihan, memungkinkan insinyur junior untuk mengamati berbedapendekatan untuk analisis perangkat lunak, desain, dan implementasi. FTR juga melayaniuntuk mempromosikan backup dan kontinuitas karena sejumlah orang menjadi akrab denganbagian dari perangkat lunak yang mereka tidak mungkin telah dinyatakan terlihat.FTR itu sebenarnya adalah kelas review yang meliputi walkthrough, inspeksi,round-robin review dan penilaian kelompok kecil lainnya teknis dari perangkat lunak. SetiapFTR dilakukan sebagai pertemuan dan akan berhasil hanya jika benar direncanakan,dikendalikan, dan dihadiri. Dalam bagian berikut, pedoman mirip dengan yang untukwalkthrough [FRE90], [GIL93] disajikan sebagai suatu tinjauan teknis perwakilan formal.8.5.1 Rapat ReviewTerlepas dari format FTR yang dipilih, setiap pertemuan kajian harus mematuhikendala berikut:• Antara tiga dan lima orang (biasanya) harus terlibat dalam pemeriksaan.• Advance persiapan harus dilakukan tetapi harus membutuhkan tidak lebih dari duajam kerja untuk setiap orang.• Durasi pertemuan kajian harus kurang dari dua jam.Mengingat kendala tersebut, harus jelas bahwa FTR sebuah berfokus pada tertentu (dankecil) bagian dari perangkat lunak secara keseluruhan. Sebagai contoh, daripada mencoba untuk meninjau sebuahdesain keseluruhan, walkthrough dilakukan untuk setiap komponen atau kelompok kecilkomponen. Dengan fokus penyempitan, yang FTR memiliki kemungkinan yang lebih tinggi mengungkap kesalahan.Fokus FTR adalah pada sebuah produk kerja (misalnya, sebagian dari spesifikasi kebutuhan,desain rinci komponen, kode sumber daftar untuk komponen a). Theindividu yang telah mengembangkan produk kerja-produser-menginformasikan proyekpemimpin yang bekerja adalah produk lengkap dan yang review diperlukan. Proyekkontak pemimpin pemimpin review, yang mengevaluasi produk untuk kesiapan, menghasilkansalinan bahan produk, dan mendistribusikan mereka untuk tinjauan dua atau tiga untuk mukapersiapan. Setiap resensi diharapkan untuk menghabiskan antara satu dan dua jam meninjauproduk, membuat catatan, dan sebaliknya menjadi akrab dengan pekerjaan. Bersamaan,pemimpin review juga review produk dan menetapkan agenda untukpertemuan kajian, yang biasanya dijadwalkan untuk hari berikutnya.Pertemuan review tersebut dihadiri oleh pemimpin review, semua reviewer, dan produser.Salah satu tinjauan mengambil peran perekam, yaitu, individuyang mencatat (secara tertulis) semua isu penting yang muncul selama pemeriksaan. FTR dimulaidengan pengenalan agenda dan pengenalan singkat oleh produser. Produsen

kemudian mulai "berjalan melalui" produk kerja, menjelaskan materi,sedangkan tinjauan mengangkat isu berdasarkan persiapan muka mereka. Ketika berlaku masalahatau kesalahan ditemukan, perekam catatan masing-masing.

Pada akhir review, semua peserta dari FTR harus memutuskan apakah akan (1) menerimaproduk tanpa modifikasi lebih lanjut, (2) menolak produk karena kesalahan berat(Sekali dikoreksi, review lain harus dilakukan), atau (3) menerima produk sementara(Kesalahan kecil telah ditemukan dan harus dikoreksi, tapi tidak ada tambahanreview akan diperlukan). Keputusan dibuat, semua peserta FTR menyelesaikansign-off, menunjukkan partisipasi mereka dalam tinjauan dan persetujuan mereka denganmeninjau temuan tim.Review 8.5.2 Pelaporan dan Penyimpanan CatatanSelama FTR, seorang penulis resensi (perekam) aktif mencatat semua masalah yang telahterangkat. Ini diringkas pada akhir pertemuan kajian dan isu tinjauandaftar diproduksi. Selain itu, ringkasan laporan review teknis formal selesai.Sebuah laporan ringkasan memeriksa jawaban tiga pertanyaan:1. Apa yang ditinjau?2. Siapa yang ditinjau itu?3. Apa temuan dan kesimpulan?Ringkasan laporan review adalah bentuk halaman (dengan lampiran mungkin). Inimenjadi bagian dari catatan sejarah proyek dan dapat didistribusikan ke proyekpemimpin dan pihak lain yang berkepentingan.Tinjauan masalah daftar melayani dua tujuan: (1) mengidentifikasi masalah dalamproduk dan (2) untuk melayani sebagai daftar item tindakan yang memandu produsen sebagai koreksidibuat. Sebuah daftar masalah biasanya menempel pada ringkasan laporan.Sangat penting untuk menetapkan prosedur-tindak lanjut untuk memastikan bahwa item pada isu-isudaftar sudah benar dikoreksi. Kecuali ini dilakukan, adalah mungkin bahwa masalah yang diangkatdapat "jatuh antara retak." adalah Satu pendekatan untuk menetapkan tanggung jawab untuk ikutankepada pemimpin review.8.5.3 Petunjuk tentang TinjauanPedoman untuk melakukan tinjauan teknis formal harus didirikan di muka,didistribusikan kepada semua tinjauan, disepakati, dan kemudian diikuti. Sebuah review yang tidak terkendalisering bisa lebih buruk bahwa ada ulasan sama sekali. Berikut adalah minimumseperangkat pedoman untuk review teknis formal:1. Review produk, bukan produsen. FTR Sebuah melibatkan orang dan ego. Melakukanbenar, FTR harus meninggalkan semua peserta dengan perasaan hangatprestasi. Dilakukan dengan benar, FTR bisa mengambil aura dariinkuisisi. Kesalahan harus ditunjukkan dengan lembut, nada rapatharus longgar dan konstruktif, niat tersebut tidak boleh mempermalukan atau

meremehkan. Pemimpin review harus melakukan pertemuan kajian untuk memastikan bahwanada yang tepat dan sikap yang dipertahankan dan harus segera berhentireview yang telah didapat di luar kendali.

2. Tetapkan agenda dan mempertahankannya. Salah satu penyakit kunci rapat semuaadalah jenis drift. Sebuah FTR harus disimpan di jalur dan jadwal. Tinjauanpemimpin yang disewa dengan tanggung jawab untuk menjaga jadwal pertemuandan tidak perlu takut untuk mendorong orang-orang ketika drift set masuk3. Batas perdebatan dan bantahan. Bila masalah dinaikkan oleh sebuah resensi, mungkin adatidak ada kesepakatan universal tentang dampaknya. Daripada menghabiskan waktu berdebatpertanyaan, masalah harus dicatat untuk diskusi lebih lanjut secara off-line.4. masalah daerah memberitahukan, tapi jangan berusaha untuk memecahkan setiap masalah dicatat. Areview bukan sesi pemecahan masalah. Solusi dari masalah seringkali dapatdicapai oleh produsen sendiri atau dengan bantuan hanya satu lainnyaindividu. Pemecahan masalah harus ditunda sampai setelah pertemuan kajian.5. Membuat catatan tertulis. Kadang-kadang ide yang baik untuk perekam untuk membuat catatandi papan dinding, sehingga kata-kata dan prioritas dapat dinilai oleh laintinjauan sebagai informasi dicatat.6. Membatasi jumlah peserta dan menuntut persiapan terlebih dahulu. Duakepala lebih baik dari satu, tapi 14 belum tentu lebih baik dari 4. Jauhkanjumlah orang yang terlibat untuk jumlah minimum yang diperlukan. Namun, meninjau semuaanggota tim harus menyiapkan terlebih dahulu. komentar tertulis harusdiminta oleh pemimpin review (memberikan indikasi bahwa resensi tersebut telahreview materi).7. Mengembangkan checklist untuk setiap produk yang kemungkinan akan ditinjau. A checklistmembantu pemimpin penelaahan untuk struktur pertemuan FTR dan membantu setiap resensiuntuk fokus pada isu-isu penting. Daftar-pembanding harus dikembangkan untuk analisis,desain, kode, dan bahkan uji dokumen.8. Mengalokasikan sumber daya dan waktu jadwal untuk FTRs. Untuk review menjadi efektif, merekaharus dijadwalkan sebagai tugas selama proses rekayasa perangkat lunak. DalamSelain itu, waktu harus dijadwalkan untuk modifikasi tak terelakkan yang akanterjadi sebagai hasil dari suatu FTR.9. Melakukan berarti pelatihan untuk semua tinjauan. Agar efektif semua peserta reviewharus menerima beberapa pelatihan formal. Pelatihan harus menekankan keduaproses-terkait isu-isu dan sisi psikologis manusia tinjauan. Freedmandan Weinberg [FRE90] memperkirakan kurva belajar satu bulan untuk setiap 20orang-orang yang untuk berpartisipasi secara efektif dalam tinjauan.10. Review review awal Anda. Debriefing dapat bermanfaat dalam mengungkap masalahdengan proses peninjauan itu sendiri. Produk pertama yang akan ditinjauharus meninjau pedoman itu sendiri.Karena banyak variabel (misalnya, jumlah peserta, jenis produk kerja, waktudan panjang, pendekatan review tertentu) berdampak pada keberhasilan review

organisasi perangkat lunak harus percobaan untuk menentukan apa pendekatan yang terbaik dikonteks lokal. Porter dan rekan-rekannya [POR95] memberikan bimbingan yang tepat untuk inijenis percobaan.8.6 PENDEKATAN FORMAL TERHADAP SQAPada bagian sebelumnya, kami telah berpendapat bahwa kualitas perangkat lunak adalah tugas semua orang;bahwa hal itu dapat dicapai melalui analisis yang kompeten, desain, coding, dan pengujian, sebagaijuga melalui penerapan review teknis formal, strategi pengujian multitier,kontrol yang lebih baik dari produk kerja software dan perubahan yang dibuat untuk mereka, danpenerapan standar rekayasa perangkat lunak diterima. Selain itu, kualitas bisadidefinisikan dalam bentuk array yang luas dari faktor kualitas dan diukur (secara tidak langsung) dengan menggunakanberbagai indeks dan metrik.Selama dua dekade terakhir, segmen kecil, tetapi vokal, dari rekayasa perangkat lunakmasyarakat berpendapat bahwa pendekatan yang lebih formal untuk jaminan kualitas perangkat lunakdiperlukan. Bisa dikatakan bahwa sebuah program komputer adalah objek matematika[SOM96]. Sebuah sintaks dan semantik yang ketat dapat didefinisikan untuk setiap pemrogramanbahasa, dan pekerjaan dilakukan untuk mengembangkan pendekatan yang sama ketat untuk spesifikasipersyaratan perangkat lunak. Jika model persyaratan (spesifikasi) danbahasa pemrograman dapat direpresentasikan secara ketat, seharusnya mungkinuntuk menerapkan matematika bukti kebenaran untuk menunjukkan bahwa program sesuaipersis dengan spesifikasinya.Upaya untuk membuktikan program yang benar bukanlah hal baru. Dijkstra [DIJ76] dan Linger, Mills,dan Witt [LIN79], antara lain, menganjurkan bukti kebenaran program dan diikatini dengan penggunaan konsep-konsep pemrograman terstruktur (Bab 16).8,7 STATISTIK JAMINAN KUALITAS PERANGKAT LUNAKjaminan kualitas statistik mencerminkan trend yang berkembang di seluruh industri menjadilebih kuantitatif tentang kualitas. Untuk perangkat lunak, jaminan kualitas statistik menunjukkanlangkah-langkah berikut:1. Informasi tentang perangkat lunak cacat dikumpulkan dan dikelompokkan.2. Suatu usaha dilakukan untuk menelusuri setiap cacat penyebab nya (misalnya, ketidaksesuaianuntuk spesifikasi, kesalahan desain, pelanggaran standar, miskinkomunikasi dengan pelanggan).3. Menggunakan prinsip Pareto (80 persen dari cacat dapat ditelusuri sampai 20 persendari semua kemungkinan penyebab), mengisolasi 20 persen (yang "vital few").4. Setelah beberapa penyebab penting telah diidentifikasi, bergerak untuk memperbaiki masalahyang telah menyebabkan cacat.

Konsep ini relatif sederhana merupakan suatu langkah penting menuju terciptanyasuatu rekayasa perangkat lunak adaptif proses di mana perubahan dibuat untuk memperbaikiunsur-unsur dari proses yang memperkenalkan kesalahan.Untuk menggambarkan hal ini, berasumsi bahwa sebuah organisasi rekayasa perangkat lunak mengumpulkan informasipada cacat untuk jangka waktu satu tahun. Beberapa cacat yang terungkap sebagai perangkat lunaksedang dikembangkan. Lain ditemui setelah perangkat lunak telah dirilisuntuk-pengguna akhir. Meskipun ratusan kesalahan yang berbeda yang terungkap, semua bisa

dilacak untuk satu (atau lebih) penyebab berikut:• spesifikasi lengkap atau keliru (IES)• salah tafsir komunikasi pelanggan (PKS)• disengaja penyimpangan dari spesifikasi (IDS)• Pelanggaran standar pemrograman (VPS)• Kesalahan dalam representasi data (EDR)• komponen antar muka yang tidak konsisten (ICI)• Kesalahan dalam logika desain (EDL)• tidak lengkap atau salah pengujian (IET)• tidak akurat atau tidak lengkap dokumentasi (Iid)• kesalahan dalam penerjemahan bahasa pemrograman desain (PLT)• ambigu atau tidak konsisten manusia / interface komputer (HCI)• miscellaneous (MIS)Untuk menerapkan SQA statistik, Tabel 8.1 dibangun. Tabel tersebut menunjukkan bahwa IES, PKS, dan EDRadalah beberapa penyebab penting bahwa account untuk 53 persen dari semua kesalahan. Perlu dicatat,bagaimanapun, bahwa IES, EDR, WBP, dan EDL akan dipilih sebagai beberapa penyebab penting jikahanya kesalahan serius dipertimbangkan. Setelah beberapa penyebab vital ditentukan,organisasi rekayasa perangkat lunak dapat mulai tindakan korektif. Misalnya, untuk memperbaikiPKS, pengembang perangkat lunak mungkin menerapkan difasilitasi spesifikasi aplikasiteknik (Bab 11) untuk meningkatkan kualitas komunikasi pelanggan danspesifikasi. Untuk meningkatkan EDR, pengembang mungkin memperoleh CASE tools untuk pemodelan datadan melakukan yang lebih ketat review data desain.Penting untuk dicatat bahwa tindakan korektif berfokus terutama pada beberapa penting. Sepertibeberapa penyebab vital dikoreksi, calon baru muncul ke atas tumpukan.teknik statistik jaminan kualitas untuk perangkat lunak telah terbukti memberikanpeningkatan kualitas substansial [ART97]. Dalam beberapa kasus, organisasi perangkat lunak memilikimencapai pengurangan 50 persen per tahun di cacat setelah menerapkan teknik ini.Dalam kaitannya dengan pengumpulan informasi cacat, pengembang perangkat lunak dapatmenghitung indeks kesalahan (EI) untuk setiap langkah besar dalam proses software {IEE94]. Setelahanalisis, desain, coding, pengujian, dan melepaskan, data berikut dikumpulkan:Ei = jumlah kesalahan yang ditemukan selama langkah i dalam rekayasa perangkat lunakproses

8,8 KEANDALAN PERANGKAT LUNAKTidak ada keraguan bahwa keandalan program komputer merupakan elemen pentingkualitas secara keseluruhan. Jika program berulang kali dan sering gagal untuk melakukan, itu pentingsedikit apakah faktor perangkat lunak lain kualitas dapat diterima.Keandalan perangkat lunak, seperti banyak faktor kualitas lainnya, dapat diukur dan diarahkandiestimasi dengan menggunakan data historis dan pembangunan. Keandalan perangkat lunak

didefinisikan dalam statistikistilah sebagai "probabilitas kegagalan operasi bebas dari suatu program komputer dalamlingkungan tertentu untuk waktu tertentu "[MUS87] Untuk menggambarkan,. Program X diperkirakanmemiliki keandalan 0,96 lebih dari delapan jam pengolahan berlalu. Dengan kata lain, jika programX dijalankan 100 kali dan membutuhkan delapan jam pengolahan berlaluwaktu (waktu eksekusi), kemungkinan untuk beroperasi dengan benar (tanpa kegagalan) 96 kali dari 100.Setiap kali keandalan perangkat lunak dibahas, pertanyaan penting muncul: Apakah yang dimaksudoleh kegagalan panjang? Dalam konteks diskusi kualitas dan kehandalan perangkat lunak,kegagalan adalah ketidaksesuaian dengan kebutuhan perangkat lunak. Namun, bahkan dalam definisi ini,ada gradasi. Kegagalan hanya dapat mengganggu atau bencana. Satu kegagalandapat diperbaiki dalam hitungan detik sementara yang lain memerlukan beberapa minggu atau bahkan bulan untukbenar. Rumit masalah ini lebih jauh, koreksi satu kegagalan mungkin sebenarnyamenghasilkan pengenalan kesalahan lain yang pada akhirnya mengakibatkan kegagalan lainnya.8.8.1 Ukuran Reliabilitas dan KetersediaanAwal bekerja dalam kehandalan perangkat lunak berusaha untuk ekstrapolasi matematika hardwareteori keandalan (misalnya, [ALV64]) untuk prediksi keandalan perangkat lunak. Sebagian besarModel keandalan perangkat keras yang berhubungan dengan didasarkan pada kegagalan karena memakai daripadakegagalan karena desain cacat. Di hardware, karena memakai fisik (misalnya, kegagalan tersebutpengaruh suhu, shock korosi,) lebih mungkin daripada kegagalan desain-terkait.Sayangnya, sebaliknya adalah benar untuk perangkat lunak. Bahkan, semua kegagalan perangkat lunak dapatditelusuri ke masalah desain atau pelaksanaan; pakai (lihat Bab 1) tidak masukke dalam gambar.Telah ada perdebatan tentang hubungan antara konsep-konsep kunci dalam perangkat keraskeandalan dan penerapan mereka untuk perangkat lunak (misalnya, [LIT89], [ROO90]). Meskipunlink terbantahkan belum harus dibentuk, akan lebih bermanfaat untuk mempertimbangkan beberapa sederhanakonsep yang berlaku untuk kedua elemen sistem.Jika kita mempertimbangkan sistem berbasis komputer, ukuran sederhana keandalan Sementara-antara-kegagalan (MTBF), dimanaMTBF = MTTF + MTTRThe MTTF dan MTTR adalah singkatan rata-time-to-kegagalan dan mean-time-to-perbaikan,masing.

Banyak peneliti berpendapat bahwa MTBF merupakan ukuran yang berguna jauh lebih banyak daripada cacat KLOC /

atau cacat / FP. Lain sederhana, end-user berkaitan dengan kegagalan, tidak dengan totalkesalahan hitung. Karena setiap kesalahan yang terkandung di dalam sebuah program tidak memiliki samatingkat kegagalan, jumlah kesalahan total memberikan indikasi sedikit keandalan sistem.Sebagai contoh, pertimbangkan sebuah program yang telah beroperasi selama 14 bulan. Banyakkesalahan dalam program ini akan tetap tidak terdeteksi selama beberapa dekade sebelum mereka ditemukan.The MTBF kesalahan jelas seperti itu mungkin menjadi 50 atau bahkan 100 tahun. Lain kesalahan,yang belum ditemukan, mungkin memiliki tingkat kegagalan 18 atau 24 bulan. Bahkan jika setiap orangdari kategori pertama kesalahan (orang-orang dengan MTBF panjang) dihapus, dampak terhadap perangkat lunakkeandalan diabaikan.Selain mengukur keandalan, kita harus mengembangkan suatu ukuran ketersediaan.Software ketersediaan adalah probabilitas bahwa sebuah program sedang beroperasi sesuai dengan persyaratanpada suatu titik waktu tertentu dan didefinisikan sebagaiKetersediaan = [MTTF / (MTTF + MTTR)]? 100%Ukuran reliabilitas MTBF sama sensitif terhadap MTTF dan MTTR. Ketersediaanukuran agak lebih sensitif terhadap MTTR, ukuran yang tidak langsung pemeliharaan yangperangkat lunak.8.8.2 Perangkat Lunak KeamananLeveson [LEV86] membahas dampak perangkat lunak dalam sistem keamanan kritis ketika diamenulis:Sebelum perangkat lunak yang digunakan dalam sistem keamanan kritis, mereka sering dikendalikan oleh konvensional(Nonprogrammable) mekanik dan perangkat elektronik. Sistem keamanan teknikdirancang untuk mengatasi kegagalan acak dalam sistem-sistem [nonprogrammable]. Manusiakesalahan desain tidak dianggap karena diasumsikan bahwa semua kesalahan yang disebabkan oleh kesalahan manusiadapat dihindari sepenuhnya atau dihapus sebelum pengiriman dan operasi.Ketika perangkat lunak digunakan sebagai bagian dari sistem kontrol, kompleksitas dapat meningkatkan olehurutan besarnya atau lebih. Desain halus kesalahan disebabkan oleh manusia-sesuatu kesalahanyang dapat ditemukan dan dieliminasi dalam kontrol konvensional berbasis hardware-menjadi jauh lebih sulit untuk mengungkap ketika perangkat lunak digunakan.Software keselamatan adalah jaminan kualitas perangkat lunak kegiatan yang berfokus pada identifikasidan penilaian potensi bahaya yang dapat mempengaruhi negatif dan perangkat lunakmenyebabkan seluruh sistem gagal. Jika bahaya dapat diidentifikasi pada awal rekayasa perangkat lunakproses, perangkat lunak fitur desain dapat ditentukan bahwa baik akan menghilangkanatau mengendalikan potensi bahaya.Sebuah proses pemodelan dan analisis dilakukan sebagai bagian dari keamanan perangkat lunak. Awalnya,

bahaya diidentifikasi dan dikategorikan oleh kekritisan dan risiko. Misalnya, beberapaberbahaya yang berhubungan dengan cruise control berbasis komputer untuk mobil mungkin• menyebabkan percepatan yang tak terkendali yang tidak dapat dihentikan• tidak menanggapi depresi dari pedal rem (dengan mematikan)

• tidak melakukan ketika saklar diaktifkan• perlahan kehilangan atau kecepatan keuntunganSetelah ini sistem-tingkat bahaya diidentifikasi, teknik analisis digunakan untuk menetapkankeparahan dan kemungkinan occurrence.4 Agar efektif, perangkat lunak harus dianalisadalam konteks seluruh sistem. Misalnya, kesalahan pengguna halus masukan (orangKomponen sistem) dapat diperbesar oleh kesalahan perangkat lunak untuk menghasilkan data kontrolyang benar posisi alat mekanis. Jika satu set kondisi lingkungan eksternalterpenuhi (dan hanya jika mereka terpenuhi), posisi yang tidak benar dari mekanikperangkat akan menyebabkan bencana kegagalan. Analisis teknik seperti analisis fault tree[VES81], real-time logika [JAN86], atau model bersih petri [LEV87] dapat digunakan untuk memprediksirantai peristiwa yang dapat menyebabkan bahaya dan probabilitas bahwa setiap peristiwaakan terjadi untuk menciptakan rantai.Setelah bahaya diidentifikasi dan dianalisis, persyaratan keselamatan terkait dapat dispesifikasikanuntuk perangkat lunak. Artinya, spesifikasi dapat berisi daftar kejadian yang tidak diinginkandan yang diinginkan respon sistem untuk peristiwa ini. Peran perangkat lunak dalam mengelolakejadian yang tidak diinginkan kemudian ditunjukkan.Meskipun perangkat lunak kehandalan dan keamanan perangkat lunak yang erat terkait satu sama lain,adalah penting untuk memahami perbedaan halus antara mereka. Keandalan perangkat lunakmenggunakan analisis statistik untuk menentukan kemungkinan bahwa kegagalan perangkat lunak akanterjadi. Namun, terjadinya kegagalan tidak selalu mengakibatkan bahayaatau kecelakaan. Software keselamatan meneliti cara-cara yang mengakibatkan kegagalan kondisiyang dapat menyebabkan suatu kecelakaan. Artinya, kegagalan tidak dianggap dalam ruang hampa, tetapidievaluasi dalam konteks sistem berbasis komputer secara keseluruhan.Sebuah diskusi komprehensif keamanan perangkat lunak adalah di luar cakupan buku ini.Mereka pembaca dengan bunga lebih lanjut harus mengacu pada Leveson buku [LEV95] padasubjek.8.9 KESALAHAN-proofing UNTUK PERANGKAT LUNAKJika William Shakespeare memiliki mengomentari kondisi software engineer modern,ia mungkin telah menulis: "Untuk kesalahan adalah manusiawi, untuk menemukan kesalahan dengan cepat dan benar ituadalah ilahi "Pada tahun 1960., seorang insinyur industri Jepang, Shigeo Shingo [SHI86], bekerjadi Toyota, mengembangkan teknik jaminan mutu yang menyebabkan pencegahandan / atau koreksi awal kesalahan dalam proses manufaktur. Disebut poka-yoke(Kesalahan-pemeriksaan), konsep Shingo's memanfaatkan poka-yoke-mekanisme perangkatyang mengarah ke (1) pencegahan masalah kualitas potensial sebelum itu terjadi atau (2)

deteksi cepat masalah kualitas jika mereka diperkenalkan. Kami menemukan pokayokeperangkat dalam kehidupan sehari-hari kita (bahkan jika kita tidak menyadari konsep). Untuk ujian-

saklar pengapian untuk mobil tidak akan bekerja jika transmisi otomatisdi gear (alat pencegahan); beep peringatan sebuah auto akan suara jika sabuk pengaman yangtidak melengkung (perangkat deteksi).Sebuah pameran perangkat efektif poka-yoke satu set karakteristik umum:• Ini adalah sederhana dan murah. Jika perangkat terlalu rumit atau mahal, itu akantidak efektif biaya.• Ini adalah bagian dari proses. Artinya, perangkat poka-yoke ini diintegrasikan menjadi sebuahkegiatan rekayasa.• Hal ini terletak dekat tugas proses di mana kesalahan terjadi. Dengan demikian,memberikan umpan balik yang cepat dan koreksi kesalahan.Meskipun poka-yoke pada awalnya dikembangkan untuk digunakan dalam "nol quality control"[SHI86] untuk hardware diproduksi, bisa diadaptasi untuk digunakan dalam rekayasa perangkat lunak.Untuk menggambarkan, kami mempertimbangkan masalah berikut [ROB97]:Sebuah perangkat lunak menjual produk perusahaan perangkat lunak aplikasi ke pasar internasional. Themenu pull-down dan mnemonik yang terkait yang disediakan dengan setiap aplikasi harus mencerminkanbahasa lokal. Sebagai contoh, item menu bahasa Inggris untuk "Close" memilikimnemonic "C" yang terkait dengannya. Bila aplikasi yang dijual di negara berbahasa Perancis,item menu yang sama adalah "Fermer" dengan mnemonic "F." Untuk melaksanakan yang sesuaientri menu untuk setiap lokal, sebuah "localizer" (orang yang fasih dalam bahasa lokal danterminologi) menerjemahkan menu yang sesuai. Masalahnya adalah untuk memastikan bahwa (1) setiap menuentri bisa (ada ratusan) sesuai dengan standar yang tepat dan bahwa tidak ada konflik,terlepas dari bahasa yang digunakan.Penggunaan poka-yoke untuk menguji menu berbagai aplikasi diimplementasikan di berbagaibahasa sebagai hanya dijelaskan akan didiskusikan dalam makalah oleh Harry Robinson [ROB97]: 5Kami pertama kali memutuskan untuk memecahkan masalah pengujian down menu menjadi bagian-bagian yang kami bisa memecahkan.muka pertama kami pada masalah ini adalah untuk memahami bahwa ada dua aspek yang terpisahke katalog pesan. Ada aspek isi: terjemahan teks sederhana, sepertisebagai mengubah "Close" untuk "Fermer." Karena tim uji tidak fasih dalam 11 bahasa target,kami harus meninggalkan aspek ini para ahli bahasa.Aspek kedua dari katalog pesan yang struktur, aturan sintaks bahwabenar dibangun katalog target harus patuh. Tidak seperti konten, akan mungkin untukTim uji untuk memverifikasi aspek struktural dari katalog.Sebagai contoh dari apa yang dimaksud dengan struktur, mempertimbangkan label dan mnemonik darimenu aplikasi. Sebuah menu terdiri dari label dan mnemonik terkait. Setiap menu, tanpaisi atau lokal nya, harus mematuhi aturan-aturan berikut tercantum dalam Motif Style Guide:

• Setiap mnemonic harus tercantum dalam label yang berkaitan• Setiap mnemonic harus unik dalam menu

• Setiap mnemonic harus berupa sebuah karakter tunggal• Setiap mnemonic harus dalam ASCIIPeraturan-peraturan ini invarian di locales, dan dapat digunakan untuk memverifikasi bahwa menu dibangunbenar dalam target lokal.Ada beberapa kemungkinan untuk bagaimana kesalahan-bukti yang mnemonik menu:device.We Pencegahan bisa menulis sebuah program untuk menghasilkan mnemonik otomatis, diberikandaftar label dalam menu masing-masing. Pendekatan ini akan mencegah kesalahan, tapi masalahnyadari memilih mnemonik yang baik adalah sulit dan upaya yang diperlukan untuk menulis program akantidak dibenarkan oleh manfaat yang didapat.device.We Pencegahan bisa menulis sebuah program yang akan mencegah localizer dari memilihmnemonik yang tidak memenuhi kriteria. Pendekatan ini juga akan mencegah kesalahan,tetapi manfaat yang diperoleh akan minim; mnemonik salah cukup mudah untuk mendeteksidan benar setelah mereka terjadi.Deteksi perangkat. Kami bisa menyediakan sebuah program untuk memverifikasi bahwa label menu yang dipilih danmnemonik memenuhi kriteria di atas. pelokalan kami bisa menjalankan program di diterjemahkan merekakatalog pesan sebelum mengirim katalog kepada kami. Pendekatan ini akan memberikansangat umpan balik yang cepat pada kesalahan, dan kemungkinan sebagai langkah ke depan.Deteksi perangkat. Kita bisa menulis sebuah program untuk memverifikasi label menu dan mnemonik,dan menjalankan program pada katalog pesan setelah mereka dikembalikan kepada kami oleh pelokalan.Pendekatan ini adalah jalan kita saat ini sedang. Hal ini tidak efisien karena beberapa hal di atasmetode, dan dapat memerlukan komunikasi bolak-balik dengan pelokalan, tetapikesalahan yang terdeteksi masih mudah untuk memperbaiki pada saat ini.Beberapa kecil poka-yoke script digunakan sebagai perangkat poka-yoke untuk memvalidasi strukturalaspek menu. Sebuah script poka-yoke kecil akan membaca meja, mengambil mnemonikdan label dari katalog pesan, dan membandingkan string diambil terhadapkriteria yang ditetapkan disebutkan di atas.Script poka-yoke adalah kecil (sekitar 100 baris), mudah untuk menulis (beberapa ditulisdalam waktu kurang dari satu jam) dan mudah dijalankan. Kami berlari script kami poka-yoke terhadap 16 aplikasi dalamlokal Inggris default ditambah 11 locales asing. Setiap lokal berisi 100 menu, untuk1200 total menu. Perangkat poka-yoke ditemukan 311 kesalahan dalam menu dan mnemonik.Beberapa masalah yang kita ditemukan adalah menghancurkan bumi, tetapi total mereka akansebesar merupakan gangguan yang besar dalam pengujian dan menjalankan aplikasi lokal kita.Contoh ini menggambarkan perangkat poka-yoke yang telah diintegrasikan ke dalam perangkat

lunakteknik uji aktivitas. Teknik poka-yoke dapat diterapkan pada desain,kode, dan pengujian tingkat dan memberikan jaminan kualitas yang efektif filter.8,10 ATAS KUALITAS ISO 9000 STANDARDS6Sistem jaminan kualitas dapat didefinisikan sebagai struktur organisasi, tanggung jawab,prosedur, proses, dan sumber daya untuk menerapkan manajemen mutu

[ANS87]. sistem penjaminan mutu diciptakan untuk membantu organisasi memastikan merekaproduk dan jasa memenuhi harapan pelanggan dengan memenuhi spesifikasi mereka.Sistem ini mencakup berbagai kegiatan meliputi seluruh hidup suatu produksiklus termasuk perencanaan, pengendalian, pengukuran, pengujian dan pelaporan, dan meningkatkantingkat kualitas sepanjang pengembangan dan proses manufaktur. ISO 9000menjelaskan unsur-unsur jaminan mutu dalam istilah generik yang dapat diterapkan pada bisnisterlepas dari produk atau jasa yang ditawarkan.Standar ISO 9000 telah diadopsi oleh banyak negara termasuk semua anggotaMasyarakat Eropa, Kanada, Meksiko, Amerika Serikat, Australia, NewSelandia, dan Rim Pasifik. Negara-negara di Latin dan Amerika Selatan juga telah menunjukkanbunga dalam standar.Setelah mengadopsi standar, suatu negara biasanya hanya mengijinkan ISO perusahaan yang terdaftaruntuk memasok barang dan jasa kepada instansi pemerintah dan utilitas umum.Peralatan telekomunikasi dan alat kesehatan adalah contoh dari kategori produkyang harus disediakan oleh perusahaan ISO terdaftar. Pada gilirannya, produsenproduk-produk ini sering membutuhkan pemasok mereka untuk menjadi terdaftar. Perusahaan swastaseperti mobil dan produsen komputer sering membutuhkan pemasok merekamenjadi ISO terdaftar juga.Untuk menjadi didaftarkan ke salah satu model sistem jaminan mutu yang terkandung dalamISO 9000, kualitas sistem dan operasi perusahaan yang diteliti oleh pihak ketigaauditor untuk kepatuhan terhadap standar dan untuk operasi yang efektif. Setelah berhasilpendaftaran, sebuah perusahaan mengeluarkan sertifikat dari badan registrasi diwakilioleh auditor. Semi-surveilans audit tahunan terus memastikan kepatuhan terhadapstandar.8.10.1 Pendekatan ISO untuk Sistem Penjaminan MutuModel jaminan mutu ISO 9000 memperlakukan perusahaan sebagai jaringan interkoneksiproses. Untuk sistem mutu yang harus sesuai dengan ISO, proses ini harusalamat area yang diidentifikasi dalam standar dan harus didokumentasikan dan dipraktekkanseperti yang dijelaskan.ISO 9000 menggambarkan elemen sebuah sistem jaminan mutu secara umum.Elemen-elemen ini mencakup struktur organisasi, prosedur, proses, dansumber daya yang dibutuhkan untuk melaksanakan perencanaan mutu, pengendalian mutu, jaminan mutu,dan peningkatan kualitas. Namun, ISO 9000 tidak menggambarkan bagaimana suatu organisasiharus menerapkan unsur-unsur sistem mutu. Akibatnya, tantangan

terletak dalam merancang dan menerapkan sistem jaminan kualitas yang sesuai standardan cocok produk perusahaan, layanan, dan budaya.8.10.2 Standar ISO 9001ISO 9001 adalah standar jaminan kualitas yang berlaku untuk rekayasa perangkat lunak. Thestandar berisi 20 persyaratan yang harus hadir untuk jaminan kualitas yang efektifsistem. Karena standar ISO 9001 berlaku untuk rekayasa semua disiplin, satu set khusus pedoman ISO (ISO 9000-3) telah dikembangkan untuk membantumenginterpretasikan standar untuk digunakan dalam proses perangkat lunak.Persyaratan digambarkan oleh ISO 9001 alamat topik seperti manajementanggung jawab, sistem mutu, review kontrak, pengendalian desain, dokumen dan datakontrol, identifikasi dan mampu telusur produk, kontrol proses, inspeksi dan pengujian,perbaikan dan tindakan pencegahan, pengendalian catatan mutu, audit mutu internal,pelatihan, pelayanan, dan teknik statistik. Agar sebuah organisasi perangkat lunak untukmenjadi terdaftar untuk ISO 9001, ia harus menetapkan kebijakan dan prosedur untuk mengatasisetiap persyaratan hanya mencatat (dan lain-lain) dan kemudian dapat menunjukkanbahwa kebijakan dan prosedur sedang diikuti. Untuk informasi lebih lanjut tentang ISO9001, pembaca yang tertarik akan melihat [HOY98], [SCH97], atau [SCH94].8,11 RENCANA SQARencana SQA menyediakan peta jalan untuk melembagakan jaminan kualitas perangkat lunak. Dikembangkanoleh kelompok SQA, rencana tersebut berfungsi sebagai template untuk aktivitas SQA yang dilembagakanuntuk setiap proyek software.Sebuah standar untuk rencana SQA telah direkomendasikan oleh IEEE [IEE94]. Bagian awalmenjelaskan tujuan dan ruang lingkup dokumen dan menunjukkan perangkat lunak yangkegiatan proses yang tercakup dalam jaminan kualitas. Semua dokumen tertulis diRencana SQA terdaftar dan semua standar yang berlaku dicatat. Bagian Manajemendari rencana tersebut menggambarkan tempat SQA dalam struktur organisasi, tugas dan aktivitas SQAdan mereka penempatan selama proses perangkat lunak, dan organisasiperan dan tanggung jawab relatif terhadap kualitas produk.Bagian dokumentasi menjelaskan (referensi) masing-masing produk kerjadiproduksi sebagai bagian dari proses perangkat lunak. Ini termasuk• Proyek dokumen (misalnya, rencana proyek)• model (misalnya, ERD, hirarki kelas)• teknis dokumen (misalnya, spesifikasi, rencana uji)• pengguna dokumen (misalnya, file bantuan)Selain itu, bagian ini mendefinisikan set minimum produk kerja yang dapat diterimauntuk mencapai kualitas tinggi.Standar, praktik, dan bagian konvensi daftar semua standar yang berlakudan praktik yang diterapkan selama proses perangkat lunak (misalnya, standar dokumen,

coding standar, dan pedoman review). Selain itu, semua proyek, proses, dan (dalambeberapa kasus) Produk metrik yang akan dikumpulkan sebagai bagian dari rekayasa perangkat lunakkerja terdaftar.Bagian review dan audit dari rencana mengidentifikasi review dan audit yang akandilakukan oleh tim rekayasa perangkat lunak, kelompok SQA, dan pelanggan. Inimemberikan gambaran tentang pendekatan untuk setiap review dan audit.

Referensi test section Perangkat Lunak Test Rencana dan Prosedur (Bab 18). Inijuga mendefinisikan uji pencatatan persyaratan. Masalah pelaporan dan tindakan korektifmendefinisikan prosedur untuk pelaporan, pelacakan, dan mengatasi kesalahan dan cacat, dan mengidentifikasidi organisasi tanggung jawab untuk kegiatan ini.Sisa dari Rencana SQA mengidentifikasi alat dan metode yang mendukung SQAkegiatan dan tugas-tugas; referensi perangkat lunak prosedur manajemen konfigurasi untukperubahan pengendali; mendefinisikan pendekatan manajemen kontrak; menciptakan metodeuntuk perakitan, menjaga, dan memelihara semua catatan; mengidentifikasi pelatihan yang dibutuhkanuntuk memenuhi kebutuhan rencana; dan mendefinisikan metode untuk mengidentifikasi, menilai, pemantauan,dan mengendalikan risiko.8,12 RINGKASANSoftware quality assurance merupakan kegiatan payung yang diterapkan pada setiap langkah dalamproses software. SQA meliputi prosedur untuk aplikasi yang efektif metodedan alat-alat, review teknis formal, strategi pengujian dan teknik, poka-yokeperangkat, prosedur untuk kontrol perubahan, prosedur untuk memastikan kepatuhan terhadap standar,dan pengukuran dan pelaporan mekanisme.SQA rumit dengan kompleksitas perangkat lunak-atribut mutu dariprogram komputer yang didefinisikan sebagai "kesesuaian untuk secara eksplisit dan implisit ditetapkanpersyaratan. "Tetapi ketika dianggap lebih umum, kualitas perangkat lunak meliputibanyak berbeda produk dan faktor proses dan metrik terkait.Ulasan Software adalah salah satu kegiatan SQA yang paling penting. Ulasan berfungsi sebagaifilter seluruh kegiatan rekayasa perangkat lunak, menghapus kesalahan saat merekarelatif murah untuk menemukan dan benar. Tinjauan teknis formal adalah bergayapertemuan yang telah terbukti sangat efektif dalam mengungkap kesalahan.Untuk benar melakukan jaminan kualitas perangkat lunak, data tentang rekayasa perangkat lunakproses harus dikumpulkan, dievaluasi, dan disebarluaskan. Statistik SQAmembantu untuk meningkatkan kualitas produk dan proses perangkat lunak itu sendiri. Perangkat Lunakmodel keandalan memperpanjang pengukuran, memungkinkan data cacat dikumpulkan untuk diekstrapolasike tingkat kegagalan proyeksi dan prediksi kehandalan.Singkatnya, kita ingat kata-kata Dunn dan Ullman [DUN82]: "kualitas Perangkat Lunak

jaminan adalah pemetaan aturan manajerial dan disiplin desain kualitasjaminan ke ruang manajerial dan teknologi yang berlaku perangkat lunakrekayasa "Kemampuan untuk menjamin kualitas. adalah ukuran dari rekayasa matangdisiplin. Bila pemetaan berhasil dicapai, rekayasa perangkat lunak dewasahasilnya.

BAB 9

Apa itu? Ketika Anda membangun komputerperangkat lunak, perubahan terjadi.Dan karena hal itu terjadi, Andaperlu mengendalikan secara efektif. Konfigurasi perangkat lunakmanajemen (SCM) adalah serangkaian kegiatandirancang untuk mengontrol perubahan dengan mengidentifikasikerja produk yang cenderung berubah, mendirikanhubungan di antara mereka, mendefinisikan mekanismeuntuk mengelola versi yang berbeda dariproduk kerja, mengendalikan perubahan yang dikenakan,dan audit dan pelaporan pada perubahandibuat.Siapa yang melakukan itu? Setiap orang yang terlibat dalam rekayasa perangkat lunakproses yang terlibat dengan SCM untuk beberapabatas, tetapi khusus posisi dukungan kadang-kadangdibuat untuk mengelola proses SCM.Mengapa itu penting? Jika Anda tidak mengontrol berubah,kontrol Anda. Dan itu tidak pernah baik. Ini sangat mudahuntuk suatu aliran perubahan yang tidak terkontrol untuk mengubahbaik menjalankan proyek perangkat lunak ke dalam kekacauan. Untuk alasan itu,SCM merupakan bagian penting dari manajemen proyek yang baikdan solid rekayasa perangkat lunakpraktek.Apa langkah-langkah? Karena banyak produk kerjadihasilkan ketika perangkat lunak dibangun, masing-masing harusdiidentifikasi secara unik. Setelah ini selesai,mekanisme kontrol versi dan perubahan bisadibentuk. Untuk memastikan kualitas yang dipeliharasebagai perubahan yang dibuat, proses inidiaudit; dan untuk memastikan bahwa mereka dengan kebutuhan untuk

tahu diberitahu tentang perubahan, pelaporandilakukan.

Apakah produk kerja? ThePerangkat Lunak Manajemen KonfigurasiMendefinisikan rencana proyekstrategi untuk SCM. Selain itu, ketika formal SCMdipanggil, proses kontrol perubahan menghasilkanperangkat lunak perubahan permintaan dan laporan dan rekayasamengubah perintah.Bagaimana saya memastikan bahwa saya telah melakukan dengan benar? Ketikasetiap produk kerja dapat dipertanggungjawabkan, dilacak,dan dikendalikan, ketika setiap perubahan dapatdilacak dan dianalisis, ketika setiap orang yang memerlukanuntuk mengetahui tentang perubahan telah informedAnda sudah melakukan dengan benar.

ke dalam operasi. manajemen konfigurasi perangkat lunak adalah serangkaian pelacakan dan kontrolkegiatan yang dimulai ketika sebuah proyek rekayasa perangkat lunak dimulai dan berakhir hanyaketika perangkat lunak tersebut diambil dari operasi.Tujuan utama rekayasa perangkat lunak adalah untuk meningkatkan kemudahan dengan yang perubahandapat ditampung dan mengurangi jumlah usaha dikeluarkan ketika perubahanharus dibuat. Dalam bab ini, kita membahas kegiatan khusus yang memungkinkan kita untuk mengelolaberubah.9.1 KONFIGURASI PERANGKAT LUNAK MANAJEMENOutput dari proses perangkat lunak adalah informasi yang dapat dibagi menjadi tiga luaskategori: (1) program komputer (baik tingkat sumber dan bentuk executable), (2) dokumenyang menggambarkan program komputer (ditargetkan pada kedua praktisi teknisdan pengguna), dan (3) data (yang terkandung dalam program atau eksternal untuk itu). Itemyang terdiri dari semua informasi yang diproduksi sebagai bagian dari proses software secara bersamadisebut konfigurasi perangkat lunak.Sebagai proses software berlangsung, jumlah item konfigurasi perangkat lunak(SCIs) tumbuh pesat. Sebuah Spesifikasi Sistem menumbuhkan Software Proyek Rencana dan SoftwarePersyaratan Spesifikasi (serta dokumen-dokumen terkait perangkat keras). Ini digilirannya spawn dokumen lain untuk menciptakan hirarki informasi. Jika setiap SCI hanyaSCIs lain melahirkan, akan mengakibatkan sedikit kebingungan. Sayangnya, variabel lainmemasuki proses perubahan. Perubahan dapat terjadi setiap saat, untuk alasan apapun. Bahkan,Hukum Pertama Sistem [BER80] Rekayasa menyatakan: "Tidak peduli di mana Anda berada di

sistem siklus hidup, sistem akan berubah, dan keinginan untuk mengubahnya akan bertahansepanjang siklus hidup. "Apa adalah asal dari perubahan ini? Jawaban atas pertanyaan ini beragam sepertiperubahan itu sendiri. Namun, ada empat sumber dasar dari perubahan:• Baru bisnis atau kondisi pasar mendikte perubahan dalam persyaratan produkatau aturan bisnis.• kebutuhan pelanggan baru modifikasi permintaan data yang dihasilkan oleh informasisistem, fungsionalitas disampaikan oleh produk, atau layanan yang diberikan olehsistem berbasis komputer.

• Reorganisasi atau pertumbuhan bisnis menyebabkan perampingan / perubahan dalam proyekprioritas atau perangkat lunak rekayasa struktur tim.• Anggaran atau kendala penjadwalan menyebabkan redefinisi dari sistem atauproduk.manajemen konfigurasi perangkat lunak adalah sekumpulan kegiatan yang telah dikembangkanuntuk mengelola perubahan di seluruh siklus hidup perangkat lunak komputer. SCM dapatdipandang sebagai kegiatan jaminan kualitas perangkat lunak yang diterapkan di seluruh perangkat lunakproses. Dalam bagian berikut, kami memeriksa tugas-tugas penting dan utama SCMkonsep-konsep yang membantu kita untuk mengelola perubahan.9.1.1 baselinePerubahan adalah fakta kehidupan dalam pengembangan perangkat lunak. Pelanggan ingin mengubah persyaratan.Pengembang ingin memodifikasi pendekatan teknis. Manajer ingin memodifikasistrategi proyek. Mengapa semua modifikasi ini? Jawabannya benar-benar sangat sederhana.Dengan berjalannya waktu, semua konstituen tahu lebih banyak (tentang apa yang mereka butuhkan, yang pendekatanakan lebih baik, bagaimana untuk mendapatkannya dilakukan dan masih menghasilkan uang). Pengetahuan tambahanadalah kekuatan pendorong di belakang perubahan yang paling dan menyebabkan pernyataan fakta yang sulitbagi para praktisi banyak perangkat lunak rekayasa untuk menerima: Kebanyakan perubahan dibenarkan!dasar adalah konsep manajemen konfigurasi perangkat lunak yang membantu kita untuk mengendalikanberubah tanpa serius menghambat perubahan dibenarkan. IEEE (IEEE Std. No610,12-1990) mendefinisikan awal sebagai:Sebuah spesifikasi atau produk yang telah resmi ditinjau dan disepakati, bahwa setelahberfungsi sebagai dasar untuk pengembangan lebih lanjut, dan yang dapat diubah hanya melalui formalperubahan prosedur pengendalian.Salah satu cara untuk mendeskripsikan data dasar adalah melalui analogi:Pertimbangkan pintu ke dapur di restoran besar. Satu pintu ditandai OUT danlain ditandai DI. Pintu-pintu telah berhenti yang memungkinkan mereka untuk dibuka hanya yang sesuai

arah.Jika pelayan mengambil perintah di dapur, meletakkannya di nampan dan kemudian menyadari bahwa diamemilih hidangan yang salah, dia bisa berubah untuk hidangan yang benar cepat dan informal sebelumia meninggalkan dapur.Namun, jika dia meninggalkan dapur, memberikan pelanggan piring dan kemudian diberitahu tentangkesalahan, ia harus mengikuti prosedur yang ditetapkan: (1) melihat periksa untuk menentukan jika kesalahan telahterjadi, (2) mohon maaf sebesar-besarnya, (3) kembali ke dapur melalui DI pintu, (4) menjelaskanmasalah, dan sebagainya.dasar adalah analog dengan pintu dapur di restoran. Sebelum perangkat lunakitem konfigurasi menjadi baseline, perubahan dapat dilakukan dengan cepat dan informal.Namun, setelah baseline didirikan, kami kiasan melewati satu arah ayunpintu. Perubahan dapat dibuat, tetapi prosedur, spesifik formal harus diterapkan untukmengevaluasi dan memverifikasi setiap perubahan.

tes. Lebih realistis, sebuah SCI adalah dokumen, sebuah suite seluruh kasus uji, atau bernamaProgram komponen (misalnya, C + + fungsi atau sebuah paket Ada).Selain SCIs yang berasal dari produk kerja perangkat lunak, banyak softwareorganisasi rekayasa juga menempatkan perangkat lunak di bawah kontrol konfigurasi.Artinya, versi spesifik dari editor, kompiler, dan alat-alat KASUS lainnya adalah "beku"sebagai bagian dari konfigurasi perangkat lunak. Karena alat ini digunakan untuk menghasilkan dokumentasi,kode sumber, dan data, mereka harus tersedia bila perubahan perangkat lunakkonfigurasi yang harus dibuat. Meskipun masalah ini jarang terjadi, ada kemungkinan bahwaversi baru alat (misalnya, kompilator) bisa menghasilkan hasil yang berbeda dari yang asliversi. Untuk alasan ini, alat-alat, seperti perangkat lunak yang mereka membantu untuk menghasilkan, dapatmenjadi baselined sebagai bagian dari proses manajemen konfigurasi yang komprehensif.Pada kenyataannya, SCIs disusun untuk membentuk obyek konfigurasi yang mungkin di katalogdalam database proyek dengan nama tunggal. Sebuah objek konfigurasi memiliki nama, atribut,dan "terhubung" ke obyek lain oleh hubungan. Mengacu pada Gambar 9.2, makakonfigurasi objek, Desain Spesifikasi, data model, N komponen, sumberkode dan Uji Spesifikasi masing-masing didefinisikan secara terpisah. Namun, masing-masingobyek berhubungan dengan yang lain seperti yang ditunjukkan oleh panah. Sebuah panah melengkung menunjukkankomposisi hubungan. Artinya, model data dan komponen N merupakan bagian dari objekSpesifikasi desain. Sebuah panah lurus berkepala dua mengindikasikan suatu hubungan timbal balik.

Jika perubahan yang dilakukan terhadap kode obyek sumber, keterkaitan memungkinkan perangkat lunakinsinyur untuk menentukan apa benda lain (dan SCIs) mungkin affected.19.2 PROSES SCMmanajemen konfigurasi perangkat lunak merupakan elemen penting dari kualitas perangkat lunakjaminan. tanggung jawab utamanya adalah kontrol perubahan. Namun, SCM jugabertanggung jawab untuk identifikasi SCIs individu dan berbagai versi perangkat lunak,audit dari konfigurasi perangkat lunak untuk memastikan bahwa telah benardikembangkan, dan pelaporan semua perubahan konfigurasi diterapkan.Setiap diskusi SCM memperkenalkan serangkaian pertanyaan rumit:• Bagaimana organisasi mengidentifikasi dan mengelola banyak versi yang adaprogram (dan dokumentasi perusahaan) dengan cara yang akan memungkinkan berubah menjadiditampung efisien?• Bagaimana perubahan organisasi kontrol sebelum dan sesudah perangkat lunakdirilis ke pelanggan?• Siapa yang memiliki tanggung jawab untuk menyetujui dan peringkat perubahan?• Bagaimana kita bisa memastikan bahwa perubahan telah dibuat dengan benar?• Mekanisme apa yang digunakan untuk menilai orang lain dari perubahan yang dibuat?Pertanyaan-pertanyaan ini membawa kita ke definisi lima tugas SCM: identifikasi, kontrol versi,perubahan kontrol, konfigurasi audit, dan pelaporan.9.3 IDENTIFIKASI OBJEK DALAM PERANGKAT LUNAKKONFIGURASIUntuk mengontrol dan mengelola item konfigurasi perangkat lunak, masing-masing harus secara terpisah bernamadan kemudian diatur menggunakan pendekatan berorientasi objek. Dua jenis objek dapatdiidentifikasi [CHO89]: objek dasar dan agregat objects.2 Sebuah objek dasar adalah unit "dariteks "yang telah diciptakan oleh seorang insinyur perangkat lunak selama analisa, kode desain,, atauuji. Sebagai contoh, sebuah objek dasar mungkin bagian dari spesifikasi kebutuhan,daftar sumber komponen, atau suite kasus uji yang digunakan untuk latihankode. Sebuah objek agregat adalah kumpulan objek dasar dan objek agregat lainnya.Mengacu pada Gambar 9.2, Desain Spesifikasi adalah sebuah objek agregat. Secara konseptual,itu dapat dilihat sebagai daftar (diidentifikasi) bernama pointer yang menentukan objek dasar sepertisebagai model data dan komponen N.Setiap benda memiliki serangkaian fitur yang berbeda yang mengidentifikasi secara unik: nama, deskripsi,daftar sumber daya, dan "realisasi." Nama objek adalah string karakter yangmengidentifikasi objek jelas. Deskripsi objek adalah daftar dari item data yangmengidentifikasi