Rekayasa perangkat lunak

Pertemuan 6Manajemen resiko

By : anisah 41812110004

DEFINISI KONSEPTUAL :1. Resiko berhubungan dengan kejadian dimasa yang akan datang2. 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 PROAKTIFStrategi reaktif, bila pada titik terbaik, akan :a. Memonitor proyek terhadap kemungkinan resikob. Sumber-sumber daya dikesampingkanc. Tim perangkat lunak tidak akan berbuat apa-apa diseputar resiko sampai sesuatu yang buruk

terjadid. Kemudian tim akan melakukan aksi untuk membetulkan masalah itu dengan cepat

Strategi ProaktifCiri strategi ini :a. Dimulai lama sebelum kerja teknis diawalib. Resiko potensial di identifikasic. Probabilitas dan pengaruh proyek diperkirakan serta diprioitaskan menurut kepenting an.

RESIKO PERANGKAT LUNAKDua karakteristik utama yang selalu ada dalam resiko perangkat lunak yaitu :1. Ketidakpastian (uncertainty) => kejadian yang menandai resiko mungkin atau tidak mungkin

terjadi.2. Rugi (loss) => bila resiko menjadi realitas, akibat tidak yang tidak diinginkan atau kerugian

akan dialami.

KATAGORI RESIKOPenting 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 edgec. Resiko bisnis

resiko ini dapat membahayakan proyek atau produk. Kandidat untuk lima resiko bisnis yang utama dapat berupa :

• pembangunan produk atau sistem yang baik sekali yang sebenarnya tidak pernah diinginkan oleh setiap orang (resiko pasar)

• pembangunan sebuah produk yang tidak lagi sesuai dengan keseluruhan (resiko strategi)

• pembangunan sebuah produk dimana bagian pemasaran tidak tahu bagaimana menjualnya

• kehilangan dukungan manajemen senior sehubungan dengan perubahan pada fokus atau perubahan pada manusia (resiko manajemen)

• 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 :• Ukuran produk => dihubungkan dengan keseluruhan ukuran perangkat lunak yang akan

dibangun / dimodifikasi• Pengaruh bisnis => dihubungkan dengan batasan yang dibebankan oleh manajemen / pasar• Karakteristik pelanggan => dihubungkan dengan kepintaran pelanggan dan kemampuan

pengembang untuk berkomunikasi dengan pelanggan dengan cara yang tepat• Definisi proses => dihubungkan dengan tingkat dimana proses perangkat lunak telah

didefinisikan dan diikuti oleh organisasi • Lingkaran pengembangan => dihubungkan dengan keberadaan dan kualitas piranti yang akan

digunakan untuk membangun produk

• Teknologi yang akan dibangun => dihubungkan dengan kompleksitas system yang akan dibangun dan kebaruan teknologi yang dikemas oleh system

• Ukuran dan pengalaman staf => dihubungkan dengan keseluruhan teknik dan pengalaman proyek dari perekayasa perangkat lunak yang akan melakukan tugas tersebut.

RESIKO UKURAN PRODUKMuncul pertanyaan : apakah resiko proyek berbanding langsung dengan ukuran ?. Untuk mengetahuinya, check list item berikut :• Ukuran produk diperkirakan dalam LOC atau FP ?• Tingkat kepercayaan dalam estimasi ukuran yang diperkirakan ?• Ukuran produk yang diestimasi dalam jumlah program, file , transaksi ?• Persentase deviasi dalam ukuran produk dari rata-rata produk terakhir ?• Ukuran data base yang dibuat, digunakan oleh produk ?• Berapa jumlah pemakai produk ?• Jumlah perangkat lunak yang digunakan kembali ?

RESIKO-RESIKO YANG MEMPENGARUHI BISNISChecklist item berikut untuk mengidentifikasi resiko generic sehubungan dengan pengaruh bisnis :• Bagaimana pengaruh produk terhadap hasil perusahaan ?• Bagaimana visibilitas produk terhadap manajemen senior ?• Kelayakan deadline penyampaian ?• Jumlah pelanggan yang akan menggunakan produk dan konsistensi kebutuhan relative

mereka dengan produk tersebut ?

• Jumlah produk / system 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 ?

RESIKO YANG DIHUBUNGKAN DENGAN PELANGGANSemua pelanggan tidak diciptakan sama. Pembahasan Presman menyatakan bahwa :• Pelanggan mempunyai keinginan yang berbeda

o Ada yang tahu apa yang mereka inginkan, yang lain tidako Banyak yang mau merinci detail (keinginan) nya, sementara yang lain cukup dengan

janji-janji kosong. • Pelanggan memiliki kepribadian yang berbeda

o Ada yang menikmatinya sebagai pelanggan / rekanan, negosiasi atau penghargaan psikologis dari suatu produk yang baik, sementara yang lainnya tidak ingin menjadi pelanggan sama sekali.

o Beberapa akan gembira menerima hampir semua yang disampaikan, sementara yang lainnya akan mengeluh

• Pelanggan memiliki hubungan yang bervariasi dengan pemasoko Beberapa mengenali produk dan produsen secara baik, namun sebagian lagi hanya

berkomunikasi via telepon, email ataupun surat

• Pelanggan kadang-kadang juga bertentangano 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 :• Pernahkah anda sebelumnya bekerja dengan pelanggan ?• Apakah pelanggan memiliki gagasan yang solid tentang apa yang diperlukannya ? dan

