Sunday, May 22, 2016

MPPL - UAS Dokumentasi lengkap

Nama : I Gusti Ngurah Adi Wicaksana
NRP : 5113100110
Kelas : F

Deskripsi Proyek
Pada awalnya proses bisnis yang terjadi pada PT.Yonote berjalan secara manual. Namun dengan proses bisnis yang manual tersebut pendataan pelanggan tidak dapat dilakukan dengan baik, proses bisnis yang terjadi juga tidak dapat berjalan dengan baik dengan besarnya kemungkinan Human Error yang terjadi.
Dengan adanya sistem infromasi ini, semua proses bisnis dan pendataan yang dilakukan oleh PT. Yonote akan lebih baik, dan kemungkinan kesalahan yang diakibatkan oleh human error dapat diminimalisir.
Aplikasi ini adalah aplikasi desktop akan dibuat dengan menggunakan VB.net guna mempermudah dan mempercepat proses pembuatan aplikasi. Selain itu, aplikasisistem informasi ini membutuhkan database untuk menyimpan dan mendapatkan informasi-informasi yang berkaitan dengan proses bisnis PT. Yonote. Database diolah dengan bantuan software Microsoft SQL Server 2005. 

Link Dokumentasi yang telah dikerjakan.
  1. Link KAK
  2. Link Project Charter
  3. Link Manajemen Waktu
  4. Link Manajemen Biaya
  5. Link Manajemen SDM
  6. Link Manajemen Resiko
  7. Link Manajemen  Mutu 
  8. Link Monitoring Kegiatan
Link Dokumen Pelengkap Lain : Drive MPPL 

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

Penyebab kegagalan rekayasa perangkat lunak adalah :
-       Perencanaan yang tidak realistik, terlalu optimis dalam perhitungan.
-       Sistem pemantauan kerja yang tidak berjalan dengan seharusnya.
-       Perubahan kebutuhan.

Ada resiko yang terlihat lebih penting dari pada resiko lainnya. Baik penting atau tidaknya resiko tergantung pada resiko tersebut, pengaruhnya pada aktivitas tertentu dan kekeritisan aktivitas tersebut.  Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk meminimalkan resiko atau paling tidak mendistribusikan selama pengembangan.

Resiko dalam perangkat lunak memiliki dua karakteristik :
-       Uncertainty : tidak ada resiko yang 100% pasti muncul.
-       Loss : resiko berimbas pada kehilangan.

Dan resiko memiliki tiga kategori :
-       Resiko proyek : berefek pada perencanaan proyek.
-       Resiko teknikal : berefek pada kualitas dan waktu pembuatan perangkat lunak.
-       Resiko bisnis : berefek pada nilai jual produk

Identifikasi Resiko Proyek Pembuatan Sistem Informasi PT. Yonote

No
Risiko
Jenis Risiko
Kategori (check list risiko)
Usaha yang dilakukan
1
Dokumentasi tidak detail.
Risiko yang sudah diketahui
Resiko proyek
Melakukan validasi mereview ulang.
2
Waktu pengerjaan lebih lama dari yang direncanakan
Resiko yang dapat diramalkan
Resiko proyek
Resiko teknikal
Resiko bisnis
Memastikan milestone dilaksanakan sesuai dengan jadwalnya, jika tidak maka setiap stakeholder yang terkait harus menerima risiko agar bisa mengembalikan sesuai jadwal, seperti lembur.

3
Server tidak kuat menangani banyaknya permintaan
Risiko yang dapat diramalkan
Resiko teknikal
Melakukan peningkatan spesifikasi server dan mendistribusikan server sehingga operasi tidak dilakukan oleh satu server.
4
User Interface (UI) yang kurang user-friendly
Risiko yang dapat diramalkan
-  Risiko teknikal
Melakukan teknik validasi UI dengan prototyping, bekerja sama dengan pengguna sebagai tester.
5
Server rusak
Risiko yang tidak diharapkan
-  Resiko proyek
Resiko teknikal
Back up data dari satu server ke server lain yang merupakan replikasi server utama.
6
Terjadi hal yang tidak di inginkan pada developer saat pengerjaan.
Risiko yang tidak diharapkan
-  Resiko proyek
Mengatur waktu kerja seefektif mungkin untuk menghindari kerja berlebihan dan stress


