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
jumlah cacat yang dilepaskan ke lapangan, kami ingin memastikan bahwa varians
jumlah bug juga diminimalkan dari satu rilis ke rilis lain. (kami pelanggan
kemungkinan akan marah jika rilis ketiga produk memiliki sepuluh kali cacat sebanyak
rilis sebelumnya) Kami. ingin meminimalkan perbedaan dalam kecepatan dan ketepatan
tanggapan hotline kami dukungan terhadap permasalahan pelanggan. Daftar ini berjalan dan terus.

8.1.1 Kualitas
The American Heritage Dictionary mendefinisikan kualitas sebagai "karakteristik atau atribut
dari
sesuatu "Sebagai atribut item., kualitas mengacu pada karakteristik terukur-
hal yang kita dapat dibandingkan dengan standar yang dikenal seperti panjang, warna, listrik
sifat, dan kelenturan. Namun, perangkat lunak, sebagian besar entitas intelektual, lebih
menantang untuk ciri dari benda-benda fisik.
Namun demikian, pengukuran karakteristik suatu program memang ada. Properti ini
termasuk cyclomatic kompleksitas, kohesi, jumlah titik fungsi, baris kode,
dan banyak lainnya, dibahas dalam Bab 19 dan 24. Ketika kita memeriksa item berdasarkan
karakteristik terukur, dua jenis kualitas mungkin ditemui: kualitas
desain dan kualitas kesesuaian.
Kualitas desain mengacu pada karakteristik yang desainer menentukan untuk item. The
grade spesifikasi bahan, toleransi, dan kinerja semua berkontribusi terhadap
kualitas desain. Sebagai bahan-kelas yang lebih tinggi digunakan toleransi, lebih kencang dan
lebih besar
tingkat kinerja ditentukan, kualitas desain produk meningkat, jika
produk diproduksi sesuai dengan spesifikasi.
Kualitas kesesuaian adalah tingkat dimana spesifikasi desain diikuti
selama manufaktur. Sekali lagi, semakin besar tingkat kesesuaian, makin tinggi
adalah tingkat kualitas kesesuaian.
Dalam pengembangan perangkat lunak, kualitas desain mencakup persyaratan, spesifikasi,
dan desain dari sistem. Kualitas kesesuaian adalah masalah fokus

terutama pada implementasi. Jika implementasi mengikuti desain dan yang dihasilkan
sistem memenuhi persyaratan dan tujuan kinerja, kualitas kesesuaian adalah
tinggi.
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, Glass berpendapat kualitas yang penting, tetapi jika pengguna tidak puas,
ada lagi yang benar-benar penting. DeMarco [DEM99] memperkuat pandangan ini ketika ia
menyatakan: "mutu A produk adalah fungsi dari berapa mengubah dunia untuk
lebih baik. "berpendapat Pandangan kualitas yang jika produk perangkat lunak menyediakan substansial
manfaat untuk-pengguna akhir, mereka mungkin bersedia untuk mentolerir keandalan sesekali atau
kinerja
masalah.
8.1.2 Pengendalian Mutu
Variasi kontrol mungkin disamakan dengan kontrol kualitas. Tetapi bagaimana kita mencapai kualitas
kontrol? Kontrol kualitas melibatkan serangkaian inspeksi, review, dan tes yang digunakan
seluruh proses software untuk memastikan setiap produk memenuhi persyaratan kerja
ditempatkan di atasnya. Kontrol kualitas mencakup loop umpan balik kepada proses yang
menciptakan produk kerja. Kombinasi pengukuran dan umpan balik memungkinkan kita
untuk menyempurnakan proses ketika produk kerja yang diciptakan gagal untuk memenuhi spesifikasi
mereka.
Pendekatan ini pandangan kendali mutu sebagai bagian dari proses manufaktur.
kegiatan pengendalian Kualitas mungkin sepenuhnya otomatis, seluruhnya manual, atau kombinasi
alat otomatis dan interaksi manusia. Sebuah konsep kunci dari pengendalian kualitas adalah
bahwa semua produk kerja telah menetapkan, spesifikasi terukur yang kita dapat membandingkan
output dari setiap proses. Loop umpan balik sangat penting untuk meminimalkan
cacat yang dihasilkan.
8.1.3 Jaminan Kualitas
Jaminan kualitas terdiri dari audit dan fungsi pelaporan manajemen.
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. Tentu saja, jika data yang diberikan melalui jaminan kualitas
mengidentifikasi masalah, adalah tanggung jawab manajemen untuk mengatasi masalah
dan menerapkan sumber daya yang diperlukan untuk menyelesaikan masalah kualitas.
8.1.4 Biaya Kualitas
Biaya kualitas meliputi seluruh biaya yang terjadi dalam mengejar kualitas atau dalam menjalankan
kualitas kegiatan terkait. Biaya studi kualitas dilakukan untuk memberikan baris untuk biaya saat ini
kualitas, mengidentifikasi peluang untuk mengurangi biaya kualitas,
dan memberikan dasar perbandingan normal. Dasar normalisasi
hampir selalu dolar. Setelah kami telah dinormalisasi biaya kualitas secara dolar, kita
memiliki data yang diperlukan untuk mengevaluasi di mana kesempatan berbohong untuk memperbaiki
kami
proses. Selanjutnya, kita dapat mengevaluasi pengaruh perubahan dalam dolar berbasis.
Kualitas biaya dapat dibagi menjadi biaya yang terkait dengan pencegahan, penilaian, dan
kegagalan. Biaya Pencegahan meliputi
• perencanaan mutu
• tinjauan teknis formal
• alat uji
• Pelatihan
Biaya Penilaian meliputi kegiatan untuk mendapatkan wawasan tentang kondisi produk waktu "pertama
melalui "setiap proses. 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 Kegagalan dapat dibagi menjadi biaya kegagalan internal dan
Biaya kegagalan eksternal. Biaya kegagalan internal terjadi ketika kita mendeteksi cacat
produk kami sebelum pengiriman. Biaya kegagalan internal meliputi
• ulang
• perbaikan
• Analisis mode kegagalan
Biaya kegagalan eksternal berhubungan dengan cacat yang ditemukan setelah produk telah
dikirim ke pelanggan. Contoh biaya kegagalan eksternal adalah
• Resolusi keluhan
• Produk kembali dan penggantian
• membantu garis dukungan
• Garansi kerja
Seperti yang diharapkan, biaya relatif untuk menemukan dan memperbaiki cacat meningkat secara
dramatis karena
kita pergi dari pencegahan untuk mendeteksi kegagalan internal untuk biaya kegagalan eksternal.
Gambar
8.1, berdasarkan data yang dikumpulkan oleh Boehm [BOE81] dan lain-lain, menggambarkan fenomena
ini.
Data anekdotal dilaporkan oleh Kaplan, Clark, dan Tang [KAP95] memperkuat sebelumnya biaya
Statistik dan didasarkan pada pekerjaan di fasilitas pengembangan IBM Rochester

8.2 GERAKAN KUALITAS

Hari ini, manajer senior di perusahaan industri di seluruh dunia mengakui
yang menerjemahkan produk berkualitas tinggi dengan biaya tabungan dan garis bawah
ditingkatkan.
Namun, ini tidak selalu terjadi. Gerakan kualitas dimulai pada tahun 1940-an
dengan pekerjaan seminalis W. Edwards Deming [DEM86] dan telah uji pertama benar di
Jepang. Menggunakan ide-ide Deming sebagai suatu landasan, Jepang mengembangkan
sistematis

pendekatan penghapusan akar penyebab cacat produk. Sepanjang

1970-an dan 1980-an, pekerjaan mereka bermigrasi ke dunia barat dan diberi nama
seperti "manajemen mutu total" (TQM) .2 Meskipun terminologi berbeda antar berbagai
perusahaan dan penulis, sebuah perkembangan empat langkah dasar biasanya dihadapi
dan bentuk-bentuk dasar dari setiap program TQM yang baik.
Langkah pertama, yang disebut kaizen, mengacu pada sistem proses perbaikan yang berkesinambungan.

