1. Carilah dan kemudian anda paparkan model-model yang dapat digunakan untuk

estimasi biaya pada suatu proyek Sistem Informasi

Teknik-Teknik Estimasi Biaya Sistem Informasi

A. SLIM (Software Life Cycle Management)

SLIM (Perangkat Lunak Manajemen Hidup Siklus)

SLIM adalah salah satu model algoritmik untuk estimasi biaya yang pertama. Hal ini didasarkan

pada fungsi / Norden Rayleigh dan umumnya dikenal sebagai model estimasi makro (Hal ini

untuk proyek-proyek besar). SLIM memungkinkan estimator biaya perangkat lunak untuk

melakukan fungsi-fungsi berikut:

Mengklalibari model dan menyesuaikan untuk mewakili lingkungan pengembangan

perangkat lunak lokal dengan cara menafsirkan histories database proyek-proyek masa

lalu.

Membangun model informasi dari sistem perangkat lunak, mengumpulkan karakteristik

perangkat lunak, dan atribut computer.

Menggunakan versi otomatis dari untuk menghitung baris kode (LOC)

Algoritma matematis yang digunakan

K = ( LOC / ( C * t4/3 )) * 3

K adalah siklus hidup usaha total tahun bekerja, t adalah pengembangan dan C adalah konstanta

teknologi, menggabungkan efek penggunaan alat, bahasa, metodologi dan jaminan kualitas

(QA). Nilai konstanta teknologi bervariasi antara 610-57314. Untuk mudahnya, suatu proyek

skala besar konstanta teknologinya pun tinggi.

Keuntungan SLIM

1. Menggunakan pemrograman linier untuk mempertimbangkan kendala pembangunan di

kedua biaya dan usaha.

2. SLIM memiliki parameter yang lebih sedikit untuk menghasilkan perkiraan / estimasi

dibandingkan dengan COCOMO'81 dan COCOMO'II

Kelemahan dari SLIM

1. Perkiraan terhadap faktor teknologi sangat sensitif

2. Tidak cocok untuk proyek kecil

B. Estimasi Bottom-Up

Pendekatan bottom-up memecah proyek ke dalam komponen-komponen tugasnya dan

kemudian menghitung berapa banyak biaya yang diperlukan untuk menyelesaikan  setiap tugas

tersebut.  Untuk proyek besar, proses pemecahan akan berulang hingga mendapatkan komponen

yang bisa dieksekusi oleh  satu orang selama 1 hingga 2 minggu.  Setiap komponen tugas

dianalisa hingga komponen sub tugasnya, yang menghasilkan Work Breakdown Schedule

(WBS). Bagian bottom-up muncul ketika terjadi penjumlahan biaya yang dihitung dari setiap

aktifitas untuk memperoleh estimasi keseluruhan. Pendekatan ini lebih cocok digunakan di

bagian akhir tahap perencanaan proyek. Jika digunakan pada awal siklus proyek, beberapa

karakteristik sistem final harus diasumsikan. 

C. Experd Judgement

Metode ini digunakan ketika melakukan estimasi biaya yang diperlukan untuk mengubah

sebagian software yang masih eksis. Estimator akan memberikan beberapa analisis dampak

berdasarkan pendapat yang proporsional dengan kode yang ditambahkan. Seseorang yang telah

terbiasa dengan software tersebut yang lebih tepat untuk mengerjakannya.  

D. Estimasi Dengan Analogi

Penggunaan analogi disebut juga case-based reasoning. Estimator mencari proyek-

proyek yang telah selesai dikerjakan (sumber) yang memiliki karakteristik hampir sama untuk

referensi proyek baru (target). Biaya yang telah dilaporkan yang sesuai dengan kasus sumber

dapat dijadikan pijakan estimasi proyek target. Estimator kemudian melakukan identifikasi

perbedaan sistem target dengan sumber, selanjutnya menetapkan estmasi dasar untuk

menghasilakan estimasi biaya proyek baru.  Masalahnya adalah bagaimana mengidentifikasi

kemiripan dan perbedaan yang sesungguhnya pada aplikasi yang berbeda, khususnya bila ada

banyak proyek masa lampau sebagai gambaran. Untuk mengidentifikasi sumber yang paling

dekat dengan target  biasanya menggunakan ukuran jarak Euclidian  : 

Distance = square-root of((target_parameter1 – source_parameter1)2 + …. + (target

_parametern – source_parametern)2)        

                                

