Modul 6. WBS dan Manajemen Estimasi Biay

Modul 6.
WBS dan Manajemen Estimasi Biaya (Cost) Proyek
Sebelum keputusan jadi atau tidaknya suatu investasi, salah satu syarat terpenting adalah
mengkaji aspek finansial dan ekonomi. Hal ini diperlukan untuk menyaring macam proyek atau
investasi yang memiliki potensi keberhasilan paling terbesar. Aspek finansial bertujuan untuk
meningkatkan kekayaan perusahaan yang diukur dengan naiknya nilai saham.

6.1. Sistematika aspek finansial
1. Menentukan parameter dasar
Parameter dasar memberikan ketentuan seperti kapasitas produksi, teknologi yang dipakai,
pilihan peralatan utama, fasilitas pendukung, jumlah produksi, pangsa pasar, proyeksi harga
produk, dan lain-lain. Parameter dasar disusun berdasarkan masukan dari pengkajian dan
penelitian aspek-aspek yang terkait terutama pemasaran dan teknik-teknik engineering.
2. Membuat perkiraan biaya investasi
Meliputi 3 komponen utama, yaitu biaya pertama (pembangunan), modal kerja (working
capital), dan biaya operasi produksi.
3. Proyeksi pendapatan
Proyeksi pendapatan (revenue) adalah perkiraan dana yang masuk sebagai hasil penjualan
produksi dari unit usaha yang bersangkutan
4. Membuat model
Membuat aliran kas selama umur proyek/ investasi. Aliran kas ini dikelompokkan menjadi

aliran kas awal, operasional dan terminal, lalu dihitung diskonto aliran tersebut.
5. Kriteria penilaian
Kriteria penilaian (figure of merit) diawali dengan konsep ekuivalent yang mencoba
memberikan bobot kuantitatif factor waktu terhadap nilai uang seperti bunga dan rendemen
(rate of return). Kriteria penilaian merupakan alat bantu bagi manajemen untuk
membandingkan dan memilih alternatif investasi yang tersedia.
6. Melakukan penilaian dan menyusun ranking alternatif
Penilaian akan menghasilkan mana usulan yang mempunyai prospek yang baik atau tidak
(accept-reject decision).
7. Analisis resiko. Sampai pada penyusunan alternatif ranking yang dilakukan terhadap suatu
asumsi tertentu, bbaik mengenai biaya yang dikeluarkan ataupun pemasukan yang akan
didapatkan dari biaya yang diperoleh.

1

6.1

Analisis pendapatan dan aliran kas
Siklus proyek dimulai dari permulaan kegiatan proyek sampai pembangunan fisik selesai.


Umur proyek berlangsung sejak awal siklus proyek sampai instalas atau produk hasil pembangunan
fisik tidak lagi beroperasi. Umur suatu proyek bergantung pada factor teknis dan factor permintaan
pasar produk.

Biaya pertama
Biaya pengeluaran fisik serta pengeluaran lainnya yang berkaitan sering disebut sebagai biaya
pertama.
a. Modal tetap untuk membangun proyek
Pengeluaran untuk studi kelayakan, desain engineering dan pembelian, dan untuk
membangun instalasi dan fasilitas produksi.
b. Modal kerja
Pengeluaran untuk membiayai keperluan operasi dan produksi pada waktu pertama kali
dijalankan.

Biaya operasi dan Produksi
a.

Bahan mentah
Pengeluaran biaya untuk bahan mentah merupakan porsi yang cukup besar dari ongkos
produksi.


b.

Tenaga kerja
Pengeluaran biaya ini terdiri dari gaji dan tunjangan

c.

Utility atau penunjang
Pengeluaran untuk mendukung operasi dan produksi

d.

Administrasi, manajemen dan overhead
Pengeluaran-pengeluaran penting yang sifatnya tidak langsung

