Dokumen tersebut membahas manajemen resiko dalam pengembangan perangkat lunak. Secara khusus, dibahas tentang definisi konsep resiko, strategi penanganan resiko secara reaktif maupun proaktif, jenis-jenis resiko yang mungkin timbul seperti resiko proyek, teknis, dan bisnis, serta cara mengidentifikasi berbagai resiko tersebut dengan menggunakan daftar pertanyaan pada berbagai aspek pengembangan perangkat lunak.

1. Pertemuan 6
Manajemen resiko
By : anisah 41812110004

2. DEFINISI KONSEPTUAL :
1. Resiko berhubungan dengan kejadian dimasa yang akan datang
2. Resiko melibatkan perubahan (pikiran, pendapat, aksi atau tempat)
3. Resiko melibatkan pilihan dan ketidakpastian bahwa pilihan itu akan dilakukan
Bila dikaitkan dengan konteks rekayasa perangkat lunak, maka :
• Kondisi apa yang menyebabkan adanya resiko sehingga menyebabkan proyek perangkat
lunak menjadi serba salah ?
• Bagaimana perubahan pada persyaratan pelanggan, teknologi pengembangan, target dan
semua entitas lain yang berhubungan dengan proyek, ketepatan waktu dan keberhasilan
keseluruhan.
• Kita harus ”bergulat” dengan banyak pilihan, metode dan piranti apa yang harus digunakan,
berapa banyak orang yang harus dilibatkan
STRATEGI RESIKO REAKTIF VS PROAKTIF
Strategi reaktif, bila pada titik terbaik, akan :
a. Memonitor proyek terhadap kemungkinan resiko
b. Sumber-sumber daya dikesampingkan
c. Tim perangkat lunak tidak akan berbuat apa-apa diseputar resiko sampai sesuatu yang buruk
terjadi
d. Kemudian tim akan melakukan aksi untuk membetulkan masalah itu dengan cepat

3. Strategi Proaktif
Ciri strategi ini :
a. Dimulai lama sebelum kerja teknis diawali
b. Resiko potensial di identifikasi
c. Probabilitas dan pengaruh proyek diperkirakan serta diprioitaskan menurut kepenting an.
RESIKO PERANGKAT LUNAK
Dua karakteristik utama yang selalu ada dalam resiko perangkat lunak yaitu :
1. Ketidakpastian (uncertainty) => kejadian yang menandai resiko mungkin atau tidak mungkin
terjadi.
2. Rugi (loss) => bila resiko menjadi realitas, akibat tidak yang tidak diinginkan atau kerugian
akan dialami.
KATAGORI RESIKO
Penting untuk mengkuantifikasi tingkat ketidak pastian dan tingkat kerugian, sehubungan
dengan masing-masing resiko. Untuk melakukannya, perlu diperhatikan katagori nya.
a. Resiko proyek
• resiko yang bila menjadi kenyataan, ada kemungkinan jadual proyek akan mengalami
slip dan biaya akan bertambah
• resiko ini mengidentifikasi hal potensial yang berhubungan dengan pembiayaan, jadual,
personil (staffing dan organisasi), sumber-sumber daya, pelanggan dan masalah
persyaratan serta pengaruhnya pada proyek PL

4. b. Resiko teknis
• resiko ini mengancam kualitas dan ketepatan waktu PL yang akan dihasilkan.
• bila menjadi kenyataan, implementasinya menjadi sangat sulit
• resiko ini mengidentifikasi desain potensial, implementasi, interfacing, verifikasi dan
masalah pemeliharaan
• faktor resiko lain yang perlu diperhatikan seperti ambiguitas, spesifikasi, ketidakpastian
teknik, keusangan teknik dan teknologi yang leading edge
c. Resiko bisnis
resiko ini dapat membahayakan proyek atau produk. Kandidat untuk lima resiko bisnis yang
utama dapat berupa :
• pembangunan produk atau sistem yang baik sekali yang sebenarnya tidak pernah
diinginkan oleh setiap orang (resiko pasar)
• pembangunan sebuah produk yang tidak lagi sesuai dengan keseluruhan (resiko
strategi)
• pembangunan sebuah produk dimana bagian pemasaran tidak tahu bagaimana
menjualnya
• kehilangan dukungan manajemen senior sehubungan dengan perubahan pada
fokus atau perubahan pada manusia (resiko manajemen)
• kehilangan hal-hal yang berhubungan dengan biaya atau komitmen personal (resiko
biaya)

5. IDENTIFIKASI RESIKO (Risk Identification)
Merupakan usaha sistematis untuk menentukan ancaman terhadap rencana proyek (perkiraan,
jadual, pemuatan sumber daya, dll)
Ada dua tipe resiko yang berbeda bagi masing-masing katagori yaitu resiko generik dan resiko
produk spesifik.
• Resiko generik merupakan ancaman potensial pada setiap proyek perangkat lunak.
• Resiko produk spesifik hanya dapat diidentifikasi oleh mereka dengan pemahaman khusus
mengenai teknologi tersebut, manusia serta lingkungan yang spesifik terhadap proyek yang
ada.
BAGAIMANA MENGIDENTIFIKASI RESIKO ?
Ciptakan checklist item resiko yang berfokus kepada beberapa himpunan bagian yang sudah
diketahui dan diprediksi sebagai berikut :
• Ukuran produk => dihubungkan dengan keseluruhan ukuran perangkat lunak yang akan
dibangun / dimodifikasi
• Pengaruh bisnis => dihubungkan dengan batasan yang dibebankan oleh manajemen / pasar
• Karakteristik pelanggan => dihubungkan dengan kepintaran pelanggan dan kemampuan
pengembang untuk berkomunikasi dengan pelanggan dengan cara yang tepat
• Definisi proses => dihubungkan dengan tingkat dimana proses perangkat lunak telah
didefinisikan dan diikuti oleh organisasi
• Lingkaran pengembangan => dihubungkan dengan keberadaan dan kualitas piranti yang akan
digunakan untuk membangun produk

6. • Teknologi yang akan dibangun => dihubungkan dengan kompleksitas system yang akan
dibangun dan kebaruan teknologi yang dikemas oleh system
• Ukuran dan pengalaman staf => dihubungkan dengan keseluruhan teknik dan pengalaman
proyek dari perekayasa perangkat lunak yang akan melakukan tugas tersebut.
RESIKO UKURAN PRODUK
Muncul pertanyaan : apakah resiko proyek berbanding langsung dengan ukuran ?. Untuk
mengetahuinya, check list item berikut :
• Ukuran produk diperkirakan dalam LOC atau FP ?
• Tingkat kepercayaan dalam estimasi ukuran yang diperkirakan ?
• Ukuran produk yang diestimasi dalam jumlah program, file , transaksi ?
• Persentase deviasi dalam ukuran produk dari rata-rata produk terakhir ?
• Ukuran data base yang dibuat, digunakan oleh produk ?
• Berapa jumlah pemakai produk ?
• Jumlah perangkat lunak yang digunakan kembali ?
RESIKO-RESIKO YANG MEMPENGARUHI BISNIS
Checklist item berikut untuk mengidentifikasi resiko generic sehubungan dengan
pengaruh bisnis :
• Bagaimana pengaruh produk terhadap hasil perusahaan ?
• Bagaimana visibilitas produk terhadap manajemen senior ?
• Kelayakan deadline penyampaian ?
• Jumlah pelanggan yang akan menggunakan produk dan konsistensi kebutuhan relative
mereka dengan produk tersebut ?

7. • Jumlah produk / system lain dengan apa produk ini harus dapat saling dioperasikan ?
• Kepintaran pemakai akhir ?
• Jumlah dan kualitas dokumentasi produk yang harus diproduksi dan disampaikan kepada
pelanggan ?
• Batasan pemerintahan pada konstruksi produk ?
• Biaya yang berhubungan dengan penyampaian yang terlambat ?
• Biaya yang berhubungan dengan produk defektif ?
RESIKO YANG DIHUBUNGKAN DENGAN PELANGGAN
Semua pelanggan tidak diciptakan sama. Pembahasan Presman menyatakan bahwa :
• Pelanggan mempunyai keinginan yang berbeda
o Ada yang tahu apa yang mereka inginkan, yang lain tidak
o Banyak yang mau merinci detail (keinginan) nya, sementara yang lain cukup dengan
janji-janji kosong.
• Pelanggan memiliki kepribadian yang berbeda
o Ada yang menikmatinya sebagai pelanggan / rekanan, negosiasi atau penghargaan
psikologis dari suatu produk yang baik, sementara yang lainnya tidak ingin menjadi
pelanggan sama sekali.
o Beberapa akan gembira menerima hampir semua yang disampaikan, sementara yang
lainnya akan mengeluh
• Pelanggan memiliki hubungan yang bervariasi dengan pemasok
o Beberapa mengenali produk dan produsen secara baik, namun sebagian lagi hanya
berkomunikasi via telepon, email ataupun surat

