Software Project Planning, oleh Sabrina [5105 100 103]

Proses Manajemen proyek perangkat lunak dimulai dengan serangkaian aktivitas  yang secara kolektif disebut project planning (perencanaan proyek). Dan aktivitas pertamanya adalah estimation (perkiraan). Karena estimasi menjadi dasar bagi semua aktivitas perencanaan proyek yang lain dan perencanaan proyek memberikan sebuah peta jalan bagi suksesnya rekayasa perangkat lunak, maka tanpa estimasi kita tidak dapat berjalan dengan baik.

Estimasi sumber daya, biaya dan jadwal untuk usaha pengembangan perangkat lunak membutuhkan pengalaman, mengakses informasi histories yang baik, dan keberanian untuk melakukan pengukuran kuantitatif bila hanya data kualitatif saja yang ada. Estimasi membawa resiko yang inheren dan resiko inilah yang membawa kepada ketidakpastian.

Faktor-faktor yang mempengaruhi estimasi adalah :
–    Project Complexity (kompleksitas proyek) berpengaruh kuat terhadap ketidapastian yang inheren dalam perencanaan. Tetapi kompleksitas merupakan pengukuran relatif yang dipengaruhi oleh kebiasaan dengan usaha yang sudah dilakukan pada masa sebelumnya.
–    Project Size (Ukuran Proyek). Bila ukuran bertmbah maka ketergantungan diantara berbagai elemen perangkat lunak akan meningkat dengan cepat. Dekomposisi masalah sebagai suatu pendekatan yang sangat penting dalam proses estimasi menjadi lebih sulit karena lagi karena elemen-elemen yang akan didekomposisimasih sangat berat.
–    Structural Uncertainty (ketidakpastian struktural). Bila metrik perangkat lunak yang komprehensif dapat diperoleh pada proyek yang telah lalu, maka estimasi dapat dilakukan dengan kepastian yang lebih tinggi.jadwal dapat dibuat untuk menhindari kesulitan-kesuliatan yang terjadi di masa lalu, dan resiko keseluruhan dapat dikurangi.

Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface (spesifikasi system). Perencana, dan lebih penting lagi pelanggan, harus mengetahui bahwa variabilitas pada kebutuhan perangkat lunak berarti ketidakstabilan biaya san jadwal.

Manajer proyek tidak boleh obsesif terhadap estimasi. Pendekatan-pendekatan rekayasa perangkat lunak modern memakai pandangan pengembangan yang interaktif. Pada pendekatan semacam ini dimungkinkan untuk melihat lagi estimasi dan merevisinya bila pelanggan mengubah kebutuhannya.

Ø    Tujuan Project Planning

Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan seharusnya diperbarui secara teratur selagi proyek sedang berjalan. Tujuan perencanaan dicapai melalui suatu proses penemuan informasi yang menunjuk ke estimasi yang dapat dipertanggungjawabkan.

Ø    Ruang Lingkup Perangkat Lunak

Aktivitas pertama dalam perencanaan proyek perangkat lunak adalah penentuan ruang lingkup perangkat lunak. Ruang lingkup perangkat lunak menggambarkan fungsi, kinerja, batasan, interface, dan reliabilitas. Funsi-fungsi yang digambarkan dalam statemen ruang lingkup dievaluasi dan dalam banyak kasus juga disaring untuk memberikan awalan yang lebih detail pada saat estimasi dimulai.

Ø    Sumber Daya

Tugas kedua perencanaan perangkat lunak adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak tersebut.
sabrina1
Gambar diatas memperlihatkan sumber daya pengembangan sebagai sebuah piramid.

–    Lingkungan pengembangan (piranti perangkat kers dan perangkat lunak) berada pada fondasi piramid sumber daya dan menyediakan infrastruktur untuk mendukung usaha pengembangan.
–    Komponen Perangkat Reusable merupakan blok bangunan perangkat lunak  yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat penyampaian.
–    Sumber Daya Utama (Manusia) berada pada puncak piramid.

Masing-masing sumber daya ditentukan dengan empat karakteristik yaitu deskripsi sumber daya, statemen ketersediaan, waktu kronologis sumber daya diperlukan , serta durasi waktu sumber daya diaplikasikan.

Ø    Estimasi Proyek Perangkat Lunak

