Chapter 5

Obyektif

Menghindari estimasi yang tidak realistis
Memahami range dari metode estimasi yang dapat digunakan
Estimasi proyek menggunakan pendekatan butoom-up
Menghitung function point untuk sebuah system
Estimasi usaha yang diperlukan untuk implementasi software menggunakan bahasa pemrograman prosedural
Memahami pendekatan COCOMO untuk membangun model usaha

5.1 Pendahuluan
Salah satu definisi proyek yang sukses adalah systemnya dikirim “tepat waktu, sesuai anggaran, sesuai dengan kualitas yang diharapkan”. Oleh karena itu, estimasi awal haruslah tepat, karena ini sangat penting dalam sebuah proyek. Untuk estimasi itu sendiri tidaklah mudah. Faktor-faktor yang mempengaruhi antara lain :

Complesity dan invisibility
Aplikasi baru dalam software
Perubahan teknologi
Ketidak samaan dari pengalaman proyek terdahulu
Subjective nature of estimating
Beberapa peneliti menunjukkan bahwa orang cenderung meremehkan proyek yang kecil dan over-estimasi untuk proyek yang besar. Pada dunia software development dapat dikatakan untuk proyek yang besar biasanya tidak sepadan kekomplekan dan kesulitannya dibandingkan dengan yang kecil
Political implication
IOE information system development manager, dengan melihat sebayak mungkin system yang diimplementasikan, sehingga akan memberikan tekanan pada estimator untuk mereduksi biaya, sehingga untuk managememnt yang lebih tinggi dapat menyetujui proyek tersebut. Salah satu solusi untuk menghindari faktor “politik” adalah dengan menggunakan group spesialis estimasi yang independen.

5.2 Dimana Estimasi telah dilakukan ?
Estimasi terdapat bayak tahap dari proyek software. Setiap tahap, alasan untuk estimasi dan metode yang digunakan bermacam-macam.

Perencanaan strategis
Pada tahap ini, biaya dari aplikasi potensial yang terkomputerisasi dan keuntungan akan membutuhkan estimasi untuk menentukan prioritas pada setiap proyek. Estimasi tersebut juga dipengaruhi jumlah staf development yang direkrut oleh sebuah organisasi
Feasibility study
Ini memastikan bahwa keuntungan dari sistem potensial akan menentukan cost
Spesifikasi sistem
Kebanyakan metodologi pembangunan sistem berguna untuk membedakan antara definisi dari user requirement dan desain dari dokumen yang mana requirement tersebut harus terpenuhi. Usaha untuk mengimplementasi proposal desain yang berbeda perlu diestimasi. Estimasi pada tahap desain akan mengkonfirmasikan bahwa feasibility study tetap valid.
Evaluasi dari proposal supplier
Perencanaan Proyek
Perencanaan dan implementasi dari perkembangan proyek ke level yang lebih detail, estimasi yang lebih detail dari komponen pekerjaan yang lebih kecil harus dilakukan. Semakin dini estimasi yang dilakukan, ini akan membantu memberi informasi seperti kapan staff dapat menyelesaikan perkerjaannya dan available untuk aktivitas yang baru.

2 point umum yang dapat ditangkap disini adalah :

Untuk memulai proyek, sehingga akurasi dari estimasi harus ditingkatkan sebagai pengetahuan tentang nature of project meningkat.
Kebijakan yang konvensional adalah pada saat permulaan dari proyek, user requirement adalah yang sangat penting dan pertimbangan yang premature dari implementasi fisik dapat dihindari. Urutan untuk menghasilkan estimasi, estimator akan berspekulasi tentang implementasi fisik ( jumlah komponen software yang ditulis)

5.3 Problem with over- and under-estimates
over estimates menyebabkan projek akan lebih lama. Ini dapat dijelaskan dengan aplikasi dua “Law” berikut :

“Parkinson Law” ‘works expands to fill the time available’ ini memberikan target yang mudah sehingga staff bekerja kurang keras.
“Brooks Law” ‘putting more people on a late work makes it later” jika terdapat over estimates dari usaha yang dibutuhkan maka dapat menambah staff yang diperlukan dan managerial overhead akan meningkat. Ini biasanya pada proyek yang besar