Tujuan kaizen adalah untuk mengembangkan proses (dalam hal ini, proses perangkat lunak) yang
terlihat, diulang, dan terukur.
Langkah kedua, dipanggil hanya setelah kaizen telah dicapai, disebut atarimae
hinshitsu. Langkah ini membahas berwujud yang mempengaruhi proses dan bekerja untuk
mengoptimalkan
dampaknya pada proses. Sebagai contoh, proses perangkat lunak mungkin akan terpengaruh
oleh pergantian staf tinggi, yang itu sendiri disebabkan oleh reorganisasi konstan dalam perusahaan.
Mungkin struktur organisasi yang stabil bisa berbuat banyak untuk meningkatkan kualitas
perangkat lunak. hinshitsu Atarimae akan menyebabkan manajemen untuk menyarankan perubahan
dalam
cara reorganisasi terjadi.
Sementara dua langkah pertama fokus pada proses, langkah berikutnya, yang disebut Kansei
(diterjemahkan
sebagai "panca indera"), berkonsentrasi pada pengguna produk (dalam hal ini, perangkat lunak).
Pada intinya, dengan memeriksa cara pengguna menerapkan Kansei produk mengarah ke
perbaikan dalam produk itu sendiri dan, berpotensi, untuk proses yang menciptakannya.
Akhirnya, langkah yang disebut hinshitsu miryokuteki memperluas perhatian manajemen luar
produk langsung. Ini adalah langkah berorientasi bisnis yang mencari peluang
bidang yang terkait diidentifikasi dengan mengamati penggunaan produk di pasar. Dalam
dunia perangkat lunak, hinshitsu miryokuteki mungkin dipandang sebagai upaya untuk mengungkap
baru
dan menguntungkan produk atau aplikasi yang merupakan perkembangan dari yang ada
sistem berbasis komputer.
Bagi kebanyakan perusahaan kaizen harus menjadi perhatian segera. Sampai perangkat lunak dewasa
proses (Bab 2) telah tercapai, tidak ada gunanya di pindah ke berikutnya
langkah.
8.3 JAMINAN KUALITAS PERANGKAT LUNAK
Bahkan pengembang perangkat lunak yang paling letih akan setuju bahwa software yang berkualitas
tinggi adalah
penting tujuan. Tapi bagaimana kita mendefinisikan kualitas? mengipaskan Seorang pernah berkata,
"Setiap program tidak
sesuatu yang benar, itu hanya mungkin bukan hal yang kita inginkan. "
Banyak definisi kualitas perangkat lunak telah diusulkan dalam literatur. Untuk kami
tujuan, kualitas perangkat lunak didefinisikan sebagai
Kesesuaian untuk secara eksplisit dinyatakan persyaratan fungsional dan kinerja, secara eksplisit
didokumentasikan
pengembangan standar, dan karakteristik implisit yang diharapkan dari semua profesional
mengembangkan perangkat lunak.
199
2 Lihat [ART92] untuk pembahasan yang komprehensif TQM dan penggunaannya
Ada sedikit pertanyaan bahwa definisi ini dapat diubah atau diperpanjang. Bahkan, sebuah
definisi definitif kualitas perangkat lunak bisa diperdebatkan tanpa henti. Untuk tujuan
buku ini, definisi yang berfungsi untuk menekankan tiga poin penting:
1. Persyaratan Perangkat Lunak adalah fondasi dari mana kualitas diukur.
Kurangnya kesesuaian dengan persyaratan adalah kurangnya kualitas.
2. standar Ditentukan mendefinisikan seperangkat kriteria pembangunan yang menjadi pedoman cara
yang
di mana perangkat lunak direkayasa. Jika kriteria tersebut tidak diikuti, kurangnya
kualitas akan hampir pasti terjadi.
3. Satu set persyaratan implisit sering berjalan tidak disebutkan (misalnya, keinginan untuk
kemudahan penggunaan dan rawatan yang baik). Jika perangkat lunak sesuai dengan eksplisit
persyaratan, namun gagal untuk memenuhi persyaratan implisit, kualitas perangkat lunak adalah
tersangka.
8.3.1 Latar Belakang Masalah
Jaminan Mutu adalah kegiatan penting untuk setiap bisnis yang memproduksi produk untuk
digunakan oleh orang lain. Sebelum abad kedua puluh, jaminan kualitas adalah satu-satunya
tanggung jawab perajin yang membangun suatu produk. Jaminan kualitas pertama formal
dan fungsi kontrol diperkenalkan di Bell Labs pada 1916 dan menyebar dengan cepat
seluruh dunia manufaktur. Selama tahun 1940-an, lebih formal pendekatan untuk
kontrol kualitas yang disarankan. Ini didasarkan pada pengukuran dan proses yang berkesinambungan
perbaikan sebagai elemen kunci dari manajemen mutu.
Saat ini, setiap perusahaan memiliki mekanisme untuk menjamin mutu produk-produknya. Bahkan,
laporan eksplisit perhatian perusahaan untuk kualitas telah menjadi taktik pemasaran
selama beberapa dekade terakhir.
Sejarah jaminan mutu dalam pengembangan perangkat lunak sejajar dengan sejarah
kualitas di bidang manufaktur hardware. Selama hari-hari awal komputasi (1950-an dan
1960), 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]. Memperluas definisi yang disajikan sebelumnya, kualitas perangkat lunak
jaminan adalah "pola yang terencana dan sistematis tindakan" [SCH98] yang diperlukan
untuk memastikan kualitas tinggi dalam perangkat lunak. Ruang lingkup tanggung jawab jaminan mutu
mungkin
terbaik akan ditandai dengan parafrase komersial mobil sekali-populer: "Kualitas
Apakah Ayub # 1. "Implikasi untuk perangkat lunak adalah bahwa berbagai konstituen banyak
jaminan kualitas perangkat lunak tanggung jawab-perangkat lunak insinyur, manajer proyek,
pelanggan, tenaga penjual, dan individu yang melayani dalam grup SQA.
Kelompok SQA berfungsi sebagai perwakilan di-rumah pelanggan. Artinya, orang-orang
yang melakukan SQA harus melihat perangkat lunak dari titik pandang pelanggan.
Apakah perangkat lunak cukup memenuhi faktor kualitas mencatat dalam Bab 19?

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.
8.3.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, pencatatan,
analisis, dan pelaporan.
insinyur Perangkat Lunak alamat kualitas (dan melaksanakan jaminan kualitas dan kualitas
pengendalian kegiatan) dengan menerapkan metode teknis yang solid dan tindakan, melakukan formal
tinjauan teknis, dan melakukan pengujian perangkat lunak yang terencana dengan baik. Hanya review
dibahas dalam bab ini. Teknologi topik yang dibahas di Bagian Tiga melalui
Lima dari buku ini.
Piagam dari kelompok SQA adalah untuk membantu tim software dalam mencapai suatu highquality
produk akhir. Rekayasa Perangkat Lunak Institut [PAU93] merekomendasikan menetapkan
aktivitas SQA yang membahas perencanaan jaminan kualitas, pengawasan, pencatatan,
analisis, dan pelaporan. Kegiatan ini dilakukan (atau difasilitasi) oleh seorang independen
SQA kelompok yang:
Menyiapkan rencana SQA untuk sebuah proyek. Program ini dikembangkan selama perencanaan proyek
dan direview oleh semua pihak yang berkepentingan. kegiatan jaminan mutu yang dilakukan
oleh tim rekayasa perangkat lunak dan kelompok SQA diatur oleh rencana. 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.
Tim perangkat lunak memilih proses untuk pekerjaan yang akan dilakukan. The SQA
review grup deskripsi proses untuk kesesuaian dengan kebijakan organisasi,
standar perangkat lunak internal, eksternal dikenakan standar (misalnya, ISO-9001), dan lainnya
bagian dari rencana proyek perangkat lunak.
kegiatan rekayasa perangkat lunak Tinjauan untuk memverifikasi sesuai dengan yang ditetapkan
proses software. Kelompok SQA mengidentifikasi, dokumen, dan trek penyimpangan dari
proses dan memverifikasi bahwa koreksi telah dibuat.
Audit produk perangkat lunak yang ditunjuk bekerja untuk memverifikasi kepatuhan terhadap
didefinisikan sebagai bagian dari proses perangkat lunak. Kelompok SQA review pekerjaan yang dipilih
produk; mengidentifikasi, dokumen, dan trek penyimpangan; memverifikasi bahwa koreksi telah
telah dibuat, dan secara berkala melaporkan hasil kerja kepada manajer proyek.
Memastikan bahwa penyimpangan dalam pekerjaan perangkat lunak dan produk kerja
didokumentasikan
dan ditangani sesuai dengan prosedur yang terdokumentasi. Penyimpangan mungkin ditemui
dalam rencana proyek, uraian proses, standar yang berlaku, atau pekerjaan teknis
produk.
Records setiap ketidakpatuhan dan laporan kepada manajemen senior. Ketidakpatuhan
item dilacak sampai mereka diselesaikan.
Selain kegiatan tersebut, kelompok SQA mengkoordinasikan DNS dan manajemen
perubahan (Bab 9) dan membantu untuk mengumpulkan dan menganalisis metrik perangkat lunak.
8.4 SOFTWARE ULASAN
ulasan Perangkat lunak adalah "filter" bagi proses rekayasa perangkat lunak. Artinya, tinjauan
diterapkan pada berbagai titik selama pengembangan perangkat lunak dan berfungsi untuk mengungkap
kesalahan
dan cacat yang kemudian dapat dihapus. Software review "memurnikan" rekayasa perangkat lunak
kegiatan yang kita sebut analisis, desain, dan coding. 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. 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. Proses review tersebut, oleh karena itu, 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. Jelaskan diperlukan perbaikan dalam produk satu orang atau tim;
2. Konfirmasi bagian-bagian dari produk di mana perbaikan yang baik tidak diinginkan atau tidak
dibutuhkan;
3. Mencapai pekerjaan teknis yang lebih seragam, atau setidaknya lebih diprediksi, kualitas daripada
yang dapat
dicapai tanpa review, dalam rangka untuk membuat pekerjaan teknis lebih mudah ditangani.
Banyak jenis review dapat dilakukan sebagai bagian dari rekayasa perangkat lunak.
Masing-masing memiliki tempatnya. Sebuah pertemuan informal di sekitar mesin kopi merupakan
bentuk
review, jika masalah teknis yang dibahas. Sebuah presentasi formal perancangan perangkat lunak
kepada para pelanggan, manajemen, dan staf teknis juga merupakan bentuk review. Dalam buku ini,
bagaimanapun, kami fokus pada kajian teknis formal, kadang-kadang
disebut sebagai panduan atau inspeksi. Sebuah tinjauan teknis formal yang paling efektif
filter dari sudut pandang jaminan kualitas. Dilakukan oleh para insinyur perangkat lunak (dan
lainnya) untuk perangkat lunak insinyur, FTR merupakan cara yang efektif untuk meningkatkan
perangkat lunak
kualitas.
8.4.1 Biaya Dampak Kerusakan Software
Standar IEEE Kamus Istilah Listrik dan Elektronika (IEEE 100 Standard -
1992) mendefinisikan cacat sebagai "produk anomali." Definisi untuk kesalahan dalam perangkat keras
konteks dapat ditemukan dalam Standar IEEE 610,12-1.990:
(A) cacat dalam sebuah perangkat keras atau komponen, misalnya, sebuah sirkuit pendek atau rusak
kawat. (B) tahapan proses, salah, atau definisi data dalam program komputer. Catatan: Ini
Definisi ini digunakan terutama oleh disiplin toleransi kesalahan. Dalam penggunaan umum, istilah
"Kesalahan" dan "bug" digunakan untuk mengungkapkan makna ini. Lihat juga: kesalahan data-sensitif;
programsensitive
kesalahan, kesalahan setara; masking kesalahan, kesalahan berselang.
Dalam konteks proses perangkat lunak, 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). Dalam bab-bab sebelumnya,
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).
Tujuan utama dari tinjauan teknis formal adalah untuk menemukan kesalahan selama proses
sehingga mereka tidak menjadi cacat setelah merilis perangkat lunak. Manfaat jelas
tinjauan teknis formal adalah penemuan awal kesalahan sehingga mereka tidak menyebarkan
ke langkah berikutnya dalam proses perangkat lunak.
Sejumlah penelitian industri (oleh TRW, Nippon Electric, Mitre Corp, antara lain)
menunjukkan bahwa kegiatan desain memperkenalkan persen antara 50 dan 65 dari semua kesalahan
(Dan akhirnya, semua cacat) selama proses perangkat lunak. Namun, teknik tinjauan resmi
telah terbukti sampai 75 persen efektif [JON86] dalam mengungkap desain
kekurangan. Dengan mendeteksi dan menghapus sebagian besar kesalahan ini, proses peninjauan
secara substansial mengurangi biaya langkah-langkah berikutnya dalam pengembangan dan dukungan
fase.
Untuk menggambarkan dampak biaya deteksi dini kesalahan, kami mempertimbangkan serangkaian
relatif
biaya yang didasarkan pada data biaya aktual yang dikumpulkan untuk proyek software besar
[IBM81] .3 Asumsikan bahwa kesalahan ditemukan selama desain akan biaya 1,0 satuan mata uang
untuk memperbaiki. Sehubungan dengan biaya ini, kesalahan yang sama ditemukan tepat sebelum
pengujian dimulai
akan biaya 6,5 unit; selama pengujian, 15 unit, dan setelah rilis, antara 60 dan
100 unit.
8.4.2 Cacat Amplifikasi dan Penghapusan
Sebuah model amplifikasi cacat [IBM81] dapat digunakan untuk menggambarkan generasi dan
deteksi kesalahan selama desain awal, perancangan detail, dan langkah-langkah coding
dari proses rekayasa perangkat lunak. Model ini diilustrasikan pada Gambar skematis
8.2. Sebuah kotak merupakan langkah pengembangan perangkat lunak. Selama langkah ini,
mungkin kesalahan
secara tidak sengaja dihasilkan. Review mungkin gagal untuk menemukan kesalahan yang baru
dibuat dan
kesalahan dari langkah sebelumnya, sehingga beberapa nomor kesalahan yang lewat.
Dalam beberapa kasus, kesalahan melewati dari langkah sebelumnya diperkuat (amplifikasi
faktor, x) dengan pekerjaan saat ini. Subdivisi kotak mewakili masing-masing karakteristik
dan persen efisiensi untuk mendeteksi kesalahan, fungsi dari ketelitian yang
tinjauan.
Gambar 8.3 mengilustrasikan sebuah contoh hipotetis amplifikasi cacat untuk perangkat lunak
proses pembangunan di mana tidak ada review dilakukan. Mengacu pada gambar, masing-
masing
langkah uji diasumsikan untuk mengungkap dan benar 50 persen dari semua kesalahan yang
masuk tanpa
memperkenalkan kesalahan baru (asumsi optimis). Sepuluh desain awal
cacat diperkuat untuk 94 kesalahan sebelum pengujian dimulai. Dua belas kesalahan laten yang
dirilis ke lapangan. Gambar 8.4 mempertimbangkan kondisi yang sama, kecuali desain itu dan
Ulasan kode dilakukan sebagai bagian dari setiap langkah pembangunan. Dalam hal ini, sepuluh
awal
kesalahan desain awal yang diperkuat dengan 24 error sebelum pengujian dimulai.
Hanya tiga kesalahan laten ada. Mengingat biaya relatif yang terkait dengan penemuan
dan koreksi kesalahan, biaya keseluruhan (dengan dan tanpa ulasan untuk hipotetis kami
misalnya) dapat dibentuk. Jumlah kesalahan ditemukan pada setiap
langkah-langkah dicatat dalam Angka 8,3 dan 8,4 dikalikan dengan biaya untuk menghapus
kesalahan
(Unit biaya 1,5 untuk desain, unit biaya 6,5 sebelum ujian, unit biaya 15 selama pengujian, dan
67
biaya unit setelah rilis). Dengan menggunakan data tersebut, total biaya untuk pengembangan
dan pemeliharaan
saat review dilakukan adalah 783 unit biaya. Bila tidak ada review yang dilakukan,
total biaya adalah 2177 unit-hampir tiga kali lebih mahal.
Untuk melakukan review, software engineer harus mengeluarkan waktu dan usaha dan
pengembangan organisasi harus mengeluarkan uang. Namun, hasil sebelumnya
contoh meninggalkan sedikit keraguan bahwa kita bisa membayar sekarang atau membayar jauh
lebih kemudian.

