Friday, November 15, 2019

5 Software Process Model

Menurut saya, software engineering penting dalam pengembangan aplikasi dikarenakan software engineering dapat mengurangi kompleksitas, mengurangi biaya software, mempersingkat waktu, membantu dalam menangani project yang besar, dan sebagainya.

Software Process Model adalah merupakan standarisasi yang ditetapkan untuk membangun suatu perangkat lunak. Di dalam sebuah komputer terdapat sejumlah komponen-komponen hardware aktif yang saling bekerjasama satu dengan yang lainnya untuk menghidupkan komputer.

Waterfall model Proses ini adalah proses yang memiliki sifat sistematis sistem penerapannya, dimana setiap tahap yang dilakukan harus bisa dipastikan bahwa semua kebutuhan yang akan dilakukan sudah dipenuhi dengan sempurna (fixed) sehingga memungkinkan pada tahap selanjutnya tidak ada lagi sistem ulangan-ulangan untuk kembali pada tahap-tahap sebelumnya.

Kelebihan:
  1. Memiliki proses yang urut, mulai dar analisa hingga support
  2. Setiap proses memiliiki spesifikasinya sendiri, sehingga sebuah sistem dapat dikembangkan sesuai dengan apa yang dikehendaki (tepat sasaran)
  3. Setiap proses tidak dapat saling tumpang tindih.

Kekurangan:
  1. Proses yang dilakukan cenderung panjang dan juga lama
  2. Biaya penggunaan metode yang cenderung mahal
  3. Membutuhkan banyak riset dan juga penelitian pendukung untuk mengembangkan sistem menggunakan metode waterfall


V-Model
Jika dalam model waterfall proses dijalankan secara linier, maka dalam model V proses dalikukan bercabang dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

Kelebihan v model :
  1. V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dantool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.
  2. V Model dikembangkan dan di-maintain oleh publik. Userdari V Model berpartisipasi dalam change control boardyang memproses semua change request terhadap V Model.

Kekurangan v model :
  1. V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.
  2. V Model terlalu fleksibel dalam arti ada beberapa activitydalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalamactivity tersebut dan apa yang tidak.

Incremental Model 

adalah proses pemodelan kombinasi antar elemen-elemen Linear Sequential Model dan Prototyping Model. Setiap jangka waktu tertentu, hasil produk ini secara berkala diperbaharui sehingga memungkinkan spesifikasi kebutuhan- kebutuhan pengguna akan fungsi, performa dan efisiensinya dipenuhi.

Kelebihan incremental model :
  1. Resiko yang rendah pada pengembangan sistem.
  2. Mengutamakan fungsi-fungsi pada sistem perangkat lunak sehingga kemudahan pemakaian sistem yang paling di utamakan. 
  3. Tahap awal adalan dasar dari pembuatan tahap berikutnya (dikerjakan secara terurut).
  4. Cocok digunakan bila pembuat software tidak banyak/kekurangan pembuat
  5. Mampu mengakomodasi perubahan kebutuhan customer. 
  6. Mengurangi trauma karena perubahan sistem. Klien dibiasakan perlahan-lahan menggunakan produknya bagian per bagian.
  7. Memaksimalkan pengembalian modal investasi konsumen. 

Kekurangan incremental model :
  1. Hanya akan berhasil jika tidak ada staffing untuk penerapan secara menyeluruh.
  2. Penambahan staf dilakukan jika hasil incremental akan dikembangkan lebih lanjut.
  3. Hanya cocok untuk proyek dengan skala kecil.
  4. kemungkinan tiap bagian tidak dapat diintegrasikan.
Protoyping Model 

adalah model yang dapat diterapkan pada model apapun. Model ini tidak memerlukan data yang lengkap dari sisi client dan banyaknya keraguan dari pembuat software karena kondisi yang belum diketahui (seberapa besar software, bagaimana sistem penerapannya). 


Kelebihan Prototyping model : 
  • Menghemat waktu pengembangan.
  • Adanya komunikasi yang baik antara pengembang dan pelanggan.
  • Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.
  • Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.
  • User dapat berpartisipasi aktif dalam pengembangan sistem.
  • Punya kemampuan menangkap requirement secara konkret daripada secara abstrak.
  • Untuk digunakan secara standalone.

Kekurangan Prototyping model :
  • Pada prototype tentu saja banyak kebutuhan yang tidak di tampilkan seluruhnya karena data yang dikumpulkan hanya sebagian.
  • Prototype yang di setujui oleh client harus dikembangkan oleh developer tanpa ada data tambahan dari client dan software dari prototype harus memiliki fungsi yang lengkap.
  • Banyak ketidak sesuaian pada bentuk prototype.
  • Proses analisis dan perancangan terlalu singkat.
Spiral model 

adalah model proses yang pendekatannya bersifat realistis pada software besar karena proses dari awal sampai proses pengiriman dan perbaikan dapat dipahami dnegan baik oleh clieent dan developer. 

Kelebihan model Spiral :
  • Setiap tahap pengerjaan dibuat prototyping sehingga kekurangan dan apa yang diharapkan oleh client dapat diperjelas dan juga dapat menjadi acuan untuk client dalam mencari kekurangan kebutuhan.
  • Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar.
  • Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer. 
Kekurangan model Spiral :
  • Banyak konsumen (Client) tidak percaya bahwa pendekatan secara evolusioner dapat dikontrol oleh kedua pihak. Model spiral mempunyai resiko yang harus dipertimbangkan ulang oleh konsumen dan developer.
  • Memerlukan tenaga ahli untuk memperkirakan resiko, dan harus mengandalkannya supaya sukses.
  • Belum terbukti apakah metode ini cukup efisien karena usianya yang relatif baru. 

Requirements engineering adalah fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. 

Untuk melakukan requirement engineering, dapat dilakukan dengan langkah-langkah requirement engineerings sebagai berikut :

1. Inception (Mendefinisikan ruang lingkup dan batasan masalah)
2. Elicitation (Kebutuhan customer, permasalahan)
3. Elaboration (informasi fungsional software) 
4. Negotitation (permulaan) 
5. Specification (hasil akhir dari kegiatan requirements engineering.)
6. Validation (memastikan bahwa developer mengerti permasalahannya dan customer memahami masalah dengan tepat.)
7. Management (memahami konsep)

Requirement modeling dalam rekayasa perangkat lunak pada dasarnya adalah tahap perencanaan aplikasi atau sistem perangkat lunak. Umumnya proses akan dimulai ketika bisnis atau entitas, misalnya lembaga pendidikan, mendekati tim pengembangan perangkat lunak untuk membuat aplikasi atau sistem dari awal atau memperbarui yang sudah ada. 

kelebihannya --> predicted, saya senang bermain dengan metode-metode ini karena pengumpulan data dari requirement ini dapat di oleh menggunakan statistika dan probabilitas dan menghasilkan output yang baik dan informasi yang baik

kekurangan --> collect data. ya memang benar collect data dan menyatukannya menjadi informasi itu sangat sulit

Berikut ini adalah pertanyaan yang dapat digunakan untuk melakukan validasi terhadap requirement yang telah dirancang:  
  • Apakah setiap requirement dapat dicapai dalam lingkungan teknikal dari sistem atau produk 
  • Apakah requirement dapat diuji ketika telah dikembangkan? 
  • Apakah requirement model secara layak merefleksikan informasi, fungsi dan behavior dari sistem yang akan dibuat? 
  • Sudahkah requirement dipartisi sehingga dapat menunjukan detail informasi secara progresif.  
  • Sudahkah pattern requirement digunakan untuk menyederhanakan model requirement. 
  • Apakah semua pattern secara layak divalidasi? 
  • Apakah pattern konsisten dengan kebutuhan customer? 


Software architecture adalah sebuah desain umum suatu proses pada sebuah software system, meliputi: 
  • Pembagaian software ke dalam subsistem
  • Memutuskan bagaimana saling berhubungan
  • Menentukan alat penghubung

Component-level design, atau juga dikenal dengan procedural design, baru ada setelah data, arsitektur dan rancangan antarmuka dibuat terlebih dahulu. Component-level design tujuannya adalah untuk menterjemahkan model design ke bentuk software yang akan dibuat. Namun dikarenakan abstraksi model design yang sudah ada relatif tinggi sedangkan abstraksi tingkat program operasionalnya rendah, maka proses penterjemahannya ini menjadi sebuah tantangan tersendiri. 

Komponen yang harus didesain adalah :
  • Notasi grafis : flowchart.
  • Notasi tabular : tabel.
  • Program Desain Language : pseudocode.

Design patterns
  • Menangani elemen tertentu dari desain seperti agregasi komponen atau memecahkan beberapa masalah desain, hubungan antar komponen, atau mekanisme untuk mempengaruhi komunikasi antar-komponen
  • Terdiri dari penciptaan, struktural, dan perilaku pola

