1

1.Evaluasi Sistem Yang Berjalan

perancangan program yang berhubunga denga objek penelitian untuk memperoleh data
pelanggaran lalulintas yang meliputi pembutan slip surat tilang.
dalam hal ini ada bagian-bagian yang terlibat dalam pembuatan tersebut dan masihbanyak
kelemahan-kelemahan dalam sistem yang sedang berjalan ini.
evaluasi terhadap kelemahan-kelemahan sistem penilangan polisi lalulintas yang berjalan
terlihat pada table di bahas ini.
Table :1.1 evaluasi sistem yang berjalan
NO

PERMASALAHAN

WORKET

SOLUSI

Tidak ada tersedia alat

admin

Harus menggunakan

sistem pengambilan

sistem yang berteknologi

tagihan pembayaran

agar melakukan proses

listrik

penagihan listrik berjalan

lancar.

Warga masih di

warga

Harus mempunyai media

datangi aleh amin satu-

penyimpanan data base

satu kerumah, untuk

berteknologi agar

penagihan uang listrik

penagihan bias berjalan

dengan mudah

2.Perancangan Sistem

Perancangan sistem merupakan tahap selanjutnya setelah analisa sistem, mendapatkan

gambaran dengan jelas tentang apa yang dikerjakan pada analisa sistem, maka dilanjutkan
dengan memikirkan bagaimana membentuk sistem tersebut.
Perancangan sistem adalah suatu fase dimana diperlukan suatu keahlian perancangan
untuk elemen-elemen yang akan mengunakan sistem yaitu pemilihan peralatan dan program
untuk sistem yang baru.
3.tujuan peranjangan sistem
Adapun tujuan yang hendak dicapai dari tahap perancangan system mempunyai maksud atau
tujuan utama, yaitu sebagai berikut:
1. Untuk memenuhi kebutuhan pemakaian sistem (user)
2. Untuk memberikan gambaran yang jelas dan menghasilkan rancangan yang bagus dan
lengkap kepada pemograman dan ahli-ahli teknik lainnya yang terlibat dalam
pengembangan atau pembuatan sistem.

4. Gambatan Umum Prangakat lunak

Aplikasi ini sendiri dirancang dan dibuat berdasarkan kebutuhan dan keluhan-keluhan
yang dialami oleh pelanggan dan pengalaman dari penulis sendiri ketika melakukan pemesanan
air isi ulang. sistem pemesanan yang ada saat ini dirasa masih belum mampu menjawab
keinginan dari kebutuhan pelanggan/konsumen dalam mendapatkan pelayanan yang maksimal,
cepat dan efesien.
Adapun pengguna dari sistem ini terbagi atas tiga bagian yaitu, Admin (petugas pengadilan),
petugas polisi dan pelanggar Sedangkan perancangannya adalah menggunakan UML sebagai
deskripsi dari sistem yang akan dibangun

admin

User/warga

Gambar 4. Pengguna Sistem

5. Modul Perangkat Lunak

Modularitas adalah sebuah teori pemecahan suatu sistem menjadi sub sistem (break down)
menjadi yang lebih kecil, yang biasa dikenal dengan modul. Untuk memudahkan dalam
pengelolaan aplikasi ini, maka kelas-kelas akan dipecah kedalam empat modul tersendiri, yaitu:
Tabel 4.10 Modul Perangkat Lunak
No

Modul

InManagement

Keterangan
Modul

antaramuka

utama

yang

mengontrol pemanggilan proses-proses

pada sub modul-modulnya
2

penginputan

Modul penginputan ,berguna untuk

memasukan data warga

Management

Modul Management meliputi: kelola

user. dan setting profil),

Report

6. Fitur Utama Perangkat Lunak

Mencetak laporan transaksi pemesanan.

Perangkat lunak yang dibangun memiliki beberapa fitur-fitur pada umumnya yang
berfungsi untuk memanipulasi keberadaan data di dalam database. Berikut ini penjelasan
fitur-fitur yang terdapat dalam setiap modul:
Tabel 4.11 Fitur Utama Perangkat Lunak
No
1

penginputan

Data Pelanggan : input, delete, update

Data denda : input, delete, update
Aduan/klaim : input, delete, update
Data petugas polisi : input, delete,
update

Management

Kelola User : input, delete, update

Manage pembayarana : input, delete,
update
Respon aduan/klaim : input, delete,
update

Report

Melihat dan Mencetak Laporan

transaksi pemesanan.

7. Kebutuhan Perangkat Lunak

Deskripsi kebutuhan dari perangkat lunak menjelaskan mengenai kebutuhan-kebutuhan baik
Kebutuhan Antarmuka Eksternal, Fungsional maupun Non-Fungsional. Berikut ini kebutuhan
perangkat lunak yang akan dibangun:
4.2.3.1 Kebutuhan Antarmuka Eksternal
1. Sebagai penunjang antarmuka pemakai dari perangkat lunak, diperlukan spesifikasi
perangkat sebagai berikut :
a)
Sistem Operasi Android 4.1.2 (Jelly Bean) Mobile Device sebagai client.
b)
Eclipse untuk desain dan penulisan kode program Android.
A. Kebutuhan Antar Muka Komunikasi

2. Untuk komunikasi antara server dan client akan menggunakan jaringan Wireless atau
berlangganan paket internet ke penyedia jasa internet seperti : Telkomsel, XL, Three,
dan lain-lain.

B. Aplikasi Server
3. Dibutuhkan server untuk memusatkan proses dari perangkat lunak, yaitu database
server. Kebutuhan database server pada aplikasi ini dapat menggunakan MySQL.
Aplikasi server ini akan mengatur request ke server dan juga respon terhadap request
dari server ke client.

8. Kebutuhan Fungsional
Merupakan kebutuhan secara fungsional yang harus dipenuhi oleh perangkat lunak yang
akan dibangun. Kebutuhan fungsional tersebut akan dideskripsikan dalam bentuk tabel, sebagai
berikut:

Tabel 8. Deskripsi Kebutuhan Fungsional

Kode

Nama

Deskripsi

Kebutuhan
KB-F-001

Login

Untuk mengakses kedalam sistem

KB-F-002

Input data

Memasukan data-data kedalam

database

KB-F-003

Update data

Memperbaharui data sebelumnya yang

KB-F-004

Hapus data

Menghapus data dari database sistem

KB-F-005

Aduan/Klaim

warga dapat mengadukan /

laporkan hal-hal yang terjadi ketika
melakukan transaksi.

KB-F-006

Laporan

mencetak laporan transaksi

9. Kebutuhan Non-Fungsional
Kebutuhan non-fungsional mencakup fungsi-fungsi yang membantu sistem untuk
berjalan dengan baik serta dapat digunakan dengan mudah.
Tabel 9 Deskripsi Kebutuhan Non-Fungsional

Kode

Nama Kebutuhan

NON-F-001

User Friedly

NON-F-002

Confirm Alert

Deskripsi
Sistem Mudah untuk digunakan
Pesan peringatan untuk setiap
pengiriman data sensitif yang
memerlukan persetujuan dari user.

NON-F-003

Responsif

Kegiatan pemesanan dilakukan

secara cepat dan akurat

NON-F-004

Data Validation

Mengecek data yang di input, sesuiai

atau tidak sesuai ketentuan.

NON-F-005

Security

Sistem menggunakan metode

enkrips dan deskrips dalam
pengiriman dan penerimaan data.

NON-F-006

Realtime

Admin selalu dalam keadaan online

10. Kandidat Kelas

Pendefinisian kandidat kelas digunakan untuk menjelaskan objek-objek dalam
sistem. Dimana kelas-kelas mendefinisikan model data dan esensi sistem.
Tabel 10 Kandidat Kelas
N

Identifikas

i Objek

Nama Objek

Ditolak /
Diterima

Alasan

(*)
1

Objek Fisik

Input data

Input data
Detail_pelanggar,
Data_pelanggar
Detail_pelanggar,
Aduan/Klaim
Detail_Aduan

2
2
2
2
2
2

Dalam Sistem
Dalam Sistem
Dalam Sistem
Dalam Sistem
Dalam Sistem
Dalam Sistem

warga

Manajemen

Kelola User
Detail_User,
Manage Saldo
Detail_saldo,
Respon Aduan
Detail_aduan

2
2
2
2
2
2

Dalam Sistem
Dalam Sistem
Dalam Sistem
Dalam Sistem
Dalam Sistem
Dalam Sistem

Report

Cetak_laporan
Detail_laporan

2
2

Dalam Sistem
Dalam Sistem

Peranan

Admin
Petugas

2
2

Pengontrol
Pengguna

