BAB IV HASIL DAN PEMBAHASAN
4.1
Hasil Wawancara dengan Developer dan Pengguna Wawancara dilakukan terhadap dua orang developerweb survey PT. Kalbe
Morinaga Indonesia dengan pertanyaan yang sama dengan kuesioner, wawancara berlangsung kurang lebih 20 menit untuk masing-masing orang. Wawancara dilakukan untuk mengumpulkan data sekaligus pengecekan data hasil kuesioner sebagai salah satu bentuk metode triangulasi yang dilakukan. Sedangkan untuk wawancara yang dilakukan terhadap administrator atau orang yang menggunakan sistem ini secara langsung, Ibu Kus Niarti Handayani selaku kepala divisi Human Resource and Development PT. Kalbe Morinaga Indonesia. Beliau mengatakan bahwa masih banyaknya fitur yang kurang memuaskan terutama di bagian penarikan laporan. Hal ini mempengaruhi kinerja divisi HRD di akhir tahun karena hasil dari laporan survey ini akan digunakan untuk melakukan kalkulasi KPI (Key Performance Index) dari masing-masing karyawan. Di sisi lain, masih sulitnya sinkronisasi data karyawan karena selama ini terjadi redundansi data karyawan di dalam aplikasi web survey dengan aplikasi Pro-INT. Hasil wawancara menunjukkan memang adanya kesulitan dari developer untuk memenuhi harapan pengguna terutama dari segi responsiveness dan assurance aplikasi web survey PT. Kalbe Morinaga Indonesia. Developer menganggap bahwa rentannya aplikasi dalam memberikan respon yang cepat
45
46
terhadap user lebih dikarenakan oleh permasalahan Operating System yang digunakan oleh PT. Kalbe Morinaga Indonesia, yakni Windows Server 2008 sedangkan di sisi lain aplikasi web survey menggunakan teknologi PHP dengan web server XAMPP. Namun karena keterbatasan yang ada karena regulasi yang terjadi perubahan Operating System Server dan web server dari aplikasi web survey tidak mungkin dilakukan. Hal ini berarti pengkajian hanya akan dilakukan dari area teknis aplikasi.
4.2
Analisis Web Survey
4.2.1 Analisis Fungsionalitas Web Dari evaluasi yang telah dilakukan baik dari kuesioner maupun wawancara, dapat dilihat bahwa beberapa aspek yang dianggap kurang oleh pengguna dan developer. Dari berbagai jenis masukkan tersebut, dilakukan analisa fungsionalitas terhadap web survey PT. Kalbe Morinaga Indonesia. Tes fungsionalitas ini menggunakan metode black box testing, di mana setiap halaman web akan dicoba untuk dibuka dan dimasukkan input secara sembarang untuk menemukan kesalahan-kesalahan yang muncul. Berikut ini adalah beberapa kesalahan fungsionalitas yang ditangkap ketika melakukan testing : 1.
Terjadi kesalahan logika pada web survey ketika sorting data dilakukan. Fitur sorting data hanya berguna untuk mengurutkan data yang terdapat pada satu halaman itu saja.
47
Gambar 4.1 Tampilan Web SurveySebelum Diurutkan
Gambar 4.2 Tampilan Web Survey Setelah Diurutkan
Hal ini terjadi di setiap halaman web yang memiliki fitur sort, di mana seharusnya ketika pengurutan dilakukan maka semua data akan diurutkan. Namun pada aplikasi web survey ini data yang diurutkan hanya data yang terdapat pada halaman yang dibuka saja, sehingga ketika web dipindah ke
48
halaman berikutnya maka data tidak terurut kembali. Hal ini menyulitkan pengguna karena biasanya fitur pengurutan dibutuhkan untuk mencari data ataupun menggunakan data secara berurut untuk kepentingan tertentu.
2.
Terjadi error ketika melakukan import data di dalam fitur manajemen pegawai. Error muncul karena file excel yang dimasukkan tidak sesuai dengan format umum yang dapat diterima program.
Gambar 4.3 Tampilan Error Web Survey Ketika Melakukan Import Data
Tampilan di atas menunjukkan bahwa halaman web menunjukkan error yang tidak semestinya dimunculkan karena akan membingungkan pengguna. Pesan timbal balik yang dikembalikan oleh halaman web tidak sesuai dengan kebutuhan pengguna, karena pesan error tersebut bersifat teknis. Pengguna akan mengalami kebingungan apabila melihat error seperti di atas, harusnya pesan error yang dimunculkan tidak memunculkan pesan teknis seperti yang tertera pada gambar di atas.
49
3.
Tampilan yang berbeda dengan browser yang berbeda. Berikut ini adalah tampilan yang muncul akibat penggunaan browser Internet Explorer 10 dan Google Chrome.
Gambar 4.5 Tampilan Web Survey di Browser IE 10
Gambar 4.6 Tampilan Web Survey di Browser Google Chrome
50
Gambar 4.4 Tampilan Normal Web Survey di Firefox
Ketika melihat tampilan di atas, hal ini menunjukkan bahwa aplikasi tidak mendukung interopability. Tampilan pada bagian bawah web terlihat menyambung pada gambar 4.15, sedangkan pada gambar 4.16 terlihat tampilan yang salah pada bagian header web karena garis background memotong tulisan header. Apabila dibandingkan dengan tampilan normal di gambar 4.17, di mana web dibuka dengan browser firefox maka hal ini telah membuktikan bahwa aplikasi web survey PT. Kalbe Morinaga Indonesia belum sepenuhnya mendukung konsep cross browser. Sehingga apabila client memiliki keterbatasan dalam hal penggunaan browser atau menggunakan browser yang berbeda, maka dapat menurunkan tingkat kepuasan pengguna dari sisi tampilan.
51
4.
Terjadi error ketika penarikkan data laporan, percobaan berikut merupakan contoh penarikan data dari tanggal 1 Agustus 2010 sampai dengan 21 February 2013.
Gambar 4.5 Tampilan Web Survey Ketika Menarik LaporanSurvey
Gambar di atas menunjukkan adanya pesan error teknis yang kembali muncul ketika melakukan penarikan data laporan. Menurut pengguna, pesan teknis ini kerap muncul dalam penarikan laporan sehingga kadang menyulitkan pengguna dalam menarik laporan.
4.2.2 Analisis Non-Fungsional Web Untuk melakukan analisis ini, maka analisis struktur aplikasi dalam server PT. Kalbe Morinaga Indonesia. Data mengenai arsitektur dari web survey PT. Kalbe Morinaga Indonesia ini didapatkan dengan melakukan wawancara langsung terhadap supervisor IT PT. Kalbe Morinaga Indonesia, Ibu Diana Susanti.
52
Web
survey
hanya
dapat
diakses
secara
internal
lewat
link
http://10.175.12.25/kmi, di mana server ini bertugas untuk menyimpan fileaplikasi. Server ini adalah milik divisi IT yang bertugas untuk melayani request dari user. Sedangkan untuk database, akan disimpan di dalam server dengan IP 10.175.11.45. Server ini adalah server milik divisi HRD, di mana tidak sembarangan orang punya akses masuk ke dalam server ini. Tujuan pemisahan antara server aplikasi dengan database adalah agar adanya pembagian beban kerja serta pemisahan hak akses. Karena web survey berada di bawah naungan divisi HRD, maka data dari divisi HRD tidak boleh sembarangan dibuka ke pihak atau divisi lain.
Gambar 4.6 Arsitektur Aplikasi Web Survey PT. Kalbe Morinage Indonesia
Berikut ini adalah spesifikasi server aplikasi yang digunakan oleh web survey PT. Kalbe Morinaga Indonesia :
53
Table 4.1 Spesifikasi Server Aplikasi Processor
Intel Xeon Quad Core E3-1220 (3.10 GHz, 80W, 8M)
Memory
2 x DDR3 2 GB SATA RAID
Software
Windows Server 2008, XAMPP, Pro-INT
Table 4.2 Spesifikasi Server Database Processor
Intel Dual Core G6950 (2.80GHz, 73W, 3MB, 1066)
Memory
2 x DDR3 1 GB SATA RAID
Software
Windows Server 2008, XAMPP
Pada dasarnya kriteria server PT. Kalbe Morinaga Indonesia telah memenuhi standar yang telah ada, hal ini dikarenakan PT. Kalbe Morinaga Indonesia telah merancang jaringan dan server secara baik. Yang dapat dijadikan pertimbangan lebih lanjut oleh pihak PT. Kalbe Morinaga Indonesia adalah Operationg System yang digunakan untuk menjalankan aplikasi web survey dengan platform PHP. Menurut Lee, J. (Desember, 2012) aplikasi yang didasarkan oleh PHP akan meningkat performanya apabila menggunakan web server Linux yang menggunakan engine web server Nginx. Pada keterangan tabel 4.21 terlihat bahwa web server yang digunakan adalah XAMPP, tentu hal ini dapat dijadikan masukkan untuk melakukan perubahan web server di server PT. Kalbe Morinaga Indonesia. Namun karena adanya batasan regulasi, hal ini tidak dapat dilakukan.
54
4.2.2.1 Analisis Performa Aplikasi Survey Untuk melakukan analisis performa akan digunakan alat bantu berupa software otomasi open source bernama Jmeter. Software ini mendukung virtualisasi pengaksesan web berdasarkan jumlah user virtual, halaman web per user, serta jumlah pengaksesan dari user itu sendiri. Software Jmeter akan ditempatkan pada satu komputer di PT. Kalbe Morinaga Indonesia, untuk menangkap besaran-besaran variabel yang telah ditentukan sebelumnya. Adapun variabel-variabel tersebut adalah besaran minimum waktu pengaksesan per halaman, waktu maksimum, rata-rata waktu, besaran throughput, serta standar deviasi. Adapun komputer yang digunakan untuk melakukan uji coba performa memiliki spesifikasi seperti yang tercantum pada tabel 4.23 berikut.
Table 4.3 Spesifikasi Server Database Processor
Intel Core 2 Duo T5900 (2.20GHz, 35W, 2MB)
Memory
2 x DDR2 1 GB SATA RAID
Operating System
Windows 8
Untuk memulai tes performa, maka ditentukan terlebih dahulu tetapantetapan nilai yang berlaku ketika melakukan tes. Tetapan tersebut antara lain adalah tetapan link utama (base url) dari web yang ingin diuji, port dari link utama, total threads atau virtual user yang mengakses, pembebanan RAM, jumlah
55
pengaksesan per user, serta variabel-variabel tambahan lain yang akan digunakan untuk uji coba.
Gambar 4.6 Tampilan awal Jmeter dengan User Defined Variables
Gambar di atas (Gambar 4.6) menunjukkan pengujian akan melakukan pengaksesan pada url 10.175.12.25/kmi dengan port 80. Jumlah virtual user yang mengakses adalah 10 user, besaran pembebanan RAM adalah 10 kali dan jumlah pengaksesan per user adalah sebesar satu kali. Sedangkan sisanya adalah variabelvariabel yang akan digunakan untuk melakukan otentikasi dan otorisasi ketika melakukan pengaksesan ke semua halaman web.
56
Gambar 4.7 Test Plan Web Survey PT. Kalbe Morinaga Indonesia
4.2.2.1.1 Uji Coba dengan 10 Virtual User Setelah dilakukan inisialisasi nilai awal, maka test plan akan dilakukan pada setiap halaman web yang terdapat dalam PT. Kalbe Morinaga Indonesia. Semua halaman web ini akan diakses dan dimasukkan input sesuai dengan kebutuhan lalu dicek seberapa besar nilai dari variabel-variabel yang telah
57
ditentukan sebelumnya. Apabila telah didapatkan maka, selanjutnya adalah mencari permasalahan mendasar dari halaman-halaman yang mengalami waktu pemrosesan yang besar (berdasarkan kriteria rerata dari halaman lainnya).
Gambar 4.8 Hasil dari Summary Test Plan Gambar 4.8 adalah hasil dari summary test plan yang telah dilakukan dengan simulasi 10 virtual user. Besaran waktu yang tercantum pada gambar di atas dalam millisecond. Dari gambar di atas dapat dilihat bahwa halaman report dinilai, menilai dan halaman report builder ESI menunjukkan rata-rata waktu respon yang paling tinggi yakni 12.815, 7.503 serta 4.879 millisecond. Hal ini sesuai dengan kesimpulan yang ditarik dari kuesioner user bahwa aplikasi web survey mengalami kelemahan di bagian respon web dan juga bahwa sulitnya pengguna untuk menarik laporan dari website. Selain itu hasil dari summary test plan menunjukkan bahwa tingkat error tertinggi ditunjukkan juga oleh halaman report dinilai dan menilai, yakni sebesar 80%. Hal ini sama dengan hasil uji coba fungsionalitas yang telah dilakukan, di mana banyak error yang ditangkap ketika melakukan uji coba untuk memasukkan data secara buta ke dalam halaman web
58
untuk menarik report. Dari gambar 4.8 didapatkan grafik performa dari response time.
Gambar 4.9 Response Time Graph
Gambar 4.9 menunjukkan waktu yang dibutuhkan oleh Jmeter untuk melakukan pengaksesan halaman. Dari grafik, dapat dilihat bahwa waktu yang dibutuhkan untuk menyelesaikan semua tugas yang diberikan ditunjukkan oleh halaman report builder ESI. Sedangkan halaman dengan total waktu terbesar ketika melakukan request adalah halaman report dinilai dan report menilai menempati urutan kedua waktu terbanyak untuk melakukan request. Dengan bentang waktu antara pukul 22:44:30 sampai dengan pukul 22:45:10.
59
Gambar 4.10 Aggregate Average Rate Graph
Gambar 4.10 merupakan bentuk diagram batang untuk menunjukkan waktu rata-rata dari masing-masing virtual user untuk mengakses halaman website. Halaman report dinilai, menilai serta halaman report builder ESI menunjukkan waktu rata-rata respon dari web yang tertinggi dibandingkan dengan halaman lain.
Gambar 4.11 Grafik Total Transfer Rate
60
Gambar 4.11 menunjukkan kecepatan transfer data dari pengaksesan masing-masing halaman web. Gambar di atas menunjukkan besarnya transfer rate yang dibutuhkan dari halaman report dinilai dan menilai. Dari grafik dapat dilihat bahwa kecepatan transfer dari halaman report dinilai, menilai dan ESI menempati urutan terendah dalam kecepatan transfer datanya. Hal ini bisa menunjukkan lambatnya waktu pemrosesan halaman tersebut dibandingkan dengan halaman lainnya.
Gambar 4.12 Grafik Total Throughput
Gambar 4.12 menunjukkan besaran throughput atau rerata kecepatan pengiriman data yang sukses dari masing-masing halaman web. Semakin tinggi rerata kecepatan maka semakin baik, namun terlihat kembali bahwa halaman report dinilai dan menilai memiliki kecepatan pengiriman data yang lebih lambat dibandingkan dengan halaman lainnya. Maka dapat disimpulkan bahwa halaman report dinilai dan menilai memang mengalami waktu pemrosesan yang lebih lama ketimbang halaman lainnya.
61
4.2.2.1.2Uji Coba dengan 60 Virtual User Kesimpulan yang dapat ditarik dari percobaan simulasi tes performa dari web survey PT. Kalbe Morinaga Indonesia adalah perlunya diadakan perbaikan pada halaman web report dinilai, menilai serta report builder ESI. Namun untuk memastikannya, akan diadakan simulasi ulang dengan jumlah thread atau virtual user sebesar 60 virtual user sebagai bentuk realisasi dari pengaksesan beruntun apabila web survey dibuka oleh seluruh karyawan. Gambar 4.13 adalah gambar yang menunjukkan hasil realisasi dari tes performa dengan jumlah virtual user sebesar 60 karyawan.
Gambar 4.13 Hasil dari Summary Test Plan 60 Threads
Gambar 4.13 adalah hasil dari summary test plan dari jumlah 60 virtual user. Dari gambar di atas dapat dilihat bahwa halaman report dinilai, menilai dan halaman employee menunjukkan rata-rata waktu respon yang paling tinggi yakni 20.480, 15.839 serta 14.243 millisecond. Hasil ini sedikit berbeda dengan hasil tes performa dengan 10 virtual user, di mana hasil yang ditunjukkan oleh tes tersebut
62
halaman web report builder ESI menempati urutan tertinggi ketiga. Hasil dari summary test plan ini juga menunjukkan bahwa tingkat error tertinggi ditunjukkan juga oleh halaman report dinilai dan menilai, yakni sebesar 21.67% dan 30.00%. Hal ini sama dengan hasil uji coba tes performa dengan 10 virtual user.
Gambar 4.14 Response Time Graph 60 Threads
Gambar 4.14 menunjukkan waktu yang dibutuhkan oleh Jmeter untuk melakukan pengaksesan halaman. Dari grafik, dapat dilihat bahwa halaman dengan total waktu terbesar ketika melakukan request adalah halaman report dinilai dan report menilai menempati urutan kedua waktu terbanyak untuk melakukan request. Sedangkan halaman employee berada pada posisi yang sama ketika melakukan penyelesaian dengan halaman report dinilai, menilai, survey history, halaman login, report builder CSI dan report builder CSI CK. Dengan bentang waktu antara pukul 00:12:20 sampai dengan pukul 00:17:20. Hasil ini tidak jauh berbeda dengan dengan uji coba performa 10 virtual user sebelumnya.
63
Gambar 4.15 Aggregate Average Rate Graph 60 Threads
Gambar 4.15 merupakan bentuk diagram batang untuk menunjukkan waktu rata-rata dari masing-masing virtual user untuk mengakses halaman website. Halaman report dinilai dan menilai menunjukkan waktu rata-rata respon dari web yang tertinggi dibandingkan dengan halaman lain. Hal ini sama dengan sama dengan percobaan dengan menggunakan 10 virtual user, perbedaannya hasil hanya terletak pada halaman employee.
64
Gambar 4.16 Grafik Total Transfer Rate 60 Threads
Gambar 4.16 menunjukkan kecepatan transfer data dari pengaksesan masing-masing halaman web. Gambar di atas menunjukkan besarnya transfer rate yang dibutuhkan dari halaman report dinilai dan menilai. Dari grafik dapat dilihat bahwa kecepatan transfer dari halaman report dinilai, menilai dan Employee menempati urutan terendah dalam kecepatan transfer datanya. Hal ini bisa menunjukkan lambatnya waktu pemrosesan halaman tersebut dibandingkan dengan halaman lainnya.
65
Gambar 4.17 Grafik Total Throughput 140 Threads
Gambar 4.17 menunjukkan besaran throughput atau rerata kecepatan pengiriman data yang sukses dari masing-masing halaman web. Dari hasil percobaan tersebut maka dapat dilihat bahwa hasil dari percobaan tidak mengalami perbedaan yang signifikan, baik dari hasil uji coba dengan 10 virtual user maupun 60 virtual user. Maka dapat disimpulkan bahwa halaman report dinilai dan menilai memang mengalami waktu pemrosesan yang lebih lama ketimbang halaman lainnya.
4.2.2.1.3 Uji Coba dengan 140 Virtual User Gambar 4.17 adalah gambar yang menunjukkan hasil realisasi dari tes performa dengan jumlah virtual user sebesar 140 karyawan.
66
Gambar 4.18 Hasil dari Summary Test Plan 140 Threads
Gambar 4.18 adalah hasil dari summary test plan dari jumlah 140 virtual user. Dari gambar di atas dapat dilihat bahwa halaman report dinilai, menilai dan halaman document survey preview menunjukkan rata-rata waktu respon yang paling tinggi yakni 13.667, 13.019 serta 11.527 millisecond. Hasil ini sedikit berbeda dengan hasil tes performa dengan 10 virtual user, di mana hasil yang ditunjukkan oleh tes tersebut halaman web report builder ESI menempati urutan tertinggi ketiga. Hasil dari summary test plan ini juga menunjukkan bahwa tingkat error tertinggi ditunjukkan juga oleh halaman report dinilai dan menilai, yakni sebesar 15% dan 25.71%. Hal ini sama dengan hasil uji coba tes performa dengan 10 virtual user dan 60 virtual user.
67
Gambar 4.19 Response Time Graph 140 Threads
Gambar 4.19 menunjukkan waktu yang dibutuhkan oleh Jmeter untuk melakukan pengaksesan halaman. Dari grafik, dapat dilihat bahwa halaman dengan total waktu terbesar ketika melakukan request adalah halaman report dinilai dan report menilai menempati urutan kedua waktu terbanyak untuk melakukan request. Sedangkan halaman report ESI berada pada posisi yang sama ketika melakukan penyelesaian dengan halaman report dinilai, menilai, survey history, halaman login, report builder CSI dan report builder CSI CK. Dengan bentang waktu antara pukul 00:12:20 sampai dengan pukul 00:17:20. Hasil ini tidak jauh berbeda dengan dengan uji coba performa 10 virtual user dan 60 virtual user sebelumnya.
68
Gambar 4.20 Aggregate Average Rate Graph 140 Threads
Gambar 4.20 merupakan bentuk diagram batang untuk menunjukkan waktu rata-rata dari masing-masing virtual user untuk mengakses halaman website. Halaman report dinilai dan menilai menunjukkan waktu rata-rata respon dari web yang tertinggi dibandingkan dengan halaman lain. Hal ini sama dengan sama dengan percobaan dengan menggunakan 10 virtual user dan 60 virtual user.
69
Gambar 4.21 Grafik Total Transfer Rate 140 Threads
Gambar 4.21 menunjukkan kecepatan transfer data dari pengaksesan masing-masing halaman web. Gambar di atas menunjukkan besarnya transfer rate yang dibutuhkan dari halaman report dinilai dan menilai. Dari grafik dapat dilihat bahwa kecepatan transfer dari halaman report dinilai, menilai dan ESI menempati urutan terendah dalam kecepatan transfer datanya. Hal ini bisa menunjukkan lambatnya waktu pemrosesan halaman tersebut dibandingkan dengan halaman lainnya.
70
Gambar 4.22 Grafik Total Throughput 140 Threads
Gambar 4.22 menunjukkan besaran throughput atau rerata kecepatan pengiriman data yang sukses dari masing-masing halaman web. Dari hasil percobaan tersebut maka dapat dilihat bahwa hasil dari percobaan tidak mengalami perbedaan yang signifikan, baik dari hasil uji coba dengan 10 virtual user, 60 virtual user maupun 140 virtual user. Maka dapat disimpulkan bahwa halaman report dinilai dan menilai memang mengalami waktu pemrosesan yang lebih lama ketimbang halaman lainnya. Maka kesimpulan mengenai halaman mana saja dari web survey PT. Kalbe Morinaga Indonesia masih sama dengan percobaan dengan 10 virtual user maupun 60 virtual user. Oleh karena itu dibutuhkan pengkajian lebih lanjut dengan menggunakan metode penelusuran kode serta database dari aplikasi.
71
4.2.2.2 Analisis Kode Aplikasi Pengkajian kode aplikasi akan berfokus pada halaman report dinilai dan menilai, karena berdasarkan analisis tes performa dan analisis kuesioner kepuasan pengguna
kedua
halaman
tersebut
yang
paling
banyak
menimbulkan
permasalahan dan layak untuk diuji secara white box testing. Dari hasil analisis kode, didapatkan bahwa framework untuk pembuatan aplikasi menggunakan metode MVC (Model, View, Controller) dan merupakan framework internal dari developer. Developer tidak menggunakan framework yang telah ada atau open source framework untuk membangun aplikasi web survey PT. Kalbe Morinaga Indonesia.
Gambar 4.23 Struktur Hirarki Kode
Dan ketika dilakukan uji coba dengan menggunakan browser Google Chrome, pada Gambar 4.23 menunjukkan bahwa seluruh eksternal source diunduh ketika membuka halaman report dinilai.
72
Gambar 4.24 Network Activity
Gambar 4.24 menunjukkan bahwa banyaknya eksternal source yang diunduh ketika mengakses halaman report dinilai. Hal ini disebabkan oleh pemanggilan seluruh eksternal source dari layar utama (Master Page) sehingga memakan waktu pemrosesan pada aplikasi. Dan ketika menelusuri kode dari controller, terlihat bahwa banyaknya dilakukan pemrosesan yang membebani web server. Berikut ini adalah potongan kode dari controller report dinilai yang telah ditelusuri :
73
private function GridViewTrMemberSurveyReport() { $tags['StartDate'] = $_POST['StartDate']?$_POST['StartDate'] :''; $tags['EndDate'] = $_POST['EndDate']?$_POST['EndDate']:''; $MsEmployeeEnt = new MsEmployeeEntities(); $TrJadwalSurveyEnt = new TrJadwalSurveyEntities(); $TrMemberSurveyEnt = new TrMemberSurveyEntities(); if($tags['StartDate'] && $tags['EndDate']) { $jadwalSurvey = $TrJadwalSurveyEnt->Where(" StartDate >= '".$tags['StartDate']."' AND EndDate <= '".$tags['EndDate']."' AND ID_DocSurvey IN ( SELECT ID_DocSurvey FROM msdocsurvey WHERE ID_TipeSurvey IN ( SELECT IdTipeSurvey FROM mstipesurvey WHERE IsPublic = 0 AND IsMultiDepartement = 0 ))")->Get(); if($jadwalSurvey){ $i=0; foreach($jadwalSurvey as $result){ $employee = $MsEmployeeEnt-> Where("IdEmployee = ".$result->ID_Employee) ->First(); $this->template->setVar("EmployeeName[".$i."]", $employee->EmployeeName); $this->template->setVar("EmployeeId[".$i."]", $employee->EmployeeId); $i++; } $i = 0; foreach($jadwalSurvey as $result){ $memberSurvey = $TrMemberSurveyEnt->Where("ID_JadwalSurvey = ".$result->ID_JadwalSurvey)->Get(); if($memberSurvey){ $show = ""; $show .= "
"; foreach($memberSurvey as $row) $employee =$MsEmployeeEnt ->Where("IdEmployee = ".$row>ID_Employee)->First(); $status = $row->IsAnswered == 1 ? '<spanclass="approved">Answered' :'<spanclass="rejected">Not Ansswered'; $show .= "- ".$employee-> EmployeeId." - ". $employee->EmployeeName." ".$status."
"; $show .= "
"; } $this->template->setVar("Dinilai[".$i."]", $show); $i++; } } else $this->errMsg = "No data."; } $this->template->renderLoopingData("msemployeesdatasource", $jadwalSurvey); $this->template->ifs("isHasRows",$tags['StartDate'] != ''); $this->template->addTags($tags); }
74
Pada potongan baris di atas, dapat dilihat banyaknya perulangan dan nested query yang terjadi pada masing-masing perulangan. Hal ini akan memperlambat waktu pemrosesan baik dari sisi server aplikasi maupun dari sisi server database. Karena perulangan query yang bersifat sequensial akan memakan banyak resource, sehingga baiknya perulangan seperti ini dihilangkan. Dari kode di atas, ditunjukkan bahwa query yang berada di dalam perulangan terjadi karena adanya kebutuhan untuk menggabungkan data dari satu tabel ke tabel lain. Ketika ditelusuri dengan melakukan interview terhadap developer, mereka mengatakan bahwa hal ini dikarenakan oleh keterbatasan dari framework MVC yang belum sempurna. Sehingga tidak dapat mendukung query untuk menggabungkan data dari satu tabel ke dalam tabel lain. Hal ini tentu merugikan dan memakan daya yang besar karena pengkoneksian terpisah untuk melakukan query secara berulang akan menyebabkan beratnya server untuk melakukan pemrosesan. Kesimpulan yang didapatkan dari analisis kode aplikasi adalah adanya keterbatasan dari framework yang digunakan untuk mendukung dan mempercepat proses aplikasi.
4.2.2.3 Analisis Database Setelah melakukan analisis pada database web survey PT. Kalbe Morinaga Indonesia, ditemukan beberapa masalah yang dapat menyebabkan kurangnya performa dari aplikasi. Berikut ini adalah beberapa masalah yang dapat menimbulkan kurang baiknya performa web survey :
75
1.
Tidak adanya foreign key pada rancangan database web survey. Hal ini dapat menimbulkan kurangnya performa pada query karena tidak adanya indexing yang mengatur peletakan data pada bagian tempat penyimpanan (Hard Disk), sehingga ketika proses pencarian berlangsung membutuhkan waktu yang sedikit lebih panjang bahkan cukup panjang ketimbang menggunakan foreign key. Selain itu indexing yang digunakan di dalam database adalah MyISAM, indexing tipe ini tidak mendukung penggunaan foreign key sehingga harus diubah ke dalam indexing dengan tipe InnoDB.
76
Gambar 4.25 ERD Web Survey
77
Gambar 4.26 Indexing yang Digunakan dalam Struktur DatabaseWeb Survey
Berikut ini adalah beberapa pembuktian perbandingan query antara query yang menggunakan foreign key dengan yang tidak menggunakan. a.
Tabel msdocsurvey dengan msdocquestion.
Gambar 4.27 Tanpa Menggunakan Foreign Key (msdocsurvey)
78
Gambar 4.28 Dengan Menggunakan Foreign Key (msdocsurvey)
Gambar 4.27 dan Gambar 4.28 menunjukkan bahwa adanya perbedaan signifikan dalam menarik data apabila menggunakan relasi dan teknik indexing dalam melakukan query. Tercatat bahwa tanpa foreign key, waktu total yang dibutuhkan untuk menjalankan query di atas adalah sebesar 0.008 detik sedangkan waktu yang dibutuhkan untuk melakukan eksekusi query pada tabel yang telah diberi foreign key adalah sebesar 0.003 detik. Percobaan di atas dilakukan dengan sejumlah data dan dilakukan dengan cara langsung mengkoneksikan tools SQL Yog ke jaringan server database PT. Kalbe Morinaga Indonesia.
b.
Tabel trjadwalsurvey dengan tabel msdocsurvey, msdocquestion, mscategorytype.
79
Gambar 4.29 Tanpa Menggunakan Foreign Key (trjadwalsurvey)
Gambar 4.30 Dengan Menggunakan Foreign Key (trjadwalsurvey)
Dari kedua contoh di atas, dapat dilihat bahwa dengan menggunakan foreign key performa dari query ke dalam database web survey dapat
80
ditingkatkan. Selain itu karakterstik database, yakni ACID (atomic, consistency, isolation, durability) dapat dipertahankan. Hal ini sangat penting mengingat bahwa performa dari volume transaksi yang cukup banyak per tahun dari penggunaan database web survey ini.
4.3
Uji Coba Perbaikan Web Survey
Setelah melakukan analisis pada web survey PT. Kalbe Morinaga Indonesia, ditarik kesimpulan bahwa adanya permasalahan di beberapa halaman web. Halaman yang menimbulkan permasalahan adalah halaman report survey dinilai dan menilai, hal ini ditunjukkan oleh beberapa kali uji coba otomasi dengan 10 virtual user, 60 virtual user serta 140 virtual user. Dengan adanya hasil tersebut maka akan dilakukan uji coba perbaikan di halaman report survey dinilai dan menilai. Uji coba hanya akan dibatasi pada perbaikan database dan penggunaan framework lain pada kode halaman report survey dinilai dan menilai. Perbaikan akan dimulai dari sisi database dengan menambahkan relasi antar tabel sehingga performa dapat ditingkatkan. Selain itu simulasi ulang kode dengan menggunakan framework DooPHP. Hal ini dilakukan karena framework yang digunakan untuk membuat aplikasi web survey PT. Kalbe Morinaga tidak efisien dalam melakukan query, sehingga akan diuji dengan mengembangkan mock up aplikasi dengan framework lain. Penggunaan framework
DooPHP
mengacu
pada
benchmark
yang
diberikan
oleh
http://DooPHP.com/benchmark, di mana hasil pembanding performa dari
81
beberapa framework seperti CakePHP, Symfony, Kohana, Yii, serta Code Igniter menunjukkan bahwa framework untuk PHP yang paling efisien adalah DooPHP.
Gambar 4.31 Perbandingan performa antar Framework
Berikut ini adalah hasil yang didapatkan lewat uji coba perbaikan framework serta database aplikasi web survey dengan menggunakan 140 virtual user pada halaman report dinilai dan menilai.
82
Gambar 4.32 Hasil dari Summary Test Plan 140 Threads
Gambar 4.32 adalah hasil dari summary test plan dari jumlah 140 virtual user dengan perbaikan pada database serta framework aplikasi. Dari gambar di atas dapat dilihat bahwa halaman report dinilai dan menilai mengalami kemajuan performa yang jauh lebih baik ketimbang menggunakan framework awal dari aplikasi web survey. Apabila dibandingkan rata-rata waktu respon antara aplikasi mock up dan aplikasi yang sebelumnya maka perbandingan efisiensi dari penggunaan framework dan perbaikan dari aplikasi adalah sebesar 55.70% pada halaman report dinilai serta sebesar 48.10% pada halaman report menilai.
Gambar 4.33 Perbandingan hasil average response time Pada Gambar 4.33 terlihat perbedaan yang cukup signifikan antara ratarata waktu respon yang dibutuhkan oleh aplikasi lama dengan aplikasi mock up menggunakan framework DooPHP serta database yang telah diberikan relasi.
83
Dari hasil yang didapatkan terjadi peningkatan waktu respon dari aplikasi, peningkatan transfer rate serta peningkatan throughput dari aplikasi. Hal ini tentu dapat dijadikan masukkan bagi pengembang aplikasi untuk perbaikan di masa yang akan datang. Dengan memperbaiki struktur database dan pergantian framework aplikasi, maka peningkatan performa dapat dicapai sehingga permasalahan seputar performa dapat dipecahkan.