Rekayasa perangkat lunak pendekatan yang dijelaskan dalam buku ini bekerja ke arah satu tujuan: untuk menghasilkan

software yang berkualitas tinggi. Namun banyak pembaca akan ditantang oleh pertanyaan: "Apakah kualitas perangkat lunak?" Philip Crosby [CRO79], dalam buku monumentalnya pada kualitas, menyediakan jawaban yang masam pertanyaan ini: Masalah manajemen mutu adalah bukan apa yang orang tidak tahu tentang hal itu. The masalahnya adalah apa yang mereka pikir mereka tahu. . . Dalam hal ini, kualitas memiliki banyak kesamaan dengan seks. Semua orang untuk itu. (Di bawah kondisi tertentu, tentu saja.) Setiap orang merasa mereka memahaminya. (Bahkan meskipun mereka tidak ingin menjelaskannya) Setiap orang berpikir eksekusi. adalah hanya soal berikut kecenderungan alami. (Setelah semua, kita bergaul entah bagaimana.) Dan, tentu saja, kebanyakan orang merasa bahwa masalah-masalah di wilayah tersebut yang disebabkan oleh orang lain. (Kalau saja mereka akan meluangkan waktu untuk melakukan hal yang benar.) Beberapa pengembang perangkat lunak tetap percaya bahwa kualitas perangkat lunak adalah sesuatu Anda mulai khawatir setelah kode telah dihasilkan. Tidak ada yang bisa lebih jauh dari kebenaran! Perangkat Lunak jaminan kualitas (SQA) merupakan kegiatan payung (Bab 2) yang diterapkan selama proses perangkat lunak.

Apa itu? Ini tidak cukup untuk bicara bicara dengan mengatakan perangkat lunak yang kualitas adalah penting, Anda harus (1) secara eksplisit mendefinisikan apa yang dimaksud ketika Anda mengatakan "kualitas perangkat lunak," (2) membuat set kegiatan yang akan membantu memastikan bahwa setiap perangkat lunak rekayasa pameran produk yang tinggi bekerja kualitas, (3) melakukan kegiatan jaminan kualitas pada setiap proyek software, (4) menggunakan metrik untuk mengembangkan strategi untuk meningkatkan perangkat lunak Anda proses dan, sebagai konsekuensinya, kualitas produk akhir. Siapa yang melakukan itu? Setiap orang yang terlibat dalam rekayasa perangkat lunak Proses bertanggung jawab atas kualitas. Mengapa itu penting? Anda dapat melakukannya dengan benar, atau Anda dapat melakukannya lagi. Jika tim software menekankan kualitas dalam semua kegiatan rekayasa perangkat lunak, mengurangi jumlah pengerjaan ulang yang harus dilakukan. Bahwa hasil biaya yang lebih rendah, dan yang lebih penting, peningkatan waktu-ke-pasar.

Quick look Apa langkah-langkah? Sebelum jaminan kualitas perangkat lunak kegiatan dapat dimulai, penting untuk define 'kualitas perangkat lunak' di sejumlah yang berbeda tingkat abstraksi. Setelah Anda memahami apa yang kualitas, tim perangkat lunak harus mengidentifikasi satu set SQA kegiatan yang akan menyaring kesalahan dari produk kerja sebelum mereka meninggal dunia. Apakah produk kerja? Sebuah Jaminan Kualitas Perangkat Lunak Rencana dibuat untuk mendefinisikan sebuah tim software SQA strategi. Selama analisis, desain, dan kode generasi, produk SQA pekerjaan utama adalah formal review teknis ringkasan laporan. Selama pengujian, menguji rencana dan prosedur diproduksi. Pekerjaan lain produk terkait dengan proses perbaikan juga dapat dihasilkan. Bagaimana saya memastikan bahwa saya telah melakukan dengan benar? Cari kesalahan sebelum mereka menjadi cacat! Artinya, bekerja untuk meningkatkan efisiensi cacat penghapusan Anda (Bab 4 dan 7), sehingga mengurangi jumlah ulang bahwa tim perangkat lunak Anda harus melakukan

SQA meliputi (1) pendekatan manajemen mutu, (2) rekayasa perangkat lunak yang efektif teknologi (metode dan alat-alat), (3) formal teknis review yang diterapkan selama proses perangkat lunak, (4) strategi pengujian multitier, (5) kontrol perangkat lunak dokumentasi dan perubahan yang dibuat untuk itu, (6) prosedur untuk memastikan kepatuhan dengan standar pengembangan perangkat lunak (bila ada), dan (7) pengukuran dan mekanisme pelaporan. Dalam bab ini, kita fokus pada isu-isu manajemen dan proses kegiatan khusus yang memungkinkan sebuah organisasi perangkat lunak untuk memastikan bahwa hal itu "hal yang benar pada waktu yang tepat dengan cara yang benar. "

8.1 KUALITAS CONCEPTS1 Dikatakan bahwa tidak ada dua kepingan salju yang sama. Tentu saja ketika kita menonton salju jatuh sulit untuk membayangkan bahwa kepingan salju berbeda sama sekali, apalagi yang menyerpih masing-masing memiliki struktur 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 sebagai serta penciptaan alam. Sebagai contoh, jika dua "identik" papan sirkuit diperiksa dekat cukup, kita boleh mengamati bahwa jalur tembaga pada papan sedikit berbeda dalam geometri, penempatan, dan ketebalan. Selain itu, lokasi dan diameter dibor lubang di papan bervariasi juga. Semua bagian rekayasa dan diproduksi menunjukkan variasi. Variasi antara sampel tidak mungkin jelas tanpa bantuan peralatan yang tepat untuk mengukur geometri, listrik karakteristik, atau atribut lain dari bagian-bagian. Namun, dengan instrumen cukup sensitif, kita mungkin akan sampai pada kesimpulan bahwa tidak ada dua sampel barang apapun yang persis sama. Variasi kontrol adalah jantung dari kontrol kualitas. Produsen A ingin meminimalkan variasi di antara produk yang dihasilkan, bahkan ketika melakukan sesuatu yang relatif sederhana seperti menduplikasi disket. Tentunya, ini tidak dapat menjadi masalah-duplicattesting, menguji rencana dan prosedur diproduksi. Pekerjaan lain produk terkait dengan proses perbaikan juga dapat dihasilkan. Bagaimana saya memastikan bahwa saya telah melakukan dengan benar? Cari kesalahan sebelum mereka menjadi cacat! Artinya, bekerja untuk meningkatkan efisiensi cacat penghapusan Anda (Bab 4 dan 7), sehingga mengurangi jumlah ulang bahwa tim perangkat lunak Anda harus melakukan.

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

kualitas desain produk meningkat.. 8. jika produk diproduksi sesuai dengan spesifikasi.1 Kualitas The American Heritage Dictionary mendefinisikan kualitas sebagai "karakteristik atau atribut dari sesuatu "Sebagai atribut item. Glass berpendapat kualitas yang penting. dan desain dari sistem. (kami pelanggan kemungkinan akan marah jika rilis ketiga produk memiliki sepuluh kali cacat sebanyak rilis sebelumnya) Kami. kualitas mengacu pada karakteristik terukurhal yang kita dapat dibandingkan dengan standar yang dikenal seperti panjang. ada lagi yang benar-benar penting. dua jenis kualitas mungkin ditemui: kualitas desain dan kualitas kesesuaian. dan kelenturan. kualitas kesesuaian adalah tinggi. dan kinerja semua berkontribusi terhadap kualitas desain. Namun demikian. Daftar ini berjalan dan terus. perangkat lunak. Properti ini termasuk cyclomatic kompleksitas.jumlah cacat yang dilepaskan ke lapangan. baris kode. tetapi jika pengguna tidak puas. warna. listrik sifat. spesifikasi. Sekali lagi. toleransi. sebagian besar entitas intelektual. dan banyak lainnya. kami ingin memastikan bahwa varians jumlah bug juga diminimalkan dari satu rilis ke rilis lain. lebih menantang untuk ciri dari benda-benda fisik. dibahas dalam Bab 19 dan 24. Kualitas kesesuaian adalah masalah fokus terutama pada implementasi. DeMarco [DEM99] memperkuat pandangan ini ketika ia . Sebagai bahan-kelas yang lebih tinggi digunakan toleransi. Ketika kita memeriksa item berdasarkan karakteristik terukur.1. Namun. lebih kencang dan lebih besar tingkat kinerja ditentukan. makin tinggi adalah tingkat kualitas kesesuaian. pengukuran karakteristik suatu program memang ada. Jika implementasi mengikuti desain dan yang dihasilkan sistem memenuhi persyaratan dan tujuan kinerja. The grade spesifikasi bahan. Kualitas desain mengacu pada karakteristik yang desainer menentukan untuk item. kualitas desain mencakup persyaratan. semakin besar tingkat kesesuaian. Kualitas kesesuaian adalah tingkat dimana spesifikasi desain diikuti selama manufaktur. ingin meminimalkan perbedaan dalam kecepatan dan ketepatan tanggapan hotline kami dukungan terhadap permasalahan pelanggan. Tapi apakah kualitas desain dan kualitas kesesuaian hanya masalah perangkat lunak insinyur harus mempertimbangkan? Robert Glass [GLA98] berpendapat bahwa lebih "intuitif" hubungan adalah dalam rangka: Pengguna kepuasan = kualitas produk + baik compliant + pengiriman dalam anggaran dan jadwal Di bottom line. Dalam pengembangan perangkat lunak. kohesi. jumlah titik fungsi.

