Effort Estimasi

Contoh Kasus Effort Estimasi

Program Sederhana Switch Luas Dengan Fungsi

Perhitungan UFP adalah :

Perhitungan TCF adalah:
1. Backup dan recovery dapat dipercaya 0
2. Komunikasi data 0 
3. Fungsi distribusi 0 
4. Performansi 1 
5. Lingkungan operasional 1 
6. Data entry on-line 0
7. Layar interaktir untuk input 0 
8. Online update 0
9. Kompleksitas interface 0
10. Bisa digunakan kembali (reusability) 1 
11. Kompleksitas proses 0
12. Kemudahan dalam install 1
13. Memiliki banyak site 0 
14. Mudah digunakan 1
TCF = 5


1). Perhitungan Function Point
FP = UFP x (0.65 + 0.01 * TCF)
FP = 6 x (0.65 + 0.01 * 5) = 4,2

2) Konversi SIZE ke Satuan KDSI
SIZE = FP*NCSS
SIZE = 4,2*70
SIZE = 294
SIZE = 0.294 KDSI

Program Sederhana Switch Luas ini termasuk dalam kelas organic sesuai criteria :

Organik : 
Merupakan proyek rutinitas, proyek yang dikerjakan mudah dipelajari, tim work bekerja scara efisien, proyek yang dikerjakan memiliki sedikit hambatan dan umumnya sistem kecil.

3). Person-Month
PM(Person Month) = EAF * a * SIZE + b

EAF(Effort Adjustment Factor) : 
Required software reliability v.low 0.75 
Product Complexity v.low 0.70

PM = (0.75*0.70)* (2.4 * (0.294) + 1.05)
PM = 0.525*1.7556
PM = 0.92169

2 PM(Person Month) yang dibutuhkan untuk menyelesaikan proyek Open Source ini.

Duration =2.5 * (0.92169)^0.38  
Duration = 2.423718967
Waktu yang dibutuhkan sebanyak 2 bulan

4). Staffing 
Staffing adalah jumlah orang yang dibutuhkan untuk membangun proyek Open Source ini. Perhitungan staffing adalah sebagai berikut :
STAFFING = EFFORT(PM) / DURASI
STAFFING = 0.92169/2.423718967
STAFFING = 0.380279237

Berdasarkan perhitungan diatas, maka dapat diambil kesimpulan bahwa untuk menghasilkan program ini dibutuhkan 1 orang.

5). Kalkulasi Berbasis Function Point untuk Program Diatas
● FP : 4,2 = 4
● Effort : 1 PM
● Avg productivity : 4 FP/PM
● Labor rate : $30 (misalnya)
● Cost per FP : $7.5(Labor Rate/FP)
● Total Project cost : $30(Labor Rate*Effort)

6). Kalkulasi Berbasis LOC untuk Program Diatas
● LOC : 52(gambar paling atas)
● Effort : 1 PM
● Avg productivity : 52 LOC/PM
● Labor rate : $30 (misalnya)
● Cost per LOC : $0.576923076 = $0.6 (Labor Rate/ Avg productivity)
● Total Project cost : $30(Labor Rate*Effort)

Created by Tri Budiyanto [22064115]

Ciri khas Pengukuran Perangkat Lunak dan Metrik

Typical Software Measurements and Metrics
Ciri khas Pengukuran Perangkat Lunak dan Metrik

Daftar seluruh industri metric tersedia untuk penggunaan manajemen rekayasa perangkat Iunak, berkisar dari tingkat usaha yang tinggi dan pengukuran besar(size) perangkat lunak untuk memerincikan pengukuran requirement dan informasi personalia. Mutu, bukan kuantitas, harus menjadi faktor memandu dalam memilih metrik. Sebaiknya memilih suatu yang kecil, kumpulan metric yang memiliki arti, yang mempunyai garis dasar yang kuat di lingkungan yang serupa.

