analisis mg resiko

5/11/2018 Analisis Mg resiko - slidepdf.com

http://slidepdf.com/reader/full/analisis-mg-resiko 1/19

e

Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: StudiKasus Optimasi Organisasi dan Dokumentasi pada Organisasi PengembangPerangkat Lunak(Thomas Suselo)

Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: Studi Kasus Optimasi Organisasi dan Dokumentasipada Organisasi Pengembang Perangkat Lunak

Thomas SuseloProgram Studi Teknik Informatika, Fakultas Teknologi Industri, Universitas Atma Jaya Yogyakarta Jl.

Babarsari no 43 YogyakartaE-mail: [email protected]

Abstract

Software developments often have many risks, such as developmentfailures, cost-overruns,and schedule overruns.Those factors have to be minimize using riskmanagement, and oneof risk management methods is Just-In-Time (JIT). The concept of JIT ismanaging costs,schedules and software functionalities. JIT talks about risk quality of those factors, andusualy people have difficulty to fix or minimize risks by thinking thequality area. ThenKarolak (1999) was developed Software Engineering Risk Model (SERIM)based on JITmethod to analyze riks and give quantity results. SERIM uses risk metricsthat contains

many question to be answered by management and then solvesproblems by makingconclution of resultsSERIM and JIT are used in this analysis to give conclusions on simulationcase. The case is about software developer that have internal organizationsand software documentations problems, and these problems usualy makecost-overruns and schedule-overruns. Target of analysis are getting risk quantity, making conclusions about howto minimize risk by using risk management.

Keywords: Software Developer, Risk Management, Just-In-Time, SERIM

1. Pendahuluan

Tidak sedikit pengembang perangkat lunak yang mengalami kendala cost-overruns,schedule-overruns dan seringkali mereka memandang penyebab kendala tersebut hanya dari

segi metodologi pengembangan perangkat lunak, bukan dari sisi keutuhan pengembangansistem (wholism) pada organisasi. Sisi wholism yaitu jika memandang organisasi, estimasi,monitoring, metodologi, tools, budaya organisasi, usability, kecermatan organisasi, reabilitas

dan anggota organisasi tersebut. Sehingga pengembang perangkat lunak perlu menyadari,menyelidiki kendala dan kegagalan tersebut secara lebih detil, sehingga nantinya akan dikelola dan

dimimasi dari setiap resiko yang ada.Resiko meskipun sangat kecil pasti selalu ada, sehingga tidak dapat dihilangkan begitu

saja. Oleh sebab itu agar resiko tidak berkembang, resiko dapat diatur supaya berada dalamtingkatan yang terkendali sehingga pengembangan perangkat lunak, mencakup aktivitasnya

dapat mencapai tingkat keberhasilan yang diinginkan. Oleh sebab itulah pengembang perangkatlunak perlu melakukan manajemen resiko.

Salah satu pendekatan manajemen resiko adalah Just-in-Time (JIT) dengan menggunakanSoftware Engineering Risk Model (SERIM). Pendekatan tersebut dikembangkan sebagai



upayauntuk mengatasi berbagai kegagalan pada pembangunan perangkat lunak. Filosofi JIT bertumpu pada fungsionalitas, biaya dan waktu (jadual) dan konsep JIT berdasarkan pada identifikasi dan

antisipasi resiko secara proaktif. Analisis pada kendala, kegagalan dan resiko pengembangan

121



Jurnal Teknologi Industri Vol. XI No. 2 April 2007:121 - 132

perangkat lunak bukan lagi dipandang pada akibat pemilihan pendekatan metoda, melainkan

karena kurangnya pengetahuan pada pola-pola pengembangan yang lebih rasional, kuantitatif,sistematik, dan memiliki dokumentasi yang lebih formal.

Simulasi kasus yang akan dianalisa adalah suatu organisasi pengembangan perangkatlunak yang memiliki sumber daya yang baik namun lemah dalam hal koordinasi dan merekatidak memiliki standar penulisan dokumentasi pada pengembangan perangkat lunaknya sertadokumentasi untuk user. Untuk menjelaskan manajemen resiko JIT dengan menggunakan