6.2. Teknik Dekomposisi
Pengertian :
Dekomposisi berarti membagi menjadi bagian-bagian yang lebih kecil. Dalam hal ini teknik
dekomposisi dalam proses perangkat lunak berarti modulisasi, sedangkan dalam proyek berarti

membentuk sub-sub proyek, yang pada level berikutnya menjadi task-task proyek.
Dalam perencanaan proyek perangkat lunak pendekatan dekomposisi dibedakan atas :


Dekomposisi masalah



Dekomposisi proses

2

Gambar 6.1. Dekomposisi
Dekomposisi Masalah :
Dekomposisi masalah dikenal sebagai partitioning (pembagian), yaitu proses yang membagi
masalah menjadi beberapa sub masalah. Dalam hal ini pada masalah pembangunan perangkat lunak
dekomposisi dapat juga diartikan sebagai modularisasi, atau memecah persoalan perangkat lunak
menjadi sub-sub program. Sub program dapat berupa sebuah prosedur atau fungsi, ataupun
sekumpulan prosedur dan/atau fungsi.
Sebagai contoh dalam pengembangan perangkat lunak administrasi akademik, maka modul-modul

berikut mestinya manjadi bagiannya :


Preparasi data mahasiswa



Preparasi data kurikulum



Pengisian Rencana Studi



Pengisian nilai akhir

Pada sub-masalah yang komplek dapat dipecah lagi menjadi sub sub-masalah, misalnya pada modul
Pengisian Rencana Studi, dapat dipecah lagi menjadi :



Fungsi validasi user log-on



Fungsi validasi hutang-piutang mahasiswa



Prosedur pengisian rencana studi



Prosedur batal-tambah rencana studi

Dekomposisi Proses :
Dekomposisi proses didasarkan pada fase-fase generik perangkat lunak. Misalnya pada model
yang konvensional fase pertama adalah menginvenraisasi kebutuhan user dan fase terakhir adalah
pelatihan bagi user.
3


Konsep dasar pemodelan proses :
a. Sebuah proses adalah kumpulan aktifitas
b. Aktifitas adalah tindakan yang sesuai dari suatu proses. Beberapa aktifitas yang sama
mungkin bagian dari proses yang berbeda
c. Pemecahan aktifitas menjadi step
d. Formalisasi Step dengan RAISE
Dalam menerapkan dekomposisi proses, model proses perangkat lunak yang dipilih menjadi penentu
sub-sub proses yang didefinisikan pada sub proses.
Sebagai contoh pada model Sekuensial Linear, dekomposisi proses yang dimiliki adalah sebagai
berikut:


Analisis



Desain




Pemrograman / coding



Tes

Dekomposisi Proses dengan RAISE
RAISE : Rigorous Approach to Industrial Software Engineering, metoda ini adalah metoda aplikatif
dalam pengembangan perangkat lunak
Prinsip dasar RAISE :
Pengembangan secara terpisah (modular)
Pengembangan dengan tahapan-tahapan yang bijak
Perinci dan periksa
Rombak secara paksa
Konsep dasar RAISE adalah pengembangan secara modular (dekomposisi) yang dapat
dilakukan oleh teknisi berbeda. Yang menjadi masalah adalah jika ada fungsi yang sedang dibuat oleh
seorang teknisi disaat yang sama ingin dipakai oleh teknisi lain (reuse). Karena cukup sulit mengenali
semantik sebuah fungsi. RAISE digunakan untuk merinci semantic dari suatu fungsi. Konstruksi
modul RAISE digunakan untuk merinci setiap komponen.


Software Sizing
Akurasi estimasi proyek perangkat lunak didasarkan pada sejumlah hal: (1) tingkat di mana
perencana telah dengan tepat mengestimasi ukuran produk yang akan dibuat; (2) kemampuan untuk
menerjemahkan estimasi ukur-an ke dalam kerja manusia, waktu kalender, dan dolar (fungsi
availabilitas metrik perangkat lunak yang reliabel dari proyek sebelumnya); (3) tingkat di mana

