REKAYASA PERANGKAT LUNAK

COCOMO (Constructive Cost Model)

Jaya Sena Turana

G651120734

Program Studi Ilmu Komputer

Institut Pertanian Bogor

COCOMO (Constructive Cost Model)

COCOMO adalah singkatan dari Constructive Cost Model yang merupakan

sebuah kombinasi dari estimasi parameter persamaan dan metode pembobotan.

Sejarah COCOMO
COCOMO pertama kali diterbitkan pada tahun 1981 Barry Boehm W.'s Book
ekonomi Software engineering sebagai model untuk memperkirakan usaha,
biaya, dan jadwal untuk proyek-proyek perangkat lunak. Ini menarik pada studi
dari 63 proyek di TRW Aerospace mana Barry Boehm adalah Direktur Riset dan
Teknologi Perangkat Lunak pada tahun 1981. Penelitian ini memeriksa proyekproyek ukuran mulai dari 2.000 sampai 100.000 baris kode, dan bahasa
pemrograman mulai dari perakitan untuk PL / I. Proyek-proyek ini didasarkan
pada model pengembangan perangkat lunak waterfall yang merupakan proses
software umum pembangunan di 1981.

Pengertian COCOMO
Tidak seperti model estimasi biaya yang lain, COCOMO adalah model terbuka,
sehingga semua detail dipublikasikan, termasuk :

Dasar persamaan perkiraan biaya

Setiap asumsi yang dibuat dalam model
Setiap definisi
Biaya yang disertakan dalam perkiraan dinyatakan secara eksplisit

Perhitungan paling fundamental dalam COCOMO model adalah penggunaan

Effort Equation (Persamaan Usaha) untuk mengestimasi jumlah dari PersonMonths yang dibutuhkan untuk pengembangan proyek.

COCOMO terdiri dari tiga bentuk hirarki semakin rinci dan akurat. Tingkat
pertama, Basic COCOMO adalah baik untuk cepat, order awal, kasar estimasi
besarnya biaya perangkat lunak, namun akurasinya terbatas karena kurangnya
faktor untuk memperhitungkan perbedaan atribut proyek (Cost Drivers).
Intermediate COCOMO mengambil Driver Biaya ini diperhitungkan dan Rincian
tambahan COCOMO account untuk pengaruh fase proyek individu.

SOURCE LINE OF CODE

Perhitungan COCOMO didasarkan pada estimasi anda pada ukuran proyek

dalam Source Line Of Code (SLOC). Pendefinisian SLOC:
Hanya jumlah baris kode yang dikirim sebagai bagian dari produk yang
disertakan (test drivers dan software pendukung lainnya tidak dihitung).
Baris kode dibuat oleh staf proyek (kode yang di-generate oleh aplikasi
tidak dihitung).
Satu SLOC adalah satu baris kode secara logis.
Deklarasi dihitung sebagai SLOC.
Komentar tidak dihitung sebagai SLOC.

Model COCOMO 81 didefinisikan dalam bentuk Delivered Source Instruction,

yang mana sangat menyerupai SLOC. Perbedaan utama antara DSI dan SLOC
adalah sebuah SLOC mungkin merupakan beberapa baris secara fisik. Sebagai
contoh, sebuah statement if-then-else akan dihitung sebagai satu SLOC,
tetapi mungkin dihitung sebagai beberapa DSI.

SCALE DRIVERS
Pada model COCOMO II, beberapa factor terpenting yang berkontribusi pada
durasi proyek dan biaya yang dikeluarkan adalah Scale Drivers. Anda mengeset
setiap Scale Driver untuk mendeskripsikan proyek anda. Scale Drivers tersebut
menentukan eksponen yang digunakan dalam Effort Equation.
Ada 5 Scale Drivers :

Precedentedness
Development Flexibility
Architecture / Risk Resolution
Team Cohesion
Process Maturity

Catat bahwa Scale Drivers telah menggantikan Development Mode dari

COCOMO 81. Dua Scale Drivers yang pertama, Precedentedness dan
Development Flexibility sebenamya mendeskripsikan pengaruh yang hampir
sama dibanding Development Mode.