Ciri khas kumpulan metrik mungkin meliputi:
1.Mutu (Quality)
2.Ukuran(Size)
3.Kompleksitas(Complexity)
4.Persyaratan (Requirements)
5.Usaha(Effort)
6.Produktivitas(Productivity)
7.Harga dan jadwal(Cost and schedule)
8.Scrap and rework(Sisa dan pengerjaan ulang)
9.Dukungan(Support).

A.Kualitas

Mengukur kualitas produk merupakan kesulitan dari sejumlah pertimbangan. Satu alasan adalah ketiadaan suatu definisi yang tepat untuk kualitas. kualitas dapat digambarkan sebagai derajat keunggulan yang terukur pada produk Anda. definisi IEEE untuk kualitas perangkat lunak adalah derajat pada suatu sistim, komponen,or proses pertemuan:

• Persyaratan(requirements) ditetapkan.

• Kebutuhan pelanggan atau pengguna atau harapan. [IEEE90].

Kualitas di dalam mata dari pengguna! Untuk beberapa program, kualitas produk boleh jadi digambarkan sebagai keandalan [contohnya., suatu densitas kegagalan yang rendah], selagi maintainabilitas yang lain adalah persyaratan untuk kualitas produk. [MARCINIAK90] Definisi anda dari kualitas suatu produk harus didasarkan pada kelengkapan kualitas yang terukur yang meberikan kepuasan pada pengguna program sesuai dengan kebutuhan yang ditetapkan. Karena persyaratan-persyaratan berbeda antar program-program, kualitas kelengkapan juga akan berubah atau berbeda.

B.Ukuran/Size

Ukuran perangkat lunak mengindikasikan usaha yang diperlukan. Metrik size perangkat lunak telah dibahas seperti SLOC, function point, dan feature point.

C.Kompleksitas

Pengukuran kompleksitas berfokus pada desain-desain dan kode sesungguhnya. Mereka mengasumsikan ada suatu korelasi langsung antara kompleksitas desain dan error desain, dan kode kompleksitas dan cacat-cacat yang tersembunyi. Dengan cara mengenali setiap properti yang menghubungkan kepada kompleksitas mereka, kita dapat mengidentifikasi aplikasi-aplikasi yang memiliki tingkat kerusakan tinggi yang manapun harus ditinjau kembali atau diperlakukan untuk dilakuan pengujian tambahan.

Perlengkapan perangkat lunak yang menghubungkan kepada seberapa kompleks ukurannya, antar muka antar modules (biasanya diukur sebagai fan-in, banyaknya permohonan modul-modul suatu aplikasi yang diberikan, atau fan-out, banyaknya modul-modul yang dilibatkan oleh suatu aplikasi yang diberi), dan struktur (banyaknya alur-alur di dalam suatu modul). Metric kompleksitas membantu untuk menentukan jumlah dan jenis dari test-test yang diperlukan yang mencakup desain (antarmuka atau panggilan) atau kode logika (cabang dan statemen-statemen). Ada beberapa metoda-metoda yang diterima untuk mengukur kompleksitas, kebanyakan dapat dihitung dengan menggunakan tools otomatis.

dikutip dari :Chapter 13: Software Estimation, Measurement & Metrics GSAM Version 3.0. Oleh Karen Rasmussen

Oleh Tri Budiyanto [ 22 06 4115 ]

Daur hidup dari Pengukuran Perangkat Lunak

Software Measurement Life Cycle

Daur hidup dari Pengukuran Perangkat Lunak

Pengukuran perangkat lunak yang efektif akan menambahkan nilai pada semua tahap daur hidup.

Gambar 13-3 menggambarkan ukuran-ukuran yang utama yang berhubungan dengan setiap tahap dari pengembangan. Selama fase requirements, function point dihitung.


Sejak masalah requirement yang merupakan sumber utama dari biaya dan jadwal yang terbanjiri, kesalahan(error) dan kualitas dari sistem tracking mulai berjalan. Suatu requirement mulai digambarkan.