4

rencana proyek mencerminkan kemampuan tim perangkat lunak; (4) stabilitas syarat produk serta
lingkungan yang mendukung usaha pengembangan perangkat lunak.
Karena estimasi proyek sama baiknya dengan estimasi ukuran kerja yang dilakukan, maka
penentuan ukuran menjadi tantangan utama bagi perencana proyek. Dalam konteks perencana proyek,
ukuran berarti keluaran yang dapat dikuantitatifkan dari proyek perangkat lunak. Bila dilakukan
pendekatan langsung, ukuran dapat diukur dalam LOC. Tetapi bila dipilih pendekatan tidak langsung,
ukuran dihadirkan sebagai FP. Putnam dan Myers mengusulkan 4 pendekatan yang berbeda terhadap
masalah penentuan ukuran:

Fuzzy-logic sizing.
Pendekatan ini menggunakan teknik reasoning aprok simasi yang merupakan dasar bagi fuzzy logic

(logika kabur ). Untuk menerapkan aplikasi ini, perencana harus mengidentifikasi tipe aplikasi,
membuat besarannya dalam skala kuantitatif, dan kemudian menyaring besaran itu dalam rentang
orisinil. Meskipun pengalaman personal dapat digunakan, tetapi perencana harus memiliki akses
terhadap database historis dari proyek sehingga estimasi dapat dibandingkan dengan pengalaman
aktual.

Function point sizing.
Perencana mengembangkan estimasi karakteristik domain informasi.

Standard component sizing.
Perangkat lunak dibangun dari sejumlah “komponen standar” yang berbeda –beda yang umum bagi
suatu area aplikasi tertentu. Contohnya, komponen standar bagi sebuah sistem informasi adalah
subsistem, modul, layar, laporan,program-program interaktif, program batch, file, LOC, dan intruksi
tingkat objek. Perencana proyek mengestimasi jumlah kejadian dari masing-masing komponen
standar dan kemudian menggunakan data proyek historis untuk menentukan ukuran yang disampaikan
per komponen standar. Untuk menjelaskan, perhatikan aplikasi sistem informasi. Perencana
memperkirakan bahwa akan dihasilkan 18 buah laporan. Data historis menunjukkan bahwa 967 baris
Cobol [PUT92 ] dibutuhkan untuk perlaporan. Hal ini memungkinkan perencana memperkirakan
bahwa akan dibutuhkan sebanyak 17.000 LOC untuk komponen laporan. Perkiraan dan perhitungan
yang serupa dapat dibuat untuk komponen standar yang lain sehingga akan dihasilkan harga ukuran

kombinasi (yang disesuaikan secara statistik).

Change sizing.
Pendekatan ini digunakan bila proyek melingkupi pemakaian perangkat lunak yang ada yang harus
dimodifikasi dengan banyak cara sebagai bagian dari sebuah proyek. Perencana memperkirakan
jumlah dan tipe ( contohnya reuse, kode perubahan, kode penghapusan ) modifikasi yang harus
5

diselesaikan. Dengan menggunakan suatu “ rasio kerja“ bagi masing-masing tipe perubahan, maka
ukuran perubahan dapat diperkirakan. Hasil dari masing-masing pendekatan sizing tersebut,
dikombinasikan secara statistik untuk membuat perkiraan three point atau expected value.

6.3. Perkiraan Berdasarkan Masalah
Baris kode ( LOC ) dan titik fungsi ( FP ) digambarkan sebagai pengukuran dasar di mana
metrik produktivitas dapat dihitung. Selama estimasi proyek perangkat lunak, data LOC dan FP
digunakan dalam dua cara: ( 1 ) sebagai variabel estimasi yang dipakai untuk “ mengukur” masingmasing elemen perangkat lunak, dan ( 2 ) sebagai metrik baseline yang dikumpulkan dari proyek yang
lalu dan dipakai dalam hubungannya dengan variabel estimasi untuk mengembangkan proyeksi kerja
dan biaya.
Estimasi LOC dan FP merupakan teknik estimasi yang berbeda, tetapi keduanya memiliki sejumlah
karakteristik umum. Perencana proyek memulainya dengan pernyataan ruang lingkup yang terbatas
dan dari pernyataan tersebut kemudian dilakukan dekomposisi perangkat lunak ke dalam fungsifungsi masalah yang masing-masing dapaat diestimasi secara individual. Kemudian LOC dan FP
(variabel estimasi) diestimasi untuk masing-masing fungsi. Secara alternatif, perencanaan dapat
memiliki komponen yang lain untuk mengukur kelas atau objek, perubahan, atau bisnis yang
dipengaruhi oleh proses.
Metrik produktivitas baseline ( seperti LOC/pm ) kemudian diaplikasikan pada variabel
estimasi yang sesuai dan dikeluarkan biaya atau usaha untuk fungsi. Estimasi fungsi dikombinasikan
untuk menghasilkan estimasi keseluruhan untuk bagian dalam proyek. Penting juga untuk dicatat
bahwa sering ada penyebab substansial di dalam metrik produktivitas untuk suatu organisasi, dengan
memakai metrik produktivitas baseline tunggal.
Secara umum, rata-rata LOC/pm dan FP/pm harus dihitung oleh domain proyek, yaitu bahwa
proyek harus dikelompokan oleh ukuran tim, area, aplikasi, kompleksitas, serta parameter-parameter
yang relevan lainnya. Rata-rata domain lokal lainnya juga harus dihitung. Pada saat proyek diestimasi,
pertama kali proyek harus dialokasikan ke dalam sebuah domain, dan kemudian harus digunakan ratarata domain yang sesuai bagi produktivitas untuk membuat estimsi.
Teknik estimasi LOC dan FP berbeda di dalam tingkat detail yang dibutuhkan untuk
dekomposisi dan target pembagian. Bila LOC digunakan sebagai variabel estimasi, dekomposisi
menjadi sangat penting dan sering dipakai pada tingkat yang dapat dipertanggungjawabkan. Semakin
besar tingkat pemisahannya, semakin akurat estimasi LOC dan FP yang dikembangkan.
Pada estimasi FP, dekomposisi bekerja secara berbeda. Selain berfokus pada fungsi, masing-masing
karakteristik domain informasi – infut, output, file data,inquiry, dan intervace eksternal – serta 14
nilai penyesuaian kompleksitas. Estimasi resultan digunakan untuk mendapatkan nilai FP yang dapat
diikat dengan data sebelumnya serta digunakan untuk melakukan estimasi.
6

Tanpa memperhatikan variabel estimasi yang dipakai, perencana proyek memulainya dengan
mengestimasi range nilai untuk masing-masing fungsi atau harga domain informasi. Dengan
menggunakan data historis, atau ( bila semua yang lain gagal ) intuisi, perencana mengestimasi harga
ukuran optimistik dan pesimistik untuk setiap fungsi atau menghitung setiap harga domain informas.
indikasi implisit dari tingkat ketidakpastian diberikan bila range nilai sudah ditentukan.
Kemudian three-point atau expectid value dihitung. Expectid value untuk variabel estimasi
(ukuran),EV, dapat dihitung. Agar rata-rata terbobot dari estimasi optimistik (Sopt), paling sering (Sm),
dan pesimistik (Spess).
Contohnya:
EV = (Sopt + Sm + Spess)/6
memberikan kepercayaan terbesar pada estimasi “ yang paling mungkin “ serta mengikuti distribusi
probalitas beta.
Kita asumsikan bahwa ada probalitas yang sangat kecil di mana hasil ukuran aktual akan
jatuh di luar harga ostimistik dan nilai pesimistik. Dengan menggunakan standar taknik statistik, kita
dapat manghitung deviasi estimasi. Tetapi harus dicatat bahwa deviasi yang berdasarkan data (
estimasi ) tidak pasti harus digunakan secara bijaksana.
Sekali expected value untuk variabel estimasi ditentukan, data produktivitas LOC atau FP
diaplikasikan. Apakah estimasi itu benar? Satu-satunya jawaban yang beralasan bagi pertanyaan itu
adalah: “ Kita tidak yakin.” Setiap teknik estimasi, bagaimanapun canggihnya, masih harus tetap dicross-check dengan pendekatan lainnya dab barukemudian kaidah umum dan pengalaman dapat
berlaku di sini.

Contoh Estimasi Berbasis LOC
Sebagai contoh untuk teknik estimasi LOC dan FP, perhatikan paket perangkat lunak yang
dikembangkan untuk aplikasi computer-aided design ( CAD ) untuk komponen mekanis. Kajian
spesifikasi sistem menunjukan bahwa perangkat lunak akan mengeksekusi workstation rekayasa dan
harus berinterface dengan berbagai periferal grafis komputer meliputi mouse, digitizer, display warna
resolusi tinggi dan printer laser.
Dengan menggunakan spesifikasi sistem sebagai paduan, dapat dikembangkan pernyataan
pendahuluan ruang lingkup perangkat lunak sebagai berikut :
Perangkat lunak CAD akan menerima data geometri dua dan tiga dimensi dari seorang
perekayasa. Perekayasa akan berinteraksi dan mangontrol sistem CAD melalui suatu interfac
pemakai yang akan memperlihatkan karakteristik desain manusia mesin yang baik. Semua
dan geometri dan informasi pendukung yang lain akan dipelihara pada database CAD. Modul
7

analisis desain akan dikembangkan untuk memproduksi output yang dibutuhkan yang akan
ditampilkan pada berbagai perangkat grafik. Perangkat lunak akan dirancang untuk
mengontrol dan berinteraksi dengan perangkat periferal termasuk mouse, digitizer, dan printer
laser.
Pernyataan ruang lingkup di atas merupakan suatu pendahuluan – tidak terbatas. Setiap kalimat harus
dikembangkan untuk memberikan detail konkrit serta batasan kuantitatif. Contohnya, sebelum
perkiraan dapat dimulai, perancang harus menentukan apa artinya “karakteristik desain interface
manusia – mesin yang baik” atau akan seperti apakah ukuran dan kecanggihan “database CAD”
tersebut.
Untuk tujuan tersebut, kita asumsikan penyaringan lebih jauh lagi telah terjadi dan bahwa fungsi
perangkat lunak mayor telah diidentifikasikan sebagai berikut:
-

interface pemakai dan fasilitas kontrol ( UICF ).

-

analisis geometri dua dimensi ( 2DGA ).

-

analisis geometri tiga dimensi ( 3DGA ).

-

manajemen database ( DBM ).

-

fasilitas tampilan grafis komputer ( CGDF ).

-

kontrol periferal ( PC ).

-

modul analisis desain ( DAM ).

Untuk mengikuti teknik perhitungan three-point untuk LOC telah dikembangkan tabel yang
diperlihatkan pada tabel A. Sebagai contoh, rentang perhitungan LOC untuk fungsi analisis geometri
3D adalah:
optimis

:

4600

most likely

:

6900

pesimistik

: 8600

Dengan menerapkan persamaan, harga yang diharapkan untuk analisis geometri 3D adalah 6800
LOC. Jumlah itu dimasukkan ke dalam tabel. Perhitungan lain ditarik dengan cara yang sama.
Dengan menjumlahkan secara vertikal dalam kolom LOC terestimasi, maka perhitungan 33.200 baris
kode dibangun untuk sistem CAD.
Suatu kajian data historis menunjukkan bahwa produktivitas rata-rata organisional untuk sistem tipe
tersebut adalah 620 LOP/pm. Dengan didasarkan pada upah buruh yang juga dibebankan, yang
berjumlah $ 8.000 per bulan, biaya perbaris kode kira-kira $13.00. Berdasarkan perhitungan LOC dan
data produktivitas historis, biaya proyeksi total terhitung $431.000 dan usaha yang terhitung adalah
54 person-month.

