Mengidentifikasi Risiko Perangkat Lunak

Identifikasi risiko adalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek (perkiraan, jadwal, pemuatan sumber daya, dil). Ada dua tipe risiko yang berbeda : risiko generik dan risiko produk spesifik. Risiko generik merupakan ancaman potensial pada setiap proyek perangkat lunak. Risiko produk spesifik hanya dapat diidentifikasi oleh mereka dengan pemahaman khusus mengenai teknologi tsb, manusia, serta lingkungan yang spesifik terhadap proyek yang ada.

Tom Gilb menyatakan: "Bila anda tidak aktif menyerang risiko, maka risiko akan aktif menyerang anda." Metode untuk mengidentifikasi risiko adalah menciptakan cheklist item risiko. Checklist dapat digunakan pada identifikasi risiko dan berfokus pada beberapa himpunan bagian risiko yang sudah diketahui dan diprediksi dalam sub kategori berikut ini :

• Ukuran produk risiko sehubungan dengan keseluruhan ukuran perangkat lunak yang akan dibangun atau dimodifikasi.
• Pengaruh bisnis risiko sehubungan dengan batasan yang dibebankan oleh manajemen atau pasar.
• Karakteristik pelanggan risiko sehubungan dengan kepintaran pelanggan dan kemampuan pengembang untuk berkomunikasi dengan pelangan dengan cara yang tepat.
• Definisi proses — risiko sehubungan dengan tingkat di mana proses perangkat lunak telah didefinisikan dan diikuti oleh organisasi pengembangan.
• Lingkungan pengembang — risiko sehubungan dengan keberadaan dan kualitas peranti yang akan digunakan untuk membangun produk.
• Teknologi yang akan dibangun — risiko sehubungan dengan kompleksitas sistem yang akan dibangun dan "kebaruan" teknologi yang dikemas oleh sistem.
• Ukuran dan pengalaman staf — risiko sehubungan dengan keseluruhan teknik dan pengalaman proyek dari rekayasa perangkat lunak yang akan melakukan tugas tersebut.

 Identifikasi risiko

Proses ini meliputi identifikasi risiko yang mungkin terjadi dalam suatu aktivitas usaha. Identifikasi risiko ecara akurat dan komplit sangatlah vital dalam manajemen risiko. Salah satu aspek penting dalam identifikasi risiko adalah mendaftar risiko yang mungkin terjadi sebanyak mungkin. Teknik-teknik yang dapat digunakan dalam identifikasi risiko antara lain:

• Brainstorming
• Survei 
• Wawancara
• Informasi histori
• Kelompok kerja

Kesalahan estimasi

Beberapa pekerjaan lebih sulit untuk melakukan estimasi dibandingkan pekerjaan lainnya disebabkan karena terbatasnya pengalaman pada pekerjaan serupa atau disebabkan karena jenis pekerjaan tersebut. pembuatan sebuah user manual merupakan langkah yang tepat yang dapat dipertanggungjawabkan dan sebagai bukti bahwa kita pernah mengerjakan tugas yang serupa sebelumnya. Dengan pengalaman itu seharusnya kita mampu untuk melakukan estimasi dengan lebih tepat mengenai berapa lama pekerjaan dapat diselesaikan dan berapa besarnya biaya yang dibutuhkan. Selain itu, waktu yang dibutuhkan untuk melakukan pengujian dan penelusuran program dapat menjadi sesuatu hal yang sulit diprediksi dengan tingkat keakuratan yang serupa walaupun kita pernah membuat program yang serupa sebelumnya.

Estimasi dapat ditingkatkan melalui analisa data historis untuk aktivitas yang serupa dan untuk sistem yang serupa. Dengan menyimpan perbandingan antara estimasi semula dengan hasil akhir akan mengakibatkan beberapa tipe pekerjaan sulit diestimasi secara tepat.

Risiko ini terjadi jika perkiraan LOC pada kenyataan yang ada jauh melebihi LOC perkiraan pada perhitungan COCOMO, yang mengakibatkan berubahnya jadwal pengerjaan dan biaya operasional.

Aksumsi perencanaan

Pada setiap tahapan perencanaan, asumsi perlu dibuat, jika tidak benar maka dapat mengakibatkan risiko tersebut berisiko. Misal pada jaringan aktivitas, aktivitas dibangun berdasarkan pada asumsi menggunakan metode desain tertentu dimana memungkinkan urutan aktivitas diubah. Kita biasanya membuat asumsi bahwa setelah coding, biasanya sebuah modul akan diuji dan kemudian diintegrasikan dengan modul lainnya. Akan tetapi kita tidak merencanakan pengujian modul yang dapat mangakibatkan perubahan desain awal. Hal ini dapat terjadi setiap saat.

Pada setiap tahapan pada proses perencanaan, sangat penting untuk memeperinci secara eksplisit semua asumsi yang dibuat dan mengidentifikasi apa pengaruhnya jika ternyata dalam pelaksanaannya tidak sesuai dengan yang sudah direncanakan.

Kemungkinan

Beberapa kemungkinan dapat saja tidak pernah terlihat dan kita hanya dapat menyakinkan diri kita sendiri bahwa ada sesuatu yang tidak dapat dibayangkan, kadang-kadang dapat terjadi. Akan tetapi biasanya jarang terjadi hal seperti itu. Mayoritas kejadian yang tidak diharapkan biasanya dapat diidentifikasi beberapa spesifikasi kebutuhan kemungkinan diubah setelah beberapa modul telah dikodekan, programmer senior meninggalkan pengembangan, perangkat keras yang diperlukan tidak dikirim tapat waktu. Beberapa kejadian iemacam itu dapat terjadi sewaktu-waktu dan walaupun kejadian tersebut kemungkinan terjadinya relatif rendah akan tetapi kejadian tersebut perlu dipertimbangkan dan direncanakan.

Metode untuk evaluasi pengaruh ketidakpastian ini terhadap jadwal proyek:

• Penggunaan PERT untuk evaluasi pengaruh ketidakpastian
• PERT dikembangkan untuk menghitung estimasi ketidakpastian lingkungan terhadap durasi pekerjaan.

PERT dikembangkan pada suatu lingkungan proyek yang mahal, berisiko tinggi dan kompleks. Metode PERT ini memerlukan tiga estimasi:

Most likely time

Waktu yang diperlukan untuk menyelesaikan pekerjaan dalam situasi normal dan diberikan simbol m.

Optimistic time

Waktu tersingkat yang diperlukan untuk menyelesaikan pekerjaan dan diberi simbol a.

Pessimistic time

Waktu terlama yang diperlukan untuk menyelesaikan pekerjaan dikarenakan berbagai kemungkinan yang masuk akal dan diberikan simbol b.

PERT mengkombinasikan ketiga estimasi tersebut untuk membentuk durasi tunggal yang diharapkan,

t = a + 4m + b

 Penggunaan durasi yang diharapkan

Durasi yang diharapkan dipergunakan supaya suatu forward pass dapat melalui sebuah jaringan; dengan mempergunakan metode yang sama dengan teknik CPM. Akan tetapi dalam hal ini, tanggal aktivitas yang dihitung bukan merupakan tanggal paling awal akan tetapi merupakan tanggal yang diharapkan dapat mencapai aktivitas tersebut.

Jaringan PERT yang diperlihatkan pada gambar 3 memperlihatkan bahwa kita berharap proyek tersebut dapat diselesaikan dalam waktu 13,5 minggu tidak seperti CPM yang tidak memperlihatkan tanggal paling awal untuk menyelesaikan proyek tersebut akan tetapi tanggal yang diharapkan (atau most likely). Salah satu keuntungan dari pendekatan ini adalah menempatkan sebuah emphasis dalam ketidakpastian di dunia nyata.

Tabel 4.7. berikut ini memperlihatkan contoh estimasi durasi aktivitas yang memperkirakan durasi secara optimistic(a), pessimistic(b) dan most likeliy(m).

Pendekatan PERT juga difokuskan pada ketidakpastian estimasi durasi aktivitas. Perlu tiga estimasi untuk masing-masing aktivitas yang memperlihatkan fakta bahwa kita tidak yakin dengan apa yang akan terjadi kita dipaksa untuk menghitung fakta yang diperkirakan akan terjadi.

Deviasi standar aktivitas

Perhitungan kuantitatif tingkat ketidakpastian suatu estimasi durasi aktivitas bisa diperoleh dengan menghitung standar deviasi s dari sebuah durasi aktivitas dengan mempergunakan rumus:

Standar deviasi aktivitas porporsional dengan beda antara estimasi optimistic dan pessimistic, dan dapat dipergunakan sebagai tingkatan ukuran level ketidakpastian atau risiko masing-masing aktivitas. Durasi yang diharapkan dari masing-masing aktivitas dan standar deviasi dari proyek tersebut (tabel 4.7) dapat dilihat pada tabel 4.8

Likehood target terpenuhi

Keuntungan utama dari teknik PERT adalah memberikan suatu metode untuk melakukan estimasi probabilitas tanggal target terpenuhi atau tidak. Teknik ini bisa saja hanya mempunyai tanggal target tunggal yaitu proyek selesai, akan tetapi kita diharapkan untuk mengatur tambahan target antara. Misalkan kita harus menyelesaikan proyek dalam waktu 15 minggu. Kita berharap proyek tersebut dapat diselesaikan dalam waktu 13.5 minggu akan tetapi durasinya bisa lebih dan bisa kurang. Misalkan aktivitas C harus diselesaikan pada minggu ke 10 karena salah satu anggota yang melaksanakan aktivitas tersebut sudah dijadwalkan untuk bekerja pada proyek lain dan kejadian 5 memperlihatkan penyerahan produk kepada pelanggan.

Risiko Ukuran Produk

Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan ukuran produk (perangkat lunak) :

• Berapa ukuran produk diperkirakan dalam LOC atau FP?
• Ukuran produk yang diestimasi dalam jumlah program, file, transaksi?
• Ukuran database yang dibuat atau digunakan oleh produk?
• Jumlah pemakai produk?
• Jumlah perangkat lunak yang dipergunakan kembali?

Share this post