MANAJEMEN RESIKO
Menurur Robert Charette dalam bukunya Software Engineering Risk Analysis and Management, resiko adalah : Pertama, resiko berhubungan dengan kejadian masa yang akan datang. Sekarang dan kemarin tidak mendapat perhatian aktif, karena kita telah mendapatkan apa yang telah kita tabur lewat sepak terjang di masa lalu. Kedua, bahwa resiko melibatkan perubahan, seperti dalam perubahan pikiran, pendapat, aksi atau tempat. Dan yang ketiga, resiko melibatkan pilihan dan ketidakpastian bahwa pilihan itu akan dilakukan.
Bila resiko dipertimbangkan dalam konteks rekayasa perangkat lunak, maka masa yang akan datang adalah perhatian kita mengenai :
1. Resiko apa yang menyebabkan proyek perangkat lunak menjadi serba salah ?
2. Bagaimana perubahan pada persyaratan pelanggan, teknologi pengembangan, komputer target, dan semua entitas lain yang berhubungan dengan proyek, mempengaruhi ketepatan waktu dan keberhasilan keseluruhan ?
3. Bagaimana banyak orang harus dilibatkan, berapa banyak penekanan pada kualitas yang dianggap memadai ?
Peter Drucker mengatakan “Meskipun tidak ada gunanya mencoba mengeliminasi resiko, dan sangat mungkin dipertanyakan bila kita mencoba meminimalkannya, sangat penting bahwa resiko yang diambil merupakan resiko yang tepat.” Sebelum kita mengidentifikasian “resiko yang benar” yang akan diambil selama menjalankan suatu proyek perangkat lunak, penting untuk mengidentifikasi semua resiko secara jelas.
STRATEGI RESIKO REAKTIF VS. PROAKTIF
RESIKO PERANGKAT LUNAK
Resiko selalu melibatkan dua karakteristik yaitu :
1. Ketidakpastian
Kejadian yang menandai resiko mungkin atau tidak mungkin terjadi, yaitu ada 100% resiko yang mungkin.
2. Rugi
Bila resiko menjadi realitas, akibat yang tidak diinginkan atau kerugian akan dialami.
Ada beberapa Kategori resiko yaitu :
1. Resiko Proyek
Resiko proyek mengancam rencana proyek. Yaitu bila resiko proyek menjadi nyata, ada kemungkinan jadwal proyek akan mengalami slip dan bahwa biaya menjadi bertambah. Resiko proyek mengidentifikasi hal potensial yang berhubungan dengan pembiayaan, jadwal, personil, sumber-sumber daya, pelanggan dan masalah persyaratan serta pengaruhnya terhadap proyek perangkat lunak.
2. Resiko Teknis
Resiko teknis mengancam kualitas dan ketepatan waktu perangkat lunak yang akan dihasilkan. Bila resiko teknis menjadi kenyataan, implementasinya menjadi sangat sulit atau tidak mungkin. Resiko teknis mengidentifikasi desain potensial, implementasi, interfecing, verifikasi dan masalah pemeliharaan.
3. Resiko Bisnis
Resiko bisnis mengancam viabilitas perangkat lunak yang akan dibangun. Resiko bisnis membahayakan proyek atau produk. Adapun lima resiko bisnis utama yaitu :
* Pembangunan produk atau system yang baik sekali yang sebenarnya tidak pernah diinginkan oleh setiap orang (resiko pasar).
* Pembangunan sebuah produk yang tidak lagi sesuai dengan keseluruhan strategi bisnis bagi perusahaan (resiko strategi)
* Pembangunan sebuah produk di mana bagian pemasaran tidak tahu bagaimana harus menjualnya
* Kehilangan dukungan manajemen senior sehubungan dengan perubahan pada focus atau perubahan pada manusia (resiko manajemen)
* Kehilangan hal-hal yang berhubungan dengan biaya atau komitment personal (resiko manajemen)
Sedangkan resiko yang diusulkan oleh Charette adalah :
1. Resiko yang sudah diketahui adalah resiko yang dapat diungkap setelah dilakukan evaluasi secara hati-hati terhadap rencana proyek, bisnis, dan lingkungan teknik dimana proyek sedang dikembangkan dan sumber informasi reliable lainnya.
2. Resiko yang dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya.
3. Resiko yang tidak diharapkan dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.
IDENTIFIKASI RESIKO
Identifikasi resiko adalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek. Dengan mengidentifikasian resiko yang sudah diketahui dan dapat diprediksi, manajer proyek mengambil langkah pertama ke depan untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap saat diperlukan.
Metode untuk mengidentifikasi resiko adalah menciptakan checklist item resiko. Checklist dapat digunakan pada identifikasi resiko dan berfokus pada beberapa himpunan bagian resiko yang sudah diketahui dan diprediksi dalam sub kategori berikut ini :
1. Ukuran produk
Resiko sehubungan dengan keseluruhan ukuran perangkat lunak yang akan dibangun atau dimodifikasi. Check list item resiko yang berhubungan dengan ukuran produk adalah :
* Ukuran produk diperkirakan dalam LOC atau FP ?
* Tingkat kepercayaan dalam estimasi ukuran yang diperkirakan ?
* Ukuran produk yang diestimasi dalam jumlah program, file dan transaksi ?
* Presentase deviasi dalam ukuran produk dari rata-rata produk terakhir ?
* Ukuran database yang dibuat atau digunakan oleh produk ?
* Jumlah pemakai produk ?
* Jumlah perubahan yang diproyeksikan ke persyaratan produk ? sebelum penyampaian ? setelah penyampaian ?
* Jumlah perangkat lunak yang digunakan kembali ?
2. Pengaruh bisnis
Resiko sehubungan dengan batasan yang dibebankan oleh manajemen atau pasar. Check list item resiko yang berhubungan dengan pengaruh bisnis adalah
* Pengaruh produk terhadap hasil perusahaan ?
* Visibilitas produk terhadap manajemen senior ?
* Kelayakan deadline penyampaian ?
* Jumlah pelanggan yang akan menggunakan produk dan konsistensi kebutuhan relative mereka dengan produk tersebut ?
* Jumlah produk/system lain dengan apa produk ini harus dapat saling dioperasikan ?
* Kepintaran pemakai akhir ?
* Jumlah dan kualitas dokumentasi produk yang harus diproduksi dan disampaikan kepada pelanggan ?
* Batasan pemerintahan pada konstruksi produk ?
* Biaya yang berhubungan dengan penyampaian yang terlambat ?
* Biaya yang berhubungan dengan produk detektif ?
3. Karakteristik pelanggan
Resiko sehubungan dengan kepintaran pelanggan dan kemampuan pengembang untuk berkomunikasi dengan pelanggan dengan cara yang tepat. Semua pelanggan tidak diciptakan sama. Pressman dan Herron menyatakan bahwa :
* Pelanggan mempunyai keinginan yang berbeda. Beberapa tahu apa yang mereka inginkan; yang lainnya tahu apa yang tidak mereka inginkan. Banyak pelanggan mau merinci detailnya, sementara yang lain dapat dipuaskan dengan janji-janji kosong.
* Pelanggan memiliki kepribadian yang berbeda. Beberapa menikmatinya sebagai pelanggan - tekanan, negosiasi, penghargaan psikologis dari suatu produk yang baik. Sementara lainnya tidak ingin menjadi pelanggan sama sekali.
* Pelanggan juga memiliki hubungan yang bervariasi dengan pemasok mereka. Beberapa mengenali produk dan produser secara baik; yang lainnya mungkin tidak, hanya berkomunikasi dengan produser melalui surat atau korespondensi serta beberapa melalui telepon.
* Pelanggan juga kadang-kadang bertentangan. Mereka menginginkan semua yang sudah ada kemarin secara gratis. Sering para pelanggan terperangkap di antara kontradisksi di dalam diri mereka sendiri.
Checklist item resiko yang mengidentifikasi resiko-resiko yang berhubungan dengan para pelanggan yang berbeda adalah :
* Pernahkan anda sebelumnya bekerja dengan pelanggan ?
* Apakah pelanggan memiliki gagasan yang solid mengenai apa yang diperlukannya ? sudahkah pelanggan menggunakan waktunya untuk menuliskannya ?
* Apakah pelanggan akan setuju dengan penggunaan waktu di dalam pertemuan pengumpulan persyaratan formal untuk mengidentifikasi ruang lingkup proyek?
* Apakah pelanggan bersedia membangun sambungan komunikasi cepat dengan pengembang ?
* Apakah pelanggan bersedia berpartisipasi dalam kajian ?
* Apakah pelanggan secara teknis pandai dalam area produk tersebut ?
* Apakah pelanggan bersedia membiarkan orang-orang melakukan pekerjaan mereka?
* Apakah pelanggan memahami proses perangkat lunak tersebut ?
4. Definisi proses
Resiko sehubungan dengan tingkat di mana proses perangkat lunak telah didefinisikan dan diikuti oleh organisasi pengembangan. Adapun masalah-masalah dalam proses :
* Apakah manajemen senior anda mendukung suatu pernyataan kebijaksanaan yang menekankan pentingnya suatu proses standar untuk pengembangan proses ?
* Sudahkah 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 ?
* Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian kursus pelatihan rekayasa perangkat lunak bagi para manajer dan staf teknik ?
* Apakah standar rekayasa perangkat lunak yang diterbitkan disediakan untuk setiap pengembangan perangkat lunak dan manajer perangkat lunak ?
* Sudahkah dokumen outline dan contoh-contoh dikembangkan untuk semua yang ditentukan sebagai bagian yang dapat disampaikan sebagai bagian dari proses perangkat lunak ?
* Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain dan kode dilakukan secara regular ?
* Apakah kajian teknis formal terhadap prosedur pengujian dan test case dilakukan secara reguler ?
* Apakah hasil dari masing-masing kajian teknis formal didokumentasikan, termaksud kesalahan yang ditemukan dan sumber daya yang digunakan ?
* Apakah mekanisme untuk memastikan bahwa kerja yang dilakukan pada suatu proyek sesuai dengan standar rekayasa perangkat lunak ?
* Apakah manajemen konfigurasi digunakan untuk memelihara konsistensi diantara system/persyaratan perangkat lunak, desain, kode dan test case ?
* Apakah digunakan suatu mekanisme untuk mengontrol perubahan ke persyaratan pelanggan yang memperngaruhi perangkat lunak ?
* Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan dan rencana pengembangan perangkat lunak yang didokumentasikan untuk masing-masing subkontrak ?
* Apakah ada prosedur untuk menelusuri dan mengkaji kinerja subkontrak ?
Masalah-masalah teknis
* Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi di antara pelanggan dan pengembang ?
* Apakah metode spesifik digunakan untuk analisis perangkat lunak ?
* Apakah anda melihat suatu metode spesifik untuk data dan desain arsitektur?
* Apakah lebih dari 90 persen dari kode anda ditulis dengan bahasa orde yang lebih tinggi ?
* Apakah konvensi spesifik untuk dokumentasi kode didefiniskan dan digunakan ?
* Apakah anda menggunakan metode spesifik untuk desain test case ?
* Apakah digunakan peranti lunak untuk mendukung perencanaan dan aktivitas penelusuran ?
* Apakah digunakan peranti perangkat lunak manajemen konfigurasi untuk mengontrol dan menelusuri aktivitas perubahan di seluruh proses perangkat lunak ?
* Apakah digunakan peranti perangkat lunak untuk mendukung analisis perangkat lunak dan desain proses ?
* Apakah digunakan peranti untuk menciptakan prototipe perangkat lunak ?
* Apakah digunakan peranti perangkat lunak untuk mendukung proses pengujian ?
* Apakah peranti perangkat lunak digunakan untuk mendukung produksi dan manajemen dokumentasi ?
* Apakah metrik kualitas dikumpulkan bagi semua proyek perangkat lunak ?
* Apakah metrik produktivitas dikumpulkan bagi semua proyek perangkat lunak ?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah tidak, maka proses perangkat lunak lemah dan berisiko tinggi.
5. Lingkungan pengembangan
Resiko sehubungan dengan keberadaan dan kualitas peranti yang akan digunakan untuk membangun produk. Lingkungan proses perangkat lunak mendukung tim proyek, proses dan produk. Lingkungan yang salah dapat menjadi sumber resiko yang penting. Adapun checklist item yang berhubungan dengan lingkungan pengembangan :
* Apakah peranti manajemen proyek dapat diperoleh ?
* Apakah peranti manajemen proses dapat diperoleh ?
* Apakah peranti untuk analisis dan desain dapat diperoleh ?
* Apakah peranti analisis dan desain penyampaian metode sesuai bagi produk yang akan dibangun ?
* Apakah kompiler atau generasi kode dapat diperoleh sesuai untuk produk yang akan dibangun ?
* Apakah peranti pengujian dapat diperoleh dan sesuai dengan produk yang akan dibangun ?
* Apakah peranti manajemen konfigurasi perangkat lunak dapat diperoleh ?
* Apakah lingkungan menggunakan suatu database atau tempat penyimpanan ?
* Apakah semua peranti perangkat lunak diintegrasikan satu dengan lainnya ?
* Sudahkah anggota tim proyek menerima pelatihan dengan masing-masing peranti ?
* Apakah ada pakar lokal untuk menjawab pertanyaan-pertanyaan mengenai peranti tersebut ?
* Apakah bantuan dan dokumentasi on line bagi peranti memadai ?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah tidak, berarti lingkungan pengembangan perangkat lunak lemah dan beresiko tinggi.
6. Teknologi yang akan dibangun
Resiko sehubungan dengan komplesitas system yang akan dibangun dan kebaruan teknologi yang dikemas oleh system. Checklist item resiko yang berhubungan dengan teknologi yang akan dibangun adalah :
* 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 berinterface dengan perangkat keras baru atau belum terbukti ?
* Apakah perangkat lunak yang akan dibangun berinterface dengan produk perangkat lunak yang dipasok oleh vendor yang belum terbukti ?
* Apakah perangkat lunak yang akan dibangun berinterface dengan suatu sistem database yang fungsi dan kinerjanya belum dibuktikan di dalam area aplikasi ini ?
* Apakah diperlukan interface pemakai khusus oleh persyaratan produk ?
* Apakah persyaratan untuk produk memerlukan kreasi komponen program yang tidak sama dengan yang dikembangkan terakhir oleh organisasi anda ?
* Apakah persyaratan memerlukan pemakaian analisis, desain, atau metode pengujian baru ?
* Apakah persyaratan memerlukan metode pengembangan perangkat lunak tidak konvensional, seperti metode formal, pendekatan AI based, dan jaringan saraf buatan.
* Apakah persyaratan meletakan batasan kinerja yang efektif pada produk tersebut?
* Apakah pelanggan tidak yakin bahwa fungsionalitas yang diminta dapat dilakukan?
Bila jawaban dari pertanyaan-pertanyaan di atas adalah ya, penyelidikan lebih lanjut harus dilakukan untuk memperkirakan resiko potensial.
7. Ukuran dan pengalaman staf - resiko sehubungan dengan keseluruhan teknik dan pengalaman proyek dari perekayasa perangkat lunak yang akan melakukan tugas tersebut. Checklist item resiko yang berhubungan dengan ukuran staf dan pengalaman adalah :
* Apakah orang-orang terbaik dapat didapatkan ?
* Apakah orang-orang tersebut memiliki gabungan keterampilan yang benar ?
* Apakah orang-orang yang ada mencukupi ?
* Apakah staf dimasukkan ke dalam seluruh durasi proyek ?
* Akankah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini ?
* Apakah staf memiliki pengharapan yang tepat mengenai pekerjaan yang ada sekarang ?
* Sudahkah staf menerima pelatihan yang memadai ?
* Apakah pergantian di antara staf akan cukup rendah untuk memungkinkan kontinuitas ?
Bila jawaban terhadap pertanyaan-pertanyaan tersebut adalah tidak, maka penyelidikan lebih lanjut harus dilakukan untuk memperkirakan resiko potensial.
KOMPONEN RESIKO DAN DRIVER
Manajer proyek mengidentifikasi resiko driver yang mempengaruhi komponen resiko perangkat lunak. Adapun komponen resiko didefinisikan dengan cara :
1. Resiko kinerja - tingkat ketidakpastian di mana produk akan memenuhi persyaratannya dan cocok dengan penggunaannya.
2. Resiko biaya - tingkat ketidakpastian di mana biaya produk akan dijaga
3. Resiko dukungan - tingkat ketidakpastian di mana perangkat lunak akan mudah dikoreksi, disesuaikan dan ditingkatkan
4. Resiko jadwal - tingkat ketidakpastian di mana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu.
PROYEKSI RESIKO
Proyeksi resiko disebut juga perkiraan resiko, berusaha menjangkau setiap resiko dalam dua cara - kemungkinan atau probablititas di mana resiko adalah nyata dan konseskuensi masalah yang berhubungan dengan resiko yang harus terjadi. Ada empat aktivitas proyeksi resiko yaitu :
1. Membangun suatu skala yang merefleksikan kemungkinan resiko yang dirasakan
2. Menggambarkan konsekuensi resiko
3. Memperkirakan pengaruh resiko pada proyek dan produk
4. Mencatat keseluruhan akurasi proyeksi resiko sehingga tidak akan ada kesalahpahaman
MENILAI PENGARUH RESIKO
Ada tiga faktor yang kemungkinan besar mempengaruhi konsekuensi jika suatu resiko benar-benar terjadi yaitu :
1. Sifat
2. Ruang lingkupnya
3. Timingnya
Berikut ini langkah-langkah yang direkomendasikan untuk menentukan konsekuensi keseluruhan dari suatu resiko :
1. Tentukan probabilitas rata-rata dari kejadian untuk masing-masing komponen resiko
2. Dengan menggunakan tabel resiko, tentukan pengaruh untuk masing-masing komponen berdasarkan kriteria yang diperlihatkan
3. Lengkapi tabel resiko dan analisis hasilnya.
PENILAIAN RESIKO
Rumus untuk penilaian resiko : [ri,li,xi]
Dimana ri adalah resiko, li adalah kemungkinan dan xi adalah pengaruh dari resiko tersebut. Selama penilaian resiko, lebih jauh kita harus menguji akurasi estimasi yang dibuat selama proyeksi resiko, berusaha memprioritaskan resiko yang diungkap, dan mulai berpikir mengenai cara mengontrol dan atau mencegah resiko yang mungkin terjadi.
Selama penilaian resiko, kita melakukan langkah-langkah berikut :
1. Tentukan tingkat referen resiko 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. Cobalah memprediksi bagaimana penggabungan kombinasi resiko akan mempengaruhi suatu titik referen.
Tidak ada komentar:
Posting Komentar