E. COSMIC Full Function Points

Penggunaan pendekatan FP efektif digunakan pada organisasi yang mempunyai akses

informasi historis tentang proyek-proyek masa lampau, khusus perihal FP untuk setiap proyek

dan biaya aktual yang diperlukan. Metode pendekatan seperti IFPUG cocok untuk sistem

informasi, tetapi kurang membantu untuk aplikasi ukuran real-time atau aplikasi yang telah

canggih, maka  the Common Software Measurement Consorsium (COSMIC)  memasukkan tidak

hanya versi originalnya tetapi juga versi lain menjadi the COSMIC FFP method.   COSMIC

sepakat dengan kebutuhan analis untuk memecah arsitektur sistem ke dalam hirarki lapisan

software. Komponen software diukur dan menerima permintaan layanan dari lapisan diatasnya

dan bisa meminta layanan di bawahnya. Di saat yang sama, ada juga komponen software terpisah

yang berada dalam level sama  yang dihubungkan dalam peer-to-peer communication. Hal ini

membantu identifikasi batas komponen software yang diakses, jumlah input yang diterima dan

transmisi output. Input dan output dikumpulkan dalam data-group, dimana setiap group

membawa item data bersama  yang berkaitan dengan obyek yang sama.  Grup data  dapat

dipindahkan lewat 4 cara ;

1. Entri (E) : dipengaruhi oleh sub-proses yang memindahkan grup data ke dalam

komponen software atas permintaan user di luar lingkupnya, bisa dari lapisan lain atau

komponen software terpisah yang lain dalam lapisan yang sama lewat peer-to-peer

communication.

2. Exit (X) : dipengaruhi oleh subproses yang memindahkan grup data dari komponen

software ke user yang berada di luar batasan.

3. Read (R) : gerakan data yang memindahkan group data dari  storage tetap ke dalam

komponen software.

4. Write (W) : Perpindahan data yang mentransfer group data dari komponen software ke

dalam storage tetap.   

 Jumlah keseluruhan FFP diperoleh dari penjumlahan sederhana keempat tipe perpindahan data.

Unit yang dihasilkan disebut Cfsu (COSMIC functional size units). Metode ini tidak menghitung

lagi pemrosesan data yang pernah dipindahkan sekali ke komponen software.    

F.  Procedural Code-Oriented Approach

Pendekatan yang dibahas sebelumnya berguna pada tahap desain proyek dimana bahasa

pemrograman prosedural tidak merupakan sarana utama untuk pengembangan. Bagaimanapun

biaya pengembangan modul software individual bisa diestimasi menggunakan pendekatan

bahasa prosedural, dengan step-step sebagai berikut :

1. Pertimbangkan jumlah dan tipe modul software dalam sistem final.

Yang paling mudah, dimana merupakan sistem konvensional yang telah dipahami secara

baik. Semua sistem informasi dibangun dari satu set operasi kecil seperti Insert, Amend, Update,

Display, Delete, Print. Prinsip yang sama bisa diterapkan pada sistem terintegrasi (embedded),

walaupun fungsi primitifnya berbeda.  

2. Estimasikan jumlah SLOC setiap program teridentifikasi.

Estimator harus memilih bahasa implementasi tertentu. Untuk menaksir  jumlah instruksi

menggunakan bahasa tersebut, dengan cara menggambar diagram struktur program dan

memvisualisasikan berapa banyak instruksi yang diperlukan untuk implementasi setiap prosedur

teridentifikasi. Estimator mungkin harus melihat program eksisting yang mempunyai kemiripan

deskripsi fungsional untuk membantu proses ini.    

3. Estimasikan isi pekerjaan yang dimasukkan dalam perhitungan kompleksitas dan kesulitan

modul.

Prakteknya dengan mengalikan estimasi SLOC dengan faktor kompleksitas dan kesulitan

teknik. Faktor ini sangat tergantung pada penilaian subyektif estimator. Pembobotan diperlukan

ketika ada hal-hal yang tak bisa dipastikan, namun jangan berlebihan.  

4. Hitung biaya hari kerja

Data historis dapat digunakan untuk memberi rasio bobot  biaya SLOC. Faktor konversi

sering didasarkan produktifitas ‘standard programmer’  (kira berpengalaman 15 – 18 bulan)   

G. COnstructive COst MOdel (COCOMO)

