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