1. Buku Ajar Rekayasa Perangkat Lunak
BAB 5
Manajemen Risiko
Kompetensi Dasar :
Mahasiswa memahami maksud dari manajemen risiko dan dapat
menerapkannya pada proyek perangkat lunak.
1. Risiko perangkat lunak.
Risiko selalu melibatkan dua karakteristik :
 Ketidakpastian – kejadian yang menandai risiko mungkin
atau tidak mungkin terjadi.
 Rugi – bila risiko menjadi kenyataan, akibat yang tidak
diinginkan atau kerugian akan dialami.
Pada saat risiko dianalisis, penting untuk mengkuantifikasi
tingkat ketidakpastian dan tingkat kerugian sehubungan
dengan masing-masing risiko. Untuk melakukannya,
perhatikan kategori risiko yang berbeda.
Risiko proyek mengancam rencana proyek. Yaitu bila risiko
proyek menjadi nyata, ada kemungkinan jadwal proyek akan
mengalami slip dan biaya akan menjadi bertambah. Risiko
proyek mengidentifikasi hal potensial yang berhubungan
dengan pembiayaan, jadwal, personil, sumber-sumber daya,
pelanggan dan masalah persyaratan serta pengaruhnya
terhadap proyek perangkat lunak.
Risiko teknis mengancam kualitas dan ketepatan waktu
perangkat lunak yang akan dihasilkan. Bila risiko teknis
menjadi kenyataan, implementasinya menjadi sangat sulit
atau tidak mungkin. Risiko teknis mengidentifikasi desain
potensial, implementasi, interfacing, verifikasi dan masalah
pemeliharaan. Ambiguitas, spesifikasi, ketidakpastian teknik,
keusangan teknik dan teknologi yang leading edge juga
merupakan faktor risiko. Risiko teknis terjadi karena
masalahnya ternyata lebih sulit untuk dipecahkan daripada
yang dipikirkan.
53

2. Buku Ajar Rekayasa Perangkat Lunak
Risiko bisnis mengancam visibilitas perangkat lunak yang akan
dibangun. Risiko bisnis membahayakan proyek atau produk.
Kandidat untuk lima risiko bisnis utama adalah :
 Pembangunan produk atau sistem yang baik sekali yang
sebenarnya tidak pernah diinginkan oleh setiap orang
(risiko pasar).
 Pembangunan sebuah produk yang tidak sesuai lagi
dengan keseluruhan strategi bisnis bagi perusahaan (risiko
strategi).
 Pembangunan sebuah produk di mana bagian
pemasaran tidak tahu bagaimana harus menjualnya.
 Kehilangan dukungan manajemen senior sehubungan
dengan perubahan pada fokus atau perubahan pada
manusia (risiko manajemen).
 Kehilangan hal-hal yang berhubungan dengan biaya
atau komitmen personal (risiko biaya).
Sangat penting untuk dicatat bahwa kategorisasi sederhana
tidak akan selalu bekerja. Banyak risiko sangat tidak dapat
diramalkan sebelumnya.
Kategorisasi risiko umum lainnya ialah :
 Risiko yang sudah diketahui adalah risiko yang dapat
diungkap setelah dilakukan evaluasi secara hati-hati
terhadap rencana proyek, bisnis dan lingkungan teknik di
mana proyek sedang dikembangkan dan sumber
informasi reliabel lainnya seperti tanggal penyampaian
yang tidak realistis, kurangnya persyaratan yang
terdokumentasi atau ruang lingkup perangkat lunak,
lingkungan pengembangan yang buruk.
 Risiko yang dapat diramalkan diekstrapolasi dari
pengalaman proyek sebelumnya misalnya pergantian
staf, komunikasi yang buruk dengan para pelanggan,
mengurangi usaha staf bila permintaan pemeliharaan
yang sedang berlangsung dilayani.
 Risiko yang tidak diharapkan dapat benar-benar terjadi,
tetapi sangat sulit untuk diidentifikasikan sebelumnya.
2. Identifikasi risiko.
Identifikasi risiko adalah usaha sistematis untuk menentukan
ancaman terhadap rencana proyek. Dengan mengiden-
tifikasi risiko yang sudah diketahui dan dapat diprediksi,
54

3. Buku Ajar Rekayasa Perangkat Lunak
manajer proyek mengambil langkah pertama ke depan untuk
menghindari risiko bilamana mungkin, serta menghindarinya
setiap saat diperlukan.
Risiko generik merupakan ancaman potensial pada setiap
proyek perangkat lunak. Risiko produk spesifik hanya dapat
diidentifikasi oleh orang yang memiliki pemahaman khusus
mengenai teknologi tersebut, manusia serta lingkungan yang
spesifik terhadap proyek yang ada. Untuk mengidentifikasi
risiko produk spesifik, rencana proyek dan pernyataan ruang
lingkup perangkat lunak diuji dan dikembangkan jawaban
terhadap pertanyaan-pertanyaan berikut : “karakteristik
khusus apa dari produk ini yang mengancam rencana proyek
kita ?”. Oleh karena itu baik risiko generik maupun produk
spesifik harus diidentifikasi secara skematis.
Metode untuk mengidentifikasi risiko adalah menciptakan
checklist item risiko. Checklist dapat dipergunakan pada
identifikasi risiko dan berfokus pada beberapa himpunan
bagian risiko yang sudah diketahui dan diprediksi dalam
subkategori berikut ini :
 Ukuran produk – risiko yang sehubungan dengan
keseluruhan ukuran perangkat lunak yang akan dibangun
atau dimodifikasi.
 Pengaruh bisnis – risiko yang sehubungan dengan
batasan yang dibebankan oleh manajemen atau pasar.
 Karakteristik pelanggan – risiko yang sehubungan dengan
kepintaran pelanggan dan kemampuan pengembang
untuk berkomunikasi dengan pelanggan dengan cara
yang tepat.
 Definisi proses – risiko yang sehubungan dengan tingkat di
mana proses perangkat lunak telah didefinisikan dan
diikuti oleh organisasi pengembangan.
 Lingkungan pengembangan – risiko yang sehubungan
dengan keberadaan dan kualitas peranti yang akan
digunakan untuk membangun produk.
 Teknologi yang akan dibangun – risiko yang sehubungan
dengan kompleksitas sistem yang akan dibangun dan
kemutakhiran teknologi yang dikemas oleh sistem.
 Ukuran dan pengalaman staf – risiko yang sehubungan
dengan keseluruhan teknik dan pengalaman proyek dari
55

4. Buku Ajar Rekayasa Perangkat Lunak
perekayasa perangkat lunak yang akan melakukan tugas
tersebut.
Checklist item risiko dapat dikumpulkan dengan cara yang
berbeda. Pertanyaan-pertanyaan yang relevan dengan
masing-masing topik tersebut dapat dijawab untuk masing-
masing proyek perangkat lunak. Jawaban terhadap
pertanyaan-pertanyaan itu memungkinkan perencana
memperkirakan pengaruh risiko. Format checklist item risiko
yang berbeda secara jelas mendaftar karakteristik yang
relevan dengan masing-masing subkategori generik. Akhirnya,
serangkaian “komponen dan pengendali risiko” didaftar
bersama dengan kemungkinan kejadiannya. Pengendali-
pengendali untuk kinerja, dukungan, biaya dan jadwal
dibicarakan untuk menjawab pertanyaan terakhir tersebut.
2.1. Risiko ukuran poduk.
Checklist item risiko berikut mengidentifikasi risiko generik
yang berhubungan dengan ukuran produk perangkat
lunak :
 Ukuran produk diperkirakan dalam LOC atau FP.
 Tingkat kepercayaan dalam estimasi ukuran yang
diperkirakan.
 Ukuran produk yang diperkirakan dalam hal jumlah
program, file dan transaksi.
 Prosentase deviasi (penyimpangan) dalam ukuran
produk dari rata-rata produk terakhir.
 Ukuran database yang dibuat atau digunakan oleh
produk.
 Jumlah pemakai produk.
 Jumlah perubahan yang diproyeksikan ke
persyaratan produk sebelum penyampaian dan
sesudah penyampaian.
 Jumlah perangkat lunak yang digunakan kembali.
Dalam masing-masing kasus, informasi untuk produk yang
akan dikembangkan harus dibandingkan dengan
pengalaman sebelumnya. Bila prosentase deviasi besar,
atau jika deviasinya sama, tetapi hasil yang lalu sangat
kurang dari yang diharapkan, maka berarti risikonya
tinggi.
2.2. Risiko-risiko yang mempengaruhi bisnis.
56

5. Buku Ajar Rekayasa Perangkat Lunak
Bagian pemasaran dikendalikan oleh pertimbangan
bisnis, dan pertimbangan bisnis kadang menaglami
konflik langsung dengan kenyataan teknis. Checklist item
risiko berikut ini mengidentifikasi risiko generik sehubungan
dengan pengaruh bisnis :
 Pengaruh produk terhadap hasil perusahaan.
 Visibilitas produk terhadap manajemen senior.
 Kelayakan batas akhir penyampaian.
 Jumlah pelanggan yang akan menggunakan produk
dan konsistensi kebutuhan relatif mereka dengan
produk tersebut.
 Jumlah produk / sistem 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.
Masing-masing respon bagi produk yang akan
dikembangkan harus dibandingkan dengan
pengalaman sebelumnya. Bila prosentase deviasi besar,
atau jika deviasinya sama, tetapi hasil yang lalu sangat
kurang dari yang diharapkan, maka berarti risikonya
tinggi.
2.3. Risiko yang dihubungkan dengan pelanggan.
Semua pelanggan tidak diciptakan sama. Pressman dan
Heron membahas masalah ini dengan menyatakan :
 Pelanggan mempunyai keinginan yang berbeda.
 Pelanggan memiliki kepribadian yang berbeda.
 Pelanggan juga memiliki hubungan yang bervariasi
dengan pemasok mereka.
 Pelanggan juga kadang-kadang bertentangan.
Pelanggan yang buruk dapat besar pengaruhnya
terhadap kemampuan tim perangkat lunak untuk
menyelesaikan suatu proyek tepat waktu dan sesuai
anggaran. Pelanggan yang buruk menghadirkan
ancaman besar terhadap rencana proyek dan
57

6. Buku Ajar Rekayasa Perangkat Lunak
merupakan risiko substansial bagi manajer proyek.
Checklist item risiko berikut mengidentifikasi risiko-risiko
generik yang berhubungan dengan para pelanggan
yang berbeda :
 Pengalaman perekayasa bekerja dengan
pelanggan.
 Gagasan yang solid dari pelanggan mengenai apa
yang diperlukannya dan kesempatan untuk
menuliskannya.
 Persetujuan pelanggan dengan penggunaan waktu
dalam pertemuan pengumpulan persyaratan formal
untuk mengidentifikasi ruang lingkup proyek.
 Kesediaan pelanggan membangun sambungan
komunikasi cepat dengan pengembang.
 Kesediaan pelanggan berpartisipasi dalam kajian.
 Kepandaian pelanggan secara teknis dalam area
produk tersebut.
 Kesediaan pelanggan membiarkan orang-orang
melakukan pekerjaan mereka – yaitu apakah
pelanggan akan menolak untuk mengawasi
perekayasa selama kerja detil secara teknis.
 Pemahaman pelanggan pada proses perangkat
lunak tersebut.
Bila jawaban terhadap setiap pertanyaan tersebut
adalah “tidak” maka investigasi lebih jauh harus
dilakukan untuk memperkirakan potensi risiko.
2.4. Risiko proses.
Bila proses perangkat lunak adalah terdfinisi sakit; bila
analisis, desain dan pengujian dilakukan secara ad hoc;
bila kualitas merupakan sebuah konsep yang disetujui
oleh setiap orang sebagai sesuatu hal yang penting,
tetapi tidak ada seorangpun bertindak untuk
mencapainya dengan setiap cara yang dapat
dilakukan, maka proyek tersebut berisiko.
Masalah-masalah proses
 Dukungan manajemen senior terhadap suatu
pernyataan kebijaksanaan yang menekankan
pentingnya suatu proses standar untuk
pengembangan proses.
58

7. Buku Ajar Rekayasa Perangkat Lunak
 Adanya pengembangan suatu deskripsi tertulis
dalam organisasi mengenai proses perangkat lunak
yang akan digunakan pada proyek ini.
 Penugasan anggota-anggota staf pada proses
perangkat lunak pada saat didokumentasikan dan
kesediaan menggunakannya.
 Penggunaan proses perangkat lunak untuk proyek
lain.
 Pengembangan atau pelatihan rekayasa perangkat
lunak bagi para manajer dan staf teknik.
 Standarisasi rekayasa perangkat lunak yang
diterbitkan disediakan untuk setiap pengembang
perangkat lunak dan manajer perangkat lunak.
 Dokumentasi dan contoh-contoh dikembangkan
untuk semua yang ditentukan sebagai bagian yang
dapat disampaikan dari proses perangkat lunak.
 Pengkajian teknis formal secara reguler terhadap
spesifikasi persyaratan, desain dan kode serta
prosedur pengujian.
 Dokumentasi hasil dari masing-masing kajian teknis
formal termasuk kesalahan yang ditemukan dan
sumber daya yang digunakan.
 Kesesuaian mekanisme untuk memastikan bahwa
kerja yang dilakukan pada suatu proyek.
 Penggunaan manajemen konfigurasi untuk
memelihara konsistensi antara sistem / persyaratan
perangkat lunak, desain, kode dan test case.
 Penggunaan mekanisme pengontrolan perubahan
ke persyaratan pelanggan yang mempengaruhi
perangkat lunak.
 Adanya pernyataan mengenai kerja, spesifikasi
persyaratan pelanggan dan rencana pengembang-
an perangkat lunak yang didokumentasikan untuk
setiap subkontrak.
 Adanya prosedur untuk menelusuri dan mengkaji
kinerja subkontrak.
Masalah-masalah teknis.
 Penggunaan teknik spesifikasi aplikasi untuk
membantu komunikasi antara pelanggan dan
pengembang.
59

8. Buku Ajar Rekayasa Perangkat Lunak
 Penggunaan metode tertentu untuk analisis
perangkat lunak, data dan desain arsitektur.
 Penggunaan bahasa pemrograman tingkat tinggi.
 Penggunaan dan pendefinisian konvensi spesifik
untuk dokumentasi kode.
 Penggunaan metode spesifik untuk desain test case.
 Penggunaan peranti perangkat lunak untuk
mendukung perencanaan dan aktifitas penelusuran,
manajemen konfigurasi untuk mengontrol dan
menelusuri aktifitas perubahan di seluruh proses
perangkat lunak, juga untuk mendukung analisis
perangkat lunak, desain proses, menciptakan
prototip perangkat lunak, proses pengujian, produksi
dan manajemen dokumentasi.
 Pengumpulan metrik kulitas dan metrik produktifitas
bagi semua proyek perangkat lunak.
Jika mayoritas jawaban dari pertanyaan-pertanyaan
tersebut adalah “tidak”, maka proses perangkat lunak
lemah dan berisiko tinggi.
2.5. Risiko teknologi.
Checklist item risiko berikut mengidentifikasi risiko generik
yang berhubungan dengan teknologi yang akan
dibangun :
 Kemutakhiran teknologi yang akan dibangun.
 Kebutuhan kreasi algoritma baru atau teknologi
input-output pada persyaratan pelanggan.
 Interfacing perangkat lunak dengan perangkat keras
atau dengan produk perangkat lunak yang dipasok
oleh vendor lain atau juga dengan sistem database
yang fungsi dan kinerjanya belum dibuktikan dalam
area aplikasi ini.
 Diperlukannya interface pemakai khusus oleh
persyaratan produk.
 Perlunya kreasi komponen program yang tidak sama
dengan yang dikembangkan terakhir oleh organisasi
perekayasa perangkat lunak.
 Perlunya pemakaian analisis, desain atau pengujian
metode baru.
60

9. Buku Ajar Rekayasa Perangkat Lunak
 Perlunya metode pengembangan perangkat lunak
tidak konvensional, seperti metode formal, AI-based,
dll.
 Peletakan batas kinerja yang eksesif pada produk
tersebut.
 Keyakinan pelanggan terhadap kemampuan
implementasi fungsionalitas yang diminta.
2.6. Risiko lingkungan pengembangan.
Peranti yang tidak sesuai dan tidak efektif dapat
menggagalkan suatu usaha bahkan dari pelaksana
yang terampil sekalipun. Lingkungan proses perangkat
lunak mendukung tim proyek, proses dan produk.
Lingkungan yang salah dapat menjadi sumber risiko yang
penting. Checklist item berikut ini mengidentifikasikan
risiko generik yang berhubungan dengan lingkungan
pengembangan :
 Ketersediaan peranti manajemen proyek,
manajemen proses, analisis dan desain, pengujian,
dan manajemen konfigurasi perangkat lunak.
 Kesesuaian peranti analisis dan desain metode
penyampaian, kompiler, peranti pengujian dengan
produk yang akan dibangun.
 Penggunaan database.
 Integrasi semua peranti perangkat lunak.
 Keterampilan setiap anggota dengan setiap peranti.
 Ketersediaan bantuan dan dokumentasi on-line bagi
peranti tersebut.
Bila mayoritas jawaban “tidak” berarti lingkungan
pengembangan perangkat lunak lemah dan berisiko
tinggi.
2.7. Risiko yang berhubungan dengan ukuran staf dan
pengalaman.
Berikut ini checklist item untuk memperkirakan risiko yang
berhubungan dengan ukuran staf dan pengalaman.
 Didapatkannya orang-orang terbaik.
 Gabungan keterampilan yang dimiliki oleh orang-
orang tersebut.
 Jumlah orang-orang yang dibutuhkan.
61

10. Buku Ajar Rekayasa Perangkat Lunak
 Keterlibatan staf ke dalam seluruh proyek.
 Banyaknya staf proyek yang bekerja paruh waktu
pada proyek ini.
 Pengharapan yang tepat mengenai pekerjaan yang
ada sekarang oleh staf proyek.
 Pelatihan yang diterima oleh staf.
 Pengaruh pergantian staf untuk memungkinkan
kontinuitas.
Bila jawaban terhadap pertanyaan-pertanyaan tersebut
adalah “tidak”, maka penyelidikan lebih lanjut harus
dilakukan untuk memperkirakan risiko potensial.
Selain risiko-risiko di atas perlu juga diidentifikasi risiko driver
yang mempengaruhi komponen risiko perangkat lunak, yaitu :
 Risiko kinerja – tingkat ketidakpastian di mana produk
akan memenuhi persyaratannya dan cocok dengan
penggunaannya.
 Risiko biaya – tingkat ketidakpastian di mana biaya
proyek akan dijaga.
 Risiko dukungan – tingkat ketidakpastian di mana
perangkat lunak akan mudah dikoreksi, disesuaikan dan
ditingkatkan.
 Risiko jadwal – tingkat ketidakpastian di mana jadwal
proyek akan dijaga dan produk akan disampaikan tepat
waktu.
3. Analisis risiko.
Selama proses analisis risiko, setiap risiko yang teridentifikasi
diperhitungkan secara bergantian dan penilaian mengenai
besarnya probabilitas dan keseriusan risiko tersebut. Tidak ada
cara yang mudah untuk melakukan hal ini. Analisis ini
bergantung pada penilaian dan pengalaman manajer
proyek. Hasilnya seharusnya bukan berupa penilaian numerik
yang presisi, tetapi didasarkan sekitar sejumlah kisaran :
• Probabilitas risiko bisa dinilai sangat rendah ( < 10 % ),
rendah ( 10 – 25 % ), sedang ( 25 – 50 % ), tinggi ( 50 – 75
% ), atau sangat tinggi ( > 75 % ).
• Efek risiko bisa dinilai sebagai katastropik, serius, bisa
ditolelir, atau tidak signifikan.
62

11. Buku Ajar Rekayasa Perangkat Lunak
Hasil proses analisis ini harus ditabulasikan dengan tabel yang
disusun menurut keseriusan risiko. Pada prakteknya, diperlukan
informasi yang rinci mengenai poyek tersebut, proses, tim
pengembangan, dan organisasi untuk melakukan penilaian
ini. Baik probabilitas maupun penilaian efek risiko bisa berubah
dengan tersedianya lebih banyak infomasi mengenai risiko
tersebut dan dengan diimplementasikannya rencana
manajemen risiko. Dengan demikian tabel ini harus diupdate
pada setiap iterasi proses risiko.
Begitu risiko telah dianalisis dan diberi peringkat, harus
dilakukan penilaian mengenai yang mana yang paling
penting dan hal tersebut harus diperhitungkan pada saat
proyek berjalan. Penilaian ini harus bergantung pada
kombinasi probabilitas risiko yang muncul dan efeknya. Pada
umumnya, semua risiko yang katastropik harus selalu
diperhitungkan, sebagaimana semua risiko yang serius yang
mempunyai probabilitas lebih dari sedang.
4. Perencanaan respon risiko.
Setelah organisasi mengidentifikasi dan mengkuantifikasi risiko,
tugas berikutnya yaitu membangun suatu respon terhadap
risiko tersebut. Membangun sebuah respon untuk suatu risiko
termasuk mendefinisikan langkah-langkah untuk menambah-
kan kesempatan dan membangun rencana untuk
menangani risiko atau ancaman pada keberhasilan proyek.
Ada 4 strategi respon dasar yaitu pencegahan, penerimaan,
pemindahan dan peringanan. Output penting dari proses
pembangunan respon risiko termasuk rencana manajemen
risiko, rencana-rencana darurat dan rencana cadangan.
 Pencegahan risiko termasuk menghilangkan suatu
ancaman atau risiko tertentu, biasanya dengan
menghilangkan penyebabnya. Tentu saja tidak semua
risiko bisa dihilangkan, tetapi kejadian risiko tertentu
dapat. Contoh : sebuah tim proyek dapat memutuskan
untuk terus menggunakan hardware atau software
tertentu pada suatu proyek karena tahu cara kerjanya.
Produk-produk yang lain yang dapat digunakan pada
proyek yang mungkin tersedia, tetapi jika tim proyek tidak
biasa menggunakannya, dapat menyebabkan risiko yang
63

12. Buku Ajar Rekayasa Perangkat Lunak
berarti. Dengan menggunakan hardware atau software
yang biasa digunakan akan menghilangkan risiko ini.
 Penerimaan risiko berarti menerima konsekuensi risiko
yang seharusnya muncul. Contoh : sebuah tim proyek
merencanakan pertemuan untuk peninjauan ulang
sebuah proyek besar yang dapat mengambil suatu
pendekatan aktif untuk mengambil risiko dengan memiliki
ketidaktentuan atau rencana bantuan dan
ketidaktentuan cadangan jika mereka tidak bisa
mendapatkan persetujuan untuk lokasi tertentu untuk
bertemu. Dipihak lain, mereka dapat mengambil
pendekatan dan menerima apapun fasilitas yang
diberikan oleh organisasi.
 Pemindahan risiko adalah memindahkan konsekuensi
risiko dan tanggung jawab untuk manajemennya pada
pihak ketiga. Contoh : pemindahan risiko sering
digunakan untuk berhadapan dengan ekspose risiko
finansial. Suatu tim proyek boleh membeli asuransi khusus
atau jaminan perlindungan untuk hardware tertentu yang
dibutuhkan untuk proyek. Jika hardware gagal,
perusahaan asuransi akan menggantinya.
 Peringanan risiko, termasuk mereduksi dampak dari
kejadian risiko dengan mereduksi kemungkinan
kemunculannya. Contoh : peringanan risiko meliputi
penggunaan terknologi yang teruji, mempunyai personil
yang berkompetensi pada proyek, menggunakan
berbagai analisis dan teknik validasi, dan membeli
persetujuan pemeliharaan dari subkontraktor.
5. Pengendalian Risiko.
Pemantauan risiko mencakup penilaian secara reguler dari
setiap risiko yang teridentifikasi untuk memutuskan apakah
probabilitas terjadinya risiko tersebut menjadi lebih besar atau
lebih kecil dan apakah efeknya telah berubah. Tentu saja hal
ini biasanya tidak dapat dilihat langsung, sehingga harus
dilihat faktor lain yang memberi petunjuk mengenai
probabilitas risiko dan efeknya.
Pemantauan risiko harus merupakan proses yang
berkesinambungan dan pada setiap peninjauan kemajuan
manajemen, setiap risiko kunci harus dipikirkan secara terpisah
dan dibahas dalam rapat.
64

13. Buku Ajar Rekayasa Perangkat Lunak
Rangkuman
Risiko adalah kemungkinan untuk mengalami kerugian atau
kehilangan. Risiko dikategorikan menjadi risiko proyek, risiko teknik,
dan risiko bisnis. Dalam risiko bisnis dibagi lagi menjadi risiko pasar,
risiko strategi, risiko pemasaran, risiko manajemen, dan risiko biaya.
Identifikasi risiko adalah usaha sistematis untuk menentukan
ancaman terhadap rencana proyek. Metode untuk
mengidentifikasi risiko adalah menciptakan checklist item risiko.
Checklist dapat dipergunakan pada identifikasi risiko dan berfokus
pada beberapa himpunan bagian risiko yang sudah diketahui
dan diprediksi dalam subkategori berikut ini :
 Ukuran poduk.
 Pengaruh bisnis.
 Karakteristik pelanggan.
 Definisi proses.
 Lingkungan pengembangan.
 Teknologi yang akan dibangun.
 Ukuran dan pengalaman staf.
Selama proses analisis risiko, setiap risiko yang teridentifikasi
diperhitungkan secara bergantian dan penilaian mengenai
besarnya probabilitas dan keseriusan risiko tersebut.
Membangun sebuah respon untuk suatu risiko termasuk
mendefinisikan langkah-langkah untuk menambahkan
kesempatan dan membangun rencana untuk menangani risiko
atau ancaman pada keberhasilan proyek. Ada 4 strategi respon
dasar yaitu pencegahan, penerimaan, pemindahan dan
peringanan.
Pemantauan risiko mencakup penilaian secara reguler dari setiap
risiko yang teridentifikasi untuk memutuskan apakah probabilitas
terjadinya risiko tersebut menjadi lebih besar atau lebih kecil dan
apakah efeknya telah berubah.
Latihan/Tugas/Test Mandiri
1. Jelaskan apa yang dimaksud dengan risiko perangkat lunak !
2. Sebutkan dan jelaskan kategori risiko perangkat lunak yang
anda ketahui !
3. sebutkan dan jelaskan langkah-langkah dalam manajemen
risiko proyek perangkat lunak !
4. Bagaimana cara untuk mengidentifikasi risiko ? sebutkan dan
jelaskan !
65

14. Buku Ajar Rekayasa Perangkat Lunak
5. Bagaimana cara menganalisis risiko ? sebutkan dan jelaskan !
6. Apa saja strategi dasar dalam perencanaan respon terhadap
risiko ?
66