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 :
  1. Memonitor proyek terhadap kemungkinan resiko
  2. Sumber-sumber daya dikesampingkan
  3. Tim perangkat lunak tidak akan berbuat apa-apa diseputar resiko sampai sesuatu yang buruk terjadi
  4. Kemudian tim akan melakukan aksi untuk membetulkan masalah itu dengan cepat


Strategi Proaktif
Ciri strategi ini :
  1. Dimulai lama sebelum kerja teknis diawali
  2. Resiko potensial di identifikasi
  3. Probabilitas dan pengaruh proyek diperkirakan serta diprioitaskan menurut kepentingan.


RESIKO PERANGKAT LUNAK
Dua karakteristik utama yang selalu ada dalam resiko perangkat lunak yaitu :
Ketidakpastian (uncertainty) => kejadian yang menandai resiko mungkin atau tidak mungkin terjadi.
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

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 :
  1. pembangunan produk atau sistem yang baik sekali yang sebenarnya tidak pernah diinginkan oleh setiap orang (resiko pasar)
  2. pembangunan sebuah produk yang tidak lagi sesuai dengan keseluruhan (resiko strategi)
  3. pembangunan sebuah produk dimana bagian pemasaran tidak tahu bagaimana menjualnya
  4. kehilangan dukungan manajemen senior sehubungan dengan perubahan pada fokus atau perubahan pada manusia (resiko manajemen)
  5. kehilangan hal-hal yang berhubungan dengan biaya atau komitmen personal (resiko biaya)


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 :
  1. Ukuran produk => dihubungkan dengan keseluruhan ukuran perangkat lunak yang akan dibangun / dimodifikasi
  2. Pengaruh bisnis => dihubungkan dengan batasan yang dibebankan oleh manajemen / pasar
  3. Karakteristik pelanggan => dihubungkan dengan kepintaran pelanggan dan kemampuan pengembang untuk berkomunikasi dengan pelanggan dengan cara yang tepat
  4. Definisi proses => dihubungkan dengan tingkat dimana proses perangkat lunak  telah didefinisikan dan diikuti oleh organisasi
  5. 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
  7. 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 :
  1. Ukuran produk diperkirakan dalam LOC atau FP ?
  2. Tingkat kepercayaan dalam estimasi ukuran yang diperkirakan ?
  3. Ukuran produk yang diestimasi dalam jumlah program, file , transaksi ?
  4. Persentase deviasi dalam ukuran produk dari rata-rata produk terakhir ?
  5. Ukuran data base yang dibuat, digunakan oleh produk ?
  6. Berapa jumlah pemakai produk ?
  7. Jumlah perangkat lunak yang digunakan kembali ?


RESIKO-RESIKO YANG MEMPENGARUHI BISNIS
Checklist item berikut untuk mengidentifikasi resiko generic sehubungan dengan
pengaruh bisnis :
  1. Bagaimana pengaruh produk terhadap hasil perusahaan ?
  2. Bagaimana visibilitas produk terhadap manajemen senior ?
  3. Kelayakan deadline penyampaian ?
  4. Jumlah pelanggan yang akan menggunakan produk dan konsistensi kebutuhan relative mereka dengan produk tersebut ?
  5. Jumlah produk / system lain dengan apa produk ini harus dapat saling dioperasikan ?
  6. Kepintaran pemakai akhir ?
  7. Jumlah dan kualitas dokumentasi produk yang harus diproduksi dan disampaikan kepada pelanggan ?
  8. Batasan pemerintahan pada konstruksi produk ?
  9. Biaya yang berhubungan dengan penyampaian yang terlambat ?
  10. Biaya yang berhubungan dengan produk defektif ?


RESIKO YANG DIHUBUNGKAN DENGAN PELANGGAN
Semua pelanggan tidak diciptakan sama. Pembahasan Presman menyatakan bahwa :
  1. Pelanggan mempunyai keinginan yang berbeda
  2. Ada yang tahu apa yang mereka inginkan, yang lain tidak
  3. Banyak yang mau merinci detail (keinginan) nya, sementara yang lain cukup dengan janji-janji kosong.
  4. Pelanggan memiliki kepribadian yang berbeda
  5. Ada yang menikmatinya sebagai pelanggan / rekanan, negosiasi atau penghargaan psikologis dari suatu produk yang baik, sementara yang lainnya tidak ingin menjadi pelanggan sama sekali.
  6. Beberapa akan gembira menerima hampir semua yang disampaikan, sementara yang lainnya akan mengeluh
  7. Pelanggan memiliki hubungan yang bervariasi dengan pemasok
  8. Beberapa mengenali produk dan produsen secara baik, namun sebagian lagi hanya berkomunikasi via telepon, email ataupun surat
  9. Pelanggan kadang-kadang juga bertentangan
  10. 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 :
  1. Pernahkah anda sebelumnya bekerja dengan pelanggan ?
  2. Apakah pelanggan memiliki gagasan yang solid tentang apa yang diperlukannya ? dan sudahkah pelanggan menggunakan waktunya untuk menuliskannya ?
  3. Apakah pelanggan akan setuju dengan penggunaan waktu  untuk mengidentifikasi ruang lingkup proyek ?
  4. Apakah pelanggan bersedia membangun komunikasi yang cepat dengan pengembang ?
  5. Apakah pelanggan bersedia berpartisipasi dalam kajian ?
  6. Apakah pelanggan secara teknis pandai dalam area produk tersebut ?
  7. Apakah pelanggan memahami proses perangkat lunak tersebut ?


MASALAH-MASALAH PROSES.
  1. Apakah manajer senior anda mendukung pernyataan kebijaksanaan pengambangan proses ?
  2. Sudahkah organisasi anda menggunakan deskripsi tertulis dalam proses pengembangan perangkat lunak
  3. Apakah anggota / staf bersedia ditugasi ke proses PL untuk selanjutnya didokumentasikan ?
  4. Apakah proses perangkat lunak juga digunakan untuk proyek lain ?
  5. Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian kursus pelatihan rekayasa perangkat lunak bagi para manajer dan staf teknik ?
  6. Apakah standar rekayasa perangkat lunak yang diterbitkan  disediakan untuk setiap pengembang perangkat lunak dan manajer perangkat lunak ?
  7. Sudahkah dokumen outline dan contoh-contoh dikembangkan untuk semua yang ditentukan sebagai bagian yang dapat disampaikan sebagai bagian dari proses perangkat lunak ?
  8. Apakah kajian teknis dilakukan secara regular ?
  9. Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan dan rencana pengembangan yang didokumentasikan, termasuk kesalahan yang ditemukan dan sumber daya yang digunakan ?
  10. Apakah mekanisme untuk memastikan bahwa yang dilakukan pada suatu proyek sesuai dengan standar rekayasa perangkat lunak ?
  11. Apakah manajemen konfigurasi digunakan untuk memelihara konsistensi diantara sistem / persyaratan perangkat lunak, desain, kode dan test case ?
  12. Apakah digunakan suatu mekanisme untuk mengontrol perubahan ke persyaratan pelanggan yang mempengaruhi perangkat lunak ?
  13. Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan dan rencana pengembangan perangkat lunak yang didokumentasikan untuk masing-masing subkontrak ?
  14. Apakah ada prosedur untuk menelusuri dan mengkaji kinerja subkontrak ?


MASALAH MASALAH TEKNIS.
  1. Apakah teknik spesifikasi aplikasi untuk membangun komunikasi ?
  2. Apakah sudah digunakan metode spesifik untuk analisis PL ?
  3. Apakah anda melihat suatu metode spesifik untk data dan desain arsitektur ?
  4. Apakah 90% dari kode anda ditulis dengan orde bahasa yang lebih tinggi ?
  5. Apakah ada konvensi khusus untuk definisi dokumentasi ?
  6. Apakah anda menggunakan metode spesifik untuk desain test case ?
  7. Apakah digunakan piranti Perangkat Lunak untuk mendukung perencanaan dan aktivitas penelusuran ?
  8. Apakah digunakan  piranti perangkat lunak manajemen konfigurasi untuk mengontrol da menelusuri aktivitas perubahan di seluruh proses PL ?
  9. Apakah digunakan piranti Perangkat Lunak untuk mendukung analisis PL dan desain proses ?
  10. Apakah digunakan piranti untuk menciptakan prototype Perangkat Lunak ?
  11. Apakah digunakan piranti Perangkat Lunak untuk mendukung proses pengujian ?
  12. Apakah piranti Perangkat Lunak digunakan untuk mendukung produksi dan manajemen dokumentasi ?
  13. Apakah metric kualitas dikumpulkan bagi semua proyek ?
  14. 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

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

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 :
  1. Apakah piranti manajemen proyek dapat diperoleh ?
  2. Apakah piranti manajemen proses dapat diperoleh ?
  3. Apakah piranti untuk analisis dan desain dapat diperoleh ?
  4. Apakah piranti analisis dan desain penyampaian metoe sesuai bagi produk yang akan dibangun ?
  5. Apakah diperoleh compiler atau generasi kode dapat dan sesuai dengan produk yang akan dibangun ?
  6. Apakah piranti pengujian dapat diperoleh dan sesuai dengan produk yang akan dibangun ?
  7. Apakah piranti manajemen konfigurasi perangkat lunak dapat diperoleh ?
  8. Apakah lingkungan menggunakan suatu database atau tempat penyimpanan ?
  9. Apakah semua piranti perangkat lunak diintegrasikan satu dengan lainnya ?
  10. Sudahkan anggota tim proyek menerima pelatihan dengan masing-masing piranti ?
  11. Apakah ada pakar local untuk menjawab pertanyaan pertanyaan mengenai piranti tersebut ?
  12. Apakah bantuan dan dokumentasi on line bagi piranti memadai ?

Bila mayoritas jawaban adalah “TIDAK”, berarti lingkungan pengembangan perangkat lunak lemah dan beresiko tinggi.

RESIKO YANG BERHUBUNGAN DENGAN UKURAN STAF DAN PENGALAMAN.
Hendaknya dijawab pertanyaan-pertanyaan berikut agar bisa memperkirakan resiko yang berhubungan dengan ukuran staf dan pengalaman :
  1. Apakah orang-orang terbaik didapatkan ?
  2. Apakah orang-orang tersebut memiliki gabungan ketrampilan yang benar ?
  3. Apakah orang-orang yang ada mencukupi ?
  4. Apakah staf yang ada dimasukkan ke dalam seluruh durasi proyek ?
  5. Apakah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini ?
  6. Apakah staf memiliki pengharapan yang tepat mengenai pekerjaan yang ada sekarang ?
  7. Sudahkah staf menerima pelatihan yang memadai ?
  8. 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.

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

Post a Comment

إرسال تعليق

أحدث أقدم