8. • Pelanggan kadang-kadang juga bertentangan
o Ada yang menginginkan semua yang ada secara gratis, namun ada yang “terperangkap”
diantara kontradiksi dalam diri mereka sendiri
Jika ditinjau lebih dalam dari sisi resiko yang berhubungan dengan pelanggan yang berbeda,
dapat kita tanyakan pada checklist berikut :
• Pernahkah anda sebelumnya bekerja dengan pelanggan ?
• Apakah pelanggan memiliki gagasan yang solid tentang apa yang diperlukannya ? dan
sudahkah pelanggan menggunakan waktunya untuk menuliskannya ?
• Apakah pelanggan akan setuju dengan penggunaan waktu untuk mengidentifikasi ruang
lingkup proyek ?
• Apakah pelanggan bersedia membangun komunikasi yang cepat dengan pengembang ?
• Apakah pelanggan bersedia berpartisipasi dalam kajian ?
• Apakah pelanggan secara teknis pandai dalam area produk tersebut ?
• Apakah pelanggan memahami proses perangkat lunak tersebut ?
MASALAH-MASALAH PROSES.
• Apakah manajer senior anda mendukung pernyataan kebijaksanaan pengambangan proses ?
• Sudahkah organisasi anda menggunakan deskripsi tertulis dalam proses pengembangan
perangkat lunak
• Apakah anggota / staf bersedia ditugasi ke proses PL untuk selanjutnya didokumentasikan ?

9. • Apakah proses perangkat lunak juga digunakan untuk proyek lain ?
• Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian kursus pelatihan
rekayasa perangkat lunak bagi para manajer dan staf teknik ?
• Apakah standar rekayasa perangkat lunak yang diterbitkan disediakan untuk setiap
pengembang perangkat lunak dan manajer perangkat lunak ?
• Sudahkah dokumen outline dan contoh-contoh dikembangkan untuk semua yang ditentukan
sebagai bagian yang dapat disampaikan sebagai bagian dari proses perangkat lunak ?
• Apakah kajian teknis dilakukan secara regular ?
• Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan dan rencana
pengembangan yang didokumentasikan, termasuk kesalahan yang ditemukan dan sumber
daya yang digunakan ?
• Apakah mekanisme untuk memastikan bahwa yang dilakukan pada suatu proyek sesuai
dengan standar rekayasa perangkat lunak ?
• Apakah manajemen konfigurasi digunakan untuk memelihara konsistensi diantara sistem /
persyaratan perangkat lunak, desain, kode dan test case ?
• Apakah digunakan suatu mekanisme untuk mengontrol perubahan ke persyaratan pelanggan
yang mempengaruhi perangkat lunak ?
• Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan dan rencana
pengembangan perangkat lunak yang didokumentasikan untuk masing-masing subkontrak ?
• Apakah ada prosedur untuk menelusuri dan mengkaji kinerja subkontrak ?

10. MASALAH MASALAH TEKNIS.
• Apakah teknik spesifikasi aplikasi untuk membangun komunikasi ?
• Apakah sudah digunakan metode spesifik untuk analisis PL ?
• Apakah anda melihat suatu metode spesifik untk data dan desain arsitektur ?
• Apakah 90% dari kode anda ditulis dengan orde bahasa yang lebih tinggi ?
• Apakah ada konvensi khusus untuk definisi dokumentasi ?
• Apakah anda menggunakan metode spesifik untuk desain test case ?
• Apakah digunakan piranti Perangkat Lunak untuk mendukung perencanaan dan aktivitas
penelusuran ?
• Apakah digunakan piranti perangkat lunak manajemen konfigurasi untuk mengontrol da
menelusuri aktivitas perubahan di seluruh proses PL ?
• Apakah digunakan piranti Perangkat Lunak untuk mendukung analisis PL dan desain proses ?
• Apakah digunakan piranti untuk menciptakan prototype Perangkat Lunak ?
• Apakah digunakan piranti Perangkat Lunak untuk mendukung proses pengujian ?
• Apakah piranti Perangkat Lunak digunakan untuk mendukung produksi dan manajemen
dokumentasi ?
• Apakah metric kualitas dikumpulkan bagi semua proyek ?
• Apakah metric produktivitas dikumpulkan bagi semua proyek perangkat lunak ?
Bila mayoritas jawaban terhadap pertanyaan tersebut di atas adalah “TIDAK”, maka proses
perangkat lunak lemah dan beresiko tinggi

