• Tidak ada hasil yang ditemukan

Aplikasi transaksi pembelian dan penjualan berbasis intranet : studi kasus Toko ``Ateng``, Cirebon - USD Repository

N/A
N/A
Protected

Academic year: 2019

Membagikan "Aplikasi transaksi pembelian dan penjualan berbasis intranet : studi kasus Toko ``Ateng``, Cirebon - USD Repository"

Copied!
140
0
0

Teks penuh

(1)

i

APLIKASI TRANSAKSI PEMBELIAN DAN PENJUALAN BERBASIS INTRANET (STUDI KASUS: TOKO “ATENG”, CIREBON)

Skripsi

Diajukan untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Komputer

Program Studi Teknik Informatika

Oleh:

UNTUNG SUSANTO NIM: 05 5314 131

PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS SANATA DHARMA YOGYAKARTA

(2)

ii

INTRANET-BASED APPLICATION OF PURCHASING AND SELLING TRANSACTION

(A case study at TOKO “ATENG”, CIREBON)

A THESIS

Presented as Partial Fulfillment of the Requirements

To Obtain

Sarjana Komputer

Degree

In Informatics Engineering Department

By:

UNTUNG SUSANTO NIM: 05 5314 131

INFORMATICS ENGINEERING STUDY PROGRAM INFORMATICS ENGINEERING DEPARTMENT

FACULTY OF SCIENCE AND TECHNOLOGY SANATA DHARMA UNIVERSITY

(3)
(4)
(5)
(6)
(7)

vii ABSTRAKSI

Toko “ATENG” adalah sebuah toko yang menjual barang-barang kebutuhan

sehari-hari seperti mie instan, sabun mandi, shampo, kopi, susu dan lain-lain. Saat ini pencatatan dan penyimpanan data-data transaksi pembelian, penjualan serta me-monitoring stok barang pada toko “ATENG” masih dilakukan secara manual. Hal tersebut akan memakan waktu yang cukup lama dalam mengelola data. Pekerjaan empat orang pegawai sebagai pengelola data transaksi dan stok barang dirasa sangat berat, maka itu dibutuhkan sistem aplikasi komputer yang dapat melakukan proses transaksi dan pencatatan lebih efisien.

(8)

viii ABSTRACT

Toko Ateng is a store sells items of daily needs such as instant noodles, soap, shampoo, coffee, milk and others. Currently, recording and storing transaction data of purchasing, selling, and inventory monitoring of Toko Ateng is still done manually. It will take considerable time in managing data. Work of four employees as the managers of transaction and inventory data is felt very heavy, so it would be needed a computer application system that able to perform transaction processing and recording more efficient.

(9)

ix

KATA PENGANTAR

Puji Syukur kepada Tuhan Yang Maha Esa atas rahmat dan karunia-NYA sehingga penulis dapat menyelesaikan pembuatan skripsi, yang merupakan salah satu saat syarat untuk memperoleh gelar kesarjanaan di Fakultas Sains dan Teknologi Sanata Dharma Yogyakarta.

Dalam menyelesaikan Skripsi ini penulis telah mendapat bantuan, bimbingan dan motivasi dari berbagai pihak. Dalam kesempatan ini, penulis ingin menyampaikan terima kasih kepada :

1. Kedua orang tua saya yang telah memberi dukungan moral, spiritual dan finansial dalam penyusunan Skripsi.

2. Ibu P.H. Prima Rosa, S.Si., M.Sc. selaku Dekan Fakultas Sains dan Teknologi Universitas Sanata Dharma Yogyakarta dan selaku dosen pembimbing akademik. Terima kasih telah membimbing dan memberikan motivasi dan masukan selama perkuliahan dan penulisan Skripsi ini.

3. Ibu Ridowati Gunawan, S.Kom., S.T. selaku Ketua Jurusan Teknik Informatika Fakultas Sains dan Teknologi Universitas Sanata Dharma Yogyakarta.

4. Bapak JB. Budi Darmawan, S.T., M.Sc. selaku dosen pembimbing Skripsi. Terimakasih telah membimbing dan menyediakan waktu dalam memberikan pengarahan selama penulisan Skripsi ini.

5. Bapak dan Ibu dosen Teknik Informatika Universitas Sanata Dharma.

(10)

x

7. Teman-teman Teknik Informatika, khususnya keapada Agus, Charles, Roby dan Anton yang telah memberi dukungannya kepada penulis.

8. Buat anak-anak kost yang telah memberikan bantuan dan dukungannya.

9. Semua pihak yang belum tersebut yang telah membantu dalam penulisan Skripsi ini, sehingga segala kritik dan dan saran yang bersifat membangun sangat penulis harapkan demi kesempurnaan Skripsi ini.

Yogyakarta, 22 Maret 2012 Penulis,

(11)

xi

Daftar Isi

HALAMAN JUDUL ... i

HALAMAN PERSETUJUAN ... iii

HALAMAN PENGESAHAN ... iv

PERNYATAAN KEASLIAN KARYA ... v

LEMBAR PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ... vi

ABSTRAKSI ... vii

ABSTRACT ... viii

KATA PENGANTAR ... ix

DAFTAR ISI ... xi

DAFTAR GAMBAR ... xv

DAFTAR TABEL ... xviii

BAB I PENDAHULUAN ... 1

I.1. Latar Belakang ... 1

I.2. Rumusan Masalah ... 2

I.3. Tujuan ... 2

I.4. Batasan Masalah ... 3

I.5. Metodologi Penelitian ... 3

I.6. Sistematika Penulisan ... 6

BAB II LANDASAN TEORI ... 7

II.1. Aplikasi Berbasis Web ... 7

II.2. Metodologi FAST ... 10

II.3. Database ... 11

II.4. Use Case Diagram ... 14

(12)

xii

II.6. Entity Relationship ... 17

II.7. MySQL ... 19

BAB III ANALISA dan PERANCANGAN SISTEM ... 21

III.1. Analisis Sistem ... 21

III.1.1. Scope Definition ... 21

III.1.2. Problem Analysis ... 22

III.1.3. Requirements Analysis ... 24

III.1.4. Gambaran Umum Sistem yang Baru ... 25

III.1.5. Logical Design ... 26

III.1.6. Physical Design and integration ... 26

III.1.7. Construction and Testing ... 26

III.2. Perancangan Sistem ... 27

III.2.1. Aktor-aktor Use Case ... 27

III.2.2. Use Case Diagrams ... 28

III.2.3. Narasi Singkat Use Case ... 30

III.2.4. Narasi Lengkap Use Case ... 32

III.3. Logical Design ... 63

III.3.1. Input dan Output Sistem ... 63

III.3.2. Diagram Konteks ... 63

III.3.3. Diagram Berjenjang ... 64

III.3.4. Data Flow Diagram ... 65

III.3.4.1. Data Flow Diagram Level 1 Subsistem Administrator…....66

III.3.4.2. Data Flow Diagram Level 1 Subsistem Pegawai...66

III.3.4.3. Data Flow Diagram Level 2 Proses 1.2...66

III.3.4.4. Data Flow Diagram Level 2 Proses 1.3...67

(13)

xiii

III.3.4.6. Data Flow Diagram Level 2 Proses 1.5...68

III.3.4.7. Data Flow Diagram Level 2 Proses 1.6...68

III.3.4.8. Data Flow Diagram Level 2 Proses 1.7...69

III.3.4.9. Data Flow Diagram Level 2 Proses 1.8...69

III.3.4.10. Data Flow Diagram Level 2 Proses 2.2...70

III.3.5. Entity Relationship Conceptual Diagrams ... 71

III.3.6. Entity Relationship Logical Diagrams ... 72

III.3.7. Physical Data Model ... 73

III.4. Prototype Desain Interface ... 76

III.4.1. Desain Interface Administrator ... 76

III.4.2. Desain Interface Pegawai ... 89

BAB IV IMPLEMENTASI SISTEM ... 91

IV.1. Implementasi pembuatan database ... 91

IV.1.1. Pembuatan database toko ... 91

IV.1.2. Pembuatan tabel-tabel dalam database “toko" ... 92

IV.2. Implementasi pembuatan aplikasi berbasis web ... 96

IV.2.1. Implementasi interface administrator ... 96

IV.2.1.1. Menu Login Administrator...96

IV.2.1.2. Menu Beranda Administrator...97

IV.2.1.3. Menu Kelola Data Barang...98

IV.2.1.4. Menu Kelola Data Merk...98

IV.2.1.5. Menu Kelola Data Kategori...99

IV.2.1.6. Menu Kelola Data Satuan...100

IV.2.1.7. Menu Kelola Data Supplier...100

IV.2.1.8. Menu Kelola Data Pengguna...100

(14)

xiv

IV.2.1.10. Menu Lihat Data Order Pembelian...101

IV.2.1.11. Menu Transaksi Pembelian Tanpa Order...102

IV.2.1.12. Menu Transaksi Pembelian Dengan Order...103

IV.2.1.13. Menu Transaksi Penjualan...103

IV.2.1.14. Menu Laporan Transaksi Pembelian ...104

IV.2.1.15. Menu Laporan Transaksi Penjualan...105

IV.2.1.16. Menu lihat data barang untuk pegawai...106

BAB V Analisa Hasil Implementasi ... 107

V.1. Evaluasi Pengguna ... 107

V.2. Pengumpulan Data Koesioner ... 107

V.3. Sasaran Penyebaran Koesioner ... 108

V.4. Form Koesioner ... 109

V.5. Hasil dan Pembahasn Koesioner ... 111

BAB VI PENUTUP ... 118

VI.1. Kesimpulan ... 118

VI.2. Saran ... 119

(15)

xv

Daftar Gambar

Gambar 2.1. Skema PHP ... 9

Gambar 2.2. File Share Database ... 13

Gambar 2.3. Client/Share database ... 13

Gambar 2.4. Proses ... 16

Gambar 2.5. Aliran Data ... 16

Gambar 2.6. Penyimpan Data ... 17

Gambar 2.7. Agen Eksternal ... 17

Gambar 2.8. Entity Relationship ... 19

Gambar 3.1. Usecase Diagram Sistem ... 30

Gambar 3.2. Diagram Konteks ... 63

Gambar 3.3. Diagram Berjenjang Sistem ... 64

Gambar 3.4. Data Flow Diagram subsistem administrator ... 65

Gambar 3.5. Data Flow Diagram subsistem pegawai. ... 66

Gambar 3.6. Data Flow Diagram level 2 proses 1.2. ... 66

Gambar 3.7. Data Flow Diagram level 2 proses 1.3. ... 67

Gambar 3.8. Data Flow Diagram level 2 proses 1.4. ... 67

Gambar 3.9. Data Flow Diagram level 2 proses 1.5. ... 68

Gambar 3.10. Data Flow Diagram level 2 proses 1.6. ... 68

Gambar 3.11. Data Flow Diagram level 2 proses 1.7. ... 69

Gambar 3.12. Data Flow Diagram level 2 proses 1.8. ... 70

Gambar 3.13. Data Flow Diagram level 2 proses 2.2. ... 70

Gambar 3.14. Entity Relationship Conceptual Diagrams. ... 71

Gambar 3.15. Entity Relationship Logical Diagrams. ... 72

(16)

xvi

Gambar 3.17. Halaman admin menu home/beranda. ... 76

Gambar 3.18. Halaman admin menu data barang. ... 77

Gambar 3.19. Halaman admin menu tambah data barang. ... 77

Gambar 3.20. Halaman admin menu ubah data barang. ... 78

Gambar 3.21. Halaman admin menu hapus data barang. ... 78

Gambar 3.22. Halaman admin menu data merk. ... 78

Gambar 3.23. Halaman admin menu tambah data merk. ... 79

Gambar 3.24. Halaman admin menu ubah data merk. ... 79

Gambar 3.25. Halaman admin menu hapus data merk.. ... 79

Gambar 3.26. Halaman admin menu data kategori. ... 80

Gambar 3.27. Halaman admin menu tambah data kategori. ... 80

Gambar 3.28. Halaman admin menu ubah data kategori. ... 80

Gambar 3.29. Halaman admin menu hapus data kategori. ... 81

Gambar 3.30. Halaman admin menu data satuan. ... 81

Gambar 3.31. Halaman admin menu tambah data satuan. ... 81

Gambar 3.32. Halaman admin menu ubah data satuan. ... 82

Gambar 3.33. Halaman admin menu hapus data satuan. ... 82

Gambar 3.34. Halaman admin menu data supplier. ... 82

Gambar 3.35. Halaman admin menu tambah data supplier. ... 83

Gambar 3.36. Halaman admin menu ubah data supplier. ... 83

Gambar 3.37. Halaman admin menu hapus data supplier. ... 83

Gambar 3.38. Halaman admin menu data barang supplier. ... 84

Gambar 3.39. Halaman admin menu data pengguna. ... 84

Gambar 3.40. Halaman admin menu tambah data pengguna. ... 84

(17)

xvii

Gambar 3.42. Halaman admin menu hapus data pengguna. ... 85

Gambar 3.43. Halaman admin menu order pembelian. ... 85

Gambar 3.44. Halaman admin menu ubah quantity order. ... 86

Gambar 3.45. Halaman admin menu data order. ... 86

Gambar 3.46. Halaman admin menu detail order supplier. ... 86

Gambar 3.47. Halaman admin menu transaksi pembelian tanpa order. ... 87

Gambar 3.48. Halaman admin menu transaksi pembelian dengan order. ... 87

Gambar 3.49. Halaman admin menu transaksi penjualan. ... 88

Gambar 3.50. Halaman admin menu laporan pembelian. ... 88

Gambar 3.51. Halaman admin menu laporan penjualan ... 89

Gambar 3.52. Halaman login sistem pegawai ... 89

Gambar 3.53. Halaman pegawai menu lihat data barang. ... 90

Gambar 4.1. Database toko pada PhpMyAdmin. ... 91

Gambar 4.2. Tabel tuser dalam database toko. ... 92

Gambar 4.3. Tabel tbarang dalam database toko. ... 92

Gambar 4.4. Tabel tsupplier dalam database toko. ... 93

Gambar 4.5. Tabel tsupplieritem dalam database toko ... 93

Gambar 4.6. Tabel tmerk dalam database toko. ... 93

Gambar 4.7. Tabel tkategori dalam database toko. ... 93

Gambar 4.8. Tabel tsatuan dalam database toko ... 94

Gambar 4.9. Tabel torder dalam database toko... 94

Gambar 4.10. Tabel torderitem dalam database toko ... 94

Gambar 4.11. Tabel tpembelian dalam database toko ... 94

Gambar 4.12. Tabel tpembelianitem dalam database toko ... 95

(18)

xviii

Gambar 4.14. Tabel tpenjualanitem dalam database toko ... 95

Gambar 4.15. Halaman Login Toko ... 96

Gambar 4.16. Peringatan Login Salah ... 97

Gambar 4.17. Halaman Beranda Toko ... 97

Gambar 4.18. Halaman Data Barang ... 98

Gambar 4.19. Halaman Data Merk ... 98

Gambar 4.20. Halaman Data Kategori ... 99

Gambar 4.21. Halaman Data satuan ... 99

Gambar 4.22. Halaman Data Supplier ... 100

Gambar 4.23. Halaman Data Pengguna ... 100

Gambar 4.24. Halaman Order ... 101

Gambar 4.25. Halaman Data Order. ... 101

Gambar 4.26. Halaman Transaksi Pembelian tanpa order. ... 102

Gambar 4.27. Halaman Transaksi Pembelian dengan Order ... 103

Gambar 4.28. Halaman Transaksi Penjualan ... 103

Gambar 4.29. Halaman Laporan Transaksi Pembelian ... 104

Gambar 4.30. Halaman Laporan Transaksi Pembelian dalam bentuk PDF ... 104

Gambar 4.31. Halaman Laporan Transaksi Pnjualan ... 105

Gambar 4.32. Halaman Laporan Transaksi Penjualan dalam bentuk PDF ... 105

Gambar 4.33. Halaman Cari dan Lihat Data Barang untuk pegawai ... 106

Daftar Tabel

Tabel 3.1. Aktor-aktor use case ... 27

Tabel 3.2. Narasi singkat use case ... 30

(19)

xix

Tabel 3.4. Tabel user ... 73

Tabel 3.5. Tabel Barang ... 73

Tabel 3.6. Tabel Supplier ... 73

Tabel 3.7. Tabel Supplieritem ... 73

Tabel 3.8. Tabel Merk ... 74

Tabel 3.9. Tabel Kategori ... 74

