November 26, 2008

PENGUKURAN METRIK


1. PENGUKURAN, METRIK, DAN INDIKATOR

Dalam konteks rekayasa perangkat lunak, mengukur (measure) mengindikasikan kuantitatif dari ukuran atribut sebuah proses atau produk. Pengukuran (measurement) adalah kegiatan menentukan sebuah measure (pengukuran). Dan definisi metriks menurut IEEE adalah “ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu”.

Pengukuran telah ada jika suatu data-data tunggal telah dikumpulkan (misal: jumlah kesalahan yang ditemukan pada kajian sebuah modul tunggal). Metrik perangkat lunak menghubungkan pengukuran-pengukuran individu dengan banyak cara, misal rata-rata dari jumlah kesalahan yang ditemukan pada setiap kajian.

Rekayasa perangkat lunak mengumpulkan pengukuran dan mengembangkan metrik menjadi sebuah indikator, yaitu sebuah metrik atau kombinasi metrik yang memberikan pengetahuan dalam proses perangkat lunak, sebuah proyek perangkat lunak, atau produk itu sendiri. Fungsinya adalah memberi pengetahuan pada manajer proyek atau perekayasa perangkat lunak untuk menyesuaikan proses, proyek, dan produk agar menjadi lebih baik.

2. PENGUKURAN PERANGKAT LUNAK

Pengukuran langsung dari produk berkaitan dengan deretan kode, kecepatan eksekusi, ukuran memori, dan cacat yang dilaporkan pada suatu periode tertentu. Sedangkan pengukuran tidak langsung dari produk adalah tentang fungsionalitas, kualitas, kompleksitas, efisiensi, realibilitas, kemampuan pemeliharaan, dsb.Dalam kenyataannya, pengukuran perangkat lunak secara objektif akan sulit dilakukan secara langsung karena ada pengaruh-pengaruh seperti individu dalam tim pengukuran, atau tingkat kompleksitas proyek.
Tetapi jika pengukuran dinormalisasi, maka mungkin akan dapat didapatkan metrik perangkat lunak yang memungkinkan perbandingan dengan rata-rata organisas
ional yang lebih besar.

2.1 METRIK SIZE ORIENTED

Parameternya adalah ”ukuran” dari software yang dihasilkan. Dapat dilakukan jika ada record atau catatan dari organisasi. Perlu diperhatikan bahwa yang record yang diperlukan adalah keseluruhan aktivitas rekayasa perangkat lunak. Misalnya tabel dibawah ini adalah pengumpulan dari data-data record yang ada dari sebuah organisasi:

Dimana LOC (line of code) menunjukkan jumlah baris kode yang dibuat pada masing-masing proyek, misalnya pada kolom pertama, proyek aplha dibuat dengan 12100 baris kode dalam 365 halaman, dikembangakan dengan usaha 24 orang per bulan dengan biaya $168000. Lalu ditemukan kesalahan sebanyak 134 pada proyek sebelum direlease, 29 cacat setelah direlease pada pelanggan, dan ada 3 orang yang bekerja pada pengembangan proyek perangkat lunak alpha.

Untuk pengembangan dari metrik ini, dapat dibuat metrik size oriented baru yang sederhana untuk tiap proyek, misal: kesalahan per baris kode (dihitung ribuan), cacat per baris kode (ribuan), dokumentasi per baris kode (ribuan), kesalahan per usaha, baris kode per usaha, biaya per halaman dokumentasi, dsb.

Metrik ini tidak dapat diterima secara universal karena adanya kontroversi pada penggunaan baris kode sebagai titik ukur. Sebagian yang setuju pada pengukuran LOC menganggap bahwa LOC adalah suatu bukti real dari apa yang dilakukan oleh perekayasa perangkat lunak (dalam konteks ini membuktikan berapa banyak baris program yang ditulis oleh seorang programmer – comment yang ada).