Beberapa saran mengatakan bahwa proyek under-estimates mungkin tidak selesai on time atau tidak sesuai dengan biayanya, itu mungkin masih bisa diimplementasi dalam waktu yang lebih pendek dibandingkan dengan estimasi yang baik.

Bahayanya dengan under-estimates adalah berefek pada kualitasnya. Manifestasi dari under-estimates adalah “Weinberg’s zeroth Law” ‘if system does not have to be reliable, it can meet any other objective.

5.4 The basis for software estimating
The need for historical data
Semua metode estimasi membutuhkan informasi bagaimana proyek diiplementasikan pada masa yang lalu. Bagaimanapun, perhatian diperlukan untuk menentukan data yang dapat dipakai dalam pertimabangan proyek karena kemungkinan perbedaan pada faktor lingkungan seperti bahasa pemrograman, software tool, menjalankan standart, dan pengalaman dari staff

Measure of Work
Waktu yang diperlukan untuk menulis program bermacam-macam, salah satunya tergantung dari kompentensi atau pengalaman dari software developer. Waktu implementasi juga bermacam-macam karena faktor lingkungan seperti software tool yang dapat digunakan. Biasanya untuk menyatakan work content dari aplikasi yang diimplementasi secara independen menggunakan Source Line of Code (SLOC).

Untuk SLOC merupakan pengukuran yang tidak teliti. Apakah komentar akan termasuk dihitung? Apakah deklarasi juga termasuk?para peneliti tdak konsisten pada poin ini. ini tergantung dari menurut penulis, kalau comment line tidak termasuk, kalau deklarasi maka akan termasuk yang dihitung.

Perhitungan SLOC adalah sulit dimana aplication-building tool berupa tabel, diagram untuk menyimpan processing rule. Pengukuran yang berbeda untuk ukuran diperlukan seperti function point.

Complexity
Dua buah software dengan KLOC yang sama akan memakan waktu yang tidak sama., walau dengan programmer yang sama dan lingkungan yang sama. Salah satu komponen mungkin lebih komplek. Usaha estimasi berdasarkan SLOC mungkin dimodifiaksi untuk disimpan pada account. Telah dilakukan percobaan untuk menemukan pengukuran dari kompleksitas, akan tetapi itu masih tergantung pada pendapat yang subyektif dari estimator

5.5 Software effort estimation techniques
Barry Boehm, pada pekerjaan klasiknya pada software effort model, identifikasi jalur utama untuk memperoleh estimasi dari software development effort adalah :

algorithm model, yang mana menggunakan “effort drive” untuk merepresentasikan karakteristik dari target sytem dan implementasi lingkungan untuk memprediksi usaha/effort
expert judgement, dimana mengumpulkan staff yang lebih banyak
analogy, dimana kesamaan, kelengkapan, proyek yang diidentifikasi, dan usaha yang sebenarnya adalah digunakan sebagai basis dari estimasi untuk proyek yang baru
parkinson, yang mana mengidentifikasi staff effort yang available untuk melakukan proyek dan menggunakannya untuk estimasi
price to win, dimana estimasi adalah harga yang muncul cukup rendah untuk memenangkan kontrak
top-down, dimana keseluruhan estimasi diformulasikan untuk keseluruhan proyek dimana kemudian dipecah menjadi usaha yang dibutuhkan untuk komponen task
bottom up, dimana komponen task diidentifikasi dan diukur kemudian estimasi individual ini digabungkan.

Bottom-up estimating
Pendekatan bottom-up estimator, memecah proyek menjadi komponen task dan kemudian mengestimasi berapa banyak usaha yang dibutuhkan untuk setiap tasknya. Untuk proyek yang besar, proses breaking down akan dilakukan repetisi, setiap task akan dianalisa pada tiap komponen subtask. Repetisi ini dilakukan hingga komponen dapat dieksekusi oleh satu orang dalam satu atau dua minggu. Bagian dari bottom-up ditambahkan untuk mendapatkan kalkulasi usaha setiap aktivitasnya untuk mendapatkan estimasi keseluruhan