Analisa Resiko
Penentuan probabilitas terjadinya suatu event sangatlah subyektif dan lebih berdasarkan nalar dan pengalaman. Beberapa risiko memang mudah untuk diukur, namun sangatlah sulit untuk memastikan probabilitas suatu kejadian yang sangat jarang terjadi. Sehingga, pada tahap ini sangtalah penting untuk menentukan dugaan yang terbaik supaya nantinya kita dapat memprioritaskan dengan baik dalam implementasi perencanaan manajemen risiko. Kesulitan dalam pengukuran risiko adalah menentukan kemungkinan terjadi suatu risiko karena informasi statistik tidak selalu tersedia untuk beberapa risiko tertentu. Selain itu, mengevaluasi dampak severity (kerusakan) seringkali cukup sulit untuk asset immateriil. Dampak adalah efek biaya, waktu dan kualitas yang dihasilkan suatu resiko.

Dampak
Biaya
Waktu
Kualitas
Sangat rendah
Dana mencukupi
Agak menyimpang dari target
Kualitas agak berkurang namun masih dapat digunakan
Rendah
Membutuhkan dana tambahan
Agak menyimpang dari target
Gagal untuk memenuhi janji pada stakeholder
Sedang
Membutuhkan dana tambahan
Penundaan berdampak terhadap stakeholder
Beberapa fungsi tidak dapat dimanfaatkan
Tinggi
Membutuhkan dana tambahan yang signifikan
Gagal memenuhi deadline
Gagal untuk memenuhi kebutuhan banyak stakeholder
Sangat tinggi
Membutuhkan dana tambahan yang substansial
Penundaan merusak proyek
Proyek tidak efektif dan tidak berguna

Setelah mengetahui probabilitas dan dampak dari suatu resiko, maka kita dapat mengetahui potensi suatu resiko. Untuk mengukur bobot resiko kita dapat menggunakan skala dari 1 – 5 sebagai berikut :

Skala
Probabilitas
Dampak
Sangat rendah
Hampir tidak mungkin terjadi
Dampak kecil
Rendah
Kadang terjadi
Dampak kecill pada biaya, waktu dan kualitas
Sedang
Mungkin tidak terjadi
Dampak sedang pada biaya, waktu dan kualitas
Tinggi
Sangat mungkin terjadi
Dampak substansial pada biaya, waktu dan kualitas
Sangat tinggi
Hampir pasti terjadi
Mengancam kesuksesan proyek

Setelah resiko yang dapat mempengaruhi pengembangan teridentifikasi maka diperlukan cara untuk menentukan tingkat kepentingan dari masing-masing resiko. Beberapa resiko secara relatif tidak terlalu fatal (misal resiko keterlambatan penyerahan dokumentasi) sedangkan beberapa resiko lainnya berdampak besar.  (misal resiko keterlambatan penyerahan software).  Beberapa resiko sering terjadi (salah satu anggota tim sakit sehingga tidak bisa bekerja selama beberapa hari). Sementara itu resiko lainnya jarang terjadi (misal kerusakan perangkat keras yang dapat mengakibatkan sebagian program hilang).

Pengelolaan Resiko
Terdapat beberapa cara untuk mengelola resiko yaitu sebagai berikut :
1. Risk Avoidance
Yaitu memutuskan untuk tidak melakukan aktivitas yang mengandung resiko sama sekali. Dalam memutuskan untuk melakukannya, maka harus dipertimbangkan potensial keuntungan dan potensial kerugian yang dihasilkan oleh suatu aktivitas
2.    Risk Reduction
Risk reduction atau disebut juga risk mitigation yaitu merupakan metode yang mengurangi kemungkinan terjadinya suatu resiko ataupun mengurangi dampak kerusakan yang dihasilkan oleh suatu resiko.
3.    Risk Transfer
Yaitu memindahkan resiko pada pihak lain, umumnya melalui suatu kontrak (asuransi) maupun hedging.
4.    Risk Deferral
Dampak suatu resiko tidak selalu konstan. Risk deferral meliputi menunda aspek suatu proyek hingga saat dimana probabilitas terjadinya resiko tersebut kecil.
5.     Risk Retention
Walaupun resiko tertentu dapat dihilangkan dengan cara mengurangi maupun mentransfernya, namun beberapa resiko harus tetap diterima sebagai bagian penting dari aktivitas.
Penanganan resiko:
  1. High probability, high impact: resiko jenis ini umumnya dihindari ataupun ditransfer.
  2. Low probability, high impact: respon paling tepat untuk tipe resiko ini adalah dihindari. Dan jika masih terjadi, maka lakukan mitigasi resiko serta kembangkan contingency plan.
  3. High probability, low impact: mitigasi resiko dan kembangkan contingency plan.
  4. Low probability, low impact: efek dari resiko ini dapat dikurangi, namun biayanya dapat saja melebihi dampak yang dihasilkan. Dalam kasus ini mungkin lebih baik untuk menerima efek dari resiko tersebut.

