BAB IV PERANCANGAN SISTEM USULAN

(1)

47

BAB IV

PERANCANGAN SISTEM USULAN

4.1. Tahap Perancangan Sistem

Tahapan perancangan sistem menjelaskan tentang rancangan dari fungsi- fungsi sistem yang terdiri dari analisis, proses, data, antar muka dan sistem. Adapun tahapan-tahapan yang penulis rancang dalam sistem ini adalah sebagai berikut.

4.1.1. Analisis Kebutuhan

Sebelum melakukan perancangan sistem, penulis terlebih dahulu melakukan analisis kebutuhan pada sistem. Hal ini dimaksudkan agar dapat mengatasi ketidaksesuaian antara aplikasi yang dirancang dengan kebutuhan pengguna. Sehingga dapat memberikan kemudahan dan kenyamanan pengguna dalam mengakases sistem agar sistem berjalan dengan lancar.

1. Analisa Kebutuhan Fungsional

Analisa kebutuhan fungsional yang terdapat pada sistem pendaftaran online berbasis website ini terdiri dari 2 kebutuhan user , yaitu :

A. Kebutuhan Admin

1) Admin dapat melakukan masuk/Login dengan akun yang telah dibuat.

2) Admin dapat melihat dan mengelola data Pasien.

3) Admin dapat mencari data Pasien.

4) Admin dapat mengubah data Pasien.

5) Admin dapat menghapus data Pasien.

6) Admin dapat menyimpan data Pasien.

7) Admin dapat mencetak data Pasien.

(2)

8) Admin dapat keluar/Logout dari sistem.

B. Kebutuhan Pasien

1) Pasien dapat melakukan masuk/Login dengan akun yang telah dibuat.

2) Pasien yang belum memiliki akun dapat melakukan registrasi akun untuk mendapatkan hak akses masuk/Login.

3) Pasien dapat melihat informasi mengenai pelayanan yang ada di BKMM Cikampek.

4) Pasien dapat melakukan layanan pendaftaran online.

2. Kebutuhan Nonfungsional

Adapun kebutuhan nonfungsional diantara lain yaitu :

a. Sistem dapat menampilkan Form Login bagi pengguna atau Form registrasi akun bagi pengguna yang belum memiliki akun.

b. Sistem dapat menampilkan informasi pelayanan yang ada di BKMM Cikampek kepada pengguna.

c. Sistem dapat menampilkan form registrasi dan melakukan pendaftaran untuk pengguna.

d. Sistem dapat menampilkan dan mencetak data Pasien.

e. Sistem dapat keluar/Logout.

4.1.2. Rancangan Diagram Use Case

Use case diagram menjelaskan manfaat dari aplikasi jika dilihat dari sudut

pandang orang yang berada diluar sistem (aktor). Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem berinteraksi dengan dunia luar. Use Case diagram dapat digunakan selama proses analisa untuk menangkap requirements atau permintaan terhadap sistem dan untuk memahami bagaimana sistem

(3)

tersebut harus bekerja

.

Adapun Use Case diagram yang penulis rancang adalah sebagai berikut:

Gambar IV.1. Rancangan Use Case Diagram Pendaftaran Online

Tabel IV.1 Deskripsi Use Case Login

Use Case Name Login

Requirements

Pasien/Admin melakukan login sebelum mengakses sistem

Goal Pasien/Admin berhasil Login ke sistem

Pre-conditions Memasukan Username dan Password Post-Conditions Pasien /Admin dapat mengakses sistem Failed end conditions Pasien /Admin gagal melakukan Login

Actors Pasien dan Admin

Main flow/ Basic Path

1. Pasien /Admin masuk pada halaman Login

(4)

2. Pasien /Admin memasukan Username dan Password

3. Pasien /Admin masuk pada halaman utama website

Alternate Flow/ invariant A

Pasien/Admin berhasil masuk pada halaman utama website

Alternate Flow/ invariant B

1. Pasien/Admin gagal Login 2. Pasien/Admin melakukan Login

kembali

Tabel IV.2 Deskripsi Use Case Input Data Diri & Registrasi akun Use Case Name Input data diri & registrasi akun

Requirements Pasien melakukan penginputan data diri

Goal Pasien berhasil menginput data diri ke

sistem Pre-conditions

Pasien berada pada halaman pendaftaran online

Post-Conditions

Pasien berhasil menyimpan data diri ke sistem

Failed end conditions

Pasien tidak memasukan data diri ke sistem

Actors Pasien

1. Pasien masuk pada halaman utama website

2. Pasien masuk pada menu pendaftaran Online

3. Pasien input data diri

Alternate Flow/ invariant A Pasien berhasil input data diri ke sistem Alternate Flow/ invariant B

1. Pasien gagal input data diri

2. Pasien menginput kembali data diri

Tabel IV.3 Deskripsi Use Case Pilih Poli

Use Case Name Pilih Poli

Requirements Pasien diminta untuk memilih poli Goal Pasien berhasil memilih poli yang dituju Pre-conditions Pasien berada pada halaman pilih poli Post-Conditions Pasien berhasil memilih poli yang dituju Failed end conditions Pasien batal memilih poli

Actors Pasien

1. Pasien masuk pada halaman Login 2. Pasien pilih jenis poli

3. Poli berhasil tersimpan

(5)

Alternate Flow/ invariant A Pasien berhasil memilih poli yang dituju Alternate Flow/ invariant B

4. Pasien batal memilih poli 5. Poli yang dituju sudah penuh

Tabel IV.4 Deskripsi Use Case Cetak nomor antrian Use Case Name Cetak nomor antrian

Requirements

Pasien diminta untuk mencetak nomor antrian

Goal Pasien berhasil mencetak nomor antrian

Pre-conditions

Pasien berada pada halaman informasi nomor antrian

Post-Conditions Pasien berhasil mencetak nomor antrian Failed end conditions Pasien tidak mencetak nomor antrian

Actors Pasien

1. Pasien masuk pada halaman Login 2. Pasien pilih jenis poli

3. Poli berhasil tersimpan 4. Cetak nomor antrian Alternate Flow/ invariant A

User berhasil menyimpan data diri ke sistem

5. Pasien batal mencetak nomor antrian 6. Nomor antrian sudah penuh

Tabel IV.5 Deskripsi Use Case Melihat Informasi Use Case Name Melihat Informasi

Requirements Pasien melihat informasi website Goal Pasien dapat melihat informasi website Pre-conditions Pasien berada pada halaman utama website Post-Conditions Pasien dapat melihat informasi website Failed end conditions Pasien tidak melihat informasi website

Actors Pasien

1. Pasien berada pada halaman utama web 2. Pasien pilih menu tentang

Alternate Flow/ invariant A Pasien berhasil melihat informasi website Alternate Flow/ invariant B Sistem gagal diakses

Tabel IV.6 Deskripsi Use Case Kelola Data Pasien Use Case Name Kelola data pasien

Requirements Admin mengelola data pasien

(6)

Goal Admin dapat mengelola data pasien Pre-conditions

Admin berada pada halaman utama website

Post-Conditions Admin dapat mengelola data pasien Failed end conditions Admin tidak kelola data pasien

Actors Admin

1. Admin masuk pada halaman Login 2. Admin memasukan Username dan

Password

3. Admin masuk pada halaman utama website

4. Admin masuk pada menu data pasien Alternate Flow/ invariant A Admin berhasil mengelola data user

5. Admin gagal Login

6. Admin melakukan Login kembali 7. Admin melakukan kelola data pasien yang diinginkan

Tabel IV.7 Deskripsi Use Case Cari Data Pasien Use Case Name Cari data pasien

Requirements Admin mencari data pasien

Goal Admin dapat menemukan data pasien

yang diinginkan Pre-conditions

Admin berada pada halaman utama website

Post-Conditions Admin dapat menemukan data pasien Failed end conditions

Admin tidak dapat menemukan data pasien

Actors Admin

1. Admin masuk pada halaman Login 2. Admin memasukan Username dan

Password

3. Admin masuk pada halaman utama website

4. Admin masuk pada menu data pasien 5. Admin pilih cari data pasien

Alternate Flow/ invariant A Admin berhasil mengelola data pasien

6. Admin gagal Login

7. Admin melakukan Login kembali 8. Admin melakukan cari data pasien

yang diinginkan

(7)

Tabel IV.8 Deskripsi Use Case Edit Data Pasien Use Case Name Edit data pasien

Requirements Admin melakukan edit data pasien

Goal Admin berhasil mengedit data pasien ke

sistem

Pre-conditions Admin berada pada halaman data pasien Post-Conditions Admin berhasil mengedit data pasien Failed end conditions Admin gagal edit data pasien

Actors Admin

1. Admin masuk pada halaman Login 2. Admin masuk pada halaman data

pasien

3. Admin pilih data pasien 4. Admin edit data pasien

Alternate Flow/ invariant A Admin berhasil mengedit data pasien Alternate Flow/ invariant B

5. Admin gagal edit data pasien

6. Admin mengedit kembali data pasien

Tabel IV.9 Deskripsi Use Case Hapus Data Pasien

Use Case Name Hapus data pasien

Requirements Admin melakukan hapus data pasien

Goal Admin berhasil menghapus data pasien

Pre-conditions Admin berada pada halaman data pasien Post-Conditions Admin berhasil menghapus data pasien Failed end conditions Admin batal menghapus data pasien

Actors Admin

1. Admin masuk pada halaman Login 2. Admin masuk pada halaman data

pasien

3. Admin pilih data pasien 4. Admin hapus data pasien

Alternate Flow/ invariant A Admin berhasil menghapus data pasien

5. Admin gagal hapus data pasien 6. Admin menghapus kembali data

pasien yang diinginkan

4.1.3. Rancangan Diagram Aktivitas

Activity diagram menggambarkan aktivitas sistem bukan apa yang dilakukan oleh aktor, jadi aktivitas yang dapat dilakukan oleh sistem. Sebuah aktivitas dapat

(8)

direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Adapun Activity Diagram yang penulis rancang adalah sebagai berikut :

Gambar IV.2 Rancangan Activity Diagram Pendaftaran Online

(9)

4.1.4. Rancangan Dokumen Pengembangan Sistem

Berdasarkan hasil penelitian yang dilakukan penulis mendapatkan beberapa hal dalam merancang sistem usulan. Adapun dokumen yang terkait dalam usulan ini adalah sebagai berikut :

A. Bentuk Dokumen Masukan

Dokumen masukan adalah dokumen dalam suatu proses agar dapat menghasilkan keluaran yang sesuai dengan yang diinginkan. Adapun dokumen- dokumen masukan tersebut adalah :

1. Nama Dokumen : Form Pendaftaran Online

Fungsi : Sebagai persyaratan pendaftaran

Sumber : Pasien

Tujuan : Admin

Media : Komputer

Jumlah Rangkap : 1 File

Frekuensi : Setiap melakukan pendaftaran Bentuk : Lampiran C-01

B. Bentuk Dokumen Keluaran

Dokumen keluaran dihasilkan berdasarkan hasil pengolahan dari dokumen masukan. Adapun bentuk dokumen yang dihasilkan adalah sebagai berikut :

1. Nama Dokumen : Nomor Antrian pendaftaran online

Fungsi : Sebagai bukti Pasien telah melakukan pendaftaran

Sumber : Pasien

Tujuan : Admin

Media : Komputer

Jumlah Rangkap : 1 Lembar

(10)

Frekuensi : Setiap melakukan pendaftaran Bentuk : Lampiran D-01

2. Nama Dokumen : Formulir Rekam Medis

Fungsi : Sebagai bukti User telah melakukan pendaftaran

Sumber : Admin

Tujuan : User

Media : Kertas

3. Nama Dokumen : Laporan data pasien

Fungsi : Sebagai bukti Pasien telah melakukan pendaftaran

Sumber : Admin

Tujuan : Pimpinan

Media : Komputer

4.1.5. Rancangan Prototype

Berikut adalah contoh tampilan rancangan interface aplikasi sistem informasi pendaftaran online pada BKMM Cikampek.

(11)

1. Desain Menu Utama Pasien

Gambar IV.3 Rancangan interface menu utama website Penjelasan gambar :

Gambar IV.3 Menampilkan halaman utama bagi para pasien yang sedang mengunjungi website. Pada menu ini adalah halaman yang pertama muncul saat pasien mulai mengakses website, pasien juga bisa melihat seputar informasi mengenai website dan antrian SIPO saat ini.

2. Desain Form Login

Gambar IV.4 Rancangan interface form Login

(12)

Penjelasan gambar :

Gambar IV.4 Menampilkan halaman login bagi para pasien yang sudah memiliki akun.

Pada menu ini pasien diminta memasukan username dan password yang terdaftar.

3. Desain Form Daftar

Gambar IV.5 Rancangan interface form Daftar Penjelasan gambar :

Gambar IV.5 Menampilkan halaman form registrasi atau pendaftaran bagi para pasien yang belum memiliki akun dan ingin melakukan pendaftaran. Pada menu ini pasien diminta memasukan data diri, username dan password yang akan dibuat.

4. Desain Menu Bantuan

Gambar IV.6 Rancangan interface menu bantuan

(13)

Penjelasan gambar :

Gambar IV.6 Menampilkan menu bantuan dimana user bisa melihat informasi mengenai sistem tersebut. Selain informasi mengenai tata cara pendaftaran, pada halaman ini pula terdapat informasi mengenai BKMM Cikampek.

5. Desain Menu Informasi Antrian

Gambar IV.7 Rancangan interface halaman antrian saat ini Penjelasan gambar :

Gambar IV.7 Menampilkan halaman antrian saat ini, halaman ini adalah halaman setelah pasien melakukan login. Pada halaman ini juga pasien bisa melihat informasi antrian poli dan mencetak nomor antrian.

(14)

6. Desai Menu Ambil Antrian Poli

Gambar IV.8 Rancangan interface halaman ambil antrian poli Penjelasan gambar :

Gambar IV.8 Menampilkan halaman ambil antrian poli yang dituju pasien. Pada halaman ini juga pasien bisa melihat informasi poli apa saja yang terdapat di BKMM Cikampek.

7. Desain Form Login Admin

Gambar IV.9 Rancangan interface form login admin

(15)

Penjelasan gambar :

Gambar IV.9 Menampilkan halaman login bagi admin yang sudah memiliki akun.

Pada menu ini pasien diminta memasukan email dan password yang terdaftar.

8. Desain Menu Utama Admin

Gambar IV.10 Rancangan interface menu utama admin Penjelasan gambar :

Gambar IV.10 Menampilkan menu utama admin dimana pada menu ini pertama kali saat admin telah berhasil masuk pada halaman admin. Pada halaman ini juga admin dapat melihat informasi jumlah antrian poli saat ini.

(16)

9. Desain Menu Data Pasien

Gambar IV.11 Rancangan interface Menu Data Pasien Penjelasan gambar :

Gambar IV.11 Menampilkan menu data user dimana pada menu ini admin bisa mengelola data user yang telah terdaftar. Pada halaman ini juga admin admin dapat mengedit, mengahapus atau mencetak laporan data pasien.

10. Desain Menu Edit Pasien

Gambar IV.12 Rancangan interface menu edit pasien Penjelasan gambar :

(17)

Gambar IV.12 Menampilkan menu edit pasien dimana terdapat informasi mengenai pasien yang telah mendaftar. Pada halaman ini juga admin dapat mengedit data pasien apabila terdapat kesalahan saat penginputan oleh pasien.

11. Desain Menu Poli

Gambar IV.13 Rancangan interface menu poli Penjelasan gambar :

Gambar IV.13 Menampilkan menu poli, pada menu ini admin dapat mengubah jumlah maksimal pendaftaran poli.

12. Desain Menu Antrian Poli

Gambar IV.14 Rancangan interface menu antrian poli

(18)

Penjelasan gambar :

Gambar IV.14 Menampilkan menu antrian poli, pada menu ini admin dapat melihat jumlah antrian poli. Pada menu ini juga admin dapat mengecek antrian poli yang pasien tuju.

4.2. Perancangan Perangkat Lunak 4.2.1. Entity Relationship Diagram (ERD)

Entity Relationship Diagram (ERD) merupakan komponen-komponen Himpunan Entitas dan Himpunan Relasi yang masing-masing dilengkapi dengan atribut-atribut yang merepresentasikan seluruh fakta dari ‘dunia nyata’ yang kita tinjau, dapat digambarkan dengan lebih sistematis dengan menggunakan Entity Relationship Diagram (ERD). Adapun Entity Relationship Diagram (ERD) yang penulis rancang adalah sebagai berikut :

(19)

Gambar IV.15 Rancangan Entity Relationship Diagram (ERD) Pendaftaran Online

4.2.2. Logical Record Structure (LRS)

Logical Record Structured (LRS) adalah representasi dari struktur record-

record pada tabeltabel yang terbentuk dari hasil relasi antar himpunan entitas.

Menentukan kardinalitas, jumlah tabel, dan ForeignKey (FK). Adapun Logical Record Structure (LRS) yang penulis rancang adalah sebagai berikut :

(20)

Gambar IV.16 Rancangan Logical Record Structure (LRS) Pendaftaran Online

4.2.3. Spesifikasi File

Spesifikasi file ini terdiri dari file-file yang diperlukan dalam pembuatan sebuah program, biasanya berisi file, akronim, organisasi file, kunci field dan panjang record, dan software. Adapun spesifikasi file yang penulis gunakan dalam perancangan sistem ini adalah sebagai berikut:

(21)

1. Spesifikasi File Pasien

Nama File : Pasien

Akronim : Pasien

Fungsi : Untuk Menyimpan Data Pasien Tipe File : File Master

Organisasi File : Index Sequential Akses File : Random

Media : Harddisk

Panjang record : 566 byte Kunci Field : id_pasien

Software : MySQL

Tabel IV.10 Spesifikasi File Pasien

No. Nama Akronim Type Size Keterangan

1 Kode User id_pasien Integer 11 Primary

Key

2 Nomor

Identitas no_identitas Varchar 50

3 Nama Pasien nama Varchar 50

4 Jenis Kelamin jenis_kelamin Varchar 50

5 Tempat lahir tempat_lahir Varchar 50 6 Tanggal lahir tgl_lahir Date

7 Alamat alamat text

8 Telepon no_tlp Varchar 20

9 Kota kabupaten Varchar 50

10 Kecamatan kecamatan Varchar 50

11 Kelurahan desa Varchar 50

12 Rt Rt Varchar 5

(22)

13 Rw Rw Varchar 5 14 Nama Ayah

Kandung nama_ayah Varchar 50

15 Provinsi provinsi Varchar 10

16 Kode Pos Kode_Pos Varchar 10

17 Pekerjaan Pekerjaan Varchar 20

18 Status

Pernikahan Status_pernikahan Varchar 20

19 Username Username Varchar 50

20 Password Password Varchar 35

2. Spesifikasi File Admin

Nama File : Admin

Akronim : Admin

Fungsi : Untuk Menyimpan Data Admin Tipe File : File Master

Media : Harddisk

Panjang record : 215 byte Kunci Field : Id_admin

Software : MySQL

Tabel IV.11 Spesifikasi File Admin

1 Kode Admin id Integer 11 Primary

Key

2 Nama Admin nama_admin Varchar 50

(23)

3 Username email Varchar 50

4 Password password Varchar 50

5 Gambar gambar Varchar 50

6 Status status Int 4

3. Spesifikasi File Pendaftaran

Nama File : Pendaftaran Akronim : Pendaftaran

Fungsi : Untuk Menyimpan Data Pendaftaran Tipe File : File Transaksi

Media : Harddisk

Panjang record : 26 byte

Kunci Field : Id_pendaftaran

Software : MySQL

Tabel IV.12

Spesifikasi File Pendaftaran No

. Nama Akronim Type Size Keterangan

1 Nomor

Pendaftaran no_pendaftaran Integer 11 Primary Key

2 Kode User id_pasien Integer 11 Foreign

Key

3 Tanggal Pendaftaran

tanggal_pendaftara

n Datetime

20 Kode Admin id Integer 4 Foreign Key

(24)

4. Spesifikasi File RekamMedis

Nama File : Rekam Medis

Akronim : rekam_medis

Fungsi : Untuk Menyimpan Data RekamMedis Tipe File : File Master

Media : Harddisk

Panjang record : 33 byte Kunci Field : No_Rm

Software : MySQL

Tabel IV.13

Spesifikasi File RekamMedis

No Nama Akronim Type Size Keterangan

1 Kode Rekam Medis no_rm Integer 11 Primary Key

2 Kode User id_pasien Integer 11 Foreign

Key

3 Kode Diagnosa kd_diagnosa Integer 11 Foreign Key

5. Spesifikasi File Diagnosa

Nama File : Diagnosa

Akronim : Diagnosa

Fungsi : Untuk Menyimpan Data Diagnosa Tipe File : File Master

Organisasi File : Index Sequential

(25)

Akses File : Random

Media : Harddisk

Panjang record : 69 byte Kunci Field : kd_diagnosa

Tabel IV.14

Spesifikasi File Diagnosa

1 Kode Diagnosa kd_diagnosa Integer 11 Primary Key 2 Nama Diagnosa nama_diagnosa Varchar 50

3 Hasil Diagnosa

mata Kanan OD Varchar 4

4 Hasil Diagnosa

mata Kiri OS Varchar 4

6. Spesifikasi File Antrian_Poli

Nama File : Antrian_Poli Akronim : antrian_poli

Fungsi : Untuk Menyimpan Data antrian_poli Tipe File : File Master

Media : Harddisk

Panjang record : 27 byte

Kunci Field : id_antrian_poli

(26)

Tabel IV.15

Spesifikasi File Antrian_Poli

1 Id Antrian Poli id_antrian_poli Integer 4 Primary Key 2 Nomor Pendaftaran no_pendaftaran Integer 11

3 Id Poli id_poli Integer 2

4 Tanggal Antrian

Poli tgl_antrian_poli Date

5 Nomor Antrian Poli no_antrian_poli Varchar 10

7. Spesifikasi File Kategori_Poli

Nama File : Kategori_Poli Akronim : kategori_poli

Fungsi : Untuk Menyimpan Data kategori_poli Tipe File : File Master

Media : Harddisk

Panjang record : 110 byte Kunci Field : id_poli

Tabel IV.16

Spesifikasi File Kategori Poli

1 Id Poli id_poli Integer 2 Primary

Key

(27)

2 Kode Poli kode_poli Varchar 5

3 Nama Poli nama_poli Varchar 100

4 Jumlah Maksimal jumlah_maksimal Varchar 3

4.2.4. Class Model / Class Diagram

Class diagram memberikan gambaran hubungan antara tabel-tabel yang ada

dalam database. Masingmasing class memiliki atribut dan metode atau fungsi sesuai dengan proses yang terjadi. Adapun Class Diagram yang penulis rancang adalah sebagai berikut :

Gambar IV.17 Rancangan Class Diagram Pendaftaran Online

(28)

4.2.5. Sequence Diagram

Sequence diagram menjelaskan interaksi antar objek di dalam dan di sekitar

sistem berupa pesan (message) yang disusun dalam suatu urutan waktu yaitu urutan kejadian yang dilakukan oleh seorang aktor dalam menjalankan sistem. Diagram ini menunjukkan bagaimana detil operasi dilakukan, pesan apa yang dikirim dan kapan terjadinya.

Sequence diagram terdiri atas dimensi vertikal yaitu waktu dan dimensi

horizontal yaitu menggambarkan objek-objek yang terkait.Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai response dari sebuah kegiatan untuk menghasilkan output tertentu.

Adapun Sequence diagram yang penulis rancang adalah sebagai berikut :

Gambar IV.18 Rancangan Sequence Diagram Pendaftaran Online

(29)

Gambar IV.19 Rancangan Sequence Diagram Cetak Antrian Poli

4.2.6. Spesifikasi Hardware dan Software A. Spesifikasi Hardware

Adapun spesifikasi dari perangkat keras yang diperlukan dalam merancang sistem informasi registrasi online terdiri dari:

1. CPU (Central Processing Unit)

a. Processor : Intel® Pentium® Core 2 Duo

b. Memory : 2 GB

c. Harddisk : 500 GB

2. Monitor : Resolusi Layar Maksimum (1366 x 768)

3. Keyboard : 86 keys

4. Mouse : Optical

B. Spesifikasi Software

1. Sistem Operasi : Windows 8.

2. Web Server

a. Apache : Apache/2.4.29

b. PHP : PHP Version 7.2.2

c. PhpMyAdmin : PhpMyAdmin 4.7.7

(30)

3. Web Editor : Macromedia Dreamweaver 8 4. Web Browser

a. Microsoft Edge : Microsoft Edge Version 81.0.416.62 b. Google Chrome : Google Chrome Versi 83.0.4103.116 4.3. Jadwal Implementasi

Jadwal implementasi sistem merupakan suatu rencana penerapan sistem, dalam usaha untuk membangun sistem diperlukan tahapan-tahapan baik agar sistem yang dirancang dapat berjalan dengan lancer. Pengimplementasian dari sistem ini dibutuhkan waktu sekitar 3 bulan. Adapun rincian kegiatannya yaitu:

Tabel IV.17 Jadwal Implementasi

No Tahapan Kegiatan

Waktu Kegiatan Per minggu

April Mei Juni

1 2 3 4 1 2 3 4 1 2 3 4 1. Penelitian

2. Analisa

3. Pengumpulan Data 4. Penulisan Judul & Bab I 5. Penulisan Bab II 6. Penulisan Bab III 7. Penulisan Bab IV 8. Penulisan Bab V 9. Evalusai Rancangan Sistem