11. RESIKO TEKNOLOGI
Resiko ini sangat sulit untuk diramalkan. Sebaiknya cek pertanyaan berikut untuk
mengidentifikasi resiko generic yang berhubungan dengan teknologi yang akan dibangun :
• Apakah teknologi yang akan dibangun adalah hal yang baru untuk organisasi anda ?
• Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi input atau
output ?
• Apakah perangkat lunak (yang ada) ber interface dengan perangkat lunak baru atau belum
terbukti ?
• Apakah perangkat lunak yang akan dibangun ber-interface dengan produk PL yang dipasok
oleh vendor yang belum terbukti ?
• Apakah perangkat lunak yang akan dibangun ber-interface dengan suatu system database
yang fungsi dan kinerjanya belum dibuktikan di dalam area aplikasi ini ?
• Apakah diperlukan interface pemakai khusus oleh persyaratan produk ?
• Apakah persyaratan untuk produk memerlukan kreasi komponen program yang tidak sama
dengan yang dikembangkan terakhir oleh organisasi anda ?
• Apakah persyaratan memerlukan metode pengambangan perangkat lunak tidak
konvensional, seperti metode formal, pendekatan AI-based dan jaringan syaraf buatan ?
• Apakah persyaratan meletakkan batasan kerja yang eksesif pada produk tersebut ?
• Apakah pelanggan tidak yakin bahwa fungsionalitas yang diminta dapat dipenuhi ?.
Bila jawaban dari pertanyaan-pertanyaan di atas adalah “YA”, penyelidikan lebih lanjut harus
dilakukan untuk memperkirakan resiko potensial

12. RESIKO LINGKUNGAN PENGEMBANGAN
Lingkungan yang salah, dapat menjadi sumber resiko yang tinggi. Checklist item resiko berikut ini
untuk mengidentifikasi resiko generic yang berhubungan dengan lingkungan
pengembangan :
• Apakah piranti manajemen proyek dapat diperoleh ?
• Apakah piranti manajemen proses dapat diperoleh ?
• Apakah piranti untuk analisis dan desain dapat diperoleh ?
• Apakah piranti analisis dan desain penyampaian metoe sesuai bagi produk yang akan
dibangun ?
• Apakah diperoleh compiler atau generasi kode dapat dan sesuai dengan produk yang akan
dibangun ?
• Apakah piranti pengujian dapat diperoleh dan sesuai dengan produk yang akan dibangun ?
• Apakah piranti manajemen konfigurasi perangkat lunak dapat diperoleh ?
• Apakah lingkungan menggunakan suatu database atau tempat penyimpanan ?
• Apakah semua piranti perangkat lunak diintegrasikan satu dengan lainnya ?
• Sudahkan anggota tim proyek menerima pelatihan dengan masing-masing piranti ?
• Apakah ada pakar local untuk menjawab pertanyaan pertanyaan mengenai piranti tersebut ?
• Apakah bantuan dan dokumentasi on line bagi piranti memadai ?
Bila mayoritas jawaban adalah “TIDAK”, berarti lingkungan pengembangan perangkat lunak
lemah dan beresiko tinggi.

13. RESIKO YANG BERHUBUNGAN DENGAN UKURAN STAF DAN PENGALAMAN.
Hendaknya dijawab pertanyaan-pertanyaan berikut agar bisa memperkirakan resiko yang
berhubungan dengan ukuran staf dan pengalaman :
• Apakah orang-orang terbaik didapatkan ?
• Apakah orang-orang tersebut memiliki gabungan ketrampilan yang benar ?
• Apakah orang-orang yang ada mencukupi ?
• Apakah staf yang ada dimasukkan ke dalam seluruh durasi proyek ?
• Apakah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini ?
• Apakah staf memiliki pengharapan yang tepat mengenai pekerjaan yang ada sekarang ?
• Sudahkah staf menerima pelatihan yang memadai ?
• Apakah pergantian diantara staf akan cukup rendah untuk memungkinan kontinuitas ?
Bila mayoritas jawaban adalah “TIDAK”, maka penyelidikan lebih lanjut harus dilakukan untuk
memperkirakan resiko potensial.

14. RANGKUMAN
Setelah melihat berbagai kemungkinan resiko yang bias timbul, banyak hal yang mengendalikan
proyek perangkat lunak, tetapi akal sehat akan menentukan analisis resiko. Bahkan sebagian
besar manajer proyek melakukannya secara informal dan superficial, bila mereka benar-benar
melakukannya.
Waktu yang dipergunakan untuk meng-identifikasi, menganalisis dan mengatur resiko dalam
beberapa cara mengakibatkan :
• Sedikit kehobohan selama proyek berlangsung
• Kemampuan yang lebih baik untuk menelusuri dan mengontrol suatu proyek
• Konfidensi yang muncul bersama dengan perencanaan untuk masalah sebelum masalah ini
terjadi
Analisis resiko dapat menyerap usaha perencanaan proyek. Identifikasi proyeksi, perkiraan,
manajemen dan monitoring, semuanya akan makan waktu. Tetapi semua usaha itu sangat
berharga, seperti yang dikatakan oleh Sun Tzu, seorang jenderal Cina yang hidup 2500 tahun
yang lalu, “Jika Anda mengenali musuh dan mengenali diri Anda sendiri , Anda tidak perlu
mengkhawatirkan hasil dari ratusan pertempuran”. Bagi manajer perangkat lunak, musuhnya
adalah resiko.