Manajemen risiko adalah proses pengukuran atau pencilling risiko serta pengembangan strategi pengelolaannya. Strategi yang dapat diambil antara lain adalah memindahkan risiko kepada pihak lain (risk transfer), menghindari risiko (risk averse), mengurangi efek negatif risiko (mitigate), dan menampung sebagian atau semua konsekuensi risiko tertentu. Manajemen risiko tradisional terfokus pada risiko-risiko yang timbul oleh penyebab fisik atau legal (seperti bencana alam atau kebakaran, kematian serta tuntutan hukum).
Manajemen risiko adalah rangkaian langkah-langkah yang membantu suatu perangkat lunak untuk memahami dan mengatur ketidak pastian.
Pada saat kita mengerjakan pengembangan perangkat lunak sering kita menghadapi berbagai situasi yang tidak nyaman seperti keterlambatan pengembangan atau pengeluaran biaya pengembangan yang melebihi anggaran. Hal ini dikarenakan kurang siapnya kita menghadapi berbagai kemungkinan risiko yang akan terjadi. Untuk itu perlu dilakukan identifikasi tindakan yang harus dilakukan untuk mencegah ataupun meminimalkan risiko tersebut.
Mengapa manajemen risiko itu penting? Sikap orang ketika menghadapi risiko berbeda-beda. Ada orang yang berusaha untuk menghindari risiko, namun ada juga yang sebaliknya sangat senang menghadapi risiko sementara yang lain mungkin tidak terpengaruh dengan adanya risiko. Pemahaman atas sikap orang terhadap risiko ini dapat membantu untuk mengerti betapa risiko itu penting untuk ditangani dengan baik.
Beberapa risiko lebih penting dibandingkan risiko lainnya. Baik penting maupun tidak sebuah risiko tertentu bergantung pada sifat risiko tersebut, pengaruhnya pada aktifitas tertentu dan kekritisan aktifitas tersebut. Aktifitas berisiko tinggi pada jalur kritis pengembangan biasanya merupakan penyebabnya.
Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk meminimalkan risiko atau paling tidak mendistribusikannya selama pengembangan tersebut dan idealnya risiko tersebut dihapus dari aktifitas yang mempunyai jalur yang kritis.
Risiko dari sebuah aktifitas yang sedang berlangsung sebagian bergantung pada siapa yang mengerjakan atau siapa yang mengelola aktifitas tersebut. Evaluasi risiko dan alokasi staf dan sumber daya lainnya erat kaitannya.
Risiko dalam perangkat lunak memiliki dua karakteristik:
- Uncertainty : tidak ada risiko yang 100% pasti muncul.
- Loss : risiko berimbas pada kehilangan.
Dan risiko memiliki tiga kategori:
- Risiko proyek : berefek pada perencanaan proyek.
- Risiko teknikal : berefek pada kualitas dan waktu pembuatan perangkat lunak.
- Risiko bisnis : berefek pada nilai jual produk.
Langkah-langkah dalam manajemen proses adalah :
Identifikasi risiko
Proses ini meliputi identifikasi risiko yang mungkin terjadi dalam suatu aktivitas usaha. Identifikasi risiko secara akurat dan komplit sangatlah vital dalam manajemen risiko. Salah satu aspek penting dalam identifikasi risiko adalah mendaftar risiko yang mungkin terjadi sebanyak mungkin. Teknik-teknik yang dapat digunakan dalam identifikasi risiko antara lain:
Brainstorming
Survei
Wawancara
Informasi histori
Kelompok kerja
Tipe-tipe risiko:
Untuk keperluan identifikasi dan mengelola risiko yang dapat menyebabkan sebuah pengembangan melampaui batas waktu dan biaya yang sudah dialokasikan maka perlu diidentifikasikan tiga tipe risiko yang ada yaitu:
Risiko yang disebabkan karena kesulitan melakukan estimasi.
Risiko yang disebabkan karena asumsi yang dibuat selama proses perencanaan.
Risiko yang disebabkan adanya even yang tidak terlihat (atau tidak direncanakan).
Beberapa kategori faktor yang perlu dipertimbangkan adalah sebagai berikut:
Application Factor
Sesuatu yang alami dari aplikasi baik aplikasi pengolahan data yang sederhana, sebuah sistem kritis yang aman maupun sistem terdistribusi yang besar dengan elemen real time terlihat menjadi sebuah faktor kritis. Ukuran yang diharapkan dari aplikasi juga sesuatu yang penting – sistem yang lebih besar, lebih besar dari masalah error, komunikasi dan manajemennya.
Staff Factor
Pengalaman dan kemampuan staf yang terlibat merupakan faktor utama – seorang programer yang berpengalaman, diharapkan akan sedikit melakukan kesalahan dibandingkan dengan programer yang sedikit pengalamannya. Akan tetapi kita harus juga mempertimbangkan ketepatan pengalaman tersebut- pengalaman membuat modul dengan Cobol bisa mempunyai nilai kecil jika kita akan mengembangkan sistem kendali real-time yang komplek dengan mempergunakan C++.
Beberapa faktor seperti tingkat kepuasan staf dan tingkat pergantian dari staf juga penting untuk keberhasilan sebarang pengembangan – staf yang tidak termotivasi atau person utama keluar dapat menyebabkan kegagalan pengembangan.
Project Factor
Merupakan hal yang penting bahwa pengembangan dan obyektifnya terdefinisi dengan baik dan diketahui secara jelas oleh semua anggota tim dan semua stakeholder utama. Jika hal ini tidak terlaksana dapat muncul risiko yang berkaitan dengan keberhasilan pengembangan tersebut. Dengan cara serupa, perencanaan kualitas yang formal dan telah disepakati harus dipahami oleh semua partisipan. Jika perencanaan kualitas kurang baik dan tidak tersosialisasi maka dapat mengakibatkan gangguan pada pengembangan tersebut.
Project Methods
Dengan mempergunakan spefikasi dan metode terstruktur yang baik pada manajemen pengembangan dan pengembangan sistem akan mengurangi risiko penyerahan sistem yang tidak memuaskan atau terlambat. Akan tetapi penggunaan metode tersebut untuk pertama kali dapat mengakibatkan problem dan delay.
Hardware/software Factor
Sebuah pengembangan yang memerlukan hardware baru untuk pengembangan mempunyai risiko yang lebih tinggi dibandingkan dengan software yang dapat dibangun pada hardware yang sudah ada (dan familiar). Sebuah sistem yang dikembangkan untuk satu jenis hardware atau software platform tertentu jika dipergunakan pada hardware atau software platform lainnya bisa menimbulkan risiko tambahan (dan tinggi) pada saat instalasi.
Changeover Factor
Kebutuhan perubahan “all-in-one” kedalam suatu sistem baru mempunyai risiko tertentu. Perubahan secara bertahap atau gradual akan meminimisasi risiko akan tetapi cara tersebut tidak praktis. Menjalankan secara paralel dapat memberikan solusi yang aman akan tetapi biasanya tidak mungkin atau terlalu mahal.
Supplier Factor
Suatu pengembangan yang melibatkan organisasi eksternal yang tidak dapat dikendalikan secara langsung dapat mempengaruhi keberhasilan pengembangan. Misal tertundanya instalasi jalur telpon atau pengiriman peralatan yang sulit dihindari- dapat berpengaruh terhadap keberhasilan pengembangan.
Environment Factor
Perubahan pada lingkungan dapat mempengaruhi keberhasilan pengembangan. Misal terjadi perubahan regulasi pajak, akan mempunyai dampak yang cukup serius pada pengembangan aplikasi penggajian.
Health and Safety Factor
Ada satu isu utama yaitu faktor kesehatan dan keamanan dari partisipan yang terlibat dalam pengembangan software walaupun tidak umum (dibandingkan dengan pengembangan teknik sipil) yang dapat mempengaruhi aktifitas pengembangan.
Kesalahan estimasi
Beberapa pekerjaan lebih sulit untuk melakukan estimasi dibandingkan pekerjaan lainnya disebabkan karena terbatasnya pengalaman pada pekerjaan serupa atau disebabkan karena jenis pekerjaan tersebut. Pembuatan sebuah user manual merupakan langkah yang tepat yang dapat dipertanggungjawabkan dan sebagai bukti bahwa kita pernah mengerjakan tugas yang serupa sebelumnya. Dengan pengalaman itu seharusnya kita mampu untuk melakukan estimasi dengan lebih tepat mengenai berapa lama pekerjaan dapat diselesaikan dan berapa besarnya biaya yang dibutuhkan. Selain itu, waktu yang dibutuhkan untuk melakukan pengujian dan penelusuran program dapat menjadi sesuatu hal yang sulit diprediksi dengan tingkat keakuratan yang serupa walaupun kita pernah membuat program yang serupa sebelumnya.
Estimasi dapat ditingkatkan melalui analisa data historis untuk aktifitas yang serupa dan untuk sistem yang serupa. Dengan menyimpan perbandingan antara estimasi semula dengan hasil akhir akan mengakibatkan beberapa tipe pekerjaan sulit diestimasi secara tepat.
Risiko ini terjadi jika perkiraan LOC pada kenyataan yang ada jauh melebihi LOC perkiraan pada perhitungan COCOMO, yang mengakibatkan berubahnya jadwal pengerjaan dan biaya operasional.
Asumsi perencanaan
Pada setiap tahapan perencanaan, asumsi perlu dibuat, jika tidak benar maka dapat mengakibatkan risiko tersebut berisiko. Misal pada jaringan aktifitas, aktifitas dibangun berdasarkan pada asumsi menggunakan metode desain tertentu dimana memungkinkan urutan aktifitas diubah. Kita biasanya membuat asumsi bahwa setelah coding, biasanya sebuah modul akan diuji dan kemudian diintegrasikan dengan modul lainnya. Akan tetapi kita tidak merencanakan pengujian modul yang dapat mangakibatkan perubahan desain awal. Hal ini dapat terjadi setiap saat.
Pada setiap tahapan pada proses perencanaan, sangat penting untuk memeperinci secara eksplisit semua asumsi yang dibuat dan mengidentifikasi apa pengaruhnya jika ternyata dalam pelaksanaannya tidak sesuai dengan yang sudah direncanakan.
Kemungkinan
Beberapa kemungkinan dapat saja tidak pernah terlihat dan kita hanya dapat menyakinkan diri kita sendiri bahwa ada sesuatu yang tidak dapat dibayangkan, kadang-kadang dapat terjadi. Akan tetapi biasanya jarang terjadi hal seperti itu. Mayoritas kejadian yang tidak diharapkan biasanya dapat diidentifikasi beberapa spesifikasi kebutuhan kemungkinan diubah setelah beberapa modul telah dikodekan, programmer senior meninggalkan pengembangan, perangkat keras yang diperlukan tidak dikirim tapat waktu. Beberapa kejadian semacam itu dapat terjadi sewaktu-waktu dan walaupun kejadian tersebut kemungkinan terjadinya relatif rendah akan tetapi kejadian tersebut perlu dipertimbangkan dan direncanakan.
Metode untuk evaluasi pengaruh ketidakpastian ini terhadap jadwal proyek:
Penggunaan PERT untuk evaluasi pengaruh ketidakpastian
PERT dikembangkan untuk menghitung estimasi ketidakpastian lingkungan terhadap durasi pekerjaan. PERT dikembangkan pada suatu lingkungan proyek yang mahal, berisiko tinggi dan kompleks. Metode PERT ini memerlukan tiga estimasi:
- Most likely time
Waktu yang diperlukan untuk menyelesaikan pekerjaan dalam situasi normal dan diberikan simbol m.
- Optimistic time
Waktu tersingkat yang diperlukan untuk menyelesaikan pekerjaan dan diberi simbol a.
- Pessimistic time
Waktu terlama yang diperlukan untuk menyelesaikan pekerjaan dikarenakan berbagai kemungkinan yang masuk akal dan diberikan simbol b.
PERT mengkombinasikan ketiga estimasi tersebut untuk membentuk durasi tunggal yang diharapkan, te = a + 4m + b
Penggunaan durasi yang diharapkan
Durasi yang diharapkan dipergunakan supaya suatu forward pass dapat melalui sebuah jaringan; dengan mempergunakan metode yang sama dengan teknik CPM. Akan tetapi dalam hal ini, tanggal aktifitas yang dihitung bukan merupakan tanggal paling awal akan tetapi merupakan tanggal yang diharapkan dapat mencapai aktifitas tersebut.
Jaringan PERT yang diperlihatkan pada gambar 3 memperlihatkan bahwa kita berharap proyek tersebut dapat diselesaikan dalam waktu 13,5 minggu- tidak seperti CPM yang tidak memperlihatkan tanggal paling awal untuk menyelesaikan proyek tersebut akan tetapi tanggal yang diharapkan (atau most likely). Salah satu keuntungan dari pendekatan ini adalah menempatkan sebuah emphasis dalam ketidakpastian di dunia nyata.
No comments:
Post a Comment