Manajemen Resiko Software Engineering

“Manajemen Resiko Software Engineering”
Tanti Kristanti
“Manajemen Resiko Software Engineering”
Tanti Kristanti
e-mail: [email protected]
Abstraksi
Kesuksesan pengembangan perangkat lunak bukan hanya didasarkan pada
metoda dan tool yang digunakan, namun ternyata perlu adanya manajemen resiko
dalam pengembangannya. Manajemen resiko penting untuk industri perangkat
lunak guna mengurangi faktor-faktor yang mengejutkan karena ketidakpastian
mengenai apa yang akan terjadi pada masa mendatang. Diharapkan dengan
mengaplikasikan manajemen resiko terstruktur, dapat mewaspadai dan mengambil
aksi untuk meminimasi akibat dari potensi masalah. Resiko tidak hanya
diidentifikasi
secara sederhana namun
perlu
dokumentasi
resiko
guna
memudahkan komunikasi pada komunitas project stakeholder selama proyek
berjalan.
Para pengembang perangkat lunak selama ini merasa telah mengetahui
banyak hal mengenai apa yang harus dikerjakannya terkait dengan perangkat
lunak, mengetahui benar siapa user yang menggunakan produk atau layanan yang
disediakannya, mengetahui apa yang diperlukan oleh user, dan tidak pernah
menyadari adanya hal-hal tak terduga yang mungkin terjadi seperti turn over
pegawai, atau masalah teknis lain yang tiba-tiba muncul. Manajemen resiko dapat
mengatasi hal-hal yang tidak terduga yang akan mengakibatkan kegagalan proyek
pengembangan perangkat lunak.
Keywords : manajemen resiko, rekayasa perangkat lunak
1. Pendahuluan
Terdapat permasalahan dalam pengembangan software dalam kurun waktu
20 tahun terakhir ini, dimana biaya pengembangan software telah melampaui
biaya pengembangan hardware. Lebih dari 90% biaya sistem berbasis komputer
terkait dengan permasalahan software termasuk biaya pengembangan dan
perawatan (maintenance).
1
“Manajemen Resiko Software Engineering”
Tanti Kristanti
Telah diakui bahwa software memberikan manfaat ekonomis dan fungsional
bagi perusahaan, namun pengembangannya sering dianggap sebagai usaha dengan
resiko tinggi. Adanya persepsi bahwa keterlambatan pengembangan software
seringkali dikaitkan dengan masalah teknologi (seperti kompleksnya algoritma)
namun hal tersebut telah dibantah dengan bukti bahwa 45% dari keterlambatan
proyek dikarenakan permasalahan organisasi yang sebenarnya dapat dikontrol
manajemen.
Dari sudut pandang bisnis, kriteria kesuksesan pengembangan software
diukur melalui Return on Investment (ROI), time to market serta customer
satisfaction. Sedangkan dari sudut pandang teknologi, kriteria kesuksesan diukur
dari pemenuhan functional requirement, product usability dan future support.
Penelitian yang dilakukan US General Accounting Office menunjukkan bahwa
pengembangan software dan manajemen resiko dengan kriteria kesuksesan (dari
sudut pandang bisnis dan teknologi) ternyata tidak memberikan hasil yang
mengesankan. Dari survey, diperoleh informasi bahwa dari sejumlah vendor
penyuplai software untuk US Government, 50.4% mengindikasikan adanya cost
overrun dan 62% mengalami schedule overrun saat mengembangkan sistem.
Penelitian serupa dilakukan di United Kingdom yang melibatkan 60 perusahaan
dengan 200 proyek software mengindikasi adanya 55% cost overrun dan 66%
schedule overrun. (Karolak, 1996) 6)
Terdapat banyak permasalahan seputar software management yang dapat
mengakibatkan late deliveries, budget overages serta adanya error/kesalahan dan
performansi teknis yang tidak sesuai dengan harapan. Permasalahan-permasalahan
tersebut dapat
dilihat dari sudut pandang industri (industrial viewpoint) dan
praktisi (practitioner viewpoint) yang terlibat didalamnya. Berikut ini uraian
masalah-masalah utama yang sering terjadi :
1. Dari sudut pandang industri (industrial viewpoint)
a. Persepsi bahwa produksi software bukanlah usaha pengembangan yang
besar.
Sebagaimana telah disebutkan pada uraian sebelumnya bahwa 90% biaya
sistem komputer berasal dari software. Pada umumnya perusahaan
pengembang terutama pengembang software yang menyertakan atau
2
“Manajemen Resiko Software Engineering”
Tanti Kristanti
menggabungkan produknya dalam hardware, hanya menilai biaya proyek
dari sisi hardware yang dihasilkannya saja, tanpa memperhatikan adanya
biaya software. Hal ini terjadi karena Work Breakdown Structure (WBS)
tidak diorganisasikan untuk mengidentifikasi pengembangan software
sebagai item yang terpisah.
b. Meskipun telah dirasakan bahwa disiplin Software Engineering (SE) telah
memberikan banyak manfaat (semenjak dicetuskan tahun 1968), namun
masih terdapat persepsi bahwa software merupakan usaha keras yang
kreatif, yang tidak dapat direkayasa (engineer) seperti disiplin ilmu
lainnya.
c. Persepsi bahwa meskipun disadari pengembangan software memiliki
resiko, namun kita tidak dapat melakukan apapun untuk mengontrol resiko
tersebut. Sejarah menunjukkan bahwa umumnya pengembang software
selalu mengalami keterlambatan jadwal, over budget dan memiliki
performansi teknis yang buruk.
2. Dari sudut pandang praktisi (practitioner viewpoint)
a. Kurangnya pemahaman/edukasi mengenai apa yang terlibat dalam
manajemen software.
Konsep manajemen pengembangan software beserta resikonya tidak
diberikan dalam sistem pendidikan kita di universitas-universitas dan
bahkan jarang diadakan dalam seminar atau
manajemen hanya ditemui
pada program
pelatihan.
bisnis
Konsep
yang biasanya
mengemukakan konsep resiko yang berkaitan dengan investasi.
b. Kurangnya disiplin ilmu untuk mengimplementasikan teknik manajemen
yang baik.
Meskipun seseorang memiliki ilmu mengenai manajemen software dan
teknik manajemen resiko yang baik, namun tetap memerlukan disiplin
ilmu
lain
untuk
mengidentifikasi,
mengkalkulasi,
menentukan,
merencanakan, mengumpulkan serta melaporkan resiko software.
c. Kurangnya tool untuk melakukan manajemen resiko software
3
“Manajemen Resiko Software Engineering”
Tanti Kristanti
Meskipun telah banya tool manajemen proyek untuk software, namun
tidak mudah mendapatkan tool untuk manajemen resiko software.
d. Adanya pandangan sempit mengenai manajemen resiko software serta
kegagalan mengintegrasikan manajemen software yang mengandung
resiko.
Manajemen resiko software harus dilihat secara keseluruhan melalui
semua tahapan Siklus Hidup
Pengembangan
Sistem
(Software
Development Life Cycle).
Terdapat 2 perspektif dari para software engineer terhadap pengembangan
perangkat lunak :
1. Jika sudah merencanakan suatu proyek perangkat lunak, diasumsikan bahwa
semua telah berjalan sesuai dengan rencana.
2. Pengembangan perangkat lunak yang alamiah berarti bahwa tidak pernah
dapat memprediksi secara akurat apa yang akan terjadi, jadi untuk apa
diperlukan perencanaan ?
Kedua perspektif tersebut dapat mengarah pada adanya kejadian-kejadian di luar
dugaan yang dapat membawa proyek keluar dari jalur.
Manajemen resiko menjadi penting untuk industri perangkat lunak untuk
mengurangi surprise factor. Karena ketidakpastian mengenai apa yang akan
terjadi pada masa mendatang, diharapkan dengan mengaplikasikan manajemen
resiko terstruktur, dapat mewaspadai dan mengambil aksi untuk meminimasi
akibat dari potensi masalah, karena resiko manajemen berarti berkaitan dengan
perhatian terhadap sesuatu sebelum menjadi krisis.
Gejala suatu perusahaan yang tidak menerapkan manajemen resiko secara
efektif adalah adanya ketidakstabilan proyek yang berkesinambungan, jadwal
yang selalu meleset karena surprise factor yang terulang, operasi yang selalu
dalam kondisi high-stress, krisis peran manajemen. Resiko manajemen
meningkatkan kesuksesan penyelesaian proyek, dan mengurangi konsekuensi
potensi negatif dari resiko-resiko yang tidak dapat dihindari.
4
“Manajemen Resiko Software Engineering”
Tanti Kristanti
2. Pengertian Resiko
1. Resiko dapat didefinisikan sebagai “Kemungkinan menderita kerugian atau
kehilangan; bahaya“. [www.baz.com] 1)
Setiap orang memiliki kewaspadaan terhadap potensi bahaya yang akan
muncul bahkan dalam aktivitas sederhana sehari-hari, resiko akan membentuk
behavior tiap individu. Setiap orang sebenarnya terbiasa mengatur resiko
kehidupannya masing-masing.
2. Resiko dapat didefinisikan sebagai “Potensi bahaya masa mendatang yang
dapat muncul sebagai akibat aksi saat ini“. [www.wikipedia.org] 2)
3. Resiko adalah “masalah yang dapat menyebabkan kerugian atau mengancam
proyek , namun hal tersebut belum terjadi, dan kita ingin menjaga supaya hal
tersebut tidak terjadi”. [www.processimpact.com] 3)
Potensi masalah dapat memberikan dampak yang kurang baik terhadap
biaya, jadwal, atau kesuksesan teknis suatu proyek, kualitas dari produk perangkat
lunak atau moral tim proyek. Manajemen resiko merupakan proses untuk
mengindentifikasi, memberikan arah, dan mengeliminasi potensi masalah sebelum
dapat merusak proyek.
Perlu adanya pembedaan antara resiko sebagai potensi masalah dengan
masalah yang dihadapi saat ini pada suatu proyek, karena kedua hal ini
memerlukan pendekatan yang berbeda. Sebagai contoh, kekurangan pegawai
karena tidak mampu mempekerjakan pegawai yang memiliki kemampuan teknis
merupakan masalah saat ini, tapi ancaman bahwa orang-orang teknis puncak akan
direbut untuk dipekerjakan oleh kompetitor kita merupakan resiko.
Masalah yang nyata memerlukan aksi korektif, sedangkan resiko dapat
dihadapi dengan beberapa pendekatan yang berbeda. Resiko dapat dihindari
sepenuhnya dengan merubah pendekatan proyek atau bahkan membatalkan
proyek, atau dapat juga dengan memilih untuk menyerap resiko tersebut dan tidak
melakukan aksi khusus apapun untuk menghindari atau meminimasinya. Namun,
bagaimanapun
juga,
harus
dipikirkan
aksi
tertentu
untuk
meminimasi
kecenderungan resiko berubah menjadi masalah, atau mengurangi dampak negatif
dari masalah tersebut pada proyek.
5
“Manajemen Resiko Software Engineering”
Tanti Kristanti
3. Manajemen Resiko
Manajemen Resiko adalah “proses yang digunakan untuk meminimasi atau
menghilangkan resiko sebelum membahayakan produktivitas proyek perangkat
lunak”. Dengan hanya 28% proyek perangkat lunak yang dapat selesai tepat
waktu dan sesuai budget, resiko dan manajemen resiko memainkan peran penting
dalam pengembangan perangkat lunak.
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.
Terdapat beberapa tipe resiko yang dapat muncul selama proyek
pengembangan perangkat lunak seperti yang dapat dilihat pada tabel 1, yaitu :
Tabel 1 Tipe-tipe Resiko
Tipe Resiko
Keterangan
Ancaman umum pada semua proyek. Sebagai contoh :
Generic Risk
perubahan
requirement,
kehilangan
anggota
tim,
kehilangan dana
Product-Specific
Risk
Resiko tingkat tinggi berhubungan dengan tipe produk
yang dikembangkan. Sebagai contoh : ketersediaan
sumber daya pengujian
Project Risk
Mempengaruhi jadwal proyek atau sumber daya
Product Risk
Mempengaruhi kualitas atau performansi perangkat
lunak
Business Risk
Mempengaruhi kelangsungan hidup perangkat lunak
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.
6
“Manajemen Resiko Software Engineering”
Tanti Kristanti
4. Resiko dalam Manajemen Proyek
Tidak seperti menghadapi resiko dalam kehidupan sehari-hari, bahaya dalam
software engineering (rekayasa perang lunak) haruslah dipelajari dengan
pendekatan tertentu dan melibatkan penelitian dari pengalaman sejumlah manajer
proyek yang berhasil atau melalui para penulis dan peneliti. Salah satu penulis
mengenai resiko ini adalah Dr.Barry W. Boehm (1989)
4)
, dalam bukunya
"Software Risk Management: Principles and Practices", beliau memberikan daftar
10 macam resiko yang terbesar, yaitu :
1. Personnel Shortfall
2. Penjadwalan dan budget yang tidak realistik
3. Membangun fungsi dan properti yang salah
4. Membangun user interface yang salah
5. Gold-plating
6. Melanjutkan aliran perubahan requirement
7. Shortfalls pada furnished component eksternal
8. Shortfalls pada performed task eksternal
9. Real-time performance shortfall
10. Straining computer-science capabilities
5. Bagaimana Mengatur (Manage)
Pada artikel yang sama, Dr. Boehm (1989)
4)
menjelaskan risk management
terdiri atas aktivitas-aktivitas berikut ini :
1. Risk Assessment (menggambarkan resiko apa yang terjadi dan harus fokus
terhadap yang mana)
a. Membuat daftar semua potensi bahaya yang akan mempengaruhi proyek.
b. Memperkirakan probabilitas kejadian dan potensi kehilangan dari tiap item
yang didaftar.
c. Mengurutkan item-item tersebut dari yang paling berbahaya sampai
kurang berbahaya.
2. Risk Control (berbuat sesuatu terhadap item-item tersebut)
a. Menggunakan teknik dan strategi untuk mengurangi resiko tertinggi.
7
“Manajemen Resiko Software Engineering”
Tanti Kristanti
b. Mengimplementasikan strategi untuk menetapkan faktor resiko tertinggi.
c. Mengawasi efektivitas strategi dan level perubahan resiko pada proyek.
6. Mengatur Resiko Secara Formal
Proses manajemen resiko formal menyediakan sejumlah manfaat bagi tim
proyek.
Pertama-tama,
dapat
memberikan
mekanisme
terstruktur
untuk
menyediakan visibilitas terhadap ancaman bagi kesuksesan proyek. Dengan
memperhatikan dampak potensial pada setiap item resiko, dapat memfokuskan
pada pengawasan terhadap resiko yang paling berat terlebih dahulu. Pendekatan
tim memungkinkan beragam stakeholder proyek menunjukkan resiko mereka
secara kolaboratif, dan melakukan mitigasi resiko dengan menentukan tanggung
jawab pada individu yang paling tepat. Risk assessment dapat dikombinasikan
dengan estimasi proyek sehingga dapat diukur kemungkinan penyimpangan
jadwal jika resiko tertentu muncul pada suatu proyek. Tanpa pendekatan yang
formal, tidak dapat dipastikan apakah aksi manajemen resiko diberlakukan pada
waktu yang tepat, sesuai rencana dan efektif. Tujuan akhir dari aktivitas ini adalah
membantu menghindari kejutan yang dapat dihindari, sehingga meningkatkan
kemungkinan pemenuhan komitmen awal.
Organisasi pengembangan mendapatkan manfaat dari manajemen resiko,
dimana dengan saling berbagi pengetahuan mengenai apa yang dapat dan tidak
dapat dilakukan untuk mengontrol resiko pada sejumlah proyek membantu proyek
untuk dapat menghindari pengulangan kesalahan yang sama. Anggota organisasi
dapat menyatukan pengalaman mereka dan mengidentifikasi peluang untuk
mengontrol resiko yang paling umum, melalui edukasi, process improvement, dan
aplikasi untuk rekayasa perangkat lunak dan teknik manajemen yang telah
diperbaiki. Setiap waktu, dapat dibuat daftar item resiko dan strategi mitigasi dari
berbagai proyek yang dapat membantu proyek di masa mendatang melihat adanya
bahaya yang tersembunyi.
7. Resiko dan Ketidakpastian
Resiko seringkali dihubungkan dengan ketidakpastian mengenai hal-hal
yang seolah-olah dianggap di bawah kendali, padahal akan berbahaya.
8
“Manajemen Resiko Software Engineering”
Tanti Kristanti
Ketidakpastian adalah karakteristik normal dan tidak dapat dihindari dari hampir
semua proyek perangkat lunak, ketidakpastian dapat dihasilkan dari kompleksitas
produk perangkat lunak yang muncul secara berkelanjutan, dan ketergesaan untuk
terjun pada source code editor. Kondisi teknologi dan bisnis yang berubah secara
cepat, mengakibatkan ketidakpastian akan selalu muncul. Kurangnya pengetahuan
akan teknik pengembangan perangkat lunak dan tool yang digunakan juga
mengakibatkan ketidakpastian yang semakin bertambah.
Mengontrol resiko dapat berarti mengurangi ketidakpastian. Tentu saja,
mengurangi
ketidakpastian
akan
mengakibatkan
biaya.
Perlu
adanya
penyeimbangan antara sejumlah biaya dengan biaya potensial yang akan didapat
jika resiko datang. Dengan mengurangi terlalu banyak ketidakpastiaan bukan
berarti akan mengakibatkan cost-effective. Sebagai contoh, jika suatu perusahaan
khawatir dengan kemampuan subkontraktor untuk dapat mengantarkan produk
yang dipesan tepat waktu, perusahaan tersebut dapat mengambil tindakan untuk
bekerjasama dengan banyak subkontraktor sehingga meningkatkan atau
setidaknya terdapat satu subkontraktor yang dapat mengirim tepat waktu. Namun
tindakan itu akan menjadi terlalu mahal, terutama jika masalah tersebut belum
tentu terjadi. Apakah hal ini bernilai ? Hal ini tergantung pada kebutuhan karena
setiap situasi memerlukan keputusan yang berbeda.
Manajemen resiko proaktif bukan berarti menghindari proyek yang memiliki
resiko tingkat tinggi, karena manajemen resiko bertujuan membuka mata para
pengembang sehingga dapat mengetahui apa yang akan berakibat fatal, dan
melakukan yang terbaik untuk memastikan faktor tersebut tidak akan mencegah
kesuksesan proyek.
8. Tipe Resiko Perangkat Lunak
Berikut ini adalah beberapa kategori resiko dan daftar resiko yang dapat
mengancam proyek [McConnell, 1996]7). Jika ada diantaranya pernah terjadi pada
proyek, buatlah sebagai faktor resiko utama sehingga tidak akan kembali terjadi
pada proyek di masa mendatang, berdasarkan pengalaman para software engineer
dan praktisi manajemen, resiko dapat dikontrol.
9
“Manajemen Resiko Software Engineering”
Tanti Kristanti
Capers Jones mengidentifikasi 5 faktor resiko yang mengancam proyek pada
sektor aplikasi yang berbeda [Jones, 1994]
5)
. Tabel 2 memberikan ilustrasi
tersebut, disertai juga dengan perkiraan persentase proyek yang diaplikasikan
pada Management Information Systems (MIS) dan sektor software komersial.
Tabel 2. Faktor Resiko Umum untuk Beragam Tipe Proyek
Sektor
Proyek
Persentase Proyek
dalam Resiko
Faktor Resiko
Memahami
secara
perlahan
kebutuhan user
MIS
Penekanan jadwal yang berlebihan
65%
Kualitas rendah
60%
Biaya membengkak
55%
Pengontrolan konfigurasi yang tidak
baik
Pendokumentasian user yang tidak
baik
Komersial
80%
50%
70%
User satisfaction yang rendah
55%
Time to market yang berlebihan
50%
Aksi-aksi kompetitif yang berbahaya 45%
Biaya litigasi
30%
9. Ketergantungan
Banyak resiko muncul karena external dependencies, jadi strategi mitigasi
dapat melibatkan rencana kontengensi untuk mendapatkan komponen yang
diperlukan dari sumber lain atau bekerja dengan sumber ketergantungan untuk
menjaga visibilitas yang baik ke dalam status dan mendeteksi masalah yang
membayangi. Berikut ini adalah jenis-jenis faktor resiko yang berkaitan dengan
ketergantungan :
1. Daftar atau informasi konsumen
2. Relasi subkontraktor internal dan eksternal
3. Ketergantungan inter komponen atau inter group
4. Kemampuan orang-orang terlatih dan berpengalaman
10
“Manajemen Resiko Software Engineering”
Tanti Kristanti
5. Guna ulang proyek untuk proyek berikutnya
10. Isu Requirement
Banyaknya
proyek
yang
menghadapi
ketidakpastian
requirement
(kebutuhan) produk, yang pada tahap awal pengembangan ditoleransi, namun jika
tidak dipecahkan selama proyek akan mengancam kesuksesan proyek. Jika tidak
melakukan kontrol pada faktor-faktor resiko, maka tidak mengherankan jika
pengembang akan mengembangkan produk yang salah atau mengembangkan
produk yang benar namun dengan kualitas yang buruk, dan hal-hal ini akan
mengakibatkan ketidakpuasan bagi konsumen. Oleh karena itu pengembang harus
memperhatikan bagaimana mendapatkan requirement yang jelas dan juga
mewaspadai beberapa faktor resiko berikut yaitu :
1. Ketidakjelasan visi produk
2. Kurangnya persetujuan/perjanjian terhadap requirement produk
3. Requirement yang tidak diprioritaskan
4. Market baru dengan kebutuhan yang tidak jelas
5. Aplikasi baru dengan ketidakjelasan requirement
6. Requirement yang selalu berubah
7. Requirement yang tidak efektif merubah proses manajemen
8. Analisis dampak perubahan requirement yang tidak memadai
11. Isu Manajemen
Meskipun banyak kekurangan manajemen yang dapat menghalangi
kesuksesan proyek, namun merencanakan manajemen resiko tidak dapat
mendaftarkan semua permasalahan, karena proyek manajer yang membuat
rencana manajemen resiko biasanya tidak akan mendaftarkan semua kelemahan
perusahaannya kepada publik meskipun resiko tersebut jelas-jelas diketahui oleh
para proyek manajer, hal seperti inilah yang akan membuat proyek mencapai
kesuksesan. Proses penelusuran proyek terdefinisi, dengan aturan dan tanggung
jawab yang jelas dapat memberi petunjuk terhadap faktor-faktor resiko berikut :
1. Identifikasi rencana dan tugas yang tidak memadai
2. Visibilitas status proyek aktual yang tidak memadai
11
“Manajemen Resiko Software Engineering”
Tanti Kristanti
3. Kepemilikan proyek dan pengambilan keputusan yang tidak jelas
4. Pembuatan komitmen yang tidak realistik, kadang kala untuk suatu alasan
yang tidak masuk akal
5. Ekspektasi manajer dan konsumen yang tidak realistik
6. Konflik antar staf
7. Komunikasi yang kurang
12. Kurangnya Pengetahuan
Perubahan teknologi software yang pesat, serta semakin berkurangnya staf
yang memiliki keahlian, akan membuat tim proyek tidak memiliki skill untuk
meraih kesuksesan. Untuk mengatasi hal ini, kuncinya adalah mengenali area
resiko secara dini sehingga dapat mengambil aksi-aksi preventif yang tepat seperti
melaksanakan pelatihan, menyewa konsultan dan merekrut orang-orang yang
berkompeten untuk tim proyek. Faktor-faktor berikut ini dapat terjadi dalam tim
proyek :
1. Pelatihan yang tidak memadai
2. Pemahaman yang kurang terhadap metoda, tool dan teknik
3. Pengalaman domain aplikasi yang tidak memadai
4. Adanya teknologi atau metoda pengembangan yang baru
5. Proses yang tidak efektif, tidak terdokumentasi secara baik atau lalai
dijalankan
13. Kategori Resiko Lainnya
Daftar area resiko potensial sangatlah banyak, namun permasalahan ini
harus tetap diketahui agar pengembang dapat mengantisipasi. Beberapa area yang
harus diperhatikan termasuk :
1. Tidak tersedianya perlengkapan dan fasilitas untuk mengembangkan sistem
dan melakukan perawatan.
2. Ketidakmampuan untuk memperoleh sumber daya dengan kemampuan kritis
3. Turnover personil-personil yang penting
4. Requirement performansi yang tidak terpenuhi
5. Permasalahan dengan bahasa dan internasionalisasi produk
12
“Manajemen Resiko Software Engineering”
Tanti Kristanti
6. Pendekatan teknis yang tidak dapat bekerja
14. Pendekatan Manjemen Resiko
Organisasi dapat memilih satu dari 5 pendekatan untuk mengatasi resiko
[McConnell, 1996]7). Manajemen krisis merupakan reaksi terhadap resiko yang
sebelumnya tidak teridentifikasi atau ter-manage yang muncul menjadi bahaya
yang jelas saat ini. Pendekatan yang lebih proaktif adalah dengan mengidentifikasi
resiko proyek dan merencanakan bagaimana merespon resiko tersebut ketika
muncul. Sangatlah baik untuk mengambil aksi konkret untuk mencegah resiko
yang teridentifikasi yang dapat menyebabkan permasalahan dan bukan hanya
sekedar memperbaiki produk dari kesalahan. Manajemen resiko yang utama
adalah untuk menghilangkan penyebab utama resiko yang akan mengancam
proyek organisasi. Manajemen resiko merupakan aplikasi tool dan prosedur yang
tepat untuk mengatasi resiko dengan batasan yang dapat diterima. Manajemen
resiko terdiri atas sejumlah komponen yaitu:
1. Risk assessment
Merupakan proses untuk menguji proyek dan mengidentifikasi area resiko
potensial. Identifikasi resiko dapat difasilitas dengan bantuan suatu daftar area
resiko umum untuk proyek software, atau dengan menguji isi database
organisasi yang berisi resiko serta strategi mitigasi yang teridentifikasi
sebelumnya (baik sukses maupun tidak). Analisis resiko melibatkan pengujian
bagaimana outcome proyek berubah dengan melakukan modifikasi variabel
input resiko.
2. Risk prioritization
Membantu proyek memfokuskan pada resiko yang paling berat dengan
memperkirakan risk exposure. Prioritas dapat dilakukan dengan cara
kuantitatif, dengan estimasi probabilitas (antara 0.1-1.0) dengan kegagalan
relatif pada skala 1 sampai 10. Menggabungkan beberapa faktor ini akan
menyediakan estimasi risk exposure bagi tiap risk item, yang dapat terjadi
pada kisaran 0.1 sampai 10. Semakin tinggi exposure, semakin agresif resiko
yang harus ditangani. Lebih mudah untuk mengestimasi probabilitas dan
dampaknya sebagai High, Medium atau Low. Dengan item tersebut,
13
“Manajemen Resiko Software Engineering”
Tanti Kristanti
setidaknya terdapat 1 dimensi resiko dengan rate High dan perlu diperhatikan
terlebih dahulu.
3. Risk avoidance
Merupakan salah satu cara untuk berhubungan dengan resiko, dimana resiko
dihindari dengan tidak melaksanakan proyek tertentu dan hanya melaksanakan
proyek yang pasti.
4. Risk control
Merupakan proses mengatur resiko untuk mencapai outcome yang
dikehendaki. Merencanakan manajemen resiko akan menghasilkan rencana
untuk berhubungan dengan setiap resiko yang signifikan, termasuk mitigasi
pendekatan, kepemilikan dan timeline. Resolusi resiko merupakan eksekusi
rencana yang berkaitan dengan tiap resiko. Dimana pada akhirnya, risk
monitoring akan membantu melacak perkembangan pemecahan tiap resiko.
Mengidentifikasi resiko proyek secara sederhana tidaklah cukup karena
resiko tersebut perlu didokumentasikan guna memudahkan komunikasi nature dan
status resiko pada komunitas project stakeholder selama proyek berjalan. Tabel 3
menunjukkan form untuk mendokumentasikan resiko. Daftar resiko dapat
disertakan sebagai bagian dokumentasi dari rencana proyek software atau menjadi
dokumen yang berdiri sendiri. Sebagai alternatif, form pada Tabel 4 dapat
digunakan untuk mendokumentasikan faktor resiko individual secara detail.
Saat mendokumentasikan statemen resiko, gunakanlah format conditionconsequence yang menyatakan situasi/kondisi resiko yang diperhatikan, diikuti
dengan setidaknya satu outcome yang kurang potensial (consequence) jika resiko
tersebut berubah menjadi masalah. Seringkali, orang-orang menyatakan resiko
sebagai condition (“konsumen tidak menyetujui requirement produk tertentu”)
atau consequence (“kita hanya dapat memuaskan satu atau sejumlah besar
konsumen”). Yang baik adalah menggabungkan struktur condition-consequence
(“Konsumen tidak menyetujui requirement produk tertentu, sehingga kita hanya
mampu untuk memuaskan satu atau sejumlah besar konsumen”).
14
“Manajemen Resiko Software Engineering”
Tanti Kristanti
Kolom P, L dan E pada Tabel 3 menyediakan tempat untuk menangkap
probabilitas materialisasi resiko menjadi masalah (P), kegagalan yang dapat
terjadi akibat resiko (L), dan semua risk exposure (P dikali L). Resiko dapat
diurutkan secara descending, sehingga resiko dengan prioritas utama berada pada
daftar yang teratas. Perhatikan semua daftar resiko dengan menggunakan
mekanisme prioritas resiko untuk mempelajari dimana harus memfokuskan
pengontrolan resiko. Tentukan tujuan (goal) untuk menentukan kapan setiap
resiko dikontrol secara baik. Untuk beberapa resiko, strategi mitigasi dapat
difokuskan pada pengurangan probabilitas, sementara pendekatan untuk daftar
resiko lain dapat mengurangi dampak tersebut.
Pada kolom berikutnya dalam form, dokumentasikan hasil observasi yang
dapat mendasari adanya indikator pertama bahwa suatu faktor resiko akan
menjadi masalah saat ini. Dengan memonitor indikator pertama ini, akan
memberikan peringatan awal bahwa pendekatan manajemen resiko yang lebih
agresif
diperlukan.
Kolom
Risk
Mitigation
Approches
diperuntukkan
mengidentifikasi aksi-aksi untuk menjaga agar resiko tetap terkendali.
Tabel 3. Risk Documentation Form [processimpact.com]
ID
Risk
P
L
E
Description
First
Risk
Indicator
Mitigation
Who
Due
Assign
each risk
mitigation to
an
individual.
State a
date by
which the
mitigation
approach
is to be
implemented.
Approach
List each major
risk facing the
project. Describe
each risk in the
form "condition
– consequence".
Example:
"Subcontractor’s
staff does not
have sufficient
technical
expertise, so
their work is
delayed for
training and
slowed by
*P
*L
*E
 For
each
risk,
describe
the
earliest
indicato
r or
trigger
conditio
n that
might
indicate
that the
risk is
turning
into a
problem
 For each
risk, state
one or
more
approache
s to
control,
avoid,
minimize,
or
otherwise
mitigate
the risk.
 Risk
mitigation
approache
s should
yield
15
“Manajemen Resiko Software Engineering”
Tanti Kristanti
ID
Risk
P
L
E
Description
First
Risk
Who
Indicator
Mitigation
Due
Approach
learning curve."
Tabel 4. Form Lain
[processimpact.com]
Risk ID: <sequence number>
.
untuk
demonstra
ble results,
so you can
measure
whether
the risk
exposure
is
changing.
Dokumentasi
Classification: <risk category,
e.g., from SEI taxonomy>
Individual
Risk
Item
Report Date: <date this risk
report was last updated>
Description: <Describe each risk in the form "condition – consequence".>
Probability: <What’s the
likelihood
of
this
risk
becoming a problem?>
Impact: <What’s the damage if
the risk does become a
problem?>
Risk Exposure: <Multiply
Probability times Loss to
estimate the risk exposure.>
First Indicator: <Describe the earliest indicator or trigger condition that might indicate that the
risk is turning into a problem.>
Mitigation Approaches: <State one or more approaches to control, avoid, minimize, or
otherwise mitigate the risk. Mitigation approaches may reduce the probability or the impact.>
Date Started: <State the date
the
mitigation
plan
implementation was begun.>
Date to Complete: <State a
date by which the mitigation
plan is to be implemented.>
Owner: <Assign each risk
mitigation action to an
individual for resolution.>
Current Status: <Describe the status and effectiveness of the risk mitigation actions as of the
date of this report.>
Contingency Plan: <Describe the actions that will be taken to deal with the situation if this risk
factor actually becomes a problem.>
Trigger for Contingency Plan: <State the conditions under which the contingency plan will
begin to be implemented.>
15. Kesimpulan
Berdasarkan pada pembahasan pada bagian sebelumnya, dapat ditarik
beberapa kesimpulan sebagai berikut :
16
“Manajemen Resiko Software Engineering”
Tanti Kristanti
1. Manajemen resiko menjadi penting untuk industri perangkat lunak untuk
mengurangi surprise factor.
2. Manajemen resiko merupakan proses untuk mengindentifikasi, memberikan
arah, dan mengeliminasi potensi masalah sebelum dapat merusak proyek.
3. Manajemen resiko proaktif bukan berarti menghindari proyek yang memiliki
resiko tingkat tinggi, karena manajemen resiko bertujuan membuka mata para
pengembang sehingga dapat mengetahui apa yang akan berakibat fatal, dan
melakukan yang terbaik untuk memastikan faktor tersebut tidak akan
mencegah kesuksesan proyek.
4. Mengidentifikasi resiko proyek secara sederhana tidaklah cukup karena resiko
tersebut perlu didokumentasikan guna memudahkan komunikasi diantara
komunitas project stakeholder selama proyek berjalan.
Daftar Pustaka
[1] http://www.baz.com, diakses pada 09 Maret 2007 pukul 09.52
[2] http://www.wikipedia.org, diakses pada 09 Maret 2007 pukul 09.52
[3] http://www.processimpact.com, diakses pada 09 Maret 2007 pukul 09.52
[4] Boehm, Barry W, Software Risk Management, Los Alamitos, Calif.: IEEE
Computer Society Press, 1989.
[5] Jones, Capers, Assessment and Control of Software Risks, Englewood Cliffs,
N.J.: PTR Prentice-Hall, 1994.
[6] Karolak, Dale Walter, Software Engineering Risk Management, USA :
Computer Society Press, 1996.
[7] McConnell, Steve, Rapid Development: Taming Wild Software Schedules,
Redmond, Wash.: Microsoft Press, 1996.
17