6.4. Membuat Work Breakdown Structure
Work Breakdown Structure (WBS) adalah representasi visual tentang hal-hal berkaitan
dengan proyek yang akan dibuat. Secara tipikal WBS adalah tuntunan proyek yang harus diselesaikan
8

Tabel 6.1. Perkiraan untuk LOC
Fungsi

LOC Terestimasi

interface pemakai dan fasilitas kontrol ( UIC )

2.300

anaalisis geometrik dua dimensi ( 2DG )

5.300

analisis geometrik tiga dimensi

( 3DGA )

manajemen database ( DBM )
fasilitas
kontrol

disflay

grafis

3.350

komputer

periperal

6.800

(
(

PC
PC

)

4.950

)

2.100

modul analisis desain ( DAM )

8.400

baris kode terestimasi

33.200

dan menjadi alat pembanding proyek yang telah diselesaikan. WBS merupakan input langsung untuk
melakukan verifikasi terhadap ruang lingkup proyek yang meliputi:


Estimasi biaya
WBS memungkinkan untuk membuat estimasi biaya berdasarkan kebutuhan proyek



Biaya budgeting
WBS digunakan untuk melakukan pelacakan terhadap aktual biaya dibandingkan dengan estimasi
proyek yang telah dibuat



Perencanaan sumber daya
Komponen-komponen WBS yang dibutuhkan untuk menyelesaikan proyek dapat diperhitungkan
secara akurat, termasuk SDM dan peralatan.



Perencanaan Manajemen Resiko.
WBS memberikan ilustrasi terhadap segala sesuatu yang harus dibuat dan gambaran resiko yang
mungkin akan timbul.



Activity definition
Hasil akhir WBS adalah menghasilkan daftar kegiatan yang menguraikan aktifitas yang harus
dilakukan oleh team proyek.
Beberapa departemen IT dan sistem perusahaan membangun WBS berdasarkan pengalaman

yang diperoleh dari beberapa proyek. Jika dimungkinkan mereka menyediakan starting point yang
sangat berguna dalam membuat WBS yang spesifik dan mencegah agar tidak ada yang terlupa.
Namun demikian, perlu diperhatikan dalam penggunaan WBS standar bahwa setiap proyek memiliki
fitur-fitur yang berbeda dan sangat penting untuk tidak mencocokkan seluruh proyek menggunakan
pendekatan yang standar, melainkan pendekatan standar tersebut harus disesuaikan dengan kebutuhan
setiap proyek.
Berikut langkah-langkah yang dilakukan dalam pembuatan WBS :

9

1. Buat penjabaran scope menjadi beberapa bagian inti proyek yang akan dibuat
Beberapa manajer proyek lebih menyukai untuk menggunakan tahapan proyek sebagai
komponen utama. Pilih pendekatan yang terbaik dan sesuai bagi anda dan tim proyek anda.
Sebagai contoh, melakukan dekomposisi scope proyek menjadi :
• Project management
• Database
• Server
• End-user
• Education and documentation
2. Melakukan dekomposisi unit-unit yang lebih kecil atau paket-paket kerja
Jika setelah proses dekomposisi, produk hasil dekomposisi menurun dan item terkecil masih
setara dengan 400 jam kerja, maka anda perlu menjabarkan WBS lebih detail lagi.

Referensi :
1. Software Engineering, Roger S. Pressman,McGrawHill 1997
2. Management Information System, Raymond McLeod, Prentice Hall 2000
3. Software Project Management for Dummies, Teresa Luckey, Joseph Phillips, Wiley Publishing
Inc., 2006
4. Berbagai Sumber

10