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 Penerimaan
Barang ......................................................................... 51
4.4.1.9 Persyaratan Bisnis Look Up Data Penjualan Barang ..52
4.4.1.10 Persyaratan Bisnis Look Up Data Persediaan
Barang ......................................................................... 52
4.4.1.11 Persyaratan Bisnis Look Up Data Pesanan Barang ... 53
4.4.1.12 Persyaratan Bisnis Look Up Data Return Barang....... 53
4.4.1.13 Persyaratan Bisnis Update Data Penerimaan Barang . 54
4.4.1.14 Persyaratan Bisnis Update Data Pesanan Barang ....... 54
4.4.1.15 Persyaratan Bisnis Update Data Return Barang ......... 55
4.4.1.16 Persyaratan Bisnis Cetak Laporan .............................. 55
4.4.1.17 Persyaratan Bisnis Cetak Struck Pembayaran............. 56
4.4.2 Analisa Sistem......................................................................... 56
4.4.2.1 Analisa Sistem Login ................................................. 56
4.4.2.2 Analisa Sistem Input Data Barang ...............................
4.4.2.3 Analisa Sistem Input Data Penerimaan Barang ........... 57
4.4.2.4 Analisa Sistem Penjualan Barang ................................ 59
4.4.2.5 Analisa Sistem Pesanan Barang ................................. 60
4.4.2.6 Analisa Sistem Return Barang ..................................... 61
4.4.2.7 Analisa Sistem Cek Harga ........................................ 63
4.4.2.8 Analisa Sistem Look Up Data Penerimaan Barang ..... 64
4.4.2.9 Analisa Sistem Look Up Data Penjualan Barang ...... 65
4.4.2.10 Analisa Sistem Look Up Data Persediaan Barang ..... 66
4.4.2.11 Analisa Sistem Look Up Data Pesanan Barang ......... 67

4.4.2.12 Analisa Sistem Look Up Return Barang .................... 69
4.4.2.13 Analisa Sistem Update Data Penerimaan Barang ........ 70
4.4.2.14 Analisa Sistem Update Data Pesanan Barang ............ 71
4.4.2.15 Analisa Sistem Update Data Return Barang................ 72
4.4.2.16 Analisa Sistem Cetak Laporan .................................... 73
4.4.2.17 Analisa Sistem Cetak Struk Pembayaran ................... 74
4.4.3 Desain Sistem .......................................................................... 56
4.4.3.1 Desain Sistem Login ....................................................... 56
4.4.3.2 Desain Sistem Input Data Barang ....................................
4.4.3.3 Desain Sistem Input Data Penerimaan Barang ................ 57
4.4.3.4 Desain Sistem Penjualan Barang...................................... 59
4.4.3.5 Desain Sistem Pesanan Barang ...................................... 60
4.4.3.6 Desain Sistem Return Barang .......................................... 61
4.4.3.7 Desain Sistem Cek Harga .............................................. 63
4.4.3.8 Desain Sistem Look Up Data Penerimaan Barang........... 64
4.4.3.9 Desain Sistem Look Up Data Penjualan Barang ............ 65
4.4.3.10 Desain Sistem Look Up Data Persediaan Barang .......... 66
4.4.3.11 Desain Sistem Look Up Data Pesanan Barang ............... 67
4.4.3.12 Desain Sistem Look Up Return Barang ......................... 69
4.4.3.13 Desain Sistem Update Data Penerimaan Barang ............. 70
4.4.3.14 Desain Sistem Update Data Pesanan Barang ................. 71
4.4.3.15 Desain Sistem Update Data Return Barang ..................... 72
4.4.3.16 Desain Sistem Cetak Laporan .......................................... 73
4.4.3.17 Desain Sistem Cetak Struk Pembayaran ........................ 74

4.5 Diagram Ketergantungan Use Case.................................................... 96
4.5.1 Inheritance ......................................................................... 96
4.5. 2 Extension .......................................................................... 96
4.5.2 Depends On ...................................................................... 99
4.6 Use Case Diagram (Diagram Use Case) ............................................ 101
4.7 Rancangan Database ........................................................................... 102
4.7.1 Entity Relationship Diagram (ERD) ..................................... 103
4.7.2 Relasi Antar Tabel ................................................................. 124
4.7.3 Spesifikasi File ........................................................................ 124
4.7.3.1 Tabel Barang.................................................................... 124
4.7.3.2 Tabel Pegawai ................................................................. 124
4.7.3.3 Tabel Penerimaan Barang ............................................... 124
4.7.3.4 Tabel Detail Penerimaan Barang .................................... 126
4.7.3.5 Tabel Penjualan Barang ................................................. 126
4.7.3.6 Tabel Detail Penjualan Barang ....................................... 126
4.7.3.7 Tabel Pesanan Barang..................................................... 126
4.7.3.8 Tabel Persediaan Barang ............................................... 127
4.7.3.9 Tabel Return Barang........................................................ 127
4.7.4 Diagram Kelas ........................................................................ 128
4.8 Activity Diagram (Diagram Aktivitas) ................................................ 129
4.8.1 Activity Login ......................................................................... 129
4.8.2 Activity Barang .......................................................................
4.8.3 Activity Input Data Penerimaan Barang ................................ 129
4.8.4 Activity Penjualan Barang .................................................... 130

