Kesimpulan - Software Effort Estimation -

kesimpulan yang bisa diambil dari bab 5 tentang Software effort estimation adalah membandingkan antara teori dan praktek dalam estimasi effort yang dibutuhkan. hasil yang diperoleh dari estimasi tersebut bisa sama(kurang lebih) bisa jauh berbeda. jika terdapat perbedaan yang begitu jauh maka dapat dilakukan perbaikan pada metode yang digunakan.

terimakasih
kami ucapkan pada bapak Fajar Baskoro yang telah mengajarkan kami pada mata kuliah Manajemen Proyek Perangkat Lunak(MPPL) serta Rekayasa Perangkat Lunak Lanjut (RPLL).
Kami menyadari bahwa Mahasiswa Beasiswa Unggulan banyak kekurangan yang mungkin menyakiti bapak fajar kami ucapkan minta maaf sebesar-besarnya. semoga ilmu yang diajarkan mendapatkan barokah serta amal jariyah yang senantiasa mengirimkan pahala kepada beliau.
kami keluarga besar Beasiswa Unggulan teknik Informatika 06 ucapkan terima kasih sebesar-besarnya.

wassalam

Contoh Effort Estimation pada SIstem Informasi Daerah

Berdasarkan proposal penawaran oleh PT. ZAQINA PRIMA KARSA kepada pemerintah daerah tentang pengadaan Sistem Informasi Daerah – SIMDA Pemerintahan Daerah tingkat I/II (terlampir). Untuk menganalisa berapakah effort yang dibutuhkan untuk membangun aplikasi sistem informasi daerah dengan menggunakan COCOMO adalah sebagai berikut :

Menentukan UFP (Unadjusted Function Point)
Seperti yang dijabarkan diatas, UFP terdiri dari 5 komponen. Tabel dari 5 komponen tersebut dapat dilihat dibawah.

Pada SIMDA maka dapat diambil analisa sebagai berikut :
Jenis Komponen klasifikasi bobot jumlah

1.Eksternal Input Simple 3 x 5 = 15
2.Eksternal Output Simple 4 x 5 = 20
3.User Average 4 x 10 = 40
4.Files Complex 15 x 20 = 300
5. External Interface Complex 10 x 10 = 100
Total UFP 475

Menentukan kompleksitas
Pada kompeksitas didapatkan dari perhitungan technical complexity factor (TCF). Pada TCF terdapat 14 pertanyaan yang harus diberi nilai. Pertanyaan itu adalah dari E1 hingga 14. Dari tiap pertanyaan dibawah harus diberikat bobot antara 0 hingga 5. Untuk penjelasan penentuan bobot dapat dilihat pada gambar dibawah ini.

Untuk analisa pada SIMDA untuk TCF adalah sebagai berikut
Kode Keterangan Bobot
E1 Backup dan recovery dapat dipercaya 5
E2 Komunikasi data 4
E3 Fungsi distribusi 3
E4 Performansi 5
E5 Lingkungan operasional 3
E6 Data entry on-line 3
E7 Layar interaktif untuk input 4
E8 On-line update 2
E9 Kompleksitas interface 5
E10 Bisa digunakan kembali (reusability) 4
E11 Kompleksitas proses 5
E12 Kemudahan dalam install 5
E13 Memiliki banyak site 5
E14 Mudah digunakan 4
TOTAL = 57

Menentukan FP (Function Point)
Untuk mendapatkan nilai FP (function Point) dengan menggunakan rumus

FP = UFP x (0.65+0.01 x TCF )

Dari perhitungan diatas diketahui,
UFP = 475
TCF = 57

Maka FP adalah sebagai berikut :
FP = 475 x ( 0.65 + 0.01 x 57 )
FP = 475 x ( 0.65 + 0.57 )
FP = 475 x (1.22)
FP = 579,5

