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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful