SESI 4. PERENCANAAN PROYEK PL

Presentasi berjudul: "SESI 4. PERENCANAAN PROYEK PL"— Transcript presentasi:

1 SESI 4. PERENCANAAN PROYEK PL
WEDA A. DEWA, S.Kom., MMSI

2 SESI 4. Perencanaan Proyek PL
Observasi terhadap estimasi Tujuan perencanaan proyek Ruang lingkup PL Estimasi sumberdaya Estimasi proyek software

3 Observasi terhadap estimasi
Proses manajemen proyek perangkat lunak dimulai dengan kegiatan project planning (perencanaan proyek). Yang pertama dari aktifitas ini adalah estimation (perkiraan). Estimasi membawa resiko yang inheren (dari diri sendiri) dan resiko inilah yang membawa ketidakpastian. Yang mempengaruhi estimasi al: - Project complexity (kompleksitas proyek) - Project size (ukuran proyek) - Struktural uncertainty (ketidakpastian struktural)

4 Tujuan Perencanaan Proyek
Untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan terhadap sumber daya, biaya dan jadwal pada awal proyek yang dibatasi oleh waktu. Aktivitas Perencanaan proyek PL : Menentukan ruang lingkup PL Mengestimasi sumber daya yang dibutuhkan

5 Ruang lingkup software
Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi antara pelanggan dengan pengembang serta untuk memulai proses komunikasi adalah dengan melakukan pertemuan atau wawancara pendahuluan Tak satupun orang yang tahu apa yang akan dikatakan atau ditanyakan; keduanya khawatir apa yang mereka katakan akan disalah artikan; keduanya berpikir kemana arah yang akan mereka tuju; keduanya ingin pertemuan cepat cepat seleasi; tetapi pada saat yang sama mereka ingin pertemuan berjalan dengan sukses

6 Ruang lingkup software (lanj)
Contoh rangkaian pertanyaan : Rangkain pertanyaan analis yang berfokus pada pelanggan, tujuan keseluruhan serta keuntungan Siapakah yang menginginkan pekerjaan tersebut? Siapa yang akan mempergunakan solusi tersebut? Apa saja keuntungan ekonomis yang akan didapatkan jika solusi tersebut berhasil? Adakah sumber lain untuk solusi tersebut? Rangkain pertanyaan analis yang memungkinkan analis untuk memahami masalah lebih baik serta memungkinkan pelanggan menyuarakan persepsi mereka tentang sebuah solusi Bagaimana batasan karakter output yang baik menurut customer yang akan dihasilkan melalui solusi tersebut Problem apa saja yang bisa diatasi terhadap solusi tersebut? Dapatkah anda menunjukkan lingkungan dimana solusi tersebut akan dipergunakan? Adakah performance khusus atau constraint yang mempengaruhi solusi tersebut?

7 Ruang lingkup software (lanj)
Contoh rangkaian pertanyaan lanjuatan Rangkain akhir dari pertanyaan berfokus pada efektifitas pertemuan, adapun beberapa contoh pertanyaannya adalah sbb: Apakah anda orang yang tepat untuk menjawab pertanyaan ini? Apakah jawaban anda merupakan jawaban yang “resmi” Apakah pertanyaan saya relevan terhadap persoalan yang anda hadapi? Apakah pertanyaan saya terlalu banyak? Apakah masih ada hal lain yang sebaiknya saya tanyakan kepada anda? Pertanyaan-pertanyaan tersebut akan membantu “memecahkan kekakuan” dan memulai komunikasi yang esensial untuk menentukan ruang lingkup proyek

8 pendukung pengembangan
Estimasi sumber daya Tugas kedua perencanaan software adalah estimasi sumber daya yang diperlukan untuk pengembangan software. Manusia Komponen Perangkat Lunak reusable Piranti Hardware/Software Sumberdaya Utama Mengurangi biaya pengembangan Infrastruktur pendukung pengembangan

9 Estimasi sumber daya (lanj)
Perencanaan mulai evaluasi scope dan memilih keahlian yang dibutuhkan untuk pengembangan. Perencana harus menentukan posisi organisasional (misal: manajer, software enginer dll) dan speciality (misal: telecomunication, database, client /server). Untuk proyek yang relatif kecil (6 orang-month atau kurang), seseorang bisa melaksanakan semua tahapan rekayasa software, konsultasi dengan spesialis pada saat diperlukan Jumlah orang yang dibutuhkan untuk sebuah proyek software bisa ditentukan setelah adanya estimasi usaha untuk pengembangan (misal: person-month atau person-years).

10 Estimasi sumber daya (lanj)
Sumber Daya Perangkat Lunak Reuseable Sumberdaya perangkat lunak tidak bisa dilepaskan dari pengetahuan tentang reusability yaitu kreasi dan penggunaan kembali blok bangunan perangkat lunak. Blok bangunan tersebut harus dikatalog menjadi referensi yang mudah, distandarisasi untuk aplikasi yang mudah dan divalidasi untuk integrasi yang mudah

