10.1.

Strategi Resiko Reaktif vs Proaktif

Strategi reaksi reaktif secara menggelikan disebut “sekolah manajemen resiko Indiana Jones”.
Pada film tersebut, Indiana Jones, pada saat dihadapkan dengan bermacam-macam kesulitan
akan tetap mengatakan, “jangan khawatir, aku akan memikirkan sesuatu!” Tidak pernah
mengkhawatirkan masalah sampai mereka benar-benar terjadi, di mana Indi akan beraksi secara
heroik.

Sayangnya, rata-rata manajer proyek tidak seperti Indiana Jones. Mayoritas tim perangkat lunak
hanya bersandar pada strategi reaktif. Pada titik terbaik, strategi reaktif memonitor proyek
terhadap kemungkinan resiko.

Strategi yang benar-benar lebih baik untuk manajemen resiko adalah bersikap proaktif. Strategi
proaktif dimulai lama sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas
dan pengaruh proyek diperkirakan, dan dirioritaskan menurut kepentingan. Tim perangkat lunak
kemudian membangun suatu rencana untuk manajemen resiko. Sasarannya adalah menghindari
resiko.Terdapat dua cara para software engineer menangani resiko, yaitu software
engineer  yang reaktif selalu memperbaiki masalah saat masalah tersebut muncul, dan software
engineer  proaktif yang selalu memikirkan kemungkinan resiko yang dapat terjadi pada suatu
proyek sebelum resiko-resiko tersebut muncul. Beberapa tipe resiko yang dapat muncul selama
proyek pengembangan perangkat lunak seperti yang dapat dilihat pada tabel 1, yaitu :

Tabel 1 Tipe-tipe Resiko

Selain tipe-tipe resiko di atas, terdapat juga resiko khusus berkaitan dengan anggota tim,
konsumen, tool, teknologi, estimasi waktu, serta ukuran tim. Banyak dari resiko ini dapat
diminimasi dengan menggunakan metodologi pengembangan pada proyek. Terdapat
banyak tool yang dapat digunakan untuk menganalisa resiko yang akan muncul pada proyek,
dapat dipilih tool yang terbaik untuk dapat meminimasi atau mengeliminasi resiko.

10.2. Resiko Perangkat Lunak

Resiko selalu melibatkan dua karakteristik :

o Ketidakpastian – kejadian yang menandai resiko mungkin atau tidak mungkin

terjadi;
o Rugi – bila resiko menjadi realitas, akibat yang tidak diinginkan atau kerugian
akan dialami.

Resiko proyek mengancam rencana proyek. Yaitu, bila resiko proyek menjadi nyata, ada
kemungkinan jadwal proyek akan mengalami slip dan bahwa biaya menjadi bertambah. Resiko
proyek mengidentifikasi hal potensial yang berhubungan dengan pembiayaan, jadwal, personil
(staffing dan organisasi), sumber-sumber daya, pelanggan dan masalah persyaratan serta
pengaruhnya terhadap proyek perangkat lunak. Resiko teknis mengancam kualitas dan ketepatan
waktu perangkat lunak yang akan dihasilkan. Resiko teknis mengidentifikasi desain potensial,
implementasi, interfacing, verifikasi dan masalah pemeliharaan. Ambiguitas, spesifikasi,
ketidakpastian teknik, keusangan teknik, dan teknologi yang leading edge juga merupakan faktor
resiko. Resiko bisnis mengancam viabilitas perangkat lunak yang akan dibangun. Kandidat untuk
lima resiko bisnis utama adalah :

1. Pembangunan produk atau sistem yang baik sekali yang sebenarnya tidak pernah
diinginkan oleh setiap orang (resiko pasar);
2. Pembangun sebuah produk yang tidak lagi sesuai dengan keseluruhan strategis bisnis
bagi perusahaan (resiko strategis);
3. Pembangunan sebuah produk di mana bagian pemasaran tidak tahu bagaimana harus
menjualnya;
4. Kehilangan dukungan manajemen senior sehubungan dengan perubahan pada fokus atau
perubahan pada manusia (resiko manajemen);
5. Kehilangan hal-hal yang berhubungan dengan biaya atau komitmen personal (resiko
biaya).

Kategori resiko umum lainnya telah diusulkan oleh Charette yaitu :

 Resiko yang sudah diketahui adalah resiko yang dapat diungkap setalh dilakukan evaluasi
secara hati-hati terhadap rencana proyek, bisnis, dan lingkungan teknik di mana proyek
sedang dikembangkan, dan sumber informasi reliabel lainnya (seperti tanggal
 penyampaian yang tidak realistis, kurangnya persyaratan yang terdokumentasi atau ruang
lingkup perangkat lunak, lingkungan pengembangan yang buruk).

 Resiko yang dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya

(misalnya, pergantian staf, komunikasi yang buruk dengan para pelanggan, mengurangi
usaha staf bila permintaan pemeliharaan yang sedang berlangsung dilayani). Resiko yang
tidak diharapkan dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi
sebelumnya.

10.3. Identifikasi Resiko

Identifikasi resiko adalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek
(perkiraan, jadwal, pemuatan sumber daya, dll). Ada dua tipe resiko yang berbeda : resiko
generik dan resiko produk spesifik.. Resiko generik merupakan ancaman potensial pada setiap
proyek perangkat lunak. Resiko produk spesifik hanya dapat diidentifikasi oleh mereka dengan
pemahaman khusus mengenai teknologi tsb, manusia, serta lingkungan yang spesifik terhadap
proyek yang ada.

Tom Gilb menyatakan: “Bila anda tidak aktif menyerang resiko, maka resiko akan aktif
menyerang anda.” Metode untuk mengidentifikasi resiko adalah menciptakan cheklist item
resiko. Checklist dapat digunakan pada identifikasi resiko dan berfokus pada beberapa himpunan
bagian resiko yang sudah diketahui dan diprediksi dalam sub kategori berikut ini :

 Ukuran produk – resiko sehubungan dengan keseluruhan ukuran perangkat lunak yang
akan dibangun atau dimodifikasi.
 Pengaruh bisnis – resiko sehubungan dengan batasan yang dibebankan oleh manajemen
atau pasar.
 Karakteristik pelanggan – resiko sehubungan dengan kepintaran pelanggan dan
kemampuan pengembang untuk berkomunikasi dengan pelangan dengan cara yang tepat.
 Definisi proses – resiko sehubungan dengan tingkat di mana proses perangkat lunak telah
didefinisikan dan diikuti oleh organisasi pengembangan.
 Lingkungan pengembang – resiko sehubungan dengan keberadaan dan kualitas peranti
yang akan digunakan untuk membangun produk.
 Teknologi yang akan dibangun – resiko sehubungan dengan kompleksitas sistem yang
akan dibangun dan “kebaruan” teknologi yang dikemas oleh sistem.
 Ukuran dan pengalaman staf – resiko sehubungan dengan keseluruhan teknik dan
pengalaman proyek dari rekayasa perangkat lunak yang akan melakukan tugas tersebut.

10.3.1. Resiko Ukuran Produk

Checklist item resiko berikut mengidentifikasi resiko generik yang berhubungan dengan ukuran
produk (perangkat lunak) :

 Berapa ukuran produk diperkirakan dalam LOC atau FP?

 Ukuran produk yang diestimasi dalam jumlah program, file, transaksi?
 Ukuran database yang dibuat atau digunakan oleh produk?
 Jumlah pemakai produk?
 Jumlah perangkat lunak yang dipergunakan kembali?

10.3.2. Resiko-resiko yang mempengaruhi bisnis

Checklist item resiko berikut mengidentifikasi resiko generik yang berhubungan dengan
pengaruh bisnis:

 Pengaruh produk terhadap hasil perusahaan?

 Kelayakan deadline penyampaian?
 Jumlah pelanggan yang akan menggunakan produk dan konsistensi
kebutuhan relatif mereka dengan produk tersebut?
 Kepintaran pemakai akhir?
 Biaya yang berhubungan dengan penyampaian yang terlambat?

