Manajemen merupakan sebuah proses terpadu dimana individu-individu sebagai bagian dari organisasi yang dilibatkan untuk merencanakan, mengorganisasikan, menjalankan dan mengendalikan aktifitas-aktifitas, yang kesemuanya diarahkan pada sasaran yang telah ditetapkan dan berlangsung terus menerus seiring dengan berjalannya waktu. Agar proses manajemen berjalan lancar, diperlukan sistem serta struktur organisasi yang solid. Pada organisasi tersebut, seluruh aktifitasnya haruslah berorientasi pada pencapaian sasaran. Organisasi tersebut berfungsi sebagai wadah untuk menuangkan konsep, ide-ide manajemen. Jadi dapat dikatakan bahwa manajemen merupakan suatu rangkaian tanggung jawab yang berhubungan erat satu sama lainnya.
• Pengertian Proyek
Proyek merupakan suatu tugas yang perlu dirumuskan untuk mencapai sasaran yang dinyatakan secara kongkrit serta harus diselesaikan dalam suatu periode tertentu dengan menggunakan tenaga manusia dan alat-alat yang terbatas dan begitu kompleks sehingga dibutuhkan pengelolaan dan kerjasama yang berbeda dari yang biasanya digunakan. Menurut DI Cleland dan Wr. King (1987), proyek merupakan gabungan dari berbagai sumber daya yang dihimpun dalam organisasi sementara untuk mencapai suatu tujuan tertentu.
• Manajemen Proyek
Manajemen proyek adalah penerapan dari pengetahuan, ketrampilan, ‘tools and techniques’ pada aktivitas-aktivitas proyek supaya persyaratan dan kebutuhan dari proyek terpenuhi. Proses-proses dari manajemen proyek dapat dikelompokkan dalam lima kelompok yaitu : ‘initiating process, planning process, executing process, controlling process dan closing process’.
Bilamana dibandingkan dengan definisi dari proyek, maka semua ‘pekerjaan yang lain’ dianggap sebagai suatu rutinitas belaka. Suatu pekerjaan rutin biasanya berlangsung secara kontinu, berulang-ulang dan berorientasi ke proses. Sebagai suatu proses yang terus menerus, pekerjaan yang rutin tidak dianggap suatu proyek.
Pengertian Resiko
Ada banyak definisi tentang resiko, resiko dapat ditafsirkan sebagai bentuk keadaan ketidakpastian tentang suatu keadaan yang akan terjadi nantinya (future) dengan keputusan yang diambil berdasarkan berbagai pertimbangan pada saat ini.
• Manajemen Resiko
Manajemen resiko adalah proses pengukuran atau penilaian resiko serta pengembangan strategi pengelolaannya. Strategi yang dapat diambil antara lain adalah memindahkan resiko kepada pihak lain, menghindari resiko, mengurangi efek negatif resiko, dan menampung sebagian atau semua konsekuensi resiko tertentu. Manajemen resiko tradisional terfokus pada resiko-resiko yang timbul oleh penyebab fisik atau legal (seperti bencana alam atau kebakaran, kematian serta tuntutan hukum). Manajemen resiko adalah rangkaian langkah-langkah yang membantu suatu perangkat lunak untuk memahami dan mengatur ketidak pastian (Roger S. Pressman).
1. Contoh Manajemen Proyek dan Resiko
Contoh manajemen proyek diantaranya adalah : membangun sebuah stadion sepak bola, megelola penelitian berskala besar, melaksanakan pembedahan transplantasi organ tubuh, memasang lintas produksi, atau berjuang mendapatkan ijazah strata satu di suatu perguruan tinggi.
2. Contoh manajemen resiko diantaranya adalah :
1. Manajement Resiko Proyek Pengembangan Perangkat Lunak Mybiz 2 di Software House ABC
Software House ABC merupakan sebuah perusahaan pembuatan perangkat lunak yang memprioritaskan dirinya dalam pengembangan perangkat lunak produksi masal untuk keperluan perusahaan dagang, khususnya dalam hal inventory dan payroll. Salah satu proyek perangkat lunak yang sedang dikembangkan saat ini adalah MyBiz 2. Dalam proses pengembangannya, seringkali Software House ABC harus menghadapi resiko atau masalah yang sifatnya tidak terduga. Resiko yang muncul akan menghambat jalannya proses pengembangan perangkat lunak. Metode yang digunakan untuk mengatasinya selama ini bersifat reaktif atau hanya akan direncanakan jika resiko sudah benar-benar terjadi. Karenanya Software House ABC membutuhkan sebuah metode manajemen resiko khususnya untuk proyek MyBiz 2 ini. Penelitian ini dilakukan berdasarkan metodologi manajemen resiko proyek pengembangan perangkat lunak yang ada dan dilakukan melalui lima tahap yaitu tahap perencanaan manajemen resiko, tahap identifikasi resiko, tahap analisa resiko, tahap perencanaan respon resiko, dan tahap pengawasan dan kontrol resiko. Tujuan dari penelitian ini adalah menerapkan manajemen resiko sesuai dengan metodologi yang ada pada proyek MyBiz 2. Hasil yang diharapkan dari penelitian adalah dokumentasi penerapan manajemen resiko proyek pengembangan perangkat lunak MyBiz 2 di Software House ABC.
3. IDENTIFIKASI DAN MITIGASI RESIKO BERKAITAN DENGAN TOTAL PRODUCTIVE MAINTENANCE (TPM) DENGAN MENGGUNAKAN PENDEKATAN MANAJEMEN RESIKO
PT Unilever Indonesia, Tbk sebagai perusahaan multinasional dengan kapasitas produksi yang tinggi pertahunnya, menerapkan Total Productive Maintenance (TPM) agar dapat menjadi perusahaan kelas dunia baik dalam hal produksi, maintenance, maupun kualitas. Akan tetapi nampaknya penerapan itu belum dapat memaksimalkan efektivitas peralatannya. Penelitian ini bertujuan untuk mengidentifikasi resiko yang berkaitan dengan penerapan TPM dengan efektivitas peralatan sebagai titik utamanya. Penyebab nilai efektivitas peralatan ini akan dilihat melalui indikator kinerja (KPI) pada pilar-pilar yang diterapkan untuk mendukung penerapan TPM. Selain itu cause effect diagram juga digunakan sebagai alat bantu untuk mengidentifikasi resiko dan segala penyebabnya. Setelah semua resiko teridentifikasi, akan dilakukan analisis, evaluasi, serta langkah mitigasi pada resiko tersebut. Hasil dari penelitian ini adalah prioritas resiko yang perlu diwaspadai oleh perusahaan beserta langkah mitigasi yang diperlukan untuk menangani resiko tersebut. Adapun mitigasi yang dihasilkan disini adalah control, menghindari, atau mentransfer resiko tersebut.
TEORI
Pengertian Proyek : proyek merupakan suatu tugas yang perlu dirumuskan untuk mencapai sasaran yang dinyatakan secara kongkrit serta harus diselesaikan dalam suatu periode tertentu dengan menggunakan tenaga manusia dan alat – alat yang terbatas dan begitu kompleks sehingga dibutuhkan pengelolaan dan kerja sama yang berbeda dari yang biasanya digunakan
Ciri – ciri proyek
1. sasarannya jelas
2. sasaran diarahkan pada suatu perubahan atau pembaharuan
3. sasaran terjadi hanya satu kali
4. ada batasan awal dan batasan akhir pelaksanaan proyek
5. proyek bersifat antar disiplin
6. adanya anggaran dan batasan terhadap biaya – biaya
Macam – macam proyek
1. proyek pengembangan produk baru adalah kegiatan untuk menciptakan produk baru yang biasanya merupakan gabungan antara proyek kapital dan proyek riset dan pengembangan
2. proyek kapital (modal)
3. proyek penelitian dan pengembangan adalah kegistsn untuk melakukan penelitian dengan sasaran yang ditentukan.proyek ini dapat berupa proyek yang meningkatkan dan memperbaiki mutu produk
4. proyek sistem informasi adalah kegiatan yang sifatnya spesifik dengan mempergunakan alat – alat pemprosesan data.
Manajemen proyek adalah merencanakan, menyusun organisasi memimpin dan mengendalikan sumber proyek daya perusahaan untuk mencapai sasaran jangka pendek yang telah ditentukan
Konsep manajemen proyek meliputi :
1. Proyek merupakan suatu kegiatan yang sifatnya sementara dengan tujuan tertentu dan memanfaatkan sumber – sumber daya
2. manajemen proyek adalah proses pencapaian tujuan proyek dalam suatu wadah tertentu
3. manajemen proyek meliputi langkah – langkah perencanaan, pelaksanaan, pengawasan, dan penyesuaian proyek.
4. kendala / hambatan proyek adalah spesifikasi kerja, jadwal waktu dan dana
5. bentuk organisasi atau wadah yang dimaksud dalam manajemen proyek adalah organisasi fungsional, koordinator gugus tegas dan matrik
manajemen resiko;
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.
Rekayasa Perangkat Lunak
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
Rekayasa Perangkat Lunak
@ 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 generic 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 Rekayasa Perangkat Lunak
@ 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 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 ?
Rekayasa Perangkat Lunak
• 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
Rekayasa Perangkat Lunak
• 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
Rekayasa Perangkat Lunak
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 system 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.
Rekayasa Perangkat Lunak
@ Resiko lingkungan pengembangan
Resiko yg berhubungan dgn keberadaan & kualitas peranti yg akan digunakan untuk membangun produk. Lingkungan proses PL mendukung tim proyek, proses dan produk.
Lingkungan yg salah dapat menjadi sumber resiko yg penting.
Checklist item resiko yg berhubungan dengan lingkungan
pengembangan :
• Apakah peranti manajemen proyek dapat diperoleh?
• Apakah peranti manajemen proses dapat diperoleh?
• Apakah peranti untuk analisis dan desain dapat diperoleh?
• Apakah peranti analisis dan desain penyampaian metode sesuai bagi produk yg akan dibangun?
• Apakah kompiler atau generasi kode dapat diperoleh dan sesuai untuk produk yg akan dibangun?
• Apakah peranti pengujian dapat diperoleh dan sesuai untuk produk yg akan dibangun?
• Apakah peranti manajemen konfigurasi PL dapat diperoleh?
• Apakah lingkungan menggunakan suatu database atau tempat penyimpanan?
• Apakah semua peranti PL dapat diintegrasikan satu dgn lainnya?
• Sudahkah anggota tim proyek menerima pelatihan dgn masing2 peranti?
• Apakah ada pakar lokal untuk menjawab pertanyaan2 mengenai peranti tersebut?
• Apakah bantuan dan dokumentasi on-line bagi peranti memadai?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah ’tidak’, berarti lingkungan pengembangan PL lemah dan berisiko tinggi.
Rekayasa Perangkat Lunak
@ Resiko yg berhubungan dgn ukuran & pengalaman staf
Resiko yg berhubungan dgn keseluruhan teknik & pengalaman proyek dari RPL yg akan melakukan tugas tsb. Checklist item resiko yg berhubungan dengan ukuran & pengalaman staf :
• Apakah orang2 terbaik dapat diperoleh?
• Apakah orang2 tsb memiliki gabungan ketrampilan yg benar?
• Apakah orang2 yg ada mencukupi?
• Apakah staf dimasukkan ke dalam seluruh durasi proyek?
• Akankah banyak staf proyek bekerja hanya dalam paruh waktu pada proyek ini?
• Apaka staf memiliki pengharapan yg tepat mengenai pekerjaan yg ada sekarang?
• Sudahkah staf menerima pelatihan yg memadai?
• Apakah pergantian di antara staf akan cukup rendah untuk memungkinkan kontinuitas?
Bila jawaban terhadap pertanyaan2 tsb adalah ’tidak’, maka penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial.
Komponen Risiko dan Driver Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu
menghendaki agar manajer proyek mengidentifikasi risiko driver yg mempengaruhi komponen risiko PL – kinerja, biaya, dukungan dan jadwal.
Komponen risiko didefinisikan dgn cara sbb :
Rekayasa Perangkat Lunak
• Risiko kinerja – tingakat ketidakpastian dimana produk akan memenuhi persyaratannya dan cocok dgn penggunaannya.
• Risiko biaya – tingkat ketidakpastian dimana biaya proyek akan dijaga
• Risiko dukungan – tingkat ketidakpastian dimana PL akan mudah dikoreksi, disesuaikan dan ditingkatkan.
• Risiko jadwal – tingkat ketidakpastian dimana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu. Pengaruh driver risiko thd komponen risiko dibagi ke dalam satu dari empat kategori pengaruh – diabaikan, marjinal, kritis dan katastropis. Tabel 6.1. menunjukkan konsekuensi potensial kesalahan (baris berlabel 1) atau kegagalan untuk mencapai suatu keluaran yg diharapkan (baris berlabel 2). Kategori pengaruh dipilih berdasarkan karakterisasi yg paling cocok dgn deskripsi pada tabel.
Rekayasa Perangkat Lunak, Penilaian Pengaruh KOMPONEN KINERJA DUKUNGAN BIAYA JADWAL
KATEGORI
1 Gagal memenuhi persyaratan Kegagalan menyebabakan biaya menyebabkan misi gagal meningkat dan jadwal tertunda dgn EV>$500K Tgl pengiriman Kemungkinana PL yg tdk KATASTROPIK 2 Degradasi yg tdk dpt kurangnya responsive signifikanpd dipenuhi finansial dan atau tdk dpt tdk membengkaknya berprestasinya didukung anggaran kinerja teknis Kegagalan menyebabkan
1 Gagal memenuhi persyaratan tertundanya operasinal dan atau akan menurunkan kinerja ke titik meningkatnya biaya dgn EV $100K dimana sukses misi diragukan s/d $500K Sedikit Sedikit Penundaan KRITIS 2 Beberapa meleset dlm tgl kekurangan minor dalam penundaan dlm pengiriman sumber daya modifikasi PL kinerja teknis finansial, mungkin
membengkak Biaya, pengaruh dan atau
1 Gagal memenuhi persyaratan melesetnya jadwal dpt diperbaiki akan mengakibatkan degradasi dgn EV $1 s/d $100K misi kedua Jadwal yg Dukungan PL Sumber daya MARJINAL 2 Penurunan realistis dan minimal sampai yg responsif finansial yg dpt dicapai mencukupi kecil dlm kinerja teknis Kesalahan menyebabkan biaya
1 Gagal memenuhi persyaratan tambahan dan atau berpengaruh memberikan pengaruh yg tdk terhadap jadwal dgn EV < $1K menyenangkan dan DAPAT non-operasional DIABAIKAN Tgl pengiriman Mungkin
PL yg dpt
2 Tdk ada dpt dicapai anggaran di bwh didukung dg \penurunan dlm lebih cepat ketentuan mudah kinerja teknis Rekayasa Perangkat Lunak Bab 6 Halaman 15 Catatan:
(1) Konsekuensi potensial terhadap kesalahan PL yg tdk dpt dideteksi
(2) Konsekuensi potensial jika hasil akhir yg diinginkan tidak tercapai EV = Expected Value PROYEKSI RISIKO / PERKIRAAN RISIKO
Dua cara melakukan proyeksi risiko :
1. Probabilitas di mana risiko adalah nyata
2. Konsekuensi masalah yang berhubungan dengan risiko Perencanaan proyek bersama dengan manajer & staf teknik
melakukan 4 aktifitas proyeksi risiko :
1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan
2. Menggambar konsekuensi risiko
3. Memperkirakan pengaruh risiko pada proyek dan produk
4. Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada kesalahpahaman
MENGEMBANGKAN TABEL RISIKO
Tabel risiko memberi manajer proyek sebuah teknik sederhana bagi
proyeksi risiko.
Risiko Kategori Prob Pengaruh RMMM Estimasi ukuran rendah PS 60% 2 secara signifikan
Jumlah pemakai lebih PS 30% 3 besar dari yg diharapkan PS 70% 2 Pemakaian ulang lebih rendah dr yg diharapkan Pemakaian akhir menolak BU 40% 3 Deadline pengiriman BU 50 % 2 diperketat Pendanaan dihapuskan CU 40% 1 Pelanggan akan merubah PS 80% 2 kebutuhan Teknologi tdk memenuhi TE 30% 1
harapan Kurangnya pelatihan pada DE 80% 3 piranti Staf tdk berpengalaman ST 30% 2 Turnover staf tinggi ST 60% 2 § § §
KATEGORI RISIKO :
PS : Ukuran produk TE : Teknologi
BU : Bisnis DE : Lingkungan Pengembangan
CU : Proses ST : Ukuran Staf & Pengalaman
Rekayasa Perangkat Lunak
NILAI PENGARUH
1 : Katastropik 3 : Marjinal
2 : Kritis 4 : Dapat diabaikan
Caranya :
1. Daftarkan semua risiko
2. Masing-masing risiko dikatogorikan
3. Probabilitas masing-masing risiko dapat diperkirakan oleh anggota tim secara individual
4. Pengaruh masing-masing risiko diperkirakan dengan menggunkan karekteristik .
5. Katergori untuk masing-masing dari keempat komponen risiko kinerja, dukungan, biaya, dan jadwal dirata-rata untuk menentukan nilai keseluruhan
6. Urutkan probabilitas tinggi dan pengaruh tinggi dimasukkan ke urutan pertama.
MENILAI PENGARUH RISIKO
Tiga factor yg mempengaruhi konsekuensi jika suatu risiko benar-benar terjadi :
1. Sifatnya ; risiko yang menunjukkan masalah yg muncul bila ia terjadi
2. Ruang lingkupnya; menggabungkan kepelikannya (seberapa seriusnya masalah ini ? ) dengan keseluruhan distribusi ( berapa banyak proyek yg akan dipengaruhi atau berapa banyak pelanggan terganggu ? )
3. Timingnya; mempertimbangkan kapan dan untuk berapa lama pengaruh itu dirasakan. Rekayasa Perangkat Lunak Bab 6 Halaman 18 Seorang manajer proyek mungkin menginginkan berita buruk terjadi
segera mungkin tetapi dalam beberapa kasus penundaan lebih lama akan lebih baik.
Langkah-langkah yg direkomendasikan untuk menentukan konsekuensi keseluhan dari suatu resiko :
1. Tentukan probabilitas rata-rata dari nilai kejadian untuk masing-masing komponen risiko
2. tentukan pengaruh untuk masing-masing komponen berdasarkan kreteria yg diperlihatkan
3. Lengkapi tabel risiko dan analsis hasilnya seperti dijelaskan sebelumnya di bab 6 ini. Tim proyek harus melihat tabel risiko pada interval yg regular mengevaluasi lagi masing-masing risiko untuk menentukan kapan keadaan baru menyebabkan probabilitas dan pengaruh berubah. Akibatnya diperlukan penambahan risiko baru ke tabel, mengganti risiko yg tidak relevan dan mengubah pemosisian relatif dari risiko lainnya.
PENILAIN RISIKO
Dalam proses manajemen risiko, maka telah membangun serangkaian titik tripel yg berbentuk :
[ ri , l i , x i ] ri adalah risiko, li adalah kemungkinan (probabilitas) dan xi adah pengaruh dari risiko tersebut. Selama penilaian risiko harus menguji akurasi estimasi yg dibuat selama proyeksi risiko dan
Rekayasa Perangkat Lunak Bab 6 Halaman 19 memprioritaskan risiko yg telah diungkap dan cara mengontrol serta mencegah risiko yg mungkin terjadi. Tingkat referen risiko harus ditentukan sehingga bermanfaat. Sebagian besar proyek PL , komponen resiko yaitu kinerja, biaya, dukungan dan jadwal mencerminkan tingkat referen risiko. Tingkat referen risiko adalah tingkat degradasi kinerja,
peningkatan biaya, kesulitan dukungan, dan melesatnya jadwal yang menyebabkan proyek diterminasi.
Jika kombinasi risiko menciptakan masalah sehinnga ≥ 1 tingkat referen terlampaui maka kerja berhenti.
Tingkat referen memiliki titik tunggal yg disebut referen point / break point dimana keputusan diteruskan atau dihentikan sama-sama diterima.
Selama penilaian maka dilakukan langkah-langkah sebagai berikut :
1. Tentukan tingkat referen risiko untuk proyek
2. Usahakan untuk mengembangkan hubungan antara [ ri , l i , x i ] masing-masing dan masing-masing tingkat referen
3. Prediksi himpunan titik referen yg menentukan daerah tereliminasi dibatasi oleh kurva atau area ketidakpastian.
4. Cobalah memprediksi bagaimana penggabungan kombinasi risiko akan mempengaruhi suatu titik referen
PENGURANGAN, MONITORING dan MANAJEMEN RISIKO
Aktifitas analisis risiko mempunyai titik tunggal yg memiliki tujuan untuk membantu tim proyek dalam mengembangkan strategi yg berkaitan dengan risiko. Rekayasa Perangkat Lunak Bab 6 Halaman 20
Strategi yg efektif harus :
1. Menghindari risiko
2. Memonitoring risiko
3. Manajemen risiko dan perencanaan kemungkinan
Langkah-langkah untuk mengurangi turnover staf adalah
1. Temui staf yg ada, untuk menentukan penyebab keluar
2. Bertindaklah untuk mengurangi penyebab-penyebab yg ada di bawah kontrol manajemen sebelum proyek dimulai
3. Bila proyek dimulai asumsikan turnover akan terjadi dan kembangkan teknik-teknik untuk memastikan kontiunitas pada saat orang keluar
4. Kumpulkan tim proyek sehingga informasi mengenai masing-masing aktivitas pengembangan dapat disebarluaskan
5. Tentukan standar dokumentasi dan buat mekanisme untuk memastikan bahwa dokumen dikembangkan tepat waktu
6. Lakukan kajian antar teman terhadap semua pekerjaan tersebut sehingga lebih dari satu orang yang terbiasa dengan pekerjaan itu
7. Tentukan backup anggota staf untuk setiap teknologi kritis Aktifitas pemonitoran dimulai, manajer proyek memonitor factor-faktor yang dapat memberikan suatu indikasi apakah risiko
mungkin sedang menjadi lebih atau kurang.
Untuk kasus turnover tinggi, factor-faktor yg dapat dimonitor :
1. Sikap umum anggota tim berdasarkan tekanan proyek
2. Tingkat di mana tim disatu – padukan
3. Hubungan interpersonal di antara anggota tim
4. Masalah pontensial dengan kompensasi dan manfaat
5. Keberadaan pekerjakan di dalam perusahaan dan di luarnya
Rekayasa Perangkat Lunak Bab 6 Halaman 21 Langkah pengurangan resiko diperlukan bagi definisi standar dokuntasi dan mekanisme untuk memastikan bahwa dokumen dikembangkan secara tepat waktu, guna memastikan kontinuitas. Manajemen risiko dan perencanaan kemungkinan mengasumsikan bahwa usaha pengurangan telah gagal dan risiko menjadi suatu kenyataan.
Contoh, diandaikan proyek sedang berlangsung dengan baik dan sejumlah orang mengatakan akan keluar dari proyek tersebut maka strategi pengurangan telah dilakukan dengan backup , informasi,
dokumentasi dan pengetahuan telah disebar ke semua tim. Manajer proyek akan menyesuaikan lagi jadwal dengan fungsi-fungsi yg telah disusun sepenuhnya dan pendatang baru akan ditambah untuk
mengejar dan membagun serta akan ditransfer pengetahuan oleh orang akan keluar.
Langkah RMMM (Risk Mitigating Monitoring and Management Plan) menambah biaya proyek.
RISIKO KESELAMATAN DAN BAHAYA
Risiko tidak hanya pada proyek itu sendiri tetapi juga pada risiko kegagalan PL dilapangan (pemakai akhir). Bila PL digunakan untuk sistem kontrol, kompleksitas sistem dapat bertambah dengan urutan naik. Cacat desain yg tidak kentara yaitu sesuatu yg tidak dapat terungkap dan tereliminasi dalam kontrol konvensional berbasis perangkat keras menjadi lebih sulit diungkap pada saat PL digunakan.
Rekayasa Perangkat Lunak Bab 6 Halaman 22 Keselamatan PL dan analisis bahaya adalah aktifitas jaminan kualitas PL yg berfokus pd indentifikasi dan perkiraan bahaya pontensial terhadap PL dan menyebabkan kegagalan sistem. RMMM PLAN Strategi manajemen risiko dapat dimasukkan dalam rencana proyek PL atau langkah manajemen risiko dapat diatur ke dalam RMMM
PLAN yg terpisah dimana akan didokumentasikan semua kegiatan yg dilakukan sebagai bagian dari analisis risiko dan oleh manajer proyek digunakan sebagai bagian dari keseluruhan rencana proyek.
Uraian untuk RMMM PLAN adalah sebagai berikut :
I. Pengantar
1. Lingkup dan tujuan Dokumen
2. Tinjauan risiko utama
3. Tanggung jawab
a. Manajemen
b. Staf teknis
II. Tabel Risiko Proyek
1. Deskripsi semua risiko di atas yang ditentukan
2. Faktor-faktor yang mempengaruhi probabilitas dan
pengaruh
III. Pengurangan, monitoring, dan Manajemen Risiko
n. Risiko # n
a. Pengurangan
i. Strategi umum
ii. Langkah khusus untuk mengurangi risiko
b. Monitoring
i. Faktor-faktor yang dimonitoring
ii. Pendekatan monitoring
c. Manajemen
Rekayasa Perangkat Lunak Bab 6 Halaman 23
i. Rencana kontigensi
ii. Konsiderasi khusus
IV. Jadwal Iterasi Rencana RMMM
V. Kesimpulan
Sasaran dari monitoring risiko (aktifitas penelurusan proyek) yaitu
1. Memperkirakan apakah risiko yang diramalkan benar-benar terjadi
2. Memastikan bahwa langkah aversi risiko yang didefiniskan untuk risiko telah diterapkan secara benar
3. Mengumpulkan informasi yang dapat digunakan untuk analisis risiko masa yang akan datang
Tugas lain dari monitoring risiko adalah berusaha menentukan risiko asli pada seluruh proyek.
Tidak ada komentar:
Posting Komentar