The top-down approach and parametric models
Pendekatan top-down berasosiasi dengan model parametric ( atau algoritma ). Ini dapat dijelaskan dnegna mneggunakan analogi membangun sebuah rumah. Pada prakteknya pemilik rumah memerlukan jaminan yang cukup jika propertinya rusak. Kecuali pemilik rumah membeli rumah maka akan memperkirakan mempekerjakan berapa banyak tukang batu, tukan kayu, tukang listrik dan seterusnya.

Usaha yang diperlukan untuk mengimplementasi proyek akan berhubungan dengan variabel yang berasosiasi dengan karakteristik dari final system. Formulasinya :

Effort = (system size) * (productivity rate)

Sebagai contoh, ukuran sistem mungkin berbentuk “ribuan baris kode” (KLOC) dan memiliki 3 KLOC spesifik dan produktivitasnya 40 hari/KLOC. Nilai ini seringkali menjadi bahan pertimbangan.

Sebuah model untuk meramalkan software development effort memiliki 2 komponen utama. Pertama, sebuah metode menilai ukuran dari software development task dapat dilakukan. Kedua, menilai kecepatan kerja pada task yang dapat dilakukan.

Beberapa parameter model, seperti function point, fokusnya pada system atau ukuran task, sedangkan COCOMO pada faktor produkvifitas.

Aplikasi yang dibangun itdak menggunakan kode prosedura;, ukuran driver mungkin berbeda tipe komponen. Contoh, dimana microsoft access digunakan, estimator akan menghitung table, form, function, query, report dan seterusnya.

5.6 Expert judgment
ini dugunakan untuk estimasi task effort dari seseorang yang memeniliki banyak pengalaman tentang aplikasi atau development environment. Metode ini sering digunakan ketika estimasi effort diperlukan untuk merubah bagian software yang telah ada. Estimator akan membawa beberapa analisa pengaruh untuk menilai proporsi dari kode yang terpengaruh untuk memperoleh estimasi. Sesorang yang telah terbiasa dengan software adalah posisi yang terbaik untuk melakukan ini.

5.7 Estimating by analogy
Penggunaan analogi sering disebut “case-based reasoning”. Estimator akan mencari proyek yang telah sempuna (source access) dan memiliki kesamaan karakteristik pada proyek yang baru (target case). Usaha yang telah terekam pada source code yang kurang lebih sama, maka dapat dijadikan sebagai dasar estimasi target. Estimator akan mengidentfikasi setiap perbedaan antara target dan source dan membuat penyesuaian pada dasar estimasi untuk menghasilkan estimasi usaha pada proyek yang baru.

Ini dapat menjadi pendekatan yang baik dimana anda mempunyai informasi tentang proyek sebelumnya akan tetapi tidak cukup untuk menggambarkan kesimpulan umum.
Masalahnya adalah bagaiamana anda mengidentifikasi persamaan dan perbedaan antara aplikasi yang berbeda, terutama jika anda memiliki proyek yang besar pada masa lalu. Untuk mempermudah dapat menggunakan ANGEL software tool. Ini mengidentifikasi source case yang paling dekat dengan target dengan mengukur euclidean distancenya. Euclidean distance adalah sebagai berikut :

Distance = square-root((target_parameter1 – source_parameter1)^2 + .....(taget_parameter2 – source_parameter2)^2)

5.8 Albrecht function point analyis
model top-down ditemukan oleh Allan Albrecht ketika ia bekerja pada IBM. Untuk mengukur ukuran fungsional dari program independen maka menggunakan function point(FPs)

Dasar dari analisa sfunction point sistem informasi berbasis komputer terdiri dari 5 komponen utama :

external input types
input transaksi mengupdate file komputer internal
external output types
transaksi dimana data adalah output kepada user. Biasanya berupa printed report.
logical internal file types
file yang digunakan oleh sistem
external interface file types
mengijinkan input dan output yang mana meninggalkan ke atau dari aplikasi komputer yang lain.
external inquiry types
transaksi yang dimulai oleh user yang menyediakan informasi tetapi tidak mengupdate internal file.

