UNIVERSITAS INDONESIA

UNIVERSITAS INDONESIA

PEMERINGKATAN KUALITAS MIDDLEWARE ENTERPRISE SERVICE BUS MENGGUNAKAN QUALITY FUNCTION DEPLOYMENT DAN ANALYTICAL HIERARCHY PROCESS: STUDI KASUS BPJS KESEHATAN

KARYA AKHIR

SANDI JUNIAR 1406522456

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JULI 2016

Pemeringkatan kualitas ..., Sandi Juniar, Fasilkom UI, 2016


UNIVERSITAS INDONESIA

PEMERINGKATAN KUALITAS MIDDLEWARE ENTERPRISE SERVICE BUS MENGGUNAKAN QUALITY FUNCTION DEPLOYMENT DAN ANALYTICAL HIERARCHY PROCESS: STUDI KASUS BPJS KESEHATAN

KARYA AKHIR Diajukan sebagai salah satu syarat untuk memperoleh gelar Magister Teknologi Informasi

SANDI JUNIAR 1406522456

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI JAKARTA JULI 2016


HALAMAN PERNYATAAN ORISINALITAS

ii


HALAMAN PENGESAHAN

iii


KATA PENGANTAR

Alhamdulillah segala puji dan syukur penulis panjatkan kehadirat Allah SWT yang telah melimpahkan rahmat-Nya, serta shalawat dan salam juga penulis sampaikan kepada nabi besar kita Muhammad SAW beserta keluarga dan para sahabat, karenaNya karya Akhir yang berjudul Pemeringkatan Kualitas Middleware Enterprise Service Bus menggunakan Quality Function Deployment dan Analytical Hierarchy Process: Studi Kasus BPJS Kesehatan ini dapat tersusun sebagai salah satu syarat dalam memperoleh gelar Magister Teknologi Informasi di Universitas Indonesia. Dalam kesempatan ini penulis menyampaikan rasa terima kasih kepada : 1. Bapak Dr. Achmad Nizar Hidayanto, S.Kom., M.Kom., selaku dosen pembimbing yang telah banyak membantu menyediakan waktunya dalam memberikan bimbingan hingga tersusunnya Karya Akhir ini. 2. Ibu Yova Ruldeviyani S.Kom., M.Kom dan Bapak Ir. Dana Indra Sensuse M.LIS., Ph.D selaku Dewan Penguji Karya Akhir. 3. Nurmania Ramdhani istri tercinta, orang tua, mertua, dan keluarga besar, yang telah memberikan semangat, dukungan, do’a, dan pengertiannya. 4. Dosen, sekretariat, dan teman-teman pada program studi Magister Teknologi Informasi Universitas Indonesia dan rekan kerja pada Direktorat TI BPJS Kesehatan yang telah membantu secara langsung ataupun tidak langsung dalam melakukan penelitian. 5. Semua pihak yang tidak dapat disebutkan satu per satu yang telah membantu atas tersusunnya Karya Akhir ini. Penulis membuka diri terhadap kritik dan saran untuk membangun dari berbagai pihak demi kebaikan penulisan di waktu mendatang. Jakarta, 6 Juni 2016

Penulis iv


HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ILIMAH UNTUK KEPENTINGAN AKADEMIS

v


ABSTRAK

Nama Program Studi Judul

: Sandi Juniar : Magister Teknologi Informasi : Pemeringkatan Kualitas Middleware Enterprise Service Bus menggunakan Quality Function Deployment dan Analytical Hierarchy Process: Studi Kasus BPJS Kesehatan

Tujuan dalam suatu organisasi dalam mengembangkan sistem informasi adalah ketersediaan dan aksesibilitas informasi yang dapat tercapai melalui sistem informasi yang terintegrasi. Teknologi yang dikenal dapat melakukan integrasi, menawarkan konektivitas, dan memiliki interoperabilitas tinggi adalah middleware. Teknologi middleware yang memanfaatkan konsep Service Oriented Architectures (SOA) adalah web service, yang kemudian berevolusi menjadi suatu teknologi baru bernama Enterprise Service Bus (ESB). Saat ini, terdapat berbagai produk middleware ESB yang menawarkan keunggulannya masing-masing, sehingga diperlukan suatu metode dalam memilih produk middleware ESB yang berkualitas. Metode yang menyediakan solusi, berorientasi terhadap tujuan, fleksibel, dan fokus terhadap kebutuhan pengguna adalah Quality Function Deployment (QFD), dan metode yang dapat digunakan dalam membantu pengambilan keputusan guna menetapkan pilihan, menentukan peringkat, dan pemilahan terhadap alternatifalternatif pilihan yang ada berdasarkan kriteria-kriteria penentu keputusan adalah Multi Criteria Decision Analysis (MCDA). Salah satu metode yang menggunakan pendekatan MCDA adalah Analytic Hierarchy Process (AHP). Penelitian ini menghasilkan suatu model pemeringkatan kualitas produk middleware ESB dengan menggunakan metode Analytic Hierarchy Proces (AHP) yang diintegrasikan dengan metode Quality Function Deployment (QFD) berdasarkan kriteria model kualitas SOAQM. Implementasi dari model tersebut menghasilkan peringkat produk middleware ESB. WebMethods adalah produk middleware ESB yang mendapatkan peringkat pertama diikuti oleh IIB, Oracle SOA Suite, dan BizTalk. Penerapan metode pemeringkatan yang telah dilakukan menjadi masukan dalam proses pembelajaran dan panduan bagi BPJS Kesehatan dalam kaitannya dengan pemilihan perangkat lunak yang paling tepat dengan kebutuhan organisasi pada masa mendatang. Kata Kunci: Analytic Hierarchy Proces (AHP), Middleware, Enterprise Service Bus (ESB), Multi Criteria Decision Analysis (MCDA), Quality Function Deployment (QFD), Service Oriented Architecture (SOA), Model Kualitas Perangkat Lunak.

vi

Universitas Indonesia


ABSTRACT

Name Study Program Title

: Sandi Juniar : Magister of Information Technology : Prioritizing Enterprise Service Bus Middleware Quality using Quality Function Deployment and Analytical Hierarchy Process: A Case Study in Healthcare Social Security Agency

The goal of developing an information systems in an organization are for the availability and accessibility of information that can be achieved through integrated information systems. The technology that has function to integrating, offering connectivity, and has a high interoperability known as middleware. The middleware technology which utilizes the concept of Service Oriented Architectures (SOA) known as web service, which evolved into a new technology called Enterprise Service Bus (ESB). Currently, there are various ESB middleware products that offering the advantages of each, so we must adopt a method for choosing the right ESB middleware product. The method that provides a solution, oriented to the organization goals, flexible, and focused to the needs of users, known as Quality Function Deployment (QFD), then, a method that can be used to help decision makers in order to making and prioritizing a selection, and sorting for the available alternatives based on criteria known as Multi Criteria Decision Analysis (MCDA). A method that uses MCDA approach is the Analytic Hierarchy Process (AHP). This research resulted an ESB middleware product quality model using Analytic Hierarchy Proces (AHP) integrated with the Quality Function Deployment (QFD) based on the criteria of quality models SOAQM. The application of the model provide a priority quality of ESB middleware products. WebMethods ESB is the middleware product that get the first ranked, followed by IIB, Oracle SOA Suite and BizTalk. The implementation of the method can become input for the learning process and give guidance to BPJS Kesehatan in relation to the selection of the most appropriate software that best suits to the needs of the organization in the future. Keywords: Analytic Hierarchy Proces (AHP), Middleware, Enterprise Service Bus (ESB), Multi Criteria Decision Analysis (MCDA), Quality Function Deployment (QFD), Service Oriented Architecture (SOA), Software Quality Model.

vii



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 GAMBAR ............................................................................................. x DAFTAR TABEL ................................................................................................ xi BAB 1

PENDAHULUAN ............................................................................... 1

1.1 1.2 1.3 1.4 1.5 1.6 BAB 2

Latar Belakang.......................................................................................... 1 Identifikasi Masalah ................................................................................. 3 Pertanyaan Penelitian ............................................................................. 10 Tujuan dan Manfaat Penelitian ............................................................... 11 Batasan Penelitian .................................................................................. 12 Sistematika Penulisan ............................................................................. 13 TINJAUAN PUSTAKA ................................................................... 15

2.1 Arsitektur Aplikasi ................................................................................. 15 2.2 Integrasi Arsitektur ................................................................................. 16 2.3 Infrastruktur Teknologi Informasi .......................................................... 18 2.4 Service Oriented Architecture (SOA) .................................................... 19 2.5 Middleware ............................................................................................. 21 2.6 Web service ............................................................................................. 23 2.7 Enterprise Service Bus (ESB) ................................................................ 24 2.8 Model Kualitas Perangkat Lunak ........................................................... 27 2.8.1 McCall ............................................................................................. 28 2.8.2 Boehm ............................................................................................. 29 2.8.3 FURPS ............................................................................................ 30 2.8.4 ISO 9126 ......................................................................................... 30 2.8.5 Dromey............................................................................................ 33 2.8.6 ISO 25010 ....................................................................................... 34 2.9 Quality Function Deployment (QFD)..................................................... 41 2.10 Multi Criteria Decision Analysis (MCDA) ............................................ 42 2.11 Analytic Hierarchy Process (AHP) ........................................................ 43 2.12 Proof of Concept (PoC) .......................................................................... 46 viii



2.13 Penelitian Terdahulu ............................................................................... 47 2.14 Kerangka Pemikiran ............................................................................... 59 BAB 3 METODOLOGI PENELITIAN...................................................... 64 3.1 3.2 3.3 3.4 3.5 BAB 4

Rancangan Penelitian ............................................................................. 64 Perancangan Model HoQ QFD dan Hirarki AHP .................................. 67 Metode Pengumpulan Data .................................................................... 77 Instrumen Pengumpulan Data ................................................................ 79 Uji Rasio Konsistensi Data..................................................................... 84 PROFIL ORGANISASI ................................................................... 86

4.1 4.2 4.3 4.4 BAB 5

Profil Organisasi ..................................................................................... 86 Visi dan Misi Organisasi ........................................................................ 86 Struktur Organisasi ................................................................................. 87 Rencana Strategis Teknologi Informasi ................................................. 89 ANALISIS DAN PEMBAHASAN .................................................. 90

5.1 Analisis model QFD ............................................................................... 90 5.1.1 Penentuan ‘WHATs’ pada HoQ 1 .................................................. 90 5.1.2 Penentuan ‘Priority of WHATs’ pada HoQ 1 ................................. 92 5.1.3 Penentuan ‘HOWs’ pada HoQ 1 ..................................................... 95 5.1.4 Penentuan ‘Relationship Matrix’ pada HoQ 1 ................................ 96 5.1.5 Penentuan ‘Weight of HOWs’ pada HoQ 1 .................................... 99 5.1.6 Pendaftaran ‘WHATs’ pada HoQ 2 .............................................. 101 5.1.7 Penentuan ‘Priority of WHATs’ pada HoQ 2 ............................... 102 5.1.8 Pendaftaran ‘HOWs’ pada HoQ 2................................................. 103 5.1.9 Penentuan ‘Relationship Matrix’ pada HoQ 2 .............................. 104 5.1.10 Penentuan ‘Weight of HOWs’ pada HoQ 2 .................................. 106 5.2 Analisis Hirarki AHP ........................................................................... 107 5.2.1 Pembobotan kriteria kualitas perangkat lunak .............................. 107 5.2.2 Penilaian terhadap alternatif .......................................................... 114 5.2.3 Pembobotan alternatif terhadap kriteria ........................................ 115 5.3 Analisis Data ........................................................................................ 136 5.4 Hasil Akhir Pemeringkatan .................................................................. 141 BAB 6 KESIMPULAN DAN SARAN....................................................... 142 6.1 Kesimpulan ........................................................................................... 142 6.2 Saran ..................................................................................................... 143 DAFTAR PUSTAKA ........................................................................................ 145 LAMPIRAN ....................................................................................................... 151

ix



DAFTAR GAMBAR

Gambar 1.1 Diagram Ishikawa Analisis Sumber Masalah ..................................... 7 Gambar 2.1 Lapisan Komponen Infrastruktur ...................................................... 18 Gambar 2.2 Relasi Layanan Infrastruktur Terintegrasi......................................... 19 Gambar 2.3 Interaksi Antar Komponen SOA ....................................................... 21 Gambar 2.4 Perkembangan Teknologi Middleware ............................................. 21 Gambar 2.5 Arsitektur Web Service ...................................................................... 23 Gambar 2.6 Contoh Arsitektur menggunakan ESB .............................................. 25 Gambar 2.7 Model Kualitas Mccall ...................................................................... 28 Gambar 2.8 Model Kualitas Boehm...................................................................... 29 Gambar 2.9 Model Kualitas FURPS ..................................................................... 30 Gambar 2.10 Model Kualitas Internal dan Eksternal ISO 9126 ........................... 32 Gambar 2.11 Model Kualitas dalam Penggunaan dari ISO 9126 ......................... 32 Gambar 2.12 Model Kualitas Dromey .................................................................. 33 Gambar 2.13 Framework SQuaRE ....................................................................... 34 Gambar 2.14 Model Kualitas Perangkat Lunak ISO 25010 ................................. 35 Gambar 2.15 Model Kualitas SOAQM................................................................. 37 Gambar 2.16 Elemen HoQ .................................................................................... 42 Gambar 2.17 Pengelompokan MCDA .................................................................. 43 Gambar 2.18 Struktur Hirarki dari AHP ............................................................... 44 Gambar 2.19 Format Pairwise Comparison ......................................................... 45 Gambar 2.20 Indeks Konsistensi Acak ................................................................. 46 Gambar 2.21 Hirarki pemeringkatan ESB untuk sistem C4I ................................ 48 Gambar 2.22 Hirarki AHP Qualified Analysis ESB ............................................. 48 Gambar 2.23 Model Pemeringkatan Web Service................................................. 50 Gambar 2.24 Metodologi QFD AHP Pemilihan supplier ..................................... 51 Gambar 2.25 HoQ berdasarkan Kebutuhan dan Karakteristik Software .............. 52 Gambar 2.26 HoQ berdasarkan Karakteristik dan Fitur Software ........................ 53 Gambar 2.27 Kerangka Pemikiran Penelitian ....................................................... 62 Gambar 3.1 Metodologi Penelitian ....................................................................... 67 Gambar 3.2 Model Pemeringkatan Produk Middleware ESB .............................. 70 Gambar 3.3 Tahapan Model Pemeringkatan Produk Middleware ESB ............... 71

x



DAFTAR TABEL

Tabel 1.1 Progres Pengembangan Integrasi SIM dengan Rumah Sakit.................. 5 Tabel 2.1 Perbandingan Model Kualitas ............................................................... 35 Tabel 2.2 Analisis antar Penelitian Terdahulu ...................................................... 56 Tabel 3.1 Daftar Faktor Teknologi........................................................................ 68 Tabel 3.2 Daftar Kriteria Kualitas Perangkat Lunak ............................................ 68 Tabel 3.3 HoQ Relasi Kebutuhan Non-fungsional dan Faktor Teknologi............ 73 Tabel 3.4 Nilai Keterhubungan antar ‘WHATs’ dan ‘HOWs’ QFD .................... 73 Tabel 3.5 HoQ Relasi Faktor Teknologi dan Kriteria Kualitas ............................ 75 Tabel 3.6 Daftar Pertanyaan Kualitas Perangkat Lunak ....................................... 79 Tabel 3.7 Skala Perbandingan antar Kriteria ........................................................ 82 Tabel 3.8 Daftar Penilaian ESB sesuai Service Performance Report ................... 84 Tabel 5.1 Daftar Kebutuhan Non-fungsional dalam ‘WHATs’ HoQ 1 ................ 91 Tabel 5.2 Matriks Perbandingan dari ‘WHATs’ ................................................... 93 Tabel 5.3 Normalisasi dari Matriks Perbandingan ‘WHATs’ .............................. 94 Tabel 5.4 Daftar ‘HOWs’ pada HoQ 1 ................................................................. 95 Tabel 5.5 ‘Relationship Matrix’ pada HoQ 1........................................................ 97 Tabel 5.6 Perhitungan ‘Weight of HOWs’ pada HoQ 1 ..................................... 100 Tabel 5.7 Daftar Peserta FGD penyusunan HoQ 2 ............................................. 101 Tabel 5.8 Daftar ‘Priority of WHATs’ pada HoQ 2 ........................................... 102 Tabel 5.9 ‘HOWs’ pada HoQ 2........................................................................... 103 Tabel 5.10 ‘Relationship Matrix’ pada HoQ 2.................................................... 105 Tabel 5.11 Perhitungan ‘Weight of HOWs’ pada HoQ 2 ................................... 106 Tabel 5.12 Hasil Pembobotan Kriteria Kualitas Perangkat Lunak ..................... 107 Tabel 5.13 Hasil Pembobotan Subkriteria Functional Suitability ...................... 108 Tabel 5.14 Hasil Pembobotan Subkriteria Performance Efficiency.................... 109 Tabel 5.15 Hasil Pembobotan Subkriteria Compatibility ................................... 110 Tabel 5.16 Hasil Pembobotan Subkriteria Usability ........................................... 110 Tabel 5.17 Hasil Pembobotan Subkriteria Reliability ......................................... 111 Tabel 5.18 Hasil Pembobotan Subkriteria Security ............................................ 112 Tabel 5.19 Hasil Pembobotan Subkriteria Maintainability ................................ 113 Tabel 5.20 Hasil Pembobotan Subkriteria Portability ........................................ 113 Tabel 5.21 Alternatif Produk middleware ESB .................................................. 114 Tabel 5.22 Hasil Performance Testing ESB ....................................................... 114 Tabel 5.23 Penilaian Kriteria Functional Completeness..................................... 115 Tabel 5.24 Pembobotan Subkriteria Functional Completeness .......................... 116 Tabel 5.25 Pembobotan Subkriteria Functional Correctness ............................. 117 Tabel 5.26 Pembobotan Subkriteria Functional Appropriateness ...................... 118 Tabel 5.27 Pembobotan Subkriteria Time Behaviour ......................................... 118 Tabel 5.28 Kebutuhan Hardware Minimum....................................................... 119 xi Universitas Indonesia


Tabel 5.29 Pembobotan Subkriteria Resource Utilization .................................. 119 Tabel 5.30 Pembobotan Subkriteria Co-existence .............................................. 120 Tabel 5.31 Pembobotan Subkriteria Interoperability.......................................... 121 Tabel 5.32 Penilaian Subkriteria Appropriateness Recognizability .................... 121 Tabel 5.33 Pembobotan Subkriteria Appropriateness Recognizability .............. 122 Tabel 5.34 Pembobotan Subkriteria Learnability ............................................... 123 Tabel 5.35 Pembobotan Subkriteria Operability ................................................ 124 Tabel 5.36 Pembobotan Subkriteria User Error Protection ............................... 124 Tabel 5.37 Pembobotan Subkriteria Maturity ..................................................... 125 Tabel 5.38 Pembobotan Subkriteria Availability ................................................ 126 Tabel 5.39 Pembobotan Subkriteria Fault Tolerance ......................................... 127 Tabel 5.40 Pembobotan Subkriteria Recoverability............................................ 127 Tabel 5.41 Pembobotan Subkriteria Confidentiality ........................................... 128 Tabel 5.42 Pembobotan Subkriteria Integrity ..................................................... 129 Tabel 5.43 Pembobotan Subkriteria Accountability............................................ 129 Tabel 5.44 Pembobotan Subkriteria Authenticity................................................ 130 Tabel 5.45 Pembobotan Subkriteria Non-repudiation ........................................ 130 Tabel 5.46 Pembobotan Subkriteria Modularity ................................................. 131 Tabel 5.47 Pembobotan Subkriteria Reusability ................................................. 132 Tabel 5.48 Pembobotan Subkriteria Modifiability .............................................. 132 Tabel 5.49 Pembobotan Subkriteria Testability .................................................. 133 Tabel 5.50 Pembobotan Subkriteria Analyzability .............................................. 134 Tabel 5.51 Pembobotan Subkriteria Adaptability ............................................... 135 Tabel 5.52 Pembobotan Subkriteria Installability .............................................. 135 Tabel 5.53 Pembobotan Subkriteria Replaceability ............................................ 136 Tabel 5.54 Nilai Pembobotan setiap Kriteria ...................................................... 137 Tabel 5.55 Nilai setiap Alternatif berdasarkan Kriteria ...................................... 138 Tabel 5.56 Pembobotan Alternatif berdasarkan Kriteria .................................... 139 Tabel 5.57 Normalisasi penilaian Alternatif ....................................................... 140 Tabel 5.58 Hasil Pemeringkatan Produk Middleware ESB ................................ 141

xii



BAB 1 PENDAHULUAN

Bab ini diawali dengan penjabaran latar belakang penelitian. Masalah dan pertanyaan penelitian dirumuskan berdasarkan latar belakang tersebut. Selanjutnya rumusan masalah akan dijadikan pertanyaan penelitian guna dijawab dalam penelitian. Selain itu, dijelaskan mengenai tujuan, manfaat, dan batasan penelitian untuk memberi arah dan ruang lingkup penelitian. Di akhir bab dijelaskan juga sistematika penulisan. 1.1

Latar Belakang

Tujuan yang ingin dicapai oleh suatu organisasi dalam mengembangkan sistem informasinya adalah ketersediaan dan aksesibilitas informasi dalam mendukung kebutuhan

organisasi.

Berbagai

sistem

informasi

dikembangkan

sesuai

keperluannya guna mendukung kelancaran operasional organisasi dalam mencapai tujuan tersebut. Untuk mencapai ketersediaan dan aksesibilitas informasi yang tinggi, diperlukan sistem informasi yang terintegrasi dalam internal organisasi maupun antar organisasi untuk keperluan business-to-business (Juric et al., 2007). Berbagai teknologi dan konsep diterapkan untuk memenuhi keperluan pengembangan sistem informasi yang terintegrasi dalam suatu organisasi. Juric et al. (2007) menyatakan bahwa teknologi yang saat ini dikenal untuk melakukan integrasi, menawarkan konektivitas, dan interoperabilitas terhadap sistem informasi adalah middleware. Lebih lanjut, menurutnya arsitektur dan prinsip yang menjanjikan penyederhanaan proses integrasi, membuat integrasi lebih efisien, dan mendukung integrasi proses bisnis sepenuhnya adalah Service Oriented Architectures (SOA), dan teknologi middleware yang memanfaatkan konsep SOA adalah web service, yang kemudian berevolusi menjadi suatu teknologi baru bernama Enterprise Service Bus (ESB).

Saat ini, terdapat berbagai produk

middleware ESB di pasaran yang mempunyai kemiripan fungsi dan menawarkan keunggulannya masing-masing. Menyadari akan hal tersebut, diperlukan suatu metode dalam mempertimbangkan pemilihan produk middleware ESB yang tepat 1



2

dan sesuai kebutuhan pengguna dalam suatu organisasi. Dalam rangka memperoleh keberhasilan dalam mengimplementasikan sistem informasi, sangat penting untuk menentukan persyaratan kualitas dalam memilih perangkat lunak yang paling sesuai dengan kebutuhan pengguna (Esaki, 2013). Untuk itu, perlu memerhatikan kualitas perangkat lunak dalam memilih produk middleware ESB. Terdapat beberapa model yang dapat digunakan saat ini untuk menilai kualitas perangkat lunak, antara lain, McCall, Boehm, FURPS, ISO 9126, ISO 25010, dan lainnya. Model-model kualitas tersebut menawarkan kriteria-kriteria penting dalam penilaian perangkat lunak. Siddiqui, Abdullah, & Khan (2011), Siddiqui et al. (2011), Jiménez, Carreras, & Skarmeta (2010), Kruessmann et al. (2009), Astrova, Koschel, & Kruessmann (2010), Ahuja & Patel (2011), Alghamdi, Ahmad, & Nasir (2010), dan Alghamdi et al. (2010) menawarkan beberapa persyaratan kualitas perangkat

lunak

yang

dapat

digunakan

pada

suatu

organisasi

dalam

mempertimbangkan pemilihan produk middleware ESB dari beberapa alternatif produk yang tersedia. Franca & Soares (2015) menawarkan sebuah model kualitas yang merupakan pengembangan dari ISO 25010 yang spesifik diterapkan dalam konsep SOA yang diberi nama SOAQM (Service Oriented Architecture Quality Model). Seiring dinamika bisnis organisasi yang berubah cepat, organisasi harus memahami kebutuhan pengguna produk untuk mencapai keunggulan kompetitif dan meningkatkan performa organisasi (Roghanian & Alipour, 2014). Metode yang menyediakan solusi, berorientasi terhadap tujuan, fleksibel, dan fokus terhadap kebutuhan pengguna adalah Quality Function Deployment (QFD) (Herzwurm & Schockert, 2003). Dalam pengambilan keputusan terhadap pemilihan dari alternatif-alternatif pilihan yang ada, perlu ditentukan prioritas kepentingan dari alternatif-alternatif tersebut (Saaty, 2008). Metode yang dapat digunakan dalam membantu pengambilan keputusan guna menetapkan pilihan, menentukan peringkat, dan pemilahan terhadap alternatif-alternatif pilihan yang ada berdasarkan kriteria-kriteria penentu keputusan adalah Multi Criteria Decision Analysis (MCDA) (Whaiduzzaman et al., 2014). Salah satu metode yang menggunakan pendekatan MCDA dalam menetapkan pilihan dan peringkat adalah Analytic Hierarchy Process (AHP). Siddiqui, Abdullah, & Khan (2011), Negi dan Chandra Universitas Indonesia


3

(Negi & Chandra, 2014), dan Alghamdi, Ahmad, & Nasir (2010) menyebutkan bahwa metode AHP dapat dipergunakan dalam melakukan pemeringkatan web service ataupun ESB berdasarkan kriteria-kriteria tertentu yang dibutuhkan dalam organisasi. Melalui penelitian ini akan dilakukan analisis untuk mengetahui peringkat produk middleware ESB berdasarkan kualitas yang sesuai kebutuhan pemangku kepentingan di BPJS Kesehatan. Analisis tersebut menggunakan metode QFD yang diintegrasikan dengan metode AHP guna mendapatkan hasil yang komprehensif dalam pemeringkatan produk middleware ESB. Konsep integrasi metode QFD dan AHP ini pernah dilakukan oleh Rajesh dan Malliga (Rajesh & Malliga, 2013). 1.2

Identifikasi Masalah

Berdasarkan Peta Jaminan Kesehatan Nasional 2012-2019 (Kementrian Kesehatan RI, 2013), Pemerintah mengharapkan pengembangan Sistem Informasi Manajemen (SIM) BPJS Kesehatan yang terinterkoneksi dengan berbagai lembaga dan instansi terkait. Harapan tersebut ditegaskan kembali dalam Peta Strategi BPJS Kesehatan 2014-2019 (BPJS Kesehatan, 2014), yang menyatakan bahwa strategi Teknologi Informasi dan Komunikasi (TIK) BPJS Kesehatan dalam mendukung strategi utama BPJS Kesehatan diantaranya adalah mengembangkan metode dan model pengumpulan iuran yang cost-effective dengan didukung integrated online transaction dan memastikan kelengkapan dan keaktualan data masterfile peserta dengan didukung implementasi Electronic Data Interchange (EDI) dengan instansi terkait. Selain itu, salah satu dari Indikator Kinerja Utama (IKU) fungsi organisasi yang tersirat dalam Peta Strategi BPJS Kesehatan 2014-2019 adalah otomasi proses bisnis, menyempurnakan sistem pelaporan akuntansi yang terintegrasi, dan membangun sistem jaringan komunikasi terintegrasi dengan Fasilitas Kesehatan (Faskes) yang bekerjasama dengan BPJS Kesehatan. Direktorat Teknologi dan Informasi (TI) sebagai Direktorat yang bertanggung jawab dalam mendukung operasional TIK di BPJS Kesehatan, telah berupaya menerjemahkan harapan pemerintah dan organisasi tersebut dalam bentuk pengembangan dan implementasi integrasi SIM lintas satuan kerja dengan Universitas Indonesia


4

menggunakan teknologi middleware dan mengadopsi konsep SOA, yaitu dengan mengimplementasikan teknologi web service. Pengembangan SIM di BPJS Kesehatan dengan menggunakan teknologi middleware melalui penerapan web service diharapkan dapat meningkatkan kualitas produk maupun layanan dari Direktorat TI untuk mendukung kinerja organisasi dalam mencapai tujuannya. Namun, pada kenyataannya diperoleh informasi

bahwa

masih

terdapat

permasalahan

yang

menggambarkan

pengembangan dan implementasi SIM menggunakan teknologi web service pada BPJS Kesehatan belum optimal dalam mendukung kelancaran upaya-upaya pelayanan kepada peserta dan operasionalisasi proses bisnis BPJS Kesehatan. Hal tersebut diperoleh melalui observasi kondisi nyata di lapangan terkait pengembangan SIM di lingkungan Direktorat TI. Observasi tersebut dilakukan terhadap dokumen korespondensi lintas unit kerja di BPJS Kesehatan, temuan IT Audit sebagai dukungan untuk General Audit terhadap BPJS Kesehatan, laporan manajemen Direktorat TI BPJS Kesehatan, dan wawancara terhadap berbagai pihak di lingkungan Direktorat TI BPJS Kesehatan. Permasalahan pertama yang dapat teridentifikasi adalah masih sedikitnya pencapaian integrasi SIM dengan rumah sakit yang bekerjasama dengan BPJS Kesehatan sebagai penyedia layanan kesehatan untuk peserta BPJS Kesehatan. Progres pengembangan integrasi dengan rumah sakit dianggap masih rendah jika dibandingkan dengan banyaknya rumah sakit yang bekerjasama dengan BPJS Kesehatan diseluruh Divisi Regional. Dengan banyaknya rumah sakit yang belum dapat terkoneksi dengan web service yang disediakan oleh BPJS Kesehatan, mengakibatkan pencatatan data pendaftaran peserta di loket rumah sakit masih dilakukan pada dua sistem yang berbeda, yaitu pada sistem rumah sakit sendiri dan sistem BPJS Kesehatan, sehingga berdampak terhadap penumpukan antrean pasien pada loket pendaftaran di rumah sakit. Hal tersebut terjadi juga di Faskes Tingkat Pertama (FKTP), seperti di Puskesmas, Klinik, dan Balai Pengobatan (BP). Penilaian tersebut didukung oleh hasil wawancara dengan Kepala Departemen Perencanaan TI Grup SPKTI, terkait masih rendahnya pencapaian integrasi SIM dengan mengadopsi SOA melalui teknologi web service. Tabel 1.1 menyajikan Universitas Indonesia


5

progres pengembangan integrasi SIM BPJS Kesehatan dengan rumah sakit dan FKTP. Tabel 1.1 Progres Pengembangan Integrasi SIM dengan Rumah Sakit Rumah sakit No

Divisi Regional

Jumlah

Jumlah

Rumah

Integrasi

Sakit

SIM

FKTP Jumlah FKTP

Jumlah Integrasi SIM

1

I

Medan

178

9

1.444

0

2

II

Pekanbaru

115

31

1.427

0

3

III

Pelambang

77

4

1.033

0

4

IV

DKI Jakarta

216

41

1.360

9

5

V

Bandung

143

27

1.818

234

6

VI

Semarang

288

91

318

140

7

VII

Surabaya

213

45

2.267

0

8

VIII

Balikpapan

83

13

1.248

1

9

IX

Makasar

128

5

1.584

0

10

X

Menado

78

1

981

0

11

XI

Bali

86

10

1.371

6

12

XII

Jayapura

38

1

707

0

13

XIII

Tangerang

89

7

1.504

11

1.732

285

17.062

401

Total

Sumber: Laporan Manajemen Grup SKPTI BPJS Kesehatan Tahun 2015, telah diolah kembali

Permasalahan lainnya yang muncul yaitu banyaknya keluhan dari unit kerja internal BPJS Kesehatan lainnya mengenai lambatnya performa sistem dan sering terjadinya kegagalan transaksi pada sistem yang sudah terintegrasi. Keluhankeluhan tersebut ditemukan pada dokumen korespondensi antar unit kerja di BPJS Kesehatan. Hal tersebut diakui oleh Kepala Departemen Perencanaan TI yang diperoleh melalui proses wawancara, dimana kondisi tersebut menggambarkan bahwa pengembangan sistem informasi di BPJS Kesehatan belum optimal dan belum sesuai harapan organisasi, karena masih banyak permasalahan yang dihadapi Direktorat TI BPJS Kesehatan. Juric et al. (2007) mengungkapkan bahwa terdapat Universitas Indonesia


6

permasalahan yang sering dihadapi organisasi dalam mengintegrasikan sistem informasinya. Permasalahan-permasahan tersebut antara lain: 1. Perbedaan tipe dan produk Database Management System (DBMS). 2. Perbedaan solusi middleware yang digunakan sistem dalam berkomunikasi. 3. Perbedaan pengelolaan keamanan middleware. 4. Perbedaan konsep dalam berbagi data. 5. Penggunaan konsep dan format pertukaran data elektronik, model transmisi informasi, dan bahasa pemograman yang berbeda. Permasalahan-permasalahan yang diungkapkan Juric et al. (2007) tersebut, dialami juga oleh Direktorat TI terkait pengembangan dan pemanfaatan teknologi web service dalam menunjang integrasi SIM di BPJS Kesehatan. Permasalahanpermasalahan tersebut antara lain: 1. Terdapat pekerjaan dan waktu tambahan bagi pengembang sistem informasi BPJS Kesehatan untuk mengembangkan web service tersendiri untuk setiap channel penyedia pelayanan kesehatan dan agen pembayaran iuran peserta, serta pengelolaan pemutakhiran dan keamanan masing-masing web service. 2. Pengembangan dan penggunaan web service yang spesifik untuk setiap channel pembayaran iuran menyebabkan kemampuan dan kecepatan BPJS Kesehatan dalam melakukan kerjasama penerimaan iuran dengan bank atau lembaga lain menjadi terbatas dan kurang fleksibel. Kondisi tersebut menyebabkan terbatasnya jumlah lokasi tempat peserta dapat melakukan pembayaran iuran. 3. Memerlukan waktu yang lama dalam pengembangan dan implementasi sistem jika terdapat user requirment sistem baru atau perubahan kebijakan pada proses bisnis internal BPJS Kesehatan dan instansi eksternal. 4. Kemampuan interoperability yang terbatas dalam mengintegrasikan dengan legacy system yang dimiliki pihak eksternal, seperti rumah sakit. 5. Keterbatasan fitur yang dimiliki teknologi web service. 6. Skalabilitas teknologi web service yang dikembangkan belum mampu dalam penyesuaiaan dengan tingkat beban yang ditopang, 7. Kinerja sistem yang lambat dan sering terjadi kegagalan transaksi. Universitas Indonesia


7

8. Infrastruktur TI belum cukup adaptif dalam mendukung layanan TI. 9. Terdapat ketidaksesuaian antara protokol komunikasi dan format pesan yang digunakan oleh pengguna layanan. Selain permasalahan-permasalahan yang telah disebutkan, terdapat management letter dari Kantor Akuntan Publik (KAP) dan temuan pemeriksaan dari Otoritas Jasa

Keuangan

(OJK)

yang

menyebutkan

bahwa

pengelolaan

Sistem

Informasi/Teknologi Informasi (SI/TI) di BPJS Kesehatan belum optimal mendukung layanan prima kepada peserta. Management letter dan temuan pemeriksaan tersebut menyarankan pengkajian dan peningkatan teknologi middleware untuk pengoptimalan integrasi SIM, terutama dengan pihak eksternal BPJS Kesehatan. Dari analisis kondisi permasalahan yang terjadi pada BPJS Kesehatan tersebut di atas, terlihat bahwa pengembangan integrasi SIM yang dikelola Direktorat TI BPJS Kesehatan belum optimal dalam mendukung harapan pemerintah dan organisasi. Untuk memetakan sumber masalah berdasarkan masalah-masalah yang ditemukan, maka dilakukan analisis dengan menggunakan diagram Ishikawa (diagram tulang ikan). Gambar 1.1 menunjukkan diagram Ishikawa untuk mengidentifikasi potensi penyebab terhadap permasalahan dari integrasi SIM yang belum optimal yang dibagi menjadi 5 M’s, yaitu machine ‘infrastruktur’, man ‘manusia’, milieu ‘lingkungan’, method ‘metode’, material ‘informasi’ (Parkash, Kumar, & Rajoria, 2013).

Gambar 1.1 Diagram Ishikawa Analisis Sumber Masalah Universitas Indonesia


8

Berdasarkan diagram Ishikawa tersebut, berikut dijabarkan penyebab-penyebab masalah tersebut. 1. Infrastruktur a. Format Electronic Data Interchange (EDI) tidak seragam. Bermacam format pertukaran data secara elektronik dengan pihak instansi eksternal BPJS Kesehatan menyulitkan pengerjaan proyek pengembangan SIM terkait integrasi antar SIM. b. Infrastruktur SOA yang tidak adaptif. Infrastruktur SI/TI saat ini belum cukup adaptif dalam mendukung perubahan bisnis. Selain itu, komponenkomponen dari infrastruktur TI yang ada saat ini tidak dapat dimanfaatkan, diintegrasikan, dan digunakan kembali oleh semua sistem informasi, sehingga komponen-komponen tersebut belum mampu memberikan dukungan operasional terhadap seluruh komponen organisasi (enterprise) di BPJS Kesehatan c. Penggunaan web service sebagai middleware, mempunyai keterbatasan dalam mendukung integrasi SIM di BPJS Kesehatan. Keterbatasan tersebut diantaranya

minimnya

kehandalan,

interoperabilitas,

ketersediaan,

keamanan, kapasitas layanan, waktu respon, kemudahan penggunaan dan pemeliharaan, sehingga belum optimal mendukung integrasi SIM di BPJS Kesehatan. 2. Manusia a. Keterbatasan personil TI. Jumlah personil pengembangan SI/TI pada Direktorat TI BPJS Kesehatan yang terbatas, sedangkan banyaknya proyek pengembangan SI/TI yang harus dikerjakan dengan konsep interkoneksi SIM sesuai tuntutan organisasi. Upaya-upaya peningkatan pengembangan SI/TI yang terintegrasi belum tercapai karena terbatasnya sumber daya manusia (SDM) pelaksananya. b. Beban kerja personil TI yang tinggi. Dengan semakin banyaknya user requirement dari pemangku kepentingan, semakin meningkatnya beban kerja personil TI, sehingga memengaruhi pengerjaan pengembangan SI/TI



9

yang terintegrasi untuk mendukung kelancaran upaya-upaya pelayanan kepada peserta dan operasionalisasi proses bisnis organisasi. c. Keterampilan dan pengetahuan personil pengembangan SI/TI tidak semuanya lengkap mengenai komponen-komponen teknologi SOA, sehingga sering kali mengembangkan produk SI/TI yang tidak sejalan dengan sistem lainnya. 3. Lingkungan Kapabilitas sumber daya TI pada instansi eksternal yang kurang mendukung integrasi, misalnya terdapat Faskes yang belum dapat terhubung secara sistem dengan BPJS Kesehatan. Hal ini disebabkan teknologi yang digunakan oleh pihak ekternal belum mendukung integrasi SIM dengan BPJS Kesehatan, misalnya masih menggunakan legacy systems yang tidak mendukung teknologi saat ini, dan kemampuan Sumber Daya Manusia (SDM) TI di beberapa Faskes belum mendukung integrasi SIM sehingga menghambat pengembangan integrasi SIM dengan BPJS Kesehatan. 4. Metode a. Standard Operating Procedure (SOP) dari Joint Application Development (JAD) dengan instansi eksternal tidak tersedia. Belum ada dokumen acuan yang mengatur SOP terhadap pengembangan SIM yang dilakukan bersama instansi

eksternal,

sehingga

mengakibatkan

pengerjaan

proyek

pengembangan produk SI/TI belum dapat di-deliver secara tepat waktu. b. Standardisasi Electronic Data Interchange (EDI) terhadap SIM yang sudah selesai dikembangkan tidak tersedia. Sistem yang dikembangkan masih bersifat berdiri sendiri, dikembangkan tanpa memerhatikan integrasi dengan SIM yang sudah ada di BPJS Kesehatan, sehingga menyulitkan untuk dilakukan integrasi dengan SIM internal BPJS Kesehatan yang sudah tersedia. c. Rancangan arsitektur enterprise SI/TI BPJS Kesehatan yang tercantum dalam dokumen ITMP BPJS Kesehatan 2014-2019 dinilai tidak relevan dengan kondisi nyata saat ini. Selain itu, ITMP BPJS Kesehatan 2014-2019 masih menggabungkan IT strategic plan dan arsitektur TI sehingga Universitas Indonesia


10

arsitektur TI tidak didefinisikan secara lengkap dan detil. Hal ini membuat para pengembang SI/TI membuat inovasi-inovasi yang tidak standar, pengerjaan proyek pengembangan SI/TI bersifat ad-hoc dan tanpa perencanaan

yang

baik.

Selain

itu,

terjadinya

kecenderungan

pengembangan SI/TI dilakukan secara tambal sulam karena adanya urgensi kebutuhan suatu modul dari pihak manajemen. Keterbatasan waktu yang sangat singkat membuat para pengembang hanya memerhatikan dampak jangka pendek, dalam arti kata yang penting bahwa kebutuhan mendesak dari manajemen organisasi dapat segera terpenuhi. Kondisi ini menghasilkan produk SI/TI yang tidak berkualitas, pemanfaatan dan sinergi terhadap layanan dan data antar SIM yang rendah. 5. Informasi Pendidikan dan pelatihan (Diklat) berupa kursus pada lembaga pelatihan profesional TI sangat kurang dilakukan terhadap personil SI/TI BPJS Kesehatan. Sehingga informasi mengenai pengetahuan perkembangan teknologi SOA sangat kurang. Berdasarkan sumber masalah di atas, penulis menganggap yang paling kritis dan perlu mendapatkan perhatian khusus adalah penggunaan web service sebagai middleware mempunyai keterbatasan dalam mendukung integrasi SIM di BPJS Kesehatan. 1.3

Pertanyaan Penelitian

Dari analisis identifikasi masalah, diketahui sumber permasalahan di BPJS Kesehatan yang perlu mendapatkan perhatian khusus. Menurut Benosman, Barkaoui, & Albriex (2013), teknologi middleware yang mengimplementasikan konsep SOA dan menjanjikan integrasi aplikasi bisnis dalam lingkungan terdistribusi dan heterogen saat ini adalah teknologi Enterprise Service Bus (ESB). Untuk mengatasi sumber permasalahan tersebut, dan sejalan dengan strategi utama Direktorat TI BPJS Kesehatan, yaitu perencanaan penggunaan teknologi Integrated Switching Services dan Integrated Application Services, Direktorat TI berencana menggunakan teknologi middleware ESB. Universitas Indonesia


11

Saat ini, penyedia teknologi middleware ESB cukup banyak dengan segala kelebihan dan kekurangannya. Pemilihan produk middleware ESB yang paling tepat digunakan tidak mudah dilakukan dalam organisasi, karena banyak faktor yang terlibat dalam pemilihan tersebut (Alghamdi, Ahmad, & Nasir, 2010). Karena tidak sedikit investasi yang dikeluarkan dalam mendukung integrasi sistem informasi di BPJS Kesehatan dan keberlanjutan pemanfaatan teknologi ESB untuk jangka panjang, maka dalam menentukan produk middleware ESB yang dipilih membutuhkan analisis yang tepat. Untuk membantu Direktorat TI BPJS Kesehatan dalam memilih produk middleware ESB yang paling tepat dan sesuai kebutuhan organisasi, maka penulis menetapkan pertanyaan penelitian sebagai berikut: 1. Bagaimana model pemeringkatan kualitas middleware ESB yang sesuai dengan kebutuhan BPJS Kesehatan dalam rangka mengoptimalkan integrasi SIM? 2. Produk middleware ESB yang mana yang paling tepat digunakan BPJS Kesehatan berdasarkan implementasi dari model pemeringkatan kualitas middleware ESB yang telah disusun? Maksud dari pertanyaan penelitian yang pertama adalah menyusun suatu model pemeringkatan produk middleware ESB berdasarkan kriteria kualitas yang sesuai dengan kebutuhan para pemangku kepentingan di BPJS Kesehatan dalam rangka mengoptimalkan integrasi SIM dengan pihak eksternal maupun di internal Direktorat TI BPJS Kesehatan, sedangkan maksud dari pertanyaan penelitian yang kedua adalah mengimplementasikan model yang telah disusun tersebut untuk menentukan produk middleware ESB yang paling tepat digunakan BPJS Kesehatan. 1.4

Tujuan dan Manfaat Penelitian

Dari penetapan pertanyaan penelitian, tujuan penelitian ini adalah menyusun model pemeringkatan kualitas produk middleware ESB untuk memperoleh produk middleware ESB yang paling sesuai dengan kebutuhan BPJS Kesehatan dalam Universitas Indonesia


12

rangka mengoptimalkan integrasi SIM, dan implementasi model tersebut untuk menentukan produk middleware ESB yang paling tepat digunakan BPJS Kesehatan. Penelitian ini dapat memberi manfaat baik dari segi teoretis bagi akademisi maupun dari segi praktis bagi organisasi. Berikut uraian manfaat penelitian ini bagi berbagai pemangku kepentingan: 1. Bagi Akademisi: Sebagai referensi bagi penelitian serupa maupun penelitian lanjutan mengenai penerapan metode Quality Function Deployment dan Analytic Hierarchy Process dalam menyususn model pemeringkatan kualitas perangkat lunak. 2. Bagi Organisasi: a.

Sebagai bahan masukan proses pembelajaran dan panduan dalam kaitannya dengan pemilihan produk middleware ESB yang paling tepat dan sesuai dengan kebutuhan organisasi.

b.

Sebagai referensi untuk mempermudah dalam pembuatan kebijakan organisasi mengenai pemilihan perangkat lunak pada masa yang akan datang.

1.5

Batasan Penelitian

Batasan penelitian ditentukan sebagai berikut: 1. Penelitian ini mengambil studi kasus pada Direktorat TI BPJS Kesehatan. 2. Objek pemeringkatan dibatasi pada empat produk middleware ESB yang ada di pasaran. 3. Pemeringkatan produk middleware ESB yang dilakukan berdasarkan kebutuhan non-fungsional dari faktor teknis perangkat lunak.



13

1.6

Sistematika Penulisan

Sistematika penulisan pada laporan penelitian ini adalah sebagai berikut: 1. BAB 1 PENDAHULUAN Bab ini diawali dengan penjabaran latar belakang penelitian. Masalah dan pertanyaan penelitian dirumuskan berdasarkan latar belakang tersebut. Selanjutnya rumusan masalah akan dijadikan pertanyaan penelitian guna dijawab dalam penelitian. Selain itu, dijelaskan mengenai tujuan, manfaat, dan batasan penelitian untuk memberi arah dan ruang lingkup penelitian. Di akhir bab dijelaskan juga sistematika penulisan. 2. BAB 2 TINJAUAN PUSTAKA Bab ini berisi pembahasan tentang tinjauan pustaka yang akan digunakan oleh penulis sebagai acuan dalam melakukan penelitian ini. Tinjauan pustaka terdiri dari teori yang berhubungan dengan penelitian, penelitian terdahulu, dan kerangka pemikiran. Hasil dari tinjauan pustaka yang sudah dilakukan akan dijadikan rujukan dalam menghasilkan ESB yang paling tepat digunakan BPJS Kesehatan. 3. BAB 3 METODOLOGI PENELITIAN Bab ini membahas rancangan penelitian, instrumen penelitian, perancangan model QFD dan AHP, dan metode pengumpulan data yang digunakan selama penelitian. Selain itu, Bab ini dilengkapi kebutuhan masukan dan keluaran pada setiap tahapan. 4. BAB 4 PROFIL ORGANISASI Bab ini menjelaskan tentang profil organisasi yang menjadi studi kasus penelitian, yang mencakup visi dan misi organisasi, struktur organisasi, dan sekilas tentang rencana strategis BPJS Kesehatan. 5. BAB 5 ANALISIS DAN PEMBAHASAN Bab ini menjelaskan proses analisis data sehingga menghasilkan sebuah keluaran yang menjadi tujuan penelitian. Dengan mengikuti metode QFD dan AHP dilakukan penentuan prioritas kebutuhan, pembobotan terhadap kriteria Universitas Indonesia


14

penilaian, penilaian terhadap alternatif terhadap kriteria, dan hasil akhir pemeringkatan produk middleware ESB. 6. BAB 6 KESIMPULAN DAN SARAN Bab ini menjelaskan hasil kesimpulan yang diperoleh dari setiap tahapan penelitian untuk menjawab pertanyaan penelitian. Selain itu, dibahas juga saran perbaikan untuk penelitian sejenis atau lanjutan.



BAB 2 TINJAUAN PUSTAKA

Bab ini berisi pembahasan tentang tinjauan pustaka yang akan digunakan oleh penulis sebagai acuan dalam melakukan penelitian ini. Tinjauan pustaka terdiri dari teori yang berhubungan dengan penelitian, penelitian terdahulu, dan kerangka pemikiran. Hasil dari tinjauan pustaka yang sudah dilakukan akan dijadikan rujukan dalam menghasilkan ESB yang paling tepat digunakan BPJS Kesehatan. 2.1

Arsitektur Aplikasi

Menurut ISO/IEC/IEEE (2011), arsitektur adalah sesuatu hal yang mendasar dalam organisasi yang terdiri atas sekumpulan komponen organisasi tersebut yang memiliki hubungan satu sama lain dan memiliki keterhubungan dengan lingkungan di sekitarnya, serta memiliki prinsip-prinsip aturan dalam perancangan dan evolusinya. Sedangkan menurut The Open Group Architecture Framework (TOGAF) (2009), arsitektur mempunyai dua pengertian, antara lain: 1. Sebuah deskripsi formal mengenai suatu sistem, atau rencana yang terperinci dari suatu sistem pada tingkat komponen untuk memandu pelaksanaan sistem tersebut. 2. Struktur dari komponen, hubungan antar komponen tersebut, prinsip-prinsip, dan pedoman dalam pengelolaan, perancangan dan evolusinya dari waktu ke waktu. Rotem-Gal-Oz (2012) mendefinisikan arsitektur aplikasi sebagai kumpulan keputusan yang mendasar mengenai produk perangkat lunak atau solusi yang dirancang untuk memenuhi kriteria kualitas proyek atau produk. Arsitektur aplikasi mencakup komponen dan atribut utama, dan kolaborasi antar komponen aplikasi termasuk interaksinya. Arsitektur biasanya dinyatakan dalam beberapa tingkatan yang tergantung pada ukuran dan kompleksitas proyek.

15



16

2.2

Integrasi Arsitektur

Kebanyakan organisasi masih menggunakan sistem informasi warisan yang telah dibangun dengan arsitektur dan teknologi berbeda dengan teknologi saat ini dan biasanya tidak dirancang untuk integrasi. Organisasi tersebut tidak dapat membangun ulang sistem informasinya dari awal dalam waktu yang cepat. Mengintegrasikan arsitektur dalam organisasi yang besar merupakan pekerjaan yang sangat sulit dikerjakan (Juric et al., 2007). Juric et al. (2007) menawarkan pendekatan untuk mempermudah melakukan integrasi arsitektur, yaitu pendekatan bottom-up dan top-down. Pendekatan bottomup adalah pendekatan yang fokusnya terhadap permasalahan individual yang timbul karena kurangnya integrasi antar sistem informasi. Pendekatan bottom-up memecahkan permasalahan individual melalui pengerjaan proyek terhadap integrasi yang tidak terkoordinasi, tanpa membangun ulang arsitektur integrasi secara global. Pendekatan top-down adalah integrasi yang dilakukan dimana arsitektur integrasi didefinisikan terlebih dahulu, dan kemudian ditentukan bagaimana caranya dengan sistem yang sudah ada, dapat untuk melakukan integrasi terhadap arsitektur yang sudah didefinisikan tersebut. Juric et al. (2007) menyatakan beberapa manfaat dari arsitektur terintegrasi. Manfaat tersebut antara lain: 1. Reusability, adalah kemampuan untuk menggunakan kembali fungsi yang sudah tersedia. 2. Enkapsulasi, adalah kemampuan untuk mengenkapsulasi setiap lapisan dari suatu layanan sistem, sehingga klien yang mengakses layanan sistem tidak perlu mengetahui internal layanan sistem secara terperinci. 3. Terdistribusi, dimana layanan sistem dari arsitektur terintegrasi terdistribusi, dan atau direplikasi tanpa diperlukan modifikasi dari klien, dengan demikian untuk mengakses layanan sistem tidak terbatas pada satu klien atau satu proses. 4. Kemampuan partisi, dimana dengan menempatkan logika bisnis aplikasi ke dalam partisi-partisi yang terpisah.



17

5. Skalabilitas, adalah kemampuan untuk meningkatkan ukuran, volume, atau jumlah pengguna yang dilayani. 6. Kemampuan peningkatan kinerja sistem, dimana dengan teknik optimasi, seperti melakukan multi proses, multi urutan, penyatuan, dan pengelolaan sumber daya tanpa memodifikasi aplikasi dan memungkinkan perubahan konfigurasi secara dinamis. 7. Kemampuan peningkatan kehandalan sistem, yaitu kegagalan sistem dapat dihilangkan dengan menggunakan replikasi dan distribusi. Arsitektur terintegrasi dibangun dalam beberapa tipe untuk memecah permasalahan menjadi lebih kecil dan untuk memecahkannya dalam beberapa tahap (Juric at al, 2007). Tipe-tipe integrasi arsitektur antara lain: 1. Integrasi Data, adalah integrasi yang fokus terhadap perpindahan data antar aplikasi yang berbeda dengan tujuan untuk berbagi data yang sama. 2. Integrasi Aplikasi, adalah integrasi yang fokus terhadap berbagi fungsionalitas atau logika yang ada dalam aplikasi. Integrasi aplikasi biasanya menggunakan Application Programming Interfaces (APIs). Fungsionalitas aplikasi yang dibagikan melalui APIs, secara terprogram dapat diakses tanpa menggunakan antar muka pengguna. 3. Integrasi Proses Bisnis, adalah integrasi yang menyajikan sistem informasi untuk organisasi yang besar dengan persyaratan kebutuhan yang jelas dengan dukungan pengetahuan dan teknologi modern. Antar muka sistem informasi dibangun berdasarkan rancangan arsitektur baru dengan menggunakan dan memodifikasi aplikasi yang sudah ada. 4. Integrasi Lapisan Presentasi, adalah integrasi yang menghasilkan sistem yang terintegrasi dengan menyediakan lapisan presentasi yang menyatu, dimana pengguna dapat mengakses fungsionalitas melalui lapisan presentasi dari sistem yang terintegrasi tersebut.



18

2.3

Infrastruktur Teknologi Informasi

Infrastruktur teknologi informasi adalah sebuah kombinasi dari sekumpulan aplikasi perangkat lunak, perangkat keras, sistem penyimpanan, piranti jaringan komputer, perlengkapan komunikasi, piranti pengendali akses, dan lainnya untuk mendukung manusia, aplikasi, dan infrastruktur lainnya supaya beroperasi (ITIL, 2007). Gambar 2.1 menunjukkan kaitan antara infrastruktur umum, infrastruktur TI dan aplikasi.

Gambar 2.1 Lapisan Komponen Infrastruktur Sumber: Robertson & Sribar (2001)

Menurut Robertson dan Sribar (2001), infrastruktur memiliki karakteristik, antara lain: 1. Penggunaannya lebih luas dibanding struktur yang didukungnya. 2. Lebih permanen atau statis dibanding struktur yang didukungnya. 3. Sering diperhitungkan sebagai layanan pendukung. 4. Terhubung secara fisik dengan struktur yang didukungnya. 5. Kepemilikan dan pengelolaan oleh pihak yang berbeda dari struktur yang didukungnya. Terdapat dua layanan infrastruktur yang diperlukan untuk integrasi (Juric et al, 2007), yaitu layanan horizontal yang menyediakan infrastruktur dasar untuk mendukung sistem informasi yang sudah ada dan sistem informasi baru, dan Universitas Indonesia


19

layanan vertikal yang menyediakan layanan fungsionalitas yang berhubungan dalam tugas tertentu dalam infrastruktur untuk mendukung beberapa layanan dari lapisan horizontal. Layanan infrastruktur integrasi lapisan horizontal terdiri dari communication, brokering and routing, transformation, dan business intelligence. Sedangkan layanan infrastruktur integrasi lapisan vertikal terdiri dari transactions, security, lifecycle, naming, scalability, management, dan rules. Relasi antar layanan infrastruktur integrasi ditunjukkan pada Gambar 2.2.

Gambar 2.2 Relasi Layanan Infrastruktur Terintegrasi Sumber: Juric et al. (2007)

2.4

Service Oriented Architecture (SOA)

Istilah SOA pertama kali digunakan pada tahun 1996 oleh Roy Schulte dan Yeffim V. Natiz untuk menggambarkan gaya komputasi berlapis untuk membantu organisasi dalam berbagi logika dan data antar aplikasi (Rotem-Gal-Oz, 2012). Definisi dari service adalah penyampaian sekumpulan proses atau layanan aplikasi kepada pengguna melalui penyedia layanan (Robertson & Sribar, 2001). Menurut Juric (2007), Service Oriented Architecture (SOA) didefinisikan sebagai arsitektur, prinsip, pola, dan teknologi untuk menyederhanakan integrasi, membuatnya lebih efisien dan mendukung sepenuhnya proses bisnis; sedangkan menurut Rotem-GalOz (2012), SOA adalah gaya arsitektur untuk membangun sistem berdasarkan interaksi loosely coupled, coarse-grained dan otonomi komponen yang digabung menjadi satu layanan. Rotem-Gal-Oz (2012) menyatakan bahwa terdapat enam komponen penting yang menjadikan sebuah infrastruktur TI dapat disebut sebagai SOA. Komponenkomponen penting tersebut antara lain: Universitas Indonesia


20

1. Service Service merupakan komponen paling utama dari SOA. Fungsionalitas yang terdapat dalam suatu service harus berbeda satu sama yang lainnya dan service tersebut harus dapat mengimplementasikan semua fungsi yang sudah dijanjikan dalam suatu kontrak layanan. 2. Message Unit komunikasi dari SOA adalah message. Bentuk dari message bisa bermacam-macam, seperti HTTP GET, Simple Object Access Protocol (SOAP), Java Message Services (JMS), Simple Mail Transfer Protocol (SMTP). Suatu message memiliki header dan body. Header biasanya generik dan isinya dapat dimengerti oleh komponen infrastruktur dan kerangka kerja sistem tanpa mengetahui implementasinya secara rinci. 3. Contract Contract adalah sekumpulan dari semua message yang didukung oleh service. 4. Endpoint Endpoint adalah sebuah Universal Resource Identifier (URI), yaitu alamat atau lokasi spesifik dimana service berada. 5. Policy Suatu policy mengatur syarat dan ketentuan yang menjadikan service tersedia untuk melayani kebutuhan. 6. Service Consumer Service consumer adalah komponen perangkat lunak yang berinteraksi dengan sebuah service melalui message. Interaksi antara keenam komponen penting penting yang menjadikan sebuah infrastruktur TI dapat disebut sebagai SOA ditunjukkan pada Gambar 2.3.



21

Gambar 2.3 Interaksi Antar Komponen SOA Sumber: Rotem-Gal-Oz (2012)

2.5

Middleware

Integrasi infrastruktur secara menyeluruh pada suatu organisasi biasanya ditemukan penggunaan teknologi-teknologi yang berbeda dan kemudian harus menyatukan teknologi-teknologi tersebut. Untuk menyatukan teknologi yang berbeda tersebut perlu memerhatikan interoperabilitasnya. Teknologi yang saat ini dapat digunakan untuk integrasi yang menawarkan konektivitas dan interoperabilitas terhadap aplikasi adalah teknologi middleware (Juric et al., 2007). Middleware adalah perangkat lunak yang menjadi perantara antara lapisan sistem operasi dan lapisan aplikasi, dan menyediakan layanan (Juric et al., 2007). Teknologi middleware digunakan sebagai solusi untuk menggabungkan satu atau lebih aplikasi yang berbeda. Teknologi middleware sejak pertama kali ditemukan, telah mengalami evolusi perkembangan. Gambar 2.4 menunjukkan evolusi perkembangan teknologi middleware.

Gambar 2.4 Perkembangan Teknologi Middleware Sumber: Chappell D. (2004) Universitas Indonesia


22

Bentuk umum dari teknologi middleware antara lain: 1. Database Access Technologies, adalah teknologi yang menyediakan akses terhadap basis data melalui suatu lapisan yang memungkinkan melakukan perubahan pada Database Management System (DBMS) tanpa melakukan perubahan terhadap kode sumber pada aplikasi. 2. Remote Procedure Calls (RPC), adalah infrastruktur klien-server yang memungkinkan melakukan komunikasi langsung (synchronous) antar aplikasi melalui

platform

terdistribusi

dan

berbeda

untuk

meningkatkan

interoperabilitas, fleksibilitas, dan portabilitas dari aplikasi. 3. Message-Oriented Middleware (MOM), adalah infrastruktur klien-server yang mempunyai kesamaan fungsi seperti RPC, tetapi mendukung komunikasi tidak langsung (asynchronous) 4. Transaction Processing (TP) Monitors, adalah teknologi middleware yang berfungsi untuk melakukan pengawasan terhadap kinerja sistem melalui teknik pengaturan beban dan sumber daya untuk mengefisienkan penggunaan sumber daya dan akses klien yang bersamaan dalam jumlah besar. 5. Object Request Broker (ORB), adalah teknologi middleware yang mengatur dan mendukung komunikasi antar komponen atau objek yang terdistribusi. 6. Application Server, adalah teknologi yang menangani semua proses interaksi antar lapisan klien dan lapisan data, dan menyediakan semua layanan dari middleware. 7. Web Service, adalah konsep yang menjadi dasar untuk mencapai interoperabilitas antara aplikasi yang menggunakan platform perangkat lunak, sistem operasi, dan bahasa pemrograman yang berbeda. 8. Enterprise Service Buse (ESB), adalah infrastruktur perangkat lunak yang bertindak sebagai lapisan perantara dari middleware yang memenuhi persyaratan kebutuhan yang biasanya tidak dapat dipenuhi oleh web service pada umumnya, seperti integrasi antara beberapa web service dan teknologi dan produk middleware lainnya.



23

2.6

Web service

Web service didefinisikan sebagai sekumpulan logika bisnis yang dapat diakses melaui protokol internet berbasis Hypertext Transfer Protocol (HTTP) dan Simple Mail Transfer Protocol (SMTP) untuk menyederhanakan kebutuhan bisnis antar organisasi (Chappell & Jewell, 2002). Arsitktur web service ditunjukkan pada Gambar 2.5.

Gambar 2.5 Arsitektur Web Service Sumber: Juric et al. (2007)

Web service mempunyai karakteristik sebagai berikut: 1. Berbasiskan Extension Markup Language (XML). XML merupakan representasi pertukaran data dari teknologi web service. XML tidak mempunyai ketergantungan terhadap jaringan, sistem operasi dan protokol tertentu. 2. Loosely Coupled. Loosely

coupled

adalah

sebuah

konsep

sistem

untuk

mengurangi

ketergantungan dari suatu sistem. Pengadopsian konsep loosely coupled digunakan untuk membuat sistem perangkat lunak lebih mudah dikelola dan penyederhanaan integrasi antara sistem yang berbeda. 3. Coarse-grained. Teknologi web service menyediakan layanan coarse-grained yang merupakan kumpulan dari beberapa layanan kecil yang terbentuk menjadi layanan besar yang dapat diakses oleh klien dan web service itu sendiri. Universitas Indonesia


24

4. Mendukung Remote Procedure Calls (RPCs). Web Service menyediakan layanan terhadap klien yang memungkinkan klien memanggil prosedur, fungsi, dan metode dengan menggunakan protokol berbasis XML. 5. Mendukung pertukaran dokumen. Salah satu manfaat dari XML adalah XML tidak hanya merepresentasikan data, tetapi juga merepresentasikan dokumen yang mempunyai kompleksitas tinggi. 2.7

Enterprise Service Bus (ESB)

Terdapat beberapa definisi yang terkait dengan ESB. Definisi dari ESB adalah sebagai berikut: 1. ESB adalah platform integrasi berbasis standar yang menggabungkan pertukaran pesan, web service, transformasi data dan intelligent routing, yang dipercaya handal dalam menghubungkan dan mengkoordinasikan interaksi sejumlah besar aplikasi antar organisasi besar dengan integrasi transaksional (Chappell D. , 2004). 2. ESB adalah infrastruktur untuk mendukung integrasi secara fleksibel menggunakan konsep SOA secara end-to-end (Li et al., 2012). 3. ESB adalah infrastruktur perangkat lunak yang bertindak sebagai lapisan perantara dari middleware yang memenuhi persyaratan kebutuhan yang biasanya tidak dapat dipenuhi oleh web service pada umumnya, seperti integrasi antara beberapa web service dan teknologi dan produk middleware lainnya. ESB mempunyai tingkat ketahanan, keamanan, pengelolaan yang tinggi, dan pengendalian terhadap komunikasi dan layanannya (Juric et al., 2007). 4. ESB merupakan standar terbuka, berbasis pesan, infrastruktur integrasi terdistribusi yang menyediakan routing, permintaan dan mediasi layanan untuk memfasilitasi interaksi dari aplikasi terdistribusi yang berbeda dan layanan dalam cara yang aman dan terpercaya (Menge, 2007). Proses penciptaan teknologi ESB dimulai pada tahun 1990-an ketika dikembangkannya konsep MOM. ESB berawal dari kegiatan vendor dan pengguna Universitas Indonesia


25

yang mempunyai pikiran ke depan dengan mencoba membuat jaringan terintegrasi berbasis standar menggunakan prinsip-prinsip dasar dari SOA, messaging, dan XML. ESB merupakan perangkat lunak untuk menyederhanakan pengembangan konsep Enterprise Application Integration (EAI). ESB menawarkan layanan terhadap organisasi yang menyediakan infrastruktur sesuai kebutuhan dan menyediakan fungsionalitas seperti skalabilitas komunikasi, mediasi dan pengendalian layanan. Gambar 2.6 menunjukkan contoh arsitektur menggunakan teknologi ESB.

Gambar 2.6 Contoh Arsitektur menggunakan ESB Sumber: Breest (2006)

ESB berfungsi sebagai middleware, dimana setiap pengguna layanan hanya perlu terhubung ke bus, dan dengan sekali terhubung dapat mengakses setiap layanan yang tersedia pada bus. Sebuah permintaan layanan dari pengguna diterjemahkan menjadi suatu message dan kemudian dikirim ke endpoint. Tidak seperti solusi integrasi sederhana lainnya, suatu layanan atau proses yang mengakses beberapa layanan tidak perlu membangun koneksi kembali ke masing-masing layanan endpoint. Dengan begitu terjadi kondisi yang optimal pada lingkungan SOA secara luas dan terdistribusi. Juric et al. (2007) menjelaskan konsep ESB sebagai berikut: 1. ESB memberikan layanan dengan kualitas untuk organisasi besar. Kehandalan, toleransi kegagalan, dan keamanan adalah sifat yang melekat dari layanan, dan merupakan tanggung jawab dari platform ESB. Universitas Indonesia


26

2. Layanan pada ESB sangat sangat mudah digunakan oleh semua pengguna layanan. 3. ESB mengimplementasikan topologi bus untuk membuat layanan tersedia secara luas dan untuk digunakan kembali. Prinsip penggunaan dari ESB menurut Juric et al. (2007), antara lain: 1. Bebasiskan XML. 2. Kerangka kerja untuk layanan host dan run, atau layanan akses yang berjalan pada lingkungan eksternal. 3. Skalabilitas komunikasi sangat tinggi untuk memastikan kualitas layanan yang diberikan. 4. Kapabilitas untuk terhubung dengan sistem yang bermacam-macam. 5. Dukungan untuk melakukan rute dan transformasi pesan. 6. Dukungan melakukan orkestrasi dari layanan yang diberikan. 7. Kerangka kerja untuk sistem yang berdasarkan kejadian dan notifikasi. ESB menawarkan standardisasi terhadap proses integrasi. Standardisasi tersebut berdampak positif terhadap organisasi. Dampak tersebut antara lain: 1. Memungkinkan organisasi untuk memanfaatkan staf TI yang ada, daripada menggunakan konsultan spesialis. 2. Mengurangi ketergantungan terhadap konsultan. 3. Meningkatkan kemampuan untuk mengintegrasikan dengan mitra bisnis menggunakan antarmuka dan protokol yang standar. Layanan yang ditawarkan oleh ESB pada dasarnya cocok untuk semua jenis model layanan yang umum. Layanan dalam suatu ESB dianggap tersedia pada alamat layanan yang diberikan kepada pengakses ESB sering disebut sebagai endpoint layanan. Endpoint tersebut bisa berbentuk service, process, message router, transformation, dan simple message destination. Menurut Menge (2007), ESB mempunyai fitur-fitur sebagai berikut:



27

1. Invocation, adalah kemampuan dari ESB untuk mengirim permintaan dan menerima tanggapan dari layanan dan sumber daya yang sudah terintegrasi. 2. Routing, adalah kemampuan untuk menentukan tujuan dari pesan selama proses perpindahan pesan tersebut. 3. Mediation, mengacu pada semua transformasi dan penerjemahan antara protokol perpindahan, format pesan, dan isi pesan dari sumber yang berbeda. 4. Adapters, adalah alat untuk menghubungkan antarmuka transaksi dan struktur data yang diekspos oleh aplikasi bisnis dan menyajikan antarmuka standar, yang membuatnya mudah untuk menggunakan kembali logika bisnis dan data. 5. Security, adalah kemampuan untuk mengamankan pesan dalam proses pertukarannya. 6. Management, adalah kemampuan untuk menyediakan fasilitas audit untuk mengawasi infrastruktur dan skenario integrasi serta untuk mengontrol proses eksekusi. 7. Process Orchestration, adalah kemampuan untuk menyediakan alat untuk mengeksekusi proses bisnis yang digambarkan dengan Web Services Business Process Execution Language (WS-BPEL). 8. Complex Event Processing, adalah mekanisme untuk interpretasi peristiwa, korelasi dan pencocokan pola peristiwa yang memungkinkan terciptanya arsitektur yang ditentukan oleh suatu kejadian. 9. Integration Tooling, adalah penyediaan alat untuk pengembangan, pengujian, dan penyebaran secara profesional dengan grafis yang baik. 2.8

Model Kualitas Perangkat Lunak

Kualitas adalah totalitas karakteristik suatu entitas yang bertanggungjawab pada kemampuannya dalam memenuhi kebutuhan yang dinyatakan dan tersirat (ISO/IEC, 2001). Model kualitas didefinisikan sebagai sekumpulan dari karakteristik-karakteristik dan hubungan antara karakteristik tersebut yang memberikan landasan dalam menentukan persyaratan kualitas dan untuk mengevaluasi kualitas (ISO/IEC, 2001). Untuk mendapatkan pernyataan yang valid Universitas Indonesia


28

sebagai hasil dari pengukuran, model kualitas perlu dilakukan untuk mendefinisikan kriteria dan subkriteria yang berhubungan dengan kualitas perangkat lunak (Zeiss, Vega, & Schieferdecker, 2007). Berikut dijabarkan beberapa model kualitas perangkat lunak. 2.8.1

McCall

Mccall merupakan model kualitas pertama yang dikembangkan dalam pengembangan sistem informasi pada tahun 1977. Model ini berupaya untuk membangun hubungan antara pengguna dan pengembang sistem informasi dengan mendefinisikan sejumlah faktor kualitas produk perangkat lunak yang diperlukan pengguna dan pengembang sistem (Djouab & Bari, 2010). Model kualitas Mccall menyusun kualitas produk perangkat lunak berdasarkan beberapa faktor yang dikelompokan menjadi tiga kelompok yang menggambarkan sudut pandang dari luar, yaitu pengguna sistem, yang terdiri atas product review ‘ulasan produk’, product operation ‘operasi produk’, dan product transition ‘transisi produk’. Setiap faktor mempunyai quality criteria ‘kriteria kualitas’ yang menggambarkan sudut pandang dari dalam, yaitu pengembang sistem. Setiap kriteria kualitas mempunyai metric ‘ukuran’ untuk memberikan skala dan metode dalam pengukuran kualitas. Gambar 2.7 menunjukkan model kualitas Mccall.

Gambar 2.7 Model Kualitas Mccall Sumber: Miguel, Mauricio, & Rodríguez (2014) Universitas Indonesia


29

Kekurangan dari model kualitas Mccall adalah tidak mempertimbangkan fungsi sehingga sudut pandang dari pengguna berkurang. Kekurangan lainnya adalah ketepatan dalam pengukuran kualitas, dimana pengukuran tidak objektif yang didasarkan pada jawaban responden, ya atau tidak (Miguel, Mauricio, & Rodríguez, 2014). 2.8.2

Boehm

Model kualitas Boehm merupakan pengembangan dari model Mccall dengan menambahkan beberapa faktor (Boehm, Brown, & Lipow, 1976). Faktor utama dari model ini adalah (1) utility yang mengindikasikan kemudahan, kehandalan, dan efesiensi, (2) maintability yang menjelaskan fasilitas untuk modifikasi, pengujian, dan aspek pemahaman, (3) portability yaitu kemampuan keberlanjutan penggunaan pada lingkungan yang berubah. Model Boehm dan Mccall, keduanya menjelaskan kualitas berdasarkan pendekatan dekomposisi, tetepi keduanya mempunyai perbedaan, yaitu pada model Boehm, ruang lingkup faktor maintainability yang lebih luas daripada model Mccall. Gambar 2.8 menunjukkan model kualitas Boehm.

Gambar 2.8 Model Kualitas Boehm Sumber: Boehm, Brown, & Lipow (1976) Universitas Indonesia


30

2.8.3

FURPS

FURPS

merupakan

akronim

dari

Functionality,

Usability,

Reliability,

Performance, dan Supportability. Model kualitas FURPS diperkenalkan pada tahun 1992 oleh Robert Grady dan Hewlett-Packard yang digunakan untuk kebutuhan industri perangkat lunak. Faktor kualitas model ini terbagi atas dua kategori, yaitu functional yang menjelaskan masukan dan keluaran yang diharapkan, dan nonfunctional requirements yang terdiri atas kehandalan, kinerja, kemudahan penggunaan, dan dukungannya. Kekurangan dari model ini adalah tidak mengikutsertakan faktor portability (Miguel, Mauricio, & Rodríguez, 2014). Gambar 2.9 menunjukkan model kualitas FURPS.

Gambar 2.9 Model Kualitas FURPS Sumber: Miguel, Mauricio, & Rodríguez (2014)

2.8.4 ISO 9126 The International Organization for Standardisation (ISO) adalah organisasi yang didirikan pada tahun 1946 untuk memfasilitasi perdagangan internasional, Universitas Indonesia


31

koordinasi internasional dan penyatuan standar industri dengan menyediakan sekumpulan standardisasi untuk dipergunakan (Chua & Dyson, 2004). ISO/IEC 9126 adalah standar kualitas produk perangkat lunak yang diperkenalkan oleh ISO dan the International Electrotechnical Commission (IEC) pada tahun 1991 untuk menyediakan spesifikasi yang komprehensif dan model evaluasi kualitas produk perangkat lunak yang diberi nama ISO/IEC 9126:1991 Software Product Evaluation-Quality Characteristics and Guidelines (Idri, Karima, & Abran, 2013). Model Kualitas ini mengadopsi model kualitas McCall dan Boehm (ISO/IEC, 2001). Komite ISO melakukan revisi terhadap ISO/IEC 9126:1991 dengan membagi ISO/IEC 9126 menjadi empat bagian (ISO/IEC, 2001), antara lain: 1. Bagian 1: Quality Model atau ISO/IEC 9126-1. ISO/IEC 9126 Bagian 1 atau ISO/IEC 9126-1, dirilis pada tahun 2001. Isinya merekomendasikan suatu model kualitas yang terdiri dari karakteristikkarakteristik kualitas yang penting dalam menghasilkan produk perangkat lunak. Model kualitas yang ditawarkan ISO/IEC 9126-1 terdiri dari tiga aspek, yaitu: a. Kualitas internal, adalah totalitas karakteristik produk perangkat lunak dari sudut pandang internal yang diukur dan dievaluasi terhadap persyaratan kualitas internal (ISO/IEC, 2001). b. Kualitas eksternal, adalah totalitas karakteristik produk perangkat lunak dari sudut pandang eksternal dimana kualitas ketika perangkat lunak dijalankan, yang biasanya diukur dan dievaluasi saat uji coba pada lingkungan simulasi dengan data simulasi menggunakan ukuran dari sisi eksternal (ISO/IEC, 2001). c. Kualitas dalam penggunaan, adalah pandangan pengguna dari kualitas produk perangkat lunak bila digunakan dalam lingkungan tertentu dan konteks penggunaan tertentu (ISO/IEC, 2001).



32

Model kualitas untuk kualitas internal dan eksternal ISO/IEC 9126 ditunjukkan pada Gambar 2.10, dan model kualitas dalam penggunaan ditunjukkan pada Gambar 2.11.

Gambar 2.10 Model Kualitas Internal dan Eksternal ISO 9126 Sumber: ISO/IEC (2001)

Gambar 2.11 Model Kualitas dalam Penggunaan dari ISO 9126 Sumber: ISO/IEC (2001)

2. Bagian 2: External Metrics atau ISO/IEC 9126-2. ISO/IEC 9126 Bagian 2 atau ISO/IEC 9126-2, dirilis pada tahun 2003. Isinya membahas ukuran kualitas eksternal yang digunakan dalam pengukuran karakteristik kualitas perangkat lunak (yang bisa dijalankan) yang diaplikasikan untuk produk perangkat lunak selama pengujian atau pengoperasian pengembangan dalam tahap selanjutnya dan setelah memasuki proses operasi. 3. Bagian 3: Internal Metrics atau ISO/IEC 9126-3. ISO/IEC 9126 Bagian 3 atau ISO/IEC 9126-3, dirilis pada tahun 2003. Isinya membahas ukuran kualitas internal yang digunakan dalam pengukuran karakteristik kualitas perangkat lunak (yang tidak bisa dijalankan) yang Universitas Indonesia


33

diaplikasikan untuk produk perangkat lunak selama perancangan dan pada tahap awal proses pengembangan. 4. Bagian 4: Quality in Use Metrics atau ISO/IEC 9126-4. ISO/IEC 9126 Bagian 4 atau ISO/IEC 9126-4, dirilis pada tahun 2001. Isinya membahas ukuran kualitas dalam penggunaan untuk mengukur karakteristik kualitas perangkat lunak (yang bisa dijalankan) yang diaplikasikan untuk produk perangkat lunak setelah memasuki proses pengoperasian. Djouab & Bari (2010) menyatakan bahwa model kualitas ISO/IEC 9126 mempunyai kekurangan. Kekurangan tersebut antara lain: 1.

Terlalu umum.

2.

Tidak menjelaskan kebutuhan manajerial bisnis mengenai Return on Investment (ROI) dan faktor kualitas.

3.

Penelusuran terhadap perangkat lunak dan konsistensi data yang sulit dimengerti.

4.

Tidak menjelaskan metode yang digunakan dalam pengukuran.

2.8.5

Dromey

Model Dromey dikembangkan oleh R. Geoff Dromey yang didasarkan pada hubungan antara atribut kualitas dan sub atribut, serta hubungan antara sifat-sifat produk dan atribut kualitas perangkat lunak (Djouab & Bari, 2010). Model ini bertujuan untuk menyediakan suatu model dalam cakupan yang luas yang dapat diaplikasikan ke berbagai area (Kumar, 2012). Gambar 2.12 menunjukkan model kualitas Dromey.

Gambar 2.12 Model Kualitas Dromey Sumber: Miguel, Mauricio, & Rodríguez (2014) Universitas Indonesia


34

2.8.6

ISO 25010

Setelah merilis dan memperbarui standar kualitas produk perangkat lunak ISO 9126, ISO/EIC mengembangkan standar baru yang lebih komprehensif dalam suatu framework yang disebut SQuaRE (Systems and software Quality Requirements and Evaluation)

pada

tahun

2008.

SQuaRE

membagi

organisasinya

yang

merepresentasikan pengelompokan standardisasi dengan nama divisi (ISO/IEC JTC 1, 2008). Gambar 2.13 menunjukkan framework dari SQuaRE.

Gambar 2.13 Framework SQuaRE Sumber: ISO/IEC JTC 1 (2008)

Model kualitas ISO 25010 merupakan bagian dari SQuaRE yang menyajikan model kualitas perangkat lunak secara terperinci, kualitas penggunaan dan kualitas data (ISO/IEC JTC 1, 2008). ISO 25010 merupakan standar untuk kualitas perangkat lunak yang menghadirkan model kualitas yang dapat diterapkan untuk setiap jenis produk perangkat lunak. Model kualitas ISO 25010 menjelaskan model kualitas sistem dan perangkat lunak yang dikembangkan untuk memperbarui model ISO 9126:2001 dengan menambahkan karakteristik kualitas baru, yaitu security, dan memperbarui

karakteristik

portability

menjadi

dua

karakteristik,

yaitu

transferability dan compatibility, serta membagi kualitas penggunaan menjadi usability in use, flexibility in use dan safety. Gambar 2.14 menunjukkan model kualitas produk perangkat lunak ISO 25010. Sama seperti ISO 9126, standar ISO 25010 terdiri dari model kualitas produk perangkat lunak yang yang dapat digunakan untuk mengukur internal dan eksternal, dan model kualitas penggunaan Universitas Indonesia


35

yang dapat digunakan untuk mengukur penggunaan produk dalam konteks penggunaan yang realistis.

Gambar 2.14 Model Kualitas Perangkat Lunak ISO 25010 Sumber: ISO/IEC JTC 1 (2008)

Perbandingan karakteristik kualitas antara model kualitas yang sudah dijelaskan dapat dilihat pada Tabel 2.1. Tabel 2.1 Perbandingan Model Kualitas Karakteristik Kualitas

McCall

Boehm

FURPS

Dromey

Accuracy

ISO

ISO

9126

25010

√

√

√

Adaptability

√

Analyzability

√

√

Attractiveness

√

√

Changeability

√

√

Correctness

√

Efficiency

√

Flexibility

√

√ √ √

Functionality

√

√

√

√

√

√

√

√

√

Human Engineering Installability Integrity

√

√

Interoperability

√

√

Maintainability

√

√

Maturity

√

√

√

√



36

Tabel 2.1 Perbandingan Model Kualitas (sambungan) Karakteristik Kualitas

McCall

Boehm

FURPS

Dromey

ISO

ISO

9126

25010 √

Modifiability √

√

√

√

√

√

√

√

√

√

√

√

Operability √

Performance Portability

√

√

Reliability

√

√

√

Resource utilization √

Reusability

√

√

Stability

√

√

Suitability

√

√

√

√

√

√

√

Supportability √

Testability

√

√

Transferability √

Understandability √

Usability

√

√

√

√

√

√

Sumber: Miguel, Mauricio, & Rodríguez (2014)

Berdasarkan Tabel 2.1 tersebut, terlihat bahwa standar ISO 25010 adalah versi paling lengkap dari model kualitas standar ISO lainnya karena mempunyai jumlah atribut kualitas paling banyak. Franca & Soares (2015) menyatakan bahwa karakteristik kualitas yang terdapat dalam ISO 25010 perlu dipelajari dan disesuaikan untuk diterapkan secara spesifik pada aplikasi SOA. Untuk itu, mereka mengkaji dan membangun suatu model baru berdasarkan model kualitas ISO 25010 yang spesifik diterapkan dalam penerapan SOA yang diberi nama SOAQM (Service Oriented Architecture Quality Model). Semua atribut kualitas yang ditawarkan oleh ISO 25010 dilakukan analisis dari perspektif SOA. Analisis tersebut melibatkan pendapat ahli dan kajian literatur. Model kualitas SOAQM ditunjukkan pada Gambar 2.15.



37

SOAQM

Performance efficiency

Functional Suitability

Functional completeness Time behaviour Functional correctness Resource utilization Functional appropriateness

Compatibility

Usability

Reliability

Security

Maintainability

Portability

Co-existence Interoperability

Appropriateness recognizability Operability Learnability User error protection

Maturity Availability Fault tolerance Recoverability

Confidentiality Integrity Accountability Authenticity Non-repudiation

Modularity Reusability Modifiability Testability Analyzability

Adaptability Installability Replaceability

Gambar 2.15 Model Kualitas SOAQM Berikut dijabarkan definisi dari setiap kriteria dan subkriteria kualitas perangkat lunak berdasarkan model kualitas SOAQM. 1. Functional suitability menyatakan ukuran yang terdapat pada perangkat lunak dalam menyediakan fungsi sesuai kebutuhan ketika digunakan dalam kondisi tertentu. a. Functional completeness adalah ukuran sejauh mana sekumpulan fungsi perangkat lunak mencakup semua tugas tertentu sesuai dengan tujuan pengguna. b. Functional correctness adalah ukuran sejauh mana produk atau sistem memberikan hasil yang benar dengan tingkat presisi sesuai dengan kebutuhan. c. Functional appropriateness adalah ukuran sejauh mana suatu fungsi dapat memfasilitasi tugas dan tujuan yang ditentukan. 2. Performance efficiency menyatakan ukuran kinerja terhadap jumlah sumber daya yang digunakan dalam kondisi yang ditentukan. a. Time behaviour menganalisis waktu respons dan waktu pengolahan, dan throughput dari sistem ketika menjalankan fungsinya. b. Resource utilization adalah kemampuan dalam pengelolaan jumlah dan jenis sumber daya yang digunakan oleh suatu produk atau sistem ketika menjalankan fungsinya. Universitas Indonesia


38

3. Compatibility menyatakan sejauh mana suatu produk, sistem atau komponen dapat saling bertukar informasi dengan produk, sistem, atau komponen lainnya, dan, atau melakukan fungsi yang diperlukan, dalam berbagi perangkat keras atau perangkat lunak dalam lingkungan yang sama. a. Co-existence adalah sejauh mana suatu produk dapat menjalankan fungsinya secara efisien ketika berbagi sumber daya yang sama dengan produk lainnya tanpa dampak yang merugikan pada produk lainnya. b. Interoperability mengacu kepada sejauh mana dua atau lebih sistem bisa bertukar informasi dan menggunakan informasi yang telah dipertukarkan. 4. Usability menyatakan sejauh mana produk atau sistem dapat digunakan oleh pengguna tertentu untuk mencapai tujuan tertentu secara efektif, efisien, dan kepuasan penggunaan dalam konteks tertentu. a. Appropriateness recognizability mengacu kepada sejauh mana pengguna dapat mengenali apakah sistem sesuai dengan kebutuhan. b. Learnability terkait dengan tingkat dimana suatu sistem dapat digunakan oleh pengguna tertentu untuk mencapai tujuan tertentu dalam melakukan proses pembelajaran penggunaan sistem dengan mudah. c. Operability mengacu kepada sejauh mana atribut yang dimiliki suatu produk atau sistem mudah dioperasikan. d. User error protection terkait dengan sejauh mana sistem melindungi pengguna terhadap pembuatan kesalahan. 5. Reliability menyatakan sejauh mana sistem, produk atau komponen melakukan fungsi secara spesifik di bawah kondisi tertentu dalam jangka waktu tertentu. a. Maturity berkaitan dengan sistem dalam memenuhi kebutuhan mengenai ketersediaan dalam melakukan operasi yang normal, atau dapat diartikan sebagai harapan dari layanan dalam menanggapi permintaan informasi.



39

b. Availability adalah pendefinisian sejauh mana sistem, produk atau komponen untuk dioperasikan dan diakses bila diperlukan. c. Fault tolerance mengacu pada sejauh mana suatu sistem dapat beroperasi meskipun terjadi kesalahan pada perangkat keras atau perangkat lunak. d. Recoverability terkait dengan sejauh mana perangkat lunak, produk atau sistem dalam menangani gangguan atau kegagalan melalui pemulihan data secara langsung dan membangun kembali keadaan yang diinginkan. 6. Security menyatakan sejauh mana produk atau sistem dalam melindungi informasi dan data sehingga orang, produk, atau sistem lainnya memiliki level akses data sesuai dengan jenis dan level otorisasinya. a. Confidentiality adalah sejauh mana sistem memastikan data yang dapat diakses hanya untuk mereka yang berwenang untuk mengakses. b. Integrity mengacu pada sejauh mana sistem, produk atau komponen mencegah akses yang tidak sah untuk, atau memodifikasi perangkat lunak atau data. c. Accountability mengacu pada sejauh mana tindakan dari suatu entitas dapat ditelusuri. d. Authenticity mengacu pada klaim dan identifikasi dari akses subjek atau sumber daya permintaan kepada informasi tertentu. e. Non-repudiation dalam konsep SOA dapat diartikan sebagai kemampuan penyedia layanan untuk membuktikan bahwa informasi telah disampaikan kepada pengguna layanan. 7. Maintainability menyatakan sejauh mana produk atau sistem dapat secara efektif dan efisien dimodifikasi untuk meningkatkan, memperbaiki, atau beradaptasi dengan perubahan lingkungan sesuai kebutuhan.



40

a. Modularity adalah pendefinisian kemampuan sistem yang memiliki dampak minimal ketika terjadi perubahan pada komponen lainnya. b. Reusability menandakan suatu logika dapat digunakan pada lebih dari satu service. c. Modifiability terkait dengan kemampuan perangkat lunak untuk dapat melakukan modifikasi tanpa menimbulkan cacat pada produk yang sudah ada. d. Testability menyatakan bahwa sistem atau komponen dapat dilakukan pengujuan untuk menentukan apakah kriteria tertentu telah dipenuhi. e. Analyzability menunjukkan tingkat efektivitas dan efisiensi dengan cara penilaian terhadap dampak pada produk atau sistem atas terjadinya perubahan satu atau lebih bagian, atau untuk mendiagnosa produk atas terjadinya kegagalan, atau untuk mengidentifikasi bagian yang akan perlu untuk dimodifikasi. 8. Portability adalah kriteria kualitas yang mengutamakan efektivitas dan efisiensi suatu sistem dapat dipindahkan dari satu perangkat ke perangkat lainnya. a. Adaptability mengacu pada sejauh mana produk atau sistem, secara efektif dan efisien dapat disesuaikan untuk perangkat yang berbeda sesuai perkembangan kebutuhan perangkat lunak dan perangkat keras dan perubahan lingkungan operasional. b. Installability berhubungan dengan tingkat efektivitas dan efisiensi produk atau sistem dipasang atau dihapus dalam lingkungan operasional tertentu. c. Replaceability menunjukkan kemampuan perangkat lunak untuk dapat digantikan dengan perangkat lunak lainnya dengan fungsi yang sama dalam lingkungan yang sama.



41

2.9

Quality Function Deployment (QFD)

QFD adalah metode yang menyediakan solusi, berorientasi terhadap tujuan, fleksibel, dan fokus terhadap kebutuhan pengguna (Herzwurm & Schockert, 2003). QFD dapat diterapkan dalam membantu perencanaan, analisis data, dan pengambilan keputusan secara rasional (Carnevalli & Miguel, 2008). Metode QFD pertama kali digunakan di Jepang pada akhir 1960 ketika industri Jepang mengalami kemunduran pasca perang dunia. Metode QFD menggunakan diagram yang dikenal dengan House of Quality (HoQ) untuk mendefinisikan parameterparameter sebagai ekspetasi pengguna terhadap suatu produk. Bevilacqua, Ciarapica, & Giacchetta (2006) dan Rajesh & Malliga (2013) menjelaskan proses pembentukan HoQ yang terdiri dari beberapa elemen. Elemen tersebut antara lain: 1. Mengidentifikasi ‘WHATs’. Manfaat yang dicari dari sebuah produk atau layanan berdasarkan keinginan pelanggan itu sendiri sebagai kebutuhan pengguna dan biasanya disebut Customer Attributes (CA) atau ‘WHATs’ ditunjukkan pada wilayah (A) pada Gambar 2.16. 2. Mengidentifikasi nilai prioritas kepentingan dari kebutuhan ‘Priority of WHATs’. Berdasarkan ‘WHATs’ yang telah didefinisikan, kemudian ditetapkan prioritas kepentingannya yang ditunjukkan pada wilayah (B) pada Gambar. 2.16. 3. Menentukan bagaimana ‘HOWs’. Kriteria teknis dibentuk secara lebih spesifik dan ditentukan sebagai ‘HOWs’ dari HoQ, dan juga disebut kebutuhan terukur. ‘HOWs’ diposisikan pada wilayah (C) pada Gambar 2.16. 4. Penyusunan ‘Relationship Matrix’ (D). Sebuah tim menentukan dampak ‘WHATs’ yang mana yang berpengaruh terhadap ‘HOWs’ dan seberapa pengaruhnya. 5. Penjabaran ‘Relationship Matrix’. Hubungan fisik antara kebutuhan teknis yang ditentukan dikenal sebagai ‘The Roof Matrix’ dan ditunjukkan pada wilayah (E) pada Gambar 2.16.



42 6. Rencana aksi. Nilai pembobotan ‘Weight of HOWs’ diidentifikasi pada wilayah (F), ditempatkan pada dasar kualitas matriks. Nilai pembobotan ini merupakan keluaran HoQ. Hubungan antar elemen HoQ digambarkan pada Gambar 2.16.

Gambar 2.16 Elemen HoQ Sumber: Rajesh & Malliga (2013)

2.10 Multi Criteria Decision Analysis (MCDA) MCDA adalah suatu metode yang dapat digunakan dalam membantu pengambilan keputusan guna menetapkan pilihan, menentukan peringkat, dan pemilahan terhadap alternatif-alternatif pilihan yang tersedia berdasarkan kriteria-kriteria penentu keputusan (Whaiduzzaman et al., 2014). Konsep dasar MCDA mulai diperkenalkan pada tahun 1951 oleh Harold William Kuhn dan Albert William Tucker. Pada tahun 1972 dilaksanakan sebuah konferensi Multiple Criteria Decision Making (MCDM) di Amerika, dan sejak itu MCDA/MCDM berkembang sampai dengan saat ini. Terdapat beberapa metode yang menggunakan pendekatan metode MCDA/MCDM dalam menetapkan pilihan, pemeringkatan, dan penyortiran terhadap alternatifalternatif pilihan yang tersedia. Whaiduzzaman et al. (2014) menyebutkan metodemetode tersebut, antara lain: 1. Analytic Hierarchy Process (AHP). 2. Analytic Network Process (ANP). Universitas Indonesia


43

3. Technique for Order of Preferences by Similarity to Ideal Solution (TOPSIS). 4. Elimination and Choice Expressing Reality (ELECTRE). 5. Preference Ranking Organization METHod of Enrichment Evaluations (PROMETHEE). 6. Decision-Making Trial and Evaluation Laboratory (DEMATEL). 7. Grey Relational Analysis (GRA). 8. VIKOR. 9. Fuzzy. 10. Goal Programming. 11. Data Envelopment Analysis (DEA). Pengelompokan MCDA berdasarkan metode, tipe, kategori, dan landasan permasalahan ditunjukkan pada Gambar 2.17.

Gambar 2.17 Pengelompokan MCDA Sumber: Whaiduzzaman et al. (2014)

2.11 Analytic Hierarchy Process (AHP) AHP adalah suatu pendekatan sistematis guna pengambilan keputusan berdasarkan pengalaman, intuisi, dan heuristik dengan menggunakan suatu metodologi yang terdefinisi dengan baik atas dasar prinsip perhitungan matematika (Bhushan & Rai, 2004). Pada dasarnya AHP membantu dalam pemeringkatan, prediksi, pengukuran sesuai kebutuhan terhadap sesuatu yang rumit untuk dipecahkan. AHP Universitas Indonesia


44

dikembangkan oleh Thomas L. Saaty berdasarkan pengalaman yang diperolehnya ketika mengerjakan proyek penelitian untuk menemukan metodologi yang mudah diimplementasikan, mudah dipahami, dan mendukung pengambilan keputusan yang rumit pada US Arms Control and Disarmament Agency sekitar tahun 1970an. Fitur-fitur AHP sudah digunakan pada berbagai ranah seperti ranah bisnis, pemerintahan, ilmu sosial, penelitian dan pengembangan, pertahanan, dan ranah lainnya. AHP dapat diterapkan dalam pemeringkatan berbagai alternatif, alokasi sumber daya, rekayasa proses bisnis, balance scorecard, benchmarking, kebijakan umum, dunia kesehatan, dan sebagainya. Bhushan & Rai (2004) menjelaskan beberapa langkah penggunaan metode AHP dalam pengambilan keputusan. Langkah-langkah tersebut dijelaskan sebagai berikut: 1. Dekomposisi permasalahan menjadi suatu struktur hirarki yang terdiri atas tujuan, kriteria, subkriteria, dan alternatif-alternatif pilihan. Struktur hirarki tersebut mengindikasikan relasi antar elemen terhadap terhadap elemen-elemen di bawahnya. Gambar 2.18 menunjukkan struktur hirarki dari AHP. Struktur paling atas dari gambar hirarki adalah goal atau tujuan dari pemecahan permasalahan yang akan dianalisis, sedangkan struktur paling bawah menunjukkan alternatif-alternatif pilihan yang akan dilakukan perbandingan. Struktur antara goal dan alternatif-alternatif pilihan adalah struktur kriteria dan subkriteria.

Gambar 2.18 Struktur Hirarki dari AHP Sumber: Bhushan & Rai (2004)



45

2. Pengumpulan data dari para ahli atau pengambil keputusan sesuai dengan struktur hirarki, kemudian dilakukan perbandingan pairwise comparison dari alternatif-alternatif pilihan berdasarkan skala kualitatif. Data dari para ahli atau pengambil keputusan tersebut dilakukan penilaian berdasarkan format yang ditunjukkan pada Gambar 2.19. Huruf X pada kolom Very Strong menandakan bahwa B sangat kuat terhadap A dalam kriteria tertentu.

Gambar 2.19 Format Pairwise Comparison Sumber: Bhushan & Rai (2004)

3. Hasil dari pairwise comparison, dilakukan tabulasi menjadi suatu matriks persegi. Angka dari elemen diagonal matriks tersebut adalah 1. Kriteria pada baris ke-i lebih baik dari kriteria di kolom j jika nilai elemen (i, j) adalah lebih besar dari 1; jika kriteria di kolom j lebih baik daripada yang di baris i. Elemen (j, i) adalah kebalikan dari elemen (i, j). 4. Nilai eigen dilakukan normalisasi menjadi vektor eigen terhadap hasil dari matriks perbandingan untuk menghasilkan nilai kepentingan dari berbagai kriteria yang dibandingkan. Elemen dari vektor eigen yang sudah dilakukan normalisasi menghasilkan nilai pembobotan dari alternatif-alternatif pilihan sesuai dengan peringkat kriteria dan subkriteria 5. Melakukan evaluasi terhadap seluruh hirarki. Hasil perbandingan yang dengan metode AHP adalah subjektif dan AHP mentolerir inkonsistensi berdasarkan redundansi yang muncul. Indeks konsistensi dihitung berdasarkan rumus sebagai berikut: CI =(λmax-n)/(n-1)

(2,1)

dimana λmax adalah nilai eigen dari matriks pertimbangan. Nilai CI dapat dibandingkan dengan indeks konsistensi acak (RI). Matriks acak tersebut disajikan pada Gambar 2.20. Rasio dihasilkan dari perbandingaan CI/RI, yang disebut rasio konsistensi (CR). Saaty menyarankan nilai CR harus kurang dari 0,1. Universitas Indonesia


46

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0.00 0.00 0.58 0.90 1.12 1.24 1.32 1.41 1.45 1.49 1.51 1.48 1.56 1.57 1.59

Gambar 2.20 Indeks Konsistensi Acak 6. Nilai pembobotan dari setiap alternatif dikalikan dengan nilai pembobotan dari subkriteria dan dikumpulkan untuk mendapatkan nilai pembobotan lokal untuk setiap kriteria. Nilai pembobotan lokal kemudian dikalikan dengan nilai pembobotan dari kriteria dan dikumpulkan untuk mendapatkan nilai pembobotan global. 7. Selanjutnya, metode AHP akan menghasilkan peringkat dari setiap alternatif berdasarkan perhitungan dari satu alternatif dengan alternatif lainnya dan nilai pembobotan dari kriteria yang sama. 2.12 Proof of Concept (PoC) Menurut Molyneaux (2009), sebelum membuat komitmen untuk membeli suatu produk perangkat lunak, kita harus berhati-hati dalam membuat pilihan akhir, beliau menyarankan untuk melakukan proof of concept terlebih dahulu. POC adalah suatu istilah yang digunakan untuk menggambarkan suatu proyek yang sering dipakai dalam proses penjualan produk, dengan tujuan untuk membandingkan solusi atau sebuah perangkat lunak kepada pelanggan sehingga dapat dijadikan sebagai suatu referensi yang dapat dipahami oleh pelanggan (Molyneaux, 2009). Salah satu kegiatan dalam POC adalah performance testing. POC mampu menyediakan informasi sebagai berikut: 1. Memberikan

kesempatan

untuk

melakukan

evaluasi

secara

teknis

menggunakan alat pengujian kinerja terhadap perangkat lunak. 2. Mengidentifikasi kebutuhan data. 3. Memungkinkan penilaian terhadap perangkat lunak. 4. Menunjukkan kemampuan perangkat lunak menggunakan alat bantu pengujian kinerja sistem. Molyneaux (2009) menjelaskan beberapa langkah dalam melakukan kegiatan POC. Langkah-langkah tersebut dijelaskan sebagai berikut: Universitas Indonesia


47

1. Mengidentifikasi spesifikasi kebutuhan performance testing. 2. Pemeriksaan perangkat pengujian. 3. Mengidentifikasi kebutuhan data transaksi. 4. Pembuatan skenario pengujian. 5. Pengerjaan pengujian performa. 6. Menganalisis hasil dan laporan. 2.13 Penelitian Terdahulu Pada bagian ini akan menjelaskan tentang penelitian terdahulu yang pernah dilakukan oleh penulis lainnya. Penelitian yang dilakukan tersebut antara lain: 1. “Selecting the Best Alternative SOA Service Bus for C4I systems Using Multicriteria Decision Making Technique” (Alghamdi, Ahmad, & Nasir, 2010) Penelitian ini bertujuan untuk menentukan produk ESB yang paling tepat yang akan digunakan di kerajaan Arab Saudi dalam rangka menangani permasalahan dalam mengintegrasikan sistem “Command, Control, Communications, Computers and Intelligence” (C4I) dengan sistem pertahanan lainnya. Kandidat produk ESB yang akan dipilih adalah Mule, Fuse, and GlassFish. Metode pemeringkatan yang dipergunakan pada penelitian ini menggunakan Multi Criteria Decision Analysis (MCDA). Gambar 2.21 mengambarkan hirarki pemeringkatan ESB pada penelitian ini. Hasil penelitian mengungkapkan bahwa, kriteria yang dibutuhkan dalam pemeringkatan produk ESB antara lain: a. Interoperability, terdiri dari network, semantic, dan syntetic. b. Extensibility. c. Messaging, terdiri dari speed, security, dan reliability. d. Easiness. e. Avalability, terdiri failover, state full, dan state less.



48

Gambar 2.21 Hirarki pemeringkatan ESB untuk sistem C4I Sumber: Alghamdi, Ahmad, & Nasir (2010)

2. “Qualified Analysis b/w ESB(s) using Analytical Hierarchy Process (AHP) Method” (Siddiqui, Abdullah, & Khan, 2011) Penelitian ini bertujuan untuk melakukan analisis pemeringkatan antara produk ESB komersial dan non-komersial yang akan digunakan oleh suatu organisasi. Kandidat produk ESB yang akan dipilih adalah Oracle ESB pada produk komersial, sedangkan Mule dan Fuse pada produk non-komersial. Metode MCDA dipergunakan pada penelitian ini dengan pendekatan AHP. Hasil penelitian mengungkapkan bahwa, metode MCDA dengan pendekatan AHP dengan menggunakan kriteria information security, interoperability dan high avalaibility dapat membantu pengambil keputusan dalam melakukan pemeringkatan terhadap alternatif produk ESB yang tersedia berdasarkan kriteri-kriteria tersebut. Gambar 2.22 menggambarkan hirarki perbandingan alternatif produk ESB berdasarkan kriteri yang telah ditentukan menggunakan metode AHP.

Gambar 2.22 Hirarki AHP Qualified Analysis ESB Sumber: Siddiqui, Abdullah, & Khan (2011)



49 3. “Comparison of Enterprise Service Buses Based on Their Support of High Availability” (Astrova, Koschel, & Kruessmann, 2010) Penelitian ini melakukan perbandingan terhadap produk ESB komersial yaitu Artix, dan non-komersial, antara lain, Fuse, Mule, dan OpenESB. Tujuan penelitian ini adalah ingin mengetahui dukungan high availability dari produk ESB tersebut. Kriteria pengujian yang digunakan adalah availability dan reliability. Hasil penelitian ini mengungkapkan bahwa, pengujian secara teknis, yaitu fault tolerance penting dilakukan untuk mengetahui reliability dari produk ESB. 4. “Enterprise Service Bus: A Performance Evaluation” (Ahuja & Patel, 2011) Penelitian ini melakukan perbandingan terhadap tiga produk open source ESB. Ketiga produk ESB tersebut antara lain, Mule, WSO2 ESB, dan ServiceMix. Perbandingan dilakukan dengan melakukan pengujian scalability dan load handling, untuk mengetahui nilai mean response time dan throughput dari masing-masing produk ESB. Hasil penelitian ini mengungkapkan bahwa, pengujian secara teknis terhadap produk ESB penting untuk dilakukan guna mendapat penilaian performa ESB sesuai kebutuhan. 5. “Evaluating Open Source Enterprise Service Bus” (Jiménez, Carreras, & Skarmeta, 2010) Penelitian ini melakukan perbandingan terhadap tiga produk open source ESB. Tujuan penelitian ini adalah untuk mengevaluasi produk ESB berdasarkan fitur dan performanya dalam mengintegrasikan layanannya. Ketiga produk ESB tersebut antara lain, Fuse, Mule, dan Petals. Perbandingan berdasarkan fitur dari produk ESB yang dilakukan antara lain: a. Dukungan implementasi. b. Kemudahan dalam penggunaan. c. Dukungan terhadap grafis antarmuka pengguna. d. Dokumentasi. Sedangkan untuk mengetahui performa produk ESB, dilakukan pengujian dengan cara direct invocation experiment untuk mengetahui kemampuan Universitas Indonesia


50

integrasinya dengan menggunakan Application Programing Interface (API). Selain itu, pengujian dilakukan dengan cara Java Messaging Service (JMS) invocation experiment untuk mengetahui performanya. Hasil penelitian ini mengungkapkan bahwa, perbandingan produk ESB berdasarkan fitur dan performanya penting untuk dilakukan guna mendapat penilaian ESB secara obyektif. 6. “Web service selection on the basis of QoS parameter” (Negi & Chandra, 2014). Penelitian ini menyajikan suatu model pemilihan web service berdasarkan Quality of Service (QoS) yang dilakukan untuk memenuhi persyaratan nonfungsional. Kriteria penilaian dari QoS yang digunakan adalah response time, security, reliability, dan cost. Metode AHP dan TOPSIS digunakan untuk melakukan pembobotan berdasarkan kriteria QoS tersebut guna mendapatkan pemeringkatan web service. Model pemeringkatan kualitas web service ditunjukkan pada Gambar 2.23. Hasil penelitian mengungkapkan bahwa, metode MCDA dengan pendekatan AHP yang diintegrasikan dengan metode lainnya, dengan menggunakan kriteria response time, security, reliability, dan cost dapat membantu pengambil keputusan dalam melakukan pemeringkatan terhadap alternatif produk ESB yang tersedia berdasarkan kriteri-kriteria tersebut

Criteria

AHP

Weight

TOPSIS

Rank of web services

Decision Matrix

Gambar 2.23 Model Pemeringkatan Web Service Sumber: Negi & Chandra (2014)

7. “Supplier Selection Based on AHP QFD Methodology” (Rajesh & Malliga, 2013). Penelitian ini bertujuan untuk memilih pemasok yang tepat sesuai kebutuhan pemangku kepentingan dalam suatu perusahaan manufaktur dalam rangka meningkatkan kualitas, fleksibilitas, dan untuk mengurangi waktu produksi. Universitas Indonesia


51

Strategi pemilihan pemasok yang digunakan adalah dengan mengintegrasikan metode AHP dan QFD. QFD melakukan proses pembobotan kriteria berdasarkan kebutuhan pemangku kepentingan yang dikombinasikan dengan metode pairwise comparison dari AHP. Dari hasil pembobotan kriteria tersebut, kemudian dilakukan penilaian dan perbandingan terhadap setiap kandidat pemasok menggunakan metode AHP sehingga menghasilkan pemilihan yang optimal. Metodologi pemilihan pemasok menggunakan QFD dan AHP tersebut digambarkan pada Gambar 2.24. Hasil penelitian ini membuktikan bahwa, pendekatan dengan mengintegrasikan QFD dan AHP layak untuk diterapkan pada bidang industri lainnya dengan penyesuaian sesuai keperluan.

Gambar 2.24 Metodologi QFD AHP Pemilihan supplier Sumber: Rajesh & Malliga (2013)

8. “Quality function deployment: a tool to improve software quality” (Erikkson & McFadden, 1993). Penelitian ini menggunakan metode QFD sebagai alat bantu dalam rangka meningkatkan kualitas pengembangan perangkat lunak pada suatu laboratorium klinik bernama Metpath. Untuk mengembangkan fitur pada sistem informasi tersebut, Metpath menerapkan metode QFD dalam beberapa HoQ. Tahap pertama melakukan penentuan kebutuhan pemangku kepentingan dan prioritas terhadap

kebutuhan

tersebut.

Tahap

kedua,

dilakukan

pendefinisian



52

karakteristik perangkat lunak dan memetakannya dengan kebutuhan pemangku kepentingan yang ditunjukkan pada Gambar 2.25. Tahap ketiga dilakukan identifikasi fitur aplikasi dan kemudian memetakan karakteristik perangkat lunak dengan fitur aplikasi tersebut yang ditunjukkan pada Gambar 2.26. Tahap keempat dilakukan pendefinisian matriks produk dan memetakan fitur aplikasi dengan matriks produk tersebut. Tahap kelima dilakukan ulasan dari QFD dan perencanaan

projek

pengembangan

selanjutnya

bersama

pemangku

kepentingan.

Gambar 2.25 HoQ berdasarkan Kebutuhan dan Karakteristik Software Sumber: Erikkson & McFadden (1993)

Penelitian ini memaparkan manfaat dari penerapan metode QFD dalam membantu peningkatan kualitas pengembangan perangkat lunak yang terdiri dari: a. QFD membuat seluruh pihak yang terlibat dalam pengembangan sistem menjadi

lebih

fokus

dan

memprioritaskan

kebutuhan

pemangku

kepentingan. b. QFD mendorong untuk berpikir dalam hal pencegahan terhadap kegagalan.



53

c. QFD adalah alat komunikasi yang kuat yang memungkinkan kita untuk menetukan model diskusi diantara pemangku kepentingan, pengembang perangkat lunak, dan pihak yang terlibat lainnya. d. QFD memungkinkan kita untuk mempermudah dalam mengidentifikasi kebutuhan para pemangku kepentingan mengenai karakteristik perangkat lunak terkait fitur produk dan metrik produk. Hasil penelitian mengungkapkan bahwa, metode QFD dapat diterapkan dalam menerjemahkan kebutuhan para pemangku kepentingan dalam pemilihan perangkat lunak berdasarkan karakteristik perangkat lunak dan fitur perangkat lunak tersebut.

Gambar 2.26 HoQ berdasarkan Karakteristik dan Fitur Software Sumber: Erikkson & McFadden (1993)

9. “Fuzzy quality function deployment based methodology for acquiring enterprise software selection requirements” (Sen & Baraçli, 2010). Penelitian ini menggunakan pendekatan metode Fuzzy QFD untuk mendefinisikan prioritas persyaratan non-fungsional yang diperlukan oleh Universitas Indonesia


54

perusahaan dalam pemilihan ERP dan integrasinya dengan persyaratan fungsional. Solusi yang ditawarkan dalam penelitian ini tidak hanya membantu pengambil keputusan dalam menentukan kebutuhan perangkat lunak dan mendefinisikan kriteria pemilihan ERP, tetapi juga membantu dalam menentukan nilai prioritas kepentingan dari kriteria tersebut. Penggunaan fuzzylogic memungkinkan pengambil keputusan untuk menghilangkan, atau setidaknya menyimpan permasalahan yang berasal dari sifat informasi yang subjektif dan ambigu. Dengan menerapkan metode Fuzzy QFD pada suatu perusahaan dalam mendefinisikan dan memprioritaskan persyaratan fungsional dan non-fungsional, diharapkan dapat membantu pengambil keputusan dalam memeriksa kelemahan dan kekuatan alternatif ERP dengan membandingkannya secara tepat berdasarkan kriteria dan subkriteria. Penelitian ini membahas kebutuhan non-fungsional yang diperlukan dalam pemilihan perangkat lunak yang dibagi menjadi 3 kriteria utama, yaitu faktor teknologi, kriteria kualitas perangkal lunak, dan faktor sosial ekonomi. Kriteria utama tersebut dijelaskan sebagai berikut: a. Faktor teknologi, terdiri dari: -

Platform, yaitu platform TI yang didukung.

-

Database management system, yaitu DBMS yang didukung.

-

Languages and development tools, yaitu bahasa pemograman dan alat bantu pengembangan yang digunakan untuk memodifikasi perangkat lunak.

-

User management tools, yaitu kapabilitas pengelolaan pengguna dan kelompok pengguna, tingkat akses, aturan-aturan, dan otorisasi.

-

External connectivity, yaitu jenis konektivitas dengan eksternal yang didukung.

-

User documentation, yaitu jenis dokumentasi pengguna untuk pelatihan dan membantu dalam penggunaan perangkat lunak.

-

Technical documentation, yaitu jenis dokumentasi teknis yang menyediakan struktur perangkat lunak dan basis data. Universitas Indonesia


55

-

Versioning,

yaitu

teknik

yang

digunakan

dalam

menangani

permasalahan dari versi baru dan migrasi. -

Interface standard, kemampuan dimana komponen perangkat lunak memenuhi standar tertentu yang dapat sangat mempengaruhi interoperabilitas dan portabilitas dari sebuah sistem

-

Framework and Architecture style, yaitu jenis infrastruktur yang menyediakan penggabungan komponen yang berbeda seperti object request broker, message bus, dan basis data.

b. Kriteria kualitas perangkat, terdiri dari: - Portability terdiri dari adaptability, conformance, Installability, dan replaceability. - Maintability terdiri dari analyzability, changeability, stability, dan testability. - Efficiency terdiri dari resource behaviour dan time behaviour - Usability terdiri dari learnability, operatability, dan understandability. - Reliability terdiri dari fault tolerance, maturity, dan recoverability. - Functionality terdiri dari accuracy, compliance, interoperatability, security, dan suitability. c. Faktor sosial ekonomi, terdiri dari: -

Kriteria bisnis.

-

Kapabilitas dari penyedia perangkat lunak.

Berdasarkan penelitian-penelitian tersebut, kemudian dilakukan analisis tentang hal-hal penting meliputi komparasi, perbedaan, tanggapan, rangkuman, dan relevansinya dengan KA. Analisis tersebut dapat dilihat pada Tabel 2.2.



56

Tabel 2.2 Analisis antar Penelitian Terdahulu Judul “Selecting the Best Alternative SOA Service Bus for C4I systems Using Multicriteria Decision Making Technique” (Alghamdi, Ahmad, & Nasir, 2010)

Komparasi Penelitian ini melakukan perbandingan terhadap perangkat lunak, yaitu produk ESB menggunakan metode MCDA.

Perbedaan Kriteria yang digunakan dalam penelitian ini meliputi interoperability, extensibility, messaging, easiness, dan avalability

Tanggapan Metode MCDA membuktikan bisa membantu dalam menentukan produk ESB yang tepat sesuai kebutuhan, tetapi tidak dijelaskan metode pengumpulan datanya.

“Qualified Analysis b/w ESB(s) using Analytical Hierarchy Process (AHP) Method” (Siddiqui, Abdullah, & Khan, 2011).

Penelitian ini membahas tentang perbandingan antara produk ESB menggunakan metode MCDA, yaitu AHP.

Kriteria kualitas ESB yang digunakan adalah information security, interoperability dan high avalaibility.

Pengukuran hanya dilakukan terhadap keberadaan fitur yang dimiliki dan atas dasar tinjauan literatur, akan lebih tepat jika memasukan pengukuran terhadap faktor teknis yaitu performa produk.

“Comparison of Enterprise Service Buses Based on Their Support of High Availability” (Astrova, Koschel, & Kruessmann, 2010))

Penelitian ini membahas perbandingan perangkat lunak antara produk ESB komersial dan nonkomersial.

Pengujian secara teknis dilakukan dalam penelitian ini untuk membuktikan dukungan high availability dari produk ESB

Metode yang dilakukan hanya secara teknis, akan lebih baik jika melakukan pengujian berdasarkan kriteria non teknis dengan menggunakan metode pemeringkatan.

Rangkuman Penelitian ini bertujuan untuk menentukan produk ESB yang paling tepat digunakan dalam rangka mengintegrasikan sistem pertahanan negara dengan sistem pertahanan lainnya menggunakan metode MCDA berdasarkan kriteria interoperability, extensibility, messaging, easiness, dan avalability. Penelitian ini bertujuan untuk menentukan produk ESB yang tepat digunakan oleh suatu organisasi menggunakan metode AHP berdasarkan kriteria information security, interoperability dan high avalaibility. Penelitian ini membahas perbandingan terhadap produk menggunakan pengujian teknis, yaitu fault tolerance testing untuk mengetahui high availability dari ESB

Relevansi dengan KA Penggunaan metode MCDA bersamaan beberapa kriteria yang memengaruhi pemeringkatan ESB.

Kriteria kualitas perangkat lunak digunakan sebagai kriteria penilaian dalam metode AHP dalam KA ini.

Pengujian teknis sebagai persyaratan non-fungsional perangkat lunak dilakukan dalam KA ini.



57

Tabel 2.2 Analisis antar Penelitian Terdahulu (sambungan) Judul “Enterprise Service Bus: A Performance Evaluation” (Ahuja & Patel, 2011)

Komparasi Penelitian ini membahas perbandingan terhadap produk ESB

Perbedaan Perbandingan dilakukan dengan melakukan pengujian scalability dan load handling, untuk mengetahui nilai mean response time dan throughput dari masingmasing produk ESB.

“Evaluating Open Source Enterprise Service Bus” (Jiménez, Carreras, & Skarmeta, 2010)

Penelitian ini membahas perbandingan terhadap produk ESB

“Web service selection on the basis of QoS parameter” (Negi & Chandra, 2014)

Penelitian ini membahas pemeringkatan web service menggunakan metode AHP untuk menentukan pembobotan terhadap Quality of Service

Perbandingan dilakukan dengan melakukan perbandingan fitur dan pengujian Direct Invocation Experiment dan JMS Invocation Experiment untuk mengetahui performa ESB Perbandingan dilakukan dengan melakukan perbandingan terhadap empat kriteria (response time, security, reliability, dan cost), dan mengintegrasikan metode AHP dengan TOPSIS digunakan untuk pemeringkatan terhadap kebutuhan pengguna.

Tanggapan Pengujian teknis scalability dan load handling terhadap produk ESB mendapatkan hasil yang relevan secara statistik, tetapi tidak dijelaskan aplikasi yang digunakan dalam melakukan pengujian. Bahwa pengujian response time penting dilakukan untuk mengetahui performa ESB, tetapi tidak dijelaskan aplikasi yang digunakan dalam melakukan pengujian

Rangkuman Penelitian ini membahas perbandingan secara kualitatif and kuantitatif terhadap produk open source ESB menggunakan pengujian secara teknis, yang meliputi Scalability Test dan Load Handling Test.

Relevansi dengan KA Pengujian performa sebagai persyaratan non-fungsional perangkat lunak secara teknis dilakukan dalam KA ini.

Tujuan penelitian ini adalah untuk mengevaluasi produk ESB berdasarkan fitur dan performanya dalam mengintegrasikan layanannya.

Pengujian response time untuk mengetahui performa fitur ESB teknis dilakukan dalam KA ini.

Akan lebih baik jika menambahkan kriteria lainnya.

Penelitian ini menawarkan suatu model untuk memilih web service berdasarkan pemeringkatan QoS yang dilakukan untuk memenuhi persyaratan non-fungsional. Kriteria QoS terdiri atas response time, security, reliability, dan cost.

Kriteria kualitas ESB digunakan sebagai kriteria penilaian dalam metode AHP dalam KA ini.



58

Tabel 2.2 Analisis antar Penelitian Terdahulu (sambungan) Judul “Supplier Selection Based on AHP QFD Methodology” (Rajesh & Malliga, 2013)

Komparasi Penerapan metode AHP dalam menentukan suatu pilihan dari beberapa alternatif pilihan.

Perbedaan Integrasi metode AHP dengan QFD. QFD melakukan proses pembobotan kriteria berdasarkan kebutuhan pemangku kepentingan yang dikombinasikan dengan metode pairwise comparison dari AHP. Kriteria yang digunakan adalah quality, cost, dan delivery.

Tanggapan Penelitian ini membuktikan bahwa pendekatan dengan mengintegrasikan QFD dan AHP layak untuk diterapkan pada bidang industri lainnya dengan penyesuaian sesuai keperluan, tetapi tidak dijelaskan metode pengumpulan datanya.

Rangkuman Penelitian ini bertujuan untuk memilih pemasok yang tepat sesuai kebutuhan pemangku kepentingan pada perusahaan manufaktur untuk meningkatkan kualitas, fleksibilitas, dan untuk mengurangi waktu produksi berdasarkan kriteria quality, cost, dan delivery dengan penerapan metode AHP dan QFD.

Relevansi dengan KA Setiap tahapan dari penerapanan integrasi metode AHP dan QFD dilakukan dalam KA ini.

“Quality function deployment: a tool to improve software quality” (Erikkson & McFadden, 1993)

Penelitian ini membahas proses dalam menentukan kriteria yang diperlukan dalam suatu perangkat lunak berdasarkan kebutuhan pemangku kepentingan.

Penerapan metode QFD dalam menentukan pembobotan kriteria

Diperoleh tahapan dalam penerapanan metode QFD dalam pengembangan perangkat lunak, akan lebih baik jika penentuan karakterisitk teknologi dilakukan pada tahap pertama.

Penelitian ini memaparkan manfaat dari penerapan metode QFD dalam membantu peningkatan kualitas pengembangan perangkat lunak.

Pengadopsian tahapan dari penerapanan metode QFD dalam menentukan kriteria yang diperlukan dalam suatu perangkat lunak

“Fuzzy quality function deployment based methodology for acquiring enterprise software selection requirements” (Sen & Baraçli, 2010)

Penelitian ini membahas proses dalam memilih perangkat lunak, yaitu ERP berdasarkan kriteria kualitas dan teknologi.

Penerapan metode Fuzzy QFD dalam mendefinisikan prioritas kriteria yang terdiri dari quality characteristics, technology factors, dan socio-economic factors.

Penentuan karakterisitk teknologi dilakukan bersamaan dengan karakterisitk kualitas, akan lebih baik jika dilakukan secara berurutan.

Penelitian ini menyajikan pendekatan metode Fuzzy QFD untuk mendefinisikan prioritas yang diperlukan dalam pemilihan ERP.

Penerapan QFD sebagai metode untuk menentukan prioritas faktor teknologi yang diperlukan pemangku kepentingan



59

2.14 Kerangka Pemikiran Berdasarkan landasan teori dan hasil analisis penelitian terdahulu, ditemukan beberapa informasi yang dapat dijadikan masukan terhadap penelitian ini. Selain itu, terdapat persamaan metode penilaian, pengujian, dan kriteria yang akan digunakan dalam proses pemeringkatan produk middleware ESB di BPJS Kesehatan. Masukan dan persamaan metode penilaian, pengujian, dan kriteria tersebut dijelaskan sebagai berikut: 1. Menurut Erikkson & McFadden (1993), penentuan nilai pembobotan dari setiap karakteristik perangkat lunak yang diperlukan bisa menggunakan metode QFD, dengan tahapan sebagai berikut: a. Mendefinisikan kebutuhan pemangku kepentingan. b. Mendefinisikan karakteristik perangkat lunak berdasarkan kebutuhan pemangku kepentingan yang sudah dilakukan pada tahap pertama. Pada tahap

ini

dilakukan

pembobotan

terhadap

kebutuhan

pemangku

kepentingan. HoQ pada tahap ini ditunjukkan pada Gambar 2.25. c. Mendefinisikan fitur produk berdasarkan karakteristik perangkat lunak yang sudah dilakukan pada tahap kedua. HoQ pada tahap ini ditunjukkan pada Gambar 2.26. 2. Menurut Sen & Baraçli (2010), kebutuhan non-fungsional dari pemeringkatan perangkat lunak antara lain faktor teknologi dan kriteria kualitas perangkat lunak. Selain itu menurutnya metode QFD dapat digunakan untuk menentukan kriteria yang diperlukan untuk pemilihan perangkat lunak dan faktor teknologi yang berpengaruh terhadap pemenuhan kebutuhan teknis perangkat lunak terdiri dari platform, database management system, languages and development tools, user management tools, external connectivity, user documentation, technical documentation, versioning, interface standard, dan framework and architecture style. 3. Menurut Siddiqui, Abdullah, & Khan (2011), kriteria penilaian kualitas ESB yang dapat digunakan antara lain adalah information security, interoperability dan high avalaibility. Menurut Alghamdi, Ahmad, & Nasir (2010), kriteria yang Universitas Indonesia


60

digunakan antara lain interoperability, extensibility, messaging, easiness, dan avalability; sedangkan menurut Sener & Karsak (2012), kriteria yang dapat digunakan untuk penilaian kualitas perangkat lunak antara lain scalability, reliability, speed, accuracy, easy to use. Menurut Franca & Soares (2015), kriteria yang dapat digunakan dalam menilai kualitas aplikasi SOA, bisa menggunakan model kualitas SOAQM yang terdiri dari functional suitability, performance

efficiency,

compatibility,

usability,

reliability,

security,

maintainability, portability, dan subkriterianya. 4. Menurut Astrova, Koschel, & Kruessmann (2010), Ahuja & Patel (2011), dan Jiménez, Carreras, & Skarmeta (2010) pengujian secara teknis pada ESB penting untuk dilakukan untuk mengetahui performa produk ESB tersebut. 5. Menurut Negi & Chandr (2014), Siddiqui, Abdullah, & Khan (2011), Alghamdi, Ahmad, & Nasir (2010), metode MCDA, yaitu AHP, dapat digunakan untuk pemeringkatan perangkat lunak berdasarkan kriteria kualitasnya. 6. Menurut Rajesh & Malliga (2013), penerapan metode QFD yang diintegrasikan dengan metode AHP digunakan untuk menentukan pilihan atau prioritas dari berbagai alternatif pilihan. 7. Ahuja & Patel (2011) menyatakan bahwa pengujian terhadap ESB digunakan untuk mengetahui kinerja dan efisiensi perangkat lunak. Pengujian tersebut terdiri dari response time dan throughput. Berdasarkan masukan dan persamaan metode di atas, penelitian ini akan mengkombinasikan landasan teori dengan metode penilaian, dan kriteria yang digunakan penelitian terdahulu agar analisis dilakukan secara komprehensif. Kombinasi tersebut dijabarkan sebagai berikut: 1. Metode yang dipakai dalam pemeringkatan produk middleware ESB menggunakan QFD yang dikombinasikan dengan AHP. Metode ini penulis gunakan berdasarkan pengalaman dari penelitian Rajesh & Malliga (2013), dimana kombinasi QFD dan AHP bisa menghasilkan nilai yang lebih akurat berdasarkan kebutuhan pemangku kepentingan dalam organisasi. Universitas Indonesia


61

2. Faktor teknologi menggunakan faktor-faktor teknologi dalam penelitian Sen & Baraçli (2010), yang terdiri dari platform, database management system, languages and development tools, user management tools, external connectivity, user documentation, technical documentation, versioning, interface standard, dan framework and architecture style. 3. Kriteria kualitas perangkat lunak yang digunakan mengadopsi penelitian Franca & Soares (2015), yaitu berdasarkan model kualitas SOAQM yang merupakan turunan dari model kualitas ISO 25010 yang dirancang khusus untuk diterapkan pada aplikasi SOA. 4. Model HoQ pada metode QFD mengadopsi penelitian Erikkson & McFadden (1993). Berikut penjabaran dari HoQ tersebut: a.

Penentuan nilai pembobotan dari faktor teknologi pada HoQ 1. ‘WHATs’ pada HoQ 1 terdiri dari kebutuhan pemangku kepentingan, yang kemudian dilakukan pembobotan terhadap ‘WHATs’ pada ‘Priority of WHATs’ dengan mengadopsi penelitian Rajesh & Malliga (2013) yaitu dengan menggunakan metode AHP. ‘HOWs’ terdiri dari faktor teknologi. HoQ 1 menghasilkan nilai prioritas kepentingan dari faktor teknologi yang tertuang dalam ‘Weight of HOWs’ pada HoQ1.

b.

Penentuan nilai pembobotan dari kriteria kualitas perangkat lunak pada HoQ 2. ‘WHATs’ pada HoQ 2 terdiri dari faktor teknologi berdasarkan ‘HOWs’ pada HoQ 1 yang selanjutnya ‘Priority of WHATs’ pada HoQ 2 terdiri dari prioritas kepentingan dari fitur yang dimiliki produk perangkat lunak sebagai keluaran dari ‘Weight of HOWs’ pada HoQ1. Isi dari ‘HOWs’ berisi kriteria kualitas perangkat lunak. HoQ 2 menghasilkan nilai prioritas kepentingan dari kriteria kualitas perangkat lunak yang tertuang dalam ‘Weight of HOWs’ pada HoQ 2.



62

5. Kriteria kualitas perangkat lunak yang sudah ditentukan nilai prioritas kepentingannya, selanjutnya dilakukan perbandingan terhadap alternatifalternatif produk middleware ESB yang tersedia dengan mengadopsi penelitian Siddiqui, Abdullah, & Khan, (2011) yaitu dengan metode AHP. Selain itu, pengujian performa terhadap alternatif-alternatif produk middleware ESB dilakukan berdasarkan penelitian Ahuja & Patel (2011) untuk mengetahui performa dari ESB yang tersedia. Gambar 2.27 menunjukkan kerangka pemikiran penelitian untuk menghasilkan produk middleware ESB yang paling tepat digunakan BPJS Kesehatan dalam rangka mengoptimalkan integrasi SIM. Penulis menganalisis dan mengambil pengalaman dari penelitian sejenis yang sebelumnya pernah dilakukan pada organisasi lain di negara lain. Selain itu, penulis menganalisis kebutuhan berdasarkan pendapat dari pemangku kepentingan mengenai pemilihan produk middleware ESB yang paling tepat. Kriteria Kualitas Perangkat LunakSOAQM

Faktor Teknologi

Quality Function Deployment (QFD)

Produk middleware Enterprise Service Bus (ESB) yang paling tepat

Analytic Hierarchy Process (AHP)

Pendapat Pemangku Kepentingan

Gambar 2.27 Kerangka Pemikiran Penelitian Terdapat 5 komponen yang berpengaruh dalam melakukan analisis pemeringkatan produk middleware ESB pada penelitian ini, yaitu: 1. Pendapat pemangku kepentingan, merupakan informasi penting dalam mendefinisikan kebutuhan non-fungsional, kriteria, dan nilai prioritas kepentingannya untuk menghasilkan ESB yang paling tepat digunakan BPJS Kesehatan. Universitas Indonesia


63

2. Faktor teknologi, sebagai kriteria teknis dalam menerjemahkan kebutuhan nonfungsional pemangku kepentingan. Faktor teknologi tersebut diberikan kepada pemangku kepentingan untuk dilakukan penentuan nilai pembobotannya dan keterhubungannya dengan kebutuhan non-fungsional. 3. Kriteria kualitas perangkat lunak, menggunakan model kualitas SOAQM yang merupakan turunan dari model kualitas ISO 25010 yang spesifik diterapkan pada konsep SOA. Kriteria kualitas perangkat lunak tersebut diberikan kepada pemangku kepentingan untuk dinilai keterhubungannya dengan faktor teknologi. 4. QFD, yaitu metode untuk menerjemahkan kebutuhan pemangku kepentingan menjadi sekumpulan informasi yang dapat diterima oleh pemangku kepentingan sebagai kriteria yang memengaruhi pemeringkatan produk middleware ESB. 5. AHP, yaitu metode untuk menentukan nilai prioritas kepentingan atas kebutuhan non-fungsional dari pemangku kepentingan dan pemeringkatan produk middleware ESB berdasarkan kriteria-kriteria yang telah didefinisikan.



BAB 3 METODOLOGI PENELITIAN

Bab ini menjelaskan rancangan penelitian, instrumen penelitian, perancangan model QFD dan AHP, dan metode pengumpulan data yang digunakan selama penelitian. Selain itu, Bab ini dilengkapi kebutuhan masukan dan keluaran pada setiap tahapan. 3.1

Rancangan Penelitian

Penelitian ini termasuk ke dalam policy research, karena penelitian ini menghasilkan alternatif pilihan guna mempermudah dalam pengambilan keputusan. Alternatif pilihan tersebut adalah produk middleware ESB yang akan dipergunakan di BPJS Kesehatan. Selain itu, penelitian ini termasuk juga ke dalam action research karna data yang diambil berdasarkan pendapat dari seseorang; dan case study research karna mengambil studi kasus di BPJS Kesehatan. Berdasarkan data yang diolah, penelitian ini termasuk sebagai penelitian kuantitatif dan kualitatif. Rancangan penelitian dimulai dengan pengumpulan data awal dan diakhiri dengan penyusunan kesimpulan dan saran yang merupakan penjabaran dari kerangka pemikiran yang telah digambarkan pada Gambar 2.27. Tahapan-tahapan penelitian yang dilakukan dalam penelitian ditunjukkan pada Gambar 3.1. Berikut ini dijabarkan tahapan-tahapan yang dilakukan dalam penelitian ini. 1. Pengumpulan data awal Tahap awal penelitian ini dimulai dengan melakukan pengumpulan data mengenai permasalahan pada Direktorat TI BPJS Kesehatan. Tahap ini dilakukan untuk mendukung identifikasi permasalahan yang akan diangkat dalam penelitian ini. Pengumpulan data dilakukan dengan cara observasi dokumentasi dan kondisi TI dimana lokasi studi kasus diambil, dilanjutkan dengan wawancara terhadap beberapa pengembang SIM dan pejabat di

64



65

lingkungan Direktorat TI. Hasil tahapan ini adalah data harapan dan kenyataan yang dijabarkan pada subbab “Identifikasi Masalah” dalam bab “Pendahuluan”. 2. Identifikasi masalah Pendefinisian permasalahan dilakukan berdasarkan data harapan dan kenyataan dari tahapan sebelumnya. Untuk memetakan sumber permasalahan, dilakukan analisis permasalahan yang disajikan dalam bentuk analisis diagram Ishikawa (diagram tulang ikan). Dari beberapa sumber permasalahan tersebut, penulis memilih salah satu sumber permasalahan yang paling kritis untuk dianalisis solusinya dan dijadikan pertanyaan penelitian yang akan dijawab dalam penelitian. Hasil dari tahapan ini adalah diagram Ishikawa, pertanyaan, tujuan, manfaat, dan batasan penelitian yang dijabarkan dalam bab “Pendahuluan”. 3. Studi literatur Studi literatur dilakukan berdasarkan identifikasi masalah dan pertanyaan penelitian yang diperoleh dari tahapan sebelumnya. Studi literatur digunakan untuk menganalisis berbagai teori dan metodologi yang berhubungan dengan topik penelitian yang meliputi arsitektur aplikasi, integrasi arsitektur, infrastruktur TI, SOA, middleware, web service, ESB, model kualitas perangkat lunak, metode-metode yang digunakan dalam penelitian, dan referensi lainnya serta analisis penelitian sejenis yang pernah dilakukan sebelumnya yang meliputi komparasi, perbedaan, tanggapan, rangkuman, dan relevansinya dengan penelitian ini. Selanjutnya dilakukan penyusunan kerangka pemikiran yang mendasari keseluruhan penelitian yang terdiri dari berbagai teori dan metodologi yang menjadi acuan penelitian. Hasil tahapan ini adalah kerangka pemikiran dijabarkan pada subbab “Kerangka Pemikiran” dalam bab “Tinjauan Pustaka”. 4. Metodologi Penelitian Pada tahap ini disusun rancangan penelitian secara keseluruhan dari awal sampai akhir berdasarkan kerangka pemikiran, yang meliputi dan perancangan model QFD dan AHP, penyusunan metode pengumpulan data dan penyusunan instrumen pengumpulan data. 5. Pengumpulan Data Universitas Indonesia


66

Pengumpulan data dilakukan berdasarkan instrumen dan metode pengumpulan data yang telah disusun pada tahap sebelumnya. Metode pengumpulan data yang dilakukan berupa observasi dokumentasi, wawancara, Focus Group Discussion (FGD), dan performance testing pada perangkat lunak. Hasil tahapan ini adalah transkrip wawancara dan FGD, service performance report. 6. Analisis data Pada tahap ini dilakukan analisis data untuk menentukan peringkat akhir berdasarkan kriteria dan alternatif produk middleware ESB dengan metode QFD dan AHP yang meliputi penentuan ‘WHATs’, ‘Priority of WHATs’, ‘HOWs’, ‘weight of HOWs’, ‘Relationship matrix’, pairwise comparison, perbandingan antar kriteria, dan perbandingan alternatif. Tahap ini telah dapat teridentifikasi peringkat produk middleware ESB yang dapat digunakan oleh Direktorat TI BPJS Kesehatan. Hasil dari tahap ini adalah nilai prioritas kepentingan dari setiap kriteria berdasarkan model HoQ QFD dan Hirarki AHP, dan peringkat produk middleware ESB. 7. Penyusunan kesimpulan dan saran. Pada tahapan ini, dilakukan penyusunan kesimpulan penelitian yang dihasilkan dari analisis dan kajian yang telah dilakukan yang diharapkan menjawab pertanyaan penelitian. Saran yang diperoleh dari pembelajaran keseluruhan proses penelitian ditujukan kepada BPJS Kesehatan maupun bagi penelitian serupa atau lanjutan.



67

Masukan

Tahapan

Keluaran

Metode

Mulai

Dokumen organisasi

Pengumpulan data awal

Kesenjangan antara harapan dan kenyataan

Identifikasi masalah

Pertanyaan penelitian, teori dan metodologi terkait permasalahan, dan penelitian terdahulu Kerangka pemikiran

Studi literatur

Metodologi penelitian

Instrumen dan metode pengumpulan data

Pengumpulan data

Trankrip wawancara dan FGD, service performance report

Analisis data

Penyusunan kesimpulan dan saran

Peringkat ESB

Kesenjangan antara harapan dan kenyataan

Observasi dokumen dan wawancara

Diagram Ishikawa dan pertanyaan, tujuan, manfaat, dan batasan penelitian

Analisis Diagram Ishikawa

Kerangka pemikiran

Analisis teori, metodologi, dan penelitian terdahulu

Rancangan penelitian, Model HoQ QFD dan hirarki AHP, metode dan instrumen pengumpulan data

Mengembangkan kerangka pemikiran

Trankrip wawancara dan FGD, service performance report

FGD, POC, dan performance testing

Prioritas kepentingan setiap kriteria berdasarkan model HoQ QFD dan Hirarki AHP, dan peringkat ESB

Pairwise comparison, menentukan relationship matrix, melakukan pembobotan kriteria dan perbandingan alternatif

Saran perbaikan

Menyusun kesimpulan dan saran

Selesai

Gambar 3.1 Metodologi Penelitian 3.2

Perancangan Model HoQ QFD dan Hirarki AHP

Penelitian ini akan mengkombinasikan landasan teori, metode, dan kriteria pemilihan perangkat lunak pada penelitian terdahulu menjadi suatu model kerangka pemeringkatan tersendiri. Model tersebut menjadi dasar dalam penyusunan instrumen penelitian dan selanjutnya digunakan sebagai acuan pemeringkatan terhadap produk middleware ESB berdasarkan penerapan metode QFD yang diintegrasikan dengan metode AHP. Integrasi dari metode QFD dan AHP dilakukan karena metode QFD mampu menerjemahkan kebutuhan pemangku kepentingan dan mampu menghasilkan nilai pembobotan dari kebutuhan non-fungsional yang telah ditentukan, sedangkan metode AHP mampu membantu pengambil keputusan dalam melakukan pemeringkatan dari berbagai alternatif pilihan. Kebutuhan non-fungsional yang diperlukan dalam pemeringkatan produk middleware ESB terdiri dari faktor teknologi dan kualitas perangkat lunak. Masukan dalam menentukan kriteria dari faktor teknologi diperoleh dari penelitian Sen & Baraçli (2010). Setiap faktor teknologi yang perangkat lunak diberi kode dan disajikan pada Tabel 3.1. Universitas Indonesia


68

Tabel 3.1 Daftar Faktor Teknologi Kode

Faktor Teknologi

T1

Platform

T2

Database management system

T3

Languages and development tools

T4

User management tools

T5

External connectivity

T6

User documentation

T7

Technical documentation

T8

Versioning

T9

Interface standard

T10

Framework and architecture style

Kriteria kualitas perangkat lunak dapat terwakili oleh atribut yang terdapat pada model kualitas SOAQM. Pemilihan model kualitas tersebut dilakukan karena SOAQM adalah model kualitas perangkat lunak yang diaplikasikan secara khusus pada konsep SOA. Kriteria-kriteria penting dari kualitas perangkat lunak diberi kode dan disajikan pada Tabel 3.2. Tabel 3.2 Daftar Kriteria Kualitas Perangkat Lunak Kode

Q1

Q2

Q3

Kriteria

Kode

Subkriteria

Q1.1

Functional completeness

Q1.2

Functional correctness

Q1.3

Functional appropriateness

Performance

Q2.1

Time behaviour

efficiency

Q2.2

Resource utilization

Q3.1

Co-existence

Q3.2

Interoperability


Compatibility



69

Tabel 3.2 Daftar Kriteria Kualitas Perangkat Lunak (sambungan) Kode

Q4

Q5

Q6

Q7

Q8

Kriteria

Kode

Subkriteria

Q4.1

Appropriateness recognizability

Q4.2

Learnability

Q4.3

Operability

Q4.4

User error protection

Q5.1

Maturity

Q5.2

Availability

Q5.3

Fault tolerance

Q5.4

Recoverability

Q6.1

Confidentiality

Q6.2

Integrity

Q6.3

Accountability

Q6.4

Authenticity

Q6.5

Non-repudiation

Q7.1

Modularity

Q7.2

Reusability

Q7.3

Modifiability

Q7.4

Testability

Q7.5

Analyzability

Q8.1

Adaptability

Q8.2

Installability

Q8.3

Replaceability

Usability

Reliability

Security

Maintainability

Portability

Model pemeringkatan produk middleware ESB berdasarkan metode QFD dan AHP ditunjukkan pada Gambar 3.2.



70

HoQ HoQ 11

HoQ HoQ 22

‘Relationship Matrix’

‘HOWs’ ‘HOWs’

‘WHATs’ ‘WHATs’

Priority of ‘WHATs’

D Q FF D Q

‘WHATs’ ‘WHATs’

Priority of ‘WHATs’

‘HOWs’ Faktor Teknologi Teknologi ‘HOWs’ Faktor

‘Relationship Matrix’

Weight of ‘HOWs’

CA1 1,00 CA2

H PP AH A

CA3 … …

…

…

?

?

?

?

?

?

1,00

?

?

?

?

?

1,00

?

?

?

?

1,00

?

?

?

1,00

CAn

CAn Nilai Eigen

?

?

1,00

?

SOAQM

Weight of ‘HOWs’

Pairwise Pairwise Comparation Comparation A AH H PP

CA1 CA2 CA3

Kriteria Kriteria Kualitas Kualitas Perangkat Perangkat Lunak Lunak

Produk ESB yang tepat


Compatibility


-Functional -Functional completeness completeness -Functional -Functional correctness correctness -Functional -Functional appropriateness appropriateness

ESB ESB II

Usability

-Co-existence -Co-existence -Interoperability -Interoperability

-Time -Time behaviour behaviour -Resource -Resource utilization utilization -Capacity -Capacity

Reliability

Security

-Maturity -Maturity -Availability -Availability -Fault -Faulttolerance tolerance -Recoverability -Recoverability

-Appropriateness -Appropriateness recognizability recognizability -Operability -Operability -Learnability -Learnability -User -Usererror error protection protection

ESB ESB IIII

Maintainability

Portability

-Modularity -Modularity -Reusability -Reusability -Modifiability -Modifiability -Testability -Testability -Analyzability -Analyzability

-Confidentiality -Confidentiality -Integrity -Integrity -Accountability -Accountability -Authenticity -Authenticity -Non -Non repudiation repudiation

ESB ESB III III

-Adaptability -Adaptability -Installability -Installability -Replaceability -Replaceability

ESB ESB IV IV

Gambar 3.2 Model Pemeringkatan Produk Middleware ESB Perancangan HoQ pada metode QFD terdiri dari 2, yaitu HoQ 1 dan dan HoQ 2. HoQ 1 berfungsi untuk mendapatkan nilai pembobotan dari masing-masing faktor teknologi, sedangkan HoQ 2 berfungsi untuk mendapatkan nilai pembobotan dari masing-masing kriteria kualitas perangkat lunak. Metode pairwise comparation dari AHP diterapkan sebanyak 2 kali, yaitu pada tahapan penentuan nilai prioritas kepentingan ‘Priority of WHATs’ pada HoQ 1, dan pada tahapan penentuan nilai pembobotan dari subkriteria kualitas perangkat lunak. Selanjutnya dilakukan penilaian terhadap alternatif-alternatif pilihan produk middleware ESB berdasarkan subkriteria kualitas perangkat lunak yang telah ditetapkan nilai pembobotannya.



71

Tahapan-tahapan dari analisis data berdasarkan model QFD dan AHP ditunjukkan pada Gambar 3.3. Mulai Quality Function Deployment HoQ 1

Analytic Hierarchy Process

HoQ 2

Mengidentifikasi WHATs

Pendaftaran WHATs

Melakukan Pembobotan kriteria

Penentuan priority of WHATs

Penentuan Priority of WHATs

Penilaian terhadap Alternatif

Penentuan HOWs

Pendaftaran HOWs

Melakukan Pembobotan Alternatif terhadap kriteria

Penentuan Relationship Matrix

Penentuan Relationship Matrix

Selesai

Penentuan Weight of HOWs

Penentuan Weight of HOWs

Pairwise comparison

Gambar 3.3 Tahapan Model Pemeringkatan Produk Middleware ESB Berikut ini dijabarkan tahapan-tahapan dari analisis data berdasarkan model QFD dan AHP tersebut. 1. Mengidentifikasi ‘WHATs’ pada HoQ 1. Pada tahap ini dilakukan identifikasi kebutuhan yang diinginkan dari produk middleware ESB menurut pemangku kepentingan ‘customer attributes’. Identifikasi kebutuhan tersebut dilakukan melalui proses wawancara terhadap pejabat di lingkungan Direktorat TI BPJS Kesehatan. Kebutuhan yang sudah diperoleh, dipilih hanya kebutuhan non-fungsional yang mampu memenuhi kebutuhan pemangku kepentingan terhadap pemilihan produk middleware ESB. Kebutuhan non-fungsional tersebut dituangkan dalam daftar ‘WHATs’ pada HoQ 1 ini dan merupakan hasil dari tahap ini. 2. Penentuan ‘Priority of WHATs’ pada HoQ 1. Universitas Indonesia


72

Dari kebutuhan non-fungsional yang sudah didefinisikan pada tahap sebelumnya, selanjutnya dilakukan penilaian prioritas kepentingan ‘Priority of WHATs’ terhadap kebutuhan pemangku kepentingan dengan mengadopsi perhitungan pairwise comparison metode AHP. Tahap ini dilakukan pada FGD yang pertama yang dihadiri para pemangku kepentingan yang terdiri dari pengembangan SI/TI dan pejabat yang berwenang dalam pengambilan keputusan di lingkungan Direktorat TI BPJS Kesehatan. Hasil dari tahap ini adalah daftar nilai prioritas kepentingan ‘Priority of WHATs’ kebutuhan nonfungsional dari pemangku kepentingan. 3. Penentuan ‘HOWs’ pada HoQ 1. Masih dalam FGD yang pertama, selanjutnya dilakukan penentuan kriteria teknis untuk memenuhi kebutuhan non-fungsional dari pemangku kepentingan yang terdapat dalam ‘WHATs’. Masukan kriteria diperoleh dari faktor teknologi yang dimiliki perangkat lunak yang disajikan pada Tabel 3.1. Faktor teknologi tersebut tertuang dalam ‘HOWs’ pada HoQ 1 yang merupakan hasil dari tahap ini. 4. Penentuan ‘Relationship Matrix’ pada HoQ 1. Setelah ‘WHATs’ dan ‘HOWs’ ditentukan, masih pada FGD yang pertama, selanjutnya ditentukan nilai keterhubungan keduanya dimana setiap hubungan diberi nilai pada ‘Relationship Matrix’. Keterhubungan tersebut merupakan dampak ‘WHATs’ yang mana yang berpengaruh terhadap ‘HOWs’ dan seberapa pengaruhnya. Tabel 3.3 menunjukkan tabulasi keterhubungan kebutuhan non-fungsional dan faktor teknologi yang harus ditentukan. Nilai keterhubungan antara ‘WHATs’ dan ‘HOWs’ ditentukan berdasarkan notasi yang digambarkan dalam matriks yang ditampilkan pada Tabel 3.4. Hasil dari tahap ini adalah daftar nilai keterhubungan ‘Relationship Matrix’ antara kebutuhan non-fungsional dari pemangku kepentingan dalam ‘WHATs’ dan faktor teknologi dalam ‘HOWs’.



73

Tabel 3.3 HoQ Relasi Kebutuhan Non-fungsional dan Faktor Teknologi Faktor Teknologi T1

T2

T3

.

.

Tn

Kebutuhan Non-fungsional

CA1 CA2 CA3 . . . CAn Tabel 3.4 Nilai Keterhubungan antar ‘WHATs’ dan ‘HOWs’ QFD Rasio Dampak

Notasi

Nilai

Kuat

9

Sedang

3

Lemah

1

5. Penentuan ‘Weight of HOWs’ pada HoQ 1. Masih dalam FGD pertama, tahap selanjutnya dilakukan pembobotan dari ‘HOWS’ yang disebut juga ‘Weight of HOWs’. Pembobotan tersebut dilakukan untuk mendapatkan nilai pembobotan dari masing-masing faktor teknologi yang sudah ditentukan. Hasil dari tahap ini adalah ‘Weight of HOWs’ berupa nilai pembobotan dari faktor teknologi yang terdapat dalam ‘HOWs’. Tahap ini merupakan akhir dari model HoQ 1, dan merupakan hasil dari FGD yang pertama. 6. Pendaftaran ‘WHATs’ pada HoQ 2.



74

Pada tahap ini dimulainya kegiatan FGD yang kedua, yang dihadiri para pengembangan SI/TI pada Direktorat TI BPJS Kesehatan. ‘HOWs’ pada HoQ 1 terdiri dari faktor teknologi merupakan masukan ‘WHATs’ pada HoQ 2. Hasil dari tahap ini adalah daftar faktor teknologi. 7. Penentuan ‘Priority of WHATs’ pada HoQ 2. ‘Weight of HOWs’ pada HoQ 1 merupakan faktor teknologi yang sudah ditentukan nilai pembobotannya. ‘Weight of HOWs’ tersebut merupakan masukan ‘Priority of WHATs’ pada HoQ 2 sehingga tidak perlu ditentukan nilai prioritasnya kembali karena nilai pembobotan pada HoQ 1 sudah bisa menentukan nilai prioritas kepentingannya. Hasil dari tahap ini adalah daftar nilai prioritas kepentingan dari faktor teknologi. 8. Pendaftaran ‘HOWs’ pada HoQ 2. Setelah pendaftaran ‘Priority of WHATs’ pada HoQ 2 selesai dilakukan, selanjutnya dilakukan pendaftaran kriteria dari kualitas perangkat lunak. Kriteria dari kualitas perangkat lunak yang terdapat dalam model kualitas SOAQM merupakan isi dari ‘HOWs’. Tahap ini dilakukan dalam FGD yang kedua. Hasil dari tahap ini adalah daftar kriteria dari kualitas perangkat lunak yang tertuang dalam ‘HOWs’ pada HoQ 2. 9. Penentuan ‘Relationship Matrix’ pada HoQ 2. Setelah ‘WHATs’ dan ‘HOWs’ pada HoQ 2 ditentukan, selanjutnya ditentukan nilai keterhubungan keduanya seperti yang dilakukan pada HoQ 1. Tabel 3.5 menunjukkan keterhubungan antara faktor teknologi dan kriteria kualitas perangkat lunak. Pemberian nilai keterhubungan antara ‘WHATs’ dan ‘HOWs’ ditentukan berdasarkan notasi yang digambarkan dengan matriks yang ditampilkan pada Tabel 3.4. Hasil dari tahap ini adalah daftar nilai keterhubungan ‘Relationship Matrix’ antara faktor teknologi dalam ‘WHATs’ dan kriteria kualitas dalam ‘HOWs’.



75

Tabel 3.5 HoQ Relasi Faktor Teknologi dan Kriteria Kualitas Kriteria Kualitas Q1

Q2

Q3

.

.

Qn

T1

Faktor Teknologi

T2 T3 . . Tn 10. Penentuan ‘Weight of HOWs’ pada HoQ 2. Masih dalam FGD yang kedua, pada tahap ini dilakukan pembobotan terhadap kriteria dari kriteria kualitas perangkat lunak pada ‘HOWs’. Pembobotan kriteria kualitas tersebut merupakan keluaran dari HoQ 2. Tahap ini merupakan akhir dari model HoQ 2. Hasil dari tahap ini adalah daftar ‘Weight of HOWs’ yang terdiri dari nilai pembobotan dari kriteria kualitas perangkat lunak yang terdapat dalam ‘HOWs’ 11. Melakukan pembobotan antar kriteria Berdasarkan daftar kriteria dari kriteria kualitas perangkat lunak yang telah ditetapkan nilai pembobotannya pada ‘Weight of HOWs’ pada HoQ 2, tahap selanjutnya dilakukan pembobotan subkriteria yaitu dengan perbandingan berpasangan antar subkriteria dalam kriteria yang sama dari kriteria kualitas perangkat lunak. Kemudian, dihitung nilai pembobotan dilakukan terhadap subkriterianya berdasarkan perhitungan pairwise comparison metode AHP sehingga menghasilkan nilai pembobotan lokal. Total penjumlahan dari nilai pembobotan subkriteria pada setiap kriteria adalah angka 1. Setelah diketahui nilai pembobotan untuk masing-masing subkriteria, kemudian dilakukan perbandingan kembali kriteria utamanya dengan cara membagi nilai Universitas Indonesia


76

pembobotan kriteria utama dengan nilai pembobotan untuk masing-masing subkriteria, sehingga menghasilkan nilai pembobotan global untuk masingmasing subkriteria. Setiap perbandingan antar subkriteria diperiksa nilai rasio konsistensinya, sehingga jika ada perbandingan yang tidak konsisten dapat langsung diperbaiki. Tahap ini masih dalam FGD yang kedua. 12. Penilaian terhadap alternatif Tahap ini dilakukan pada sesi proof of concept dengan para penyedia produk middleware ESB. Tujuan dari proof of concept ini adalah untuk memperlihatkan kemampuan dari produk middleware ESB dengan cara membuktikan fitur-fitur dan kemampuan produk ESB yang ditawarkan oleh setiap penyedia produk middleware ESB. Penilaian yang dilakukan terdiri dari pengajuan pertanyaan dari pihak pengembang SI/TI pada Direktorat TI kepada para penyedia produk middleware ESB, dan performance testing terhadap produk middleware ESB. Daftar pertanyaan yang diajukan berdasarkan masukan dari penelitian Franca & Soares (2015) dan Alrawashdeh, Muhairat, & Alqatawneh (2014) yang akan dijelaskan pada subbab “Instrumen Penelitian” pada bab ini. Performance testing dilakukan untuk membuktikan performa dari produk middleware ESB yang ditawarkan, yang terdiri dari response time dan throughput yang diperoleh dari aplikasi Rational Performance Tester. Hasil tahap ini adalah jawaban dari para penyedia produk middleware ESB dan service performance report. 13. Melakukan pembobotan alternatif terhadap kriteria. Tahap ini dilakukan penilaian terhadap alternatif-alternatif pilihan produk middleware ESB dengan menggunakan metode pairwise comparison AHP berdasarkan kriteria yang telah ditetapkan. Masukan informasi penilaian terhadap alternatif-alternatif pilihan diperoleh dari jawaban dari pertanyaan yang telah disusun sebelumnya dan hasil pengujian performa pada saat dilakukannya POC dengan para penyedia produk middleware ESB. Tahap ini dilakukan pada FGD yang ketiga yang dihadiri para pengembangan SI/TI pada Direktorat TI BPJS Kesehatan. Hasil dari tahap ini adalah nilai perbandingan alternatif terhadap kriteria kualitas perangkat lunak. 14. Analisis data. Universitas Indonesia


77

Pada tahap ini dilakukan analisis data untuk menentukan peringkat akhir berdasarkan perbandingan alternatif terhadap kriteria kualitas perangkat lunak. Tahap ini telah dapat teridentifikasi peringkat produk middleware ESB yang dapat digunakan oleh Direktorat TI BPJS Kesehatan. Hasil dari tahap ini adalah peringkat dari produk middleware ESB. 3.3

Metode Pengumpulan Data

Pengumpulan data bersifat kualitatif dan kuantitatif yang dikumpulkan dari dua sumber data. Sumber data tersebut antara lain: 1. Data Primer Pengumpulan data primer dilakukan melalui 3 metode, antara lain: a. Observasi. Observasi dilakukan dalam bentuk participant observer, dimana penulis melakukan partisipasi dan terlibat langsung dalam kegiatan yang diamati terhadap kondisi permasalahan implementasi teknologi web service pada Direktorat TI BPJS Kesehatan saat ini. Selain itu, observasi dilakukan dalam bentuk Focus Group Discussion (FGD) untuk memperoleh informasi yang sistematis dan terarah mengenai pembobotan persyaratan teknologi, kualitas perangkat lunak, serta pemeringkatan produk middleware ESB tersebut dari para pemangku kepentingan. FGD ini dilakukan beberapa kali dan diikuti oleh para pengembangan SI/TI dan pejabat yang berwenang dalam pengambilan keputusan di lingkungan Direktorat TI BPJS Kesehatan. FGD pertama untuk menentukan nilai prioritas kepentingan ‘Priority

of

WHATs’

kebutuhan

non-fungsional

dari

pemangku

kepentingan dengan menerapkan teknik skala pairwise comparison metode AHP, yaitu dengan cara membandingkan setiap kebutuhan non-fungsional sehingga menghasilkan nilai prioritas kepentingan dari kebutuhan nonfungsional. Selain itu, pada FGD pertama dilakukan penentuan kriteria teknis untuk memenuhi kebutuhan non-fungsional dari pemangku kepentingan, penentuan skala keterhubungan antara kebutuhan nonfungsional dan kriteria teknis dalam HoQ metode QFD, dan pembobotan Universitas Indonesia


78

dari kriteria teknis. FGD kedua menentukan nilai pembobotan dari faktor teknologi dan kriteria kualitas perangkat lunak dengan menerapkan skala keterhubungan HoQ untuk menentukan ‘Relationship Matrix’ dan ‘Weight of HOWs’ pada setiap HoQ, dan pembobotan terhadap setiap kriteria dari kualitas perangkat lunak. Skala keterhubungan HoQ ditunjukkan pada Tabel 3.4. FGD ketiga menentukan penilaian terhadap alternatif-alternatif pilihan produk middleware ESB berdasarkan skala pairwise comparison AHP berdasarkan kriteria yang telah ditetapkan pembobotannya. b. Wawancara. Wawancara dilakukan terhadap responden internal dan eksternal organisasi. Wawancara terhadap pihak internal organisasi dilakukan kepada beberapa pengembang SIM dan pejabat di lingkungan Direktorat TI dalam bentuk wawancara bebas untuk mengetahui kondisi permasalahan pada Direktorat TI dan kebutuhan non-fungsional dari produk middleware ESB yang akan digunakan di BPJS Kesehatan. Sedangkan wawancara terhadap pihak eksternal yaitu kepada para penyedia produk middleware ESB dilakukan pada saat dilakukan proof of concept produk middleware ESB dalam bentuk wawancara terencana dan terstruktur karena terdiri dari daftar pertanyaan untuk memperoleh informasi mengenai ESB yang ditawarkan yang akan dijadikan sebagai bahan pemeringkatan ESB. Tujuan dari wawancara ini untuk memperoleh informasi yang tepat dari sumber yang tepat pula mengenai pertanyaan yang dirumuskan pada perancangan instrumen penelitian. c. Tes Tes dilakukan dalam bentuk performance testing untuk memperoleh informasi mengenai performa dari produk middleware ESB yang akan dilakukan penilaian, informasi tersebut berupa response time dan throughput. Performance testing dilakukan pada sesi Proof Of Concept (POC) dengan para penyedia produk middleware ESB. 2. Data Sekunder diperoleh dari dokumen yang berkaitan dengan penelitian yang meliputi Peta Jalan JKN dan Peta Strategi BPJS Kesehatan, strategi utama Universitas Indonesia


79

organisasi, jurnal penelitian, buku referensi, teori yang membahas metode MDCA, QFD, AHP, teknologi ESB, dan informasi produk middleware ESB dari website resmi penyedia produk middleware ESB, serta dokumen lainnya yang mendukung penelitian. 3.4

Instrumen Pengumpulan Data

Instrumen pengumpulan data yang dirancang terdiri dari instrumen wawancara dan FGD. Instrumen wawancara terencana dan terstruktur hanya dilakukan terhadap pihak eksternal, yaitu kepada para penyedia produk middleware ESB berupa daftar pertanyaan untuk mendapatkan penilaian dari produk middleware ESB yang ditawarkan yang disusun berdasarkan kriteria kualitas perangkat lunak dengan mengadopsi model kualitas SOAQM. Daftar pertanyaan yang diajukan berdasarkan masukan dari penelitian Franca & Soares (2015) dan Alrawashdeh, Muhairat, & Alqatawneh (2014). Setiap kode kriteria yang disajikan pada Tabel 3.2 terwakili oleh 1 pertanyaan yang dapat dilihat pada Tabel 3.6. Tabel 3.6 Daftar Pertanyaan Kualitas Perangkat Lunak Kode Q1.1

Q1.2

Subkriteria

Pertanyaan

Functional

Fitur apa saja yang tersedia pada produk ESB

completeness

yang ditawarkan?

Functional

Bagaimana fitur yang tersedia pada produk

correctness

ESB tersebut yang bisa memberikan hasil yang sesuai dengan kebutuhan organisasi?

Q1.3

Functional

Bagaimana fitur yang tersedia pada produk

appropriateness

ESB yang ditawarkan bisa memenuhi tugas tertentu dalam mendukung proses bisnis organisasi?

Q2.1

Time behaviour

Seberapa cepat waktu respons dari produk ESB yang ditawarkan ketika dioperasikan?



80

Tabel 3.6 Daftar Pertanyaan Kualitas Perangkat Lunak (sambungan) Kode Q2.2

Subkriteria Resource utilization

Pertanyaan Bagaimana produk ESB yang ditawarkan dalam memanfaatkan sumber daya secara efisien?

Q3.1

Co-existence

Bagaimana layanan dari ESB yang ditawarkan bisa digunakan secara bersamaan?

Q3.2

Interoperability

Bagaimana interoperabilitas produk ESB yang ditawarkan dalam berinteraksi dengan sistem lainnya?

Q4.1

Appropriateness

Bagaimana kelayakan produk ESB yang

recognizability

ditawarkan dalam memenuhi kebutuhan yang diinginkan?

Q4.2

Learnability

Sejauh mana layanan produk ESB yang ditawarkan bisa dengan mudah dipahami oleh pengguna?

Q4.3

Operability

Bagaimana kemudahan pengoperasian produk ESB yang ditawarkan?

Q4.4


Bagaimana

layanan

produk

ESB

yang

ditawarkan dalam mencegah kesalahan input yang salah? Q5.1

Maturity

Bagaimana produk ESB yang ditawarkan dalam melayanani permintaan bisa ditanggapi sesuai harapan?

Q5.2

Availability

Bagaimana produk ESB yang ditawarkan dalam menyediakan layanan ketika diminta?

Q5.3

Fault tolerance

Bagaimana produk ESB yang ditawarkan mampu

mempertahankan

tingkat

kinerja

tertentu jika terdapat kesalahan pada perangkat lunak dan perangkat keras?



81

Tabel 3.6 Daftar Pertanyaan Kualitas Perangkat Lunak (sambungan) Kode Q5.4

Subkriteria Recoverability

Pertanyaan Bagaimana produk ESB yang ditawarkan melanjutkan proses dan memulihkan data jika terkena dampak dari kegagalan sistem?

Q6.1

Confidentiality

Bagaimana pengaturan layanan informasi bersama oleh penyedia layanan dapat diakses hanya untuk klien resmi?

Q6.2

Integrity

Bagaimana pengaturan produk ESB yang ditawarkan dalam mencegah akses yang tidak sah?

Q6.3

Accountability

Bagaimana layanan dari produk ESB yang ditawarkan bisa menyimpan data akses? Bagaimana produk ESB yang ditawarkan

Q6.4

Authenticity

dalam mencegah akses dari yang tidak berhak? Bagaimana produk ESB yang ditawarkan

Q6.5

Non-repudiation

dalam membuktikan bahwa informasi telah dikirim kepada pengguna layanan? Bagaimana modul-modul dari produk ESB

Q7.1

Modularity

yang ditawarkan dapat dipasang dan diimplementasikan sebagai sistem tunggal? Bagaimana modul yang terdapat pada produk

Q7.2

Reusability

ESB yang ditawarkan dapat digunakan kembali pada proyek yang sedang atau akan dikembangkan? Bagaimana karakteristik produk ESB yang

Q7.3

Modifiability

ditawarkan bisa mengurangi ketergantungan antar layanan? Bagaimana modul perangkat lunak yang telah

Q7.4

Testability

dimodifikasi dalam ESB yang ditawarkan mudah dilakukan pengujian? Universitas Indonesia


82

Tabel 3.6 Daftar Pertanyaan Kualitas Perangkat Lunak (sambungan) Kode

Subkriteria

Pertanyaan Bagaimana produk ESB yang ditawarkan

Q7.5

Analyzability

dalam menganalisis dampak perubahan ketika layanan perlu untuk dilakukan modifikasi? Bagaimana produk ESB yang ditawarkan

Q8.1

Adaptability

dalam

beradaptasi

dengan

perubahan

platform? Q8.2

Installability

Q8.3

Replaceability

Bagaimana

instalasi

produk

ESB

yang

ditawarkan jika terjadi perubahan platform? Bagaimana

instalasi

produk

ESB

yang

ditawarkan jika terjadi pergantian platform?

Instrumen yang digunakan pada saat FGD yang diikuti oleh para pengembangan SI/TI dan pejabat yang berwenang dalam pengambilan keputusan di lingkungan Direktorat TI BPJS Kesehatan berisi daftar pertanyaan tertutup, dimana peserta FGD menentukan pilihan dari perbandingan dua data secara berpasangan, kemudian peserta FGD menentukan jawaban berdasarkan skala penilaian berdasarkan metode QFD yang telah disajikan pada Tabel 3.4, dan metode AHP yang disajikan pada Tabel 3.7. Tabel 3.7 Skala Perbandingan antar Kriteria Nilai Angka

Definisi

Penjelasan

1

Sama Pentingnya

Dua faktor berkontribusi sama besar atas satu kepentingan.

3

Lebih Penting daripada elemen lainnya

Pengalaman dan pertimbangan sedikit kecenderungannya satu elemen terhadap elemen lainnya.

5

Kuat Kepentingannya

Pengalaman dan pertimbangan dengan kuat kecenderungannya satu elemen terhadap elemen lainnya.

7

Sangat Kuat Kepentingannya

Pengalaman dan pertimbangan sangat kuat kecenderungannya satu elemen terhadap elemen lainnya.



83

Tabel 3.7 Skala Perbandingan antar Kriteria (sambungan) Nilai Angka 9

Definisi

Penjelasan

Mutlak Kepentingannya Bukti kecenderungannya satu elemen terhadap elemen lainnya memiliki tingkat validitas paling tinggi yang mungkin menguatkan.

2,4,6,8 Skor Antara

Ketika kompromi diperlukan di antara dua perbandingan.

Topik diskusi pada FGD pertama adalah untuk memperoleh nilai prioritas kepentingan dari kebutuhan non-fungsional dari pemangku kepentingan. Kepada para peserta FGD ditampilkan perbandingan berpasangan antar kebutuhan nonfungsional, kemudian peserta FGD menentukan pilihan dari perbandingan berpasangan tersebut dan penilaiannya berdasarkan skala yang ditunjukkan pada Tabel 3.7. Selain itu, pada FGD pertama membahas penentuan kriteria teknis untuk memenuhi kebutuhan non-fungsional dari pemangku kepentingan, penentuan skala keterhubungan antara kebutuhan non-fungsional dan kriteria teknis dalam HoQ metode QFD, dan pembobotan dari kriteria teknis. Nilai pembobotan dari faktor teknologi terhadap kebutuhan non-fungsional dipetakan menggunakan HoQ dari metode QFD yang telah disajikan pada Tabel 3.3. Matriks keterhubungan dan seberapa pengaruhnya masing-masing faktor mempengaruhi faktor lain diberi notasi dan nilai berdasarkan Tabel 3.4. Topik diskusi pada FGD kedua adalah untuk menentukan nilai pembobotan dari model kriteria kualitas perangkat lunak SOAQM yang diperoleh dari seberapa pengaruhnya dengan faktor teknologi yang sudah dilakukan pada FGD pertama. Nilai pembobotan dari kriteria kualitas perangkat lunak terhadap faktor teknologi dipetakan menggunakan HoQ dari metode QFD yang ditunjukkan pada Tabel 3.5. Selanjutnya pada FGD ketiga, topik diskusi adalah untuk menentukan peringkat dari masing-masing kandidat produk middleware ESB menggunakan metode AHP yang diberi nilai berdasarkan kriteria kualitas perangkat lunak SOAQM yang diperoleh pada FGD kedua. Performance testing dilakukan untuk memperoleh nilai response time dan throughput dari produk middleware ESB. Hasil yang diharapkan dari performance Universitas Indonesia


84

testing adalah tabulasi dari nilai response time dan throughput. Dalam melakukan performance testing, penulis memerlukan alat bantu perangkat lunak, yaitu IBM Rational Performance Tester 9.0. Perangkat lunak tersebut berfungsi untuk melakukan pengujian kinerja dari aplikasi web dan server. IBM Rational Performance Tester mampu untuk mengidentifikasi keberadaan dan penyebab kemacetan kinerja sistem dan mengurangi kompleksitas dalam melakukan pengujian beban suatu sistem. Salah satu fitur dalam aplikasi IBM Rational Performance Tester adalah melakukan pengujian beban load testing untuk membantu memastikan aplikasi dalam menangani beban pengguna yang besar sebelum dilakukan instalasi atau penyebaran. Daftar penilaian produk sesuai service performance report yang mengacu pada keluaran dari aplikasi IBM Rational Performance Tester disajikan pada Tabel 3.8. Tabel 3.8 Daftar Penilaian ESB sesuai Service Performance Report No. 1

Performance Summary Response Time

Response Time [ms] -- Minimum Response Time [ms] -- Average Response Time [ms] -- Maximum Response Time [ms] -- Standard Deviation

2

Throughput

Request Starts -- Count Request Success -- Count Request Timeouts -- Count Request Fails -- Count

3.5

Uji Rasio Konsistensi Data

Pengujian rasio konsistensi data dalam metode AHP perlu dilakukan untuk mengukur seberapa konsisten penilaian yang telah dilakukan. AHP mentolerir inkonsistensi dalam penilaian, karena pendapat dari seseorang tidak selalu konsisten. Indeks konsistensi dihitung berdasarkan rumus sebagai berikut: CI =(λmax-n)/(n-1)

(3,1)



85 dimana λmax adalah nilai eigen dari matriks pertimbangan. Nilai CI dapat dibandingkan dengan matriks acak (RI). Rasio dihasilkan dari perbandingaan CI/RI, yang disebut rasio konsistensi (CR). Saaty menyarankan nilai CR harus kurang dari 0,1. Jika nilai CR melebihi 0,1, maka penilaian dianggap tidak dapat dipercaya karena penilaian terlalu mirip, dan proses penilaian harus diulang. Dalam melakukan perhitungan rasio konsistensi data, penulis memerlukan alat bantu perangkat lunak, yaitu Expert Choice 11. Perangkat lunak tersebut dapat digunakan untuk membantu dalam pengambilan keputusan berdasarkan konsep MCDA yang khusus mengimplementasikan metode AHP. Fitur yang terdapat pada perangkat lunak ini sudah mencukupi dalam melakukan perhitungan rasio konsistensi data sekaligus mengimplementasikan metode AHP secara keseluruhan.



BAB 4 PROFIL ORGANISASI

Bab ini menjelaskan tentang profil organisasi yang menjadi studi kasus penelitian, yang mencakup visi dan misi organisasi, struktur organisasi, dan sekilas tentang rencana strategis TI BPJS Kesehatan. 4.1

Profil Organisasi

Berdasarkan UU No. 40 Tahun 2004 tentang SJSN, pemerintah wajib membentuk Badan Penyelenggara Jaminan Sosial (BPJS) demi terselenggaranya jaminan sosial bagi seluruh rakyat Indonesia. UU No. 24 Tahun 2011 tentang Badan Penyelenggara Jaminan Sosial (BPJS) mengamanatkan transformasi kelembagaan PT Askes (Persero) menjadi BPJS Kesehatan. BPJS Kesehatan merupakan badan hukum publik yang bertanggungjawab kepada Presiden yang berfungsi menyelenggarakan jaminan sosial dalam program Jaminan Kesehatan Nasional (JKN) bagi seluruh penduduk Indonesia semenjak 1 Januari 2014. 4.2

Visi dan Misi Organisasi

Visi BPJS Kesehatan adalah CAKUPAN SEMESTA 2019 dengan penjelasan “Paling lambat 1 Januari 2019, seluruh penduduk Indonesia memiliki jaminan kesehatan nasional untuk memperoleh manfaat pemeliharaan kesehatan dan perlindungan

dalam

memenuhi

kebutuhan

dasar

kesehatannya

yang

diselenggarakan oleh BPJS Kesehatan yang handal, unggul, dan terpercaya”. Misi BPJS Kesehatan adalah : 1. Membangun kemitraan strategis dengan berbagai lembaga dan mendorong partisipasi masyarakat dalam perluasan kepesertaan Jaminan Kesehatan Nasional (JKN). 2. Menjalankan dan memantapkan sistem pelayanan kesehatan yang efektif, efisien, dan bermutu melalui kemitraan yang optimal dengan fasilitas kesehatan. 86



87

3. Mengoptimalkan pengelolaan dana jaminan sosial dan dana BPJS Kesehatan secara efektif, efisien, transparan, dan akuntabel untuk mendukung kesinambungan program. 4. Membangun BPJS Kesehatan yang efektif berlandaskan prinsip-prinsip tata kelola organisasi yang baik dan meningkatkan kompetensi pegawai untuk mencapai kinerja unggul. 5. Mengimplementasikan dan mengembangkan sistem perencanaan dan evaluasi, kajian, manajemen mutu dan manajemen risiko atas seluruh operasionalisasi BPJS Kesehatan. 6. Mengembangkan dan memantapkan teknologi informasi dan komunikasi untuk mendukung keseluruhan operasionalisasi BPJS Kesehatan. Salah satu strategi utama BPJS Kesehatan dalam mewujudkan visi dan misi organisasi adalah “Meningkatkan tingkat pemanfaatan teknologi informasi dan komunikasi untuk mendukung kelancaran upaya-upaya pelayanan kepada peserta dan operasionalisasi Badan“. 4.3

Struktur Organisasi

Struktur organisasi BPJS Kesehatan ditunjukkan Gambar 4.1. Pada Gambar 4.1 dapat dijelaskan bahwa pemegang kebijakan TI tertinggi di BPJS Kesehatan dipegang secara khusus Direktur Teknologi Informasi yang berada pada Direktorat Teknologi Informasi. Struktur Organisasi Direktorat Teknologi Informasi ditunjukkan Gambar 4.2.



88

Direktur Utama

Direktur Pelayanan

Direktur Keuangan dan Investasi

Direktur Kepesertaan dan Pemasaran

Direktur Perencaan, Pengembangan, dan Manajemen Risiko

Direktur Hukum, Komunikasi dan Hubungan antar Lembaga

Direktur SDM dan Umum

Direktur Teknologi Informasi

Gambar 4.1 Struktur Organisasi BPJS Kesehatan Sumber: Perdir No. 12 Tahun 2015 BPJS Kesehatan (2015), telah diolah kembali

Direktur Teknologi Informasi

Grup Strategi, Perencanaan, dan Keamanan TI

Grup Pengembangan Teknologi Informasi

Grup Operasional Teknologi Informasi

Departemen Perencanaan Teknologi Informasi

Departemen Pengembangan Aplikasi Inti

Departemen Database Management

Departemen IT Security

Departemen Pengembangan Aplikasi Pendukung

Departemen Data Center and Disaster Recovery Center

Departemen Penanganan Keluhan TI

Departemen IT Quality Assurance

Departemen Layanan TI dan Service Desk

Departemen Pengembangan Managemen Data

Departemen Jaringan dan Infrastruktur Teknologi Informasi

Gambar 4.2 Struktur Organisasi Direktorat TI BPJS Kesehatan Sumber: Perdir No. 12 Tahun 2015 (2015), telah diolah kembali



89

4.4

Rencana Strategis Teknologi Informasi

Dalam dokumen Peta Jaminan Kesehatan Nasional 2012-2019, Pemerintah mengharapkan pengembangan Sistem Informasi Manajemen (SIM) BPJS Kesehatan yang terinterkoneksi dengan berbagai lembaga dan instansi terkait. Harapan tersebut ditegaskan kembali dalam Peta Strategi BPJS Kesehatan Tahun 2014-2019, yang menyatakan strategi TIK BPJS Kesehatan dalam mendukung strategi utama BPJS Kesehatan diantaranya adalah mengembangkan metode dan model pengumpulan iuran yang cost-effective dengan didukung integrated online transaction dan memastikan kelengkapan dan keaktualan data masterfile peserta dengan didukung implementasi Electronic Data Interchange (EDI) dengan lembaga dan instansi terkait. Selain itu, salah satu dari Indikator Kinerja Utama (IKU) fungsi organisasi dalam Peta Strategi BPJS Kesehatan adalah otomatisasi proses bisnis, menyempurnakan sistem pelaporan akuntansi yang terintegrasi, dan membangun sistem jaringan komunikasi terintegrasi antar Fasilitas Kesehatan (Faskes). Direktorat

Teknologi

Informasi

(TI)

BPJS

Kesehatan

telah

berupaya

menerjemahkan harapan pemerintah dan organisasi tersebut dalam bentuk pengembangan dan implementasi integrasi SIM lintas satuan kerja melalui pendekatan Enterprise Application Integrator (EAI) dengan pemanfaatan teknologi middleware. Untuk menjamin tercapainya dukungan terhadap harapan pemerintah dan organisasi tersebut, Direktorat TI sebagai unit kerja yang bertanggung jawab dalam mendukung operasional TIK di BPJS Kesehatan telah menuangkan dasar pengembangan Sistem Informasi/Teknologi Informasi (SI/TI) BPJS Kesehatan dalam dokumen IT Master Plan (ITMP) BPJS Kesehatan 2014-2019 yang ditetapkan melalui Peraturan Direksi BPJS Kesehatan Nomor 50 Tahun 2014 tentang Dokumen IT Master Plan dan Dokumen Tata Kelola Teknologi Informasi BPJS Kesehatan.



BAB 5 ANALISIS DAN PEMBAHASAN

Bab ini menjelaskan proses analisis data sehingga menghasilkan sebuah keluaran yang menjadi tujuan penelitian. Dengan mengikuti metode QFD dan AHP dilakukan penentuan prioritas kebutuhan, pembobotan terhadap kriteria penilaian, penilaian terhadap alternatif terhadap kriteria, dan hasil akhir pemeringkatan produk middleware ESB. 5.1

Analisis model QFD

Untuk menerjemahkan kebutuhan non-fungsional produk middleware ESB berdasarkan pendapat dari pemangku kepentingan digunakan metode QFD. Karakteristik teknologi dan kualitas perangkat lunak dapat dipilih sebagai faktor yang bisa berpengaruh terhadap pemenuhan kebutuhan non-fungsional tersebut. Setelah mengetahui faktor yang berpengaruh, kemudian perlu ditentukan nilai prioritas kepentingan dari faktor tersebut, yang dapat diperoleh melalui penerapan HoQ sebagai implementasi dari metode QFD. Nilai pembobotan dari faktor teknologi dari perangkat lunak, dapat diperoleh dari keterhubungannya dengan kebutuhan non-fungsional dari pemangku kepentingan yang disusun dalam HoQ 1. Selanjutnya, faktor teknologi tersebut ditentukan keterhubungannya kembali dengan kriteria teknis lainnya, yaitu kriteria kualitas perangkat lunak yang kemudian diperoleh nilai pembobotan dari kualitas perangkat lunak tersebut yang disusun dalam HoQ 2. 5.1.1

Penentuan ‘WHATs’ pada HoQ 1

‘WHATs’ pada HoQ 1 adalah kebutuhan non-fungsional dari produk middleware ESB yang akan digunakan di BPJS Kesehatan. Untuk mendapatkan informasi ‘WHATs’ tersebut, dilakukan proses wawancara dengan pejabat di lingkungan Direktorat TI yang menghasilkan ‘customer attributes’. Dari tahapan wawancara diperoleh daftar kebutuhan non-fungsional dari pemangku kepentingan. Setiap ‘customer attributes’ diberi kode dan disajikan pada Tabel 5.1. 90



91 Tabel 5.1 Daftar Kebutuhan Non-fungsional dalam ‘WHATs’ HoQ 1 ‘WHATs’

Kode

Produk middleware ESB dapat memanfaatkan DBMS 10 yang sudah CA1

didukung oleh database administrator dan database developer saat ini di Direktorat TI. Produk middleware ESB harus dapat diintegrasikan dengan

CA2

pengembangan sistem menggunakan bahasa pemograman 3 yang sudah didukung oleh para pengembang SI/TI di Direktorat TI Produk middleware ESB mempunyai dokumentasi 5,13 yang lengkap

CA3

yang dipahami oleh para pengembang SI/TI di Direktorat TI dalam melakukan pengembangan dan konfigurasi. Produk middleware ESB dapat memanfaatkan

CA4

aplikasi/komponen/modul 4 yang sudah digunakan di Direktorat TI. Produk middleware ESB dapat memanfaatkan platform dan

CA5

CA6

infrastruktur 9 yang sudah digunakan di Direktorat TI. Produk middleware ESB selalu mendapatkan dukungan pembaruan 6 perangkat lunak dari para penyedia produk.

CA7

Produk middleware ESB dapat mendukung standar konektivitas 1 pada sistem internal BPJS Kesehatan maupun pada instansi eksternal.

CA8

Produk middleware ESB dapat mengadaptasi kinerja sistemnya 11 sesuai beban yang ditopang. Produk middleware ESB dapat mendukung percepatan waktu

CA9

CA10

pengembangan 2 sistem. Produk middleware ESB dapat dibuktikan mempunyai performa 14 yang tinggi. Produk middleware ESB dapat dengan mudah dilakukan

CA11 konfigurasi, modifikasi, pengelolaan, instalasi, dan penyebaran sistem 7.



92 Tabel 5.1 Daftar Kebutuhan Non-fungsional dalam ‘WHATs’ HoQ 1 (sambungan) ‘WHATs’

Kode

Kapabel dari produk middleware ESB dapat diperluas untuk penerapan CA12

Software as a Service (SaaS) 8. Produk middleware ESB dapat mengimplementasikan standar

CA13

5.1.2

keamanan 12 informasi Direktorat TI.

Penentuan ‘Priority of WHATs’ pada HoQ 1

Penentuan ‘Priority of WHATs’ pada HoQ 1 dilakukan pada FGD yang pertama yang dihadiri para pemangku kepentingan yang terdiri dari pengembangan SI/TI dan pejabat yang berwenang dalam pengambilan keputusan di lingkungan Direktorat TI BPJS Kesehatan. Kepada peserta FGD ditampilkan hasil dari wawancara dengan pejabat di lingkungan Direktorat TI, kemudian peserta FGD menentukan ‘Priority of WHATs’ pada HoQ 1 melalui perhitungan berdasarkan pairwise comparison dari metode AHP yakni dengan melakukan perbandingan berpasangan antar masing-masing kebutuhan non-fungsional yang menghasilkan nilai pembobotan dan prioritas kepentingannya yang ditampilkan pada Tabel 5.2. Setiap kebutuhan non-fungsional diwakili oleh kode berdasarkan daftar kebutuhan non-fungsional ‘WHATs’ pada Tabel 5.1. Nilai yang terdapat pada Tabel 5.2 kemudian dilakukan normalisasi sehingga mendapatkan nilai pembobotan. Dari nilai pembobotan tersebut dapat ditentukan nilai prioritas kepentingan dari masingmasing kebutuhan non-fungsional yang disajikan pada Tabel 5.3. Nilai prioritas kepentingan paling tinggi yang terdapat pada Tabel 5.3 merupakan kebutuhan nonfungsional yang perlu mendapatkan perhatian paling besar.



Tabel 5.2 Matriks Perbandingan dari ‘WHATs’ CA1 CA2 CA3 CA4 CA5 CA6 CA7 CAC8 CA9 CA10 CA11 CA12 CA13 CA1

1.00

0.20

0.33

0.14

0.33

2.00

0.11

0.25

0.11

0.11

0.11

2.00

0.33

CA2

5.00

1.00

0.50

0.50

3.00

7.00

0.50

3.00

2.00

0.33

0.11

7.00

0.33

CA3

3.00

2.00

1.00

0.33

0.50

4.00

0.33

1.00

0.33

0.20

0.14

5.00

0.33

CA4

7.00

2.00

3.00

1.00

1.00

7.00

0.50

2.00

1.00

0.14

0.17

5.00

1.00

CA5

3.00

0.33

2.00

1.00

1.00

3.00

0.14

3.00

0.33

0.11

0.11

5.00

1.00

CA6

0.50

0.14

0.25

0.14

0.33

1.00

0.14

0.20

0.11

0.11

0.11

0.33

0.14

CA7

9.00

2.00

3.00

2.00

7.00

7.00

1.00

7.00

2.00

2.00

0.33

9.00

1.00

CA8

4.00

0.33

1.00

0.50

0.33

5.00

0.14

1.00

0.25

0.25

0.11

3.00

0.50

CA9

9.00

0.50

3.00

1.00

3.00

9.00

0.50

4.00

1.00

1.00

0.33

8.00

1.00

CA10 9.00

3.00

5.00

7.00

9.00

9.00

0.50

4.00

1.00

1.00

0.33

9.00

1.00

CA11 9.00

9.00

7.00

6.00

9.00

9.00

3.00

9.00

3.00

3.00

1.00

9.00

5.00

CA12 0.50

0.14

0.20

0.20

0.20

3.00

0.11

0.33

0.13

0.11

0.11

1.00

0.20

CA13 3.00

3.00

3.00

1.00

1.00

7.00

1.00

2.00

1.00

1.00

0.20

5.00

1.00



94

Tabel 5.3 Normalisasi dari Matriks Perbandingan ‘WHATs’ CA1 CA2 CA3 CA4 CA5 CA6 CA7 CAC8 CA9 CA10 CA11 CA12 CA13

Nilai

Nilai

Pembobotan

Prioritas

CA1

0.02

0.01

0.01

0.01

0.01

0.03

0.01

0.01

0.01

0.01

0.03

0.03

0.03

0.016

3

CA2

0.08

0.04

0.02

0.02

0.08

0.10

0.06

0.08

0.16

0.04

0.03

0.10

0.03

0.065

7

CA3

0.05

0.08

0.03

0.02

0.01

0.05

0.04

0.03

0.03

0.02

0.04

0.07

0.03

0.039

5

CA4

0.11

0.08

0.10

0.05

0.03

0.10

0.06

0.05

0.08

0.02

0.05

0.07

0.08

0.068

8

CA5

0.05

0.01

0.07

0.05

0.03

0.04

0.02

0.08

0.03

0.01

0.03

0.07

0.08

0.044

6

CA6

0.01

0.01

0.01

0.01

0.01

0.01

0.02

0.01

0.01

0.01

0.03

0.00

0.01

0.011

1

CA7

0.14

0.08

0.10

0.10

0.20

0.10

0.13

0.19

0.16

0.21

0.10

0.13

0.08

0.133

11

CA8

0.06

0.01

0.03

0.02

0.01

0.07

0.02

0.03

0.02

0.03

0.03

0.04

0.04

0.033

4

CA9

0.14

0.02

0.10

0.05

0.08

0.12

0.06

0.11

0.08

0.11

0.10

0.12

0.08

0.091

10

CA10 0.14

0.13

0.17

0.34

0.25

0.12

0.06

0.11

0.08

0.11

0.10

0.13

0.08

0.140

12

CA11 0.14

0.38

0.24

0.29

0.25

0.12

0.38

0.24

0.24

0.32

0.31

0.13

0.39

0.265

13

CA12 0.01

0.01

0.01

0.01

0.01

0.04

0.01

0.01

0.01

0.01

0.03

0.01

0.02

0.014

2

CA13 0.05

0.13

0.10

0.05

0.03

0.10

0.13

0.05

0.08

0.11

0.06

0.07

0.08

0.079

9



95

Dari Tabel 5.3 terlihat bahwa kebutuhan terkait produk middleware ESB yang dapat dengan mudah dilakukan konfigurasi, modifikasi, pengelolaan, instalasi, dan penyebaran sistem (CA11) merupakan kebutuhan non-fungsional yang perlu mendapat perhatian paling besar dalam proses pemeringkatan produk middleware ESB, diikuti oleh kebutuhan produk middleware ESB yang dapat dibuktikan mempunyai performa yang tinggi (CA10), dan produk middleware ESB dapat mendukung standar konektivitas pada sistem internal BPJS Kesehatan maupun pada instansi eksternal (CA7) pada peringkat ke-2 dan ke-3. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,09, maka perhitungan ini masih di bawah batas yang dapat diterima, yaitu di bawah 0.1. 5.1.3

Penentuan ‘HOWs’ pada HoQ 1

Setelah diketahui nilai prioritas dari kebutuhan non-fungsional dari pemangku kepentingan, selanjutnya ditentukan karakteristik teknis dari perangkat lunak untuk mengisi ‘HOWs’ pada HoQ 1 sebagai cara untuk memenuhi kebutuhan tersebut. Masukan karakteristik teknis pada HoQ1 adalah faktor teknologi dari perangkat lunak yang ditampilkan dan diberi kode untuk setiap kriteria pada Tabel 3.1. Tahap ini masih dilakukan pada FGD yang pertama. Pada FGD ini, disepakati penambahan beberapa faktor teknologi selain faktor teknologi yang sudah didaftarkan, sehingga faktor teknologi yang didaftarkan pada ‘HOWS’ terdiri dari 14 faktor, kemudian setiap faktor teknologi tersebut diberi kode yang disajikan pada Tabel 5.4. Masukan dari peserta FGD dianggap sebagai pendapat ahli, karena peserta FGD telah mempunyai cukup banyak pengalaman di bidang TI. Tabel 5.4 Daftar ‘HOWs’ pada HoQ 1 ‘HOWs’

Kode T1

Platform

T2


T3


T4


T5

External connectivity Universitas Indonesia


96 Tabel 5.4 Daftar ‘HOWs’ pada HoQ 1 (sambungan) ‘HOWs’

Kode T6

User documentation

T7


T8

Versioning

T9

Interface standard

T10


T11

Performance

T12

Security

T13

Scalability

T14

Usability

5.1.4

Penentuan ‘Relationship Matrix’ pada HoQ 1

Selanjutnya, dilakukan penilaian keterhubungan ‘Relationship Matrix’ antara ‘WHATs’ dan ‘HOWs’ pada HoQ 1. Tahap ini masih dilakukan pada FGD yang pertama. Para peserta FGD memberikan penilaian berdasarkan dampak ‘WHATs’, yaitu kebutuhan non-fungsional pemangku kepentingan yang mana yang berpengaruh terhadap faktor teknologi pada ‘HOWs’ dan seberapa pengaruhnya. Setiap kebutuhan non-fungsional diwakili oleh kode yang berdasarkan daftar kebutuhan non-fungsional ‘WHATs’ pada Tabel 5.1; sedangkan faktor teknologi diwakili oleh kode yang berdasarkan daftar ‘HOWs’ pada HoQ 1 yang terdapat pada Tabel 5.4. Nilai keterhubungan antara ‘WHATs’ dan ‘HOWs’ ditentukan berdasarkan notasi yang ditampilkan pada Tabel 3.4. Hasil keterhubungan ‘Relationship Matrix’ antara ‘WHATs’ dan ‘HOWs’ pada HoQ 1 dapat dilihat pada Tabel 5.5.



97


Prioritas

Tabel 5.5 ‘Relationship Matrix’ pada HoQ 1

CA1

3

CA2

7

CA3

5

CA4

8

CA5

6

CA6

1

CA7

11

CA8

4

CA9

10

CA10

12

CA11

13

CA12

2

CA13

9

Faktor Teknologi T1

T2

T1: Platforms T2: Database management system T3: Languages and development tools T4: User management tools

T3

T4

T5

T6

T5: External connectivity T6: User documentation T7: Technical documentation T8: Versioning

T7

T8

T9

T9: Interface standard T10: Architecture style T11: Performance T12: Security

T10 T11

T13: Scalability T14: Easy to Use

T12

T13 T14

Notas i : Dampak

Nilai

Kuat

9

Sedang

3

Lemah

1

Notas i



98 Berdasarkan hasil keterhubungan ‘Relationship Matrix’ antara ‘WHATs’ dan ‘HOWs’ pada HoQ 1 yang ditampilkan pada Tabel 5.5, dapat disimpulkan hal-hal sebagai berikut: 1. Untuk

memenuhi

kebutuhan

non-fungsional

terkait

DBMS,

dapat

memerhatikan faktor teknologi plaform, database management system, dan usability. 2. Untuk memenuhi kebutuhan non-fungsional terkait bahasa pemograman, dapat memerhatikan faktor teknologi languages and development tools, user documentation, technical documentation, dan usability. 3. Untuk memenuhi kebutuhan non-fungsional terkait dokumentasi, dapat memerhatikan faktor teknologi user documentation, technical documentation, dan usability. 4. Untuk memenuhi kebutuhan non-fungsional terkait aplikasi/komponen/modul, dapat memerhatikan faktor teknologi database management system, languages and development tools, user management tools, external connectivity, interface standard, dan framework and architecture style. 5. Untuk memenuhi kebutuhan non-fungsional terkait platform dan infrastruktur, dapat memerhatikan faktor teknologi platform, database management system, external connectivity, interface standard, dan framework and architecture style. 6. Untuk memenuhi kebutuhan non-fungsional terkait pembaruan perangkat lunak, dapat memerhatikan faktor teknologi versioning. 7. Untuk memenuhi kebutuhan non-fungsional terkait standar konektivitas, dapat memerhatikan faktor teknologi platform, external connectivity, interface standard, framework and architecture style, dan security. 8. Untuk memenuhi kebutuhan non-fungsional terkait adaptasi kinerja sistem, dapat memerhatikan faktor teknologi platform, external connectivity, framework and architecture style, performance dan scalability. 9. Untuk memenuhi kebutuhan non-fungsional terkait percepatan waktu pengembangan, dapat memerhatikan faktor teknologi languages and



99

development tools, user documentation, technical documentation, dan easy to use. 10. Untuk memenuhi kebutuhan non-fungsional terkait pembuktian performa, dapat memerhatikan faktor teknologi external connectivity, interface standard, framework and architecture style, dan performance. 11. Untuk memenuhi kebutuhan non-fungsional terkait kemudahan konfigurasi, modifikasi, pengelolaan, instalasi, dan penyebaran sistem, dapat memerhatikan faktor teknologi languages and development tools, user management tools, user documentation, technical documentation, interface standard, framework and architecture style, dan usability. 12. Untuk memenuhi kebutuhan non-fungsional terkait penerapan SaaS dapat memerhatikan faktor teknologi platform, database management system, external connectivity, technical documentation, interface standard, dan framework and architecture style. 13. Untuk memenuhi kebutuhan non-fungsional terkait standar keamanan dapat memerhatikan faktor teknologi security. 5.1.5

Penentuan ‘Weight of HOWs’ pada HoQ 1

‘Weight of HOWs’ pada HoQ 1 adalah nilai pembobotan dari masing-masing faktor teknologi yang sudah ditentukan. Tahap ini masih dilakukan pada FGD yang pertama. Para peserta FGD memberikan penilaian berdasarkan perhitungan antara nilai ‘Priority of WHATs’ dengan nilai ‘Relationship Matrix’ yang sudah ditentukan pada tahap sebelumnya. ‘Weight of HOWs’ pada HoQ 1 diperoleh dari hasil perkalian setiap nilai prioritas kebutuhan non-fungsional dengan nilai ‘Relationship Matrix’ yang kemudian dibagi rata berdasarkan proporsi masingmasing hasil perkalian. Perhitungan tersebut menghasilkan ‘Weight of HOWs’. Hasil dari tahap ini adalah daftar nilai pembobotan yang tertuang dalam ‘Weight of HOWs’ yang merupakan faktor teknologi yang perlu dipertimbangkan dalam pemeringkatan ESB pada tahap selanjutnya. Daftar ‘Weight of HOWs’ disajikan pada Tabel 5.6.



100


Prioritas

Tabel 5.6 Perhitungan ‘Weight of HOWs’ pada HoQ 1 Faktor Teknologi T1

T2

T3

T4

T5

T6

T7

T8

T9

T10

T11

T12

T13

T14

CA1

3

3

27

0

0

0

0

0

0

0

0

0

0

0

9

CA2

7

0

0

81

0

0

9

9

0

0

0

9

0

0

9

CA3

5

0

0

0

0

0

54

54

0

0

0

0

0

0

18

CA4

8

0

8

72

24

24

0

0

0

24

24

0

0

0

0

CA5

6

63

21

0

0

21

0

0

0

21

63

0

0

0

0

CA6

1

0

0

0

0

0

0

0

9

0

0

0

0

0

0

CA7

11

12

0

0

0

108

0

0

0

108

12

0

12

0

0

CA8

4

15

0

0

0

15

0

0

0

0

5

45

0

45

0

CA9

10

0

0

33

0

0

33

33

0

0

0

0

0

0

99

CA10

12

0

0

0

0

39

0

0

0

13

39

117

0

0

0

CA11

13

0

0

126

126

0

126

126

0

14

42

0

0

0

28

CA12

2

18

6

0

0

18

0

2

0

6

18

0

0

0

0

CA13

9

0

0

0

0

0

0

0

0

0

0

0

90

0

0

0.049

0.030

0.142

0.071

0.105

0.101

0.102

0.005

0.087

0.094

0.076

0.046

0.018

0.074

Nilai Pembobotan



101

Hasil dari model HoQ 1 adalah nilai pembobotan dari faktor teknologi yang menjadi masukan pada tahap selanjutnya, yaitu sebagai informasi penting dalam menentukan nilai pembobotan dari kriteria kualitas perangkat lunak. 5.1.6

Pendaftaran ‘WHATs’ pada HoQ 2

Pada tahap ini dimulainya kegiatan FGD yang kedua, yang dihadiri oleh para perwakilan dari beberapa Departemen pada Direktorat TI BPJS Kesehatan. ‘WHATs’ pada HoQ 2 adalah faktor teknologi yang merupakan ‘HOWs’ pada HoQ 1. Daftar ‘WHATs’ dapat dilihat pada Tabel 5.4 yang juga merupakan daftar pada ‘HOWs’ pada HoQ 1. Daftar Peserta FGD tahap kedua dapat dilihat pada Tabel 5.7. Tabel 5.7 Daftar Peserta FGD penyusunan HoQ 2 No. 1

Jabatan Peserta FGD System Development Pratama

Departemen Pengembangan Aplikasi Inti pada Grup

Pengembangan

Teknologi

Informasi 2

Assisten System Development

Pengembangan Aplikasi Pendukung pada Grup Pengembangan Teknologi Informasi

3

System Analyst Pratama

Pengembangan Aplikasi Inti pada Grup

Pengembangan

Teknologi

Informasi 4

Application and Database Quality IT Quality Assurance pada Grup Assurance Pratama

5

6

Pengembangan Teknologi Informasi

Network and Infrastruktur Quality IT Quality Assurance pada Grup Assurance Pratama

Pengembangan Teknologi Informasi

Business Analyst Pratama

Perencanaan pada

Grup

Teknologi

Informasi

Perencanaan,

dan

Keamanan Teknologi Informasi



102

Tabel 5.7 Daftar Peserta FGD penyusunan HoQ 2 (sambungan) No.

Jabatan Peserta FGD

7

Departemen

Assisten Network and

Perencanaan Teknologi Informasi

Infrastructure

pada

Grup

Perencanaan,

dan

Keamanan Teknologi Informasi 8

System Administrator Pratama

Layanan

Informasi

pada

Grup

Operasional Teknologi Informasi 9

Network Engineer Pratama

Jaringan dan Infrastuktur Teknologi Informasi pada Grup Operasional Teknologi Informasi

5.1.7

Penentuan ‘Priority of WHATs’ pada HoQ 2

‘Weight of HOWs’ pada HoQ 1 merupakan faktor teknologi yang sudah ditentukan nilai pembobotannya. ‘Weight of HOWs’ tersebut merupakan masukan ‘Priority of WHATs’ pada HoQ 2 yang tidak perlu ditentukan nilai prioritas kepentinganya, karena dengan nilai pembobotan yang sudah ditentukan pada HoQ 1, sudah dapat diperoleh nilai prioritas kepentinganya. Daftar ‘Priority of WHATs’ pada HoQ 2 dapat dilihat pada Tabel 5.8. Tabel 5.8 Daftar ‘Priority of WHATs’ pada HoQ 2 ‘HOWs’

Kode

Nilai

Nilai

Pembobotan

Prioritas

T1

Platform

0.049

5

T2


0.030

3

T3


0.142

14

T4


0.071

6

T5


0.105

13

T6

User documentation

0.101

11

T7


0.102

12

T8

Versioning

0.005

1

T9

Interface standard

0.087

9 Universitas Indonesia


103 Tabel 5.8 Daftar ‘Priority of WHATs’ pada HoQ 2 (sambungan) ‘HOWs’

Kode

Nilai

Nilai

Pembobotan

Prioritas

T10


0.094

10

T11

Performance

0.076

8

T12

Security

0.046

4

T13

Scalability

0.018

2

T14

Usability

0.074

7

5.1.8

Pendaftaran ‘HOWs’ pada HoQ 2

Setelah pendaftaran ‘Priority of WHATs’ pada HoQ 2 selesai dilakukan, selanjutnya dilakukan pendaftaran kriteria kualitas perangkat lunak. Masukan ‘HOWs’ terdiri dari kriteria kualitas perangkat lunak yang terdapat dalam model kualitas SOAQM. Tahap pendaftaran ‘HOWs’ pada HoQ 2 ini masih dilakukan dalam FGD yang kedua. Daftar kriteria kualitas perangkat lunak yang dihasilkan pada tahap ini adalah kriteria kualitas perangkat lunak, tanpa mengikutsertakan subkriterianya. Setiap kriteria kualitas perangkat lunak yang terdapat dalam model kualitas SOAQM diberi kode yang disajikan pada Tabel 5.9. Tabel 5.9 ‘HOWs’ pada HoQ 2 ‘HOWs’

Kode Q1


Q2


Q3

Compatibility

Q4

Usability

Q5

Reliability

Q6

Security

Q7

Maintainability

Q8

Portability



104

5.1.9

Penentuan ‘Relationship Matrix’ pada HoQ 2

Selanjutnya dilakukan penilaian keterhubungan ‘Relationship Matrix’ antara ‘WHATs’ dan ‘HOWs’ pada HoQ 2. Tahap ini masih dilakukan pada FGD yang kedua. Para peserta FGD memberikan penilaian berdasarkan dampak ‘WHATs’ yaitu faktor teknologi yang mana yang berpengaruh terhadap kriteria kualitas perangkat lunak pada ‘HOWs’ dan seberapa pengaruhnya. Nilai keterhubungan antara ‘WHATs’ dan ‘HOWs’ ditentukan berdasarkan notasi yang telah ditampilkan pada Tabel 3.4. Hasil keterhubungan ‘Relationship Matrix’ antara ‘WHATs’ dan ‘HOWs’ pada HoQ 2 dapat dilihat pada Tabel 5.10, dan dapat disimpulkan hal-hal sebagai berikut: 1. Untuk

memenuhi

kebutuhan

dari

faktor

teknologi

platform,

dapat

memerhatikan kriteria compatibility dan portability 2. Untuk memenuhi kebutuhan dari faktor teknologi database management system, dapat memerhatikan kriteria functional suitability, compatibility dan portability 3. Untuk memenuhi kebutuhan dari faktor teknologi languages and development tools,

dapat

memerhatikan

kriteria

functional

suitability,

usability,

maintainability, dan portability. 4. Untuk memenuhi kebutuhan dari faktor teknologi user management tools, dapat memerhatikan kriteria functional suitability, security, dan maintainability. 5. Untuk memenuhi kebutuhan dari faktor teknologi external connectivity, dapat memerhatikan kriteria functional suitability, compatibility dan portability. 6. Untuk memenuhi kebutuhan dari faktor teknologi user documentation, dapat memerhatikan kriteria functional suitability, usability, dan maintainability. 7. Untuk memenuhi kebutuhan dari faktor teknologi technical documentation, dapat

memerhatikan

kriteria

functional

suitability,

usability,

dan

maintainability. 8. Untuk memenuhi kebutuhan dari faktor teknologi versioning, dapat memerhatikan kriteria functional suitability.



105

9. Untuk memenuhi kebutuhan dari faktor teknologi interface standard, dapat memerhatikan kriteria compatibility. 10. Untuk memenuhi kebutuhan dari faktor teknologi framework and architecture style, dapat memerhatikan kriteria functional suitability, compatibility, dan portability. 11. Untuk memenuhi kebutuhan dari faktor teknologi performance, dapat memerhatikan kriteria performance efficiency dan reliability. 12. Untuk memenuhi kebutuhan dari faktor teknologi security, dapat memerhatikan kriteria security. 13. Untuk memenuhi kebutuhan dari faktor teknologi scalability, dapat memerhatikan kriteria performance efficiency. 14. Untuk

memenuhi

kebutuhan

dari

faktor

teknologi

usability,

dapat

memerhatikan kriteria usability dan maintainability.

Faktor Teknologi

Prioritas

Tabel 5.10 ‘Relationship Matrix’ pada HoQ 2

T1

5

T2

3

T3

14

T4

6

T5

13

T6

11

T7

12

T8

1

T9

9

T10

10

T11

8

T12

4

T13

2

T14

7

Kriteria Kualitas Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8



106 5.1.10 Penentuan ‘Weight of HOWs’ pada HoQ 2 Masih dalam FGD yang kedua, pada tahap ini dilakukan pembobotan kriteria kualitas perangkat lunak pada ‘HOWS’ HoQ 2. ‘Weight of HOWs’ adalah nilai pembobotan dari setiap kriteria kualitas perangkat lunak yang sudah ditentukan. Para peserta FGD memberikan penilaian berdasarkan perhitungan antara nilai ‘Priority of WHATs’ dengan nilai ‘Relationship Matrix’ yang sudah ditentukan pada tahap sebelumnya. ‘Weight of HOWs’ pada HoQ 2 diperoleh dari hasil perkalian setiap nilai prioritas dari faktor teknologi dengan nilai ‘Relationship Matrix’ yang kemudian dibagi rata berdasarkan proporsi masing-masing hasil perkalian. Hasil dari tahap ini adalah daftar nilai pembobotan yang tertuang dalam ‘Weight of HOWs’ dari kriteria kualitas perangkat lunak yang perlu dipertimbangkan dalam pemeringkatan ESB pada tahap selanjutnya. Daftar nilai pembobotan dari ‘Weight of HOWs’ disajikan pada Tabel 5.11. Hasil dari model HoQ 2 adalah nilai pembobotan dari kriteria kualitas yang dimiliki perangkat lunak yang menjadi masukan pada tahap selanjutnya.

Faktor Teknologi

Prioritas

Tabel 5.11 Perhitungan ‘Weight of HOWs’ pada HoQ 2 Kriteria Kualitas Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

T1

5

0

0

5

0

0

0

0

15

T2

3

3

0

9

0

0

0

0

9

T3

14

42

0

0

126

0

0

14

14

T4

6

6

0

0

0

0

18

6

0

T5

13

13

0

117

0

0

0

0

39

T6

11

11

0

0

11

0

0

11

0

T7

12

12

0

0

12

0

0

12

0

T8

1

1

0

0

0

0

0

0

0

T9

9

0

0

81

0

0

0

0

0

T10

10

10

0

30

0

0

0

0

30

T11

8

0

72

0

0

72

0

0

0

T12

4

0

0

0

0

0

36

0

0

T13

2

0

6

0

0

0

0

0

0

T14

7

0

0

0

63

0

0

63

0

0.101

0.080

0.250

0.219

0.074

0.056

0.109

0.110

Nilai Pembobotan



107

5.2

Analisis Hirarki AHP

Berdasarkan kriteria kualitas perangkat lunak yang telah ditetapkan nilai pembobotannya pada ‘Weight of HOWs’ pada HoQ 2, tahap selanjutnya dilakukan perbandingan berpasangan antar subkriteria dalam kriteria yang sama dari kriteria kualitas perangkat lunak. Kemudian, dihitung pembobotannya berdasarkan metode AHP, serta diperiksa nilai rasio konsistensinya. Dari pembobotan kriteria kualitas perangkat lunak ini kemudian dapat dilakukan perbandingan terhadap alternatif pilihan produk middleware ESB. 5.2.1

Pembobotan kriteria kualitas perangkat lunak

Tahap ini dilakukan masih dalam FGD yang kedua. Peserta FGD melakukan pembobotan terhadap subkriteria pada masing-masing kriteria kualitas perangkat lunak, yaitu dengan melakukan perbandingan berpasangan antar subkriteria dalam kriteria yang sama. Nilai pembobotan global dari kriteria utama kualitas perangkat lunak diperoleh dari nilai pembobotan lokal; sedangkan nilai pembobotan global dari subkriteria kualitas perangkat lunak diperoleh dari perbandingan terhadap kriteria utamanya, yaitu dengan cara membagi nilai pembobotan kriteria utama dengan nilai pembobotan untuk masing-masing subkriteria. Nilai pembobotan global dari kriteria utama kualitas perangkat lunak disajikan pada Tabel 5.12. Tabel 5.12 Hasil Pembobotan Kriteria Kualitas Perangkat Lunak Nilai Kode

Kriteria

Pembobotan Lokal

Global

Q1


0.101

0.101

Q2


0.080

0.080

Q3

Compatibility

0.250

0.250

Q4

Usability

0.219

0.219

Q5

Reliability

0.074

0.074



108

Tabel 5.12 Hasil Pembobotan Kriteria Kualitas Perangkat Lunak (sambungan) Nilai Kode

Pembobotan

Kriteria

Lokal

Global

Q6

Security

0.056

0.056

Q7

Maintainability

0.109

0.109

Q8

Portability

0.110

0.110

Perhitungan nilai pembobotan untuk setiap subkriteria kualitas perangkat lunak dijabarkan sebagai berikut: 1. Functional suitability menyatakan ukuran yang terdapat pada perangkat lunak dalam menyediakan fungsi sesuai kebutuhan ketika digunakan dalam kondisi tertentu. Hasil pembobotan subkriteria dalam functional suitability disajikan pada Tabel 5.13. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima. Menurut pendapat para peserta FGD, fungsi dan fitur dalam middleware ESB tidak perlu terlalu banyak, karena fitur standar yang terdapat dalam produk middleware ESB dianggap sudah mencukupi kebutuhan integrasi SIM. Faktor yang lebih penting dalam pemeringkatan middleware ESB ini adalah ketepatan dan kelayakan fungsi dan fitur sesuai kebutuhan. Tabel 5.13 Hasil Pembobotan Subkriteria Functional Suitability Q1.1

Q1.2

Q1.3

1,00

0,50

2,00

1,00

Nilai Pembobotan Lokal

Global

0,11

0,082

0,008

0,20

0,158

0,016

Functional completeness (Q1.1) Functional correctness (Q1.2)



109

Tabel 5.13 Hasil Pembobotan Subkriteria Functional Suitability (sambungan) Q1.1

Q1.2

Q1.3

Nilai Pembobotan Lokal

Global

0,761

0,077

Functional appropriateness (Q1.3)

9,00

5,00

1,00

Nilai Pembobotan Global

0,101

2. Performance efficiency menyatakan ukuran kinerja terhadap jumlah sumber daya yang digunakan dalam kondisi yang ditentukan. Hasil pembobotan subkriteria dalam performance efficiency disajikan pada Tabel 5.14. Tabel 5.14 Hasil Pembobotan Subkriteria Performance Efficiency Nilai Q2.1

Pembobotan

Q2.2

Lokal

Global

Time behaviour (Q2.1)

1,00

3,00

0,750

0,060

Resource utilization (Q2.2)

0,33

1,00

0,250

0,020


0,080

Perhitungan rasio konsistensi diperoleh nilai sebesar 0,05, maka perhitungan ini masih di bawah batas yang dapat diterima. Menurut pendapat para peserta FGD, kecepatan pemrosesan data merupakan hal yang terpenting dalam penerapan middleware ESB ini, karena kondisi saat ini dengan menerapkan web service dirasakan performa pemrosesan data sangat rendah, untuk itu tuntutan performa middleware semakin diperhatikan. 3. Compatibility menyatakan sejauh mana suatu produk, sistem atau komponen dapat saling bertukar informasi dengan produk, sistem, atau komponen lainnya, dan, atau melakukan fungsi yang diperlukan, dalam berbagi perangkat keras atau perangkat lunak dalam lingkungan yang sama. Hasil pembobotan subkriteria dalam compatibility disajikan pada Tabel 5.15.



110

Tabel 5.15 Hasil Pembobotan Subkriteria Compatibility Nilai Q3.1

Pembobotan

Q3.2

Lokal

Global

Co-existence (Q3.1)

1,00

0,14

0,125

0,031

Interoperability (Q3.2)

7,00

1,00

0,875

0,219


0,250

Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima. Menurut pendapat para peserta FGD, interoperabilitas merupakan faktor yang sangat penting. Hal ini disebabkan adanya tuntutan yang sangat tinggi terhadap middleware dalam berinteraksi dengan sistem yang ada, baik di internal maupun eksternal organisasi. 4. Usability menyatakan sejauh mana produk atau sistem dapat digunakan oleh pengguna tertentu untuk mencapai tujuan tertentu secara efektif, efisien, dan kepuasan penggunaan dalam konteks tertentu. Hasil pembobotan subkriteria dalam usability disajikan pada Tabel 5.16. Tabel 5.16 Hasil Pembobotan Subkriteria Usability Nilai Q4.1

Q4.2

Pembobotan

Q4.3 Q4.4

Lokal Global Appropriateness 1,00

0,20

0,20

0,20

0,059

0,013

Learnability (Q4.2)

5,00

1,00

0,33

2,00

0,257

0,056

Operability (Q4.3)

5,00

3,00

1,00

3,00

0,502

0,110

5,00

0,50

0,33

1,00

0,183

0,040


0,219

recognizability (Q4.1)

User error protection (Q4.4)

Perhitungan rasio konsistensi diperoleh nilai sebesar 0,08, maka perhitungan ini masih di bawah batas yang dapat diterima. Menurut pendapat para peserta FGD, Universitas Indonesia


111

kemudahan para pengembang SI/TI dalam mengoperasikan produk middleware ESB merupakan hal yang paling penting, karena 95% pengembangan SIM di BPJS Kesehatan dikerjakan secara in-house development, dan sisanya dikerjakan secara outsource. Untuk itu, kemudahan dalam pengoperasian perangkat lunak sangat diperhatikan di Direktorat TI. 5. Reliability menyatakan sejauh mana sistem, produk atau komponen melakukan fungsi secara spesifik di bawah kondisi tertentu dalam jangka waktu tertentu. Hasil pembobotan subkriteria dalam reliability disajikan pada Tabel 5.17. Tabel 5.17 Hasil Pembobotan Subkriteria Reliability Nilai Q5.1

Q5.2

Q5.3

Q5.4

Pembobotan Lokal

Global

Maturity (Q5.1)

1,00

0,14

0,20

3,00

0,091

0,007

Availability (Q5.2)

7,00

1,00

2,00

7,00

0,524

0,039

5,00

0,50

1,00

7,00

0,336

0,025

0,33

0,14

0,14

1,00

0,049

0,004

Fault tolerance (Q5.3) Recoverability (Q5.4)


0,074

Perhitungan rasio konsistensi diperoleh nilai sebesar 0,06, maka perhitungan ini masih di bawah batas yang dapat diterima. Menurut pendapat para peserta FGD, tingkat ketersediaan operasional perangkat lunak merupakan faktor yang paling penting, karena menyangkut kebijakan SLA yang sudah ditetapkan di Direktorat TI. Selain itu, hal ini menyangkut reputasi organisasi terkait dukungan TI dalam operasional pelayanan peserta di Faskes maupun di Kantor Cabang. 6. Security menyatakan sejauh mana produk atau sistem dalam melindungi informasi dan data sehingga orang, produk, atau sistem lainnya memiliki level akses data sesuai dengan jenis dan level otorisasinya. Hasil pembobotan subkriteria dalam security disajikan pada Tabel 5.18. Universitas Indonesia


112

Tabel 5.18 Hasil Pembobotan Subkriteria Security Nilai Q6.1

Q6.2

Q6.3

Q6.4

Q6.5

Pembobotan Lokal

Global

Confidentiality (Q6.1)

1,00

2,00

3,00

1,00

3,00

0,334

0,019

Integrity (Q6.2)

0,50

1,00

0,33

1,00

2,00

0,138

0,008

Accountability (Q6.3)

0,33

3,00

1,00

1,00

5,00

0,252

0,014

Authenticity (Q6.4)

1,00

1,00

1,00

1,00

2,00

0,200

0,011

Non-repudiation (Q6.5)

0,33

0,50

0,20

0,50

1,00

0,076

0,004


0,056

Perhitungan rasio konsistensi diperoleh nilai sebesar 0,08, maka perhitungan ini masih di bawah batas yang dapat diterima. Menurut pendapat para peserta FGD, faktor keamanan dari sisi akuntabilitas merupakan faktor yang paling penting, karena dengan penerapan teknologi middleware menggunakan ESB, akan semakin banyak channel yang terkoneksi. Untuk itu, perlu diperhatikan kemampuan middleware dalam melacak aksi pihak tertentu yang terkoneksi dengan SIM BPJS Kesehatan. 7. Maintainability menyatakan sejauh mana produk atau sistem dapat secara efektif dan efisien dimodifikasi untuk meningkatkan, memperbaiki, atau beradaptasi dengan perubahan lingkungan sesuai kebutuhan. Hasil pembobotan subkriteria dalam maintainability disajikan pada Tabel 5.19. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,08, maka perhitungan ini masih di bawah batas yang dapat diterima. Menurut pendapat para peserta FGD, testability dan analyzability merupakan faktor yang mempunyai kemiripan karakteristik, dan keduanya sangat berperan penting dalam implementasi integrasi SIM, karena sebagian besar pengembangan SIM di BPJS Kesehatan dikerjakan secara inhouse. Untuk itu, kemudahan dalam pengujian perangkat lunak, analisis jika terjadi kegagalan, kemudahan penelurusan perubahan konfigurasi sangat diperhatikan di Direktorat TI. Universitas Indonesia


113

Tabel 5.19 Hasil Pembobotan Subkriteria Maintainability Nilai Pembobotan Q7.1

Q7.2

Q7.3

Q7.4

Q7.5 Lokal

Global

Modularity (Q7.1)

1,00

3,00

0,20

0,14

0,14

0,062

0,007

Reusability (Q7.2)

0,33

1,00

0,20

0,20

0,17

0,043

0,005

Modifiability (Q7.3)

5,00

5,00

1,00

0,33

0,33

0,176

0,019

Testability (Q7.4)

7,00

5,00

3,00

1,00

1,00

0,355

0,039

Analyzability (Q7.5)

7,00

6,00

3,00

1,00

1,00

0,363

0,040


0,109

8. Portability adalah kriteria kualitas yang mengutamakan efektivitas dan efisiensi suatu sistem dapat dipindahkan dari satu perangkat ke perangkat lainnya. Hasil pembobotan subkriteria dalam portability disajikan pada Tabel 5.20. Tabel 5.20 Hasil Pembobotan Subkriteria Portability Nilai Q8.1

Q8.2

Pembobotan

Q8.3

Lokal

Global

Adaptability (Q8.1)

1,00

0,25

0,20

0,099

0,011

Installability (Q8.2)

4,00

1,00

2,00

0,537

0,059

Replaceability (Q8.3)

5,00

0,50

1,00

0,364

0,040


0,110

Perhitungan rasio konsistensi diperoleh nilai sebesar 0,09, maka perhitungan ini masih di bawah batas yang dapat diterima. Menurut pendapat para peserta FGD, kemampuan dan kemudahan perangkat lunak untuk dipasang pada lingkungan operasional merupakan faktor yang paling penting, karena instalasi middleware ESB dilakukan oleh para pengembang SI/TI di lingkungan internal Direktorat TI.



114

5.2.2

Penilaian terhadap alternatif

Penilaian terhadap alternatif yang terdiri dari 4 produk middleware ESB dilakukan pada sesi POC dengan para penyedia produk middleware ESB. Keempat produk middleware ESB beserta penyedianya disajikan pada Tabel 5.21. Tabel 5.21 Alternatif Produk middleware ESB No

Nama Produk

Versi 10

Merk

1

IIB

2

BizTalk

3

webMethods

9.9

Software AG

4

Oracle SOA Suite

12c

Oracle

2013R2

IBM Microsoft

Spesifikasi perangkat keras yang digunakan pengujian adalah sama untuk setiap pengujian. Pada tahap ini diperoleh nilai response time dan throughput sebagai hasil dari performance testing. Daftar penilaian produk sesuai service performance report dari IBM Rational Performance Tester disajikan pada Tabel 5.22. Selain itu, diperoleh juga jawaban dari daftar pertanyaan yang telah ditetapkan berdasarkan model kualitas perangkat lunak SOAQM yang telah disajikan pada Tabel 3.6.

webMethods

247

1.487

472

398

Response Time [ms] -- Average

3.392,9

6.981,6

3.421,3

4.143,1

6,531

11,325

7.675

6.984

1.883.9

1.976

1.378

1.974

Request Starts -- Count

100

100

100

100

Request Success -- Count

100

100

100

100

Request Timeouts -- Count

0

0

0

0

Request Fails -- Count

0

0

0

0

Response Time [ms] -- Maximum Response Time [ms] -- Standard

Suite

Oracle SOA

BizTalkz

2

Throughput

1

Response Time [ms] -- Minimum

Performance Summary

Response Time

No.

IIB

Tabel 5.22 Hasil Performance Testing ESB

Deviation



115

5.2.3

Pembobotan alternatif terhadap kriteria

Perbandingan alternatif produk middleware ESB terhadap kriteria dilakukan pada FGD yang ketiga yang dihadiri oleh peserta yang sama pada FGD kedua. Masukan penilaian pada pembobotan alternatif produk middleware ESB berdasarkan jawaban dari pertanyaan yang telah ditetapkan dan service performance report pada saat dilakukannya proof of concept dengan pada penyedia produk middleware ESB pada waktu yang berbeda. Selain itu, masukan penilaian diperoleh juga dari service performance report yang terdiri dari response time dan throughput yang diperoleh melalui performance testing terhadap produk middleware ESB. Hasil pembobotan alternatif produk middleware ESB terhadap setiap subkriteria dijelaskan sebagai berikut: 1. Kriteria functional completeness adalah ukuran sejauh mana sekumpulan fungsi perangkat lunak mencakup semua tugas tertentu sesuai dengan tujuan pengguna. Untuk mengukur sejauh mana kelengkapan fungsi yang telah dijelaskan para penyedia produk middleware ESB pada saat POC dalam memenuhi semua kebutuhan, kepada peserta FGD ditampilkan fitur-fitur dasar dari middleware ESB, kemudian peserta FGD melakukan konsolidasi untuk mendapatkan penilaian pada masing-masing produk middleware ESB yang disajikan pada Tabel 5.23.

webMethods

100%

100%

100%

100%

Routing

100%

100%

100%

100%

Mediation

95%

70%

90%

85%

Adapters

95%

85%

95%

90%

Security

75%

65%

70%

75%

Management

75%

60%

70%

75%

Process Orchestration

90%

60%

80%

80%

Suite

BizTalk

Invocation

Fitur

Oracle SOA

IIB

Tabel 5.23 Penilaian Kriteria Functional Completeness



116

webMethods

55%

80%

95%

60%

Integration Tooling

75%

85%

95%

80%

84%

78%

88%

83%

Nilai Rata-rata

Suite

BizTalk

Complex Event Processing

Fitur

Oracle SOA

IIB

Tabel 5.23 Penilaian Kriteria Functional Completeness (sambungan)

Berdasarkan data pada Tabel 5.23, didapatkan nilai tertinggi untuk kriteria functional completeness, yaitu webMethods yang mempunyai fitur paling lengkap. Setelah mendapatkan penilaian dari kelengkapan fungsi yang dimiliki oleh masing-masing middleware ESB, selanjutnya dilakukan pembobotan. Hasil pembobotan kriteria functional completeness disajikan pada Tabel 5.24. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,03, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.24 Pembobotan Subkriteria Functional Completeness

IIB

1,00

2,00

0,20

2,00

0,168

BizTalk

0,50

1,00

0,20

2,00

0,118

webMethods

5,00

5,00

1,00

7,00

0,638

Oracle SOA Suite

0,50

0,50

0,14

1,00

0,076

Suite

Nilai Pembobotan

2. Kriteria functional correctness adalah ukuran sejauh mana produk atau sistem memberikan hasil yang benar dengan tingkat presisi sesuai dengan kebutuhan. Menurut pendapat para peserta FGD, semua produk middleware ESB yang ditawarkan mempunyai dukungan terhadap kriteria functional correctness. BizTalk mempunyai fungsi ‘message pipeline’ untuk mengelola pesan yang masuk dan keluar, fungsi tersebut bisa di dibuat melalui Pipeline Designer. IIB, Universitas Indonesia


117

webMethods, dan Oracle SOA Suite bisa memproses pesan document streaming yang sangat besar. IIB mempunyai kelebihan pada fitur ‘Audit of Messages’ yang bisa melakukan pengecekan terhadap pesan yang diproses. Untuk membuktikan hasil yang diproses sama dengan perhitungan manual, maka pada setiap produk middleware ESB mempunyai fitur laporan. Kelengkapan fitur laporan pada setiap produk middleware ESB berbeda-beda, ada yang dijual terpisah dan ada yang sudah termasuk pada paket penjualan. Hasil pembobotan kriteria functional correctness disajikan pada Tabel 5.25. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,05, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.25 Pembobotan Subkriteria Functional Correctness

IIB

1,00

2,00

2,00

1,00

0.343

BizTalk

0.50

1,00

0.50

1,00

0.172

webMethods

0.50

2,00

1,00

1,00

0.243

Oracle SOA Suite

1,00

1,00

1,00

1,00

0.243

Suite

Nilai Pembobotan

3. Kriteria functional appropriateness adalah ukuran sejauh mana suatu fungsi dapat memfasilitasi tugas dan tujuan yang ditentukan. Menurut pendapat para peserta FGD, semua produk yang ditawarkan mempunyai fitur monitoring terhadap kinerja dan pemakaian sumber daya. Fitur standar monitoring yang dimiliki IIB belum mencukupi kebutuhan, karena fitur yang diperlukan terdapat pada produk tambahan di luar produk yang ditawarkan yaitu IBM Tivoli. Fitur standar yang paling lengkap adalah Oracle SOA Suite. Hasil pembobotan kriteria functional appropriateness disajikan pada Tabel 5.26. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,05, maka perhitungan ini masih di bawah batas yang dapat diterima.



118

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.26 Pembobotan Subkriteria Functional Appropriateness

IIB

1,00

0.50

0.33

0.20

0.087

BizTalk

2,00

1,00

2,00

0.33

0.222

webMethods

3,00

0.50

1,00

0.33

0.174

Oracle SOA Suite

5,00

3,00

3,00

1,00

0.518

Suite

Nilai Pembobotan

4. Kriteria time behaviour menganalisis waktu respons dan waktu pengolahan, dan throughput dari sistem ketika menjalankan fungsinya. Pembobotan kriteria ini diperoleh berdasarkan nilai response time sebagai hasil dari performance testing yang dilakukan juga pada sesi proof of concept. Berdasarkan service performance report dari aplikasi IBM Rational Performance Tester menunjukkan bahwa IIB mempunyai nilai rata-rata response time yang paling kecil, artinya IIB adalah produk middleware ESB yang paling cepat pada saat dilakukannya performance testing. Hasil pembobotan kriteria time behaviour disajikan pada Tabel 5.27. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,03, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.27 Pembobotan Subkriteria Time Behaviour

IIB

1,00

4.00

2,00

3,00

0.459

BizTalk

0.25

1,00

0.33

0.50

0.093

webMethods

0.50

3.00

1,00

3.00

0.305

Oracle SOA Suite

0.33

0.20

0.33

1,00

0.143

Suite

Nilai Pembobotan

5. Kriteria resource utilization adalah kemampuan dalam pengelolaan jumlah dan jenis sumber daya yang digunakan oleh suatu produk atau sistem ketika Universitas Indonesia


119

menjalankan fungsinya. Untuk melakukan pembobotan resource utilization, diperoleh berdasarkan data spesifikasi hardware minimum yang diperlukan untuk menjalankan produk middleware ESB yang ditawarkan. Data tersebut diperoleh pada tahap POC. Kebutuhan hardware minimum ditampilkan pada Tabel 5.28. Tabel 5.28 Kebutuhan Hardware Minimum Hardware

Oracle

IIB

BizTalk

webMethods

5 Core

8 Core

5 Core

4 Core

@2,4 Ghz

@2,4 Ghz

@2,4 Ghz

@2,4 Ghz

Memory

16 GB

48 GB

16 GB

32 GB

Hard disk

300 GB

120 GB

80 GB

100 GB

Processor

SOA Suite

Berdasarkan data pada Tabel 5.30, dilakukan pembobotan kriteria resource utilization yang disajikan pada Tabel 5.29. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,02, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.29 Pembobotan Subkriteria Resource Utilization

IIB

1,00

5,00

0,50

0,33

0,174

BizTalk

0,20

1,00

0,33

0,20

0,080

webMethods

2,00

3,00

1,00

0,50

0,270

Oracle SOA Suite

3,00

5,00

5,00

1,00

0,477

Suite

Nilai Pembobotan

6. Kriteria co-existence adalah sejauh mana suatu produk dapat menjalankan fungsinya secara efisien ketika berbagi sumber daya yang sama dengan produk lainnya tanpa dampak yang merugikan pada produk lainnya. Menurut pendapat para peserta FGD, kriteria co-existence dapat diartikan sebagai kemampuan produk middleware ESB ketika diintegrasikan bersamaan dengan produk Universitas Indonesia


120

perangkat lunak yang lainnya yang sudah digunakan oleh BPJS Kesehatan. Produk IIB, BizTalk, dan Oracle SOA Suite hanya bisa diintegrasikan dengan DBMS dari penyedia yang sama, artinya IIB hanya bisa menggunakan DMBS DB2, BizTalk hanya bisa menggunakan DBMS SQL Server, dan Oracle SOA Suite hanya bisa menggunakan Oracle Database. Berbeda dengan webMethods yang bisa menggunakan produk DBMS manapun. Hasil pembobotan kriteria co-existence disajikan pada Tabel 5.30. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.30 Pembobotan Subkriteria Co-existence

IIB

1,00

1,00

0,11

1,00

0,083

BizTalk

1,00

1,00

0,11

1,00

0,083

webMethods

9,00

9,00

1,00

9,00

0,750

Oracle SOA Suite

1,00

1,00

0,11

1,00

0,083

Suite

Nilai Pembobotan

7. Kriteria interoperability mengacu kepada sejauh mana dua atau lebih sistem bisa bertukar informasi dan menggunakan informasi yang telah dipertukarkan. Menurut pendapat para peserta FGD, semua produk yang ditawarkan mempunyai kemampuan interoperability yang sama, seperti dukungan protocol SOAP, HTTP, FTP, SFTP, SMTP, POP3, SPA, hingga dukungan koneksi B2B healthcare. Kelebihan webMethods adalah dukungan terhadap standar ISO8583 yang biasa digunakan dalam pertukaran data elektronik pada lembaga perbankan. Hasil pembobotan kriteria interoperability disajikan pada Tabel 5.31.



121

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.31 Pembobotan Subkriteria Interoperability

IIB

1,00

1,00

0,33

1,00

0,167

BizTalk

1,00

1,00

0,33

1,00

0,167

webMethods

3,00

3,00

1,00

3,00

0,500

Oracle SOA Suite

1,00

1,00

0,33

1,00

0,167

Suite

Nilai Pembobotan

Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima. 8. Kriteria appropriateness recognizability mengacu kepada sejauh mana pengguna dapat mengenali apakah sistem sesuai dengan kebutuhan. Untuk mengukur sejauh mana penjelasan produk middleware ESB pada saat POC sesuai dengan kebutuhan, kepada peserta FGD ditampilkan daftar kebutuhan non-fungsional dari pemangku kepentingan yang telah disusun pada saat pendefinisian ‘WHATs’ pada HoQ1, dan telah diberi kode untuk masingmasing kebutuhan. Kemudian peserta FGD melakukan konsolidasi untuk mendapatkan penilaian pada masing-masing produk middleware ESB yang disajikan pada Tabel 5.32. Tabel 5.32 Penilaian Subkriteria Appropriateness Recognizability Kebutuhan

Oracle

IIB

BizTalk

webMethods

CA1

50%

50%

95%

50%

CA2

75%

60%

90%

75%

CA3

80%

90%

50%

65%

CA4

75%

60%

90%

75%

CA5

70%

80%

90%

60%

CA6

75%

90%

60%

60%

CA7

95%

95%

95%

95%

SOA Suite



122

Tabel 5.32 Penilaian Subkriteria Appropriateness Recognizability (sambungan) Oracle

Kebutuhan

IIB

BizTalk

webMethods

CA8

90%

60%

80%

95%

CA9

60%

85%

95%

65%

CA10

90%

60%

80%

70%

CA11

60%

80%

95%

65%

CA12

90%

90%

90%

90%

CA13

60%

70%

70%

65%

Nilai Rata-rata

75%

75%

83%

72%

SOA Suite

Berdasarkan data pada Tabel 5.32, didapatkan nilai rat-rata tertinggi untuk kriteria appropriateness recognizability, yaitu webMethods yang mampu memenuhi kebutuhan non-fungsional dari pemangku kepentingan. Setelah mendapatkan penilaian dari pemenuhan kebutuhan dari masing-masing middleware ESB, selanjutnya dilakukan pembobotan. Hasil pembobotan kriteria appropriateness recognizability disajikan pada Tabel 5.33. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,1, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.33 Pembobotan Subkriteria Appropriateness Recognizability

IIB

1,00

1,00

0,20

2,00

0,140

BizTalk

1,00

1,00

0,20

2,00

0,140

webMethods

5,00

5,00

1,00

7,00

0,634

Oracle SOA Suite

0,50

0,50

0,14

1,00

0,077

Suite

Nilai Pembobotan

9. Kriteria learnability terkait dengan tingkat dimana suatu sistem dapat digunakan oleh pengguna tertentu untuk mencapai tujuan tertentu dalam Universitas Indonesia


123

melakukan proses pembelajaran penggunaan sistem dengan mudah. Penilaian kriteria learnability dilakukan berdasarkan ketersediaan materi pembelajaran dalam bentuk toturial, white paper, online manual, presentation, dan help. Menurut pendapat para peserta FGD, IIB dan BizTalk paling banyak ditemukan semua bentuk materi pembelajarannya, Oracle sulit ditemukan toturialnya, karena versi Oracle SOA Suite versi 12c ini merupakan produk yang baru saja dirilis ke pasaran; sedangkan webMethods paling jarang ditemukan semua bentuk materi pembelajarannya. Hasil pembobotan kriteria learnability disajikan pada Tabel 5.34. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,08, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.34 Pembobotan Subkriteria Learnability

IIB

1,00

0,50

5,00

3,00

0.336

BizTalk

2,00

1,00

3,00

3,00

0.428

webMethods

2,00

0,33

1,00

0,33

0.081

Oracle SOA Suite

0,33

0,33

3,00

1,00

0.155

Suite

Nilai Pembobotan

10. Kriteria operability mengacu kepada sejauh mana atribut yang dimiliki suatu produk atau sistem mudah dioperasikan. Menurut pendapat para peserta FGD, webMethods mempunyai tampilan grafis antar muka yang paling mudah dioperasikan, diikuti oleh BizTalk. Oracle SOA Suite mempunyai tampilan yang rumit, walaupun tidak serumit IIB. Hasil pembobotan kriteria operability disajikan pada Tabel 5.35. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,04, maka perhitungan ini masih di bawah batas yang dapat diterima.



124

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.35 Pembobotan Subkriteria Operability

IIB

1,00

0,33

0,20

0,33

0,077

BizTalk

3,00

1,00

0,33

0,33

0,238

webMethods

5,00

3,00

1,00

3,00

0,517

Oracle SOA Suite

3,00

3,00

0,33

1,00

0,168

Suite

Nilai Pembobotan

11. Kriteria user error protection terkait dengan sejauh mana sistem melindungi pengguna terhadap pembuatan kesalahan. Menurut pendapat para peserta FGD, fitur yang dimiliki BizTalk pada kriteria ini adalah ‘Validate schema’ dan ‘Validate instances’ yang bisa mencegah pembuatan schema dan instances XML yang salah pada awal pembuatannya. Begitu juga dengan IBM dan Oracle SOA Suite, fitur ‘Integrated debugging and testing’ yang dimilikinya bisa melakukan validasi pada saat perancangan sehingga bisa mengurangi kesalahan pada saat implementasi dan mempercepat waktu pengujian. Sedangkan webMethods, mempunyai fitur ‘Run Service’ yang berfungsi sama. Hasil pembobotan kriteria user error protection disajikan pada Tabel 5.36. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,05, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.36 Pembobotan Subkriteria User Error Protection

IIB

1,00

2,00

2,00

2,00

0,391

BizTalk

0,50

1,00

2,00

2,00

0,276

webMethods

0,50

0,50

1,00

2,00

0,138

Oracle SOA Suite

0,50

0,50

0,50

1,00

0,195

Suite

Nilai Pembobotan



125

12. Kriteria maturity berkaitan dengan sistem dalam memenuhi kebutuhan mengenai ketersediaan dalam melakukan operasi yang normal, atau dapat diartikan sebagai harapan dari layanan dalam menanggapi permintaan informasi. Pembobotan kriteria ini diperoleh berdasarkan nilai throughput sebagai hasil dari performance testing yang dilakukan juga pada sesi proof of concept. Berdasarkan service performance report dari keluaran aplikasi IBM Rational Performance Tester menunjukkan bahwa semua produk middleware ESB mempunyai nilai throughput yang sama, artinya semua produk middleware ESB mampu menanggapi semua permintaan secara sukses tanpa ada yang gagal ataupun melebihi batas waktu. Hasil pembobotan kriteria maturity disajikan pada Tabel 5.37. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.37 Pembobotan Subkriteria Maturity

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan

13. Kriteria availability adalah pendefinisian sejauh mana sistem, produk atau komponen untuk dioperasikan dan diakses bila diperlukan. Pembobotan kriteria ini diperoleh berdasarkan kemampuan perangkat lunak untuk mengelola antrian permintaan data, atau kemampuan perangkat lunak untuk diintegrasikan dengan perangkat lain untuk mendukung high availability. Menurut pendapat para peserta FGD, semua produk yang ditawarkan mempunyai kemampuan availability yang sama, seperti Microsoft Queue pada BizTalk, Universal Messaging pada webMethods, Java Messaging Service pada Oracle SOA Suite, dan Websphere MQ pada IIB, dan dukungan high availability clusters. Hasil pembobotan kriteria availability disajikan pada Tabel 5.38. Perhitungan rasio Universitas Indonesia


126

konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.38 Pembobotan Subkriteria Availability

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Nilai Suite

Pembobotan

14. Kriteria fault tolerance mengacu pada sejauh mana suatu sistem dapat beroperasi meskipun terjadi kesalahan pada perangkat keras atau perangkat lunak. Pembobotan kriteria ini diperoleh berdasarkan kemampuan perangkat lunak dalam membuat strategi ketika terjadi kesalahan pada perangkat keras atau perangkat lunak. Kemampuan ini bukan pada kemampuan middleware ESB, tetapi pada kemampuan para pengembang dalam merancang dan mengimplementasikan fault tolerance. Menurut pendapat para peserta FGD, semua produk middleware ESB yang ditawarkan mempunyai kemampuan dalam

merancang

dan

mengimplementasikan

fault

tolerance.

Hasil

pembobotan kriteria fault tolerance disajikan pada Tabel 5.39. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.



127

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.39 Pembobotan Subkriteria Fault Tolerance

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan

15. Kriteria recoverability terkait dengan sejauh mana perangkat lunak, produk atau sistem dalam menangani gangguan atau kegagalan melalui pemulihan data secara langsung dan membangun kembali keadaan yang diinginkan. Pembobotan kriteria ini diperoleh berdasarkan kemampuan perangkat lunak dalam memulihkan data ketika terjadi gangguan atau kesalahan sistem. Menurut pendapat para peserta FGD, semua produk yang ditawarkan mempunyai kemampuan recoverability yang sama, seperti dukungan Microsoft Queue pada BizTalk, Universal Messaging pada webMethods, Java Messaging Service pada Oracle SOA Suite, dan Websphere MQ pada IIB yang mampu memulihkan data ketika terjadi gangguan atau kesalahan sistem. Hasil pembobotan kriteria fault tolerance disajikan pada Tabel 5.40. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.40 Pembobotan Subkriteria Recoverability

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan



128

16. Kriteria confidentiality adalah sejauh mana sistem memastikan data yang dapat diakses hanya untuk mereka yang berwenang untuk mengakses. Pembobotan kriteria ini diperoleh berdasarkan kemampuan perangkat lunak untuk diintegrasikan dengan perangkat lain untuk mendukung confidentiality. Menurut pendapat para peserta FGD, semua produk yang ditawarkan mempunyai kemampuan confidentiality yang sama. Confidentiality dalam IIB dikelola oleh WAS Admin Console, BizTalk dikelola oleh BizTalk Server Administration Console, webMethods dikelola dalam Business Console, Oracle SOA Suite dikelola dalam One Admin Server dan One Managed Server SOA. Hasil pembobotan kriteria confidentiality disajikan pada Tabel 5.41. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.41 Pembobotan Subkriteria Confidentiality

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan

17. Kriteria integrity mengacu pada sejauh mana sistem, produk atau komponen mencegah akses yang tidak sah untuk, atau memodifikasi perangkat lunak atau data. Sama seperti kriteria confidentiality, semua produk yang ditawarkan mempunyai kemampuan integrity yang sama yang dikelola oleh suatu fitur khusus. Hasil pembobotan kriteria availability disajikan pada Tabel 5.42. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.



129

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.42 Pembobotan Subkriteria Integrity

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan

18. Kriteria accountability mengacu pada sejauh mana tindakan dari suatu entitas dapat ditelusuri. Menurut pendapat para peserta FGD, semua produk yang ditawarkan mempunyai kemampuan accountability yang sama yaitu fitur audit logging/trails yang disimpan pada audit database. Hasil pembobotan kriteria accountability disajikan pada Tabel 5.43. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.43 Pembobotan Subkriteria Accountability

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan

19. Kriteria authenticity mengacu pada klaim dan identifikasi dari akses subjek atau sumber daya permintaan kepada informasi tertentu. Sama seperti kriteria confidentiality dan integrity, semua produk yang ditawarkan mempunyai kemampuan authenticity yang sama yang dikelola oleh suatu fitur khusus. Hasil pembobotan kriteria authenticity disajikan pada Tabel 5.44. Perhitungan rasio Universitas Indonesia


130

konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.44 Pembobotan Subkriteria Authenticity

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan

20. Kriteria non-repudiation dalam konsep SOA dapat diartikan sebagai kemampuan penyedia layanan untuk membuktikan bahwa informasi telah disampaikan kepada pengguna layanan. Pembobotan kriteria ini diperoleh berdasarkan nilai throughput sebagai hasil dari performance testing yang dilakukan juga pada sesi proof of concept. Berdasarkan service performance report dari keluaran aplikasi IBM Rational Performance Tester menunjukkan bahwa semua produk middleware ESB dapat memastikan jumlah data pada request starts count sama dengan jumlah data pada completed users. Hasil pembobotan kriteria non-repudiation disajikan pada Tabel 5.45. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.45 Pembobotan Subkriteria Non-repudiation

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan



131

21. Kriteria modularity adalah pendefinisian kemampuan sistem yang memiliki dampak minimal ketika terjadi perubahan pada komponen lainnya. Pembobotan kriteria ini diperoleh berdasarkan fitur process orchestration yang dimiliki oleh setiap produk middleware ESB. Fitur process orchestration memungkinkan setiap service dapat dipecah menjadi modul-modul kecil, sehingga perubahan terhadap satu modul berdampak minimal pada modul lain. Menurut pendapat para peserta FGD, IIB mempunyai kemampuan modularity yang paling tinggi, karena terdapat fungsi refactoring yang tidak dimiliki oleh produk middleware ESB lainnya. Hasil pembobotan kriteria modularity disajikan pada Tabel 5.46. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,02, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.46 Pembobotan Subkriteria Modularity

IIB

1,00

5,00

3,00

3,00

0,522

BizTalk

0,20

1,00

0,33

0,33

0,078

webMethods

0,33

3,00

1,00

1,00

0,200

Oracle SOA Suite

0,33

3,00

1,00

1,00

0,200

Suite

Nilai Pembobotan

22. Kriteria reusability menandakan suatu logika dapat digunakan pada lebih dari satu service. Fitur reusability memungkinkan logika yang terdapat pada suatu service dapat digunakan kembali oleh service yang lain. Menurut pendapat para peserta FGD, semua produk yang ditawarkan mempunyai kemampuan reusability yang sama. Hasil pembobotan kriteria reusability disajikan pada Tabel 5.47. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.



132

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.47 Pembobotan Subkriteria Reusability

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan

23. Kriteria modifiability terkait dengan kemampuan perangkat lunak untuk dapat melakukan modifikasi tanpa menimbulkan cacat pada produk yang sudah ada. Pembobotan kriteria ini diperoleh berdasarkan fitur konversi format APIs. IIB, webMethods, dan Oracle SOA Suite dapat melakukan modifikasi format APIs secara mudah; sedangkan BizTalk sangat rumit dan memerlukan proses yang tidak semudah dilakukan pada produk middleware ESB lainnya. Hasil pembobotan kriteria modifiability disajikan pada Tabel 5.48. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.48 Pembobotan Subkriteria Modifiability

IIB

1,00

5,00

1,00

1,00

0,313

BizTalk

0,20

1,00

0,20

0,20

0,063

webMethods

1,00

5,00

1,00

1,00

0,313

Oracle SOA Suite

1,00

5,00

1,00

1,00

0,313

Suite

Nilai Pembobotan

24. Kriteria testability menyatakan bahwa sistem atau komponen dapat dilakukan pengujuan untuk menentukan apakah kriteria tertentu telah dipenuhi. Menurut pendapat para peserta FGD, semua produk middleware ESB yang ditawarkan Universitas Indonesia


133

mempunyai dukungan terhadap kriteria testability, yaitu sudah built in unit testing environment. Fitur testability pada BizTalk adalah ‘Validate schema’ dan ‘Validate instances’ yang bisa mencegah pembuatan schema dan instances XML yang salah pada awal pembuatannya. Begitu juga dengan Oracle SOA Suite, fitur ‘Integrated debugging and testing’ yang dimilikinya bisa melakukan pengujian pada saat perancangan sehingga bisa mengurangi kesalahan pada saat implementasi dan mempercepat waktu pengujian. IBM memiliki ‘Unit test and Regression Test’ yang bisa melakukan penelurusan kesalahan dan skenerio pengujian bisa disimpan untuk keperluan pada masa yang akan datang. Sedangkan webMethods, mempunyai fitur ‘Run Service’. Hasil pembobotan kriteria testability disajikan pada Tabel 5.49. Perhitungan rasio konsistensi diperoleh nilai sebesar 0,08, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.49 Pembobotan Subkriteria Testability

IIB

1,00

2,00

3,00

3,00

0,433

BizTalk

0,50

1,00

3,00

3,00

0,308

webMethods

0,33

0,33

1,00

0,33

0,094

Oracle SOA Suite

0,33

0,33

3,00

1,00

0,165

Suite

Nilai Pembobotan

25. Kriteria analyzability menunjukkan tingkat efektivitas dan efisiensi dengan cara penilaian terhadap dampak pada produk atau sistem atas terjadinya perubahan satu atau lebih bagian, atau untuk mendiagnosa produk atas terjadinya kegagalan, atau untuk mengidentifikasi bagian yang akan perlu untuk dimodifikasi. Pembobotan kriteria ini diperoleh berdasarkan fitur analytics yang dimiliki setiap produk middleware ESB. Oracle SOA Suite mempunyai Business Activity Monitoring dan Event Processing, BizTalk mempunyai BizTalk BAM, IIB sudah mempunyai fitur Operational Decision Management (ODM) yang sudah tertanam dalam perangkat lunak, webMethods mempunyai Universitas Indonesia


134

webMethods API-Portal. Fitur analyzability yang paling lengkap adalah Oracle SOA Suite karena terdapat fitur ‘Event Processing’. Hasil pembobotan kriteria analyzability disajikan pada Tabel 5.50. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.50 Pembobotan Subkriteria Analyzability

IIB

1,00

1,00

1,00

2,00

0,200

BizTalk

1,00

1,00

1,00

2,00

0,200

webMethods

1,00

1,00

1,00

2,00

0,200

Oracle SOA Suite

0,50

0,50

0,50

1,00

0,400

Suite

Nilai Pembobotan

26. Kriteria adaptability mengacu pada sejauh mana produk atau sistem, secara efektif dan efisien dapat disesuaikan untuk perangkat yang berbeda sesuai perkembangan kebutuhan perangkat lunak dan perangkat keras dan perubahan lingkungan operasional. Pembobotan kriteria ini diperoleh berdasarkan kemampuan setiap produk middleware ESB untuk diintegrasikan dengan teknologi cloud computing, berhubung BPJS Kesehatan akan menerapkan teknologi Software as a Service (SaaS). Oracle SOA Suite bisa diintegrasikan dengan teknologi Oracle Cloud maupun dengan teknologi cloud pihak ketiga lainnya, begitu juga dengan IIB dan webMethods. BizTalk hanya bisa diintegrasikan dengan Microsoft Azure. webMethods adalah satu-satunya yang bisa diintegrasikan dengan mainframe computer. Hasil pembobotan kriteria adaptability disajikan pada Tabel 5.51. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.



135

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.51 Pembobotan Subkriteria Adaptability

IIB

1,00

3,00

0,33

1,00

0,194

BizTalk

0,33

1,00

0,33

0,33

0,093

webMethods

3,00

3,00

1,00

5,00

0,534

Oracle SOA Suite

1,00

3,00

0,20

1,00

0,177

Suite

Nilai Pembobotan

27. Kriteria installability berhubungan dengan tingkat efektivitas dan efisiensi produk atau sistem dipasang atau dihapus dalam lingkungan operasional tertentu. Pembobotan kriteria ini diperoleh berdasarkan kemudahan setiap produk middleware ESB untuk dipasang pada perangkat keras. Menurut pendapat para peserta FGD, IIB, webMethods, dan BizTalk sangat mudah untuk dilakukan instalasi. Sedangkan Oracle SOA Suite, meskipun mempunyai tampilan antar muka wizard instalasi yang mudah dipahami, tetapi sering ditemukan error message, sehingga proses instalasi sering dilakukan pengulangan sampai berhasil. Hasil pembobotan kriteria installability disajikan pada Tabel 5.52. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.52 Pembobotan Subkriteria Installability

IIB

1,00

1,00

1,00

3,00

0,300

BizTalk

1,00

1,00

1,00

3,00

0,300

webMethods

1,00

1,00

1,00

3,00

0,300

Oracle SOA Suite

0,33

0,33

0,33

1,00

0,100

Suite

Nilai Pembobotan



136

28. Kriteria replaceability menunjukkan kemampuan perangkat lunak untuk dapat digantikan dengan perangkat lunak lainnya dengan fungsi yang sama dalam lingkungan yang sama. Pembobotan kriteria ini diperoleh berdasarkan kemampuan setiap produk middleware ESB memfasilitasi untuk melakukan import data atau konfigurasi dari produk middleware ESB lainnya. Menurut pendapat para peserta FGD, semua produk middleware ESB tidak bisa melakukan import data atau konfigurasi dari produk middleware ESB lainnya, sehingga untuk kriteria replaceability, semua produk middleware ESB mempunyai nilai pembobotan yang seimbang dan sama. Hasil pembobotan kriteria replaceability disajikan pada Tabel 5.53. Perhitungan rasio konsistensi diperoleh nilai sebesar 0, maka perhitungan ini masih di bawah batas yang dapat diterima.

5.3

IIB

BizTalk

webMethods

Oracle SOA

Tabel 5.53 Pembobotan Subkriteria Replaceability

IIB

1,00

1,00

1,00

1,00

0,250

BizTalk

1,00

1,00

1,00

1,00

0,250

webMethods

1,00

1,00

1,00

1,00

0,250

Oracle SOA Suite

1,00

1,00

1,00

1,00

0,250

Suite

Nilai Pembobotan

Analisis Data

Nilai pembobotan global dari masing-masing kriteria yang telah dilakukan pada tahap pembobotan kriteria kualitas perangkat lunak kemudian dikumpulkan dan disajikan pada Tabel 5.54.



137

Tabel 5.54 Nilai Pembobotan setiap Kriteria Kode

Subkriteria


Q1.1


0.008

Q1.2


0.016

Q1.3


0.077

Q2.1

Time behaviour

0.060

Q2.2


0.020

Q3.1

Co-existence

0.031

Q3.2

Interoperability

0.219

Q4.1


0.013

Q4.2

Learnability

0.056

Q4.3

Operability

0.110

Q4.4


0.040

Q5.1

Maturity

0.007

Q5.2

Availability

0.039

Q5.3

Fault tolerance

0.025

Q5.4

Recoverability

0.004

Q6.1

Confidentiality

0.019

Q6.2

Integrity

0.008

Q6.3

Accountability

0.014

Q6.4

Authenticity

0.011

Q6.5

Non-repudiation

0.004

Q7.1

Modularity

0.007

Q7.2

Reusability

0.005

Q7.3

Modifiability

0.019

Q7.4

Testability

0.039

Q7.5

Analyzability

0.040

Q8.1

Adaptability

0.011

Q8.2

Installability

0.059

Q8.3

Replaceability

0.040 Universitas Indonesia


138

Nilai pembobotan dari masing-masing alternative produk middleware ESB berdasarkan kriteria dikumpulkan dan disajikan pada Tabel 5.55. Tabel 5.55 Nilai setiap Alternatif berdasarkan Kriteria Kode

Kriteria

IIB

BizTalk

webMethods

Oracle SOA Suite

Q1.1


0,168

0,118

0,638

0,076

Q1.2


0.343

0.172

0.243

0.243

0.087

0.222

0.174

0.518

Q1.3


Q2.1

Time behaviour

0.459

0.093

0.305

0.143

Q2.2


0,174

0,080

0,270

0,477

Q3.1

Co-existence

0.083

0.083

0,750

0,083

Q3.2

Interoperability

0,167

0,167

0,500

0,167

0,140

0,140

0,634

0,077

Q4.1


Q4.2

Learnability

0.336

0.428

0.081

0.155

Q4.3

Operability

0,077

0,238

0,517

0,168

Q4.4


0,391

0,276

0,138

0,195

Q5.1

Maturity

0,250

0,250

0,250

0,250

Q5.2

Availability

0,250

0,250

0,250

0,250

Q5.3

Fault tolerance

0,250

0,250

0,250

0,250

Q5.4

Recoverability

0,250

0,250

0,250

0,250

Q6.1

Confidentiality

0,250

0,250

0,250

0,250

Q6.2

Integrity

0,250

0,250

0,250

0,250

Q6.3

Accountability

0,250

0,250

0,250

0,250

Q6.4

Authenticity

0,250

0,250

0,250

0,250

Q6.5

Non-repudiation

0,250

0,250

0,250

0,250

Q7.1

Modularity

0,522

0,078

0,200

0,200

Q7.2

Reusability

0,250

0,250

0,250

0,250

Q7.3

Modifiability

0,313

0,063

0,313

0,313

Q7.4

Testability

0,433

0,308

0,094

0,165

Q7.5

Analyzability

0,200

0,200

0,200

0,400

Q8.1

Adaptability

0,194

0,093

0,534

0,177

Q8.2

Installability

0,300

0,300

0,300

0,100

Q8.3

Replaceability

0,250

0,250

0,250

0,250



139

Setelah diketahui nilai pembobotan masing-masing subkriteria dan masing-masing produk middleware ESB, selanjutnya dilakukan perkalian antara keduanya sehingga memperoleh nilai pembobotan alternatif berdasarkan kriteria yang disajikan pada Tabel 5.56. Tabel 5.56 Pembobotan Alternatif berdasarkan Kriteria Oracle SOA

Kode Kriteria

IIB

BizTalk

webMethods

Q1.1

0.001

0.001

0.005

0.001

Q1.2

0.005

0.003

0.004

0.004

Q1.3

0.007

0.017

0.013

0.040

Q2.1

0.028

0.006

0.018

0.009

Q2.2

0.003

0.002

0.005

0.010

Q3.1

0.003

0.003

0.023

0.003

Q3.2

0.037

0.037

0.110

0.037

Q4.1

0.002

0.002

0.008

0.001

Q4.2

0.019

0.024

0.005

0.009

Q4.3

0.008

0.026

0.057

0.018

Q4.4

0.016

0.011

0.006

0.008

Q5.1

0.002

0.002

0.002

0.002

Q5.2

0.010

0.010

0.010

0.010

Q5.3

0.006

0.006

0.006

0.006

Q5.4

0.001

0.001

0.001

0.001

Q6.1

0.005

0.005

0.005

0.005

Q6.2

0.002

0.002

0.002

0.002

Q6.3

0.004

0.004

0.004

0.004

Q6.4

0.003

0.003

0.003

0.003

Q6.5

0.001

0.001

0.001

0.001

Q7.1

0.004

0.001

0.001

0.001

Q7.2

0.001

0.001

0.001

0.001

Q7.3

0.006

0.001

0.006

0.006

Q7.4

0.017

0.012

0.004

0.006

Q7.5

0.008

0.008

0.008

0.016

Q8.1

0.003

0.003

0.001

0.003

Q8.2

0.018

0.018

0.018

0.006

Q8.3

0.010

0.010

0.010

0.010

Suite



140

Berdasarakan nilai pembobotan alternatif berdasarkan kriteria pada Tabel 5.56, selanjutnya dilakukan normalisasi untuk memperoleh nilai pembobotan untuk setiap alternatif produk middleware ESB yang disajikan pada Tabel 5.57. Tabel 5.57 Normalisasi penilaian Alternatif Oracle SOA

Kode Kriteria

IIB

BizTalk

webMethods

Q1.1

0.17

0.118

0.638

0.08

Q1.2

0.34

0.17

0.24

0.24

Q1.3

0.09

0.22

0.17

0.52

Q2.1

0.46

0.09

0.31

0.14

Q2.2

0.17

0.08

0.27

0.48

Q3.1

0.08

0.08

0.75

0.08

Q3.2

0.17

0.17

0.50

0.17

Q4.1

0.14

0.14

0.64

0.08

Q4.2

0.34

0.43

0.08

0.16

Q4.3

0.08

0.24

0.52

0.17

Q4.4

0.39

0.28

0.14

0.20

Q5.1

0.25

0.25

0.25

0.25

Q5.2

0.25

0.25

0.25

0.25

Q5.3

0.25

0.25

0.25

0.25

Q5.4

0.25

0.25

0.25

0.25

Q6.1

0.25

0.25

0.25

0.25

Q6.2

0.25

0.25

0.25

0.25

Q6.3

0.25

0.25

0.25

0.25

Q6.4

0.25

0.25

0.25

0.25

Q6.5

0.25

0.25

0.25

0.25

Q7.1

0.52

0.08

0.20

0.20

Q7.2

0.25

0.25

0.25

0.25

Q7.3

0.31

0.06

0.31

0.31

Q7.4

0.43

0.31

0.09

0.17

Q7.5

0.20

0.20

0.20

0.40

Q8.1

0.30

0.30

0.10

0.30

Q8.2

0.30

0.30

0.30

0.10

Q8.3

0.25

0.25

0.25

0.25

Nilai Pembobotan

0.259

0.215

0.293

0.233

Suite



141

5.4

Hasil Akhir Pemeringkatan

Setelah mengikuti setiap tahapan dari metode QFD dan AHP, diperoleh hasil akhir pembobotan produk middleware ESB. Dari nilai pembobotan tersebut sudah bisa menentukan peringkat dari masing-masing produk middleware ESB. Hasil akhir pemeringkatan produk middleware ESB disajikan pada Tabel 5.58. Tabel 5.58 Hasil Pemeringkatan Produk Middleware ESB

No.

Nama Produk

Nilai

Urutan

Pembobotan Peringkat

1

IIB

0.259

2

2

BizTalk

0.215

4

3

webMethods

0.293

1

4

Oracle SOA Suite

0.233

3

Berdasarkan Tabel 5.58, webMethods merupakan produk middleware ESB yang mendapat peringkat pertama menurut kriteria yang telah ditetapkan, diikuti oleh IIB, Oracle SOA Suite, dan BizTalk. Terpilihnya webMethods sebagai produk middleware ESB yang memperoleh peringkat pertama, disebabkan kerena seringnya webMethods dalam memperoleh nilai pembobotan paling tinggi dari kriteria kualitas perangkat lunak yang mendapatkan pembobotan nilai paling tinggi dari kebutuhan non-fungsional yang mendapat prioritas kepentingan paling tinggi. webMethods unggul pada 7 subkriteria kualitas perangkat lunak, yaitu functional completeness, co-existence, interoperability, appropriateness recognizability, operability, modifiability, dan installability. Jika merunut kebelakang, 7 subkriteria kualitas perangkat lunak tersebut termasuk kepada kriteria kualitas perangkat lunak yang mendapat pembobotan paling tinggi, yaitu functional suitability, compatibility, usability, maintainability, dan portability. Jika kriteria kualitas perangkat lunak yang mendapat nilai pembobotan paling tinggi dihubungkan dengan faktor teknologi yang mendapat pembobotan paling tinggi dan kebutuhan yang mendapat prioritas paling tinggi, maka webMethods merupakan pemenuhan dari kebutuhan non-fungsional pada produk middleware ESB yang mudah dilakukan konfigurasi, modifikasi, pengelolaan, instalasi, dan penyebaran sistem. Universitas Indonesia


BAB 6 KESIMPULAN DAN SARAN

Bab ini menjelaskan hasil kesimpulan yang diperoleh dari setiap tahapan penelitian untuk menjawab pertanyaan penelitian. Selain itu, dibahas juga saran perbaikan untuk penelitian sejenis atau lanjutan. 6.1

Kesimpulan

Kesimpulan pada bab ini secara spesifik menjawab pertanyaan penelitian yang didapatkan dari proses analisis dan pembahasan penelitian. Berikut ini dijabarkan kesimpulan penelitian. 1. Untuk menjawab pertanyaan penelitian yang pertama, dapat disimpulkan bahwa dalam proses penyusunan model pemeringkatan kualitas middleware ESB yang sesuai dengan kebutuhan BPJS Kesehatan dalam rangka mengoptimalkan integrasi SIM terdiri dari beberapa tahapan yang mencakup hal-hal berikut: a. Penentuan

kebutuhan

dari

pemangku

kepentingan

dan

prioritas

kepentingannya dengan menggunakan konsep pairwise comparison dari metode AHP. Kebutuhan mengenai produk middleware ESB dapat dengan mudah dilakukan konfigurasi, modifikasi, pengelolaan, instalasi, dan penyebaran sistem merupakan kebutuhan non-fungsional yang mendapat priortitas paling tinggi. b. Menerjemahkan kebutuhan dari pemangku kepentingan dengan faktor teknologi dari perangkat lunak dan menilai keterhubungan kebutuhan dari pemangku kepentingan dengan faktor teknologi sehingga menghasilkan nilai pembobotan dari faktor teknologi. Pembobotan faktor teknologi tersebut menggunakan konsep house of quality dari metode QFD. c. Menilai keterhubungan faktor teknologi dengan kriteria kualitas perangkat lunak sehingga menghasilkan nilai pembobotan dari kriteria kualitas perangkat lunak. Kriteria kualitas perangkat lunak megadopsi model 142



143

kualitas SOAQM dan pembobotan kriteria kualitas perangkat lunak menggunakan konsep house of quality dari metode QFD. d. Penilaian kualitas produk middleware ESB dilakukan berdasarkan model kualitas perangkat lunak SOAQM melalui mekanisme proof of concept. e. Pembobotan subkriteria kualitas perangkat lunak menggunakan konsep pairwise comparison dari metode AHP. Subkriteria interoperability merupakan subkriteria kualitas perangkat lunak yang mendapat nilai pembobotan paling tinggi f. Pemeringkatan berbagai alternatif produk middleware ESB berdasarkan subkriteria kualitas perangkat lunak yang telah ditentukan pembobotannya menggunakan konsep pairwise comparison dari metode AHP. 2. Berdasarkan penerapan dari model pemeringkatan kualitas middleware ESB yang telah disusun, diperoleh nilai akhir pemeringkatan produk middleware ESB, sehingga dapat ditentukan pemeringkatan produk middleware ESB yang paling tepat digunakan BPJS Kesehatan untuk menjawab pertanyaan penelitian yang kedua. WebMethods merupakan produk middleware ESB yang mendapat peringkat pertama menurut kriteria yang telah ditetapkan, diikuti oleh IIB, Oracle SOA Suite, dan BizTalk. Dengan demikian, webMethods dari Software AG adalah produk middleware ESB yang paling tepat digunakan BPJS Kesehatan berdasarkan penerapan model pemeringkatan kualitas middleware ESB yang telah disusun pada kesimpulan pertama. 6.2

Saran

Setelah melalui tahapan penelitian yang dilakukan, penulis menganggap penelitian ini jauh dari sempurna dan mempunyai keterbatasan. Keterbatasan penelitian dapat dijelaskan sebagai berikut: 1. Penilaian perangkat lunak pada penelitian ini dilaksanakan berdasarkan kebutuhan non-fungsional dari faktor teknis perangkat lunak dan tidak mempertimbangkan faktor lainnya.



144

2. Penilaian terhadap alternatif produk middleware ESB pada kegiatan proof of concept, dilaksanakan dengan waktu yang terbatas, dan minimnya informasi yang diperoleh karena bergantung kepada kapabilitas ilmu personal dari para penyedia produk middleware ESB. Berdasarkan kesimpulan dan keterbatasan penelitian, terdapat beberapa saran bagi penelitian serupa atau penelitian lanjutan. Saran-saran tersebut dijelaskan sebagai berikut: 1. Pemeringkatan kualitas perangkat lunak pada penelitian ini hanya dilakukan berdasarkan kebutuhan non-fungsional perangkat lunak. Untuk itu, jika diperlukan dapat juga memerhatikan kebutuhan fungsional perangkat lunak. 2. Faktor teknologi yang digunakan pada penelitian ini dapat dikembangkan atau disesuaikan dengan kebutuhan organisasi, sehingga tidak terpaku pada faktor teknologi yang telah ditetapkan pada penelitian ini. 3. Apabila ada penelitian lebih lanjut mengenai pemeringkatan produk perangkat lunak, dapat memerhatikan faktor lain selain fakor teknis, yaitu dengan mempertimbangkan faktor sosial ekonomi, misalnya kapabilitas produk dan penyedia produk perangkat lunak, yang meliputi reputasi produk, tren pasar, training and technical support, layanan purna jual seperti layanan konsultasi dan layanan implementasi. Selain itu, dengan memerhatikan faktor bisnis dalam organisasi, yang meliputi harga, aturan lisensi produk, dan faktor risiko lainnya. 4. Tahap proof of concept yang bertujuan untuk memperoleh informasi karakterisitik perangkat lunak produk middleware ESB, lebih baik dilakukan kepada lebih dari satu penyedia produk pada nama produk yang sama untuk mendapatkan informasi yang lebih lengkap mengenai produk yang akan dilakukan penilaian. Selain itu, service performance report sebagai keluaran performance testing dapat dikembangkan lagi untuk menghasilkan keluaran lain berupa resource usage untuk mengetahui pemakaian sumber daya selama proses pengujian middleware ESB, sehingga performance testing tidak mengeluarkan response time dan throughput saja.



DAFTAR PUSTAKA

Ahuja, S. P., & Patel, A. (2011). Enterprise Service Bus: A Performance Evaluation. Communications and Network, 3(3), 133-140. Alghamdi, A. S., Ahmad, I., & Nasir, M. (2010). Evaluating ESB for C4I Architecture Framework Using Analytic Hierarchy Process. Conference: Proceedings of the 2010 International Conference on Software Engineering Research & Practice (pp. 117-123). Las Vegas: CSREA Press. Alghamdi, A. S., Ahmad, I., & Nasir, M. (2010). Selecting the Best Alternative SOA Service Bus for C4I systems Using Multi-criteria Decision Making Technique. Computational Technologies in Electrical and Electronics Engineering (SIBIRCON), 2010 IEEE Region 8 International Conference , (pp. 790-795). Alghamdi, A., Nasir, M., Ahmad, I., & Nafjan, K. A. (2010). An Interoperability Study of ESB for C4I Systems. Information Technology (ITSim), 2010 International Symposium in (Volume:2 ) (pp. 733-738). Kuala Lumpur: IEEE. Alrawashdeh, T. A., Muhairat, M. I., & Alqatawneh, S. M. (2014). A Quantitative Evaluation of ERP Systems Quality Model. 2014 11th International Conference on Information Technology: New Generations (pp. 46-49). Las Vegas: IEEE. Astrova, I., Koschel, A., & Kruessmann, T. (2010). Comparison of Enterprise Service Buses Based on Their Support of High Availability. Proceedings of the 2010 ACM Symposium on Applied Computing (SAC) (pp. 2495-2496). Sierre: ACM. Benosman, R., Barkaoui, K., & Albriex, Y. (2013). Exploiting concurrency for the ESB architecture. International Conference on Engineering of Complex Computer Systems (pp. 173-176). Singapore: IEEE. 145



146

Bevilacqua, M., Ciarapica, F. E., & Giacchetta, G. (2006). A fuzzy-QFD approach to supplier selection. Journal of Purchasing & Supply Management, 12(1), 14-27. Bhushan, N., & Rai, K. (2004). Strategic Decision Applying the AHP : Applying the Analytic Hierarchy Process. London: Springer. Boehm, B. W., Brown, J. R., & Lipow, M. (1976). Quantitative evaluation of software quality. Proceedings of the 2nd International Conference on Software engineering (pp. 592-605). Los Angeles: IEEE Computer Society Press. BPJS Kesehatan. (2014). IT Master Plan BPJS Kesehatan 2014-2019. BPJS Kesehatan. (2014). Peta Strategi BPJS Kesehatan 2014-2019. BPJS Kesehatan. (2015). Perdir No. 12 Tahun 2015. Breest, M. (2006). An Introduction to the Enterprise Service Bus. Hasso-PlattnerInstitute for IT Systems Engineering, University of Potsdam, Germany. Carnevalli, J. A., & Miguel, P. C. (2008). Review, analysis and classification of the literature on QFD-Types of research, difficulties and benefits. International Journal of Production Economics, 114(2), 737-754. Chappell, D. (2004). Theory in Practice : Enterprise Service Bus. O'Reilly Media. Chappell, D., & Jewell, T. (2002). Java Web Services. O'Reilly. Chua, B. B., & Dyson, L. E. (2004). Applying the ISO 9126 model to the evaluation of an e-learning system. Beyond the comfort zone: Proceedings of the 21st ASCILITE Conference, (pp. 184-190). Perth. Djouab, R., & Bari, M. (2010). An ISO 9126 Based Quality Model for the eLearning Systems. International Journal of Information and Education Technology, 6(5), 370-375.



147

Dromey, G. R. (1995). A Model for Software Product Quality. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, 21(2), 146-163. Erikkson, I., & McFadden, F. (1993). Quality function deployment: a tool to improve software quality. Information and Software Technology, 35(9), 491-498. Erl, T. (2004). Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services. New Jersey: Pearson Education, Inc. Esaki, K. (2013). Verification of Quality Requirement Method Based on the SQuaRE System Quality Model. American Journal of Operations Research, 6(5), 70-79. Franca, J. M., & Soares, M. S. (2015). SOAQM: Quality Model for SOA Applications based on ISO 25010. 17th International Conference on Enterprise Information Systems (ICEIS), (pp. 60-70). Barcelona. Grup SKPTI BPJS Kesehatan. (2016). Laporan Manajemen Grup SKPTI BPJS Kesehatan Januari 2016. Jakarta: Grup SKPTI BPJS Kesehatan. Herzwurm, G., & Schockert, S. (2003). The leading edge in QFD for software and eletronic business. International Journal of Quality & Reliability Management, 20(1), 36-55. Idri, A., Karima, M., & Abran, A. (2013). On the Use of Software Quality Standard ISO/IEC9126 in Mobile Environments. 2013 20th Asia-Pacific Software Engineering Conference (pp. 1-8). Bangkok: IEEE. ISO/IEC. (2001). ISO/IEC 9126-1 Software engineering - Product Quality - Part 1 : Quality Model. Geneva: ISO/IEC. ISO/IEC JTC 1. (2008). ISO/IEC CD 25010: Software engineering-Software product Quality Requirements and Evaluation (SQuaRE) – Software and quality in use models. Tokyo: ISO/IEC JTC 1.



148

ISO/IEC/IEEE. (2011). ISO/IEC/IEEE 42010. Institute of Electrical and Electronics Engineers, Inc. ITIL. (2007). ITIL Version 3 Service Transition. Belfast: The Stationary Office. Jiménez, F. G., Carreras, M. M., & Skarmeta, A. G. (2010). Evaluating Open Source Enterprise Service Bus. IEEE International Conference on EBusiness Engineering (pp. 284-291). Shanghai: IEEE. Juric, M., Loganathan, R., Sarang, P., & Jennings, F. (2007). SOA Approach to Integration : XML, Web services, ESB, and BPEL in real-world SOA projects. Birmingham: Packt Publishing Ltd. Kementrian Kesehatan RI. (2013). Peta Jalan Jaminan Kesehatan Nasional. Kruessmann, T., Koschel, A., Murphy, M., Trenaman, A., & Astrova, I. (2009). High Availability: Evaluating Open Source Enterprise Service Buses. Information Technology Interfaces, 2009. ITI '09. Proceedings of the ITI 2009 31st International Conference on Information Technology Interfaces (pp. 615-620). Dubrovnik: IEEE. Kumar, P. (2012). Aspect-Oriented Software Quality Model: The AOSQ Model. Advanced Computing: An International Journal, 3(2), 105-118. Li, G., Xiao, J., Li, C., Li, S., & Cheng, J. (2012). A Comparative Study between Soft System Bus and Enterprise Service Bus. International Conference on Computer Science and Service System (pp. 557-561). Nanjing: IEEE. Mccall, J. A., Richards, P. K., & Walters, G. F. (1977). Factors In Software Quality. New York: US Rome Air Development Center Reports, US Department of Commerce, USA. Menge, F. (2007). Enterprise Service Bus. Free and Open Source Software Conference, Vol. 2 (pp. 1-6). 1-6.



149

Miguel, J. P., Mauricio, D., & Rodríguez, G. (2014). A Review of Software Quality Models for the Evaluation of Software Products. International Journal of Software Engineering & Applications (IJSEA), 5(6), 31-53. Molyneaux, I. (2009). The Art of Application Performance. Sebastopol: O’Reilly Media, Inc. Negi, N., & Chandra, S. (2014). Web service selection on the basis of QoS parameter. Contemporary Computing (IC3), 2014 Seventh International Conference on Contemporary Computing (pp. 495-500). Noida: IEEE. Parkash, V., Kumar, D., & Rajoria, R. (2013). Statistical Process Control. International Journal of Research in Engineering and Technology, 2(8), 7072. Pemerintah Republik Indonesia. (2004). Undang-Undang Nomor 40 Tahun 2004 tentang Sistem Jaminan Sosial Nasional. Pemerintah Republik Indonesia. (2011). Undang-Undang Nomor 40 Tahun 2011 tentang Badan Penyelenggaran Jaminan Sosial. Rajesh, G., & Malliga, P. (2013). Supplier Selection Based on AHP QFD Methodology.

International

Conference

On

DESIGN

AND

MANUFACTURING (pp. 1283-1292). Elsevier Ltd. Robertson, B., & Sribar, V. (2001). The Adaptive Enterprise : IT Infrastructure Strategies to Manage Change and Enable Growth. Intel Press. Roghanian, E., & Alipour, M. (2014). A fuzzy model for achieving lean attributes for competitive advantages development using AHP-QFD-PROMETHEE. Journal of Industrial Engineering International, 10(1), 1-11. Rotem-Gal-Oz, A. (2012). SOA Patterns. Shelter Island: Manning Publications Co. Saaty, T. (1990). How to make a decision : The Analytical Hierarchy Process. European Journal of Operation Research 48(1), 9-26.



150

Saaty, T. L. (2008). Decision making with the analytic hierarchy process. International Journal Services Sciences, 1(1), 83-98. Sen, C. G., & Baraçli, H. (2010). Fuzzy quality function deployment based methodology for acquiring enterprise software selection requirements. Expert Systems with Applications 37(4), 3415–3426. Sener, Z., & Karsak, E. E. (2012). A decision model for setting target levels in software quality function deployment to respond to rapidly changing customer needs. Concurrent Engineering: Research and Applications, 20(1), 19–29. Siddiqui, Z., Abdullah, A. H., & Khan, M. K. (2011). Qualified Analysis b/w ESB(s) using Analytical Hierarchy Process (AHP) Method. 2011 Second International Conference on Intelligent Systems, Modelling and Simulation (pp. 100-104). Kuala Lumpur: IEEE. Siddiqui, Z., Abdullah, A. H., Khan, M. K., & Alghathbar, K. (2011). Analysis of enterprise service buses based on information security, interoperability and high availability using Analytical Hierarchy Process (AHP) method. Journal of the Physical Sciences, 6(1), 35-42. The Open Group Architecture Framework (TOGAF). (2009). TOGAF Version 9. The Open Group. Whaiduzzaman, M., Gani, A., Anuar, N. B., & Shiraz, M. (2014). Cloud Service Selection Using Multicriteria Decision Analysis. The Scientific World Journal 2014. Zeiss, B., Vega, D., & Schieferdecker, I. (2007). Applying the ISO 9126 Quality Model to Test Specifications: Exemplified for TTCN-3 Test Specifications. Software Engineering, 15(6), 231-244.



LAMPIRAN Lampiran 1: Transkrip wawancara dengan pejabat di Direktorat TI TRANSKRIP WAWANCARA Tujuan

Penggalian informasi kebutuhan produk middleware ESB yang akan digunakan di BPJS Kesehatan.

Narasumber

Pps. Kepala Grup Pengembangan Teknologi Informasi, Direktorat Teknologi Informasi

Tempat

Grup PTI, Gd. Rizali Noor Lt 10, BPJS Kesehatan Kantor Pusat.

Waktu

Selasa, 8 Maret 2016, Pukul 10:30 WIB W

: Pewawancara

N

: Narasumber

W

Bagaimana gambaran integrasi SIM di BPJS Kesehatan saat ini?

N

Integrasi SIM saat ini belum berjalan seabagai mana mestinya. Melihat tuntutan organisasi saat ini yang sangat tinggi, sangat tidak memungkinkan untuk terus mengembangkan SIM menggunakan teknologi yang ada saat ini dalam mengintegrasikan SIM di BPJS Kesehatan.

W

Bisa dijelaskan apa tuntutan organisasi saat ini?

N

Organisasi menuntut untuk membuka channel integrasi SIM dengan pihak eksternal sebanyak-banyaknya, karena hal ini merupakan strategi organisasi dalam meningkatkan reputasi Badan di hadapan para stakeholders, baik pemerintah maupun masyarakat

W

Secara umum, bagaimana kondisi infrastruktur saat ini?

N

Kondisi saat ini, sulit untuk mengintegrasikan sistem antara dua atau lebih sistem jika sistem tidak mempunyai kesamaan database platform, bahasa pemograman, dan konsep pertukaran data. Harus ada persamaan

151



152

Lampiran 1: Transkrip wawancara dengan pejabat di Direktorat TI (lanjutan) Atau mempunyai standar konektivitas pada sistem internal BPJS Kesehatan maupun pada instansi eksternal 1. , sehingga penting untuk mengimplementasikan teknologi baru seperti middleware ESB. W

Dengan kondisi tersebut siapa yang terkena dampak terhadap perbedaan tersebut?

N

Dampaknya terhadap para system development di Departemen PTI, maupun para pengembang di instansi eksternal, seperti di Faskes rumah sakit, klinik, dan puskemas. Kita harus menyediakan service yang mereka butuhkan atau mereka harus menyesuaikan dengan service yang telah kita siapkan. Hal tersebut membuat penyelesaian pengembangan integrasi SIM yang lama. Percepatan waktu pengembangan sistem

2

merupakan hal

yang penting. W

Apa strategi Bapak dalam percepatan waktu pengembangan sistem tersebut?

N:

Dengan alokasi SDM system development di Grup PTI yang minim, sedangkan tuntutan untuk integrasi SIM semakin banyak, maka kita harus memikirkan bagaimana caranya dengan jumlah system development yang minim bisa untuk mendapatkan hasil yang maksimal. Pemanfaatan sumber daya yang ada perlu dilakukan. Untuk itu, setiap penerapan teknologi, harus dapat diintegrasikan dengan pengembangan sistem menggunakan bahasa pemograman yang sudah didukung oleh para pengembang SI/TI di Direktorat TI 3 dan dapat memanfaatkan aplikasi /komponen /modul yang sudah digunakan di Direktorat TI 4.

W

Apa harapan Bapak mengenai produk middleware ESB yang akan digunakan di BPJS Kesehatan?



153

Lampiran 1: Transkrip wawancara dengan pejabat di Direktorat TI (lanjutan) Produk middleware ESB yang akan digunakan harus mempunyai dokumentasi yang lengkap yang dipahami oleh para pengembang sistem dalam melakukan pengembangan dan konfigurasi 5. mempunyai reputasi brand yang bagus, ada pelatihan kepada para pengembang sistem dari pada penyedia produk, selalu mendapatkan dukungan pembaruan perangkat lunak dari para penyedia produk 6, harus sesuai dengan tren pasar saat ini, mudah dilakukan konfigurasi, modifikasi, pengelolaan, instalasi, dan penyebaran sistem 7. Dan ketika ESB sudah diimplementasikan, para penyedia produk harus mau memandu proses implementasi



154

Lampiran 1: Transkrip wawancara dengan pejabat di Direktorat TI (lanjutan) TRANSKRIP WAWANCARA Tujuan

Penggalian informasi kebutuhan produk middleware ESB yang akan digunakan di BPJS Kesehatan.

Narasumber

Kepala Grup Operasional Teknologi Informasi, Direktorat Teknologi Informasi

Tempat

Grup OTI, Gd. Siwabesi Lt 6, BPJS Kesehatan Kantor Pusat.

Waktu

W:

Rabu, 9 Maret 2016, Pukul 9:30 WIB W

: Pewawancara

N

: Narasumber

Berdasarkan Program Kerja TI BPJS Kesehatan 2016, terdapat 6 strategi utama Direktorat TI untuk mendukung misi BPJS Kesehatan pada tahun 2016 ini, diantaranya adalah integrated switching services dan integrated application service melalui penerapan teknologi middleware ESB. Menurut Bapak, apa urgensi untuk mengimplementasikan middleware ESB segera tahun ini?

N:

Selain dua strategi tersebut, Direktorat TI mempunyai 4 strategi lainnya yang berhubungan dengan implementasikan middleware ESB, salah satunya yaitu penerapan Software as a Service. Dengan demikian ketiga strategi tersebut diharuskan untuk bisa mendukung satu sama lainnya.

W:

Jadi selain implementasikan middleware ESB, implementasi SaaS merupakan hal yang urgen juga?

N:

Ya, implementasi SaaS merupakan KPI dari ketiga Grup di Direktorat TI ini, Jadi diharapkan kapabel dari produk middleware ESB dapat diperluas untuk penerapan Software as a Service (SaaS) 8 juga.



155

Lampiran 1: Transkrip wawancara dengan pejabat di Direktorat TI (lanjutan) W:

Faktor apa saja yang perlu mendapat perhatian terhadap implementasi middleware ESB?

N:

Intinya

kita

harus

bisa

secara

efektif

dan

efisien

dalam

mengimplementasikan middleware ESB dengan sumber daya yang ada, misalnya dengan memanfaatkan platform dan infrastruktur yang sudah digunakan di Direktorat TI 9 dan memanfaatkan DBMS yang sudah didukung oleh database administrator dan database developer saat ini di Direktorat TI 10, serta ESB mampu mengadaptasi kinerja sistemnya sesuai beban yang ditopang 11, sehingga kita sudah siap jika terjadi penambahan channel koneksi ke BPJS Kesehatan dari pihak eksternal. W:

Bagaimana dengan pengelolaan keamanan data ? Dengan penambahan channel koneksi yang sudah saya jelaskan kita harus mengantisipasinya dengan memperkuat keamanan, jadi middleware ESB dapat mengimplementasikan standar keamanan informasi Direktorat TI 12.

W:

Apa harapan Bapak mengenai produk middleware ESB yang akan digunakan di BPJS Kesehatan?

N:

Kemudahan operasional, dimana ESB harus mempunyai dokumentasi yang lengkap yang dipahami oleh para pengembang TI di Grup OTI dalam melakukan konfigurasi dan dengan mudah dilakukan konfigurasi, modifikasi, pengelolaan, instalasi, dan penyebaran sistem13 , dan tentu saja harus mempuyai kinerja yang powerfull karna kondisi middleware saat ini sangat rendah dalam segi performa. Untuk itu, harus dapat dibuktikan mempunyai performa yang tinggi 14 karena semua penyedia produk pasti mengatakan produknya paling cepat.



156

Lampiran 2: Transkrip FGD dengan pejabat dan pengembang SI/TI

RISALAH RAPAT

Hari/Tanggal

: Selasa, 22 Maret 2016

Waktu

: 09.00 WIB

Notulis

: Sandi Juniar

Agenda 1. Penjelasan konsep metode QFD dan AHP 2. Penentuan Prioritas kebutuhan non-fungsional 3. Penentuan faktor teknologi untuk memenuhi kebutuhan non-fungsional 4. Penentuan nilai keterhubungan antara kebutuhan non-fungsional dan faktor teknologi 5. Penentuan nilai pembobotan faktor teknologi Peserta 1. Kepala Grup Operasional Teknologi Informasi pada Direktorat Teknologi Informasi 2. Pps. Kepala Grup Pengembangan Teknologi Informasi 3. Kepala Departemen Pengembangan Aplikasi Pendukung 4. Kepala Departemen Quality Assurance 5. System Development Pratama 6. Network Engineer Pratama Hasil 1. Penjelasan konsep metode QFD dan AHP Penjelasan konsep metode QFD dan AHP dalam melakukan pemeringkatan perangkat lunak berdasarkan faktor teknologi dan model kualitas perangkat lunak kepada peserta rapat. Selanjutnya dilakukan tanya jawab mengenai penerapan metode tersebut 2. Penentuan Prioritas kebutuhan non-fungsional Kepada peserta FGD ditampilkan hasil dari wawancara dengan pejabat di lingkungan Direktorat TI, kemudian peserta FGD menentukan ‘Priority of WHATs’ pada HoQ 1 melalui perhitungan berdasarkan pairwise comparison dari metode AHP yakni dengan melakukan perbandingan berpasangan antar



157

Lampiran 2: Transkrip FGD dengan pejabat dan pengembang SI/TI (lanjutan) masing-masing kebutuhan non-fungsional yang menghasilkan nilai pembobotan dan prioritas kepentingannya 3. Penjelasan konsep metode QFD dan AHP Penjelasan konsep metode QFD dan AHP dalam melakukan pemeringkatan perangkat lunak berdasarkan faktor teknologi dan model kualitas perangkat lunak kepada peserta rapat. Selanjutnya dilakukan tanya jawab mengenai penerapan metode tersebut 4. Penentuan Prioritas kebutuhan non-fungsional Kepada peserta FGD ditampilkan hasil dari wawancara dengan pejabat di lingkungan Direktorat TI, kemudian peserta FGD menentukan ‘Priority of WHATs’ pada HoQ 1 melalui perhitungan berdasarkan pairwise comparison dari metode AHP yakni dengan melakukan perbandingan berpasangan antar masing-masing kebutuhan non-fungsional yang menghasilkan nilai pembobotan dan prioritas kepentingannya 5. Penentuan faktor teknologi untuk memenuhi kebutuhan non-fungsional Setelah diketahui nilai prioritas dari kebutuhan non-fungsional dari pemangku kepentingan, selanjutnya ditentukan karakteristik teknis dari perangkat lunak sebagai cara untuk memenuhi kebutuhan tersebut. Masukan karakteristik teknis adalah faktor teknologi dari perangkat lunak, kemudian disepakati penambahan beberapa faktor teknologi selain faktor teknologi yang sudah didaftarkan, sehingga faktor teknologi yang didaftarkan menjadi 14 faktor. 6. Penentuan nilai keterhubungan antara kebutuhan non-fungsional dan faktor teknologi. Dilakukan penilaian keterhubungan antara kebutuhan non-fungsional dan teknologi. Para peserta rapat memberikan penilaian berdasarkan dampak kebutuhan non-fungsional pemangku kepentingan yang mana yang berpengaruh terhadap faktor teknologi dan seberapa pengaruhnya.



158

Lampiran 2: Transkrip FGD dengan pejabat dan pengembang SI/TI (lanjutan) 7. Penentuan nilai pembobotan faktor teknologi Para peserta rapat memberikan penilaian berdasarkan perhitungan antara nilai priortitas kebutuhan non-fungsional dengan hasil keterhubungan antara kebutuhan non-fungsional dan teknologi yang telah dilakukan yang menghasilkan nilai pembobotan faktor teknologi yang perlu mendapat perhatian untuk dipertimbangkan dalam pemeringkatan ESB pada tahap selanjutnya.



159

Lampiran 3: Data Kebutuhan Non-Fungsional yang akan ditentukan prioritasnya Kode Kebutuhan

Kebutuhan

Non-Fungsional

Produk middleware ESB dapat memanfaatkan produk DBMS yang sudah CA1

didukung oleh database administrator dan database developer saat ini di Direktorat TI. Produk middleware ESB dapat diintegrasikan dengan pengembangan

CA2

dengan menggunakan bahasa pemograman yang sudah didukung oleh para pengembang SI/TI di Direktorat TI. Produk middleware ESB mempunyai dokumentasi yang lengkap yang

CA3

dipahami oleh para pengembang SI/TI di Direktorat TI dalam melakukan pengembangan dan konfugurasi. Produk middleware ESB dapat memanfaatkan aplikasi/komponen/modul

CA4

yang sudah digunakan di Direktorat TI. Produk middleware ESB dapat memanfaatkan platform dan infrastruktur

CA5

yang sudah digunakan di Direktorat TI. Produk middleware ESB selalu mendapatkan dukungan pembaruan dari

CA6

para penyedia produk. Produk middleware ESB dapat mendukung standar konektivitas pada

CA7

sistem internal BPJS Kesehatan maupun pada instansi eksternal. Produk middleware ESB dapat menyesuaikan kinerja sistem sesuai beban

CA8

yang ditopang. Produk middleware ESB dapat mendukung percepatan waktu

CA9

pengembangan sistem.

CA10

CA11

CA12

CA13

Produk middleware ESB dapat dibuktikan mempunyai performa yang tinggi. Produk middleware ESB dapat dengan mudah dilakukan konfigurasi, modifikasi, pengelolaan, instalasi, dan penyebaran sistem. Kapabel dari produk middleware ESB dapat diperluas untuk penerapan Software as a Service (SaaS). Produk middleware ESB dapat mengimplementasikan standar keamanan informasi



160

Lampiran 4: Hasil Rekapitulasi Prioritas Kebutuhan Non-Fungsional Kebutuhan Non-Fungsional

Nilai Kepentingan

A

B

A/B

Skala Perbandingan

CA1

CA2

B

5

CA1

CA3

B

3

CA1

CA4

B

7

CA1

CA5

B

3

CA1

CA6

A

2

CA1

CA7

B

9

CA1

CA8

B

4

CA1

CA9

B

9

CA1

CA10

B

9

CA1

CA11

B

9

CA1

CA12

A

2

CA1

CA13

B

3

CA2

CA3

B

2

CA2

CA4

B

2

CA2

CA5

A

3

CA2

CA6

A

7

CA2

CA7

B

2

CA2

CA8

A

3

CA2

CA9

A

2

CA2

CA10

B

3

CA2

CA11

B

9

CA2

CA12

A

7

CA2

CA13

B

3

CA3

CA4

B

3

CA3

CA5

B

2

CA3

CA6

A

4

CA3

CA7

B

3

CA3

CA8

B

1

CA3

CA9

B

3

CA3

CA10

B

5

CA3

CA11

B

7



161

Lampiran 4: Hasil Rekapitulasi Prioritas Kebutuhan Non-Fungsional (lanjutan) Kebutuhan Non-Fungsional

Nilai Kepentingan

A

B

A/B

Skala Perbandingan

CA3

CA12

A

5

CA3

CA13

B

3

CA4

CA5

A

1

CA4

CA6

A

7

CA4

CA7

B

2

CA4

CA8

A

2

CA4

CA9

A

1

CA4

CA10

B

7

CA4

CA11

B

6

CA4

CA12

A

5

CA4

CA13

A

1

CA5

CA6

A

3

CA5

CA7

B

7

CA5

CA8

A

3

CA5

CA9

B

3

CA5

CA10

B

9

CA5

CA11

B

9

CA5

CA12

A

5

CA5

CA13

B

1

CA6

CA7

B

7

CA6

CA8

B

5

CA6

CA9

B

9

CA6

CA10

B

9

CA6

CA11

B

9

CA6

CA12

B

3

CA6

CA13

B

7

CA7

CA8

A

7

CA7

CA9

A

2

CA7

CA10

A

2

CA7

CA11

B

3

CA7

CA12

A

9

CA7

CA13

A

1

CA8

CA9

B

4



162

Lampiran 4: Hasil Rekapitulasi Prioritas Kebutuhan Non-Fungsional (lanjutan) Kebutuhan Non-Fungsional

Nilai Kepentingan

A

B

A/B

Skala Perbandingan

CA8

CA10

B

4

CA8

CA11

B

9

CA8

CA12

A

3

CA8

CA13

B

2

CA9

CA10

A

1

CA9

CA11

B

3

CA9

CA12

A

8

CA9

CA13

A

1

CA10

CA11

B

3

CA10

CA12

A

9

CA10

CA13

A

1

CA11

CA12

A

9

CA11

CA13

A

5

CA12

CA13

B

5



163

Lampiran 5: Hasil Rekapitulasi Nilai Keterhubungan antara Kebutuhan Nonfungsional dan Faktor Teknologi Faktor Teknologi T1

T2

T3

T4

T5

T6

T7

T8

T9

T10

T11

T12

T13

T14

CA1

3

27

0

0

0

0

0

0

0

0

0

0

0

9

CA2

0

0

81

0

0

9

9

0

0

0

9

0

0

9

CA3

0

0

0

0

0

54

54

0

0

0

0

0

0

18

CA4

0

8

72

24

24

0

0

0

24

24

0

0

0

0

CA5

63

21

0

0

21

0

0

0

21

63

0

0

0

0

CA6

0

0

0

0

0

0

0

9

0

0

0

0

0

0

CA7

12

0

0

0

108

0

0

0

108

12

0

12

0

0

CA8

15

0

0

0

15

0

0

0

0

5

45

0

45

0

CA9

0

0

33

0

0

33

33

0

0

0

0

0

0

99

CA10

0

0

0

0

39

0

0

0

13

39

117

0

0

0

CA11

0

0

126

126

0

126

126

0

14

42

0

0

0

28

CA12

18

6

0

0

18

0

2

0

6

18

0

0

0

0

CA13

0

0

0

0

0

0

0

0

0

0

0

90

0

0



164

Lampiran 6: Hasil Rekapitulasi Nilai Pembobotan Faktor Teknologi Kode

Nilai

Faktor Teknologi

Pembobotan

T1

Platform

0.049

T2


0.030

T3


0.142

T4


0.071

T5


0.105

T6

User documentation

0.101

T7


0.102

T8

Versioning

0.005

T9

Interface standard

0.087

T10


0.094

T11

Performance

0.076

T12

Security

0.046

T13

Scalability

0.018

T14

Usability

0.074



165

Lampiran 7: Transkrip FGD dengan pengembang SI/TI di lingkungan Direktorat TI

RISALAH RAPAT

Hari/Tanggal

: Selasa, 29 Maret 2016

Waktu

: 09.00 WIB

Notulis

: Sandi Juniar

Agenda 1. Penjelasan konsep metode QFD 2. Penentuan nilai keterhubungan antara faktor teknologi dan kriteria kualitas perangkat lunak 3. Penentuan nilai pembobotan kriteria kualitas perangkat lunak Peserta 1. System Development Pratama 2. Assisten System Development 3. System Analyst Pratama 4. Application and Database Quality Assurance Pratama 5. Assisten Network and Infrastruktur Quality Assurance 6. Business Analyst Pratama 7. Assisten Network and Infrastructure 8. System Administrator Pratama 9. Network Engineer Pratama Hasil 1. Penjelasan konsep metode QFD Penjelasan konsep metode QFD dalam melakukan penentuan nilai prioritas dan pemobobotan kriteria berdasarkan faktor teknologi dan kulitas perangkat lunak 2. Penentuan nilai keterhubungan antara faktor teknologi dan kriteria kualitas perangkat lunak Para peserta rapat memberikan penilaian berdasarkan keterhubungan faktor teknologi yang mana yang berpengaruh terhadap kriteria kualitas perangkat lunak dan seberapa pengaruhnya



166

Lampiran 7: Transkrip FGD dengan pengembang SI/TI di lingkungan Direktorat TI (lanjutan) 3. Penentuan nilai pembobotan kriteria kualitas perangkat lunak Peserta rapat memberikan nilai pembobotan dari masing-masing kriteria kualitas perangkat lunak yang sudah ditentukan, yang menghasilkan kriteria kualitas

perangkat

lunak

yang

perlu

mendapat

perhatian

untuk

dipertimbangkan dalam pemeringkatan ESB pada tahap selanjutnya



167

Lampiran 8: Hasil Rekapitulasi Nilai Keterhubungan antara Faktor Teknologi dan Kriteria Kualitas Perangkat Lunak

Faktor Teknologi

Kriteria Kualitas Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

T1

0

0

5

0

0

0

0

15

T2

3

0

9

0

0

0

0

9

T3

42

0

0

126

0

0

14

14

T4

6

0

0

0

0

18

6

0

T5

13

0

117

0

0

0

0

39

T6

11

0

0

11

0

0

11

0

T7

12

0

0

12

0

0

12

0

T8

1

0

0

0

0

0

0

0

T9

0

0

81

0

0

0

0

0

T10

10

0

30

0

0

0

0

30

T11

0

72

0

0

72

0

0

0

T12

0

0

0

0

0

36

0

0

T13

0

6

0

0

0

0

0

0

T14

0

0

0

63

0

0

63

0



168

Lampiran 9: Hasil Rekapitulasi Nilai Pembobotan Kriteria Kualitas Perangkat Lunak Kode

Nilai Pembobotan

Kriteria

Q1


0.101

Q2


0.080

Q3

Compatibility

0.250

Q4

Usability

0.219

Q5

Reliability

0.074

Q6

Security

0.056

Q7

Maintainability

0.109

Q8

Portability

0.110



169

Lampiran 10: Hasil Rekapitulasi Nilai Pembobotan Subkriteria Kualitas Perangkat Lunak Kode

Nilai

Subkriteria

Pembobotan

Q1.1


0.008

Q1.2


0.016

Q1.3


0.077

Q2.1

Time behaviour

0.060

Q2.2


0.020

Q3.1

Co-existence

0.031

Q3.2

Interoperability

0.219

Q4.1


0.013

Q4.2

Learnability

0.056

Q4.3

Operability

0.110

Q4.4


0.040

Q5.1

Maturity

0.007

Q5.2

Availability

0.039

Q5.3

Fault tolerance

0.025

Q5.4

Recoverability

0.004

Q6.1

Confidentiality

0.019

Q6.2

Integrity

0.008

Q6.3

Accountability

0.014

Q6.4

Authenticity

0.011

Q6.5

Non-repudiation

0.004

Q7.1

Modularity

0.007

Q7.2

Reusability

0.005

Q7.3

Modifiability

0.019

Q7.4

Testability

0.039

Q7.5

Analyzability

0.040

Q8.1

Adaptability

0.011

Q8.2

Installability

0.059

Q8.3

Replaceability

0.040 Universitas Indonesia


170

Lampiran 11: Hasil Rekapitulasi Pengujian Perfoma 1. IIB

2. BizTalk

3. webMethod



171

Lampiran 11: Hasil Rekapitulasi Pengujian Perfoma (lanjutan) 4. Oracle



172

Lampiran 12: Lembar Pertanyaan wawancara dengan Penyedia Produk Middleware ESB pada saat POC No.

Pertanyaan

Penjelasan Produk

1

Fitur apa saja yang tersedia pada produk ESB yang ditawarkan?

2

Bagaimana fitur yang tersedia pada produk ESB tersebut yang bisa

memberikan

sesuai

hasil

dengan

yang

kebutuhan

organisasi? 3

Bagaimana fitur yang tersedia pada

produk

ESB

yang

ditawarkan bisa memenuhi tugas tertentu dalam mendukung proses bisnis organisasi? 4

Seberapa cepat waktu respons dari produk ESB yang ditawarkan ketika dioperasikan?

5

Bagaimana produk ESB yang ditawarkan dalam memanfaatkan sumber daya secara efisien?

6

Bagaimana layanan dari ESB yang ditawarkan bisa digunakan secara bersamaan?

7

Bagaimana

interoperabilitas

produk ESB yang ditawarkan dalam berinteraksi dengan sistem lainnya? 8

Bagaimana

kelayakan

produk

ESB yang ditawarkan dalam memenuhi

kebutuhan

yang

diinginkan? Universitas Indonesia


173

Lampiran 12: Lembar Pertanyaan wawancara dengan Penyedia Produk Middleware ESB pada saat POC (lanjutan) No.

Pertanyaan

9

Sejauh mana layanan produk ESB

Penjelasan Produk

yang ditawarkan bisa dengan mudah dipahami oleh pengguna? 10

Bagaimana

kemudahan

pengoperasian produk ESB yang ditawarkan? 11

Bagaimana layanan produk ESB yang ditawarkan dalam mencegah kesalahan input yang salah?

12

Bagaimana produk ESB yang ditawarkan

dalam

melayanani

permintaan bisa ditanggapi sesuai harapan? 13

Bagaimana produk ESB yang ditawarkan dalam menyediakan layanan ketika diminta?

14

Bagaimana produk ESB yang ditawarkan mampu mempertahankan tingkat kinerja tertentu jika terdapat kesalahan pada perangkat lunak dan perangkat keras?

15

Bagaimana produk ESB yang ditawarkan melanjutkan proses dan memulihkan data jika terkena dampak dari kegagalan sistem?

16

Bagaimana pengaturan layanan informasi bersama oleh penyedia



174

Lampiran 12: Lembar Pertanyaan wawancara dengan Penyedia Produk Middleware ESB pada saat POC (lanjutan) No.

Pertanyaan

Penjelasan Produk

layanan dapat diakses hanya untuk klien resmi? 17

Bagaimana pengaturan produk ESB yang ditawarkan dalam mencegah akses yang tidak sah?

18

Bagaimana layanan dari produk ESB yang ditawarkan bisa menyimpan data akses?

19

Bagaimana produk ESB yang ditawarkan dalam mencegah akses dari yang tidak berhak?

20

Bagaimana produk ESB yang ditawarkan dalam membuktikan bahwa informasi telah dikirim kepada pengguna layanan?

21

Bagaimana modul-modul dari produk ESB yang ditawarkan dapat dipasang dan diimplementasikan sebagai sistem tunggal?

22

Bagaimana modul yang terdapat pada produk ESB yang ditawarkan dapat digunakan kembali pada proyek yang sedang atau akan dikembangkan?

23

Bagaimana karakteristik produk ESB

yang

ditawarkan

bisa

mengurangi ketergantungan antar layanan? Universitas Indonesia


175

Lampiran 12: Lembar Pertanyaan wawancara dengan Penyedia Produk Middleware ESB pada saat POC (lanjutan) No. 24

Pertanyaan Bagaimana

modul

Penjelasan Produk perangkat

lunak yang telah dimodifikasi dalam ESB yang ditawarkan mudah dilakukan pengujian? 27

Bagaimana produk ESB yang ditawarkan dalam menganalisis dampak perubahan ketika layanan perlu untuk dilakukan modifikasi?

26

Bagaimana produk ESB yang ditawarkan

dalam

beradaptasi

dengan perubahan platform? 27

Bagaimana instalasi produk ESB yang

ditawarkan

jika

terjadi

perubahan platform? 28

Bagaimana instalasi produk ESB yang

ditawarkan

jika

terjadi

pergantian platform?



176

Lampiran 13: Transkrip FGD dengan pengembang SI/TI di lingkungan Direktorat TI

RISALAH RAPAT

Hari/Tanggal

: Selasa, 5 April 2016

Waktu

: 09.00 WIB

Notulis

: Sandi Juniar

Agenda Penilaian alternatif produk middleware ESB berdasarkan kriteria Peserta 1. System Development Pratama 2. Assisten System Development 3. System Analyst Pratama 4. Application and Database Quality Assurance Pratama 5. Assisten Network and Infrastruktur Quality Assurance 6. Business Analyst Pratama 7. Assisten Network and Infrastructure 8. System Administrator Pratama 9. Network Engineer Pratama Hasil Peserta rapat memberikan penilaian terhadap alternatif-alternatif pilihan produk middleware ESB dengan menggunakan metode pairwise comparison AHP berdasarkan kriteria yang telah ditetapkan. Masukan informasi penilaian terhadap alternatif-alternatif pilihan diperoleh dari jawaban dari pertanyaan yang telah disusun sebelumnya dan hasil pengujian performa pada saat dilakukannya POC dengan para penyedia produk middleware ESB



177

Lampiran 14: Hasil Rekapitulasi Nilai Alternatif Kode

Kriteria

IIB

BizTalk

webMethods

Oracle SOA Suite

Q1.1


0,168

0,118

0,638

0,076

Q1.2


0.343

0.172

0.243

0.243

0.087

0.222

0.174

0.518

Q1.3


Q2.1

Time behaviour

0.459

0.093

0.305

0.143

Q2.2


0,174

0,080

0,270

0,477

Q3.1

Co-existence

0.083

0.083

0,750

0,083

Q3.2

Interoperability

0,167

0,167

0,500

0,167

0,140

0,140

0,634

0,077

Q4.1


Q4.2

Learnability

0.336

0.428

0.081

0.155

Q4.3

Operability

0,077

0,238

0,517

0,168

Q4.4


0,391

0,276

0,138

0,195

Q5.1

Maturity

0,250

0,250

0,250

0,250

Q5.2

Availability

0,250

0,250

0,250

0,250

Q5.3

Fault tolerance

0,250

0,250

0,250

0,250

Q5.4

Recoverability

0,250

0,250

0,250

0,250

Q6.1

Confidentiality

0,250

0,250

0,250

0,250

Q6.2

Integrity

0,250

0,250

0,250

0,250

Q6.3

Accountability

0,250

0,250

0,250

0,250

Q6.4

Authenticity

0,250

0,250

0,250

0,250

Q6.5

Non-repudiation

0,250

0,250

0,250

0,250

Q7.1

Modularity

0,522

0,078

0,200

0,200

Q7.2

Reusability

0,250

0,250

0,250

0,250

Q7.3

Modifiability

0,313

0,063

0,313

0,313

Q7.4

Testability

0,433

0,308

0,094

0,165

Q7.5

Analyzability

0,200

0,200

0,200

0,400

Q8.1

Adaptability

0,300

0,300

0,100

0,300

Q8.2

Installability

0,300

0,300

0,300

0,100

Q8.3

Replaceability

0,250

0,250

0,250

0,250



UNIVERSITAS INDONESIA

Recommend Documents