Konversi FP ke NCSS ( bahasa pemrograman yang digunakan )
Setelah FP diketahui, maka pada tahap implementasi harus ditentukan penggunaan bahasa pemrograman. Maka untuk mengkonversi dari FP ke NCSS adalah berdasarkan tabel dibawah ini :



Jika pada tahap implementasi SIMDA, bahasa pemrograman yang digunakan adalah C maka konversi ke NCSS adalah sebagai berikut :
Size = FP x NCSS
Size = 579,5 x 70
Size = 40565
atau
Size = 40,565 KDSI

Menentukan tipe proyek ( berdasarkan COCOMO)
Tipe proyek pada COCOMO ada 3 buah, yaitu organic, semi-detached, dan embeded. Pada SIMDA, tipe proyek yang dikerjakan adalah semi-detach, karena memiliki sistem yang komplek akan tetapi bukan sebuah proyek yang baru. Tim yang mengerjakan adalah bisa tenaga yang berpengalaman dan tenaga yang kurang pengalaman.

Dengan tipe proyek adalah semi-detached maka konstanta :
a = 3.0
b = 1.12
karena proyek SIMDA merupaka proyek yang besar, maka perumusan untuk effortnya adalah sebagai berikut :

EFFORT = EAF x a x (SIZE) ^ b

Menentukan EAF (Effort Adjusted Factor )
Jenis-jenis EAF dapat dilihat dari gambar dibawah ini :

Karakteristik dari proyek SIMDA adalah sebagai berikut :
1. Require software reliability : high 1.15
2. Database size : high 1.08
3. Product complexity : v.high 1.30
4. Main storage constraint : nominal 1.00
5. Computer turnaround time : low 0.87
6. Analyst capability : high 0.86
7. Application experience : Nominal 1.00
8. Programmer capability : high 0.86
9. Programming language experience : nominal 1.00
10. Use of software tools : high 0.91
11. Required development schedule : nominal 1.00

Dari analisa di atas, maka dapat dihitung EAF dengan mengalikan semuanya. Perhitungannya adalah sebagai berikut :


EAF = 1.15 x 1.08 x 1.30 x 1.00 x 0.87 x 0.86 x 1.00 x 0.86 x 1.00 x 0.91 x 1.00
EAF = 0.945


Didapatkan effort yang dihasilkan
Setelah EAF, a, b, size diketahui, maka effort yang diperlukan untuk membangun sebuah software dapat dihitung. Perhitungannya adalah sebagai berikut :
EFFORT = EAF x a x SIZE b
EFFORT = (0.945) x (3.00) (40,5)1,15
EFFORT = 200

Sehingga dapat diambil kesimpulan untuk membangun software SIMDA maka memerlukan effort sebesar 200 PM (Person Month)



Durasi
Durasi adalah waktu yang diperlukan untuk membangun sebuah software SIMDA adalah sebagai berikut :

Berdasarkan perumusan diatas, bahwa tipe proyek SIMDA adalah semi-detached maka, perhitungan durasinya adalah seabgai berikut :

DURASI = 1.5 x EFFORT 0.35
DURASI = 1.5 x (200)0.35
DURASI = 15,9

Maka dapat diambil kesimpulan dari perhitungan diatas maka waktu yang diperlukan untuk membangun software SIMDA adalah 16 bulan

Staffing
Staffing adalah jumlah orang yang dibutuhkan untuk memebangun software SIMDA. Perhitungan staffing adalah sebagai berikut :

STAFFING = EFFORT / DURASI
STAFFING = 200 / 15,9
STAFFING = 12,57

