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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lain sederhana. Karena setiap kesalahan yang terkandung di dalam sebuah program tidak memiliki sama tingkat kegagalan. 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. Selain mengukur keandalan.The MTTF dan MTTR adalah singkatan rata-time-to-kegagalan dan mean-time-to-perbaikan. Sistem keamanan teknik dirancang untuk mengatasi kegagalan acak dalam sistem-sistem [nonprogrammable]. 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. Lain kesalahan.8. Banyak peneliti berpendapat bahwa MTBF merupakan ukuran yang berguna jauh lebih banyak daripada cacat KLOC / atau cacat / FP. ukuran yang tidak langsung pemeliharaan yang perangkat lunak. 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. Sebagai contoh. end-user berkaitan dengan kegagalan. pertimbangkan sebuah program yang telah beroperasi selama 14 bulan. . masing. dampak terhadap perangkat lunak keandalan diabaikan. kita harus mengembangkan suatu ukuran ketersediaan.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. 8. jumlah kesalahan total memberikan indikasi sedikit keandalan sistem. Banyak kesalahan dalam program ini akan tetap tidak terdeteksi selama beberapa dekade sebelum mereka ditemukan. mungkin memiliki tingkat kegagalan 18 atau 24 bulan. yang belum ditemukan. mereka sering dikendalikan oleh konvensional (Nonprogrammable) mekanik dan perangkat elektronik. Ketika perangkat lunak digunakan sebagai bagian dari sistem kontrol. The MTBF kesalahan jelas seperti itu mungkin menjadi 50 atau bahkan 100 tahun. tidak dengan total kesalahan hitung. Ketersediaan ukuran agak lebih sensitif terhadap MTTR. kompleksitas dapat meningkatkan oleh urutan besarnya atau lebih.

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful