RISK MANAGEMENT SOFTWARE PROJECT Dwi Retnoningsih, S.T, M.T Jurusan Teknik Informatika, STMIK El Rahma Jl. Sisingamangaraja No.76, Telp. (0274) 377982, Yogyakarta ABSTRACT - Jurnal Online STMIK EL RAHMA
RISK MANAGEMENT SOFTWARE PROJECT
Dwi Retnoningsih, S.T, M.T
Jurusan Teknik Informatika, STMIK El Rahma
Jl. Sisingamangaraja No.76, Telp. (0274) 377982, Yogyakarta
ABSTRACT
Rrisk management is one of important factor in development of a
software which good. Why? Usually if in expansion and making of a
software assumes that all run matching with the one which is planned. So
no thinking of will which there will be in the future. And if happened thing
surprising, hence that thing is not news that is good for fluency of process
software. Risk menejemen does can lessen level of risk which there will be.
With management risk, can predict things which can happened period to
come, arrest;detains big the thing and earns soon takes action action to
lessen impact of the risk. Risk management to overcome risk before
becoming more hard.
Way or stages; steps taken to face risks which possibly will
happened that is firstly starts with recognizing / recognizes what which
able to become wrong, called as also "risk identification" or identifies risk.
The next, every risk is analysed possibility that possibly happened and
damage resulted if really happened (risk component, projection of risk,
assess risk impact). After making information, risk is sorted based on its
(the possibility and impact. Last, builds plan to arrange risk with high
possibility and the high impact that is with RMMM (Risk Mitigation,
Monitoring, Manage).
Strategy faces risk which there will be front of eye that is reactive
and proaktif. Reactive faces a risk without plan which is clear, only hopes
luck. Looks down to risks until the risk is really happened and faces all out
the. This strategy usualy applied by team project of software.
Key words : risk menejemen, project of software, software manager,
customer, developer, user, RMMM.
INTISARI
Menejemen resiko merupakan salah satu faktor penting dalam
pembangunan sebuah software yang baik. Mengapa? Biasanya bila dalam
pengembangan dan pembuatan sebuah software berasumsi bahwa semua
berjalan sesuai dengan yang direncanakan. Jadi tak ada memikirkan apa
yang akan terjadi diwaktu yang akan datang. Dan bila terjadi sesuatu yang
mengejutkan, maka hal itu bukanlah kabar yang bagus bagi kelancaran
proses software. Melakukan menejemen resiko dapat mengurangi tingkat
resiko yang akan terjadi. Dengan menejemen resiko, bisa memprediksikan
1
hal–hal yang dapat terjadi dimasa mendatang, menahan hal tersebut
membesar dan dapat segera mengambil langkah aksi untuk mengurangi
dampak dari resiko tersebut. Menejemen resiko untuk mengatasi resiko
sebelum menjadi lebih parah.
Cara atau langkah–langkah yang diambil untuk menghadapi resiko–
resiko yang mungkin akan terjadi yaitu pertama memulai dengan recognizing
/mengenal apa yang bisa menjadi salah, disebut juga “risk identification” atau
mengidentifikasi resiko. Berikutnya, tiap resiko dianalisis kemungkinan
yang mungkin terjadi dan kerusakan yang diakibatkan bila benar terjadi
(komponen resiko, proyeksi resiko, menilai dampak resiko). Setelah
membuat informasi, resiko diurutkan berdasarkan kemungkinan dan
dampaknya. Terakhir, membangun rencana untuk mengatur resiko dengan
kemungkinan yang tinggi dan dampak yang tinggi tersebut yaitu dengan
RMMM (Risk Mitigation, Monitoring, Manage).
Strategi menghadapi resiko yang akan terjadi didepan mata yaitu
reaktif dan proaktif. Reaktif menghadapi sebuah resiko tanpa plan yang
jelas, hanya berharap keberuntungan. Meremehkan resiko–resiko sampai
resiko tersebut benar–benar terjadi dan menghadapi sekuat tenaga yang
ada. Strategi ini biasa diterapkan oleh tim proyek software.
Kata-kata kunci : menejemen resiko, proyek perangkat lunak, manajer
perangkat lunak, pelanggan, pengembang, pemakai, RMMM.
Apakah Resiko?
Menurut buku Analisis dan Manajemen Resiko, Robert Charette,
menyajikan definisi konseptual mengenai resiko. “Resiko berhubungan
dengan sesuatu yang akan datang. Sekarang dan kemarin tidak menjadi
perhatian khusus. Maka bila melakukan perubahan cara menghadapi suatu
resiko, maka kita dapat mencipkatan sesuatu yang berbeda dan kesempatan
yang besar pada situasi yang lebih baik dimasa mendatang. Ini melibatkan
perubahan seperti perubahan pikiran, pendapat, aksi, atau tempat. Resiko
melibatkan banyak pilihan dan ketidakpastian bahwa pilihan itu yang
diperlukan”.
Menurut sumber lain, Know Your Enemy : Software Risk Management
oleh Karl E. wiegers, yang dipublikasikan pada majalah software development,
oktober 1998, walau dengan inti arti resiko yang sama, memberikan definisi
resiko yang sederhana “Resiko adalah sesuatu yang dapat mengakibatkan
“loss” dan dapat mengancam kesuksesan dari project, tetapi belum pasti
terjadi.(dan perlu mempertahankan jauh darinya).”
Selain itu sebuah statement dalam Software Risk Management :
Principles and Practices oleh Barry W. Boehm, bahwa resiko didalam kamus
webster’s diartikan “the possibility of loss and injury”. Ini dapat diartikan dalam
konsep dasar dari menejemen resiko yaitu yang disebut pemaparan resiko
merupakan “risk impact” (dampak resiko) atau “risk factor” (faktor resiko).
Perpaduan dari nilai kemungkinan dari hasil yang tidak diinginkan/tidak
2
memuaskan dan nilai kerugian yang diakibatkan jika hasil tersebut benar
tidak diinginkan/tidak memuaskan. Dimana hasil yang tidak diinginkan
berhubungan dengan customer, developer, user dan maintainer.
Resiko selalu melibatkan dua karakteristik berikut:
1. Uncertainty (ketidakpastian) : kejadian dimana menandakan bahwa
resiko dapat terjadi ataupun tidak bakal terjadi. Maka tidak ada 100%
kemungkinan dari resiko.
2. Loss (rugi/hilang) : jika resiko benar–benar terjadi maka akan ada
konsekuensi yang tidak diharapkan ataupun mengalami kerugian.
Bila resiko dipertimbangkan dalam kontek rekayasa perangkat
lunak dan dunia IT, konsep Charrete selalu menjadi terbukti. Masa akan
datang adalah menjadi perhatian, Resiko apakah yang dapat mengakibatkan
proyek software menjadi serba salah. Perubahan adalah perhatian kita,
bagaimana akan perubahan pada customer, requirement, development technologies,
target environtment dan semua hal lain yang berhubungan dengan proyek yang
mempengaruhi batas waktu dan keberhasilan seluruhnya? Berbagai pilihan
seperti metode dan tools apakah yang harus kita gunakan? Berapa banyak
orang yang dilibatkan? Berapa banyak penekanan kualitas yang harus
dicapai?
Masalah yang potensial akan memberikan dampak yang merugikan
pada biaya, penjadwalan, teknik yang sukses, kualitas produk atau moral
tim.
Menejemen resiko adalah proses mengidentifikasi, mengalamatkan
dan mengeliminasi masalah potensial ini sebelum memberikan kerusakan
pada proyek.
Menurut Peter Drucker “Meski tidak ada gunanya mencoba mengeliminasi
resiko, dan mempertanyakan untuk meminimal resiko tersebut, itu perlu
bahwa resiko yang diambil adalah resiko yang benar”. Tetapi sebelum
beranjak tentang resiko yang benar perlu dahulu di identifikasi,
kemungkinan terjadinya, estimasi dampak yang akan dialami dan membuat
rencana bila mungkin masalah benar-benar terjadi oleh orang–orang yang
terlibat dengan resiko tersebut. Orang-orang yang terlibat dalam proses
software yaitu manajer, software engineer, stockholder yang berpartisipasi dalam
analisis resiko dan menejemen.
Bagaimana pun juga perlu berusaha meng-tackle resiko tersebut
dan menghilangkannya, resiko memiliki potensial memberikan banyak
dampak dari banyak aspek dalam suatu proyek. Asumsi ini bahwa tidak ada
sesuatu yang tidak diharapkan akan dapat menggelincirkan proyek menjadi
sedikit tidak masuk akal. Estimasi yang dilakukan seharusnya adalah
memasukkan dalam pendapat terbaik bahwa sesuatu yang menyeramkan
yang potensial dapat terjadi pada semua proyek, dan menejer harus
merespek dari penaksiran yang dibuat bersama tim. Dengan menejemen
resiko, akan membuang the rose-colored glasses dan menghadapi potensi yang
3
nyata dari sesuatu yang tidak diinginkan yang dapat melempar proyek
keluar jalur.
Cara atau langkah–langkah yang diambil untuk menghadapi resiko–
resiko yang mungkin akan terjadi yaitu pertama memulai dengan recognizing
/ mengenal apa yang bisa menjadi salah, disebut juga “risk identification”
atau mengidentifikasi resiko. Berikutnya, tiap resiko dianalisis kemungkinan
yang mungkin terjadi dan kerusakan yang diakibatkan bila benar terjadi
(komponen resiko, proyeksi resiko, menilai dampak resiko). Setelah
membuat informasi, resiko diurutkan berdasarkan kemungkinan dan
dampaknya. Terakhir, membangun rencana untuk mengatur resiko dengan
kemungkinan yang tinggi dan dampak yang tinggi tersebut yaitu dengan
RMMM (Risk Mitigation, Monitoring, Manage).
Cara atau langkah–langkah yang dilakukan menurut Software Risk
Management : Principles and Practices oleh Barry W. Boehm, terdiri 6 buah yaitu :
1. Identifikasi resiko
2. Analisis resiko
3. Memprioritaskan resiko
4. Merencanakan menejemen resiko
5. Membuat solusi resiko
6. Memonitor resiko
Menejemen resiko ini dikompres lagi menjadi aktivitas berikut :
1. Risk assessment (menaksikan resiko) : memperhitungkan apa resikonya
dan bagaimana untuk menghadapinya.
a. Membuat list dari semua bahaya yang potensial akan
mempengaruhi proyek.
b. Menaksir kemungkinan yang mungkin terjadi dan potensial
kerugian dari tiap resiko.
c. Mengurutkan resiko berdasarkan yang paling bahaya.
2. Risk Control (mengkontrol resiko) : melakukan sesuatu terhadap resiko
tersebut.
a. Segera dengan teknologi dan strategi untuk mengurangi dampak
tertinggi resiko.
b. Mengimplementasi strategi untuk memecahkan dampak tertinggi
faktor resiko.
c. Memonitor efektivitas dari strategi dan merubah level resiko dari
keseluruhan proyek
Resiko Reaktif dan Proaktif
Strategi menghadapi resiko yang akan terjadi didepan mata yaitu
reaktif dan proaktif. Reaktif menghadapi sebuah resiko tanpa plan yang
jelas, hanya berharap keberuntungan. Meremehkan resiko–resiko sampai
resiko tersebut benar–benar terjadi dan menghadapi sekuat tenaga yang
ada. Strategi ini biasa diterapkan oleh tim proyek software. Tim ini tidak
berbuat apa–apa hingga sesuatu yang buruk terjadi, kemudian mereka baru
4
segera menyelesaikan masalah dengan cepat. Bila ini gagal maka muncul
menejemen krisis, dan proyek dalam keadaan bahaya.
Strategi yang biasanya menejer proyek yang lakukan dan lebih baik
untuk menejemen resiko adalah strategi proaktif. Strategi proaktif
dilakukan sebelum proyek dimulai. Resiko potensial diidentifikasi,
menaksirkan kemungkinannya dan dampaknya, dan diurutkan berdasarkan
yang paling utama diperhatikan. Kemudian membangun menejemen
resiko. Tujuan utamanya adalah menghindari resiko, tetapi tidak semua
resiko dapat dihindari. Dengan ini tim mengembangkan rencana proyek
yang mudah memberikan respon kontrol dan dengan cara yang efektif.
Mengapa Harus Memanage Resiko Secara Formal?
Cara formal proses menejemen resiko memberikan keuntungan
antara tim proyek dan organisasi yang membangun secara bersamaan.
Pertama, memberikan mekanisme yang terstruktur untuk memberikan
penglihatan atas ancaman yang dapat mengancam kesuksesan proyek.
Dengan mempertimbangkan dampak yang potensial dari tiap item resiko,
dapat memusatkan dahulu untuk mengendalikan pada resiko yang paling
berbahaya, yang paling mungkin terjadi dan yang paling berdampak.
Dalamm hal ini dapat mengkombinasikan antara penaksiran resiko dengan
estimasi proyek untuk mengukur kemungkinan penggeseran jadwal jika
materi resiko–resiko pasti mengakibatkan masalah. Berbagi cara apa yang
bisa dilakukan dan cara apa yang tidak dapat dilakukan untuk
mengendalikan resiko–resiko dengan berbagai bantuan proyek,
menghindari kesalahan yang telah dilakukan dari proyek yang sebelumnya.
Tanpa pendekatan formal, maka tidak dapat memastikan bahwa tindakan
dari menejemen resiko memulai pada waktu yang tepat, menyelesaikan
sesuai rencana dan efektif. (Know Your Enemy : Software Risk Management
oleh Karl E. wiegers, yang dipublikasikan pada majalah software development,
oktober 1998)
Resiko Software
Agar dapat mengenali resiko–resiko, perlu untuk mengenal dan
menganalisis kualifikasi resiko berdasarkan ketidakpastiannya dan tingkat
kerugian dari masing–masing resiko, untuk itu perlu memperhatikan
kategori resiko :
1. Project risks (resiko proyek), akan mengancam rencana proyek. Bila
resiko proyek benar menjadi kenyataan, maka kemungkinan jadwal
proyek akan meleset dan biaya akan membengkak. Resiko proyek
mengidentifikan
akan
pembiayaan
potensial,
penjadwalan,
staff/organisasi, sumber daya, pelanggan dan requirement permintaan
dan yang berdampak pada proyek software. Selain itu juga kompleksitas
proyek, ukuran dan ketidakpastian level struktural juga sebagai faktor
resiko proyek.
5
2. Technical risks (resiko teknik), akan mengancam kualitas dan waktu
pengerjaan softaware. Bila resiko teknik ini menjadi kenyataan, maka
implementasi akan menjadi susah ataupun menjadi tidak mungkin.
Resiko teknik mengidentifikasikan akan desain potensia, implementasi,
interface, verifikasi, dan pemeliharaan. Didalamnya spesifikasi yang
ambiguitas, ketidakpastian teknik, keusangan teknik, dan “leading edge”
teknologi juga merupakan faktor resiko. Resiko teknik terjadi
dikarenakan masalah yang terjadi ternyata lebih sulit untuk dipecahkan
daripada yang dibayangkan.
3. Business risk (resiko bisnis), akan mengancam ketahanan dari software
yang dibangun. Resiko bisnis dapat membayakan proyek atau produk.
Lima resiko bisnis utama yaitu :
a. Resiko pasar, dimana membuat produk atau sistem tetapi tidak ada
yang membutuhkan atau tidak ada yang mau.
b. Resiko strategi, dimana membuat produk yang tidak mampu untuk
menangani keseluruhan proses bisnis yang diinginkan.
c. Resiko pemasaran, dimana membuat produk tetapi bagian
pemasaran bingung cara untuk memasarkannya.
d. Resiko menejemen, dimana tidak adanya dukungan dari
menejemen senior sehubungan dengan perubahan focus atau
perubahan manusia
e. Resiko biaya, dimana kehilangan pembiayaan dan personal
4. Kategori umum lain yang dipublikasikan oleh Charette. Known risk
(resiko yang diketahui), resiko yang ditemukan setelah evaluasi yang
hati–hati dari rencana proyek, bisnis dan lingkungan teknik saat proyek
sedang dikembangkan dan sumber informasi yang reliabel lainnya
(tanggal penyelesaian yang tidak mungkin, kurangnya domentasi
requirement dari batasan software, lingkungan pengembang yang buruk).
5. Predictable risk (resiko yang telah diprediksi), resiko dari pengalaman
proyek yang sebelumnya (perubahan staf, kurangnya komunikasi
dengan customer)
6. Unpredictable risk (resiko yang tidak dapat diprediksi), resiko yang
tersembunyi, bisa benar – benar terjadi tetapi sangat sulit diidentikasi.
Dari kategori–kategori ini maka dapat memikirkan resiko–resiko tersebut
termasuk dalam kategori yang mana sebelum memulai dari sebuah proyek.
Pengkategorian ini bisa diperhitungkan dari jenis proyek yang akan
ditangani. Sebagai contoh sebuah proyek pembangunan yang akan dipakai
untuk perusahaan tertentu (telah dipesan), berbeda dengan proyek untuk
diperjual belikan. Jenis kategori resiko bisnis untuk resiko pemasaran tidak
perlu diperhatikan lebih detil untuk proyek yang disebutkan pertama dari
pada proyek kedua, mungkin lebih menitik beratkan pada kategori resiko
yang lainya.
6
Identifikasi Resiko
Identifikasi resiko adalah cara sistematis untuk menentukan
ancaman terhadap rencana proyek. Dengan mengidentifikasi resiko yang
diketahui dan yang dapat diprediksikan, menejer dapat mengambil langkah
awal untuk menghindari saat memunginkan dan mengkontrol saat
dibutuhkan.
Terdapat dua tipe resiko terhadap kategori–kategori yang
teridentifikasi sebelumnya, yaitu tipe resiko generik dan tipe resiko produk
spesifik. Resiko generik merupakan ancaman potensial yang dapat terjadi
pada setiap proyek software. Resiko produk spesifik hanya dapat
diidentifikasi hanya oleh mereka yang mengerti benar dari teknologi, orang,
dan lingkungan yang spesifik akan software yang sedang dibuat. Untuk
mengidentifikasi resiko produk spesifik, rencana proyek dan lingkup
software telah diuji, kemudian mengembangkan terhadap pertanyaan–
pertanyaan berikut : “karakteristik apa dari sebuah produk yang bisa
mengancam rencana proyek?”.
Sebuah metode untuk mengidentifikasi resiko dengan membuat
checklist item resiko. Checklist ini digunakan untuk mengidentifikasi dan
memfokus pada bagian resiko yang telah diketahui dan diprediksi dari subkategori berikut :
1. Ukuran produk : resiko yang berhubungan dengan keseluruhan dari
ukuran software yang sedang dibuat atau dimodifikasi.
Sebuah pernyataan bahwa resiko berbanding langsung dengan ukuran
produk. Dalam masing–masing kasus, informasi produk yang akan
dikembangkan harus dibandingkan dengan pengalaman sebelumnya.
Bila presentase deviasi besar atau sama tetapi hasil yang lalu sangat
kurang dari yang diharapkan maka resikonya adalah tinggi.
2. Dampak bisnis : resiko yang berhubungan dengan batasan dari
menejemen dan pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan
pertimbangan bisnis kadang mengalami konflik dengan kenyataan
teknik. Respon pada produk yang akan dikembangkan harus
dibandingkan dengan pengalaman sebelumnya. Bila presentase deviasi
besar atau sama tetapi hasil yang lalu sangat kurang dari yang
diharapkan maka resikonya adalah tinggi.
3. Karakteristik customer : resiko yang berhubungan dengan keinginan
customer dan kemampuan pengembang dengan customer pada waktu yang
tepat.
Customer tidak diciptakan sama semua. Menurut Pressman dan Herron
menyatakan :
Customer memiliki keinginan yang berbeda. Beberapa ada yang tahu
apa yang mereka inginkan dan yang lain tahu apa yang tidak mereka
inginkan.
Customer memiliki kepribadian yang berbeda. Beberapa menikmati
sebagai pelanggan dan yang lain tidak mengharapkannya. Beberapa
7
4.
5.
6.
7.
akan senang menerima produk yang buruk, sementara beberapa
yang lainya akan mengeluh dengan produk yang kurang.
Customer memiliki hubungan yang bervariasi dengan pengembang.
Beberapa mengenali produk dan produser secara baik, yang lain
tidak
Customer juga bertentanan. Menginginkan gratis dan ada yang
teperangkan kontradiksi dalam diri.
Customer yang buruk akan berpengaruh yang besar terhadap
kemampuan tim software untuk menyelesaikan proyek tepat waktu
dan sesuai anggaran.
Proses pendefinisian : resiko yang berhubungan dengan level dari proses
software yang telah didefinisikan dan disesuaikan dengan organisasi
pengembang.
Lingkungan pengembang : resiko yang berhubungan dengan
kecocokan dan kualitas tools yang akan digunakan dalam membuat
produk.
Peranti yang tidak sesuai dan tidak efektif dan menumpulkan usaha
bahkan dari pembuat yang trampil sekalipun.
Teknologi untuk membuat : resiko yang berhubungan dengan
kompleksitas dari sistem yang akan dibangun.
Membuka batasan teknologi merupakan hal yang menantang dan
menyenangkan karena memaksa seseorang pengembang untuk
menggunakan keterampilannya secara penuh, tetapi hal tersebut
sangatlah berisiko.
Ukuran dan pengalaman staf : resiko yang berhubungan dengan
keseluruhan pengalaman teknik dan proyek dari software engineer.
Checklist item resiko dapat dikumpulkan dengan berbagai cara yang
berbeda, dibuat pertanyaan–pertanyaan yang relevan dengan masing–
masing sub-kategori tadi dan dijawab untuk masing–masing proyek software.
Jawaban tersebut memungkinkan perencana memperkirakan dampak dari
resiko. Kemudian tercipta “risk component and driver” dengan kemungkinan
terjadinya.
Berdasarkan penelitian identifikasi resiko yang dituangkan dalam
Risk Management during Requirements oleh Tom DeMarco and Tim Lister terdapat
5 resiko yang sering muncul dan merupakan resiko inti yaitu :
1. Kekurangan penjadwalan : estimasi bahwa kesalahan dimulai dari
hari pertama, yang sering berdasarkan hanya pada kebijaksanaan.
2. Spesifikasi yang keliru : kegagalan dalam konsensuk pada pelanggan
akan apa yang ingin dibangun.
3. Ruang lingkup yang merayap : requirement/permintaan tambahan
yang menambah setting-an yang diterima pada permulaan.
4. Hilangnya personel : anggota proyek yang telah meninggalkan
sebelum proyek selesai.
8
5. Variasi produktifitas : perbedaan antara pelaksanaan nyata dengan
asumsi.
Menurut Barry W. Boehm, dalam Software Risk Management : Principles
and Practices, bahwa identifikasi resiko menghasilkan daftar produksi dari
item resiko spesifikasi proyek yang dapat membantu kesuksesan proyek.
Tipikal dari identifikasi resiko meliputi checklist, pengujian dari keputusan
driver, perbandingan dengan pengalaman (analisis asumsi), dan
mengkomposisi ulang. Terdapat item resiko software yaitu :
1. Shortfalls personal
2. Penjadwalan dan pembiayaan yang tidak masuk akal
3. Mengembangkan fungsi dan properti yang salah
4. Mengembangkan interface pengguna
5. Gold-plating
6. Melanjutkan alur dari perubahan requirement
7. Shortfalls didalam komponen pelengkap external
8. Shortfalls didalam melakukan tugas external
9. Real-time performance shortfalls
10. Kemampuan straining computer-science
Memprediksikan Resiko Proyek Keseluruhan
Membuat pertanyaan yang diambil dari data resiko yang didapat
dari mengsurvei pengalaman dari menejer proyek software. Pertanyaan ini
dibuat sesuai dengan tingkat pentingnya pada kesuksesan dari proyek.
1. Apakah software utama dan customer menejer terkait untuk mensupport proyek?
2. Apakah pengguna terakhir terkait pada proyek dan sistem yang
akan dibuat?
3. Apakah requirement benar–benar dimengerti oleh tim ahli software
dan customer?
4. Apakah customer ikut terlibat pebuh pada definisi dan requirement?
5. Apakah pengguna terakhir memiliki pengharapan yang realistik?
6. Apakah ruang lingkup proyek stabil?
7. Apakah tim ahli software memiliki penggabungan skill yang baik?
8. Apakan requirement proyek stabil?
9. Apakah tim proyek memilki pengalaman dengan teknologi yang
akan diimplementasikan?
10. Apakah jumlah orang dalam proyek mampu mengerjakan tugas?
11. Apakan semua customer / pengguna setuju dengan yang penting dari
proyek dan requirement dari sistem yang akan dibuat?
Jika pertanyaan ini dijawab dengan negatif maka pengurangan, monitoring
dan memanage resiko (RMMM) harus dilakukan.
9
Komponen Resiko dan Driver
Perlunya mengidentifikasi resiko driver yang dapat mempengaruhi
komponen resiko yaitu performance, cost, support, and schedule. Komponen
resiko didefinisikan dengan:
1. performance risk (resiko kinerja) : derajat ketidakpastian bahwa
produk akan sesuai dengan requirement dan bakal digunakan.
2. cost risk (resiko biaya) : derajat ketidakpastian bahwa biaya proyek
akan dijaga.
3. support risk (resiko pendukung) : derajat ketidakpastian bahwa
software yang dihasilkan akan mudah diperbaiki, adaptasi dan
dikembangkan.
4. schedule risk (resiko jadwal) : derajat ketidakpastian bahwa jadwal
proyek akan dijaga, dan produk akan selesai pada waktunya.
Pengaruh ini dibandingkan dengan pengaruh driver yaitu kecil, sedang, kritis
dan parah. Seperti contoh pada tabel berikut :
Tabel 1. prediksi dampak
Proyeksi Resiko
Proyeksi resiko disebut juga estimasi resiko, menjangkau resiko
dengan dua cara yaitu kemungkinan resiko yang terjadi dan konsekuensi
dari resiko tersebut. Kemudian perencana proyek, menejer, dan staf teknik
melakukan 4 tahap proyeksi resiko yaitu :
1. Membuat skala dimana merefleksikan resiko yang mungkin terjadi.
2. Menggambarkan konsekuensi dari resiko tersebut.
10
3. Mengestimasi pengaruh resiko dalam proyek dan produk.
4. Mencatat keseluruhan ketepatan dari proyeksi resiko, sehingga
tidak ada kesalahpahaman.
Dengan membuat prioritas resiko, tim bisa melokasikan sumber daya ke
tempat paling besar dampaknya.
Mengembangkan Tabel Resiko
Tabel resiko akan memberi menejer teknik yang sederhana untuk
proyeksi resiko. Tim proyek memulai dengan mendaftarkan semua resiko
dengan bantuan dari checklist item resiko yang telah diketahui sebelumnya.
Disesuikan dengan kategorinya, kemudian dinilai presentasi kemungkinan
terjadinya. Nilai kemungkinan didapat dari rata–rata dari nilai yang
diberikan oleh tiap–tiap anggota tim. Dan terakhir menilai tingkat
pengaruhnya dilihat dari tabel komponen yang telah diketahui sebelumnya.
Setelah kesemuanya diisi dan dinilai maka diurutkan sesuai dengan
kemungkinan dan dampaknya. Kemungkinan yang paling tinggi, pengaruh
paling besar berada paling atas tabel, dan sebaliknya.
Tabel 2. proyeksi tabel
Menaksirkan Dampak Resiko
Tiga faktor yang mempengaruhi konsekuensi jika sebuah resiko
benar–benar terjadi yaitu sifatnya, ruang lingkup, dan waktunya. Sifat
mengindikasikan pada masalah yang muncul jika resiko itu terjadi. Ruang
lingkup adalah kombinasi dari kerumitan dan keseluruhan distribusinya.
Waktunya suatu resiko dipertimbangkan dari kapan dan lamanya resiko
tersebut akan dialami.
Proyeksi resiko dan analisis teknik yang telah diuraikan sebelumnya
diaplikasikan dengan iteratif selama proyek perangkat lunak berjalan. Tim
proyek harus melihat lagi tabel resiko pada interval yang reguler,
mengevaluasi lagi masing–masing resiko untuk menentukan perubahan
dari kemungkinan dan dampaknya. Perlunya penambahan resiko baru
dalam tabel dan mengganti resiko lama yang tidak relevan lagi.
Keseluruhan dari risk exposure (pembukaan resiko), RE, adalah
ditentukan dengan relasi berikut :
11
RE = P * C
P adalah kemungkinan terjadi dari resiko.
C adalah biaya dari proyek bila resiko benar terjadi .
Menurut Software Risk Management : Principles and Practices oleh Barry
W. Boehm, bahwa risk exposure (RE) memiliki relasi berikut :
RE = P(UO) * L(UO)
P(UO) adalah nilai kemungkinan dari hasil yang tidak diinginkan/tidak
memuaskan
L(UO) adalah nilai kerugian yang diakibatkan jika hasil tersebut benar tidak
diinginkan/tidak memuaskan.
Agar penilaian bermanfaat, maka tingkat referensi resiko harus
ditentukan. Tingkat referensi resiko meliputi tingkat penurunan kinerja,
pembengkakan biaya, kesulitan pendukung, dan melesetnya jadwal yang
akan menyebabkan dampak pada proyek dan akan diterminasi.
Pengurangan, Monitoring, dan Menejemen Resiko (RMMM)
Semua analisis resiko yang pada bagian ini memiliki datu tujuan
yaitu membantu tim proyek dalam mengembangkan strategi yang berkaitan
dengan resiko. Strategi yang efektif harus berdasarkan :
1. Menghindari resiko.
2. Memonitor resiko.
3. Menejemen resiko dan perencanaan kemungkinan.
Bila tim software menggunakan pendekatan proaktif terhadap
resiko, maka penghindaran selalu menjadi strategi yang terbaik. Dengan
mengembangkan rencana pengurangan resiko (mitigation).
Pada saat proyek berjalan, aktivitas pemonitoran resiko
(monitoring) dimulai. Manajer memonitor faktor–faktor yang dapat
memberikan suatu indikasi bahwa resiko menjadi lebih atau berkurang.
Sebagai tambahan untuk memonitor faktor–faktor tersebut, menejer
proyek juga harus memonitor efektivitas langkah pengurangan resiko.
Menejemen resiko dan perencanaan kemungkinan mengasumsikan
bahwa usaha pengurangan telah gagal dan resiko menjadi nyata. Bila
strategi telah diikuti, maka backup ada, informasi terdokumentasi dan
pengetahuan telah disebarkan pada semua anggota tim. Menejer proyek
juga secara temporal memfokuskan kembali pada sumberdaya dengan
fungsi–fungsi yang telah disusun sepenuhnya, sehingga bagi penambahan
anggota tim bisa melanjutkan.
12
Perlu diketahui bahwa langkah RMMM akan membutuhkan biaya
proyek tambahan. Maka salah satu bagian dari menejemen resiko adalah
mengevaluasi pada saat manfaat yang ditambahkan oleh langkah RMMM
diberatkan oleh biaya yang berkaitan dengan implementasi RMMM.
Resiko Keselamatan dan Bahaya
Resiko tidak hanya dibatasi oleh proyek itu saja. Tetapi resiko juga
dapat terjadi setelah software telah diselesaikan dengan sukses dan diterima
oleh customer. Ini berhubungan dengan konsekuensi di lapangan.
Meskipun kemungkinan suatu sistem yang dibuat dengan baik
adalah kecil, tetapi kesalahan yang terdeteksi pada kontrol dan monitoring
dapat menghasilkan kerusakan yang besar, seperti ekonomi, cacat manusia
atau kematian.
Keselamatan software dan analisis bahaya adalah aktivitas jaminan
kualitas software yang terfokus pada identifikasi dan perkiraan bahaya
potensial yang dapat mempengaruhi software secara negatif, dan keseluruhan
sistem bisa gagal. Bila bahaya telah teridentifikasi dari awal proses rekayasa,
maka ciri–ciri desain software depat ditentukan, dan itu akan mengeliminasi
atau mengontrol bahaya potensial.
RMMM Plan
Strategi menejemen resiko dapat dimasukkan dalam rencana
proyek software atau langkah menejemen resiko diatur dalam risk mitigation,
monitoring, and management plan (RMMM plan). RMMM plan yaitu
mendokumentasikan semua kegiatan yang dilakukan sebagai bagian dari
keseluruhan rencana proyek.
Tabel 3. RMMM plan dokumen
13
Setelah RMMM plan telah dikembangkan dan proyek dimulai,
pengurangan resiko (mitigation) dan monitoring resiko (monitor) juga dimulai.
Penguarangan resiko (mitigation) adalah aktivitas penghindaran
masalah, dengan mencari penyebabnya. Monitoring resiko (monitoring)
adalah untuk memperkirakan apakah resiko yang diramalkan akan benar–
benar terjadi, untuk memastikan bahwa langkah resiko yang telah
didefinisikan telah diterapkan dengan benar, mengumpulkan informasi
yang dapat digunakan untuk analisis resiko diwaktu mendatang.
Kesimpulan
Banyak hal yang mengendalikan proyek software tetapi akal sehat
menentukan analisis resiko. Waktu yang digunakan untuk mengidentifikasi,
menganalisis, dan mengatur resiko dalam beberapa cara, dapat
mengkibatkan kehebohan saat proyek berlangsung, kemampuan
bertambah untuk menelusuri dan mengontrol proyek, konfidensi yang
muncul bersamaan dengan perencanaan untuk masalah sebelum masalah
itu terjadi.
Identifikasi, analisis, proyeksi, perkiraan, menejemen dan
monitoring semuanya butuh waktu, tetapi tetap berharga. “Jika anda
mengenali musuh dan mengenali diri sendiri, anda tidak perlu
mengkhawatirkan hasil dari ratusan pertempuran” menurut SunTzu,
jendral cina. Untuk manajer software maka resiko adalah musuhnya.
DAFTAR PUSTAKA
Wiegers, Karl E Know Your Enemy : Software Risk Management, Software
development magazine, oktober 1998.
Boehm Barry W, Software Risk Management : Principles and Practices
Pressman, Roger S, Software engineering, sixth edition, 2005
BIODATA PENULIS
Dwi Retnoningsih, adalah dosen tetap STMIK El Rahma Yogyakarta,
lahir di Sukoharjo 29 Mei 1975. Memperoleh gelar Sarjana Teknik, Jurusan
Manajemen Informatika dan Teknik Komputer dari Institut Sains dan
Teknologi Akprind Yogyakarta pada tahun 1999, Memperoleh gelar
Magister Teknik, dari Program Studi Teknik Informatika, Magister
Teknologi Informasi, Universitas Gadjah Mada Yogyakarta pada tahun
2008, Jabatan akademik Asisten Ahli, Minat keilmuan Teknologi Informasi.
14
Dwi Retnoningsih, S.T, M.T
Jurusan Teknik Informatika, STMIK El Rahma
Jl. Sisingamangaraja No.76, Telp. (0274) 377982, Yogyakarta
ABSTRACT
Rrisk management is one of important factor in development of a
software which good. Why? Usually if in expansion and making of a
software assumes that all run matching with the one which is planned. So
no thinking of will which there will be in the future. And if happened thing
surprising, hence that thing is not news that is good for fluency of process
software. Risk menejemen does can lessen level of risk which there will be.
With management risk, can predict things which can happened period to
come, arrest;detains big the thing and earns soon takes action action to
lessen impact of the risk. Risk management to overcome risk before
becoming more hard.
Way or stages; steps taken to face risks which possibly will
happened that is firstly starts with recognizing / recognizes what which
able to become wrong, called as also "risk identification" or identifies risk.
The next, every risk is analysed possibility that possibly happened and
damage resulted if really happened (risk component, projection of risk,
assess risk impact). After making information, risk is sorted based on its
(the possibility and impact. Last, builds plan to arrange risk with high
possibility and the high impact that is with RMMM (Risk Mitigation,
Monitoring, Manage).
Strategy faces risk which there will be front of eye that is reactive
and proaktif. Reactive faces a risk without plan which is clear, only hopes
luck. Looks down to risks until the risk is really happened and faces all out
the. This strategy usualy applied by team project of software.
Key words : risk menejemen, project of software, software manager,
customer, developer, user, RMMM.
INTISARI
Menejemen resiko merupakan salah satu faktor penting dalam
pembangunan sebuah software yang baik. Mengapa? Biasanya bila dalam
pengembangan dan pembuatan sebuah software berasumsi bahwa semua
berjalan sesuai dengan yang direncanakan. Jadi tak ada memikirkan apa
yang akan terjadi diwaktu yang akan datang. Dan bila terjadi sesuatu yang
mengejutkan, maka hal itu bukanlah kabar yang bagus bagi kelancaran
proses software. Melakukan menejemen resiko dapat mengurangi tingkat
resiko yang akan terjadi. Dengan menejemen resiko, bisa memprediksikan
1
hal–hal yang dapat terjadi dimasa mendatang, menahan hal tersebut
membesar dan dapat segera mengambil langkah aksi untuk mengurangi
dampak dari resiko tersebut. Menejemen resiko untuk mengatasi resiko
sebelum menjadi lebih parah.
Cara atau langkah–langkah yang diambil untuk menghadapi resiko–
resiko yang mungkin akan terjadi yaitu pertama memulai dengan recognizing
/mengenal apa yang bisa menjadi salah, disebut juga “risk identification” atau
mengidentifikasi resiko. Berikutnya, tiap resiko dianalisis kemungkinan
yang mungkin terjadi dan kerusakan yang diakibatkan bila benar terjadi
(komponen resiko, proyeksi resiko, menilai dampak resiko). Setelah
membuat informasi, resiko diurutkan berdasarkan kemungkinan dan
dampaknya. Terakhir, membangun rencana untuk mengatur resiko dengan
kemungkinan yang tinggi dan dampak yang tinggi tersebut yaitu dengan
RMMM (Risk Mitigation, Monitoring, Manage).
Strategi menghadapi resiko yang akan terjadi didepan mata yaitu
reaktif dan proaktif. Reaktif menghadapi sebuah resiko tanpa plan yang
jelas, hanya berharap keberuntungan. Meremehkan resiko–resiko sampai
resiko tersebut benar–benar terjadi dan menghadapi sekuat tenaga yang
ada. Strategi ini biasa diterapkan oleh tim proyek software.
Kata-kata kunci : menejemen resiko, proyek perangkat lunak, manajer
perangkat lunak, pelanggan, pengembang, pemakai, RMMM.
Apakah Resiko?
Menurut buku Analisis dan Manajemen Resiko, Robert Charette,
menyajikan definisi konseptual mengenai resiko. “Resiko berhubungan
dengan sesuatu yang akan datang. Sekarang dan kemarin tidak menjadi
perhatian khusus. Maka bila melakukan perubahan cara menghadapi suatu
resiko, maka kita dapat mencipkatan sesuatu yang berbeda dan kesempatan
yang besar pada situasi yang lebih baik dimasa mendatang. Ini melibatkan
perubahan seperti perubahan pikiran, pendapat, aksi, atau tempat. Resiko
melibatkan banyak pilihan dan ketidakpastian bahwa pilihan itu yang
diperlukan”.
Menurut sumber lain, Know Your Enemy : Software Risk Management
oleh Karl E. wiegers, yang dipublikasikan pada majalah software development,
oktober 1998, walau dengan inti arti resiko yang sama, memberikan definisi
resiko yang sederhana “Resiko adalah sesuatu yang dapat mengakibatkan
“loss” dan dapat mengancam kesuksesan dari project, tetapi belum pasti
terjadi.(dan perlu mempertahankan jauh darinya).”
Selain itu sebuah statement dalam Software Risk Management :
Principles and Practices oleh Barry W. Boehm, bahwa resiko didalam kamus
webster’s diartikan “the possibility of loss and injury”. Ini dapat diartikan dalam
konsep dasar dari menejemen resiko yaitu yang disebut pemaparan resiko
merupakan “risk impact” (dampak resiko) atau “risk factor” (faktor resiko).
Perpaduan dari nilai kemungkinan dari hasil yang tidak diinginkan/tidak
2
memuaskan dan nilai kerugian yang diakibatkan jika hasil tersebut benar
tidak diinginkan/tidak memuaskan. Dimana hasil yang tidak diinginkan
berhubungan dengan customer, developer, user dan maintainer.
Resiko selalu melibatkan dua karakteristik berikut:
1. Uncertainty (ketidakpastian) : kejadian dimana menandakan bahwa
resiko dapat terjadi ataupun tidak bakal terjadi. Maka tidak ada 100%
kemungkinan dari resiko.
2. Loss (rugi/hilang) : jika resiko benar–benar terjadi maka akan ada
konsekuensi yang tidak diharapkan ataupun mengalami kerugian.
Bila resiko dipertimbangkan dalam kontek rekayasa perangkat
lunak dan dunia IT, konsep Charrete selalu menjadi terbukti. Masa akan
datang adalah menjadi perhatian, Resiko apakah yang dapat mengakibatkan
proyek software menjadi serba salah. Perubahan adalah perhatian kita,
bagaimana akan perubahan pada customer, requirement, development technologies,
target environtment dan semua hal lain yang berhubungan dengan proyek yang
mempengaruhi batas waktu dan keberhasilan seluruhnya? Berbagai pilihan
seperti metode dan tools apakah yang harus kita gunakan? Berapa banyak
orang yang dilibatkan? Berapa banyak penekanan kualitas yang harus
dicapai?
Masalah yang potensial akan memberikan dampak yang merugikan
pada biaya, penjadwalan, teknik yang sukses, kualitas produk atau moral
tim.
Menejemen resiko adalah proses mengidentifikasi, mengalamatkan
dan mengeliminasi masalah potensial ini sebelum memberikan kerusakan
pada proyek.
Menurut Peter Drucker “Meski tidak ada gunanya mencoba mengeliminasi
resiko, dan mempertanyakan untuk meminimal resiko tersebut, itu perlu
bahwa resiko yang diambil adalah resiko yang benar”. Tetapi sebelum
beranjak tentang resiko yang benar perlu dahulu di identifikasi,
kemungkinan terjadinya, estimasi dampak yang akan dialami dan membuat
rencana bila mungkin masalah benar-benar terjadi oleh orang–orang yang
terlibat dengan resiko tersebut. Orang-orang yang terlibat dalam proses
software yaitu manajer, software engineer, stockholder yang berpartisipasi dalam
analisis resiko dan menejemen.
Bagaimana pun juga perlu berusaha meng-tackle resiko tersebut
dan menghilangkannya, resiko memiliki potensial memberikan banyak
dampak dari banyak aspek dalam suatu proyek. Asumsi ini bahwa tidak ada
sesuatu yang tidak diharapkan akan dapat menggelincirkan proyek menjadi
sedikit tidak masuk akal. Estimasi yang dilakukan seharusnya adalah
memasukkan dalam pendapat terbaik bahwa sesuatu yang menyeramkan
yang potensial dapat terjadi pada semua proyek, dan menejer harus
merespek dari penaksiran yang dibuat bersama tim. Dengan menejemen
resiko, akan membuang the rose-colored glasses dan menghadapi potensi yang
3
nyata dari sesuatu yang tidak diinginkan yang dapat melempar proyek
keluar jalur.
Cara atau langkah–langkah yang diambil untuk menghadapi resiko–
resiko yang mungkin akan terjadi yaitu pertama memulai dengan recognizing
/ mengenal apa yang bisa menjadi salah, disebut juga “risk identification”
atau mengidentifikasi resiko. Berikutnya, tiap resiko dianalisis kemungkinan
yang mungkin terjadi dan kerusakan yang diakibatkan bila benar terjadi
(komponen resiko, proyeksi resiko, menilai dampak resiko). Setelah
membuat informasi, resiko diurutkan berdasarkan kemungkinan dan
dampaknya. Terakhir, membangun rencana untuk mengatur resiko dengan
kemungkinan yang tinggi dan dampak yang tinggi tersebut yaitu dengan
RMMM (Risk Mitigation, Monitoring, Manage).
Cara atau langkah–langkah yang dilakukan menurut Software Risk
Management : Principles and Practices oleh Barry W. Boehm, terdiri 6 buah yaitu :
1. Identifikasi resiko
2. Analisis resiko
3. Memprioritaskan resiko
4. Merencanakan menejemen resiko
5. Membuat solusi resiko
6. Memonitor resiko
Menejemen resiko ini dikompres lagi menjadi aktivitas berikut :
1. Risk assessment (menaksikan resiko) : memperhitungkan apa resikonya
dan bagaimana untuk menghadapinya.
a. Membuat list dari semua bahaya yang potensial akan
mempengaruhi proyek.
b. Menaksir kemungkinan yang mungkin terjadi dan potensial
kerugian dari tiap resiko.
c. Mengurutkan resiko berdasarkan yang paling bahaya.
2. Risk Control (mengkontrol resiko) : melakukan sesuatu terhadap resiko
tersebut.
a. Segera dengan teknologi dan strategi untuk mengurangi dampak
tertinggi resiko.
b. Mengimplementasi strategi untuk memecahkan dampak tertinggi
faktor resiko.
c. Memonitor efektivitas dari strategi dan merubah level resiko dari
keseluruhan proyek
Resiko Reaktif dan Proaktif
Strategi menghadapi resiko yang akan terjadi didepan mata yaitu
reaktif dan proaktif. Reaktif menghadapi sebuah resiko tanpa plan yang
jelas, hanya berharap keberuntungan. Meremehkan resiko–resiko sampai
resiko tersebut benar–benar terjadi dan menghadapi sekuat tenaga yang
ada. Strategi ini biasa diterapkan oleh tim proyek software. Tim ini tidak
berbuat apa–apa hingga sesuatu yang buruk terjadi, kemudian mereka baru
4
segera menyelesaikan masalah dengan cepat. Bila ini gagal maka muncul
menejemen krisis, dan proyek dalam keadaan bahaya.
Strategi yang biasanya menejer proyek yang lakukan dan lebih baik
untuk menejemen resiko adalah strategi proaktif. Strategi proaktif
dilakukan sebelum proyek dimulai. Resiko potensial diidentifikasi,
menaksirkan kemungkinannya dan dampaknya, dan diurutkan berdasarkan
yang paling utama diperhatikan. Kemudian membangun menejemen
resiko. Tujuan utamanya adalah menghindari resiko, tetapi tidak semua
resiko dapat dihindari. Dengan ini tim mengembangkan rencana proyek
yang mudah memberikan respon kontrol dan dengan cara yang efektif.
Mengapa Harus Memanage Resiko Secara Formal?
Cara formal proses menejemen resiko memberikan keuntungan
antara tim proyek dan organisasi yang membangun secara bersamaan.
Pertama, memberikan mekanisme yang terstruktur untuk memberikan
penglihatan atas ancaman yang dapat mengancam kesuksesan proyek.
Dengan mempertimbangkan dampak yang potensial dari tiap item resiko,
dapat memusatkan dahulu untuk mengendalikan pada resiko yang paling
berbahaya, yang paling mungkin terjadi dan yang paling berdampak.
Dalamm hal ini dapat mengkombinasikan antara penaksiran resiko dengan
estimasi proyek untuk mengukur kemungkinan penggeseran jadwal jika
materi resiko–resiko pasti mengakibatkan masalah. Berbagi cara apa yang
bisa dilakukan dan cara apa yang tidak dapat dilakukan untuk
mengendalikan resiko–resiko dengan berbagai bantuan proyek,
menghindari kesalahan yang telah dilakukan dari proyek yang sebelumnya.
Tanpa pendekatan formal, maka tidak dapat memastikan bahwa tindakan
dari menejemen resiko memulai pada waktu yang tepat, menyelesaikan
sesuai rencana dan efektif. (Know Your Enemy : Software Risk Management
oleh Karl E. wiegers, yang dipublikasikan pada majalah software development,
oktober 1998)
Resiko Software
Agar dapat mengenali resiko–resiko, perlu untuk mengenal dan
menganalisis kualifikasi resiko berdasarkan ketidakpastiannya dan tingkat
kerugian dari masing–masing resiko, untuk itu perlu memperhatikan
kategori resiko :
1. Project risks (resiko proyek), akan mengancam rencana proyek. Bila
resiko proyek benar menjadi kenyataan, maka kemungkinan jadwal
proyek akan meleset dan biaya akan membengkak. Resiko proyek
mengidentifikan
akan
pembiayaan
potensial,
penjadwalan,
staff/organisasi, sumber daya, pelanggan dan requirement permintaan
dan yang berdampak pada proyek software. Selain itu juga kompleksitas
proyek, ukuran dan ketidakpastian level struktural juga sebagai faktor
resiko proyek.
5
2. Technical risks (resiko teknik), akan mengancam kualitas dan waktu
pengerjaan softaware. Bila resiko teknik ini menjadi kenyataan, maka
implementasi akan menjadi susah ataupun menjadi tidak mungkin.
Resiko teknik mengidentifikasikan akan desain potensia, implementasi,
interface, verifikasi, dan pemeliharaan. Didalamnya spesifikasi yang
ambiguitas, ketidakpastian teknik, keusangan teknik, dan “leading edge”
teknologi juga merupakan faktor resiko. Resiko teknik terjadi
dikarenakan masalah yang terjadi ternyata lebih sulit untuk dipecahkan
daripada yang dibayangkan.
3. Business risk (resiko bisnis), akan mengancam ketahanan dari software
yang dibangun. Resiko bisnis dapat membayakan proyek atau produk.
Lima resiko bisnis utama yaitu :
a. Resiko pasar, dimana membuat produk atau sistem tetapi tidak ada
yang membutuhkan atau tidak ada yang mau.
b. Resiko strategi, dimana membuat produk yang tidak mampu untuk
menangani keseluruhan proses bisnis yang diinginkan.
c. Resiko pemasaran, dimana membuat produk tetapi bagian
pemasaran bingung cara untuk memasarkannya.
d. Resiko menejemen, dimana tidak adanya dukungan dari
menejemen senior sehubungan dengan perubahan focus atau
perubahan manusia
e. Resiko biaya, dimana kehilangan pembiayaan dan personal
4. Kategori umum lain yang dipublikasikan oleh Charette. Known risk
(resiko yang diketahui), resiko yang ditemukan setelah evaluasi yang
hati–hati dari rencana proyek, bisnis dan lingkungan teknik saat proyek
sedang dikembangkan dan sumber informasi yang reliabel lainnya
(tanggal penyelesaian yang tidak mungkin, kurangnya domentasi
requirement dari batasan software, lingkungan pengembang yang buruk).
5. Predictable risk (resiko yang telah diprediksi), resiko dari pengalaman
proyek yang sebelumnya (perubahan staf, kurangnya komunikasi
dengan customer)
6. Unpredictable risk (resiko yang tidak dapat diprediksi), resiko yang
tersembunyi, bisa benar – benar terjadi tetapi sangat sulit diidentikasi.
Dari kategori–kategori ini maka dapat memikirkan resiko–resiko tersebut
termasuk dalam kategori yang mana sebelum memulai dari sebuah proyek.
Pengkategorian ini bisa diperhitungkan dari jenis proyek yang akan
ditangani. Sebagai contoh sebuah proyek pembangunan yang akan dipakai
untuk perusahaan tertentu (telah dipesan), berbeda dengan proyek untuk
diperjual belikan. Jenis kategori resiko bisnis untuk resiko pemasaran tidak
perlu diperhatikan lebih detil untuk proyek yang disebutkan pertama dari
pada proyek kedua, mungkin lebih menitik beratkan pada kategori resiko
yang lainya.
6
Identifikasi Resiko
Identifikasi resiko adalah cara sistematis untuk menentukan
ancaman terhadap rencana proyek. Dengan mengidentifikasi resiko yang
diketahui dan yang dapat diprediksikan, menejer dapat mengambil langkah
awal untuk menghindari saat memunginkan dan mengkontrol saat
dibutuhkan.
Terdapat dua tipe resiko terhadap kategori–kategori yang
teridentifikasi sebelumnya, yaitu tipe resiko generik dan tipe resiko produk
spesifik. Resiko generik merupakan ancaman potensial yang dapat terjadi
pada setiap proyek software. Resiko produk spesifik hanya dapat
diidentifikasi hanya oleh mereka yang mengerti benar dari teknologi, orang,
dan lingkungan yang spesifik akan software yang sedang dibuat. Untuk
mengidentifikasi resiko produk spesifik, rencana proyek dan lingkup
software telah diuji, kemudian mengembangkan terhadap pertanyaan–
pertanyaan berikut : “karakteristik apa dari sebuah produk yang bisa
mengancam rencana proyek?”.
Sebuah metode untuk mengidentifikasi resiko dengan membuat
checklist item resiko. Checklist ini digunakan untuk mengidentifikasi dan
memfokus pada bagian resiko yang telah diketahui dan diprediksi dari subkategori berikut :
1. Ukuran produk : resiko yang berhubungan dengan keseluruhan dari
ukuran software yang sedang dibuat atau dimodifikasi.
Sebuah pernyataan bahwa resiko berbanding langsung dengan ukuran
produk. Dalam masing–masing kasus, informasi produk yang akan
dikembangkan harus dibandingkan dengan pengalaman sebelumnya.
Bila presentase deviasi besar atau sama tetapi hasil yang lalu sangat
kurang dari yang diharapkan maka resikonya adalah tinggi.
2. Dampak bisnis : resiko yang berhubungan dengan batasan dari
menejemen dan pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan
pertimbangan bisnis kadang mengalami konflik dengan kenyataan
teknik. Respon pada produk yang akan dikembangkan harus
dibandingkan dengan pengalaman sebelumnya. Bila presentase deviasi
besar atau sama tetapi hasil yang lalu sangat kurang dari yang
diharapkan maka resikonya adalah tinggi.
3. Karakteristik customer : resiko yang berhubungan dengan keinginan
customer dan kemampuan pengembang dengan customer pada waktu yang
tepat.
Customer tidak diciptakan sama semua. Menurut Pressman dan Herron
menyatakan :
Customer memiliki keinginan yang berbeda. Beberapa ada yang tahu
apa yang mereka inginkan dan yang lain tahu apa yang tidak mereka
inginkan.
Customer memiliki kepribadian yang berbeda. Beberapa menikmati
sebagai pelanggan dan yang lain tidak mengharapkannya. Beberapa
7
4.
5.
6.
7.
akan senang menerima produk yang buruk, sementara beberapa
yang lainya akan mengeluh dengan produk yang kurang.
Customer memiliki hubungan yang bervariasi dengan pengembang.
Beberapa mengenali produk dan produser secara baik, yang lain
tidak
Customer juga bertentanan. Menginginkan gratis dan ada yang
teperangkan kontradiksi dalam diri.
Customer yang buruk akan berpengaruh yang besar terhadap
kemampuan tim software untuk menyelesaikan proyek tepat waktu
dan sesuai anggaran.
Proses pendefinisian : resiko yang berhubungan dengan level dari proses
software yang telah didefinisikan dan disesuaikan dengan organisasi
pengembang.
Lingkungan pengembang : resiko yang berhubungan dengan
kecocokan dan kualitas tools yang akan digunakan dalam membuat
produk.
Peranti yang tidak sesuai dan tidak efektif dan menumpulkan usaha
bahkan dari pembuat yang trampil sekalipun.
Teknologi untuk membuat : resiko yang berhubungan dengan
kompleksitas dari sistem yang akan dibangun.
Membuka batasan teknologi merupakan hal yang menantang dan
menyenangkan karena memaksa seseorang pengembang untuk
menggunakan keterampilannya secara penuh, tetapi hal tersebut
sangatlah berisiko.
Ukuran dan pengalaman staf : resiko yang berhubungan dengan
keseluruhan pengalaman teknik dan proyek dari software engineer.
Checklist item resiko dapat dikumpulkan dengan berbagai cara yang
berbeda, dibuat pertanyaan–pertanyaan yang relevan dengan masing–
masing sub-kategori tadi dan dijawab untuk masing–masing proyek software.
Jawaban tersebut memungkinkan perencana memperkirakan dampak dari
resiko. Kemudian tercipta “risk component and driver” dengan kemungkinan
terjadinya.
Berdasarkan penelitian identifikasi resiko yang dituangkan dalam
Risk Management during Requirements oleh Tom DeMarco and Tim Lister terdapat
5 resiko yang sering muncul dan merupakan resiko inti yaitu :
1. Kekurangan penjadwalan : estimasi bahwa kesalahan dimulai dari
hari pertama, yang sering berdasarkan hanya pada kebijaksanaan.
2. Spesifikasi yang keliru : kegagalan dalam konsensuk pada pelanggan
akan apa yang ingin dibangun.
3. Ruang lingkup yang merayap : requirement/permintaan tambahan
yang menambah setting-an yang diterima pada permulaan.
4. Hilangnya personel : anggota proyek yang telah meninggalkan
sebelum proyek selesai.
8
5. Variasi produktifitas : perbedaan antara pelaksanaan nyata dengan
asumsi.
Menurut Barry W. Boehm, dalam Software Risk Management : Principles
and Practices, bahwa identifikasi resiko menghasilkan daftar produksi dari
item resiko spesifikasi proyek yang dapat membantu kesuksesan proyek.
Tipikal dari identifikasi resiko meliputi checklist, pengujian dari keputusan
driver, perbandingan dengan pengalaman (analisis asumsi), dan
mengkomposisi ulang. Terdapat item resiko software yaitu :
1. Shortfalls personal
2. Penjadwalan dan pembiayaan yang tidak masuk akal
3. Mengembangkan fungsi dan properti yang salah
4. Mengembangkan interface pengguna
5. Gold-plating
6. Melanjutkan alur dari perubahan requirement
7. Shortfalls didalam komponen pelengkap external
8. Shortfalls didalam melakukan tugas external
9. Real-time performance shortfalls
10. Kemampuan straining computer-science
Memprediksikan Resiko Proyek Keseluruhan
Membuat pertanyaan yang diambil dari data resiko yang didapat
dari mengsurvei pengalaman dari menejer proyek software. Pertanyaan ini
dibuat sesuai dengan tingkat pentingnya pada kesuksesan dari proyek.
1. Apakah software utama dan customer menejer terkait untuk mensupport proyek?
2. Apakah pengguna terakhir terkait pada proyek dan sistem yang
akan dibuat?
3. Apakah requirement benar–benar dimengerti oleh tim ahli software
dan customer?
4. Apakah customer ikut terlibat pebuh pada definisi dan requirement?
5. Apakah pengguna terakhir memiliki pengharapan yang realistik?
6. Apakah ruang lingkup proyek stabil?
7. Apakah tim ahli software memiliki penggabungan skill yang baik?
8. Apakan requirement proyek stabil?
9. Apakah tim proyek memilki pengalaman dengan teknologi yang
akan diimplementasikan?
10. Apakah jumlah orang dalam proyek mampu mengerjakan tugas?
11. Apakan semua customer / pengguna setuju dengan yang penting dari
proyek dan requirement dari sistem yang akan dibuat?
Jika pertanyaan ini dijawab dengan negatif maka pengurangan, monitoring
dan memanage resiko (RMMM) harus dilakukan.
9
Komponen Resiko dan Driver
Perlunya mengidentifikasi resiko driver yang dapat mempengaruhi
komponen resiko yaitu performance, cost, support, and schedule. Komponen
resiko didefinisikan dengan:
1. performance risk (resiko kinerja) : derajat ketidakpastian bahwa
produk akan sesuai dengan requirement dan bakal digunakan.
2. cost risk (resiko biaya) : derajat ketidakpastian bahwa biaya proyek
akan dijaga.
3. support risk (resiko pendukung) : derajat ketidakpastian bahwa
software yang dihasilkan akan mudah diperbaiki, adaptasi dan
dikembangkan.
4. schedule risk (resiko jadwal) : derajat ketidakpastian bahwa jadwal
proyek akan dijaga, dan produk akan selesai pada waktunya.
Pengaruh ini dibandingkan dengan pengaruh driver yaitu kecil, sedang, kritis
dan parah. Seperti contoh pada tabel berikut :
Tabel 1. prediksi dampak
Proyeksi Resiko
Proyeksi resiko disebut juga estimasi resiko, menjangkau resiko
dengan dua cara yaitu kemungkinan resiko yang terjadi dan konsekuensi
dari resiko tersebut. Kemudian perencana proyek, menejer, dan staf teknik
melakukan 4 tahap proyeksi resiko yaitu :
1. Membuat skala dimana merefleksikan resiko yang mungkin terjadi.
2. Menggambarkan konsekuensi dari resiko tersebut.
10
3. Mengestimasi pengaruh resiko dalam proyek dan produk.
4. Mencatat keseluruhan ketepatan dari proyeksi resiko, sehingga
tidak ada kesalahpahaman.
Dengan membuat prioritas resiko, tim bisa melokasikan sumber daya ke
tempat paling besar dampaknya.
Mengembangkan Tabel Resiko
Tabel resiko akan memberi menejer teknik yang sederhana untuk
proyeksi resiko. Tim proyek memulai dengan mendaftarkan semua resiko
dengan bantuan dari checklist item resiko yang telah diketahui sebelumnya.
Disesuikan dengan kategorinya, kemudian dinilai presentasi kemungkinan
terjadinya. Nilai kemungkinan didapat dari rata–rata dari nilai yang
diberikan oleh tiap–tiap anggota tim. Dan terakhir menilai tingkat
pengaruhnya dilihat dari tabel komponen yang telah diketahui sebelumnya.
Setelah kesemuanya diisi dan dinilai maka diurutkan sesuai dengan
kemungkinan dan dampaknya. Kemungkinan yang paling tinggi, pengaruh
paling besar berada paling atas tabel, dan sebaliknya.
Tabel 2. proyeksi tabel
Menaksirkan Dampak Resiko
Tiga faktor yang mempengaruhi konsekuensi jika sebuah resiko
benar–benar terjadi yaitu sifatnya, ruang lingkup, dan waktunya. Sifat
mengindikasikan pada masalah yang muncul jika resiko itu terjadi. Ruang
lingkup adalah kombinasi dari kerumitan dan keseluruhan distribusinya.
Waktunya suatu resiko dipertimbangkan dari kapan dan lamanya resiko
tersebut akan dialami.
Proyeksi resiko dan analisis teknik yang telah diuraikan sebelumnya
diaplikasikan dengan iteratif selama proyek perangkat lunak berjalan. Tim
proyek harus melihat lagi tabel resiko pada interval yang reguler,
mengevaluasi lagi masing–masing resiko untuk menentukan perubahan
dari kemungkinan dan dampaknya. Perlunya penambahan resiko baru
dalam tabel dan mengganti resiko lama yang tidak relevan lagi.
Keseluruhan dari risk exposure (pembukaan resiko), RE, adalah
ditentukan dengan relasi berikut :
11
RE = P * C
P adalah kemungkinan terjadi dari resiko.
C adalah biaya dari proyek bila resiko benar terjadi .
Menurut Software Risk Management : Principles and Practices oleh Barry
W. Boehm, bahwa risk exposure (RE) memiliki relasi berikut :
RE = P(UO) * L(UO)
P(UO) adalah nilai kemungkinan dari hasil yang tidak diinginkan/tidak
memuaskan
L(UO) adalah nilai kerugian yang diakibatkan jika hasil tersebut benar tidak
diinginkan/tidak memuaskan.
Agar penilaian bermanfaat, maka tingkat referensi resiko harus
ditentukan. Tingkat referensi resiko meliputi tingkat penurunan kinerja,
pembengkakan biaya, kesulitan pendukung, dan melesetnya jadwal yang
akan menyebabkan dampak pada proyek dan akan diterminasi.
Pengurangan, Monitoring, dan Menejemen Resiko (RMMM)
Semua analisis resiko yang pada bagian ini memiliki datu tujuan
yaitu membantu tim proyek dalam mengembangkan strategi yang berkaitan
dengan resiko. Strategi yang efektif harus berdasarkan :
1. Menghindari resiko.
2. Memonitor resiko.
3. Menejemen resiko dan perencanaan kemungkinan.
Bila tim software menggunakan pendekatan proaktif terhadap
resiko, maka penghindaran selalu menjadi strategi yang terbaik. Dengan
mengembangkan rencana pengurangan resiko (mitigation).
Pada saat proyek berjalan, aktivitas pemonitoran resiko
(monitoring) dimulai. Manajer memonitor faktor–faktor yang dapat
memberikan suatu indikasi bahwa resiko menjadi lebih atau berkurang.
Sebagai tambahan untuk memonitor faktor–faktor tersebut, menejer
proyek juga harus memonitor efektivitas langkah pengurangan resiko.
Menejemen resiko dan perencanaan kemungkinan mengasumsikan
bahwa usaha pengurangan telah gagal dan resiko menjadi nyata. Bila
strategi telah diikuti, maka backup ada, informasi terdokumentasi dan
pengetahuan telah disebarkan pada semua anggota tim. Menejer proyek
juga secara temporal memfokuskan kembali pada sumberdaya dengan
fungsi–fungsi yang telah disusun sepenuhnya, sehingga bagi penambahan
anggota tim bisa melanjutkan.
12
Perlu diketahui bahwa langkah RMMM akan membutuhkan biaya
proyek tambahan. Maka salah satu bagian dari menejemen resiko adalah
mengevaluasi pada saat manfaat yang ditambahkan oleh langkah RMMM
diberatkan oleh biaya yang berkaitan dengan implementasi RMMM.
Resiko Keselamatan dan Bahaya
Resiko tidak hanya dibatasi oleh proyek itu saja. Tetapi resiko juga
dapat terjadi setelah software telah diselesaikan dengan sukses dan diterima
oleh customer. Ini berhubungan dengan konsekuensi di lapangan.
Meskipun kemungkinan suatu sistem yang dibuat dengan baik
adalah kecil, tetapi kesalahan yang terdeteksi pada kontrol dan monitoring
dapat menghasilkan kerusakan yang besar, seperti ekonomi, cacat manusia
atau kematian.
Keselamatan software dan analisis bahaya adalah aktivitas jaminan
kualitas software yang terfokus pada identifikasi dan perkiraan bahaya
potensial yang dapat mempengaruhi software secara negatif, dan keseluruhan
sistem bisa gagal. Bila bahaya telah teridentifikasi dari awal proses rekayasa,
maka ciri–ciri desain software depat ditentukan, dan itu akan mengeliminasi
atau mengontrol bahaya potensial.
RMMM Plan
Strategi menejemen resiko dapat dimasukkan dalam rencana
proyek software atau langkah menejemen resiko diatur dalam risk mitigation,
monitoring, and management plan (RMMM plan). RMMM plan yaitu
mendokumentasikan semua kegiatan yang dilakukan sebagai bagian dari
keseluruhan rencana proyek.
Tabel 3. RMMM plan dokumen
13
Setelah RMMM plan telah dikembangkan dan proyek dimulai,
pengurangan resiko (mitigation) dan monitoring resiko (monitor) juga dimulai.
Penguarangan resiko (mitigation) adalah aktivitas penghindaran
masalah, dengan mencari penyebabnya. Monitoring resiko (monitoring)
adalah untuk memperkirakan apakah resiko yang diramalkan akan benar–
benar terjadi, untuk memastikan bahwa langkah resiko yang telah
didefinisikan telah diterapkan dengan benar, mengumpulkan informasi
yang dapat digunakan untuk analisis resiko diwaktu mendatang.
Kesimpulan
Banyak hal yang mengendalikan proyek software tetapi akal sehat
menentukan analisis resiko. Waktu yang digunakan untuk mengidentifikasi,
menganalisis, dan mengatur resiko dalam beberapa cara, dapat
mengkibatkan kehebohan saat proyek berlangsung, kemampuan
bertambah untuk menelusuri dan mengontrol proyek, konfidensi yang
muncul bersamaan dengan perencanaan untuk masalah sebelum masalah
itu terjadi.
Identifikasi, analisis, proyeksi, perkiraan, menejemen dan
monitoring semuanya butuh waktu, tetapi tetap berharga. “Jika anda
mengenali musuh dan mengenali diri sendiri, anda tidak perlu
mengkhawatirkan hasil dari ratusan pertempuran” menurut SunTzu,
jendral cina. Untuk manajer software maka resiko adalah musuhnya.
DAFTAR PUSTAKA
Wiegers, Karl E Know Your Enemy : Software Risk Management, Software
development magazine, oktober 1998.
Boehm Barry W, Software Risk Management : Principles and Practices
Pressman, Roger S, Software engineering, sixth edition, 2005
BIODATA PENULIS
Dwi Retnoningsih, adalah dosen tetap STMIK El Rahma Yogyakarta,
lahir di Sukoharjo 29 Mei 1975. Memperoleh gelar Sarjana Teknik, Jurusan
Manajemen Informatika dan Teknik Komputer dari Institut Sains dan
Teknologi Akprind Yogyakarta pada tahun 1999, Memperoleh gelar
Magister Teknik, dari Program Studi Teknik Informatika, Magister
Teknologi Informasi, Universitas Gadjah Mada Yogyakarta pada tahun
2008, Jabatan akademik Asisten Ahli, Minat keilmuan Teknologi Informasi.
14