Chapter 23 Project Planning

Perencanaan proyek berlangsung dalam tiga tahap dalam siklus hidup proyek:
1. Pada tahap proposal, untuk membantu anda memutuskan apakah anda
memliki sumber daya untuk menyelesaikan pekerjaan dan untuk menentukan
harga yang harus anda tawarkan kepada pelanggan.
2. Selama fase permulaan proyek, ketika anda harus merencanakan siapa yang
akan mengerjakan proyek, bagaimana proyek akan dipecah menjadi beberapa
bagian, bagaimana sumber daya akan dialokasikan ke seluruh perusahaan
anda, dll.
3. Secara berkala selama proyek berlangsung, ketika anda memodifikasi rencana
anda berdasarkan pengalaman yang diperoleh dan informasi dari pemantauan
kemajuan pekerjaan.

23.1 Software Pricing

Saat menghitung harga, anda harus mempertimbangkan organisasi, ekonomi,
pilotik, dan pertimbangan bisnis, seperti yang ditunjukkan pada Gambar 23.1. karena
pertimbangan organisasi yang terlibat, memutuskan harga proyek harus menjadi
aktivitas kelompok yang melibatkan staf pemasaran dan penjualan, manajemen senior,
dan manajemen proyek.

Gambar 23.1

Biaya proyek disetujui berdasarkan proposal garis besar. Negosiasi kemudian

terjadi antara klien dan pelanggan untuk menetapkan spesifikasi proyek yang
terperinci. Spesifikasi ini dibatasi oleh biaya yang disepakati. Faktor tetap dalam
banyak proyek bukanlah persyaratan proyek tetapi biaya. Persyaratan dapat diubah
agar biayanya tidak terlampaui.
23.2 Plan-Driven Development
Plan-driven atau plan-based development adalah pendekatan rekayasa perangkat
lunak dimana proses pengembangan direncanakan secara rinci. Sebuah rencana
proyek dibuat yang mencatat pekerjaan yang harus dilakukan, siapa yang akan
melakukannya, jadwal pengembangan, dan produk pekerjaan. Manajer menggunakan
rencana tersebut untuk mendukung pengambilan keputusan proyek dan sebagai cara
untuk mengukur kemajuan. Plan-drive development didasarkan pada teknik
manajemen proyek rekayasa dan dapat dianggap sebagai cara ‘tradisional’ dalam
mengelola proyek pengembangan perangkat lunak besar.

23.2.1 Project Plans

Pada rincian spesifik dari rencana proyek bervariasi tergantung pada jenis proyek
dan organisasinya, rencana biasanya mencakup bagian-bagian berikut:
1. Introduction, ini menjelaskan secara singkat tujuan proyek dan menetapkan
batasan (mis. Anggaran, waktu, dll.) yang memengaruhi manajemen proyek
2. Project organization, ini menjelaskan cara tim pengembangan diatur, orang-
orang terlibat, dan peran mereka dalam tim.
3. Risk analysis, ini menjelaskan kemungkinan risiko proyek, kemungkinan
timbulnya risiko ini, dan strategi pengurangan risiko yang diusulkan.
4. Hardware and software resource requirements, ini menentukan perangkat
keras dan perangkat lunak pendukung yang diperlukan unutk melakukan
pengembangan. Jika perangkat keras harus dibeli, perkiraan harga dan jadwal
pengiriman dapat disertakan.
5. Work breakdown, ini menetapkan rincian proyek menjadi kegiatan dan
mengidentifikasi tonggak dan kiriman yang terkait dengan setiap kegiatan.
Tonggak pencapaian adalah tahapan kunci dalam proyek dimana kemajuan
dapat dinilai; kemampuan pengiriman adalah produk kerja yang dikirimkan
ke pelanggan.
6. Project schedule, ini menunjukkan ketergantungan antara kegiatan, perkiraan
waktu yang dibutuhkan untuk mencapai setiap tonggak dan alokasi orang
untuk kegiatan.
7. Monitoring and reporting machanisms, ini menentukan laporan manajemen
yang harus dibuat, kapan harus dibuat, dan mekanisme pemantauan proyek
yang kakan digunakan.
 Contoh rencana tambahan yang mungkin ditunjukkan pada Gambar 23.2.

Gambar 23.2

23.2.2 The Planning Process

Perencanaan proyek adalah proses berulang yang dimulai saat anda membuat
rencana proyek awal selama fase permulaan proyek. Gambar 23.3 adalah diagram
aktivitas UML yang menunjukkan alur kerja umum untuk proses perencanaan proyek.
Perubahan rencana tidak bisa dihindari. Semakin banyak informasi tentang sistem dan
tim proyek tersedia selama proyek berlangsung, anda harus secara teratur merevisi
rencana untuk mencerminkan persyaratan, jadwal, dan perubahan risiko.

Gambar 23.3

23.3 Project Scheduling

Penjadwalan dalam plan-driven project (Gambar 23.4) melibatkan pemecahan
total pekerjaan yang terlibat dalam proyek menjadi tugas-tugas terpisah dan
memperkirakan waktu yang dibutuhkan untuk menyelesaikan setiap tugas. Tugas
biasanya harus berlangsung setidaknya seminggu, dan tidak lebih dari 2 bulan. Jumlah
waktu maksimum untuk tugas apapun harus sekitar 8 hingga 10 minggu. Jika
membutuhkan waktu lebih lama dari ini, tugas harus dibagi lagi untuk perencanaan
dan penjadwalan proyek.

Gambar 23.4

23.3.1 Schedule Representation

Jadwal proyek dapat direpresentasikan secara sederhana dalam tabel atau
spreedsheet yang menunjukkan tugas, usaha, durasi yang diharapkan, dan
ketergantungan tugas (Gambar 23.5). Ada dua jenis representasi yang umum
digunakan:
1. Grafik batang, yang berbasis kalender, menunjukkan siapa yang bertanggung
jawab untuk setiap aktivitas, perkiraan waktu yang telah berlalu, dan kapan
aktivitas dijadwalkan untuk dimulai dan diakhiri.
2. Jaringan aktivitas, yang merupakan diagram jaringan, menunjukkan
ketergantungan antara berbagai aktivitas yang membentuk sebuah proyek.
Biasanya alat perencanaan proyek digunakan untuk mengelola informasi jadwal
proyek. Alat ini biasanya meminta anda untuk memasukkan informasi proyek ke
dalam tabel dan kemudian akan membuat database informasi proyek. Bagan batang
dan bagan aktivitas kemudian dibuat secara ototmatis dari database ini. Kegiatan
proyek adalah elemen perencanaan dasar. Setiap aktivitas memiliki:
1. Durasi dalam hari atau bulan kalender.
2. Perkiraan upaya, yang mencerminkan jumlah orang-hari atau orang-bulan
untuk menyelesaikan pekerjaan.
3. Tenggat waktu penyelesaian kegiataan.
4. Titik akhir ditentukan. Ini bisa berupa dokumen, diadakannya rapat tinjauan,
pelaksanaan semua tes yang berhasil, dll.
 Gambar 23.5

23.4 Agile Planning

Agile methods pengembangan perangkat lunak adalah pendekatan berulang
dimana pernagkat lunak dikembangkan dan dikirm ke pelanggan secara bertahap.
Tidak seperti plan-driven, fungsionalitas peningkatan ini tidak direncanakan
sebelumnya tetapi diputuskan selama pengembangan. Keputusan tentang apa yang
kakan dimasukkan dalam selisih bergantung pada kemajuan dan prioritas pelanggan.
Pendekatan tangkas yang paling umum digunakan seperti scrum (Schwaber, 2004)
dan pemrograman ekstrim (beck, 2000) memiliki pendekatan dua tahap untuk
perencanaan, sesuai dengan fase permulaan dalam perencanaan pengembangan dan
pengembangan yang digerakkan oleh rencana:
1. Perencanaan rilis, yang melihat ke depan selama beberapa bula dan
memutuskan fitur yang harus disertakan dalam rilis sistem.
2. Perencanaan iterasi, yang memiliki pandangan jangka pendek dan berfokus
pada perencanaan penambahan sistem berikutnya. Ini biasanya 2 hingga 4
minggu kerja untuk tim.
Gambar 23.8 menunjukkan tahapan-tahapan dalam permainan perencanaan.

Gambar 23.8

23.5 Estimation Techniques

 Organisasi perlu membuat upaya perangkat lunak dan perkiraan biaya. Ada dua
jenis teknik yang dapat digunakan untuk melakukan teknik ini:
1. Experiences-based techniques, perkiraan kebutuhan usaha di masa depan
didasarkan pada pengalaman manajer proyek masa lalu dan domain aplikasi.
Pada dasarnya, manajer membuat penilaian berdasarkan informasi tentang
kemungkinan persyaratan upaya yang akan dilakukan.
2. Algorithmic cost modeling, digunakan untuk menghitung upaya proyek
berdasarkan perkiraan atribut produk, seperti ukuran, dan karalteristik proses,
seperti pengalaman staf yang terlibat.

23.5.1 Algorithmic Cost Modeling

Pemodelan biaya algoritma menggunakan rumus matematika untuk memprediksi
biaya proyek berdasarkan perkiraan ukuran proyek; jenis perangkat lunak yang
dikembangkan; dan faktor tim, proses, dan produk lainnya. Model algoritmik untuk
memperkirakan upaya dalam proyek perangkat lunak sebagian besar didasarkan pada
rumus sederhana:
Effort = A x SizeB x M
A adalah faktor konstan yang bergantung pada praktik organisasi lokal dan jenis
perangkat lunak yang dikembangkan. Ukuran dapat berupa penilaian ukuran kode
perangkat lunak atau perkiraan fungsionalitas yang dinyatakan dalam fungsi atau poin
aplikasi.
Nilai eksponen B biasanya berada di antara 1 dan 1,5. M adalah pengali yang
dibuat dengan menggabungkan atribut proses, produk, dan pengembangan, seperti
persyaratan ketergantungan untuk perangkat lunak dan pengalaman tim
pengembangan.

23.5.2 The COCOMO II Model

Submodel yang merupakan bagian dari model COCOMO II adalah:
1. An application-composition model, diperlukan untuk mengembangkan sistem
yang dibuat dari komponen yang dapat digunakan kembali, skrip, atau
pemrograman database. Perkiraan ukuran perangkat lunak didasarkan pada
poin aplikasi, dan rumus ukuran / produktivitas sederhana digunakan untuk
memperkirakan upaya yang diperlukan.
 2. An early design model, digunakan pada tahap awal desain sistem setelah
persyaratan ditetapkan. Estimasi tersebut didasarkan pada rumus estimasi
standar yang telah saya diskusikan di bagian pendahuluan, dengan tujuh
pengali yang disederhanakan.
3. A reuse model, digunakan untuk menghitung upaya yang diperlukan untuk
mengintegrasikan komponen yang dapat digunakan kembali dan / atau kode
program yang dibuat secara otomatis.
A post-architecture model, setelah arsitektur sistem dirancang, perkiraan ukuran
perangkat lunak yang lebih akurat dapat dibuat.