Tahap yang berikutnya dari pengukuran bergantung pada apakah program itu merupakan suatu pengembangan yang dibuat menurut pemesanan, atau suatu kombinasi dari pengembangan aplikasi-aplikasi yang baru, asset-asset bisa kita(kami kembali, dan COTS. Resiko-Resiko dan semua calon pendekatan akan diukur dan dianalisa.

Jika solusi merupakan suatu pengembangan yang disesuaikan, dari desain sistem yang logis, penghilangan kerusakan bisa merupakan suatu aktivitas yang sangat memakan biaya. Oleh karena itu, pemeriksaan-pemeriksaan tinjauan desain dan pengamatan digunakan untuk dikumpulkan dan rekaman dari data yang mengalami kerusakan

Data dianalisa untuk menentukan bagaimana caranya mencegah kerusakan yang sama di akan datang. Selama pemeriksaan desain fisik, peninjauan ulang dan pengamatan dilanjutkan dengan baik dan kerusakan data tetap dikumpulkan dan dianalisa. Tahap pengkodean dapat menjadi sesuatu dari yang sangat sulit ke seuatu yang hampir tidak sulit tergantung dari suksesnya tahap-tahap yang terdahulu. Kerusakan dan kualitas data seperti halnya pengukuran kompleksitas kode, direkam selama pemeriksaan peninjauan kode dan pengamatan.

Salah satu dari karakteristik-karakteristik yang paling penting dari pengembangan perangkat lunak adalah kompleksitas. Dengan yang pertama adalah proses arsitektur, sepanjang fase desain, dan sesudah itu, seperti kode dikembangkan dan di-compile, mengevaluasi kompleksitas dari pengembangan yang anda usulkan. Ini akan memberi anda pengertian yang penting dalam hal kelayakan software yang anda bawa ke suatu kesimpulan atau konklusi yang sukses.

Fase ujian akan mencakup dari suatu unit uji perilaku para programmer yang sederhana, ke skala yang besar, deretan test formal yang multi-staged, termasuk uji fungsi, uji integrasi, uji tekanan, uji regresi, uji kemandirian, uji lapangan, uji sistim, dan uji kemampuan akhir. Selama semua kegiatan ini, kerusakan data yang mendalam dikumpulkan dan dianalisa untuk digunakan dalam pencegahan kerusakan berikutnya.
aktivitas seperti mengubah proses pengembangan untuk mencegah kerusakan yang sama di pengembangan selanjutnya. Analisis retrospektif ditunjukan pada penghilangan cacat secara efisien untuk setiap tinjauan ulang yang spesifik, inspeksi pengamatan, dan pengujian, dan efisiensi yang kumulatif dari seluruh rangkaian langkah-langkah penghilangan kerusakan.

Selama fase perawatan, kepuasan pengguna dan data cacat yang tersembunyi dikumpulkan. Untuk peningkatan atau penggantian pada sistem yang ada, struktur, kompleksitas, dan tingkat kerusakan dari perangkat lunak yang ada ditentukan. Analisa retrospektif lebih lanjut dari penghilangan cacat efisien juga dilaksanakan. Gol dari penghilangan cacat secara umum adalah kumulatif suatu efisiensi penghilangan kerusakan(cacat) yang dari 95% untuk MIS(sistem informasi manajemen), dan 999% (atau lebih besar) untuk sistem senjata real-time. Ini berarti itu, ketika cacat ditemukan oleh tim pengembangan atau pemakai, cacat akan dijumlahkan terlebih dulu (dan berikut) tahun(s) operasi. Idealnya, tim pengembangan akan menemukan dan menghilangkan 95% ke 100% dari semua cacat yang tersembunyi.


dikutip dari :Chapter 13: Software Estimation, Measurement & Metrics GSAM Version 3.0. Oleh Karen Rasmussen

Oleh Tri Budiyanto [ 22 06 4115 ]