Download - rpl_baru3

MODUL PERKULIAHAN

Rekayasa Perangkat Lunak

Metrik Proyek

Fakultas Ilmu Komputer

Program Studi Teknik Informatika

Tatap Muka Kode MK Disusun Oleh

03Devi Fitrianah

Abstract KompetensiModul ini berisi materi tentang tools atau perangkat yang digunakan dalam mengukur proyek Perangkat Lunak

Mahasiswa mengetahui tools yang digunakan untuk mengukur proyek perangkat lunak dan dapat menentukan tools yang tepat untuk jenis proyek perangkat lunak

Metrik Proyek

Metrik software process digunakan untuk tujuan strategis. Pengukuran proyek perangkat

lunak bersifat taktis, yaitu bahwa metrik proyek dan indikator yang berasal dari pengukuran

digunakan oleh manajer proyek dan tim perangkat lunak untuk mengadaptasi aliran kerja

proyek dan aktivitas teknis.

Aplikasi pertama dari metrik proyek pada sebagian besar proyek perangkat lunak terjadi

selama perkiraan. Metrik yang dikumpulkan dari proyek yang terdahulu digunakan sebagai

dasar yang dari sana perkiraan usaha dan durasi waktu dibuat untuk kerja perangkat lunak

saat ini. Selagi sebuah proyek berjalan, pengukuran usaha dan waktu kalnedar yang

digunakan dibandingkan dengan perkiraan awal (dan jadwal proyek). Manajer proyek

menggunakan data tersebut untuk memonitor dan mengontrol kemajuan.

Pada saat kerja teknis dimulai, metrik proyek akan mulai memiliki arti. Nilai produksi yang

disajikan dalam bentuk halaman dokumentasi, waktu yang diperlukan untuk analisa, function

points, dan jumlah kode program yang disubmit, dan kesalahan yang ditemukan selama

mengerjakan pekerjaan-pekerjaan software engineering. Selagi software berjalan dari

spesifikasi ke perancangan, metrik teknik dikumpulkan untuk memperkirakan kualitas desain

serta memberikan indikator yang akan mempengaruhi pendekatan yang akan diambil untuk

memunculkan kode dan modul serta pengujian integritas.

Metrik proyek mempunyai tujuan ganda :

1. Metrik tersebut digunakan untuk meminimalkan jadwal pengembangan dengan

melakukan penyesuaian yang diperlukan untuk menghindari penundaan serta

mengurangi masalah dan risiko potensial.

2. Metrik proyek dipakai untuk memprkirakan kualitas produk pada basis yang berlaku

dan, bila dibutuhkan, memodifikasi pendakatan teknis untuk meningkatkan kualitas,

2013 2

APLIKOMPusat Bahan Ajar dan eLearning

Devi Fitrianah http://www.mercubuana.ac.id

Pada saat kualitas meningkat, kesalahan menjadi minimal, dan selagi kesalahan semakin

berkurang, jumlah kerja ulang yang dibutuhkan selama proyek berlangsung juga berkurang.

Dengan demikian, pembiayaan proyek secara keseluruhan dapat berkurang.

Model yang lain dari metrik proyek [HET93] mengusulkan bahwa setiap proyek

seharusnya mengukur:

Input (pengukuran sumber daya seperti manusia, lingkungan yang dibutuhkan untuk

melakukan pekerjaan),

Output (pengukuran kemampuan penyampaian atau produk kerja yang diciptakan

selama proses rekayasa perangkat lunak)

Hasil (pengukuran yang menunjukkan efektivitas kemampuan penyampian).

Pada kenyataannya model ini dapat diterapkan, baik pada proses maupun pada proyek.

Dalam konteks proyek, model dapat diterapkan secara rekursif pada saat masing-masing

aktivitas kerangka berjalan, sehingga output dari satu aktivitas menjadi input bagi aktivitas