4.8.5 Activity Pesanan Barang ....................................................... 130
4.8.6 Activity Return Barang ........................................................... 131
4.8.7 Activity Cek Harga ................................................................. 131
4.8.8 Activity Look Up Data Penerimaan Barang........................... 133
4.8.9 Activity Look Up Data Penjualan Barang ............................. 134
4.8.10 Activity Look Up Data Persediaan Barang ............................ 134
4.8.11 Activity Look Up Data Pesanan Barang ............................... 135
4.8.12 Activity Look Up Data Return Barang ................................... 135
4.8.13 Activity Update Data Penerimaan Barang ............................. 137
4.8.14 Activity Update Data Pesanan Barang................................... 137
4.8.15 Activity Update Data Return Barang ..................................... 138
4.8.16 Activity Cetak Laporan .......................................................... 139
4.8.17 Activity Cetak Struk Pembayaran ......................................... 140
4.9 Sequence Diagram .............................................................................. 141
4.10 Deployment Diagram.......................................................................... 153
4.11 Rancangan User Interface.................................................................... 154
BAB V. PENUTUP
5.1.Kesimpulan ............................................................................................... 137
5.2.Saran........................................................................................................... 138
DAFTAR PUSTAKA

BAB I
PENDAHULUAN
1.1 Latar Belakang Masalah
Perkembangan teknologi informasi saat ini sangatlah cepat, hal ini diikuti
dengan perkembangan disegala hal. Dengan adanya perkembangan teknologi, maka
penyebaran informasi sangatlah cepat dan mudah. Untuk memenuhi kebutuhan
informasi, memerlukan pengolahan yang sistematis dengan cara membentuk suatu
sistem informasi. Sistem persediaan barang sangat dibutuhkan oleh perusahaan,
karena dengan sistem tersebut perusahaan dapat mendukung operasional usaha.
Kegiatan pengelolaan barang dari tahun ke tahun terus berlangsung.
Pengelolaan ini bukan hanya melibatkan barang-barang dan aset lama saja tetapi
juga barang-barang dan aset yang baru sehingga dengan demikian dari tahun ke
tahun jumlah barang ini bukannya berkurang bahkan terus bertambah. Dengan
bertambahnya jumlah barang-barang tersebut, tentunya mendatangkan kesulitan
tersendiri dalam pengelolaannya. Agar pelaksanaan penyimpanan barang dalam
gudang dapat terkelola serta tertata dengan baik, maka perlu dikembangkan suatu
aplikasi berupa Sistem Informasi Inventori. Karena bila dengan cara biasa (manual)
seperti sekarang, cukup menyulitkan dalam hal pengarsipan dan penelusuran data
barang.

Sistem Informasi Inventori ini akan menampung semua data dan informasi
tentang barang-barang tersebut. Data dan informasi ini nantinya akan terakumulasi
dan tersimpan (diarsipkan) secara terpusat pada suatu database. Dengan terpusatnya
data dan informasi ini, maka jelas akan mempermudah pengelolaan barang.
Pencarian data dan status barang akan lebih cepat, mudah, dan efisien.
Sistem inventori Barang pada Salemba Toko Buku masih menggunakan
manual, menggunakan kertas formulir stock barang. Dengan proses
pengolahan data yang masih manual ini seringkali terjadi penumpukan data
(redundancy), sehingga informasi akhir stock/persediaan barang yang dihasilkan
terkadang tidak sesuai dengan stock fisik yang ada digudang. Dari permasalahan
tersebut peneliti mengambil judul ”Perancangan Sistem Informasi Inventori
Pada Salemba Toko Buku”
1.2 Tujuan
Tujuan dari Perancangan Sistem Informasi ini adalah untuk
membangun atau merancang sistem informasi inventori dengan alur bisnis
yang dibutuhkan.
1.3 Sasaran
Ada pun sasaran yang akan dicapai pada pengembangan ini adalah
terbentuknya rancangan sistem informasi Inventori pada Salemba Toko Buku.

1.4 Manfaat
1. Mahasiswa mampu memahami dan menganalisis faktor-faktor yang
mempengaruhi suatu sistem informasi.
2. Menerapkan ilmu- ilmu yang diperoleh selama kuliah.
3. Membandingkan teori-teori yang didapatkan di perkuliahan dengan
masalah yang sebenarnya di lapangan.
1.5 Batasan Masalah
Sistem Inventori ini adalah suatu aplikasi yang meliputi input, proses,
output dimana data yang diolah merupakan data seluruh perlengkapan yang
ada di Salemba Toko Buku. Sistem Inventori ini akan memberikan informasi
tentang nama barang, jumlah barang, keadaan barang dan beberapa informasi
yang terkait dengan barang, serta pembuatan laporan, yaitu laporan
peneriman barang, laporan penjualan barang, laporan pesanan barang, laporan
persediaan barang, dan laporan return barang.
Berdasarkan identifikasi dan batasan masalah tersebut, penulis
membatasi permasalahan menjadi :
a . Membahas mengenai stok persediaan barang
b. Membahas mengenai return barang yang rusak
c. Membahas mengenai penjualan barang
d. Membahas mengenai pesanan barang ke pusat

BAB II
LANDASAN TEORI
2.1 Teori Umum
2.1.1 Sistem Informasi
Sistem adalah Sekumpulan objek-objek yang saling berelasi dan
berinteraksi serta hubungan antar objek bisa dilihat sebagai satu kesatuan yang
dirancang untuk mencapai satu tujuan (Hanif Al Fatta, 2007 hal. 3).
Informasi adalah data yang telah diolah menjadi sebuah bentuk yang
berarti bagi penerimanya dan bermanfaat dalam pengambilan keputusan saat
ini atau mendatang (Hanif Al Fatta, 2007 hal. 9).
Sistem Informasi adalah pengaturan orang, data, proses, dan
information technologi (IT)/teknologi informasi yang berinteraksi untuk
mengumpulkan, memproses, menyimpan, dan menyediakan sebagai output
informasi yang diperlukan untuk mendukung sebuah organisasi (Jeffery
L.Whitten, 2004 hal 10).
Kualitas informasi terkadang dipakai untuk menyatakan informasi
yang baik. Kualitas informasi sering kali diukur berdasarkan:

