Tulisan ini berisi beberapa hal yang perlu dikuasai oleh seorang Project  Manager untuk dapat menyusun suatu rencana proyek rekayasa  perangkat lunak. Tulisan ini juga dilengkapi dengan contoh-contoh  dokumen dalam perencanaan proyek rekayasa perangkat lunak.
 
Latar Belakang
 
Proyek Software adalah manajemen proyek yang berfokus hanya pada  membuat dan mengupdate software. Sifat manajemen proyek haruslah seperti  berikut ini:
 
-          Menyeselsaikan masalah,
 
-          Mengerjakan sesuatu hingga selesai,
 
-          Memiliki batas waktu mulai dan selesainya,
 
-          Membutuhkan resource/sumber daya dan waktu,
 
-          Bagi beberapa orang merupakan kesempatan/opportunity  dan menarik.
 
Untuk itu sebuah proyek software perlu di menej. Manajemen itu berupa  persiapan pekerjaan, pelaksanaan rencana, mengendalikan proyek tersebut  dan terakhir menutup proyek dengan sebuah kesimpulan, yaitu sukses.
 
- Initiating: proyek sedang dalam proses untuk  dipilih/disetujui, disponsori, didanai, dan diluncurkan.
- Planning: perencanaan adalah proses yang berulang  (perhatikan gambar). Perencanaan pada dasarnya menggambarkan proses  bagaimana proyek akan dilaksanakan hingga selesai.
- Executing: setelah proyek direncanakan, tim proyek memulai  pekerjaannya.
- Controlling: selama tim proyek mengerjakan tugasnya,  project manager mengontrolnya.
- Closing: setelah proyek diselesaikan project manager akan  menutup proyek software.
 
Banyak proyek gagal di awal, bukan di akhir. Artinya, persiapan  adalah bagian yang sangat penting bagi proyek software. Persiapan  diwujudkan dalam bentuk perencanaan proyek. Tulisan ini menjelaskan  point kedua yaitu Planning.
 
Tujuan Perencanaan Proyek
 
Perencanaan proyek Rekayasa Perangkat Lunak dari berbagai sudut  pandang kurang lebih memiliki tujuan sebagai berikut:
 
- Bagi Project Manager: - untuk menggambarkan status proyek kepada manajer senior dan  stakeholder,
- untuk merencanakan aktivitas tim proyek.
 
- Bagi anggota Tim Proyek: untuk memahami konteks pekerjaan.
- Bagi Manajer Senior: - untuk memastikan apakah biaya dan waktu yang dialokasikan masuk akal  dan terkendali,
- untuk melihat apakah proyek dilaksanakan secara efisien dan cost  effective.
 
- Bagi Stakeholder: - untuk memastikan apakah proyek masih berada pada jalurnya,
- untuk memastikan kebutuhan mereka sedang diakomodir oleh proyek.
 
 
Perencanaan proyek rekayasa perangkat lunak membahas berbagai  tindakan atau pekerjaan yang perlu dilakukan oleh semua yang terlibat di  dalam proyek, termasuk dokumen-dokumen yang sebaiknya dibuat. Dokumen  Perencanaan Proyek Rekayasa Perangkat Lunak akan terdiri atas sub-sub  dokumen berikut ini:
 
- Vision and Scope
- Statement of Work
- Resource List
- Work Breakdown Structure
- Project Schedule
- Risk Plan
 
Berikutnya tiap-tiap dokumen tersebut akan dibahas secara lebih  terperinci.
 
Vision and Scope
 
Dokumen ini adalah hasil kerja pertama dari seorang project manager.  Berikutnya dokumen ini akan menjadi tool utama bagi project manager  untuk acuan bagi dokumen-dokumen dan proses-proses berikutnya. Dokumen  Vision and Scope yang baik dapat mencegah terjadinya masalah-masalah  yang dapat memakan biaya yang besar. Dengan menunjukkan dokumen ini,  baik kepada stakeholder maupun anggota tim proyek, diharapkan pemahaman  yang sama tentang proyek yang sedang berjalan dapat diraih. Dokumen ini  dapat dibagi menjadi dua bagian,yaitu:
 
- Problem Statement
 
Bagian Problem Statement terdiri atas empat sub bab, antara lain:
 
- Latar belakang proyek
 
Sub bab ini menceritakan dengan cukup mendalam baik latar belakang  masalah maupun penjelasan mengenai mengapa organisasi memutuskan untuk  membangun software untuk mengatasi masalah tersebut. Pada sub bab ini  diceritakan sebab munculnya masalah, sejarah organisasi dengan  permasalahan tersebut dan mengapa akhirnya diputuskan untuk membangun  software yang diproyekkan.
 
- Stakeholder
 
Pada sub bab ini akan diberikan daftar stakeholder yang dilibatkan  dalam proyek. Mulai dari customer hingga manajer-manajer senior.  Stakeholder ini bisa berupa nama atau jabatan. Tim proyek harus paham  dengan siapa mereka bekerja dan apa bidang kerja mereka. Daftar juga  dilengkapi dengan alasan dicantumkannya stakeholder tersebut. Untuk  proyek-proyek besar tentu saja pencantuman nama tidak relevan karena  akan menjadi terlalu panjang daftarnya.
 
- Pengguna
 
Sub bab ini berisi daftar calon pengguna software. Sama dengan  stakeholder, bisa berupa nama atau jabatan. Daftar juga dilengkapi  dengan alasan dicantumkannya pengguna tersebut.
 
- Resiko
 
Sub bab ini akan diisi dengan faktor-faktor yang mungkin menjadi  pemicu munculnya masalah, seperti keterlambatan dan permasalahan lain.  Resiko yang dimaksud pada sub bab ini bisa faktor internal maupun  eksternal.
 
- Vision of the Solution
 
Bagian Vision of the Solution juga akan terdiri atas empat sub bab,  yaitu:
 
- Vision statement
 
Tujuan vision statement adalah menggambarkan apa yang ingin dicapai  setelah proyek berjalan. Di dalam sub bab ini disebutkan faktor-faktor  apa yang harus terpenuhi untuk menandakan kapan proyek dinyatakan  selesai. Selain itu tujuan dari proyek juga harus jelas disebutkan di  dalam sub bab ini. Waktu terbaik untuk membuat vision statement adalah  setelah tim melakukan proses Requirement Engineering.
 
Gambaran produk yang ingin dicapai tersebut akan menjadi batasan  ruang lingkup (scope) yang harus diperhatikan oleh semua pihak yang  terlibat di dalam project. Ruang lingkup ini membutuhkan biaya dan waktu  tertentu. Project manager yang baik akan mempersembahkan software tepat  seperti yang telah dijanjikan kepada stakeholder dan user, tepat pada  waktunya dengan menghabiskan biaya (menerima bayaran) tepat sama dengan  perjanjiannya dengan customer.
 
Mungkin ada pendapat bahwa memberikan sedikit bonus fungsi terhadap  software, dengan asumsi bahwa stakeholder atau user akan menyukainya,  maka pendapat itu adalah kesalahan. Antara ruang lingkup, waktu dan  biaya/harga harus ada keseimbangan. Jika ada penambahan pada ruang  lingkup, maka seharusnya ada penambahan waktu atau biaya, jika tidak  maka akan menyebabkan ketidak adilan bagi tim proyek/pengembang. Begitu  juga sebaliknya. Perubahan ruang lingkup mestinya diatur dengan Change  Control System.
 
- Daftar fitur
 
Sebuah paket software umumnya dapat dibagi-bagi menjadi beberapa  fitur. Jumlah yang umumnya dapat diterima adalah sekitar sepuluh fitur.  Jumlah ini sudah cukup menggambarkan kompleksitas software namun tetap  nyaman dibaca oleh tim pengembang. Tiap fitur sebaiknya ditulis dalam  paragraph yang terpisah atau dalam bentuk pointer-pointer. Deskripsi  fitur-fitur ini tidak perlu sangat detil, cukup beberapa kalimat yang  menggambarkan penjelasan umum tentang fitur tersebut. Fitur-fitur ini  mungkin mengalami penambahan atau pengurangan, sesuai dengan permintaan  stakeholder. Jika perlu, sebuah fitur dapat dilengkapi dengan use case.  Namun tentu saja use case dibuat agar cukup simpel untuk dipahami oleh  semua stakeholder.
 
- Ruang lingkup tiap fase (jika perlu)
 
Terkadang deadline yang diberikan untuk mengerjakan sebuah proyek  software membuat pengerjaan seluruh fitur yang diajukan tidak mungkin  selesai. Oleh karenanya dibuat solusi untuk membagi software menjadi  beberapa fase rilis. Software akan dirilis pada saat deadline tercapai,  namun dengan fitur yang dikurangi. Sedangkan rilis berikutnya lah yang  memuat semua fitur.
 
Fitur-fitur yang ada pada rilis awal seharusnya adalah fitur yang  sifatnya lebih penting daripada fitur lainnya, menurut stakeholder. Hal  semacam ini perlu dikonsultasikan kepada tim pengembang.
 
- Fitur yang tidak akan dibuat
 
Terkadang stakeholder meminta fitur yang memang harus  dibuang/ditinggalkan karena tidak masuk akal untuk diselesaikan dalam  waktu yang tersedia, atau karena sebab-sebab lain. Fitur-fitur semacam  ini perlu dicantumkan pada sub bab ini. Ini dicantumkan untuk diketahui  semua pihak agar ada kesepahaman dan agar semua setuju dengan  penghapusan fitur ini.
 
Statement of Work
 
Statement of Work adalah dokumen yang menggambarkan semua produk yang  akan dihasilkan selama proyek berjalan dan siaa yang akan  mengerjakannya. Secara lebih detil, di dalam SOW akan dirinci:
 
- Daftar fitur yang akan dibuat; jika software akan dirilis dalam  fase-fase, maka fiturnya juga harus dibagi ke dalam fase-fase tersebut.
- Deskripsi hasil kerja (work product: spesifikasi kebutuhan, source  code, test plan, laporan defect, dll) yang akan dibuat.
- Estimasi usaha setiap work product tersebut.
 
Estimasi dibutuhkan agar proyek dapat berjalan dan selesai tepat  waktu. Project manager perlu membantu timnya untuk membuat estimasi yang  tepat. Sebuah pendekatan perlu diambil untuk menyeragamkan teknik  estimasi ini. Salah satu teknik estimasi yang dapat dipilih adalah  Wideband Delphi. Berikut ini langkah-langkah di dalam Wideband Delhi:
 
- Memilih tim estimasi
 
Project manager memilih seorang moderator dan tim estimasi yang  terdiri atas 3 hingga 7 orang. Jika tim yang telah dipilih merasa bahwa  dokumen Vision and Scope kurang memberikan informasi, maka project  manager harus memperbaiki dokumen tersebut.
 
- Kickoff Meeting
 
Pada rapat ini, tim akan membuat sebuah Work Breakdown Structure dan  mendiskusikan berbagai asumsi yang muncul. Langkah-langkah yang dapat  dijadikan acuan ketika rapat berlangsung kurang lebih sebagai berikut:
 
- Moderator menjelaskan metode Wideband Delphi,
- Moderator mereview dokumen Vision and Scope dan dokumen-dokumen  pendukungnya, jika ada anggota tim yang belum membacanya,
- Tim mendiskusikan produk yang akan dibuat dengan berbagai asumsinya,
- Tim membuat 10 hingga 20 pekerjaan utama sebagai representasi  pekerjaan level tertinggi pada WBS,
- Tim mendiskusikan estimasi terhadap WBS (jam, minggu, halaman, dll)  tersebut hingga mendapatkan kata sepakat.
- Individual Preparation
 
Setelah kicoff meeting tiap anggota berusaha mengestimasi tiap-tiap  pekerjaan di dalam WBS secara mandiri. Tahapan ini disebut sebagai  Individual Preparation. Sebelumnya, moderator mencatat semua asumsi dan  WBS kemudian membagikannya kepada semua anggota tim. Format berikut ini  bisa dijadikan acuan untuk mendokumentasikan Individual Preparation.
 
- Estimation Session
 
Pada rapat ini, anggota tim bersama-sama merevisi  estimasi-estimasiyang telah dibuat hingga menemukan kata sepakat.  Dokumen berikut dapat dijadikan acuan sebagai contoh untuk membuat  dokumentasi selama Estimation Session. Kepada setiap anggota tim akan  dibagikan dokumen semacam ini (yang kosong) untuk kemudian direvisi  selama jalannya Estimatin Session.
 
Berikutnya:
 
- Moderator dapat mengumpulkan Estimation Form. Estimasi tersebut  kemudian ditabulasikan di papan tulis kemudian ditunjukkan kepada  hadiri.
 
Estimation Form kemudian dikembalikan kepada anggota tim.
 
- Anggota kemudian akan melihat tabulasi tersebut. Jika diskusi  meminta perubahan estimasi, maka perubahan tersebut dapat langsung  dituliskan pada Estimation Form yang ada di tangan setiap anggota tim.
- Anggota tim mungkin akan menyampaikan perbedaanpendapat. Tetapi di  dalam rapat ini tidak akan dibahas estimasi individu. Jadi yang mungkin  diperdebatkan justru pekerjaannya. Tahap ini mugkin terbagi menjadi dua  sesi, sesi pertama 40 menit dan sesi kedua 20 menit.
- Rapat akan merevisi estimasi individu dengan mengisikan kolom Delta  berikutnya pada form Estimation Form. Isinya bisa +3, +2, -4 dsb. Nilai  total barunya akan dituliskan pada bagian bawah form.
 
Tahap-tahap di atas dapat berulang hingga selesai, yaitu jika semua  anggota tim menyetujui estimasi hasil rapat, atau jika rapat sudah  berlangsung selama dua jam.
 
- Review
 
Project manager akan meringkas, mengkompail kemudian mereview hasil  estimasi untuk kemudian digunakan sebagai dasar perencanaan proyek  software.
 
Resource List
 
Resource list adalah daftar resource/sumber daya yang digunakan  selama proyek berlangsung. Daftar ini berisi apa saja yang dibutuhkan  berdasarkan jadwal proyek dengan mencantumkan deskripsi resource  tersebut serta limit ketersediaan resource tersebut. Daftar semacam ini  umumnya dapat dibuat menggunakan software manajemen proyek. Tetapi bisa  juga dibuat dengan worksheet atau word processor. Setelah SOW dan  Resource List dibuat, seorang project manager harus membuat jadwal  proyek (project schedule). Ini bisa dilakukan dengan urutan sebagai  berikut:
 
- Membuat Work Breakdown Structure
- Estimasi usaha yang dibutuhkan oleh setiap pekerjaan pada WBS
- Project schedule dibuat dengan mengalokasikan resource dan waktu,  berdasarkan kalender, untuk tiap pekerjaan pada WBS.
 
Jika WBS mengalami revisi (setelah melakukan estimasi, misalnya),  misalnya penambahan, perubahan atau penghapusan pekerjaan, maka revisi  ini harus tercatat di dalam dokumen Project Plan dengan disertai dengan  keterangan waktu kapan dibuatnya perubahan tersebut.
 
Work Breakdown Structure
 
Work Breakdown Structure, disingkat WBS, berisi daftar pekerjaan yang  jika diselesaikan akan menghasilkan work product. WBS menyebutkan:
 
- Apa saja pekerjaan yang akan dilakukan,
- Tipe-tipe resource yang dibutuhkan untuk bekerja,
- Estimasi tiap elemen pekerjaan,
- Identifikasi lokasi penyimpanan.
 
Tetapi tidak mencantumkan:
 
- Siapa yang mengerjakan pekerjaan-pekerjaan itu,
- Dan kapan pekerjaan itu akan diselesaikan.
 
Project Schedule
 
Project Schedule atau jadwal proyek dibuat oleh project manager untuk  mengatur manusia di dalam proyek dan menunjukkan kepada organisasi  bagaimana pekerjaan (proyek) akan dilaksanakan. Ini adalah alat untuk  memantau (bagi project manager) apakah proyek dan tim masih terkendali  atau tidak.
 
Project schedule berbentuk kalender yang dihubungkan dengan pekerjaan  yang harus dikerjakan dan daftar resource yang dibutuhkan. Sebelum  jadwal dibuat, WBS harus terlebih dahulu ada, jika tidak maka jadwal  tersebut akan terkesan mengada-ada.
 
Untuk membuat project schedule, ada beberapa software yang bisa  dijadikan pilihan. Pilihan software yang gratis dan open source antara  lain: Open Workbench, dotProject, netOffice dan Tutos. Beberapa hal  perlu diperhatikan ketika membuat project schedule, seperti:
 
- Alokasi resource pada tiap pekerjaan,
 
Resource bisa berupa berbagai hal seperti manusia, barang, peralatan  (komputer, proyektor, dll), tempat (ruang rapat, misalnya) atau layanan  (seperti training atau tim pendukung out source) yang dibutuhkan dan  mungkin ketersediaannya terbatas. Bagaimanapun juga resource yang utama  adalah manusia.
 
Pertama, project manager akan mengalokasikan orang(-orang) tertentu  untuk suatu pekerjaan. Kemudian, selama pekerjaan tersebut berlangsung,  orang tersebut mungkin menjadi terlalu sibuk sehingga tidak bisa  dialokasikan untuk pekerjaan lainnya. Perhatikan bahwa pemilihan pelaku  perlu disesuaikan dengan kemampuan dan berbagai hal lain karena ada  pekerjaan yang dapat dilakukan oleh siapa saja, tetapi umumnya pekerjaan  hanya dapat dikerjakan oleh satu atau beberapa orang saja.
 
- Identifikasikan setiap ketergantungan,
 
Sebuah pekerjaan disebut memiliki ketergantungan jika melibatkan  aktivitas, resource atau work product yang dihasilkan  pekerjaan/aktivitas lain. Contoh: test plan tidak mungkin dilaksanakan  selama software belum diimplementasikan/ditulis, program baru dapat  ditulis setelah class atau modul dibuat dan dideskripsikan pada tahapan  desain.
 
Tiap pekerjaan pada WBS perlu diberi nomor, dengan angka tersebut  bergantung pada nomor pekerjaan syaratnya.
 
3. Buat jadwalnya
 
Tiap pekerjaan juga memiliki jangka waktu pekerjaan. Dengan demikian  jadwal bisa dibuat, Tiap pekerjaan ditunjukkan dengan kotak, sedangkan  ketergantungan antar pekerjaan ditunjukkan dengan gambar panah. Kotak  hitam berbentuk wajik antara D dan E (pada gambar di atas) disebut  milestone atau pekerjaan tanpa durasi. Milestone digunakan untuk  menunjukkan kejadian penting pada jadwal. Sedangkan kotak hitam panjang  antara C dan D yang juga mengandung potongan wajik menunjukkan summary  task atau dua sub pekerjaan yang memiliki induk yang sama.
 
 
 
Risk Plan
 
Risk plan adalah daftar resiko/masalah yang mungkin terjadi selama  proyek berlangsung dan bagaimana menangani terjadinya resiko tersebut.  Bagaimanapun juga ketidakpastian adalah musuh semua rencana, termasuk  rencana proyek. Terkadang ada saja waktu-waktu yang tidak menyenangkan  bagi proyek, banyak kesulitan terjadi misalnya suatu resource tiba-tiba  tidak tersedia. Oleh karenanya risk plan adalah persiapan terbaik  menghadapi ketidakpastian.
 
Langkah-langkah berikut dapat menjadi acuan untuk mendapatkan Risk  Plan:
 
- Pembahasan resiko potensial
 
Project manager akan memimpin sebuah sesi/rapat untuk  mengidentifikasikan masalah-masalah yang mungkin akan muncul. Anggota  tim akan dipancing untuk mengemukakan resiko-resiko yang terpikirkan.  Project manager akan menuliskannya di papan tulis setiap ada yang  mengemukakan pendapat yang relevan. Sedikit pendapat mungkin akan muncul  pada awalnya, kemudian berlanjut dengan tanggapan yang susul-menyusul  hingga akhirnya suasana mendingin sampai akhirnya pendapat terakhir  diutarakan.
 
Resiko yang dimaksud di sini adalah resiko spesifik. Jika suatu  resiko dirasa belum spesifik maka project manager akan memancing agar  permasalahan disampaikan secara lebih spesifik. Sumber masalah yang baik  lainnya adah asumsi-asumsi yang muncul ketika membuat Vision and Scope  dan melakukan estimasi dengan metode Wideband Dephi.
 
- Estimasi dampat tiap resiko/masalah
 
Tim akan memberikan rating untuk setiap resiko. Nilainya berkisar  dari 1 (masalah dengan resiko kecil) hingga 5 (masalah dengan resiko  besar, kemungkinan munculnya besar, mungkin menghabiskan biaya besar dan  sulit untuk membereskannya).
 
- Buat sebuah risk plan
 
Tim akan mengidentifikasi langkah-langkah yang akan di ambil untuk  mengatasi masalah-masalah yang akan muncul tersebut, dimulai dari resiko  bernilai 5.
 Read More..