COnstructive  COst  MOdel (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. 

1. Model COCOMO Dasar  

Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:

a) Proyek organik (organic mode) Adalah proyek dengan ukuran relatif kecil, dengan

anggota tim yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif

fleksibel.

b) Proyek sedang (semi-detached mode)Merupakan proyek yang memiliki ukuran dan

tingkat kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang

berbeda

c)  Proyek terintegrasi (embedded mode)Proyek yang dibangun dengan spesifikasi dan

operasi yang ketat 

Model COCOMO dasar ditunjukkan dalam persamaan 1, 2, dan 3 berikut ini:      

                                                                 

Dimana :

E          :  besarnya usaha (orang-bulan)

D         :  lama waktu pengerjaan (bulan)

KLOC  :  estimasi jumlah baris kode (ribuan)

P           :  jumlah orang yang diperlukan.  

Sedangkan koefisien  ab, bb, cb, dan db diberikan pada Tabel 1  berikut: 

Tabel 1 .  Koefisien Model COCOMO Dasar  

2. Model COCOMO Lanjut (Intermediate COCOMO) 

Pengembangan model COCOMO adalah dengan menambahkan atribut yang dapat menentukan

jumlah biaya dan tenaga dalam pengembangan perangkat lunak, yang dijabarkan dalam kategori

dan subkatagori sebagai berikut: 

a. Atribut produk (product attributes)

1. Reliabilitas perangkat lunak yang diperlukan (RELY)2. Ukuran basis data aplikasi (DATA)3. Kompleksitas produk (CPLX)

b. Atribut perangkat keras (computer attributes)

1. Waktu eksekusi program ketika dijalankan (TIME)2. Memori yang dipakai (STOR)3. Kecepatan mesin virtual (VIRT)4. Waktu yang diperlukan untuk mengeksekusi perintah (TURN)

c. Atribut sumber daya manusia  (personnel attributes)

1. Kemampuan analisis (ACAP)2. Kemampuan ahli perangkat lunak (PCAP)3. Pengalaman membuat aplikasi (AEXP)4. Pengalaman penggunaan mesin virtual (VEXP)5. Pengalaman dalam menggunakan bahasa pemrograman (LEXP)

d. Atribut proyek (project attributes)

1. Penggunaan sistem pemrograman modern(MODP) 2. Penggunaan perangkat lunak (TOOL)3. Jadwal pengembangan yang diperlukan (SCED) 

3. Model  COCOMO II 

Model COCOMO II, pada awal desainnya terdiri dari 7 bobot pengali yang relevan dan kemudian menjadi 16 yang dapat digunakan pada arsitektur terbarunya. 

Tabel 2. COCOMO II Early Design Effort Multipliers  

Tabel 3. COCOMO II Post Architecture Effort Multipliers

Sama seperti COCOMO Intermediate (COCOMO81), masing-masing sub katagori bisa

digunakan untuk aplikasi tertentu pada kondisi very low, low, manual,  nominal, high maupun

very high. Masing-masing kondisi memiliki nilai bobot tertentu. Nilai yang lebih besar dari 1

menunjukkan usaha pengembangan yang meningkat, sedangkan nilai di bawah 1 menyebabkan

usaha yang menurun. Kondisi Laju nominal (1) berarti bobot pengali tidak berpengaruh pada

estimasi. Maksud dari bobot yang digunakan dalam COCOMO II, harus dimasukkan dan

direfisikan di kemudian hari sebagai detail dari proyek aktual yang ditambahkan dalam database.

Dari beberapa model estimasi biaya yang telah dipaparkan, model COCOMO paling

banyak digunakan dan diterapkan.

2. Paparkan mengenai PMBOK (Project Management Body of Knowledge) dalam proyek.

Pada dasarnya, Manajemen proyek dilakukan melalui aplikasi dan integrasi proses-proses

manajemen proyek yang terdiri dari pengajuan (initiating), perencanaan, pelaksanaan,

pengawasan dan pengendalian, dan penutupan . Setiap proyek umumnya pasti memiliki batasan-

batasan (constraints), dan manajemen proyek berfungsi mengelola batasan-batasan ini agar

proyek bisa mencapai hasilnya secara efisien dan efektif. Secara tradisional constraints proyek

dibagi menjadi tiga jenis, yaitu: bidang kerja (scope), biaya (cost), waktu (time). Ketiga