8,5 TEKNIS ULASAN FORMAL

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

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

2. Tetapkan agenda dan mempertahankannya. Salah satu penyakit kunci rapat semua
adalah jenis drift. Sebuah FTR harus disimpan di jalur dan jadwal. Tinjauan
pemimpin yang disewa dengan tanggung jawab untuk menjaga jadwal pertemuan
dan tidak perlu takut untuk mendorong orang-orang ketika drift set masuk
3. Batas perdebatan dan bantahan. Bila masalah dinaikkan oleh sebuah resensi, mungkin ada
tidak ada kesepakatan universal tentang dampaknya. Daripada menghabiskan waktu berdebat
pertanyaan, masalah harus dicatat untuk diskusi lebih lanjut secara off-line.
4. masalah daerah memberitahukan, tapi jangan berusaha untuk memecahkan setiap masalah
dicatat. A
review bukan sesi pemecahan masalah. Solusi dari masalah seringkali dapat
dicapai oleh produsen sendiri atau dengan bantuan hanya satu lainnya
individu. Pemecahan masalah harus ditunda sampai setelah pertemuan kajian.
5. Membuat catatan tertulis. Kadang-kadang ide yang baik untuk perekam untuk membuat
catatan
di papan dinding, sehingga kata-kata dan prioritas dapat dinilai oleh lain
tinjauan sebagai informasi dicatat.
6. Membatasi jumlah peserta dan menuntut persiapan terlebih dahulu. Dua
kepala lebih baik dari satu, tapi 14 belum tentu lebih baik dari 4. Jauhkan
jumlah orang yang terlibat untuk jumlah minimum yang diperlukan. Namun, meninjau semua
anggota tim harus menyiapkan terlebih dahulu. komentar tertulis harus
diminta oleh pemimpin review (memberikan indikasi bahwa resensi tersebut telah
review materi).
7. Mengembangkan checklist untuk setiap produk yang kemungkinan akan ditinjau. A checklist
membantu pemimpin penelaahan untuk struktur pertemuan FTR dan membantu setiap resensi
untuk fokus pada isu-isu penting. Daftar-pembanding harus dikembangkan untuk analisis,
desain, kode, dan bahkan uji dokumen.
8. Mengalokasikan sumber daya dan waktu jadwal untuk FTRs. Untuk review menjadi efektif,
mereka
harus dijadwalkan sebagai tugas selama proses rekayasa perangkat lunak. Dalam
Selain itu, waktu harus dijadwalkan untuk modifikasi tak terelakkan yang akan
terjadi sebagai hasil dari suatu FTR.
9. Melakukan berarti pelatihan untuk semua tinjauan. Agar efektif semua peserta review
harus menerima beberapa pelatihan formal. Pelatihan harus menekankan kedua
proses-terkait isu-isu dan sisi psikologis manusia tinjauan. Freedman
dan Weinberg [FRE90] memperkirakan kurva belajar satu bulan untuk setiap 20
orang-orang yang untuk berpartisipasi secara efektif dalam tinjauan.
10. Review review awal Anda. Debriefing dapat bermanfaat dalam mengungkap masalah
dengan proses peninjauan itu sendiri. Produk pertama yang akan ditinjau
harus meninjau pedoman itu sendiri.
Karena banyak variabel (misalnya, jumlah peserta, jenis produk kerja, waktu
dan panjang, pendekatan review tertentu) berdampak pada keberhasilan review
 organisasi perangkat lunak harus percobaan untuk menentukan apa pendekatan yang terbaik di