COST DRIVERS
COCOMO II memiliki 17 cost drivers. Cost driver tersebut adalah factor pengali
yang menentukan usaha yang diperlukan untuk menyelesaikan proyek software
anda. Sebagai contoh, jika proyek anda akan mengembangkan software yang
mengatur penerbangan pesawat, anda akan mengeset Required Software
Reliability (RELY) cost driver menjadi sangat tinggi. Rating tersebut
berhubungan dengan effort multiplier 1,26 yang berarti bahwa proyek anda
akan membutuhkan usaha lebih sebesar 26% dibanding proyek software pada
umumnya. COCOMO II mendefinisikan setiap cost drivers dan effort multiplier
yang terhubung dengan setiap rating.

Model COCOMO

Model COCOMO terdiri dari 3 model yaitu :

1. Dasar Cocomo
Dengan menggunakan estimasi parameter persamaan (dibedakan menurut tipe
sistem yang berbeda) upaya pengembangan dan pembangunan durasi dihitung
berdasarkan perkiraan DSI.
Dengan rincian untuk fase ini diwujudkan dalam persentase. Dalam hubungan
ini dibedakan menurut tipe sistem (organik-batch, sebagian bersambung-online, embedded-real-time) dan ukuran proyek (kecil, menengah, sedang, besar,
sangat besar).

Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:

Proyek organik (organic mode) Adalah proyek dengan ukuran relatif

kecil, dengan anggota tim yang sudah berpengalaman, dan mampu
bekerja pada permintaan yang relatif fleksibel.

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

ukuran dan tingkat kerumitan yang sedang, dan tiap anggota tim
memiliki tingkat keahlian yang berbeda
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:

keterangan :

E
: besarnya usaha (orang-bulan)
D
: lama waktu pengerjaan (bulan)
KLOC : estimasi jumlah baris kode (ribuan)
P
: jumlah orang yang diperlukan.

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 (Complete atau Detailed COCOMO model)

Model COCOMO II, pada awal desainnya terdiri dari 7 bobot pengali yang
relevan dan kemudian menjadi 16 yang dapat digunakan pada arsitektur
terbarunya. 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.

Contoh Kasus : Perhitungan Sistem Infomasi Manajemen Daerah (SIMDA)

Perhitungan COCOMO bisa digunakan untuk mengetahui

jenis proyek,

menghitung Person Month (perbandingan antara waktu dan tenaga yang

dibutuhkan), Durasi (waktu yang dibutuhkan untuk menyelesaikan proyek), tim
size (tenaga yang dibutuhkan).
Metode Function Point pertama kali diusulkan oleh Albrecht dan Gaffney. Pada
metode ini, ukuran proyek dapat dihitung oleh tiga komponen yaitu ukuran
proses informasi (Unadjusted Function Points-UFP), faktor penyesuaian
kompleksitas dan Function Points. Komponen tersebut dianalisa sebagai
berikut:

Unadjusted Function Points - UFP

Fitur ini disebut juga sebagai ukuran proses informasi. Ukuran ditentukan oleh
identifikasi komponen eksternal sistem atau logical input, output, pemeriksaan
(inquiry), external interface ke sistem lain dan logical internal file. Komponen
ini memiliki kategori "mudah", "menengah" atau "komplek" tergantung pada
karakteristik yang dimiliki. Lalu jumlah dari semua komponen disebut
Unadjusted Function Points (UFP). Kategori yang dimiliki digambarkan pada
tabel 1 dibawah [Symons,88]. Dengan catatan jumlah keseluruhan didapatkan
dengan mengalikan kategori yang dipilih (mudah, menengah atau komplek).

Sesuai dengan kategori yang dimiliki SIMDA, maka perhitungan UFP adalah:
Eksternal input

mudah

x3

=9

Eksternal output

mudah

x4

= 16

User

menengah

x4

= 16

File

komplek

15

x15

= 225

Eksternal interface

menengah

x7

= 49

UFP

= 315

Perhitungan Kompleksitas Teknis

Perhitungan ini dihasilkan dari perhitungan technical complexity factor (TCF).
TCF dihitung dengan melakukan penilaian 14 pertanyaan yang ditunjukkan pada
table 2 [Pressman,87] dari 0 sampai 5 dimana

Sesuai dengan kategori yang dimiliki SIMDA, maka perhitungan TCF adalah:

1. Backup dan recovery dapat dipercaya

2. Komunikasi data

3. Fungsi distribusi

4. Performansi

5. Lingkungan operasional

6. Data entry on-line

7. Layar interaktir untuk input

8. Online update

9. Kompleksitas interface

10.Bisa digunakan kembali (reusability)

11.Kompleksitas proses

12.Kemudahan dalam install

13.Memiliki banyak site

14.Mudah digunakan

4
TCF

= 52

Perhitungan Function Point

