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
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 proyeksoftware.
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).”
memuaskan dan nilai kerugian yang diakibatkan jika hasil tersebut benar tidak diinginkan/tidak memuaskan. Dimana hasil yang tidak diinginkan berhubungan dengancustomer, developer, userdanmaintainer.
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 environtmentdan 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.
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 denganrecognizing / 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 PracticesolehBarry 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
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 :
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 requirementdari batasansoftware, lingkungan pengembang yang buruk). 5. Predictable risk (resiko yang telah diprediksi), resiko dari pengalaman
proyek yang sebelumnya (perubahan staf, kurangnya komunikasi dengancustomer)
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 sub-kategori berikut :
1. Ukuran produk : resiko yang berhubungan dengan keseluruhan dari ukuransoftwareyang 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 customerdan kemampuan pengembang dengancustomerpada waktu yang tepat.
Customer tidak diciptakan sama semua. Menurut Pressman dan Herron menyatakan :
Customermemiliki keinginan yang berbeda. Beberapa ada yang tahu apa yang mereka inginkan dan yang lain tahu apa yang tidak mereka inginkan.
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.
4. Proses pendefinisian : resiko yang berhubungan denganlevel dari proses software yang telah didefinisikan dan disesuaikan dengan organisasi pengembang.
5. 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.
6. 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.
7. Ukuran dan pengalaman staf : resiko yang berhubungan dengan keseluruhan pengalaman teknik dan proyek darisoftware 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 proyeksoftware. 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 Listerterdapat 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 menambahsetting-an yang diterima pada permulaan.
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 resikosoftwareyaitu :
1. Shortfallspersonal
2. Penjadwalan dan pembiayaan yang tidak masuk akal 3. Mengembangkan fungsi dan properti yang salah 4. Mengembangkaninterfacepengguna
5. Gold-plating
6. Melanjutkan alur dari perubahanrequirement 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 men-supportproyek?
2. Apakah pengguna terakhir terkait pada proyek dan sistem yang akan dibuat?
3. Apakah requirement benar–benar dimengerti oleh tim ahli software dancustomer?
4. Apakahcustomerikut terlibat pebuh pada definisi danrequirement? 5. Apakah pengguna terakhir memiliki pengharapan yang realistik? 6. Apakah ruang lingkup proyek stabil?
7. Apakah tim ahlisoftwarememiliki penggabungan skill yang baik? 8. Apakanrequirementproyek stabil?
9. Apakah tim proyek memilki pengalaman dengan teknologi yang akan diimplementasikan?
10. Apakah jumlah orang dalam proyek mampu mengerjakan tugas? 11. Apakan semuacustomer/ pengguna setuju dengan yang penting dari
proyek danrequirementdari sistem yang akan dibuat?
Komponen Resiko danDriver
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 denganrequirementdan 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 pengaruhdriveryaitu 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 :
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.
P adalah kemungkinan terjadi dari resiko.
C adalah biaya dari proyek bila resiko benar terjadi .
Menurut Software Risk Management : Principles and Practicesoleh Barry W. Boehm,bahwarisk exposure(RE) memiliki relasi berikut :
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.
RE = P * C
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 olehcustomer. 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 mempengaruhisoftwaresecara negatif, dan keseluruhan sistem bisa gagal. Bila bahaya telah teridentifikasi dari awal proses rekayasa, maka ciri–ciri desainsoftwaredepat ditentukan, dan itu akan mengeliminasi atau mengontrol bahaya potensial.
RMMM Plan
Strategi menejemen resiko dapat dimasukkan dalam rencana proyek softwareatau 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.
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 manajersoftwaremaka 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
