P. 1
Rekayasa perangkat lunak pendekatan yang dijelaskan dalam buku ini bekerja ke arah

Rekayasa perangkat lunak pendekatan yang dijelaskan dalam buku ini bekerja ke arah

|Views: 738|Likes:
Published by Intan Ninda

More info:

Published by: Intan Ninda on Mar 24, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

11/03/2012

pdf

text

original

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

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

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

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

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

Selama hari-hari awal komputasi (1950-an dan 1960). jaminan kualitas adalah satu-satunya tanggung jawab perajin yang membangun suatu produk. kualitas perangkat lunak jaminan adalah "pola yang terencana dan sistematis tindakan" [SCH98] yang diperlukan untuk memastikan kualitas tinggi dalam perangkat lunak. sebuah definisi definitif kualitas perangkat lunak bisa diperdebatkan tanpa henti. Persyaratan Perangkat Lunak adalah fondasi dari mana kualitas diukur. Jika kriteria tersebut tidak diikuti. "Implikasi untuk perangkat lunak adalah bahwa berbagai konstituen banyak jaminan kualitas perangkat lunak tanggung jawab-perangkat lunak insinyur. Bahkan. Saat ini. kualitas adalah tanggung jawab programmer. 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]. namun gagal untuk memenuhi persyaratan implisit. Ini didasarkan pada pengukuran dan proses yang berkesinambungan perbaikan sebagai elemen kunci dari manajemen mutu. Jika perangkat lunak sesuai dengan eksplisit persyaratan. kurangnya kualitas akan hampir pasti terjadi.Ada sedikit pertanyaan bahwa definisi ini dapat diubah atau diperpanjang. 8. pelanggan. Selama tahun 1940-an. Ruang lingkup tanggung jawab jaminan mutu mungkin terbaik akan ditandai dengan parafrase komersial mobil sekali-populer: "Kualitas Apakah Ayub # 1. lebih formal pendekatan untuk kontrol kualitas yang disarankan. Sejarah jaminan mutu dalam pengembangan perangkat lunak sejajar dengan sejarah kualitas di bidang manufaktur hardware. orang-orang yang melakukan SQA harus melihat perangkat lunak dari titik pandang pelanggan. Memperluas definisi yang disajikan sebelumnya. Artinya. tenaga penjual. Sebelum abad kedua puluh.1 Latar Belakang Masalah Jaminan Mutu adalah kegiatan penting untuk setiap bisnis yang memproduksi produk untuk digunakan oleh orang lain.3. Kelompok SQA berfungsi sebagai perwakilan di-rumah pelanggan. Apakah perangkat lunak cukup memenuhi faktor kualitas mencatat dalam Bab 19? . definisi yang berfungsi untuk menekankan tiga poin penting: 1. 2. standar Ditentukan mendefinisikan seperangkat kriteria pembangunan yang menjadi pedoman cara yang di mana perangkat lunak direkayasa. Kurangnya kesesuaian dengan persyaratan adalah kurangnya kualitas. manajer proyek. Satu set persyaratan implisit sering berjalan tidak disebutkan (misalnya. setiap perusahaan memiliki mekanisme untuk menjamin mutu produk-produknya. dan individu yang melayani dalam grup SQA. keinginan untuk kemudahan penggunaan dan rawatan yang baik). Bahkan. laporan eksplisit perhatian perusahaan untuk kualitas telah menjadi taktik pemasaran selama beberapa dekade terakhir. Untuk tujuan buku ini. kualitas perangkat lunak adalah tersangka. Jaminan kualitas pertama formal dan fungsi kontrol diperkenalkan di Bell Labs pada 1916 dan menyebar dengan cepat seluruh dunia manufaktur. 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. The SQA review grup deskripsi proses untuk kesesuaian dengan kebijakan organisasi. pengawasan.3. 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. dan trek penyimpangan dari proses dan memverifikasi bahwa koreksi telah dibuat. dokumen. Kegiatan ini dilakukan (atau difasilitasi) oleh seorang independen SQA kelompok yang: Menyiapkan rencana SQA untuk sebuah proyek. ISO-9001). melakukan formal tinjauan teknis. analisis. 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. Hanya review dibahas dalam bab ini. pencatatan. pencatatan. kegiatan rekayasa perangkat lunak Tinjauan untuk memverifikasi sesuai dengan yang ditetapkan proses software. insinyur Perangkat Lunak alamat kualitas (dan melaksanakan jaminan kualitas dan kualitas pengendalian kegiatan) dengan menerapkan metode teknis yang solid dan tindakan. Kelompok SQA review pekerjaan yang dipilih . Kelompok SQA mengidentifikasi. dan melakukan pengujian perangkat lunak yang terencana dengan baik. dan pelaporan. Teknologi topik yang dibahas di Bagian Tiga melalui Lima dari buku ini. dan lainnya bagian dari rencana proyek perangkat lunak. Rekayasa Perangkat Lunak Institut [PAU93] merekomendasikan menetapkan aktivitas SQA yang membahas perencanaan jaminan kualitas. kegiatan jaminan mutu yang dilakukan oleh tim rekayasa perangkat lunak dan kelompok SQA diatur oleh rencana.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. pengawasan. eksternal dikenakan standar (misalnya. Program ini dikembangkan selama perencanaan proyek dan direview oleh semua pihak yang berkepentingan. analisis. dan pelaporan. Audit produk perangkat lunak yang ditunjuk bekerja untuk memverifikasi kepatuhan terhadap didefinisikan sebagai bagian dari proses perangkat lunak. standar perangkat lunak internal. 8.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->