Skripsi 4.0

PENGEMBANGAN SISTEM APLIKASI MANAJEMEN
Commented [F1]: layout

DISTRIBUSI PUPUK PT. PETROKIMIA GRESIK BERBASIS WEB
SKRIPSI
Untuk memenuhi sebagian persyaratan

memperoleh gelar Sarjana Komputer
Disusun oleh:
Moh. Wahyu Dwi Ridiansyah
NIM: 155150200111232
PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNIK INFORMATIKA
FAKULTAS ILMU KOMPUTER
UNIVERSITAS BRAWIJAYA
MALANG
2018
KATA PENGANTAR
Assalamu’alaikum Warrahmatullahi Wabarakatuh. Alhamdulillahi

Rabbil’Alamin. Puji Syukur penulis panjatkan kehadirat Allah SWT, karena atas
berkah, rahmat, serta hidayah-Nya penulis dapat menyelesaikan Skripsi yang
berjudul “Pengembangan Sistem Aplikasi Manajemen Distribusi Pupuk PT
Petrokimia Gresik Berbasis Web” dengan baik.
Pada kesempatan ini, penulis menyampaikan rasa terima kasih kepada
pihak- pihak yang telah membantu penulis selama proses penyusunan skripsi,
diantaranya adalah:
1. Allah SWT yang telah memberi kemudahan dalam semua proses
penulisan skripsi ini.
2. Kepada Ibu saya yang selalu mendukung saya serta tidak henti-
hetinnya memberikan doa kepada saya.
3. Bapak Fajar Pradana, S.ST, M.Eng selaku dosen pembimbing I, yang
telah meluangkan waktu untuk memberikan ilmu serta saran dalam
proses penyusunan skripsi ini.
4. Bapak Nurudin Santoso, S.T., M.T selaku dosen pembimbing II, yang
juga telah meluangkan waktu untuk memberikan ilmu serta saran
dalam proses penyusunan skripsi ini.
5. Mas Yafi Anshori selaku Pengawai Departemen Teknologi Informasi
PT. Petrokimia Gresik yang telah mendukung serta memberikan ilmu
yang berharga dalam proses penyusunan skripsi ini.
6. Mas Edwyk Sony Edaieby dan Mas Rachmad Edy Rafianto selaku
Pegawai Departemen Distribusi Wilayah 1 PT. Petrokimia Gresik yang
telah mendukung serta memberikan ilmunya dalam proses
penyusunan skripsi ini.
7. Saudara Nugroho Samiyono yang telah memberikan ilmunya dalam
proses penyusunan skripsi ini.
8. Saudari Nurud Diana Syafa’ati yang selalu mendukung dan
mendoakan saya dalam proses penyusunan skripsi ini. Commented [F2]: layout
9. Seluruh teman-teman Fakultas Ilmu Komputer yang telah
memberikan bantuan serta ilmu yang berharga, dan seluruh
dukungannya selama proses penyusunan skripsi ini.
10. Seluruh pihak yang tidak dapat disebutkan satu per satu dan telah
membantu selama proses penyusunan skripsi ini.
Semoga seluruh jasa dan bantuannya mendapatkan balasan dari Allah SWT.
Penulis menyadari dalam penyusunan skripsi ini masih banyak ditemukan
kekurangan, semoga skripsi ini dapat bermanfaat baik untuk pembaca dan
pengembangan penelitian selanjutnya. Oleh karena itu, segala bentuk saran dan
kritikan yang bersifat membangun skripsi ini dapat disampaikan melalui email
penulis.
ii
Malang, 13 September 2018
Penulis
wahyuridiansyah@gmail.com
iii
BAB 1 PENDAHULUAN
1.1 Latar belakang

Sistem distribusi PT. Petrokimia Gresik menggunakan gudang penyangga pada
setiap kabupaten (Gunawan dkk, 2014). Gudang penyangga ini berfungsi untuk
menjadi tempat penyimpanan pupuk yang dikirim dari Gudang Pusat di Gresik agar
memudahkan dalam proses distribusi disetiap daerah di Indonesia. Dalam satu
kabupaten atau daerah bisa terdiri dari satu atau lebih Gudang penyangga
tergantung pada banyaknya kebutuhan pupuk di daerah tersebut dan daya
tampung Gudang penyangga. Pengawasan stok di gudang penyangga dilakukan
oleh Departemen Distribusi. Untuk wilayah Jawa Timur pegawasan dilakukan oleh
Departemen Distribusi Wilayah 1. Dalam menyelenggarakan fungsinya,
Departemen Distribusi Wilayah 1 mempunyai data berupa pendistribusian stok
dan memantau informasi stok pada setiap gudang penyangga.
Setiap gudang penyangga memiliki data pergudangan yang berbeda sehingga
pengelolaan data pergudangan membutuhkan suatu cara tertentu yang digunakan
untuk semua gudang sehingga mendapatkan data yang lebih informatif. Selama
ini pemantauan data setiap gudang penyangga menggunakan file excel yang
merupakan hasil pengolahan dari file document yang dikirimkan oleh kepala
Gudang penyangga. Staff Departemen Distribusi Wilayah 1 yang mengolah data
pelaporan dari Gudang penyangga mengalami kendala karena banyaknya data
yang dikirim melalui email sehingga sering terjadi data yang terlewat dan tidak
terolah. Keluhan tidak hanya dirasakan oleh Staff Distribusi Wilayah 1, Manager
juga mengeluh kesulitan memantau keadaan stok di Gudang-gudang penyangga
secara cepat dan efisien karena harus mengecek melalui data table excel ditengah
banyaknya kegiatan. Hal ini berdampak lamanya tidak lanjut dari Departemen
Distribusi Wilayah 1 apabila terjadi kekurangan stok pupuk didaerah sehingga
dapat mempengaruhi hasil pertanian (Rafianto dan Udaieby, 2018).
Stock opname adalah kegiatan penghitungan stok fisik yang ada di gudang.
Tujuan dilakukannya stock opname ini adalah untuk mengetahui keakuratan
antara stok yang tercatat dengan stok fisik yang ada. Jika terjadi selisih antara
stock opname dengan stok yang tercatat, maka kemungkinan ada transaksi yang
belum dicatat atau terjadi kecurangan dalam persediaan. Secara periodik
Departemen Distribusi Wilayah 1 melakukan stok opname disetiap Gudang
Penyangga dan proses masih menggunakan hardcopy dalam penghitungan
maupun hasil stok opname sehingga meningkatkan resiko kehilangan data, hal ini
diperkuat oleh Rafianto dan Udaieby (2018) yang mengungkapkan bahwa
beberapa kali terjadi kehilangan data pada saat stok opname menyebabkan harus
dilakukannya hitung ulang sehingga biaya perjalanan membengkak.
Berdasarkan permasalahan tersebut, maka diperlukan sebuah sistem untuk
memudahkan pihak Departemen Distribusi Wilayah 1 dalam menyelenggarakan
fungsinya yang diberi judul “Pengembangan Sistem Aplikasi Manajemen Distribusi
Pupuk PT. Petrokimia Gresik Berbasis Web”. Sistem ini dapat membantu
1
memantau proses pendistribusian pupuk dari Gudang pusat ke Gudang
penyangga, menyediakan peta sebagai visualisasi kondisi pupuk di daerah-daerah,
dan menjadi media distribusi data hasil stok opname.
1.2 Rumusan masalah

Berdasarkan latar belakang yang sudah disebutkan sebelumnya, berikut adalah
hasil dari rumusan masalah yang akan dibahas:
1. Bagaimana hasil analisis kebutuhan Sistem Aplikasi Manajemen Distribusi
Pupuk PT. Petrokimia Gresik yang sesuai dengan kebutuhan pengguna?
2. Bagaimana hasil perancangan Sistem Aplikasi Manajemen Distribusi Pupuk PT.
Petrokimia Gresik yang sesuai dengan hasil analisis kebutuhan?
3. Bagaimana hasil implementasi Sistem Aplikasi Manajemen Distribusi Pupuk PT.
Petrokimia Gresik yang sesuai dengan hasil perancangan sistem?
4. Bagaimana hasil pengujian dari Sistem Aplikasi Manajemen Distribusi Pupuk
PT. Petrokimia Gresik yang telah dibangun?
1.3 Tujuan
Berikut merupakan tujuan utama dari penelitian ini:
1. Menganalisis dan menyusun kebutuhan Sistem Aplikasi Manajemen
Distribusi Pupuk PT. Petrokimia Gresik sesuai dengan kebutuhan
pengguna.
2. Merancang Sistem Aplikasi Manajemen Distribusi Pupuk PT. Petrokimia
Gresik sesuai dengan hasil dari analisis kebutuhan yang diperoleh.
3. Mengimplementasikan hasil perancangan dari Sistem Aplikasi Manajemen
Distribusi Pupuk PT. Petrokimia Gresik.
4. Melakukan pengujian terhadap Sistem Aplikasi Manajemen Distribusi
Pupuk PT. Petrokimia Gresik yang dibangun. Commented [r3]: belum diperbaiki
1.4 Manfaat
Dalam membangun Sistem Aplikasi Manajemen Distribusi Pupuk PT.
Petrokimia Gresik ini, diharapkan penulis berharap penelitian ini dapat
bermanfaat bagi PT. Petrokimia Gresik terutama bagi Departemen Distribusi
Wilayah 1. Karena diharapkan dapat memudahkan PT. Petrokimia Gresik dalam
melakukan akses informasi distribusi. Tidak hanya memudahkan dalam melakukan
akses informasi distribusi, namun juga akan memudahkan pemetaan distribusi
karena menggunakan webgis.
1.5 Batasan masalah

Adapun batasan masalah dari penelitian ini sehingga mencegah terjadinya
penyimpangan dari tujuan yang sudah direncanakan :
1. Sistem hanya diterapkan di PT. Petrokimia Gresik.

2. Sistem hanya akan diterapkan di wilayah Jawa Timur.
2
3. Sistem akan dibangun dengan menggunakan platform web.
4. Sistem menggunakan database MySQL.
5. Sistem ini membutuhkan koneksi internet untuk dapat menerima dan
mengirim data ke server.
6. Sistem akan dapat diakses hanya dengan menggunakan browser yang
mendukung.
1.6 Sistematika pembahasan

Sistematika pembahasan yang akan digunakan dalam penulisan penelitian ini
adalah:
BAB I PENDAHULUAN
Bab ini berisi Latar Belakang Masalah, Rumusan Masalah, Tujuan
Penelitian, Manfaat Penelitian yang diharapkan, dan Sistematika
Penulisan.
BAB II TINJAUAN PUSTAKA
Bab ini membahas tentang metode-metode dan teori yang digunakan
untuk mendasari penelitian ini.
BAB III METODOLOGI PENELITIAN
Bab ini berisi metode penilitan yang menjelaskan metode dan langkah proses
yang digunakan dalam Pengembangan Sistem Aplikasi Manajemen Distribusi
Pupuk PT. Petrokimia Gresik.
BAB IV ANALISIS KEBUTUHAN
Bab ini membahas analisis kebutuhan yang dibutuhkan dan proses
perancangan solusi yang dilakukan dalam Pengembangan Sistem Aplikasi
Manajemen Distribusi Pupuk PT. Petrokimia Gresik.
BAB V PERANCANGAN SISTEM
Bab ini membahas tentang perancangan perangkat lunak yang akan dilakukan
berdasarkan analisis kebutuhan yang telah diperoleh dari bab sebelumnya.
Perancangan sistem yang digunakan adalah pemodelan sequence diagram,
pemodelan class diagram, dan perancangan basis data.
BAB VI IMPLEMENTASI
Bab ini berisi implementasi dari Sistem Aplikasi Manajemen Distribusi Pupuk
PT. Petrokimia Gresik berdasarkan perancangan sistem yang telah dibuat.
BAB VII PENGUJIAN
Bab ini membahas tentang teknik pengujian yang dilakukan dan analisis hasil
pengujian terhadap sistem.
3
BAB VIII KESIMPULAN DAN SARAN
Bab ini berisi kesimpulan yang diperoleh dari hasil perancangan sistem ini dan
memuat saran-saran dari penulis terhadap penelitian selanjutnya.
4
BAB 2 LANDASAN KEPUSTAKAAN
Pada bab landasan kepustakaan, akan dibahas kajian pustaka dan dasar- dasar
teori yang digunakan penulis sebagai penunjang dalam menyusun penelitian ini.
Kajian pustaka yang dibahas pada penelitian ini digunakan sebagai pembanding
dari penelitian-penelitian terdahulu yang berkaitan dengan Sistem Aplikasi
Manajemen Distribusi dan sebagai penunjang dalam penyusunan penelitian ini.
2.1 Kajian Pustaka

Kajian pustaka dilakukan guna sebagai referensi dalam penyusunan penelitian
ini. Kajian pustaka yang digunakan sebagai referensi adalah beberapa penelitian
terkait dengan Sistem Aplikasi Manajemen Distribusi. Ditemukan beberapa
penelitian-penelitian mengenai Sistem Aplikasi Manajemen Distribusi tetapi dari
seluruh penelitian yang ada, hanya dua penelitian yang akan digunakan sebagai
referensi. Dua penelitian akan dikaji untuk dapat menganalisis kebutuhan dari
sistemnya. Referensi yang pertama diperoleh dari Dian Andarini Wardaani (2013),
dan yang kedua adalah penelitian dari Anna Indah Pratiwi (2013).
Penelitian pertama oleh Wardaani, Dian Andarini (2013) yang berjudul Aplikasi
Inventory Control Stock Opname Barang Habis Pakai (Bhp) Berbasis Web (Study
Kasus Balai Laboratorium Kesehatan D.I.Yogyakarta) menyimpulkan Hasil yang
dicapai dari penelitian ini adalah Aplikasi Inventory Control Stock Opname Barang
habis Pakai (BHP) yang digunakan oleh tiga user yaitu Bagian Administrasi Gudang
sebagai user admin, Bagian Deputi Manajer, dan Manajer Puncak. Aplikasi ini
menghasilkan ouput yang diperlukan oleh manajer puncak, antara lain dapat
mengakses laporan stock opname persediaan barang, dan memaksimalkan kinerja
bagian administrasi gudang dalam melakukan transaksi dan mengatur persediaan
barang yang ada digudang. Namun, penelitian tersebut belum menerapkan
webGIS pada studi kasus distribusi pupuk.
Penelitian kedua yang dijadikan referensi adalah penelitian berjudul
Implementasi Metode Waterfall Pada Sistem informasi Stock Opname oleh
Irnawati, Oky (2018). Metode pengembangan sistem yang digunakan adalah
metode Waterfall. Hasil dari penelitian ini dapat membuat kegiatan yang meliputi
penerimaan dan pengeluaran suku cadang, penyesuaian fisik dengan data stok,
melihat history barang keluar dan masuk, dan kegiatan stok opname menjadi lebih
mudah, efisien dan lebih terjamin.
2.2 Rekayasa Perangkat Lunak

Dikutip dari buku Rekayasa Perangkat Lunak oleh Janner Simarmata, Rekayasa
Perangkat Lunak adalah sebuah profesi yang dilakukan oleh seorang perekayasa
perangkat lunak yang berkaitan dengan pembuatan dan pemeliharaan aplikasi
perangkat lunak dengan menerapkan teknologi dan praktik dari ilmu komputer,
manajemen proyek, dan bidang-bidang lainnya.
5
2.3 SDLC (System Development Life Cycle)
System Development Life Cycle (SDLC) atau Siklus Hidup Pengembangan
Sistem adalah metode atau cara yang dapat digunakan dalam pengembangan
sistem yang sebagian besar digunakan pada saat ini, terdiri dari kerangka-kerangka
yang terstruktur dan berisi tahapan bagaimana sistem dikembangkan (Turban, et
al., 2003). SDLC memiliki beberapa metode yang dapat digunakan dalam
pengembangan sistem, yaitu: prototyping, V model, Waterfall, Spiral, Metode
Formal, dan Extreme Programming. Pada pengembangan perangkat lunak ini,
metode yang digunakan adalah Waterfall.
2.3.1 Metode Waterfall

Metode waterfall adalah metode pengembangan sistem yang digunakan
pada penelitian ini. Model SDLC waterfall menyediakan pendekatan alur hidup
perangkat lunak secara sekuensial atau urut dimulai dari analisis, desain,
pengkodean, pengujian dan tahap support (Rosa dan Shalahuddin, 2011).
Waterfall adalah model klasik yang bersifat sistematis, berurutan dalam11
membangun software. Berikut ini ada dua gambaran dari waterfall model
(Pressman, 2010:39).
Menurut Sommerville (2011) dalam menggunakan metode waterfall, ada
beberapa langkah-langkah yang harus dilakukan. Berikut merupakan tahapan-
tahapan metode waterfall: Commented [F4]: gambar ulang..font berbeda, sebelum tanda
baca tidak boleh ada spasi
Gambar 2.1 Model Waterfall Commented [F5]: ??
Sumber: Sommerville (2011)
1. Analisis Kebutuhan / Requirement

Pada tahap analisis kebutuhan ini pengembang harus melakukan
komunikasi untuk memahami masalah yang ada agar perangkat lunak yang akan
dikembangkan sesuai dengan kebutuhan pengguna dan batasan-batasan dalam
membuat perangkat lunak tersebut. Beberapa cara komunikasi yang dapat
dilakukan adalah wawancara, diskusi, ataupun survei.
6
2. Perancangan Perangkat Lunak / System Design
Hasil dari tahap analisis kebutuhan yang diperoleh pada tahap
sebelumnya, akan dipergunakan pada tahap ini untuk membuat desin sistem yang
akan diterapkan pada perangkat lunak. Dari tahap ini, dapat digambarkan
arsitektur dari sistem, perangkat lunak yang digunakan, dan persyaratan
sistemnya.
3. Implementasi / Implementation
Pada tahap ini, perancangan yang dilakukan pada tahap sebelumnya akan
diimplementasikan dalam kode-kode program dimulai dengan fungsional
perfungsional untuk kemudian diintegrasikan menjadi satu.
4. Pengujian / System Testing
Pada tahap ini, segala sistem yang telah dibuat dan diimplementasikan
dilakukan pengujian dengan berbagai teknik yang memperhatikan tujuan atau hal-
hal penting yang ada dalam sistem untuk mengetahui apakah ada kesalahan,
ketidaksesuaian atau kerusakan yang terjadi.
5. Pemeliharaan / Maintenance
Setelah semua tahap selesai dan perangkat lunak berhasil dibuat dan
dijalankan dengan baik, perlu diadakannya tahap pemeliharaan. Setiap kesalahan
atau kerusakan yang ditemukan pada tahap pengujian, akan diperbaiki pada tahap
pemeliharaan. Perbaikan dari unit system yang dilakukan ini bertujuan untuk
meningkatkan kinerja dan kehandalan dari sistem. Commented [F6]: Plagiasi , tulis ulang
Keunggulan yang dimiliki dari metode Waterfall ini adalah:

1. Penerapannya mudah.
2. Kemudahan dalam mendefinisikan kebutuhan sistem pada awal proyek.
3. Dengan pendefinisian kebutuhan sistem di awal proyek, maka akan
menghemat dana, waktu, dan usaha.
4. Proses pengembangan model fase satu demi satu, dapat meminimalisir
kesalahan yang mungkin akan terjadi karena dikerjakan secara berurutan.
5. Tuntutan untuk mendefinisikan kebutuhan selengkap dan sebaik mungkin
diawal cocok untuk proyek yang dikerjakan cukup jauh atau diluar kota
dengan dana perjalanan yang terbatas.
Kekurangan dari metode waterfall adalah:
1. Susah untuk melakukan perubahan jika terjadi kesalahan dalam berbagai
tahapannya, karna bersifat aliran yang berarti akan terus jalan dan akan
sangat susah kembali ke tahap sebelumnya.
2. Biasanya digunakan untuk rekayasa sistem yang besar misalnya proyek
yang dikerjakan di beberapa tempat berbeda dan dibagi menjadi beberapa
sub proyek.
7
2.4 Unified Modeling Language (UML)
UML merupakan sistem arsitektur yang bekerja dalam OOAD (Object-Oriented Commented [F7]: Jika sudah disingkat pada judul.gunakan UM
saja
Analysis/Design) dengan satu bahasa yang konsisten untuk menentukan,
visualisasi, mengkontruksi, dan mendokumentasikan artifact (sepotong informasi
yang digunakan atau dihasilkan dalam suatu proses rekayasa software, dapat
berupa model, deskripsi, atau software) yang terdapat dalam sistem software.
UML merupakan bahasa pemodelan yang paling sukses dari tiga metode OO yang
telah ada sebelumnya, yaitu Booch, OMT (Object Modeling Technique), dan OOSE
(Object-Oriented Software Engineering).
Tujuan UML diantaranya adalah:
1. Memberikan model yang siap pakai, bahasa pemodelan visual yang ekspresif
untuk mengembangkan dan saling menukar model dengan mudah dan
dimengerti secara umum.
2. Memberikan bahasa pemodelan yang bebas dari berbagai bahasa
pemrograman dan proses rekayasa.
3. Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan. Untuk
membuat suatu model, UML memiliki diagram grafis sebagai berikut:
a) Business Use Case model
b) Use Case model
c) Behavior diagram: Sequence diagram
d) Implementation diagram: Component diagram, Deployment diagram
e) Generate Code
Diagram diagram tersebut diberi nama berdasarkan sudut pandang yang
berbeda-beda terhadap sistem dalam proses analisis atau rekayasa. Dibuatnya
berbagai jenis diagram diatas karena:
1. Setiap sistem yang kompleks selalu paling baik jika didekati melalui himpunan
berbagai sudut pandang yang kecil yang satu sama lain hampir saling bebas
(independent). Sudut pandang tunggal senantiasa tidak mencukupi untuk
melihat isi item yang besar dan kompleks.
2. Diagram yang berbeda-beda tersebut dapat menyatakan tingkatan yang
berbeda-beda dalam proses rekayasa.
3. Diagram-diagram tersebut dibuat agar model yang dibuat semakin mendekati
realitas.
Diagram-diagram ini ditambah dengan kemampuan dokumentasi perupakan
artifacts utama UML. Data-flow diagram dan tipe diagram lain yang tidak terdapat
dalam UML tidak termasuk dalam paradigma object-oriented. Activity diagram
dan collaboration diagram yang terdapat dalam UML menggantikan data-flow
diagram. Activity diagram juga sangat bermanfaat untuk membuat workflow.
8
2.4.1 Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari
sebuah sistem, yang ditekankan adalah “apa” yang diperbuat sistem dan bukan
“bagaimana”. Sebuah use case mempresentasikan sebuah interaksi antara actor
dengan sistem. Use case menggambarkan kata kerja seperti Login ke sistem,
maintenance user dan sebagainya.
Lambang-lambang dalam use case Diagram
1). Actor merupakan sebuah entita yang berinterkasi dengan use case. Nama actor
dituliskan di bawah gambar tersebut.
2). Use case menggambarkan sebuah fungsi terntentu yang disediakan oleh
sistem, sebuah subsistem atau urutan pertukaran pesan antara anggota
sistem dan satu atau lebih actor melakukan aksi yang dikerjakan oleh sistem.
3). Hubungan, menggambarkan hubungan association. Garis ini digunakan untuk
menghubungkan antara actor dengan use case.
Komponen - komponen Use case Diagram disajikan pada tabel Tabel 2.1:
Tabel 2.1 Notasi Use Case Diagram Commented [F8]: layout
NO GAMBAR NAMA KETERANGAN

Menspesifikasikan himpuan
peran yang pengguna mainkan
1 Actor
ketika berinteraksi dengan use
case.
Menspesifikasikan bahwa use
2 Include
case sumber secara eksplisit.
Menspesifikasikan bahwa use

case target memperluas perilaku
3 Extend
dari use case sumber pada suatu
titik yang diberikan.
Apa yang menghubungkan antara
4 Association
objek satu dengan objek lainnya.
Deskripsi dari urutan aksi-aksi
yang ditampilkan sistem yang
5 Use Case
menghasilkan suatu hasil yang
terukur bagi suatu aktor
Elemen fisik yang eksis saat
aplikasi dijalankan dan
6 Note
mencerminkan suatu sumber
daya komputasi
9
2.4.2 Sequence Diagram
Diagram sekuensial atau sequence diagram digunakan untuk
menggambarkan aliran fungsionalitas dalam use case. Diagram ini disusun
berdasarkan urutan waktu. Kegunaan sequence diagram:
a. Sequence diagram dapat digunakan untuk menggambarkan skenario atau
rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah
events untuk menghasilkan output tertentu. Diawali dari apa yang men-
trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi
secara internal dan output apa yang dihasilkan.
b. Diagram ini secara khusus berasosiasi dengan use case diagram.
c. Memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk
menghasilkan sesuatu di dalam use case.
2.4.3 Class Diagram

