MANAJEMEN RISIKO
Rekayasa Perangkat Lunak STMIK-AUB Surakarta
DEFINISI
Definisi konseptual mengenai risiko :
(Robert Charette)
Risiko berhubungan dengan kejadian di masa yg
akan datang.
Risiko melibatkan perubahan (spt. perubahan
pikiran, pendapat, aksi, atau tempat)
Risiko melibatkan pilihan & ketidakpastian bahwa
STRATEGI REAKTIF vs
PROAKTIF
Strategi reaktif memonitor proyek terhadap
kemungkinan resiko. Sumber2 daya dikesampingkan, padahal seharusnya sumber2 daya menjadi masalah yang sebenarnya / penting.
Strategi proaktif dimulai sebelum kerja teknis
diawali.
Resiko potensial diidentifikasi, probabilitas &
pengaruh proyek diperkirakan, dan diprioritaskan
menurut kepentingan, kemudian membangun suatu rencana untuk manajemen resiko.
RESIKO PERANGKAT LUNAK
Karakteristik risiko : Ketidakpastian Kerugian Kategori risiko : Risiko proyek Risiko teknis Risiko bisnis Kategori risiko oleh Robert Charette :
Risiko yang sudah diketahui Risiko yang dapat diramalkan Risiko yang tidak diharapkan
@ Risiko proyek
Risiko proyek mengancam rencana proyek.
Bila risiko proyek menjadi kenyataan maka ada
kemungkinan jadwal proyek akan mengalami slip &
biaya menjadi bertambah.
Risiko proyek mengidentifikasi :
- biaya
- sumber daya
- jadwal
- pelanggan
- personil (staffing & organisasi)
- masalah persyaratan
@ Risiko teknis
Risiko teknis mengancam kualitas & ketepatan waktu PL yg
akan dihasilkan. Bila resiko teknis menjadi kenyataan maka implementasinya menjadi sangat sulit atau tidak mungkin.
Risiko teknis mengidentifikasi :
- desain potensial - ambiquitas
- implementasi - spesifikasi
- interfacing - ketidakpastian teknik
- verivikasi - keusangan teknik
- masalah pemeliharaan
- teknologi yg leading edge
@ Risiko bisnis
Risiko bisnis mengancam viabilitas PL yg akan
dibangun.
Risiko bisnis membahayakan proyek atau
produk.
5 RISIKO BISNIS UTAMA
1.
Risiko Pasar – tidak diinginkan pasar
2.
Risiko Strategi – tidak diinginkan strategi
bisnis prsh
3.
Risiko Pemasaran – tidak tahu bgmn dijual
4.Risiko Manajemen – kehilangan dukungan
manajemen
5.
Risiko Biaya – kehilangan hal-hal yang
@ Risiko yg sudah diketahui
adalah risiko yg dpt diungkap setelah
dilakukan evaluasi secara hati2 terhadap
rencana proyek, bisnis, & lingkungan teknik
dimana proyek sedang dikembangkan, dan
sumber informasi reliable lainnya, seperti :
tgl penyampaian yg tdk realitas
kurangnya persyaratan yg terdokumentasi kurangnya ruang lingkup PL
lingkungan pengembangan yg buruk
@ Risiko yg dapat diramalkan
diekstrapolasi dari pengalaman proyek
sebelumnya.
Misalnya :
pergantian staf
komunikasi yg buruk dgn para pelanggan mengurangi usaha staff bila permintaan
pemeliharaan sedang berlangsung dilayani
@ Risiko yg tidak diharapkan
risiko ini dapat benar-benar terjadi, tetapi
sangat sulit untuk diidentifikasi sebelumnya.
IDENTIFIKASI RISIKO
Usaha sistematis untuk menentukan ancaman terhadap rencana proyek. Tujuan identifikasi risiko :
untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap saat diperlukan.
Tipe risiko :
risiko generik
merupakan ancaman potensial pd setiap proyek PL.
risiko produk spesifik
hanya dapat diidentifikasi dgn pemahaman khusus mengenai teknologi, manusia, serta lingkungan yg spesifik terhadap proyek yg ada.
Kategori checklist item risiko :
risiko ukuran produk
risiko yg mempengaruhi bisnis
risiko yg dihubungkan dgn karakteristik pelanggan
risiko definisi proses
risiko teknologi yang akan dibangun
risiko lingkungan pengembangan
risiko yg berhubungan dgn ukuran dan pengalaman
staf
KOMPONEN RISIKO dan DRIVER
Pedoman untuk mengidentifikasi risiko PL dan
pengurangannya yaitu menghendaki agar manajer proyek mengidentifikasi risiko driver yg mempengaruhi komponen
risiko PL – kinerja, biaya, dukungan dan jadwal.
Komponen risiko didefinisikan dgn cara sbb :
Risiko kinerja – tingakat ketidakpastian dimana produk akan
memenuhi persyaratannya dan cocok dgn penggunaannya.
Risiko biaya – tingkat ketidakpastian dimana biaya proyek akan
dijaga
Risiko dukungan – tingkat ketidakpastian dimana PL akan mudah
dikoreksi, disesuaikan dan ditingkatkan.
Risiko jadwal – tingkat ketidakpastian dimana jadwal proyek akan
PROYEKSI RISIKO/ PERKIRAAN
RISIKO
Dua cara melakukan proyeksi risiko :
Probabilitas di mana risiko adalah nyata
Konsekuensi masalah yang berhubungan dengan risiko
Perencanaan proyek bersama dengan manajer & staf teknik
melakukan 4 aktifitas proyeksi risiko :
Membangun suatu skala yang merefleksikan kemungkinan risiko
yang dirasakan
Menggambar konsekuensi risiko
Memperkirakan pengaruh risiko pada proyek dan produk
Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan
MENILAI PENGARUH RISIKO
Tiga factor yg mempengaruhi konsekuensi jika
suatu risiko benar-benar terjadi :
Sifatnya ; risiko yang menunjukkan masalah yg muncul bila ia terjadi
Ruang lingkupnya; menggabungkan kepelikannya
(seberapa seriusnya masalah ini ? ) dengan keseluruhan distribusi ( berapa banyak proyek yg akan dipengaruhi
atau berapa banyak pelanggan terganggu ? )
Timingnya; mempertimbangkan kapan dan untuk berapa lama pengaruh itu dirasakan.
Pengurangan, Monitoring dan
Manajemen Resiko
Tujuan analisis resiko – membantu tim proyek dalam mengembangkan
strategi yang berkaitan dengan resiko.
Strategi yang efektif hrs memiliki gagasan berikut :
Menghindari resiko
Pendekatan proaktif terhadap resiko
Monitoring resiko
Memonitor faktor-faktor yang dapat memberikan suatu indikasi apakah resiko sedang menjadi lebih atau kurang mungkin
Memonitor efektivitas langkah pengurangan resiko
Manajemen resiko dan perencanaan kemungkinan
Mengasumsikan bahwa usaha pengurangan telah gagal dan bahwa resiko telah menjadi kenyataan
Resiko Keselamatan dan Bahaya
Resiko dapat terjadi setelah perangkat lunak dikembangkan dengan
sukses dan dikirim ke pelanggan
Resiko secara khusus berhubungan dengan konsekuensi kegagalan
perangkat lunak dilapangan
Keselamatan perangkat lunak dan analisis bahaya adalah aktivitas
jaminan kualitas perangkat lunak yang berfokus pada identifikasi dan perkiraan bahaya potensial yang dapat mempengaruhi perangkat
lunak secara negatif dan menyebabkan keseluruhan sistem menjadi gagal
RMMM Plan (1)
RMMM Plan
Risk Mitigating, Monitoring and Management Plan Mendokumentasi semua kegiatan yang dilakukan
sebagai bagian dari analisis resiko
Digunakan oleh manajer proyek sebagai bahan dari
keseluruhan rencana proyek
RMMM plan dikembangkan dan proyek dimulai,
pengurangan resiko dan langkah monitoring
dimulai.
RMMM Plan (2)
Monitoring resiko adalah aktivitas penelusuran proyek dengan
tiga sasaran utama :
Memperkirakan apakah resiko yg diramalkan benar2 terjadi
Memastikan bahwa langkah aversi resiko yg didefinisikan untuk
resiko telah diterapkan dgn benar
Mengumpulkan informasi yg dapat digunakan utk analisis resiko
masa yg akan datang
Tugas lain monitoring resiko
Berusaha menentukan “resiko asli” (resiko apa atau masalah
JAMINAN KUALITAS PERANGKAT
LUNAK
(SOFTWARE QUALITY ASSURANCE)
JAMINAN KUALITAS PL
Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh
proses perangkat lunak.
SQA meliputi :
pendekatan manajemen kualitas
teknologi rekayasa perangkat lunak yang efektif (metode dan peranti) kajian teknik formal yang diaplikasikan pada keseluruhan proses
perangkat lunak
strategi pengujian multitiered (deret bertingkat)
kontrol dokumentasi perangkat lunak dan perubahan
prosedur untuk menjamin kesesuaian dengan standar pengembangan
perangkat lunak
KONTROL KUALITAS
Kontrol kualitas merupakan serangkaian pemeriksaan,
kajian, dan pengujian yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap
produk memenuhi persyaratan yang ditetapkan.
Konsep kunci kualitas kontrol adalah bahwa semua
produk kerja memiliki spesifikasi yang telah ditentukan dan dapat diukur dimana kita dapat membandingkan output dari setiap proses.
Kalang (loop) menjadi penting untuk meminimalkan cacat
JAMINAN KUALAITAS
Jaminan kualitas terdiri atas fungsi auditing dan
pelaporan manajemen.
Tujuan jaminan kualitas adalah :
untuk memberikan data yang diperlukan oleh
manajemen untuk menginformasikan masalah
kualitas produk, sehingga dapat memberikan
kepastian & konfidensi bahwa kulitas produk
dapat memenuhi sasaran.
BIAYA KUALITAS
Biaya kualitas menyangkut semua biaya yang diadakan
untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas.
Biaya kualitas dapat dibagi ke dalam biaya-biaya yang
dihubungkan dengan :
pencegahan
penilaian
DEFINISI KUALITAS PL
Kualitas perangkat lunak didefinisikan sebagai:
Konformansi terhadap kebutuhan fungsional dan kinerja yang dinyatakan secara eksplisit, standar perkembangan yang didokumentasikan secara
eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat lunak dikembangkan secara profesional.
DEFINISI KUALITAS PL (cont.)
Definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu:
Kebutuhan perangkat lunak merupakan fondasi yang
melaluinya kualitas diukur.
Standar yang telah ditentukan menetapkan serangkaian
kriteria pengembangan yang menuntun cara perangkat lunak direkayasa.
Ada serangkaian kebutuhan implisit yang sering
dicantumkan (misalnya kebutuhan akan kemampuan pemeliharaan yang baik).
DEFINISI KUALITAS PL (cont.)
Kelompok SQA berfungsi sebagai perwakilan
in-house pelanggan, yaitu orang yang akan melakukan
SQA harus memperhatikan perangkat lunak dari
sudut pandang pelanggan.
Apakah perangkat lunak cukup memenuhi faktor kualitas
Sudahkah pengembangan perangkat lunak dilakukan sesuai
dengan standar yang telah ditetapkan sebelumnya?
Sudahkah disiplin teknik dengan tepat memainkan perannya
AKTIVITAS SQA
Jaminan kualitas perangkat lunak terdiri dari
berbagai tugas yang berhubungan dengan dua
konstituen yang berbeda :
perekayasa perangkat lunak yang mengerjakan kerja teknis kelompok SQA yang bertanggung jawab terhadap
perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan.
KAJIAN PERANGKAT LUNAK
Kajian perangkat lunak merupakan salah satu aktivitas
SQA yang terpenting.
Kajian perangkat lunak adalah suatu filter bagi proses
rekayasa perangkat lunak, yaitu kajian yg diterapkan pd berbagai titik selama pengembangan PL & berfungsi
untuk mencari kesalahan yg kemudian akan dihilangkan.
Kajian perangkat lunak berfungsi untuk “memurnikan”
produk kerja perangkat lunak yang terjadi sebagai hasil dari analisis, desain, dan pengkodean.
KAJIAN TEKNIK FORMAL
(Formal Technic Review – FTR)
FTR adalah aktivitas jaminan kualitas perangkat lunak
yang dilakukan oleh perekayasa perangkat lunak.
Kajian teknik formal atau walktrough adalah pertemuan
kajian yang disesuaikan dengan kebutuhan yang terbukti sangat efektif untuk menemukan kesalahan.
Keuntungan utama kajian teknis formal adalah penemuan
kesalahan sejak awal sehingga tidak berlanjut ke langkah selanjutnya dalam proses perangkat lunak.
Formal Technic Review – FTR (cont.)
Tujuan FTR adalah
Menemukan kesalahan dlm fungsi, logika, /
implementasinya dlm berbagai representasi PL;
Membuktikan bahwa perangkat lunak di bawah kajian
memenuhi syarat;
Memastikan bahwa PL disajikan sesuai dgn standar
yg sudah ditentukan sebelumnya;
Mencapai perangkat lunak yg dikembangkan dengan
Formal Technic Review – FTR (cont.)
FTR berfungsi
dasar pelatihan yang memungkinkan perekayasa yunior mengamati berbagai pendekatan yang berbeda
terhadap analisis perangkat lunak, desain, dan implementasi.
mengembangkan backup dan kontinuitas karena sejumlah orang mengenal baik bagian-bagian
PERTEMUAN KAJIAN
Tanpa memperhatikan format FTR yang dipilih, setiap
pertemuan kajian harus mematuhi batasan-batasan berikut ini :
Antara 3 & 5 orang (khususnya) harus dilibatkan dalam
kajian;
Persiapan awal harus dilakukan, tetapi waktu yang
dibutuhkan harus tidak lebih dari 2 jam dari kerja bagi setiap person
PERTEMUAN KAJIAN (cont.)
Pada akhir kajian, semua peserta FTR yang hadir harus
memutuskan apakah akan ....(ada 3) kemudian ambil keputusan
Setelah pertemuan kajian akan dilakukan
Pelaporan Kajian & Penyimpanan Rekaman
Apa yang dikaji ?
Siapa yang melakukan?
penemuan apa yang dihasilkan dan apa kesimpulannya?
PENDEKATAN FORMAL TERHADAP SQA
