Manajemen Proyek Perangkat Lunak
Teknik Informatika UHO2016
Materi Pert 9-10 Manajemen risiko (apa itu risiko? contoh risiko?)
Manajemen resiko proyek perangkat lunak (mengapa risiko perlu di-manage?)
Cara menghitung risiko dengan probability matrix
Analogi Proyek Perangkat Lunak sebagai sebuah kapal
Dalam hidup kita, terkadang kita harus
mengambil risiko
Karena terkadang ada hasil positif (reward) yang akan kita
peroleh ketika memutuskan untuk mengambil risiko
tersebut.
Without risk, there is no reward
Apa itu Risiko (Risk)
Segala kemungkinan terburuk bisa saja
terjadi
Apa kemungkinan terburuk yang bisa
terjadi?
Wi-fi mati?
Lambat loading?
Baterai lemah?
Risiko adalah kejadian tidak pasti (uncertain event) yang
kemungkinan akan berdampak negatif maupun
positif
PMBOK: RISIKO PROYEK adalah kejadian tidak pasti atau
keadaan yang apabila terjadi dapat berefek negatif atau positif terhadap salah satu tujuan dari proyek (baik itu
biaya, ruang lingkup, kualitas, waktu, dsb)
Risiko bisa berbentuk Negatif maupun
Positif
Risiko Positif biasanya disebut dengan
Kesempatan (opportunity)
Risiko Negatif biasanya disebut dengan
Ancaman (threat)
Satu risiko negatif, bisa memiliki lebih dari satu
dampak negatif
Mengapa perlu melakukan
manajemen risiko?
Tujuan dilakukannya manajemen risiko adalah untuk meminimalkan dampak negatif (threat) dan memaksimalkan dampak positif (opportunity)
CONTOH ILUSTRASI RISIKOTUJUAN: menempuh perjalanan dengan pesawat dari A ke B untuk
menghadiri rapat pada pukul 9.00 WITA
KIRA-KIRA…APA SAJA
RISIKONYA?
ILUSTRASI RISIKOTUJUAN: menempuh perjalanan dengan pesawat dari A ke B untuk
menghadiri rapat pada pukul 9.00 WITA
Gagal berangkat dari A ke B Ini hanya kebalikan dari tujuan
Terlambat dan melewatkan rapat
Ini adalah pernyataan dampak dari risiko, bukan risiko itu sendiri
Tidak ada makanan dalam pesawat sehingga jadi kelaparan
Ini bukan risiko terhadap pencapaian tujuan / tujuannya berbeda
Ketinggalan pesawat sehingga terlambat hadir mengikuti rapat
Ini adalah risiko, yang dapat dikendalikan dengan memastikan masih banyak waktu untuk mencapai bandara
Cuaca buruk membuat pesawat tidak dapat berangkat mengangkut peserta rapat
Ini adalah risiko, yang tidak dapat dikendalikan, namun kita dapat membuat rencana B.
Pada saat kita membangun sebuah perangkat lunak, seringkali kita menghadapi berbagai situasi yang tidak nyaman seperti keterlambatan pengembangan atau pengeluaran biaya pengembangan yang melebihi anggaran.
Risiko dalam Proyek Perangkat Lunak
Untuk itu perlu dilakukan identifikasi tindakan yang harus dilakukan untuk mencegah ataupun meminimalkan risiko tersebut.
Risiko dalam Proyek Perangkat Lunak
Hal ini dikarenakan kurang siapnya kita menghadapi berbagai kemungkinan risiko negatif yang akan terjadi.
UNSUR-UNSUR RISIKO
PeristiwaProbabilita
s terjadinya
Dampak peristiwa
Perhitungan Risiko
Risiko bisa diukur dengan menggunakan
analisis kuantitatif maupun kualitatif
Mengukur Risiko Proyek Perangkat Lunak
Setelah kita (manajer proyek perangkat lunak) dan stakeholder mengidentifikasi segala kemungkinan risiko yang bisa terjadi, maka perlu dilakukan yang namanya ranking. Biasanya risiko proyek diukur dengan risk impact matrix (matriks dampak dari risiko). Ada dua pendekatan untuk risk ranking, yaitu:
Ordinal/kualitatif: Perhitungan cukup dilakukan dengan mengurut risiko dalam kategori risiko tinggi, risiko menengah dan risiko rendah. (kebanyakan menggunakan perhitungan ordinal)
Cardinal / kuantitatif: Perhitungan dilakukan dengan menggunakan skor dalam bentuk angka seperti 0.67 (67%) atau 0.99 (99%) dan sebagainya.
Perform Quantitative Risk Analysis:
Kita bisa membuat keputusan yang lebih baik dengan informasi yang lebih jelas. Oleh karena itu proses ini disebut menandakan nilai numerik untuk tiap peluang dan dampak dari tiap risiko.
Setelah didapatkan tiap risiko yang mungkin, maka manajer proyek (terkadang bersama stakeholder), harus mengikuti langkah berikut:
1. Evaluasi peluang (probability) bahwa risiko tersebut akan muncul dan berikan skor terhadap peluang tersebut.
2. Tentukan dampak (impcat) dari tiap-tiap risiko tersebut (biasanya dalam bentuk biaya)
3. Kalikan nilai peluang dengan nilai dampak untuk memperoleh nilai risiko
Perform Qualitative Risk Analysis:
DampakPeluangRisikoNilai x
Perform Qualitative Risk Analysis: Setelah kita memperoleh dampak risiko, kita
bisa menentukan peluang (probability) dan dampak (impact) dari tiap risiko
Kapal Titanic dan analoginya dengan proyek perangkat
lunak
Tahun 1912Kapal TITANIC tenggelam
Kejadian tersebut menyebabkan lebih dari 1500 nyawa melayang.
Tenggelamnya kapal Titanic dianggap
sebagai bencana laut terbesar di abad 20
Jika kita mengandaikan sebuah proyek perangkat lunak sebagai sebuah kapal Titanic, maka kita
bisa memperoleh beberapa pelajaran, sebagai berikut:
Pelajaran 1: Hati-hati terhadap asumsi
Kapten kapal beberapa kali menerima informasi dari beberapa kapal yang telah melewati area tersebut bahwa terdapat iceberg (gundukan es) di jalur kapal titanic. Namun, dengan asumsi bahwa kapal mereka tidak akan tenggelam, kapten tidak terlalu memperdulikan peringatan tersebut.
Pelajaran 1: Hati-hati terhadap asumsi
Pelajaran: Dalam membangun sebuah proyek perangkat lunak, pastikan semua informasi jelas dan jangan biarkan tim pengembang proyek maupun client berasumsi sendiri. Komunikasi adalah hal yang paling utama.
Pelajaran 2 : Jangan lupakan proses maupun pihak-pihak yang terlibat dalam proyek
Kru dari kapal Titanic tidak terlatih dalam hal penyelamatan sehingga banyak korban berjatuhan. Tidak adanya rencana mengenai kemungkinan risiko terburuk yang terjadi menyebabkan proses evakuasi penumpang menjadi tidak teratur. Akibatnya, penggunaan sekoci tidak dimaksimalkan dengan baik.
Pelajaran 2 : Jangan lupakan proses maupun pihak-pihak yang terlibat dalam proyek
Proyek perangkat lunak yang sukses pastinya melibatkan rencana yang harus dipikirkan secara matang terlebih dahulu sebelum diimplementasikan. Rencana tersebut adalah mengenai rencana terhadap tim maupun proses pengembangan software. Biasanya kita hanya fokus pada aspek teknologi dan kadang melupakan aspek manusia maupun aspek proses dari proyek.
Ketika dalam perjalanannya, Chairman dari perusahaan pembuat Titanic meminta kepada kapten kapal Titanic untuk meningkatkan kecepatan kapal.
Pelajaran 3: Jangan mengubah target proyek di tengah jalan
Padahal sebenarnya, kapal ini tidak didesain untuk kecepatan. Akibatnya, kapal menabrak gundukan es dalam kecepatan di atas normal.
Hati-hati terhadap ruang lingkup proyek (project scope). Terkadang, di tengah proses pembuatan software, client meminta sedikit perubahan pada software. Faktanya, perubahan kecil bisa berdampak pada sistem dalam jumlah yang besar, menghasilkan kompleksitas tinggi dan testing yang harus ditambah.
Pastikan kepada client bahwa untuk membangun sebuah perangkat lunak, kita telah terikat pada aturan yang telah didefinisikan dari awal. Jadi, sejak awal keinginan client harus jelas dan tidak ada kemungkinan untuk berubah
Pelajaran 3: Jangan mengubah target proyek di tengah jalan
Setiap proyek perangkat lunak, memiliki setidaknya 8 resiko berikut:
Time (waktu) Cost (biaya) Scope (ruang lingkup) Feasibility (kelayakan) Quality (kualitas) Stakeholder expectations (harapan pemangku kepentingan) Human Resources (sumberdaya manusia) Technical accuracy (akurasi teknis)
Berikan penjelasan beserta contoh pada masing-masing risiko yang mungkin
Tugas Anggap Anda adalah seorang manajer dalam sebuah proyek
perangkat lunak.(Identifikasi apa saja risiko negatif yang kemungkinan akan muncul. Lalu lakukan perhitungan risiko
nya secara kuantitatif)
TERIMA KASIH