MANAJEMEN RISIKO

Rekayasa Perangkat LunakSTMIK-AUB Surakarta

RPL 2

DEFINISI

Definisi konseptual mengenai risiko :(Robert Charette)

Risiko berhubungan dengan kejadian di masa ygakan datang.

Risiko melibatkan perubahan (spt. perubahanpikiran, pendapat, aksi, atau tempat)

Risiko melibatkan pilihan & ketidakpastian bahwapilihan itu akan dilakukan.

RPL 3

STRATEGI REAKTIF vsPROAKTIF Strategi reaktif memonitor proyek terhadap

kemungkinan resiko. Sumber2 daya dikesampingkan,padahal seharusnya sumber2 daya menjadi masalahyang sebenarnya / penting.

Strategi proaktif dimulai sebelum kerja teknisdiawali.Resiko potensial diidentifikasi, probabilitas &pengaruh proyek diperkirakan, dan diprioritaskanmenurut kepentingan, kemudian membangun suaturencana untuk manajemen resiko.Sasaran utama adalah menghindari resiko.

RPL 4

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

RPL 5

@ 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

RESIKO PERANGKAT LUNAK (cont.)

RPL 6

@ Risiko teknis Risiko teknis mengancam kualitas & ketepatan waktu PL yg

akan dihasilkan. Bila resiko teknis menjadi kenyataan makaimplementasinya 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

RESIKO PERANGKAT LUNAK (cont.)

RPL 7

@ Risiko bisnis Risiko bisnis mengancam viabilitas PL yg akan

dibangun. Risiko bisnis membahayakan proyek atau

produk.

RESIKO PERANGKAT LUNAK (cont.)

RPL 8

5 RISIKO BISNIS UTAMA

1. Risiko Pasar – tidak diinginkan pasar2. Risiko Strategi – tidak diinginkan strategi

bisnis prsh3. Risiko Pemasaran – tidak tahu bgmn dijual4. Risiko Manajemen – kehilangan dukungan

manajemen5. Risiko Biaya – kehilangan hal-hal yang

berhubungan dengan biaya

RPL 9

@ Risiko yg sudah diketahui adalah risiko yg dpt diungkap setelah

dilakukan evaluasi secara hati2 terhadaprencana proyek, bisnis, & lingkungan teknikdimana proyek sedang dikembangkan, dansumber informasi reliable lainnya, seperti :

tgl penyampaian yg tdk realitas kurangnya persyaratan yg terdokumentasi kurangnya ruang lingkup PL lingkungan pengembangan yg buruk

RISIKO PERANGKAT LUNAK (cont.)

RPL 10

@ 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 PERANGKAT LUNAK (cont.)

RPL 11

@ Risiko yg tidak diharapkan risiko ini dapat benar-benar terjadi, tetapi

sangat sulit untuk diidentifikasi sebelumnya.

RISIKO PERANGKAT LUNAK (cont.)

RPL 12

IDENTIFIKASI RISIKO Usaha sistematis untuk menentukan ancaman terhadap rencana proyek. Tujuan identifikasi risiko :

untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap saatdiperlukan.

Tipe risiko : risiko generik

merupakan ancaman potensial pd setiap proyek PL. risiko produk spesifik

hanya dapat diidentifikasi dgn pemahaman khusus mengenai teknologi, manusia, sertalingkungan yg spesifik terhadap proyek yg ada.

Metode untuk mengidentifikasi resiko adalah menciptakan checklist item risiko.

RPL 13

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

IDENTIFIKASI RISIKO

RPL 14

KOMPONEN RISIKO dan DRIVER Pedoman untuk mengidentifikasi risiko PL dan

pengurangannya yaitu menghendaki agar manajer proyekmengidentifikasi risiko driver yg mempengaruhi komponenrisiko 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.

RPL 15

PROYEKSI RISIKO/ PERKIRAANRISIKO Dua cara melakukan proyeksi risiko :

Probabilitas di mana risiko adalah nyata Konsekuensi masalah yang berhubungan dengan risiko

Perencanaan proyek bersama dengan manajer & staf teknikmelakukan 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

tidak ada kesalahpahaman

RPL 16

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 keseluruhandistribusi ( berapa banyak proyek yg akan dipengaruhiatau berapa banyak pelanggan terganggu ? )

Timingnya; mempertimbangkan kapan dan untuk berapalama pengaruh itu dirasakan.

RPL 17

Pengurangan, Monitoring danManajemen Resiko

Tujuan analisis resiko – membantu tim proyek dalam mengembangkanstrategi 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 indikasiapakah resiko sedang menjadi lebih atau kurang mungkin

Memonitor efektivitas langkah pengurangan resiko Manajemen resiko dan perencanaan kemungkinan

Mengasumsikan bahwa usaha pengurangan telah gagal dan bahwaresiko telah menjadi kenyataan

RPL 18

Resiko Keselamatan dan Bahaya Resiko dapat terjadi setelah perangkat lunak dikembangkan dengan

sukses dan dikirim ke pelanggan

Resiko secara khusus berhubungan dengan konsekuensi kegagalanperangkat lunak dilapangan