konteks lokal. Porter dan rekan-rekannya [POR95] memberikan bimbingan yang tepat untuk ini
jenis percobaan.
8.6 PENDEKATAN FORMAL TERHADAP SQA
Pada bagian sebelumnya, kami telah berpendapat bahwa kualitas perangkat lunak adalah tugas semua
orang;
bahwa hal itu dapat dicapai melalui analisis yang kompeten, desain, coding, dan pengujian, sebagai
juga melalui penerapan review teknis formal, strategi pengujian multitier,
kontrol yang lebih baik dari produk kerja software dan perubahan yang dibuat untuk mereka, dan
penerapan standar rekayasa perangkat lunak diterima. Selain itu, kualitas bisa
didefinisikan dalam bentuk array yang luas dari faktor kualitas dan diukur (secara tidak langsung) dengan
menggunakan
berbagai indeks dan metrik.
Selama dua dekade terakhir, segmen kecil, tetapi vokal, dari rekayasa perangkat lunak
masyarakat berpendapat bahwa pendekatan yang lebih formal untuk jaminan kualitas perangkat lunak
diperlukan. Bisa dikatakan bahwa sebuah program komputer adalah objek matematika
[SOM96]. Sebuah sintaks dan semantik yang ketat dapat didefinisikan untuk setiap pemrograman
bahasa, dan pekerjaan dilakukan untuk mengembangkan pendekatan yang sama ketat untuk spesifikasi
persyaratan perangkat lunak. Jika model persyaratan (spesifikasi) dan
bahasa pemrograman dapat direpresentasikan secara ketat, seharusnya mungkin
untuk menerapkan matematika bukti kebenaran untuk menunjukkan bahwa program sesuai
persis dengan spesifikasinya.
Upaya untuk membuktikan program yang benar bukanlah hal baru. Dijkstra [DIJ76] dan Linger, Mills,
dan Witt [LIN79], antara lain, menganjurkan bukti kebenaran program dan diikat
ini dengan penggunaan konsep-konsep pemrograman terstruktur (Bab 16).
8,7 STATISTIK JAMINAN KUALITAS PERANGKAT LUNAK
jaminan kualitas statistik mencerminkan trend yang berkembang di seluruh industri menjadi
lebih kuantitatif tentang kualitas. Untuk perangkat lunak, jaminan kualitas statistik menunjukkan
langkah-langkah berikut:
1. Informasi tentang perangkat lunak cacat dikumpulkan dan dikelompokkan.
2. Suatu usaha dilakukan untuk menelusuri setiap cacat penyebab nya (misalnya, ketidaksesuaian
untuk spesifikasi, kesalahan desain, pelanggaran standar, miskin
komunikasi dengan pelanggan).
3. Menggunakan prinsip Pareto (80 persen dari cacat dapat ditelusuri sampai 20 persen
dari semua kemungkinan penyebab), mengisolasi 20 persen (yang "vital few").
4. Setelah beberapa penyebab penting telah diidentifikasi, bergerak untuk memperbaiki masalah
yang telah menyebabkan cacat.

