Definisi RPL dan PL

Apakah PL ?

Dalam organ tubuh manusia terdapat perangkat lunak dan perangkat keras. Biasanya
perangkat lunak pada tubuh manusia dilindungi dengan jaringan perangkat kerasnya. Contoh
otak sebagai perangkat lunak dan dilindungi oleh tulang tengkorak. Hal ini berbeda sama sekali
dengan asumsi bahwa perangkat lunak komputer itu berupa alat yang lunak seperti pada organ
tubuh manusia. Mungkin agar mendekati kesamaan asumsi perangkat lunak komputer, perangkat
lunak manusia mungkin bukan berupa alat/organ atau jaringan tubuh yang sifatnya lunak
melainkan sinyal sensorik dan motorik yang menggerakkan atau memberikan perintah pada
organ melalui jaringan syaraf yang saliang berkoordinasi dan berhubungan dengan baik. Berikut
rangkuman hal-hal yang berkaitan dengan apa yang disebut dengan perangkat lunak komputer;

 Program komputer & dokumentasi yang berkaitan seperti dokumen kebutuhan,rancangan,

dan user manual.
 Produk PL bisa dibangun untuk pengguna khusus atau umum.
 PC seperti Excel atau Word. Generic dibangun untuk dijual ke pengguna yang
berbeda-beda misalnya PL untuk
  Bespoke (custom) untuk pengguna khusus/pemesan sesuai kebutuhannya.
 PL baru bisa dibuat dengan membangun program baru, konfigurasi sistem PL atau
gunakan lagi (reuse) program yang sudah ada.

Perangkat lunak merupakan program komputer yang mengkoordinasikan (mengenalkan,

memiliki fungsi pengaturan dan pengontrolan) unjuk kerja perangkat keras dan dokumentasi
yang berkaitan seperti dokumen kebutuhan, rancangan dan petunjuk pemakaiannya. Sedangkan
Rekayasa Perangkat Lunak adalah disiplin ilmu rekayasa atau teknik yang berkaitan dengan
semua aspek dalam membuat perangkat lunak yang mengharuskan mengikuti pendekatan yang
sistematis dan teratur dan menggunakan alat dan teknik yang cocok sesuai dengan masalah yang
akan dipecahkan, batasan pembangunan dan sesumber yang tersedia.

Beda RPL Dengan Istilah-Istilah lain

Beda RPL dan Ilmu Komputer

 Ilmu komputer berkaitan dengan teori dan konsep-konsep dasar; RPL berkaitan dengan
praktek pembangunan PL.
 Teori ilmu komputer masih kurang sebagai penyangga RPL.

Beda RPL dan Rekayasa Sistem

 Rekayasa sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis
komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa
sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database
pada sistem.
  Para ahli sistem (system engineers) terlibat dalam spesifikasi sistem, desain arsitektural,
integrasi dan peluncurannya.

Posted by Rekayasa Perangkat Lunak at 6:27 PM 0 comments

Definisi Sedernaha

Software engineering didefinisikan oleh Fritz Bauer sebagai: penerapan dan penggunaan prinsip-
prinsip engineering yang baik dalam rangka menghasilkan software yang ekonomis, reliable, dan
bekerja secara efisien pada komputer sungguhan. Software engineering is the establishment and
use of sound engineering principles in order to obtain economically software that is reliable and
works efficiently on real machines.

Sementara itu IEEE mendefinisikan software engineering sebagai: (1) The application of a
systematic, disciplined, quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software. (2) The study of approaches in (1)
Posted by Rekayasa Perangkat Lunak at 6:19 PM 0 comments
Labels: Konsep Dasar

Pentingnya Rekayasa Perangkat Lunak (RPL) dan Perangkat Lunak (PL)

Berbagai instansi pemerintah maupun swasta, baik dalam maupun luar negeri menggunakan
perangkat lunak (software) sebagai kebutuhan esensial. PL digunakan dari berbagai tingkatan
manajemen. Terdapat tingkatan manajemen tertentu yang bertugas untuk mengembangkan atau
bahkan membuat perangkat lunak (software engineering). Bahkan saat ini banyak
instansi/perusahaan tersebut yang dengan sengaja menciptakan departemen/bagian yang
mengurusi perangkat lunak atau rekayasa perangkat lunak.

Berikut ini adalah pentingnya RPL dan PL;

 Semua negara maju ekonominya bergantung pada perangkat lunak.

 Makin banyak sistem yang dikendalikan oleh PL
 RPL berkaitan dengan teori, metode dan alat untuk pembangunan PL secara rofesional.
 Pengeluaran dana untuk PL di negara maju sangat besar.
 Harga PL sering lebih mendominasi harga sistem komputer. Harga PL pada PC sering
lebih mahal dari pada harga perangkat kerasnya.
 Biaya pemeliharaan PL lebih mahal dibanding biaya pembuatannya.
 RPL berkaitan dengan biaya efektif pembuatan PL.

Dari poin-poin di atas, peninjauan pengadaan PL dan pengembangan PL ternyata menimbulkan

komponen biaya yang tidak sedikit. Hal ini cukup beralasan, karena dengan PL yang dimilikinya
pihak manajemen dapat membuat keputusan berdasarkan data yang disediakan oleh PL dengan
akurat, cepat, efisien dan dapat menyesuaikan kondisi saat ini (relevan).

Posted by Rekayasa Perangkat Lunak at 6:38 AM 0 comments

Perangkat Lunak

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:

 Menyelesaikan 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. Secara lebih sistematis, tahapan-tahapan proyek dapat
tergambarkan sebagai berikut:

Figure 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.
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.

Tujuan Perencanaan Proyek

Perencanaan proyek Rekayasa Perangkat Lunak dari berbagai sudut pandang kurang lebih
memiliki tujuan sebagai berikut:
1. Bagi Project Manager:
a. untuk menggambarkan status proyek kepada manajer senior dan stakeholder,
b. untuk merencanakan aktivitas tim proyek.
2. Bagi anggota Tim Proyek: untuk memahami konteks pekerjaan.
3. Bagi Manajer Senior:
a. untuk memastikan apakah biaya dan waktu yang dialokasikan masuk akal dan terkendali,
b. untuk melihat apakah proyek dilaksanakan secara efisien dan cost effective.
4. Bagi Stakeholder:
a. untuk memastikan apakah proyek masih berada pada jalurnya,
b. 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:
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 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:

1. 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.

1. 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:

1. Daftar fitur yang akan dibuat; jika software akan dirilis dalam fase-fase, maka fiturnya
juga harus dibagi ke dalam fase-fase tersebut.
2. Deskripsi hasil kerja (work product: spesifikasi kebutuhan, source code, test plan, laporan
defect, dll) yang akan dibuat.
3. 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:

1. 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.
 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 hingga 20 pekerjaan utama sebagai representasi pekerjaan level tertinggi
pada WBS,
e. Tim mendiskusikan estimasi terhadap WBS (jam, minggu, halaman, dll) tersebut hingga
mendapatkan kata sepakat.
3. 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.

Figure 2 Dokumen Individual Preparation

4. 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.

Figure 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:

Figure 4 Estimasi awal

Estimation 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 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.
d. 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. Hasilnya akan
menghasilkan tabulasi estimasi seperti berikut:

Figure 5 Estimasi akhir

5. 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:
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.

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:
1. Apa saja pekerjaan yang akan dilakukan,
2. Tipe-tipe resource yang dibutuhkan untuk bekerja,
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.
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 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.
2. 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. Berikut ini adalah sedikit gambaran tentang bagaimana suatu pekerjaan
menjadi tergantung pada pekerjaan lainnya.

3. Buat jadwalnya
Tiap pekerjaan juga memiliki jangka waktu pekerjaan. Dengan demikian jadwal bisa dibuat,
contoh:

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.
Jadwal bisa dibuat dalam bentuk Gantt Chart, PERT atau diagram semacamnya.
Contoh Gantt Chart yang dibuat dengan sebuah tool manajemen proyek:

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:

1. 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.
2. 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).
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:

Figure 6 Risk Plan

Referensi
Banyak bagian dari tulisan ini disarikan dari web site [Link]. Beberapa point
diambil dari Software Project Management for Dummies yang ditulis oleh Teresa Luckey dan
Joseph Philips.
Biografi Penulis
Amri Shodiq. Lulus dari program Diploma 3 Akademi Sandi Negara pda tahun 2001. Kemudian
melanjutkan studi pada jurusan Sistem Informasi STMIK Jakarta STI&K hingga lulus tahun
2006. Saat ini bekerja sebagai staff Unit Laboratorium merangkap staff pengajar di Sekolah
Tinggi Sandi Negara.