Proses Software & Project Metrics

Presentasi berjudul: "Proses Software & Project Metrics"— Transcript presentasi:

1 Proses Software & Project Metrics
Pertemuan V

2 :: Outline Pendahuluan 4.1. Software Metric 4.2. Size Oriented Metric
4.3. Function Oriented Metric

3 :: Pendahuluan Pengukuran merupakan hal yang pokok bagi disiplin enginering Tak terkecuali untuk software enginering

4 :: Pendahuluan Seperti kutipan perkataan Lord Kelvin :
“Bila anda dapat mengukur apa yang sedang anda bicarakan dan mengexpresikan dalam angka, berarti anda memahaminya…dan bila tidak berarti pengetahuan anda belum lengkap…”

5 4.1. SOFTWARE METRIC Software metric = cara untuk mengukur sebuah software. Software metric mengacu pada pengukuran sebuah software dalam jangkauan yang luas. Pengukuran diterapkan guna pengembangan selanjutnya dengan dasar yang kontinyu. Membantu perhitungan, kontrol kualitas, perkiraan produktivitas & kontrol proyek. Membantu mengambil keputusan taktis saat proyek sedang berjalan.

6 4.1. SOFTWARE METRIC Pengukuran, metrik, indikator Pengukuran = kegiatan menentukan nilai kuantitatif dari luasan, jumlah, dimensi, kapasitas, ukuran dari atribut sebuah proses/produk. Metrik = ukuran kuantitatif dari tingkat dimana sebuah sistem, komponen,/proses memiliki atribut tertentu Indikator = sebuah metrik/kombinasi dari metrik yang memberikan pengetahuan ke dalam proses perangkat lunak/produk, untuk kemudian memberikan pengetahuan kepada perekayasa untuk menyesuaikan proses, proyek, dan produk yang lebih baik.

7 4.1. SOFTWARE METRIC Indikator proses
Indikator proses  memungkinkan sebuah organisasi RPL memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung Mis : paradigma, tugas2 RPL, produk kerja, dan kejadian penting

8 4.1. SOFTWARE METRIC Indikator proyek
Indikator proyek  memungkinkan manager proyek : Memperkirakan status proyek Menelusuri resiko2 potensial. Menemukan area masalah sebelum semakin kritis Menyesuaikan aliran kerja Mengevaluasi kemempuan tim & kontrol kualitas atas hasil kerja RPL

9 4.1. SOFTWARE METRIC Gambar : determinan untuk kualitas dan efektifitas organisasional perangkat lunak

10 4.1. SOFTWARE METRIC Keterangan gambar :
Proses ditengah segitiga yang menghubungkan 3 faktor yang berpengaruh terhadap kualitas SW & unjuk kerja Ketrampilan manusia = faktor paling pengaruh pada kualitas & unjuk kerja tim Teknologi (metode2 SW) juga berpengaruh Segitiga berada dalam lingkaran yang menggambarkan kondisi lingkungan : lingkungan pengembangan (alat bantu CASE), kondisi bisnis (batas waktu,aturan bisnis), karakteristik pelanggan (komunikasi yang lancar)

11 4.1. SOFTWARE METRIC Kesalahan & Cacat
Kesalahan = ketidaksempurnaan yang ditemukan sebelum disampaikan kepada end-user Cacat = ketidaksempurnaan yang ditemukan sesudah disampaikan kepada end-user

12 4.1. SOFTWARE METRIC Distribusi cacat yang sederhana
Gambar : 8 penyebab cacat dan sumbernya (arsiran)

13 4.1. SOFTWARE METRIC Untuk membantu mendiagnosa data dilakukan pengembangan sebuah diagram fishbone. Diagram fishbone memperlihatkan penyebab dari kelas cacat.

14 4.1. SOFTWARE METRIC Keterangan gambar :
Punggung(garis pusat) merepresentasikan faktor kualitas yang sedang dipertimbangkan Masing2 rusuk(garis diagonal) menunjukkan penyebab potensial masalah kualitas (ex: syarat yg hilang, ambiguitas, syarat yg tidak tepat, syarat yg diubah). Notasi punggung & rusuk ditambahkan ke rusuk utama dari diagram untuk memperluas penyebab yang dicatat.

15 4.1. SOFTWARE METRIC Pengukuran Software Ada dua pengukuran: Langsung
Misal: Panjang program (LOC) yang diproduksi, kecepatan eksekusi, ukuran memori, dll. Tidak langsung Misal: Fungsionalitas, kualitas, komplexitas, efisiansi, dll

16 4.1. SOFTWARE METRIC Permasalahan pengukuran
Bagaimana sebuah organisasi menggabungkan metrik yg datang dari proyek & individu yg berbeda? Mis : dalam satu proyek dibentuk 2 tim yg mencatat & mengkatagorikan kesalahan2 yg ada. Tim 1 menemukan 342 kesalahan. Tim 2 menemukan 184 kesalahan. Tim mana yg lebih efektif dlm menemukan kesalahan?

17 4.1. SOFTWARE METRIC TIDAK TAHU ! ;)
Kita tidak bisa menjawabnya, karena kita tidak tahu ukuran dan komplexitas proyek. Oleh karena itu perlu adanya normalisasi agar tercipta metrik dengan pembanding yang mendekati sama.

18 4.2. Size Oriented Metric Size oriented software metric dihasilkan melalui normalisasi pengukuran kualitas dan atau pengukuran produktifitas dengan mempertimbangkan “Ukuran” software yang dihasilkan.

19 4.2. Size Oriented Metric Gambar : metrik size-oriented

20 4.2. Size Oriented Metric Untuk mengembangkan metrik yg baru dari data tabel diatas yang belum sempurna, kita dapat menggunakan sederetan kode sebagai nilai normalisasinya. Size Oriented Metric yang bisa dikembangkan untuk masing-masing proyek: (mis : normalisasi dr KLOC) Error per KLOC (Kilo Lines of Code) Defect per KLOC $ per KLOC page of documentation per KLOC

21 4.2. Size Oriented Metric Sebagai tambahan, Metrik lain yang dapat dihitung : Kesalahan/person-month LOC/person-month $/halaman dokumentasi

22 4.2. Size Oriented Metric Perdebatan
Metrik size oriented tidak diterima secara universal sebagai cara terbaik untuk mengukur proses perkembangan SW. Kontroversi berkisar masalah pemakaian LOC Mereka yg setuju  LOC = artifak proyek Mereka yg tidak setuju  LOC tergantung bahasa pemrograman …

23 4.2. Size Oriented Metric Lalu…bagaimana menurut anda?

24 4.2. Size Oriented Metric Pasrah…;)

25 4.3. Function Oriented Metric
Function Oriented Software metric menggunakan pengukuran fungsionalitas yang dihasilkan aplikasi. Fungsionalitas tersebut tidak bisa diukur secara langsung, akan tetapi harus diturunkan secara tidak langsung dengan menggunakan pengukuran langsung yang lainnya.

26 4.3. Function Oriented Metric
Function oriented metric menggunakan pengukuran yang dinamakan “Function Point”. Function Point dihitung dengan melengkapi tabel berikut:

27 4.3. Function Oriented Metric
Keterangan gambar : Jumlah input pemakai : setiap input pemakai yang memberikan data kepada aplikasi. (mis: entry data) Jumlah output pemakai : setiap output pemakai yang memberikan informasi dari aplikasi kepada pemakai. (mis: laporan, tampilan kesalahan) Jumlah penyelidikan pemakai : input on-line yang mengakibatkan respon aplikasi dalam bentuk output on-line pula Jumlah file : jumlah data logis baik dalam suatu database besar atau file terpisah Jumlah interface internal : semua interface yg dibaca mesin (file data pada disket) yang digunakan untuk memindahkan informasi.

28 4.3. Function Oriented Metric
Untuk menghitung function point: FP = jumlah total x [0,65 + 0,01 x SFi] Fi (i = 1 s/d 14) Merupakan “complexity Adjustment values” berdasarkan respon pada pertanyaan- pertanyaan berikut:

29 4.3. Function Oriented Metric
Apakah system memerlukan back-up dan recovery yang reliable ? Apakah komunikasi data dibutuhkan ? Apakah terdapat fungsi proses yang tersebar ? Apakah performa hal yang kritikal ? Apakah sistem tersebut dijalankan pada lingkungan operasional yang sudah dan bebannya berat ? Apakah sistem tersebut memerlukan entry data secara online ? Apakah online data entri tersebut memerlukan transaksi input yang harus dibuat pada banyak screen atau operasi ? Apakah master file diupdate secara online ? Apakah input, output, file atau inquiries hal yang komplek ? Apakah proses internal hal yang komplek ? Apakah program (code) dirancang supaya reusable ? Apakah konversi dan instalasi termasuk dalam perencanaan ? Apakah sistem tersebut dirancang untuk beberapa organisasi yanng berbeda ? Apakah aplikasi dirancang untuk memberikan fasilitas perubahan dan kemudahan penggunaan bagi user ?

30 4.3. Function Oriented Metric
Rate masing-masing faktor pada skala 0 – 5

31 selesai…