Strategi Software Process Improvement: Studi Kasus PT....

UNIVERSITAS INDONESIA

STRATEGI SOFTWARE PROCESS IMPROVEMENT:

STUDI KASUS PT XYZ

KARYA AKHIR

JOSHUA ROCKY TUAHTA PURBA

1506706566

FAKULTAS ILMU KOMPUTER

PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI

JAKARTA

OKTOBER 2017

Strategi software process..., Joshua Rocky Tuahta Purba, FASILKOM, 2017

UNIVERSITAS INDONESIA

STRATEGI SOFTWARE PROCESS IMPROVEMENT:

STUDI KASUS PT XYZ

KARYA AKHIR

Diajukan sebagai salah satu syarat untuk memperoleh gelar

Magister Teknologi Informasi

JOSHUA ROCKY TUAHTA PURBA

1506706566

FAKULTAS ILMU KOMPUTER

PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI

JAKARTA

OKTOBER 2017


ii

HALAMAN PERNYATAAN ORISINALITAS

Karya akhir ini adalah hasil karya saya sendiri,

dan semua sumber baik yang dikutip maupun dirujuk

telah saya nyatakan dengan benar.

Nama : Joshua Rocky Tuahta Purba

NPM : 1506706566

Tanda Tangan :

Tanggal : 22 Juni 2017


iii

HALAMAN PENGESAHAN

Karya akhir ini diajukan oleh:


NPM : 1506706566

Program Studi : Magister Teknologi Informasi

Judul Karya Akhir : Strategi Software Process Improvement: Studi Kasus PT

XYZ

Telah berhasil dipertahankan di hadapan Dewan Penguji dan diterima sebagai

bagian persyaratan yang diperlukan untuk memperoleh gelar Magister Teknologi

Informasi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu

Komputer, Universitas Indonesia.

DEWAN PENGUJI

Pembimbing : Dr. Ir. Eko Kuswardono Budiardjo, M.Sc. ( ........................ )

Penguji : Alex Ferdinansyah, M.Kom. ( ........................ )

Penguji : Dr.Eng. Mohamad Ivan Fanany, S.Si., M.Kom. ( ........................ )

Ditetapkan di : Jakarta

Tanggal : 22 Juni 2017


iv

KATA PENGANTAR

Puji syukur saya panjatkan kepada Tuhan Yang Maha Esa, karena atas berkat dan

rahmat-Nya, saya dapat menyelesaikan Karya Akhir ini. Saya menyadari bahwa

tanpa bantuan dan bimbingan dari berbagai pihak, dari masa perkuliahan sampai

pada penyusunan Karya Akhir ini, sangatlah sulit bagi saya untuk

menyelesaikannya. Oleh karena itu, saya mengucapkan terima kasih kepada:

1. Bapak Dr. Ir. Eko Kuswardono Budiardjo, M.Sc. selaku dosen pembimbing

yang telah menyediakan waktu, tenaga, dan pikiran, untuk mengarahkan

saya dalam penyusunan Karya Akhir ini.

2. Bapak Alex Ferdinansyah, M.Kom. dan Bapak Dr.Eng. Mohamad Ivan

Fanany, S.Si., M.Kom. selaku dosen penguji yang telah memberikan kritik

konstruktif untuk revisi Karya Akhir ini.

3. Semua dosen lainnya dan staf administrasi Program Studi Magister

Teknologi Informasi, Fakultas Ilmu Komputer - Universitas Indonesia atas

didikan dan bantuannya.

4. Rekan-rekan di PT XYZ, terutama Bapak RK, Bapak IWSY, Bapak IYB,

Bapak JW, dan Ibu TYS yang telah banyak membantu dalam usaha

memperoleh data yang saya perlukan.

5. Teman-teman seangkatan MTI-2015SB dan teman-teman satu bimbingan

Karya Akhir atas pertolongan, saran, dan kritiknya.

6. Ayah saya Ir. Rolettha Yahya Purba, MS dan Ibu saya Mitrawaty

Sembiring, SH atas bantuan dukungan material dan moral.

Akhir kata, saya berharap Tuhan Yang Maha Esa berkenan membalas segala

kebaikan semua pihak yang telah membantu. Semoga Karya Akhir ini membawa

manfaat bagi PT XYZ dan untuk pengembangan ilmu.

Jakarta, 22 Juni 2017

Penulis

( Joshua Rocky Tuahta Purba )


v

HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI

KARYA AKHIR UNTUK KEPENTINGAN AKADEMIS

Sebagai sivitas akademik Universitas Indonesia, saya yang bertanda tangan di

bawah ini:


NPM : 1506706566


Fakultas : Fakultas Ilmu Komputer

Jenis Karya : Karya Akhir

Demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada

Universitas Indonesia Hak Bebas Royalti Nonekslusif (Non-exclusive Royalty-

Free Right) atas karya ilmiah saya yang berjudul:

Strategi Software Process Improvement: Studi Kasus PT XYZ

Beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti

Nonekslusif ini Universitas Indonesia berhak menyimpan, mengalihmedia/

formatkan, mengelola dalam bentuk pangkalan data (database), merawat, dan

memublikasikan karya akhir saya tanpa meminta izin dari saya selama tetap

mencantumkan saya sebagai penulis/pencipta dan sebagai pemilik Hak Cipta.

Demikian pernyataan ini saya buat dengan sebenarnya.

Dibuat di : Jakarta

Pada tanggal : 22 Juni 2017

Yang menyatakan,

( Joshua Rocky Tuahta Purba )


vi Universitas Indonesia

ABSTRAK



Judul : Strategi Software Process Improvement: Studi Kasus PT XYZ

Kelangsungan bisnis PT XYZ sangat tergantung pada SI/TI yang

dimanfaatkannya. Namun PT XYZ tidak memiliki proses pemeliharaan perangkat

lunak yang terdefinisi. Tidak tercapainya target pemeliharaan perangkat lunak

berpotensi menghambat pemanfaatan SI/TI, yang dapat merambat pada

terhambatnya proses bisnis yang menggunakan SI/TI tersebut.

Untuk mengatasi masalah manajemen pada pemeliharaan perangkat lunak, perlu

diketahui tingkat kematangan proses pemeliharaan terlebih dahulu, agar dapat

menyusun strategi SPI. Penelitian ini mengukur tingkat kematangan berdasarkan

S3m menggunakan S3mAssess. Strategi SPI akan disusun menggunakan tingkat

kematangan yang lebih tinggi dari saat ini.

Penelitian ini menghasilkan strategi SPI yang dapat digunakan sebagai saran

perbaikan bagi PT XYZ untuk meningkatkan kematangan proses pemeliharaan

perangkat lunaknya. Peningkatan kematangan proses tersebut diharapkan dapat

membantu dalam pencapaian visi dan misinya.

Kata Kunci : software process improvement, proses pemeliharaan perangkat

lunak, s3m, prinsip pareto

xvii + 408 halaman; 38 tabel; 22 gambar; 10 lampiran


vii Universitas Indonesia

ABSTRACT

Name : Joshua Rocky Tuahta Purba

Study Program : Master of Information Technology

Title : Software Process Improvement Strategy: A Case Study of PT

XYZ

Business continuity of PT XYZ depends on the usage of IS/IT. However, PT XYZ

does not have defined processes for its software maintenance. Unachieved

maintenance target has potential to hamper the utilization of IS/IT, thus could

obstruct the business processes that depends on the IS/IT as well.

To solve the management problem of the software maintenance process, the

maturity level of current process need to be figured out first, so the SPI strategy

can be established. This research appraises maturity level based on S3m using

S3mAssess. The SPI strategy will be established using higher maturity level than the

current maturity level.

This research establishes the SPI strategy that will be used to as a suggestion for

improvement for PT XYZ to increase its maturity level of its software

maintenance process. The increase in maturity level is expected to help it in

achieving its vision and mission.

Keywords : software process improvement, software maintenance process, s3m,

pareto principle

xvii + 408 pages; 38 tables; 22 figures; 10 attachments


viii Universitas Indonesia

DAFTAR ISI

HALAMAN JUDUL ................................................................................................ i

HALAMAN PERNYATAAN ORISINALITAS .................................................... ii

HALAMAN PENGESAHAN ................................................................................ iii

KATA PENGANTAR ........................................................................................... iv

HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI .............................. v

ABSTRAK ............................................................................................................. vi

ABSTRACT .......................................................................................................... vii

DAFTAR ISI ........................................................................................................ viii

DAFTAR TABEL .................................................................................................. xi

DAFTAR GAMBAR ............................................................................................ xii

DAFTAR LAMPIRAN ........................................................................................ xiii

DAFTAR ISTILAH ............................................................................................. xiv

BAB 1 PENDAHULUAN ..................................................................................... 1

1.1 Latar Belakang .......................................................................................... 1

1.2 Perumusan Masalah .................................................................................. 2

1.2.1 Harapan Manajemen Terhadap Proses Pemeliharaan Perangkat

Lunak............................................................................................. 2

1.2.2 Realita Proses Pemeliharaan Perangkat Lunak ............................. 3

1.2.3 Identifikasi Masalah ...................................................................... 4

1.3 Pertanyaan Penelitian ................................................................................ 8

1.4 Tujuan Penelitian ...................................................................................... 8

1.5 Manfaat Penelitian .................................................................................... 8

1.6 Ruang Lingkup Penelitian......................................................................... 8

1.7 Sistematika Penulisan ............................................................................... 9

BAB 2 TINJAUAN PUSTAKA .......................................................................... 11

2.1 Perangkat Lunak ..................................................................................... 11

2.2 Software Process ..................................................................................... 11

2.3 Pemeliharaan Perangkat Lunak ............................................................... 13

2.3.1 Software Maintenance Framework ............................................. 15

2.3.2 Proses Pemeliharaan Perangkat Lunak ....................................... 17

2.4 Software Process Improvement (SPI) ..................................................... 19

2.5 Capability Maturity Model Integration for Development (CMMI-DEV)

................................................................................................................. 20

2.5.1 Representasi Bertingkat (Staged Representation) ....................... 25

2.5.2 Representasi Berkelanjutan (Continuous Representation) ......... 27

2.6 Software Maintenance Maturity Model (S3m) ........................................ 27

2.7 Pemilihan Kerangka Kerja SPI ............................................................... 35

2.8 Appraisal atau Assessment untuk SPI ..................................................... 35

2.8.1 Standard CMMI Appraisal Method for Process Improvement

(SCAMPI) ................................................................................... 36

2.8.2 S3mAssess ....................................................................................... 36

2.9 Prinsip Pareto .......................................................................................... 38

2.10 Penelitian Sebelumnya ............................................................................ 40


ix Universitas Indonesia

2.10.1 Software Maintenance Process Model and Contrastive Analysis40

2.10.2 Evaluating the Relationship Between Process Improvement and

Schedule Deviation in Software Maintenance ............................ 40

2.10.3 Critical Success Factors in Software Maintenance: A Case Study

..................................................................................................... 41

2.10.4 Beyond Productivity in Software Maintenance: Factors Affecting

Lead Time in Servicing Users' Requests ..................................... 41

2.10.5 Rangkuman Penelitian Sebelumnya ............................................ 41

2.11 Kerangka Teoretis ................................................................................... 43

BAB 3 METODOLOGI PENELITIAN ............................................................ 45

3.1 Rancangan Penelitian .............................................................................. 45

3.1.1 Pengumpulan Data Awal............................................................. 47

3.1.2 Identifikasi Masalah .................................................................... 47

3.1.3 Tinjauan Pustaka ......................................................................... 47

3.1.4 Pengumpulan Data Penilaian ...................................................... 47

3.1.5 Penilaian Tingkat Kematangan ................................................... 47

3.1.6 Penyusunan Strategi SPI ............................................................. 48

3.1.7 Pembuatan Kesimpulan dan Saran .............................................. 48

3.2 Metode Pengumpulan Data ..................................................................... 48

3.2.1 Wawancara .................................................................................. 48

3.2.2 Studi Dokumen ........................................................................... 91

3.3 Objek Studi Kasus................................................................................... 91

3.3.1 Struktur Organisasi Departemen TI ............................................ 93

3.3.2 Fungsi Departemen Teknologi Informasi ................................... 93

3.4 Studi Kasus: Proses Pemeliharaan Perangkat Lunak ............................ 100

3.5 Jadwal Penelitian .................................................................................. 101

BAB 4 RANCANGAN DAN HASIL KAJIAN KPA S3M .............................. 103

4.1 Rancangan Kajian ................................................................................. 103

4.1.1 Pemetaan PA CMMI-SE/SW/IPPD/SS V1.1 ke KPA S3m ....... 105

4.1.2 Pemetaan PA CMMI-DEV V1.2 ke KPA S3m ......................... 107

4.1.3 Pemetaan PA CMMI-DEV V1.3 ke KPA S3m ......................... 110

4.2 Penjabaran Hasil Kajian ........................................................................ 129

4.2.1 Maintenance Process Focus (Pro1) .......................................... 129

4.2.2 Maintenance Process/Service Definition (Pro2) ....................... 140

4.2.3 Maintenance Training (Pro3) .................................................... 146

4.2.4 Maintenance Process Performance (Pro4) ............................... 151

4.2.5 Maintenance Innovation and Deployment (Pro5) ..................... 156

4.2.6 Event/Request Management (Req1) .......................................... 162

4.2.7 Maintenance Planning (Req2) .................................................. 168

4.2.8 Request/Software Monitoring and Control (Req3) ................... 184

4.2.9 SLA and Supplier Agreements Management (Req4) ................. 191

4.2.10 Predelivery and Transition Services (Evo1) ............................. 201

4.2.11 Operational Support Services (Evo2) ....................................... 212

4.2.12 Software Evolution and Correction Services (Evo3) ................ 219

4.2.13 Verification and Validation (Evo4) ........................................... 229

4.2.14 Configuration and Version Management (Sup1) ...................... 236

4.2.15 Process, Service, and Software Quality Assurance (Sup2)....... 241

4.2.16 Maintenance Measurement and Analysis (Sup3) ...................... 246


x Universitas Indonesia

4.2.17 Causal Analysis and Problem Resolution (Sup4) ..................... 249

4.2.18 Software Rejuvenation, Migration, and Retirement (Sup5) ...... 252

4.3 Ringkasan Hasil Kajian......................................................................... 258

4.3.1 Tingkat Kematangan 0 .............................................................. 258



BAB 5 REKOMENDASI PERBAIKAN PROSES PEMELIHARAAN

PERANGKAT LUNAK ........................................................................ 267

5.1 Fase Initiating ....................................................................................... 267

5.2 Fase Diagnosing.................................................................................... 267

5.3 Fase Establishing .................................................................................. 270

5.3.1 Rekomendasi untuk Kategori Kelemahan ART (Tidak Ada

Artifak) ...................................................................................... 273

5.3.2 Rekomendasi untuk Kategori Kelemahan PRD (Tidak ada

Prosedur) ................................................................................... 275

5.3.3 Validasi Rekomendasi ............................................................... 276

5.4 Fase Acting ............................................................................................ 277

5.5 Fase Leveraging .................................................................................... 278

BAB 6 KESIMPULAN DAN SARAN ............................................................. 279

6.1 Kesimpulan ........................................................................................... 279

6.2 Saran ..................................................................................................... 280

DAFTAR PUSTAKA ......................................................................................... 281


xi Universitas Indonesia

DAFTAR TABEL

Tabel 1.1 Target Aktivitas Pemeliharaan Perangkat Lunak .................................. 2

Tabel 1.2 Ringkasan Tiket Pemeliharaan Perangkat Lunak.................................. 3

Tabel 2.1 Kategori-kategori Pemeliharaan Perangkat Lunak ............................. 14

Tabel 2.2 Rangkuman Penelitian Sebelumnya .................................................... 42

Tabel 3.1 Rancangan Penelitian .......................................................................... 45

Tabel 3.2 Pemilihan Narasumber Masing-masing KPA ..................................... 49

Tabel 3.3 Pointer Pertanyaan Wawancara .......................................................... 50

Tabel 3.4 Jadwal Kegiatan Penelitian ............................................................... 102

Tabel 4.1 Ringkasan Penilaian Praktek-praktek Pro1 ....................................... 130





Tabel 4.6 Ringkasan Penilaian Praktek-praktek Req1 ...................................... 163




Tabel 4.10 Ringkasan Penilaian Praktek-praktek Evo1 ...................................... 203




Tabel 4.14 Ringkasan Penilaian Praktek-praktek Sup1 ...................................... 238





Tabel 4.19 Evaluasi Pencapaian Tingkat Kematangan 0 .................................... 258



Tabel 5.1 Praktek-praktek Tingkat Kematangan 1 Yang Tidak Tercapai

Sepenuhnya ....................................................................................... 268

Tabel 5.2 Kode dan Kategori Kelemahan Berdasarkan Kemiripan .................. 270

Tabel 5.3 Kelemahan-kelemahan yang Menyebabkan Tidak Tercapainya

Tingkat Kematangan 1 ...................................................................... 271

Tabel 5.4 Frekuensi Kumulatif Kelemahan Per Kategori ................................. 272

Tabel 5.5 Kategori Kelemahan Dipetakan Terhadap KPA ............................... 273

Tabel 5.6 Kategori Kelemahan ART dan Rekomendasinya ............................. 273

Tabel 5.7 Kategori Kelemahan PRD dan Rekomendasinya.............................. 275

Tabel 5.8 Validasi Rekomendasi dengan Kepala Departemen ......................... 276

Tabel 5.9 Dampak Rekomendasi Terhadap Kelemahan Pada Praktek-praktek di

Tingkat Kematangan 1 ...................................................................... 277


xii Universitas Indonesia

DAFTAR GAMBAR

Gambar 1.1 Diagram Fishbone Analisis Akar Masalah ....................................... 5

Gambar 2.1 Hubungan Antar Elemen Pemeliharaan Perangkat Lunak ............. 16

Gambar 2.2 Proses Pemeliharaan ....................................................................... 18

Gambar 2.3 Elemen-elemen Kerangka Kerja SPI .............................................. 20

Gambar 2.4 Struktur S3m Berdasarkan Deskripsi April & Abran (2008) .......... 29

Gambar 2.5 Diagram Flowchart Algoritma S3mAssess Berdasarkan Deskripsi

Paquette, April, & Abran (2006) .................................................... 37

Gambar 2.6 Kerangka Teoretis .......................................................................... 43

Gambar 3.1 Langkah-langkah Penelitian ........................................................... 46

Gambar 3.2 Struktur Organisasi PT XYZ .......................................................... 92

Gambar 3.3 Struktur Organisasi Departemen TI................................................ 93

Gambar 4.1 Pemetaan PA dalam CMMI-SE/SW/IPPD/SS V1.1 ke KPA dalam

S3m Berdasarkan Deskripsi April & Abran (2008) ....................... 106

Gambar 4.2 Pemetaan PA dalam CMMI-DEV V1.2 ke KPA dalam S3m

Berdasarkan Pemetaan dari CMMI-SE/SW/IPPD/SS V1.1 ke S3m109


Berdasarkan Pemetaan dari CMMI-DEV V1.2 ke S3m ................ 111

Gambar 4.4 Pemetaan SP dari QPM di CMMI-DEV V1.3 ke S3m ................. 116

Gambar 4.5 Pemetaan SP dari RSKM di CMMI-DEV V1.3 ke S3m ............... 118

Gambar 4.6 Pemetaan SP dari REQM di CMMI-DEV V1.3 ke S3m ............... 120

Gambar 4.7 Pemetaan SP dari RD di CMMI-DEV V1.3 ke S3m ..................... 123

Gambar 4.8 Pemetaan SP dari TS di CMMI-DEV V1.3 ke S3m ..................... 126

Gambar 4.9 Pemetaan SP dari DAR di CMMI-DEV V1.3 ke S3m .................. 127


Berdasarkan Pemetaan Praktek-praktek ....................................... 128

Gambar 5.1 Kesenjangan Rating KPA Saat Ini dan Target untuk Tingkat

Kematangan 1 ............................................................................... 268

Gambar 5.2 Diagram Pareto Kelemahan Per Kategori .................................... 272


xiii Universitas Indonesia

DAFTAR LAMPIRAN

Lampiran A. Transkrip Wawancara Awal .......................................................... 284

Lampiran B. Transkrip Wawancara Identifikasi Masalah .................................. 292

Lampiran C. Transkrip Wawancara Req1 ........................................................... 311

Lampiran D. Transkrip Wawancara Evo4 ........................................................... 318

Lampiran E. Transkrip Wawancara Sup2 ........................................................... 323

Lampiran F. Transkrip Wawancara Sup1 ........................................................... 325

Lampiran G. Transkrip Wawancara Pro2, Req2, Evo1, Evo2, Evo3, Sup1, Sup2,

Sup3, Sup4, dan Sup5 .................................................................... 327

Lampiran H. Transkrip Wawancara Req4 dan Evo4 .......................................... 374

Lampiran I. Transkrip Wawancara Pro1, Pro2, Pro3, Pro4, Pro5, dan Sup2 .... 389

Lampiran J. Jawaban Pertanyaan Req3 ............................................................. 405


xiv Universitas Indonesia

DAFTAR ISTILAH

Artifak:

Bentuk nyata dari bukti objektif yang menunjukkan pekerjaan yang

dilakukan yang merupakan salah satu keluaran utama dari praktek atau

konsekuensi dari pelaksanaan praktek (Cahyadi, 2015, hal. xv).

Capability Level:

Lihat tingkat kemampuan.

Domain proses:

Pengelompokan besar dari proses-proses dalam model kematangan. Domain

proses dibagi menjadi area-area yang disebut dengan KPA. Beberapa model

kematangan akan membagi lagi KPA ke dalam road map (April & Abran,

2008, hal. 44-45).

Evo1:

KPA dalam S3m yang bernama Predelivery and Transition Services.

Evo2:

KPA dalam S3m yang bernama Operational Support Services.

Evo3:

KPA dalam S3m yang bernama Software Evolution and Correction Services.

Evo4:

KPA dalam S3m yang bernama Verification and Validation.

Key Process Area (KPA):

Sekumpulan praktek kunci yang berkaitan dengan domain aktivitas umum

yang sama (April & Abran, 2008, hal. 44).

Maintainability:

1. Kemudahan dalam melakukan pemeliharaan (Grubb & Takang, 2003,

hal. 6).


xv Universitas Indonesia

2. Kemampuan produk perangkat lunak untuk dimodifikasi. Modifikasi

termasuk koreksi, peningkatan, atau adaptasi perangkat lunak terhadap

perubahan dalam lingkungan serta perubahan requirement dan

spesifikasi fungsional (ISO/IEEE, 2006, hal. 3; IEEE Computer

Society, 2014, hal. 5-5).

Maturity Level:

Lihat tingkat kematangan.

Modification Request (MR):

Permintaan modifikasi SI/TI yang sudah ada.

Pro1:

KPA dalam S3m yang bernama Maintenance Process Focus.

Pro2:

KPA dalam S3m yang bernama Maintenance Process/Service Definition.

Pro3:

KPA dalam S3m yang bernama Maintenance Training.

Pro4:

KPA dalam S3m yang bernama Maintenance Process Performance.

Pro5:

KPA dalam S3m yang bernama Maintenance Innovation and Deployment.

Problem Report (PR):

Laporan masalah atau laporan insiden yang berhubungan dengan SI/TI.

Process Area (PA):

Sekumpulan praktek yang berkaitan dalam sebuah area yang, jika

diimplementasikan dengan benar, memenuhi sekumpulan tujuan yang

dianggap penting untuk membuat peningkatan dalam area tersebut (CMMI

Product Team, 2010, hal. ii).


xvi Universitas Indonesia

Produk kerja:

Apapun yang dihasilkan dari sebuah proses. Termasuk berkas, dokumen,

komponen, pekerjaan sedang berjalan, spesifikasi, tagihan, dan sebagainya,

yang dihasilkan selama dilakukannya proses, bukan hanya produk yang

disampaikan kepada pelanggan atau pengguna proses (April & Abran, 2008,

hal. 284).

Program comprehension:

Membaca dan memahami program-program untuk mengimplementasikan

perubahan (IEEE Computer Society, 2014, hal. 5-10).

Rating:

Angka pencapaian suatu praktek, KPA, atau domain proses dalam S3m yang

merupakan hasil kajian menggunakan metode S3mAssess.

Req1:

KPA dalam S3m yang bernama Event/Request Management.

Req2:

KPA dalam S3m yang bernama Maintenance Planning.

Req3:

KPA dalam S3m yang bernama Request/Software Monitoring and Control.

Req4:

KPA dalam S3m yang bernama SLA and Supplier Agreements Management.

S3m:

Software Maintenance Maturity Model. Merupakan model tingkat

kematangan yang dibuat khusus untuk pemeliharaan perangkat lunak

berskala kecil (yang tidak memerlukan manajemen proyek).

S3mAssess:

Metode penilaian (assessment) untuk S3m.

Sup1:


xvii Universitas Indonesia

KPA dalam S3m yang bernama Configuration and Version Management.

Sup2:

KPA dalam S3m yang bernama Process, Service and Software Quality

Assurance.

Sup3:

KPA dalam S3m yang bernama Maintenance Measurement and Analysis.

Sup4:

KPA dalam S3m yang bernama Causal Analysis and Problem Resolution.

Sup5:

KPA dalam S3m yang bernama Software Rejuvenation, Migration, and

Retirement.

Support Request (SR):

Permintaan dukungan dari pengguna SI/TI terhadap personil pemelihara

perangkat lunak, umumnya untuk ekstrak data operasional.

SWEBOK V3.0:

Guide to the Software Engineering Body of Knowledge, Version 3.0.

Tingkat kemampuan:

Pencapaian dari sebuah perbaikan proses dalam sebuah PA (CMMI Product

Team, 2010, hal. 436).

Tingkat kematangan:

1. Derajat perbaikan proses dalam sekumpulan PA yang sudah

ditentukan di mana semua tujuannya tercapai (CMMI Product Team,

2010, hal. 445). Ini adalah istilah yang digunakan dalam CMMI-DEV

V1.3.

2. Tingkat pencapaian proses dalam satu KPA. Ini adalah istilah yang

digunakan dalam S3m. Konsepnya berbeda dengan tingkat kematangan

pada CMMI-DEV V1.3, dan justru serupa dengan tingkat kemampuan

dalam CMMI-DEV V1.3.


1 Universitas Indonesia

BAB 1

PENDAHULUAN

Bab ini membahas latar belakang, identifikasi masalah, pertanyaan penelitian,

ruang lingkup, tujuan, manfaat, dan sistematika penulisan karya akhir ini.

1.1 Latar Belakang

PT XYZ merupakan perusahaan swasta yang bergerak di bidang asuransi umum

di Indonesia. PT XYZ menetapkan visi yaitu “menjadi perusahaan terkemuka di

industri asuransi umum Indonesia dengan pangsa pasar yang profitable dan

menjadi pelopor dalam memberikan solusi bagi nasabah, mitra kerja dan

stakeholder di tahun 2020”. Misi-misi yang dirumuskan untuk mewujudkan visi

tersebut adalah:

1. Menyediakan solusi asuransi umum yang inovatif kepada nasabah, mitra

kerja dan stakeholder.

2. Berkomitmen untuk memberikan solusi yang bernilai tambah dengan

integritas, etika, dan layanan prima yang berstandar tinggi.

3. Terus berusaha untuk menjadi perusahaan idaman di Indonesia dengan

menghargai dan memberikan tantangan kepada karyawan kami.

Untuk mencapai visi dan misi di atas, PT XYZ memanfaatkan Sistem Informasi

(SI) dan Teknologi Informasi (TI). Salah satu SI yang dimiliki PT XYZ adalah

yang namanya disamarkan sebagai Sistem Informasi Asuransi Umum. Sistem

Informasi Asuransi Umum adalah SI core insurance, yaitu SI yang mampu

menangani seluruh proses bisnis perasuransian, antara lain: marketing,

underwriting, claim, finance, dan accounting. Sistem Informasi Asuransi Umum

bersifat key operational, yang berarti keberlangsungan bisnis PT XYZ bergantung

pada berjalannya Sistem Informasi Asuransi Umum.

Sistem Informasi Asuransi Umum dibangun oleh pihak ke-3, dan semenjak

operasionalnya Sistem Informasi Asuransi Umum di tahun 2006, semua kegiatan

pengembangan (development) perangkat lunak dan pemeliharaan (maintenance)


2

Universitas Indonesia

yang berkaitan dengan Sistem Informasi Asuransi Umum telah diserahkan

sepenuhnya kepada PT XYZ. Yang dimaksud dengan kegiatan pengembangan

perangkat lunak dan pemeliharaan di sini termasuk penambahan fitur

(pemeliharaan adaptif) dan perbaikan defect (pemeliharaan korektif). Penambahan

fitur dilakukan karena berubahnya proses bisnis PT XYZ sebagai penyesuaian

terhadap perubahan kondisi internal maupun eksternal perusahaan. Yang

dimaksud dengan perubahan kondisi internal adalah perubahan proses bisnis

karena alasan penyederhanaan proses bisnis organisasi. Yang dimaksud dengan

perubahan kondisi eksternal misalnya perubahan yang disebabkan bertambahnya

mitra bisnis yang perlu diintegrasikan proses bisnisnya ke dalam Sistem Informasi

Asuransi Umum.

1.2 Perumusan Masalah

Bagian ini menjelaskan harapan manajemen PT XYZ terhadap proses

pemeliharaan perangkat lunak yang dilakukannya, realita yang terjadi di lapangan,

dan identifikasi masalah yang terjadi karena adanya selisih antara harapan dan

realita tersebut.

1.2.1 Harapan Manajemen Terhadap Proses Pemeliharaan Perangkat Lunak

Berdasarkan hasil wawancara dengan manajer Departemen TI di PT XYZ

(Lampiran B J24-J31), untuk mencapai tujuan bisnisnya, Departemen TI diberikan

target untuk proses pemeliharaan perangkat lunak berdasarkan kategori aktivitas

dan prioritas sebagai berikut:

Tabel 1.1 Target Aktivitas Pemeliharaan Perangkat Lunak

No. Kategori Prioritas Target Penyelesaian

1. Korektif Tinggi 1 hari

2. Korektif Sedang 3 hari

3. Korektif Rendah 7 hari

4. Adaptif Tinggi 30 hari

5. Adaptif Sedang 60 hari

6. Adaptif Rendah 90 hari

(Sumber: Wawancara dengan Manajer Departemen TI, telah diolah kembali)


3


Kategori aktivitas pada Tabel 1.1 di atas dibuat berdasarkan wawancara, yang

kemudian dikategorikan berdasarkan SWEBOK V3.0 (Guide to the Software

Engineering Body of Knowledge, Version 3.0). Berdasarkan SWEBOK V3.0

(IEEE Computer Society, 2014), pemeliharaan perangkat lunak dikelompokkan

berdasarkan aktivitas proaktif dan reaktif. Aktivitas proaktif memiliki dua

kategori, yaitu: pencegahan dan penyempurnaan. Aktivitas reaktif dibagi dua

kategori, yaitu: korektif dan adaptif. Karena aktivitas pemeliharaan perangkat

lunak yang bersifat proaktif di PT XYZ tidak diukur, maka yang memiliki target

hanya kegiatan reaktif (korektif dan adaptif).

Jika suatu aktivitas dalam pemeliharaan perangkat lunak tidak memenuhi target

penyelesaian yang diharapkan oleh manajemen di Tabel 1.1, maka hal tersebut

akan menghambat penyelesaian kegiatan pemeliharaan perangkat lunak lainnya.

Semakin banyak kegiatan pemeliharaan perangkat lunak yang tidak memenuhi

target, semakin terhambat kegiatan bisnis PT XYZ, karena bisnis perusahaan

sangat bergantung terhadap SI. Dengan terhambatnya kegiatan bisnis, maka

semakin besar potensi tidak tercapainya visi dan misi yang sudah ditentukan oleh

PT XYZ.

1.2.2 Realita Proses Pemeliharaan Perangkat Lunak

Mulai tahun 2015, Departemen TI PT XYZ menggunakan SI untuk ticketing yang

digunakan untuk melakukan pencatatan permasalahan yang perlu ditanganinya.

Berikut adalah ringkasan data tiket yang direkam dalam SI ticketing tersebut yang

berkaitan dengan pemeliharaan perangkat lunak:

Tabel 1.2 Ringkasan Tiket Pemeliharaan Perangkat Lunak

Tahun Kategori Prioritas Waktu Penyelesaian (Dalam Hari)

≤ 1 ≤ 3 ≤ 7 ≤ 30 ≤ 60 ≤ 90 > 90

2015 Korektif Sedang 142 86 127* 135* 37* 24* 60*

2015 Adaptif Sedang 0 0 1 0 1 1* 5*

2015 Adaptif Tinggi 0 0 0 0 0 0 1*

2016 Korektif Sedang 356 222 187* 153* 35* 18* 35*

2016 Adaptif Sedang 1 0 0 0 0 0 1*

2017 Korektif Sedang 38 26 33* 20* 4* 0 0

2017 Adaptif Sedang 0 0 1 0 0 0 0

(Sumber: SI Ticketing Departemen TI 17 Februari 2017, telah diolah kembali)


4


Dalam tabel di atas, tiket-tiket yang terlambat diberikan simbol bintang (*). Data

di Tabel 1.2 menunjukkan banyaknya tiket-tiket yang tidak terselesaikan sesuai

dengan harapan manajemen yang tertuang dalam Tabel 1.1. Di tahun 2015, yang

terlambat adalah: 383 tiket korektif prioritas sedang, 6 tiket adaptif prioritas

sedang, dan 1 tiket adaptif prioritas tinggi. Di tahun 2016, yang terlambat adalah:

428 tiket korektif prioritas sedang dan 1 tiket adaptif prioritas sedang. Di tahun

berjalan 2017, ada 57 tiket korektif prioritas sedang yang terlambat. Data ini

berarti proses pemeliharaan perangkat lunak di Departemen TI belum bisa

mencapai target yang ditentukan oleh manajemen.

1.2.3 Identifikasi Masalah

Berdasarkan data permasalahan di atas, maka dilakukan analis akar masalah untuk

menemukan penyebab tidak terpenuhinya ekspektasi manajemen terhadap proses

pemeliharaan perangkat lunak. Hasil analisis akar masalah diilustrasikan pada

Gambar 1.1 di bawah:


5


Pemeliharaan

perangkat lunak

tidak mencapai target

Produk

perangkat lunak

Proses

pemeliharaan

Lingkungan

PenggunaPersonil

pemeliharaan

Learning curve

tinggi

Requirement

kurang jelasProses masih

bersifat reaktif

Progress tidak

transparan

Backlog

jarang di-update

Tugas yang

berganti-ganti

Prioritas tugas

kurang jelas

Prioritas tugas

kurang jelas

Tool kurang

mendukung pemantauan

Program comprehension

sulit

Belum ada

standar coding

Sulit dimodifikasi

Tidak ada

standar coding

Banyak modul

yang perlu dipelajari

Jumlah personil

sedikit

Gambar 1.1 Diagram Fishbone Analisis Akar Masalah


6


Domain-domain yang digunakan dalam analisis akar masalah pada Gambar 1.1

diambil dari Software Maintenance Framework (Grubb & Takang, 2003), yaitu:

pengguna, lingkungan, proses pemeliharaan, produk perangkat lunak, dan personil

pemeliharaan. Berikut penjelasan akar masalah masing-masing domain tersebut:

1.2.3.1 Pengguna

Untuk domain pengguna, masalah yang diidentifikasi adalah requirement yang

kurang jelas dan prioritas tugas yang kurang jelas. Jika requirement yang kurang

jelas, berarti hasil pengerjaannya berpotensi tidak sesuai dengan kebutuhan

pengguna, yang mengakibatkan perlunya pengerjaan ulang, dan berujung pada

terlambatnya penyelesaian tiket. Jika prioritas tugas kurang jelas, maka ada

potensi saat personil pemeliharaan mengerjakan tugas, prioritas tugas tersebut

diganti, yang mengakibatkan personil tersebut perlu berganti tugas, dan saat

kembali mengerjakan tugas awal tersebut harus melakukan program

comprehension lagi, yang berujung pada terlambatnya penyelesaian tiket.

1.2.3.2 Lingkungan

Tidak ada masalah yang berkaitan dengan domain lingkungan yang berhasil

diidentifikasi.

1.2.3.3 Proses Pemeliharaan

Untuk domain proses pemeliharaan, masalah yang diidentifikasi adalah proses

pemeliharaan yang masih bersifat reaktif, dan progress penyelesaian tiket tidak

transparan. Karena belum proses bersifat reaktif , belum mengetahui kelemahan

proses secara proaktif, maka perusahaan belum tahu area proses mana yang baik

dan mana yang buruk, yang berarti perusahaan tidak mengetahui strategi apa yang

perlu dilaksanakan untuk memperbaiki prosesnya agar target aktivitas

pemeliharaan perangkat lunak bisa dicapai. Penyebab tidak transparannya

progress adalah: maintenance backlog yang jarang di-update, dan tool yang

kurang mendukung pemantauan. Saat ini maintenance backlog hanya di-update

saat ada permintaan kepada manajer proyek Selain itu, tool yang digunakan untuk

mencatat progress maintenance backlog adalah spreadsheet Microsoft Excel, dan

project manager harus bertanya kepada masing-masing developer tentang


7


progress. Hal-hal ini mengakibatkan tidak transparannya progress, baik kepada

manajer proyek maupun kepada pengguna. Progress yang tidak transparan

menghambat pemantauan dan pengendalian proses, yang berarti sulitnya

menentukan kapan harus melakukan corrective action agar target pemeliharaan

perangkat lunak tercapai.

1.2.3.4 Produk Perangkat Lunak

Untuk domain produk perangkat lunak, masalah yang diidentifikasi adalah

learning curve yang tinggi dan sulitnya melakukan modifikasi. Produk perangkat

lunak yang pemeliharaannya ditangani oleh Departemen TI, terutama SI core

insurance yang bernama Sistem Informasi Asuransi Umum, memerlukan learning

curve yang tinggi baik untuk pengguna maupun personil pemeliharaan. Hal ini

disebabkan SI tersebut mengandung modul-modul yang mencerminkan proses

bisnis dari banyak departemen (marketing, underwriting, claim, reinsurance,

accounting, dan finance). Selain itu, produk perangkat lunak tersebut juga sulit

dimodifikasi oleh personil pemeliharaan karena tidak adanya standar coding.

Tidak adanya standar coding ini mengakibatkan personil pemeliharaan

memerlukan waktu yang lama untuk melakukan program comprehension. Hal-hal

ini dapat mengakibatkan terlambatnya penyelesaian tiket, yang menyebabkan

tidak tercapainya target aktivitas pemeliharaan perangkat lunak.

1.2.3.5 Personil Pemeliharaan

Untuk domain personil pemeliharaan, masalah yang diidentifikasi adalah: jumlah

personil yang sedikit, sulitnya program comprehension, dan tugas yang berganti-

ganti. Jumlah personil yang sedikit berarti menumpuknya tiket yang harus

dikerjakan. Sulitnya program comprehension berarti personil pemeliharaan

memerlukan waktu yang lama untuk mengerti source code produk perangkat

lunak sebelum bisa melakukan perubahan, baik yang bersifat korektif maupun

adaptif. Hal ini disebabkan tidak adanya standar coding. Tugas yang berganti-

ganti disebabkan oleh kurang jelasnya prioritas pengerjaan tiket. Semua hal-hal ini

berpotensi menyebabkan tidak tercapainya target pemeliharaan perangkat lunak.


8


1.3 Pertanyaan Penelitian

Berdasarkan hasil identifikasi masalah didapat beberapa akar masalah. Akar

masalah yang diangkat dalam karya akhir ini adalah proses yang masih bersifat

reaktif. Karya akhir ini akan mengidentifikasi kelemahan proses pemeliharaan

perangkat lunak saat ini dengan cara melakukan kajian tingkat kematangan proses

tersebut. Dalam penelitiannya, Jung & Goldenson (2009) menyatakan bahwa

tingkat kematangan proses yang lebih tinggi dapat menyebabkan kinerja

pemeliharaan perangkat lunak yang lebih baik. Dengan demikian, pertanyaan

penelitian karya akhir ini adalah: “Bagaimana kondisi kematangan proses

pemeliharaan perangkat lunak di PT XYZ? Dan bagaimana strategi

perbaikan proses pemeliharaan perangkat lunak yang tepat untuk PT

XYZ?”

1.4 Tujuan Penelitian

Tujuan dari penelitian ini adalah:

a. Menilai kematangan proses pemeliharaan perangkat lunak di PT XYZ.

b. Mengidentifikasi kelemahan proses pemeliharaan perangkat lunak di PT

XYZ.

c. Merekomendasikan strategi Software Process Improvement (SPI) yang tepat

untuk PT XYZ.

1.5 Manfaat Penelitian

Manfaat yang diharapkan dari penelitian ini adalah:

a. Sebagai rekomendasi kepada PT XYZ untuk bahan perbaikan proses

pemeliharaan perangkat lunaknya, untuk membantu pencapaian visi dan

misinya.

b. Sebagai referensi tambahan untuk penelitian akademis terkait SPI.

1.6 Ruang Lingkup Penelitian

Ruang lingkup dari penelitian ini adalah:


9


a. Penelitian dibatasi dengan lingkup proses pemeliharaan perangkat lunak SI

core insurance Sistem Informasi Asuransi Umum yang dilakukan oleh

Departemen Teknologi Informasi PT XYZ.

b. Data yang digunakan dalam penelitian dibatasi dengan lingkup 1 Januari

2015 sampai 17 Februari 2017.

c. Implementasi dari strategi SPI yang direkomendasikan dari penelitian ini

tidak dinilai dalam penelitian ini.

1.7 Sistematika Penulisan

Sistematika penulisan karya akhir ini disusun sebagai berikut:

BAB 1 PENDAHULUAN

Bab ini menjelaskan tentang latar belakang, identifikasi masalah,

pertanyaan penelitian, tujuan penelitian, manfaat penelitian, ruang

lingkup penelitian, dan sistematika penulisan karya akhir ini.

BAB 2 TINJAUAN PUSTAKA

Bab ini membahas landasan teori yang akan digunakan, penelitian-

penelitian sebelumnya, teori tentang metodologi penelitian akan yang

digunakan, dan kerangka teoritis penelitian ini.

BAB 3 METODOLOGI PENELITIAN

Bab ini menjelaskan langkah-langkah yang dilakukan dalam penelitian

ini, yang berupa masukan, proses, dan keluaran yang diharapkan. Bab ini

juga membahas kondisi organisasi tempat studi kasus dilakukan, yaitu PT

XYZ.

BAB 4 Rancangan dan Hasil Kajian KPA S3m

Bab ini membahas analisis yang dilakukan terhadap data yang sudah

dikumpulkan, penilaian tingkat kematangan, dan profil tingkat

kematangan yang dihasilkan dari penilaian tersebut.


10


BAB 5 Rekomendasi Perbaikan Proses Pemeliharaan Perangkat Lunak

Bab ini membahas rekomendasi strategi SPI yang dihasilkan dari analisis

terhadap data yang sudah dikumpulkan.

BAB 6 KESIMPULAN DAN SARAN

Bab ini menyimpulkan penelitian yang sudah dilakukan dan saran

penelitian ke depan.



BAB 2

TINJAUAN PUSTAKA

Bab ini membahas latar belakang, identifikasi masalah, pertanyaan penelitian,

ruang lingkup, tujuan, manfaat, dan sistematika penulisan karya akhir ini.

2.1 Perangkat Lunak

Menurut Pressman (2010, hal. 4), yang dimaksud dengan perangkat lunak adalah:

a. Kumpulan instruksi (program komputer) yang jika dieksekusi akan

menyediakan fungsi dan daya guna yang diinginkan.

b. Kumpulan struktur data yang memungkinkan program untuk memanipulasi

informasi secukupnya.

c. Informasi deskriptif baik dalam bentuk hard copy maupun formulir virtual

Kumpulan dokumen yang menggambarkan operasi dan penggunaan

program.

Menurut Sommerville (2011, hal. 6-7), terdapat dua jenis produk perangkat lunak:

a. Generic products, yang merupakan sistem stand-alone yang diproduksi oleh

organisasi pengembang dan dijual di pasar bebas kepada seluruh pelanggan

yang mampu membelinya.

b. Customized/bespoke products, merupakan sistem yang dibuat khusus atas

permintaan pelanggan tertentu.

Dalam konteks PT XYZ, SI core insurance yang dimilikinya termasuk ke kategori

perangkat lunak customized/bespoke product.

2.2 Software Process

Menurut Sommerville (2011, hal. 28) proses perangkat lunak (software process)

adalah sekumpulan aktivitas-aktivitas yang berhubungan yang berarah pada

produksi suatu produk perangkat lunak. Ada 4 aktivitas dasar yang umum pada

proses perangkat lunak (Sommerville, 2011, hal. 9), yaitu:


12


1. Software Specification (Spesifikasi Perangkat Lunak)

Klien dan pengembang mendefinisikan perangkat lunak yang akan

dihasilkan dan batasan-batasan operasinya.

2. Software Development (Pengembangan Perangkat Lunak)

Perangkat lunak dirancang dan diprogram.

3. Software Validation (Validasi Perangkat Lunak)

Perangkat lunak diperiksa dan dipastikan sudah sesuai dengan yang

dipersyaratkan klien.

4. Software Evolution (Evolusi Perangkat Lunak)

Perangkat lunak dimodifikasi untuk mencerminkan kebutuhan klien dan

pasar yang berubah.

Menurut Pressman (Pressman, 2010, hal. 14), proses perangkat lunak adalah

kerangka kerja untuk aktivitas, tindakan, dan tugas yang diperlukan untuk

membangun perangkat lunak berkualitas tinggi. Aktivitas bertujuan lebar,

misalnya komunikasi dengan pemangku kepentingan. Tindakan mencakup

sekumpulan tugas yang menghasilkan suatu produk kerja yang besar, misalnya

tindakan perancangan arsitektur menghasilkan rancangan model arsitektur. Tugas

berfokus pada tujuan kecil yang terdefinisi dengan baik yang memberikan hasil

nyata, contohnya melaksanakan unit test. Ada 5 aktivitas dalam kerangka kerja

proses rekayasa perangkat lunak generik (Pressman, 2010, hal. 15), yaitu:

1. Communication (Komunikasi)

Sebelum pekerjaan teknis apapun dimulai, sangat penting untuk

berkomunikasi dan kolaborasi dengan pemangku kepentingan lainnya.

Tujuannya adalah untuk memahami obyektif pemangku kepentingan untuk

proyek dan mengumpulkan requirement yang membantu untuk

mendefinisikan fitur dan fungsi dari perangkat lunak yang akan dibuat,

2. Planning (Perencanaan)

Membuat rencana proyek perangkat lunak (software project plan) yang

mendefinisikan pekerjaan rekayasa perangkat lunak dengan

menggambarkan tugas-tugas teknis yang harus dikerjakan, risiko yang


13


mungkin, sumber daya yang diperlukan, produk kerja yang akan dihasilkan,

dan jadwal pekerjaan.

3. Modeling (Pemodelan)

Membuat model untuk meningkatkan pemahaman terhadap requirement

perangkat lunak dan untuk membuat rancangan yang dapat memenuhi

requirement tersebut.

4. Construction (Konstruksi)

Aktivitas ini merupakan gabungan dari pembuatan kode (code generation)

baik secara manual maupun berotomasi, dan pengujian yang diperlukan

untuk menyingkapkan galat dalam kode.

5. Deployment (Penyebaran/Pemasangan)

Perangkat lunak baik sebagai entitas yang lengkap maupun peningkatan

yang sebagian selesai (partially completed increment) diserahkan kepada

klien yang mengevaluasi produk tersebut dan memberikan umpan balik.

Dalam konteks SI core insurance PT XYZ, dari definisi Sommerville, saat ini

aktivitas dasar dalam proses perangkat lunak yang dilakukan adalah evolusi

perangkat lunak.

2.3 Pemeliharaan Perangkat Lunak

Menurut Edelstein (1993, hal. 94), pemeliharaan perangkat lunak adalah

modifikasi dari sebuah produk perangkat lunak setelah delivery, untuk mengoreksi

kesalahan, untuk meningkatkan kinerja atau atribut lainnya, atau sebagai

penyesuaian produk terhadap perubahan lingkungan.

Dalam ISO/IEC 14764:2006, pemeliharaan perangkat lunak didefinisikan sebagai

keseluruhan aktivitas-aktivitas yang diperlukan untuk menyediakan dukungan

yang efektif biaya untuk suatu sistem perangkat lunak. Yang dimaksud dengan

keseluruhan adalah termasuk aktivitas sebelum delivery dan sesudah delivery.

Aktivitas pemeliharaan sebelum delivery antara lain: perencanaan operasi sesudah

delivery, dukungannya, dan penentuan logistiknya. Aktivitas pemeliharaan

sesudah delivery antara lain: modifikasi perangkat lunak, pelatihan, dan

mengoperasikan help desk (ISO/IEEE, 2006, hal. 4).


14


Berdasarkan ISO/IEC 14764:2006 dan SWEBOK V3.0, pemeliharaan perangkat

lunak dikategorikan sebagai berikut:

Tabel 2.1 Kategori-kategori Pemeliharaan Perangkat Lunak

Correction Enhancement

Proactive Preventive Perfective

Reactive Corrective Adaptive

Sumber: SWEBOK V3.0 (IEEE Computer Society, 2014, hal. 5-4)

Masing-masing kategori dari Tabel 2.1 di atas dijelaskan sebagai berikut (IEEE

Computer Society, 2014, hal. 5-3 -- 5-4):

a. Corrective Maintenance (Pemeliharaan Korektif), modifikasi atau perbaikan

yang bersifat reaktif yang dilakukan setelah delivery sebagai koreksi

terhadap masalah yang ditemukan.

b. Adaptive Maintenance (Pemeliharaan Adaptif), modifikasi produk

perangkat lunak setelah delivery untuk menjaga agar tetap dapat digunakan

dalam kondisi lingkungan yang berubah.

c. Perfective Maintenance (Pemeliharaan Penyempurnaan), modifikasi produk

perangkat lunak setelah delivery untuk memberikan peningkatan kepada

pengguna, meningkatkan dokumentasi program, dan coding ulang untuk

meningkatkan kinerja perangkat lunak, maintainability, atau atribut-atribut

perangkat lunak lainnya.

d. Preventive Maintenance (Pemeliharaan Pencegahan), modifikasi produk

perangkat lunak setelah delivery untuk mendeteksi dan koreksi kesalahan

laten, sebelum menjadi kesalahan operasional.

Menurut Sommerville (2011, hal. 242), pemeliharaan perangkat lunak adalah

proses umum untuk mengubah sistem setelah delivery. Menurut Sommerville ada

3 jenis pemeliharaan perangkat lunak:

1. Fault Repairs (Perbaikan Kesalahan), yaitu koreksi kesalahan baik

kesalahan coding, kesalahan perancangan, maupun kesalahan requirement.


15


2. Environmental Adaptation (Adaptasi Lingkungan), terjadi karena adanya

perubahan pada lingkungan dari sistem, seperti: perangkat keras, platform

sistem operasi, atau perangkat lunak pendukung lainnya.

3. Functionality Addition (Penambahan Fungsionalitas), terjadi karena sistem

harus menyesuaikan terhadap perubahan bisnis atau organisasional.

Dalam konteks PT XYZ, kategori pemeliharaan perangkat lunak berdasarkan

ISO/IEC 14764:2006 yang diukur adalah yang bersifat reaktif saja, yaitu korektif

dan adaptif. Semua jenis pemeliharaan perangkat lunak berdasarkan Sommerville

dilakukan di PT XYZ.

2.3.1 Software Maintenance Framework

Yang dimaksud dengan Software Maintenance Framework adalah konteks dan

lingkungan tempat terlaksananya aktivitas-aktivitas pemeliharaan perangkat

lunak. Elemen-elemen dari Software Maintenance Framework adalah: pengguna,

lingkungan, proses pemeliharaan, produk perangkat lunak, dan personil

pemeliharaan. Perubahan atau interaksi antara elemen-elemen tersebut

menyebabkan berevolusinya produk perangkat lunak, dan dengan demikian

menyebabkan timbulnya masalah pemeliharaan (Grubb & Takang, 2003, hal. 29).

Hubungan antara elemen-elemen tersebut diilustrasikan pada Gambar 2.1 di

bawah.


16


Maintenance

Process &Personnel

Organisational environment User environment

Operationalenvironment

Software

Indirect influence

Direct influence

Gambar 2.1 Hubungan Antar Elemen Pemeliharaan Perangkat Lunak

Sumber: (Grubb & Takang, 2003, hal. 30)

Tiga jenis hubungan besar yang dapat diidentifikasi dalam Software Maintenance

Framework adalah: produk dengan lingkungan, produk dengan pengguna, dan

produk dengan personil pemeliharaan. Berikut adalah penjelasan hubungan antara

masing-masing elemen tersebut (Grubb & Takang, 2003, hal. 29-31):

a. Hubungan antara produk dengan lingkungan terjadi karena produk

perangkat lunak tidak berdiri di ruang hampa, melainkan disokong oleh

lingkungan organisasi dan operasional.

b. Hubungan antara produk dengan pengguna terjadi karena salah satu tujuan

produk perangkat lunak adalah untuk memenuhi kebutuhan penggunanya.

c. Hubungan antara produk dengan personil pemeliharaan terjadi karena

personil pemeliharaan adalah medium terjadinya perubahan pada produk

perangkat lunak. Perubahan pada elemen-elemen seperti requirement

pengguna, proses pemeliharaan, atau lingkungan organisasi dan operasional,

akan menyebabkan perlunya perubahan pada produk perangkat lunak.

Namun produk perangkat lunak tidak akan berubah sampai personil


17


pemeliharaan mengimplementasikan perubahan tersebut. Jenis dari proses

pemeliharaan dan sifat dari personil pemeliharaan akan mempengaruhi

kualitas dari perubahan.

2.3.2 Proses Pemeliharaan Perangkat Lunak

Menurut April, Hayes, Abran, & Dumke (2005) banyak organisasi perangkat

lunak yang tidak memiliki proses-proses yang terdefinisi untuk kegiatan

pemeliharaan perangkat lunaknya. Menurut April & Abran (2009, hal. 73), hal ini

mengakibatkan manajemen yang bergaya krisis (crisis management style) dan

tidak terencananya pemeliharaan perangkat lunak.

Proses pemeliharaan perangkat lunak menyediakan aktivitas-aktivitas yang

dibutuhkan dalam pemeliharaan perangkat lunak, dan masukan atau keluaran yang

mendetail dari aktivitas-aktivitas tersebut. Proses pemeliharaan terdiri dari:

implementasi proses, analisis masalah dan modifikasi, implementasi modifikasi,

ulasan/penerimaan pemeliharaan, migrasi, dan retirement (ISO/IEEE, 2006, hal.

5).

Proses pemeliharaan dimulai dari implementasi proses di mana perencanaan untuk

pemeliharaan dilaksanakan dan berakhir dengan dipensiunkannya produk

perangkat lunak. Tujuan dari proses pemeliharaan perangkat lunak adalah untuk

memodifikasi perangkat lunak yang sudah ada dengan mempertahankan

integritasnya (ISO/IEEE, 2006, hal. 34).

Proses pemeliharaan perangkat lunak diilustrasikan dalam Gambar 2.2 sebagai

berikut:


18


Process Implementation

1

Migration5

Retirement6

Problem and Modification Analysis

2

Maintenance Review/Acceptance

4

Modification Implementation

3

Gambar 2.2 Proses Pemeliharaan

Sumber: ISO/IEC 14764:2006 (ISO/IEEE, 2006, hal. 6)

Berikut adalah penjelasan masing-masing elemen dalam proses pemeliharaan

perangkat lunak:

1. Process Implementation (Implementasi Proses)

Dalam implementasi proses, maintainer menyusun rencana-rencana dan

prosedur-prosedur yang akan dieksekusi selama proses pemeliharaan

perangkat lunak. Rencana pemeliharaan perangkat lunak seharusnya dibuat

secara paralel dengan rencana pengembangan perangkat lunak. Dalam

aktivitas ini maintainer juga seharusnya membuat hubungan organisasi yang

diperlukan.

2. Problem and Modification Analysis (Analisis Masalah dan Modifikasi)

Aktivitas ini dan aktivitas-aktivitas sesudahnya diaktifkan setelah serah

terima perangkat lunak, dan akan dilaksanakan secara iteratif jika

diperlukan.

3. Modification Implementation (Implementasi Modifikasi)

Dalam aktivitas ini maintainer mengembangkan dan menguji modifikasi

untuk produk perangkat lunak.

4. Maintenance Review/Acceptance (Ulasan/Penerimaan Pemeliharaan)


19


Aktivitas ini memastikan bahwa modifikasi terhadap sistem sudah benar dan

dilaksanakan sesuai dengan standar yang sudah disetujui dan menggunakan

metodologi yang benar.

5. Migration (Migrasi)

Sistem mungkin harus dimodifikasi agar bisa dijalankan di lingkungan yang

berbeda. Untuk memindahkan sistem ke lingkungan yang berbeda,

maintainer perlu menentukan tindakan-tindakan yang diperlukan agar

migrasi sukses, dan kemudian mengembangkan dan mendokumentasikan

langkah-langkah yang diperlukan untuk melaksanakan migrasi.

6. Retirement (Pensiun)

Saat perangkat lunak sudah mencapai akhir dari daur hidup bergunanya,

maka perangkat lunak tersebut harus dipensiunkan (retired). Diperlukan

analisis untuk membantu mengambil keputusan untuk memensiunkan

perangkat lunak. Analisis ini biasanya berupa analisis nilai ekonomi dan

bisa dimasukkan ke dalam rencana retirement. Produk perangkat lunak bisa

diganti dengan produk lain, namun dalam beberapa kasus tidak akan diganti.

Maintainer perlu mempertimbangkan cara untuk mengakses data dari

produk perangkat lunak yang dipensiunkan tersebut.

2.4 Software Process Improvement (SPI)

SPI adalah sebuah program kerja yang dirancang untuk meningkatkan kinerja dan

kematangan dari proses pengembangan perangkat lunak sebuah organisasi dan

programnya. Tujuan SPI adalah agar organisasi bisa mencapai tujuan bisnis

utamanya seperti memasarkan perangkat lunaknya secara lebih cepat, mengurangi

atau menghapus proses yang tidak penting (O'Regan, 2011).

SPI adalah suatu model framework (kerangka kerja) yang bertujuan untuk

meningkatkan kualitas dari produk perangkat lunak yang dibangun dengan

memperbaiki proses pengembangan menjadi lebih baik, yang kemudian

menghasilkan pembiayaan produksi yang lebih efisien serta mempercepat waktu

untuk memasarkan (time to market). Industri perangkat lunak sudah menyadari

bahwa SPI sangat memberikan kesuksesan yang sangat memberikan perubahan


20


yang signifikan dalam membantu suksesnya proyek pengembangan perangkat

lunak (Unterkalmsteiner, Gorschek, Islam, Cheng, Permadi, & Feldt, 2012).

Softwareprocess

Assessment

Capability determination

Improvement strategy

Is examined

by

Identifies capabilities, strengths, and weaknesses of

Identifies changes to

Identifies maturity ofSuggests improvement approach for

Leads to Leads to

Is a foundation for

Gambar 2.3 Elemen-elemen Kerangka Kerja SPI

Sumber: (Pressman, 2010, hal. 788)

Kerangka kerja SPI pada Gambar 2.3 di atas mendefinisikan (Pressman, 2010, hal.

787):

a. Sekumpulan karakteristik yang harus ada jika ingin mencapai proses

perangkat lunak yang efektif.

b. Metode untuk memeriksa keberadaan karakteristik-karakteristik tersebut.

c. Mekanisme untuk meringkas hasil pemeriksaan.

d. Strategi untuk membantu organisasi perangkat lunak dalam

mengimplementasikan karakteristik-karakteristik proses yang masih lemah

atau yang belum ditemukan.

2.5 Capability Maturity Model Integration for Development (CMMI-DEV)

Kerangka kerja SPI memiliki beberapa model yang sering digunakan, salah

satunya adalah Capability Maturity Model Integration (CMMI) oleh Software

Engineering Institute (SEI). CMMI dapat digunakan sebagai kumpulan

karakteristik suatu proses pengembangan perangkat lunak, yang kemudian dapat


21


juga dijadikan sebagai metode untuk melakukan penilaian dari proses yang

berjalan. Hasil dari penilaian tersebut disebut dapat dijadikan sebagai acuan untuk

memandu organisasi untuk membuat suatu strategi SPI.

Menurut de Vasconcelos, de la Vara, Sánchez, & Pastor (2012, hal. 194), CMMI-

DEV adalah panduan untuk perbaikan proses yang berkesinambungan dalam

mengembangkan produk atau layanan. CMMI-DEV adalah salah satu model

kematangan (maturity model) yang paling banyak digunakan.

Penekanan CMMI-DEV adalah pada pekerjaan yang diperlukan untuk

membangun dan merawat produk secara keseluruhan. CMMI-DEV mencakup

praktek-praktek untuk seluruh daur hidup produk, mulai dari konsepsi, delivery,

sampai pemeliharaan (CMMI Product Team, 2010, hal. 3). CMMI-DEV

mencakup manajemen proyek, manajemen proses, rekayasa sistem (systems

engineering), rekayasa perangkat lunak (hardware engineering), rekayasa

perangkat lunak (software engineering), dan proses-proses pendukung lainnya

yang digunakan dalam pengembangan dan pemeliharaan (CMMI Product Team,

2010, hal. 8).

Ada 4 domain proses dalam CMMI-DEV:

1. Process Management

Domain proses ini mencakup aktivitas-aktivitas lintas proyek yang

berhubungan dengan mendefinisikan, perencanaan, deploying,

implementasi, pemantauan, pengendalian, penilaian, pengukuran, dan

peningkatan proses-proses. Area-area prosesnya adalah: Organizational

Process Definition (OPD), Organizational Process Focus (OPF),

Organizational Performance Management (OPM), Organizational Process

Performance (OPP), dan Organizational Training (OT).

2. Project Management

Domain proses ini mencakup aktivitas-aktivitas manajemen proyek yang

berhubungan dengan perencanaan, pemantauan, dan pengendalian proyek.

Area-area prosesnya adalah: Integrated Project Management (IPM), Project

Monitoring and Control (PMC), Project Planning (PP), Quantitative


22


Project Management (QPM), Requirements Management (REQM), Risk

Management (RSKM), dan Supplier Agreement Management (SAM).

3. Engineering

Domain proses ini mencakup aktivitas-aktivitas pengembangan dan

pemeliharaan. Area-area prosesnya adalah: Product Integration (PI),

Requirements Development (RD), Technical Solution (TS), Validation

(VAL), dan Verification (VER).

4. Support

Domain proses ini mencakup aktivitas-aktivitas yang mendukung

pengembangan dan pemeliharaan. Area-area prosesnya adalah: Causal

Analysis and Resolution (CAR), Configuration Management (CM),

Decision Analysis and Resolution (DAR), Measurement and Analysis (MA),

dan Process and Product Quality Assurance (PPQA).

Ada 22 Process Area (PA) dalam CMMI-DEV (CMMI Product Team, 2010):

1. Causal Analysis and Resolution (CAR)

Tujuan dari CAR adalah untuk mengidentifikasi penyebab dari suatu akibat

dan mengambil tindakan untuk meningkatkan kinerja proses.

2. Configuration Management (CM)

Tujuan dari CM adalah untuk membuat dan menjaga integritas dari produk

kerja menggunakan identifikasi konfigurasi, kendali konfigurasi, accounting

status konfigurasi, dan audit konfigurasi.

3. Decision Analysis and Resolution (DAR)

Tujuan dari DAR adalah untuk menganalisis keputusan-keputusan yang

dimungkinkan dengan menggunakan proses evaluasi formal yang

mengevaluasi alternatif-alternatif yang telah teridentifikasi terhadap kriteria-

kriteria yang telah ditentukan.

4. Integrated Project Management (IPM)

Tujuan dari IPM adalah untuk menyusun dan mengatur proyek dan

keterlibatan para pemangku kepentingan yang relevan berdasarkan suatu

proses yang terintegrasi yang terdefinisi yang telah disesuaikan (tailored)

dari kumpulan proses-proses standar organisasi tersebut.


23


5. Measurement and Analysis (MA)

Tujuan dari MA adalah untuk mengembangkan dan menyokong suatu

kemampuan untuk mengukur yang digunakan untuk mendukung kebutuhan

informasi pihak manajemen.

6. Organizational Process Definition (OPD)

Tujuan dari OPD adalah untuk menyusun dan memelihara sekumpulan aset

proses organisasi, standar lingkungan kerja, dan aturan dan pedoman

(guidelines) yang dapat digunakan oleh tim.

7. Organizational Process Focus (OPF)

Tujuan dari OPF adalah untuk merencanakan, mengimplementasikan, dan

menyebarkan perbaikan-perbaikan dari proses-proses organisasi

berdasarkan pada pemahaman yang mendalam dari kekuatan dan kelemahan

saat ini pada proses-proses organisasi dan aset-aset prosesnya.

8. Organizational Performance Management (OPM)

Tujuan dari OPM adalah untuk mengatur kinerja organisasi secara proaktif

untuk memenuhi tujuan-tujuan bisnisnya.

9. Organizational Process Performance (OPP)

Tujuan dari OPP adalah untuk menyusun dan memelihara pemahaman

kuantitatif dari kinerja proses-proses terpilih dalam kumpulan proses standar

organisasi dalam mendukung pencapaian tujuan kualitas dan kinerja proses,

dan untuk menyediakan data kinerja proses, baseline, dan model-model

untuk mengatur proyek-proyek organisasi secara kuantitatif.

10. Organizational Training (OT)

Tujuan dari OT adalah untuk mengembangkan keterampilan dan

pengetahuan dari orang-orang sehingga mereka bisa melaksanakan perannya

secara efektif dan efisien.

11. Product Integration (PI)

Tujuan dari PI adalah untuk merakit produk dari komponen-komponen

produk, memastikan bahwa produk yang terintegrasi sudah berperilaku

benar (yaitu memiliki fungsionalitas dan atribut-atribut kualitas yang

dipersyaratkan), dan men-deliver produk.

12. Project Monitoring and Control (PMC)


24


Tujuan dari PMC adalah untuk menyediakan pemahaman tentang progres

proyek sehingga tindakan korektif (corrective actions) yang tepat dapat

diambil saat kinerja proyek menyimpang secara signifikan dari yang

direncanakan.

13. Project Planning (PP)

Tujuan dari PP adalah untuk menyusun dan memelihara rencana-rencana

yang mendefinisikan aktivitas-aktivitas proyek.

14. Process and Product Quality Assurance (PPQA)

Tujuan dari PPQA adalah untuk menyediakan wawasan (insight) proses-

proses dan produk kerja yang berkaitan, kepada staf dan manajemen.

15. Quantitative Project Management (QPM)

Tujuan dari QPM adalah untuk mengatur secara kuantitatif proyek-proyek

untuk mencapai tujuan kualitas proyek dan kinerja proses yang telah

ditentukan.

16. Requirements Development (RD)

Tujuan dari RD adalah untuk memancing, menganalisis, dan menyusun

persyaratan pelanggan, produk, dan komponen produk.

17. Requirements Management (REQM)

Tujuan dari REQM adalah untuk mengatur persyaratan dari produk proyek

dan komponen produk untuk memastikan keselarasan antara persyaratannya

dengan rencana proyek dan produk kerja.

18. Risk Management (RSKM)

Tujuan dari RM adalah untuk mengidentifikasi potensi masalah sebelum

terjadi, sehingga aktivitas penanganan risiko dapat direncanakan dan

dilaksanakan saat dibutuhkan di sepanjang umur produk atau proyek, untuk

memitigasi dampak buruknya terhadap pencapaian tujuan.

19. Supplier Agreement Management (SAM)

Tujuan dari SAM adalah untuk mengatur akuisisi produk dan layanan dari

pemasok.

20. Technical Solution (TS)

Tujuan dari TS adalah untuk memilih, merancang, dan

mengimplementasikan solusi dari persyaratan. Solusi, rancangan, dan


25


implementasi mencakup produk, komponen produk, dan proses-proses yang

berkaitan dengan siklus hidup produk.

21. Validation (VAL)

Tujuan dari VAL adalah untuk mendemonstrasikan bahwa produk atau

komponen produk memenuhi penggunaan yang semestinya (intended use),

pada saat ditempatkan pada lingkungan yang semestinya (intended

environment).

22. Verification (VER)

Tujuan dari VER adalah untuk memastikan bahwa produk kerja yang

terpilih sudah memenuhi persyaratan-persyaratan yang sudah ditentukan.

Ada dua representasi dalam CMMI-DEV, yaitu bertingkat (staged) dan

berkelanjutan (continuous). Perbedaan utama antara Staged Representation dan

Continuous Representation terletak pada PA yang dinilai. Pada Staged

Representation, semua area proses yang terdapat dalam satu tingkat kematangan

harus dipenuhi, sedangkan pada Continuous Representation area proses yang

dipenuhi dipilih tergantung pada kebutuhan organisasi.

2.5.1 Representasi Bertingkat (Staged Representation)

Representasi ini menggunakan tingkat kematangan (Maturity Level) untuk

mengukur perbaikan proses. Tingkat kematangan ini diterapkan pada organisasi

secara keseluruhan. Representasi ini memiliki 5 tingkat kematangan (CMMI

Product Team, 2010, hal. 27-29; Chrissis, Konrad, & Shrum, 2011, hal. 42-44),

yaitu:

1. Maturity Level 1: Initial

Pada tingkat kematangan 1, proses-proses biasanya ad hoc dan kacau.

Organisasi biasanya tidak menyediakan lingkungan yang stabil untuk

mendukung proses. Kesuksesan organisasi bergantung pada kompetensi dan

heroik dari orang-orang dalam organisasi dan bukan karena penggunaan

proses yang terbukti. Biarpun kacau, organisasi tingkat kematangan 1 sering

menghasilkan produk dan layanan yang bisa digunakan, tapi sering

melampaui anggaran dan jadwal yang terdokumentasi dalam rencana.


26


2. Maturity Level 2: Managed

Pada tingkat kematangan 2, proyek-proyek sudah memastikan bahwa

proses-proses sudah direncanakan dan dieksekusi sesuai dengan kebijakan,

proyek mempekerjakan orang yang berkeahlian dan memiliki sumber daya

yang memadai untuk menghasilkan keluaran yang terkendali, melibatkan

pemangku kepentingan yang relevan, dimonitor, dikendalikan, dan ditinjau,

dan dievaluasi kepatuhannya terhadap gambaran proses. Disiplin proses

yang dicerminkan dari tingkat kematangan 2 membantu untuk memastikan

bahwa praktek-praktek yang sudah ada terjaga saat organisasi mengalami

tekanan. Saat praktek-praktek ini terjaga, proyek-proyek dilakukan dan

dikelola sesuai dengan dokumentasi rencananya.

3. Maturity Level 3: Defined

Proses terkarakterisasi dengan baik dan dipahami, dan digambarkan dalam

standar, prosedur, tool, dan metode-metode. Kumpulan proses standar

organisasi, yang merupakan dasar dari tingkat kematangan 3, dibuat dan

ditingkatkan seiring waktu. Proses-proses standar ini digunakan untuk

membuat konsistensi di seluruh organisasi. Proyek-proyek membuat proses

terdefinisinya dengan menyesuaikan dari kumpulan proses standar

organisasi berdasarkan panduan penyesuaian.

4. Maturity Level 4: Quantitatively Managed

Pada tingkat kematangan 4, organisasi dan proyek-proyek membuat tujuan

kuantitatif untuk kualitas dan kinerja proses dan menggunakannya sebagai

kriteria dalam pengelolaan proyek. Tujuan kuantitatif berdasar pada

kebutuhan pelanggan, pengguna akhir, organisasi, dan pengimplementasi

proses. Kualitas dan kinerja proses dipahami sebagai istilah-istilah statistik

dan dikelola sepanjang berjalannya proyek.

5. Maturity Level 5: Optimizing

Pada tingkat kematangan 5, organisasi memperbaiki prosesnya secara

berkesinambungan berdasarkan pada pemahaman kuantitatif dari tujuan

bisnisnya dan kebutuhan kinerjanya. Organisasi menggunakan pendekatan

kuantitatif untuk memahami variasi yang inheren dalam proses dan

penyebab dari hasil proses.


27


2.5.2 Representasi Berkelanjutan (Continuous Representation)

Representasi ini menggunakan tingkat kemampuan (Capability Level) untuk

mengukur perbaikan proses. Tingkat kemampuan diterapkan pada masing-masing

area proses. Representasi ini memiliki 5 tingkat kemampuan (CMMI Product

Team, 2010, hal. 24-25; Chrissis, Konrad, & Shrum, 2011, hal. 35-36):

1. Capability Level 0: Incomplete

PA belum diterapkan atau diterapkan sebagian. Satu atau lebih specific goal

dari PA tidak terpenuhi dan tidak ada generic goal yang ada untuk tingkat

ini karena tidak ada alasan untuk menginstitusikan (institutionalize) proses

yang dilakukan sebagian.

2. Capability Level 1: Performed

Proses yang terlaksana (performed process) adalah proses yang

menyelesaikan pekerjaan untuk menghasilkan produk kerja. Specific goal

dari PA terpenuhi.

3. Capability Level 2: Managed

Proses yang dikelola (managed process) adalah proses yang dilakukan

terencana dan dieksekusi sesuai dengan kebijakan, mempekerjakan orang

yang berkeahlian yang memiliki sumber daya yang memadai untuk

menghasilkan keluaran yang terkendali, melibatkan pemangku kepentingan

yang relevan, dipantau, dikendalikan, dan ditinjau, dan dievaluasi

kepatuhannya terhadap gambaran proses.

4. Capability Level 3: Defined

Proses yang terdefinisi (defined process) adalah proses yang dikelola yang

disesuaikan (tailored) dari kumpulan proses standar milik organisasi

berdasarkan panduan penyesuaian dari organisasi, memiliki gambaran

proses, dan berkontribusi terhadap pengalaman yang berkaitan dengan

proses terhadap aset proses organisasi.

2.6 Software Maintenance Maturity Model (S3m)

S3m adalah model dengan lingkup proses-proses pemeliharaan yang langsung di

bawah kendali organisasi. Organisasi dapat menggunakan S3m untuk memulai dan

mempertahankan program perbaikan yang berkesinambungan (continuous


28


improvement) dengan awalnya dengan melakukan perbandingan (benchmarking)

praktek-praktek pemeliharaan perangkat lunak mereka terhadap model ini. Hal ini

akan membantu organisasi pemeliharaan perangkat lunak mengidentifikasi

kekuatan dan kelemahannya dalam memberikan layanan pemeliharaan perangkat

lunak. Dengan mengidentifikasi kesenjangan, organisasi pemeliharaan dapat

mengidentifikasi, melalui perbandingan dengan model, masalah-masalah apa yang

perlu ditangani dan bagaimana menanganinya, dan dengan demikian

meningkatkan proses pemeliharaan perangkat lunaknya (April & Abran, 2008,

hal. 69).

Skop dari model S3m terbatas untuk aktivitas-aktivitas pemeliharaan yang kecil,

dan model proses ini tidak tepat untuk proyek-proyek pemeliharaan perangkat

lunak dengan skop yang lebih besar, yang seharusnya dikelola sebagai proyek

dengan teknik-teknik manajemen proyek. Untuk beban kerja yang memerlukan

keahlian dan teknik-teknik manajemen proyek, sebaiknya CMMI dan model

kematangan lain (April & Abran, 2008, hal. 70).

S3m terdiri dari 4 domain proses, 18 Key Process Area (KPA), dan 196 praktek-

praktek (exemplary practices). Struktur S3m diilustrasikan sebagai berikut:


29


S3m

Process Management

Event/Request Management

Evolution Engineering

Support to Evolution

Engineering

Pro1 Pro2 Pro3 Pro4 Pro5 Req1 Req2 Req3 Req4 Evo1 Evo2 Evo3 Evo4 Sup1 Sup2 Sup3 Sup4 Sup5

Pro1.0.1

Pro1.1.1

Pro1.1.2

Pro1.2.1

Pro1.2.2

Pro1.2.3

Pro1.2.4

Pro1.2.5

Pro1.2.6

Pro1.2.7

Pro1.2.8

Pro1.2.9

Pro1.2.10

Pro1.2.11

Pro2.0.1

Pro2.1.1

Pro2.1.2

Pro2.2.1

Pro2.2.2

Pro2.2.3

Pro2.2.4

Pro3.0.1

Pro3.1.1

Pro3.1.2

Pro3.2.1

Pro3.2.2

Pro3.2.3

Pro3.2.4

Pro3.2.5

Pro3.2.6

Pro3.2.7

Pro3.2.8

Pro3.2.9

Pro3.2.10

Pro3.2.11

Pro3.2.12

Pro3.2.13

Pro3.1.3

Pro4.0.1

Pro4.1.1

Pro4.1.2

Pro4.2.1

Pro4.2.2

Pro4.2.3

Pro5.0.1

Pro5.1.1

Pro5.1.2

Pro5.2.1

Pro5.2.2

Pro5.2.3

Pro5.1.3

Pro5.0.2

Pro5.0.3

Req1.0.1

Req1.1.1

Req1.1.2

Req1.2.1

Req1.2.2

Req1.2.3

Req1.2.4

Req2.0.1

Req2.1.1

Req2.1.2

Req2.2.1

Req2.2.2

Req2.2.3

Req2.2.4

Req2.2.5

Req2.2.6

Req2.2.7

Req2.2.8

Req2.2.9

Req2.2.12

Req2.2.13

Req2.1.3

Req2.2.14

Req2.2.15

Req2.2.16

Req2.2.17

Req2.2.18

Req2.2.19

Req2.2.20

Req2.2.10

Req2.2.11

Req3.0.1

Req3.1.1

Req3.2.1

Req3.2.2

Req3.2.3

Req3.2.4

Req3.2.5

Req3.2.6

Req4.0.1

Req4.1.1

Req4.2.1

Req4.2.2

Req4.2.3

Req4.2.4

Req4.2.5

Req4.2.6

Req4.2.7

Req4.2.8

Req4.2.9

Req4.2.12

Req4.2.13

Req4.2.10

Req4.2.11

Evo1.0.1

Evo1.1.1

Evo1.2.1

Evo1.2.2

Evo1.2.3

Evo1.2.4

Evo1.2.5

Evo1.2.6

Evo1.2.7

Evo1.2.8

Evo1.2.9

Evo1.2.10

Evo1.2.11

Evo2.0.1

Evo2.1.1

Evo2.2.1

Evo2.2.2

Evo2.2.3

Evo2.2.4

Evo2.2.5

Evo2.2.6

Evo3.0.1

Evo3.1.1

Evo3.2.1

Evo3.2.2

Evo3.2.3

Evo3.2.4

Evo3.2.5

Evo3.2.6

Evo3.2.7

Evo3.2.8

Evo3.2.9

Evo3.2.10

Evo3.2.11

Evo4.0.1

Evo4.1.1

Evo4.2.1

Evo4.2.2

Evo4.2.3

Evo4.2.4

Evo4.2.5

Evo4.2.6

Evo4.2.7

Evo4.2.8

Sup1.0.1

Sup1.1.1

Sup1.2.1

Sup1.2.2

Sup1.2.3

Sup1.2.4

Sup1.2.5

Sup1.2.6

Sup1.2.7

Sup1.2.8

Sup2.0.1

Sup2.1.1

Sup2.2.1

Sup2.2.2

Sup2.2.3

Sup2.2.4

Sup2.2.5

Sup2.2.6

Sup2.2.7

Sup2.2.8

Sup2.2.9

Sup2.2.12

Sup2.2.13

Sup2.2.10

Sup2.2.11

Sup3.0.1

Sup3.1.1

Sup3.2.1

Sup3.2.2

Sup4.0.1

Sup4.1.1

Sup4.2.1

Sup4.2.2

Sup4.2.3

Sup4.2.4

Sup5.0.1

Sup5.1.1

Sup5.1.2

Sup5.2.1

Sup5.2.2

Sup5.2.3

Sup5.2.4

Sup5.2.5

Sup5.2.6

Sup5.2.7

Process Domains

(4)

Key Process Areas (18)

Level 0 Practices

(20)

Level 1 Practices

(29)

Level 2 Practices

(147)

Gambar 2.4 Struktur S3m Berdasarkan Deskripsi April & Abran (2008)


30


KPA dalam S3m dikelompokkan dalam 4 domain proses, yaitu:

1. Process Management, sistem manajemen untuk proses-proses pemeliharaan

perangkat lunak yang baik harus memenuhi semua kriteria pelayanan

pelanggan dan domain teknis. KPA-nya adalah: Pro1, Pro2, Pro3, Pro4, dan

Pro5.

2. Event/Request Management, sistem manajemen untuk pemeliharaan

perangkat lunak yang baik harus memenuhi semua kriteria SLA dan domain

teknis. KPA-nya adalah: Req1, Req2, Req3, dan Req4.

3. Evolution Engineering, mencakup kegiatan sebelum delivery, transisi,

dukungan operasional, dan layanan koreksi dan evolusi, dam verifikasi dan

validasi. KPA-nya adalah: Evo1, Evo2, Evo3, dan Evo4.

4. Support for the Evolution Engineering, mencakup kegiatan-kegiatan untuk

mendukung domain proses Evolution Engineering. KPA-nya adalah: Sup1,

Sup2, Sup3, Sup4, dan Sup5.

Domain proses Project Management dalam CMMI kontras terhadap

Event/Request Management dalam S3m. April & Abran (2008, hal. 76)

berargumen bahwa penamaan domain proses Project Management adalah karena

CMMI berfokus pada pengembangan perangkat lunak, sedangkan karena S3m

berfokus pada pemeliharaan maka penamaan Event/Request Management lebih

cocok sebab aktivitas-aktivitas pemeliharaan perangkat lunak lebih berupa

permintaan-permintaan kecil, bukan proyek-proyek besar. (Paquette, April, &

Abran (2006) berpendapat bahwa skop S3m terbatas untuk aktivitas pemeliharaan

berskala kecil, dan model ini tidak cocok untuk proyek pemeliharaan perangkat

lunak dengan skop yang lebih besar yang memerlukan teknik-teknik manajemen

proyek. April & Abran (2008, hal. 77) juga berargumen bahwa domain proses

Engineering dan Support dalam CMMI-DEV lebih berfokus kepada konsepsi

perangkat lunak, bukan terhadap perubahannya (evolusinya).

Ada 18 KPA dalam S3m (April & Abran, 2008, hal. 79), yaitu:

1. Maintenance Process Focus (Pro1)


31


KPA ini membantu organisasi dalam merencanakan perbaikan yang

berkelanjutan dengan mengumpulkan informasi dari: pelanggan, personil

pemeliharaan, kebutuhan personil pemeliharaan terhadap pengetahuan dan

kompetensi tambahan, kinerja saat ini dari proses-proses pemeliharaan,

kekuatan/kelemahan dari teknik-teknik dan tools pemeliharaan saat ini,

lingkungan kerja pemeliharaan secara keseluruhan, dan terakhir, umpan

balik dari antar muka pemeliharaan perangkat lunak.

2. Maintenance Process/Service Definition (Pro2)

Informasi dari KPA Pro1 dinilai dan diulas untuk meningkatkan kinerja dari

personil pemeliharaan dalam tugas sehari-harinya.

3. Maintenance Training (Pro3)

Mengidentifikasi kebutuhan strategis untuk pendidikan dan pelatihan,

dengan berfokus pada proses-proses dan juga pada aspek-aspek teknis.

4. Maintenance Process Performance (Pro4)

Menyusun tujuan kuantitatif untuk: tingkat kualitas dan kinerja dari

eksekusi dari proses-proses pemeliharaan, produk perangkat lunak dalam

operasi, dan produk-produk sementara (artifak) dari pemeliharaan perangkat

lunak. Melalui KPA ini, organisasi memastikan koordinasi dengan unit

organisasi SI/TI lainnya tentang implementasi dari: tujuan dari ukuran

proses/produk, definisi dari ukuran proses/produk, titik acuan (baseline)

untuk ukuran-ukuran tersebut, repository, dan penggunaan ukuran-ukuran

dalam model prediksi kinerja.

5. Maintenance Innovation and Deployment (Pro5)

Mengelompokkan praktek-praktek untuk memilih dan menyebarkan proyek-

proyek inovasi dan perbaikan. Sasaran dari proyek-proyek ini adalah untuk

meningkatkan kemampuan organisasi dalam memenuhi tujuan SLA untuk

kualitas dan kinerja proses.

6. Event/Request Management (Req1)

Merupakan titik masuk, melalui help desk, untuk komunikasi dengan para

pengguna. Segala jenis permintaan pengguna (dukungan operasional, MR,

atau PR) ditangani melalui KPA ini. KPA ini akan mengidentifikasi

prioritas pelanggan dengan cepat, dan menguasai proses penanganan


32


masalah dari organisasi. Tujuan dari KPA ini adalah untuk memastikan

bahwa proses-proses pemeliharaan perangkat lunak memenuhi tujuan SLA

kualitas/layanan yang sudah disepakati.

7. Maintenance Planning (Req2)

Merencanakan alokasi sumber daya terhadap permintaan individual dan

untuk menangani prioritas yang cepat berubah-ubah. KPA ini menangani

permintaan dari: pelanggan dan pengguna, tim-tim pengembangan,

subkontraktor, dan operasional komputer. Setelah diberikan prioritas dan

diotorisasi, maka butir-butir pekerjaan akan diserahkan kepada personil

pemeliharaan.

8. Request/Software Monitoring and Control (Req3)

Mengidentifikasi butir-butir pekerjaan yang perlu dikendalikan dan butir-

butir pekerjaan individual yang ditugaskan kepada sumber daya yang saat

ini lagi dalam proses.

9. SLA and Supplier Agreement Management (Req4)

Mengidentifikasi tingkat-tingkat kualitas dan kebutuhan sumber daya, dan

menegosiasikan harga-harga dengan pelanggan dan mitra-mitra layanan

(service partners). Dalam KPA ini, layanan-layanan pemeliharaan

perangkat lunak digambarkan dan dijelaskan untuk memastikan pelanggan

mengerti dan puas dengan persetujuan yang dicapai. Maintenance engineers

juga perlu memastikan bahwa para pemasok menyediakan kemitraan yang

memiliki nilai tambah dan ikut serta dalam usaha memenuhi target SLA.

10. Predelivery and Transition Services (Evo1)

Merupakan kontak pertama dari para maintenance engineer dengan

perangkat lunak yang nantinya akan mereka rawat. Tujuan utama dari KPA

ini adalah untuk meningkatkan pemahaman dari para maintainer tentang

produk perangkat lunak, dan untuk mencoba mempengaruhi maintainability

dari perangkat lunak saat masih dalam tahap pengembangan (jika

dimungkinkan).

11. Operational Support Services (Evo2)

Menangani permintaan layanan yang tidak terpecahkan oleh para pengguna

super atau petugas help desk. Pengguna super adalah nama yang diberikan


33


kepada pengguna yang ditugaskan untuk mendukung dan melatih pengguna

lainnya dari produk perangkat lunak. KPA ini tidak memodifikasi perangkat

lunak, melainkan memberikan layanan konsultasi seperti:

a. Menarik informasi dari sistem-sistem yang sudah ada.

b. Membuat informasi teknis dan penyuluhan kepada para pengembang

dan tim operasional.

c. Menyediakan bantuan kepada pelanggan untuk lebih memahami

perangkat lunak, transaksi, data, atau dokumentasinya.

12. Software Evolution and Correction Services (Evo3)

KPA ini menyediakan modifikasi terhadap perangkat lunak. Para

programmer pemeliharaan perlu melakukan analisis dampak modifikasi dan

membuat rancangan yang detail, melakukan modifikasi, menguji, dan

menyediakan dokumentasi. Dalam KPA ini proses-proses pemeliharaan

(dan alur kerjanya) diimplementasikan untuk masing-masing jenis

pemeliharaan (korektif, adaptif, preventif, dan penyempurnaan).

13. Verification and Validation (Evo4)

Mengendalikan permintaan modifikasi yang sudah ditugaskan kepada

sumber daya dan saat ini lagi dalam proses.

14. Configuration and Version Management (Sup1)

Merupakan proses-proses pendukung yang sering dipakai bersama-sama

oleh pengembang maupun maintainer dalam organisasi SI/TI. Sasaran

utamanya adalah untuk membangun dan mengendalikan hubungan antara

produk-produk menengah (intermediate products) yang dihasilkan dalam

suatu perubahan. KPA ini juga bertanggung jawab dalam melaksanakan

rencana versi/rilis menggunakan strategi yang diidentifikasi dalam rencana

pemeliharaan.

15. Process, Service, and Software Quality Assurance (Sup2)

Segala kegiatan yang berkaitan dengan penjaminan mutu (quality

assurance) seperti: inspeksi, ulasan, audit, dan penilaian kualitas produk

(product quality assessments).

16. Maintenance Measurement and Analysis (Sup3)

Merupakan segala kegiatan yang berkaitan dengan pengukuran dan analisis.


34


17. Causal Analysis and Problem Resolution (Sup4)

KPA ini menerima informasi dari proses-proses untuk mempelajari situasi

yang perlu dipahami untuk memecahkan permasalahan yang repetitif, dan

untuk memandu perbaikan dan inovasi. KPA ini melibatkan semua

organisasi pendukung SI/TI untuk memastikan bahwa ada komunikasi yang

baik untuk menemukan akar masalah dengan cepat.

18. Software Rejuvenation, Migration, and Retirement (Sup5)

Mengoptimalkan perangkat lunak untuk meningkatkan maintainability, dan

mengusulkan kegiatan seperti: dokumentasi ulang, restrukturisasi perangkat

lunak, reverse engineering, rekayasa ulang (reengineering), migrasi

perangkat lunak, dan memensiunkan perangkat lunak (software retirement).

Dalam S3m, ada 5 tingkat kematangan, yaitu tingkat 0 sampai tingkat 4. Dalam

buku referensi S3m (April & Abran, 2008), hanya ada Level 0 sampai Level 2,

sedangkan Level 3 dan 4 ditulis oleh para penulis yang sama dalam makalah

ilmiah (April & Abran, 2009) yang diterbitkan setelah terbitnya buku referensi

tersebut, dan hanya untuk KPA Pro4. Berikut 5 tingkat kematangan tersebut:

1. Level 0, proses tidak dilakukan.

2. Level 1, proses dilakukan secara tidak formal, yaitu tidak terstruktur dan

tidak berkoordinasi.

3. Level 2, proses memiliki prosedur terdokumentasi.

4. Level 3, hanya untuk Pro4.

5. Level 4, hanya untuk Pro4.

Karena tingkat 3 dan tingkat 4 yang sudah dipublikasikan baru tersedia untuk

KPA Pro4, maka dalam karya akhir ini pengukuran untuk tingkat 3 dan tingkat 4

tidak dilakukan, agar semua KPA memiliki tingkat kematangan yang sebanding.

Konsep tingkat kematangan (maturity level) di S3m berbeda dengan konsep

tingkat kematangan di CMMI-DEV V1.3. Di CMMI-DEV V1.3, suatu tingkat

kematangan diberikan apabila semua PA yang terkandung di dalamnya sudah

terpenuhi. Di S3m, tingkat kematangan diberikan ke satu KPA yang praktek-

praktek untuk tingkat kematangan tersebut sudah dipenuhi. Jadi dapat


35


disimpulkan bahwa tingkat kematangan di S3m lebih mirip dengan tingkat

kemampuan (capability level) di CMMI-DEV V1.3.

2.7 Pemilihan Kerangka Kerja SPI

Berdasarkan kerangka kerja terkait dengan tingkat kematangan proses

pemeliharaan perangkat lunak yang telah dijelaskan sebelumnya, penelitian ini

mengacu kepada kerangka kerja S3m. Kerangka kerja S3m dipilih karena:

1. Lebih cocok dengan kondisi pemeliharaan perangkat lunak di lingkungan

organisasi PT XYZ, yaitu berupa permintaan-permintaan berskala kecil

yang tidak membutuhkan teknik manajemen proyek.

2. Memiliki KPA yang mencakup aktivitas-aktivitas unik pemeliharaan, yang

tidak dicakup dalam CMMI-DEV V1.3, yaitu: Predelivery and Transition

Services dan Software Rejuvenation, Migration and Retirement.

Untuk memastikan bahwa semua PA dalam CMMI-DEV V1.3 yang relevan untuk

pemeliharaan perangkat lunak memang sudah dipetakan ke KPA dalam S3m,

dilakukan analisis untuk memastikan hal ini di subbab 4.1 (Rancangan Kajian).

2.8 Appraisal atau Assessment untuk SPI

Tujuan melakukan penilaian (appraisal) adalah untuk menemukan seberapa baik

proses yang dilakukan organisasi berdasarkan dengan best practices dan

mengidentifikasi area-area di mana perbaikan dapat dilakukan. Selain itu,

penilaian juga dilakukan untuk memberikan informasi terhadap pihak luar

organisasi mengenai seberapa baik proses organisasi tersebut (Chrissis, Konrad, &

Shrum, 2011)

Tujuan utama adalah penilaian internal organisasi dan identifikasi peluang-

peluang yang mungkin untuk meningkatkan proses yang ada dalam suatu

organisasi. Jika dilakukan oleh internal organisasi, proses ini disebut assessment.

Jika dilakukan oleh pihak eksternal organisasi, proses ini disebut evaluasi. Melalui

proses penilaian, organisasi dapat mengukur tingkat kemapanan proses

pengembangan perangkat lunak. Jika kemapanan telah diketahui, dapat


36


dirumuskan rekomendasi sejauh mana perbaikan proses pengembangan perangkat

lunak dapat dijalankan (Kneuper, 2009).

2.8.1 Standard CMMI Appraisal Method for Process Improvement

(SCAMPI)

SCAMPI adalah metode yang digunakan untuk menilai organisasi-organisasi yang

menggunakan CMMI, yang salah satu hasilnya berupa rating. Jika representasi

yang dinilai adalah representasi berkelanjutan, maka rating berupa profil tingkat

kemampuan (capability level profile). Jika representasi yang dinilai adalah

representasi bertingkat, maka rating berupa profil tingkat kematangan (maturity

level profile) (CMMI Product Team, 2010, hal. 34).

Dalam SCAMPI, ada tiga kelas appraisal, yaitu Kelas A, B, dan C. Metode

appraisal Kelas A diakui secara resmi dan merupakan metode appraisal yang

paling ketat. Metode ini merupakan satu-satunya dari ketiga kelas tersebut yang

dapat digunakan untuk benchmark rating kualitas. Metode Kelas B dan C dapat

digunakan untuk memberikan informasi perbaikan bagi organisasi yang hasilnya

tidak seformal Kelas A, namun tetap dapat membantu organisasi untuk

mengidentifikasi kesempatan untuk perbaikan (CMMI Product Team, 2010, hal.

60).

2.8.2 S3mAssess

S3mAssess adalah metode mini-assessment untuk S3m, yang dibuat untuk

mendapatkan maturity rating dari proses-proses pemeliharaan perangkat lunak

tanpa harus menghabiskan terlalu banyak usaha. Tiap praktek dalam proses yang

ditentukan dalam model kematangan digunakan untuk membangun daftar

pertanyaan yang berkaitan dengan praktek tersebut, dan seluruh kumpulan

pertanyaan tersebut disimpan dalam lembar Excel. Biasanya pertanyaan-

pertanyaan assessment tersebut dijawab melalui wawancara dengan personil

pemeliharaan dan manajemen senior (Zarour, Alarifi, Abran, & Desharnais, 2012,

hal. 2).Sesuai dengan subbab 2.7 (Pemilihan Kerangka Kerja SPI), metode ini

dipilih untuk digunakan dalam karya akhir ini karena merupakan metode yang

dibuat khusus untuk S3m.


37


Berikut ilustrasi algoritma S3mAssess yang dituangkan dalam bentuk diagram

Flowchart:

Mulai Selesai

Pilih domain proses

Kaji praktek-praktek tingkat kematangan 0

≥ 86%

Hitung rating rata-rata

praktek tingkat kematangan 0

Semua domain sudah

dikajiBelum

Kaji praktek-praktek tingkat kematangan 1



Ya

≥ 86%Kaji praktek-




Ya

≥ 86%

Ya

Sudah

Tidak

Tidak

Tidak

Gambar 2.5 Diagram Flowchart Algoritma S3mAssess Berdasarkan Deskripsi

Paquette, April, & Abran (2006)

Berikut penjelasan algoritma S3mAssess (Paquette, April, & Abran, 2006):

1. Yang pertama dilakukan adalah menentukan domain proses yang dingin

dikaji.


38


2. Kajian dilakukan untuk semua praktek-praktek dalam KPA dalam domain

proses tersebut untuk tingkat kematangan 0.

3. Rating tingkat kematangan 0 dari domain proses tersebut didapat dengan

cara menghitung rata-rata dari rating masing-masing praktek.

4. Jika rating tingkat kematangan 0 dari domain proses tersebut lebih kecil dari

86%, maka dinyatakan bahwa tingkat kematangan tersebut tidak tercapai,

dan tidak perlu melakukan kajian untuk tingkat kematangan berikutnya.

Langsung ulangi ke langkah pertama untuk domain proses berikutnya.

5. Jika rating tingkat kematangan 0 dari domain proses tersebut lebih besar

atau sama dengan 86%, maka dinyatakan bahwa tingkat kematangan

tersebut tercapai. Langkah 2, 3, dan 4 diulangi untuk tingkat kematangan

selanjutnya.

6. Rating tingkat kematangan 0, 1, dan 2 secara keseluruhan diperoleh dengan

cara menghitung rating rata-rata dari masing-masing domain proses pada

tingkat kematangan tersebut.

2.9 Prinsip Pareto

Iqbal & Rizwan (2009, hal. 223) menulis bahwa prinsip Pareto adalah aturan yang

dibuat oleh Vilfredo Pareto dengan mengamati bahwa 20% populasi memiliki

80% tanah yang berguna. Pareto menemukan bahwa aturan 80/20 juga berlaku

untuk proses-proses ekonomi dan alami lainnya. Observasi Pareto ini disebut

prinsip atau hukum Pareto 80/20 atau hukum banyak yang sepele dan sedikit yang

kritis (law of the trivial many and the critical few).

Dalam penelitiannya, Iqbal & Rizwan (2009, hal. 228) menyimpulkan bahwa

penerapan prinsip Pareto dalam proses perangkat lunak model Waterfall

menghasilkan peningkatan yang cukup besar yang membuat proses perangkat

lunak tersebut lebih berguna dan lebih efisien, karena mengurangi susah payah

dan meningkatkan kinerja. Dalam penelitian tersebut ada beberapa aspek

pemeliharaan perangkat lunak yang termasuk dalam 20% produktivitas sehingga

tidak diikutsertakan dalam perbaikan, yaitu:

1. Pengembangan kondisi pengujian.


39


2. Pembuatan data untuk pengujian.

3. Menjaga kekinian support request log.

4. Operasi paralel dalam rangka memensiunkan perangkat lunak.

5. Memensiunkan perangkat lunak itu sendiri.

Dalam penelitian tersebut, aspek pemeliharaan perangkat lunak yang termasuk

dalam 80% produktivitas sehingga perlu difokuskan untuk perbaikan yaitu:

1. Perencanaan instalasi.

2. Distribusi perangkat lunak.

3. Instalasi perangkat lunak itu sendiri.

4. Perencanaan pengujian perangkat lunak.

5. Eksekusi pengujian (oleh pengguna).

6. Penerimaan perangkat lunak dalam lingkungan operasional.

7. Operasi sistem.

8. Penyediaan bantuan teknis dan konsultasi (untuk pemeliharaan korektif saat

ada galat).

9. Memenuhi requirement pengguna untuk memperluas fungsionalitas

perangkat lunak (untuk pemeliharaan penyempurnaan).

10. Notifikasi terhadap pengguna.

Menurut Pressman (2010, hal. 439), penggunaan prinsip Pareto dalam pengujian

perangkat lunak merupakan salah satu langkah dalam penjaminan mutu perangkat

lunak (Software Quality Assurance) yang berdasarkan pada statistika. Penerapan

prinsip Pareto dalam hal ini adalah bahwa 80% defect berasal dari 20% penyebab.

Jadi dengan mengisolasi 20% dari penyebab kritis ini, 80% defect bisa diatasi.

Pressman (2010, hal. 757) juga menyatakan bahwa prinsip Pareto bisa digunakan

dalam manajemen risiko untuk proyek rekayasa perangkat lunak. Pendapat

Pressman tersebut diperkuat oleh penelitian Andersson & Runeson (2007, hal.

284) yang berhasil mereplikasi distribusi 80/20 sesuai prinsip Pareto dalam

distribusi kesalahan (fault distribution) pada modul-modul perangkat lunak.


40


Dalam karya akhir ini prinsip Pareto digunakan untuk menganalisis profil

kematangan proses pemeliharaan perangkat lunak untuk memilih KPA yang akan

diperbaiki.

2.10 Penelitian Sebelumnya

Bagian ini menjelaskan penelitian-penelitian sebelumnya yang berhubungan

dengan pertanyaan penelitian dalam karya akhir ini.

2.10.1 Software Maintenance Process Model and Contrastive Analysis

Penelitian Ren, Xing, Liu, & Chen (2011) ini membandingkan 4 model

pemeliharaan, yaitu: model ubah secepatnya (Quickly Modify), model Boehm,

model IEEE 1219-1993, dan perbaikan iteratif (Iterative Enhancement). Penelitian

ini mendefinisikan langkah-langkah dalam proses pemeliharaan perangkat lunak

sebagai: persiapan, permintaan, kebutuhan analisis, ulasan analisis, implementasi

modifikasi, pengujian, verifikasi, dan upgrade. Penelitian ini berkesimpulan

bahwa:

a. Model ubah secepatnya hanya menutupi gejala permasalahan dan tidak

menjamin terpenuhinya persyaratan kehandalan proses pemeliharaan.

b. Model Boehm bisa diterapkan untuk manajemen dari organisasi

pemeliharaan, didorong dari perspektif kepentingan ekonomis.

c. Model IEEE 1219-1993 memastikan kualitas pemeliharaan melalui

pengujian sistem pengujian penerimaan (acceptance testing).

2.10.2 Evaluating the Relationship Between Process Improvement and

Schedule Deviation in Software Maintenance

Penelitian Jung & Goldenson (2009) ini, memberikan bukti empiris bahwa proses

yang lebih matang berkorelasi dengan kinerja proyek dan kualitas yang lebih baik.

Pembuktian dilakukan dengan melakukan pengujian hipotesis bahwa kematangan

yang lebih tinggi berkorelasi negatif dengan penyimpangan jadwal pemeliharaan

perangkat lunak. Penelitian ini juga menyelidiki apakah faktor ukuran organisasi

dan wilayah geografis mempengaruhi hubungan antara kematangan proses dan

penyimpangan jadwal. Hasil penelitian ini menyatakan bahwa ukuran organisasi


41


tidak mempengaruhi hubungan tersebut, sedangkan wilayah geografis merupakan

variabel independen.

2.10.3 Critical Success Factors in Software Maintenance: A Case Study

Penelitian Sneed & Brössler (2003) ini bertujuan untuk mengidentifikasi Critical

Success Factor (CSF) dari kesuksesan operasi pemeliharaan secara umum lalu

menerapkannya dalam sebuah proyek pemeliharaan tertentu. Aplikasi dalam

proyek pemeliharaan tersebut adalah sebuah sistem perbankan yang kompleks

yang berfungsi untuk pemrosesan efek (securities). Penelitian didasarkan pada

data empiris yang dikumpulkan selama berlangsungnya proyek. Delapan CSF

berhasil diidentifikasi, yaitu: menjaga fungsionalitas, menjaga kualitas,

mengendalikan kompleksitas, mencegah naiknya volatility, mengendalikan biaya,

menjaga rilis yang teratur, mempertahankan kepuasan pengguna, dan profitabilitas

(menutup biaya).

2.10.4 Beyond Productivity in Software Maintenance: Factors Affecting Lead

Time in Servicing Users' Requests

Penelitian Chan (2000) ini mengidentifikasi faktor-faktor yang mempengaruhi

lead time dalam pemeliharaan perangkat lunak. Faktor-faktor yang diidentifikasi

adalah: karakteristik sistem, permintaan, dan maintainer yang bertanggung jawab

terhadap permintaan. Kompleksitas permintaan dapat memperpanjang lead time

secara signifikan. Lead time juga jadi lebih panjang karena disesuaikan dengan

target lead time internal departemen yang dibuat berdasarkan ketersediaan staf.

Faktor usia sistem ditemukan tidak mempengaruhi kegiatan pemeliharaan dan

tidak memperpanjang lead time. Faktor pengetahuan domain aplikasi tidak

membantu mempersingkat lead time jika staf sudah terlalu sibuk.

2.10.5 Rangkuman Penelitian Sebelumnya

Tabel 2.2 di bawah merepresentasikan rangkuman dari kelima penelitian yang

berkaitan dengan pertanyaan penelitian dalam karya akhir ini, dengan hasil

analisis Compare, Contrast, Criticize, Summarize, dan Synthesize (3C+2S).


42


Tabel 2.2 Rangkuman Penelitian Sebelumnya

Aspek

Software Maintenance

Process Model and

Contrastive Analysis

Evaluating the Relationship

Between Process

Improvement and Schedule

Deviation in Software

Maintenance

Critical Success

Factors in Software

Maintenance: A Case

Study

Beyond Productivity in Software

Maintenance: Factors Affecting Lead

Time in Servicing Users' Requests

Nama

Peneliti

Ren, Xing, Liu, & Chen Jung & Goldenson Sneed & Brössler Chan

Tahun 2011 2009 2003 2000

Compare Membandingkan model

proses pemeliharaan

perangkat lunak.

Evaluasi hubungan antara

tingkat kematangan proses

dengan penyimpangan

jadwal pemeliharaan.

Mencari CSF proses

pemeliharaan sebuah

sistem perbankan yang.

Mencari faktor-faktor yang

mempengaruhi lead time dari

pemeliharaan.

Contrast Tidak ada studi kasus. Analisis terhadap 752 proyek

pemeliharaan dari 441

assessment SW-CMM.

Studi kasus perusahaan

perbankan.

Sudi kasus di organisasi nirlaba.

Criticize Masalah tidak jelas. Data SW-CMM, bukan

CMMI-DEV.

Tidak menghasilkan

strategi SPI.

Tidak menghasilkan strategi SPI.

Summarize Membandingkan model

proses pemeliharaan

perangkat lunak.

Tingkat kematangan proses

berkorelasi negatif dengan

penyimpangan jadwal

pemeliharaan.

Ada 8 CSF yang

berhasil diidentifikasi

untuk pemeliharaan

perangkat lunak.

Usia sistem tidak memperpanjang lead

time. Penguasaan domain aplikasi tidak

memperpendek lead time jika staf terlalu

sibuk. Kompleksitas permintaan

memperpanjang lead time.

Synthesize Strategi SPI untuk organisasi bisa disusun dengan mengidentifikasi CSF proses, meningkatkan tingkat kematangan proses,

memilih model proses, mempertimbangkan faktor yang mempengaruhi lead time, dan aspek pemeliharaan yang penting

menurut manajemen.


43


2.11 Kerangka Teoretis

Dari teori-teori dan penelitian-penelitian terdahulu yang telah dibahas, disusun

kerangka teoretis (theoretical framework) berikut:

Kondisi Proses Pemeliharaan

Perangkat Lunak

S3m

S3mAssessTingkat Kematangan Proses Pemeliharaan

Perangkat Lunak

Strategi SPI Pemeliharaan

Perangkat LunakMasukan Manajemen

Analisis Pareto

Gambar 2.6 Kerangka Teoretis

Penelitian ini akan menggunakan metode appraisal S3mAssess untuk mengukur

kematangan proses pemeliharaan perangkat lunak di PT XYZ. Kegiatan

assessment akan menilai kondisi proses pemeliharaan perangkat lunak saat ini

dengan terhadap model referensi. Hasil penilaian yang berupa tingkat kematangan

akan diajukan kepada manajemen untuk memilih KPA yang akan diperbaiki.

Rekomendasi perbaikan proses untuk KPA terpilih akan disusun, lalu diajukan

kembali kepada manajemen untuk validasi, agar hasilnya diadopsi menjadi

strategi SPI yang tepat bagi PT XYZ.

Dari Gambar 2.6 dapat dilihat hal-hal yang mempengaruhi penelitian ini:

a. S3m

Karya akhir ini menggunakan S3m sebagai model referensi untuk perbaikan

proses pemeliharaan perangkat lunak.

b. S3mAssess

Metode ini digunakan dalam menilai proses pemeliharaan perangkat lunak

saat ini.

c. Kondisi Proses Pemeliharaan Perangkat Lunak


44


Kondisi proses saat ini dinilai terhadap model S3m. Penilaian dilakukan

dengan menggunakan metode S3mAssess.

d. Analisis Pareto

Menggunakan prinsip Pareto untuk memilih KPA yang akan diperbaiki.

e. Masukan Manajemen

Masukan manajemen digunakan untuk validasi rekomendasi perbaikan.



BAB 3

METODOLOGI PENELITIAN

Bab ini membahas metodologi penelitian dalam karya akhir ini, yaitu masukan,

proses, dan keluaran dari tiap-tiap langkah dari penelitian yang akan dilakukan.

3.1 Rancangan Penelitian

Penelitian ini merupakan penelitian kualitatif dengan metodologi penelitian studi

kasus dan penelitian survei. Metodologi penelitian studi kasus dilakukan pada

perusahaan PT XYZ. Metodologi penelitian survei dilakukan dengan cara

wawancara dan pengumpulan dokumen. Studi kasus harus dibatasi waktu dan

aktivitas peneliti dalam mengumpulkan informasi menggunakan berbagai

prosedur pengumpulan dan pengolahan data.

Tabel 3.1 Rancangan Penelitian

Elemen Keterangan

Klasifikasi Studi kasus.

Paradigma Interpretivism.

Tujuan Penelitian Menyusun strategi SPI pemeliharaan perangkat lunak.

Jenis Data Teks.

Pengumpulan Data Wawancara dan studi dokumen.

Analisis Data Kualitatif.

Metode Penarikan

Kesimpulan

Induktif.

Metode Olah Data Kodifikasi hasil wawancara.

Instrumen Penelitian Daftar pertanyaan kondisi aktual organisasi, daftar

pertanyaan area proses.

Tool Olah Data Lembar Microsoft Excel dari S3mAssess.

Narasumber Kepala Departemen, Kepala Seksi, dan anggota tim-tim

yang bertugas melakukan pemeliharaan.

Langkah-langkah yang akan dilakukan dalam penelitian ini diilustrasikan pada

Gambar 3.1 di bawah:


46


Masukan Proses Keluaran

Data ticketing

1. Pengumpulan Data Awal

Metode: wawancara, studi dokumen, dan observasi

Kondisi saat ini dan

harapan manajemen

2. Identifikasi Masalah

Metode: analisis akar masalah

Pertanyaan penelitian

Teori dan penelitian terdahulu

3. Tinjauan Pustaka

Metode: studi literatur, 3C+2S

Kerangka teoretis

S3m

5. Penilaian Tingkat Kematangan

Metode: S3mAssess

Profil tingkat kematangan

Strategi SPIMasukan Manajemen

6. Penyusunan Strategi SPI

Metode: S3m, Pareto

Kesimpulan dan saran

7. Pembuatan Kesimpulan dan Saran

Metode: Induktif

Kondisi Proses Pemeliharaan Perangkat

Lunak Saat Ini

5. Pengumpulan Data Penilaian

Metode: wawancara, studi dokumen

Transkrip wawancara dan artifak

Gambar 3.1 Langkah-langkah Penelitian

Berikut adalah penjelasan dari Gambar 3.1 di atas:


47


3.1.1 Pengumpulan Data Awal

Penelitian dalam karya akhir ini dimulai dengan mengumpulkan data awal dengan

melakukan wawancara, studi dokumen, dan observasi. Data yang dikumpulkan

berupa data ticketing dan ekspektasi manajemen. Tujuan tahap ini adalah untuk

mengetahui kondisi organisasi saat ini dan ekspektasi manajemen.

3.1.2 Identifikasi Masalah

Tahap ini dilakukan dengan membandingkan kondisi saat ini terhadap ekspektasi

manajemen. Masalah dirumuskan menggunakan analisis akar masalah yang

hasilnya ditampilkan dalam bentuk diagram tulang ikan. Berikutnya salah satu

akar masalah dipilih dan dirumuskan dalam bentuk pertanyaan penelitian.

3.1.3 Tinjauan Pustaka

Untuk memperdalam pemahaman agar dapat menjawab pertanyaan penelitian,

dilakukan peninjauan pustaka. Teori-teori yang ditinjau kemudian diringkas, dan

penelitian-penelitian terdahulu yang berkaitan dengan penelitian ini dianalisis

dengan metode 3C+2S. Dari teori-teori dan penelitian-penelitian terdahulu,

dibentuk kerangka teoretis yang diharapkan dapat membantu menyusun langkah-

langkah yang perlu dilakukan untuk menjawab pertanyaan penelitian.

3.1.4 Pengumpulan Data Penilaian

Wawancara dengan personil-personil yang relevan dalam proses pemeliharaan

perangkat lunak dilakukan untuk mendapatkan bukti lisan pelaksanaan praktek-

praktek dari model referensi (S3m). Studi dokumen juga dilakukan untuk

mendapatkan bukti artifak.

3.1.5 Penilaian Tingkat Kematangan

Kondisi proses pemeliharaan perangkat lunak saat ini di organisasi dinilai dengan

menggunakan S3mAssess. Evaluasi tingkat kematangan ini menghasilkan profil

tingkat kematangan saat ini.


48


3.1.6 Penyusunan Strategi SPI

Dilakukan analisis menggunakan prinsip Pareto untuk menentukan prioritas KPA

yang akan diperbaiki. Khusus untuk KPA yang terpilih, rekomendasi perbaikan

praktek disusun berdasarkan satu tingkat kematangan S3m di atasnya. Setelah

rekomendasi disusun, diakukan kembali ke manajemen untuk validasi

rekomendasi mana yang akan dilaksanakan. Setelah mendapatkan validasi,

rekomendasi diadopsi menjadi strategi SPI.

3.1.7 Pembuatan Kesimpulan dan Saran

Tahap terakhir penelitian adalah penarikan kesimpulan dari profil tingkat

kematangan saat ini dan strategi SPI yang cocok untuk organisasi. Selain itu,

disampaikan juga saran untuk penelitian selanjutnya.

3.2 Metode Pengumpulan Data

Pengumpulan data dilakukan dengan wawancara dan studi dokumen.

3.2.1 Wawancara

Pada penelitian ini wawancara dilakukan untuk memperoleh pandangan dari

pemangku kepentingan yang terlibat langsung dengan pemeliharaan SI/TI di

lingkungan internal PT XYZ, yaitu:

a. Bapak RK yang menjabat sebagai Kepala Departemen TI.

b. Bapak IWSY yang menjabat sebagai Kepala Seksi Application

Development.

c. Bapak IYB yang menjabat sebagai Kepala Seksi Business Analyst.

d. Bapak JW yang menjabat sebagai Kepala Seksi IT Support.

e. Ibu TYS yang merupakan staf seksi Application Development yang bertugas

sebagai System Analyst.

Wawancara melibatkan serangkaian pertanyaan yang diturunkan dari praktek-

praktek dari semua KPA dalam S3m, untuk memperoleh pandangan dari

narasumber. Tabel berikut menunjukkan narasumber dan KPA yang ditanyakan

kepadanya:


49


Tabel 3.2 Pemilihan Narasumber Masing-masing KPA

KPA Bapak

RK

Bapak

IWSY

Bapak

IYB

Bapak

JW

Ibu

TYS

Maintenance Process Focus

(Pro1)

Maintenance Process/Service

Definition (Pro2)

Maintenance Training (Pro3)

Maintenance Process

Performance (Pro4)

Maintenance Innovation and

Deployment (Pro5)

Event/Request Management

(Req1)

Maintenance Planning (Req2)

Request/Software Monitoring

and Control (Req3)

SLA and Supplier Agreement

Management (Req4)

Predelivery and Transition

Services (Evo1)

Operational Support Services

(Evo2)

Software Evolution and

Correction Services (Evo3)

Verification and Validation

(Evo4)

Configuration and Version

Management (Sup1)

Process, Service, and

Software Quality Assurance

(Sup2)

Maintenance Measurement

and Analysis (Sup3)

Causal Analysis and Problem

Resolution (Sup4)

Software Rejuvenation,

Migration, and Retirement

(Sup5)

Narasumber masing-masing KPA dipilih berdasarkan kesesuaian uraian tugasnya

dengan KPA tersebut. Jika suatu KPA memerlukan pendapat lebih dari satu

narasumber, maka KPA tersebut atau praktek yang bersangkutan dapat ditanyakan

ke beberapa narasumber.


50


Butir-butir pertanyaan dalam wawancara diturunkan dari teks praktek-praktek

dalam S3m. Berikut adalah daftar pertanyaan untuk semua KPA dan semua

praktek:

Tabel 3.3 Pointer Pertanyaan Wawancara

Nomor

Praktek

Teks Praktek

(April & Abran, 2008)

Pertanyaan

Wawancara

KPA Maintenance Process Focus (Pro1)

Pro1.0.1

The software maintenance

organization does not carry out

structured process improvement

activities leading to persistent and

controlled improvements.

Apakah Departemen TI tidak

melakukan aktivitas perbaikan

proses yang mengarah kepada

perbaikan yang terkendali dan

terus menerus?

Pro1.1.1

Within the software maintenance

organization, improvement is

carried out in an informal way.

Apakah Departemen TI

melakukan perbaikan proses

secara informal?

Pro1.1.2

Some individual improvement

initiatives aim mostly at improving

technical aspects of software

maintenance processes.

Apakah inisiatif perbaikan

proses bertujuan untuk

memperbaiki aspek teknis dari

proses perawatan perangkat

lunak?

Pro1.2.1

A quality and process improvement

program has been initiated at the

IS/IT organization level. The

software maintenance managers

are aware of this program and

have had initial quality awareness

training.

Apakah program perbaikan

proses dan kualitas sudah

dimulai di tingkat Departemen

TI? Apakah Bapak - sebagai

manajer yang bertanggung

jawab terhadap perawatan

perangkat lunak -

mengetahui/sadar akan

program ini? Apakah Bapak

sudah pernah diberikan

pelatihan kesadaran kualitas

(quality awareness training)?

Pro1.2.2

A representative of the software

maintenance organization is

assigned to plan and coordinate

improvement activities.

Adakah perwakilan dari

Departemen TI yang

ditugaskan untuk

merencanakan dan

mengoordinasikan aktivitas

perbaikan proses?

Pro1.2.3

Results of the software

maintenance products/services

customer survey is used to identify

candidate improvement.

Apakah ada survei untuk

mencari tahu tingkat kepuasan

pengguna terhadap proses

perawatan perangkat lunak

(misalnya korektif atau

adaptif)? Kalau ada, apakah


51


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

hasil survei tersebut digunakan

untuk mengidentifikasi

kandidat perbaikan proses?

Pro1.2.4

The observations, comments, and

complaints from users/customers

and interface groups (developers,

operations, help desk,

subcontractors, etc.) are used to

collect data for identifying

candidate improvements.

Adakah pengumpulan pendapat

dari tim Developer, tim

Hardware & Infrastructure,

dan tim Help Desk, tentang


lunak? Kalau ada, apakah

pendapat-pendapat tersebut

digunakan untuk

mengidentifikasi kandidat

perbaikan proses?

Pro1.2.5

Comparisons of application

software profiles and relevant

internal benchmarks are used to

identify candidate improvements.


melakukan profiling atau

benchmarking aplikasi secara

berkala?

Pro1.2.6

The data on software failures is

collected and used to identify

candidate improvements to

maintenance processes/products

and also to the many interfaces

with the other interface groups

(developers, operations, help desk,

subcontractors, etc.)

Adakah pengumpulan data

kesalahan perangkat lunak?

Kalau ada, apakah data tersebut

digunakan untuk perbaikan

proses atau perbaikan

perangkat lunak tersebut?

Kalau ada, untuk apakah data

tersebut digunakan?

Pro1.2.7

The maintenance organization is

subject to internal audits from

internal auditor (e.g., COBIT. ISO

90003 4.2.4 e or other types of

audits) and the results are used to

identify candidate improvements.

Apakah Departemen TI sudah

pernah diaudit terhadap suatu

standar, misalnya untuk

COBIT, ISO 90003, dsb.?

Kalau sudah, apakah hasilnya

digunakan untuk


perbaikan proses?

Pro1.2.8

A maturity assessment of some

processes has been performed. At

least one maintenance organization

has conducted a process maturity

assessment and the results are used

to identify candidate improvements.


pernah dikaji/dinilai (assess)

terhadap suatu model referensi

(misalnya menggunakan

SCAMPI terhadap CMMI-

DEV V1.3)? Kalau sudah,

apakah hasilnya digunakan


kandidat proses?

Pro1.2.9 A list of candidate improvements,

ordered by priorities, is developed

Apakah Departemen TI ada

membuat daftar kandidat

Tabel 3.3 Pointer Pertanyaan Wawancara (sambungan)


52


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

and used as a guide for developing

the software maintenance

improvement program.

perbaikan, yang diurutkan

berdasarkan prioritas? Apakah

daftar tersebut digunakan

sebagai panduan dalam

mengembangkan program

perbaikan proses perawatan

perangkat lunak?

Pro1.2.10

The list of the top 10 possible

improvements is discussed, and

actions plans are drawn up by

middle and senior management.

The planned improvement

activities/projects are funded within

the annual budgets and current

operations.

Apakah manajemen senior ada

membuat dan mendiskusikan

rencana tindakan (action plan)

yang berisi 10 perbaikan proses

tertinggi (top 10 improvement)

untuk perawatan perangkat

lunak? Apakah rencana

aktivitas/proyek perbaikan


lunak tersebut didanai dari

anggaran tahunan?

Pro1.2.11

Improvements to some processes

have been initiated. The annual

plan, of each maintenance

organization, includes both the

improvement activities planned and

carried out during the year.

Apakah ada perbaikan proses

yang sudah dimulai? Apakah

rencana tahunan dari

Departemen TI memiliki

kegiatan yang direncanakan

untuk perbaikan proses

perawatan perangkat lunak?

Apakah rencana tersebut

dilaksanakan?

KPA Maintenance Process/Service Definition (Pro2)

Pro2.0.1



process/services definition

activities. It does not provide a list

or directory of services to its

customers.


melakukan aktivitas

mendefinisikan proses atau

layanan? Apakah Departemen

TI tidak menyediakan daftar

atau direktori layanan kepada

para pengguna?

Pro2.1.1

The maintenance

processes/services are informal and

based on the experience of

individuals.

Apakah proses atau layanan

bersifat tidak formal dan

berdasarkan pada pengalaman

individu saja?

Pro2.1.2

Individual initiatives, for defining

maintenance processes/services,

mainly address technical aspects of

the software or describe, in a local

format, the activities of a specific

Apakah inisiatif individu dalam

mendefinisikan proses atau

layanan ini utamanya untuk

mengatasi aspek teknis?



53


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

maintenance organization.

Pro2.2.1

There is at least one description of

maintenance processes/services

that is used by the customer and

offered by the maintenance

organization.

Apakah Departemen TI (atau

salah satu seksinya)

mendefinisikan dan

mendokumentasikan proses

standarnya yang digunakan

untuk menggambarkan

aktivitasnya? Apakah dokumen

tersebut dibagikan kepada

pengguna? Apakah pengguna

menggunakan dokumen

tersebut?

Pro2.2.2

Portions of the maintenance

processes/services/resources are

documented and deployed in the

software maintenance organization.


memiliki dokumentasi proses

perawatan perangkat lunak,

baik layanannya maupun

sumber dayanya (personil, tool,

perangkat lunak, lingkungan

kerja, standar pemrograman,

naming conventions)? Apakah

dokumen tersebut dijaga up-to-

date? Apakah dokumen

tersebut digunakan orang yang

bertugas memelihara perangkat

lunak?

Pro2.2.3

There are activities under way, at

the organization unit level, to

document and standardize software

maintenance processes/services.


memiliki aktivitas untuk

mendokumentasikan dan

menstandarkan proses atau

layanan perawatan perangkat

lunak?

Pro2.2.4

Software maintenance management

acknowledges and promotes the use

of standard processes/services and

the use of external standards

relevant to software maintenance.

Apakah Bapak - sebagai

manajer yang bertanggung

jawab untuk pemeliharaan

perangkat lunak - mengakui

dan mempromosikan

(acknowledges and promotes)

penggunaan proses atau

layanan yang terstandarisasi,

dan penggunaan standar

eksternal yang relevan untuk


(seperti ISO 9001, ISO 12207,

ISO 14764)?



54


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

KPA Maintenance Training (Pro3)

Pro3.0.1

Software maintenance organization

do not have structured training

activities that address predelivery

and transition, the software

maintained and its technical

environment, the maintenance

processes/services or the engineers'

morale career plans.


memiliki kegiatan pelatihan

yang terstruktur yang

mengatasi:

1. predelivery and transition,

2. perangkat lunak yang

dirawat dan lingkungan

teknisnya,

3. proses atau layanan


yang disediakan, dan

4. rencana karier atau semangat

kerja personil.

Pro3.1.1

Technical training in the software


provided when there is an urgent

need.

Apakah Departemen TI baru

memberikan pelatihan dalam

perawatan perangkat lunak saat

ada keperluan mendesak?

(Misalnya pada saat ada

perubahan platform,

infrastruktur, proses, atau saat

ada perangkat lunak yang

selesai pengembangannya dan

transisi ke perawatan)

Pro3.1.2

Individual training initiatives are

aimed mainly at the technical

aspects of software maintenance

and the products they support. A

pairing process appears where a

senior staff member is assigned to a

junior employee as a mentor and to

answer his or her questions.

Apakah sasaran utama

pelatihan adalah aspek teknis

dari perawatan perangkat lunak

dan dukungan produk saja?

Apakah ada proses di mana staf

senior ditugaskan sebagai

mentor bagi karyawan junior,

untuk menjawab pertanyaan-

pertanyaannya?

Pro3.1.3

The training plans for new

engineers address generic topics

about management, processes, and

software maintenance activities.

Apakah rencana pelatihan bagi

karyawan yang bertugas untuk

pemeliharaan perangkat lunak

mengatasi topik-topik umum

tentang manajemen, proses,

dan aktivitas pemeliharaan

perangkat lunak?

Pro3.2.1

Maintenance engineers become

proficient and periodically update

their proficiency with the software

they maintain and its

Apakah karyawan yang

bertugas untuk pemeliharaan

perangkat lunak diberikan

pelatihan secara periodik



55


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

infrastructure. sehingga menjadi mahir dalam

struktur perangkat lunak

(komponen internalnya dan

pemrosesan datanya)? Apakah

ada kegiatan diskusi yang

terencana dengan pengguna

tentang bagaimana cara mereka

menggunakan perangkat lunak

tersebut?

Pro3.2.2

The maintenance engineer is

trained and motivated to perform

well when using the

process/services and their support

role.

Apakah Departemen TI:

1. Mengidentifikasi pelatihan

mana yang perlu diadakan?

2. Mengidentifikasi kelemahan

dari pelatihan saat ini?

3. Mengulas dokumen

pelatihan saat ini?

4. Menilai pengetahuan

personil tentang proses

pemeliharaan perangkat lunak?

5. Mengundang personil


untuk memberikan saran untuk

perbaikan dalam pelatihan

untuk proses pemeliharaan

perangkat lunak?

Pro3.2.3

Training on communication with

customers is offered to software

maintenance engineers.


memberi pelatihan bagi

personil pemeliharaan

perangkat lunak tentang

komunikasi dengan pengguna?

Pro3.2.4

Use of internal benchmarking data

to guide the training of

maintenance resources.


menggunakan data benchmark

internal untuk memandu

pelatihan bagi personil


Pro3.2.5

Financial resources are available

to maintenance managers for the

education and training of each

maintenance engineer.


memiliki anggaran untuk

pelatihan? Apakah ada

dokumentasi tentang:

1. Pelatihan yang sudah

selesai?

2. Aktivitas pelatihan internal

yang diikuti?

3. Rencana pelatihan ke



56


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

depannya?

Pro3.2.6

There are plans and record that

describe the education and training

needed for each maintenance

engineering position and

application software. This training

plan documents the training needs,

the courses offered, and related

material, credits, resources

available, and the schedule of

education and training activities.

Apakah ada rencana atau

catatan tentang pendidikan atau

pelatihan yang dibutuhkan bagi

setiap posisi pemeliharaan

perangkat lunak? Apakah di

dokumennya ada:

1. Daftar pelatihan yang

diperlukan?

2. Daftar pelatihan yang

ditawarkan?

3. Ketersediaan material,

sumber daya, dan jadwal?

Pro3.2.7 Training time is planned.

Apakah karyawan yang

bertugas untuk pemeliharaan

perangkat lunak diberikan

waktu khusus untuk pelatihan?

Kalau ya, berapa jam dalam

seminggu?

Pro3.2.8

Senior maintainers familiarize new

employees and prospective

maintainers with the maintenance

of the software for which they are

responsible.

Apakah staf maintainer senior

membiasakan karyawan

prospektif maintainer baru

terhadap pemeliharaan

perangkat lunak?

1. Dokumentasi dan library

yang digunakan.

2. Editor, tools termasuk untuk

membandingkan source code,

compiler, debuggers, static

source code analyzers, test

tools, documentation tools,

configuration management,

dan DBMS.

3.Operasional dukungan

(support) dan jam dukungan.

Pro3.2.9

For each development project to be

transitioned to software

maintenance, the training needs are

defined for both the technical and

management responsibilities (e.g.,

nature of training, identification of

the staff to be trained, timing of

trainings, etc.)

Apakah jika ada transisi proyek

ke pemeliharaan, ada proses

identifikasi kebutuhan

pelatihan, baik teknis maupun

manajemen? (Misalnya

identifikasi pelatihan apa yang

diperlukan, siapa yang perlu

diberi pelatihan, kapan, dst.)

Apakah saat dalam proses



57


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

pengembangan, pihak

pengembang (developer)

mengidentifikasi kebutuhan

pelatihan bagi pengguna?

Apakah ada komunikasi antara

pengembang dan pemelihara

tentang kebutuhan pelatihan

pengguna?

Pro3.2.10

People who work on the

predelivery and transition of a

project to maintenance receive the

training deemed appropriate by the

software developer.

Apakah pihak manajemen

(Bapak, sebagai manajer yang

bertanggung jawab dalam

pemeliharaan perangkat lunak)

memastikan para maintainer

mendapatkan pelatihan sesuai

dengan apa yang menurut

developer merupakan keahlian

yang dibutuhkan untuk

memelihara perangkat lunak?

Pro3.2.11

The end-user training material is

designed in accordance with a

locally documented procedure.

Apakah materi pelatihan untuk

pengguna sudah sesuai dengan

dokumentasi prosedur yang

dilaksanakan saat ini? Apakah

Departemen TI memiliki

prosedur pembuatan

dokumentasi atau prosedur

pembuatan materi pelatihan?

Pro3.2.12

The user (and some other

stakeholders) receives enough

education and training to allow for

autonomous use of the application

software.

Apakah pengguna diberikan

pelatihan atau pendidikan yang

cukup untuk dapat

mengoperasikan atau


tanpa bantuan Departemen TI?

Pro3.2.13

Users receive information and

training on the maintenance and

support processes for all their

supported application software.


memiliki prosedur untuk

melakukan pengadaan

pelatihan bagi pengguna?

Apakah para pengguna tahu

prosedur ini?

KPA Maintenance Process Performance (Pro4)

Pro4.0.1


organization does not have

activities organized to measure the

performance of its processes,

services, products and resources.


memiliki aktivitas yang

terorganisasi untuk pengukuran

kinerja prosesnya, layanannya,

produknya, dan sumber



58


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

dayanya?

Pro4.1.1

Some initiatives for measuring

process, services, or products are

carried out by individuals who have

an interest in measurement.

Apakah pengukuran proses,

layanan, atau produk

merupakan inisiatif individu,

atau memang inisiatif

organisasi? Kalau individu,

apakah ini berarti data yang

dikumpulkan tidak dibagikan

dengan personil lainnya?

Pro4.1.2

Some qualitative measures of

maintenance processes, services,

and products are collected.

Apakah data yang

dikumpulkan berupa kualitatif

atau kuantitatif? Yang diukur

apa? Kepuasan pelanggan?

Atau kecepatan transaksi?

Pro4.2.1

Some key maintenance processes,

services, and products have

measures. They are defined and

used locally.


memiliki ukuran-ukuran untuk

proses pemeliharaan perangkat

lunak:

1. Persentase ukuran kepuasan

pengguna, berdasarkan survei?

2. Formulir untuk rekam

penggunaan waktu berdasarkan

aktivitas atau sumber daya?

3. Jumlah panggilan telepon

berdasarkan jenis layanan?

4. Jumlah pengguna?

5. Jumlah jam pekerjaan dan

pekerjaan lembur?

6. Jumlah permintaan yang

ditutup untuk suatu periode,

permintaan yang baru dibuka,

permintaan yang dibawa dari

periode sebelumnya ke periode

berikutnya (carry forward),

dan permintaan yang lagi

menunggu?

7. Jumlah sumber daya

(personil) untuk tiap produk

aplikasi perangkat lunak?

8. Pengukuran untuk evolusi

proses (misalnya menggunakan

model perbaikan dan/atau ISO

9001)?



59


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

Pro4.2.2

Measurement baselines on the

quality and performance of

processes, services, and products,

are collected, stored, reviewed, and

used with the various stakeholders

(customers, users, sponsors,

program manager, maintenance

engineers, and interface groups).

They are used for improving the

current processes, services, and

products.

Apa acuan pengukuran kinerja

dan kualitas dari proses,

layanan, dan produk di

Departemen TI (yang relevan

untuk pemeliharaan perangkat

lunak)? Bagaimana acuan

tersebut dikumpulkan,

disimpan, dan diulas? Apakah

para pemangku kepentingan

tahu/paham tentang acuan

tersebut? Untuk apa acuan

tersebut digunakan?

Pro4.2.3

The maintenance organization has

set some performance and quality

objectives.


menentukan tujuan/obyektif

kinerja dan kualitas?

KPA Maintenance Innovation and Deployment (Pro5)

Pro5.0.1


organization does not collect

information, for improvement

purposes, from its stakeholders,

end users, customers, and other

interface groups.


mengumpulkan informasi

untuk tujuan perbaikan proses?

Dari siapa saja informasi

tersebut dikumpulkan?

(pemangku kepentingan,

pengguna, pelanggan, grup

antar muka lainnya?)

Pro5.0.2


organization does not study

improvement or innovation

proposals.


mengumpulkan proposal

inovasi proses? Apakah

proposal tersebut dipelajari?

Pro5.0.3


organization does not assess the

impact of an innovation or

improvement on the processes,

services, and products.


mengkaji dampak dari suatu

inovasi atau perbaikan dari

proses, layanan, dan produk?

Caranya bagaimana?

Pro5.1.1

The maintenance organization

informally evaluates the benefits of

its improvement and innovation

projects.


mengevaluasi manfaat dari

proyek-proyek perbaikan dan

inovasinya? Secara formal atau

tidak formal?

Pro5.1.2

Individual initiatives for

improvement and innovation target

mainly the technical aspects of

software maintenance.

Apakah inisiatif perbaikan

proses dari Departemen TI atau

secara individual? Apa target

utama perbaikan? Aspek teknis

atau manajemen?



60


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

Pro5.1.3

Assessments of new processes,

technologies, methodologies, and

tools for maintenance are

performed informally.

Jika ada proses, teknologi baru,

metodologi baru, dan tools

baru untuk pemeliharaan

perangkat lunak, apakah dikaji

secara formal (misalnya masuk

ke dalam daftar kegiatan TI

yang dinilai untuk kemajuan

karier)? Ataukah secara tidak

formal?

Pro5.2.1

New processes, services,


tools are identified and investigated

for their potential use in software

maintenance.

Apakah Departemen TI secara

proaktif mencari atau

mengidentifikasi proses,

layanan, teknologi, metodologi,

dan tools baru berdasarkan

potensi penggunaannya di


Apakah ada personil yang

ditugaskan untuk mencari hal-

hal tersebut?

Pro5.2.2

New processes, services,


tools are assessed and introduced

at the request level.

Apakah proses, layanan,

teknologi, metodologi, dan

tools baru tersebut dinilai dan

diperkenalkan/ditangani

sebagai suatu permintaan

pemeliharaan noncritical?

(Misalnya dimasukkan ke

dalam ticketing, jadi

kegiatannya juga terekam)

Pro5.2.3

Improvements to some maintenance

processes, services, technologies,

,methodologies, and tools have

been initiated, in a controlled way,

locally.

Apakah ada

peningkatan/perbaikan dari

proses pemeliharaan perangkat

lunak, layanan, teknologi,

metodologi, dan tools yang

sudah diterapkan secara

terkendali?

KPA Event/Request Management (Req1)

Req1.0.1


organization does not manage

(record, assign, control, and

measure) the events and incoming

service requests.


menugaskan, merekam,

mengendalikan, mengukur,

kejadian-kejadian dan

permintaan layanan?

Req1.1.1

Customer requests and system

events, inside the software

maintenance organization, are

Kalau ya, apakah pengaturan

tersebut secara informal?



61


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

managed informally.

Req1.1.2

An individual approach for

management of customer requests

and of system events exists. It is

mainly based on the personal

relationship between the

maintenance programmer and a

resources in the customer/user

organization. Customers/users

interact differently based on the

nature of this contract.

Apakah penanganan kejadian

atau permintaan dari pengguna

berbeda-beda oleh tiap

petugas? Ataukah ada

standarisasi alur penanganan?

Apakah penanganan tersebut

tergantung relasi/hubungan

antara petugas dengan

pengguna? Apakah interaksi

antara pengguna dengan

petugas berbeda-beda

tergantung hubungan mereka?

Req1.2.1

Each customer/user and system has

a documented contact point that

provides maintenance services.


memiliki contact person

khusus untuk tiap tipe

pengguna dan sistem? Apakah

terdokumentasi?

Req1.2.2

Each customer request and system

incident is recorded by the

maintenance organization or its

agent (i.e., the help desk) and

generates a support request (SR), a

modification request (MR), or a

problem report (PR).

Apakah tiap permintaan atau

insiden direkam dalam suatu

sistem (misalnya oleh help

desk)? Apakah setelah itu

diterbitkan Support Request

(SR), Modification Request

(MR), atau Problem Report

(PR)?

Req1.2.3

Each customer request and event is

first accepted or rejected, and then,

if accepted, is assigned a service

category, a priority, and a

preliminary estimate of its size and

scope.

Apakah ada penyaringan atas

permintaan yang masuk,

misalnya help desk menerima

atau penolak permintaan?

Kalau diterima, apakah

diberikan kategori layanan,

prioritas, dan perkiraan ukuran

dan lingkup kerja?

Req1.2.4

The accepted modification requests

are assigned, in a preliminary way,

to a future version of the software.

Apakah suatu MR ditentukan

akan dirilis ke versi perangkat

lunak yang mana?

KPA Maintenance Planning (Req2)

Req2.0.1

The maintenance organization does

not conduct planning activities and

does not produce and publish

plans.


melakukan perencanaan

(misalnya tahunan) yang

berkaitan dengan pemeliharaan

(misalnya penyempurnaan atau



62


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

juga preventif)?

Req2.1.1

Planning in the organization for

software maintenance is carried

out in an informal way.

Jika ya, apakah perencanaan

tersebut secara informal?

(Tidak terstruktur, bersifat

reaktif, predelivery and

transition baru dilakukan saat-

saat terakhir, perencanaan

dibuat sporadis dan tidak

konsisten. Perencanaan ada,

tapi hanya sedikit yang

dilaksanakan)

Req2.1.2

Individual initiatives for planning

are mainly aimed at informing

customers, verbally, of the

possibility of processing a specific

and ad-hoc request.

Apakah perencanaan baru di

tingkat individual (bukan

tingkat departemen)? Misalnya

personil memberitahukan

secara verbal terhadap

pengguna tentang

kemungkinan pemrosesan

permintaan ad-hoc.

Req2.1.3

Customer requests and project

predelivery and transition are

processed in a reactive way, as

opposed to a planned way.

Apakah pemrosesan

permintaan pelanggan dan

project predelivery and

transition dilakukan secara

reaktif, bukan secara

terencana?

Req2.2.1

There is a planning policy at the

organizational level. Software

maintenance publishes a

maintenance plan for a 1-to 3-year

view. This plans includes the

objects, scope, goals, objectives,

and deliverables, and some others

which are important software

maintenance planning subjects

concerning services, processes,

resources, and products.


membuat rencana pemeliharaan

(misalnya 1 sampai 3 tahun)?

Apakah di dalam rencana

tersebut ada objek

pemeliharaan, skop, tujuan dan

sasaran, dan deliverable, dll.?

Req2.2.2

The maintenance plan (1 to 3

years) is elaborated and updated

yearly, according to a documented

procedure.

Apakah ada jadwal reguler

untuk memperbaharui rencana

pemeliharaan tersebut? Apakah

ada prosedur terdokumentasi

untuk perbaharuan tersebut?

Req2.2.3

The maintenance planning

activities follow the standards of

the organization and are

Apakah kegiatan perencanaan

pemeliharaan mengikuti

standar perencanaan

Tabel 3.3 Pointer Pertanyaan Wawancara (sambungan) Tabel 3.3 Pointer Pertanyaan Wawancara (sambungan)


63


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

coordinated/aligned with its key

support interfaces (i.e., developers

and operations).

organisasi? Apakah

terkoordinasi dengan

pengembang (developers) dan

operasi (operations)?

Req2.2.4

Maintenance planning (1 to 3

years) considers the possibilities of

rejuvenation of the software

portfolio.

Apakah kegiatan perencanaan

pemeliharaan ada

mempertimbangkan

peremajaan portofolio

perangkat lunak? Apakah ada

studi kasus yang menjelaskan

kegiatan peremajaan seperti

apa yang bisa menguntungkan

perusahaan? Apakah studi

kasus tersebut dipresentasikan

kepada pemangku kepentingan

untuk mendapatkan persetujuan

mereka?

Req2.2.5

The maintenance plan (1 to 3

years) considers the resources

needs (personnel, infrastructure,

and tools).

Apakah rencana pemeliharaan

mempertimbangkan kebutuhan

sumber daya (seperti personil,

infrastruktur, dan tools)?

Req2.2.6

Pre-delivery and transition

planning are included and initiated

during the early stages of an IS/IT

project.

Apakah kegiatan predelivery

and transition sudah

direncanakan dari tahap awal

proyek SI/TI?

Req2.2.7

Every software project stakeholder

is aware of the need to plan pre-

delivery and transition activities.

Apakah para maintainer sudah

ikut serta dalam perencanaan

awal untuk predelivery and

transition bersama dengan

developer? Apakah unit-unit

yang berkepentingan sudah

diundang dalam rapat

predelivery and transition?

Req2.2.8

The predelivery and transition

activities are part of the developer's

main project schedule.

Apakah rencana transisi dibuat

bersamaan dengan rencana

pengembangan lainnya?

Apakah standar untuk rencana

transisi sama dengan standar

untuk pengembangan lainnya?

Apakah rencana transisi sudah

diturunkan dari rencana

pengembangan? Apakah

rencana transisi, jika ada

perubahan, dijaga agar tetap



64


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

relevan dibandingkan dengan

rencana pengembangan?

Req2.2.9

The predelivery and transition plan

describes the relationship with the

other development and

infrastructure deployment plans.

Apakah rencana predelivery

and transition jelas

hubungannya dengan rencana-

rencana tahunan, transisi, atau

penanganan permintaan?

1. Hubungannya dengan

rencana infrastruktur dan tools

untuk mendukung perangkat

lunak baru?


rencana pelatihan dari HR?


rencana configuration

management, rencana kualitas,

rencana pengujian?

Req2.2.10

Maintenance test and support

activities, techniques and tools

needed for the new software are

defined in the predelivery and

transition plans.

Apakah rencana predelivery

and transition sudah merinci

kegiatan pengujian, dukungan,

teknik dan tools yang akan

digunakan?

Req2.2.11

The predelivery and transition plan

assesses, documents, and approves

the risks linked to technical aspects,

the costs (hardware, software, and

licenses), human resources

requirements and final transition

schedule.

Apakah dalam rencana

predelivery and transition

sudah ada risk assessment yang

berkaitan dengan aspek teknis,

biaya, SDM , dan jadwal

transisi?

Req2.2.12

Every maintained software product

identifies whether or not a disaster

recovery service is offered. The

maintainer has identified,

documented, and communicated its

testing role (application recovery

vs. platform recovery), testing

frequency, and the limits to his

responsibilities.

Apakah masing-masing SI

sudah diidentifikasi kebutuhan

layanan disaster recovery-nya?

Apakah maintainer sudah

mengidentifikasi,

mendokumentasikan, dan

menginformasikan perannya

dalam: pengujian, frekuensi

pengujian, dan batas tanggung

jawabnya?

Req2.2.13

The data, programs, scripts, and

critical documentation are copied

and stored outside the maintenance

site, and this is done on a regular

basis.


membuat salinan dari data,

program, script, dokumentasi

kritis, dan menyimpan

salinannya di luar Departemen



65


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

TI? Apakah dilakukan secara

reguler?

Req2.2.14

A disaster recovery service may be

offered. When offered, the detailed

disaster recovery plan is tested

(including the business recovery

and data center recovery, if

available) and reviewed as per the

terms indicated in the agreements.

Apakah layanan pemulihan

bencana (disaster recovery)

merupakan bagian dari layanan

Departemen TI? Kalau ya,

apakah rencana pemulihan

bencana sudah diuji dan diulas

kesesuaiannya terhadap SLA?

Req2.2.15

The software versions and

upgrades are produced, by the

maintainer, as soon as possible.

Apakah perbaikan terhadap

kesalahan langsung

dilaksanakan? Untuk MR,

apakah maintainer memberi

tahu pengguna terlebih dahulu

sebelum

mengimplementasikannya?

Req2.2.16

The maintenance manager

dynamically assigns the request

workload.

Apakah ada orang yang

bertugas:

1. Sebagai contract person

dengan pengguna?

2. Memberikan masukan pada

prioritas pengerjaan

berdasarkan:

2.a. perubahan infrastruktur

dan operasi/prosedur?

2.b. Proyek-proyek dalam

pengembangan atau transisi?

2.c. Siklus produksi tahunan?

2.d. Kesalahan/kegagalan

sistem saat ini?

2.e. Kesepakan kontraktual

dengan mitra atau pemasok?

2.f. Masukan dari manajer

Departemen TI?

3. Melakukan analisis dampak

(impact analysis) dan verifikasi

hasil analisis tersebut dengan

para programmer?

4. Memastikan SDM

pemeliharaan paham tentang

prioritas yang sudah diatur

tersebut?

5. Memastikan SDM

pemeliharaan bekerja



66


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

berdasarkan prioritas yang

sudah diatur tersebut?

6. Memastikan proses-proses

pemeliharaan diikuti?

Req2.2.17

The operational maintenance plan

is used to track the status of each

customer request and to

communicate the status of the work

load.

Apakah daftar kegiatan dalam

rencana pemeliharaan

digunakan untuk melacak

status dari tiap permintaan

pengguna, dan untuk

menginformasikan beban

kerja?

Req2.2.18

The customer request priority is

assigned in close collaboration

with the end user, according to a

documented procedure.

Apakah daftar kegiatan

tersebut didiskusikan dengan

para pengguna? Apakah

persetujuan mereka untuk

daftar tersebut didaftarkan?

Apakah ada prosedur

terdokumentasi untuk kegiatan

ini? Apakah

mempertimbangkan aspek

finansial? (misalnya

menggunakan cost benefit

analysis)

Req2.2.19

PRs are rerouted to the appropriate

support group only when the

current holder has documented its

intervention. Intergroup

relationships and processes are

documented and negotiated.

Jika ada PR (Problem Report)

yang penyelesaiannya akan

mempengaruhi banyak

pengguna, apakah persetujuan

mereka untuk penyelesaian

tersebut didapatkan? Ada

prosedur terdokumentasi? Atau

maintainer langsung

melakukan perbaikan, dan

hanya melakukan sosialisasi

setelah selesai?

Req2.2.20

A support and modification request

capacity plan is created. The plan

takes into account the maintenance

plan (1 to 3 years) and the

individual SLAs.


memiliki rencana kapasitas

permintaan (request capacity

plan)? Apakah rencana tersebut

mempertimbangkan rencana

pemeliharaan (yang 1 sampai 3

tahun) dan semua SLA?

KPA Request/Software Monitoring and Control (Req3)

Req3.0.1 The software maintenance

organization does not track or


melacak atau memantau



67


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

monitor its service/product

commitments.

komitmen layanan atau

produknya?

Req3.1.1


service/product tracking and

monitoring is carried out

informally.

Kalau ya, apakah secara

informal? (Misalnya masing-

masing maintainer melakukan

pemantauan sendiri-sendiri,

tanpa kendali dari manajemen)

Req3.2.1

The maintenance engineer ensures

that the software is monitored and

that the activities for solving

technical problems of production

software are coordinated.

Apakah para maintainer

diberikan tanggung jawab

memantau perangkat lunak

produksi? Apakah ada jadwal

dukungan di luar jam kerja

yang sudah disetujui

manajemen? Apakah ada

prosedur terdokumentasi untuk

dukungan antar grup

(pengguna, infrastruktur,

pengembang, pemasok, dan

help desk)?

Req3.2.2

The commitments of various

stakeholders, as agreed upon in the

maintenance plans, are tracked on

a periodic basis.

Apakah ada sesi ulasan

(review) dengan pengguna

untuk urusan pemeliharaan

secara berkala? Apakah

komitmen pengguna untuk

urusan pemeliharaan dipastikan

oleh manajer? Apakah

perubahan komitmen pengguna

dilacak (tracked)?

Req3.2.3

A review of each production

software service level, monitored

by maintenance engineers, is

presented at the weekly

maintenance management meeting.

Apakah ada rapat berkala

(misalnya mingguan) untuk

mengulas hasil pemantauan

tingkat layanan (SLA)?

Misalnya untuk mendiskusikan

nilai availability, panggilan

telepon di luar jam kerja, dan

untuk permintaan yang lagi

dalam proses dan yang lagi

menunggu? Apakah ada

diskusi /antisipasi tentang

kasus-kasus yang tidak akan

memenuhi SLA? Apakah hasil

rapat didokumentasikan?

Req3.2.4 External and internal maintenance

commitments are managed and

Apakah komitmen

pemeliharaan eksternal dan



68


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

reviewed periodically with software

maintenance management.

internal diatur, dan diulas

secara periodik dengan

manajemen pemeliharaan?

Apakah jika diminta,

Departemen TI bisa

menunjukkan saat itu juga

status kerja pemeliharaan yang

dalam proses untuk semua

layanan, permintaan pengguna,

predelivery and transition,

upgrade, pemulihan bencana,

dst., dan bisa dibandingkan

dengan rencana dan komitmen?

Apakah saat diskusi, statusnya

sangat berbeda antara manajer,

maintainer, dan pengguna?

Req3.2.5

The transition plan, including its

schedule, is subject to tracking and

corrective actions, which are

performed if needed.

Apakah rencana transisi

(termasuk jadwalnya) dilacak

perubahannya, dan dilakukan

tindakan korektif (corrective

actions) jika diperlukan?

1. Apakah maintainer memiliki

salinan jadwal predelivery and

transition?

2. Apakah maintainer meninjau

progres aktivitas

mingguan/bulanannya?

3. Apakah maintainer

berpartisipasi dalam rapat

bulanan untuk

menginformasikan kemajuan

prosesnya (telat, on track, on

early)?

4. Apakah maintainer negosiasi

rencana tindakan (yang

disepakati bersama) untuk

tindakan perbaikan masalah?

5. Apakah maintainer meminta

informasi tentang

perbaikan/perubahan terakhir

terhadap kegiatan predelivery

and transition?

Req3.2.6 The maintenance commitments are

tracked and renegotiated, if needed.

Jika ada perubahan komitmen,

apakah maintainer memastikan



69


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

kesepakatan semua pemangku

kepentingan?

KPA SLA and Supplier Agreements Management (Req4)

Req4.0.1

Software maintenance management

has not yet recognize the need for

formal contracts and SLAs.

Apakah ada yang bertugas

untuk menentukan dan

memantau tingkat layanan

(SLA)? Apakah ada prosedur

untuk membuat kontrak dan

SLA dengan pemasok dan

pengguna/pelanggan? Apakah

ada ukuran kepuasan terhadap

pemasok atau terhadap layanan

pemeliharaan Departemen TI?

Apakah ada survei kepuasan?

Dengan apa manajemen

mengamati indikator kualitas

layanan?

Req4.1.1

The agreements with clients,

subcontractors, and outsourcers

are elaborated from templates,

documents, and contracts from

suppliers and subcontractors.

Apakah ada template untuk

kontrak dengan pengguna /

klien, subkontraktor,

outsourcer, dll.? Bagaimana

cara mengukur kepuasan

(kualitatif/kuantitatif)? Apakah

tugas memantau dan

mengendalikan

permintaan/perangkat lunak

bersifat informal? Apakah ada

laporan kinerja personil atau

untuk keseluruhan Departemen

TI? Untuk apa laporan tersebut

digunakan? Apakah digunakan

untuk pengambilan keputusan?


menegosiasikan kesepakatan

dengan pemasok (jadi bukan

hanya menerima)? Apakah jika

Departemen TI tidak sepakat

dengan pemasok, maka

negosiasi atau langsung ganti

pemasok?

Req4.2.1

Preliminary discussions are held

on the introduction of a more

formal SLA and contracts.


mengadakan pengenalan apa

itu kontrak/SLA formal?

Apakah ada ditunjukkan



70


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

manfaat dari kontrak/SLA

formal?

Req4.2.2

A maintenance engineer is assigned

as an account manager to plan and

coordinate the customer account

management activities.

Apakah ada maintainer yang

ditugaskan sebagai account

manager? Apakah pekerjaan

tersebut bersifat penuh waktu,

ataukah persentase dari

pekerjaan?

Req4.2.3

The stakeholders (customers, end

users, maintainers, developers,

operations, and suppliers) agree on

the necessity for more formal SLAs

and contracts concerning software

maintenance.

Apakah para pemangku

kepentingan (pengguna,

pelanggan, maintainer,

pengembang, operasi, dan

pemasok) setuju akan

kebutuhan penggunaan SLA

dan kontrak formal dalam


Sudah adakah kesepakatan

antara pengguna / pelanggan

tentang definisi layanan,

tingkat kinerja, dan cara

pengukurannya? Apakah ada

rapat berkala (misalnya

tahunan) untuk mendiskusikan

dan negosiasi berdasarkan

perubahan proses dan tools?

Apakah sudah ditentukan

petugas untuk komunikasi

pengguna dengan maintainer?

Apakah ada proses untuk

memperbaiki uraian pekerjaan?

Apakah ada proses untuk

menangani permintaan layanan

yang tidak termasuk dari

layanan pemeliharaan?

Req4.2.4

The maintainer selects and

reassesses suppliers and

subcontractors. The selection and

assessment is based on assessment

of their capabilities to meet the

specified conditions and

established criteria stated in the

SLAs.

Apakah pemilihan

pemasok/vendor berdasarkan

kapabilitas mereka untuk

memenuhi kriteria yang sudah

kita tentukan dan untuk

memenuhi SLA kita? Ada

prosedur untuk pemilihan

vendor?

Req4.2.5 A maintenance SLA, supplier, and

subcontractor contract template is

Ada dokumen template kontrak

untuk SLA pemeliharaan,



71


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

defined, documented, and

approved.

untuk pemasok, dan

subkontraktor?

Req4.2.6

The SLA concluded between the

maintainer and the customer

establishes the foundation of the

management of the relationship.

Apakah sebelum SLA

disepakati, acuan kinerja saat

ini sudah terdokumentasi?

Apakah Departemen TI bisa

mengukur kapabilitas yang

diatur dalam SLA? Apa

indikator kinerja (KPI) dan

bagaimana cara mengukurnya?

Req4.2.7

The modifications to the scope of

work given to the subcontractors,

to modalities of the contract for

subcontracting, and the SLAs are

made according to a documented

procedure. Changes to

commitments are reviewed and

agreed between stakeholders.

Apakah sudah ada prosedur

untuk modifikasi skop kerja

yang diberikan ke

subkontraktor? Sudah ada

prosedur terdokumentasi untuk

meninjau, mengadaptasi,

mengoordinasikan informasi

kontraktual?

Req4.2.8

Formal reviews on the execution

and results of services provided are

conducted at selected milestones,

according to a documented

procedure.

Apakah ada tinjauan formal

terhadap hasil eksekusi layanan

pada milestone yang dicapai?

Ada prosedur terdokumentasi?

Dilakukan secara berkala (4

kali setahun)? Apakah ada

diskusi tindakan korektif

(corrective action) jika kinerja

menyimpang secara signifikan?

Req4.2.9


establishes a policy for billing

services.


memiliki kebijakan untuk

menagih (secara internal)

terhadap layanan yang

dilakukannya?

Req4.2.10

Internal customers who are bound

to the services of the internal IS/IT

maintainer will engage in a

simulated billing.

Apakah ada simulasi tagihan

untuk layanan pemeliharaan?

Req4.2.11


designs, documents and presents its

bill to its many service customers.


memiliki sistem tagihan

(billing system) yang

digunakan untuk membuat

tagihan terhadap layanannya?

Req4.2.12 The SLA indicators are used for

billing purposes.

Apakah proses pengukuran

SLA dan laporan kinerja juga

digunakan untuk tagihan



72


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

layanan Departemen TI?

Req4.2.13

Raw data describing costs are

available for some maintenance

resources (personnel, systems,

contracts/licenses). Maintenance

billing captures, presents, and

explains the most important cost

elements.

Apakah Departemen TI mampu

membuat laporan tentang

biaya-biaya yang digunakan

dalam kegiatan pemeliharaan?

Apakah bisa dibagi

berdasarkan kategori

pemeliharaan?

KPA Predelivery and Transition Services (Evo1)

Evo1.0.1



activities of software predelivery

and transition before the handover

of a software.


melakukan kegiatan


sebelum serah terima perangkat

lunak dari pengembang ke

pemelihara?

Evo1.1.1

Pre-delivery and transition, within


organization, is carried out in an

informal way.

Jika ada, apakah secara

informal? Apakah ada prosedur

terdokumentasi? Apakah ada

kebijakan yang mengharuskan

hal tersebut? Atau berupa

inisiatif pribadi?

Evo1.2.1


organization communicates with

the developer to clarify and agree

on predelivery and transition

activities required for the software.

Apakah maintainer

berkomunikasi dengan

developer mengenai kegiatan


Pada tahap life-cycle apa

maintainer mulai terlibat dalam

proyek? Dalam TOT antara

developer dengan maintainer,

apa saja yang ditransfer

(produk intermediate, tools,

pengetahuan)? Apa kriteria

yang digunakan untuk

menentukan sudah saatnya

melakukan transisi?

Evo1.2.2


organization manages the

relationship with the developer and

the customer proactively. The

objective is that there be no conflict

or resistance regarding software


activities.

Apakah maintainer secara

proaktif mengangkat isu

predelivery and transition ke

hadapan developer dan

pelanggan/pengguna/pemangku

kepentingan?



73


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

Evo1.2.3


organization communicates

proactively with the purchasing

organization (or directly with the

developers) to ensure that software

maintenance predelivery and

transition considerations are

included in the contract, as well as

in the project development plan and

schedule.

Apakah maintainer secara

proaktif mengangkat isu

predelivery and transition ke

hadapan orang yang bertugas

untuk pengadaan, di tahap awal

proyek pengembangan?

Apakah maintainer

menyampaikan requirement

yang berkaitan dengan

maintainability dan predelivery

and transition?

Evo1.2.4


organization communicates with

the customer to ensure that the

predelivery and final transition

activities are well understood. In

addition, this communication

activity is used to introduce the

basic notions of the software.


melakukan sosialisasi kegiatan


kepada pelanggan/pengguna?

Atau apa yang dilakukan

Departemen TI untuk

memastikan

pelanggan/pengguna paham

tentang apa yang akan mereka

alami selama transisi? Apakah

pengguna diberi tahu tentang

masalah yang masih belum

diselesaikan dalam

pengembangan yang akan

diserahkan kepada maintainer?

Apakah ada sosialisasi proses

dukungan? Apakah ada

sosialisasi kepada pengguna

tentang layanan apa saja yang

nantinya akan disediakan oleh

Departemen TI untuk

pemeliharaan perangkat lunak,

dan siapa saya yang bertugas

sebagai pemelihara? Apakah

ada sosialisasi tentang SLA?

Evo1.2.5


organization develops, adapts, and

uses a checklist to follow up on

deliverables and key activities of

the predelivery and transition of

software.


membuat, mengadaptasi, dan

menggunakan checklist untuk

memastikan kebenaran

deliverable dan aktivitas-

aktivitas predelivery and

transition? Apakah Departemen

TI membuat - berdasarkan



74


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

pengalaman - daftar kegiatan

predelivery and transition, dan

hal-hal penting yang

berkontribusi terhadap transisi

yang mulus dan efektif?

Apakah checklist ini juga

digunakan sebagai alat

komunikasi dengan pemangku

kepentingan?

Evo1.2.6


engineers assigned to support the

software obtain information and

knowledge to facilitate the final

transition of the software from

development to maintenance.


diberikan pelatihan, informasi,

dan pengetahuan sesuai dengan

yang dinyatakan oleh

developer, untuk memfasilitasi

transisi perangkat lunak dari

pengembangan ke

pemeliharaan?

Evo1.2.7


organization ensures the

effectiveness of maintenance

training (on infrastructure,

architecture, software, and

documentation) provided by the

developer before final transition.


memastikan pelatihan untuk

pemeliharaan (untuk

infrastruktur, arsitektur,

perangkat lunak, dan

dokumentasi) yang diberikan

oleh pengembang memang

efektif? Apakah ada

perbandingan antara tujuan

pelatihan terhadap hasil

pelatihan? Kalau tidak sesuai,

apa tindakan perbaikannya?

Evo1.2.8


organization evaluates and

discusses the efficiency and

effectiveness of the user training

undertaken by the customer (in

terms of access, functionality, help

function, and user documentation)

and recommended by the

developer. This must be done

before the final software transition.

Apakah sebelum transisi,

Departemen TI mengevaluasi

dan mendiskusikan efisiensi

dan efektivitas pelatihan untuk

pengguna/pelanggan?

Evo1.2.9

Software maintenance engineers,

who are responsible for conducting

the final transition, ensure that the

product documentation is obtained,

that they understand its interfaces,

Apakah maintainer

membuat/menjaga kekinian

inventori lisensi, pengguna,

lingkungan, dan dokumen

teknis? Apakah maintainer



75


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

data, and operational environment,

and that they update the

outstanding problems log before

final transition.

mengerti antar muka, data, dan

lingkungan operasional?

Apakah daftar masalah yang

belum diselesaikan selama

pengembangan di-update?

Evo1.2.10

Software maintenance engineers,

who are responsible for conducting

the final transition, ensure that the

final configuration of the source

code that will be used to evolve the

software after final transition is

obtained.


memastikan bahwa

konfigurasi/versi source code

yang dimilikinya adalah

konfigurasi/versi yang akan

digunakan untuk evolusi

perangkat lunak setelah transisi

akhir? Apakah maintainer

sudah memastikan dia bisa

membuat perubahan perangkat

lunak, compile, menguji, dan

memindahkan perubahan

tersebut ke sistem produksi?

Evo1.2.11


engineers, who are responsible for

conducting the final transition,

ensure that the official list of

outstanding problems found during

systems testing and acceptance

testing are obtained. For each

problem, he/she will record their

categories, priority, and status in

order to identify and make visible,

to the customer, the extent of the

request backlog that is being

transferred from development to

maintenance after the final

transition.

Apakah maintainer, dalam

menjaga kekinian daftar

masalah yang belum

diselesaikan dalam

pengembangan,

mengelompokkan berdasarkan

kategori, prioritas, dan status,

agar pengguna/pelanggan

paham tentang luasnya backlog

yang ditransfer oleh

pengembang kepada

pemelihara setelah transisi

akhir? (Tujuannya adalah

untuk menjaga ekspektasi

pengguna, dan untuk

memastikan skop pekerjaan

awal maintainer)

KPA Operational Support Services (Evo2)

Evo2.0.1


not provide operational support

services.


menyediakan layanan

dukungan operasional?

Evo2.1.1

The operational support service, in


organization, is offered informally.

Apakah dukungan tersebut

bersifat informal? Apakah

definisi layanan dukungan

operasional jelas? Apakah

kegiatannya direkam/dicatat?



76


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

Apakah SLA ini ditentukan?

Evo2.2.1

A software operation schedule

(online and batch) exists and is

established on the basis of resource

capability and software workload.

Apakah maintainer memiliki

jadwal operasi perangkat lunak

(misalnya untuk batch update,

script update, update untuk

perangkat lunak,

transfer/sinkronisasi data antar

sistem)?

Apakah maintainer

memastikan bahwa dia selalu

memiliki jadwal yang terbaru,

perubahan terbaru, update

terakhir? Apakah maintainer

memonitor perubahan perilaku

perangkat lunak?

Evo2.2.2

The maintenance engineer and the

operations organization are aware

of their mutual responsibilities for

monitoring of each piece of

operational software. The

maintenance engineers monitor the

software proactively in conjunction

with the computer operations that

typically monitor infrastructure

(memory, communication links, and

disk space).

Apakah pembagian tugas

pemantauan perangkat lunak

jelas? Bagaimana cara

Departemen TI membagi tugas

memantau perangkat lunak?

Yang mana seperti apa yang

dipantau bagian operasi (tim

infrastruktur dan tim help

desk)? Yang seperti apa yang

dipantau tim developer (yang

juga merupakan maintainer di

Departemen TI)? Misalnya:

tugas untuk backup, defrag,

clustering, database

administration, proses

pengujian perangkat lunak

setelah pemulihan dari

kegagalan/kesalahan (berbeda

dengan unit testing dan UAT),

dan tugas meng-update jadwal

otomatis.

Evo2.2.3

The maintainer produces

monitoring reports on the key

characteristics for each service and

of each piece of operational

software.

Apakah maintainer membuat

laporan pemantauan

berdasarkan karakteristik kunci

dari tiap layanan dan masing-

masing perangkat lunak

operasional?

Laporan ini bisa digunakan

untuk manajemen SLA,



77


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

komunikasi dengan

pelanggan/pengguna, dan

melihat tren untuk

mencegah/memperbaiki

kerusakan/kegagalan.

Evo2.2.4

The support schedule is created,

updated, and published. It is built

to ensure a service coverage as

agreed upon and described in the

SLAs.

Apakah ada jadwal dukungan

sistem? Apakah di-update dan

dipublikasikan (internal)?

Yang dimaksud dengan jadwal

adalah daftar personil yang bisa

dihubungi, yang dalam jam

kerja, dan yang di luar jam

kerja.

Apakah ada prosedur

terdokumentasi untuk

menghubungi maintainer

dalam kasus

kegagalan/kesalahan sistem di

dalam dan di luar jam kerja?

Evo2.2.5

The maintenance engineer has

functional and business rule

expertise about the software he/she

maintains.

Apakah maintainer mampu

menjawab pertanyaan

pengguna tentang

fungsionalitas dan aturan bisnis

(business rules) untuk

perangkat lunak yang

dipeliharanya? Apakah

maintainer mampu

mengevaluasi source code lalu

memberikan gambaran /

menjelaskan kepada pengguna

tentang jalannya program?

Apakah manajemen paham

tentang usaha yang diperlukan

untuk kegiatan ini (berarti hal

ini dianggap sebagai satu

kategori layanan Departemen

TI)?

Evo2.2.6 The maintenance engineer offers ad

hoc services on demand.

Apakah maintainer:

1. dapat membantu pengguna

untuk lebih memahami data

atau aturan ekstraksi data?

2. merancang dan

mengeksekusi laporan ad-hoc?

(yang hanya hasilnya langsung



78


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

diberikan ke pengguna, berarti

programnya bukan

dikategorikan sebagai program

operasional atau tidak di-

deploy)

3. Membuat program laporan

yang bisa dijalankan pengguna

kapan pun mereka mau?

4. Bekerja bersama dengan tim

operasi (infrastruktur atau help

desk) yang memerlukan

pengetahuan dalam perangkat

lunak?

Apakah usaha-usaha ini diakui

sebagai layanan Departemen

TI? Berarti dipublikasikan,

didokumentasikan, dan diukur,

sama seperti layanan


lainnya?

KPA Software Evolution and Correction Services (Evo4)

Evo3.0.1


organization does not provide

correction and evolution services

for software.


menyediakan layanan koreksi

dan evolusi perangkat lunak?

Evo3.1.1


organization provides informal

correction and evolution services

for software.

Apakah layanan tersebut

bersifat informal? Apakah

proses koreksi mengikuti suatu

prosedur yang terdokumentasi,

atau terserah maintainer?

Apakah ada prosedur

pemilihan maintainer untuk

masing-masing tipe permintaan

koreksi/evolusi?

Evo3.2.1

The detailed design elaborates the

requirements of the user, and it is

developed according to a


Apakah requirement dalam

MR (modification request)

untuk pemeliharaan cukup

detail?

Apakah ada mengidentifikasi

komponen apa saja yang harus

diubah? Apakah

mengidentifikasi dokumentasi

apa saja yang harus diubah?



79


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

Evo3.2.2

The activities of investigation and

design associated with a failure

(documented in a PR) are

performed according to a


Apakah PR diproses seperti

CR/MR?

Seharusnya tidak, karena tidak

ada analisis dampak dan tidak

ada permintaan otorisasi untuk

deployment kepada pelanggan,

karena maintainer harus

bekerja dengan cepat untuk

memperbaiki kesalahan, lalu

mendokumentasikan

perubahannya setelah itu.

Apakah ada prosedur


penyelesaian PR?

Evo3.2.3

The activities of implementation

(programming) are performed


procedure.

Apakah ada prosedur

terdokumentasi untuk untuk

implementasi/programming?

Misalnya: programming and

naming conventions, life-cycle

stages?

Evo3.2.4

The roles and responsibilities

concerning operational data

modifications are formally defined

for the maintenance engineer.

Apakah ada prosedur


modifikasi data operasional?

Apakah perlu minta izin

pemilik data terlebih dahulu?

Apakah pemangku kepentingan

diberi tahu bahwa akan/sudah

ada perubahan data? Apakah

maintainer menyimpan berkas-

berkas komunikasi/otorisasi

untuk permintaan modifikasi

data operasional tersebut?

Evo3.2.5

The original programming

languages of the software

maintained are used for the

corrections and evolution of the

software.

Apakah evolusi perangkat

lunak yang dipelihara,

menggunakan bahasa

pemrograman yang sama

dengan dengan saat perangkat

lunak tersebut dikembangkan?

Apakah ada kasus di mana

tidak demikian? Kenapa

(misalnya karena cost benefit

analysis)? Apakah ada

prosedur yang digunakan untuk

menentukan kapan boleh tidak



80


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

menggunakan bahasa

pemrograman yang sama?

Evo3.2.6

The interrelationships (traceability)

between the administrative

procedures, the modules, the

processes, and the data are

updated when the software is

corrected and evolved.

Apakah dalam evolusi

perangkat lunak, dokumentasi

yang perlu di-update

diidentifikasi? Apakah bisa

dilacak antara PR/MR dengan

prosedur/proses yang mana,

modul yang mana, data yang

dimodifikasi? Apakah bisa

backtracking/rollback

perubahan perangkat lunak

atau data? Ada prosedurnya?

Ada tool untuk melacak ini?

Evo3.2.7

The unit tests must be performed

for each component that is the

subject of a modification.

Apakah ada unit test untuk

tiap-tiap modifikasi? Apakah

ada rencana unit test? Apakah

ada prosedur pembuatan data

untuk pengujian?

Tujuannya untuk memastikan

perubahan sudah sesuai dengan

requirements.

Apakah hasil unit testing

didokumentasikan?

Tujuannya adalah untuk

membuktikan perubahan tidak

mendestabilisasi perangkat

lunak.

Evo3.2.8

The integration and regression

tests must be performed for each

component that is the subject of a

modification.

Apakah ada integration test?

Regression test? Apakah

dilakukan untuk tiap

perubahan? Apakah ada

rencana integration test dan

regression test? Apakah ada

prosedur pembuatan data untuk

pengujian ini?

Tujuannya adalah untuk

meminimalisasi efek samping

yang tidak diinginkan setelah

adanya perubahan perangkat

lunak

Evo3.2.9

The documentation of the user is

submitted for testing by the

maintainer during the unit tests and

Apakah dokumentasi untuk

pengguna di juga diuji saat

unit/integration/regression



81


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

the integration tests. testing?

Jika iya, dan jika ditemukan

kesalahan di dokumentasi

pengguna, apa yang dilakukan?

Evo3.2.10

The internal documentation of the

software is modified and kept up to

date according to a documented

procedure.

Apakah dokumentasi internal

juga diperbaharui saat ada

perubahan/evolusi perangkat

lunak? Ada prosedurnya?

Evo3.2.11

The external documentation of the

software is modified and kept up to

date according to a documented

procedure.

Apakah dokumentasi eksternal

juga diperbaharui saat ada

perubahan/evolusi perangkat

lunak? Ada prosedurnya?

Seharusnya ada:

1. Apa masalah yang

dipecahkan oleh modifikasi

ini?

2. Apa struktur data / algoritma

yang berubah? Seperti apa

sebelum dan sesudah?

3. Apa perubahan alur data?

KPA Verification and Validation (Evo4)

Evo4.0.1


organization does not perform

verification and validation

activities on the maintained

software.

Apakah ada kegiatan verifikasi

dan validasi untuk


Evo4.1.1



activities for verification and

validation in a structured and

coordinated way.

Kalau ada, apakah secara

terstruktur dan terkoordinasi?

Apakah pengujian dibuat

secara sporadis dan tidak

terencana?

Artinya, apakah rencana

pengujian baru dibuat setelah


selesai dibuat? Apakah ada

personil khusus untuk

pengujian? Apakah

menggunakan tools khusus

pengujian (misalnya

otomatisasi skenario, atau tool

untuk load testing)? Apakah

ada lingkungan khusus untuk

pengujian? Apakah dalam

pengembangan, para



82


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

pengembang

mempertimbangkan cara-cara

pengujian perangkat lunak,

yang nantinya akan transisi ke

pemelihara?

Apakah kegiatannya

terdokumentasi?

Apakah debugging dianggap

sebagai proses testing?

Evo4.2.1

The verification and validation

activities are documented, known,

and planned. The plans are

documented according to a


Apakah ada rencana-rencana

untuk kegiatan verifikasi dan

validasi? Apakah kegiatan

yang sudah dijalankan

didokumentasikan? Apakah

ada prosedurnya? Apakah ada

template untuk membuat

rencana verifikasi/validasi?

Apakah kegiatan ini dilakukan

untuk setiap MR?

Evo4.2.2

Reviews and verification/validation

are performed, selectively, after the

production of some key

intermediate products.

Apakah tinjauan dan

verifikasi/validasi dilakukan

setelah produk intermediate

(produk setengah jadi)

dihasilkan?

Evo4.2.3 Supplier maintenance activities are

selectively reviewed at given steps.

Apakah ada prosedur

peninjauan aktivitas

pemeliharaan oleh

pemasok/vendor?

Evo4.2.4

The acceptance test is performed


procedure to show that the

modified product conforms to and

meets the customer's requirements.

Apakah pengujian (acceptance,

functional, performance,

installation, UAT) sudah ada

prosedurnya?

Evo4.2.5

Regression tests are systematically

and formally performed on all parts

of the software affected by

modifications, including

corrections.

Apakah regression test

dilakukan untuk tiap

modifikasi, termasuk koreksi?

Evo4.2.6

The coordination of the installation

of the test on-site and the software

maintenance with the user are

carried out according to a


Apakah implementasi

dilakukan dengan persetujuan

pelanggan/pengguna? Ada

prosedur terdokumentasi?

Evo4.2.7 The practices surrounding the Apakah kegiatan modifikasi



83


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

installation of software

modifications (including the

installation documentation) are

designed to reduce interruptions of

the daily work of the system.

dirancang untuk mengurangi

interupsi kerja pengguna?

Evo4.2.8

The maintenance engineer

participates in acceptance tests

during the final transition of

software from the subcontractor

and supplier, according to a


Apakah maintenance engineer

berpartisipasi dalam

acceptance test saat transisi

akhir? Ada prosedurnya (sesuai

prosedurkah)?

KPA Configuration and Version Management (Sup1)

Sup1.0.1



software configuration



melakukan manajemen

konfigurasi?

Sup1.1.1


organization unit does not perform

software configuration

management activities in a

structured and coordinated

manner.

Apakah dilakukan secara

terstruktur dan terkoordinasi?

Apakah maintainer konfigurasi

sendiri berdasarkan struktur

direktori, tanpa bantuan tool

untuk CM?

Sup1.2.1

Modification requests are

documented, prioritized, and

authorized by the customers before

implementing a change to the

application software.

Apakah MR

didokumentasikan,

diprioritisasi, dan diotorisasi

oleh pelanggan/pengguna

sebelum implementasi

perubahan perangkat lunak?

Sup1.2.2

The configuration management

plan, documented and approved by

the developer (if available), is used

as a basis for starting the

maintainer's configuration


Apakah ada rencana CM dari

pengembang? Apakah

digunakan sebagai dasar

kegiatan CM oleh pemelihara?

Apa tool yang digunakan?

Apakah konfigurasi didapat

sebelum transisi akhir?

Sup1.2.3

Configuration management systems

are used to handle production

versions of the software

maintained.

Apakah maintainer


pendukung yang terotomatisasi

untuk mendukung CM dari

perangkat lunak aplikasi versi

produksinya?

Sup1.2.4

The maintained source code is

handled by configuration

management control.

Apakah maintainer

menggunakan kendali CM

untuk source code perangkat



84


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

lunak aplikasi?

Sup1.2.5

Documentation management is in

place in the maintenance

organization for each MR

(creation, modification, version,

archiving, diffusion, destruction,

and validation).

Apakah ada manajemen

dokumentasi di Departemen

TI? Apakah untuk tiap MR ada

pencatatan untuk: kapan dibuat,

dimodifikasi, versi, arsip,

penghapusan, dan validasi?

Sup1.2.6

Configuration elements and the

configuration image are modified

formally, according to a


Apakah ada prosedur


modifikasi elemen

terkonfigurasi?

Sup1.2.7

There is traceability between the

CRs, the requirements, the detailed

designs, and the source code at one

end, and the integration testing sets

at the other.

Apakah bisa dilacak

(traceability) antara CR,

requirement, rancangan, source

code, terhadap integration test?

Sup1.2.8

Standardized reports that document

configuration management

activities and the content of the

images produced are developed

and made available to the

concerned groups and people.


membuat laporan yang

terstandarisasi untuk urusan

CM? Apakah ada mekanisme

untuk menyebarluaskan

konfigurasi terhadap pihak

yang berkepentingan?

KPA Process, Service and Software Quality Assurance (Sup2)

Sup2.0.1

Quality assurance is not performed

by the software maintenance

organization.


melakukan kegiatan/proses

penjaminan mutu (quality

assurance) yang independen?

Sup2.1.1


performs quality assurance

activities informally.

Apakah kegiatan penjaminan

mutu dilaksanakan secara

informal? Apakah satu seksi

menjalankan penjaminan mutu

secara terpisah dan tidak

terkoordinasi dengan seksi

lain? Apakah kegiatan ini

hanya dijalankan setelah

masalah terjadi? Apakah

maintainer memiliki kualifikasi

untuk penjaminan mutu?

Apakah ketidaksesuaian /

ketidakpatuhan terhadap proses

didokumentasikan untuk

tinjauan eksternal yang



85


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

independen (independent

external review)?

Sup2.2.1

Responsibility, authority, and the

relationships between individuals

in charge of managing, executing,

and verifying the work who have an

influence on quality, are defined.


mendefinisikan tanggung

jawab, otoritas, dan hubungan

antara individu-individu yang

bertugas untuk mengatur,

mengeksekusi, dan verifikasi

pekerjaan yang ada

pengaruhnya terhadap kualitas

proses, layanan, dan perangkat

lunak?

Sup2.2.2

A quality assurance plan that

includes the software maintenance

processes/services is established,

documented, approved, and

monitored.


membuat rencana penjaminan

mutu? Apakah di dalamnya

termasuk proses/layanan

perawatan perangkat lunak, dan

didokumentasikan, disetujui

(oleh manajemen), dan

dipantau?

Sup2.2.3

Independent conformity reviews are

performed on critical products or

major changes.


melaksanakan tinjauan

kepatuhan independen terhadap

produk-produk kritis atau

terhadap perubahan besar?

Sup2.2.4

Quality assurance activities are

performed in accordance with the

maintenance methodology criteria.


melakukan kegiatan

penjaminan mutu sesuai

dengan kriteria metodologi


Sup2.2.5

The maintenance organization is

audited to ensure their conformity

with the defined and accepted

process.

Apakah Departemen TI diaudit

untuk memastikan

kepatuhannya terhadap proses

yang sudah didefinisikan dan

diterima?

Sup2.2.6

Product configuration management

audits are performed in accordance

with a documented procedure.

Apakah audit CM produk

dilakukan sesuai dengan

prosedur?

Sup2.2.7

Products are maintained in

accordance with a documented

procedure, covered by the quality

system.

Apakah produk-produk

dipelihara sesuai dengan

prosedur yang terdokumentasi?

Apakah dicakup dalam

penjaminan mutu?

Sup2.2.8 The maintenance organization Apakah Departemen TI



86


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

monitors the suppliers' and

developers' quality assurance

activities, in accordance with a


memantau kegiatan penjaminan

mutu pemasok dan

pengembang? Apakah ada

prosedur terdokumentasi?

Sup2.2.9

Sample of immediate and final

maintenance products are reviewed

for their conformity to customer

request requirements.

Apakah ada tinjauan terhadap

sampel dari produk

pemeliharaan, untuk diperiksa

kepatuhan/kesesuaian terhadap

requirement permintaan dari

pengguna/pelanggan?

Sup2.2.10

Nonconformances observed in

maintenance activities are

documented and handled locally, in

accordance with a documented

procedure.

Apakah ada prosedur untuk

menangani

ketidaksesuaian/ketidakpatuhan

terhadap proses? Apakah

ditangani secara lokal?

Sup2.2.11

Results of quality assurance

activities are the object of

periodical reports presented to the

maintenance management and

engineers.

Apakah hasil QA dimasukkan

dalam laporan berkala yang

dipresentasikan terhadap

manajemen pemeliharaan dan

para maintainer?

Sup2.2.12

Independent conformity review

results are periodically reviewed

with upper management.

Apakah hasil tinjauan

kepatuhan independen ditinjau

secara berkala oleh manajemen

atas?

Sup2.2.13

The maintenance engineers who

manage, execute, and verify work

that has an impact on quality has

the necessary liberty and authority

to report quality issues.

Apakah maintainer bebas dan

berwewenang untuk

melaporkan masalah kualitas?

Biasanya dalam bentuk:

1. Mengambil tindakan untuk

mencegah ketidaksesuaian.

2. Mengidentifikasi dan

mencatat/merekam masalah

kualitas.

3. Mendapatkan,

merekomendasikan, dan

menyediakan solusi

menggunakan saluran

komunikasi yang sudah ada.

4. Verifikasi implementasi

solusi.

5. Mengelola penanganan,

delivery, dan instalasi dari

produk yang tidak sesuai

dengan proses, sampai elemen



87


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

yang tidak sesuai berhasil

dikoreksi.

KPA Maintenance Measurement and Analysis (Sup3)

Sup3.0.1


not measure process/services,

software or personnel.


mengukur dan menganalisis

proses, layanan, perangkat

lunak, atau personil

pemeliharaannya? Apakah ada

pelacakan untuk perkiraan

waktu pengerjaan, sasaran

waktu pengerjaan, atau waktu

pengerjaan sebenarnya?

Sup3.1.1

Measurement and analysis, in the


performed individually by each

manager.

Apakah kegiatan pengukuran

dan analisis untuk


dijalankan secara individu

(oleh manajer pemeliharaan

atau kepala seksi yang bertugas

untuk pemeliharaan)? Atau

kegiatan pengukuran sudah

ada, tapi tidak untuk

pemeliharaan?

Sup3.2.1

The maintainer has defined basic

operational measurements that

meet software maintenance

measurement objectives.


menentukan ukuran-ukuran

dasar operasional untuk

memenuhi tujuan pengukuran


Sup3.2.2

The maintainer performs, analyzes

and produces reports to address

specific requests.

Apakah maintainer bisa

membuat dan menganalisis

laporan untuk kegiatan


KPA Causal Analysis and Problem Resolution (Sup4)

Sup4.0.1


not recognize the need for a

problem resolution and causal

analysis process.

Apakah Departemen TI paham

akan perlunya proses analisis

penyebab dan penyelesaian

masalah?

Sup4.1.1


recognizes the need to have a

problem resolution and causal

analysis process.


melakukan kegiatan mencari

akar permasalahan untuk

memecahkan permasalahan

secara permanen? Apakah

Departemen TI sadar bahwa

kegiatan ini merupakan proses



88


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

yang dilakukan antar seksi?

Apakah kegiatan ini dilakukan

atas inisiatif personil, dan

bukan merupakan kegiatan

yang diperintahkan oleh

manajemen Departemen TI?

Apakah jika permasalahan dan

akar permasalahan berhasil

diidentifikasi, maka

didokumentasikan dan disebar

ke pihak yang berkepentingan?

Sup4.2.1


organization documents its

problems resolution and causal

analysis process.


mendokumentasikan proses

analisis penyebab dan

penyelesaian masalah? Apakah

antar muka masalah dengan

seksi/organisasi lain

diidentifikasi? Apakah

prosesnya berbeda-beda antar

seksi?

Sup4.2.2

Maintenance management analyzes

quality, customer, and performance

data regularly.

Apakah manajemen

menganalisis data kualitas,

pelanggan/pengguna, dan

kinerja secara reguler untuk

mengidentifikasi dan

menganalisis penyebab

masalah?

Sup4.2.3

Upper managers analyze the

results of surveys and develop and

implement an action plan based on

their analysis. These results and the

action plan are communicated to

all personnel.

Apakah manajer tingkat atas

menganalisis hasil dari survei

(misalnya kepuasan

maintainer) dan membuat

rencana tindakan berdasarkan

hasil analisis tersebut? Apakah

hasil analisis dan rencana

tindakan tersebut

dikomunikasikan kembali ke

personil yang terkena

dampaknya?

Sup4.2.4

Process analysis and reports are

produced and distributed to the

concerned groups.


melakukan analisis proses, dan

laporannya dibuat dan

didistribusikan ke kelompok-

kelompok yang

berkepentingan?



89


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

KPA Software Rejuvenation, Migration, and Retirement (Sup5)

Sup5.0.1



rejuvenation activities on the

maintained software.


melakukan aktivitas

peremajaan terhadap perangkat

lunak yang dipeliharanya?

Sup5.1.1

In the software maintenance

organization, rejuvenation is

performed informally, during a

specific change, without any prior

planning.

Apakah peremajaan dilakukan

secara informal, bersamaan

dengan suatu perubahan (MR

atau PR), tanpa perencanaan

sebelumnya? Apakah atas

inisiatif individu? Apakah

diakui oleh pelanggan /

pengguna?

Sup5.1.2

Retirement of a feature or

application is carried out by

leaving all software component

infrastructures in place and

preventing its execution.

Apakah dalam memensiunkan

(retirement) suatu fitur atau

aplikasi, komponen perangkat

lunak/infrastrukturnya

dibiarkan saja? Hanya

mencegah eksekusinya?

Sup5.2.1

Maintained product

redocumentation is only performed

for components subjected to a

change or correction.

Apakah redokumentasi

dilakukan? Apakah hanya

untuk komponen yang berubah

/ dikoreksi?

Sup5.2.2

Maintained product restructuring is

only performed for components

subjected to a change or

correction.

Apakah restrukturisasi produk

yang dipelihara dilakukan?

Apakah hanya untuk

komponen yang berubah /

dikoreksi?

Sup5.2.3

Maintained product reverse

engineering is only performed for

components subjected to a change,

a correction, or an operational

support request.

Apakah reverse engineering

produk yang dipelihara

dilakukan? Apakah hanya

untuk komponen yang berubah

/ dikoreksi? Apakah maintainer

mengekstrak business rules

dari perubahan-perubahan /

koreksi-koreksi, untuk

membantu pelanggan mengerti

lebih dalam tentang bagaimana

perangkat lunak berfungsi?

Sup5.2.4

Maintained product reengineering

is only performed for components

subjected to a change, a correction,

or an operational support request.

Apakah rekayasa ulang

(reengineering) produk yang

dipelihara dilakukan? Apakah

hanya untuk komponen yang

berubah / dikoreksi?



90


Nomor

Praktek

Teks Praktek


Pertanyaan

Wawancara

Sup5.2.5


develops a migration plan and

communicates it to the customers

for approval.


membuat rencana migrasi dan

menginformasikannya pada

pelanggan/pengguna untuk

mendapatkan persetujuan

mereka?


mempertimbangkan operasi

paralel? Apakah ada pelatihan

untuk pengguna dalam periode

transisi? Apakah produk lama

dan baru diarsipkan (termasuk

source code, dokumentasi,

dll.)? Apakah maintainer

melakukan revisi setelah sistem

baru online, dengan tujuan

membuat data sistem lama bisa

diakses, aman (secure), dan

terlindung dalam sistem yang

baru?

Sup5.2.6

Software tools are used to support

migration from one technological

platform to another.

Apakah dalam migrasi

platform menggunakan tool?

Apakah dapat mengotomatisasi

proses (biarpun hanya

sebagian)?

Sup5.2.7


develops a software retirement plan

and communicates it to the

customers for approval.


membuat rencana untuk

memensiunkan perangkat lunak

(software retirement plan)?

Apakah rencana tersebut

dikomunikasikan kepada

pengguna/pelanggan untuk

mendapatkan persetujuan

mereka?

Penulisan nomor praktek dalam Tabel 3.3 di atas sudah penulisan nomor praktek

dalam S3m. Dalam S3m, nomor praktek dituliskan sebagai berikut: KpaX.Y.Z.

KpaX merupakan singkatan dari KPA yang bersangkutan. Y merupakan tingkat

kematangan. Z merupakan nomor praktek dalam tingkat kematangan tersebut. Jadi

untuk contoh nomor praktek Sup5.2.7, penomoran tersebut berarti: praktek untuk



91


KPA Software Rejuvenation, Migration, and Retirement (Sup5), praktek ke-7,

untuk tingkat kematangan 2.

Dengan informasi yang diperoleh dari jawaban atas pointer pertanyaan

wawancara di atas, dapat dilakukan kajian untuk mengukur tingkat kematangan

proses pemeliharaan perangkat lunak di PT XYZ.

3.2.2 Studi Dokumen

Dokumen yang dikumpulkan akan dijadikan acuan sebagai kelengkapan evaluasi

tingkat kematangan kondisi saat ini dari proses pemeliharaan perangkat lunak di

PT XYZ. Dokumen-dokumen acuan tersebut dijadikan bukti (artifak) bahwa suatu

praktek dari model referensi sudah benar-benar dilakukan.

3.3 Objek Studi Kasus

Berikut adalah struktur organisasi PT XYZ secara keseluruhan.


92


General Meeting of Shareholders

Board of Commissioners

Audit Committee Risk Monitoring Committee

President Director

Internal Audit Legal Advisor

Corporate Risk Management

Corporate Secretary

Office of Strategy Management Marketing Support

HR & GA Director IT Director Marketing & Sales Retail Director

Marketing & Sales Corporate Director Technical Director Finance &

Accounting Director

HR Development Dept.

HR Admin Dept.

GA Dept.

Compliance Dept.

IT Dept. Marketing & Sales Retail Dept.

Marketing & Sales Corporate Dept.

UR Treaty & Admin Dept.

UR MV & HE Dept.

UR Property & Engineering Dept.

UR Marine & Misc. Oil & Gas Dept.

Claim MV & HE Dept.

Technical

Corporate Actuary Dept.

Investment Committee

Finance Dept.

Accounting Dept.

Gambar 3.2 Struktur Organisasi PT XYZ

Sumber: SK No. 029/SK/DIR/VII/2012 (PT XYZ, 2012), telah diolah kembali

PT XYZ dipimpin oleh seorang Presiden Direktur (President Director) yang

bertanggung jawab terhadap Dewan Komisioner (Board of Commissioners) yang

berfungsi sebagai wakil dari Pemegang Saham (Shareholders). Presiden Direktur

diawasi oleh Komite Audit (Audit Committee) dan Komite Pemantauan

Risiko.(Risk Monitoring Committee). Dalam melaksanakan tugasnya, Presiden

Direktur dibantu oleh Audit Internal (Internal Audit), Penasihat Hukum (Legal

Advisor), Manajemen Risiko Korporat (Corporate Risk Management), Sekretaris

Korporat (Corporate Secretary), Kantor Manajemen Strategis (Office of Strategy

Management), dan Dukungan Pemasaran (Marketing Support). Bawahan

langsung dari Presiden Direktur adalah Direktur SDM dan Urusan Umum (HR &


93


GA Director), Direktur TI (IT Director), Direktur Pemasaran dan Penjualan Ritel

(Marketing & Sales Retail Director), Direktur Pemasaran dan Penjualan Korporat

(Marketing & Sales Corporate Director), Direktur Teknis (Technical Director),

dan Direktur Akunting dan Keuangan (Finance & Accounting Director).

3.3.1 Struktur Organisasi Departemen TI

IT Director

IT Department Head

Application Development Section Head IT Support Section Head Report Development

Section HeadBusiness Analyst Section

Head

IT Software Developer

System Analyst

Hardware & Infrastructure

Help Desk Hardware

Help Desk Application

Report Development

Database Administrator

Business Analyst

Gambar 3.3 Struktur Organisasi Departemen TI

Sumber: SK No. 029/SK/DIR/VII/2012 (PT XYZ, 2012), telah diolah kembali

Departemen TI terdiri atas 1 Direktur, 1 Kepala Departemen, dan 4 Seksi, yaitu:

Application Development, IT Support, Report Development, dan Business Analyst.

Masing-masing Seksi memiliki 1 Kepala Seksi yang membawahi beberapa orang

personil dalam beberapa uraian tugas (job description).

3.3.2 Fungsi Departemen Teknologi Informasi

Fungsi Departemen TI di PT XYZ tercermin di uraian tugas Kepala Departemen

TI. Fungsi utama dari uraian tugas ini adalah untuk merencanakan strategi

pengembangan, pengendalian pengembangan, dan operasional dari SI/TI untuk

menunjang tujuan bisnis perusahaan. Dalam melaksanakan tugasnya, Departemen

TI bertanggung jawab kepada Direktur TI melalui Kepala Departemen TI. Berikut

dijelaskan fungsi dari masing-masing Seksi dalam Departemen TI.


94


3.3.2.1 Seksi Application Development

Seksi ini berfungsi untuk merencanakan, mengoordinir, memantau, dan

melaksanakan proyek-proyek pengembangan aplikasi SI perusahaan. Ada 2 uraian

tugas dalam Seksi ini, yaitu:

1. IT Software Developer

Uraian tugas ini memiliki fungsi utama membuat program dan melakukan

pemeliharaan modul SI/TI perusahaan. Tanggung jawab uraian tugas ini

adalah:

a. Terlaksananya pembuatan dan deploy modul SI/TI perusahaan.

b. Terselenggaranya kegiatan dukungan sistem (system support) atas

operasional SI/TI perusahaan.

Tugas-tugas pokok uraian tugas ini adalah:

a. Melaksanakan pemrograman atas user requirement dan system

requirement specification.

b. Melaksanakan kegiatan deploy modul SI/TI perusahaan.

c. Melakukan pemantauan terhadap kinerja aplikasi dan memelihara

aplikasi.

d. Menyiapkan aplikasi untuk keperluan pelatihan pengguna.

e. Memperbaiki galat aplikasi.

2. System Analyst

Uraian tugas ini memiliki fungsi utama melakukan identifikasi dan

merancang system requirement specification. Tanggung jawab uraian tugas

ini adalah:

a. Tersedianya rancangan system requirement specification.

b. Terlaksananya tata dokumen system requirement specification.



95


a. Mengumpulkan data dan menganalisa rancangan modul aplikasi yang

akan dikembangkan maupun SI/TI perusahaan secara keseluruhan.

b. Membuat system requirement specification.

c. Melakukan ulasan dan membuat rekomendasi perbaikan atas system

requirement specification yang berjalan.

d. Melakukan pengujian terhadap modul SI/TI yang di- deploy.

3.3.2.2 Seksi IT Support

Seksi ini berfungsi untuk merencanakan, mengoordinir, dan melaksanakan

pemantauan terhadap penggunaan perangkat keras, jaringan, dan dukungan

terhadap pengguna (user support) dari SI/TI perusahaan. Ada 3 uraian tugas

dalam Seksi ini, yaitu:

1. Hardware & Infrastructure

Uraian tugas ini memiliki fungsi utama memantau penggunaan dan

pemeliharaan perangkat keras dan jaringan SI/TI perusahaan. Tanggung

jawab uraian tugas ini adalah:

a. Terpantaunya penggunaan dan pemeliharaan perangkat keras.

b. Terpantaunya operasi jaringan SI/TI perusahaan.

c. Terlaksana dan terpantaunya kegiatan persiapan perangkat SI/TI

perusahaan.


a. Melakukan inventarisasi masa dan kapasitas pakai perangkat keras.

b. Membuat laporan dan rekomendasi penggantian atau perbaikan

perangkat keras.

c. Melakukan atau mengoordinasi perbaikan atas kerusakan perangkat

keras.

d. Memeriksa spesifikasi perangkat keras yang telah dibeli perusahaan.

e. Memantau kinerja jaringan.

f. Melakukan koordinasi dengan penyedia jaringan untuk perbaikan

jaringan.


96


g. Melaksanakan dan memantau instalasi perangkat lunak di komputer

pengguna, seperti: sistem operasi, aplikasi, antivirus, dan sebagainya.

h. Melaksanakan dan memantau instalasi perangkat lunak di komputer

server, seperti: sistem operasi, email server, file server, proxy server,

DNS server, dan antivirus server.

i. Melaksanakan dan memantau pemasangan perangkat komputer dan

kelengkapannya di Head Office (Kantor Pusat), Regional Office

(Kantor Regional), dan Sales Office (Kantor Penjualan).

j. Memantau pemasangan dan pengujian jaringan serta membuat

laporannya.

2. Help Desk Hardware

Uraian tugas ini memiliki fungsi utama memelihara perangkat keras

meliputi server, jaringan, antarmuka ke internet, proses backup dan recovery

SI/TI. Tanggung jawab uraian tugas ini adalah:

a. Terpeliharanya perangkat keras.

b. Terpantaunya operasi jaringan SI/TI perusahaan.

c. Terlaksana dan terpantaunya kegiatan persiapan perangkat SI/TI

perusahaan.


a. Melakukan perbaikan atas kerusakan perangkat keras.

b. Mengganti perangkat keras yang sudah ketinggalan teknologi.

c. Analisis masalah pada server dan jaringan untuk memperbaikinya.

d. Memilih jaringan alternatif untuk meminimalkan risiko gangguan

perangkat keras.

e. Melaksanakan pengaturan akses pengguna ke LAN (Local Area

Network) dan WAN (Wide Area Network).

f. Memantau pelaksanaan persiapan dan pengujian jaringan serta

membuat laporannya.


97


g. Melaksanakan dan memantau instalasi perangkat lunak di komputer

server, seperti: sistem operasi, email server, file server, proxy server,

DNS server, dan antivirus server.

h. Melakukan pemasangan antarmuka ke internet.

3. Help Desk Application

Uraian tugas ini memiliki fungsi utama memberikan informasi dan solusi

kepada pengguna dalam implementasi SI/TI dan SOP. Tanggung jawab

uraian tugas ini adalah:

a. Tersedianya solusi/informasi atas pertanyaan pengguna tentang SI/TI

dan SOP.

b. Terlaksananya administrasi permasalahan pengguna dan

penyelesaiannya.


a. Menerima dan menanggapi pertanyaan sehari-hari pengguna tentang

permasalahan implementasi SI/TI dan SOP.

b. Melakukan konsultasi ke atasan untuk penyelesaian atas pertanyaan

sehari-hari pengguna tentang permasalahan implementasi SI/TI dan

SOP.

c. Melakukan korespondensi dengan Seksi terkait di Departemen TI

untuk penyelesaian permasalahan pengguna.

d. Mencatat setiap pertanyaan sehari-hari pengguna tentang

permasalahan implementasi SI/TI dan SOP.

e. Mengarsipkan dokumen yang berkaitan dengan pertanyaan sehari-hari

pengguna tentang permasalahan implementasi SI/TI dan SOP dan

solusinya.

3.3.2.3 Seksi Report Development

Seksi ini berfungsi untuk merencanakan, mengoordinir, memantau, dan

melaksanakan proyek-proyek pengembangan aplikasi pelaporan dan pengelolaan


98


basis data yang digunakan dalam SI/TI perusahaan. Ada 2 uraian tugas dalam

Seksi ini, yaitu:

1. Report Development

Uraian tugas ini memiliki fungsi utama melaksanakan proyek

pengembangan aplikasi pelaporan, pemeliharaan basis data, dan kegiatan

pemrosesan data. Tanggung jawab uraian tugas ini adalah:

a. Terlaksananya proyek pengembangan aplikasi pelaporan.

b. Terlaksananya pemrosesan data untuk pembuatan laporan ad hoc.

c. Terlaksananya administrasi program pembuatan laporan ad hoc.


a. Membuat rancangan data laporan SI/TI perusahaan.

b. Membuat aplikasi pelaporan dan laporan ad hoc.

c. Melaksanakan proses pembuatan/pemrosesan data laporan ad hoc.

d. Menyiapkan fasilitas dan sistem penyimpanan laporan.

e. Melakukan penyimpanan berkas program pembuatan laporan.

2. Database Administrator

Uraian tugas ini memiliki fungsi utama mengelola dan memelihara basis

data SI/TI perusahaan. Tanggung jawab uraian tugas ini adalah:

a. Terlaksananya program kegiatan pemeliharaan basis data, server basis

data, dan report server secara berkala.

b. Termonitornya ketersediaan kapasitas penyimpanan data untuk

operasional SI/TI.


a. Menyelesaikan permasalahan dan hambatan operasional basis data,

server basis data, dan report server.

b. Melaksanakan kegiatan backup basis data.


99


c. Memantau kondisi basis data, server basis data, dan report server.

d. Melaksanakan migrasi data sesuai keperluan.

e. Melaksanakan kegiatan pembersihan data.

f. Membuat laporan periodik pemakaian dan ketersediaan kapasitas

basis data dan report server.

g. Membuat rekomendasi penyesuaian kapasitas basis data dan report

server.

3.3.2.4 Seksi Business Analyst

Hanya ada 1 uraian tugas dalam Seksi ini, yaitu: Business Analyst. Uraian tugas

ini memiliki fungsi utama mengumpulkan data pendukung untuk pengembangan

model bisnis (business model) dan proses bisnis (business process) perusahaan,

serta tata administrasi yang berurusan dengan hal ini. Tanggung jawab uraian

tugas ini adalah:

a. Tersedianya data pendukung untuk pengembangan model bisnis dan proses

bisnis perusahaan.

b. Tersedianya tata administrasi yang berhubungan dengan model bisnis dan

proses bisnis perusahaan.


a. Mengumpulkan data dan membuat laporan rangkumannya tentang

perkembangan cara transaksi atau cara operasional berbagai Departemen di

Head Office, Regional Office, maupun di Sales Office.

b. Mengumpulkan data dan membuat laporan rangkumannya tentang

perkembangan alur kerja operasional di Head Office, Regional Office,

maupun di Sales Office.

c. Melakukan ulasan dan membuat konsep model bisnis.

d. Melakukan ulasan dan identifikasi kebutuhan perubahan proses bisnis atas

dasar ulasan model bisnis saat ini.

e. Membuat konsep rancangan proses bisnis baru, ataupun memperbaharui

rancangan yang sudah ada.

f. Menyiapkan tools untuk pengumpulan data.


100


g. Menyusun jadwal dan menyelenggarakan rapat yang berhubungan dengan

pengumpulan data untuk penyusunan model bisnis dan proses bisnis.

h. Membuat jadwal dan menyiapkan kebutuhan sosialisasi proses bisnis ke

pihak terkait.

i. Melakukan pengarsipan seluruh dokumen kerja.

3.4 Studi Kasus: Proses Pemeliharaan Perangkat Lunak

Salah satu SI yang dimiliki PT XYZ adalah Sistem Informasi Asuransi Umum.

Sistem Informasi Asuransi Umum adalah SI core insurance, yaitu SI yang mampu

menangani seluruh proses bisnis perasuransian, antara lain: marketing,

underwriting, claim, finance, dan accounting. Sistem Informasi Asuransi Umum

bersifat key operational, yang berarti keberlangsungan bisnis PT XYZ bergantung

pada berjalannya Sistem Informasi Asuransi Umum.

Sistem Informasi Asuransi Umum dibangun oleh pihak ke-3, dan semenjak

operasionalnya Sistem Informasi Asuransi Umum di tahun 2006, semua kegiatan

pengembangan (development) perangkat lunak dan pemeliharaan (maintenance)

yang berkaitan dengan Sistem Informasi Asuransi Umum telah diserahkan

sepenuhnya kepada PT XYZ. Yang dimaksud dengan kegiatan pengembangan

perangkat lunak dan pemeliharaan di sini termasuk penambahan fitur

(pemeliharaan adaptif) dan perbaikan defect (pemeliharaan korektif). Penambahan

fitur dilakukan karena berubahnya proses bisnis PT XYZ sebagai penyesuaian

terhadap perubahan kondisi internal maupun eksternal perusahaan. Yang

dimaksud dengan perubahan kondisi internal adalah perubahan proses bisnis

karena alasan penyederhanaan proses bisnis organisasi. Yang dimaksud dengan

perubahan kondisi eksternal misalnya perubahan yang disebabkan bertambahnya

mitra bisnis yang perlu diintegrasikan proses bisnisnya ke dalam Sistem Informasi

Asuransi Umum.

Saat ini penanganan permintaan modifikasi (modification request, disingkat MR)

atau yang secara lokal disebut change request (CR), laporan permasalahan

(problem report, disingkat PR), dan permintaan dukungan (support request,

disingkat SR) yang berkaitan dengan Sistem Informasi Asuransi Umum,


101


semuanya ditangani oleh Departemen TI. Semua seksi dari Departemen TI terlihat

dalam penanganan ini.

Untuk MR, alurnya dimulai dari seksi Business Analyst yang mendapatkan

requirement dari pengguna dan untuk validasi. Seksi Application Development

dan Report Development yang implementasi dan verifikasi requirement tersebut.

Seksi IT Support bertugas untuk melakukan pengadaan dan pemeliharaan

perangkat keras dan infrastruktur, dan sebagai pintu masuk permintaan dari

pengguna. Seksi Business Analyst akan meminta masukan dari Application

Development dan Report Development untuk membuat perkiraan ukuran dan

waktu. Dalam prakteknya, MR dibagi menjadi dua jenis berdasarkan perkiraan

ukuran dan waktunya, yaitu MR besar dan MR kecil. MR besar akan masuk ke

dalam antrean proyek, sedangkan MR kecil akan langsung dieksekusi.

Untuk PR, alurnya dimulai dari seksi IT Support yang mendapatkan laporan

kegagalan (failure) dari pengguna. IT Support akan memastikan bahwa

permasalahan benar-benar terjadi, dan meneruskannya ke seksi Application

Development atau Report Development. Perbaikan dilakukan, dilakukan pengujian

bahwa masalah sudah selesai.

Untuk SR, alurnya dimulai dari seksi IT Support yang mendapatkan laporan

kegagalan (failure) dari pengguna. IT Support akan meneruskannya ke seksi

Report Development atau Application Development. Kegiatan dukungan

dilakukan (biasanya berupa ekstrak data dalam bentuk laporan), laporan atau data

disampaikan ke pengguna, dan SR dianggap selesai.

3.5 Jadwal Penelitian

Berikut jadwal pelaksanaan penelitian yang akan dilakukan dalam karya akhir ini.

Penelitian dilakukan mulai dari tahapan pengumpulan data awal, identifikasi

masalah, peninjauan pustaka, perancangan penelitian, dilanjutkan dengan

pengumpulan data kondisi pemeliharaan perangkat lunak saat ini (evaluasi tingkat

kematangan), analisis data, penyusunan strategi SPI, dan penulisan laporan

penelitian. Jadwal penelitian ini sudah mempertimbangkan batas waktu


102


pengumpulan laporan karya akhir siap sidang yang ditentukan oleh sekretariat

MTI UI, yaitu 5 Juni 2017.

Tabel 3.4 Jadwal Kegiatan Penelitian

No. Kegiatan Februari Maret April Mei Juni

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 5

1. Pengumpulan

data awal

2. Identifikasi masalah

3. Peninjauan

pustaka

4. Perencanaan penelitian

5. Evaluasi

tingkat kematangan

6. Analisis data

7. Penyusunan

strategi SPI

8. Penulisan laporan



BAB 4

RANCANGAN DAN HASIL KAJIAN KPA S3M

Bab ini menjelaskan rancangan kajian (assessment) yang dilakukan di objek studi

kasus, dan hasil kajian semua KPA dari S3m yang telah dipilih sesuai rancangan.

4.1 Rancangan Kajian

Sebelum melakukan kajian berdasarkan S3m menggunakan S3mAssess, penulis

merasa perlu untuk melakukan pemetaan dari S3m ke CMMI-DEV V1.3 karena

sedikitnya studi kasus yang dipublikasikan yang menggunakan S3m. Penulis hanya

berhasil menemukan satu karya ilmiah yang menggunakan S3m untuk studi kasus,

yaitu karya ilmiah oleh Paquette, April, & Abran (2006). Dengan demikian demi

memastikan kelayakan penggunaan S3m dalam karya akhir ini, perlu dipastikan

bahwa KPA dalam S3m dapat dipetakan ke PA dalam CMMI-DEV V1.3 yang

relevan untuk pemeliharaan perangkat lunak.

Para pembuat kerangka kerja S3m merancang domain-domain proses dan KPA-

nya agar selaras dengan proses-proses domain dan PA dalam CMMI (April &

Abran, 2008, hal. 70), yaitu CMMI-SE/SW/IPPD/SS V1.1 (CMMI for Systems

Engineering, Software Engineering, Integrated Product and Process Development,

and Supplier Sourcing, Version 1.1). Keselarasan ini dirancang dengan tujuan

agar para manajer yang melaksanakan SPI dalam bidang pengembangan tidak

mendapatkan banyak perbedaan terminologi saat melakukan kegiatan yang serupa

untuk pemeliharaan. Saat S3m dibuat, CMMI-DEV V1.3 belum diterbitkan,

sehingga agar pemetaan antara PA dalam CMMI-DEV V1.3 ke KPA dalam S3m

dapat diperoleh, perlu dilakukan terlebih dahulu pemetaan dari CMMI-

SE/SW/IPPD/SS V1.1 ke S3m, lalu dari CMMI-DEV V1.2 ke S3m, dan yang

terakhir CMMI-DEV V1.3 ke S3m. Tujuan melakukan pemetaan ini adalah untuk

memastikan bahwa semua PA di CMMI-DEV V1.3 sudah benar-benar

dipertimbangkan di dalam S3m.

Setelah pemetaan dari KPA di S3m ke PA dalam CMMI-DEV V1.3 diperoleh,

akan dilakukan kajian terhadap tiap-tiap KPA dalam S3m untuk mendapatkan


104


tingkat kematangan proses pemeliharaan perangkat lunak di Departemen TI PT

XYZ. Kajian ini mempertimbangkan bukti lisan (afirmasi) atau bukti tulisan (jika

wawancara via email), dan bukti artifak. Metode kajian yang digunakan adalah

S3mAssess. Dalam S3mAssess, pencapaian tingkat kematangan dibagi sebagai berikut

(Zarour, Alarifi, Abran, & Desharnais, 2012; Paquette, April, & Abran, 2006):

N : Not Achieved (tidak tercapai), rating tingkat kematangan 0%-15%, berarti

tidak terbukti bahwa tujuan proses terpenuhi.

P : Partially Achieved (tercapai sebagian), rating tingkat kematangan 16%-

50%, berarti beberapa tujuan proses terpenuhi.

L : Largely Achieved (tercapai sebagian besar), rating tingkat kematangan 51%-

85%, berarti sebagian besar tujuan proses terpenuhi.

F : Fully Achieved (tercapai sepenuhnya), rating tingkat kematangan 86%-

100%, tujuan proses terpenuhi seluruhnya.

Jadi dapat disimpulkan bahwa jika rating tingkat kematangan mencapai 86%,

maka tingkat kematangan tersebut tercapai.

Untuk pencapaian praktek, untuk mengurangi kemungkinan subjektivitas karena

kurangnya pengalaman si penilai, pemenuhan praktek tingkat 1 dan 2 diberi nilai

sebagai berikut (Zarour, Alarifi, Abran, & Desharnais, 2012; Paquette, April, &

Abran, 2006):

N : Not Achieved, rating 0%.

P : Partially Achieved, rating 33%.

L : Largely Achieved, rating 68%.

F : Fully Achieved, rating 93%.

Untuk praktek tingkat 0, jika jawaban pertanyaan adalah “Ya” maka diberi rating

0%, sedangkan jika dijawab “Tidak” maka diberi rating 100% (Zarour, Alarifi,

Abran, & Desharnais, 2012; Paquette, April, & Abran, 2006).

Karena S3mAssess tidak memberikan kriteria untuk membedakan praktek N, P, L,

dan F, maka penulis menyusun kriteria penilaian sebagai berikut:

N : Praktek sama sekali tidak dilakukan atau tujuannya tidak tercapai.


105


P : Praktek dilakukan tapi memiliki kelemahan (termasuk tidak didukung

artifak) yang menyebabkan tujuannya tidak tercapai.

L : Praktek dilakukan dan memiliki kelemahan (termasuk tidak didukung

artifak), tapi tujuannya tercapai.

F : Praktek dilakukan dan tidak ada kelemahan yang teridentifikasi.

4.1.1 Pemetaan PA CMMI-SE/SW/IPPD/SS V1.1 ke KPA S3m

Berikut ilustrasi pemetaan dari PA di CMMI-SE/SW/IPPD/SS V1.1 ke KPA di

S3m:


106


Gambar 4.1 Pemetaan PA dalam CMMI-SE/SW/IPPD/SS V1.1 ke KPA

dalam S3m Berdasarkan Deskripsi April & Abran (2008)

Dari Gambar 4.1 dapat dilihat bahwa semua PA dalam domain proses Process

Management dari CMMI dipetakan ke KPA dalam domain proses Process

Management di S3m. Menurut April & Abran (2008, hal. 78), PA dalam Process


107


Management di CMMI relevan untuk pemeliharaan perangkat lunak, jadi

penamaannya hanya diubah sedikit.

Perbedaan paling besar terlihat pada domain proses Project Management dari

CMMI dibandingkan dengan Event/Request Management di S3m. PA Project

Planning menjadi KPA Maintenance Planning, PA Project Monitoring and

Control menjadi KPA Request/Software Monitoring and Control, dan PA yang

berhubungan dengan pemasok dikelompokkan menjadi KPA SLA and Supplier

Agreements Management (April & Abran, 2008, hal. 79). April & Abran tidak

menyebutkan secara eksplisit PA Integrated Project Management, Risk

Management, Quantitative Project Management, dan Integrated Teaming

dipetakan ke mana.

Dalam domain proses Engineering dari CMMI ke Evolution Engineering di S3m,

hanya PA Verification dan Validation yang secara eksplisit dipetakan, yaitu ke

KPA Verification and Validation (April & Abran, 2008, hal. 80). PA Product

Integration, Requirements Management, Requirements Development, dan

Technical Solution tidak secara eksplisit dipetakan.

Dalam domain proses Support dari CMMI ke Support to Evolution Engineering di

S3m, PA Configuration Management dipetakan ke KPA Configuration and

Versioning Management, PA Process and Product Quality Assurance dipetakan

ke KPA Process, Service and Software Quality Assurance, PA Measurement and

Analysis dipetakan ke KPA Maintenance Measurement and Analysis, dan PA

Causal Analysis and Resolution dipetakan ke KPA Causal Analysis and Problem

Resolution (April & Abran, 2008, hal. 80). April & Abran tidak membahas

pemetaan PA Decision Analysis and Resolution dan Organizational Environment

for Integration.

4.1.2 Pemetaan PA CMMI-DEV V1.2 ke KPA S3m

Pemetaan dari CMMI-DEV V1.2 ke S3m perlu dilakukan agar pemetaan CMMI-

DEV V1.3 ke S3m dapat dilakukan. Sebelum PA dari CMMI-DEV V1.2 dipetakan

ke S3m, terlebih dahulu didaftarkan perubahan PA dari CMMI-SE/SW/IPPD/SS

V1.1 ke CMMI-DEV V1.2, yaitu:


108


1. Integrated Supplier Management digabung ke dalam Supplier Agreement

Management (CMMI Product Team, 2006, hal. vi; Kneuper, 2009, hal.

102).

2. Integrated Teaming digabung ke dalam Integrated Project Management

(Phillips, 2007, hal. 5; Kneuper, 2009, hal. 102).

3. Organizational Environment for Integration digabung ke dalam

Organizational Process Definition (Phillips, 2007, hal. 5; Kneuper, 2009,

hal. 102).

Ini berarti CMMI-DEV 1.2 memiliki 22 PA dibandingkan dengan 25 PA pada

CMMI-SE/SW/IPPD/SS V1.1. Pemetaan dari CMMI-DEV V1.2 ke S3m menjadi

sebagai berikut:


109



Berdasarkan Pemetaan dari CMMI-SE/SW/IPPD/SS V1.1 ke S3m

Dapat dilihat di Gambar 4.2 bahwa untuk domain proses Process Management

tidak ada perubahan pemetaan. Untuk domain proses Project Management, karena

dari sisi CMMI-DEV V1.2 Integrated Supplier Management digabung ke

Supplier Agreement Management, maka pemetaan berubah menjadi dari Supplier

Agreement Management ke SLA and Supplier Agreements Management di domain

proses Event/Request Management pada S3m. Dari domain proses Engineering di


110


CMMI-DEV V1.2 ke domain proses Evolution Engineering di S3m tidak ada

perubahan pemetaan. Dari domain proses Support di CMMI-DEV V1.2 ke

domain proses Support to Evolution Engineering di S3m juga tidak ada perubahan.

4.1.3 Pemetaan PA CMMI-DEV V1.3 ke KPA S3m

Dengan mempertimbangkan pemetaan dari CMMI-DEV V1.2 ke S3m, maka akan

dilakukan pemetaan dari CMMI-DEV V1.3 ke S3m. Sebelum PA di CMMI-DEV

V1.3 dipetakan ke S3m, terlebih dahulu didaftarkan perubahan PA dari CMMI-

DEV V1.2 ke CMMI-DEV V1.3, yaitu:

1. Organizational Innovation and Deployment diganti namanya menjadi

Organizational Performance Management (CMMI Product Team, 2010,

hal. iv).

2. Requirements Management dipindahkan dari domain proses Engineering ke

Project Management (CMMI Product Team, 2010, hal. 43).

Ini berarti CMMI-DEV V1.3 memiliki jumlah PA yang sama dengan CMMI-

DEV V1.2, yaitu 22 PA. Pemetaan dari CMMI-DEV V1.3 ke S3m, menjadi

sebagai berikut:


111



Berdasarkan Pemetaan dari CMMI-DEV V1.2 ke S3m

Dapat dilihat di Gambar 4.3, dalam proses domain Process Management di

CMMI-DEV V1.3, pemetaan diubah menjadi dari Organizational Performance

Management ke Maintenance Innovation and Deployment di S3m. Untuk domain-

domain proses Project Management dan Engineering di CMMI-DEV V1.3,

perubahannya adalah Requirements Management dipindah dari Engineering ke


112


Project Management. Untuk pemetaan dari domain proses Support ke Support to

Evolution Engineering tidak ada perubahan.

Karena pemetaan yang tidak eksplisit oleh April & Abran (2008), pemetaan-

pemetaan berikut perlu dilakukan, yaitu dari PA: (i) dari PA Integrated Project

Management, (ii) Quantitative Project Management, (iii) Risk Management, (iv)

Requirements Management, (v) Product Integration, (vi) Requirements

Development, (vii) Technical Solution, dan (viii) Decision Analysis and

Resolution. Untuk mendapatkan pemetaan dari semua PA tersebut, dilakukan

perbandingan praktek-prakteknya (SP) dengan praktek-praktek (exemplary

practices) di S3m.

4.1.3.1 Integrated Project Management (IPM)

Untuk memetakan PA IPM dari CMMI ke KPA di S3m, pertama-tama SG dan SP

dari PA IPM didaftarkan dulu, lalu di S3m dicari praktek yang mencakup hal yang

serupa. Berikut SG dan SP dari IPM:

SG 1: Use the Project’s Defined Process

SP 1.1: Establish the Project’s Defined Process

SP 1.2: Use Organizational Process Assets for Planning Project Activities

SP 1.3: Establish the Project’s Work Environment

SP 1.4: Integrate Teams

SP 1.5: Manage the Project Using Integrated Plans

SP 1.6: Establish Teams

SP 1.7: Contribute to Organizational Process Assets

SG 2: Coordinate and Collaborate with Relevant Stakeholders

SP 2.1: Manage Stakeholders Involvement

SP 2.2: Manage Dependencies

SP 2.3: Resolve Coordination Issues

Dalam S3m, April & Abran tidak memetakan secara eksplisit PA IPM dari CMMI.

Untuk mencari pemetaannya ke KPA di S3m, dilakukan pencarian ke praktek

terhadap kata-kata kunci yang diturunkan dari SP, sebagai berikut: defined

process, process asset, work environment, integrate team, integrated plan,


113


establish team, manage stakeholder, stakeholder involvement, manage

dependencies, coordination.

Hanya kata kunci work environment yang ditemukan, dalam penjelasan KPA

Maintenance Process/Service Definition (Pro2), praktek Pro2.0.1:

“The software maintenance organization does not carry out process/services

definition activities. It does not provide a list or directory of services to its

customers.” (April & Abran, 2008, hal. 135)

Berikut adalah penjelasan yang menggunakan kata kunci work environment (cetak

tebal tambahan penulis):

“The only available documentation, and related maintenance work environment,

has been provided to developers, suppliers, and subcontractors.” (April & Abran,

2008, hal. 136)

Penjelasan di atas membahas bahwa lingkungan kerja disediakan kepada

pengembang, pemasok, dan subkontraktor, tapi tidak menyebutkan maintainer

secara eksplisit, dan dalam konteks penjelasan praktek yang tidak dilakukan

(Tidak 0). Hal ini sesuai dengan pernyataan-pernyataan dalam S3m bahwa:

a. Manajemen proyek hanya diperlukan untuk proyek-proyek pemeliharaan

besar, dan bukan untuk permintaan-permintaan pemeliharaan. Untuk kasus-

kasus spesifik dari proyek-proyek pemeliharaan besar, sebaiknya

menggunakan model CMMI. (April & Abran, 2008, hal. 193, 197)

b. Beban kerja pemeliharaan tidak diatur menggunakan teknik-teknik

manajemen proyek, melainkan menggunakan teknik-teknik manajemen

antrean. (April & Abran, 2008, hal. 12, 72)

c. Perubahan ini diperkenalkan untuk mencerminkan manajemen

kejadian/permintaan pemeliharaan perangkat lunak yang berbeda dengan

manajemen proyek yang digunakan dalam pengembangan perangkat lunak.

Model kematangan yang diajukan berfokus pada aktivitas-aktivitas

pemeliharaan yang berdasarkan pada permintaan-permintaan pemeliharaan

kecil, bukan proyek-proyek besar. (April & Abran, 2008, hal. 76)


114


Berarti dapat disimpulkan bahwa PA IPM tidak dapat dipetakan ke KPA dalam

S3m.

4.1.3.2 Quantitative Project Management (QPM)

Untuk memetakan PA QPM dari CMMI ke KPA di S3m, pertama-tama SG dan SP

dari PA QPM didaftarkan dulu, lalu di S3m dicari praktek yang mencakup hal

yang serupa. Berikut SG dan SP dari QPM:

SG 1: Prepare for Quantitative Management

SP 1.1: Establish the Project’s Objectives

SP 1.2: Compose the Defined Process

SP 1.3: Select Subprocesses and Attributes

SP 1.4: Select Measures and Analytic Techniques

SG 2: Quantitatively Manage the Project

SP 2.1: Monitor the Performance of Selected Subprocesses

SP 2.2: Manage Project Performance

SP 2.3: Perform Root Cause Analysis

Dalam S3m, April & Abran tidak memetakan secara eksplisit PA QPM dari

CMMI. Untuk mencari pemetaannya ke KPA di S3m, dilakukan pencarian ke

praktek terhadap kata-kata kunci yang diturunkan dari SP, sebagai berikut:

quantitative management, project objective, defined process, subprocess,

attribute, measure, analytic technique, monitor performance, manage

performance, root cause analysis.

Kata kunci quantitative management ditemukan dalam road map yang berjudul

Quantitative Management Road Map (cetak tebal tambahan penulis) dalam KPA

Maintenance Process Performance (Pro4), praktek Pro4.2.3:

“The maintenance organization has set some performance and quality

objectives.” (April & Abran, 2008, hal. 146)

Berikut teks penjelasannya (garis bawah tambahan penulis):


115


“By setting up objectives for the quality and performance of processes, services,

and products of the maintenance portfolio SP1.1 under their control, middle

managers can forecast expected levels of services and analyze historical data to

help set up mode realistic objectives. With historical data available, initial

objectives can be revised SP2.2. At this maturity level, the maintenance

organization has identified basic objectives for management purposes SP1.1.

Maintenance middle managers collect and present performance information at

weekly management meetings SP1.3, SP1.4, SP2.1 and meetings with customers (for

example, the availability percentage of the software, say, 96%; the percentage of

customer satisfaction; or the number of overtime hours SP1.3.” (April & Abran,

2008, hal. 146)

Jadi dapat disimpulkan bahwa SP 1.1, SP 1.3, SP 1.4, SP 2.1, dan SP 2.2 dari

QPM sudah dicakup dalam praktek ini.

Untuk kata kunci measure, ditemukan dalam Definition of Maintenance Measures

Road Map, praktek Pro4.2.1:

“Some key maintenance processes, services, and products have measures. They

are defined and used locally.” (April & Abran, 2008, hal. 144)

Teks penjelasannya adalah sebagai berikut:

“At this maturity level, the maintenance organization has identified the basic

measures that are to be used by its management and customers SP1.4. Maintenance

managers use the information at (a) weekly management meetings and (b) at

customer meetings.” (April & Abran, 2008, hal. 145)

Berikut hasil pemetaan SP di QPM ke praktek di S3m:


116


Gambar 4.4 Pemetaan SP dari QPM di CMMI-DEV V1.3 ke S3m

Dapat dilihat bahwa SP 1.2 dan SP 2.3 tidak dapat dipetakan ke praktek di S3m.

Pernyataan-pernyataan di S3m yang telah ditulis di pembahasan mengenai IPM

sebelumnya juga berlaku untuk QPM, bahwa S3m lebih cocok untuk permintaan-

permintaan pemeliharaan yang tidak membutuhkan teknik manajemen proyek.

4.1.3.3 Risk Management (RSKM)

Untuk memetakan PA RSKM dari CMMI ke KPA di S3m, pertama-tama SG dan

SP dari PA RSKM didaftarkan, lalu di S3m dicari praktek yang mencakup hal

yang serupa. Berikut SG dan SP dari RSKM:

SG 1: Prepare for Risk Management

SP 1.1: Determine Risk Sources and Categories

SP 1.2: Determine Risk Parameters

SP 1.3: Establish a Risk Management Strategy

SG 2: Identify and Analyze Risks

SP 2.1: Identify Risks

SP 2.2: Evaluate, Categorize, and Prioritize Risks

SG 3: Mitigate Risks

SP 3.1: Develop Risk Mitigation Plans

SP 3.2: Implement Risk Mitigation Plans

Dalam S3m, April & Abran (2008) tidak memetakan secara eksplisit PA RSKM

dari CMMI. Penanganan risiko ada disebutkan secara eksplisit dalam KPA

Maintenance Planning (Req2), praktek Req2.2.11 (cetak tebal tambahan penulis):


117


“The predelivery and transition plan assesses, documents, and approves the risks

linked to technical aspects, the costs (hardware, software, and licenses), human

resources requirements, and final transition schedule.” (April & Abran, 2008, hal.

155).

Selain itu, dalam praktek Req2.2.11 juga ada menyatakan perlunya

menggarisbawahi risiko-risiko yang berdampak langsung pada pelanggan,

perlunya mendapatkan pendapat pengembang dalam penilaian risiko, perlunya

mendapatkan konsensus pada persepsi terhadap risiko-risiko (kualitatif dan

kuantitatif), dan perlunya memasukkan hasil penilaian risiko ke dalam rencana

transisi (transition plan) (April & Abran, 2008, hal. 155-156). Berarti dapat

disimpulkan bahwa manajemen risiko yang berkaitan dengan proses pemeliharaan

sebelum delivery (predelivery) dan transisi ditangani dalam KPA Req2.

Penanganan risiko juga ada dalam pembahasan terhadap KPA Requests/Software

Monitoring and Control (Req3), praktek Req3.2.2:

“The commitments of various stakeholders, as agreed upon in the maintenance

plans, are tracked on periodic basis.” (April & Abran, 2008, hal. 160)

Dalam pembahasannya, untuk memastikan bahwa komitmen terpenuhi maka

tindakan yang perlu dilakukan antara lain: mengulas komitmen permintaan yang

paling penting atau paling berisiko dengan manajer pemeliharaan, dan

mengidentifikasi dan mendokumentasikan perbedaan, masalah, dan pertanyaan

atau dampak yang signifikan tentang komitmen yang tidak bisa dipenuhi (April &

Abran, 2008, hal. 160). Berarti dapat disimpulkan bahwa manajemen risiko yang

berkaitan dengan permintaan-permintaan pemeliharaan ditangani pada KPA Req3.

Penanganan risiko juga ada dalam pembahasan praktek Req3.2.3:

“A review of each production software service level, monitored by maintenance

engineers, is presented at the weekly maintenance management meeting.” (April

& Abran, 2008, hal. 160)


118


Dalam pembahasannya, ada disebutkan bahwa: kasus-kasus yang tidak memenuhi

SLA dan yang berisiko tidak memenuhi komitmen diidentifikasi (April & Abran,

2008, hal. 160). Berarti dapat disimpulkan bahwa manajemen risiko yang

berkaitan dengan SLA ditangani dalam KPA Req3.

Berikut hasil pemetaan antara praktek-praktek dari RSKM di CMMI-DEV V1.3

ke S3m:

Gambar 4.5 Pemetaan SP dari RSKM di CMMI-DEV V1.3 ke S3m

Dapat dilihat bahwa SP 3.2 tidak dapat dipetakan ke S3m. S3m tidak membahas

secara eksplisit tentang implementasi dari rencana mitigasi risiko. Selain itu,

manajemen risiko dalam praktek Req2.2.11, Req3.2.2, dan Req3.2.3 sudah

dibatasi untuk: kegiatan sebelum delivery dan transisi, komitmen pemangku

kepentingan tentang permintaan-permintaan pemeliharaan, dan dalam hal

pemenuhan SLA.

Justifikasi April & Abran tidak memetakan RSKM secara eksplisit adalah bahwa

tidak ada yang khusus dalam proses analisis risiko untuk pemeliharaan perangkat

lunak, sehingga dapat disesuaikan (tailored) sebagai pendekatan generik,

misalnya dari PMBOK (April & Abran, 2008, hal. 155-156).

4.1.3.4 Requirements Management (REQM)

Untuk memetakan PA REQM dari CMMI ke S3m, pertama-tama SG dan SP dari

PA REQM didaftarkan dulu, lalu di S3m dicari praktek yang mencakup hal yang

serupa. Berikut SG dan SP dari REQM:


119


SG 1: Manage Requirements

SP 1.1: Understand Requirements

SP 1.2: Obtain Commitment to Requirements

SP 1.3: Manage Requirements Changes

SP 1.4: Maintain Bidirectional Traceability of Requirements

SP 1.5: Ensure Alignment Between Project Work and Requirements

Dalam S3m, April & Abran tidak memetakan secara eksplisit PA REQM dari

CMMI. Untuk mencari pemetaannya ke KPA di S3m, dilakukan pencarian praktek

terhadap kata-kata kunci yang diturunkan dari SP, sebagai berikut: manage

requirement, understand requirement, commitment, change management,

traceability, alignment.

Untuk SP 1.1 ditemukan pada KPA Operational Support Services (Evo2),

Business Rules and Functional Support Road Map, praktek Evo2.2.5:

“The maintenance engineer has functional and business rules expertise SP1.1 about

the software he/she maintains.” (April & Abran, 2008, hal. 177)

Untuk kata kunci change management, ditemukan di KPA Configuration and

Version Management (Sup1), Change Management Road Map, praktek Sup1.2.1:

“Modification requests are documented, prioritized, and authorized, by the

customers before implementing a change SP1.3 to the application software.” (April

& Abran, 2008, hal. 189)

Dapat disimpulkan bahwa praktek di atas memenuhi SP 1.3.

Untuk kata kunci traceability, ditemukan di KPA Configuration and Version

Management (Sup1), praktek Sup1.2.7:

“There is traceability between CR, the requirements, the detailed designs, and the

source code at one end, end the integration testing sets at the other SP1.4.” (April

& Abran, 2008, hal. 190)


120


Praktek di atas tidak menyebutkan apakah traceability merupakan dua arah

(bidirectional).

Berikut hasil pemetaan SP di REQM ke praktek di S3m:

Gambar 4.6 Pemetaan SP dari REQM di CMMI-DEV V1.3 ke S3m

Jadi dapat disimpulkan bahwa dari PA REQM di CMMI, hanya SP 1.1, SP 1.3

dan SP 1.4 yang ditemui di S3m.

4.1.3.5 Product Integration (PI)

Untuk memetakan PA PI dari CMMI ke S3m, pertama-tama SG dan SP dari PA PI

didaftarkan dulu, lalu di S3m dicari praktek yang mencakup hal yang serupa.

Berikut SG dan SP dari PI:

SG 1: Prepare for Product Integration

SP 1.1: Establish an Integration Strategy

SP 1.2: Establish the Product Integration Environment

SP 1.3: Establish Product Integration Procedures and Criteria

SG 2: Ensure Interface Compatibility

SP 2.1: Review Interface Descriptions for Completeness

SP 2.2: Manage Interfaces

SG 3: Assemble Product Components and Deliver Final Product

SP 3.1: Confirm Readiness of Product Components for Integration

SP 3.2: Assemble Product Components

SP 3.3: Evaluate Assembled Product Components

SP 3.4: Package and Deliver the Product or Product Component


121


Dalam S3m, April & Abran tidak memetakan secara eksplisit PA PI dari CMMI.

Untuk mencari pemetaannya ke KPA di S3m, dilakukan pencarian praktek

terhadap kata-kata kunci yang diturunkan dari SP, sebagai berikut: integration

strategy, integration environment, interface, manage interfaces, confirm

readiness, product components, assemble product components, package.

Kata kunci interface dalam konteks integrasi produk ditemukan dalam KPA

Predelivery and Transition Services (Evo1), praktek Evo1.2.9 (cetak tebal

tambahan penulis):

“Software maintenance engineers, who are responsible for conducting the final

transition, ensure the product documentation is obtained, that they understand its

interfaces, data, and operational environment, and that they update the

outstanding problems log before final transition.” (April & Abran, 2008, hal.

174)

Dapat dilihat dari praktek Evo1.2.9 di atas bahwa KPA Evo1 lebih membahas ke

arah pemahaman terhadap antar muka produk dan lingkungan produk, bukan ke

arah pembuatan dan pengaturan antar muka seperti di PA PI. Hal ini berarti tidak

ada SP yang dapat dipetakan ke praktek ini. Karena tidak ada SP yang dapat

dipetakan, maka dapat disimpulkan bahwa PA PI tidak dapat dipetakan ke KPA di

S3m.

4.1.3.6 Requirement Development (RD)

Untuk memetakan PA RD dari CMMI ke S3m, pertama-tama SG dan SP dari PA

RD didaftarkan dulu, lalu di S3m dicari praktek yang mencakup hal yang serupa.

Berikut SG dan SP dari RD:

SG 1: Develop Customer Requirements

SP 1.1: Elicit Needs

SP 1.2: Transform Stakeholder Needs into Customer Requirements

SG 2: Develop Product Requirements

SP 2.1: Establish Product and Product Component Requirements

SP 2.2: Allocate Product Component Requirements


122


SP 2.3: Identify Interface Requirements

SG 3: Analyze and Validate Requirements

SP 3.1: Establish Operational Concepts and Scenarios

SP 3.2: Establish a Definition of Required Functionality and Quality

Attributes

SP 3.3: Analyze Requirements

SP 3.4: Analyze Requirements to Achieve Balance

SP 3.5: Validate Requirements

Dalam S3m, April & Abran tidak memetakan secara eksplisit PA RD dari CMMI.


terhadap kata-kata kunci yang diturunkan dari SP, sebagai berikut: elicit,

stakeholder needs, customer requirements, establish requirements, allocate

requirements, interface requirements, operational concept, scenario, required

functionality, quality attributes, analyze requirement, achieve balance, validate

requirements.

Kata kunci requirements of the user ditemukan dalam KPA Software Evolution

and Correction Services (Evo3), Detailed Design Road Map, praktek Evo3.2.1:

“The detailed design elaborates the requirements of the user SP1.2, and it is

developed according to documented procedure SP1.1.” (April & Abran, 2008, hal.

179)

Kata kunci customer’s requirements ditemukan dalam KPA Verification and

Validation (Evo4), praktek Evo4.2.4:

“The acceptance test is performed according to a documented procedure to show

that the modified product conforms to and meets the customer’s requirements

SP3.5.” (April & Abran, 2008, hal. 185)

Praktek di atas membahas tentang uji penerimaan (acceptance test) yang

dilakukan untuk validasi dari pelanggan bahwa modifikasi perangkat lunak sudah

sesuai dengan persyaratannya. Jadi SP 3.5 dipetakan ke praktek Evo4.2.4.


123


Untuk SP 3.4 ditemukan di KPA SLA and Supplier Agreements Management

(Req4), Report, Explain, and Bill Services Road Map, praktek, Req4.2.13:

“Raw data describing costs are available for some maintenance resources,

(personnel, systems, and contract/licenses). Maintenance billing captures,

presents, and explains the most important cost elements.” (April & Abran, 2008,

hal. 168)

Dalam PA RD, Konteks SP 3.4 adalah untuk mendapatkan keseimbangan antara

kebutuhan pemangku kepentingan dengan keterbatasan (constraints) seperti biaya,

jadwal, dan kinerja produk atau proyek (CMMI Product Team, 2010, hal. 339).

Dalam KPA Req4, konteks praktek Req4.2.13 adalah untuk membantu memahami

aspek biaya dari pekerjaan yang telah dilakukan berdasarkan kategori

pemeliharaan. Perbedaan utama antara SP 3.4 dengan Req4.2.13 adalah: dalam SP

3.4 pemahaman terhadap constraints dilakukan sebelum pekerjaan dilakukan,

sedangkan dalam Req4.2.13 dilakukan setelah pekerjaan dilakukan.

Berikut hasil pemetaan SP di RD ke praktek di S3m:

Gambar 4.7 Pemetaan SP dari RD di CMMI-DEV V1.3 ke S3m

Hanya SP 1.1, SP 1.2, dan SP 3.5 yang ditemukan dalam S3m.


124


4.1.3.7 Technical Solution (TS)

Untuk memetakan PA TS dari CMMI ke S3m, pertama-tama SG dan SP dari PA

TS didaftarkan dulu, lalu di S3m dicari praktek yang mencakup hal yang serupa.

Berikut SG dan SP dari TS:

SG 1: Select Product Component Solutions

SP 1.1: Develop Alternative Solutions and Selection Criteria

SP 1.2: Select Product Component Solutions

SG 2: Develop the Design

SP 2.1: Design the Product or Product Components

SP 2.2: Establish a Technical Data Package

SP 2.3: Design Interfaces Using Criteria

SP 2.4: Perform Make, Buy, or Reuse Analyses

SG 3: Implement the Product Design

SP 3.1: Implement the Design

SP 3.2: Develop the Product Support Documentation

Dalam S3m, April & Abran tidak memetakan secara eksplisit PA TS dari CMMI.


terhadap kata-kata kunci yang diturunkan dari SP, sebagai berikut: alternative

solution, selection criteria, product design, technical data package, design

interface, make analysis, buy analysis, reuse analysis, design implementation,

support documentation.

Kata kunci documentation dalam konteks produk, ditemukan dalam penjelasan

KPA Software Evolution and Correction Services (Evo3), Detailed Design Road

Map, praktek Evo3.2.1:

“The detailed design elaborates the requirements of the user, and it is developed

according to documented procedure.” (April & Abran, 2008, hal. 179)

Berikut teks penjelasannya:

“For example, once the detailed design on the RMs for maintenance has

identified the affected components in the software SP2.1, the maintainer modifies


125


the documentation for these components SP3.2, builds test cases for verification,

validates new design, (including the questions about security and safety),

identifies and creates the test cases for regression, and finally, updates the

documentation with the list of modifications SP3.2.” (April & Abran, 2008, hal.

179)

Konteks dokumentasi di Evo3 memiliki perbedaan dengan TS. Dalam SP 3.2

konteksnya adalah pembuatan dokumentasi, sedangkan dalam Evo3.2.1,

konteksnya adalah modifikasi dari dokumentasi yang sudah ada.

Kata kunci documentation juga ditemukan dalam Documentation Road Map,

praktek Evo3.2.10:

“The internal documentation of the software is modified and kept up to date SP2.2

according to a documented procedure.” (April & Abran, 2008, hal. 181)

Karena praktek Evo3.2.10 membahas tentang dokumentasi internal, praktek ini

dapat dipetakan ke SP 2.2 yang membahas tentang paket data teknis (technical

data package) seperti: gambaran arsitektur produk, gambaran komponen produk,

dll. Ada perbedaan konteks antara CMMI dan S3m, yaitu dalam CMMI membahas

tentang pembuatan paket data teknis, sementara dalam S3m adalah untuk

menjaganya tetap kini (up to date).

Selain itu, dokumentasi juga dibahas dalam Evo3.2.11:

“The external documentation of the software is modified and kept up to date SP3.2

according to a documented procedure.” (April & Abran, 2008, hal. 182)

Karena praktek Evo3.2.11 membahas tentang dokumentasi eksternal, maka

praktek tersebut dipetakan dengan SP 3.2 di TS.

Untuk SP 3.1 ditemukan dalam Evolution/Correction Road Map, praktek

Evo3.2.3:

“The activities of implementation (programming) are performed SP3.1 according to

a documented procedure.” (April & Abran, 2008, hal. 179)


126


Berikut hasil pemetaan SP di TS ke praktek di S3m:

Gambar 4.8 Pemetaan SP dari TS di CMMI-DEV V1.3 ke S3m

Dapat dilihat bahwa tidak semua SP dalam TS dapat dipetakan ke praktek di S3m.

4.1.3.8 Decision Analysis and Resolution (DAR)

Untuk memetakan PA DAR dari CMMI ke S3m, pertama-tama SG dan SP dari PA

DAR didaftarkan dulu, lalu di S3m dicari praktek yang mencakup hal yang serupa.

Berikut SG dan SP dari TS:

SG 1: Evaluate Alternatives

SP 1.1: Establish Guideline for Decision Analysis

SP 1.2: Establish Evaluation Criteria

SP 1.3: Identify Alternate Solutions

SP 1.4: Select Evaluation Methods

SP 1.5: Evaluate Alternative Solutions

SP 1.6: Select Solutions

Dalam S3m, April & Abran tidak memetakan secara eksplisit PA DAR dari

CMMI. Untuk mencari pemetaannya ke KPA di S3m, dilakukan pencarian praktek

terhadap kata-kata kunci yang diturunkan dari SP, sebagai berikut: decision

analysis, establish guideline, evaluation criteria, alternate solutions, evaluation

methods, evaluate alternative, select solution.

Kata kunci decisional analysis ditemukan di KPA Causal Analysis and Problem

Resolution (Sup4), Identify and Analyze Causes Road Map, praktek Sup4.2.2:


127


“Maintenance management analyzes quality, customer, and performance data

regularly.” (April & Abran, 2008, hal. 196)


“To meet this practice, decisional analysis activities on general quality,

performance, and satisfaction data are identified SP1.3. Results are communicated

and can be the object of specific problem resolution assignments.” (April &

Abran, 2008, hal. 196)

Kata kunci decisional analysis juga ditemukan di penjelasan praktek Sup4.2.3:

“Upper managers analyze the results of surveys and develop and implement an

action plan based on their analysis SP1.5, SP1.6. These results and the action plan

are communicated to all personnel.” (April & Abran, 2008, hal. 197)


“To meet this practice, decisional analysis activities on general maintenance

personnel satisfaction data are identified SP1.3. Results are communicated and can

be the object of specific problem resolution assignments.” (April & Abran, 2008,

hal. 197)

Berikut hasil pemetaan SP di DAR ke praktek di S3m:

Gambar 4.9 Pemetaan SP dari DAR di CMMI-DEV V1.3 ke S3m

Dapat dilihat bahwa SP 1.1, SP 1.2, dan SP 1.4 tidak dapat dipetakan ke S3m.


128


Setelah semua PA yang tidak dipetakan secara eksplisit dalam April & Abran

(2008) dilakukan, maka berikut hasil pemetaannya:


Berdasarkan Pemetaan Praktek-praktek

Dapat dilihat bahwa ada 2 PA di CMMI-DEV V1.3 yang tidak bisa dipetakan ke

S3m, yaitu: Integrated Project Management dan Product Integration. PA

Integrated Project Management tidak relevan untuk pemeliharaan perangkat


129


lunak dengan skop permintaan (request), karena dalam skop permintaan kecil

tersebut teknik manajemen proyek tidak diperlukan. PA Product Integration tidak

relevan untuk penelitian ini karena objek studi kasus terbatas pada satu SI.

Sedangkan di sisi S3m, ada 3 KPA yang tidak memiliki pasangan di CMMI-DEV

V1.3, yaitu: Event/Request Management, Predelivery and Transition Services, dan

Software Rejuvenation, Migration and Retirement. KPA Event/Request

Management merupakan adaptasi dari manajemen proyek tapi untuk skala

permintaan atau kejadian, yang ukurannya kecil, cepat muncul, dan cepat

ditangani. KPA Predelivery and Transition Services dan KPA Software

Rejuvenation, Migration, and Retirement mencakup proses-proses yang unik

untuk pemeliharaan perangkat lunak. Ketiga KPA ini dinilai sehingga wajar jika

tidak dicakup dalam CMMI-DEV V1.3 yang fokusnya adalah organisasi dan

proyek-proyek pengembangan perangkat lunak.

Jadi dapat disimpulkan bahwa semua KPA dalam S3m sudah mencakup area-area

proses di CMMI-DEV V1.3 yang relevan dalam bidang pemeliharaan perangkat

lunak. Berdasarkan kesimpulan ini, maka kajian terhadap objek studi kasus

dilakukan dengan menggunakan metode S3mAssess.

4.2 Penjabaran Hasil Kajian

Bagian ini membahas hasil wawancara dan hasil penilaian dari masing-masing

KPA dalam S3m. Kajian dilakukan dengan melakukan wawancara kepada

narasumber di Tabel 3.2 (Pemilihan Narasumber Masing-masing KPA), dengan

mengajukan pertanyaan-pertanyaan yang diturunkan dari praktek-praktek dalam

S3m di Tabel 3.3 (Pointer Pertanyaan Wawancara), lalu mencari artifak

pendukungnya.

4.2.1 Maintenance Process Focus (Pro1)

Tujuan dari KPA ini adalah memastikan tanggung jawab untuk mengumpulkan

informasi yang diperlukan untuk perbaikan yang dibutuhkan, mengembangkan

wawasan untuk menganalisanya, dan mengidentifikasi solusi perbaikan

berdasarkan prioritas, tujuan, dan batasan (April & Abran, 2008, hal. 86).


130


Berikut adalah pertanyaan yang diajukan kepada narasumber beserta respons mereka yang berkaitan dengan KPA ini:

Tabel 4.1 Ringkasan Penilaian Praktek-praktek Pro1

Nomor

Praktek

Pointer Pertanyaan

(Dari Tabel 3.3) Respons Kelemahan

Nilai

(Rating)

Pro1.0.1

Apakah Departemen TI tidak melakukan

aktivitas perbaikan proses yang mengarah

kepada perbaikan yang terkendali dan terus

menerus?

Lampiran I (J3-J4):

“...metode implementasi di mana kita

melihat dari seluruh user response ...

application response, kita matriks ...

terus kita ambil rata-ratanya. Nah,

terus untuk yang tidak memenuhi

dengan SLA itu, kita lihat kenapa. Itu

dilakukan terus-menerus.”

- No

(100%)

Pro1.1.1 Apakah Departemen TI melakukan perbaikan

proses secara informal?

Lampiran I (J5):

“Informal, belum ada blueprint,

belum ada SOP-nya ...”

Belum ada petunjuk

pelaksanaannya.

Largely

Achieved

(68%)

Pro1.1.2

Apakah inisiatif perbaikan proses bertujuan

untuk memperbaiki aspek teknis dari proses

perawatan perangkat lunak?

Lampiran I (J10-J11):

“Job description pasti.”

“Tidak secara harfiah ...”

1. Tujuan utamanya

bukan aspek teknis.

2. Tidak artifak

pendukung.

Partially

Achieved

(33%)

Pro1.2.1

Apakah program perbaikan proses dan kualitas

sudah dimulai di tingkat Departemen TI?

Apakah Bapak - sebagai manajer yang

bertanggung jawab terhadap perawatan

perangkat lunak - mengetahui/sadar akan

program ini? Apakah Bapak sudah pernah

diberikan pelatihan kesadaran kualitas (quality


“Kalau quality awareness belum.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)


131


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

awareness training)?

Pro1.2.2

Adakah perwakilan dari Departemen TI yang

ditugaskan untuk merencanakan dan

mengoordinasikan aktivitas perbaikan proses?


“... kita lagi mau untuk ... ini kan mau

ikut training, beberapa saya sudah

tunjuk untuk mau ikut training ...”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Pro1.2.3

Apakah ada survei untuk mencari tahu tingkat

kepuasan pengguna terhadap proses perawatan

perangkat lunak (misalnya korektif atau

adaptif)? Kalau ada, apakah hasil survei tersebut

digunakan untuk mengidentifikasi kandidat

perbaikan proses?


“Belum. Paling yang ada adalah

mereka kan belum ada surveinya ...”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Pro1.2.4

Adakah pengumpulan pendapat dari tim

Developer, tim Hardware & Infrastructure, dan

tim Help Desk, tentang proses perawatan

perangkat lunak? Kalau ada, apakah pendapat-

pendapat tersebut digunakan untuk

mengidentifikasi kandidat perbaikan proses?


“...sekarang kita mau implementasi

user portal sendiri untuk user

submission ...”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Pro1.2.5 Apakah Departemen TI melakukan profiling

atau benchmarking aplikasi secara berkala?


“Dulu disimpan.”

“Nggak, yang ini nggak secara

berkala.”

Data yang bukan untuk

perbaikan proses.

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Pro1.2.6

Adakah pengumpulan data kesalahan perangkat

lunak? Kalau ada, apakah data tersebut

digunakan untuk perbaikan proses atau

Lampiran I (J26-28):

“Kalau mau laporan iya. Maksudnya

secara periodik kita mau lapor ke

Data tidak digunakan


masalah dan kandidat

Largely

Achieved

(68%)

Tabel 4.1 Ringkasan Penilaian Praktek-praktek Pro1 (sambungan)


132


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

perbaikan perangkat lunak tersebut? Kalau ada,

untuk apakah data tersebut digunakan?

steering committee ...” perbaikan proses.

Pro1.2.7

Apakah Departemen TI sudah pernah diaudit

terhadap suatu standar, misalnya untuk COBIT,

ISO 90003, dsb.? Kalau sudah, apakah hasilnya

digunakan untuk mengidentifikasi kandidat

perbaikan proses?

Lampiran I (J29):

“Belum.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Pro1.2.8

Apakah Departemen TI sudah pernah

dikaji/dinilai (assess) terhadap suatu model

referensi (misalnya menggunakan SCAMPI

terhadap CMMI-DEV V1.3)? Kalau sudah,

apakah hasilnya digunakan untuk

mengidentifikasi kandidat proses?

Lampiran I (J30):

“Belum.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Pro1.2.9

Apakah Departemen TI ada membuat daftar

kandidat perbaikan, yang diurutkan berdasarkan

prioritas? Apakah daftar tersebut digunakan

sebagai panduan dalam mengembangkan

program perbaikan proses perawatan perangkat

lunak?


“...kita punya list improvement.”

“Dalam bentuk project plan.”

-

Fully

Achieved

(93%)

Pro1.2.10

Apakah manajemen senior ada membuat dan

mendiskusikan rencana tindakan (action plan)

yang berisi 10 perbaikan proses tertinggi (top 10

improvement) untuk perawatan perangkat

lunak? Apakah rencana aktivitas/proyek

Lampiran I (J33):

“Mungkin bukan top 10, tapi ada

kriterianya ...”

Praktek tidak

dilakukan.

Not

Achieved

(0%)



133


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

perbaikan proses perawatan perangkat lunak

tersebut didanai dari anggaran tahunan?

Pro1.2.11

Apakah ada perbaikan proses yang sudah

dimulai? Apakah rencana tahunan dari

Departemen TI memiliki kegiatan yang

direncanakan untuk perbaikan proses perawatan

perangkat lunak? Apakah rencana tersebut

dilaksanakan?


“Ada. Itu yang sedang kita berusaha

implementasi.”

“Bukan berarti sudah dijalankan, baru

kita mengarah ke sana ...”

Sudah masuk program

kerja, tapi belum

dilaksanakan.

Partially

Achieved

(33%)

Penjelasan dari setiap praktek-praktek di Tabel 4.1 di atas dijelaskan di subbab 4.2.1.1 sampai 4.2.1.14 untuk memaparkan kelemahan yang

diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Maintenance Process Focus (Pro1).



134


4.2.1.1 Praktek Pro1.0.1

Praktek : The software maintenance organization does not carry out

structured process improvement activities leading to persistent

and controlled improvements.

Sumber Lisan : Lampiran I (J3-J4)

Artifak : -

Berdasarkan bukti lisan, pernyataan negatif untuk praktek ini tidak dipenuhi. Saat

ini salah satu kegiatan Departemen TI untuk perbaikan proses yang akan adalah

mengadopsi metodologi agile, yang dinilai dapat memberikan perbaikan yang

menetap (persistent) dan terkontrol.


Praktek : Within the software maintenance organization, improvement is


Sumber Lisan : Lampiran I (J5)

Artifak : Program Kerja Departemen TI (Pro1.1.1 - IT Raker 2016 -

v2.pptx)

Berdasarkan bukti lisan dan artifak yang dihasilkan, pernyataan untuk praktek ini

dipenuhi. Biarpun pengenalan metodologi yang dinilai dapat memperbaiki proses

sudah masuk ke dalam program kerja departemen, program tersebut belum

dilaksanakan, dan belum ada petunjuk pelaksanaannya. Berarti dapat disimpulkan

bahwa praktek ini tercapai sebagian besar (Largely Achieved).


Praktek : Some individual improvement initiatives aim mostly at

improving technical aspects of software maintenance processes.


Artifak : -


135


Berdasarkan bukti lisan, ada inisiatif pribadi – yang dianggap sebagai pemenuhan

uraian tugas – yang bertujuan untuk meningkatkan perbaikan proses. Kekurangan

praktek ini adalah tujuan utamanya bukan aspek teknis, dan tidak didukung bukti

artifak. Berarti dapat disimpulkan bahwa praktek ini tercapai sebagian (Partially

Achieved).


Praktek : A quality and process improvement program has been initiated

at the IS/IT organization level. The software maintenance

managers are aware of this program and have had initial

quality awareness training.


Artifak : -

Berdasarkan bukti lisan, belum ada kegiatan quality awareness. Kegiatan

berkaitan awareness yang dilakukan terbatas pada penjelasan strategic initiative

perusahaan, dan tidak kepada seluruh Departemen TI. Jadi dapat disimpulkan

bahwa praktek ini tidak tercapai (Not Achieved).


Praktek : A representative of the software maintenance organization is

assigned to plan and coordinate improvement activities.


Artifak : -

Berdasarkan bukti lisan, saat ini yang menjadi koordinator kegiatan perbaikan

proses adalah Kepala Departemen TI sendiri. Kepala Departemen TI berencana

untuk memberikan tugas koordinasi tersebut ke stafnya, tapi belum dilaksanakan,

penyampaiannya secara lisan, dan rencana penugasannya belum secara tertulis.

Jadi dapat disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).


136



Praktek : Results of the software maintenance products/services customer

survey is used to identify candidate improvement.


Artifak : -

Berdasarkan bukti lisan, saat ini tidak ada survei untuk mengidentifikasi kandidat

perbaikan proses. Jadi dapat disimpulkan bahwa praktek ini tidak tercapai (Not

Achieved).


Praktek : The observations, comments, and complaints from

users/customers and interface groups (developers, operations,

help desk, subcontractors, etc.) are used to collect data for

identifying candidate improvements.


Artifak : Email Tiket (Pro1.2.4 - Ticket #21495 Follow Up Proses

Program B2C Marine Cargo PT ANTAM (Persero) Tbk -

Spiceworks.msg)

Berdasarkan bukti lisan dan artifak yang dihasilkan, pengumpulan komentar dan

komplain dari pengguna yang berkaitan dengan proses maintenance dilakukan

melalui sistem ticketing. Hal ini berarti perlakuannya tidak dibedakan dengan tiket

laporan insiden (problem report), permintaan modifikasi aplikasi (modification

request), dan dengan permintaan dukungan (support request). Kekurangan

praktek ini adalah manajemen akan kesulitan untuk memisahkan masukan atau

komplain dari PR, MR, dan SR. Selain itu, tujuan utama dari pengumpulan data

ini bukan untuk perbaikan proses, melainkan untuk memperbaiki kerusakan atau

kesalahan sistem, demi pencapaian SLA. Bottleneck proses diidentifikasi bukan

dengan menggunakan data ini. Jadi dapat disimpulkan bahwa praktek ini tidak

tercapai (Not Achieved).


137



Praktek : Comparisons of application software profiles and relevant

internal benchmarks are used to identify candidate

improvements.


Artifak : -

Berdasarkan bukti lisan, Departemen TI melakukan stress test untuk menguji SI,

tapi bukan untuk perbaikan proses. Kegiatan profiling SI belum dilakukan secara

berkala, tapi sudah ada rencana tidak tertulis untuk ini. Hasil profiling disimpan

tapi tidak dijaga kekiniannya sehingga tidak bisa digunakan sebagai indikator

terhadap peningkatan atau penurunan kinerja proses. Jadi dapat disimpulkan



Praktek : The data on software failures is collected and used to identify

candidate improvements to maintenance processes/products and

also to the many interfaces with the other interface groups

(developers, operations, help desk, subcontractors, etc.)

Sumber Lisan : Lampiran I (J26-28)

Artifak : Laporan dari Dashboard (Pro1.2.6 - Laporan Dashboard.png)

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini dilakukan

pengumpulan data kegagalan atau kerusakan perangkat lunak. Data yang

dikumpulkan digunakan untuk perbaikan produk dan sebagai laporan terhadap

steering committee perusahaan. Data ini juga digunakan untuk meminimalkan

kesalahan oleh pengguna, dengan cara mengubah aplikasi. Kelemahan dari

praktek ini adalah data tersebut belum digunakan untuk mengidentifikasi masalah

dan kandidat perbaikan dalam proses pemeliharaan perangkat lunak itu sendiri.

Jadi dapat disimpulkan bahwa praktek tercapai sebagian besar (Largely Achieved).


138



Praktek : The maintenance organization is subject to internal audits from

internal auditor (e.g., COBIT, ISO 90003 4.2.4 e or other types of

audits) and the results are used to identify candidate

improvements.


Artifak : -

Berdasarkan bukti lisan, saat ini Departemen TI belum pernah diaudit terhadap

suatu standar. Jadi disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).


Praktek : A maturity assessment of some processes has been performed.

At least one maintenance organization has conducted a process

maturity assessment and the results are used to identify

candidate improvements.


Artifak : -

Berdasarkan bukti lisan, Departemen TI belum pernah melakukan penilaian

kematangan terhadap suatu model referensi. Jadi disimpulkan bahwa praktek ini

tidak tercapai (Not Achieved).


Praktek : A list of candidate improvements, ordered by priorities, is

developed and used as a guide for developing the software

maintenance improvement program.


Artifak : Daftar Kandidat Perbaikan


139


Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini Departemen TI sudah

memiliki daftar kandidat perbaikan proses. Jika perbaikan proses tersebut dinilai

besar, maka akan dijadikan suatu proyek perbaikan proses. Jadi disimpulkan

bahwa praktek ini tercapai sepenuhnya (Fully Achieved).

4.2.1.13 Praktek Pro1.2.10

Praktek : The list of the top 10 possible improvements is discussed, and

actions plans are drawn up by middle and senior management.

The planned improvement activities/projects are funded within

the annual budgets and current operations.


Artifak : -

Berdasarkan bukti lisan, belum ada diskusi mengenai daftar perbaikan proses

pemeliharaan perangkat lunak dengan pihak manajemen. Jadi disimpulkan bahwa

praktek ini tidak tercapai (Not Achieved).

4.2.1.14 Praktek Pro1.2.11

Praktek : Improvements to some processes have been initiated. The

annual plan, of each maintenance organization, includes both

the improvement activities planned and carried out during the

year.


Artifak : Program Kerja Departemen TI (Pro1.2.11 - IT Raker 2016 -

v2.pptx)

Berdasarkan bukti lisan dan artifak yang dihasilkan, belum ada perbaikan proses

yang terlaksana. Saat ini ada perbaikan proses yang masuk ke dalam program

kerja tahun berjalan dari Departemen TI, tapi belum dilaksanakan. Jadi dapat

disimpulkan bahwa praktek ini tercapai sebagian (Partially Achieved).


140


4.2.2 Maintenance Process/Service Definition (Pro2)

Tujuan dari KPA ini adalah untuk membangun, mendokumentasikan, merancang,

dan memelihara proses-proses yang memiliki standar. Termasuk di dalamnya

adalah pembangunan infrastruktur untuk mendukung proses-proses ini, misalnya

gambaran dari request life cycle untuk tiap jenis pemeliharaan, kebijakan dan

kriteria untuk penyesuaian (customization) proses, gudang (repository) proses

perusahaan (April & Abran, 2008, hal. 87).

Berikut adalah pertanyaan yang diajukan kepada narasumber beserta respons

mereka yang berkaitan dengan KPA ini:


141



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Pro2.0.1

Apakah Departemen TI tidak melakukan aktivitas

mendefinisikan proses atau layanan? Apakah Departemen

TI tidak menyediakan daftar atau direktori layanan kepada

para pengguna?

Lampiran I (J38):

“…ada SOP-nya.” - No (100%)

Pro2.1.1 Apakah proses atau layanan bersifat tidak formal dan

berdasarkan pada pengalaman individu saja?

Lampiran I (J39):

“Iya.”

1. Proses baru

didefinisikan saat ada

masalah.

2. Tidak ada artifak

pendukung.

Partially

Achieved

(33%)

Pro2.1.2 Apakah inisiatif individu dalam mendefinisikan proses atau

layanan ini utamanya untuk mengatasi aspek teknis?

Lampiran I (J41, J63):

“Dokumen nggak disebar

...”

“Iya.”

-

Fully

Achieved

(100%)

Pro2.2.1

Apakah Departemen TI (atau salah satu seksinya)

mendefinisikan dan mendokumentasikan proses standarnya

yang digunakan untuk menggambarkan aktivitasnya?

Apakah dokumen tersebut dibagikan kepada pengguna?

Apakah pengguna menggunakan dokumen tersebut?


“Business Analyst.”

“Dokumen nggak disebar

...”

1. Dokumen-dokumen

standar proses tidak

disebar.


pendukung. Praktek

tidak dilakukan.

Not

Achieved

(0%)

Pro2.2.2

Apakah Departemen TI memiliki dokumentasi proses

perawatan perangkat lunak, baik layanannya maupun

sumber dayanya (personil, tool, perangkat lunak,

lingkungan kerja, standar pemrograman, naming

conventions)? Apakah dokumen tersebut dijaga up-to-date?

Lampiran I (J42):

“Kalau khusus

maintenance nggak ada.”

Lampiran G (J168):

“Nggak.”

1. Pernyataan yang

berlawanan.


pendukung.

Not

Achieved

(0%)


142


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Apakah dokumen tersebut digunakan orang yang bertugas

memelihara perangkat lunak?

Pro2.2.3

Apakah Departemen TI memiliki aktivitas untuk

mendokumentasikan dan menstandarkan proses atau

layanan perawatan perangkat lunak?

Lampiran I (J43):

“Ada. Sudah ada functional

spec-nya, harus tanda

tangan siapa gitu.”

Tidak disediakan

tempat dan struktur

khusus untuk gudang

(repository) praktek

standar.

Largely

Achieved

(68%)

Pro2.2.4

Apakah Bapak - sebagai manajer yang bertanggung jawab

untuk pemeliharaan perangkat lunak - mengakui dan

mempromosikan (acknowledges and promotes) penggunaan

proses atau layanan yang terstandarisasi, dan penggunaan

standar eksternal yang relevan untuk perawatan perangkat

lunak (seperti ISO 9001, ISO 12207, ISO 14764)?

Lampiran I (J44):

“Tidak. Saya justru lebih ke

metodologinya dulu

daripada ini. Saya mau ke

agile. Itu yang saya pikir

lebih benefit.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)


diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Maintenance Process/Service Definition (Pro2).



143




process/services definition activities. It does not provide a list or

directory of services to its customers.


Artifak : Standar Data Upload (Pro2.0.1 - Standar Data Up Load -

PA.docx)

Berdasarkan bukti lisan dan artifak yang dihasilkan, pernyataan negatif praktek ini

tidak dipenuhi. Kegiatan mendefinisikan proses dan layanan pemeliharaan

perangkat lunak sudah dilakukan secara formal, karena sudah ada SOP.


Praktek : The maintenance processes/services are informal and based on

the experience of individuals.


Artifak : -

Berdasarkan bukti lisan, proses dibuat secara formal, tapi bersifat reaktif. Proses

baru didefinisikan saat ada masalah yang teridentifikasi dan berlanjut.

Kekurangan lainnya praktek ini adalah tidak adanya bukti artifak yang

mendukung pernyataan. Jadi dapat disimpulkan bahwa praktek ini tercapai

sebagian (Partially Achieved).


Praktek : Individual initiatives, for defining maintenance

processes/services, mainly address technical aspects of the

software or describe, in a local format, the activities of a

specific maintenance organization.


144


Sumber Lisan : Lampiran I (J41, J63)

Artifak : Standar Data Upload (Pro2.1.2 - Standar Data Up Load -

PA.docx)

Berdasarkan bukti lisan dan artifak yang dihasilkan, sudah ada inisiatif untuk

mendefinisikan proses atau layanan pemeliharaan perangkat lunak. Hal ini

didukung dengan bukti artifak berupa prosedur standar untuk unggah data ke

dalam SI dan format standar datanya. Prosedur dan format ini spesifik untuk tim

support. Jadi dapat disimpulkan bahwa praktek ini sudah tercapai secara penuh

(Fully Achieved).


Praktek : There is at least one description of maintenance

processes/services that is used by the customer and offered by

the maintenance organization.


Artifak : -

Berdasarkan bukti lisan, yang bertugas untuk membuat dokumen standar proses

adalah Business Analyst. Kekurangan praktek ini adalah dokumen-dokumen

standar proses tidak disebar ke seluruh bagian PT XYZ. Jadi pada prakteknya

personil help desk yang melakukan pengisian formulir atau dokumen standar

berdasarkan tiket. Selain itu, kekurangan lainnya adalah tidak adanya artifak yang

menunjukkan daftar proses dan layanan yang disediakan oleh Departemen TI. Hal

ini berarti para pengguna tidak memiliki pemahaman terhadap proses atau layanan

standar pemeliharaan perangkat lunak yang disediakan oleh Departemen TI. Jadi

dapat disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).


Praktek : Portions of the maintenance processes/services/resources are

documented and deployed in the software maintenance

organization.


145


Sumber Lisan : Lampiran I (J42), Lampiran G (J168)

Artifak : -

Berdasarkan bukti lisan Lampiran I (J42), ada dokumentasi untuk pemrograman

yang digunakan sehari-hari dalam proses pemeliharaan perangkat lunak.

Kekurangannya adalah hal ini kontras dengan bukti lisan di Lampiran G (J168),

dan tidak adanya artifak yang mendukung bukti lisan Lampiran I (J42). Jadi dapat

disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).


Praktek : There are activities under way, at the organization unit level, to

document and standardize software maintenance

processes/services.


Artifak : Folder Elektronik Kepala Seksi Business Analyst (Pro2.2.3 -

Folder Kepala Seksi Business Analyst.png)

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini sudah ada aktivitas

untuk mendokumentasikan dan menstandarkan proses pemeliharaan perangkat

lunak. Kekurangan praktek ini adalah tidak disediakan tempat dan struktur khusus

untuk gudang (repository) praktek standar. Saat ini repository tersebut berbentuk

suatu folder elektronik yang isinya bercampur dengan dokumen pekerjaan Kepala

Seksi Business Analyst. Hal ini akan menyulitkan pencarian dokumen baik oleh

Kepala Seksi Business Analyst tersebut maupun oleh personil lain. Jadi dapat

disimpulkan bahwa praktek ini tercapai sebagian besar (Largely Achieved).


Praktek : Software maintenance management acknowledges and promotes

the use of standard processes/services and the use of external

standards relevant to software maintenance.



146


Artifak : -

Berdasarkan bukti lisan, saat ini Departemen TI tidak mengakui dan tidak

mempromosikan standar eksternal yang relevan untuk pemeliharaan perangkat

lunak. Jadi disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).

4.2.3 Maintenance Training (Pro3)

Tujuan dari KPA ini adalah untuk mengidentifikasi kebutuhan pelatihan dan

perencanaan pelatihan, dan untuk mengidentifikasi profil personil yang diperlukan

untuk perangkat lunak baru di tahap predelivery. Komitmen individu terhadap

pendidikan mereka sendiri adalah sesuatu yang penting dan harus dipromosikan.

Karyawan baru harus terlatih dan diawasi saat bergabung ke dalam tim

pemeliharaan. Pelatihan di sini termasuk untuk proses, dan juga untuk perangkat

lunak dan teknologi (April & Abran, 2008, hal. 89).




147



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Pro3.0.1

Apakah Departemen TI tidak memiliki kegiatan pelatihan yang terstruktur

yang mengatasi:

1. predelivery and transition,

2. perangkat lunak yang dirawat dan lingkungan teknisnya,

3. proses atau layanan perawatan perangkat lunak yang disediakan, dan

4. rencana karier atau semangat kerja personil.

Lampiran I (J45-

J47):

“Belum sih.”

Praktek tidak

dilakukan.

Yes

(100%)

Pro3.1.1

Apakah Departemen TI baru memberikan pelatihan dalam perawatan

perangkat lunak saat ada keperluan mendesak? (Misalnya pada saat ada

perubahan platform, infrastruktur, proses, atau saat ada perangkat lunak

yang selesai pengembangannya dan transisi ke perawatan)

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.1.2

Apakah sasaran utama pelatihan adalah aspek teknis dari perawatan

perangkat lunak dan dukungan produk saja? Apakah ada proses di mana

staf senior ditugaskan sebagai mentor bagi karyawan junior, untuk

menjawab pertanyaan-pertanyaannya?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.1.3

Apakah rencana pelatihan bagi karyawan yang bertugas untuk

pemeliharaan perangkat lunak mengatasi topik-topik umum tentang

manajemen, proses, dan aktivitas pemeliharaan perangkat lunak?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.1

Apakah karyawan yang bertugas untuk pemeliharaan perangkat lunak

diberikan pelatihan secara periodik sehingga menjadi mahir dalam struktur

perangkat lunak (komponen internalnya dan pemrosesan datanya)? Apakah

ada kegiatan diskusi yang terencana dengan pengguna tentang bagaimana

cara mereka menggunakan perangkat lunak tersebut?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.2 Apakah Departemen TI: (Tidak ditanyakan - Not


148


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

1. Mengidentifikasi pelatihan mana yang perlu diadakan?

2. Mengidentifikasi kelemahan dari pelatihan saat ini?

3. Mengulas dokumen pelatihan saat ini?

4. Menilai pengetahuan personil tentang proses pemeliharaan perangkat

lunak?

5. Mengundang personil pemeliharaan perangkat lunak untuk memberikan

saran untuk perbaikan dalam pelatihan untuk proses pemeliharaan

perangkat lunak?

karena praktek

tingkat 0 tidak

dilakukan)

Achieved

(0%)

Pro3.2.3 Apakah Departemen TI ada memberi pelatihan bagi personil pemeliharaan

perangkat lunak tentang komunikasi dengan pengguna?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.4 Apakah Departemen TI menggunakan data benchmark internal untuk

memandu pelatihan bagi personil pemeliharaan perangkat lunak?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.5

Apakah Departemen TI memiliki anggaran untuk pelatihan? Apakah ada

dokumentasi tentang:

1. Pelatihan yang sudah selesai?

2. Aktivitas pelatihan internal yang diikuti?

3. Rencana pelatihan ke depannya?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.6

Apakah ada rencana atau catatan tentang pendidikan atau pelatihan yang

dibutuhkan bagi setiap posisi pemeliharaan perangkat lunak? Apakah di

dokumennya ada:

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

-

Not

Achieved

(0%)



149


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

1. Daftar pelatihan yang diperlukan?

2. Daftar pelatihan yang ditawarkan?

3. Ketersediaan material, sumber daya, dan jadwal?

dilakukan)

Pro3.2.7

Apakah karyawan yang bertugas untuk pemeliharaan perangkat lunak

diberikan waktu khusus untuk pelatihan? Kalau ya, berapa jam dalam

seminggu?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.8

Apakah staf maintainer senior membiasakan karyawan prospektif

maintainer baru terhadap pemeliharaan perangkat lunak?

1. Dokumentasi dan library yang digunakan.

2. Editor, tools termasuk untuk membandingkan source code, compiler,

debuggers, static source code analyzers, test tools, documentation tools,

configuration management, dan DBMS.

3.Operasional dukungan (support) dan jam dukungan.

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.9

Apakah jika ada transisi proyek ke pemeliharaan, ada proses identifikasi

kebutuhan pelatihan, baik teknis maupun manajemen? (Misalnya

identifikasi pelatihan apa yang diperlukan, siapa yang perlu diberi

pelatihan, kapan, dst.) Apakah saat dalam proses pengembangan, pihak

pengembang (developer) mengidentifikasi kebutuhan pelatihan bagi

pengguna? Apakah ada komunikasi antara pengembang dan pemelihara

tentang kebutuhan pelatihan pengguna?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.10

Apakah pihak manajemen (Bapak, sebagai manajer yang bertanggung

jawab dalam pemeliharaan perangkat lunak) memastikan para maintainer

mendapatkan pelatihan sesuai dengan apa yang menurut developer

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

-

Not

Achieved

(0%)



150


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

merupakan keahlian yang dibutuhkan untuk memelihara perangkat lunak? dilakukan)

Pro3.2.11

Apakah materi pelatihan untuk pengguna sudah sesuai dengan dokumentasi

prosedur yang dilaksanakan saat ini? Apakah Departemen TI memiliki

prosedur pembuatan dokumentasi atau prosedur pembuatan materi

pelatihan?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.12

Apakah pengguna diberikan pelatihan atau pendidikan yang cukup untuk

dapat mengoperasikan atau menggunakan perangkat lunak tanpa bantuan

Departemen TI?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Pro3.2.13 Apakah Departemen TI memiliki prosedur untuk melakukan pengadaan

pelatihan bagi pengguna? Apakah para pengguna tahu prosedur ini?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Penjelasan dari setiap praktek-praktek di Tabel 4.3 di atas dijelaskan di subbab 4.2.3.1 untuk memaparkan kelemahan yang diidentifikasi

dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Maintenance Training (Pro3).



151



Praktek : Software maintenance organization do not have structured

training activities that address predelivery and transition, the

software maintained and its technical environment, the

maintenance processes/services or the engineers' morale career

plans.


Artifak : -

Berdasarkan bukti lisan, pernyataan negatif praktek ini dipenuhi. Saat ini

Departemen TI belum memiliki kegiatan untuk pelatihan personil pemeliharaan

perangkat lunak. Berdasarkan terpenuhinya pernyataan negatif praktek ini, maka

untuk praktek level 1 dan 2 tidak ditanyakan lagi ke narasumber.

4.2.4 Maintenance Process Performance (Pro4)

Tujuan dari KPA ini adalah untuk mendapatkan dan memelihara gambaran

kuantitatif dari kinerja aktivitas-aktivitas kunci dari proses-proses pemeliharaan

perangkat lunak. Ini akan membantu menjelaskan kinerja proses atau layanan saat

ini dan untuk menentukan target. Target kualitas ditentukan dengan

berkomunikasi dan negosiasi berdasarkan usulan target dengan

mempertimbangkan pencapaian tingkat layanan saat ini (April & Abran, 2008,

hal. 90).




152



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Pro4.0.1

Apakah Departemen TI tidak memiliki aktivitas yang

terorganisasi untuk pengukuran kinerja prosesnya,

layanannya, produknya, dan sumber dayanya?


“Iya sih, kalau untuk ini.”

“Penyelesaian bug-bug itu.

Rentang waktunya. Berapa

cepat penanganannya.”

- No (100%)

Pro4.1.1

Apakah pengukuran proses, layanan, atau produk

merupakan inisiatif individu, atau memang inisiatif

organisasi? Kalau individu, apakah ini berarti data yang

dikumpulkan tidak dibagikan dengan personil lainnya?


“Belum formal sih, masih

nonformal.”

“Nggak formal yang kita

kerjakan terus menerus.

Kalau ada masalah baru

kita perhatikan.”

1. Hasil pengukuran

tidak digunakan

untuk perbaikan

proses.


pendukung.

Largely

Achieved

(68%)

Pro4.1.2

Apakah data yang dikumpulkan berupa kualitatif atau

kuantitatif? Yang diukur apa? Kepuasan pelanggan? Atau

kecepatan transaksi?


“Ada cuma belum pernah

review.”

“Kita cuma ada menyimpan

jumlah tiketnya.”

Hanya

mengumpulkan PR.

Not

Achieved

(0%)

Pro4.2.1

Apakah Departemen TI memiliki ukuran-ukuran untuk

proses pemeliharaan perangkat lunak:

1. Persentase ukuran kepuasan pengguna, berdasarkan

survei?

2. Formulir untuk rekam penggunaan waktu berdasarkan

aktivitas atau sumber daya?

3. Jumlah panggilan telepon berdasarkan jenis layanan?


“Kalau lembur mungkin

nggak. Cuma berapa hari

saja resolve-nya.”

“Ada.”

“Bentuknya report dari

sistem ticketing.”

1. Tidak memiliki

survei kepuasan

pelanggan.

2. Tidak mencatat

waktu lembur untuk

pemeliharaan.

3. Jumlah SDM per

Partially

Achieved

(33%)


153


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

4. Jumlah pengguna?

5. Jumlah jam pekerjaan dan pekerjaan lembur?

6. Jumlah permintaan yang ditutup untuk suatu periode,

permintaan yang baru dibuka, permintaan yang dibawa dari

periode sebelumnya ke periode berikutnya, dan permintaan

yang lagi menunggu?

7. Jumlah personil untuk tiap SI?

8. Pengukuran untuk evolusi proses (misalnya

menggunakan model perbaikan dan/atau ISO 9001)?

“Yang di-update nggak sih.

Tapi penunjukannya ada.

Nggak ada surat

penunjukan. Lisan.”

proses tidak tertulis.

Pro4.2.2

Apa acuan pengukuran kinerja dan kualitas dari proses,

layanan, dan produk di Departemen TI (yang relevan untuk

pemeliharaan perangkat lunak)? Bagaimana acuan tersebut

dikumpulkan, disimpan, dan diulas? Apakah para

pemangku kepentingan tahu/paham tentang acuan tersebut?

Untuk apa acuan tersebut digunakan?

Lampiran I (J57):

“Belum sih.”

Praktek tidak

dilakukan.

Not

Achieved

(100%)

Pro4.2.3 Apakah Departemen TI ada menentukan tujuan/obyektif

kinerja dan kualitas?

Lampiran I (J58):

“Target kinerja ada, KPI.” -

Fully

Achieved

(100%)


diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Maintenance Process Performance (Pro4).



154



Praktek : The software maintenance organization does not have activities

organized to measure the performance of its processes, services,

products and resources.


Artifak : -

Berdasarkan bukti lisan, pernyataan negatif praktek ini tidak dipenuhi. Saat ini

Departemen TI sudah memiliki kegiatan untuk mengukur kinerja proses, layanan,

produk, dan sumber daya.


Praktek : Some initiatives for measuring process, services, or products

are carried out by individuals who have an interest in

measurement.


Artifak : -

Berdasarkan bukti lisan, sudah ada inisiatif individu untuk pengukuran proses,

layanan, atau produk. Pengukuran ini dilakukan secara informal karena tidak ada

review-nya. Hasil pengukuran tidak digunakan untuk perbaikan proses.

Kekurangan praktek ini adalah tidak adanya artifak pendukung. Jadi dapat

disimpulkan bahwa praktek ini tercapai sebagian besar (Largely Achieved)


Praktek : Some qualitative measures of maintenance processes, services,

and products are collected.


Artifak : -


155


Berdasarkan bukti lisan, belum ada pengukuran kualitatif tentang proses, layanan,

dan produk. Pengumpulan data dalam bentuk tiket dilakukan tapi hanya untuk

permasalahan (PR). Jadi disimpulkan bahwa praktek ini tidak tercapai (Not

Achieved).


Praktek : Some key maintenance processes, services, and products have

measures. They are defined and used locally.


Artifak : Laporan Tiket (Pro4.2.1 - Laporan Tiket.png)

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini Departemen TI sudah

bisa membuat laporan yang berisi jumlah permintaan yang ditutup dalam suatu

periode dan permintaan yang dibawa ke periode berikutnya. Kelemahannya

adalah, berdasarkan bukti lisan, saat ini Departemen TI tidak memiliki survei

kepuasan pelanggan dan tidak mencatat waktu lembur yang terjadi karena proses

pemeliharaan. Selain itu, ukuran penting berupa jumlah SDM per proses tidak

tertulis, karena penunjukannya lisan. Jadi dapat disimpulkan bahwa praktek ini

tercapai sebagian (Partially Achieved).


Praktek : Measurement baselines on the quality and performance of

processes, services, and products, are collected, stored,

reviewed, and used with the various stakeholders (customers,

users, sponsors, program manager, maintenance engineers, and

interface groups). They are used for improving the current

processes, services, and products.


Artifak : -


156


Berdasarkan bukti lisan, Departemen TI tidak memiliki acuan kinerja baik untuk

proses, layanan, dan produk. Jadi disimpulkan bahwa praktek ini tidak tercapai

(Not Achieved).


Praktek : The maintenance organization has set some performance and

quality objectives.


Artifak : KPI (Pro4.2.3 - IT Dept Head - Pasca Meeting 2.xlsx)

Berdasarkan bukti lisan dan artifak yang dihasilkan, Departemen TI sudah

memiliki target kinerja dalam bentuk KPI. Jadi disimpulkan bahwa praktek ini

tercapai sepenuhnya (Fully Achieved).

4.2.5 Maintenance Innovation and Deployment (Pro5)

Tujuan dari KPA ini adalah untuk mengidentifikasi dan menerapkan inovasi dan

perbaikan yang akan memiliki dampak yang dapat diukur dan signifikan terhadap

kinerja, kualitas, dan profitabilitas dari proses, layanan, atau teknologi

pemeliharaan perangkat lunak (perbaikan kecil tidak ditangani di sini). Kriteria

pemilihan diidentifikasi untuk dikaji terhadap proposal-proposal yang bersaing.

Manfaat yang diharapkan dianalisis dalam perbandingan dengan investasi yang

perlukan. Aktivitas-aktivitas perbaikan mendukung tujuan kinerja proses dan

kualitas yang diturunkan dari tujuan bisnis organisasi (April & Abran, 2008, hal.

91).




157



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Pro5.0.1

Apakah Departemen TI mengumpulkan informasi

untuk tujuan perbaikan proses? Dari siapa saja

informasi tersebut dikumpulkan? (pemangku

kepentingan, pengguna, pelanggan, grup antar muka

lainnya?)

Lampiran I (J59):

“Biasanya informal dulu kan. Kalau

mau perbaikan proses dari seluruh

company. Misalnya perbaikan proses

penerbitan polis. Itu turun ke kita,

gimana caranya beberapa modul

yang perlu diperbaiki, ...”

- No (100%)

Pro5.0.2 Apakah Departemen TI ada mengumpulkan proposal

inovasi proses? Apakah proposal tersebut dipelajari?

Lampiran I (J67):

“Tukar pikiran iya. Biasanya ada

arahan dari saya, ada teknologi baru,

tolong dilihat.”

- No (100%)

Pro5.0.3

Apakah Departemen TI mengkaji dampak dari suatu

inovasi atau perbaikan dari proses, layanan, dan

produk? Caranya bagaimana?

Lampiran I (J67):

“Biasanya ada arahan dari saya, ada

teknologi baru, tolong dilihat.

Bandingkan, secara teknologi make

sense nggak di kita? Baru panggil

vendor, jadikan proyek.”

- No (100%)

Pro5.1.1

Apakah Departemen TI mengevaluasi manfaat dari

proyek-proyek perbaikan dan inovasinya? Secara

formal atau tidak formal?


“Secara formal belum sih.”

Tidak ada artifak

pendukung.

Partially

Achieved

(33%)

Pro5.1.2

Apakah inisiatif perbaikan proses dari Departemen TI

atau secara individual? Apa target utama perbaikan?

Aspek teknis atau manajemen?


“Biasanya yang berkaitan dengan

problem sih, misalnya hardware

failure.”

Tidak ada artifak

pendukung.

Largely

Achieved

(68%)


158


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Pro5.1.3

Jika ada proses, teknologi baru, metodologi baru, dan

tools baru untuk pemeliharaan perangkat lunak, apakah

dikaji secara formal (misalnya masuk ke dalam daftar

kegiatan TI yang dinilai untuk kemajuan karier)?

Ataukah secara tidak formal?


“Belum saya tuangkan secara formal

... nggak dituangkan secara formal

untuk review, belum.”

Tidak ada artifak

pendukung.

Largely

Achieved

(68%)

Pro5.2.1

Apakah Departemen TI secara proaktif mencari atau

mengidentifikasi proses, layanan, teknologi,

metodologi, dan tools baru berdasarkan potensi

penggunaannya di pemeliharaan perangkat lunak?

Apakah ada personil yang ditugaskan untuk mencari

hal-hal tersebut?

Lampiran I (J67):

“Secara formal belum sih. Tukar

pikiran iya. Biasanya ada arahan dari

saya, ada teknologi baru, tolong

dilihat. Bandingkan, secara teknologi

make sense nggak di kita?”

Tidak ada

tinjauan formal.

Tidak ada artifak

pendukung.

Partially

Achieved

(33%)

Pro5.2.2

Apakah proses, layanan, teknologi, metodologi, dan

tools baru tersebut dinilai dan diperkenalkan/ditangani

sebagai suatu permintaan pemeliharaan noncritical?

(Misalnya dimasukkan ke dalam ticketing, jadi

kegiatannya juga terekam)

Lampiran I (J70):

“Belum ada untuk itu.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Pro5.2.3

Apakah ada peningkatan/perbaikan dari proses

pemeliharaan perangkat lunak, layanan, teknologi,

metodologi, dan tools yang sudah diterapkan secara

terkendali?

Lampiran I (J35):

“Bukan berarti sudah dijalankan,

baru kita mengarah ke sana, ...”

Praktek tidak

dilakukan.

Not

Achieved

(0%)


diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Maintenance Innovation and Deployment (Pro5).



159



Praktek : The software maintenance organization does not collect

information, for improvement purposes, from its stakeholders,

end users, customers, and other interface groups.


Artifak : -

Berdasarkan bukti lisan, pernyataan negatif praktek ini dipenuhi. Saat ini tidak ada

kegiatan pengumpulan informasi untuk tujuan perbaikan proses oleh Departemen

TI.


Praktek : The software maintenance organization does not study

improvement or innovation proposals.


Artifak : -


sudah ada inisiatif dari Kepala Departemen TI untuk mempelajari inovasi atau

perbaikan proses.


Praktek : The software maintenance organization does not assess the

impact of an innovation or improvement on the processes,

services, and products.


Artifak : -


inovasi atau perbaikan proses, layanan, dan produk, tidak dikaji dampaknya. Saat


160


ini pengkajian dilakukan dalam bentuk perbandingan manfaat, tapi tidak terhadap

dampak.


Praktek : The maintenance organization informally evaluates the benefits

of its improvement and innovation projects.


Artifak : -

Berdasarkan bukti lisan, saat ini sudah ada penugasan secara lisan kepada staf

Departemen TI untuk meninjau suatu teknologi atau metodologi. Kelemahan

praktek ini tidak ada bukti artifak yang mendukung pernyataan ini. Dokumen

perbandingan manfaat yang disebutkan dalam wawancara tidak berhasil

ditemukan. Jadi dapat disimpulkan bahwa praktek ini tercapai sebagian (Partially

Achieved).


Praktek : Individual initiatives for improvement and innovation target

mainly the technical aspects of software maintenance.


Artifak : -

Berdasarkan bukti lisan, saran perbaikan dari staf adalah untuk perbaikan

perangkat keras dan perangkat lunak, bukan untuk proses. Sedangkan inisiatif dari

Kepala Departemen TI tentang tinjauan teknologi baru, masih bersifat penunjukan

lisan dan tidak didukung bukti artifak. Jadi dapat disimpulkan bahwa praktek ini

dilakukan sebagian besar (Largely Achieved).


Praktek : Assessments of new processes, technologies, methodologies, and

tools for maintenance are performed informally.


161



Artifak : -

Berdasarkan bukti lisan, pengkajian terhadap metodologi, teknologi, dan tool

untuk pemeliharaan perangkat lunak dilakukan secara tidak formal. Kekurangan

praktek ini bersifat tidak formal. Kekurangan praktek ini adalah artifak berupa

dokumen hasil pengkajian tidak berhasil ditemukan. Jadi dapat disimpulkan

bahwa praktek ini dilakukan sebagian besar (Largely Achieved).


Praktek : New processes, services, technologies, methodologies, and tools

are identified and investigated for their potential use in software

maintenance.


Artifak : -

Berdasarkan bukti lisan, saat ini kegiatan untuk mengidentifikasi teknologi,

metodologi, dan tool sudah dilakukan. Kepala Departemen TI sendiri mengikuti

seminar-seminar untuk memperluas wawasan dan mengidentifikasi inovasi dan

perbaikan proses yang mungkin. Kekurangan praktek ini adalah tidak ada tinjauan

formal untuk inovasi dan perbaikan proses tersebut, dan tidak ada bukti artifak

pendukung. Jadi dapat disimpulkan bahwa praktek ini tercapai sebagian (Partially

Achieved).



are assessed and introduced at the request level.


Artifak : -


162


Berdasarkan bukti lisan, saat ini calon inovasi dan perbaikan proses belum

diperlakukan sebagai permintaan pemeliharaan tidak kritis (noncritical

maintenance request). Ini karena penugasan untuk meninjau calon inovasi dan

perbaikan proses baru bersifat lisan. Jadi disimpulkan bahwa praktek ini tidak




are assessed and introduced at the request level.


Artifak : -

Berdasarkan bukti lisan, salah satu inovasi atau perbaikan proses sudah

direncanakan, tapi belum dilaksanakan. Jadi disimpulkan bahwa praktek ini tidak


4.2.6 Event/Request Management (Req1)

Tujuan dari KPA ini adalah agar kegagalan, permasalahan, dan permintaan untuk

dukungan operasional dan evolusi perangkat lunak, secara proaktif diidentifikasi,

ditentukan prioritasnya, dibagikan, atau diproses dengan cara yang memenuhi

(atau melampaui) ketentuan SLA pelanggan (April & Abran, 2008, hal. 97).




163


Tabel 4.6 Ringkasan Penilaian Praktek-praktek Req1

Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Req1.0.1

Apakah Departemen TI ada menugaskan,

merekam, mengendalikan, mengukur, kejadian-

kejadian dan permintaan layanan?

Lampiran C (J3-J4):

“Ada.” -

No

(100%)

Req1.1.1 Kalau ya, apakah pengaturan tersebut secara

informal?

Lampiran C (J5):

“Iya, sekarang ini memang ada, di job

description masing-masing section itu sudah

disebutkan secara detail ...”

-

Fully

Achieved

(93%)

Req1.1.2

Apakah penanganan kejadian atau permintaan

dari pengguna berbeda-beda oleh tiap petugas?

Ataukah ada standarisasi alur penanganan?

Apakah penanganan tersebut tergantung

relasi/hubungan antara petugas dengan

pengguna? Apakah interaksi antara pengguna

dengan petugas berbeda-beda tergantung

hubungan mereka?

Lampiran C (J6):

“...sudah ada standarisasi untuk alur

penanganan suatu change request atau

permintaan perubahan, dan itu karena

framework-nya sudah standar, siapa pun yang

menjalankan itu, baik dia masuk ke level

section, atau ke level officer, dia akan

menerima bentuk layanan yang sama ...”

-

Fully

Achieved

(93%)

Req1.2.1

Apakah Departemen TI memiliki contact

person khusus untuk tiap tipe pengguna dan

sistem? Apakah terdokumentasi?

Lampiran C (J6-J8):

“Iya, di kita ada yang menjadi counterpart

yang kita sebutnya module owner. Jadi setiap

ada permintaan perubahan aplikasi oleh user,

bagian Business Analyst akan berkonsultasi,

akan berdiskusi dengan module owner

tersebut. Kita terbagi menjadi beberapa

kategori besar, di masing-masing sudah ada

PIC-nya, untuk underwriting dan claim,

PIC dari sisi

Departemen TI

tidak berupa

penugasan

resmi.

Largely

Achieved

(68%)


164


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

kemudian untuk finance, accounting, dan

untuk marketing.”

Req1.2.2

Apakah tiap permintaan atau insiden direkam

dalam suatu sistem (misalnya oleh help desk)?

Apakah setelah itu diterbitkan Support Request

(SR), Modification Request (MR), atau

Problem Report (PR)?

Lampiran C (J9):

“Proses recording yang kita gunakan ada dua

nih sebetulnya. Yang pertama yang kita kenal

sebagai sistem ticketing. Dan bug tracker.”

-

Fully

Achieved

(93%)

Req1.2.3

Apakah ada penyaringan atas permintaan yang

masuk, misalnya help desk menerima atau

penolak permintaan? Kalau diterima, apakah

diberikan kategori layanan, prioritas, dan

perkiraan ukuran dan lingkup kerja?

Lampiran C (J10-J12):

“Nah, nanti untuk keputusan ini kita biasanya

akan berkonsultasi dengan departemen

terkait, atau dengan Dept. Head IT, atau

dengan user-nya sendiri. Keputusannya ada di

mereka, jadi di Business Analyst tidak

menolak atau menerima permintaan, bukan di

situ. Tapi kita memberikan analisisnya

dilengkapi dengan plus minus-nya.”

Tidak ada

artifak

pendukung.

Largely

Achieved

(68%)

Req1.2.4 Apakah suatu MR ditentukan akan dirilis ke

versi perangkat lunak yang mana?

Lampiran C (J14):

“Untuk versi berapa perangkat lunak yang

akan dirilis, itu juga kita tidak ada statement

khusus kepada user kita.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)


diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Event/Request Management (Req1).

Tabel 4.6 Ringkasan Penilaian Praktek-praktek Req1 (sambungan)


165


4.2.6.1 Praktek Req1.0.1

Praktek : The software maintenance organization does not manage

(record, assign, control, and measure) the events and incoming

service requests.

Sumber Lisan : Lampiran C (J3-J4)

Artifak : Uraian tugas Business Analyst (Req1.0.1 - Business Analyst.pdf)


tidak dipenuhi. Pengelolaan requirement dilaksanakan oleh seksi Business Analyst

sebagai bagian dari uraian tugas mereka.


Praktek : Customer requests and system events, inside the software

maintenance organization, are managed informally.

Sumber Lisan : Lampiran C (J5)

Artifak : Uraian tugas Business Analyst (Req1.1.1 - Business Analyst.pdf)

Berdasarkan bukti lisan dan artifak yang dihasilkan, praktek pengelolaan

requirement dilakukan secara formal karena merupakan bagian dari uraian tugas

Business Analyst. Kekurangannya adalah tidak ada petunjuk pelaksanaan untuk

pengukuran dan pengendaliannya. Jadi dapat disimpulkan bahwa praktek ini

sudah dilaksanakan secara sepenuhnya (Fully Achieved).


Praktek : An individual approach for management of customer requests

and of system events exists. It is mainly based on the personal

relationship between the maintenance programmer and a

resource in the customer/user organization. Customers/users

interact differently based on the nature of this contract.



166


Artifak : Dokumen Alur Proses CR (Flow of Correspondence_change

request.pdf)

Berdasarkan bukti lisan dan yang dihasilkan, praktek pengelolaan requirement

tidak dilakukan berdasarkan relasi antara seorang Business Analyst dengan

pelanggan/pengguna. Jadi dapat disimpulkan bahwa praktek ini sudah

dilaksanakan secara sepenuhnya (Fully Achieved).


Praktek : Each customer/user and system has a documented contact point

that provides maintenance services.


Artifak : SK Penentuan Module Owner


requirement saat ini sudah memiliki orang yang bertanggung jawab (Person in

Charge, disingkat PIC), baik di sisi Departemen TI maupun di sisi

pelanggan/pengguna. PIC dari sisi pelanggan/pengguna disebut sebagai module

owner, yang memiliki wewenang untuk otorisasi permintaan modifikasi.

Pemberian peran module owner sudah diatur berdasarkan surat keputusan (SK)

yang ditandatangani oleh seorang Direktur. Kekurangan praktek ini adalah PIC

dari sisi Departemen TI tidak berupa penugasan resmi. Jadi dapat disimpulkan

bahwa praktek ini dilakukan sebagian besar (Largely Achieved).


Praktek : Each customer request and system incident is recorded by the

maintenance organization or its agent (i.e., the help desk) and

generates a support request (SR), a modification request (MR),

or a problem report (PR).


Artifak : Tiket (Req1.2.2 - Contoh Tiket.png)


167



requirement saat ini sudah melakukan pencatatan untuk setiap SR, MR, dan PR,

yang bisa direkam ke dalam sistem bug tracker dan sistem ticketing, baik oleh

user sendiri, maupun oleh help desk. Baik bug tracker maupun ticketing

digunakan sebagai pintu masuk SR, MR, dan PR, bedanya adalah bug tracker

digunakan untuk komunikasi internal, sedangkan ticketing langsung menangkap

keluhan dan permintaan dari pengguna. Keluaran dari bug tracker berupa nomor

bug, sedangkan keluaran dari ticketing adalah nomor tiket. Jadi dapat disimpulkan

bahwa praktek ini dilakukan sepenuhnya (Fully Achieved).


Praktek : Each customer request and event is first accepted or rejected,

and then, if accepted, is assigned a service category, a priority,

and a preliminary estimate of its size and scope.


Artifak : Tiket (Req1.2.3 - Contoh Tiket.png)

Berdasarkan bukti lisan yang dihasilkan, praktek penyaringan permintaan sudah

dilakukan. Penyaringan awal dilakukan oleh help desk, untuk menyaring

permintaan yang berakitan dengan TI perusahaan dan memberikan kategori

permintaan. Penyaringan berikutnya dilakukan oleh seksi Business Analyst, untuk

menentukan PIC di seksi tersebut. Seksi Business Analyst tidak berwenang untuk

memutuskan apakah suatu permintaan itu disetujui atau ditolak, hanya module

owner dan kepala Departemen TI yang memiliki wewenang tersebut. Seksi

Business Analyst akan berkonsultasi dengan module owner untuk mendapatkan

persetujuan tersebut, lalu berkonsultasi dengan System Analyst dan Software

Developer untuk mendapatkan perkiraan ukuran dan lingkup kerja. Kekurangan

praktek ini adalah tidak didukung dengan bukti artifak. Jadi dapat disimpulkan

bahwa praktek ini tercapai sebagian besar (Largely Achieved).


168



Praktek : The accepted modification requests are assigned, in a

preliminary way, to a future version of the software.


Artifak : -

Berdasarkan bukti lisan yang dihasilkan, Departemen TI tidak memberikan

perkiraan kepada pengguna tentang MR akan masuk ke perangkat lunak versi

yang mana. Jadi dapat disimpulkan bahwa praktek ini tidak dilaksanakan (Not

Achieved).

4.2.7 Maintenance Planning (Req2)

Tujuan dari KPA ini adalah untuk memastikan pembuatan dan penjagaan kekinian

dari rencana-rencana yang menggambarkan aktivitas-aktivitas pemeliharaan

perangkat lunak saat ini dan di masa depan (April & Abran, 2008, hal. 98).

(atau melampaui) ketentuan SLA pelanggan (April & Abran, 2008, hal. 97).




169



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Req2.0.1

Apakah Departemen TI melakukan perencanaan

(misalnya tahunan) yang berkaitan dengan

pemeliharaan (misalnya penyempurnaan atau juga

preventif)?

Lampiran G (J18):

“Yang ter-schedule sih, Pak

RK space-nya cuma project

plan ...”

- No

(100%)

Req2.1.1

Jika ya, apakah perencanaan tersebut secara informal?

(Tidak terstruktur, bersifat reaktif, predelivery and

transition baru dilakukan saat-saat terakhir,

perencanaan dibuat sporadis dan tidak konsisten.

Perencanaan ada, tapi hanya sedikit yang dilaksanakan)

Lampiran G (J18):



plan ...”

-

Fully

Achieved

(93%)

Req2.1.2

Apakah perencanaan baru di tingkat individual (bukan

tingkat departemen)? Misalnya personil

memberitahukan secara verbal terhadap pengguna

tentang kemungkinan pemrosesan permintaan ad-hoc.

Lampiran G (J18):



plan ...”

-

Fully

Achieved

(93%)

Req2.1.3

Apakah pemrosesan permintaan pelanggan dan project

predelivery and transition dilakukan secara reaktif,

bukan secara terencana?

Lampiran G (J18):



plan, biasanya nggak di-

state jelas-jelas bahwa ini

harus begini, itu belum. Itu

jadi kayak task sampingan.”

-

Fully

Achieved

(93%)

Req2.2.1

Apakah Departemen TI ada membuat rencana

pemeliharaan (misalnya 1 sampai 3 tahun)? Apakah di

dalam rencana tersebut ada objek pemeliharaan, skop,

tujuan dan sasaran, dan deliverable, dll.?

Lampiran G (J18):



plan ...”

Tidak menggambarkan

objek pemeliharaan,

lingkup pengerjaan, dan

tujuan pemeliharaan.

Partially

Achieved

(33%)


170


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Req2.2.2

Apakah ada jadwal reguler untuk memperbaharui

rencana pemeliharaan tersebut? Apakah ada prosedur

terdokumentasi untuk perbaharuan tersebut?

Lampiran G (J21-J22):

“...ada sih, di-update.

Memang sudah kita plan,

nanti kita launch, karena

terkait dengan third party

juga, cuma waktunya kapan

belum ditentukan.”

“Belum ada sih.”

Tidak dilakukan secara

berkala.

Largely

Achieved

(68%)

Req2.2.3

Apakah kegiatan perencanaan pemeliharaan mengikuti

standar perencanaan organisasi? Apakah terkoordinasi

dengan pengembang (developers) dan operasi

(operations)?


“Nggak.” Praktek tidak dilakukan.

Not

Achieved

(0%)

Req2.2.4

Apakah kegiatan perencanaan pemeliharaan ada

mempertimbangkan peremajaan portofolio perangkat

lunak? Apakah ada studi kasus yang menjelaskan

kegiatan peremajaan seperti apa yang bisa

menguntungkan perusahaan? Apakah studi kasus

tersebut dipresentasikan kepada pemangku kepentingan

untuk mendapatkan persetujuan mereka?

Lampiran G (J24):

“Itu pun tanpa

perencanaan.”

Praktek tidak dilakukan.

Not

Achieved

(0%)

Req2.2.5

Apakah rencana pemeliharaan mempertimbangkan

kebutuhan sumber daya (seperti personil, infrastruktur,

dan tools)?


“Nggak.” Praktek tidak dilakukan.

Not

Achieved

(0%)

Req2.2.6 Apakah kegiatan predelivery and transition sudah

direncanakan dari tahap awal proyek SI/TI?

Lampiran G (J19):

“Kita mau rilis nih, itu yang Praktek tidak dilakukan.

Not

Achieved



171


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

belum ...” (0%)

Req2.2.7

Apakah para maintainer sudah ikut serta dalam

perencanaan awal untuk predelivery and transition

bersama dengan developer? Apakah unit-unit yang

berkepentingan sudah diundang dalam rapat predelivery

and transition?

Lampiran G (J35):

“Belum.” Praktek tidak dilakukan.

Not

Achieved

(0%)

Req2.2.8

Apakah rencana transisi dibuat bersamaan dengan

rencana pengembangan lainnya? Apakah standar untuk

rencana transisi sama dengan standar untuk

pengembangan lainnya? Apakah rencana transisi sudah

diturunkan dari rencana pengembangan? Apakah

rencana transisi, jika ada perubahan, dijaga agar tetap

relevan dibandingkan dengan rencana pengembangan?

Lampiran G (J38):

“Belum ada.” Praktek tidak dilakukan.

Not

Achieved

(0%)

Req2.2.9

Apakah rencana predelivery and transition jelas

hubungannya dengan rencana-rencana tahunan, transisi,

atau penanganan permintaan?

1. Hubungannya dengan rencana infrastruktur dan tools

untuk mendukung perangkat lunak baru?

2. Hubungannya dengan rencana pelatihan dari HR?

3. Hubungannya dengan rencana configuration

management, rencana kualitas, rencana pengujian?

Lampiran G (J39):

“Sudah, kalau itu sudah.

Formalnya sih nggak ada,

email doang. Hanya dalam

bentuk tanya jawab lewat

email.”

Tidak ada tinjauan

formal terhadap rencana

pengembangan

infrastruktur. Tidak ada

artifak pendukung.

Partially

Achieved

(33%)

Req2.2.10

Apakah rencana predelivery and transition sudah

merinci kegiatan pengujian, dukungan, teknik dan tools

yang akan digunakan?

Lampiran G (J48):

“Belum ada.” Praktek tidak dilakukan.

Not

Achieved

(0%)



172


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Req2.2.11

Apakah dalam rencana predelivery and transition sudah

ada risk assessment yang berkaitan dengan aspek

teknis, biaya, SDM , dan jadwal transisi?


“...nggak di-state dalam satu

dokumen.”

“...bentuknya, ngobrol-

ngobrol.”


Not

Achieved

(0%)

Req2.2.12

Apakah masing-masing SI sudah diidentifikasi

kebutuhan layanan disaster recovery-nya? Apakah

maintainer sudah mengidentifikasi,

mendokumentasikan, dan menginformasikan perannya

dalam: pengujian, frekuensi pengujian, dan batas

tanggung jawabnya?


“Dari server juga nggak ada

sih.”

“Kalau jeblok pasti nggak

bisa ngapa-ngapain.”

“Nggak ada.”


Not

Achieved

(0%)

Req2.2.13

Apakah Departemen TI sudah membuat salinan dari

data, program, script, dokumentasi kritis, dan

menyimpan salinannya di luar Departemen TI? Apakah

dilakukan secara reguler?

Lampiran G (J51, J56):

“Kalau Sistem Informasi

Asuransi Umum itu, sampai

saat ini saya tidak tahu

posisi DRC-nya itu.”

“Belum.”

Tidak diketahui apakah

program, skrip, dan

dokumentasi kritis juga

ikut disalin dan di

gudang arsip.

Partially

Achieved

(33%)

Req2.2.14

Apakah layanan pemulihan bencana (disaster recovery)

merupakan bagian dari layanan Departemen TI? Kalau

ya, apakah rencana pemulihan bencana sudah diuji dan

diulas kesesuaiannya terhadap SLA?

Lampiran G (J51-52):

“Kalau Sistem Informasi

Asuransi Umum itu, sampai

saat ini saya tidak tahu

posisi DRC-nya itu.”

“Belum rutin.”


Not

Achieved

(0%)

Req2.2.15 Apakah perbaikan terhadap kesalahan langsung Lampiran G (J24): Praktek tidak dilakukan. Not



173


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

dilaksanakan? Untuk MR, apakah maintainer memberi

tahu pengguna terlebih dahulu sebelum

mengimplementasikannya?

“Itu pun tanpa

perencanaan.”

Achieved

(0%)

Req2.2.16

Apakah ada orang yang bertugas:

1. Sebagai contract person dengan pengguna?

2. Memberikan masukan pada prioritas pengerjaan

berdasarkan:

2.a. perubahan infrastruktur dan operasi/prosedur?

2.b. Proyek-proyek dalam pengembangan atau transisi?

2.c. Siklus produksi tahunan?

2.d. Kesalahan/kegagalan sistem saat ini?

2.e. Kesepakan kontraktual dengan mitra atau

pemasok?

2.f. Masukan dari manajer Departemen TI?

3. Melakukan analisis dampak (impact analysis) dan

verifikasi hasil analisis tersebut dengan para

programmer?

4. Memastikan SDM pemeliharaan paham tentang

prioritas yang sudah diatur tersebut?

5. Memastikan SDM pemeliharaan bekerja berdasarkan

prioritas yang sudah diatur tersebut?

6. Memastikan proses-proses pemeliharaan diikuti?


“Iya, help desk.”

“Nggak bisa.”

“Belum ada prosedurnya.”

“Nggak ada.”


Not

Achieved

(0%)

Req2.2.17 Apakah daftar kegiatan dalam rencana pemeliharaan

digunakan untuk melacak status dari tiap permintaan


“Yang sudah karena -

Fully

Achieved



174


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

pengguna, dan untuk menginformasikan beban kerja? ditagih.” (100%)

Req2.2.18

Apakah daftar kegiatan tersebut didiskusikan dengan

para pengguna? Apakah persetujuan mereka untuk

daftar tersebut didaftarkan? Apakah ada prosedur

terdokumentasi untuk kegiatan ini? Apakah

mempertimbangkan aspek finansial? (misalnya

menggunakan cost benefit analysis)

Lampiran G (J64, J69-J71):

“Belum ada prosedurnya.”

“Prosedur tertulis sih nggak

ada.”


Not

Achieved

(0%)

Req2.2.19

Jika ada PR (Problem Report) yang penyelesaiannya

akan mempengaruhi banyak pengguna, apakah

persetujuan mereka untuk penyelesaian tersebut

didapatkan? Ada prosedur terdokumentasi? Atau

maintainer langsung melakukan perbaikan, dan hanya

melakukan sosialisasi setelah selesai?


“Wah, itu saya kurang

tahu.”


Not

Achieved

(0%)

Req2.2.20

Apakah Departemen TI memiliki rencana kapasitas

permintaan (request capacity plan)? Apakah rencana

tersebut mempertimbangkan rencana pemeliharaan

(yang 1 sampai 3 tahun) dan semua SLA?

Lampiran G (J74):

“...apa on-track atau tidak

itu lain lagi”


Not

Achieved

(0%)


diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Maintenance Planning (Req2).



175



Praktek : The maintenance organization does not conduct planning

activities and does not produce and publish plans.

Sumber Lisan : Lampiran G (J18)

Artifak : -

Berdasarkan bukti lisan dan artifak yang dihasilkan, pernyataan negatif dari

praktek ini tidak tercapai. Saat ini sudah ada aktivitas perencanaan, dan rencana-

rencana tersebut sudah dipublikasikan.


Praktek : Planning in the organization for software maintenance is



Artifak : Rencana Pemeliharaan

Berdasarkan bukti lisan dan artifak yang dihasilkan, perencanaan pemeliharaan

perangkat lunak bukan hanya dilakukan secara informal, melainkan secara formal.

Jadi dapat disimpulkan bahwa praktek ini tercapai sepenuhnya (Fully Achieved).


Praktek : Individual initiatives for planning are mainly aimed at

informing customers, verbally, of the possibility of processing a

specific and ad-hoc request.



Berdasarkan bukti lisan dan artifak yang dihasilkan, perencanaan pemeliharaan

perangkat lunak bukan hanya dilakukan secara inisiatif individu dan bukan hanya


176


bersifat lisan. Rencana pemeliharaan perangkat lunak dipublikasikan. Jadi dapat

disimpulkan bahwa praktek ini tercapai sepenuhnya (Fully Achieved).


Praktek : Customer requests and project predelivery and transition are

processed in a reactive way, as opposed to a planned way.



Berdasarkan bukti lisan dan artifak yang dihasilkan, sudah ada permintaan

pengguna dan kegiatan predelivery and transition yang diproses secara terencana,

bukan reaktif. Jadi dapat disimpulkan bahwa praktek ini tercapai sepenuhnya

(Fully Achieved).


Praktek : There is a planning policy at the organizational level. Software

maintenance publishes a maintenance plan for a 1-to 3-year

view. This plans includes the objects, scope, goals, objectives,

and deliverables, and some others which are important software

maintenance planning subjects concerning services, processes,

resources, and products.



Berdasarkan bukti lisan dan artifak yang dihasilkan, sudah ada rencana

pemeliharaan tahunan yang dipublikasikan. Kekurangan praktek ini adalah

rencana tersebut tidak menggambarkan objek pemeliharaan, lingkup pengerjaan,

dan tujuan pemeliharaan. Jadi dapat disimpulkan bahwa praktek ini tercapai

sebagian (Partially Achieved).


177



Praktek : The maintenance plan (1 to 3 years) is elaborated and updated

yearly, according to a documented procedure.

Sumber Lisan : Lampiran G (J21-J22)


Berdasarkan bukti lisan dan artifak yang dihasilkan, kegiatan rencana

pemeliharaan sudah dilakukan. Kekurangan praktek ini adalah kegiatan tersebut

tidak dilakukan secara berkala. Jadi dapat disimpulkan bahwa praktek ini tercapai

sebagian besar (Largely Achieved).


Praktek : The maintenance planning activities follow the standards of the

organization and are coordinated/aligned with its key support

interfaces (i.e., developers and operations).


Artifak : -

Narasumber ragu untuk menjawab pertanyaan ini. Mempertimbangkan jabatan

narasumber sebagai Kepala Seksi Application Development, dapat disimpulkan



Praktek : Maintenance planning (1 to 3 years) considers the possibilities

of rejuvenation of the software portfolio.


Artifak : -


178


Berdasarkan bukti lisan, saat ini kegiatan peremajaan perangkat lunak yang

dilakukan tidak terencana, melainkan reaktif. Jadi dapat disimpulkan bahwa



Praktek : The maintenance plan (1 to 3 years) considers the resources

needs (personnel, infrastructure, and tools).


Artifak : -

Narasumber ragu untuk menjawab pertanyaan ini. Mempertimbangkan jabatan

narasumber sebagai Kepala Seksi Application Development, dapat disimpulkan



Praktek : Pre-delivery and transition planning are included and initiated

during the early stages of an IS/IT project.


Artifak : -

Berdasarkan bukti lisan, praktek ini tidak dilakukan dengan alasan di seksi

Application Development personilnya terbatas, di mana pengembang (developer)

dan pemelihara (maintainer) sering kali orangnya sama. Justifikasi narasumber

adalah karena orangnya sama, maka tidak perlu dokumen. Kelemahan dari

justifikasi ini adalah jika ada keperluan menggunakan maintainer yang bukan

developer dari aplikasi, maka akan mengganggu transisi. Jadi dapat disimpulkan



Praktek : Every software project stakeholder is aware of the need to plan

pre-delivery and transition activities.


179



Artifak : -

Berdasarkan bukti lisan, narasumber lebih memperhatikan peran seksi IT Support

dalam perencanaan predelivery and transition, dan tidak membahas tentang

pemangku kepentingan dari sisi bisnis. Jadi dapat disimpulkan bahwa praktek ini



Praktek : The predelivery and transition activities are part of the

developer's main project schedule.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada rencana untuk kegiatan predelivery

and transition yang diturunkan dari rencana proyek. Jadi disimpulkan bahwa



Praktek : The predelivery and transition plan describes the relationship

with the other development and infrastructure deployment plans.


Artifak : -

Berdasarkan bukti lisan, saat ini koordinasi dengan tim infrastruktur dilaksanakan

melalui tanya jawab lewat email. Kelemahan dari praktek ini adalah tidak ada

tinjauan formal terhadap rencana pengembangan infrastruktur, dan bukti artifak

korespondensi tersebut tidak dapat ditemukan. Jadi dapat disimpulkan bahwa

praktek ini tercapai sebagian (Partially Achieved).


180


4.2.7.14 Praktek Req2.2.10

Praktek : Maintenance test and support activities, techniques and tools

needed for the new software are defined in the predelivery and

transition plans.


Artifak : -

Berdasarkan bukti lisan, saat ini perencanaan untuk kegiatan predelivery and

transition belum ada rincian untuk pengujian, dukungan, teknik, dan tool yang

akan digunakan. Jadi disimpulkan bahwa praktek ini tidak tercapai (Not

Achieved).

4.2.7.15 Praktek Req2.2.11

Praktek : The predelivery and transition plan assesses, documents, and

approves the risks linked to technical aspects, the costs

(hardware, software, and licenses), human resources

requirements and final transition schedule.


Artifak : -

Berdasarkan bukti lisan, saat ini penilaian risiko predelivery and transition dari

aspek teknis, biaya, dan SDM, baru dilakukan dalam bentuk dialog lisan.

Kekurangan praktek ini adalah hasil diskusi tidak tertuang dalam bentuk tertulis,

sehingga tidak ada bukti artifak. Karena potensi para pemangku kepentingan tidak

mengetahui atau tidak ingat risiko-risiko tersebut, maka disimpulkan bahwa


4.2.7.16 Praktek Req2.2.12

Praktek : Every maintained software product identifies whether or not a

disaster recovery service is offered. The maintainer has

identified, documented, and communicated its testing role


181


(application recovery vs. platform recovery), testing frequency,

and the limits to his responsibilities.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada identifikasi terhadap keperluan

layanan pemulihan terhadap bencana, baik identifikasi, dokumentasi, dan

komunikasi peran dan tanggung jawab. Jadi disimpulkan bahwa praktek ini tidak


4.2.7.17 Praktek Req2.2.13

Praktek : The data, programs, scripts, and critical documentation are

copied and stored outside the maintenance site, and this is done

on a regular basis.

Sumber Lisan : Lampiran G (J51, J56)

Artifak : -

Berdasarkan bukti lisan, saat sudah ada salinan data yang disimpan di gudang

arsip di luar PT XYZ. Narasumber tidak mengetahui apakah program, skrip, dan

dokumentasi kritis juga ikut disalin dan di gudang arsip tersebut.

Mempertimbangkan posisi narasumber sebagai Kepala Seksi Application

Development, maka dapat disimpulkan bahwa program, skrip, dan dokumentasi

kritis tersebut tidak ikut disalin dan disimpan di gudang arsip. Jadi dapat


4.2.7.18 Praktek Req2.2.14

Praktek : A disaster recovery service may be offered. When offered, the

detailed disaster recovery plan is tested (including the business

recovery and data center recovery, if available) and reviewed as

per the terms indicated in the agreements.

Sumber Lisan : Lampiran G (J51-52)


182


Artifak : -

Berdasarkan bukti lisan, narasumber tidak mengetahui posisi DRC dan

berpendapat bahwa pengujian DRP tidak rutin. Mempertimbangkan jabatan

narasumber sebagai Kepala Seksi Application Development, disimpulkan bahwa


4.2.7.19 Praktek Req2.2.15

Praktek : The software versions and upgrades are produced, by the

maintainer, as soon as possible.


Artifak : -

Berdasarkan bukti lisan, upgrade versi perangkat lunak tidak terencana dan tidak

berkala. Jadi disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).

4.2.7.20 Praktek Req2.2.16

Praktek : The maintenance manager dynamically assigns the request

workload.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada prosedur untuk penugasan permintaan

yang berdasarkan prioritas, yang berarti pertimbangan penugasan seperti:

memastikan personil pemeliharaan paham tentang prioritas pengerjaan dan

bekerja sesuai dengan urut prioritas juga tidak dilakukan. Jadi dapat disimpulkan


4.2.7.21 Praktek Req2.2.17

Praktek : The operational maintenance plan is used to track the status of

each customer request and to communicate the status of the

work load.


183




Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini rencana pemeliharaan

sudah digunakan untuk melacak (track) status dari permintaan-permintaan

pengguna dan untuk mengomunikasikan beban kerja. Jadi disimpulkan bahwa

praktek ini tercapai sepenuhnya (Fully Achieved).

4.2.7.22 Praktek Req2.2.18

Praktek : The customer request priority is assigned in close collaboration

with the end user, according to a documented procedure.

Sumber Lisan : Lampiran G (J64, J69-J71)

Artifak : -

Berdasarkan bukti lisan, saat ini belum ada prosedur untuk kolaborasi dengan

pengguna untuk menentukan prioritas permintaan pengguna. Jadi disimpulkan


4.2.7.23 Praktek Req2.2.19

Praktek : PRs are rerouted to the appropriate support group only when

the current holder has documented its intervention. Intergroup

relationships and processes are documented and negotiated.


Artifak : -

Berdasarkan bukti lisan, narasumber tidak mengetahui pelaksanaan praktek ini.

Mempertimbangkan jabatan narasumber sebagai Kepala Seksi Application

Development, dapat disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).


184


4.2.7.24 Praktek Req2.2.20

Praktek : A support and modification request capacity plan is created.

The plan takes into account the maintenance plan (1 to 3 years)

and the individual SLAs.


Artifak : -


Mempertimbangkan jabatan narasumber sebagai Kepala Seksi Application

Development, dapat disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).

4.2.8 Request/Software Monitoring and Control (Req3)

Tujuan dari KPA ini adalah untuk memastikan bahwa target SLA tercapai.

Pemelihara perangkat lunak harus memantau kesenjangan dalam tingkat layanan

secara proaktif, membuat penyesuaian yang diperlukan, dan meninjau atau

membuat kesepakatan baru untuk penyampaian tingkat layanan saat dibutuhkan

(April & Abran, 2008, hal. 100).




185



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Req3.0.1 Apakah Departemen TI melacak atau memantau

komitmen layanan atau produknya?

Lampiran J (J1):

“Iya” -

No

(100%)

Req3.1.1

Kalau ya, apakah secara informal? (Misalnya masing-

masing maintainer melakukan pemantauan sendiri-

sendiri, tanpa kendali dari manajemen)

Lampiran J (J2) :

“Secara formal dilakukan, setiap

aplikasi (berikut perubahannya)

selalu dilengkapi dengan guidance

user bahkan training untuk

menjalankannya ...”

Tidak ada artifak

pendukung.

Largely

Achieved

(68%)

Req3.2.1

Apakah para maintainer diberikan tanggung jawab

memantau perangkat lunak produksi? Apakah ada

jadwal dukungan di luar jam kerja yang sudah disetujui

manajemen? Apakah ada prosedur terdokumentasi

untuk dukungan antar grup (pengguna, infrastruktur,

pengembang, pemasok, dan help desk)?

Lampiran J (J3):

“Diberikan tanggung jawab iya ...”

“Tidak ada jadwal dukungan di

luar jam kerja normal.”

“Tidak ada prosedur yang

terdokumentasi untuk dukungan

antar group tersebut.”

Tidak ada artifak

pendukung. Tidak

ada pendekatan

terstruktur untuk

kendali.

Partially

Achieved

(33%)

Req3.2.2

Apakah ada sesi ulasan (review) dengan pengguna

untuk urusan pemeliharaan secara berkala? Apakah

komitmen pengguna untuk urusan pemeliharaan

dipastikan oleh manajer? Apakah perubahan komitmen

pengguna dilacak (tracked)?

Lampiran J (J4):

“Review secara berkala memang

tidak dilakukan, namun review

pasca perubahan aplikasi sering

kali dilakukan, terutama jika masih

ada gap antara kebutuhan user

dengan aplikasi yang di-deliver.”

Tinjauan belum

dilakukan secara

berkala.

Largely

Achieved

(68%)

Req3.2.3 Apakah ada rapat berkala (misalnya mingguan) untuk

mengulas hasil pemantauan tingkat layanan (SLA)?

Lampiran J (J5):

“Tidak ada meeting berkala

Praktek tidak

dilakukan.

Not

Achieved


186


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Misalnya untuk mendiskusikan nilai availability,

panggilan telepon di luar jam kerja, dan untuk

permintaan yang lagi dalam proses dan yang lagi

menunggu? Apakah ada diskusi /antisipasi tentang

kasus-kasus yang tidak akan memenuhi SLA? Apakah

hasil rapat didokumentasikan?

khususnya dalam hal SLA.” (0%)

Req3.2.4

Apakah komitmen pemeliharaan eksternal dan internal

diatur, dan diulas secara periodik dengan manajemen

pemeliharaan? Apakah jika diminta, Departemen TI

bisa menunjukkan saat itu juga status kerja

pemeliharaan yang dalam proses untuk semua layanan,

permintaan pengguna, predelivery and transition,

upgrade, pemulihan bencana, dst., dan bisa

dibandingkan dengan rencana dan komitmen? Apakah

saat diskusi, statusnya sangat berbeda antara manajer,

maintainer, dan pengguna?

Lampiran J (J6) :

“Jika diperlukan, Departemen TI

bisa menunjukkan schedule

internal saja, kecuali jika suatu

proses pemeliharaan termasuk

penjadwalannya dilakukan

bersama-sama dengan pihak

eksternal.”

-

Fully

Achieved

(93%)

Req3.2.5

Apakah rencana transisi (termasuk jadwalnya) dilacak

perubahannya, dan dilakukan tindakan korektif

(corrective actions) jika diperlukan?

1. Apakah maintainer memiliki salinan jadwal


2. Apakah maintainer meninjau progres aktivitas

mingguan/bulanannya?

3. Apakah maintainer berpartisipasi dalam rapat

Lampiran J (J7-J12):

“Iya.”

“Setiap proyek yang di-handle ke

depannya harus dilengkapi dengan

project plan.”

“Iya.”

“Iya.”

“Sering kali dilakukan.”

Tidak ada artifak

pendukung.

Largely

Achieved

(68%)



187


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

bulanan untuk menginformasikan kemajuan prosesnya

(telat, on track, on early)?

4. Apakah maintainer negosiasi rencana tindakan (yang

disepakati bersama) untuk tindakan perbaikan masalah?

5. Apakah maintainer meminta informasi tentang

perbaikan/perubahan terakhir terhadap kegiatan


“Selalu dilakukan demikian.”

Req3.2.6

Jika ada perubahan komitmen, apakah maintainer

memastikan kesepakatan semua pemangku

kepentingan?

Lampiran J (J13):

“Iya.”

Tidak ada artifak

pendukung.

Largely

Achieved

(68%)


diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Request/Software Monitoring and Control (Req3).



188



Praktek : The software maintenance organization does not track or

monitor its service/product commitments.

Sumber Lisan : Lampiran J (J1)

Artifak : -

Berdasarkan bukti tulisan, pernyataan negatif praktek ini tidak dipenuhi. Saat ini

pelacakan atau pemantauan komitmen layanan atau produk sudah dilakukan.


Praktek : The software maintenance service/product tracking and

monitoring is carried out informally.


Artifak : -

Berdasarkan bukti tulisan, praktek ini sudah dilaksanakan secara formal.

Perubahan aplikasi dipantau dan dilengkapi dengan panduan kepada pengguna

dan pelatihan terhadap yang menjalankannya. Kekurangan praktek ini adalah

tidak didukung bukti artifak. Jadi dapat disimpulkan bahwa praktek ini tercapai



Praktek : The maintenance engineer ensures that the software is

monitored and that the activities for solving technical problems

of production software are coordinated.


Artifak : -

Berdasarkan bukti tulisan, sudah ada pemantauan terhadap perangkat lunak

produksi. Untuk perubahan perangkat lunak, tim Business Analyst melakukan


189


pemantauan terhadap layanan, lalu ada transisi ke tim Help Desk. Kekurangan

praktek ini adalah tidak ada bukti artifak yang ditemukan dan tidak adanya

pendekatan terstruktur untuk kendali, seperti: jadwal dukungan, proses dukungan

antar grup (customer dan user, help desk, operations, developer, supplier, dan

maintainer sendiri), kebijakan pelaporan penggunaan waktu, dan proses eskalasi.

Jadi dapat disimpulkan bahwa praktek ini tercapai sebagian (Partially Achieved).


Praktek : The commitments of various stakeholders, as agreed upon in the

maintenance plans, are tracked on a periodic basis.


Artifak : -

Berdasarkan bukti tulisan, tidak ada peninjauan (review) secara berkala untuk

komitmen pemangku kepentingan. Tinjauan yang sudah dilakukan adalah pasca

perubahan perangkat lunak oleh Business Analyst untuk melihat kesenjangan

kebutuhan pengguna dengan aplikasi yang disampaikan. Saat ini perubahan

komitmen pengguna dilacak melalui email, bug tracker, dan ticketing. Jadi dapat

disimpulkan bahwa praktek ini tercapai sebagian besar (Largely Achieved).


Praktek : A review of each production software service level, monitored

by maintenance engineers, is presented at the weekly

maintenance management meeting.


Artifak : -

Berdasarkan bukti tulisan, tidak ada rapat untuk peninjauan secara berkala tentang

pencapaian SLA. Jadi disimpulkan bahwa praktek tidak tercapai (Not Achieved).


190



Praktek : External and internal maintenance commitments are managed

and reviewed periodically with software maintenance

management.


Artifak : Laporan Tiket (Req3.2.4 - Laporan Tiket.png)

Berdasarkan bukti tulisan dan artifak yang dihasilkan, status pekerjaan

maintenance untuk semua layanan bisa dihasilkan, sehingga pencapaian

komitmen dapat ditinjau oleh manajemen jika diminta. Jadi dapat disimpulkan

bahwa praktek ini tercapai sepenuhnya (Fully Achieved).


Praktek : The transition plan, including its schedule, is subject to tracking

and corrective actions, which are performed if needed.

Sumber Lisan : Lampiran J (J7-J12)


Berdasarkan bukti tulisan, saat ini rencana transisi termasuk jadwalnya sudah

dilacak perubahannya, dan dilakukan tindakan korektif jika diperlukan. Business

Analyst melakukan peninjauan progres aktivitas secara mingguan atau bulanan,

dan berpartisipasi dalam rapat untuk komunikasi kemajuan progres ini. Sering kali

terjadi negosiasi rencana tindakan untuk tindakan korektif jika progres tidak

sesuai rencana. Jadi dapat disimpulkan bahwa praktek ini tercapai sebagian besar

(Largely Achieved).


Praktek : The maintenance commitments are tracked and renegotiated, if

needed.



191


Artifak : -

Berdasarkan bukti tulisan, saat ini Business Analyst memastikan kesepakatan

pemangku kepentingan jika ada perubahan komitmen. Kekurangan praktek ini

adalah tidak ada bukti artifak yang mendukung. Jadi dapat disimpulkan bahwa

praktek ini tercapai sebagian besar (Largely Achieved).

4.2.9 SLA and Supplier Agreements Management (Req4)

Ada dua tujuan utama dari KPA ini. Yang pertama adalah tentang manajemen

rekening pelanggan, yang dipenuhi dengan membuat dan melacak tingkat layanan

secara formal. Kesepakatan menggambarkan ketentuan layanan dan membuat

resmi (a) jumlah layanan pemeliharaan yang perlu disampaikan, (b) biaya tiap

layanan, (c) kualitas dan efisiensi dari produk dan layanan, dan (d) pembuatan

ukuran standar untuk pengukuran kinerja dari masing-masing kontrak dan laporan

untuk pelanggan. Tujuan kedua adalah untuk pembuatan kontrak-kontrak individu

dengan pemasuk untuk mendefinisikan komitmen timbal balik yang dihubungkan

dengan LSA. Prosedur-prosedur untuk eksekusi dan melacak SLA dan kinerja

kontrak dengan pemasok juga diperlukan (April & Abran, 2008, hal. 101-102).




192



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Req4.0.1

Apakah ada yang bertugas untuk menentukan

dan memantau tingkat layanan (SLA)? Apakah

ada prosedur untuk membuat kontrak dan SLA

dengan pemasok dan pengguna/pelanggan?

Apakah ada ukuran kepuasan terhadap pemasok

atau terhadap layanan pemeliharaan Departemen

TI? Apakah ada survei kepuasan? Dengan apa

manajemen mengamati indikator kualitas

layanan?

Lampiran H (J2):

“. Saat ini untuk pemantauan itu

dilakukan secara manual …”

- No

(100%)

Req4.1.1

Apakah ada template untuk kontrak dengan

pengguna / klien, subkontraktor, outsourcer, dll.?

Bagaimana cara mengukur kepuasan

(kualitatif/kuantitatif)? Apakah tugas memantau

dan mengendalikan permintaan/perangkat lunak

bersifat informal? Apakah ada laporan kinerja

personil atau untuk keseluruhan Departemen TI?

Untuk apa laporan tersebut digunakan? Apakah

digunakan untuk pengambilan keputusan?

Apakah Departemen TI menegosiasikan

kesepakatan dengan pemasok (jadi bukan hanya

menerima)? Apakah jika Departemen TI tidak

sepakat dengan pemasok, maka negosiasi atau

langsung ganti pemasok?

Lampiran H (J2, J10):

“...tapi kalau andai kata template kontrak

dengan third party, itu ada.”

-

Fully

Achieved

(93%)

Req4.2.1 Apakah Departemen TI ada mengadakan Lampiran H (J18): Tidak ada artifak Largely


193


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

pengenalan apa itu kontrak/SLA formal? Apakah

ada ditunjukkan manfaat dari kontrak/SLA

formal?

“Tentu. Kalau kita ngomong SLA sebuah

software, kita harus ngomong ke anak

buah.”

pendukung. Achieved

(68%)

Req4.2.2

Apakah ada maintainer yang ditugaskan sebagai

account manager? Apakah pekerjaan tersebut

bersifat penuh waktu, ataukah persentase dari

pekerjaan?

Lampiran H (J19):

“Jadi sampai dengan saat ini kalau saya

melihat, itu hanya terjadinya itu hanya

apabila kita sudah mempunyai

segmentasi. Kalau belum mempunyai

segmentasi seperti saat ini, berarti

contact person-nya adalah saya. Apabila

tidak ada saya, berarti ke bawah.”

Belum ada yang

bertugas sebagai

account manager.

Tidak ada artifak

pendukung.

Partially

Achieved

(33%)

Req4.2.3

Apakah para pemangku kepentingan (pengguna,

pelanggan, maintainer, pengembang, operasi,

dan pemasok) setuju akan kebutuhan penggunaan

SLA dan kontrak formal dalam pemeliharaan

perangkat lunak? Sudah adakah kesepakatan

antara pengguna / pelanggan tentang definisi

layanan, tingkat kinerja, dan cara

pengukurannya? Apakah ada rapat berkala

(misalnya tahunan) untuk mendiskusikan dan

negosiasi berdasarkan perubahan proses dan

tools? Apakah sudah ditentukan petugas untuk

komunikasi pengguna dengan maintainer?

Apakah ada proses untuk memperbaiki uraian

Lampiran H (J20-22):

“Kalau untuk software yang digunakan

oleh client dan di-hosting-nya di data

center, infrastrukturnya PT XYZ, maka

kita kembalikan lagi kepada customer-

nya.”

Tidak ada artifak

pendukung.

Largely

Achieved

(68%)



194


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

pekerjaan? Apakah ada proses untuk menangani

permintaan layanan yang tidak termasuk dari

layanan pemeliharaan?

Req4.2.4

Apakah pemilihan pemasok/vendor berdasarkan

kapabilitas mereka untuk memenuhi kriteria yang

sudah kita tentukan dan untuk memenuhi SLA

kita? Ada prosedur untuk pemilihan vendor?

Lampiran H (J23):

“Tidak ada sih, saat ini.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Req4.2.5

Ada dokumen template kontrak untuk SLA

pemeliharaan, untuk pemasok, dan

subkontraktor?

Lampiran H (J24):

“Tentunya kalau ditanya sanggup, tidak

bisa dimonitor secara manual, karena

dihitung dari departemen yang ada ...”

-

Fully

Achieved

(93%)

Req4.2.6

Apakah sebelum SLA disepakati, acuan kinerja

saat ini sudah terdokumentasi? Apakah

Departemen TI bisa mengukur kapabilitas yang

diatur dalam SLA? Apa indikator kinerja (KPI)

dan bagaimana cara mengukurnya?

Lampiran H (J2, J7-J8, J24):

“Bisa, tapi di PT XYZ belum

diimplementasikan karena adanya

beberapa indikasi biaya yang perlu

diimplementasikan.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Req4.2.7

Apakah sudah ada prosedur untuk modifikasi

skop kerja yang diberikan ke subkontraktor?

Sudah ada prosedur terdokumentasi untuk

meninjau, mengadaptasi, mengoordinasikan

informasi kontraktual?

Lampiran H (J25-J28):

“Kalau software itu tidak ada yang perlu

kita isi, tapi kita mengajukan proposal.”

“Ada, kita diberikan sebuah dokumen.

Ada dokumentasinya.”

“Kalau review tidak perlu meeting, ...”

Tidak ada rapat

dengan vendor

untuk review

pencapaian SLA.

Partially

Achieved

(33%)

Req4.2.8 Apakah ada tinjauan formal terhadap hasil

eksekusi layanan pada milestone yang dicapai?

Lampiran H (J27):

“Kalau review tidak perlu meeting, ...”

Praktek tidak

dilakukan.

Not

Achieved



195


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Ada prosedur terdokumentasi? Dilakukan secara

berkala (4 kali setahun)? Apakah ada diskusi

tindakan korektif (corrective action) jika kinerja

menyimpang secara signifikan?

(0%)

Req4.2.9

Apakah Departemen TI memiliki kebijakan

untuk menagih (secara internal) terhadap layanan

yang dilakukannya?

Lampiran H (J33):

“Tidak ada.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Req4.2.10 Apakah ada simulasi tagihan untuk layanan

pemeliharaan?

Lampiran H (J33):

“Tidak ada.” Praktek tidak

dilakukan.

Not

Achieved

(0%)

Req4.2.11

Apakah Departemen TI memiliki sistem tagihan

(billing system) yang digunakan untuk membuat

tagihan terhadap layanannya?

Lampiran H (J33):


dilakukan.

Not

Achieved

(0%)

Req4.2.12

Apakah proses pengukuran SLA dan laporan

kinerja juga digunakan untuk tagihan layanan

Departemen TI?

Lampiran H (J33):


dilakukan.

Not

Achieved

(0%)

Req4.2.13

Apakah Departemen TI mampu membuat laporan

tentang biaya-biaya yang digunakan dalam

kegiatan pemeliharaan? Apakah bisa dibagi

berdasarkan kategori pemeliharaan?

Lampiran H (J34-J35):

“Anggaran tahunan kita itu dibagi dua,

opex sama capex.”

“Saya sih baru buat ya.”

-

Fully

Achieved

(100%)


diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA SLA and Supplier Agreements Management (Req4).



196



Praktek : Software maintenance management has not yet recognize the

need for formal contracts and SLAs.

Sumber Lisan : Lampiran H (J2)

Artifak : -

Berdasarkan bukti lisan, pernyataan negatif praktek ini tidak dipenuhi. Saat

pemantauan tingkat layanan sudah dilakukan secara manual.


Praktek : The agreements with clients, subcontractors, and outsourcers

are elaborated from templates, documents, and contracts from

suppliers and subcontractors.

Sumber Lisan : Lampiran H (J2, J10)

Artifak : Template Kontrak dengan Pihak Ketiga

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini sudah ada template

untuk pembuatan kontrak dengan pihak ketiga. Jadi disimpulkan bahwa praktek

ini tercapai sepenuhnya (Fully Achieved).


Praktek : Preliminary discussions are held on the introduction of a more

formal SLA and contracts.


Artifak : -

Berdasarkan bukti lisan, saat ini sudah ada kegiatan di seksi Hardware &

Infrastructure untuk pengenalan SLA dan kontrak formal. Hal ini dilakukan

dengan justifikasi agar tidak hanya Kepala Seksi yang paham dengan ketentuan-

ketentuan layanan. Kekurangan dari praktek ini adalah tidak ada bukti artifak


197


yang mendukung. Jadi dapat disimpulkan bahwa praktek ini tercapai sebagian

besar (Largely Achieved).


Praktek : A maintenance engineer is assigned as an account manager to

plan and coordinate the customer account management

activities.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada orang yang ditugaskan sebagai

account manager. Praktek saat ini adalah Kepala Seksi IT Support bertindak

sebagai contact person, dan jika berhalangan maka turun ke stafnya. Kepala Seksi

IT Support juga sudah menginformasikan ke vendor siapa saja rekan kerjanya,

untuk mengambil alih kegiatan koordinasi jika Kepala Seksi berhalangan.

Kelemahan dari praktek ini adalah tidak ada artifak yang mendukung. Jadi dapat



Praktek : The stakeholders (customers, end users, maintainers,

developers, operations, and suppliers) agree on the necessity for

more formal SLAs and contracts concerning software

maintenance.

Sumber Lisan : Lampiran H (J20-22)

Artifak : -

Berdasarkan bukti lisan, saat ini ada dua jenis SLA yang ditangani oleh

Departemen TI. Yang berkaitan dengan infrastruktur, dan yang berkaitan dengan

SI. Untuk yang berkaitan dengan SI, SLA ditentukan dengan kesepakatan

pengguna. Untuk yang berkaitan dengan infrastruktur, SLA ditentukan oleh

Departemen TI sendiri. Kekurangan praktek ini adalah tidak ada bukti artifak


198


yang mendukung. Jadi dapat disimpulkan bahwa praktek ini tercapai sebagian

besar (Largely Achieved).


Praktek : The maintainer selects and reassesses suppliers and

subcontractors. The selection and assessment is based on

assessment of their capabilities to meet the specified conditions

and established criteria stated in the SLAs.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada prosedur formal untuk pemilihan

vendor. Kriteria pemilihan yang digunakan adalah harga dan kredibilitas vendor.

Tidak ada checklist untuk memeriksa tawaran jasa oleh vendor. Jadi dapat



Praktek : A maintenance SLA, supplier, and subcontractor contract

template is defined, documented, and approved.


Artifak : Template Kontrak dengan Pihak Ketiga

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini sudah ada template

untuk pembuatan kontrak dengan pihak ketiga. Jadi disimpulkan bahwa praktek

ini tercapai sepenuhnya (Fully Achieved).


Praktek : The SLA concluded between the maintainer and the customer

establishes the foundation of the management of the

relationship.

Sumber Lisan : Lampiran H (J2, J7-J8, J24)


199


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada prosedur pemilihan indikator kinerja

secara formal untuk menentukan pencapaian SLA. Pemantauan SLA juga

dilakukan secara manual, yang karena tidak ada indikator resminya, berarti

dilakukan atas inisiatif pribadi. Pemantauan SLA ada bantuan terotomatisasi

karena pertimbangan biaya. Jadi dapat disimpulkan bahwa praktek ini tidak



Praktek : The modifications to the scope of work given to the

subcontractors, to modalities of the contract for subcontracting,

and the SLAs are made according to a documented procedure.

Changes to commitments are reviewed and agreed between

stakeholders.

Sumber Lisan : Lampiran H (J25-J28)

Artifak : Prosedur Perubahan Skop Kerja

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini sudah ada prosedur

perubahan skop kerja vendor. Kelemahan dari praktek ini adalah tidak ada rapat

dengan vendor untuk review pencapaian SLA. Justifikasi tidak ada rapat tersebut

adalah karena laporan pencapaian SLA yang ditinjau adalah yang diberikan dari

vendor. Jadi dapat disimpulkan bahwa praktek ini tercapai sebagian (Partially

Achieved).


Praktek : Formal reviews on the execution and results of services

provided are conducted at selected milestones, according to a



Artifak : -


200


Berdasarkan bukti lisan, saat ini tidak ada tinjauan formal terhadap pencapaian

SLA. Jadi disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).


Praktek : The maintenance organization establishes a policy for billing

services.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada kebijakan untuk tagihan internal

terhadap layanan dari Departemen TI. Jadi disimpulkan bahwa praktek ini tidak


4.2.9.12 Praktek Req4.2.10

Praktek : Internal customers who are bound to the services of the internal

IS/IT maintainer will engage in a simulated billing.


Artifak : -




4.2.9.13 Praktek Req4.2.11

Praktek : The maintenance organization designs, documents and presents

its bill to its many service customers.


Artifak : -


201





4.2.9.14 Praktek Req4.2.12

Praktek : The SLA indicators are used for billing purposes.


Artifak : -




4.2.9.15 Praktek Req4.2.13

Praktek : Raw data describing costs are available for some maintenance

resources (personnel, systems, contracts/licenses). Maintenance

billing captures, presents, and explains the most important cost

elements.

Sumber Lisan : Lampiran H (J34-J35)

Artifak : Contoh Pengeluaran Tahunan OPEX dan CAPEX

Berdasarkan bukti lisan, saat ini ada pembagian pengeluaran berdasarkan sifatnya

OPEX (operational expenditure, belanja operasional) atau CAPEX (capital

expenditure, belanja modal). Jadi dapat disimpulkan bahwa praktek ini tercapai

sepenuhnya (Fully Achieved).

4.2.10 Predelivery and Transition Services (Evo1)

Tujuan dari KPA ini adalah untuk meningkatkan pemahaman pemelihara

perangkat lunak, dan untuk mempengaruhi maintainability dari perangkat lunak

saat masih dalam pengembangan. (April & Abran, 2008, hal. 109).


202





203


Tabel 4.10 Ringkasan Penilaian Praktek-praktek Evo1

Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Evo1.0.1

Apakah Departemen TI melakukan kegiatan predelivery

and transition sebelum serah terima perangkat lunak dari

pengembang ke pemelihara?

Lampiran G (J75):

“Iya.” -

No

(100%)

Evo1.1.1

Jika ada, apakah secara informal? Apakah ada prosedur

terdokumentasi? Apakah ada kebijakan yang

mengharuskan hal tersebut? Atau berupa inisiatif pribadi?


“Ah, maksud saya

terdokumentasi ada yang

tidak.”

Tidak ada artifak

pendukung.

Partially

Achieved

(33%)

Evo1.2.1

Apakah maintainer berkomunikasi dengan developer

mengenai kegiatan predelivery and transition? Pada tahap

life-cycle apa maintainer mulai terlibat dalam proyek?

Dalam TOT antara developer dengan maintainer, apa saja

yang ditransfer (produk intermediate, tools, pengetahuan)?

Apa kriteria yang digunakan untuk menentukan sudah

saatnya melakukan transisi?


“Iya, karena full stack kan

selalu gue lagi gue lagi.”

“Iya, not applicable.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo1.2.2

Apakah maintainer secara proaktif mengangkat isu

predelivery and transition ke hadapan developer dan

pelanggan/pengguna/pemangku kepentingan?


“Idealnya sih memang

diikutkan, tapi itu sangat

susah sekali.”

“Kita terlalu kecil mungkin

ya.”

“Nggak ada sih, ...”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo1.2.3

Apakah maintainer secara proaktif mengangkat isu

predelivery and transition ke hadapan orang yang bertugas

untuk pengadaan, di tahap awal proyek pengembangan?

Lampiran G (J83):

“Belum ada.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)


204


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Apakah maintainer menyampaikan requirement yang

berkaitan dengan maintainability dan predelivery and

transition?

Evo1.2.4

Apakah Departemen TI melakukan sosialisasi kegiatan

predelivery and transition kepada pelanggan/pengguna?

Atau apa yang dilakukan Departemen TI untuk memastikan

pelanggan/pengguna paham tentang apa yang akan mereka

alami selama transisi? Apakah pengguna diberi tahu

tentang masalah yang masih belum diselesaikan dalam

pengembangan yang akan diserahkan kepada maintainer?

Apakah ada sosialisasi proses dukungan? Apakah ada

sosialisasi kepada pengguna tentang layanan apa saja yang

nantinya akan disediakan oleh Departemen TI untuk

pemeliharaan perangkat lunak, dan siapa saya yang

bertugas sebagai pemelihara? Apakah ada sosialisasi

tentang SLA?


“Ada yang kemarin sih

ada.”

“Selama masa transisi

kontak ininya langsung

nih, bisa direct.”

“Ada formal itu juga, tapi

dikirim dalam distribusi

email ...”

Tidak ada artifak

pendukung.

Largely

Achieved

(68%)

Evo1.2.5

Apakah Departemen TI membuat, mengadaptasi, dan

menggunakan checklist untuk memastikan kebenaran

deliverable dan aktivitas-aktivitas predelivery and

transition? Apakah Departemen TI membuat - berdasarkan

pengalaman - daftar kegiatan predelivery and transition,

dan hal-hal penting yang berkontribusi terhadap transisi

yang mulus dan efektif? Apakah checklist ini juga

digunakan sebagai alat komunikasi dengan pemangku


“Ya checklist lah, bisa

dibilang checklist itu kan.”

“Ada. Tanggal segitu udah

harus deploy.”

Tidak ada artifak

pendukung.

Largely

Achieved

(68%)

Tabel 4.10 Ringkasan Penilaian Praktek-praktek Evo1 (sambungan)


205


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

kepentingan?

Evo1.2.6

Apakah maintainer sudah diberikan pelatihan, informasi,

dan pengetahuan sesuai dengan yang dinyatakan oleh

developer, untuk memfasilitasi transisi perangkat lunak dari

pengembangan ke pemeliharaan?

Lampiran G (J99):

“Nggak ada.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo1.2.7

Apakah Departemen TI memastikan pelatihan untuk

pemeliharaan (untuk infrastruktur, arsitektur, perangkat

lunak, dan dokumentasi) yang diberikan oleh pengembang

memang efektif? Apakah ada perbandingan antara tujuan

pelatihan terhadap hasil pelatihan? Kalau tidak sesuai, apa

tindakan perbaikannya?

Lampiran G (J99);

“Nggak ada.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo1.2.8

Apakah sebelum transisi, Departemen TI mengevaluasi dan

mendiskusikan efisiensi dan efektivitas pelatihan untuk

pengguna/pelanggan?

Lampiran J (J2):

“...setiap aplikasi (berikut

perubahannya) selalu

dilengkapi dengan

guidance user bahkan

training untuk

menjalankannya, ...”

Pelatihan dilakukan

tapi tidak dievaluasi

efisiensi dan

efektivitasnya.

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo1.2.9

Apakah maintainer membuat/menjaga kekinian inventori

lisensi, pengguna, lingkungan, dan dokumen teknis?

Apakah maintainer mengerti antar muka, data, dan

lingkungan operasional? Apakah daftar masalah yang

belum diselesaikan selama pengembangan di-update?


“Nggak ada.”

“Awal-awal semua orang

di PT XYZ ini sebagai

maintainer, Jos. Jadi nggak

perlu dokumen itu. Karena

Praktek tidak

dilakukan.

Not

Achieved

(0%)



206


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

sudah tahu semua, gitu.”

Evo1.2.10

Apakah maintainer sudah memastikan bahwa

konfigurasi/versi source code yang dimilikinya adalah

konfigurasi/versi yang akan digunakan untuk evolusi

perangkat lunak setelah transisi akhir? Apakah maintainer

sudah memastikan dia bisa membuat perubahan perangkat

lunak, compile, menguji, dan memindahkan perubahan

tersebut ke sistem produksi?


“Sudah sih itu.”

Tidak ada prosedur

yang mengharuskan

dilakukannya praktek

ini.

Partially

Achieved

(33%)

Evo1.2.11

Apakah maintainer, dalam menjaga kekinian daftar

masalah yang belum diselesaikan dalam pengembangan,

mengelompokkan berdasarkan kategori, prioritas, dan

status, agar pengguna/pelanggan paham tentang luasnya

backlog yang ditransfer oleh pengembang kepada

pemelihara setelah transisi akhir? (Tujuannya adalah untuk

menjaga ekspektasi pengguna, dan untuk memastikan skop

pekerjaan awal maintainer)

Lampiran G (J117):

“Daftar saja sih.”

Tidak ada artifak

pendukung.

Partially

Achieved

(33%)

Penjelasan dari setiap praktek-praktek di Tabel 4.10 di atas dijelaskan di subbab 4.2.10.1 sampai 4.2.10.13 untuk memaparkan kelemahan

yang diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Predelivery and Transition Services (Evo1).



207


4.2.10.1 Praktek Evo1.0.1


activities of software predelivery and transition before the

handover of a software.


Artifak : -

Berdasarkan bukti lisan, pernyataan negatif dari praktek ini tidak terpenuhi. Saat

ini sudah ada aktivitas predelivery and transition sebelum serah terima perangkat

lunak dari pengembang ke pemelihara.


Praktek : Pre-delivery and transition, within the software maintenance

organization, is carried out in an informal way.


Artifak : -

Berdasarkan bukti lisan, saat ini predelivery and transition dijalankan secara tidak

formal. Kekurangan dari praktek ini adalah tidak ada bukti artifak yang

mendukung. Jadi dapat disimpulkan bahwa praktek ini tercapai sebagian

(Partially Achieved).


Praktek : The software maintenance organization communicates with the

developer to clarify and agree on predelivery and transition

activities required for the software.


Artifak : -


208


Berdasarkan bukti lisan, narasumber berpendapat bahwa tidak diperlukan

komunikasi antara pengembang dengan pemelihara karena sering kali orangnya

sama. Kekurangan praktek ini adalah jika saat transisi proyek ternyata orangnya

dibedakan, maka operasional dan penanganan permintaan pemeliharaan dapat

terhambat. Kekurangan lainnya adalah karena orangnya sering sama, maka isu-isu

yang belum terselesaikan saat delivery tidak tercatat. Jadi dapat disimpulkan



Praktek : The software maintenance organization manages the

relationship with the developer and the customer proactively.

The objective is that there be no conflict or resistance regarding

software predelivery and transition activities.


Artifak : -

Berdasarkan bukti lisan, belum ada pengelolaan hubungan antara pemelihara

dengan pengembang dan pengguna. Jadi disimpulkan bahwa praktek ini tidak



Praktek : The software maintenance organization communicates

proactively with the purchasing organization (or directly with

the developers) to ensure that software maintenance predelivery

and transition considerations are included in the contract, as

well as in the project development plan and schedule.


Artifak : -

Berdasarkan bukti lisan, belum ada hubungan antara pemelihara dengan

pengadaan. Jadi disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).


209



Praktek : The software maintenance organization communicates with the

customer to ensure that the predelivery and final transition

activities are well understood. In addition, this communication

activity is used to introduce the basic notions of the software.


Artifak : -

Berdasarkan bukti lisan, sudah ada sosialisasi aktivitas predelivery and transition

dengan pengguna. Contoh aktivitas yang dilakukan adalah melakukan conference

call dengan pengguna di cabang lain. Kekurangan praktek ini adalah tidak

didukung dengan artifak. Jadi dapat disimpulkan bahwa praktek ini tercapai



Praktek : The software maintenance organization develops, adapts, and

uses a checklist to follow up on deliverables and key activities of

the predelivery and transition of software.


Artifak : -

Berdasarkan bukti lisan, sudah ada daftar kegiatan yang dianggap sebagai

checklist yang berupa jadwal untuk sosialisasi kegiatan transisi dengan cabang

lain. Kekurangan praktek ini adalah email daftar kegiatan tersebut (artifaknya)

tidak berhasil ditemukan. Jadi dapat disimpulkan bahwa praktek ini tercapai



Praktek : The software maintenance engineers assigned to support the

software obtain information and knowledge to facilitate the final

transition of the software from development to maintenance.


210



Artifak : -

Berdasarkan bukti lisan, tidak ada daftar keahlian dan daftar pelatihan bagi

pemelihara untuk mendukung transisi proyek. Jadi disimpulkan bahwa praktek ini



Praktek : The software maintenance organization ensures the

effectiveness of maintenance training (on infrastructure,

architecture, software, and documentation) provided by the

developer before final transition.


Artifak : -

Berdasarkan bukti lisan, tidak ada pelatihan bagi pemelihara untuk mendukung

transisi proyek. Jadi disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).

4.2.10.10 Praktek Evo1.2.8

Praktek : The software maintenance organization evaluates and discusses

the efficiency and effectiveness of the user training undertaken

by the customer (in terms of access, functionality, help function,

and user documentation) and recommended by the developer.

This must be done before the final software transition.


Artifak : -

Berdasarkan bukti lisan, pelatihan untuk pengguna saat adanya perubahan

aplikasi, bukan hanya saat transisi. Namun belum ada evaluasi dan diskusi

efisiensi dan efektivitas pelatihan tersebut. Jadi disimpulkan bahwa praktek ini



211


4.2.10.11 Praktek Evo1.2.9

Praktek : Software maintenance engineers, who are responsible for

conducting the final transition, ensure that the product

documentation is obtained, that they understand its interfaces,

data, and operational environment, and that they update the

outstanding problems log before final transition.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada kegiatan untuk memastikan

dokumentasi produk diperoleh dan agar pemelihara mengerti antar muka, data,

dan lingkungan operasional, serta agar mereka memperbaharui daftar

permasalahan sebelum transisi. Jadi disimpulkan bahwa praktek ini tidak tercapai

(Not Achieved).

4.2.10.12 Praktek Evo1.2.10

Praktek : Software maintenance engineers, who are responsible for

conducting the final transition, ensure that the final

configuration of the source code that will be used to evolve the

software after final transition is obtained.


Artifak : -

Berdasarkan bukti lisan, saat ini pemelihara sudah memastikan bahwa kode

sumber yang digunakannya adalah memang yang digunakan di produksi.

Kekurangannya adalah hal ini merupakan inisiatif pribadi, tidak ada prosedur

yang mengharuskan pemelihara untuk memastikan hal ini. Jadi disimpulkan

bahwa praktek ini tercapai sebagian (Partially Achieved).


212


4.2.10.13 Praktek Evo1.2.11

Praktek : The software maintenance engineers, who are responsible for

conducting the final transition, ensure that the official list of

outstanding problems found during systems testing and

acceptance testing are obtained. For each problem, he/she will

record their categories, priority, and status in order to identify

and make visible, to the customer, the extent of the request

backlog that is being transferred from development to

maintenance after the final transition.


Artifak : -

Berdasarkan bukti lisan, saat ini pemelihara sudah membuat daftar masalah yang

belum diselesaikan saat pengembangan, dan sudah disosialisasikan ke pengguna.

Kekurangannya daftar tersebut (artifak dari praktek ini) tidak berhasil ditemukan.

Jadi disimpulkan bahwa praktek ini tercapai sebagian (Partially Achieved).

4.2.11 Operational Support Services (Evo2)

Tujuan dari KPA ini adalah untuk memastikan definisi yang jelas, identifikasi,

dan fasilitas untuk merekam waktu pengerjaan atau tagihan dari aktivitas-aktivitas

dukungan operasional. KPA ini juga menekankan dukungan pemeliharaan yang

memadai (setelah jam kerja biasa) untuk memperjelas atau mencatat usaha yang

dilakukan terhadap berbagai macam aktivitas dukungan operasional. Aktivitas-

aktivitas dukungan operasional ini sangat memakan waktu sehingga harus diakui,

tapi justru sering diabaikan. Pentingnya aktivitas-aktivitas ini harus

diinformasikan kepada para pemangku kepentingan (April & Abran, 2008, hal.

111).




213



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Evo2.0.1 Apakah Departemen TI menyediakan layanan dukungan

operasional?

Lampiran G (J118):

“Iya.” - No (100%)

Evo2.1.1

Apakah dukungan tersebut bersifat informal? Apakah definisi

layanan dukungan operasional jelas? Apakah kegiatannya

direkam/dicatat? Apakah SLA ini ditentukan?


“Iya.”

“Formal.”

-

Fully

Achieved

(93%)

Evo2.2.1

Apakah maintainer memiliki jadwal operasi perangkat lunak

(misalnya untuk batch update, script update, update untuk

perangkat lunak, transfer/sinkronisasi data antar sistem)?

Apakah maintainer memastikan bahwa dia selalu memiliki

jadwal yang terbaru, perubahan terbaru, update terakhir? Apakah

maintainer memonitor perubahan perilaku perangkat lunak?


“Jadwal maksudnya? Ada.”

“Ada, walaupun nggak resmi

kan bisa.”

Tidak ada

artifak

pendukung.

Largely

Achieved

(68%)

Evo2.2.2

Apakah pembagian tugas pemantauan perangkat lunak jelas?

Bagaimana cara Departemen TI membagi tugas memantau

perangkat lunak? Yang mana seperti apa yang dipantau bagian

operasi (tim infrastruktur dan tim help desk)? Yang seperti apa

yang dipantau tim developer (yang juga merupakan maintainer

di Departemen TI)? Misalnya: tugas untuk backup, defrag,

clustering, database administration, proses pengujian perangkat

lunak setelah pemulihan dari kegagalan/kesalahan (berbeda

dengan unit testing dan UAT), dan tugas meng-update jadwal

otomatis.


“Kalau terkait database ya

Pak INS, kalau aplikasi saya.”

-

Fully

Achieved

(93%)

Evo2.2.3

Apakah maintainer membuat laporan pemantauan berdasarkan

karakteristik kunci dari tiap layanan dan masing-masing

perangkat lunak operasional?

Lampiran G (J138):

“Nggak.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)


214


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Laporan ini bisa digunakan untuk manajemen SLA, komunikasi

dengan pelanggan/pengguna, dan melihat tren untuk

mencegah/memperbaiki kerusakan/kegagalan.

Evo2.2.4

Apakah ada jadwal dukungan sistem? Apakah di-update dan

dipublikasikan (internal)?

Yang dimaksud dengan jadwal adalah daftar personil yang bisa

dihubungi, yang dalam jam kerja, dan yang di luar jam kerja.

Apakah ada prosedur terdokumentasi untuk menghubungi

maintainer dalam kasus kegagalan/kesalahan sistem di dalam

dan di luar jam kerja?


“Nggak ada di kita. Karena by

default kan kita nggak 24

hours kan. Jadi, jadinya nggak

di-formalized itunya.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo2.2.5

Apakah maintainer mampu menjawab pertanyaan pengguna

tentang fungsionalitas dan aturan bisnis (business rules) untuk

perangkat lunak yang dipeliharanya? Apakah maintainer mampu

mengevaluasi source code lalu memberikan gambaran /

menjelaskan kepada pengguna tentang jalannya program?

Apakah manajemen paham tentang usaha yang diperlukan untuk

kegiatan ini (berarti hal ini dianggap sebagai satu kategori

layanan Departemen TI)?


“...mencari pembuktian itu

yang lebih nyata artifact-nya

kan dari source code.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo2.2.6

Apakah maintainer:

1. dapat membantu pengguna untuk lebih memahami data atau

aturan ekstraksi data?

2. merancang dan mengeksekusi laporan ad-hoc? (yang hanya

hasilnya langsung diberikan ke pengguna, berarti programnya

bukan dikategorikan sebagai program operasional atau tidak di-

Lampiran G (J151, J157-

J158):

“Ada, tapi tiket itu

kebanyakan request sih,

bukan bug. Itu yang ad hoc

sih. Kalau yang reguler kan

-

Fully

Achieved

(93%)



215


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

deploy)

3. Membuat program laporan yang bisa dijalankan pengguna

kapan pun mereka mau?

4. Bekerja bersama dengan tim operasi (infrastruktur atau help

desk) yang memerlukan pengetahuan dalam perangkat lunak?

Apakah usaha-usaha ini diakui sebagai layanan Departemen TI?

Berarti dipublikasikan, didokumentasikan, dan diukur, sama

seperti layanan pemeliharaan perangkat lunak lainnya?

sudah di deploy langsung, bisa

dipakai terus.”


yang diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Operational Support Services (Evo2).



216



Praktek : The maintenance organization does not provide operational

support services.


Artifak : Uraian tugas Software Developer (Evo2.0.1 - Software

Developer.pdf)


praktek ini tidak terpenuhi. Saat ini sudah ada layanan untuk dukungan

operasional.


Praktek : The operational support service, in the software maintenance

organization, is offered informally.



Developer.pdf)

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini layanan dukungan

operasional bukan hanya bersifat informal, melainkan sudah merupakan bagian

dari uraian tugas. Jadi disimpulkan bahwa praktek ini tercapai sepenuhnya (Fully

Achieved).


Praktek : A software operation schedule (online and batch) exists and is

established on the basis of resource capability and software

workload.


Artifak : -


217


Berdasarkan bukti lisan, saat ini layanan dukungan operasional yang migrasi data

dan perbaikan dijadwalkan di luar jam atau hari kerja. Penjadwalan di luar jam

atau hari kerja tersebut dilakukan agar operasional bisnis tidak terganggu.

Kekurangan praktek ini adalah praktek ini dilakukan karena perintah lisan,

sehingga tidak ada bukti artifak yang mendukung. Jadi dapat disimpulkan bahwa



Praktek : The maintenance engineer and the operations organization are

aware of their mutual responsibilities for monitoring of each

piece of operational software. The maintenance engineers

monitor the software proactively in conjunction with the

computer operations that typically monitor infrastructure

(memory, communication links, and disk space).



Developer.pdf), Uraian tugas Kepala Seksi IT Support (Evo2.2.2

- IT Support Section Head.pdf)

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat pembagian tugas dan

tanggung jawab antara bagian operasional (seksi IT Support) dan pemelihara

(seksi Application Development) untuk memonitor perangkat lunak, dilakukan

berdasarkan uraian tugas. Jadi dapat disimpulkan bahwa praktek ini tercapai

sepenuhnya (Fully Achieved).


Praktek : The maintainer produces monitoring reports on the key

characteristics for each service and of each piece of operational

software.


Artifak : -


218


Berdasarkan bukti lisan, saat ini para pemelihara tidak ada membuat laporan

pemantauan karakteristik kunci layanan dari perangkat lunak operasional. Jadi



Praktek : The support schedule is created, updated, and published. It is

built to ensure a service coverage as agreed upon and described

in the SLAs.


Artifak : -

Berdasarkan bukti lisan, tidak ada jadwal dukungan luar jam kerja. Justifikasinya

adalah karena PT XYZ bukan bisnis 24 jam. Dukungan di luar jam kerja

dilakukan hanya jika diperlukan. Jadi disimpulkan bahwa praktek ini tidak



Praktek : The maintenance engineer has functional and business rule

expertise about the software he/she maintains.


Artifak : -

Berdasarkan bukti lisan, pemelihara perlu mengerti tentang proses bisnis dari

perangkat lunak yang dipeliharanya. Kekurangan dari praktek ini adalah tidak

adanya indikasi bahwa sudah ada usaha untuk mengevaluasi pemahaman para

pemelihara tentang proses bisnis perusahaan. Yang terjadi di lapangan justru

sebaliknya, pemahaman proses bisnis dicari dari kode sumber. Jadi dapat



Praktek : The maintenance engineer offers ad hoc services on demand.


219


Sumber Lisan : Lampiran G (J151, J157-J158)

Artifak : Uraian Tugas Kepala Seksi Report Development (Evo2.2.6 -

Report Development Section Head.pdf)

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini layanan sesuai

permintaan (on demand) sudah disediakan, baik yang berupa ekstrak data satu

kali, maupun ekstrak data yang bisa dilakukan berulang kali oleh pengguna

sendiri. Permintaan layanan on demand tersebut sudah masuk ke dalam sistem

ticketing. Jadi dapat disimpulkan bahwa praktek ini tercapai sepenuhnya (Fully

Achieved).

4.2.12 Software Evolution and Correction Services (Evo3)

KPA ini berisi aktivitas-aktivitas untuk memodifikasi perangkat lunak aplikasi.

Aktivitas-aktivitas tersebut terdiri dari perancangan yang mendetail, evolusi

(adaptif, preventif, dan penyempurnaan), koreksi, dan pengujian. Aktivitas-

aktivitas tersebut menggunakan proses-proses pemeliharaan yang berstandar dan

dipublikasikan. Aktivitas-aktivitas dalam KPA ini mirip dengan aktivitas-aktivitas

para pengembang. Untuk layanan koreksi, para pemelihara bisa memilih untuk

mengimplementasikan solusi sementara untuk mengembalikan layanan lalu

kemudian dilanjutkan dengan MR untuk menyelesaikan masalahnya secara

permanen (April & Abran, 2008, hal. 111).




220



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Evo3.0.1 Apakah Departemen TI menyediakan layanan

koreksi dan evolusi perangkat lunak?

Lampiran G (J159):

“Ada pasti.” -

No

(100%)

Evo3.1.1

Apakah layanan tersebut bersifat informal? Apakah

proses koreksi mengikuti suatu prosedur yang

terdokumentasi, atau terserah maintainer? Apakah

ada prosedur pemilihan maintainer untuk masing-

masing tipe permintaan koreksi/evolusi?

Lampiran G (J160):

“Iya. Formal. Cuma

perencanaannya yang ...

sebenarnya punya cuma tidak

jalannya seperti yang

semestinya. Banyak kendala.

Yang begini plan lengkap sih.

Ya mungkin tidak semua

terlaksana. Banyak proyek yang

menyusup.”

-

Fully

Achieved

(93%)

Evo3.2.1

Apakah requirement dalam MR (modification

request) untuk pemeliharaan cukup detail?

Apakah ada mengidentifikasi komponen apa saja

yang harus diubah? Apakah mengidentifikasi

dokumentasi apa saja yang harus diubah?


“...kalau dokumen nggak ada.”

Tidak merinci daftar

dokumentasi yang

perlu diubah. Tidak

ada artifak pendukung.

Partially

Achieved

(33%)

Evo3.2.2

Apakah PR diproses seperti CR/MR?

Seharusnya tidak, karena tidak ada analisis dampak

dan tidak ada permintaan otorisasi untuk deployment

kepada pelanggan, karena maintainer harus bekerja

dengan cepat untuk memperbaiki kesalahan, lalu

mendokumentasikan perubahannya setelah itu.

Apakah ada prosedur terdokumentasi untuk


“Nggak sih.”

Prosedur tidak tertulis.

Tidak ada artifak

pendukung.

Largely

Achieved

(68%)


221


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

penyelesaian PR?

Evo3.2.3

Apakah ada prosedur terdokumentasi untuk untuk

implementasi/programming?

Misalnya: programming and naming conventions,

life-cycle stages?


“Ada itu, dokumen resmi.”

Tidak ada prosedur

standar tahapan

pemrograman.

Partially

Achieved

(33%)

Evo3.2.4

Apakah ada prosedur terdokumentasi untuk

modifikasi data operasional? Apakah perlu minta izin

pemilik data terlebih dahulu? Apakah pemangku

kepentingan diberi tahu bahwa akan/sudah ada

perubahan data? Apakah maintainer menyimpan

berkas-berkas komunikasi/otorisasi untuk permintaan

modifikasi data operasional tersebut?


“Prakteknya sih begitu.

Formalnya nggak tahu. Mungkin

ada edarannya, tapi kita nggak

tahu.”

Tidak ada prosedur

modifikasi data

operasional.

Partially

Achieved

(33%)

Evo3.2.5

Apakah evolusi perangkat lunak yang dipelihara,

menggunakan bahasa pemrograman yang sama

dengan dengan saat perangkat lunak tersebut

dikembangkan? Apakah ada kasus di mana tidak

demikian? Kenapa (misalnya karena cost benefit

analysis)? Apakah ada prosedur yang digunakan

untuk menentukan kapan boleh tidak menggunakan

bahasa pemrograman yang sama?


“Nggak.”

Tidak ada prosedur

yang mengatur

penggunaan bahasa

pemrograman.

Largely

Achieved

(68%)

Evo3.2.6

Apakah dalam evolusi perangkat lunak, dokumentasi

yang perlu di-update diidentifikasi? Apakah bisa

dilacak antara PR/MR dengan prosedur/proses yang

mana, modul yang mana, data yang dimodifikasi?

Lampiran G (J176):

“Nggak ada.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)



222


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Apakah bisa backtracking/rollback perubahan

perangkat lunak atau data? Ada prosedurnya? Ada

tool untuk melacak ini?

Evo3.2.7

Apakah ada unit test untuk tiap-tiap modifikasi?

Apakah ada rencana unit test? Apakah ada prosedur

pembuatan data untuk pengujian?

Tujuannya untuk memastikan perubahan sudah

sesuai dengan requirements.

Apakah hasil unit testing didokumentasikan?

Tujuannya adalah untuk membuktikan perubahan

tidak mendestabilisasi perangkat lunak.

Lampiran G (J180):

“Nggak ada.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo3.2.8

Apakah ada integration test? Regression test?

Apakah dilakukan untuk tiap perubahan? Apakah ada

rencana integration test dan regression test? Apakah

ada prosedur pembuatan data untuk pengujian ini?

Tujuannya adalah untuk meminimalisasi efek

samping yang tidak diinginkan setelah adanya



“Nggak ada. Orang yang

integration test.”

“Prosedurnya nggak ada.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo3.2.9

Apakah dokumentasi untuk pengguna di juga diuji

saat unit/integration/regression testing?

Jika iya, dan jika ditemukan kesalahan di

dokumentasi pengguna, apa yang dilakukan?

Lampiran G (J185):

“User guide-nya? Dibaca itu. Di-

update sih. Pak IYB sih rajin

update-nya. Tapi yang koboi,

yang tiba-tiba, nggak sempat.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo3.2.10 Apakah dokumentasi internal juga diperbaharui saat Lampiran G (J186-J187): Praktek tidak Not



223


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

ada perubahan/evolusi perangkat lunak? Ada

prosedurnya?

“Nah itu nggak ada.” dilakukan. Achieved

(0%)

Evo3.2.11

Apakah dokumentasi eksternal juga diperbaharui saat

ada perubahan/evolusi perangkat lunak? Ada

prosedurnya?

Seharusnya ada:

1. Apa masalah yang dipecahkan oleh modifikasi ini?

2. Apa struktur data / algoritma yang berubah?

Seperti apa sebelum dan sesudah?

3. Apa perubahan alur data?

Lampiran G (J188):

“Kayaknya beberapa ada.

Mungkin beberapa nggak ada.”

Praktek tidak seragam

dilakukan. Tidak ada

prosedur yang

mengharuskan

dokumentasi eksternal

dijaga kekiniannya.

Partially

Achieved

(33%)


yang diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Software Evolution and Correction Services

(Evo3).

Tabel 4.12 Ringkasan Penilaian Praktek-praktek Evo3 (sambungan) Tabel 4.11 Ringkasan Penilaian Praktek-praktek Evo2 (sambungan)


224



Praktek : The software maintenance organization does not provide

correction and evolution services for software.


Artifak : Uraian Tugas Software Developer (Evo3.0.1 - Software

Developer.pdf)


praktek ini tidak terpenuhi. Saat ini sudah ada layanan evolusi dan koreksi

perangkat lunak.


Praktek : The software maintenance organization provides informal

correction and evolution services for software.


Artifak : Uraian Tugas Software Developer (Evo3.0.1 - Software

Developer.pdf)

Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini layanan evolusi dan

koreksi perangkat lunak bersifat formal karena merupakan bagian dari uraian

tugas dari seksi Application Development. Jadi disimpulkan bahwa praktek ini

tercapai sepenuhnya (Fully Achieved).


Praktek : The detailed design elaborates the requirements of the user, and

it is developed according to a documented procedure.


Artifak : -


225


Berdasarkan bukti lisan, saat ini rancangan yang mendetail sudah menguraikan

requirement dari pengguna, dan sudah merinci daftar komponen yang perlu

diubah. Kekurangan praktek ini adalah tidak merinci daftar dokumentasi aplikasi

yang perlu diubah, dan tidak didukung dengan bukti artifak. Jadi disimpulkan



Praktek : The activities of investigation and design associated with a

failure (documented in a PR) are performed according to a



Artifak : -

Berdasarkan bukti lisan, saat ini kegiatan koreksi yang dilakukan untuk

penyelesaian kegagalan (failure) sudah memiliki prosedur yang berbeda dengan

MR, yaitu tidak perlu persetujuan dari pengguna atau pemangku kepentingan.

Kekurangan praktek ini adalah prosedur tersebut tidak tertulis, jadi tidak

ditemukan artifak pendukungnya. Jadi disimpulkan bahwa praktek ini tercapai



Praktek : The activities of implementation (programming) are performed

according to a documented procedure.


Artifak : -

Berdasarkan bukti lisan, saat ini sudah ada prosedur standar tahapan pemrograman

(life cycle). Kekurangan praktek ini adalah tidak adanya konvensi penamaan

(naming convention) untuk standarisasi penamaan variabel dan struktur kode

sumber. Kekurangan lainnya adalah prosedur standar tahapan pemrograman


226


tersebut (artifak dari praktek ini) tidak berhasil ditemukan. Jadi disimpulkan



Praktek : The roles and responsibilities concerning operational data

modifications are formally defined for the maintenance

engineer.


Artifak : -

Berdasarkan bukti lisan, tidak ada prosedur standar untuk modifikasi data

operasional. Dalam praktek di lapangan, modifikasi data memerlukan persetujuan

dari pemilik data terlebih dahulu, dengan persetujuan tersebut direkam di dalam

sistem ticketing. Jadi disimpulkan bahwa praktek ini tercapai sebagian (Partially

Achieved).


Praktek : The original programming languages of the software

maintained are used for the corrections and evolution of the

software.


Artifak : -

Berdasarkan bukti lisan, saat ini bahasa pemrograman yang digunakan untuk

evolusi dan koreksi perangkat lunak adalah sama dengan yang dipergunakan

dengan pada saat pengembangan. Kekurangan praktek ini adalah tidak ada

prosedur yang mengharuskan penggunaan bahasa pemrograman yang sama, dan

tidak ada kriteria kapan boleh menggunakan bahasa pemrograman yang berbeda.

Jadi disimpulkan bahwa praktek ini tercapai sebagian besar (Largely Achieved).


227



Praktek : The interrelationships (traceability) between the administrative

procedures, the modules, the processes, and the data are

updated when the software is corrected and evolved.


Artifak : -

Berdasarkan bukti lisan, saat ini tidak ada kegiatan untuk mengidentifikasi

dokumentasi atau prosedur yang perlu dikoreksi saat ada perubahan perangkat



Praktek : The unit tests must be performed for each component that is the

subject of a modification.


Artifak : -

Berdasarkan bukti lisan, saat ini tidak ada prosedur yang mengharuskan

pembuatan dan pelaksanaan pengujian unit (unit test) untuk setiap modifikasi.

Jadi disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).

4.2.12.10 Praktek Evo3.2.8

Praktek : The integration and regression tests must be performed for each

component that is the subject of a modification.


Artifak : -


pembuatan dan pelaksanaan pengujian integrasi dan regresi (integration and


228


regression test) untuk setiap komponen yang dimodifikasi. Jadi disimpulkan


4.2.12.11 Praktek Evo3.2.9

Praktek : The documentation of the user is submitted for testing by the

maintainer during the unit tests and the integration tests.


Artifak : -


pembuatan dan pelaksanaan pengujian unit, integrasi dan regresi, yang berarti

dokumentasi juga tidak diperiksa. Jadi disimpulkan bahwa praktek ini tidak


4.2.12.12 Praktek Evo3.2.10

Praktek : The internal documentation of the software is modified and kept

up to date according to a documented procedure.


Artifak : -

Berdasarkan bukti lisan, saat ini tidak ada prosedur yang mengharuskan agar

dokumentasi internal dijaga agar tetap diperbaharui. Jadi disimpulkan bahwa


4.2.12.13 Praktek Evo3.2.11

Praktek : The external documentation of the software is modified and kept

up to date according to a documented procedure.


Artifak : Contoh Dokumentasi Yang Dijaga Kekiniannya


229


Berdasarkan bukti lisan dan artifak yang dihasilkan, saat ini sudah ada

dokumentasi eksternal yang dijaga agar tetap diperbaharui. Kekurangan praktek

ini adalah menurut narasumber hal ini tidak seragam dilakukan, dan tidak ada

prosedur yang mengharuskan agar dokumentasi eksternal tetap dijaga

kekiniannya. Jadi disimpulkan bahwa praktek ini tercapai sebagian (Partially

Achieved).

4.2.13 Verification and Validation (Evo4)

Tujuan dari KPA ini adalah untuk memastikan bahwa layanan atau permintaan

pemeliharaan sudah sesuai dengan requirement dan memang benar-benar

memenuhi kebutuhan pengguna (April & Abran, 2008, hal. 113).




230



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Evo4.0.1 Apakah ada kegiatan verifikasi dan validasi

untuk pemeliharaan perangkat lunak?

Lampiran D (J1):

“...saya melakukannya terutama untuk

proyek-proyek yang besar.”

- No

(100%)

Evo4.1.1

Kalau ada, apakah secara terstruktur dan

terkoordinasi? Apakah pengujian dibuat secara

sporadis dan tidak terencana?

Artinya, apakah rencana pengujian baru dibuat

setelah perubahan perangkat lunak selesai

dibuat? Apakah ada personil khusus untuk

pengujian? Apakah menggunakan tools khusus

pengujian (misalnya otomatisasi skenario, atau

tool untuk load testing)? Apakah ada lingkungan

khusus untuk pengujian? Apakah dalam

pengembangan, para pengembang

mempertimbangkan cara-cara pengujian

perangkat lunak, yang nantinya akan transisi ke

pemelihara?

Apakah kegiatannya terdokumentasi?

Apakah debugging dianggap sebagai proses

testing?

Lampiran D (J4-J9):

“Biasanya ada proyek besar, ada

permintaan-permintaan dadakan, ad hoc

tadi. Kalau proyek besar yang memang dari

awal ada meeting-nya, biasanya saya buat.

Kecuali kalau ad hoc yang kecil-kecil.

Karena biasanya kalau ad hoc itu harus

segera, karena dibutuhkan secepatnya. Nah

untuk itu biasanya tidak dilakukan secara

formal. Mungkin hanya lewat tiket, atau

lewat email. Tidak benar-benar formal yang

ada dokumentasi tertulis. Kalau yang besar

kan ada tanda tangan.”

-

Fully

Achieved

(93%)

Evo4.2.1

Apakah ada rencana-rencana untuk kegiatan

verifikasi dan validasi? Apakah kegiatan yang

sudah dijalankan didokumentasikan? Apakah

ada prosedurnya? Apakah ada template untuk

Lampiran D (J13-J17):

“Iya. Kebanyakan seperti itu. Kasusnya

banyak.”

“Kadang terencana kadang tidak.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)


231


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

membuat rencana verifikasi/validasi? Apakah

kegiatan ini dilakukan untuk setiap MR?

Evo4.2.2

Apakah tinjauan dan verifikasi/validasi

dilakukan setelah produk intermediate (produk

setengah jadi) dihasilkan?


“Iya. Kebanyakan seperti itu. Kasusnya

banyak.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo4.2.3 Apakah ada prosedur peninjauan aktivitas

pemeliharaan oleh pemasok/vendor?

Lampiran H (J37):

“Vendor akan menjelaskan seperti apa

langkah-langkah, tapi secara detail kita tidak

bisa mengetahuinya.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo4.2.4

Apakah pengujian (acceptance, functional,

performance, installation, UAT) sudah ada

prosedurnya?

Lampiran D (J23):

“Ini lebih ke test scenario kan? Itu

bagiannya Business Analyst. Tapi ada.”

Tidak ada

prosedur tertulis

untuk UAT.

Tidak ada artifak

pendukung.

Partially

Achieved

(33%)

Evo4.2.5 Apakah regression test dilakukan untuk tiap

modifikasi, termasuk koreksi?


“Secara formal tidak ada kewajiban tertulis

harus dilakukan, tapi biasanya saya

melakukannya untuk melihat oh ini masih

error apa nggak.”

“Biasanya pengujian berdasarkan apabila

bug yang kemarin, saya uji ulang.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo4.2.6

Apakah implementasi dilakukan dengan

persetujuan pelanggan/pengguna? Ada prosedur

terdokumentasi?


“Harus ada persetujuan.”

“Kalau untuk permintaan kecil nggak.

Tidak ada

prosedur

tertulisnya.

Partially

Achieved

(33%)



232


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Nggak tertulis.”

“Nggak ada prosedur yang mengharuskan

...”

Tidak ada artifak

pendukung.

Evo4.2.7 Apakah kegiatan modifikasi dirancang untuk

mengurangi interupsi kerja pengguna?

Lampiran D (J30):

“Iya seperti itu.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Evo4.2.8

Apakah maintenance engineer berpartisipasi

dalam acceptance test saat transisi akhir? Ada

prosedurnya (sesuai prosedurkah)?


“Tidak, tidak ada alasan untuk itu.”

“Iya oleh saya. Tapi developer tidak ikut.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)


yang diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Verification and Validation (Evo4).



233



Praktek : The software maintenance organization does not perform

verification and validation activities on the maintained software.

Sumber Lisan : Lampiran D (J1)

Artifak : Uraian Tugas System Analyst (Evo4.0.1 - System Analyst.pdf)


tidak dipenuhi. Praktek ini dilakukan oleh seorang System Analyst sebagai bagian

dari uraian tugasnya, yaitu melakukan pengujian sistem.



activities for verification and validation in a structured and

coordinated way.

Sumber Lisan : Lampiran D (J4-J9)

Artifak : -

Berdasarkan bukti lisan, saat ini praktek validasi dan verifikasi dilakukan secara

tidak terstruktur dan tidak terkoordinasi. Tidak ada prosedur formal untuk validasi

dan verifikasi. Jadi disimpulkan bahwa praktek ini tercapai sepenuhnya (Fully

Achieved).


Praktek : The verification and validation activities are documented,

known, and planned. The plans are documented according to a



Artifak : -


234


Berdasarkan bukti lisan, saat ini praktek validasi dan verifikasi tidak terencana

dan tidak memiliki prosedur dokumentasi. Jadi disimpulkan bahwa praktek ini



Praktek : Reviews and verification/validation are performed, selectively,

after the production of some key intermediate products.


Artifak : -


Mempertimbangkan posisi narasumber sebagai System Analyst, yang dalam uraian

tugasnya bertugas untuk melakukan pengujian sistem, dapat disimpulkan bahwa



Praktek : Supplier maintenance activities are selectively reviewed at given

steps.


Artifak : -

Berdasarkan bukti lisan, tidak ada peninjauan terhadap kegiatan pemeliharaan

vendor. Saat ini yang dilakukan hanya mendapatkan indikasi waktu pengerjaan.

Jadi disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).


Praktek : The acceptance test is performed according to a documented

procedure to show that the modified product conforms to and

meets the customer's requirements.



235


Artifak : -

Berdasarkan bukti lisan, sudah ada user acceptance test (UAT) yang dilakukan

oleh seksi Business Analyst. Kelemahan praktek ini adalah tidak ada prosedur

tertulis untuk melakukan UAT dan ditemukan artifak pendukung. Jadi

disimpulkan bahwa praktek ini tercapai sebagian besar (Partially Achieved).


Praktek : Regression tests are systematically and formally performed on

all parts of the software affected by modifications, including

corrections.


Artifak : -

Berdasarkan bukti lisan, saat ini praktek uji regresi (regression test) kadang-

kadang dilakukan sebagai inisiatif pribadi dari System Analyst. Tidak ada prosedur

tertulis yang mewajibkan aktivitas ini untuk semua bagian dari perangkat lunak

yang terpengaruh modifikasi dan koreksi Jadi disimpulkan bahwa praktek ini



Praktek : The coordination of the installation of the test on-site and the

software maintenance with the user are carried out according to

a documented procedure.


Artifak : -

Berdasarkan bukti lisan, saat melakukan instalasi maupun pengujian di produksi,

harus dengan persetujuan pengguna (module owner). Kekurangan praktek ini

adalah tidak ada prosedur tertulisnya, dan tidak ada artifak pendukung. Jadi dapat



236



Praktek : The practices surrounding the installation of software

modifications (including the installation documentation) are

designed to reduce interruptions of the daily work of the system.


Artifak : -

Berdasarkan bukti lisan, saat instalasi tidak dirancang untuk mengurangi interupsi

operasional bisnis. Praktek saat ini saat melakukan deployment maka SI mati dan

tidak bisa diakses dari semua cabang. Jadi dapat disimpulkan bahwa praktek ini


4.2.13.10 Praktek Evo4.2.8

Praktek : The maintenance engineer participates in acceptance tests

during the final transition of software from the subcontractor

and supplier, according to a documented procedure.


Artifak : -

Berdasarkan bukti lisan, saat melakukan UAT, tidak ada partisipasi dari

maintainer. Jadi dapat disimpulkan bahwa praktek ini tidak tercapai (Not

Achieved).

4.2.14 Configuration and Version Management (Sup1)

Tujuan utama dari KPA ini adalah untuk membuat hubungan antara produk-

produk setengah jadi yang berbeda-beda (different intermediate products) selama

perubahan. Jadi pemelihara dapat mengikuti progres perubahan mulai dari

permintaan awal, ke requirements, ke analisis dampak, ke detail rancangan, ke

pemrograman, ke pengujian, ke dokumentasi teknis, dan akhirnya, ke penggunaan

oleh sang pengguna sendiri. Aspek pertama dari konfigurasi disebut traceability.

Aspek lain dari manajemen konfigurasi adalah penggunaan perangkat lunak


237


pendukung untuk reservasi komponen perangkat lunak yang lagi dikerjakan.

Aktivitas ini memastikan tidak ada yang melakukan perubahan tanpa sadar akan

perubahan yang dibuat oleh rekan kerjanya. Pengembang dan pemelihara juga

membuat citra (image) dari perangkat lunak pada tiap langkah kritis dengan

menggunakan tool tersebut. Mereka selalu bisa mengembalikan ke citra ini jika

pekerjaannya rusak. Jadi bisa dibayangkan bahwa salinan untuk backup juga

merupakan citra dari konfigurasi perangkat lunak (April & Abran, 2008, hal. 120).




238


Tabel 4.14 Ringkasan Penilaian Praktek-praktek Sup1

Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Sup1.0.1 Apakah Departemen TI melakukan manajemen

konfigurasi?

Lampiran G (J192):

“Iya.” - No (100%)

Sup1.1.1

Apakah dilakukan secara terstruktur dan terkoordinasi?

Apakah maintainer konfigurasi sendiri berdasarkan

struktur direktori, tanpa bantuan tool untuk CM?


“Ada tempatnya, cuma

nggak ada yang taruh di

situ.”

Lampiran F (J4-J7):

“Disimpan tapi tidak

secara terstruktur. ... Jadi

tanpa version.”

“SVN tidak untuk

dokumentasi saat ini. ...

cuma punya BaliCamp

dulu.”

“Jadi apabila ada

perubahan-perubahan

tidak di-update di

dokumentasi itu.”

Dokumentasi SI tidak

dianggap sebagai

configurable item.

Program pembuatan

laporan tidak dianggap

sebagai configurable

item.

Tidak ada artifak

pendukung.

Partially

Achieved

(33%)

Sup1.2.1

Apakah MR didokumentasikan, diprioritisasi, dan

diotorisasi oleh pelanggan/pengguna sebelum

implementasi perubahan perangkat lunak?

(Tidak ditanyakan karena

praktek tingkat 1 tidak

tercapai)

-

Not

Achieved

(0%)

Sup1.2.2 Apakah ada rencana CM dari pengembang? Apakah

digunakan sebagai dasar kegiatan CM oleh pemelihara?


praktek tingkat 1 tidak -

Not

Achieved


239


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Apa tool yang digunakan? Apakah konfigurasi didapat

sebelum transisi akhir?

tercapai) (0%)

Sup1.2.3

Apakah maintainer menggunakan perangkat lunak

pendukung yang terotomatisasi untuk mendukung CM

dari perangkat lunak aplikasi versi produksinya?



tercapai)

-

Not

Achieved

(0%)

Sup1.2.4 Apakah maintainer menggunakan kendali CM untuk

source code perangkat lunak aplikasi?



tercapai)

-

Not

Achieved

(0%)

Sup1.2.5

Apakah ada manajemen dokumentasi di Departemen TI?

Apakah untuk tiap MR ada pencatatan untuk: kapan

dibuat, dimodifikasi, versi, arsip, penghapusan, dan

validasi?



tercapai)

-

Not

Achieved

(0%)

Sup1.2.6 Apakah ada prosedur terdokumentasi untuk modifikasi

elemen terkonfigurasi?



tercapai)

-

Not

Achieved

(0%)

Sup1.2.7

Apakah bisa dilacak (traceability) antara CR,

requirement, rancangan, source code, terhadap

integration test?



tercapai)

-

Not

Achieved

(0%)

Sup1.2.8

Apakah Departemen TI ada membuat laporan yang

terstandarisasi untuk urusan CM? Apakah ada

mekanisme untuk menyebarluaskan konfigurasi

terhadap pihak yang berkepentingan?



tercapai)

-

Not

Achieved

(0%)

Tabel 4.14 Ringkasan Penilaian Praktek-praktek Sup1 (sambungan)


240


Penjelasan dari setiap praktek-praktek di Tabel 4.14 di atas dijelaskan di subbab

4.2.14.1 sampai 4.2.14.2 untuk memaparkan kelemahan yang diidentifikasi dan

justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA

Configuration and Version Management (Sup1).

4.2.14.1 Praktek Sup1.0.1


software configuration management activities.


Artifak : -


ini sudah ada aktivitas manajemen konfigurasi perangkat lunak, khususnya untuk

kode sumber.


Praktek : The software maintenance organization unit does not perform

software configuration management activities in a structured

and coordinated manner.

Sumber Lisan : Lampiran G (J193-J194), Lampiran F (J4-J7)

Artifak : -

Berdasarkan bukti lisan, saat ini manajemen konfigurasi perangkat lunak hanya

dilakukan untuk kode sumber. Untuk dokumentasi perangkat lunak dan untuk

laporan-laporan yang bisa digunakan berulang-ulang oleh pengguna, tidak

dianggap sebagai configurable item. Selain itu tidak ada dukungan artifak untuk

praktek ini. Jadi dapat disimpulkan bahwa praktek ini hanya tercapai sebagian

(Partially Achieved). Berdasarkan pertimbangan ini, tidak diajukan pertanyaan-

pertanyaan untuk level 2 KPA ini.


241


4.2.15 Process, Service, and Software Quality Assurance (Sup2)

Tujuan dari KPA ini adalah untuk memberikan dukungan untuk penyampaian

(delivery) produk dan layanan berkualitas tinggi dengan cara memberikan para

pemeliharaan wewenang untuk angkat bicara dalam aplikasi proses, prosedur, dan

aturan-aturan yang digunakan dalam pekerjaan pemeliharaan sehari-hari. KPA ini

merinci praktek-praktek untuk memastikan proses-proses berstandar direncanakan

dan digunakan sepanjang penanganan permintaan (April & Abran, 2008, hal.

122).




242



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Sup2.0.1 Apakah Departemen TI melakukan kegiatan/proses penjaminan mutu

(quality assurance) yang independen?

Lampiran E (J3):

“Pernah dengar

tapi tidak tahu

secara detail.”

Lampiran G (J45-

J47, J197-J202):

“Belum.”

Lampiran I (J72-

J77):

“Audit belum.”

Praktek tidak

dilakukan. Yes (0%)

Sup2.1.1

Apakah kegiatan penjaminan mutu dilaksanakan secara informal? Apakah

satu seksi menjalankan penjaminan mutu secara terpisah dan tidak

terkoordinasi dengan seksi lain? Apakah kegiatan ini hanya dijalankan

setelah masalah terjadi? Apakah maintainer memiliki kualifikasi untuk

penjaminan mutu? Apakah ketidaksesuaian / ketidakpatuhan terhadap proses

didokumentasikan untuk tinjauan eksternal yang independen (independent

external review)?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.1

Apakah Departemen TI mendefinisikan tanggung jawab, otoritas, dan

hubungan antara individu-individu yang bertugas untuk mengatur,

mengeksekusi, dan verifikasi pekerjaan yang ada pengaruhnya terhadap

kualitas proses, layanan, dan perangkat lunak?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.2 Apakah Departemen TI membuat rencana penjaminan mutu? Apakah di (Tidak ditanyakan - Not


243


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

dalamnya termasuk proses/layanan perawatan perangkat lunak, dan

didokumentasikan, disetujui (oleh manajemen), dan dipantau?

karena praktek

tingkat 0 tidak

dilakukan)

Achieved

(0%)

Sup2.2.3 Apakah Departemen TI melaksanakan tinjauan kepatuhan independen

terhadap produk-produk kritis atau terhadap perubahan besar?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.4 Apakah Departemen TI melakukan kegiatan penjaminan mutu sesuai dengan

kriteria metodologi pemeliharaan perangkat lunak?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.5 Apakah Departemen TI diaudit untuk memastikan kepatuhannya terhadap

proses yang sudah didefinisikan dan diterima?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.6 Apakah audit CM produk dilakukan sesuai dengan prosedur?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.7 Apakah produk-produk dipelihara sesuai dengan prosedur yang

terdokumentasi? Apakah dicakup dalam penjaminan mutu?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.8 Apakah Departemen TI memantau kegiatan penjaminan mutu pemasok dan (Tidak ditanyakan - Not



244


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

pengembang? Apakah ada prosedur terdokumentasi? karena praktek

tingkat 0 tidak

dilakukan)

Achieved

(0%)

Sup2.2.9

Apakah ada tinjauan terhadap sampel dari produk pemeliharaan, untuk

diperiksa kepatuhan/kesesuaian terhadap requirement permintaan dari

pengguna/pelanggan?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.10 Apakah ada prosedur untuk menangani ketidaksesuaian/ketidakpatuhan

terhadap proses? Apakah ditangani secara lokal?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.11 Apakah hasil QA dimasukkan dalam laporan berkala yang dipresentasikan

terhadap manajemen pemeliharaan dan para maintainer?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.12 Apakah hasil tinjauan kepatuhan independen ditinjau secara berkala oleh

manajemen atas?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup2.2.13

Apakah maintainer bebas dan berwewenang untuk melaporkan masalah

kualitas? Biasanya dalam bentuk:

1. Mengambil tindakan untuk mencegah ketidaksesuaian.

2. Mengidentifikasi dan mencatat/merekam masalah kualitas.

3. Mendapatkan, merekomendasikan, dan menyediakan solusi menggunakan

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)



245


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

saluran komunikasi yang sudah ada.

4. Verifikasi implementasi solusi.

5. Mengelola penanganan, delivery, dan instalasi dari produk yang tidak

sesuai dengan proses, sampai elemen yang tidak sesuai berhasil dikoreksi.

Penjelasan dari setiap praktek-praktek di Tabel 4.15 di atas dijelaskan di subbab 4.2.15.1 untuk memaparkan kelemahan yang diidentifikasi

dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Process, Service, and Software Quality Assurance (Sup2).



246



Praktek : Quality assurance is not performed by the software maintenance

organization.

Sumber Lisan : Lampiran E (J3), Lampiran G (J45-J47, J197-J202), Lampiran I

(J72-J77)

Artifak : -

Berdasarkan bukti lisan, pernyataan negatif dari praktek ini terpenuhi. Saat ini

belum ada aktivitas penjaminan mutu yang dilakukan di Departemen TI.

4.2.16 Maintenance Measurement and Analysis (Sup3)

Tujuan dari KPA ini adalah untuk memastikan semua kebutuhan informasi

pemeliharaan perangkat lunak didefinisikan, dan untuk menentukan apa ukuran ,

teknik analisis, aktivitas pengumpulan data, gudang informasi (repository), dan

laporan-laporan yang akan digunakan oleh karyawan pemeliharaan perangkat

lunak, pelanggan, dan manajer (April & Abran, 2008, hal. 123).




247



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Sup3.0.1

Apakah Departemen TI mengukur dan menganalisis proses, layanan,

perangkat lunak, atau personil pemeliharaannya? Apakah ada

pelacakan untuk perkiraan waktu pengerjaan, sasaran waktu

pengerjaan, atau waktu pengerjaan sebenarnya?

Lampiran G (J203-

J205):

“Estimasi sekarang kan

dilakukan.”

- No (100%)

Sup3.1.1

Apakah kegiatan pengukuran dan analisis untuk pemeliharaan

perangkat lunak dijalankan secara individu (oleh manajer

pemeliharaan atau kepala seksi yang bertugas untuk pemeliharaan)?

Atau kegiatan pengukuran sudah ada, tapi tidak untuk pemeliharaan?


“Resmi. Iya, kalau user-

nya rajin, kalau sudah

lewat estimasi, ditagih.”

“Nggak. Itu cuma untuk

... informal aja. Kalau

CR sih biasanya

ditanya.”

Tidak ada

artifak

pendukung.

Largely

Achieved

(68%)

Sup3.2.1

Apakah maintainer sudah menentukan ukuran-ukuran dasar

operasional untuk memenuhi tujuan pengukuran pemeliharaan

perangkat lunak?

Lampiran G (J210-

J212)

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Sup3.2.2 Apakah maintainer bisa membuat dan menganalisis laporan untuk

kegiatan pemeliharaan perangkat lunak? Lampiran G (J213)

Praktek tidak

dilakukan.

Not

Achieved

(0%)


yang diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Maintenance Measurement and Analysis

(Sup3).


248



Praktek : The maintenance organization does not measure

process/services, software or personnel.


Artifak : -


ini sudah ada aktivitas pengukuran terhadap proses atau layanan, perangkat lunak,

atau personil.


Praktek : Measurement and analysis, in the maintenance organization is

performed individually by each manager.


Artifak : -

Berdasarkan bukti lisan, saat ini kegiatan estimasi yang merupakan salah satu

wujud dari pengukuran dan analisis sudah dilakukan secara resmi untuk CR

(change request), dan secara tidak resmi untuk permintaan selain CR. Kekurangan

praktek ini adalah tidak didukung bukti artifak. Jadi dapat disimpulkan bahwa

praktek ini sudah tercapai sebagian besar (Largely Achieved).


Praktek : The maintainer has defined basic operational measurements

that meet software maintenance measurement objectives.


Artifak : -


249


Berdasarkan bukti lisan, belum ada ukuran operasional dasar untuk pemeliharaan.

Belum ada survei, observasi kualitatif, benchmark internal, maupun data profiling

aplikasi. Jadi disimpulkan bahwa praktek ini tidak tercapai (Not Achieved).


Praktek : The maintainer performs, analyzes and produces reports to

address specific requests.


Artifak : -

Berdasarkan bukti lisan, para pemelihara belum bisa menganalisis dan

menghasilkan laporan kegiatan spesifik pemeliharaan perangkat lunak. Jadi


4.2.17 Causal Analysis and Problem Resolution (Sup4)

Tujuan dari KPA ini adalah untuk mengidentifikasi prioritas dan memberikan

analisis perbaikan dan rekomendasi. Tujuan yang dimaksud adalah untuk

mengidentifikasi penyebab kegagalan (failure) dan untuk mengeliminasinya.

Meningkatkan kualitas juga termasuk tujuan (April & Abran, 2008, hal. 125).




250



Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Sup4.0.1 Apakah Departemen TI paham akan perlunya proses analisis

penyebab dan penyelesaian masalah?

Lampiran G

(J215-J216):

“Ada lah pasti

kalau itu.”

- No (100%)

Sup4.1.1

Apakah Departemen TI melakukan kegiatan mencari akar

permasalahan untuk memecahkan permasalahan secara permanen?

Apakah Departemen TI sadar bahwa kegiatan ini merupakan proses

yang dilakukan antar seksi? Apakah kegiatan ini dilakukan atas

inisiatif personil, dan bukan merupakan kegiatan yang diperintahkan

oleh manajemen Departemen TI? Apakah jika permasalahan dan

akar permasalahan berhasil diidentifikasi, maka didokumentasikan

dan disebar ke pihak yang berkepentingan?

Lampiran G

(J215-J226):

“”

Tidak ada prosedur

untuk analisis

penyebab masalah

dan resolusi masalah.

Partially

Achieved

(33%)

Sup4.2.1

Apakah Departemen TI mendokumentasikan proses analisis

penyebab dan penyelesaian masalah? Apakah antar muka masalah

dengan seksi/organisasi lain diidentifikasi? Apakah prosesnya

berbeda-beda antar seksi?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup4.2.2

Apakah manajemen menganalisis data kualitas, pelanggan/pengguna,

dan kinerja secara reguler untuk mengidentifikasi dan menganalisis

penyebab masalah?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)

Sup4.2.3

Apakah manajer tingkat atas menganalisis hasil dari survei (misalnya

kepuasan maintainer) dan membuat rencana tindakan berdasarkan

hasil analisis tersebut? Apakah hasil analisis dan rencana tindakan

tersebut dikomunikasikan kembali ke personil yang terkena

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)


251


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

dampaknya?

Sup4.2.4

Apakah Departemen TI melakukan analisis proses, dan laporannya

dibuat dan didistribusikan ke kelompok-kelompok yang

berkepentingan?

(Tidak ditanyakan

karena praktek

tingkat 0 tidak

dilakukan)

-

Not

Achieved

(0%)


yang diidentifikasi dan justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Causal Analysis and Problem Resolution

(Sup4).



252



Praktek : The maintenance organization does not recognize the need for a

problem resolution and causal analysis process.


Artifak : -


ini sudah ada perintah untuk mencari akar permasalahan dengan tujuan untuk

mengeliminasinya.


Praktek : The maintenance organization recognizes the need to have a

problem resolution and causal analysis process.


Artifak : -

Berdasarkan bukti lisan, saat ini sudah ada perintah untuk mencari akar

permasalahan tapi tidak ada resolusi untuk mengeliminasi akar masalah. Praktek

yang dilakukan baru berupa mengidentifikasi data yang bermasalah dan untuk

mengatasinya dilakukan dengan koreksi data. Kelemahan lainnya adalah tidak ada

prosedur untuk analisis penyebab masalah dan resolusi masalah. Jadi disimpulkan

bahwa praktek ini tercapai sebagian (Partially Achieved). Dengan pertimbangan

hanya tercapainya sebagian praktek ini, maka untuk level 2 tidak diajukan

penilaian.

4.2.18 Software Rejuvenation, Migration, and Retirement (Sup5)

Tujuan dari KPA ini adalah untuk agar penggunaan teknik-teknik peremajaan saat

diperlukan sudah dikonfirmasikan dan disetujui dengan perencanaan

pemeliharaan: (a) redokumentasi perangkat lunak, (b) restrukturisasi perangkat

lunak, atau (c) melakukan reverse engineering perangkat lunak (April & Abran,

2008, hal. 126).


253


Berikut adalah pertanyaan yang diajukan kepada narasumber beserta respons mereka yang berkaitan dengan KPA ini:


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Sup5.0.1 Apakah Departemen TI melakukan aktivitas peremajaan terhadap

perangkat lunak yang dipeliharanya?


“Ada.” - No (100%)

Sup5.1.1

Apakah peremajaan dilakukan secara informal, bersamaan dengan

suatu perubahan (MR atau PR), tanpa perencanaan sebelumnya?

Apakah atas inisiatif individu? Apakah diakui oleh pelanggan /

pengguna?

Lampiran G (J236):

“Tidak ada sih. Contoh

memecah tabel juga tidak

ada, cuma memperbaiki.

Dan informal.”

Tidak ada

artifak

pendukung.

Largely

Achieved

(68%)

Sup5.1.2

Apakah dalam memensiunkan (retirement) suatu fitur atau aplikasi,

komponen perangkat lunak/infrastrukturnya dibiarkan saja? Hanya

mencegah eksekusinya?

Lampiran G (J231-J232,

J251):

“Nggak, sih. Dihapus.”

Tidak ada

artifak

pendukung.

Largely

Achieved

(68%)

Sup5.2.1 Apakah redokumentasi dilakukan? Apakah hanya untuk komponen

yang berubah / dikoreksi?

Lampiran G (J235):

“Belum.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Sup5.2.2 Apakah restrukturisasi produk yang dipelihara dilakukan? Apakah

hanya untuk komponen yang berubah / dikoreksi?


“Tidak ada sih. Contoh

memecah tabel juga tidak

ada, cuma memperbaiki.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Sup5.2.3

Apakah reverse engineering produk yang dipelihara dilakukan?

Apakah hanya untuk komponen yang berubah / dikoreksi? Apakah

maintainer mengekstrak business rules dari perubahan-perubahan /

koreksi-koreksi, untuk membantu pelanggan mengerti lebih dalam

tentang bagaimana perangkat lunak berfungsi?

Lampiran G (J238, J240):

“Nggak, cuma ngetes

doang.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)


254


Nomor

Praktek

Pointer Pertanyaan


Nilai

(Rating)

Sup5.2.4

Apakah rekayasa ulang (reengineering) produk yang dipelihara

dilakukan? Apakah hanya untuk komponen yang berubah /

dikoreksi?


“Sudah ada ancang-

ancang ke situ.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Sup5.2.5

Apakah Departemen TI membuat rencana migrasi dan

menginformasikannya pada pelanggan/pengguna untuk

mendapatkan persetujuan mereka?

Apakah maintainer sudah mempertimbangkan operasi paralel?

Apakah ada pelatihan untuk pengguna dalam periode transisi?

Apakah produk lama dan baru diarsipkan (termasuk source code,

dokumentasi, dll.)? Apakah maintainer melakukan revisi setelah

sistem baru online, dengan tujuan membuat data sistem lama bisa

diakses, aman (secure), dan terlindung dalam sistem yang baru?

Lampiran G (J248):

“Nggak ada itu, cuma

lempar-lemparan data

doang, di-replicate.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Sup5.2.6 Apakah dalam migrasi platform menggunakan tool? Apakah dapat

mengotomatisasi proses (biarpun hanya sebagian)?

Lampiran G (J248):

“Nggak ada itu, cuma

lempar-lemparan data

doang, di-replicate.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)

Sup5.2.7

Apakah Departemen TI membuat rencana untuk memensiunkan

perangkat lunak (software retirement plan)? Apakah rencana

tersebut dikomunikasikan kepada pengguna/pelanggan untuk

mendapatkan persetujuan mereka?


“Wah, itu belum ada.”

“Belum. Source code-nya

nggak dicabut, tapi di

menu user-nya tidak bisa

di akses.”

Praktek tidak

dilakukan.

Not

Achieved

(0%)



255


Penjelasan dari setiap praktek-praktek di Tabel 4.18 di atas dijelaskan di subbab

4.2.18.1 sampai 4.2.18.10 untuk memaparkan kelemahan yang diidentifikasi dan

justifikasi pemberian nilai (rating) bagi praktek-praktek dalam KPA Software

Rejuvenation, Migration, and Retirement (Sup5).



rejuvenation activities on the maintained software.


Artifak : -


ini sudah ada kegiatan peremajaan perangkat lunak secara informal.


Praktek : In the software maintenance organization, rejuvenation is

performed informally, during a specific change, without any

prior planning.


Artifak : -

Berdasarkan bukti lisan, saat ini sudah ada kegiatan peremajaan yang dilakukan

secara tidak formal, tidak terjadwal, yang berarti tidak terencana. Kekurangan

praktek ini adalah tidak ada dukungan artifak. Jadi dapat disimpulkan bahwa



Praktek : Retirement of a feature or application is carried out by leaving

all software component infrastructures in place and preventing

its execution.

Sumber Lisan : Lampiran G (J231-J232, J251)


256


Artifak : -

Berdasarkan bukti lisan, saat ini jika ada fitur yang perlu dipensiunkan

(retirement) maka praktek yang dilakukan adalah membuat menu di aplikasi

menjadi tidak muncul lagi, sedangkan kode programnya tidak diubah. Kelemahan

dari praktek ini adalah tidak ada dukungan artifak. Jadi dapat disimpulkan bahwa



Praktek : Maintained product redocumentation is only performed for

components subjected to a change or correction.


Artifak : -

Berdasarkan bukti lisan, saat ini tidak ada aktivitas redokumentasi perangkat



Praktek : Maintained product restructuring is only performed for

components subjected to a change or correction.


Artifak : -

Berdasarkan bukti lisan, saat ini tidak ada aktivitas restrukturisasi perangkat



Praktek : Maintained product reverse engineering is only performed for

components subjected to a change, a correction, or an

operational support request.

Sumber Lisan : Lampiran G (J238, J240)


257


Artifak : -

Berdasarkan bukti lisan, saat ini tidak ada aktivitas reverse engineering perangkat



Praktek : Maintained product reengineering is only performed for

components subjected to a change, a correction, or an

operational support request.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada aktivitas rekayasa ulang

(reengineering) perangkat lunak. Jadi disimpulkan bahwa praktek ini tidak



Praktek : The maintenance organization develops a migration plan and

communicates it to the customers for approval.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada rencana migrasi perangkat lunak. Jadi



Praktek : Software tools are used to support migration from one

technological platform to another.


Artifak : -


258


Berdasarkan bukti lisan, karena saat ini belum ada rencana migrasi perangkat

lunak, berarti belum ada rencana penggunaan tool untuk dukungan migrasi. Jadi


4.2.18.10 Praktek Sup5.2.7

Praktek : The maintenance organization develops a software retirement

plan and communicates it to the customers for approval.


Artifak : -

Berdasarkan bukti lisan, saat ini belum ada pengembangan rencana untuk

memensiunkan perangkat lunak, termasuk untuk rencana untuk memensiunkan

fitur. Praktek saat ini adalah dengan mencabut akses ke menu. Jadi disimpulkan


4.3 Ringkasan Hasil Kajian

Bagian ini menyajikan tingkat kematangan berdasarkan penjabaran hasil kajian di

atas.

4.3.1 Tingkat Kematangan 0

Tabel berikut menyajikan ringkasan pencapaian praktek-praktek tingkat 0 untuk

tiap KPA, dengan menggunakan format tabel dari (Paquette, April, & Abran,

2006):

Tabel 4.19 Evaluasi Pencapaian Tingkat Kematangan 0

KPA Tabel

Referensi

Praktek

Tingkat 0

Evaluasi

Tingkat 0 %

Maintenance process focus Tabel 4.1 Pro1.0.1 No 100

Maintenance process/service

definition Tabel 4.2 Pro2.0.1 No 100

Maintenance training Tabel 4.3 Pro3.0.1 Yes 0

Maintenance process

performance Tabel 4.4 Pro4.0.1 No 100

Maintenance innovation and

deployment Tabel 4.5

Pro5.0.1 Yes 0

Pro5.0.2 No 100


259


KPA Tabel

Referensi

Praktek

Tingkat 0

Evaluasi

Tingkat 0 %

Pro5.0.3 No 100

Rating domain proses Process Management 71,43

Event/request management Tabel 4.6 Pro1.0.1 No 100

Maintenance planning Tabel 4.7 Pro2.0.1 No 100

Requests/software monitoring and

control Tabel 4.8 Pro3.0.1 No 100

SLA and supplier agreements

management Tabel 4.9 Pro4.0.1 No 100

Rating domain proses Event/Request Management 100

Predelivery and transition

services Tabel 4.10 Req1.0.1 No 100

Operational support services Tabel 4.11 Req2.0.1 No 100

Software evolution and correction

services Tabel 4.12 Req3.0.1 No 100

Verification and validation Tabel 4.13 Req4.0.1 No 100

Rating domain proses Evolution Engineering 100

Configuration and version

management Tabel 4.14 Evo1.0.1 No 100

Process, service and software

quality assurance Tabel 4.15 Evo2.0.1 Yes 0

Maintenance measurement and

analysis Tabel 4.16 Evo3.0.1 No 100

Causal analysis and problem

resolution Tabel 4.17 Evo4.0.1 No 100

Software rejuvenation, migration

and retirement Tabel 4.18 Evo5.0.1 No 100

Rating domain proses Support to Evolution Engineering 80

Rating tingkat kematangan 0 87,86

Tabel 4.19 di atas menjabarkan penilaian untuk tiap-tiap praktek tingkat 0 di

Departemen TI PT XYZ. Kolom Praktek Tingkat 0 berisi nomor praktek untuk

tiap KPA yang dinilai. Kolom Evaluasi Tingkat 0 berisi penilaian berdasarkan

S3mAssess. Kolom “%” berisi nilai persentase rating (pencapaian) berdasarkan

kolom Evaluasi Tingkat 0 sesuai dengan S3mAssess.

Metode S3mAssess memberikan cara evaluasi bagi seorang penilai yang tidak

berpengalaman. Pernyataan praktek tingkat 0 adalah dalam bentuk negatif.

Pernyataan praktek ini mencoba mengonfirmasi absennya proses pemeliharaan

perangkat lunak tertentu. Misalnya pernyataan “organisasi pemelihara perangkat

Tabel 4.19 Evaluasi Pencapaian Tingkat Kematangan 0 (sambungan)


260


lunak tidak mengelola permintaan pengguna,” jawaban “Ya” (Yes dalam tabel di

atas) akan mendapatkan rating 0%, sedangkan jawaban “Tidak” (No dalam tabel

di atas) akan mendapatkan rating 100% (Zarour, Alarifi, Abran, & Desharnais,

2012; Paquette, April, & Abran, 2006).

Cara perhitungan rating domain proses adalah dengan menghitung rata-rata rating

dari semua praktek di dalamnya. Cara perhitungan total rating tingkat kematangan

0 adalah dengan menghitung rata-rata rating dari semua domain proses. Dapat

dilihat bahwa rating tingkat kematangan 0 untuk proses pemeliharaan perangkat

lunak di Departemen TI PT XYZ adalah 87,86%. Karena nilai rating melewati

86%, maka berarti tingkat kematangan ini sudah tercapai sepenuhnya.


Tabel berikut menyajikan ringkasan pencapaian praktek-praktek tingkat 1 untuk

tiap KPA, dengan menggunakan format tabel dari (Paquette, April, & Abran,

2006):


KPA Tabel

Referensi

Praktek

Tingkat 1

Evaluasi

Tingkat 1 %

Maintenance process focus Tabel 4.1 Pro1.1.1 L 68

Pro1.1.2 P 33


definition Tabel 4.2

Pro2.1.1 P 33

Pro2.1.2 F 93

Maintenance training Tabel 4.3

Pro3.1.1 N 0

Pro3.1.2 N 0

Pro3.1.3 N 0

Maintenance process

performance Tabel 4.4

Pro4.1.1 L 68

Pro4.1.2 N 0



Pro5.1.1 P 33

Pro5.1.2 L 68

Pro5.1.3 L 68


Event/request management Tabel 4.6 Req1.1.1 F 93

Req1.1.2 F 93

Maintenance planning Tabel 4.7

Req2.1.1 F 93

Req2.1.2 F 93

Req2.1.3 F 93

Requests/software monitoring and Tabel 4.8 Req3.1.1 L 68


261


KPA Tabel

Referensi

Praktek

Tingkat 1

Evaluasi

Tingkat 1 %

control


management Tabel 4.9 Req4.1.1 F 93

Rating domain proses Event/Request Management 89,43


services Tabel 4.10 Evo1.1.1 P 33

Operational support services Tabel 4.11 Evo2.1.1 F 93


services Tabel 4.12 Evo3.1.1 F 93

Verification and validation Tabel 4.13 Evo4.1.1 F 93

Rating domain proses Evolution Engineering 78


management Tabel 4.14 Sup1.1.1 P 33


quality assurance Tabel 4.15 Sup2.1.1 N 0


analysis Tabel 4.16 Sup3.1.1 L 68


resolution Tabel 4.17 Sup4.1.1 P 33


and retirement Tabel 4.18

Sup5.1.1 L 68

Sup5.1.2 L 68




Departemen TI PT XYZ. Kolom Praktek Tingkat 1 berisi nomor praktek untuk

tiap KPA yang dinilai. Kolom Evaluasi Tingkat 1 berisi penilaian berdasarkan

S3mAssess. Kolom “%” berisi nilai persentase rating (pencapaian) berdasarkan

kolom Evaluasi Tingkat 1 sesuai dengan S3mAssess.

Metode S3mAssess memberikan cara evaluasi bagi seorang penilai yang tidak

berpengalaman. Dalam penilaian tingkat 1 dan 2, untuk memfasilitasi perhitungan

persentase dan untuk mengurangi kemungkinan subjektivitas karena kurangnya

pengalaman si penilai (assessor), nilai 0% diberikan jika praktek tidak dilakukan

(Not Achieved, N dalam tabel). Nilai 33% diberikan jika praktek dilakukan

sebagian (Partially Achieved, P dalam tabel). Nilai 68% diberikan jika praktek

dilakukan sebagian besar (Largely Achieved, L dalam tabel). Nilai 93% diberikan



262


jika praktek dilakukan sepenuhnya (Fully Achieved, F dalam tabel) (Zarour,

Alarifi, Abran, & Desharnais, 2012; Paquette, April, & Abran, 2006).

Cara perhitungan rating domain proses dan total rating tingkat kematangan 1

adalah sama dengan cara perhitungan tingkat 0. Dapat dilihat bahwa rating tingkat

kematangan 1 untuk proses pemeliharaan perangkat lunak di Departemen TI PT

XYZ adalah 64,96%. Karena nilai rating di bawah 86%, maka berarti tingkat

kematangan ini tidak sepenuhnya tercapai, melainkan baru tercapai sebagian

besar.


Biarpun tingkat kematangan proses pemeliharaan perangkat lunak di Departemen

TI PT XYZ belum memenuhi sepenuhnya tingkat kematangan 1, informasi

mengenai pencapaian praktek-praktek di tingkat 2 tetap berguna untuk keperluan

perbaikan proses. Tabel berikut menyajikan ringkasan pencapaian praktek-praktek

tingkat 2 untuk tiap KPA, dengan menggunakan format tabel dari (Paquette,

April, & Abran, 2006):


KPA Tabel

Referensi

Praktek

Tingkat 2

Evaluasi

Tingkat 2 %

Maintenance process focus Tabel 4.1

Pro1.2.1 N 0

Pro1.2.2 N 0

Pro1.2.3 N 0

Pro1.2.4 N 0

Pro1.2.5 N 0

Pro1.2.6 L 68

Pro1.2.7 N 0

Pro1.2.8 N 0

Pro1.2.9 F 93

Pro1.2.10 N 0

Pro1.2.11 P 33


definition Tabel 4.2

Pro2.2.1 N 0

Pro2.2.2 N 0

Pro2.2.3 L 68

Pro2.2.4 N 0

Maintenance training Tabel 4.3

Pro3.2.1 N 0

Pro3.2.2 N 0

Pro3.2.3 N 0


263


KPA Tabel

Referensi

Praktek

Tingkat 2

Evaluasi

Tingkat 2 %

Pro3.2.4 N 0

Pro3.2.5 N 0

Pro3.2.6 N 0

Pro3.2.7 N 0

Pro3.2.8 N 0

Pro3.2.9 N 0

Pro3.2.10 N 0

Pro3.2.11 N 0

Pro3.2.12 N 0

Pro3.2.13 N 0

Maintenance process

performance Tabel 4.4

Pro4.2.1 P 33

Pro4.2.2 N 0

Pro4.2.3 F 93



Pro5.2.1 P 33

Pro5.2.2 N 0

Pro5.2.3 N 0


Event/request management Tabel 4.6

Req1.2.1 L 68

Req1.2.2 F 93

Req1.2.3 L 68

Req1.2.4 N 0

Maintenance planning Tabel 4.7

Req2.2.1 P 33

Req2.2.2 L 68

Req2.2.3 N 0

Req2.2.4 N 0

Req2.2.5 N 0

Req2.2.6 N 0

Req2.2.7 N 0

Req2.2.8 N 0

Req2.2.9 P 33

Req2.2.10 N 0

Req2.2.11 N 0

Req2.2.12 N 0

Req2.2.13 P 33

Req2.2.14 N 0

Req2.2.15 N 0

Req2.2.16 N 0

Req2.2.17 F 93

Req2.2.18 N 0

Req2.2.19 N 0

Req2.2.20 N 0

Requests/software monitoring and

control Tabel 4.8

Req3.2.1 P 33

Req3.2.2 L 68



264


KPA Tabel

Referensi

Praktek

Tingkat 2

Evaluasi

Tingkat 2 %

Req3.2.3 N 0

Req3.2.4 F 93

Req3.2.5 L 68

Req3.2.6 P 33


management Tabel 4.9

Req4.2.1 L 68

Req4.2.2 P 33

Req4.2.3 L 68

Req4.2.4 N 0

Req4.2.5 F 93

Req4.2.6 N 0

Req4.2.7 P 33

Req4.2.8 N 0

Req4.2.9 N 0

Req4.2.10 N 0

Req4.2.11 N 0

Req4.2.12 N 0

Req4.2.13 F 93

Rating domain proses Event/Request Management 27,26


services Tabel 4.10

Evo1.2.1 N 0

Evo1.2.2 N 0

Evo1.2.3 N 0

Evo1.2.4 L 68

Evo1.2.5 L 68

Evo1.2.6 N 0

Evo1.2.7 N 0

Evo1.2.8 N 0

Evo1.2.9 N 0

Evo1.2.10 P 33

Evo1.2.11 P 33

Operational support services Tabel 4.11

Evo2.2.1 L 68

Evo2.2.2 F 93

Evo2.2.3 N 0

Evo2.2.4 N 0

Evo2.2.5 N 0

Evo2.2.6 F 93


services Tabel 4.12

Evo3.2.1 P 33

Evo3.2.2 L 68

Evo3.2.3 P 33

Evo3.2.4 P 33

Evo3.2.5 L 68

Evo3.2.6 N 0

Evo3.2.7 N 0

Evo3.2.8 N 0



265


KPA Tabel

Referensi

Praktek

Tingkat 2

Evaluasi

Tingkat 2 %

Evo3.2.9 N 0

Evo3.2.10 N 0

Evo3.2.11 P 33

Verification and validation Tabel 4.13

Evo4.2.1 N 0

Evo4.2.2 N 0

Evo4.2.3 N 0

Evo4.2.4 P 33

Evo4.2.5 N 0

Evo4.2.6 P 33

Evo4.2.7 N 0

Evo4.2.8 N 0

Rating domain proses Evolution Engineering 21,94


management Tabel 4.14

Sup1.2.1 N 0

Sup1.2.2 N 0

Sup1.2.3 N 0

Sup1.2.4 N 0

Sup1.2.5 N 0

Sup1.2.6 N 0

Sup1.2.7 N 0

Sup1.2.8 N 0


quality assurance Tabel 4.15

Sup2.2.1 N 0

Sup2.2.2 N 0

Sup2.2.3 N 0

Sup2.2.4 N 0

Sup2.2.5 N 0

Sup2.2.6 N 0

Sup2.2.7 N 0

Sup2.2.8 N 0

Sup2.2.9 N 0

Sup2.2.10 N 0

Sup2.2.11 N 0

Sup2.2.12 N 0

Sup2.2.13 N 0


analysis Tabel 4.16

Sup3.2.1 N 0

Sup3.2.2 N 0


resolution Tabel 4.17

Sup4.2.1 N 0

Sup4.2.2 N 0

Sup4.2.3 N 0

Sup4.2.4 N 0


and retirement Tabel 4.18

Sup5.2.1 N 0

Sup5.2.2 N 0

Sup5.2.3 N 0

Sup5.2.4 N 0

Tabel 4.21 Evaluasi Pencapaian Tingkat Kematangan 2 (sambungan) Tabel 4.21 Evaluasi Pencapaian Tingkat Kematangan 2 (sambungan)


266


KPA Tabel

Referensi

Praktek

Tingkat 2

Evaluasi

Tingkat 2 %

Sup5.2.5 N 0

Sup5.2.6 N 0

Sup5.2.7 N 0




Departemen TI PT XYZ. Penjelasan kolom-kolom, pemberian nilai huruf dan

persentase rating tingkat 2 sudah dijelaskan di subbab 4.3.2 (Tingkat Kematangan

1). Cara perhitungan rating domain proses dan total rating tingkat kematangan 2

adalah sama dengan cara perhitungan tingkat 0 dan 1.

Dapat dilihat bahwa rating tingkat kematangan 2 untuk proses pemeliharaan

perangkat lunak di Departemen TI PT XYZ adalah 15,4%. Hal ini berarti tujuan

tingkat kematangan 2 tidak tercapai.

Jadi untuk pertanyaan penelitian yang pertama: “Bagaimana kondisi

kematangan proses pemeliharaan perangkat lunak di PT XYZ?” jawabannya

adalah saat ini proses pemeliharaan perangkat lunak di Departemen TI PT XYZ

berada di tingkat kematangan 0. Menurut Paquette, April, & Abran (2006) hal ini

berarti penerapan proses masih belum konsisten, tidak terkendali, dan akan

berdampak pada kualitas layanan kepada pelanggan.




BAB 5

REKOMENDASI PERBAIKAN PROSES PEMELIHARAAN

PERANGKAT LUNAK

Bab ini menjelaskan rekomendasi perbaikan proses pemeliharaan perangkat lunak

yang disusun berdasarkan hasil kajian dari Bab 4. Model acuan dalam perbaikan

proses pemeliharaan perangkat lunak di Departemen TI PT XYZ adalah model

IDEAL. Berikut adalah lima fase dalam model IDEAL yang dilaksanakan dalam

karya akhir ini:

5.1 Fase Initiating

Ini merupakan langkah awal dalam model IDEAL. Dalam fase ini, manajemen

senior dari organisasi pertama-tama memahami kebutuhan akan SPI, berkomitmen

terhadap program SPI, dan mendefinisikan konteks SPI (McFeely, 1996). Dalam

karya akhir ini, organisasi sudah disadarkan akan kebutuhan SPI di subbab 1.2.3

(Identifikasi Masalah).

5.2 Fase Diagnosing

Organisasi harus memahami baseline proses perangkat lunak saat ini agar dapat

mengembangkan rencana yang akan mencapai perubahan-perubahan bisnis yang

ditentukan dalam tujuan SPI organisasi. Aktivitas menentukan baseline yang

dilakukan di fase ini akan menyediakan informasi untuk proses perencanaan dan

prioritisasi SPI (McFeely, 1996).

Dalam karya akhir ini, fase ini sudah dilakukan di subbab 4.2 (Penjabaran Hasil

Kajian). Tingkat kematangan yang sudah tercapai adalah tingkat 0. Sesuai dengan

subbab 3.1 (Rancangan Penelitian), maka rekomendasi yang akan diberikan

adalah satu tingkat di atasnya. Berikut adalah daftar KPA yang tidak memenuhi

rating 86% untuk tingkat kematangan 1:


268


Gambar 5.1 Kesenjangan Rating KPA Saat Ini dan Target untuk Tingkat

Kematangan 1

Di Gambar 5.1 dapat dilihat bahwa rating target untuk setiap KPA adalah 93%

untuk praktek-praktek tingkat kematangan 1. Nilai target bukan 100% karena

menggunakan target praktek-praktek adalah tercapai secara penuh (Fully

Achieved) yang nilai rating-nya adalah 93%. Jadi pada dasarnya rekomendasi

yang dibuat perlu memenuhi semua praktek-praktek untuk masing-masing KPA

pada tingkat kematangan 1. Tabel di bawah ini menunjukkan kondisi pencapaian

praktek-praktek tingkat 1 untuk KPA terpilih, dan jumlah kelemahannya:

Berikut adalah daftar praktek-praktek tingkat kematangan 1 yang tidak tercapai

sepenuhnya (Fully Achieved):


Sepenuhnya

Nomor

Praktek

Teks Praktek


Evaluasi

Tingkat 1 %

Pro1.1.1 Within the software maintenance organization,

improvement is carried out in an informal way. L 68

Pro1.1.2

Some individual improvement initiatives aim mostly

at improving technical aspects of software

maintenance processes.

P 33

Pro2.1.1 The maintenance processes/services are informal

and based on the experience of individuals. P 33

Pro3.1.1 Technical training in the software maintenance N 0

50,5

63

0

34

56,33

68

33 33

0

68

33

68

86 86 86 86 86 86 86 86 86 86 86 86

0

20

40

60

80

100

Pro1 Pro2 Pro3 Pro4 Pro5 Req3 Evo1 Sup1 Sup2 Sup3 Sup4 Sup5

Rating (%) Target (%)


269


Nomor

Praktek

Teks Praktek


Evaluasi

Tingkat 1 %

organization is provided when there is an urgent

need.

Pro3.1.2

Individual training initiatives are aimed mainly at

the technical aspects of software maintenance and

the products they support. A pairing process

appears where a senior staff member is assigned to

a junior employee as a mentor and to answer his or

her questions.

N 0

Pro3.1.3

The training plans for new engineers address

generic topics about management, processes, and

software maintenance activities.

N 0

Pro4.1.1

Some initiatives for measuring process, services, or

products are carried out by individuals who have an

interest in measurement.

L 68

Pro4.1.2 Some qualitative measures of maintenance

processes, services, and products are collected. N 0

Pro5.1.1

The maintenance organization informally evaluates

the benefits of its improvement and innovation

projects.

P 33

Pro5.1.2

Individual initiatives for improvement and

innovation target mainly the technical aspects of

software maintenance.

L 68

Pro5.1.3

Assessments of new processes, technologies,

methodologies, and tools for maintenance are

performed informally.

L 68

Req3.1.1 The software maintenance service/product tracking

and monitoring is carried out informally. L 68

Evo1.1.1

Pre-delivery and transition, within the software

maintenance organization, is carried out in an

informal way.

P 33

Sup1.1.1

The software maintenance organization unit does

not perform software configuration management

activities in a structured and coordinated manner.

P 33

Sup2.1.1 The maintenance organization performs quality

assurance activities informally. N 0

Sup3.1.1

Measurement and analysis, in the maintenance

organization is performed individually by each

manager.

L 68

Sup4.1.1

The maintenance organization recognizes the need

to have a problem resolution and causal analysis

process.

P 33

Sup5.1.1 In the software maintenance organization, L 68


Sepenuhnya (sambungan)


270


Nomor

Praktek

Teks Praktek


Evaluasi

Tingkat 1 %

rejuvenation is performed informally, during a

specific change, without any prior planning.

Sup5.1.2

Retirement of a feature or application is carried out

by leaving all software component infrastructures in

place and preventing its execution.

L 68

Tabel 5.1 menunjukkan ada 19 praktek untuk tingkat kematangan 1 yang tidak

mencapai rating 93% ke atas (tidak berhasil tercapai sepenuhnya/Fully Achieved).

Untuk kolom Evaluasi Tingkat 1 dan kolom %, nilai-nilainya dirujuk dari Tabel

4.20 (Evaluasi Pencapaian Tingkat Kematangan 1). Berarti agar semua KPA bisa

mencapai tingkat kematangan 1 (rating KPA 86% ke atas), maka perlu dibuat

rekomendasi agar tiap-tiap praktek bisa tercapai sepenuhnya (Fully Achieved).

Agar praktek-praktek bisa tercapai sepenuhnya, rekomendasi harus bisa mengatasi

semua kelemahan-kelemahan dalam praktek-praktek tersebut.

5.3 Fase Establishing

Pembuatan rencana tindakan strategis (strategic action plan) untuk SPI adalah

salah satu dari inisiatif paling penting dalam SPI – dan juga yang paling sering

diabaikan. Pada fase ini tim manajemen mengembangkan atau memperbaharui

sebuah rencana tindakan strategis SPI berdasarkan visi organisasi, rencana bisnis,

dan upaya-upaya perbaikan yang sudah pernah dilakukan, bersama dengan

temuan dari kegiatan baselining dari fase diagnosing (McFeely, 1996).

Berikut kelompok kelemahan dari praktek-praktek di Tabel 5.1 yang dibuat

berdasarkan kemiripannya.

Tabel 5.2 Kode dan Kategori Kelemahan Berdasarkan Kemiripan

Kode Kategori Kelemahan Kategori Kelemahan

ART Tidak ada artifak.

CI Configurable item.

DAT Data tidak cukup untuk digunakan.

PRC Praktek tidak dilakukan.

PRD Tidak ada prosedur.


Sepenuhnya (sambungan)


271


Kategori kelemahan dan kodenya digunakan untuk mengelompokkan kelemahan-

kelemahan yang sudah teridentifikasi. Berikut kelemahan-kelemahan pada

praktek-praktek tersebut di proses pemeliharaan perangkat lunak di PT XYZ saat

ini:

Tabel 5.3 Kelemahan-kelemahan yang Menyebabkan Tidak Tercapainya

Tingkat Kematangan 1

Tabel

Referensi

Nomor

Praktek Kelemahan

Kode

Kategori

Tabel 4.1

Pro1.1.1 Belum ada petunjuk pelaksanaannya. PRD

Pro1.1.2 Tujuan utamanya bukan aspek teknis. PRD

Tidak artifak pendukung. ART

Tabel 4.2 Pro2.1.1 Proses baru didefinisikan saat ada masalah. PRD

Tidak ada artifak pendukung. ART

Tabel 4.3

Pro3.1.1 Praktek tidak dilakukan. PRC



Tabel 4.4 Pro4.1.1

Hasil pengukuran tidak digunakan untuk

perbaikan proses. DAT


Pro4.1.2 Hanya mengumpulkan PR. DAT

Tabel 4.5

Pro5.1.1 Tidak ada artifak pendukung. ART



Tabel 4.8 Req3.1.1 Tidak ada artifak pendukung. ART

Tabel 4.10 Evo1.1.1 Tidak ada artifak pendukung. ART

Tabel 4.14 Sup1.1.1

Dokumentasi SI tidak dianggap sebagai

configurable item. CI

Program pembuatan laporan tidak

dianggap sebagai configurable item. CI


Tabel 4.15 Sup2.1.1 Praktek tidak dilakukan. PRC

Tabel 4.16 Sup3.1.1 Tidak ada artifak pendukung. ART

Tabel 4.17 Sup4.1.1 Tidak ada prosedur untuk analisis

penyebab masalah dan resolusi masalah. PRD

Tabel 4.18 Sup5.1.1 Tidak ada artifak pendukung. ART

Sup5.1.2 Tidak ada artifak pendukung. ART

Berdasarkan pengelompokan kelemahan di tabel Tabel 5.3 di atas, untuk analisis

Pareto, dilakukan pengurutan berdasarkan frekuensi kemunculan kelemahan, lalu

dihitung frekuensi kumulatif kemunculan kelemahan dan persentasenya. Berikut

hasilnya:


272


Tabel 5.4 Frekuensi Kumulatif Kelemahan Per Kategori

Kode

Kategori

Frekuensi

Kelemahan

Frekuensi

Kumulatif

Persentase

Kumulatif (%)

ART 12 12 50,00

PRD 4 16 66,67

PRC 4 20 83,33

DAT 2 22 91,67

CI 2 24 100,00

Nilai frekuensi, frekuensi kumulatif, dan persentase kumulatif dari Tabel 5.4 di

atas kemudian digunakan untuk membuat diagram Pareto di bawah ini.

Gambar 5.2 Diagram Pareto Kelemahan Per Kategori

Dari Gambar 5.2 dapat dilihat proporsi kelemahan yang harus diatasi dalam

rekomendasi yang akan disusun. Untuk mengimplementasikan prinsip Pareto,

sedikit rekomendasi harus bisa mengatasi banyak kelemahan. Dengan menerapkan

aturan 80/20 dari prinsip Pareto, dipilih kategori-kategori kelemahan yang bersifat

critical few, yang persentase kumulatifnya di bawah garis batas 80%, yaitu ART

(tidak ada artifak) dan PRD (tidak ada prosedur). Dalam penerapan ini, kategori-

kategori kelemahan ART dan PRD persentase kumulatifnya adalah 66,67%,

sehingga artinya dengan menerapkan rekomendasi perbaikan untuk 2 kategori

kelemahan, dapat menyelesaikan 66,67% kelemahan.

12

4 4

2 2

50,00%

66,67%

83,33%

91,67%

100,00%

0%

80%

0

6

12

18

24

ART PRD PRC DAT CI

Frekuensi Kelemahan Persentase Kumulatif (%)


273


Rekomendasi perbaikan yang diberikan untuk kategori kelemahan yang terpilih

dapat dilihat dalam Tabel 5.5 berikut.

Tabel 5.5 Kategori Kelemahan Dipetakan Terhadap KPA

Pro1 Pro2 Pro3 Pro4 Pro5 Req3 Evo1 Sup1 Sup2 Sup3 Sup4 Sup5

ART × ×

× × × × ×

×

×

PRD × ×

×

PRC

×

×

DAT

×

CI

×

Keterangan: PRC, DAT, dan CI tidak diberikan rekomendasi perbaikan karena di luar batas 80%

dari prinsip Pareto.

Berdasarkan Tabel 5.5, dapat dilihat bahwa perlu disusun rekomendasi untuk

mengatasi kelemahan pada kategori kelemahan ART (tidak ada artifak) dan PRD

(tidak ada prosedur), untuk KPA yang terpilih berdasarkan penerapan prinsip

Pareto. Dalam Tabel 5.5 dapat dilihat bahwa untuk kategori kelemahan PRC,

DAT, dan CI, tidak disusun rekomendasinya, karena berdasarkan prinsip Pareto

ketiga kategori kelemahan ini merupakan trivial many.

5.3.1 Rekomendasi untuk Kategori Kelemahan ART (Tidak Ada Artifak)

Rekomendasi untuk kategori kelemahan ini bertujuan untuk menutupi kelemahan

tidak adanya artifak pendukung praktek-praktek dalam proses pemeliharaan

perangkat lunak saat ini. Berikut kelemahan dan rekomendasi yang diberikan:

Tabel 5.6 Kategori Kelemahan ART dan Rekomendasinya

Tabel

Referensi

Nomor

Praktek Kelemahan Rekomendasi

Tabel 4.1 Pro1.1.2

Tidak ada artifak

pendukung inisiatif

perbaikan aspek teknis

proses pemeliharaan

perangkat lunak.

Membuat:

1. Naming convention yang

digunakan untuk

pemeliharaan.

2. Daftar library, tool,

dokumentasi, script, dan

script yang digunakan untuk

pemeliharaan.

Tabel 4.2 Pro2.1.1

Tidak ada artifak

pendukung definisi

proses atau layanan

pemeliharaan perangkat

Membuat daftar proses

terdefinisi yang bisa diakses

oleh personil pemeliharaan

perangkat lunak.


274


Tabel

Referensi

Nomor


lunak.

Tabel 4.4 Pro4.1.1

Tidak ada artifak

pendukung pengukuran

proses, layanan, atau

produk yang dilakukan

berdasarkan inisiatif

pribadi.

Membuat dokumentasi hasil

pengukuran proses, layanan,

atau produk, yang nantinya

bisa disebarkan ke seluruh

personil pemelihara.

Tabel 4.5

Pro5.1.1

Tidak ada artifak

pendukung evaluasi

manfaat dari proyek

perbaikan dan inovasi.

Membuat dokumen

evaluasi/perbandingan

manfaat dari proyek

perbaikan dan inovasi.

Pro5.1.2

Tidak ada artifak

pendukung perbaikan

aspek teknis yang

dilakukan secara pribadi.

Membuat dokumen kegiatan

perbaikan aspek teknis

proses pemeliharaan.

Pro5.1.3

Tidak ada artifak

pendukung penilaian

proses, teknologi,

metodologi, dan tool

untuk pemeliharaan.

Membuat laporan penilaian

proses, teknologi, dan tool

untuk pemeliharaan.

Tabel 4.8 Req3.1.1

Tidak ada artifak

pendukung untuk

pelacakan dan

pemantauan layanan atau

produk.

Membuat laporan berkala

kegiatan pelacakan dan

pemantauan layanan atau

produk.

Tabel 4.10 Evo1.1.1

Tidak ada artifak

pendukung untuk

kegiatan predelivery and

transition.

Membuat:

1. Rencana dan laporan

berkala kegiatan predelivery

and transition.

2. Daftar proyek yang lagi

dalam tahap predelivery.

3. Daftar proyek yang akan

segera memasuki transition.

4. Checklist kegiatan

predelivery and transition.

Tabel 4.14 Sup1.1.1

Tidak ada artifak

pendukung kegiatan

configuration

management.

Membuat laporan

configuration management

yang berisi baseline

perangkat lunak saat ini.

Tabel 4.16 Sup3.1.1

Tidak ada artifak

pendukung kegiatan

pengukuran dan analisis

oleh manajer untuk tiket

selain CR.

Membuat laporan

pengukuran dan analisis

untuk tiket selain CR.

Tabel 5.6 Kategori Kelemahan ART dan Rekomendasinya (sambungan)


275


Tabel

Referensi

Nomor


Tabel 4.18

Sup5.1.1

Tidak ada artifak

pendukung kegiatan

peremajaan

(rejuvenation).

Membuat:

1. Rencana peremajaan.

2. Laporan komponen yang

sudah diremajakan.

Sup5.1.2

Tidak ada artifak

pendukung kegiatan

memensiunkan

(retirement) perangkat

lunak.

Membuat:

1. Rencana untuk menilai

fitur atau perangkat lunak

yang sudah tidak digunakan

oleh pengguna, untuk


untuk dipensiunkan.

2. Laporan fitur atau

perangkat lunak yang sudah

dipensiunkan, yang sudah

tidak bisa diakses lagi, tapi

kode sumbernya tidak

dihapus.

Dengan menerapkan rekomendasi dari Tabel 5.6 di atas, diharapkan semua

kelemahan praktek-praktek dengan kategori kelemahan ART dapat ditangani.

5.3.2 Rekomendasi untuk Kategori Kelemahan PRD (Tidak ada Prosedur)

Rekomendasi untuk kategori kelemahan ini bertujuan untuk menutupi kelemahan

tidak adanya prosedur untuk praktek-praktek dalam proses pemeliharaan

perangkat lunak saat ini. Berikut kelemahan dan rekomendasi yang diberikan:

Tabel 5.7 Kategori Kelemahan PRD dan Rekomendasinya

Tabel

Referensi

Nomor


Tabel 4.1

Pro1.1.1 Belum ada petunjuk

pelaksanaannya.

Membuat petunjuk

pelaksanaan program kerja

pengenalan metodologi

Scrum.

Pro1.1.2 Tujuan utamanya bukan

aspek teknis.

Membuat prosedur untuk

mengatur perbaikan aspek

teknis proses pemeliharaan

perangkat lunak.

Tabel 4.2 Pro2.1.1 Proses baru didefinisikan

saat ada masalah.


mendefinisikan proses

pemeliharaan perangkat

Tabel 5.6 Kategori Kelemahan ART dan Rekomendasinya (sambungan)


276


Tabel

Referensi

Nomor


lunak, sehingga tidak perlu

menunggu terjadi masalah.

Tabel 4.17 Sup4.1.1

Tidak ada prosedur untuk

analisis penyebab

masalah dan resolusi

masalah.


analisis penyebab masalah

dan resolusi masalah, di

mana penyebab masalah

dan resolusinya dicatat

dalam suatu gudang

informasi yang bisa diakses

oleh semua personil

pemeliharaan.

Dengan menerapkan rekomendasi dari Tabel 5.7 di atas, diharapkan semua

kelemahan praktek-praktek dengan kategori kelemahan PRD dapat ditangani.

5.3.3 Validasi Rekomendasi

Dari rekomendasi Tabel 5.6 dan Tabel 5.7 yang dihasilkan, dilakukan validasi

dengan Kepala Departemen TI untuk mengetahui rekomendasi mana yang

diterima dan mana yang ditolak. Berikut adalah hasil validasi rekomendasi:

Tabel 5.8 Validasi Rekomendasi dengan Kepala Departemen

Kode

Kategori

Pengelompokan

Rekomendasi Komentar

ART

Membuat dokumen-dokumen

untuk merencanakan dan

merekam kegiatan yang

berkaitan dengan praktek-

praktek.

OK. Perlu koordinasi antara Seksi

Application Development dengan

Seksi Business Analyst untuk

pembagian tugas. Dilakukan

bertahap.

PRD

Membuat daftar proses

terdefinisi yang bisa diakses

oleh personil pemeliharaan

perangkat lunak.

OK. Perlu dibuat contoh dokumen

prosedur-prosedur yang

direkomendasikan tersebut.

Dapat disimpulkan bahwa semua rekomendasi perbaikan diterima oleh Kepala

Departemen TI.

Tabel 5.7 Kategori Kelemahan PRD dan Rekomendasinya (sambungan)


277


5.4 Fase Acting

Dalam fase ini perbaikan-perbaikan dikembangkan, dipraktekkan, dan

diimplementasikan di seluruh organisasi. Berbagai perbaikan-perbaikan yang

sudah dikembangkan sudah lengkap dan nilainya dibuktikan kepada organisasi

dengan merintisnya (McFeely, 1996). Fase ini tidak termasuk ke dalam lingkup

pengerjaan karya akhir ini. Asumsi karya akhir ini adalah rekomendasi yang

sudah diterima di subbab 5.3 (Fase Establishing) semuanya akan dilakukan.

Dampak jika semua rekomendasi yang sudah diterima tersebut dilakukan adalah

sebagai berikut:

Tabel 5.9 Dampak Rekomendasi Terhadap Kelemahan Pada Praktek-

praktek di Tingkat Kematangan 1

KPA Kelemahan Kelemahan

Diatasi

Kelemahan

Diatasi (%)

Maintenance Process Focus (Pro1) 3 3 100,00%

Maintenance Process/Service

Definition (Pro2) 2 2 100,00%

Maintenance Training (Pro3) 3 0 0,00%

Maintenance Process Performance

(Pro4) 3 1 33,33%

Maintenance Innovation and

Deployment (Pro5) 3 3 100,00%

Request/Software Monitoring and

Control (Req3) 1 1 100,00%

Predelivery and Transition Services

(Evo1) 1 1 100,00%

Configuration and Version

Management (Sup1) 3 1 33,33%

Process, Service, and Software

Quality Assurance (Sup2) 1 0 0,00%

Maintenance Measurement and

Analysis (Sup3) 1 1 100,00%

Causal Analysis and Problem

Resolution (Sup4) 1 1 100,00%

Software Rejuvenation, Migration,

and Retirement (Sup5) 2 2 100,00%

Jadi dapat disimpulkan bahwa jika semua rekomendasi yang sudah divalidasi

tersebut diterapkan, maka semua KPA yang 100% kelemahannya sudah diatasi

akan mencapai tingkat kematangan 1, yaitu: Pro1, Pro2, Pro5, Req3, Evo1, Sup3,


278


Sup4, dan Sup5. Ini juga berarti tetap ada KPA yang tertinggal pada tingkat

kematangan 0, yaitu: Pro3, Pro4, Sup1, dan Sup2.

5.5 Fase Leveraging

Setelah organisasi menyelesaikan satu siklus dari IDEAL, perlu untuk meninjau

apa yang terjadi dalam siklus tersebut dan bersiap-siap untuk siklus berikutnya

dari model ini. Daripada masuk ulang melalui fase initiating di siklus berikutnya,

dengan melakukan aktivitas fase leveraging ini, fase berikutnya yang akan

dimasuki adalah fase diagnosing. Fase ini, selain merupakan persiapan untuk

siklus berikutnya, memberikan kesempatan untuk menyesuaikan (tune up) proses

SPI sebelum dimulai lagi. Kemungkinan ada permulaan yang salah saat memulai

siklus sebelumnya, ada yang tidak dilakukan, aktivitas-aktivitas yang semestinya

dilakukan di siklus sebelumnya. Karena manajemen sudah terus melacak

pelajaran yang dipelajari (lesson learned) dari tiap aktivitas SPI sebelumnya,

sekarang manajemen bisa menerapkannya saat fase leveraging untuk membuat

proses SPI bisa bekerja lebih baik untuk siklus berikutnya (McFeely, 1996). Fase

ini tidak masuk ke dalam lingkup pengerjaan karya akhir ini.



BAB 6

KESIMPULAN DAN SARAN

Bab ini menjelaskan kesimpulan dan saran yang diperoleh dari penelitian ini.

Penelitian ini sudah menghasilkan rating tingkat kematangan proses pemeliharaan

perangkat lunak di Departemen TI PT XYZ. Setelah rating tingkat kematangan

dibuat, maka masukan manajemen untuk pemilihan KPA yang akan diperbaiki

diperoleh. Setelah itu rekomendasi perbaikan proses pemeliharaan perangkat

lunak dihasilkan untuk memperbaiki KPA terpilih tersebut.

6.1 Kesimpulan

Berikut butir-butir kesimpulan yang diambil dari penelitian ini.

a. Organisasi menyadari adanya keperluan untuk perbaikan proses perangkat

lunak (SPI) karena adanya target pemeliharaan perangkat lunak yang tidak

tercapai.

b. S3m dipilih sebagai model referensi karena khusus untuk pemeliharaan

perangkat lunak.

c. Karena organisasi belum pernah melakukan penilaian serupa sebelumnya,

maka organisasi memilih untuk melakukan penilaian untuk semua KPA

dalam S3m.

d. Hasil kajian terhadap semua KPA dalam S3m memperoleh tingkat

kematangan organisasi, yaitu tingkat kematangan 0. Tingkat kematangan ini

berarti penerapan proses pemeliharaan perangkat lunak masih belum

konsisten, tidak terkendali, dan akan berdampak pada kualitas layanan

kepada pelanggan. Hal ini mengonfirmasi masalah tidak tercapainya target

pemeliharaan perangkat lunak oleh organisasi.

e. Kelemahan-kelemahan dalam praktek-praktek pada KPA yang tidak

mencapai tingkat kematangan 1 dapat dikelompokkan dalam 5 kategori,

yaitu: tidak ada artifak, configurable item, data tidak cukup untuk

digunakan, praktek tidak dilakukan, dan tidak ada prosedur.


280


f. Dengan melakukan analisis Pareto, kategori kelemahan yang merupakan

critical few adalah: tidak ada artifak dan tidak ada prosedur. Kedua kategori

ini kemudian dibuatkan rekomendasi untuk mengatasi kelemahannya.

g. Rekomendasi diajukan kepada Kepala Departemen untuk validasi. Hasilnya

adalah semua rekomendasi diterima.

h. Jika semua rekomendasi dilaksanakan, maka KPA yang masih tertinggal

pada tingkat kematangan 0 adalah Pro3, Pro4, Sup1, dan Sup2.

6.2 Saran

Untuk perbaikan proses pemeliharaan perangkat lunak berikutnya di Departemen

TI PT XYZ, peneliti memberikan saran-saran berikut:

a. Agar Departemen TI PT XYZ benar-benar melakukan rekomendasi

perbaikan proses, sehingga akar masalah awal yang diidentifikasi bisa

dikurangi atau dieliminasi.

b. Agar melakukan penilaian berkala terhadap KPA pemeliharaan perangkat

lunak berdasarkan model S3m. Hal ini disarankan agar progres perbaikan

dapat dilacak, sehingga manfaat awal yang diperoleh tidak hilang.

c. Agar KPA yang tertinggal pada tingkat kematangan 0 untuk selanjutnya

juga dibuatkan rencana perbaikannya agar bisa mencapai tingkat 1 juga.

d. Setelah tingkat kematangan yang ditargetkan di karya akhir ini tercapai

(tingkat 1), agar dilanjutkan ke tingkat berikutnya (tingkat 2), sehingga

manfaat yang diperoleh dari inisiatif SPI bisa menjadi lebih besar bagi

organisasi, supaya dapat lebih membantu pencapaian visi dan misi

perusahaan.



DAFTAR PUSTAKA

Andersson, C., & Runeson, P. (2007). A Replicated Quantitative Analysis of Fault

Distributions in Complex Software Systems. IEEE Transactions on

Software Engineering, 33(5), 273-286.

April, A., & Abran, A. (2008). Software Maintenance Management: Evaluation

and Continuous Improvement. Hoboken, NJ, USA: John Wiley & Sons.

April, A., & Abran, A. (2009). A Software Maintenance Maturity Model (S3M):

Measurement Practices at Maturity Levels 3 and 4. Electronic Notes in

Theoretical Computer Science, 233, 73-87.

April, A., Hayes, J. H., Abran, A., & Dumke, R. (2005, Mei 23). Software

Maintenance Maturity Model (SMmm): The software maintenance process

model. Journal of Software Maintenance and Evolution: Research and

Practice, 17(3), 197-223.

Cahyadi, A. H. (2015). Evaluasi dan Perbaikan Proses Pengembangan Perangkat

Lunak Menggunakan Kerangka Kerja CMMI-DEV dan Scrum: Studi

Kasus PT. Gemawidia Solusi Komputer. Fakultas Ilmu Komputer,

Magister Teknologi Informasi. Jakarta: Universitas Indonesia.

Chan, T. (2000). Beyond Productivity in Software Maintenance: Factors Affecting

Lead Time in Servicing Users' Requests. International Conference on

Software Maintenance (hal. 228-235). San Jose: IEEE.

Chrissis, M. B., Konrad, M., & Shrum, S. (2011). CMMI for Development:

Guidelines for Process Integration and Product Improvement (3rd ed.).

Upper Saddle River, New Jersey, USA: Addison-Wesley.

CMMI Product Team. (2006, Agustus). CMMI for Development, Version 1.2.

Dipetik Mei 7, 2017, dari SEI CMU Digital Library:

https://www.sei.cmu.edu/reports/06tr008.pdf

CMMI Product Team. (2010, November). CMMI for Development, Version 1.3.

Dipetik Oktober 8, 2015, dari SEI CMU Digital Library:

https://www.sei.cmu.edu/reports/10tr033.pdf

de Vasconcelos, A. M., de la Vara, J. L., Sánchez, J., & Pastor, Ó. (2012).

Towards CMMI-Compliant Business Process-Driven Requirements

Engineering. 8th International Conference on the Quality of Information

and Communications Technology (QUATIC) (hal. 193-198). Lisbon,

Portugal: IEEE.


282


Edelstein, D. V. (1993). Report on the IEEE STD 1219 - 1993 - Standard for

Software Maintenance. SIGSOFT Software Engineering Notes, 18(4), 94-

95.

Grubb, P., & Takang, A. A. (2003). Software Maintenance: Concepts and

Practice (2nd ed.). River Edge, NJ, USA: World Scientific.

IEEE Computer Society. (2014, Januari 17). Guide to the Software Engineering

Body of Knowledge, Version 3.0. (P. Bourque, & R. E. Fairley, Penyunt.)

Dipetik Februari 13, 2017, dari IEEE Computer Society:

https://www.computer.org/web/swebok/v3

Iqbal, M., & Rizwan, M. (2009). Application of 80/20 Rule in Software

Engineering Waterfall Model. 2009 International Conference on

Information and Communication Technologies (hal. 223-228). Karachi,

Pakistan: IEEE.

ISO/IEEE. (2006, Mei 19). ISO/IEC 14764:2006 - Software Engineering —

Software Life Cycle Processes — Maintenance. Dipetik Februari 21, 2017,

dari IEEE Xplore:

http://ieeexplore.ieee.org/servlet/opac?punumber=11168

Jung, H.-W., & Goldenson, D. R. (2009). Evaluating the relationship between

process improvement and schedule deviation in software maintenance.

Information and Software Technology, 51(2), 351-361.

Kneuper, R. (2009). CMMI: Improving Software and Systems Development

Processes Using Capability Maturity Model Integration (CMMI-DEV) (1st

ed.). Santa Barbara, California, USA: Rocky Nook.

McFeely, B. (1996, Februari). IDEAL: A User's Guide for Software Process

Improvement. Dipetik April 13, 2017, dari SEI CMU Digital Library:

https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=12449

O'Regan, G. (2011). Introduction to Software Process Improvement. London, UK:

Springer.

Paquette, D.-A., April, A., & Abran, A. (2006). Assessment results using the

Software Maintenance Maturity Model (S3m). 16th International

Workshop on Software Measurement (IWSM-MetriKon) (hal. 147-160).

Postdam: Shaker Verlag.

Phillips, M. (2007). CMMI V1.2: What Has Changed and Why. The Journal of

Defense Software Engineering, 4-7.

Pressman, R. S. (2010). Software Engineering: A Practitioner's Approach (7th

ed.). Crawfordsville, IN, USA: McGraw-Hill.


283


PT XYZ. (2012, Juli 16). Struktur Organisasi Information Technology (IT)

Department. SK No. 029/SK/DIR/VII/2012. Jakarta Selatan, DKI Jakarta,

Indonesia: PT XYZ.

Ren, Y. C., Xing, T., Liu, Z., & Chen, X. (2011). Software Maintenance Process

Model and Contrastive Analysis. International Conference on Information

Management, Innovation Management and Industrial Engineering (ICII).

3, hal. 169-172. Shenzhen, China: IEEE.

Sneed, H. M., & Brössler, P. (2003). Critical Success Factors in Software

Maintenance: A Case Study. International Conference on Software

Maintenance (ICSM) (hal. 190-198). Amsterdam, Netherlands: IEEE.

Sommerville, I. (2011). Software Engineering (9th ed.). Boston, MA, USA:

Addison-Wesley.

Unterkalmsteiner, M., Gorschek, T., Islam, A. M., Cheng, C. K., Permadi, R. B.,

& Feldt, R. (2012). Evaluation and Measurement of Software Process

Improvement—A Systematic Literature Review. IEEE Transactions on

Software Engineering, 38(2), 398-424.

Zarour, M., Alarifi, A., Abran, A., & Desharnais, J.-M. (2012). Evaluating the

Assessment Method of the Software Maintenance Maturity Model. 2012

International Conference on Information Technology and e-Services (hal.

1-8). Sousse, Tunisia: IEEE.


284


LAMPIRAN

Lampiran A. Transkrip Wawancara Awal

Tanggal : 7 Februari 2017

Tempat : Ruang Kepala Departemen TI

Narasumber : Bapak RK (Kepala Departemen TI)

Masa Kerja : 14 tahun

Wawancara ini bertujuan untuk mendapatkan latar belakang pembuatan SI core

insurance Sistem Informasi Asuransi Umum.

P-1 : Selamat sore, Pak RK. Saya ada beberapa pertanyaan untuk tujuan

penelitian Karya Akhir. Bapak RK adalah Manajer IT di PT XYZ.

Kita mulai dari pertanyaan nomor satu, Pak. Dulu Sistem Informasi

Asuransi Umum dibuat, tujuannya apa Pak?

J-1 : Tujuannya itu adalah untuk membuat satu aplikasi yang terintegrasi untuk

sistem core asuransi, yang terintegrasi antara marketing, underwriting,

terus claim, finance, dan accounting. Itu tujuannya. Dulu sudah ada

sistemnya, cuma kita upgrade supaya juga, dulu client-server application,

waktu Sistem Informasi Asuransi Umum dibuat itu kita mau beralih ke

web-based application. Begitu, tujuannya itu.

P-2 : Berarti sebelumnya sudah ada tapi berbasis web.

J-2 : Belum berbasis web dan belum seluruhnya terintegrasi. Masih modular,

begitu.

P-3 : OK, belum terintegrasi. Berarti tidak terintegrasinya itu adalah suatu

masalah, begitu? Kita ingin … integrasi itu sebetulnya apa yang

dicapai?

J-3 : Contohnya dulu kalau accounting system itu berbeda. Jadi setiap, kalau

tidak salah setiap hari itu ada proses pemindahan antara core system dan

accounting system. Jadi tidak terintegrasi. Dia harus ada batch processing


285


antara dua sistem ini. Itu salah satunya. Terus, dulu juga karena belum

online seluruh cabang, itu harus ada batch processing juga mengambil dari

data-data cabang, kemudian mengakumulasi, mengompilasi di server yang

pusat setiap sebulan sekali. Itu juga kan data-datanya telat, jadi kita tidak

bisa tahu misalnya produksi cabang, yang seperti sekarang langsung pada

saat ini juga kita bisa tahu, datanya belum terintegrasi secara in one place,

begitu.

P-4 : Berarti salah satu permasalahan yang mau dipecahkan itu adalah

dulu data produksi itu tidak bisa langsung diketahui, begitu?

J-4 : Iya.

P-5 : Harus diproses batch-nya?

J-5 : Jadi kan island. Masing-masing cabang punya server sendiri-sendiri.

Kalau dulu, lain server, biarpun bisa sebenarnya di pusat. Cuma kan

network dulu juga susah. Masing-masing cabang punya server masing-

masing, kemudian baru ditarik setiap ada, setiap beberapa, apa namanya,

ada interval lah. Saya lupa, dulu dua minggu sekali apa sebulan sekali.

Buat direkonsiliasi di pusat, begitu.

P-6 : Berarti salah satunya juga yang mengurangi pekerjaan karyawannya

yang harus rekonsiliasi itu di perusahaan?

J-6 : Iya, iya.

P-7 : Baik. Itu untuk masalah yang dihadapi sistem sebelum Sistem

Informasi Asuransi Umum. Berikutnya adalah, tentunya Sistem

Informasi Asuransi Umum itu dibuat bukan hanya untuk mengatasi

sebuah permasalahan saja. Pasti dia ada kepingin menggapai sebuah

opportunity bisnis, business opportunity yang ingin dicapai. Sesuatu

yang dengan sistem sebelumnya belum bisa.

Lampiran A. Transkrip Wawancara Awal (lanjutan)


286


J-8 : Sekarang bisa.

P-9 : Tapi setelah ada sistem ini bisa, tapi bukan mengatasi permasalahan,

mau menggapai business opportunity. Itu, seperti itu apa saja?

J-9 : Contohnya salah satu itu dulu kita nggak bisa, ini menurut cerita manajer

IT yang dulu ya, kita nggak bisa provide B2B, apa namanya, Business to

Business secara gampang. Maksudnya secara gampang, secara ter-

integrated gitu. Jadi salah satu tantangan bisnisnya itu kita mau connect ke

misalnya partner kita leasing company gitu. Leasing company itu mau

mengirimkan datanya lewat satu pintu, kemudian menyebar ke seluruh

cabangnya. Dulu itu kita nggak bisa karena kan sistemnya island-island.

Bisa sebenarnya, cuma membutuhkan waktu, effort dan yang cukup besar.

Kalau sekarang kan kita bisa gitu. Upload di sistem, di pusat, langsung

semua cabang langsung dapat. Itu salah satu keunggulannya sih. Dan

business opportunities yang dapat. Karena itu kita entry juga tidak usah

entry, karena datanya sudah di-feed oleh partner asuransi kita. Kemudian

semua apa namanya, prosedur juga sudah kita lakukan di sistem.

Kemudian tinggal cabang-cabang print.

P-10 : OK.

J-10 : Itu salah satunya.

P-11 : Salah satunya. Selain itu masih ada lagi, Pak? Yang utama gitu, yang

paling …

J-11 : Salah satunya juga, kalau dulu kita belum ada workflow ya namanya.

P-12 : Workflow?

J-12 : Di sistem ini kita juga implementasi workflow. Contohnya marketing

entry, kemudian dengan parameter tertentu dia bisa di-approve oleh kantor

cabang itu sendiri, atau langsung butuh approval di kantor pusat. Jadi ada



287


semacam workflow-nya lah gitu. Untuk workflow dan limit-limit tertentu

masing-masing dulu tidak ada, hanya data entry saja. Jadi kita

implementasi di Sistem Informasi Asuransi Umum juga.

P-13 : Oh, berarti dulu itu pembuatan polis …

J-13 : Mereka approval-nya harus manual dulu.

P-14 : OK.

J-14 : Manual di kertas dulu, setelah polisnya OK jadi, baru di-entry.

P-15 : Oh OK.

J-15 : Kalau sekarang dilakukan, di-entry dulu, approval juga di sini.

P-16 : Baik. Berarti pertanyaan itu terjawab. Berikutnya adalah apakah

sejauh ini tujuan-tujuan tersebut, yang tadi Bapak sebutkan …

J-16 : Iya.

P-17 : Tujuan awal itu tercapai? Tadi salah satunya adalah integrasi semua

cabang.

J-17 : Iya, itu tercapai.

P-18 : Tercapai.

J-18 : Kemudian kita juga lebih mudah integrasi dengan business partner kita.

P-19 : B2B tadi.

J-19 : Tercapai karena teknologinya lebih baru kan? Karena yang dulu juga agak

lama, sekarang lebih baru. Tercapai. Ya, pasti kalau dibilang tercapai

100%, nggak, nggak, apa ya, pasti ada room for improvement lah, room for

improvement. Justru sistem ini sekarang yang kita lakukan selalu ada room

for improvement kita.



288


P-20 : OK. Nah, yang room for improvement itu contohnya yang mana ya

Pak? Berarti kan ada sesuatu yang seharusnya masih bisa kita capai

dengan Sistem Informasi Asuransi Umum sekarang ini, tetapi kita

belum, atau entah alasan apapun.

J-20 : Ya, seiring kemajuan teknologi pasti kan selalu ada room for improvement,

ya?

P-21 : Iya.

J-21 : Room for improvement. Jadi, sekarang juga kita melihat teknologinya

kalau dulu lima tahun, sepuluh tahun lalu belum ada tablet, contohnya

begitu. Sekarang orang nggak hanya duduk di komputer saja, entry mau

jalan-jalan lewat bisa misalnya survei lewat tablet, gitu. Jadi, jadi dia

nggak usah bawa PC atau nggak bawa laptop, dia hanya khusus bawa

tablet kemudian bisa berinteraksi dengan customer atau interaksi dengan

apa namanya, business partner. Nah, itu tujuan seperti itu yang kita mau

improve. Jadi mobility-lah, mobility, mobility-nya itu yang kita mau

improve. Juga usability dari sistem ini kita mau tingkatkan terus supaya

lebih mudah, lebih mudah, gitu. Contohnya kita mau upgrade UI kita yang

sudah, UI itu user interface, supaya lebih mudah lagi buat pengguna,

dengan menggunakan teknologi-teknologi yang baru, gitu.

P-22 : OK, itu contoh improvement yang bisa kita lakukan ya Pak ya?

J-22 : Iya.

P-23 : Nah, sekarang ini, sebelumnya kita sudah pernah diskusi tentang

masalah utama yang dihadapi …

J-23 : OK.

P-24 : Organisasi yang berkaitan dengan jadwal …

J-24 : Nah iya itu.



289


P-25 : Proyek …

J-25 : Karena room buat improvement itu kan ada banyak ya.

P-26 : Iya.

J-26 : Justru itu ada banyak, kemudian kita juga punya banyak input-an dari

user-user. Itu create semacam backlog lah, kasarnya gitu, backlog. Jadi

kita butuh improvement yang banyak dan cepat untuk backlog-nya. Kita

selama ini mengerjakan sesuai dengan kemampuan kita dan standar

framework yang saya bilang standar, standar framework gitu aja yang

seperti, ada permintaan kemudian kita masukkan dalam list, kemudian kita

kerjakan sesuai dengan format SDLC lah, standard software life …

development cycle, gitu. Kita merasa ini kita kurang, kurang apa ya

namanya, kurang cepat dan kurang, kurang agile lah kalau dibilang

sekarang itu. Kurang agile untuk dengan perubahan. Karena seiring

perubahan itu, setiap perubahan pasti juga, apa namanya, nggak 100% itu

kita tahu dari awal perubahan apa yang kita harus perbuat, problem-nya

salah satunya itu. Jadi misalnya kita mau bikin A nih, feature A gitu. Nah

feature A itu kita belum tahu 100% feature A ini maunya seperti apa. Di

tengah-tengah jalan bisa berubah. Kita sudah develop 20%, 30%, eh tiba-

tiba “kayaknya nggak begini nih feature yang kita mau”. Untuk user kita

mesti ubah, gitu. Nah, sudah gitu ditambah lagi dengan banyaknya feature-

feature request yang ada. Kita agak kesulitan untuk me-manage itu dan

untuk segampang itu berubah di tengah jalan, untuk, untuk apa namanya,

memfasilitasi request-request itu.

P-27 : OK. Jadi itu salah satu permasalahan yang dihadapi.

J-27 : Iya.

P-28 : Kita kurang agile, gitu?

J-28 : Ya kurang cepat dan kurang ini dengan perubahan lah, gitu.

Lampiran A. Transkrip Wawancara Awal (lanjutan) Lampiran A. Transkrip Wawancara Awal (lanjutan)


290


P-29 : OK, jadi kalau misalnya dari user kita mengajukan permintaan terus

kita mau, biasanya kan kalau dalam tahap Software Development Life

Cycle itu ada requirement gathering …

J-29 : Iya requirement gathering …

P-30 : Baru nanti ya coding-nya …

J-30 : Coding.

P-31 : Baru setelah itu diujikan lagi ke user untuk validasi, seperti itu?

Selama ini kita kurang di bagian situ ya Pak?

J-31 : Iya.

P-32 : Kalau di bagian progress-nya itu sendiri, Pak? Soalnya kalau misalnya

Manajer Marketing kan kadang-kadang mau nanya tuh ... “yang B2B

ini sudah sampai mana ya?”

J-32 : Nah itu juga kita agak kurang dalam dokumentasi yang itu karena kita

nggak punya tools … ya kita punya semacam Excel tools gitu tapi kita

satu nggak punya tools untuk yang collaboration lah gitu. Nggak punya

framework untuk collaboration untuk … update status ini sendiri hanya

dilakukan oleh satu orang Project Manager-nya. Kemudian kalau Project

Manager-nya lupa update, ya nggak ke-update itu statusnya semua, gitu.

Jadi update secara berkala, dan tidak dilakukan berkalanya secara cepat

untuk update status. Nah itu problem justru kita. Kadang-kadang backlog

itu lupa sampai kelamaan lah, kasarnya.

P-33 : OK itu tentang masalah backlog ya Pak ya. Kalau boleh diklarifikasi,

Pak, sebetulnya yang bertugas sebagai Project Manager di

Departemen IT di sini siapa Pak?



291


J-33 : Sekarang kita, sebenarnya nggak ada PMO murni, Project Management

Office murni, tapi sekarang tanggung jawabnya yang handle project ini

adalah, yang list project itu ada di Business Analyst.

P-34 : OK, di bagian Business Analyst ya Pak. OK Pak, kayaknya itu aja

dulu.

J-34 : Cukup?

P-35 : Untuk saat ini. Terima kasih Pak atas klarifikasinya.

J-35 : Iya, terima kasih kembali.



292


Lampiran B. Transkrip Wawancara Identifikasi Masalah

Tanggal : 16 Februari 2017

Tempat : Ruang Kepala Departemen TI

Narasumber : Bapak RK (Kepala Departemen TI)


Wawancara ini bertujuan untuk mencari tahu:

1. Sejauh apa PT XYZ bergantung pada SI/TI.

2. Pengaruh kegiatan software maintenance pada bisnis PT XYZ.

3. Harapan manajemen terhadap kegiatan software maintenance.

4. Realita kegiatan software maintenance.

5. Akar permasalahan yang mempengaruhi kegiatan software maintenance.

P-1 : OK, selamat sore Bapak RK. Kita melanjutkan tentang wawancara

topik karya akhir saya, Software Process Improvement untuk PT XYZ.

J-1 : OK.

P-2 : OK Pak, kita langsung aja Pak, ke pertanyaan pertama Pak. PT XYZ

sejauh apa ketergantungannya terhadap SI atau TI?

J-2 : Sejak diberlakukannya Sistem Informasi Teknologi yang baru di 2005-an

gitu, PT XYZ sudah sangat sekali tergantung Sistem Informasi ini yang

kita namakan Sistem Informasi Asuransi Umum. Jadi semua transaksi

sudah tercatat secara sistematis di Sistem Informasi ini, dan tidak ada

informasi yang dicatat secara manual. Maksudnya dengan Excel atau

dengan apapun, semuanya udah dalam sistem. Jadi kalau ditanya

tergantung apa tidak, ya sangat tergantung lah.

P-3 : Sangat tergantung, Pak. Ini pertanyaan kalau-kalau saja Pak, kalau

Sistem Informasi Asuransi Umum kita tidak bisa diakses, katakanlah

matilah ini, Sistem Informasi Asuransi Umumnya.

J-3 : Mati.


293


P-4 : Dampaknya itu kira-kira apa?

J-4 : Dampaknya ya pasti tidak bisa membukukan premi, tidak bisa membayar,

semua … ya semua tidak bisa apa-apa lah kasarnya gitu.

P-5 : Kalau gitu, misalnya saya bilang, kalau Sistem Informasi Asuransi

Umum mati, maka bisnis PT XYZ itu stop total?

J-5 : Iya, walaupun kita punya contingency plan. Itu ada.

P-6 : Baik Pak. Kalau begitu saya lanjutkan lagi ke pertanyaan berikutnya

adalah, saat ini aplikasi, atau Sistem Informasi di Lintas … , eh di PT

XYZ itu apa aja ya Pak? Atau paling tidak, daftarnya itu yang

megang sekarang siapa, Pak?

J-6 : Daftar aplikasi kita, sebenarnya aplikasinya itu namanya … untuk core

application ya, untuk sistem itu satu, namanya Sistem Informasi Asuransi

Umum. Nah dalam Sistem Informasi Asuransi Umum itu terdiri beberapa

modul. Ada modul marketing, modul underwriting, ada modul claim, ada

modul reinsurance, ada accounting, ada finance, dan ada modul fixed asset

sedikit gitu. Jadi tujuh modul ini core insurance dan accounting system,

semua udah di-integrated. Untuk sistem yang lain-lain, e-mail, server, dan

itu pasti punya sendiri lah, tapi itu standar, bukan core insurance begitu.

P-7 : Berarti kalau misalnya saya simpulkan bahwa: yang paling penting

itu dari aplikasi-aplikasi yang kita pegang sekarang ini adalah Sistem

Informasi Asuransi Umum itu sendiri.

J-7 : Iya itu core system-nya lah gitu.

P-8 : Baik, baik. Kalau gitu pertanyaan tiga sudah terjawab. OK, kalau

gitu, ini penegasan aja ya Pak, klarifikasi aja ya. Yang bertugas untuk

maintenance dan operasional aplikasi-aplikasi ini di PT XYZ itu tim-

tim apa saja, Pak?

Lampiran B. Transkrip Wawancara Identifikasi Masalah (lanjutan)


294


J-8 : Jadi kita ada dibagi beberapa tim di sini. Jadi ada tim development, itu

developer, kemudian tim help desk dan infrastructure, kemudian tim MIS,

satu lagi tim business analyst. Jadi yang help desk itu tujuannya pasti

untuk support aplikasi, help desk application dan help desk hardware ya.

Jadi help desk application tugasnya untuk men-support Sistem Informasi

Asuransi Umum ini, gitu. Dia yang mencatat kalau ada error, ada problem,

mereka yang catat. Kemudian, tim business analyst untuk … biasanya act

as a second level support dan juga ... kalau dia business analyst untuk new

feature request, gitu. Nah, pasti yang untuk pengerjaannya di tim

developer, tim developer. Dan MIS khususnya untuk penyediaan data-

data, untuk reporting lah. Itu aja.

P-9 : Oh, tim MIS itu istilah resminya, saya pikir selama ini itu tim report.

J-9 : Iya.

P-10 : Tim MIS. Baik.

J-10 : Iya, report plus MIS lah.

P-11 : Baik Pak. Kalau gitu berikutnya adalah, untuk kegiatan development

atau maintenance, kita sekarang sudah ada SOP nya Pak?

J-11 : SOP secara baku belum ada. Jadi dulu pernah ada flowchart-nya

bagaimana meng-handle, meng-handle ada request masuk mesti ke mana

dulu, itu ada sebenarnya. Tapi untuk SOP bener-bener kalau ada kayak

knowledge based management-nya belum ada sih.

P-12 : Oh, baik. Tapi itu sudah lama ya?

J-12 : Iya sudah lama.

P-13 : Itu sepertinya, masih ada dulu organisasi, suborganisasi, yang

namanya BSD ya?



295


J-13 : Iya.

P-14 : Sekarang sudah dilebur dengan Departemen IT ya?

J-14 : Iya dilebur.

P-15 : Bisa dibilang sudah out of date ya?

J-15 : Waktu kita lebur, itu di-revisit sih sebenarnya.

P-16 : Oh.

J-16 : Itu di-revisit di … apa namanya … di ini ulang, di-revisit ulang. Sekarang

masih berlaku, cuma kurang di-update aja.

P-17 : Jadi sebetulnya ada, masih berlaku …

J-17 : Iya, ada, masih berlaku, tapi udah ketinggalan, belum di-revisit lagi.

Mungkin udah dua, tiga tahun belum di-revisit lagi.

P-18 : OK, baik Pak. Kita lanjut lagi. Kalau KPI, Pak. KPI itu ada level

organisasi, ada level orang. Kalau di level organisasinya itu kita sudah

ada belum KPI untuk mengukur kinerja development dan

maintenance.

J-18 : Jadi KPI secara organisasi kita udah ada. Kemudian KPI turunan-

turunannya itu sedang dibuat. Bukan sedang dibuat, sedang disusun.

Dalam tahap akhir, gitu. Memang selama ini, untuk KPI ini masih

bergantung pada … belum diselaraskan lah gitu. Diselaraskan ke KPI

perusahaan. Tapi kalau yang dimaksud KPI itu cara penilaian kerja dan …

apa namanya … individual itu ada masing-masing itunya. Cuma belum

terlalu detail. Kemudian biasanya kita di sini berjalan dengan project plan

kalau untuk dari sisi departemental.

P-19 : Baik. Itu tadi tentang pengukuran kinerja ya, Pak.



296


J-19 : Iya.

P-20 : Baik. Berikutnya adalah, ekspektasi manajemen terhadap proses,

SOP, dan kinerja itu tadi, untuk development atau maintenance itu …

Bapak sebagai manajer IT, berarti Bapak di sini kan punya

wewenang, diberikan wewenang oleh Direksi untuk menentukan

ekspektasi dari bagian IT ini seperti apa. Bapak, harapan Bapak

terhadap bagian IT itu valid. Nah, tapi itu seperti apa harapannya

Pak? Ini saya udah sempat bikin ini, kasar aja Pak, tabelnya kayak

begini. Ada untuk new ... tadi kan kita udah sempat diskusi ya Pak.

Untuk new feature itu dia perlakuannya berbeda dengan untuk bug,

tapi kategorisasinya di sini bisa dibagi untuk yang sama. Ada critical,

high, medium, low, tapi mungkin berbeda di masanya. Misalnya untuk

new feature sekian hari, maka di bug biarpun dia critical tapi mungkin

toleransinya lebih tinggi.

J-20 : Iya, iya, iya, benar. Jadi kalau bug itu kita, dulu sejak development Sistem

Informasi Asuransi Umum ini sudah, sudah ada. Jadi critical itu satu hari,

sebenarnya.

P-21 : Bug ya Pak, ya?

J-21 : Iya, bug, untuk bug. Kemudian untuk medium kalau nggak salah …

P-22 : Ada high, ada medium, ada low, Pak. Yang high ini berarti nggak valid

ya Pak?

J-22 : Iya, nggak valid.

P-23 : OK, baik berarti …

J-23 : Critical atau high itu lah.

P-24 : Oh, critical itu high. Siap Pak.



297


J-24 : Jadi definisi critical juga, misalnya dia blocker, transaksi blocking gitu.

Jadi nggak ada cara lain melakukan transaksi daripada membetulkan

programnya gitu. Itu 1 hari, 1 × 24 jam. Kemudian medium itu kita

kategorikan bisa ada cara lain tapi … ya … apa namanya … tidak bisa

dibiarkan berlarut-larut.

P-25 : Karena memperlambat begitu ya?

J-25 : Ya, itu 3 hari. Untuk yang low itu 7 hari.

P-26 : 7 hari. Itu untuk bug ya?

J-26 : Iya, bug.

P-27 : Kalau untuk new feature atau new product?

J-27 : Nah, new feature atau product ini memang dari dulu belum ada ininya …

belum ada apa namanya … SLA-nya benar-benar, gitu. Tapi ekspektasinya

ini adalah, berdasarkan pengalaman itu kalau misalnya kita mau bilang

new feature lah, new product, itu pengalamannya itu dalam hitungan

bulan. Satu atau dua bulan, gitu.

P-28 : Satu atau dua bulan.

J-28 : Itu pengalamannya, tapi untuk ekspektasinya sekarang, sekarang kayaknya

sudah berubah. Jaman makin berkembang, dengan teknologi berkembang,

itu kita bisa ini harus dalam … implementasi dalam waktu mingguan.

Dalam waktu minggu gitu, less than 1 bulan. Itu new features gitu.

P-29 : Kita bisa bilang standarnya makin tinggi?

J-29 : Makin tinggi.

P-30 : Dan hitungan minggu itu, dua minggu kah? Satu minggu?



298


J-30 : Ya lebih cepat lebih baik. Tapi dalam hitungan nggak boleh, nggak bisa go

live, kita mau new product, kita butuh waktu 3 bulan, nggak bisa. Mungkin

1 bulan itu maksimum sekarang gitu. Jadi new feature bisa aja mungkin 1

bulan ekspektasinya yang high. Yang medium 2 bulan. Dan 3 bulan gitu.

P-31 : Low itu berarti 3 bulan paling lama ya?

J-31 : Ya mungkin nggak se-simple itu. Mesti di itu ya. Tapi mesti di … ada

definisi-definisinya gitu.

P-32 : Karena memang menentukan itu bukan exact science tadi yang Bapak

bilang.

J-32 : Iya.

P-33 : Setiap feature itu juga tentunya ada yang critical tapi mungkin nggak

bisa 1 bulan selesai.

J-33 : Iya.

P-34 : Jadi case by case juga sebenarnya ya?

J-34 : Iya.

P-35 : Baik. Berikutnya. Tadi tentang ekspektasi terhadap SOP dan KPI.

Berikutnya adalah, kalau di atas itu, yang 1 bulan, 1 hari, dimulainya,

dimulai start begitu mulai identifikasi atau mulai pengerjaan, Pak?

Kan bisa beda ya? Jadi, kita identifikasi hari ini, tapi kita masukkan

ke dalam … apa namanya … ke dalam antrean dulu.

J-35 : Iya. Itu mulai pengerjaan.

P-36 : Mulai pengerjaan ya? Bukan mulai identifikasi. Baik, Pak.

Berikutnya adalah, itu tadi kalau untuk new feature atau product dan

bug. Kalau tentang jumlah item di backlog, kita yang tadi sempat



299


diskusi ada sekitar 80 ya Pak, ya? Itu apakah ada angka maksimum

toleransinya?

J-36 : Untuk saat ini, kita belum punya. Belum punya. Pasti idealnya kan maunya

0. Tapi untuk maksimumnya … kita mesti lihat lagi. Belum ada sih

sekarang ini.

P-37 : Belum ada ya?

J-37 : Saya juga agak susah menemukannya, berapa yang harus backlog gitu.

Tergantung priority dan tergantung ininya juga.

P-38 : Dan bisa jadi juga item banyak di backlog juga sebetulnya tidak

dianggap masalah.

J-38 : Iya.

P-39 : Itu kan tergantung.

J-39 : Iya, again, backlog-nya ada yang nice to have, ada yang critical, ada yang

itu, itu. Berapa yang … mesti dipecahin satu-satu lagi.

P-40 : Baik, baik, baik. Kalau misalnya kita persempit nih, jangan backlog

total. Itu yang critical. Itu ada angka toleransinya? Misalnya 1 bulan

maksimum sekian, gitu? Untuk critical, kalau semua tadi kan ada

banyak ya? Ada yang nice to have. Belum ada juga ya nggak apa-apa.

J-40 : Belum ada sih sekarang.

P-41 : Baik. OK kita lanjut ke pertanyaan berikutnya, Pak. Apakah saat ini

sudah ada SOP … tadi tentang kinerja, kalau yang ini untuk

memperkirakan resource, Pak? Baik itu man-hour ataupun budget

dalam proses development atau maintenance.

J-41 : SOP belum ada, tapi memang biasanya dilakukan adalah dengan estimasi

berdasarkan expertise masing-masing. Jadi expertise. Misalnya

Department Head IT estimasi, kemudian kita confirm dulu ke bagian


300


business analyst-nya, kemudian kita confirm juga ke bagian developer-

nya. Biasanya cara counter check-nya begitu. Biasanya kita bikin … saya

sebagai IT Head bikin plan dulu, secara mungkin plan tahunan, atau plan

lima tahunan, tapi kemudian kita turunkan ke bagian masing-masing.

P-42 : OK. Seperti itu prosedurnya ya Pak, ya?

J-42 : Ya.

P-43 : Jadi sebenarnya ada, tapi berdasarkan experience.

J-43 : Betul.

P-44 : Valid sih sebetulnya. Ada di sini.

J-44 : Oh gitu.

P-45 : Dia bilang di nomor satunya. OK. Berikutnya adalah, kalau untuk

item backlog itu, yang tadi siang dikirim ke Bapak. Itu tadi kan saya

melihat ada beberapa item yang belum ada dia tanggal … tanggal …

eh bukan tanggalnya, maksudnya prioritasnya, Pak. Jadi ada

beberapa item yang prioritasnya belum bisa ditentukan.

J-45 : Iya.

P-46 : Itu saya tertarik di sini, kita ada nggak menentukan berapa

maksimum waktu yang diperlukan untuk analisis prioritas?

Katakanlah mungkin bukan backlog, tapi di …

J-46 : Prioritas ya?

P-47 : Iya, jadi ada item di tiket nih kita melihat ini kayaknya rumit tiket ini.

Jadi kita bingung menentukan … ini prioritasnya tinggikah?

Rendahkah? Nah jadi itu, kita menentukan prioritas itu …

J-47 : Dari mana?



301


P-48 : Ditentukan nggak waktunya?

J-48 : Biasanya kan gini, kalau ada project bukan yang … kalau yang high

project itu kita ada prioritas namanya, sekarang ya mulai ada, kita untuk

yang strategic project.

P-49 : Strategic project?

J-49 : Strategic project itu pasti udah di-approve manajemen, dan saya udah di

ini, itu high priority. Makanya yang udah ada tanggal-tanggalnya biasanya

itu strategic project yang kita pandang high priority dan strategic. Itu

datangnya dari … ini apa namanya … hasil meeting dengan bagian-bagian

lain. Itu satu project. Timnya pun ada tim strategic management yang

koordinir. Nah bagian IT yang mengerjakan. Nah, yang belum ada,

biasanya ini adalah yang feature-feature request yang diminta direct dari

… business user. Nah business user ini minta "oh, saya minta begini dong"

dan kita udah review, oh valid ini permintaannya. Cuma memang kita

belum bisa justify apakah ini high priority atau tidak. Makanya, makanya

… mungkin low lah berarti ya? Kalau yang ini low priority. Makanya

kalau ada nganggur baru dikerjain.

P-50 : OK.

J-50 : Nah problem-nya sekarang nganggurnya jarang-jarang, kan gitu. Selalu

ada strategic project, makanya saya, kita mau menentukan gimana caranya

membagi tim atau membagi apa namanya … metode yang bisa

mengakomodir dua-duanya, yang high juga dijalanin, yang low ini sedikit-

sedikit juga dikerjain.

P-51 : OK Pak. Berarti sebetulnya kita ada cara analisis prioritasnya ya?

Paling gampang yang namanya strategis pasti langsung high gitu?

J-51 : Iya.



302


P-52 : Terus yang dari business user komunikasi langsung, kalau kita susah

menjustifikasi apakah itu high atau low ya, kemungkinan besar bukan

high ya?

J-52 : Iya.

P-53 : Sebetulnya bisa begitu ya? Baik Pak. Kalau begitu berarti ada

caranya. Baik.

J-53 : Ada caranya tapi nggak didokumentasikan, nggak di-SOP-kan. Itu

mungkin kekurangan kita.

P-54 : Baik, baik. OK berikutnya, Pak. Di sini kalau kita melihat ke … ini

saya membahas sedikit tentang literatur ya Pak. Ada yang namanya

Software Engineering Body of Knowledge. Nah itu dari IEEE. Salah

satu kegiatan untuk maintenance, yang kalau perusahaannya

keterbatasan di staf, biasanya itu akan dilakukan yang namanya

outsourcing Pak.

J-54 : Iya.

P-55 : Nah, outsourcing itu … kita ada kegiatan outsourcing? Untuk

maintenance dan development. Jadi saya kepingin menyempitkan

dulu. Bukan, bukan yang di luar ini, bukan.

J-55 : Tidak. Untuk outsourcing ini belum. Dulu pernah dicoba. Kita hire

outsourcing, two resources. Tapi, kayak pekerja lepas outsourcing, bukan

pekerja lepas ya … apa namanya … ya kita outsource tapi bukan full

project outsource gitu. Cuma tambahin material, orangnya kita hire. Itu

kendalanya dulu apa ya? Kendalanya, mungkin kendala resources-nya

juga, tapi itu nggak work out buat kita, gitu. Nggak berjalan mulus lah.

Nah kita stop, akhirnya semua internal process, internal resource.



303


P-56 : Berarti kenapa sekarang tidak ada outsource untuk maintenance dan

development alasannya ini … apa namanya …

J-56 : Udah pernah dicoba.

P-57 : Lesson learned?

J-57 : Iya, lesson learned.

P-58 : OK.

J-58 : Udah pernah dicoba, ternyata nggak gampang juga. Apa ya? Nggak

gampang juga suruh ngejahitin program kita sama orang lain, gitu. Butuh

learning curve yang cukup tinggi ternyata.

P-59 : Baik … oh … berarti itu salah satunya ya, learning curve-nya tinggi

…

J-59 : Iya.

P-60 : … untuk program kita yang ini. Baik. OK itu pertanyaan nomor dua

belas. Tadinya saya mau nanya ini, ada target kinerjanya nggak,

cuman kan ternyata ke depannya sudah tidak lagi seperti itu. Baik,

kalau begitu ini pertanyaan terakhir, Pak. Cuman memang panjang,

Pak.

J-60 : Ya nggak apa-apa.

P-61 : Untuk ekspektasi manajemen yang sebelumnya dibahas. Yang ini

tadi. Yang ini barusan. Kan memang selama ini belum tertulis.

J-61 : Iya.

P-62 : Jadi, saya kepingin tahu, kalau menurut Bapak nih, karena memang

tidak dalam bentuk tertulis berarti kan kita susah melakukan tracking

nih … ini berapa yang terpenuhi? Berapa yang tidak? Gitu ya?



304


J-62 : Nah.

P-63 : Menurut Bapak itu tercapai nggak selama ini?

J-63 : Tidak optimal.

P-64 : Tidak optimal?

J-64 : Iya. Tercapai, yang critical-critical kita bisa. Makanya ini problemnya

justru yang critical-critical kita bisa selesaikan, tapi yang non-critical ini

rasanya pending-nya cukup banyak, makanya punya 80 list, ranging antara

2 week sampai dua, tiga bulan project-nya yang 80-an itu. Belum optimal

lah, kasarnya. Tercapai untuk yang critical doang kita bisa kerjain gitu,

tapi untuk yang ini kita nggak bisa kerjain. Makanya kita cari metodologi

baru, gimana caranya.

P-65 : Baik.

J-65 : Selain itu, kita juga mau udah diperbaiki secara ... secara company ini …

punya KPI yang jelas. KPI yang jelas ya. Pasti harus ada rencana yang

jelas, dan metodologi yang baru. Ini bareng-barengan kita mau apa

namanya … kita mau revamp. Makanya pilihan agile … kita kepikiran

bilang agile, apakah bisa membantu kita mencapai tujuan itu?

P-66 : Itu, itu bisa menjadi pertanyaan penelitian itu Pak. Baik, ini tadi

sebetulnya saya ingin drill down itu alasannya. Barusan kan tidak

optimal karena alasan utamanya kalau saya menangkap, yang critical

itu aja udah banyak, kita resource-nya sudah terpakai untuk itu, terus

muncul yang non-critical, biarpun sebetulnya valid dan penting untuk

bisnis PT XYZ, tapi jadi tidak tertangani karena banyaknya yang

critical, gitu. Berarti utamanya kan kalau saya melihat dari … people.

Dari, kalau kita melihat faktor-faktor yang mempengaruhi

kesuksesan atau keterlambatan proyek … jadi di sini saya bukan



305


ngomong khusus untuk maintenance aja tapi udah ke proyeknya. Kan

ada 4 utamanya, ada people, process, technology …

J-66 : OK.

P-67 : Ini yang umum, tapi untuk yang baru itu ada ditambah satu,

organizational. Ini kultur. Nah, kalau untuk domain people, ini tadi

sepertinya Bapak udah membahas sedikit tentang … sewaktu saya

bertanya tentang outsourcing ya? Di sini dia people itu salah satunya

adalah kompetensi pegawai itu sendiri. Kompetensi pegawai di sini

bisa dalam beberapa … bisa di-drill down lagi contohnya keahlian

dia. Misalnya coding. Bukan hanya coding tapi juga program

comprehension yang Bapak bilang tadi, learning curve-nya ternyata

tinggi.

J-67 : Iya.

P-68 : Nah, terus kemauan belajar dia, dan kemauan berbagi informasi juga

penting. Itu mempengaruhi nggak Pak? Apakah ini selama ini

menjadi …

J-68 : Mempengaruhi tapi bukan … apa ya … mungkin kita problem yang lebih

besarnya bukan di people, kalau menurut saya. Dari segi technical ya,

banyak yang … apa namanya … sudah cukup advanced dan cukup ini

memenuhi, gitu. Tapi secara tugas, kadang-kadang priority-nya itu yang

bikin tim kita agak changing tugas. Kalau changing tugas kan otomatis

harus mengulang beberapa, gitu. Itu satu. Saya lebih ke proses sih.

P-69 : OK.

J-69 : Makanya kenapa itu proses, prosesnya ini ... apa ya namanya ... prosesnya

belum optimal kalau menurut saya.



306


P-70 : OK. Itu faktor kedua adalah proses. Kalau di dalam software

development atau maintenance itu, pertanyaan yang biasa

dipertanyakan itu adalah: apakah kita ada metodologi yang baku

yang diikuti? Jadi setiap proyek itu, biasanya, ada semacam template

gitu. Yang namanya proses kan ada kegiatan, activity, ada input, kita

masukkan, dan ada output, kan kasarnya begitu.

J-70 : Iya.

P-71 : Terus proses dideretin, harapannya kita nanti masukkan sesuatu di

awal, di akhir keluarlah hasil yang kita inginkan.

J-71 : Iya.

P-72 : Idealnya … ada yang namanya kematangan. Awalnya kan seperti itu

ya kasarnya: input, process, output, dideretin. Yang lebih matang

sedikit, input, process, output, di antara masing-masing proses ini

diukur. Waktunya, tanggalnya, gitu. Terus nanti kematangan lebih

tinggi lagi, hambatannya apa di masing-masing proses ini? Yang lebih

tinggi lagi, hambatannya apa, itu dijadikan lesson learned, untuk ke

proses berikutnya, yang namanya continuous improvement. Nah itu

contohnya. Ada lagi, misalnya, kalau dalam proses development,

mungkin ada dia proses yang diikuti, yang baku, tapi begitu selesai,

hand over, terus mungkin dianggap sudah terlalu kaku gitu untuk

maintenance. Itu kita dulu ada nggak? Seperti itu?

J-72 : Justru untuk maintenance dan software development mungkin kita kurang

adalah dalam proses … apa ya … OK pasti ada lah prosesnya. Ada

gathering analysis, gathering requirement, bikin technical spec, terus,

bikin functional spec, eh bikin functional spec dulu, bikin technical spec,

kemudian coding, UAT, eh testing dulu baru UAT. Itu normal behavior

untuk software development gitu. Yang belum ada memang mungkin yang,

satu, belum ada yang seperti Jos bilang, belum ada orang yang melihat



307


bahwa "kekurangannya di mana sih?", "lesson learned-nya apa?", "apa

yang perlu improvement?", itu belum ada. Satu. Kemudian, belum ada juga

standar, orang development kan mengerjakan satu, misalnya coding gitu.

Dia belum ada standarnya coding-nya mesti bagaimana. Kita ada

framework, tapi kan coding kan kayak … apa ya? Menulis juga gitu. Kalau

menulis kan mesti ada, misalnya mesti ada pembuka, penutup, akhir. Akhir

itu harus consist of ini, ini, ini aja. Pembuka ini, ini, ini. Kita belum ada

juga. walaupun udah punya framework, misalnya framework MVP1. Oh

yang EJB ini ada di sini. Misalnya apa ya, kalau secara technical SQL

harus ada di EJB ini, gitu. Cuma, bener-bener standarnya yang harus ada

di sini itu apa, belum ada kita gitu. Mungkin itu yang perlu kita, kita bikin

juga.

P-73 : Baik Pak. Itu dari proses ya. Tapi ini, ini sebenarnya sudah terjawab

sih, tapi saya mau minta klarifikasi aja Pak. Kita sebelumnya pernah

melakukan pengukuran kematangan proses?

J-73 : Belum.

P-74 : Belum? Kalau boleh tahu Pak, itu kenapa belum ya Pak? Apakah

memang dipandang …

J-74 : Karena, ya belum … belum kepikiran, dan pasti hasilnya jelek. Jadi ini

belum ada process improvement lah gitu. Biasanya gitu.

P-75 : Sebetulnya Pak, salah satu tujuan dari pengukuran kematangan ini,

bukan untuk mencari jeleknya Pak. Justru untuk mencari bagusnya

di mana, jadi kita poin positifnya gitu ketahuan. Jadi bisa

dioptimalkan.

J-75 : Mungkin bisa direkomendasikan.

1 Maksudnya MVC (model-view-controller).

Lampiran B. Transkrip Wawancara Identifikasi Masalah (lanjutan) Lampiran B. Transkrip Wawancara Identifikasi Masalah (lanjutan)


308


P-76 : Baik. Kita lanjutkan ke pertanyaan berikutnya. SOP untuk

dokumentasi. OK ini sudah terjawab. Nah itu tadi ada people, process,

dan berikutnya adalah …

J-76 : Teknologi.

P-77 : Technology, ini barusan, bukan barusan, minggu lalu dengan Pak

IYB, Pak IYB ada menunjukkan saya Excel yang tadi Bapak

tunjukkan aku. Terus aku ingat Pak IYB pernah bilang itu mau di-

update ke depannya supaya bentuknya jangan seperti itu supaya

mudah tracking. Jadi saya menangkapnya, dengan dibilangnya,

dengan pernyataan seperti itu, berarti tool-nya itu, spreadsheet-nya

itu, sekarang ini kurang memfasilitasi untuk tracking Pak.

J-77 : Iya kita biasanya kan pakai, biasanya kita taruh di Excel dulu baru

kemudian naikin ke project plan, Microsoft Project. Itu kita mau upgrade

ke tools-tools yang ada sekarang ini yang lebih, lebih apa namanya …

lebih integrated dan lebih mumpuni lah, semacam … ya itu related juga

dengan metodologi yang kita mau pakai itu. Yang agile technology itu kan

ada tools-nya. Tools untuk development dan project management itu.

Contohnya tools yang kita lagi lihat itu, Bitrix, terus apa lagi, ya ada lah

yang kita mau upgrade ke situ. Kalau dari segi tools ya kita belum update

teknologi tapi mau update teknologi ke sana, gitu.

P-78 : Baik. Itu tadi dari sisi dukungan tools terhadap pemantauan proyek.

Nah kalau pemantauan proses development sendiri setahu saya baru

ada, kita udah ada, yang namanya Bugtracker. Tapi dia

kekurangannya, ya sama dengan file Excel itu, tidak ada … apa

namanya … tanggal ekspektasi selesainya. Terus dia tidak bisa di-

tracking itu perkiraan berapa persen selesainya.

J-78 : Nah iya, itu juga including, termasuk yang itu, metodologinya kita mau

upgrade sesuai dengan yang ini. Jadi collaboration. Collaboration tools



309


yang … dia plan dengan collaboration juga supaya developer-developer

ini bisa update langsung. Kalau sekarang kan mesti tunggu project

manager-nya dulu tanyain "berapa persen sih you?" Nah ini bisa langsung

update.

P-79 : Kita mau developernya proaktif lah gitu ya?

J-79 : Proaktif. Ada yang integrated, katanya ada yang bisa kalau deploy itu

ketahuan, ke-track gitu. Nah yang gitu.

P-80 : Baik, baik.

J-80 : Cuma dari segi teknologi agak ketinggalan juga.

P-81 : Itu kalau boleh tahu Pak, selama ini kenapa seperti itu prakteknya ya

Pak, ya? Biasanya kan ada hambatan. Apakah budget? Apakah

memang tool-nya selama ini dianggap sudah cukup?

J-81 : Ya, antara kebiasaan, dianggap sudah cukup. Sekarang cuma ininya aja …

apa … demand-nya naik, jadi kita perlu.

P-82 : Oh, karena ada yang 80 itu ya?

J-82 : Iya, iya.

P-83 : Makin ter-highlight ya, kalau tool-nya perlu di-upgrade, gitu ya? Baik

Pak. Itu tadi dia dari people, process, technology. Sekarang yang,

faktor yang baru juga nih, organisasi Pak. Kultur di organisasi.

Paling gampang itu … kalau ini udah bukan ngomong tentang IT lagi

ya Pak, ya. Tentang Quality Assurance. Misalnya produk asuransi kita

itu, ada prosesnya nggak Pak selama ini?

J-83 : Belum. Nggak ada.

P-84 : Oh? Di luar IT …



310


J-84 : Iya, di luar IT memang.

P-85 : Kayak … kalau nggak salah namanya ISO 9001?

J-85 : Iya, belum kita. Kita belum ke arah sana.

P-86 : Belum ke arah situ. Jadi secara strategi kita memang belum

mengarahkan ke situ?

J-86 : Belum. Belum ke arah situ.

P-87 : Baik. Udah terjawab semua ini. OK. Tadi kita salah satunya adalah

ada 80, gitu ya? Eh udah terjawab juga itu Pak. OK kalau gitu Pak.

Kita akhiri aja Pak, soalnya udah terjawab ini tadi. Ini udah terjawab

semua. Iya, OK itu aja dulu Pak. Terima kasih atas bantuannya Pak.

J-87 : OK. Terima kasih, sama-sama.



311


Lampiran C. Transkrip Wawancara Req1

Tanggal : 24 Mei 2017

Tempat : Ruang Rapat Lantai 4

Narasumber : Bapak IYB (Kepala Seksi Business Analyst)


Wawancara ini bertujuan untuk mencari tahu apakah praktek-praktek untuk KPA

Event/Request Management (Req1) dilakukan di Departemen TI.

P-1 : Selamat siang Bapak IYB, saya ingin bertanya tentang karya akhir

saya yang topiknya adalah software maintenance. Bapak adalah

kepala seksi dari Business Analyst. Kita bisa mulai?

J-1 : Silakan, Pak Jos.

P-2 : Baik. Pertanyaan saya adalah tentang KPA yang namanya

Event/Request Management.

J-2 : Iya.

P-3 : Req1.0.1 Pertanyaan pertama saya adalah apakah Departemen TI ada

menugaskan, merekam, mengendalikan, mengukur hal-hal yang

berkaitan dengan kejadian-kejadian, atau permintaan layanan dari

user?

J-3 : Ada.

P-4 : Req1.0.1 Ada?

J-4 : Iya.

P-5 : Req1.1.1 OK, saya lanjut pertanyaannya. Karena ada, apakah

pengaturan tersebut secara formal atau informal?


312


J-5 : Iya, sekarang ini memang ada, di job description masing-masing section

itu sudah disebutkan secara detail, apa-apa yang menjadi tugas dan

tanggung jawab di section-nya. Ada juga, apa namanya, instruksi detail

mengenai pengukurannya. Nah, kalau dibilang formal, saya akan jawab itu

formal, karena pengaturannya jelas di job description. Tetapi, peraturan

pelaksanaan dari job description-nya itu sendiri yang menjelaskan lebih

detail, bagaimana itu harus diukur, bagaimana itu harus dikendalikan, itu

yang selama ini belum ada.

P-6 : Req1.1.2, Req1.2.1 Baik kita lanjut lagi. Pertanyaan berikutnya adalah

penanganan kejadian atau permintaan dari pengguna berbeda-beda

oleh setiap petugas? Ataukah ada standarisasi alur penanganan?

Apakah ada penanganan di mana tergantung pada relasi antara

petugas – dalam hal ini bisa dalam arti Business Analyst atau

programmer-nya – relasinya dengan pengguna yang meminta? Atau

apakah interaksi antara pengguna dengan organisasi maintenance itu

berbeda-beda tergantung antara hubungan pribadi mereka?

Bagaimana menurut Bapak?

J-6 : Iya, kalau, saya akan jawab untuk standarisasi alur penanganannya dulu.

Iya, di kita kan sudah ada standarisasi untuk alur penanganan suatu change

request atau permintaan perubahan, dan itu karena framework-nya sudah

standar, siapa pun yang menjalankan itu, baik dia masuk ke level section,

atau ke level officer, dia akan menerima bentuk layanan yang sama dari

Business Analyst. Kemudian, kalau ada perbedaan dari penanganan kita,

itu yang lebih dominan biasanya terjadi apabila permintaannya dari level

manajemen. Apalagi kalau perubahannya itu sudah dalam bentuk

kebijakan perusahaan. Biasanya kita akan naikkan prioritasnya menjadi

lebih tinggi. Selama itu tidak ada perbedaan tersebut, penanganan kita bisa

dibilang first in first out. Yang membedakan adalah bobot project-nya.

Kita menyusun prioritas berdasarkan bobot project-nya dan impact-nya.

Semakin tinggi atau semakin luas impact-nya maka prioritasnya akan naik.

Lampiran C. Transkrip Wawancara Req1 (lanjutan)


313


Itu saja yang membedakan. Nggak ada perbedaan perlakuan berdasarkan

kedekatan hubungan antara user kita dengan kami di Business Analyst.

P-7 : Req1.2.1 Baik kita lanjut ke pertanyaan berikutnya. Apakah antara

Departemen TI dan masing-masing pengguna atau pelanggannya itu

sudah memiliki contact person masing-masing untuk tiap-tiap layanan

maintenance? Bagaimana menurut Bapak?

J-7 : Iya, di kita ada yang menjadi counterpart yang kita sebutnya module

owner. Jadi setiap ada permintaan perubahan aplikasi oleh user, bagian

Business Analyst akan berkonsultasi, akan berdiskusi dengan module

owner tersebut. Kita terbagi menjadi beberapa kategori besar, di masing-

masing sudah ada PIC-nya, untuk underwriting dan claim, kemudian

untuk finance, accounting, dan untuk marketing.

P-8 : Req1.2.1 Kalau begitu saya bertanya, itu ada dokumentasinya Pak?

Misalnya dalam bentuk file Excel, jadi departemen ini contact person

di departemen itu adalah si anu, tapi di Departemen TI contact

person-nya adalah si anu. Jadi kelihatan jelas antara departemen –

katakanlah marketing dengan IT – masing-masing contact person-nya

siapa. Ketahuan nggak?

J-8 : Iya, ada. Kita bisa lihat, karena sudah di-SK-kan dari perusahaan. Jadi

sudah ada aturan tertulisnya mengenai siapa akan handle apa. Jadi SK itu

berkesinambungan, pada waktu ada module owner – misalnya – berhenti

karena pensiun, itu sudah ada SK penunjukan baru yang menggantikan

module owner tersebut. Jadi dari sisi perusahaan juga sudah

mendokumentasikan itu dalam bentuk surat keputusan.

P-9 : Req1.2.2 Baik. OK, pertanyaan berikutnya. Apakah tiap permintaan

oleh pengguna, atau tiap-tiap insiden, direkam dalam suatu sistem

kita. Misalnya oleh help desk-nya atau user-nya itu sendiri untuk

merekamkan permintaan itu sendiri.



314


J-9 : Iya. Di kita ada. Proses recording yang kita gunakan ada dua nih

sebetulnya. Yang pertama yang kita kenal sebagai sistem ticketing. Dan

bug tracker. Sistem ticketing ini cara kita untuk melakukan dokumentasi

terhadap permintaan user, jadi interaksinya dari user ke kita nanti ada

petugas yang melakukan split masuk ke bagian mana-mana. Yang kedua,

yang kita sebut sebagai bug tracker itu lebih ke komunikasi internal antara

Business Analyst dengan Development, Business Analyst dengan System

Analyst, yang di situ juga ada framework cara penggunaannya. Biasanya

kita mencantumkan inti dari permintaan user seperti apa. Di sana juga kita

berikan, kita jelaskan, perubahan itu harus ditanggapi oleh IT dalam

bentuk aplikasi yang seperti apa. Itu ada dokumentasinya.

P-10 : Req1.2.3 Berarti dari dalam bug tracker atau dalam ticketing kita, itu kita

sanggup nggak – kita maksudnya Departemen TI – sanggup nggak,

kita membedakan yang mana yang merupakan support request, yang

mana yang merupakan modification/change request, mana yang

merupakan problem report atau incident report, itu bisa atau nggak?

J-10 : Bisa, karena di masing-masing problem yang masuk ke IT itu nanti sudah

ada pengategorian dari masing-masing ininya, masing-masing

permasalahannya. Jadi setiap user sudah bisa langsung tahu apakah

permintaan itu permintaan maintenance, biasa atau permintaan perubahan.

Bahkan permintaan seperti ... apa ... ada gangguan terhadap jaringan,

error, itu juga sudah bisa terkategorisasi di sana.

P-11 : Req1.2.3 Baik. Pertanyaan yang berikutnya. Pada saat ada permintaan

dari pengguna, atau dari stakeholder lainnya, itu apakah kita ada

penyaringan, dalam arti itu kalau diterima apakah, oh maksudnya

apakah kalau permintaan masuk, kita bisa memutuskan ini diterima,

apa ditolak, ada prosedurnya? Terus kalau diterima, itu apakah akan

disebar lagi ke masing-masing seksi, atau setelah itu kategori

layanannya, baru misalnya ditentukan prioritasnya, baru misalnya



315


setelah itu ditentukan perkiraan ukuran dan lingkup kerjanya? Terus

yang melakukan itu sudah ditentukan belum, siapa yang melakukan

perkiraan-perkiraan ini?

J-11 : Iya, kalau di awal tadi kita sudah pernah sampaikan, itu kan ada yang

namanya sistem ticketing. Sistem ticketing, splitter-nya itu dilakukan oleh

help desk. Dia yang akan mengategorikan permasalahan, kemudian kalau

sudah masuk ke Business Analyst, di kami juga ada penyaringan lagi. Di

section, itu akan melihat apakah di masing-masing officer itu project in

hand-nya masih memungkinkan untuk diberikan tambahan project baru.

Kemudian, kita juga sebetulnya sudah bagi, officer A itu akan handle

untuk masalah-masalah yang berkaitan dengan – misalnya – finance

accounting, officer B akan handle masalah-masalah yang berkaitan dengan

marketing dan underwriting. Nah, kita akan lihat, apakah permasalahan

atau permintaan itu masuk dalam kategori itu dulu apa tidak. Akan terpisah

berdasarkan kategorinya dan PIC yang meng-handle-nya. Itu yang

pertama. Yang kedua, kita juga akan melihat prioritasnya. Untuk

pertanyaan mengenai apakah permintaan yang masuk itu akan diterima

atau ditolak, wewenang tidak ada di kita. Biasanya Business Analyst

memberikan opsi terhadap setiap permintaan perubahan itu, dan biasanya

juga sudah kita lengkapi dengan apa advantage-nya dan apa faktor

minusnya. Jadi kelebihannya apa kalau opsi itu dipilih, dan apa

kekurangannya opsi itu jika dilakukan. Nah, nanti untuk keputusan ini kita

biasanya akan berkonsultasi dengan departemen terkait, atau dengan Dept.

Head IT, atau dengan user-nya sendiri. Keputusannya ada di mereka, jadi

di Business Analyst tidak menolak atau menerima permintaan, bukan di

situ. Tapi kita memberikan analisisnya dilengkapi dengan plus minus-nya.

P-12 : Req1.2.3 Baik. Sama perkiraan ukuran dan lingkup kerja, ini yang

menentukan juga dari Business Analyst ya Pak?



316


J-12 : Untuk perkiraan selesainya permintaan biasanya kita konsultasi dengan

System Analyst dan Development. Jadi mereka yang akan menghitung

apakah pekerjaan tertentu ini alokasi waktunya, resource-nya perlu berapa

orang, itu di Business Analyst tidak ada, tidak sampai ke sana. Jadi

Business Analyst hanya menyampaikan kepada user, setelah berdiskusi

internal dengan System Analyst dan Development.

P-13 : Baik. Saya ingin klarifikasi sedikit di sini Pak. Kita kan menggunakan

istilah project tadi ya? Di sini maksudnya permintaan dari user itu,

apakah akan dikategorikan yang mana yang akan menjadi project,

atau mana yang akan dianggap sebagai suatu permintaan ad-hoc?

J-13 : Kalau suatu permintaan itu sudah masuk ke budget IT, jadi sudah

disampaikan satu tahun, sebelum tahun berjalan, maka permintaan

perubahan yang disampaikan itu disusun dalam annual planning. Itu kita

sebut project. Yang ad-hoc adalah permintaan-permintaan yang

disampaikan dalam tahun berjalan, yang memang belum ada atau belum

termasuk dalam permintaan yang disampaikan dalam tahun sebelumnya.

Biasanya project itu yang sifatnya strategic. Sedangkan yang ad-hoc

biasanya atas dasar operasional, misalnya tiba-tiba ada perubahan regulasi,

atau kebijakan internal perusahaan.

P-14 : Req1.2.4 Baik. Kita lanjut ke pertanyaan berikutnya. Apakah jika ada

suatu change request atau modification request, apakah kita

menentukan itu akan dirilis ke versi perangkat lunak berapa?

Apakah ditentukan tanggalnya? Jadi apakah kita memberikan suatu

kepastian kepada para pengguna atau para pelanggan kita bahwa

permintaan mereka yang sudah disepakati, yang sudah disetujui, itu

akan kapan mereka bisa mengaksesnya, bisa menggunakannya?

J-14 : Untuk penetapan delivery permintaan itu kapan, kita harus berdiskusi

internal dengan System Analyst dan Development. Untuk versi berapa



317


perangkat lunak yang akan dirilis, itu juga kita tidak ada statement khusus

kepada user kita.

P-15 : Baik. Itu mengakhiri wawancara kita tentang KPA Event/Request

Management. Terima kasih Pak IYB.

J-15 : Sama-sama.



318


Lampiran D. Transkrip Wawancara Evo4



Narasumber : Ibu TYS (Staf System Analyst)

Masa Kerja : 7,5 tahun


Verification and Validation (Evo4) dilakukan di Departemen TI.

P-1 : Evo4.0.1 Di sini saya akan bertanya kepada Ibu tentang topiknya yang

namanya Verification & Validation. Pertanyaan pertama, apakah

Departemen TI melakukan kegiatan verifikasi dan validasi untuk

pemeliharaan perangkat lunaknya?

J-1 : Kalau untuk saya sendiri saya melakukannya terutama untuk proyek-

proyek yang besar.

P-2 : Berarti dilakukan Ibu ya. Baik. Pertanyaan berikutnya adalah

apakah kegiatan verifikasi dan validasi – tadi katanya kita melakukan

– apakah itu dilakukan secara terstruktur dan terkoordinasi?

J-2 : Untuk proyek-proyek yang dilakukan, terstruktur dan terkoordinasi.

P-3 : OK. Saya perlu klarifikasi sedikit, yang dimaksud dengan proyek

termasuk yang ad hoc? Yang muncul tiba-tiba, request dari user.

J-3 : Bukan proyek besar maksudnya?

P-4 : Evo4.1.1 Iya, skopnya di sini soalnya request.

J-4 : Tergantung.

P-5 : Evo4.1.1 Berarti ada yang dilakukan, ada yang tidak?

J-5 : Iya, ada yang dilakukan, ada yang tidak.


319


P-6 : Evo4.1.1 Apakah verifikasi dan validasi itu ada rencananya? Artinya kita

sudah tahu apa yang mau dibangun, apa yang ingin divalidasi? Dan

kita sudah ada daftar requirement, yang akan diverifikasi? Itu sudah

ada dari awal?

J-6 : Ada.

P-7 : Evo4.1.1 Itu bentuknya seperti apa ya?

J-7 : Dokumentasi, biasanya sih dalam dokumentasi Excel atau Word.

P-8 : Evo4.1.1 Tapi itu tidak semua ya? Sebagian?

J-8 : Kalau saya, sebagian.

P-9 : Evo4.1.1 Sudah ada cara, kriteria untuk membagikan mana yang

dilakukan, mana yang tidak? Seperti apa request yang perlu divalidasi

dan diverifikasi? Seperti apa request yang sudah langsung digolkan?

J-9 : Biasanya ada proyek besar, ada permintaan-permintaan dadakan, ad hoc

tadi. Kalau proyek besar yang memang dari awal ada meeting-nya,

biasanya saya buat. Kecuali kalau ad hoc yang kecil-kecil. Karena

biasanya kalau ad hoc itu harus segera, karena dibutuhkan secepatnya. Nah

untuk itu biasanya tidak dilakukan secara formal. Mungkin hanya lewat

tiket, atau lewat email. Tidak benar-benar formal yang ada dokumentasi

tertulis. Kalau yang besar kan ada tanda tangan.

P-10 : Ini konteksnya tidak harus ada tanda tangan sih. Lebih ke arah, itu

sebetulnya dilakukan nggak verifikasi dan validasinya untuk yang

kecil-kecil.

J-10 : Kalau yang kecil-kecil biasanya melalui tiket atau email. Ada permintaan

lewat situ.

P-11 : Ada permintaan lewat situ, diverifikasi, divalidasi?

Lampiran D. Transkrip Wawancara Evo4 (lanjutan)


320


J-11 : Divalidasi.

P-12 : Sebagian?

J-12 : Sebagian. Kalau yang harus buru-buru, biasanya lebih, saya tes terus

mereka harus cepat, kalau nggak ada waktu.

P-13 : Evo4.2.1, Evo4.2.2 Klarifikasi sedikit ya? Untuk yang kecil-kecil, sebagian

diverifikasi?

J-13 : Iya.

P-14 : Evo4.2.1, Evo4.2.2 Yang kecil-kecil itu kita nggak minta ke user untuk

validasi, tapi hanya Ibu yang yang melakukan verifikasi?

J-14 : Iya. Kebanyakan seperti itu. Kasusnya banyak.

P-15 : Evo4.2.1, Evo4.2.2 Berarti pertanyaan berikutnya, apakah pengujian

dilakukan secara sporadis, sudah terjawab.

J-15 : Ha ha.

P-16 : Evo4.2.1, Evo4.2.2 Tidak terencana juga sudah terjawab.

J-16 : Kadang terencana kadang tidak.

P-17 : Evo4.2.1, Evo4.2.2 Tergantung besar kecil tadi ya?

J-17 : Iya.

P-18 : Evo4.2.2 Sebetulnya skopnya di sini adalah yang kecil-kecil, yang ad hoc

request itu. Berikutnya adalah, apakah rencana pengujian baru dibuat

setelah perubahan itu selesai? Dari awal sudah tahu apa yang mau

diuji? Dalam bentuk dokumentasi tertulis?

J-18 : Iya. Rencananya ada. Tidak dalam bentuk dokumentasi tertulis.



321


P-19 : Pengujian itu pakai tool khusus, apa manual?

J-19 : Iya manual.

P-20 : Pengujian itu pakai tool khusus, apa manual?

J-20 : Iya manual.

P-21 : Kegiatan debugging itu dianggap testing apa maintenance?

J-21 : Bukan testing itu.

P-22 : Saat ada produk setengah jadi, apakah ada verifikasi dan validasi?

Saat ada intermediate product dihasilkan? Ada checklist-nya? Jadi

produk setengah jadi tersebut ada, requirement ini sudah dipenuhi, itu

belum, begitu?

J-22 : Itu lebih tepat ditanyakan ke Software Developer.

P-23 : Evo4.2.4 Untuk acceptance test, apakah dilakukan berdasarkan prosedur

yang terdokumentasi?

J-23 : Ini lebih ke test scenario kan? Itu bagiannya Business Analyst. Tapi ada.

P-24 : Evo4.2.5 Untuk regression test, kita ada nggak?

J-24 : Secara formal tidak ada kewajiban tertulis harus dilakukan, tapi biasanya

saya melakukannya untuk melihat oh ini masih error apa nggak.

P-25 : Evo4.2.5 Berarti berdasarkan inisiatif sendiri ya?

J-25 : Iya.

P-26 : Evo4.2.5 Sudah ada daftar hal-hal yang perlu diuji, atau berdasarkan

perasaan saja?

J-26 : Biasanya pengujian berdasarkan apabila bug yang kemarin, saya uji ulang.



322


P-27 : Evo4.2.6 Pada saat kita melakukan deployment, itu sudah dengan

persetujuan pengguna? Misalnya saat ada change request.

J-27 : Harus ada persetujuan. Bisa lewat telepon.

P-28 : Evo4.2.6 Bisa lewat telepon. Ada isi formulir, untuk permintaan kecil?

J-28 : Kalau untuk permintaan kecil nggak. Nggak tertulis.

P-29 : Evo4.2.6 Prosedurnya ada nggak, untuk memintakan persetujuan itu?

J-29 : Nggak ada prosedur yang mengharuskan “tanya dulu”. Inisiatif sih.

P-30 : Evo4.2.7 Saat deployment, apakah itu mengganggu orang? Apa dari

semua cabang jadi tidak bisa akses? Sistemnya mati, saat itu sama

sekali tidak ada yang bisa akses?

J-30 : Iya seperti itu.

P-31 : Evo4.2.8 Saat UAT, maintainer ikut partisipasi? Menyaksikan?

J-31 : Tidak, tidak ada alasan untuk itu.

P-32 : Evo4.2.8 Setelah deployment, apakah diuji apa fitur baru memang sudah

bisa dipakai?

J-32 : Iya oleh saya. Tapi developer tidak ikut.

P-33 : Baik. Terima kasih atas partisipasinya. Ini mengakhiri pertanyaan di

topik verifikasi dan validasi. Terima kasih dan selamat siang Ibu TYS.

J-33 : Selamat siang.



323


Lampiran E. Transkrip Wawancara Sup2






Process, Service, and Software Quality Assurance (Sup2) dilakukan di

Departemen TI.

P-1 : Baik, Ibu TYS. Saya lanjutkan pertanyaannya untuk topik Process,

Service, and Software Quality Assurance. Skop adalah software

maintenance, di mana permintaan yang kita handle adalah

permintaan yang kecil, jadi bukan proyek.

J-1 : OK.

P-2 : Pertanyaan pertama, apakah Departemen TI melakukan kegiatan

atau proses penjaminan mutu atau quality assurance? Setahu Ibu?

J-2 : Kalau saya sih, tidak.

P-3 : Sup2.0.1 Tidak dilakukan setahu Ibu. Baik, Ibu kalau tentang quality

assurance itu sendiri pernah dengar ya?

J-3 : Pernah dengar tapi tidak tahu secara detail.

P-3 : Departemen TI pernah nggak bertanya-tanya tentang quality

assurance?

J-3 : Setahu saya tidak, tapi lebih tepat ditanyakan ke Pak IWYS2.

2 Kepala seksi Application Development.


324


P-4 : Baik. Itu mengakhiri pembahasan kita tentang topik Process, Service,

and Software Quality Assurance. Terima kasih.

Lampiran E. Transkrip Wawancara Sup2 (lanjutan)


325


Lampiran F. Transkrip Wawancara Sup1






Configuration and Version Management (Sup1) dilakukan di Departemen TI.

P-1 : Baik, Ibu TYS. Berikutnya adalah tentang topik Configuration and

Version Management. Ibu TYS setahu saya ada menyimpan dokumen-

dokumen bahan pengembangan Sistem Informasi Asuransi Umum

dari dulu ya, dari awal ya?

J-1 : Khusus proyek reinsurance.

P-2 : Khusus proyek reinsurance saja?

J-2 : Iya.

P-3 : Yang lain-lain?

J-3 : Yang lain-lain saya belum ikut.

P-4 : Sup1.1.1 Kalau dokumentasi non reinsurance yang baru-baru ada di

situ?

J-4 : Disimpan tapi tidak secara terstruktur. Hanya simpan biasa. Nggak lewat

SVN, nggak lewat CVS. Jadi tanpa version.

P-5 : Sup1.1.1 Itu Ibu TYS menyimpan ke dalam SVN, ada sosialisasi ke

developer bahwa ada versi yang disimpan ke dalam SVN itu?

J-5 : SVN tidak untuk dokumentasi saat ini. SVN itu yang terstruktur dan

terkoordinasi cuma punya BaliCamp dulu.


326


P-6 : Sup1.1.1 Dulu. Berarti setelah selesai BaliCamp, jadi setelah handover

Sistem Informasi Asuransi Umum ke kita itu sudah tidak di-update

lagi?

J-6 : Tidak, karena itu menurut saya itu porsinya BaliCamp. Yang update harus

orang-orang BaliCamp. Jadi apabila ada perubahan-perubahan tidak di-

update di dokumentasi itu.

P-7 : Sup1.1.1 Baik. Saya perlu klarifikasi, bahwa dokumentasi kita itu

sebenarnya sudah masuk SVN?

J-7 : Belum masuk. Kalau dokumentasi nggak ada yang di SVN. Yang

reinsurance tadi itu punya BaliCamp. Jadi kalau yang sekarang ini,

misalnya ada CR, itu tidak masuk ke SVN. Kalaupun ada bug reinsurance,

itu tidak meng-update SVN BaliCamp.

P-8 : Baik sudah terjawab. Itu mengakhiri wawancara kita tentang

Configuration and Version Management. Terima kasih atas

partisipasinya.

J-8 : Terima kasih sama-sama.

Lampiran F. Transkrip Wawancara Sup1 (lanjutan)


327


Lampiran G. Transkrip Wawancara Pro2, Req2, Evo1, Evo2, Evo3, Sup1,

Sup2, Sup3, Sup4, dan Sup5



Narasumber : Bapak IWYS (Kepala Seksi Application Development)



berikut dilakukan di Departemen TI:


2. Maintenance Planning (Req2)

3. Predelivery and Transition Services (Evo1)

4. Operational Support Services (Evo2)

5. Software Evolution and Correction Services (Evo3)

6. Configuration and Version Management (Sup1)


8. Maintenance Measurement and Analysis (Sup3)

9. Causal Analysis and Problem Resolution (Sup4)

10. Software Rejuvenation, Migration, and Retirement (Sup5)

P-1 : Saya ingin mewawancarai Bapak dengan beberapa, bukan

beberapa, banyak pertanyaan yang berhubungan dengan software

maintenance.

J-1 : Baik.

P-2 : Di sini kita ada beberapa topik – yang saya sebutnya sebagai KPA –

ada 10 topik.

J-2 : Wah.

P-3 : Kita mulai dengan Maintenance Process/Service Definition.

Pertanyaan pertama, apakah Departemen TI ada melakukan


328


aktivitas untuk mendefinisikan proses atau layanan? Silakan Pak.

Kalau kurang jelas boleh ditanya, Pak.

J-3 : Nah, maksudnya?

P-4 : Maksudnya begini, Pak. Kita di Departemen TI, ada nggak yang

bertugas untuk mendefinisikan kita ini sebenarnya yang dikerjai ini,

ini, ini, gitu, layanannya ini, ini, ini, SI yang diurus oleh kita yang

ini, yang ini, yang ini, kaya gitu.

J-4 : Secara itunya dari job description sih saya lihat di ininya. Itu bisa disebut

sebagai itu nggak?

P-5 : Bisa.

J-5 : Ada berarti.

P-6 : Ada ya. Baik. Untuk itu formal berarti ya karena sudah ada di job

description.

J-6 : Iya.

P-7 : Tapi itu berarti kalau tidak ada di job description kita lakukan apa

nggak?

J-7 : Ada yang dilakukan ... istilahnya ya kemarin itu ya ... yang sudah kayak

... apa namanya ... keseharian gitu. Tapi biasanya sih ada di job

description, mostly sih ada di job description yang sekarang ini.

P-8 : OK, berarti kalau misalnya saya ringkas, di Departemen TI layanan

apa yang kita – secara departemen – menyediakan kepada para

pengguna kita, baik internal maupun eksternal, itu lihatnya dari job

description masing-masing posisi ya?


Sup2, Sup3, Sup4, dan Sup5 (lanjutan)


329


J-8 : Iya

P-9 : Baik. Saya lanjut ke pertanyaan berikutnya. Masing-masing orang,

layanan yang diberikan itu bersifat teknis apa tidak, Pak? Misalnya

Bapak sebagai Software Developer. Untuk dalam hal maintenance ini

layanannya berupa layanan teknis, atau Bapak juga menyediakan –

misalnya – kalau dipanggil, bisa tolong jelaskan alur program ini,

gitu?

J-9 : Lebih ke teknisnya. Kalau di development.

P-10 : Baik. Berikutnya adalah, kita ada nggak seksinya atau misalnya

orangnya yang bertugas untuk mendefinisikan standar aktivitas

kita, Pak? Gampangnya gini, kalau misalnya developer mau tambah

fitur, yang membuat prosedurnya seperti apa itu siapa ya?

J-10 : Ada sih, dari BA seharusnya. Dia yang sebagai pintu masuk sebenarnya.

P-11 : Kalau di kita?

J-11- : Iya di kita. Kalau kita section head Pak IYB, kalau di PT XYZ.

P-12 : Kita ada nggak, dokumentasi proses perawatan perangkat lunak?

Misalnya daftar personil kita siapa saja. Daftar tools yang kita pakai

apa saja. Perangkat lunak yang kita maintain apa saja. Lingkungan

kerja kita yang tersedia apa saja. Istilahnya, inventor kita ada

nggak?

J-12- : Nah, ini nih yang belum ada.

P-13 : Nggak ada ya Pak?




330


J-13- : Belum terdokumentasi. Ininya ada, sebenarnya di level 1 kayak yang Jos

bilang tadi, tapi kita melakukan masing-masing. Belum terorganisir

ininya.

P-14 : Baik kalau begitu. Jadi kalau dibilang di seksi Application

Development, belum ada orang yang ditunjuk sebagai koordinator

dokumentasi misalnya?

J-14- : Belum.

P-15 : Baik. Lanjut. Bapak di sini sebagai kepala seksi bertanggung jawab

untuk pemeliharaan perangkat lunak. Itu Bapak ada mendukung

semacam, misalnya mempromosikan ke bawahan, atau

memperkenalkan ke atasan, tentang standar-standar yang berkaitan

dengan pemeliharaan perangkat lunak? Contoh: ISO 9001, ISO

12207, yang beginilah, ini ada daftarnya. Nggak harus yang ISO

seperti ini, misalnya framework seperti CMMI-DEV. Ada nggak

Bapak memperkenalkan seperti itu, entah ke atasan atau ke

bawahan?

J-15- : Masih informal. Kalau ISO itu hanya ini saja, kita nggak terapkan secara

baku ininya dalam suatu prosedur gitu. Masih pengenalan-pengenalan.

P-16 : Kalau ISO ini ada yang pakai audit, dan ada yang tidak pakai audit,

hanya memberi tahu itu perlu dilakukan seperti ini, seperti ini,

terserah kita mau memenuhi apa tidak, dan tidak ada auditnya.

Berarti yang Bapak maksud, sudah diperkenalkan, tapi tidak

diterapkan secara formal.

J-16 : Bisa dibilang begitu. Karena yang sehari-hari kita lakukan sebenarnya

sudah itu kan, cuma kita nggak mengacu satu standar yang baku.




331


P-17 : Dan demikian, itu sudah selesai untuk satu topik, Maintenance

Process/Service Definition. Kita lanjut ke topik berikutnya. Yang

namanya Maintenance Planning. Pada saat kita melakukan

maintenance, itu kalau berdasarkan framework ini idealnya adalah

ada perencanaannya. Perencanaan tahunan, misalnya tahun ini

akan melakukan maintenance sistem ini, sistem ini, sistem ini. Kita

ada nggak seperti itu?

J-17 : Maintenance dalam arti upgrading atau menambah fitur CR?

P-18 : Req2.0.1, Req2.1.1, Req2.1.2, Req2.1.3, Req2.2.1 Termasuk. Ini menurut saya

termasuk upgrading. Contoh kegiatannya ada yang restrukturisasi,

reengineering, redocumentation, dan reverse engineering. Jadi

misalnya ini ada software yang sudah lambat, banyak yang

komplain, terus kita mau bilang “OK, tahun depan kita akan

melakukan suatu kegiatan restrukturisasi atau reengineering supaya

dia jalannya lebih cepat.”

J-18 : Untuk sekarang sih belum. Tapi sudah mengarah ke situ, artinya dari

beberapa bagian kan, terutama semenjak akan dimulai KPI itu, jadinya

itu sudah menjadi tuntutan, gitu. Yang ter-schedule sih, Pak RK space-

nya cuma project plan, biasanya nggak di-state jelas-jelas bahwa ini

harus begini, itu belum. Itu jadi kayak task sampingan. Bukan dari major.

Kalau major kan yang bisnis, permintaan-permintaan user, tapi tidak

memperbaiki secara menyeluruh. Belum sih.

P-19 : Req2.2.6 Itu yang kalau versi tahunan. Nah kalau ini misalnya,

konsepnya proyek, bukan request, ada yang namanya predelivery and

transition. Contoh predelivery adalah, sebelum proyek itu deliver,

sudah ada yang namanya perencanaan maintenance. Yang

direncanakan itu misalnya, bagaimana cara menguji, bagaimana

cara rollback, bagaimana saat mau diserahkan dari developer ke




332


maintainer itu perlu ilmu apa saja yang dia paham. Terus dia perlu

tahu tool apa saja. Terus struktur file seperti apa saja. Itu contoh

kegiatan predelivery. Contoh kegiatan transisi, saat betul-betul sudah

diserahkan ke maintainer, dia akan mendapatkan daftar outstanding

defect, daftar masalah yang belum dipecahkan tapi karena software

sudah harus online maka dia harus mendapatkan masalah

istilahnya. Terus user juga harus paham bahwa dalam masa transisi

programnya nggak akan bisa 100% kapasitas, gitu. Dan lagi nanti

saat transisi itu orang support juga harus paham dia akan

mendapatkan bug dengan kategori baru. Itu ada direncanakan

nggak, sebelum proyek selesai.

J-19 : Ada. Yang terkait pengembangan di seksi kita orangnya terbatas, saya

dan saya juga orangnya. Yang melakukan ya nggak perlu dokumen,

karena sudah ada di kepala. Tapi terkait untuk isu-isu itu sudah ada

dokumennya. Kita mau rilis nih, itu yang belum, a, b, c, d, itu sudah kita

state ketika kita mau live itu yang ini nggak bisa, ini nggak bisa, ini

nggak bisa gitu ke user. Jadi kalau ada yang ini, dilakukan apa itu

sebelum di-launch, itu sudah ada, entah di-share dokumennya. Kalau ada

x, maka lakukan ini, gitu. Kalau tidak terpecahkan, maka kontak support.

P-20 : Berarti sebenarnya sudah dilakukan, baik. Berarti sudah dilakukan

secara terencana. Dalam rencana maintenance misalnya untuk

kegiatan predelivery and transition, sudah ada rincian-rincian obyek

yang perlu dipelihara itu. Itu kan tidak harus SI itu sendiri, tapi bisa

juga database-nya ini, tabelnya ini, gitu. Skopnya bagaimana, tujuan

dan sasaran dari rencana itu ada, gitu. Deliverable dari maintenance

itu apa saja. Istilahnya, ada formalnya nggak sih?

J-20 : Nggak ada.




333


P-21 : Req2.2.2 Ada nggak, jadwal reguler untuk memperbaharui rencana

pemeliharaan tersebut. Jadi rencana pemeliharaan itu di-update

nggak? Secara berkala?

J-21 : Kalau yang kemarin, ada sih, di-update. Memang sudah kita plan, nanti

kita launch, karena terkait dengan third party juga, cuma waktunya

kapan belum ditentukan.

P-22 : Req2.2.2 Berarti kita nggak ada kegiatan berkala untuk update

maintenance plan?

J-22 : Belum ada sih.

P-23 : Baik.

J-23 : Karena yang kita punya ini kebanyakan ... apa istilahnya ya ... barang-

barang yang jalan di tempat gitu, bukan sesuatu yang bisa bertambah

terus.

P-24 : Req2.2.4, Req2.2.15 Sebenarnya ada Pak, kita sudah Java 7 sekarang.

J-24 : Itu pun tanpa perencanaan. Mestinya kan regular update. Itu karena takut

tidak compatible. Kemarin itu sudah harus, mungkin. Karena meng-

upgrade ininya kan ... app server-nya itu, sudah naik versi sudah nggak

bisa lagi running pakai runtime yang lama.

P-25 : Alasan upgrade ke 10g dulu apa ya?

J-25 : DB-nya juga sudah naik, itu satu paket.

P-26 : Berarti alasan Java mesti di-upgrade karena app server 10g mesti

dinaikkan. App server 10g mesti dinaikkan karena DB-nya mesti

dinaikkan. DB-nya mesti dinaikkan karena?




334


J-26 : Fitur-fitur barunya, enterprise management. DB-nya itu ada enterprise

manager istilahnya.

P-27 : Berarti karena ada satu fitur yang kita perlu manfaatnya. Manfaat

bagus, gitu?

J-27 : Iya.

P-28 : Req2.2.3, Req2.2.5 Baik kalau gitu itu terjawab. Kalau gitu saya minta

penjelasan tentang enterprise manager itu, EM itu. Kita ada nggak

melakukan semacam studi, keuntungannya apa saja sih fitur ini?

Apakah memang sedemikian besarnya kelebihannya sampai kita

melakukan upgrade.

J-28 : Nggak.

P-29 : Req2.2.3, Req2.2.5 Nggak sampai kayak gitu?

J-29 : Nggak. Sepertinya sih sudah dilakukan Pak INS3 mungkin ya. Dulu kita

masih 9i, padahal Oracle sudah 11, dan 10g itu sendiri banyak sekali

improvement dari sisi performance database, secara arsitekturnya dia.

Untuk peningkatan speed sih alasannya mungkin.

P-30 : Req2.2.3, Req2.2.5 Berarti sebenarnya Bapak nggak bisa menjawab

pertanyaan ini?

J-30 : Iya.

P-31 : Baik. Pertanyaan berikutnya adalah, pada saat kita membuat

rencana pemeliharaan, kita sudah mempertimbangkan sumber

daya? Maksudnya personil, infrastruktur, atau tool. Itu sudah

termasuk di dalamnya?

3 Staf Database Administrator.




335


J-31 : Kayaknya belum deh. Saya masih ragu dengan itu.

P-32 : Baik. Berarti di sini kita belum melakukan. Nah OK, apakah

kegiatan predelivery and transition sudah direncanakan dari tahap

awal, tadi sudah Bapak jawab iya dilakukan. Berikutnya adalah

apakah para maintainer sudah ikut serta dalam kegiatan predelivery

and transition bersamaan dengan developer? Seperti Bapak bilang

tadi, karena kita kecil sebenarnya orangnya sama, berarti bisa

dibilang iya, bisa dibilang tidak, bisa dibilang not applicable karena

orangnya sama?

J-32 : Iya.

P-33 : Ada nggak, kasus di mana developer dan maintainer beda orangnya?

J-33 : Belum ada saat ini.

P-34 : Jadi sebenarnya praktek ini belum diperlukan?

J-34 : Sebenarnya diperlukan. Sekarang sudah ada dua orang, ke depannya kita

perlu itu, biar nggak mesti satu orang. Yang jelas, yang ada dokumennya.

P-35 : Req2.2.7 Selama ini kalau misalnya dalam kegiatan predelivery and

transition ada nggak diundang, beberapa orang selain developer?

Misalnya saya diundang supaya maintenance tahu apa saja yang

perlu dilakukan.

J-35 : Belum.

P-36 : Belum ada ya?

J-36 : Iya. Untuk maintainer belum, yang ada support.

P-37 : Oh, orang support sudah?




336


J-37 : Iya.

P-38 : Req2.2.8 Berarti ini sudah dilakukan sebagian, cuma maintainer saja

yang belum ikut serta. Baik berikutnya adalah, untuk rencana

transisi, sudah dibuat bersamaan dengan rencana pengembangan?

Bisa dibilang, project plan sudah ada transition plan-nya?

J-38 : Belum ada.

P-39 : Req2.2.9 Rencana predelivery and transition ini sudah

mempertimbangkan rencana infrastruktur? Infrastruktur kita kan

berubah terus. Ada yang ditambah, ada yang dikurangi. Atau paling

tidak, sudah diskusi belum dengan orang infra?

J-39 : Sudah, kalau itu sudah. Formalnya sih nggak ada, email doang. Hanya

dalam bentuk tanya jawab lewat email.

P-40 : Ada nggak hubungannya dengan rencana pelatihan? Kalau

orangnya beda kan ilmunya beda?

J-41 : Dulu sih sudah ada rencana pelatihan. Ini training user atau ...

P-42 : Bisa dua-duanya Pak.

J-42 : Untuk user ada.

P-43 : Untuk maintainer?

J-43 : Belum ada.

P-44 : Untuk configuration management sudah termasuk?

J-44 : Belum.

P-45 : Sup2.0.1 Rencana kualitas? Untuk quality assurance?




337


J-45 : Belum.

P-46 : Sup2.0.1 Kita sebetulnya ada quality assurance nggak sih?

J-46 : Belum ada.

P-47 : Sup2.0.1 Kita sebetulnya ada quality assurance nggak sih?

J-47 : Belum ada.

P-48 : Req2.2.10 Baik. Berikutnya adalah, apakah rencana predelivery and

transition sudah ada merinci kegiatan pengujian, dukungan, teknik

dan tool yang akan digunakan?

J-48 : Belum ada.

P-49 : Req2.2.11 Kalau risk assessment sudah ada belum? Dari aspek teknis,

dampaknya bagaimana, biaya dampaknya bagaimana, SDM?

J-49 : Ada sih, cuma nggak di-state dalam satu dokumen.

P-50 : Req2.2.11 Berarti ini informal, atas inisiatif Bapak sendiri?

J-50 : Percakapan begitu bentuknya, ngobrol-ngobrol, tapi tidak dalam suatu ...

apa sih ... work product-nya tidak ada. Artifaknya nggak ada.

P-51 : Req2.2.12, Req2.2.14 Itu tadi dari sisi risk assessment. Apakah sudah ada

assessment untuk keperluan disaster recovery?

J-51 : Kalau dari sisi infrastruktur nggak tahu ya. Dari server juga nggak ada

sih. Kalau Sistem Informasi Asuransi Umum itu, sampai saat ini saya

tidak tahu posisi DRC-nya itu.

P-52 : Req2.2.12, Req2.2.14 Kalau saya dengar dari Pak RK sebenarnya ada, cold

site. Terus backup kita juga sebenarnya sudah ada, tapi yang saya




338


yakin kita belum ada itu disaster recovery plan. Mungkin kita punya

kapabilitas untuk disaster recovery, tapi tidak terorganisasi. Idealnya

kan ada pengujian untuk ini.

J-52 : Belum rutin. Kalau jeblok pasti nggak bisa ngapa-ngapain. Dan cold site

itu kan nggak seperti itu, seharusnya hanya dalam hitungan jam.

Seharusnya hardware itu sudah ready cuma data mungkin harus di-

restore dari backup. Katakanlah backup disimpan di remote site,

kopiannya kan mesti didatangkan.

P-53 : Req2.2.12 Kalau dari sudut pandang personil. Kalau misalnya ada

disaster nih, sudah jelas belum contact person-nya siapa?

J-53 : Pak INS ha ha ha, belum ada sih. Kalau di kita kan support pintunya.

P-54 : Req2.2.12 Kalau dari sudut pandang personil. Kalau misalnya ada

disaster nih, sudah jelas belum contact person-nya siapa?

J-54 : Kontak yang di kita support sebagai pintu ininya.

P-55 : Req2.2.12 Berarti kalau saya klarifikasi pertanyaan saya, kita ada

nggak dokumen yang menyatakan “in the event of a disaster, please

call xyz”. Jadi misalnya tanggung jawab kalau ada disaster, terus

kita mau disaster recovery, tanggung jawab untuk ini siapa, untuk ini

si anu. Seperti itu belum ada ya?

J-55 : Nggak ada.

P-56 : Req2.2.13 Kita sudah ada belum, mengidentifikasi skrip, dokumentasi,

program, dan data yang kritis. Dalam arti kalau dia nggak ada,

maka Sistem Informasi Asuransi Umum nggak jalan, maka bisnis

stop. Sudah diidentifikasi, Pak?

J-56 : Belum




339


P-57 : Apakah Departemen TI secara formal menyatakan bahwa layanan

pemulihan dari bencana, atas data dan layanan, itu merupakan

bagian dari layanan yang disediakan TI? Kalau ada bencana,

apakah Departemen TI langsung menyatakan untuk bertanggung

jawab untuk memperbaiki – nggak masalah itu tadi yang bikin

masalah siapa – pokoknya langsung bertugas untuk memperbaiki?

Ada nggak seperti itu?

J-57 : Nggak tahu.

P-58 : OK, berarti ini saya harus bertanya ke Pak RK.

J-58 : Ha ha ha.

P-59 : Kalau ada change request nih, kita ada diwajibkan untuk

menghubungi si user, apa kita langsung commit saja?

J-59 : Maksudnya?

P-60 : Ini untuk change request, delivery-nya, kita mau deploy? Wajib?

J-60 : Wajib.

P-61 : Ini ada dokumennya?

J-61 : Formulir UAT biasanya. Formalnya ada sih untuk itu.

P-62 : Req2.2.16 Ada nggak orang yang bertugas sebagai contact person untuk

pengguna?

J-62 : Iya, help desk.

P-63 : Req2.2.16 Orang help desk bisa nggak membantu untuk prioritisasi?

J-63 : Nggak bisa.




340


P-64 : Req2.2.16, Req2.2.18 Prioritisasi kita itu berdasarkan apa ya? Ini

konteksnya request, bukan proyek. Apa belum ada prosedurnya?

J-64 : Belum ada prosedurnya. Itu berdasarkan jabatan.

P-65 : Req2.2.16 Baik belum ada prosedur, jadi pertanyaan berikutnya tidak

perlu. Itu valid, Pak. Berdasarkan jabatan pun. Yang penting ada

prosedurnya. Tapi nggak ada prosedurnya ya?

J-65 : Nggak ada.

P-66 : Berarti sekarang penentuan prioritas adalah berdasarkan inisiatif

sendiri, yang berdasarkan pada jabatan.

J-66 : Iya.

P-67 : Req2.2.17 Untuk daftar rencana pemeliharaan tadi, digunakan nggak

untuk melacak status permintaan dari pengguna? Terus digunakan

nggak untuk mengomunikasikan beban kerja, baik itu untuk

manajemen maupun pengguna?

J-67 : Sebagian sih kayaknya sudah. Yang sudah karena ditagih.

P-68 : Req2.2.17 Ada dokumennya?

J-68 : Ada, sama Pak IYB4.

P-69 : Req2.2.18 Dalam maintenance plan, kita biasanya ada membuat daftar,

ada step-step-nya, terus bisa dipecah-pecah, itu kan ada daftar

kegiatan? Sudah mendapatkan persetujuan pelanggan atau

pengguna? Apa kita bikin, bahkan nggak ditanya ke mereka?

J-69 : Belum pernah ditanya kayaknya.

4 Kepala seksi Business Analyst.




341


P-70 : Req2.2.18 Tapi mereka paham, nggak. Maksudnya, nanti kita akan

melakukan ini, ini, ini.

J-70 : Kalau ada impact-nya sih dikasih tahu.

P-71 : Req2.2.18 Ada prosedurnya nggak? Kasus seperti apa kita perlu

memberitahukan orang?

J-71 : Prosedur tertulis sih nggak ada. Inisiatif pribadi itu.

P-72 : Req2.2.19 Kalau ada problem report, terus kita mau ada perbaikan, kita

rupanya mempengaruhi banyak orang. Misalnya ada yang critical,

kita harus perbaiki saat itu juga. Kita mesti deploy saat itu juga,

sistem mesti dibawa down dulu, itu kita melakukan sosialisasi setahu

aku, pakai running text di Sistem Informasi Asuransi Umum.

Sebetulnya itu ada prosedurnya nggak?

J-72 : Wah, itu saya kurang tahu. Kita boleh nge-down itu juga belum ada ...

P-73 : Req2.2.19 Belum tahu yang punya wewenang siapa?

J-73 : Iya.

P-74 : Req2.2.20 Apakah Departemen TI memiliki rencana kapasitas

permintaan (request capacity plan)? Jadi kita melakukan

pengukuran untuk menentukan tren masa depan, jadi kita bisa tahu

misalnya resource-nya menjadi seperti ini, perlu ditambah RAM,

perlu tambah orang sekian. Ada nggak seperti itu?

J-74 : Pak RK kayaknya ada yang begitu. Seharusnya dia punya, tapi apa on-

track atau tidak itu lain lagi.

P-75 : Evo1.0.1 Itu mengakhiri pertanyaan mengenai Maintenance Planning.

Berikutnya adalah Predelivery and Transition Services. Ini




342


pertanyaan pertama adalah, apakah kita melakukan kegiatan itu.

Tapi Bapak sudah menjawab bahwa iya sudah melakukan.

J-75 : Iya.

P-76 : Evo1.1.1 Apakah itu bersifat formal.

J-76 : Ada yang formal, ada yang tidak. Campur-campur sih.

P-77 : Evo1.1.1 Sebentar, kalau formal berarti sudah diperintahkan dari

manajemen. Kalau Bapak bilang ada yang formal, berarti ...

J-77 : Ah, maksud saya terdokumentasi ada yang tidak.

P-78 : Evo1.2.1 Apakah maintainer berkomunikasi dengan developer? Ini

sebenarnya banyak pertanyaan yang duplikat ya Pak? Apa karena

maintainer dan developer itu sering kali orang yang sama, maka

tidak perlu berkomunikasi?

J-78 : Iya, karena full stack kan selalu gue lagi gue lagi.

P-79 : Evo1.2.1 Ini sepertinya not applicable, saya lanjut saja ya?

J-79 : Iya, not applicable.

P-80 : Evo1.2.2 Ada nggak ketentuan pada life cycle apa maintainer mulai

terlibat pada proyek? Idealnya kan jangan pas transisi baru

maintainer dilibatkan, tiba-tiba saja maintainer dikasih software,

bingunglah dia.

J-80 : Idealnya sih memang diikutkan, tapi itu sangat susah sekali. Bahkan di

tempat yang besar sekalipun. Kalau jelas developer itu siapa, maintainer

itu siapa, bisa lempar bola ke situ.




343


P-81 : Evo1.2.2 Kalau konsepnya dalam framework ini, sebelum transisi

developer, setelah transisi maintainer. Jadi asumsinya dalam

framework ini, developer dengan maintainer itu orangnya beda.

J-81 : Kita terlalu kecil mungkin ya. Tapi secara dokumen seharusnya ada.

P-82 : Evo1.2.2 Kita ada nggak prosedur yang menentukan proyek yang siap

untuk transisi itu yang seperti apa? Apakah kalau diperintahkan

transisi ya transisi. Ada nggak kriterianya?

J-82 : Wah saya belum tahu. Biasanya di akhir-akhir saat mulai user training,

itu sudah mulai transisi. Nggak ada sih, itu kan artinya sudah ada duluan

duduk bareng. Idealnya sih maintainer ikut duduk.

P-83 : Evo1.2.3 Ada nggak selama ini maintainer secara mengangkat isu

predelivery and transition? Katakanlah dia diikutsertakan, ada nggak

dia bertanya secara proaktif tentang kebutuhan maintenance. Secara

proaktif di sini karena dia ada wewenang untuk bertanya hal

tersebut. Jadi bukan atas inisiatif saja. Memang itu kewajiban dia,

mengangkat isu yang belum dibahas, menyangkut predelivery and

transition.

J-83 : Belum ada.

P-84 : OK. Berikutnya adalah ... OK ini sudah terjawab ... dia belum ada

mengangkat isu predelivery and transition baik ke hadapan developer

maupun ke hadapan petugas pengadaan infrastruktur itu ya?

J-84 : Belum.

P-85 : Baik. Apakah Departemen TI melakukan sosialisasi kegiatan

predelivery and transition kepada pelanggan ataupun pengguna? Di

sini dia membedakan pelanggan dengan pengguna. Pelanggan orang




344


yang memerintahkan, pengguna ya yang memakai. Ada nggak,

kegiatan sosialisasi predelivery and transition?

J-85 : Contohnya apa itu?

P-86 : Evo1.2.4 Misalnya, kita kasih tahu ke user, “nanti kita akan melakukan

online, dan setelah online ... dua bulan setelah online masa

handholding-nya selesai, saya akan menyerahkan ke si anu,

kedepannya bisa menghubungi si anu.” Itu kan jelas nanti saat kita

bilang seperti itu kita memberitahukan ke user pada dasarnya

operasionalnya itu akan terhambat sedikit selama masa transisi itu.

J-86 : Ada yang kemarin sih ada.

P-87 : Evo1.2.4 Ada ya? Itu contohnya apa itu?

J-87 : Waktu itu kan kita con-call juga, secara itunya, menyampaikannya, even

yang regional ... Surabaya itu apa ya? Timur ya? Timur itu Pak RK5 yang

menyampaikan langsung kalau di situ. Akan ada ini bla bla bla itu kan.

Ya kita di sini support Skype, waktu itu sempat itu ikutan conference call

dengan wajah, nggak hanya ditelepon. Selama masa transisi kontak

ininya langsung nih, bisa direct. Kan kita belum tahu yang bagian tiket-

tiket itu kan, bisa telepon saja. Dua minggu setelah live, itu bisa direct

contact, kalau ada problem, direct call atau apa gitu. Setelah itu ya ... kita

serahkan ke yang tiket tadi. Kalau ada problem masukin ke IT Support.

P-88 : Evo1.2.4 OK. Berarti ada ya?

J-88 : Ada. Ada formal itu juga, tapi dikirim dalam distribusi email, seperti itu.

P-89 : Kalau SLA, kita ada komunikasikan nggak?

5 Kepala Departemen TI.




345


J-89 : SLA, belum.

P-90 : Belum ya? Baik.

J-90 : Kita belum punya SLA yang resmi.

P-91 : Baik. Berikutnya adalah ...

J-91 : Baru mau dibikin.

P-92 : Baru mau dibikin. Kita dalam kegiatan predelivery and transition itu

ada semacam checklist nggak?

J-92 : Checklist?

P-93 : Evo1.2.5 Daftar kegiatan yang mau dilakukan? “Oh ini sudah

dilakukan, oh ini sudah dilakukan, ini belum dilakukan.”

J-93 : Hmm ada nggak ya?

P-94 : Evo1.2.5 Yang pas Bapaklah? Pas Bapak predelivery and transition ada

nggak? Bentuknya kan nggak klop harus checklist gitu.

J-94 : Ada sih kemarin itu. Work ininya sih udah ... waktu kita mau deploy itu

kita udah bikin ininya kan ... planning ininya nih. Ya checklist lah, bisa

dibilang checklist itu kan. Tanggal berapa tanggal berapa itu neleponin

orang regional.

P-95 : Evo1.2.5 Oh, ada berarti?

J-95 : Ada. Tanggal segitu udah harus deploy.

P-96 : Dokumennya sama siapa?




346


J-96 : Ada di Pak IYB6 sih.

P-97 : Ada di Pak IYB ya? Baik.

J-97 : Ini ngirimnya dalam bentuk email sih. Tapi emailnya isinya panjang gitu.

Bisa di-save ke dalam dokumen.

P-98 : Korespondensi berarti. Baik. Ini dalam kasus maintainer dengan

developer-nya beda ya Pak ya. Apa pada saat developer bilang “OK

nanti yang maintain ini perlu skill ini, ini, ini, gitu” diadakan nggak

training?

J-98 : Nggak ada.

P-99 : Evo1.2.6, Evo1.2.7 Nggak ada. Baik. Karena tidak ada maka pertanyaan

berikutnya juga lewat. Tapi memberikan rekomendasi training itu

ada nggak? Maksudnya “nanti dia perlu skill ini, ini, ini,” itu ada

nggak didaftarkan. Dalam bentuk daftar?

J-99 : Nggak ada.

P-100 : Nggak ada juga ya. Baik. Berarti ini ada tiga lewat.

J-100 : Dulu sih ada, cuma masih dari sisi yang sana. Kayak Nia7 itu dilibatkan

tujuannya kan itu sebenarnya. Kayak Pak Vinno8, Pak Dody9, kan cuma

6 bulan di Bali. Itu untuk maintain ini, tujuannya untuk transisi sih

sebenarnya. Mungkin bisa dibilang ada tapi tidak kontinu kali ya? Karena

tidak sering dilakukan. Waktu mau rilis, deploy itu kan ada semua nih, kit

training ini entah apa namanya. Dulu sempat mereka kan training Java di

sini. Dari luar itunya.

6 Kepala Seksi Business Analyst. 7 Software Developer. 8 Dulu Software Developer. 9 Dulu Software Developer.




347


P-101 : Didatangkan dari luar trainer-nya?

J-101 : Jadi sore gitu mereka training. Saya sih nggak ikutan. Nia itu, mungkin

memperdalam lagi lah. Sempat itu kayaknya dua mingguan itu kayaknya.

P-102 : Evo1.2.9 Baik. Saya lanjut aja ya Pak? Itu tadi untuk Training and

Knowledge Transfer Control. Berikutnya adalah persiapan transisi

final. Maintainer ada nggak, dia menjaga up to date inventori lisensi,

pengguna ... inventori pengguna, lingkungannya itu seperti apa,

misalnya Blitz, Flash, dokumen teknis yang ada itu apa aja? Ada

nggak dia membuat inventori dan menjaga up to date?

J-102 : Nggak ada.

P-103 : Evo1.2.9 Nggak ada ya?

J-103 : Even saya sendiri bingung Flash sama Blitz itu apa ha ha ha.

P-104 : Evo1.2.9 Tapi maintainer ngerti nggak dia dengan interface? Interface

di sini bukan graphical user interface tapi interface ... sistem yang ini

interface dengan sistem yang mana aja. Terus data itu strukturnya

seperti apa? Lingkungan operasional, berarti maksudnya si user itu

nanti akan memakainya seperti apa? Itu ada nggak diinformasikan

kepada maintainer?

J-105 : Nggak ada

P-106 : Evo1.2.9 Nggak ada juga ya? Baik.

J-106 : Karena, apa ya? Kalau dalam kasus Sistem Informasi Asuransi Umum itu

dalam, dalam, apa namanya? Awal-awal semua orang di PT XYZ ini

sebagai maintainer, Jos. Jadi nggak perlu dokumen itu. Karena sudah

tahu semua, gitu.




348


P-107 : Evo1.2.9 Yang kayak gitu kan perlunya kalau ada orang keluar masuk.

J-107 : Iya. Waktu itu ya semua, satu kotak yang develop report sekarang itu kan

maintainer. Karena timnya nggak berubah-ubah dari itu kan ... even

katakanlah sekarang ini katakanlah kita nggak mau transisi ke mana-

mana ya jadinya stuck saja di situ sudah.

P-108 : Baik. Tapi ini sepertinya ini Bapak sudah jawab tadi. Daftar

masalah yang belum diselesaikan selama pengembangan transisi ke

maintainer. Itu berarti dijaga up to date ya?

J-108 : Dijaga kalau itu.

P-109 : Dokumennya di ... Pak IYB?

J-109 : Di Pak IYB.

P-110 : Baik.

J-110 : Pak RA10 juga simpan.

P-111 : Evo1.2.10 Baik. Apakah maintainer sudah memastikan – ini berarti

dalam arti maintenance engineer seperti kita nih – dia sudah

memastikan belum, source code yang dimilikinya itu adalah source

code yang akan digunakan untuk produksi? Gampangnya begini,

Pak. Itu CVS kita itu versi produksinya yang mana sih?

J-111 : Sudah sih itu.

P-112 : Evo1.2.10 Sudah? Itu tahunya dari mana gitu Pak? Apa kita selama klik

kanan, update, dijamin itu yang dipakai di produksi?

J-112 : Dijamin.

10 Staf Help Desk Application.




349


P-113 : Evo1.2.10 Nah, OK, baik.

J-113 : Karena yang di deployer-nya kan get dari HEAD terus.

P-114 : Evo1.2.10 OK. Nah pada saat predelivery and transition apakah

maintainer itu sudah memastikan dia bisa belum, check out, versi

dari yang terakhir tadi? Terus dia sudah memastikan belum, bisa

compile? Dia sudah memastikan belum, kalau sudah di-compile, itu

bisa diuji nggak? Maksudnya dimasukkan ke dalam sistem produksi

terus di-testing dulu, oh ini sudah nyala. Ada nggak kayak begitu?

J-114 : Ada.

P-115 : Evo1.2.10 Ada? Memang dilakukan ya? Ada prosedurnya? Memang

diminta seperti itu?

J-115 : Nggak.

P-116 : Evo1.2.10 Inisiatif sendiri?

J-116 : Iya.

P-117 : Evo1.2.11 OK ini pertanyaan terakhir untuk topik yang ini Pak.

Maintainer ada nggak dia bisa, sorry, dia bisa nggak mengategorikan

masalah yang belum diselesaikan tadi. Jadi, bisa nggak dia

mengatakan, katakanlah ini oh yang kategorinya seperti ini,

prioritasnya itu yang seperti ini, statusnya itu sekarang apa,

katakanlah menunggu input dari user. Apakah masalah teknis?

Apakah masalah arsitektur? Yang seperti itu ada nggak? Bisa, ada

kategorisasinya nggak? Apa cuma daftar saja?

J-117 : Daftar saja sih.




350


P-118 : Evo2.0.1 Baik. Disosialisasikan ... oh sudah, sudah tadi. Disosialisasikan

ke pengguna. Baik. Topik berikutnya adalah Operational Support

Services. Kita Departemen TI kan umumnya menyediakan layanan

dukungan operasional. Iya ya, di Departemen TI PT XYZ?

Menyediakan ya Pak ya?

J-118 : Iya.

P-119 : Evo2.1.1 Dukungan kita itu memang bagian dari job description?

J-119 : Iya.

P-120 : Evo2.1.1 Formal ya?

J-120 : Formal.

P-121 : Evo2.2.1 Baik. Ada nggak kita, jadwal operasi perangkat lunak yang

khusus untuk batch update? Untuk script update? Maksudnya update,

script-nya mau diubah gitu. Ada nggak jadwal untuk update

perangkat lunak? Atau sinkronisasi, atau transfer data antar

sistem? Jadwal khusus untuk itu ada nggak?

J-121 : Sepertinya ada.

P-122 : Evo2.2.1 Ada?

J-122 : Jadwal maksudnya? Ada. Backup-backup, Pak INS. Biasanya malam.

P-123 : Evo2.2.1 OK, itu jadwal backup sama jadwal deploy. Kalau misalnya

jadwal update perangkat lunak? Misalnya nih, Pak. Kita mau bring

down sistem karena mau untuk update setiap ...

J-123 : Sabtu.

P-124 : Evo2.2.1 Sabtu? Oh ada jadwalnya?




351


J-124 : Ada, walaupun nggak resmi kan bisa.

P-125 : Evo2.2.1 Oh. Berarti bisa dibilang nih ... katakanlah kita perlu

melakukan update, biasanya dilakukan Sabtu.

J-125 : Iya. Bukan office hour lah.

P-126 : Evo2.2.1 Baik. Tapi itu bukan kebijakan ya? Maksudnya, inisiatif?

J-126 : Itu perintah sih.

P-127 : Evo2.2.1 Perintah?

J-127 : Iya.

P-128 : Evo2.2.2 Baik. Sudah diperintahkan seperti itu. Baik. Berikutnya

adalah, kita ada nggak memonitor, misalnya kita, aku menambah

fitur. Kita ada memonitor nggak, fiturnya itu nanti efeknya di

produksi apa? Atau jangan fitur dah. Bilangnya gini. Aku ada

restrukturisasi, tujuannya adalah mempercepat transaksi. Benar

nggak kita melakukan apa namanya, pemantauan sebelum dan

sesudah deploy? Sesuatu yang tadinya kita klaim mempercepat itu,

benar nggak kita monitor? Ini bukan mengatakan apakah benar-

benar makin cepat, tapi pertanyaannya adalah, apakah kita

memonitor?

J-128 : Monitor sih biasanya. Kalau saya selalu monitor. Sebelum dan sesudah

deploy. Cuma nggak resmi aja.

P-129 : Evo2.2.2 Nggak resmi ya Pak ya? Baik. Bapak memonitornya dalam

bentuk apa, Pak? Caranya?

J-129 : Tergantung. Kalau kecepatan ya dilihat, dicoba, atau kalau fitur ininya

sudah benar apa nggak, dicek sih di live. Datanya kek, atau sudah benar-




352


benar ter-deploy juga kan, karena kita scheduler, harus dicek juga kan?

Paginya nambah kolom belum nongol. Atau kalau terkait speed sih

dicobain.

P-130 : Evo2.2.2 Itu wajib dilakukan? Memonitor penambahan, apa namanya,

kecepatan, apa jangan-jangan makin lambat.

J-130 : Wajib sih. Itu harus.

P-131 : Evo2.2.2 Yang bertugas siapa Pak?

J-131 : Biasanya saya. Sama Pak INS.

P-132 : Evo2.2.2 Memang bagian dari job description?

J-132 : Nanti akan menjadi bagian dari KPI.

P-133 : Evo2.2.2 Nanti, tapi? Baik. Pertanyaan berikutnya, ini masih berkaitan

di pemantauan ya. Ada nggak pembagian tugasnya? Tadi kan Bapak

bilang “biasanya saya dengan Pak INS.” Yang membedakan tugas

Bapak dengan tugasnya Pak INS dalam hal pemantauan itu seperti

apa? Pembagian tugasnya itu?

J-133 : Nggak ada sih? Yang jelas. Kalau pembagian tugas nggak ada.

P-134 : Evo2.2.2 Jadi Bapak tahu itu kerjaannya siapa? Apa tergantung

ketersediaannya saja? Siapa yang ada, begitu?

J-134 : Iya lebih ke situ juga. Sama ininya, jenis ininya, cuma nggak ini sih.

Kalau terkait database ya Pak INS, kalau aplikasi saya. Begitulah.

P-135 : Yang tugas untuk backup itu kita siapa ya Pak? Backup, clustering?

J-135 : Pak INS itu.




353


P-136 : Ini yang terakhir untuk topik ini. Itu kita kan ada jadwal-jadwal

otomatis, Pak. Jadwal deploy, ada lagi jadwal report yang kecil-kecil

aku itu. Itu sebetulnya tugas siapa sih Pak? Yang administrasi itu?

Kalau membikinnya kan otomatis tugas kita. Kita developer. Tapi

administrasinya nih. Katakanlah Bapak kepingin SOA tuh “jalanin

dong.” Itu seharusnya ke siapa, berdasarkan job description. Apa

jangan-jangan ...

J-136 : Nggak ada job description-nya itu.

P-137 : Jadi-jadian, berarti?

J-137 : Iya.

P-138 : Evo2.2.3 Baik. Pertanyaan berikutnya adalah, Bapak bilang kan tadi

sebetulnya Bapak dengan Pak INS itu tugasnya untuk memantau

operasionalnya seperti apa. Bapak bikin laporan nggak untuk itu?

Hari ini, atau minggu ini, jalannya seperti ini. Entah gimana

ceritanya minggu ini dia lambat, pemrosesan hanya 50% kapasitas

normal.

J-138 : Nggak.

P-139 : Nggak sampai kayak begitu ya?

J-139 : Nggak.

P-140 : Baik.

J-140 : Kita belum ada itu. Sudah diminta sih.

P-141 : Oh sudah diminta?




354


J-141 : Maksudnya biar bisa ngeluarin itu. Kan pengukuran itunya Jos.

Katakanlah KPI speed itunya kan.

P-142 : Transaksi?

J-142 : Transaksi.

P-143 : Evo2.2.4 OK. Baik. Tadi itu tentang pemantauan. Berikutnya adalah

dukungan setelah jam kerja. Kita ada nggak sebenarnya dukungan

setelah jam kerja? Kayaknya kan tidak formal ya? Seolah-olah tidak

ada orang yang bertugas untuk itu. Menurut Bapak?

J-143 : Nggak ada di kita. Karena by default kan kita nggak 24 hours kan. Jadi,

jadinya nggak di-formalized itunya. Jadinya ad hoc itunya, occasional,

kalau ada keperluan saja.

P-144 : Evo2.2.4 Oh tapi untuk yang ad hoc itu ditentukan nggak orangnya?

J-144 : Itu terkait masalah.

P-145 : Evo2.2.4 Baik. Berarti kalau misalnya saya bilang ini belum ada

kebijakannya ...

J-145 : Kalau kita 24 hours kan seharusnya ada yang on duty.

P-146 : Evo2.2.4 Berarti kita nggak ada jadwal support, yang perlu dihubungi

siapa? Nggak ada berarti ya?

J-146 : Nggak ada.

P-147 : Evo2.2.5 Berikutnya sedikit tentang bisnisnya nih. Bapak sebagai

developer dan maintainer, kepala seksi bisnis, eh kepala seksi

Software Developer nih. Maintainer itu mampu nggak menjawab

pertanyaan seputar fungsionalitas dan aturan bisnis untuk




355


perangkat lunak yang dipeliharanya? Artinya, maintainer-nya ini

sebenarnya ngerti nggak sih, bisnisnya?

J-147 : Harus ngerti sih. Tapi ini maintenance ya? Ya harus ngerti juga.

Berdasarkan pengalaman, orang support itu lebih pintar dari developer.

Bukan coding ya, apa namanya, entah bolong-bolongnya, entah cara

kerjanya.

P-148 : Evo2.2.5 Kalau misalnya saya bilang begini, Pak. Developer atau

maintainer tidak diwajibkan mengerti business rule, hanya perlu

secara minimal paham business rule, karena bisa langsung

berhubungan dengan tim support, tim help desk. Benar nggak

pernyataan itu?

J-148 : Mereka juga nggak paham-paham amat. Paham hanya kalau terkait isu

doang. Kalau nggak itu, kadang tahu, kadang nggak.

P-149 : Evo2.2.5 Baik pertanyaan berikutnya ya Pak. Tadi tentang business

rule, sudah terjawab, kecuali satu. Bapak sebagai developer, atau

anak buah Bapak, dianggap nggak sebagai layanan, kalau misalnya

ada orang bertanya “tolong ekstrak business rule dari source code.”

Reverse engineering pada dasarnya itu dianggap layanan nggak?

Formal?

J-149 : Bukan layanan sih. Tapi kadang mencari, apa namanya, mencari

pembuktian itu yang lebih nyata artifact-nya kan dari source code. Jadi

sering terjadi sih memang. Nggak ada dalam bentuk dokumen sih.

Katakanlah dokumen sudah hilang, kan bingung tuh, di code nggak ada

nih, “dulu nggak minta.” Bisa menjadi pembelaan.

P-150 : Apakah maintenance engineer ada nggak kita menyediakan layanan

untuk membantu pengguna lebih memahami data? Kalau misalnya




356


ada report, terus ditanya “kenapa datanya begini?” jawabnya “dari

sistem memang begini.” Ditanyalah kita “kenapa seperti itu?”

J-150 : Nggak, paling ditanya ini datanya dari tabel mana. Masalah isi sih nggak.

P-151 : Evo2.2.6 Setahu saya kita ada menyediakan layanan laporan ad hoc

kan? Tim report itu ya? Tim MIS kalau Pak RK bilangnya. Ada ya?

Ada juga membuat laporan yang bisa diulangi oleh mereka? Ada

ya? Dua-dua ada ya?

J-151 : Ada.

P-152 : Terus kita ada nggak bekerja sama dengan tim operasi, dalam hal

ini orang infrastruktur dan help desk, untuk misalnya mereka perlu

pengetahuan tentang bagian dalam perangkat lunak kita? Misalnya

versi Java-nya berapa, biar diketahui itu nanti server-nya mesti

yang kayak apa.

J-152 : Belum sih. Diserahkan sepenuhnya ke kita yang proses itunya.

P-153 : Baik. Jadi tugas kita sebetulnya ya?

J-153 : Iya.

P-154 : Makanya tidak perlu bekerja sama dengan, sori, makanya ...

J-154 : Kita cuma nggak mengeluarkan dokumentasi aja.

P-155 : Usaha-usaha yang kita bahas ini dianggap sebagai layanan TI

nggak?

J-155 : Sebagai layanan sih.

P-156 : OK. Karena dianggap sebagai layanan berarti dipublikasikan ya?

Maksudnya, ada catatannya berarti?




357


J-156 : Maksudnya apanya?

P-157 : Evo2.2.6 Katakanlah kita mau buat laporan yang bisa diulangi tadi oleh

user. Itu dianggap sebagai kegiatan formal, dicatat dalam ticketing?

J-157 : Iya.

P-158 : Evo2.2.6 Ada kategorinya sendiri berarti?

J-158 : Ada, tapi tiket itu kebanyakan request sih, bukan bug. Itu yang ad hoc

sih. Kalau yang reguler kan sudah di deploy langsung, bisa dipakai terus.

P-159 : Evo3.0.1 Itu mengakhiri pertanyaan tentang layanan dukungan

operasional. Berikutnya adalah, ini sebenarnya core-nya kita nih.

Layanan evolusi perangkat lunak dan koreksi perangkat lunak. Ada

nggak Software Evolution and Correction Services di PT XYZ?

J-159 : Ada pasti.

P-160 : Evo3.1.1 Ha ha ha, ini pasti formal ya. Memang job description kita

begitu. Mengubah dan memperbaiki. Formal ini.

J-160 : Iya. Formal. Cuma perencanaannya yang ... sebenarnya punya cuma

tidak jalannya seperti yang semestinya. Banyak kendala. Yang begini

plan lengkap sih. Ya mungkin tidak semua terlaksana. Banyak proyek

yang menyusup.

P-161 : Evo3.2.1 Kita saat membuat change request nih dari user, itu

requirement-nya sudah cukup detail, belum? Untuk keperluan kita.

Apa kita sering mesti menebak-nebak lagi sebetulnya si user itu

maunya apa sih.




358


J-161 : Kalau kita kan, lebih confirm-nya ke BA, mereka yang mencari tahu

itunya. Kalau yang kita terima sih, sudah jelas. Ya kalau kita menerima

dari user sudah pasti tidak jelas.

P-162 : Evo3.2.1 Ada nggak kita kegiatannya mengidentifikasi komponen apa

saja yang harus diubah?

J-162 : Ada.

P-163 : Evo3.2.1 Ada? Dokumentasi yang harus diubah?

J-163 : Nggak ada.

P-164 : Evo3.2.1 Nggak Ada? Baik.

J-164 : Ha ha ha kalau dokumen nggak ada.

P-165 : Evo3.2.2 Apakah problem report diproses seperti change request.

Problem report itu laporan insiden.

J-165 : Nggak sih.

P-166 : Evo3.2.2 Beda ya caranya?

J-166 : Beda.

P-167 : Evo3.2.2 Baik. Berarti kalau problem report nih, ada insiden gitu, kita

mau fix. Katakanlah ada salah perhitungan programnya. Itu masih

perlu approval si user nggak?

J-167 : Nggak.

P-168 : Pro2.2.2, Evo3.2.3 Nggak ya? Baik. Ada nggak prosedur terdokumentasi

untuk programming? Contohnya naming convention, life cycle apa

aja, gitu. Kita punya naming convention?




359


J-168 : Nggak.

P-169 : Evo3.2.3 Kalau daftar life cycle stage kita ada nggak?

J-169 : Ada itu, dokumen resmi. Artifaknya ada itu.

P-170 : Evo3.2.4 Kita ada nggak, prosedur terdokumentasi, untuk modifikasi

data operasional. Katakanlah diminta “tolong dong edit data begini,

begini begini,” ada prosedurnya nggak apa yang harus dilakukan?

Ada ya? Prosedurnya itu terdokumentasi Pak?

J-170 : Ada, dari email biasanya approval-nya.

P-171 : Evo3.2.4 Oh, berarti ada prosedur yang menyatakan bahwa kita harus

meminta approval, by email atau apalah? Yang barusan itu kan

prakteknya.

J-171 : Prakteknya sih begitu. Formalnya nggak tahu. Mungkin ada edarannya,

tapi kita nggak tahu.

P-172 : Evo3.2.4 Kita ada nggak menyimpan secara formal approval-nya itu?

J-172 : Di tiket sih ada. Email juga ada.

P-173 : Evo3.2.5 Berikutnya, evolusi perangkat lunak ... ini sebenarnya sudah

terjawab, tapi saya tetap harus bertanya. Bahasa pemrograman

untuk maintenance sama nggak dengan waktu development?

J-173 : Sama.

P-174 : Evo3.2.5 Sama. Baik. Ada nggak kasus di mana bahasa

pemrogramannya berbeda?

J-174 : Belum, sih.




360


P-175 : Evo3.2.5 Kita ada nggak semacam kriteria, kapan boleh menggunakan

bahasa pemrograman yang tidak standar kita?

J-175 : Nggak.

P-176 : Evo3.2.6 Ada nggak dalam koreksi atau evolusi, kita diwajibkan untuk

memperbaiki dokumentasi? Atau jangan langsung ngomong

memperbaiki deh. Diidentifikasi nggak, dokumen apa aja yang perlu

diperbaiki? Nggak ada ya?

J-176 : Nggak ada.

P-177 : Kita bisa nggak, rollback perubahan perangkat lunak atau data?

J-177 : Bisa.

P-178 : Prosedurnya ada?

J-178 : Nggak ada.

P-179 : Bisa, tapi nggak ada prosedur.

J-179 : Ini kayaknya dokumen perlu kita centralized. Ada banyak dokumen-

dokumen, di mana, siapa yang simpan, nggak tahu.

P-180 : Evo3.2.7 Kita ada nggak, unit test untuk masing-masing modifikasi?

J-180 : Nggak ada.

P-181 : Evo3.2.8 Baik. Kalau integration test?

J-181 : Nggak ada. Orang yang integration test.

P-182 : Evo3.2.8 Nggak apa-apa. Di sini dia nggak ada bilang terotomatisasi,

Pak.




361


J-182 : Ada, berarti.

P-183 : Evo3.2.8 Ada, ya? Ada prosedurnya nggak?

J-183 : Nggak ada.

P-184 : Evo3.2.8 Nggak ada, ya? Baik. Kalau regression test? TYS bilang ada

sih. Prosedurnya ada nggak?

J-184 : Prosedurnya nggak ada.

P-185 : Evo3.2.9 Ibu TYS juga bilang begitu, tadi. Dia melakukan atas inisiatif

dia sendiri. Baik, berikutnya adalah, apakah dokumentasi untuk

pengguna juga diuji. Nah, dokumentasi diuji. Jadi, dari Business

Analyst misalnya, ada guideline untuk menjalankan program. Itu

sewaktu pengujian, dokumentasi itu dibaca juga nggak? Untuk

memastikan itu masih benar apa tidak.

J-185 : User guide-nya? Dibaca itu. Di-update sih. Pak IYB sih rajin update-nya.

Tapi yang koboi, yang tiba-tiba, nggak sempat. Kalau yang formal sih

biasanya ada di list CR. Biasanya sih ditambahin. Jadi misalnya ada

program versi dua, dia ditambah di bawahnya, tambahan fitur. Yang

ditambah ini.

P-186 : Evo3.2.10 Baik. Dokumentasi internal juga diperbaiki nggak? Atau

gampangnya begini deh, kita ada nggak prosedur perbaikan

dokumentasi internal?

J-186 : Nah itu nggak ada.

P-187 : Evo3.2.10 Nggak ada ya?

J-187 : Itu nggak ada.




362


P-188 : Evo3.2.11 Baik. Kalau dokumentasi eksternal? Tadi Bapak bilang user

guide diperbaharui oleh Pak IYB. Kita ada nggak – misalnya kalau

diperbaharui – kita tulis, versi satu, di-update karena ada ini, ini, ini,

yang memecahkan masalah ini? Jadi istilahnya, user tahu nggak?

“Ini versi baru, kenapa ada versi baru?”

J-188 : Kayaknya beberapa ada. Mungkin beberapa nggak ada. Kurang tahu

juga.

P-189 : Baik. Nah itu sudah mengakhiri diskusi kita tentang Software

Evolution and Correction Services. Kita lanjut ke topik berikutnya.

Configuration and Version Management. Ini sebenarnya sudah

ditanya ke TYS.

J-189 : TYS yang lebih tahu tuh. Dia yang lebih tahu harusnya.

P-190 : Baik. Kalau begitu saya bertanya ke Bapak sederhana saja, Bapak

mengerti nggak dengan konsep Configuration Management?

J-190 : Dulu sempat baca, tapi sudah lupa.

P-191 : Jadi kalau misalnya saya mengajukan pertanyaan ke Bapak nih,

tentang Configuration Management, itu relevan nggak? Maksudnya,

pada tempatnya nggak saya mengajukan pertanyaan ke Bapak

untuk topik ini?

J-191 : Ya coba dulu pertanyaannya apa saja?

P-192 : Sup1.0.1 Baik. Apakah Departemen TI melakukan kegiatan

Configuration and Version Management? Kalau bagi kita developer,

bentuknya yang paling gampang dimengerti adalah source code

management. Kalau di kita memakai CVS. Ada yang pakai SVN, Git.

Setahu saya kita memakai, untuk source code kita.




363


J-192 : Iya.

P-193 : Sup1.1.1 Kalau untuk item-item dokumentasi, Pak?

J-193 : Ada tempatnya, cuma nggak ada yang taruh di situ.

P-194 : Sup1.1.1 Ibu TYS juga bilang tadi begitu. Dia ada taruh di SVN, tapi

terbatas khusus untuk reinsurance, dan itu peninggalan dari

BaliCamp, dan dia tidak update itu. Karena bukan kerjaan dia

katanya. Berarti kalau saya bilang kita melakukan ... Setahu Bapak

kalau tentang report-report kita, file-file RDF itu, nggak masuk ke

dalam ...

J-194 : Itu yang saya ributkan. Selalu ribut.

P-195 : OK. Kalau begitu saya akhiri diskusi tentang Configuration and

Version Management.

J-195 : Ini mestinya ada ... apa sih namanya ... CMP, Configuration Management

Plan, isinya aturan mainnya. Pasal-pasal, ininya begini, letaknya di sini.

P-196 : Sebetulnya ada perangkat lunaknya Pak. Sudah terotomatisasi.

J-196 : Ya jadinya continuous integration itu.

P-197 : Sup2.0.1 Karena memang inti utama dari Configuration Management

ini adalah integritas product. OK tapi karena kita sudah jelas ke

mana arahnya itu, ya sudah kita lewat. Berikutnya Process, Service,

and Quality Assurance. Saya sebelum masuk ke sini saya ada

pertanyaan dulu ...

J-197 : Apakah ini departemen QA?

P-198 : Sup2.0.1 Iya. Jadi ...




364


J-198 : Di departemen ini nggak ada.

P-199 : Sup2.0.1 Nggak ada, ya?

J-199 : Seharusnya mungkin merangkap, kali ya? Pak IYB itu menyangkut QA

sih harusnya.

P-200 : Sup2.0.1 Harusnya, ya? Tapi gini deh. Kalau misalnya aku tanya ke

Bapak nih. Menurut Bapak, Departemen TI melakukan yang

namanya QA nggak?

J-200 : Belum sih, testing iya, tapi QA kan lebih ke ininya kan? Audit aturan. Ya

audit sedikit biarpun nggak audit benar-benar. Meneliti kelengkapan?

P-201 : Sup2.0.1 Iya, memang tentang itu Pak. Berarti tidak dilakukan?

J-201 : SQA? Nggak ada SQA.

P-202 : Sup2.0.1 OK kalau begitu kita akhiri topik tentang Process, Service, and

Quality Assurance. Berikutnya Maintenance Measurement and

Analysis. Apakah Departemen TI ada mengukur, menganalisis,

proses, layanan, perangkat lunak, atau personil maintenance-nya?

Apakah ada tracking untuk perkiraan waktu pengerjaan? Jadi kalau

perkiraan waktunya berubah-ubah, ada di-track nggak? Sasaran

waktu pengerjaannya, kalau berubah-ubah ada di-track nggak?

Waktu pengerjaan sebenarnya, ada di-track nggak?

J-202 : Belum.

P-203 : Sup3.0.1 OK kalau begitu kita akhiri topik tentang Process, Service, and

Quality Assurance. Berikutnya Maintenance Measurement and

Analysis. Apakah Departemen TI ada mengukur, menganalisis,

proses, layanan, perangkat lunak, atau personil maintenance-nya?

Apakah ada tracking untuk perkiraan waktu pengerjaan? Jadi kalau




365


perkiraan waktunya berubah-ubah, ada di-track nggak? Sasaran

waktu pengerjaannya, kalau berubah-ubah ada di-track nggak?

Waktu pengerjaan sebenarnya, ada di-track nggak?

J-203 : Di-track belum.

P-204 : Sup3.0.1 OK, kalau di-track belum. Tapi kalau pengukurannya?

J-204 : Ada.

P-205 : Sup3.0.1 Ada, ya?

J-205 : Estimasi sekarang kan dilakukan.

P-206 : Sup3.1.1 Itu, estimasi itu sebenarnya di ... istilahnya ... resmi nggak sih?

Pembuatan estimasi?

J-206 : Kalau yang agak-agak CR sih, resmi. Tapi itu bukan CR ya?

P-207 : Sup3.1.1 Nggak apa-apa. CR juga termasuk.

J-207 : Termasuk? Itu resmi.

P-208 : Sup3.1.1 Oh, yang CR resmi?

J-208 : Resmi. Iya, kalau user-nya rajin, kalau sudah lewat estimasi, ditagih.

P-209 : Sup3.1.1 Kalau yang non-CR gitu? Perkiraan, waktu perkiraan untuk

pengerjaan nggak diwajibkan untuk dibuat?

J-209 : Nggak. Itu cuma untuk ... informal aja. Kalau CR sih biasanya ditanya.

Berapa lama ininya sih. Itu tergantung kapan mulai dikerjakan. User sulit

membedakan man month dengan month.

P-210 : Sup3.2.1 Oh, OK. Jadi kita kan sudah ada ticketing, bisa tracking dari

situ, sebenarnya. Bisa diukur dari situ? Tapi itu kan untuk request




366


itu sendiri ya? Kalau pengukuran untuk data kepuasan maintainer

ada nggak? Survei, atau misalnya, kepuasan pengguna atas layanan

maintenance? Observasi kualitatif ...

J-210 : Belum itu.

P-211 : Sup3.2.1 Benchmark internal ada nggak? Ini dalam arti, “modul A

dengan modul B, kok kayaknya modul A lelet banget?” Ada nggak?

J-211 : Internal ... belum sih.

P-212 : Sup3.2.1 Ada bikin profil perangkat lunak? Yang paling banyak

digunakan oleh user itu modul ini ... belum ada ya?

J-212 : Nggak.

P-213 : Sup3.2.2 Belum ada, ya? Baik. Kalau begitu ini sisanya saya langkahi.

Yang terakhir untuk Maintenance Measurement and Analysis,

sebagai maintainer, kita bisa nggak, membuat dan menganalisis

laporan perangkat lunak ... yang seperti Bapak bilang tapi Pak INS

diminta. Itu Pak INS sudah bisa belum menyajikan datanya? On

demand?

J-213 : Belum. Itu ada di fitur sih katanya. Kalau secara ininya sih ada, cuma

nggak detail. Nggak bisa dipecah-pecah per ini.

P-214 : Itu pertanyaan terakhir untuk Maintenance Measurement and

Analysis. Topik berikutnya adalah yang namanya Causal Analysis

and Problem Resolution. Ini konsepnya adalah mengeliminasi

problem.

J-214 : Causal, cause-nya apa, gitu?




367


P-215 : Sup4.0.1, Sup4.1.1 Ada nggak kita lakukan itu, Pak? Gampangnya gini,

Pak. Kalau misalnya ada permintaan yang dari user, dalam satu

bulan ada 20 kali permintaan “tolong dong, dibikinkan report PDF

yang ini, karena sewaktu dicek, nggak masuk ke FTP.” Kita ada

nggak, dilakukan, secara formal, diperintahkan sama Pak RK,

“tolong dong itu dicari masalahnya apa?”

J-215 : Ada.

P-216 : Sup4.0.1, Sup4.1.1 Ada? Terus disediakan nggak ... disediakan waktu

khusus untuk itu nggak?

J-216 : Ada lah pasti kalau itu.

P-217 : Sup4.1.1 Tadi perintah ya. Tapi itu bukan ... maksudnya gini Pak. Kita

ada nggak, semacam kriteria, kalau masalah ini berulang sekian

kali, maka kita harus mencari akar permasalahannya? Ada

kriterianya?

J-217 : Ada sih. Banyak yang sudah ketemu akar permasalahannya, cuma nggak

tahu cara memecahkannya.

P-218 : Sup4.1.1 Berarti causal analysis-nya sudah, problem resolution belum?

J-218 : Iya. Contohnya tembak data tembak data itu.

P-219 : Sup4.1.1 Kalau akar permasalahannya ditemukan, diinformasikan

nggak ke user? Kalau akar permasalahannya bukan teknis,

misalnya. Diinformasikan?

J-219 : Ya disebar.

P-220 : Sup4.1.1 Yang menyebar itu siapa?




368


J-220 : Pak IYB biasanya.

P-221 : Sup4.1.1 Proses Causal Analysis and Problem Resolution itu sendiri ada

prosedurnya nggak, Pak?

J-221 : Nggak ada.

P-222 : Sup4.1.1 Berarti beda-beda antar orang?

J-222 : Iya.

P-223 : Sup4.1.1 Baik. OK, berikutnya adalah, Bapak sebagai kepala seksi ada

nggak analisis data kualitas atau data pelanggan, pengguna, dan

kinerja kita secara berkala untuk mengidentifikasi penyebab

masalah? Jadi intinya pertanyaan ini adalah, apakah manajemen

atau paling tidak orang yang didelegasikan untuk hal itu, mencari

tempat yang bermasalah, secara proaktif?

J-223 : Belum. Karena urusan lain masih banyak.

P-224 : Sup4.1.1 Baik. Kita berarti kalau kayak tadi, kepuasan maintainer itu

belum ada ya, sama sekali ya? Ini kan sudah ditanya tadi ya? Baik.

Tindakan analisis proses itu tadi juga, oh ini sorry, tadi kan analisis

masalah. Kalau proses ada nggak, dianalisis, Pak? Ini bottleneck di

mana?

J-224 : Proses apa nih?

P-225 : Sup4.1.1 Seperti misalnya, business rule.

J-225 : Proses bisnisnya?

P-226 : Sup4.1.1 Iya.

J-226 : Nggak ada sih.




369


P-227 : Baik. Ini mengakhiri pertanyaan mengenai Causal Analysis and

Problem Resolution. Berikutnya adalah, ini kegiatan unique untuk

software maintenance. Kegiatan unique, yaitu Software Rejuvenation,

Migration, and Retirement.

J-227 : Oh, server-nya mau dimatikan, gitu?

P-228 : Sup5.0.1 Iya. Termasuk. Kita ada nggak melakukan kegiatan

peremajaan terhadap terhadap perangkat lunak? Peremajaan.

J-228 : Ada.

P-229 : Sup5.0.1 Ada, ya?

J-229 : Iya.

P-230 : Sup5.0.1 Formal? Dalam arti ada jadwalnya ...

J-230 : Nggak.

P-231 : Sup5.1.2 OK. Tidak formal. Katakanlah kalau memensiunkan

perangkat lunak, ini ada perangkat lunak yang kita tidak ingin

memakai lagi, atau fitur yang tidak akan dipakai lagi. Sudah tidak

relevan, misalnya. Itu sewaktu kita memensiunkannya, itu apa

infrastrukturnya dibiarkan begitu saja? Misalnya source code cuma

di-comment.

J-231 : Nggak, sih. Dihapus.

P-232 : Sup5.1.2 Dihapus?

J-232 : Ya tergantung. Kadang sih nggak di level itu juga sih. Tapi secara fitur

sih suka ada yang dipensiunkan juga. Kayak menu, kalau sudah tidak

dipakai, ya ... dihilangkan kan? Sudah ada beberapa.




370


P-233 : Soalnya Pak, kalau saya lihat, untuk submodul yang tidak dipakai

lagi, masih ada di situ source code yang tidak dipakai lagi.

J-233 : Kalau kayak begitu sih masih ada di situ.

P-234 : Masih menambah kompleksitas di kode. Bahkan tidak di-comment.

J-234 : Ini masih dipakai apa sudah nggak dipakai, apa belum dipakai, itu masih

nggak jelas.

P-235 : Sup5.2.1 Nah OK. Baik. Kita ada nggak, kegiatan redokumentasi, Pak?

J-235 : Belum.

P-236 : Sup5.1.1, Sup5.2.2 Oh, baik. Langsung lewat. Belum melakukan. Apakah

kita ada restrukturisasi produk? Gampangnya gini. Ada tabel nih,

kita lihat tabelnya tidak efisien lagi. Misalnya terlalu denormalized.

Kita ingin normalisasi menjadi tiga tabel. Itu kan nggak cuma ubah

tabel aja. Programnya juga select-nya mesti diubah, insert, update

diubah. Ini konsepnya request, setelah transisi. Sesudah di

maintenance. Kalau seperti itu di development kan jelas-jelas

dilakukan.

J-236 : Tidak ada sih. Contoh memecah tabel juga tidak ada, cuma memperbaiki.

Dan informal. Begitu sih.

P-237 : Sup5.2.2 Itu tadi tabel. Kalau source code, misalnya ingin refactor,

disediakan waktu khusus untuk itu?

J-237 : Nggak.

P-238 : Sup5.2.3 OK, kalau begitu saya lanjut bertanya, reverse engineering.

Beda ya, yang tadi restrukturisasi, sekarang reverse engineering.




371


Reverse engineering itu gampangnya, mendapatkan desain dari

source code.

J-238 : Nggak.

P-239 : Baik, langsung lewat.

J-239 : Bisa, sih. Tapi hasilnya akan sangat kusut sekali.

P-240 : Sup5.2.3 Sudah pernah dilakukan? Ada perintah?

J-240 : Nggak, cuma ngetes doang.

P-241 : Sup5.2.4 Oh, inisiatif untuk test? Baik kalau begitu saya lanjut. Kalau

reengineering?

J-241 : Reengineering, akan.

P-242 : Sup5.2.4 Reengineering akan dilakukan. Baik. Berarti belum pernah?

Saat ini belum pernah?

J-242 : Sudah ada ancang-ancang ke situ.

P-243 : Baik, berarti pertanyaan yang ini saya lewatkan. Berikutnya ini

adalah migrasi, Pak. Migrasi ini kita ada nggak yang namanya studi

requirement.

J-243 : Studi requirement?

P-244 : Ini migrasi bukan migrasi data saja ya, tapi migrasi perangkat lunak

juga. Data dan perangkat lunak.

J-244 : Dulu sih ada.

P-245 : Studi requirement maksudnya?




372


J-245 : Iya.

P-246 : Ada diverifikasi nggak? Diuji. Sudah persis dengan requirement. Itu

kapan sih?

J-246 : Dulu pertama-tama. Setelah live ada ganti server. Ada capacity planning.

Ada proyeknya dulu itu. Ada stress test.

P-247 : Tapi dulu banget, ya?

J-247 : Iya. Kalau ganti software iya.

P-248 : Sup5.2.5, Sup5.2.6 Kalau dalam konteks migrasi perangkat lunak ini, ada

nggak ditentukan itu perangkat lunak yang lama mau didukung

sampai kapan? Contohnya, modul claim kita kan sudah integrasi

dengan layanan luar nih, berarti kan ada semacam migrasi. Itu

diverifikasi, nggak?

J-248 : Nggak ada itu, cuma lempar-lemparan data doang, di-replicate.

P-249 : Sup5.2.7 Baik, kalau gitu saya lanjut yang ini. Berikutnya adalah

software retirement.

J-249 : Wah, itu belum ada.

P-250 : Sup5.2.7 Itu kalau software. Kalau fitur?

J-250 : Fitur ada.

P-251 : Sup5.1.2, Sup5.2.7 Ada prosedurnya? Misalnya “source code yang sudah

tidak relevan lagi harus dicabut bersih.”

J-251 : Belum. Source code-nya nggak dicabut, tapi di menu user-nya tidak bisa

di akses.




373


P-252 : Sup5.2.7 Level-nya di situ, berarti?

J-252 : Iya. Itu misalnya kalau bisnisnya sudah berubah.

P-253 : Sup5.2.7 Itu feature retirement ya. Kalau misalnya yang ada fitur

penggantinya, sudah pernah ada yang ada fitur pengganti belum?

J-253 : Ada.

P-254 : Sup5.2.7 Ada, ya. Berarti kan sebetulnya kita mengganti ya, yang A ke

B, gitu ya? Waktu mengganti dari A ke B, ada nggak dinyatakan

“dukungan untuk sistem yang lama ... dukungan sistem yang baru?”

Biasanya yang kayak gitu kan dibikin paralel dulu. Jangan langsung

dimatikan.

J-254 : Nggak ada itu.

P-255 : Baik. Itu mengakhiri pertanyaan untuk Bapak. Semua pertanyaan

sudah berakhir. Kalau begitu saya akhiri dulu. Terima kasih atas

partisipasinya, Bapak IWYS.

J-255 : Terima kasih sama-sama.






374


Lampiran H. Transkrip Wawancara Req4 dan Evo4


Tempat : Ruang Departemen TI

Narasumber : Bapak JW (Kepala Seksi IT Support)




1. SLA and Supplier Agreement Management (Req4)

2. Verification and Validation (Evo4)

P-1 : Saya pagi Pak JW. Kita di sini akan melakukan wawancara dengan

topik utama adalah SLA and Supplier Agreements Management dan

beberapa topik lainnya yang berhubungan dengan pekerjaan Bapak,

untuk pemeliharaan perangkat lunak di Departemen TI PT XYZ.

Sudah siap Pak, untuk pertanyaan pertama?

J-1 : Siap.

P-2 : Req4.0.1, Req4.1.1, Req4.2.6 Kita di PT XYZ ada nggak yang bertugas untuk

menentukan dan memantau tingkat layanan? Maksudnya SLA. Ada

nggak, prosedur untuk membuat kontrak dan SLA dengan supplier,

atau dengan pengguna, atau dengan pelanggan? Ada nggak, ukuran

kepuasan terhadap supplier? Terhadap layanan pemeliharaan. Ada

nggak, survei kepuasan ke pengguna? Atau ke dalam Departemen TI

juga boleh. Yang penting dia survei kepuasan deh. Manajemen

mengamati ... indikator kualitas layanan itu pakai apa? Silakan Pak.

J-2 : Yang pertama, pertanyaannya adalah, apakah ada yang bertugas untuk

menentukan dan memantau tingkat layanan. Saat ini untuk pemantauan itu

dilakukan secara manual, di mana apabila ada gangguan terhadap SLA-nya

itu maka kita akan melakukan eskalasi kepada tim internal support dulu.


375


Apabila tim internal support melihat failure itu pada sisi pihak ke-3, maka

kita akan eskalasi lagi pada pihak ke-3. Tapi tentunya di sini secara

agreement itu, yang ditanyakan adalah berbasis apa? Apakah dia berbasis

jaringan? Apakah dia berbasis software? Apakah dia berbasis hardware?

Karena berbeda. Ini harus ditentukan saja nih. Nah, kalau saya lihat kan

berarti dari software. Nah di sini pun, software pun, ada dua macam kalau

menurut saya. Yang sifatnya dibangun secara built in internal departemen,

ataupun sekarang ini belinya third party software sudah jadi. Jadi kalau

andai kata jawabannya sekarang ini third party software, ada beberapa

software yang kita melakukan renewal maintenance tiap tahunnya, ada

yang tidak. OK, berarti itu sudah menjawab pertanyaan pertama nih ya?

P-3 : Iya.

J-3 : Nomor dua, apakah ada prosedur untuk membuat kontrak dan SLA dengan

pemasok dan pengguna/pelanggan, ini pun ada dua jawaban. Misalnya

seperti ini, ada yang sifatnya itu, untuk SLA-nya itu, dijamin, dan ada yang

tidak dijamin. Mengapa seperti itu? Ada yang one time purchase, artinya

adalah kita melakukan pembelian satu kali beli, tapi kita tidak melakukan

renewal untuk setiap tahunnya. Itu diperbolehkan. Berarti adalah kita

membeli sekali, one time purchase, apabila nanti ada kendala, kita bisa

posting di grup atau mereka punya support. Nanti mereka akan jawab. Ada

lagi yang yang nomor dua. Nomor dua adalah untuk melakukan one time

purchase lalu ada renewal setiap tahunnya. Nah renewal itulah yang

membuat kita mempunyai privilege sebagai client untuk kita melakukan

diskusi apabila kita mengalami issue terhadap SLA aplikasi yang kita

gunakan. Nah itu menjawab pertanyaan nomor dua. Jadi ada yang ada, dan

ada yang tidak. Tergantung dengan aplikasi apa yang kita gunakan.

P-4 : OK.

J-4 : Nah, poin ke tiga. Apakah ada ukuran kepuasan terhadap supplier? Berarti

indikasinya adalah kita melihat ke supplier?

Lampiran H. Transkrip Wawancara Req4 dan Evo4 (lanjutan)


376


P-5 : Iya, betul.

J-5 : Saya rasa sampai saat ini tidak ada. Kenapa? Karena mereka menciptakan

sebuah produk itu bukan berdasarkan customization. Mereka menciptakan

sebuah produk itu berdasarkan dari sifatnya itu general, umum. Mereka

kalau andai kata melihat itu dapat digunakan di masyarakat, dan bisa

dipakai secara umum, diimplementasikan di berbagai macam bidang, maka

tingkat ukuran untuk ... terhadap supplier itu ditentukannya itu adalah ...

sebetulnya dilihatnya itu ... ketika digunakan apakah ada bug atau tidak.

Ketika ada bug tersebut kita laporkan, tapi secara yearly, monthly, atau

weekly, tidak pernah ada informasi yang kita berikan kepada mereka.

Karena sifatnya ini adalah menggunakan aplikasi tetapi tidak berdasarkan

dari kepuasan pelanggan yang ada survei setiap minggu. Atau setiap bulan,

atau setiap tahun. Tidak ada seperti itu. Karena dia kan software. Jadi

mereka akan mengerjakan sesuatu berdasarkan dari laporan/kendala yang

dialami ketika kita melakukannya itu pada saat operasional bisnis. Poin

berikutnya. Apakah ada survei kepuasan ...

P-6 : Sepertinya ini barusan Bapak sudah jawab.

J-6 : Sudah jawab ya?

P-7 : Req4.2.6 Yang bawahnya saja.

J-7 : Dengan apa manajemen mengamati ... indikator kualitas layanan. Nah

kalau andai kata ini, balik ke poin nomor satu yang sudah saya bilang.

Kalau andai kata kita melakukan one time purchase, tidak ada support,

maka kita tidak bisa memaksakan kehendak, harus beres dengan timeline

... seperti apa misalnya. Ada tingkatannya, low, medium, critical atau high

misalnya gitu ya. Kalau andai kata kategorinya itu misalnya critical harus

diselesaikan dalam waktu satu jam, atau dua jam. Tetapi tidak ada indikasi

seperti itu. Kalau yang namanya software itu biasanya indikasinya itu

membutuhkan waktu untuk mereka debugging kembali. Mereka mesti



377


melihat dulu, biasanya itu bukan hanya dari satu aspek saja, tapi ada

beberapa aspek. Contohnya, misalnya kita menggunakan sebuah software,

software tersebut digunakan di platform-nya, OS-nya apa? Lalu hardware-

nya apa? Versinya apa? Bagaimana cara melakukan update-nya? Jadi

indikator kualitas layanan tersebut, itu tidak bisa diputuskan terhadap

sebuah software yang kita gunakan, karena ada banyak aspek. Tergantung.

Kecuali kita sudah melakukan pemetaan. Misalnya yang kita tanyakan ini

adalah software yang sudah berbasisnya itu, tingkat SLA-nya tinggi.

Contoh yang paling nge-top saat ini adalah web based application. Itu

adalah sebuah layanan yang melakukan penjualan jasa, software, tapi tidak

melakukan instalasi pada hardware lokal, tetapi menggunakan basis

koneksi internet, lalu koneksi internet tersebut terhubung dengan mereka

punya data center. Nah itulah yang menggunakan indikator kualitas.

Indikator kualitas itu adalah yang disebut dengan SLA. Layanan yang

diberikan dari si penyedia jasa, kepada customer itu, tersedianya itu,

berapa lama dalam waktu seminggu, dalam waktu sebulan, atau dalam

waktu setahun. Karena kan biasanya dikurangi dengan maintenance,

downtime seperti itu. Itu jawabannya.

P-8 : Req4.2.6 Baik. Berarti pada dasarnya, tergantung pada banyak aspek?

J-8 : Betul sekali.

P-9 : Baik. Kalau begitu saya lanjutkan ke pertanyaan berikutnya. Kita

pada saat ... maaf ... Bapak pada saat membuat persetujuan atau

kesepakatan dengan pemasok, dengan subkontraktor ... kita pakai

subkontraktor nggak ya?

J-9 : Subkontraktor tidak ada. Saat ini kan aplikasi yang dibangun ... ini kita

ngomong software ya?

P-10 : Iya.



378


J-10 : Software tersebut kan kita cuma melihat ada dua aspek, yaitu aspek yang

dibuat customization berdasarkan operasional bisnis PT XYZ, yaitu dibuat

secara internal ... dalam arti kata plus vendor. Jadi internal bekerja sama

dengan vendor. Ada lagi yang nomor dua, adalah yang kita memang beli

aplikasi third party yang memang sudah fixed, sudah jadi. Gitu. Jadi kalau

kontrak, saya kurang tahu yang terkait dengan internal developer plus

vendor, tapi kalau andai kata template kontrak dengan third party, itu ada.

Akan tetapi, tergantung pada one time purchase apa dengan renewal.

P-11 : Baik. Berarti tergantung pada suatu kriteria ... apakah renewal atau

one time purchase gitu ya?

J-11 : Betul.

P-12 : Baik. Kalau misalnya jenis yang renewal berarti, itu ada cara

penentuan kepuasannya? Baik secara kualitatif maupun kuantitatif.

J-12 : Ada. Kalau kita melakukan sebuah renewal, terhadap aplikasi yang kita ...

IT sebutnya itu maintenance ya ... itu ada penilaiannya. Penilaian itu kita

sebut sebagai kualitatif sih, bukan kuantitatif. Kita melihat seberapa cepat

vendor itu membantu kita dalam menyelesaikan sebuah masalah, dan

bagaimana cara mereka merespon masalah tersebut. Apakah dengan

melakukan investigasi secara menyeluruh? Apakah mereka langsung

sudah pernah, mengetahui oh apabila terjadi issue atau insiden seperti ini

maka resolusinya seperti ini. Nah jadi saya melihat dari knowledge

management si vendor. Kalau kuantitatif, angka, kurang bisa dipakai.

Karena biasanya itu yang pertama kali dikirim sudah professional

engineer. Tapi yang kedua kalinya, dilihat yang ini lagi sibuk nih, proyek

ke tempat lain, saya kirim newbie aja deh. Yang baru kerja setahun saya

kirim. Jadi kalau menurut saya, lebih condong menilai secara kualitatif.

P-12 : Baik. Berarti ada ya, caranya.

Lampiran H. Transkrip Wawancara Req4 dan Evo4 (lanjutan) Lampiran H. Transkrip Wawancara Req4 dan Evo4 (lanjutan)


379


J-12 : Ada. Ada caranya.

P-13 : Kita ada laporan kinerja saat ini? Laporan kinerja personil atau

keseluruhan Departemen TI, yang berhubungan dengan software

maintenance?

J-13 : Secara dampak tidak ada. Yang adanya pengukuran terhadap personil IT.

Karena kalau kita mau melihat tolak ukurnya itu terhadap dampak yang

ada dalam personil IT, itu dilihat dari, secara, per tahunnya saja. Biasanya

kan yang namanya software itu kan ada dua. Ada yang monthly based kita

bayar jasanya. Ada yang yearly based kita bayar jasanya. Nah, kalau andai

kata kita ingin melihat yang namanya pengukuran kinerja, itu biasanya

dilihat dari, seberapa tanggapnya kita, atau seberapa detailnya kita, dalam

kita itu, melakukan perpanjangan. Misalnya, kita jangan sampai

melakukan perpanjangan terhadap sebuah third party software, aplikasi,

itu telat. Karena ada dua dampak yang terjadi. Pertama, bisa saja aplikasi

tersebut diblokir oleh si pemilik aplikasi. Kedua, adanya penalty yang

diberikan, dari si penyedia jasa kepada si pengguna. Jadi menurut saya

laporan yang sekarang ini kita buat adalah berdasarkan dari adanya ...

achieve atau tidak achieve kita dalam melakukan monthly or yearly

contract. Seperti itu.

P-14 : Kita saat ini sudah ada semacam checklist belum, Pak? Daftar yang

perlu dilakukan.

J-14 : Checklist yang ada saat ini ... itu sudah saya mulai buatkan. Tetapi kan

setiap data yang ada itu harus divalidasi lagi, apakah data tersebut betul.

Contohnya adalah kita bisa melihat rujukannya itu, terhadap invoice setiap

tahunnya. Contoh, kita memiliki tiga domain. Masing-masing itu

kontraknya beda-beda. Ada yang per tiga tahun, per lima tahun, ada yang

kontraknya itu per satu tahun. Nah dengan adanya perbedaan seperti itu,

maka, kita harus melihat invoice-nya. Kita melihat invoice itu kan, kalau

andai kata tiga tahun kan, berarti kan, nggak mungkin setiap tahun muncul,

kan? Kita mesti investigasi lagi kapan kita terakhir melakukan


380


perpanjangan dengan vendor tersebut. Kita lihat, kita belinya itu

perpanjangannya untuk berapa lama. Apakah setahun? Apakah tiga tahun?

Apakah lima tahun? Seperti itu. Jadi bisa dibilang datanya itu sedang di-

assess kembali. Berarti diinvestigasi dan divalidasi.

P-15 : Baik. Tadi kan Bapak bilang kita sudah ada template kontrak, untuk

yang jenis subscription ya. Itu kalau dari supplier-nya mereka kasih

ketentuan ternyata berbeda dengan yang ada di template, itu kita

negosiasikan supaya jadi sama dengan punya kita atau gimana?

J-15 : Ini maksudnya kontrak awal, atau pelanggaran kontrak ya?

P-16 : Kontrak awal.

J-16 : Kontrak awal setiap penyedia jasa, mereka itu mempunyai template yang

sifatnya itu umum. Juga, pengalaman saya ada beberapa vendor penyedia

jasa itu, dia itu membagi kontraknya itu dari bidang bisnis. Karena

berbeda-beda. Contohnya bisnis banking dan ada lagi dengan yang

bergerak di distribusi FMCG itu berbeda-beda. Jadi mereka sudah punya

template. Akan tetapi template tersebut apakah valid atau tidak bisa

digunakan terhadap sebuah perusahaan yang nanti mau join dengan

mereka, belum tentu juga. Mereka itu mempunyai framework bisa kita edit

sesuai dengan kita punya kemauan. Akan tetapi dikembalikan lagi kepada

vendor, apakah vendor tersebut mau peraturan main yang kita inginkan

tentunya kan kita sebagai pengguna jasa itu kan menginginkan untuk yang

senyaman mungkin dan fleksibel. Karena kita kan bisa dibilang adalah,

pembeli adalah raja. Konsepnya di Indonesia adalah seperti itu. Nah,

tentunya dengan fleksibilitas yang kita inginkan, belum tentu semua

penyedia jasa itu bisa memenuhinya. Jadi tentunya ada kedua belah pihak

yang harus sama-sama setuju dengan kita tahu apa keuntungan dari

kontrak tersebut dan apa kekurangan dari kontrak tersebut. Jadi, secara

menyeluruh, tidak mungkin, kesepakatan itu hanya terjadi oleh satu belah

pihak saja tetapi oleh kedua belah pihak. Tetapi kalimatnya adalah



381


mengetahui, bahasa Inggrisnya adalah acknowledgement, mengetahui

bahwa di dalam kontrak tersebut akan ada yang namanya penyempurnaan.

Karena setiap kontrak balik lagi dilihat dari bidang-bidang bisnis yang

dilakukan oleh masing-masing pengguna jasa. Seperti itu. Contoh: ada

yang bisnis bergerak 24×7, ada yang hanya 8×7, ada lagi yang 7×5. Itu

membuat perbedaan-perbedaan.

P-17 : Kalau misalnya dalam kontrak awalnya ini ada ketentuan dari

supplier, ada ketentuan dari PT XYZ, tidak terjadi kesepakatan , itu

kita utamanya ganti pemasok, apa mencari kompromi? Ini dari sudut

pandang kita, bukan dari sudut pandang supplier.

J-17 : Kalau sampai ada ketidaksepakatan, kita melihat dulu adalah secara risiko.

Karena kalau kita melihat vendor itu, kita melihat bukan vendor yang

dapat berkata kepada kita “apa yang Bapak inginkan kita sepakat.” Kita

harus melihat dari segi profesionalisme mereka, kredibilitas mereka.

Tentunya vendor itu, setiap tahun itu ada review-nya. Kita lihat dari

portfolio company mereka. Berapa banyak client, besar ataupun kelas

small to medium business, yang mereka pegang. Tentunya itu akan

menjadi tolak ukur. Kalau misalnya negosiasinya itu tidak bisa mencapai

kesepakatan, maka kita melihat ukurannya dulu. Ukurannya seperti ini.

Kita melihat vendor yang pertama adalah vendor yang terbaik di

Indonesia. Lalu kita melihat vendor ini sepertinya apabila kita panggil

mereka untuk berdiskusi, setelah kontrak terjadi, agak susah nih. Alot,

tidak bisa berjalan dengan lancar. Makanya kita mesti melihat opsi nomor

dua. Urutan nomor dua yang terbaik. Jadi kalau risiko dengan pihak nomor

satu terlalu tinggi, kita lihat pihak nomor dua yang lebih fleksibel. Jadi kita

melihat dari yang terbaik, lalu ke nomor dua, nomor tiga, nomor empat,

sampai dengan yang memenuhi kebutuhan kita. Kita lihat dari fleksibilitas

mereka punya bisnis. Kalau di bidang software ada yang namanya gold

partner, silver partner, platinum partner. Itu award yang mereka dapat

berdasarkan dari berapa banyak konsumen yang mereka bisa dapatkan.



382


Jadi principal mereka melakukan review setiap tahun dan memberikan

award kepada mereka. Jadi negosiasi dengan vendor itu banyak sekali

aspeknya. Belum tentu vendor terbaik cocok dengan kita sebagai kita

pengguna jasa. Seperti itu.

P-18 : Req4.2.1 Baik. Bapak ada melakukan sosialisasi SLA atau kontrak

formal ke anak buah Bapak?

J-18 : Tentu. Kalau kita ngomong SLA sebuah software, kita harus ngomong ke

anak buah. Karena vendor akan bertanya ke kita “Pak, kita boleh minta

alamat email Bapak?” Email yang diminta ini adalah email yang akan

ditaruh sebagai alamat kontak, untuk vendor atau principal menghubungi

kita. Atau, agar kita bisa membuat tiket pada support mereka. Maka

pengenalan terhadap kontrak itu perlu kita informasikan. Dengan ada

pengenalan kontrak tersebut, maka tim, anak buah kita, rekan kerja kita,

akan mengetahui apabila kita punya kontrak hanya 8×7, berarti kan itu

office hour ya, apabila terjadi sesuatu kendala dalam operasional bisnis,

melewati dari basis jam kerja tersebut, maka harus menunggu di besoknya.

Jadi pengenalan SLA terhadap sebuah produk itu harus dilakukan. Harus

dibaca kontrak demi ... poin demi poin, dan kita melihat apakah itu sesuai

dengan kita punya operasional atau tidak.

P-19 : Req4.2.2 Baik. Adakah maintainer yang ditugaskan sebagai account

manager? Itu dari bagian Bapak, ada nggak orang yang ditugaskan

misalnya Pak A untuk kontrak dengan vendor X, kalau dengan vendor

Y maka si B orangnya dari kita.

J-19 : Itu apabila sebuah perusahaan sudah mempunyai divisi IT, sudah

menerapkan konsep ITIL dan ITSM. Artinya sudah ada segmentasi dalam

pembagian kerja. Contohnya divisi IT itu dibagi menjadi beberapa

departemen, ada departemen services, kedua infrastruktur, ketiga untuk

database. Di bawah services ada beberapa unit, yaitu help desk, support,

dan asset management. Di bawah infrastruktur, ada sysadmin, lalu data



383


center, lalu security, ada network. Nah itu bisa dialokasikan per masing-

masing unit sebagai PIC berdasarkan job description mereka. Di PT XYZ

saat ini tidak ada segmentasi untuk departemen dan unit. Di divisi IT, ada

support dengan orang yang mempunyai multi skill, di mana mereka

bertanggung jawab untuk semua operasional baik itu services maupun

infrastruktur. Jadi sampai dengan saat ini kalau saya melihat, itu hanya

terjadinya itu hanya apabila kita sudah mempunyai segmentasi. Kalau

belum mempunyai segmentasi seperti saat ini, berarti contact person-nya

adalah saya. Apabila tidak ada saya, berarti ke bawah. Dan mulai tahun

2017, saya selalu menginformasikan kepada vendor, atau principal, rekan

kerja saya siapa saja, apabila saya tidak ada, silakan berhubungan dengan

rekan-rekan kerja saya.

P-20 : Req4.2.3 Baik. Sewaktu kita mau melakukan kontrak yang berdasarkan

subscription, untuk SLA kita meminta pendapat dari para pemangku

kepentingan nggak?

J-20 : Kalau untuk software yang digunakan oleh client dan di-hosting-nya di

data center, infrastrukturnya PT XYZ, maka kita kembalikan lagi kepada

customer-nya. Kita untuk PT XYZ operasional bisnis itu ada dua

segmentasi. Kita sebagai fasilitator network, hardware, data center, kita

instalasi, kita siapkan operating system-nya, platform dasarnya, tetapi

untuk aplikasi, SLA-nya itu ditentukan kepada pengguna. Jadi bisa

dibilang kita hanya penyedia jasa untuk hosting. Kecuali kita penyedia jasa

sekaligus pengguna. Misalnya Active Directory. Itu SLA-nya saya yang

memutuskan. Tetapi kalau yang IT hanya menyediakan jasa yang sifatnya

jaringan, infrastruktur, maka aplikasi itu SLA-nya dikembalikan kepada si

pengguna dan pembuat aplikasi tersebut. Sehingga kesepakatan yang harus

dilakukan antara vendor, dengan si pengguna atau si pembuat, itu di antara

mereka. IT tidak ikut campur tangan di situ.



384


P-21 : Req4.2.3 Kalau misalnya yang kita hosting ... misalnya Sistem Informasi

Asuransi Umum, Bapak kan menyediakan server, jadi kalau misanya

perlu tambah memori nih, itu kan bagian Bapak berarti?

J-21 : Iya.

P-22 : Req4.2.3 Misalnya waktu mau tambah memori Sistem Informasi

Asuransi Umum harus dimatikan dulu. Itu Bapak melakukan

sosialisasi kepada para pengguna?

J-22 : Oh tentu. Itu ada planned outage dan unplanned outage. Kalau planned

outage berarti kan ada change management yang harus dijalankan. Harus

ada persetujuan apakah aplikasi ini bisa dimatikan terlebih dahulu, dari

jam berapa sampai jam berapa, di hari apa. Tentunya kita izin dulu. Dan

itupun, misalnya permintaan-permintaan peningkatan performa, itukan

biasanya datang dari pengguna, setelah mereka melihat operasionalnya

seperti apa, atau mungkin diskusi dengan vendor dampaknya seperti apa.

Baru disampaikan ke kita. Jadi apabila tidak ada request dari end user,

atau apabila tidak ada hardware failure yang terjadi unplanned, maka kita

tidak akan melakukan perubahan apapun. Kecuali kalau ada audit yang

dilakukan, findings yang dihasilkan, kita akan melakukan patching. Berarti

itu dari sisi kita. Kita yang melakukan request kepada pengguna maupun

penyedia jasa, vendor, bahwa kita ingin melakukan patching. Kita ngobrol

dulu dengan mereka. Itu tetap kategorinya planned outage. Kalau

unplanned, contohnya hardware failure. Contoh: power supply rusak,

listrik mati, UPS tidak merespon, kerusakan motherboard, kerusakan disk,

seperti itu.

P-23 : Req4.2.4 Baik. Pada dasarnya ada dua jenis outage ya? Jadi sosialisasi

juga tergantung pada jenis outage. Kita ada prosedur pemilihan

vendor nggak, Pak? Kriteria maksudnya. Kita membuat kriteria, baru

dicari balance-nya yang mana vendor yang cocok dengan kita?



385


J-23 : Tidak ada sih, saat ini. Saat ini kita dicari yang paling murah. Tentunya

vendor yang kredibilitas Tbk dengan perusahaan yang belum berbasis Tbk,

tentunya akan mempunyai tawaran untuk kontrak yang berbeda. Karena

yang dilihat bukan hanya produk yang ditawarkan, tapi juga kredibilitas

mereka sebagai penyedia jasa. Sampai dengan saat ini, tidak ada checklist

untuk vendor yang akan menyediakan jasa untuk kita.

P-24 : Req4.2.5, Req4.2.6 Baik. Apakah ada template kontrak ... tadi sudah dijawab

... kita lanjut saja. Kita sanggup memonitor SLA, Pak?

J-24 : Tentunya kalau ditanya sanggup, tidak bisa dimonitor secara manual,

karena dihitung dari departemen yang ada, yang saya bilang belum

tersegmentasi unitnya. Bisa, tapi di PT XYZ belum diimplementasikan

karena adanya beberapa indikasi biaya yang perlu diimplementasikan. Itu

tidak bisa diimplementasikan secara berbarengan dalam setahun karena

biaya investasinya cukup tinggi.

P-25 : Req4.2.7 Baik. Kalau misalnya kita mau mengadakan perubahan skop

kerja ke vendor, kita sudah ada prosedur dalam hal itu? Ini kita

ngomong prosedurnya Pak.

J-25 : Prosedural apa ini? Latar belakang atau eksekusi. Kalau eksekusi, ada form

yang mesti diisi. Kalau software itu tidak ada yang perlu kita isi, tapi kita

mengajukan proposal. Misalnya saat ini kita aplikasi yang layanannya per

bulan, paket standar, kita mau naikkan ke paket profesional. Biasanya ada

proposal yang mesti kita ajukan, alasannya mengapa, mesti diisi. Kalau

yearly mesti diisi. Kalau monthly tidak ada, tinggal menunggu per

bulannya habis, bulan berikutnya kita perpanjang pilih yang paket

profesional. Kalau jaringan, biasanya kontrak lama di-terminate, kita

ajukan proposal kontrak baru. Itu biasanya kalau sudah melewati batas

waktu yang ditentukan dalam kontrak ya, karena kalau di bawah batas

waktunya, biasanya ada penalty yang mesti kita tanggung.



386


P-26 : Req4.2.7 Kalau untuk jaringan ini, prosedur terdokumentasinya belum

ada ya?

J-26 : Ada, kita diberikan sebuah dokumen. Ada dokumentasinya.

P-27 : Req4.2.7, Req4.2.8 Ada ya. Baik. Kita ada meeting tinjauan formal ...

review?

J-27 : Kalau review tidak perlu meeting, karena setiap bulannya itu selalu

diberikan informasi dari berapa layanan yang kita gunakan itu, berapa

persentase SLA yang diberikan. Setiap bulan. Dari target 99% bulan ini

terjadi downtime beberapa kali, di beberapa tempat, diinformasikan,

berdasarkan dari persentase. Kalau jaringan sifatnya per bulan kalau kita

minta.

P-28 : Req4.2.7 Laporan SLA berarti datang dari vendor ke kita? Tinjauan

berdasarkan laporan dari vendor?

J-28 : Betul. Iya.

P-29 : Baik. Kalau misalnya tidak tercapai nih, SLA dari vendor ... sudah

pernah kejadian belum, tidak tercapai?

J-29 : Sudah, sudah pernah.

P-30 : Itu tindakan korektif dari kita apa ya? Bukan dari mereka, dari kita.

J-30 : Tindakan korektif apa nih sifatnya?

P-31 : Misalnya kita kepingin supaya itu ke depan tercapai. Tidak terjadi

lagi.

J-31 : Kayaknya kalau kita menggunakan jasa, dari vendor, kita harus melihat

dulu job description dan scope of work mereka dulu. Misalnya mereka

menyediakan jaringan kabel sampai kantor kita, dan mereka menyediakan

router. Dari bagian kita, listrik, rak, UPS, kita mesti lihat dulu. Kalau kita,



387


di cabang-cabang ada yang listriknya kurang stabil. Jadi kalau perangkat

dipasang, tidak akan bisa bertahan 24×7. Kita mesti lihat, introspeksi diri

kita juga. Kita mesti menyediakan standar minimum mereka. Misalnya

mereka bilang “Pak, kalau saya mau meminjamkan alat ke Bapak, Bapak

mau menggunakan jasa kita, bisa. Tapi Bapak mesti menyediakan satu, rak

dulu, supaya aman, tidak ada orang yang bisa sentuh langsung hardware-

nya. Kedua availability untuk listrik. Kalau sampai listrik ada gangguan,

kita ada UPS bisa menyediakan daya sampai 2 jam. Besaran SLA sebesar

ini.” Jadi harus ada hubungan timbal balik berdasarkan dari kontraknya.

Jadi bisa dibilang, kerja sama tetap harus dilakukan antara kedua belah

pihak. Kalau andai kata korektif, itu tergantung dari kita. Kita yang

penting asal jalan, atau kita punya standarisasi yang akan kita

implementasikan tiap kantor?

P-32 : Standarisasi antar cabang kita belum ada ya?

J-32 : Belum ada saat ini. Di cabang ada yang mengikuti standarnya kita, ada

juga yang nggak.

P-33 : Req4.2.9, Req4.2.10, Req4.2.11, Req4.2.12 Kita menyediakan layanan kepada

internal, atau cabang, itu ada semacam billing internal nggak, Pak?

J-33 : Tidak ada. Pertanyaan kamu itu berhubungan dengan yang namanya cost

center dan profit center. Itu konsepnya mengeluarkan uang bukan dari

budget IT, melainkan dari budget mereka. Kalau billing, itu berarti kita

menyediakan fasilitas dan jasa kepada mereka. Nah itu belum berjalan di

sini.

P-34 : Req4.2.12 Baik. Berarti pertanyaan tentang simulasi tagihan tidak perlu,

sistem tagihan tidak perlu, pengukuran SLA dan laporan kinerja

untuk tagihan juga tidak perlu, dan laporan biaya-biaya ...yang ini

sepertinya masih nyambung Pak. Kita ada nggak, laporan-laporan



388


tentang pengeluaran IT untuk infrastruktur, software, mingguan atau

bulanan, yang dikarenakan maintenance?

J-34 : Anggaran tahunan kita itu dibagi dua, opex sama capex. Pertanyaan ini

menyangkut opex. Ini biaya jaringan per bulan, biaya renewal.

P-35 : Req4.2.12 Berarti ada catatan untuk hal itu?

J-35 : Saya sih baru buat ya. Sebelumnya nggak ada.

P-36 : Oh, baik. Itu bisa dibagi berdasarkan kategori pemeliharaan?

Misalnya kelihatan yang karena insiden ...

J-36 : Oh, nggak ada. Sifatnya itu satu kontrak maintenance untuk semuanya.

P-37 : Evo4.2.3 Baik sekarang kita keluar dari SLA and Supplier Agreements

Management. Berikutnya masuk ke Verification and Validation. Hanya

satu pertanyaan yang langsung berkaitan dengan Bapak. Kita

melakukan peninjauan aktivitas maintenance oleh supplier atau

vendor, apa tidak? Bapak meninjau nggak, langkah-langkah dari

mereka itu apa?

J-37 : Itu saya melakukan interview saat mereka bilang “Pak ini membutuhkan

waktu satu sampai dua bulan”. Kita bisa bertanya kepada mereka, secara

prosedural eskalasinya, untuk perbaikan seperti apa. Vendor akan

menjelaskan seperti apa langkah-langkah, tapi secara detail kita tidak bisa

mengetahuinya. Hanya indikasi waktu berapa lama yang dibutuhkan.

P-38 : Baik, itu saja pertanyaan untuk Bapak. Saya akhiri wawancaranya,

terima kasih atas partisipasinya Bapak JW. Selamat siang.

J-38 : Selamat siang.

Lampiran H. Transkrip Wawancara Req4 dan Evo4 (lanjutan) Lampiran H. Transkrip Wawancara Req4 dan Evo4 (lanjutan) Lampiran H. Transkrip Wawancara Req4 dan Evo4 (lanjutan)


389


Lampiran I. Transkrip Wawancara Pro1, Pro2, Pro3, Pro4, Pro5, dan Sup2


Tempat : Ruang Departemen TI

Narasumber : Kepala Departemen TI





2. Maintenance Process/Service Definition (Pro2)

3. Maintenance Training (Pro3)

4. Maintenance Process Performance (Pro4)

5. Maintenance Innovation and Deployment (Pro5)


P-1 : Selamat sore Pak RK, saya ingin melakukan wawancara dengan

Bapak yang berkaitan dengan topik karya akhir saya, software

maintenance. Di sini Bapak ada banyak topiknya, saya akan bertanya

satu demi satu. Siap?

J-1 : Iya, siap.

P-2 : OK Bapak RK, pertanyaan pertama adalah untuk topik Maintenance

Process Focus. Jadi inti dari banyak pertanyaan ini adalah, apakah

kita di Departemen TI ada yang namanya fokus untuk proses

maintenance. Fokusnya itu, dia dalam arti improvement.

J-2 : Improvement, iya OK.

P-3 : Pro1.0.1 Terus apakah dia dilakukan secara formal atau tidak formal.

Yang formal itu maksudnya yang periodik, ada jadwalnya, termasuk

dalam program kerja Bapak misalnya. Untuk yang pertama, apakah


390


kita melakukan aktivitas perbaikan proses, yang mengarah kepada

perbaikan yang terkendali dan terus-menerus Pak?

J-3 : Perbaikan proses, pertanyaannya lebih ke melakukan aktivitas perbaikan

proses, saya jelaskan yang ada dulu aja mungkin. Nanti itu dinilai ke sana

apa bukan. Yang ada sekarang di kita itu adalah satu, kita punya KPI untuk

kecepatan aplikasi. Jadi kecepatan aplikasi kita punya KPI, rata-rata user

klik ... user response-nya ... ada beberapa matriksnya lah gitu. Itu memang

baru hampir dua tahun kita punya KPI itu, sejalan dengan ininya

perusahaan. Itu metode implementasi di mana kita melihat dari seluruh

user response ... application response, kita matriks ... terus kita ambil rata-

ratanya. Nah, terus untuk yang tidak memenuhi dengan SLA itu, kita lihat

kenapa. Itu dilakukan terus-menerus. Mungkin itu yang satu, yang

memenuhi kriteria perbaikan yang terus-menerus. Yang kedua, sebenarnya

yang kita lakukan adalah kita adakan beberapa forum-forum. Contohnya

setiap tahun itu sebenarnya ada dua forum ... marketing dan underwriting,

yang baru kita lakukan kita ada beberapa software modul, tapi yang inti

core system kita adalah untuk policy administration. Nah yang untuk

policy administration itu kita biasanya ada forum setahun dua kali,

bersama dengan business user, untuk melihat apakah ada kendala-kendala

yang ada di sistem kita. Nah, itu diinventori, dijadikan semacam list untuk

enhancement. Itu tapi memang dibagi dua, itu satu yang kita nilai besar,

dijadikan proyek, yang user requirement yang bisa kita kerjakan langsung

kita kerjakan langsung.

P-4 : Pro1.0.1 Bapak pernah membawa topik yang namanya agile methodology

ke saya. Itu termasuk salah satu perbaikan proses?

J-4 : Iya, itu kita mau lihat ... kita kan pasti review juga setiap tahun, kita ada

berapa proyek. Secara involvement-nya berapa, secara pengerjaannya kita

Lampiran I. Transkrip Wawancara Pro1, Pro2, Pro3, Pro4, Pro5, dan

Sup2 (lanjutan)


391


speed-nya berapa, gitu. Dengan metodologi itu, yang kita baca-baca, kita

ketahui bisa improve untuk proses itu.

P-5 : Pro1.1.1 Baik. Berarti sebetulnya bisa dibilang kalau ...

J-5 : Secara konsep iya, tapi informal iya. Informal, belum ada blueprint, belum

ada SOP-nya untuk Kanban dan lain-lain. Belum ada itu.

P-6 : Baik. Agile methodology itu seingat saya sudah masuk ke dalam

program Bapak sebetulnya.

J-6 : Iya.

P-7 : Jadi sudah direncanakan dari tahun lalu?

J-7 : Sudah direncanakan.

P-8 : Itu Bapak memang ada sasaran, misalnya ya, tahun depan kita akan

perbaikan proses, bukan maintenance, misalnya untuk tim reporting

kita perlu diperbaiki kira-kira dengan menggunakan jalan ini.

Misalnya setelah itu untuk help desk kita perlu diperbaiki dengan

jalan ini. Sudah ada itu?

J-8 : Blueprint-nya sebenarnya sudah ada. Blueprint-nya mau ke mana mau ke

mana lima tahun ... salah satunya itu. Meningkatkan proses, sebenarnya

nggak hanya di IT-nya, tapi proses secara keseluruhan. Contohnya kita

juga mau ada proyek besar lagi untuk revamp Sistem Informasi Asuransi

Umum, core system kita.

P-9 : Baik. Tapi itu sepertinya proyek besar ya?

J-9 : Iya, tapi barangkali ada yang kecil. Maksudnya itu.


Sup2 (lanjutan)


392


P-10 : Pro1.1.2 Perbaikan proses itu tadi sebetulnya masuk ke dalam job

description Bapak, atau inisiatif Bapak?

J-10 : Job description pasti.

P-11 : Pro1.1.2 Baik, berarti bagian dari job description Bapak.

J-11 : Tidak secara harfiah, tapi ...

P-12 : Pro1.2.1 Baik. Kita sudah ada, sudah pernah belum, misalnya kalau kita

mau meningkatkan, memperbaiki proses, itu pada dasarnya

meningkatkan kualitasnya pelayanan kepada pengguna kita. Itu

sudah pernah melakukan pelatihan kesadaran kualitas bagi anggota

tim? Ini maksudnya bukan secara formal, misalnya dikumpulkan

secara meeting baru Bapak menjabarkan sasaran kita itu seperti apa.

J-12 : Kalau quality awareness belum. Kalau yang ada itu, “oh kita punya target

seperti ini.” Sekarang company punya strategic initiative, kita di IT kena

yang mana aja. Kemudian apa yang harus kita inikan secara perannya.

Tapi secara awareness ini sayangnya belum.

P-13 : Pro1.2.1 Itu yang Bapak bilang strategic objective itu Bapak

sosialisasikan ke personil Bapak, staf Bapak?

J-13 : Yang kita tunjuk sebagai pelaksana proyek saja. Nggak seluruh tim IT

memang.

P-14 : Pro1.2.1 Baik, berarti yang Bapak anggap relevan secara pencapaian

langsung, begitu ya?

J-14 : Iya, iya, iya.

P-15 : Pro1.2.2 Baik. Untuk kegiatan koordinasi atau perencanaan perbaikan

proses ini, misalnya kayak agile methodology tadi, itu Bapak ada


Sup2 (lanjutan)


393


menunjuk person in charge-nya nggak? Apa Bapak misalnya Bapak

sendirilah orangnya? Atau misalnya Bapak ada menunjuk anak buah

Bapak?

J-15 : Sekarang saya ambil tanggung jawab sendiri. Tapi memang kita lagi mau

untuk ... ini kan mau ikut training, beberapa saya sudah tunjuk untuk mau

ikut training, begitu. Kira-kira saya sudah bilang bahwa, you sebagai

product owner-nya, ini sebagai Scrum Master-nya.

P-16 : Pro1.2.2 Berarti pada dasarnya, kalau misalnya kalau saya ringkas,

untuk tahap awal sekarang ini, PIC Bapak sendiri, tapi ke depan

nanti setelah training itu, diharapkan peserta training itu menjadi

PIC?

J-16 : Iya.

P-17 : Pro1.2.3 Baik. Di Departemen TI, kita ada survei untuk kepuasan

pengguna terhadap proses perawatan perangkat lunak, Pak?

Misalnya ...

J-17 : Belum. Paling yang ada adalah mereka kan belum ada surveinya tapi kita

bisa lihat sedikit, kita kan punya semacam ticketing. Berarti kalau ada

iteration berarti ada missing link di situ. Tapi secara formal untuk ini ...

P-18 : Pro1.2.3 Survei formal belum ada?

J-18 : Belum.

P-19 : Pro1.2.4 Kalau survei terhadap tim Bapak sendiri? Misalnya

menanyakan ini misalnya bottleneck-nya di mana? Ini tidak harus

semua, bisa jadi Bapak hanya menunjuk hanya kepala seksi.

J-19 : Kita lagi berusaha menjamin SLA. Membangun SLA. Berapa banyak yang

tidak memenuhi SLA pasti kita review. Kenapa ini tidak terpenuhi.


Sup2 (lanjutan)


394


P-20 : Pro1.2.4 Berarti sebetulnya Bapak ada mengumpulkan data untuk

pencapaian SLA. Kalau untuk memperbaiki proses? Misalnya dengan

memperbaiki proses harapannya SLA tercapai. Ada seperti itu?

J-20 : Ya kadang-kadang ada. Misalnya sekarang kita mau implementasi user

portal sendiri untuk user submission. Sekarang itu ada bottleneck harus

ada orang yang assign ke kategori-kategori tertentu. Satu orang assign.

Kita mau hilangkan itu, supaya langsung bisa automatic assign. Jadi

digantikan dengan software.

P-21 : Baik Pak. Kita ada melakukan profiling terhadap perangkat lunak

kita. Maksudnya Sistem Informasi Asuransi Umum itu I/O-nya

seperti apa, penggunaan hard disk-nya …

J-21 : Oh, sudah. Ada. Kita namanya stress test. Itu kita punya benchmark-nya.

Kita punya tool untuk benchmark. Kalau misalnya kita ganti perangkat

lunak, perangkat keras, atau server. Cara kita test kita pump kita punya

transaction. Nggak semua transaction, kita bikin sendiri tool-nya. Itu nanti

hasilnya berapa rata-rata transaction. Kalau kita pump 20 transaksi per

detik, berapa responsnya. Kalau 5 transaksi per detik berapa responsnya.

Begitu.

P-22 : Pro1.2.5 Hasil dari profiling atau benchmarking itu disimpan?

J-22 : Dulu disimpan.

P-23 : Pro1.2.5 Secara berkala?

J-23 : Nggak, yang ini nggak secara berkala. Yang secara berkala itu yang

sedangkan kita lakukan ... mau kita lakukan.

P-24 : Pro1.2.5 Targetnya ke depan ini kita lakukan secara berkala?


Sup2 (lanjutan)


395


J-24 : Yang kayak tadi, SLA. Application response time. Itu kita sedang hitung

rata-ratanya berapa. Kita punya target semua rata-rata itu under 5 seconds.

Itu globalnya tapi kan memang ada bagian aplikasi yang cepat, dan ada

yang lambat.

P-25 : Pro1.2.5 Baik. Kalau perbandingan antar modul ada nggak? Misalnya

modul accounting rata-ratanya, dibandingkan dengan finance, atau

dibandingkan dengan claim.

J-25 : Nggak, itu belum.

P-26 : Pro1.2.6 Baik. Kita ada mengumpulkan data kesalahan. Kesalahan di

sini failure. Maksudnya bisa dalam bentuk bug, outage, ada

dikumpulkan?

J-26 : Iya.

P-27 : Pro1.2.6 Direkap?

J-27 : Kalau mau laporan iya. Maksudnya secara periodik kita mau lapor ke

steering committee kita lapor berapa bug yang kita kerjakan, turun apa

naik gitu.

P-28 : Pro1.2.6 Itu digunakan untuk pengambilan keputusan perbaikan proses,

Pak?

J-28 : Iya. Jadi misalnya, kenapa ada problem yang berulang, ini masalahnya

apa? Oh, kita mesti betulkan software-nya. Karena kesalahan user

misalnya, harus ada intervensi dari IT untuk perbaikan data. Kita juga

perbaiki gimana caranya supaya si user nggak usah ... kesalahannya bisa

diminimalkan.

P-29 : Pro1.2.7 Kita sudah pernah audit terhadap standar, Pak. Misalnya ISO

9001 ...


Sup2 (lanjutan)


396


J-29 : Belum.

P-30 : Pro1.2.8 Kita sudah pernah dikaji terhadap suatu model referensi,

seperti CMMI-DEV?

J-30 : Belum.

P-31 : Pro1.2.9 Bapak ada membuat daftar kandidat perbaikan?

J-31 : Ada. Itu biasanya kita punya list improvement. Ada yang secara aplikasi

harus ada perbaikan besar, dalam bentuk proyek. Kalau minor change

request, itu nggak berdasarkan proyek.

P-32 : Pro1.2.9 Baik. Itu dokumennya dalam bentuk apa ya, Pak?

J-32 : Dalam bentuk project plan. Bukan project plan, list lah.

P-33 : Pro1.2.10 Apakah kita ada top 10 improvement yang berdasarkan

pentingnya, prioritasnya? Ini tadi Bapak sudah jawab ya? Sudah

dilakukan.

J-33 : Mungkin bukan top 10, tapi ada kriterianya satu, dua, tiga. Satu itu very

important kita langsung kerjain. Dua hold off dulu. Tiga ...

P-34 : Pro1.2.11 Baik. Rencana perbaikan proses yang sudah dimulai ada?

J-34 : Ada. Itu yang sedang kita berusaha implementasi. Lagi baru first starting,

cari metodenya dulu.

P-35 : Pro1.2.11, Pro5.2.3 Sudah dijalankan, ya?

J-35 : Bukan berarti sudah dijalankan, baru kita mengarah ke sana, lagi mau

proses, implementasi ke sana.


Sup2 (lanjutan)


397


P-36 : Itu mengakhiri topik Maintenance Process Focus. Berikutnya

Maintenance Process/Service Definition. Intinya adalah layanan kita,

atau proses-proses yang ada di Departemen TI yang berhubungan

dengan maintenance itu ada nggak yang bertugas untuk menentukan

apa aja layanannya, prosesnya seperti apa, yang perlu diikuti itu

prosedurnya seperti apa?

J-36 : Itu belum kayaknya.

P-37 : Atau misalnya, bisa jadi sebagian sudah ada.

J-37 : Mendefinisikan proses layanan ... contohnya seperti apa ya?

P-38 : Pro2.0.1 Misalnya Bapak menentukan, kalau orang mau meminta

perubahan, CR, itu prosesnya seperti apa. Harus dari mana dulu,

formulir apa yang perlu diisi. Yang seperti apa yang benar layak

menjadi CR. Ada kategorinya.

J-38 : Ada sih. Jadi misalnya, kita punya module owner, kita punya Business

Analyst, ada SOP-nya. Kalau misalnya ada bug, bagaimana. Kalau bug kan

lebih simpel, ya. Kalau misalnya berasa lambat, itu ada prosedur.

P-39 : Pro2.1.1 Baik. Apakah itu formal atau informal? Tapi ini sudah ada

SOP, berarti formal ya?

J-39 : Iya.

P-40 : Pro2.1.1, Pro2.2.1 Inisiatif individu juga sudah terjawab. Karena formal

bukan inisiatif individu. Nah, yang bertugas untuk merancang

dokumen standar, itu Bapak?

J-40 : Business Analyst.

P-41 : Pro2.1.2, Pro2.2.1 Itu disebar ke pengguna nggak dokumennya?


Sup2 (lanjutan)


398


J-41 : Dokumen nggak disebar, tapi orang sudah tahu bahwa kalau mau ada

misalnya CR, itu masuk user ticket aja, lalu nanti kita yang proses. Sesuai

dengan itu.

P-42 : Pro2.2.2 Kita ada dokumentasi yang berisi daftar resource? Dalam hal

ini personil, tool, perangkat lunak pembantu, lingkungan kerja seperti

misalnya Flash atau Blitz, standar pemrograman. Contoh standar

pemrograman itu naming convention. Ini kita ada semacam

inventorinya nggak Pak?

J-42 : Kalau standar programming ada. Kalau khusus maintenance nggak ada.

P-43 : Pro2.2.3 Kita ada aktivitas untuk mendokumentasikan dan

menstandarkan proses pemeliharaan perangkat lunak, Pak?

J-43 : Ada. Sudah ada functional spec-nya, harus tanda tangan siapa gitu.

P-44 : Pro2.2.4 Baik. Bapak sebagai manajer, ada mempromosikan standar

nggak? Maksudnya ISO 9001 atau yang lain. Ke bawahan Bapak.

J-44 : Tidak. Saya justru lebih ke metodologinya dulu daripada ini. Saya mau ke

agile. Itu yang saya pikir lebih benefit.

P-45 : Pro3.0.1 Baik. Itu mengakhiri pertanyaan tentang topik Maintenance

Process/Service Definition. Topik berikutnya adalah yang namanya

Maintenance Training. Yang dimaksud di sini training sekitar

maintenance. Apakah Departemen TI memiliki kegiatan pelatihan

yang terstruktur, yang mengatasi kegiatan predelivery and transition,

pelatihan yang berkaitan dengan perangkat lunak yang dirawat

sekarang, pelatihan yang berkaitan dengan proses perawatan

perangkat lunak, dan pelatihan yang bertujuan untuk meningkatkan

rencana karier atau semangat kerja personil?


Sup2 (lanjutan)


399


J-45 : Belum sih.

P-46 : Pro3.0.1 Baik. Kalau begitu ini satu topik saya skip.

J-46 : Eh, di bawah-bawah itu pertanyaannya apa? Bisa dicoba dulu?

P-47 : Pro3.0.1 Apakah topik pelatihannya tentang manajemen maintenance?

Proses maintenance? Aktivitas maintenance? Apakah kita sudah

mengidentifikasi pelatihan apa yang perlu diadakan, dan kelemahan

pelatihannya itu apa? Semua fokusnya ke maintenance.

J-47 : Belum sih. Belum.

P-48 : Pro4.0.1 Baik. Itu mengakhiri tentang Maintenance Training. Berikutnya

adalah Maintenance Process Performance. Kita ada aktivitas untuk

mengukur kinerja proses, Pak?

J-48 : Iya sih, kalau untuk ini. Misalnya ... khusus untuk software maintenance

ya?

P-49 : Pro4.0.1 Iya.

J-49 : Lebih ke bug-bug itu sih. Penyelesaian bug-bug itu. Rentang waktunya.

Berapa cepat penanganannya.

P-50 : Pro4.1.1 Pengukurannya itu formal, apa berupa inisiatif individu? Jadi

kalau formal sudah ada cara pengukuran yang diakui untuk satu

departemen.

J-50 : Belum formal sih, masih nonformal. Maksudnya kalau nggak ada user

yang komplain, ya nggak terukur.

P-51 : Pro4.1.1, Pro4.1.2 Pengukuran kuantitatif ada?


Sup2 (lanjutan)


400


J-51 : Ada cuma belum pernah review. Kita monitor, cuma nggak formal. Nggak

formal yang kita kerjakan terus menerus. Kalau ada masalah baru kita

perhatikan.

P-52 : Pro4.1.2 Kita ada nggak mencatat jumlah panggilan telepon yang

berkaitan dengan masalah atau insiden.

J-52 : Kita cuma ada menyimpan jumlah tiketnya. Karena email langsung masuk

tiket.

P-53 : Pro4.2.1 Kita ada mencatat jam pengerjaan, Pak? Misalnya lembur

ketahuan?

J-53 : Kalau lembur mungkin nggak. Cuma berapa hari saja resolve-nya.

P-54 : Pro4.2.1 Kita bisa tahu permintaan yang ditutup dalam satu periode

berapa? Permintaan yang carry forward untuk periode berikutnya

berapa?

J-54 : Ada.

P-55 : Pro4.2.1 Itu bentuknya apa, Pak?

J-55 : Bentuknya report dari sistem ticketing.

P-56 : Pro4.2.1 Kalau jumlah sumber daya untuk tiap aplikasi perangkat

lunak? Misalnya Sistem Informasi Asuransi Umum sekian orang. Kita

ada spreadsheet-nya yang dijaga up to date?

J-56 : Yang di-update nggak sih. Tapi penunjukannya ada. Nggak ada surat

penunjukan. Lisan.

P-57 : Pro4.2.2 Acuan pengukuran kinerja ada?

J-57 : Belum sih.


Sup2 (lanjutan)


401


P-58 : Pro4.2.3 Kita ada menentukan target kinerja dan kualitas?

J-58 : Target kinerja ada, KPI. Kualitas ... agak susah juga menentukan kualitas.

Justru itu, mungkin belum.

P-59 : Pro5.0.1 Itu mengakhiri pertanyaan yang berkaitan dengan Maintenance

Process Performance. Berikutnya topik Maintenance Innovation and

Deployment. Kita ada proses formal untuk mendapatkan masukan

perbaikan proses, semacam formulir untuk ...

J-59 : Nggak ada. Biasanya informal dulu kan. Kalau mau perbaikan proses dari

seluruh company. Misalnya perbaikan proses penerbitan polis. Itu turun ke

kita, gimana caranya beberapa modul yang perlu diperbaiki, itu turun ke

user requirement, baru ke functional spec, baru ke pengerjaan.

P-60 : Oh, itu kalau ...

J-60 : Itu kita kategorikan lagi sebagai proyek dan sebagai request, tergantung

besarnya.

P-61 : Pro5.1.2 Bapak ada mendapatkan masukan dari misalnya Application

Development, atau misalnya meminta proposal untuk upgrade server?

J-61 : Kalau yang itu, beberapa ada meminta.

P-62 : Pro5.1.2 Itu dari Bapak inisiatifnya? Yang dari anak buah Bapak ada

inisiatif seperti itu? Kalau mau mengajukan perbaikan proses?

J-62 : Biasanya yang berkaitan dengan problem sih, misalnya hardware failure.

P-63 : Pro2.1.2, Pro5.1.2 Berarti aspek teknisnya ya?

J-63 : Iya.

P-64 : Pro5.1.2 Kalau proposal perbaikan proses dari anak buah Bapak?


Sup2 (lanjutan)


402


J-64 : Ada juga sih. Kita kan ada tim MIS. “Oh, saya banyak user yang error di

sini nih Pak. Mestinya aplikasinya begini.” Itu ada sih.

P-65 : Misalnya Bapak lagi deploy suatu innovation di proses ... perbaikan itu

Bapak ada cara evaluasi? Dari awal maksudnya, bukan nanti setelah

di-deploy? Jadi misalnya Bapak memilih innovation yang akan di-

deploy, nah indikator keberhasilan deployment-nya apa Pak?

J-65 : Iya, itu sedang di-design sekarang. Pastinya kan peningkatan kualitas dan

kuantitas yang bisa diukur. Itu kita mau ukur. Tapi belum diukur.

P-66 : Pro5.1.1, Pro5.1.3 Pengkajian innovation itu dalam bentuk formal?

Misalnya ada case study?

J-66 : Belum saya tuangkan secara formal sih, berdasarkan ikut seminar, ngobrol

sama orang. Tapi nggak dituangkan secara formal untuk review, belum.

P-67 : Pro5.0.2, Pro5.0.3, Pro5.1.1, Pro5.1.3, Pro5.2.1 Bapak ada menugaskan anak buah

Bapak untuk mencari berbagai macam cara untuk meningkatkan

kinerja proses kita?

J-67 : Secara formal belum sih. Tukar pikiran iya. Biasanya ada arahan dari saya,

ada teknologi baru, tolong dilihat. Bandingkan, secara teknologi make

sense nggak di kita? Baru panggil vendor, jadikan proyek.

P-68 : Pro5.1.3 Hasil perbandingannya ini apa, Pak?

J-68 : Dalam bentuk lisan, tapi ada beberapa yang dalam bentuk dokumen.

P-69 : Pro5.1.3 Itu dokumen diarsipkan?

J-69 : Ada sih, kalau mau dicari.


Sup2 (lanjutan)


403


P-70 : Pro5.2.2 Kalau orang mau memberi saran perbaikan proses, dicatat?

Daftar masukan perbaikan proses dari siapa saja ada? Mungkin nanti

ada review-nya. Apakah proses, layanan, teknologi, metodologi, dan

tool baru tersebut diperlakukan sebagai suatu noncritical maintenance

request?

J-70 : Belum ada untuk itu.

P-71 : Penerapan perbaikan proses ini sudah ada jadwalnya?

J-71 : Roughly.

P-72 : Sup2.0.1 Itu mengakhiri Maintenance Process Innovation and

Deployment. Yang terakhir. Sebenarnya di awal dulu saya sudah

pernah tanya. Tapi ini tetap saya masukkan di wawancara ini. Kita

sudah ada penjaminan mutu, quality assurance?

J-72 : Seperti apa ya?

P-73 : Sup2.0.1 Ide utamanya adalah, kalau proses atau prosedur diikuti,

variasinya minimal, maka kualitasnya seragam. Jadi ada nggak

mengambil sampel misalnya di ticketing, terus melihat apakah

penanganannya sudah sesuai dengan SOP?

J-73 : Secara periodik tidak. Kita melihat sewaktu mau deploy perubahan, ada

kelengkapannya nggak? Tanda tangannya, hasil meeting dengan user-nya.

Tapi secara periodik itu belum sih.

P-74 : Sup2.0.1 Kita sudah ada petugas yang memiliki kualifikasi quality

assurance?

J-74 : Secara sertifikasi nggak sih. Formal training nggak.

P-75 : Sup2.0.1 Sudah ada audit untuk quality assurance sebelumnya?


Sup2 (lanjutan)


404


J-75 : Audit belum.

P-76 : Sup2.0.1 Kita ada prosedur untuk menangani ketidaksesuaian atau

ketidakpatuhan terhadap proses, Pak?

J-76 : Belum. Kalau yang secara whole company, secara sudah ada.

P-77 : Sup2.0.1 Baik. Berarti kalau saya bertanya laporan quality assurance

berkala IT ...

J-77 : Belum.

P-78 : Kalau maintainer melihat ketidaksesuaian terhadap proses

maintenance, sudah ada prosedur, mau dilaporkan ke siapa?

J-78 : Prosedur formal belum. Jadi lapor ke saya.

P-79 : Itu mengakhiri pertanyaan ke Bapak. Kita akhiri wawancaranya Pak.

Terima kasih atas partisipasinya Pak RK.

J-79 : Sama-sama.


Sup2 (lanjutan)


405


Lampiran J. Jawaban Pertanyaan Req3


Tempat : melalui email

Narasumber : Bapak IYB (Kepala Seksi Business Analyst)


Wawancara via email ini bertujuan untuk mencari tahu apakah praktek-praktek

untuk KPA Request/Software Monitoring and Control (Req3) dilakukan di

Departemen TI.

P-1 : Req3.0.1 Apakah Departemen TI melacak atau memantau komitmen

layanan atau produknya?

J-1 : Iya.

P-2 : Req3.1.1, Evo1.2.8 Apakah secara informal? Misalnya masing-masing

maintainer melakukan pemantauan terhadap komitmen secara

sendiri-sendiri, tanpa kendali dari manajemen.

J-2 : Secara formal dilakukan, setiap aplikasi (berikut perubahannya) selalu

dilengkapi dengan guidance user bahkan training untuk menjalankannya,

hanya saja pelanggaran terhadap prosedur belum disertai sanksi.

P-3 : Req3.2.1 Apakah para maintainer diberikan tanggung jawab memantau

perangkat lunak produksi? Apakah ada jadwal dukungan di luar jam

kerja yang sudah disetujui manajemen? Apakah ada prosedur

terdokumentasi untuk dukungan antar grup (pengguna,

infrastruktur, pengembang, supplier, dan help desk)?

J-3 : Diberikan tanggung jawab iya, idealnya Business Analyst melakukan

maintenance hingga beberapa saat setelah perubahan aplikasi deploy, ada

masa transisi dengan user support sampai aplikasi benar-benar beroperasi

dan tanggung jawabnya beralih. Tidak ada jadwal dukungan di luar jam


406


kerja normal. Tidak ada prosedur yang terdokumentasi untuk dukungan

antar group tersebut.

P-4 : Req3.2.2 Apakah ada sesi review dengan pengguna untuk urusan

pemeliharaan secara berkala? Apakah komitmen pengguna untuk

urusan pemeliharaan dipastikan oleh manajer? Apakah perubahan

komitmen pengguna dilacak (tracked)?

J-4 : Review secara berkala memang tidak dilakukan, namun review pasca

perubahan aplikasi sering kali dilakukan, terutama jika masih ada gap

antara kebutuhan user dengan aplikasi yang di-deliver. Business Analyst

mempunyai kewajiban report ke manajer termasuk dalam komitmen

pengguna. Perubahan komitmen pengguna bisa dilacak menggunakan:

komunikasi via email, bug tracker, dan tiket.

P-5 : Req3.2.3 Apakah ada meeting berkala (misalnya mingguan) untuk

mengulas hasil pemantauan tingkat layanan (SLA)? Misalnya untuk

mendiskusikan nilai availability, panggilan telepon di luar jam kerja,

dan untuk permintaan yang lagi dalam proses dan yang lagi

menunggu? Apakah ada diskusi /antisipasi tentang kasus-kasus yang

tidak akan memenuhi SLA? Apakah hasil meeting

didokumentasikan?

J-5 : Tidak ada meeting berkala khususnya dalam hal SLA. Jika ada diskusi

(tidak terbatas soal SLA) BA mendokumentasikan dalam Minute of

Meeting yang diedarkan lagi ke peserta meeting untuk review ulang.

P-6 : Req3.2.4 Apakah komitmen pemeliharaan eksternal dan internal diatur,

dan diulas secara periodik dengan manajemen pemeliharaan?

Apakah jika diminta, Departemen TI bisa menunjukkan saat itu juga

status kerja pemeliharaan yang dalam proses untuk semua layanan,

permintaan pengguna, predelivery and transition, upgrade, pemulihan

bencana, dan seterusnya, dan bisa dibandingkan dengan rencana dan

Lampiran J. Jawaban Pertanyaan Req3 (lanjutan)


407


komitmen? Apakah saat diskusi, statusnya sangat berbeda antara

manajer, maintainer, dan pengguna?

J-6 : Tidak ada schedule khusus untuk pemeliharaan eksternal. Jika diperlukan,

Departemen TI bisa menunjukkan schedule internal saja, kecuali jika suatu

proses pemeliharaan termasuk penjadwalannya dilakukan bersama-sama

dengan pihak eksternal.

P-7 : Req3.2.5 Apakah rencana transisi (termasuk jadwalnya) dilacak

perubahannya, dan dilakukan tindakan korektif (corrective actions)

jika diperlukan?

J-7 : Iya.

P-8 : Req3.2.5 Apakah maintainer memiliki salinan jadwal predelivery and

transition?

J-8 : Setiap proyek yang di-handle ke depannya harus dilengkapi dengan

project plan.

P-9 : Req3.2.5 Apakah maintainer meninjau progres aktivitas mingguan atau

bulanannya?

J-9 : Iya.

P-10 : Req3.2.5 Apakah maintainer berpartisipasi dalam meeting bulanan untuk

komunikasi kemajuan prosesnya (telat, on track, on early)?

J-10 : Iya.

P-11 : Req3.2.5 Apakah maintainer negosiasi rencana tindakan (yang disepakati

bersama) untuk tindakan perbaikan masalah?

J-11 : Sering kali dilakukan.



408


P-12 : Req3.2.5 Apakah maintainer meminta informasi tentang

perbaikan/perubahan terakhir terhadap kegiatan predelivery and

transition?

J-12 : Selalu dilakukan demikian.

P-13 : Req3.2.6 Jika ada perubahan komitmen, apakah maintainer memastikan

kesepakatan semua pemangku kepentingan?

J-13 : Iya.



Strategi Software Process Improvement: Studi Kasus PT....

Documents

Transcript of Strategi Software Process Improvement: Studi Kasus PT....