Laporan PKL 4.0 PDF

LAPORAN PRAKTIK KERJA LAPANGAN (PKL)
PERUSAHAAN/INDUSTRI
CV. TECHNOBIT INDONESIA
PENGEMBANGAN SISTEM PELAYANAN FASILITAS

KESEHATAN TERPADU BERBASIS WEBSITE
Diajukan untuk memenuhi sebagian persyaratan Kurikulum Sarjana
Disusun oleh:
Muhammad Alimuddien Rasyid NIM : 155150200111227

Moh. Zulfiqar Naufal Maulana NIM : 155050201111353
PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNIK INFORMATIKA
FAKULTAS ILMU KOMPUTER
UNIVERSITAS BRAWIJAYA
MALANG
2018
LEMBAR PENGESAHAN
LAPORAN PRAKTIK KERJA LAPANGAN (PKL)

PERUSAHAAN/INDUSTRI
CV. TECHNOBIT INDONESIA
PENGEMBANGAN SISTEM PELAYANAN FASILITAS KESEHATAN TERPADU

BERBASIS WEBSITE
Diajukan untuk memenuhi sebagian persyaratan Kurikulum Sarjana

Program Studi Teknik Informatika
Bidang Rekayasa Perangkat Lunak
Disusun oleh:
Muhammad Alimuddien Rasyid NIM : 155150200111227
Moh. Zulfiqar Naufal Maulana NIM : 155150201111353
Praktik Kerja Lapangan ini dilaksanakan pada

2 Juli sampai dengan 31 Agustus 2018
Telah diperiksa dan disetujui oleh:
Dosen Pembimbing PKL
Agi Putra Kharisma, S.T, M.T.

NIK: 2013048604301001
Mengetahui,
Ketua Jurusan Teknik Informatika
Tri Astoto Kurniawan, S.T, M.T, Ph.D

NIP: 19710518 200312 1 001
ii
PERNYATAAN ORISINALITAS
Saya menyatakan dengan sebenar-benarnya bahwa sepanjang pengetahuan

saya, di dalam naskah laporan PKL ini tidak terdapat karya ilmiah yang pernah
diajukan oleh orang lain untuk memperoleh gelar akademik di suatu perguruan
tinggi, dan tidak terdapat karya atau pendapat yang pernah ditulis atau diterbitkan
oleh orang lain, kecuali yang secara tertulis disitasi dalam naskah ini dan
disebutkan dalam daftar pustaka.
Apabila ternyata didalam naskah laporan PKL ini dapat dibuktikan terdapat
unsur-unsur plagiasi, saya bersedia laporan PKL ini digugurkan dan nilai akademik
yang telah saya peroleh dibatalkan, serta diproses sesuai dengan peraturan
perundang-undangan yang berlaku (UU No. 20 Tahun 2003, Pasal 25 ayat 2 dan
Pasal 70).
Malang, 26 September 2018

Ketua Kelompok,
Moh. Zulfiqar Naufal Maulana

NIM: 155150201111353
iii
KATA PENGANTAR
Puji syukur kehadirat Allah SWT yang telah melimpahkan rahmat, taufik dan
hidayah-Nya sehingga laporan PKL yang berjudul “Pengembangan Sistem
Pelayanan Fasilitas Kesehatan Terpadu berbasis Website” ini dapat terselesaikan.
Penulis menyadari bahwa laporan ini tidak akan berhasil tanpa bantuan dari
beberapa pihak. Oleh karena itu, penulis ingin menyampaikan rasa hormat dan
terima kasih kepada:
1. Bapak Agi Putra Kharisma, S.T., M.T. selaku dosen pembimbing PKL yang telah
dengan sabar membimbing dan mengarahkan penulis sehingga dapat
menyelesaikan laporan ini Fakultas Ilmu Komputer.
2. Bapak Agus Wahyu Widodo, S.T., M.Cs. selaku Ketua Program Studi Teknik
Informatika Fakultas Ilmu Komputer.
3. Bapak Tri Astoto Kurniawan, S.T., M.T., Ph.D. selaku selaku Ketua Jurusan
Teknik Informatika Fakultas Ilmu Komputer.
4. Ayahanda dan Ibunda dan seluruh keluarga besar atas segala nasehat, kasih
sayang, perhatian dan kesabarannya di dalam membesarkan dan mendidik
penulis, serta yang senantiasa tiada henti-hentinya memberikan doa dan
semangat demi terselesaikannya laporan ini.
5. Seluruh pihak dari CV. Technobit Indonesia, Bapak Danang dan Bapak Finsa
yang telah bersedia membina dan membimbing penulis dalam menjalankan
dan menyelesaikan PKL ini.
6. Seluruh anggota dan pengurus Lembaga Kajian Islam – Al-Fatih Muslim Drenalin
yang telah membersamai penulis dalam banyak waktu selama masa kuliah dan
memberikan banyak dukungan berupa doa dan aspek non-materi lainnya.
7. Seluruh civitas akademika Teknik Informatika Universitas Brawijaya yang telah
banyak memberi bantuan dan dukungan selama penyelesaian laporan PKL ini.
Penulis menyadari bahwa dalam penyusunan laporan ini masih banyak

kekurangan, sehingga saran dan kritik yang membangun sangat penulis harapkan.
Akhir kata penulis berharap PKL ini dapat membawa manfaat bagi semua pihak
yang menggunakannya.
Malang, 26 September 2018

Ketua Kelompok
Moh. Zulfiqar Naufal Maulana

Email : mznaufalmaulana@student.ub.ac.id
iv
ABSTRAK
E-Medica merupakan sebuah sistem pelayanan fasilitas kesehatan terpadu

yang mengintegrasikan antara manajemen dan administrasi fasilitas kesehatan
menggunakan infrastruktur teknologi informasi. Sistem ini berbasis cloud
computing, berjalan pada platform web, menggunakan protokol SOAP untuk
berkomunikasi antara sistem dengan cloud server dan menggunakan XML sebagai
media pertukaran pesan. Hanya saja sejak E-Medica diluncurkan tahun 2016, CV.
Technobit Indonesia selaku pengembang sistem ini mengupayakan agar kinerja
sistem dapat lebih efisien dan untuk meningkatkan kenyamanan pengguna
dengan meningkatkan tampilan antarmuka. Sehingga penulis melakukan
pengembangan ulang sistem E-Medica tanpa menghilangkan fungsionalitas sistem
yang lama. Sistem yang telah dikembangkan ulang ini dinamakan Medique.
Setelah melalui proses analisis kebutuhan, perancangan, implementasi dan
pengujian, seluruh fungsionalitas dan usabilitas sistem dinyatakan valid dan
kenyamanan pengguna dalam menggunakan sistem Medique meningkat.
Kata kunci: E-Medica, fasilitas kesehatan, cloud computing, web, SOAP, XML
v
ABSTRACT
E-Medica is an integrated health facility service system which integrates

management and administration aspects of health facility using information
technology infrastructure. This system is based on cloud computing, runs on a web
platform, uses SOAP protocol to communicate with cloud server and uses XML as
a message exchanging medium. However since E-Medica was launched in 2016,
CV. Technobit Indonesia as the developer of this system strive to make the
performance of the system more efficient and to improve user’s convenience by
improving the interface. So we did a redevelopment of E-Medica without omitting
the functionality of the old system. We call it Medique. After going through the
process of requirement analysis, design, implementation and testing, all of the
system’s functionality and its usability declared valid and user’s convenience in
using the Medique system improved.
Keywords: E-Medica, health facility, cloud computing, web, SOAP, XML
vi
DAFTAR ISI
LEMBAR PENGESAHAN ............................................................................................ii

PERNYATAAN ORISINALITAS ................................................................................... iii
KATA PENGANTAR ................................................................................................... iv
ABSTRAK ................................................................................................................... v
ABSTRACT ................................................................................................................ vi
DAFTAR ISI .............................................................................................................. vii
DAFTAR TABEL .......................................................................................................... x
DAFTAR GAMBAR ................................................................................................... xii
DAFTAR LAMPIRAN ............................................................................................... xiv
BAB 1 PENDAHULUAN............................................................................................. 1
1.1 Latar belakang........................................................................................ 1
1.2 Rumusan masalah .................................................................................. 1
1.3 Tujuan .................................................................................................... 2
1.4 Batasan masalah .................................................................................... 2
1.5 Manfaat.................................................................................................. 2
1.6 Sistematika Pembahasan ....................................................................... 3
BAB 2 PROFIL OBYEK PKL ........................................................................................ 4
2.1 Sejarah Perusahaan ............................................................................... 4
2.2 Alamat Perusahaan ................................................................................ 4
2.3 Visi dan Misi Perusahaan ....................................................................... 4
2.4 Struktur Organisasi Perusahaan ............................................................ 5
2.5 Rantai Bisnis Perusahaan ....................................................................... 5
BAB 3 TINJAUAN PUSTAKA...................................................................................... 7
3.1 Web Service............................................................................................ 7
3.2 XML ........................................................................................................ 7
3.3 Pengembangan Perangkat Lunak .......................................................... 7
3.4 Cloud Computing.................................................................................... 9
3.5 Teknologi Pengembangan Sistem .......................................................... 9
3.6 Unified Modelling Language ................................................................ 10
3.6.1 Class Diagram.............................................................................. 10
vii
3.6.2 Use Case Diagram ....................................................................... 12
3.6.3 Use Case Scenario ....................................................................... 15
3.6.4 Sequence Diagram ...................................................................... 15
3.7 Teori Pengujian .................................................................................... 16
3.7.1 Whitebox Testing ........................................................................ 16
3.7.2 Blackbox Testing.......................................................................... 16
3.7.3 Usability Testing .......................................................................... 18
BAB 4 METODOLOGI ............................................................................................. 19
Studi Literatur ...................................................................................... 19
4.2 Analisis Kebutuhan .............................................................................. 20
4.3 Perancangan ........................................................................................ 20
4.4 Implementasi ....................................................................................... 21
4.5 Pengujian ............................................................................................. 21
4.5.1 Pengujian Unit (Whitebox Testing) ............................................. 21
4.5.2 Pengujian Validasi (Blackbox Testing) ......................................... 22
4.5.3 Pengujian Usabilitas (Usability Testing) ...................................... 22
4.6 Kesimpulan dan Saran ......................................................................... 22
BAB 5 HASIL DAN PEMBAHASAN .......................................................................... 23
5.1 Gambaran Umum Sistem ..................................................................... 23
5.2 Analisis Kebutuhan .............................................................................. 23
5.2.1 Identifikasi Aktor ......................................................................... 23
5.2.2 Kebutuhan Fungsional................................................................. 23
5.2.3 Kebutuhan Non-fungsional ......................................................... 26
5.3 Pemodelan Sistem ............................................................................... 26
5.3.1 Use Case Diagram ....................................................................... 26
5.3.2 Use Case Scenario ....................................................................... 27
5.4 Perancangan ........................................................................................ 34
5.4.1 Perancangan Arsitektur Sistem ................................................... 34
5.4.2 Perancangan Komponen ............................................................. 43
5.4.3 Perancangan Antarmuka ............................................................. 44
5.5 Spesifikasi Piranti Pendukung .............................................................. 52
5.5.1 Spesifikasi Perangkat Keras ......................................................... 52
viii
5.5.2 Spesifikasi Perangkat Lunak ........................................................ 53
5.6 Implementasi ....................................................................................... 53
5.6.1 Implementasi Algoritma.............................................................. 53
5.6.2 Implementasi Antarmuka ........................................................... 55
5.7 Pengujian ............................................................................................. 60
5.7.1 Pengujian Unit (Whitebox testing) .............................................. 60
5.7.2 Pengujian Validasi (Blackbox testing) ......................................... 66
5.7.3 Pengujian Usabilitas .................................................................... 71
BAB 6 PENUTUP .................................................................................................... 72
6.1 Kesimpulan........................................................................................... 72
6.2 Saran .................................................................................................... 72
DAFTAR PUSTAKA.................................................................................................. 73
ix
DAFTAR TABEL
Tabel 4.1 Aturan Penulisan Kode Kebutuhan ....................................................... 20

Tabel 5.1 Identifikasi Pengguna ............................................................................ 23
Tabel 5.2 Spesifikasi kebutuhan fungsional pengguna tamu................................ 23
Tabel 5.3 spesifikasi kebutuhan fungsional pengguna terdaftar .......................... 24
Tabel 5.4 Spesifikasi kebutuhan non-fungsional .................................................. 26
Tabel 5.5 Use Case Scenario Login ........................................................................ 27
Tabel 5.6 Use Case Scenario Daftar....................................................................... 28
Tabel 5.7 Use Case Scenario Melihat Daftar Dokter ............................................. 28
Tabel 5.8 Use Case Scenario Melihat Daftar Fasilitas Kesehatan ......................... 29
Tabel 5.9 Use Case Scenario Memfilter Daftar Dokter ......................................... 29
Tabel 5.10 Use Case Scenario Memfilter Daftar Fasilitas Kesehatan ................... 29
Tabel 5.11 Use Case Scenario Melihat Detail Dokter ............................................ 30
Tabel 5.12 Use Case Scenario Melihat Detail Fasilitas Kesehatan ........................ 30
Tabel 5.13 Use Case Scenario Melihat Jadwal Praktik Tertentu ........................... 31
Tabel 5.14 Use Case Scenario Melakukan Booking Pada Dokter Tertentu ........... 31
Tabel 5.15 Use Case Scenario Memantau Nomor Antrian ................................... 32
Tabel 5.16 Use Case Scenario Melihat Detail Profil Pengguna ............................. 32
Tabel 5.17 Use Case Scenario Mengedit Detail Profil Pengguna .......................... 32
Tabel 5.18 Use Case Scenario Logout.................................................................... 33
Tabel 5.19 Keterangan Perancangan Antarmuka Login........................................ 44
Tabel 5.20 Keterangan Perancangan Antarmuka Daftar ...................................... 45
Tabel 5.21 Keterangan Perancangan Antarmuka Melihat Daftar Dokter............. 47
Tabel 5.22 Keterangan Perancangan Antarmuka Melihat Detail Dokter ............. 48
Tabel 5.23 Keterangan Perancangan Antarmuka Memantau Nomor Antrian ..... 49
Tabel 5.24 Keterangan Perancangan Antarmuka Melihat Detail Profil Pengguna 50
Tabel 5.25 Keterangan Perancangan Antarmuka Mengedit Detail Profil Pengguna
............................................................................................................................... 51
Tabel 5.26 method-method yang Diuji ................................................................. 61
Tabel 5.27 Hasil Pengujian Unit booking_dokter.................................................. 62
Tabel 5.28 Hasil Pengujian Unit get_data_selection ............................................ 64
Tabel 5.29 Hasil Pengujian Unit index................................................................... 66
x
Tabel 5.30 Rencana Pengujian Validasi ................................................................. 67
Tabel 5.31 Rencana Pengujian Validasi Kebutuhan Non-fungsional .................... 68
Tabel 5.32 Hasil Pengujian Validasi Kebutuhan Funsional.................................... 68
xi
DAFTAR GAMBAR
Gambar 2.1 Struktur Organisasi CV. Technobit Indonesia ..................................... 5

Gambar 2.2 Rantai Bisnis CV. Technobit Indonesia ................................................ 6
Gambar 3.1 Struktur Pesan pada Protokol SOAP (IBM, 2018) ............................... 8
Gambar 3.2 Siklus Pengembangan Perangkat Lunak secara Iteratif (Sommerville,
2011) ..................................................................................................................... 10
Gambar 3.3 Contoh Struktur Class Diagram (Dietel, 2004).................................. 11
Gambar 3.5 Contoh Diagram Use Case (Booch et al., 2005) ................................ 13
Gambar 3.6 Contoh Relasi antar Aktor (Booch et al., 2005)................................. 13
Gambar 3.7 Contoh Relasi antar Use Case (Booch et al., 2005) ........................... 14
Gambar 3.8 Contoh Sequence Diagram (Pressman, 2010) .................................. 15
Gambar 3.9 Contoh Flow Graph (Pressman, 2010) .............................................. 16
Gambar 4.1 Diagram Alir Pelaksanaan PKL ........................................................... 19
Gambar 5.1 Use Case Diagram Medique .............................................................. 27
Gambar 5.2 Sequence Diagram Login ................................................................... 34
Gambar 5.3 Sequence Diagram Daftar ................................................................. 35
Gambar 5.4 Sequence Diagram Melihat Daftar Dokter ........................................ 36
Gambar 5.5 Sequence Diagram Memfilter Daftar Dokter .................................... 36
Gambar 5.6 Sequence Diagram Melihat Detail Dokter ........................................ 37
Gambar 5.7 Sequence Diagram Melihat Jadwal Praktik Tertentu ........................ 38
Gambar 5.8 Sequence Diagram Melakukan Booking pada Dokter Dimaksud ...... 38
Gambar 5.9 Sequence Diagram Memantau Nomor Antrian ................................ 39
Gambar 5.10 Sequence Diagram Melihat Detail Profil Pengguna ........................ 40
Gambar 5.11 Sequence Diagram Mengedit Detail Profil Pengguna ..................... 41
Gambar 5.12 Sequence Diagram Logout .............................................................. 41
Gambar 5.13 Class Diagram Medique .................................................................. 42
Gambar 5.14 Perancangan Antarmuka Login ....................................................... 44
Gambar 5.15 Perancangan Antarmuka Daftar...................................................... 45
Gambar 5.16 Perancangan Antarmuka Melihat Daftar Dokter ............................ 46
Gambar 5.17 Perancangan Antarmuka Melihat Detail Dokter ............................. 48
Gambar 5.18 Perancangan Antarmuka Memantau Nomor Antrian..................... 49
Gambar 5.19 Perancangan Antarmuka Melihat Detail Profil Pengguna .............. 50
xii
Gambar 5.20 Perancangan Antarmuka Mengedit Detail Profil Pengguna ........... 51
Gambar 5.21 Implementasi Antarmuka Login ...................................................... 55
Gambar 5.22 Implementasi Antarmuka Daftar .................................................... 56
Gambar 5.23 Implementasi Antarmuka Melihat Daftar Dokter ........................... 57
Gambar 5.25 Implementasi Antarmuka Melihat Daftar Dokter ........................... 57
Gambar 5.26 Implementasi Antarmuka Melihat Detail Dokter............................ 58
Gambar 5.27 Implementasi Antarmuka Memantau Nomor Antrian ................... 59
Gambar 5.28 Implementasi Antarmuka Melihat Detail Profil Pengguna ............. 59
Gambar 5.29 Implementasi Antarmuka Mengedit Detail Profil Pengguna .......... 60
Gambar 5.30 Implementasi Antarmuka Mengedit Detail Profil Pengguna .......... 60
Gambar 5.31 Flow Graph booking_dokter ........................................................... 62
Gambar 5.32 Flow Graph get_data_selection ...................................................... 64
Gambar 5.33 Flow Graph index ............................................................................ 65
xiii
DAFTAR LAMPIRAN
LAMPIRAN A DOKUMENTASI KEGIATAN PKL ........................................................ 74
xiv
BAB 1 PENDAHULUAN
1.1 Latar belakang

E-Medica merupakan sebuah sistem pelayanan fasilitas kesehatan terpadu
yang mengintegrasikan antara manajemen dan administrasi fasilitas kesehatan
menggunakan infrastruktur teknologi informasi. Sistem ini berbasis cloud
computing, sehingga dapat diakses dari banyak tempat dan berbagai macam
perangkat. Sistem ini dikembangkan oleh CV. Technobit Indonesia dan telah
diluncurkan di beberapa fasilitas kesehatan masyarakat seperti UPT Puskesmas
Randuagung Kabupaten Lumajang dan UPT Puskesmas Bululawang Kabupaten
Malang di tahun 2016, serta di Rumah Sakit Islam Gondanglegi Kabupaten Malang
pada tahun 2018.
Protokol komunikasi yang digunakan antara sistem E-Medica dengan cloud
server sendiri adalah Simple Object Access Protocol (SOAP) yang mengakomodasi
nilai jual dari E-Medica yaitu mudah, cepat dan akurat. SOAP sendiri dapat
dijalankan walaupun dengan bahasa pemrograman yang berbeda, karena SOAP
memang dibuat untuk menyambungkan dan menjadi media komunikasi antara
sistem atau program yang berbeda maupun terpisah (Mukhi et al., 2008). Protokol
SOAP sendiri menggunakan Extensible Markup Language (XML) sebagai struktur
dokumen yang baku, agar antar client dapat berkomunikasi dengan akurat tanpa
ada kesalahan pada transmisi datanya.
Namun seiring dengan peluncuran E-Medica yang sudah berlangsung sejak
tahun 2016, CV. Technobit Indonesia terus mengupayakan agar kinerja sistem
tersebut dapat ditingkatkan agar lebih efisien dan kualitas tampilan antarmukanya
dapat ditingkatkan agar pengguna nyaman selama menggunakan sistem tersebut,
khususnya platform web dari sistem E-Medica. Di sisi lain, kompleksitas sistem dan
keterbatasan dokumentasi sistem membuat proses maintenance tidak dapat
dilakukan dengan mudah.
Maka atas pertimbangan tersebut, perlu dilakukan pengembangan ulang
sistem E-Medica dari awal. Seluruh fungsionalitas tetap akan diimplementasikan
pada sistem yang baru, hanya saja seluruh implementasi kode dan tampilan
antarmuka pengguna dibangun dari awal tanpa ada sentimen tertentu mengenai
sistem E-Medica yang lama. Sehingga dari pengembangan ulang sistem E-Medica
ini diharapkan kinerja sistem dapat ditingkatkan agar lebih optimal dan tampilan
antarmuka pengguna dapat diatur agar pengguna lebih nyaman.
1.2 Rumusan masalah

Berdasarkan latar belakang masalah yang telah diuraikan, ditetapkan rumusan
masalah sebagai berikut:
1
1. Bagaimana hasil analisis dan spesifikasi persyaratan yang harus terwujud
pada sistem pelayanan fasilitas kesehatan terpadu berbasis website
tersebut?
2. Bagaimana rancangan sistem pelayanan fasilitas kesehatan terpadu yang
sesuai dengan spesifikasi persyaratan sistem tersebut?
3. Bagaimana hasil implementasi sistem pelayanan fasilitas kesehatan
terpadu yang sesuai dengan rancangan sistem tersebut?
4. Bagaimana hasil pengujian sistem pelayanan fasilitas kesehatan terpadu
tersebut?
1.3 Tujuan
Tujuan penelitian yang harus dicapai adalah sebagai berikut:
1. Mengetahui hasil analisis dan spesifikasi persyaratan yang harus terwujud
pada sistem pelayanan fasilitas kesehatan terpadu berbasis website.
2. Mengetahui rancangan sistem pelayanan fasilitas kesehatan terpadu yang
sesuai dengan spesifikasi persyaratan sistem
3. Mengetahui hasil implementasi sistem pelayanan fasilitas kesehatan
terpadu yang sesuai dengan rancangan sistem
4. Mengetahui hasil pengujian sistem pelayanan fasilitas kesehatan terpadu
1.4 Batasan masalah

Batasan masalah dalam Praktik Kerja Lapangan ini, yaitu:
1. Sistem yang akan dikembangkan berbasis web dan berfokus dalam
penyediaan layanan informasi ketersediaan fasilitas kesehatan serta
layanan pemesanan antrean fasilitas kesehatan.
2. Sistem dikembangkan menggunakan SOAP API yang disediakan oleh
perusahaan
1.5 Manfaat
Manfaat yang akan diperoleh dari Praktik Kerja Lapangan ini, antara lain:
1. Bagi penulis, manfaat yang didapatkan dalam praktik kerja lapangan ini adalah
untuk melatih dan menambah pengalaman serta wawasan kerja di lingkungan
perusahaan teknologi informasi. Penulis dapat memperoleh pengetahuan
mengenai mekanisme kerja yang secara umum terdapat pada setiap
perusahaan.
2. Bagi perusahaan CV. Technobit Indonesia, manfaat yang didapatkan adalah
untuk mengembangkan dan memperbaiki sistem yang sebelumnya telah dicoba
2
untuk dikembangkan, terlebih dari sisi tampilan antarmuka dan optimalisasi
kinerja website.
3. Bagi masyarakat secara umum, manfaat yang diperoleh adalah dapat
menghemat biaya perjalanan menuju tempat layanan fasilitas kesehatan dan
penyakit para pasien dapat tertangani dengan lebih efisien.
1.6 Sistematika Pembahasan

Untuk mempermudah pemahaman laporan PKL ini, penulis membuat
sistematika penulisan yang mengemukakan secara singkat mengenai isi dari tiap-
tiap bab sebagai berikut:
BAB I PENDAHULUAN
Pada bab ini diuraikan latar belakang penelitian, rumusan masalah, tujuan,
manfaat penelitian dan batasan dari permasalahan yang diangkat pada
penelitian ini serta sistematika pembahasan pada penelitian ini.
BAB II PROFIL OBYEK PKL
Pada bab ini dijelaskan profil tempat peneliti melaksanakan praktik kerja
lapangan (PKL), yaitu berkaitan dengan sejarah, alamat, visi dan misi, struktur
organisasi dan rantai bisnis perusahaan.
BAB III TINJAUAN PUSTAKA
Pada bab ini dijelaskan penelitian terdahulu yang sudah dilakukan berikut
hasilnya dan teori-teori yang digunakan sebagai acuan atau dasar dalam
melakukan penelitian.
BAB IV METODOLOGI
Pada bab ini dijelaskan metode yang digunakan dalam melaksanakan praktik
kerja lapangan beserta langkah-langkah yang dilalui di dalamnya, yaitu
melakukan studi literatur, menganalisis kebutuhan, merancang,
mengimplementasi, menguji sistem dan menarik kesimpulan dari seluruh
proses yang telah ditempuh.
BAB V HASIL DAN PEMBAHASAN
Pada bab ini dipaparkan hasil dari penelitian dan pelaksanaan PKL serta
pembahasan dari hasil tersebut.
BAB VI PENUTUP
Pada bab ini ditarik kesimpulan akhir dari penelitian dan pelaksanaan PKL lalu
dikumpulkan saran-saran sehingga dapat memberikan kontribusi untuk
penelitian dan pelaksanaan PKL pada kesempatan selanjutnya.
3
BAB 2 PROFIL OBYEK PKL
2.1 Sejarah Perusahaan

CV. Technobit Indonesia merupakan perusahaan yang bergerak dalam riset
dan pengembangan teknologi informasi, komunikasi dan data. Berdiri pada 1
Oktober 2014 yang kemudian disahkan sebagai badan usaha sesuai dengan akta
pendirian pada 13 Oktober 2014 oleh Notaris Benediktus Bosu, SH di Kota Malang.
CV. Technobit Indonesia melakukan riset, pengembangan dan penerapan
teknologi bersama semua elemen masyarakat dan mitra lainnya dengan saling
bersinergi untuk terciptanya suatu layanan atau produk teknologi dalam segala
bidang keahlian atau keilmuan dan sumber daya yang saling memberikan manfaat
dan berkelanjutan.
2.2 Alamat Perusahaan

CV. Technobit Indonesia beralamat di Jalan Danau Tondano Dalam II A2C24,
Kelurahan Sawojajar, Kecamatan Kedungkandang, Kota Malang, Jawa Timur,
Indonesia, Kodepos 65139.
2.3 Visi dan Misi Perusahaan

Visi CV. Technobit Indonesia adalah “Menjadi perusahaan di bidang teknologi
informasi, komunikasi dan data yang melakukan riset, pengembangan hingga
penerapan secara berkelanjutan”. Sementara Misi CV. Technobit Indonesia adalah
sebagai berikut:
1. Melakukan riset untuk menciptakan inovasi terbaru di bidang teknologi-
teknologi informasi, komunikasi dan data.
2. Pengembangan teknologi agar selalu sesuai dengan kebutuhan dan
perubahan zaman.
3. Penerapan teknologi dengan dukungan dan pendampingan layanan yang
insentif.
4. Mengembangkan kerjasama dan kemitraan dengan berbagai pihak agar
terciptanya kondisi yang saling menguntungkan.
5. Menjaga amanah, profesionalisme serta kerjasama yang solid dan
berkualitas untuk mendukung pelayanan atau produk secara
berkelanjutan.
4
2.4 Struktur Organisasi Perusahaan
Gambar 2.1 Struktur Organisasi CV. Technobit Indonesia

Pada Gambar 2.1 menjelaskan bahwa CV. Technobit Indonesia dikepalai oleh
Finsa Ferdifiansyah sebagai Direktur, diwakili oleh Danang Subandriyo yang
mengarahkan dan menentukan kebijakan dari Direktur secara lebih mendetail dan
spesifik agar dapat dilaksanakan oleh Programmer. Berkaitan dengan fitur-fitur
apa saja yang perlu dikaji ulang pada produk yang telah dihasilkan dan bagaimana
pengembangan lanjutannya, kedua hal ini dikelolah oleh Hasanudin Muslim selaku
R&D (research and development) Manager. Danang Subandriyo mengepalai
Programmer yang bekerja pada CV ini, meliputi Web Programmer, Desktop
Programmer, Mobile Programmer dan Database Programmer.
Sementara berkaitan dengan posisi penulis dalam melaksanakan PKL, penulis
ditempatkan pada divisi Web Programmer sehingga secara langsung berada di
bawah tanggung jawab Danang Subandriyo selaku Wakil Direktur. Koordinasi yang
berkaitan dengan teknis pengerjaan proyek PKL penulis lakukan dengan Wakil
Direktur
2.5 Rantai Bisnis Perusahaan

Pada Gambar 2.2 ini merupakan proses bisnis CV. Technobit Indonesia, yang
diawali dan terus berkesinambungan dengan dijalankannya proyek pengadaan IT
yang bekerjasama dengan pemerintah daerah setempat. Kemudian dari produk
yang telah dihasilkan, diperoleh juga pemasukan bagi CV ini. CV ini juga melayani
konsultasi berkaitan dengan produk atau kendala di bidang IT. Dari konsultasi ini
diperoleh pemasukan juga.
Dari ketiga aktivitas dan proyek di atas, CV ini memperoleh modal untuk
melangsungkan aktivitas-aktivitas operasional, seperti investasi untuk melakukan
5
pengembangan dari sistem yang telah dibuat sebelumnya, untuk menggaji
karyawan dan juga untuk memenuhi biaya operasional.
Gambar 2.2 Rantai Bisnis CV. Technobit Indonesia
6
BAB 3 TINJAUAN PUSTAKA
3.1 Web Service

Web service adalah sebagian kode yang dapat diakses atau dieksekusi oleh
berbagai macam pengguna di seluruh dunia karena kode tersebut diletakkan pada
server (Mukhi et al., 2008).
Web service menggunakan standar web dan teknologi tertentu yang spesifik
agar komunikasi antar mesin dengan mesin dapat berjalan. Salah satu file yang
biasa digunakan sebagai bagian dari komunikasi pada web service adalah XML.
Mekanisme ini dapat melayani pengguna dalam jumlah yang banyak. Mekanisme
komunikasi antar pengguna atau entitas tersebut diatur dalam Web Service
Description Language (WSDL). WSDL menggunakan XML sebagai media
pertukaran pesan dari pengguna dengan pemberi layanan melalui protokol
jaringan (Tran, 2013).
3.2 XML
Berdasarkan dokumentasi W3C (2013), Extensible Markup Language atau
biasa disingkat menjadi XML adalah bahasa yang digunakan untuk
mendeskripsikan sekumpulan data objek-objek dari sebuah kelas pada dokumen-
dokumen XML dan menjelaskan bagaimana ketentuan program dari suatu
komputer dalam memproses dokumen-dokumen tersebut.
Dokumen XML terdiri dari entitas yang merupakan unit penyimpanan data
terurai yang tersusun atas karakter-karakter yang beberapa di antaranya
membentuk data karakter dan sisanya membentuk markup, ataupun data yang
tidak terurai. Deskripsi dari tata letak penyimpanan dan struktur logika dari
dokumen XML disandikan oleh markup, sehingga pada tata letak penyimpanan
dan struktur logika dimasukkan aturan atau batasan-batasan melalui penyandian
tersebut secara paksa (W3C, 2013).
3.3 Pengembangan Perangkat Lunak

Simple Object Access Protocol (SOAP) adalah protokol komunikasi yang
berfungsi sebagai untuk memberikan penjelasan atau ketentuan spesifik
mengenai bagaimana seharusnya struktur dan konten yang di muat di dalam
dokumen XML. SOAP biasa digunakan di berbagai macam platform perangkat
lunak dan keras karena memiliki sifat interoperabilitas pada berbagai macam
lingkungan sistem. SOAP dapat dijalankan walaupun dengan bahasa
pemrograman yang berbeda, karena SOAP sendiri memang dibuat untuk
menyambungkan dan menjadi media komunikasi antara sistem atau program
yang berbeda maupun terpisah, sehingga SOAP banyak digunakan dan menjadi
standar pada berbagai macam industri (Mukhi et al., 2008).
7
Gambar 3.1 Struktur Pesan pada Protokol SOAP (IBM, 2018)
Sebuah pesan SOAP dikemas dalam sebuah dokumen XML yang terdiri dari
envelope, header, body dan vault (IBM, 2018). Hal ini digambarkan pada
Gambar 3.1 dimana envelope adalah elemen yang membungkus header dan body.
Envelope merupakan elemen inti dari pesan SOAP. Header adalah sub-elemen
yang bersifat opsional yang berfungsi sebagai tempat bertukar informasi terkait
aplikasi yang nantinya akan diproses oleh node SOAP dalam jalur pesan. Body
adalah sub-elemen yang harus ada dalam pesan SOAP, karena memuat informasi
yang akan disampaikan kepada penerima pesan yang terakhir. Elemen terakhir
pada pesan SOAP adalah fault, yaitu sub-elemen dari pesan SOAP yang berfungsi
sebagai tempat untuk menyertakan laporan error.
1 <?xml version='1.0' Encoding='UTF-8' ?>
2 <env:Envelopexmlns:env="http://www.w3.org/2003/05/soap-
3 envelope">
4 <env:Header>
5 <m:reservation
6 xmlns:m="http://travelcompany.example.org/reservation"env:r
7 ole="http://www.w3.org/2003/05/soap-envelope/role/next">
8 <m:reference>uuid:093a2da1-q345-739r-ba5d-
9 pqff98fe8j7d</m:reference>
10 <m:dateAndTime>2007-11-29T13:20:00.000-
11 05:00</m:dateAndTime>
12 </m:reservation>
13 <n:passenger
14 xmlns:n="http://mycompany.example.com/employees"env:role="h
15 ttp://www.w3.org/2003/05/soap-envelope/role/next">
16 <n:name>Fred Bloggs</n:name>
17 </n:passenger>
18 </env:Header>
19 <env:Body>
20 <p:itinerary
21 xmlns:p="http://travelcompany.example.org/reservation/trave
22 l">
23 <p:departure>
24 <p:departing>New York</p:departing>
25 <p:arriving>Los Angeles</p:arriving>
26 <p:departureDate>2007-12-14</p:departureDate>
27 <p:departureTime>late afternoon</p:departureTime>
28 </p:departure>
29 <p:return>
30 <p:departing>Los Angeles</p:departing>
31 <p:arriving>New York</p:arriving>
32 <p:departureDate>2007-12-20</p:departureDate>
33 <p:departureTime>mid-morning</p:departureTime>
34 </p:return>
8
35 </p:itinerary>
36 </env:Body>
37 </env:Envelope>
3.4 Cloud Computing

Secara singkat, cloud computing adalah komputasi yang memungkinkan untuk
memperoleh, mengakses, menggunakan dengan mudah tanpa memerlukan biaya
mahal. Hal ini dapat diwujudkan karena inovasi yang dikembangkan pada
teknologi komputasi, operasi dan model bisnis. Pengguna cloud tidak perlu
memikirkan bagaimana mekanisme kerja sistem cloud computing, siapa yang
menjalankannya dan di mana server sistem ini diletakkan (Marks dan Lozano,
2010)
Kata cloud dari cloud computing merupakan visualisasi dari jaringan hubungan
antar komputer yang tergambar pada diagram yang menyerupai gambar awan.
Jaringan ini merepresentasikan jalur transportasi data antar komputer yang
dikirim melalui carrier backbone yang memiliki cloud. Konsep ini diusung pada
tahun 1961 oleh Profesor John McCarthy yang berpendapat bahwa daya pada
komputer dan bahkan aplikasi-aplikasi tertentu dapat terjual melalui tipe bisnis
utility model di masa depan.
Cloud computing sendiri merupakan sumberdaya yang dapat menyajikan
layanan untuk virtual data center. Sebagai contoh adalah Amazon S3 Storage
Service, hanya saja terdapat perbedaan antara virtual data center dengan cloud
computing. Cloud computing menyimpan data milik pengguna secara permanen
pada server jauh yang dapat diakses melalui internet sehingga dapat diakses di
mana saja dan kapan saja. Untuk mempercepat akses data pada perangkat milik
client, data tersebut juga disimpan dalam bentuk cache pada komputer desktop,
tablet, notebook, telepon seluler dan lain sebagainya. Hal ini sering diistilahkan
sebagai Software as a Service (SaaS) (Rittinghouse dan Ransome, 2010).
Penggunaan cloud computing pada sistem layanan kesehatan yang
dikembangkan oleh Bahrami et al. (2016) memberikan kemudahan dalam
memberikan antarmuka layanan kesehatan secara seragam walaupun cloud yang
menyediakan layanan ini (vendor) bermacam-macam. Pengguna dapat
memindahkan data dan aplikasi dari satu vendor ke vendor lainnya dengan sedikit
modifikasi, dengan mempertahankan privasi pada data pasien dengan enkripsi
AES (advanced encryption standard) dan DPM (data privacy method).
3.5 Teknologi Pengembangan Sistem

Pengembangan perangkat lunak dengan pendekatan iteratif adalah sebuah
pendekatan dalam mengembangkan perangkat lunak secara tersisip pada
spesifikasi kebutuhan, perancangan, pemrograman dan pengujian dan secara
berulang dilakukan pengembangan pada setiap bagian tersebut secara bertahap.
Pendekatan ini cocok untuk digunakan pada pengembangan sistem yang dibangun
9
berdasarkan komponen yang dapat digunakan kembali, seperti sistem berbasis
web. Namun kekurangan dari pendekatan ini adalah jika sistem yang lama
digantikan oleh sistem baru dan sedang dalam proses pengembangan. Pengguna
menginginkan fungsionalitas pada sistem yang lama, sementara sistem yang baru
belum selesai secara utuh dan pengguna tidak ingin mencoba sistem yang belum
selesai sehingga sulit untuk mendapatkan masukan yang berguna dari pelanggan
(Sommerville, 2011).
Secara umum, pendekatan iteratif memiliki tahapan-tahapan sebagaimana
pada Gambar 3.2 berikut.
Gambar 3.2 Siklus Pengembangan Perangkat Lunak secara Iteratif

(Sommerville, 2011)
3.6 Unified Modelling Language

Unified Modelling Language (UML) adalah bahasa pemodelan yang digunakan
untuk menggambarkan sistem, baik dari segi proses bisnis, fungsional sistem
secara spesifik dan konstruktif, ataupun menggambarkan bagian dari sistem yang
sudah konkret seperti kelas yang telah dituliskan kode programnya, skema pada
basis data, dan komponen perangkat lunak yang dapat digunakan kembali.
Pemodelan menggunakan UML ini merupakan cara yang standar setelah proses
penyeragaman banyak metode yang muncul sejak pertengahan tahun 1970 hingga
pertengahan tahun 1990 untuk memodelkan bahasa pemodelan berbasis objek
(Booch et al., 2005). Terdapat beberapa alat pemodelan UML yang akan digunakan
dalam laporan ini, yaitu class diagram, use case diagram dan sequence diagram.
3.6.1 Class Diagram

Class diagram adalah alat untuk memodelkan kelas-kelas, antarmuka,
kolaborasi yang terjadi dan hubungan antar keduanya secara statis. Diagram ini
paling sering dijumpai pada pemodelan sistem berorientasi objek. Class diagram
tidak hanya digunakan untuk memodelkan struktur sistem namun juga dapat
digunakan untuk membangun sistem sehingga nantinya dapat dieksekusi dalam
pendekatan rekayasa maju ataupun rekayasa terbalik (Booch et al., 2005).
Class diagram adalah diagram yang bersifat statis sehingga tidak terikat
dengan waktu. Secara umum, diagram ini menjelaskan tipe-tipe dan contohnya,
10
serta hubungan antar elemen tersebut dan struktur internalnya (Bell, 2004). Tipe-
tipe atau classifier yang dimaksud dalam class diagram adalah class, interface, tipe
data dan komponen. Untuk lebih jelasnya mengenai gambaran struktur class
diagram dapat dilihat pada Gambar 3.3.
Gambar 3.3 Contoh Struktur Class Diagram (Dietel, 2004)

3.6.1.1 Relasi Antar Class
Pada class diagram terdapat unsur-unsur yang penting untuk mendefinisikan
struktur dari sebuah sistem, di antaranya adalah relasi dan multiplisitas antar
class. Terdapat beberapa macam relasi antar class, yaitu dependensi, asosiasi,
agregasi, komposisi, pewarisan dan realisasi. Sementara multiplisitas antar class
terdiri dari one-to-one, one-to-many, many-to-one dan many-to-many.
Relasi dependensi terdiri atas dua unsur yang saling berhubungan, yaitu
supplier dan client. Jika terdapat perubahan definisi pada supplier, pada client juga
akan terjadi perubahan. Sebagai contoh, terdapat tiga class yang memiliki
hubungan dependensi. Kelas pertama mengirim pesan kepada kelas lain, kelas
kedua memiliki sebagian dari data yang dikirimkan tersebut dan kelas ketiga
menyebutkan kelas lain sebagai parameter dari sebuah operasi. Jika salah satu dari
interface kelas tersebut diubah, pesan yang dikirimkan menjadi tidak valid
(Fowler, 2003).
Relasi dependensi dimodelkan dengan garis putus-putus dan panah tidak
penuh. Sementara relasi asosiasi adalah penghubung antar class yang memiliki
satu atau beberapa data yang secara sintaks sama, hanya saja data tersebut dapat
berbeda antar class. Relasi ini dimodelkan dengan garis utuh dan panah terbuka
(Fowler, 2003). Sementara relasi realisasi merupakan hubungan antara class
interface dengan kelas lainnya yang mengimplementasikan class interface
tersebut. Class tempat implementasi ini juga mengimplementasikan class abstract
yang belum utuh. Relasi ini dimodelkan dengan garis putus-putus dan panah
tertutup (Fowler, 2003).
Relasi agregasi dan komposisi memiliki kemiripan namun terdapat perbedaan
yang cukup sulit untuk dipertimbangkan. Agregasi antar kelas dapat dianalogikan
ibarat mobil yang memiliki bagian-bagian seperti mesin dan roda. Jika tidak
terdapat kedua bagian tersebut, mobil tidak dapat berfungsi dengan baik.
Sementara komposisi dapat dianalogikan ibarat titik yang sama-sama dimiliki oleh
poligon dan lingkaran, namun jika titik ini sudah dimiliki oleh salah satu di antara
dua bangun tersebut, bangun lainnya tidak dapat memiliki titik ini. Sehingga dapat
disimpulkan bahwa komposisi memiliki dua prinsip, yaitu tanpa berbagi dan
kepemilikan eksklusif dari sebuah class terhadap komponen lain. Agregasi
11
dimodelkan dengan garis utuh, panah terbuka dan di pangkal panah disertakan
belah ketupat berwarna putih. Sementara komposisi dimodelkan dengan garis
utuh, panah terbuka dan disertai belah ketupat berwarna hitam di pangkal panah
(Fowler, 2003).
Relasi pewarisan adalah relasi antara kedua class yang memiliki perbedaan
namun terdapat banyak kemiripan. Kedua class tersebut dinamakan sebagai
supertype dan subtype. Sebagai contoh, terdapat class Customer yang masih
bersifat general, memiliki class yang lebih spesifik yaitu Personal Customer dan
Corporate Customer. Pada contoh ini, class Customer adalah supertype dan kedua
kelas setelahnya adalah subtype. Sehingga properti pada class Customer
diwariskan pada masing-masing subtype (Fowler, 2003).
Multiplisitas pada setiap relasi menunjukkan berapa banyak obyek yang dapat
dimiliki (Fowler, 2003). Terdapat beberapa multiplisitas yang sering dijumpai,
yaitu:
1. 1 yang bermakna sebuah kelas setidaknya harus memiliki satu obyek
2. 0..1, yang artinya sebuah kelas bisa atau tidak memiliki satu obyek.
3. *, yang berarti sebuah kelas tidak perlu memiliki satu objek dan jika
akan dibuat sebuah objek pada kelas tersebut, tidak ada batasan
maksimal jumlah objek yang dapat dibuat.
3.6.2 Use Case Diagram

Use case diagram merupakan landasan utama untuk memodelkan konteks
atau kebutuhan atas perilaku dari sistem, sub-sistem atau kelas berdasarkan sudut
pandang luar sistem, sehingga dapat diwujudkan dan dipahami penggunaannya
secara konteks. Diagram ini juga digunakan untuk menguji sistem yang dapat
dieksekusi dalam pendekatan rekayasa maju ataupun untuk memahami sistem
dalam pendekatan rekayasa terbalik (Booch et al., 2005).
Bagian-bagian pada use case diagram tersusun atas use case, aktor dan
relasi antar aktor atau antara aktor dengan use case.
3.6.2.1 Use Case
Use case adalah alat untuk memodelkan bagaimana perilaku sistem atau
entitas lain yang menjadi bagian dari sistem, sehingga pengembang sistem
memahami apa saja perilaku sistem yang harus tersedia tanpa perlu memahami
bagaimana proses implementasi dari perilaku tersebut. Use case biasa digunakan
untuk menyamakan persepsi antara pengembang, calon pengguna sistem dan
para ahli pada pemahaman sistem yang akan dibangun pada aspek arsitektur
sistem (Booch et al., 2005).
Masing-masing use case harus memiliki nama yang unik atau berbeda satu
dengan yang lainnya. Use case dapat terdiri dari huruf, angka dan tanda baca
selain tanda titik dua (:) yang merupakan tanda pemisah nama kelas dengan paket
12
yang terdiri di dalamnya. Panjang kalimat use case dapat dituliskan lebih dari satu
baris. Use case dituliskan dengan menggunakan kata kerja.
Gambar 3.4 Contoh Diagram Use Case (Booch et al., 2005)

3.6.2.2 Aktor
Gambar 3.5 Contoh Relasi antar Aktor (Booch et al., 2005)

Aktor adalah representasi dari peran yang dapat diambil oleh pengguna ketika
berinteraksi atau menjalankan use case yang ada pada sistem (Booch et al., 2005).
Aktor dapat berupa manusia, perangkat keras, atau sistem lainnya yang
berinteraksi dengan sistem ini. Aktor bukan bagian dari sistem, walaupun aktor
berinteraksi dengan sistem.
Aktor digambarkan menggunakan stick figure. Aktor dapat dispesialisasikan
menjadi lebih spesifik, sebagaimana pada gambar di atas. Hubungan antara aktor
dengan use case hanya dapat dikategorikan dengan hubungan asosiasi, yang
berarti bahwa aktor dan use case saling berkomunikasi satu sama lain dan masing-
masing dari keduanya dapat saling bertukar pesan.
13
3.6.2.3 Relasi Antar-Use Case
Gambar 3.6 Contoh Relasi antar Use Case (Booch et al., 2005)
Terdapat beberapa relasi yang dapat dibangun pada antar use case, yaitu
generalisasi, include dan extend (Booch et al., 2005). Relasi generalisasi diartikan
sebagaimana generalisasi pada sesama kelas. Pada generalisasi antar use case,
sebuah use case dapat mewarisi makna dan perilaku dari parent use case. Use case
juga dapat memodifikasi dengan melakukan override pada parent use case dan
juga menggantikan peran parent use case pada bagian di mana parent use case
muncul jika diperlukan. Relasi generalisasi ditandai dengan panah bergaris utuh
dengan panah besar terbuka.
Relasi include dimaknai sebagai hubungan antara base use case dengan
supplier use case, dimana supplier use case digunakan pada bagian atau tahapan
tertentu pada proses yang terjadi pada base use case. Base use case tidak dapat
berdiri sendiri tanpa supplier use case. Relasi include ini digunakan untuk
mendelegasikan sebuah proses yang sama pada banyak use case menjadi satu
atau banyak use case yang berdiri sendiri, sehingga use case baru ini dapat
digunakan oleh use case lain sesuai dengan kebutuhan.
Relasi extend memiliki arti bahwa supplier use case digunakan pada bagian
atau tahapan tertentu pada proses yang terjadi pada base use case, namun hanya
bersifat opsional sehingga base use case dapat berdiri sendiri atau dijalankan
tanpa supplier use case. Relasi ini dapat diistilahkan juga sebagai ekstensi atau
perpanjangan proses yang terjadi pada use case lainnya. Use case ekstensi ini
dapat digunakan oleh use case lain, bisa juga tidak digunakan. Dalam kata lain, use
case ini bersifat opsional dari sudut pandang perilaku sistem.
Relasi include dan extend ditandai dengan panah bergaris putus-putus dengan
kepala panah tidak utuh. Perbedaan panah include dan extend terletak pada arah
panahnya. Panah include mengarah pada supplier use case, sementara panah
extend mengarah pada base use case.
14
3.6.3 Use Case Scenario
Scenario dalam use case dapat diartikan sebagai tahapan interaksi yang
dilakukan antara aktor dengan sistem secara berurutan. Use case scenario
menjelaskan cerita yang dilalui dalam menggunakan sistem, atau tahapan-
tahapan yang dilakukan untuk menuntaskan use case. Sebagai contoh, scenario
yang menjelaskan tahapan-tahapan yang harus dilalui untuk membeli barang
secara tunai, atau bagaimana scenario yang dilalui ketika gagal membeli barang
karena penolakan pembayaran kartu kredit (Larman, 2004).
Cockburn (2001) mengusulkan cara untuk mendeskripsikan use case scenario
dengan sebuah template yang terdiri dari nama use case, nama aktor, tujuan dari
use case tersebut, pre-condition yang terjadi sebelum use case tersebut berjalan
dan pemicu dijalankannya use case, scenario atau tahapan-tahapan berjalannya
use case tersebut atau biasa diistilahkan pula dengan sebutan main flow,
exception atau pengecualian jika main flow tidak berjalan sesuai dengan harapan
atau biasa disebut dengan alternative flow. Lalu diakhiri dengan post-condition
yang merupakan kondisi akhir yang akan terjadi setelah use case dijalankan.
3.6.4 Sequence Diagram

Sequence diagram merupakan diagram yang menjelaskan interaksi antar objek
dan hubungannya serta pengiriman pesan yang terjadi antar objek tersebut, yang
menekankan pada urutan waktu pada masing-masing pengiriman pesan tersebut
yang digambarkan dengan sumbu x sebagai garis penghubung antar objek dan
pesan yang dikirimkan dan sumbu y sebagai waktu yang ditempuh dalam
pengiriman pesan tersebut (Pressman, 2010).
Gambar 3.7 Contoh Sequence Diagram (Pressman, 2010)
15
3.7 Teori Pengujian
3.7.1 Whitebox Testing
Pengujian white-box adalah pengujian yang memfokuskan perhatian pada
mekanisme internal dari sebuah sistem atau komponen, sehingga untuk
melakukan pengujian ini memerlukan pemahaman pada logika pemrosesan
sistem. Salah satu teknik yang biasa digunakan dalam pengujian adalah pengujian
basis path (Gao et al., 2003).
3.7.1.1 Pengujian Basis Path
Pengujian basis path adalah pengujian yang dilakukan berdasarkan ukuran
kompleksitas yang terdapat pada logika dan prosedur suatu sistem (Pressman,
2010).
Gambar 3.8 Contoh Flow Graph (Pressman, 2010)

Flow graph merupakan representasi logika alur program yang telah dibuat
sebelumnya dalam bentuk graf. Graf ini terdiri dari node dan edge. Terdapat dua
node spesial pada flow graph, yaitu node paling awal untuk memulai dan node
paling akhir. Terdapat node khusus lainnya, yaitu decision node atau node yang
memiliki edge lebih dari satu yang dimaknai percabangan pada program (Booth et
al., 2005).
3.7.2 Blackbox Testing

Black-box testing adalah pengujian yang memfokuskan perhatian pada output
yang dihasilkan berdasarkan input yang dimasukkan dan kondisi eksekusi.
Pengujian ini mengabaikan bagaimana mekanisme sistem dalam memproses input
tersebut untuk menghasilkan output, dalam kata lain pengujian ini dilakukan pada
level pengujian sistem dan integrasi, yaitu berkaitan dengan fungsionalitas sistem
berikut kesesuaiannya dengan kebutuhan pengguna (Gao et al., 2003). Terdapat
16
beberapa teknik yang biasa digunakan pada pengujian black-box, yaitu
equivalence partitioning, boundary value analysis dan cause-effect graph.
3.7.2.1 Equivalence Partitioning
Equivalence partitioning merupakan teknik yang membagi input-input yang
dapat dimasukkan ke dalam klasifikasi data sehingga dari klasifikasi tersebut dapat
dipilih kasus uji yang akan dilakukan. Dari sekian banyak kasus uji, dipilih kasus uji
yang dapat mewakili satu kelas tertentu sehingga penguji perangkat lunak tidak
perlu melakukan banyak kasus uji untuk menemukan kesalahan umum (Pressman,
2010). Klasifikasi input pada equivalence partitioning mewakili nilai valid maupun
invalid yang diharapkan. Berikut panduan yang menjadi dasar dalam
mendefinisikan kelas equivalence:
1. Jika kondisi input adalah terkategori rentang, didefinisikan satu kelas valid
dan dua kelas invalid.
2. Jika kondisi input mengharuskan ada nilai yang spesifik, didefinisikan satu
kelas valid dan dua kelas invalid.
3. Jika kondisi input adalah terkategori bagian dari sebuah rangkaian,
didefinisikan satu kelas valid dan satu kelas invalid.
4. Jika kondisi input adalah boolean, didefinisikan satu kelas valid dan satu
kelas invalid.
3.7.2.2 Boundary Value Analysis
Boundary value analysis (BVA) adalah teknik pengujian yang digunakan untuk
menguji nilai-nilai yang berada pada batas pembeda nilai input pada suatu kelas
equivalence (Pressman, 2010). Teknik ini dilakukan karena seringkali error lebih
banyak terjadi pada batas dari domain input jika dibandingkan pada tengah
domain. BVA tidak hanya memfokuskan perhatian pada input yang mempengaruhi
kasus uji, namun juga output yang dihasilkan dari kasus uji tersebut. Berikut
panduan yang menjadi dasar dalam mendefinisikan kasus uji dalam BVA:
1. Jika kondisi input memiliki rentang antara a sampai b, kasus uji harus
mencakup kasus dengan input bernilai a dan b, input bernilai sedikit di atas
a dan b serta input bernilai sedikit di bawah a dan b.
2. Jika kondisi input mencakup beberapa nilai, nilai terendah dan tertinggi
harus diuji, disertai dengan nilai yang berada sedikit di atas dan di bawah
nilai terendah dan tertinggi.
3. Terapkan dua panduan di atas untuk kondisi output, sehingga kasus uji
dapat diukur apakah dapat menghasilkan nilai tertinggi dan nilai terendah
yang dapat dicapai.
4. Jika pada struktur program ditetapkan batasan tertentu, misal ditetapkan
bahwa sebuah tabel hanya dapat menampung maksimal 100 catatan,
kasus uji dapat dibuat untuk menguji batasan tersebut.
17
3.7.3 Usability Testing
Usability Testing dilakukan untuk melakukan pengujian sistem dengan cara
menguji sistem secara langsung kepada sejumlah responden untuk mengetahui
tingkat kemudahan penggunaan sebuah sistem. Pengujian ini dilakukan setelah
sistem sudah siap digunakan sehingga diperoleh penilaian berdasarkan hasil dan
analisis responden yang dihitung berdasarkan metode yang digunakan. Dalam
pengujian usabilitas kali ini digunakan metode expert.
18
BAB 4 METODOLOGI
Selama praktik kerja lapangan ini dilaksanakan, terdapat tahapan-tahapan

yang dilalui yang diawali dengan studi literatur hingga perangkat lunak selesai
dibangun. Tahapan-tahapan tersebut dilaksanakan sebagaimana pada Gambar 4.1
berikut:
Gambar 4.1 Diagram Alir Pelaksanaan PKL
Studi Literatur
Literatur yang dikumpulkan dan dipelajari untuk menunjang penelitian dan
penulisan laporan telah dipaparkan sebelumnya pada bab 3. Literatur-Literatur
tersebut berkaitan dengan teori-teori berikut:
1. Web Service
2. XML
3. SOAP
19
4. Cloud Computing
5. Pengembangan Perangkat Lunak Metode Iteratif
6. Unified Modeling Language
a. Class Diagram
b. Use Case Diagram
c. Use Case Scenario
d. Sequence Diagram
7. Pengujian
a. White-Box Testing
b. Black-Box Testing
4.2 Analisis Kebutuhan

Analisis kebutuhan adalah tahapan untuk mengidentifikasi dan menetapkan
kebutuhan fungsional dan non-fungsional apa saja yang dibutuhkan oleh sistem
yang akan dibangun. Hal ini nantinya juga akan mempengaruhi proses pengujian
pada beberapa tahap selanjutnya. Kebutuhan ini dianalisis dengan pendekatan
berorientasi objek. Terdapat aturan penomoran dalam tahap analisis kebutuhan
yang telah didapat dan diolah sesuai dengan kabutuhan fungsional dan non-
fungsional sistem. Untuk lebih jelasnya, aturan penulisan kode pada kebutuhan
sistem dapat dilihat pada Tabel 4.1 berikut ini:
Tabel 4.1 Aturan Penulisan Kode Kebutuhan
No Kode Kebutuhan Karateristik Aktor
1 Med Menunjukkan nama sistem yang sedang dibangun yaitu
Medique
2 01/02 Menunjukkan tipe kebutuhan sistem. 01 untuk
kebutuhan fungsional dan 02 untuk kebutuhan non-
fungsional
3 XXX Menunjukkan urutan nomor kebutuhan sistem yang
terdiri dari tiga digit bilangan asli. Contoh: 001, 002, dst
4.3 Perancangan
Perancangan adalah tahapan untuk mengadaptasi seluruh spesifikasi
kebutuhan yang telah diidentifikasi menjadi model yang siap untuk
diimplementasikan dalam bentuk kode program. Pada tahap ini, rancangan sistem
harus mewujudkan seluruh spesifikasi kebutuhan yang diinginkan pada sistem dan
tidak kontraproduktif terhadap spesifikasi tersebut. Perancangan ini dianalisis
dengan pendekatan berorientasi objek. Beberapa tahapan dalam perancangan
adalah sebagaimana pada uraian berikut.
20
1. Perancangan Arsitektur
Arsitektur sistem akan dimodelkan menggunakan sequence diagram dan class
diagram berdasarkan standar UML
2. Perancangan Komponen
Rancangan komponen didokumentasikan dalam bentuk pseudocode dari
kelas-kelas yang nantinya akan menjadi controller dari sistem ini.
3. Perancangan Antarmuka
Rancangan antarmuka sistem diatur dan disesuaikan berdasarkan kebutuhan
sistem.
4.4 Implementasi
Implementasi adalah tahapan untuk mewujudkan rancangan yang sudah
disusun sebelumnya dalam bentuk kode program. Implementasi yang dilakukan
pada sistem ini mencakup algoritma pemrosesan pada sistem (back end) dan
tampilan antarmuka sistem (front end). Implementasi sistem ini harus sesuai
dengan perancangan yang telah dibuat sebelumnya.
Terdapat dua aspek implementasi yang dilakukan, yaitu pada aspek logika yang
mengimplementasikan algoritma yang berfungsi untuk mengatur dan mengolah
jalur pemrosesan data dan informasi. Aspek yang kedua yaitu aspek antarmuka
yang diimplementasikan menggunakan bahasa pemrograman PHP versi 7.2
dengan framework CodeIgniter 3.1.4 pada back-end dan pada front-end
diimplementasikan menggunakan framework bootstrap versi 3 dan dioptimalkan
dengan Javascript.
4.5 Pengujian
Setelah implementasi sistem tuntas, dilakukan pengujian pada sistem dengan
tujuan untuk mengukur tingkat kesesuaian sistem dengan kebutuhan yang telah
dianalisis dan untuk memperbaiki kesalahan yang menyebabkan ketidaksesuaian
jika terjadi. Pengujian ini dilakukan dengan metode white box dan black box.
Pengujian yang dilakukan terdapat pengujian unit yang dilakukan dengan
whitebox testing, pengujian validasi dengan menggunakan blacbox testing, dan
pengujian usabilitas sistem.
4.5.1 Pengujian Unit (Whitebox Testing)

Pengujian white-box adalah pengujian yang memfokuskan perhatian pada
mekanisme internal dari sebuah sistem atau komponen, sehingga untuk
melakukan pengujian ini memerlukan pemahaman pada logika pemrosesan
sistem. Salah satu teknik yang biasa digunakan dalam pengujian adalah pengujian
basis path (Gao et al., 2003).
21
4.5.2 Pengujian Validasi (Blackbox Testing)
Black-box testing adalah pengujian yang memfokuskan perhatian pada output
yang dihasilkan berdasarkan input yang dimasukkan dan kondisi eksekusi.
Pengujian ini mengabaikan bagaimana mekanisme sistem dalam memproses input
tersebut untuk menghasilkan output, dalam kata lain pengujian ini dilakukan pada
level pengujian sistem dan integrasi, yaitu berkaitan dengan fungsionalitas sistem
berikut kesesuaiannya dengan kebutuhan pengguna (Gao et al., 2003). Terdapat
beberapa teknik yang biasa digunakan pada pengujian black-box, yaitu
equivalence partitioning, boundary value analysis dan cause-effect graph.
4.5.3 Pengujian Usabilitas (Usability Testing)

Pengujian ini bertujuan untuk mengidentifikasi masalah usabilitas atau
kemudahan dalam menggunakan sistem, mengumpulkan data kualitatif dan
kuantitatif dan menentukan kepuasan pengguna terhadap sistem yang sedang
dikembangkan (Usability.gov, 2018).
4.6 Kesimpulan dan Saran

Setelah melalui tahapan-tahapan sebelumnya, hasil-hasil tahapan tersebut
disimpulkan pada tahapan ini secara keseluruhan. Pada tahapan ini dikumpulkan
seluruh kritik dan saran untuk meningkatkan kualitas pengembangan sistem ini.
Jika dalam penarikan kesimpulan ini didapati kekurangan fungsi pada sistem,
kebutuhan akan dianalisis kembali dan sistem dilengkapi dengan fungsi tambahan
lainnya. Jika sudah tidak diperlukan fungsi tambahan pada sistem, penarikan
kesimpulan dapat dituntaskan dan dapat merumuskan saran mengenai
pengembangan sistem seperti apa yang dapat dilakukan di masa yang akan
datang.
22
BAB 5 HASIL DAN PEMBAHASAN
5.1 Gambaran Umum Sistem

Medique merupakan sistem penyedia layanan pendaftaran nomor antrian
pemeriksaan dokter yang memudahkan pengguna dalam hal pengambilan nomor
antrian dan pengecekan nomor antrian. Dalam pengembangannya, system ini
berbasis website dengan menggunakan framework CodeIgniter versi 3.1.4 pada
bagian back-end serta menggunakan Amanda template pada bagian front-end
sistem. Simulasi pembangunan sistem ini juga menggunakan server localhost yang
disambungkan melalui XAMPP versi 3.2.2, apache versi 2.4.29 dan penyimpanan
menggunakan SOAP API.
5.2 Analisis Kebutuhan

Bagian ini membahas berisi deskripsi dan hasil analisis kebutuhan sistem yang
digunakan sebagai gambaran system yang akan dibangun dan menjadi
dokumentasi untuk pengembangan sistem kedepannya.
5.2.1 Identifikasi Aktor

Aktor pada sistem Medique ini terbagi menjadi 2 bagian, yaitu pengguna
terdaftar dan pengguna tamu. Pada Tabel 5.1 berikut merupakan karakteristik
pada system Medique ini.
Tabel 5.1 Identifikasi Pengguna
No Identifikasi Aktor Karakteristik Aktor
1 Pengguna Tamu Pengguna tamu merupakan pengguna system yang
belum memiliki akun atau belum melakukan login pada
system Medique
2 Pengguna Terdaftar Pengguna terdaftar merupakan pengguna system yang
telah memiliki akun dan telah melakukan login pada
system Medique ini
5.2.2 Kebutuhan Fungsional

Kebutuhan fungsional merupakan kebutuhan yang harus ada didalam system
Medique ini. Kebutuhan fungsional tersebut akan dituliskan dalam bentuk tabel.
5.2.2.1 Kebutuhan Fungsional Pengguna Tamu
Spesifikasi kebutuhan bagi pengguna tamu akan dituliskan pada Tabel 5.2
berikut ini.
Tabel 5.2 Spesifikasi kebutuhan fungsional pengguna tamu
No SRS-ID Nama Fungsi Deskripsi
23
Pengguna terdaftar dapat masuk kedalam
sistem dengan menggunakan username
1 Med-01-001 Login
dan password pengguna untuk
menggunakan sistem secara keseluruhan
Pengguna baru dapat melakukan

2 Med-01-002 Daftar
pendaftaran dengan memasukkan nama
Melihat Daftar Pengguna dapat melihat daftar dokter

3 Med-01-003
Dokter yang terintegrasi dalam sistem
Melihat Daftar
Pengguna dapat melihat daftar fasilitas
4 Med-01-004 Fasilitas
kesehatan yang terintegrasi dalam sistem
Kesehatan
Memfilter Daftar Pengguna dapat memilih kriteria dokter

5 Med-01-005
Dokter yang akan ditampilkan oleh sistem
Memfilter Daftar Pengguna dapat memilih kriteria fasilitas

6 Med-01-006 Fasilitas kesehatan yang akan ditampilkan oleh
Kesehatan sistem
Melihat Detail Pengguna dapat melihat detail dokter yang

7 Med-01-007
Dokter dipilihnya
Melihat Detail
Pengguna dapat melihat detail fasilitas
kesehatan yang dipilihnya
Kesehatan
Melihat Jadwal Pengguna dapat melihat djadwal praktik

9 Med-01-009
Praktik Tertentu dokter yang dimaksud
5.2.2.2 Kebutuhan Fungsional Pengguna Terdaftar

Spesifikasi kebutuhan bagi pengguna tamu akan dituliskan pada Tabel 5.3
berikut ini
Tabel 5.3 spesifikasi kebutuhan fungsional pengguna terdaftar
No SRS-ID Nama Fungsi Deskripsi
24
Pengguna terdaftar dapat masuk kedalam
sistem dengan menggunakan username
1 Med-01-001 Login
dan password pengguna untuk
menggunakan sistem secara keseluruhan
Pengguna baru dapat melakukan

2 Med-01-002 Daftar
pendaftaran dengan memasukkan nama
Melihat Daftar Pengguna dapat melihat daftar dokter

3 Med-01-003
Dokter yang terintegrasi dalam sistem
Melihat Daftar
Pengguna dapat melihat daftar fasilitas
kesehatan yang terintegrasi dalam sistem
Kesehatan
Memfilter Daftar Pengguna dapat memilih kriteria dokter

5 Med-01-005
Dokter yang akan ditampilkan oleh sistem
Memfilter Daftar Pengguna dapat memilih kriteria fasilitas

6 Med-01-006 Fasilitas kesehatan yang akan ditampilkan oleh
Kesehatan sistem
Melihat Detail Pengguna dapat melihat detail dokter yang

7 Med-01-007
Dokter dipilihnya
Melihat Detail
Pengguna dapat melihat detail fasilitas
kesehatan yang dipilihnya
Kesehatan
Melihat Jadwal Pengguna dapat melihat djadwal praktik

9 Med-01-009
Praktik Tertentu dokter yang dimaksud
Melakukan
Pengguna dapat melakukan booking pada
10 Med-01-010 Booking Pada
dokter dimaksud
Dokter Dimaksud
Memantau Pengguna dapat memantau nomor antrian

11 Med-01-011
Nomor Antrian yang sedang dilayani oleh dokter terkait
Melihat Detail
12 Med-01-012 Pengguna dapat melihat detail profilnya
Profil Pengguna
25
Mengedit Detail
13 Med-01-013 Pengguna dapat mengedit detail profilnya
Profil Pengguna
Pengguna keluar dari sistem dan tidak

14 Med-01-014 Logout dapat menggunakan sebagian fungsi
sistem
5.2.3 Kebutuhan Non-fungsional

Spesifikasi kebutuhan non-fungsional akan dituliskan pada Tabel 5.4 berikut ini
Tabel 5.4 Spesifikasi kebutuhan non-fungsional
SRS-ID Kebutuhan Sistem Deskripsi
Med-02-001 Usability System dapat dioperasikan
dengan mudah oleh aktor
5.3 Pemodelan Sistem

Bagian ini merupakan bagian permodeln system yang akan digunakan dalam
memodelkan kebutuhan system Medique ini.
5.3.1 Use Case Diagram

Gambar 5.1 Use Case Diagram Medique merupakan use case diagram dari
Sistem Medique ini. Terlihat bahwa aktor yang terlibat dalam sistem berjumlah
dua yaitu Pengguna tamu dan Pengguna terdaftar, dimana pengguna tamu hanya
dapat mengakses sebagian fitur yang disediakan oeh system. Sedangkan
pengguna terdaftar dapat menggunakan semua fitur yang disediakan oleh system.
Pada hasil analisis tersebut didapatkan 9 kebutuhan fungsional pengguna tamu
dan 14 kebutuhan fungsional pengguna terdaftar. Fungsi-fungsi tersebut
kemudian direpresentasikan dalam bentuk use case diagram.
26
Gambar 5.1 Use Case Diagram Medique
5.3.2 Use Case Scenario

Tabel 5.5 Use Case Scenario Login
Login (Med-01-001)
Objektif Pengguna dapat masuk kedalam sistem
Aktor Pengguna terdaftar
Prasyarat Pengguna membuka menu utama sistem
1. Pengguna memilih menu ‘Masuk’ pada pojok kanan atas sistem
2. Sistem membuka halaman login
Alur Utama
3. Pengguna memasukkan data yang diperlukan
4. Memasukkan username
27
5. Memasukkan kata sandi
6. Sistem melakukan pengecekan username dan kata sandi pengguna.
Jika gagal masuk kedalam sistem maka akan menampilkan tulisan ‘Oh Sorry!
Alur Alternatif
Username Or Password Not Match’
Kondisi Sesudah Pengguna dapat menggunakan seluruh fungsi sistem
Tabel 5.6 Use Case Scenario Daftar

Daftar (Med-01-002)
Objektif Pengguna tamu memiliki akun dan mengakses sistem secara keseluruhan
Aktor Pengguna tamu
Prasyarat Pengguna tamu mengakses halaman ‘Login’
1. Pengguna tamu memilih menu ‘daftar sekarang’ pada halaman login
2. Sistem mengarahkan pengguna tamu ke halaman daftar
3. Pengguna tamu memsukkan data yang dibutuhkan
4. Pengguna tamu memasukkan alamat email
5. Pengguna tamu memasukkan nama depan
6. Pengguna tamu memasukkan nama belakang
Alur Utama
7. Pengguna tamu memasukkan username
8. Pengguna tamu memasukkan kata sandi
9. Sistem merekam seluruh masukan pengguna tamu
10. Pengguna tamu menekan tombol ‘Daftar’
11. Sistem menyimpan data pengguna tamu kedalam database dan
mengarahkan ke halaman Login
1. Apabila terdapat kolom kosong, maka akan muncul pemberitahuan
Alur Alternatif
untuk mengisi kolom tersebut
Pengguna tamu memiliki akun dalam sistem dan bisa mengakses sistem
Kondisi Sesudah
secara keseluruhan
Tabel 5.7 Use Case Scenario Melihat Daftar Dokter

Melihat Daftar Dokter (Med-01-003)
Objektif Pengguna dapat mengetahui daftar dokter yang terintegrasi dengan sistem
1. Pengguna Terdaftar
Aktor
2. Pengguna Tamu
Prasyarat Pengguna membuka sistem
1. Pengguna memilih tab ‘Dokter’
Alur Utama
2. Sistem menampilkan daftar dokter yang ada dalam database
28
Alur Alternatif Tidak ada
Kondisi Sesudah Pengguna dapat melihat daftar dokter yang terintegrasi sistem
Tabel 5.8 Use Case Scenario Melihat Daftar Fasilitas Kesehatan

Melihat Daftar Fasilitas Kesehatan (Med-01-004)
Pengguna dapat mengetahui daftar fasilitas kesehatan yang terintegrasi
Objektif
dengan sistem
Aktor
2. Pengguna Tamu
Prasyarat Pengguna membuka sistem
1. Pengguna memilih tab ‘Fasilitas Kesehatan’
Alur Utama 2. Sistem menampilkan daftar fasilitas kesehatan yang ada dalam
database
Kondisi Sesudah Pengguna dapat melihat daftar fasilitas kesehatan yang terintegrasi sistem
Tabel 5.9 Use Case Scenario Memfilter Daftar Dokter

Memfilter Daftar Dokter (Med-01-005)
Objektif Pengguna dapat mencari dokter dengan kriteria yang ditetapkan pengguna
Aktor
2. Pengguna Tamu
1. Pengguna membuka sistem
Prasyarat
2. Pengguna membuka tab ‘Dokter’
1. Pengguna memilih kriteria dokter yang ingin ditampilkan
2. Pengguna memasukkan nama dokter
3. Pengguna memilih kota domisili dokter
Alur Utama
4. Pengguna memilih spesialisasi dokter
5. Pengguna memilih jenis kelamin dokter
6. Sistem menampilkan data dokter dimaksud
Apabila data tidak ditemukan, maka sistem akan menampilkan ‘Maaf! Data
Alur Alternatif
yang Anda Cari Tidak Ditemukan’
Pengguna dapat melihat daftar dokter sesuai dengan kriteria masukan dari
Kondisi Sesudah
pengguna
Tabel 5.10 Use Case Scenario Memfilter Daftar Fasilitas Kesehatan

Memfilter Daftar Fasilitas Kesehatan (Med-01-006)
29
Pengguna dapat mencari fasilitas kesehatan dengan kriteria yang ditetapkan
Objektif
pengguna
Aktor
2. Pengguna Tamu
Prasyarat
2. Pengguna membuka tab ‘Fasilitas Kesehatan’
1. Pengguna memilih kriteria fasilitas kesehatan yang ingin ditampilkan
2. Pengguna memasukkan nama fasilitas kesehatan
3. Pengguna memilih kota fasilitas kesehatan berada
Alur Utama
4. Pengguna memilih klinik
5. Pengguna memilih jenis jaminan kesehatan
6. Sistem menampilkan data fasilitas kesehatan dimaksud
Apabila data tidak ditemukan, maka sistem akan menampilkan ‘Maaf! Data
Alur Alternatif
yang Anda Cari Tidak Ditemukan’
Pengguna dapat melihat daftar fasilitas kesehatan sesuai dengan kriteria
Kondisi Sesudah
masukan dari pengguna
Tabel 5.11 Use Case Scenario Melihat Detail Dokter

Melihat Detail Dokter (Med-01-007)
Objektif Pengguna dapat melihat detail dokter yang diilihnya
Aktor
2. Pengguna Tamu
Prasyarat
2. Pengguna membuka tab ‘Dokter’
1. Pengguna memilih dokter yang ingin dilihat detailnya
Alur Utama
2. Sistem menampilkan data dokter yang dipilih pengguna
Kondisi Sesudah Pengguna dapat melihat detail dokter yang dipilih
Tabel 5.12 Use Case Scenario Melihat Detail Fasilitas Kesehatan

Melihat Detail Fasilitas Kesehatan (Med-01-008)
Objektif Pengguna dapat melihat detail fasilitas kesehatan yang diilihnya
Aktor
2. Pengguna Tamu
Prasyarat
2. Pengguna membuka tab ‘Fasilitas Kesehatan’
30
1. Pengguna memilih fasilitas kesehatan yang ingin dilihat detailnya
Alur Utama
2. Sistem menampilkan data fasilitas kesehatan yang dipilih pengguna
Kondisi Sesudah Pengguna dapat melihat detail fasilitas kesehatan yang dipilih
Tabel 5.13 Use Case Scenario Melihat Jadwal Praktik Tertentu

Melihat Jadwal Praktik Tertentu (Med-01-009)
Objektif Pengguna dapat melihat jadwal praktik dokter tertentu
Aktor
2. Pengguna Tamu
Prasyarat
2. Pengguna masuk kedalam halaman detail dokter
1. Pengguna memilih tanggal yang diinginkan pada kolom seleksi tanggal
2. Sistem merekam masukan pengguna
Alur Utama 3. Pengguna menekan tombol ‘Cari’
4. Sistem menampilkan daftar praktik pada jadwal terpilih yang dipilih
pengguna
Apabila data yang dicari tidak ditemukan, maka system akan menampilkan
Alur Alternatif
‘Maaf! Data yang Anda Cari Tidak Ditemukan’
Kondisi Sesudah Pengguna dapat melihat detail fasilitas kesehatan yang dipilih
Tabel 5.14 Use Case Scenario Melakukan Booking Pada Dokter Tertentu
Melakukan Booking Pada Dokter Tertentu (Med-01-010)
Objektif Pengguna dapat melakukan booking pada dokter dan waktu tertentu
Aktor Pengguna Terdaftar
Prasyarat 2. Penguna telah melakukan login pada sistem
3. Pengguna masuk kedalam halaman detail dokter
1. Pengguna memilih tanggal yang diinginkan pada kolom seleksi tanggal
2. Sistem menampilkan daftar praktik pada jadwal terpilih yang dipilih
pengguna
3. Pengguna menekan tombol ‘booking’ pada bagian kanan detail jadwal
Alur Utama yang diinginkan
4. Sistem menampilkan pilihan jaminan kesehatan yang dapat digunakan
5. Pengguna memilih jenis jaminan kesehatan apa yang akan digunakan
6. Sistem menyimpan data pengguna dan dan menampilkan nomor
antrian dan nomor loket yang didapat pengguna
31
Ketika pengguna belum melakukan login maka akan muncul halaman ‘Maaf,
Alur Alternatif
permintaaan tidak dapat diproses. Silahkan lakukan login terlebih dahulu’
Kondisi Sesudah Pengguna mendapat nomor antrian pada dokter dituju
Tabel 5.15 Use Case Scenario Memantau Nomor Antrian

Memantau Nomor Antrian (Med-01-011)
Objektif Pengguna dapat melakukan pengecekan dan status nomor antriannya
Prasyarat
2. Penguna telah melakukan login pada sistem
1. Pengguna memilih menu antrian pada samping kiri halaman utama
Alur Utama
2. Sistem menampilkan halaman antrian pengguna
Ketika pengguna belum melakukan login maka akan muncul halaman ‘404!
Alur Alternatif
Error’ dan ada himbauan unutk melakukan login terlebih dahulu
Kondisi Sesudah Pengguna dapat mengetahui status antrian di loket yang bersangkutan
Tabel 5.16 Use Case Scenario Melihat Detail Profil Pengguna

Melihat Detail Profil Pengguna (Med-01-012)
Objektif Pengguna dapat melihat detail profilnya
Prasyarat
1. Pengguna menekan tombol yang ada pada pojok kanan atas tampilan
sistem
Alur Utama 2. Sistem menampilkan menu yang ada didalamnya

3. Pengguna memilih menu ‘Lihat Profil’
4. Sistem mengarahkan pengguna ke halaman profil
Kondisi Sesudah Pengguna mendapat nomor antrian pada dokter dituju
Tabel 5.17 Use Case Scenario Mengedit Detail Profil Pengguna

Mengedit Detail Profil Pengguna (Med-01-013)
Objektif Pengguna dapat mengedit detail profilnya
Prasyarat
32
3. Pengguna masuk kedalam halaman profil
1. Pengguna menekan link ‘Edit Profil’
2. Sistem menampilkan menu edit profil
3. Pengguna mengisi kolom yang disediakan
4. Pengguna mengisi kolom Nama Pengguna
5. Pengguna mengisi kolom Nomor KTP
6. Pengguna mengisi kolom Tempat Lahir
7. Pengguna mengisi kolom Tanggal Lahir
Alur Utama 8. Pengguna mengisi kolom Alamat
9. Pengguna mengisi kolom Nomor Telepon
10. Pengguna Memilih Jenis Jaminan Kesehatan
11. Pengguna mengisi kolom Nomor Jaminan Kesehatan
12. Pengguna memilih Foto Profil
13. Sistem merekam semua masukan pengguna
14. Pengguna menekan tombol ‘Simpan Data’
15. Sistem menyimpan perubahan dan kembali ke halaman profil
Kondisi Sesudah Pengguna dapat memperbaharui data profilnya
Tabel 5.18 Use Case Scenario Logout

Logout (Med-01-014)
Objektif Pengguna dapat keluar dari sistem
Prasyarat
1. Pengguna menekan tombol yang ada pada pojok kanan atas tampilan
sistem
2. Sistem menampilkan menu yang ada didalamnya
Alur Utama
3. Pengguna memilih menu ‘Keluar’
4. Sistem menghapus session pengguna dan membuka halaman awal
sistem
Pengguna dapat keluar dari sistem dan tidak dapat menggunakan sebagian
Kondisi Sesudah
fungsi sistem
33
5.4 Perancangan
5.4.1 Perancangan Arsitektur Sistem
5.4.1.1 Sequence Diagram
1. Login (Med-01-001)
Gambar 5.2 merupakan alur proses login pada sistem Medique ini. Aktor
membuka halaman login sistem Medique ini kemudian memasukkan username
dan kata sandi akunnya yang kemudian diteruskan oleh controller c_login dengan
memanggil method index yang kemudian masukan dari aktor akan dilakukan
pengecekan pada entitas m_user dengan memanggil method get_data_user
dengan parameter dt, dimana dt tersebut merupakan username dan kata sandi
hasil masukan pengguna. Apabila username dan kata sandi tersebut benar, maka
sistem akan menampilkan halaman beranda dari sistem Medique ini. Namun
apabila masukan aktor salah maka akan menampilkan pesan error pada halaman
login sistem Medique ini.
Gambar 5.2 Sequence Diagram Login
2. Daftar (Med-01-002)
Gambar 5.3 merupakan alur proses dari fungsi daftar pada sistem ini. Pada
langkah pertama pengguna memilih menu daftar sekarang pada halaman v_login
yang kemudian memanggil controller c_register dengan menjalankan method
index setelah itu menampilkan halaman v_register. Selanjutnya sistem akan
meminta masukan aktor untuk mengisi data yang diperlukan berupa alamat email,
nama depan, nama belakang, username, dan kata sandi. Data tersebut akan
dibawa oleh controller c_register dengan memanggil method insert_data setelah
aktor menekan tombol daftar. Controller c_reister akan memanggil entitas m_user
34
dengan menjalankan method insert_user yang memiliki parameter dt dimana dt
merupakan hasil masukan dari aktor terhapat sistem. Apabila proses registrasi
berjalan maka selanjutnya akan ditampilkan halaman login untuk aktor kemudian
masuk kedalam sistem, namun apabila gagal maka sistem akan menampilkan
pesan eror yang terjadi.
Gambar 5.3 Sequence Diagram Daftar

3. Melihat Daftar Dokter (Med-01-003)
Gambar 5.4 merupakan alur proses dari fungsi melihat daftar dokter, dimana
aktor dapat melakukannya dengan memilih tab ‘dokter’ yang kemudian akan
menjalankan controller c_dashboard dengan menjalankan method index.
Kemudian method tersebut menjalankan entitas m_doctor dengan menjalankan
method show_doctor yang memiliki parameter dt yang merupakan data default
dari sistem yaitu berupa nama dokter, kota domisili, spesialisasi, dan jenis kelamin
dokter yang memiliki nilai ’0’ sebagai nilai default pengambilan data pertama kali
oleh sistem. Setelah itu controlller akan memanggil entitas m_doctor dengan
menjalankan method getCategory_city untuk mengambil data kota yang
terintegrasi oleh sistem Medique ini serta method getCategory_Spesialis untuk
mengambil data spesialisasi dokter yang terintegrasi oleh sistem medique ini juga.
35
Gambar 5.4 Sequence Diagram Melihat Daftar Dokter
4. Memfilter Daftar Dokter (Med-01-005)
Gambar 5.5 Sequence Diagram Memfilter Daftar Dokter

Gambar 5.5 merupakan alur proses dari fungsi memfilter daftar dokter.
Dimana aktor dapat melakukannya dengan memasukkan nama dokter, kota
domisili dokter, spesialisasi dokter, dan jenis kelamin dokter yang dimana data
masukan tersebut dapat dipilih salah satunya atau bisa diisi semua data tersebut
untuk keperluan filtering dokter. Data tersebut nantinya akan dibawa ke controller
c_dashboard dengan menjalankan method filter_dokter yang selanjutnya akan
mengeksekusi entitas m_doctor dengan menjalankan method show_doctor yang
memiliki parameter dt, dimana parameter tersebut merupakan parameter hasil
masukan dari aktor. Setelah itu controlller akan memanggil entitas m_doctor
36
dengan menjalankan method getCategory_city untuk mengambil data kota yang
terintegrasi oleh sistem Medique ini serta method getCategory_Spesialis untuk
mengambil data spesialisasi dokter yang terintegrasi oleh sistem medique ini juga.
5. Melihat Detail Dokter (Med-01-007)
Gambar 5.6 merupakan alur proses dari fungsi melihat detail dokter, dimana
aktor dapat menjalankanfungsi ini ketika aktor sudah memilih dokter yang akan
dilihat detailnya pada halaman v_dashboard yang selanjutnya akan dilakukan
pemanggilan controller c_detail_dokter dengan menjalankan method index.
Method index akan memanggil entitas m_detail dan menjalan method
get_detail_dokter yang memiliki parameter id yang mana parameter tersebut
didapatkan dari id dokter pilihan aktor. Setelah ini controller akan memanggil
entitas m_detail denganmethod get_detail_jadwal_dokter yang memiliki
parameter dt, dima dt tersebut dedapatkan dari nomor id dokter pilihan aktor.
Gambar 5.6 Sequence Diagram Melihat Detail Dokter

6. Melihat Jadwal Praktik Tertentu (Med-01-009)
Gambar 5.7 merupakan alur proses dari fungsi melihat jadwal praktik tertentu,
dimana aktor dapat menjalankan fungsi tersebut dengan memilih tanggal
dimaksud terlebih dahulu. Kemudian aktor menekan tombol cari yang selanjutnya
akan memanggil controller c_detail_dokter yang akan menjalankan method
get_data_selection. Method tersebut akan memanggil entitas m_detail dengan
menjalankan method get_detail_jadwal_dokter yang memiliki parameter dt
dalam bentuk array, dimana dt tersebut merupakan gabungan data dari nomor id
dokter dan tanggal pilihan aktor. Apabila data yang dicari ada dalam sistem, maka
akan langsung disajikan oleh sistem pada aktor. Namun apabila data yang
dimaksud tidak ada, maka sistem akan menampilkan pesan bahwa data yang
sedang dicari tidak ditemukan.
37
Gambar 5.7 Sequence Diagram Melihat Jadwal Praktik Tertentu
7. Melakukan Booking pada Dokter Dimaksud (Med-01-010)
Gambar 5.8 Sequence Diagram Melakukan Booking pada Dokter Dimaksud
38
Gambar 5.8 merupakan alur proses dari fungsi melakukan booking pada dokter
dimaksud, dimana aktor dapat menjalankan fungsi tersebut dengan memilih
tanggal dimaksud terlebih dahulu. Kemudian aktor menekan tombol cari yang
selanjutnya akan memanggil controller c_detail_dokter yang akan menjalankan
method get_data_selection. Method tersebut akan memanggil entitas m_detail
dengan menjalankan method get_detail_jadwal_dokter yang memiliki parameter
dt dalam bentuk array, dimana dt tersebut merupakan gabungan data dari nomor
id dokter dan tanggal pilihan aktor. Kemudian aktor memilih tempat praktik dokter
tersebut dan menekan tombol ‘booking’ pada bagian kanan tabel dimaksud.
Tombol tersebut akan memanggil controller c_detail_dokter dengan menjalankan
method get_data_loket yang selanjutkan akan memanggil entitasm_detail yang
akan menjalankan method get_data_loket dengan parameter dt yang merupakan
array. Dt merupakan data nomor id tempat dokter tersebut melaksanakan praktik.
Kemudian data kembalian tersebut ditampilkan dalam bentuk modal untuk aktor
memilih loket pendaftaran yang tersedia. Apabila aktor telah memilih loket
pendaftaran tersebut maka selanjutnya sistem akan memanggil controller
c_detail_dokter dengan memanggil method booking_dokter yang selanjutnya
akan memanggil entitas m_detail dengan menjalankan method booking_dokter
yang memiliki parameter dt dalam bentuk array. Parameter dt tersebut
merupakan kumpulan data dari nomor id praktik, nomor id pelayanan, nomor id
pengguna, nomor id loket, nomor id jadwal praktik, dan nomor antrian saat ini.
Apabila aktor sudah melakukan login maka akan muncul nomor antrian aktor
tersebut, namun apabila aktor belum masuk kedalam sistem maka akan muncul
pesan untuk melakukan login terlebih dahulu.
8. Memantau Nomor Antrian (Med-01-011)
Gambar 5.9 Sequence Diagram Memantau Nomor Antrian

Gambar 5.9 merupakan alur proses dari fungsi memantau nomor antrian,
dimana aktor dapat menjalankan fungsi tersebut dengan cara memilih menu
antrian yang kemudian akan memanggil controller c_antrian dengan menjalankan
method index. Selanjutnya method index tersebut akan memanggil entitas
m_antrian dengan menjalankan method get_antrian yang memiliki parameter id
39
yang merupakan id dari aktor tersebut. apabila aktor telah melakukan login maka
akan menampilkan status antriannya, namun apabila belum melakukan login
maka akan muncul pesan error dan permintaan untuk melakukan login terlnbih
dahulu
9. Melihat Detail Profil Pengguna (Med-01-012)
Gambar 5.10 merupakan alur proses dari fungsi melihat detail profil pengguna,
dimana aktor dapat melakukan fungsi tersebut dengan menekan tombol yang ada
di pojok kanan atas sistem yang nantinya akan menampilkan submenu yang ada
didalamnya. Kemudian akan memanggil controller c_profil dengan menjalankan
method index yang selanjutnya akan memanggil entitas m_user dengan
menjalankan get_data_profil yang memiliki parameter id yang merupakan id dari
aktor tersebut. setelah itu kemudian akan menjalankan method get_jamkes
dengan parameter id yang merupakan id dari aktor tersebut.
Gambar 5.10 Sequence Diagram Melihat Detail Profil Pengguna

10. Mengedit Detail Profil Pengguna (Med-01-013)
Gambar 5.11 merupakan alur proses dari fungsi mengedit detail profil
pengguna, dimana aktor dapat melakukan fungsi tersebut dengan cara menenkan
menu edit profil yang nantinya akan memanggil controller c_profil yang nantinya
akan menjalankan method editProfil(). Method tersebut akan memanggil entitas
m_user kemudian menjalankan method get_data_profil yang memilii parameter
id yang merupakan id dari aktor serta menjalankan method get_jamkes dengan
parameter id yang sama dengan sebelumnya. Kemudian aktor memasukkan
datayang diperlukan oleh sistem, kemudian sistem akan merekan dan
mengirimkan data tersebut melalui controller c_profil dengan menggunakan
method insertData yang nantinya akan memanggil entitas m_user dengan
menjalankan method isert_data_update dengan parameter dt dimana dt tersebut
merupakan array dan kumpulan dari data masukan aktor.
40
Gambar 5.11 Sequence Diagram Mengedit Detail Profil Pengguna
11. Logout (Med-01-014)
Gambar 5.12 Sequence Diagram Logout

Gambar 5.12 merupakan alur proses dari fungsi logut, dimana aktor dapat
menekan tombol logout yang ada di pojok kanan atas dari sistem kemudian akan
memanggil controller c_login untuk menghapus session aktor menggunakan
method logout dan melakukan destroy menggunakan method sess_destroy.
41
5.4.1.2 Class Diagram
Gambar 5.13 Class Diagram Medique
42
Pada Gambar 5.13 sistem Medique ini memiliki 14 kelas yang terdiri dari kelas
controller dan kelas model, dimana kelas controller terdiri dari c_login, c_antrian,
c_detail_dokter, c_dashcoard, c_profil, dan c_detail_faskes dimana kelas-kelas
tersebut meng-extends kelas MY_Controller. Kelas model pada sistem Medique ini
terdiri dari kelas m_antrian, m_doctor, m_detail, m_user, dan m_faskes dimana
kelas-kelas tersebut meng-extends kelas MY_Model.
5.4.2 Perancangan Komponen

Perancangan komponen pada sistem Medique ini diwakili oleh pseudocode
dari 3 method. Method tersebut adalah method booking_dokter pada kelas
c_detail_dokter, method get_data_selection pada kelas c_detail_dokter, method
index pada kelas c_antrian.
Kode Sumber 1: Pseudocode booking_dokter
1 start booking_dokter()
2
3 alamatUrl = ‘’
4
5 dt[‘intIDPartner’] = post(‘idPartner’)
6 dt['intIDJenisPelayanan']= post(‘idJenisPelayanan’)
7 dt['intIDUser']= execute session->userdata('intIDPartner')
8 dt['intIDLoket'] = post(‘idLoket’)
9 dt['intIDJadwalPraktek'] = post(‘idJadwalPraktek’)
10 dt['dtAntrian'] = post(‘dtAntrian’)
11
12 output = ‘’
13 if dt['intIDUser'] is not empty then
14 retVal = execute booking_dokter(dt)
15 alamatUrl = ‘c_antrian’;
16
17 foreach retVal do
18 output .= judul halaman
19 output .= nomor antrian dan nomor loket
20 end foreach
21
22 else
24 output = judul halaman
25 output = pesan error
26 end if
27 output = button ‘OK’
28
29 print output
30 end
Kode Sumber 2: Pseudocode get_data_selection

1 start get_data_selection
2 date_input = post(‘dateSelection’)
3 date = execute DateTime(date_input)
4 result = execute date(‘Y-m-d H:i:s’)
5
6 dt['intIDDokter'] = post("idDokter")
7 dt['intDay'] = execute date('w', strtotime(date_input)) + 1
8 dt['dtAntrian'] = date_input ." 00:00:00"
9
10 retVal = execute get_detail_jadwal_dokter(dt)
11
12 if count retVal = 0 then
43
13 output .= pesan error
14
15 else
16 output.= table header
17
18 foreach retVal do
19 output .= daftar praktik dokter
20 end foreach
21
22 output .= tag table
23 end if
24
25 print output
26 end
Kode Sumber 3: Pseudocode index

1 start index
2
3 id = execute session->userdata(‘intIDPartner’)
4
5 if id is not empty then
6 dt[‘user’] = id
7 retVal[‘data_antrian’] = execute get_antrian(dt)
8 execute view ('antrian/content', retVal)
9 else
10 execute view ('layout/404_error')
11 end if
12 end
5.4.3 Perancangan Antarmuka

5.4.3.1 Perancangan Antarmuka Login
Perancangan antarmuka login dapat dilihat pada Gambar 5.14 dan keterangan
dari masing-masing nomor dijelaskan pada Tabel 5.19 berikut ini:
Gambar 5.14 Perancangan Antarmuka Login
Tabel 5.19 Keterangan Perancangan Antarmuka Login

No Nama Objek Tipe Keterangan
1 Logo Image Logo sistem Medique
44
2 Judul halaman Header Judul halaman login
3 Username Label Label Username
4 Kolom username Textfield Digunakan untuk memasukkan
username pengguna
5 Kata sandi Label Label kata sandi
6 Kolom kata sandi Textfield Digunakan untuk memasukkan kata
sandi pengguna
7 Label daftar sekarang Link Label tulisan yang digunakan untuk
mendaftar sebagai pengguna baru
sistem
8 Masuk Button Tombol untuk masuk kedalam sistem
5.4.3.2 Perancangan Antarmuka Daftar

Perancangan antarmuka daftar dapat dilihat pada Gambar 5.15 dan
keterangan dari masing-masing nomor dijelaskan pada Tabel 5.20 berikut ini:
Gambar 5.15 Perancangan Antarmuka Daftar
Tabel 5.20 Keterangan Perancangan Antarmuka Daftar

1 Logo Image Logo sistem Medique
2 Judul halaman Header Judul halaman daftar
3 Email Label Label email
4 Kolom email Textfield Digunakan untuk memasukkan email
pengguna
45
5 Nama depan Label Label nama depan
6 Nama belakang Label Label nama belakang
7 Kolom nama depan Textfield Digunakan untuk memasukkan nama
depan pengguna
8 Kolom nama belakang Textfield Digunakan untuk memasukkan nama
belakang pengguna
9 Username Label Label username
10 Kolom username Textfield Digunakan unutk memasukkan
username pengguna
11 Kata sandi Label Label kata sandi
12 Konfirmasi kata sandi Label Label konfirmasi kata sandi
13 Kolom kata sandi Textfield Digunakan untuk memasukkan kata
sandi pengguna
14 Kolom konfirmasi kata Textfield Digunakan untuk konfirmasi kata sandi
sandi pengguna
15 Label masuk Link Label tulisan yang digunakan untuk
masuk kedalam sistem Medique
16 Daftar Button Tombol untuk mendaftarkan akun
5.4.3.3 Perancangan Antarmuka Melihat Daftar Dokter

Perancangan antarmuka melihat daftar dokter dapat dilihat pada Gambar 5.16
dan keterangan dari masing-masing nomor dijelaskan pada Tabel 5.21 berikut ini:
Gambar 5.16 Perancangan Antarmuka Melihat Daftar Dokter
46
Tabel 5.21 Keterangan Perancangan Antarmuka Melihat Daftar Dokter
1 Logo medique Image Logo medique yang dapat berfungsi
sebagai link membuka halaman
beranda sistem
2 Masuk/username Button Tombol yang berguna untuk membuka
pengguna halaman login atau sebagai tombol
untuk membuka halaman profil
pengguna dan keluar dari sistem
3 Judul halaman Header Judul halaman beranda
4 Menu beranda Link link yang digunakan untuk membuka
halaman beranda sistem Medique ini
5 Menu antrian Link link yang digunakan untuk membuka
halaman antrian pengguna
6 Dokter Tab Tab yang digunakan untuk melihat
daftar dokter yang terintegrasi dengan
sistem
7 Fasilitas Kesehatan Tab Tab yang digunakan untuk melihat
daftar fasilitas kesehatan yang
terintegrasi dengan sistem
8 Cari dokter Label Label cari dokter
9 Kolom cari dokter Textfield Digunakan untuk memasukkan nama
dokter yang dicari
10 Pilih kota Label Label pilih kota
11 Kolom pilih kota Dropdown Digunakan untuk memilih kota domisili
dokter
12 Pilih spesialis Label Label pilih spesialis
13 Kolom pilih spesialis Dropdown Digunakan untuk memilih spesialisasi
dokter
14 Pilih jenis kelamin Label Label pilih jenis kelamin
15 Daftar jenis kelamin Radio button Digunakan untuk memilih jenis kelamin
dokter
16 Tombol cari Button Tombol untuk mengirimkan data
filtering
17 Foto dokter Image Foto dokter yang terintegrasi sistem
18 Nama doker Link Digunakan untuk melihat detail
informasi dokter
19 Data profil dokter Paragraf Detail informasi dokter
47
5.4.3.4 Perancangan Antarmuka Melihat Detail Dokter
Perancangan antarmuka melihat detail dokter dapat dilihat pada Gambar 5.17
dan keterangan dari masing-masing nomor dijelaskan pada Tabel 5.22 berikut ini:
Gambar 5.17 Perancangan Antarmuka Melihat Detail Dokter
Tabel 5.22 Keterangan Perancangan Antarmuka Melihat Detail Dokter

beranda sistem
3 Judul halaman Header Judul halaman detail dokter
6 Foto dokter Image Foto dokter yang terintegrasi sistem
7 Nama doker Label Label nama dokter
8 Data profil dokter Paragraf Detail informasi dokter
9 Kolom tanggal seleksi Date time picker Digunakan untuk melihat jadwal
praktik dokter di waktu lain
48
10 Tombol cari Button Digunakan untuk mencari dengan
tanggal terpilih
11 Daftar jadwal praktik Table Tabel daftar praktik dokter
dokter
12 Label booking Link Digunakan untuk memesan nomor
antrian pada jadwal praktik dimaksud
5.4.3.5 Perancangan Antarmuka Memantau Nomor Antrian

Perancangan antarmuka memantau nomor antrian dapat dilihat pada
Gambar 5.18 dan keterangan dari masing-masing nomor dijelaskan pada
Tabel 5.23 berikut ini:
Gambar 5.18 Perancangan Antarmuka Memantau Nomor Antrian
Tabel 5.23 Keterangan Perancangan Antarmuka Memantau Nomor Antrian

beranda sistem
3 Judul halaman Header Judul halaman riwayat antrian
6 Nama tempat praktik Label Label nama tempat praktik dimana
nomor antrian didapat
7 Data antrian Label Berisi nomor antrian yang sedang
dilayani dokter
49
5.4.3.6 Perancangan Antarmuka Melihat Detail Profil Pengguna
Perancangan antarmuka melihat detail profil pengguna dapat dilihat pada
Gambar 5.19 Perancangan Antarmuka Melihat Detail Profil Pengguna
Tabel 5.24 Keterangan Perancangan Antarmuka Melihat Detail Profil Pengguna

beranda sistem
3 Judul halaman Header Judul halaman profil
6 Foto profil pengguna Image Foto profil pengguna
7 Data profil pengguna Paragraf Detail informasi pengguna
8 Label edit profil Link Digunakan untuk mengedit detail profil
pengguna
5.4.3.7 Perancangan Antarmuka Mengedit Detail Profil Pengguna

Perancangan antarmuka mengedit detail profil pengguna dapat dilihat pada
50
Gambar 5.20 Perancangan Antarmuka Mengedit Detail Profil Pengguna
Tabel 5.25 Keterangan Perancangan Antarmuka Mengedit Detail Profil

Pengguna
beranda sistem
3 Judul halaman Header Judul halaman profil
6 Foto profil pengguna Image Foto profil pengguna
7 Nama pengguna Label Label nama pengguna
8 Kolom nama pengguna Textfield Digunakan untuk memasukkan nama
pengguna
9 Nomor KTP Label Label nomor KTP
10 Kolom nomor KTP Textfield Digunakan untuk memasukkan nomor
KTP pengguna
11 Tempat lahir Label Label tempat lahir
51
12 Kolom tempat lahir Textfield Digunakan untuk memasukkan tempat
lahir pengguna
13 Tanggal lahir Label Label tanggal lahir
14 Kolom tanggal lahir Date time picker Digunakan untuk memilih tanggal lahir
pengguna
15 Alamat Label Label alamat
16 Kolom alamat Rich-text box Digunakan untuk memasukkan alamat
pengguna
17 Nomor telepon Label Label nomor telepon
18 Kolom nomor telepon Textfield Digunakan untuk memasukkan nomor
telepon pengguna
19 Jenis jaminan Label Label jenis jaminan kesehatan
kesehatan
20 Kolom jenis jaminan Dropdown Digunakan untuk memilih jenis jaminan
kesehatan kesehatan pengguna
21 Nomor jaminan Label Label nomor jaminan kesehatan
kesehatan
22 Kolom nomor jaminan Textfield Digunakan untuk memasukkan nomor
kesehatan jaminan kesehatan pengguna
23 Pilih file foto profil Label Label pilih file foto profil
24 Kolom foto profil Input data Digunakan untuk memilih foto profil
pengguna
25 Tombol simpan data Button Digunakan untuk menyimpan data
masukan pengguna
26 Tombol batal button Digunakan untuk membatalkan
perubahan detail informasi opengguna
kdan kembali ke halaman profil
5.5 Spesifikasi Piranti Pendukung

5.5.1 Spesifikasi Perangkat Keras
Perangkat keras yang digunakan untuk pengembangan Sistem Informasi
Tanaman Tembakau adalah:
1. Intel Core i5 2.4 GHz
2. 14.0” HD LCD
3. Nvidia Geforce™ GT 820M with 2 GB Dedicated VRAM
4. 4 GB DDR3 Memory / 1000 GB HDD
52
5.5.2 Spesifikasi Perangkat Lunak
Pada pengembangan Sistem Informasi Tanaman Tembakau ini didukung oleh
perangkat lunak berikut ini:
1. Development Tools: Sublime, XAMPP
2. Browser: Google Chrome
3. Framework: Code Igniter 3.1.4
4. Bahasa Pemrograman: PHP, HTML, Javascript
5. Sistem Operasi: Windows 10
5.6 Implementasi
5.6.1 Implementasi Algoritma
Bagian ini merupakan implementasi dari pseudocode yang telah dideklarasikan
pada sub-bab 5.4.2. Dimulai dengan implementasi method booking_dokter,
get_data_selection dan index yang dapat dilihat pada kode sumber 4, kode
sumber 5 dan kode sumber 6 berikut ini:
Kode Sumber 4: method booking_dokter
1 public function booking_dokter(){
2 $alamatUrl = "";
3 $dt['intIDPartner'] = $this->input->post("idPartner");
4 $dt['intIDJenisPelayanan'] = $this->input-
5 >post("idJenisPelayanan");
6 $dt['intIDUser'] = $this->session->userdata('intIDPartner');
7 $dt['intIDLoket'] = $this->input->post("idLoket");
8 $dt['intIDJadwalPraktek'] = $this->input-
9 >post("idJadwalPraktek");
10
11 $dt['dtAntrian'] = $this->input->post("dtAntrian");
12 $output ="";
13 if (isset($dt['intIDUser'])) {
14 $retVal = $this->m_detail->booking_dokter($dt);
15
16 $alamatUrl = "c_antrian";
17 foreach ($retVal as $key => $value) {
18 $output .= '
19 <h4 class="lh-3 mg-b-20">Berhasil</h4>
20 ';
21 $output .= '
22 <p>Selamat Nomor Antrian Anda <b>'.
23 $value['txtNoAntrianLoket'] .'</b> dengan Nomor Antrian Poli <b>'.
24 $value['txtNoAntrianPoli'] .'</b> ada <b>'.
25 $value['txtJenisPelayanan'] .'</b></p>
26 ';
27 }
28 } else {
29
30 $alamatUrl = "c_login";
31 $output .= '
32 <h4 class="lh-3 mg-b-20">Maaf</h4>
33 ';
34 $output .= '
35 Permintaan Anda Tidak Dapat Diproses<br/>
36 Silahkan Lakukan Login Terlebih Dahulu.
53
37 ';
38 }
39
40 $output .= '
41 <div class="modal-footer">
42 <a href="'. $alamatUrl .'" type="button" class="btn btn-
43 primary pd-x-20">OK</a>
44 </div>
45 ';
46 echo $output;
47 }
Kode Sumber 5: method get_data_selection

1 public function get_data_selection(){
2 $output = "";
3 $date_input = $this->input->post("dateSelection");
4 $date = new DateTime($date_input);
5 $this->result = $date->format('Y-m-d H:i:s');
6
7 $dt['intIDDokter'] = $this->input->post("idDokter");
8 $dt['intDay'] = date('w', strtotime($date_input)) + 1;
9 $dt['dtAntrian'] = $date_input ." 00:00:00";
10
11 $retVal = $this->m_detail->get_detail_jadwal_dokter($dt);
12 if (count($retVal)==0) {
13 $output .= '
14 <div class="alert mg-b-0 text-center" role="alert">
15 <strong class="d-block d-sm-inline-block-
16 force">Maaf!</strong>Data yang Anda Cari Tidak Ditemukan
17 </div>
18 ';
19 }
20 else {
21 $output .= '
22 <table id="dataTable" class="table display responsive
23 nowrap">
24 <thead>
25 <tr>
26 <th class="wd-25p">Lokasi Praktek</th>
27 <th class="wd-20p">Jenis Pelayanan</th>
28 <th class="wd-25p">Jam Pelayanan</th>
29 <th class="wd-15p">Antrian</th>
30 <th class="wd-15p">Kuota</th>
31 <th class="wd-10p"></th>
32 </tr>
33 </thead>
34 ';
35 foreach ($retVal as $key => $value) {
36 $output .= '
37 <tbody>
38 <tr id="'. $value['intIDPartner'] .'">
39 <td data-target="idPartner" hidden>'.
40 $value['intIDPartner'] .'</td>
41 <td data-target="idJenisPelayanan" hidden>'.
42 $value['intIDJenisPelayanan'] .'</td>
43 <td data-target="idJadwalPraktek" hidden>'.
44 $value['intIDJadwalPraktek'] .'</td>
45 <td>'. $value['txtPartnerName'] .'</td>
46 <td>'. $value['txtJenisPelayanan'] .' </td>
47 <td>'. $value['dtJamMulai']. ' - '
48 .$value['dtJamSelesai'] .'</td>
49 <td>'. $value['intJumlahAntrian'] .' </td>
50 <td>'. $value['intKuota'] .' </td>
54
51 <td> <a href="" data-toggle="modal" data-
52 target="#pilihLoket" data-role="booking" data-id="'.
53 $value['intIDPartner'] .'"> Booking </a></td>
54 </tr>
55 </tbody>
56 ';
57 }
58 $output .= '</table>';
59 }
60 echo $output;
61 }
Kode Sumber 6: method index

1 public function index(){
2 $id = $this->session->userdata('intIDPartner');
3 if (isset($id)) {
4 $dt['idUser'] = $id;
5 $retVal['data_antrian'] = $this->m_antrian->get_antrian($dt);
6 $this->load->view('antrian/content', $retVal);
7 } else {
8 $this->load->view('layout/404_error');
9 }
10 }
5.6.2 Implementasi Antarmuka

5.6.2.1 Implementasi Antarmuka Login
Gambar 5.21 Implementasi Antarmuka Login

Gambar 5.21 merupakan implementasi dari perancangan antarmuka login,
dimana terdapat logo sistem Medique pada samping kiri layar, judul pada bagian
atas sistem, label dan kolom untuk username, label dan kolom untuk kata sandi,
link pendaftaran, serta tombol untuk masuk kedalam sistem Medique.
5.6.2.2 Implementasi Antarmuka Daftar
Gambar 5.22 merupakan implementasi dari perancangan antarmuka daftar.
Terdapat 6 kolom yang harus diisi oleh pengguna untuk bisa menggunakan sistem
55
secara keseluruhan. 6 kolom tersebut terdiri dari alamat email, nama depan, nama
belakang, username, kata sandi kan konfirmasi kata sandi.
Gambar 5.22 Implementasi Antarmuka Daftar
5.6.2.3 Implementasi Antarmuka Melihat Daftar Dokter
Gambar 5.23 Implementasi Antarmuka Melihat Daftar Dokter
dan Gambar 5.24 merupakan implementasi dari perancangan antarmuka

melihat daftar dokter. Daftar dokter tersebut akan ditampilkan sesuai dengan
banyaknya dokter yang teerintegrasi dengan sistem. Daftar tersebut dapat
dilakukan filterisasi dengan menentukan parameter yang ingin ditampilkan pada
bagian atas halaman yaitu nama, kota, spesialisasi, dan jenis kelamin dari dokter
yang ingin ditampilkan.
56

5.6.2.4 Implementasi Antarmuka Melihat Detail Dokter
Gambar 5.25 merupakan implementasi dari perancangan antarmuka melihat
detail dokter, dimana pada detail dokter tersebut terdapat nama dan foto dokter
dimaksud serta menampilkan data praktik pada hari tertentu. Data tersebut
ditampilkan pada tabel bagian bawah sistem dengan terdapat tombol booking di
sebelah kanan tabel untuk pengguna melakukan pemesanan nomor antrian.
57
Gambar 5.25 Implementasi Antarmuka Melihat Detail Dokter
5.6.2.5 Implementasi Antarmuka Memantau Nomor Antrian

Gambar 5.26 merupakan implementasi dari perancangan antarmuka
memantau nomor antrian, dimana terdapat nama fasilitas kesehatan pada bagian
atas dengan latar hijau sebagai penanda bahwa antrian sedang berjalan
sedangkan apabila nomor antrian telah lewat maka akan berubah menjadi warna
abu-abu. Pada bagian bawah terdapat nomor antrian pengguna dan nomor
antrian saat ini yang sedang dilakukan pelayanan kesehatan oleh dokter.
58
Gambar 5.26 Implementasi Antarmuka Memantau Nomor Antrian
5.6.2.6 Implementasi Antarmuka Melihat Detail Profil Pengguna
Gambar 5.27 Implementasi Antarmuka Melihat Detail Profil Pengguna

Gambar 5.27 merupakan implementasi dari perancangan antarmuka melihat
detail profil pengguna, dimana pada sebelah kiri terdapat foto pengguna dengan
data informasi pengguna berada pada sebelah kanan. Link untuk mengedit detail
profil disini terletak disebelah nama pengguna sehingga pengguna tidak
kebingungan ketika mencari link pengeditan detail profilnya.
59
5.6.2.7 Implementasi Antarmuka Mengedit Detail Profil Pengguna
Gambar 5.28 Implementasi Antarmuka Mengedit Detail Profil Pengguna
Gambar 5.29 Implementasi Antarmuka Mengedit Detail Profil Pengguna

Gambar 5.28 dan Gambar 5.29 merupakan implementasi dari peracangan
antarmuka mengedit detail profil pengguna. Terdapat kolom yang harus pengguna
isi seperti nama pengguna, tempat lahir sampai nomor jaminan kesehatan.
Terdapat tombol input file untuk mengubah foto profil pengguna pada bagian
bawah serta terdapat 2 tombol fisik untuk menyimpan dan membatalkan
perubahan yang dilakukan pengguna.
5.7 Pengujian
5.7.1 Pengujian Unit (Whitebox testing)
Pada pengujian unit menggunakan white box untuk mengetahui apakah sistem
yang dibangun sudah benar sesuai dengan yang dibutuhkan berdasarkan unit yang
dibuat. Pada proses pengujian unit ini, method yang akan diuji dapat dilihat pada
Tabel 5.26
60
Tabel 5.26 method-method yang Diuji
Jenis
No. Nama Method Tujuan Pengujian
Pengujian
1 Booking_dokter Memastikan semua jalur pada unit White Box
booking_dokter dilewati dan hasil keluaran
sesuai dengan yang diharapkan
2 Get_data_selection Memastikan semua jalur pada unit White Box
get_data_selection dilewati dan hasil keluaran
sesuai dengan yang diharapkan
3 Index Memastikan semua jalur pada unit index White Box
dilewati dan hasil keluaran sesuai dengan yang
diharapkan
5.7.1.1 Method booking_dokter

Kode Sumber 1: Pseudocode booking_dokter
1 start booking_dokter()
1
1 alamatUrl = ‘’
1
1 dt[‘intIDPartner’] = post(‘idPartner’)
1 dt['intIDJenisPelayanan']= post(‘idJenisPelayanan’)
1 dt['intIDUser']= execute session->userdata('intIDPartner')
1 dt['intIDLoket'] = post(‘idLoket’)
1 dt['intIDJadwalPraktek'] = post(‘idJadwalPraktek’)
1 dt['dtAntrian'] = post(‘dtAntrian’)
1
1 output = ‘’
2 if dt['intIDUser'] is not empty then
3 retVal = execute booking_dokter(dt)
3
4 foreach retVal do
5 output .= judul halaman
5 output .= nomor antrian dan nomor loket
6 end foreach
7 else
7 alamatUrl = ‘c_login’;
7 output = judul halaman
7 output = pesan error
8 end if
9 output = button ‘OK’
9
9 print output
9 end
61
Gambar 5.30 Flow Graph booking_dokter
Gambar 5.30 merupakan flow graph dari pseudocode booking_dokter. Flow
graph tersebut akan digunakan nantinya dalam penentuan ukuran kompleksitas
(cyclomatic complexity) dan jalur independennya. Untuk lebih jelasnya dapat
dilihat pada persamaan 5.1 dan 5.2 dibawah ini.
Cyclomatic Complexity
𝑉[𝐺] = ∑ 𝑟𝑒𝑔𝑖𝑜𝑛 (5.1)
=3
𝑉[𝐺] = (𝐸 − 𝑁) + 2
= 10 − 9 + 2
=3
𝑉[𝐺] = 𝑃 + 1
=2+1
=3
Jalur Independen
𝐽𝑎𝑙𝑢𝑟 [1] = 1 − 2 − 3 − 4 − 5 − 6 − 4 − 8 − 9 (5.2)
𝐽𝑎𝑙𝑢𝑟 [2] = 1 − 2 − 3 − 4 − 8 − 9
𝐽𝑎𝑙𝑢𝑟 [3] = 1 − 2 − 7 − 8 − 9
Tabel 5.27 Hasil Pengujian Unit booking_dokter

No. Jalur Data input Hasil yang Hasil Valid
diharapkan
1 1-2-3-4-5-6- [intIDPartner] => 1, Data tersimpan, Data tersimpan, Pass
4-8-9 [intIDJenisPelayanan] pengguna pengguna
=> 1, [intIDUser] => 1, mendapatkan mendapatkan
62
[intIDLoket] => 1, nomor antrian, nomor antrian,
[intIDJadwalPraktek] sistem sistem
=> 1, [dtAntrian] => menampilkan menampilkan
2018-10-29 00:00:00 halaman antrian halaman antrian
pengguna pengguna
2 1-2-3-4-8-9 [intIDPartner] => 1, Data tersimpan, Data tersimpan, Pass

[intIDJenisPelayanan] pengguna pengguna
=> 1, [intIDUser] => 1, mendapatkan mendapatkan
[intIDLoket] => 1, nomor antrian, nomor antrian,
[intIDJadwalPraktek] sistem sistem
=> 1, [dtAntrian] => menampilkan menampilkan
2018-10-29 00:00:00 halaman antrian halaman antrian
pengguna pengguna
3 1-2-7-8-9 [intIDPartner] => 1, Permintaan tidak Permintaan tidak Pass
[intIDJenisPelayanan] dapat diproses dapat diproses
=> 1, [intIDUser] => dan menampilkan dan menampilkan
null, [intIDLoket] => 1, pesan error untuk pesan error untuk
[intIDJadwalPraktek] melakukan login melakukan login
=> 1, [dtAntrian] => kedalam sistem kedalam sistem
2018-10-29 00:00:00 terlebih dahulu terlebih dahulu
5.7.1.2 Method get_data_selection

Kode Sumber 2: Pseudocode get_data_selection
1 start get_data_selection
1 date_input = post(‘dateSelection’)
1 date = execute DateTime(date_input)
1 result = execute date(‘Y-m-d H:i:s’)
1
1 dt['intIDDokter'] = post("idDokter")
1 dt['intDay'] = execute date('w', strtotime(date_input)) + 1
1 dt['dtAntrian'] = date_input ." 00:00:00"
1
1 retVal = execute get_detail_jadwal_dokter(dt)
1
2 if count retVal = 0 then
3 output .= pesan error
3
4 else
4 output.= table header
4
5 foreach retVal do
6 output .= daftar praktik dokter
7 end foreach
8 output .= ‘</table>’
9 end if
10 print output
10 end
63
Gambar 5.31 Flow Graph get_data_selection
Gambar 5.31 merupakan flow graph dari pseudocode get_data_selection.
Flow graph tersebut akan digunakan nantinya dalam penentuan ukuran
kompleksitas (cyclomatic complexity) dan jalur independennya. Untuk lebih
jelasnya dapat dilihat pada persamaan 5.3 dan 5.4 dibawah ini.
𝑉[𝐺] = ∑ 𝑟𝑒𝑔𝑖𝑜𝑛 (5.3)
=3
𝑉[𝐺] = (𝐸 − 𝑁) + 2
= 11 − 10 + 2
=3
𝑉[𝐺] = 𝑃 + 1
=2+1
=3
Jalur Independen
𝐽𝑎𝑙𝑢𝑟 [1] = 1 − 2 − 3 − 9 − 10 (5.4)
𝑗𝑎𝑙𝑢𝑟 [2] = 1 − 2 − 4 − 5 − 6 − 7 − 5 − 8 − 9 − 10
𝑗𝑎𝑙𝑢𝑟 [3] = 1 − 2 − 4 − 5 − 8 − 9 − 10
Tabel 5.28 Hasil Pengujian Unit get_data_selection

diharapkan
1 1-2-3-9-10 ['intIDDokter'] = 1 Menampilkan Menampilkan Pass
pesan data yang pesan data yang
['intDay'] = 7
64
['dtAntrian'] = 28-10- dicari tidak dicari tidak
2018 00:00:00 ditemukan ditemukan
2 1-2-4-5-6-7- ['intIDDokter'] = 1 Permintaan Permintaan Pass
4-8-9-10 diproses dan diproses dan
['intDay'] = 3
menampilkan menampilkan
['dtAntrian'] = 24-10- data praktik data praktik
2018 00:00:00 dokter dokter
3 1-2-4-5-8-9- ['intIDDokter'] = 1 Permintaan Permintaan Pass
10 diproses dan diproses dan
['intDay'] = 3
['dtAntrian'] = 24-10- data praktik data praktik
2018 00:00:00 dokter dokter
5.7.1.3 Method index

Kode Sumber 3: Pseudocode index
1 start index
1
1 id = execute session->userdata(‘intIDPartner’)
1
2 if id is not empty then
3 dt[‘user’] = id
3 retVal[‘data_antrian’] = execute get_antrian(dt)
3 execute view ('antrian/content', retVal)
4 else
4 execute view ('layout/404_error')
5 end if
6 end
Gambar 5.32 Flow Graph index

Gambar 5.32 merupakan flow graph dari pseudocode index dari kelas
c_antrian. Flow graph tersebut akan digunakan nantinya dalam penentuan ukuran
kompleksitas (cyclomatic complexity) dan jalur independennya. Untuk lebih
jelasnya dapat dilihat pada persamaan 5.5 dan 5.6 dibawah ini.
65
𝑉[𝐺] = ∑ 𝑟𝑒𝑔𝑖𝑜𝑛 (5.5)
=2
𝑉[𝐺] = (𝐸 − 𝑁) + 2
=6−6+2
=2
𝑉[𝐺] = 𝑃 + 1
=1+1
=2
Jalur Independen
𝐽𝑎𝑙𝑢𝑟 [1] = 1 − 2 − 4 − 5 − 6 (5.6)
𝐽𝑎𝑙𝑢𝑟 [2] = 1 − 2 − 3 − 5 − 6
Tabel 5.29 Hasil Pengujian Unit index

diharapkan
1 1-2-4-5-6 id = “1” Permintaan Permintaan Pass
diproses dan diproses dan
data antrian data antrian
pengguna pada pengguna pada
halaman antrian halaman antrian
2 1-2-3-5-6 id = “null” Permintaan tidak Permintaan tidak Pass
dapat diproses dapat diproses
dan menampilkan dan menampilkan
pesan error untuk pesan error untuk
melakukan login melakukan login
kedalam sistem kedalam sistem
terlebih dahulu terlebih dahulu
5.7.2 Pengujian Validasi (Blackbox testing)

Pengujian validasi dilakukan ketika kebutuhan yang sudah ditetapkan sebagai
bagian dari pemodelan kebutuhan divalidasi terhadap perangkat lunak yang telah
dibangun. Pengujian validasi dikatakan berhasil apabila fungsi yang ada pada
perangkat lunak sesuai dengan yang diharapkan. Pada pengujian validasi ini
digunakan metode blackbox testing. Dengan blackbox testing memungkinkan
pembuat perangkat lunak untuk memperoleh kondisi yang terjadi untuk suatu
masukan yang akan menjalankan semua kebutuhan. Untuk lebih jelasnya, rencana
66
dan hasil pengujian validasi dapat dilihat pada Tabel 5.30, Tabel 5.31, dan
Tabel 5.32
Tabel 5.30 Rencana Pengujian Validasi
No Nomor Use Case Tujuan Pengujian Jenis Pengujian
Kebutuhan
1 Med-01-001 Login Mengetahui bahwa sistem Black Box
dapat merespon request
untuk login kedalam
sistem
2 Med-01-002 Daftar Mengetahui bahwa sistem Black Box
untuk daftar kedalam
sistem
3 Med-01-003 Melihat Daftar Mengetahui bahwa sistem Black Box
Dokter dapat merespon request
untuk melihat daftar
dokter
4 Med-01-004 Melihat Daftar Mengetahui bahwa sistem Black Box
Fasilitas Kesehatan dapat merespon request
untuk melihat daftar
fasilitas Kesehatan
5 Med-01-005 Memfilter Daftar Mengetahui bahwa sistem Black Box
Dokter dapat merespon request
untuk memfilter daftar
dokter
6 Med-01-006 Memfilter Daftar Mengetahui bahwa sistem Black Box
untuk memfilter daftar
fasilitas kesehatan
7 Med-01-007 Melihat Detail Dokter Mengetahui bahwa sistem Black Box
untuk melihat detail
dokter
8 Med-01-008 Melihat Detail Mengetahui bahwa sistem Black Box
untuk melihat detail
fasilitas kesehatan
9 Med-01-009 Melihat Jadwal Mengetahui bahwa sistem Black Box
Praktik Tertentu dapat merespon request
untuk melihat jadwal
praktik tertentu
10 Med-01-010 Melakukan Booking Mengetahui bahwa sistem Black Box
Pada Dokter dapat merespon request
Dimaksud untuk melakukan booking
pada dokter dimaksud
67
11 Med-01-011 Memantau Nomor Mengetahui bahwa sistem Black Box
Antrian dapat merespon request
untuk memantau nomor
antrian
12 Med-01-012 Melihat Detail Profil Mengetahui bahwa sistem Black Box
Pengguna dapat merespon request
untuk melihat detail profil
pengguna
13 Med-01-013 Mengedit Daftar Mengetahui bahwa sistem Black Box
Profil Pengguna dapat merespon request
untuk mengedit detail
profil pengguna
14 Med-01-014 Logout Mengetahui bahwa sistem Black Box
untuk keluar dari sistem
Tabel 5.31 Rencana Pengujian Validasi Kebutuhan Non-fungsional

No Nomor Kebutuhan Sistem Spesifikasi Kebutuhan Jenis Pengujian
Kebutuhan Sistem
1 Med-02-001 Usability Sistem dapat digunakan Manual
dengan mudah
Tabel 5.32 Hasil Pengujian Validasi Kebutuhan Funsional

No Kode Nama Kasus Uji Hasil yang Hasil yang Valid
Fungsi Diharapkan Didapatkan
1 Med-01- Login Pengguna Pengguna Pengguna Ya
001 memasukkan masuk kedalam masuk kedalam
username sistem sebagai sistem sebagai
dan kata pengguna pengguna
sandi yang terdaftar terdaftar
benar
Pengguna Sistem Sistem Ya
memasukkan menampilkan menampilkan
username pesan eror pesan eror
dan/atau bahwa bahwa
kata sandi username dan username dan
yang salah kata sandi tidak kata sandi tidak
benar benar
2 Med-01- Daftar Pengguna Data berhasil Data berhasil Ya
002 mengisi disimpan dan disimpan dan
semua field sistem akan sistem akan
yang tersedia membuka membuka
dan halaman login halaman login
menekan
68
tombol
daftar
Pengguna Muncul Muncul ya
mengisi permintaan permintaan
sebagian pengisian field pengisian field
field yang yang kosong yang kosong
tersedia dan
menekan
tombol
daftar
3 Med-01- Melihat Pengguna Sistem Sistem Ya
003 Daftar memilih tab menampilkan menampilkan
Dokter ‘dokter’ pada daftar dokter daftar dokter
yang yang
terintegrasi terintegrasi
oleh sistem oleh sistem
004 Daftar memilih tab menampilkan menampilkan
Fasilitas ‘fasilitas daftar fasilitas daftar fasilitas
Kesehatan kesehatan’ kesehatan yang kesehatan yang
pada terintegrasi terintegrasi
oleh sistem oleh sistem
5 Med-01- Memfilter Pengguna Sistem Sistem Ya
005 Daftar memasukkan menampilkan menampilkan
Dokter kriteria yang daftar dokter daftar dokter
sesuai dengan kriteria dengan kriteria
dengan dimaksud dimaksud
daftar dokter
yang ada
pada sistem
mengisi field menampilkan menampilkan
nama dokter bahwa data bahwa data
dengan isi dokter dokter
‘xyz’ dimaksud tidak dimaksud tidak
ditemukan ditemukan
6 Med-01- Memfilter Pengguna Sistem Sistem Ya
006 Daftar memasukkan menampilkan menampilkan
Fasilitas kriteria yang daftar fasilitas daftar fasilitas
Kesehatan sesuai kesehatan kesehatan
dengan dengan kriteria dengan kriteria
daftar dimaksud dimaksud
fasilitas
kesehatan
yang ada
pada sistem
mengisi field menampilkan menampilkan
nama bahwa data bahwa data
fasilitas fasilitas fasilitas
69
kesehatan kesehatan kesehatan
dengan isi dimaksud tidak dimaksud tidak
‘xyz’ ditemukan ditemukan
007 Detail memilih satu menampilkan menampilkan
Dokter dokter untuk detail informasi detail informasi
dilihat dokter dokter
detailnya dimaksud dimaksud
008 Detail memilih satu menampilkan menampilkan
Fasilitas fasilitas detail informasi detail informasi
Kesehatan kesehatan fasilitas fasilitas
untuk dilihat kesehatan kesehatan
detailnya dimaksud dimaksud
009 Jadwal memilih menampilkan menampilkan
Praktik tanggal daftar jadwal daftar jadwal
Tertentu 25/10/2018 praktik pada praktik pada
tanggal tanggal
25/10/2018 25/10/2018
memilih menampilkan menampilkan
tanggal pesan eror pesan eror
28/10/2018 bahwa data bahwa data
yang dicari tidak yang dicari tidak
ada ada
10 Med-01- Melakukan Pengguna Data booking Data booking Ya
010 Booking melakukan tersimpan dan tersimpan dan
Pada Dokter booking sistem sistem
Dimaksud dengan menampilkan menampilkan
kondisi telah halaman halaman
melakukan antrian antrian
login
melakukan menampilkan menampilkan
booking halaman eror halaman eror
dengan dan pesan dan pesan
kondisi untuk untuk
belum melakukan melakukan
melakukan login terlebih login terlebih
login dahulu dahulu
11 Med-01- Memantau Pengguna Sistem Sistem Ya
011 Nomor memilih menampilkan menampilkan
Antrian menu antrian antrian
antrian pengguna pengguna
dengan
kondisi telah
melakukan
login
70
memilih menampilkan menampilkan
menu halaman eror halaman eror
antrian dan pesan dan pesan
dengan untuk untuk
kondisi melakukan melakukan
belum login terlebih login terlebih
melakukan dahulu dahulu
login
012 Detail Profil memilih menampilkan menampilkan
Pengguna menu lihat detail profil detail profil
profil pengguna pengguna
13 Med-01- Mengedit Pengguna Sistem Sistem Ya
013 Detail Profil memilih menyimpan menyimpan
Pengguna menu edit perubahan perubahan
profil dan pengguna dan pengguna dan
melakukan menampilkan menampilkan
perubahan detail profil detail profil
foto profil
serta
menekan
tombol
simpan data
14 Med-01- Logout Pengguna Sistem Sistem Ya
014 memilih menghapus menghapus
menu logout session session
pada sistem pengguna dan pengguna dan
halaman halaman
beranda beranda
5.7.3 Pengujian Usabilitas

Pengujian usabilitas (Usability Testing) pada sistem ini dilakukan dengan
percobaan yang dilakukan oleh expert. Dimana expert mencoba sistem yang telah
kami bangun dan kemudian memberikan masukan dari sistem yang telah kami
bangun. Pengujian usabilitas ini dilakukan setiap kali iterasi dalam pembangunan
sistem Medique ini sehingga sistem dilakukan pengujian usabilitas setiap
penambahan kebutuhan sistem.
71
BAB 6 PENUTUP
6.1 Kesimpulan
Setelah dilakukan proses praktik kerja lapangan dan diperoleh hasil analisis dan
spesifikasi persyaratan, rancangan, implementasi dan pengujian sistem, ditarik
kesimpulan sebagai berikut:
1. Proses analisis kebutuhan sistem Medique dengan mengakuisisi dari
sistem sebelumnya menghasilkan 23 kebutuhan fungsional dan 1
kebutuhan non-fungsional untuk sistem Medique. Kebutuhan fungsional
tersebut terbagi ke dalam dua aktor, yaitu pengguna tamu dengan jumlah
9 kebutuhan dan pengguna terdaftar dengan jumlah 14 kebutuhan.
Kebutuhan fungsional dan non-fungsional tersebut kemudian dimodelkan
ke dalam use case diagram disertai dengan uraian skenarionya. Didapati
pula spesifikasi pada perangkat keras dan perangkat lunak yang dapat
mendukung berjalannya sistem Medique ini.
2. Proses perancangan berdasarkan analisis kebutuhan pada tahap
sebelumnya menghasilkan perancangan arsitektur yang dimodelkan
menggunakan sequence diagram dan class diagram, perancangan
komponen yang disusun dengan menggunakan pseudocode, dan
perancangan antarmuka yang dijelaskan dengan tata letak dan disertai
dengan keterangan objek yang terdapat pada tata letak masing-masing
halaman.
3. Dari hasil perancangan pada tahapan sebelumnya, dilakukan implementasi
sistem Medique pada sisi algoritma dan antarmuka. Implementasi pada sisi
algoritma dilakukan menggunakan bahasa PHP, sementara pada sisi
antarmuka diimplementasikan menggunakan HTML, didukung dengan
Bootstrap dan Javascript.
4. Setelah implementasi selesai, dilakukan pengujian white-box pada 3 unit.
Dari pengujian diperoleh hasil pass pada setiap kasus uji. Pengujian
dilanjutkan pada tingkat validasi kebutuhan dengan pengujian black-box
pada seluruh kebutuhan fungsional dan non-fungsional. Seluruh pengujian
validasi dinyatakan valid. Selanjutnya dilakukan pengujian usabilitas yang
dilakukan oleh expert yang kemudian dinyatakan bahwa sistem
6.2 Saran
Berdasarkan hasil penelitian ini, disimpulkan saran-saran berikut:
1. Sistem dapat dikembangkan pada platform mobile agar dapat menjangkau
pengguna mobile dengan lebih mudah.
2. Sistem dapat diluncurkan pada fasilitas kesehatan yang lebih banyak di
berbagai tempat, sehingga dapat diperoleh masukan yang lebih beragam agar
sistem dapat dikembangkan lebih baik lagi.
72
DAFTAR PUSTAKA
Bahrami, M., Singhal, M. 2016. A Dynamic Cloud Computing Platform for eHealth
Systems. 17th International Conference on e-Health Networking, Application
and Services, HealthCom 2015. p. 435-438
Booch, G., Rumbaugh, J., Jacobson, I. 2005. The Unified Modeling Language User
Guide. Reading: Addison-Wesley.
Cockburn, A. 2001. Writing Effective Use-Cases. Boston: Addison Wesley.
Deitel, H.M. 2004. JavaTM How to Program, Sixth Edition. Upper Saddle River:
Prentice Hall.
Fowler, M. 2004. UML Distilled: A Brief Guide to The Standard Object Modeling
Language (Third Edition). Boston: Addison-Wesley.
Gao, J., Tsao, J., Wu, Y. 2003. Testing and Quality Assurance for Component-Based
Software. Norwood: Artech House.
IBM, 2018. The structure of a SOAP message. [online] Tersedia di: <
https://www.ibm.com/support/knowledgecenter/en/SSMKHH_10.0.0/com.
ibm.etools.mft.doc/ac55780_.htm> [Diakses 18 Oktober 2018]
Larman, C. 2004. Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development (Third Edition). Upper Saddle
River: Addison Wesley Professional.
Marks, E.A., Lozano, R.R. 2010. Executive’s Guide to Cloud Computing. Hoboken:
John Wiley & Sons.
Mukhi, V., Shanbhag, S., Mukhi, S. 2008. XML WebServices and SOAP. New Delhi:
BPB Publications.
Rittinghouse, J.W., Ransome, J.F. 2010. Cloud Computing: Implementation,
Management, and Security. Boca Raton: CRC Press.
Pressman, R.S. 2010. Software Engineering: A Practitioner’s Approach. New York:
McGraw-Hill.
Sommerville, I. 2011. Software Engineering. Boston: Addison-Wesley.
Tran, K.T. 2013. Introduction to Web Services with Java. London: BookBoon
Usability.gov, 2018. Usability Testing. [Online]
Available at: https://www.usability.gov/how-to-and-
tools/methods/usability-testing.html [Diakses 18 Oktober 2018].
W3C, 2013. Extensible Markup Language (XML) 1.0 (Fifth Edition). World Wide
Web Consortium
73
LAMPIRAN A DOKUMENTASI KEGIATAN PKL
74
75

Laporan PKL 4.0 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Laporan PKL 4.0 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

LAPORAN PRAKTIK KERJA LAPANGAN (PKL)

CV. TECHNOBIT INDONESIA

PENGEMBANGAN SISTEM PELAYANAN FASILITAS

Muhammad Alimuddien Rasyid NIM : 155150200111227

PROGRAM STUDI TEKNIK INFORMATIKA

LAPORAN PRAKTIK KERJA LAPANGAN (PKL)

PENGEMBANGAN SISTEM PELAYANAN FASILITAS KESEHATAN TERPADU

Diajukan untuk memenuhi sebagian persyaratan Kurikulum Sarjana

Praktik Kerja Lapangan ini dilaksanakan pada

Telah diperiksa dan disetujui oleh:

Dosen Pembimbing PKL

Agi Putra Kharisma, S.T, M.T.

Tri Astoto Kurniawan, S.T, M.T, Ph.D

Saya menyatakan dengan sebenar-benarnya bahwa sepanjang pengetahuan

Malang, 26 September 2018

Moh. Zulfiqar Naufal Maulana

Penulis menyadari bahwa dalam penyusunan laporan ini masih banyak

Malang, 26 September 2018

Moh. Zulfiqar Naufal Maulana

E-Medica merupakan sebuah sistem pelayanan fasilitas kesehatan terpadu

E-Medica is an integrated health facility service system which integrates

Keywords: E-Medica, health facility, cloud computing, web, SOAP, XML

LEMBAR PENGESAHAN ............................................................................................ii

Tabel 4.1 Aturan Penulisan Kode Kebutuhan ....................................................... 20

Gambar 2.1 Struktur Organisasi CV. Technobit Indonesia ..................................... 5

LAMPIRAN A DOKUMENTASI KEGIATAN PKL ........................................................ 74

1.1 Latar belakang

1.2 Rumusan masalah

1.4 Batasan masalah

1.6 Sistematika Pembahasan

2.1 Sejarah Perusahaan

2.2 Alamat Perusahaan

2.3 Visi dan Misi Perusahaan

Gambar 2.1 Struktur Organisasi CV. Technobit Indonesia

2.5 Rantai Bisnis Perusahaan

Gambar 2.2 Rantai Bisnis CV. Technobit Indonesia

3.1 Web Service

3.3 Pengembangan Perangkat Lunak

3.4 Cloud Computing

3.5 Teknologi Pengembangan Sistem

Gambar 3.2 Siklus Pengembangan Perangkat Lunak secara Iteratif

3.6 Unified Modelling Language

3.6.1 Class Diagram

Gambar 3.3 Contoh Struktur Class Diagram (Dietel, 2004)

3.6.2 Use Case Diagram

Gambar 3.4 Contoh Diagram Use Case (Booch et al., 2005)

Gambar 3.5 Contoh Relasi antar Aktor (Booch et al., 2005)

3.6.4 Sequence Diagram

Gambar 3.7 Contoh Sequence Diagram (Pressman, 2010)

Gambar 3.8 Contoh Flow Graph (Pressman, 2010)

3.7.2 Blackbox Testing

Selama praktik kerja lapangan ini dilaksanakan, terdapat tahapan-tahapan

Gambar 4.1 Diagram Alir Pelaksanaan PKL

4.2 Analisis Kebutuhan

4.5.1 Pengujian Unit (Whitebox Testing)

4.5.3 Pengujian Usabilitas (Usability Testing)

4.6 Kesimpulan dan Saran

5.1 Gambaran Umum Sistem

5.2 Analisis Kebutuhan

5.2.1 Identifikasi Aktor

5.2.2 Kebutuhan Fungsional

No SRS-ID Nama Fungsi Deskripsi

Pengguna baru dapat melakukan