pendekatan SERIM, dilakukan simulasi kasus tersebut. Studi kasus dilakukan denganmelakukan simulasi kalkulasi probabilitas SERIM, yang diimplementasikan secara sederhana pada piranti lunak aplikasi spreadsheet SERIM

2. Tujuan dan Hasil PenelitianAdapun tujuan dari melakukan analisis pada simulasi organisasi pengembang perangkat

lunak ini adalah :

a. Mengukur peran faktor-faktor resiko dalam kasus organisasi pengembang perangkat lunak melalui simulasi SERIM.

b. Membandingkan simulasi tahap awal dan minimasi resiko, yaitu berdasarkan hasil bobot

simulasi SERIM pertama (bobot Total Product Risk , Risk Elements , RiskFactors, dan

Development ) dijadikan dasar kesimpulan awal manajemen resiko yang kemudian

dibandingkan dengan simulasi SERIM dengan perbaikan beberapa faktor untuk memimasiresiko.

c. Menyusun rekomendasi bagi organisasi pengembang perangkat lunak dari hasil pembandingan tersebut untuk kemudian dapat dijadikan kesimpulan.

3. Manajemen Resiko Perangkat Lunak dan Pendekatan Just-In-Timea. Manajemen Resiko

Manajemen resiko perangkat lunak adalah pengelolaan dan minimasi kegagalan yangmencakup aspek fungsionalitas, cost overruns , dan schedule overruns pada pengembangan perangkat lunak (Karolak, 1999). Tiga area pokok dari resiko pengembangan

perangkat lunak tersebut dijabarkan sebagai berikut:1) Tidak adanya kejelasan akan kebutuhan perangkat lunak sehingga mengakibatkan

ketidaktepatan fungsionalitas yang dikembangkan.2) Ketidakpahaman dalam estimasi biaya yang akan digunakan dalam mengembangkan

perangkat lunak sehingga mengakibatkan biaya berlebihan3) Ketidakmampuan dalam mengukur kinerja tim pengembang perangkat lunak dalam

menyelesaikan pekerjaannya dan besarnya fungionalitas sehingga mengakibatkan

pemuluran jadual pengembangan perangkat lunak tersebut.

Kegiatan yang dilakukan dalam manajemen resiko (Karolak, 1999) adalah :

1) Risk Identification, yaitu melakukan identifikasi gejala resiko yang terjadi.2) Risk Strategy, yaitu merancang suatu tahapan langkah untuk menanggulangi resiko.3) Risk Assessment, yaitu mengukur akibat yang akan disebabkan resiko.

4) Risk Mitigation, yaitu melakukan mitigasi dari hasil penilaian resiko.

5) Risk Reporting, yaitu membuat penulisan terhadap seluruh kegiatan manajemen resikosehingga dapat digunakan sebagai dasar analisis manajemen resiko berikutnya.

6) Risk Prediction, yaitu membuat perkiraan akan resiko yang akan terjadi berikutnya dalam pengembangan perangkat lunak.



Gambar 1. Aktivitas Manajemen Resiko JIT Perangkat Lunak (Karolak, 1999)

Pada penelitian ini yang akan dikaji adalah seberapa besar kuantitas resiko pada kasusorganisasi pengembang perangkat lunak yang :

1) Tidak membuat dokumentasi pembangunan perangkat lunak (dokumen Spesifikasi

Kebutuhan Perangkat Lunak/ SKPL), dokumentasi user-manual, dan penetapandokumentasi tersebut menjadi standar dalam melakukan pengembangan perangkat lunak.

2) Manajemen organisasi tidak dapat mengkomunikasikan anggota pengembang dengan baik sehingga setiap anggota cenderung berjalan sendiri-sendiri.

Kuantitas resiko tersebut haruslah diminimasi dengan menggunakan manajemen resiko.Pendekatan yang dilakukan terhadap manajemen resiko kasus ini adalah Just-In-Time (JIT)dengan tools Software Engineering Risk Model (SERIM).

b. Pendekatan Just-In-Time (JIT)Konsep JIT pada pengembangan perangkat lunak, filosofinya bertumpu pada

fungsionalitas, biaya dan waktu (jadual). Manajemen organisasi perangkat lunak kadangkalimemandang proses pengembangan perangkat lunak sebagai proses yang sangat tidak dapatdigambarkan (abstrak), sehingga tidak didapatkan pengukuran fungsionalitas yang dibutuhkan.Tahap awal inilah yang memicu cost-overruns dan schedule-overruns. JIT pada pengembangan perangkat lunak merupakan pendekatan yang dilakukan oleh pihak manajemen

organisasi yang bersifat risk-driven, dimana konsepnya adalah sebagai berikut:1) Antisipasi dan minimasi resiko dalam pengembangan perangkat lunak.

2) Menangani resiko sejak dini dalam pengembangan perangkat lunak sehingga mengurangi

waktu siklus proses, yang akan berimbas pada pengurangan biaya, pemenuhan jadual, dankesesuaian fungsionalitas.

Dalam hal melakukan manajemen resiko perlu untuk memahami dan mengakomodasisemua perspektif sebagai berikut dan perspektif tersebut akan dijadikan dasar untuk melakukan

kegiatan manajemen resiko, yang telah diuraikan pada pembahasan mengenai pengertianmanajemen resiko:1) Operasional: berkaitan dengan ketidakpastian dalam kegiatan rutin-harian.

2) Strategis: berkaitan dengan dampak jangka panjang bagi organisasi / perusahaan.3) Teknis: berkaitan dengan penggunaan teknologi perangkat lunak.4) Bisnis: berkaitan dengan proyek-proyek yang dilakukan organisasi / perusahaan dalam

berbagai bentuk komersialitasnya.5) Industri: berkaitan dengan model dan proses pengembangan perangkat lunak yang

berbasiskan industri (definitif, terkuantifikasi, sistematik).6) Praktisi: berkaitan dengan implementasi dan praktik-praktik pengembangan perangkat lunak

123




4. Analisis Menggunakan Software Engineering Risk Model (SERIM)

a. Dasar Analisis

Karolak (1999) meneliti suatu model yang dapat digunakan sebagai acuan manajemenresiko dengan pendekatan JIT yang disebut sebagai Software Engineering Risk Model(SERIM).Model tersebut merupakan model probabilitas yang mengakomodasikan elemen-elemen berikut:

1) Technical Risk terdiri atas aspek-aspek functionality, quality, reability, usability,timelines,

maintainability, reusability.2) Cost Risk, terdiri atas aspek-aspek budget, nonrecurring cost, recurring cost,fixed cost,

variable cost.3) Schedule Risk, terdiri atas aspek-aspek flexibility, Meeting Established Milestones, Realism.

Pada SERIM, aspek-aspek pada tiap elemen diatas diterjemahkan menjadi 10 faktor

resiko sebagai berikut:1) Organization 6) Risk Culture2) Estimation 7) Usability3) Monitoring 8) Correctness4) Development methodology 9) Reliability5) Tools 10) Personel

Faktor resiko inilah yang kemudian diukur dalam risk metrics yang diformulasikan kedalam 81 pertanyaan (gambar 2). Risk Metrics pada SERIM menggunakan konsep pohon probabilitas yang menunjukkan muatan resiko sebagai rujukan untuk antisipasi atapun pengembangan produk perangkat lunak, atau bahkan kinerja organisasi tersebut. Alur kalkulasirentang nilai pada pohon probabilitas mencerminkan formulasi faktor resiko yang dihadapiorganisasi (tertuang dalam 81 pertanyaan).

Masing-masing pertanyaan dalam risk metrics dijawab (secara self-assessment)

dengan nilai rentang 0-1, hal tersebut bertujuan untuk membangun satuan probabilitas pengembangan proses. Satuan probabilitas kemudian dikelompokkan menurut aktivitas

manajemen resiko, tahapan pengembangan, dan faktor resiko. Faktor resiko kemudiandikelompokkan berdasarkan elemen-elemen resiko untuk kemudian dipadukan sehingga

menghasilkan total resiko pengembangan perangkat lunak.

b. Penerapan SERIM pada Studi Kasus Organisasi Pengembang Perangkat LunakSebenarnya untu mengukur tingkat resiko dalam suatu organisasi dengan menggunakan

SERIM sangatlah mudah, langkah penerapan SERIM adalah sebagai berikut :

o Menentukan organisasi pengembang perangkat lunak untuk analisis manajemen resiko danmendeskripsikan karakteristik umum organisasi berdasarkan 10 faktor-faktor resiko, yangkemudian menjadi dasar untuk simulasi awal.

o Menjawab 81 pertanyaan dalam simulasi risk metrics disesuaikan dengan

karakteristik berdasarkan faktor resiko tersebut.

o Melihat keluaran dari perhitungan risk metrics. Dari hasil keluaran tersbut dapatditarik

kesimpulan mengenai tingkat resiko yang ada di dalam organisasi.

1) Menentukan Organisasi dan Mendeskripsikan Karakteristik UmumOrganisasi yang dijadikan simulasi adalah organisasi pengembang perangkat lunak

dengan memiliki prosedur pengembangan perangkat lunak yang baik, namun buruk dalam hal

dokumentasi yaitu pembuatan Spesifikasi Kebutuhan Perangkat Lunak (SKPL) yang termasuk ke dalam faktor development methodology, dan dokumentasi kelengkapan produk

(usermanual). Untuk karakteristik lainnya dapat dilihat di dalam tabel 1.Deskripsi singkat organisasi tersebut sebagai berikut :



124




Tabel 1. Karakteristik Organisasi Pengembang Perangkat Lunak

FAKTOR KARAKTERISTIK OrganizationSumber daya manusia kompeten dalam bidangnya (ahli).

Pembagian kerja dilakukan secara terperinci dan baik.

Koordinasi dan komunikasi dalam pengembangan tidak dilakukan dengan baik, sehingga pengembangan cenderung berjalan sendiri-sendiri.Produk yang dihasilkan hanya berdasarkan permintaan user.

Estimation Estimasi dilakukan berdasarkan banyaknya fungsionalitas perangkat lunak

yang akan dikembangkan.

Pelakuan estimasi tidak memiliki prosedur standar, dan hasil estimasi tidak didokumentasikan sehingga untuk kasus yang sama terkadang memiliki hasilestimasi yang berbeda.

Monitoring Monitoring dilakukan kepada masing-masing anggota pengembang oleh

manajemen dan dilakukan secara baik.Komunikasi oleh pihak manajemen tidak dilakukan dengan baik untuk koordinasi setiap anggota pengembang, sehingga tercipta silo mentality(pengembangan cenderung berjalan sendiri-sendiri).

Development Metodologi pengembangan telah diterapkan dengan baik .Methodology Pengembangan perangkat lunakstandar tetapi tidak ada

dokumentasi pengembangan (SKPL)

Keterlibatan user dalam pengembangan perangkat lunak dilakukan hanyasesekali.

Tools Penggunaan tools dalam pengembangan telah banyak digunakan dan

diseuaikan dengan standar dan kebutuhan.

Setiap tools yang digunakan telah dikuasai oleh setiap anggota pengembang,sehingga secara optimal dapat digunakan.

Risk Culture Konsep manajemen resiko belum diterapkan di dalam organisasi.

Usability Usability perangkat lunak telah cukup baik dikembangkan berdasarkanmetodologi yang digunakan.Belum adanya dokumentasi untuk user (user manual) karena dianggap

perangkat lunak dibuat sesuai permintaan user, sehingga user mampu

menggunakannya.

Correctness Spesifikasi perangkat lunak dibuat dengan kurang baik karena seringkali

kebutuhan user berubah-ubah.

Pelacakan error pada suatu fungsi dapat dilakukan dengan baik dan cepat.

Reliability Keandalan perangkat lunak dilakukan oleh tim penguji dan user secara trial-error.

Tidak adanya pengujian desain pengembangan perangkat lunak

Personel Pelaksana pengembangan perangkat lunak adalah tim yang handal sesuaidengan bidangnya.

Diharapkan dengan pengukuran menggunakan SERIM didapatkan gambaran pengaruh dari

kurang baiknya dokumentasi dan estimasi terhadap pengembangan perangkat lunak.Kemudian dari hasil tersebut dibuat suatu pengukuran modifikasi, yang merupakan perbaikan dari

