Assalamu’alaikum Wr. Wb.
Hello Guyss , kali ini saya akan sedikit berbagi ilmu tentang SOFTWARE PROJECT PLANNING . . .
Proses Manajemen proyek perangkat ???
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.
Perencanaan Proyek (Project Planning) merupakan awal dari serangkaian aktivitas secara kolektif dari sebuah proses Manajemen Proyek Perangkat Lunak. Proses manajemen proyek perangkat lunak dimulai dengan kegiatan project planning (perencanaan proyek). Yang pertama dari aktifitas ini adalah estimation (perkiraan). 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.
1.Observasi pada Estimasi
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. Dibawah ini merupakan faktor-faktor yang mempengaruhi estimasi :
-Project Complexity (Kompleksitas Proyek)
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.
2. Tujuan Perencanaan Proyek Perangkat Lunak
Tujuan umum dari perencanaan proyek perangkat lunak adalah:
-Menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggung-jawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan seharusnya diperbaharui secara teratur selagi proyek sedang berjalan.
-Untuk pengawasan, penelusuran, dan pemantauan sebuah proyek teknik yang kompleks.
3. Ruang Lingkup Perangkat Lunak
Aktivitas pertama dalam perencanaan perangkat lunak adalah penentuan ruang lingkup perangkat lunak yang terdiri dari
-Fungsi : Untuk memberikan awalan yang lebih detail pada saat dimulai estimasi.
-Kinerja : Melingkupi pemrosesan dan kebutuhan waktu respon.
-Batasan : Mengidentifikasi batas yang ditempatkan pada perangkat lunak oleh hardware eksternal, memori dan system lain.
-Interface : Konsep sebuah Interface diinterpretasikan untuk menentukan:
-Hardware : yang mengeksekusi perangkat lunak dan device yang dikontrol secara langsung oleh perangkat lunak.
-Software : yang sudah ada dan harus dihubungkan dengan perangkat lunak baru.
-Manusia yang menggunakan perangkat lunak melalui perangkat I/O
-Prosedur
-Realibilitas (Keandalan)
Untuk mengerti Ruang Lingkup tersebut, maka perekayasa perangkat lunak harus:
-Mengerti kebutuhan pelanggan
-Mengerti konteks bisnis
-Mengerti batasan-batasan proyek
-Mengerti motivasi pelanggan
-Mengerti alur kearah perubahan
4. Sumber Daya
Tugas kedua perencanaan perangkat lunak adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak tersebut. Gambar berikut memperlihatkan sumber daya pengembangan sebagai sebuah piramid.
Piramida diatas memperlihatkan sumber daya pengembangan sebagai sebuah piramis. Piranti perangkat keras dan perangkat lunak berada pada fondasi dan menyediakan infrastruktur untuk mendukung usaha pengembangan (lingkungan pengembang). Dalam tingkat yang lebih tinggi terdapat komponen perangkat lunak reusable, blok bangunan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat pencapaian. Pada puncak piramida terdapat sumber daya utama yaitu manusia.
- Dibawah ini merupakan penjelasan lebih spesifik mengenai sumber daya.- Sumber Daya Manusia
Perencanaan sumber daya manusia memulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk mnyelesaikan pengembangan. Baik posisi organisasi maupun specialty. Jumlah orang yang diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan setelah estimasi usaha pengembangan dibuat.- Komponen Perangkat lunak (reusable)
Kreasi dan penggunaan kembali blok bangunan perangkat lunak yang seharusnya dikatalog menjadi referensi yang mudah, distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk integrasi yang mudah. Ada empat kategori sumber daya perangkat lunak yang harus dipertimbngkan pada saat perencanaan berlangsung, yaitu :- Komponen Off-the self
Perangkat lunak yang ada dapat diperoleh dari bagian ketiga atau telah dikembangkan secara internal untuk proyek sebelumnya.- Komponen Full-Experience
Spesifikasi, kode, desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan perangkat lunak yang akan dibangun pada proyek saat ini.- Komponen Partial-Experience
Aplikasi, kode, desain, atau data pengujiaan yang ada pada proyek yang lalu yang dihubungkan dengan perangkat lunak yang dibangun untuk proyek saat ini, tetapi akan membutuhkan modifikasi substansial.- Komponen Baru
Komponen perangkat lunak yang harus dibangun oleh tim perangkat lunak khususnya adalah untuk kebutuhan proyek sekarang . Lebih baik mengkhususkan syarat sumber daya perangkat lunak dari awal. Dengan cara ini evaluasi teknis dari semua alternatif dapat dilakukan dan akuisisi secara berkala dapat terjadi.– Lingkungan
Lingkungan yang mendukung proyek perangkat lunak, yang disebut juga software engineering environment (SEE), menggabungkan perangkat lunak dan perangkat keras. Karena sebagian besar organisasi perangkat lunak memiliki konstituen ganda yang memerlukan akses ke SEE, maka perencana proyek harus menentukan jendela waktu yang dibutuhkan bagi perangkat keras dan perangkat lunak serta membuktikan bahwa sember-sumber daya tersebut dapat diperoleh.
Pada saat sebuah sistem berbasis komputer akan direkayasa, tim perangkat lunak mungkin membutuhkan akses ke elemen perangkat keras yang sedang dikembangkan oleh tim rekayasa yang lain.
5. Estimasi Proyek Perangkat Lunak
Estimasi biaya dan usaha perangkat lunak tidak akan pernah menjadi ilmu pasti. Variabel yang terlalu banyak, manusia, teknik, lingkungan, politik dapat mempengaruhi biaya dan usaha akhir yang diaplikasikan untuk mengembangkannya.
Ada sejumlah pilihan untuk mencapai estimasi biaya dan usaha yang dapat dipertanggung jawabkan :
-Menunda estimasi sampai akhir proyek (estimasi akurat 100% bila proyek sudah selesai)
-mendasarkan estimasi pada proyek-proyek yang mirip yang sudah dilakukan sebelumnya.
-menggunkana “teknik dekomposisi” yang relatif sederhana untuk melakukan estimasi biaya dan usaha proyek.
-menggunakan satu atau lebih model empiis bagi estimasi usaha dan biaya PL
Perkiraan Biaya
-Ruang Lingkup proyek harus didefinisikan secara eksplisit
-Tugas dan atau dekomposisi fungsional diperlukan
-Pengukuran historis sangat membantu
-Paling sedikit harus digunakan dua teknik berbeda
-Harus diingat bahwa ketidakpastian adalah hal yang tidak dapat dipidahkan (dari proyek PL).
Akurasi Estimasi perangkat lunak ditentukan oleh:
-Ukuran yang diperkirakan dari produk.
-Kemampuan untuk menterjemahkan ukuran ke satuan usaha, waktu dan anggaran.
-Kemampuan tim menyesuaikan dengan rencana proyek.
-Stabilitas kebutuhan dan lingkungan.
Secara ideal, teknik yang ditulis untuk masing-masing pilihan harus diaplikasi secara berpasangan, masing-masing digunakan sebagai cross check bagi yang lain. Pada estimasi proyek PL, teknik dekomposisi mengambil cara “membagi dan mengalahkan.”
Model estimasi empiris dapat digunakan untuk melengkapi teknik dekomposisi serta menawarkan pendekatan estimasi yang secara potensial berharga. Model berbasis pengalaman dan berbentuk :
D = f(vi)
Dimana d adalah satu dari sejumlah harga estimasi (contoh usaha, biaya, durasi proyek) dan vi adalah parameter independen yang dipilih (seperti LOC dan FP yang diestimasi). Peranti estimasi otomatis mengimplementasi satu atau lebih teknik dekomposisi atau model empiris.
6. 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
7. 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
8. 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
9. 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.
10. KEPUTUSAN MAKE-BUY
Manajer rekayasa perangkat lunak dihadapkan pada keputusan make-buy yang dapat dikompilasikan lebih jauh lagi oleh sejumlah pilihan akuisisi :
1. Perangkat lunak dapat dibeli(atau lisensi) off-the-shelf.
2. Komponen perangkat lunak full-experience dan partial-experiance dapat diperoleh dan kemudian dimodifikasi dan diintegrasikan untuk memenuhi kebutuhan tertentu.
3. Perangkat lunak dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi pembeli.
Langkah-langkah yang tercakup dalam akuisisi perangkat lunak ditentukan oleh kekritisan perangkat lunak yang akan dibeli dan biaya akhir. Dalam analisis akhir, keoputusan make-buy dibuat berdasarkan kndisi berikut :
1. Apakah tanggal penyampaian produk perangkat lunka akan lebih cepat dari pada perangkat lunak yang dikembangkan secara internal?
2. Apakah biaya akuisisi ditambah biaya pemesanan akan lebih kecil dari pada biaya pengembangan perangkat lunak secara internal?
3. Apakah biaya dukungan luar (seperti kontrak pemeliharaan) akan lebih rendah daripada biaya dukungan internal?
Kondisi ini berlaku untuk setiap pilihan akuisisi yang telah dicantumkan di atas
Referensi :
http://pemogramanajip.blogspot.co.id/2012/10/perencanaan-proyek-perangkat-lunak.html
Perencanaan Proyek Perangkat Lunak, oleh Mizar [5105 100 067]
Leave a Reply