Kuis 5 - Pengintegrasian antara Manajemen Resiko dengan SDLC (System Development Life Cycle), dan Kerangka Resiko menurut ISO 270

Pendahuluan

Setiap proyek terkait software akan terpengaruh atau akan terintegrasi secara otomatis dengan resiko software itu sendiri. Resikonya dapat mempengaruhi biaya, durasi proyek dan kualitas produk. Setiap proyek perlu melakukan analisis identifikasi risiko. Resiko yang teridentifikasi ini kemudian dimasukkan secara sistematis dalam rencana proyek, agar dapat dikelola dan dikendalikan. Tulisan ini berfokus pada masalah bagaimana mengelola resiko dalam pengembangan ssuatu software.

Definisi sederhana dari Risiko adalah: "Kemungkinan kerugian, cedera, kerugian atau kehancuran." Zardari dkk (2009). Risiko berkaitan dengan ketidakpastian. Ketidakpastian terhadap terjadinya peristiwa-peristiwa, baik itu peristiwa yang sudah teridentifikasi maupun peristiwa yang belum teridentifikasi, yang dapat berdampak pada keberlangsungan proyek.

Oleh karenanya sangatlah penting dilakukan pengelolaan dan pengendalian terhadap resiko-resiko yang mungkin terjadi.

Manajemen Risiko merupakan suatu pengelolaan resiko, yang terdiri dari proses, metodologi dan sekumpulan alat penanganan resiko. Manajemen Risiko diartikan sebagai suatu aktivitas identifikasi, penilaian, dan penentuan kebijakan atau strategi guna meringankan atau mengurangi risiko. "Manajemen risiko merupakan sebuah praktik sistematis yang dapat bekerja secara efektif dan efisien guna meminimalkan ancaman terhadap organisasi."

Resiko bahaya dalam bidang rekayasa software harus dipelajari secara berkelanjutan dan terus menerus. Diperlukan pendekatan yang mendalam, seperti mempelajari pengalaman manajer proyek, mengikuti perkembangan para penulis dan para ahli khusus di bidangnya.

Resiko dari suatu software, adalah sebagai berikut:

• Terbatasnya personal yang dapat mengoperasikan software
• Tidak realistisnya suatu anggaran dan jadwalnya
• Memungkinkan melakukan pengembangkan fungsi dan properti yang salah
• Memungkinkan melakukan pengembangkan antarmuka pengguna yang salah
• Memungkinkan melanjutkan perubahan suatu persyaratan
• Terbatasnya perlengkapan eksternal software
• Kekurangan dalam tugas yang dilakukan secara eksternal
• Terbatasnya kinerja real-time
• Harus memiliki kemampuan dalam pengelolaan ilmu komputer

Manajemen Risiko Proaktif dan Reaktif

Industri software secara aktif menggunakan teknik manajemen risiko dalam praktik manajemen risiko mereka. Teknik manajemen risiko adalah suatu sistem yang secara fokus dapat mengukur berapa kemungkinan terjadinya risiko, mengidentifikasi pemicu peristiwa risiko, mengukur kemungkinan dampak yang terjadi, dan mengidentifikasi pemicu dampak sebelum risiko tersebut benar-benar terjadi. Hal ini biasa disebut sebagai 'manajemen risiko proaktif'.

Pada saat tim proyek merespon resiko yang terjadi, maka hal itu disebut sebagai resiko reaktif pengelolaan. Kegagalan telah diperbaiki; sumber daya ditemukan dan digunakan ketika risiko terjadi.

Model, metode dan teknik penilaian risiko banyak digunakan untuk mengendalikan risiko dalam suatu proyek software. Pengambilan keputusan yang efektif membutuhkan penilaian risiko yang jelas dan analisis yang tepat, yang dapat menunjukkan kemungkinan hasil apa pun. Hasil yang buruk adalah berupa resiko dan hasil yang baik adalah berupa kemungkinan untuk menghasilkan software yang baik.

Salah satu analisis risiko yang akurat adalah menggunakan suatu alat yang bekerja secara otomatis dalam menyimpan, mengatur, dan memproses data menjadi pengetahuan yang bermakna, Boehm dkk (1989).

Pada saat ini, banyak proyek software yang ketika diterapkan, menunjukkan kesalahan yang berlebihan dan keandalan hasil yang sangat rendah. Dan meskipun industri software secara aktif menggunakan teknik manajemen risiko dalam pengelolaan resiko mereka, namun tetap saja, hanya sedikit laporan yang tersedia, yang berisi perancangan alat visualisasi pengelolaan risiko software.

Pengembangan Software menggunakan Model Air Terjun 

Royce memperkenalkan model proses pengembangan suatu software yang sangat tradisional yaitu "Model Air Terjun" pada tahun 1970. Kemudian, Boehm memperluas model ini pada tahun 1981 dengan menambahkan langkah-langkah tambahan. Model air terjun ini, diilustrasikan pada Gambar 2.

Pada model air terjun ini memungkinkan langkah dapat mundur ke tahap sebelumnya jika diperlukan. Model air terjun ini telah menjadi dasar bagi sebagian besar standar akuisisi software di pemerintahan dan industri Boehm dkk (1988). Model air terjun memiliki tujuan yang jelas dimana setiap proses mengambil masukan dari langkah sebelumnya.

Dokumen Pribadi 2

Menurut Gillian et al (2004), masalah mendasar dari model air terjun adalah bahwa model ini tetap memiliki risiko tinggi di sepanjang siklus pengembangannya. Hal ini dikarenakan proses air terjun mengasumsikan bahwa setiap tahapan dapat didefinisikan sepenuhnya tanpa memerlukan umpan balik dari tahapan berikutnya.