Konsep ini relatif sederhana merupakan suatu langkah penting menuju terciptanya
suatu rekayasa perangkat lunak adaptif proses di mana perubahan dibuat untuk memperbaiki
unsur-unsur dari proses yang memperkenalkan kesalahan.
Untuk menggambarkan hal ini, berasumsi bahwa sebuah organisasi rekayasa perangkat lunak
mengumpulkan informasi
pada cacat untuk jangka waktu satu tahun. Beberapa cacat yang terungkap sebagai perangkat lunak
sedang dikembangkan. Lain ditemui setelah perangkat lunak telah dirilis
untuk-pengguna akhir. Meskipun ratusan kesalahan yang berbeda yang terungkap, 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, Tabel 8.1 dibangun. Tabel tersebut menunjukkan bahwa IES, PKS, dan
EDR
adalah beberapa penyebab penting bahwa account untuk 53 persen dari semua kesalahan. Perlu
dicatat,
bagaimanapun, bahwa IES, EDR, WBP, dan EDL akan dipilih sebagai beberapa penyebab penting jika
hanya kesalahan serius dipertimbangkan. Setelah beberapa penyebab vital ditentukan,
organisasi rekayasa perangkat lunak dapat mulai tindakan korektif. Misalnya, untuk memperbaiki
PKS, pengembang perangkat lunak mungkin menerapkan difasilitasi spesifikasi aplikasi
teknik (Bab 11) untuk meningkatkan kualitas komunikasi pelanggan dan
spesifikasi. Untuk meningkatkan EDR, pengembang mungkin memperoleh CASE tools untuk pemodelan
data
dan melakukan yang lebih ketat review data desain.
Penting untuk dicatat bahwa tindakan korektif berfokus terutama pada beberapa penting. Seperti
beberapa penyebab vital dikoreksi, calon baru muncul ke atas tumpukan.
teknik statistik jaminan kualitas untuk perangkat lunak telah terbukti memberikan
peningkatan kualitas substansial [ART97]. Dalam beberapa kasus, organisasi perangkat lunak memiliki
mencapai pengurangan 50 persen per tahun di cacat setelah menerapkan teknik ini.
Dalam kaitannya dengan pengumpulan informasi cacat, pengembang perangkat lunak dapat
menghitung indeks kesalahan (EI) untuk setiap langkah besar dalam proses software {IEE94]. Setelah
analisis, desain, coding, pengujian, dan melepaskan, data berikut dikumpulkan:
Ei = jumlah kesalahan yang ditemukan selama langkah i dalam rekayasa perangkat lunak
proses
8,8 KEANDALAN PERANGKAT LUNAK
Tidak ada keraguan bahwa keandalan program komputer merupakan elemen penting
kualitas secara keseluruhan. Jika program berulang kali dan sering gagal untuk melakukan, itu penting
sedikit apakah faktor perangkat lunak lain kualitas dapat diterima.
Keandalan perangkat lunak, seperti banyak faktor kualitas lainnya, dapat diukur dan diarahkan
diestimasi dengan menggunakan data historis dan pembangunan. 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,. Program X diperkirakan
memiliki keandalan 0,96 lebih dari delapan jam pengolahan berlalu. Dengan kata lain, jika program
X dijalankan 100 kali dan membutuhkan delapan jam pengolahan berlalu
waktu (waktu eksekusi), kemungkinan untuk beroperasi dengan benar (tanpa kegagalan) 96 kali dari
100.
Setiap kali keandalan perangkat lunak dibahas, pertanyaan penting muncul: Apakah yang dimaksud
oleh kegagalan panjang? Dalam konteks diskusi kualitas dan kehandalan perangkat lunak,
kegagalan adalah ketidaksesuaian dengan kebutuhan perangkat lunak. Namun, bahkan dalam definisi
ini,
ada gradasi. Kegagalan hanya dapat mengganggu atau bencana. Satu kegagalan
dapat diperbaiki dalam hitungan detik sementara yang lain memerlukan beberapa minggu atau bahkan
bulan untuk
benar. Rumit masalah ini lebih jauh, koreksi satu kegagalan mungkin sebenarnya
menghasilkan pengenalan kesalahan lain yang pada akhirnya mengakibatkan kegagalan lainnya.
8.8.1 Ukuran Reliabilitas dan Ketersediaan
Awal bekerja dalam kehandalan perangkat lunak berusaha untuk ekstrapolasi matematika hardware
teori keandalan (misalnya, [ALV64]) untuk prediksi keandalan perangkat lunak. Sebagian besar
Model keandalan perangkat keras yang berhubungan dengan didasarkan pada kegagalan karena
memakai daripada
kegagalan karena desain cacat. Di hardware, karena memakai fisik (misalnya, kegagalan tersebut
pengaruh suhu, shock korosi,) lebih mungkin daripada kegagalan desain-terkait.
Sayangnya, sebaliknya adalah benar untuk perangkat lunak. Bahkan, semua kegagalan perangkat lunak
dapat
ditelusuri ke masalah desain atau pelaksanaan; pakai (lihat Bab 1) tidak masuk
ke dalam gambar.
Telah ada perdebatan tentang hubungan antara konsep-konsep kunci dalam perangkat keras
keandalan dan penerapan mereka untuk perangkat lunak (misalnya, [LIT89], [ROO90]). Meskipun
link terbantahkan belum harus dibentuk, akan lebih bermanfaat untuk mempertimbangkan beberapa
sederhana
konsep yang berlaku untuk kedua elemen sistem.
Jika kita mempertimbangkan sistem berbasis komputer, ukuran sederhana keandalan Sementara-
antara-kegagalan (MTBF), dimana
MTBF = MTTF + MTTR
The MTTF dan MTTR adalah singkatan rata-time-to-kegagalan dan mean-time-to-perbaikan,
masing.

Banyak peneliti berpendapat bahwa MTBF merupakan ukuran yang berguna jauh lebih banyak daripada
cacat KLOC /
atau cacat / FP. Lain sederhana, end-user berkaitan dengan kegagalan, tidak dengan total
kesalahan hitung. Karena setiap kesalahan yang terkandung di dalam sebuah program tidak memiliki
sama
tingkat kegagalan, jumlah kesalahan total memberikan indikasi sedikit keandalan sistem.
Sebagai contoh, pertimbangkan sebuah program yang telah beroperasi selama 14 bulan. Banyak
kesalahan dalam program ini akan tetap tidak terdeteksi selama beberapa dekade sebelum mereka
ditemukan.
The MTBF kesalahan jelas seperti itu mungkin menjadi 50 atau bahkan 100 tahun. Lain kesalahan,
yang belum ditemukan, mungkin memiliki tingkat kegagalan 18 atau 24 bulan. Bahkan jika setiap orang
dari kategori pertama kesalahan (orang-orang dengan MTBF panjang) dihapus, dampak terhadap
perangkat lunak
keandalan diabaikan.
Selain mengukur keandalan, kita harus mengembangkan suatu ukuran ketersediaan.
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. Ketersediaan
ukuran agak lebih sensitif terhadap MTTR, ukuran yang tidak langsung pemeliharaan yang
perangkat lunak.
8.8.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, mereka sering dikendalikan
oleh konvensional
(Nonprogrammable) mekanik dan perangkat elektronik. Sistem keamanan teknik
dirancang untuk mengatasi kegagalan acak dalam sistem-sistem [nonprogrammable]. Manusia
kesalahan desain tidak dianggap karena diasumsikan bahwa semua kesalahan yang disebabkan oleh
kesalahan manusia
dapat dihindari sepenuhnya atau dihapus sebelum pengiriman dan operasi.
Ketika perangkat lunak digunakan sebagai bagian dari sistem kontrol, kompleksitas dapat meningkatkan
oleh
urutan besarnya atau lebih. Desain halus kesalahan disebabkan oleh manusia-sesuatu kesalahan
yang dapat ditemukan dan dieliminasi dalam kontrol konvensional berbasis hardware-
menjadi jauh lebih sulit untuk mengungkap ketika perangkat lunak digunakan.
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. Jika bahaya dapat diidentifikasi pada awal rekayasa perangkat lunak
proses, perangkat lunak fitur desain dapat ditentukan bahwa baik akan menghilangkan
atau mengendalikan potensi bahaya.
Sebuah proses pemodelan dan analisis dilakukan sebagai bagian dari keamanan perangkat lunak.
Awalnya,
bahaya diidentifikasi dan dikategorikan oleh kekritisan dan risiko. Misalnya, 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, teknik analisis digunakan untuk menetapkan
keparahan dan kemungkinan occurrence.4 Agar efektif, perangkat lunak harus dianalisa
dalam konteks seluruh sistem. Misalnya, kesalahan pengguna halus masukan (orang
Komponen sistem) dapat diperbesar oleh kesalahan perangkat lunak untuk menghasilkan data kontrol
yang benar posisi alat mekanis. Jika satu set kondisi lingkungan eksternal
terpenuhi (dan hanya jika mereka terpenuhi), posisi yang tidak benar dari mekanik
perangkat akan menyebabkan bencana kegagalan. Analisis teknik seperti analisis fault tree
[VES81], real-time logika [JAN86], 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.
Setelah bahaya diidentifikasi dan dianalisis, persyaratan keselamatan terkait dapat dispesifikasikan
untuk perangkat lunak. Artinya, spesifikasi dapat berisi daftar kejadian yang tidak diinginkan
dan yang diinginkan respon sistem untuk peristiwa ini. Peran perangkat lunak dalam mengelola
kejadian yang tidak diinginkan kemudian ditunjukkan.
Meskipun perangkat lunak kehandalan dan keamanan perangkat lunak yang erat terkait satu sama lain,
adalah penting untuk memahami perbedaan halus antara mereka. Keandalan perangkat lunak
menggunakan analisis statistik untuk menentukan kemungkinan bahwa kegagalan perangkat lunak akan
terjadi. Namun, terjadinya kegagalan tidak selalu mengakibatkan bahaya
atau kecelakaan. Software keselamatan meneliti cara-cara yang mengakibatkan kegagalan kondisi
yang dapat menyebabkan suatu kecelakaan. Artinya, kegagalan tidak dianggap dalam ruang hampa,
tetapi
dievaluasi dalam konteks sistem berbasis komputer secara keseluruhan.
Sebuah diskusi komprehensif keamanan perangkat lunak adalah di luar cakupan buku ini.
Mereka pembaca dengan bunga lebih lanjut harus mengacu pada Leveson buku [LEV95] pada
subjek.
8.9 KESALAHAN-proofing UNTUK PERANGKAT LUNAK
Jika William Shakespeare memiliki mengomentari kondisi software engineer modern,
ia mungkin telah menulis: "Untuk kesalahan adalah manusiawi, untuk menemukan kesalahan dengan
cepat dan benar itu
adalah ilahi "Pada tahun 1960., seorang insinyur industri Jepang, Shigeo Shingo [SHI86], bekerja
di Toyota, mengembangkan teknik jaminan mutu yang menyebabkan pencegahan
dan / atau koreksi awal kesalahan dalam proses manufaktur. Disebut poka-yoke
(Kesalahan-pemeriksaan), 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. Kami menemukan pokayoke
perangkat dalam kehidupan sehari-hari kita (bahkan jika kita tidak menyadari konsep). Untuk ujian-