Sedangkan sebagian yang tidak setuju bahwa LOC dijadikan suatu tolak ukur kebanyakan disebabkan alasan ambiguitas dari cara menghitung LOC itu sendiri. Dalam masa-masa awal bahasa pemrograman Assembly, hal ini tidak menjadi suatu masalah karena dalam 1 baris aktual program merupakan 1 baris instruksi, tetapi dalam bahasa pemrograman tingkat tinggi, dimana pada masing-masing bahasa, untuk menyelesaikan suatu masalah dengan algoritma yang sama pun LOC nya sudah berbeda-beda. Bahkan dalam satu bahasa pemrograman yang sama, untuk menyelesaikan masalah yang sama, LOC nya bisa berbeda jauh tergantung dari algoritma yang digunakan. Hal ini yang membuat banyak sekali kontroversi mengenai LOC sebagai tolak ukur dari sebuah software.

2.2 METRIK FUNCTION ORIENTED

Normalisasi dilakukan pada fungsionalitas pada aplikasi, tetapi untuk melakukan hal ini, fungsionalitas harus diukur dengan pengukuran langsung yang lain karena fungsionalitas tidak dapat diukur secara langsung. Maka pengukuran dapat dilakukan dengan pengukuran function point. Function point didapat dari penarikan hubungan empiris berdasarkan pengukuran domain informasi software dan perkiraan kompleksitas software.

Domain informasi yang biasa digunakan ada 5 karakteristik, yaitu:

· jumlah input pemakai: setiap input pemakai yang memberikan data yang berorientasi pada aplikasi yang jelas pada perangkat lunak (harus dibedakan dari penelitian yang dihitung secara terpisah) misal: tipe transaksi.

· jumlah output pemakai: setiap output pemakai yang memberikan informasi yang berorientasi pada aplikasi kepada pemakai. Pada konteks ini output mengacu pada laporan, layar, tampilan kesalahan, dsb. Jenis data individual pada laporan tidak dihitung terpisah. misal: report type.

· jumlah penyelidikan pemakai: input online yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk output online.

· jumlah file: setiap master logika (pengelompokan data logis yang menjadi suatu bagian dari sebuah database yang besar atau sebuah file terpisah).

· jumlah interface eksternal: semua interface yang dapat dibaca oleh mesin yang digunakan untuk memindahkan informasi ke sistem yang lain

Sekali data telah dikumpulkan, maka nilai kompleksitas dihubungkan dengan masing-masing penghitungan dengan tabel perhitungan sebagai berikut:
Faktorpembobotan

Dalam hal ini faktor pembobotan setiap faktor sudah menjadi standar dan tidak dapat diubah-ubah, tetapi dalam penentuan kriteria suatu perangkat lunak pada salah satu parameter pengukuran adalah sederhana, rata-rata atau kompleks ditentukan oleh organisasi atau perekeyasa perangkat lunak yang melakukan penghitungan itu sendiri. Tetapi meskipun begitu perkiraan kompleksitas tetap bersifat subyektif.

Untuk menghitung function point (FP) dapat digunakan hubungan sbb:
FP = jumlah total x [0,65 + 0,01 x Fi]
dimana jumlah total adalah nilai yang kita dapatkan pada tabel perhitungan di atas.

Sedangkan Fi dapat dihitung dari perhitungan sebagai berikut:
Pertama-tama kita diberi 14 buah karakteristik dari suatu perangkat sebagai berikut:
1. Data communications
2. Distributed functions
3. Performance
4. Heavily used configuration
5. Transaction rate
6. Online data entry
7. End-user efficiency
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitation of change
Pada setiap karakteristik tersebut diberi bobot dari nilai 0 sampai 5 dengan asumsi nilai sebagai berikut:
0. Tidak berpengaruh
1. Insidental
2. Moderat
3. Rata-rata
4. Signifikan
5. Essential

Setelah setiap karakteristik diberi bobot masing-masing, lalu bobot-bobot dari setiap karakteristik ini dijumlahkan (jadi minimum 0 dan maksimal 70) dan kita akan mendapatkan nilai Fi. Setelah mendapatkan nilai Fi maka kita bisa menghitung nilai FP dengan rumus di yang sudah ada di atas. Setelah kita mendapatkan nilai FP, maka kita dapat menggunakannya dengan cara analog dengan LOC untuk menormalisasi pengukuran produktivitas, kualitas perangkat lunak, serta atribut-atribut yang lain seperti:

· kesalahan per FP

· cacat per FP

· $ per FP

· halaman dokumentasi per FP

· FP per person-month

· dsb
(dimana untuk mendapatkan data-data untuk kesalahan, cacat, dolar, dsb dapat diambil dari data-data pada tabel record pada metrik size-oriented).

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!

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: 168000
$ per FP = 168000 / 910,47 = $184,52

Hasil dari contoh kasus diatas masih berupa suatu angka mentah, untuk dapat dilihat apakah angka ini termasuk baik atau tidak harus diperbandingkan dengan perhitungan lain, misalnya $ per FP dari proyek beta atau gamma, atau proyek dari organisasi lain.

Oleh Nathanael Sandy Ardianto (22064126)

Referensi : http://rpl07.wordpress.com/Pengukuran Perangkat Lunak Menggunakan Metrik Size-Oriented dan Metrik Function Oriented, oleh Arif M [5105 100 139]

November 24, 2008

Proyek protype SIMANCA

METRIC PADA PERANGKST LUNAK

Proyek protype SIMANCA

 

Metric dalam Proses dan Proyek

Indikator proses digunakan oleh organisasi atau perusahaan yang bergerak dalam bidang rekayasa perangkat lunak untuk memperoleh data-data yang dapat digunakan untuk meningkatkan efisiensi dalam proses pengembangan perangkat lunak atau untuk prediksi dari biaya produksi sebuah software. Dengan metric, maka client (pemesan software) dan tim pengembang dapat beradaptasi dengan alur kerja dan aktifitas-aktifitas yang bersifat teknis. Metrik -metric yang dikumpulkan dari proyek-proyek di masa lalu digunakan sebagai acuan untuk melakukan estimasi pada proyek yang sedang dikerjakan. Manajer proyek menggunakan data tersebut untuk melakukan pengawasan dan kendali proyek.

Selainitu metric juga dapat diperoleh dengan cara normalisasi ukuran kualitas dan produktivitas dengan menghitung ukuran dari software yang dibuat. Dengan cara ini fungsionalitas program dapat dicapai dengan baris program (LOC) yang lebih sedikit. Funsionalitas tadi  digunakan sebagai masukan yang biasa disebut dengan Function point (FP).

Setelah kita mempunyai data-data maka kita dapat melakukan estimasi. Dalam hal ini estimasi dilakukan dengan berbasis masalah. Perencanaan proyek dimulai dengan kumpulan pernyataan yang berisi kerangka dan batas-batas dari perangkat lunak dan dari pernyataan-pernyataan tersebut kemudian dicoba untuk melalukan dekomposisi software kedalam Problem Function dan melakukan estimasi variable-variabel (LOC dan FP) pada tiap fungsi permasalahan.

Estimasi juga bisa kita lakukan dengan Model Estimasi Empiris. Dalam Estimasi Empiris, formula yang diperoleh secara empiris untuk memperkirakan tenaga sebagai sebuah fungsi dari LOC dan FP.

IMPLEMENTASI

Pembuatan Prototype SIMANCA

1.      Pengamatan dilakukan dengan menghitung jumlah hari dan jam yang diperlukan berdasarkan table absensi.

2.      Sumber daya manusia yang terlibat dalam pengembangan prototype SIMANCA berjumlah 4 orang. Dengan pembagian Komposisi analis system atau basis data = 1 orang dan Programer = 3 orang.

Tebel Absensi

Orang

Jumlah Hari

Jumlah Jam

A

18

79

B

18

81

C

16

76

D

17

83

Total orang – jam

319

 

Hasil Estimasi dengan berbagai model

Model

Estimasi EOJ

Estimasi Berbasis LOC

Analisis LOC umum

630,92

Model Waltson-Felix

1891,32

Model Bailey-Basili

1278,79

Model Sederhana Boehm

1304,47

Model COCOMO

1294,69

Estimasi berbasis FP

Model Albert dan Gaffney

2358,99

Model Kemerer

98730,44

Model Matson,Bernett, dan Mellichamp

1399864,94

Estimasi berbasis proses

Estimasi berbasis proses

649,9

 

Dari table diatas dapat kita lihat bahwa tiap model memiliki hasil yang berbeda dengan LOC dan FP yang berbeda. Apabila data dari hasil estimasi dibandingkan dengan hasil pengamatan pada proyek, maka diperoleh selisih, dimana hasil estimasi tenaga lebih besar dari kenyataan yang terjadi di lapangan. Pada proyek SIMANCA jumlah waktu pengerjaan sistem dapat menjadi lebih kecil dari estimasi.

Estimasi perangkat lunak digunakan untuk melakukan perkiraan terhadap sumber daya dan biaya yang diperlukan untuk menyelesaikan suatu proyek pengembangan perangkat lunak.

 

Referensi

IMPLEMENTASI METRIK PADA PENGEMBANGAN PERANGKAT LUNAK. Makalah_Skripsi_Wahyu.pdf


Oleh : yudhistira anggi p. [22 06 4095]

November 15, 2008

Metrics for Web Engineering Effort

Rekayasa Web mencurahkan upaya manusia untuk melakukan berbagai tugas sebagai pengembang Aplikasi web . Mendes dan koleganya menyarankan beberapa kemungkinan langkah-langkah pengukuran untuk aplikasi web. Beberapa atau keseluruhan ini dapat dicatat oleh tim rekayasa web dan digunakan untuk membangun sebuah historical database untuk estimasi.

Pembuatan aplikasi dan perancangan

Ukuran yang diusulkan Uraian

Structuring effort : Waktu untuk membuat aplikasi web dan atau memperoleh arsitektur

Interlinking effort : Waktu menghubungkan halaman untuk membagun struktur aplikasi web

Interface planning: Waktu yang digunakan untuk merancang antarmuka aplikasi web

Interface building: Waktu yang digunakan untuk mengimplementasi antarmuka aplikasi web

Link-testing effort: Waktu yang digunakan untuk menguji link pada aplikasi web

Media-tesing effort: Waktu yang digunakan untuk menguji semua media di aplikasi web


Total effort = structuring effort + Interlinking effort + Interface planning + Interface building + Link-testing effort + Media-tesing effort

Pembuatan halaman

Text effort: Waktu yang diperlukan untuk pembuatan dan penggunaan text di halaman

Page-linking effort: Waktu yang diperlukan untuk pembuatan link pada halaman

Page-structuring effort: Waktu yang diperlukan untuk menata halaman

Total page effort = text effort + page-linking effort + page-structuring effort



Pembuatan media

Media effort: Waktu yang diperlukan untuk membangun atau menggunakan kembali file media

Media-digitizing effort: Waktu yang digunakan untuk penomoran media

Total media effort = media effort + media-digitizing effort


Pembuatan program

Program effort: Waktu untuk membuat HTML, java, atau bahasa pemrograman web lainnya.

Reuse effort: Waktu untu mencoba atau memodifikasi program yang telah jadi


diposting oleh: Alril Ambanaga (22064113)

November 05, 2008

Cyclomatic Complexity

Contoh Kasus Perhitungan Cyclomatic Complexity

Program Pemangkatan Dengan Fungsi


Source Code :


Flow Graph Notation :


Cyclomatic Complexity :

1). Region

2). Predicate Node

3). McCabe

Result :

1). Number of Region : R1,R2,R3

Cylomatic Complexity = 3

2). Predicate Node :

Cylomatic Complexity = predicate_node + 1

Predicate_node = …..(1) & …..(2)

Cylomatic Complexity = 2 + 1 = 3


3) McCabe

V(G) = E – N + 2

· Edge = 11

· Node = 10

V(G) = 11 – 10 + 2

V(G) = 3





Oleh : Mohammad Irfan Rahardian (22064117)