selanjutnya. Metrik hasil dapat digunakan untuk memberikan indikasi daya kerja selagi

mereka mengalir dari satu aktivitas kerangka kerja (atau tugas) ke aktivitas kerangka kerja

selanjutnya.

2013 3



PENGUKURAN PERANGKAT LUNAK (SOFTWARE MEASUREMENT)

Pengukuran dapat dikategorikan dalam dua cara :

1. pengukuran langsung (contohnya panjang sebuah baut)

2. pengukuran tidak langsung (misal “kualitas” baut yang diproduksi, pengukuran

dengan menghitung penolakan).

Pengukuran langsung dadri proses rekayasa perangkat lunak menyangkut biaya dan usaha

yang dilakukan. Pengukuran langsung dari produk menyangkut deretan kode (LOC) yang

diproduksi, kecepatan eksekusi, ukuran memori, dan defects yang dilaporkan pada sejumlah

periode waktu. Pengukuran tidak langsung dari produk menyangkut fungsionalitas, kualitas,

kompleksitas, efisiensi, reliabilitas, kemampuan pemeliharaan, dan banyak lagi

“kemampuan” lain.

Kita telah membagi domain metrik perangkat lunak ke dalam proses, proyek, dan

metrik produk. Kita juga telah mencatat bahwa metrik produk yang bersifat pribadi bagi

individu sering dikombinasikan untuk mengembangkan metrik proyek yang bersifat umum

bagi sebuah tim perangkat lunak. Metrik proyek kemudian dikonsolidasi untuk menciptakan

metrik proses yang bersifat umum bagi organisasi perangkat lunak sebagai suatu kesatuan.

Tetapi bagaimana sebuah organisasi menggabungkan metrik yang datang dari proyek atau

individu yang berbeda?

Untuk menggambarkannya kita mengandaikan sebuah contoh sederhana. Individu

pada dua tim proyek yang berbeda mencatat dan mengkategorikan semua kesalahan yang

mereka temukan selama proses rekayasa perangkat lunak. Pengukuran individual

dikombinasikan untuk mengembangkan pengukuran tim. Tim A menemukan 342 kesalahan

selama proses perangkat lunak sebelum perangkat lunak itu diserahkan Tim B menemukan

184 kesalahan. Semua hal yang lainnya sama. Tim mana yang lebih efektif dalam

menemukan kesalahan pada seluruh proses? Karena kita tidak tahu ukuran atau

kompleksitas proyek, kita tidak dapat menjawab pertanyaan tersebut. Tetapi bila

pengukuran dinormalisasikan, mungkin akan menciptakan metrik perangkat lunak yang

memungkinkan pembandingan dengan rata-rata organisasional yang lebih besar.

2013 4



1. Size-Oriented Metrics

Metrik perangkat lunak size-oriented (beorientasi pada ukuran) ditarik dengan normalisasi

kualitas dan atau pengukuran produktivitas dengan mempertimbangkan “ukuran” perangkat

lunak yang dihasilkan. Bila sebuah organisasi memelihara rekaman-rekaman sederhana,

sebuah tabel penggukuran size-oriented, seperti yang ditunjukkan pada gamabar 4.4 dapat

diciptakan. Tabel tersebut mencantumkan daftar setiap proyek pengembangan perangkat

lunak yang sudah diselesaikan pada tahun-tahun terakhir dan pengukuran yang sesuai

untuk proyek tersebut. Dengan mengacu pada catatan tabel (Gambar 4.4) utnuk proyek

alpha: 12, 100 baris kode (LOC) dikembangkan dengan 24 person-months dari usaha

dengan biaya $168.000. Perlu dicatat bahwa kerja dan biaya yang direkam dalam tabel

mewakili seluruh aktivitas rekayasa perangkat lunak (analisis, desain, pengkodean, dan

pengujian), tidak hanya pengkodean saja. Informasi lebih jauh untuk proyek alpha

