Proses Perangkat Lunak dan Metrik Proyek Dr. M. Sarosa, Dipl. Ing. MT.
[email protected]
Pendahuluan Lord Kelvin: “Bila anda dapat mengukur apa yang sedang anda bicarakan dan mengekspresikannya dalam angka berarti anda memahaminya, tetapi bila anda tidak dapat mengukur, tidak dapat mengekspresikannya dalam angka, hal ini berarti pengetahuan anda tidak lengkap dan tidak memuaskan, mungkin ini merupakan awal dari pengetahuan tetapi hanya di dalam pikiran anda, dan anda hampir maju ke arah ilmu pengetahuan.”
2
1. Pengukuran, metrik dan Indikator Measure (mengukur), mengindikasikan kuantitatif dari luasan, jumlah, dimensi, kapasitas ukuran dari atribut sebuah proses atau produk. Measurement (pengukuran), kegiatan menentukan sebuah measure Metrik (IEEE), ukuran kuantitatif dari tingkat dimana sebuah sistem, komponen atau proses memiliki atribut tertentu. Indikator, sebuah metrik atau kombinasi dari metrik yang memberikan pengetahuan ke dalam proses perangkat lunak, proyek perangkat lunak atau produk itu sendiri 3
2. Metrik dalam proses dan domain proyek Indikator proses, memungkinkan sebuah organisasi rekayasa perangkat lunak memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung (misalnya paradigma, tuas-tugas rekayasa perangkat lunak, produk kerja, dan kejadian penting) Indikator proyek, memungkinkan manajer proyek melakukan: memperkirakan status proyek yang sedang berlangsung, menelusuri resiko yang potensial, Menyesuaikan aliran kerja atau tugas Mengevaluasi kemampuan tim proyek mengontrol kualitas hasil kerja rekyasa perangkat lunak
4
a. Metrik proses dan peningkatan perangkat lunak Meningkatkan proses adalah mengukur atribut tertentu dari proses, mengembangkan serangkaian metrik berdasarkan atribut tersebut, kemudian menggunakan metrik tersebut untuk indikator yang akan membawa kepada sebuah strategi pengembangan. Proses merupakan salah satu faktor yang dapat dikontrol dalam mengembangkan kualitas perangkat lunak serta unjuk kerja organisasional. 5
Determinan untuk kualitas dan efektifitas organisasional perangkat lunak
6
Determinan untuk kualitas …. (Lanjutan 1)
Proses berada ditengah-tengah segitiga yang menghubungkan 3 faktor yang mempengaruhi kualitas perangkat lunak dan unjuk kerja organisasional Ketrampilan dan motivasi (manusia) menjadi faktor yang mempengaruhi unjuk kerja tim Metode rekayasa perangkat lunak (teknologi) juga mempengaruhi proses. Lingkaran menggambarkan lingkungan pengembangan (alat-alat bantu), kondisi bisnis (batas waktu, aturan bisnis) , karakteristik pelanggan (lancarnya komunikasi) 7
Contoh metrik yang bersifat pribadi terhadap individu Nilai cacat oleh individu Nilai cacat oleh modul Kesalahan yang ditemukan selama pengembangan
8
Proses Perangkat lunak Personal Humrey: “Proses perangkat lunak presonal (PSP) merupakan serangkaian deskripsi proses pengukuran dan metode yang terstruktur, yang dapat membantu perekayasa untuk mengembangkan unjuk kerja personal mereka. PSP memperlihatkan bagaimana mendefinisikan proses, bagaimana mengukur kualitas dan produktivitas. PSP membantu perekayasa untuk mengukur dan menelusuri kerja merea sendiri sehingga mereka mendapatkan bahwa metoda tersebut merupakan yang terbaik untuk mereka.” 9
Analisis kegagalan bekerja Semua kesalahan dan cacat dikategorikan dari awal (contoh kekurangan dalam spesifikasi, logika, ketidaksesuaian dengan standar) Biaya untuk mengoreksi setiap kesalahan dan cacat dicatat Jumlah kesalahan dan cacat dari setiap kategori dihitung dan ditata dalam urutan naik Biaya keseluruhan dari kesalahan dan cacat dalam setiap kategori dihitung Data resultan dianalisis untuk menemukan kategori yang menelan biaya besar Rencana dikembangkan untuk memodifikasi proses guna mengeliminasi (mengurangi frekuensi kejadian) kelas kesalahan dan cacat yang paling membutuhkan banya biaya. 10
Penyebab dan asal cacat pada proyek perangkat lunak
8 penyebab kerusakan dan sumbernya (ditunjukkan dengan arsiran)
11
Diagram fishbone memperlihatkan penyebab kelas cacat
12
Diagram fishbone …. (lanjutan 1)
Punggung diagram (garis pusat) merepresentasi faktor kualitas yang sedang dipertimbangkkan (cacat=25% jumlah total) Rusuk (garis diagonal) penyebab potensial masalah kualitas (syarat yang hilang, spesifikasi ambiguitas, syarat yang tidak tepat, syarat yang diubah). Notasi punggung dan rusuk kemudian ditambahkan ke masing-masing rusuk utama dari diagram untuk memperluas penyebab yang dicatat 13
b. Matrik proyek Matrik proses untuk tujuan strategis, matrik proyek perangkat lunak bersifat taktis (matrik proyek dan indikator berasal dari pengukuran digunakan untuk mengadaptasi aliran kerja proyek dan aktivitas teknik) Tujuan matrik proyek: Untuk meminimalkan jadwal pengembangan dengan penyesuaian yang diperlukan, untuk menghindari penundaan serta masalah dan resiko potensial Untuk memperkirakan kulitas produk pada basis yang berlaku dan bila dibutuhkan, memodifikasi pendekatan teknis untuk meningkatkan kualitas
14
Model lain matrik proyek Setiap proyek seharusnya mengukur: Input (pengukuran sumber daya seperti manusia, lingkungan yang dibutuhkan untuk melaksanakan pekerjaan) Output (pengukuran kemampuan penyampaian atau produk kerja yang diciptakan selama proses rekayasa perangkat lunak) Hasil (pengukuran yang menunjukkan efektifitas kemampuan penyampaian) 15
3. Pengukuran perangkat lunak Pengukuran langsung dari proses rekayasa perangkat lunak biaya dan usaha yang diaplikasikan. dari produk deretan kode (LOC) yang diproduksi, kecepatan eksekusi, ukuran memori, cacat yang dilaporkan pada sejumlah periode waktu
Pengukuran tidak langsung Dari produk fungsionalitas, kualitas, kompleksitas, efisiensi, reliabilitas, kemampuan pemeliharaan
16
a. Metrik size oriented
Contoh tabel pengukuran berorientasi ukuran, berisi daftar setiap proyek yang telah diselesaikan dr tahun ke tahun dan pengukuran yang berhasil dilakukan 17
Pengembangan metrik size-oriented Data yang belum sempurna yang ada pada tabel dapat dikembangkan untuk setiap proyeknya, Kesalahan (error) per KLOC (ribuan baris kode) $ perLOC cacat (defect) per KLOC Halaman dokumentasi per KLOC
Metrik yang dapat dihitung: Kesalahan /person-month LOC/person-month $/halaman dokumentasi
18
b. Metrik Function-Oriented
Menggunakan sebuah pengukuran fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai normalisasi. 19
Metrik Function-Oriented (lanjutan 1)
Jumlah input pemakai, setiap input pemakai yang memberikan data yang berorientasi pada aplikasi yang jelas pada perangkat lunak dihitung Jumlah output pemakai, setiap output yang memberikan informasi yang beorientasi pada aplikasi kepada pemakai dihitung. Pada konteks ini output mengacu pada laporan, layar, tampilan. Jumlah penyelidikan pemakai, sebuah penyelidikan didefinisikan sebagai input on-line yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk sebuah output on-line. Jumlah file, setiap file master logika (yaitu pengelompokkan data secara logis yang menjadi suatu bagian dari sebuah database yang besar atau sebuah file yang terpisah) dihitung. Jumlah interface eksternal, semua interface yang dapat dibaca oleh mesin yang digunakan untuk memindahkan informasi ke sistem yang lain dihitung. 20
Menghitung titik-titik fungsi Untuk menghitung titik-titik fungsi (FP) dipakai hubungan : FP=jumlah total x (0,65 + 0,01 x Fi) Dengan jumlah total adalah jumlah semua entri yang diperoleh Fi (i=1 s.d. 14) harga penyesuaian kompleksitas berdasarkan pada pertanyaan yang ditulis pada tabel berikut: 21
Tabel menghitung function point
1. Apakah sistem membutuhkan backup dan recovery yang reliabel ? 2. Apakah komunikasi data dibutuhkan ? 3. Apakah fungsi pemrosesan didistribusikan ? 4. Apakah kinerja penting ? 5. Apakah sistem akan berjalan pada lingkungan operasional yang sudah ada yang paling banyak digunakan ? 6. Apakah sistem mebutuhkan entri data online ? 22
Tabel menghitung function point (lanjutan 1)
1. Apakah entri data online membutuhkan adanya
transaksi input terhadap layar ? 2. Apakah file master diperbaharui secara online ? 3. Apakah input, output, file atau inquiri kompleks ? 4. Apakah pemrosesan internal kompleks ? 5. Apakah kode didesain untuk dapat dipakai kembali ? 6. Apakah kode didesain untuk dapat dipakai kembali ? 7. apakah sistem didesain untuk instalasi ganda dalam
organisasi berbeda? 8. Apakah aplikasi didesain untuk memfasilitasi perubahan
dan mempermudah pemakai untuk menggunakannya? 23
Sekali function point telah dihitung, maka titiktitik itu digunakan dengan cara analog dengan LOC untuk menormalisasi pengukuran produktifitas, kualitas perangkat lunak, serta atribut-atribut yang lain: Kesalahan per FP Cacat per FP $ per FP Halaman dokumentasi per FP FP per person-month
Metrik untuk kualitas perangkat lunak Kualitas sistem, aplikasi, atau produk merupakan persyaratan yang menjelaskan masalah, desain model solusi, kode yang membuat program dapat dieksekusi, dan pengujian yang menguji perangkat lunak untuk menemukan kesalahan. Pengukuran ditujukan untuk menilai kualitas model analisis dan desain, kode sumber, dan test case yang dibuat ketika perangkat lunak direkayasa. Tujuan utama pengukuran kualitas adalah untuk mencari kesalahan dan cacat.