11 Estimasi sumber daya (lanj)
Ada empat kategori sumberdaya perangkat lunak yang harus dipertimbangkan pada saat perencanaan sedang berlangsung, yaitu: Komponen Off-the-self =>Perangkat lunak yang ada dapat diperoleh dari sebagian software yang telah dikembangkan oleh pihak ketiga pada proyek sebelumnya. Komponen tersebut siap digunakan pada proyek sekarang dan telah divalidasi. Komponen Full-Experience=>Spesifikasi, desain, kode atau data test yang telah yang dikembangkan pada proyek sebelumya serupa dengan proyek yang sedang dikerjakan. Setiap anggota tim software mempunyai pengalaman penuh pada bidang aplikasi yang disajikan. Maka modifikasi pada Full experience component beresiko lebih rendah

12 Estimasi sumber daya (lanj)
Komponen Partial-experiance =>Aplikasi, desain, kode atau data test yang telah dikembangkan pada proyek sebelumya dihubungkan dengan perangkat lunak yang hendak dikembangkan tetapi membutuhkan modifikasi substansial. Anggota tim software mempunyai pengalaman yang terbatas pada area aplikasi tersebut. Maka modifikasi pada partial experience component beresiko sedang Komponen Baru =>Komponen software yang harus dibuat oleh tim sesuai dengan kebutuhan proyek sekarang.

13 Estimasi proyek PL Untuk mendapatkan estimasi biaya dan effort(usaha) yang bisa dipertanggung jawabkan, maka muncul sejumlah opsi: Estimasi delay sampai dengan terlambatnya proyek (estimasi biaya akurat 100% jika proyek selesai). Estimasi dasar pada proyek serupa yang telah dikembangkan Gunakan teknik dekomposisi yang sederhana untuk menghasilkan biaya dan effort proyek tersebut. Gunakan satu atau beberapa model empiris untuk estimasi biaya dan effort software.

14 Estimasi proyek PL (lanj)
Teknik dekomposisi/pedekatan dekomposisi dapat dilihat dari dua sudut pandang yaitu: Dekomposisi masalah. Dekomposisi proses Sebelum estimasi dibuat, perencana software harus mengetahui batasan software yang akan dibangun dan kemudian membuat estimasi dari “ukurannya”

15 Teknik Dekomposisi Software Sizing
Estimasi biaya dan usaha dapat dilakukan dengan cara : Menunda estimasi sampai akhir proyek. Berdasarkan estimasi pada proyek yg mirip sebelumnya. Menggunakan 'teknik dekomposisi' yg relatif sederhana u/ estimasi biaya dan usaha proyek. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya PL.

16 Teknik Dekomposisi (lanj)
Akurasi estimasi proyek perangkat lunak didasarkan pada sejumlah hal al: Tingkat ketepatan seorang perencana PL dalam mengestimasi ukuran perangkat lunak Kemamapuan menterjemahkan estimasi ukuran PL ke dalam kerja manusai, waktu kalender, dan biaya Tingakat dimana rencana proyek mencerminkan kemampuan tim perangkat lunak. Stabilitas keutuhan prokud serta lingkungan yang mendukung usaha pengembangan perangkat lunak

17 Keputusan membuat/membeli
Pada aplikasi PL, dari segi biaya sering lebih efektif membeli dari pada mengembangkan sendiri. Manajer RPL dihadapkan pada keputusan make-buy dengan pilihan : PL dapat dibeli (atau lisensi) off-the-self. Komponen PL full-experience dan partial-experience, dapat diperoleh dan kemudian dimodifikasi dan integrasi untuk memenuhi kebutuhan sendiri. PL dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi pembeli.

18 Keputusan membuat/membeli (lanj)
Untuk produk PL yang mahal, langkah-langkah di bawah ini dapat dipetimbangkan: 1. Kembangkan spesifikasi untuk fungsi dan kinerja PL yg diperlukan. 2. Perkirakan biaya internal untuk pengembangan dan tanggal penyampaian. 3. a. Pilih tiga atau empat calon aplikasi yang paling cocok dengan aplikasi anda. b. Pilih komponen yang reusable yg dapat membantu konstruksi aplikasi yg diperlukan. 4. Kembnagkan sebuah matriks perbandingan untuk membandingkan calon PL. 5. Evaluasi masing-masing paket PL berdasarkan kualitas produk sebelumnya, dukungan penjual, arah proyek, reputasi dsb. 6. Hubungi pemakai PL lain dan mintalah pendapat mereka.

19 Keputusan membuat/membeli (lanj)
Pada analisis akhir, keputusan make-buy berdasarkan kondisi sbb : Tanggal penyampaian Biaya yang diperlukan Dukungan

20 Keputusan membuat/membeli (lanj)
Membuat pohon keputusan untuk mendukung make buy: Rekayasa atau organisasi PL dapat menggunakan teknik statistik analisis pohon keputusan dengan pilihan : Membangun sistem X dari permulaan Menggunakan lagi komponen partial experience yang ada untuk membangun sistem Membeli sebuah produk perangkat lunak yang dapat diperoleh dan dimodifikasi untuk memenuhi kebutuhan lokal

21 Terima kasih lakukan segala sesuatu dengan tulus