10.3.3. Resiko-resiko yang dihubungkan dengan pelanggan

Semua pelanggan tidak diciptakan sama. Pressman dan Herron membahas masalah ini dengan
menyatakan :

o Pelanggan mempunyai keinginan yang berbeda.

o Pelanggan memiliki kepribadian yang berbeda.
o Pelanggan juga memiliki hubungan yang bervariasi dengan pemasok mereka.
o Pelanggan juga kadang-kadang bertentangan.

Checklist item resiko berikut mengidentifikasi resiko generik yang berhubungan dengan para
pelanggan yang berbeda:

o Pernahkah anda sebelumnya bekerja dengan pelanggan?

o Apakah pelanggan memilki gagasan yang solid mengenai apa yang
diperlukannya? Sudahkan pelanggan menggunakan waktunya untuk
menuliskannya?
o Apakah pelanggan bersedia membangun sambungan komunikasi cepat dengan
pengembang?
o Apakah pelanggan bersedia berpartisipasi dalam kajian?
o Apakah pelanggan memahami proses perangkat lunak tersebut?

10.3.4. Resiko Proses

Contoh resiko yang berhubungan dengan masalah-masalah proses :

o Apakah manajemen senior anda mendukung suatu pernyataan kebijakan yang

menekankan pentingnya suatu prses standar untuk pengembangan proses?
o Sudahkan organisasi anda mengembangkan suatu deskripsi tertulis mengenai
proses perangkat lunak yang akan digunakan pada proyek ini?
o Apakah anggota-anggota staf “ditugasi” ke proses perangkat lunak pada saat
perangkat lunak didokumentasi dan bersedia menggunakannya?
o Apakah proses perangkat lunak digunakan untuk proyek lain?
o Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain dan kode
dilakukan secara reguler?

Contoh resiko yang berhubungan dengan masalah-masalah teknis :

o Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi di

antara pelanggan dan pengembang?
o Apakah metode spesifikasi digunakan untuk analisis perangkat lunak?
o Apakah anda melihat suatu metode spesifik untuk data dan desain arsitektur?
o Apakah digunakan peranti perangkat lunak untuk mendukung perencanaan dan
aktivitas penelusuran?
o Apakah metrik kualitas dikumpulkan bagi semua proyek perangkat lunak?

10.3.5. Resiko Teknologi

Checklist item resiko berikut mengidentifikasi resiko generik yang berhubungan dengan
teknologi yang akan dibangun:

o Apakah teknologi yang akan dibangun adalah hal yang baru untuk organisasi
anda?
o Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi
input atau output?
o Apakah perangkat lunak ber-interface dengan perangkat keras baru atau belum
terbukti?
o Apakah perangkat lunak yang akan dibangun ber-interface dengan produk
perangkat lunak yang dipasok oleh vendor yang belum terbukti?
o Apakah perangkat lunak yang akan dibangun ber-interface dengan suatu sistem
database yang fungsi dan kinerjanya belum dibuktikan di dalam area aplikasi ini?

10.3.6. Resiko Lingkungan Pengembang

Checklist item resiko berikut mengidentifikasi resiko generik yang berhubungan dengan
lingkungan pengembang:
 o Apakah peranti manajemen proyek dapat diperoleh?
o Apakah peranti manajemen proses dapat diperoleh
o Apakah peranti untuk analisis dan desain dapat diperoleh?
o Apakah kompiler atau pembangkit kode dapat diperoleh dan sesuai untuk produk
yang akan dibangun?
o Sudahkan anggota tim proyek menerima pelatihan dengan masing-masing
peranti?

10.3.7. Resiko Yang Berhubungan Dengan Ukuran Staf Dan Pengalaman

Checklist item resiko berikut mengidentifikasi resiko generik yang berhubungan dengan ukuran
staf dan pengalaman (diusulkan Boehm):

 Apakah orang-orang terbaik dapat didapatkan?

 Apakah orang-orang tsb memiliki gabungan ketrampilan yang benar?
 Apakah orang-orang yang ada mencukupi?
 Akankah banyak staf proyek bekerja dalam paruh waktu pada proyek ini?
 Sudahkan staf menerima pelatihan yang memadai?

