Upload
meli-amelia
View
1.113
Download
6
Embed Size (px)
Citation preview
PERANCANGAN SISTEM INFORMASI INVENTORI
PADA SALEMBA TOKO BUKU
Diajukan Untuk Memenuhi Syarat Kelulusan
Mata Kuliah Perancangan Sistem Informasi
DisusunOleh :
Aminatul Rosidah NPM 212.1.63.0016
Meli Amelia NPM 212.1.63.0014
AKADEMI MANAJEMEN INFORMATIKA DAN KOMPUTER
AMIK BOGOR
2014
LEMBAR PENGESAHAN
Perancangan Sistem Informasi Inventori
Pada Salemba Toko Buku
Untuk Nilai Akhir Mata Kuliah Perancangan Sistem Informasi
Disetujui oleh:
Pembimbing Mata Kuliah
( Charmiyanti Nurkentjana Aju, S.Kom
Ketua Program Studi
( Zulkarnaen NS, S.Kom)
Penguji I
( Zulkarnaen NS, S.Kom)
Penguji II
( Zulkarnaen NS, S.Kom)
KATA PENGANTAR
Segala puji syukur penulis panjatkan kehadirat Allah SWT, karena atas limpahan
rahmat dan hidayah-Nya penulis dapat menyelesaikan Makalah Penelitian yang berjudul
“Perancangan Sistem Informasi Inventori Pada Salemba Toko Buku”. Makalah ini
disusun sebagai menyelesaikan mata kuliah Perancangan Sistem Informasi, jurusan
Manajemen Informatika di AMIK Bogor.
Dalam penyusunan Makalah ini penulis banyak mendapat saran, dorongan,
bimbingan dari berbagai pihak. Oleh karena itu dengan segala hormat dan kerendahan hati
perkenankanlah penulis mengucapkan terima kasih kepada :
1. Ibu Charmiyanti Nurkentjana Aju, S.Kom selaku Dosen Pengajar
sekaligus Dosen Pembimbing.
2. Bapak Zulkarnaen NS, S.Kom selaku ketua Program Studi.
3. Salemba Toko Buku selaku Objek Penelitian.
4. Semua pihak yang telah membantu penyelesaian makalah ini.
Penulis menyadari bahwa makalah yang penulis susun jauh dari kata sempurna,
untuk itu penulis mengharapkan kritik dan saran yang sifatnya membangun, dan tidak lupa
penulis ucapkan terima kasih atas segala perhatian dan penulis berharap semoga makalah ini
dapat bermanfaat bagi semua pihak.
Bogor, Oktober 2014
Penulis
DAFTAR ISI
LEMBAR PENGESAHAN ....................................................................... i
KATA PENGANTAR .............................................................................. ii
DAFTAR ISI................................................................................................................... iii
BAB I. PENDAHULUAN
1.1................................................................................................................... Latar Belakang
.................................................................................................................. 1
1.2................................................................................................................... Tujuan
.................................................................................................................. 2
1.3................................................................................................................... Sasaran
.................................................................................................................. 3
1.4................................................................................................................... Manfaat
.................................................................................................................. 3
1.5................................................................................................................... Batasan Masalah
.................................................................................................................. 3
BAB II. LANDASAN TEORI
2.1 Teori Umum............................................................................................ 5
2.1.1 Sistem Informasi......................................................................... 5
2.1.2 Basis Data (Database)................................................................. 7
2.1.2.1 Entity-Relationship Diagram (Diagram ERD)................... 8
2.1.3 Unified Modeling Language (UML)........................................... 10
2.1.3.1 Diagram Modeling Language (UML)................................ 12
1. Usecase Diagram (Diagram Usecase) ................................... 12
2. Class Diagram (Diagram Kelas)............................................ 17
3. Sequence Diagram (Diagram Aktivitas)................................ 18
4. Aktivity Diagram..................................................................... 19
5. Deployment Diagram ............................................................. 20
2.1.4 Feasibility Study (Studi Kelayakan)............................................ 20
2.1.4.1 Operasional Feasibility (Kelayakan Operasional)............... 21
2.1.4.2 Kelayakan Teknis................................................................. 21
2.1.4.3 Kelayakan Jadwal................................................................. 21
2.1.4.4 Kelayakan Ekonomis............................................................ 21
2.1.5 ID Card dan Mesin EDC............................................................... 22
2.1.6 Teknologi Barcode........................................................................ 24
2.2 Jaringan Komputer............................................................................. 27
2.2.1 Local Area Network (LAN)........................................................ 27
2.2.2 Two Tier...................................................................................... 28
2.3 MySQL .............................................................................................. 28
2.4 Visual Basic 2010 .............................................................................. 29
2.5 Objek Pengembangan ........................................................................ 30
2.6 Kerangka Pemikiran........................................................................... 31
BAB III. ANALISA SISTEM
3.1 Jadwal Proyek .................................................................................... 32
3.2 Analisa Kelayakan Sistem.................................................................. 32
3.2.1 Kelayakan Ekonomi ................................................................... 32
3.2.2 Kelayakan Teknis ....................................................................... 38
3.2.3 Kelayakan Jadwal ....................................................................... 39
3.2.4 Kelayakan Operasional ............................................................... 40
3.3 Analisa Proses Bisnis yang Berjalan ................................................. 41
3.4 Analisa Proses Bisnis Sistem Baru yang Dikembangkan................... 42
3.5 Konstruksi Sistem yang Dikembangkan ............................................ 43
3.6 Skenario Sistem yang dikembangkan ................................................ 44
BAB IV. PERANCANGAN SISTEM
4.1 Diagram Konteks ......................................................... 45
4.2 Daftar Istilah Pelaku Bisnis........................................... 46
4.3 Identifikasi Use Case ................................................... 47
4.4 Use Case Naratif .......................................................... 48
4.4.1 Persyaratan Bisnis ............................................. 48
4.4.1.1 Persyaratan Bisnis Login .......................... 48
4.4.1.2 Persyaratan Bisnis Input Data Barang.......
4.4.1.3 Persyaratan Bisnis Input Data
Penerimaan Barang................................... 49
4.4.1.4 Persyaratan Bisnis Penjualan Barang........ 49
4.4.1.5 Persyaratan Bisnis Pesanan Barang.......... 50
4.4.1.6 Persyaratan Bisnis Return Barang............. 50
4.4.1.7 Persyaratan Bisnis Cek Harga................... 51
4.4.1.8 Persyaratan Bisnis Look Up Data
Penerimaan Barang................................... 51
4.4.1.9 Persyaratan Bisnis Look Up Data
Penjualan Barang......................................52
4.4.1.10 Persyaratan Bisnis Look Up Data
Persediaan Barang.................................... 52
4.4.1.11 Persyaratan Bisnis Look Up Data Pesanan
Barang ...................................................... 53
4.4.1.12 Persyaratan Bisnis Look Up Data Return
Barang....................................................... 53
4.4.1.13 Persyaratan Bisnis Update Data
Penerimaan Barang................................... 54
4.4.1.14 Persyaratan Bisnis Update Data Pesanan
Barang....................................................... 54
4.4.1.15 Persyaratan Bisnis Update Data Return
Barang....................................................... 55
4.4.1.16 Persyaratan Bisnis Cetak Laporan............. 55
4.4.1.17 Persyaratan Bisnis Cetak Struck
Pembayaran.............................................. 56
4.4.2 Analisa Sistem.................................................... 56
4.4.2.1 Analisa Sistem Login ................................. 56
4.4.2.2 Analisa Sistem Input Data Barang.............
4.4.2.3 Analisa Sistem Input Data Penerimaan
Barang....................................................... 57
4.4.2.4 Analisa Sistem Penjualan Barang............... 59
4.4.2.5 Analisa Sistem Pesanan Barang ................ 60
4.4.2.6 Analisa Sistem Return Barang................... 61
4.4.2.7 Analisa Sistem Cek Harga ........................ 63
4.4.2.8 Analisa Sistem Look Up Data Penerimaan
Barang....................................................... 64
4.4.2.9 Analisa Sistem Look Up Data Penjualan
Barang ...................................................... 65
4.4.2.10 Analisa Sistem Look Up Data Persediaan
Barang ...................................................... 66
4.4.2.11 Analisa Sistem Look Up Data Pesanan
Barang ...................................................... 67
4.4.2.12 Analisa Sistem Look Up Return Barang ..... 69
4.4.2.13 Analisa Sistem Update Data Penerimaan
Barang....................................................... 70
4.4.2.14 Analisa Sistem Update Data Pesanan
Barang ...................................................... 71
4.4.2.15 Analisa Sistem Update Data Return
Barang....................................................... 72
4.4.2.16 Analisa Sistem Cetak Laporan................... 73
4.4.2.17 Analisa Sistem Cetak Struk Pembayaran . .
74
4.4.3 Desain Sistem..................................................... 56
4.4.3.1.....................................................................Desain Sistem Login
...................................................................... 56
4.4.3.2.....................................................................Desain Sistem Input Data Barang
......................................................................
4.4.3.3.....................................................................Desain Sistem Input Data Penerimaan
Barang........................................................... 57
4.4.3.4.....................................................................Desain Sistem Penjualan Barang
...................................................................... 59
4.4.3.5.....................................................................Desain Sistem Pesanan Barang
...................................................................... 60
4.4.3.6.....................................................................Desain Sistem Return Barang
...................................................................... 61
4.4.3.7.....................................................................Desain Sistem Cek Harga
...................................................................... 63
4.4.3.8.....................................................................Desain Sistem Look Up Data Penerimaan
Barang........................................................... 64
4.4.3.9.....................................................................Desain Sistem Look Up Data Penjualan
Barang .......................................................... 65
4.4.3.10.....................................................................Desain Sistem Look Up Data Persediaan
Barang .......................................................... 66
4.4.3.11.....................................................................Desain Sistem Look Up Data Pesanan
Barang .......................................................... 67
4.4.3.12.....................................................................Desain Sistem Look Up Return Barang
...................................................................... 69
4.4.3.13.....................................................................Desain Sistem Update Data Penerimaan
Barang........................................................... 70
4.4.3.14.....................................................................Desain Sistem Update Data Pesanan
Barang .......................................................... 71
4.4.3.15.....................................................................Desain Sistem Update Data Return Barang
...................................................................... 72
4.4.3.16.....................................................................Desain Sistem Cetak Laporan
...................................................................... 73
4.4.3.17.....................................................................Desain Sistem Cetak Struk Pembayaran
...................................................................... 74
4.5 Diagram Ketergantungan Use Case............................. 96
4.5.1 Inheritance................................................... 96
4.5. 2 Extension.................................................... 96
4.5.2 Depends On................................................. 99
4.6 Use Case Diagram (Diagram Use Case)....................... 101
4.7 Rancangan Database................................................... 102
4.7.1 Entity Relationship Diagram (ERD) .................... 103
4.7.2 Relasi Antar Tabel .............................................. 124
4.7.3 Spesifikasi File.................................................... 124
4.7.3.1 Tabel Barang................................................. 124
4.7.3.2 Tabel Pegawai................................................ 124
4.7.3.3 Tabel Penerimaan Barang............................. 124
4.7.3.4 Tabel Detail Penerimaan Barang................... 126
4.7.3.5 Tabel Penjualan Barang ................................ 126
4.7.3.6 Tabel Detail Penjualan Barang....................... 126
4.7.3.7 Tabel Pesanan Barang................................... 126
4.7.3.8 Tabel Persediaan Barang .............................. 127
4.7.3.9 Tabel Return Barang...................................... 127
4.7.4 Diagram Kelas..................................................... 128
4.8 Activity Diagram (Diagram Aktivitas)........................... 129
4.8.1 Activity Login ..................................................... 129
4.8.2 Activity Barang...................................................
4.8.3 Activity Input Data Penerimaan Barang.............. 129
4.8.4 Activity Penjualan Barang .................................. 130
4.8.5 Activity Pesanan Barang .................................... 130
4.8.6 Activity Return Barang........................................ 131
4.8.7 Activity Cek Harga.............................................. 131
4.8.8 Activity Look Up Data Penerimaan Barang......... 133
4.8.9 Activity Look Up Data Penjualan Barang............ 134
4.8.10 Activity Look Up Data Persediaan Barang........... 134
4.8.11 Activity Look Up Data Pesanan Barang.............. 135
4.8.12 Activity Look Up Data Return Barang................. 135
4.8.13 Activity Update Data Penerimaan Barang........... 137
4.8.14 Activity Update Data Pesanan Barang................ 137
4.8.15 Activity Update Data Return Barang................... 138
4.8.16 Activity Cetak Laporan ....................................... 139
4.8.17 Activity Cetak Struk Pembayaran ...................... 140
4.9 Sequence Diagram....................................................... 141
4.10 Deployment Diagram................................................... 153
4.11 Rancangan User Interface............................................ 154
BAB V. PENUTUP
5.1...........................................................................................Kesimpulan
........................................................................................... 137
5.2...........................................................................................Saran
........................................................................................... 138
DAFTAR PUSTAKA
BAB I
PENDAHULUAN
1.1 Latar Belakang Masalah
Perkembangan teknologi informasi saat ini sangatlah cepat,
hal ini diikuti dengan perkembangan disegala hal. Dengan adanya
perkembangan teknologi, maka penyebaran informasi sangatlah
cepat dan mudah. Untuk memenuhi kebutuhan informasi,
memerlukan pengolahan yang sistematis dengan cara membentuk
suatu sistem informasi. Sistem persediaan barang sangat
dibutuhkan oleh perusahaan, karena dengan sistem tersebut
perusahaan dapat mendukung operasional usaha.
Kegiatan pengelolaan barang dari tahun ke tahun terus
berlangsung. Pengelolaan ini bukan hanya melibatkan barang-
barang dan aset lama saja tetapi juga barang-barang dan aset
yang baru sehingga dengan demikian dari tahun ke tahun jumlah
barang ini bukannya berkurang bahkan terus bertambah. Dengan
bertambahnya jumlah barang-barang tersebut, tentunya
mendatangkan kesulitan tersendiri dalam pengelolaannya. Agar
pelaksanaan penyimpanan barang dalam gudang dapat terkelola
serta tertata dengan baik, maka perlu dikembangkan suatu aplikasi
berupa Sistem Informasi Inventori. Karena bila dengan cara biasa
(manual) seperti sekarang, cukup menyulitkan dalam hal
pengarsipan dan penelusuran data barang.
Sistem Informasi Inventori ini akan menampung semua data
dan informasi tentang barang-barang tersebut. Data dan informasi
ini nantinya akan terakumulasi dan tersimpan (diarsipkan) secara
terpusat pada suatu database. Dengan terpusatnya data dan
informasi ini, maka jelas akan mempermudah pengelolaan barang.
Pencarian data dan status barang akan lebih cepat, mudah, dan
efisien.
Sistem inventori Barang pada Salemba Toko Buku masih
menggunakan manual, menggunakan kertas formulir stock
barang. Dengan proses pengolahan data yang masih manual ini
seringkali terjadi penumpukan data (redundancy), sehingga
informasi akhir stock/persediaan barang yang dihasilkan terkadang
tidak sesuai dengan stock fisik yang ada digudang. Dari
permasalahan tersebut peneliti mengambil judul ”Perancangan
Sistem Informasi Inventori Pada Salemba Toko Buku”
1.2 Tujuan
Tujuan dari Perancangan Sistem Informasi ini adalah untuk
membangun atau merancang sistem informasi inventori dengan alur bisnis
yang dibutuhkan.
1.3 Sasaran
Ada pun sasaran yang akan dicapai pada pengembangan ini
adalah terbentuknya rancangan sistem informasi Inventori pada
Salemba Toko Buku.
1.4 Manfaat
1. Mahasiswa mampu memahami dan menganalisis faktor-
faktor yang mempengaruhi suatu sistem informasi.
2. Menerapkan ilmu-ilmu yang diperoleh selama kuliah.
3. Membandingkan teori-teori yang didapatkan di
perkuliahan dengan masalah yang sebenarnya di
lapangan.
1.5 Batasan Masalah
Sistem Inventori ini adalah suatu aplikasi yang meliputi
input, proses, output dimana data yang diolah merupakan
data seluruh perlengkapan yang ada di Salemba Toko Buku.
Sistem Inventori ini akan memberikan informasi tentang
nama barang, jumlah barang, keadaan barang dan beberapa
informasi yang terkait dengan barang, serta pembuatan
laporan, yaitu laporan peneriman barang, laporan penjualan
barang, laporan pesanan barang, laporan persediaan barang,
dan laporan return barang.
Berdasarkan identifikasi dan batasan masalah tersebut,
penulis membatasi permasalahan menjadi :
a . Membahas mengenai stok persediaan barang
b. Membahas mengenai return barang yang rusak
c. Membahas mengenai penjualan barang
d. Membahas mengenai pesanan barang ke pusat
BAB II
LANDASAN TEORI
2.1 Teori Umum
2.1.1 Sistem Informasi
Sistem adalah Sekumpulan objek-objek yang saling
berelasi dan berinteraksi serta hubungan antar objek bisa
dilihat sebagai satu kesatuan yang dirancang untuk mencapai
satu tujuan (Hanif Al Fatta, 2007 hal. 3).
Informasi adalah data yang telah diolah menjadi sebuah
bentuk yang berarti bagi penerimanya dan bermanfaat dalam
pengambilan keputusan saat ini atau mendatang (Hanif Al
Fatta, 2007 hal. 9).
Sistem Informasi adalah pengaturan orang, data, proses,
dan information technologi (IT)/teknologi informasi yang
berinteraksi untuk mengumpulkan, memproses, menyimpan,
dan menyediakan sebagai output informasi yang diperlukan
untuk mendukung sebuah organisasi (Jeffery L.Whitten, 2004
hal 10).
Kualitas informasi terkadang dipakai untuk menyatakan
informasi yang baik. Kualitas informasi sering kali diukur
berdasarkan:
a. Relevansi (kesesuaian);
b. Ketepatan waktu; dan
c. Keakurasian.
Dalam suatu sistem informasi terdapat komponen-
komponen seperti:
a. Perangkat keras (hardware) yaitu perangkat keras
komponen untuk melengkapi kegiatan memasukkan data,
memproses data, dan keluaran data.
b. Perangkat lunak (software) yaitu program dari
instruksi yang
diberikan ke komputer.
c. Database yaitu kumpulan data dan informasi yang
diorganisasikan sedemikian rupa sehingga mudah diakses
pengguna sistem informasi .
d. Jaringan komputer dan Komunikasi data yaitu
komunikasi yang menghubungkan antara pengguna dengan
sistem komputer secara bersama-sama ke dalam suatu
jaringan kerja yang efektif.
e. Manusia yaitu personel dari sistem informasi, meliputi
manager, analis, programmer, dan operator, serta
bertanggung jawab terhadap perawatan sistem.
f. Prosedur yaitu tatacara yang meliputi strategi, kebijakan,
metode, dan peraturan-peraturan dalam menggunakan
sistem informasi berbasis komputer (Hanif Al Fatta, 2007 hal.
10).
Gambar 2.1. Komponen Sistem Informasi
2.1.2 Basis Data (Database)
Database adalah kumpulan file yang saling terkait.
Kata kuncinya adalah”Saling terkait”. Database tidak
hanya kumpulan file. Record pada setiap file harus
memperbolehkan hubungan–hubungan untuk
menyimpan file-file lain (Jeffery L.Whitten, Hal 518).
Untuk mengelola basis data diperlukan perangkat
lunak yang disebut DBMS. DBMS adalah perangkat
lunak sistem yang memungkinkan pemakai
membuat, memelihara, mengontrol dan mengakses
basisdata dengan cara yang praktis.
Perangkat lunak yang didesain untuk mengelola
database disebut DBMS (Database Management
System). Contoh DBMS yang ada di pasaran adalah
Oracle,Microsoft SQL Server, MYSQL, Informix, Progress
4GL, Firebird dan FileMaker. DBMS sering digunakan oleh
Database Adminisator (DBA) untuk membuat sistem
database. Secara lebih rinci DBMS merupakan kumpulan
software program yang sangat kompleks untuk
mengontrol organisasi data dan alat penyimpanan data
di database. (Bambang Wahyudi, 2008 Hal 188).
2.1.2.1 Entity – RelationshipDiagram (Diagram E-R)
Model entity – Relationship (ER) pada
awalnya disampaikan oleh Peter di tahun 1976
sebagai suatu cara untuk menyatukan jaringan dan
menggambarkan relational database. Singkatnya,
model ER adalah sebuah model konseptual dari
data yang menggambarkan keadaan sebenarnya
dari entities dan relationship (Bambang Wahyudi,
2008 Hal 199).
Notasi-notasi simbolik di dalam Diagram E-R
yang digunakan adalah:
1. Entitas (entity), dilambangkan dengan persegi
panjang (rectangle);
2. Relasi (relationship), dilambangkan dengan belah
ketupat (diamonds);
3. Atribut(attribute),dilambangkan dengan elips
(ellipses atau ovals);
4. Garis penghubung (line links), dilambangkan dengan
gais (lines). (Bambang Wahyudi, 2008 Hal 199).
Gambar 2.2 Notasi-notasi Simbolik ERD
Ada beberapa tahapan membuat diagram ERD
yaitu :
1.Menentukan entitas Menentukan peran,
kejadian/kegiatan, lokasi, hal abstrak/konsep yang
datanya disimpan oleh end-user.
2. Menentukan atribut-atribut key dari masing-
masing himpunan entitas.
3. Tentukan hubungan antara sepasang entitas
menggunakan relationship matriks.
4. Tentukan kardinalitas (pemunculan suatu entitas
di entitas lainnya yang berhubungan).
2.1.3 Unified Modeling Language (UML)
UML adalah satu kumpulan konvensi pemodelan yang
digunakan untuk menunjukkan atau menggambarkan
sebuah sistem software yang terkait dengan objek (Jeffery
L.Whitten, 2004 Hal 408).
a. Objek
Objek adalah sesuatu yang ada atau dapat dilihat,
disentuh atau dirasakan dan user menyimpan serta
mencatat perilaku mengenai sesuatu itu. Setiap objek
memiliki dua karakteristik yaitu:
1. Atribut
Atribut adalah data yang mewakili karakteristik
interest tentang sebuah objek.
2. Behavior
Behavior adalah kumpulan dari sesuatu yang
dapat dilakukan oleh objek dan terkait dengan
fungsi-fungsi yang bertindak pada data objek
(atribut). Pada siklus berorientasi objek, perilaku
objek merujuk kepada metode, operasi, atau fungsi
(Jeffery L.Whitten, 2004 Hal 409).
b. Kelas
Kelas adalah satu set objek yang memiliki atribut
dan behavior yang sama. Kadang-kadang disebut object
class (Jeffery L.Whitten, 2004 Hal 410).
c. Generalisasi/Spesialisasi
Adalah sebuah teknik dimana atribut dan behavior
yang umum pada beberapa tipe kelas objek,
dikelompokkan (atau diabstraksi) kedalam kelasnya
sendiri, disebut supertype. Atribute dan metode kelas
objek supertype kemudian diwariskan oleh kelas objek
tersebut (subtype).
d. Inheritance
Adalah konsep dimana metode dan atau atribute
yang ditentukan di dalam sebuah objeck class dapat
diwariskan atau digunakan lagi oleh objeck class
lainnya(Jeffery L.Whitten, 2004 Hal 411).
UML menyediakan beberapa diagram visual yang
menunjukkan berbagai aspek dalam sistem, ada beberapa
diagram yang disediakan dalam UML, antara lain :
- Use Case Diagram
- Class Diagram
- Sequential Diagram
- Activity Diagram
- Deployment Diagram
2.1.3.1 Diagram Unifield Modeling Language (UML)
1. Use Case Diagram
Use case diagram adalah metode berbasis
text untuk menggambarkan dan
mendokumentasikan proses yang kompleks. Use
case menambahkan detail untuk kebutuhan yang
telah dituliskan pada definisi sistem kebutuhan. Use
case diagram dikembangkan oleh analisis sistem
bersama-sama dengan pengguna. Pada tahap
selanjutnya, berdasarkan use case ini, analisis
menyusun model data dan model proses (Hanif Al
Fatta,2007 hal.91).
Komponen Pembentuk Use-case Diagram
a. Actor / Pelaku
Actor / pelaku adalah segala sesuatu yang
perlu berinteraksi dengan sistem untuk
pertukaran informasi .
Ada 4 tipe macam pelaku :
Primary business actor(pelaku bisnis utama)
yaitu stakeholder yang terutama
mendapatkan keuntungan dari pelaksanaan
use case dengan menerima nilai yang
terukur atau terobservasi.
Primary system actor(Pelaku sistem utama)
yaitu stakeholder yang secara langsung
berhadapan dengan sistem untuk
menginisiasi untuk memicu kegiatan atau
sistem.
External server actor(Pelaku server
eksternal) yaitu stakeholder yang melayani
kebutuhan penggunan use case.
Exernal receiving actor(Pelaku penerima
teramati) yaitu stakeholder yang bukan
pelaku utama, tapi menerima nilai yang
terukur atau teramati(output) dari use
case(Jeffery L.Whitten, 2004 hal 259).
Gambar 2.3 Simbol actor / pelaku
b.Relationship (Hubungan)
Pada diagram use case, hubungan
digambarkan sebagai sebuah garis antara
dua simbol. Pemaknaan hubungan berbeda
– beda tergantung bagaimana garis
tersebut digambarkan dan tipe simbol apa
yang digunakan untuk menghubungkan
garis tersebut(Jeffery L.Whitten, 2004 hal
259). Perbedaan diantara hubungan –
hubungan yang ada pada diagram use case
yaitu :
1. Association (Gabungan)
Association yaitu hubungan antara
seorang pelaku dan satu use case
terbentuk kapan pun use case
menggambarkan interaksi antara
keduanya(Jeffery L.Whitten, 2004 hal
259).
2. Extension Use Case
Extension Use Case yaitu Use Case
yang terdiri dari langkah yang diekstraksi
dari Use Case yang lebih kompleks untuk
menyederhanakan masalah orisinal dan
karena itu memperluas fungsinya.
3. Depends On
Manager proyek atau developer
utama sangat perlu mengetahui Use
Case mana yang memiliki
ketergantungan pada Use Case lain
untuk menetapkan rangkaian Use Case
yang perlu dikembangkan.
4. Abstract Use Case
Use case yang mengurangi
redudansi antara dua atau lebih Use Case
lain dengan menggabungkan langkah-
langkah yang biasa ditemukan pada Use
Case tersebut(Jeffery L.Whitten, 2004 hal
260).
5. Inheritance
Pada saat dua atau lebih pelaku
berbagi kelakuan umum dengan kata
lain mereka dapat menginisiasi Use Case
yang sama maka yang paling baik adalah
mengekstrapolasi kelakuan umum dan
menetapkannya ke pelaku abstrak baru
untuk mengurangi komunikasi redundan
dengan sistem(Jeffery L.Whitten, 2004
hal 262).
Tipe relasi atau stereotype yang mungkin terjadi pada
use-case diagram:
1. <<include>>, yaitu kelakuan yang harus
terpenuhi agar sebuah event dapat terjadi,
dimana pada kondisi ini sebuah use-case adalah
bagian dari use-case lainnya.
2. <<extends>>, kelakuan yang hanya berjalan di
bawah kondisi tertentu seperti menggerakkan
alarm.
3. <<communicates>>, mungkin ditambahkan
untuk asosiasi yang menunjukkan asosiasinya
adalah communicates association. Ini merupakan
pilihan selama asosiasi hanya tipe relationship
yang dibolehkan antara actor dan use-case.
2.Class Diagram
Class Diagram menggambarkan struktur objek
sistem. Diagram ini menunjukkan kelas objek yang
menyusun sistem dan juga hubungan antara kelas
objek tersebut(Jeffery L.Whitten, 2004 hal 418).
Gambar 2.4 Class Diagram
3.Sequential Diagram (Diagram rangkaian)
Secara grafis menggambarkan bagaimana objek
berinteraksi dengan satu sama lain melalui pesan
pada eksekusi sebuah use case atau operasi.
Diagram ini mengilustrasikan bagaimana pesan
terkirim di antara objek dan dalan sekuensi apa.
Gambar 2.5 Contoh Sequential Diagram
4.Activity Diagram (Diagram Aktivitas)
Secara grafis digunakan untuk menggambarkan
rangkaian aliran aktivitas baik proses bisnis atau use
case. Diagram ini juga dapat digunakan untuk
memodelkan action yang akan dilakukan saat sebuah
operasi dieksekusi , dan memodelkan hasil dari
action tersebut.
Gambar 2.6 Contoh Activity Diagram
5.Diagram Deployment (Diagram Penguraian)
Mendeskripsikan arsitektur fisik dalam istilah
”node” untuk hardware dan software dalam sistem.
Diagram ini menggambarkan konfigurasi komponen-
komponen software run-time, prosesor, dan
peralatan yang membentuk arsitektur sistem (Jeffery
L.Whitten, 2004 hal 419).
Gambar 2.7 Contoh Deployment Diagram
2.1.4 Feasibility Study (Studi Kelayakan)
Kelayakan adalah ukuran akan seberapa
menguntungkan atau seberapa praktis pengembangan
sistem informasi terhadapa organisasi. Kelayakan
analysis/analisis kelayakan adalah proses pengukuran
kelayakan(Jeffery L.Whitten, 2004 hal 380).
Ada 4 Pengujian kelayakan :
2.1.4.1 Operational feasibility/kelayakan operasional
Ukuran sebaiknya apa solusi tersebut akan
bekerja dalam organisasi. Juga ukuran pendapat
orang tentang sistem/proyek tersebut. Kriteria
kelayakan operasional mengukur tingkat
kepentingan masalah (fase survei dan studi) atau
tingkat penerimaan solusi(fase definisi, pemilihan,
akuisisi, dan desain). (Jeffery L.Whitten, 2004 hal
382).
2.1.4.2 Technical feasibility/kelayakan teknis
Ukuran kepraktisan solusi teknis tertentu dan
ketersediaan sumber dan pakar teknis. Sedikit hal
yang secara teknis tidak mungkin. Akibatnya,
kelayakan teknis mengarah pada hal yang praktis
dan masuk akal(Jeffery L.Whitten, 2004 hal 384).
2.1.4.3 Schedule feasibility/kelayakan jadwal
Ukuran seberapa masuk akal daftar waktu
pelaksanaan suatu proyek(Jeffery L. Whitten, 2004,
hal.382). Beberapa proyek diawali dengan tenggat
waktu yang spesifik. Sangat perlu untuk menentukan
apakah tenggat waktu itu bersifat
perintah(mandatory) atau keinginan. (Jeffery L.
Whitten, 2004, hal.384).
2.1.4.4 Economic feasibility/kelayakan ekonomis
Ukuran efektivitas biaya sebuah proyek atau
solusinya.Hal mendasar dalam banyak proyek adalah
kelayakan ekonomis. Selama fase awala proyek,
analisis kelayakan ekonomis hanyalah menentukan
apakah manfaat yang diperoleh dari penyelesaikan
persoalan tersebut cukup berharga(Jeffery L.Whitten,
2004 hal 384).
2.1.5 Teknologi Barcode
Dalam pembuatan sistem informasi ini kami
menggunakan alat teknologi barcode. Scanner barcode
adalah piranti keras yang memiliki fungsi khusus, yakni
membaca kode barcode yang tertempel pada barang.
Barcode adalah sebagai kumpulan kode yang berbentuk
garis, dimana masing-masing ketebalan setiap garis
berbeda sesuai dengan isi kodenya.
Teknologi Barcode ini memiliki beberapa manfaat
diantaranya :
1. Akurasi
2. Kemudahan Pemakaian
3. Keseragaman Pengumpulan Data
4. Feedback yang tepat waktu
5. Keamanan
6. Meningkatkan Produktivitas
7. Meningkatkan Profit
Teknologi yang ada pada barcode diantaranya :
1. Teknologi Laser
Teknologi Laser menggunakan dioda laser
berkekuatan 650 ns. Laser ini sebenarnya setara dengan
kekuatan pada pointer presentasi. Kelemahan barcode
scanner ini adalah rentan rusak dan tidak bisa digunakan
untuk membaca barcode 2 Dimensi, barcode jenis ini
banyak digunakan oleh industri manufaktur besar seperti
Seagate Hard Disk, Sony, dan Matsuhita.
2. Teknologi CCD
Teknologi CCD (Charge Coupled Device)
menggunakan sinar infrared, berbeda dengan sinar laser,
seperti yang digunakan pada kamera. Pembacaan dengan
scanner CCD juga mensyaratkan supaya sinar dan objek
barcode didekatkan atau ditempelkan pada jarak
maksimal 2 cm. Jenis barcode sinar CCD jauh lebih kuat
dan tahan banting.
3. Teknologi Linear Imager
Teknologi ini menggabungkan kepekaan laser,
kekuatan CCD, ditambah dengan kemampuan untuk
membaca barcode 2 dimensi.
Sistem kerja pada barcode merupakan instrumen
yang bekerja berdasarkan asas digital. Pada konsep
digital, hanya ada 2 sinyal data yang dikenal dan bersifat
boolean, yaitu 0 atau 1. Ada arus listrik atau tidak ada
listrik (dengan besaran (tresshold) tegangan tertentu,
misalnya 5 volt dan 0 volt). Barcode menerapkannya
pada batang-batang baris yang terdiri dari warna hitam
dan putih. Warna hitam mewakili bilangan 0 dan warna
putih mewakili bilangan 1. Warna hitam akan menyerap
cahaya yang dipancarkan oleh alat pembaca barcode,
sedangkan warna putih akan memantul-balikan cahaya
tersebut. Masing-masing batang barcode memiliki
ketebalan yang berbeda. Ketebalan inilah yang akan
diterjemahkan ke dalam suatu nilai.
Gambar 2.8 Anatomy of a Barcode
Keterangan gambar barcode di atas adalah :
1. Number System Character
Angka ini merupakan sebuah sistem bilangan barcode
UPC yang mengkarakteristikkan jenis-jenis khusus pada
barcode. Di dalam barcode UPC, Number System
Character ini biasanya terletak di sebelah kiri barcode.
2. Guard Bars
Ada 3 guard bars yang ditempatkan di awal, tengah dan
akhir barcode. Guard bars bagian awal dan akhir di-
encode-kan sebagai ‘space-bar-space” atau “01010”.
3. Manufacture Code
Kode perusahaan ini ada lima digit bilangan yang secara
khusus menentukan manufaktur suatu produk. Kode
perusahaan/manufaktur ini dilindungi dan ditetapkan oleh
Uniform Code Council(UCC).
4. Product Code
Kode produk ini terdiri dari lima digit bilangan
yangditetepkan oleh perusahaan/manufaktur untuk setiap
produk yang dihasilkan.
5. Check Digit
Disebut sebagai digit Selft-check. Check digit ini terletak
di bagian luar sebelah kanan barcode. Check digit ini
merupaka suatu old programmer’s trick untuk
memvalidasi digit-digit lainnya(number system
cahracter,manufacture code, product code) yang dibaca
secara teliti.
2.2 Jaringan Komputer
Jaringan komputer adalah hubungan dua simpul (umumnya
berupa komputer) atau lebih yang tujuan utamanya adalah untuk
melakukan pertukaran data. Dalam prakteknya, jaringan
komputer memungkinkan untuk melakukan berbagi perngkat
lunak, perangkat keras, dan bahkan berbagai kekuatan
pemrosesan (Abdul Kadir, 2003 hal.346).
2.2.1 Local Area Network (LAN)
LAN adalah jaringan komputer yang mencakup area
dalam satu ruang, satu gedung, atau beberapa gedung yang
berdekatan. Sebagai contoh, jaringan dalam satu kampus
yang terpadu atau disebuah lokasi perusahaan tergolong
sebagai LAN. LAN umumnya menggunakan media transmisi
berupa kabel. Namun ada juga yang tidak menggunakan
kabel dan disebut sebagai wireless LAN atau LAN tanpa
kabel. Kecepatan LAN berkisar dari 10 Mbps sampai 1 Gbps
(Abdul Kadir, 2003 hal.348).
2.2.2 Two Tier (2 Tier)
Arsitektur two tier merupakan arsitektur yang disebut
client server, dimana terdapat komputer sebagai client dan
server yang berinteraksi melalui protokol dan media
komunikasi tertentu (Budi Sutedjo Dharma Oetomo, S.Kom,
2006, hal. 99).
2.2.3 Topologi Star
Pada topologi ini terdapat komponen yang
bertindak sebagai pusat pengontrol. Semua simpul
yang hendak berkomunikasi selalun melalui pusat
pengontrol tersebut dalam hal ini, pusat pengontrol
berupa Hub atau swicth (Abdul Kadir, 2003.hal 354).
2.3 MySQL
MySQL adalah sebuah program database server yang
mampu menerima dan mengirimkan datanya dengan sangat
cepat, multi user, serta menggunakan perintah standard SQL
(Structured Query Language). MySQL memiliki dua bentuk lisensi,
yaitu FreeSoftware dan Shareware. (Bunafit Nugroho, 2005 hal 3).
Selain itu database ini memliki banyak kelebihan dibanding
database lain, di antaranya adalah :
1. MySQL sebagai Database Management System (DBMS)
2. MySQL sebagai Relation Database Management System
(RDBMS)
3. Merupakan software database yang OpenSource
4. MySQL dapat menjadi database Client dan dapat juga
menjadi Server.
5. Multi-Threading yaitu mampu menerima query yang
bertumpuk dalam satu permintaan.
6. Mampu menyimpan data berkapasitas sangat besar.
7. Multi User, artinya database dapat dugunakan oleh
banyak pengguna.
8. MySQL memliki kecepatan dalam pembuatan dan update
tabel.
2.4 Visual Basic 2010
Visual Basic 2010 merupakan salah satu bagian dari produk
pemrograman terbaru yang dikeluarkan oleh Microsoft, yaitu
Microsoft Visual Studio 2010. Sebagai produk lingkungan
pemrograman terintegrasi atau IDE andalan yang dikeluarkan
oleh Microsoft, Visual Studio 2010 menambahkan perbaikan –
perbaikan fitur dan fitur baru yang lebih lengkap dibandingkan
versi Studio pendahulunya, yaitu Microsoft Visual Studio 2008.
Visual Studio merupakan produk pemrgraman andalan dari
Microsoft Corporation, yang didalamnya berisi beberapa jenis IDE
pemrograman seperti Visual Basic, Visual C++, Visual Web
Developer, Visual C#, dan Visual F#. Semua IDE pemrograman
tersebut sudah mendukung penuh implementasi .Net Framework
terbaru, yaitu Net Framework 4.0 yang merupakan
pengembangan dari .Net Framework 3.5(Penerbit Andi, 2010, hal
2).
2.5 Objek Pengembangan (Sejarah Salemba Toko Buku)
Salemba Toko Buku yang beralamat di Jl.Merdeka Ruko PGB
Blok A No 2-3 Bogor adalah cabang perusahaan di Bogor yang
bergerak di bidang penjualan Buku dan ATK. Salemba ini berdiri
sekitar 10-15 tahun yang lalu. Dulu Salemba Toko Buku ini tidak
hanya menjual buku dan ATK saja, tetapi ada sebuah swalayan
yang berada di lantai 3. Tetapi karena jumlah pembeli minim jadi
Salemba hanya menjual buku-buku dan ATK saja . Salemba Toko
Buku sekarang sudah mempunyai 54 cabang, disetiap kota di
Indonesia ada, dan salah satunya ada di Bogor. Salemba Toko
Buku yang berada di Bogor ini menjual buku-buku dan ATK, tetapi
lebih memfokuskan penjualan ATK.
2.5.1 Visi dan Misi Salemba Toko Buku
a. Visi
Sebagai Toko penjualan terlengkap dan
memenuhi kebutuhan konsumen dalam bidang
buku dan ATK.
b. Misi
Membuat pelayanan yang berkualitas sebagai
tanggung jawab setiap orang. Memenuhi kebutuhan
konsumen.
2.6 Kerangka Pemikiran
Dari hasil analisa masalah yang ada, maka dirancanglah
sistem dimana dari segi pendataan barang dibuat seefisien
mungkin. Rancangan sistem informasi ini meliputi pembuatan
aplikasi yang sesuai dengan kebutuhan user dan pembaharuan
sistem yang ada. Perancangan sistem informasi inventori yang
akan dikembangkan pada tahap implementasi menggunakan
Database Management System (DBMS) MySQL sebagai konektor.
Sistem ini akan memberi kemudahan dalam proses persediaan
barang.
Proses persediaan yaitu persediaan barang, penerimaan
barang, penjualan barang, pesanan barang dan return barang.
Sehingga menghasilkan laporan persediaan barang, laporan
penerimaan barang, laporan penjualan barang, laporan pesanan
barang dan laporan return barang.
Dalam membangun Sistem Informasi ini penulis
menggunakan perangkat lunak Microsoft Visual Basic 2010
(VB.Net 2010) sebagai bahasa pemrograman dan MySQL sebagai
perangkat lunak pengelola database, server menggunakan sistem
operasi Windows Server 2008 sedangkan untuk client
menggunakan sistem operasi Windows7, dan untuk mencetak
laporan digunakan printer type deskjet.
BAB III
ANALISA SISTEM
3.1 Jadwal Proyek
Jadwal proyek merupakan acuan agar pelaksanaan Perancangan Sistem
Informasi Inventori di Salemba Toko Buku ini berjalan sesuai dengan yang
diharapkan dan selesai tepat pada waktunya.
Tabel 3.1 Penjadwalan Proyek menggunakan Microsoft Project
3.2 Analisa Kelayakan Sistem
3.2.1 Kelayakan Ekonomi (Analisa biaya dan manfaat)
Kelayakan Ekonomi hal mendasar dalam banyak proyek, analisis
kelayakan ekonomis hanyalah menentulan apakah manfaat yang diperoleh
dari menyelesaikan persoalan tersebut cukup berharga. Biaya secara praktis
tidak mungkin diperkirakan pada tahap itu, karena persyaratan pengguna
akhir dan solusi teknis alternatif belum diidentifikasi. Akan tetapi, segara
setelah persyaratan dan solusi spesifikasi diidentifikasi, analis dapat
diperkirakan biaya dan keuntungan tiap alternatif tersebut. Ini disebut analisis
cost-benefit (Jeffery L. Whitten, 2004, hal. 384).
Analisis dan perancangan biaya pada perancangan sistem ini adalah
sebagai berikut:
NO Deskripsi TAHUN 0 TAHUN 1 TAHUN 2 TAHUN 3 TAHUN 4
Rincian Biaya
1. Biaya Pengadaan
- Biaya Pembelian H/WRp.7.200.000
-Jaringan Rp.250.000
Sub Total Biaya Pengadaan
Rp.7.450.000
2.Biaya Persiapan Operasi
- Biaya pembelian S/WRp.4.000.000
- Biaya Biaya PersonilRp.900.000
Sub Total Biaya Persiapan Operasi
Rp.4.900.000
3.Biaya proyek
a. Tahap Analisis Sistem
- Biaya pengumpulan data
Rp. 250.000
- Biaya ATK Rp. 50.000
- Biaya manajemen dan staf
Rp. 2.700.000
- Biaya rapat Rp. 250.000
-Biaya programer Rp.9.000.000
- Biaya konsultan analisRp.3.500.000
Sub Total Biaya Tahap Analisis
Rp.15.500.000
Total KeseluruhanRp.27.850.000
4.Biaya Operasional & Perawatan
- Biaya overheadRp.500.000 Rp. 600.000 Rp.700.000 Rp.800.000
-Biaya Perwatan H/WRp. 650.000Rp. 700.000 Rp. 780.000 Rp. 850.000
-Biaya Perawatan S/WRp. 550.000 Rp. 600.000 Rp. 650.000 Rp. 700.000
-Biaya KontrakRp 4.000.000 Rp. 4.500.000 Rp. 5.000.000 Rp. 5.500.000
Sub Total Biaya Operasional dan Perawatan
Rp.5.700.000 Rp.6.400.000 Rp.7.130.000 Rp.7.850.000
Total Biaya Rp.27.850.000Rp.5.700.000 Rp.6.400.000 Rp.7.130.000 Rp.7.850.000
Tabel 3.2 Analisa Biaya dan Manfaat
Tabel Analisa Manfaat
No Deskripsi TAHUN 1 TAHUN 2 TAHUN 3 TAHUN 4
1. Keuntungan Berwujud
a. Mengurangi kesalahan
Rp. 1.500.000 Rp.2.000.000 Rp.3.000.000 Rp.5.000.000
b. Peningkatan Penjualan
Rp. 3.500.000 Rp.4.000.000 Rp.5000.000 Rp.5.500.000
c. Mempermudah Mendeteksi & Mengawasi
Rp.5.000.000 Rp.5.300.000 Rp.5.500.000 Rp.6.000.0000
Total Rp.10.000.000 Rp.11.300.000 Rp.13.500.000 Rp.16.000.000
2.KeuntunganTak berwujud
a. Peningkatan Manajement
Rp.6.500.000 Rp.6.500.000 Rp.6.700.000 Rp.7.000.000
b. Efisiensi waktu Rp.6.000.000 Rp.7.000.000 Rp.8.000.000 Rp.9.000.000
Total Rp.12.500.000 Rp.13.500.000 Rp.14.700.000 Rp.16.800.000
Investasi Awal : Rp. 27.850.000Total Manfaat Total Biaya Proceed
Tahun 1 Rp 22.500.000 Rp. 6.700.000 Rp. 15.800.000Tahun 2 Rp. 24.800.000 Rp. 7.600.000 Rp. 17.280.000Tahun 3 Rp. 28.200.000 Rp. 8.530.000 Rp. 19.670.000Tahun 4 Rp. 32.800.000 Rp. 9.350.000 Rp. 23.450.000
Total Rp. 108.000.000Rp. 32.108.000
Tabel 3.3 Proceed
a. Payback Period (PP)
Nilai investasi : Rp. 27.850.000
Proceed tahun ke-1 = Rp. 15.800.000
Sisa (tahun ke-2) :
PP = 1 tahun + [(Rp. 27.850.000– Rp. 15.800.000 ) x 12 bulan]
Rp. 17.280.000 = 1 tahun + (Rp. 12050000) x 12 bulan Rp. 17.280.000 = 1 tahun 8,36 bulanJadi, Payback Periodnya adalah 1 tahun 8 bulan 18 hari.
b. Return of Investment (ROI)
ROI=[ 1 08.000 .000−59.958 .00059.958 .000 ] x100%ROI=[ 48.042.000
59.958 .000 ] x100 %
ROI= [0,801 ] x100 % ROI=80,1 %
ROI bernilai positif, maka sistem layak dikembangkan.c. Net Present Value (NPV)
NPV =−Nilai Proyek+ Proceed thn1
(1+i )1+ Proceed thn2
(1+i )2+ Proceed thn3
(1+i )3+ Proceed thn4
(1+i )4
NPV =−27.850 .000+ 15.800.000
(1+0,25 )1+ 17.200 .000
(1+0,25 )2+ 19.670 .000
(1+0,25 )3+ 23.450 .000
(1+0,25 )4
NPV =−27.850 .000+12.640 .000+11.008.000+10.071 .000+9.610 .657
NPV =−27.850 .000+43.329 .657
NPV =Rp .15 .479 .657(NPV Positif )
NPV bernilai positif, maka sistem layak dikembangkan.
Untuk menghitung IRR, harus menemukan nilai NPV=0 dengan cara mencari NPV positif
dan NPV negatif dengan cara trial and eror.
NPV =−Nilai Proyek+ Proceed thn1
(1+i )1+ Proceed thn2
(1+i )2+ Proceed thn3
(1+i )3+ Proceed thn4
(1+i )4
NPV =−27.850 .000+ 15.800.000
(1+0,55 )1+ 17.200 .000
(1+0,55 )2+ 19.670 .000
(1+0,55 )3+ 23.450 .0000
(1+0,55 )4
NPV =−27.850 .000+10.193 .543+7.151 .767+5.283 .373+4.064 .124
NPV =−27.850 .000+26.692 .807
NPV =−Rp .115 .719(NPV Negatif )
Nilai IRR terletak pada rate of return 25% (Positif) dan 55% (Negatif)
d. Internal Rate of Return (IRR)
Diketahui : i1 = Rate of Return (NPV Positif) = 25%
i2 = Rate of Return (NPV Negatif) = 55%
NPV 1 = NPV Positif = Rp. 15.479 .657
NPV 2 = NPV Negatif = Rp. -115.719
IRR=¿IRR=¿
IRR=¿
IRR=[25+ 46438971015595376 ]%
IRR=[ 25+29,77 ] %
IRR=54,77 %
3.2.2 Kelayakan Teknis
Kelayakan teknis adalah ukuran kepraktisan solusi teknis
tertentu dan ketersediaan sumber dan pakar teknis (Jeffery L.
Whitten, 2004, hal. 382). Sangat sedikit hal yang secara teknis
tidak mungkin. Akibatnya, kelayakan teknis mengarah pada hal
praktis dan masuk akal (Jeffery L. Whitten, 2004, hal.384).
a. Perangkat keras (hardware) dan perangkat lunak (software)
pada komputer server
Komputer server
PerangkatKeras(hardware) Perangkatlunak(software)
- Processor intel core i3 -Mainboard-Harddisk 80Gb - Keyboard + Mouse -Casing ATX 450w + 2 FAN CPU-LCD Monitor - DVD-RW
Windows Server 2008
MySQL
b. Perangkat keras (hardware) dan perangkat lunak
(software) pada komputer client
Komputer client
PerangkatKeras (hardware)PerangkatLunak
(software) Processor intel core i3 Windows 7
-Mainboard Microsoft Visual Studio 2010
-Harddisk 160 Gb -Keyboard + Mouse
-Casing ATX 450w + 2FAN CPU
-LCD Monitor
c. Jaringan
Jaringan1. Kabel UTP2. Switch Dlink 10/100
d. Alat Bantu
Alat bantu 1. Scanner Barcode 2. ID Card RFID
3.2.3 Kelayakan Jadwal
Kelayakan jadwal adalah ukuran kelayakan daftar pelaksanaan
proyek tersebut (Jeffery L. Whitten, 2004, hal.382). Beberapa proyek
diawali dengan tenggat waktu yang spesifik. Sangat perlu untuk
menentukan apakah tenggat waktu itu bersifat perintah (mandatory)
atau keinginan.(Jeffery L. Whitten, 2004, hal.384).
3.2.4 Kelayakan Operasional
Kelayakan operasional adalah ukuran sebaik apa solusi tersebut
akan bekerja dalam organisasi. Juga ukuran pendapat orang tentang
sistem / proyek tersebut. Kriteria kelayakan operasional mengukur
tingkat kepentingan masalah(fase survei dan studi) atau tingkat
penerimaan solusi(fase definisi, pemilihan, akuisisi, dan desain)
(Jeffery L. Whitten, 2004, hal. 382).
3.3 Analisa Proses Sistem yang Berjalan
3.4 Analisa Proses Sistem Baru yang dikembangkan
Gambar 3.10 Analisa Proses Sistem yang Berjalan
Gambar 3.11 Analisa Proses Sistem yang Dikembangkan
3.5 Kontruksi Sistem yang dikembangkan
Gambar 3.12 Kontruksi Sistem yang dikembangkan
3.6 Skenario Sistem yang dikembangkan
Semua aktor yang akan masuk ke sistem harus login terlebih dahulu
dengan ID Card.
Supervisor membuat surat pesanan barang ke Pusat, Pusat
mengirimkan barang ke cabang Salemba Toko Buku di Bogor. Barang
diterima dan di cek oleh admin gudang, jika ada kerusakan barang maka
admin gudang mengembalikan barang tersebut ke Pusat. Jika barang tidak
rusak, maka Admin gudang akan menginputkan penerimaan barang ke sistem,
Barang yang diinputkan oleh admin gudang tersebut akan masuk ke sistem
sehingga pimpinan dan supervisor bisa mengontrol penerimaan barang
tersebut.
Pembeli bisa mengecek harga barang dengan menyodorkan barang ke
barcode.
Pembeli membeli barang dan dibayar dikasir, kasir mengecek barang
tersebut dengan scanner barcode. Maka dengan mengecek barang
menggunakan scanner barcode, barang yang keluar bisa terlihat dari sistem
ini.
Supervisor membuat dan mencetak laporan persediaan barang,
penerimaan barang, penjualan barang, pesanan barang dan retun barang.
Laporan tersebut kemudian diserahkan kepada pimpinan untuk di tanda
tangan kemudian di arsipkan.
BAB IV
PERANCANGAN SISTEM
4.1 DiagramKonteks
Gambar 4.13 Diagram Konteks
4.2 Daftar Istilah Pelaku Bisinis
Daftar istilah pelaku bisnis mendeskripsikan aktor beserta peran.
Istilah Deskripsi
Pimpinan Bertanggung jawab atas semua kegiatan yang terjadi pada Salemba Toko Buku dan berhak mengambil keputusan serta menerima laporan.
Supevisor Bertanggung jawab membuat surat pesanan barang, mengelola persediaan barang, penerimaan barang, penjualan barang, dan return barang , dan membuat laporan.
Admin Gudang
Menginput data barang dan input penerimaan barang masuk.
Kasir Bertanggung jawab dalam penjualan barang menggunakan scanner barcode.
Pembeli Membeli, Pencarian barang, membayar dan menerima struck pembayaran.
4.3 Identifikasi Use Case
Istilah DeskripsiPelaku yang
BerpartisipasiLogin Use case ini mendeskripsikan kejadian pada saat user pertama
masuk kedalam sistem.- Supervisor
- Admin Gudang
- Kasir
- Pimpinan
Input BarangUse case ini mendeskripsikan proses penginputan barang baru yang dilakukan oleh Admin gudang ke sistem
-Admin Gudang
Input Penerimaan BarangUsecase ini mendeskripsikan proses penginputan data penerimaan barang yang dilakukan oleh Admin Gudang ke dalam sistem.
- Admin Gudang
Penjualan BarangUsecase ini mendeskripsikan proses penjualan barang menggunakan scanner barcode yang dilakukan oleh kasir ke dalam sistem.
- Kasir
Pesanan BarangUsecase ini mendeskripsikan proses penginputan pesanan barang yang dilakukan oleh Supervisor ke dalam sistem.
- Supervisor
Return BarangUsecase ini mendeskripsikan proses return barang yang dilakukan oleh Supervisor ke dalam sistem.
- Supervisor
Pencarian BarangUsecase ini mendeskipsikan proses pencarian barang yang dilakukan oleh pembeli ke dalam sistem.
-Pembeli
Look up data Penerimaan Barang
Usecase ini mendeskripsikan proses look up data penerimaan barang berdasarkan tglpenerimaan dalam sistem.
- Supervisor
- Pimpinan
Look up data Penjualan Barang
Usecase ini mendeskripsikan proses look up data penjualan barang berdasarkan tglpenjualan dalam sistem.
- Supervisor
- Pimpinan
Look up data Persediaan Barang.
Usecase ini mendeskripsikan proses look up data persediaan barang berdasarkan stock barang dalam sistem.
- Supervisor
- Pimpinan
Look up data Pesanan Barang.
Usecase ini mendeskripsikan proses look up data pesanan barang berdasarkan tglpesan dalam sistem.
- Supervisor
- Pimpinan
Look up data Return Barang.
Usecase ini mendeskripsikan proses look up data Return barang berdasarkan tglreturn dalam sistem.
- Supervisor
- Pimpinan
Update data Penerimaan Barang
Usecase ini mendeskripsikan proses update data yang terjadi pada data penerimaan barang yang telah diinput sebelumnya oleh Admin gudang kedalam sistem.
- Admin Gudang
Update data Pesanan BarangUsecase ini mendeskripsikanproses update data yang terjadi pada data pesanan barang yang telah diinput sebelumnya oleh Supervisor kedalam sistem.
- Supervisor
Update data Return BarangUsecase ini mendeskripsikan proses update data yang terjadi pada data return barang yang telah diinput sebelumnya oleh Supervisor kedalam sistem.
- Supervisor
Cetak LaporanUsecase ini mendeskripsikan pencetakan laporan yang telah dikelola sebelumnya dalam sistem.
- Supervisor
Cetak Struck PembayaranUsecase ini mendeskripsikan pencetakan Struck Pembayaran yang telah dikelola sebelumnya dalam sistem.
- Kasir
4.4 Use Case Naratif
4.4.1 Persyaratan Bisnis
Untuk mendeskripsikan use case dengan singkat dan tepat dan
mengetahui bagaimana user berinteraksi dengan sistem baik langsung
maupun tidak langsung digambarkan dengan use case persyaratan
bisnis seperti dibawah ini.
No ID Usecase Nama Usecase
1 1.1 Login
2 1.2 Input Barang
3 1.3 Input Penerimaan Barang
4 1.4 Penjualan Barang
5 1.5 Pesanan Barang
6 1.6 R Return Barang
7 1.7 Pencarian Barang
8 1.8 Look up data Penerimaan Barang
9 1.9 Look up data Penjualan Barang
10 1.10 Look up data Persediaan barang
11 1.11 Look up data Pesanan barang
12 1.12 Look up data Return barang
13 1.13 Update data Penerimaan Barang
14 1.14 Update data Pesanan Barang
15 1.15 Update data Return Barang
16 1.16 Cetak laporan
17 1.17 Cetak Struck Pembayaran
4.4.1.1 Persyaratan Bisnis Login
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Login Tipe Use Case
ID Use Case : 1.1
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor, Admin Gudang, Pimpinan, Kasir.
Pelaku Partisipan Lain : -
Stake holder yang berminat lain :-
Deskripsi :Use case ini mendeskripsikan kejadian pada saat user pertama masuk kedalam sistem.
4.4.1.2 Persyaratan Bisnis Input Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Input Barang Tipe Use Case
ID Use Case : 1.2
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses penginputan data barang baru yang dilakukan oleh Admin Gudang ke dalam sistem.
4.1.1.3 Persyaratan Bisnis Input Penerimaan Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Input Penerimaan BarangTipe Use Case
ID Use Case : 1.3
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses penginputan data penerimaan barang yang dilakukan oleh Admin Gudang ke dalam sistem.
4.1.1.4 Persyaratan Bisnis Penjualan Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Penjualan Barang Tipe Use Case
ID Use Case : 1.4
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses penjualan barang menggunakan barcode yang dilakukan oleh kasir ke dalam sistem.
4.1.1.5 Persyaratan Bisnis Pesanan Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Pesanan Barang Tipe Use Case
ID Use Case : 1.5
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses penginputan pesanan barang yang dilakukan oleh Supervisor ke dalam sistem.
4.4.1.6 Persyaratan Bisnis Return Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Return Barang Tipe Use Case
ID Use Case : 1.6
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Use case ini mendeskripsikan return barang yang dilakukan oleh Supervisor ke dalam sistem.
4.4.1.7 Persyaratan Bisnis Pencarian Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Pencarian barang Tipe Use Case
ID Use Case : 1.7
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Pembeli
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Use case ini mendeskipsikan proses pencarian barang yang dilakukan oleh pembeli ke dalam sistem.
4.4.1.8 Persyaratan Bisnis Look up Data Penerimaan Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case :Look up Data Penerimaan Barang
Tipe Use Case
ID Use Case : 1.8
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses look up data penerimaan barang berdasarkan tglpenerimaan dalam sistem.
4.4.1.9 Persyaratan Bisnis Look up Data Penjualan Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case :Look up Data Penjualan Barang
Tipe Use Case
ID Use Case : 1.9
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses look up data penjualan barang berdasarkan tglpenjualan dalam sistem.
4.4.1.10 Persyaratan Bisnis Look up Data Persediaan Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case :Look up Data Persediaan Barang
Tipe Use Case
ID Use Case : 1.10
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses look up data persediaan barang berdasarkan stock barang dalam sistem
4.4.1.11 Persyaratan Bisnis Look up Data Pesanan Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case :Look up Data Pesanan Barang
Tipe Use Case
ID Use Case : 1.11
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses look up data pesanan barang berdasarkan tglpesan dalam sistem.
4.4.1.12 Persyaratan Bisnis Look up Data Return Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up Data Return BarangTipe Use Case
ID Use Case : 1.12
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses look up data return barang berdasarkan tgtlreturn dalam sistem
4.4.1.13 Persyaratan Bisnis Update Data Penerimaan Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case :Update Data Penerimaan Barang
Tipe Use Case
ID Use Case : 1.13
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses update data yang terjadi pada data penerimaan barang yang telah diinput sebelumnya oleh Admin gudang kedalam sistem.
4.4.1.14 Persyaratan Bisnis Update Data Pesanan Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Update Data Pesanan Barang Tipe Use Case
ID Use Case : 1.14
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses update data yang terjadi pada data pesanan barang yang telah diinput sebelumnya oleh Supervisor kedalam sistem.
4.4.1.15 Persyaratan Bisnis Update Data Return Barang
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Update Data Return Barang Tipe Use Case
ID Use Case : 1.15
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan proses update data yang terjadi pada data return barang yang telah diinput sebelumnya oleh Supervisor kedalam sistem.
4.4.1.16 Persyaratan Bisnis Cetak laporan
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Cetak laporan Tipe Use Case
ID Use Case : 1.16
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase inimendeskripsikan pencetakan laporan yang telah dikelola sebelumnya dalam sistem.
4.4.1.17 Persyaratan Bisnis Cetak Struck Pembayaran
Pengarang : 1. Meli Amelia Tanggal : 16 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Cetak Struck PembayaranTipe Use Case
ID Use Case : 1.17
Prioritas : Tinggi Persyaratan Bisnis :
Sumber : -
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain : -
Stakeholder yang berminat lain :-
Deskripsi :Usecase ini mendeskripsikan pencetakan Struck Pembayaran yang telah dikelola sebelumnya dalam sistem.
4.4.2 Analisis Sistem
4.4.2.1 Analisis Sistem Login
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Login Tipe Use Case
ID Use Case : 1.1 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Admin Gudang, Pimpinan, Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian pada saat user pertama masuk kedalam sistem.
Prakondisi :User telah memiliki user name dan passwordnya masing-masing yang sudah secara otomatis sudah ada di ID Card.
Pemicu :Use case ini dilakukan untuk memastikan bahwa sistem hanya digunakan oleh user yang telah diberi hak akses berdasarkan kepentingannya.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
User mengscankan IDCard yang sudah ada username dan password yang bertipe barcode pada barcode Scanner.
Langkah 3 :
Apabila pilihan user mentombol Cancel.
Langkah 2 :
Sistem akan memproses dan menampilkan menu utamaMenu Transaksi, Transaksi dan menu Laporan .
jika validasi IDCard dimasukkan adalah valid.
Langkah 4 :
Sistem akan menghentikan proses Login.
Bidang Alternatif :
Alternatif Langkah 2:
2.1 Sistem akan menampilkan pesan kesalahan jika kombinasi IDCard tidak valid, dan meminta pengguna untuk mengscankan barcode yang ada pada IDCard dengan benar.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah awal user hendak menggunakan sistem sesuai hak aksesnya.
Postkondisi :User masuk dan menggunakan sistem sesuai hak akses pelaku.
Aturan Bisnis : IDCard harus dimasukkan dengan data yang valid.
Batasan Dan Spesifikasi Implementasi :
Hanya user yang mempunyai hak akses saja yang bisa masuk kedalam sistem.
Asumsi : User telah memiliki IDCard.
Masalah Terbuka : User lupa/hilang IDCard .
4.4.2.2 Analisis Sistem Input Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Input Barang Tipe Use Case
ID Use Case : 1.2 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu menambah/input data barang baru.
Prakondisi :User telah memiliki data barang baru yang akan diinputkan.
Pemicu :Use case ini dimulai saat user menyeleksi pilihan input data barang untuk menambah/input data barang baru .
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Pilih menu Master dan kliksub menu barang.
Langkah 3:
User Masukkan data barang baru kedalam field yang sudah disediakan dengan benar.
Langkah 5 :
Cek semua data barang yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Simpan].
Langkah 2 :
Sistem merespon dengan menampilkan form inputan barang.
Langkah 4 :
Sistem merespon dengan menyimpan data barang baru yang telah diinputkan tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data.
Langkah 6:
Sistem merespon dengan menutup From Barang dan menampilkan Form utama.
Bidang Alternatif :
Alternatif Langkah 4:
4.1 Jika sistem merespon bahwa penyimpanan gagal data tidak lengkap maka user harus melengkapi data yang diperlukan dan kembali ke langkah 3.
Kesimpulan :Usecase ini menyimpulkan bagaimana langkah barang oleh admin gudang.
Postkondisi :Data barang telah disimpan dan telah terupdate, dan sistem menampilkan kembali Form Utama.
Aturan Bisnis : User sudah menyiapkan data barang yang valid.
Batasan Dan Spesifikasi Implementasi :
Admin Gudang hanya menginput barang.
Asumsi :Hanya Admin gudang yang dapat melakukan penginputan barang.
Masalah Terbuka : -
4.4.2.3 Analisis Sistem Input Penerimaan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Input Penerimaan BarangTipe Use Case
ID Use Case : 1.3 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu menambah/input data penerimaan barang.
Prakondisi :User telah memiliki data penerimaan barang yang akan diinputkan.
Pemicu :Use case ini dimulai saat user menyeleksi pilihan input data barang untuk menambah/input data penerimaan barang .
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Pilih menu Transaksi dan kliksub menu penerimaan barang.
Langkah 3:
User Masukkan data penerimaan barang kedalam field yang sudah disediakan dengan benar.
Langkah 5 :
Cek semua data barang masuk yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Simpan].
Langkah 2 :
Sistem merespon dengan menampilkan form inputan penerimaan barang.
Langkah 4 :
Sistem merespon dengan menyimpan data penerimaan barang yang telah diinputkan tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data.
Langkah 6:
Sistem merespon dengan menutup From Penerimaan Barang dan menampilkan Form utama.
Bidang Alternatif :
Alternatif Langkah 4:
4.1 Jika sistem merespon bahwa penyimpanan gagal data tidak lengkap maka user harus melengkapi data yang diperlukan dan kembali ke langkah 3.
Kesimpulan :Usecase ini menyimpulkan bagaimana langkah penerimaan barang oleh admin gudang.
Postkondisi :Data barang telah disimpan dan telah terupdate, dan sistem menampilkan kembali Form Utama.
Aturan Bisnis :User sudah menyiapkan data penerimaan barang yang valid.
Batasan Dan Spesifikasi Implementasi :
Admin Gudang hanya menginput penerimaan barang.
Asumsi :Hanya Admin gudang yang dapat melakukan penginputan penerimaan barang.
Masalah Terbuka : -
4.4.2.4 Analisis Sistem Penjualan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Penjualan Barang Tipe Use Case
ID Use Case : 1.4 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu menambah data penjualan barang dengan mengescan barcode barang.
Prakondisi :User telah memiliki data penjualan barang yang akan diinputkan menggunakan scanner barcode.
Pemicu :Use case ini dimulai saat user menyeleksi pilihan input data penerimaan barang untuk menambah data penjualan barang.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
Pilih menu Transaksi dan klik sub menu penjualan barang.
Langkah 2:
Sistem merespon dengan menampilkan form inputan penjualan barang.
Langkah 3: Masukkan data barang keluar dengan mengescankan barcode barang menggunakan alat scanner barcode ke dalam field yang sudah disediakan dengan benar.
Langkah 4 :
Cek semua data penjualan barang yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Bayar].
Langkah 5 :
Sistem merespon dengan mencetak struck pembayaran.
Langkah 6 :
Setelah sistem mencetakstruck pembayaran maka Sistem akan menyimpan data penjualan barang yang telah diinputkan dengan scanner barcode tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data.
Bidang Alternatif :
Alternatif Langkah 5:
5.1 Jika Sistem tidak bisa membaca barcode barang , karena ketidakjelasan barcode, maka user harus menginputkan kodebarcode barang kedalam field yang sudah disediakan.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah input data penjualan barang oleh Kasir.
Postkondisi :Data barang telah dibayar dan disimpan dan telah terupdate, dan sistem menampilkan kembali Form Input Penjualan barang.
Aturan Bisnis :User sudah menyiapkan alat scanner barcode untuk menscanbarcode yang valid.
Batasan Dan Spesifikasi Implementasi :
Kasir hanya menginput data penjualan barang dengan mengscanbarcode pada kodebarcode barang untuk transaksi penjualan barang.
Asumsi :Hanya Kasir yang dapat melakukan penginputan data transaksi penjualan barang.
Masalah Terbuka : -
4.4.2.5 Analisis Sistem Pesanan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Pesanan Barang Tipe Use Case
ID Use Case : 1.5 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu mengPesanan Barang .
Prakondisi :User Telah memiliki data pesanan barang yang akan diinputkan.
Pemicu :Use case ini dimulai saat user meyeleksi pilihan input data pesanan barang.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Pilih menu Transaksi dan kliksub menu input data pesanan barang.
Langkah 3:
User Masukkan data pesanan barang kedalam field yang sudah disediakan dengan benar.
Langkah 5 :
Cek semua data barang pesanan yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Simpan].
Langkah 2 :
Sistem merespon dengan menampilkan form input data pesanan barang.
Langkah 4 :
Sistem merespon dengan menyimpan data pesanan barang yang telah diinputkan tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data.
Langkah 6:
Sistem merespon dengan menutup From input pesanan Data Barang dan menampilkan Form utama.
Bidang Alternatif :
Alternatif Langkah 4 :
4.1 Jika sistem merespon bahwa penyimpanan gagal data tidak lengkap maka user harus melengkapi data yang diperlukan dan kembali ke langkah 3.
Kesimpulan : Use-case ini menyimpulkan bagaimana langkah Pesanan
Barang oleh Supervisor.
Postkondisi :Data barang yang sudah diinputkan akan disimpan dan akan terupdate,dan sistem menampilkan kembali Form Input Pesanan Barang.
Aturan Bisnis :User harus memiliki IDCard yang sudah secara otomatis terdapat username dan password untuk login.
Batasan Dan Spesifikasi Implementasi :
Supervisor hanya menginput data Pesanan Barang.
Asumsi :Hanya Supervisor yang dapat melakukan penginputan dataPesanan barang .
Masalah Terbuka : -
4.4.2.6 Analisis Sistem Return Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Return Barang Tipe Use Case
ID Use Case : 1.6 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu Return Barang.
Prakondisi :User telah memiliki data return barang yang akan diinputkan.
Pemicu :Use case ini dimulai saat user menyeleksi pilihan input data return barang untuk menambah, merubah, dan menghapus data barang.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Pilih menu Transaksi dan kliksub menu input data return barang.
Langkah 3:
User Masukkan data return barang kedalam field yang
Langkah 2 :
Sistem merespon dengan menampilkan form input data return barang.
Langkah 4 :
Sistem merespon dengan menyimpan data return barang
sudah disediakan dengan benar.
Langkah 5 :
Cek semua data return barang yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Simpan].
yang telah diinputkan tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data.
Langkah 6:
Sistem merespon dengan menutup From input Data return Barang dan menampilkan Form utama.
Bidang Alternatif :
Alternatif Langkah 4:
4.1 Jika sistem merespon bahwa penyimpanan gagal data tidak lengkap maka user harus melengkapi data yang diperlukan dan kembali ke langkah 3.
Kesimpulan :Usecase ini menyimpulkan bagaimana langkah input data return barang oleh Supervisor.
Postkondisi :Data barang telah disimpan dan telah terupdate, dan sistem menampilkan kembali Form Utama.
Aturan Bisnis : User sudah menyiapkan data return barang yang valid.
Batasan Dan Spesifikasi Implementasi :
Supervisor hanya menginput data return barang.
Asumsi :Hanya Supervisor yang dapat melakukan penginputan data return barang.
Masalah Terbuka : -
4.4.2.7 Analisis Sistem Pencarian Baranng
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Pencarian barang Tipe Use Case
ID Use Case : 1.7 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Pembeli
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi : Use case ini mendeskripsikan kejadian seorang user yaitu
untuk pencarian barang .
Prakondisi : -
Pemicu : Use case ini dimulai saat user mencari barang
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User menginputkan data barang yang akan dicari
Langkah 2 :
Sistem merespon dengan menampilkan informasi barang yang dicari user
Bidang Alternatif :
Alternatif Langkah 2 :
2.1 Jika sistem tidak merespon maka pencarian barang gagal karena barang yang dicari tidak tersedia dan kembali ke langkah 1.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah pencarian barang oleh Pembeli.
Postkondisi :
Pencarian barang sudah dicari maka sistem akan menampilkan kembali form pencarian barang
Aturan Bisnis : -
Batasan Dan Spesifikasi Implementasi :
pembeli hanya menginputkan data barang yang akan dicari.
Asumsi :Pembeli yang dapat pencarian barang.
Masalah Terbuka : -
4.4.2.8 Analisis Sistem Look up Data Penerimaan barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up data barang masukTipe Use Case
ID Use Case : 1.8 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data penerimaan barang berdasarkan tglpenerimaan dalam sistem.
Prakondisi :Memastikan apakah data penerimaan barang yang akan di look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up penerimaan barang.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Pilih menu View dan klik submenu data penerimaan barang
Langkah 3:
User memasukan tglpenerimaan
Langkah 5 :
User mengklik data barang yang dicari.
Langkah 2 :
Sistem merespon dengan menampilkan form data barang masuk.
Langkah 4 :
Sistem akan secara otomatis mencari data penerimaan barang yang telah tersimpan.
Langkah 6:
Sistem akan menampilkan data barang masuk yang di cari.
Bidang Alternatif : Alternatif langkah 3 :
3.1 jika tglpenerimaan yang dimasukan tidak sesuai
dengan yang ada di database, maka sistem akan muncul informasi bahwa tglpenerimaan yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look uppenerimaan barang.
Postkondisi : Data penerimaan barang yang dicari akan ditampilkan.
Aturan Bisnis :Tglpenerimaan yang dimasukan harus sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data penerimaan barang.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data penerimaan barang.
Masalah Terbuka : -
4.4.2.9 Analisis Sistem Look up Data Penjualan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up data penjualan barangTipe Use Case
ID Use Case : 1.9 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data penjualan barang berdasarkan tglpenjualan dalam sistem.
Prakondisi :Memastikan apakah data penjualan barang yang akan di look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up penjualan barang.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Pilih menu View barang dan kliksubmenu data Penjualan barang.
Langkah 3:
User memasukan tglpenjualan.
Langkah 5 :
User mengklik data penjualan barang yang dicari.
Langkah 2 :
Sistem merespon dengan menampilkan form data barang keluar.
Langkah 4 :
Sistem akan secara otomatis mencari data penjualan barang yang telah tersimpan.
Langkah 6:
Sistem akan menampilkan data penjualan barang yang di cari.
Bidang Alternatif :
Alternatif langkah 3 :
3.1 jika tglpenjualan yang dimasukan tidak sesuai dengan yang ada di database, maka sistem akan muncul informasi bahwa tglpenjualan yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look uppenjualan barang.
Postkondisi : Data penjualan barang yang dicari akan ditampilkan.
Aturan Bisnis :tglpenjualan yang dimasukan harus sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data penjualan barang.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data penjualan barang.
Masalah Terbuka : -
4.4.2.10 Analisis Sistem Look up Data Persediaan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up Persediaan barangTipe Use Case
ID Use Case : 1.10 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data barang Persediaan barang berdasarkan stockbarang dalam sistem.
Prakondisi :Memastikan apakah data persediaan barang yang akan di look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look persediaan barang.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Pilih menu View barang dan kliksub menu data PersediaanBarang .
Langkah 3:
User memasukan stock minimal barang .
Langkah 5 :
User mengklik data stock persediaan barang .
Langkah 2 :
Sistem merespon dengan menampilkan form data Persediaan barang .
Langkah 4 :
Sistem akan secara otomatis mencari data stock minimal barang yang telah yang tersimpan.
Langkah 6:
Sistem akan menampilkan data stock persediaan barang .
Bidang Alternatif :
Alternatif langkah 3 :
3.1 jika stockbarang yang dimasukan tidak sesuai dengan yang ada di database, maka akan muncul informasi bahwa stock barang yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look uppersediaan barang.
Postkondisi : Data persediaan barang yang dicari akan ditampilkan.
Aturan Bisnis :Stock barang yang dimasukan harus sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data persediaan barang.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data barang persediaan barang.
Masalah Terbuka : -
4.4.2.11 Analisis Sistem Look up Data Pesanan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up Pesanan barangTipe Use Case
ID Use Case : 1.11 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data Pesanan barang berdasarkan tglpesan dalam sistem.
Prakondisi :Memastikan apakah data Pesanan barang yang akan di look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up Pesanan barang.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Pilih menu View barang dan kliksub menu data Pesanan barang .
Langkah 3:
User memasukan tglpesan .
Langkah 5 :
User mengklik data Pesanan Barang.
Langkah 2 :
Sistem merespon dengan menampilkan form data Pesanan barang .
Langkah 4 :
Sistem akan secara otomatis mencari data Pesanan barang yang telah yang tersimpan.
Langkah 6:
Sistem akan menampilkan data pesanan barang .
Bidang Alternatif : Alternatif langkah 3 :
3.1 jika tglpesan yang dimasukan tidak sesuai dengan yang ada di database, maka akan muncul informasi bahwa tglpesan yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look upPesanan barang.
Postkondisi : Data Pesanan barang yang dicari akan ditampilkan.
Aturan Bisnis :tglpesan yang dimasukan harus sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data Pesanan barang.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data barang Pesanan barang.
Masalah Terbuka : -
4.4.2.12 Analisis Sistem Look up Data Return Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up return barangTipe Use Case
ID Use Case : 1.12 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data barang return barang berdasarkan tglreturn dalam sistem.
Prakondisi :Memastikan apakah data return barang yang akan di look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up return barang.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Pilih menu View barang dan kliksub menu data return Barang.
Langkah 2 :
Sistem merespon dengan menampilkan form data return barang.
Langkah 3:
User memasukan tglreturn.
Langkah 5 :
User mengklik data return barang yang dicari.
Langkah 4 :
Sistem akan secara otomatis mencari data return barang yang telah tersimpan.
Langkah 6:
Sistem akan menampilkan data return barang yang di cari.
Bidang Alternatif :
Alternatif langkah 3 :
3.1 jika tglreturn yang dimasukan tidak sesuai dengan yang ada di database, maka akan muncul informasi bahwa tglreturn yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look upreturn barang.
Postkondisi : Data return barang yang dicari akan ditampilkan.
Aturan Bisnis :tglreturn yang dimasukan harus sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data return barang.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data return barang.
Masalah Terbuka : -
4.4.2.13 Analisis Sistem Update data Penerimaan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Update penerimaan barang Tipe Use Case
ID Use Case : 1.13 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses update data penerimaan barang yang terjadi pada data penerimaan barang yang telah diinput.
Prakondisi :Memastikan Admin Gudang telah terhubung dengan data penerimaan barang yang akan di edit/update yang telah diinput sebelumnya kedalam sistem.
Pemicu :Usecase ini diinisiasi saat Admin Gudang akan melakukan proses update edit/ data barang masuk yang telah diinput sebelumnya kedalam sistem.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1:
User Pilih menu Transaksi dan kliksub menu penerimaan barang.
Langkah 4 :
User mengubah data barang yang akan diubah.
Langkah 5 :
User mengklik tombol update.
Langkah 2 :
Sistem merespon dengan menampilkan form data penerimaan barang
Langkah 6:
Data penerimaan barang yang datanya telah di ubah akan tersimpan kembali kedalam database.
Bidang Alternatif :
Alternatif langkah 5 :
5.1 jika data barang yang di update/edit tidak sesuai, maka akan muncul pesan pemberitahuan untuk memasukan data barang masuk yang benar.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan update/edit data barang masuk yang dilakukan oleh oleh Admin Gudang.
Postkondisi :Hasil proses update data barang masuk akan dimasukan kedalam database.
Aturan Bisnis : Data yang dimasukan harus sesuai
dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
Admin Gudang hanya mengubah databarang masuk.
Asumsi :Hanya admin gudang yang dapat melakukan update/edit data barang masuk.
Masalah Terbuka : -
4.4.2.14 Analisis Sistem Update data Pesanan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Update Pesanan barang Tipe Use Case
ID Use Case : 1.14 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses update data pesanan barang yang terjadi pada data barang pesanan yang telah diinput.
Prakondisi :Memastikan Supervisor telah terhubung dengan data pesanan barang yang akan di edit/update yang telah diinput sebelumnya kedalam sistem.
Pemicu :Usecase ini diinisiasi saat Supervisor akan melakukan proses update edit/ data pesanan barang yang telah diinput sebelumnya kedalam sistem.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1:
User Pilih menu Transaksi barang dan kliksub menu data pesanan barang.
Langkah 4 :
User mengubah data pesanan barang yang akan diubah.
Langkah 5 :
User mengklik tombol update.
Langkah 2 :
Sistem merespon dengan menampilkan form pesanan barang.
Langkah 6:
Data pesanan barang yang datanya telah di ubah akan tersimpan kembali kedalam database.
Bidang Alternatif : Alternatif langkah 5 :
5.1 jika data pesanan barang yang di update/edit tidak sesuai, maka akan muncul pesan pemberitahuan untuk
memasukan data pesanan barang yang benar.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan update/edit data pesanan barang yang dilakukan oleh Supervisor.
Postkondisi :Hasil proses update data pesanan barang akan dimasukan kedalam database.
Aturan Bisnis : Data yang dimasukan harus sesuai
dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
Supervisor hanya mengubah data pesanan barang.
Asumsi :Hanya Supervisor yang dapat melakukan update/edit data pesanan barang.
Masalah Terbuka : -
4.4.2.15 Analisis Sistem Update data Return Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Update Return barang Tipe Use Case
ID Use Case : 1.15 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses update data return barang yang terjadi pada data barang return yang telah diinput.
Prakondisi :Memastikan Supervisor telah terhubung dengan data return barang yang akan di edit/update yang telah diinput sebelumnya kedalam sistem.
Pemicu :Usecase ini diinisiasi saat Supervisor akan melakukan proses update edit/ data return barang yang telah diinput sebelumnya kedalam sistem.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1:
User Pilih menu Transaksi barang dan kliksub menu data return barang.
Langkah 2 :
Sistem merespon dengan menampilkan form return barang.
Langkah 4 :
User mengubah data return barang yang akan diubah.
Langkah 5 :
User mengklik
tombol update.
Langkah 6:
Data return barang yang datanya telah di ubah akan tersimpan kembali kedalam database.
Bidang Alternatif :
Alternatif langkah 5 :
5.1 jika data return barang yang di update/edit tidak sesuai, maka akan muncul pesan pemberitahuan untuk memasukan data return barang yang benar.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan update/edit data return barang yang dilakukan oleh Supervisor.
Postkondisi :Hasil proses update data return barang akan dimasukan kedalam database.
Aturan Bisnis : Data yang dimasukan harus sesuai
dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
Supervisor hanya mengubah data return barang.
Asumsi :Hanya Supervisor yang dapat melakukan update/edit data return barang.
Masalah Terbuka : -
4.4.2.16 Analisis Sistem Cetak laporan
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Cetak laporan Tipe Use Case
ID Use Case : 1.16 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan pencetakan laporan yang telah dikelola sebelumnya dalam sistem.
Prakondisi : Data atau laporan yang akan dicetak harus tersedia.
Pemicu : Usecase ini diinisiasi saat proses pencetakan laporan.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1:
User mengklik menu laporan dan pilih dan klik jenis laporan yang dipilih.
Langkah 3:
User mengatur tanggal laporan yang akan di cetak.
Langkah 6 :
User mengklik tombol view.
Langkah 8 :
User mengklik tombol cetak/print.
Langkah 2 :
Sistem merespon dengan menampilakan form laporan yang dipilih.
Langkah 7 :
Sistem akan merespon perintah dan printer akan mencetak laporan.
Bidang Alternatif :
Alternatif langkah 3 :
3.1 Jika data atau laporan yang dipilih tidak tersedia maka sistem akan memberikan pemberitahuan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan pencetakan laporan.
Postkondisi :Laporan yang telah dicetak akan diserahkan kepada Pimpinan.
Aturan Bisnis :Data atau laporan yang akan dicetak harus ada pada database.
Batasan Dan Spesifikasi Implementasi :
Supervisor hanya mencetak laporan.
Asumsi : Hanya Supervisor yang dapat mencetak laporan.
Masalah Terbuka : -
4.4.2.17 Analisis Sistem Cetak Struck Pembayaran
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Cetak Struk PembayaranTipe Use Case
ID Use Case : 1.17 Persyaratan Bisnis : □
Prioritas : Sedang Analisis Sistem :
Sumber :
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase inimendeskripsikan pencetakan struk biaya yang telah dikelola sebelumnya dalam sistem.
Prakondisi : Pembeli membayar kepada Kasir.
Pemicu : Usecase ini diinisiasi saat proses pencetakan struk biaya.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1:
User mengklik tombol view.
Langkah 3 :
User mengklik tombol cetak/print.
Langkah 2:
Sistem akan secara otomatis menampilkan data transaksi pembayaran.
Langkah 4 :
Sistem akan merespon perintah dan printer akan mencetak struk Pembayaran.
Bidang Alternatif : Alternatif langkah 2 :
2.1 Jika data transaksi pembayaran yang dipilih tidak
tersedia maka sistem akan memberikan pemberitahuan.
Kesimpulan :Usecase ini menyimpulkan tentang proses pencetakan struk pembayaran.
Postkondisi : Struk pembayaran pembeli.
Aturan Bisnis : Pembeli harus terlebih dahulu membayar kepada kasir.
Batasan Dan Spesifikasi Implementasi :
Kasir hanya mencetak struk pembayaran.
Asumsi : Hanya kasir yang dapat mencetak struk pembayaran.
Masalah Terbuka : -
4.4.3 Desain Sistem
4.4.3.1 Desain Sistem Login
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Login Tipe Use Case
ID Use Case : 1.1 Persyaratan Bisnis : □
Prioritas : Tinggi Desain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Admin Gudang, Pimpinan, Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian pada saat user pertama masuk kedalam sistem.
Prakondisi :User telah memiliki user name dan passwordnya masing-masing yang sudah secara otomatis sudah ada di Idcard.
Pemicu :Use case ini dilakukan untuk memastikan bahwa sistem hanya digunakan oleh user yang telah diberi hak akses berdasarkan kepentingannya.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
User Mengscankan barcode yang terdapat pada IDCard yang sudah ada username dan password(Form 1)
Langkah 3 :
Langkah 2 :
Sistem akan memproses dan menampilkan menu utama jika validasi IDCard dimasukkan adalah valid(form2).
Langkah 4 :
Apabila user membatalkan untuk mengklik tombol Cancel(Button).
Sistem akan menghentikan proses Login.
Bidang Alternatif :
Alternatif Langkah 2:
2.1 Sistem akan menampilkan pesan kesalahan jika kombinasi IDCard tidak valid, dan meminta pengguna untuk scankan IDCard yang benar.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah awal user hendak menggunakan sistem sesuai hak aksesnya.
Postkondisi :User masuk dan menggunakan sistem sesuai hak akses pelaku.
Aturan Bisnis : IDCard harus dimasukkan dengan data yang valid.
Batasan Dan Spesifikasi Implementasi :
Hanya user yang mempunyai hak akses saja yang bisa masuk kedalam sistem.
Asumsi : User telah memiliki IDCard.
Masalah Terbuka : User lupa/hilang IDCard .
4.4.3.2 Desain Sistem Input Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Input barang Tipe Use Case
ID Use Case : 1.2 Persyaratan Bisnis : □
Prioritas : Tinggi Desain Sistem :
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat l
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu menambah/input data barang.
Prakondisi : User telah memiliki data barang yang akan diinputkan
Pemicu :Use case ini dimulai saat user menyeleksi pilihan input data barang untuk menambah/input data barang .
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
Pilih menu Master dan klik sub menu input data barang.
Langkah 3:
User memasukan Kodebarcode(Text Box), Kategori (Text box), Stock (TextBox), dan Harga(TextBox)
Langkah 4 :
Cek semua data barang yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Simpan](Button)
Langkah 2 :
Sistem merespon dengan menampilkan form inputan barang (Form 3).
Langkah 5 : Sistem merespon dengan menyimpan data barang yang telah diinputkan tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data
(DataGridView).
Bidang Alternatif :
Alternatif langkah 3 :
3.1 KodeBarcode tidak boleh kosong (not null)
3.2 Kategori tidak boleh kosong (not null)
3.3 Stock tidak boleh kosong(not null)
3.4 Harga tidak boleh kosong (not null)
Alternatif 5: 5.1 jika data barang yang dimasukan tidak sesuai, maka akan muncul pesan pemberitahuan untuk memasukan data barang yang benar.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah input data barang oleh admin gudang.
Postkondisi :Data barang telah disimpan dan telah terupdate, dan sistem menampilkan kembali ke Form input barang.
Aturan Bisnis : Kode Barcode yang dimasukan harus
sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
Admin Gudang hanya menginput data barang.
Asumsi : Hanya Admin gudang yang dapat melakukan penginputan
data barang.
Masalah Terbuka :-
4.4.3.3 Desain Sistem Input Penerimaan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Input Penerimaan barang Tipe Use Case
ID Use Case : 1.3 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat ain :
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu menambah/input data penerimaan barang.
Prakondisi :User telah memiliki data penerimaan barang yang akan diinputkan
Pemicu :Use case ini dimulai saat user menyeleksi pilihan input data barang untuk menambah/input data penerimaan barang .
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
Pilih menu Transaksi dan klik sub menu input penerimaan barang.
Langkah 3:
User mengklik TabControl Penerimaan dan Detail Perimaan lalu
User memasukan
tglpenerimaan(DateTimePicker), barcode (TextBox),
nopenerimaan(Text Box), nopesan(TextBox),
Langkah 2 :
Sistem merespon dengan menampilkan form inputan penerimaan barang (Form 4).
Langkah 5 : Sistem merespon dengan menyimpan data penerimaan barang masuk yang telah diinputkan tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data
(DataGridView).
QTYpenerimaan(TextBox).
Langkah 4 :
Cek semua data penerimaan barang masuk yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Simpan](Button).
Bidang Alternatif :
Alternatif langkah 3 :
3.1 tglpenerimaan tidak boleh kosong (not null)
3.2 KodeBarcode tidak boleh kosong (not null)
3.3 Nopenerimaan tidak boleh kosong(not null)
3.4 Nopesan tidak boleh kosong (not null)
3.5 QTYpenerimaan tidak boleh kosong (not null)
Alternatif 5: 5.1 jika data penerimaan barang masuk yang dimasukan tidak sesuai, maka akan muncul pesan pemberitahuan untuk memasukan data penerimaan barang masuk yang benar.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah input data penerimaan barang masuk oleh admin gudang.
Postkondisi :Data barang telah disimpan dan telah terupdate, dan sistem menampilkan kembali ke Form input penerimaan barang.
Aturan Bisnis : nopenerimaan yang dimasukan harus sesuai
dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
Admin Gudang hanya menginput penerimaan data barang masuk.
Asumsi :Hanya Admin gudang yang dapat melakukan penginputan data barang masuk.
Masalah Terbuka :-
4.4.3.4 Desain Sistem Penjualan barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Penjualan barang Tipe Use Case
ID Use Case : 1.4 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu menambah data penjualan barang dengan men-Scan barcode barang.
Prakondisi :User Telah memiliki data penjualan barang yang akan diinputkan menggunakan scanbarcode.
Pemicu :Use case ini dimulai saat user menyeleksi pilihan input data barang untuk menambah data penjualan barang.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
Pilih menu Transaksi dan klik sub menu input data penjualan barang.
Langkah 3:
Masukkan data barang keluar dengan mengescankan barcode barang menggunakan alat Scanner Barcode kedalam field yang sudah disediakan dengan benar.
Langkah 4 :
Cek semua data penjualan barang yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Bayar](Button).
Langkah 2:
Sistem merespon dengan menampilkan form inputan penjualan barang(Form5).
Langkah 5 :Sistem merespon dengan mencetak struck pembayaran.
Langkah 6 :
Setelah sistem mencetakstruck pembayaran maka Sistem akan menyimpan data penjualan barang yang telah diinputkan dengan scandbarcode tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data.(Data Grid View).
Bidang Alternatif : Alternatif Langkah 5:
5.1 Jika Sistem tidak bisa membaca scanbarcode barang, karena ketidakjelasan barcode, maka user harus menginputkan kodebarcode barang kedalam field yang
sudah disediakan.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah input data penjualan barang oleh Kasir.
Postkondisi :Data barang telah dibayar dan disimpan dan telah terupdate, dan sistem menampilkan kembali Form Input Penjualan barang.
Aturan Bisnis : User sudah menyiapkan alat
scanbarcode untuk menscan barcode yang valid.
Batasan Dan Spesifikasi Implementasi :
Kasir hanya menginput data penjualan barang dengan mengscan barcode pada kodebarcode barang untuk input penjualan barang.
Asumsi :Hanya Kasir yang dapat melakukan penginputan data penjualan barang.
Masalah Terbuka : -
4.4.3.5 Desain Sistem Input Data Pesanan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Pesanan Barang Tipe Use Case
ID Use Case : 1.5 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu mengPesanan Barang .
Prakondisi :User Telah memiliki data pesanan barang yang akan diinputkan.
Pemicu :Use case ini dimulai saat user meyeleksi pilihan input data pesanan barang.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
Pilih menu Transaksi dan kliksub menu input data Pesanan barang.
Langkah 2 :
Sistem merespon dengan menampilkan form inputan Pesanan barang(Form 6).
Langkah 3:
User memasukkan
tglbarang pesan (DateTimePicker), kategori(TextBox)
nopesan (Text Box),
QTYpesan(TextBox).
Langkah 4 :
Cek semua data Pesanan barang yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Simpan](Button).
Langkah 5 :
Sistem merespon dengan menyimpan data Pesanan barang yang telah diinputkan tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data.
(DataGridView)
Bidang Alternatif :
Alternatif langkah 3 :
3.1 tglbarang pesan tidak boleh kosong (not null),
3.2 kategori tidak boleh kosong (not null),
3.3 Nopesan tidak boleh kosong(not null),
3.4 QTYpesan tidak boleh kosong (not null).
Alternatif 5: 5.1 jika data pesanan barang yang dimasukan tidak sesuai, maka akan muncul pesan pemberitahuan untuk memasukan data pesanan barang yang benar.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah Pesanan Barang oleh Supervisor.
Postkondisi :Data barang yang sudah diinputkan akan disimpan dan akan terupdate,dan sistem menampilkan kembali Form Input Pesanan Barang.
Aturan Bisnis : nopesan yang dimasukan harus sesuai
dengan format yang telah ditentukan oleh aplikasi
Batasan Dan Spesifikasi Implementasi :
Supervisor hanya menginput data Pesanan Barang.
Asumsi :Hanya Supervisor yang dapat melakukan penginputan dataPesanan barang .
Masalah Terbuka : -
4.4.3.6 Desain Sistem Input Data Return Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014 2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Return Barang Tipe Use Case
ID Use Case : 1.6 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat l
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu Return Barang.
Prakondisi :User Telah memiliki data return barang yang akan diinputkan.
Pemicu :Use case ini dimulai saat user menyeleksi pilihan input data return barang untuk menambah ,merubah, dan menghapus data barang.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
Pilih menu Transaksi dan kliksub menu input data return barang.
Langkah 3:
User memasukkan tglbarang return (DateTimePicker), kategori(TextBox),
noreturn (Text Box),
QTYreturn(TextBox).
Langkah 2 :
Sistem merespon dengan menampilkan form inputan return barang(Form 7).
Langkah 5 : Sistem merespon dengan menyimpan data barang return yang telah diinputkan tersebut kedalam database sistem dan menampilkan kembali informasi yang telah terupdate kedalam Display Informasi data.
(DataGridView)
Langkah 4 :Cek semua data barang return yang sudah dimasukkan, bila tidak ada perubahan maka user melanjutkan dengan klik tombol[Simpan](Button).
Bidang Alternatif :
Alternatif langkah 3 :
3.1 tglbarang return tidak boleh kosong (not null),
3.2 Kategori tidak boleh kosong (not null),
3.3 Nopesan tidak boleh kosong(not null),
3.4 QTYreturn tidak boleh kosong (not null).
Alternatif 5: 5.1 jika data return barang yang dimasukan tidak sesuai, maka akan muncul pesan pemberitahuan untuk memasukan data return barang yang benar.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah input data return barang oleh Supervisor.
Postkondisi :Data barang telah disimpan dan telah terupdate,dan sistem menampilkan kembali Form Utama.
Aturan Bisnis : User sudah menyiapkan data return
barang yang valid.Batasan Dan Spesifikasi Implementasi :
Supervisor hanya menginput data return barang.
Asumsi :Hanya Supervisor yang dapat melakukan penginputan data return barang.
Masalah Terbuka : -
4.4.3.7 Desain Sistem Pencarian Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Pencarian barang Tipe Use Case
ID Use Case : 1.7 Persyaratan Bisnis : □
Prioritas : Tinggi Desain Sistem :
Sumber :
Pelaku Bisnis Utama : Pembeli
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu untuk pencarian barang .
Prakondisi : -
Pemicu : Use case ini dimulai saat user pencarian barang.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User menginputkan :
Kategori(TextBox), dan nama Barang(TextBox).
Langkah 2 :
Sistem merespon dengan menampilkan informasi barang yang dicari(Form 8).
Bidang Alternatif :
Alternatif Langkah 2 :
2.1 Jika sistem tidak merespon maka pencarian barang gagal karena barang yang dicari tidak ada dan kembali ke langkah 1.
Kesimpulan :Use-case ini menyimpulkan bagaimana langkah pencarian barang oleh pembeli.
Postkondisi :Pencarian barang sudah dicari maka sistem menampilkan kembali form pencarian barang.
Aturan Bisnis : -
Batasan Dan Spesifikasi Implementasi :
pembeli hanya menginputkandata barang pada komputer yang sudah disediakan
Asumsi : Pembeli yang dapat melakukan Pencarian Barang.
Masalah Terbuka : -
4.4.3.8 Desain Sistem Look Up data Penerimaan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case :Look up data penerimaan barang
Tipe Use Case
ID Use Case : 1.8 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data penerimaan barang masuk berdasarkan tglpenerimaan dalam sistem.
Prakondisi :Memastikan apakah penerimaan data barang masuk yang akan di look up sudah ada didalam database atau belum.
Pemicu :Usecase ini di inisiasi saat look up penerimaan barang masuk.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User klik data barang masuk.
Langkah 3 :
User memasukan tglpenerimaan (DateTimePicker).
Langkah 4 :
User mengklik tombol[Cari](Button) .
Langkah 2 :
Sistem merespon dengan menampilkan form data penerimaan barang masuk (form9).
Langkah 5:
Sistem akan secara otomatis mencari data penerimaan barang masuk yang telah tersimpan kemudian menampilkan kedalam tabel (DataGridView).
Bidang Alternatif :
Alternatif langkah 3 :
3.1 jika tglpenerimaan yang dimasukan tidak sesuai dengan yang ada di database, maka sistem akan muncul informasi bahwa tglpenerimaan yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look uppenerimaan barang masuk.
Postkondisi :Data penerimaanbarang masuk yang dicari akan ditampilkan.
Aturan Bisnis : Tglpenerimaan yang dimasukan
harus sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data penerimaan barang masuk.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data penerimaan barang masuk.
Masalah Terbuka : -
4.4.3.9 Desain Sistem Look up Data Penjualan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up data penjualan barangTipe Use Case
ID Use Case : 1.9 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data penjualan barang berdasarkan tglpenjualan dalam sistem.
Prakondisi :Memastikan apakah data penjualan barang yang akan di look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up penjualan barang.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 :
User klik data penjualan barang.
Langkah 3 :
User memasukan tglpenjualan(DateTimePicker)
Langkah 2 :
Sistem merespon dengan menampilkan form data penjualan barang (form10).
Langkah 5:
Langkah 4:
User mengklik tombol[Cari](Button).
Sistem akan secara otomatis mencari data barang keluar yang telah tersimpan kemudian menampilkan kedalam tabel (DataGridView).
Bidang Alternatif :
Alternatif langkah 3 :
3.1 jika tglpenjualan yang dimasukan tidak sesuai dengan yang ada di database, maka sistemn akan muncul informasi bahwa tglpenjualan yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look uppenjualan barang.
Postkondisi : Data penjualan barang yang dicari akan ditampilkan.
Aturan Bisnis : Tglpenjualan yang dimasukan harus
sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data penjualan barang.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data penjualan barang.
Masalah Terbuka : -
4.4.3.10 Desain Sistem Look up Data Persediaan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up Persediaan barangTipe Use Case
ID Use Case : 1.10 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data barang Persediaan barang berdasarkan stock dalam sistem.
Prakondisi :Memastikan apakah data persediaan barang yang akan di look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look persediaan barang.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User klik data barang persediaan.
Langkah 3 :
User memasukan stockbarang (TextBox).
Langkah 4 :
User mengklik tombol[Cari](Button).
Langkah 2 :
Sistem merespon dengan menampilkan form data persediaan barang (form11).
Langkah 5:
Sistem akan secara otomatis mencari datapersediaan barang yang telah tersimpan kemudian menampilkan kedalam tabel (DataGridView).
Bidang Alternatif :
Alternatif langkah 3 :
3.1 jika stockbarang yang dimasukan tidak sesuai dengan yang ada di database, maka akan muncul informasi bahwa stockbarang yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look uppersediaan barang.
Postkondisi : Data persediaan barang yang dicari akan ditampilkan.
Aturan Bisnis : stockbarang yang dimasukan harus
sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data persediaan barang.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data barang persediaan barang.
Masalah Terbuka : -
4.4.3.11 Desain Sistem Look up Data Pesanan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up Pesanan barangTipe Use Case
ID Use Case : 1.11 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data barang Pesanan barang berdasarkan tglpesan dalam sistem.
Prakondisi :Memastikan apakah data Pesanan barang yang akan di look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up Pesanan barang.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User klik data pesanan barang.
Langkah 3 :
Usermemasukan tglpesan(DateTimePicker).
Langkah 4 :
User mengklik tombol [Cari](Button).
Langkah 2 :
Sistem merespon dengan menampilkan form data pesanan barang (form12).
Langkah 5:
Sistem akan secara otomatis mencari datapesanan barang yang telah tersimpan kemudian menampilkan kedalam tabel (DataGridView).
Bidang Alternatif :
Alternatif langkah 3 :
3.1 jika tglpesan yang dimasukan tidak sesuai dengan yang ada di database, maka akan muncul informasi bahwa tglpesan yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look upPesanan barang.
Postkondisi : Data Pesanan barang yang dicari akan ditampilkan.
Aturan Bisnis : tglpesan yang dimasukan harus
sesuai dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data Pesanan barang.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data barang Pesanan barang.
Masalah Terbuka : -
4.4.3.12 Desain Sistem Look up Data Return Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Look up return barang Tipe Use Case
ID Use Case : 1.12 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses look up data barang return barang berdasarkan tglreturn dalam sistem.
Prakondisi :Memastikan apakah data return barang yang akan di look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up return barang.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
User klik data Return barang.
Langkah 3 :
Usermemasukan tglreturn(DateTimePicker) .
Langkah 5 :
User mengklik tombol[Cari](Button).
Langkah 2 :
Sistem merespon dengan menampilkan form data return barang (form13).
Langkah 4:
Sistem akan secara otomatis mencari data return barang yang telah tersimpan kemudian menampilkan kedalam tabel (DataGridView).
Bidang Alternatif : Alternatif langkah 3 :
3.1 jika tglreturn yang dimasukan tidak sesuai dengan yang ada di database, maka akan muncul informasi bahwa
tglreturn yang dimasukan tidak ada dalam database dan tidak dapat ditampilkan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan look upreturn barang.
Postkondisi : Data return barang yang dicari akan ditampilkan.
Aturan Bisnis : tglreturn yang dimasukan harus sesuai
dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
User hanya look up data return barang.
Asumsi :Hanya Supervisor dan Pimpinan yang dapat melakukan look up data return barang.
Masalah Terbuka : -
4.4.3.13 Desain Sistem Update Data Penerimaan barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case :Update data Penerimaan barang
Tipe Use Case
ID Use Case : 1.13 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses update data penerimaan barang masuk yang terjadi pada data barang masuk yang telah diinput.
Prakondisi :Memastikan Admin Gudang telah terhubung dengan data penerimaan barang masuk yang akan di edit/update yang telah diinput sebelumnya kedalam sistem.
Pemicu :Usecase ini diinisiasi saat Admin Gudang akan melakukan proses update edit/ data penerimaan barang masuk yang telah diinput sebelumnya kedalam sistem.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1:
User Pilih menu Transaksi
Langkah 2 :
Sistem merespon dengan
barang dan kliksub menu input penerimaan barang.
Langkah 3 :
User mengklik dan mengubah data penerimaan barang masuk yang akan diubah.
Langkah 5 :
User mengubah penerimaan barang mengklik tombol [Update](Button).
menampilkan form inputan penerimaanbarang masuk(Form 4).
Langkah 4 :
Sistem merespon dengan menampilkan penerimaan data barang masuk.
Langkah 6:
Data penerimaan barang masuk yang datanya telah di ubah akan tersimpan kembali kedalam database(Data gridView)
Bidang Alternatif :
Alternatif langkah 5 :
5.1 jika data penerimaan barang masuk yang di update/edit tidak sesuai, maka akan muncul pesan pemberitahuan untuk memasukan data penerimaan barang masuk yang benar.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan update/edit data penerimaan barang masuk yang dilakukan oleh oleh Admin Gudang.
Postkondisi :Hasil proses update data penerimaan barang masuk akan dimasukan kedalam database.
Aturan Bisnis : Data yang dimasukan harus sesuai
dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
Admin Gudang hanya mengubah penerimaan databarang masuk.
Asumsi :Hanya admin gudang yang dapat melakukan update/edit data penerimaan barang masuk.
Masalah Terbuka : -
4.4.3.14 Desain Sistem Update data Pesanan Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Update data Pesanan barang Tipe Use Case
ID Use Case : 1.14 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses update data pesanan barang yang terjadi pada data barang pesanan yang telah diinput.
Prakondisi :Memastikan Supervisor telah terhubung dengan data pesanan barang yang akan di edit/update yang telah diinput sebelumnya kedalam sistem.
Pemicu :Usecase ini diinisiasi saat Supervisor akan melakukan proses update edit/ data pesanan barang yang telah diinput sebelumnya kedalam sistem.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1:
User Pilih menu Transaksi barang dan kliksub menu data pesanan barang.
Langkah 4 :
User mengklik dan mengubah data pesanan barang yang akan diubah.
Langkah 5 :
User mengubah barang mengklik tombol [Update](Button).
Langkah 2 :
Sistem merespon dengan menampilkan form inputan pesanan barang(Form6).
Langkah 6:
Data pesanan barang yang datanya telah di ubah akan tersimpan kembali kedalam database(Data Grid View).
Bidang Alternatif :
Alternatif langkah 5 :
5.1 jika data pesanan barang yang di update/edit tidak sesuai, maka akan muncul pesan pemberitahuan untuk memasukan data pesanan barang yang benar.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan update/edit data pesanan barang yang dilakukan oleh Supervisor.
Postkondisi : Hasil proses update data pesanan barang akan dimasukan
kedalam database.
Aturan Bisnis : Data yang dimasukan harus sesuai
dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
Supervisor hanya mengubah data pesanan barang.
Asumsi :Hanya Supervisor yang dapat melakukan update/edit data pesanan barang.
Masalah Terbuka : -
4.4.3.15 Desain Sistem Update Data Return Barang
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Update data Return barang Tipe Use Case
ID Use Case : 1.15 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan proses update data return barang yang terjadi pada data barang return yang telah diinput.
Prakondisi :Memastikan Supervisor telah terhubung dengan data return barang yang akan di edit/update yang telah diinput sebelumnya kedalam sistem.
Pemicu :Usecase ini diinisiasi saat Supervisor akan melakukan proses update edit/ data return barang yang telah diinput sebelumnya kedalam sistem.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1:
User Pilih menu Transaksi barang dan kliksub menu data return barang.
Langkah 3 :
Langkah 2 :
Sistem merespon dengan menampilkan form inputan return barang(Form 7).
Langkah 6:
User mengklik dan mengubah data return barang yang akan diubah.
Langkah 5 :
User mengklik
tombol update(Button).
Data return barang yang datanya telah di ubah akan tersimpan kembali kedalam database(Data Grid View).
Bidang Alternatif :
Alternatif langkah 5 :
5.1 jika data return barang yang di update/edit tidak sesuai, maka akan muncul pesan pemberitahuan untuk memasukan data return barang yang benar.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan update/edit data return barang yang dilakukan oleh Supervisor.
Postkondisi :Hasil proses update data return barang akan dimasukan kedalam database.
Aturan Bisnis : Data yang dimasukan harus sesuai
dengan format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi Implementasi :
Supervisor hanya mengubah data return barang.
Asumsi :Hanya Supervisor yang dapat melakukan update/edit data return barang.
Masalah Terbuka : -
4.4.3.16 Desain Sistem Cetak laporan
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Cetak laporan Tipe Use Case
ID Use Case : 1.16 Persyaratan Bisnis : □
Prioritas : TinggiDesain Sistem :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan pencetakan laporan yang telah dikelola sebelumnya dalam sistem.
Prakondisi : Data atau laporan yang akan dicetak harus tersedia.
Pemicu : Usecase ini diinisiasi saat proses pencetakan laporan.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1:
User mengklik menu laporan dan pilih dan klik jenis laporan yang dipilih.
Langkah 3:
User memilih jenis laporan (Combo Box) dan mengatur tanggal laporan yang akan di cetak(DateTimePicker).
Langkah 6 :
User mengklik tombol view(Button).
Langkah 8 :
User mengklik tombol cetak/print(Button).
Langkah 2 :
Sistem merespon dengan menampilkan form laporan yang dipilih(Form 14).
Langkah 7 :
Sistem akan merespon perintah dan printer akan mencetak laporan.
Bidang Alternatif :
Alternatif langkah 3 :
3.1 Jika data atau laporan yang dipilih tidak tersedia maka sistem akan memberikan pemberitahuan.
Kesimpulan :Usecase ini menyimpulkan tentang kegiatan pencetakan laporan.
Postkondisi :Laporan yang telah dicetak akan diserahkan kepada Pimpinan.
Aturan Bisnis :Data atau laporan yang akan dicetak harus ada pada database.
Batasan Dan Spesifikasi Supervisor hanya mencetak laporan.
Implementasi :
Asumsi : Hanya Supervisor yang dapat mencetak laporan.
Masalah Terbuka : -
4.4.3.17 Desain Sistem Cetak Struck Pembayaran
Pengarang : 1. Meli Amelia Tanggal : 17 September 2014
2. Aminatul Rosidah Versi : 1.0
Nama Use Case : Cetak Struk PembayaranTipe Use Case
ID Use Case : 1.17 Persyaratan Bisnis : □
Prioritas : SedangDesain Sistem :
Sumber :
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain
Deskripsi :Usecase ini mendeskripsikan pencetakan struk biaya yang telah dikelola sebelumnya dalam sistem.
Prakondisi : Pembeli membayar kepada Kasir.
Pemicu : Usecase ini diinisiasi saat proses pencetakan struk biaya.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1:
User mengklik tombol view(Button)
Langkah 3 :
User mengklik tombol cetak/print(Button).
Langkah 2:
Sistem akan secara otomatis menampilkan data transaksi pembayaran(Form18).
Langkah 4 :
Sistem akan merespon perintah dan printer akan mencetak struk Pembayaran.
Bidang Alternatif :
Alternatif langkah 2 :
2.1 Jika data transaksi pembayaran yang dipilih tidak tersedia maka sistem akan memberikan pemberitahuan.
Kesimpulan :Usecase ini menyimpulkan tentang proses pencetakan struk pembayaran.
Postkondisi : Struk pembayaran pembeli.
Aturan Bisnis : pembeli harus terlebih dahulu membayar kepada kasir.
Batasan Dan Spesifikasi Implementasi :
Kasir hanya mencetak struk pembayaran.
Asumsi : Hanya kasir yang dapat mencetak struk pembayaran.
Masalah Terbuka : -
4.5 Diagram Ketergantungan Use Case
4.5.1 Inheritance
Gambar 4.14 Inheritance
4.5.2 Extension
Gambar 4.15 Extension Penerimaan Masuk
Gambar 4.16 Extension Penjualan barang
Gambar 4.17 Extension Pesanan Barang
Gambar 4.18 Extension Return Barang
Gambar 4.19 Extension Pencarian Barang
Gambar 4.20 Extension Persediaan Barang
Gambar 4.21 Extension Laporan Barang
Gambar 4.22 Extension Cetak Struck Pembayaran
4.5.3 Depends On
Gambar 4.23 Depends On Persediaan Barang
Gambar 4.24 Depends On Penerimaan Masuk
Gambar 4.25 Depends On Penjualan barang
Gambar 4.26 Depends On Pesanan Barang
Gambar 4.27 Depends On Return Barang
4.6 Use Case Diagram
Gambar 4.28 Use Case4.7 Rancangan Database
4.7.1 Entity Relation Diagram (ERD)
Gambar 4.29 Entity Relation Diagram (ERD)
4.7.2 Relasi Antar Tabel
Gambar 4.30 Relasi Antar Tabel
4.7.3 Spesifikasi File
Spesifikasi file merupakan penjabaran dari perancangan database
termasuk field-filed pada beberapa tabel, yaitu :
4.7.3.1 TabelBarang
Field Tipe Data Length Ket
1 Barcode Char 20 Primary Key /
Not Null
2 KdKategori Char 10
3 NamaBarang Varchar 35
4 Harga Currency
5 Stock Barang Char 10
4.7.3.2 TabelPegawai
Field Tipe Data Length Ket
1 KdPegawai Char 10 Primary Key / Not Null
2 NamaPegawai Varchar 25
3 Alamat Varchar 35
4 Jabatan Varchar 20
4.7.3.3 TabelPenerimaanBarang
Field Tipe Data Length Ket
1 NoPenerimaan Char 10 Primary Key / Not Null
2 KdPegawai Char 10
3 TglPenerimaan Date -
4.7.3.4 Tabel Detail PenerimaanBarang
Field Tipe Data Length Ket
1 NoDpenerimaan Char 10 Primary Key / Not Null
2 NoPenerimaan Char 10
3 Nopesan Char 10
4 Barcode Char 20
5 QTYpesan Char 10
6 Harga Currency -
4.7.3.5 TabelCustomer
Field Tipe Data Length Ket
1 NoCustomer Char 10 Primary Key / Not Null
2 NoTransaksi Char 10
3 KdPegawai Char 10
4 NamaCustomer
Varchar 25
5 QTYbeli Char 10
6 Tglbeli Date -
4.7.3.6 TabelPesanan Barang
Field Tipe Data Length Ket
1 Nopesan Char 10 Primary Key / Not Null
2 Kdpegawai Char 10
3 Tglpesan Date -
4.7.3.7 TabelDetailPesananBarang
Field Tipe Data Length Ket
1 NoDPesanan Char 10 Primary Key / Not Null
2 Nopesan Char 10
3 Barcode Char 20
4 QTYpesan Char 10
5 Harga Currency -
4.7.3.8 TabelReturnBarang
Field Tipe Data
Length Ket
1 NoReturn Char 10 Primary Key / Not Null
2 Kdpegawai Char 10
3 Date Date -
4.7.3.9 TabelDetailReturnBarang
Field Tipe Data Length Ket
1 NoDReturn Char 10 Primary Key / Not Null
2 NoReturn Char 10
3 NoPenerimaan Char 10
4 Barcode Char 20
5 Harga Currency -
6 QTYReturn Char 10
4.7.3.10 TabelKategori
Field Tipe Data Length Ket
1 KdKategori Char 10 Primary Key / Not Null
2 NamaKategori Char 10
4.7.3.11 Tabel Penjualan
Field Tipe Data Length Ket
1 NoTransaksi Char 10 Primary Key / Not Null
2 KdPegawai Char 10
3 Barcode Char 20
4.7.4 Diagram Kelas (Classs Diagram)
Gambar 4.31 Diagram Kelas
4.8 Diagram Aktivitas (Activity Diagram)
4.8.1 Diagram Aktivitas Login
Gambar 4.32 Diagram Aktivitas Login
4.8.2 Diagram Aktivitas Input Barang
Gambar 4.33 Diagram Aktivitas input barang
4.8.3 Diagram Aktivitas Input Penerimaan Barang
Gambar 4.34 Input penerimaan barang
4.8.4 Diagram Aktivitas Penjualan Barang
Gambar 4.35 Diagram Aktivitas Penjualan barang
4.8.5 Diagram Aktivitas Pesanan Barang
Gambar 4.36 Diagram Aktivitas Pesanan Barang
4.8.6 Diagram Aktivitas Return Barang
Gambar 4.37 Diagram Aktivitas Return Barang
4.8.7 Diagram Aktivitas Pencarian Barang
Gambar 4.33 Diagram Aktivitas Pencarian Barang
4.8.8 Diagram Aktivitas Look Up Data Penerimaan barang
Gambar 4.34 Look Up Data Penerimaan Barang
4.8.9 Diagram Aktivitas Look Up Data Penjualan Barang
Gambar 4.35 Look Up Data Penjualan Barang
4.8.10 Diagram Aktivitas Look Up Data Persediaan Barang
Gambar 4.36 Look Up Data Persediaan Barang
4.8.11 Diagram Aktivitas Look Up Data Pesanan Barang
Gambar 4.37 Look Up Data Pesanan Barang
4.8.12 Diagram Aktivitas Look Up Data Return Barang
Gambar 4.38 Look Up Data Return barang
4.8.13 Diagram Aktivitas Update Data Penerimaan Barang
Gambar 4.39 Update Data Penerimaan Barang
4.8.14 Diagram Aktivitas Update Pesanan barang
Gambar 4.40 Update Pesanan barang
4.8.15 Diagram Aktivitas Update Data Return Barang
Gambar 4.41 Update Data Return barang
4.8.16 Diagram Aktivitas Cetak Laporan
Gambar 4.42 Cetak Laporan
4.8.17 Diagram Aktivitas Cetak Struck Pembayaran
Gambar 4.43 Cetak Struk Pembayaran
4.9 Sequence Diagram
4.9.1 Sequence Diagram Login
Gambar 4.44 Sequence Diagram Login
4.9.2 Sequence Diagram Input Barang
Gambar 4.45 Sequence Diagram Input Barang
4.9.3 Sequence Diagram Penerimaan Barang
Gambar 4.46 Sequence Diagram Penerimaan Barang
4.9.4 Sequence Diagram Penjualan Barang
Gambar 4.47 Sequence Diagram Penjualan Barang
4.9.5 Sequence Diagram Pesanan Barang
Gambar 4.48 Sequence Diagram Pesanan Barang
4.9.6 Sequence Diagram Return Barang
Gambar 4.49 Sequence Diagram Return Barang
4.9.7 Sequence Diagram Pencarian Barang
Gambar 4.50 Sequence Diagram Pencarian Barang
4.9.8 Sequence Diagram Look Up Data Penerimaan Barang
Gambar 4.51 Sequence Diagram Look Up Data Penerimaan Barang
4.9.9 Sequence Diagram Look Up Data Penjualan Barang
Gambar 4.52 Sequence Diagram Look Up Data Penjualan Barang
4.9.10 Sequence Diagram Look Up Data Persediaan Barang
Gambar 4.53 Sequence Diagram Look Up Data Persediaan
4.9.11 Sequence Diagram Look Up Data Pesanan Barang
Gambar 4.54 Sequence Diagram Look Up Data Pesanan Barang
4.9.12 Sequence Diagram Look Up Data Return Barang
Gambar 4.55 Sequence Diagram Look Up Data Return Barang
4.9.13 Sequence Diagram Update Data Penerimaan Barang
Gambar 4.56 Sequence Diagram Update Data Penerimaan
4.9.14 Sequence Diagram Update Data Pesanan Barang
Gambar 4.57 Sequence Diagram Update Data Pesanan
4.9.15 Sequence Diagram Update Data Return Barang
Gambar 4.58 Sequence Diagram Update Return Barang
4.9.16 Sequence Diagram Cetak Laporan
Gambar 4.59 Sequence Diagram Cetak Laporan
4.9.17 Sequence Diagram Struck Pembayaran
Gambar 4.60 Sequence Diagram Struck Pembayaran
4.10 Deployment Diagram
Gambar 4.61 Deployment Diagram
4.11 User Interface
4.11.1 User Interface Login
Gambar 4.62 User Interface Login (Form 1)
4.11.2 User Interface Menu Utama
Gambar 4.63 User Interface Menu Utama (Form 2)
4.11.3 User Interface Input Barang
Gambar 4.64 User Interface Input Barang (Form 3)
4.11.4 User Interface Input Penerimaan Barang
Gambar 4.65 User Interface Penerimaan Barang (Form 4)
4.11.5 User Interface Penjualan Barang
Gambar 4.66 User Interface Penjualan Barang (Form 5)
4.11.6 User Interface Pesanan Barang
Gambar 4.67 User Interface Pesanan Barang (Form 6)
4.11.7 User Interface Return Barang
Gambar 4.68 User Interface Return Barang (Form 7)
4.11.8 User Interface Pencarian Barang
Gambar 4.67 User Interface Pencarian Barang (Form 8)
4.11.9 User Interface Look Up Data Penerimaan Barang
Gambar 4.68 User Interface Look Up Penerimaan Barang (Form 9)
4.11.10 User Interface Look Up Data Penjualan Barang
Gambar 4.69 User Interface Look Up Penjualan (Form 10)
4.11.11 User Interface Look Up Data Persediaan Barang
Gambar 4.70 User Interface Look Up Persediaan (Form 11)
4.11.12 User Interface Look Up Pesanan Barang
Gambar 4.71 User Interface Look UpPesanan (Form 12)
4.11.13 User Interface Look Up Data Return Barang
Gambar 4.72 User Interface Return (Form 13)
4.11.14 User Interface Laporan
Gambar 4.75 User Interface Laporan (Form 14)
4.11.15 User Interface Pegawai
Gambar 4.76 User Interface Pegawai (Form 15)
4.11.16 User Interface Kategori
Gambar 4.77 User Interface Kategori(Form 16)
4.11.17 User Interface Customer
Gambar 4.78 User Interface Customer(Form 17)
BAB V
PENUTUP
5.1 Kesimpulan
Setelah melakukan observasi pada SALEMBA Toko Buku, maka
dapat diperoleh simpulan sebagai berikut :
1. Salemba Toko Buku merupakan perusahaan yang
bergerak dalam bidang Penjualan Buku dan ATK.
2. Sistem baru yang dikembangkan dapat menghindari
kesulitan dalam pencarian data barang, data
persediaan, serta meningkatkan produktivitas
pekerjaan dan efisiensi waktu.
3. Dengan menggunakan program aplikasi yang
dirancang didapat keuntungan sebagai berikut:
a. Pencatatan data barang dan persediaan dapat
lebih akurat.
b. Mudah menyajikan informasi
4. Dengan menggunakan sistem baru, memudahkan
dalam pembuatan laporan.
5. Perancangan sistem informasi ini menggunakan Unified
Modelling Language (UML), yang merupakan sebuah
“bahasa” yang telah menjadi standar instansi untuk
visualisasi, merancang dan mendokumentasikan suatu
sistem.
5.2 Saran
Adapun saran-saran sehubungan dengan sistem baru yang dirancang adalah:
1. Dalam penerapan sistem baru ini, perlu dilakukan pelatihan terhadap
karyawan untuk menghindari terjadinya kesulitan dan kesalahan-
kesalahan dalam pengoperasian sistem.
2. Ketelitian dan kecermatan di bidang komputer harus diperhatikan
dengan sungguh-sungguh dan diperlukan tenaga ahli yang terampil
baik dalam pengoperasian maupun pengontrolan hardware.
DAFTAR PUSTAKA
Whitten. Jeffry L., Lonnie D. Bentley., Kevin C Ditman. 2004 Metode
Desain dan Analisis Sistem edisi 6. Yogyakarta:
PenerbitAndidanMcGraw Hail Education
Kadir, Abdul. 2003. Pengenalan Sistem Informasi. Yogyakarta : Andi
Wahyudi, Bambang. 2008. Konsep Sistem Informasi. Yogyakarta : Andi
Nugroho, Bunafit.2005. Database Relasional dengan MYSQL. Yogyakarta: Andi
Th Arie Prabawati.2010. Belajar Pemrograman Visual Basic 2010. Yogyakarta: Andi