Bab 5 IT Project Estimates (Anggaran Projek IT)
5.1 Software Estimates (Anggaran Perisian)
Anggaran adalah
taksiran hasil kuantitatif
Anggaran
perisian merangkumi
anggaran usaha, kos, jadual dan pekerja (jumlah perkerja)
Usaha (effort) adalah jumlah jangka masa yang diperlukan
oleh seseorang untuk menyiapkan tugasan
Jadual
(schedule) adalah jumlah
jangka masa yang dirancang untuk melengkapkan tugas
Anggaran untuk
pembangunan projek perisian mesti mempunyai unit ukuran. Contoh: usaha (effort)
di ukur dalam seorang dalam jam (person-hours), seorang dalam seminggu
(person-weeks), seorang dalam bulan
(person-months) dll. Unit ukuran yang digunakan adalah untuk pengkhususan:
a)
Produk
(rekabentuk, kod sumber dll)
b)
Proses
(aktiviti analisis, rekabentuk dan pengkodan dll)
c)
Manusia
(people) (produktiviti rekabentuk
individu dll)
Anggaran yang baik berupa penerangan mengenai skop projek, penilaian teknik yang digunakan, dan ketepatan anggaran yang dibuat. Anggaran awalan akan menghasilkan keputusan yang tepat dan boleh dipercayai anggarannya dan faktor kos yang mempengaruhi pembangunan perisian mudah difahami. Anggaran ada satu proses yang berterusan apabila berlaku perubahan dari segi skop, perubahan perlu dilakukan apabila berlaku perbezaan parameter seperti usaha, kos, jadual, kakitangan dll.
5.1.1 Benefits
Manfaat terhadap anggaran perisian adalah:
5.1.2 Stages where Estimates are Done (Peringkat
Dimana Anggaran Selesai)
|
Peringkat |
Penerangan |
|
Strategic Planning (Perancangan Strategik) |
Kos dan faedah daripada pengkomputeran aplikasi yang berpotensi harus
dianggarkan untuk menentukan keutamaan yang perlu diberikan pada setiap
projek |
|
Feasibility Study (Pengkajian Kebolehlaksanaan) |
Pengajian kebolehlaksanaan mesti dipastikan manfaat daripada sistem yang
dicadangkan dapat dijustifikasi ke atas kosnya |
|
System Specification (Spesifikasi Sistem) |
Usaha itu diperlukan untuk dilaksanakan usul reka bentuk yang berbeza
perlu dibuat anggaran. Anggaran pada peringkat reka bentuk juga mesti
dipastikan pengkajian kebolehlaksaan masih munasabah |
|
Evaluation of Supplier’s Proposals (Penilaian Cadangan Pembekal) |
Kakitangan di dalam software house yang menimbangkan cadangan atau tender
mesti disemak dengan spesifikasi sistem dan menyediakan anggaran berdasarkan
cadangan penilaian tersebut |
|
Project Planning (Perancangan Projek) |
Sebagai perancangan dan pelaksanaan tentang kemajuan projek kepada
peringkat yang lebih terperinci, lebih terperinci anggaran terhadap elemen
kerja yang kecil akan dibuat |
Anggaran dibuat pada pelbagai peringkat terhadap projek perisian. Pada setiap peringkat, alasan untuk anggaran dan metod yang digunakan tidak sama. Langkah penting seperti yang ditunjukkan pada jadual di atas.
|
Parkinson’s Law |
Brooks’ Law |
|
“Work
expands to accommodate the time available” |
“Putting more people on a late job makes it later”. |
|
This implies that given an easy target, staff will work
less hard. |
The effort required to implement a project will go up
disproportionately with the number of staff assigned to the project. |
5.1.3 Problems
with Over-estimates dan Under-estimates (Masalah Anggaran berlebihan dan
Anggaran Terkurang)
Terlebih anggaran boleh menyebabkan projek mengambil masa yang lama dari sepatutnya.
Terkurang anggaran boleh menyebabkan projek mengambil masa lebih singkat dari satu anggaran murah hati. Bahaya kepada anggaran terkurang adalah ia akan memberi kesan kepada kualiti. Kakitangan yang kurang mahir mungkin terdesak dengan tarikh akhir projek itu perlu disiapkan dan akan melakukan kerja yang tidak berkualiti (sub standard).
Anggaran terkurang akan menyebabkan jumlah pekerja akan dikurangkan oleh
pengurus dan akibatnya meningkatkan tekanan terhadap pekerja yang terlibat
dalam projek tersebut.
5.1.4 Software
Estimation Process (Proses Anggaran Perisian)
Anggaran perisian adalah proses terus menerus yang mesti digunakan sepanjang kita hayat projek. Proses mengenai saiz, kos dan jadual perisian bermula dengan definasi keperluan fungsian yang diperlukan dalam projek. Dua atau lebih orang mesti terlibat di dalam membuat anggaran pembangunan. Pengurus projek tidak sepatutnya bergantung kepada seseorang atau metod untuk membina anggaran perisian.
Terdapat lima
prosedur untuk proses anggaran perisian iaitu:
|
Prosedur |
Penerangan |
|
Estimate Size (Anggaran saiz) |
Produk perisian selalunya diukur dalam Source
Lines Of Code (SLOC). WBS, SLOC
atau fungsi mata boleh digunakan untuk menanggarkan saiz perisian produk.
Tentukan sama ada perisian tersebut dibangunkan menggunakan kod sumber baru
atau kombinasi kod baru dengan kod lama. Anggaran kos untuk penyesuaian kod
sedia adalah sama penting dengan anggaran kos untuk kod baru. Malah
kadang-kadang penyesuaian kod lama lagi sukar untuk dibangunkan. Anggaran
saiz perisian produk mesti berdasarkan kepada data lama (jika ada) dan
pengalaman yang lepas-lepas |
|
Estimate Cost
and Effort (Anggaran Kos dan Usaha) |
Kunci utama pada peringkat ini adalah anggaran saiz untuk projek
tersebut. Anggaran mesti termasuk semua aktiviti pekerjaan yang terlibat
dengan tugas. Aktiviti ini termasuk upah pekerja untuk tugas kerja lain yang
terlibat dengan projek tersebut. Anggaran kos perlu dibuat seawal kitar hayat
projek iaitu sebaik sahaja keperluan perisian ditentukan. Anggaran kos
selalunya mengenai usaha (effort) atau orang sehari/minggu, yang mana boleh
diterjemahkan sebagai asas kadar upah buruh. Contoh: Kos untuk 20
bulan kitar hayat projek adalah pada kadar 17.8 orang sehari, Kadar bayaran
adalah RM 200 seorang sehari, maka jumlah kos adalah RM 71,200 |
|
Estimate
Schedule (Anggaran Jadual) |
Tujuan membuat anggaran jadual adalah untuk menentukan jumlah masa
(length of time) yang diperlukan untuk menyiapkan projek dan menentukan
milestones yang utama dan membuat penilaian akan berlaku. Sebelum proses ini,
anggaran fungsian WBS, saiz dan kos mesti disiapkan. Jadual anggaran boleh
dihasilkan dengan cara manual atau dengan menggunakan model anggaran
automatik atau kedua-duanya sekali |
|
Inspect and
Approve Estimate (Memeriksa dan Menyokong Anggaran) |
Tujuan pada peringkat ini adalah untuk meningkatkan kualiti anggaran yang dihasilkan dan mendapatkan komitmen pengurusan atasan. Objektif pada peringkat ini termasuk:
|
|
Track Estimates
(Prestasi
Anggaran) |
Tujuan pada
peringkat ini adalah untuk memeriksa ketepatan anggaran apabila masa berlalu
dan membangunkan data empiris dengan berlalunya masa. Anggaran mesti dlihat
merentas masa untuk membandingkan perancangan dengan keadaan sebenar yang
mendatang. Ini membolehkan kakitangan projek melihat progres dan bagaimana
ketepatan mereka membuat anggaran. |
5.1.5 Basic for Software Estimation (Asas Kepada Anggaran Perisian)
The Need for Historical Data (Perlu Data Bersejarah)
Kebanyakkan metod anggaran memerlukan maklumat
mengenai bagaimana projsek dilaksanakan dimasa lalu. Data yang ada perlu
dinilai mengikut kepakaran orang yang menganggar itu, ini kerana setiap projek mempunyai
persekitaran yang berbeza seperti bahasa pengaturcaraan berlainan, alat bantuan
perisian yang ada, piawai yang dilaksanakan dan kemahiran kakitangan.
Measure of Work (Ukuran Kerja)
Masa yang digunakan untuk menulis sesuatu program
akan berbeza mengikut kemampuan dan kemahiran juru aturcara. Masa pelaksanaan
mungkin berbeza kerana faktor persekitaran projek. Amalan biasa digunakan untuk menyatakan kandungan kerja yang
perlu dilakukan terhadap sistem yang akan dibangunkan adalah dengan menggunakan
ukuran seperti SLOC. Penggunan jadual atau diagram atau cara anggaran saiz yang
mengunakan keperluan fungsian.
Complexity (Kerumitan)
Dua porgram yang mempunyai SLOC atau KLOC
(thousand lined of Code) yang sama tidak semestinya mengambil masa yang sama untuk
menulisnya walaupun dibuat oleh pembangun perisian yang sama pada persekitaran
yang sama. Satu program mungkin lebih rumit dari problem yang lain. Kerumitan
sesuatu kerja perlulah diambil kira dalam membuat anggaran.
5.2 Software Effort Estimation Techniques (Teknik
Anggaran Usaha Perisian)
5.2.1 Bottom-up Estimation (Anggaran dari Bawah ke
Atas)
Dengan menggunakan pendekatan dari bawah ke atas,
anggaran terhadap projek dipecahkan kepada tugas-tugas komponen dan kemudian
anggaran terhadap usaha yang perlu dilakukan akan dikira untuk setiap
tugas.Dengan projek yang besar, proses memecahkan akan dilakukan berulang kali,
setiap tugas akan dianalisis kepada komponen sub tugas dan ditukar untuk
analisis seterusnya. Setiap tugas ada jumlahkan untuk mendapat anggaran
keseluruhan. Keadah ini amat sesuai digunak untuk memperolehi maklumat yang
lebih terperinci dan merupakan peringkat perancangan projek. Dimana projek
tersebut merupakan projek baru atau tiada data lama yang dapat diguna pakai
maka kaedah dari atas ke bawah (bottom-up) adalah lebih sesuai.
5.2.2 Top-down Estimation (Anggaran dari Atas ke
Bawah)
Ini merupakan anggaran keseluruhan projek. Selalu
digunakan oleh pemilik perisian global yang mengeluarkan produk perisian. Anggaran ini selalunya berdasarkan
pengalaman projek lepas termasuk kos untuk semua fungsian di dalam projek.
Sebagai contoh: Kos untuk Fungsian untuk intergrasi dokumen, jaminan kualiti
perisian, konfigurasi pengurusan dll.
5.2.3 Expert Judgment (Pakar Pendapat)
Metod ini bergantung kepada seorang atau lebih
orang yang mahir di dalam sesuatu percubaan mengenai sesuatu masalah. Contoh:
Aplikasi kawasan atau pembangunan persekitaran. Metod ini banyak digunakan di
dalam metod anggaran secara manual.
5.2.4 Estimating by Analogy (Anggaran Menerusi
Analogi)
Merupaka satu metod yang lama tetapi dapat
dipercayai. Metod ini merupakan perbandingan terhadap cadangan projek terhadap
projek yang telah siap yang secara amnya sama dimana kosnya telah diketahui.
Kemiripan itu harus sampai sehingga jenis perniagaan terlibat, saiz aplikasi
secara menyeluruh, skop am sistem dan metod teknikal, piawai dan bahasa yang
digunakan. Jika terdapat perbezaan dari yang dinyatakan tadi, perubahan perlu dilakukan. Metod ini menekan
keperluan kos perisian terhadap pengkalan data yang lama. Semakin banyak data
yang boleh didapati, semakin tepat anggaran yang akan dibuat.
Kelebihan metod analogi ini adalah menganggarkan
kos keseluruhan projek dengan cepat seperti semasa menyiapkan cadangan. Bahaya
yang mungkin dihadapi mengunakan metod analogi adalah perbezaan antara projek
lama dengan projek baru. Sekiranya projek lama mempunyai fungsian yang lebih
mudah dari projek baru, maka akan berlaku anggaran yang berlebihan (over
estimate). Begitu juga sebaliknya akan berlaku kekurangan anggaran (under
estimate).
5.2.5 Analysis Effort Method (Metod Analisis
Usaha)
Metod ini amat sesuai untuk menghasilkan anggaran
permulaan untuk sesuatu projek iaitu sebelum projek bermula. Secara amya,
anggaran usaha (effort) memerlukan analisis kerja ke atas sejumlah fungsian
projek dan kemudian menyediakan anggaran untuk peringkat projek yang berikut
melalui penggunaan ratio terhadap analisis usaha.
Setelah fungsian dikenal pastik, maka penilai
perlu menilaikan usaha (effort) yang perlukan untuk analisis setiap fungsian.
Dalam membuat anggaran, penilai akan menggunakan kemahiran dan pengalaman
mereka, membincangkan idea mereka dengan orang lain dan mungkin mengunakan
statistik dari projek sebelum ini yang mana mempunyai fungsian yang hampir
sama. Dengan adanya analisis anggaran untuk fungsian individu, ianya akan dapat
dijumlahkan untuk memberikan nilai untuk fungsian kawasan -- fungsian kumpulan
– untuk subsistem dan untuk keseluruhan sistem.
Langkah seterusnya membuat sedikit penilaian
terhadap 3 faktor kunci, yang mana ianya akan dilaksanakan pada projek didalam
batas saiz, kesesuaian dan kerumitan.
·
Faktor saiz
berkait dengan jumlah orang yang akan terlibat diwaktu puncak projek tersebut.
·
Faktor
kesesuaian adalah selalunya berkait dengan jenis kerja dan jenis perniagaan dan
persekitaran teknikal yang melibatkan kebiasaan kakitangan yang terlibat di
dalam projek.
·
Faktor
kerumitan diambil kira jenis-jenis isu teknikal yang akan digunakan di dalam
projek
Menggunakan ketiga-tiga faktor: kadar (ratio)
diantara analisis dan fungsian lain disebarang peringkat dapat ditentukan.
Kadar itu nanti boleh digunakan untuk mengira anggaran usaha (effort) pada
setiap peringkat dan jua pada keseluruhan projek.
5.2.6 Programming Method (Metod Aturcara)
Metod ini bermula dari sudut yang berbeza dengan
Metod analisis usaha, iaitu melakukan pemeriksaan terhadap usaha aturcara yang
diperlukan dan memperolehi nilai-nilai sepanjang tugas-tugas projek
dilaksanakan. Cara paling mudah adalah dengan melakukan penilaian program untuk
menentukan program yang mana akan menjadi kecil, medium atau besar. Penilai
kemudian akan menggunakan metrik dari projek lain atau dari pengalamannya
sendiri, untuk menentukan usaha purata bagi
peringkat projek yang diberi tumpuan.
5.2.7 Three-point Technique/Three Time Probalistic
Model
Metod (kaedah) ini mengunakan tiga anggaran untuk
masa: optimis, putus harap (pessimistic) dan anggaran
Sama seperti Metod Analisis Usaha, anggaran disini
akan meliputi aktiviti utama projek.
·
Optimistic
time(0) adalah masa
tersingkat yang mana aktiviti boleh disiapkan, terkecuali ajaiban langsung.
·
Pessimistic
time (p) adalah masa yang
paling teruk yang dibenarkan untuk semua alasan yang munasabah
·
Most
likely (M) adalah masa
yang biasa dalam keadaan biasa
5.2.8 The Delphi Technique (Teknik Delphi)
Metod ini berasaskan kepada idea memperolehi
anggaran daripada orang yang berkelayakan dan kemudian menyatu padukan anggaran
tersebut untuk menghasilkan anggaran terakhir. Ini kerana setiap orang mempunyai
tahap pengalaman yang berbeza terhadap membuat anggaran, dan terhadap
perkakasan dan perisian yang akan digunakan. Terdapat beberapa peringkat
pendekatan:
(i)
Setiap
penilai diberikan spesifik kerja yang perlu dilakukan (aktiviti, tugas dll) dan
akan diminta menyediakan anggaran terhadap kerja tersebut.
(ii)
Anggaran
kemudian akan diringkaskan tanpa mengetahui siapa yang membuat penilaian dan
ringkasan tersebut akan diedarkan kepada setiap penilai
(iii)
Para penilai
akan menilai semua anggaran yang mereka buat sendiri dan memperbaiki anggaran
(penilaian) mereka sekiranya mereka merasakan ianya perlu.
Prosedur di atas boleh dilakukan beberapa kali
mengikut kemahuan mereka demi mencapai persetujuan. Teknik Delphi merupakan
pendekatan berkumpulan
5.2.9 COCOMO (Constructive Cost Model) (Model
Membangun Kos)
Metod COCOMO dibangunkan oleh Dr. Barry Boehm. Ia
lebih dikenali sebagai model ‘software costing’.
Basic Model komputer COCOMO membangun perisian di
atas dasar usaha (dan kos) sebagai fungsian terhadap saiz program di dalam
anggaran jumlah baris kod (line of code).
Model komputer jenis pertengahan (intermediate)
COCOMO membangun perisian di atas dasar usaha (effort) sebagai fungsian
terhadap saiz program dan menentukan “cost drivers”.
Model komputer jenis tinggi (advanced) COCOMO
mengabungkan semua kriteria yang ada di
dalam mode jenis pertengahan dengan penilaian terhadap kesan ‘cost drivers’ untuk setiap langkah
(analisis, rekabentuk dll) didalam kitar hayat projek.
5.2.10 Function Point Analysis (
Ini merupakan metod ‘top-down’ yang dicipta oleh
Allan Albrecht. Metod ini digunakan untuk mengukur saiz fungsian program secara
berasingan dengan bahasa pengaturcaraan yang digunakan.
5.3 COCOMO (Constructive Cost Model)
Terdapat 3 jenis susunan di dalam model ini.
5.3.1 The Basic COCOMO
Formula tidak perlu hafal, masukkan data yang
diberi kepada formula yang sesuai. Dalam soalan akan nyatakan jenis mode yang
perlu digunakan seperti contoh di bawah:
Example: Estimate the
number of persons required to do an organic mode software project with
an estimated size of 35,000 deliverable lines of code.

5.3.2 The Intermediate COCOMO
Sebagai tambahan kepada saiz projek, model ini
mengambil kira banyak faktor lain yang memberi kesan terhadap keperluan sumber
di dalam sesuatu projek. Faktor termasuk anggaran sumber ke atas Basic Model
Usaha (effort) COCOMO. Dengan cara ini, terdapat 15 kos drivers dikenalpasti
dan dikumpulkan kepada empat kategori utama iaitu:
(a)
Atribut
Produk (3 kos driver)
(b)
Atribut Komputer
atau Perkakasan (4 kos driver)
(c)
Atribut
Projek (3 kos driver)
(d)
Atribut
Personel (5 kos driver)
Nilai untuk setiap kos driver akan dikategori
kepada 6 iaitu
i)
Very low
ii)
Low
iii)
Nominal
iv)
High
v)
Very High
vi)
Extra High
Nilai semua kos driver akan didarabkan untuk memperolehi
effort adjusment factor (EAF). Kebiasan range EAF adalah diantara 0.9
sehingga 1.4.
5.3.3 The Advanced COCOMO or COCOMO II
Model ini mempertimbangkan faktor yang berlainan
yang mana diguna pakai semasa peringkat yang berlainan dalam pembangunan sistem
dan mengeluarkan anggaran yang lebih terperinci terhadap fasa-fasa yang ada
dalam basis. Model ini membenarkan anggaran dibuat keatas subsistem dan
anggaran-anggaran ini seterusnya akan digabungkan untuk menjadi anggaran
keseluruhan projek. Pendekatan menggunakan berbagai pendarab (multipliers) dan
eksponen, yang mana nilai telah ditentukan oleh pakar.
5.3.4 Kelebihan dan Kelemahan COCOMO
Kelebihan – mudah, kerana memerlukan jumlah data yang kecil
untuk menentukan usaha dan kos. Ia merupakan nilai statik yang mempunyai model
satu nilai. Rumus adalah diperoleh daripada analisa yang dilakukan terhadap
beberapa projek dan ini boleh diguna pakai untuk menjadi asas kepada keadaan
sebenar.
Kelemahan – merupakan model anggaran empiris. Data empiris yang menyokong model ini
mengunakan sampel projek yang terhad. Ini menambahkan kemungkinan menghasilkan
keputusan yang tidak tepat kerana model yang berlainan bergantung kepada
konstant yang tidak tetap. Walaubagaimanapun, dengan menggunakan data yang banyak
dari projek-projek sebelum ini, boleh membuatkan keputusan COCOMO menjadi lebih
baik.
5.4 Function Point (FP) Analysis
Metod ini mempunyai tiga peringkat.
(a)
Analisis
sistem dari keperluan maklumat pemprosesan pada peringkat logik, pertimbangan
perlaksanaan adalah berkecuali dan mengkira ‘unadjusted function points’ (UFP).
(b)
‘Processing
Complexity Adjustment (PCA) mengira untuk membenarkan pemikiran seperti mudah
digunakan, pemprosesan disebarkan, boleh dijaga dll.
(c)
UFP adalah
difaktorkan oleh PCA untuk memperolehi mata function point yang terakhir untuk
projek tersebut.
Basic model berdasarkan Sistem Informasi
Berkomputer (computer-based information systems) mengandungi lima komponen utama atau ‘jenis pengguna luar’ yang
akan memberi manfaat kepada pengguna seperti mana yang ditunjukkan pada jadual
di bawah:
|
Komponen |
Penerangan |
|
Internal Logical Files (ILF) |
Merupakan fail logikal data yang menyimpan
informasi untuk aplikasi yang akan menghasilkan (generates), menggunakan
(uses) dan menjaga data tersebut. |
|
External Logical Files (ELF) |
Fail ini mengandungi data atau informasi kawalan
datang dari, dihantar kepada, atau dikongsi oleh aplikasi lain. Fail-fail ini
membenarkan data di bawa masuk atau di bawa keluar dari satu komputer ke
komputer lain |
|
External Input (EI) |
Transaksi input (dari papan kekunci, talian
komunikasi, tape dll) yang akan mengemaskini fail dalaman komputer. Dalam
sistem interaktif, input skrin merupakan input luaran (external) yang utama. |
|
External Output (EO) |
Transaksi dimana data adalah merupakan output
kepada pengguna. Contoh: Report dan mesej |
|
External Inquiries (EIQ) |
Pertanyaan (queries) dari pengguna |
Analisis yang dibuat perlu mengenai pasti setiap
‘instance’ untuk setiap jenis pengguna luararn di dalam projek sistem. Setiap
komponen di atas akan dikelaskan sama ada tinggi, purata atau rendah mengikut kerumitannya. Pengiraan
setiap jenis pengguna luaran pada setiap kumpulan kerumitan akan didarab dengan
pemberat khas untuk mendapatkan mata ganjaran.

