Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Pertemuan V.  Pendahuluan  4.1. Software Metric  4.2. Size Oriented Metric  4.3. Function Oriented Metric.

Presentasi serupa


Presentasi berjudul: "Pertemuan V.  Pendahuluan  4.1. Software Metric  4.2. Size Oriented Metric  4.3. Function Oriented Metric."— Transcript presentasi:

1 Pertemuan V

2  Pendahuluan  4.1. Software Metric  4.2. Size Oriented Metric  4.3. Function Oriented Metric

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

4  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  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 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 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 Indikator proyek  Indikator proyek  memungkinkan manager proyek : 1.Memperkirakan status proyek 2.Menelusuri resiko2 potensial. 3.Menemukan area masalah sebelum semakin kritis 4.Menyesuaikan aliran kerja 5.Mengevaluasi kemempuan tim & kontrol kualitas atas hasil kerja RPL

9  Gambar : determinan untuk kualitas dan efektifitas organisasional perangkat lunak

10 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 Kesalahan & Cacat  Kesalahan = ketidaksempurnaan yang ditemukan sebelum disampaikan kepada end-user  Cacat = ketidaksempurnaan yang ditemukan sesudah disampaikan kepada end-user

12  Distribusi cacat yang sederhana  Gambar : 8 penyebab cacat dan sumbernya (arsiran)

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

14 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 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 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  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  Size oriented software metric dihasilkan melalui normalisasi pengukuran kualitas dan atau pengukuran produktifitas dengan mempertimbangkan “Ukuran” software yang dihasilkan.

19  Gambar : metrik size-oriented

20  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) 1.Error per KLOC (Kilo Lines of Code) 2.Defect per KLOC 3.$ per KLOC 4.page of documentation per KLOC

21  Sebagai tambahan, Metrik lain yang dapat dihitung : 1.Kesalahan/person-month 2.LOC/person-month 3.$/halaman dokumentasi

22 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 Lalu…bagaimana menurut anda?

24 Pasrah…;)

25  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  Function oriented metric menggunakan pengukuran yang dinamakan “Function Point”. Function Point dihitung dengan melengkapi tabel berikut:

27 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  Untuk menghitung function point: FP = jumlah total x [0,65 + 0,01 x  Fi] Fi (i = 1 s/d 14) Merupakan “complexity Adjustment values” berdasarkan respon pada pertanyaan- pertanyaan berikut:

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

30  Rate masing-masing faktor pada skala 0 – 5

31 selesai…


Download ppt "Pertemuan V.  Pendahuluan  4.1. Software Metric  4.2. Size Oriented Metric  4.3. Function Oriented Metric."

Presentasi serupa


Iklan oleh Google