Tabel 310. Tabel Satuan ... 74

Tabel 3.11. Tabel Order ... 74

Tabel 3.12. Tabel Orderitem ... 74

Tabel 3.13. Tabel Pembelian ... 75

Tabel 3.14. Tabel Pembelianitem ... 75

Tabel 3.15. Tabel Penjualan ... 75

Tabel 3.16. Tabel Penjualanitem ... 75

Tabel 5.1. Tabel jawaban “Sistem ini dapat membantu dalam pendataan” ... 111

Tabel 5.2. Tabel jawaban “Sistem ini dapat mempermudah dan mempercepat pengguna dalam membuat order pembelian” ... 111

Tabel 5.3. Tabel jawaban “Sistem ini dapat mempermudah dan mempercepat pengguna dalam proses transaksi pembelian” ... 112

Tabel 5.4. Tabel jawaban “Sistem ini dapat mempermudah dan mempercepat pengguna dalam proses transaksi penjualan” ... 113

Tabel 5.5. Tabel jawaban “Sistem ini dapat memberikan informasi barang-barang yang di suply oleh setiap supplier” ... 113

(20)

xx

Tabel 5.7. Tabel jawaban “Sistem ini dapat memanajemen data masukan dengan baik” ... 114

Tabel 5.8. Tabel jawaban “Sistem ini mempunyai tampilan/user interface yang menarik” ... 115 Tabel 5.9. Tabel jawaban “Sistem ini dapat memberikan informasi data barang” .. 115

Tabel 5.10. Tabel jawaban “Sistem ini dapat membantu dalam pencarian data barang” ... 116

(21)

1

BAB I

PENDAHULUAN

II.1 Latar Belakang

Toko “ATENG” adalah sebuah toko yang menjual barang-barang

kebutuhan sehari-hari seperti mie instan, sabun mandi, shampo, kopi, susu dan lain-lain. Dalam toko tersebut terdapat tiga pegawai yang ditugaskan sebagai pelayan (yang melayani) pembeli yang datang. Dan seorang pegawai yang ditugaskan sebagai pengelola toko seperti menambah data barang, harga suatu barang dan me-monitoring jumlah barang/stock di gudang. Setiap harinya toko tersebut melakukan pencatatan secara manual untuk proses transaksi maupun pencatatan data pembelian, penjualan ataupun me-monitoring stok barang. Dalam melakukan suatu transaksi atau pencatatan tersebut dibutuhkan informasi yang cepat dan akurat, karena informasi tersebut sangat penting untuk perkembangan toko. Kondisi seperti itu dapat mengakibatkan lambatnya akses informasi karena menggunakan sistem yang masih manual dan proses transaksi serta pencatatan menjadi tidak efisien.

(22)

2

diharapkan mampu membantu pekerjaan pegawai dalam mengatur atau mengelola data, sehingga dalam pengimplementasian dari sistem administrasi pembelian dan penjualan barang jadi lebih efisien serta dapat mengurangi kerugian sekecil mungkin karena keteledoran dalam melayani pembeli, terutama di bidang transaksi penjualan, sehingga dapat meningkatkan keamanan dan kenyamanan bagi pemilik toko. Program yang dibuat akan menangani transaksi pembelian, transaksi penjualan dan pemantauan stok barang. Sistem ini bersifat multiuser berbasis web PHP dan database MySQL yang bersifat Open Source yang akan diterapkan dengan jaringan lokal atau intranet. Dengan teknologi berbasis web, program ini dapat diakses dari komputer tanpa harus menginstal program klien. Program bantuan untuk mengakses sistem ini hanya sebuah browser.

II.2 Rumusan Masalah

Bagaimana membuat aplikasi untuk membantu transaksi pembelian dan penjualan barang pada Toko “ATENG” berbasis intranet, sehingga dapat lebih efisien dan dapat mengurangi kerugian karena keteledoran dalam melakukan transaksi penjualan.

II.3 Tujuan

(23)

3 II.4 Batasan Masalah

Batasan-batasan masalah yang terdapat pada tugas akhir ini antara lain: a) Sistem yang dibuat dibatasi hanya sampai pada transaksi

pembelian, penjualan barang.

b) Sistem yang dibuat tidak mengelola masalah konversi satuan barang, barang rusak, retur, akuntasi dan utang-piutang (pembelian kredit).

c) Pada saat tertentu, saat ada transaksi penjualan dan pembelian hanya satu user saja yang boleh login dan melakukan proses transaksi.

d) Sistem ini berbasis multiuser hanya untuk melihat informasi data barang saja.

e) Sistem yang dibuat sudah dapat menangani keamanan sistem dengan menggunakan login user namun tidak menangani masalah keamanan jaringan.

II.5 Metodologi Penelitian

Metodologi penelitian yang digunakan dalam pembuatan sistem pada Tugas Akhir adalah metodologi pendekatan terstruktur, sebagai berikut:

1. Studi Pustaka

(24)

4 2. Wawancara

Melakukan wawancara dengan pemilik dan pegawai toko.

3. Perancangan dan implementasi sistem yang akan dibuat menggunakan metode FAST (Framework for the Application of Systems Thinking) ( Whitten, 2004), yang meliputi :

a) Definisi Lingkup (Scope definition) yang didalamnya terdapat pernyataan masalah dengan ruang lingkup sesuai yang dianalisis. Fase ini meliputi : gambaran sistem yang ada saat ini dan problem statement ysng didefinisikan dalam PIECES (Performance, Imformation, Economic, Control Problem, Efficiency, Service).

b) Analisis Masalah (Problem Analysis)

Merupakan tahap analisis masalah yang ada. Dari analisis masalah akan diketahui layak tidaknya sebuah sistem baru dibangun, Fase ini meliputi : PIECES Cause Efect Analysis dan System Improvement Objective, serta gambaran sistem yang baru.

c) Analisis Persyaratan (Requirements Analysis)

Merupakan tahap analisis kebutuhan. Perlu ada pendekatan kepada user untuk mengetahui apa yang dibutuhkan atau yang diinginkan terhadap sistem yang baru. Fase ini meliputi : use case diagram, dan use case narrative.

(25)

5

Merupakan tahap untuk menterjemahkan kebutuhan user kedalam sistem model atau desain secara logika. Fase ini meliputi : diagram konteks, diagram berjenjang, Entity Relation diagram, Data Flow Diagram (DFD), dan desain data model

e) Desain Fisik dan Integrasi (Physical Design and integration)

Merupakan tahap menterjemahkan kebutuhan user kedalam sistem secara fisik berdasarkan rancangan yang telah ada. Output berupa design of spesification dan design of prototyping.

f) Konstruksi dan Pengujian (Construction and Testing) Merupakan tahap konstruksi dan pengujian komponen sistem. Output berupa functional system yang siap untuk diimplementasikan.

(26)

6 II.6 Sistematika Penulisan

Bab I PENDAHULUAN

Membahas mengenai latar belakang masalah, rumusan masalah, batasan masalah, tujuan penelitian dan metodelogi penelitian.

Bab II LANDASAN TEORI

Bab ini berisi teori-teori dan prinsip-prinsip yang menunjang pembuatan tugas akhir.

Bab III PERANCANGAN SISTEM

Bab ini membahas perancangan sistem yang dibangun, dengan menggunakan DFD dan melakukan desain database dengan menggunakan ERD hingga terbentuk databasse dengan struktur tabel yang lengkap.

BAB IV IMPLEMENTASI SISTEM

Membahas tahap-tahap implementasi dari perancangan yang telah dibuat sebelumnya meliputi tampilan program dari input maupun output yang akan dihasilkan.

BAB V ANALISA HASIL IMPLEMENTASI

Bab ini berisi analisa hasil implementasi system berdasarkan kuesioner.

BAB VI KESIMPULAN DAN SARAN

(27)

7

BAB II

LANDASAN TEORI

II.1 Aplikasi Berbasis WEB

Saat ini, web telah menjadi antarmuka pemakai untuk aplikasi basisdata. E-commerce menjadi bagian terpadu perdagangan dimana basisdata berperan penting. Web telah menjadi sistem informasi tersebar berbasis hypertext. Web menjadi penting sebagai front-end basisdata karena beberapa alasan : (Bambang Hariyanto, 2004)

f) Web browser telah menyediakan front-end universal terhadap informasi yang diberikan back-end yang berlokasi di manapun di dunia.