Pada masa awal-awal penghitungan, biaya perangkat lunak terdiri dari persentase kecil biaya sistem berbasis komputer secara kesekuruhan. Urutan kesalahan besaran pada estimasi biaya perangkat lunak memiliki pengaruh yang relatif kecil.sekarang perangkat lunak menjadi sesuatu yang mahal di dalam sebagian besar sistem berbasis komputer. Kesalahan estimasi biaya yang besar dapat memberikan perbedaan antara keuntungan dan kerugian. Biaya yang terlalu banyak dapat menjadi bencana bagi pengembang perangkat lunak.

Ada sejumlah pilihan untuk mencapai estimasi biaya dan usa yang dapat dipertanggungjawabkan, yaitu :
1.    Menunda estimasi sampai akhir proyek.
2.    Mendasarkan estimasi pada proyek-proyek yang mirip yang sudah dilakukan sebelumnya.
3.    Menggunakan teknik dekomposisi yang relatif sederhana untuk melakukan estimasi biaya biaya dan usaha proyek.
4.    Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya perangkat lunak.

Pada estimasi proyek perangkat lunak, teknik dekomposisi mengambil cara “membagi dan mengalahkan.” Dengan mendekomposisi sebuah proyek ke dalam fungsi-fungsi utama serta aktovitas rekayasa perangkat lunak yang berhubungan, estimasi biaya dan usaha dapat dilakukan langkah demi langkah. Model estimasi empiris dapat digunakan untuk melengkapi teknik dekomposisi serta menawarkan pendekatan estimasi yang secara potensial berharga. Model berbasis pengalaman (data histories) dan berbentuk :

d = f(vi)

Dimana d adalah satu dari sejumlah harga estimasi (contonya usaha, biaya, durasi proyek) dan vi adalah parameter independen yang dipilih (seperti LOC dan FP yang diestimasi)

Ø    Teknik Dekomposisi
Estimasi proyek perangkat lunak merupakan bentuk pemecahan masalah, dan dalam banyak kasus, masalah yang harus dipecahkan (yakni pengembangan estimasi biaya dan usaha bagi sebuah proyek perangkat lunak) sangat kompleks untuk dipertimbangkan sebagai satu bagian. Karena alasan tersebut, kita mendekomposisi masalah, menandainya sebagai serangkaian masalah yang lebih kecil (yang diharapkan lebih dapat teratur).

–    Software Sizing

Akurasi estimasi proyek perangkat lunak didasarkan pada sejumlah hal :
1.    tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk yang akan dibuat
2.    kemampuan untuk menerjemahkan estimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar (fungsi avaibilitas metrik perangkat lunak yang reliabel dari proyek sebelumnya)
3.    tingkat dimana rencana proyek mencerminkan kemampuan tim perangkat lunak
4.    stabilitas syarat produk serta lingkungan yang mendukung usaha pengembangan perangkat lunak

Putnam dan Myers mengusulkan 4 pendekatan yang berbeda terhadap masalah penentuan ukuran :
1.    Fuzzy-Logic Sizing. Pendekatan ini menggunakan teknik reasoning aproksimasi yang merupakan dasar bagi fuzzy logic
2.    Function Point Sizing.
3.    Standard Component Sizing
4.    Change Sizing

–    Perkiraan Berdasarkan Masalah

Selama estimasi proyek perangkat lunak, data LOC dan FP digunakan dalam dua cara :
1.    sebagai variabel estimasi yang dipakai untuk mengukur masing-masing elemen perangkat lunak
2.    sebagai matrik 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 karakteristik umum. Teknik estimasi LOC dan FP berbeda 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 LOC dan FP yang dikembangkan.
Pada estimasi FP, dekomposisi bekerja secara berbeda. Selain berfokus pada fungsi, masing-masing karakteristik domain informasi – input, output, file data, inquriry dan interface eksternal – serta 14 nilai penyesuaian kompleksitas. Estimasi resultan digunakan untuk mendapatkan nilai FP yang dapat diikat dengan data sebelumnya serta digunakan untuk melakukan estimasi.

–    Estimasi Berbasis Proses

