1 | P a g e
REKAYASA PERANGKAT LUNAK
Oleh : Deci Irmayani
Dosen Prodi Manajemen Informatika, AMIK Labuhanbatu Rantauprapat, Medan;deci_irmayani1@gmail.com
Abstract
Karya ilmiah ini berisi beberapa hal yang perlu dikuasai oleh seorang project Manager untuk dapat menyusun suatu rencana proyek rekayasa perangkat lunak. Tulisan ini juga dilengkapai dengan contoh-contoh dokumen dalam perencanaan proyek rekayasa perangkat lunak.
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, (2) Statement of Work, (3) Resource List, (4) Work Breakdown Structure, (5) Project Schedule dan (6) Risk Plan.
Keyword : rekayasan, perangkat lunak, Software I. PENDAHULUAN
Proyek Software adalah manajemen proyek yang berfokus hanya pada membuat dan mengupdate software. Sifat manajemen proyek haruslah seperti berikut ini:
- Menyelesaikan masalah,
- Mengerjakan sesuai hingga selesai,
- Memiliki batas waktu mulai dan selesainya,
- Membutuhkan resource/sumber daya waktu,
- Bagi beberapa orang merupakan kesempatan / oppurtunity 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. Secara lebih sistematis, tahapan-tahapan proyek dapat tergambarkan sebagai berikut:
Gambar 1. Tahapan-Tahapan Proyek 1. Initiating: proyek sedang dalam proses
untuk dipilih/disetujui, disponsori, didanai, dan diluncurkan,
2. Planning: perencanaan adalah proses yang berulang (perhatikan gambar). Perencanaan pada dasarnya menggambarkan proses bagaimana proyek akan dilaksanakan hingga selesai.
3. Executing: setelah proyek direncanakan, tim proyek memulai pekerjaannya.
4. Controlling: selama tim proyek mengerjakan tugasnya, project manager mengontrolnya.
2 | P a g e 5. 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.
II. URAIAN TEORITIS
2.1. Perangkat Lunak
Software (perangkat lunak), merupakan program-program komputer yang berguna untuk menjalankan suatu pekerjaan sesuai dengan yang dikehendaki. Program tersebut ditulis dengan bahasa khusus yang dimengerti oleh komputer. Software terdiri dari beberapa jenis, yaitu ;
• Sistem Operasi, seperti DOS, Unix, Novell, OS/2, Windows, dll.
Adalah software yang berfungsi untuk mengaktifkan seluruh perangkat yang terpasang pada komputer sehingga masing-masingnya dapat saling berkomunikasi. Tanpa ada sistem operasi maka komputer tak dapat difungsikan sama sekali.
• Program Utility, seperti Norton Utility, Scandisk, PC Tools, dll.
Program utility berfungsi untuk membantu atau mengisi kekurangan/kelemahan dari system operasi, misalnya PC Tools dapat melakukan perintah format sebagaimana DOS, Tapi PC Tools mampu memberikan keterang dan animasi yang bagus dalam proses pemformatan. File yang telah dihapus oleh DOS tidak dapat dikembalikan lagi tapi dengan program bantu hal ini dapat dilakukan.
• Program Aplikasi, seperti GL, MYOB, Payroll, dll.
Merupakan program yang khusus melakukan suatu pekerjaan tertentu, seperti program gaji pada suatu perusahaan. Maka program ini hanya digunakan oleh bagian keuangan saja tidak dapat digunakan oleh departemen yang lain. Biasanya program aplikasi ini dibuat oleh seorang programmer komputer sesuai dengan permintaan/kebutuhan seseorang/lembaga/perusahaan guna keperluan interennya.
• Program Paket, seperti M-Word, MS-Excel, Lotus 125, dan lain-lain.
Adalah program yang disusun sedemikian rupa sehingga dapat digunakan oleh banyak orang dengan berbagai kepentingan. Seperti MS-Word, dapat digunakan oleh departemen keuangan untuk membuat nota, atau bagian administrasi untuk membuat surat penawaran dan lain sebagainya,.
• Bahasa Pemrograman, Pascal, Fortran, Clipper, dBase, dan lain-lain.
Merupakan software yang khusus digunakan untuk membuat program komputer, apakah itu sistem operasi, program paket dll. Bahasa pemrograman ini biasanya dibagi atas 3 tingkatan, yaitu ; 1. Low Level Language, bahasa
pemrograman generasi pertama, bahasa pemrograman jenis ini sangat sulit dimengerti karena instruksinya menggunakan bahasa mesin. Biasanya yang mengerti hanyalah pembuatnya saja.
2. Midle Level Language, merupakan bahasa pemrograman tingkat menegah dimana penggunaan instruksi sudah mendekati bahasa sehari-hari, walaupun begitu masih sulit untuk di mengerti karena banyak menggunakan singkatansingkatan seperti STO artinya simpan (singkatan dari STORE) dan MOV artinya pindah (singkatan dari MOVE). Yang tergolong kedalam bahasa ini adalah Assembler, ForTran (Formula Translator).
3. High Level Language, merupakan bahasa tingkat tinggi yang mempunyai ciri mudah dimengerti, karena menggunakan bahasa sehari-hari, seperti BASIC, COBOL,dBase dan lain-lain.
2.2. Rekayasa Perangkat Lunak
Rekayasa Perangkat Lunak merupakan terjemahan dari terminologi Software Engineering, sedikit mengalami pergerseran makna di relita dunia industri, bisnis, pendidikan maupun kurikulim Teknologi Informasi (TI) di tanah air. Di industri, tester dan programmer sering salah kaprah menyandang gelar Software Engineer. SMK di indonesia juga layah dengan membuka jurusan Rekayasa Perangkat Lunak, meskipun secara kurikulum hanya mengajari bahasa C atau Pascal (mungkin lebih pas disebut jurusan pemrograman komputer) ;) Tulisan ini berusaha menyegarkan kembali pemahaman kita tentang apa
3 | P a g e itu Rekayasa Perangkat Lunak (Software
Engineering) berdasarkan kesepakatan, acuan, dan standart yang ada di dunia internasional.
Sejarah munculnya Rekayasa Perangkat Lunak sebenarnya dilatarbelakangi oleh adanya krisis perangkat lunak (software crisis) di era tahun 1960-an. Krisis perangkat lunak merupakan akibat langsung dari lahirnya komputer generasi ke 3 yang canggih, ditandai dengan penggunaan Integrated Circuit (IC) untuk komputer. Performansi hardware yang meningkat, membuat adanya kebutuhan untuk memproduksi perangkat lunak yang lebih baik.
Akibatnya perangkat lunak yang dihasilkan menjadi beberapa kali lebih besar dan kompleks. Pendekatan informal yang digunakan pada waktu itu dalam pengembangan perangkat lunak, menjadi tidak cukup efektif (secara cost, waktu dan kualitas). Biaya hardware mulai jatuh dan biaya perangkat lunak menjadi naik cepat. Karena itulah muncul pemikiran untuk menggunakan pendekatan engineering yang lebih pasti, efektif, standart dan terukur dalam pengembangan perangkat lunak.
Dari berbagai literatur, kita dapat menyimpulkan bahwa Rekayasa Perangkat Lunak adalah : Suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal requirement capturing (analisa kebutuhan pengguna), specification (menentukan spesifikasi dari kebutuhan pengguna), desain, coding, testing sampai pemeliharaan sistem setelah digunakan.
Kalimat “seluruh aspek produksi perangkat lunak” membawa implikasi bahwa Rekayasa Perangkat Lunak tidak hanya berhubungan dengan masalah teknis pengembangan perangkat lunak tetapi juga kegiatan strategis seperti manajemen proyek perangkat lunak, penentuan metode dan proses pengembangan, serta aspek teoritis, yang kesemuanya untuk mendukung terjadinya produksi perangkat lunak.
Kemudian tidak boleh dilupakan bahwa secara definisi perangkat lunak tidak hanya untuk program komputer,tetapi juga termasuk dokumentasi dan konfigurasi data yang berhubungan yang diperlukan untuk membuat program beroperasi dengan benar. Dengan definisi ini otomatis keluaran (output) produksi perangkat lunak dismping program komputer juga dokumentasi lengkap berhubungan dengannya. Ini yang kadang kurang dipahami oleh pengembang , sehingga menggangap cukup memberikan program yang jalan (running program) ke pengguna (customer).
Rekayasa Perangkat Lunak bukan merupakan cabang ilmu Computer Science yang mempelajari tentang technical coding. Ini yang sering slah kaprah dipahami, sehingga pelajar, mahasiswa atau bahkan calon dosen ;) shock ketika dihadapkan dengan buku-buku textbook Rekayasa Perangkat Lunak yang selalu tebal dengan penjelasan sangat luas tentang bagaimana perangkat lunak diproduksi, dari aspek requirement capturing, desain, arsitektur, testing, kualitas software, sampai people/cost management.
Dan ini adalah suatu kesepakatan yang sudah diterima umum tentang Rekayasa Perangkat Lunak, sejak jaman Roger S Pressman menulis buku “Software Engineering: A Practitioner’s Approch”, sampai Ian Sommerville yang kemudian datang dengan buku “Software Engineering” yang sudah sampai edisi ke 7, maupun pendatang baru semacam Hans Van Vliet, Shari Lawrence Pfleeger maupun James F Peters.
Ada dua cabang ilmu lain yang membahas lebih dalam masalah ini, yaitu: Algoritma dan Struktur Data, dan bahasa pemograman. Computer Science itu juga memiliki definisi, ruang lingkup, klasifikasi dan kategorisasinya. Klasifikasi yang paling terkenal dikeluarkan Task Force yang dibentuk oleh IEEE ( Instituate of Electrical and Electronics Engineers ) dan ACM ( Association for Computing Machinary (http:// acm.org)) yang dipimpin oleh Peter J Denning, yang kemudian terkenal dengan sebutan Matriks Denning. Sangat jelas bahwa Matriks Denning memisahkan antara cabang ilmu Software Engineering dengan Algoritma dan Struktur Data, serta Bahasa Pemograman.
Itulah di paragraf awal disebut bahwa lebih tepat SMK, akademi atau universitas menggunakan nama jurusan ( atau mata kuliah): Pemrograman Komputer, Algoritma dan Struktur Dta atau Bhasa Pemrograman, kalau memang materinya hanya mempelajari masalah bahasa pemrograman scara teknis.
III. PEMBAHASAN
Banyak buku yang bervariasi tentang pemahaman software engineering. Pada tahun tim di tahun 1998 dibentuk tim yang mulai menyusun pemahaman standard (body of knowladge) tentang bidang ilmu Software Engineering, yang kemudian terkenal dengan sebutan SWBOK (Software Engineering Body of Knowledge). Sudah ada dua versi SWEBOK ini, yaitu yang diterbitkan tahun 1999 dan terakhir tahun 2004.
Tiada gading yang tak retak kata orang bijak, project IEEE Computer Society tentang
4 | P a g e SWEBOK ini sebenarnya juga banyak dikritik
oleh pakar yang lain. Paling tidak dua tokoh besar duania Software Engineering yaitu Cem Kaner and Grady Booch tidak terlalu setuju dengan materi yang ada didalam SWEBOK, bahkan menyebutnya sebagai sebuah guide yang misguided ;) Terlepas dari hal itu, boleh dikatakan SWEBOK cukup bisa diterima banyak pihak.
Selain SWEBOK,sebenarnya ada project lain yang mirip dalam usaha menyusun pemahaman standard dalam bidang software Engineering, yaitu CCSE (Computing Curriculum Software Engineering). Project ini juga disponsori oleh IEEE Computer Society dan ACM, hanya orientasinya sedikit berbeda, yaitu untuk membentuk kurikulum standard berhubungan dengan bidang ilmu software Engineering. Hal ini berbeda dengan orientasi SWEBOK yang lebih umum melingkupi dunia akademis dan praktisi.
Perencanaan proyek rekayasa perangkat lunak membahas berbagai tindakan atau pekerjaan yang perlu dilakukan oleh semua yang terlibat didalam proyek, termasuk dokumen-dokumen yang sebaiknya dibuat.
Dokumen Perencanaan Proyek Rekayasa Perangkat Lunak akan terdiri atas sub-sub dokumen berikut ini:
1. Vision and Scope 2. Statement of Work 3. Resource List
4. Work Breakdown Structure 5. Project Schedule
6. Risk Plan
Berikutnya tiap-tiap dokumen tersebut akan dibahas secara lebih terperici.
3.1. Vision and Scope
Dokumen ini adalah hasil kerja pertama dari seseorang 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-dokumen ini dapat dibagi menjadi dua kelpmpok bagian, yaitu:
1. Problem Statement
Bagian problem statement terdiri atas empat sub bab, antara lain:
a. 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 dang mengapa akhirnya diputuskan untuk membangun software yang diproyekkan. b. 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.
c. 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.
d. 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 amupun eksternal.
2. Vision of the Solution
Bagian Vision of the Solution juga akan terdiri atas empat sub bab, yaitu:
a. 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 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
5 | P a g e 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 sama 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/biaya,jika tidak maka akan menyebabkan ketidak adilan bagi tim proyek/pengembang. Begitu juga sebaliknya. Perubahan ruang lingkup mestinya diatur dengan Change Control System.
b. 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 bebrapa 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 sja use case dibuat agar cukup simpel untuk dipahami oleh semua stakeholder. c. 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 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. d. 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. Fitrur-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. 3.2. Statement of the Work
Statement of Work adalah dokumen yang menggambarkan semua produk yang akan dihasilkan selama proyek berjalan dan sia yang akan mengerjakan. Secara lebih detil, di dalam SOW akan dirinci:
Kurang memberikan informasi, maka project manager harus memperbaiki dokumen tersebut.
1. 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:
a. Moderator menjelaskan metode Wideband Delphi,
b. Moderator mereview dokumen Vision and Scope dan dokumen-dokumen pendukungnya, jika ada anggota tim yang belum membacanya,
c. Tim mendiskusikan produk yang akan dibuat dengan berbagai asumsinya, d. Tim membuat 10 hungga 20 pekerjaan
utama sebagai represntasi pekerjaan level tertinggi pada WBS,
e. Tim memdiskusikan estimasi terhadap WBS (jam,minggu, halaman, dll) tersebut hingga mendapatkan kata sepakat.
2. Individual preparationt
Setelah kicoff meeting tiap anggota berusaha mengestimasi tiap-tiap pekerjaan di dalam WBS secara mandiri. Tahapan ini disebut sebai 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.
6 | P a g e Gambar 2. Dokumen individual Preparation
3. Estimation session
Pada rapat ini, anggota tim bersama-sama merevisi estimasi-estimasi yang 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 Estimation Session.
Gambar 3. Estimation Form Berikutnya:
a. Moderator dapat mengumpulkan Estimation Form. Estimasi tersebut kemudian ditabulasikan di papan tulis kemudian ditunjukkan kepada hadiri. Tabulasi tersebut dapat berbentuk seperti berikut:
Gambar 4. Estimasi Awal
Estimasi Form kemudian dikembalikan kepada anggota tim.
b. 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. c. Anggota tim mungkin akan menyampaikan
perbedaan pendapat. Tetapi di dalam rapat ini tidak akan dibahas estimasi individu. Jadi yang mungkin diperdebatkan justru pekerjaannya. Tahap ini mungkin terbagi menjadi dua sesi, sesi pertama 40 menit dan sesi kedua 20 menit.
d. Rapat akan merevisi estimasi individu dengan mengisikan kolom Delta berikutnya pada Form Estimasi 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. Hasilnya akan menghasilkan tabulasi estimasi seperti berikut:
Gambar 5. Estimasi Akhir 4. Review
Project manager akan meringkas, mengkompail kemudian mereview hasil estimasi untuk kemudian digunakan sebagai dasar perencanaan proyek software.
3.3. 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 menggunakan 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:
1. Membuat Work Breakdown Structure 2. Estimasi usaha yang dibutuhkan oleh
setiap pekerjaan pada WBS
3. Project schedule dibuat dengan mengalokasikan resource dan waktu, berdasarkan kalender, untuk tiap pekerjaan pada WBS.
7 | P a g e 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.
3.4. Work Breakdown Structure
Work Breakdown Structure, disingkat WBS, berisi daftar pekerjaan yang jika diselesaikan akan menghasilkan work product. WBS menyebutkan:
1. Apa saja pekerjaan yang akan dilakukan, 2. Tipe-tipe resource yang dibutuhkan untuk
pekerjaan,
3. Estimasi tiap elemen pekerjaan, 4. Identifikasi lokasi penyimpanan.
Tetapi tidak mencantumkan:
1. Siapa yang mengerjakan pekerjaan-pekerjaan itu,
2. Dan kapan pekerjaan itu akan diselesaikan.
3.5. 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:
1. Alokasi resource pada tiapa pekerjaan, Resource bisa berupa berbagai hal seperti manusia, barang, peralatan (komputer, proyektor, dll), tempat (ruang rapat, misalnya) atau layanan (seperti training tau tim pendukung out source) yang dibutuhkan dan mungkin ketersediaannya terbatas. Bagaimana 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.
2. Identifikasikan setiap ketergantungannya, Sebuah pekerjaan disebut memiliki ketergantungan jika melibatkan aktifitas, 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. Berikut ini adalah sedikit gambaran tentang bagaimana suatu pekerjaan menjadi tergantung pada pekerjaan lainnya.
Gambar 6. Pekerjaan Menjadi Tergantung Pada Pekerjaan Lainnya
3. Buat jadwalnya
Tiap pekerjaan juga memiliki jangka waktu pekerjaan. Dengan demikian jadwal bisa dibuat, contoh:
8 | P a g e Gambar 7. Jadwal Kegiatan Pekerjaan
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 wajik menunjukkan summary task atau dua sub pekerjaan yang memiliki induk yang sama.
Jadwal bisa dibuat dalam bentuk Gantt Chart, PERT atau diagram semacamnya.
Contoh Gantt Chart yang dibuat dengan sebuah tool manajemen proyek:
Gambar &. Gantt Chart 3.6. 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 ketikdakpastian.
Langkah-langkah berikut dapat menjadi acuan untuk mendapatkan Risk Plan:
1. Pembahasan resiko potensial
Project manager akan memimpin sebuah sesi/rapat untuk mengidentifikasikan masalah-maslah 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 akhitnya pendapat terakhir diutarakan.
Resiko yang dimaksud disini adalah resiko spesifik. Jika suatu resiko dirasa belum spesifik maka project manager akan memancing agar permasalahan disampaikan secara lebih spesifik. Sumber maslah yang baik lainnya ada asumsi-asumsi yang muncul ketika membuat Vision and scope dan melakukan estimasi dengan metode Wideband Dephi.
2. Estimasi dampat tiap resiko/ masalah
Tim akan memberikan rating untuk setiap resiko. Nilainya berkisar dari 1 (masalah dengan resiko besar, kemugkinan munculnya besar, mungkin menghabiskan biaya besar dan sulit untuk membereskannya).
3. 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.
Contoh sebuah dokumen risk plan:
Gambar 8. Risk Plan IV. PENUTUP
Karya ilmiah ini berisi beberapa hal yang perlu dikuasai oleh seorang project Manager untuk dapat menyusun suatu rencana proyek
9 | P a g e rekayasa perangkat lunak. Tulisan ini juga
dilengkapai dengan contoh-contoh dokumen dalam perencanaan proyek rekayasa perangkat lunak.
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, (2) Statement of Work, (3) Resource List, (4) Work Breakdown Structure, (5) Project Schedule dan (6) Risk Plan.
DAFTAR PUSTAKA
Bertsekas, D.P. dan Tsitsiklis, J.N. --, Parallel and Distributed Computation, Prentis Hall International Inc., New Jersey ,USA. Carmona, E.A. dan Rice, M. D. 1991,
Modeling the Serial and Parallel Fraction of Parallel Algorithm, journal of Parallel and Distributed Computing Volume 1, No. 13 , P.286-298, London. Golub, G.H. dan Loan, C.F.V. 1989, Matrix
Computations, J.H. University Press, London.
Jaja, J. 1992, An Introduction to Parallel Algorithm, Addison-Wesley P.C., Reading
Knob, K. Dkk. 1990, Data Optimization: Allocation of Array to Reduce Communication on SIMD Machine, Journal of Parallel and Distributed Computing Volume --, No. 8 , P.108-118, London.
Saad, Y dan Schuldz, M.H. 1990, Data Communication in Hypercubes , Journal of Parallel and Distributed Computing Volume --, No. 6, P.115-135, London. Schendel, U. 1984, Introduction to Numerical
Methods for Parallel Computer, E.H. Limited, Chichester.
Selim, G.A. 1989, The Design and Analysis of Paralell Algorithm, Prentice Hall International Inc., Canada.