saklar pengapian untuk mobil tidak akan bekerja jika transmisi otomatis
di gear (alat pencegahan); beep peringatan sebuah auto akan suara jika sabuk pengaman yang
tidak melengkung (perangkat deteksi).
Sebuah pameran perangkat efektif poka-yoke satu set karakteristik umum:
• Ini adalah sederhana dan murah. Jika perangkat terlalu rumit atau mahal, itu akan
tidak efektif biaya.
• Ini adalah bagian dari proses. Artinya, perangkat poka-yoke ini diintegrasikan menjadi sebuah
kegiatan rekayasa.
• Hal ini terletak dekat tugas proses di mana kesalahan terjadi. Dengan demikian,
memberikan umpan balik yang cepat dan koreksi kesalahan.
Meskipun poka-yoke pada awalnya dikembangkan untuk digunakan dalam "nol quality control"
[SHI86] untuk hardware diproduksi, bisa diadaptasi untuk digunakan dalam rekayasa perangkat lunak.
Untuk menggambarkan, kami mempertimbangkan masalah berikut [ROB97]:
Sebuah perangkat lunak menjual produk perusahaan perangkat lunak aplikasi ke pasar internasional.
The
menu pull-down dan mnemonik yang terkait yang disediakan dengan setiap aplikasi harus
mencerminkan
bahasa lokal. Sebagai contoh, item menu bahasa Inggris untuk "Close" memiliki
mnemonic "C" yang terkait dengannya. Bila aplikasi yang dijual di negara berbahasa Perancis,
item menu yang sama adalah "Fermer" dengan mnemonic "F." Untuk melaksanakan yang sesuai
entri menu untuk setiap lokal, sebuah "localizer" (orang yang fasih dalam bahasa lokal dan
terminologi) menerjemahkan menu yang sesuai. Masalahnya adalah untuk memastikan bahwa (1) setiap
menu
entri bisa (ada ratusan) sesuai dengan standar yang tepat dan bahwa tidak ada konflik,
terlepas dari bahasa yang digunakan.
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 bagian-
bagian yang kami bisa memecahkan.
muka pertama kami pada masalah ini adalah untuk memahami bahwa ada dua aspek yang terpisah
ke katalog pesan. Ada aspek isi: terjemahan teks sederhana, seperti
sebagai mengubah "Close" untuk "Fermer." Karena tim uji tidak fasih dalam 11 bahasa target,
kami harus meninggalkan aspek ini para ahli bahasa.
Aspek kedua dari katalog pesan yang struktur, aturan sintaks bahwa
benar dibangun katalog target harus patuh. Tidak seperti konten, akan mungkin untuk
Tim uji untuk memverifikasi aspek struktural dari katalog.
Sebagai contoh dari apa yang dimaksud dengan struktur, mempertimbangkan label dan mnemonik dari
menu aplikasi. Sebuah menu terdiri dari label dan mnemonik terkait. Setiap menu, tanpa
isi atau lokal nya, 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, dan dapat digunakan untuk memverifikasi bahwa
menu dibangun
benar dalam target lokal.
Ada beberapa kemungkinan untuk bagaimana kesalahan-bukti yang mnemonik menu:
device.We Pencegahan bisa menulis sebuah program untuk menghasilkan mnemonik otomatis,
diberikan
daftar label dalam menu masing-masing. Pendekatan ini akan mencegah kesalahan, tapi
masalahnya
dari memilih mnemonik yang baik adalah sulit dan upaya yang diperlukan untuk menulis
program akan
tidak dibenarkan oleh manfaat yang didapat.
device.We Pencegahan bisa menulis sebuah program yang akan mencegah localizer dari memilih
mnemonik yang tidak memenuhi kriteria. Pendekatan ini juga akan mencegah kesalahan,
tetapi manfaat yang diperoleh akan minim; mnemonik salah cukup mudah untuk mendeteksi
dan benar setelah mereka terjadi.
Deteksi perangkat. Kami bisa menyediakan sebuah program untuk memverifikasi bahwa label
menu yang dipilih dan
mnemonik memenuhi kriteria di atas. pelokalan kami bisa menjalankan program di
diterjemahkan mereka
katalog pesan sebelum mengirim katalog kepada kami. Pendekatan ini akan memberikan
sangat umpan balik yang cepat pada kesalahan, dan kemungkinan sebagai langkah ke depan.
Deteksi perangkat. Kita bisa menulis sebuah program untuk memverifikasi label menu dan
mnemonik,
dan menjalankan program pada katalog pesan setelah mereka dikembalikan kepada kami oleh
pelokalan.
Pendekatan ini adalah jalan kita saat ini sedang. Hal ini tidak efisien karena beberapa hal di atas
metode, dan dapat memerlukan komunikasi bolak-balik dengan pelokalan, tetapi
kesalahan yang terdeteksi masih mudah untuk memperbaiki pada saat ini.
Beberapa kecil poka-yoke script digunakan sebagai perangkat poka-yoke untuk memvalidasi
struktural
aspek menu. Sebuah script poka-yoke kecil akan membaca meja, mengambil mnemonik
dan label dari katalog pesan, dan membandingkan string diambil terhadap
kriteria yang ditetapkan disebutkan di atas.
Script poka-yoke adalah kecil (sekitar 100 baris), mudah untuk menulis (beberapa ditulis
dalam waktu kurang dari satu jam) dan mudah dijalankan. Kami berlari script kami poka-yoke
terhadap 16 aplikasi dalam
lokal Inggris default ditambah 11 locales asing. Setiap lokal berisi 100 menu, untuk
1200 total menu. Perangkat poka-yoke ditemukan 311 kesalahan dalam menu dan mnemonik.
Beberapa masalah yang kita ditemukan adalah menghancurkan bumi, tetapi total mereka akan
sebesar merupakan gangguan yang besar dalam pengujian dan menjalankan aplikasi lokal kita.
Contoh ini menggambarkan perangkat poka-yoke yang telah diintegrasikan ke dalam perangkat
lunak
teknik uji aktivitas. Teknik poka-yoke dapat diterapkan pada desain,
kode, dan pengujian tingkat dan memberikan jaminan kualitas yang efektif filter.
8,10 ATAS KUALITAS ISO 9000 STANDARDS6
Sistem jaminan kualitas dapat didefinisikan sebagai struktur organisasi, tanggung jawab,
prosedur, proses, dan sumber daya untuk menerapkan manajemen mutu

