Anda di halaman 1dari 14

MODUL PERKULIAHAN

Rekayasa Perangkat Lunak


Metrik Proyek

Fakultas Ilmu Komputer

Program Studi Teknik Informatika

Tatap Muka

Kode MK

Disusun Oleh
Devi Fitrianah

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

Kompetensi
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

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning 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

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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 Beta Gamma

12,100 27,200 20,200

24 62 43

168 440 314

365 1224 1050

134 321 256

29 86 64

3 5 6

Gambar 1 size-oriented Metrics

2013

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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 sizeoriented 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 nonprosedural, dan pemakaiannya dalam estimasi membutuhkan tingakt detail yang mungkin sulit dicapai (perencanaan harus mengestimasi LOC untuk dibuat jauh sebelum analisis dan desain dilengkapi).

2013

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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 Pengukuran Jumlah input pemakai Jumlah output pemakai Jumlah penyelidikan pemakai Jumlah file

Jumlah

Sederhana

Rata-rata

Kompleks

Faktor pembobotan

X3

X4

X3

X7

10

15

Jumlah interface internal Total Gambar 2 Penghitungan metrik function point. X6 7 10

2013

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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 online 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

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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

Tidak berpengaruh

Insidental Signifikan Moderat

Berpengaruh

Esesnsial

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

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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 Langkah1 -5 Langkah Pemrosesan 6 10 11+

1 10 11 20 21+

Rendah Rendah Rata-rata

Rendah Rata-rata Tinggi

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

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

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 Struktur data internal Data eksternal Jumlah input pemakai Jumlah output pemakai Jumlah pemakai Transformasi Transisi Indeks function point 3D penyelidikan

Rendah x 7 + x 5 + x 3 + x 4 + x 3 + x 7 + x n/a +

Sedang x 10 + x x x x 7 + 4 + 5 + 4 +

Tinggi x 15 + x 10 + x x x 6 + 7 + 6 +

x 10 + x n/a +

x 15 + x n/a +

Gambar 4 Menghitung Indeks Function Point 3D

Daftar Pustaka
1. Pressman, Roger S. Software Engineering: A Practitioners Approach, 6th edition.

2013

14

APLIKOM Devi Fitrianah

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id