Mata Kuliah Semester 6: Manajemen Proyek Perangkat Lunak

gambar: ontimec.com

Manajemen Proyek Perangkat Lunak atau MPPL bisa diambil di semester genap, esp semester 6, dan punya bobot 4 sks. Kuliah ini menurut saya kuliah bidang minat RPL banget karena ada teori (ttg manajemen proyek,  dsb), praktek langsung bikin proyek, dan ngoding :)

Pengalaman kemarin, kuliah MPPL kami belajar tentang manajemen proyek pembuatan aplikasi dari awal hingga akhir dengan menggunakan Rational Unified Process (c) IBM. Rational Unified Process itu seperti framework manajemen proyek yang merupakan best practices dari berbagai macam proyek dan banyak organisasi.



Ciri-ciri dari RUP adalah proses development software yang iteratif, manajemen kebutuhan yang rinci, arsitektur yang berbasis komponen, pemodelan software secara visual (dengan diagram-diagram, dll), evaluasi software secara berkala beserta rencana perbaikan, dan mengontrol perubahan software.

Untuk gampangnya saya cerita saja dari awal hingga akhir perjuangan kami kemarin :)

FP Sejak Awal
Pertama-tama, sejak awal perkuliahan, kami sudah diberi judul proyek yang menurut saya lumayan besar, yaitu membuat aplikasi pendeteksi plagiarisme dalam dokumen (doc, docx, pdf, txt, dll). Aplikasinya harus mampu menerima input dokumen dan membandingkannya dengan dokumen lain untuk dicari presentase kesamaannya. Kalau tinggi, berarti kemungkinan plagiatnya tinggi, dsb.

Nah jadi sejak minggu-minggu awal kami sudah siap-siap bikin FP.

Langkah-langkahnya?
Langkah awal otomatis bagi tugas satu tim. Siapa Project manager, tim analist, tim desainer, tim programmer, tim tester, tim lainnya kalau ada (terserah kelompoknya, tapi harus bisa dipertanggungjawabkan). Setelah project manager terbentuk, baru bisa jalan ke perencanaan langkah selanjutnya.

Milestone, Iteration, Phase
Terus kelompok itu harus punya milestone, seperti tonggak pencapaian dalam sepanjang perjalanan development. Milestone-milestone ini harus bisa dipetakan/didistribusikan dalam 4 fase RUP: inception, elaboration, construction, transition. Lalu, tiap fase harus memiliki rencana iterasi.

Misalnya di fase inception, kelompok kami punya milestone:
1. Terlaksana meeting dengan client sebanyak 2 kali
2. Dokumen Software Development Plan sudah fix
3. Client menyetujui rencana kebutuhan aplikasi yang terdapat di dokumen SDP
4. Bussines Case diagram selesai 20%
5. Terdapat pembagian tugas pada setiap anggota kelompok
6. Dsb

Btw, yang di atas itu cuma contoh, mungkin masih salah. Yang jelas, milestone harus bisa diukur keberhasilannya dan ada bukti yang menunjukkan apakah sebuah milestone telah dicapai atau gagal. Misalnya: keberhasilan milestone 1 dibuktikan dengan adanya bukti meeting, yaitu notulensi yang ditandatangani. Misalnya lagi, milestone 2 dibuktikan dengan adanya dokumen SDP yang disetujui asisten, dsb.

Milestone tidak boleh abstrak karena akan susah dibuktikan dan dipertanggungjawabkan. Misalnya milestone "Resiko-resiko sudah diidentifikasi dan siap ditanggulangi" tidak akan bisa dibuktikan karena tidak ada bukti yang menunjukkan bahwa suatu resiko telah siap ditanggulangi. Namun ini semua bergantung sikon dan bergantung kepiawaian Project Manager dalam mengatur proyeknya.

Selain milestone, dalam satu fase juga harus terdapat rencana iterasi. Apakah suatu fase cuma 1 iterasi, atau 2 iterasi, dsb. Semuanya tergantung kebijakan kelompok dan harus terdapat Iteration Plan (rencana) dan Iteration Assessment (evaluasi) dalam tiap iterasi yang dituangkan dalam dua dokumen yang berbeda. Hasil iterasi sebelumnya menjadi masukan dalam iterasi berikutnya dan otomatis mempengaruhi rencana/agenda iterasi tersebut.