g) Web browser berjalan di sistem komputer manapun dan pemakai tidak perlu melakukan download perangkat lunak khusus untuk mengakses informasi. Saat ini hampir setiap orang dapat melakukan pengaksesan informasi melalui web. Web browser telah menjadi pilihan antarmuka pemakai untuk aplikasi fungsi perusahaan. Pada perusahaan, aplikasi web interaktif digunakan dalam beragam cara :

 Intranet : Aplikasi yang menyediakan pengaksesan informasi skala perusahaan.

(28)

8

 Internet : Aplikasi interaktif website perusahaan seperti sistem e-commerce.

Tidak hanya penggunaan dan fungsi solusi berbasis web perusahaan yang meluas tapi juga aplikasi web menjadi semakin kompleks, memberi interaktif pemakai akhir, integrasi aplikasi lain, dan pengaksesan basisdata dan sumber data.

Website perusahaan memerlukan fungsionalitas yang semakin canggih seperti pelacakan, pembaruan dan agregasi basisdata. Kebutuhan bisnis dan pemakai yang berevolusi memberi tekanan pada peningkatan infrastruktur aplikasi web serta secara cepat mengembangkan dan menghasilkan produk, fitur dan fungsionalitas baru (Bambang Hariyanto, 2004).

(29)

9

dikirimkan ke mesin PHP dan mesin inilah yang memproses dan memberikan hasilnya (berupa kode HTML) ke web server. Selanjutnya web server menyampaikan ke klien (Abdul Kadir, 2008).

Gambar 2. 1. Skema PHP

Web Server atau lebih tepatnya worl wide web server adalah server Internet yang mampu melayani koneksi transfer data dalam protokol HTTP (hypertext transfer protokol). Web server saat ini merupakan inti dari beberapa server Internet selain e-mail server, ftp dan news server. Hal tersebut bisa dimaklumi karena web server telah dirancang agar dapat melayani beragam jenis data, mulai dari text, hypertext, gambar(image), suara, gambar tiga dimensi, plug-in, dan sebagainya. Apache merupakan

Tanggapan HTTP Skrip PHP

Mesin PHP

Kode HTML Permintaan HTTP

(sesuatu.php)

Web server

Browser

(30)

10

salah satu web server yang paling banyak digunakan di Internet. Hal ini disebabkan oleh beberapa faktor, seperti kecepatan, performa dan tentu saja karena harganya yang gratis. (Iswanto, 2007)

II.2 Metodologi FAST

Dalam proses pengembangan sistem, penulis menggunakan metode FAST (Framework for the Systems Thinking) (Whitten, 2004), yang meliputi:

g) Definisi Lingkup (Scope definition) yang didalamnya terdapat pernyataan masalah dengan ruang lingkup sesuai yang dianalisis. Fase ini meliputi : gambaran sistem yang ada saat ini dan problem statement ysng didefinisikan dalam PIECES (Performance, Imformation, Economic, Control Problem, Efficiency, Service).

h) Analisis Masalah (Problem Analysis)

Merupakan tahap analisis masalah yang ada. Dari analisis masalah akan diketahui layak tidaknya sebuah sistem baru dibangun, Fase ini meliputi : PIECES Cause Efect Analysis dan System Improvement Objective, serta gambaran sistem yang baru.

i) Analisis Persyaratan (Requirements Analysis)

(31)

11

j) Desain Logis (Logical Design)

Merupakan tahap untuk menterjemahkan kebutuhan user kedalam sistem model atau desain secara logika. Fase ini meliputi : diagram konteks, diagram berjenjang, Data Flow Diagram (DFD), Entity Relation diagram.

k) Desain Fisik dan Integrasi (Physical Design and integration)

Merupakan tahap menterjemahkan kebutuhan user kedalam sistem secara fisik berdasarkan rancangan yang telah ada. Output berupa design of spesification dan design of prototyping.

l) Konstruksi dan Pengujian (Construction and Testing) Merupakan tahap konstruksi dan pengujian komponen sistem. Output berupa functional system yang siap untuk diimplementasikan.

II.3 Database

Database adalah kumpulan data-data yang saling memiliki relasi dan terstruktur, dimana kumpulan data-data tersebut berfungsi sebagai sumber dalam pengolahan menjadi informasi. Database ini umumnya digunakan untuk arus informasi atau data dalam jumlah yang besar. Garis besarnya, database dipakai untuk menyimpan data sehingga dapat dimanipulasi dengan mudah. (Laudon, 2000)

(32)

berbelit-12

belit, sehingga memudahkan dalam pengaksesan dan manajemen darai data yang ada.

Beberapa hal yang muncul jika database tidak memenuhi syarat seperti di atas, antara lain :

 Ketidaksesuaian Data (Data Inconsistency)

Hal ini terjadi ketika hubungan antar data tidak diatur secara benar dalam database. Akibat yang muncul adalah data yang seharusnya berubah ketika ada data baru masuk, atau ketika ada perubahan data, table tersebut tidak berubah sesuai dengan apa yang diharapkan. (McLeod, 2000)

 Kelebihan Data (Redudancy Data)

Data yang sama disimpan dalam scbuah database tanpa alasan yang jelas. Hal ini mengakibatkan pemborosan kapasitas penyimpanan, penurunan kecepatan proses, dan lain-lain. (McLcod, 2000).

 Data yang Tersebar (Lack of Data Sharing and Availability) Kesalahan dalam pengelompokan data mengakibatkan data yang seharusnya mudah didapatkan, menjadi berbelit-belit dalam pengaksesannya. Dampak yang muncul dari hal ini adalah kelambatan system dan kurang akurat dalam menampilkan informasi yang diminta user. (Laudon, 2000) Berdasarkan kompleksitas datanya, database dibagi menjadi 3 model yaitu:

(33)

13

database disimpan pada komputer yang sama. Sehingga, otomatis hanya diakses oleh komputer tersebut saja.

b. File share database. Hampir sama dengan database stand-alone, tetapi diakses oleh beberapa user. Seperti dapat dilihat pada gambar 2.2.

c. Client/Server database. Database ini menggunakan sebuah komputer tersendiri yang berfungsi sebagai Server, dan memiliki beberapa komputer Client yang saling terhubung. Seperti dapat dilihat pada gambar 2.3.

Perbedaan File Share database dan Client/Server database : (McLeod, 2000)

File Share Databse

Gambar 2.2. File Share Database

Client/Server Databse

Gambar 2.3. Client/Server Database

Server Clien

2) Kirim Data 1)Minta Data

3)Data diproses sendiri oleh

Client

Server Client

2)Data yang diminta diproses oleh Server

3)Data diproses sendiri oleh

Client

(34)

14 II.4 Use Case Diagrams

Use Case Diagram digunakan untuk menggambarkan interaksi antara pengguna sistem (actor) dengan kasus (use case) yang disesuaikan dengan langkah-langkah (scenario) yang telah ditentukan. Sejak tahun 1992, dengan adanya pengembang UML, yaitu Jacob Et All, menjadikan use case sebagai model utama atau yang dibutuhkan (Requeirment Model) pada UML.

Use Case Diagram digunakan untuk menggambarkan fungsi sistem yang terdapat dalam bisnis even, siapa yang melakukan kejadian dan bagaimana sistem memberikan respon terhadap kejadian (Whitten, 2004).

Berikut adalah lambang-lambang dalam diagram Use case : Urutan langkah-langkah yang secara tindakan saling terkait (skenario), baik terotomasi maupu secara manual, untuk tujuan melengkapi satu tugas bisnis tunggal.

Segala sesuatu yang perlu berinteraksi dengan sistem untuk pertukaran informasi.

Simbol Relasi

Menghubungkan interksi antara aktor dengan usecase.

Simbol Use Case

(35)

15

Use case diagram ini menggambarkan kebutuhan system dari sudut pandang user, memfokuskan pada proses komputerisasi (automated processes), menggambarkan hubungan antara use case dan actor serta menggambarkan proses system (kebutuhan sistem dari sudut pandang user). Secara umum use case adalah pola perilaku system dan urutan transaksi yang berhubungan yang dilakukan oleh satu acktor.

Use case diagram terdiri dari Use case, actors, relationship, system boundary boxes (optional), packages(optional).

II.5 Data Flow Diagram (DFD)

