ESTIMATIONS
I Putu Surya Ari Taram (22 06 4054)
Rekayasa Perangkat Lunak II
ESTIMATIONS
Akan semakin sulit untuk meramalkan sumber daya, biaya-biaya, dan jangka waktu untuk pengintegrasian perangkat lunak dan sistem. Banyak model biaya menggunakan konsep ukuran produk sebagai pemegang utama untuk penilaian biaya. Tetapi pengalaman sudah menunjukkan bahwa mutu komponen-komponen dan mutu sistem terintegrasi akan menjadi faktor-faktor dominan yang mempengaruhi timbangan biaya-biaya dan waktu dari banyak proyek-proyek saat ini.
Perangkat lunak mahal untuk dikembangkan dan biaya merupakan suatu faktor yang utama di dalam anggaran-anggaran sistem informasi. Dengan bermacam-macam karakteristik perangkat lunak dan kemunculan teknologi baru akan mempersulit dalam mengestimasi biaya-biaya pengembangan software dengan tepat. Bagaimanapun, perangkat lunak itu ditargetkan untuk pelanggan dan biaya pengembangan mempengaruhi harga. Sebagai pelanggan atau pengembang, untuk mampu mendasari keputusan pembelian atau penjualan harus bisa mengestimasi biaya pengembangan secara konsisten dan benar. Penilaian melibatkan identifikasi dan hitungan faktor-faktor di dalam pengembangan suatu produk perangkat lunak. Termasuk di dalamnya proses-proses dengan siapa perangkat lunak itu dikembangkan, sumber daya personil dan dukungan yang digunakan di dalam pengembangan dan sifat alami produk diri sendiri.
Meramalkan biaya dan jangka waktu suatu proyek masih menjadi suatu masalah. Jack dan Mannion (1995) menyimpulkan dari survei organisasi-organisasi bahwa hanya 25% dari proyek-proyek tepat dengan prediksi biaya dan jadwal mereka mula-mula, 66% dari perusahaan itu meremehkan waktu dan biaya, lalu biaya untuk proyek-proyek yang serupa dapat bertambah sampai 200%. Ada beberapa teknik-teknik penilaian yang berbeda yang sekarang ini digunakan di dalam industri dan ini dapat diatur ke dalam 3 kategori utama:
model-model Algorithmic yang meramalkan usaha dan jangka waktu sebagai suatu fungsi sejumlah variabel. Algorithmic yang paling umum digunakan adalah COCOMO (COnstructive COst MOdel) (Boehm 1981) dan Function Point Analysis ( Albrecht &Gaffney 1983).
Ahli pakar menyertai ramalan-ramalan yang didasarkan pada keterampilan dan pengalaman dari satu atau lebih ahli-ahli.
Penilaian oleh Analogy yang menyertai perbandingan dari satu atau lebih proyek dengan suatu proyek baru yang serupa untuk meramalkan biaya dan jadwal.
1. Cellular Manufacturing Process Model (CMPM)
Secara tradisional, ICL (sebuah Company) sudah menggunakan V-diagram waterfall life cycle model untuk merencanakan dan mengendalikan pengembangan dari pengelola perangkat lunak dan sistem. Perkiraan-perkiraan kegiatan dan pertimbangan waktu yang didasarkan pada satu pemahaman arsitektur solusi, dan pendapat ahli atas derajat kesulitan serta masalah potensial akan ditemui selama aktivitas pengintegrasian. ketersediaan sumber daya dan ukuran tim juga diambil ketika membuat estimasi. Sejumlah alternatif life cycle models dan metoda-metoda pengembangan, saat ini tak satupun menunjukan hasil spesifik untuk mengatur pengintegrasian yang kompleks dari komponen-komponen yang disediakan.
CMPM adalah life cycle model yang baru dikembangkan bersama-sama oleh ICL dan Southampton University. Model ini memungkinkan pemahaman lebih dini dan lebih menyeluruh atas persyaratan pengintegrasian. Pemahaman ini memastikan verifikasi lebih baik dan pengesahan perangkat lunak dan sistem yang terintegrasi dan membantu melawan resiko potensial.
CMPM adalah satu set "Manufacturing Cells" berisi hubungan antara sel-sel yang digambarkan sebagai suatu set dari metrics. Model didasarkan pada model jaringan dari pengembangan software, dan pada "value chain" model. Model ini menunjukkan suatu pandangan ingintegrasi produk dari suatu campuran dari yang dibeli dan komponen-komponen diri yang dibangun sendiri. Di dalam konteks ini, integrasi sistem diartikan aktivitas yang mengidentifikasi (dan menetapkan) komponen-komponen dan mengembangkan "glue" untuk mengikat mereka (gambar 1.0).
Masing-masing aktivitas pengintegrasian digambarkan sebagai suatu sel di dalam CMPM. Model ini hirarki. Masing-masing sel bisa merupakan suatu komponen di suatu aktivitas pengintegrasian tingkat yang lebih tinggi.
Produk-produk dengan struktur hierarkis membiarkan diri mereka diberkembangkan dan dibuat di suatu jaringan dari manufacturing cells. Masing-masing sel bertanggung jawab atas satu tingkatan integrasi. Sel menerima komponen-komponen dari para supplier, membuat beberapa komponen di tempat itu, menempelkan komponen-komponen ke dalam satu produk yang terintegrasi (yang diuji untuk standar output) dan mengirim produk yang terintegrasi kepada pelanggan atau kepada sel yang melaksanakan tingkat integrasi berikutnya. Proses pengembangan software yang tradisional dapat digambarkan sebagai satu sel pengintegrasian di dalam dari CMPM. Itu membuat semua komponen (baris kode) inhouse dan merekatkan (compiles and builds) mereka ke dalam modul perangkat lunak atau produk perangkat lunak.
a. Metrics dalam CMPM
Enam metrics didefinisikan untuk setiap sel dalam jaringan CMPM (gambar 2). Q, P, and S harga penegendali dan digunakan untuk menentukan upaya yang dibutuhkan untuk menyelesaikan proyek. T ditentukan dari W dengan mengambil sumber yang ada, N, menjadi account.
W, T, dan N digambarkan di dalam COCOMO. definisi-definisi pengendali biaya adalah:
Q: bagian persyaratan-persyaratan pada komponen-komponen input tanpa biaya yang terjadi di dalam sel pengintegrasian.
P: bagian persyaratan-persyaratan pelanggan pada produk terintegrasi yang dijumpai dengan produk yang dikirimkan.
S: Ukuran dari komponen-komponen yang dikirimkan dan dikonsumsi di dalam “Unit-unit Pengintegrasian Standar” (SIU'S).
Kualitas metrics secara langsung berhubungan dengan resiko proyek. Lebih miskin kualitas input, semakin besar resiko menemukan masalah tak terduga selama pengintegrasian. Sama dengan, lebih miskin mutu yang dikirimkan, lebih besar resiko pelanggan-pelanggan menemukan masalah yang tak terduga.
Baseline data (tabel 1) dikumpulkan dari proyek-proyek yang diselesaikan sebelum eksperimen. Satu-satunya data yang tersedia adalah usaha total yang dihabiskan dan jangka waktu aktivitas pengembangan.
Pengukuran di atas dapat dibandingkan dengan yang estimasi asli pada masing-masing release. Data menunjukkan usaha nyata bervariasi 76% (24% under-spend) sampai 183% (83% overspend) dari prediksi, sedangkan jangka waktu bervariasi dari 152% (52% overrun) sampai 248% (148% overrun). Bahkan ketika proyek under-spend berbanding terbalik dengan estimasi usaha asli, waktu yang dilewatkan lebih dari dua kali perkiraan. Bukti dari proyek-proyek di dalam organisasi lainnya mengkonfirmasikan generalisasi bahwa hampir semua proyek-proyek overrun dari 50% -100%.
Langkah pertama adalah menggambarkan proyek sebagai suatu set dari sel-sel peroduksi yang terkait dengan menggunakan CMPM, masing-masing sel menunjukan integrasi beberapa komponen yang menghasilkan satu bagian sistim yang lain. Masing-masing sel, mengestimasi untuk biaya Q, P, dan S, menggunakan data checklist dan historis di dalam experience database. Pengendalian biaya digunakan untuk meramalkan usaha (W) dan waktu (T), pengambilan ketersediaan sumber daya pelanggan.
Gambar 3: Estimasi biaya dan proses project tracking
Table.2: Checklist generic work products untuk mengestimasi ukuran
2. Estimasi Proyek Menggunakan CBR
Case-based reasoning (CBR) berfungsi sebagai suatu memori terstruktur di mana pengalaman disimpan sebagai kasus-kasus dan bisa digambarkan lagi ketika permasalahan yang baru muncul dalam proyek baru. Sehingga kita dapat mengestimasi proyek baru berdasarkan pengalaman proyek sebelumnya yang serupa. Efektivitas CBR pada satu tingkat operasional sudah terbukti dengan banyak aplikasi. Sungguh ada banyak riset memakai CBR pada tingkat operasional dalam perkiraan biaya proyek perangkat lunak yang kita minati.
Estimasi biaya proyek perangkat lunak adalah masalah karena sulit untuk memperoleh gambaran ukuran dan biaya yang akurat yang bisa diketahui di awal proses pengembangan. Ini adalah karakteristik dari weak theory domains di mana CBR dapat menjadi solusinya. Pendekatan CBR menggunakan teknik estimasi konvensional seperti COCOMO atau Function Point Analysis untuk membangun suatu struktur kasus.
a. Estimasi Awal
Ketelitian estimasi perangkat lunak mempunyai suatu dampak langsung pada mutu keputusan investasi organisasi perangkat lunak. Penilaian yang akurat sejak awal sebisa mungkin dilakukan dalam development life cycle. Ini penting sebagai perkiraan awal sebelum dimasukan ke analisa biaya/untung dan keputusan dengan strategi yang lain.
Untuk mengestimasi kegiatan pengembangan pada tahap awal development life cycle perlu dilakukan identifikasi atribut-atribut dari proyek. Kebanyakan dari model-model algorithmic menggunakan ukuran dari ukuran sistim seperti kunci input untuk prosedur estimasi. COCOMO menggunakan bentuk kode sebagai ukuran dari ukuran perangkat lunak. Function Point Analysis menggunakan suatu ukuran dari ukuran sistim disebut Function Point yang berasal dari fitur desain seperti banyaknya input, output dan entitas dalam sistim perangkat lunak. Aplikasi CBR di atas juga menggunakan fitur disain dan metrics yang tidak bisa diketahui setiap kepastiannya yang layak di awal dalam life cycle pada saat estimasi biaya awal.
b. CBR pada Estimasi Awal
Satu cara yang sederhana menghitung usaha (effort) yang dilibatkan dalam pengembangan sistim perangkat lunak memerlukan ukuran sistim (contoh poin-poin kode atau fungsi) dikalikan dengan produktivitas yang diharapkan tim proyek (seperti banyaknya bentuk dari kode atau titik fungsi per hari).
Effort Size * Productivity
Salah satu persoalan paling sulit berhubungan dengan usaha estimasi di awal penilaian adalah menyediakan ukuran dari ukuran sistim. Shepperd et al. (1996) menjelaskan dengan analogi untuk estimasi usaha dan menyatakan bahwa sangat penting untuk memilih sedikitnya nya variabel atau fitur untuk bertindak sebagai pengendali ukuran (size driver). Pada tahap siklus pengembangan pengendali ukuran digunakan untuk menghasilkan estimasi. Tanpa beberapa kerja desain mustahil untuk mengestimasi banyaknya input, layar-layar atau kelas-kelas dengan teliti. Untuk alasan ini tidak baik untuk mengharapkan estimasi yang akurat (contoh dalam bulan kerja). Lebih sesuai menggunakan prediksi fitur yang tersedia dengan suatu penimbang yang akan menandai adanya pengaruh dimana fitur kasus akan memiliki produktivitas proyek yang diharapkan.
Gambar 4 menampilkan usulan representasi kasus. Beberapa fitur di dalam representasi kasus mengacu pada pengaruh dan pengalaman dari manajemen proyek pengembangan software. “Manajemen bisa mempunyai lebih banyak pengaruh pada produktivitas dari staf programming daripada teknologi yang digunakan sekarang” ( Kendall & Lamb 1977). Variabel itu dikenali sebagai variabel-variabel resiko atau variabel-variabel yang menambah
overrun proyek atau menyebabkan estimasi yang tidak akurat dalam berbagai studi-studi (Barki et al. 1993; Subramanian &Breslawski 1994; Subramanian &Breslawski 1995;
Heemstra 1992). Subramanian & Breslawski (1995) juga menemukan bahwa menggunakan suatu pengalaman manajer proyek untuk menyesuaikan estimasi yang diperoleh dari model-model algorithmic untuk meningkatkan akuransi estimasi usaha.
komposisi dan pengalaman dari tim proyek juga menjadi kunci usaha dalam mempengaruhi estimasi pengembangan (Heemstra 1992; Barki et al. 1993; Boehm &Papaccio 1990; Jeffery 1987). Heemstra (1992) menyimpulkan bahwa “aspek manusia” adalah sangat penting dalam estimasi biaya perangkat lunak. Fitur seperti mutu, pengalaman dan komposisi tim proyek, tingkat derajat manager proyek dapat memotivasi dan mendorong timnya .
Gambar 4
Riset-riset juga telah mebuktikan pentingnya keikutsertaan pengguna dan pengalamannya di dalam proyek-proyek sukses (Barki et al 1993; Lederer &Prasad 1992; Subramanian &Breslawski 1995).
Beberapa cost driver yang digunakan dalam teknik-teknik estimasi Aplikasi sendiri adalah variabel-variabel yang bersifat tergantung pada jumlah tertentu dari desain yang sudah diselesaikan, seperti kompleksitas perangkat lunak atau ukuran database.
Pertimbangan akhir metode pengembangan, studi-studi sudah menunjukkan bahwa penggunaan dari alat-alat produktivitas, teknologi tertentu dan teknik-teknik desain standar dapat mempengaruhi estimasi ( Lederer &Prasad 1992; Subramanian &Breslawski 1994; Heemstra 1992). Lederer & Prasad (1992) juga menyimpulkan bahwa ketelitian dari estimasi meningkat dengan pemakaian fakta-fakta dan standarisasi yang didokumentasikan.
KESIMPULAN
Eksperimen-eksperimen sudah menunjukkan bahwa CMPM menyediakan suatu makna yang lebih efektif untuk perencanaan dan pengerjaan perangkat lunak dan proyek-proyek pengintegrasian sistem yang tergantung atas komponen-komponen yang disediakan oleh pihak ketiga. Metode ini cukup fleksibel untuk dikembangkan oleh organisasi yang integrasi sistem komponen-komponennya disediakan oleh pihak ketiga, seperti COTS atau pengembangan kolaboratif. Ini dapat digunakan untuk proyek-proyek ukuran kecil sampai menengah.
Mengestimasi proyek baru berdasarkan pengalaman proyek (CBR) yang serupa cukup baik untuk diterapkan. Kemungkinan untuk mengalami kesalahan yang sama dapat ditanggulangi dengan estimasi yang benar. Faktor manusia juga sangat penting bagi kesuksuksesan dari suatu proyek pengembangan software walaupun estimasi yang dibuat sudah sangat bagus. Tanpa kualitas developer dan pelaku manajemen proyek yang berkualitas sebuah proyek tidak akan berhasil dengan baik.
REFERENSI
An Experiment to Improve Cost Estimation and Project Tracking for Software and Systems Integration Projects
Brian Chatters, ICL,
Peter Henderson,
Chris Rostron, ICL,
The Limits of CBR in Software Project Estimation
Sarah Jane Delany1, Pádraig Cunningham2 and Wolfgang Wilke3
1Dublin Institute of
3University of
Tidak ada komentar:
Posting Komentar