Mengukur produktivitas dalam pengembangan perangkat lunak

Presentasi berjudul: "Mengukur produktivitas dalam pengembangan perangkat lunak"— Transcript presentasi:

1 Mengukur produktivitas dalam pengembangan perangkat lunak

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

3 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…”

4 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.

5 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.

6 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

7 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

8 SOFTWARE METRIC Gambar : determinan untuk kualitas dan efektifitas organisasional perangkat lunak

9 SOFTWARE METRIC Keterangan gambar :
Proses ditengah segitiga yang menghubungkan 3 faktor yang berpengaruh terhadap kualitas Soft Ware & unjuk kerja Ketrampilan manusia = faktor paling pengaruh pada kualitas & unjuk kerja tim Teknologi (metode Soft Ware) 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)

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

11 SOFTWARE METRIC 8 penyebab cacat dan sumbernya

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

13 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.

14 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 LOC (Line of Code) dari baris kode suatu perangkat lunak

15 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?

16 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.

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

18 Size Oriented Metric

19 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.

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

21 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.

22 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:

23 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 ?

24 Function Oriented Metric
Rate masing-masing faktor pada skala 0 – 5

25 Contoh: Pada proyek alpha (tabel record metrik size oriented) sudah dihitung bahwa jumlah input pemakainya ada 18 buah, jumlah output pemakai: 6 buah, jumlah penyelidikan pemakai 22 buah, jumlah file 45 buah, jumlah interface eksternal 20 buah, dengan asumsi bahwa jumlah input pemakai rata-rata, jumlah output pemakai sederhana, jumlah penyelidikan pemakai rata-rata, jumlah file kompleks, jumlah interface eksternal sederhana. Semua karakteristik pada perangkat lunak ini moderat. Hitung $ per FP nya!

26 Jawab: jumlah total = (18 x 4) + (6 x 4) + (22 x 4) + (45 x 15) + (20 x 6) = 979 Fi = 14 x 2 = 28 FP = 979 x (0,65 + (0,01 x 28)) = 910,47 $ pada proyek alpha: $ per FP = / 910,47 = $184,52

27 SELESAI