Contigency plan
Untuk resiko yang mungkin terjadi maka perlu dipersiapkan contingency plan seandainya benar-benar terjadi. Contigency plan haruslah sesuai dengan proposional terhadap dampak resiko tersebut. Dalam banyak kasus seringkali lebih efisien untuk mengalokasikan sejumlah sumber daya untuk mengurangi resiko dibandingkan mengembangkan contingency plan yang jika diimplementasikan akan lebih mahal. Namun beberapa skenario memang membutuhkan full contingency plan, tergantung pada proyeknya. Namun jangan sampai tertukar antaracontingency planning dengan re-planning normal yang memang dibutuhkan karena adanya perubahan dalam proyek yang berjalan.

Tabel resiko proyek software dan strategi mengurangi resiko :
Resiko
Teknik mengurangi resiko
Kegagalan pada personil
·        Memperkerjakan staf yang handal
·        Job matching
·        Membangun tim
·        Mengadakan pelatihan dan peningkatan karir
·        Membuat jadwal lebih awal bagi personil utama
Estimasi biaya dan waktu yang tidak realistis
·   Membuat beberapa estimasi
·   Desain untuk biaya
·   Meningkatkan pengembangan
·   Merekam dan menganalisa proyek sebelumnya
·   Standarisasi metode
Mengembangkan fungsi software yang salah
·   Evaluasi proyek ditingkatkan
·   Buat metode spesifikasi yang formal
·   Survey pengguna
·   Buat prototype
·   Buat user manual lebih awal
Mengembangkan antarmuka pengguna yang salah
·   Membuat prototype
·   Analisis tugas
·   Keterlibatan pengguna
Gold plating
·   Mengurangi kebutuhan
·   Membuat prototype
·   Analisis biaya manfaat
·   Desain biaya
Terlambat untuk mengubah kebutuhan
·   Mengubah prosedur kendali
·   Membatasi perubahan yang terlalu banyak
·   Meningkatkan prototype
·   Meningkatkan pengembangan (akibat perubahan)
Kegagalan pada komponen yang disuplai pihak eksternal
·   Melakukan benchmarking
·   Inspeksi
·   Spesifikasi formal
·   Kontrak perjanjian
·   Prosedur dan sertifikasi jaminan kualitas
Kegagalan menjalankan tugas eksternal
·   Prosedur jaminan kualitas
·   Desain / prototype yang kompetitif
·   Membangun tim
·   Kontrak insentif
Kegagalan kinerja real-time
·   Simulasi
·   Benchmarking
·   Prototipe
·   Tuning
·   Analisis teknis
Pengembangnya terlalu sulit secara teknis
·   Analisa teknis
·   Analisis biaya manfaat
·   Prototipe
·   Melatih dan mengembangkan staf


Daftar Resiko
No
Rank
Risk
Category
Root
Cause
Risk
Owner
Status
R5
1
Server rusak
Resiko Teknologi
 Server
Stakeholder
Active
R1
2
Dokumentasi yang tidak mendetail
Struktur/Proses risiko
Developer
Developer
Active
R3
3
Waktu pengerjaan yang lebih lama dibandingkan dengan rencana pengerjaan
Struktur/Proses risiko
 Developer
Developer
Active

Mitigasi
No
Risk
Risiko
Anti-Risk
1
Risk 1
Dokumentasi yang tidak mendetail
-     Melakukan penggalian kebutuhan secara maksimal
-     Analisis scope lebih diperdalam
-     Melakukan pengecekan dokumen secara berkala
2
Risk 2
Waktu pengerjaan yang lebih lama dibandingkan dengan rencana pengerjaan
-      Pengecekan milestone secara teratur sesuai dengantimelinenya
-      Peningkatan otoritas project manager
-      Peningkatan frekuensi pemantauan project
-      Pemilihan project manager yang paling berpengalaman
-      Meningkatkan komunikasi dan pemahaman project goals
-      Peningkatan penanganan masalah dan komunikasi antar
3
Risk 3
Server tidak kuat menangani banyak pengguna
-      Memperkirakan jumlah pengguna yang akan mengakses
-      Melakukan proses dengan beberapa server replikasi sehingga operasi tidak dilakukan oleh satu server saja
4
Risk 4
Desain UI yang kurang user-friendly
-      Melakukan evaluasi secara berkala ke stakeholder
-      Sistem Analyst mengecek secara berkala sudahkah sesuai atau mdah digunakan oleh stakeholder
5
Risk 5
Server rusak
-      Back up data dari satu server ke server lain yang merupakan replikasi server utama
6
Risk 6
Developer sakit pada saat pengerjaan proyek
-      Peningkatan otoritas project manager
-      Pengaturan waktu seefektif mungkin