Kamis, 18 Desember 2008

METRIK PENGUKURAN PERANGKAT LUNAK PADA PROYEK PERANGKAT LUNAK SISTEM INFORMASI BISNIS

PENDAHULUAN
Dalam IEEE Standart 610.12 Rekayasa Perangkat Lunak di definisikan sebagai :
“The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software”.
Metrik digunakan oleh industri perangkat lunak untuk mengukur proses pembuatan, operasi, dan perawatan perangkat lunak. Melalui metrik, dapat diperoleh informasi-informasi berharga dan parameter-parameter sebagai bahan evaluasi yang obyektif mengenai atribut-atribut dan status dari suatu pengembangan perangkat lunak. Implementasi metrik perangkat lunak pada suatu proses pengembangan perangkat lunak dan pada suatu produk perangkat lunak melibatkan tahapan-tahapan kompleks yang memerlukan pembelajaran yang berkelanjutan, yang pada akhirnya dapat memberikan pengetahuan mengenai status dari suatu proses pembuatan perangkat lunak dan atau suatu produk dari perangkat lunak.

METRIK PERANGKAT LUNAK
Metrik perangkat lunak memiliki batasan-batasan yang luas. Metrik perangkat lunak tergantung pada atribut-atribut perangkat lunak yang ingin dinilai kuantitas dan kualitasnya. Hal-hal yang harus diukur dalam perangkat lunak adalah: masukan, keluaran, dan efektifitas hasil [Hetzel, 1993]. Secara umum, metrik perangkat lunak dibagi dalam dua kelas yang berbeda, yaitu metrik yang digunakan pada proyek
pengembangan perangkat lunak dan metrik yang digunakan pada produk perangkat lunak. Pada Metik terdapat penggunaan privat dan publik untuk data-data proses yang diperoleh. Beberapa metrik proses bisa bersifat privat untuk tim dalam proyek, namun bisa bersifat publik untuk seluruh anggota tim [Grady, 1992].

METRIK BERORIENTASI UKURAN JUMLAH DAN BARIS (SLOC)
SLOC = Source Line of Code
Secara virtual tidak mungkin untuk menghitung SLOC dari dokumen requirement awal. SLOC pengukurannya didasarkan pada bahasa pemrograman tertentu, oleh karena itu muncul banyak masalah dalam membuat standard pengukuran dengan teknik SLOC.
SLOC merupakan ukuran yang kurang akurat dan merupakan sebuah topik yang menimbulkan perdebatan selama bertahun- tahun, dipandang sebagai sebuah ukuran untuk mengestimasi biaya dan waktu, tidak dapat dipastikan bahwa dua program yang mempunyai SLOC sama akan membutuhkan waktu implementasi yang sama walaupun keduanya diimplemenatsikan dengan kondisi pemrograman
yang standard. Meskipun metode ini kurang akurat dan merupakan metodologi yang belum diterima secara luas, tetapi metrik dengan orientasi ukuran ini merupakan kunci pengukuran dan banyak estimasi software yang menggunakan model ini.

METRIK YANG BERORIENTASI PADA FUNGSI (FUNCTION POINT)

Pendekatan yang berorientasi fungsi mengukur fungsionalitas aplikasi untuk mengestimasi ukuran software dan selanjutnya digunakan untuk estimasi biaya dan usaha yang diperlukan untuk mengembangkan system.
Pendekatan ini diusulkan oleh Albrecht yang disebut sebagai metrik Function Points. Metrik ini diperoleh dari keterhubungan dasar antara domain informasi software dan kompleksitas software (Gambar 1). Function Points biasanya digunakan dalam mengukur system informasi manajemen (SIM).
Pada metodologi ini software dapat diklasifikasikan menjadi 5 domain yaitu:
• Jumlah data input pengguna
• Jumlah data output pengguna
• Jumlah data permintaan pengguna
• Jumlah file
• Jumlah file interface luar
Kemudian hitung nilai fungsi proyek yang mungkin pada setiap katagori dan kemudian setiap nilai perhitungan dikalikan dengan factor kompleksitas sebagai berikut:
• Sederhana (simple)
• Rata-rata (average)
• Komplek (complex)
Untuk menghitung Unadjusted Function Points digunakan tabel berikut berdasarkan kriteria dari setiap kategori.




Untuk menghitung function point digunakan persamaan berikut:

FP = count total * [0.65 * 0.01 * sum(Fj)]

Dimana count total adalah total yang diperoleh dari table function point analisis sum(Fj) adalah jumlah dari 14 faktor kompleksitas yang bernilai 0 s/d 5.



14 faktor kompleksitasnya adalah 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

PERNDEKATAN MODEL
Pendekatan model yang digunakan dalam menghitung besaran proyek adalah model function point (FP). Dibandingkan dengan pendekatan berbasis ukuran baris (LOC/Line Of Code). Pendekatan FP lebih independen terhadap bahasa pemrograman sehingga bisa diterapkan pada jenis aplikasi yang berbeda baik aplikasi database yang non-procedural, sistem informasi berbasis web, maupun aplikasi penghitungan, misalnya payroll. Pendekatan ini juga lebih mudah diprediksi daripada LOC karena parameternya dihitung berdasarkan data yang lebih diketahui, misalnya prediksi jumlah input dan ouput.
Meskipun FP dianggap memiliki kelemahan dalam subyektifitas data yang dimasukkan tetapi beberapa kriteria, misalnya untuk menentukan kategori sederhana atau kompleks, telah ditetapkan secara numerik untuk lebih memastikan obyektivitas data. Disamping itu, hasil perhitungan FP juga sering dianggap tidak memiliki arti yang mudah dipahami dibandingkan dengan LOC yang besarannya menunjukkan jumlah ukuran coding. Akan tetapi, hasil akhir FP dapat dikonversikan ke dalam LOC berdasarkan jenis bahasa pemrograman yang dipakai.
Jumlah usaha didapatkan dari waktu pengerjaan dikalikan dengan jumlah personel yang terlibat dalam pengerjaan proyek. Analisa regresi linear selanjutnya dilakukan terhadap beberapa sampel jumlah FP terhadap jumlah usaha/effort. Dari analisa tersebut akan didapatkan suatu persamaan, yakni:
Effort = a + b* FP
Konstanta a dan b yang didapat tersebut akan menjadi model bagi penentuan usaha (i.e jumlah biaya dan personel yang diperlukan) jika diketahui jumlah function point yang dapat dihitung dari kebutuhan pengguna (requirement definition).

VERIFIKASI MODEL
Verifikasi terhadap validitas model yang dihasilkan dapat diketahui dari sampel data yang masuk, tingkat kesalahan dalam regresi tingkat kesesuaian dengan model yang sudah ada. Perbedaan lingkungan pengembangan software, tentu akan menyebabkan persamaan yang berbeda. Kemungkinan perbedaan itu jugalah yang mendorong dilakukannya kajian ini sehingga diperoleh suatu model yang paling sesuai untuk daerah/lingkungan tertentu.
Verifikasi dengan berdasar pada jumlah sampel sering disebut sebagai exhaustive testing. Cara ini dilakukan dengan mengambil sampel atau kasus sebanyak mungkin untuk menguji disain dan implementasi sebuah sistem. Pendekatan ini diharapkan dapat mendeteksi kesalahan lebih akurat. Pendekatan ini membutuhkan semua kombinasi (exhaustive test) agar disain atau implementasi dapat dijamin benar. Untuk sistem yang besar dan kompleks, hal ini tentu saja tidak dapat dilakukan. Pendekatan formal method, yang menggunakan pembuktian secara matematis, biasanya digunakan untuk menguji sistem dengan tingkat kemungkinan yang tinggi. Akan tetapi untuk sample yang kecil (i.e tidak melebihi ribuan) seperti dalam kajian ini, exhaustive test ini dapat dilakukan.

CONTOH KASUS
Dalam Kasus ini kita akan mencoba implementasi Mertik Pengukuran Perangkat Lunak pada beberapa Sistem Informasi Bisnis
Data Pengembangan Proyek Perangkat Lunak Sistem Infomasi Bisnis


data yang diperoleh tidak dipublikasikan semuanya karena beberapa data merupakan rahasia perusahaan yang tidak boleh di ketahui oleh umum.

Pada proyek Sistem Informasi A diperoleh data sebagai berikut :
• jumlah input pemakainya = 22
• jumlah output pemakai = 8
• jumlah penyelidikan pemakai = 20
• jumlah file = 75
• jumlah interface eksternal = 25
• Diasumsikan 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.
count total
= (22 x 4) + (8 x 4) + (20 x 4) + (75 x 15) + (25 x 6)
= 88 + 32 +80+1125+ 150
=1475
sum Fj = 14 x 2 = 28
FP = 1475 x (0,65 + (0,01 x 28)) = 1371,75
Dana Proyek : Rp. 55.500.000
Dana per FP = Rp. 55.500.000 / 1371,75 =Rp. 40.459,26736

diatas merupakan contoh kasus metrik pengukuran perangkat lunak menggunakan Metrik Function Point.
Dengan menggunakan analisis LOC umum, Proyek Sistem Infomasi Bisnis A memiliki 194506 LOC

dan juga cara yang sama dapat diterapkan untuk Sistem Informasi Bisnis B dan C.

Referenced
B. Hetzel, 1993, Making Software Measurement Work: Building an Effective Measurement Program, QED Technical Publishing Group, Boston, Massachusetts, ISBN: 0471565687
Grady, Robert B., 1992, Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, Inc., ISBN: 0137203845
Lowell Jay Arthur, 1985, Measuring Programmer Productivity and Software Quality, John Wiley & Sons, Inc., New York, NY, ISBN: 0471887137
Pressman, 2000, R. S. Software Engineering A Practitioner’s Approach, 5th Edition, New York, McGraw Hill, ISBN: 0073655783
Albrecht, A. J., 1979, Measuring Application Development Productivity, IBM Applications Development Symposium, Monterey, CA , pp. 83-92
http://www.proyeksoftware.com

Sender : Matahari Bhakti Nendya
Sender ID : 22064091

3 komentar:

Bundet mengatakan...

Kuis RPL
ESTIMASI TOTAL BIAYA PROYEK (Rekayasa Perangkat Lunak)

Unknown mengatakan...

thanks....sangat membantu

My blog

Unknown mengatakan...

How to Play Casino: Easy Guide to playing slots on
Casino games are played by 4 players, the average 벳 매니아 time they take air jordan 18 retro toro mens sneakers free shipping turns is around 14:20. The house air jordan 18 retro online store is divided air jordan 18 retro men sale into three distinct top air jordan 18 retro yellow suede categories: the house