a. Relevansi (kesesuaian);
b. Ketepatan waktu; dan
c. Keakurasian.
Dalam suatu sistem informasi terdapat komponen-komponen seperti:
a. Perangkat keras (hardware) yaitu perangkat keras komponen untuk
melengkapi kegiatan memasukkan data, memproses data, dan keluaran data.
b. Perangkat lunak (software) yaitu program dari instruksi yang
diberikan ke komputer.
c. Database yaitu kumpulan data dan informasi yang diorganisasikan
sedemikian rupa sehingga mudah diakses pengguna sistem informasi .
d. Jaringan komputer dan Komunikasi data yaitu komunikasi yang
menghubungkan antara pengguna dengan sistem komputer secara bersama-sama
ke dalam suatu jaringan kerja yang efektif.
e. Manusia yaitu personel dari sistem informasi, meliputi manager, analis,
programmer, dan operator, serta bertanggung jawab terhadap perawatan
sistem.
f. Prosedur yaitu tatacara yang meliputi strategi, kebijakan, metode, dan
peraturan-peraturan dalam menggunakan sistem informasi berbasis
komputer (Hanif Al Fatta, 2007 hal. 10).

Gambar 2.1. Komponen Sistem Informasi
2.1.2 Basis Data (Database)
Database adalah kumpulan file yang saling terkait. Kata
kuncinya adalah”Saling terkait”. Database tidak hanya kumpulan file.
Record pada setiap file harus memperbolehkan hubungan–hubungan
untuk menyimpan file-file lain (Jeffery L.Whitten, Hal 518).
Untuk mengelola basis data diperlukan perangkat lunak yang
disebut DBMS. DBMS adalah perangkat lunak sistem yang
memungkinkan pemakai membuat, memelihara, mengontrol dan
mengakses basisdata dengan cara yang praktis.
Perangkat lunak yang didesain untuk mengelola database
disebut DBMS (Database Management System). Contoh DBMS yang
ada di pasaran adalah Oracle,Microsoft SQL Server, MYSQL,
Informix, Progress 4GL, Firebird dan FileMaker. DBMS sering
digunakan oleh Database Adminisator (DBA) untuk membuat sistem
database. Secara lebih rinci DBMS merupakan kumpulan software

program yang sangat kompleks untuk mengontrol organisasi data dan
alat penyimpanan data di database. (Bambang Wahyudi, 2008 Hal 188).
2.1.2.1 Entity – RelationshipDiagram (Diagram E-R)
Model entity – Relationship (ER) pada awalnya
disampaikan oleh Peter di tahun 1976 sebagai suatu cara untuk
menyatukan jaringan dan menggambarkan relational database.
Singkatnya, model ER adalah sebuah model konseptual dari data
yang menggambarkan keadaan sebenarnya dari entities dan
relationship (Bambang Wahyudi, 2008 Hal 199).
Notasi-notasi simbolik di dalam Diagram E-R yang
digunakan adalah:
1. Entitas (entity), dilambangkan dengan persegi panjang (rectangle);
2. Relasi (relationship), dilambangkan dengan belah ketupat
(diamonds);
3. Atribut(attribute),dilambangkan dengan elips (ellipses atau ovals);
4. Garis penghubung (line links), dilambangkan dengan gais (lines).
(Bambang Wahyudi, 2008 Hal 199).
Entitas
Relasi
Atribut
Penghubung
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.
Pembeli Barang
2. Menentukan atribut-atribut key dari masing-masing himpunan
entitas.
No_kwitansi Kd_barang Nama_barang
Pembeli Barang
Kd_distr
Jenis_barang Satuan
Stock
Merek
Harga_satuan
3. Tentukan hubungan antara sepasang entitas menggunakan
relationship matriks.
No_kwitansi Jml_bayar
Kd_barang Nama_barang
Pembeli Barang
Kd_distr
Jenis_barang Satuan
Stock
Merek
Harga_satuan
Membeli
Tgl_beli
4. Tentukan kardinalitas (pemunculan suatu entitas di entitas
lainnya yang berhubungan).

No_kwitansi Jml_bayar
Kd_barang Nama_barang
M N
Pembeli Barang
Kd_distr
Jenis_barang Satuan
Stock
Merek
Harga_satuan
Membeli
Tgl_beli
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).

Club Member
Place New Member Order
Distribution Center
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.
Extension Use Case
Generate
Worehouse
Packing Order
Calculate order
subtotal & Sales
Tax
<<extend>>
<<extends>>
Place New Order
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.

<<Dependension>>
Input Data Barang
Masuk
Update data
barang
Data Barang
Cetak Laporan
persediaan
barang
<<Depend
ension>>
Dependensi
on>>
<<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
Place New Order
Submit Change of
Postal Address
Revisi Postal Address
<<User>>
<<User>>
Abstract Use case
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).
Pimpinan
Login
User
<<Inheritance>>
<<Inheritance>>
<<Inheritance>> <<Inheritance>>
Adm.Gudang Supervisor Kasir
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

ClsPegawai
-IdPegawai : Char
-NamaPegawai : Varchar
-Harga : Char
Tambah Pegawai
ClsPenerimaanBarang
-NoPenerimaan : Char
-Tglpenerimaanm : Date
-IdPegawai : Char
Tambah barang
Ubah data barang
ClsPenjualanBarang
-NoPenjualan : Char
-Tanggalpenjualan : Date
-IdPegawai : Char
Tambah Transaksi Penjualan
ClsPesanan Barang
-NoPesan : Char
-TglBarangpesan : Date
-KdBarang : Char
-QTYPesan : Char
Tambah Pesanan
Ubah Data Pesanan
ClsBarang
- KdBarang : Char
- Barcode : Char
- Nama Barang : Varchar
- Harga : Char
Tambah Barang
Return Barang
-NoReturn : Char
-TglReturn : Date
-Kdbarang : Char
-QTYPesan : Char
Tambah Return Barang
Ubah Return Barang
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.
User
Login
From Login Login Data User Menu Utama
Validasi user
Masuk ke Halaman Menu Utama
[Result]
Cek validasi
Validasi

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.
Admin
Gudang
Login
Sistem
Menampilakan pesan eror Login
Menampilakan Menampilakan pesan eror Login hal menu utama
Search data barang
Input tanggal awal dan akhir Lap. kembali
Klik Print Menampilkan informasi lap data barang masuk
Print Laporan
Exit
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).
LAN
Jalur Koneksi
Scanner Barcode
Server
Window
s Server
2008
MySQL
Client
Window
s 7
Microsof
t Visual
Studio
2010
Printer type
deskjet .

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
B1i. a ya Pengadaan
- Biaya PembeliRanp .7H.2/0W0. 000
-Jaringan Rp.250.000
Sub Total Biaya
Pengadaan
Rp.7.450.000
B2i. aya Persiapan Operasi
- Biaya pembeliRanp .4S./0W00 .000
- Biaya Biaya PReprs.9o0n0il.0 00

Sub Total Biaya
Persiapan Operasi
Rp.4.900.000
Tabel 3.2 Analisa Biaya dan Manfaat
B3i. aya 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 aRnpa.l3is.5 00.000
Sub Total Biaya Tahap
Analisis
Rp.15.500.000
Total KeseluruhanR p.27.850.000
B4i. aya Operasional &
Perawatan
- Biaya overhead
Rp.500.000 Rp. 600.000 Rp.700.000 Rp.800.000
-Biaya Perwatan H/W
Rp. 650.00R0p . 700.000 Rp. 780.000 Rp. 850.000
-Biaya Perawatan S/W
Rp. 550.000 Rp. 600.000 Rp. 650.000 Rp. 700.000
-Biaya Kontrak
Rp 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.000
Rp.5.700.000 Rp.6.400.000 Rp.7.130.000 Rp.7.850.000

Tabel Analisa Manfaat
No Deskripsi TAHUN 1 TAHUN 2 TAHUN 3 TAHUN 4
K1e. u ntungan 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
K2e. untunganTak 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.000
Total Manfaat Total Biaya Proceed
Tahun 1 Rp 22.500.000 Rp. 6.700.000 Rp. 15.800.000
Tahun 2 Rp. 24.800.000 Rp. 7.600.000 Rp. 17.280.000
Tahun 3 Rp. 28.200.000 Rp. 8.530.000 Rp. 19.670.000
Tahun 4 Rp. 32.800.000 Rp. 9.350.000 Rp. 23.450.000
Total Rp. 108R.0p0. 0 . 0 0302 .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 bulan
Jadi, Payback Periodnya adalah 1 tahun 8 bulan 18 hari.
b. Return of Investment (ROI)
푅푂퐼 = [ퟏ08.000.000− 59.958.000
59.958.000
] 푥 100%
48.042.000
59.958.000
푅푂퐼 = [
] 푥 100%
푅푂퐼 = [0,801]푥 100%
푅푂퐼 = 80,1%
ROI bernilai positif, maka sistem layak dikembangkan.
c. Net Present Value (NPV)
푁푃푉 = −푁푖푙푎푖 푃푟표푦푒푘 +
푃푟표푐푒푒푑 푡ℎ푛1
(1 + 푖)1 +
(1 + 푖)2 +
(1 + 푖) 3 +
(1 + 푖)4
푁푃푉 = −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 푁푃푉 =
−27.850.000 + 12.640.000 + 11.008.000 + 10.071.000 + 9.610.657
푁푃푉 = −27.850.000 + 43.329.657
푁푃푉 = 푅푝. 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.
푁푃푉 = −푁푖푙푎푖 푃푟표푦푒푘 +
(1 + 푖)1 +
(1 + 푖)2 +
(1 + 푖) 3 +
(1 + 푖)4
푁푃푉 = −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
푁푃푉 = −27.850.000 + 10.193.543 + 7.151.767 + 5.283.373 + 4.064.124
푁푃푉 = −27.850.000 + 26.692.807
푁푃푉 = −푅푝. 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
퐼푅푅 = [푖1 +
(푖2 − 푖1)푥 푁푃푉1
푁푃푉1 − 푁푃푉2
] %
퐼푅푅 = [25 +
(55 − 25) 푥 15.479.657
15.479.657 − (−115.719)
] %

퐼푅푅 = [25 +
30 푥 15.479.657
15595376
] %
퐼푅푅 = [25 +
464389710
15595376
] %
퐼푅푅 = [25 + 29,77]%
퐼푅푅 = 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
PerangkatLunak
PerangkatKeras (hardware)
(software)
- Processor intel core i3 Windows 7
-Mainboard
Microsoft Visual Studio
2010
-Harddisk 160 Gb
-Keyboard + Mouse
-Casing ATX 450w + 2FAN C P U
-LCD Monitor
c. Jaringan
Jaringan
d. Alat Bantu
1. Kabel UTP
2. Switch Dlink 10/100
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
Supervisor Pusat Kasir Pimpinan
Membuat
Surat
permintaan
barang
Mengirim
barang
Struck
Y Struk pembayaran
pembayaran
Tanda
tangan
lap
Membuat
data return
barang
Laporan Persediaan
barang
C
C
Lap.Penerimaan
barang
Penerimaan
Barang
Barang
Rusak ?
Kembali ke
pusat
Input barang
masuk
Lap.Penjualan
Barang
Cek barang
dengan barcode
Belanja Barang
Lap.Persediaan
barang
Lap.Penerimaan
barang
Admin gudang Customer
T
Membuat
laporan
Lap. Persediaan
barang
Lap. Pembelian
barang
Lap.Penjualan
Barang
Lap.Pesanan
barang
Lap.Return barang
Lap.Penjualan
barang
Lap.Pesanan barang
Lap.Return barang
Lap.Pesanan
barang
Lap.Return
barang
C
C
C
Gambar 3.10 Analisa Proses Sistem yang Berjalan

3.4 Analisa Proses Sistem Baru yang dikembangkan
Admin
Gudang
Pusat Kasir Pimpinan
Login Barcode
Y
Data Penerimaan
barang
Supervisor
Membayar
Struck
Pembayaran
Struck
Pembayaran
Tanda
tangan
Barang
Rusak ?
Input data
penerimaan
barang
Kembali
kan ke
pusat
T
Database
Cek harga
dengan barcode
dan pembayaran
Lap. Persediaan
barang
Customer
Lap. Persediaan
barang
Mengirim barang
Lap. Persediaan
barang
Lap. Persediaan
barang
Surat Pesanan
Barang
Menerima barang
Return Barang
C
C
C
C
Mesin
Marcode
C
Login
Melihat
Semua
Lap.barang
Data Pesanan
Barang
Data Return
Barang
Data
Penjualan
Barang
Lap.Penerimaan
barang
Lap.Penjualan
Barang
Lap.Pesanan
barang
Lap.Return barang
Lap.Penerimaan
barang
Lap.Penjualan
barang
Lap.Pesanan
barang
Lap.Retutn
Barang
Lap.Penerimaan
barang
Lap.Penjualan
barang
Lap.Pesanan
barang
Lap.Retutn
Barang
Lap.Penerimaan
barang
Lap.Penjualan
barang
Lap.Retutn
Barang
Lap.Pesanan
barang
Gambar 3.11 Analisa Proses Sistem yang Dikembangkan

3.5 Kontruksi Sistem yang dikembangkan
Swicth
Barcode
scanner
Barang
Server
Database
Kasir
Pimpinan
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
Data Pesanan barang
Data Return barang
Look Up Persediaan
Lap.Persediaan barang
Lap.Penerimaan barang
Sistem Informasi Inventori
Salemba Toko Buku
Lap.Return barang
Lap.Pesanan barang
Data Barang
Data Penerimaan barang Admin Gudang
Lap.Persediaan barang
Lap.Penjualan barang
Pembeli
Kasir
Supervisor
Pimpinan
Lap.Penerimaan barang
Struck Pembayaran
Lap.Penjualan barang
Lap.Return barang
Barcode
Informasi Buku
Cek Harga
Data Barang
Data Penjualan barang
Lap.Pesanan barang
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 Deskripsi
Pelaku yang
Berpartisipasi
Login
- Supervisor
- Admin Gudang
Use case ini mendeskripsikan kejadian pada saat user pertama
masuk kedalam sistem.
- Kasir
- Pimpinan
Input Barang
Use case ini mendeskripsikan proses penginputan barang baru
yang dilakukan oleh Admin gudang ke sistem
-Admin Gudang
Usecase ini mendeskripsikan proses penginputan data
penerimaan barang yang dilakukan oleh Admin Gudang ke
dalam sistem.
Input Penerimaan Barang
- Admin Gudang
Penjualan Barang
Usecase ini mendeskripsikan proses penjualan barang
menggunakan scanner barcode yang dilakukan oleh - kasir Kasir
ke
dalam sistem.
Pesanan Barang
Usecase ini mendeskripsikan proses penginputan pesanan barang
yang dilakukan oleh Supervisor ke dalam sistem.
- Supervisor
Return Barang
Usecase ini mendeskripsikan proses return barang yang
dilakukan oleh Supervisor ke dalam sistem.
- Supervisor
Pencarian Barang
Usecase ini mendeskipsikan proses pencarian barang yang
-Pembeli
dilakukan oleh pembeli ke dalam sistem.
Look up data Penerimaan
Barang
- Supervisor
Usecase ini mendeskripsikan proses look up data penerimaan
barang berdasarkan tglpenerimaan dalam sistem.
- Pimpinan
Look up data Penjualan
Barang
- Supervisor
Usecase ini mendeskripsikan proses look up data penjualan
barang berdasarkan tglpenjualan dalam sistem.
- Pimpinan
Look up data Persediaan
Barang.
- Supervisor
Usecase ini mendeskripsikan proses look up data persediaan
barang berdasarkan stock barang dalam sistem.
- Pimpinan
Look up data Pesanan
Barang.
- Supervisor
Usecase ini mendeskripsikan proses look up data pesanan
barang berdasarkan tglpesan dalam sistem.
- Pimpinan
Look up data Return
Barang.
- Supervisor
Usecase ini mendeskripsikan proses look up data Return barang
berdasarkan tglreturn dalam sistem.
- Pimpinan
Usecase ini mendeskripsikan proses update data yang terjadi
pada data penerimaan barang yang telah diinput sebelumnya
oleh Admin gudang kedalam sistem.
Update data Penerimaan
Barang
- Admin Gudang
Usecase ini mendeskripsikanproses update data yang terjadi
pada data pesanan barang yang telah diinput sebelumnya oleh
Supervisor kedalam sistem.
Update data Pesanan Barang
- Supervisor
Usecase ini mendeskripsikan proses update data yang terjadi
pada data return barang yang telah diinput sebelumnya oleh
Supervisor kedalam sistem.
Update data Return Barang
- Supervisor

