MANAJEMEN RISIKO
Rekayasa Perangkat Lunak STMIK-AUB Surakarta
DEFINISI
PL
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 pilihan itu akan dilakukan.
STRATEGI REAKTIF vs PROAKTIF
PL
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. Sasaran utama adalah menghindari resiko.
RESIKO PERANGKAT LUNAK
PL
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
RESIKO PERANGKAT LUNAK (cont.
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
PL
RESIKO PERANGKAT LUNAK (cont.)
@ 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
PL
RESIKO PERANGKAT LUNAK (cont.
@ Risiko bisnis Risiko bisnis mengancam viabilitas PL yg akan dibangun. Risiko bisnis membahayakan proyek atau produk.
PL
5 RISIKO BISNIS UTAMA
.
.
.
.
.
PL
Risiko Pasar – tidak diinginkan pasar Risiko Strategi – tidak diinginkan strategi bisnis prsh Risiko Pemasaran – tidak tahu bgmn dijual Risiko Manajemen – kehilangan dukungan manajemen Risiko Biaya – kehilangan hal-hal yang berhubungan dengan biaya
RISIKO PERANGKAT LUNAK (cont.)
@ 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 :
PL
tgl penyampaian yg tdk realitas kurangnya persyaratan yg terdokumentasi kurangnya ruang lingkup PL lingkungan pengembangan yg buruk
RISIKO PERANGKAT LUNAK (cont.)
@ Risiko yg dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya. Misalnya :
PL
pergantian staf komunikasi yg buruk dgn para pelanggan mengurangi usaha staff bila permintaan pemeliharaan sedang berlangsung dilayani
RISIKO PERANGKAT LUNAK (cont.)
@ Risiko yg tidak diharapkan risiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.
PL
DENTIFIKASI RISIKO
PL
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.
Metode untuk mengidentifikasi resiko adalah menciptakan checklist item risiko.
IDENTIFIKASI RISIKO
PL
Kategori checklist item risiko :
risiko ukuran produk risiko yg mempengaruhi bisnis risiko yg dihubungkan dgn karakteristik risiko definisi proses risiko teknologi yang akan dibangun risiko lingkungan pengembangan risiko yg berhubungan dgn ukuran dan staf
pelanggan
pengalaman
KOMPONEN RISIKO dan DRIVER
PL
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 dijaga dan produk akan disampaikan tepat waktu.
PROYEKSI RISIKO/ PERKIRAAN RISIKO
PL
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 aka tidak ada kesalahpahaman
MENILAI PENGARUH RISIKO
PL
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
PL
Resiko Keselamatan dan Bahaya
PL
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)
PL
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)
PL
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 mana yang menyebabkan resiko) pada keseluruhan proyek
JAMINAN KUALITAS PERANGKA LUNA (SOFTWARE QUALITY ASSURANCE
JAMINAN KUALITAS PL
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 mekanisme pengukuran dan pelaporan.
KONTROL KUALITAS
PL
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 yang dihasilkan.
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.
PL
BIAYA KUALITAS
PL
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 kegagalan.
DEFINISI KUALITAS PL
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.)
PL
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.)
PL
Kelompok SQA berfungsi sebagai perwakilan inhouse 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 sebagi bagian dari aktivitas SQA?
AKTIVITAS SQA
PL
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
PL
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)
PL
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 langka selanjutnya dalam proses perangkat lunak.
Formal Technic Review – FTR (cont.)
PL
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 cara yang seragam; Membuat proyek lebih dapat dikelola.
Formal Technic Review – FTR (cont.)
PL
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 perangkat lunak yang tidak mereka ketahui sebelumnya
PERTEMUAN KAJIAN
PL
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 bag setiap person Durasi pertemuan kajian harus kurang dari 2 jam
PERTEMUAN KAJIAN (cont.)
PL
Pada akhir kajian, semua peserta FTR yang hadir harus memutuskan apakah akan ....(ada 3) kemudian ambi keputusan Setelah pertemuan kajian akan dilakukan
Pelaporan Kajian & Penyimpanan Rekaman
Apa yang dikaji ? Siapa yang melakukan? penemuan apa yang dihasilkan dan apa kesimpulannya?
Adanya Pedoman Kajian
PENDEKATAN FORMAL TERHADAP SQA
PL
Kualitas perangat lunak merupakan tugas setiap orang & kualitas dapat dicapai melalui analisis, desain, pengkodean, dan pengujian yang baik serta aplikasi standar pengembangan perangkat lunak yang diterima.
