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

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

Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: Studi Kasus Optimasi Organisasi dan Dokumentasi pada Organisasi Pengembang Perangkat Lunak Thomas Suselo Program Studi Teknik Informatika, Fakultas Teknologi Industri, Universitas Atma Jaya Yogyakarta Jl. Babarsari no 43 Yogyakarta E-mail: [email protected]

Abstract Software developments often have many risks, such as development failures, cost-overruns, and schedule overruns.Those factors have to be minimize using risk management, and one of risk management methods is Just-In-Time (JIT). The concept of JIT is managing costs, schedules and software functionalities. JIT talks about risk quality of those factors, and usualy people have difficulty to fix or minimize risks by thinking the quality area. Then Karolak (1999) was developed Software Engineering Risk Model (SERIM) based on JIT method to analyze riks and give quantity results. SERIM uses risk metrics that contains many question to be answered by management and then solves problems by making conclution of results SERIM and JIT are used in this analysis to give conclusions on simulation case. The case is about software developer that have internal organizations and software documentations problems, and these problems usualy make cost-overruns and schedule-overruns. Target of analysis are getting risk quantity, making conclusions about how to 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 pengembangan sistem (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 dalam tingkatan yang terkendali sehingga pengembangan perangkat lunak, mencakup aktivitasnya dapat mencapai tingkat keberhasilan yang diinginkan. Oleh sebab itulah pengembang perangkat lunak perlu melakukan manajemen resiko. Salah satu pendekatan manajemen resiko adalah Just-in-Time (JIT) dengan menggunakan Software Engineering Risk Model (SERIM). Pendekatan tersebut dikembangkan sebagai upaya untuk 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 13

Jurnal Teknologi Industri Vol. XI No. 2 April 2007:13-24

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 perangkat lunak yang memiliki sumber daya yang baik namun lemah dalam hal koordinasi dan mereka tidak memiliki standar penulisan dokumentasi pada pengembangan perangkat lunaknya serta dokumentasi untuk user. Untuk menjelaskan manajemen resiko JIT dengan menggunakan pendekatan SERIM, dilakukan simulasi kasus tersebut. Studi kasus dilakukan dengan melakukan simulasi kalkulasi probabilitas SERIM, yang diimplementasikan secara sederhana pada piranti lunak aplikasi spreadsheet SERIM 2. Tujuan dan Hasil Penelitian Adapun 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, Risk Factors, dan Development) dijadikan dasar kesimpulan awal manajemen resiko yang kemudian dibandingkan dengan simulasi SERIM dengan perbaikan beberapa faktor untuk memimasi resiko. 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-Time 3.1. Manajemen Resiko Manajemen resiko perangkat lunak adalah pengelolaan dan minimasi kegagalan yang mencakup 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: a. Tidak adanya kejelasan akan kebutuhan perangkat lunak sehingga mengakibatkan ketidaktepatan fungsionalitas yang dikembangkan. b. Ketidakpahaman dalam estimasi biaya yang akan digunakan dalam mengembangkan perangkat lunak sehingga mengakibatkan biaya berlebihan c. 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 : a. Risk Identification, yaitu melakukan identifikasi gejala resiko yang terjadi. b. Risk Strategy, yaitu merancang suatu tahapan langkah untuk menanggulangi resiko. c. Risk Assessment, yaitu mengukur akibat yang akan disebabkan resiko. d. Risk Mitigation, yaitu melakukan mitigasi dari hasil penilaian resiko. e. Risk Reporting, yaitu membuat penulisan terhadap seluruh kegiatan manajemen resiko sehingga dapat digunakan sebagai dasar analisis manajemen resiko berikutnya. f. Risk Prediction, yaitu membuat perkiraan akan resiko yang akan terjadi berikutnya dalam pengembangan perangkat lunak.

14


Gambar 1. Aktivitas Manajemen Resiko JIT Perangkat Lunak (Karolak, 1999) Pada penelitian ini yang akan dikaji adalah seberapa besar kuantitas resiko pada kasus organisasi pengembang perangkat lunak yang : a. Tidak membuat dokumentasi pembangunan perangkat lunak (dokumen Spesifikasi Kebutuhan Perangkat Lunak/ SKPL), dokumentasi user-manual, dan penetapan dokumentasi tersebut menjadi standar dalam melakukan pengembangan perangkat lunak. b. 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). 3.2. Pendekatan Just-In-Time (JIT) Konsep JIT pada pengembangan perangkat lunak, filosofinya bertumpu pada fungsionalitas, biaya dan waktu (jadual). Manajemen organisasi perangkat lunak kadangkali memandang proses pengembangan perangkat lunak sebagai proses yang sangat tidak dapat digambarkan (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: a. Antisipasi dan minimasi resiko dalam pengembangan perangkat lunak. b. Menangani resiko sejak dini dalam pengembangan perangkat lunak sehingga mengurangi waktu siklus proses, yang akan berimbas pada pengurangan biaya, pemenuhan jadual, dan kesesuaian fungsionalitas. Dalam hal melakukan manajemen resiko perlu untuk memahami dan mengakomodasi semua perspektif sebagai berikut dan perspektif tersebut akan dijadikan dasar untuk melakukan kegiatan manajemen resiko, yang telah diuraikan pada pembahasan mengenai pengertian manajemen resiko: a. Operasional: berkaitan dengan ketidakpastian dalam kegiatan rutin-harian. b. Strategis: berkaitan dengan dampak jangka panjang bagi organisasi / perusahaan. c. Teknis: berkaitan dengan penggunaan teknologi perangkat lunak. d. Bisnis: berkaitan dengan proyek-proyek yang dilakukan organisasi / perusahaan dalam berbagai bentuk komersialitasnya. e. Industri: berkaitan dengan model dan proses pengembangan perangkat lunak yang berbasiskan industri (definitif, terkuantifikasi, sistematik). f. Praktisi: berkaitan dengan implementasi dan praktik-praktik pengembangan perangkat lunak

15


4. Analisis Menggunakan Software Engineering Risk Model (SERIM) Karolak (1999) meneliti suatu model yang dapat digunakan sebagai acuan manajemen resiko dengan pendekatan JIT yang disebut sebagai Software Engineering Risk Model (SERIM). Model tersebut merupakan model probabilitas yang mengakomodasikan elemen-elemen berikut: a. Technical Risk terdiri atas aspek-aspek functionality, quality, reability, usability, timelines, maintainability, reusability. b. Cost Risk, terdiri atas aspek-aspek budget, nonrecurring cost, recurring cost, fixed cost, variable cost. c. 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: a. Organization f. Risk Culture b. Estimation g. Usability c. Monitoring h. Correctness d. Development methodology i. Reliability e. Tools j. Personel Faktor resiko inilah yang kemudian diukur dalam risk metrics yang diformulasikan ke dalam 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 kalkulasi rentang nilai pada pohon probabilitas mencerminkan formulasi faktor resiko yang dihadapi organisasi (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 kemudian dikelompokkan berdasarkan elemen-elemen resiko untuk kemudian dipadukan sehingga menghasilkan total resiko pengembangan perangkat lunak. 4.1. Penerapan SERIM pada Studi Kasus Organisasi Pengembang Perangkat Lunak Sebenarnya untu mengukur tingkat resiko dalam suatu organisasi dengan menggunakan SERIM sangatlah mudah, langkah penerapan SERIM adalah sebagai berikut : a. Menentukan organisasi pengembang perangkat lunak untuk analisis manajemen resiko dan mendeskripsikan karakteristik umum organisasi berdasarkan 10 faktor-faktor resiko, yang kemudian menjadi dasar untuk simulasi awal. b. Menjawab 81 pertanyaan dalam simulasi risk metrics disesuaikan dengan karakteristik berdasarkan faktor resiko tersebut. c. Melihat keluaran dari perhitungan risk metrics. Dari hasil keluaran tersbut dapat ditarik kesimpulan mengenai tingkat resiko yang ada di dalam organisasi. 4.1.1. Menentukan Organisasi dan Mendeskripsikan Karakteristik Umum Organisasi 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 (user manual). Untuk karakteristik lainnya dapat dilihat di dalam tabel 1. Deskripsi singkat organisasi tersebut sebagai berikut :

16


Tabel 1. Karakteristik Organisasi Pengembang Perangkat Lunak FAKTOR Organization

KARAKTERISTIK Sumber 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

Monitoring

Development Methodology

Tools

Risk Culture Usability

Correctness

Reliability

Personel

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 hasil estimasi yang berbeda. 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). Methodology pengembangan telah diterapkan dengan baik . Pengembangan perangkat lunak memiliki standar tetapi tidak ada dokumentasi pengembangan (SKPL) Keterlibatan user dalam pengembangan perangkat lunak dilakukan hanya sesekali. 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. Konsep manajemen resiko belum diterapkan di dalam organisasi. Usability perangkat lunak telah cukup baik dikembangkan berdasarkan metodologi yang digunakan. Belum adanya dokumentasi untuk user (user manual) karena dianggap perangkat lunak dibuat sesuai permintaan user, sehingga user mampu menggunakannya. Spesifikasi perangkat lunak dibuat dengan kurang baik karena seringkali kebutuhan user berubah-ubah. Pelacakan error pada suatu fungsi dapat dilakukan dengan baik dan cepat. Keandalan perangkat lunak dilakukan oleh tim penguji dan user secara trialerror. Tidak adanya pengujian desain pengembangan perangkat lunak Pelaksana pengembangan perangkat lunak adalah tim yang handal sesuai dengan 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 risk metrics) lalu dibandingkan untuk didapatkan kesimpulan.

