Download - 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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 2/19
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 3/19
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.
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 4/19
Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: StudiKasus Optimasi Organisasi dan Dokumentasi pada Organisasi PengembangPerangkat Lunak(Thomas Suselo)
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 5/19
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 6/19
Jurnal Teknologi Industri Vol. XI No. 2 April 2007:121 - 132
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 :
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 7/19
124
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 8/19
Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: StudiKasus Optimasi Organisasi dan Dokumentasi pada Organisasi PengembangPerangkat Lunak(Thomas Suselo)
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 9/19
Jurnal Teknologi Industri Vol. XI No. 2 April 2007:121 - 132
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 10/19
1 0
126
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 11/19
Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: StudiKasus Optimasi Organisasi dan Dokumentasi pada Organisasi PengembangPerangkat Lunak(Thomas Suselo)
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 12/19
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 13/19
Jurnal Teknologi Industri Vol. XI No. 2 April 2007:121 - 132
RF NO QUESTION 0 0,5 1 SCORE
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 14/19
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 15/19
Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: StudiKasus Optimasi Organisasi dan Dokumentasi pada Organisasi PengembangPerangkat Lunak(Thomas Suselo)
RF NO QUESTION 0 0,5 1 SCORE
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 16/19
Jurnal Teknologi Industri Vol. XI No. 2 April 2007:121 - 132
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 17/19
Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: StudiKasus Optimasi Organisasi dan Dokumentasi pada Organisasi PengembangPerangkat Lunak(Thomas Suselo)
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
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 18/19
131
5/11/2018 Analisis Mg resiko - slidepdf.com
http://slidepdf.com/reader/full/analisis-mg-resiko 19/19
Jurnal Teknologi Industri Vol. XI No. 2 April 2007:121 - 132
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