Cetak Laporan
- Supervisor
Usecase ini mendeskripsikan pencetakan laporan yang telah
dikelola sebelumnya dalam sistem.
Usecase ini mendeskripsikan pencetakan Struck Pembayaran
yang telah dikelola sebelumnya dalam sistem.
Cetak Struck Pembayaran
- 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 :
barang baru yang dilakukan oleh Admin Gudang ke
dalam sistem.
4.1.1.3 Persyaratan Bisnis Input Penerimaan Barang
Nama Use Case : Input Penerimaan BarTanipge Use Case
ID Use Case : 1.3
Sumber : -
Deskripsi :
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 :
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 :
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 :
pesanan barang berdasarkan tglpesan dalam sistem.
4.4.1.12 Persyaratan Bisnis Look up Data Return Barang
Nama Use Case : Look up Data Return TBiaprea nUgs e 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 PesananT Biparea nUgs e Case
ID Use Case : 1.14
Sumber : -
Deskripsi :
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 BTaipraen Ug s e Case
ID Use Case : 1.15
Sumber : -
Deskripsi :
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 PembayTariapne 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
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 la in :
Deskripsi :
Use case ini mendeskripsikan kejadian pada saat user
pertama masuk kedalam sistem.

Prakondisi :
User telah memiliki user name dan passwordnya masing-masing
yang sudah secara otomatis sudah ada di ID Card.
Pemicu :
Use case ini dilakukan untuk memastikan bahwa sistem
hanya digunakan oleh user yang telah diberi hak akses
berdasarkan kepentingannya.
BidangKhasSuatu Event :
Kegiatan Pelaku Respons Sistem
Langkah 1 :
Langkah 2 :
User mengscankan IDCard yang
sudah ada username dan
password yang bertipe barcode
pada barcode Scanner.
Langkah 3 :
Sistem akan memproses dan
menampilkan menu utama yaitu
Menu Transaksi, Transaksi dan
menu Laporan .
jika validasi IDCard dimasukkan
adalah valid.
Apabila pilihan user mengklik
tombol Cancel.
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 .
Langkah 1 :
Langkah 2 :
User Pilih menu Master dan
kliksub menu barang.
Langkah 3:
Sistem merespon dengan
menampilkan form inputan
barang.
Langkah 4 :
User Masukkan data barang
baru kedalam field yang sudah
disediakan dengan benar.
Langkah 5 :
menyimpan data barang baru yang
telah diinputkan tersebut kedalam
database sistem dan menampilkan
kembali informasi yang telah
terupdate kedalam Display
Informasi data.
Cek semua data barang yang
sudah dimasukkan, bila tidak ada
perubahan maka user
melanjutkan dengan klik
tombol[Simpan].
Langkah 6:
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 input
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.
Implementasi :
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 BaranTgip e Use Case
Sumber :
Deskripsi :
menambah/input data penerimaan barang.
Prakondisi :
User telah memiliki data penerimaan barang yang akan
diinputkan.
Pemicu :
data barang untuk menambah/input data penerimaan
barang .
Langkah 1 :
Langkah 2 :
User Pilih menu Transaksi dan
kliksub menu penerimaan
barang.
Langkah 3:
penerimaan barang.
Langkah 4 :
User Masukkan data
penerimaan barang kedalam
field yang sudah disediakan
dengan benar.
Langkah 5 :
menyimpan data penerimaan
barang yang telah diinputkan
tersebut kedalam database sistem
dan menampilkan kembali
informasi yang telah terupdate
kedalam Display Informasi data.
Cek semua data barang masuk
yang sudah dimasukkan, bila
tidak ada perubahan maka user
Langkah 6:

tombol[Simpan].
menutup From Penerimaan
Barang dan menampilkan Form
utama.
Bidang Alternatif :
Kesimpulan :
Usecase ini menyimpulkan bagaimana langkah input
penerimaan barang oleh admin gudang.
Postkondisi :
Aturan Bisnis :
User sudah menyiapkan data penerimaan barang yang
valid.
Implementasi :
Admin Gudang hanya menginput penerimaan barang.
Asumsi :
Hanya Admin gudang yang dapat melakukan penginputan
penerimaan barang.
Masalah Terbuka : -
4.4.2.4 Analisis Sistem Penjualan Barang
Nama Use Case : Penjualan Barang Tipe Use Case
Sumber :
Deskripsi :
menambah data penjualan barang dengan mengescan
barcode barang.
Prakondisi :
User telah memiliki data penjualan barang yang akan
diinputkan menggunakan scanner barcode.
Pemicu :
data penerimaan barang untuk menambah data penjualan

barang.
Langkah 1 :
Langkah 2:
Pilih menu Transaksi dan klik
sub menu penjualan barang.
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 :
Langkah 5 :
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.
Cek semua data penjualan
barang yang sudah dimasukkan,
bila tidak ada perubahan maka
user melanjutkan dengan klik
tombol[Bayar].
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.
Implementasi :
Asumsi :
Hanya Kasir yang dapat melakukan penginputan data
transaksi penjualan barang.
Masalah Terbuka : -

4.4.2.5 Analisis Sistem Pesanan Barang
Nama Use Case : Pesanan Barang Tipe Use Case
Sumber :
Deskripsi :
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 :
Langkah 2 :
kliksub menu input data pesanan
barang.
Langkah 3:
menampilkan form input data
pesanan barang.
Langkah 4 :
User Masukkan data pesanan
barang kedalam field yang
Langkah 5 :
menyimpan data pesanan barang
yang telah diinputkan tersebut
kedalam database sistem dan
menampilkan kembali informasi
yang telah terupdate kedalam
Display Informasi data.
Cek semua data barang pesanan
tombol[Simpan].
Langkah 6:
menutup From input pesanan Data
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.
Implementasi :
Supervisor hanya menginput data Pesanan Barang.
Asumsi :
Hanya Supervisor yang dapat melakukan penginputan
dataPesanan barang .
Masalah Terbuka : -
4.4.2.6 Analisis Sistem Return Barang
Nama Use Case : Return Barang Tipe Use Case
Sumber :
Deskripsi :
Return Barang.
Prakondisi :
User telah memiliki data return barang yang akan
diinputkan.
Pemicu :
data return barang untuk menambah, merubah, dan
menghapus data barang.
Langkah 1 :
Langkah 2 :
kliksub menu input data return
menampilkan form input data

barang.
Langkah 3:
return barang.
Langkah 4 :
User Masukkan data return
barang kedalam field yang
Langkah 5 :
menyimpan data return barang
yang telah diinputkan tersebut
kedalam database sistem dan
menampilkan kembali informasi
yang telah terupdate kedalam
Display Informasi data.
Cek semua data return barang
tombol[Simpan].
Langkah 6:
menutup From input Data return
utama.
Bidang Alternatif :
Kesimpulan :
Usecase ini menyimpulkan bagaimana langkah input data
return barang oleh Supervisor.
Postkondisi :
Aturan Bisnis : User sudah menyiapkan data return barang yang valid.
Supervisor hanya menginput data return barang.
Implementasi :
Asumsi :
Hanya Supervisor yang dapat melakukan penginputan data
return barang.
Masalah Terbuka : -
4.4.2.7 Analisis Sistem Pencarian Baranng
Nama Use Case : Pencarian barang Tipe Use Case

Sumber :
Pelaku Bisnis Utama : Pembeli
Deskripsi :
untuk pencarian barang .
Prakondisi : -
Pemicu : Use case ini dimulai saat user mencari barang
Langkah 1 :
Langkah 2 :
User menginputkan data barang
yang akan dicari
menampilkan informasi barang
yang dicari user
Bidang Alternatif :
Alternatif Langkah 2 :
2.1 Jika sistem tidak merespon maka pencarian barang
gagal karena barang yang dicari tidak tersedia dan
kembali ke langkah 1.
Kesimpulan :
Use-case ini menyimpulkan bagaimana langkah pencarian
barang oleh Pembeli.
Postkondisi :
Pencarian barang sudah dicari maka sistem akan
menampilkan kembali form pencarian barang
Aturan Bisnis : -
pembeli hanya menginputkan data barang yang akan
dicari.
Implementasi :
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 maTsipuek Use Case
Sumber :
Stakeholder yang berminat lain :
Deskripsi :
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 :
Langkah 2 :
User Pilih menu View dan klik
submenu data penerimaan
barang
Langkah 3:
menampilkan form data barang
masuk.
Langkah 4 :
User memasukan tglpenerimaan
.
Sistem akan secara otomatis
mencari data penerimaan barang
yang telah tersimpan.

Langkah 5 :
Langkah 6:
User mengklik data barang yang
dicari.
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 up data
penerimaan barang.
Postkondisi : Data penerimaan barang yang dicari akan ditampilkan.
Aturan Bisnis :
Tglpenerimaan yang dimasukan harus sesuai dengan
format yang telah ditentukan oleh aplikasi.
Implementasi :
User hanya look up data penerimaan barang.
Asumsi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
look up data penerimaan barang.
Masalah Terbuka : -
4.4.2.9 Analisis Sistem Look up Data Penjualan Barang
Nama Use Case : Look up data penjualanT bipaera Ungse Case
Sumber :

Deskripsi :
penjualan barang berdasarkan tglpenjualan dalam sistem.
Prakondisi :
Memastikan apakah data penjualan barang yang akan di
Pemicu : Usecase ini diinisiasi saat look up penjualan barang.
Langkah 1 :
Langkah 2 :
User Pilih menu View barang
dan kliksubmenu data Penjualan
barang.
Langkah 3:
menampilkan form data barang
keluar.
Langkah 4 :
User memasukan tglpenjualan.
Langkah 5 :
mencari data penjualan barang
yang telah tersimpan.
Langkah 6:
User mengklik data penjualan
barang yang dicari.
penjualan barang yang di cari.
Bidang Alternatif :
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 :
penjualan barang.
Postkondisi : Data penjualan barang yang dicari akan ditampilkan.
Aturan Bisnis :
tglpenjualan yang dimasukan harus sesuai dengan format
yang telah ditentukan oleh aplikasi.
Implementasi :
User hanya look up data penjualan barang.
Asumsi :
look up data penjualan barang.
Masalah Terbuka : -

4.4.2.10 Analisis Sistem Look up Data Persediaan Barang
Nama Use Case : Look up Persediaan barTainpge 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
Pemicu : Usecase ini diinisiasi saat look persediaan barang.
Langkah 1 :
Langkah 2 :
dan kliksub menu data
PersediaanBarang .
Langkah 3:
menampilkan form data
Persediaan barang .
Langkah 4 :
User memasukan stock minimal
barang .
Langkah 5 :
mencari data stock minimal
barang yang telah yang tersimpan.
Langkah 6:
User mengklik data stock
persediaan barang .
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 :
persediaan barang.
Postkondisi : Data persediaan barang yang dicari akan ditampilkan.
Aturan Bisnis :
Stock barang yang dimasukan harus sesuai dengan format
yang telah ditentukan oleh aplikasi.
Implementasi :
User hanya look up data persediaan barang.
Asumsi :
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 baranTgi pe 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
Pemicu : Usecase ini diinisiasi saat look up Pesanan barang.
Langkah 1 :
Langkah 2 :
dan kliksub menu data Pesanan
barang .
menampilkan form data Pesanan
barang .