Tabel 5.2 Albrecht complexity multipliers

Setiap komponen kemudian diklasifikasi terhadap kompleksitas yang tinggi, rata-rata atau rendah. Perhitungan setiap tipe user external pada setiap kompleksitas dikalikan dengan bobot yang spesifik ( table 5.2 )untuk mendapatkan score FP dengan dijumlahkan untuk mendapatkan keseluruhan perhitungan FP yang mengidentifikasi ukuran information processing.

Salah satu masalah menentukan tipe user eksternal adalah tinggi, rata-rata, rendah adalah lebih subjektif. International FP User Group (IFPUG) mengeluarkan aturan untuk penentuan ini. Contohnya, pada kasus logical internal file dan esternal interface file, batasnya ditunjukkan pada tabel 5.3 yang digunakan untuk menentukan kompleksitas level.

Table 5.3 IFPUG file type complexity

Tabel 5.4 IFPUG External input complexity

Table 5.5 IFPUG External output complexity

Tabel 5.4 dan 5.5 digunakan untuk skala eksternal input dan eksternal output. Setiap eksternal inquiry telah dihitung jika eksternal input dan eksternal output yang mana score yang digunakan lebih tinggi.

5.9 Function Point Mark II
Pendekatan Mark II metode yang bagus untuk structured system analyst and design methode (SSADM). Mark II menyatakan peningkatan dan penggantian dari metode Albrecht. Seperti pada Albrecht, informasi processing size diukur pada Unadjusted function point(UFP) yang mana technical complexity adjustment dapat (TCA) diaplikasikan. Asumsinya adalah sistem informasi terdiri dari transaksi, struktur dasarnya pada gambar 5.2

Gambar 5.2 Model of Transaction

Setiap transaksi UFP dihitung :

Wi * (jumlah dari input data element types) + We * (jumlah dari entity type referenced) + Wo*(jumlah dari output data element types)

Wi, We, Wo adalah bobot yang diperoleh dengan bertanya ke developer berapa proporsi effort yang telah dikeluarkan pada project yang lalu pada bagian tersebut. Dari sini dapat diambil average hour daro pekerjaan untuk tiap tipe elemen.

Average kemudian dinormalisasi ke rasio, atau bobot, yang ditambahkan hingga 2.5. Jika cara ini membutuhkan waktu yang lama, maka beberapa industri mengambil 0.58 untuk Wi ,1.66 untuk We ,0.26 untuk Wo.

Mark II FPs mengidentifikasi 5 faktor :

interface to other application
special security features
direct access for third parties
user training features
documentation requirement

Dengan metode Albrecht dan symons, FP dapat dihitung untuk project sebelumnya dimana effortnya diketahui. Jika anda mempunyai gambaran untuk effort yang dikembangkan dari proyek yang lalu dan juga system size pada FP, anda seharusnya dapat menghasilkan pruductivity rate :

productivity = size / effort

Untuk proyek yang baru, function point dapat dihitung dan kemudian effort dapat diproyekkan menggunakan productivity rate yang diperoleh dari :

effort = size / productivity

Dengan teknik statistik least squares regression untuk mendapatkan rumus pada form :

effort = constant1 + (size * constant2)

5.10 COSMIC Full Function Points
untuk menggunakan function point approach secara efektif, organisasi perlu mengkakses historical information pada proyek yang lalu, pada jumlah tertentu dari function point untuk setiap proyek dan actual effort yang dibutuhkan. Mungkin juga membutuhkan informasi yang lain tentang karakteristik dari proyek, seperti perbdaan tipe dari proyek akan menghasilkan produktivitas rate yang berbeda

contoh, beberapa menyarankan bahwa pendekatan seperti IFPUG cocok untuk sistem informasi, tetapi tidak membantu ketika aplikasi yang realtime dan embeded. Sehingga dibangun versi yang lain dari function point – COSMIC FFP method. Full istiFunction Point (FFP)merupakan perluasan dari IFPUG yang dapat digunakan untuk real-time system dan hasilnya lebih akurat.

