Bab 2 an Baru1
Transcript of Bab 2 an Baru1
BAB II
PERENCANAAN PROYEK
Ada beberapa alasan yang menentang perencanaan seperti berikut ini :
“Perencanaan membuang waktu yang banyak “
“Perencanaan sangat mahal “
“Mengapa harus direncanakan bila rencana selesai maka jadwal sudah lewat“
“Setiap proyek berbeda masing-masingnya tidak perlu rencana”
“Perencanaan tidak mendukung fleksibilitas “
“Perencanaan memadamkan kreatifitas “
Suatu perencanaan proyek adalah proses yang membuat bingkai kerja
(framework) untuk bagaimana proyek dijalankan. Termasuk defenisi dan tujuan
proyek, pemilihan pendekatan siklus hidup, pembuatan kebijakan, prosedur dan
proses-proses penting untuk mencapai sasaran, penetapan tanggung jawab dan
perhitungan biaya. Proses perencanaan adalah suatu pekerjaan yang sulit dan
merupakan fungsi utama dari manajemen. Perencanaan bukan hanya :
Memperkirakan / memprediksi sesuatu
Mengidentifikasi resiko, tetapi mencoba mengantisipasi resiko
Suatu proses membuat keputusan yang akan datang
Mengapa perlu rencana ? rencana diperlukan untuk :
Melengkapi pengertian secara umum tentang tujuan dan pekerjaan proyek
Meningkatkan komunikasi dengan baik di dalam proyek
Acuan jadwal yang realistis dan titik kontrol
Mengantisipasi lingkup resiko
Mendapat dukungan dari Manajemen atas
Mengelola keterbatasan sumber daya
II.1 BEBERAPA ISU DALAM PERENCANAAN
Isu penting dalam Perencanaan Perangkat Lunak :
Kebutuhan perangkat lunak adalah sangat sulit untuk dapat dituliskan dengan
tepat
Perencanaan adalah program kegiatan yang sering kali tidak lengkap dan /
atau kurang
14
Kriteria yang dihasilkan tidak dapat dipakai untuk pemilihan teknologi yang
baik
Isu dari suatu Rencana Umum :
Identifikasi dan misi
Tujuan
Maksud
Sumber daya
Rencana kegiatan
Rencana aksi
Hubungan Rencana Umum dengan Rencana Proyek ditunjukkan pada tabel 2.1.
Tabel 2.1. Hubungan antara rencana umum dan rencana proyek
Rencana Umum Rencana Proyek
Identifikasi dan misi Kegunaan dan lingkup proyek
Tujuan Obyektif proyek dan gol manajemen
Maksud Pengendalian, pemantapan proses proyek
Sumber daya Uang, orang, peralatan, waktu
Rencana kegiatan Jaringan kerja, jadwal, anggaran, rencana
pengujian, rencana konversi, penugasan kerja
Rencana- aksi Rencana kontigensi, pengumpulan data,
pelaporan, perencanaan ulang
II.2 PERENCANAAN KONTIGENSI
Kontigensi perlu direncanakan untuk 3 kendala berkaitan dengan proyek, yaitu :
Performansi
Jadwal
Biaya
Orang
Tugas Perencana Kontigensi
Penspesifikasian performansi
Estimasi kesalahan
Perubahan dalam upaya pengembangan
Pelatihan orang baru
Antar muka dengan lainnya
15
Dukungan dari grup lainnya
Perubahan dalam proses pengembangan perangkat lunak
Perubahan dalam prioritas proyek
Panduan untuk perencanaan kontigensi
Tambahkan 10 % diatas estimasi – untuk setiap aktifitas
Gunakan estimasi individual dan ketidak-tentuan
Tambahkan aktifitas yang tidak direncanakan dan dibutuhkan
Analisis performansi proyek yang lalu
Ada beberapa siklus perencanaan seperti yang yang ditunjukkan gambar 2.1 dan gambar 2.2.
Gambar 2.1. Siklus Perencanaan –Contoh 1
16
Inisialisasi kebutuhan
Pengestimasian ukuran produk
Pengestimasian sumber daya produk
Pengembangan jadwal
Penyesuaaian jadwal
Pengembangan PL
Negosiasi utk komitmen
Penilaian komitmen
Kebutuhan yang telah dinegosiasikan
WBS
SLOC
Bulan, orang, waktu & mesin
Proyeksi jadwal
sesuai
aktual
Pembandingan (basis data)
Estimasi
penyesuaian
tidak
Produk yg diserahkan
Keinginan,kebutuhan, kesempatan
Pengusulan proyek
Usulan Proyek
Pembangunan sistem
Sistem yang sudah terinstalasi
Perawatan & pengoperasian System
Gambar 2.2. Siklus Perencanaan – Contoh 2II.3 PENGELOLAAN PROSES PERENCANAAN
Unsur-unsur Perencanaan perangkat lunak adalah ;
17
Gol dan obyektif : yang menggambarkan apa yang dilakukan, untuk siapa,
dan kapan
Work Breakdown Structure (WBS) : WBS membagi tugas proyek dalam sub-
sub tugas yang masing-masing akan didefenisikan,
diestimasi dan di lacak
Mengestimasi besar produk : adalah perkiraan kode yang dibutuhkan secara
kuantitatif untuk masing-masing elemen produk
(subsistem, komponen atau modul). Estimasi ini
didasarkan pada pengalaman utama proyek-proyek yang
lalu
Mengestimasi sumber daya : didasarkan pada pengalaman yang sudah-
sudah, dapat diketahui faktor produktifitas yang
dimasukkan ke bagian perkiraan yang masuk akal bagi
kebutuhan sumber daya untuk tiap-tiap elemen WBS.
Penjadwalan proyek : berdasarkan pada ketersediaan staf proyek dan
perkiraan sumber daya, suatu penjadwalan tugas dan
penyetoran item dapat dihasilkan.
II.4 GOL DAN OBYEKTIF
Gol dan obyektif proyek ditentukan pada tahap kebutuhan dari siklus hidup
pengembangan perangkat lunak, juga pada saat periode negosiasi antara
pengembang perangkat lunak dan user yaitu apa yang akan dilakukan, bagaimana
ukuran kesuksesan, berapa lama waktu yang dibutuhkan dan berapa banyak sumber
daya yang diperlukan. Karena kebutuhan user umumnya berubah sejalan waktu.
Ketika mereka melihat masalah mereka secara sempit, maka perubahan kebutuhan
secara bertahap dikerjakan dalam progress pekerjaan. Perubahan kebutuhan adalah
suatu masalah klasik dalam rekayasa perangkat lunak. Ada beberapa cara untuk
mengelola masalah ini, yaitu tim perangkat lunak harus mengikuti beberapa aturan
sederhana berikut:
1. Implementasikan produk dalam tahapan-tahapan kecil
2. Untuk tiap kenaikan tahap pilih yang mendukung pada kenaikan
berikutnya dan atau tingkatkan pengetahuan terhadap kebutuhan.
3. Tinjau kebutuhan-kebutuhan untuk tiap-tiap kenaikan tapi lakukan
sebelum memulai desain
18
4. Jika kebutuhan berubah selama tahap implementasi, liput perubahan ke
kenaikan tahap berikutnya.
5. Jika perubahan tidak terliput, berhenti bekerja, ubah kebutuhan, ulangi
perencanaan, dan mulai lagi pada desain.
Beberapa pertimbangan utama dari fase kebutuhan adalah :
Kebutuhan fungsional : Fungsi-fungsi produk di daftar, bersama dengan
beberapa performansi atau konstrain lain, Jika
memungkin sebuah draft petunjuk manual user
dibuat atau sebuah prototype di bangun untuk
mentes beberapa item-item pertanyaan.
Kebutuhan sistem : Konfigurasi target sistem ditentukan, bersama
dengan beberapa standarnya, kompatibilitas, atau
konstrain lingkungan.
Identifikasi pelanggan : user diidentifikasi sesuai dukungan
kebutuhannya, termasuk ; mekanisme
penyetoran, pemaketan produk, dukungan
instalasi, kebutuhan dokumentasi, dan
pelatihan.
Mengukur kesuksesan : biaya, penjadwalan, performansi, kualitas,
ukuran, dan ukuran-ukuran kesuksesan lainnya
dikuantifikasi.
Validasi dan Penerimaan : menentukan kesuksesan yang dapat diterima,
termasuk tanggung jawab terhadap Acceptance
testing, kriteria yang dipakai dan beberapa
garansi atau konsekwensi-konsekwensi lain
jika kegagalan terjadi.
Dukungan : Kelanjutan kebutuhana dukungan di tetapkan, termasuk
pelaporan dan koreksi.
II.5 MEMBUAT WORK BREAKDOWN STRUCTURE (WBS)
WBS adalah teknik untuk :
Membagi keseluruhan proyek ke dalam komponen-komponen
19
Memecah komponen ke level-level berikutnya sampai dengan setiap tugas
merupakan unit-unit yang dapat dikelola (misalnya oleh manajer teknik)
seperti :
Direncanakan
Dianggarkan
Dijadwalkan
Dikendalikan
Menampilkan gambar / grafik tentang hirarki proyek
Tujuan WBS :
Melengkapi komunikasi antar personel proyek
Menjaga konsistensi dalam pengendalian dan pelaporan proyek
Cara efektif untuk melengkapi tugas manajemen
Manfaat WBS :
Mengurangi kompleksitas
Fasilitas penjadwalan dan pengendalian
Dimana posisi WBS dalam siklus hidup pengembangan produk ? sebagaimana
ditunjukkan dalam gambar 2.3 , adalah pada tahap-tahap awal, yaitu sebelum tahap
eksplorasi konsep.
Pertimbangan WBS :
Harapan
Hasil yang jelas
Tugas yang fleksibel
Antarmuka minimum
Berhubungan dengan ketrampilan
Level pengendalian
Berhubungan dengan sistem manajemen yang lain
Petugas tradisional
Kepuasan pekerja
20
Gambar 2.3 Siklus Hidup Pengembangan Produk menurut IEEE 1074
Panduan WBS :
1. Pecah setiap fungsi ke dalam 3 subfungsi yang
Menerima masukan dan memasukkannya kebentuk yang
berkaitan
Mentransformasikan masukan ke dalam keluaran yang
dibutuhkan
21
Laporan arsip
Dokumentasi pemeliharaan
Dokumentasi user
Laporan validasi / verifikasi perangkat lunak
Rencana validasi / verifikasi perangkat lunak
Spesifikasi kebutuhan perangkat lunak (SRS)
Biaya
SLC
Model SLC
. SLCs
Operasi dan support
pemeliharaan
Analisis kebutuhan
Desain
Spesifikasi antar muka sistem
Implementasi
Instalasi
Deskripsi desain perangkat lunak
Eksplorasi konsep
Eksplorasi sistem
Dokumen kebutuhan
Pengembalian
Identifikasi SLCs
Memilih model
Peta Task-task ke SLC menggunakan IEEE 1074
Alokasi sumber daya
Menyiapkan keluaran ke dalam bentuk akhir yang diminta
2. Lakukan dekomposisi secara iteratif
3. tidak seluruh cabang mempunyai level yang sama
4. buat struktur produk dengan perangkat lunak
5. WBS bukan hanya untuk proyek saja
6. Jika WBS sangat rumit untuk ditampilkan dalam satu peta maka
pecah setiap level subfungsi dalam peta terpisah
7. bangun inisial WBS oleh manajer proyek
8. kaji dan perbaiki WBS oleh semua kelompok yang berkaitan
9. WBS adalah merupakan / menyerupai struktur pohon
Struktur WBS ditunjukkan seperti gambar 2.3.
Gambar 2.3. Struktur WBS
WBS dapat dibuat dari pendekatan top-down atau bottom-up, seperti
ditunjukkan pada gambar 2.4. Pendekatan top-down meliputi proses dekomposisi
berturut-turut. Pendekatan bottom-up menggunakan brainstorming dan gabungan
diagram. Biasanya pada awal proyek ketika tahap kebutuhan, pendekatan top-down
digunakan. Pendekatan top-down sering digunakan ketika pekerjaan belum
dilaksanakan dan tim proyek memahami langkah-langkah dengan baik. Pendekatan
bottom-up adalah suatu pendekatan yang baik dan sesuai untuk suatu proyek, ketika
tim proyek belum begitu terbiasa dengan langkah-langkah yang akan dilakukan.
pendekatan ini pada umumnya yang dilaksanakan dengan pengungkapan pendapat
semua hal yang dapat dilakukan selama proyek dan kemudian menggolongkan
22
sistem
subsistemsubsistem subsistem
modul modulmodul modulmodulmodul modulmodul modul
aktivitas yang berada dalam tingkatan yang sama dan kemudian mengatur semua
aktivitas ke dalam pengelompokan yang lebih tinggi sampai item yang tertinggi
dicapai.
Gambar 2.4 Membangun WBS secara Tpo-Down atau Bottom-Up
Suatu milestone adalah suatu keadaaan signifikan dalam suatu proyek,
biasanya diasosiasikan dengan pekerjaan utama atau produk yang disetor. Milestone
mempunyai durasi waktu 0. Ia hanya menandai suatu titik dalam waktu ketika
sesuatu yag penting harus diselesaikan. Mereka dapat didefenisikan diakhir satu atau
lebih aktifitas, atau untuk suatu hasil kerja atau setoran. Sebaiknya menggunakan
bahasa yang menunjukkan penyelesaian seperti “ done” atau “completion”. Tahap
ataupun fase bukan milestone tapi adalah sekumpulan aktifitas produk yang saling
berhubungan, tetapi milestone dapat dipakai untuk menandai tahap atau fase
penyelesaian seperti ditunjukkan Gambar 2.4.
23
Tahap
Milestone Milestone
Task
Task
Task
Task
Task
Task
Task
Task
Task
Tahap
Milestone
Task
Task
Task
Task
Task
Task
Task
Tahap
Milestone Milestone
Task
Task
Task
Task
Task
Task
Task
Task
Task
Task
ProjectTop-Down
Bottom-up
Level terendah WBS adalah level di mana pekerjaan dapat diselesaikan.
Level ini seperti daun pada sebuah representasi pohon, dan dikenal sebagai paket
pekerjaan dan biasanya hasilnya dalam suatu produk pekerjaan yang disetor
(delivered). Paket pekerjaan menggambarkan produk pekerjaan sedemikian sehingga
masing-masing pekerjaan dengan jelas dibedakan dari semua paket pekerjaan yang
lain dalam proyek itu. Mereka pada umumnya dilukiskan sebagai semua informasi
penting bagi seorang yang berkualitas untuk menyelesaikan pekerjaan itu. Untuk
proyek-proyek pengembangan perangkat lunak, ini pada umumnya berhubungan
dengan modul atau object terkecil yang bisa diidentifikasi untuk dibuat dalam suatu
deliverable sistem.
Isi dari suatu paket pekerjaan meliputi:
uraian tentang produk pekerjaan yang diharapkan- elemen perangkat lunak
untuk diproduksi;
kebutuhan terhadap kepegawaian - siapa atau berapa banyak orang-orang
akan melakukan aktivitas ini;
nama dari individu yang bertanggung jawab - siapa yang bertanggung jawab
atas penyelesaiannya;
penjadwalan tanggal mulai dan tgl berakhir - ketika aktivitas diharapkan
untuk mulai dan berakhir;
biaya yang dianggarkan - usaha menaksir aktivitas;
kriteria-kriteria penerimaan pekerjaan – tingkat cacat atau ukuran kualitas
lain.
Jika staff proyek telah mengetahui berbagai hal tersebut, sudah umum
terjadi dalam organisasi di mana kelompok yang sama sama sebagai perekayasa
perangkat lunak bekerja bersama setiap hari, kemudian penulisan suatu paket
pekerjaan yang formal menjadi tidak perlu karena mereka telah mengetahui tugas
tugas yang diperlukan untuk menyelesaikan aktivitas itu. Bagaimanapun,
diperlukan kendali yang lebih untuk mengorganisir suatu kelompok yang belum
pernah sebelumnya bekerja bersama dan tidak memiliki kultur perangkat lunak yang
umumnya dapat menyediakan suatu kerangka, maka menurunkan penulisan
informasi paket pekerjaan menjadi sangat menolong sebab akan memperkecil
kerancuan mengenai tugas mereka. Mungkin juga terjadi bahwa suatu paket
pekerjaan untuk suatu proyek menjadi lingkup pekerjaan untuk suatu sub proyek
24
yang utuh, yang lebih lanjut dibagi menjadi beberapa aktivitas, dikelola sebagai
suatu proyek yang berada jauh di bawah usaha yang lebih besar.
Suatu cara untuk membedakan suatu sub proyek dengan proyek utuh
adalah dengan menjawab pertanyaan apakah sub proyek bisa mandiri pada dirinya
sendiri, tanpa adanya konteks proyek yang lebih besar. Setoran produk pekerjaan
sub proyek mungkin bisa berupa modul perangkat lunak yang mandiri dan
bermanfaat diluar konteks lingkup proyek yang sekarang. Membuat tradisi utilitas
perangkat lunak adalah suatu contoh yang baik dari suatu sub proyek perangkat
lunak. Kebanyakan alat bantu penjadwalan (tool schedulling) manajemen proyek,
seperti Microsoft Project, mengalokasikan suatu tempat untuk mencatat masing-
masing aktivitas dan cara untuk mencetak mereka sebagai lembaran tugas.
II.6 PENGUKURAN BESAR PERANGKAT LUNAK
Memprediksi "ukuran" dari suatu sistem perangkat lunak akan lebih
membantu dan menjadikan proyek lebih mudah. Pengukuran yang dilakukan dalam
mengestimasi ukuran program selayaknya mudah digunakan di awal proyek dan
mudah dibaca ketika pekerjaan sudah selesai. Selanjutnya perbandingan besar
produk estimasi awal dengan pengukuran aktual kemudian digunakan untuk
menyediakan umpan balik ke estimator agar dapat membuat estimasi yang lebih
akurat.
Beberapa unit pengukuran perangkat lunak yang paling banyak digunakan ,
meliputi :
Lines of Code (LOC)
Function point
Jumlah node pada diagram alir data (DAD)
Jumlah entitas pada diagram relasi entitas (ER diagram)
Jumlah kotak proses (PSPEC) atau Kontak kontrol (CSPEC) pada suatu
bagan struktur
Jumlah pernyataan “sebaiknya” versus pernyataan “harus” dalam spesifikasi
kebijakan pemerintah
Jumlah dokumentasi
Jumlah obyek, atribut, dan layanan pada diagram obyek
Ketika perdebatan berlanjut pada pertanyaan apakah model terbaik untuk
pengukuran besar perangkat lunak , maka tidak ada jawaban yang dapat memenuhi
25
semua tujuan. Disatu sisi menghitung jumlah baris dari kode sumber mudah untuk
didefenisikan, dan telah digunakan secara luas juga difasilitasi dengan perhitungan
otomatis. Sayangnya sangat sulit untuk menghubungkan antara baris-baris kode
dengan deskripsi awal kebutuhan fungsional. Untuk menyelesaikan masalah ini
Albrecht merancang suatu metode estimasi yang disebut Functoin point. Di dalam
istilah yang paling sederhana function point dimulai dari perspektif user dan
mengestimasi ukuran aplikasi. Baris-baris kode adalah suatu pengukur produk dan
berhubungan lebih dekat kepada apa yang pengembang perangkat lunak inginkan
untuk dibangun. Keduanya mempunyai keunggulan dan kelemahan, maka sebelum
menjelaskan proses estimasi, dua metode ini akan dijelaskan secara singkat.
II.6.1. Mengestimasi Line of Code (LOC)
LOC mengestimasi secara tipikal dengan menghitung semua instruksi-instruksi
sumber dan mengabaikan komentar dan blank. sebagai contoh sebuah tool otomatis
didesain untuk menghitung semicolon (misal pada pascal satu baris ditandai dengan
semicolon). Bagaimanapun juga sangat sulit untuk memperkirakan baris-baris kode
dari statemen-statemen kebutuhan level tinggi. Pengukuran ini memfasilitasi suatu
proses pembelajaran sehingga meningkatkan estimasi. LOC juga memfasilitasi
penyimpanan dan pengambilan data ukuran yang dibutuhkan untuk meningkatkan
akurasi estimasi. Keunggulan utama dari LOC adalah bahwa LOC berhubungan
secara langsung kepada produk yang dibangun. Dengan demikian pengukuran
dilakukan setelah adanya fakta yang dibandingkan dengan rencana awal.
Ketika dekomposisi WBS telah sampai pada tingkatan terendah, suatu ukuran "
statistik" dapat dibuat melalui suatu pengukuran proses. Ukuran dari tiap
komponen dapat diperoleh dengan menanyakan pada tenaga ahli yang sudah pernah
mengembangkan sistem yang sama, atau dengan meminta pada pengembang sistem
yang berpotensi untuk mengestimasi ukuran dari tiap task pada tingkat terendah dari
WBS itu. Ketika ukuran dijumlahkan, jumlah total disebut sebagai penaksiran
ukuran " bottom-up". Suatu penaksiran yang lebih baik biasanya diperoleh jika
masing-masing penaksir diminta untuk menyediakan dalam suatu bentuk taksiran
terhadap ukuran optimis, pesimistis, dan realistis. Kemudian dapat dibentuk sebuah
distribusi beta dengan mengalikan taksiran ukuran realistis dengan 4, ditambah
ukuran optimis dan pesimistis, dan totalnya dibagi 6. Hasil rata-rata ini adalah suatu
konversi yang tidak dapat dipisahkan dari ketidakpastian penaksiran. Sebagai
contoh, diberikan suatu obyek window yang didekati dengan WBS sistem, kode
26
pendukung yang dibutuhkan untuk proses mengedit window itu diperkirakan antara
200-400 baris kode, dengan nilai keyakinan mendekati 250. Dengan pendekatan
nilai optimis dan pesimistis akan menghasilkan perkiraan hasil akhir sebagai
berikut :
Jumlah baris = nilai optimis + (nilai realistis x 4) + nilai pesimis
6
266 = 200 + (250 x 4) + 400
6
Jumlah seribu baris kode disebut sebagai KLOC (Kilo Lines of Code ).
Menghitung baris kode secara manual akan memakan waktu dan membosankan,
maka kebanyakan organisasi membeli atau membangun suatu peranti penghitung
LOC otomatis. Peranti ini dapat menjawab beberapa masalah yang kompleks
mengenai pertanyaan tentang persisnya apa yang disebut satu baris kode. Lagipula,
tidak jadi soal seperti apa kita menggambarkan LOC, sepanjang definisi tersebut
digunakan secara konsisten. Petunjuk perhitungan berikut ini telah digunakan
selama bertahun-tahun, untuk merekam ukuran program ada dan untuk menaksir
ukuran program yang dikembangkan:
Pastikan bahwa tiap-tiap " baris kode program" yang terhitung berisi
hanya satu statemen program ( jika dua statemen yang executable berada
pada satu baris, yang dipisahkan oleh suatu titik koma, maka dihitung
menjadi dua; jika satu statemen yang executable ada atau tersebar ke dua
/ beberapa baris, maka dihitung satu. Bahasa pemrograman menyediakan
pilihan pengkodean untuk bermacam-maccam keperluan, tetapi biasanya
tetap mudah untuk menentukan satu statemen tunggal yang executable
karena compiler atau interpreter melakukan hal yang sama.
Hitung semua setoran , termasuk statemen statemen yang executable -
pemakai akhir tidak akan secara langsung menggunakan setiap statemen,
tapi suatu produk bisa memerlukannya sebagai pendukungnya (seperti
utilitas)
Menghitung definisi data sekali saja
Jangan menghitung baris yang mengandung komentar
jangan menghitung kode debug atau kode yang bersifat temporer lainnya
seperti perangkat lunak pengujian, kasus uji, peranti bantu
pengembangan, peranti bantu prototipe, dan seterusnya
27
Hitung tiap-tiap defenisi permintaaan, pemanggilan, atau pemasukan
( kadang-kadang disebut compiler directive) dari suatu makro sebagai
bagian dari program yang memakainya ( jangan menghitung statemen
program yang dipakai ulang)
Terjemahkan banyaknya baris dari kode program ke baris bahasa
asembler padanannya sedemikian sehingga mungkin dapat dibuat
perbandingannya terhadap proyek-proyek lain
Kolom pertama dan kedua tabel... memberikan suatu metoda yang digunakan
secara umum untuk menterjemahkan baris kode program / sistem ( SLOC) dalam
berbagai bahasa ke jumlah rata-rata LOC program asembler. (catat bahwa SLOC
dan LOC dapat saling dipertukarkan) Banyak manager proyek yang menginginkan
suatu konversi semua bahasa ke dalam dasar asembler sedemikian sehingga suatu
perbandingan satu sama lain bisa dibuat terhadap proyek-proyek. Fungsi lain dari
data ini adalah untuk suatu proyek dalam suatu bahasa tertentu akan dikonversi ke
bahasa lain. Sebagai contoh, diberikan sautu sistem dengan 50.000 LOC yang ditulis
dalam bahasa Cakan dikonversi ke bahasa C++. Dengan menggunakan tabel 2.2.,
dasar assembler SLOC untuk bahasa C adalah 2,5, maka 50.000 SLOC sistem yang
ditulis dalam bahasa C ekivalen dengan 50.000 x 2,5 = 125.000 SLOC jika ditulis
dalam Basic Assembler. Dari 125.000 SLOC ini jika ditulis dalam bahasa C++
menjadi 125.000/6 = 20.833 SLOC.
Tabel 2.2. Konversi Bahasa Pemrograman ke Baris Kode Program Basic
Assembler per function point
BahasaBasic Assembler SLOC
(Level)
Rerata SLOC per
Function Point
Basic Assembler 1 320
Autocoder 1 320
Macro Assembler 1.5 213
C 2.5 128 – 150
DOS Batch Files 2.5 128
Basic 3 107
LOTUS Macro 3 107
ALGOL 3 105 -106
COBOL 3 105 – 107
28
FORTRAN 3 105 – 106
JOVIAL 3 105 – 107
Mixed Languages(default) 3 105
Pascal 3.5 91
COBOL (ANSI 85) 3.5 91
RPG 4 80
MODULA-2 4.5 80
PL/ I 4.5 80
Concurrent PASCAL 4 80
FORTRAN 95 4.5 71
BASIC (ANSI) 5 64
FORTH 5 64
LISP 5 64
PROLOG 5 64
LOGO 5.5 58
Ext Common LISP 5.75 56
RPG III 5.75 56
C++ 6 53
JAVA 6 53
YACC 6 53
Ada 95 6.5 49
CICS 7 46
SIMULA 7 46
Database Language 8 40
CLIPPER DB dan Dbase III 8 40
INFORMIX 8 40
ORACLE dan SYBASE 8 40
Access 8.5 38
Dbase IV 9 36
FileMaker Pro 9 36
Decision Support Languages 9 35
FOXPRO 2.5 9.5 34
APL 10 32
29
SAS 10 32
DELPHI 11 29
Object-oriented default 11 29
OBJECTIVE-C 12 27
Oracle Developer / 2000 14 23
SMALLTALK 15 21
awk 15 21
EIFFEL 15 21
UNIX shell Script (PERL) 15 21
4th Generation Default 16 20
Aplication Builder 16 20
COBRA 16 20
Crystal Reports 16 20
Datatrieve 16 20
CLIPPER 17 19
SQL 25 13 – 16
HTML 3.0 22 15
IEF / IEW 23 14
EASYTRIEVE+ 25 13
SQL (ANSI) 25 13
EXCELL 50 6
QUATRO PRO 51 6
Graphic Icon Languages 75 4
Salah satu cara untuk menaksir ukuran dari suatu sistem perangkat lunak
yang akan dikembangkan adalah dengan membandingkan kemampuan atau
fungsionalitasnya dengan sistem-sistem yang telah ada. Misalkan kita telah
mempunyai suatu komponen perangkat lunak , katakan modul A, yang harus
dibangun kembali dengan sistem yang baru. A mempunyai besar 2.345 LOC dan
kita yakin modul A yang baru nanti akan lebih efisien ( mungkin karena telah
dipelajari mulai dari awal sampai pemeliharaan A sehingga dapat diketahui
bagaimana membuat kodenya lebih ramping), tetapi karena terdapat beberapa fitur
30
tambahan yang dapat ditambahkan pada modul A itu nanti, maka kemudian modul
A yang baru ini diperkirakan terdiri atas 3000 LOC.
Metode ini tentu saja juga bukan suatu metode yang sangat akurat
mengingat modul A yang baru mungkin saja ditulis dalam bahasa pemrograman
yang berbeda, domain aplikasi yang berbeda, menggunakan algoritma yang berbeda,
level kompleksitas yang berbeda, dengan fungsionalitas yang belum diuji coba, dan
level realitas yang berbeda.
Contoh dengan kasus lain adalah sebagai berikut : diberikan suatu perangkat
lunak yang akan dikonversi dari bahasa COBOL,yang sebelumnya tanpa
menggunakan teknik desain, akan ditulis ke dalam bahasa C++ dengan
menggunakan desain berorientasi obyek. Dari ukuran program akan menurun karena
pada waktu sekarang telah dirancang secara lebih baik, bahkan kemampuan dan
mutunya pun lebih baik, tetapi biaya per baris kode ini naik 10% lebih tinggi.
Apakah ini terlihat sebagai kebocoran produktifitas ? Tentu saja tidak. Ini adalah
suatu peningkatan dalam produktifitas seperti halnya kemampuan dan daya
pemeliharaannya yang juga menjadi lebih baik.
Kelebihan-kelebihan menggunakan baris kode (LOC) ini sebagai unit
pengukuran perangkat lunak meliputi :
LOC ini sudah umum digunakan dan dapat diterima secara universal
LOC ini mengijinkan adanya perbandingan matriks ukuran dan
produktifitas antara kelompok-kelompok pengembangan yang berbeda beda
LOC ini berhubungan secara langsung dengan produk akhir
LOC lebih mudah diukur terhadap penyelesaian proyek
LOC mengukur perangkat lunak dari sudut pandang pengembang - yaitu
apa yang ia kerjakan.
Teknik estimasi ini memungkinkan adanya aktifitas untuk kenaikan
berkelanjutan - ukuran perkiraan dapat dengan mudah dibandingkan
dengan ukuran riil ketika sesudahnya dilakukan analisa terhadap proyek
tadi (seperti bagaimana keakuratan perkiraan, mengapa ia bisa mengubah
sekian persen?, apa yang bisa dipelajari dari sini untuk menilai ukuran
proyek berikutnya?, .. dan seterusnya).
Kelemahan-kelemahan menggunakan baris kode (LOC) adalah sebagai
berikut :
31
LOC kesulitan untuk menaksir perangkat lunak baru diawal tahap siklus
hidup pengembangan
Instruksi program berbeda menurut jenis bahasa pemrograman, metoda-
metoda disain, dan dengan gaya dan kemampuan programmer
Tidak adanya organisasi standarisasi ( seperti ISO) untuk menghitung baris
kode
Perangkat lunak melibatkan banyak biaya-biaya yang mungkin tidak
dipertimbangkan ketika melakukan pengukuran kode untuk menaksir biaya
– terdapat " biaya-biaya tetap" seperti biaya kebutuhan spesifikasi dan
dokumen-dokumen pemakai yag tidak dimasukkan dalam pengkodean.
Pemrogram mungkin akan menerima bayaran lebih untuk jumlah baris
kode yang besar jika pihak manajemen salah tanggap terhadap
produktifitas mereka dan tidak sebaliknya untuk pihak desainer, padahal
kode program bukanlah yang paling esensi dari suatu produk melainkan
pencapaian fungsionalitas dan performansi.
Penghitungan LOC seharusnya membedakan antara kode yang dihasilkan
dengan kode berdasarkan fungsinya - karena ini lebih sulit yaitu
menghitung utilitas, bukan hanya sekedar "menghitung langsung" kode,
yang sebenarnya bisa diperoleh dari daftar kode compiler
LOC tidak dapat digunakan untuk normalisasi jika platform atau bahasa
dibedakan
Hanya ada dua cara untuk memperkirakan jumlah LOC untuk perangkat
lunak baru yang akan dibangun yaitu pertama dengan menganalogikan
kesamaan fungsional dengan produk perangkat lunak yang telah ada dan
kedua dengan opini pakar, keduanya adalah metode yang kurang akurat
Sayangnya, produktifitas sering diukur dengan baris kode yang dihasilkan.
Jika seorang pemrogram bisa meningkatkan dari rata-rata 200 baris kode per bulan
menjadi 250 baris kode perbulan, manajer mengira bahwa produktifitasnya telah
meningkat. Hal ini adalah persepsi yang berbahaya yang sering mengakibatkan
pemrogram tergoda untuk menghasilkan baris kode yang lebih banyak per
desainnya. Tidak hanya pengembang yang menilainya mempunyai produktivitas
yang lebih tinggi, tetapi ia juga dianggap menghasilkan kode yang bersih. Beberapa
organisasi menggunakan rumus ini untuk mengukur mutu:
32
Jumlah cacat / jumlah baris kode
Jika pembagi besar, maka kualitas kelihatannya dibuat tinggi. Pada umumnya tahap
pengkodean mengkonsumsi hanya 7 % dari total usaha dan maksimum sekitar 20 %.
tetapi tentu saja kualitas kode yang terpenting, bukan volume.
II.6.2. Function_Point Sebagai Unit Pengukuran
Metode Function Point ( FP) didasarkan pada gagasan di mana ukuran
perangkat lunak akan lebih baik diukur dalam kaitannya terhadap jumlah dan
kompleksitas fungsi yang dikerjakannya dibanding dengan banyaknya baris dari
kode yang merepresentasikannya. Function point pertama kali dikenalkan oleh A.J.
Albrecht dari IBM yang ditulis di akhir 1970, untuk sistem yang berorientasi
transaksi. Capers Jones suatu korporasi dibidang Riset produktifitas perangkat
lunak, mengembangkan gagasan Albrecht ke suatu badan pengetahuan nasional.
Pada tahun 1986, suatu kelompok non profit, yang disebut The International
Function Point User Group (IFPUG) dibentuk untuk mengelola informasi
matriksnya. Tahun 1987, pemerintah Inggris mengadopsi function point yang
dimodifikasi sebagai matriks baku untuk produktivitas perangkat lunak. Kemudian
tahun 1994, dikenalkan Latihan Manual Penghitungan Function Point versi 4.0
(Function Point Counting Practices Manual Release 4.0) Standar IFPUG dan dirilis
Petunjuk Pengukuran Perangkat lunak versi 1.0 (Guidelines to Software
Measurement Release 1.0 ) Standard IFPUG.
Prinsip Function point :
Melengkapi unit standar dari pengukuran
Berdasarkan pada pandangan eksternal pemakai terhadap sistem
Pengukuran kerja produktif bersama dengan pengukuran usaha kerja
akan menghasilkan pengukuran produktifitas
Model estimasi yang mendasarkan pengukuran function-point untuk
produktifitas
Tujuannya adalah membangun pengukuran relatif dari nilai fungsi
hasil yang akan diserahkan, terlepas dari teknologi atau pendekatan
yang digunakan
Secara umum pendekatan dilakukan berdasar perhitungan (bobot
yang merefleksikan nilai tipe fungsi ) dari :
33
External input (data screen, ligt-pen, switch, transaksi dari
aplikasi lain)
External output (screen report, terminal report, screen
message, transaksi untuk aplikasi lain)
Logical internal file (Data base, user table, message table,
logical internal table)
File atau struktur data
External interface file (share data base, logical internal file
yang dapat diakses dari / ke aplikasi lain)
External inquiry (user inquiry tanpa update file, help
message and screen, pemilihan menu screen)
Langkah-langkah :
Kumpulkan dokumen dari sudut pandang user
Klasifikasikan ke dalam 5 tipe fungsi
Siapkan lembar kerja untuk masing-masing fungsi
Gunakan faktor pembobotan untuk setiap fungsi
Jumlahkan ke dalam function Count (FC)
Gunakan nilai dari 0-5 untuk masing-masing dari 14 karakteristik (N)
Jumlahkan ke dalam Processing Complexity (CF)
Hitung AFP = FP x CF
Konversikan ke LOC
Petunjuk Menghitung Function Point
Gambar 2.5. menunjukkan langkah-langkah dasar dalam menghitung
function point (FP) yang akan dijelaskan lebih lanjut. Tabel 2.3 menunjukkan input,
transformasi, dan output untuk tiap-tiap langkah dalam menghitung FP
Langkah 1. Hitung Jumlah fungsi untuk tiap kategori
Petunjuk Umum untuk Menghitung:
Hitung fungsi kebutuhan perangkat lunak saja
Hitung representasi logika, dimana beberapa input, output dan seterusnya
yang memerlukan logika pemrosesan yang berbeda, masing-masng
direpresentasikan sebagai function point yang unik.
34
Hitung jumlah fungsi untuk tiap kategori
Terapkan faktor pembobotan kompleksitas
Terapkan faktior lingkungan
Kalkulasi faktor kompleksitas
Hitung function point
Konversi ke baris kode
Gambar 2.5. Langkah-langkah Dasar dalam Analisis Function Point
Menghitung Output
Daftar berikut meliputi "tanda" untuk diingat ketika menghitung keluaran:
keluaran yang eksternal adalah berbagai hal diproduksi oleh perangkat lunak
yang pergi [bagi/kepada] bagian luar dari sistem
Output adalah unit informasi yang dihasilkan oleh perangkat lunak untuk
pemakai.
Contohnya meliputi: data screen, data report, pesan kesalahan, dst.
Tabel 2.3 Lembar worksheet Analisis FP
Langkah 1. Menghitung Jumlah Fungsi dalam tiap-tiap kategori
Langkah 2. Menerapkan faktor pembobotan kompleksitas
Sederhana Menengah Kompleks Function Point
Jumlah Output ____ x 4 ____ x 5 ____ x 7
Jumlah Input ____ x 3 ____ x 4 ____ x 6
35
Jumlah Inquiry Output ____ x 4 ____ x 5 ____ x 7
Jumlah Inquiry Input ____ x 3 ____ x 4 ____ x 6
Jumlah File ____ x 7 ____ x 10 ____ x 15
Jumlah Interface ____ x 5 ____ x 7 ____ x 10
Total FP :
Langkah 3. Menerapkan Faktor Lingkungan
Faktor Lingkungan Rating (0,1,2,3,4,5)
Komunikasi Data
Pemrosesan terdistribusi
Kebutuhan Performansi
Batasan Konfigurasi
Rating Transaksi
Online Inquiry dan / atau Entry
Efisiensi pemakai akhir
Online update
Pemrosesan Kompleks
Reusability
Kemudahan konversi / Install
Kemudahan Operasi
Digunakan dibeberapa site
Potensial terhadap perubahan fungsi
Total(N) :
Langkah 4. Kalkulasi Faktor Kompleksitas (CF)
CF = 0.65 + (0.01 x N) =
Langkah 5. Menghitung Kesesuaian Function Point (AFP)
AFP = FP x CF
Langkah 6. Konversi ke LOC (Optional)
LOC = AFP x LOC/AFP
Hitung tiap-tiap unit output unik sebagai keluaran aplikasi, suatu unit output
unik adalah jika ia memiliki format berbeda atau logika pemrosesan yang
berbeda
36
Masing-masing output ditambahkan ke salah satu dari tiga kategori, tergantung pada
kompleksitasnya: suatu output kompleks akan membutuhkan usaha lebih untuk
membuatnya dibanding output menengah ataupun yang sederhana. Bilangan yang
diapit tanda “()” menunjukkan bobot pengali. Petunjuk untuk menentukan
kompleksitas ditemukan di tabel 2.4.
Tabel 2.4 Faktor Pembobotan Output pada analisis Function Point
Merujuk 1-5 Data Merujuk 6-19
Data
Merujuk lebih dari
20 data
Merujuk 0 – 1 File Sederhana (4) Sederhana (4) Menengah (5)
Merujuk 2 atau 3 File Sederhana (4) Menengah (5) Kompleks (7)
Merujuk 4 atau lebih
File
Menengah (5) Kompleks (7) Kompleks(7)
Menghitung Input
Ingat Berikut ini ketika menghitung input :
Input eksternal adalah sesuatu yang diterima oleh perangkat lunak dari luar
sistem
Input adalah unit informasi yang diberikan pemakai pada perangkat lunak
untuk diproses atau disimpan
Hitung masing–masing unit input yang unik.
Sebagaimana output, input dibagi dalam kategori sederhana, menengah dan
kompleks untuk pembobotan. Petunjuk untuk menentukan kompleksitas diberikan
pada tabel 2.5.
Tabel 2.5. Faktor Pembobotan Analisa Input pada Function Point
Merujuk 1-5 Data Merujuk 6-19
Data
Merujuk lebih dari
20 data
Merujuk 0 – 1 File Sederhana (3) Sederhana (3) Menengah (4)
37
Merujuk 2 atau 3 File Sederhana (3) Menengah (4) Kompleks (6)
Merujuk 4 atau lebih
File
Menengah (4) Kompleks (6) Kompleks(6)
Menghitung Inquiry (Output/Input)
Ketika menghitung inquiries , ingat hal-hal berikut :
Eksternal inquiry adalah instruksi khusus atau permintaan agar perangkat
lunak merespon, membentuk, atau menurunkan sesuatu akibat masukan yang
diberikan.
Inquiry mengakses langsung ke database yang menerima data spesifik,
menggunakan kunci, dan membentuk fungsi-fungsi yang tidk mengubah
data.
Hitung tiap-tiap unit inquiry unik. Suatu inquiry dianggap unik jika
memenuhi salah satu berikut :
- Memiliki format yang berbeda dari yang lain baik input maupun
outputnya
- Memiliki format yang sama, baik input maupun output, dengan
inquiry lainnya tapi salah satu memiliki logika pemrosesan yang
berbeda
Inquiry dengan input dan output yang berbeda akan memiliki faktor bobot
kompleksitas yang berbeda
Query bukan suatu inquiry. Query biasanya diklasifikasikan sebagai salah
satu input atau otput karena ia sering menggunakan beberapa kunci dan
melibatkan operasi atau kalkulasi pada data
Inquiry dikelompokkan ke dalam kelompok : sederhana, menengah, dan
kompleks. Petunjuk untuk menentukan kompleksitasnya ditunjukkan oleh tabel
2.6.
Tabel 2.6. Faktor Pembobotan Analissi Inquiry Pada Function Point
Bagian Output (Catatan:
Pilih Nilai Tertinggi :
Merujuk 1-5 Data Merujuk 6-19
Data
Merujuk lebih dari
20 data
38
Output atau Input
Merujuk 0 – 1 File Sederhana (4) Sederhana (4) Menengah (5)
Merujuk 2 atau 3 File Sederhana (4) Menengah (5) Kompleks (7)
Merujuk 4 atau lebih
File
Menengah (5) Kompleks (7) Kompleks(7)
Bagian Input (Catatan:
Pilih Nilai Tertinggi :
Output atau Input)
Merujuk 1-5 Data Merujuk 6-19
Data
Merujuk lebih dari
20 data
Merujuk 0 – 1 File Sederhana (3) Sederhana (3) Menengah (4)
Merujuk 2 atau 3 File Sederhana (3) Menengah (4) Kompleks (6)
Merujuk 4 atau lebih
File
Menengah (4) Kompleks (6) Kompleks(6)
Meghitung Struktur Data (File)
Hal-hal yang harus diingat ketika menghitung struktur data / File meliputi :
File internal adalah File yang secara logik berada dalam program
Struktur data dikenal sebagai “file” adalah kelompok data user utama yang
secara permanen disimpan dalam lingkungan sisitem perangkat lunak
Struktur data dijangkau pemakai melalui input, output, inquiry, atau interface
Struktur data dibagi kedalam : sederhana, menengah, dan kompleks. Petunjuk untuk
menentukan kompleksitas ditunjukkan dalam tabel 2.7.
Menghitung Interface
Ketika menghitung interface, beberapa hal yang harus diingat adalah :
File eksternal adalah file turunan mesin yang digunakan program
Interface adalah data (dan kontrol) yang disimpan diluar lingkungan
perangkat lunak sistem yang dievaluasi
Struktur data bersama diantara sistem-sistem dihitung sebagai interface dan
juga struktur data
39
Hitung tiap-tiap data dan aliran kontrol menurut arahnya sebagai interface
unik
Tabel 2.7. Faktor Pembobotan Analisis File Pada Function Point
Catatan: Hitung Relasi
secara logik bukan tipe
record secara fisik
Merujuk 1-19
Item Data
Merujuk 20-50
Item Data
Merujuk lebih dari
50 Item Data
Relasi / Format 1 record
lojik
Sederhana (7) Sederhana (7) Menengah (10)
Relasi / Format 2-5 record
lojik
Sederhana (7) Menengah
(10)
Kompleks (15)
6 atau lebih record lojik Menengah (10) Kompleks (15) Kompleks(15)
Interface dibagi ke dalam sederhana, menengah dan kompleks. Petunjuk untuk
menentukan kompleksitas ditunjuk dalam tabel 2.8.
Tabel 2.8. Faktor Pembobotan Analisis Interface Pada Function Point
Catatan: Jumlah Relasi
secara logik bukan tipe
record secara fisik
Merujuk 1-19
Item Data
Merujuk 20-50
Item Data
Merujuk lebih dari
50 Item Data
Relasi / Format 1 record
lojik
Sederhana (5) Sederhana (5) Menengah (7)
Relasi / Format 2-5 record
lojik
Sederhana (5) Menengah (7) Kompleks (10)
6 atau lebih record lojik Menengah (7) Kompleks (10) Kompleks(10)
Langkah 2. Terapkan Faktor Pembobotan Kompleksitas
kalikan masing-masing jumlah masing-masing kategori (sederhana,
menengah, kompleks) dalam tiap kategori (output, input,
40
inquiry[output/input], struktur data[file], interface) dengan faktor penimbang
yang sesuai
Jumlahkan total dari tiap kategori. Ketika langkah 1 dan langkah 2
dilaksanakan maka hasilnya akan terlihat seperti tabel 2.11.
Ingat hasil total ini dalam jumlah function point murni.
Langkah 3. Terapkan Faktor Lingkungan
lakukan penyesuaian jumlah function point murni terhadap faktor lingkungan yang
mempengaruhi proses pengembangan perangkat lunak. Beberapa aspek lingkungan
mungkin akan mempengaruhi proses pengembangan perangkat lunak. Beberapa
aspek ini mempengaruhi proyek secara positif, dan disisi lain menimbulkan
pengaruh negatif.
Tabel 2.9 memuat suatu defenisi detil terhadap 14 faktor lingkungan.
Menggunakan tabel 2.9, setiap faktor diberi skala 0 sampai 5 (0 berarti tidak dapat
diaplikasikan). Untuk membantu menaksir batas spektrum, tabel 2.10. berisi contoh-
contoh sistem perangkat lunak yang akan dinilai tinggi - dengan skala 4 atau 5.
Jumlahkan rating factor (Fn) untuk mengkalkulasi total Faktor Pengaruh
Lingkungan (N) :
N = sum (Fn)
Gunakan Tabel Function point dalam Tabel 2.3. untuk merekam nilai. Rujuk tabel
2.11. untuk melihat bagaimana hasilnya setelah langkah 3 dilakukan.
Tabel 2.9. Deskripsi Analisis Faktor Lingkungan pada Function Point
Faktor lingkungan Rating (0,1,2,3,4,5)
Komunikasi data Informasi data atau kendali dikirim atai diterima
melalui fasilitas komunikasi data. Sistem online
dipengaruhi oleh komunikas data.
Pemrosesan Terdistribusi Aplikasi menggunakan data yang disimpan, diakses
atau diproses pada suatu storage lain atau memproses
sistem lain selain dari sistem yang digunakan pada
sistem utama tersebut.
Kebutuhan Performansi permintaan user yang telah disetujui dibuat dengan
throughput luar biasa tinggi atau memiliki respon
41
waktu yang cepat
Batasan Konfigurasi Aplikasi akan dijalankan pada konfigurasi yang
ketat,berat atau padat
Rating Transaksi Trafik jaringan tinggi, layar penuh dengan informasi
dan grafik, frekuensi transmisi layar tinggi
Online Inquiry dan/ atau
Entry
Terlalu Interaktif
Efisiensi pemakai akhir Pertimbangan faktor manusia perlu ditambahkan
Online Update Update database dinamis, database terdistribusi
Pemrosesan kompleks keamanan yang tinggi, proses transaksi yang berat,
algoritma yang kompleks, interupsi logika kendali
Reusability Kode yang didesain untuk dapat dipakai ulang harus
berkualitas tinggi
Kemudahan Konversi /
install
Konversi dan instalasi memerlukan dokumen
perencanaan yang telah diuji
Kemudahan operasi Efektif tetapi tetap mudah untuk melakukan prosedur
start, backup, error recovery dan shutdown. Aktifitas
manual dibuat minimal
Digunakan dibeberapa site Account meliputi fungsi bisnis yang berbeda-beda
Potensial terhadap
perubahan fungsi
Bersifat modular, table-driven, user-maintened,
kapabilitas query fleksibel, dan seterusnya
Langkah 4. Kalkulasi Faktor
II.7 ESTIMASI
Karakteristik Estimasi
Estimasi didasarkan pada model probabilitas, bukan deterministic
Estimasi pada suatu angka dalam suatu selang dari suatu kuantitas yang
diestimasi
Kepercayaan pada estimasi tergantung pada ukuran selang dari kuantitas
yang diestimasi
Kepercayaan pada estimasi tergantung pada ukuran selang dari kuantitas
yang diukur
Informasi yang cukup banyak (sebagai dasar estimasi) akan memperkecil
selang dan memperbesar kepercayaan
42
Informasi yang sangat relevan yang dipakai sebagai dasar estimasi adalah
dalam selang yang kecil
Beberapa kemungkinan penyebab lemahnya estimasi
Kita tidak mengembangkan kepakaran estimasi
Kita tidak membuat cukup syarat untuk menggantikan akibat dari bias
Kita tidak memiliki cukup pengertian dari apa yang seharusnya diestimasi
Kita tidak mendasarkan estimasi pada ukuran performansi waktu yang lalu
Pemodelan Estimasi Empiris dengan COCOMO (Constructive Cost Model)
Pada perencanaan pengembangan perangkat lunak diperlukan suatu model
perhitungan ( estimation model) dengan menggunakan rumusan-rumusan yang
diturunkan secara empiris untuk memprediksi data-data yang diperlukan pada setiap
tahapannya.
Model sumber terdiri dari paling sedikit satu persamaan empiris untuk
berusaha memprediksi berbagai hal misalnya :
Kemajuan proses pengembangan (dalam satuan orang – bulan)
Lamanya proyek
Ukuran staf
Jumlah baris kode program
Selanjutnya Basili membagi kelas-kelas model sumber ke dalam empat jenis
model yaitu :
Model static single-variable
Model static multivariable
Model dynamic multivariable
Model theoritical
Pada diktat ini hanya akan dibahas rumusan model Model static single-variable dan
model static multivariable.
Model static single-variable mengambil bentuk :
Resource = c1 . (karakteristik perhitungan)c2
43
Dimana :
Resource bisa berupa kemajuan yang dicapai, lamanya proyek, ukuran staf,
jumlah baris kode program
C1 dan c2 adalah konstanta yang diambil dari kumpulan data yang terkoleksi
dari proyek sebelumnya
Karakteristik perhitungan yang bisa berupa jumlah baris kode sumber,
kemajuan pengembangan dan karakteristik perangkat lunak lainnya
Model static multivariable seperti model sebelumnya mengambil bentuk data
historis ke dalam persamaan :
Resource = c11.e1 + c21.e2 + …
Dimana :
ei adalah karakteristik perangkat lunak yang ke i
ci1, ci2 adalah konstanta yang secara empiris diturunkan dari karakteristik ke i
resource bisa berupa kemajuan yang dicapai, lamanya proyek, ukuran staf,
jumlah baris kode program
Cocomo dikemukakan oleh Barry Boehm dan merupakan model perhitungan
perangkat lunak secara hirarkis yang mengambil bentuk antara lain :
Model 1 : BASIC COCOMO
Adalah model static single valued yang menghitung kemajuan dan biaya
pengembangan perangkat lunak sebagai fungsi dari ukuran program yang
dalam hal ini dinyatakan dalam perhitungan jumlah baris kode program
Model 2 : INTERMEDIATE COCOMO
Model ini menghitung kemajuan pengembangan perangkat lunak sebagai
fungsi dari ukuran program dan kumpulan komponen biaya lainnya yang
termasuk penilaian subyektif dari produk, perangkat keras, personil dan
komponen proyek lainnya.
Model 3 : ADVANCE COCOMO
Model ini menggabungkan semua karakteristik dari versi Intermediate
Cocomo dengan tambahan penilaian dari komponen biaya yang berpengaruh pada
tiap tahapan dari pengembangan perangkat lunak (analisis, desain, pengkodean,
implementasi dan pemeliharaan).
Cocomo dapat diaplikasikan ke dalam 3 kelas dari proyek pengembangan
perangkat lunak diantaranya :
44
Mode Organic
Mode ini diterapkan pada kelas proyek untuk pengembangan perangkat lunak
yang sederhana dan tidak terlalu besar. Tim pengembang bisa berupa tim kecil
yang biasa bekerja sama dan telah berpengalaman dalam pengembangan
aplikasi. Kebutuhan perangkat lunak yang dikembangkan biasanya bersifat
fleksibel.
Mode Semi-Detached
Mode ini diterapkan pada kelas proyek yang agak kompleks dan melibatkan
personil dalam tim yang agak besar. Personil bisa berasal dari berbagai
bidangn dan tingkatan pengalaman yang bervariasi. Dengan demikian tingkat
pemenuhan kebutuhan yang beragam pula.
Mode Embedded
Mode ini diterapkan pada kelas proyek yang rumit. Dalam mode ini terdapat
hubungan yang sangat kuat antara perangkat lunak, perangkat keras dan
batasan operasi yang harus dipenuhi sistem, seperti dalam pengembangan
perangkat lunak pengatur lalu lintas pesawat udara
Persamaan untuk model BASIC COCOMO adalah :
E = ab (KLOC)exp(bb)
D = cb (E) exp (db)
Dimana:
E merupakan satuan usaha dalam orang- bulan
D merupakan waktu pengembangan dalam bulan yang berurutan
KLOC perkiraan jumlah baris kode program (dalam ribuan)
ab, cb, bb, db adalah koefisien seperti yang diberikan pada table berikut :
Proyek PL ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Selanjutnya model ini dapat dikembangkan dengan mempertimbangkan
kumpulan sifat-sifat penggerak komponen biaya yang dapat dikelompokkan ke
dalam 4 kategori umum yaitu :
45
1. Sifat produk
Kehandalan dari perangkat lunak yang dibutuhkan
Ukuran dari aplikasi database
Kompleksitas dari produk
2. Sifat Perangkat lunak
Batasan performansi pada saat run-time
Batasan memori
Keseimbangan dari lingkungan virtual machine
Waktu perubahan yang diperlukan
3. Sifat personil
Kemampuan analisis
Kemampuan perekayasa perangkat lunak
pengalaman dalam pengembangan aplikasi
pengalaman terhadap virtual machine
pengalaman terhadap bahasa pemrograman
3. Sifat proyek
penggunaan perangkat lunak pembantu
penerapan dari metoda-metoda dalam rekayasa perangkat lunak
jadwal pengembangan yang diperlukan
Tiap sifat ini berharga dari yang paling kecil sampai paling besar pada skala 6.
Kemudian nilai ini dikalikan dengan factor pengali yang didapat dari table Boehm.
Hasil penjumlahan keseluruhan merupakan nilai effort adjusment factor (EAF) yang
biasanya berkisar dari 0,9 sampai 1,4
Persamaan untuk model Intermediate Cocomo adalah :
E = ai (LOC) exp (bi). EAF
Dimana :
E merupakan satuan usaha dalam orang-bulan
LOC perkiraan jumlah baris kode program
ai, bi adalah koefisien seperti yang diberikan pada table berikut ;
46
Proyek PERANGKAT
LUNAK
ai bi
Organic 3.2 1.05
Semidetached 3.0 1.12
Embedded 2.8 1.20
Contoh aplikasi BASIC COCOMO
Sebuah perusahaan perdagangan membuat aplikasi bisnis untuk mendukung
penyediaan informasi yang diperlukan. Pada tahap pengembangannya melibatkan
seluruh bagian yang terlibat dalam hal perumusan sistem yang tepat, seperti bagian
keuangan, penjualan, pembelian, gudang, pembukuan, akutansi dan bagian EDP.
Aplikasi dibagi ke dalam 7 modul besar yaitu :
modul pembelian
modul penjualan
modul general ledger
modul account receivable
modul account payable
modul pemeliharaan data stok
modul utilitas
pada akhir proses pengkodean didapatkan distribusi ukuran baris kode program
sesuai dengan modul-modul yang ada sebagai berikut :
Modul Jumlah baris kode program (LOC)
modul pembelian 31500
modul penjualan 32250
modul general ledger 17600
modul account receivable 18050
modul account payable 19600
modul pemeliharaan data stok 25000
modul utilitas 12000
TOTAL 156000
Dari table di atas diketahui jumlah baris program daro keseluruhan modul adalah
156.000 baris.
47
Penentuan penggunaan model estimasi dilakukan sebagai berikut :
Pemilihan model BASIC COCOMO dilakukan karena dasar perhitungan
hanya didasarkan pada ukuran program yang dalam hal ini jumlah baris kode
program
Pemilihan model semi-detached dari model BASIC COCOMO adalah karena
pengembangan aplikasi ini melibatkan personil yang agak besar dan dari
berbagai bidang dan keahlian yang berbeda
Selanjutnya perhitungan dilakukan terhadap komponen-komponen:
usaha pengembangan dalam satuan orang-bulan
E = ai (LOC) exp (bi). EAF
= 3.0 (156)1.12
858 orang-bulan
jangka waktu proyek yang diperlukan dalam satuan bulan ditentukan
dengan :
D = 2.5 (E) exp (0.35)
= 2.5 (858)
26 bulan
jumlah personil yang diperlukan dalam satuan orang ditentukan dengan :
N = E/D
= 858 / 26
= 33 orang
II.7 PENJADWALAN
Ada beberapa teknik penjadwalan yang dapat digunakan yaitu :
Gantt Chart
Diagram Milestone
Metoda Jaringan Kerja
Kurva S
Gantt Chart
Dikembangkan sekitar tahun 1900 oleh Henry Gantt
Saat ini digunakan secara luas
Berisi kumpulan garis / bar horizontal yang dibuat berskala waktu
48
Setiap bar merepresentasikan aktifitas
Awal dan akhir garis menunjukkan jadwal mulai dan selesai
Terdapat beberapa variasi saat ini, untuk membedakan digunakan warna
Kelebihan dan kekurangan Gantt Chart :
Kelebihan Kekurangan
Efektif untuk komunikasi Tidak menunjukkan interdependensi
Mudah dibuat Tidak menguji dampak perubahan suatu
aktifitas
Ringkas Sulit dimodifikasi
Grafikal Sulit untuk memelihara proyek yang besar /
compels
Dapat menjadi sangat rumit, sulit
diinterpretasi / dibaca
Contoh :
49
aktifitas
A
Waktu (minggu)
B
C
D
E
0 1 2 3 4 5 6
…
direncanakan
aktual
Diagram Milestone
Patok-patok kejadian (events) penting pada suatu proyek yang waktunya
sudah ditetapkan dari awal
Dibuat pada bar chart, sehingga diketahui hubungan antara aktifitas
Diperiksa dan disetujui oleh pelanggan
Menunjukkan interface kejadian antara langkah langkah pada SDLC
(software Development Life Circle)
Sangat berguna untuk awal menuju penggunaan metoda jaringan kerja
Kelebihan dan kekurangan :
Kelebihan Kekurangan
Mudah dibuat Tidak menunjukkan interdepedensi
Ringkas Tidak mencukupi untuk menelusuri
kemajauan kerja
Grafikal
Contoh :
50
waktu
Milestone
UR D I T UR - User RequirementD - DesignI - ImplementationT - Testing
Metoda Jaringan Kerja
Fokus pada interdependensi aktifitas
Menampilkan proyek sebagai jaringan kerja dari beberapa aktifitas
Bila ditinjau cara merepresentasikan kegiatannya, ada 2 jenis :
Activity on arrow (AOA)
Kegiatan dinyatakan dalam bentuk panah, yang berhubungan
satu dengan lainnya melalui titik simpul (node) event
Kegiatan sebagai elemen utama yang diberi perhatian
Activity on node (AON)
Kegiatan dinyatakan dalam titik simpul,keterkaitan antara
kegiatan dinyatakan dalam panah
Ada 3 fokus utama : aktiftas
Kejadian
Aktifitas semu (dummy)
Aktifitas :
Kumpulan gerakan atau rangkaian kerja proyek dari satu titik ke titik lainnya
dalam suatu waktu
Lambang
Kejadian :
Kondisi tertentu yang terjadi pada saat tertentu atau suatu penyelesaian dari
sutau kumpulan aktifitas. Awal dan akhir aktifitas dinyatakan oleh suatu
kejadian.
Lambang
Aktifitas semu (dummy) :
Aktifitas yang tidak ada kerja riil yang diwakilinya (zero time activity)
digunakan karena adanya ketergantungan logis dari suatu jaringan kerja
Bila ditinjau dari cara pendekatannya , ada 2 tipe :
CPM (Critical Path Method)
PERT (Program Evaluation and Review Technique )
Perbandingan antara CPM dan PERT :
CPM (Du Pont) PERT (Boez &Hamilton)
51
Beroroientasi ke depan untuk proyek
yang terdefenisi baik (biasanya industri
konstruksi)
Berorientasi ke depan tetapi dengan
pendefenisisan yang tidak pasti
(biasanya proyek (R&D))
Berkaitan dengan biaya dan waktu Berkaitan dengan 3 waktu estimasi : T0,
Tp, Tm
Mengutamakan biaya sebagai obyek
yang dianalisis (biaya percepatan
minimum)
Parameter utama waktu penyelesaian
pekerjaan
Istilah :
TE : Earliest Time of Occurrence (waktu paling awal peristiwa boleh terjadi)
TL : Latest time of occurrence (waktu paling akhir peristiwa boleh terjadi)
ES : Earliest start (waktu paling awal kegiatan)
EF : Earliest finish (waktu selesai paling awal suatu kegiatan)
LS : Latest start (waktu paling akhir kegiatan boleh diawali)
LF : Latest finish (waktu paling akhir kegiatan boleh selesai)
D : duration
Hitungan maju :
EFij = ESij + Dij
Hitungan mundur :
LSij = LFij - Dij
Sifat jalur kritis :
Pada pelaksanaan awal ES =LS=0
Pada pelaksanaan terakhir LF=EF
Total float TF = 0, TF = Lj – Ei - Dij
Contoh :
Suatu proyek dipecah ( memiliki WBS) menjadi aktifitas-aktifitas sebagai berikut :
Aktifitas Aktifitas pendahulu waktu
52
A - 10
B - 8
C - 12
D A 22
E B 27
F B 7
G B,C 15
H D,E 8
I F 20
J D,E,G 15
Maka kegiatan kegiatan ini dapat digambarkan dalam jaringan kerja sebagai berikut:
Latihan :
Diberikan kegiatan-kegiatan sebagai berikut :
Aktifitas Prasyarat waktu
A - 3
B A 4
C - 4
D B,C 8
E B,C 5
F E 3
G D 2
H G,F 2
I H 2
53
10
03
8
8
412
20
615
30
735
35
150
50
535
352
10
13
B
A
C
D
E
F
G
H
I
J
10
8
12
22
27
7
15
8
20
15
D1
D2
J I 3
Diitanya:
1. Buat diagram jaringan kerja (CPM)?
2. Hitung nilai EF, LS, dan Jalur kritis?
54
Kurva S
Grafik yang disusun untuk menunjukkan hubungan antara nilai kumulatif
biaya / jam- orang / prosentase penyelesaian pekerjaan terhadap waktu
Langkah pembuatan kurva S
1. buat bar chart (jadwal pelaksanaan)
2. alokasikan anggaran yang disediakan untuk setiap kegiatan pada
setiap periodenya
3. hitung prosentase penyerapan dana untuk setiap periode
4. hitung prosentase kumulatif penyerapan dana / periode
5. gambarkan dalam sumbu kartesian antara prosentasi kumulatif
dengan waktu (periodenya)
55
percepatan
keterlambatan
waktu
% kumulatif penyerapan dana
: rencana
: aktual
Contoh :
1. Bar Chart
Kegiatan Pendahulu waktu (bln) anggaran(Rp Juta)
A - 3 5
B - 6 5
C A,B 6 60
D C 3 10
E C 1,5 20
2. Alokasi anggaran
D1
D2
3. Prosentasi kumulatif penyerapan dana
Kegiatan Periode (3 bulan) anggaran (Rp. Juta)
1 2 3 4 5
A 5 5
B 3 2 5
C 30 30 60
D 10 10
E 20 20
Kebutuhan
Per periode 8 2 30 30 30 100
% penyerapan
perperiode 8(8/100) 2 30 30 30
% kumulatif
penyerapan 8 10 40 70 100
56
B(6)
A(3) C(6) D(3)
E(1,5)
57