menunjukkan bahwa telah dikembangkan dokumentasi setebal 365 halaman, dicatat 134

kesalahan sebelum perangkat lunak dilepaskan, dan terhitung ada 29 cacat setelah

diserahkan kepada pelanggan pada tahun pertama operasi. Tiga orang telah bekerja pada

pengembangan perangkat lunak proyek alpha.

Proyek LOC Usaha Dolar Halaman Kesalahan Catat Manusia

Alpha 12,100 24 168 365 134 29 3

Beta 27,200 62 440 1224 321 86 5

Gamma 20,200 43 314 1050 256 64 6

Gambar 1 size-oriented Metrics

2013 5



Untuk mengambangkan metrics yang dapat dibandingkan dengan metrics yang sama dari

proyek yang lain, kita memilih sederetan kode sebagai nilai normalisasi. Dari data yang

belum sempurna yang ada pada tabel, dapat dikembangkan serangkaian metrik size-

oriented yang sederhana untuk setiap proyek:

Kesalahan (error) per KLOC (ribuan baris kode)

$ per LOC cacat (defect) per KLOC,

halaman dokunetasi per KLOC

Sebagai tambahan, metrik menarik yang lain dapat dihitung :

Kesalahan / person-month

LOC per person-month

$/halaman dokumentasi

Metrik size-oriented tidak diterima secara universal sebagai cara terbaik untuk mengukur

proses perkembangan perangkat lunak [JON86]. Sebagian besar kontrovesi berkisar di

seputar pemakian baris kode [LOC] sebagai pengukuran kunci. Mereka yang setuju pada

pengukuran LOC mengatakan bahwa LOC merupakan sebuah artifak dari semua proyek

pengembangan perangkat lunak yang dapat dihitung dengan mudah; bahwa banyak model

perkiraan perangkat lunak yang ada menggunakan LOC atau KLOC sebagai input kunci,

dan bahwa sebuah badan literatur yang besar dan data yang didasarkan pada LOC sudah

ada. Tetapi yang tidak setuju mengatakan bahwa pengukuran terhadap LOC tergantung

pada bahasa pemograman; pengukuran LOC tidak mendukung desain yang baik, melainkan

program-program singkat; tidak dapat dengan mudah mengakomodasi bahasa non-

prosedural, dan pemakaiannya dalam estimasi membutuhkan tingakt detail yang mungkin

sulit dicapai (perencanaan harus mengestimasi LOC untuk dibuat jauh sebelum analisis dan

desain dilengkapi).

2013 6



2. Function-Oriented Metrics

Metrik perangkat lunak function-oriented (berorientasi pada fungsi) menggunakan sebuah

pengukuran fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai normalisasi.

Karena fungsionalitas tidak dapat diukur secara langsung, maka fungsionalitas harus ditarik

secara tidak langsung dengan menggunakan penggunakan pengukuran langsung yang

lain. Metrik berorintasi fungsi pertama kali diusulkan oleh Al brecht [ALB79] yang

mengusulkan sebuah pengukuran yang disebut function point. Fungtion point ditarik dengan

menggunakan sebuah hubungan empiris berdasarkan pengukuran (langsung) domain

informasi perangkat lunak yang dapat dihitung sereta perkiraan kompleksitas perangkat

lunak.

Function point dihitung dengan melengkapi tabel yang diperlihatkan pada Gambar 2.

Lima karakteristik domain informasi ditentukan dan penghitungan diberikan di dalam lokasi

tabel yang sesuai. Nilai domain informasi didefinisikan dengan cara sebagai berikut4 :

Parameter

PengukuranJumlah Sederhana Rata-rata Kompleks

Faktor

pembobotan

Jumlah input

pemakaiX 3 4 6

Jumlah output

pemakaiX 4 5 7

Jumlah

penyelidikan

pemakai

X 3 4 6

Jumlah fileX 7 10 15

Jumlah

interface

internal