Keselamatan perangkat lunak dan analisis bahaya adalah aktivitasjaminan kualitas perangkat lunak yang berfokus pada identifikasi danperkiraan bahaya potensial yang dapat mempengaruhi perangkatlunak secara negatif dan menyebabkan keseluruhan sistem menjadigagal

RPL 19

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 monitoringdimulai.

RPL 20

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

mana yang menyebabkan resiko) pada keseluruhan proyek

JAMINAN KUALITAS PERANGKATLUNAK

(SOFTWARE QUALITY ASSURANCE)

RPL 22

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 mekanisme pengukuran dan pelaporan.

RPL 23

KONTROL KUALITAS Kontrol kualitas merupakan serangkaian pemeriksaan,

kajian, dan pengujian yang digunakan pada keseluruhansiklus pengembangan untuk memastikan bahwa setiapproduk memenuhi persyaratan yang ditetapkan.

Konsep kunci kualitas kontrol adalah bahwa semuaproduk kerja memiliki spesifikasi yang telah ditentukandan dapat diukur dimana kita dapat membandingkanoutput dari setiap proses.

Kalang (loop) menjadi penting untuk meminimalkan cacatyang dihasilkan.

RPL 24

JAMINAN KUALAITAS

Jaminan kualitas terdiri atas fungsi auditing danpelaporan manajemen.

Tujuan jaminan kualitas adalah :untuk memberikan data yang diperlukan olehmanajemen untuk menginformasikan masalahkualitas produk, sehingga dapat memberikankepastian & konfidensi bahwa kulitas produkdapat memenuhi sasaran.

RPL 25

BIAYA KUALITAS

Biaya kualitas menyangkut semua biaya yang diadakanuntuk mengejar kualitas atau untuk menampilkan kualitasyang berhubungan dengan aktivitas.

Biaya kualitas dapat dibagi ke dalam biaya-biaya yangdihubungkan dengan : pencegahan penilaian kegagalan.

RPL 26

DEFINISI KUALITAS PL

Kualitas perangkat lunak didefinisikan sebagai:Konformansi terhadap kebutuhan fungsional dan

kinerja yang dinyatakan secara eksplisit, standarperkembangan yang didokumentasikan secaraeksplisit, dan karakteristik implisit yang diharapkanbagi semua perangkat lunak dikembangkan secaraprofesional.

RPL 27

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 perangkatlunak direkayasa.

Ada serangkaian kebutuhan implisit yang seringdicantumkan (misalnya kebutuhan akan kemampuanpemeliharaan yang baik).

RPL 28

DEFINISI KUALITAS PL (cont.) Kelompok SQA berfungsi sebagai perwakilan in-house pelanggan, yaitu orang yang akan melakukanSQA harus memperhatikan perangkat lunak darisudut 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?

RPL 29

AKTIVITAS SQA

Jaminan kualitas perangkat lunak terdiri dariberbagai tugas yang berhubungan dengan duakonstituen yang berbeda : perekayasa perangkat lunak yang mengerjakan kerja teknis kelompok SQA yang bertanggung jawab terhadap

perencanaan jaminan kualitas, kesalahan, penyimpananrekaman, analisis, dan pelaporan.

RPL 30

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 pdberbagai titik selama pengembangan PL & berfungsiuntuk mencari kesalahan yg kemudian akan dihilangkan.

Kajian perangkat lunak berfungsi untuk “memurnikan”produk kerja perangkat lunak yang terjadi sebagai hasildari analisis, desain, dan pengkodean.

RPL 31

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 terbuktisangat efektif untuk menemukan kesalahan.

Keuntungan utama kajian teknis formal adalah penemuankesalahan sejak awal sehingga tidak berlanjut ke langkahselanjutnya dalam proses perangkat lunak.

RPL 32

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

cara yang seragam; Membuat proyek lebih dapat dikelola.

RPL 33

Formal Technic Review – FTR (cont.)

FTR berfungsidasar pelatihan yang memungkinkan perekayasa yunior

mengamati berbagai pendekatan yang berbedaterhadap analisis perangkat lunak, desain, danimplementasi.

mengembangkan backup dan kontinuitas karenasejumlah orang mengenal baik bagian-bagianperangkat lunak yang tidak mereka ketahui sebelumnya.

RPL 34

PERTEMUAN KAJIAN

Tanpa memperhatikan format FTR yang dipilih, setiappertemuan kajian harus mematuhi batasan-batasan berikutini : 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 bagisetiap person

Durasi pertemuan kajian harus kurang dari 2 jam

RPL 35

PERTEMUAN KAJIAN (cont.)

Pada akhir kajian, semua peserta FTR yang hadir harusmemutuskan apakah akan ....(ada 3) kemudian ambilkeputusan

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

RPL 36

PENDEKATAN FORMAL TERHADAP SQA

Kualitas perangat lunak merupakan tugas setiaporang & kualitas dapat dicapai melalui analisis,desain, pengkodean, dan pengujian yang baik sertaaplikasi standar pengembangan perangkat lunakyang diterima.