Architectural patterns
  • Menentukan struktur keseluruhan perangkat lunak
  • Menunjukkan hubungan antara subsistem dan komponen software
  • Menentukan aturan untuk menentukan hubungan antara unsur-unsur perangkat lunak
Perbedaan dari WebApps Interface Design dan MobileApps Interface Design diantaranya:

- Ukuran pada layout masing2 sangat berbeda
- Cara penggunaan/User Experience pada keduanya sangat berbeda juga
untuk persamaannya yaitu:
- Sama sama dibuat untuk mempermudah dan mempercantik tampilan suatu aplikasi

Software Quality Metrics adalah sebuah pengukuran kuantitatif terhadap sesuatu yang dijadikan sebagai atribut dalam menentukan kualitas suatu perangkat lunak (Software).

Software quality dillema adalah kondisi dimana bila membuat software dengan biaya rendah, maka akan didapat hasil software dengan quality yang jelek, sedangkan bila membuat software dengan biaya tinggi, maka akan memakan waktu dan sulit untuk memasarkannya. Akan dari itu solusinya adalah dengan membuat software dengan kualitas "good enough".

Menurut David Garvin [Gar87] dimensi quality adalah:
  • Performance Quality
  • Feature quality
  • Reliability
  • Conformance
  • Durability
  • Serviceability
  • Aesthetics
  • Perception

Menurut saya berdasarkan bacaan yang baca dari suatu web, dimana dimensi yang paling utama harus dipenuhi dalam pengembangan software adalah Performance Quality. Mengapa saya memilih itu? Karena performance atau kinerja adalah dimensi kualitas yang berkaitan dengan karakteristik utama suatu produk. Contohnya sebuah televisi kinerja utama yang kita kehendaki adalah kualitas gambar yang dapat kita tonton dan kualitas suara yang dapat didengar dengan jelas dan baik.

Software testing adalah proses mengeksekusi program atau aplikasi dengan tujuan menemukan bug dari software tersebut.

Melakukan testing yang baik :
  • White Box/Glass Box - pengujian operasi
    basis path, loop testing , ataudata flow untuk memastikan bahwa setiap pernyataan dalam operasi telah diuji
  • Black Box - untuk menguji sistem
  • Use case - untuk membuat input dalamperancanganblack box dan pengujianstate-based

Software testing metrics  adalah indikasi kuantitatif tingkat, kapasitas, dimensi, jumlah atau ukuran beberapa atribut suatu proses atau produk.

Tipe Metrics

Metrics Proses: Dapat digunakan untuk meningkatkan efisiensi proses SDLC (Siklus Hidup Pengembangan Perangkat Lunak)

Metrics Produk: Ini berkaitan dengan kualitas produk perangkat lunak

Metrics Proyek: Dapat digunakan untuk mengukur efisiensi tim proyek atau alat pengujian apa pun yang digunakan oleh anggota tim

Metrics Tes Manual, Dalam Rekayasa Perangkat Lunak, metrik uji manual diklasifikasikan ke dalam dua kelas

Software configuration management adalah suatu proses untuk secara sistematis mengelola, mengatur, dan mengendalikan perubahan dalam dokumen, kode, dan entitas lainnya selama software development life cycle. Ini disingkat sebagai proses SCM dalam software. Tujuan utamanya adalah meningkatkan produktivitas dengan kesalahan minimal.

Change Management dan Configuration Management adalah bagian dari manajemen integrasi dan keduanya menangani semua perubahan yang dapat terjadi dalam proyek atau produk. Change Management berkaitan dengan perubahan yang terkait dengan rencana, proses, dan garis dasar, sementara Configuration Management berkaitan dengan perubahan yang terkait dengan ruang lingkup produk. Tugas manajer proyek adalah untuk meningkatkan permintaan ini dan memastikan bahwa mereka ditinjau dengan benar. Setelah keputusan dibuat, itu harus segera diimplementasikan.

SCM adalah sebuah elemen penting dari SQA Tanggung jawab utamanya adalah mengontrol perubahan.

SCM juga bertanggung jawab untuk :
  • mengidentifikasi individual SCI & berbagai versi perangkat lunak,
  • meng-audit software configuration untuk memastikan bahwa dia telah dikembangkan dengan benar, dan
  • melaporkan semua perubahan yang telah dilakukan pada konfigurasi tersebut.

