Manajemen Kualitas Software - Panduan Cepat
Perangkat lunak berkualitas mengacu pada perangkat lunak yang bebas bug atau cacat, dikirimkan tepat waktu dan dalam anggaran yang ditentukan, memenuhi persyaratan dan / atau ekspektasi, dan dapat dipelihara. Dalam konteks rekayasa perangkat lunak, kualitas perangkat lunak mencerminkan keduanyafunctional quality sebaik structural quality.
Software Functional Quality - Ini mencerminkan seberapa baik itu memenuhi desain yang diberikan, berdasarkan persyaratan fungsional atau spesifikasi.
Software Structural Quality - Ini berkaitan dengan penanganan persyaratan non-fungsional yang mendukung pengiriman persyaratan fungsional, seperti ketahanan atau pemeliharaan, dan sejauh mana perangkat lunak diproduksi dengan benar.
Software Quality Assurance- Software Quality Assurance (SQA) adalah sekumpulan aktivitas untuk memastikan kualitas dalam proses rekayasa perangkat lunak yang pada akhirnya menghasilkan produk perangkat lunak yang berkualitas. Kegiatan menetapkan dan mengevaluasi proses yang menghasilkan produk. Ini melibatkan tindakan yang berfokus pada proses.
Software Quality Control- Software Quality Control (SQC) adalah sekumpulan aktivitas untuk memastikan kualitas produk software. Kegiatan ini berfokus pada penentuan cacat pada produk aktual yang dihasilkan. Ini melibatkan tindakan yang berfokus pada produk.
Tantangan Kualitas Perangkat Lunak
Dalam industri perangkat lunak, para pengembang tidak akan pernah menyatakan bahwa perangkat lunak bebas dari cacat, tidak seperti yang biasanya dilakukan oleh produsen produk industri lain. Perbedaan ini disebabkan oleh beberapa alasan berikut.
Kompleksitas Produk
Ini adalah jumlah mode operasional yang diizinkan produk. Biasanya, sebuah produk industri hanya memungkinkan kurang dari beberapa ribu mode operasi dengan kombinasi berbeda dari pengaturan mesinnya. Namun, paket perangkat lunak memungkinkan jutaan kemungkinan operasional. Karenanya, memastikan semua kemungkinan operasional ini dengan benar merupakan tantangan utama bagi industri perangkat lunak.
Visibilitas Produk
Karena produk industri terlihat, sebagian besar cacatnya dapat dideteksi selama proses pembuatan. Juga ketiadaan suatu suku cadang dalam suatu produk industri dapat dengan mudah dideteksi dalam produk tersebut. Namun, cacat pada produk perangkat lunak yang disimpan pada disket atau CD tidak terlihat.
Pengembangan Produk dan Proses Produksi
Dalam produk industri, cacat dapat dideteksi selama fase berikut -
Product development - Pada fase ini, perancang dan staf Quality Assurance (QA) memeriksa dan menguji prototipe produk untuk mendeteksi cacatnya.
Product production planning- Selama fase ini, proses produksi dan alat dirancang dan disiapkan. Fase ini juga memberikan kesempatan untuk memeriksa produk untuk mendeteksi cacat yang tidak diketahui selama fase pengembangan.
Manufacturing- Dalam fase ini, prosedur QA diterapkan untuk mendeteksi kegagalan produk itu sendiri. Cacat pada produk yang terdeteksi pada periode pertama produksi biasanya dapat diperbaiki dengan mengubah desain produk atau bahan atau alat produksi, dengan cara yang menghilangkan cacat tersebut pada produk yang diproduksi di masa mendatang.
Namun, dalam kasus perangkat lunak, satu-satunya fase di mana cacat dapat dideteksi adalah fase pengembangan. Dalam hal perangkat lunak, perencanaan produksi produk dan fase pembuatan tidak diperlukan karena pembuatan salinan perangkat lunak dan pencetakan manual perangkat lunak dilakukan secara otomatis.
Faktor-faktor yang mempengaruhi deteksi cacat pada produk perangkat lunak dibandingkan dengan produk industri lainnya ditunjukkan pada tabel berikut.
Ciri | Produk Perangkat Lunak | Produk Industri Lainnya |
---|---|---|
Kompleksitas | Jutaan opsi operasional | ribuan opsi operasional |
visibilitas produk | Produk Tak Terlihat Sulit untuk mendeteksi cacat dengan penglihatan | Produk Terlihat Deteksi cacat secara efektif dengan penglihatan |
Sifat pengembangan dan proses produksi | dapat merusak cacat hanya dalam satu fase | dapat mendeteksi kerusakan di semua fase berikut
|
Karakteristik perangkat lunak seperti kompleksitas dan tembus pandang membuat pengembangan metodologi jaminan kualitas perangkat lunak dan penerapannya yang berhasil menjadi tantangan yang sangat profesional.
Berbagai faktor, yang mempengaruhi perangkat lunak, disebut sebagai faktor perangkat lunak. Mereka dapat secara luas dibagi menjadi dua kategori. Kategori pertama dari faktor-faktor tersebut adalah yang dapat diukur secara langsung seperti jumlah kesalahan logika, dan kategori kedua menggabungkan faktor-faktor yang hanya dapat diukur secara tidak langsung. Misalnya, pemeliharaan tetapi masing-masing faktor harus diukur untuk memeriksa konten dan kontrol kualitas.
Beberapa model faktor kualitas perangkat lunak dan kategorinya telah disarankan selama bertahun-tahun. Model klasik faktor kualitas perangkat lunak, yang disarankan oleh McCall, terdiri dari 11 faktor (McCall et al., 1977). Demikian pula, model yang terdiri dari 12 hingga 15 faktor, disarankan oleh Deutsch dan Willis (1988) dan oleh Evans dan Marciniak (1987).
Semua model ini tidak jauh berbeda dari model McCall. Model faktor McCall menyediakan metode praktis dan terkini untuk mengklasifikasikan kebutuhan perangkat lunak (Pressman, 2000).
Model Faktor McCall
Model ini mengklasifikasikan semua persyaratan perangkat lunak menjadi 11 faktor kualitas perangkat lunak. 11 faktor tersebut dikelompokkan menjadi tiga kategori - operasi produk, revisi produk, dan faktor transisi produk.
Product operation factors - Ketepatan, Keandalan, Efisiensi, Integritas, Kegunaan.
Product revision factors - Pemeliharaan, Fleksibilitas, Kemampuan untuk diuji.
Product transition factors - Portabilitas, Dapat Digunakan Kembali, Interoperabilitas.
Faktor Kualitas Software Operasi Produk
Menurut model McCall, kategori operasi produk mencakup lima faktor kualitas perangkat lunak, yang berhubungan dengan persyaratan yang secara langsung memengaruhi operasi harian perangkat lunak. Mereka adalah sebagai berikut -
Ketepatan
Persyaratan ini berkaitan dengan kebenaran keluaran sistem perangkat lunak. Mereka termasuk -
Misi keluaran
Keakuratan keluaran yang diperlukan yang dapat dipengaruhi secara negatif oleh data yang tidak akurat atau penghitungan yang tidak akurat.
Kelengkapan informasi keluaran, yang dapat dipengaruhi oleh data yang tidak lengkap.
Up-to-dateness informasi didefinisikan sebagai waktu antara kejadian dan respon oleh sistem perangkat lunak.
Ketersediaan informasi.
Standar untuk pengkodean dan pendokumentasian sistem perangkat lunak.
Keandalan
Persyaratan keandalan menangani kegagalan layanan. Mereka menentukan tingkat kegagalan maksimum yang diizinkan dari sistem perangkat lunak, dan dapat merujuk ke seluruh sistem atau ke satu atau lebih fungsi terpisahnya.
Efisiensi
Ini berkaitan dengan sumber daya perangkat keras yang diperlukan untuk melakukan berbagai fungsi sistem perangkat lunak. Ini mencakup kemampuan pemrosesan (diberikan dalam MHz), kapasitas penyimpanannya (diberikan dalam MB atau GB) dan kemampuan komunikasi data (diberikan dalam MBPS atau GBPS).
Ini juga berkaitan dengan waktu antara pengisian ulang unit portabel sistem, seperti, unit sistem informasi yang terletak di komputer portabel, atau unit meteorologi yang ditempatkan di luar ruangan.
Integritas
Faktor ini berkaitan dengan keamanan sistem perangkat lunak, yaitu untuk mencegah akses ke orang yang tidak berhak, juga untuk membedakan antara kelompok orang yang akan diberikan izin baca dan tulis.
Kegunaan
Persyaratan kegunaan berhubungan dengan sumber daya staf yang dibutuhkan untuk melatih karyawan baru dan mengoperasikan sistem perangkat lunak.
Faktor Kualitas Revisi Produk
Menurut model McCall, tiga faktor kualitas perangkat lunak termasuk dalam kategori revisi produk. Faktor-faktor tersebut adalah sebagai berikut -
Pemeliharaan
Faktor ini mempertimbangkan upaya yang akan dibutuhkan oleh pengguna dan personel pemeliharaan untuk mengidentifikasi alasan kegagalan perangkat lunak, untuk memperbaiki kegagalan, dan untuk memverifikasi keberhasilan koreksi.
Fleksibilitas
Faktor ini berkaitan dengan kemampuan dan upaya yang diperlukan untuk mendukung aktivitas pemeliharaan adaptif perangkat lunak. Ini termasuk mengadaptasi perangkat lunak saat ini ke keadaan dan pelanggan tambahan tanpa mengubah perangkat lunak. Persyaratan faktor ini juga mendukung aktivitas pemeliharaan yang sempurna, seperti perubahan dan penambahan perangkat lunak untuk meningkatkan layanannya dan menyesuaikannya dengan perubahan dalam lingkungan teknis atau komersial perusahaan.
Testabilitas
Persyaratan testabilitas berhubungan dengan pengujian sistem perangkat lunak serta pengoperasiannya. Ini mencakup hasil antara yang telah ditentukan, file log, dan juga diagnostik otomatis yang dilakukan oleh sistem perangkat lunak sebelum memulai sistem, untuk mengetahui apakah semua komponen sistem berfungsi dengan baik dan untuk mendapatkan laporan tentang kesalahan yang terdeteksi. Jenis lain dari persyaratan ini berkaitan dengan pemeriksaan diagnostik otomatis yang diterapkan oleh teknisi pemeliharaan untuk mendeteksi penyebab kegagalan perangkat lunak.
Faktor Kualitas Perangkat Lunak Transisi Produk
Menurut model McCall, tiga faktor kualitas perangkat lunak termasuk dalam kategori transisi produk yang berhubungan dengan adaptasi perangkat lunak ke lingkungan lain dan interaksinya dengan sistem perangkat lunak lain. Faktor-faktor tersebut adalah sebagai berikut -
Portabilitas
Persyaratan portabilitas cenderung pada adaptasi suatu sistem perangkat lunak ke lingkungan lain yang terdiri dari perangkat keras yang berbeda, sistem operasi yang berbeda, dan lain sebagainya. Perangkat lunak harus memungkinkan untuk terus menggunakan perangkat lunak dasar yang sama dalam berbagai situasi.
Dapat digunakan kembali
Faktor ini berkaitan dengan penggunaan modul perangkat lunak yang awalnya dirancang untuk satu proyek dalam proyek perangkat lunak baru yang sedang dikembangkan. Mereka juga dapat memungkinkan proyek masa depan untuk menggunakan modul tertentu atau sekelompok modul dari perangkat lunak yang sedang dikembangkan. Penggunaan kembali perangkat lunak diharapkan dapat menghemat sumber daya pengembangan, mempersingkat periode pengembangan, dan menyediakan modul berkualitas lebih tinggi.
Interoperabilitas
Persyaratan interoperabilitas berfokus pada pembuatan antarmuka dengan sistem perangkat lunak lain atau dengan firmware peralatan lain. Misalnya, firmware mesin produksi dan peralatan pengujian berhubungan dengan perangkat lunak kontrol produksi.
Software Quality Assurance(SQA) adalah serangkaian aktivitas untuk memastikan kualitas dalam proses rekayasa perangkat lunak. Ini memastikan bahwa perangkat lunak yang dikembangkan memenuhi dan sesuai dengan spesifikasi kualitas yang ditentukan atau standar. SQA adalah proses berkelanjutan dalam Siklus Hidup Pengembangan Perangkat Lunak (SDLC) yang secara rutin memeriksa perangkat lunak yang dikembangkan untuk memastikannya memenuhi ukuran kualitas yang diinginkan.
Praktik SQA diterapkan di sebagian besar jenis pengembangan perangkat lunak, terlepas dari model pengembangan perangkat lunak yang digunakan. SQA menggabungkan dan menerapkan metodologi pengujian perangkat lunak untuk menguji perangkat lunak. Daripada memeriksa kualitas setelah selesai, SQA memproses pengujian kualitas di setiap tahap pengembangan, hingga perangkat lunak selesai. Dengan SQA, proses pengembangan perangkat lunak berpindah ke fase berikutnya hanya setelah fase saat ini / sebelumnya sesuai dengan standar kualitas yang disyaratkan. SQA umumnya bekerja pada satu atau lebih standar industri yang membantu dalam membangun pedoman kualitas perangkat lunak dan strategi implementasi.
Ini termasuk kegiatan berikut -
- Definisi dan implementasi proses
- Auditing
- Training
Prosesnya bisa -
- Metodologi Pengembangan Perangkat Lunak
- Manajemen proyek
- Manajemen konfigurasi
- Persyaratan Pengembangan / Manajemen
- Estimation
- Desain perangkat lunak
- Pengujian, dll.
Setelah proses ditentukan dan diimplementasikan, Quality Assurance memiliki tanggung jawab berikut -
- Identifikasi kelemahan dalam proses
- Perbaiki kelemahan tersebut untuk terus meningkatkan proses
Komponen Sistem SQA
Sistem SQA selalu menggabungkan berbagai komponen SQA. Komponen-komponen ini dapat diklasifikasikan ke dalam enam kelas berikut -
Komponen pra-proyek
Ini memastikan bahwa komitmen proyek telah ditetapkan dengan jelas dengan mempertimbangkan sumber daya yang diperlukan, jadwal dan anggaran; dan rencana pengembangan dan kualitas telah ditentukan dengan benar.
Komponen penilaian kegiatan siklus hidup proyek
Siklus hidup proyek terdiri dari dua tahap: tahap siklus hidup pengembangan dan tahap operasi-pemeliharaan.
Komponen tahap siklus hidup pengembangan mendeteksi kesalahan desain dan pemrograman. Komponennya dibagi menjadi sub-kelas berikut: Review, Opini ahli, dan Pengujian perangkat lunak.
Komponen SQA yang digunakan selama fase operasi-pemeliharaan mencakup komponen pemeliharaan khusus serta komponen siklus hidup pengembangan, yang diterapkan terutama untuk fungsionalitas guna meningkatkan tugas pemeliharaan.
Komponen pencegahan dan perbaikan kesalahan infrastruktur
Tujuan utama dari komponen ini, yang diterapkan di seluruh organisasi, adalah untuk menghilangkan atau setidaknya mengurangi tingkat kesalahan, berdasarkan pengalaman SQA organisasi yang terakumulasi.
Komponen manajemen kualitas perangkat lunak
Kelas komponen ini menangani beberapa tujuan, seperti pengendalian kegiatan pengembangan dan pemeliharaan, dan pengenalan tindakan dukungan manajerial awal yang terutama mencegah atau meminimalkan kegagalan jadwal dan anggaran serta hasilnya.
Komponen standarisasi, sertifikasi, dan penilaian sistem SQA
Komponen ini menerapkan standar profesional dan manajerial internasional dalam organisasi. Tujuan utama kelas ini adalah pemanfaatan pengetahuan profesional internasional, peningkatan koordinasi sistem mutu organisasi dengan organisasi lain, dan penilaian pencapaian sistem mutu menurut skala yang sama. Berbagai standar dapat diklasifikasikan menjadi dua kelompok utama: standar manajemen mutu dan standar proses proyek.
Pengorganisasian untuk SQA - komponen manusia
Basis organisasi SQA mencakup manajer, personel penguji, unit SQA dan orang-orang yang tertarik dengan kualitas perangkat lunak seperti pengawas SQA, anggota komite SQA, dan anggota forum SQA. Tujuan utamanya adalah untuk memulai dan mendukung implementasi komponen SQA, mendeteksi penyimpangan dari prosedur dan metodologi SQA, dan menyarankan perbaikan.
Komponen Kualitas Perangkat Lunak pra-proyek
Komponen-komponen ini membantu meningkatkan langkah awal yang diambil sebelum memulai proyek. Ini termasuk -
- Review Kontrak
- Rencana Pengembangan dan Kualitas
Review Kontrak
Biasanya, perangkat lunak dikembangkan untuk kontrak yang dinegosiasikan dengan pelanggan atau untuk pesanan internal guna mengembangkan firmware yang akan disematkan di dalam produk perangkat keras. Dalam semua kasus ini, unit pengembangan berkomitmen pada spesifikasi fungsional, anggaran, dan jadwal yang telah disepakati. Oleh karena itu, kegiatan tinjauan kontrak harus mencakup pemeriksaan rinci dari draf proposal proyek dan draf kontrak.
Secara khusus, kegiatan tinjauan kontrak meliputi -
Klarifikasi kebutuhan pelanggan
Review jadwal proyek dan perkiraan kebutuhan sumber daya
Evaluasi kapasitas staf profesional untuk melaksanakan proyek yang diusulkan
Evaluasi kapasitas pelanggan untuk memenuhi kewajibannya
Evaluasi risiko pembangunan
Rencana Pengembangan dan Kualitas
Setelah menandatangani kontrak pengembangan perangkat lunak dengan organisasi atau departemen internal dari organisasi yang sama, rencana pengembangan proyek dan kegiatan penjaminan kualitas terintegrasi disiapkan. Rencana ini mencakup rincian tambahan dan revisi yang diperlukan berdasarkan rencana sebelumnya yang menjadi dasar untuk proposal dan kontrak saat ini.
Seringkali dibutuhkan waktu beberapa bulan antara pengajuan tender hingga penandatanganan kontrak. Selama periode ini, sumber daya seperti ketersediaan staf, kemampuan profesional dapat berubah. Rencana tersebut kemudian direvisi untuk mencerminkan perubahan yang terjadi untuk sementara.
Masalah utama yang ditangani dalam rencana pengembangan proyek adalah -
- Schedules
- Sumber daya tenaga kerja dan perangkat keras yang dibutuhkan
- Evaluasi resiko
- Masalah organisasi: anggota tim, subkontraktor dan kemitraan
- Metodologi proyek, alat pengembangan, dll.
- Paket penggunaan ulang perangkat lunak
Masalah utama yang ditangani dalam rencana kualitas proyek adalah -
Sasaran kualitas, diekspresikan dalam istilah terukur yang sesuai
Kriteria untuk memulai dan mengakhiri setiap tahapan proyek
Daftar review, tes, dan verifikasi terjadwal dan kegiatan validasi
Metrik perangkat lunak dapat diklasifikasikan menjadi tiga kategori -
Product metrics - Menjelaskan karakteristik produk seperti ukuran, kompleksitas, fitur desain, performa, dan tingkat kualitas.
Process metrics - Karakteristik ini dapat digunakan untuk meningkatkan aktivitas pengembangan dan pemeliharaan perangkat lunak.
Project metrics- Metrik ini menggambarkan karakteristik dan pelaksanaan proyek. Contohnya termasuk jumlah pengembang perangkat lunak, pola kepegawaian selama siklus hidup perangkat lunak, biaya, jadwal, dan produktivitas.
Beberapa metrik termasuk dalam beberapa kategori. Misalnya, metrik kualitas dalam proses suatu proyek adalah metrik proses dan metrik proyek.
Software quality metricsadalah bagian dari metrik perangkat lunak yang berfokus pada aspek kualitas produk, proses, dan proyek. Ini lebih terkait erat dengan metrik proses dan produk daripada dengan metrik proyek.
Metrik kualitas perangkat lunak dapat dibagi lagi menjadi tiga kategori -
- Metrik kualitas produk
- Metrik kualitas dalam proses
- Metrik kualitas pemeliharaan
Metrik Kualitas Produk
Metrik ini meliputi:
- Waktu Berarti untuk Gagal
- Kerapatan Cacat
- Masalah Pelanggan
- Kepuasan pelanggan
Waktu Berarti untuk Gagal
Ini adalah waktu antara kegagalan. Metrik ini sebagian besar digunakan dengan sistem keamanan kritis seperti sistem kontrol lalu lintas maskapai penerbangan, avionik, dan senjata.
Kerapatan Cacat
Ini mengukur cacat relatif terhadap ukuran perangkat lunak yang dinyatakan sebagai baris kode atau titik fungsi, dll. Yaitu, mengukur kualitas kode per unit. Metrik ini digunakan di banyak sistem perangkat lunak komersial.
Masalah Pelanggan
Ini mengukur masalah yang dihadapi pelanggan saat menggunakan produk. Ini berisi perspektif pelanggan terhadap ruang masalah perangkat lunak, yang mencakup masalah berorientasi non-cacat bersama dengan masalah cacat.
Metrik masalah biasanya dinyatakan dalam Problems per User-Month (PUM).
PUM = Total Problems that customers reported (true defect and non-defect oriented
problems) for a time period + Total number of license months of the software during
the period
Dimana,
Number of license-month of the software = Number of install license of the software ×
Number of months in the calculation period
PUM biasanya dihitung untuk setiap bulan setelah perangkat lunak dirilis ke pasar, dan juga untuk rata-rata bulanan menurut tahun.
Kepuasan pelanggan
Kepuasan pelanggan sering diukur dengan data survei pelanggan melalui skala lima poin -
- Sangat Puas
- Satisfied
- Neutral
- Dissatisfied
- Sangat tidak puas
Kepuasan terhadap kualitas produk secara keseluruhan dan dimensi spesifiknya biasanya diperoleh melalui berbagai metode survei pelanggan. Berdasarkan data skala lima poin, beberapa metrik dengan sedikit variasi dapat dibuat dan digunakan, tergantung pada tujuan analisis. Misalnya -
- Persentase pelanggan yang benar-benar puas
- Persentase pelanggan yang puas
- Persentase pelanggan yang tidak puas
- Persentase pelanggan yang tidak puas
Biasanya, persentase kepuasan ini digunakan.
Metrik Kualitas Dalam Proses
Metrik kualitas dalam proses berhubungan dengan pelacakan kedatangan kerusakan selama pengujian mesin formal untuk beberapa organisasi. Metrik ini mencakup -
- Kerapatan cacat selama pengujian mesin
- Pola kedatangan yang rusak selama pengujian mesin
- Pola penghapusan cacat berbasis fase
- Efektivitas penghapusan cacat
Kerapatan cacat selama pengujian mesin
Tingkat kerusakan selama pengujian mesin formal (pengujian setelah kode diintegrasikan ke dalam perpustakaan sistem) berkorelasi dengan tingkat kerusakan di lapangan. Tingkat kerusakan yang lebih tinggi yang ditemukan selama pengujian merupakan indikator bahwa perangkat lunak telah mengalami injeksi kesalahan yang lebih tinggi selama proses pengembangannya, kecuali tingkat kerusakan pengujian yang lebih tinggi disebabkan oleh upaya pengujian yang luar biasa.
Metrik sederhana dari kerusakan per KLOC atau titik fungsi ini adalah indikator kualitas yang baik, sementara perangkat lunak masih diuji. Sangat berguna untuk memantau rilis produk berikutnya dalam organisasi pengembangan yang sama.
Pola kedatangan yang rusak selama pengujian mesin
Kerapatan cacat keseluruhan selama pengujian hanya akan memberikan ringkasan dari cacat tersebut. Pola kedatangan barang cacat memberikan informasi lebih lanjut tentang berbagai tingkat kualitas di lapangan. Ini termasuk yang berikut -
Kedatangan cacat atau cacat dilaporkan selama fase pengujian dengan interval waktu (misalnya, minggu). Di sini semua yang cacat tidak akan valid.
Pola kedatangan cacat yang valid pada saat dilakukan penentuan masalah terhadap masalah yang dilaporkan. Ini adalah pola cacat yang sebenarnya.
Pola backlog cacat lembur. Metrik ini diperlukan karena organisasi pengembangan tidak dapat menyelidiki dan memperbaiki semua masalah yang dilaporkan dengan segera. Ini adalah pernyataan beban kerja serta pernyataan kualitas. Jika defect backlog besar pada akhir siklus pengembangan dan banyak perbaikan yang belum diintegrasikan ke dalam sistem, stabilitas sistem (karena itu kualitasnya) akan terpengaruh. Pengujian ulang (uji regresi) diperlukan untuk memastikan bahwa tingkat kualitas produk yang ditargetkan tercapai.
Pola penghapusan cacat berbasis fase
Ini adalah perpanjangan dari metrik kepadatan cacat selama pengujian. Selain pengujian, ia melacak cacat di semua fase siklus pengembangan, termasuk tinjauan desain, inspeksi kode, dan verifikasi formal sebelum pengujian.
Karena sebagian besar cacat pemrograman terkait dengan masalah desain, melakukan tinjauan formal, atau verifikasi fungsional untuk meningkatkan kemampuan penghapusan cacat proses di ujung depan mengurangi kesalahan dalam perangkat lunak. Pola penghapusan cacat berbasis fase mencerminkan kemampuan menghilangkan cacat secara keseluruhan dari proses pengembangan.
Berkenaan dengan metrik untuk fase desain dan pengkodean, selain tingkat kerusakan, banyak organisasi pengembangan menggunakan metrik seperti cakupan inspeksi dan upaya inspeksi untuk manajemen kualitas dalam proses.
Efektivitas penghapusan cacat
Itu dapat didefinisikan sebagai berikut -
$$DRE = \frac{Defect \: removed \: during \: a \: development\:phase }{Defects\: latent \: in \: the\: product} \times 100\%$$
Metrik ini dapat dihitung untuk seluruh proses pengembangan, untuk front-end sebelum integrasi kode dan untuk setiap fase. Itu disebutearly defect removal saat digunakan untuk front-end dan phase effectivenessuntuk fase tertentu. Semakin tinggi nilai metrik, semakin efektif proses pengembangan dan semakin sedikit cacat yang diteruskan ke fase atau lapangan berikutnya. Metrik ini adalah konsep kunci dari model penghapusan cacat untuk pengembangan perangkat lunak.
Metrik Kualitas Perawatan
Meskipun banyak yang tidak dapat dilakukan untuk mengubah kualitas produk selama fase ini, berikut adalah perbaikan yang dapat dilakukan untuk menghilangkan cacat sesegera mungkin dengan kualitas perbaikan yang sangat baik.
- Perbaiki backlog dan indeks manajemen backlog
- Perbaiki waktu respons dan perbaiki respons
- Persen perbaikan tunggakan
- Perbaiki kualitas
Perbaiki backlog dan indeks manajemen backlog
Fix backlog terkait dengan tingkat kedatangan cacat dan tingkat ketersediaan perbaikan untuk masalah yang dilaporkan. Ini adalah hitungan sederhana dari masalah yang dilaporkan yang tetap ada di akhir setiap bulan atau setiap minggu. Dengan menggunakannya dalam format diagram tren, metrik ini dapat memberikan informasi yang berarti untuk mengelola proses pemeliharaan.
Backlog Management Index (BMI) digunakan untuk mengelola backlog masalah yang terbuka dan belum terselesaikan.
$$BMI = \frac{Number \: of \: problems \: closed \: during \:the \:month }{Number \: of \: problems \: arrived \: during \:the \:month} \times 100\%$$
Jika BMI lebih besar dari 100, berarti backlog berkurang. Jika BMI kurang dari 100, maka backlog meningkat.
Perbaiki waktu respons dan perbaiki respons
Metrik waktu respons perbaikan biasanya dihitung sebagai waktu rata-rata semua masalah dari buka hingga tutup. Waktu respons perbaikan yang singkat mengarah pada kepuasan pelanggan.
Elemen penting dari fix responsiveness adalah ekspektasi pelanggan, waktu yang disepakati untuk memperbaiki, dan kemampuan untuk memenuhi komitmen seseorang kepada pelanggan.
Persen perbaikan tunggakan
Ini dihitung sebagai berikut -
$Percent \:Delinquent\: Fixes =$
$\frac{Number \: of \: fixes \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \: fixes \: delivered \: in \:a \:specified \:time} \times 100\%$
Perbaiki Kualitas
Perbaiki kualitas atau jumlah perbaikan yang rusak adalah metrik kualitas penting lainnya untuk fase pemeliharaan. Perbaikan rusak jika tidak memperbaiki masalah yang dilaporkan, atau jika memperbaiki masalah asli tetapi menyuntikkan cacat baru. Untuk perangkat lunak yang sangat penting, perbaikan yang rusak merugikan kepuasan pelanggan. Metrik persen perbaikan rusak adalah persentase dari semua perbaikan dalam interval waktu yang rusak.
Perbaikan yang rusak dapat direkam dengan dua cara: Catat pada bulan ditemukannya atau catat pada bulan perbaikan tersebut dikirim. Yang pertama adalah ukuran pelanggan; yang kedua adalah ukuran proses. Perbedaan antara kedua tanggal tersebut adalah periode laten dari perbaikan yang rusak.
Biasanya semakin lama latensi, semakin banyak pelanggan yang terpengaruh. Jika jumlah cacatnya besar, maka nilai persentase metrik yang kecil akan menunjukkan gambaran yang optimis. Sasaran kualitas untuk proses pemeliharaan, tentu saja, adalah nol perbaikan cacat tanpa tunggakan.
Pengukuran adalah tindakan mengukur sesuatu. Ini adalah penetapan angka untuk karakteristik suatu objek atau peristiwa, yang dapat dibandingkan dengan objek atau peristiwa lain.
Secara formal dapat didefinisikan sebagai, proses di mana angka atau simbol ditetapkan ke atribut entitas di dunia nyata, sedemikian rupa untuk menggambarkannya sesuai dengan aturan yang ditentukan dengan jelas.
Pengukuran dalam Kehidupan Sehari-hari
Pengukuran tidak hanya digunakan oleh ahli teknologi profesional, tetapi juga digunakan oleh kita semua dalam kehidupan sehari-hari. Di toko, harga bertindak sebagai ukuran nilai suatu barang. Demikian pula, pengukuran tinggi dan ukuran akan memastikan apakah kain akan pas atau tidak. Dengan demikian, pengukuran akan membantu kita membandingkan suatu item dengan yang lain.
Pengukuran tersebut mengambil informasi tentang atribut entitas. Entitas adalah objek seperti orang atau peristiwa seperti perjalanan di dunia nyata. Atribut adalah fitur atau properti dari suatu entitas seperti tinggi seseorang, biaya perjalanan, dll. Dalam dunia nyata, meskipun kita berpikir untuk mengukur sesuatu, sebenarnya kita mengukur atribut dari benda-benda itu.
Atribut sebagian besar ditentukan oleh angka atau simbol. Misalnya harga bisa ditentukan dalam jumlah rupee atau dollar, ukuran pakaian bisa ditentukan dari segi kecil, sedang, besar.
Keakuratan suatu pengukuran bergantung pada alat ukur serta definisi pengukurannya. Setelah mendapatkan pengukuran, kita harus menganalisisnya dan kita harus mengambil kesimpulan tentang entitas.
Pengukuran adalah penghitungan langsung sedangkan penghitungan adalah penghitungan tidak langsung di mana kami menggabungkan pengukuran yang berbeda menggunakan beberapa rumus.
Pengukuran dalam Rekayasa Perangkat Lunak
Rekayasa Perangkat Lunak melibatkan pengelolaan, penetapan biaya, perencanaan, pemodelan, analisis, spesifikasi, perancangan, penerapan, pengujian, dan pemeliharaan produk perangkat lunak. Oleh karena itu, pengukuran memainkan peran penting dalam rekayasa perangkat lunak. Pendekatan yang ketat diperlukan untuk mengukur atribut produk perangkat lunak.
Untuk sebagian besar proyek pengembangan,
- Kami gagal menetapkan target yang dapat diukur untuk produk perangkat lunak kami
- Kami gagal memahami dan menghitung biaya komponen proyek perangkat lunak
- Kami tidak mengukur atau memprediksi kualitas produk yang kami hasilkan
Jadi, untuk mengontrol produk perangkat lunak, perlu dilakukan pengukuran atribut. Setiap tindakan pengukuran harus dimotivasi oleh tujuan atau kebutuhan tertentu yang didefinisikan dengan jelas dan mudah dimengerti. Tujuan pengukuran harus spesifik, mencoba untuk mengetahui apa yang perlu diketahui oleh manajer, pengembang, dan pengguna. Pengukuran diperlukan untuk menilai status proyek, produk, proses, dan sumber daya.
Dalam rekayasa perangkat lunak, pengukuran sangat penting untuk tiga aktivitas dasar berikut -
- Untuk memahami apa yang terjadi selama pengembangan dan pemeliharaan
- Untuk mengontrol apa yang terjadi di proyek
- Untuk meningkatkan proses dan tujuan
Teori Pengukuran Representasi
Pengukuran memberi tahu kita aturan yang meletakkan dasar untuk mengembangkan dan bernalar tentang semua jenis pengukuran. Ini adalah pemetaan dari dunia empiris ke dunia relasional formal. Akibatnya, ukuran adalah angka atau simbol yang ditetapkan ke suatu entitas dengan pemetaan ini untuk mengkarakterisasi suatu entitas.
Hubungan Empiris
Di dunia nyata, kita memahami berbagai hal dengan membandingkannya, bukan dengan memberikan angka padanya.
Misalnya, untuk membandingkan tinggi, kami menggunakan istilah 'lebih tinggi dari', lebih tinggi dari '. Jadi, 'lebih tinggi dari', lebih tinggi dari 'ini adalah hubungan empiris untuk ketinggian.
Kita dapat mendefinisikan lebih dari satu relasi empiris pada himpunan yang sama.
Misalnya, X lebih tinggi dari Y. X, Y jauh lebih tinggi dari Z.
Hubungan empiris dapat berupa unary, binary, ternary, dll.
X tinggi, Y tidak tinggi adalah hubungan unary.
X lebih tinggi dari Y adalah relasi biner.
Hubungan empiris dalam dunia nyata dapat dipetakan ke dalam dunia matematika formal. Sebagian besar hubungan ini mencerminkan preferensi pribadi.
Beberapa teknik pemetaan atau penilaian yang digunakan untuk memetakan hubungan empiris ini ke dunia matematika adalah sebagai berikut:
Skala Likert
Di sini, pengguna akan diberikan pernyataan yang harus mereka setujui atau tidak setujui.
For example - Perangkat lunak ini bekerja dengan baik.
Sangat setuju | Setuju | Tidak setuju atau tidak setuju | Tidak setuju | Sangat Disgaree |
---|---|---|---|---|
Peringkat Paksa
Pesan alternatif yang diberikan dari 1 (terbaik) hingga n (terburuk).
Misalnya: Beri peringkat 5 modul perangkat lunak berikut menurut kinerjanya.
Nama Modul | Pangkat |
---|---|
Modul A | |
Modul B | |
Modul C | |
Modul D | |
Modul E |
Skala Frekuensi Verbal
For example - Seberapa sering program ini gagal?
Selalu | Sering | Terkadang | Jarang | Tidak pernah |
---|---|---|---|---|
Skala Ordinal
Di sini, pengguna akan diberikan daftar alternatif dan mereka harus memilih salah satu.
For example - Seberapa sering program ini gagal?
- Hourly
- Daily
- Weekly
- Monthly
- Beberapa kali setahun
- Sekali atau dua kali dalam setahun
- Never
Skala Perbandingan
Di sini, pengguna harus memberikan nomor dengan membandingkan opsi yang berbeda.
Very superiorAbout the sameVery inferior
12345678910
Skala Numerik
Di sini, pengguna harus memberi nomor sesuai kepentingannya.
UnimportantImportant
12345678910
Aturan Pemetaan
Untuk melakukan pemetaan, kita harus menentukan domain, range serta aturan untuk melakukan pemetaan.
For example - Domain - Dunia nyata
Range - Dunia matematika seperti bilangan bulat, bilangan real, dll.
Rules - Untuk mengukur ketinggian, sepatu harus dipakai atau tidak
Demikian pula, dalam hal pengukuran perangkat lunak, daftar periksa pernyataan yang akan dimasukkan ke dalam baris kode yang akan ditentukan.
Kondisi Pengukuran Representasi
Kondisi keterwakilan menegaskan bahwa pemetaan pengukuran (M) harus memetakan entitas menjadi angka, dan hubungan empiris menjadi hubungan numerik sedemikian rupa sehingga hubungan empiris dipertahankan dan dipertahankan oleh hubungan numerik.
Contoh: Relasi empiris 'lebih tinggi dari' dipetakan ke relasi numerik '>'. Yaitu, X is taller than Y, if and only if M(X) > M(Y)
Karena, dapat terdapat banyak relasi pada himpunan tertentu, kondisi representasi juga memiliki implikasi untuk masing-masing relasi tersebut.
Untuk relasi unary 'is tall', kita mungkin memiliki relasi numerik
X > 50
Kondisi representasi mensyaratkan itu untuk ukuran apapun M,
X is tall if and only if M(X) > 50
Tahapan Kunci Pengukuran Formal
Tahapan utama pengukuran dapat diringkas sebagai berikut -
Model berguna untuk menafsirkan perilaku elemen numerik dari entitas dunia nyata serta mengukurnya. Untuk membantu proses pengukuran, model pemetaan juga harus dilengkapi dengan model domain pemetaan. Sebuah model juga harus menentukan bagaimana entitas ini terkait dengan atribut dan bagaimana karakteristik berhubungan.
Pengukuran terdiri dari dua jenis -
- Pengukuran langsung
- Pengukuran tidak langsung
Pengukuran Langsung
Ini adalah pengukuran yang dapat diukur tanpa keterlibatan entitas atau atribut lain.
Tindakan langsung berikut biasanya digunakan dalam rekayasa perangkat lunak.
- Panjang kode sumber oleh LOC
- Durasi tujuan pengujian dengan waktu yang telah berlalu
- Jumlah cacat yang ditemukan selama proses pengujian dengan menghitung cacat
- Waktu yang dihabiskan programmer untuk suatu program
Pengukuran Tidak Langsung
Ini adalah pengukuran yang dapat diukur dalam bentuk entitas atau atribut lainnya.
Tindakan tidak langsung berikut ini biasanya digunakan dalam rekayasa perangkat lunak.
$$\small Programmer\:Productivity = \frac{LOC \: produced }{Person \:months \:of \:effort}$$
$\small Module\:Defect\:Density = \frac{Number \:of\:defects}{Module \:size}$
$$\small Defect\:Detection\:Efficiency = \frac{Number \:of\:defects\:detected}{Total \:number \:of\:defects}$$
$\small Requirement\:Stability = \frac{Number \:of\:initial\:requirements}{Total \:number \:of\:requirements}$
$\small Test\:Effectiveness\:Ratio = \frac{Number \:of\:items\:covered}{Total \:number \:of \:items}$
$\small System\:spoilage = \frac{Effort \:spent\:for\:fixing\:faults}{Total \:project \:effort}$
Pengukuran untuk Prediksi
Untuk mengalokasikan sumber daya yang sesuai untuk proyek, kita perlu memprediksi tenaga, waktu, dan biaya untuk mengembangkan proyek. Pengukuran prediksi selalu membutuhkan model matematis yang menghubungkan atribut-atribut yang akan diprediksi dengan beberapa atribut lain yang dapat kita ukur sekarang. Oleh karena itu, sistem prediksi terdiri dari model matematika bersama dengan serangkaian prosedur prediksi untuk menentukan parameter yang tidak diketahui dan menafsirkan hasil.
Skala pengukuran adalah pemetaan yang digunakan untuk merepresentasikan sistem hubungan empiris. Ini terutama dari 5 jenis -
- Skala nominal
- Skala Ordinal
- Skala interval
- Skala Rasio
- Skala Mutlak
Skala nominal
Ini menempatkan elemen dalam skema klasifikasi. Kelas tidak akan dipesan. Setiap entitas harus ditempatkan dalam kelas atau kategori tertentu berdasarkan nilai atribut.
Ini memiliki dua karakteristik utama -
Sistem hubungan empiris hanya terdiri dari kelas-kelas yang berbeda; tidak ada gagasan tentang keteraturan di antara kelas-kelas.
Setiap penomoran atau representasi simbolis kelas yang berbeda adalah ukuran yang dapat diterima, tetapi tidak ada gagasan tentang besaran yang terkait dengan angka atau simbol.
Skala Ordinal
Ini menempatkan elemen dalam skema klasifikasi yang teratur. Ini memiliki karakteristik sebagai berikut -
Sistem hubungan empiris terdiri dari kelas-kelas yang diurutkan sesuai dengan atributnya.
Pemetaan apa pun yang mempertahankan pengurutan dapat diterima.
Angka-angka tersebut hanya mewakili peringkat. Karenanya, penjumlahan, pengurangan, dan operasi aritmatika lainnya tidak ada artinya.
Skala interval
Skala ini menangkap informasi tentang ukuran interval yang memisahkan klasifikasi. Karenanya, ini lebih kuat daripada skala nominal dan skala ordinal.
Ini memiliki karakteristik sebagai berikut -
Ini menjaga ketertiban seperti skala ordinal.
Ini mempertahankan perbedaan tetapi bukan rasionya.
Penjumlahan dan pengurangan dapat dilakukan pada skala ini tetapi tidak perkalian atau pembagian.
Jika atribut dapat diukur pada skala interval, dan M dan M’ adalah pemetaan yang memenuhi kondisi representasi, maka kita selalu dapat menemukan dua angka a dan b seperti yang,
M = aM '+ b
Skala Rasio
Ini adalah skala pengukuran yang paling berguna. Di sini, ada hubungan empiris untuk menangkap rasio. Ini memiliki karakteristik sebagai berikut -
Ini adalah pemetaan pengukuran yang menjaga keteraturan, ukuran interval antara entitas dan rasio antara entitas.
Ada elemen nol, yang mewakili kekurangan total atribut.
Pemetaan pengukuran harus dimulai dari nol dan meningkat pada interval yang sama, yang disebut satuan.
Semua operasi aritmatika dapat diterapkan.
Di sini, pemetaan akan berbentuk
M = aM’
Dimana ‘a’ adalah skalar positif.
Skala Mutlak
Pada skala ini, hanya akan ada satu kemungkinan ukuran untuk suatu atribut. Oleh karena itu, satu-satunya transformasi yang mungkin adalah transformasi identitas.
Ini memiliki karakteristik sebagai berikut -
Pengukuran dilakukan dengan menghitung jumlah elemen dalam himpunan entitas.
Atribut selalu berbentuk “jumlah kemunculan x dalam entitas”.
Hanya ada satu pemetaan pengukuran yang mungkin, yaitu hitungan aktual.
Semua operasi aritmatika dapat dilakukan pada hitungan yang dihasilkan.
Penyelidikan Empiris melibatkan penyelidikan ilmiah atas alat, teknik, atau metode apa pun. Investigasi ini terutama berisi 4 prinsip berikut.
- Memilih teknik investigasi
- Menyatakan hipotesis
- Mempertahankan kontrol atas variabel
- Membuat investigasi menjadi bermakna
Memilih Teknik Investigasi
Komponen utama investigasi empiris dalam rekayasa perangkat lunak adalah -
- Survey
- Studi kasus
- Eksperimen formal
Survei
Survei adalah studi retrospektif dari suatu situasi untuk mendokumentasikan hubungan dan hasil. Itu selalu dilakukan setelah suatu peristiwa terjadi. Misalnya, dalam rekayasa perangkat lunak, jajak pendapat dapat dilakukan untuk menentukan bagaimana pengguna bereaksi terhadap metode, alat, atau teknik tertentu untuk menentukan tren atau hubungan.
Dalam kasus ini, kami tidak memiliki kendali atas situasi yang dihadapi. Kami dapat merekam situasi dan membandingkannya dengan situasi serupa.
Studi kasus
Ini adalah teknik penelitian di mana Anda mengidentifikasi faktor-faktor kunci yang dapat mempengaruhi hasil suatu kegiatan dan kemudian mendokumentasikan kegiatan tersebut: masukan, kendala, sumber daya, dan keluarannya.
Eksperimen Formal
Ini adalah penyelidikan terkontrol yang ketat dari suatu aktivitas, di mana faktor-faktor kunci diidentifikasi dan dimanipulasi untuk mendokumentasikan pengaruhnya terhadap hasil.
Metode investigasi tertentu dapat dipilih sesuai dengan pedoman berikut -
Jika kegiatan sudah terlanjur dilakukan, kita bisa melakukan survey atau studi kasus. Jika belum terjadi, maka studi kasus atau eksperimen formal dapat dipilih.
Jika kami memiliki kontrol tingkat tinggi atas variabel yang dapat memengaruhi hasil, kami dapat menggunakan eksperimen. Jika kita tidak memiliki kendali atas variabel tersebut, maka studi kasus akan menjadi teknik yang lebih disukai.
Jika replikasi tidak memungkinkan pada tingkat yang lebih tinggi, maka percobaan tidak mungkin dilakukan.
Jika biaya replikasi rendah, maka kita dapat mempertimbangkan percobaan.
Menyatakan Hipotesis
Untuk meningkatkan keputusan teknik investigasi tertentu, tujuan penelitian harus dinyatakan sebagai hipotesis yang ingin kami uji. Hipotesis adalah teori tentatif atau anggapan yang menurut programmer menjelaskan perilaku yang ingin mereka eksplorasi.
Mempertahankan Kontrol atas Variabel
Setelah menyatakan hipotesis, selanjutnya kita harus memutuskan variabel berbeda yang mempengaruhi kebenarannya serta seberapa besar kendali yang kita miliki terhadapnya. Ini penting karena pembeda utama antara eksperimen dan studi kasus adalah tingkat kendali atas variabel yang memengaruhi perilaku.
Variabel keadaan yang merupakan faktor yang dapat mencirikan proyek dan juga dapat mempengaruhi hasil evaluasi digunakan untuk membedakan situasi kontrol dari situasi eksperimental dalam eksperimen formal. Jika kita tidak dapat membedakan kontrol dari eksperimen, teknik studi kasus akan menjadi pilihan.
Misalnya, jika kita ingin menentukan apakah perubahan bahasa pemrograman dapat mempengaruhi produktivitas proyek, maka bahasa tersebut akan menjadi variabel keadaan. Misalkan kita saat ini menggunakan FORTRAN yang ingin kita ganti dengan Ada. Kemudian FORTRAN akan menjadi bahasa kontrol dan Ada sebagai bahasa eksperimental.
Membuat Investigasi Berarti
Hasil percobaan biasanya lebih dapat digeneralisasikan daripada studi kasus atau survei. Hasil studi kasus atau survei biasanya hanya dapat diterapkan pada organisasi tertentu. Poin-poin berikut membuktikan efisiensi teknik-teknik ini untuk menjawab berbagai pertanyaan.
Teori yang sesuai dan kebijaksanaan konvensional
Studi kasus atau survei dapat digunakan untuk menyesuaikan keefektifan dan kegunaan kebijaksanaan konvensional dan banyak standar, metode, atau alat lainnya dalam satu organisasi. Namun, percobaan formal dapat menyelidiki situasi di mana klaim tersebut secara umum benar.
Menjelajahi hubungan
Hubungan antara berbagai atribut sumber daya dan produk perangkat lunak dapat disarankan melalui studi kasus atau survei.
Misalnya, survei proyek yang diselesaikan dapat mengungkapkan bahwa perangkat lunak yang ditulis dalam bahasa tertentu memiliki lebih sedikit kesalahan daripada perangkat lunak yang ditulis dalam bahasa lain.
Memahami dan memverifikasi hubungan ini sangat penting untuk keberhasilan proyek di masa depan. Masing-masing hubungan ini dapat dinyatakan sebagai hipotesis dan eksperimen formal dapat dirancang untuk menguji sejauh mana hubungan tersebut bertahan. Biasanya, nilai dari satu atribut tertentu diamati dengan menjaga atribut lain tetap konstan atau terkendali.
Mengevaluasi akurasi model
Model biasanya digunakan untuk memprediksi hasil dari suatu aktivitas atau untuk memandu penggunaan metode atau alat. Ini menghadirkan masalah yang sangat sulit saat merancang eksperimen atau studi kasus, karena prediksi mereka sering memengaruhi hasil. Manajer proyek sering mengubah prediksi menjadi target penyelesaian. Efek ini umum terjadi ketika model biaya dan jadwal digunakan.
Beberapa model seperti model reliabilitas tidak mempengaruhi hasil, karena reliabilitas diukur sebagai waktu rata-rata untuk kegagalan tidak dapat dievaluasi sampai perangkat lunak siap digunakan di lapangan.
Memvalidasi tindakan
Ada banyak ukuran perangkat lunak untuk menangkap nilai suatu atribut. Oleh karena itu, studi harus dilakukan untuk menguji apakah ukuran tertentu mencerminkan perubahan atribut yang seharusnya ditangkap. Validasi dilakukan dengan menghubungkan satu ukuran dengan ukuran lainnya. Ukuran kedua yang juga merupakan ukuran langsung dan valid dari faktor yang mempengaruhi harus digunakan untuk memvalidasi. Ukuran seperti itu tidak selalu tersedia atau mudah diukur. Selain itu, ukuran yang digunakan harus sesuai dengan konsep manusia tentang faktor yang diukur.
Kerangka pengukuran perangkat lunak didasarkan pada tiga prinsip -
- Mengklasifikasikan entitas yang akan diperiksa
- Menentukan tujuan pengukuran yang relevan
- Mengidentifikasi tingkat kematangan yang telah dicapai organisasi
Mengklasifikasikan Entitas yang Akan Diperiksa
Dalam rekayasa perangkat lunak, terdapat tiga kelas entitas. Mereka adalah -
- Processes
- Products
- Resources
Semua entitas ini memiliki entitas internal maupun eksternal.
Internal attributesadalah yang dapat diukur secara murni dalam kaitannya dengan proses, produk, atau sumber daya itu sendiri. Misalnya: Ukuran, kompleksitas, ketergantungan antar modul.
External attributesadalah hal-hal yang hanya dapat diukur sehubungan dengan hubungannya dengan lingkungan. Misalnya: Jumlah total kegagalan yang dialami oleh pengguna, lamanya waktu yang dibutuhkan untuk mencari database dan mengambil informasi.
Atribut berbeda yang dapat diukur untuk setiap entitas adalah sebagai berikut -
Proses
Proses adalah kumpulan aktivitas yang berhubungan dengan perangkat lunak. Berikut adalah beberapa atribut internal yang dapat diukur secara langsung untuk suatu proses -
Durasi proses atau salah satu aktivitasnya
Upaya yang terkait dengan proses atau salah satu aktivitasnya
Jumlah insiden dari jenis tertentu yang timbul selama proses atau salah satu aktivitasnya
Atribut eksternal yang berbeda dari suatu proses adalah biaya, kemampuan pengendalian, efektivitas, kualitas dan stabilitas.
Produk
Produk tidak hanya item yang menjadi komitmen manajemen untuk dikirimkan, tetapi juga artefak atau dokumen apa pun yang dihasilkan selama siklus hidup perangkat lunak.
Atribut produk internal yang berbeda adalah ukuran, upaya, biaya, spesifikasi, panjang, fungsionalitas, modularitas, penggunaan kembali, redundansi, dan kebenaran sintaksis. Di antara ukuran, tenaga, dan biaya ini relatif mudah diukur dibandingkan yang lain.
Atribut produk eksternal yang berbeda adalah kegunaan, integritas, efisiensi, kemampuan untuk diuji, usabilitas, portabilitas, dan interoperabilitas. Atribut ini tidak hanya menjelaskan kode tetapi juga dokumen lain yang mendukung upaya pengembangan.
Sumber daya
Ini adalah entitas yang dibutuhkan oleh aktivitas proses. Ini bisa menjadi masukan apa pun untuk produksi perangkat lunak. Ini termasuk personel, bahan, alat dan metode.
Atribut internal yang berbeda untuk sumber daya adalah usia, harga, ukuran, kecepatan, ukuran memori, suhu, dll. Atribut eksternal yang berbeda adalah produktivitas, pengalaman, kualitas, kegunaan, keandalan, kenyamanan, dll.
Menentukan Tujuan Pengukuran yang Relevan
Pengukuran tertentu akan berguna hanya jika itu membantu untuk memahami proses atau salah satu produk yang dihasilkannya. Perbaikan dalam proses atau produk hanya dapat dilakukan jika proyek telah menetapkan tujuan untuk proses dan produk dengan jelas. Pemahaman yang jelas tentang tujuan dapat digunakan untuk menghasilkan metrik yang disarankan untuk proyek tertentu dalam konteks kerangka kematangan proses.
Paradigma Sasaran-Pertanyaan-Metrik (GQM)
Pendekatan GQM menyediakan kerangka kerja yang melibatkan tiga langkah berikut -
Membuat daftar tujuan utama dari proyek pengembangan atau pemeliharaan
Memperoleh pertanyaan dari setiap tujuan yang harus dijawab untuk menentukan apakah tujuan tersebut terpenuhi
Putuskan apa yang harus diukur agar dapat menjawab pertanyaan dengan memadai
Untuk menggunakan paradigma GQM, pertama-tama kami mengungkapkan tujuan organisasi secara keseluruhan. Kemudian, kami menghasilkan pertanyaan sedemikian rupa sehingga jawabannya diketahui sehingga kami dapat menentukan apakah tujuan itu tercapai. Nanti, analisis setiap pertanyaan dalam hal pengukuran apa yang kita butuhkan untuk menjawab setiap pertanyaan.
Tujuan tipikal diekspresikan dalam hal produktivitas, kualitas, risiko, kepuasan pelanggan, dll. Tujuan dan pertanyaan harus dibangun dalam kaitannya dengan audiens mereka.
Untuk membantu menghasilkan tujuan, pertanyaan, dan metrik, Basili & Rombach menyediakan serangkaian templat.
Purpose - Untuk (mengkarakterisasi, mengevaluasi, memprediksi, memotivasi, dll.) (Proses, produk, model, metrik, dll.) Untuk memahami, menilai, mengelola, merekayasa, mempelajari, meningkatkan, dll. Example: Untuk mengkarakterisasi produk untuk mempelajarinya.
Perspective - Memeriksa (biaya, efektivitas, ketepatan, cacat, perubahan, ukuran produk, dll.) Dari sudut pandang pengembang, manajer, pelanggan, dll. Example: Memeriksa cacat dari sudut pandang pelanggan.
Environment - Lingkungan terdiri dari: faktor proses, faktor orang, faktor masalah, metode, alat, kendala, dll. Example: Pelanggan perangkat lunak ini adalah mereka yang tidak memiliki pengetahuan tentang alat.
Pengukuran dan Peningkatan Proses
Biasanya pengukuran berguna untuk -
- Memahami proses dan produk
- Menetapkan garis dasar
- Mengakses dan memprediksi hasilnya
Menurut tingkat kematangan proses yang diberikan oleh SEI, jenis pengukuran dan program pengukuran akan berbeda. Berikut adalah program pengukuran berbeda yang dapat diterapkan di setiap tingkat kematangan.
Level 1: Ad hoc
Pada level ini, input tidak jelas, sedangkan output diharapkan. Transisi dari input ke output tidak ditentukan dan tidak terkontrol. Untuk tingkat kematangan proses ini, pengukuran dasar diperlukan untuk memberikan titik awal pengukuran.
Level 2: Repeatable
Pada tingkat ini, masukan dan keluaran dari proses, kendala, dan sumber daya dapat diidentifikasi. Proses yang berulang dapat dijelaskan dengan diagram berikut.
Ukuran input dapat berupa ukuran dan volatilitas persyaratan. Keluaran dapat diukur dalam hal ukuran sistem, sumber daya dalam hal upaya staf, dan kendala dalam hal biaya dan jadwal.
Level 3: Defined
Pada tingkat ini, kegiatan perantara didefinisikan, dan masukan serta keluarannya diketahui dan dipahami. Contoh sederhana dari proses yang ditentukan dijelaskan pada gambar berikut.
Masukan dan keluaran dari kegiatan antara dapat diperiksa, diukur, dan dinilai.
Level 4: Managed
Pada tingkat ini, umpan balik dari kegiatan proyek awal dapat digunakan untuk menetapkan prioritas untuk kegiatan saat ini dan nanti untuk kegiatan proyek. Kami dapat mengukur efektivitas proses kegiatan. Pengukuran tersebut mencerminkan karakteristik dari keseluruhan proses dan interaksi di antara dan di seluruh aktivitas utama.
Level 5: Optimizing
Pada level ini, ukuran dari aktivitas digunakan untuk memperbaiki proses dengan menghilangkan dan menambahkan aktivitas proses dan mengubah struktur proses secara dinamis sebagai respons terhadap umpan balik pengukuran. Dengan demikian, perubahan proses dapat mempengaruhi organisasi dan proyek serta prosesnya. Proses tersebut akan bertindak sebagai sensor dan monitor, dan kami dapat mengubah proses tersebut secara signifikan sebagai respons terhadap tanda peringatan.
Pada tingkat kematangan tertentu, kami dapat mengumpulkan pengukuran untuk tingkat tersebut dan semua tingkat di bawahnya.
Mengidentifikasi Tingkat Kedewasaan
Kematangan proses menyarankan untuk mengukur hanya apa yang terlihat. Dengan demikian, kombinasi kematangan proses dengan GQM akan memberikan ukuran yang paling berguna.
Di level 1, proyek tersebut kemungkinan memiliki persyaratan yang tidak jelas. Pada level ini, pengukuran karakteristik kebutuhan sulit dilakukan.
Di level 2, persyaratan ditentukan dengan baik dan informasi tambahan seperti jenis setiap persyaratan dan jumlah perubahan untuk setiap jenis dapat dikumpulkan.
Di level 3, aktivitas menengah ditentukan dengan kriteria masuk dan keluar untuk setiap aktivitas
Analisis tujuan dan pertanyaan akan sama, tetapi metriknya akan bervariasi sesuai kematangan. Semakin matang prosesnya, semakin kaya ukurannya. Paradigma GQM, sejalan dengan kematangan proses, telah digunakan sebagai dasar untuk beberapa alat yang membantu manajer dalam merancang program pengukuran.
GQM membantu memahami kebutuhan untuk mengukur atribut, dan kematangan proses menunjukkan apakah kita mampu mengukurnya dengan cara yang berarti. Bersama-sama mereka memberikan konteks untuk pengukuran.
Memvalidasi pengukuran sistem perangkat lunak melibatkan dua langkah -
- Memvalidasi sistem pengukuran
- Memvalidasi sistem prediksi
Memvalidasi Sistem Pengukuran
Pengukuran atau sistem pengukuran digunakan untuk menilai entitas yang ada dengan mencirikan satu atau lebih atributnya secara numerik. Suatu ukuran valid jika secara akurat mencirikan atribut yang diklaim diukurnya.
Memvalidasi sistem pengukuran perangkat lunak adalah proses untuk memastikan bahwa ukuran tersebut merupakan karakterisasi numerik yang tepat dari atribut yang diklaim dengan menunjukkan bahwa kondisi representasi terpenuhi.
Untuk memvalidasi sistem pengukuran, kita membutuhkan model formal yang menggambarkan entitas dan pemetaan numerik yang mempertahankan atribut yang kita ukur. Misalnya, jika ada dua program P1 dan P2, dan kami ingin menggabungkan program tersebut, maka kami mengharapkanm panjang untuk memuaskan itu,
m (P1 + P2) = m (P1) + m (P2)
Jika sebuah program P1 memiliki panjang lebih dari program P2, lalu ukuran apa pun m juga harus memuaskan,
m (P1)> m (P2)
Panjang program dapat diukur dengan menghitung baris kode. Jika hitungan ini memenuhi hubungan di atas, kita dapat mengatakan bahwa baris kode adalah ukuran panjang yang valid.
Persyaratan formal untuk memvalidasi suatu ukuran melibatkan mendemonstrasikan bahwa ia mencirikan atribut yang dinyatakan dalam pengertian teori pengukuran. Validasi dapat digunakan untuk memastikan bahwa pengukur didefinisikan dengan benar dan konsisten dengan perilaku dunia nyata entitas.
Memvalidasi Sistem Prediksi
Sistem prediksi digunakan untuk memprediksi beberapa atribut dari entitas masa depan yang melibatkan model matematika dengan prosedur prediksi terkait.
Memvalidasi sistem prediksi dalam lingkungan tertentu adalah proses membangun keakuratan sistem prediksi dengan cara empiris, yaitu dengan membandingkan kinerja model dengan data yang diketahui di lingkungan tertentu. Ini melibatkan eksperimen dan pengujian hipotesis.
Tingkat akurasi yang dapat diterima untuk validasi tergantung pada apakah sistem prediksi bersifat deterministik atau stokastik serta orang yang melakukan penilaian. Beberapa sistem prediksi stokastik lebih stokastik daripada yang lain.
Contoh sistem prediksi stokastik adalah sistem seperti estimasi biaya software, estimasi upaya, estimasi jadwal, dll. Oleh karena itu, untuk memvalidasi sistem prediksi secara formal, kita harus memutuskan seberapa stokastiknya, kemudian membandingkan kinerja sistem prediksi dengan data yang diketahui.
Metrik perangkat lunak adalah standar ukuran yang berisi banyak aktivitas yang melibatkan beberapa derajat pengukuran. Ini dapat diklasifikasikan menjadi tiga kategori: metrik produk, metrik proses, dan metrik proyek.
Product metrics mendeskripsikan karakteristik produk seperti ukuran, kompleksitas, fitur desain, performa, dan tingkat kualitas.
Process metricsdapat digunakan untuk meningkatkan pengembangan dan pemeliharaan perangkat lunak. Contohnya termasuk efektivitas penghapusan cacat selama pengembangan, pola kedatangan cacat pengujian, dan waktu respons dari proses perbaikan.
Project metricsmenjelaskan karakteristik dan pelaksanaan proyek. Contohnya termasuk jumlah pengembang perangkat lunak, pola kepegawaian selama siklus hidup perangkat lunak, biaya, jadwal, dan produktivitas.
Beberapa metrik termasuk dalam beberapa kategori. Misalnya, metrik kualitas dalam proses suatu proyek adalah metrik proses dan metrik proyek.
Cakupan Metrik Software
Metrik perangkat lunak berisi banyak aktivitas yang meliputi:
- Estimasi biaya dan usaha
- Ukuran dan model produktivitas
- Pengumpulan data
- Model dan ukuran kuantitas
- Model reliabilitas
- Model kinerja dan evaluasi
- Metrik struktural dan kompleksitas
- Kapabilitas - penilaian kematangan
- Manajemen berdasarkan metrik
- Evaluasi metode dan alat
Pengukuran perangkat lunak adalah kumpulan beragam aktivitas ini yang berkisar dari model yang memprediksi biaya proyek perangkat lunak pada tahap tertentu hingga ukuran struktur program.
Estimasi Biaya dan Upaya
Upaya dinyatakan sebagai fungsi dari satu atau lebih variabel seperti ukuran program, kapabilitas pengembang dan tingkat penggunaan kembali. Model estimasi biaya dan usaha telah diusulkan untuk memprediksi biaya proyek selama fase awal dalam siklus hidup perangkat lunak. Model berbeda yang diusulkan adalah -
- Model COCOMO Boehm
- Model ramping Putnam
- Model titik fungsi Albrecht
Model dan Ukuran Produktivitas
Produktivitas dapat dianggap sebagai fungsi dari nilai dan biaya. Masing-masing dapat diuraikan menjadi ukuran, fungsionalitas, waktu, uang, dll yang dapat diukur yang berbeda, berbagai kemungkinan komponen model produktivitas dapat diekspresikan dalam diagram berikut.
Pengumpulan data
Kualitas program pengukuran jelas bergantung pada pengumpulan data yang cermat. Data yang terkumpul dapat disaring menjadi bagan dan grafik sederhana sehingga pengelola dapat memahami kemajuan dan masalah pembangunan. Pengumpulan data juga penting untuk penyelidikan ilmiah tentang hubungan dan tren.
Model dan Ukuran Kualitas
Model kualitas telah dikembangkan untuk mengukur kualitas produk yang tanpanya produktivitas tidak berarti. Model kualitas ini dapat digabungkan dengan model produktivitas untuk mengukur produktivitas yang benar. Model ini biasanya dibuat dengan gaya seperti pohon. Cabang atas memiliki faktor kualitas tingkat tinggi yang penting seperti keandalan dan kegunaan.
Pengertian pendekatan divide and conquer telah diimplementasikan sebagai pendekatan standar untuk mengukur kualitas perangkat lunak.
Model Keandalan
Sebagian besar model kualitas memasukkan keandalan sebagai faktor komponen, namun, kebutuhan untuk memprediksi dan mengukur keandalan telah menyebabkan spesialisasi terpisah dalam pemodelan dan prediksi keandalan. Masalah dasar dalam teori reliabilitas adalah memprediksi kapan suatu sistem pada akhirnya akan gagal.
Evaluasi dan Model Kinerja
Ini mencakup karakteristik kinerja sistem yang dapat diamati secara eksternal seperti waktu respons dan tingkat penyelesaian, dan kerja internal sistem seperti efisiensi algoritme. Ini adalah aspek kualitas lainnya.
Metrik Struktural dan Kompleksitas
Di sini kami mengukur atribut struktural representasi perangkat lunak, yang tersedia sebelum eksekusi. Kemudian kami mencoba untuk membangun teori prediktif secara empiris untuk mendukung jaminan kualitas, pengendalian kualitas, dan prediksi kualitas.
Penilaian Kematangan Kemampuan
Model ini dapat menilai berbagai atribut pengembangan termasuk penggunaan alat, praktik standar, dan lainnya. Ini didasarkan pada praktik-praktik utama yang harus digunakan oleh setiap kontraktor yang baik.
Manajemen menurut Metrik
Untuk mengelola proyek perangkat lunak, pengukuran memiliki peran penting. Untuk memeriksa apakah proyek berjalan sesuai rencana, pengguna dan pengembang dapat mengandalkan bagan dan grafik berbasis pengukuran. Rangkaian pengukuran dan metode pelaporan standar sangat penting ketika perangkat lunak tertanam dalam produk di mana pelanggan biasanya tidak berpengalaman dalam terminologi perangkat lunak.
Evaluasi Metode dan Alat
Hal ini tergantung pada desain eksperimental, identifikasi faktor yang mungkin mempengaruhi hasil dan pengukuran atribut faktor yang tepat.
Metrik perangkat lunak adalah standar ukuran yang berisi banyak aktivitas, yang melibatkan beberapa derajat pengukuran. Keberhasilan pengukuran perangkat lunak terletak pada kualitas data yang dikumpulkan dan dianalisis.
Apa itu Good Data?
Data yang dikumpulkan dapat dikatakan sebagai data yang baik, jika dapat menghasilkan jawaban atas pertanyaan-pertanyaan berikut -
Are they correct? - Sebuah data dapat dianggap benar, jika dikumpulkan sesuai dengan aturan yang tepat dari definisi metrik.
Are they accurate? - Akurasi mengacu pada perbedaan antara data dan nilai sebenarnya.
Are they appropriately precise? - Presisi berkaitan dengan jumlah tempat desimal yang diperlukan untuk mengekspresikan data.
Are they consistent? - Data dapat dianggap konsisten, jika tidak menunjukkan perbedaan besar antara satu alat pengukur dengan yang lainnya.
Are they associated with a particular activity or time period? - Jika data dikaitkan dengan aktivitas atau periode waktu tertentu, maka data harus ditentukan dengan jelas.
Can they be replicated?- Biasanya, penyelidikan seperti survei, studi kasus, dan eksperimen sering diulang dalam keadaan yang berbeda. Oleh karena itu, data juga harus dapat direplikasi dengan mudah.
Bagaimana Mendefinisikan Data?
Data yang dikumpulkan untuk tujuan pengukuran terdiri dari dua jenis -
Raw data- Hasil data mentah dari pengukuran awal proses, produk, atau sumber daya. Misalnya: Timesheet mingguan karyawan di sebuah organisasi.
Refined data - Hasil data yang disempurnakan dari mengekstraksi elemen data penting dari data mentah untuk mendapatkan nilai atribut.
Data dapat ditentukan berdasarkan poin-poin berikut -
- Location
- Timing
- Symptoms
- Hasil akhir
- Mechanism
- Cause
- Severity
- Cost
Bagaimana Mengumpulkan Data?
Pengumpulan data membutuhkan observasi dan pelaporan manusia. Manajer, analis sistem, pemrogram, penguji, dan pengguna harus mencatat data baris pada formulir. Untuk mengumpulkan data yang akurat dan lengkap, penting untuk -
Buat prosedur tetap sederhana
Hindari perekaman yang tidak perlu
Latih karyawan yang perlu mencatat data dan prosedur yang akan digunakan
Berikan hasil pengambilan dan analisis data kepada penyedia asli dengan segera dan dalam bentuk yang berguna yang akan membantu pekerjaan mereka
Validasi semua data yang dikumpulkan di titik pengumpulan pusat
Perencanaan pengumpulan data melibatkan beberapa langkah -
Putuskan produk mana yang akan diukur berdasarkan analisis GQM
Pastikan produk berada di bawah kendali konfigurasi
Tentukan dengan tepat atribut mana yang akan diukur dan bagaimana pengukuran tidak langsung akan diturunkan
Setelah kumpulan metrik jelas dan kumpulan komponen yang akan diukur telah diidentifikasi, buat skema untuk mengidentifikasi setiap aktivitas yang terlibat dalam proses pengukuran.
Tetapkan prosedur untuk menangani formulir, menganalisis data, dan melaporkan hasilnya
Perencanaan pengumpulan data harus dimulai saat perencanaan proyek dimulai. Pengumpulan data aktual terjadi selama banyak fase pengembangan.
For example - Beberapa data yang terkait dengan personel proyek dapat dikumpulkan pada awal proyek, sedangkan pengumpulan data lainnya seperti upaya dimulai saat proyek dimulai dan berlanjut hingga operasi dan pemeliharaan.
Cara Menyimpan dan Mengekstrak Data
Dalam rekayasa perangkat lunak, data harus disimpan dalam database dan diatur menggunakan Database Management System (DBMS). Contoh struktur database ditunjukkan pada gambar berikut. Basis data ini akan menyimpan detail berbagai karyawan yang bekerja di berbagai departemen dalam suatu organisasi.
Dalam diagram di atas, setiap kotak adalah tabel dalam database, dan panah menunjukkan pemetaan banyak-ke-satu dari satu tabel ke tabel lainnya. Pemetaan menentukan batasan yang menjaga konsistensi logis dari data.
Setelah database dirancang dan diisi dengan data, kita dapat menggunakan bahasa manipulasi data untuk mengekstrak data untuk dianalisis.
Setelah mengumpulkan data yang relevan, kami harus menganalisisnya dengan cara yang tepat. Ada tiga item utama yang perlu dipertimbangkan untuk memilih teknik analisis.
- Sifat data
- Tujuan percobaan
- Pertimbangan desain
Sifat Data
Untuk menganalisis data, kita juga harus melihat populasi yang lebih besar yang diwakili oleh data serta sebaran datanya.
Pengambilan sampel, populasi, dan distribusi data
Sampling adalah proses memilih sekumpulan data dari populasi yang besar. Statistik sampel mendeskripsikan dan meringkas ukuran yang diperoleh dari sekelompok subjek eksperimen.
Parameter populasi mewakili nilai-nilai yang akan diperoleh jika semua kemungkinan subjek diukur.
Populasi atau sampel dapat dijelaskan dengan ukuran tendensi sentral seperti mean, median, dan mode dan ukuran dispersi seperti varians dan deviasi standar. Banyak kumpulan data yang didistribusikan secara normal seperti yang ditunjukkan pada grafik berikut.
Seperti yang ditunjukkan di atas, data tentang mean akan didistribusikan secara merata. yang merupakan karakteristik penting dari distribusi normal.
Distribusi lain juga ada di mana datanya miring sehingga ada lebih banyak titik data di satu sisi mean daripada yang lain. Sebagai contoh: Jika sebagian besar data ada di sisi kiri mean, maka kita dapat mengatakan bahwa distribusinya miring ke kiri.
Tujuan Eksperimen
Biasanya, eksperimen dilakukan -
- Untuk mengkonfirmasi teori
- Untuk mengeksplorasi suatu hubungan
Untuk mencapai masing-masing, tujuan harus dinyatakan secara formal dalam bentuk hipotesis, dan analisis harus membahas hipotesis secara langsung.
Untuk mengkonfirmasi teori
Investigasi harus dirancang untuk mengeksplorasi kebenaran sebuah teori. Teori biasanya menyatakan bahwa penggunaan metode, alat, atau teknik tertentu memiliki efek tertentu pada subjek, membuatnya lebih baik dalam beberapa hal daripada yang lain.
Ada dua kasus data yang harus dipertimbangkan: normal data dan non-normal data.
Jika data berdistribusi normal dan terdapat dua kelompok yang dibandingkan maka uji t siswa dapat digunakan untuk analisis. Jika ada lebih dari dua kelompok untuk dibandingkan, analisis umum dari uji varians yang disebut F-statistik dapat digunakan.
Jika datanya tidak normal, maka data tersebut dapat dianalisis menggunakan uji Kruskal-Wallis dengan cara memeringkatnya.
Untuk mengeksplorasi suatu hubungan
Investigasi dirancang untuk menentukan hubungan antara titik data yang menggambarkan satu variabel atau beberapa variabel.
Ada tiga teknik untuk menjawab pertanyaan tentang suatu hubungan: plot kotak, plot sebar, dan analisis korelasi.
SEBUAH box plot dapat mewakili ringkasan rentang sekumpulan data.
SEBUAH scatter plot mewakili hubungan antara dua variabel.
Correlation analysis menggunakan metode statistik untuk memastikan apakah ada hubungan yang benar antara dua atribut.
Untuk nilai terdistribusi normal, gunakan Pearson Correlation Coefficient untuk memeriksa apakah kedua variabel sangat berkorelasi atau tidak.
Untuk data non-normal, rangking data dan gunakan Spearman Rank Correlation Coefficientsebagai ukuran asosiasi. Ukuran lain untuk data non-normal adalahKendall robust correlation coefficient, yang menyelidiki hubungan antara pasangan titik data dan dapat mengidentifikasi korelasi parsial.
Jika peringkat berisi sejumlah besar nilai terikat, a chi-squared testpada tabel kontingensi dapat digunakan untuk menguji hubungan antar variabel. Demikian pula,linear regression dapat digunakan untuk menghasilkan persamaan untuk menggambarkan hubungan antar variabel.
Untuk lebih dari dua variabel, multivariate regression dapat digunakan.
Pertimbangan Desain
Desain investigasi harus dipertimbangkan saat memilih teknik analisis. Pada saat yang sama, kompleksitas analisis dapat mempengaruhi desain yang dipilih. Beberapa kelompok menggunakan F-statistik daripada uji-T Student dengan dua kelompok.
Untuk desain faktorial yang kompleks dengan lebih dari dua faktor, diperlukan uji asosiasi dan signifikansi yang lebih canggih.
Teknik statistik dapat digunakan untuk menjelaskan pengaruh satu set variabel pada yang lain, atau untuk mengkompensasi waktu atau efek pembelajaran.
Atribut produk internal menggambarkan produk perangkat lunak dengan cara yang hanya bergantung pada produk itu sendiri. Alasan utama untuk mengukur atribut produk internal adalah, ini akan membantu memantau dan mengontrol produk selama pengembangan.
Mengukur Atribut Produk Internal
Atribut produk internal utama meliputi size dan structure. Ukuran dapat diukur secara statis tanpa harus menjalankannya. Ukuran produk memberi tahu kita tentang upaya yang diperlukan untuk membuatnya. Demikian pula struktur produk memegang peranan penting dalam merancang perawatan produk.
Mengukur Ukuran
Ukuran perangkat lunak dapat dijelaskan dengan tiga atribut -
Length - Ini adalah ukuran fisik produk.
Functionality - Ini menjelaskan fungsi yang disediakan oleh produk kepada pengguna.
Complexity - Kompleksitas memiliki tipe yang berbeda, seperti.
Problem complexity - Mengukur kompleksitas masalah yang mendasarinya.
Algorithmic complexity - Mengukur kompleksitas algoritma yang diterapkan untuk menyelesaikan masalah
Structural complexity - Mengukur struktur perangkat lunak yang digunakan untuk mengimplementasikan algoritma.
Cognitive complexity - Mengukur upaya yang diperlukan untuk memahami perangkat lunak.
Pengukuran ketiga atribut tersebut dapat dijelaskan sebagai berikut -
Panjangnya
Ada tiga produk pengembangan yang pengukuran ukurannya berguna untuk memprediksi upaya yang diperlukan untuk prediksi. Mereka adalah spesifikasi, desain, dan kode.
Spesifikasi dan desain
Dokumen-dokumen ini biasanya menggabungkan teks, grafik, dan diagram serta simbol matematika khusus. Pengukuran spesifikasi dapat digunakan untuk memprediksi panjang desain, yang pada gilirannya merupakan prediktor panjang kode.
Diagram dalam dokumen memiliki sintaks yang seragam seperti digraf berlabel, diagram aliran data, atau skema Z. Karena spesifikasi dan dokumen desain terdiri dari teks dan diagram, panjangnya dapat diukur dalam sepasang angka yang mewakili panjang teks dan panjang diagram.
Untuk pengukuran ini, objek atom harus didefinisikan untuk berbagai jenis diagram dan simbol.
Objek atom untuk diagram aliran data adalah proses, entitas eksternal, penyimpanan data, dan aliran data. Entitas atom untuk spesifikasi aljabar adalah macam, fungsi, operasi, dan aksioma. Entitas atom untuk skema Z adalah berbagai baris yang muncul dalam spesifikasi.
Kode
Kode dapat diproduksi dengan berbagai cara seperti bahasa prosedural, orientasi objek, dan pemrograman visual. Ukuran tradisional yang paling umum digunakan untuk panjang program kode sumber adalah Lines of code (LOC).
Panjang total,
LOC = NCLOC + CLOC
yaitu,
LOC = Non-commented LOC + Commented LOC
Selain baris kode, alternatif lain seperti ukuran dan kompleksitas yang disarankan oleh Maurice Halsted juga dapat digunakan untuk mengukur panjang.
Ilmu perangkat lunak Halstead berusaha menangkap atribut yang berbeda dari suatu program. Dia mengusulkan tiga atribut program internal seperti panjang, kosakata, dan volume yang mencerminkan pandangan ukuran yang berbeda.
Dia mulai dengan mendefinisikan sebuah program Psebagai kumpulan token, diklasifikasikan oleh operator atau operan. Metrik dasar untuk token ini adalah,
μ1 = Jumlah operator unik
μ2 = Jumlah operan unik
N1 = Jumlah kejadian operator
N2 = Jumlah operator unik
Panjangnya P dapat didefinisikan sebagai
$$N = N_{1}+ N_{2}$$
Kosakata P adalah
$$\mu =\mu _{1}+\mu _{2}$$
Volume program = Jumlah perbandingan mental yang diperlukan untuk menulis panjang program N, adalah
$$V = N\times {log_{2}} \mu$$
Tingkat program suatu program P volume V adalah,
$$L = \frac{V^\ast}{V}$$
Dimana, $V^\ast$ adalah volume potensial, yaitu volume implementasi ukuran minimal P
Kebalikan dari level adalah kesulitan -
$$D = 1\diagup L$$
Menurut teori Halstead, kita dapat menghitung perkiraan L sebagai
$${L}' = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$
Demikian pula, perkiraan durasi program adalah, $\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$
Upaya yang dibutuhkan untuk menghasilkan P diberikan oleh,
$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$
Dimana satuan ukurnya E adalah diskriminasi mental dasar yang perlu dipahami P
Alternatif lain untuk mengukur panjang adalah -
Dalam hal jumlah byte penyimpanan komputer yang dibutuhkan untuk teks program
Dalam hal jumlah karakter dalam teks program
Pengembangan berorientasi objek menyarankan cara baru untuk mengukur panjang. Pfleeger dkk. menemukan bahwa jumlah objek dan metode menghasilkan perkiraan produktivitas yang lebih akurat daripada yang menggunakan baris kode.
Kegunaan
Jumlah fungsionalitas yang melekat pada suatu produk memberikan ukuran ukuran produk. Ada begitu banyak metode berbeda untuk mengukur fungsionalitas produk perangkat lunak. Kita akan membahas salah satu metode tersebut ─ metode Titik Fungsi Albrecht ─ dalam bab berikutnya.
Metrik titik fungsi menyediakan metode standar untuk mengukur berbagai fungsi aplikasi perangkat lunak. Ini mengukur fungsionalitas dari sudut pandang pengguna, yaitu, berdasarkan apa yang diminta dan diterima pengguna sebagai imbalan. Analisis titik fungsi adalah metode standar untuk mengukur pengembangan perangkat lunak dari sudut pandang pengguna.
Ukuran Titik Fungsi yang awalnya dibuat oleh Albrecht mendapatkan popularitas yang meningkat dengan dimulainya Kelompok Pengguna Titik Fungsi Internasional (IFPUG) pada tahun 1986. Pada tahun 2002, Titik Fungsi IFPUG menjadi standar ISO internasional - ISO / IEC 20926.
Apa itu Titik Fungsi?
FP (Function Point)adalah jenis metrik fungsional paling luas yang cocok untuk mengukur aplikasi perangkat lunak. Ini didasarkan pada lima "fungsi" logis yang dapat diidentifikasi pengguna, yang dibagi menjadi dua jenis fungsi data dan tiga jenis fungsi transaksional. Untuk aplikasi perangkat lunak tertentu, masing-masing elemen ini dihitung dan diberi bobot, menghitung elemen karakteristiknya, seperti referensi file atau bidang logika.
Angka yang dihasilkan (FP yang tidak disesuaikan) dikelompokkan ke dalam kumpulan fungsi yang Ditambahkan, Diubah, atau Dihapus, dan digabungkan dengan Faktor Penyesuaian Nilai (VAF) untuk mendapatkan jumlah akhir dari FP. Formula akhir yang berbeda digunakan untuk setiap jenis penghitungan: Aplikasi, Proyek Pengembangan, atau Proyek Peningkatan.
Menerapkan Metode Titik Fungsi Albrecht
Mari kita sekarang memahami bagaimana menerapkan metode Titik Fungsi Albrecht. Prosedurnya adalah sebagai berikut -
Tentukan banyaknya komponen (EI, EO, EQ, ILF, dan ELF)
EI- Jumlah input eksternal. Ini adalah proses dasar di mana data turunan melewati batas dari luar ke dalam. Dalam contoh sistem database perpustakaan, masukkan nomor kartu perpustakaan pelindung yang ada.
EO- Jumlah keluaran eksternal. Ini adalah proses dasar di mana data turunan melewati batas dari dalam ke luar. Dalam contoh sistem database perpustakaan, tampilkan daftar buku yang diperiksa kepada seorang pelindung.
EQ- Jumlah kueri eksternal. Ini adalah proses dasar dengan komponen input dan output yang menghasilkan pengambilan data dari satu atau lebih file logika internal dan file antarmuka eksternal. Dalam contoh sistem basis data perpustakaan, tentukan buku apa yang saat ini diperiksa oleh seorang pelindung.
ILF- Jumlah file log internal. Ini adalah grup yang dapat diidentifikasi pengguna dari data terkait secara logis yang berada sepenuhnya dalam batas aplikasi yang dipertahankan melalui input eksternal. Dalam contoh sistem database perpustakaan, file buku di perpustakaan.
ELF- Jumlah file log eksternal. Ini adalah grup yang dapat diidentifikasi pengguna dari data terkait secara logis yang digunakan untuk tujuan referensi saja, dan yang seluruhnya berada di luar sistem. Dalam contoh sistem database perpustakaan, file yang berisi transaksi dalam sistem penagihan perpustakaan.
Hitung Jumlah Titik Fungsi yang Tidak Disesuaikan (UFC)
Beri nilai setiap komponen sebagai low, average, atau high.
Untuk transaksi (EI, EO, and EQ), peringkat didasarkan pada FTR dan DET.
FTR - Jumlah file yang diperbarui atau direferensikan.
DET - Jumlah bidang yang dapat dikenali pengguna.
Berdasarkan tabel berikut, sebuah EI bahwa referensi 2 file dan 10 elemen data akan diberi peringkat sebagai average.
FTR | DET | |||
---|---|---|---|---|
1-5 | 6-15 | >15 | ||
0-1 | Rendah | Rendah | Rata-rata | |
2-3 | Rendah | Rata-rata | Tinggi | |
>3 | Rata-rata | Tinggi | Tinggi |
Untuk file (ILF and ELF), peringkat didasarkan pada RET dan DET.
RET - Jumlah elemen data yang dapat dikenali pengguna dalam file ILF atau ELF.
DET - Jumlah bidang yang dapat dikenali pengguna.
Berdasarkan tabel berikut, sebuah ILF yang berisi 10 elemen data dan 5 bidang akan diberi peringkat sebagai high.
RET | DET | |||
---|---|---|---|---|
1-5 | 6-15 | >15 | ||
1 | Rendah | Rendah | Rata-rata | |
2-5 | Rendah | Rata-rata | Tinggi | |
>5 | Rata-rata | Tinggi | Tinggi |
Ubah peringkat menjadi UFCs.
Peringkat | Nilai | ||||
---|---|---|---|---|---|
EO | EQ | EI | ILF | ELF | |
Low | 4 | 3 | 3 | 7 | 5 |
Average | 5 | 4 | 4 | 10 | 7 |
High | 6 | 5 | 6 | 15 | 10 |
Hitung Jumlah Titik Fungsi Akhir (FPC)
Hitung faktor penyesuaian nilai (VAF) berdasarkan 14 karakteristik sistem umum (GSC).
Karakteristik Sistem Umum | Deskripsi singkat | |
---|---|---|
GSC 1 | Komunikasi data | Berapa banyak fasilitas komunikasi yang ada untuk membantu transfer atau pertukaran informasi dengan aplikasi atau sistem? |
GSC 2 | Pemrosesan data terdistribusi | Bagaimana data terdistribusi dan fungsi pemrosesan ditangani? |
GSC 3 | Performa | Apakah waktu respons atau throughput diperlukan oleh pengguna? |
GSC 4 | Konfigurasi yang sangat banyak digunakan | Seberapa sering digunakan platform perangkat keras saat ini di mana aplikasi akan dijalankan? |
GSC 5 | Tingkat transaksi | Seberapa sering transaksi dilakukan harian, mingguan, bulanan, dll.? |
GSC 6 | Entri data On-Line | Berapa persentase informasi yang dimasukkan secara online? |
GSC 7 | Efisiensi pengguna akhir | Apakah aplikasi dirancang untuk efisiensi pengguna akhir? |
GSC 8 | Pembaruan On-Line | Berapa ILF yang diperbarui melalui transaksi online? |
GSC 9 | Pemrosesan yang kompleks | Apakah aplikasi memiliki pemrosesan logika atau matematika yang ekstensif? |
GSC 10 | Dapat digunakan kembali | Apakah aplikasi dikembangkan untuk memenuhi satu atau banyak kebutuhan pengguna? |
GSC 11 | Kemudahan instalasi | Seberapa sulit konversi dan pemasangan? |
GSC 12 | Kemudahan operasional | Seberapa efektif dan / atau otomatis prosedur start-up, back-up, dan pemulihan? |
GSC 13 | Beberapa situs | Apakah aplikasi secara khusus dirancang, dikembangkan, dan didukung untuk dipasang di banyak situs untuk banyak organisasi? |
GSC 14 | Memfasilitasi perubahan | Apakah aplikasi dirancang, dikembangkan, dan didukung secara khusus untuk memfasilitasi perubahan? |
Timbang masing-masing GSC pada skala 0 sampai 5 berdasarkan apakah tidak berpengaruh kuat atau tidak.
Hitung FPC sebagai berikut -
FPC = UFC * (0,65+ (jumlah (GSC) * .01))
Kompleksitas
Kompleksitas adalah komponen ukuran yang terpisah. Ini dari dua jenis -
Complexity of a problem - Ini adalah jumlah sumber daya yang dibutuhkan untuk solusi optimal untuk masalah tersebut.
Complexity of a solution- Ini adalah sumber daya yang dibutuhkan untuk mengimplementasikan solusi tertentu. Ini memiliki dua aspek. Mereka adalah sebagai berikut -
Time complexity - Sumbernya adalah waktu komputer.
Space complexity - Sumber daya adalah memori komputer.
Mengukur Kompleksitas
Salah satu aspek kompleksitas adalah efisiensi. Ini mengukur produk perangkat lunak apa pun yang dapat dimodelkan sebagai algoritme.
Misalnya: Jika algoritma untuk menyelesaikan semua contoh dari masalah tertentu membutuhkan f(n) komputasi, lalu f(n) optimal secara asimtotik, jika untuk setiap algoritme lain dengan kompleksitas g yang memecahkan masalah f adalah O(g). Kemudian, kompleksitas masalah yang diberikan sangat besar -O dari algoritme yang optimal secara asimtotik untuk solusi masalah.
Pengukuran sifat struktural suatu perangkat lunak penting untuk memperkirakan upaya pengembangan serta untuk pemeliharaan produk. Struktur persyaratan, desain, dan kode membantu memahami kesulitan yang muncul dalam mengonversi satu produk ke produk lainnya, dalam menguji produk, atau dalam memprediksi atribut perangkat lunak eksternal dari pengukuran produk internal awal.
Jenis Tindakan Struktural
Struktur perangkat lunak memiliki tiga bagian. Mereka adalah -
Control-flow structure - Ini adalah urutan di mana instruksi dieksekusi dalam suatu program.
Data-flow structure - Ini adalah perilaku data saat berinteraksi dengan program.
Data structure - Ini adalah organisasi elemen data dalam bentuk daftar, antrian, tumpukan, atau struktur lain yang terdefinisi dengan baik bersama dengan algoritme untuk membuat, memodifikasi, atau menghapusnya.
Mengukur Struktur Aliran Kontrol
Pengukuran aliran kendali biasanya dimodelkan dengan grafik terarah, di mana setiap simpul atau titik sesuai dengan pernyataan program, dan setiap busur atau ujung terarah menunjukkan aliran kendali dari satu pernyataan ke pernyataan lainnya. Grafik ini disebut grafik aliran kontrol atau grafik terarah.
Jika ‘m’ adalah ukuran struktural yang didefinisikan dalam model grafik aliran, dan jika program A secara struktural lebih kompleks daripada program B, lalu ukurannya m(A) harus lebih besar dari m(B).
Mengukur Struktur Aliran Data
Aliran data atau aliran informasi dapat bersifat inter-modular (aliran informasi di dalam modul) atau intra-modular (aliran informasi antara modul individu dan bagian sistem lainnya).
Menurut cara di mana data bergerak melalui sistem, dapat diklasifikasikan sebagai berikut -
Local direct flow - Jika salah satu modul memanggil modul kedua dan meneruskan informasi ke modul tersebut atau modul yang dipanggil mengembalikan hasil ke pemanggil.
Local indirect flow - Jika modul yang dipanggil mengembalikan informasi yang kemudian diteruskan ke modul yang dipanggil kedua.
Global flow - Jika informasi mengalir dari satu modul ke modul lainnya melalui struktur data global.
Kompleksitas arus informasi dapat diungkapkan menurut Henry dan Kafura sebagai,
Information flow complexity (M) = length (M) × fan-in (M) × (fan-out (M))2
Dimana,
Fan-in (M) - Jumlah aliran lokal yang berhenti pada M + jumlah struktur data darimana informasi tersebut diambil oleh M.
Fan–out (M) - Jumlah aliran lokal yang berasal dari M + jumlah struktur data yang dimutakhirkan oleh M.
Mengukur Struktur Data
Struktur data dapat berupa keduanya local dan global.
Locally, jumlah struktur di setiap item data akan diukur. Pendekatan teori-grafik dapat digunakan untuk menganalisis dan mengukur properti dari struktur data individu. Dalam tipe data sederhana seperti integer, karakter, dan Boolean dipandang sebagai bilangan prima dan berbagai operasi yang memungkinkan kita untuk membangun struktur data yang lebih kompleks dipertimbangkan. Ukuran struktur data kemudian dapat didefinisikan secara hierarki dalam istilah nilai untuk bilangan prima dan nilai yang terkait dengan berbagai operasi.
Globally, jumlah total variabel buatan pengguna akan diukur.
Beberapa lembaga standar nasional dan internasional, organisasi profesional dan berorientasi industri telah terlibat dalam pengembangan standar SQA.
Lembaga dan organisasi berikut adalah pengembang utama SQA dan standar rekayasa perangkat lunak -
- IEEE (Institute of Electrical and Electronics Engineers) Computer Society
- ISO (Organisasi Internasional untuk Standardisasi)
- DOD (Departemen Pertahanan AS)
- ANSI (Institut Standar Nasional Amerika)
- IEC (Komisi Teknis Elektro Internasional)
- EIA (Asosiasi Industri Elektronik)
Organisasi-organisasi ini menyediakan standar internasional yang diperbarui untuk kualitas kegiatan profesional dan manajerial yang dilakukan dalam pengembangan perangkat lunak dan organisasi pemeliharaan.
Mereka juga memberikan sertifikasi SQA melalui audit kualitas profesional independen. Audit eksternal ini menilai pencapaian dalam pengembangan sistem SQA dan implementasinya. Sertifikasi, yang diberikan setelah audit berkala, hanya akan berlaku hingga audit berikutnya, dan oleh karena itu harus diperbarui. Saat ini, Layanan Sertifikasi ISO 9000 adalah penyedia sertifikasi SQA paling terkemuka di Eropa dan negara lain.
Mereka juga menyediakan alat untuk penilaian mandiri sistem SQA organisasi dan operasinya. Model Maturitas Kapasitas (CMM) yang dikembangkan oleh Software Engineering Institute (SEI), Carnegie Mellon University, dan ISO / IEC Std 15504 adalah contoh dari pendekatan ini.
Standar SQA
Standar jaminan kualitas perangkat lunak dapat diklasifikasikan menjadi dua kelas utama -
Standar manajemen jaminan kualitas perangkat lunak, termasuk sertifikasi dan metodologi penilaian (standar manajemen kualitas)
Standar proses pengembangan proyek perangkat lunak (standar proses proyek)
Standar Manajemen Mutu
Ini fokus pada sistem SQA organisasi, infrastruktur dan persyaratan, sambil menyerahkan pilihan metode dan alat kepada organisasi. Dengan standar manajemen kualitas, organisasi dapat terus memastikan bahwa produk perangkat lunak mereka mencapai tingkat kualitas yang dapat diterima.
Example - ISO 9000-3 dan Model Kematangan Kemampuan (CMM)
Standar Proses Proyek
Ini berfokus pada metodologi untuk melaksanakan proyek pengembangan dan pemeliharaan perangkat lunak. Standar ini meliputi:
- Langkah-langkah yang harus diambil
- Persyaratan dokumentasi desain
- Isi dokumen desain
- Desain ulasan dan masalah ulasan
- Pengujian perangkat lunak yang akan dilakukan
- Menguji topik
Secara alami, karena karakteristiknya, banyak standar SQA di kelas ini dapat berfungsi sebagai standar rekayasa perangkat lunak dan sebaliknya.
Karakteristik kedua kelas standar ini dirangkum dalam tabel berikut.
Karakteristik | Standar Manajemen Mutu | Standar Proses Proyek |
---|---|---|
Unit sasaran | Manajemen pengembangan perangkat lunak, pemeliharaan, dan unit SQA tertentu | Sebuah tim proyek pengembangan dan pemeliharaan perangkat lunak |
Fokus utama | Organisasi sistem, infrastruktur, dan persyaratan SQA | Metodologi untuk melaksanakan proyek pengembangan dan pemeliharaan perangkat lunak |
Tujuan standar | “Apa” yang ingin dicapai | "Bagaimana" melakukan |
Tujuan standar | Menjamin kualitas perangkat lunak pemasok dan menilai kemampuan proses perangkat lunaknya | Menjamin kualitas perangkat lunak pemasok dan menilai kemampuan proses perangkat lunaknya Menjamin kualitas proyek perangkat lunak tertentu. |
Contoh | CMM ISO 9000-3 SEI | ISO / IEC 12207 IEEEStd 1012-1998 |
Sertifikasi ISO 9001
ISO (Organisasi Internasional untuk Standardisasi) adalah federasi badan standar nasional di seluruh dunia. Komite teknis ISO mempersiapkan Standar Internasional. ISO bekerja sama erat dengan Komisi Elektro-teknis Internasional (IEC) dalam semua hal standardisasi elektro-teknis.
Standar Internasional dirancang sesuai dengan aturan yang diberikan dalam ISO / IEC Directive, Bagian 2. Draft Standar Internasional yang diadopsi oleh komite teknis diedarkan ke badan anggota untuk pemungutan suara. ISO 9001 disiapkan oleh Komite Teknis ISO / TC 176, Manajemen mutu dan jaminan mutu, Sub-komite SC 2, Sistem mutu.
Pendekatan Proses
Standar Internasional ini mempromosikan adopsi pendekatan proses ketika mengembangkan, menerapkan, dan meningkatkan efektivitas sistem manajemen mutu, untuk meningkatkan kepuasan pelanggan dengan memenuhi persyaratan pelanggan. Agar organisasi berfungsi secara efektif, ia harus menentukan dan mengelola berbagai aktivitas terkait. Suatu kegiatan atau serangkaian kegiatan yang menggunakan sumber daya, dan dikelola untuk memungkinkan transformasi masukan menjadi keluaran, dapat dianggap sebagai suatu proses.
Seringkali keluaran dari satu proses secara langsung membentuk masukan ke proses berikutnya. Penerapan sistem proses dalam suatu organisasi, bersama dengan identifikasi dan interaksi proses ini, dan manajemennya untuk menghasilkan hasil yang diinginkan, dapat disebut sebagai“process approach”.
Keuntungan dari pendekatan proses adalah kontrol berkelanjutan yang diberikannya atas hubungan antara proses individu dalam sistem proses, serta kombinasi dan interaksinya. Ketika digunakan dalam sistem manajemen mutu, pendekatan seperti itu menekankan pentingnya hal-hal berikut -
- Memahami dan memenuhi persyaratan
- Perlu memperhatikan proses dalam hal nilai tambah
- Dapatkan hasil kinerja dan efektivitas proses
- Perbaikan berkelanjutan dari proses berdasarkan pengukuran objektif
ISO 9001 - Aplikasi untuk Perangkat Lunak: Inisiatif TickIT
TickIT diluncurkan pada akhir 1980-an oleh industri perangkat lunak Inggris bekerja sama dengan Departemen Perdagangan dan Industri Inggris untuk mempromosikan pengembangan metodologi untuk mengadaptasi ISO 9001 dengan karakteristik industri perangkat lunak yang dikenal sebagai inisiatif TickIT.
TickIT juga mengkhususkan diri pada teknologi informasi (TI). Ini mencakup seluruh jajaran pengembangan perangkat lunak komersial dan layanan pemeliharaan. TickIT, sekarang dikelola dan dikelola oleh DISC Department of BSI (British Standards Institute), diakreditasi untuk sertifikasi organisasi IT di Inggris dan Swedia.
Aktivitasnya meliputi -
Publikasi Panduan TickIT, yang mendukung upaya industri perangkat lunak untuk menyebarkan sertifikasi ISO 9001. Panduan saat ini (edisi 5.0, TickIT, 2001), yang mencakup referensi ke ISO / IEC 12207 dan ISO / IEC 15504, didistribusikan ke semua pelanggan TickIT.
Kinerja penilaian berbasis audit dari sistem kualitas perangkat lunak dan konsultasi kepada organisasi tentang peningkatan pengembangan perangkat lunak dan proses pemeliharaan selain manajemen mereka.
Lakukan audit sertifikasi ISO 9000.
Auditor TickIT yang melakukan penilaian berbasis audit dan audit sertifikasi terdaftar di International Register of Certificated Audors (IRCA). Auditor IRCA terdaftar diwajibkan, antara lain, memiliki pengalaman dalam manajemen dan pengembangan perangkat lunak; mereka juga harus berhasil menyelesaikan kursus auditor.
Auditor utama yang terdaftar diharuskan memiliki pengalaman yang ditunjukkan dalam melakukan dan mengarahkan audit TickIT.
Penilaian proses perangkat lunak adalah pemeriksaan disiplin proses perangkat lunak yang digunakan oleh organisasi, berdasarkan model proses. Pengkajian mencakup identifikasi dan karakterisasi praktik saat ini, mengidentifikasi area kekuatan dan kelemahan, dan kemampuan praktik saat ini untuk mengontrol atau menghindari penyebab signifikan dari kualitas, biaya, dan jadwal yang buruk (perangkat lunak).
Penilaian perangkat lunak (atau audit) dapat terdiri dari tiga jenis.
SEBUAH self-assessment (first-party assessment) dilakukan secara internal oleh personel organisasi itu sendiri.
SEBUAH second-party assessment dilakukan oleh tim penilai eksternal atau organisasi dinilai oleh pelanggan.
SEBUAH third-party assessment dilakukan oleh pihak eksternal atau (misalnya, pemasok sedang dinilai oleh pihak ketiga untuk memverifikasi kemampuannya untuk membuat kontrak dengan pelanggan).
Penilaian proses perangkat lunak dilakukan di lingkungan terbuka dan kolaboratif. Mereka digunakan oleh organisasi untuk meningkatkan proses perangkat lunaknya, dan hasilnya dirahasiakan bagi organisasi. Organisasi yang akan dinilai harus memiliki anggota dalam tim penilai.
Penilaian Kematangan Proses Perangkat Lunak
Ruang lingkup penilaian proses perangkat lunak dapat mencakup semua proses dalam organisasi, bagian yang dipilih dari proses perangkat lunak, atau proyek tertentu. Sebagian besar pendekatan penilaian proses berbasis standar selalu didasarkan pada konsep kematangan proses.
Jika target penilaian adalah organisasi, hasil penilaian proses mungkin berbeda, bahkan pada penerapan metode yang sama secara berurutan. Ada dua alasan untuk hasil yang berbeda. Mereka,
Organisasi yang diselidiki harus ditentukan. Untuk perusahaan besar, beberapa definisi organisasi dimungkinkan dan oleh karena itu ruang lingkup penilaian yang sebenarnya mungkin berbeda dalam penilaian yang berurutan.
Bahkan dalam apa yang tampak sebagai organisasi yang sama, sampel proyek yang dipilih untuk mewakili organisasi dapat mempengaruhi ruang lingkup dan hasil.
Ketika unit target penilaian berada di tingkat proyek, penilaian harus mencakup semua faktor yang berarti yang berkontribusi pada keberhasilan atau kegagalan proyek. Ini tidak boleh dibatasi oleh dimensi yang ditetapkan dari model kematangan proses tertentu. Di sini, tingkat implementasi dan keefektifannya yang didukung oleh data proyek dinilai.
Kematangan proses menjadi relevan ketika sebuah organisasi bermaksud untuk memulai strategi perbaikan jangka panjang secara keseluruhan. Penilaian proyek perangkat lunak harus penilaian independen agar objektif.
Siklus Penilaian Proses Perangkat Lunak
Menurut Paulk dan rekan (1995), pendekatan penilaian berbasis CMM menggunakan siklus enam langkah. Mereka adalah -
Pilih tim - Anggota tim harus profesional yang memiliki pengetahuan dalam bidang rekayasa dan manajemen perangkat lunak.
Perwakilan situs yang akan dinilai menyelesaikan kuesioner kematangan proses standar.
Tim penilai melakukan analisis terhadap tanggapan kuesioner dan mengidentifikasi area yang memerlukan eksplorasi lebih lanjut sesuai dengan area proses utama CMM.
Tim penilai melakukan kunjungan situs untuk mendapatkan pemahaman tentang proses perangkat lunak yang diikuti oleh situs.
Tim penilai membuat daftar temuan yang mengidentifikasi kekuatan dan kelemahan proses perangkat lunak organisasi.
Tim penilai mempersiapkan analisis profil Area Proses Kunci (KPA) dan mempresentasikan hasilnya kepada audiens yang sesuai.
Misalnya, tim penilai harus dipimpin oleh Penilai Utama SEI yang berwenang. Tim harus terdiri dari empat hingga sepuluh anggota tim. Setidaknya, satu anggota tim harus berasal dari organisasi yang sedang dinilai, dan semua anggota tim harus menyelesaikan kursus Pengenalan SEI tentang CMM (atau yang setara) dan kursus pelatihan tim IPI CBA SEI. Anggota tim juga harus memenuhi beberapa pedoman seleksi.
Berkenaan dengan pengumpulan data, CBA IPI mengandalkan empat metode -
- Kuesioner kematangan standar
- Wawancara individu dan kelompok
- Review dokumen
- Umpan balik dari peninjauan draf temuan dengan peserta penilaian
SCAMPI
Metode Penilaian CMMI Standar untuk Peningkatan Proses (SCAMPI) dikembangkan untuk memenuhi persyaratan model CMMI (Software Engineering Institute, 2000). Ini juga didasarkan pada CBA IPI. Baik CBA IPI dan SCAMPI terdiri dari tiga fase -
- Rencana dan persiapan
- Lakukan penilaian di lokasi
- Laporkan hasil
Kegiatan untuk tahap perencanaan dan persiapan meliputi -
- Identifikasi ruang lingkup penilaian
- Kembangkan rencana penilaian
- Persiapkan dan latih tim penilai
- Buatlah penilaian singkat terhadap peserta
- Mengelola Kuesioner Penilaian CMMI
- Periksa tanggapan kuesioner
- Lakukan tinjauan dokumen awal
Kegiatan untuk fase penilaian di lokasi meliputi -
- Lakukan pertemuan pembukaan
- Lakukan wawancara
- Gabungkan informasi
- Siapkan presentasi draf temuan
- Sajikan draf temuannya
- Gabungkan, beri peringkat, dan persiapkan temuan akhir
Kegiatan tahap hasil pelaporan meliputi -
- Sajikan temuan akhir
- Lakukan sesi eksekutif
- Akhiri penilaian
Definisi IEEE untuk jaminan kualitas perangkat lunak adalah sebagai berikut -
"Pola yang terencana dan sistematis dari semua tindakan yang diperlukan untuk memberikan keyakinan yang memadai bahwa item atau produk sesuai dengan persyaratan teknis yang ditetapkan. Serangkaian aktivitas yang dirancang untuk mengevaluasi proses di mana produk dikembangkan atau diproduksi."
Tujuan Kegiatan SQA
Tujuan dari kegiatan SQA adalah sebagai berikut -
Dalam pengembangan perangkat lunak (berorientasi proses)
Memastikan tingkat keyakinan yang dapat diterima bahwa perangkat lunak akan sesuai dengan persyaratan teknis fungsional.
Menjamin tingkat kepercayaan yang dapat diterima bahwa perangkat lunak akan sesuai dengan penjadwalan manajerial dan persyaratan anggaran.
Memulai dan mengelola aktivitas untuk peningkatan dan efisiensi yang lebih besar dari pengembangan perangkat lunak dan aktivitas SQA.
Dalam pemeliharaan perangkat lunak (berorientasi produk)
Memastikan dengan tingkat keyakinan yang dapat diterima bahwa aktivitas pemeliharaan perangkat lunak akan sesuai dengan persyaratan teknis fungsional.
Memastikan dengan tingkat keyakinan yang dapat diterima bahwa aktivitas pemeliharaan perangkat lunak akan sesuai dengan penjadwalan manajerial dan persyaratan anggaran.
Memulai dan mengelola aktivitas untuk meningkatkan dan meningkatkan efisiensi pemeliharaan perangkat lunak dan aktivitas SQA. Ini melibatkan peningkatan prospek pencapaian persyaratan fungsional dan manajerial sambil mengurangi biaya.
Pengorganisasian untuk Jaminan Kualitas
Kerangka organisasi jaminan kualitas yang beroperasi dalam struktur organisasi mencakup peserta berikut -
Manajer
Eksekutif manajemen puncak, terutama eksekutif yang bertanggung jawab langsung atas jaminan kualitas perangkat lunak
Manajer departemen pengembangan dan pemeliharaan perangkat lunak
Manajer departemen pengujian perangkat lunak
Manajer proyek dan pemimpin tim proyek pengembangan dan pemeliharaan
Pemimpin tim pengujian perangkat lunak
Penguji
- Anggota tim pengujian perangkat lunak
Profesional SQA dan praktisi yang tertarik -
- Pengawas SQA
- Anggota komite SQA
- Anggota forum SQA
- Anggota tim unit SQA
Hanya manajer dan karyawan departemen pengujian perangkat lunak yang bekerja penuh waktu dalam melaksanakan tugas-tugas SQA. Yang lain mendedikasikan sebagian waktu mereka untuk masalah kualitas, baik selama pemenuhan fungsi manajerial atau tugas profesional mereka, atau sebagai sukarelawan pada orang lain, paling sering sebagai komite SQA, forum SQA, atau sebagai pengawas SQA.
Pada dasarnya, struktur tiga tingkat manajemen ada dalam organisasi pengembangan perangkat lunak -
- Manajemen puncak
- Manajemen departemen
- Manajemen proyek
Tanggung Jawab Manajemen Atas dalam Kualitas Perangkat Lunak
Berikut adalah tanggung jawab manajemen puncak dalam memastikan Kualitas Perangkat Lunak -
Menjamin kualitas produk perangkat lunak perusahaan dan layanan pemeliharaan perangkat lunak
Komunikasikan pentingnya kualitas produk dan layanan selain kepuasan pelanggan kepada karyawan di semua tingkatan
Yakinkan fungsi yang memuaskan dan kepatuhan penuh dengan persyaratan pelanggan
Pastikan bahwa sasaran mutu ditetapkan untuk sistem SQA organisasi dan sasarannya tercapai
Memulai perencanaan dan mengawasi implementasi perubahan yang diperlukan untuk menyesuaikan sistem SQA dengan perubahan internal dan eksternal utama yang terkait dengan klien, persaingan, dan teknologi organisasi
Melakukan intervensi secara langsung untuk mendukung penyelesaian situasi krisis dan meminimalkan kerusakan
Pastikan ketersediaan sumber daya yang dibutuhkan oleh sistem SQA
Langkah-langkah berikut dapat diambil oleh manajemen puncak untuk memenuhi tanggung jawabnya -
Menetapkan dan memperbarui kebijakan kualitas perangkat lunak organisasi.
Menugaskan salah satu eksekutif seperti Vice President SQA untuk bertanggung jawab atas masalah kualitas perangkat lunak
Melakukan tinjauan manajemen kinerja secara teratur sehubungan dengan masalah kualitas perangkat lunak
Kebijakan Kualitas Perangkat Lunak
Kebijakan kualitas perangkat lunak organisasi harus mengkomunikasikan persyaratan berikut -
Kesesuaian dengan maksud dan tujuan organisasi
Komitmen terhadap konsep jaminan kualitas perangkat lunak umum
Komitmen terhadap standar kualitas yang diadopsi oleh organisasi
Komitmen untuk mengalokasikan sumber daya yang memadai untuk jaminan kualitas perangkat lunak
Komitmen untuk terus meningkatkan kualitas dan produktivitas organisasi
Eksekutif yang Bertanggung Jawab atas Kualitas Perangkat Lunak
Tanggung jawab eksekutif yang bertanggung jawab atas masalah kualitas perangkat lunak dapat diklasifikasikan sebagai -
Tanggung jawab untuk mempersiapkan program dan anggaran kegiatan SQA tahunan
Tanggung jawab untuk penyusunan rencana pengembangan sistem SQA
Kontrol keseluruhan atas implementasi program kegiatan rutin SQA tahunan dan proyek pengembangan SQA yang direncanakan
Presentasi dan advokasi masalah SQA kepada manajemen eksekutif
Tanggung Jawab untuk Persiapan Program Kegiatan SQA Tahunan
Ini mengharuskan eksekutif untuk -
Tetapkan tujuan SQA sistem untuk tahun mendatang
Meninjau proposal yang disiapkan oleh unit SQA untuk program kegiatan tahunan dan memverifikasi potensi proposal untuk memenuhi tujuan yang ditetapkan untuk sistem SQA
Tentukan apakah program kegiatan sesuai dengan karakteristik dan ruang lingkup layanan subkontraktor dan pembelian perangkat lunak yang direncanakan untuk tahun yang akan datang
Menentukan kecukupan tenaga kerja dan sumber daya lain yang direncanakan untuk pelaksanaan program SQA
Menyetujui versi final dari anggaran dan program kegiatan SQA tahunan
Tanggung jawab untuk Penyusunan Rencana Pengembangan Sistem SQA
Rencana ini harus dapat beradaptasi dengan perubahan teknologi serta tuntutan dan persaingan pelanggan. Tanggung jawabnya meliputi -
Review tren yang diharapkan mempengaruhi kualitas perangkat lunak organisasi dalam waktu dekat
Tinjau proposal untuk adaptasi SQA seperti persiapan prosedur baru yang sesuai dengan alat baru dan standar SQA
Persiapan program pelatihan untuk tim pengembangan perangkat lunak veteran dan anggota tim yang baru direkrut
Pengembangan metrik kualitas perangkat lunak yang sesuai untuk mengevaluasi alat dan standar baru serta keberhasilan program pelatihan
Persetujuan versi akhir dari proyek pengembangan SQA yang direncanakan, termasuk jadwal dan anggarannya
Pengendalian Keseluruhan Pelaksanaan Program SQA Tahunan
Eksekutif yang bertanggung jawab bertanggung jawab untuk -
Pengawasan umum program kegiatan tahunan
Review kemajuan proyek adaptasi SQA
Pengawasan umum atas tindakan yang diambil untuk mewujudkan pencapaian kualitas yang ditentukan oleh tujuan tim (berdasarkan laporan berkala)
Review kepatuhan terhadap prosedur dan standar SQA berdasarkan audit kualitas internal
Tindak lanjut umum kepatuhan terhadap jadwal dan anggaran proyek pengembangan perangkat lunak
Tindak lanjut umum penyediaan layanan pemeliharaan berkualitas kepada pelanggan eksternal dan internal
Presentasi dan Advokasi Masalah SQA kepada Manajemen Eksekutif
Untuk meningkatkan kualitas dan menyelesaikan kesulitan sistem SQA, diperlukan -
Presentasi untuk persetujuan akhir dari program kegiatan dan anggaran tahunan yang diusulkan
Presentasi untuk persetujuan akhir dari proyek adaptasi SQA yang direncanakan bersama dengan anggaran yang sesuai
Inisiasi dan kepemimpinan rapat tinjauan manajemen berkala yang didedikasikan untuk kualitas perangkat lunak organisasi
Memulai diskusi tingkat manajemen yang didedikasikan untuk peristiwa kualitas perangkat lunak khusus, seperti kegagalan kualitas yang parah, ancaman terhadap penyelesaian proyek yang berhasil karena kekurangan staf profesional yang parah, krisis manajerial di unit SQA, dan sebagainya
Tanggung Jawab Manajemen Departemen untuk SQA
Tanggung jawab jaminan kualitas manajemen menengah meliputi -
Manajemen sistem manajemen kualitas perangkat lunak (tugas yang berhubungan dengan sistem kualitas)
Manajemen tugas yang terkait dengan proyek dan layanan yang dilakukan oleh unit atau tim di bawah otoritas manajer tertentu (tugas terkait proyek)
Tanggung jawab terkait sistem mutu
Ini termasuk kegiatan SQA yang akan dilakukan di tingkat departemen -
Penyusunan program dan anggaran kegiatan SQA tahunan departemen, berdasarkan program yang direkomendasikan yang disiapkan oleh unit SQA
Penyusunan rencana pengembangan sistem SQA departemen, berdasarkan rencana yang direkomendasikan yang disiapkan oleh unit SQA
Kontrol kinerja program kegiatan SQA tahunan dan proyek pengembangan departemen
Presentasi masalah SQA departemen kepada manajemen puncak
Tanggung Jawab Terkait Proyek
Ini bervariasi sesuai dengan prosedur organisasi dan distribusi kewenangan; mereka biasanya melibatkan -
Kontrol kepatuhan terhadap prosedur jaminan kualitas di unit departemen, termasuk badan CAB, SCM dan SCCA
Tindak lanjut rinci dari hasil tinjauan kontrak dan persetujuan proposal
Review kinerja unit kegiatan review yang direncanakan; persetujuan dokumen proyek dan penyelesaian tahap proyek
Tindak lanjut dari tes perangkat lunak dan hasil tes; persetujuan produk perangkat lunak proyek
Tindak lanjut kemajuan jadwal proyek pengembangan perangkat lunak dan penyimpangan anggaran
Nasihat dan dukungan untuk manajer proyek dalam menyelesaikan kesulitan jadwal, anggaran dan hubungan pelanggan
Tindak lanjut kualitas penyediaan layanan pemeliharaan
Tindak lanjut rinci dari risiko proyek dan solusinya
Tindak lanjut dari kepatuhan proyek dengan persyaratan pelanggan dan kepuasan pelanggan
Persetujuan pesanan perubahan perangkat lunak besar dan penyimpangan signifikan dari spesifikasi proyek
Tanggung jawab manajemen proyek pada kualitas perangkat lunak
Sebagian besar tanggung jawab manajemen proyek ditentukan dalam prosedur dan instruksi kerja; manajer proyek adalah orang yang bertanggung jawab untuk memastikan bahwa semua anggota tim mematuhi prosedur dan instruksi tersebut.
Tugasnya termasuk tugas profesional dan tugas manajerial, terutama yang berikut -
Professional hands-on tasks
Persiapan proyek dan rencana kualitas serta pembaruannya
Partisipasi dalam komite pelanggan-pemasok bersama
Tindak lanjut yang dekat dari kepegawaian tim proyek, termasuk menghadiri perekrutan, pelatihan dan instruksi
Management tasks
Manajer proyek menangani masalah tindak lanjut seperti -
Kinerja kegiatan tinjauan dan koreksi akibatnya
Pengembangan perangkat lunak dan kinerja unit pemeliharaan, integrasi dan pengujian sistem serta koreksi dan uji regresi
Kinerja tes penerimaan
Instalasi perangkat lunak di situs pelanggan jarak jauh dan eksekusi sistem perangkat lunak oleh pelanggan
Pelatihan SQA dan instruksi anggota tim proyek
Jadwal dan sumber daya yang dialokasikan untuk kegiatan proyek
Permintaan dan kepuasan pelanggan
Risiko pengembangan proyek yang berkembang, penerapan solusi dan kontrol hasil
Struktur unit SQA bervariasi menurut jenis dan ukuran organisasi. Gambar berikut menunjukkan contoh struktur standar dan semua komponen di bawah unit SQA. Dalam bab ini, kita akan membahas peran dan tanggung jawab masing-masing sub-unit.
Tugas yang Dilakukan oleh Kepala SQA Unit
Kepala unit SQA bertanggung jawab atas semua tugas penjaminan kualitas yang dilakukan oleh unit SQA dan sub-unitnya. Tugas-tugas ini dapat diklasifikasikan ke dalam kategori berikut -
- Tugas perencanaan
- Manajemen unit
- Kegiatan profesional SQA
Tugas Perencanaan
Penyusunan usulan program kegiatan tahunan dan anggaran unit
Merencanakan dan memperbarui sistem manajemen mutu perangkat lunak organisasi
Penyusunan program kegiatan SQA tahunan yang direkomendasikan dan rencana pengembangan sistem SQA untuk departemen pengembangan dan pemeliharaan perangkat lunak
Tugas Manajemen
Manajemen aktivitas tim SQA
Memantau pelaksanaan program kegiatan SQA
Nominasi anggota tim, anggota komite SQA dan wali SQA
Penyusunan laporan khusus dan berkala, misalnya, status masalah kualitas perangkat lunak dalam organisasi dan laporan kinerja bulanan
Kegiatan Profesional SQA
- Partisipasi dalam komite bersama proyek
- Partisipasi dalam tinjauan desain formal
- Review dan persetujuan penyimpangan dari spesifikasi
- Konsultasi dengan manajer proyek dan pemimpin tim
- Partisipasi dalam komite dan forum SQA
Siklus Hidup Proyek SQA
Tugas SQA yang terkait dengan sub-unit siklus hidup proyek dapat diklasifikasikan menjadi dua kelompok -
Tindak lanjut manajerial dan tugas persetujuan "murni" (tugas kontrol siklus hidup proyek)
Partisipasi aktif atau "hands-on" atau aktif dalam kegiatan SQA tim proyek, yang memerlukan kontribusi profesional (tugas partisipasi)
Tugas Kontrol Siklus Hidup Proyek
Tindak lanjut dari kepatuhan tim pengembangan dan pemeliharaan dengan prosedur SQA dan instruksi kerja
Persetujuan atau rekomendasi produk perangkat lunak sesuai dengan prosedur yang relevan
Memantau pengiriman layanan pemeliharaan perangkat lunak ke pelanggan internal dan eksternal
Memantau kepuasan pelanggan dan memelihara kontak dengan perwakilan jaminan kualitas pelanggan
Tugas Partisipasi
Tugas ini termasuk partisipasi dalam -
- Tinjauan kontrak
- Persiapan dan pemutakhiran pengembangan proyek dan rencana kualitas
- Ulasan desain formal
- Ulasan desain formal subkontraktor
- Pengujian perangkat lunak, termasuk pengujian penerimaan pelanggan
- Tes penerimaan perangkat lunak dari produk perangkat lunak subkontraktor
- Pemasangan produk perangkat lunak baru
Tugas Operasi Infrastruktur SQA
Sistem SQA menggunakan berbagai komponen infrastruktur untuk beroperasi dengan lancar, yaitu -
- Prosedur dan instruksi kerja
- Mendukung perangkat berkualitas (templat, daftar periksa)
- Pelatihan staf, instruksi dan sertifikasi
- Tindakan pencegahan dan korektif
- Manajemen konfigurasi
- Kontrol dokumentasi
Lebih khusus lagi, tugas sub-unit SQA mengenai komponen ini meliputi -
Penerbitan versi terbaru dari prosedur, instruksi kerja, templat, daftar periksa, dan sebagainya, bersama dengan peredarannya dalam bentuk hard copy dan / atau melalui sarana elektronik
Transmisi pelatihan dan instruksi tentang kepatuhan dan penerapan prosedur SQA, instruksi kerja dan item serupa kepada staf baru dan saat ini
Instruksi dari wali SQA mengenai prosedur baru dan yang direvisi serta alat dan metode pengembangan, di antara komponen lainnya
Memantau dan mendukung penerapan prosedur SQA baru dan revisi
Tindak lanjut kegiatan sertifikasi staf
Proposal subjek yang membutuhkan tindakan preventif dan korektif, termasuk partisipasi dalam komite CAB
Tindak lanjut dari aktivitas manajemen konfigurasi, termasuk partisipasi dalam komite CCA
Tindak lanjut kepatuhan terhadap prosedur dokumentasi dan instruksi kerja
Tugas Audit dan Sertifikasi Internal SQA
Jenis audit SQA yang dilakukan di atau oleh organisasi perangkat lunak dapat diklasifikasikan sebagai berikut -
Audit internal
Audit subkontraktor dan pemasok untuk mengevaluasi sistem SQA mereka
Audit eksternal dilakukan oleh badan sertifikasi
Audit eksternal dilakukan oleh pelanggan yang ingin mengevaluasi sistem SQA sebelum menerima organisasi sebagai pemasok
Dua kelas audit pertama dimulai dan dilakukan oleh subunit SQA, dua kelas terakhir oleh badan eksternal.
Unit SQA melakukan tugas berikut untuk audit SQA internal
Persiapan program tahunan untuk audit SQA internal
Kinerja audit SQA internal
Tindak lanjut perbaikan dan perbaikan akan dilakukan oleh tim yang diaudit dan unit lainnya
Penyusunan laporan ringkasan berkala status temuan audit, termasuk rekomendasi perbaikan
Unit SQA melakukan tugas berikut untuk audit subkontraktor dan pemasok -
Persiapan program tahunan untuk audit SQA subkontraktor dan pemasok
Kinerja audit SQA subkontraktor dan pemasok
Tindak lanjut dari koreksi dan perbaikan yang akan dilakukan oleh subkontraktor dan pemasok yang diaudit
Pengumpulan data tentang kinerja subkontraktor dan pemasok dari sumber internal maupun eksternal
Evaluasi berkala sistem SQA subkontraktor dan pemasok bersertifikasi organisasi berdasarkan laporan audit dan informasi yang dikumpulkan dari sumber internal dan eksternal lainnya. Laporan evaluasi meliputi -
Rekomendasi terkait sertifikasi subkontraktor dan pemasok
Audit eksternal yang dilakukan oleh badan sertifikasi melibatkan tugas-tugas berikut -
Koordinasi isi dan jadwal audit sertifikasi
Penyusunan dokumen yang ditentukan oleh lembaga sertifikasi
Instruksi tim yang diaudit dan kinerja persiapan yang diperlukan untuk audit sertifikasi
Partisipasi dalam audit sertifikasi
Pastikan koreksi dan peningkatan yang diperlukan dilakukan
Audit SQA yang dilakukan oleh pelanggan organisasi memerlukan tugas-tugas ini -
Koordinasi isi dan jadwal audit
Penyusunan dokumen ditentukan oleh auditor pelanggan
Instruksi tim yang diaudit dan kinerja persiapan yang diperlukan untuk audit SQA oleh pelanggan organisasi
Partisipasi dalam audit
Pastikan bahwa koreksi dan peningkatan yang diperlukan telah dilakukan
Tugas Dukungan SQA
Sebagian besar konsumen layanan dukungan SQA berada di dalam organisasi. Mereka termasuk manajer proyek, pemimpin tim, dan pengawas SQA. Tugas mereka meliputi -
Penyusunan rencana proyek dan rencana kualitas proyek
Tim peninjau kepegawaian
Pilihan langkah-langkah untuk memecahkan risiko pengembangan perangkat lunak yang teridentifikasi
Pilihan tindakan untuk mengatasi penundaan jadwal dan pembengkakan anggaran
Pilihan metrik SQA dan komponen biaya perangkat lunak
Penggunaan sistem informasi SQA
Pilihan metodologi dan alat pengembangan yang mencerminkan data pengalaman kegagalan yang dikumpulkan oleh unit SQA
Standar SQA dan Prosedur Tugas
Sub-unit SQA sangat terlibat dalam memutuskan standar SQA mana yang akan diadopsi serta mengembangkan dan memelihara prosedur organisasi. Untuk memenuhi kewajiban petugas, unit SQA diharuskan untuk -
Siapkan program tahunan untuk pengembangan prosedur baru dan pembaruan prosedur
Bertanggung jawab atas pengembangan prosedur baru dan pembaruan prosedur, dengan partisipasi dalam komite dan forum yang sesuai
Tindak lanjut atas perkembangan dan perubahan dalam SQA dan standar rekayasa perangkat lunak; pengenalan prosedur tambahan dan perubahan yang relevan dengan organisasi
Memulai pembaruan dan adaptasi prosedur dalam menanggapi perubahan dalam standar profesional, termasuk adopsi atau penghapusan standar yang diterapkan oleh organisasi
Tugas Rekayasa SQA
Tindak lanjut dari kemajuan profesional, solusi kesulitan operasional dan analisis kegagalan ahli adalah tujuan langsung dari sub-unit SQA ini.
Oleh karena itu, tugas teknik utama melibatkan hal-hal berikut -
Menguji aspek kualitas dan produktivitas sehubungan dengan alat pengembangan baru dan versi baru dari alat pengembangan yang saat ini digunakan
Evaluasi kualitas dan produktivitas pengembangan baru dan metode pemeliharaan serta perbaikan metode
Pengembangan solusi untuk kesulitan yang dihadapi dalam penerapan alat dan metode pengembangan perangkat lunak yang saat ini digunakan
Pengembangan metode untuk mengukur kualitas perangkat lunak dan produktivitas tim
Penyediaan dukungan teknologi kepada komite CAB selama analisis kegagalan pengembangan perangkat lunak dan perumusan solusi yang diusulkan
Tugas Sistem Informasi SQA
Sistem informasi SQA dimaksudkan untuk memfasilitasi dan meningkatkan fungsi sistem SQA. Tugas yang terlibat termasuk -
Pengembangan sistem informasi SQA untuk pengembangan perangkat lunak dan unit pemeliharaan untuk
pengumpulan data aktivitas
pemrosesan, misalnya, laporan berkala, daftar, laporan pengecualian, dan kueri
pemrosesan, misalnya, laporan berkala, daftar, laporan pengecualian, dan kueri
Pengembangan sistem informasi SQA yang memfasilitasi pemrosesan informasi unit SQA yang disampaikan oleh unit pengembangan dan pemeliharaan perangkat lunak termasuk perkiraan metrik kualitas perangkat lunak dan biaya kualitas perangkat lunak
Memperbarui sistem informasi SQA
Pengembangan dan pemeliharaan situs Internet / Intranet SQA organisasi
Pengawas SQA dan Tugas Mereka
Pengawas SQA adalah anggota yang terutama terlibat dalam promosi kualitas perangkat lunak. Anggota ini memberikan dukungan internal yang diperlukan untuk berhasil menerapkan komponen SQA.
Tugas mereka mungkin berbeda tergantung pada organisasi. Oleh karena itu, mungkin tugas terkait unit dan / atau organisasi.
Tugas terkait Unit
Dukung rekan kerja untuk memecahkan kesulitan selama penerapan prosedur kualitas perangkat lunak dan instruksi kerja
Membantu manajer unit dalam melaksanakan tugas SQA terkait
Mempromosikan kepatuhan dan memantau pelaksanaan prosedur SQA dan instruksi kerja oleh rekan kerja
Laporkan peristiwa ketidakpatuhan yang substansial dan sistematis kepada unit SQA
Laporkan kegagalan kualitas perangkat lunak yang parah ke unit SQA
Tugas Terkait Organisasi
Memicu perubahan dan pembaruan prosedur SQA di seluruh organisasi dan instruksi kerja
Memicu perbaikan proses pengembangan dan pemeliharaan dalam organisasi
Memulai aplikasi ke CAB terkait solusi untuk kegagalan berulang yang diamati di masing-masing unit
Identifikasi kebutuhan pelatihan SQA di seluruh organisasi dan usulkan program pelatihan atau instruksi yang sesuai untuk dilaksanakan oleh unit SQA
Komite SQA dan Tugasnya
Komite SQA dapat bersifat permanen atau ad hoc. Tugas dapat sangat bervariasi dari satu organisasi ke organisasi lainnya.
Permanent committees biasanya berurusan dengan SCC (Software Change Control), CA (Corrective Actions), prosedur, alat pengembangan metode dan metrik kualitas.
Ad hoc committees biasanya menangani kasus tertentu yang menarik secara umum seperti memperbarui prosedur tertentu, analisis dan solusi kegagalan perangkat lunak, menguraikan metrik perangkat lunak untuk proses atau produk yang ditargetkan, memperbarui biaya kualitas perangkat lunak dan metode pengumpulan data untuk masalah tertentu.
Komite SQA permanen merupakan bagian integral dari kerangka organisasi SQA; tugas dan operasi mereka biasanya ditentukan dalam prosedur SQA organisasi.
Komite ad hoc dibentuk berdasarkan masalah jangka pendek, dengan anggota yang ditunjuk oleh eksekutif yang bertanggung jawab atas masalah kualitas perangkat lunak, kepala Unit SQA, sub-unit SQA, komite SQA permanen, atau badan lain yang memulai pembentukannya dan memiliki minat dalam pekerjaan. Badan ini juga menentukan tugas dari komite ad hoc.