Class Diagram adalah penggambaran hubungan antara suatu kelas dengan
kelas yang lain dan dilengkapi dengan komponen dari kelas tersebut (Hendini,
2018). Class Diagram terdiri dari class, relasi asosiasi, relasi agregasi, relasi
generalisasi, atribut, operasi, dan visibility dari operasi dan atribut. Class Diagram
akan menggambarkan komponen kelas yaitu atribut dan operasi yang ada didalam
kelas tersebut.
2.5 PT. Petrokimia Gresik

PT Petrokimia Gresik adalah salah satu perusahaan yang memproduksi pupuk
terlengkap di Indonesia, PT Petrokimia Gresik juga memproduksi produk non
pupuk, antara lain Asam Sulfat, Asam Fosfat, Amoniak, Dry Ice, Aluminum
Fluoride, Cement Retarder, dll. perusahaan ini memproduksi berbagai macam
pupuk, seperti: Urea, ZA, SP-36, ZK, NPK Phonska, NPK Kebomas, dan pupuk
organik Petroganik. Keberadaan PT Petrokimia Gresik adalah untuk mendukung
program Pemerintah dalam rangka meningkatkan produksi pertanian dan
ketahanan pangan Nasional. PT Petrokimia Gresik merupakan pabrik pupuk
terlengkap di Indonesia, yang pada awal berdirinya disebut Proyek Petrokimia
Surabaya. Kontrak pembangunannya ditandatangani pada tanggal 10 Agustus
1964, dan mulai berlaku pada tanggal 8 Desember 1964. Proyek ini diresmikan
oleh Presiden Republik Indonesia pada tanggal 10 Juli 1972.
PT Petrokimia Gresik memiliki visi menjadi produsen pupuk dan produk kimia
lainnya yang berdaya saing tinggi dan produknya paling diminati konsumen. Misi :
Mendukung penyediaan pupuk nasional untuk tercapainya program swasembada
pangan. Meningkatkan hasil usaha untuk menunjang kelancaran kegiatan
operasional dan pengembangan usaha perusahaan. dan Mengembangkan potensi
usaha untuk mendukung industri kimia nasional dan berperan aktif dalam
community development.
10
2.5.1 Distribusi Pupuk PT. Petrokimia Gresik
Gambar 2.2 Alur Distribusi PT. Petrokimia Gresik
Seperti dalam Gambar 2.2 alur distribusi pupuk PT. Petrokimia Gresik.
Setiap gudang penyangga tidak memproduksi pupuk sendiri melainkan disediakan
oleh Gudang Gresik (Gudang utama). Sudah terdapat jadwal pengiriman
banyaknya stock yang dikirim, sesuai dengan permintaan dari setiap gudang
penyangga.
2.6 Sistem Aplikasi Manajemen

Sistem informasi adalah suatu sistem di dalam suatu organisasi yang
mempertemukan kebutuhan pengolahan transaksi harian, mendukung operasi,
bersifat manajerial dan kegiatan strategi dari suatu organisasi dan menyediakan
pihak luar tertentu dengan laporan-laporan yang diperlukan (Jogiyanto, 2005).
Sistem informasi didefinisikan sebagai kumpulan elemen yang saling
berhubungan satu sama lain yang membentuk satu kesatuan untuk
mengintegrasikan data, memproses dan menyimpan serta mendistribusikan
informasi (Sutedjo, 2002).
Sifat Informasi menurut Subawe (2000) antara lain:
1. Akurasi (accuracy). Berkaitan dengan tingkat kemampuan dari suatu informasi
untuk mengukur apa yang seharusnya diukur. Informasi harus merefleksikan
realitas secara benar.
2. Ketepatan Waktu (timeliness). Informasi besifat mutakhir dan disajikan pada
saat dibutuhkan.
3. Kuantibilitas (quantifiability). Yang disajikan dalam informasi hanya yang
dapat dinilai dengan uang.
4. Kepadatan (cinciseness). Informasi disajikan secara singkat dan langsung
mengarah pada pokok masalah.
5. Relevan (relevance). Berkaitan dengan seberapa baik hubungan antara
informasi dengan suatu masalah keputusan tertentu. Informasi yang relevan
adalah informasi yang mempengaruhi keputusan yang dibuat.
11
Menurut Ardiyanto (2011), sistem informasi merupakan sekumpulan
komponen pembentuk sistem yang mempunyai keterkaitan antara satu
komponen dengan komponen lainnya yang bertujuan menghasilkan suatu
informasi dalam suatu bidang tertentu. Dalam sistem informasi diperlukannnya
klasifikasi alur informasi, hal ini disebabkan keanekaragaman kebutuhan akan
suatu informasi oleh pengguna informasi. Kriteria dari sistem informasi antara
lain, fleksibel, efektif dan efisien. Sistem informasi berbasis komputer (Computer
based information system) terdiri dari komponen-komponen sebagai berikut:
a. Perangkat keras (hardware), merupakan komponen untuk melengkapi
kegiatan memasukkan data, memproses data dan keluaran data.
b. Perangkat lunak (software), merupakan program dan instruksi yang diberikan
ke komputer untuk menjalankan sistem.
c. Basis data (database), merupakan sekumpulan data dan informasi yang
diorganisasikan sedemikian rupa sehingga mudah diakses pengguna sistem
informasi.
d. Telekomunikasi, merupakan sebuah sistem yang menghubungkan anatara
pengguna sistem dengan sistem komputer secara bersama-sama ke dalam
suatu jaringan kerja yang efektif.
e. Manusia (human), merupakan personel dari sistem informasi, meliputi
manajer, analis, programmer, dan operator, serta bertanggung jawab
terhadapa perawatan sistem.
f. Prosedur, merupakan tata cara yang meliputi strategi, kebijakan, metode dan
peraturan-peraturan dalam menggunakan sistem informasi.
Sistem informasi manajeman (management information system) merupakan
penerapan sistem informasi didalam organisasi untuk mendukung informasi-
informasi yangdibutuhkan oleh semua tingkatan manajemen (Jogiyanto, 2005).
Sedangkan menurut Ismail (2004), sistem Aplikasi Manajemen merupakan
serangkaian sub-sistem informasi yang menyeluruh dan terkoordinasi yang secara
rasional mampu mentransformasikan data sehingga menjadi informasi dengan
berbagai cara guna meningkatkan produktivitas yang sesuai dengan gaya dan sifat
manajer.
Sistem Aplikasi Manajemen adalah kunci dari suatu bidang yang
menekankan personal manajemen yang dapat memproses dan mengolah data
menjadi suatu bentuk informasi yang dapat digunakan dalam mendukung
keputusan dengan melewati suatu prosedur kerja (aturan kerja) yang telah
ditetapkan. Sistem Aplikasi Manajemen merupakan sistem yang menyediakan
informasi yang digunakan untuk mendukung operasi, manajemn serta
pengambilan keputusan sebuah organisasi. Jenis-jenis sistem Aplikasi Manajemen
selanjutnya dispesialisasikan jenisnya menurut kebutuhan dari organisasi
penggunanya. Sistem informasi yang digunakan di instansi pemerintah,
pendidikan, rumah sakit atau perusahaan memiliki fungsi yang berbeda (Widyanti,
2006).
Sistem Aplikasi Manajemen secara umum dapat dikatakan sebagai sebuah
sistem manusia dan mesin yang terintegrasi dalam menyediakan informasi guna
mendukung fungsi operasi manajemen dan penentuan alternatif tindakan dalam
12
sebuah organisasi sistem tersebut. Dalam operasinya, sistem Aplikasi Manajemen
menggunakan perangkat keras (hardware), perangkat lunak (software), prosedur,
mdel manajemen dan keputusan serta sebuah terminal data. Sistem Aplikasi
Manajemen sebagai suatu kumpulan manusia dan sumber modal di dalam suatu
organisasi bertanggung jawab untuk pengumpulan dan pengolahan data sewaktu
menghasilkan informasi yan gberguna untuk setiap hierarki manajemen dalam
perencanaan dan pengendalian kegiatan-kegiatan organisasi. Tujuan dari suatu
sistem Aplikasi Manajemen adalah memberikan informasi untuk pembuatan
keputusan dalam merencanakan, memulai, mengatur dan mengendalikan operasi
sub-sistem dari perusahaan/organisasi dan juga untuk memberikan perusahaan
sebuah sinergi dalam prosesnya (Gaol, 2008).
Para pengguna sistem Aplikasi Manajemen biasanya terdiri dari entitas-
entitas organisasi formal-perusahaan atau sub-unit anak perusahaan. Informasi
yang diberikan oleh sistem infomasi manajemen menjelaskan perusahaan atau
salah satu sistem utamanya dilihat dari apa yang telah terjadi di masa lalu, apa
yang terjadi dan apa yang kemungkinan akan terjadi di masa depan. Output
informasi yang dihasilkan akan digunakan oleh pihak-pihak yang akan
memecahkan masalah (baik itu manajer maupun kalangan professional) dalam
mengambil keputusan guna memecahkan masalah perusahaan (McLeod dan
Schell, 2008).
Lingkungan
Pihak Pemecah
Masalah Organisasi
Peranti Lunak
Model Matematis
Pembuat Laporan
Basis Data
Sistem
Informasi
Manajemen
Lingkungan
Gambar 2.3 Model SIstem Aplikasi Manajemen

Keterangan:
Data
Informasi
13
Pada Gambar 2.3 terlihat bahwa pada basis data memuat data yang
diberikan oleh sistem pemrosesan transaksi. Selain itu, baik data maupun
informasi dimasukkan dari lingkungan. Lingkungan menjadi terlibat ketika
peusahaan berinteraksi dengan organisasi-organisasi lain, seperti pemasok, unutk
membentuk suatu sistem informasi antarorganisasi (interorganizational
information system) (McLeod dan Schell, 2008).
2.7 Pengujian Sistem

Pengujian dilakukan untuk menguji setiap modul untuk menjamin setiap
modul menjalankan fungsinya dengan baik (Fatta, 2007). Ada dua (2) metode
untuk melakukan unit testing menurut Fatta (2007), yaitu:
1. Blackbox Testing
Blackbox testing focus pada apakah unit program memenuhi kebutuhan
(requirement) yang disebutkan dalam spesifikasi. Pada blackbox testing, cara
pengujian hanya dilakukan dengan menjalankan atau mengeksekusi unit atau
modul, kemudian diamati apakah hasil dari unit itu sesuai dengan proses
bisnis yang diinginkan. Jika ada unit yang tidak sesuai output-nya, maka untuk
menyelesaikannya diteruskan pada pengujian kedua, yaitu whitebox testing.
Menurut Yulianto (2012), blackbox testing cenderung untuk menemukan hal-
hal berikut:
a. Fungsi yang tidak benar atau tidak ada.
b. Kesalahan antarmuka (interface errors).
c. Kesalahan pada struktur data dan akes basis data.
d. Kesalahan performansi (performance errors).
e. Kesalahan inisialisasi dan terminasi.
2. Whitebox Testing
Whitebox testing merupakan cara pengujian dengan melihat kedalam modul
untuk meneliti kode-kode program yang ada, dan menganalisis apakah ada
kesalahan atau tidak. Jika ada modul yang menghasilkan output yang tidak
sesuai dengan proses bisnis yang dilakukan, maka baris-baris program,
variabel dan parameter yang terlibat pada unit tersebut akan dicek satu
persatu dan diperbaiki, kemudian di-compile ulang. Menurut Yulianto (2012),
penggunaan metode pengujian whitebox dilakukan untuk:
a. Memberikan jaminan bahwa semua jalur independent suatu modul
digunakna minimal satu kali.
b. Menggunakan semua keputusan logis untuk semua kondisi true atau false.
c. Mengeksekusi semua perulangan pada batasan nilai dan operasional pada
setiap kondisi.
d. Menggunakan struktur data internal untuk menjamin validitas jalur
keputusan.
14
BAB 3 METODOLOGI PENELITIAN
Pada bab ini akan diuraikan langkah-langkah penelitian yang akan dilakukan
dalam proses penyelesaian penelitian ini. Metode penelitian ini digunakan sebagai
pedoman dalam proses pengerjaan penelitian ini. Langkah-langkah yang diambil
seperti yang terlihat dalam Gambar 3.1 yaitu studi literature, analisis kebutuhan,
perancangan sistem, implementasi, pengujian, penarikan kesimpulan dan saran.
Gambar 3.1 Diagram Alir Penelitian
3.1 Studi Literatur

Studi literatur berisikan studi kepustakaan yang dapat menunjang penulisan
penelitian ini. Sumber yang digunakan berasal dari buku, berbagai jurnal ilmiah,
website dan tulisan yang berhubungan dengan analisis dan perancangan sistem.
Teori dan pustaka yang sesuai dengan penelitian ini adalah:
1. PT. Petrokimia Gresik
15
2. Sistem Informasi
3. Manajemen Distribusi
4. PHP
5. MySQL
6. SDLC (System Development Life Cycle)
7. UML (Unified Modelling Language)
8. WebGIS
9. Stock opname
10. Pengujian Perangkat Lunak
3.2 Analis Kebutuhan

Dalam tahapan ini dilakukan analisa terhadap kondisi yang terjadi saat ini.
Tahap ini merupakan tahap terpenting dalam mengembangkan suatu sistem. Pada
tahap ditujukan untuk mengetahui kebutuhan fungsional dan non fungsional.
Dalam tahap ini akan dilakukan wawancara yang akan dilakukan kepada
Departemen Distribusi Wilayah 1 PT. Petrokimia Gresik. Dari situ bisa
mendapatkan gambaran umum sistem, identifikasi aktor yang terlibat, daftar
kebutuhan yang nantinya dimodelkan ke dalam diagram use case dan skenario use
case.
3.3 Perancangan Sistem

Perancangan dilakukan ketika semua kebutuhan sistem telah tersedia.
Kebutuhan sistem yang sudah diperoleh melalui tahap analisis kebutuhan
kemudian akan menghasilkan perancangan awal, dari perancangan awal akan
dimodelkan. Tahap ini merupakan proses menterjemahkan kebutuhan yang
didapat sebelumnya menjadi model perangkat lunak menggunakan pemodelan
UML (Unified Modeling Language). Pemodelan UML yang akan dilakukan adalah
perancangan Diagram Class, perancangan Diagram Sequence, perancangan Basis
Data, dan Perancangan interface.
Stock opname distribusi pupuk gudang penyangga merupakan fitur distribusi
dari Gudang gresik ke gudang penyangga dan diteruskan ke distribusi setiap
kabupaten. Selanjutnya webGIS berfungsi sebagai pemetaan distribusi dari
penyangga ke setiap distribusi kabupaten guna membuat visualisasi sehingga
memudahkan petugas dalam pemantauan stock distribusi. Dalam manajemen
distribusi tidak boleh telat stock ataupun kehabisan sehingga dapat
memperhambat proses, oleh sebab itu dilengkapi dengan fitur peramalan stock
demand guna antisipasi lonjakan permintaan atau stok berlebihan sehingga dapat
tepat guna.
16
3.4 Implementasi
Desain yang telah disetujui dan diverifikasi pada tahap sebelumnya kemudian
diterapkan dalam bentuk kode-kode pemrograman. Membuat fitur-fitur yang
dibutuhkan untuk digabungkan dan dintergrasikan untuk menjadi suatu Aplikasi.
Implementasi dilakukan menggunakan bahasa pemograman PHP.
3.5 Pengujian
Pengujian akan dilakukan untuk menemukan kesalahan pada perangkat lunak
dan menguji apakah semua kebutuhan sudah sesuai dengan permintaaan user.
Bentuk pengujian yang akan dilakukan adalah dengan menggunakan metode Black
Box Testing dan White Box testing. Pengujian menggunakan metode blackbox
testing, yang mana metode ini menguji apakah masukan yang diberikan dan
keluaran yang diberikan sesuai. Lalu metode ini juga digunakan untuk mengecek
apakah sistem yang dibuat sudah memenuhi requirement yang dijabarkan di awal.
Jika selama pengujian ditemukan kesalahan ataupun ada kebutuhan yang tidak
berjalan dengan semestinya, maka akan dilakukan perbaikan dari kesalahan
kesalahan tersebut.
3.6 Penarikan Kesimpulan dan Saran

Pengambilan kesimpulan dan saran dilakukan setelah semua tahapan dalam
penyusunan penelitian ini selesai. Saran didapatkan untuk memperbaiki
kesalahan-kesalahan yang terjadi dan sebagai bahan pertimbangan untuk
pengembangan.
17
BAB 4 ANALISIS KEBUTUHAN
Analisis kebutuhan merupakan tahapan awal untuk mengembangkan sistem.

Dari analisis kebutuhan ini didapatkan kebutuhan-kebutuhan yang ada pada
sistem ini. Kebutuhan-kebutuhan ini didapatkan dari hasil studi lapangan di
Departemen Distribusi Wilayah 1 PT. Petrokimia Gresik dengan teknik wawancara
dan observasi. Dalam tahap ini, didapatkan aktor-aktor yang ada didalam sistem
dan apa saja yang dapat dilakukan serta pendefinisian kebutuhan fungsional dan
non-fungsional.
4.1 Deskripsi Sistem

Sistem Aplikasi Manajemen Distribusi Pupuk PT. Petrokimia Gresik adalah
sitem yang dibuat dengan tujuan untuk menjadi media berbagi informasi antar
stakeholder distribusi dari Gudang pusat ke Gudang penyangga untuk memastikan
proses distibusi berjalan baik dan data dapat terekam dengan baik. Selain itu,
dapat menjadi media pemantauan data stok digudang penyangga secara realtime.
Dilengkapi juga dengan validasi keakuratan data dilapangan dengan melakukan
stok opname yang datanya dapat langsung diproses dalam sistem.
4.2 Identifikasi Aktor

Identifikasi aktor menjelaskan tentang peran-peran dari aktor yang terlibat
dalam sistem. Aktor-aktor ini didapatkan berdasarkan hasil wawancara dan
observasi pada saat studi lapangan. Berdasarkan hasil wawancara dan observasi,
pada sistem ini terdapat tujuh peran aktor yaitu Operator Diswil 1, Operator
Gudang Penyangga, Operator Rekanan Transportir, Operator Gudang Pusat,
Manager Diswil 1, Operator Stok Opname, dan Operator Rekanan Gudang
Penyangga. Identifikasi aktor dijelaskan pada Tabel 4.1 yang terdiri dari kolom no,
nama aktor, dan deskripsi yang menjelaskan kegiatan dari aktor.
Tabel 0.10.1 Identifikasi Aktor
No. Nama Aktor Deskripsi
1. Operator Diswil 1 Operator Diswil 1 adalah actor yang merupakan
karyawan Departemen Distribusi Wilayah 1 yang
memiliki tanggung jawab penuh atas proses
distribusi dan manajemen stok pupuk.
2. Operator Gudang Operator Gudang Penyangga adalah actor yang
Penyangga merupakan rekanan dari PT. Petrokimia Gresik
yang bertugas dan bertanggung jawab mengelola
suatu Gudang penyangga.
3. Operator Rekanan Operator Rekanan Transportir adalah actor yang
Transportir bertanggung jawab untuk menyediakan
18
transportasi guna mengambil pupuk dari gudang
pusat untuk diantarkan ke gudang penyangga.
4. Operator Gudang Operator Gudang Pusat adalah actor yang
Pusat bertanggung jawab untuk menyiapkan pupuk yang
akan diambil oleh Rekanan Transportir.
5. Manager Diswil 1 Manager Diswil 1 adalah actor yang bertanggung
jawab untuk melihat kondisi stok pada daerah
tertentu secara real time melalui GIS.
6. Operator Stok Operator Stok Opname adalah actor yang
Opname bertanggung jawab melakukan proses stok
opname.
7. Operator Rekanan Operator Rekanan Pengelola Gudang Penyangga
Pengelola Gudang adalah actor yang bertanggung jawab terhadap
Penyangga kehilangan pupuk yang terjadi di Gudang
penyangga.
4.3 Aturan Penomoran

Kebutuhan Fungsional:
Contoh: SIDP_F_101: Representasi kebutuhan fungsional sistem aplikasi SIDP
dengan nomor 101.
Kode: SIDP _F_D _101
Digit / nomor kebutuhan
Kode untuk deskripsi

kebutuhan fungsional
Kode jenis kebutuhan

fungsional
Singkatan nama Sistem

Informasi Distribusi
Pupuk.
19
Spesifikasi Kebutuhan:
Contoh: SIDP_F_S_101: Representasi spesifikasi kebutuhan fungsional sistem
aplikasi SIDP dengan nomor 101.
Kode: SIDP _F_S _101
Kode untuk spesifikasi

kebutuhan

fungsional

Pupuk.
Kebutuhan Non Fungsional :

Contoh: SIDP_NF_001: Representasi kebutuhan non fungsional sistem aplikasi
SIDP dengan nomor 001.
Kode: SIDP_NF_ 001

Non fungsional

Pupuk.
4.4 Kebutuhan Fungsional

Kebutahan fungsional adalah kebutuhan utama yang harus dapat disediakan
system dan dapat diakses oleh pengguna. Dari hasil elisitasi kebutuhan yang telah
dilakukan, diperoleh kebutuhan-kebutuhan fungsional yang diharapkan oleh
pengguna. Kebutuhan fungsional dari sistem ini berjumlah 38 kebutuhan dan
dijabarkan dalam bentuk tabel 4.2 dengan ketegori kode dari kebutuhan, actor
yang bersangkutan, nama fungsi dan deksripsi dari kebutuhan.
20
Tabel 0.20.2 Kebutuhan Fungsional
No Aktor Nama Fungsi Kode Deskripsi Kebutuhan Commented [F9]: Repeat header row
Aktor harus dapat melihat data

SIDP_F_D_001
Melihat Jenis jenis pupuk pada sistem.
Operator Pupuk
1. Aktor dapat melihat data jenis
Diswil 1
SIDP_F_S_001 pupuk yaitu jenis pupuk, berat per
kemasan
Aktor dapat menambah jenis
SIDP_F_D_002
pupuk.
Operator Menambah Aktor dapat menambah jenis
2.
Diswil 1 Jenis Pupuk pupuk dengan data jenis pupuk,
SIDP_F_S_002
dan berat per kemasan dalam
satuan kg
Aktor dapat mengubah data jenis
SIDP_F_D_003
pupuk
Operator Mengubah
3. Aktor dapat menguah data jenis
Diswil 1 Jenis Pupuk
SIDP_F_S_003 pupuk yaitu jenis pupuk, berat per
kemasan dalam satuan kg.
SIDP_F_D_004
rekanan transportir
Melihat
Operator Aktor harus dapat melihat data
4. Rekanan
Diswil 1 rekanan transportir yaitu nama
Transportir SIDP_F_S_004
rekanan, daftar gudang,
username, password.
Aktor harus dapat menambah
SIDP_F_D_005
rekanan transportir.
Menambah
Operator Aktor harus dapat menambah
5. Rekanan
username, password
Aktor dapat mengubah data
SIDP_F_D_006
rekanan transportir
Mengubah
Operator Aktor dapat mengubah data
6. Rekanan
username, password
Operator Melihat Batas Aktor harus dapat melihat data
7. SIDP_F_D_007
Diswil 1 Stok Kritis batas stok kritis.
21
Operator Diswil harus dapat

melihat data batas stok kritis yaitu
SIDP_F_S_007
nama daerah, jenis pupuk, dan
qty batas stok kritis
SIDP_F_D_008
data batas stok kritis.
Menambah
Operator Aktor harus dapat menambah
8. Batas Stok
Diswil 1 data batas stok kritis. Yang terdiri
Kritis SIDP_F_S_008
dari nama daerah, jenis pupuk,
dan qty batas stok kritis
Aktor harus dapat mengubah data
SIDP_F_D_009
batas stok kritis.
9. Mengubah
Operator Aktor harus dapat mengubah data
Batas Stok
Diswil 1 batas stok kritis. Yang terdiri dari
Kritis SIDP_F_S_009
nama daerah, jenis pupuk, dan
qty batas stok kritis
SIDP_F_D_010 rekanan pengelola Gudang
Melihat penyangga.
Rekanan Aktor harus dapat melihat data
Operator
10. Pengelola rekanan pengelola Gudang
Diswil 1
Gudang penyangga yang terdiri dari nama
Penyangga SIDP_F_S_010
rekanan, daftar Gudang
penyangga yang dikelola, dan
username
SIDP_F_D_011 data rekanan pengelola Gudang
Menambah penyangga.
Rekanan Aktor harus dapat menambah
Operator
11. Pengelola data rekanan pengelola Gudang
Diswil 1
Gudang penyangga yang terdiri dari nama
penyangga yang dikelola,
username, dan password.
Mengubah Aktor harus dapat mengubah data
Rekanan SIDP_F_D_012 rekanan pengelola Gudang
Operator
12. Pengelola penyangga.
Diswil 1
Gudang
Penyangga SIDP_F_S_012 Aktor harus dapat mengubah data
rekanan pengelola Gudang
22
penyangga yang terdiri dari nama

penyangga yang dikelola,
SIDP_F_D_013
Gudang penyangga.
Melihat Aktor harus dapat melihat data

Operator Gudang penyangga yang terdiri
13. Gudang
Diswil 1 dari kode Gudang penyangga,
alamat, daya tampung Gudang,
pengelola, nama kepala Gudang,
kontak, dan username.
SIDP_F_D_014
data Gudang penyangga.
Menambah data Gudang penyangga yang
Operator
14. Gudang terdiri dari kode Gudang
Diswil 1
Penyangga SIDP_F_S_014 penyangga, alamat, daya
tampung Gudang, pengelola,
nama kepala Gudang, kontak,
SIDP_F_D_015
Gudang penyangga.

Operator Gudang penyangga yang terdiri
15. Gudang
Diswil 1 dari kode Gudang penyangga,
alamat, daya tampung Gudang,
pengelola, nama kepala Gudang,
kontak, username, dan password.
SIDP_F_D_016
Petugas Stok Opname.
Melihat
Operator Aktor harus dapat melihat data
16. Petugas Stok
Diswil 1 Petugas Stok Opname yang terdiri
Opname SIDP_F_S_016
dari kode tim, nama petugas 1,
nama petugas 2, dan username.
Menambah SIDP_F_D_017
Operator data Petugas Stok Opname.
17. Petugas Stok
Diswil 1
Opname SIDP_F_S_017 Aktor harus dapat menambah
data Petugas Stok Opname yang
23
terdiri dari kode tim, nama

petugas 1, nama petugas 2,
username dan password.
SIDP_F_D_018
Petugas Stok Opname.
Operator
18. Data Petugas Petugas Stok Opname yang terdiri
Diswil 1
Stok Opname SIDP_F_S_018 dari kode tim, nama petugas 1,
nama petugas 2, username dan
password.
Aktor harus dapat membuat
SIDP_F_D_019
penugasan stok opname.
Membuat Aktor harus dapat membuat
Operator
19. Penugasan penugasan stok opname dengan
Diswil 1
Stok Opname SIDP_F_S_019 rincian data yaitu kode tim, kode
Gudang penyangga, dan tanggal
berangkat.
Aktor harus dapat melihat
SIDP_F_D_020
Operator
Melihat Aktor harus dapat melihat
Diswil 1,
20. Penugasan penugasan stok opname dengan
Operator
Stok Opname SIDP_F_S_020 rincian data yaitu kode tim, kode
Stok Opname
Gudang penyangga, dan tanggal
berangkat.
SIDP_F_D_021
permintaan pengiriman pupuk.
Membuat
Operator Permintaan Aktor harus dapat membuat
21. permintaan pengiriman pupuk
Diswil 1 Pengiriman
Pupuk SIDP_F_S_021 dengan rincian data yaitu no
pengiriman, jenis pupuk, quantity,
tujuan, batas waktu pengantaran.
Operator Aktor harus dapat melihat
SIDP_F_D_022
Diswil 1, permintaan pengiriman pupuk.
Melihat
Operator
Permintaan Aktor harus dapat melihat
Gudang
22. Pengiriman permintaan pengiriman pupuk
Pusat,
Pupuk dengan rincian data yaitu nomor
Operator SIDP_F_S_022
pengiriman, jenis pupuk, quantity,
Gudang
tujuan, batas waktu pengantaran,
Penyangga,
nama transportir.
Operator
24
Rekanan
Transportir
Aktor harus dapat mengisi detail
SIDP_F_D_023
Mengisi Detail Aktor harus dapat mengisi detail

Operator permintaan pengiriman pupuk
Permintaan
23. Rekanan dengan data yang harus
Pengiriman
Transportir SIDP_F_S_023 dimasukan adalah plat nomor
Pupuk
kendaraan pengangkut, nama
supir, qty angkut tiap kendaraan,
tanggal pengambilan pupuk.
Aktor harus dapat melihat daftar
SIDP_F_D_026 pupuk yang hilang di Gudang
penyangga.
Melihat Daftar
Operator Aktor harus dapat melihat daftar
Pupuk yang
Rekanan pupuk yang hilang di Gudang
24. Hilang di
Gudang penyangga dengan rincian data
Gudang
Penyangga SIDP_F_S_026 yaitu kode Gudang penyanggga,
Penyangga
nama kepala Gudang, dan qty
pupuk yang hilang dari hasil stok
opname.
Aktor harus dapat melihat hasil
Operator SIDP_F_D_027 stok opname yang sudah
Rekanan divalidasi.
Gudang Aktor harus dapat melihat hasil
Melihat Hasil
25. Penyangga, stok opname yang sudah
Stok Opname
Operator divalidasi dengan rincian data
yang Sudah
Stok Opname yaitu kode Gudang penyangga,
Divalidasi SIDP_F_S_027
Diswil 1, nama kepala Gudang, nama
Manager petugas stok opname, jenis
Diswil 1 pupuk, stok hasil stok opname,
stok sistem, dan selisih.
SIDP_F_D_028
perhitungan stok opname.
26. Operator Membuat Aktor harus dapat membuat

Stok Opname Perhitungan perhitungan stok opname dengan
Diswil 1 Stok Opname SIDP_F_S_028 rincian data yaitu tanggal, jam,
kode Gudang penyangga, jenis
pupuk, berat kemasan, area,
kunci, Panjang, lebar, tinggi,
25
jumlah bag, jumlah ton, lebihan

bag, lebihan ton, total bag, total
ton.
Aktor harus dapat melihat
SIDP_F_D_029
perhitungan stok opname.
Operator Aktor harus dapat melihat

Stok Opname perhitungan stok opname dengan
Melihat rincian data yaitu tanggal, jam,
Diswil 1,
27. Perhitungan kode Gudang penyangga, jenis
Operator
Stok Opname SIDP_F_S_029 pupuk, berat kemasan, area,
Gudang
Penyangga kunci, Panjang, lebar, tinggi,
jumlah bag, jumlah ton, lebihan
bag, lebihan ton, total bag, total
ton.
Aktor harus dapat melihat hasil
SIDP_F_D_030
stok opname.
Operator
Gudang Aktor harus dapat melihat hasil
Penyangga, Melihat Hasil stok opname dengan rincian data
28. yaitu kode Gudang penyangga,
Operator Stok Opname
Stok Opname SIDP_F_S_030 nama kepala Gudang, nama
Diswil 1 petugas stok opname, jenis
pupuk, stok hasil stok opname,
Aktor harus dapat melihat peta
SIDP_F_D_031
kondisi stok.
Aktor harus dapat melihat peta
kondisi stok dengan rincian data
yaitu WebGIS yang dilengkapi
Operator dengan layering warna setiap
Diswil 1, Melihat Peta daerah yang mengindikasikan
29. kondisi stok (aman/kurang)
Manager Kondisi Stok
Diswil 1 SIDP_F_S_031 dilengkapi dengan stok tersedia di
Gudang penyangga daerah
tersebut (tiap jenis pupuk),
tanggal terakhir stok opname,
selisih hasil stok opname, stok
buffer (tiap jenis pupuk), kontak
Gudang penyangga.
30. SIDP_F_D_032
laporan pupuk rusak.
26

Operator Membuat laporan pupuk rusak dengan
Gudang Laporan Pupuk SIDP_F_S_032 rincian data yaitu jenis pupuk, qty,
Penyangga Rusak kemasan, foto, alasan kerusakan
pupuk.
Aktor harus dapat melihat laporan
Operator SIDP_F_D_033
pupuk rusak.
Gudang Melihat
31. Penyangga, Laporan Pupuk Aktor harus dapat melihat laporan
Operator Rusak pupuk rusak dengan rincian data
SIDP_F_S_033
Diswil 1. yaitu jenis pupuk, qty, kemasan,
foto, alasan kerusakan pupuk.
Aktor harus dapat validasi
SIDP_F_D_034
penerimaan pupuk.
Operator Validasi Aktor harus dapat validasi
32. Gudang Penerimaan penerimaan pupuk dengan data
Penyangga. Pupuk SIDP_F_S_034 yang harus dimasukan ubah
status diterima Gudang
penyangga, qty diterima.
SIDP_F_D_035 data pupuk keluar Gudang
penyangga.
Menambah Aktor harus dapat menambah
Operator
Pupuk Keluar data pupuk keluar Gudang
33. Gudang
Gudang penyangga dengan data yang
Penyangga.
Penyangga. SIDP_F_S_035 harus dimasukan nomor
pengiriman, jenis pupuk, nama
distributor, nomor plat, nama
supir, nama distributor.
SIDP_F_D_036 data pupuk keluar Gudang
penyangga.
Operator Melihat Pupuk Aktor harus dapat menambah

34. Gudang Keluar Gudang data pupuk keluar Gudang
Penyangga Penyangga penyangga dengan data yang
SIDP_F_S_036 harus dimasukan nomor
pengiriman, jenis pupuk, nama
distributor, nomor plat, nama
supir, nama distributor.
27

SIDP_F_D_037 stok keluar masuk Gudang
penyengga
stok keluar masuk Gudang
Melihat Stok penyengga dengan rincian data
Operator Keluar Masuk stok masuk (nomor pengiriman,
35. transporter, nama supir, jenis
Diswil 1 Gudang
Penyangga pupuk, qty diterima, Gudang
SIDP_F_S_037
penyangga, tanggal pengiriman)
dan stok keluar (nomor
pengiriman, distributor, nama
supir, jenis pupuk, qty keluar,
Gudang penyangga, tanggal
pengiriman)
Aktor harus dapat validasi hasil
SIDP_F_D_038
stok opname.
Aktor harus dapat validasi hasil
Operator stok opname dengan rincian data
Validasi Hasil
36. Gudang yaitu kode Gudang penyangga,
Stok Opname
Penyangga SIDP_F_S_038 nama kepala Gudang, nama
petugas stok opname, jenis
pupuk, stok hasil stok opname,
Aktor harus dapat mengubah
SIDP_F_D_039
status keberangkatan pupuk.
Aktor harus dapat mengubah
status keberangkatan pupuk
Operator Mengubah dengan rincian data yaitu nomor
37. Gudang Status pengiriman, jenis pupuk, quantity
Pusat Keberangkatan SIDP_F_S_039 angkut, tujuan, batas waktu
pengantaran, nama transporter,
plat nomor, nama supir.
Dilengkapi dengan tombol ubah
status keberangkatan.
Melihat Total Aktor harus dapat melihat total

Kehilangan SIDP_F_D_040 kehilangan pupuk saat
Operator
Pupuk Saat pengiriman.
38. Rekanan
Transportir Pengiriman Aktor harus dapat melihat total
SIDP_F_S_040 kehilangan pupuk saat
pengiriman dengan rincian data
28
nomor pengiriman, tanggal

pengiriman, nama supir, plat
nomor, tujuan Gudang
penyangga, qty hilang, total qty
hilang.
4.5 Kebutuhan Non-Fungsional

Kebutuhan non-fungsional merupakan daftar kebutuhan-kebutuhan yang
berkaitan dengan kualitas dan batasan yang dimiliki system. Kebutuhan non-
fungsional yang harus dimiliki Sistem Aplikasi Manajemen Distribusi Pupuk PT.
Petrokimia Gresik dijabarkan dalam bentuk Tabel 4.3
Tabel 0.30.3 Kebutuhan Non-Fungsional
No Kode Parameter Deskripsi Kebutuhan
1. SIDP_NF_01 Compatibility Sistem harus dapat berjalan pada semua
web browser modern.
2. SIDP_NF_02 Performance Sistem harus dapat merespon
permintaan kurang dari 5 detik.
4.6 Diagram Use Case

Diagram use case merupakan suatu diagram yang memodelkan perilaku
dari actor terhadap system, mengembarkan apa saja yang dapat dilakukan oleh
actor terhadapat system. Actor yang terdapat dalam Sistem Aplikasi Manajemen
Distribusi Pupuk PT. Petrokimia Gresik ini ada 7 aktor. Perilaku dari masing-masing
actor digambarkan dalam bentuk diagram use case seperti pada gambar 4.1
29
Gambar 4.1 Diagram Use Case Commented [F10]: Pake tool apa ini? Berantakan sekali.
Gunakan visual paradigm, atau EA
30
4.7 Skenario Use Case
Skenario use case merupakan uraian dari alur kegiatan yang terjadi saat
pengguna menggunakan system dan diketegorikan menurut use case yang telah
dibuat. Scenario use case dijabarkan dengan menggunakan table yang terdiri dari
actor, objective, pre-condition, main flow, altenative flow, dan post-condition.
Terdapat Tiga Puluh Sembilan scenario use case yang akan dijabarkan pada table
4.7.1 sampai dengan table 4.7.38
Tabel 4.7.1 Skenario Use Case Melihat Jenis Pupuk
Aktor Operator Diswil 1
Objective Melihat Data Jenis Pupuk
Pre-Condition Aktor harus sudah masuk pada sistem dengan cara
login
Main Flow 1. Aktor memilih menu jenis pupuk
2. Sistem menampilkan Daftar Jenis Pupuk
Alternatif Sistem memunculkan pemberitahuan data gagal diload
Flow
Post- Sistem menampilkan halaman daftar jenis pupuk
Condition
Tabel 4.7.2 Skenario Use Case Menambah Jenis Pupuk

Objective Menambah Jenis Pupuk
login, dan sudah pada menu jenis pupuk
Main Flow 1. Aktor menekan tombol tambah jenis pupuk
2. Sistem menampilkan form pengisian jenis pupuk
3. Aktor memasukkan data yang diperlukan yaitu,
nama pupuk, berat per kemasan
4. Aktor menekan tombol save Commented [F11]: Paham salah nya dimana? Cek lagi
Alternatif 2.1 Apabila aktor memilih membatalkan dengan

Flow menekan tombol “x” maka sistem akan menutup form
pengisian jenis pupuk dan kembali ke menu jenis
pupuk.
4.1 Apabila aktor tidak mengisi salah satu data maka
akan menampilkan pemberitahuan untuk mengisi
semua form.
31
Post- Sistem menampilkan pesan berhasil, dan jenis pupuk
Condition telah tertambah pada tabel
Tabel 4.7.3 Skenario Use Case Mengubah Jenis Pupuk

Objective Mengubah Data Jenis Pupuk
Main Flow 1. Aktor menekan tombol ubah jenis pupuk pada
kolom aksi di tabel jenis pupuk
dengan data pupuk yang dipilih
3. Aktor mengubah data jenis pupuk jika ada yang
diperlukan yaitu, nama pupuk, berat per kemasan Commented [F12]: salah
4. Aktor menekan tombol save changes

pengisian ubah jenis pupuk dan kembali ke menu jenis
pupuk.
Condition telah terubah pada data yang diinginkan
Tabel 4.7.4 Skenario Use Case Melihat Data Rekanan Transportir

Objective Melihat Data Rekanan Transportir
login
Main Flow 5. 1. Aktor memilih menu rekanan transporter
Alternatif -
Flow
Post- Menampilkan halaman daftar rekanan transportir
Condition
Tabel 4.7.5 Skenario Use Case Menambah Rekanan Transportir

Objective Menambah Rekanan Transportir
32
login, dan sudah pada menu rekanan transportir
Main Flow 1. Aktor menekan tombol tambah rekanan transportir
pada halaman transportir
2. Sistem menampilkan form penambahan Rekanan
Transportir
3. Aktor mengisi form dengan data rekanan
transportir yaitu, nama rekanan, daftar gudang
penyangga, username, password
4. Aktor menekan tombol save
pengisian rekanan transportir dan kembali ke menu
rekanan transportir.
semua form.
Post- Sistem menampilkan pesan berhasil, dan rekanan
Condition transportir telah bertambah
Tabel 4.7.6 Skenario Use Case Mengubah Rekanan Transportir

Objective Mengubah Rekanan Transportir
Main Flow 1. Aktor menekan tombol ubah rekanan transportir
pada kolom aksi di tabel rekanan trasnportir yang
akan diubah
2. Sistem menampilkan form untuk mengubah data
rekanan transportir yang diinginkan
3. Aktor menambahkan data rekanan transportir
yaitu, nama rekanan, daftar gudang penyangga,
username, password
pengisian ubah jenis pupuk dan kembali ke menu jenis
pupuk.
33
Tabel 4.7.7 Skenario Use Case Melihat Batas Stok Kritis

Objective Melihat Data Batas Stok Kritis
login
Main Flow 6. Aktor memilih menu batas stok kritis pada sistem
Alternatif -
Flow
Post- Sistem menampilkan halaman daftar batas stok kritis
Condition
Tabel 4.7.8 Skenario Use Case Menambah Batas Stok Kritis

Objective Menambah Data Batas Stok Kritis
login, dan sudah pada menu batas stok kritis
Main Flow 1. Aktor menekan tombol tambah pada halaman
batas stok kritis
2. Sistem menampilkan form penambahan Batas Stok
Kritis
3. Aktor mengisikan data batas stok kritis yaitu, nama
daerah, jenis pupuk, dan qty batas stok kritis
pengisian batas stok kritis dan kembali ke menu batas
stok kritis.
semua form.
Post- Sistem menampilkan pesan berhasil, dan batas stok
Condition kritis telah ditambahkan
34
Tabel 4.7.9 Skenario Use Case Mengubah Batas Stok Kritis
Objective Mengubah Data Batas Stok Kritis
Main Flow 1. Aktor menekan tombol ubah batas stok kritis pada
kolom aksi di tabel batas stok kritis yang akan
diubah
Kritis
3. Aktor menambahkan data batas stok kritis yaitu,
nama daerah, jenis pupuk, dan qty batas stok kritis
pengisian batas stok kritis dan kembali ke menu batas
stok kritis.
Condition kritis telah terubah pada data yang diinginkan
Tabel 4.7.10 Skenario Use Case Melihat Rekanan Pengelola Gudang

Penyangga
Objective Melihat Data Rekanan Pengelola Gudang Penyangga
login
Main Flow 7. Aktor memilih menu rekanan pengelola gudang
penyangga
Alternatif -
Flow
Post- Sistem menampilkan halaman daftar rekanan
Condition pengelola gudang penyangga
Tabel 4.7.11 Skenario Use Case Menambah Rekanan Pengelola Gudang

Penyangga
35
Objective Menambah Data Rekanan Pengelola Gudang
Penyangga
login, dan sudah pada menu rekanan pengelola gudang
penyangga
rekanan pengelola gudang penyangga
Pengelola Gudang Penyangga
3. Aktor mengisikan data rekanan pengelola gudang
penyangga yaitu, nama rekanan, daftar gudang
penyangga yang dikelola, username, dan password.
pengisian rekanan pengelola gudang penyangga dan
kembali ke menu rekanan pengelola gudang
penyangga.
semua form.
Condition pengelola gudang penyangga telah ditambahkan
Tabel 4.7.12 Skenario Use Case Mengubah Rekanan Pengelola Gudang

Penyangga
Objective Mengubah Data Rekanan Pengelola Gudang
Penyangga
penyangga
Main Flow 1. Aktor menekan tombol ubah rekanan pengelola
gudang penyangga pada kolom aksi di tabel
rekanan pengelola gudang penyangga yang akan
diubah
2. Sistem menampilkan form pengubahan data
rekanan pengelola yang diinginkan
36
3. Aktor menambahkan data rekanan pengelola
gudang penyangga yaitu, nama rekanan, daftar
gudang penyangga yang dikelola, username, dan
password
pengisian rekanan pengelola gudang penyangga dan
kembali ke menu rekanan pengelola gudang
penyangga.
Condition pengelola gudang penyangga telah terubah pada data
yang diinginkan
Tabel 4.7.13 Skenario Use Case Melihat Gudang Penyangga

Objective Melihat Melihat Data Gudang Penyangga
login
Main Flow 8. Aktor memilih menu gudang penyangga
Alternatif -
Flow
Post- Sistem menampilkan halaman daftar Data Gudang
Condition Penyangga
Tabel 4.7.14 Skenario Use Case Menambah Gudang Penyangga

Objective Menambah Data Gudang Penyangga
login, dan sudah pada menu rekanan gudang
penyangga
gudang penyangga
2. Sistem menampilkan form penambahan gudang
penyangga
3. Aktor mengisikan data gudang penyangga yaitu,
kode gudang penyangga, alamat, daya tampung
37
gudang, pengelola, nama kepala Gudang, kontak,
pengisian gudang penyangga dan kembali ke menu
gudang penyangga.
semua form.
Condition gudang penyangga telah ditambahkan
Tabel 4.7.15 Skenario Use Case Mengubah Gudang Penyangga

Objective Mengubah Data Gudang Penyangga
login, dan sudah pada menu data Gudang penyangga
Main Flow 1. Aktor menekan tombol ubah data Gudang
penyangga pada kolom aksi di tabel data Gudang
penyangga yang akan diubah
2. Sistem menampilakan form pengubahan data
Gudang Penyangga yang diinginkan
3. Aktor mengubah data Gudang penyangga yaitu,
kode Gudang penyangga, alamat, daya tampung
Gudang, pengelola, nama kepala Gudang, kontak,
pengisian gudang penyangga dan kembali ke menu
gudang penyangga.
Post- Sistem menampilkan pesan berhasil, dan data Gudang
Condition penyangga telah berhasil diubah
Tabel 4.7.16 Skenario Use Case Melihat Petugas Stok Opname

Objective Melihat data petugas stok opname
38
login.
Main Flow 9. Aktor memilih menu petugas stok opname.
Alternatif -
Flow
Post- Sistem menampilkan pesan berhasil, dan data petugas
Condition stok opname berhasil ditampilkan.
Tabel 4.7.17 Skenario Use Case Menambah Petugas Stok Opname

Objective Menambah Data Petugas Stok Opname
login, dan sudah pada menu petugas stok opname.
petugas stok opname.
2. Sistem menampilkan form penambahan data
petugas stok opname
3. Aktor mengisikan data petugas stok opname yaitu,
kode tim, nama petugas 1, nama petugas 2,
pengisian petugas stok opname dan kembali ke menu
semua form.
Condition stok opname berhasil ditambahkan.
Tabel 4.7.18 Skenario Use Case Mengubah Petugas Stok Opname

Objective Mengubah Data Petugas Stok Opname
login, dan sudah pada menu petugas stok opname
39
Main Flow 1. Aktor menekan tombol ubah data petugas stok
opname pada kolom aksi di tabel petugas stok
opname yang akan diubah
Petugas Stok Opname yang diinginkan
3. Aktor mengubah data petugas stok opname yaitu,
pengisian petugas stok opname dan kembali ke menu
Post- Siste menampilkan pesan berhasil, dan data petugas
Condition stok opname berhasil diubah.
Tabel 4.7.19 Skenario Use Case Membuat Penugasan Stok Opname

Objective Membuat penugasan stok opname
login, dan sudah pada menu penugasan stok opname.
Main Flow 1. Aktor menekan tombol buat penugasan pada
halaman penugasan stok opname.
2. Sistem menampilkan form penambahan Penugasan
Stok Opname.
3. Aktor menambahkan data penugasan stok opname
yaitu, kode tim, kode Gudang penyangga, dan
tanggal berangkat.
pengisian penugasan stok opname dan kembali ke
menu penugasan stok opname.
semua form.
Post- Sistem menampilkan pesan berhasil, dan data
Condition penugasan stok opname berhasil dibuat.
40
Tabel 4.7.20 Skenario Use Case Melihat Penugasan Stok Opname
Aktor Operator Diswil 1, Operator Stok Opname.
Objective Melihat penugasan stok opname.
login
Main Flow 10. Aktor memilih menu penugasan stok opname
Alternatif -
Flow
Post- Sistem menampilkan halaman melihat penugasan stok
Condition opname.
Tabel 4.7.21 Skenario Use Case Membuat Permintaan Pengiriman Pupuk

Objective Membuat permintaan pengiriman pupuk
login, dan sudah pada menu pengiriman pupuk.
Main Flow 11. Aktor menekan tombol buat permintaan pada
halaman pengiriman pupuk.
12. Sistem menampilkan form penambahan
Permintaan Pengiriman Pupuk
13. Aktor mengisikan data permintaan pengiriman
pupuk yaitu, no pengiriman, jenis pupuk, quantity,
pengisian permintaan pengiriman pupuk dan kembali
ke menu permintaan pengiriman pupuk.
semua form.
Post- Sisitem menampilkan pesan berhasil, dan data
Condition permintaan pengiriman pupuk berhasil dibuat.
Tabel 4.7.22 Skenario Use Case Melihat Permintaan Pengiriman Pupuk

Aktor Operator Diswil 1, Operator Gudang Pusat, Operator
Gudang Penyangga, Operator Rekanan Transportir.
Objective Melihat Permintaan Pengiriman Pupuk
41
login
Main Flow 15. Aktor memilih menu permintaan pengiriman pupuk
Alternatif -
Flow
Post- Sistem menampilkan daftar permintaan pengiriman
Condition pupuk di halaman permintaan pengiriman pupuk.
Tabel 4.7.23 Skenario Use Case Mengisi Detail Permintaan Pengiriman

Pupuk
Aktor Operator Rekanan Transportir
Objective Mengisi detail permintaan pengiriman pupuk
login, dan sudah pada menu permintaan pupuk.
Main Flow 1. Aktor menekan tombol respon permintaan pada
halaman permintaan pupuk.
2. Sistem menampilkan form penambahan Detail
3. Aktor menambahkan detail permintaan pengiriman
pupuk yaitu plat nomor kendaraan pengangkut,
nama supir, qty angkut tiap kendaraan, tanggal
pengambilan pupuk.
pengisian detail permintaan pengiriman pupuk dan
kembali ke menu permintaan pengiriman pupuk.
semua form.
Post- Sistem menampilkan pesan berhasil, dan data detail
Tabel 4.7.24 Skenario Use Case Melihat Daftar Pupuk yang Hilang di
Gudang Penyangga
Aktor Operator Rekanan Gudang Penyangga.
Objective Melihat daftar pupuk yang hilang di Gudang Penyangga
42
login
Main Flow 16. Aktor memilih menu pupuk hilang
Alternatif -
Flow
Post- Sistem menampilkan data pupuk yang hilang digudang
Condition penyangga pada halaman pupuk hilang
Tabel 4.7.25 Skenario Use Case Melihat Hasil Stok Opname yang Sudah
Divalidasi
Aktor Operator Rekanan Gudang Penyangga, Operator Stok
Opname Diswil 1, Manager Diswil 1.
Objective Melihat Hasil Stok Opname yang Sudah Divalidasi.
login
Main Flow 17. 1. Aktor memilih menu stok opname selesai
Alternatif -
Flow
Post- Sistem menampilkan data hasil stok opname yang
Condition sudah divalidasi pada halaman stok opname selesai
Tabel 4.7.26 Skenario Use Case Membuat Perhitungan Stok Opname

Aktor Operator Stok Opname Diswil 1
Objective Membuat perhitungan stok opname
login, dan sudah pada menu stok opname.
Main Flow 1. Aktor menekan tombol buat perhitungan pada
halaman stok opname.
Perhitungan Stok Opname
3. Sistem secara otomatis mengunci fitur pupuk
keluar dan pupuk masuk.
4. Aktor mengisikan data perhitungan stok opname
yaitu tanggal, jam, kode Gudang penyangga, jenis
pupuk, berat kemasan, area, kunci, Panjang, lebar,
tinggi, jumlah bag, jumlah ton, lebihan bag, lebihan
ton, total bag, total ton.
43
5. Aktor menekan tombol selesai
perhitungan stok opname dan kembali ke menu hitung
stok opname.
semua form.
Condition perhitungan stok opname berhasil dibuat.
Tabel 4.7.27 Skenario Use Case Melihat Perhitungan Stok Opname

Aktor Operator Stok Opname Diswil 1, Operator Gudang
Penyangga.
Objective Melihat Perhitungan Stok Opname.
login.
Main Flow 18. Aktor memilih menu perhitungan stok opname.
Alternatif -
Flow
Post- Sistem menampilkan data perhitungan stok opname
Condition pada halaman perhituangan stok opname.
Tabel 4.7.28 Skenario Use Case Melihat Hasil Stok Opname

Aktor Operator Gudang Penyangga, Operator Stok Opname
Diswil 1.
Objective Melihat Hasil Stok Opname.
login.
Main Flow 1. Aktor memilih menu hasil stok opname.
Alternatif -
Flow
Post- Sistem menampilkan data hasil stok opname pada
Condition halaman hasil stok opname.
Tabel 4.7.29 Skenario Use Case Melihat Peta Kondisi Stok

Aktor Operator Diswil 1, Manager Diswil 1
44
Objective Melihat Peta Kondisi Stok.
login.
Main Flow 19. Aktor memilih menu peta stok.
Alternatif Sistem menampilkan pesan error saat data tidak bisa
Flow ditampilkan
Post- Sistem menampilkan peta kondisi stok pada halaman
Condition peta stok.
Tabel 4.7.30 Skenario Use Case Membuat Laporan Pupuk Rusak

Aktor Operator Gudang Penyangga
Objective Membuat Laporan Pupuk Rusak
login, dan sudah pada menu pupuk rusak.
Main Flow 1. Aktor menekan tombol lapor pupuk rusak pada
halaman pupuk rusak.
2. Sistem menampilkan form penambahan Pupuk
Rusak
3. Aktor menambahkan data laporan pupuk rusak
yaitu jenis pupuk, qty, kemasan, foto, alasan
kerusakan pupuk.
laporan pupuk rusak dan kembali ke menu pupuk
rusak.
semua form.
Post- Menampilkan pesan berhasil, dan data laporan pupuk
Condition rusak berhasil dibuat.
Tabel 4.7.31 Skenario Use Case Melihat Laporan Pupuk Rusak

Aktor Operator Gudang Penyangga, Operator Diswil 1.
Objective Melihat Laporan Pupuk Rusak.
login.
45
Main Flow 20. Aktor memilih menu pupuk rusak.
Alternatif -
Flow
Post- Sistem menampilkan daftar laporan pupuk rusak pada
Condition halaman pupuk rusak
Tabel 4.7.32 Skenario Use Case Validasi Penerimaan Pupuk

Aktor Operator Gudang Penyangga.
Objective Validasi penerimaan pupuk.
login dan sudah pada menu permintaan pupuk.
Main Flow 1. Aktor memilih tombol pupuk diterima.
2. Sistem menampilkan form Validasi Penerimaan
Pupuk dengan data pupuk yang diinginkan
3. Aktor mengisi data validasi data penerimaan pupuk
yaitu qty diterima.
validasi penerimaan pupuk dan kembali ke menu
penerimaan pupuk.
semua form.
Post- Sistem menampilkan pesan berhasil, dan status
Condition pengiriman pupuk yang diinginkan berubah menjadi
diterima.
Tabel 4.7.33 Skenario Use Case Menambah Pupuk Keluar Gudang

Penyangga
login, dan sudah pada menu pupuk.
Main Flow 21. Aktor menekan tombol tambah pupuk keluar
Keluar
46
23. Aktor mengisi data pupuk keluar yaitu nomor
pengiriman, jenis pupuk, nama distributor, nomor
plat, nama supir, nama distributor.
pupuk keluar dan kembali ke menu pupuk keluar.
semua form.
Post- Sistem menampilkan pesan berhasil, dan data pupuk
Condition keluar berhasil ditambahkan.
Tabel 4.7.34 Skenario Use Case Melihat Pupuk Keluar Gudang Penyangga
Objective Melihat Laporan Pupuk Rusak
login.
Main Flow 1. Aktor menekan menu pupuk
Alternatif -
Flow
Condition keluar berhasil ditampilkan.
Tabel 4.7.35 Skenario Use Case Melihat Stok Keluar Masuk Gudang
Penyangga.
Objective Melihat Data Stok Keluar Masuk Gudang Penyangga
login.
Main Flow 2. Aktor menekan menu lalu-lintas stok
3. Sistem menampilkan daftar gudang penayangga
4. Memilih Gudang penyangga yang akan dilihat
Alternatif -
Flow
Post- Sistem menampilkan data stok keluar masuk Gudang
Condition Penyangga yang diinginkan.
47
Tabel 4.7.36 Skenario Use Case Validasi Hasil Stok Opname
Objective Validasi hasil stok opname.
login dan sudah pada menu hasil stok opname.
Main Flow 25. Aktor memilih hasil stok opname yang akan
divalidasi.
26. Sistem menampilkan form Validasi Hasil Stok
opname yang diinginkan
27. Aktor menekan tombol validasi.
validasi hasil stok opname dan kembali ke menu hasil
stok opname.
Post- Sistem menampilkan pesan berhasil, dan status stok
Condition opname yang diinginkan berubah menjadi tervalidasi
selesai.
Tabel 4.7.37 Skenario Use Case Mengubah Status Keberangkatan

Aktor Operator Gudang Pusat.
Objective Mengubah status keberangkatan.
Pre-Condition Actor harus sudah masuk pada sistem dengan cara
Main Flow 1. Aktor menekan tombol ubah status keberangkatan
pada perminataan pupuk yang ingin diubah
2. Sistem menampilkan form pengubahan Status
Keberangkatan.
3. Aktor mengisi data yang ingin diubah.
4. Actor menekan tombol save
status keberangkatan dan kembali ke menu
permintaan pupuk.
semua form.
48
Condition permintaan pengiriman pupuk yang diinginkan
berubah menjadi berangkat dari Gudang pusat.
Tabel 4.7.38 Skenario Use Case Melihat Total Kehilangan Pupuk Saat
Pengiriman
Aktor Operator Rekanan Transportir.
Objective Melihat total kehilangan pupuk saat pengiriman
login
Main Flow 28. Aktor memilih menu kehilangan pupuk
Alternatif -
Flow
Post- Sistem berhasil menampilkan data kehilangan pupuk
Condition oleh transportir pada halaman kehilangan pupuk
Formatted: Indent: First line: 0"
Tabel 4.7.1 Skenario Use Case Melihat Jenis Pupuk

Objective Melihat Data Jenis Pupuk
login
Main Flow 1. Aktor memilih menu jenis pupuk
2. Sistem menampilkan Daftar Jenis Pupuk
Alternatif Sistem mengarahkan pada halaman login, dikarenakan
Flow belum melakukan authentikasimemunculkan
pemberitahuan data gagal diload
Post- Sistem menampilkan halaman daftar jenis pupuk
Condition
Tabel 4.7.2 Skenario Use Case Menambah Jenis Pupuk

Objective Menambah Jenis Pupuk
Main Flow 1. Aktor menekan tombol tambah jenis pupuk
49
3. Aktor memasukkan data yang diperlukan yaitu,
Alternatif Sistem menampilkan pesan error saat proses
Flow penyimpanan
Condition telah masuk pada tabel
Formatted: Left
Tabel 4.7.3 Skenario Use Case Mengubah Jenis Pupuk

Objective Mengubah Data Jenis Pupuk
Main Flow 1. Aktor menekan tombol ubah jenis pupuk pada
kolom aksi di tabel jenis pupuk
dengan data pupuk yang dipilih
3. Aktor mengubah data jenis pupuk jika ada yang
diperlukan yaitu, nama pupuk, berat per kemasan
Flow penyimpanan
Tabel 4.7.4 Skenario Use Case Menampilkan Rekanan Transportir

Objective Melihat Data Rekanan Transportir
login
Main Flow 3. Aktor memilih menu rekanan transporter
Alternatif Menampiklan halaman login, jika belum melakukan
Flow proses authentikasi
50
Post- Menampilkan halaman daftar rekanan transportir
Condition
Tabel 4.7.5 Skenario Use Case Menambah Rekanan Transportir

Objective Menambah Rekanan Transportir
Main Flow 1. Aktor menekan tombol tambah rekanan transportir
pada halaman transportir
Transportir
3. Aktor mengisi form dengan data rekanan
transportir yaitu, nama rekanan, daftar gudang
penyangga, username, password
Flow penyimpanan
Condition transportir telah bertambah
Tabel 4.7.6 Skenario Use Case Mengubah Rekanan Transportir

Objective Mengubah Rekanan Transportir
Main Flow 1. Aktor menekan tombol ubah rekanan transportir
pada kolom aksi di tabel rekanan trasnportir yang
akan diubah
3. Aktor menambahkan data rekanan transportir
yaitu, nama rekanan, daftar gudang penyangga,
username, password
Flow penyimpanan
51
Tabel 4.7.7 Skenario Use Case Melihat Batas Stok Kritis

Objective Melihat Data Batas Stok Kritis
login
Main Flow 1. Aktor memilih menu batas stok kritis pada sistem
Alternatif Sistem menampilkan halaman login, ketika belum
Flow melakukan proses authentikasi
Post- Sistem menampilkan halaman daftar batas stok kritis
Condition
Tabel 4.7.8 Skenario Use Case Menambah Batas Stok Kritis

Objective Menambah Data Batas Stok Kritis
batas stok kritis
Kritis
Flow penyimpanan
Condition kritis telah ditambahkan
Tabel 4.7.9 Skenario Use Case Mengubah Batas Stok Kritis

Objective Mengubah Data Batas Stok Kritis
52
Main Flow 1. Aktor menekan tombol ubah batas stok kritis pada
kolom aksi di tabel batas stok kritis yang akan
diubah
Kritis
Flow penyimpanan
Condition kritis telah terubah pada data yang diinginkan
Tabel 4.7.10 Skenario Use Case Melihat Rekanan Pengelola Gudang

Penyangga
Objective Melihat Data Rekanan Pengelola Gudang Penyangga
login
Main Flow 1. Aktor memilih menu rekanan pengelola gudang
penyangga
Flow penyimpanan
Post- Sistem menampilkan halaman daftar rekanan
Condition pengelola gudang penyangga
Tabel 4.7.11 Skenario Use Case Menambah Rekanan Pengelola Gudang

Penyangga
Objective Menambah Data Rekanan Pengelola Gudang
Penyangga
penyangga
53
Flow penyimpanan
Condition pengelola gudang penyangga telah ditambahkan
Tabel 4.7.12 Skenario Use Case Mengubah Rekanan Pengelola Gudang

Penyangga
Objective Mengubah Data Rekanan Pengelola Gudang
Penyangga
penyangga
Main Flow 1. Aktor menekan tombol ubah rekanan pengelola
gudang penyangga pada kolom aksi di tabel
rekanan pengelola gudang penyangga yang akan
diubah
rekanan pengelola yang diinginkan
3. Aktor menambahkan data rekanan pengelola
gudang penyangga yaitu, nama rekanan, daftar
gudang penyangga yang dikelola, username, dan
password
Flow penyimpanan
Condition pengelola gudang penyangga telah terubah pada data
yang diinginkan
Tabel 4.7.13 Skenario Use Case Melihat Gudang Penyangga

54
Objective Melihat Melihat Data Gudang Penyangga
login
Main Flow 1. Aktor memilih menu gudang penyangga
Flow penyimpanan
Post- Sistem menampilkan halaman daftar Data Gudang
Condition Penyangga
Tabel 4.7.14 Skenario Use Case Menambah Gudang Penyangga

Objective Menambah Data Gudang Penyangga
login, dan sudah pada menu rekanan gudang
penyangga
gudang penyangga
penyangga
3. Aktor mengisikan data gudang penyangga yaitu,
kode gudang penyangga, alamat, daya tampung
gudang, pengelola, nama kepala Gudang, kontak,
Flow penyimpanan
Condition gudang penyangga telah ditambahkan
Tabel 4.7.15 Skenario Use Case Mengubah Gudang Penyangga

Objective Mengubah Data Gudang Penyangga
login, dan sudah pada menu data Gudang penyangga
Main Flow 1. Aktor menekan tombol ubah data Gudang
penyangga pada kolom aksi di tabel data Gudang
penyangga yang akan diubah
55
2. Sistem menampilakan form pengubahan data
Gudang Penyangga yang diinginkan
3. Aktor mengubah data Gudang penyangga yaitu,
kode Gudang penyangga, alamat, daya tampung
Gudang, pengelola, nama kepala Gudang, kontak,
Flow penyimpanan
Post- Sistem menampilkan pesan berhasil, dan data Gudang
Condition penyangga telah berhasil diubah
Tabel 4.7.16 Skenario Use Case Melihat Petugas Stok Opname

Objective Melihat data petugas stok opname
login.
Main Flow 1. Aktor memilih menu petugas stok opname.
Flow menampilkan
Condition stok opname berhasil ditampilkan.
Tabel 4.7.17 Skenario Use Case Menambah Petugas Stok Opname

Objective Menambah Data Petugas Stok Opname
login, dan sudah pada menu petugas stok opname.
2. Sistem menampilkan form penambahan data
petugas stok opname
56
Flow penyimpanan
Condition stok opname berhasil ditambahkan.
Tabel 4.7.18 Skenario Use Case Mengubah Petugas Stok Opname

Objective Mengubah Data Petugas Stok Opname
login, dan sudah pada menu petugas stok opname
Main Flow 1. Aktor menekan tombol ubah data petugas stok
opname pada kolom aksi di tabel petugas stok
opname yang akan diubah
Petugas Stok Opname yang diinginkan
Flow penyimpanan
Post- Siste menampilkan pesan berhasil, dan data petugas
Condition stok opname berhasil diubah.
Tabel 4.7.19 Skenario Use Case Membuat Penugasan Stok Opname

Objective Membuat penugasan stok opname
login, dan sudah pada menu penugasan stok opname.
Main Flow 1. Aktor menekan tombol buat penugasan pada
halaman penugasan stok opname.
2. Sistem menampilkan form penambahan Penugasan
Stok Opname.
yaitu, kode tim, kode Gudang penyangga, dan
tanggal berangkat.
57
Flow penyimpanan
Condition penugasan stok opname berhasil dibuat.
Tabel 4.7.20 Skenario Use Case Melihat Penugasan Stok Opname

Aktor Operator Diswil 1, Operator Stok Opname.
Objective Melihat penugasan stok opname.
login
Main Flow 1. Aktor memilih menu penugasan stok opname
Flow penyimpanan
Post- Sistem menampilkan halaman melihat penugasan stok
Condition opname.
Tabel 4.7.21 Skenario Use Case Membuat Permintaan Pengiriman Pupuk

Objective Membuat permintaan pengiriman pupuk
login, dan sudah pada menu pengiriman pupuk.
Main Flow 1. Aktor menekan tombol buat permintaan pada
Flow penyimpanan
Post- Sisitem menampilkan pesan berhasil, dan data
Tabel 4.7.22 Skenario Use Case Melihat Permintaan Pengiriman Pupuk

Aktor Operator Diswil 1, Operator Gudang Pusat, Operator
Gudang Penyangga, Operator Rekanan Transportir.
Objective Melihat Permintaan Pengiriman Pupuk
58
login
Main Flow 1. Aktor memilih menu permintaan pengiriman pupuk
Flow penyimpanan
Post- Sistem menampilkan daftar permintaan pengiriman
Condition pupuk di halaman permintaan pengiriman pupuk.
Tabel 4.7.23 Skenario Use Case Mengisi Detail Permintaan Pengiriman

Pupuk
Aktor Operator Rekanan Transportir
Objective Mengisi detail permintaan pengiriman pupuk
login, dan sudah pada menu permintaan pupuk.
Main Flow 1. Aktor menekan tombol respon permintaan pada
pengambilan pupuk.
Flow penyimpanan
Post- Sistem menampilkan pesan berhasil, dan data detail
Tabel 4.7.24 Skenario Use Case Melihat Daftar Pupuk yang Hilang di
Gudang Penyangga
Aktor Operator Rekanan Gudang Penyangga.
Objective Melihat daftar pupuk yang hilang di Gudang Penyangga
login
Main Flow 1. Aktor memilih menu pupuk hilang
Flow penyimpanan
59
Post- Sistem menampilkan data pupuk yang hilang digudang
Condition penyangga pada halaman pupuk hilang
Tabel 4.7.25 Skenario Use Case Melihat Hasil Stok Opname yang Sudah
Divalidasi
Aktor Operator Rekanan Gudang Penyangga, Operator Stok
Opname Diswil 1, Manager Diswil 1.
Objective Melihat Hasil Stok Opname yang Sudah Divalidasi.
Pre-Condition 1. Aktor harus sudah masuk pada sistem dengan cara
login
Main Flow 2. Aktor memilih menu stok opname selesai
Alternatif Siste menampilkan pesan error saat proses
Flow penyimpanan
Post- Sistem menampilkan data hasil stok opname yang
Condition sudah divalidasi pada halaman stok opname selesai
Tabel 4.7.26 Skenario Use Case Membuat Perhitungan Stok Opname

Aktor Operator Stok Opname Diswil 1
Objective Membuat perhitungan stok opname
login, dan sudah pada menu stok opname.
Main Flow 1. Aktor menekan tombol buat perhitungan pada
Perhitungan Stok Opname
3. Sistem secara otomatis mengunci fitur pupuk
keluar dan pupuk masuk.
tinggi, jumlah bag, jumlah ton, lebihan bag, lebihan
ton, total bag, total ton.
Flow penyimpanan
Condition perhitungan stok opname berhasil dibuat.
60
Tabel 4.7.27 Skenario Use Case Melihat Perhitungan Stok Opname
Aktor Operator Stok Opname Diswil 1, Operator Gudang
Penyangga.
Objective Melihat Perhitungan Stok Opname.
login.
Main Flow 1. Aktor memilih menu perhitungan stok opname.
Flow penyimpanan
Post- Sistem menampilkan data perhitungan stok opname
Condition pada halaman perhituangan stok opname.
Tabel 4.7.28 Skenario Use Case Melihat Hasil Stok Opname

Aktor Operator Gudang Penyangga, Operator Stok Opname
Diswil 1.
Objective Melihat Hasil Stok Opname.
login.
Main Flow 1. Aktor memilih menu hasil stok opname.
Flow penyimpanan
Post- Sistem menampilkan data hasil stok opname pada
Condition halaman hasil stok opname.
Tabel 4.7.29 Skenario Use Case Melihat Peta Kondisi Stok

Aktor Operator Diswil 1, Manager Diswil 1
Objective Melihat Peta Kondisi Stok.
login.
Main Flow 1. Aktor memilih menu peta stok.
Flow ditampilkan
Post- Sistem menampilkan peta kondisi stok pada halaman
Condition peta stok.
61
Tabel 4.7.30 Skenario Use Case Membuat Laporan Pupuk Rusak
login, dan sudah pada menu pupuk rusak.
Main Flow 1. Aktor menekan tombol lapor pupuk rusak pada
Rusak
3. Aktor menambahkan data laporan pupuk rusak
yaitu jenis pupuk, qty, kemasan, foto, alasan
kerusakan pupuk.
Alternatif Menampilkan pesan error saat proses penyimpanan
Flow
Post- Menampilkan pesan berhasil, dan data laporan pupuk
Condition rusak berhasil dibuat.
Tabel 4.7.31 Skenario Use Case Melihat Laporan Pupuk Rusak

Aktor Operator Gudang Penyangga, Operator Diswil 1.
Objective Melihat Laporan Pupuk Rusak.
login.
Main Flow 1. Aktor memilih menu pupuk rusak.
Flow ditampilkan
Post- Sistem menampilkan daftar laporan pupuk rusak pada
Condition halaman pupuk rusak
Tabel 4.7.32 Skenario Use Case Validasi Penerimaan Pupuk

Objective Validasi penerimaan pupuk.
Main Flow 1. Aktor memilih tombol pupuk diterima.
62
2. Sistem menampilkan form Validasi Penerimaan
Pupuk dengan data pupuk yang diinginkan
yaitu qty diterima.
Flow ditampilkan
Condition pengiriman pupuk yang diinginkan berubah menjadi
diterima.
Tabel 4.7.33 Skenario Use Case Menambah Pupuk Keluar Gudang

Penyangga
login, dan sudah pada menu pupuk.
Main Flow 2. Aktor menekan tombol tambah pupuk keluar
Keluar
Flow penyimpanan
Condition keluar berhasil ditambahkan.
Tabel 4.7.34 Skenario Use Case Melihat Pupuk Keluar Gudang Penyangga
Objective Melihat Laporan Pupuk Rusak
login.
Main Flow 1. Aktor menekan menu pupuk
Flow pengambilan data.
Condition keluar berhasil ditampilkan.
63
Tabel 4.7.35 Skenario Use Case Melihat Stok Keluar Masuk Gudang
Penyangga.
Objective Melihat Data Stok Keluar Masuk Gudang Penyangga
login.
Main Flow 1. Aktor menekan menu lalu-lintas stok
Flow pengambilan data.
Post- Sistem menampilkan data stok keluar masuk Gudang
Condition Penyangga yang diinginkan.
Tabel 4.7.36 Skenario Use Case Validasi Hasil Stok Opname

Objective Validasi hasil stok opname.
login dan sudah pada menu hasil stok opname.
Main Flow 1. Aktor memilih hasil stok opname yang akan
divalidasi.
2. Sistem menampilkan form Validasi Hasil Stok
opname yang diinginkan
Flow ditampilkan
Post- Sistem menampilkan pesan berhasil, dan status stok
Condition opname yang diinginkan berubah menjadi tervalidasi
selesai.
Tabel 4.7.37 Skenario Use Case Mengubah Status Keberangkatan

Aktor Operator Gudang Pusat.
Objective Mengubah status keberangkatan.
Main Flow 1. Aktor menekan tombol ubah status keberangkatan
64
Keberangkatan.
Flow ditampilkan
Condition permintaan pengiriman pupuk yang diinginkan
berubah menjadi berangkat dari Gudang pusat.
Tabel 4.7.38 Skenario Use Case Melihat Total Kehilangan Pupuk Saat
Pengiriman
Aktor Operator Rekanan Transportir.
Objective Melihat total kehilangan pupuk saat pengiriman
login
Main Flow 1. Aktor memilih menu kehilangan pupuk
Flow ditampilkan
Post- Sistem berhasil menampilkan data kehilangan pupuk
Condition oleh transportir pada halaman kehilangan pupuk
65
BAB 5 PERANCANGAN
Pada bab ini akan dibahas tahap perancangan dari sistem Aplikasi Manajemen
distribusi pupuk. Setelah melakukan analisis kebutuhan, kemudian akan
dilanjutkan pada tahap perancangan. Perancangan sistem dilakukan dengan lima
tahap perancangan. Tahapan perancangan sistem terdiri dari perancangan
sequence diagram, perancangan class diagram, perancangan basis data,
perancangan komponen, dan perancangan antarmuka.
5.1 Perancangan Sequence Diagram

Sequence diagram merupakan representasi dari alur jalannya sebuah interaksi
yang terjadi antar objek pada sistem. Seluruh objek yang terdapat pada sequence
diagram diperoleh dari hasil identifikasi terhadap spesifikasi kebutuhan dan use
case. Berikut merupakan tiga sequence diagram yang akan digunakan sebagai
sampel.
5.1.1 Sequence Diagram Membuat Perhitungan Stok Opname

Sequence Diagram membuat perhitungan stok opname Gambar 5.1
menggambarkan proses yang terjadi saat operator stok opname memasukkan
data stok opname. Operator stok opname harus masuk pada menu stok opname.
Setelah itu menekan tombol tambah untuk memunculkan form. Operator stok
opname diharuskan minimal mengisi setiap data yang ada dengan lengkap.
Kemudian sistem akan melakukan penyimpanan data stok opname yaitu tanggal,
daerah, dan detail stok yang sudah dihitung secara manual. Setelah data selesai
tersimpan, sistem akan kembali menampilkan halaman sotk opname untuk
melihat seluruh stok opname disertai dengan data yang baru saja di masukkan
66
Gambar 5.1 Diagram Sequence Membuat Perhitungan Stok Opname
5.1.2 Sequence Diagram Validasi Penerimaan Pupuk

Sequence Diagram validasi penerimaan pupuk pada Gambar 5.2
menggambarkan proses yang terjadi saat truk dari reknan transportir sudah
datang di gudang penyangga yang di tuju. Pada operator gudang penyangga
diharuskan masuk pada halaman validasi penerimaan pupuk. Setelah itu menekan
tombol tambah untuk memunculkan form. Operator stok opname diharuskan
minimal mengisi setiap data yang ada dengan lengkap. Kemudian sistem akan
melakukan penyimpanan data stok yang diterima di gudang penyanga yaitu qty,
dan nomot polisi truk. Pada saat proses penyimpanan sistem akan melakukan
pengubahan data request stok, perubahan data stok di gudang tersebut, dan
pertambahan log transaksi stok. Setelah data selesai tersimpan, sistem akan
kembali menampilkan halaman pupuk datang
67
Gambar 5.2 Diagram Sequence Validasi Penerimaan Pupuk
5.1.3 Sequence Diagram Menambah Stok Keluar

Diagram validasi penerimaan pupuk pada Gambar 5.3 menggambarkan
proses yang terjadi saat truk dari reknan transportir sudah datang di gudang
penyangga yang di tuju. Pada operator gudang penyangga diharuskan masuk pada
halaman stok keluar. Setelah itu menekan tombol tambah untuk memunculkan
form. Operator stok opname diharuskan minimal mengisi setiap data yang ada
dengan lengkap. Kemudian sistem akan melakukan penyimpanan data stok yang
diterima di gudang penyanga yaitu qty, jenis pupuk, nomot polisi truk, dan
distributor. Pada saat proses penyimpanan sistem akan melakukan pengubahan
68
data stok di gudang tersebut, dan pertambahan log transaksi stok. Setelah data
selesai tersimpan, sistem akan kembali menampilkan halaman stok keluar
Gambar 5.3 Diagram Sequence Menambah Stok Keluar
5.2 Perancangan Class Diagram

Perancanagan class diagram dilakukan untuk mengidentifikasi kelas, objek,
dan interaksi yang terjadi pada sistem. Kelas-kelas yang ditemukan diperoleh
dengan cara memeriksa objek yang terdapat pada sequence diagram. Class
diagram dari Ssistem Aplikasi Manajemen Ddistribusi Ppupuk PT Petrokimia
Gresik terdiri dari 15 12 kelas controller,r dan 15 kelas model dan 35 kelas view.
Class Diagram dari Ssistem Aplikasi Manajemen Ddistribusi Ppupuk diilustrasikan
pada Gambar 5.4. Sedangkan untuk detail dari kelas controller dijelaskan pada Commented [F13]: clas tidak terbaca
Gambar 5.4.1, detail kelas model pada Gambar 5.4.2 dan detail kelas view pada
Gambar 5.4.2.
69
70
Gambar 5.4 Diagram Class
Gambar 5.4.1 Detail Diagram Class Controller
71
Gambar 5.4.2 Detail Diagram Class Model
Gambar 5.4.3 Detail Diagram Class View
72
5.3 Perancangan Komponen
Perancangan komponen menggambarkan bagaimana rincian subsistem
dari masing-masing komponen yang ada pada perangkat lunak. Perancangan
komponen menjelaskan bagaimana algoritme dari sebuah proses yang terjadi
pada sistem. Pada perancangan komponen ini terdapat 3 algoritme fungsi yang
73
digunakan sebagai sampel, yaitu algoritme fungsi menghitung stok opname,
validasi kedatangan pupuk, dan menambah stok keluar.
5.3.1 Algoritme Fungsi Menghitung Stok Opname

Algoritme fungsi save_stokopname merupakan algoritme yang
menjelaskan proses ketika operator stok opname telah melakukan penambahan
pada data stok opname yang dilakukan di gudang penyangga, kemudian data
transaksi akan disimpan di dalam database. Algoritme ini dapat dilihat dalam Kode
Program 5.1.
Nama Class: stokopname_c
Nama Method: save_stokopname
Algoritme:
1 Mulai
2 Mengecheck / validator post data stokopname ( data kosong )
3 Mengecheck / validator post data detail stokopname ( data
kosong )
4
5 Inialisasi model pada variabel locAL
6 Inialisasi status dengan nilai kosong
7
8 Deklarasi block try
9 Inialisaisi pada pemanggilan function
insert_stokopname (data dan data detail)
10 Inialisasi status dengan hasil pemanggilan
11
12 Deklarasi block catch
13 Inialisasi status dengan catch
14 Akhiri block catch
15
16 return tampilan stok opname dengan umpan balikan nilai
status
17 Akhir kode
Kode Program 5.1
5.3.2 Algoritme Fungsi Validasi Kedatangan Pupuk

Algoritme fungsi validasi_kedatangan_stok merupakan algoritme yang
menjelaskan proses ketika operator gudang penyangga telah melakukan
penambahan informasi pada data request stok, kemudian data request stok akan
disimpan di dalam database, data stok akan bertambah di database, dan
74
memasukkan data baru logtransaksistok ke database. Algoritme ini dapat dilihat
dalam Kode Program 5.2.
Nama Class: stok_c
Nama Method: validasi_kedatangan_stok pupuk
Algoritme:
1 Mulai
2 Mengecheck / validator post qty ( data kosong )
3
4 Inialisasi model request stok pada variabel local
5 Inialisasi model stok pada variabel local
6 Inialisasi model logtransaksistok stok pada variabel
local
8
10 Inialisasi varibael pass dengan nilai false
11
12 Inialisaisi pass pada pemanggilan dr model request
stok function update_requeststok(qty)
13
14 buka blok if dengan seleksi nilai pass
15 Inialisaisi pass pada pemanggilan dr model stok
function update_increqasi_stok(qty)
16 tutup block if
17
19 Inialisaisi pada pemanggilan dr logtransaksistok
function insert_stok_masuk(qty)
20 tutup block if
21
22 Inialisasi status dengan nilai pass
26
27 return tampilan penerimaan stok dengan umpan balikan nilai
status
28 Akhir kode
75
Kode Program 5.2
5.3.3 Algoritme Fungsi Menambah Pupuk Keluar

Algoritme fungsi tambah_stok_keluar merupakan algoritme yang
menjelaskan proses ketika operator gudang penyangga telah melakukan
penambahan stok keluar saat ada pengurangan stok di gudang penyangga, data
stok akan bertambah di database, dan memasukkan data baru logtransaksistok ke
database. Algoritme ini dapat dilihat dalam Kode Program 5.3.
Nama Class: stok_
Nama Method: tambah_stok_keluar
Algoritme:
1 Mulai
2 Mengecheck / validator post qty (data kosong)
3
local
7
10
function update_decrease_stok(Array data)
12
function insert_stok_keluar(Array data)
15 tutup block if
16
21
22 return tampilan stok keluar dengan umpan balikan nilai
status
23 Akhir kode
Kode Program 5.3

76
5.4 Perancangan Basis Data
Perancangan basis data akan dibuat secara konseptual dengan
menggunakan Entity Relationship Diagram (ERD). Terdapat sebelas entitas
Perancangan basis data dari sistem Aplikasi Manajemen distribusi pupuk
diilustrasikan dengan diagram pada Gambar 5.5.
Gambar 5.5 Entity Relationship Diagram
5.5 Perancangan Antarmuka

Pada bagian ini akan dijelaskan hasil perancangan antarmuka halaman web
dari sistem Aplikasi Manajemen distribusi pupuk yang dikembangkan. Terdapat 3
buat perancangan antarmuka dari sistem yang diambil sebagai sampel. Hasil
perancangan antarmuka dari sistem ditunjukkan pada Gambar 5.6 hingga Gambar
5.9.
5.5.1 Perancangan Antarmuka Hitung Stok Opname

Antarmuka hitung stok opname merupakan halaman untuk operator stok
opname yang berfungsi untuk menghitung stok opname. Hasil perancangan
antarmuka hitung stok opname direpresentasikan pada Gambar 5.6.
77
Gambar 5.6 Perancangan Antarmuka Hitung Stok Opname
5.5.2 Perancangan Antarmuka Tambah Pupuk Keluar

Antarmuka tambah pupuk keluar merupakan halaman untuk operator
Gudang penyangga yang berfungsi untuk menambah data pupuk yang keluar dari
Gudang penyangga. Hasil perancangan antarmuka tambah pupuk keluar
direpresentasikan pada Gambar 5.8.
Gambar 5.7 Perancangan Antarmuka Tambah Pupuk Keluar
5.5.3 Perancangan Antarmuka Validasi Penerimaan Pupuk

Antarmuka validasi penerimaan pupuk merupakan halaman untuk
operator Gudang penyangga yang berfungsi untuk memvalidasi pupuk yang
datang digudang penyangga. Hasil perancangan antarmuka validasi penerimaan
pupuk direpresentasikan pada Gambar 5.9.
78
Gambar 5.9 Perancangan Antarmuka Validasi Penerimaan Pupuk
79
Formatted: Indonesian
BAB 6 IMPLEMENTASI
Pada bab ini akan dijabarkan mengenai implementasi sistem yang akan dibuat
berdasarkan hasil peracangan sistem yang telah dibuat di bab sebelumnya. Pada
tahap terdiri dari spesifikasi sistem, implementasi basis data, implementasi kode
program, dan implementasi antarmuka.
6.1 Spesifikasi Sistem Formatted: Outline numbered + Level: 2 + Numbering Style:

1, 2, 3, … + Start at: 1 + Alignment: Left + Aligned at: 0" +
Indent at: 0.26"
Spesifikasi sistem dari sistem aplikasi manajemen distribusi pupuk PT
Petrokimia Gresik yang digunakan dalam mengembangkan sistem dibagi menjadi
dua sub bab, yaitu spesifikasi perangkat keras dan spesifikasi perangkat lunak.
6.1.1 Spesifikasi Perangkat Keras Formatted: Outline numbered + Level: 3 + Numbering Style:
Pengembangan sistem aplikasi manajemen distribusi PT Petrokimia Gresik Indent at: 0.5"
menggunakan perangkat keras dengan spesifikasi yang dijabarkan pada Table 6.1.
Tabel 6.1 Spesifikasi Perangkat Keras
Nama Komponen Spesifikasi Formatted Table
System Model Apple Macbook Pro A1502

Processor Intel Core i5 2,9 Ghz
Memory (RAM) 8GB Dual-Slot DDR3 1867 MHz
GPU Intel Iris Graphics 6100
Storage Apple SSD SM0512G
6.1.2 Spesifikasi Perangkat Lunak

Dalam pengembangan yang dilakukan terdapat beberapa perangkat lunak
pendukung. Spesifikasi perangkat lunak yang digunakan dijelaskan pada Tabel 6.2.
Tabel 6.2 Spesifikasi Perangkat Lunak
Nama Komponen Spesifikasi
Sistem Operasi MacOS Mojave 10.14.1
Bahasa Pemrograman PHP, Javascript, CSS, HTML, Ajax
Perkakas Bantu Visual Code
Visual Paradigm Comunity Edition
Draw.io
Microsoft Office 365
80
6.1.3 Batasan Implementasi
Berikut merupakan beberapa batasan dalam tahap implementasi sistem aplikasi
manajemen distribusi pupuk PT Petrokimia Gresik. Batasan-batasan tersebut
diantaranya adalah:
1. Sistem yang dikembangkan berbasis web dengan menggunakan beberapa

bahasa pemrograman antara lain PHP, CSS, HTML, AJAX, dan Javascript.
2. Databasa Management System yang digunakan adalah MySQL.
3. Sistem dikembangkan dengan menggunakan framework Codeigniter versi 3.1.7.
6.2 Implementasi Basis Data

Implementasi basis data dibuat berdasarkan hasil perncangan basis data
yang telah dibuat pada tahap perancangan sistem. Implementasi basis data
menggunakan PHPMyAdmin.
6.3 Implementasi Kode Program

Pada tahap implementasi kode program ini adalah mengubah hasil
perancangan algoritme ke dalam bahasa komputer dengan menggunakan
beberapa bahasa pemrograman yaitu PHP, Javascript, Ajax.
6.4 Implementasi Antarmuka

Pada tahap implementasi antarmuka ini dibuat antarmuka sebagai media
interaksi antara pengguna dan sistem. Implementasi antarmuka dibuat dengan
mangacu pada perancangan antara muka yang telah dibuat pada tahap
perancangan antarmuka.
81
BAB 7 PENGUJIAN
Pada bab ini akan dijabarkan.berisi pengujian-pengujian yang dilakukan

terhadap Sistem Aplikasi Manajemen Distribusi PT Petrokimia Gresik dan hasil
analisis dari pengujian sistem yang dilakukan. Tahap ini dilakukan setelah
menyelesaikan fase implementasi dari sistem. Sistem akan dilakukan beberapa
pengujian mulai dari pengujian unit dengan menggunakan metode white box
testing dan pengujian validasi dengan menggunakan metode black box testing.
6.1 7.1 Pengujian Unit Formatted: No bullets or numbering
Pengujian unit dilakukan untuk menguji united seperti komponen, objek, atau
klas dari hasil perancangan sistem. Pengujian dilakukan menggunakan salah satu
metode pada White Box Testing yaitu basis path testing. Pengujian unit dilakukan
dalam tiga sampel uji yaitu pada klas blabla.
6.1.17.1.1 Pengujian Unit Klas Stok Opname Formatted: Outline numbered + Level: 3 + Numbering Style:
1. Pseudocode Indent at: 0.5"
1 Formatted: Centered
1 Mulai Formatted Table
2 Mengecheck / validator post data stokopname ( data kosong )
3 Mengecheck / validator post data detail stokopname ( data
kosong )
Formatted:
2 Centered
4
5 Inialisasi model pada variabel locAL
7
9 Inialisaisi pada pemanggilan function 3
Formatted: Centered
insert_stokopname (data dan data detail)
10 Inialisasi status dengan hasil pemanggilan
11
4
Formatted: Centered
14 Akhiri block catch Formatted:
5 Centered
15
16 return tampilan stok opname dengan umpan balikan nilai 6 Formatted: Centered
status
7 Formatted: Centered
17 Akhir kode
Formatted: Indent: First line: 0.3"
82
2. Basis Path Testing
a. Flow Graph
b. Cyclomatic Complexity
1. Region : 2
2. Node : 7
3. Edge : 7
i. V(G) = 2, ada 2 Region = R1, R2
ii. V(G) = Edges – Node + 2 = 7 – 7 + 2 = 2
iii. V(G) = 1 Predicates nodes + 1 = 2
c. Independent Path
1. Path 1 = 1 – 2 – 3 – 5 – 6 – 7
2. Path 2 = 1 – 2 – 4 – 5 – 6 – 7
No. No. Prosedur Uji Expected Result Result Status Formatted: Centered
Jalur Formatted Table
83
1 1 Mengaktifkan Data bisa Data bisa Valid
database server tertambah tertambah
2 2 Menonaktifkan Error, dan Error, dan Valid Formatted: Normal, Centered
database server masuk pada masuk pada
block catch block catch
7.1.2 Pengujian Unit Klas Validasi Kedatangan Stok

1. Pseudocode
1 Mulai
2 Mengecheck / validator post qty ( data kosong )
3
4 Inialisasi model request stok pada variabel local
local
8
11
12 Inialisaisi pass pada pemanggilan dr model request
stok function update_requeststok(qty)
13
function update_increqasi_stok(qty)
16 tutup block if
17
function insert_stok_masuk(qty)
20 tutup block if
21
84
26
27 return tampilan penerimaan stok dengan umpan balikan nilai
status
28 Akhir kode
2. Basis Path Testing

a. Flow Graph
b. Cyclomatic Complexity
4. Region : 2
5. Node : 7
6. Edge : 7
iv. V(G) = 2, ada 2 Region = R1, R2
v. V(G) = Edges – Node + 2 = 7 – 7 + 2 = 2
vi. V(G) = 1 Predicates nodes + 1 = 2
c. Independent Path
3. Path 1 = 1 – 2 – 3 – 5 – 6 – 7
4. Path 2 = 1 – 2 – 4 – 5 – 6 – 7
85
No. No. Prosedur Uji Expected Result Result Status
Jalur
1 1 Mengaktifkan Data bisa Data bisa Valid
database server tertambah tertambah
2 2 Menonaktifkan Error, dan Error, dan Valid
database server masuk pada masuk pada
block catch block catch
7.2 Pengujian Integrasi

Pengujian integrasi menggunakan teknik basis path testing dan pendekatan
top-down. Pengujian integrasi ini dilakukan pada method blabla pada klas blabla
yang did
7.3 Pengujian Validasi

Pengujian unit dilakukan untuk menguji united seperti komponen, objek, Formatted: Indent: First line: 0.5"
atau klas dari hasil perancangan sistem. Pengujian dilakukan menggunakan salah
satu metode pada White Box Testing yaitu basis path testing. Pengujian unit
dilakukan dalam tiga sampel uji yaitu pada klas blabla.
7.1.1 7.3.1 Pengujian Validasi Melihat Data Jenis Pupuk Formatted: No bullets or numbering
7.1.2 Pada kasus pengujian validasi melihat data jenis pupuk blabla
terdapat satu kasus uji yaitu kasus uji berhasil melihat data jenis pupuk yang dapat
dilihat pada tabel 7.1.1.
7.1.3 A. Kasus Uji Berhasil Melihat Data Jenis Pupuk
Tabel 7.1.1 Kasus Uji Berhasil Melihat Data Jenis Pupuk Formatted: Indonesian
Nama Kasus Uji Melihat Data Jenis Pupuk Formatted: Left

Prosedur 1. Aktor memilih menu jenis pupuk
Formatted: Left
Hasil yang Sistem akan menampilkan halaman daftar jenis pupuk Formatted: Indonesian
diharapkan Formatted: Left
Hasil Formatted: Indonesian
Status
86
7.3.2 Pengujian Validasi Manambah Jenis Pupuk
Pada kasus pengujian validasi menambah data jenis pupuk terdapat tiga
kasus uji yaitu kasus uji berhasil menambah data jenis pupuk yang dapat dilihat
pada tabel 7.2.1, kasus uji batal menambah data jenis pupuk yang dapat dilihat
pada tabel 7.2.2, dan kasus uji tidak mengisi salah satu data jenis pupuk yang dapat
A. Kasus Uji Berhasil Menambah Data Jenis Pupuk
Tabel 7.2.1 Kasus Uji Berhasil MelihatMenambah Data Jenis Pupuk
Nama Kasus Uji Berhasil Menambah Data Jenis Pupuk
Prosedur 1. Aktor menekan tombol tambah jenis pupuk Formatted: No bullets or numbering

3. Aktor memasukkan data yang diperlukan yaitu, nama
pupuk, berat per kemasan
Formatted: Indent: Left: 0", Hanging: 0.24", No bullets or
Hasil yang Sistem akan menampilkan pesan berhasil dan jenis numbering
diharapkan pupuk telah tertambah pada tabel.
Hasil
Status
7.1.4 Formatted: Body Text, No bullets or numbering
7.1.5 Formatted: Indonesian
B. Kasus Uji Batal Menambah Data Jenis Pupuk

Tabel 7.2.2 Kasus Uji Batal Menambah Data Jenis Pupuk
Nama Kasus Uji Batal Menambah Data Jenis Pupuk
Prosedur 1. Aktor menekan tombol tambah jenis pupuk.
2. Sistem menampilkan form pengisian jenis pupuk.
3. Aktor batal menambah data jenis pupuk dengan Formatted: Body Text First Indent
menekan tombol “X”.
Hasil yang Sistem akan menghilangkan form pengisian jenis pupuk
diharapkan dan kembali ke menu jenis pupuk.
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Jenis Pupuk

Tabel 7.2.3 Kasus Uji Tidak Mengisi Salah Satu Data Jenis Pupuk
87
Nama Kasus Uji Tidak Mengisi Salah Satu Data Jenis Pupuk
Prosedur 1. Aktor menekan tombol tambah jenis pupuk.
3. Aktor tidak memasukkan salah satu data yang
diperlukan yaitu, nama pupuk, berat per kemasan.
4. Aktor menekan tombol save. Commented [F15]: Paham salah nya dimana? Cek lagi
Hasil yang Sistem akan menampilkan pemberitahuan untuk
diharapkan mengisi semua form
Hasil
Status
7.3.3 Pengujian Validasi Mengubah Jenis Pupuk

Pada kasus pengujian validasi mengubah data jenis pupuk terdapat dua
kasus uji yaitu kasus uji berhasil mengubah data jenis pupuk yang dapat dilihat
pada tabel 7.3.1, dan kasus uji batal mengubah data jenis pupuk yang dapat dilihat
pada tabel 7.3.2.
A. Kasus Uji Berhasil Mengubah Data Jenis Pupuk
Tabel 7.3.1 Kasus Uji Berhasil Mengubah Data Jenis Pupuk
Prosedur 1. Aktor menekan tombol ubah jenis pupuk
3. Aktor memasukkan data yang ingin diubah yaitu,
Hasil yang Sistem akan menampilkan pesan berhasil.

diharapkan
Hasil
Status
B. Kasus Uji Batal Mengubah Data Jenis Pupuk

Tabel 7.3.2 Kasus Uji Batal Mengubah Data Jenis Pupuk
Nama Kasus Uji Batal Mengubah Data Jenis Pupuk
Prosedur 1. Aktor menekan tombol ubah jenis pupuk.
88
3. Aktor batal menambah data jenis pupuk dengan
Hasil
Status
7.3.4 Pengujian Validasi Melihat Data Rekanan Transportir

Pada kasus pengujian validasi melihat data rekanan transportir terdapat
satu kasus uji yaitu kasus uji berhasil melihat data rekanan transportir yang dapat
A. Kasus Uji Berhasil Melihat Data Rekanan Transportir
Tabel 7.4.1 Kasus Uji Berhasil Melihat Data Rekanan Transportir
Nama Kasus Uji Melihat Data Rekanan Transportir
Prosedur 1. Aktor memilih menu rekanan transporter Formatted: Indent: Left: 0", Hanging: 0.24", No bullets or
numbering
Hasil yang Sistem akan menampilkan halaman daftar rekanan
diharapkan transportir
Hasil
Status
7.3.5 Pengujian Validasi Manambah Rekanan Transportir

Pada kasus pengujian validasi menambah rekanan transportir terdapat tiga
kasus uji yaitu kasus uji berhasil menambah rekanan transportir yang dapat dilihat
pada tabel 7.5.1, kasus uji batal menambah rekanan transportir yang dapat dilihat
pada tabel 7.5.2, dan kasus uji tidak mengisi salah satu data rekanan transportir
yang dapat dilihat pada tabel 7.5.3.
A. Kasus Uji Berhasil Menambah Rekanan Transportir
Tabel 7.5.1 Kasus Uji Berhasil Menambah Rekanan Transportir
Nama Kasus Uji Berhasil Menambah Rekanan Transportir
Prosedur 1. Aktor menekan tombol tambah rekanan transportir
2. Sistem menampilkan form pengisian rekanan
transportir
rekanan, daftar gudang penyangga, username,
password.
Formatted: Indent: Left: 0", Hanging: 0.24", No bullets or
numbering
89
Hasil yang Sistem akan menampilkan pesan berhasil dan data
diharapkan rekanan transportir telah tertambah pada tabel.
Hasil
Status

Tabel 7.2.2 Kasus Uji Batal Menambah Rekanan Transportir
Nama Kasus Uji Batal Menambah Rekanan Transportir
Prosedur 1. Aktor menekan tombol tambah rekanan transportir.
2. Sistem menampilkan form pengisian data rekanan
transportir.
3. Aktor batal menambah data rekanan transportir
dengan menekan tombol “X”.
Hasil yang Sistem akan menghilangkan form pengisian rekanan
diharapkan transportir dan kembali ke menu rekanan transportir.
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Rekanan Transportir

Tabel 7.2.3 Kasus Uji Tidak Mengisi Salah Satu Data Rekanan Transportir
Nama Kasus Uji Tidak Mengisi Salah Satu Data Rekanan Transportir
transportir.
diperlukan yaitu, nama rekanan, daftar gudang
penyangga, username, password.

Hasil
Status
90
7.3.3 Pengujian Validasi Mengubah Jenis Pupuk
Pada kasus pengujian validasi mengubah data jenis pupuk terdapat dua
kasus uji yaitu kasus uji berhasil mengubah data jenis pupuk yang dapat dilihat
pada tabel 7.3.1, dan kasus uji batal mengubah data jenis pupuk yang dapat dilihat
pada tabel 7.3.2.
A. Kasus Uji Berhasil Mengubah Data Jenis Pupuk
Tabel 7.3.1 Kasus Uji Berhasil Mengubah Data Jenis Pupuk
Prosedur 1. Aktor menekan tombol ubah jenis pupuk
3. Aktor memasukkan data yang ingin diubah yaitu,
Hasil yang Sistem akan menampilkan pesan berhasil.

diharapkan
Hasil
Status
B. Kasus Uji Batal Mengubah Data Jenis Pupuk

Tabel 7.3.2 Kasus Uji Batal Mengubah Data Jenis Pupuk
Nama Kasus Uji Batal Mengubah Data Jenis Pupuk
Prosedur 1. Aktor menekan tombol ubah jenis pupuk.
3. Aktor batal menambah data jenis pupuk dengan
Hasil
Status
7.3.4 Pengujian Validasi Melihat Data Rekanan Transportir

Pada kasus pengujian validasi melihat data rekanan transportir terdapat
satu kasus uji yaitu kasus uji berhasil melihat data rekanan transportir yang dapat
A. Kasus Uji Berhasil Melihat Data Rekanan Transportir
91
Tabel 7.4.1 Kasus Uji Berhasil Melihat Data Rekanan Transportir
Nama Kasus Uji Melihat Data Rekanan Transportir
Prosedur 1. Aktor memilih menu rekanan transporter
diharapkan transportir
Hasil
Status
7.3.5 Pengujian Validasi Manambah Rekanan Transportir

Pada kasus pengujian validasi menambah rekanan transportir terdapat tiga
kasus uji yaitu kasus uji berhasil menambah rekanan transportir yang dapat dilihat
pada tabel 7.5.1, kasus uji batal menambah rekanan transportir yang dapat dilihat
pada tabel 7.5.2, dan kasus uji tidak mengisi salah satu data rekanan transportir
A. Kasus Uji Berhasil Menambah Rekanan Transportir
Tabel 7.5.1 Kasus Uji Berhasil Menambah Rekanan Transportir
Nama Kasus Uji Berhasil Menambah Rekanan Transportir
Prosedur 1. Aktor menekan tombol tambah rekanan transportir
transportir
rekanan, daftar gudang penyangga, username,
password.
Hasil yang Sistem akan menampilkan pesan berhasil dan data

diharapkan rekanan transportir telah tertambah pada tabel.
Hasil
Status

Tabel 7.2.2 Kasus Uji Batal Menambah Rekanan Transportir
Nama Kasus Uji Batal Menambah Rekanan Transportir
transportir.
92
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Rekanan Transportir

Tabel 7.2.3 Kasus Uji Tidak Mengisi Salah Satu Data Rekanan Transportir
Nama Kasus Uji Tidak Mengisi Salah Satu Data Rekanan Transportir
transportir.
penyangga, username, password.

Hasil
Status
7.3.6 Pengujian Validasi Mengubah Rekanan Transportir

Pada kasus pengujian validasi mengubah data rekanan transportir terdapat
dua kasus uji yaitu kasus uji berhasil mengubah data rekanan transportir yang
dapat dilihat pada tabel 7.6.1, dan kasus uji batal mengubah data rekanan
transportir yang dapat dilihat pada tabel 7.6.2.
A. Kasus Uji Berhasil Mengubah Data Rekanan Transportir
Tabel 7.6.1 Kasus Uji Berhasil Mengubah Data Rekanan Transportir
Nama Kasus Uji Berhasil Mengubah Data Rekanan Transportir
Prosedur 1. Aktor menekan tombol ubah rekanan transportir pada
kolom aksi di tabel rekanan trasnportir yang akan diubah
93
3. Aktor menambahkan data rekanan transportir yaitu,
nama rekanan, daftar gudang penyangga, username,
password
Hasil yang Sistem akan menampilkan pesan berhasil, dan jenis
diharapkan pupuk telah terubah pada data yang diinginkan
Hasil
Status
B. Kasus Uji Batal Mengubah Data Rekanan Transportir

Tabel 7.6.2 Kasus Uji Batal Mengubah Data Rekanan Transportir
Nama Kasus Uji Batal Mengubah Data Rekanan Transportir
Prosedur 1. Aktor menekan tombol ubah rekanan transportir.
transportir.
Hasil
Status
7.3.7 Pengujian Validasi Melihat Batas Stok Kritis

Pada kasus pengujian validasi melihat data batas stok kritis terdapat satu
kasus uji yaitu kasus uji berhasil melihat data data batas stok kritis yang dapat
A. Kasus Uji Berhasil Melihat Data Batas Sto Kritis
Tabel 7.7.1 Kasus Uji Berhasil Melihat Data Batas Stok Kritis
Nama Kasus Uji Melihat Data Batas Stok Kritis
Prosedur 1. Aktor memilih menu batas stok kritis pada sistem
Hasil yang Sistem akan menampilkan halaman daftar batas stok
diharapkan kritis
Hasil
Status
94
7.3.8 Pengujian Validasi Menambah Batas Stok Kritis
Pada kasus pengujian validasi menambah batas stok kritis terdapat tiga
kasus uji yaitu kasus uji berhasil menambah batas stok kritis yang dapat dilihat
pada tabel 7.8.1, kasus uji batal menambah batas stok kritis yang dapat dilihat
pada tabel 7.8.2, dan kasus uji tidak mengisi salah satu data batas stok kritis yang
dapat dilihat pada tabel 7.8.3.
A. Kasus Uji Berhasil Menambah Batas Stok Kritis
Tabel 7.8.1 Kasus Uji Berhasil Menambah Batas Stok Kritis
Nama Kasus Uji Berhasil Menambah Batas Stok Kritis
Prosedur 1. Aktor menekan tombol tambah pada halaman batas
stok kritis
Kritis
Hasil yang Sistem akan menampilkan pesan berhasil, dan batas stok
diharapkan kritis telah ditambahkan
Hasil
Status
B. Kasus Uji Batal Menambah Data Batas Stok Kritis

Tabel 7.2.2 Kasus Uji Batal Menambah Batas Stok Kritis
Nama Kasus Uji Batal Menambah Batas Stok Kritis
Prosedur 1. Aktor menekan tombol tambah batas stok kritis.
2. Sistem menampilkan form pengisian data batas stok
kritis.
3. Aktor batal menambah data batas stok kritis dengan
Hasil yang Sistem akan menghilangkan form pengisian batas stok
diharapkan kristis dan kembali ke menu batas stok kritis.
Hasil
Status
95
C. Kasus Uji Tidak Mengisi Salah Satu Data Batas Stok Kritis
Tabel 7.2.3 Kasus Uji Tidak Mengisi Salah Satu Data Stok Kritis.
Nama Kasus Uji Tidak Mengisi Salah Satu Data Batas Stok Kritis
Prosedur 1. Aktor menekan tombol tambah data batas stok kritis.
kritis.
diperlukan yaitu, nama daerah, jenis pupuk, dan qty
batas stok kritis

Hasil
Status
7.3.9 Pengujian Validasi Mengubah Batas Stok Kritis

Pada kasus pengujian validasi mengubah data batas stok kritis terdapat
dua kasus uji yaitu kasus uji berhasil mengubah data batas stok kritis yang dapat
dilihat pada tabel 7.9.1, dan kasus uji batal mengubah data batas stok kritis yang
A. Kasus Uji Berhasil Mengubah Data Batas Stok Kritis
Tabel 7.9.1 Kasus Uji Berhasil Mengubah Data Batas Stok Kritis
Nama Kasus Uji Berhasil Mengubah Data Batas Stok Kritis
Prosedur 1. Aktor menekan tombol ubah batas stok kritis pada
kolom aksi di tabel batas stok kritis yang akan diubah
Kritis
Hasil yang Sistem akan menampilkan pesan berhasil, dan batas stok
diharapkan kritis telah terubah pada data yang diinginkan
Hasil
Status
96
B. Kasus Uji Batal Mengubah Data Batas Stok Kritis
Tabel 7.9.2 Kasus Uji Batal Mengubah Data Batas Stok Kritis
Nama Kasus Uji Batal Mengubah Data Batas Stok Kritis
Prosedur 1. Aktor menekan tombol ubah data batas stok kritis.
kritis.
3. Aktor batal menambah data batas stok kritis dengan
Hasil yang Sistem akan menghilangkan form pengisian batas stok
diharapkan terakhir dan kembali ke menu batas stok terakhir.
Hasil
Status
7.3.10 Pengujian Validasi Melihat Rekanan Pengelola Gudang Penyangga

Pada kasus pengujian validasi melihat data rekanan pengelola gudang
penyangga terdapat satu kasus uji yaitu kasus uji berhasil melihat data rekanan
pengelola gudang penyangga yang dapat dilihat pada tabel 7.10.1.
A. Kasus Uji Berhasil Melihat Data Rekanan Pengelola Gudang Penyangga
Tabel 7.10.1 Kasus Uji Berhasil Melihat Data Rekanan Pengelola Gudang
Penyangga
Nama Kasus Uji Melihat Data Rekanan Pengelola Gudang Penyangga
Prosedur 1. Aktor memilih menu rekanan pengelola gudang
penyangga
diharapkan pengelola gudang penyangga
Hasil
Status
7.3.11 Pengujian Validasi Menambah Rekanan Pengelola Gudang

Penyangga
Pada kasus pengujian validasi menambah rekanan pengelola gudang
penyangga terdapat tiga kasus uji yaitu kasus uji berhasil menambah rekanan
pengelola gudang penyangga yang dapat dilihat pada tabel 7.11.1, kasus uji batal
menambah rekanan pengelola gudang penyangga yang dapat dilihat pada tabel
7.11.2, dan kasus uji tidak mengisi salah satu data rekanan pengelola gudang
penyangga yang dapat dilihat pada tabel 7.11.3.
97
A. Kasus Uji Berhasil Menambah Rekanan Pengelola Gudang Penyangga
Tabel 7.11.1 Kasus Uji Berhasil Menambah Rekanan Pengelola Gudang
Penyangga
Nama Kasus Uji Berhasil Menambah Rekanan Pengelola Gudang
Penyangga
Prosedur 1. Aktor menekan tombol tambah pada halaman
Hasil yang Sistem akan menampilkan pesan berhasil, dan rekanan
diharapkan pengelola gudang penyangga telah ditambahkan
Hasil
Status
B. Kasus Uji Batal Menambah Data Rekanan Pengelola Gudang Penyangga

Tabel 7.11.2 Kasus Uji Batal Menambah Rekanan Pengelola Gudang Penyangga
Nama Kasus Uji Batal Menambah Rekanan Pengelola Gudang Penyangga
Prosedur 1. Aktor menekan tombol tambah rekanan pengelola
gudang penyangga.
pengelola gudang penyangga.
3. Aktor batal menambah data rekanan pengelola
gudang penyangga dengan menekan tombol “X”.
diharapkan pengelola gudang penyangga dan kembali ke menu
rekanan pengelola gudang penyangga.
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Rekanan Pengelola Gudang Penyangga
Tabel 7.11.3 Kasus Uji Tidak Mengisi Salah Satu Data Rekanan Pengelola
Gudang Penyangga.
98
Nama Kasus Uji Tidak Mengisi Salah Satu Data Rekanan Pengelola
Gudang Penyangga
Prosedur 1. Aktor menekan tombol tambah data rekanan

Hasil
Status
7.3.9 Pengujian Validasi Mengubah Rekanan Pengelola Gudang

Penyangga
Pada kasus pengujian validasi mengubah data rekanan pengelola gudang
penyangga terdapat dua kasus uji yaitu kasus uji berhasil mengubah data rekanan
pengelola gudang penyangga yang dapat dilihat pada tabel 7.12.1, dan kasus uji
batal mengubah data rekanan pengelola gudang penyangga yang dapat dilihat
pada tabel 7.12.2.
A. Kasus Uji Berhasil Mengubah Data Rekanan Pengelola Gudang Penyangga
Tabel 7.12.1 Kasus Uji Berhasil Mengubah Data Rekanan Pengelola Gudang
Penyangga
Nama Kasus Uji Berhasil Mengubah Data Rekanan Pengelola Gudang
Penyangga
Prosedur 1. Aktor menekan tombol ubah rekanan pengelola
gudang penyangga pada kolom aksi di tabel rekanan
pengelola gudang penyangga yang akan diubah
2. Sistem menampilkan form pengubahan data rekanan
pengelola yang diinginkan
3. Aktor menambahkan data rekanan pengelola gudang
penyangga yang dikelola, username, dan password
99
diharapkan pengelola gudang penyangga telah terubah pada data
yang diinginkan
Hasil
Status
B. Kasus Uji Batal Mengubah Data Rekanan Pengelola Gudang Penyangga

Tabel 7.12.2 Kasus Uji Batal Mengubah Data Rekanan Pengelola Gudang
Penyangga
Nama Kasus Uji Batal Mengubah Data Rekanan Pengelola Gudang
Penyangga
Prosedur 1. Aktor menekan tombol ubah data rekanan pengelola
gudang penyangga.
3. Aktor batal menambah data rekanan pengelola
gudang penyangga dengan menekan tombol “X”.
diharapkan pengelolaan gudang penyangga dan kembali ke menu
rekanan pengelolaan gudang penyangga.
Hasil
Status
7.3.13 Pengujian Validasi Melihat Gudang Penyangga

Pada kasus pengujian validasi melihat data gudang penyangga terdapat
satu kasus uji yaitu kasus uji berhasil melihat data gudang penyangga yang dapat
A. Kasus Uji Berhasil Melihat Data Gudang Penyangga
Tabel 7.13.1 Kasus Uji Berhasil Melihat Data Gudang Penyangga
Nama Kasus Uji Melihat Data Gudang Penyangga
Prosedur 1. Aktor memilih menu gudang penyangga
Hasil yang Sistem akan menampilkan halaman daftar Data Gudang
diharapkan Penyangga
Hasil
Status
100
7.3.14 Pengujian Validasi Menambah Gudang Penyangga
Pada kasus pengujian validasi menambah gudang penyangga terdapat tiga
kasus uji yaitu kasus uji berhasil menambah gudang penyangga yang dapat dilihat
pada tabel 7.14.1, kasus uji batal menambah gudang penyangga yang dapat dilihat
pada tabel 7.14.2, dan kasus uji tidak mengisi salah satu data gudang penyangga
A. Kasus Uji Berhasil Menambah Gudang Penyangga
Tabel 7.14.1 Kasus Uji Berhasil Menambah Gudang Penyangga
Nama Kasus Uji Berhasil Menambah Gudang Penyangga
Prosedur 1. Aktor menekan tombol tambah pada halaman gudang
penyangga
penyangga
3. Aktor mengisikan data gudang penyangga yaitu, kode
gudang penyangga, alamat, daya tampung gudang,
pengelola, nama kepala Gudang, kontak, username, dan
password.

diharapkan gudang penyangga telah ditambahkan
Hasil
Status
B. Kasus Uji Batal Menambah Data Gudang Penyangga

Tabel 7.14.2 Kasus Uji Batal Menambah Gudang Penyangga
Nama Kasus Uji Batal Menambah Gudang Penyangga
Prosedur 1. Aktor menekan tombol tambah gudang penyangga.
2. Sistem menampilkan form pengisian data gudang
penyangga.
3. Aktor batal menambah data gudang penyangga
Hasil yang Sistem akan menghilangkan form pengisian gudang
diharapkan penyangga dan kembali ke menu gudang penyangga.
101
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Gudang Penyangga

Tabel 7.14.3 Kasus Uji Tidak Mengisi Salah Satu Data Gudang Penyangga.
Nama Kasus Uji Tidak Mengisi Salah Satu Data Gudang Penyangga
Prosedur 1. Aktor menekan tombol tambah data gudang
penyangga.
penyangga.
5. 3. Aktor tidak memasukkan salah satu data yang
diperlukan yaitu, kode gudang penyangga, alamat,
daya tampung gudang, pengelola, nama kepala
Gudang, kontak, username, dan password..

Hasil
Status
7.3.15 Pengujian Validasi Mengubah Gudang Penyangga

Pada kasus pengujian validasi mengubah data gudang penyangga terdapat
dua kasus uji yaitu kasus uji berhasil mengubah data gudang penyangga yang
dapat dilihat pada tabel 7.15.1, dan kasus uji batal mengubah data gudang
penyangga yang dapat dilihat pada tabel 7.15.2.
A. Kasus Uji Berhasil Mengubah Data Gudang Penyangga
Tabel 7.15.1 Kasus Uji Berhasil Mengubah Data Gudang Penyangga
Nama Kasus Uji Berhasil Mengubah Data Gudang Penyangga
Prosedur 1. Aktor menekan tombol ubah data Gudang penyangga
pada kolom aksi di tabel data Gudang penyangga yang
akan diubah
2. Sistem menampilakan form pengubahan data Gudang
Penyangga yang diinginkan
3. Aktor mengubah data Gudang penyangga yaitu, kode
Gudang penyangga, alamat, daya tampung Gudang,
102
pengelola, nama kepala Gudang, kontak, username, dan
password.
Hasil yang Sistem akan menampilkan pesan berhasil, dan data
diharapkan Gudang penyangga telah berhasil diubah
Hasil
Status
B. Kasus Uji Batal Mengubah Data Gudang Penyangga

Tabel 7.15.2 Kasus Uji Batal Mengubah Data Gudang Penyangga
Nama Kasus Uji Batal Mengubah Data Gudang Penyangga
Prosedur 1. Aktor menekan tombol ubah data gudang penyangga.
penyangga.
3. Aktor batal menambah data rekanan penyangga
Hasil yang Sistem akan menghilangkan form pengisian gudang
diharapkan penyangga dan kembali ke menu gudang penyangga.
Hasil
Status
7.3.16 Pengujian Validasi Melihat Petugas Stok Opname

Pada kasus pengujian validasi melihat data petugas stok opname terdapat
satu kasus uji yaitu kasus uji berhasil melihat data petugas stok opname yang
A. Kasus Uji Berhasil Melihat Data Gudang Penyangga
Tabel 7.16.1 Kasus Uji Berhasil Melihat Data Petugas Stok Opname
Nama Kasus Uji Melihat Data Petugas Tok Opname
Prosedur 1. Aktor memilih menu petugas stok opname
diharapkan petugas stok opname berhasil ditampilkan.
Hasil
Status
103
7.3.17 Pengujian Validasi Menambah Petugas Stok Opname
Pada kasus pengujian validasi menambah gudang penyangga terdapat tiga
kasus uji yaitu kasus uji berhasil menambah petugas stok opname yang dapat
dilihat pada tabel 7.17.1, kasus uji batal menambah petugas stok opname yang
dapat dilihat pada tabel 7.17.2, dan kasus uji tidak mengisi salah satu data petugas
stok opname yang dapat dilihat pada tabel 7.17.3.
A. Kasus Uji Berhasil Menambah Petugas Stok Opname
Tabel 7.14.1 Kasus Uji Berhasil Menambah Petugas Stok Opname
Nama Kasus Uji Berhasil Menambah Petugas Stok Opname
Prosedur 1. Aktor menekan tombol tambah pada halaman
2. Sistem menampilkan form penambahan data petugas
stok opname
kode tim, nama petugas 1, nama petugas 2, username
dan password.
Hasil yang Sistem menampilkan pesan berhasil, dan data petugas
diharapkan stok opname berhasil ditambahkan.
Hasil
Status
B. Kasus Uji Batal Menambah Data Petugas Stok Opname

Tabel 7.17.2 Kasus Uji Batal Menambah Petugas Stok Opname
Nama Kasus Uji Batal Menambah Petugas Stok Opname
Prosedur 1. Aktor menekan tombol tambah petugas stok opname.
2. Sistem menampilkan form pengisian data petugas
stok opname.
3. Aktor batal menambah data petugas stok opname
Hasil yang Sistem akan menghilangkan form pengisian petugas stok
diharapkan opname dan kembali ke menu petugas stok opname.
Hasil
Status
104
C. Kasus Uji Tidak Mengisi Salah Satu Data Petugas Stok Opname
Tabel 7.17.3 Kasus Uji Tidak Mengisi Salah Satu Data Petugas Stok Opname.
Nama Kasus Uji Tidak Mengisi Salah Satu Data Petugas Stok Opname
Prosedur 1. Aktor menekan tombol tambah data petugas stok
opname.
stok opname.
diperlukan yaitu, kode tim, nama petugas 1, nama
petugas 2, username dan password.

Hasil
Status
7.3.18 Pengujian Validasi Mengubah Petugas Stok Opname

Pada kasus pengujian validasi mengubah data petugas stok opname
terdapat dua kasus uji yaitu kasus uji berhasil mengubah data petugas stok
opname yang dapat dilihat pada tabel 7.18.1, dan kasus uji batal mengubah data
petugas stok opname yang dapat dilihat pada tabel 7.18.2.
A. Kasus Uji Berhasil Mengubah Data Petugas Stok Opname
Tabel 7.18.1 Kasus Uji Berhasil Mengubah Data Petugas Stok Opname
Nama Kasus Uji Berhasil Mengubah Data Petugas Stok Opname
Prosedur 1. Aktor menekan tombol ubah data petugas stok
opname pada kolom aksi di tabel petugas stok opname
yang akan diubah
2. Sistem menampilkan form pengubahan data Petugas
Stok Opname yang diinginkan
kode tim, nama petugas 1, nama petugas 2, username
dan password.
Hasil yang Sistem menampilkan pesan berhasil, dan data petugas
diharapkan stok opname berhasil diubah.
Hasil
105
Status
B. Kasus Uji Batal Mengubah Data Petugas Stok Opname

Tabel 7.18.2 Kasus Uji Batal Mengubah Data Petugas Stok Opname
Nama Kasus Uji Batal Mengubah Data Petugas Stok Opname
Prosedur 1. Aktor menekan tombol ubah data petugas stok
opname.
stok opname.
Hasil yang Sistem akan menghilangkan form pengisian petugas stok
diharapkan opname dan kembali ke menu petugas stok opname.
Hasil
Status
7.3.19 Pengujian Validasi Membuat Penugasan Stok Opname

Pada kasus pengujian validasi membuat penugasan stok opname terdapat
tiga kasus uji yaitu kasus uji berhasil membuat penugasan stok opname yang dapat
dilihat pada tabel 7.19.1, kasus uji batal membuat penugasan stok opname yang
dapat dilihat pada tabel 7.19.2, dan kasus uji tidak mengisi salah satu data
petnugasan stok opname yang dapat dilihat pada tabel 7.19.3.
A. Kasus Uji Berhasil Mmbuat Penugasan Stok Opname
Tabel 7.19.1 Kasus Uji Berhasil Membuat Penugasan Stok Opname
Nama Kasus Uji Berhasil Membuat penugasan Stok Opname
Prosedur 1. Aktor menekan tombol buat penugasan pada halaman
2. Sistem menampilkan form penugasan Penugasan Stok
Opname.
yaitu, kode tim, kode Gudang penyangga, dan tanggal
berangkat.
diharapkan penugasan stok opname berhasil dibuat.
106
Hasil
Status
B. Kasus Uji Batal Membuat Data Penugasan Stok Opname

Tabel 7.19.2 Kasus Uji Batal Membuat Penugasan Stok Opname
Nama Kasus Uji Batal Membuat Penugasan Stok Opname
Prosedur 1. Aktor menekan tombol buat penugasan stok opname.
2. Sistem menampilkan form pengisian data penugasan
stok opname.
3. Aktor batal membuat data penugasan stok opname
Hasil yang Sistem akan menghilangkan form penugasan stok
diharapkan opname dan kembali ke menu penugasan stok opname.
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Penugasan Stok Opname
Tabel 7.19.3 Kasus Uji Tidak Mengisi Salah Satu Data Penugasan Stok Opname.
Nama Kasus Uji Tidak Mengisi Salah Satu Data Penugasan Stok Opname
Prosedur 1. Aktor menekan tombol tambah data penugasan stok
opname.
2. Sistem menampilkan form pengisian data penugasan
stok opname.
diperlukan yaitu, kode tim, kode Gudang penyangga,
dan tanggal berangkat.

Hasil
Status
107
7.3.20 Pengujian Validasi Melihat Penugasan Stok Opname
Pada kasus pengujian validasi melihat data penugasan stok opname
terdapat satu kasus uji yaitu kasus uji berhasil melihat data penugasan stok
opname yang dapat dilihat pada tabel 7.20.1.
A. Kasus Uji Berhasil Melihat Data Penugasan Stok Opname
Tabel 7.20.1 Kasus Uji Berhasil Melihat Data Penugasan Stok Opname
Nama Kasus Uji Melihat Data Penugasan Stok Opname
Prosedur 1. Aktor memilih menu penugasan stok opname
Hasil yang Sistem menampilkan halaman melihat penugasan stok
diharapkan opname.
Hasil
Status
7.3.21 Pengujian Validasi Membuat Permintaan Pengiriman Pupuk

Pada kasus pengujian validasi membuat permintaan pengiriman pupuk
terdapat tiga kasus uji yaitu kasus uji berhasil membuat permintaan pengiriman
pupuk yang dapat dilihat pada tabel 7.21.1, kasus uji batal membuat permintaan
pengiriman pupuk yang dapat dilihat pada tabel 7.21.2, dan kasus uji tidak mengisi
salah satu data permintaan pengiriman pupuk yang dapat dilihat pada tabel
7.21.3.
A. Kasus Uji Berhasil Membuat Permintaan Pengriman Pupuk
Tabel 7.21.1 Kasus Uji Berhasil Membuat Permintaan Pengiriman Pupuk
Nama Kasus Uji Berhasil Membuat permintaan Pengiriman Pupuk
Prosedur 1. Aktor menekan tombol buat permintaan pada
29. Sistem menampilkan form Permintaan Pengiriman
Pupuk
Hasil yang Sisitem akan menampilkan pesan berhasil, dan data
diharapkan permintaan pengiriman pupuk berhasil dibuat.
Hasil
Status
108
B. Kasus Uji Batal Membuat Data Permintaan Pengiriman Pupuk
Tabel 7.21.2 Kasus Uji Batal Membuat Permintaan Pengiriman Pupuk
Nama Kasus Uji Batal Membuat Permintaan Pengiriman Pupuk
Prosedur 1. Aktor menekan tombol buat permintaan pengiriman
pupuk.
2. Sistem menampilkan form pengisian data permintaan
pengiriman pupuk.
3. Aktor batal membuat data permintaan pengiriman
pupuk dengan menekan tombol “X”.
Hasil yang Sistem akan menghilangkan form permintaan
diharapkan pengiriman pupuk dan kembali ke menu permintaan
pengiriman pupuk.
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Permintaan Pengiriman Pupuk
Tabel 7.21.3 Kasus Uji Tidak Mengisi Salah Satu Data Permintaan Pengiriman
Pupuk.
Nama Kasus Uji Tidak Mengisi Salah Satu Data Permintaan Pengiriman
Pupuk
Prosedur 1. Aktor menekan tombol buat data permintaan
pengiriman pupuk.
2. Sistem menampilkan form pengisian data permintaan
pengiriman pupuk.
diperlukan yaitu, no pengiriman, jenis pupuk, quantity,

Hasil
Status
109
7.3.22 Pengujian Validasi Melihat Permintaan Pengiriman Pupuk
Pada kasus pengujian validasi melihat data permintaan pengiriman pupuk
terdapat satu kasus uji yaitu kasus uji berhasil melihat data permintaan
pengiriman pupuk yang dapat dilihat pada tabel 7.22.1.
A. Kasus Uji Berhasil Melihat Data Permintaan Pengiriman Pupuk
Tabel 7.22.1 Kasus Uji Berhasil Melihat Data Permintaan Pegiriman Pupuk
Nama Kasus Uji Melihat Data Peermintaan Pengiriman Pupuk
Prosedur 1. Aktor memilih menu permintaan pengiriman pupuk
Hasil yang Sistem akan menampilkan daftar permintaan
diharapkan pengiriman pupuk di halaman permintaan pengiriman
pupuk.
Hasil
Status
7.3.23 Pengujian Validasi Mengisi Detail Permintaan Pengiriman Pupuk

Pada kasus pengujian validasi mengisi detail permintaan pengiriman pupuk
terdapat tiga kasus uji yaitu kasus uji berhasil mengisi detail permintaan
pengiriman pupuk yang dapat dilihat pada tabel 7.23.1, kasus uji batal mengisi
detail permintaan pengiriman pupuk yang dapat dilihat pada tabel 7.23.2, dan
kasus uji tidak mengisi salah satu data detail permintaan pengiriman pupuk yang
A. Kasus Uji Berhasil Mengisi detail Permintaan Pengriman Pupuk
Tabel 7.23.1 Kasus Uji Berhasil Mengisi Detail Permintaan Pengiriman Pupuk
Nama Kasus Uji Berhasil Mengisi Detail Permintaan Pengiriman Pupuk
Prosedur 1. Aktor menekan tombol respon permintaan pada
pengambilan pupuk.
diharapkan detail permintaan pengiriman pupuk berhasil dibuat.
Hasil
110
Status
B. Kasus Uji Batal Mengisi Detail Data Permintaan Pengiriman Pupuk

Tabel 7.23.2 Kasus Uji Batal Mengisi Detail Permintaan Pengiriman Pupuk
Nama Kasus Uji Batal Mengisi Detail Permintaan Pengiriman Pupuk
Prosedur 1. Aktor menekan tombol respon permintaan
pengiriman pupuk.
2. Sistem menampilkan form pengisian detail data
3. Aktor batal membuat detail data permintaan
pengiriman pupuk dengan menekan tombol “X”.
Hasil yang Sistem akan menghilangkan form permintaan
diharapkan pengiriman pupuk dan kembali ke menu permintaan
pengiriman pupuk.
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Detail Data Permintaan Pengiriman Pupuk
Tabel 7.23.3 Kasus Uji Tidak Mengisi Salah Satu Detail Data Permintaan
Pengiriman Pupuk.
Nama Kasus Uji Tidak Mengisi Salah Satu Detail Data Permintaan
Pengiriman Pupuk
Prosedur 1. Aktor menekan tombol respon permintaan
2. Sistem menampilkan form pengisian detail data
3. Aktor tidak memasukkan salah satu detail data yang
diperlukan yaitu, plat nomor kendaraan pengangkut,
pengambilan pupuk.

Hasil
Status
111
7.3.24 Pengujian Validasi Melihat Daftar Pupuk yang Hilang di Gudang
Penyangga
Pada kasus pengujian validasi melihat data pupuk yang hilang di gudang
penyangga terdapat satu kasus uji yaitu kasus uji berhasil melihat data pupuk yang
hilang di gudang penyangga yang dapat dilihat pada tabel 7.24.1.
A. Kasus Uji Berhasil Melihat Data pupuk yang hilang di gudang penyangga
Tabel 7.22.1 Kasus Uji Berhasil Melihat Data Pupuk yang Hilang di Gudang
Penyangga
Nama Kasus Uji Melihat Data Pupuk yang Hilang di Gudang Penyangga
Prosedur 1. Aktor memilih menu pupuk hilang
Hasil yang Sistem akan menampilkan data pupuk yang hilang
diharapkan digudang penyangga pada halaman pupuk hilang
Hasil
Status
7.3.25 Pengujian Validasi Melihat Hasil Stok Opname yang Sudah

Divalidasi
Pada kasus pengujian validasi melihat data hasil stok opname yang sudah
divalidasi terdapat satu kasus uji yaitu kasus uji berhasil melihat data hasil stok
opname yang sudah divalidasi yang dapat dilihat pada tabel 7.25.1.
A. Kasus Uji Berhasil Melihat Data Hasil Stok Opname yang Sudah Divalidasi
Tabel 7.25.1 Kasus Uji Berhasil Melihat Data Hasil Stok Opname yang Sudah
Divalidasi
Nama Kasus Uji Melihat Data Hasil Stok Opname yang Sudah Divalidasi
Prosedur 1. Aktor memilih menu stok opname selesai
Hasil yang Sistem akan menampilkan data hasil stok opname yang
diharapkan sudah divalidasi pada halaman stok opname selesai
Hasil
Status
7.3.26 Pengujian Validasi Membuat Perhitungan Stok Opname

Pada kasus pengujian validasi membuat perhitungan stok opname
terdapat tiga kasus uji yaitu kasus uji berhasil membuat perhitungana stok
opname yang dapat dilihat pada tabel 7.26.1, kasus uji batal membuat
perhitungan stok opname yang dapat dilihat pada tabel 7.26.2, dan kasus uji tidak
112
mengisi salah satu data perhitungan stok opname yang dapat dilihat pada tabel
7.26.3.
A. Kasus Uji Berhasil Membuat Perhitungan Stok Opname
Tabel 7.26.1 Kasus Uji Berhasil Membuat Perhitungan Stok Opname
Nama Kasus Uji Berhasil Membuat perhitungan Stok Opname
Prosedur 1. Aktor menekan tombol buat perhitungan pada
2. Sistem menampilkan form penambahan Perhitungan
Stok Opname
3. Sistem secara otomatis mengunci fitur pupuk keluar
dan pupuk masuk.
tinggi, jumlah bag, jumlah ton, lebihan bag, lebihan ton,
total bag, total ton.
diharapkan perhitungan stok opname berhasil dibuat.
Hasil
Status
B. Kasus Uji Batal Membuat Data Perhitungan Stok Opname

Tabel 7.26.2 Kasus Uji Batal Membuat Perhitungan Stok Opname
Nama Kasus Uji Batal Membuat Perhitungan Stok Opname
Prosedur 1. Aktor menekan tombol buat perhitungan stok
opname
2. Sistem menampilkan form pengisian data perhitungan
stok opname.
3. Aktor batal membuat data perhitungan stok opname
Hasil yang Sistem akan menghilangkan form perhitungan stok
diharapkan opname dan kembali ke menu perhitungan stok opname
Hasil
Status
113
C. Kasus Uji Tidak Mengisi Salah Satu Data Perhitungan Stok Opname
Tabel 7.21.3 Kasus Uji Tidak Mengisi Salah Satu Data Perhitungan Stok
Opname.
Nama Kasus Uji Tidak Mengisi Salah Satu Data Perhitungan Data Stok
Opname
Prosedur 1. Aktor menekan tombol buat data perhitungan stok
opname.
2. Sistem menampilkan form pengisian data perhitungan
stok opname.
diperlukan yaitu, tanggal, jam, kode Gudang penyangga,
jenis pupuk, berat kemasan, area, kunci, Panjang, lebar,
tinggi, jumlah bag, jumlah ton, lebihan bag, lebihan ton,
total bag, total ton.

Hasil
Status
7.3.27 Pengujian Validasi Melihat Perhitungan Stok Opname

Pada kasus pengujian validasi melihat data perhitungan stok opname
terdapat satu kasus uji yaitu kasus uji berhasil melihat data perhitungan stok
opname yang dapat dilihat pada tabel 7.27.1.
A. Kasus Uji Berhasil Melihat Data Perhitungan Stok Opname
Tabel 7.27.1 Kasus Uji Berhasil Melihat Data Perhitungan Stok Opname
Nama Kasus Uji Melihat Data Perhitungan Stok Opname
Prosedur 1. Aktor memilih menu perhitungan stok opname.
Hasil yang Sistem akan menampilkan data perhitungan stok
diharapkan opname pada halaman perhituangan stok opname.
Hasil
Status
114
7.3.28 Pengujian Validasi Melihat Hasil Stok Opname
Pada kasus pengujian validasi melihat data hasil stok opname terdapat satu
kasus uji yaitu kasus uji berhasil melihat data hasil stok opname yang dapat dilihat
pada tabel 7.28.1.
A. Kasus Uji Berhasil Melihat Data Hasil Stok Opname
Tabel 7.28.1 Kasus Uji Berhasil Melihat Data Hasil Stok Opname
Nama Kasus Uji Melihat Data Hasil Stok Opname
Prosedur 1. Aktor memilih menu hasil stok opname.
Hasil yang Sistem akan menampilkan data hasil stok opname pada
diharapkan halaman hasil stok opname.
Hasil
Status
7.3.29 Pengujian Validasi Melihat Peta Kondisi Stok

Pada kasus pengujian validasi melihat data peta kondisi stok terdapat satu
kasus uji yaitu kasus uji berhasil melihat data peta kondisi stok yang dapat dilihat
pada tabel 7.29.1.
A. Kasus Uji Berhasil Melihat Data Peta Kondisi Stok
Tabel 7.29.1 Kasus Uji Berhasil Melihat Data Peta Kondisi Stok
Nama Kasus Uji Melihat Data Peta Kondisi Stok
Prosedur 1. Aktor memilih menu peta stok.
Hasil yang Sistem akan menampilkan peta kondisi stok pada
diharapkan halaman peta stok.
Hasil
Status
7.3.30 Pengujian Validasi Membuat Laporan Pupuk Rusak

Pada kasus pengujian validasi membuat laporan pupuk rusak terdapat tiga
kasus uji yaitu kasus uji berhasil membuat laporan pupuk rusak yang dapat dilihat
pada tabel 7.30.1, kasus uji batal membuat laporan pupuk rusak yang dapat dilihat
pada tabel 7.30.2, dan kasus uji tidak mengisi salah satu data laporan pupuk rusak
A. Kasus Uji Berhasil Membuat Laporan Pupuk Rusak
Tabel 7.30.1 Kasus Uji Berhasil Membuat Laporan Pupuk Rusak
115
Nama Kasus Uji Berhasil Membuat Laporan Pupuk Rusak
Prosedur 1. Aktor menekan tombol lapor pupuk rusak pada
2. Sistem menampilkan form penambahan Pupuk Rusak
3. Aktor menambahkan data laporan pupuk rusak yaitu
jenis pupuk, qty, kemasan, foto, alasan kerusakan
pupuk.
Hasil yang Akan menampilkan pesan berhasil, dan data laporan

diharapkan pupuk rusak berhasil dibuat.
Hasil
Status
B. Kasus Uji Batal Membuat Data Laporan Pupuk Rusak

Tabel 7.30.2 Kasus Uji Batal Membuat Laporan Pupuk Rusak
Nama Kasus Uji Batal Membuat Laporan Pupuk Rusak
Prosedur 1. Aktor menekan tombol buat laporan pupuk rusak
2. Sistem menampilkan form pengisian data laporan
pupuk rusak.
3. Aktor batal membuat data laporan pupuk rusak
Hasil yang Sistem akan menghilangkan form laporan pupuk rusak
diharapkan dan kembali ke menu laporan pupuk rusak
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Laporan Pupuk Rusak
Tabel 7.30.3 Kasus Uji Tidak Mengisi Salah Satu Data Laporan Pupuk Rusak.
Nama Kasus Uji Tidak Mengisi Salah Satu Data Laporan Pupuk Rusak
Prosedur 1. Aktor menekan tombol buat data laporan pupuk
rusak.
2. Sistem menampilkan form pengisian data laporan
pupuk rusak.
116
diperlukan yaitu, jenis pupuk, qty, kemasan, foto, alasan
kerusakan pupuk.

Hasil
Status
7.3.31 Pengujian Validasi Melihat Laporan Pupuk Rusak

Pada kasus pengujian validasi melihat data laporan pupuk rusak terdapat
satu kasus uji yaitu kasus uji berhasil melihat data laporan pupuk rusak yang dapat
A. Kasus Uji Berhasil Melihat Data Laporan Pupuk Rusak
Tabel 7.31.1 Kasus Uji Berhasil Melihat Data Laporan Pupuk Rusak
Nama Kasus Uji Melihat Data Laporan Pupuk Rusak
Prosedur 1. Aktor memilih menu pupuk rusak.
Hasil yang Sistem akan menampilkan daftar laporan pupuk rusak
diharapkan pada halaman pupuk rusak
Hasil
Status
7.3.32 Pengujian Validasi Penerimaan Pupuk

Pada kasus pengujian validasi penerimaan pupuk terdapat tiga kasus uji
yaitu kasus uji berhasil validasi penerimaan pupuk yang dapat dilihat pada tabel
7.32.1, kasus uji batal validasi penerimaan pupuk yang dapat dilihat pada tabel
7.32.2, dan kasus uji tidak mengisi salah satu data validasi penerimaan pupuk yang
A. Kasus Uji Berhasil Validasi Penerimaan Pupuk
Tabel 7.32.1 Kasus Uji Berhasil Validasi Penerimaan Pupuk
Nama Kasus Uji Berhasil Validasi Penerimaan Pupuk
Prosedur 1. Aktor memilih tombol pupuk diterima.
2. Sistem menampilkan form Validasi Penerimaan Pupuk
dengan data pupuk yang diinginkan
117
yaitu qty diterima.
Hasil yang Sistem akan menampilkan pesan berhasil, dan status
diharapkan pengiriman pupuk yang diinginkan berubah menjadi
diterima.
Hasil
Status
B. Kasus Uji Batal Validasi Penerimaan Pupuk

Tabel 7.32.2 Kasus Uji Batal Validasi Penerimaan Pupuk
Nama Kasus Uji Batal Validasi Penerimaan Pupuk
Prosedur 1. Aktor menekan tombol tombol pupuk diterima
2. Sistem menampilkan form pengisian data validasi
penerimaan pupuk.
3. Aktor batal validasi penerimaan pupuk dengan
Hasil yang Sistem akan menghilangkan form validasi penerimaan
diharapkan pupuk dan kembali ke menu validasi penerimaan pupuk.
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Validasi Penerimaan Pupuk
Tabel 7.32.3 Kasus Uji Tidak Mengisi Salah Satu Data Validasi Penerimaan
Pupuk.
Nama Kasus Uji Tidak Mengisi Salah Satu Data Validasi Penerimaan
Pupuk
Prosedur 1. Aktor menekan tombol tombol pupuk diterima.
penerimaan pupuk.
diperlukan yaitu, qty diterima.

Hasil
118
Status
7.3.33 Pengujian Validasi Menambah Pupuk Keluar Gudang Penyangga

Pada kasus pengujian validasi menambah pupuk keluar gudang penyangga
terdapat tiga kasus uji yaitu kasus uji berhasil menambah pupuk keluar gudang
penyangga yang dapat dilihat pada tabel 7.33.1, kasus uji batal menambah pupuk
keluar gudang penyangga yang dapat dilihat pada tabel 7.33.2, dan kasus uji tidak
mengisi salah satu data pupuk keluar gudang penyangga yang dapat dilihat pada
tabel 7.33.3.
A. Kasus Uji Berhasil Menambah Pupuk Keluar Gudang Penyangga
Tabel 7.33.1 Kasus Uji Berhasil Menambah Pupuk Keluar Gudang Penyangga
Nama Kasus Uji Berhasil Menambah Rekanan Pengelola Gudang
Penyangga
Prosedur 1. Aktor menekan tombol tambah pupuk keluar
2. Sistem menampilkan form penambahan Pupuk Keluar

diharapkan pupuk keluar berhasil ditambahkan.
Hasil
Status
B. Kasus Uji Batal Menambah Data Pupuk Keluar Gudang Penyangga

Tabel 7.33.2 Kasus Uji Batal Menambah Pupuk Keluar Gudang Penyangga
Nama Kasus Uji Batal Menambah Pupuk Keluar Gudang Penyangga
Prosedur 1. Aktor menekan tombol tambah pupuk keluar gudang
penyangga.
2. Sistem menampilkan form pengisian data pupuk
keluar gudang penyangga.
3. Aktor batal menambah data pupuk keluar gudang
penyangga dengan menekan tombol “X”.
119
Hasil yang Sistem akan menghilangkan form pengisian pupuk
diharapkan keluar gudang penyangga dan kembali ke menu pupuk
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Pupuk Keluar Gudang Penyangga
Tabel 7.33.3 Kasus Uji Tidak Mengisi Salah Satu Data Pupuk Keluar Gudang
Penyangga.
Nama Kasus Uji Tidak Mengisi Salah Satu Data Pupuk Keluar Gudang
Penyangga
Prosedur 1. Aktor menekan tombol tambah data pupuk keluar
gudang penyangga.
2. Sistem menampilkan form pengisian data pupuk
diperlukan yaitu, nomor pengiriman, jenis pupuk, nama
distributor, nomor plat, nama supir, nama distributor.