X 6 7 10

Total

Gambar 2 Penghitungan metrik function point.

2013 7



Jumlah input. Setiap input pemakai yang memberikan data yang berorientasi pada

aplikasi yang jelas pada perangkat lunak dihitung. Input ini harus dibedakan dari

penelitian yang dihitung secara terpisah.

Jumlah output pemakai. Setiap output pemakai yang memberikan informasi yang

berorientasi pada aplikasi kepada pemakai dihitung. Pada konteks ini output

mengacu pada laporan, layar, tampilan kesalahan, dan sebagainya. Jenis data

individual pada sebuah laporan tidak dkhitung secara terpisah.

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. Setiap penyelidikan yang jelas dihitung.

Jumlah file. Setiap file master logika (yaitu pengelompokan data secara logis yang

menajdi suatu bagian dari sebuah database yang besar atau sebuah file yang

terpisah) dihitung.

Jumlah interface eksternal. Semua interface yang dapat dibaca oleh mesin

(contohnya, file data pada pita atau disket) yang digunakan untuk memindahkan

informasi ke sistem yang lain dihitung.

Sekali data tersebut dikumpulkan, maka sebuah nilai kompleksitas akan

dihubungkan dengan masing-masing penghitungan. Organisasi yang menggunakan metode

titik fungsi mengembangkan kriteria untuk menetukan apakah sebuah entri tertentu bersifat

sederhana, rata-rata, atau kompleks. Meskipun demikian perkiraan kompleksitas tetap

bersifat subyektif.

Untuk menghitung function point (FP) dipakai hubungan sebagai berikut :

2013 8