Milestone dan iterasi harus ada dalam tiap 4 fase, dan bisa berubah-ubah sesuai kondisi dan pencapaian tim. Kalau lemot, ya bisa saja jadwalnya mundur, hehe. Begitu juga 4 fase tersebut harus direncanakan rentang waktunya biar nggak molor.

Perencanaan belum cukup sampai di situ saja XD

Diagram-diagram
Selain dokumentasi proyek dalam bentuk dokumen, tim harus bisa membuat model software secara visual. Kemarin kami memakai lagi yang namanya UML (Universal Modelling Language) yang merupakan pemodelan dengan berbagai diagram: Bussiness Case Diagram, Activity Diagram, dsb yang sudah dipelajari di kuliah APS.

Ngoding, testing
Setelah perencanaan software, yang pasti adalah ngoding. Seharusnya, kalau rancangan software bagus, tim programmer tidak akan kesulitan karena tinggal terima rancangan dan langsung dibuat kodenya. Jadi yang mikir desain softwarenya bukan programmer karena sudah ada daftar fungsi (plus parameter input dan output, definisi fungsi, dll), ada class diagram (tinggal bikin), dsb. Mungkin yang jadi tantangan buat programmer adalah di bagian bahasa pemrograman dan teknisnya.

Sejalan dengan tim programmer yang sudah jalan, tim tester harus bersiap-siap merencanakan strategi testing yang dipakai. Lalu dilaksanakan testing dan didokumentasikan lagi :D

Pelaksanaan jobdesk
Dalam RUP, tiap orang harus memiliki jobdesk yang jelas. Hal ini bergantung sama Project Manager yang pintar bagi tugas dan tegas nagihin tugas. Kalau jobdesknya ngga jelas, bisa-bisa satu orang nganggur, satu orang kerja semaleman. Kalau ada yang molor, bisa saja orang lain molor karena kerjaannya nunggu dari orang tadi, dsb.

Begitulah kerja tim akan berlangsung dari awal perkuliahan hingga sidang akhir di akhir semester XD

Kebutuhan tambahan
Berikut ini hal-hal yang ngga kalah penting...

Manajemen waktu dan sumber daya
Berdasarkan pengalaman kemarin, tim analist dan desainer itu berat di awal perkuliahan karena masuk fase awal (inception, elaboration). Programmer dan tester berat dan kerja keras di akhir-akhir karena waktunya masuk fase construction dan transition. Namun ini semua gimana pintar-pintarnya tim kerja bareng dan rela susah bareng.

Dokumen RUP
Dokumen-dokumen di RUP itu banyak banget. Dokumennya terbagi dalam beberapa kategori. Manajemen bisnis, Kebutuhan, Analisis dan Desain, Implementasi, Testing, Environment, Manajemen Proyek, dan Configuration dan Change Management. Tiap kategori memiliki 1-12 dokumen yang berbeda-beda yang bisa dipakai.

Sebenarnya tujuan dokumen itu baik. Dalam RUP, dokumen itu dimaksudkan untuk menjadi acuan tim/ anggota lain supaya hasil kerja suatu tim itu bisa dimengerti oleh semua anggota proyek. Misalnya kalau tim programmer ingin tahu desain arsitektur yang sudah dibuat tim desainer, dia bisa lihat ke dokumen Software Architechture secara langsung, dsb.

Namun tidak semua dokumen perlu dibuat. Tergantung kebutuhan dan keputusan tim, asalkan mendukung proses pengembangan proyek.

Software Versioning Control
Nah, karena tiap dokumen itu bisa saja berubah karena ada perbaikan dari satu tim, maka perubahan itu harus dicatat (misalnya dalam nomor versi dokumen) agar tim lain mengetahui versi mana yang terbaru dan mana yang kadaluarsa. Perubahan dokumen ini juga harus bisa diakses semua anggota proyek secara cepat, maka dibutuhkan suatu control terhadap versioning software. Versioning ini juga harus menyiasati agar bisa diakses oleh semua anggota di lokasi yang berbeda-beda.

Pengalaman kelompok kami kemarin memakai Google Code sebagai server utama proyek dan memakai Tortoise sebagai client untuk mengambil versi terbaru dari dokumen-dokumen dan kode solution. (Untuk cara pakai Tortoise dengan Google Code bisa dilihat di link ini).

Apa lagi ya
Saya bingung juga ini mau cerita apa lagi, sepertinya banyak banget... Tapi kuliah ini adalah salah satu kuliah yang berkesan karena langsung praktek dan langsung jalan sendiri. Sayang banget kalau ngga diambil.