BAB 2
LANDASAN TEORI
2.1 Pengukuran
2.1.1 Definisi Pengukuran
Pengukuran merupakan dasar dari setiap disiplin rekayasa dan berlaku juga dalam perekayasaan perangkat lunak. Untuk mengevaluasi performa suatu system atau proses diperlukan suatu mekanisme untuk mengamati dan menentukan tingkat efisiensinya. Melalui pengukuran, maka akan diperoleh tingkat pencapaian di dalam proyek perangkat lunak yang sedang diamati.
Pengukuran menurut IEEE adalah ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu. Sedangkan mengukur (measure) adalah mengindikasikan kuantitatif dari luasan, jumlah, dimensi dan kapasitas. ( IEEE Std 610.12-1990, 1990)
Untuk setiap pengukuran yang dilakukan dibutuhkan tersedianya suatu ukuran kuantitatif yang disebut metrik. Istilah ukuran, pengukuran dan metrik sering digunakan secara bergantian. Metrik berdasarkan istilah rekayasa perangkat lunak didefinisikan sebagai sebuah ukuran kuantitatif yang dimiliki oleh suatu system, komponen atau proses tertentu dengan attribute-atribute yang diberikan. Oleh karena itu, untuk selanjutnya akan digunakan istilah metrik untuk menyebutkan pengukuran dalam pengukuran perangkat lunak
2.1.2 Metrik Perangkat Lunak
Menurut Sommerville (2003), pengukuran terbagi atas dua, yaitu pengukuran (metrik) kontrol dan pengukuran (metrik) prediktor. Metrik kontrol biasanya dihubungkan dengan proses perangkat lunak, misalnya usaha dan waktu rata-rata yang dibutuhkan untuk memperbaiki cacat yang dilaporkan. Sedangkan metrik prediktor berhubungan dengan produk perangkat lunak, misalnya kompleksitas sikomatik modul, panjang rata-rata identifier pada program dan jumlah atribut dan operasi yang berhubungan dengan objek pada suatu rancangan.
Metrik juga dapat dipisahkan dalam dua kategori, yaitu metrik langsung dan metrik tidak langsung. Metrik langsung dalam proses rekayasa perangkat lunak berhubungan dengan biaya dan sumber daya yang diperlukan, misalnya: pengukuran jumlah baris kode, kecepatan eksekusi, ukuran memori, dan kesalahan yang ditemui dalam suatu periode waktu. Metrik tidak langsung dari suatu produk berhubungan dengan fungsionalitas, kualitas, kompleksitas, efisiensi, reliabilitas, dan lain sebagainya. Pengukuran secara langsung lebih mudah dilakukan, karena hasil dapat diperoleh secara langsung, sedangkan pengukuran tidak langsung lebih sulit dilakukan, karena harus melalui proses yang lebih kompleks.
Metrik dipisahkan menjadi metrik proses, proyek, dan produk. Metrik produk bersifat privat untuk individu dan sering dikombinasikan untuk membuat metrik proyek yang bersifat publik bagi tim pengembang. Metrik proyek kemudian dikonsolidasikan untuk membuat metrik proses yang publik untuk seluruh organisasi atau perusahaan. Kesulitan yang biasanya dihadapi adalah pada saat melakukan kombinasi pada metrik-metrik yang diukur disebabkan karena sering terjadi perbedaan metrik antara individu satu dengan individu lainnya. Masalah tersebut biasa diatasi apabila dilakukan normalisasi pada proses pengukuran. Dengan adanya normalisasi maka dapat dilakukan perbandingan metrik pada cakupan yang lebih luas.
2.2 Metrik Dalam Proses dan Domain Proyek
(misalnya paradigma, tugas-tugas rekayasa perangkat lunak, produk kerja, dan kejadian penting). Indikator proses memungkinkan manajer dan pelaksana memperkirakan apa yang harus dikerjakan dan yang tidak.
Indikator proyek memungkinkan manajer proyek perangkat lunak : a. Memperkirakan status sebuah proyek yang sedang berlangsung b. Menelusuri risiko-risiko potensial
c. Menemukan area masalah sebelum masalah ”menjadi semakin kritis” d. Menyesuaikan aliran kerja atau tugas-tugas; dan
e. Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas hasil kerja rekayasa perangkat lunak
2.2.1 Metrik Proses dan Peningkatan Perangkat Lunak
Satu-satunya cara yang paling rasional untuk meningkatkan proses adalah dengan mengukur atribut tertentu dari proses, mengembangkan serangkaian metrik yang berarti berdasarkan atribut-atribut tersebut, dan kemudian menggunakan metrik itu untuk memberikan indikator yang akan membawa kepada sebuah strategi pengembangan.
Keterampilan dan motivasi yang diperlihatkan oleh manusia merupakan satu-satunya faktor yang paling berpengaruh pada kualitas dan unjuk kerja tim. Kita mengukur reliabilitas proses perangkat lunak secara tidak langsung yaitu dengan mengambil serangkaian metrik berdasarkan keluaran yang dapat diambil oleh proses. Keluaran menyangkut pengukuran kesalahan yang ditemukan sebelum pelepasan perangkat lunak, cacat yang disampaikan dan dilaporkan oleh pemakai akhir, produk kerja yang dikirim, usaha manusia yang dilakukan, waktu kalender yang digunakan, konfirmasi jadwal, serta pengukuran yang lain.
Menurut Sommerville, ada tiga kelas metrik proses:
b. Sumber daya yang dibutuhkan untuk suatu proses tertentu. Sumber Daya bisa berupa usaha dalam orang-hari, biaya perjalanan, sumber daya komputer, dan lain-lain.
c. Jumlah terjadinya even tertentu. Contoh event yang dapat dipantau mencakup jumlah cacat yang ditemukan pada saat inspeksi kode, jumlah perubahan persyaratan yang diminta, jumlah rata-rata baris kode yang dimodifikasi sebagai tanggapan terhadap perubahan persyaratan dan lain-lain
Grady menyatakan bahwa ”etika metrik perangkat lunak” merupakan hal yang tepat bagi para manajer ketika mereka melembagakan program metrik proses:
a. Gunakan istilah umum dan kepekaan organisasi ketika menginterpretasi data metrik.
b. Berikan umpan balik reguler kepada individu dan tim yang telah bekerja untuk mengumpulkan pengukuran dan metrik.
c. Jangan menggunakan metrik untuk menilai individu
d. Bekerja dengan pelaksana dan tim untuk menentukan tujuan dan metrik yang jelas yang akan dipakai untuk mencapainya.
e. Jangan pernah menggunakan metrik untuk mengancam individu dan tim.
f. Metrik data yang menunjukkan sebuah area masalah tidak boleh “dianggap negative.” Data-data itu hanya merupakan sebuah indicator bagi peningkatan proses.
g. Jangan tergoda pada sebuah metrik dan kemudian mengabaikan metrik penting yang lain.
Pada dasarnya statistical software process improvement (SSPI) menggunakan analisis kegagalan perangkat lunak untuk mengumpulkan informasi seputar semua kesalahan dan cacat yang terjadi pada saat sebuah aplikasi, sistem, atau produk dikembangkan dan dipakai. Analisis kegagalan bekerja dengan cara sebagai berikut :
b. Biaya untuk mengkoreksi setiap kesalahan dan cacat dicatat.
c. Jumlah kesalahan dan cacat dari setiap kategori dihitung dan ditata dalam urutan naik.
d. Biaya keseluruhan dari kesalahan dan cacat dari setiap kategori dihitung. e. Data resultan dianalisis untuk menemukan kategori yang menelan biaya besar. f. Rencana dikembangkan untuk memodifikasi proses guna mengeliminasi
(mengurangi frekuensi kejadian) kelas kesalahan dan cacat yang paling membutuhkan banyak biaya.
2.2.2 Metrik Proyek
Metrik yang dikumpulkan dari proyek 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 kalender yang digunakan dibandingkan dengan perkiraan awal (dan jadwal proyek).
Nilai produksi yang disajikan dalam bentuk halaman dokumentasi, jam kajian, titik-titik fungsi, dan deretan sumber yang disampaikan diukur serta kesalahan yang ditemukan selama masing-masing tugas kerja rekayasa perangkat lunak kemudian ditelusuri.
Metrik proyek mempunyai tujuan ganda. Pertama, metrik tersebut digunakan untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yang diperlukan untuk menghindar penundaan serta mengurangi masalah dan risiko potensial. Kedua, metrik proyek dipakai untuk memperkirakan kualitas produk pada basis yang berlaku dan bila dibutuhkan, memodifikasi pendekatan teknis untuk meningkatkan kualitas.
Model lain dari metrik proyek mengusulkan bahwa setiap proyek seharusnya mengukur :
b. Output (pengukuran kemampuan penyampaian atau produk kerja yang diciptakan selama proses rekayasa perangkat lunak).
c. Hasil (pengukuran yang menunjukkan efektivitas kemampuan penyampaian).
.
2.3 Mengimplementasikan Metrik pada Perangkat Lunak
Implementasi metrik pada perangkat lunak berkaitan erat dengan estimasi usaha dan biaya kegiatan proyek perangkat lunak. Produktivitas pada sistem dapat diukur dengan menghitung jumlah satuan yang dihasilkan dan membagi nilai ini dengan jumlah orang-jam yang dibutuhkan untuk menghasilkannya. Estimasi produktivitas biasanya berdasar atas pengukuran beberapa atribut perangkat lunak dan membaginya dengan usaha total yang dibutuhkan untuk pengembangan. Ada dua jenis pengukuran yang telah dipakai:
a. Metrik yang berhubungan dengan ukuran.
Pengukuran ini berhubungan dengan ukuran output dari suatu kegiatan. Pengukuran yang berhubungan dengan ukuran yang paling umum adalah jumlah baris kode sumber yang diserahkan. Pengukuran lain yang dapat digunakan adalah jumlah instruksi kode objek yang diserahkan atau jumlah halaman dokumentasi sistem.
b. Metrik yang berhubungan dengan fungsi.
Pengukuran ini berhubungan dengan fungsionalitas menyeluruh dari perangkat lunak yang diserahkan. Produktivitas dinyatakan dalam jumlah fungsionalitas yang berguna dalam waktu tertentu. Poin fungsi dan poin objek merupakan pengukuran yang paling dikenal dari jenis ini.
2.3.1 Pengukuran Yang Berhubungan Dengan Ukuran
Pegukuran yang berhubungan dengan ukuran (Metric Size Oriented) adalah pengukuran dengan normalisasi kualitas dan produktifitas atau mempertimbangkan ukuran perangkat lunak yang dihasilkan. Metric size oriented dilakukan dengan menghitung LOC (Line of Code) dari baris kode suatu perangkat lunak. Pada pengembangan, pengukuran ini juga dapat mengukur:
h. Kesalahan per KLOC (Kilo Line Of Code) i. Biaya per LOC
j. Cacat per LOC
k. Halaman dokumentasi per LOC l. Kesalahan perorang perbulan m. LOC perorang perbulan
n. Biaya perhalaman dokumentasi.
Menurut Jones (Pressman,2001) LOC 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 LOC sama akan membutuhkan waktu implementasi yang sama walaupun keduanya diimplementasikan 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.
ukuran yang berorientasi fungsi dan ukuran yang berorientasi object. Metode ini merupakan metode yang lebih konsisten dan diterima secara luas.
2.3.2 Pengukuran yang Berhubungan dengan Function Point
Pengukuran yang berhubungan dengan fungsi (Metric Function Oriented) adalah pengukuran fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai normalisasi. Perhitungan dengan metode Function Point menuntut untuk dilakukan oleh seorang profesional yang berpengalaman karena memiliki tingkat subyektifitas yang cukup tinggi. Metrik berorientasi fungsi diusulkan oleh Albrecth pada tahun 1979, yang menyarankan pengukuran yang disebut Function Point. Function Point tidak bergantung pada bahasa sehingga produktivitas pada bahasa pemrograman yang berbeda dapat dibandingkan. Produktivitas dinyatakan sebagai poin fungsi yang dihasilkan per orang-bulan. Function Point di-bias menuju system pemrosesan data yang didominasi oleh operasi input dan output. Metode ini sendiri terdiri dari banyak varia. Variasi yang adalah pada langkah/tahapan yang ada maupun pada isi dari tiap tahapan. Varian-varian ini timbul karena metode ini dapat diubah sesuai dengan kebijakan perusahaan pengembang software. Namun apapun varian yang digunakan oleh pengembang, hendaknya digunakan dengan konsisten agar tercipta komparasi yang benar antara software-software yang dinilai.
Metode dalam metrik ini berdasarkan publikasi varian yang populer seperti Gramus dan Herron, IEEE, Caldiera (Pressman, 2001) yang menghasilkan manual penggunaan function point seperi IFPUG 3, IFPUG 4 dan Mark II. Tahapan-tahapan yang ada dalam menentukan function point adalah sebagai berikut :
Langkah 1 : Menghitung crude function points (CFP)
Jumlah dari komponen fungsional sistem pertama kali diidentifikasi dan dilanjutkan dengan mengevaluasi kuantitasi bobot kerumitan dari tiap komponen tersebut. Pembobotan tersebut kemudian dijumlahkan dan menjadi angka CFP.
Perhitungan CFP melibatkan 5 tipe komponen sistem software berikut : a. Jumlah macam aplikasi input (user inputs)
c. Jumlah macam aplikasi query online – aplikasi ini berhubungan dengan query terhadap data yang tersimpan (Inquiry)
d. Jumlah macam file/tabel logic yang terlibat
e. Jumlah macam interface eksternal – output atau input yang dapat berhubungan dengan komputer lewat komunikasi data, CD, disket, dan lain-lain.
Kemudian diberikan faktor bobot pada tiap komponen di atas berdasarkan kompleksitasnya. Tabel 2.1 di bawah ini merupakan contoh blanko pembobotan tersebut.
Langkah 2 : Menghitung faktor pengubah kompleksitas relatif/Relative
Complexity Adjustment Factor (RCAF).
RCAF berfungsi untuk menghitung kesimpulan kompleksitas dari sistem software dari beberapa subyek karakteristik. Penilaian berskala 0 sampai 5 diberikan pada tiap subyek yang paling berpengaruh terhadap usaha pengembangan yang dibutuhkan. Blanko penilaian yang diusulkan penulis diberikan seperti Tabel 2.2
Tabel 2.2 Blanko penghitungan RCAF
No Subyek Nilai
1 Tingkat kompleksitas kehandalan backup/recovery 0 1 2 3 4 5
2 Tingkat kompleksitas komunikasi data 0 1 2 3 4 5
4 Tingkat kompleksitas kebutuhan akan kinerja 0 1 2 3 4 5
5 Tingkat kebutuhan lingkungan operasional 0 1 2 3 4 5
6 Tingkat kebutuhan knowledge pengembang 0 1 2 3 4 5
7 Tingkat kompleksitas updating file master 0 1 2 3 4 5
8 Tingkat kompleksitas instalasi 0 1 2 3 4 5
9 Tingkat kompleksitas aplikasi input, output, query online dan file 0 1 2 3 4 5
10 Tingkat kompleksitas pemrosesan data 0 1 2 3 4 5
11 Tingkat ketidakmungkinan penggunaan kembali dari kode (reuse) 0 1 2 3 4 5
12 Tingkat variasi organisasi pelanggan 0 1 2 3 4 5
13 Tingkat kemungkinan perubahan/fleksibilitas 0 1 2 3 4 5
14 Tingkat kebutuhan kemudahan penggunaan 0 1 2 3 4 5
Total = RCAF
Langkah 3 : Menghitung Function Point (FP)
Nilai function point untuk sistem software tersebut kemudian dihitung berdasarkan hasil dari tahap 1 dan 2 yang dimasukkan ke dalam formula
FP = CFP x (0.65 + 0.01 x RCAF) (2.1)
2.4 Estimasi Proyek Perangkat Lunak
Estimasi biaya dan tenaga sukar untuk menjadi sebuah ilmu pasti. Banyak faktor seperti manusia, teknis, lingkungan, atau politik, yang dapat mempengaruhi besarnya biaya dan tenaga yang diperlukan untuk mengembangkan perangkat lunak. Bagaimanapun juga, estimasi proyek perangkat lunak dapat ditransformasikan dari sesuatu yang abstrak menjadi suatu urutan langkah langkah sistematis yang menghasilkan perkiraan-perkiraan dengan tingkat resiko yang dapat diterima.
Ada beberapa cara yang dapat digunakan untuk melakukan perkiraan proyek: 1. Perkiraan keterlambatan suatu proyek dapat diselesaikan
3. Menggunakan teknik dekomposisi sederhana untuk membuat suatu kisaran biaya dan tenaga
4. Menggunakan satu atau lebih model empiris untuk perkiraan biaya dan tenaga
Teknik yang disarankan oleh para ahli di bidang perangkat lunak adalah dengan menggunakan kombinasi antara teknik dekomposisi dan model empiris. Teknik dekomposisi menggunakan pendekatan dengan cara membagi suatu proyek ke dalam beberapa fungsi mayor yang berhubungan dengan aktivitas rekayasa perangkat lunak. Model estimasi empiris dapat digunakan sebagai pelengkap bagi teknik dekomposisi.
2.4.1 Estimasi Berbasis Masalah
Estimasi berbasis LOC dan FP memiliki teknik yang unik. Keduanya memiliki karakteristik sendiri. Perencana proyek memulai dengan kumpulan pernyataan yang berisi kerangka dan batasan-batasan dari perangkat lunak dan dari peryataan-pernyataan tersebut kemudian mencoba untuk melakukan dekomposisi perangkat lunak ke dalam banyak fungsi permasalahan (problem function) dan melakukan estimasi variabel-variabel (LOC dan FP) pada tiap fungsi permasalahan. Sebagai alternatif, perencana proyek dapat memilih komponen untuk menentukan ukuran, seperti kelas obyek, perubahan, atau proses bisnis yang terpengaruh.
Metrik produktivitas (misalnya: LOC/pm atau FP/pm9) diaplikasikan ke dalam variabel estimasi. Akronim pm digunakan untuk menyatakan satuan person-month (orang-bulan). Metrik kemudian dikombinasikan untuk memperoleh estimasi dari keseluruhan proyek. Dengan menggunakan data dari proyek di masa lalu, perencana proyek dapat membagi nilai perkiraan ke dalam nilai ukuran (S),
2.5 Model Estimasi Empiris
estimasi yang cocok untuk semua lingkungan pengembangan perangkat lunak. Maka dari itu, penerapan hasil yang diperoleh dari model-model yang sudah disediakan harus digunakan secara bijaksana sesuai dengan keadaan lingkungan masing-masing pengembang.
2.5.1 Struktur Model-Model Estimasi
Model estimasi diperoleh melalui analisis regresi pada data yang diperoleh pada proyek-proyek di masa lalu. Keseluruhan struktur dari beberapa model mengambil dari persamaan yang dipaparkan oleh Matson ( Matson, 1994):
E = A + B x (ev)C (2-3)
Dimana E adalah effort dalam orang-bulan, dan A, B, C adalah konstanta yang diperoleh secara empiris. Dalam perkembangannya persamaan tersebut dikembangkan sesuai dengan proyek yang dikerjakan oleh masing-masing pengembang perangkat lunak. Perbedaan persamaan yang digunakan oleh masing-masing pengembang dikarenakan persamaan tersebut harus dikalibrasi terlebih dahulu, sesuai dengan kondisi maupun kebutuhan.
Di antara berbagai model perkiraan yang berorientasi pada LOC yang diusulkan dalam literatur ini adalah :
E = 5,2 x (KLOC)0,91 Walston-felix Model (2.4) E = 5,5 + 0,73 x (KLOC)1,16 Baily-Basili Model (2.5) E = 3,2 x (KLOC)1,05 Model sederhana Boehm (2.6) E = 5,288 x (KLOC)1,047 Dotu Model untuk KLOC > 9 (2.7)
Model-model orientasi FP juga telah diusulkan, yaitu :
2.5.2 Model COCOMO
COCOMO adalah sebuah model yang didesain oleh Barry Boehm untuk memperoleh perkiraan dari jumlah orang-bulan yang diperlukan untuk mengembangkan suatu produk perangkat lunak. Satu hasil observasi yang paling penting dalam model ini adalah bahwa motivasi dari tiap orang yang terlibat ditempatkan sebagai titik berat. Hal ini menunjukkan bahwa kepemimpinan dan kerja sama tim merupakan sesuatu yang penting, namun demikian poin pada bagian ini sering diabaikan.
Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:
1. Proyek organik, adalah proyek dengan ukuran relatif kecil, dengan anggota tim yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif fleksibel.
2. Proyek sedang (semi-terpisah), adalah proyek yang memiliki ukuran dan tingkat kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang berbeda.
3. Proyek terintegrasi, adalah proyek yang dibangun dengan spesifikasi dan operasi yang ketat.
Persamaan dasar model COCOMO adalah:
E = ab (KLOC)bb (2.11)
D = cb (E)db (2.12)
P = E / D (2.13)
Tabel 2.3 Model Cocomo Dasar
Proyek Perangkat Lunak ab bb cb db
Organik 2,4 1,05 2,5 0,38
Semi-detached 3,0 1,12 2,5 0,35
Embedded 3,6 1,20 2,5 0,32
Hirarki model Boehm berbentuk sebagai berikut:
Model 1 : Model COCOMO Dasar menghitung usaha pengembangan perangkat lunak (dan biaya) sebagai fungsi dari ukuran prgram yang diekspresikan dalam baris kode yang diestimasi.
Model 2 : Model COCOMO Intermediate menghitung usaha pengembangan perangkat lunak sebagai fungsi ukuran program dan serangkaian “pengendali biaya” yang menyangkut penilaian yang subyektif terhadap produk, perangkat keras personil, dan atribut proyek.
Model 3 : Model COCOMO advanced menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengendali biaya pada setiap langkah (analisis, perancangan, dan lain-lain) dari proses rekayasa perangkat lunak.
Pengembangan model COCOMO adalah dengan menambahkan atribut yang dapat menentukan jumlah biaya dan tenaga dalam pengembangan perangkat lunak, yang dijabarkan dalam kategori dan subkategori sebagai berikut:
1. Atribut produk
a. Reliabilitas perangkat lunak yang diperlukan b. Ukuran basis data aplikasi
c. Kompleksitas produk 2. Atribut perangkat keras
a. Performa program ketika dijalankan b. Memori yang dipakai
c. Stabilitas mesin virtual
3. Atribut Sumber Daya Manusia a. Kemampuan analisis
b. Kemampuan ahli perangkat lunak c. Pengalaman membuat aplikasi
d. Pengalaman menggunakan mesin virtual
e. Pengalaman dalam menggunakan bahasa pemrograman 4. Atribut proyek
a. Menggunakan perangkat lunak tambahan b. Metode rekayasa perangkat lunak
c. Waktu yang diperlukan
Masing-masing subkategori diberi bobot antara 0 (sangat rendah) sampai 6 (sangat tinggi), dan kemudian dijumlahkan. Dari pengembangan ini diperoleh persamaan:
E=ai(KLOC)(b)i.EAF (2.14)
2.5.3 Persamaan pada Perangkat Lunak
Persamaan perangkat lunak merupakan model variabel jamak yang menghitung suatu distribusi spesifik dari usaha pada jalannya pengembangan perangkat lunak. Persamaan berikut ini diperoleh dari hasil pengamatan terhadap lebih dari 4000 proyek perangkat lunak:
E = [LOC x B0.333/P]3 x (1 / t4) (2.15)
E = usaha dalam orang-bulan atau orang-tahun t = durasi proyek dalam bulan atau tahun B = faktor kemampuan khusus
P = parameter produktivitas
Nilai P merefleksikan:
1. Kematangan proses dan praktek manajemen 2. Kualitas rekayasa perangkat lunak
3. Tingkat bahasa pemrograman yang digunakan 4. Keadaan lingkungan perangkat lunak
5. Kemampuan dan pengalaman tim pengembang 6. Kompleksitas aplikasi
Berdasarkan teori, diperoleh P = 2000 untuk sistem terapan, P = 10000 untuk perangkat lunak pada sistem informasi dan sistem telekomunikasi, dan P = 28000 untuk sistem aplikasi bisnis.
2.6 Konversi Waktu Tenaga Kerja
Konversi waktu tenaga kerja pada tugas akhir ini ini diperoleh dari angka pembanding yang digunakan pada rata-rata pengerjaan proyek perangkat lunak (Sommervile, 2003), dengan hubungan persamaan antara bulan (OB), jam (OJ), orang-minggu (OM), dan orang-tahun (OT) adalah sebagai berikut:
OM = 40 OJ OT = 12 OB OT = 52 OM
Dari persamaan di atas, diperoleh konversi orang-bulan ke orang-jam sebagai berikut
OB = (40 OJ x 52) / 12