spesifikasi terukur yang kita dapat membandingkan output dari setiap proses. mengidentifikasi peluang untuk mengurangi biaya kualitas. kita dapat mengevaluasi pengaruh perubahan dalam dolar berbasis. Dasar normalisasi hampir selalu dolar. dan tes yang digunakan seluruh proses software untuk memastikan setiap produk memenuhi persyaratan kerja ditempatkan di atasnya. Kualitas biaya dapat dibagi menjadi biaya yang terkait dengan pencegahan. Sebuah konsep kunci dari pengendalian kualitas adalah bahwa semua produk kerja telah menetapkan. Tujuan jaminan kualitas adalah untuk memberikan manajemen dengan data yang diperlukan untuk informasi akan tentang kualitas produk. Setelah kami telah dinormalisasi biaya kualitas secara dolar. Kombinasi pengukuran dan umpan balik memungkinkan kita untuk menyempurnakan proses ketika produk kerja yang diciptakan gagal untuk memenuhi spesifikasi mereka. penilaian. Tetapi bagaimana kita mencapai kualitas kontrol? Kontrol kualitas melibatkan serangkaian inspeksi. review. Pendekatan ini pandangan kendali mutu sebagai bagian dari proses manufaktur. mereka mungkin bersedia untuk mentolerir keandalan sesekali atau kinerja masalah. atau kombinasi alat otomatis dan interaksi manusia. seluruhnya manual. dan memberikan dasar perbandingan normal. adalah tanggung jawab manajemen untuk mengatasi masalah dan menerapkan sumber daya yang diperlukan untuk menyelesaikan masalah kualitas.1. Loop umpan balik sangat penting untuk meminimalkan cacat yang dihasilkan.1. 8. dan kegagalan.3 Jaminan Kualitas Jaminan kualitas terdiri dari audit dan fungsi pelaporan manajemen. 8. sehingga memperoleh wawasan dan keyakinan bahwa produk kualitas pertemuan tujuannya. kegiatan pengendalian Kualitas mungkin sepenuhnya otomatis.4 Biaya Kualitas Biaya kualitas meliputi seluruh biaya yang terjadi dalam mengejar kualitas atau dalam menjalankan kualitas kegiatan terkait. 8. jika data yang diberikan melalui jaminan kualitas mengidentifikasi masalah. Biaya Pencegahan meliputi perencanaan mutu tinjauan teknis formal alat uji Pelatihan Biaya Penilaian meliputi kegiatan untuk mendapatkan wawasan tentang kondisi produk waktu "pertama .1. Selanjutnya. kita memiliki data yang diperlukan untuk mengevaluasi di mana kesempatan berbohong untuk memperbaiki kami proses.2 Pengendalian Mutu Variasi kontrol mungkin disamakan dengan kontrol kualitas. Tentu saja. "berpendapat Pandangan kualitas yang jika produk perangkat lunak menyediakan substansial manfaat untuk-pengguna akhir.menyatakan: "mutu A produk adalah fungsi dari berapa mengubah dunia untuk lebih baik. Biaya studi kualitas dilakukan untuk memberikan baris untuk biaya saat ini kualitas. Kontrol kualitas mencakup loop umpan balik kepada proses yang menciptakan produk kerja.

Biaya kegagalan internal terjadi ketika kita mendeteksi cacat produk kami sebelum pengiriman. sebuah perkembangan empat langkah dasar biasanya dihadapi dan bentuk-bentuk dasar dari setiap program TQM yang baik. biaya relatif untuk menemukan dan memperbaiki cacat meningkat secara dramatis karena kita pergi dari pencegahan untuk mendeteksi kegagalan internal untuk biaya kegagalan eksternal. Contoh biaya penilaian termasuk dalam proses dan inspeksi interprocess peralatan kalibrasi dan pemeliharaan pengujian Biaya Kegagalan adalah mereka yang akan hilang jika tidak ada cacat muncul sebelum pengapalan produk kepada pelanggan. menggambarkan fenomena ini. yang disebut kaizen. pekerjaan mereka bermigrasi ke dunia barat dan diberi nama seperti "manajemen mutu total" (TQM) . Namun. Langkah pertama. Data anekdotal dilaporkan oleh Kaplan. Jepang mengembangkan sistematis pendekatan penghapusan akar penyebab cacat produk.1. Edwards Deming [DEM86] dan telah uji pertama benar di Jepang. Clark. mengacu pada sistem proses perbaikan yang berkesinambungan. manajer senior di perusahaan industri di seluruh dunia mengakui yang menerjemahkan produk berkualitas tinggi dengan biaya tabungan dan garis bawah ditingkatkan. dan Tang [KAP95] memperkuat sebelumnya biaya Statistik dan didasarkan pada pekerjaan di fasilitas pengembangan IBM Rochester 8. Contoh biaya kegagalan eksternal adalah Resolusi keluhan Produk kembali dan penggantian membantu garis dukungan Garansi kerja Seperti yang diharapkan. ini tidak selalu terjadi.2 GERAKAN KUALITAS Hari ini.2 Meskipun terminologi berbeda antar berbagai perusahaan dan penulis. Sepanjang 1970-an dan 1980-an.melalui "setiap proses. Menggunakan ide-ide Deming sebagai suatu landasan. Gerakan kualitas dimulai pada tahun 1940-an dengan pekerjaan seminalis W. Biaya Kegagalan dapat dibagi menjadi biaya kegagalan internal dan Biaya kegagalan eksternal. berdasarkan data yang dikumpulkan oleh Boehm [BOE81] dan lain-lain. . Gambar 8. Biaya kegagalan internal meliputi ulang perbaikan Analisis mode kegagalan Biaya kegagalan eksternal berhubungan dengan cacat yang ditemukan setelah produk telah dikirim ke pelanggan.

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

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