[ANS87]. sistem penjaminan mutu diciptakan untuk membantu organisasi memastikan mereka
produk dan jasa memenuhi harapan pelanggan dengan memenuhi spesifikasi mereka.
Sistem ini mencakup berbagai kegiatan meliputi seluruh hidup suatu produk
siklus termasuk perencanaan, pengendalian, pengukuran, pengujian dan pelaporan, dan meningkatkan
tingkat kualitas sepanjang pengembangan dan proses manufaktur. ISO 9000
menjelaskan unsur-unsur jaminan mutu dalam istilah generik yang dapat diterapkan pada bisnis
terlepas dari produk atau jasa yang ditawarkan.
Standar ISO 9000 telah diadopsi oleh banyak negara termasuk semua anggota
Masyarakat Eropa, Kanada, Meksiko, Amerika Serikat, Australia, New
Selandia, dan Rim Pasifik. Negara-negara di Latin dan Amerika Selatan juga telah menunjukkan
bunga dalam standar.
Setelah mengadopsi standar, suatu negara biasanya hanya mengijinkan ISO perusahaan yang terdaftar
untuk memasok barang dan jasa kepada instansi pemerintah dan utilitas umum.
Peralatan telekomunikasi dan alat kesehatan adalah contoh dari kategori produk
yang harus disediakan oleh perusahaan ISO terdaftar. Pada gilirannya, produsen
produk-produk ini sering membutuhkan pemasok mereka untuk menjadi terdaftar. Perusahaan swasta
seperti mobil dan produsen komputer sering membutuhkan pemasok mereka
menjadi ISO terdaftar juga.
Untuk menjadi didaftarkan ke salah satu model sistem jaminan mutu yang terkandung dalam
ISO 9000, kualitas sistem dan operasi perusahaan yang diteliti oleh pihak ketiga
auditor untuk kepatuhan terhadap standar dan untuk operasi yang efektif. Setelah berhasil
pendaftaran, sebuah perusahaan mengeluarkan sertifikat dari badan registrasi diwakili
oleh auditor. Semi-surveilans audit tahunan terus memastikan kepatuhan terhadap
standar.
8.10.1 Pendekatan ISO untuk Sistem Penjaminan Mutu
Model jaminan mutu ISO 9000 memperlakukan perusahaan sebagai jaringan interkoneksi
proses. Untuk sistem mutu yang harus sesuai dengan ISO, proses ini harus
alamat area yang diidentifikasi dalam standar dan harus didokumentasikan dan dipraktekkan
seperti yang dijelaskan.
ISO 9000 menggambarkan elemen sebuah sistem jaminan mutu secara umum.
Elemen-elemen ini mencakup struktur organisasi, prosedur, proses, dan
sumber daya yang dibutuhkan untuk melaksanakan perencanaan mutu, pengendalian mutu, jaminan
mutu,
dan peningkatan kualitas. Namun, ISO 9000 tidak menggambarkan bagaimana suatu organisasi
harus menerapkan unsur-unsur sistem mutu. Akibatnya, tantangan
terletak dalam merancang dan menerapkan sistem jaminan kualitas yang sesuai standar
dan cocok produk perusahaan, layanan, dan budaya.
8.10.2 Standar ISO 9001
ISO 9001 adalah standar jaminan kualitas yang berlaku untuk rekayasa perangkat lunak. The
standar berisi 20 persyaratan yang harus hadir untuk jaminan kualitas yang efektif
sistem. Karena standar ISO 9001 berlaku untuk rekayasa semua disiplin, satu set khusus pedoman
ISO (ISO 9000-3) telah dikembangkan untuk membantu
menginterpretasikan standar untuk digunakan dalam proses perangkat lunak.
Persyaratan digambarkan oleh ISO 9001 alamat topik seperti manajemen
tanggung jawab, sistem mutu, review kontrak, pengendalian desain, dokumen dan data
kontrol, identifikasi dan mampu telusur produk, kontrol proses, inspeksi dan pengujian,
perbaikan dan tindakan pencegahan, pengendalian catatan mutu, audit mutu internal,
pelatihan, pelayanan, dan teknik statistik. Agar sebuah organisasi perangkat lunak untuk
menjadi terdaftar untuk ISO 9001, 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. Untuk informasi lebih lanjut tentang ISO
9001, pembaca yang tertarik akan melihat [HOY98], [SCH97], atau [SCH94].
8,11 RENCANA SQA
Rencana SQA menyediakan peta jalan untuk melembagakan jaminan kualitas perangkat lunak.
Dikembangkan
oleh kelompok SQA, rencana tersebut berfungsi sebagai template untuk aktivitas SQA yang
dilembagakan
untuk setiap proyek software.
Sebuah standar untuk rencana SQA telah direkomendasikan oleh IEEE [IEE94]. Bagian awal
menjelaskan tujuan dan ruang lingkup dokumen dan menunjukkan perangkat lunak yang
kegiatan proses yang tercakup dalam jaminan kualitas. Semua dokumen tertulis di
Rencana SQA terdaftar dan semua standar yang berlaku dicatat. Bagian Manajemen
dari rencana tersebut menggambarkan tempat SQA dalam struktur organisasi, tugas dan aktivitas
SQA
dan mereka penempatan selama proses perangkat lunak, dan organisasi
peran dan tanggung jawab relatif terhadap kualitas produk.
Bagian dokumentasi menjelaskan (referensi) masing-masing produk kerja
diproduksi sebagai bagian dari proses perangkat lunak. Ini termasuk
• Proyek dokumen (misalnya, rencana proyek)
• model (misalnya, ERD, hirarki kelas)
• teknis dokumen (misalnya, spesifikasi, rencana uji)
• pengguna dokumen (misalnya, file bantuan)
Selain itu, bagian ini mendefinisikan set minimum produk kerja yang dapat diterima
untuk mencapai kualitas tinggi.
Standar, praktik, dan bagian konvensi daftar semua standar yang berlaku
dan praktik yang diterapkan selama proses perangkat lunak (misalnya, standar dokumen,
coding standar, dan pedoman review). Selain itu, semua proyek, proses, dan (dalam
beberapa kasus) Produk metrik yang akan dikumpulkan sebagai bagian dari rekayasa perangkat
lunak
kerja terdaftar.
Bagian review dan audit dari rencana mengidentifikasi review dan audit yang akan
dilakukan oleh tim rekayasa perangkat lunak, kelompok SQA, dan pelanggan. Ini
memberikan gambaran tentang pendekatan untuk setiap review dan audit.

Referensi test section Perangkat Lunak Test Rencana dan Prosedur (Bab 18). Ini
juga mendefinisikan uji pencatatan persyaratan. Masalah pelaporan dan tindakan korektif
mendefinisikan prosedur untuk pelaporan, pelacakan, dan mengatasi kesalahan dan cacat, dan
mengidentifikasi
di organisasi tanggung jawab untuk kegiatan ini.
Sisa dari Rencana SQA mengidentifikasi alat dan metode yang mendukung SQA
kegiatan dan tugas-tugas; referensi perangkat lunak prosedur manajemen konfigurasi untuk
perubahan pengendali; mendefinisikan pendekatan manajemen kontrak; menciptakan metode
untuk perakitan, menjaga, dan memelihara semua catatan; mengidentifikasi pelatihan yang dibutuhkan
untuk memenuhi kebutuhan rencana; dan mendefinisikan metode untuk mengidentifikasi, menilai,
pemantauan,
dan mengendalikan risiko.
8,12 RINGKASAN
Software quality assurance merupakan kegiatan payung yang diterapkan pada setiap langkah dalam
proses software. SQA meliputi prosedur untuk aplikasi yang efektif metode
dan alat-alat, review teknis formal, strategi pengujian dan teknik, poka-yoke
perangkat, prosedur untuk kontrol perubahan, prosedur untuk memastikan kepatuhan terhadap
standar,
dan pengukuran dan pelaporan mekanisme.
SQA rumit dengan kompleksitas perangkat lunak-atribut mutu dari
program komputer yang didefinisikan sebagai "kesesuaian untuk secara eksplisit dan implisit ditetapkan
persyaratan. "Tetapi ketika dianggap lebih umum, kualitas perangkat lunak meliputi
banyak berbeda produk dan faktor proses dan metrik terkait.
Ulasan Software adalah salah satu kegiatan SQA yang paling penting. Ulasan berfungsi sebagai
filter seluruh kegiatan rekayasa perangkat lunak, menghapus kesalahan saat mereka
relatif murah untuk menemukan dan benar. Tinjauan teknis formal adalah bergaya
pertemuan yang telah terbukti sangat efektif dalam mengungkap kesalahan.
Untuk benar melakukan jaminan kualitas perangkat lunak, data tentang rekayasa perangkat lunak
proses harus dikumpulkan, dievaluasi, dan disebarluaskan. Statistik SQA
membantu untuk meningkatkan kualitas produk dan proses perangkat lunak itu sendiri. Perangkat Lunak
model keandalan memperpanjang pengukuran, memungkinkan data cacat dikumpulkan untuk
diekstrapolasi
ke tingkat kegagalan proyeksi dan prediksi kehandalan.
Singkatnya, 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. adalah ukuran dari rekayasa matang
disiplin. Bila pemetaan berhasil dicapai, rekayasa perangkat lunak dewasa
hasilnya.

BAB 9

Apa itu? Ketika Anda membangun komputer

perangkat lunak, perubahan terjadi.
Dan karena hal itu terjadi, Anda
perlu mengendalikan secara efektif. Konfigurasi perangkat lunak
manajemen (SCM) adalah serangkaian kegiatan
dirancang untuk mengontrol perubahan dengan mengidentifikasi
kerja produk yang cenderung berubah, mendirikan
hubungan di antara mereka, mendefinisikan mekanisme
untuk mengelola versi yang berbeda dari
produk kerja, mengendalikan perubahan yang dikenakan,
dan audit dan pelaporan pada perubahan
dibuat.
Siapa yang melakukan itu? Setiap orang yang terlibat dalam rekayasa perangkat lunak
proses yang terlibat dengan SCM untuk beberapa
batas, tetapi khusus posisi dukungan kadang-kadang
dibuat untuk mengelola proses SCM.
Mengapa itu penting? Jika Anda tidak mengontrol berubah,
kontrol Anda. Dan itu tidak pernah baik. Ini sangat mudah
untuk suatu aliran perubahan yang tidak terkontrol untuk mengubah
baik menjalankan proyek perangkat lunak ke dalam kekacauan. Untuk alasan itu,
SCM merupakan bagian penting dari manajemen proyek yang baik
dan solid rekayasa perangkat lunak
praktek.
Apa langkah-langkah? Karena banyak produk kerja
dihasilkan ketika perangkat lunak dibangun, masing-masing harus
diidentifikasi secara unik. Setelah ini selesai,
mekanisme kontrol versi dan perubahan bisa
dibentuk. Untuk memastikan kualitas yang dipelihara
sebagai perubahan yang dibuat, proses ini
diaudit; dan untuk memastikan bahwa mereka dengan kebutuhan untuk
tahu diberitahu tentang perubahan, pelaporan
dilakukan.

