Pertemuan 2 Perencanaan Proyek Perencanaan Proyek Memahami maksud

Pertemuan 2 Perencanaan Proyek

Perencanaan Proyek �Memahami maksud dari observasi pada estimasi �Memahami tujuan dari perencanaan proyek �Memahami ruang lingkup, biaya, kebutuhan sumber daya dan estimasi proyek

Definisi Perencanaan Proyek Disiplin untuk menyatakan bagaimana untuk menyelesaikan sebuah proyek dalam jangka waktu tertentu, biasanya dengan tahapan yang ditetapkan dan sumber daya yang ditunjuk.

Observasi pada Estimasi (1) Estimasi yang diperlukan diantaranya adalah sumber daya, biaya, dan jadwal sebagai usaha dalam pengembangan perangkat lunak, akses informasi historis yang baik, keberanian untuk melakukan pengukuran kuantitatif jika 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. �Jika ruang lingkup proyek atau syarat proyek tidak dipahami dengan baik, maka risiko dan ketidakpastian menjadi sangat tinggi. �Harus melengkapi fungsi, kinerja, dan definisi interface(yang diisikan ke dalam spesifikasi sistem). �Pendekatan rekayasa perangkat lunak modern (seperti model proses evolusioner) memakai pandangan pengembangan yang interaktif. 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

Manajemen Proyek 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.

Ruang Lingkup PL 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 1. Tak satupun orang yang tahu apa yang akan dikatakan atau ditanyakan; 2. keduanya khawatir apa yang mereka katakan disalah artikan; 3. keduanya berpikir kemana arah yang akan mereka tuju 4. keduanya ingin pertemuan cepat selesai 5. tetapi pada saat yang sama mereka ingin pertemuan berjalan dengan sukses

Ruang Lingkup PL (lanj) Rangkaian pertanyaan analis 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? Rangkaian 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

Ruang Lingkup PL (lanj) Rangkain akhir dari pertanyaan berfokus pada efektifitas pertemuan �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

Ruang Lingkup PL Menggambarkan: Fungsi yang digambarkan dlm statemen ruang lingkup dievaluasi untuk memberikan awalan yang lebih detail pada saat dimulai estimasi. Fungsi Kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Kinerja Batasan mengidentifikasi batas yang ditempatkan pada PL oleh perangkat keras eksternal, memori atau sistem lain. Batasan Interface dan reliabilitas.

Sumber Daya Manusia PL Lingkungan (Software Engineering Environment - SEE), menggabungkan PL dan Perangkat Keras.

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

Estimasi Proyek PL 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 : 1. Menunda estimasi sampai akhir proyek 2. Mendasarkan estimasi pada proyek – proyek yang mirip yang sudah dilakukan 3. Menggunakan teknik dekomposisi yang relatif sederhana 4. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya perangkat

Dasar Akurasi Estimasi Proyek 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. 1.

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

Organisasi Proyek Aktifitas ini bertujuan menghasilkan output yang terstruktur bagi manajemen dan penentuan progress 2. Milestones merupakan titik akhir dari aktifitas proses 3. Deliverable (pengiriman) merupakan hasil projek yang dikirim ke pelanggan 4. Pada model proses air terjun (waterfall) boleh didefinisikan progress milestone secara langsung 1.

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

4 Usulan Penentuan Ukuran (Putnam & Myers) 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.

Make-Buy 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.

Make-Buy Dalam analisis akhir, keputusan make-buy dibuat berdasarkan kondisi berikut : 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? 1. Kondisi ini berlaku untuk setiap pilihan akuisisi yang telah dicantumkan di atas

Atribut Pengendali Biaya 4 kategori utama : 1. Atribut produk - ukuran keandalan proyek - ukuran dari aplikasi database - kekompleksan produk 2. Atribut perangkat keras - kendala performansi runtime - kendala memori - lingkungan dari violability dari virtual memori - waktu perputaran yg diperlukan

Atribut Pengendali Biaya 3. Atribut personil - kemampuan sistem analis kemampuan software engineering - pengalaman aplikasi - pengalaman virtual mesin - pengalaman bahasa pemrograman 4. Atribut proyek - pemakaian alat bantu PL - metode aplikasi software engineering - jadwal pengembangan

Bonus Makalah + contoh studi kasus �Cocomo II �Use Case Point-Activity-Based Costing �Function Point Analysis �Improved Backpropagation 1. Ekstensi : doc/docx 2. Deadline : Selasa sebelum perkuliahan 3. Email : andriyanto. sidhiq@gmail. com

Terimakasih