Defenisi konseptual mengenai resiko : (Robert Charette)
1. Resiko berhubungan dengan kejadian di masa yg akan datang.
2. Resiko melibatkan perubahan (spt. perubahan pikiran,
pendapat, aksi, atau tempat)
3. Resiko melibatkan pilihan & ketidakpastian bahwa pilihan itu
akan dilakukan.
Strategi Resiko Reaktif vs Proaktif
Strategi reaktif memonitor proyek terhadap kemungkinan resiko.
Sumber2 daya dikesampingkan, padahal seharusnya sumber2 daya
menjadi masalah yang sebenarnya / penting.
Strategi proaktif dimulai sebelum kerja teknis diawali.
Resiko potensial diidentifikasi, probabilitas & pengaruh proyek
diperkirakan, dan diprioritaskan menurut kepentingan, kemudian
membangun suatu rencana untuk manajemen resiko.
Sasaran utama adalah menghindari resiko.
Resiko Perangkat Lunak
Karakteristik resiko :
1. Ketidakpastian
2. Kerugian
Kategori resiko :
· Resiko proyek
· Resiko teknis
· Resiko bisnis
Kategori resiko oleh Robert Charette :
· Resiko yang sudah diketahui
· Resiko yang dapat diramalkan
· Resiko yang tidak diharapkan
@ Resiko proyek
Resiko proyek mengancam rencana proyek.
Bila resiko proyek menjadi kenyataan maka ada kemungkinan jadwal
proyek akan mengalami slip & biaya menjadi bertambah.
Resiko proyek mengidenifikasi :
- biaya - sumber daya
- jadwal - pelanggan
- personil (staffing & organisasi) - masalah persyaratan
@ Resiko teknis
Resiko teknis mengancam kualitas & ketepatan waktu PL yg akan
dihasilkan. Bila resiko teknis menjadi kenyataan maka
implementasinya menjadi sangat sulit atau tidak mungkin.
Resiko teknis mengidentifikasi :
- desain potensial - ambiquitas
- implementasi - spesifikasi
- interfacing - ketidakpastian teknik
- verivikasi - keusangan teknik
- masalah pemeliharaan - teknologi yg leading edge
@ Resiko bisnis
Resiko bisnis mengancam viabilitas PL yg akan dibangun.
Resiko bisnis membahayakan proyek atau produk.
5 resiko bisnis utama :
1. pembangunan produk atau sistem yg baik sebenarnya tdk
pernah diinginkan oleh setiap orang (resiko pasar)
2. pembangunan sebuah produk yg tidak sesuai dgn keseluruhan
strategi bisnis bagi perusahaan (resiko strategi)
3. Pembangunan sebuah produk dimana sebuah bagian pemasaran
tidak tahu bagaimana harus menjualnya.
4. Kehilangan dukungan manajemen senior sehubungan dg
perubahan pd fokus atau perubahan pd manusia (resiko
manajemen)
5. Kehilangan hal2 yg berhubungan dgn biaya atau komitmen
personal (resiko biaya).
@ Resiko yg sudah diketahui
adalah resiko yg dpt diungkap setelah dilakukan evaluasi secara
hati2 terhadap rencana proyek, bisnis, & lingkungan teknik dimana
proyek sedang dikembangkan, dan sumber informasi reliable lainnya.
seperti :
- tgl penyampaian yg tdk realitas
- kurangnya persyaratan yg terdokumentasi
- kurangnya ruag lingkup PL
- lingkungan pengembangan yg buruk
@ Resiko 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
@ Resiko yg tidak diharapkan
resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk
diidentifikasi sebelumnya.
Identifikasi Resiko
Identifikasi resiko dalah usaha sistematis untuk menentukan
ancaman terhadap rencana proyek.
Tujuan identifikasi resiko :
untuk menghindari resiko bilamana mungkin, serta menghindarinya
setiap saat diperlukan.
Tipe resiko :
1. resiko generik
merupakan ancaman potensial pd setiap proyek PL.
2. resiko produk spesifik
hanya dapat diidentifikasi dgn pemahaman khusus mengenai
teknologi, manusia, serta lingkungan yg spesifik terhadap
proyek yg ada.
Metode untuk mengidentifikasi resiko adalah menciptakan
checklist item resiko.
Kategori checklist item resiko :
o resiko ukuran produk
o resiko yg mempengaruhi bisnis
o resiko yg dihubungkan dgn karakteristik pelanggan
o resiko definisi proses
o resiko teknologi yang akan dibangun
o resiko lingkungan pengembangan
o resiko yg berhubungan dgn ukuran dan pengalaman staf
@ Resiko ukuran produk
Resiko yg berhubungan dgn keseluruhan ukuran PL yg akan dibangun
atau dimodifikasi.
Checklist item resiko yg berhubungan dgn ukuran produk (PL) :
· ukuran produk diperkirakan dalam LOC atau FP ?
· tingkat kepercayaan dlm estimasi ukuran yg diperkirakan ?
· ukuran produk yg diestimasi dalam jumlah program, file,
transaksi ?
· presentase deviasi dalam ukuran produk dari rata2 produk
terakhir ?
· ukuran database yg dibuat atau digunakan oleh produk ?
· jumlah pemakai produk ?
· jumlah perubahan yg diproyeksikan ke persyaratan produk ?
sebelum produk ? setelah penyampaian ?
· jumlah PL yg digunakan kembali ?
Bila persentasie deviasi besar atau deviasinya sama, tetapi hasil yg
lalu sangat kurang dari yg diharapkan, maka resikonya tinggi.
@ Resiko yg mempengaruhi bisnis
Resiko yg berhubungan dengan batasan yg dibebankan oleh
manajemen atau pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan
pertimbangan bisnis kadang mengalami konflik langsung dengan
kenyataan teknis.
Checklist item resiko yg berhubungan dgn pengaruh bisnis :
Rekayasa Perangkat Lunak Bab 6 Halaman 6
· Pengaruh produk terhadap hasil perusahaan ?
· Visibilitas produk terhadap manajemen senior ?
· Kelayakan deadline penyampaian ?
· Jumlah pelanggan yg akan menggunakan produk & konsistensi
kebutuhan relatif mereka dengan produk tersebut ?
· Jumlah produk / sistem lain dgn apa produk ini harus dapat
saling dioperasikan ?
· Kepintaran pemakai akhir ?
· Jumlah dan kualitas dokumentasi produk yg harus diproduksi &
disampaikan kepada pelanggan ?
· Batasan pemerintahan pada konstruksi produk ?
· Biaya yg berhubungan dgn penyampaian yg terlambat ?
· Biaya yg berhubungan dgn produk defektif ?
Bila ada persentase deviasi yang besar atau jika jumlahnya sama,
tetapi hasil sebelumnya sangat kurang dari yg diharapkan, maka
resiko tinggi.
@ Resiko yg dihubungkan dgn karakteristik pelanggan
Resiko yg berhubungan dengan kepintaran pelanggan & kemampuan
pengembang untuk berkomunikasi dgn pelanggan dgn cara yg cepat.
Karakteristik pelanggan :
- Pelanggan mempunyai keinginan yg berbeda.
- Pelanggan memiliki kepribadian yg berbeda.
- Pelanggan memiliki hubungan yg bervariasi dgn pemasok.
- Pelanggan juga kadang-kadang bertentangan.
Karakteristik pelanggan mempengaruhi kemampuan tim PL untuk
menyelesaikan suatu proyek tepat waktu & sesuai anggaran.
Rekayasa Perangkat Lunak Bab 6 Halaman 7
Checklist item resiko yg berhubungan dgn karakteristik pelanggan:
· Pernahkah anda sebelumnya bekerja dengan pelanggan ?
· Apakah pelanggan memiliki gagasan yg solid mengenai apa yg
diperlukannya ? sudahkah pelanggan menggunakan waktunya
untuk menuliskannya ?
· Apakah pelanggan akan setuju dgn penggunaan waktu didalam
pertemuan pengumpulan persyaratan formal (bab 11) utk
mengidentifikasi ruang lingkup proyek ?
· Apakah pelanggan bersedia membangun sambungan
komunikasi cepat dgn pengembang ?
· Apakah pelanggan bersedia berpartisipasi dalam kajian ?
· Apakah pelanggan secara teknis pandai dlm area produk tsb?
· Apakah pelanggan bersedia membiarkan orang2 melakukan
pekerjaan mereka ?
· Apakah pelanggan memahami proses perangkat lunak tsb ?
Bila setiap jawaban dari pertanyaan diatas adalah ‘tidak’, maka
investigasi lebih jauh harus dilakukan utk memperkirakan potensi
resiko.
@ Resiko definisi proses
Bila kualitas merupakan sebuah konsep yg disetujui sbg hal yg
penting tetapi tidak tidak ada yg berintdak untuk mencapainya
dengan cara yg dapat yg dilakukan, maka proyek tersebut beresiko.
Masalah-masalah proses
· Apakah manajemen senior anda mendukung suatu pernyataan
kebijaksanaan yg menekankan pentingnya suatu proses standar
untuk pengembangan proses ?
· Sudahkah organisasi anda mengembangkan suatu diskripsi
tertulis mengenai proses PL yg akan digunakan pd proyek ini ?
· Apakah anggota2 staf ‘ditugasi’ ke proses PL pd saat PL
didokumentasi & bersedia menggunakannya ?
· Apakah proses PL digunakan untuk proyek lain ?
· Sudahkah organisasi anda mengembangkan atau mendapatkan
serangkaian serangkaian kursus pelatihan RPL bagi para
manajer dan staf teknik ?
· Apakah standar RPL yg diterbitkan disediakan utk setiap
pengembang PL & manajer PL ?
· Sudahkah dokumen outline & contoh2 dikembangkan untuk
semua yg ditentukan sebagai bagian yg dapat disampaikan
sebagai bagian dari proses PL ?
· Apakah kajian teknis formal terhadap spesifikasi persyaratan,
desain, dan kode dilakukan secara reguler ?
· Apakah kajian teknis formal terhadap prosedur pengujian &
test case dilakukan secara reguler ?
· Apakah hasil dari masing2 kajian teknis formal
didokumentasikan, termasuk kesalahan yg ditemukan & sumber
daya yg digunakan ?
· Apakah mekanisme utk memastikan bahwa kerja yg dilakukan
pd suatu proyek sesuai dengan standar RPL ?
· Apakah manajemen konfigurasi digunakan utk memelihara
konsistensi diantara _ystem/persyaratan PL, desain, kode, dan
test case ?
· Apakah digunakan suatu mekanisme utk mengontrol perubahan
ke persyaratan pelanggan yg mempengaruhi PL ?
· Adakah pernyataan mengenai kerja, spesifikasi persyaratan
pelanggan, dan rencana pengembangan PL yg didokumentasikan
untuk masing2 subkontrak ?
· Apakah ada prosedur untuk menelusuri & mengkaji kinerja
subkontrak ?
Masalah-masalah teknis
· Apakah digunakan teknik spesifikasi aplikasi untuk membantu
komunikasi diantara pelanggan & pengembang ?
· Apakah metode spesifik digunakan untuk analisis PL ?
· Apakah anda melihat suatu metode spesifik untuk data &
desain arsitektur ?
· Apakah lebih dari 90% dari kode anda ditulis dgn bahasa orde
yg lebih tinggi ?
· Apakah konvensi spesifik utk dokumentasi kode didefinisikan
& digunakan ?
· Apakah anda menggunakan metode spesifik utk desain test
case?
· Apakah digunakan peranti PL utk mendukung perencanaan &
aktivitas penelusuran ?
· Apakah digunakan peranti PL manajemen konfigurasi utk
me-ngontrol & menelusuri aktivitas perubahan diseluruh
proses PL ?
· Apakah digunakan peranti PL utk mendukung analisis PL &
desain proses ?
· Apakah digunakan peranti utk menciptakan prototipe PL ?
· Apakah digunakan peranti PL utk mendukung proses
pengujian ?
· Apakah peranti PL digunakan utk mendukung produksi dan
manajemen dokumentasi ?
· Apakah metrik kualitas dikumpulkan bagi semua proyek PL ?
· Apakah metrik produktivitas dikumpulkan bagi semua proyek
PL?
Bila mayoritas jawaban terhadap pertanyaan tsb adalah `tidak`,
maka proses PL lemah dan berisiko tinggi.
@ Resiko teknologi yang akan dibangun
Resiko yg berhubungan dgn kompleksitas sistem yg akan dibangun
dan `kebaruan` teknologi yg dikemas oleh system.
Checklist item resiko yg berhubungan dengan teknologi yg akan
dibangun :
· Apakah teknologi yg akan dibangun adalah hal yg baru untuk
organisasi anda?
· Apakah persyaratan pelanggan memerlukan kreasi algoritma
baru atau teknologi input atau output?
· Apakah PL berinterface dgn perangkat keras baru atau belum
terbukti?
· Apakah PL yg akan dibangun ber-interace dgn produk PL yg
dipasok oleh vendor yg belum terbukti?
· Apakah PL yg akan dibangun ber-interface dgn suatu sistem
database yg fungsi kinerjanya belum dibuktikan di dalam area
aplikasi ini?
· Apakan diperlukan interface pemakai khusus oleh persyaratan
produk?
· Apakah persyaratan untuk produk memerlukan kreasi
komponen program yg tidak sama dengan yg dikembangkan
terakhir oleh organisasi anda?
· Apakah persyarata memerlukan pemakaian analisis, desain
atau metode pengujian baru?
· Apakah persyaratan memerlukan metode pengembangan PL
tdk konvensional, spt metode formal, pendekatan Al-based
dan jaringan syaraf buatan?
· Apakah persyaratan meletakkan batasan kinerja yg eksesif
pada produk tersebut?
· Apakah pelanggan tidak yakin pada fungsionalitas yg diminta
dapat ’dilakukan’?
Bila jawaban dari pertanyaan2 di atas adalah ’ya’, penyelidikan lebih
lanjut harus dilakukan untuk memperkirakan risiko potensial.
Tidak ada komentar:
Posting Komentar