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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful