Introduction to Software Risk & Risk Management Web view... (seperti kompleksnya algoritma) ... Sebagai contoh, ... Tidak seperti menghadapi resiko dalam kehidupan sehari-hari, bahaya

“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

mailto:[email protected]


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


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 pelatihan. Konsep

manajemen hanya ditemui pada program bisnis 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


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


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


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

Generic RiskAncaman umum pada semua proyek. Sebagai contoh : 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.

4. Resiko dalam Manajemen Proyek

Tidak seperti menghadapi resiko dalam kehidupan sehari-hari, bahaya dalam

software engineering (rekayasa perang lunak) haruslah dipelajari dengan

6


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.

b. Mengimplementasikan strategi untuk menetapkan faktor resiko tertinggi.

c. Mengawasi efektivitas strategi dan level perubahan resiko pada proyek.

6. Mengatur Resiko Secara Formal

7


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.

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

8


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.

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.

9


Tabel 2. Faktor Resiko Umum untuk Beragam Tipe Proyek

Sektor Proyek Faktor Resiko Persentase Proyek dalam Resiko

MIS

Memahami secara perlahan kebutuhan user 80%

Penekanan jadwal yang berlebihan 65%

Kualitas rendah 60%

Biaya membengkak 55%

Pengontrolan konfigurasi yang tidak baik 50%

Komersial

Pendokumentasian user yang tidak baik 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

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

10


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

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

11


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

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

12


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,

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

13


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 condition-

consequence 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”).

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.

14


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 Description P L E First

Indicator

Risk

Mitigation

Approach

Who Due

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 learning curve."

*P *L *E For each risk, describe the earliest indicator or trigger condition that might indicate that the risk is turning into a problem.

For each risk, state one or more approaches to control, avoid, minimize, or otherwise mitigate the risk.

Risk mitigation approaches should yield demonstrable results, so you can measure whether the risk exposure is changing.

Assign each risk mitigation to an individual.

State a date by which the mitigation approach is to be implemented.

Tabel 4. Form Lain untuk Dokumentasi Individual Risk Item [processimpact.com]Risk ID: <sequence number> Classification: <risk category,

e.g., from SEI taxonomy>Report Date: <date this risk report was last updated>

Description: <Describe each risk in the form "condition – consequence".>

15


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 :

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

16

http://www.wikipedia.org/

http://www.baz.com/


[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

http://www.processimpact.com/

Documents

Introduction to Software Risk & Risk Management Web view... (seperti kompleksnya algoritma) ... Sebagai contoh, ... Tidak seperti menghadapi resiko dalam kehidupan sehari-hari, bahaya