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