2

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