Pada metode function point yang ada membuat fair job dari menilai pekerjaan dengan konten business-oriented information system, karena di sistem tersebut ukuran dari prosedur internal merefleksikan sejumlah fitur eksternal dari berbagai tipe. Pada real time dan embeded system, fitur ini akan tersembunyi karena software user mungkin bukan manusia tetapi hardware device atau komponen software yang lain.

COSMIC membutuhkan analisis untuk memecah sistem arsitektur ke bentuk hirarki software layer. Komponen software dapat menerima request untuk service dari layer diatasnya dan dapat request service dari layer dibawahnya. Pada waktu yang sama, dapat memisahkan komponen software pada level yang sama yang menggunakan komunikasi peer-to-peer. Ini membantu untuk mengidentifikasi batas dari komponen software yang dinilai dan point tersebut menerima input dan mengirimkan output. Input dan output digabungkan dalam data group, dimana setiap grup membawa bersama data item yang berhubungan dengan object of interest yang sama.

Data group dapat dipindahkan dengan 4 cara :

entries(E)
yaitu berefek dengan sub proses yaitu memindahkan data group ke komponen software dari pertanyaan dari ‘user’ diluar boundariesnya
exits(X)
yaitu berefek dengan sub proses yaitu memindahan data group dari komponen software ke ‘user’ diluar boundariesnya.
reads(R)
pergerakan data yaitu memendahkan data group dari persistent storage(database) ke komponen software
writes(W)
pergerakan data yang mana mentransfer data group dari komponen software ke persistent storage

5.11 A Procedural code-oriented approach
Pendekatan sebelumnya berguna pada tahap desain dan dimana bahasa pemrograman prosedural bukan cara yang utama untuk development. Bagaimanapun, bagaimana nada dapat mengestimasi effort untuk membangun secara individu modul software menggunakan bahasa prosedural? Pendekatan adalah sebagai berikut :

mempertimbangkan jumlah dan tipe modul software pada final system
Yang paling adalah dimana sistem adalak konvensional dan mudah dipahami. Kebanyakan sistem informasi dibangun dari sistem operasi yang kecil, yaitu Insert, Amend, Update, Display, Delete, Print.
estimasi SLOC dari setiap program yang teridenfikasi
Estimator harus mempunyai bahasa imlementasi tertentu dalam pikirannya untuk tahap ini. Salah satu jalan untuk mempertimbangkan jumlah instruksi dalam program digambarkan dalam program structure diagram dan untuk visualisasi berapa banyak instruksi yang dibutuhkan untuk mengimplementasi setiap prosedur yang ada. Estimator akan melihat program yang ada yang memiliki dskripsi fungsional yang mirip untuk membantu proses ini
estimasi pekerjaan yang dilakukan pada account kompleksitas dan tingkat kesulitan teknis
Dalam praktisnya dengan mengalikan estimasi SLOC dengan faktor kompleksitas dan tingkat kesulitasn teknis. Faktor ini akan tergantung pada besarnya pertimbangan subyektif dari estimator. Contohnya, requirement yang memiliki banyak constraint akan membutuhkan programming effort yang lebih banyak
Pembobotan dapat diberikan ketika terdapat ketidakpastian, contohnya, teknik baru yang digunakan pada modul tertentu. Dimana terdapat ketidakpastian yang besar maka pengukuran yang spesifik harus dilakukan untuk mengurangi yaitu dengan menggunakan penyelidikan prototypes
mengkalkulasi work-day effort
historical data dapat digunakan untuk menyediakan rasio untuk mengkonversi bobot SLOC ke effort. Konversi faktor ini sering berdasarkan pada produktifitas dari standart programming yaitu pengalaman 15-18 bulan.

5.12 COCOMO : a parametric model
Boehm’s COCOMO ( COnstructive COst Model ) sering dirujuk pada literatur pada software project management, terutama berhunbungan dengan estimasi software.
Model dasar dibangun dengan rumus :

(effort) = c ( size)^k