sudahkah pelanggan menggunakan waktunya untuk menuliskannya ?• Apakah pelanggan akan setuju dengan penggunaan waktu untuk mengidentifikasi ruang

lingkup proyek ?• Apakah pelanggan bersedia membangun komunikasi yang cepat dengan pengembang ?• Apakah pelanggan bersedia berpartisipasi dalam kajian ?• Apakah pelanggan secara teknis pandai dalam area produk tersebut ?• Apakah pelanggan memahami proses perangkat lunak tersebut ?

MASALAH-MASALAH PROSES.• Apakah manajer senior anda mendukung pernyataan kebijaksanaan pengambangan proses ?• Sudahkah organisasi anda menggunakan deskripsi tertulis dalam proses pengembangan

perangkat lunak • Apakah anggota / staf bersedia ditugasi ke proses PL untuk selanjutnya didokumentasikan ?

• Apakah proses perangkat lunak juga digunakan untuk proyek lain ?• Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian kursus pelatihan

rekayasa perangkat lunak bagi para manajer dan staf teknik ?• Apakah standar rekayasa perangkat lunak yang diterbitkan disediakan untuk setiap

pengembang perangkat lunak dan manajer perangkat lunak ?• Sudahkah dokumen outline dan contoh-contoh dikembangkan untuk semua yang ditentukan

sebagai bagian yang dapat disampaikan sebagai bagian dari proses perangkat lunak ?• Apakah kajian teknis dilakukan secara regular ?• Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan dan rencana

pengembangan yang didokumentasikan, termasuk kesalahan yang ditemukan dan sumber daya yang digunakan ?

• Apakah mekanisme untuk memastikan bahwa yang dilakukan pada suatu proyek sesuai dengan standar rekayasa perangkat lunak ?

• Apakah manajemen konfigurasi digunakan untuk memelihara konsistensi diantara sistem / persyaratan perangkat lunak, desain, kode dan test case ?

• Apakah digunakan suatu mekanisme untuk mengontrol perubahan ke persyaratan pelanggan yang mempengaruhi perangkat lunak ?

• Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan dan rencana pengembangan perangkat lunak yang didokumentasikan untuk masing-masing subkontrak ?

• Apakah ada prosedur untuk menelusuri dan mengkaji kinerja subkontrak ?

MASALAH MASALAH TEKNIS.• Apakah teknik spesifikasi aplikasi untuk membangun komunikasi ?• Apakah sudah digunakan metode spesifik untuk analisis PL ?• Apakah anda melihat suatu metode spesifik untk data dan desain arsitektur ?• Apakah 90% dari kode anda ditulis dengan orde bahasa yang lebih tinggi ?• Apakah ada konvensi khusus untuk definisi dokumentasi ?• Apakah anda menggunakan metode spesifik untuk desain test case ?• Apakah digunakan piranti Perangkat Lunak untuk mendukung perencanaan dan aktivitas

penelusuran ?• Apakah digunakan piranti perangkat lunak manajemen konfigurasi untuk mengontrol da

menelusuri aktivitas perubahan di seluruh proses PL ?• Apakah digunakan piranti Perangkat Lunak untuk mendukung analisis PL dan desain proses ?• Apakah digunakan piranti untuk menciptakan prototype Perangkat Lunak ?• Apakah digunakan piranti Perangkat Lunak untuk mendukung proses pengujian ?• Apakah piranti Perangkat Lunak digunakan untuk mendukung produksi dan manajemen

dokumentasi ?• Apakah metric kualitas dikumpulkan bagi semua proyek ?• 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 PENGEMBANGANLingkungan yang salah, dapat menjadi sumber resiko yang tinggi. Checklist item resiko berikut ini untuk mengidentifikasi resiko generic yang berhubungan dengan lingkungan pengembangan :• Apakah piranti manajemen proyek dapat diperoleh ?• Apakah piranti manajemen proses dapat diperoleh ?• Apakah piranti untuk analisis dan desain dapat diperoleh ?• Apakah piranti analisis dan desain penyampaian metoe sesuai bagi produk yang akan

dibangun ?• Apakah diperoleh compiler atau generasi kode dapat dan sesuai dengan produk yang akan

dibangun ?• Apakah piranti pengujian dapat diperoleh dan sesuai dengan produk yang akan dibangun ?• Apakah piranti manajemen konfigurasi perangkat lunak dapat diperoleh ?• Apakah lingkungan menggunakan suatu database atau tempat penyimpanan ?• Apakah semua piranti perangkat lunak diintegrasikan satu dengan lainnya ?• Sudahkan anggota tim proyek menerima pelatihan dengan masing-masing piranti ?• Apakah ada pakar local untuk menjawab pertanyaan pertanyaan mengenai piranti tersebut ?• 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 :• Apakah orang-orang terbaik didapatkan ?• Apakah orang-orang tersebut memiliki gabungan ketrampilan yang benar ?• Apakah orang-orang yang ada mencukupi ?• Apakah staf yang ada dimasukkan ke dalam seluruh durasi proyek ?• Apakah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini ?• Apakah staf memiliki pengharapan yang tepat mengenai pekerjaan yang ada sekarang ?• Sudahkah staf menerima pelatihan yang memadai ?• 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.

Thank You