FP = jumlah total x [0,65 + 0,01 x {Fi] ………………………………………….…(3.1)

di mana jumlah total adalah jumlah semua entri yang diperoleh dari Gambar 2

Fi (I = 1 sampai 14) adalah “harga penyesuaian kompleksitas” berdasarkan respon

pada pernyataan [ART85] yang ditulis pada Tabel 1. nilai konstanta pada persamaan dan

faktor pembobotan yang diaplikasikan pada hitungan domain informasi ditentukan secara

empiris.

Tabel 1 Menghitung function points

Rata-rata setiap faktor pada skala 0 sampai 5

0 1 2 3 4 5

Tidak

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 membutuhkan entry data online?

7. Apakah entry data online membutuhkan ada transaksi input terhadap layar atau

operasi ganda?

8. Apakah file master diperbarui secara online?

2013 9



Tidak berpengaruh

Berpengaruh

Insidental

ModeratSignifikan

Esesnsial

9. Apakah input, output, file, atau inquiri kompleks?

10. Apakah pemrosesan internal kompleks?

11. Apakah kode didesain untuk dapat dipakai kembali?

12. Apakah desain melibatkan konversi dan instalasi?

13. Apakah sistem didesain untuk instalasi ganda dalam organisasi berbeda?

14. Apakah aplikasi didesain untuk memfasilitasi perubahan dan mempermudah

pemakai untuk menggunakannya?

Sekali function point telah dihitung, maka titik-titik itu digunakan dengan cara analog

dengan LOC untuk menormalisasi pengukuran produktivitas, kualitas perangkat lunak, serta

atribut-atribut yang lain :

kesalahan per FP

cacat per FP

$ per FP

halaman dokumentasi per FP

FP per person-month

3. Metrik Function Point yang Diperluas

Metrik function secara orisinil dirancang untuk diterapkan pada aplikasi informasi bisnis (nilai

domain informasi telah dijelaskan) yang ditekankan pada pengeluaran dimensi (kontrol)

tingkah laku dan fungsional. Karena alasan tersebut, maka pengukuran function point tidak

sesuai untuk beberapa sistem terapan dan rekayasa (yang menekankan pada fungsi dan

kontrol). Sejumlah ekstensi pada pengukuran function point dasar telah diusulkan untuk

mengatasi situasi ini.

2013 10



Ekstensi function point yang disebut feature points [JON9] merupakan superset dari

pengukuran function point yang dapat diterapkan pada aplikasi perangkat lunak rekayasa

dan sistem. Pengukuran feature point mengakomodasi aplikasi yang kompleksitas

algoritmanya tinggi. Real-time, kontrol proses, dan aplikasi perangkat lunak embedded,

cenderung memiliki kompleksitas algoritma yang tinggi sehingga dapat

dipertanggungjawabkan untuk feature point.

Untuk menghitung feature point, harga domain informasi harus dihitung lagi dan

dibobot seperti dijelaskan pada Subbab 2. sebagai tambahan, metrik feature point juga

menghitung karakteristik perangkat lunak yang baru, yaitu algoritma. Algoritma didefinisikan

sebagai “masalah perhitungan yang terbatas yang dilakukan dalam sebuah program

komputer yang spesifik” [JON9]. Inversi matriks, pendekodean sebuah bit string, atau

penanganan interupsi, merupakan contoh algoritma.

Ekstensi function point untuk sistem real-time dan produk rekayasa telah

dikembangkan oleh Boeing. Pendekatan Boeing mengintegritas dimensi data perangkat

lunak dengan dimensi kontrol dan fungsional untuk memberikan sebuah pengukuran yang

berorientasi pada fungsi, yang disebut 3D Function Point [WH195], yang dapat

dipertanggungjawabkan untuk aplikasi yang menekankan kemampuan fungsi dan kontrol.

Karakteristik dari semyua dimensi perangkat lunak “dihitung, dikuantitasi, dan

ditransformasi” ke dalam sebuah pengukuran yang memberikan indikasi fungsional yang

disampaikan oleh perangkat lunak.

Dimensi data dievaluasi dengan cara yang sama seperti dijelaskan. Penghitungan

data yang disimpan (struktur data program internal, seperti file) dan data eksternal (input,

output, inquiry, dan referensi eksternal) dipakai bersama dengan pengukuran kompleksitas

untuk menarik penghitungan dimensi data.

Dimensi fungsional diukur dengan mempertimbangkan “jumlah operasi internal yang

dibutuhkan untuk mentransformasikan input ke data ouput” [WHI95]. Karena tujuan

komputasi adalah function point 3D, maka suatu “transformasi” dipandang sebagai sebuah

deretan langkah pemrosesan yang dibatasi oleh sejumlah pernyataan semantik. Sebagai

aturan umum, transformasi dilakukan dengan sebuah algoritma yang menghasilkan suatu

perubahan dasar ke data input ketika dia diproses untuk menjadi data output. Langkah

2013 11



pemrosesan yang membutuhkan data dari sebuah file dan secara sederhana menempatkan

data tersebut ke dalam memori program, tidak akan dipertimbangkan sebagai sebuah

transformasi. Data itu sendiri tidak diubah dengan cara yang mendasar.

Tingkat kompleksitas yang diberikan pada masing-masing transformasi merupakan

fungsi dari sejumlah langkah proses dan sejumlah pernyataan semantik yang mengontrol

langkah pemrosesan. Gambar 3 memberikan tuntutan bagi kompleksitas penugasan dalam

dimensi fungsional.

Pernyataan

Semantik

Langkah-

Langkah

Pemrosesan

1 -5 6 –10 11+

1 –10 Rendah Rendah Rata-rata

11 – 20 Rendah Rata-rata Tinggi

21+ Rata-rata Tinggi Tinggi

Gambar 3 Menentukan kompleksitas untuk function point 3D [WH195]

Dimensi kontrol diukur dengan menghitung jumlah transisi antar pernyataan5 . Pernyataan

mewakili beberapa mode tingkah laku yang dapat diobservasi secara eksternal. Transisi

terjadi sebagai hasil dari kejadian yang menyebabkan perangkat lunak atau sistem

mengubah mode tingkah lakunya (yakni untuk mengubah pernyataan). Contohnya, telepon

seluler berisi perangkat lunak yang mendukung fungsi-fungsi auto dial. Untuk memasuki

keadaan autodial dari keadaan resting, pemakai menekan kunci Auto pada key pad. Ini

menyebabkan LCD menandai sebuah kode yang akan menunjukkan bagian yang dipanggil.

Pada pemasukan kode dan penekanan kunci Dial (event lainnya) perangkat lunak telepon

2013 12



seluler membuat sebuah transisi untuk keadaan dialing. Pada saat menghitung function

point 3D, transisi tidak menunjukkan kompleksitas nilai.

Untuk menghitung function point 3D, digunakan hubungan sebagai berikut :

Indeks = I + 0 +Q + F + E + T + R ………………………………………………….(3.2)

di mana I, 0, Q, E, F, T dan R mewakili nilai bobot kompleksitas untuk elemen-elemen yang

telah disebutkan: input, ouput, inquiry, struktur data eksternal, file eksternal, transformasi,

dan transisi secara berurutan. Masing-masing nilai bobot kompleksitas dihitung dengan

menggunakan hubungan sebagai berikut :

nilai bobot kompleksitas = NilWil + NiaWia + NihWih ……………………………...(3.3)

Di mana Nil, Nia dan Nih adalah jumlah kejadian elemen i (contohnya, ouput) untuk masing

tingkat kompleksitas (rendah, rata-rata, tinggi), dan Wil, Wia,Wih merupakan bobot masing-

masing. Perhitungan keseluruhan untuk function point 3D diperlihatkan pada Gambar 4

Perlu diperhatikan bahwa function point, feature point, dan function point 3D

menunjukkan hal yang sama – “fungsionalitas” atau ‘utility’ yang dikirimkan oleh perangkat

lunak. Pada dasarnya, masing-masing pengukuran menghasilkan nilai yang sama hanya jika

dimensi data dari sebuah aplikasi dipertimbangkan. Untuk sistem real-time yang lebih

kompleks, jumlah fetaure point sering antara 20 dan 35 persen lebih tinggi daripada jumlah

yang ditentukan dengan hanya menggunakan function point.

Function point (dan perluasannya), seperti pengukuran LOC, adalah hal yang

kontroversial. Para pendukung mengklaim bahwa FP adalah bahasa pemograman

independen, sehingga ia ideal untuk aplikasi yang menggunakan bahasa konvensional dan

non-prosedural, dan karena didasarkan pada data yang kemungkinan besar dikenal lebih

2013 13



dini dalam evolusi sebuah proyek, membuat FP menjadi lebih menarik sebagai suatu

pendekatan estimasi. Mereka yang menentang menyatakan bahwa metode membutuhkan

beberapa “sulapan” dalam komputasi yang didasarkan pada data yang subyektif daripada

obyektif; jumlah domain informasi (dan dimensi lain) dapat sulit dikumpulkan setelah itu; dan

bahwa FP tidak mempunyai makna fisik – FP hanya sebuah angka.

Kompleksitas Pembobotan

Elemen pengukuran Rendah Sedang Tinggi

Struktur data internal

Data eksternal

Jumlah input pemakai

Jumlah output pemakai

Jumlah penyelidikan

pemakai

Transformasi

Transisi

Indeks function point 3D

x 7 +

x 5 +

x 3 +

x 4 +

x 3 +

x 7 +

x n/a +

x 10 +

x 7 +

x 4 +

x 5 +

x 4 +

x 10 +

x n/a +

x 15 +

x 10 +

x 6 +

x 7 +

x 6 +

x 15 +

x n/a +

Gambar 4 Menghitung Indeks Function Point 3D

Daftar Pustaka1. Pressman, Roger S. Software Engineering: A Practitioner’s Approach, 6th edition.

2013 14