Perkiraan berbasis proses dimulai dengan gambaran fungsi-fungsi perangkat lunak yang diperoleh dari ruang lingkup proyek. Sekali fungsi dan masalah aktivitas proses disatukan, perencana akan memperkirakan usaha yang dibutuhkan untuk menyelesaikan setiap aktivitas proses perangkat lunak untuk setiap fungsi perangkat lunak. Tingkat kerja rata-rata kemudian diterapkan pada usaha yang diperkirakan bagi setiap aktivitas proses. Biaya dan usaha bagi setiap fungsi dan aktifitas proses perangkat lunak dihitung sebagai langkah akhir. Jika perkiraan yang berbasis proses dilakukan dengan tidak tergantung pada perkiraan LOC dan FP, kita memiliki dua atau tiga perkiraan biaya dan usaha yang dapat dibandingkan dan dirundingkan. Jika kedua kumpulan perkiraan tersebut memperlihatkan kecocokan yang dapat dipertanggungjawabkan maka tidak ada alasan untuk tidak percaya bahwa perkiraan tersebut dapat diandalkan. Tetapi bila hasil teknik dekomposisi itu memperlihatkan hanya sedikit kecocokan, maka harus dilakukan investigasi dan analisis lebih jauh lagi

Ø    Model Perkiraan Empiris

Model perkiraan untuk perangkat lunak komputer menggunakan rumusan yang ditarik secara empiris untuk memprediksi usaha sebagai sebuah fungsi LOC dan FP. Model perkiraan tertentu ditarik dengan menggunakan analisis regresi terhadap data yang dikumpulkan dari proyek perangkat lunak sebelumnya. Struktur keseluruhan dari model semacam itu berbentuk :

E = A + B x (Ev)C

Dimana A, B, dan C adalah konstantayang ditarik secara empiris, E adalah usaha dalam person-month, dan Ev adalah variable perkiraan (baik dalam LOCmaupun FP).

Model COCOMO
Merupakan hierarki model estimasi perangkat lunak yang merupakan singkatan dari Constructive Cost Model (Model Biaya Konstruktif). Yang berbentuk :

Model 1 : model COCOMO dasar menghitung usaha pengembangan perangkat lunak (dan biaya) sebagai fungsi dari ukuran program yang diekspresikan dalam baris kode yang diestimasi.

Model 2 : model COCOMO intermediate menghitung usaha pengembangan perangkat lunak sebagai fungsi ukuran program dan serangkaian ”pengendali biaya” yang menyangkut penilaian yang subyektif terhadap produk, perangkat keras personil, dan atribut proyek

Model 3 : model COCOMO advanced menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengendali biaya pada setiap langkah (analisis, perancangan, dll) dari proses rekayasa perangkat lunak

Persamaan Perangkat Lunak
Persamaan perangkat lunak adalah model yang multivariasi yang mengasumsikan distribusi khusus usaha sepanjang hidup proyek pengembanganperangkat lunak. Model tersebut sudah diambil dari data produktivitas yang dikumpulkan dari 4000 proyek perangkat lunak yang sejaman. Berdasarkan data-data tersebut, model estimasinya berbentuk :

E = [LOC x B0,333/P3] x (1/f4)

Dimana :

E       = usaha dalam person-month atau person-year
T       = durasi proyek dalam bulan atau tahun
B      = “factor skill khusus” yang meningkat secara pelan-pelan “pada saat kebutuhan akan intregasi, pengujian, jaminan kualitas, dokumentasi, manajemen skill tumbuh ”. untuk program kecil (KLOC = 5 sampai 15) B = 0,16. untuk program yang lebih besar daripada daripada 70 KLOC, B = 0,39
P       = “parameter produktivitas” yang mencerminkan :
– kematangan proses dan praktik manajemen secara  keseluruhan.
–  tingkat di mana praktik rekayasa perangkat lunak yang  baik digunakan
–   tingkat bahasa pemrograman yang digunakan
–   keadaan lingkungan perangkat lunak
–   ketrampilan/skill dan pengalaman tim perangkat lunak
–   kompleksitas aplikasi

Ø    Keputusan Make-Buy

Dalam banyak area aplikasi perangkat lunak, biaya sering lebih efektif untuk mendapatkan daripada mengembangkan perangkat lunak komputer. Manajer rekayasa perangkat lunak dihadapkan pada keputusan make-buy yang dapat dikomplikasikan lebih jauh lagi oleh sejumlah pilihan akuisisi, yaitu :
1.    perangkat lunak dapat dibeli (atau lisensi) off-the-self
2.    komponen perangkat lunak full-experience dan partial-experience dapat diperoleh dan kemudian dimodifikasi dan diintregasi untuk memenuhi kebutuhan tertentu
3.    perangkat lunak dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi pembeli.