Hasil
Status
7.3.34 Pengujian Validasi Melihat Pupuk Keluar Gudang Penyangga

Pada kasus pengujian validasi melihat data Pupuk Keluar Gudang
Penyangga terdapat satu kasus uji yaitu kasus uji berhasil melihat data Pupuk
Keluar Gudang Penyangga yang dapat dilihat pada tabel 7.34.1.
A. Kasus Uji Berhasil Melihat Data Pupuk Keluar Gudang Penyangga
Tabel 7.34.1 Kasus Uji Berhasil Melihat Data Pupuk Keluar Gudang Penyangga
Nama Kasus Uji Melihat Data Laporan Pupuk Keluar Gudang Penyangga
Prosedur Aktor menekan menu pupuk

diharapkan pupuk keluar berhasil ditampilkan.
120
Hasil
Status
7.3.35 Pengujian Validasi Melihat Stok Pupuk Keluar Masuk Gudang

Penyangga
Pada kasus pengujian validasi melihat stok pupuk keluar masuk gudang
penyangga terdapat satu kasus uji yaitu kasus uji berhasil melihat stok pupuk
keluar masuk gudang penyangga yang dapat dilihat pada tabel 7.35.1.
A. Kasus Uji Berhasil Melihat Data Stok Pupuk Keluar Masuk Gudang Penyangga
Tabel 7.35.1 Kasus Uji Berhasil Melihat Data Stok Pupuk Keluar Masuk Gudang
Penyangga
Nama Kasus Uji Melihat Data Stok Pupuk Keluar Masuk Gudang
Penyangga
Prosedur 1. Aktor menekan menu lalu-lintas stok
Hasil yang Sistem menampilkan data stok keluar masuk Gudang
diharapkan Penyangga yang diinginkan.
Hasil
Status
7.3.36 Pengujian Validasi Hasil Stok Opname

Pada kasus pengujian validasi Hasil Stok Opname terdapat dua kasus uji
yaitu kasus uji berhasil validasi hasil stok opname yang dapat dilihat pada tabel
7.36.1, kasus uji batal validasi hasil stok opname yang dapat dilihat pada tabel
7.36.2, dan kasus uji tidak mengisi salah satu data validasi hasil stok opname yang
A. Kasus Uji Berhasil Validasi Hasil Stok Opname
Tabel 7.36.1 Kasus Uji Berhasil Validasi Hasl Stok Opname
Nama Kasus Uji Berhasil Validasi Hasil Stok Opname
Prosedur 1. Aktor memilih hasil stok opname yang akan divalidasi.
2. Sistem menampilkan form Validasi Hasil Stok opname
yang diinginkan.
121
diharapkan stok opname yang diinginkan berubah menjadi
tervalidasi selesai.
Hasil
Status
B. Kasus Uji Batal Validasi Hasil Stok Opname

Tabel 7.36.2 Kasus Uji Batal Validasi Hasil Stok Opname
Nama Kasus Uji Batal Validasi Penerimaan Pupuk
Prosedur 1. Aktor menekan tombol validasi hasil stok opname.
hasil stok opname.
3. Aktor batal validasi penerimaan pupuk dengan
Hasil yang Sistem akan menghilangkan form validasi hasil stok
diharapkan opname dan kembali ke menu validasi hasil stok
opname.
Hasil
Status
C. Kasus Uji Tidak Mengisi Salah Satu Data Validasi Hasil Stok Opname
Tabel 7.36.3 Kasus Uji Tidak Mengisi Salah Satu Data Validasi Hasil Stok
Opname
Nama Kasus Uji Tidak Mengisi Salah Satu Data Validasi Hasil Stok
Opname
Prosedur 1. Aktor menekan tombol buat data validasi penerimaan
pupuk.
penerimaan pupuk.
diperlukan yaitu, qty diterima.

Hasil
122
Status
7.3.37 Pengujian Validasi Mengubah Status Keberangkatan

Pada kasus pengujian validasi mengubah data status keberagkatan
terdapat tiga kasus uji yaitu kasus uji berhasil mengubah data status
keberangkatan yang dapat dilihat pada tabel 7.37.1, dan kasus uji batal mengubah
data status keberangkatan yang dapat dilihat pada tabel 7.37.2.
A. Kasus Uji Berhasil Mengubah Data Satus Keberangkatan
Tabel 7.37.1 Kasus Uji Berhasil Mengubah Data Status Keberangkatan
Nama Kasus Uji Berhasil Mengubah Data Status Keberangkatan
Prosedur 1. Aktor menekan tombol ubah status keberangkatan
Keberangkatan.
diharapkan permintaan pengiriman pupuk yang diinginkan berubah
menjadi berangkat dari Gudang pusat.
Hasil
Status
B. Kasus Uji Batal Mengubah Data Status Keberangkatan

Tabel 7.37.2 Kasus Uji Batal Mengubah Status Keberangkatan
Nama Kasus Uji Batal Mengubah Data Status Keberangkatan
Prosedur 1. Aktor menekan tombol ubah data status
keberangkatan.
2. Sistem menampilkan form pengisian data status
keberangkatan.
Hasil yang Sistem akan menghilangkan form pengisian status
diharapkan keberangkatan dan kembali ke menu status
keberangkatan.
Hasil
123
Status
7.3.38 Pengujian Validasi Melihat Total Kehilangan Pupuk Saat

Pengiriman
Pada kasus pengujian validasi melihat total kehilangan pupuk saat
pengiriman terdapat satu kasus uji yaitu kasus uji berhasil melihat total kehilangan
pupuk saat pengiriman yang dapat dilihat pada tabel 7.38.1.
A. Kasus Uji Berhasil Melihat Data Total Kehilangan Pupuk Saat Pengiriman
Tabel 7.38.1 Kasus Uji Berhasil Melihat Data Total Kehilangan Pupuk Saat
Pengiriman
Nama Kasus Uji Melihat Data Total Kehilangan Pupuk Saat Pengiriman
Prosedur 1. Aktor memilih menu kehilangan pupuk

Hasil yang Sistem akan berhasil menampilkan data kehilangan
diharapkan pupuk oleh transportir pada halaman kehilangan pupuk
Hasil
Status
124
DAFTAR PUSTAKA
Ananta, N, Adi. 2014. Sistem Pendukung Keputusan Rekomendasi Kelayakan

Penerima Beasiswa Prestasi Menggunakan Metode Analytical Hierarchy
Process (AHP). Universitas Dian Nuswantoro Semarang.
Ardiyanto, B. M. Somantri, dan K. I. Satoto. 2011. Perancangan Sistem Informasi
Beasiswa Universitas Diponegoro Berbasis Web. Universitas Diponegoro.
Semarang.
Elizabeth, T. dan S. Darmawan. 2015. Sistem Informasi Pemakaian Sparepart
Mesin Packing pada PT. XYZ. Jatisi 1(2), Maret 2015, ISSN: 2407-4322, Hal:
164-165.
Fatta, H. A., 2007. Analisis dan Perancangan Sistem Informasi untuk Keunggulan
Bersaing Perusahaan dan Organisasi Modern. Penerbit ANDI. Yogyakarta.
Gaol, C. J. L. 2008. Sistem Aplikasi Manajemen Pemahaman dan Aplikasi. Grasindo.
Gunawan, Chandra Arie., Setiawan B dan Wibisono, A. 2014. Pengembangan
Webgis Untuk Inventory Monitoring Gudang Penyangga (Studi Kasus : Pt.
Petrokimia Gresik, Provinsi Jawa Timur). Jurnal POMITS
Irnawati, O., 2018. Implementasi Metode Waterfall Pada Sistem Informasi Stock
Opname. IJSE – Indonesian Journal on Software Engineering, 4(1), hal.223–
229.
Ismail, M. 2004. Konsep Sistem Aplikasi Manajemen. Universitas Sumatera Utara.
Medan.
McLeod, R. Jr, dan G. P.Schell. 2007. Management Information System, 10th ed.
Penerjemah Yulianto, A. A. dan A. R. Fitriani. 2008. Sistem Aplikasi
Manajemen, Edisi 10. Penerbit Salemba Empat. Jakarta.
Makridakis, Spyros; Wheelright, Steven C.; McGee, Victor E. 2000. Metode dan
Aplikasi Peramalan Jilid Dua. Terjemahan Suminto, Hari. Interaksara,
Batam.
Meredith, J. 1992. Theory Building through Conceptual Methods. International
Journal od Operations and Production Management, Vol. 13, no. 5, hal: 3-
11.
Neni dan N. Uluwiya. 2011. Sistem Informasi Administrasi Manufaktur pada CV.
Adinda Kencana Palembang. STMIK. Palembang.
Pandayin, A. H. 2012. Penerapan Metode User Centered Design (UCD) pada
Aplikasi Katalog Wisata Kuliner Berbasis Web. UIN Sunan Kalijaga.
Yogyakarta.
Pressman, R. 2010. Software Engineering: a Practitioner’s Approach. McGraw-Hill
Companies, Inc. New York.
125
Putra, A dan Hardiyanti, D, Yunika. 2011. Penentuan Penerima Beasiswa Dengan
Menggunakan Fuzzy Multiple Atribute Decission Making. Jurnal Sistem
Informasi (JSI), VOL. 3, NO. 1, April 2011.
Saputra, D. 2012. Model Pengembangan Sistem Informasi.
http://danylukman.blogspot.co.id/2012/10/metode-pengembangan-
sistem-informasi.html. Diakses pada tanggal 22 September 2015.
Sommerville, I. 2007. Software Engineering Eighth Edition. Pearson Education
Limited. US of America.
Subaweh, I. 2000. Sistem Informasi Akuntansi. Universitas Gunadarma. Depok.
Sutiyarini, Kusrini dan A. Sunyoto. 2013. Rancang Bangun Sistem Administrasi
Mahasiswa Berbasis Web Menggunakan Metode User Centered Design
(Studi Kasus: STIMIK AUB Surakarta). Politeknosains, Vol. XII, No. 2,
September 2013, hal: 72-80.
Tenardi, W. dan D. Agustina. 2013. Sistem Informasi Keuangan pada Sekolah St.
Agatha. STMIK GI MDP. Palembang.
Turban, Efraim, Aronson, J. E dan Liang, P, T. 2005. Decision Support System and
Intelligent Systems (7th Edition). Andi Offset, Yogyakarta.
Turban, E., RE, P. & RK, R., 2003. Introduction to Information Systems, 2nd Edition.
USA: s.n.
Widyanti, Y. 2006. Sistem Aplikasi Manajemen dan Evaluasi Perkuliahan. Seminar
Nasional Aplikasi Teknologi Informasi 2006, Juni 2006, ISSN: 1907-5022, Hal.:
57-60.
Wardaani, Dian Andarini. 2013. Aplikasi Inventory Control Stock Opname Barang
Habis Pakai (Bhp) Berbasis Web (Study Kasus Balai Laboratorium Kesehatan
D.I.Yogyakarta). UPN "Veteran" yogyakarta.
Yulianto, F. 2012. Perancangan Software Link Budget Calculator dengan Microsoft
Visual Basic. Amikom. Yogyakarta.
126
LAMPIRAN B HASIL WAWANCARA
A. WAWANCARA TAHAP PERTAMA

Wawancara tahap pertama di fokuskan pada aspek identifikasi masalah.
1. Apakah ada kendala yang anda dihadapi dalam pelaksanaan tanggung jawab
dan tugas Departemen Distribusi Wilayah PT. Petrokimia Gresik?
Jawaban:
Ada, mengenai stok opname dan pencatatan stok gudang penyangga.
2. Bisa dijelaskan masalah yang dihadapi sekarang mengenai stok opname itu
seperti apa?
Jawaban:
Secara periodik kami melakukan stock opname disetiap Gudang Penyangga,
selanjutnya kami akan memasukan data stok yang tercatat kedalam file
document untuk menjadi bahan stok opname nanti. Pada saat penghitungan
stok opname masih menghitung manual menggunakan kertas untuk nanti
hasilnya dimasukan kedalam file dokumen dan diprint untuk meminta tanda
tangan persetujuan dari kepala gudang. Karena hasil yang kami bawa berupa
hardcopy beberapa kali terjadi kehilangan dokumen sehingga kami harus
melakukan stok opname lagi. Jadi dana perjalanan kita habis banyak mas.
Belum lagi waktu sampai di kantor kita harus mengupdate kondisi stok
sesuai hasil stok opname. dua kali kerja tidak efisien mas. Padahal, dalam
sekali penugasan stok opname staff distribusi ditugaskan bisa untuk
melakukan stok opname untuk Gudang Penyangga dalam satu provinsi.
3. Secara periodik itu berapa lama sekali ya mas?

Jawaban:
Tidak pasti mas tergantung penugasan dari kantor.
4. Kenapa kegiatan stok opname ini harus dilakukan?

Jawaban:
Untuk memastikan stok yang ada digudang penyangga sesuai dengan stok
yang tercatat. Dari stok opname juga dapat diketahui adanya kecurangan
atau kehilangan pupuk di Gudang penyangga. Karena Gudang penyangga ini
tidak langsung dikelola oleh pegawai PT. Petrokimia Gresik melainkan
bekerja sama dengan rekanan pengelola.
127
5. Apakah ada keluhan dari perusahaan rekanan pengelola gudang penyangga?
Jawaban:
Yang saya tahu mereka sering mengeluh tidak mengetahui kehilangan itu
secara langsung setelah di stok opname. jadi mereka tahunya setelah ada
klaim tahunan. padahal menurut mereka jika mereka langsung mengetahui
adanya kehilangan bisa menjadi bahan pertimbangan untuk melakukan
suatu tindakan ke kepala gudang penyangganya, entah itu teguran atau apa.
6. Bisa dijelaskan seperti apa permasalahan dan dampak yang ada mengenai
pencatatan stok gudang penyangga?
Jawaban:
Selama ini untuk pemantauan data setiap gudang penyangga kami hanya
menggunakan data pelaporan berupa file dokumen yang dikirim oleh kepala
Gudang penyangga melalui email ke Departemen Distribusi Wilayah 1 untuk
selanjutnya nanti dimasukan kedalam file excel oleh staff diswil yaitu saya
khususnya. saya sering mengalami kendala dalam mengelola data yang
dikirimkan karena banyaknya email yang dikirim sehingga sering terjadi data
yang terlewat tidak terolah, dan itu membuat proses pengeloaan data
menjadi lama atau tidak efektif. Pemantauan data stok di gudang penyangga
juga masih menggunakan table data excel yang didalamnya berisi transaksi
keluar dan masuk stok. Sehingga berakibat sulitnya memantau stok disetiap
gudang penyangga secara cepat dan mudah. Padahal, kecepatan dan
kemudahan dalam memantau stok disetiap Gudang akan berpengaruh pada
proses pengawasan ketersediaan pupuk disetiap daerah untuk menghindari
adanya kekurangan stok pupuk. Karena jika terjadi kekurangan stok maka
kebutuhan petani didaerah tersebut tidak dapat terpenuhi dan akan
berpengaruh pada hasil pertaniannya. Padahal ketika data stok dapat dilihat
secara real time dan bisa dilihat oleh diswil bisa langsung ditindak lanjuti
dengan melakukan pengiriman dari Gudang pusat ke Gudang Penyangga.
Selain itu, Manager juga sulit memantau keadaan stok yang ada digudang-
gudang penyangga. untuk menjalankan tugasnya mengawasi pengendalian
stok yang ada dengan mudah, melakukan pengecekan melalui daftar table
excel sangatlah tidak efisien. Padahal, manager memiliki banyak sekali
kegiatan
7. Apa ada keluhan dari kepala Gudang penyangga?

Jawaban:
Ada mas, kepala gudang penyangga biasanya tidak tahu ada berapa truk
yang sedang dalam perjalanan menuju Gudang penyangga, jadi itu juga
kendalanya ketika pengangkutan muatan dari truk ke Gudang kekurangan
128
tenaga angkut. Tenaga angkut inikan pekerja lepas jadi dibayar harian ketika
ada banyak truk yang datang maka akan banyak tenaga yang dipekerjakan
pada hari itu.
Gresik, 9 Oktober 2018

Staff Distribusi Wilayah 1 Staff Distribusi Wilayah 1
PT. Petrokimia Gresik PT. Petrokimia Gresik
Rachmad Edy Rafianto Edwyk Sony Udaieby
129
B. WAWANCARA TAHAP KEDUA
Wawancara tahap kedua di fokuskan pada aspek pengenalan alur proses yang
ada dan pengumpulan data.
1. Bagaimana alur proses stok opname dari penugasan sampai selesai?
Jawaban:
Pertama manager melalui staffnya diswil 1 akan menugaskan tim untuk
melakukan stok opname biasanya terdiri dari dua orang dalam satu tim.
Penugasannya sesuai area tanggung jawab tim tersebut satu tim satu
provinsi. Setelah itu tim tersebut mempersiapkan data-data keluar-masuk
pupuk sesuai yang tercatat laporan yang ada di kantor. Setelah itu
berangkat menuju gudang-gudang penyangga. Disana tim petugas stok
opname akan menghitung stok fisik pupuk yang benar-benar ada disana
dan menghentikan transaksi keluar dan masuk pupuk pada Gudang
penyangga tersebut. Apakah benar jumlah pupuk yang ada di gudang
penyangga sesuai dengan yang tercatat dikantor, setelah itu petugas akan
melaporkan dalam berita acara. Dalam berita acara tersebut juga perlu
persetujuan kepala gudang penyangga mas meskipun pada
perhitungannya sesuai ataupun tidak. Setelah semua selesai petugas akan
pindah ke gudang berikutnya dan seterusnya. Setelah selesai semua nanti
petugas akan serahkan berita acara per stok opname yang telah petugas
lakukan ke kantor PT. Petrokimia Gresik. Setelah itu data-data hasil final
dari perhitungan stok opname per gudang penyangga di serahkan pada
Manager Diswil 1 untuk laporan pertanggung jawaban mas.
2. Jika terjadi ketidaksesuaian stok di gudang penyangga apa yang akan

dilakukan?
Jawaban:
Jika ketidaksesuain itu karena kelalaian atau kecurangan dari pengelola
gudang penyangga (misalnya: hilang atau dicuri) maka akan dilakukan
klaim penggantian pupuk oleh PT. Petrokimia Gresik kepada perusahaan
rekanan pengelola gudang penyangga yang bertanggung jawab pada
gudang tersebut.
3. Apa data yang harus dimasukkan ke perhitungan stock opname mas ?

Jawaban:
Area, Perhitungan dengan metode kunci, hasil, lebihan, total. Nanti saya
berikan filenya untuk lebih jelasnya.
130
4. Apa saja yang dilaporkan dalam berita acara dari hasil perhitungan stok
opname itu mas ?
Jawaban:
Stok fisik, mutasi pupuk, hasil stok opname. Nanti saya berikan juga filenya
agar lebih jelas.
5. Untuk penjemputan pupuk dari Gudang Pusat dan diantarkan ke Gudang

Penyangga bagaimana mas alurnya ?
Jawaban:
Dari diswil membuat permintaan penjemputan pupuk ke Gudang Pusat
dan mengimkan ke Gudang Penyangga di daerah yang diinginkan kepada
Rekanan Transportir yang bertanggung jawab di daerah tersebut. Setelah
itu rekanan transportir menyetujui dan mengisi data-data truk yang
digunakan dalam penjemputan pupuk di gudang pusat hingga pengiriman
ke gudang penyangga. Setelah truk sampai di gudang pusat langsung
diantar ke gudang penyangga.
6. Apa data yang harus dimasukkan ke permintaan diswil terkait permintaan

pupuk ?
Jawaban:
rekanan transportir, gudang penyangga, jenis pupuk, nomor plat, qty (
banyak pupuk ) dalam satuan ton, dan deadline. Nanti ada datanya saya
berikan dalam bentuk excel mas
7. Apa data yang harus dimasukkan dari rekanan transportir yang akan
melakukan penjemputan pupuk berdasar permintaan diswil mas ?
Jawaban:
ekanan transportir memasukkan data yaitu tanggal, nomor plat, dan nama
supir yang akan mengengkut pupuk teresebut, Nanti juga ada datanya mas
saya kasih juga
8. Data apa saja yang dilaporkan kepala gudang penyangga kepada

departemen distribusi?
Jawaban:
Pupuk masuk (Jenis pupuk, berat pupuk yang diterima, transportir), pupuk
keluar (jenis pupuk, berat pupuk yang keluar, distributor yang mengambil),
Sisa kapasitas gudang, pupuk rusak.
9. Data apa saja yang diperlukan Departemen Distribusi wilayah untuk

diketahui secara cepat dan realtime?
131
Jawaban:
Stok pupuk digudang, stok buffer ( dalam perjalanan dari gudang pusat ke
gudang penyangga ), indikator kondisi stok disuatu daerah apakah kurang
atau aman.
10. Apa indikator bahwa stok didaerah dikatakan aman dan kurang?
Jawaban:
Diswil sudah menentukan dan memutuskan stok kritis per jenis pupuk di
setiap daerah kepada staff Distribusi Wilayah 1 yaitu saya mas.
11. Apa saja jenis pupuk yang dikirimkan di gudang penyangga?

Jawaban:
UREA, ZA, SP-36, PHONSKA dan PETROGANIK.
Gresik, 10 Oktober 2018

Staff Distribusi Wilayah 1 Staff Distribusi Wilayah 1
PT. Petrokimia Gresik PT. Petrokimia Gresik
Rachmad Edy Rafianto Edwyk Sony Udaieby
132
133

Skripsi 4.0

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

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

Skripsi 4.0

Diunggah oleh

Hak Cipta:

Format Tersedia

PENGEMBANGAN SISTEM APLIKASI MANAJEMEN

Commented [F1]: layout

Untuk memenuhi sebagian persyaratan

PROGRAM STUDI TEKNIK INFORMATIKA

Assalamu’alaikum Warrahmatullahi Wabarakatuh. Alhamdulillahi

1.1 Latar belakang

1.2 Rumusan masalah

1.5 Batasan masalah

1. Sistem hanya diterapkan di PT. Petrokimia Gresik.

1.6 Sistematika pembahasan

2.1 Kajian Pustaka

2.2 Rekayasa Perangkat Lunak

2.3.1 Metode Waterfall

Gambar 2.1 Model Waterfall Commented [F5]: ??

Sumber: Sommerville (2011)

1. Analisis Kebutuhan / Requirement

Keunggulan yang dimiliki dari metode Waterfall ini adalah:

NO GAMBAR NAMA KETERANGAN

Menspesifikasikan bahwa use

2.4.3 Class Diagram

2.5 PT. Petrokimia Gresik

Gambar 2.2 Alur Distribusi PT. Petrokimia Gresik

2.6 Sistem Aplikasi Manajemen

Gambar 2.3 Model SIstem Aplikasi Manajemen

2.7 Pengujian Sistem

Gambar 3.1 Diagram Alir Penelitian

3.1 Studi Literatur

3.2 Analis Kebutuhan

3.3 Perancangan Sistem

3.6 Penarikan Kesimpulan dan Saran

Analisis kebutuhan merupakan tahapan awal untuk mengembangkan sistem.

4.1 Deskripsi Sistem

4.2 Identifikasi Aktor

4.3 Aturan Penomoran

Digit / nomor kebutuhan

Kode untuk deskripsi

Kode jenis kebutuhan

Singkatan nama Sistem

Digit / nomor kebutuhan

Kode untuk spesifikasi

Kode jenis kebutuhan

Singkatan nama Sistem

Kebutuhan Non Fungsional :

Kode jenis kebutuhan

Singkatan nama Sistem

4.4 Kebutuhan Fungsional

Aktor harus dapat melihat data

Operator Diswil harus dapat

penyangga yang terdiri dari nama

Melihat Aktor harus dapat melihat data

Mengubah Aktor harus dapat mengubah data

terdiri dari kode tim, nama

Mengisi Detail Aktor harus dapat mengisi detail

26. Operator Membuat Aktor harus dapat membuat

jumlah bag, jumlah ton, lebihan

Operator Aktor harus dapat melihat

Aktor harus dapat membuat

Operator Melihat Pupuk Aktor harus dapat menambah

Aktor harus dapat melihat data

Melihat Total Aktor harus dapat melihat total

nomor pengiriman, tanggal

4.5 Kebutuhan Non-Fungsional