pelanggar

Sistem
Pengguna
Sistem

11. Use Case Diagram

Actor dan use case ditentukan atas dasar fungsi-fungsi dalam sistem. Selanjutnya

use case menyediakan nilai hasil kepada actor. Atas dasar analisis kandidat kelas diatas
setidaknya ada tiga (3) actor yang berhubungan dengan sistem yaitu pengadilan(admin),
polisi(petugas) dan pelanggar(User).

12. Use Case Diagram Usulan

Use Case Diagram menggambarkan fungsionalitas dari sebuah sistem (apa
fungsinya), yang merepresentasikan sebuah interaksi antara actor dengan sistem (sebuah
pekerjaan), misalnya menambah data atau membuat laporan. Elemen- elemennya adalah:
actor, use case, dan hubungan antar objek.
1. Actor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan
sistem untuk melakukan pekerjaan-pekerjaan tertentu.
2. Use case adalah sebuah tidakan atau unit fungsional dari sebuah sistem.
Sebuah use case dapat meng-include fungsionalitas use case lain. Sebuah use case
dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat
dihindari dengan cara menarik keluar fungsionalitas yang umum. Sebuah use case juga
dapat meng-extend use case lain dengan behavior- nya sendiri.
Tabel 12 Definisi Aktor
No
1

Aktor

Deskripsi

Admin

Merupakan Admin yang memiliki kewenangan

penuh atas seluruh akses terhadap sistem

warga(User)

Aktor yang berkewajiban pembayaran listrik

Berikut ini adalah gambar dari model Use Case Diagram Inventory Multi
Warehouse yang penulis usulkan, yang digambarkan secara umum sebagai beriku
login
inclut
inclut

Input
data
Update
data
aduan

admi
n
inclut

inclut

Hapus
data
laporan

inclut
warga

Gambar 12 Use Case Diagram Yang Diusulkan

Sementara itu, berikut adalah tabel yang mendeskripsikan use case usulan.
Tabel 12 Daftar Deskripsi Use Case Usulan

Kode Use

Nama Use

Case

Case

Deskripsi

USE-001

Login

Untuk mengakses kedalam sistem

USE-002

Input data

Memasukan data pelanggar dan denda

USE-003

Update data

Memperbaharui

data

sebelumnya

yang

sudah tersimpan didatabase

USE -004

Hapus data

Menghapus data dari database sistem

USE -005

Aduan/Klaim Warga dapat mengadukan /laporkan hal-hal

yang terjadi ketika melakukan transaksi.

USE -006

Laporan

mencetak laporan transaksi

13. Dokumentasi Skenario Use Case

Setiap use case di atas harus dideskripsikan dalam dokumen yang disebut dengan
dokumen flow of event. Dokumen ini merupakan definisi apa yang harus dilakukan oleh sistem
ketika actor mengaktifkan use case. Berikut ini adalah dokumentasi use case untuk Use Case
Diagram Inventory Multi Warehouse yang diusulkan oleh penulis

Tabel 13.1Skenario Use Case Login

10

Use Case

Login

Brief description

Use Case ini memungkinkan semua user yang

terdaftar bisa melakukan akses kedalam sistem.

Aktor
Precondition
Main flow

User ( Admin, warga,)

User membuka aplikasi
Aktor

Sistem

1. User menginput
username &
Password
2. Verifikasi username &
password didalam
database
3. Memberikan Informasi
login valid atau tidak,
jika ya maka otomatis
mengakses halaman
yang diminta sesuai
dengan hak akses
masing-masing setiap
user, jika tidak akan
keluar pesan gagal
login.

Postcondition

User bisa masuk mengakses aplikasi

Tabel 13.2Skenario Use Case Input Data

11

Use Case

Input Data

Brief description

Use Case ini memungkinkan admin dan petugas

penginputan data kedalam database.

Aktor

Admin

Precondition

Menu Login

Main flow

Aktor

Sistem

1. Admin dan petugas

login

2. Cek login valid atau

tidak
3. Menampilkan menu
utama
4. Cari data yang mau
proses
5. Verifikasi data input
sukses
Postcondition

Database terupdate dengan penambahan data baru

Tabel 13.3 Skenario Use Case Update Data

Use Case

Update data

Brief description

Use Case ini memungkinkan user melakukan

pengubahan data yang telah tersimpan sebelumnya.

Aktor

Admin

Precondition

Menu Login

12

Main flow

Aktor

Sistem

1. Admin Login
2. Cek Login
3. Menampilkan Menu
Utama
4. Cari data untuk di
update

5. Komparasi dan Cek

kesesuaian data
Postcondition

Data dalam database berubah atau terupdate dengan

yang baru

Tabel 13.4 Skenario Use Case Hapus Data

Use Case

Hapus data

Brief description

Use Case ini memungkinkan user melakukan

penghapusan data.

Aktor

Admin

Precondition

Menu Login

Main flow

Aktor

Sistem

1. Admin Login
2. Cek Login
3. Menampilkan Menu
Utama
4. Cari data untuk di
hapus

13

5. Cek keberadaan data

6. Verifikasi penghapusan

Postcondition

Data terhapus dari database.

Tabel 13.5 Skenario Use Case Aduan/Klaim

Use Case

Aduna/Klaim

Brief description

Use Case ini memungkinkan pelanggar melakukan

Aduan/Klaim kepada admin .apabila terjadi
kesalahan dalam denda yang di trima.

Aktor

User ( warga, Admin )

Precondition

Menu Login

Main flow

Aktor

Sistem

1. User Login
2. Cek Login
3. Menampilkan Menu
Utama
4. Memilih menu
Aduan/Klaim

14

5. Menginput data
keluhan, aduan,
kritik dan saran pada
kolom yang
disediakan

6. Data terkirim dan

tersimpan kedatabase.
Postcondition

Data terkirim ke admin untuk di cek kembali.

Tabel 13.6 Skenario Use Case Laporan

Use Case

loparan

Brief description

Use Case ini memungkinkan untuk melihat dan

mencetak laporan penilangan lalulintas

Aktor

Admin

Precondition

Menu Login

Main flow

Aktor

Sistem

1. User Login
2. Cek Login
3. Menampilkan Menu
Utama
4. Memilih menu
Laporan
5. Pilih aksi untuk
laporan

15

6. Keluar

Postcondition

Menampilkan Laporan

14. Activity Diagram

Activity diagram digunakan untuk menggambarkan kegiatan-kegiatan yang
ada di dalam sistem. Agar lebih memahami sistem yang akan dibuat, maka perlu
dibuatkan activity diagram tentang sistem, yaitu seperti yang ada di bawah ini:
Dua (2) Diagram berikut merupakan diagram aktivitas yang menjelaskan
kegiatan Login terhadap sistem dalam beberapa tingkatan hak akses, dapat terlihat
dari sistem login yang dilakukan setiap bagian memiliki modul masing-masing
untuk dijalankan. Sementara Gambar 4.16 adalah penjelasan detail dari kegiatan
Login kedalam sistem yang dilakukan oleh masing-masing admin.

16

Gambar 14.1 Activity Diagram Login

Diagram aktivitas berikut ini adalah penjelasan mengenai kegiatan pemasukan

data ke dalam sistem dan database.
Gambar 14.2 Activity Diagram Input Data

Gambar dibawah ini merupakan diagram aktivitas yang menjelaskan mengenai

kegiatan menghapus data dari dalam system
Gambar 14.3 Activity Diagram Hapus/delete

17

Diagram dibawah ini adalah diagram aktivitas yang menjelaskan kegiatan dalam pengupdatean daa
Gambar 10.4 Activity Diagram Update

Diagram dibawah ini adalah pemaparan dari fitur Aduan/Klaim yang diusulkan
oleh penulis.
Gambar 14.5 Activity Diagram Aduan/Klaim

18

Gambar dibawah ini merupakan langkah-langkah kegiatan dalam diagram

aktivitas membuat Laporan.
Gambar 14.9 Activity Diagram Laporan

15.

Sequence Diagram

sequence diagram adalah interaction diagram yang memperlihatkan event-event yang

berurutan sepanjang berjalannya waktu. Masing-masing sequence diagram akan menggambarkan
aliran-aliran pada suatu use case.
Berikut ini adalah penggambaran diagram sequence untuk proses login.
Gambar 15.1 Sequence Diagram Login

19

Diagram di bawah ini merupakan diagram sequence untuk proses penginputan

data kedalam sistem.

Gambar 15.2 Sequence Diagram Input Data

20

Diagram untuk proses update data, dapat dilihat seperti pada gambar
dibawah ini.
Gambar 15.3 Sequence Diagram Update Data

Diagram di bawah ini merupakan diagram sequence untuk proses pengapusan

21

data kedalam sistem.

Gambar 15.4 Sequence Diagram delate data

Diagram di bawah ini merupakan diagram sequence untuk proses aduan untuk
pelangar di dalam sistem.
Gambar 15.5 Sequence Diagram aduan

22

Diagram di bawah ini merupakan diagram sequence untuk menampilkan dan

mencetak laporan.
Gambar 15.6 Sequence Diagram laporan

16. Package Diagram

Package adalah sebuah pengelompokan yang menmungkinkan untuk mengambil

setiap bentuk UML dan pengelompokan eleman-eleman dalam tingkat unit yang lebih
tinggi .kegunaan untuk mengelompokan class.

PEMBAYA
RAN

23

17. Class Diagram

Modularitasi adalah sebuah teori pemecahan suatu system menjadi sub system
(brek down) menjadi yang lebih kecil,yang bias di kenal dengan modul,untuk
memudahkan dalam pengelolaan aplikasiinin ,maka kelas-kelas di pecah kedalam empat
modul tersendiri .yaitu:
Class Diagram di bawah ini merupakan class diagram pembayarn
Gambar 17.1 class Diagram pembayaran

Activity pembayaran
-id_user
-menu
-info_ditel
-gambar
-----------------------+tambah()
+hapus()
+edit()
tampil()

pelanggar

PEMBAYARANen

-id_pelanggar
-hakakses
-------------------+simpan()

Detail kesalahan
Aduan/klea
-username
-pass
-hakakses
------------------+input()
+simpan()
+update()
+delete()

-id_pelanggar
-tgl_tilang
-keterangan
-setatus
----------------------+hapus()
+edit()
+simpan()

24

Class Diagram di bawah ini merupakan class diagram managemen.

Gambar 17.2 class Diagram manageman
Kelola user
-id_user
-setatus_user
-gambar
-deskripsi
----------------------------+tampil()

aduan

manajemen

-id_pelanggar
-balasan_aduan
-status
------------------------+tampil()
+simpan()
+input()
+tambah()

Detail user

Detail denda
-saldo_user
-nama_pelanggar
------------------------+tampil()
+simpan()

-id_pelanggar
-nama
-pass
-hakakses
------------------------+input()
+simpan()
+update()
+delete()

Detail aduan
-id_pelanggar
-tgl_masuk
-id_pelanggar
-status
-hakakses
-keterangan
------------------------+display()
+simpan()
+tambah()
+input()

25

Class Diagram di bawah ini merupakan class diagram laporan.

Gambar 17.3 class Diagram laporan

Laporan pelanggar

laporan

-id _laporan
-id_pelnggar
-detail_info
-nama_pelanggar
-denda
-status
-keterangan
--------------------------------+display()
+tambah()
+update()
+cetak()
+simpan()

18. perancangan input

Perancangan input berlaku untuk menentukan tamppilan program yang berfungsi
sebagai berikut
From berikut ini untuk menampikan id dan password ketika kita login.
Tagihan listrik
username

login

password

cencel

Gambar 18.1 from login

From berikut ini untuk menampikan input data

26

Input data

Nama pelanggat
Alamt ruma

Gambar 18.2 input data

From berikut ini untuk menampikan input aduan/kleam

Aduan
teks

batal
kirim

Gambar 18.3 input data

18. perancangan Output

27

Perancangan output di tentukan untuk menampilkan tampilan program yang

berfungsi sebagai tempat tampilan informasi data yang telah di-input-kan.
Time masuk

Nama

2017-2011
jam :

OTO

Denda
RP .
200.000

Status

Pesan

Time keluar

bayar
2017-28OTOTOTOTOTOTOTOT
11
jam :

2017-2011
jam :

OTO

RP .
200.000

bayar

2017-28OTOTOTOTOTOTOTOT
11
jam :

2017-2011
jam :

OTO

RP .
200.000

bayar

2017-28OTOTOTOTOTOTOTOT
11
jam :

2017-2011
jam :

OTO

RP .
200.000

bayar

2017-2811
OTOTOTOTOTOTOTOT
jam :

2017-2011
jam :

OTO

RP .
200.000

bayar

2017-2811
OTOTOTOTOTOTOTOT
jam :

PRINT

Gambar 18.3 cetak laporan