Untuk produk perangkat lunak yang lebih mahal, langkah-langkah petunjuk berikut ini dapat dilakukan :
1.    kembangkan spesifikasi untuk fungsi dan kinerja perangkat lunak yang diperlukan.tentukan karakteristik yang dapat diukur kapan saja dibutuhkan
2.    perkirakan biaya internal untuk mengembangkan dan tanggal penyampaian.
3.    a.  Pilih 3 atau 4 calon aplikasi yang paling cocok dengan aplikasi anda
b. Pilih komponen yang reusable yang dapat membantu konstruksi aplikasi yang diperlukan
4.    kembangkan sebuah matriks perbandingan head-to-headdari fungsi kunci. Lakukan pengujian benchmark (patok duga) untuk membandingkan calon perangkat lunak
5.    evaluasi masing-masing paket perangkat lunak atau komponen berdasarkan kualitas produkk sebelumnya, dukungan penjual, arah proyek, reputasi dan sebagainya
6.    hubungi pemakai perangkat lunak lain dan mintalah pendapat mereka

Dalam analisi akhir , keptusan make-buy dibuat berdasarkan kondisi berikut :
Apakah penyampaian produk perangkat lunak akan lebih cepat daripada perangkat lunak yang dikembangkan secara internal?
Apakah biaya akuisisi ditambah biaya pemesanan akan lebih kecil daripada pengembangan perangkat lunak secara internal?
Apakah biaya dukungan luar (seperti kontrak pemeliharaan) akan lebih rendah daripada biaya dukungan internal?

Ø    Piranti Estimasi Otomatis

Piranti perangkat lunak otomatis ini memungkinkan para perencana memperkirakan biaya dan usaha serta melakukan analisis ”what if” pada variabel proyek yang penting seperti tanggal penyampaian atau staffing. Meskipun ada banyak piranti otomatis, tetapi semuamemperlihatkan karakteristik umum dan semua memerlukan satu atau lebih kategori data berikut ini :
1.    kuantitatif ukuran perangkat lunak (seperti LOC) atau fungsionalitas (data function point)
2.    karakteristik proyek kualitatif seperti kompleksitas, reliabilitas yang dibutuhkan atau tingkat kekritisan bisnis
3.    banyak gambaran staf pengembangan dan atau lingkungan pengembangan

3 Responses to “Software Project Planning, oleh Sabrina [5105 100 103]”


  1. 1 redvespa Mei 14, 2008 pukul 6:13 pm

    minta rujukan journal yang berhubungan dengan software project planning dong tx…

  2. 2 irlanggana Maret 5, 2009 pukul 2:36 pm

    terima kasih atas infonya, artikelnya sangat bermanfaat

  3. 3 likas September 29, 2010 pukul 11:14 pm

    sangat membantu


Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s




Arsip

RSS My Blog

  • Pindahan! Februari 13, 2012
    Para pembaca sekalian, mulai hari ini blog ini pindah ya.. alamatnya di www.handyeka.com Posting-posting terbaru akan muncul di alamat baru tersebut. Terima kasih :)
  • Selamat Tahun Baru 2012! Januari 26, 2012
    Selamat tahun baru 2012!! Bagaimana tahun 2011 yang baru saja kita lewati ini? pasti banyak up-and-down nya. Biasanya orang kalau ngomongin tahun baru mesti nanyain resolusi tahun baru, tapi kali ini saya ga mau nanya-nanya tentang resolusi, hahaha.. kenapa? karena … Continue reading →
  • Adele – Someone Like You Oktober 10, 2011
    Pernahkah Anda merasakan jatuh cinta.. namun pada akhirnya Anda hanya bisa mengagumi dia yang Anda cinta karena Anda berdua sayangnya tidak bisa bersatu.. namun ia akhirnya bisa bahagia.. meskipun bukan bersama Anda.. Sakit.. dan penuh emosi jiwa pastinya.. tapi apakah … Continue reading →

RSS Recipee World

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

RSS Indonesia Travel Guide

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

RSS Music Info Online

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

%d blogger menyukai ini: