BAB 6 - Openstorage Gunadarma
advertisement
Rekayasa Perangkat Lunak Pertemuan Ke 6 Manajemen Resiko 6.1. Strategi Risiko Reaktif VS Proaktif Strategi reaksi reaktif secara menggelikan disebut “sekolah manajemen risiko Indiana Jones”. Pada film tersebut, Indiana Jones, pada saat dihadapkan dengan bermacam-macam kesulitan akan tetap mengatakan, “jangan khawatir, aku akan memikirkan sesuatu!” Tidak pernah mengkhawatirkan masalah sampai mereka benar-benar terjadi, di mana Indi akan beraksi secara heroik. Sayangnya, rata-rata manajer proyek tidak seperti Indiana Jones. Mayoritas tim perangkat lunak hanya bersandar pada strategi reaktif. Pada titik terbaik, strategi reaktif memonitor proyek terhadap kemungkinan risiko. Strategi yang benar-benar lebih baik untuk manajemen risiko adalah bersikap proaktif. Strategi proaktif dimulai lama sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas dan pengaruh proyek diperkirakan, dan dirioritaskan menurut kepentingan. Tim perangkat lunak kemudian membangun suatu rencana untuk manajemen resiko. Sasarannya adalah menghindari resiko. 6.2. Risiko Perangkat Lunak Risiko selalu melibatkan dua karakteristik : Ketidakpastian – kejadian yang menandai risiko mungkin atau tidak mungkin terjadi; Rugi – bila risiko menjadi realitas, akibat yang tidak diinginkan atau kerugian akan dialami. Risiko proyek mengancam rencana proyek. Yaitu, bila risiko proyek menjadi nyata, ada kemungkinan jadwal proyek akan mengalami slip dan bahwa biaya menjadi bertambah. Lecture-Note Risiko proyek mengidentifikasi hal potensial yang Hall : 1 Rekayasa Perangkat Lunak berhubungan dengan pembiayaan, jadwal, personil (staffing dan organisasi), sumber-sumber daya, pelanggan dan masalah persyaratan serta pengaruhnya terhadap proyek perangkat lunak. Risiko teknis mengancam kualitas dan ketepatan waktu perangkat lunak yang akan dihasilkan. Risiko teknis mengidentifikasi desain potensial, implementasi, interfacing, verifikasi dan masalah pemeliharaan. Ambiguitas, spesifikasi, ketidakpastian teknik, keusangan teknik, dan teknologi yang leading edge juga merupakan faktor risiko. Risiko bisnis mengancam viabilitas perangkat lunak yang akan dibangun. Kandidat untuk lima risiko bisnis utama adalah : (1). Pembangunan produk atau sistem yang baik sekali yang sebenarnya tidak pernah diinginkan oleh setiap orang (risiko pasar); (2). Pembangun sebuah produk yang tidak lagi sesuai dengan keseluruhan strategis bisnis bagi perusahaan (risiko strategis); (3). Pembangunan sebuah produk di mana bagian pemasaran tidak tahu bagaimana harus menjualnya; (4). Kehilangan dukungan manajemen senior sehubungan dengan perubahan pada fokus atau perubahan pada manusia (risiko manajemen); (5). Kehilangan hal-hal yang berhubungan dengan biaya atau komitmen personal (risiko biaya). Kategori resiko umum lainnya telah diusulkan oleh Charette yaitu : Risiko yang sudah diketahui adalah risiko yang dapat diungkap setalh dilakukan evaluasi secara hati-hati terhadap rencana proyek, bisnis, dan lingkungan teknik di mana proyek sedang dikembangkan, dan sumber informasi reliabel lainnya (seperti tanggal penyampaian yang tidak realistis, kurangnya persyaratan yang terdokumentasi atau ruang lingkup perangkat lunak, lingkungan pengembangan yang buruk). Risiko yang dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya (misalnya, pergantian staf, komunikasi yang buruk dengan para pelanggan, mengurangi usaha staf bila permintaan pemeliharaan yang sedang Lecture-Note Hall : 2 Rekayasa Perangkat Lunak berlangsung dilayani). Risiko yang tidak diharapkan dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya. 6.3. Identifikasi Risiko Identifikasi risiko adalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek (perkiraan, jadwal, pemuatan sumber daya, dll). Ada dua tipe risiko yang berbeda : risiko generik dan risiko produk spesifik.. Risiko generik merupakan ancaman potensial pada setiap proyek perangkat lunak. Risiko produk spesifik hanya dapat diidentifikasi oleh mereka dengan pemahaman khusus mengenai teknologi tsb, manusia, serta lingkungan yang spesifik terhadap proyek yang ada. Tom Gilb menyatakan: “Bila anda tidak aktif menyerang risiko, maka risiko akan aktif menyerang anda.” Metode untuk mengidentifikasi risiko adalah menciptakan cheklist item risiko. Checklist dapat digunakan pada identifikasi risiko dan berfokus pada beberapa himpunan bagian risiko yang sudah diketahui dan diprediksi dalam sub kategori berikut ini : Ukuran produk – risiko sehubungan dengan keseluruhan ukuran perangkat lunak yang akan dibangun atau dimodifikasi. Pengaruh bisnis – risiko sehubungan dengan batasan yang dibebankan oleh manajemen atau pasar. Karakteristik pelanggan – risiko sehubungan dengan kepintaran pelanggan dan kemampuan pengembang untuk berkomunikasi dengan pelangan dengan cara yang tepat. Definisi proses – risiko sehubungan dengan tingkat di mana proses perangkat lunak telah didefinisikan dan diikuti oleh organisasi pengembangan. Lingkungan pengembang – risiko sehubungan dengan keberadaan dan kualitas peranti yang akan digunakan untuk membangun produk. Teknologi yang akan dibangun – risiko sehubungan dengan kompleksitas sistem yang akan dibangun dan “kebaruan” teknologi yang dikemas oleh sistem. Lecture-Note Hall : 3 Rekayasa Perangkat Lunak Ukuran dan pengalaman staf – risiko sehubungan dengan keseluruhan teknik dan pengalaman proyek dari rekayasa perangkat lunak yang akan melakukan tugas tersebut. 6.3.1. Risiko Ukuran Produk Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan ukuran produk (perangkat lunak) : Berapa ukuran produk diperkirakan dalam LOC atau FP? Ukuran produk yang diestimasi dalam jumlah program, file, transaksi? Ukuran database yang dibuat atau digunakan oleh produk? Jumlah pemakai produk? Jumlah perangkat lunak yang dipergunakan kembali? 6.3.2. Risiko-risko Yang Mempengaruhi Bisnis Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan pengaruh bisnis: Pengaruh produk terhadap hasil perusahaan? Kelayakan deadline penyampaian? Jumlah pelanggan yang akan menggunakan produk dan konsistensi kebutuhan relatif mereka dengan produk tersebut? Kepintaran pemakai akhir? Biaya yang berhubungan dengan penyampaian yang terlambat? 6.3.3. Risiko Yang Dihubungankan Dengan Pelanggan Semua pelanggan tidak diciptakan sama. Pressman dan Herron membahas masalah ini dengan menyatakan : Pelanggan mempunyai keinginan yang berbeda. Pelanggan memiliki kepribadian yang berbeda. Lecture-Note Hall : 4 Rekayasa Perangkat Lunak Pelanggan juga memiliki hubungan yang bervariasi dengan pemasok mereka. Pelanggan juga kadang-kadang bertentangan. Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan para pelanggan yang berbeda: Pernahkah anda sebelumnya bekerja dengan pelanggan? Apakah pelanggan memilki gagasan yang solid mengenai apa yang diperlukannya? Sudahkan pelanggan menggunakan waktunya untuk menuliskannya? Apakah pelanggan bersedia membangun sambungan komunikasi cepat dengan pengembang? Apakah pelanggan bersedia berpartisipasi dalam kajian? Apakah pelanggan memahami proses perangkat lunak tersebut? 6.3.4. Risiko Proses Contoh risiko yang berhubungan dengan masalah-masalah proses : Apakah manajemen senior anda mendukung suatu pernyataan kebijakan yang menekankan pentingnya suatu prses standar untuk pengembangan proses? Sudahkan organisasi anda mengembangkan suatu deskripsi tertulis mengenai proses perangkat lunak yang akan digunakan pada proyek ini? Apakah anggota-anggota staf “ditugasi” ke proses perangkat lunak pada saat perangkat lunak didokumentasi dan bersedia menggunakannya? Apakah proses perangkat lunak digunakan untuk proyek lain? Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain dan kode dilakukan secara reguler? Contoh risiko yang berhubungan dengan masalah-masalah teknis : Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi di antara pelanggan dan pengembang? Apakah metode spesifikasi digunakan untuk analisis perangkat lunak? Lecture-Note Hall : 5 Rekayasa Perangkat Lunak Apakah anda melihat suatu metode spesifik untuk data dan desain arsitektur? Apakah digunakan peranti perangkat lunak untuk mendukung perencanaan dan aktivitas penelusuran? Apakah metrik kualitas dikumpulkan bagi semua proyek perangkat lunak? 6.3.5. Risiko Teknologi Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan teknologi yang akan dibangun: Apakah teknologi yang akan dibangun adalah hal yang baru untuk organisasi anda? Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi input atau output? Apakah perangkat lunak ber-interface dengan perangkat keras baru atau belum terbukti? Apakah perangkat lunak yang akan dibangun ber-interface dengan produk perangkat lunak yang dipasok oleh vendor yang belum terbukti? Apakah perangkat lunak yang akan dibangun ber-interface dengan suatu sistem database yang fungsi dan kinerjanya belum dibuktikan di dalam area aplikasi ini? 6.3.6. Risiko Lingkungan Pengembang Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan lingkungan pengembang: Apakah peranti manajemen proyek dapat diperoleh? Apakah peranti manajemen proses dapat diperoleh Apakah peranti untuk analisis dan desain dapat diperoleh? Apakah kompiler atau pembangkit kode dapat diperoleh dan sesuai untuk produk yang akan dibangun? Lecture-Note Hall : 6 Rekayasa Perangkat Lunak Sudahkan anggota tim proyek menerima pelatihan dengan masing-masing peranti? 6.3.7. Risiko Yang Berhubungan Dengan Ukuran Staf Dan Pengalaman Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan ukuran staf dan pengalaman (diusulkan Boehm): Apakah orang-orang terbaik dapat didapatkan? Apakah orang-orang tsb memiliki gabungan ketrampilan yang benar? Apakah orang-orang yang ada mencukupi? Akankah banyak staf proyek bekerja dalam paruh waktu pada proyek ini? Sudahkan staf menerima pelatihan yang memadai? 6.3.8. Komponen Risiko Dan Driver Komponen risiko didefinisikan dengan cara berikut : Risiko kinerja – tingkat ketidakpastian di mana produk akan memenuhi persyaratannya dan cocok dengan penggunaannya. Risiko biaya – tingkat ketidakpastian di mana biaya proyek akan dijaga. Risiko dukungan – tingkat ketidakpastian di mana perangkat lunak akan mudah dikoreksi, disesuaikan dan ditingkatkan. Risiko jadwal – tingkat ketidakpastian di mana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu. Pengaruh driver risiko terhadap komponen risiko dibagi ke dalam satu dari empat kategori pengaruh – diabaikan, marjinal, kritis dan katastropis. 6.4. Proyeksi Risiko Proyeksi risiko yang disebut juga perkiraan risiko, berusaha menjangkau setiap risiko dalam dua cara – kemungkinan atau probabilitas di mana risiko adalah nyata dan konsekuensi masalah yang berhubungan dengan risiko, yang harus Lecture-Note Hall : 7 Rekayasa Perangkat Lunak terjadi. Perencana proyek bersama dengan manajer dan staf teknik lain, melakukan empat aktivitas proyeksi risiko : (1) membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan; (2) menggambarkan konsekuensi risiko (3) memperkirakan pengaruh risiko pada proyek dan produk (4) mencatat keseluruhan akurasi proyeksi risiko sehingga tidak akan ada kesalahpahaman. 6.4.1. Mengembangkan Tabel Risiko Tabel risiko memberi manajer proyek sebuah teknik sederhana bagi proyeksi risiko. Tabel risiko sampel ditunjukkan pada gambar 6.2. Risiko Kategori Prob. Pengaruh RMMM Estimasi ukuran rendah secara signifikan PS 60% 2 Jumlah pemakai lebih besar dari yang PS 30% 3 lebih rendah dari yang PS 70% 2 Pemakai akhir menolak sistem BU 40% 3 Deadline pengiriman akan diperketat BU 50% 2 Pendanaan dihapuskan CU 40% 1 Pelanggan akan mengubah kebutuhan PS 80% 2 Teknologi tidak memenuhi harapan TE 30% 1 Kurangnya pelatihan pada peranti DE 80% 3 Staf tidak berpengalaman ST 30% 2 Turnover staf tinggi ST 60% 2 diharapkan Pemakaian ulang diharapkan Dst Nilai pengaruh 1 – katastropis 2 – kritis 3 – marjinal 4 – dapat diabaikan Gambar 6.2. Contoh tabel risiko yang mengutamakan pengertian Lecture-Note Hall : 8 Rekayasa Perangkat Lunak Begitu empat kolom yang pertama dari tabel risiko telah diselesaikan maka tabel itu diurutkan sesuai probabilitas dan pengaruhnya. Probabilitas yang tinggi, risiko pengaruh yang tinggi menapis ke puncak tabel, dan risiko probabilitas rendah jatuh ke dasar. Dengan demikian prioritasisasi risiko urutan pertama dapat diselesaikan. Driver risiko dapat diperkirakan pada skala probabilitas kualitatif yang memiliki nilai sebagai berikut : impossible, improbable, probable, dan frekuen. Probabilitas matematis kemudian dapat dikaitkan dengan masing-masing nilai kualitatif (misalnya, suatu probabilitas 0,7 sampai 1,0 implikasikan risiko yang sangat mungkin). 6.4.2. Menilai Pengaruh Risiko Ada tiga faktor yang kemungkinan besar mempengaruhi konsekuensi jika suatu risiko benar-benar terjadi : sifatnya, ruang lingkupnya, dan timingnya. Sifat dari risiko menunjukkan masalah yang mungkin muncul bila ia terjadi. Ruang lingkup dari suatu risiko menggabungkan kepelikannya (seberapa serius hal ini?) dengan keseluruhan distribusi (berapa banyak proyek akan dipengaruhi atau berapa banyak pelanggan yang akan terganggu?). Akhirnya, timing dari suatu risiko mempertimbangkan kapan dan untuk berapa lama pengaruh itu akan dirasakan. Langkah-langkah berikut ini direkomendasikan untuk menentukan konsekuensi keseluruhan dari suatu risiko : 1. Tentukan probabilitas rata-rata dari nilai kejadian untuk masing-masing komponen risiko. 2. Dengan menggunakan gambar 6.2, tentukan pengaruh untuk masing-masing komponen berdasarkan kriteria yang diperlihatkan. 3. Lengkapi tabel risiko dan analisis hasilnya seperti digambarkan pada subbab sebelumnya. Lecture-Note Hall : 9 Rekayasa Perangkat Lunak 6.4.3. Penilaian Risiko Agar penilaian bermanfaat, tingkat referens risiko harus ditentukan. Untuk sebagian besar proyek perangkat lunak, komponen risiko yang dibicarakan sebelumnya – kinerja, biaya, dukungan dan jadwal – juga mencerminkan tingkat referensi risiko. Tingkat referens risiko adalah tingkat degradasi kinerja, pembengkakan biaya, kesulitan dukungan, dan melesetnyajadwal, yang akan menyebabkan proyek diterminasi.Jika kombinasi risiko menciptakan masalah yang menyebabkan satu atau lebih dari tingkat referen itu terlampaui, kerja akan terhenti. Dalam konteks analisis risiko perangkat lunak, tingkat referen risiko memilki titik tunggal, yang disebut referent point atau break point, di mana keputusan untuk meneruskan proyek atau menghentikannya sama-sama dapat diterima. Selama penilaian risiko, kita melakukan langkah-langkah berikut : 1. Tentukan tingkat referen risiko untuk proyek. 2. Usahakan untuk mengembangkan hubungan antara masing-masing[ri, li, xi] dan masing-masing tingkat referen. 3. Prediksikan himpunan titik referen yang menentukan daerah terminasi, dibatasi oleh kurva atau area ketidakpastian. 4. Cobalah memprediksi bagaimana penggabungan kombinasi risiko akan mempengaruhi suatu titik referen. 6.5. Pengurangan, Monitoring, Dan Manajemen Risiko Semua aktivitas analisis risiko yang disajikan pada titik ini memiliki satu tujuan tunggal – membantu tim proyek dalam mengembangkan strategi yang berkaitan dengan risiko. Strategi yang efektif harus memiliki tiga gagasan berikut : Menghindari risiko Monitoring risiko Manajemen risiko dan perencanaan kemungkinan Lecture-Note Hall : 10 Rekayasa Perangkat Lunak Pada saat proyek berjalan, aktivitas pemonitoran risiko dimulai. Manajer proyek memonitor faktor-faktor yang dapat memberikan suatu indikasi apakah risiko sedang menjadi lebih atau kurang mungkin. Dalam kasus turnover staf tinggi, faktor-faktor berikut dapat dimonitor : Sikap umum anggota tim berdasarkan tekanan proyek. Tingkat di mana tim disatu-padukan. Hubungan interpersonal di antara anggota tim. Masalah potensial dengan kompensasi dan manfaat. Keberadaan pekerjaan di dalam perusahaan dan di luarnya. 6.6. RMMM Plan Strategi manajemen risiko dapat dimasukkan dalam rencana proyek perangkat lunak; atau, langkah manajemen risiko dapat diatur ke dalam Risk Mitigating, monitoring, and Management Plan (RMMM Plan) yang terpisah. RMMM Plan mendokumentasi semua kegiatan yang dilakukan sebagai bagian dari analisis risiko dan digunakan oleh manajer proyek sebagai bagian dari keseluruhan Rencana Proyek. Uraian untuk RMMM Plan adalah sebagai berikut: I. Pengantar 1. Lingkup dan tujuan dokumen 2. Tinjauan risiko utama 3. Tanggung jawab a. Manajemen b. Staf teknis II. Tabel Risiko Proyek 1. Deskripsi semua risiko di atas yang ditentukan 2. Faktor-faktor yang mempengaruhi probabilitas dan pengaruh III. Pengurangan, Monitoring, dan Manajemen Risiko 1. Risiko 2. Pengurangan a. Strategi umum Lecture-Note Hall : 11 Rekayasa Perangkat Lunak b. Langkah khusus untuk mengurangi risiko 3. Monitoring a. Faktor-faktor yang dimonitor b. Pendekatan monitoring 4. Manajemen a. Rencana kontingensi b. Konsiderasi khusus IV. Jadwal Iterasi Rencana RMMM V. Kesimpulan Lecture-Note Hall : 12