constraints ini saling berhubungan dan digambarkan membentuk segitiga manajemen proyek.

Bertambahnya bidang kerja proyek akan menambah waktu dan biaya, waktu yang sempit dapat

berarti naiknya biaya dan berkurangnya bidang kerja, dan ketatnya keuangan bisa berarti

bertambahnya waktu dan berkurangnya bidang kerja. Semuanya akan mempengaruhi kualitas

hasil akhir proyek yang berupa produk atau jasa.

Gambar 1 Segitiiga Kesuksesan Proyek

Disiplin ilmu manajemen proyek adalah tentang menggunakan ‘alat’ (tools) dan teknik

yang memungkinkan tim proyek (bukan hanya manajer proyek) mengorganisasi pekerjaan

mereka sesuai constraints yang ada. Pihak manajemen proyek bertugas memutuskan cara dan

implementasi dalam mengatur dan memanfaatkan sumber daya manusia dan non-manusia untuk

mencapai sasaran-sasaran yang telah ditetapkan. Cara-cara dan teknik manajemen proyek ini

dirangkum dalam suatu sistem proyek yang menjadi standar acuan para pelaku proyek.

Salah satu sistem proyek itu tersusun dalam Project Management Body of Knowledge

(PMBOK®) yang dibuat oleh para anggota Project Management Institute (PMI). Menurut ANSI

(American National Standards Institute), PMBOK mendefinisikan manajemen proyek sebagai

penerapan dari pengetahuan, kemampuan, alat bantu serta teknik kedalam aktifitas proyek agar

dapat memenuhi atau melampaui apa yang dibutuhkan dan diharapkan oleh pihak-pihak terkait

(stakeholder) dari proyek., dengan cara menyeimbangkan seluruh kebutuhan yang terkait dengan

:

Ketepatan lingkup, waktu, biaya dan kualitas.

Stakeholder atau pihak-pihak yang terlibat atau terkena dampak dari proyek, dengan

kebutuhan dan harapan yang berbeda-beda.

Tujuan yang terdeskripsi (kebutuhan) dan yang tidak terdeskripsi secara tertulis.

Secara grafis, keterkaitan ilmu manajemen proyek terhadap ilmu – ilmu lain yang terkait

serta proyek – proyek sistem teknologi informasi terhadap ilmu – ilmu lain, seperti yang

diperlihatkan dalam gambar berikut:

Gambar 2 Keterkaitan Ilmu Manajemen Proyek terhadap Ilmu lainnya

Saat ini PMBOK merupakan sistem proyek yang paling banyak diterapkan dalam dunia

proyek. PMBOK® dikenal sebagai standar internasional (IEEE, ANSI) tentang aplikasi

pengetahuan, keterampilan, alat-alat, dan teknik untuk memenuhi keperluan proyek. Panduan

PMBOK® menjelaskan 5 proses dalam life cycle proyek (initiating, planning, executing,

controlling and monitoring, closing) dan 9 area pengetahuan tentang proyek (integration, scope,

time, cost, quality, human resources, communications, risks, procurement). Lima tahap proses

dalam PMBOK® menerapkan variasi dari Roda Deming (Deming Cycle) untuk peningkatan

yang berkelanjutan (continous improvement) . Dalam membuat penjadwalan proyek, PMBOK®

menjelaskan penggunaan metode yang disebut critical-path method (CPM).

Gambar 3 9 Knowledge Area beserta masing-masing aktivitasnya

Gambar 4 Keterkaitan 9 Knowledge Area dan 5 Proses

Dalam mengelola knowledge area perlu dipahamai beberapa prinsip sebagai berikut :

1) Setiap knowledge area akan dilakukan sejumlah aktivitas terkait dengan konsep

kelompok proses yang telah disajikan sebelumnya.

2) Masing-masing kelompok proses memerlukan sejumlah masukan (input) agar proses

tersebut dapat dijalankan.

3) Ketika proses berjalan, terlibat didalamnya sejumlah perangkat (tools) dan metode/teknik

pengerjaan yang disesuaikan penggunannya

4) Proses akan menghasilkan keluaran (output) yang akan dipergunakan untuk pelaksanaan

kelompok proses pada knowledge area yang lainnya

Gambar 5 Contoh Masukan , Perangkat & Metoda, dan Keluaran

Jika dilihat dari sudut peranan "knowledge" terhadap suatu manajemen proyek,