Software pembangunan dilakukan sesuai dengan standar yang ditetapkan sebelumnya? Memiliki disiplin teknis dilakukan dengan benar peran mereka sebagai bagian dari aktivitas SQA? The upaya kelompok SQA untuk menjawab ini dan pertanyaan lain untuk memastikan perangkat lunak yang mutu dipelihara. Rekayasa Perangkat Lunak Institut [PAU93] merekomendasikan menetapkan aktivitas SQA yang membahas perencanaan jaminan kualitas. pengawasan. Program ini dikembangkan selama perencanaan proyek dan direview oleh semua pihak yang berkepentingan. Kelompok SQA review pekerjaan yang dipilih . dan pelaporan. Kelompok SQA mengidentifikasi. dan pelaporan. The SQA review grup deskripsi proses untuk kesesuaian dengan kebijakan organisasi. Hanya review dibahas dalam bab ini. pencatatan. dan trek penyimpangan dari proses dan memverifikasi bahwa koreksi telah dibuat. dan melakukan pengujian perangkat lunak yang terencana dengan baik. analisis. ISO-9001). dokumen. The mengidentifikasi 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 lunak Berpartisipasi dalam pengembangan deskripsi proses proyek perangkat lunak. 8. pencatatan. Kegiatan ini dilakukan (atau difasilitasi) oleh seorang independen SQA kelompok yang: Menyiapkan rencana SQA untuk sebuah proyek.3. insinyur Perangkat Lunak alamat kualitas (dan melaksanakan jaminan kualitas dan kualitas pengendalian kegiatan) dengan menerapkan metode teknis yang solid dan tindakan. dan lainnya bagian dari rencana proyek perangkat lunak. melakukan formal tinjauan teknis. analisis. standar perangkat lunak internal. eksternal dikenakan standar (misalnya. Audit produk perangkat lunak yang ditunjuk bekerja untuk memverifikasi kepatuhan terhadap didefinisikan sebagai bagian dari proses perangkat lunak.2 Aktivitas SQA Software jaminan kualitas terdiri dari berbagai tugas yang berhubungan dengan dua yang berbeda konstituen-perangkat lunak insinyur yang melakukan pekerjaan teknis dan SQA kelompok yang memiliki tanggung jawab untuk perencanaan jaminan kualitas. kegiatan rekayasa perangkat lunak Tinjauan untuk memverifikasi sesuai dengan yang ditetapkan proses software. Tim perangkat lunak memilih proses untuk pekerjaan yang akan dilakukan. Piagam dari kelompok SQA adalah untuk membantu tim software dalam mencapai suatu highquality produk akhir. Teknologi topik yang dibahas di Bagian Tiga melalui Lima dari buku ini. kegiatan jaminan mutu yang dilakukan oleh tim rekayasa perangkat lunak dan kelompok SQA diatur oleh rencana. pengawasan.

jika masalah teknis yang dibahas. Alasan kedua yang kita butuhkan tinjauan teknis adalah bahwa walaupun orang pandai penangkapan beberapa kesalahan mereka sendiri.produk. kualitas daripada yang dapat dicapai tanpa review. desain. Ketidakpatuhan item dilacak sampai mereka diselesaikan. Dalam buku ini. kelompok SQA mengkoordinasikan DNS dan manajemen perubahan (Bab 9) dan membantu untuk mengumpulkan dan menganalisis metrik perangkat lunak. uraian proses. oleh karena itu. 3. dan trek penyimpangan. Masing-masing memiliki tempatnya. Jelaskan diperlukan perbaikan dalam produk satu orang atau tim. Konfirmasi bagian-bagian dari produk di mana perbaikan yang baik tidak diinginkan atau tidak dibutuhkan. 8. atau pekerjaan teknis produk. dokumen. tinjauan diterapkan pada berbagai titik selama pengembangan perangkat lunak dan berfungsi untuk mengungkap kesalahan dan cacat yang kemudian dapat dihapus. dan staf teknis juga merupakan bentuk review. Selain kegiatan tersebut. 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. standar yang berlaku. 2. kelas besar kesalahan melarikan diri originator lebih mudah dari mereka melarikan diri orang lain. Sebuah presentasi formal perancangan perangkat lunak kepada para pelanggan. bagaimanapun. Software review "memurnikan" rekayasa perangkat lunak kegiatan yang kita sebut analisis. Banyak jenis review dapat dilakukan sebagai bagian dari rekayasa perangkat lunak. Memastikan bahwa penyimpangan dalam pekerjaan perangkat lunak dan produk kerja didokumentasikan dan ditangani sesuai dengan prosedur yang terdokumentasi. dan coding. manajemen. kami fokus pada kajian teknis formal. memverifikasi bahwa koreksi telah telah dibuat. Mencapai pekerjaan teknis yang lebih seragam. Sebuah tinjauan teknis formal yang paling efektif filter dari sudut pandang jaminan kualitas. dalam rangka untuk membuat pekerjaan teknis lebih mudah ditangani. mengidentifikasi. dan secara berkala melaporkan hasil kerja kepada manajer proyek. Records setiap ketidakpatuhan dan laporan kepada manajemen senior. Proses review tersebut. atau setidaknya lebih diprediksi. Penyimpangan mungkin ditemui dalam rencana proyek. 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.4 SOFTWARE ULASAN ulasan Perangkat lunak adalah "filter" bagi proses rekayasa perangkat lunak. Sebuah pertemuan informal di sekitar mesin kopi merupakan bentuk review. Artinya. kadang-kadang disebut sebagai panduan atau inspeksi. Dilakukan oleh para insinyur perangkat lunak (dan .

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

total biaya untuk pengembangan dan pemeliharaan saat review dilakukan adalah 783 unit biaya.4. Bila tidak ada review yang dilakukan.8. dan langkah-langkah coding dari proses rekayasa perangkat lunak. unit biaya 6.5 sebelum ujian.3 mengilustrasikan sebuah contoh hipotetis amplifikasi cacat untuk perangkat lunak proses pembangunan di mana tidak ada review dilakukan. Dengan menggunakan data tersebut. Jumlah kesalahan ditemukan pada setiap langkah-langkah dicatat dalam Angka 8. Gambar 8. dan 67 biaya unit setelah rilis).4 dikalikan dengan biaya untuk menghapus kesalahan (Unit biaya 1. Mengingat biaya relatif yang terkait dengan penemuan dan koreksi kesalahan. masingmasing langkah uji diasumsikan untuk mengungkap dan benar 50 persen dari semua kesalahan yang masuk tanpa memperkenalkan kesalahan baru (asumsi optimis). hasil sebelumnya contoh meninggalkan sedikit keraguan bahwa kita bisa membayar sekarang atau membayar jauh lebih kemudian. x) dengan pekerjaan saat ini. mungkin kesalahan secara tidak sengaja dihasilkan.2. fungsi dari ketelitian yang tinjauan. kecuali desain itu dan Ulasan kode dilakukan sebagai bagian dari setiap langkah pembangunan. Dua belas kesalahan laten yang dirilis ke lapangan. Namun. Sepuluh desain awal cacat diperkuat untuk 94 kesalahan sebelum pengujian dimulai.4 mempertimbangkan kondisi yang sama. Selama langkah ini. sepuluh awal kesalahan desain awal yang diperkuat dengan 24 error sebelum pengujian dimulai. unit biaya 15 selama pengujian. Untuk melakukan review. Hanya tiga kesalahan laten ada.3 dan 8. Sebuah kotak merupakan langkah pengembangan perangkat lunak. biaya keseluruhan (dengan dan tanpa ulasan untuk hipotetis kami misalnya) dapat dibentuk. total biaya adalah 2177 unit-hampir tiga kali lebih mahal. Dalam hal ini. kesalahan melewati dari langkah sebelumnya diperkuat (amplifikasi faktor. Gambar 8.5 TEKNIS ULASAN FORMAL Sebuah tinjauan teknis formal adalah jaminan kualitas perangkat lunak kegiatan yang dilakukan oleh perangkat lunak . sehingga beberapa nomor kesalahan yang lewat. Model ini diilustrasikan pada Gambar skematis 8. Review mungkin gagal untuk menemukan kesalahan yang baru dibuat dan kesalahan dari langkah sebelumnya.5 untuk desain. Mengacu pada gambar. Dalam beberapa kasus. software engineer harus mengeluarkan waktu dan usaha dan pengembangan organisasi harus mengeluarkan uang. perancangan detail. 8. Subdivisi kotak mewakili masing-masing karakteristik dan persen efisiensi untuk mendeteksi kesalahan.2 Cacat Amplifikasi dan Penghapusan Sebuah model amplifikasi cacat [IBM81] dapat digunakan untuk menggambarkan generasi dan deteksi kesalahan selama desain awal.

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

menjelaskan materi. sedangkan tinjauan mengangkat isu berdasarkan persiapan muka mereka. Review 8. Ini menjadi bagian dari catatan sejarah proyek dan dapat didistribusikan ke proyek pemimpin dan pihak lain yang berkepentingan. dan kemudian diikuti. Selain itu. Pada akhir review. perekam catatan masing-masing. tapi tidak ada tambahan review akan diperlukan). Ketika berlaku masalah atau kesalahan ditemukan. 8. Kesalahan harus ditunjukkan dengan lembut. adalah mungkin bahwa masalah yang diangkat dapat "jatuh antara retak. niat tersebut tidak boleh mempermalukan atau . Keputusan dibuat. ringkasan laporan review teknis formal selesai. FTR bisa mengambil aura dari inkuisisi. Sebuah review yang tidak terkendali sering bisa lebih buruk bahwa ada ulasan sama sekali. Review produk. Sebuah laporan ringkasan memeriksa jawaban tiga pertanyaan: 1. Sebuah daftar masalah biasanya menempel pada ringkasan laporan. (2) menolak produk karena kesalahan berat (Sekali dikoreksi. disepakati. Ini diringkas pada akhir pertemuan kajian dan isu tinjauan daftar diproduksi. semua peserta FTR menyelesaikan sign-off. Apa yang ditinjau? 2. Dilakukan dengan benar." adalah Satu pendekatan untuk menetapkan tanggung jawab untuk ikutan kepada pemimpin review. Kecuali ini dilakukan.5.2 Pelaporan dan Penyimpanan Catatan Selama FTR. atau (3) menerima produk sementara (Kesalahan kecil telah ditemukan dan harus dikoreksi. Apa temuan dan kesimpulan? Ringkasan laporan review adalah bentuk halaman (dengan lampiran mungkin).3 Petunjuk tentang Tinjauan Pedoman untuk melakukan tinjauan teknis formal harus didirikan di muka. Siapa yang ditinjau itu? 3. Tinjauan masalah daftar melayani dua tujuan: (1) mengidentifikasi masalah dalam produk dan (2) untuk melayani sebagai daftar item tindakan yang memandu produsen sebagai koreksi dibuat. Melakukan benar.5. FTR Sebuah melibatkan orang dan ego. nada rapat harus longgar dan konstruktif. Sangat penting untuk menetapkan prosedur-tindak lanjut untuk memastikan bahwa item pada isu-isu daftar sudah benar dikoreksi. review lain harus dilakukan). bukan produsen. didistribusikan kepada semua tinjauan. menunjukkan partisipasi mereka dalam tinjauan dan persetujuan mereka dengan meninjau temuan tim. Berikut adalah minimum seperangkat pedoman untuk review teknis formal: 1. FTR harus meninggalkan semua peserta dengan perasaan hangat prestasi.kemudian mulai "berjalan melalui" produk kerja. seorang penulis resensi (perekam) aktif mencatat semua masalah yang telah terangkat. semua peserta dari FTR harus memutuskan apakah akan (1) menerima produk tanpa modifikasi lebih lanjut.

Untuk review menjadi efektif. A review bukan sesi pemecahan masalah. Daripada menghabiskan waktu berdebat pertanyaan. jumlah peserta. 2. masalah daerah memberitahukan. 9. 4. masalah harus dicatat untuk diskusi lebih lanjut secara off-line. tapi 14 belum tentu lebih baik dari 4. Batas perdebatan dan bantahan. Jauhkan jumlah orang yang terlibat untuk jumlah minimum yang diperlukan. 10. Namun. 8. Dalam Selain itu. komentar tertulis harus diminta oleh pemimpin review (memberikan indikasi bahwa resensi tersebut telah review materi). Mengalokasikan sumber daya dan waktu jadwal untuk FTRs. 5. jenis produk kerja. mereka harus dijadwalkan sebagai tugas selama proses rekayasa perangkat lunak. 6. Debriefing dapat bermanfaat dalam mengungkap masalah dengan proses peninjauan itu sendiri. desain. Membuat catatan tertulis. Membatasi jumlah peserta dan menuntut persiapan terlebih dahulu. Kadang-kadang ide yang baik untuk perekam untuk membuat catatan di papan dinding. meninjau semua anggota tim harus menyiapkan terlebih dahulu. mungkin ada tidak ada kesepakatan universal tentang dampaknya. Sebuah FTR harus disimpan di jalur dan jadwal. Tinjauan pemimpin yang disewa dengan tanggung jawab untuk menjaga jadwal pertemuan dan tidak perlu takut untuk mendorong orang-orang ketika drift set masuk 3. 7. Pelatihan harus menekankan kedua proses-terkait isu-isu dan sisi psikologis manusia tinjauan. Produk pertama yang akan ditinjau harus meninjau pedoman itu sendiri. Pemecahan masalah harus ditunda sampai setelah pertemuan kajian. Solusi dari masalah seringkali dapat dicapai oleh produsen sendiri atau dengan bantuan hanya satu lainnya individu. Salah satu penyakit kunci rapat semua adalah jenis drift. waktu harus dijadwalkan untuk modifikasi tak terelakkan yang akan terjadi sebagai hasil dari suatu FTR. Pemimpin review harus melakukan pertemuan kajian untuk memastikan bahwa nada yang tepat dan sikap yang dipertahankan dan harus segera berhenti review yang telah didapat di luar kendali. Freedman dan Weinberg [FRE90] memperkirakan kurva belajar satu bulan untuk setiap 20 orang-orang yang untuk berpartisipasi secara efektif dalam tinjauan. sehingga kata-kata dan prioritas dapat dinilai oleh lain tinjauan sebagai informasi dicatat. Karena banyak variabel (misalnya. Review review awal Anda. pendekatan review tertentu) berdampak pada keberhasilan review . Daftar-pembanding harus dikembangkan untuk analisis.meremehkan. tapi jangan berusaha untuk memecahkan setiap masalah dicatat. kode. Bila masalah dinaikkan oleh sebuah resensi. Dua kepala lebih baik dari satu. waktu dan panjang. A checklist membantu pemimpin penelaahan untuk struktur pertemuan FTR dan membantu setiap resensi untuk fokus pada isu-isu penting. Mengembangkan checklist untuk setiap produk yang kemungkinan akan ditinjau. dan bahkan uji dokumen. Melakukan berarti pelatihan untuk semua tinjauan. Agar efektif semua peserta review harus menerima beberapa pelatihan formal. Tetapkan agenda dan mempertahankannya.

dan pekerjaan dilakukan untuk mengembangkan pendekatan yang sama ketat untuk spesifikasi persyaratan perangkat lunak. Konsep ini relatif sederhana merupakan suatu langkah penting menuju terciptanya suatu rekayasa perangkat lunak adaptif proses di mana perubahan dibuat untuk memperbaiki . Bisa dikatakan bahwa sebuah program komputer adalah objek matematika [SOM96]. Suatu usaha dilakukan untuk menelusuri setiap cacat penyebab nya (misalnya. kesalahan desain. antara lain. Porter dan rekan-rekannya [POR95] memberikan bimbingan yang tepat untuk ini jenis percobaan. Jika model persyaratan (spesifikasi) dan bahasa pemrograman dapat direpresentasikan secara ketat. Upaya untuk membuktikan program yang benar bukanlah hal baru. kontrol yang lebih baik dari produk kerja software dan perubahan yang dibuat untuk mereka. Menggunakan prinsip Pareto (80 persen dari cacat dapat ditelusuri sampai 20 persen dari semua kemungkinan penyebab). sebagai juga melalui penerapan review teknis formal.6 PENDEKATAN FORMAL TERHADAP SQA Pada bagian sebelumnya. jaminan kualitas statistik menunjukkan langkah-langkah berikut: 1. bergerak untuk memperbaiki masalah yang telah menyebabkan cacat. mengisolasi 20 persen (yang "vital few"). Dijkstra [DIJ76] dan Linger. dan Witt [LIN79]. Setelah beberapa penyebab penting telah diidentifikasi. Mills. dari rekayasa perangkat lunak masyarakat berpendapat bahwa pendekatan yang lebih formal untuk jaminan kualitas perangkat lunak diperlukan. strategi pengujian multitier. 2. Untuk perangkat lunak. miskin komunikasi dengan pelanggan). tetapi vokal. desain. 4.7 STATISTIK JAMINAN KUALITAS PERANGKAT LUNAK jaminan kualitas statistik mencerminkan trend yang berkembang di seluruh industri menjadi lebih kuantitatif tentang kualitas. ketidaksesuaian untuk spesifikasi. 8. menganjurkan bukti kebenaran program dan diikat ini dengan penggunaan konsep-konsep pemrograman terstruktur (Bab 16). Selain itu. bahwa hal itu dapat dicapai melalui analisis yang kompeten.organisasi perangkat lunak harus percobaan untuk menentukan apa pendekatan yang terbaik di konteks lokal. Selama dua dekade terakhir. pelanggaran standar. segmen kecil. 3. coding. kami telah berpendapat bahwa kualitas perangkat lunak adalah tugas semua orang. 8. seharusnya mungkin untuk menerapkan matematika bukti kebenaran untuk menunjukkan bahwa program sesuai persis dengan spesifikasinya. kualitas bisa didefinisikan dalam bentuk array yang luas dari faktor kualitas dan diukur (secara tidak langsung) dengan menggunakan berbagai indeks dan metrik. dan pengujian. dan penerapan standar rekayasa perangkat lunak diterima. Sebuah sintaks dan semantik yang ketat dapat didefinisikan untuk setiap pemrograman bahasa. Informasi tentang perangkat lunak cacat dikumpulkan dan dikelompokkan.

Penting untuk dicatat bahwa tindakan korektif berfokus terutama pada beberapa penting. Dalam beberapa kasus. dan EDL akan dipilih sebagai beberapa penyebab penting jika hanya kesalahan serius dipertimbangkan. organisasi rekayasa perangkat lunak dapat mulai tindakan korektif. Misalnya.unsur-unsur dari proses yang memperkenalkan kesalahan. untuk memperbaiki PKS. dan EDR adalah beberapa penyebab penting bahwa account untuk 53 persen dari semua kesalahan. pengembang perangkat lunak dapat menghitung indeks kesalahan (EI) untuk setiap langkah besar dalam proses software {IEE94]. calon baru muncul ke atas tumpukan. Untuk meningkatkan EDR. Tabel 8. 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. bagaimanapun. organisasi perangkat lunak memiliki mencapai pengurangan 50 persen per tahun di cacat setelah menerapkan teknik ini. Perlu dicatat. pengembang mungkin memperoleh CASE tools untuk pemodelan data dan melakukan yang lebih ketat review data desain. PKS. coding. Beberapa cacat yang terungkap sebagai perangkat lunak sedang dikembangkan. Untuk menggambarkan hal ini. Tabel tersebut menunjukkan bahwa IES. bahwa IES. Seperti beberapa penyebab vital dikoreksi. Meskipun ratusan kesalahan yang berbeda yang terungkap. pengujian. data berikut dikumpulkan: Ei = jumlah kesalahan yang ditemukan selama langkah i dalam rekayasa perangkat lunak proses . Dalam kaitannya dengan pengumpulan informasi cacat. pengembang perangkat lunak mungkin menerapkan difasilitasi spesifikasi aplikasi teknik (Bab 11) untuk meningkatkan kualitas komunikasi pelanggan dan spesifikasi. WBP. dan melepaskan. EDR. Setelah analisis.1 dibangun. Setelah beberapa penyebab vital ditentukan. Lain ditemui setelah perangkat lunak telah dirilis untuk-pengguna akhir. desain. teknik statistik jaminan kualitas untuk perangkat lunak telah terbukti memberikan peningkatan kualitas substansial [ART97]. berasumsi bahwa sebuah organisasi rekayasa perangkat lunak mengumpulkan informasi pada cacat untuk jangka waktu satu tahun.

8. Rumit masalah ini lebih jauh. bahkan dalam definisi ini. ukuran sederhana keandalan Sementaraantara-kegagalan (MTBF).96 lebih dari delapan jam pengolahan berlalu..1 Ukuran Reliabilitas dan Ketersediaan Awal bekerja dalam kehandalan perangkat lunak berusaha untuk ekstrapolasi matematika hardware teori keandalan (misalnya. ada gradasi. pertanyaan penting muncul: Apakah yang dimaksud oleh kegagalan panjang? Dalam konteks diskusi kualitas dan kehandalan perangkat lunak. Meskipun link terbantahkan belum harus dibentuk. Di hardware. [ALV64]) untuk prediksi keandalan perangkat lunak.) lebih mungkin daripada kegagalan desain-terkait. Satu kegagalan dapat diperbaiki dalam hitungan detik sementara yang lain memerlukan beberapa minggu atau bahkan bulan untuk benar. pakai (lihat Bab 1) tidak masuk ke dalam gambar. [LIT89].8. shock korosi. sebaliknya adalah benar untuk perangkat lunak. Jika program berulang kali dan sering gagal untuk melakukan. [ROO90]). jika program X dijalankan 100 kali dan membutuhkan delapan jam pengolahan berlalu waktu (waktu eksekusi).8 KEANDALAN PERANGKAT LUNAK Tidak ada keraguan bahwa keandalan program komputer merupakan elemen penting kualitas secara keseluruhan. Sayangnya. akan lebih bermanfaat untuk mempertimbangkan beberapa sederhana konsep yang berlaku untuk kedua elemen sistem. Program X diperkirakan memiliki keandalan 0. kegagalan adalah ketidaksesuaian dengan kebutuhan perangkat lunak. Dengan kata lain. seperti banyak faktor kualitas lainnya. karena memakai fisik (misalnya. kegagalan tersebut pengaruh suhu. Keandalan perangkat lunak didefinisikan dalam statistik istilah sebagai "probabilitas kegagalan operasi bebas dari suatu program komputer dalam lingkungan tertentu untuk waktu tertentu "[MUS87] Untuk menggambarkan. Jika kita mempertimbangkan sistem berbasis komputer. Bahkan. Setiap kali keandalan perangkat lunak dibahas. Sebagian besar Model keandalan perangkat keras yang berhubungan dengan didasarkan pada kegagalan karena memakai daripada kegagalan karena desain cacat. 8. Namun. Telah ada perdebatan tentang hubungan antara konsep-konsep kunci dalam perangkat keras keandalan dan penerapan mereka untuk perangkat lunak (misalnya. kemungkinan untuk beroperasi dengan benar (tanpa kegagalan) 96 kali dari 100. koreksi satu kegagalan mungkin sebenarnya menghasilkan pengenalan kesalahan lain yang pada akhirnya mengakibatkan kegagalan lainnya. dapat diukur dan diarahkan diestimasi dengan menggunakan data historis dan pembangunan. dimana MTBF = MTTF + MTTR . Keandalan perangkat lunak. Kegagalan hanya dapat mengganggu atau bencana. semua kegagalan perangkat lunak dapat ditelusuri ke masalah desain atau pelaksanaan. itu penting sedikit apakah faktor perangkat lunak lain kualitas dapat diterima.

kita harus mengembangkan suatu ukuran ketersediaan. pertimbangkan sebuah program yang telah beroperasi selama 14 bulan. Banyak peneliti berpendapat bahwa MTBF merupakan ukuran yang berguna jauh lebih banyak daripada cacat KLOC / atau cacat / FP. dampak terhadap perangkat lunak keandalan diabaikan. yang belum ditemukan. The MTBF kesalahan jelas seperti itu mungkin menjadi 50 atau bahkan 100 tahun. Ketika perangkat lunak digunakan sebagai bagian dari sistem kontrol. Lain sederhana. Lain kesalahan. Sebagai contoh. Manusia kesalahan desain tidak dianggap karena diasumsikan bahwa semua kesalahan yang disebabkan oleh kesalahan manusia dapat dihindari sepenuhnya atau dihapus sebelum pengiriman dan operasi. Bahkan jika setiap orang dari kategori pertama kesalahan (orang-orang dengan MTBF panjang) dihapus. Software ketersediaan adalah probabilitas bahwa sebuah program sedang beroperasi sesuai dengan persyaratan pada suatu titik waktu tertentu dan didefinisikan sebagai Ketersediaan = [MTTF / (MTTF + MTTR)]? 100% Ukuran reliabilitas MTBF sama sensitif terhadap MTTF dan MTTR. jumlah kesalahan total memberikan indikasi sedikit keandalan sistem. ukuran yang tidak langsung pemeliharaan yang perangkat lunak. Selain mengukur keandalan. kompleksitas dapat meningkatkan oleh urutan besarnya atau lebih. Sistem keamanan teknik dirancang untuk mengatasi kegagalan acak dalam sistem-sistem [nonprogrammable]. Desain halus kesalahan disebabkan oleh manusia-sesuatu kesalahan yang dapat ditemukan dan dieliminasi dalam kontrol konvensional berbasis hardwaremenjadi jauh lebih sulit untuk mengungkap ketika perangkat lunak digunakan.8. Ketersediaan ukuran agak lebih sensitif terhadap MTTR. 8. . mungkin memiliki tingkat kegagalan 18 atau 24 bulan.The MTTF dan MTTR adalah singkatan rata-time-to-kegagalan dan mean-time-to-perbaikan. mereka sering dikendalikan oleh konvensional (Nonprogrammable) mekanik dan perangkat elektronik. end-user berkaitan dengan kegagalan.2 Perangkat Lunak Keamanan Leveson [LEV86] membahas dampak perangkat lunak dalam sistem keamanan kritis ketika dia menulis: Sebelum perangkat lunak yang digunakan dalam sistem keamanan kritis. Banyak kesalahan dalam program ini akan tetap tidak terdeteksi selama beberapa dekade sebelum mereka ditemukan. Karena setiap kesalahan yang terkandung di dalam sebuah program tidak memiliki sama tingkat kegagalan. tidak dengan total kesalahan hitung. masing.

beberapa berbahaya 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 keuntungan Setelah ini sistem-tingkat bahaya diidentifikasi. real-time logika [JAN86]. posisi yang tidak benar dari mekanik perangkat akan menyebabkan bencana kegagalan. Keandalan perangkat lunak menggunakan analisis statistik untuk menentukan kemungkinan bahwa kegagalan perangkat lunak akan terjadi. atau model bersih petri [LEV87] dapat digunakan untuk memprediksi rantai peristiwa yang dapat menyebabkan bahaya dan probabilitas bahwa setiap peristiwa akan terjadi untuk menciptakan rantai. bahaya diidentifikasi dan dikategorikan oleh kekritisan dan risiko. Misalnya. Analisis teknik seperti analisis fault tree [VES81]. perangkat lunak fitur desain dapat ditentukan bahwa baik akan menghilangkan atau mengendalikan potensi bahaya. Awalnya. spesifikasi dapat berisi daftar kejadian yang tidak diinginkan dan yang diinginkan respon sistem untuk peristiwa ini. Namun. Mereka pembaca dengan bunga lebih lanjut harus mengacu pada Leveson buku [LEV95] pada subjek. persyaratan keselamatan terkait dapat dispesifikasikan untuk perangkat lunak. Jika satu set kondisi lingkungan eksternal terpenuhi (dan hanya jika mereka terpenuhi). 8.9 KESALAHAN-proofing UNTUK PERANGKAT LUNAK Jika William Shakespeare memiliki mengomentari kondisi software engineer modern. adalah penting untuk memahami perbedaan halus antara mereka. Artinya. ia mungkin telah menulis: "Untuk kesalahan adalah manusiawi. kesalahan pengguna halus masukan (orang Komponen sistem) dapat diperbesar oleh kesalahan perangkat lunak untuk menghasilkan data kontrol yang benar posisi alat mekanis. Peran perangkat lunak dalam mengelola kejadian yang tidak diinginkan kemudian ditunjukkan. terjadinya kegagalan tidak selalu mengakibatkan bahaya atau kecelakaan. Jika bahaya dapat diidentifikasi pada awal rekayasa perangkat lunak proses. kegagalan tidak dianggap dalam ruang hampa. Meskipun perangkat lunak kehandalan dan keamanan perangkat lunak yang erat terkait satu sama lain. Software keselamatan meneliti cara-cara yang mengakibatkan kegagalan kondisi yang dapat menyebabkan suatu kecelakaan. Sebuah diskusi komprehensif keamanan perangkat lunak adalah di luar cakupan buku ini. perangkat lunak harus dianalisa dalam konteks seluruh sistem. Misalnya. tetapi dievaluasi dalam konteks sistem berbasis komputer secara keseluruhan.Software keselamatan adalah jaminan kualitas perangkat lunak kegiatan yang berfokus pada identifikasi dan penilaian potensi bahaya yang dapat mempengaruhi negatif dan perangkat lunak menyebabkan seluruh sistem gagal. Sebuah proses pemodelan dan analisis dilakukan sebagai bagian dari keamanan perangkat lunak.4 Agar efektif. untuk menemukan kesalahan dengan . teknik analisis digunakan untuk menetapkan keparahan dan kemungkinan occurrence. Setelah bahaya diidentifikasi dan dianalisis. Artinya.

perangkat poka-yoke ini diintegrasikan menjadi sebuah kegiatan rekayasa. memberikan umpan balik yang cepat dan koreksi kesalahan. Masalahnya adalah untuk memastikan bahwa (1) setiap menu entri bisa (ada ratusan) sesuai dengan standar yang tepat dan bahwa tidak ada konflik. Artinya." Untuk melaksanakan yang sesuai entri menu untuk setiap lokal. seorang insinyur industri Jepang. Untuk ujiansaklar pengapian untuk mobil tidak akan bekerja jika transmisi otomatis di gear (alat pencegahan). sebuah "localizer" (orang yang fasih dalam bahasa lokal dan terminologi) menerjemahkan menu yang sesuai. bekerja di Toyota. konsep Shingo's memanfaatkan poka-yoke-mekanisme perangkat yang mengarah ke (1) pencegahan masalah kualitas potensial sebelum itu terjadi atau (2) deteksi cepat masalah kualitas jika mereka diperkenalkan. item menu bahasa Inggris untuk "Close" memiliki mnemonic "C" yang terkait dengannya. mengembangkan teknik jaminan mutu yang menyebabkan pencegahan dan / atau koreksi awal kesalahan dalam proses manufaktur." Karena tim uji tidak fasih dalam 11 bahasa target.. kami mempertimbangkan masalah berikut [ROB97]: Sebuah perangkat lunak menjual produk perusahaan perangkat lunak aplikasi ke pasar internasional.cepat dan benar itu adalah ilahi "Pada tahun 1960. muka pertama kami pada masalah ini adalah untuk memahami bahwa ada dua aspek yang terpisah ke katalog pesan. seperti sebagai mengubah "Close" untuk "Fermer. Jika perangkat terlalu rumit atau mahal. Dengan demikian. Sebagai contoh. Bila aplikasi yang dijual di negara berbahasa Perancis. Ada aspek isi: terjemahan teks sederhana. Penggunaan poka-yoke untuk menguji menu berbagai aplikasi diimplementasikan di berbagai bahasa sebagai hanya dijelaskan akan didiskusikan dalam makalah oleh Harry Robinson [ROB97]: 5 Kami pertama kali memutuskan untuk memecahkan masalah pengujian down menu menjadi bagianbagian yang kami bisa memecahkan. Ini adalah bagian dari proses. Hal ini terletak dekat tugas proses di mana kesalahan terjadi. Untuk menggambarkan. item menu yang sama adalah "Fermer" dengan mnemonic "F. itu akan tidak efektif biaya. bisa diadaptasi untuk digunakan dalam rekayasa perangkat lunak. Kami menemukan pokayoke perangkat dalam kehidupan sehari-hari kita (bahkan jika kita tidak menyadari konsep). The menu pull-down dan mnemonik yang terkait yang disediakan dengan setiap aplikasi harus mencerminkan bahasa lokal. kami harus meninggalkan aspek ini para ahli bahasa. Disebut poka-yoke (Kesalahan-pemeriksaan). Sebuah pameran perangkat efektif poka-yoke satu set karakteristik umum: Ini adalah sederhana dan murah. terlepas dari bahasa yang digunakan. . Meskipun poka-yoke pada awalnya dikembangkan untuk digunakan dalam "nol quality control" [SHI86] untuk hardware diproduksi. beep peringatan sebuah auto akan suara jika sabuk pengaman yang tidak melengkung (perangkat deteksi). Shigeo Shingo [SHI86].

Kita bisa menulis sebuah program untuk memverifikasi label menu dan mnemonik. Kami berlari script kami poka-yoke . dan dapat digunakan untuk memverifikasi bahwa menu dibangun benar dalam target lokal. Sebuah script poka-yoke kecil akan membaca meja.We Pencegahan bisa menulis sebuah program yang akan mencegah localizer dari memilih mnemonik yang tidak memenuhi kriteria. Deteksi perangkat. Tidak seperti konten. diberikan daftar label dalam menu masing-masing. dan dapat memerlukan komunikasi bolak-balik dengan pelokalan. mudah untuk menulis (beberapa ditulis dalam waktu kurang dari satu jam) dan mudah dijalankan. tetapi manfaat yang diperoleh akan minim. Kami bisa menyediakan sebuah program untuk memverifikasi bahwa label menu yang dipilih dan mnemonik memenuhi kriteria di atas. 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 ASCII Peraturan-peraturan ini invarian di locales.Aspek kedua dari katalog pesan yang struktur. mengambil mnemonik dan label dari katalog pesan. tapi masalahnya dari memilih mnemonik yang baik adalah sulit dan upaya yang diperlukan untuk menulis program akan tidak dibenarkan oleh manfaat yang didapat. Script poka-yoke adalah kecil (sekitar 100 baris). Pendekatan ini juga akan mencegah kesalahan. mempertimbangkan label dan mnemonik dari menu aplikasi. aturan sintaks bahwa benar dibangun katalog target harus patuh. Pendekatan ini akan memberikan sangat umpan balik yang cepat pada kesalahan. tetapi kesalahan yang terdeteksi masih mudah untuk memperbaiki pada saat ini. Pendekatan ini adalah jalan kita saat ini sedang. Ada beberapa kemungkinan untuk bagaimana kesalahan-bukti yang mnemonik menu: device. dan kemungkinan sebagai langkah ke depan. Pendekatan ini akan mencegah kesalahan. pelokalan kami bisa menjalankan program di diterjemahkan mereka katalog pesan sebelum mengirim katalog kepada kami. mnemonik salah cukup mudah untuk mendeteksi dan benar setelah mereka terjadi. tanpa isi atau lokal nya. device.We Pencegahan bisa menulis sebuah program untuk menghasilkan mnemonik otomatis. dan menjalankan program pada katalog pesan setelah mereka dikembalikan kepada kami oleh pelokalan. Deteksi perangkat. dan membandingkan string diambil terhadap kriteria yang ditetapkan disebutkan di atas. Sebagai contoh dari apa yang dimaksud dengan struktur. Sebuah menu terdiri dari label dan mnemonik terkait. Hal ini tidak efisien karena beberapa hal di atas metode. Setiap menu. Beberapa kecil poka-yoke script digunakan sebagai perangkat poka-yoke untuk memvalidasi struktural aspek menu. akan mungkin untuk Tim uji untuk memverifikasi aspek struktural dari katalog.

1 Pendekatan ISO untuk Sistem Penjaminan Mutu Model jaminan mutu ISO 9000 memperlakukan perusahaan sebagai jaringan interkoneksi proses. dan Rim Pasifik. Pada gilirannya. kode. kualitas sistem dan operasi perusahaan yang diteliti oleh pihak ketiga auditor untuk kepatuhan terhadap standar dan untuk operasi yang efektif. Contoh ini menggambarkan perangkat poka-yoke yang telah diintegrasikan ke dalam perangkat lunak teknik uji aktivitas. Perangkat poka-yoke ditemukan 311 kesalahan dalam menu dan mnemonik. Semi-surveilans audit tahunan terus memastikan kepatuhan terhadap standar. . produsen produk-produk ini sering membutuhkan pemasok mereka untuk menjadi terdaftar. Standar ISO 9000 telah diadopsi oleh banyak negara termasuk semua anggota Masyarakat Eropa.10. untuk 1200 total menu. suatu negara biasanya hanya mengijinkan ISO perusahaan yang terdaftar untuk memasok barang dan jasa kepada instansi pemerintah dan utilitas umum. pengendalian. Perusahaan swasta seperti mobil dan produsen komputer sering membutuhkan pemasok mereka menjadi ISO terdaftar juga. Negara-negara di Latin dan Amerika Selatan juga telah menunjukkan bunga dalam standar. tanggung jawab. Peralatan telekomunikasi dan alat kesehatan adalah contoh dari kategori produk yang harus disediakan oleh perusahaan ISO terdaftar. Sistem ini mencakup berbagai kegiatan meliputi seluruh hidup suatu produk siklus termasuk perencanaan. Beberapa masalah yang kita ditemukan adalah menghancurkan bumi. pengukuran. Amerika Serikat. Australia. 8. Untuk sistem mutu yang harus sesuai dengan ISO. sistem penjaminan mutu diciptakan untuk membantu organisasi memastikan mereka produk dan jasa memenuhi harapan pelanggan dengan memenuhi spesifikasi mereka. Teknik poka-yoke dapat diterapkan pada desain. dan meningkatkan tingkat kualitas sepanjang pengembangan dan proses manufaktur. New Selandia. Meksiko. Kanada. Setiap lokal berisi 100 menu. dan pengujian tingkat dan memberikan jaminan kualitas yang efektif filter. Setelah mengadopsi standar. Untuk menjadi didaftarkan ke salah satu model sistem jaminan mutu yang terkandung dalam ISO 9000. ISO 9000 menjelaskan unsur-unsur jaminan mutu dalam istilah generik yang dapat diterapkan pada bisnis terlepas dari produk atau jasa yang ditawarkan. pengujian dan pelaporan. tetapi total mereka akan sebesar merupakan gangguan yang besar dalam pengujian dan menjalankan aplikasi lokal kita. sebuah perusahaan mengeluarkan sertifikat dari badan registrasi diwakili oleh auditor.10 ATAS KUALITAS ISO 9000 STANDARDS6 Sistem jaminan kualitas dapat didefinisikan sebagai struktur organisasi.terhadap 16 aplikasi dalam lokal Inggris default ditambah 11 locales asing. dan sumber daya untuk menerapkan manajemen mutu [ANS87]. 8. proses ini harus alamat area yang diidentifikasi dalam standar dan harus didokumentasikan dan dipraktekkan seperti yang dijelaskan. proses. Setelah berhasil pendaftaran. prosedur.

Namun. sistem mutu. pengendalian catatan mutu. Elemen-elemen ini mencakup struktur organisasi.10. atau [SCH94]. perbaikan dan tindakan pencegahan. Bagian awal menjelaskan tujuan dan ruang lingkup dokumen dan menunjukkan perangkat lunak yang kegiatan proses yang tercakup dalam jaminan kualitas. Karena standar ISO 9001 berlaku untuk rekayasa semua disiplin. Sebuah standar untuk rencana SQA telah direkomendasikan oleh IEEE [IEE94]. review kontrak. Akibatnya. jaminan mutu. tugas dan aktivitas SQA dan mereka penempatan selama proses perangkat lunak. 8. Bagian Manajemen dari rencana tersebut menggambarkan tempat SQA dalam struktur organisasi. rencana proyek) ‡ model (misalnya. pengendalian desain. Agar sebuah organisasi perangkat lunak untuk menjadi terdaftar untuk ISO 9001. dan peningkatan kualitas. proses. Untuk informasi lebih lanjut tentang ISO 9001. pelatihan. ERD. dan organisasi peran dan tanggung jawab relatif terhadap kualitas produk.ISO 9000 menggambarkan elemen sebuah sistem jaminan mutu secara umum. dan budaya. dokumen dan data kontrol. [SCH97]. Persyaratan digambarkan oleh ISO 9001 alamat topik seperti manajemen tanggung jawab. ISO 9000 tidak menggambarkan bagaimana suatu organisasi harus menerapkan unsur-unsur sistem mutu. rencana tersebut berfungsi sebagai template untuk aktivitas SQA yang dilembagakan untuk setiap proyek software. tantangan terletak dalam merancang dan menerapkan sistem jaminan kualitas yang sesuai standar dan cocok produk perusahaan. identifikasi dan mampu telusur produk.11 RENCANA SQA Rencana SQA menyediakan peta jalan untuk melembagakan jaminan kualitas perangkat lunak. Dikembangkan oleh kelompok SQA. pelayanan.2 Standar ISO 9001 ISO 9001 adalah standar jaminan kualitas yang berlaku untuk rekayasa perangkat lunak. dan sumber daya yang dibutuhkan untuk melaksanakan perencanaan mutu. pembaca yang tertarik akan melihat [HOY98]. Bagian dokumentasi menjelaskan (referensi) masing-masing produk kerja diproduksi sebagai bagian dari proses perangkat lunak. layanan. The standar berisi 20 persyaratan yang harus hadir untuk jaminan kualitas yang efektif sistem. Semua dokumen tertulis di Rencana SQA terdaftar dan semua standar yang berlaku dicatat. audit mutu internal. hirarki kelas) . dan teknik statistik. satu set khusus pedoman ISO (ISO 9000-3) telah dikembangkan untuk membantu menginterpretasikan standar untuk digunakan dalam proses perangkat lunak. kontrol proses. pengendalian mutu. 8. prosedur. Ini termasuk ‡ Proyek dokumen (misalnya. ia harus menetapkan kebijakan dan prosedur untuk mengatasi setiap persyaratan hanya mencatat (dan lain-lain) dan kemudian dapat menunjukkan bahwa kebijakan dan prosedur sedang diikuti. inspeksi dan pengujian.

dan mengendalikan risiko. Tinjauan teknis formal adalah bergaya pertemuan yang telah terbukti sangat efektif dalam mengungkap kesalahan. bagian ini mendefinisikan set minimum produk kerja yang dapat diterima untuk mencapai kualitas tinggi. menciptakan metode untuk perakitan. SQA rumit dengan kompleksitas perangkat lunak-atribut mutu dari program komputer yang didefinisikan sebagai "kesesuaian untuk secara eksplisit dan implisit ditetapkan persyaratan. Standar. strategi pengujian dan teknik. Ini juga mendefinisikan uji pencatatan persyaratan. review teknis formal. dan bagian konvensi daftar semua standar yang berlaku dan praktik yang diterapkan selama proses perangkat lunak (misalnya. Ulasan berfungsi sebagai filter seluruh kegiatan rekayasa perangkat lunak. Untuk benar melakukan jaminan kualitas perangkat lunak. SQA meliputi prosedur untuk aplikasi yang efektif metode dan alat-alat. dan pelanggan. file bantuan) Selain itu. standar dokumen. mendefinisikan pendekatan manajemen kontrak. kualitas perangkat lunak meliputi banyak berbeda produk dan faktor proses dan metrik terkait. proses. Bagian review dan audit dari rencana mengidentifikasi review dan audit yang akan dilakukan oleh tim rekayasa perangkat lunak. mengidentifikasi pelatihan yang dibutuhkan untuk memenuhi kebutuhan rencana. praktik. 8. dan mendefinisikan metode untuk mengidentifikasi. rencana uji) ‡ pengguna dokumen (misalnya. dan pengukuran dan pelaporan mekanisme. poka-yoke perangkat. menjaga. pemantauan. Masalah pelaporan dan tindakan korektif mendefinisikan prosedur untuk pelaporan. Ulasan Software adalah salah satu kegiatan SQA yang paling penting. dan mengidentifikasi di organisasi tanggung jawab untuk kegiatan ini. pelacakan. Selain itu. coding standar. spesifikasi. semua proyek. Referensi test section Perangkat Lunak Test Rencana dan Prosedur (Bab 18). dan (dalam beberapa kasus) Produk metrik yang akan dikumpulkan sebagai bagian dari rekayasa perangkat lunak kerja terdaftar. referensi perangkat lunak prosedur manajemen konfigurasi untuk perubahan pengendali. menghapus kesalahan saat mereka relatif murah untuk menemukan dan benar. dan memelihara semua catatan. kelompok SQA. dan mengatasi kesalahan dan cacat. Sisa dari Rencana SQA mengidentifikasi alat dan metode yang mendukung SQA kegiatan dan tugas-tugas. menilai. "Tetapi ketika dianggap lebih umum.12 RINGKASAN Software quality assurance merupakan kegiatan payung yang diterapkan pada setiap langkah dalam proses software. Ini memberikan gambaran tentang pendekatan untuk setiap review dan audit. prosedur untuk memastikan kepatuhan terhadap standar. dan pedoman review).‡ teknis dokumen (misalnya. prosedur untuk kontrol perubahan. data tentang rekayasa perangkat lunak .

BAB 9 Apa itu? Ketika Anda membangun komputer perangkat lunak. Bila pemetaan berhasil dicapai. mendirikan hubungan di antara mereka. SCM merupakan bagian penting dari manajemen proyek yang baik dan solid rekayasa perangkat lunak praktek. Dan karena hal itu terjadi. Siapa yang melakukan itu? Setiap orang yang terlibat dalam rekayasa perangkat lunak proses yang terlibat dengan SCM untuk beberapa batas. Perangkat Lunak model keandalan memperpanjang pengukuran. rekayasa perangkat lunak dewasa hasilnya. dan audit dan pelaporan pada perubahan dibuat. adalah ukuran dari rekayasa matang disiplin. Anda perlu mengendalikan secara efektif. perubahan terjadi. mendefinisikan mekanisme untuk mengelola versi yang berbeda dari produk kerja. Untuk alasan itu. Mengapa itu penting? Jika Anda tidak mengontrol berubah. Singkatnya. memungkinkan data cacat dikumpulkan untuk diekstrapolasi ke tingkat kegagalan proyeksi dan prediksi kehandalan. tetapi khusus posisi dukungan kadang-kadang dibuat untuk mengelola proses SCM. Ini sangat mudah untuk suatu aliran perubahan yang tidak terkontrol untuk mengubah baik menjalankan proyek perangkat lunak ke dalam kekacauan. Konfigurasi perangkat lunak manajemen (SCM) adalah serangkaian kegiatan dirancang untuk mengontrol perubahan dengan mengidentifikasi kerja produk yang cenderung berubah. mengendalikan perubahan yang dikenakan. masing-masing harus . kita ingat kata-kata Dunn dan Ullman [DUN82]: "kualitas Perangkat Lunak jaminan adalah pemetaan aturan manajerial dan disiplin desain kualitas jaminan ke ruang manajerial dan teknologi yang berlaku perangkat lunak rekayasa "Kemampuan untuk menjamin kualitas. Dan itu tidak pernah baik. dievaluasi. Statistik SQA membantu untuk meningkatkan kualitas produk dan proses perangkat lunak itu sendiri.proses harus dikumpulkan. kontrol Anda. dan disebarluaskan. Apa langkah-langkah? Karena banyak produk kerja dihasilkan ketika perangkat lunak dibangun.

9. dan untuk memastikan bahwa mereka dengan kebutuhan untuk tahu diberitahu tentang perubahan. pelaporan dilakukan. ketika formal SCM dipanggil. Sebagai proses software berlangsung. Selain itu. Untuk memastikan kualitas yang dipelihara sebagai perubahan yang dibuat. kita membahas kegiatan khusus yang memungkinkan kita untuk mengelola berubah. manajemen konfigurasi perangkat lunak adalah serangkaian pelacakan dan kontrol kegiatan yang dimulai ketika sebuah proyek rekayasa perangkat lunak dimulai dan berakhir hanya ketika perangkat lunak tersebut diambil dari operasi. jumlah item konfigurasi perangkat lunak (SCIs) tumbuh pesat. Apakah produk kerja? The Perangkat Lunak Manajemen Konfigurasi Mendefinisikan rencana proyek strategi untuk SCM. (2) dokumen yang menggambarkan program komputer (ditargetkan pada kedua praktisi teknis dan pengguna). Tujuan utama rekayasa perangkat lunak adalah untuk meningkatkan kemudahan dengan yang perubahan dapat ditampung dan mengurangi jumlah usaha dikeluarkan ketika perubahan harus dibuat. dan (3) data (yang terkandung dalam program atau eksternal untuk itu). proses kontrol perubahan menghasilkan perangkat lunak perubahan permintaan dan laporan dan rekayasa mengubah perintah. Bagaimana saya memastikan bahwa saya telah melakukan dengan benar? Ketika setiap produk kerja dapat dipertanggungjawabkan. Dalam bab ini.diidentifikasi secara unik. ketika setiap orang yang memerlukan untuk mengetahui tentang perubahan telah informed Anda sudah melakukan dengan benar. dan dikendalikan. proses ini diaudit. Setelah ini selesai. Sebuah Spesifikasi Sistem menumbuhkan Software Proyek Rencana dan Software . ke dalam operasi. dilacak. mekanisme kontrol versi dan perubahan bisa dibentuk. Item yang terdiri dari semua informasi yang diproduksi sebagai bagian dari proses software secara bersama disebut konfigurasi perangkat lunak.1 KONFIGURASI PERANGKAT LUNAK MANAJEMEN Output dari proses perangkat lunak adalah informasi yang dapat dibagi menjadi tiga luas kategori: (1) program komputer (baik tingkat sumber dan bentuk executable). ketika setiap perubahan dapat dilacak dan dianalisis.

Ini di gilirannya spawn dokumen lain untuk menciptakan hirarki informasi. Dalam bagian berikut. Hukum Pertama Sistem [BER80] Rekayasa menyatakan: "Tidak peduli di mana Anda berada di sistem siklus hidup. Pelanggan ingin mengubah persyaratan. bagaimana untuk mendapatkannya dilakukan dan masih menghasilkan uang). ada empat sumber dasar dari perubahan: Baru bisnis atau kondisi pasar mendikte perubahan dalam persyaratan produk atau aturan bisnis. Perubahan dapat terjadi setiap saat. Mengapa semua modifikasi ini? Jawabannya benar-benar sangat sederhana. bahwa setelah . untuk alasan apapun. Anggaran atau kendala penjadwalan menyebabkan redefinisi dari sistem atau produk. Jika setiap SCI hanya SCIs lain melahirkan. " Apa adalah asal dari perubahan ini? Jawaban atas pertanyaan ini beragam seperti perubahan itu sendiri. sistem akan berubah.Persyaratan Spesifikasi (serta dokumen-dokumen terkait perangkat keras). Namun. SCM dapat dipandang sebagai kegiatan jaminan kualitas perangkat lunak yang diterapkan di seluruh perangkat lunak proses. Pengetahuan tambahan adalah kekuatan pendorong di belakang perubahan yang paling dan menyebabkan pernyataan fakta yang sulit bagi para praktisi banyak perangkat lunak rekayasa untuk menerima: Kebanyakan perubahan dibenarkan! dasar adalah konsep manajemen konfigurasi perangkat lunak yang membantu kita untuk mengendalikan berubah tanpa serius menghambat perubahan dibenarkan. kebutuhan pelanggan baru modifikasi permintaan data yang dihasilkan oleh informasi sistem. IEEE (IEEE Std. Pengembang ingin memodifikasi pendekatan teknis. No 610. semua konstituen tahu lebih banyak (tentang apa yang mereka butuhkan. variabel lain memasuki proses perubahan. Bahkan. Reorganisasi atau pertumbuhan bisnis menyebabkan perampingan / perubahan dalam proyek prioritas atau perangkat lunak rekayasa struktur tim. Manajer ingin memodifikasi strategi proyek. 9. kami memeriksa tugas-tugas penting dan utama SCM konsep-konsep yang membantu kita untuk mengelola perubahan.12-1990) mendefinisikan awal sebagai: Sebuah spesifikasi atau produk yang telah resmi ditinjau dan disepakati. dan keinginan untuk mengubahnya akan bertahan sepanjang siklus hidup. atau layanan yang diberikan oleh sistem berbasis komputer.1 baseline Perubahan adalah fakta kehidupan dalam pengembangan perangkat lunak. Dengan berjalannya waktu. akan mengakibatkan sedikit kebingungan. manajemen konfigurasi perangkat lunak adalah sekumpulan kegiatan yang telah dikembangkan untuk mengelola perubahan di seluruh siklus hidup perangkat lunak komputer.1. Sayangnya. yang pendekatan akan lebih baik. fungsionalitas disampaikan oleh produk.

Namun. banyak software organisasi rekayasa juga menempatkan perangkat lunak di bawah kontrol konfigurasi. maka konfigurasi objek. Perubahan dapat dibuat. mereka harus tersedia bila perubahan perangkat lunak konfigurasi yang harus dibuat. versi spesifik dari editor. Sebuah panah melengkung . (4) menjelaskan masalah. data model. jika dia meninggalkan dapur. Sebuah objek konfigurasi memiliki nama. sebuah SCI adalah dokumen. alat-alat. tetapi prosedur. Selain SCIs yang berasal dari produk kerja perangkat lunak. meletakkannya di nampan dan kemudian menyadari bahwa dia memilih hidangan yang salah. sumber kode dan Uji Spesifikasi masing-masing didefinisikan secara terpisah. seperti perangkat lunak yang mereka membantu untuk menghasilkan. SCIs disusun untuk membentuk obyek konfigurasi yang mungkin di katalog dalam database proyek dengan nama tunggal. perubahan dapat dilakukan dengan cepat dan informal. masing-masing obyek berhubungan dengan yang lain seperti yang ditunjukkan oleh panah. C + + fungsi atau sebuah paket Ada). kompilator) bisa menghasilkan hasil yang berbeda dari yang asli versi. dan data. memberikan pelanggan piring dan kemudian diberitahu tentang kesalahan. atribut. dia bisa berubah untuk hidangan yang benar cepat dan informal sebelum ia meninggalkan dapur. Satu pintu ditandai OUT dan lain ditandai DI. (3) kembali ke dapur melalui DI pintu. Pada kenyataannya. Jika pelayan mengambil perintah di dapur. kode sumber. kami kiasan melewati satu arah ayun pintu. Artinya. Meskipun masalah ini jarang terjadi. Untuk alasan ini. ia harus mengikuti prosedur yang ditetapkan: (1) melihat periksa untuk menentukan jika kesalahan telah terjadi. Mengacu pada Gambar 9. dasar adalah analog dengan pintu dapur di restoran. dan yang dapat diubah hanya melalui formal perubahan prosedur pengendalian. Namun. sebuah suite seluruh kasus uji. setelah baseline didirikan. spesifik formal harus diterapkan untuk mengevaluasi dan memverifikasi setiap perubahan. (2) mohon maaf sebesar-besarnya. Lebih realistis. tes. dan "terhubung" ke obyek lain oleh hubungan. Desain Spesifikasi. dan sebagainya. Pintu-pintu telah berhenti yang memungkinkan mereka untuk dibuka hanya yang sesuai arah. Sebelum perangkat lunak item konfigurasi menjadi baseline.berfungsi sebagai dasar untuk pengembangan lebih lanjut. ada kemungkinan bahwa versi baru alat (misalnya. dapat menjadi baselined sebagai bagian dari proses manajemen konfigurasi yang komprehensif. atau bernama Program komponen (misalnya. Namun.2. kompiler. dan alat-alat KASUS lainnya adalah "beku" sebagai bagian dari konfigurasi perangkat lunak. Karena alat ini digunakan untuk menghasilkan dokumentasi. Salah satu cara untuk mendeskripsikan data dasar adalah melalui analogi: Pertimbangkan pintu ke dapur di restoran besar. N komponen.

tanggung jawab utamanya adalah kontrol perubahan. deskripsi. daftar sumber daya. itu dapat dilihat sebagai daftar (diidentifikasi) bernama pointer yang menentukan objek dasar seperti sebagai model data dan komponen N. Jika perubahan yang dilakukan terhadap kode obyek sumber. daftar sumber komponen. atau suite kasus uji yang digunakan untuk latihan kode.1 9." Nama objek adalah string karakter yang . atau uji.. dan pelaporan. audit dari konfigurasi perangkat lunak untuk memastikan bahwa telah benar dikembangkan. Artinya.2 Sebuah objek dasar adalah unit "dari teks "yang telah diciptakan oleh seorang insinyur perangkat lunak selama analisa. Sebagai contoh. SCM juga bertanggung jawab untuk identifikasi SCIs individu dan berbagai versi perangkat lunak. Desain Spesifikasi adalah sebuah objek agregat.2. dan "realisasi. Setiap benda memiliki serangkaian fitur yang berbeda yang mengidentifikasi secara unik: nama. model data dan komponen N merupakan bagian dari objek Spesifikasi desain. Sebuah objek agregat adalah kumpulan objek dasar dan objek agregat lainnya. Dua jenis objek dapat diidentifikasi [CHO89]: objek dasar dan agregat objects. kontrol versi. Namun. Setiap diskusi SCM memperkenalkan serangkaian pertanyaan rumit: Bagaimana organisasi mengidentifikasi dan mengelola banyak versi yang ada program (dan dokumentasi perusahaan) dengan cara yang akan memungkinkan berubah menjadi ditampung efisien? Bagaimana perubahan organisasi kontrol sebelum dan sesudah perangkat lunak dirilis 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. keterkaitan memungkinkan perangkat lunak insinyur untuk menentukan apa benda lain (dan SCIs) mungkin affected. kode desain. perubahan kontrol.2 PROSES SCM manajemen konfigurasi perangkat lunak merupakan elemen penting dari kualitas perangkat lunak jaminan. masing-masing harus secara terpisah bernama dan kemudian diatur menggunakan pendekatan berorientasi objek. dan pelaporan semua perubahan konfigurasi diterapkan. Secara konseptual. 9. Sebuah panah lurus berkepala dua mengindikasikan suatu hubungan timbal balik.menunjukkan komposisi hubungan. Mengacu pada Gambar 9. sebuah objek dasar mungkin bagian dari spesifikasi kebutuhan.3 IDENTIFIKASI OBJEK DALAM PERANGKAT LUNAK KONFIGURASI Untuk mengontrol dan mengelola item konfigurasi perangkat lunak. konfigurasi audit.

mengidentifikasi objek jelas. Deskripsi objek adalah daftar dari item data yang mengidentifikasi .

Sign up to vote on this title
UsefulNot useful