Buku ajar kecil 05

Buku Ajar Rekayasa Perangkat Lunak

BAB 5Manajemen 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.Risiko bisnis mengancam visibilitas perangkat lunak yang akan dibangun. Risiko bisnis membahayakan proyek atau produk. Kandidat untuk lima risiko bisnis utama adalah :

53


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, 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

54


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

55


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

56


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

57


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.

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.

58


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.

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

59


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.

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

60


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

61


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.

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

62


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

63


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.

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.

64


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 !

5. Bagaimana cara menganalisis risiko ? sebutkan dan jelaskan !

6. Apa saja strategi dasar dalam perencanaan respon terhadap risiko ?

65

Buku ajar kecil 05

Documents

Transcript of Buku ajar kecil 05