10.3.8. Komponen resiko dan driver

Komponen resiko didefinisikan dengan cara berikut :

 Resiko kinerja – tingkat ketidakpastian di mana produk akan memenuhi

persyaratannya dan cocok dengan penggunaannya.
 Resiko biaya – tingkat ketidakpastian di mana biaya proyek akan dijaga.
 Resiko dukungan – tingkat ketidakpastian di mana perangkat lunak akan
mudah dikoreksi, disesuaikan dan ditingkatkan.
 Resiko jadwal – tingkat ketidakpastian di mana jadwal proyek akan dijaga
dan produk akan disampaikan tepat waktu.

Pengaruh driver resiko terhadap komponen resiko dibagi ke dalam satu dari empat kategori
pengaruh – diabaikan, marjinal, kritis dan katastropis.

10. 4. Proyeksi Resiko

Proyeksi resiko yang disebut juga perkiraan resiko, berusaha menjangkau setiap resiko dalam
dua cara – kemungkinan atau probabilitas di mana resiko adalah nyata dan konsekuensi masalah
yang berhubungan dengan resiko, yang harus terjadi. Perencana proyek bersama dengan manajer
dan staf teknik lain, melakukan empat aktivitas proyeksi resiko :

 membangun suatu skala yang merefleksikan kemungkinan resiko yang

dirasakan;
 menggambarkan konsekuensi resiko
 memperkirakan pengaruh resiko pada proyek dan produk
  mencatat keseluruhan akurasi proyeksi resiko sehingga tidak akan ada
kesalahpahaman.

10.4.1. Mengembangkan tabel resiko

Tabel resiko memberi manajer proyek sebuah teknik sederhana bagi proyeksi resiko. Tabel
resiko sampel ditunjukkan pada tabel berikut.

Tabel  Contoh tabel resiko terhadap kategori, probabilitas dan pengaruh resiko

Keterangan tabel ;

Katogori Risiko :

o PS : Ukuran Produk
 o TE : Teknologi
o BU : Bisnis
o DE : Lingkungan Pengembangan
o CU : Proses
o ST : Ukuran Staf & Pengalaman

Nilai Pengaruh :

 1 – Katastropis        
 2 – Kritis       
 3 – Marjinal              
 4 – Dapat Diabaikan

Begitu empat kolom yang pertama dari tabel resiko telah diselesaikan maka tabel itu diurutkan
sesuai probabilitas dan pengaruhnya. Probabilitas yang tinggi, resiko pengaruh yang tinggi
menapis ke puncak tabel, dan resiko probabilitas rendah jatuh ke dasar. Dengan demikian
prioritasisasi resiko urutan pertama dapat diselesaikan.

Driver resiko dapat diperkirakan pada skala probabilitas kualitatif yang memiliki nilai sebagai
berikut : impossible, improbable, probable, dan frekuen. Probabilitas matematis kemudian dapat
dikaitkan dengan masing-masing nilai kualitatif (misalnya, suatu probabilitas 0,7 sampai 1,0
implikasikan resiko yang sangat mungkin).

10.4.2. Menilai pengaruh resiko

Ada tiga faktor yang kemungkinan besar mempengaruhi konsekuensi jika suatu resiko benar-
benar terjadi : sifatnya, ruang lingkupnya, dan timingnya. Sifat dari resiko menunjukkan masalah
yang mungkin muncul bila ia terjadi. Ruang lingkup dari suatu resiko menggabungkan
kepelikannya (seberapa serius hal ini?) dengan keseluruhan distribusi (berapa banyak proyek
akan dipengaruhi atau berapa banyak pelanggan yang akan terganggu?). Akhirnya, timing dari
suatu resiko mempertimbangkan kapan dan untuk berapa lama pengaruh itu akan dirasakan.

Langkah-langkah berikut ini direkomendasikan untuk menentukan konsekuensi keseluruhan dari

suatu resiko :

o Tentukan probabilitas rata-rata dari nilai kejadian untuk masing-masing

komponen resiko.
o Dengan menggunakan tabel 2, tentukan pengaruh untuk masing-masing
komponen berdasarkan kriteria yang diperlihatkan.
o Lengkapi tabel resiko dan analisis hasilnya .
10.4.3. Penilaian Resiko

Agar penilaian bermanfaat, tingkat referens resiko harus ditentukan. Untuk sebagian besar
proyek perangkat lunak, komponen resiko yang dibicarakan sebelumnya – kinerja, biaya,
dukungan dan jadwal – juga mencerminkan tingkat referensi resiko. Tingkat referens resiko
adalah tingkat degradasi kinerja, pembengkakan biaya, kesulitan dukungan, dan
melesetnyajadwal, yang akan menyebabkan proyek diterminasi.Jika kombinasi resiko
menciptakan masalah yang menyebabkan satu atau lebih dari tingkat referen itu terlampaui, kerja
akan terhenti. Dalam konteks analisis resiko perangkat lunak, tingkat referen resiko memilki titik
tunggal, yang disebut referent point atau break point, di mana keputusan untuk meneruskan
proyek atau menghentikannya sama-sama dapat diterima.

Selama penilaian resiko, kita melakukan langkah-langkah berikut : 

1. Tentukan tingkat referen resiko untuk proyek.

2. Usahakan untuk mengembangkan hubungan antara masing-masing[ri, li, xi] dan
masing-masing tingkat referen.
3. Prediksikan himpunan titik referen yang menentukan daerah terminasi, dibatasi
oleh kurva atau area ketidakpastian.
4. Cobalah memprediksi bagaimana penggabungan kombinasi resiko akan
mempengaruhi suatu titik referen.

10.5. Pengurangan, Monitoring, Dan Manajemen Resiko

Semua aktivitas analisis resiko yang disajikan pada titik ini memiliki satu tujuan tunggal –
membantu tim proyek dalam mengembangkan strategi yang berkaitan dengan resiko. Strategi
yang efektif harus memiliki tiga gagasan berikut :

 Menghindari resiko
 Monitoring resiko
 Manajemen resiko dan perencanaan kemungkinan

Pada saat proyek berjalan, aktivitas pemonitoran resiko dimulai. Manajer proyek memonitor
faktor-faktor yang dapat memberikan suatu indikasi apakah resiko sedang menjadi lebih atau
kurang mungkin. Dalam kasus turnover staf tinggi, faktor-faktor berikut dapat dimonitor :

o Sikap umum anggota tim berdasarkan tekanan proyek.

o Tingkat di mana tim disatu-padukan.
o Hubungan interpersonal di antara anggota tim.
o Masalah potensial dengan kompensasi dan manfaat.
o Keberadaan pekerjaan di dalam perusahaan dan di luarnya.

10.6. RMMM Plan

Strategi manajemen resiko dapat dimasukkan dalam rencana proyek perangkat lunak; atau,
langkah manajemen resiko dapat diatur ke dalam Risk Mitigating, monitoring, and Management
Plan (RMMM Plan) yang terpisah. RMMM Plan mendokumentasi semua kegiatan yang
dilakukan sebagai bagian dari analisis resiko dan digunakan oleh manajer proyek sebagai bagian
dari keseluruhan Rencana Proyek. Uraian untuk RMMM Plan (model) adalah sebagai berikut:

I.   Pengantar

1. Lingkup dan tujuan dokumen

2. Tinjauan resiko utama
3. Tanggung jawab : Manajemen, Staf teknis

II.   Tabel Resiko Proyek

1. Deskripsi semua resiko di atas yang ditentukan

2. Faktor-faktor yang mempengaruhi probabilitas dan pengaruh

III.  Pengurangan, Monitoring, dan Manajemen Resiko

1. Resiko
2. Pengurangan : Strategi umum, Langkah khusus untuk mengurangi resiko
3. Monitoring : Faktor-faktor yang dimonitor, Pendekatan monitoring
4. Manajemen : Rencana kontingensi, Konsiderasi khusus

IV.  Jadwal Iterasi Rencana RMMM

V.    Kesimpulan