perancangan sistem informasi inventori

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


Penguji II


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



Penjualan Barang......................................52


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


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 )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 )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



Nama Use Case : Input Barang Tipe Use Case

ID Use Case : 1.2


Sumber : -

Pelaku Bisnis Utama : Admin Gudang


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



Nama Use Case : Input Penerimaan BarangTipe Use Case

ID Use Case : 1.3


Sumber : -




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



Nama Use Case : Penjualan Barang Tipe Use Case

ID Use Case : 1.4


Sumber : -

Pelaku Bisnis Utama : Kasir



Deskripsi :Usecase ini mendeskripsikan proses penjualan barang menggunakan barcode yang dilakukan oleh kasir ke dalam sistem.

4.1.1.5 Persyaratan Bisnis Pesanan Barang



Nama Use Case : Pesanan Barang Tipe Use Case

ID Use Case : 1.5


Sumber : -

Pelaku Bisnis Utama : Supervisor



Deskripsi :Usecase ini mendeskripsikan proses penginputan pesanan barang yang dilakukan oleh Supervisor ke dalam sistem.

4.4.1.6 Persyaratan Bisnis Return Barang



Nama Use Case : Return Barang Tipe Use Case

ID Use Case : 1.6


Sumber : -




Deskripsi :Use case ini mendeskripsikan return barang yang dilakukan oleh Supervisor ke dalam sistem.

4.4.1.7 Persyaratan Bisnis Pencarian Barang



Nama Use Case : Pencarian barang Tipe Use Case

ID Use Case : 1.7


Sumber : -

Pelaku Bisnis Utama : Pembeli



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



Nama Use Case :Look up Data Penerimaan Barang

Tipe Use Case

ID Use Case : 1.8


Sumber : -

Pelaku Bisnis Utama : Supervisor, Pimpinan



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



Nama Use Case :Look up Data Penjualan Barang

Tipe Use Case

ID Use Case : 1.9


Sumber : -




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



Nama Use Case :Look up Data Persediaan Barang

Tipe Use Case

ID Use Case : 1.10


Sumber : -




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



Nama Use Case :Look up Data Pesanan Barang

Tipe Use Case

ID Use Case : 1.11


Sumber : -




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



Nama Use Case : Look up Data Return BarangTipe Use Case

ID Use Case : 1.12


Sumber : -




Deskripsi :Usecase ini mendeskripsikan proses look up data return barang berdasarkan tgtlreturn dalam sistem

4.4.1.13 Persyaratan Bisnis Update Data Penerimaan Barang



Nama Use Case :Update Data Penerimaan Barang

Tipe Use Case

ID Use Case : 1.13


Sumber : -




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



Nama Use Case : Update Data Pesanan Barang Tipe Use Case

ID Use Case : 1.14


Sumber : -




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



Nama Use Case : Update Data Return Barang Tipe Use Case

ID Use Case : 1.15


Sumber : -




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



Nama Use Case : Cetak laporan Tipe Use Case

ID Use Case : 1.16


Sumber : -




Deskripsi :Usecase inimendeskripsikan pencetakan laporan yang telah dikelola sebelumnya dalam sistem.

4.4.1.17 Persyaratan Bisnis Cetak Struck Pembayaran



Nama Use Case : Cetak Struck PembayaranTipe Use Case

ID Use Case : 1.17


Sumber : -




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


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


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


Nama Use Case : Input Barang Tipe Use Case



Sumber :




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 :


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.


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


Nama Use Case : Input Penerimaan BarangTipe Use Case



Sumber :




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 .



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 :



Kesimpulan :Usecase ini menyimpulkan bagaimana langkah penerimaan barang oleh admin gudang.


Aturan Bisnis :User sudah menyiapkan data penerimaan barang yang valid.


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


Nama Use Case : Penjualan Barang Tipe Use Case



Sumber :




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.


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 :


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.


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





Sumber :




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.



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 :


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.


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





Sumber :




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.


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 :



Kesimpulan :Usecase ini menyimpulkan bagaimana langkah input data return barang oleh Supervisor.


Aturan Bisnis : User sudah menyiapkan data return barang yang valid.


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





Sumber :




Deskripsi : Use case ini mendeskripsikan kejadian seorang user yaitu

untuk pencarian barang .

Prakondisi : -

Pemicu : Use case ini dimulai saat user mencari barang



Langkah 1 :

User menginputkan data barang yang akan dicari

Langkah 2 :

Sistem merespon dengan menampilkan informasi barang yang dicari user

Bidang Alternatif :


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 : -


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


Nama Use Case : Look up data barang masukTipe Use Case



Sumber :




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.



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.


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


Nama Use Case : Look up data penjualan barangTipe Use Case



Sumber :





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.


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.


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



Nama Use Case : Look up Persediaan barangTipe Use Case



Sumber :




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.



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 :


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.


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



Nama Use Case : Look up Pesanan barangTipe Use Case



Sumber :




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.



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 .


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.


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



Nama Use Case : Look up return barangTipe Use Case



Sumber :




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.


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 :


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.


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



Nama Use Case : Update penerimaan barang Tipe Use Case



Sumber :




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.



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 :


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.


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



Nama Use Case : Update Pesanan barang Tipe Use Case



Sumber :




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.



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.


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.




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



Nama Use Case : Update Return barang Tipe Use Case



Sumber :




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.


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 :


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.




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









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.



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 :


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.


Supervisor hanya mencetak laporan.

Asumsi : Hanya Supervisor yang dapat mencetak laporan.

Masalah Terbuka : -

4.4.2.17 Analisis Sistem Cetak Struck Pembayaran



Nama Use Case : Cetak Struk PembayaranTipe Use Case


Prioritas : Sedang Analisis Sistem :

Sumber :




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.



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.


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.


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





Prioritas : Tinggi Desain Sistem :

Sumber :

Pelaku Bisnis Utama : Supervisor, Admin Gudang, Pimpinan, Kasir




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.


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 :


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.


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



Nama Use Case : Input barang Tipe Use Case



Sumber :



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 .


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 :


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.


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



Nama Use Case : Input Penerimaan barang Tipe Use Case


Prioritas : TinggiDesain Sistem :

Sumber :



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 .


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 :


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



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



Nama Use Case : Penjualan barang Tipe Use Case



Sumber :




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.



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.


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






Sumber :




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.


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 :


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


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





Sumber :



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.


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 :


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






Sumber :




Deskripsi :Use case ini mendeskripsikan kejadian seorang user yaitu untuk pencarian barang .

Prakondisi : -

Pemicu : Use case ini dimulai saat user pencarian barang.



Langkah 1 :

User menginputkan :

Kategori(TextBox), dan nama Barang(TextBox).

Langkah 2 :

Sistem merespon dengan menampilkan informasi barang yang dicari(Form 8).

Bidang Alternatif :


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 : -


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



Nama Use Case :Look up data penerimaan barang

Tipe Use Case



Sumber :




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.



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 :


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.


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



Nama Use Case : Look up data penjualan barangTipe Use Case



Sumber :





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.


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 :


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



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



Nama Use Case : Look up Persediaan barangTipe Use Case



Sumber :




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.



Langkah 1 :

User klik data barang persediaan.

Langkah 3 :

User memasukan stockbarang (TextBox).

Langkah 4 :


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 :


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



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



Nama Use Case : Look up Pesanan barangTipe Use Case



Sumber :




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.



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 :


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



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



Nama Use Case : Look up return barang Tipe Use Case



Sumber :




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.



Langkah 1 :

User klik data Return barang.

Langkah 3 :

Usermemasukan tglreturn(DateTimePicker) .

Langkah 5 :


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).


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



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



Nama Use Case :Update data Penerimaan barang

Tipe Use Case



Sumber :




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.


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 :


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.




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



Nama Use Case : Update data Pesanan barang Tipe Use Case



Sumber :




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.



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 :


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.




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



Nama Use Case : Update data Return barang Tipe Use Case



Sumber :




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.


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 :


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.




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









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.



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 :


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



Nama Use Case : Cetak Struk PembayaranTipe Use Case


Prioritas : SedangDesain Sistem :

Sumber :




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.



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 :


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.


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


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


1 NoPenerimaan Char 10 Primary Key / Not Null

2 KdPegawai Char 10

3 TglPenerimaan Date -

4.7.3.4 Tabel Detail PenerimaanBarang


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


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


1 Nopesan Char 10 Primary Key / Not Null

2 Kdpegawai Char 10

3 Tglpesan Date -

4.7.3.7 TabelDetailPesananBarang


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


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


1 KdKategori Char 10 Primary Key / Not Null

2 NamaKategori Char 10

4.7.3.11 Tabel Penjualan


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