Langkah 3:
Langkah 4 :
User memasukan tglpesan .
Langkah 5 :
mencari data Pesanan barang yang
telah yang tersimpan.
Langkah 6:
User mengklik data Pesanan
Barang.
pesanan barang .
Bidang Alternatif :
3.1 jika tglpesan yang dimasukan tidak sesuai dengan
tglpesan yang dimasukan tidak ada dalam database dan
tidak dapat ditampilkan.
Kesimpulan :
Pesanan barang.
Postkondisi : Data Pesanan barang yang dicari akan ditampilkan.
Aturan Bisnis :
tglpesan yang dimasukan harus sesuai dengan format yang
telah ditentukan oleh aplikasi.
Implementasi :
User hanya look up data Pesanan barang.
Asumsi :
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 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 :
Langkah 2 :
dan kliksub menu data return
Barang.
Langkah 3:
menampilkan form data return
barang.
Langkah 4 :
User memasukan tglreturn.
Langkah 5 :
mencari data return barang yang
telah tersimpan.
Langkah 6:
User mengklik data return
barang yang dicari.
return barang yang di cari.
Bidang Alternatif :
3.1 jika tglreturn yang dimasukan tidak sesuai dengan
tglreturn yang dimasukan tidak ada dalam database dan
tidak dapat ditampilkan.
Kesimpulan :
return barang.
Postkondisi : Data return barang yang dicari akan ditampilkan.
Aturan Bisnis :
tglreturn yang dimasukan harus sesuai dengan format yang
telah ditentukan oleh aplikasi.
Implementasi :
User hanya look up data return barang.
Asumsi :
look up data return barang.
Masalah Terbuka : -

4.4.2.13 Analisis Sistem Update data Penerimaan Barang
Nama Use Case : Update penerimaan baTraipneg U se 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:
Langkah 2 :
kliksub menu penerimaan
barang.
Langkah 4 :
menampilkan form data penerimaan
barang
Langkah 6:
User mengubah data barang
yang akan diubah.
Langkah 5 :
Data penerimaan barang yang
datanya telah di ubah akan tersimpan
kembali kedalam database.
User mengklik tombol update.
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.
Implementasi :
Admin Gudang hanya mengubah databarang masuk.
Asumsi :
Hanya admin gudang yang dapat melakukan update/edit
data barang masuk.
Masalah Terbuka : -
4.4.2.14 Analisis Sistem Update data Pesanan Barang
Nama Use Case : Update Pesanan baranTgip e 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
Pemicu :
Usecase ini diinisiasi saat Supervisor akan melakukan
proses update edit/ data pesanan barang yang telah diinput
Langkah 1:
Langkah 2 :
User Pilih menu Transaksi
barang dan kliksub menu data

pesanan barang.
Langkah 4 :
menampilkan form pesanan barang.
Langkah 6:
User mengubah data pesanan
barang yang akan diubah.
Langkah 5 :
Data pesanan barang yang datanya
telah di ubah akan tersimpan kembali
kedalam database.
User mengklik tombol update.
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 :
data pesanan barang yang dilakukan oleh Supervisor.
Postkondisi :
Hasil proses update data pesanan barang akan dimasukan
kedalam database.
Aturan Bisnis :
oleh aplikasi.
Implementasi :
Supervisor hanya mengubah data pesanan barang.
Asumsi :
Hanya Supervisor yang dapat melakukan update/edit data
pesanan barang.
Masalah Terbuka : -
4.4.2.15 Analisis Sistem Update data Return Barang
Nama Use Case : Update Return baranTg ip e 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
Pemicu :
Usecase ini diinisiasi saat Supervisor akan melakukan
proses update edit/ data return barang yang telah diinput
Langkah 1:
User Pilih menu Transaksi
barang dan kliksub menu data
return barang.
Langkah 4 :
User mengubah data return
barang yang akan diubah.
Langkah 5 :
User mengklik
tombol update.
Langkah 2 :
menampilkan form return barang.
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 :
data return barang yang dilakukan oleh Supervisor.
Postkondisi :
Hasil proses update data return barang akan dimasukan
kedalam database.
Aturan Bisnis :
oleh aplikasi.
Implementasi :
Supervisor hanya mengubah data return barang.
Asumsi :
Hanya Supervisor yang dapat melakukan update/edit data
return barang.
Masalah Terbuka : -

4.4.2.16 Analisis Sistem Cetak laporan
Nama Use Case : Cetak laporan Tipe Use Case
Deskripsi :
Usecase ini mendeskripsikan pencetakan laporan yang
Prakondisi : Data atau laporan yang akan dicetak harus tersedia.
Pemicu : Usecase ini diinisiasi saat proses pencetakan laporan.
Langkah 1:
Langkah 2 :
User mengklik menu laporan dan
pilih dan klik jenis laporan yang
dipilih.
Langkah 3:
menampilakan form laporan yang
dipilih.
Langkah 7 :
User mengatur tanggal laporan
yang akan di cetak.
Sistem akan merespon perintah
dan printer akan mencetak
laporan.

Langkah 6 :
User mengklik tombol view.
Langkah 8 :
User mengklik tombol
cetak/print.
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.
Implementasi :
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 PembayaraTni pe Use Case
Prioritas : Sedang Analisis Sistem : 
Sumber :
Deskripsi :
Usecase inimendeskripsikan pencetakan struk biaya yang

Prakondisi : Pembeli membayar kepada Kasir.
Pemicu : Usecase ini diinisiasi saat proses pencetakan struk biaya.
Langkah 1:
Langkah 2:
User mengklik tombol view.
Langkah 3 :
menampilkan data transaksi
pembayaran.
Langkah 4 :
User mengklik tombol
cetak/print.
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.
Implementasi :
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

Perancangan sistem informasi inventori

Perancangan sistem informasi inventori

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Perancangan sistem informasi inventori

Similar to Perancangan sistem informasi inventori (20)

Recently uploaded

Recently uploaded (20)

Perancangan sistem informasi inventori