Definisi 5 tugas (task) SCM :
  • identifikasi,
  • kontrol versi,
  • kontrol perubahan,
  • auditing konfigurasi, dan
  • pelaporan.

Software Configuration Items (SCI) adalah item-item yang terdiri dari semua informasi yang dihasilkan sebagai bagian dari proses perangkat lunak secara kolektif. SCI merupakan informasi yang diciptakan sebagai bagian dari proses rekayasa perangkat lunak. SCI berikut menjadi target bagi teknik-teknik CM dan membentuk sekumpulan baseline.

SCM Object untuk mengontrol & menangani SCI2, masing2 item harus diberi nama berbeda dan kemudian diorganisir dengan menggunakan metode berorientasi objek. Dua tipe objek dapat diidentifikasi: basic objects (obyek dasar) & aggregate objects (kumpulan obyek).

Metrik perangkat lunak mengacu pada suatu jangkauan luas pengukuran perangkat lunak computer. Pengukuran dapat diteraperangkat kerasan pada proses perangkat lunak guna mengembangkannya dengan dasar yang kontinu. Pengukuran dapat digunakan di seluruh proyek perangkat lunak untuk membantu perhitungan, control kualitas, perkiraan produktivitas, dan control proyek. Akhirnya, ppengukuran dapat digunakan oleh perekayasa perangkat lunak untuk membantu memperkirakan kualitas produk kerja teknis untuk membantu mengambil keputusan taktis pada saat proyek sudah berjalan.

PENGUKURAN, METRIK, DAN INDIKATOR

Measure = kuantitatif dari luasan, jumlah, dimensi, kapasitas, atau ukuran dari atribut sebuah proses atau produk.
Measurement = kegiatan menentukan sebuah measure (pengukuran).
Metrik = ukuran kuantitatif dari tingkat dimana sebuah system, komponen, atau proses memeiliki atribut tertentu.
Pengukuran terjadi sebagai hasil dari pengumpulan satu data atau lebih. Metric perangkat lunak menghubungkan pengukuran individu dengan banyak cara.
Rekayasa perangkat lunak mengumpulkan pengukuran dan mengembangkan metric sehingga diperoleh suatu indicator.
Indicator = sebuah metric atau kombinasi dari metric yanbg memberikan pengetahuan ke dalam proses perangkat lunak, sebuah proyek perangkat lunak atau produk itu sendiri.
Indicator memberikan pengetahuan yang memungkinkan manajer proyek atau perekayasa perangkat lunak menyesuaikan proses, proyek, dan produk untuk membuat semuanya menjadi lebih baik.

Design metrics adalah metrics yang digunakan untuk mengukur secara kuantitatif kualitas dari segi user interface dan user experience dari suatu software.

Menurut lecture note pekan 8 sesi 12, mula-mula kita harus menjawab pertanyaan berikut yang dapat dijadikan acuan dalam merancang metric untuk software berbasis web maupun desktop:

a. Apakah user interface yang ada mempromosikan kegunaan dari aplikasi?
b. Apakah unsur aestetik dari aplikasi layak untuk domain aplikasi dan menyenangkan user?
c. Apakah konten sudah dirancang dengan cara yang membagi sebagian besar informasi dengan usaha yang minim?
d. Apakah navigasi yang ada efisien dan langsung?
e. Apakah arsitektur dari aplikasi telah dirancang untuk mengakomodasi tujuan dari aplikasi.
f.Apakah komponen dirancang dalam cara yang mengurangi kompleksitasi procedural dan meningkatkan ketepatan, kepercayaan dan performance dari aplikasi?

SDLC adalah proses sistematis untuk membuat perangkat lunak yang memastikan kualitas dan kebenaran perangkat lunak yang dibangun. Ada beberapa tahapan SDLC, yaitu: 

Tahap 1: Requirement collection and analysis
Tahap 2: Feasibility study:
Tahap 3: Design:
Tahap 4: Coding:
Tahap 5: Testing:
Tahap 6: Installation/Deployment:
Tahap 7: Maintenance:

Earned Value Management (EVM) adalah teknik pengukuran kinerja proyek yang mengintegrasikan lingkup, waktu dan data biaya. Earned value management sering juga disebut earned value analysis (EVA). 

EVM juga menghitung 3 nilai untuk setiap tugas atau rangkuman tugas dari WBS proyek, yaitu:

1. The planned value (PV)
Sering disebut dengan budgeted cost of work schedule (BCWS) berisi tentang perkiraan biaya yang akan dihabiskan selama batas waktu yang diberikan.