17


4.1.2. Menjawab Pertanyaan pada Risk Metrics Formulasi 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 risk metrics untuk memberikan pembobotan (score) yang disesuaikan lingkungan awal organisasi sehingga nantinya didapat nilai probabilitas resiko.

ORGANIZATION

RISK FAC-TOR (RF)

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

NO

Are You using or do You plan to use experienced software managers?

1

1

O2

Has Your company been producing software similar to this in the past?

1

1

O3

Is there a documented organizational structure 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 management team?

1

0,5

O6

Does good communication exist between different organizations supporting the development of the software project?

1

0

O7

Are software configuration management functions being performed?

1

0

O8

Are software quality functions being performed?

ESTIMATION

E2 E3

What estimation method is used?

Is a software cost model used? Is the estimation based on past software productivity metrics?

1 a) Guess b) Analogy c) Price to Win d) Dictated by Circumstances e) Top-Down f) Bottom-Up g) Other 1

0,5 =0.2 =0.6 =0.3 =0.3

0,7

=0.5 =0.7 =0.4 0

1

0,5

E4

Are the schedule estimates based on past software projects?

1

0,5

E5

Are estimates revised on a monthly or more frequent basis?

1

0,5

1

0,5

1

0,5

1

0,5

1

0,5

E6 E7 MONITORING

SCORE

O1

E1

18

QUESTION

ANSWER give "1" for one of these option (0.0 = changing, compromising, least; 0.5 = mixed; 1.0 = fixed, complete) otherwise follow the valuedchoices given 0.0 0.5 1.0

M1 M2 M3

How accurate are Your past cost estimates compared to actual costs? How accurate are Your past schedule estimates compared to actual schedules? For each major software effort, are there distinct milestones set for each software development phase? Is a detailed Work Breakdown Structure (WBS) used to track and report cost and budget for each piece of major software development? Is there a monitoring system setup for cost, schedule, and earned-value?

1

0

Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: Studi Kasus Optimasi Organisasi dan Dokumentasi pada Organisasi Pengembang Perangkat Lunak (Thomas Suselo) RF

NO

DEVELOPMENT METHODOLOGY

MONITORING

M4 M5

TOOLS

0

0,5

1

SCORE

Are cost, schedule, and earned-value reports available on demand? Are cost, schedule and earned-value reports updated on a monthly or more frequent basis?

1

0

1

0

M6

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

1

0,5

M7

Does a means exist to address and record technical problems? Is it used and updated on a weekly basis?

1

0,5

DM1

Is there a documented software development methodology or plan used for the project, and is it being adhered to closely?

DM2

Are the software developers trained in the development methodology?

DM3

How closely is the development methodology followed?

DM4

Does the development methodology include requirements, design, and code reviews/walkthroughs/inspections?

DM5

Does the development methodology require test plans and or test procedures for all software functions?

DM6

Does the development methodology require documentation such as requirements, design, and software development folders?

DM7

Is regression testing performed?

T1

Are the software developers trained in using the tools?

T2 T3

Are automated tools used for software design? Are automated tools used for testing? Are automated tools used for test procedure generation? Are automated tools used for regression testing? Are automated tools used for requirements traceability?

T4

RISK CULTURE

QUESTION

T5 T6

1

0 1 1

1 0,5

1

0

1

0,5

1

0 1

0,5 1

1

1 1

1 0,5

1

0,5

1

0,5

1

0,5

1

0,5

T7

Are automated tools used for re-engineering (identifying existing characteristics of the software based on its code, such as its structure, data dictionary, and so forth)?

T8

How stable is Your compiler/linker/debugger?

1

1

T9

Are tools readily available to the software development personnel when needed?

1

1

RC1

Is Your company willing to trade additional budget risk for additional profit?

1

0,5

RC2

Is Your company willing to trade additional schedule risk for additional profit?

1

0,5

RC3

Is Your company willing to trade additional technical risk for additional profit?

1

0,5

RC4

Is Your company willing to trade less budget risk for less profit?

1

0,5

RC5 RC6 RC7

Is Your company willing to trade less schedule risk for less profit? Is Your company willing to trade less technical functionality for less profit? Is Your company market-driven?

1

0 1

0,5

1

0,5

19


RF

NO

USABILITY

1

SCORE 0,5

RC9

How does Your company's investment in new products and technology rate?

1

0,5

RC10

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

1

0,5

U3 U4 U5

CORRECTNESS

0,5 1

U2

RELIABILITY

0

RC8

RC11 U1

20

QUESTION Is Your company culture conservative in its decisionmaking?

Does Your company practice risk management? Is there a user manual for the software? Are there help functions for each input or output screen?

1 1

0 0

1

0

Is the user involved in reviewing prototypes or earlier versions of the software? Is the user interface designed to an industry standard or to a standard familiar to the user? Have user response times been identified?

1

0,5

1

0,5

1

0,5

1

0,5

U6

Has the design been evaluated to minimize keystrokes and data entry?

C1

Have all the software requirements been identified and documented?

C2

Have the software requirements been traced to the design?

C3

Are the software requirements traceable to the code?

C4

Are the software requirements traceable to the test procedures?

1

0,5

C5

Have there been, or are there expected to be, many changes made in the requirements?

1

0,5

C6

Are the software designs traceable to the code?

C7

Is the software design traceable to the test procedures?

1

0,5

C8

Have all the open action items been addressed and implemented prior to delivery to the customer?

1

0,5

C9

Has software functional testing been performed prior to customer delivery?

1

0,5

R1

Are there error handling conditions within the software design and code?

R2

When an error condition is detected, does processing continue?

1

0,5

R3

Are error tolerances defined for input and output data?

1

0,5

R4

Are inputs checked for valid values before processing begins?

1

0,5

R5

Are hardware faults detected and processed in the software?

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

R8

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

1

0,5

R9

Is a software reliability model used to predict reliability?

R10

Are tests performed with test plans?

1

0,5

R11

Has stress testing been performed?

1

0,5

R12

Is testing performed by a group separate from the software development group?

1

0 1

0,5 1

1

1

1

0

1

1

1

0

0


PERSONNEL

RF

NO P1

QUESTION Are personnel resources available and identified?

P2

0

0,5

1 1

SCORE 1

How experienced are the personnel resources in the product type being developed?

1

1

P3

How experienced are the personnel resources in the development environment?

1

1

P4

How experienced are the personnel resources in the implementation language?

1

1

P5

How large will the number of software development personnel be at peak?

1

1

4.1.3. Hasil Output SERIM Jawaban 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)

Technical P(A1)

0,52 Cost

0,51

P(A2)

0,52

Risk Elements Schedule

Risk Factors

Development Phases

P(A3)

0,52

Organization

Estimation

Monitoring


Tools

P(A4) 0,50

P(A5) 0,46

P(A6) 0,29

P(A7) 0,36

P(A8) 0,72

Risk Culture

Usability

Correctness

Reliability

Personnel

P(A9) 0,45

P(A10) 0,33

P(A11) 0,56

P(A12) 0,38

P(A13) 1,00

Pre-Requirements

Requirements

Design

P(B) 0,54

P(C) 0,41

P(D) 0,45

Code

Test

Development & Maintenance

P(E) 0,47

P(F) 0,44

P(G) 0,44

Software Risk Management Activities Identification P(H) 0,49 Strategy & Planning

P(I)

0,43

Assessment

P(J)

0,49

Mitigation & Avoidance

P(K)

0,46

Reporting

P(L)

0,29

Prediction

P(M)

0,49

21


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 pada organisasi tersebut b. Nilai faktor resiko yang paling terlihat adalah Monitoring, yaitu sebesar 0.29, ini membuktikan pernyataan awal pada tabel 2 bahwa komunikasi pada masing-masing anggota tidak terjalin dengan baik sehingga apabila tidak diperbaiki akan menimbulkan silo mentality akan menyebabkan 71% resiko pada faktor monitoring dan berdampak pada faktor lainnya. c. Development methodology akan menyebabkan 63% resiko pada pengembangan apabila 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 pada aktivitas 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 Perbandingan Dari hasil output sebelumnya maka telah didapatkan kesimpulan awal berupa prosentase kelemahan/ kendala pada organisasi pengembangan perangkat lunak tersebut. Pada langkah ini kelemahan 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

Development Methodology Usability

Correctness

Menerapkan monitoring penjadualan dan koordinasi (M3). Mulai menerapkan pelaporan-pelaporan yang berfungsi sebagai komunikasi dan koordinasi (M4). Membuat SKPL sebagai standar dokumentasi pengembangan perangkat lunak yang lengkap dan baik (DM1,4,6) Membuat user manual yang lengkap dan baik (U1). Membuat help function dengan baik dan lengkap sehingga membantu user dalam menghadapi masalah (U2). 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 :

22

Analisis Manajemen Resiko Perangkat Lunak dengan Pendekatan Just-in-Time: Studi Kasus Optimasi Organisasi dan Dokumentasi pada Organisasi Pengembang Perangkat Lunak (Thomas Suselo) Total Product Risk

Software Project Risk

P(A)

Technical P(A1)

0,67 Cost

0,66

P(A2)

0,68

Risk Elements Schedule

Risk Factors

Development Phases

P(A3)

0,68

Organization

Estimation

Monitoring


Tools

P(A4) 0,75

P(A5) 0,46

P(A6) 0,57

P(A7) 0,79

P(A8) 0,72

Risk Culture

Usability

Correctness

Reliability

Personnel

P(A9) 0,55

P(A10) 0,67

P(A11) 0,67

P(A12) 0,38

P(A13) 1,00

Pre-Requirements

Requirements

Design

P(B) 0,68

P(C) 0,65

P(D) 0,63

Code

Test

Development & Maintenance

P(E) 0,65

P(F) 0,68

P(G) 0,65

Software Risk Management Activities Identification P(H) 0,63 Strategy & Planning

P(I)

0,60-

Assessment

P(J)

0,53

Mitigation & Avoidance

P(K)

0,68

Reporting

P(L)

0,57

Prediction

P(M)

0,63

Hasil output dengan memasukkan bobot untuk perbaikan majemen organisasi, pembuatan dokumentasi 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 ditetapkan menjadi 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 23


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 dan menetapkan standar dokumentasi, baik SKPL, user-manual, maka dapat mengurangi resiko dalam pengembangan perangkat lunak. 5. Kesimpulan Dari 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 suatu organisasi. 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 Process Whitepaper Rational Software. NN, 2005, Diktat Kuliah IS7075 Manajemen Resiko; Program Magister Sistem Informasi 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.

24

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

Recommend Documents