Sesuai dengan SIMDA, maka perhitungan Function point dihutung dengan
menggunakan rumus:

Sehingga didapatkan FP = 315 x (0.65 + 0.01 *

52) FP = 368,55
Konversi FP-ke-NCSS
Setelah function point dihitung, sesuai dengan table 3 digunakan untuk
konversi ke NCSS yang diusulkan oleh Albrecht dan Gaffney [83].

Karena SIMDA menggunakan bahasa C, maka didapatkan perhitungan konversi

dimana konversi NCSS = FP * NCSS
konversi NCSS = 368,55 * 70
= 25798,5

Menurut ide dasar COCOMO, proyek dibagi menjadi dua kategori yaitu poyek
kecil dan proyek besar, dimana masing-masing proyek tersebut memiliki ciriciri sebagai berikut:
Proyek Kecil
Tim memiliki anggota sedikit (2-3 orang)
Mudah dimodelkan
Memiliki penyelesaian tidak terlalu rumit
Perhitungan EFFORT = a * SIZE + b

Proyek Besar
Semakin banyak tim yang dimiliki, semakin komplek proyek yang akan
dikerjakan
Perhitungan EFFORT = a * SIZE

Dimana a dan b adalah faktor penskalaan

Selain itu COCOMO memiliki kriteria tipe proyek, yaitu organik, semi detached
dan embedded dimana masing-masing kriteria memiliki ciri-ciri sebagai berikut:
Organik
Merupakan proyek rutinitas
Proyek yang dikerjakan mudah dipelajari
Tim work bekerja scara efisien
Proyek yang dikerjakan memiliki sedikit hambatan
Umumnya sistem kecil

Semi-Detached
Pada pertengahan antara organic dan embedded
Memiliki sistem yang kompleks, tetapi proyek bukanlah sesuatu yang baru Tim
bisa terdiri dari tenaga yang berpengalaman dan belum berpengalaman

Embedded
Memiliki tingkat kesulitan lebih bila dibandingkan organik dan semi
detached
Proyek yang dikerjakan cukup besar (software untuk kontrol nuklir, atau
pesawat luar angkasa)
Tim sebagian besar terdiri dari tenaga yang
berpengalaman Proyek yang dikerjakan merupakan sesuatu
yang baru Biasanya memiliki hambatan yang cukup besar

Berdasarkan kriteria kategori proyek COCOMO, SIMDA merupakan proyek besar,

b

sehingga memiliki Perhitungan EFFORT = a * SIZE . Selain itu SIMDA merupakan

tipe proyek Semi detached sehingga sesuai dengan table 4, SIMDA memiliki nilai
a dan b masing-masing yaitu a = 3.0 dan b = 1.12.

Perhitungan Unadjusted function Point UFP digunakan untuk mengetahui SIZE

yang dimiliki SIMDA. Sehigga bisa diketahui SIZE yang dimiliki SIMDA adalah 315.
Untuk mengetahui berapa banyak usaha (Effort) untuk menyelesaikan SIMDA,
maka digunakan rumus

EAF adalah Effort Adjustment Factor sesuai dengan table 5

Berdasarkan table 5, EAF yang dimiliki SIMDA

adalah: Proyek yang dikerjakan memiliki detail:
Required software reliability

high

1.15

Database size

high

1.08

Main storage

high

1.06

Programmer capability

low

1.17

Programming language experience

low

1.07

Use of software tools

low

1.10

Required development schedule

low

1.08

Sehingga bisa ditentukan Person Month (PM), yaitu: PM =

EAF * a * SIZE

PM = (1.15 * 1.08 * 1.06 * 1.17 * 1.07 * 1.10 * 1.08) * 3.0 * (315)

1,958003848944

3.0

1.12

628,21430325924871194843592945187

PM =

PM

3690,1380712298466655824357345827

3690 PM yang dibutuhkan untuk menyelesaikan proyek SIMDA

Berdasarkan table 6, bisa ditentukan waktu yang dibutuhkan untuk menyelesaikan

SIMDA

Duration = 2.5 * Effort

Duration = 2.5 * (3690)

0.35
0.35

Duration = 44,300122211786639946327317299409 Waktu

yang dibutuhkan sebanyak 44 bulan

Orang yang dibutuhkan untuk menyelesaikan proyek SIMDA

3690,1380712298466655824357345827
= 83,298597994567971710619803122485
44,300122211786639946327317299409
Sehingga untuk menyelesaikan proyek SIMDA dibutuhkan 83 orang