Kegunaan dari DFD ialah untuk menggambarkan system yang ada kemudian hasil tersebut akan digunakan sebagai acuan untuk merencanakan dan mendesain physical modeling (table-table) yang sesuai.

Informasi dan perubahan dalam DFD ditujukan dengan cara hirarki dalam bentuk diagram level. DFD level 0 berisi entity-entity luar dari proses tunggal suatu system dengan input dan output data yang ditunjukkan dengan arah anak panah kedalam dan keluar. Diagram yang lebih detil lagi dari system tersebut, dibentuk dengan membagi/memecah proses pada level 0 DFD.

DFD menggunakan 4 macam simbol yaitu proses, aliran data, penyimpanan data, dan agen eksternal (Whitten, 2004).

 Proses (transformation process)

(36)

16

menghasilkan output yang telah diproses.Seperti dapat dilihat pada gambar 2.4. (Whitten, 2004).

Gambar 2.4. Proses

 Aliran data (data flow)

Menggambarkan aliran yang menunjukkan pergerakan data dari sebuah entity ke entity yang lain. Data flow disimbolkan dengan tanda panah dan diberi kctcrangan, yang menunjukkan data apa yang mengalir. Seperti dapat dilihat pada gambar 2.5. (Whitten, 2004).

Nama aliran data

Gambar 2.5. Aliran Data (data flow)

 Penyimpanan data (data store)

Menggambarkan terjadinya penyimpanan data dalam suatu sistem. Contohnya, dilakukan penyimpanan data penjualan. Sehingga data yang disimpan tersebut dapat digunakan lagi untuk proses-proses yang memerlukannya kemudian. Seperti dapat dilihat pada Gambar 2.6. (Whitten, 2004).

Nama Proses output

(37)

17

Gambar 2.6. Penyimpanan Data (Data Store)

External agent/entitas eksternal

Mendefinisikan orang, unit organisasi, sistem lain, atau organisasi lain, yang berada di luar lingkup proyek itu tetapi berinteraksi dengan sistem yang sedang dipelajari. Agen eksternal menyajikan input bersih ke sistem dan menerima output bersih dari sistem. Seperti dapat dilihat pada Gambar 2.7. (Whitten, 2004).

Gambar 2.7. Agen Eksternal (external agent)

II.6 Entity Relationship (E-R diagram)

Perancangan basis data konseptual adalah proses membangun suatu model dari informasi yang digunakan dalam suatu organisasi yang tergantung pada segala pertimbangan fisik (Connoly and Begg, 2010). Berikut ini adalah simbol-simbol yang digunakan dalam menggambarkan entity-relationship modeling pada tahap perancangan basis data konseptual (Connoly and Begg, 2010), yaitu :

Data Store

(38)

18 EntityName

EntityName attributeName

Nama Entitas

Entitas dengan atribut primary key (PK)

Keterangan Simbol

Entitas dengan atribut-atribut. Primary key diberi tanda dengan PK. Alternative key diberi tanda dengan AK.

Composite attributes ditulis dibawah dan

(39)

19

Gambar 2.8. E-R diagram.

II.7 MySQL

MySQL adalah Relational Database Management Sistem (RDBMS) yang menggunakan instruksi SQL untuk menerima request dari SQL (Kurniawan, 2002). MySQL merupakan database yang paling popular digunakan. MySQL sebenarnya merupakan turunan dari SQL (Structured Query Language). SQL yang sering dibaca “Sequel” adalah

Relatinship Name

kemungkinan nilai yang ada dari atribut tersebut {Min…Max}

Relationship berlabel nama relationship dan arah panah

Relationship dengan multiplicity constraint {Min value…Max value}

Binary Relationship

Min value....Max value Min value....Max value

EntityName Relatinship Name EntityName

EntityName

EntityName Relatinship Name EntityName

(40)

20

(41)

21

BAB III

ANALISA DAN PERANCANGAN SISTEM

III.1 Analisis Sistem.

III.1.1 Definisi Lingkup (Scope Definition)

III.1.1.1 Gambaran sistem yang ada saat ini.

Saat ini belum ada sistem yang membantu “Toko Ateng”

dalam mengelola transaksi-transaksi pembelian dan penjualan serta memonitoring barang. Dalam mengelola suatu transaksi pembelian atau penjualan dan mengelola stock barang dilakukan secara manual. Karena dilakukan secara manual maka dalam mengelola transaksi-transaksi pembelian dan penjualan serta mengelola stock barang terdapat kendala-kendala yang akan dihadapi.

Kendala yang pertama adalah terlalu banyaknya jenis barang yang ada, sehingga pegawai ataupun pemilik toko terkadang memerlukan waktu lama dalam memberikan harga jual serta menginformasikan jumlah stock barang yang ada di gudang.

Kendala yang kedua adalah semakin banyaknya jumlah pembeli yang datang, sehingga pegawai ataupun pemilik toko kerepotan dalam melayani pembeli, dikarenakan sistem transaksi penjulan masih dilakukan secara manual.

(42)

22

membantu toko dalam mengelola transaksi-transaksi pembelian dan penjualan serta membantu dalam memonitoring stock barang di gudang secara mudah dan cepat.

III.1.2 Analisis Masalah (Problem Analysis)

Permasalahan yang dihadapi oleh took saat ini banyak disenankan karena proses-proses yang dikerjakan saat ini masih secara manual. Berikut ini adalah permasalahan yang sering muncul :

 Pemilik toko tersebut kewalahan dalam mengerjakan proses transaksi pembelian dan penjualan yang semakin meningkat jumlahnya.

 Pegawai yang ditugaskan mengangani data-data transaksi dan stok barang kerepotan dalam megelola.

 Untuk stok barang dalam jumlah yang cukup besar, seringkali terjadi kesalah dalam menghitung jumlah barang yang masuk dan yang keluar.

 Untuk proses inventorisasi, seringkali terjadi kesalahan dalam mengecek pencatatan stok barang dikarenakan semakin banyaknya data yang harus dikelola.

(43)

23

Performance : Karena sistem transaksi pembelian, penjualan dan pengelolaan data barang masih manual, maka pegawai pada toko tersebut mengalami kesulitan dalam melayani pembeli. Hal itu diakibatkan karena 3 dari 4 pegawai pada toko tersebut tidak tahu harga suatu jenis barang.

Information : Dalam sistem yang ada pada toko Ateng saat ini, informasi yang dibutuhkan mengenai data harga, jumlah stok barang tidak dapat langsung diketahui, sehingga ketika ada pembeli yang datang ingin menanyakan harga atau supllier yang menawarkan barang dibutuhkan waktu yang cukup lama untuk melayaninya. Karena harus mencari data pada sistem yang manual.

Economics : Toko akan mengalami kerugian jika terjadi keteledoran dalam melayani transaksi penjualan ataupun pembelian karena keterbatasan sistem yang ada sekarang masih manual. .

(44)

24

data tersebut yang ditumpuk, sehingga keamanan data tersebut tidak terjamin, kemungkinan hilang sangat besar.

Efficiency : Sistem yang ada saat ini memerlukan waktu cukup lama untuk memperoleh informasi mengenai harga, data transaksi dan data stok barang, sehingga tidak efisien .

Service : Pelayanan kepada pembeli atau supllier yang datang kurang maksimal. Hal ini disebabkan karena penggunaan sistem yang manual sehingga pelayanan menjadi sedikit terhambat.

III.1.3 Fase Analisis Persyaratan (Requirements Analysis)

Dari permasalahan yang muncul, maka beb erapa hal berikut dibutuhkan toko dalam pembuatan sistem pembelian, penjualan, dan stok barang yang baru :

 Komputerisasi untuk proses penjualan dan pembelian, sehingga meskipun jumlah pembelian dan penjualan semakin meningkat, namun toko Ateng tetap dapat menanganinya dengan baik.

 Penghitungan atau me-monitoring jumlah stok barang secara akurat, sehingga aliran keluar dan masuk barang dapat diketahui dengan jelas.

(45)

25

Dari analisis kebutuhan di atas, program sistem pembelian, penjualan, yang hendak dibuat sebagai berikut :

 Berkaitan dengan data asset took, dilakukan penyimpanan stok barang dan penyimpanan data supplier.

 Berkaitan dengan data transaksi , dilakukan pencatatan data pembelian dan penjualan barang.

 Dari pencatatan-pencatatan data yang ada, dihasilkan laporan– laporan berupa : laporan transaksi pembelian dan penjualan.

