Perencanaan Rekayasa Perangkat Lunak

Pembahasan Observasi pada Estimasi Tujuan Perencanaan Proyek Ruang Lingkup Perangkat Lunak Sumber Daya Estimasi Proyek Perangkat Lunak

PERENCANAAN PROYEK PERANGKAT LUNAK Proses Manajemen proyek perangkat lunak Perencanaan Proyek Ruang Lingkup Perangkat Lunak Sumber Daya Estimasi Proyek

Observasi pada Estimasi (1) Estimasi yang diperlukan dalam perancangan proyek perangkat lunak di antaranya adalah sumber daya, biaya, dan jadwal sebagai usaha dalam pengembangan perangkat lunak, mengakses informasi historis yang baik, dan keberanian untuk melakukan pengukuran kuantitatif bila hanya data kualitatif saja yang ada

Observasi pada Estimasi (2) Estimasi membawa resiko yang inheren (dari diri sendiri) dan resiko inilah yang membawa ketidakpastian. Yang mempengaruhi estimasi : Project complexity (kompleksitas proyek) Project size (ukuran proyek) Struktural uncertainty (ketidakpastian struktural)

Observasi pada Estimasi (3) Risiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang dibuat untuk sumber daya, biaya, dan jadwal. Bila ruang lingkup proyek atau syarat proyek tidak dipahami dengan baik, maka risiko dan ketidakpastian menjadi sangat tinggi. Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface(yang diisikan ke dalam spesifikasi sistem). Pendekatan-pendekatan rekayasa perangkat lunak modern (seperti model proses evolusioner) memakai pandangan pengembangan yang interaktif. Dengan pandangan semacam ini dimungkinkan untuk melihat estimasi dan merevisinya bila customer mengubah kebutuhannya

Tujuan Perencanaan Proyek Untuk menyediakan kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal pada awal proyek yang dibatasi oleh waktu.

Merupakan aktifitas manajemen projek yang membutuhkan waktu paling lama Merupakan aktifitas berkelanjutan dari tahap initial hingga pengiriman software sehingga secara regular harus diperbaharui ketika terdapat informasi baru, Beberapa tipe perencanaan (rencana validasi, rencana perubahan managemen, rencana pengembangan dan training staff, rencana perawatan) harus pula dikembangkan untuk mendukung perencanaan projek utama yang memiliki kendala terhadap waktu dan biaya.

Jenis-jenis Perencanaan

Struktur perencanaan projek 1. Pendahuluan 2. Organisasi Projek 3. Analisis Resiko 4. Kebutuhan akan sumber daya hardware dan software 5. Work breakdown 6. Penjadwalan Projek 7. Mekanisme pemantauan dan pelaporan

Pengorganisasian Kegiatan Projek Aktifitas ini bertujuan menghasilkan output yang terstrukur bagi manajemen dan penentuan progress Milestones merupakan titik akhir dari aktifitas proses Deliverable (pengiriman) merupakan hasil projek yang dikirim ke pelanggan Pada model proses air terjun (waterfall) boleh didefnisikan progress milestone secara langsung

Penjadwalan Projek Membagi projek ke dalam bentuk tugas dan estiamsi waktu serta sumber daya yang dibutuhkan untuk menyelesaikan tugas tsb. Pengorganisasian tugas yang bersamaan untuk membuat jadwal yang optimum. Meminimumkan ketergantungan tugas untuk menghindari adanya delay yg ditimbulkan oleh suatu tugas yang menunggu tugas lainnya selesai Ditentukan oleh instusi dan pengalaman manajer

Ruang Lingkup Perangkat Lunak Ruang lingkup PL menggambarkan : fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi yang digambarkan dlm statemen ruang lingkup dievaluasi untuk memberikan awalan yang lebih detail pada saat dimulai estimasi. Kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Batasan mengidentifikasi batas yang ditempatkan pada PL oleh perangkat keras eksternal, memori atau sistem informasi yang ada

Sumber Daya Manusia Perangkat Lunak (Reuseable) Dimulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk menyelesaikan pengembangan. Perangkat Lunak (Reuseable) Komponen Off-the-self (menggunakan PL yang sudah jadi (dari pihak ke tiga)) Komponen Full-Experience (menggunakan PL dari proyek lalu yang serupa) Komponen Partial-Experience (menggunakan PL dari proyek lalu yang serupa tetapi masih membutuhkan modifikasi) Komponen Baru (menggunakan komponen PL yang harus dibangun oleh tim PL khususnya adalah untuk kebutuhan proyek sekarang)

Lingkungan (Software Engineering Environment - SEE), menggabungkan PL dan Perangkat Keras Perangkat keras menyediakan platform yang mendukung piranti perangkat lunak

Estimasi Proyek Perangkat Lunak Estimasi tidak akan pernah menjadi ilmu pasti, disebabkan banyaknya variable (manusia, teknik, lingkungan dan politik) yang mempengaruhi biaya dan usaha akhir yang diaplikasikan untuk mengembangkannya. Beberapa pilihan untuk mencapai estimasi : Menunda estimasi sampai akhir proyek Mendasarkan estimasi pada proyek – proyek yang mirip yang sudah dilakukan Menggunakan teknik dekomposisi yang relatif sederhana Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya perangkat

Akurasi estimasi proyek PL didasarkan pada 1. Tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk yg akan dibuat. 2. Kemampuan mengestimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar. 3. Tingkat dimana rencana proyek mencerminkan kemampuan tim PL. 4. Stabilitas syarat produk serta lingkungan yg mendukung usaha pengembangan PL.

Putnam dan Myers mengusulkan 4 masalah penentuan ukuran Fuzzy-logic sizing (logika kabur) Perencana harus mengidentifikasi tipe aplikasi, membuat besarannya dalam skala kuantitatif kemudian dibandingkan dengan rentang orisinil. Function point sizing Perencana mengembangkan estimasi berdasarkan karakteristik domain informasi. Standard component sizing PL dibangun dari sejumlah 'komponen standar' yg umum (subsistem, modul, laporan, program interaktif). Change sizing Digunakan jika PL yang ada harus dimodifikasi dengan banyak cara sebagai bagian dari proyek.

Data baris kode (LOC) dan titik fungsi (FP) pada estimasi proyek digunakan sebagai: 1. Variabel estimasi yg dipakai untuk mengukur masing-masing elemen PL. 2. Metrik baseline yg dikumpulkan dari proyek yg lalu dan dipakai dengan variabel estimasi untuk mengembangakan proyeksi kerja dan biaya.

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.

Dalam analisis akhir, keputusan make-buy dibuat berdasarkan kondisi berikut : 1. Apakah tanggal penyampaian produk perangkat lunak 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