dokumentasi dan estimasi (dengan menaikkan nilai setiap elemen faktor resiko pada riskmetrics) lalu dibandingkan untuk didapatkan kesimpulan.

125




2) Menjawab Pertanyaan pada Risk MetricsFormulasi pertanyaan berikut ini dijawab sesuai dengan karakteristik pada organisasi

pengembang perangkat lunak yang telah dipaparkan pada bab sebelumnya (terpaparkan pada

tabel 1). Tabel 2 berikut ini menunjukkan penilaian rentang 0, 0.5 dan 1 atas pertanyaan riskmetrics untuk memberikan pembobotan (score) yang disesuaikan lingkungan awal organisasi

sehingga nantinya didapat nilai probabilitas resiko.

Tabel 2. Software Risk Metrics Model (Karolak, 1999)

ANSWERgive "1" for one of theseoption (0.0 =changing,

NO QUESTION compromising, least; 0.5 =mixed; 1.0 = fixed, complete) SCOREotherwise follow the valued-

choices given

0.0 0.5 1.0

O1 Are You using or do You plan to use experiencedsoftware managers?

1 1

O2 Has Your company been producing software similar tothis in the past?

1 1

O3Is there a documented organizationalstructure either in place or planned?

1 0,5

O4 Is the organizational structure stable? 1 0,5

O5 What is the confidence level of Your managementteam? 1 0,5

Does good communication exist between different

O6 organizations supporting the development of the 1 0

software project?

O7 Are software configuration managementfunctions being performed?

1 0

O8 Are software quality functions being performed? 1 0,5

a) Guess =0.2

b) Analogy =0.6c) Price to Win =0.3

d) Dictated by =0.3E1 What estimation method is used? Circumstances 0,7

e) Top-Down =0.5

f) Bottom-Up =0.7

g) Other =0.4

E2 Is a software cost model used? 1 0

E3 Is the estimation based on past softwareproductivity metrics? 1 0,5

E4 Are the schedule estimates based on past softwareprojects?

1 0,5

E5 Are estimates revised on a monthly or more frequentbasis? 1 0,5

E6

E7

M1

How accurate are Your past cost estimates comparedto actual costs?

How accurate are Your past schedule estimatescompared to actual schedules?

For each major software effort, are there distinctmilestones set for each software development phase?

1 0,5

1 0,5

1 0,5

Is a detailed Work Breakdown Structure (WBS) used toM2 track and report cost and budget for each piece of 1 0,5

major software development?

M3 Is there a monitoring system setup for cost,schedule,

anval



1 0

126




RF NO QUESTION 0 0,5 1 SCORE

M4 Are cost, schedule, and earned-value reports available 10on demand?

M5 Are cost, schedule and earned-valuereports updated on a monthly or morefrequent basis?

1 0

M6 Is there a problem log or action log system?Is it used and updated on a weekly basis?

1 0,5

M7Does a means exist to address and recordtechnicalproblems? Is it used and updated on aweekly basis?

1 0,5

Is there a documented software developmentDM1 methodology or plan used for the project, and is it 10

being adhered to closely?

DM2Are the software developers trained in the developmentmethodology?

1 1

DM3 How closely is the development methodologyfollowed?

1 0,5

Does the development methodology includeDM4 requirements, design, and code 1 0

reviews/walkthroughs/inspections?

DM5Does the development methodologyrequire test plans and or test proceduresfor all software functions?

1 0,5

Does the development methodology requireDM6 documentation such as requirements, design, and 10

software development folders?

DM7 Is regression testing performed? 1 0,5

T1 Are the software developers trained in using the tools? 1 1

T2 Are automated tools used for software design? 1 1

T3 Are automated tools used for testing? 1 0,5

T4 Are automated tools used for test proceduregeneration?

1 0,5

T5 Are automated tools used for regression testing? 1 0,5

T6 Are automated tools used for requirementstraceability?

1 0,5

Are automated tools used for re-engineering

T7 (identifying existing characteristics of the softwarebased on its code, such as its structure, data

dictionary, and so forth)?

1 0,5

T8 How stable is Your compiler/linker/debugger? 1 1

T9 Are tools readily available to the softwaredevelopment personnel when needed?

1 1

RC1Is Your company willing to tradeadditional budget risk for additionalprofit?

1 0,5

RC2Is Your company willing to trade additionalschedule risk for additional profit?

1 0,5

RC3 Is Your company willing to trade additionaltechnical risk for additional profit?

1 0,5

RC4 Is Your company willing to trade lessbudget risk for less profit?

1 0,5



RC5

RC6

Is Your company willing to trade less schedulerisk forless profit?

Is Your company willing to trade lesstechnical functionality for less profit?

1 0

1 0,5

RC7 Is Your company market-driven? 1 0,5

127





RC8 Is Your company culture conservative in itsdecision-

making?

1 0,5

RC9 How does Your company's investment innew products and technology rate?

1 0,5

RC10 Does Your company tend to build or toacquire new products and/or technology?

1 0,5

RC11 Does Your company practice risk management? 1 0

U1 Is there a user manual for the software? 1 0

U2 Are there help functions for each inputor outputscreen?

1 0

U3 Is the user involved in reviewing prototypesor earlier versions of the software?

1 0,5

U4 Is the user interface designed to anindustry standard or to a standard familiarto the user?

1 0,5

U5 Have user response times been identified? 1 0,5

U6 Has the design been evaluated to minimizekeystrokes and data entry?

1 0,5

C1Have all the software requirements beenidentified and documented?

1 0

C2 Have the software requirements been traced to thedesign?

1 0,5

C3 Are the software requirements traceable to the code? 1 1

C4 Are the software requirements traceableto the test procedures?

1 0,5

C5 Have there been, or are there expectedto be, many changes made in therequirements?

1 0,5

C6 Are the software designs traceable to the code? 1 1

C7 Is the software design traceable to the testprocedures?

1 0,5

C8Have all the open action items beenaddressed and implemented prior todelivery to the customer?

1 0,5

C9Has software functional testing beenperformed prior to customer delivery?

1 0,5

R1Are there error handling conditionswithin the software design and code?

1 0

R2 When an error condition is detected, doesprocessing continue?

1 0,5

R3 Are error tolerances defined for input and outputdata? 1 0,5

R4 Are inputs checked for valid values beforeprocessingbegins?

1 0,5

R5 Are hardware faults detected and processed in thesoftware?

1 0,5

R6 Is the use of global data types minimized? 1 0,5

R7 Is defect data collected during software integration? 1 0,5



R8Is defect data being logged-in and closed-out prior to delivery to the customer?

1 0,5

R9 Is a software reliability model usedto predict reliability?

1 0

R10 Are tests performed with test plans? 1 0,5

R11 Has stress testing been performed? 1 0,5

Is testing performed by a group separate from theR12 software development group? 1 0

128





P1 Are personnel resources available and identified? 1 1

P2 How experienced are the personnel resources in theproduct type being developed?

1 1

P3 How experienced are the personnel resources in thedevelopment environment?

1 1

P4How experienced are the personnel resources in theimplementation language?

1 1

P5How large will the number of software developmentpersonnel be at peak?

1 1

3) Hasil Output SERIMJawaban pembobotan pada tabel 2 kemudian dikalkulasikan dengan mengunakan

spreadsheet SERIM untuk mendapatkan nilai probabilitas. Hasilnya adalah sebagai berikut :

Total Product Risk Software Project Risk P(A) 0,52

Technical Cost

P(A1 ) 0,51 P(A2 ) 0,52

Risk Elements

Schedule

P(A3 ) 0,52

Risk Factors Organization Estimation Monitoring

P(A4 ) P(A5 ) P(A6 )

0,50 0,46 0,29

DevelopmentMethodology

P(A7 )

0,36

Tools

P(A8 )

0,72

Risk Culture Usability Correctness Reliability Personnel

P(A9 ) P(A10) P(A11) P(A12) P(A13)

0,45 0,33 0,56 0,38 1,00

Development Phases Pre-Requirements RequirementsDesign

P(B) P(C) P(D)

0,54 0,41 0,45

Code Test

P(E) P(F)

0,47 0,44

Development &Maintenance

P(G)

0,44

Software Risk Management Activities

Identification

Strategy &

Planning

Assessment

Mitigation &Avoidance

Reporting

Prediction

P(H) 0,49

P(I) 0,43

P(J) 0,49

P(K) 0,46

P(L) 0,29

P(M) 0,49

129




Hasil dari penghitungan probabilitas menggunakan spreadsheet SERIM menunjukkan ada 6

faktor yang beresiko tinggi, yaitu :a. Total resiko pada organisasi pengembangan perangkat lunak tersebut adalah 0.52, ini

menunjukkan bahwa 48% resiko dalam pengembangan perangkat lunak masih terjadi padaorganisasi tersebut

b. Nilai faktor resiko yang paling terlihat adalah Monitoring, yaitu sebesar 0.29, inimembuktikan pernyataan awal pada tabel 2 bahwa komunikasi pada masing-masinganggota tidak terjalin dengan baik sehingga apabila tidak diperbaiki akan menimbulkan silomentality akan menyebabkan 71% resiko pada faktor monitoring dan berdampak

pada faktor lainnya.

c. Development methodology akan menyebabkan 63% resiko pada pengembanganapabila

tidak digunakan dokumentasi standar seperti SKPL.d. Tidak adanya user manual akan menyebabkan kenaikan resiko usability sebesar 77%, tentu

bisa menyebabkan preseden buruk pada relasi dengan user.

e. Tanpa adanya dokumentasi pembangunan perangkat lunak (SKPL) tentu akan berdampak

pada tidak adanya pengujian pada desain perangkat lunak, dan hal ini menyebabkan 62%resiko pada faktor pengujian perangkat lunak.

f. Dari semua kendala tersebut menyebabkan 71% kendala bertumpu pada dokumentasi padaaktivitas pengembangan perangkat lunak.

Faktor-faktor resiko tersebut mempengaruhi 49% kendala pada faktor resiko technical(memicu kegagalan produk), 48% faktor cost (memperbanyak biaya/ cost-overruns) dan

48%faktor schedule (memperlama waktu pengerjaan perangkat lunak/ schedule-overruns).

5. Analisis PerbandinganDari hasil output sebelumnya maka telah didapatkan kesimpulan awal berupa prosentase

kelemahan/ kendala pada organisasi pengembangan perangkat lunak tersebut. Pada langkah inikelemahan dan kendala tersebut akan dimimasi dengan memberikan masukan untuk orgasnisasi

tesebut agar melakukan perbaikan sebagai berikut:

Tabel 3. Perbaikan pada Karakteristik Organisasi Pengembang Perangkat Lunak

FAKTOR KARAKTERISTIK Organization Melakukan koordinasi dan komunikasi pada seluruh anggota dengan baik

(O6).

Manajemen konfigurasi produk perangkat lunak mulai diterapkan (O7).

Monitoring Menerapkan monitoring penjadualan dan koordinasi (M3).

Mulai menerapkan pelaporan-pelaporan yang berfungsi sebagai komunikasidan koordinasi (M4).

Development Membuat SKPL sebagai standar dokumentasi pengembangan perangkat

Methodology lunak yang lengkap dan baik (DM1,4,6)Usability Membuat user manual yang lengkap dan baik (U1).

Membuat help function dengan baik dan lengkap sehingga membantu userdalam menghadapi masalah (U2).

Correctness Membuat dokumentasi untuk kebutuhan perangkat lunak dan dijadikan

standar dokumentasi organisasi (C1).

Tabel karakteristik tersebut diatas kemudian dimasukkan ke dalam risk metrics dengan

bobot 1, sehingga akan didapatkan hasil keluarannya adalah sebagai berikut :

130




Total Product Risk Software Project Risk P(A) 0,67

Technical Cost

P(A1 ) 0,66 P(A2 ) 0,68

Risk Elements

Schedule

P(A3 ) 0,68

Risk Factors Organization Estimation Monitoring

P(A4 ) P(A5 ) P(A6 )

0,75 0,46 0,57

DevelopmentMethodology

P(A7 )

0,79

Tools

P(A8 )

0,72

Risk Culture Usability Correctness Reliability Personnel

P(A9 ) P(A10) P(A11) P(A12) P(A13)

0,55 0,67 0,67 0,38 1,00

Development Phases Pre-Requirements RequirementsDesign

P(B) P(C) P(D)

0,68 0,65 0,63

Code Test

P(E) P(F)

0,65 0,68

Development &Maintenance

P(G)

0,65

Software Risk Management Activities

Identification

Strategy &

Planning

Assessment

Mitigation &Avoidance

Reporting

Prediction

P(H) 0,63

P(I) 0,60-

P(J) 0,53

P(K) 0,68

P(L) 0,57

P(M) 0,63

Hasil output dengan memasukkan bobot untuk perbaikan majemen organisasi, pembuatandokumentasi sesuai yang dipaparkan pada tabel 3 ternyata dapat ditarik kesimpulan:

a. Meminimasi resiko pengembangan perangkat lunak (total product risk)secara keseluruhan

sebesar 15%. b. Komunikasi dan koordinasi jika dilakukan oleh manajemen organisasi akan mengurangi

resiko sebesar 25%. Pelaporan-pelaporan yang baik mengenai komunikasi, koordinasi dan

dibuatnya standar kemajuan anggota akan mengurangi resiko sebesar 28%.c. Pembuatan SKPL yang lengkap dan baik akan sangat mengurangi resiko pengembangan

perangkat lunak sebesar 43% (Development Methodology) dan apabila ditetapkanmenjadi

aturan standar perusahaan maka akan mengurangi resiko sebesar 11% (correctness).d. Apabila dibuat user-manual dan fungsionalitas help yang baik dan lengkap maka akan

mengurangi resiko usability sebesar 34%.Faktor-faktor resiko tersebut akan meningkatkan produktivitas secara teknis sebesar 15%,

mengurangi resiko biaya yang berlebih (cost-overruns) sebesar 16%, dan mengurangi resiko

waktu kerja berlebih (schedule-overruns) sebesar 16%. Apabila organisasi pengembang perangkat lunak dapat meningkatkan faktor reabilitas dan mampu membuat estimasi produk



131




dengan lebih baik maka akan secara langsung mengurangi resiko yang dapat ditimbulkan dalam

pengembangan perangkat lunak.Dengan demikian dapat ditarik kesimpulan bahwa dengan adanya perbaikan dalam

manajemen organisasi, khususnya memperbaiki komunikasi dan koordinasi, serta membuat danmenetapkan standar dokumentasi, baik SKPL, user-manual, maka dapat mengurangi resikodalam pengembangan perangkat lunak.

5. KesimpulanDari hasil penelitian didapat kesimpulan sebagai berikut :

a. Dengan menggunakan Software Engineering Risk Model (SERIM) maka dapat

menunjukkan hasil secara kuantitatif resiko pengembangan perangkat lunak pada suatuorganisasi.

b. Manajemen resiko dengan pendekatan Just-In-Time dapat diterapkan pada organisasi pengembangan perangkat lunak untuk memperbaiki dan meminimasi kendala ataupun

kegagalan yang mungkin akan atau sudah terjadi.

c. Dengan perbaikan manajemen organisasi, khususnya memperbaiki komunikasi dan

koordinasi, serta membuat dan menetapkan standar dokumentasi, baik SKPL, user-manual,maka dapat mengurangi resiko dalam pengembangan perangkat lunak, terutama yang berkaitan dengan fungionalitas, cost-overruns, schedule-overruns.

Daftar Pustaka

Boehm, B, 2001, Software Risk Management Practices, University of Southern

California, USA Humphrey, W., 1989, Managing the Software Process, Addison-Wesley/SEI series in Software

Engineering Reading.Karolak, Walter D., 1999, Software Engineering Risk Management, Computer Society Press.

NN, 1998, Best Practices for Software Development Teams, Rational Unified

ProcessWhitepaper Rational Software.

NN, 2005, Diktat Kuliah IS7075 Manajemen Resiko; Program Magister SistemInformasi

Departemen Teknik Informatika, Institut Teknologi Bandung.Pressman, R.S., 2001, Software Engineering: A Practitioner's Approach, Pressman Inc.Pryor, L. 2002, Managing the operational risks of user-developed software, Workshop

Presentation at GIRO, www.louisepryor.com.

132

http://www.louisepryor.com./



analisis mg resiko

Documents