III.1.4 Gambaran Umum Sistem yang Baru

Sistem yang akan dibuat adalah aplikasi transaksi pembelian dan penjualan berbasis intranet. Sistem ini dibuat berbasis web, sehingga memudahkan bagi pegawai atau pemilik toko dalam mengelola transaksi-transaksi pembelian dan penjualan serta memonitoring stock barang. Pengguna dalam sistem ini terdiri dari tiga pegawai yang bertugas melayani pembeli dan satu admin yang bertugas mengelola transaksi-transaksi pembelian dan penjualan serta memonitoring stock barang di gudang.

Sistem menyediakan fasilitas bagi pegawai untuk :

 Mendapatkan informasi harga-harga barang yang terdaftar.

Sistem menyediakan fasilitas bagi administrator untuk :

(46)

26

 Mengelola (insert, edit, delete) data supplier.

 Mengelola (insert, edit, delete) data user.

 Mengelola transaksi pembelian maupun penjualan.

III.1.5 Desain Logis (Logical Design)

Dalam fase ini business requirement yang ada diterjemahkan dalam bentuk gambar-gambar. Pada tahap ini menggunakan diagram aktivitas untuk menggambarkan proses bisnis, langkah–langkah use case, dan logika perilaku obyek. Selain itu, tahap ini menggunakan ER-Diagram dan DFD sebagai system modelnya.

III.1.6 Desain Fisik dan Integrasi (Physical Design and integration) Dalam fase ini merupakan tahap perancangan sistem secara fisik berupa Usecase, UML, DFD, perancangan database, dan desain User interface.

III.1.7 Konstruksi dan Pengujian (Construction and Testing)

Dalam fase ini merupakan tahap pembangunan sistem berdasarkan rancangan yang telah dibuat pada tahap desain fisikal, kemudian menguji komponen-komponen sistem tersebut dengan

(47)

27 III.2 Perancangan Sistem

III.2.1 Aktor-aktor use case.

Tabel 3. 1. Aktor-aktor use case

Nama Aktor Keterangan

Administrator Pihak yang menjalankan sistem dan mempunyai hak akses atau kewenangan khusus dalam melakukan perubahan-perubahan dalam sistem.

(48)

28 III.2.2 Use Case Diagram.

Tambah Data Merk Edit Data Merk Hapus Data Merk

Tambah Data Kategori Edit Data Kategori Hapus Data Kategori

Tambah Data Satuan Edit Data Satuan Hapus Data Satuan

Administrator

Login

Cari Data Barang

Tambah Data Barang

Edit Data Barang

Hapus Data Barang

Logout

<<depents on>>

(49)

29

Tambah User

Edit User

Hapus User

Administrator

Login

Cari Data Supplier

Tambah Data Supplier

Edit Data Supplier

Hapus Data Supplier

(50)

30 Administrator

Login

Tambah Order Pembelian

Edit Order Pembelian

Hapus Order Pembelian

Tambah Transaksi Penjualan

Tambah Transaksi Pembelian

Lihat Data Order Pembelian

Lihat Laporan Pembelian

Lihat Laporan Penjualan

Logout <<depents on>>

Gambar 3. 1 Use case diagram sistem

III.2.3 Narasi Singkat Use Case.

Tabel 3. 2 Narasi singkat use case.

Nama Use-Case Desripsi Use-Case Pelaku yang berpartisipasi

Cari Data Barang Use case ini menggambarkan proses cari data barang.

Administrator (primary business), Pegawai Tambah Data

Barang

Use case ini menggambarkan proses

input data barang.

Administrator (primary business)

Edit Data Barang Use case ini menggambarkan proses

update data barang.

(51)

31

Hapus Data Barang Use case ini menggambarkan proses

penghapusan data barang.

Administrator (primary business)

Tambah Data Merk Use case ini menggambarkan proses

input data merk.

Hapus Data Merk Use case ini menggambarkan proses

penghapusan data Merk.