2. The actual cost (AC)
Sering disebut dengan actual cost of work performed (ACWP) berisi dana total untuk menyelesaikan pekerjaan dalam jangka waktu yang diberikan.

3. The earned value (EV)
Sering disebut dengan budgeted cost of performed (BCWP) berisi persentase waktu penyelesaian proyek dikali dengan nilai yang
direncanakan.

1. Software Project Planning : adalah tugas yang dilakukan sebelum produksi perangkat lunak benar-benar dimulai. Itu ada untuk produksi perangkat lunak tetapi tidak melibatkan aktivitas konkret yang memiliki koneksi arah dengan produksi perangkat lunak, melainkan merupakan serangkaian proses ganda, yang memfasilitasi produksi perangkat lunak.

2. Software Project Schedulling : adalah suatu mekanisme untuk mengkomunikasikan tugas-tugas apa yang perlu dilakukan dan sumber daya organisasi mana yang akan dialokasikan untuk menyelesaikan tugas-tugas tersebut dalam kerangka waktu berapa lama. Jadwal proyek adalah dokumen yang mengumpulkan semua pekerjaan yang diperlukan untuk menyelesaikan proyek tepat waktu.


Model COCOMO ditetapkan untuk 3 kelas proyek PL dengan menggunakan terminologi Boehm :

Model organik :

Proyek PL sederhana dan relatif kecil dimana tim kecil dengan pengalaman aplikasi yg baik mengerjakan serangkaian kebutuhan yg lebih tidak tegar(misalnya program analisis termal yg dikembangkan untuk kelompok transfer panas).

Mode semi-detached :

Proyek PL menengah (dalam ukuran dan kompleksitas) dimana tim dengan pengalaman pada tingkat yg berbeda-beda harus memenuhi bauran yg kurang kuat dari syarat yg ketat (misalnya system pemrosesan transakasi dengan syarat tertentu untuk perangkat keras terminal dan perangkat lunak database).

Mode embedded :

Proyek PL yg harus dikembangkan ke dalam seangkaian perangkat keras, perangkat lunak dan batasan operasional yg ketat (seperti perangkat lunak kontrol penerbangan untuk pesawat udara).

RE adalah proses untuk membongkar bahan dan teknologi yang ada pada suatu benda. Orang bisa mereverse engineer aneka macam hal, misalnya resep masakan atau benda elektronik, atau program. Tentunya dalam konteks ini, yang dimaksud adalah software reverse engineering, yaitu proses bagaimana kita bisa mengetahui algoritma program (atau source codenya jika mungkin).

Reverse Engineering (RE) merupakan salah satu hal yang sangat penting dalam bidang security. Hal-hal lain juga banyak yang penting, misalnya keahlian networking, programming, crypto, forensic, dsb tapi RE menjadi dasar bagi banyak hal dalam bidang security terutama tingkat lanjut. Dalam berbagai security CTF, nilai untuk RE dan pwning sangat tinggi dibanding challenge lain.

RE kenapa perlu digunakan dalam suatu software?

RE untuk cracking program
RE untuk modifikasi program
RE untuk analisis security software komersial
RE untuk membuat exploit
RE untuk pentest
RE untuk analisis malware
RE untuk analisis protokol dan algoritma
Rekayasa Maju (Forward Engineering)

Proses tradisional perpindahan dari logika dan abstraksi tingkat tinggi, perancangan implementasi yang independen untuk implementasi fisik dari sistem. Foward engineering mengikuti urutan kebutuhan melalui perancangan implementasinya.

Rekayasa Mundur (Reverse Engineering)

Proses menganalisa suatu sistem untuk mengidentifikasi elemen-elemen sistem dan antar hubungannya berdasarkan sistem yang ada, serta untuk menciptakan dokumentasi dalam tingkat abstraksi yang lebih tinggi dari sekarang. Untuk mendapatkan gambaran proses pengembangan sistem dari awalnya. Tidak mengubah fungsionalitas sistem yang ada. Diterapkan untuk sistem yang tidak ada dokumentasinya.

Manajemen risiko dibuat guna untuk melindungi suatu perusahaan atau organisasi yang juga mencakup karyawan, properti, reputasi dan lainnya dari sebuah bahaya yang sewaktu – waktu dapat terjadi. Dapat kita ketahui bahwa tidak semua risiko dapat dihilangkan atau dihindari, oleh karena itu diperlukan tindakan – tindakan pencegahan atau tindakan untuk menghadapi risiko yang telah teridentifikasi tersebut. Dalam artikel ini akan dijelaskan beberapa langkah yang dapat dilakukan dalam proses manajemen risiko untuk membantu organisasi merancang dan mengimplementasikan rencana manajemen risiko yang efektif dan proaktif. Berikut adalah langkah – langkah yang dapat dilakukan, yaitu:

1. Risk Identification

Langkah pertama yang dilakukan adalah mengidentifikasi kemungkinan risiko yang dapat terjadi pada organisasi atau perusahaan. Ini bertujuan untuk mengetahui keadaan yang akan dihadapi oleh organisasi atau perusahaan tersebut dalam berbagai aspek seperti sosial, hukum, ekonomi, produk/jasa, pasar, dan teknologi yang ada. Risiko dari setiap aspek akan diklasifikasikan menurut kategorinya masing – masing agar mempermudah proses selanjutnya.

2. Risk Assessment

Setelah risiko telah diidentifikasi pada perusahaan atau organisasi tersebut, selanjutnya akan dinilai potensi keparahan kerugian dan kemungkinan terjadinya. Dalam hal ini, diperlukan kemampuan individu disetiap bidangnya untuk memberikan penilaian terhadap risiko – risiko yang telah diidentifikasi. Tujuannya adalah agar setiap risiko berada pada prioritas yang tepat.

3. Risk Response

Proses ini dilakukan untuk memilih dan menerapkan langkah – langkah pengelolaan risiko. Tantangan bagi manajer risiko adalah untuk menentukan portofolio yang tepat untuk membentuk sebuah strategi yang terintegrasi sehingga risiko dapat dihadapi dengan baik. Tanggapan risiko umumnya terbagi dalam kategori seperti berikut:
Risk Avoidance, Mengambil tindakan untuk menghentikan kegiatan yang dapat menyebabkan risiko terjadi
Risk Reduction, Mengambil tindakan untuk mengurangi kemungkinan atau dampak atau keduanya, biasanya melalui pengandalian di bagian internal perusahaan/organisasi
Risk Sharing or Transfer, Mengambil tindakan untuk mentransfer beberapa risiko melalui asuransi, outsourcing atau hedging.
Risk Acceptence, Tidak mengambil tindakan apapun untuk menganggulangi risiko, melainkan menerima risiko tersebut terjadi.
Create a Risk Management Plan
Membuat penanggulangan risiko yang tepat untuk setiap masing – masing kategori risiko. Mitigasi perlu mendapat persetujuan oleh level manajemen
yang sesuai, berikut adalah contoh tabel manajemen risiko:

4. Implementation

Melaksanakan seluruh metode yang telah direncanakan untuk mengurangi atau menanggulangi pengaruh dari setiap risiko yang ada.

5. Evaluate and Review

Perencanaan yang telah direncanakan di awal tidak akan seluruhnya dapat berjalan dengan lancar. Perubahan keadaan atau lingkungan yang tidak diprediksi sebelumnya akan menyebabkan perubahan rencana manajemen risiko yang telah dibuat, oleh karena itu perlu dilakukan perubahan rencana untuk menanggulangi risiko yang akan mungkin terjadi.

Reactive Risk Management

Pada umumnya perusahaan menangani resiko proyek secara reactive, dan secara proaktif. Untuk perusahaan yang reactive ,
Tim akan bereaksi jika permasalahan terjadi
Antisipasi pengurangan material, untuk mengurangi kerugian pada saat kemungkinan terburuk terjadi
Perbaikan tepat guna, resources digunakan hanya jika kerusakan terjadi
Manajemen krisis, jika kerusakan tak bias ditanggulangi/ proyek dalam keadaaan bahaya
Proactive Risk Management

Tiap manajer akan selalu memikirkan pertanyaan seperti : Kerusakan apa yang akan terjadi?Kemungkinan terburuk kira-kira apa ya?Apa yang dapat saya lakukan untuk mengantisipasinya?

Analisis resmi dilakukan sebelum pengerjaan
Menangani akar masalah dari kerugian/resiko
TQM concepts and statistical SQA
Mempersiapkan kemampuan-kemampuan tertentu untuk mengantisipasi perubahan perusahaan
Untuk managemen resiko ada beberapa tahapan dan metode .Dan metode yang kita gunakan dalam bahasn kali ini adalah metode dari R.S. Pressman & Associates, Inc. book.












Top