Apakah produk kerja? The

Perangkat Lunak Manajemen Konfigurasi
Mendefinisikan rencana proyek
strategi untuk SCM. Selain itu, ketika formal SCM
dipanggil, proses kontrol perubahan menghasilkan
perangkat lunak perubahan permintaan dan laporan dan rekayasa
mengubah perintah.
Bagaimana saya memastikan bahwa saya telah melakukan dengan benar? Ketika
setiap produk kerja dapat dipertanggungjawabkan, dilacak,
dan dikendalikan, ketika setiap perubahan dapat
dilacak dan dianalisis, ketika setiap orang yang memerlukan
untuk mengetahui tentang perubahan telah informed
Anda sudah melakukan dengan benar.

ke dalam operasi. 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.
Tujuan utama rekayasa perangkat lunak adalah untuk meningkatkan kemudahan dengan yang
perubahan
dapat ditampung dan mengurangi jumlah usaha dikeluarkan ketika perubahan
harus dibuat. Dalam bab ini, kita membahas kegiatan khusus yang memungkinkan kita untuk mengelola
berubah.
9.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), (2) dokumen
yang menggambarkan program komputer (ditargetkan pada kedua praktisi teknis
dan pengguna), dan (3) data (yang terkandung dalam program atau eksternal untuk itu). Item
yang terdiri dari semua informasi yang diproduksi sebagai bagian dari proses software secara bersama
disebut konfigurasi perangkat lunak.
Sebagai proses software berlangsung, jumlah item konfigurasi perangkat lunak
(SCIs) tumbuh pesat. Sebuah Spesifikasi Sistem menumbuhkan Software Proyek Rencana dan Software
Persyaratan Spesifikasi (serta dokumen-dokumen terkait perangkat keras). Ini di
gilirannya spawn dokumen lain untuk menciptakan hirarki informasi. Jika setiap SCI hanya
SCIs lain melahirkan, akan mengakibatkan sedikit kebingungan. Sayangnya, variabel lain
memasuki proses perubahan. Perubahan dapat terjadi setiap saat, untuk alasan apapun. Bahkan,
Hukum Pertama Sistem [BER80] Rekayasa menyatakan: "Tidak peduli di mana Anda berada di
sistem siklus hidup, sistem akan berubah, dan keinginan untuk mengubahnya akan bertahan
sepanjang siklus hidup. "
Apa adalah asal dari perubahan ini? Jawaban atas pertanyaan ini beragam seperti
perubahan itu sendiri. Namun, ada empat sumber dasar dari perubahan:
• Baru bisnis atau kondisi pasar mendikte perubahan dalam persyaratan produk
atau aturan bisnis.
• kebutuhan pelanggan baru modifikasi permintaan data yang dihasilkan oleh informasi
sistem, fungsionalitas disampaikan oleh produk, atau layanan yang diberikan oleh
sistem berbasis komputer.

• Reorganisasi atau pertumbuhan bisnis menyebabkan perampingan / perubahan dalam proyek

prioritas atau perangkat lunak rekayasa struktur tim.
• 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. SCM dapat
dipandang sebagai kegiatan jaminan kualitas perangkat lunak yang diterapkan di seluruh perangkat
lunak
proses. Dalam bagian berikut, kami memeriksa tugas-tugas penting dan utama SCM
konsep-konsep yang membantu kita untuk mengelola perubahan.
9.1.1 baseline
Perubahan adalah fakta kehidupan dalam pengembangan perangkat lunak. Pelanggan ingin mengubah
persyaratan.
Pengembang ingin memodifikasi pendekatan teknis. Manajer ingin memodifikasi
strategi proyek. Mengapa semua modifikasi ini? Jawabannya benar-benar sangat sederhana.
Dengan berjalannya waktu, semua konstituen tahu lebih banyak (tentang apa yang mereka butuhkan,
yang pendekatan
akan lebih baik, bagaimana untuk mendapatkannya dilakukan dan masih menghasilkan uang).
Pengetahuan tambahan
adalah kekuatan pendorong di belakang perubahan yang paling dan menyebabkan pernyataan fakta
yang sulit
bagi para praktisi banyak perangkat lunak rekayasa untuk menerima: Kebanyakan perubahan
dibenarkan!
dasar adalah konsep manajemen konfigurasi perangkat lunak yang membantu kita untuk mengendalikan
berubah tanpa serius menghambat perubahan dibenarkan. IEEE (IEEE Std. No
610,12-1990) mendefinisikan awal sebagai:
Sebuah spesifikasi atau produk yang telah resmi ditinjau dan disepakati, bahwa setelah
berfungsi sebagai dasar untuk pengembangan lebih lanjut, dan yang dapat diubah hanya melalui formal
perubahan prosedur pengendalian.
Salah satu cara untuk mendeskripsikan data dasar adalah melalui analogi:
Pertimbangkan pintu ke dapur di restoran besar. Satu pintu ditandai OUT dan
lain ditandai DI. Pintu-pintu telah berhenti yang memungkinkan mereka untuk dibuka hanya yang sesuai
arah.
Jika pelayan mengambil perintah di dapur, meletakkannya di nampan dan kemudian menyadari bahwa
dia
memilih hidangan yang salah, dia bisa berubah untuk hidangan yang benar cepat dan informal sebelum
ia meninggalkan dapur.
Namun, jika dia meninggalkan dapur, memberikan pelanggan piring dan kemudian diberitahu tentang
kesalahan, ia harus mengikuti prosedur yang ditetapkan: (1) melihat periksa untuk menentukan jika
kesalahan telah
terjadi, (2) mohon maaf sebesar-besarnya, (3) kembali ke dapur melalui DI pintu, (4) menjelaskan
masalah, dan sebagainya.
dasar adalah analog dengan pintu dapur di restoran. Sebelum perangkat lunak
item konfigurasi menjadi baseline, perubahan dapat dilakukan dengan cepat dan informal.
Namun, setelah baseline didirikan, kami kiasan melewati satu arah ayun
pintu. Perubahan dapat dibuat, tetapi prosedur, spesifik formal harus diterapkan untuk
mengevaluasi dan memverifikasi setiap perubahan.

tes. Lebih realistis, sebuah SCI adalah dokumen, sebuah suite seluruh kasus uji, atau bernama
Program komponen (misalnya, C + + fungsi atau sebuah paket Ada).
Selain SCIs yang berasal dari produk kerja perangkat lunak, banyak software
organisasi rekayasa juga menempatkan perangkat lunak di bawah kontrol konfigurasi.
Artinya, versi spesifik dari editor, kompiler, dan alat-alat KASUS lainnya adalah "beku"
sebagai bagian dari konfigurasi perangkat lunak. Karena alat ini digunakan untuk menghasilkan
dokumentasi,
kode sumber, dan data, mereka harus tersedia bila perubahan perangkat lunak
konfigurasi yang harus dibuat. Meskipun masalah ini jarang terjadi, ada kemungkinan bahwa
versi baru alat (misalnya, kompilator) bisa menghasilkan hasil yang berbeda dari yang asli
versi. Untuk alasan ini, alat-alat, seperti perangkat lunak yang mereka membantu untuk menghasilkan,
dapat
menjadi baselined sebagai bagian dari proses manajemen konfigurasi yang komprehensif.
Pada kenyataannya, SCIs disusun untuk membentuk obyek konfigurasi yang mungkin di katalog
dalam database proyek dengan nama tunggal. Sebuah objek konfigurasi memiliki nama, atribut,
dan "terhubung" ke obyek lain oleh hubungan. Mengacu pada Gambar 9.2, maka
konfigurasi objek, Desain Spesifikasi, data model, N komponen, sumber
kode dan Uji Spesifikasi masing-masing didefinisikan secara terpisah. Namun, masing-masing
obyek berhubungan dengan yang lain seperti yang ditunjukkan oleh panah. Sebuah panah melengkung
menunjukkan
komposisi hubungan. Artinya, model data dan komponen N merupakan bagian dari objek
Spesifikasi desain. Sebuah panah lurus berkepala dua mengindikasikan suatu hubungan timbal balik.

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