Berdasarkan perhitungan diatas, maka dapat diambil kesimpulan bahwa untuk menghasilkan sebuah software SIMDA membutuhkan 13 orang

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) + W­e * (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

Table 5.9 COCOMO II Post architecture effort multiplier

Linux vs. Windows - TCO Comparison

SUMMARY
TOTAL COST COMPARISON

One compares the TCO difference between Standard Linux (namely the one that isn't acquired with a prepaid
support contract) and Microsoft's platform. The second compares Red Hat's managed Enterprise Linux and Microsoft's platform. Both models include costings for deployment on either a site's existing equipment or through a complete hardware refresh.

Windows Platform Solution
For our Windows platform solution, we have selected the following operating systems, backoffice technologies and office productivity tools.


Linux Platform Standard Solution
For our standard Linux platform solution, we have selected the following open source backoffice technologies and office productivity tools.

18 Price obtained from reseller (freesoftwarecdr.com).
19 Price obtained from reseller (freesoftwarecdr.com).
20 Figure obtained from netcraft.com.

NB: As Linux is generally taken to be immune from viruses in general, and from Windows viruses specifically, we have not added any virusscanning software to this list.

Linux Platform Enterprise Solution
For our enterprise level Linux solution, we have selected the following open source backoffice technologies and office productivity tools. The primary difference between the Enterprise Linux solution and the standard one is the incorporation of an ongoing support contract with the Linux vendor. The Red Hat Enterprise Linux solution is based on an annual subscription model and three (3) years' worth of annual subscriptions will need to be included in the cost.

NB: As Linux is generally taken to be immune from viruses in general, and from Windows viruses specifically, we have not added any virusscanning software to this list.

Perbedaan Linux Vs Windows (3)

Partisi Harddisk
Linux tidak mengenal penamaan drive C: untuk suatu partisi. Semua drive disatukan dalam suatu sistem penyimpanan yang besar. Folder /mnt merupakan tempat untuk Anda mengakses semua media yang ada di komputer, baik partisi lain, CD-ROM, Floppy, ataupun FlashDisk.

Belakangan KDE telah memperudah akses ke media dengan menyediakan sistem Storage Media yang dapat diakses melalui My Computer ataupun file manager Konqueror.

Penamaan File
Linux menggunakan “/” untuk memisahkan folder dan bukannya “\” yang biasa digunakan DOS/Windows. Linux bersifat case-sensitive, ini berarti file “Hello.txt” berbeda dengan file “hello.txt”. Linux juga tidak terlalu memperhatikan ekstensi file. Jika Anda mengubah nama file “Hello.txt” menjadi “Hello”, Linux masih tetap mengetahui bahwa file ini adalah suatu teks. Dan ketika Anda mengklik file “Hello”, Linux secara otomatis tetap akan membuka program editor teks.

Kemudahan dan Keamanan
Anda mungkin sudah mengetahui, bahwa sebagai user biasa (bukan Root) Anda tidak bisa menulis file di sembarang folder. User biasa hanya memiliki akses tulis di folder home mereka. Sebagai user biasa, Anda tidak akan bisa mengubah bagian penting dari sistem Linux. Ini memang terkesan terlalu membatasi dan merepotkan, tetapi cara ini jauh lebih aman, karena hanya orang tertentu yang mempunyai akses Root saja yang bisa menyentuh sistem. Bahkan viruspun tidak bisa dengan mudah menyentuh sistem Linux. Itu sebabnya Anda tidak banyak mendengar adanya virus di Linux.

PENTING !!! PENTING !!! PENTING !!!
Itu sebabnya di Linux, Anda tidak disarankan menggunakan user Root untuk keperluan sehari-hari. Buatlah minimal 1 user untuk setiap komputer dan hanya pergunakan Root untuk keperluan administrasi sistem.

Hal ini berbeda jauh dengan Windows yang sangat rentan dengan virus. Ini terjadi karena user biasa di Windows juga sekaligus mempunyai hak sebagai administrator. Kebanyakan pemakai Windows tidak mengetahui hal ini, sehingga sistem mereka sangat rentan dengan serangan virus. Windows Vista sekarang telah mengadopsi sistem sekuriti Linux ini.


Defragment
Di Linux Anda tidak akan menemukan program untuk men-defrag harddisk. Anda tidak perlu melakukan defragment di harddisk Linux! Sistem file Linux yang menangani ini secara otomatis. Namun jika harddisk Anda sudah terisi sampai 99% Anda akan mendapatkan masalah kecepatan. Pastikan Anda memiliki cukup ruang supaya Linux menangani sistemnya dan Anda tidak akan pernah mendapatkan masalah deframentasi.

Sistem File
Windows mempunyai dua sistem file. FAT (dari DOS dan Windows 9x) dan NTFS (dari Windows NT/2000/XP). Anda bisa membaca dan bahkan menyimpan file di sistem FAT dan NTFS milik Windows. Hal ini tidak berlaku sebaliknya, Windows tidak akan bisa membaca atau menyimpan file di sistem Linux.

Seperti halnya Windows, Linux memiliki beberapa macam file sistem, diantaranya ReiserFS atau Ext3. Sistem ini dalam beberapa hal lebih bagus dari FAT atau NTFS milik Windows karena mengimplementasikan suatu tehnik yang disebut journaling. Jurnal ini menyimpan catatan tentang sistem file. Saat sistem Linux crash, kegiatan jurnal akan diselesaikan setelah proses reboot dan semua file di harddisk akan tetap berjalan lancar.

Perbedaan Linux Vs Windows (2)

Instalasi dan Kelengkapan Program
Windows adalah sistem operasi, itu sebabnya Windows tidak menyediakan banyak program setelah diinstal. Kalaupun ada mungkin Anda hanya akan menemukan Internet Explorer, Media Player, Notepad, dan beberapa program kecil lainnya.

Ini sangat berbeda dengan Linux. Sekalipun Linux juga suatu sistem operasi, tetapi Linux disertai dengan banyak program didalamnya. Setelah diinstal, Anda akan menemui banyak program dari hampir semua kategori program. Sebut saja kategori Office Suite, Multimedia (Sound, Video, Graphics), Internet (Browser, Email, Chat, Downloader, Messenger, Torrent, News), 3D, Games, Utility, dll.

Dengan waktu instalasi yang hampir sama, Anda bukan hanya mendapatkan suatu sistem operasi tetapi juga semua program yang diperlukan untuk kegiatan sehari-hari di Linux.

Konfigurasi Sistem
Anda mungkin sering mendengar di Linux Anda perlu menyunting file secara manual melalui command line. Sebagian berita ini benar, tetapi dengan PCLINUX Control Center konfigurasi sistem bisa Anda lakukan semudah point n click. PCLINUX memiliki deteksi perangkat keras yang baik sehingga hampir semuanya berjalan secara otomatis. Dan hampir semua program di PCLINUX disertai dengan konfigurasi yang sudah siap pakai. Sebagai contoh, browser Internet telah disertai dengan sejumlah plug-ins. Tidak perlu men-download dan menginstal plug-ins flash ataupun yang lainnya.

Hardware Support
Anda sering mendengar suatu hardware tidak bekerja di Linux. Hal ini terjadi karena pembuat hardware tidak menyediakan driver versi Linux. Untungnya, belakangan ini cukup banyak vendor yang sudah memberikan dukungan driver Linux. Dan pengenalan Linux akan hardware semakin lama semakin meningkat sehingga mulai jarang terdengar permasalahan hardware di Linux.

Menangani Crash
Linux secara umum terlihat sebagai sistem operasi yang stabil. Dan jika Anda membandingkan Linux dengan Windows 95/98/ME, Linux jauh lebih stabil. Windows XP – jika Anda mengikuti petunjuk sistemnya dengan baik – akan cukup stabil.

Dan seperti halnya dengan Windows, suatu saat Anda juga akan menemui masalah di Linux. Sekalipun jarang, tetapi program yang crash atau hang bisa saja terjadi. Ini adalah suatu fakta dari kehidupan di dunia komputer.

Sekalipun demikian ada beberapa perbedaan di Windows dan Linux. Unix dan Linux mempunyai sifat multi-user. Linux menjalankan aplikasi secara berbeda dengan Windows. Ketika suatu aplikasi terkunci, Anda dapat mematikannya dengan mudah. Cukup menekan kombinasi tombol Ctrl + Esc, dan Anda dapat memilih aplikasi (atau proses) mana yang bermasalah.

Dan jika sistem grafis yang terkunci, Anda bisa berpindah ke command-prompt (dengan menekan Ctrl+Alt+F1) dan membunuh proses software secara manual. Anda juga mempunyai pilihan untuk merestart desktop saja dengan menekan Ctrl+Alt+Backspace. Ini berarti Anda tidak harus melakukan reboot sekalipun sistem Linux sedang mengalami masalah.

Perbedaan Linux Vs Windows (1)

Ada banyak persamaan dan ada pula banyak perbedaan antara Linux dan Windows. Mari kita lihat beberapa perbedaan yang ada di Linux dan Windows.

User Interface
Di Windows, Anda tidak banyak memiliki pilihan user interface. Sebagai misal, di Windows 95/98 Anda hanya mengenal user interface bawaan Windows 95/98. Anda sedikit lebih beruntung jika menggunakan Windows XP, karena Anda bisa berpindah dari interface milik Windows XP ke Windows 98 yang lebih ringan.

Di Linux, Anda bisa menemukan banyak macam user interface. Dan biasanya pilihan user interface ini dapat Anda sesuaikan dengan spesifikasi komputer atau lingkungan kerja Anda. Sebagai misal, pada komputer yang lambat Anda bisa menggunakan user interface yang ringan, seperti XFCE atau Fluxbox.

Atau jika Anda menyukai gaya Mac, Anda bisa memilih desktop model GNOME atau menggunakan utility Docker. Dan jika Anda terbiasa di Windows dan memiliki komputer yang cukup cepat, Anda bisa memilih desktop KDE.

Dengan KDE, Anda masih bisa memilih untuk menggunakan gaya Windows XP ataupun Windows Vista. Pilihan dan variasinya sangat banyak di Linux, Anda bisa mengatur sesuai dengan favorit Anda.

Sekuriti dan Virus
Salah satu masalah utama di Windows yang paling sering Anda temukan adalah virus dan spyware. Dari tahun ke tahun permasalahan ini bukan semakin mengecil tetapi malah semakin membesar. Ini semua terjadi karena banyak lubang keamanan di Windows yang bisa dieksploitasi oleh orang-orang yang tidak bertanggungjawab.

Linux diturunkan dari sistem operasi Unix yang memiliki tingkat sekuriti lebih kuat. Itu sebabnya tidak ada banyak virus di Linux dan kalaupun ada tidak bisa berkembang biak dengan pesat dan biasanya tidak mampu membawa kerusakan yang besar.

Sekalipun tidak sepenting di Windows, Anda tetap bisa menemukan program-program anti virus di Linux, seperti ClamAV dan F-Prot. PCLinux telah menyediakan anti virus ClamAV yang bisa ditemukan pada menu Start > Applications > FileTools > KlamAV.

Spyware
Spyware adalah suatu masalah yang cukup umum di dunia Windows. Biasanya program spyware mengamati, mengumpulkan dan mengirimkan data Anda ke suatu server. Untuk hal yang lebih positif, program ini biasanya dipergunakan untuk keperluan marketing.
Sayangnya, ada juga yang berniat buruk yaitu dengan mencuri identitas, kartu kredit, dan tindakan negatif lainnya.

Tidak banyak program spyware yang menginfeksi Linux mengingat cara kerja Linux yang lebih susah untuk ditembus. PCLinux telah menyediakan pre-instal Firewall untuk melindungi sistem Anda dan bisa diaktifkan melalui PCLinux Control Panel.