Mata ganjaran FP (function point) kemudian akan dijumlahkan untuk
memperolehi kiraan keseluruhan FP, yang mana menunjukkan informasi saiz
pengolahan (processing).
Saiz pengolahan (processing) adalah ukuran permulaan di dalam ‘unadjusted
function points (UFP). Kerumitan teknikal penyelarasan (technical complexity
adjustment – TCA) boleh digunakan kepada UFP.
Setiap fungsian bisnes akan hanya dikira sekali untuk mengelakkan perkiraan
yang sama.
Satu masalah yang ada pada FP adalah persoalan sama ada jenis pengguna luar
adalah jenis kerumitan tinggi, rendah atau purata merupakan sesuatu yang
objektif.
Metod Albrecht mempunyai banyak penghalusan yang dibuat yang kini dikenali
sebagai ‘International FP user group (IFPUG).
5.4.1 Mark II Approach
Metod ini merupakan satu percubaan untuk melakukan pembaikan terhadap metod
Albrecht. Idea Analisis FP diperbaharui oleh Charles Symons dari UK yang
mencipta MK II Function Point Analysis (FPA). Di dalam versi ini terdapa tiga
aspek sistem:
(a) Maklumat pengolahan saiz logik
(information processing logic size), diambil dari sistem input, pengolahan dan
output.
(b) Secara teknikal adalah rumit, sama ada
secara kumpulan (batch) atau atas talian (online). Ia melibatkan permintaan
terhadap kriteria prestasi (performance)) atau mudah digunakan.
(c) Faktor yang mempengaruhi prestasi seperti
pembangunan persekitaran general, kakitangan yang mencukupi dsbnya.
Untuk perkiraan kena baca sendiri. Tak perlu hafal. Semua nilai akan
diberi.