dimana effort diukur dalam ppm atau jumlah dari “person-month” yang terdiri dari unit dari 152 working-hours, size diukur dalam kdsi ( thousands of delivered source code instruction ), c dan k adalah konstanta.

Langkah awal untuk mendapatkan estimasi dari ukuran sistem dalam kdsi. Konstanta c dan k ( tabel 5.6 )tergantung pada sistem dapat diklasifikasikan pada istilah Boehm’s, yaitu “organic”, “semi-detach”, “embeded”.

Organic mode
Ketika tim kecil development software sangan familiar dengan in-house environment dan sistem yang dibangun kecil dan interface requirement fleksibel
Embeded mode
Produk yang dibangun dioperasikan dengan batasan yang ketat dan perubahan pada sistem sangat mahal
Semi-detach mode
Kombinasi dari oraganic dan embeded atau memiliki karakteristik dari keduanya

Eksponen dari nilai k ketika lebih besar dari 1, berarti proyek yang lebih besar dapat dilihat sebagai ketidakseimbangan membutuhkan lebih banyak effort. Ini merefleksikan penemuan Boehm bahwa proyek yang lebih besar cenderung kurang produktif dibandingkan dengan yang lebih kecil karena membutuhkan effort yang lebih banyak untuk management dan koordinasi..

Tabel 5.6 COCOMO konstanta

Oleh karena itu nominal estimasi disesuaikan dengan membangun effort multiplier (dem) :

(pm_est) = (pm_nom) * (dem)

Multiplier ini memberi dampak pada pengurangan effort hingga 20% dengan tim yang mengenal bahasa pemrograman yang dibpakai jika dibandingkan dengan tim yang tidak familiar dengan bahasa yang digunakan. Pada faktanya, pengaruh yang paling besar terhadap produktivitas adalah kemampuan dari tim implementasi.

Contoh pendekatan, pengunaan multiplier untuk assessing the effect of analysis capability (ACAP) :
Very low 1.46
Low 1.19
Nominal 1.00
High 0.8
Very High 0.71

Tabel 5.7 COCOMO81 intermediate cost Driver

Keseluruhan dem dikalkulasi dengan mengalikan dengan multiplier yang dipilih untuk setiap cost driver pada table 5.7 untuk menghasilkan single combined multiplier

Pada COCOMO II, pendekatan ini menggunakan multiplier yang bervariasi dan nilai eksponen yang telah diset oleh expert pada inisial. Estimasi dibutuhkan pada tahap yang berbeda pada sistem life cycle dan COCOMO II yang telah didisain untuk mengakomodasi ini dengan model untuk 3 tahap yang berbeda :

Application composition
Ini adalah fitur eksternal dari sistem didisain yang mana user telah berpengalaman.
Early design
Ini adalah fundamental software structure yang didisain
Post achitecture
Ini adalah software structure yang dalam tahap final construction, modifikasi, tuning untuk menghasilkan sistem yang diinginkan

Untuk estimasi effort untuk application composition, perhitungan dari object point direkomendasikan oleh developer COCOMO II. Ini mengikuti function point approach untuk perhitungan external fitur yang terlihat dari software.

Pada tahap early design, FP direkomendasikan sebagai jalan untuk pengukuran basic system size. Perhitungan FP dapat dikonversi ke LOC yang equivalent dengan mengalikan FP dengan faktor untuk bahasa pemrograman yang digunakan.

Model berikut ini dapat digunakan untuk menghitung estimasi person-month :

pm=A(size)(sf)*(em1)* (em2)*..... (emn)

dimana pm adalah effort person-month, A adalah konstanta (pada 1998, 2.45), size diukur dalam kdsi, sf adalah exponent scale factor

scale factor diperoleh dari :

sf=1.01 + 0.01*Σ(exponent driver rating)

pada COCOMO II effort multiplier (em) mirip dengan development effort multiplier (dem) yang digunakan pada COCOMO. Terdapat 7 multiplier yang relevan ada early design dan 16 yang dapat digunakan pada tahap post architecture

Tabel 5.8 COCOMO II Early design effort Multiplier