pengetahuan terbagi atas dua fungsi yaitu fungsi inti (utama) dan fungsi fasilitas (pendukung)

yang bermuara pada bentuk Manajemen Integrasi Proyek, dimana kedua fungsi ini berjalan

secara bersamaan dan saling terkait untuk menuju satu titik tujuan. Perspektif ilmu – ilmu terkait

untuk melaksanakan pengelolaan manajemen proyek di dalam sebuah perusahaan banyak

berhubungan dengan ilmu – ilmu manajemen umum dan ilmu – ilmu aplikasi yang

dispesifikasikan untuk jenis proyek tertentu, misalnya strategi mangatur cash flow yang

dipelajari dalam ilmu akuntansi, Disamping itu ilmu – ilmu aplikasi yang terkait dalam

manajemen proyek khususnya dalam sistem teknologi informasi, seperti implementasi software

aplikasi perusahaan (SAP atau BAAN) dalam sistem informasi perusahaan, implementasi

Electronic Data Interchange (EDI) dalam extranet, implementasi oracle dalam Decision Support

System (DSS) dan lain sebagainya.

Dalam mengerjakan sebuah project baik itu skala kecil atau skala besar pasti

membutuhkan kumpulan orang-orang yang memiliki satu tujuan bersama nah ini lah yang

namanya organisasi. Dalam PMBOK, ada beberapa hal penting yang mempengaruhi sebuah

project atau dalam hal ini bisa dikatakan perusahaan yang berhubungan dengan organisasi yaitu

diantaranya :

1. Sistem organisasi

2. Struktur organisasi

3. Budaya organisasi

4. Gaya kepemimpinan

Dalam PMBOK sistem organiasi dalam sebuah perusahaan dikenal dua istilah yaitu

sistem organisasi berbasis manajemen project dan non project. Dalam sistem organisasi berbasis

manjemen project sumber pendapatannya diperoleh melalui aktvitas yang dilakukan dengan

pendekatan proyek seperti perusahaan kontrakor bangunan dll. Sehingga dalam hal ini

perusahaan dengan sistem ini tergantung pada jumlah project yang ditangani dengan semakin

banyak project yang dapat di kerjakan maka income akan semakin banyak dan begitu pula

sebalik nya

Jika sistem berpengaruh terhadap income yang didapat maka untuk menggerakan sebuah

perusahaan harus terdapat struktur yang jelas. Dikenal dua struktur dalam PMBOK yaitu :

1. Organisasi dengan struktur berbasis fungsional

2. Organisasi dengan struktur berbasis project

Pada jenis pertama anggota dalam project diambil dari berbagai individu dari beberapa

fungsi organisasi yang berbeda misal dari keuangan,operasional dll. Pada jenis ini command and

control sangat terasa. Sedangkan pada jenis yang kedua anggota dalam project diambil dari

individu yang telah memiliki spesifikasi sama sehingga potensi keberhasilan project dinilai

cukup tinggi.

REFERENSI :

1. http://journal.ui.ac.id/upload/artikel/Pengembangan%20metode_Sarno%20R.pdf

2. http://cassonsmart.blogspot.com/2010/06/estimasi-biaya-perangkat-lunak.html

3. http://yayuk05.wordpress.com/2007/11/09/constructive-cost-model-cocomo/

4. http://www.batan.go.id/ppin/lokakarya/LKSTN_17/SUHARJITO.pdf

5. http://yayuk05.wordpress.com/2007/11/27/estimasi-biaya-perangkat-lunak/

6. http://arieepunya.blogspot.com/2007/09/sistem-estimasi-biaya-dan-usaha-proyek.html

7. http://yunus.hacettepe.edu.tr/~sencer/cocomo.html

8. http://berandakami.files.wordpress.com/2008/10/pmbok-20041.pdf

9. http://avudz.alifia.co.id/2010/03/27/cara-gampang-mengingat-9-area-pmbok/

10. http://dasmitz.blogspot.com/2007/11/pmbok.html

11. http://student.eepis-its.edu/~wongthathu/COOL/MANAJ.%20PROYEK%20SI/Day

%208/Day%208%20-%20Manajemen%20Komunikasi.pdf

12. A Guide To The Project Management Body Of Knowledge (PMBOK). 1996. Project

Management Institute, Automated Graphic System. Maryland USA.

Nama : Dafie Buthlan

Nim : 57 101 10 008