Dokumen Pribadi 3

Sumbu X menunjukkan waktu, dan sumbu Y memplot fungsionalitas dan tingkat risiko proyek. Seperti yang ditunjukkan pada grafik di atas, risikonya tetap tinggi hingga tahap terakhir pengembangan software. Risiko ini secara bertahap berkurang seiring dengan pembuatan, integrasi, dan pengujian pengkodean. Untuk menghasilkan perangkat lunak yang baik, penting untuk memperhitungkan risiko. Masalah mendasarnya adalah bahwa dalam model air terjun, risiko proyek tetap tinggi sepanjang proses pengembangan suatu software.

Pengembangan Software menggunakan Model Spiral

Dokumen Pribadi 4

Ciri utama dari model spiral adalah bahwa model ini menciptakan pendekatan berbasis risiko terhadap proses suatu software, dan bukanlah proses pendekatan berbasis dokumen atau berbasis kode.

Model spiral dapat mengakomodasi model yang berbeda, seperti model air terjun, model evolusi, model prototipe, model transformasi, dll.

Setiap siklus spiral dimulai dengan identifikasi hal-hal sebagai berikut:

• Menetapkan tujuan dari porsi produk yang akan dielaborasi, seperti kinerja, fungsionalitas, kemampuan dalam mengakomodasi perubahan, dll.
• Menetapkan cara-cara alternatif dalam menerapkan setiap bagian produk, dan
• Mengidentifikasi kendala yang akan terjadi pada penerapan cara alternatif tersebut, seperti biaya, jadwal, antarmuka, dll.

Langkah berikutnya adalah mengevaluasi penerapan cara alternatif terhadap tujuan dan kendala. Seringkali, proses ini akan mengidentifikasi area ketidakpastian yang merupakan sumber risiko proyek yang paling signifikan. Dan jika demikian, maka langkah selanjutnya harus melibatkan perumusan strategi yang efektif dan efesien dalam mengatasi sumber risiko.

Setelah risiko dievaluasi, maka langkah selanjutnya ditentukan oleh risiko relatif yang tersisa. Jika kinerja risiko antarmuka pengguna sangat mendominasi pengembangan program, maka langkah berikutnya mungkin merupakan pengembangan evolusioner, berupa upaya minimal dalam menentukan sifat keseluruhan produk, baik di rencana pembuatan prototipe tingkat berikutnya, maupun di pengembangan prototipe yang lebih terperinci, guna  menyelesaikan masalah risiko utama secara berkelanjutan.

Sub pengaturan yang digerakkan oleh risiko pada model spiral ini memungkinkan model mengakomodasi model campuran lainnya, yang sesuai dengan orientasi spesifikasi, orientasi simulasi, orietasi prototipe, orietasi transformasi otomatis, dan orientasi lainnya terkait pengembangan software. Dalam kasus seperti ini, pertimbangan manajemen risiko diperlukan dalam menentukan jumlah waktu dan strategi yang diperlukan, seperti perencanaan, manajemen konfigurasi, jaminan kualitas, verifikasi formal, dan pengujian.

Model spiral, memiliki ciri seperti kebanyakan model lainnya, yaitu bahwa setiap siklus diselesaikan dengan tinjauan yang melibatkan orang atau organisasi utama yang terkait dengan produk.

Keuntungan utama model spiral adalah rangkaian pilihannya mengakomodasi fitur-fitur bagus dari model proses software yang ada, seperti sebagai berikut:

• Jika suatu proyek mempunyai risiko yang rendah dalam bidang-bidang, seperti antarmuka pengguna yang tidak tepat, atau tidak terpenuhinya persyaratan kinerja yang ketat, dan bahkan jika proyek tersebut mempunyai risiko yang tinggi dalam prediktabilitas dan pengendalian anggaran dan jadwal, maka pertimbangan risiko tersebut tadi akan mendorong model spiral ke dalam kesetaraan dengan model air terjun.
• Jika persyaratan produk perangkat lunak sangat stabil, menyiratkan risiko rendah terhadap kerusakan desain dan kode, dikarenakan perubahan persyaratan selama pengembangan, dan bahkan jika ada kesalahan dalam produk software yang dapat menimbulkan risiko tinggi terhadap misi yang dilayaninya, maka pertimbangan risiko-risiko tersebut mendorong model spiral menyerupai model dua kaki yaitu model dengan spesifikasi yang tepat dalam pengembangan program deduktif formal.
• Jika suatu proyek memiliki risiko rendah dalam beberapa bidang, seperti kehilangan anggaran dan jadwal, dan ketika menghadapi masalah integrasi sistem yang besar, atau mengatasi sklerosis informasi, dan bahkan jika proyek tersebut mempunyai risiko tinggi dalam bidang-bidang seperti antarmuka pengguna yang salah dan atau persyaratan dukungan keputusan pengguna yang salah, maka pertimbangan risiko tersebut mendorong model spiral menjadi setara dengan model pembangunan evolusioner.

Jika kemampuan pembuatan suatu software otomatis tersedia, maka model spiral akan mengakomodasi kemampuan tersebut menjadi prototipe cepat atau menjadi model transformasi, tergantung pada pertimbangan resiko yang terlibat.

Referensi:

European Journal of Scientific Research ISSN 1450-216X Vol.42 No.4 (2010), pp.629-636 EuroJournals Publishing, Inc. 2010 

http://www.eurojournals.com/ejsr.htm

https://www.scribd.com/document/297583174/Risk-Assessment-Techniques-for-Software-Development