Administrator (primary

Edit Data Kategori Use case ini menggambarkan proses

update data kategori.

Administrator (primary business)

Hapus Data Kategori

Use case ini menggambarkan proses

penghapusan data kategori.

Administrator (primary

Edit Data Satuan Use case ini menggambarkan proses

update satuan .

Administrator (primary business)

Hapus Data Satuan Use case ini menggambarkan proses

penghapusan data satuan.

Administrator (primary

Edit Data Supplier Use case ini menggambarkan proses

update supplier.

Administrator (primary business)

Hapus Data Supplier

Use case ini menggambarkan proses

penghapusan data supplier.

Administrator (primary business)

Tambah Data User Use case ini menggambarkan proses

input data user.

Hapus Data User Use case ini menggambarkan proses

penghapusan data user.

Administrator (primary business)

Tambah Order Pembelian

Use case ini menggambarkan proses pembuatan order pembelian.

Administrator (primary business)

Tambah Transaksi Pembelian Order

Use case ini menggambarkan proses transaksi pembelian order.

(52)

32

Lihat Data Order Use case ini menggambarkan proses lihat data order.

Administrator (primary business)

Lihat Laporan Penjualan

Use case ini menggambarkan proses lihat laporan penjualan.

Administrator (primary business)

Lihat Laporan Pembelian

Use case ini menggambarkan proses lihat laporan pembelian atau pembelian order.

Administrator (primary business)

LOG IN Use case ini menggambarkan proses masuk ke sistem.

Administrator (primary business) Pegawai LOG OUT Use case ini menggambarkan proses

keluar dari sistem.

Administrator (primary business) Pegawai

III.2.4 Narasi lengkap Use Case.

Nama Use case : Login.

Author : Untung S

Date :

Version : 1.0

Use-case Name: LOG IN Jenis Use-Case

Use-case ID: Lgn Business Requirements: ฀

(53)

33

dilakukan Admin tidak dapat dilakukan oleh pegawai. Precondition: Admin/pegawai telah memiliki password.

Trigger: Use case ini digunakan apabila ada aktor yang ingin masuk ke dalam sistem.

Typical Course of event:

Actor Action System Response

Step 1:user(Admin atau

pegawai) mengklik menu LOGIN.

Step 3:user memasukkan username dan password.

Step 4:user mengklik tombol LOGIN.

Step 2: Sistem meminta user untuk memasukkan username dan password.

Step 5: Sistem mengecek validasi di database.

Step 6: Sistem masuk ke menu utama/beranda.

Alternate Course: Alt-Step 4: User mengklik tombol BATAL, sehingga sistem tidak jadi masuk ke menu utama dan kembali ke menu LOGIN.

Alt-Step 5: Jika username dan password yang dimasukkan tidak sesuai maka sistem akan memberikan peringatan dan secara otomatis kembali ke menu LOGIN.

Conclusion: Use case ini berhenti apabila user telah berhasil masuk ke dalam menu utama.

Postcondition: User berhasil login dan masuk ke menu utama.

User tidak jadi masuk ke sistem.

Business Rules: User harus memasukkan username dan password dengan benar. Implementation

Constrains and Specifications:

Tampilan sistem berupa web.

Assumptions: -

(54)

34

Nama Use case : Cari Data Barang.

Author : Untung S

Date :

Version : 1.0

Use-case Name: Cari Data Barang Jenis Use-Case

Use-case ID: CrDB Business

Requirements: ฀ Priority : High

Source: Formulir data barang. Primary

Decription: Use case ini menggambarkan proses caridata. Sumber data berupa data barang.

Precondition: Admin atau pegawai telah melalui proses login.

Trigger: Use case ini akan digunakan apabila ingin melihat data barang.

Typical Course of event:

Actor Action System Response

Step 1: Admin atau pegawai mengklik menu CARI.

Step 2: Sistem menampilkan hasil pencarian data barang.

Alternate Course:

(55)

35

Nama Use case : Tambah Data Barang. Postcondition:

Business Rules: Implementation Constrains and Specifications:

Tampilan sistem berupa web yang akan mempermudah Admin untuk mencari data.

Assumptions: -

Open issues: 1. Keakuratan data tidak terjamin jika admin harus mencari data yang dimaksud hanya dengan menggunakan kumpulan dokumen-dokumen data toko.

Author : Untung S

Date :

Version : 1.0

Use-case Name: Tambah Data Barang Jenis Use-Case

Use-case ID: InptDB Business

Requirements: ฀ Priority : High

Source: Formulir data barang. Primary

Business Actor:

Admin

Other

Participating Actor:

-

Other Interested Stakeholder:

-

(56)

36

Sumber input data berupa data barang. Precondition: Admin telah melalui proses login.

Trigger: Use case ini akan digunakan apabila ada interaksi

penginputan formulir data barang. Typical Course

of event:

Actor Action System Response

Step 1: Admin mengklik menu TAMBAH.

Step 3: Admin

memasukkan data barang yang ingin diinputkan. Step 5: Admin mengklik tombol SIMPAN.

Step 2: Sistem menampilkan form tambah data barang. Step 4: Sistem memperoleh mengklik tombol BATAL.

Alt-Step 6: Jika data yang diinputkan tidak berhasil, maka sistem akan memberikan peringatan.

Conclusion: Use case ini berhenti apabila tidak ada data yang diinputkan lagi.

Postcondition:  Data berhasil ditambahkan ke database.

 Data tidak berhasil ditambahkan ke database. Business Rules: Admin harus memasukkan data dengan tipe yang sesuai. Implementation

Constrains and Specifications:

Tampilan sistem berupa web yang akan mempermudah admin untuk menginputkan data.

Assumptions: -

Open issues: 1. Keakuratan data tidak terjamin jika admin harus

memasukkannya secara manual dengan

(57)

37

Nama Use case : Edit Data Barang.

Author : Untung S

Date :

Version : 1.0

Use-case Name: Edit Data Barang Jenis Use-Case

Use-case ID: UpdtDB Business

Requirements: ฀ Priority : High

Source: Formulir data barang. Primary

Decription: Use case ini menggambarkan proses update data. Data yang diupdate dapat berupa data barang. Update data dapat dilakukan secara berkala.

Precondition: Admin telah melalui proses login.

Trigger: Use case ini akan digunakan apabila ada interaksi pengisian formulir data barang.

Typical Course of event:

Actor Action System Response

(58)

38

Nama Use case : Hapus Data Barang. Alternate

Course:

Alt-Step 5: Admin tidak jadi mengubah data dengan mengklik tombol BATAL.

Alt-Step 6: Jika data yang diubah tidak berhasil, maka sistem akan memberikan peringatan.

Conclusion: Use case ini akan berhenti apabila tidak ada data yang harus diubah.

Postcondition:  Data berhasil diubah dan disimpan ke database.

 Data tidak berhasil diubah.

Business Rules: Admin harus memasukkan data dengan tipe yang sesuai dengan tipe data yang akan diubah.

Implementation Constrains and Specifications:

Tampilan sistem berupa web yang dilengkapi dengan fitur pencarian data, kemudian data dapat diubah sesuai dengan tipe data.

Assumptions: -

Open issues: 1. Data yang diubah dengan menggunakan buku, tidak dapat langsung ter-update apabila admin ingin mengubahnya.

Author : Untung S

Date :

Version : 1.0

Use-case Name: Hapus Data Barang Jenis Use-Case

Use-case ID: Dlt DB Business

Requirements: ฀ Priority : High

(59)

39

Decription: Use case ini menggambarkan proses penghapusan data. Data yang dihapus berupa data barang. Penghapusan data dilakukan apabila data yang sudah tidak diperlukan lagi. Precondition: Admin telah melalui proses login.

Trigger: Use case ini digunakan apabila ada data yang di dalam sistem sudah tidak diperlukan lagi.

Typical Course of event:

Actor Action System Response

Step 1: Admin mengklik menu HAPUS.

Step 3: Admin mengklik tombol HAPUS.

Step 2: Sistem menampilkan data yang ingin dihapus. Step 4: Sistem memberitahu bahwa data berhasil dihapus.

Alternate Course:

Alt-Step 3: Admin mengklik tombol BATAL, sehingga sistem tidak jadi menghapus data yang dipilih(kembali ke menu utama).

Alt-Step 4: Jika telah berhasil dihapus, maka sistem akan memberikan peringatan.

Conclusion: Use case ini berhenti apabila semua data yang diinginkan telah berhasil dihapus.

Postcondition:  Data berhasil dihapus dari database.

 Data tidak berhasil dihapus dan tetap berada di dalam database.

Business Rules: Admin harus menghapus data dengan data yang sesuai dengan data yang ingin dihapus.

(60)

40

Nama Use case : Cari Data Supplier. Constrains and

Specifications:

pencarian data, kemudian data yang ditemukan tersebut dapat langsung dihapus.

Assumptions: -

Open issues: 1. Pencarian data yang lama dan tidak terlalu akurat membuat admin harus berulang-ulang kali memastikan data tersebut memang data yang ingin dihapus.

Author : Untung S

Date :

Version : 1.0

Use-case Name: Cari Data Supplier Jenis Use-Case

Use-case ID: LhtDS Business

Requirements: ฀ Priority : High

Source: Formulir data supllier. Primary

Business Actor:

Admin

Other

Participating Actor:

Other Interested Stakeholder:

-

Decription: Use case ini menggambarkan proses cari data. Sumber data berupa data data supllier.

Precondition: Admin telah melalui proses login.

(61)

41

Nama Use case : Tambah Data Supplier. Typical Course

of event:

Actor Action System Response

Step 1: Admin mengklik menu CARI.

Step 2: Sistem menampilkan form data supplier.

Alternate Course:

Conclusion: Postcondition: Business Rules: Implementation Constrains and Specifications:

Tampilan sistem berupa web yang akan mempermudah Admin untuk mencari data.

Assumptions: -

Open issues: Keakuratan data tidak terjamin jika admin harus mencari data yang dimaksud hanya dengan menggunakan kumpulan dokumen-dokumen data toko.

Author : Untung S

Date :

Version : 1.0

Use-case Name: Tambah Data Supplier Jenis Use-Case

Use-case ID: InptDS Business

Requirements: ฀ Priority : High

Source: Formulir data supllier. Primary

Business Actor:

(62)

42

Decription: Use case ini menggambarkan proses penginputan data. Sumber input data berupa data supplier.

Precondition: Admin telah melalui proses login.

Trigger: Use case ini akan digunakan apabila ada interaksi pengisian formulir data supllier.

Typical Course of event:

Actor Action System Response

Step 1: Admin mengklik menu TAMBAH.

Step 3: Admin memasukkan data yang ingin diinputkan. Step 5: Admin mengklik tombol SIMPAN.

Step 2: Sistem menampilkan form tambah data.

Step 4: Sistem memperoleh mengklik tombol BATAL.

Alt-Step 6: Jika data yang diinputkan tidak berhasil, maka sistem akan memberikan peringatan.

Conclusion: Use case ini berhenti apabila tidak ada data yang diinputkan lagi.

Postcondition:  Data berhasil ditambahkan ke database.

 Data tidak berhasil ditambahkan ke database. Business Rules: Admin harus memasukkan data dengan tipe yang sesuai. Implementation

Constrains and Specifications:

Tampilan sistem berupa web yang akan mempermudah admin untuk menginputkan data.

Assumptions: -

(63)

43

Nama Use case : Edit Data Supplier.

memasukkannya secara manual dengan

mencatat/mendokumentasikan ke dalam buku.

Author : Untung S

Date :

Version : 1.0

Use-case Name: Edit Data Supllier Jenis Use-Case

Use-case ID: UpdtDS Business

Requirements: ฀ Priority : High

Source: Formulir data supllier. Primary

Business Actor:

Admin

Other

Participating Actor:

-

Other Interested Stakeholder:

-

Decription: Use case ini menggambarkan proses update data. Data yang diupdate dapat berupa data supllier. Update data dapat dilakukan secara berkala.

Precondition: Admin telah melalui proses login.

Trigger: Use case ini akan digunakan apabila ada interaksi pengisian formulir data supllier.

Typical Course of event:

Actor Action System Response

Step 1: Admin mengklik menu EDIT.

Step 2: Sistem menampilkan

(64)

44 bahwa data berhasil diubah.

Alternate Course:

Alt-Step 5: Admin tidak jadi mengubah data dengan mengklik tombol BATAL.

Alt-Step 6: Jika data yang diubah tidak berhasil, maka sistem akan memberikan peringatan.

Conclusion: Use case ini akan berhenti apabila tidak ada data yang harus diubah.

Postcondition:  Data berhasil diubah dan disimpan ke database.

 Data tidak berhasil diubah.

Business Rules: Admin harus memasukkan data dengan tipe yang sesuai dengan tipe data yang akan diubah.

Implementation Constrains and Specifications:

Tampilan sistem berupa web yang dilengkapi dengan fitur pencarian data, kemudian data dapat diubah sesuai dengan tipe data.

Assumptions: -

Open issues: Data yang diubah dengan menggunakan buku, tidak dapat langsung ter-update apabila admin ingin mengubahnya.

Author : Untung S

Date :

Version : 1.0

(65)

45

Use-case ID: DltDS Business

Requirements: ฀ Priority : High

Source: Data yang sudah tersimpan. Primary

Decription: Use case ini menggambarkan proses penghapusan data. Data yang dihapus dapat berupa data supllier. Penghapusan data dilakukan apabila data yang sudah tidak diperlukan lagi. Precondition: Admin telah melalui proses login.

Trigger: Use case ini digunakan apabila ada data yang di dalam sistem sudah tidak diperlukan lagi.

Typical Course of event:

Actor Action System Response

Step 1: Admin mengklik menu HAPUS.

Step 3: Admin mengklik tombol HAPUS.

Step 2: Sistem menampilkan data yang ingin dihapus. Step 4: Sistem memberitahu bahwa data berhasil dihapus.

Alternate Course:

Alt-Step 3: Admin mengklik tombol BATAL, sehingga sistem tidak jadi menghapus data yang dipilih(kembali ke menu utama).

Alt-Step 4: Jika telah berhasil dihapus, maka sistem akan memberikan peringatan.

Conclusion: Use case ini berhenti apabila semua data yang diinginkan telah berhasil dihapus.

Postcondition:  Data berhasil dihapus dari database.

(66)

46

Nama Use case : Tambah Data User.

database.

Business Rules: Admin harus menghapus data dengan data yang sesuai dengan data yang ingin dihapus.

Implementation Constrains and Specifications:

Tampilan sistem berupa web yang dilengkapi dengan fitur pencarian data, kemudian data yang ditemukan tersebut dapat langsung dihapus.

Assumptions: -

Open issues: Pencarian data yang lama dan tidak terlalu akurat membuat admin harus berulang-ulang kali memastikan data tersebut memang data yang ingin dihapus.

Author : Untung S

Date :

Version : 1.0

Use-case Name: Tambah Data User Jenis Use-Case

Use-case ID: InptDC Business

Requirements: ฀ Priority : Medium

Source: Formulir data user. Primary

Business Actor:

Admin

Other

Participating Actor:

-

Other Interested Stakeholder:

-

(67)

47

Sumber input data berupa data user. Precondition: Admin telah melalui proses login.

Trigger: Use case ini akan digunakan apabila ada interaksi pengisian formulir data user.

Typical Course of event:

Actor Action System Response

Step 1: Admin mengklik menu TAMBAH.

Step 3: Admin memasukkan data yang ingin diinputkan. Step 5: Admin mengklik tombol SIMPAN.

Step 2: Sistem menampilkan form tambah data user.

Step 4: Sistem memperoleh mengklik tombol BATAL.

Alt-Step 6: Jika data yang diinputkan tidak berhasil, maka sistem akan memberikan peringatan.

Conclusion: Use case ini berhenti apabila tidak ada data yang diinputkan lagi.

Postcondition:  Data berhasil ditambahkan ke database.

 Data tidak berhasil ditambahkan ke database. Business Rules: Admin harus memasukkan data dengan tipe yang sesuai. Implementation

Constrains and Specifications:

Tampilan sistem berupa web yang akan mempermudah admin untuk menginputkan data.

Assumptions: -

Open issues: Keakuratan data tidak terjamin jika admin harus

memasukkannya secara manual dengan

(68)

48

Use-case ID: UpdtDU Business

Requirements: ฀ Priority : Medium

Source: Formulir data user. Primary

Decription: Use case ini menggambarkan proses update data. Data yang diupdate berupa data user. Update data dapat dilakukan secara berkala.

Precondition: Admin telah melalui proses login.

Trigger: Use case ini akan digunakan apabila ada interaksi pengisian formulir data user.

Typical Course of event:

Actor Action System Response

Step 1: Admin mengklik form EDIT DATA USER. Step 4: Sistem memperoleh data baru.

(69)

49

Nama Use case : Hapus Data User.

tombol SIMPAN. Alternate

Course:

Alt-Step 5: Admin tidak jadi mengubah data dengan mengklik tombol BATAL.

Alt-Step 6: Jika data yang diubah tidak berhasil, maka sistem akan memberikan peringatan.

Conclusion: Use case ini akan berhenti apabila tidak ada data yang harus diubah dan ditambahkan.

Postcondition:  Data berhasil diedit dan disimpan ke database.

 Data tidak berhasil diedit.

Business Rules: Admin harus memasukkan data dengan tipe yang sesuai dengan tipe data yang akan diedit.

Implementation Constrains and Specifications:

Tampilan sistem berupa web yang dilengkapi dengan fitur pencarian data, kemudian data yang ditemukan tersebut dapat langsung diubah.

Assumptions: -

Open issues: Data yang diubah dengan menggunakan buku, tidak dapat langsung ter-update apabila admin ingin mengubahnya.

Author : Untung S

Date :

Version : 1.0

Use-case Name: Hapus Data user Jenis Use-Case

Use-case ID: DltDU Business

Requirements: ฀ Priority : High

Source: Data yang sudah tersimpan.

(70)

50

Decription: Use case ini menggambarkan proses penghapusan data. Data yang dihapus berupa data user. Penghapusan data dilakukan apabila data yang sudah tidak diperlukan lagi. Precondition: Admin telah melalui proses login.

Trigger: Use case ini digunakan apabila ada data yang di dalam sistem sudah tidak diperlukan lagi.

Typical Course of event:

Actor Action System Response

Step 1: Admin mengklik menu HAPUS.

Step 3: Admin mengklik tombol HAPUS.

Step 2: Sistem menampilkan data yang ingin dihapus. Step 4: Sistem memberitahu bahwa data berhasil dihapus.

Alternate Course:

Alt-Step 3: Admin mengklik tombol BATAL, sehingga sistem tidak jadi menghapus data yang dipilih(kembali ke menu utama).

Alt-Step 4: Jika telah berhasil dihapus, maka sistem akan memberikan peringatan.

Conclusion: Use case ini berhenti apabila semua data yang diinginkan telah berhasil dihapus.

Postcondition:  Data berhasil dihapus dari database.

 Data tidak berhasil dihapus dan tetap berada di dalam database.

Business Rules: Admin harus menghapus data dengan data yang sesuai dengan data yang ingin dihapus.

Implementation Constrains and

Gambar

Gambar 2. 1. Skema PHP
Gambar 2.3. Client/Server Database
gambar 2.5. (Whitten, 2004).
Gambar 2.6. Penyimpanan Data (Data Store)
+7

Referensi

Dokumen terkait

Pendidikan Agama Kristen haruslah mengajarkan kepada peserta didik pada keterbukaan. Keterbukaan akan membawa diri dari menjelek-jelekkan agama lain

Keberhasilan pelaksanaan kegiatan Diseminasi Produk Teknologi ke Masyarakat, Ditjen Risbang (Direktorat Penguatan Riset dan Pengembangan) dapat dicapai melalui koordinasi

Artinya bahwa dengan terpenuhinya kebutuhan pegawai, khususnya para bidan melalui kebijakan tunjangan fungsional yang mereka terima dari pimpinan organisasi akan

Sistematika proposal biasanya terdiri atas: (1) bagian awal, yakni halaman judul, halaman pengesahan, dan abstrak; (2) bagian pendahuluan, yakni latar belakang

Pelayanan farmasi meliputi penyediaan dan distribusi semua pembekalan farmasi termasuk pemberian informasi yang dapat menjamin kualitas pelayanan yang berhubungan

Berdasarkan latar belakang diatas maka dalam penelitian ini dapat dirumuskan masalah sebagai berikut: Apakah dengan diterapkannya model pembelajaran group

Perbedaan skripsi ini dengan skripsi yang penulis bahas adalah skripsi di atas hanya menjelaskan tentang kecocokan teori al-Qur‘an dengan teori biologi, tapi

Berdasarkan hasil penelitian dan pembahasan, dan disimpulkan secara komprehensif bahwa pendapatan rata-rata setiap bulan petani penyadap karet di desa Pangkal Baru