5. Proses Perangkat Lunak dan Metrik Proyek 5.1 Domain Metrik 5.1.1 Tujuan Umum Pengukuran 5.1.2 Determinan Kualitas dan Efektivitas Perangkat Lunak 5.2 Pengukuran Perangkat Lunak 5.2.1 Size-Oriented Metrics 5.2.2 Function-Oriented Metrics 5.2.2.1 Function Points 5.2.2.2 Penghitungan Metrik Function Points 5.2.2.3 Feature Points 5.2.2.4 Penentuan Kompleksitas Transformasi Function Points 5.3 Penyatuan Pendekatan Metrik yang Berbeda 5.4 Kualitas Perangkat Lunak 5.4.1 Faktor yang Mempengaruhi Kualitas 5.4.2 Faktor yang Mempengaruhi Kualitas (Gilb) 5.5 Penyatuan Metrik-metrik dlm Proses Perangkat Lunak
Proses Perangkat Lunak dan Metrik Proyek Measure (mengukur); kuantitatif luasan, jumlah, dimensi, kapasitas, atau ukuran dari atribut sebuah proses atau produk. Measurement (pengukuran); kegiatan menentukan sebuah measure. Metrics (IEEE): ukuran kuantitatif dari tingkat di mana sebuah sistem, komponen, atau proses memiliki atribut tertentu Indikator adalah sebuah metrik atau kombinasi dari metrik yang memberikan pengetahuan ke dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk perangkat lunak.
5.1 Domain Metrik Pengukuran perangkat lunak dilakukan pada proses dan proyek perangkat lunak. Indikator proses memungkinkan: Software engineer memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung. Manajer dan pelaksana memperkirakan hal-hal yang harus dikerjakan dan yang tidak Indikator proyek, memungkinkan manajer proyek: Memperkirakan status proyek Menelusuri resiko-resiko potensial Menemukan area masalah sebelum menjadi kritis Menyesuaikan aliran kerja atau tugas-tugas Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas.
5.1.1 Tujuan Umum Pengukuran Mengetahui kualitas perangkat lunak; baik atau jelek Menilai produktifitas pembuatan perangkat lunak; kecepatan pembuatan, ukuran perangkat lunak Menilai manfaat dari penerapan sebuah metoda; mencari paradigma andalan Dasar untuk melakukan perkiraan; pedoman di masa mendatang Membantu untuk memastikan apakah dibutuhkan peralatan baru atau pelatihan tambahan?
5.1.2 Determinan Kualitas dan Efektivitas Perangkat Lunak
5.2 Pengukuran Perangkat Lunak Size-Oriented Metrics: metrik yang berorientasi pada besar fisik ukuran perangkat lunak Function-Oriented Metrics: metrik yang berorientasi pada fungsionalitas dan utilitas perangkat lunak, menggunakan: Function Points Feature Points
5.2.1 Size-Oriented Metrics Normalisasi kualitas dan produktivitas dengan mengukur besar-kecilnya (LOC/KLOC) perangkat lunak, sehingga diperoleh: Error per KLOC Defect (cacat) per KLOC Rupiah (Rp) per LOC Halaman dokumentasi per KLOC Metrik lain dapat diturunkan: Error per orang-bulan LOC per orang-bulan Rupiah (Rp) per halaman dokumentasi
Contoh (size-oriented metrics)
Kontroversi Size-Oriented Metrics Metrik size-oriented tidak diterima secara universal; kontroversi terletak pada pemakaian LOC. Pendukung: LOC merupakan artifak proyek pengembangan perangkat lunak yang mudah dihitung. Penentang: LOC tergantung bahasa pemrograman, LOC tidak mendukung desain yang baik tetapi program singkat, tidak dapat dengan mudah mengakomodasi bahasa non-prosedural, dan pemakaiannya membutuhkan tingkat detail yang sulit dicapai.
5.2.2 Function-Oriented Metrics Mengukur secara tidak langsung. Ditekankan pada fungsional & utilitas program. Diusulkan pertama kali oleh Albrecht, dengan usulan cara perhitungan yang disebut: function point (FP). FP diturunkan dengan menggunakan hubungan empiris berbasis pada sesuatu yang terukur dari domain informasi dan berhubungan dengan kompleksitas PL. (lihat berikut)
5.2.2.1 Function Points Domain Informasi: Jumlah input dari user: jumlah user input yang dibutuhkan aplikasi Jumlah output untuk user: jumlah semua keluaran baik laporan maupun kesalahan (ke printer/layar) Jumlah input inquiry: masukan on-line yang mengakibatkan keluaran on-line Jumlah file Jumlah interface eksternal: semua interface yang dibaca oleh mesin untuk memindahkan informasi ke sistem lain.
5.2.2.2 Penghitungan Metrik Function Points Weighting Factor measurement parameter count simple average complex number of user inputs x 3 4 6 = number of user outputs x 4 5 7 = number of user inquiries x 3 4 6 = number of files x 7 10 15 = number of external interfaces x 5 7 10 = total FP= total x [0.65 + 0.01 x Fi] Domain kompleksitas Fi (i = 1 s/d 14) adalah ‘complexity adjustment values’ berdasarkan respon yang diperoleh dari pertanyaan-pertanyaan berikut ini.
Pertanyaan-Pertanyaan Untuk menghitung Fi, pertanyaan-pertanyaan di bawah ini dijawab dengan memberi nilai antara 0 s/d 5 Apakah sistem memerlukan backup dan recovery? Apakah diperlukan fasilitas komunikasi data? Apakah diperlukan fasilitas ‘distributed processing’? Apakah kinerja sangat penting? Apakah sistem akan dijalankan pada lingkungan yang sudah ada yang sudah terpakai secara penuh? Apakah memerlukan pemasukan data secara ‘on-line’? Apakah pemasukan data ‘on-line’ terjadi pada transaksi input thd layar atau operasi ganda? Apakah file master di’update’ secara on-line? Apakah input,output, file secara inquiry begitu kompleks? Apakah proses internal begitu kompleks? Apakah kode yang dibuat harus dapat digunakan ulang? Apakah konversi dan instalasi termasuk dalam perancangan? Apakah sistem dirancang untuk dapat diinstall pada berbagai organisasi yang berbeda? Apakah aplikasi dirancang untuk memberikan fasilitas perubahan dan kemudahan pemakaian bagi user?
5.2.2.3 Feature Points Seperti function point dengan penambahan karakteristik perangkat lunak lain: algorithma. Boeing telah mengembangkan function point extension untuk sistem-sistem real time yang disebut 3D function point. Untuk menghitung 3D function point hubungan berikut dipakai Index = I + O + Q + F + E + T + R Keterangan : I = input O = output Q = inquiry, F = internal data structure E = external file, T = transformation, R = transition.
5.2.2.4 Penentuan Kompleksitas Transformasi Function Points Semantic Statements 1 - 5 6 - 10 11 + Processing Steps 1 - 10 low low average 11 - 20 low average high 21 + average high high
5.3 Penyatuan Pendekatan Metrik yang Berbeda
5.4 Kualitas Perangkat Lunak 5.4.1 Faktor yang Mempengaruhi Kualitas McCall dan Cavano mendefinisikan satu set quality factors yang merupakan tahap awal untuk mengembangkan metrik untuk pengukuran kualitas perangkat lunak: product operation (using it), product revision (changing it), dan product transition (porting it). (dibahas di Bab Matriks Teknis PL)
5.4.2 Faktor yang Mempengaruhi Kualitas (Gilb) Correctness: perangkat lunak bekerja dengan baik & benar ( correctness = kesalahan / kloc ) Maintainability: mudah dirawat; mttc (mean time to change) kecil Integrity: tahan gangguan; tingkat sekuriti yang baik Usability: mudah digunakan
5.5 Penyatuan Metrik-metrik dalam Proses Perangkat Lunak software engineering process software data project collection measures data collection metrics software product data collection indicators ***