skripsi -...

RANCANG BANGUN SISTEM INFORMASI ADMINISTRASI

PEMBELIAN BARANG PADA PT. BANK ANZ INDONESIA

SKRIPSI

OLEH:

MUHAMMAD AUDRI AL KAISAR

207093000299

PROGRAM STUDI SISTEM INFORMASI

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH

JAKARTA

2014

Rancang Bangun Sistem Informasi Administrasi Pembelian Barang

Pada PT Bank ANZ Indonesia

Skripsi

Sebagai Salah Satu Syarat Untuk Memperoleh Gelar

Sarjana Sistem Informasi (S.SI)

Oleh:

Muhammad Audri Al Kaisar

NIM : 207093000299

PROGRAM STUDI SISTEM INFORMASI

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS ISLAM NEGERI (UIN) SYARIF HIDAYATULLAH

JAKARTA

2014 M/1435 H

PERNYATAAN

DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENAR-

BENAR HASIL KARYA SENDIRI YANG BELUM PERNAH DIAJUKAN

SEBAGAI SKRIPSI ATAU KARYA ILMIAH PADA PERGURUAN TINGGI

ATAU LEMBAGA MANAPUN.

Jakarta, Agustus 2014


ABSTRAK

MUHAMMAD AUDRI AL KAISAR, Rancang Bangun Sistem Informasi

administrasi Pembelian Barang pada PT.BANK ANZ INDONESIA dibawah

bimbingan NUR AENI H dan RINDA HESTI K.

PT BANK ANZ INDONESIA merupakan suatu badan usaha yang bergerak

dalam bidang Perbankan. berdasarkan observasi di lapangan pendataan

Pemesanan Barang Diperusahaan ini masih Belum memenuhi kriteria yang ada

dikarenakan Proses yang sangat memakan waktu lama, seperti halnya pelaporan,

pembelian barang dan pemesanan barang, dan masih menggunakan media kertas

yang digunakan sebagai media untuk arsip data sehingga membutuhkan banyak

tempat untuk menyimpan arsip-arsip tersebut dan lamanya dalam pencarian data

dalam Laporan pemesanan. Rancang bangun sistem informasi pemesanan

Pembelian Barang ini menggunakan Metode RAD (Rapid Application

Development) dan tools UML (Unified Model Language) dengan use case

diagram, activity diagram, sequence diagram dan class diagram serta

menggunakan bahasa pemrograman PHP dan MySQL sebagai database. Sistem

informasi pemesanan Barang ini yang dibuat agar dapat meminimalisir kesalahan

di dalam melakukan Rekap data Tahunan melihat ketersedian barang, pembayaran

dan pembuatan laporan sehingga dapat membantu kegiatan operasional, dan

memudahkan manager dalam melihat laporan transaksi yang dilakukan oleh

perusahaan.

Kata Kunci: PT Bank ANZ Indonesia, Sistem Informasi administrasi Pembelian

Barang, Rapid Application Development, Unified Modeling Language, PHP dan

MySql.

V BAB + XIX HALAMAN + 134 HALAMAN + 44 GAMBAR + 22 TABEL

KATA PENGANTAR

Puji syukur peneliti panjatkan kehadirat Allah SWT karena atas berkat dan

rahmat-Nya peneliti dapat melaksanakan dan menyelesaikan penulisan skripsi

dengan judul “Rancang Bangun Sistem Informasi Pencatatan Pembelian Barang

Pada PT BANK ANZ INDONESIA” dengan baik. Shalawat serta salam penulis

curahkan kepada junjungan dan suri tauladan kita Nabi Muhammad SAW, yang

telah membawa cahaya yang terang benderang ke muka bumi ini, dan juga kepada

keluarga para sahabatnya beserta alim ulama yang senantiasa meneruskan ajaran

Islam sebagai penerang jalan kehidupan hingga akhir zaman.

Pada kesempatan ini, penulis ingin mengucapkan terimakasih kepada

seluruh pihak yang telah membantu baik moril maupun materil dalam

menyelesaikan skripsi ini, terutama kepada:

1. Bapak DR. Agus Salim, M.Si, selaku Dekan Fakultas Sains dan Teknologi

UIN Syarif Hidayatullah Jakarta.

2. Bapak Zulfiandri, MMSI selaku Ketua Program Studi Sistem Informasi dan

Ibu Nia Kumaladewi, MMSI selaku Sekretaris Program Studi Sistem

Informasi Fakultas Sains dan Teknologi Universitas Islam Negeri (UIN)

Syarif Hidayatullah Jakarta.

3. Nur Aeni Hidayah, MMSI. dan Ibu Rinda Hesti K, MMSI selaku Dosen

Pembimbing I dan Dosen Pembimbing II yang telah banyak memberikan

ilmu, waktu, motivasi dan bimbingan serta kesabarannya selama proses

penyusunan skripsi.

4. Seluruh Dosen dan Staff program Studi Sistem Informasi, Fakultas Sains dan

Teknologi, yang telah berjasa kepada penulis selama diperkuliahan.

5. Bapak Kurnia Akbar dan seluruh pegawai Bagian PCO yang tidak bisa

disebutkan satu persatu yang telah membantu saya untuk melakukan penelitian

dan memberikan data-data yang saya butuhkan untuk penelitian di PT Bank

ANZ Indonesia.

6. Bapak Santoso dan Ibu Tuty Alawiyah sebagai orangtua tercinta, yang telah

mendoakan dan mendukung peneliti baik moril maupun materil. Serta Kakak -

adikku tercinta Adam, Keka, Aan, yang telah membuat penulis bersemangat

menyelesaikan skripsi ini. Terima kasih atas doa dan semangatnya.

7. Keluarga besar kekasih tercinta Natasya Alfiani yang juga banyak

memberikan semangat dan motivasi kepada penulis selama pembuatan skripsi

ini.

8. Serta teman-teman kelas SI–A, SI-B 2007 & 2008, untuk perjuangannya

bersama penulis selama ini.

9. Pihak-pihak lain yang tidak dapat disebutkan satu persatu yang telah

membantu baik secara langsung maupun tidak langsung, demi selesainya

skripsi ini.

Penulis sadar bahwa penulisan skripsi ini masih jauh dari sempurna, oleh

karena itu saran dan kritik dapat disampaikan melalui email :

[email protected]

Akhir kata, penulis berharap skripsi ini bermanfaat bagi para pembaca.

Aamiin.

mailto:[email protected]

Wassalamu’alaikum wr, wb

Jakarta, 29Agustus 2014


NIM : 207093000299

DAFTAR ISI

BAB I PENDAHULUAN ...................................................................................... 1

1.1 Latar Belakang ............................................................................... 1

1.2 Identifikasi Masalah....................................................................... 3

1.3 Rumusan Masalah .......................................................................... 3

1.4 Batasan Masalah ............................................................................ 3

1.5 Tujuan dan Manfaat Penelitian ...................................................... 5

1.5.1 Tujuan Penelitian ............................................................... 5

1.5.2 Manfaat Penelitian ............................................................. 5

1.6 Metode Penelitian .......................................................................... 6

1.7 Sistematika Penulisan .................................................................... 9

BAB II LANDASAN TEORI ................................................................................. 10

2.1 Rancang Bangun ............................................................................ 10

2.1.1 Rancang ............................................................................. 10

2.1.2 Bangun ............................................................................... 10

2.2 Konsep Dasar Sistem ..................................................................... 10

2.2.1 Pengertian Sistem .............................................................. 11

2.2.1.1 Karakteristik Sistem............................................. 12

2.3 Konsep Dasar Informasi ................................................................ 15

2.4 Konsep Dasar Sistem Informasi .................................................... 16

2.5 Pengertian Administrasi................................................................. 19

2.6 Pengertian Pembelian .................................................................... 20

2.7 Teori Rapid Application Development (RAD) .............................. 21

2.7.1 Pengertian Rapid Application Development (RAD) .......... 21

2.7.2 Unsur-Unsur Penting RAD ................................................ 24

2.7.3 Tahap-tahap Pengembangan Sistem .................................. 25

2.8 Unified Modeling Language (UML) .............................................. 29

2.8.1 Sejarah UML ...................................................................... 29

2.8.2 Kegunaan UML ................................................................. 30

2.8.2.1 Diagram-diagram dan Notasi UML ..................... 31

2.9 Konsep Aplikasi Sistem dan Database ................................................. 40

2.9.1 PHP .................................................................................... 40

2.9.2 MySQL .............................................................................. 41

2.9.2.1 Tipe Data Numeric ............................................... 41

2.9.2.2 Tipe Data String ................................................... 42

2.9.2.3 Tipe Data Date ..................................................... 43

2.9.3 Rich Picture ....................................................................... 44

2.9.4 XAMPP .............................................................................. 45

2.9.5 phpMyAdmin ...................................................................... 45

2.9.6 Adobe Dreamweaver .......................................................... 46

2.10 Testing ........................................................................................... 48

2.10.1 Black Box Testing .............................................................. 48

BAB III METODDOLOGI PENELITIAN ............................................................ 54

3.1 Metode Pengumpulan Data............................................................ 54

3.1.1 Studi Pustaka ...................................................................... 54

3.1.2 Studi Lapangan .................................................................. 54

3.2 Metode Pengembangan Sistem ...................................................... 56

3.2.1 Investigasi Awal ................................................................ 56

3.2.2 Analisa Sistem ................................................................... 56

3.2.3 Desain Sistem .................................................................... 57

3.2.4 Desain Database ................................................................. 59

3.2.5 Desain Interface ................................................................. 59

3.2.5 Pengujian Penerapan Sistem .............................................. 59

3.3 Kerangka Berpikir ......................................................................... 61

BAB IV ANALISIS DAN PERANCANGAN SISTEM ........................................ 62

4.1 PT. Bank ANZ Indonesia .............................................................. 62

4.2 Uraian Prosedur ............................................................................. 63

4.2.1 Proses Pemesanan Barang ............................................... 63

4.2.2 Proses Terima Barang ...................................................... 64

4.2.3 Proses Pembayaran Barang ............................................. 64

4.2.4 Proses Pembuatan Laporan .............................................. 64

4.3 Analisa Sistem Berjalan ................................................................. 65

4.4 Identifikasi Masalah....................................................................... 66

4.4.1 Requirements Analysis ....................................................... 67

4.4.1.1 Functional Requrement ....................................... 67

4.4.1.2 Nonfunctional Requirement ................................. 68

4.4.2 Analisa Keputusan ............................................................. 68

4.5 Sistem Usulan ................................................................................ 69

4.6 Perancangan Sistem ....................................................................... 70

4.6.1 Perancangan Proses desain ................................................ 70

4.6.1.1 Use Case Modeling Diagram .............................. 70

4.6.1.1.1 Identifikasi Actor ................................. 70

4.6.1.1.2 Identifikasi Use Case .......................... 71

4.7 Use Case Diagram ......................................................................... 72

4.8 Use Case Narative ......................................................................... 73

4.9 Activity Diagram ........................................................................... 81

4.10 Sequence Diagram ......................................................................... 82

4.11 Class Diagram ............................................................................... 93

4.12 Boundary Class .............................................................................. 94

4.13 Rancangan Keluaran ...................................................................... 95

4.12 Rancangan Basis Data ................................................................... 102

4.12.1 Entity Relationsship Diagram ......................................... 102

4.12.2 Transformasi ERD Ke LRS .............................................. 106

4.12.3 Logical Record Structure ................................................ 081

4.12.4 Normalisasi ...................................................................... 109

4.13 desain Interface .............................................................................. 129

4.13.1 Rancangan Layar ............................................................. 129

4.14 Pemrograman ................................................................................. 132

4.14.1 Pengujian Sistem ............................................................. 133

BAB V PENUTUP ..................................................................................................... 134

5.1 Kesimpulan ................................................................................... 135

5.2 Saran ............................................................................................. 135

DAFTAR PUSTAKA

LAMPIRAN

LAMPIRAN II

LAMPIRAN III

LAMPIRAN IV

LAMPIRAN V

DAFTAR GAMBAR

Gambar 2.1 Contoh Rich Picture Sistem informasi Administrasi ................... 42

Gambar 2.2 Konfigurasi XAMPP .................................................................... 43

Gambar 2.3 Halaman Utama phpMyAdmin ..................................................... 44

Gambar 2.4 Ruang Kerja Adobe Dreamweaver CS3 ....................................... 45

Gambar 3.1 Kerangka Penelitian ..................................................................... 57

Gambar 4.1 Struktur Organisasi PT. Bank ANZ Indonesia – Payment

& Cash Operation (PCO) .............................................................. 61

Gambar 4.2 Rich Picture Sistem Berjalan ....................................................... 64

Gambar 4.3 Rich Picture Sistem Usulan ......................................................... 69

Gambar 4.4 Use Case Diagram Sistem Pembelian PT. Bank ANZ

Indonesia ...................................................................................... 73

Gambar 4.5 Activity Diagram login ................................................................. 81

Gambar 4.6 Sequence DiagramEntry Data Barang ......................................... 82

Gambar 4.7 Sequence DiagramEntry Data Supplier ....................................... 83

Gambar 4.8 Sequence DiagramEntry Data Pegawai ....................................... 84

Gambar 4.9 Sequence Diagram Cetak Surat Pesan ......................................... 85

Gambar 4.10 Sequence DiagramEntryTanda Terima Barang ........................... 86

Gambar 4.11 Sequence Diagram Cetak Bukti Bayar ........................................ 87

Gambar 4.12 Sequence Diagram Cetak Retur ................................................... 88

Gambar 4.13 Sequence Diagram Cetak Laporan Pesanan ................................ 89

Gambar 4.14 Sequence Diagram Cetak Laporan Penerimaan ........................... 90

Gambar 4.15 Sequence Diagram Cetak Laporan Pembayaran ......................... 91

Gambar 4.16 Sequence Diagram Cetak Retur .................................................. 92

Gambar 4.17 Entry Class ................................................................................... 93

Gambar 4.18 Boundary Class ............................................................................ 94

Gambar 4.19 Control Class ............................................................................... 95

Gambar 4.20 Struktur Tampilan ...................................................................... 102

Gambar 4.21 Entitas yang terlibat dalam sistem.............................................. 103

Gambar 4.22 Entitas dan atribut-atribut ........................................................... 104

Gambar 4.23 Entity Relationship Diagram...................................................... 105

Gambar 4.24 Transformasi ERD ke LRS ........................................................ 107

Gambar 4.25 Logical Record Structure ........................................................... 108

Gambar 4.26 Diagram ketergantungan secara fungsional pada relasi

Pegawai ...................................................................................... 109


Pesan .......................................................................................... 110


Barang ........................................................................................ 111

Gambar 4.29 Diagram ketergantungan secara fungsional pada relasi SP ........ 112


Supplier ...................................................................................... 113

Gambar 4.31 Diagram ketergantungan secara fungsional pada relasi TTB .... 114

Gambar 4.32 Diagram ketergantungan secara fungsional pada relasi Retur ... 115

Gambar 4.33 Diagram ketergantungan secara fungsional pada relasi Bukti

Bayar .......................................................................................... 116


Kembali ...................................................................................... 117

Gambar 4.35 Rancangan Layar Form Menu Utama .......................................... 128

Gambar 4.36 Rancangan Layar Sub Menu File Master ..................................... 129

Gambar 4.37 Rancangan Layar Entry Data Barang ........................................... 129

Gambar 4.38 Rancangan Layar Entry Data Supplier ......................................... 130

Gambar 4.39 Rancangan Layar Entry Data Pegawai ......................................... 130

DAFTAR TABEL

Tabel 2.1 KlasifikasiPIECES pada kebutuhan sistem menurut Whitten (2007) ........ 24

Tabel 2.2 Simbol-simbol Use Case Diagram .................................................... 29

Tabel 2.3 Simbol-simbol Activiti Diagram ....................................................... 30

Tabel 2.4 Simbol-simbol Squence Diagram ..................................................... 34

Tabel 2.5 Simbol-simbol Class Diagram ......................................................... 37

Tabel 2.6 Contohtipe data Numeeric ................................................................ 39

Tabel 2.7 Contohtipe data String ...................................................................... 41

Tabel 2.8 Contohtipe data date ......................................................................... 42

Tabel 2.9 Contoh Tabel Pengujian Black Box .................................................. 49

Tabel 2.10 Perbandingan Black Box Testing dengan White Box Testing ........... 50

Tabel 4.1 Nonfunctional Requirement .............................................................. 67

Tabel 4.2 Identifikasi Actor .............................................................................. 70

Tabel 4.3 Spesifikasi Tabel Pegawai .............................................................. 118

Tabel 4.4 Spesifikasi Tabel Pesan .................................................................. 119

Tabel 4.5 Spesifikasi Tabel Barang ................................................................ 120

Tabel 4.6 Spesifikasi Tabel Surat Pesan ......................................................... 121

Tabel 4.7 Spesifikasi Tabel Supplier .............................................................. 122

Tabel 4.8 Spesifikasi Tabel TTB .................................................................... 123

Tabel 4.9 Spesifikasi Tabel Retur ................................................................... 124

Tabel 4.10 Spesifikasi Tabel Bukti Bayar ........................................................ 125

Tabel 4.11 Spesifikasi Tabel Kembali .............................................................. 126

Tabel 4.12 Tabel Kebutuhan Simpanan Basis Data .......................................... 127

Tabel 4.13 Tabel Estimasi Kebutuhan Simpanan Data ....................................... 128

Daftar Simbol UML

1. Use Case Diagram

Simbol-simbol Use Case Diagram

Simbol Keterangan

Actor1

Actor

UseCase1

Use case

* *

Association

«extends»

Extends

«uses»

Uses (includes)

System

System Boundary

(Sumber: Munawar, 2005)

2. Activity Diagram

Simbol-simbol Activity Diagram

Simbol Keterangan

State1

State

Control Flow

Initial State

Final State

Transition

Decision


3. Sequence Diagram

Simbol-simbol Sequence Diagram

Simbol Keterangan

Actor

Boundary

Entity

Message1

Message

Message2

Message return

Activation

(Sumber: Wahono, 2011)

4. Class Diagram

Actor

Boundary

Entity

Simbol-simbol Class Diagram

Simbol Keterangan

Class1

2

3

Class

1. Class name

2. Attributes

3. Behaviours

Association

Generalization


1

BAB I

PENDAHULUAN

1.1 Latar Belakang

Dewasa ini, teknologi informasi berkembang sangat pesat. Hal ini dapat

dilihat dari banyaknya pengguna komputer di berbagai bidang. Banyak perusahaan

yang menggunakan komputer untuk melakukan kegiatan operasionalnya. Perusahaan

yang telah menerapkan komputerisasi memiliki keunggulan kompetitif dibandingkan

dengan perusahaan yang masih menggunakan manual, sebab manajemen operasional

akan lebih baik bila menggunakan komputerisasi.

Oleh karena itu, peranan sistem informasi yang terkomputerisasi sangat

dibutuhkan oleh setiap instansi baik pemerintah maupun swasta yang bergerak

dibidang perbankan agar dapat melakukan transaksi dengan cepat dan mudah. Dengan

berkembangnya teknologi komputer yang semakin pesat, membawa dampak kemajuan

pengolahan data serta kebutuhan akan informasi yang dapat dilakukan secara efisien

dan efektif untuk mendukung pengambilan keputusan. Salah satu faktor penunjang

kelancaran operasional suatu perusahaan adalah penggunaan barang, untuk itu

diperlukan sistem pencatatan pembelian barang yang efektif dan efisien.

Dikarenakan sistem yang digunakan untuk pencatatan PT. Bank ANZ

Indonesia kurang praktis karena masih dilakukan secara semi terkomputerisasi yang

di mana pengolahan datanya masih di simpan dalam bentuk Microsoft excel sehingga

masih terjadi kesalahan dan ketidak akuratan dalam pencarian data dan tidak efektif

2

dalam pembuatan laporan serta memakan waktu yang lama. Permasalahan lainnya

adalah dalam melakukan kontrol terhadap pembeliaan barang dari supplier dan

kontrol terhadap pemakaian barang di PT. Bank ANZ Indonesia.

Sistem pembelian yang dilakukan PT. Bank ANZ Indonesia seringkali

mengalami masalah, dikarenakan sistem yang berlaku masih semi terkomputerisasi.

Adapun masalah yang dihadapi oleh PT. Bank ANZ Indonesia pada sistem

pencatatan pembelian Barang adalah:

a. Proses dikerjakan dalam waktu yang cukup lama karena banyaknya pekerjaan

yang harus dilakukan secara manual seperti pencatatan, perhitungan, pengecekan

ataupun proses pemeriksaan yang membutuhkan ketelitian.

b. Banyaknya arsip-arsip yang membutuhkan banyak tempat penyimpanan untuk

setiap transaksi jual beli.

c. Lambatnya informasi yang diterima oleh pihak manajemen untuk membuat

laporan kepada pimpinan, karena pembuatan laporan tersebut tidak otomatis terjadi

pada saat transaksi.

Untuk itu penyusun mencoba membuat rancangan sistem informasi dari

permasalahan yang sederhana dengan mengambil judul, “Rancang Bangun Sistem

Informasi Administrasi Pembelian Barang Pada PT. Bank ANZ Indonesia”,

yang bertempat di Jl. Jend Sudirman Kav 33A, Jakarta dengan menggunakan PHP

untuk Program dah MySQL untuk database.

3

1.2 Identifikasi Masalah

Adapun identifikasi masalah berdasarkan latar belakang yang telah

diuraikan adalah sebagai berikut:

1. Sistem pencatatan pembelian barang yang ada saat ini masih manual, sehingga

memakan waktu sampai dengan 3 jam waktu kerja.

2. sering terjadi masalah human error dalam hal pengolahan data Barang,

pemesanan barang yang masih berbentuk data arsip dan belum tersimpan

dalam satu database yang terkomputerisasi sehingga membuat data tercecer.

1.3 Rumusan Masalah

Adapun rumusan masalah dibuatnya Rancang Bangun Sistem Informasi

pencatatan Pembelian Barang pada PT. Bank ANZ Indonesia ini dimaksudkan untuk:

a. Bagaimana membuat aplikasi yang dapat membantu perusahaan dalam

penyimpanan data yang terkomputerisasi ?

b. Bagaimana Cara mengatasi human error dalam hal pengolahan data Barang,

pemesanan barang yang masih berbentuk data arsip ?

1.4 Batasan Masalah

Dengan mengamati uraian pada perumusan masalah, maka akan terlihat

banyak entitas yang saling berhubungan. Namun sesuai dengan judul yang akan

disajikan, maka penulis membatasi permasalahan yang terkait dengan Administrasi

pembelian barang yang meliputi :

4

Penulis membatasi ruang lingkup penelitian agar tidak memperluas

permasalahan, yaitu khusus pada :

a. Tidak mengakomodir keamanan data, jaringan dan pemeliharaan sistem.

b. Didalam Penulisan Skripsi ini hanya meliputi penginputan data

Barang,Pencatatan ketersediaan Barang, dan laporan barang

c. Tidak meliputi data laporan keuangan akhir.

d. Sistem yang akan dikembangkan oleh penulis akan di terapkan atau

digunakan oleh staff PCO (Payment Cash Operation) PT.Bank ANZ

Indonesia

e. Metode yang digunakan Penulis dalam Perancangan menggunakan RAD

(Rapid Application Development) dengan menggunakan Diagram UML

(Unified Model Language) untuk menggambarkan proses-proses yang ada di

dalam sistem.

f. Tools yang akan digunakan Penulis untuk membuat aplikasi dengan

menggunakan PHP dan untuk Database menggunakan MySQL

1.5 Tujuan Dan Manfaat Penelitian

1.5.1 Tujuan Penelitian

Tujuan yang ingin dicapai dari penelitian ini adalah :

a. Memberikan solusi atas permasalahan yang ada, yaitu

menyediakan suatu sistem informasi Administrasi Pembelian

barang di PT. Bank ANZ Indonesia

5

b. Agar dapat menyajikan informasi Pembelian Barang yang

mudah.

c. Sistem informasi ini diharapkan dapat bermanfaat khususnya

bagi Staf PCO (Payment Cash Operation)

1.5.2 Manfaat Penulisan

a. Bagi Universitas

Penulisan ini diharapkan dapat menambah referensi tentang kajian

sistem informasi Administrasi Pembelian barang.

b. Bagi Perusahaan

Penulisan ini diharapkan dapat menghemat waktu pengerjaan dan

tenaga, juga dapat memberikan kerja yang baik dalam proses

pengolahan data itu sendiri dan dapat mengembangkan sistem

dikemudian harinya sehingga lebih baik lagi data yang akan

dihasilkan nantinya.

c. Bagi Penulis

Penulis lebih mengerti tentang teori-teori yang telah diterima

sekaligus mematangkan dan meningkatkan pengetahuan tentang

sistem Pencatatan Barang, menyerap ilmu yang ada serta menjalin

silaturahmi dengan karyawan Bank Anz.

1.6 Metode Penelitian

Metodologi penelitian merupakan suatu kerangka dan asumsi yang ada dalam

melakukan elaborasi penelitian. Dalam menganalisa dan merancang sistem informasi

6

administrasi Pembelian Barang ini penulis menggunakan 2 (dua) metodologi

penelitian, yaitu:

1. Metodologi Pengumpulan Data

Dalam pengumpulan data penulis melakukan 3 (tiga) hal, yaitu:

a) Studi pustaka

adalah semua bahan yang diperoleh berasal dari buku-buku atau jurnal.

b) Studi Lapangan

Studi lapangan adalah pengambilan data langsung dari lokasi penelitian.

Dalam studi lapangan ini, penulis melakukan 2 (dua) kegiatan yang

dilakukan dalam mengumpulkan data, yaitu:

1) Observasi / pengamatan

Observasi merupakan suatu penelitian yang dilakukan untuk

memahami sebuah fenomena berdasarkan gagasan atau

pengetahuan yang telah diketahui sebelumnya.

2) Interview/wawancara

Teknik pengumpulan data dilakukan dengan menggunakan

wawancara yang berupa tanya jawab peneliti dengan responden

(narasumber).

c) Studi Literatur Sejenis

Studi literatur berisi tentang teori, temuan dan bahan penelitian lain yang

sama, diperoleh dari bahan acuan untuk dijadikan landasan kegiatan

penelitian.

7

2. Metodologi Pengembangan Sistem

Dalam perancangan sistem ini penulis akan menganalisa mulai dari sistem

yang berjalan sampai sistem yang akan diusulkan menggunakan konsep

Object Oriented dengan metode RAD (Rapid Application Development) dari

McLeod & Schell (2008) dan dengan diagram UML (Unified Model

Language) untuk memperlihatkan aliran proses dan data pada sistem yang

akan dirancang. Berikut adalah alur metode RAD yang digunakan penulis

dalam pengembangan sistem ini:

1. Investigasi Awal

Pada tahap ini, penulis dan Staff PCO melakukan pertemuan untuk

menggambarkan permasalahan, menentukan ruang lingkup

pengembangan sistem, mengidentifikasi tujuan dari sistem dan

kebutuhan informasi untuk mencapai tujuan.

2. Analisis

Pada tahap ini, penulis menjabarkan tentang permasalahan yang terjadi

pada sistem yang sedang berjalan untuk memperbaiki sistem yang lama.

Dalam tahap analisis sistem ini terdapat tiga tahapan, yaitu:

a. Problem Analysis, mempelajari bagaimana sistem informasi

pencatatan pembelian barang yang telah berjalan dan

mendefinisikan masalah-masalah yang terdapat di dalamnya.

b. Requirement Analysis, menganalisis kebutuhan apa saja yang

diperlukan dalam permasalahan sistem informasi administrasi

8

pembelian barang.

c. Decision Analysis, menentukan solusi yang akan digunakan dalam

mengatasi masalah sistem informasi Administrasi pembelian Barang

yang digambarkan dalam Rich Picture sistem usulan.

3. Desain

Merancang komponen baik desain proses, desain input / ouput, desain

database, desain struktur menu, serta desain interface dari sistem

informasi pencatatan pemelian barang pada PT. Bank ANZ Indonesia

dan kemudian mendokumentasikan desain dengan menggunakan

berbagai jenis teknik pemodelan.

4. Testing

Komponen-komponen sistem informasi Administrasi pembelian barang

pada PT Bank ANZ Indonesia belum sampai dipasang dan hanya

dilakukan uji coba.

1.7 Sistematika Penulisan

Dalam penulisan Tugas Akhir ini, penulis memberi gambaran yang lebih

jelas mengenai sistem “Rancang Bangun Sistem Informasi Administrasi Pembelian

Barang Pada PT. Bank ANZ Indonesia”. Atas dasar pembagian masalah serta jenis

data yang terkumpul maka penulis mengelompokkan materi penelitian menjadi lima

bab yang uraiannya sebagai berikut:

9

BAB I : PENDAHULUAN

Dalam bab ini, menjelaskan tentang latar belakang masalah, permasalahan

yang sedang dihadapi, tujuan penulisan, batasan masalah dan metode

penelitian dalam pengumpulan data serta sistematika penulisan.

BAB II : LANDASAN TEORI

Berisi mengenai teori-teori yang digunakan dalam penulisan laporan

skripsi. Bagian ini berisi tentang teori-teori dasar dan pendapat ahli tentang

sistem informasi pencatatan pembelian barang, teori tentang metode

pengumpulan data, teori RAD dan UML.

BAB III : METODOLOGI PENELITIAN

Bab ini berisi uraian tentang metode penelitian yang digunakan dalam

pengumpulan data dan metode dalam pengembangan sistem. Dimana

dalam bab ini membahas lebih rinci tentang metode pengumpulan data,

metode pengembangan sistem, metode analisa yang digunakan serta

adanya kerangka penelitian dari penelitian yang dilakukan pada PT Bank

ANZ Indonesia

10

BAB IV : ANALISIS DAN PERANCANGAN SISTEM

Bab ini berisi tentang gambaran umum, sejarah dan struktur organisasi

perusahaan. Analisis permasalahan mengenai sistem yang berjalan saat ini

pada PT Bank ANZ Indonesia, serta perancangan sistem yang akan

dirancang, meliputi perancangan database, interface hingga testing sistem

ini.

BAB V : KESIMPULAN DAN SARAN

Bab ini berisi mengenai garis besar kesimpulan yang dibuat oleh penulis

dan saran-saran yang diusulkan untuk pengembangan lebih lanjut agar

tercipta hasil yang lebih baik.

11

BAB II

LANDASAN TEORI

2.1. Rancang Bangun

2.1.1. Rancang

Perancangan adalah sebuah proses yang mendefinisikan sesuatu yang akan

dikerjakan dengan menggunakan teknik yang bervariasi serta didalamnya melibatkan

deskripsi mengenai arsitektur serta detail komponen dan juga keterbatasan yang akan

dialami dalam proses pengerjaannya (Rizky, 2011).

2.1.2. Bangun

Menurut Pressman (2002) pengertian pembangunan atau bangun sistem

adalah kegiatan menciptakan sistem baru maupun mengganti atau memperbaiki

sistem yang telah ada secara keseluruhan.

Jadi rancang bangun dapat berarti mengatur segala sesuatu sebelum bertindak,

mengerjakan atau melakukan sesuatu (Alwi, 2007)

2.2. Konsep Dasar Sistem

2.2.1. Pengertian Sistem

Menurut Al Fatta dalam buku Analisis & Perancangan Sistem

Informasi(2007 : 3) pengertian sistem adalah :

“Kumpulan dari bagian–bagian yang bekerja sama untuk mencapai

tujuan yang sama, dan sekumpulan objek–objek yang saling berelasi dan

12

berinteraksi serta hubungan antar objek bisa dilihat sebagai satu kesatuan

yang dirancang untuk mencapai satu tujuan”.

Dan menurut Bentley dan Whitten (2007 : 6) pada buku karangan

nya Systems Analysis and Design for the. Global Enterprise, 7 th. Edition

mendefinisikan sistem sebagai :

“Kumpulan dari beberapa bagian yang saling berhubungan yang bekerja

bersama-sama untuk mencapai beberapa hasil.”

Berdasarkan teori-teori diatas dapat ditarik kesimpulan bahwa yang

dimaksud dengan sistem adalah kombinasi dari suatu rangkaian variabel-

variabel yang saling tergantung satu dengan yang lainnya dimana secara

keseluruhan mempunyai tujuan yang tertentu. Beroperasinya sistem adalah

dengan maksud tertentu, maksud dan tujuan akhir yang diinginkan akan bisa

tercapai hanya bila dilakukan suatu kegiatan (kontrol).

2.2.1.1. Karakteristik Sistem

Suatu sistem mempunyai karakteristik atau sifattertentu, yaitu:

1) Komponen (Components)

Terdiri dari sejumlah komponen yang saling berinteraksi, yaitu

saling bekerja sama membentuk satu kesatuan.

Komponen/elemen sistem dapat berupa suatu subsistem atau

subbagian yang mempunyai fungsi khusus dan dapat

mempengaruhi fungsi sistem secara keseluruhan.

13

2) Batasan (Boundary)

Batasan sistem adalah daerah yang membatasi antara suatu

sistem dengan lingkungan luarnya atau dengan sistem lainnya.

Batasan suatu sistem menunjukkan ruang lingkupdari sistem

tersebut.

3) Lingkungan Luar (Environments)

Lingkungan luar dari suatu sistem adalah apapun diluar batas

dari sistem yang mempengaruhi operasi dan kelangsungan

hidup sistem, serta dapat menguntungkan atau merugikan

sistem tersebut.

4) Penghubung (Interface)

Penghubung sistem merupakan media penghubung antara satu

subsistem dengan subsistem lain yang memungkinkan adanya

aliran sumber daya diantara subsistem tersebut. Keluaran dari

subsistem akan menjadi masukan bagi subsistem lainnya untuk

dapat berinteraksi menjadi satu kesatuan.

5) Masukan (Input)

Masukan sistem adalah energi yang dimasukkan kedalam

sistem yang berupa masukan perawatan (maintenance input)

dan sinyal masukan(signal input).Maintenanceinput adalah

energi yang dimasukkan agar sistem tersebut dapat beroperasi.

14

Signal input adalah energi yang dimasukkan dan di proses

untuk menghasilkan keluaran.

6) Keluaran (Output)

Keluaran adalah hasil energi yang diolah dan diklasifikasikan

menjadi satu keluaran dan dapat pula menjadi sisa pembuangan

yang tidak berguna. Keluaran suatu subsistem dapat menjadi

masukan bagi subsistem lainnya.

7) Pengolahan(Process)

Pengolahan sistem adalah bagian dari sistem yang melakukan

pengolahan sebuah masukan sehinga menghasilkan keluaran

yang berguna bagi sistem.

8) Sasaran / Tujuan (Objectives)

Sasaran sistem akan sangat menentukan masukan yang

dibutuhkan sistem dan keluaran yang dihasilkan sistem. Suatu

subsistem akan dikatakan berhasil bila sistem mengenai sasaran

atau tujuannya.

2.3. Konsep Dasar Informasi

”Informasi adalah data yang telah diolah sehingga lebih

bermakna”(Mcleod, 2007 :12).Informasi secara umum yaitu data yang telah

disusun dan di proses sedemikian rupa sehingga mempunyai makna dan

15

manfaat bagi seseorang yang dapat menggunakannya dalam membuat

keputusan.

Sumber dari informasi adalah data. Data sebagai bahan baku informasi

yaitu kelompok teratur yang menggambarkan kuantitas berupa alphabet, angka

ataupun simbol-simbol yang dapat di deskripsikan serta di klasifikasikan.

Menurut Indrajani dalam buku Sistem Informasi Akuntansi (2011 : 48)

dalam bukunya menyatakan “data adalah fakta-fakta mentah yang harus

dikelola untuk menghasilkan suatu informasi yang memiliki arti bagi suatu

organisasi atau perusahaan”. Terdapat perbedaan antara data dan informasi.

Data mencakup fakta dan angka-angka yang relatif tidak berarti, yang diubah

menjadi informasi oleh pengolah informasi.

Suatu informasi sangat bernilai dan berguna bagi penerimanya bila

mengandung beberapa hal berkualitas berikut ini :

1) Akurat

Artinya informasi tidak boleh adanya gangguan yang dapat merubah atau

merusak informasi sehingga menyesatkan, bebas dari kesalahan-

kesalahan, serta harus jelas mencerminkan maksud dan makna yang

terkandung didalamnya.

2) Tepat Waktu

Artinya informasi yang datang pada penerima tidak boleh terlambat.

Informasi yang sudah usang tidak mempunyai nilai lagi, karena informasi

16

merupakan landasan di dalam pengambilan keputusan. Bila pengambilan

keputusan terlambat maka dapat berakibat fatal untuk perusahaan.

3) Relevan

Artinya informasi tersebut mempunyai manfaat untuk pemakainya.

Relevansi informasi untuk tiap-tiap orang satu dengan yang lainnya

berbeda.

Suatu informasi dapat bersumber dari 2 hal, yaitu:

a) Internal

Sumber informasi berasal dari dalam perusahaan. Misalnya

seperti dokumen internal (dokumen pembelian, arsip pegawai,

laporan), Observasi (metode pengumpulan informasi dengan cara

menelitinya), Survey Internal (kuesioner, wawancara, dll)

b) External

Informasi yang diperoleh dari luar perusahaan (survey external,

laporan keuangan perusahaan lain, data statistik dan keputusan

pemerintah).

2.4. Konsep Dasar Sistem Informasi

Sistem informasi dapat didefinisikan sebagai suatu sistem di dalam suatu

organisasi yang merupakan kombinasi orang-orang, fasilitas, teknologi, media

prosedur-prosedur dan pengendalian yang ditunjukan untuk mendapatkan jalur

komunikasi penting. Hal penunjang yang sangat penting bagi semua tingkat

17

manajemen di suatu organisasi dalam pengambilan setiap keputusan. Schell dan

Mcleod (2007 : 6) pada buku karangannya mendefinisikan sistem informasi

sebagai :

“Sistem Informasi didefinisikan sebagai kumpulan dari beberapa bagian

yang saling berhubungan yang mengumpulkan, memproses, menyimpan, dan

menyediakan, sebagai hasil dari informasi yang dibutuhkan untuk

menyelesaikan bisnis.”

Sistem informasi dapat terdiri dari komponen yang saling berinteraksi

yang disebut dengan istilah blok bangunan(building block). Adapun komponen-

komponen yang ada pada blok bangunan menurut Jogiyanto (2005 : 12), dalam

buku Analisis Dan Desain Sistem Informasi, menyadur John Burch dan Gary

Grudnitski, yaitu :

1) Blok Masukan(Input)

Input mewakili data yang masuk ke dalam sistem informasi. Input

disini termasuk metode-metode dan media untuk menangkap data yang

akan dimasukkan, yang dapat berupa dokumen-dokumen dasar.

2) Blok Model

Blok ini terdiri dari kombinasi prosedur, logika dan model matematik

yang akan memanipulasi data input dan data yang tersimpan di basis data

dengan cara tertentu untuk menghasilkan keluaran yang diinginkan.

3) Blok Keluaran(Output)

18

Produk dari sistem informasi adalah keluaran yang merupakan

informasi yang berkualitas dan dokumentasi yang berguna untuk semua

tingkatan manajemen serta semua pemakai sistem.

4) Blok Teknologi

Teknologi digunakan untuk menerima input, menjalankan model,

menyimpan dan mengakses data, menghasilkan dan mengirimkan

keluaran dan membantu pengendalian dari sistem secara keseluruhan.

Teknologi terdiri dari 3 bagian utama, yaitu teknisi (humanware atau

brainware), perangkat lunak dan perangkat keras.

5) Blok Basis Data

Basis data (database) merupakan kumpulan dari data yang saling

berhubungan satu dengan yang lainnya, tersimpan di perangkat keras

komputer dan digunakan perangkat lunak untuk memanipulasinya. Data

perlu disimpan di dalam basis data untuk keperluan penyediaan informasi

lebih lanjut. Data di dalam basis data perlu diorganisasikan sedemikian

rupa, supaya informasi yang dihasilkan berkualitas. Organisasi basis data

yang baik juga berguna untuk efisiensi kapasitas penyimpanannya. Basis

data diakses atau dimanipulasi dengan menggunakan perangkat lunak

yang disebut DBMS (Database Management Systems).

6) Blok Kendali

Supaya sistem dapat berjalan sesuai dengan yang diinginkan, maka

perlu diterapkan pengendalian di dalamnya. Banyak hal yang dapat

19

merusak sistem informasi, seperti misalnya bencana alam, api, temperatur

dan lain-lain. Beberapa pengendali perlu dirancang dan diterapkan untuk

meyakinkan bahwa hal-hal yang dapat merusak sistem dapat dicegah

ataupun bila terlanjur terjadi kesalahan-kesalahan dapat langsung teratasi

dengan cepat.

Komponen-komponen blok bangunan di atas tersebut saling

berinteraksi satu dengan yang lainnya guna membentuk satu kesatuan

untuk mencapai tujuan tertentu.

2.5. Pengertian Administrasi

Banyak pengertian administrasi yang dikemukanan oleh para ahli

administrasi, ada pengertian adminitasi secara luas dan ada pengertian administrasi

secara sempit, dan bahkan ada yang mengartikan sebagai proses sosial

Dalam pengertian yang luas menurut Musanef (1996:1) dalam bukunya

Manajemen Kepegawaian di Indonesia menyebutkan bahwa administrasi adalah

kegiatan sekelompok manusia melalui tahapan-tahapan yang teratur dan dipimpin

secara efektif dan efisien, dengan menggunakan sarana yang dibutuhkan untuk

mencapai tujuan yang diinginkan Dalam implementasinya, administasi berkembang

dan mempunyai tugas-tugas yang biasa disebut sebagai fungsi administrasi

sebagaimana yang dikemukakan oleh para ahli seperti Henry Faysol, Harold

Koontz, George R. Terry dan lain-lain, diantaranya adalah fungsi perencanaan,

pengorganisasian sampai dengan fungsi pengawasan Salah satu bentuk rumusan

20

pengertian adminitasi secara luas yang sederhana antara lain menyebutkan :bahwa

administrasi adalah keseluruhan proses rangkaian pelaksanaan kegiatan yang

dilakukan oleh dua orang atau lebih yang terlibat dalam suatu bentuk usaha bersama

demi tercapainya tujuan yang telah ditetapkan sebelumnya

Meskipun rumusannya sederhana, pengertiannya tetap mempunyai cakupan yang

luas, yaitu seluruh proses kegiatan yang berencana dan melibatkan seluruh anggota

kelompok.

Sedangkan dalam pengertian sempit, sebagai yang dikemukakan oleh

Soewarno Handayaningrat (1996:2), dalam bukunya “Pengantar Studi Ilmu

Administrasi dan Manajemen” , administrasi adalah suatu kegiatan yang meliputi

catat-mencatat, surat-menyurat, pembukuan ringan, ketik mengetik, agenda dan

sebagainya yang bersifat teknis ketatausahaan. Pencatatan sangat perlu dilakukan

pada setiap kegiatan yang akan dan telah dilakukan untuk merekam dalam bentuk

tulisan secara rinci rencana kegiatan yang akan dilakukan dan merekam hasil

kegiatan yang telah dilakukan.

2.6. Pengertian Pembelian

Pembelian adalah serangkaian tindakan untuk mendapatkan barang dan

jasamelalui pertukaran, dengan maksud untuk digunakan sendiri atau

dijualkembali.

Tahapan-tahapan prosedur pembelian menurut Mulyadi adalah

sebagaiberikut:

“1. Prosedur permintaan pembelian

21

2. Prosedur permintaan penawaran harga pemilihan pemasok

3. Prosedur order pembelian

4. Prosedur Penawaran harga

5. Prosedur pencatatan

6. Prosedur distribusi pembelian.”(2001:301)

Penjelasan tahapan-tahapan di atas adalah sebagai berikut:

1. Prosedur permintaan pembelian

Dalam prosedur ini fungsi gudang mengajukan permintaan pembelian

dalam formulir surat penerimaan pembelian kepada fungsi pembelian.

Jika barang tidak disimpan di gudang, misalnya untuk barang-barang

yang langsung dipakai, fungsi yang memakai barang mengajukan

permintaan pembelian langsung ke fungsi pembelian dengan

menggunakan surat permintaan pembelian.

2. Prosedur permintaan penawaran harga pemilihan pemasok

Dalam prosedur ini fungsi pembelian mengirimkan surat penawaran

harga kepada para pemasok untuk memperoleh informasi mengenai

harga barang dan berbagai syarat pembelian yang lain, untuk

memungkinkan pemilihan pemasok yang akan ditujukan sebagai

pemasok barang yang diperlukan oleh perusahaan.

3. Prosedur order pembelian

Dalam prosedur ini fungsi pembelian mengirimkan suratorder

pembelian kepada pemasok yang dipilih dan memberitahukan kepada

unit-unit organisasi lain dalam perusahaan (misalnya fungsi

22

penerimaan, fungsi yang meminta barang dan fungsi pencatat utang)

mengenai order pembelian yang sudah dikeluarkan oleh perusahaan.

4. Prosedur penerimaan barang

Dalam prosedur ini fungsi penerimaan melakukan pemeriksaan

mengenai jenis, kualitas dan mutu barang yang diterima dari pemasok

dan kemudian membuat laporan penerimaan barang untuk menyatakan

barang dari pemasok tersebut.

5. Prosedur pencatatan

Dalam prosedur ini memeriksa dokumen-dokumen yang berhubungan

dengan pembelian (suratorder pembelian, laporan penerimaan barang

dan faktur dari pemasok) dan menyelenggarakan pencatatan utang atau

mengarsipkan dokumen sumber sebagai catatan.

6. Prosedur distribusi pembelian

Prosedur ini meliputi distribusi rekening yang didebet dari transaksi

pembelian untuk kepentingan pembuatan laporan manajemen.

2.7. Teori Rapid Application Development (RAD)

2.7.1. Pengertian Rapid Application Development (RAD)

Menurut Whitten (2004), Rapid Application Development (RAD) adalah

suatu pendekatan desain sistem yang menggunakan teknik terstruktur,

prototyping, dan Joint Application Development (JAD) untuk

mengembangkan sistem secara tepat.

23

RAD adalah sebuah strategi pengembangan sistem yang menekankan

kecepatan pengembangan melalui keterlibatan pengguna yang ekstensif dalam

konstruksi, cepat, berulang dan bertambah serangkaian prototype bekerja

sebuah sistem yang pada akhirnya berkembang ke dalam sistem final.

Sebagai respon pada kemajuan ekonomi pada umumnya, Rapid

Application Development (RAD) / pengembangan aplikasi cepat telah

menjadi rute yang populer untuk mengakselerasi pengembangan sistem.

Menurut Whitten (2004), model RAD mempunyai beberapa keunggulan

sebagai berikut:

1. Mendorong pengguna aktif dan partisipasi manajemen

(berkebalikan dengan reaksi pasar pada model-model sistem yang

tidak bekerja). Hal ini meningkatkan antusiasme pengguna akhir

proyek.

2. Proyek-proyek memiliki visibilitas dan dukungan lebih tinggi

karena keterlibatan pengguna yang ekstensif selama proses.

3. Para pengguna dan manajemen melihat solusi-solusi yang berbasis

perangkat lunak dan bekerja lebih cepat dari pada pengembangan

model-driven.

4. Error dan penghilangan cenderung untuk dideteksi lebih awal dalam

prototype dari pada model sistem.

5. Pengujian dan pelatihan adalah produk tambahan alami dari

pendekatan prototyping yang mendasar.

6. Pendekatan berulang adalah proses yang lebih “alami” karena

24

perubahan adalah faktor yang diharapkan selama pengembangan.

2.7.2. Unsur-unsur Penting RAD

Menurut McLeod (2008) RAD membutuhkan empat unsur

penting, yaitu:

1. Manajemen, khususnya manajemen puncak, hendaknya menjadi penguji

coba (experimenter) yang suka melakukan hal-hal dengan cara baru atau

pengadaptasi awal (early adapter) yang dengan cepat mempelajari

bagaimana cara menggunakan metodologi-metodologi baru.

2. Orang, dari pada hanya memanfaatkan satu tim untuk melakukan

seluruh aktivitas SDLC, RAD menyadari adanya efisiensi yang dapat

dicapai melalui penggunaan tim-tim khusus. Anggota dalam tim ini

adalah para ahli dalam metodologi dan alat yang dibutuhkan untuk

melakukan tugas-tugas khusus mereka masing-masing.

3. Metodologi, metodologi dasar RAD adalah siklus hidup RAD.

4. Alat-alat, alat-alat RAD terutama terdiri atas bahasa-bahasa generasi

keempat dan alat-alat rekayasa piranti lunak dengan bantuan komputer

(computer-aided software engineering-CASE) yang memfasilitasi

prototyping dan penciptaan kode. Alat-alat CASE menggunakan

komputer untuk membuat dokumentasi yang dapat diubah menjadi

piranti lunak dan basis data operasional.

25

2.7.3. Tahap-tahap Pengembangan Sistem

Menurut McLeod (2008) ada empat tahap penting dalam

pengembangan sistem, yaitu:

1. Investigasi Awal

Mempelajari tentang organisasi dengan masalah sistemnya, mendefinisikan

tujuan, hambatan, risiko, dan ruang lingkup sistem baru, mengevaluasi

proyek maupun kelayakan sistem, melakukan sub-divisi sistem menjadi

komponen-komponen besar dan mendapatkan umpan balik pengguna.

2. Analisis

Menganalisis persyaratan fungsional pengguna untuk masing-masing modul

sistem dengan menggunakan berbagai macam teknik pengumpulan

informasi dan kemudian mendokumentasikan temuan-temuannya dalam

bentuk model-model proses, data, dan objek.

Terdapat tiga tahapan analisis sistem pada alur pengembangan sistem RAD

menurut Whitten (2004), yaitu:

a. Problem Analysis, Analisa masalah merupakan tahap mempelajarisistem

yang sudah ada dan menganalisa temuan-temuan agar dapat menemukan

pemahaman yang lebih mendalam atas masalah yang memicu adanya

proyek ini.

b. Requirement Analysis, Analisa kebutuhan merupakan tahap yang

mendefinisikan dan memprioritaskan kebutuhan bisnis. Dengan kata lain

26

memahami pengguna untuk mengetahui apa yang dibutuhkan atau inginkan

dari sistem baru, dengan menghindari pembahasan tentang teknologi atau

teknis pelaksanaan. Ini mungkin merupakan tahap terpenting

pengembangan sistem karena kesalahan dan kelalaian dari hasil analisis ini

mengakibatkan ketidakpuasan pengguna dengan sistem final dan

modifikasi yang mahal.

Functional requirement adalah deskripsi dari aktivitas dan layanan

yang harus disediakan sebuah sistem.

Nonfunctional requirement adalah deskripsi dari fitur, karakteristik

dan batasan lain yang menentukan kepuasan sistem.

c. Decision Analysis, Analisa keputusan adalah untuk mengidentifikasi pilihan

solusi teknis, menganalisis solusi atas kelayakan dari pilihan tersebut, dan

merekomendasikan pilihan sistem yang akan dirancang.

3. Desain

Merancang komponen dan antarmuka dengan sistem-sistem lain umtuk

setiap modul sistem yang baru dan kemudian mendokumentasikan desain

dengan menggunakan berbagai jenis teknik pemodelan.

Terdapat empat tahapan desain pada alur pengembangan sistem RAD

menurut Mc Leod (2008)

a. Proses, pada tahapan ini menggambarkan alur proses sistem yang di

bangun dengan bantuan notasi Diagram UML seperti Use Case

Diagram, Activity Diagram dan Sequence Diagram.

27

b. Desain Input/Output, pada tahapan ini menggambarkan proses input

output yang ada pada sistem yang dibangun seperti Potensial Objek,

Class Diagram, Mapping, CRUD Matrix, schema Database dan

Spesifikasi Database.

c. Desain Database, tahapan ini mendefinisikan dan merancang

kebutuhan database pada sistem yang di bangun.

d. Desain Interface, menghasilkan dan merancang tatap muka sistem

yang akan di bangun.

4. Pengujian dan Pemasangan Sistem

Komponen-komponen sistem dipasang, dan dilakukan uji penerimaan

pengguna. Penerimaan oleh pengguna akan menjadi tanda persetujuan

untuk melanjutkan ke tahap serah terima.

2.8. Unified Models Language (UML)

2.8.1. Sejarah UML

Munawar (2005) UML adalah pengantar kepada gelombang metode Object

Oriented Analysis and Design yang muncul pada akhir tahun 1980an dan awal

1990an. Pada saat itu, ada banyak metode object oriented yang berbeda yang

digunakan dalam industri, di antaranya Booch Method dari Grady Booch, Object

Modeling Technique (OMT) dari James Rumbaugh, dan Object Oriented Software

Engineering (OOSE) dari Ivar Jacobson. Adanya banyak metode dan teknik

pemodelan tersebut merupakan permasalahan utama dalam pengembangan sistem

saat itu, karena tidak ada standar dan keseragaman tertentu sehingga terdapat

28

keterbatasan antar proyek dan antar anggota tim pengembangan. Hal ini mempersulit

komunikasi dan menimbulkan banyak kesalahan dalam proyek.Permasalahan inilah

yang membawa kepada usaha untuk menemukan bahasa pemodelan yang standar,

yang dapat digunakan pada semua keadaan di seluruh dunia.

Tahun 1994, Booch dan Rumbaugh menyatukan pandangan mereka tentang

metode pengembangan object oriented, dan disusul oleh Jacobson pada 1995, serta

metode-metode lain seperti Fusion, Shlaer-Mellor, dan lain-lain. Pada 1996, Object

Management Group (OMG) meminta proposal untuk sebuah pendekatan yang

standar untuk object oriented modeling. Para pencetus UML mulai bekerja dengan

para metodologis dan pengembang dari perusahaan lain untuk membuat sebuah

proposal yang menarik bagi OMG agar modeling language dapat diterima oleh para

pencetus, metodologis dan pengembang. Proposal diserahkan ke OMG pada

September 1997, hasil akhirnya adalah kolaborasi dari banyak orang. Dan pada

november 1997 dibuat sebuah standarnya yaitu UML version 1.0. UML adalah

standar dunia yang dibuat oleh Object Management Group (OMG), sebuah badan

yang bertugas mengeluarkan standar-standar teknologi object oriented dan software

component.

2.8.2. Kegunaan UML

Berdasarkan OMG, UML (Unified Modeling Language) dapat didefinisikan

sebagai sebuah bahasa yang berdasarkan gambar untuk memvisualisasi (visualizing),

menspesifikasi (specifying), mengkonstruksi (constructing), dan mendokumentasi

(documenting) sebuah sistem perangkat lunak. UML menggunakan notasi yang

29

dikombinasikan dari beberapa metode yang telah berkembang sebelumnya. Hal ini

ditujukan untuk mempermudah desain, dan dapat digunakan untuk model dengan

skala besar sekalipun dengan jumlah kompleksitas, jumlah tim, dan distribusi

komponen yang sangat besar. Tujuan akhir dari UML adalah untuk menjadi

sesederhana mungkin selama masih memenuhi kebutuhan untuk melakukan modeling

pada sistem yang akan dibangun.

2.8.2.1. Diagram-diagram dan Notasi UML

Notasi adalah bahasa textual dan graphical untuk menggambar sebuah sistem

dan konteksnya yang diformalisasikan secara terpisah.Tujuannya adalah untuk

menyederhanakan komunikasi dan dokumentasi. Berikut ini merupakan beberapa

diagram UML dan notasinya yang paling umum digunakan:

1. Use Case Diagram

Menurut Munawar (2005) use case diagram digunakan dalam menggambarkan

fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa”

yang diperbuat oleh sistem, dan bukan “bagaimana”. Sebuah use case

merepresantikan sebuah interaksi antara aktor dengan sistem. Use case

merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create

sebuah daftar belanja dan sebagainya. Seorang actor adalah sebuah entitas

manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-

pekerjaan tertentu.Use case diagram dapat sangat membantu bila kita sedang

menyusun requirement (kebutuhan) sebuah sistem, mengkomunikasikan

rancangan dengan klien, dan merancang test case untuk semua feature yang ada

30

pada sistem. Use case diagram menunjukkan aktor-aktor yang berinteraksi

dengan sebuah sistem dan use case yang menjelaskan cara-cara seperti bagaimana

interaksi mengambil tempat. Aktor-aktor dihubungkan dengan use case di mana

mereka dihubungkan dengan sebuah asosiasi.

Berikut ini adalah daftar simbol-simbol yang digunakan dalam membuat

use case diagram:

Tabel 2.2 Simbol-simbol Use Case Diagram

Sumber: Munawar (2005)

No. Simbol Fungsi

1

System Boundary

Menyatakan batasan sistem dalam relasi

dengan actor-actor yang menggunakannya

(di luar sistem) dan fitur-fitur yang harus

disediakan (dalam sistem). Digambarkan

dengan segi empat yang membatasi semua

use case dalam sistem terhadap pihak mana

sistem akan beraksi.

2

Actor

Actor adalah segala sesuatu yang perlu

berinteraksi dengan sistem untuk pertukaran

informasi. Bisa merupakan manusia, sistem

atau device.

3

Use Case

Mengidentifikasi fitur kunci dari sistem.

Tanpa fitur ini, sistem tidak akan memenuhi

permintaan user/aktor. Setiap use case

mengekspresikan goal dari sistem yang

harus dicapai. Diberi nama sesuai dengan

goalnya dan digambarkan dengan elips dan

nama di dalamnya.

4

Asosiation

Mengidentifikasikan interaksi antara setiap

actor tertentu dengan setiap use

casetertentu. Digambarkan sebagai garis

antara actor terhadap use case yang

bersangkutan.

5

Mengidentifikasi kelakuan yang harus

terpenuhi agar sebuah event dapat terjadi,

kondisi ini adalah hubungan dua use case

System

actor

use case

<<include>>

31

dimana yang satu memanggil yang lain.

6

Menspesifikasikan bahwa use case target

memperluas prilaku dari use case sumber

secara eksplisit.

2. Activity Diagram

MenurutMunawar (2005) Activity diagram secara grafis digunakan untuk

menggambarkan rangkaian aliran aktifitas baik proses bisnis atau use case.

Adapun simbol-simbol dari activity diagram adalah sebagai berikut:

Tabel 2.4 Simbol-simbol Activity Diagram

Sumber: Munawar (2005: 109)

No. Simbol Fungsi

1

Swimlane

Menujukkan siapa yang bertanggung

jawab melakukan aktivitas dalam suatu

diagram.

2

Start State

Menujukkan dimana aliran kerja itu di

mulai.

3

End State

Menujukkan dimana aliran kerja itu

berakhir.

4

Action State

Action state adalah langkah-langkah dalam

sebuah activity. Action bisa terjadi saat

memasuki activity, meninggalkan activity,

atau pada event yang spesifik.

<<extend>>

Swimlane1

Activity1

32

5

Decission

Menunjukkan dimana sebuah keputusan

perlu di buat dalam aliran kerja.

6

Synchronization

Synchronization menunjukkan dua atau

lebih langkah dalam aliran kerja berjalan

secara serentak.

3. Sequence Diagram

Menurut Munawar (2005) sequence diagram digunakan dalam menggambarkan

interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display,

dan sebagainya) berupa message yang digambarkan terhadap waktu.Sequence

diagram terdiri dari dimensi vertikal (waktu) dan dimensi horizontal (objek-objek

yang terkait). Bisa digunakan untuk menggambarkan skenario atau rangkaian

langkah-langkah yang dilakukan sebagai respon dari sebuah event untuk

menghasilkan output tertentu. Diawali dari apa yang menjadi trigger aktifitas

tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa

yang dihasilkan. Masing-masing objek, termasuk aktor memiliki lifeline

vertikal.Message digambarkan sebagai garis berpanah dari satu objek ke objek

lainnya.Sequence diagram menunjukkan sebuah interaksi antara peran atau objek-

objek prototipe dalam sebuah kolaborasi. Setiap peran memiliki sebuah lifeline

yang memanjang di bawahnya.Message direpresentasikan dengan panah berlabel

yang digambarkan dari satu lifeline ke lifeline lain. Message memberikan sebuah

aktivasi.Di ujung aktivasi, return message menunjukkan arah balik kendali

33

kepada objek yang memanggil. Parameter dan nilai return dapat ditunjukkan

dalam message. Message dikirim ke objek dengan sendirinya untuk memberikan

aktivasi nested. Munawar (2005) untuk looping dan conditional menggunakan

interaction frame yaitu frame untuk memberi tanda pada sequence diagram.

Ada beberapa tujuan mengapa harus membuat Sequence Diagram diantaranya

adalah

1. Menggambarkan interaksi antar objek di dalam dan di sekitar sistem

termasuk pengguna, display, dan sebagainya, yang digambarkan dengan

hubungan message dan waktu

2. Menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan

sebagai respons dari sebuah event untuk menghasilkan output tertentu.

Menurut Munawar (2005) ada 8 operator yang umum digunakan di

interaction frame, yaitu:

a. Alt

Alternatif dari banyak fragmen. Hanya yang kondisinya yang True yang

akan dijalankan.

b. Opt

Merupakan singkatan dari Optional. Fragmen yang dijalankan jika kondisi

yang mendukungnya True.

c. Par

Singkatan dari paralel.Setiap fragmen dijalankan secara parallel.

34

d. Loop

Singkatan dari looping. Fragmen mungkin dijalankan berulang kali dan

guard menunjukkan basis iterasi.

e. Region

Critical region. Fragmen hanya dapat mempunyai satu thread untuk

menjalankannya.

f. Neg

Singkatan dari negative.Fragmen menunjukkan interaction yang salah.

g. Ref

Reference. Menunjukkan ke sebuah interaction yang salah didefinisikan

pada diagram yang lain.

h. Sd

Sequence diagram.

Berikut ini adalah simbol-simbol yang digunakan dalam membuat

Sequencediagram:

Tabel 2.3 Simbol-simbol Sequence Diagram

Sumber: Wahono (2011)

Simbol Keterangan

Boundary biasanya berupa tepi dari sistem,

seperti user interface atau suatu alat yang

berinteraksi dengan sistem lain

sd Data Mo...

Boundary

35

Control merupakan elemen yang mengatur

aliran dari informasi untuk sebuah scenario.

Perilaku bisnis umumnya diatur oleh objek

ini

Entity biasanya elemen yang bertanggung

jawab menyimpan data atau informasi. Ini

dapat berupa beans / model objek

Actor1

Merepresentasikan entitas yang berada di

luar sistem,mereka bisa berupa manusia, atau

perangkat sistem lain.

Message1

Relasi ini digunakan untuk memanggil

operasi atau metode yang dimiliki oleh suatu

objek. Message mengharuskan kita

menyelesaikan proses baru kemudian

memanggil proses berikutnya.

Message2

Relasi ini menunjukkan bahwa suatu objek

hendak memanggil dirinya sendiri.

4. Class Diagram

MenurutMunawar (2005) Class merupakan sebuah spesifikasi yang jika

diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari

pengembangan dan desain berorientasi objek. Class menggambarkan keadaan

suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan

tersebut.Jadi, dapat disimpulkan bahwa class diagram menggambarkan

sd Data Mo...

Control

sd Data Mo...

Entity

36

sekumpulan class, interface, dan collaboration, dan relasi-relasinya.Class

diagram juga menunjukkan atribut dan operasi dari sebuah objek class.Atribut

adalah nama-nama properti dari sebuah kelas yang menjelaskan batasan nilainya

dari properti yang dimiliki oleh sebuah kelas tersebut.Atribut dari suatu kelas

merepresantikan properti-properti yang dimiliki oleh kelas tersebut.Atribut

mempunyai tipe yang menjelaskan tipe instansiasinya.Operasi adalah

implementasi dari layanan yang dapat diminta dari sebuah objek dari sebuah kelas

yang menentukan tingkah lakunya.Sebuah operasi dapat berupa perintah ataupun

permintaan.Sebuah permintaan tidak boleh mengubah kedudukan dari objek

tersebut.Hanya perintah yang dapat mengubah keadaan dari sebuah

objek.Keluaran dari sebuah operasi tergantung dari nilai keadaan terakhir dari

sebuah objek. Class memiliki 3 area pokok, yaitu nama, atribut, dan fungsi.

Atribut dan metoda dapat memiliki salah satu sifat berikut ini:

a. Private : tidak dapat dipanggil dari luar class yang bersangkutan.

b. Protected : hanya dapat dipanggil oleh class yang bersangkutan dan anak-

anak yang mewarisinya.

c. Public : dapat dipanggil oleh siapa saja.

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak

yang hanya memiliki metoda.Interface tidak dapat langsung diinstansiasikan,

tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian

interface mendukung resolusi metoda pada saat run time. Sesuai dengan

perkembangan class model, class dapat dikelompokkan menjadi package.

37

Hubungan antar class dapat digambarkan dengan notasi sebagai berikut:

1) Asosiasi

Hubungan statis antar class. Umumnya menggambarkan class yang memiliki

atribut berupa class lain, atau class yang harus mengetahui eksistensi class

lain. Digambarkan dengan garis yang dilengkapi dengan sebuah label, nama

dan status hubungannya. Panah navigability menunjukkan arah query antar

antar class. Navigability merupakan sebuah properti dari role yang

menandakan bahwa mungkin untuk melakukan navigasi uni-directional pada

asosiasi dari objek sumber ke objek tujuan.

2) Agregasi

Hubungan yang menyatakan “bagian dari”, “bagian keseluruhan” atau “terdiri

atas”.Suatu class atau objek mungkin atau bisa dibagi menjadi class atau

objek tertentu, dimana class atau objek yang disebut kemudian merupakan

bagian dari class atau objek yang terdahulu. Ada 2 jenis agregasi, yaitu:

a) Composite Aggregation

Disebut juga strong aggregation dimana objek “bagian” tidak dapat

berdiri sendiri tanpa objek “keseluruhan”.Jadi, antara objek yang satunya

saling terkait kuat dengan objek lainnya. Merupakan multiplicity pada

satu composite dan dinotasikan dengan filled diamond. Menunjukkan

bahwa composite secara tunggal memiliki the part.

38

b) Shared Aggregation

Merupakan multiplicity pada composite yang lebih dari 1 dan dinotasikan

dengan hollow diamond. Menunjukkan bahwa the part bisa terdapat

pada instance composite.

3) Generalisasi

Menggambarkan hubungan khusus dalam objek anak/child yang

menggantikan objek parent/induk.Objek anak memberikan pengaruhnya

dalam hal struktur dan tingkah lakunya kepada objek induk.

Tabel 2.4 Simbol-simbol Class Diagram

Sumber: Munawar (2005)

Simbol Keterangan

Class

Class adalah sebuah blok yang terdiri dari 3 buah kotak. Bagian atas yaitu nama class. bagian tengah mendefinisikan atribut class. Bagian akhir mendfinisikan method dari sebuah class.

Association

Dapat diartikan sebagai relasi. Digambarkan sebagai garis lurus antara dua kelas. Namun tidak berarti bahwa kelas satu memiliki kelas yang lain, tetapi kelas yang lain dapat berelasi juga dengan kelas yang sama.

Generalization

Menggambarkan hubungan khusus dalam objek anak/child yang menggantikan objek parent/induk.

1 * Agregation

Hubungan yang menyatakan “bagian dari”, “bagian keseluruhan” atau “terdiri atas”. Suatu class atau objek mungkin atau bisa dibagi menjadi class atau objek tertentu, dimana class atau objek yang disebut kemudian merupakan bagian dari class atau objek yang terdahulu

class

+Attribute1+Attribute2

+Operation1()+Operation2()

39

2.9. Konsep Aplikasi Sistem dan Database

2.9.1 PHP

Menurut Sidik (2006: 280), PHP merupakan script untuk pemrograman

script web server-side, script yang membuat dokumen HTML (Hypertext

Markup Language) secara on the fly, dokumen HTML yang dihasilkan dari

suatu aplikasi bukan dokumen HTML dibuat dengan menggunakan editor teks

atau editor HTML.

PHP/FI merupakan nama awal dari PHP. PHP – Personal Home Page, FI

adalah Form Interface. Dibuat pertama kali oleh Ramsus Lerdoff. PHP awalnya

merupakan program CGI (Common Gateway Interface) yang dikhususkan

untuk menerima input melalui form yang ditampilkan dalam browser web.PHP

secara resmi merupakan kependekan dari Hypertext Preprocessor, merupakan

bahasa script server-side yang disisipkan pada HTML.

2.9.2 MySQL

MySQL (My Structure Query Language) adalah sebuah program

pembuat database yang bersifat open source, artinya siapa saja dapat

menggunakan secara bebas.MySQL sebenarnya produk yang berjalan pada

platform Linux.Karena sifatnya yang open source, MySQL dapat berjalan pada

semua platform baik Windows maupun Linux.Selain itu, MySQL juga

merupakan program pengakses database bersifat jaringan sehingga dapat

digunakan untuk aplikasi multi-user (banyak pengguna). Saat ini database

MySQL telah digunakan hampir oleh semua pemrograman database, terlebih

40

dalam pemrograman web (Nugroho, 2004).

Macam-macam Tipe Data pada MySQL (Mai Se Kuel) sebenarnya

mempunyai beberapa jenis, secara umum tipe-tipe data MySQL ini ada empat

(4), diantaranya yaitu:

2.9.2.1 Tipe Data Numeric.

Tipe data numerik yaitu tipe data yang digunakan untuk

menyimpan data numeric (angka) yaitu :

Tabel 2.5 Contoh tipe data Numeeric

Sumber :Yuafanda Kholfi Hartono

No Tipe Data Penggunaan Jangkauan Ukuran

1 TINYINT digunakan untuk menyimpan

data bilangan bulat positif dan

negatif.

-128 s/d 127 1 byte (8 bit)

2 SMALLINT digunakan untuk menyimpan


negatif.

-32.768 s/d 32.767 2 byte (16

bit)

3 MEDIUMIN

T

digunakan untuk menyimpan


negatif.

-8.388.608 s/d

8.388.607

3 byte (24

bit)

4 INT digunakan untuk menyimpan


negatif.

-2.147.483.648 s/d

2.147.483.647

4 byte (32

bit)

5 BIGINT digunakan untuk menyimpan


negatif.

± 9,22 x 1018 8 byte (64

bit)

6 FLOAT digunakan untuk menyimpan

data bilangan pecahan positif

dan negatif presisi tunggal.

-3.402823466E+38

s/d -1.175494351E-

38, 0

4 byte (32

bit)

7 DOUBLE digunakan untuk menyimpan


dan negatif presisi ganda

-1.79...E+308 s/d

-2.22...E-308, 0, dan

2.22...E-308 s/d

1.79...E+308

8 byte (64

bit)

8 REAL digunakan untuk menyimpan


-1.79...E+308 s/d

-2.22...E-308, 0, dan

8 byte (64

bit)

41

dan negatif presisi ganda 2.22...E-308 s/d

1.79...E+308

9 DECIMAL digunakan untuk menyimpan


dan negatif

-1.79...E+308 s/d

-2.22...E-308, 0, dan

2.22...E-308 s/d

1.79...E+308

8 byte (64

bit)

10 NUMERIC digunakan untuk menyimpan


dan negatif

-1.79...E+308 s/d

-2.22...E-308, 0, dan

2.22...E-308 s/d

1.79...E+308

8 byte (64

bit)

2.9.2.2 Tipe Data String.

Tipe data string yaitu tipe data yang digunakan untuk menyimpan data string

(text) yaitu :

Tabel 2.6 Contoh tipe data String

Sumber :Yuafanda Kholfi Hartono


1 CHAR Digunakan untuk menyimpan

data string ukuran tetap.

0 s/d 255 karakter

2 VARCHAR Digunakan untuk menyimpan

data string ukuran dinamis.

0 s/d 255 karakter

(versi 4.1), 0 s/d

65.535 (versi 5.0.3)

3 TINYTEXT digunakan untuk menyimpan

data text.

0 s/d 255 karakter

(versi 4.1), 0 s/d

65.535 (versi 5.0.3)

4 TEXT digunakan untuk menyimpan

data text.

0 s/d 65.535 (216 - 1)

karakter

5 MEDIUMTE

XT

digunakan untuk menyimpan

data text.

0 s/d 224 - 1 karakter

6 LONGTEXT digunakan untuk menyimpan

data text.

0 s/d 232 - 1 karakter

2.9.2.3. Tipe Data Date.

Tipe data date dan time yaitu tipe data yang digunakan untuk menyimpan data

tanggal dan waktu yaitu :

42

Tabel 2.7 Contoh tipe data date


1 DATE digunakan untuk menyimpan

data tanggal.

1000-01-01 s/d 9999-

12-31 (YYYY-MM-

DD)

3 byte.

2 TIME digunakan untuk menyimpan

data waktu.

-838:59:59 s/d

+838:59:59

(HH:MM:SS)

3 byte.

3 DATETIME digunakan untuk menyimpan

data tanggal dan waktu.

'1000-01-01 00:00:00'

s/d '9999-12-31

23:59:59'

8 byte.

4 YEAR digunakan untuk menyimpan

data tahun dari tanggal.

1900 s/d 2155 2 b

y

t

e

.

2.9.3 Rich Picture

Rich Picture digunakan pada waktu penyeleksian sistem untuk

menyatakan secara keseluruhan dalam memahami proses darii tahap proyek

pengembangan sistem. Rich Picture secara khusus mendeskripsikan masalah

sistem dan sekaligus penguasaan aplikasi.Rich Picture tidak didasari pada

acuan catatan khusus tetapi memberikan penyesuaian mengenai aspek yang

dideskripsikan pada proyek (Mathiassen. at, al, 2000).

43

Staff PCO

Suppliers

Membuat PO

. Mengirim Barang

PT. Bank ANZ

Indonesia

Gudang

Barang

Sesuai?

. Memeriksa Kondisi

Barang

.(Jika Ya) Masuk Gudang

. (Jika Tidak) Retur Barang

BA Terima Barang

Pay to$

kwitansi

. Melakukan Pembayaran

. Membuat Laporan Pembayaran

Laporan Pembayaran

Pimpinan PCO

Laporan Terima Barang

Laporan terima Barang

Gambar 2.1 Contoh RichPicture Sistem informasi pencatatan

2.9.4 XAMPP

XAMPP merupakan suatu paket yang terdiri dari Apache, MySQL dan PHP

yang dapat digunakan untuk membantu proses instalasi produk tersebut, Sukarno

(2006). Selain itu dilengkapi oleh berbagai fasilitas lain yang akan memberikan

kemudahan dalam pengembangan situs web berbasis PHP. XAMPP merupakan

aplikasi gratis dan tersedia untuk platformLinux, Windows, Mac OS dan

solaris.Aplikasi ini dikembangkan oleh Kay Vogelgeang, carten Wiedmann dan

Kai EOswand Saidler di bawah lisensi General Public Lisence (GNU).Aplikasi ini

dapat diperoleh pada situs http://apachefriends.org. Tampilan konfigurasi dari

XAMPP dapat dilihat sebagai berikut :

44

Gambar 2.2 Konfigurasi XAMPP (Sumber: Sukarno, 2006)

2.9.5. phpMyAdmin

phpMyAdminadalah aplikasi berbasis web yang dibuat dari

pemrograman PHP dan diramu dengan HTML dan javascript, (Nugroho,

2009:80). phpMyAdmindapat juga disebut sebagai tool yang berguna untuk

mengakses database MySQL Server dalam bentuk tampilan web. Tool ini secara

standar telah disertakan pada saat meng-install paket PHP, seperti XAMPP,

Apache2 Triad dan WampServer.

Gambar 2.3 Halaman Utama phpMyAdmin

(Sumber: Nugroho, 2009)

45

2.9.4 Adobe Dreamweaver

Dreamweaver merupakan salah satu software dari kelompok adobe yang banyak

digunakan untuk mendesain situs web.Adobe dreamweaver itu sendiri adalah sebuah

HTMLeditor professional yang berfungsi mendesain secara visual dan mengelola

situs web maupun halaman web (Madcoms, 2008). Tampilan dari ruang kerja adobe

dreamweaver dapat dilihat sebagai berikut:

Gambar 2.4 Ruang Kerja Adobe Dreamweaver CS3

(Sumber: Madcoms, 2008:112)

2.10. Testing

Sebelum sistem diterapkan, system harus melewati tahap pengujian sistem

maupun pengujian program.Hal ini dilakukan untuk mengidentifikasi bila terjadi

kesalahan ataupun terdapatnya celah pada sistem.Pengujian ini dilakukan pada semua

modul yang telah terintegrasi. Pengujian Program dilakukan apakah sistem sudah

layak diterapkan pada instansi terkait atau belum.

Menurut Pressman (2010: 343), testing adalah suatu proses melaksanakan

46

program aplikasi dengan tujuan menemukan kesalahan. Sebelum diterapkan dalam

suatu sistem basis data harus dilakukan testing terlebih dahulu. Hal ini dicapai dengan

penggunaan secara hati-hati untuk merencanakan suatu test dan data yang realistic

sedemikian sehingga keseluruhan proses pengujian sesuai dengan metode dan

dilaksanakan sesuai dengan aturan yang ada.

Pengujian Sistem itu sendiri dibagi menjadi 2, yaitu :

a. Kesalahan Penulisan (Syntax Error)

Kesalahan seperti ini terjadi bila kode program yang telah dibuat ternyata

terdapat skrip yang masih salah. Jadi perlu dilakukan perbaikan pada

source code tersebut.

b. Kesalahan Sewaktu Proses (Runtime Error)

Kesalahan seperti ini terjadi ketika program dijalankan sehingga

menyebabkan proses program terhenti sebelum selesai menyelesaikan

request. Kesalahan semacam ini disebabkan karena compiler menemukan

kondisi-kondisi yang belum terpenuhi.

c. Kesalahan Logika (Logical Error)

Pada kesalahan jenis ini, program tetap berjalan.Namun, output yang

dihasilkan tidak seperti yang diharapkan.

2.11. Pemrograman

2.11.1. BlackBoxTesting

Pengujian Black Box disebut juga pengujian behavioral, yang berfokus pada

47

kebutuhan fungsional software. Black box mencoba untuk menemukan kesalahan

dalam kategori berikut (Pressman, 2005):

1. Fungsi-fungsi yang tidak benar atau hilang.

2. Kesalahan interface.

3. Kesalahan dan struktur data atau akses database eksternal.

4. Kesalahan kinerja.

5. Inisialisasi dan kesalahan terminasi.

Tidak seperti pengujian white box yang dilakukan pada saat awal proses

pengujian, pengujian black box cenderung diaplikasikan selama tahap akhir

pengujian, karena pengujian black box memperhatikan struktur kontrol, maka

perhatian berfokus pada domain informasi.

Adapun langkah-langkah pengujian black box ini adalah sebagai berikut

(Pressman, 2005):

1. Metode Pengujian Berbasis Grafik (Graph Based Testing)

Langkah pertama dalam pengujian black box adalah untuk memahami obyek-

obyek yang dimodelkan dalam software dan hubungan yang menghubungkan antar

obyek. Setelah ini telah dicapai, langkah selanjutnya adalah menentukan serangkaian

tes yang memverifikasi semua obyek yang berpotensi memiliki hubungan satu sama

lain (Pressman, 2005).

Pengujian berbasis grafik dimulai dengan mendefinisikan semua nodes dan

weights node, yaitu obyek-obyek dan atribut yang diidentifikasi. Model data dapat

48

digunakan sebagai permulaan tujuan, tetapi ini penting untuk dicatat bahwa banyak

node mungkin obyek program (tidak secara tegas dipresentasikan dalam model

data).Untuk menyediakan indikasi dari permulaan dan akhir tujuan grafik, ini berguna

untuk menetapkan masukan atau keluaran nodes.Nodespertama kali yang sudah

diidentifikasi, link dan link weights seharusnya dapat ditetapkan. Di beberapa kasus,

model grafik bisa memiliki loops (perulangan). Pengujian perulangan dapat juga

diaplikasikan pada tingkat behavioral (black box). Grafik tersebut akan membantu

dalam mengidentifikasi perulangan yang perlu diuji (Pressman, 2005).

2. Mempartisi Ekuivalensi (Equivalence Partitioning)

Equivalence partitioning adalah metode pengujian black box yang membagi

domain input dari program ke dalam kelas data dari kasus uji yang dapat diturunkan.

Idealnya single test case yang ideal yaitu mengungkap kelas yang error (misalnya,

pengolahan yang salah dari semua data karakter) yang mungkin memerlukan banyak

kasus yang akan dieksekusi sebelum kesalahan tersebut diamati. Equivalence

partitioning berusaha untuk mendefinisikan kasus uji yang mengungkap kesalahan

kelas, sehingga mengurangi jumlah kasus uji yang harus dikembangkan (Pressman,

2005).

3. Analisis Batas Nilai (Boundary Value Analysis)

Untuk alasan yang tidak sepenuhnya jelas, sejumlah besar kesalahan

cenderung terjadi pada batas-batas dari domain masukan daripada didomain

pusat.Alasan inilah yang menyebabkan nilai batas analisis (BVA) telah

49

dikembangkan sebagai teknik pengujian.Analisis nilai batas mengarahkan pada

penyeleksian dari kegiatan uji kasus nilai batas (Pressman, 2005).

4. Pengujian Array Orthogonal (Orthogonal Array Testing)

Ada banyak aplikasi di mana domain input relatif terbatas. Artinya, jumlah

parameter input kecil dan nilai-nilai yang masing-masing parameternya dapat dibatasi

secara jelas. Ketika angka-angka ini sangat kecil (misalnya, tiga parameter masukan

mengambil masing-masing tiga nilai diskrit, ini mungkin untuk mempertimbangkan

setiap inputan permutasi dan proses tes yang mendalam dari domain masukan).

Bagaimanapun juga, jumlah nilai inputan dan jumlah nilai diskrit berkembang untuk

setiap kenaikan item data, pengujian mendalam menjadi tidak praktis atau tidak

mungkin (Pressman, 2005).

Pengujian array orthogonal dapat diterapkan untuk masalah di mana domain

input relatif kecil, tapi pengujian tersebut terlalu besar untuk menampung pengujian

mendalam. Metode pengujian array orthogonal sangat berguna dalam menemukan

kesalahan yang terkait dengan area kesalahan, sebuah kategori errordihubungkan

dengan logika yang salah dalam komponen software(Pressman, 2005).

Berikut adalah contoh tabel pengujian black-box yang diisi langsung dari

pengguna saat aplikasi dijalankan:

Tabel 2.8Contoh Tabel Pengujian Black Box

No. Rancangan Proses Hasil Yang Diharapkan Hasil Keterangan

1. Input username dan Masuk halaman utama OK

50

password admin

2. Memilih menu halaman data

data karyawan

Menampilkan data

departemen

OK

( Sumber : pressman, 2005 )

2.16.3. White Box Testing

White box testing adalah pengujian yang didasarkan pada pengecekan

terhadap detail perancangan, menggunakan struktur kontrol dari desain program

secara prosedural untuk membagi pengujian ke dalam beberapa kasus pengujian.

Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk

mendapatkan program yang benar secara 100%.

Pengujian white box adalah untuk mengetahui cara kerja suatu perangkat

lunak secara internal dan untuk menjamin operasi-operasi internal sesuai dengan

spesifikasi yang telah ditetapkan dengan menggunakan struktur kendali dari prosedur

yang dirancang.

Pelaksanaan pengujian white box adalah sebagai berikut :

1. Menjamin seluruh independent path dieksekusi paling sedikit satu kali.

Independent path adalah jalur dalam program yang menunjukkan paling

sedikit satu kumpulan proses ataupun kondisi baru.

2. Menjalani logical decision pada sisi dan false.

3. Mengeksekusi pengulangan (looping) dalam batas-batas yang ditentukan.

4. Menguji struktur data internal.

Kelebihan white box testing :

51

1. Kesalahan logika. Digunakan pada sintaks „if‟ dan pengulangan. Dimana

white box testingakan mendeteksi kondisi-kondisi yang tidak sesuai dan

mendeteksi kapan proses pengulangan akan berhenti.

2. Ketidaksesuaian asumsi. Menampilkan asumsi yang tidak sesuai dengan

kenyataan, untuk dianalisa dan diperbaiki.

3. Kesalahan ketik. Mendeteksi bahasa pemrograman yang bersifat case

sensitive.

Kelemahan white box testing:

1. Untuk perangkat lunak yang tergolong besar, white box testing dianggap sebagai

strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar

untuk melakukannya.

Tabel 2.9PerbandinganBlack Box Testing dengan White Box Testing

Black Box Testing White Box Testing

Bersifat fungsional Bersifat struktural

Dilakukan oleh penguji independent Dilakukan oleh penguji yang

mengetahui tentang QA (Quality

Assurance )

Melakukan pengujian berdasarkan apa

yang dilihat, hanya fokus terhadap

fungsionalitas dan output. Pengujian

Melakukan testing pada

software/program aplikasi menyangkut

security dan performance program

52

lebih ditujukan pada desain software

sesuai standar dan reaksi apabila

terdapat celah-celah bug pada program

aplikasi tersebut setelah dilakukan

white box testing.

tersebut (meliputi tes code, desain

implementasi, security, data flow,

software failure)

Dilakukan setelah white box testing. Dilakukan seiring dengan tahapan

pengembangan software atau pada

tahap testing.

( Sumber : pressman, 2005 )

.

54

BAB III

METODOLOGI PENELITIAN

Dalam hal ini penulis akan menyampaikan tentang metode pengumpulan data

sebagai berikut :

3.1 Metode Pengumpulan Data

Dalam menyelesaikan skripsi ini diperlukan data-data serta informasi yang

relatif lengkap sebagai bahan yang dapat mendukung kebenaran materi uraian

dan pembahasan. Oleh karena itu, sebelum penulisan skripsi ini dilakukan, penulis

melakukan riset atau penelitian terlebih dahulu untuk mendapatkan data serta

informasi yang terkait.

Adapun metode pengumpulan data yang dilakukan penulis adalah sebagai

berikut:

3.1.1 Studi Pustaka

Penulis membaca dan mempelajari buku-buku dan artikel-artikel

dari internet yang ada kaitannya dengan pengembangan sistem informasi

Administrasi pembelian. Adapun daftar buku dan artikel-artikel terkait

dapat dilihat dalam Daftar Pustaka.

3.1.2 Studi Lapangan

1) Observasi

Penulis melakukan observasi secara langsung pada PT. BANK

ANZ INDONESIA yang dimaksudkan agar dapat mengetahui

secara langsung proses mengenai sistem informasi

Administrasi yang dilakukan, meliputi proses Pencatatan

55

Pembelian Barang, proses Pencatatan pemesanan Barang,

proses administrasi dokumen pendukung lainnya. Kegiatan

observasi dilakukan pada bulan November 2012 di PT. BANK

ANZ INDONESIA

2) Wawancara

Wawancara dilakukan dengan cara melakukan berdiskusi

dengan pihak yang dapat memberikan informasi mengenai

sistem yang berjalan. Penulis melakukan wawancara langsung

dengan beberapa pihak seperti Staff HRD PT. BANK ANZ

INDONESIA, Bapak Kurnia Akbar dan beberapa karyawan

yang terkait dengan sistem ini.

3) Studi Literatur Sejenis

Berikut ini adalah penelitian sejenis yang berkaitan dengan

analisis dan perancangan sistem Pencatatan pembelian barang

PT.Bank ANZ Indonesia

4) Tabel 3.2 Penelitian Sejenis 1

Judul Rancang Bangun Sistem Informasi Pembelian Tunai

Pada Apotek Medika Pratama

Penulis ITA NOVITA

MetodePengembangan Unified Modeling Language (UML)

Tools Ms.Access , VB.NET 2008

Kekurangan

1. Penyimpanan data yang masih rentan

2. Belum ada sistem yang menghubungkan

aplikasi dengan supplier

56

Kelebihan

1. Aplikasi yang mudah digunakan oleh User

2. Mempermudah proses pembelian barang dan

penginputan data barang

3.2 Metode Pengembangan Sistem

Penulis menggunakan metode Rapid Application Development (RAD)

karena menurut penulis, metode ini merupakan metode yang cocok dalam

pengembangan aplikasi ini karena lebih menekankan pada pembuatan aplikasi

dengan pendekatan kepada user dalam mencapai solusi dari permasalahan

yang ada.

Pada alur proses RAD, penulis membatasi dengan hanya melalui beberapa

tahapan yaitu dari InvestigasiAwal sampai dengan tahapan Testing

&Implementation dan selebihnya akan diserahkan kepada pihak perusahaan

dalam mengelola sistem ini.

Adapun dalam tahapan pengembangan sistem ini terdiri dari beberapa

aktifitas yang tentunya sesuai dengan tahapan yang sebelumnya telah

dijabarkan pada alur proses pengembangan sistem. Tahapan tersebut yaitu:

3.2.1 Investigasi Awal

Pada tahap ini, penulis dan user melakukan sejenis pertemuan untuk

menggambarkan permasalahan, menentukan ruang lingkup pengembangan

sistem, mengidentifikasi tujuan dari sistem dan kebutuhan informasi untuk

mencapai tujuan.

3.2.2 Analisa Sistem

Pada tahap ini, penulis menjabarkan tentang permasalahan yang

terjadi pada sistem yang sedang berjalan dan analisis sistem yang diusulkan

57

untuk memperbaiki sistem yang lama. Penulis menggunakan rich picture

dalam memvisualisasi prosedur sistem yang sedang berjalan dan prosedur

sistem usulan. Dalam tahap analisis sistem ini terdapat tiga tahapan, yaitu:

1. Problem Analysis, mempelajari bagaimana sistem sumber daya

manusia yang telah berjalan dan mendefinisikan masalah-masalah

yang terdapat di dalamnya.

2. Requirement Analysis, menganalisa kebutuhan apa saja yang

diperlukan dalam permasalahan sistem sumber daya manusia.

3. Decision Analysis, menentukan solusi yang akan digunakan dalam

mengatasi masalah sistem sumber daya manusia beserta rich picture

sistem yang akan diusulkan.

3.2.3. Desain Sistem

1. Proses

Pada tahap perancangan proses, tools-nya menggunakan diagram-

diagram UML (Unified Modelling Language). Namun tidak semua

diagram yang disediakan oleh UML digunakan oleh penulis dalam

perancangan sistem ini. Hanya beberapa diagram UML saja yang

digunakan oleh penulis, yang menurut penulis dapat mendukung

perancangan aplikasi ini. Adapun diagram yang digunakan oleh penulis

adalah sebagai berikut:

a. Use Case Diagram, pada tahap ini penulis menggambarkan diagram

yang menjelaskan aktifitas yang dilakukan sistem sumber daya manusia

58

yang akan dibangun dan siapa saja actor yang berinteraksi dengan

sistem sumber daya manusia ini.

1) Identifikasi Actor, pada tahap ini penulis mengidentifikasi actor-

actor yang terlibat dalam sistem ini dan apa saja tugas-tugasnya di

dalam sistem sumber daya manusia ini.

2) Perancangan Use Case, pada tahap perancangan use case ini

penulis menggambarkan use case beserta hubungannya dengan

actor-actor yang terlibat di dalam sistem.

3) Use Case Narrative, menjelaskan secara narasi diagram use case

sistem sumber daya manusia ini.

b. Activity Diagram, pada tahap perancangan diagram ini menggambarkan

berbagai alir aktifitas apa yang dilakukan user dan sistem dalam sistem

sumber daya manusia ini, serta bagaimana masing-masing alir berawal

sampai bagaimana mereka berakhir.

c. Sequence Diagram, pada tahap ini penulis menggambarkan diagram

yang menjelaskan secara detail urutan proses yang dilakukan oleh

sistem sumber daya manusia untuk mencapai tujuan dari use case,

interaksi antar class, operasi apa saja yang terlibat, urutan antar operasi

dan informasi yang diperlukan oleh masing-masing operasi.

d. Class Diagram, pada tahap ini penulis menggambarkan diagram yang

menunjukkan hubungan antara class dalam sistem sumber daya

manusia ini dan bagaimana mereka saling berkolaborasi untuk

mencapai suatu tujuan.

59

3.2.1 Desain Database

Pada tahap desain database, penulis merancang database yang

akan digunakan dalam sistem sumber daya manusia ini.

3.2.2 Desain Interface

Pada tahap desain interface, penulis merancang tampilan antar muka

yang sesuai dengan kebutuhan pengguna sehingga sistem informasi sumber

daya manusia ini dapat digunakan secara maksimal oleh pada penggunanya.

3.2.3.1 Pengujian dan Penerapan Sistem

Setelah melakukan analisis dan perancangan sistem,

saatnya sistem untuk diimplementasikan. Pada tahap ini terdapat

beberapa aktifitas-aktifitas yang dimaksud yaitu:

1. Pemrograman

Pada tahap ini hasil desain dimasukkan ke dalam bentuk

bahasa pemrograman yang digunakan agar dapat

dijalankan dalam bentuk aplikasi. Adapun perangkat lunak

yang digunakan dalam proses pemrograman ini adalah

Adobe Dreamweaver CS3 sebagai software editor, Adobe

Photoshop CS3 untuk mengolah gambar, AppServ v2.5.8

yang mencakup: Apache versi 2.2.4 untuk web server,

PHP versi 5.2.1 untuk bahasa pemrograman, dan MySQL

versi 5.0.27 untuk database.

2. Pengujian (Testing)

Pada tahap ini dilakukan uji coba terhadap sistem baru

60

agar dapat digunakan tanpa menemukan kendalaapapun.

Adapun ujicoba yang akan dilakukan menggunakan

metode Black Box Testing. Pada pengujian Black Box

Testing, tidak perlu diketahui apa yang sesungguhnya

terjadi dalam sistem/perangkat lunak. Karena yang diuji

adalah input/output. Pengujian secara Black Box

merupakan pendekatan menguji apakah setiap fungsi di

dalam program dapat berjalan dengan benar. Berikut

beberapa proses yang dilakukan dalam pengujian ini,

yaitu:

1. Fungsi-fungsi yang tidak benar, baik input maupun output.

2. Kesalahan interface.

3. Kesalahan dalam struktur data atau akses database.

3. Perangkat Sistem

Pada tahapan ini melakukan pengaturan perangkat yang

dibutuhkan dalam penerapan aplikasi ini agar dapat berjalan

sesuai dengan yang diharapkan. Adapun perangkat yang

dibutuhkan dalam membangun sistem ini antara lain seperangkat

PC (Personal Computer) sebagai server dan client. Untuk

spesifikasi server dan client dapat dilihat pada Bab IV.

61

3.3 Kerangka Penelitian

Dalam melakukan penelitian ini, penulis melakukan tahapan-tahapan

kegiatan dengan mengikuti rencana kegiatan yang tertuang dalam kerangka

penelitian meliputi metode pengumpulan data dan metode pengembangan

sistemyang dapat dilihat pada gambar 3.1 berikut:

Mulai

Metode

Pengumpulan

Data

Metode

Pengembangan

Sistem

Selesai

Studi Pustaka

Studi Lapangan

Studi Literatur

Sejenis

Observasi

Wawancara

RAD

(Mc Leod, 2008)

Investigasi Awal

Analisis

((whitten 2004)

Desain

Problem Analysis

Requirement

Analysis

Decision Analysis

Analisis Sistem

Berjalan

Sistem Usulan

Proses

Use Case

Diagram

Activity Diagram

Sequence

Diagram

Identifikasi Actor

Perancangan Use

Case

Use Case

Narrative

Class Diagram

Desain Interface

(Dreamweaver)

Desain Database

(MySQL)

Pengujian Black Box Testing

Identifikasi

Masalah

Desain Input/

Output

Profil PT BANK

ANZ INDONESIA

Gambar 3.1 Kerangka Penelitian

58

BAB IV

ANALISIS DAN PERANCANGAN SISTEM

4.1.1 PT.Bank ANZ Indonesia

a. Sejarah Perusahaan

PT. Bank ANZ Indonesia merupakan perusahaan yang berdomisili di

Indonesia, didirikan dengan akte notaris Mudofir Hadi, SH, tanggal 5 September

1990 no. 31, akte ini disetujui oleh Menteri Kehakiman Republik Indonesia

dengan No. C2-5698.HT.01.01.Th.90 tanggal 18 September 1990, didaftarkan

pada Pengadilan Negeri Jakarta dengan No. 1990/1990 tanggal 21 September

1990 dan diumumkan dalam tambahan No. 4374 pada Berita Negara No. 86

tanggal 26 Oktober 1990. Anggaran Dasar Bank Bank telah mengalami beberapa

kali perubahan. Perubahan terakhir dilakukan dalam rangka penyesuaian

terhadap Undang-Undang No. 40/2007 tentang Perseroan Terbatas dilakukan

dengan akte notaris Sri Hasmiyati, SH, tanggal 3 November 2008 No. 03, akte

ini disetujui oleh Menteri Hukum dan Hak Asasi Manusia Republik Indonesia

dengan No. AHU-91701.AH.01.02 Tahun 2008 tanggal 28 Nopember 2008.

Kehadiran ANZ di Indonesia dimulai pada tahun 1973 sewaktu ANZ

Grindlays Bank membangun kantor perwakilannya di Jakarta. Hal ini

memungkinkan perusahaan untuk langsung dapat mengetahui kekuatan ekonomi

Indonesia dan secara khusus mempelajari budaya usaha setempat dan

membangun hubungan dengan pemerintah, bidang usaha dan keuangan.Pada

59

tahun 1993, ANZ mengambil alih kepemilikan 85% saham dari sebuah bank

patungan dan saat ini dikenal sebagai PT. ANZ Panin Bank. 15% sisanya

dimiliki oleh PT. Panin Bank Tbk, salah satu dari sepuluh bank komersial swasta

terbesar di Indonesia yang membawa sentuhan lokal dan keahliannya ke dalam

bank patungan ini. PT. ANZ Panin Bank adalah bank patungan yang

menggabungkan jaringan internasional dan pengalaman ANZ dengan sentuhan

lokal dan keahlian Bank Panin.

PT. ANZ Panin Bank secara resmi mengumumkan perubahan namanya

menjadi PT Bank ANZ Indonesia pada hari Kamis, 12 Januari 2012 di Jakarta.

Perubahan nama ini merefleksikan pertumbuhan bisnis, komitmen, dan strategis

ekspansi pasar ANZ di Indonesia. PT. Bank ANZ Indonesia juga

menggambarkan kepemilikan saham Australia dan New Zealand Banking Group

Limited (ANZ Group) di PT. Bank ANZ Indonesia sebesar 99%. Selain itu

perubahan nama ini merupakan simbol dari komitmen ANZ untuk pertumbuhan

ekonomi di Indonesia sekaligus menegaskan posisi ANZ sebagai investor

terbesar di sektor layanan keuangan asal Australia di Indonesia. Sejalan dengan

keberadaaannya, PT. Bank ANZ Indonesia

Strategi Perusahaan, Para nasabah adalah inti dari semua yang perusahaan

lakukan. Bank berfokus pada penyediaan produk dengan nilai tambah dan

pelayanan transaksi perbankan untuk menarik dan mempertahankan nasabah.

Bank juga selalu berusaha untuk menyeimbangkan penyaluran kredit dengan

60

penghimpunan dana pihak ketiga pada neraca Bank. Sebagai fungsi pendukung

bagi tercapainya tujuanyang telah ditargetkan.

Adapun visi dan misi PT. Bank ANZ Indonesia adalah sebagai berikut:

1) VisiPT. Bank ANZ Indonesia

Menjadi salah satu bank terkemuka di Indonesia yang menempatkan

kebutuhan nasabah sebagai fokus utama kami (To become one of

Indonesia’sleading banks with a strong focus on customer’s needs).

2) MisiPT. Bank ANZ Indonesia

Indonesia sedang dalam perjalanan yang sangat berarti dalam membangun

bank yang memimpin dengan kapabilitas perbankan di bidang korporasi, ritel

dan kartu kredit.Perusahaan melayani segmen nasabah yang luas dan

mengarah pada bank yang berorientasi pada hubungan dengan nasabah

dengan membangun value jangka panjang yang berkesinambungan bagi

nasabah dan Bank. Indonesia adalah salah satu pasar kunci bagi ANZ Grup

dan menjadi bagian yang penting bagi rencana keseluruhan ANZ Grup untuk

menjadi Super Regional Bank yang mencakup kawasan AustralAsia.

b. Struktur Organisasi

Struktur Organisasi adalah suatu susunan dan hubungan antara tiap bagian

serta posisi yang ada pada suatu organisasi atau perusahaan dalam

menjalankan kegiatan operasional untuk mencapai tujuan. Struktur Organisasi

menggambarkan dengan jelas pemisahan kegiatan pekerjaan antara yang satu

dengan yang lain dan bagaimana hubungan aktivitas dan fungsi dibatasi.

61

Dalam struktur organisasi yang baik harus menjelaskan hubungan wewenang

siapa melapor kepada siapa. Organisasi merupakan kerjasama diantara

beberapa orang untuk mencapai suatu tujuan dengan mengadakan

pembagian dan peraturan kerja. Yang menjadi ikatan kerjasama dalam

organisasi adalah tercapainya tujuan secara efektif dan efisien. Wewanang

dan tanggung jawab pimpinan serta anggota organisasi dirumuskan sesuai

dengan struktur kedudukan mereka didalam organisasi. Dalam struktur ini

akan tampak lebih jelas dan tegas bila dituangkan dalam badan terstuktur,

karena akan memberikan pengertian yang mudah tentang garis wewenang dan

tanggung jawab kepada organisasi yang bersangkutan.

Berikut ini adalah struktur organisasi dari PT. Bank ANZ Indonesia unit

Payment and Cash Operation.

Gambar 4.1Struktur Organisasi PT. Bank ANZ Indonesia – Payment & Cash

Operation (PCO)

(Sumber: PT. Bank ANZ Indonesia)

HEAD OF PAYMENT CASH

AND OPERATION

MANAGER

CASH AND OPERATION Staff PCO

Staff PCO

Staff PCO

62

c. Tugas dan Wewenang Dari Struktur Organisasi

Adapun pembagian tugas dan tangggung jawab dari masing-masing bagian

yang terdapat dalam PT. Bank ANZ Indonesia adalah sebagai berikut:

1) Head of Payment & Cash Operation

Head of Payment & Cash Operation melakukan pengawasan atas

berlangsungnya proses kegiatan di bidang perbankan PT. Bank ANZ

Indonesia khususnya di Payment & Cash Operation. Menetapkan

peraturan-peraturan dan ketentuan-ketentuan serta kebijakasanaan

terhadap pekerjaan serta bertanggung jawab terhadap pegawai yang

bekerja dan menerima laporan perkembangan Payment & Cash

Operation.

2) Manager Payment Operation

Manager Payment Operation mempunyai tanggung jawab sebagai

berikut :

a. Mengelola Payment Operation.

b. Mengatur dan mengawasai pelaksanaan kegiatan Payment

Operation.

c. Memimpin rapat.

3) Team Leader

Team Leader mempunyai tugas dan tanggung jawab sebagai berikut :

a. Memonitor pekerjaan Staff PCO.

63

b. Mengawasi kedisiplinan Staff PCO sesuai dengan aturan yang telah

ditetapkan.

c. Mengatur dan mengawasi produktifitas pegawai.

4.2 Uraian Prosedur

Proses pembelian barang pada PT. Bank ANZ Indonesia unit Payment and

Cash Operation ini terdiri dari beberapa tahap, yaitu:

4.2.1 Proses Pemesanan Barang

Sebelum staff PCO membuat form pemesanan barang, langkah pertama

yang dilakukan adalah melakukan konfirmasi kepada pihak supplier via

telepon, hal ini bertujuan untuk mengantisipasi terjadinya pengiriman barang

secara berkala dan guna meng-update stok barang yang tersedia di supplier

pada sistem pembelian barang di PCO. Setelah terjadi kesepakatan bersama

antara pihak supplier dan staff PCO, barulah staff PCO membuat form

pemesanan barang. Kemudian staff PCO menyerahkan form pemesanan

barang tersebut kepada supplier, setelah pihak supplier menerima form

pemesanan barang maka supplier akan menyiapkan barang dan kemudian

membuatkan kwitansi dan surat jalan yang nantinya akan diserahkan

bersamaan pada saat pengiriman barang yang dipesan.

4.2.2 Proses Terima Barang

Pada saat proses terima barang, supplier akan mengirimkan barang yang

sudah dipesan berdasarkan dengan form pemesanan yang diterima beserta

dengan kwitansi dan surat jalan. Kemudian staff PCO menerima barang

64

beserta dengan kwitansi dan surat jalan. Setelah terjadi proses terima barang,

maka staff PCO akan melakukan pengecekan kondisi barang apakah baik atau

sesuai dengan yang tertera di form pemesanan. Apabila kondisi barang rusak

atau tidak sesuai dengan apa yang tertera pada form pemesanan, maka staff

PCO akan meretur barang tersebut dengan membuatkan konfirmasi

menggunakan copy form pemesanan barang yang telah diberi keterangan

berapa banyak jumlah barang yang diretur beserta dengan alasannya yang

mana akan diberikan kembali kepada supplier. Setelah supplier menerima

konfirmasi dan barang yang diretur, supplier akan menyiapkan pengganti

barang yang diretur dan kemudian akan mengirimkan kembali dengan barang

yang baru.

4.2.3 Proses Pembayaran Barang

Setelah terjadi proses terima barang maka staff PCO akan melakukan

proses pembayaran via transfer melalui Sistem Kliring Nasional(SKN)

berdasarkan kwitansi yang diterima, dan setelah selesai melakukan proses

transfer staff PCO membuatkan bukti bayar yang kemudian bukti bayar

tersebut akan diserahkan kepada supplier.

4.2.4 Proses Pembuatan Laporan

Setiap bulannya Staff PCO membuat laporan pemesanan dan laporan

bukti bayar yang akan diserahkan kepada pimpinan PCO.

65

4.3 Analisa Sistem Berjalan

Berdasarkan hasil observasi dan wawancara yang dilakukan penulis terhadap

user yang terlibat, maka dapat dijelaskan sistem yang sedang berjalan saat ini di PT.

Bank ANZ Indonesia dalam rich picture berikut ini:

Staff PCO

Suppliers

Membuat PO

. Mengirim Barang

PT. Bank ANZ

Indonesia

Gudang

Barang

Sesuai?

. Memeriksa Kondisi

Barang

.(Jika Ya) Masuk Gudang

. (Jika Tidak)Bukti Retur Barang

Pay to$

kwitansi

. Melakukan Pembayaran

. Membuat Laporan Pembayaran

Laporan Pembayaran

Pimpinan PCO

Laporan Terima Barang

Laporan terima Barang

Gambar 4.2Rich PictureSistem Berjalan

66

4.4 Identifikasi Masalah

Di dalam mengidentifikasi masalah, penelitian menganalisa sistem yang

berjalan. Penelitian menemukan masalah yang terjadi pada proses pencatatan dalam

Pembelian barang, pemesanan Barang dan invoice bersifat manual yaitu pada kertas.

Penggunaan media penyimpanan kertas akan berakibat rentan terhadap kehilangan

data ataupun rusak.

Karyawan menggunakan software Microsoft Excel dalam menginput data –

data dari kertas ketika dibuatkan laporan. Membutuhkan ketelitian yang tinggi,

sehingga karyawan merasa sulit dalam mengelola data – data Barang yang sudah

dibeli atau yang akan dipesan

Membutuhkan 1 hari kerja pada proses pencarian data Pembelian barang,

pemesanan Barang. Mengakibakan proses pembuatan laporan dirasakan terlalu lama,

sehingga pembuatan kebijakan untuk pemesanan serta Pembelian Barang yang

dilakukan oleh Pimpinan PCO membutuhkan proses yang lama dan rumit.

Untuk memudahkan pihak perusahaan PT Bank ANZ Indonesia khususnya

pada bagian Staff PCO dalam proses Pencatatan, maka dikira perlu penulis

membangun sistem informasi Pencatatan pembelian barang yang dapat memangkas

waktu lebih cepat dan efisien dalam mengakses dan menganalisis data dalam

pengambilan keputusan.

4.4.1 Requirement Analysis

Requirement Analisis dibagi menjadi 2 (dua) bagian. Bagian yang pertama

adalah Functional Requirement yaitu proses dan fungsi yang harus disediakan oleh

67

sistem yang dikembangkan. Bagian yang kedua adalah Nonfunctional Requirement

yaitu fitur-fitur lain yang diperlukan oleh sistem informasi administrasi agar dapat

lebih memuaskan pengguna sistem ini.Berikut ini adalah requirements dari sistem

informasi administrasi

4.4.1.1 Functional Requirement

Sistem yang dikembangkan harus mempunyai functional requirements

sebagai berikut:

1. Bagian Staff PCO ditunjuk sebagai Admin untuk menggunakan sistem ini

untuk input data Pembelian barang serta data Pemesanan barang yang akan

digunakan sebagai laporan terhadap pimpinan PCO. Laporan tersebut akan

digunakan sebagai bahan dalam mengambil suatu keputusan dalam

mengambil kebijakan pemesanan dalam perusahaan.

2. Pimpinan PCO Bisa mengakses sistem ini untuk melihat data barang apa saja

yang telah masuk didalam sistem pencatatan pembelian barang.

4.4.1.2 Nonfunctional Requirement

Nonfunctional Requirement dari sistem informasi pemesanan yang

dikembangkan adalah sebagai berikut :

68

Tabel 4.1Nonfunctional Requirement

Jenis Kebutuhan Penjelasan

Performance Membantu admin dalam mengelola data pembelian.pemesanan

barang

Information Mencegah hilangnya data-data mengenai Pembelian, pemesanan,

.yang sebelumnya masih menggunakan kertas.

Economic Mengurangi penggunaan kertas sebagai media penyimpanan.

Efficiency Mempercepat waktu dalam perekapan dan penyajian laporan

pembelian dan pemesananyang updatekepada Pimpinan PCO.

Effectiveness Kegiatan pencatatan Pembelian, pemesanan dalam satu sistem.

4.4.2 Analisa Keputusan (Decition Analysis)

Dari tahapan analisis sebelumnya telah diketahui permasalahan dari sistem

yang sedang berjalan, persyaratan dan kebutuhan yang diinginkan, maka tahapan

selanjutnya adalah analisis keputusan yaitu menentukan komponen-komponen dari

sistem usulan yang akan dirancang, dibangun, dan diimplementasikan. Berikut

merupakan komponen-komponen yang dibutuhkan:

1. Data Master

Proses perekaman data-data yang berhubungan dengan Pencatatan Pembelian

Barang, yaitu dataBarang, data Supplier, data Data Karyawan, dan data invoice.

Seluruh data ini terkait pada proses Administrasi Pembelian Barang.

2. Menentukan Hak Akses (user)

Dalam hal ini sistem harus dibatasi sesuai dengan level user yang berhak

memakai sistem ini. Setiap pengguna hanya dapat mengakses fitur-fitur dalam

69

sistem sesuai bagiannya masing-masing.

Setelah mengetahui komponen-komponen sistem yang diusulkan selanjutnya

adalah menentukan jenis perangkat sistem yaitu berupa tools atau alat untuk

merancang dan mengimplementasikan sistem usulan sehingga menghasilkan

arsitektur sistem usulan dan yang terpenting adalah pemahaman terhadap jenis tools

yang akan digunakan karena harus sesuai dengan kebutuhan pengguna dan fungsi-

fungsi sistem yang terdapat didalamnya.

Di dalam sistem yang lama, proses pengolahan datanya dilakukan secara manual,

sedangkan pada sistem informasi administrasi yang akan dikembangkan adalah

sistem informasi terkomputerisasi dan konsep pengembangan aplikasi ini

menggunakan UML (Unified Model Language). Sedangkan bahasa pemrograman

menggunakan PHPdan mengimplementasikan sistem database menggunakan

MySQL

.

4.5 Rich Picture Sistem Usulan

Setelah mendefinisikan permasalahan pada sistem berjalan, maka penulis

membuat sistem usulan. Pada sistem usulan ini, penulis memberikan informasi

mengenai rancangan sistem informasi administrasi pembelian barang yang penulis

ajukan guna mengatasi permasalahan pada sistem lama yang telah disebutkan

sebelumnya.

70

Adapun prosedur dari perancangan sistem informasi pembelian barang yang

diusulkan adalah sebagai berikut:

Manager PCO Staff PCO

Sistem administrasi Pembelian Barang

Cetak Laporan

Cetak Invoice

Input data barang

input data supplier

input data pegawai

Cetak tanda terima

Cetak Pembelian

Cetak Pemesanan

Cetak laporan

Database Server

Penyimpanan

Database

Gambar 4.3 Rich Picture Sistem Usulan

Sistem informasi administrasi Pembelian barang ini

1. Mempermudah Pimpinan PCO selaku eksekutif perusahaan dalam hal melihat

segala macam laporan diantaranya pesanan Pembelian, Dan Data Barang

,Pimpinan PCO dapat memperoleh data-data yang berkaitan dengan data

Pembelian Barang, dengan cepat dan update.

2. Bagian Admin dapat dengan mudah manage data Barang, manage data Supplier,

input data barang, dan dalam Pembuatan laporan .

4.6 Perancangan Sistem (Desain)

Pada tahap ini, penulis memberikan informasi mengenai rancangan sistem

yang penulis ajukan guna menanggulangi permasalahan-permasalahan sistem yang

telah disebutkan sebelumnya.

4.6.1 Proses Desain

71

4.6.1.1 Use Case Model Diagram

4.6.1.1.1 Identifikasi Actor

Identifikasi actor ditujukan untuk mengidentifikasi apa saja yang

dilakukan oleh para actor dalam sistem informasi administrasi pembelian

barang ini. Adapun actor yang terlibat dalam sistem pemesanan

programumrohini dapat diklasifikasikan sesuai dengan tugasnya menjadi

2 (dua) actor, yaitu Staff PCO dan Manager/Pimpinan PCO. Untuk lebih

jelasnya peran-peran actor yang ada dalam sistem informasi pemesanan

program umrohdilihat pada Tabel 4.2 :

Tabel 4.2 Identifikasi Actor

Actor Description

Pimpinan PCO Pimpinan PCO dalam sistem ini berperan sebagai

eksekutif yang bertugas menerima laporan-laporan

mengenai data-data didalam sistem administrasi

Pembelian Barang

Staff PCO Staff PCO bertindak sebagai admin dalam sistem ini,

yaitu mengelola file data master, seperti entry data

karyawan, barang, supplier

4.6.1.1.2 Identifikasi Use Case

Setelah actor teridentifikasi, tahapan selanjutnya dalam

perancangan sistem administrasi Pembelian Barang ini adalah

mengidentifikasi usecase. Berikut deskripsi dari tiap use case yang

terdapat dalam Tabel 4.3:

72

Tabel 4.3Identifikasi Use Case

No Use Case Name Description Actor

1 Login Use case ini menggambarkan kegiatan

login untuk mengakses sistem

informasi pencatatan ini sesuai

dengan level user yang mengakses.

Staff PCO , Pimpinan

PCO

2 Entry data barang Use Case ini menggambarkan

kegiatan entry data barang pada

sistem

Staff PCO

3 Entry data suplier Use Case ini menggambarkan

kegiatan entry data supplier admin.

Staff PCO

4 Entry data

pegawai

Use Case ini menggambarkan

kegiatan entry data pegawai

Staff PCO

5 Cetak SP Use Case ini menggambarkan

kegiatan cetak Bukti Surat Pesanan

yang telah di input sebelumnya

Staff PCO

6 Cetak Tanda

Terima


kegiatan cetak Bukti Laporan tanda

terima Barang

Staff PCO

7 Cetak Bukti

Bayar


kegiatan Cetak bukti Laporan tanda

bayar

Staff PCO

8 Cetak Laporan

Pesanan


kegiatan cetak bukti laporan surat

pesanan

Staff PCO

9 Cetak Laporan

Penerimaan


kegiatan mencetak Invoice

Staff PCO

10 Cetak laporan

pembayaran


kegiatan cetak laporan pembayaran

Staff PCO

11 Cetak laporan

retur


kegiatan cetak bukti laporan retur

barang

Staff PCO

73

12 Logout Use Case ini menggambarkan user

keluar dari aplikasi

Staff PCO

4.7 Use Case Diagram

Gambar 4.4Use Case Diagram Sistem Administrasi Pembelian PT. Bank ANZ

Indonesia

4.8 Use Case Narative

1. Use Case : Entry Data Barang

Aktor : Staff PCO

Tujuan : Mencatat Persediaan Barang

Deskripsi :

(1) Staff PCO Memilih menu file entry data

barang.

74

(2) Staff PCO memasukan data barang.

(3) Staff PCO menyimpan data barang dengan

menekan tombol simpan.

(4) Staff PCO mengubah data barang dengan

menekan tombol cari, pilih data yang ingin

diubah kemudian tekan tombol simpan.

(5) Staff PCO menghapus data barang dengan

menekan tombol cari, kemudian tekan tombol

hapus.

2. Use Case : Entry Data Supplier

Aktor : Staff PCO

Tujuan : Menyimpan Data Supplier

Deskripsi :

(1) Staff PCO memilih menu file entry data

supplier.

(2) Staff PCO memasukan data supplier.

(3) Staff PCO menyimpan data supplier dengan


(4) Staff PCO mengubah data supplier dengan



(5) Staff PCO menghapus data supplier dengan

75


dihapus kemudian tekan tombol hapus.

3. Use Case : Entry Data Pegawai

Aktor : Staff PCO

Tujuan : Menyimpan Data Pegawai

Deskripsi :

(1) Staff PCO memilih file entry data Pegawai

(2) Staff PCO memasukan data Pegawai

(3) Staff PCO menyimpan data pegawai dengan

menekan tombol simpan

(4) Staff PCO mengubah data pegawai dengan



(5) Staff PCO menghapus data pegawai dengan


dihapus kemudian tekan tombol hapus.

4. Use Case : Cetak SP

Aktor : Staff PCO

Tujuan : Mencatat SP

Deskripsi :

(1) Staff PCO memilih file entry surat pesanan.

76

(2) Staff PCO memasukan data surat pesanan.

(3) Staff PCO Menyimpan data surat pesanan

dengan menekan tombol simpan.

(4) Staff PCO mengubah data surat pesanan

dengan menekan tombol cari, pilih data yang

ingin diubah kemudian tekan tombol simpan.

(5) Staff PCO menghapus data surat pesanan

dengan menekan tombol cari, pilih data yang

ingin dihapus kemudian tekan tombol hapus.

5. Use Case : CetakTanda Terima Barang

Aktor : Staff PCO

Tujuan : Mencatat Tanda Terima Barang

Deskripsi :

(1) Staff PCO memilih file entry tanda terima

barang.

(2) Staff PCO memasukan nomor SP.

(3) Staff PCO menyimpan data tanda terima

barang dengan menekan tombol simpan.

(4) Staff PCOmencetak data tanda terima barang

dengan menekan tombol cari pada nomor SP,

pilih data yang ingin dicetak kemudian tekan

tombol cetak TTB.

77

6. Use Case : CetakBukti Bayar

Aktor : Staff PCO

Tujuan : Mencatat Bukti Bayar

Deskripsi :

(1) Staff PCO memilih file entry bukti bayar.

(2) Staff PCO memasukan nomor TTB.

(3) Staff PCO menyimpan data bukti bayar dengan


(4) Staff PCOmencetak data bukti bayar barang

dengan menekan tombol cari pada nomor TTB,

pilih data yang ingin dicetak kemudian tekan

tombol cetak bukti bayar.

7. Use Case : Cetak Retur

Aktor : Staff PCO

Tujuan : Mencatat Retur

Deskripsi :

(1) Staff PCO memilih file entryretur.

(2) Staff PCO memasukan nomor TTB.

(3) Staff PCO menyimpan data retur barang

dengan menekan tombol simpan.

(4) Staff PCO mencetak data returbarang dengan

menekan tombol cari pada nomor TTB, pilih

78

data yang ingin dicetak kemudian tekan

tombol cetak.

8. Use Case : Cetak Laporan Pemesanan.

Aktor : Staff PCO dan Pimpinan PCO

Tujuan : Mencetak Laporan Pemesanan Barang

Deskripsi :

(1) Staff PCO membuka form cetak laporan

pemesanan.

(2) Staff PCO memilih periode waktu yang

diinginkan untuk ditampilkan padaform

laporan pemesanan.

(3) Staff PCO menekan tombol cetak, kemudian

sistem akan menampilkan laporan pemesanan.

(4) Staff PCO menekan tombol keluar untuk

keluar dari form laporan pemesanan.

9. Use Case : Cetak Laporan Penerimaan


Tujuan : Mencetak Laporan Penerimaan Barang

Deskripsi :


Penerimaan.

79

(2) Staff PCO memilih periode waktu yang

diinginkan untuk ditampilkan pada form

laporan Penerimaan Barang


sistem akan menampilkan laporan

penerimaan.


keluar dari form laporan penerimaan.

10. Use Case : Cetak Laporan Pembayaran


Tujuan : Mencetak Laporan Pembayaran

Deskripsi :


Pembayaran.

(2) Staff PCOmemilih periode waktu yang


laporan Pembayaran.


sistem akan menampilkan laporan

Pembayaran.


keluar dari form laporan Pembayaran.

80

11. Use Case : Cetak Laporan Retur


Tujuan : Mencetak Laporan Retur

Deskripsi :

(1) Staff PCO membuka form cetak laporan Retur.

(2) Staff PCOmemilih periode waktu yang


laporan Retur.


sistem akan menampilkan laporan Retur.


keluar dari form laporan Retur.

4.9 Activity Diagram

Activity Diagram menggambarkan aktifitas-aktifitas yang terjadi dalam sistem

dan user. Berikut ini adalah activity diagram yang terdapat pada sistem informasi

pencatatan pembelian Barang:

81

1. Activity Diagram login

Gambar 4.6Activity Diagram login

Pada activity diagram login ini, user yang terdiri dari Staff PCO dan

PimpinanPCO harus mengisikan username dan password terlebih dahulu untuk

dapat mengakses sistem informasi Administrasi ini. Setelah berhasil memasukkan

username dan password lalu sistem memverfikasi username dan passworduser dan

menampilkan halaman utama sesuai dengan leveluser.

4.10 Sequence Diagram

Sequence diagram ini menjelaskan secara detail urutan proses yang dilakukan

dalam sistem untuk mencapai tujuan dari use case, digambarkan pada sequence

diagram berikut ini:

act Activ ity Diagram Lo...

SistemJamaah, Admin, Manager

mulai

password &

username

sesuai?

masukkan user namedan password

menampilkan halamanhome user

log out

selesai

benar

salah

82

a. Sequence DiagramEntry Data Barang

Gambar 4.6 Sequence DiagramEntry Data Barang

b. Sequence DiagramEntry Data Supplier

: Staff PCO : FrmDtBarang : Ctr Barang : Barang

Buka( ) getMaxKdBrg( ) auto_KdBarang( )

Tampil_KdBarang()

Isi_Dt_Barang() Isi_Dt_Barang() Isi_Dt_Barang()

Tambah( ) save( ) simpan_Barang( )

Cari_KdBarang() getAllDtBrg( ) get_Barang( )

Tampi_Dt_Barang()

Ubah( ) save( ) ubah_Barang( )

Batal( ) Batal()

Keluar( ) Keluar()

83

Gambar 4.7 Sequence DiagramEntry Data Supplier

: Staff PCO : FrmDtSupplier : CtrSupplier : Supplier

Buka( ) getMaxKdSupplier( ) auto_kdsupplier( )

Tampil_KdSupplier( )

Isi_Data_Supplier( )Isi_Data_Supplier( )Isi_Data_Supplier( )

Tambah( ) save( ) simpan_supplier( )

Cari_KdSupplier( ) getAllDtSupplier( ) get_supplier( )

Ubah( )

Tampil_Data_Supplier ( )

save( ) simpan_supplier( )

Batal( ) Batal( )

Keluar( ) Keluar( )

84

c. Sequence DiagramEntry Data Pegawai

Gambar 4.8 Sequence DiagramEntry Data Pegawai

: Staff PCO : FrmDtPegawai : CtrPegawai : Pegawai

Buka( ) getMaxKdPegawai( ) auto_KdPeg( )

Tampil_KdPegawai( )

Isi_Data_Pegawai( )Isi_Data_Pegawai( )Isi_Data_Pegawai( )

Tambah( ) save( ) simpan_pegawai( )

Cari_KdPegawai getAllDtPegawai( ) get_pegawai( )

Tampil_Data_Pegawai( )

Ubah( ) save( ) simpan_pegawai( )

Batal( ) Batal( )

Keluar( ) Keluar( )

85

d. Sequence Diagram Cetak Surat Pesan

Gambar 4.39 Sequence Diagram Cetak Surat Pesan

86

e. Sequence Diagram Cetak TTB

Gambar 4.40Sequence DiagramEntryTanda Terima Barang

87

f. Sequence DiagramCetak Bukti Bayar

Gambar 4.41 Sequence Diagram Cetak Bukti Bayar

88

g. Sequence Diagram Cetak Retur

Gambar 4.42 Sequence Diagram Cetak Retur

89

h. Sequence Diagram Cetak Laporan Pesanan

:Staff PCO

Cetak()Cetak()

GetSP()

Keluar()

Keluar()

Show Report()

:SP:FrmTampilTglPesan :CtrSP :Supplier :Barang :Pesan

GetPegawai()

GetBarang()

GetPesan()

:Pegawai

GetSupplier()

Buka()

Input_Periode

Input_Periode()

Gambar 4.43 Sequence Diagram Cetak Laporan Pesanan

90

i. Sequence Diagram Cetak Laporan Penerimaan

:Staff PCO

Cetak()Cetak()

GetTTB()

Keluar()

Keluar()

Show Report()

:TTB:FrmTampilTglTerima :CtrTTB :Pesan :Barang :Supplier

GetSP()

GetBarang()

GetSupplier()

:SP

GetPesan()

Buka()

Input_Periode

Input_Periode()

Gambar 4.44 Sequence Diagram Cetak Laporan Penerimaan

91

j. Sequence Diagram Cetak Laporan Pembayaran

:Staff PCO

Cetak()Cetak()

Get BuktiBayar()

Keluar()

Keluar()

Show Report()

:BuktiBayar:FrmTampilTglBayar :CtrBB :SP :Supplier :Pesan

Get TTB()

Get Supplier()

Get Pesan()

:TTB

Get SP()

Buka()

Input_Periode

Input_Periode()

Gambar 4.45Sequence Diagram Cetak Laporan Pembayaran

92

k. Sequence Diagram Cetak Laporan Retur

:Staff PCO

Cetak()Cetak()

GetRetur()

Keluar()

Keluar()

Show Report()

:Retur:FrmTampilTglRetur :CtrRetur :SP :Supplier :Pesan :Kembali

GetTTB()

GetSupplier()

GetPesan()

GetKembali()

:TTB

GetSP()

Buka()

Input_Periode

Input_Periode()

:Barang

GetBarang()

Gambar 4.46 Sequence Diagram Cetak Laporan Retur

93

4.10.1 Rancangan Class Diagram (Entity, Boundary & Control Class)

4.10.1.1 Entity Class

+auto_kdsupplier()

+cari_supplier()

+get_supplier()

+tampil_supplier()

+simpan_supplier()

+ubah_supplier()

+hapus_supplier()

-kd_sup

+nm_sup

+alamat

+no_tlp

+fax

+no_rek

supplier

+auto_nosp()

+cari_sp()

+get_sp()

+tampil_sp()

+simpan_sp()

+ubah_sp()

+hapus_sp()

-no_sp

+kd_sup

+tgl_sp

+nip

sp

+setkodeBarang()

+simpan_barang()

+get_barang()

+hapus_barang()

-kd_brg : String

+nm_brg : String

+satuan : String

+harsat : Double

+stok : Double

barang

1

1..* 1..*

1..*

+cari_pesan()

+get_pesan()

+tampil_pesan()

+simpan_pesan()

+ubah_pesan()

-no_sp

-kd_brg

+jml_pesan

+hrg_pesan

pesan

+auto_nobb()

+cari_bb()

+get_bb()

+tampil_ttb()

+simpan_ttb()

-no_bukti

+tgl_bukti

+jmlBayar

BuktiBayar

+auto_nottb()

+cari_ttb()

+get_ttb()

+tampil_ttb()

+simpan_ttb()

-no_ttb

+tgl_ttb

+no_refsj

+tgl_refsj

+no_refkwit

+tgl_refkwit

-no_sp

ttb

1

1

1

1

+auto_kdpeg()

+cari_pegawai()

+get_pegawai()

+tampil_pegawai()

+simpan_pegawai()

+ubah_pegawai()

+hapus_pegawai()

-NIP

+nm_peg

l

1

1..*

+get_kembali()

+simpan_kembali()

-no_retur

+kd_brg

+jml_retur

+ket

kembali

+auto_noretur()

+cari_retur()

+get_retur()

+tampil_retur()

+simpan_retur()

-no_retur

+tgl_retur

+no_ttb

retur

1

1

1 1..*

1

0..*

94

4.10.2 Rancangan Keluaran

Rancangan keluaran yang dihasilkan oleh Rancangan Sistem Informasi

Pencatatan Pembelian Barang pada PT. Bank ANZ Indonesia unit Payment and

Cash Operationyang dirancang adalah sebagai berikut :

1) Nama Keluaran : SP.

Fungsi : Bukti atas terjadinya proses pemesanan barang.

Media : Kertas.

Distribusi :Supplier.

Rangkap : 1 (satu).

Frekuensi : Setelahada data Pemesanan.

Volume : 1 kali perbulan.

Keterangan : Dibuat setiap melakukan pemesanan barang.

2) Nama Keluaran : TTB.

Fungsi : Bukti atas terjadinya proses terima barang.

Media : Kertas.

Distribusi : Supplier.

Rangkap : 1 (satu).

Frekuensi : Setelah barang diterima dari pihak supplier.


Keterangan : Dibuat setiap staff PCO menerima barang dari

supplier.

95

3) Nama Keluaran : Bukti Bayar.

Fungsi : Bukti atas terjadinya transaksi pembayaran.

Media : Kertas.


Rangkap : 1 (satu).

Frekuensi : Setelah pihak PCO melakukan pembayaran.


Keterangan : Dibuat setiap staff PCO melakukan proses

pembayaran ke supplier.

4) Nama Keluaran : Retur.

Fungsi : Bukti atas terjadinya retur terhadap barang yang

rusak.

Media : Kertas.


Rangkap : 1 (satu).

Frekuensi : Setiap ada barang yang ingin diretur.


Keterangan : Dibuat setiap staff PCO melakukan proses retur

barang ke supplier.

5) Nama Keluaran : Laporan Pemesanan.

Fungsi : Sebagai laporan pemesanan.

Media : Kertas.

96

Distribusi : Pimpinan PCO.

Rangkap : 1 (satu).

Frekuensi : Setiap akhir bulan.


Keterangan : Berisi laporan mengenai data pemesanan sesuai

dengan periode yang dibutuhkan.

6) Nama Keluaran : Laporan Penerimaan.

Fungsi : Sebagai laporan penerimaan.

Media : Kertas.


Rangkap : 1 (satu).


Volume : 1 kali perbulan

Keterangan : Berisi laporan mengenai data penerimaan sesuai


7) Nama Keluaran : Laporan Pembayaran.

Fungsi : Sebagai laporan pembayaran.

Media : Kertas.


Rangkap : 1 (satu).



97

Keterangan : Berisi laporan mengenai data pembayaran sesuai


8) Nama Keluaran : Laporan Retur.

Fungsi : Sebagai laporan retur.

Media : Kertas.


Rangkap : 1 (satu).



Keterangan : Berisi laporan mengenai data retur sesuai dengan

periode yang dibutuhkan.

4.10.3 Rancangan Masukan

Rancangan masukan yang dihasilkan oleh Sistem InformasiPembelian

Barang pada PT. Bank ANZ Indonesia yang dirancang adalah sebagai berikut :

1) Nama Masukan : Data Pegawai.

Fungsi : Untuk mengetahui data-data pegawai.

Sumber : Pimpinan PCO.

Media : Kertas.

Rangkap : 1 lembar.

Frekuensi : Tidak tentu.

Volume : Tidak tentu.

Format : Lampiran D-1 halaman 95

98

Keterangan : Berisi data-data pegawai

2) Nama Masukan : Data Barang.

Fungsi : Untuk mengetahui data-data barang.

Sumber : Supplier.

Media : Kertas.

Rangkap : 1 lembar.

Frekuensi : Setiap terjadi penambahan data barang.



Keterangan : Berisi tentang data barang.

3) Nama Masukan : Data Supplier.

Fungsi : Untuk mengetahui data-data supplier.

Sumber : Supplier.

Media : Kertas.

Rangkap : 1 lembar.

Frekuensi : Tidak tentu.



Keterangan : Berisi data-datasupplier.

4) Nama Masukan : Bukti Surat Pemesanan.

Fungsi : Digunakan sebagai data pemesanan barang ke

supplier.

99

Sumber : Supplier.

Media : Kertas.

Rangkap : 1 lembar.

Frekuensi : Setiap terjadinya proses pemesanan barang ke

supplier.


Keterangan : Di entry sebagai surat pesan (SP).

5) Nama Masukan : TTB.

Fungsi : Digunakan sebagai data tanda terima barang.

Sumber : Supplier.

Media : Kertas.

Rangkap : 1 lembar.

Frekuensi : Setiap terjadinya proses penerimaan barang.


Keterangan : Di entry sebagai tanda terima barang (TTB).

6) Nama Masukan : Retur.

Fungsi : Digunakan sebagai data retur barang.

Sumber : PCO.

Media : Kertas.

Rangkap : 1 lembar.

Frekuensi : Setiap terjadinya proses retur barang.


100

Keterangan : Di entry sebagai retur.

4.10.4 Struktur Tampilan

Menu Utama

Transaksi

File Master

Laporan

Entry Data

Barang

Entry Data

Supplier

Entry Surat

Pesanan

Entry Tanda

Terima Barang

Cetak Laporan

Pemesanan

Cetak Laporan

Penerimaan

Cetak Laporan

PembayaranEntry Bukti Bayar

Entry Data

Pegawai

Entry Retur Cetak Laporan

Retur

Gambar 4.20Struktur Tampilan

4.11 Rancangan Basis Data

4.11.1 Entity Relationship Diagram (ERD)

Entity Relationship Diagram (ERD) atau Diagram ER adalah suatu model

teknik pendekatan yang menyatakan atau menggambarkan hubungan suatu

model. Di dalam hubungan tersebut dinyatakan utama dari penggambaran

diagram ER-D. ER-D digunakan untuk menunjukan obyek data (entity) dan

101

hubungan (Relationship) yang ada pada entity berikutnya. Adapun Langkah-

langkah teknis dalam membuat ER-D adalah sebagai berikut:

1) Mengidentifikasi dan menetapkan seluruh himpunan entitas yang akan

terlibat. Entitas-entitias dibawah ini didapatkan dari dokumen usulan,

yang sudah di standarisasi. Karena dokumen yang sedang berjalan masih

terdapat kekurangan dan belum terstandarisasi.

pegawai spsupplier barang

pesan ttb buktibayarretur

kembali

Gambar 4.21 Entitas yang terlibat dalam sistem

2) Menentukan atribut-atribut key dari masing-masing himpunan entitas.

Atribut-atribut didapat dari dokumen usulan, karena dokumen sudah

terlebih dahulu distandarisasi.

102

3) Menentukan Primary-key pada tiap-tiap entitas.

pegawai spsupplier barang

pesan ttb buktibayar retur

*nip nm_peg

*kd_sup nm_sup alamat no_tlp fax no_rek

*kd_brg nm_brg satuan harsat stok

*no_sp tgl_sp kd_sp nip

*no_sp*kd_brg jml_pesan hrg_pesan

*no_ttb no_refsj tgl_refsj no_refkwit tgl_refkwit no_sp

*no_bukti tgl_bukti no_rek jmlbayar no_ttb

*no_retur tgl_retur no_ttb

kembali

*no_retur*kd_brg jml_retur keterangan

Gambar 4.22Entitas dan atribut-atribut

103

4) Menentukan derajat dan cardinality rasio relasi untuk setiap himpunan

relasi.

pegawai

barangsupplier sp

returttbbuktibayar

buat

cetak

pesan

kembali

ada

cetak

terima

*nip nm_peg


*no_sp*kd_sup

*no_bukti tgl_bukti jml_bayar

*no_ttb tgl_ttb no_refsj tgl_refsj no_refkwit tgl_refkwit no_sp

*no_ttb*no_retur


*no_sp tgl_sp kd_sup nip



*kd_brg*no_retur jml_retur ket

*no_ttb*no_bukti

*nip*no_sp

1

1

1

1

M

M

N

11

M

1

NM

1

*no_sp*no_ttb

Gambar 4.23Entity Relationship Diagram

5) Cara membaca dan uraian singkat tentang ERD.

Pegawai bisa membuat beberapa sp dan beberapa sp bisa dibuat oleh

satu pegawai. Beberpa sp bisa memesanbanyakbarangdan beberapa

barang bisa dipesandalambanyak sp. sp hanya boleh ditujukan untuk satu

supplier dansupplier boleh menerima beberapa sp. sp menerbitkan nomor

104

referensi surat jalan dan nomor referensi kwitansi dari supplier dan

menghasilkan tanda terima barang (ttb), tanda terima barang (ttb)

dibuat untuk satu sp, satu nomor referensi surat jalan dan nomor refernsi

kwitansi. sp dan tanda terima barang (ttb) dapat menerbitkan

buktibayar, di mana buktibayar hanya dibuat berdasarkan tanda

terima barang (ttb). tanda terima barang (ttb) dan barang dapat

menerbitkan retur, di mana retur hanya dibuat apabila ada barang yang

rusak/tidak sesuai.

4.11.2 Transformasi ERD ke LRS

Dalam membuat transformasi ERD ke LRS perlu diperhatikan

beberapa aturan-aturan yang ada, diantaranya sebagai berikut :

1) Setiap entity akan diubah kebentuk sebuah kotak dengan nama

entity berada diluar kotak dan atribut berada didalam kotak.

2) Sebuah relasi ada yang disatukan dalam sebuah kotak bersama

entity, adapula yang terpisah membentuk kotak tersendiri.

Dibawah ini adalah gambar Transformasi ERD yang diubah

kedalam bentuk LRS :

105

pegawai

Data barangsupplier Bukti SP

Bukti returttbbuktibayar

buat

cetak

pesan

kembali

ada

cetak

terima

*nip nm_peg


*kd_sup*no_sp

*no_bukti tgl_bukti jml_bayar

*no_ttb tgl_ttb no_refsj tgl_refsj no_refkwit tgl_refkwit no_sp

*no_ttb*no_retur


*no_sp tgl_sp kd_sup nip



*kd_brg*no_retur jml_retur ket

*no_ttb*no_bukti

*nip*no_sp

1

1

1

1

M

M

N

11

M

1

NM

1

*no_sp*no_ttb

Gambar 4.24 Transformasi ERD ke LRS

106

4.11.3 Logica record Stucture

SP

PK no_sp

tgl_sp

kd_sup

nip

Supplier

PK kd_sup

nm_sup

alamat

no_tlp

fax

no_rek

Pesan

PK no_sp

PK kd_brg

jml_pesan

hrg_pesan

Barang

PK kd_brg

nm_brg

satuan

harsat

stok

Pegawai

PK nip

nm_peg

TTB

PK no_ttb

tgl_ttb

no_refsj

tgl_refsj

no_refkwit

tgl_refkwit

no_sp

buktiBayar

PK no_bukti

tgl_bukti

jml_bayar

no_ttb

nip

kd_supno_sp

kd_brg

no_sp

no_ttb

Retur

PK no_retur

tgl_retur

No_TTB

no_ttb

Kembali

PK no_retur

PK kd_brg

jml_retur

ket

kd_brg

no_retur

Gambar 4.25Logical Record Structure

107

4.11.4 Normalisasi

Berikut ini langkah – langkah normalisasi yang dilakukan dengan

diuraikan gambar ketergantungan fungsional dan tahap normalisasi :

1) Relasi Pegawai

Gambar 4.26Diagram ketergantungan secara fungsional pada relasi

Pegawai

Bentuk normal yang dicapai adalah sebagai berikut :

a) Normal ke 1 (1NF) : tabel Pegawai atribut-atributnya sudah bernilai

tunggal atau tidak ada pengulangan sehingga sudah normal pada

tahap normalisasi pertama (1NF).

b) Normal ke 2 (2NF) : tabel Pegawai sudah pada 1NF dan bergantung

penuh kepada atribut primary key yaitu NIP, sehingga sudah normal

pada bentuk kedua (2NF).

c) Normal ke 3 (3NF) : tabel Pegawai sudah pada 2NF dan semua

atribut non key yaitu Nm_Peg tidak tergantung kepada atribut non

key lainnya.

108

2) Relasi Pesan

Gambar 4.27Diagram ketergantungan secara fungsional pada relasi Pesan


a) Normal ke 1 (1NF) : tabel Pesan atribut-atributnya sudah bernilai

tunggal atau tidak ada pengulangan sehingga sudah normal pada tahap

normalisasi pertama (1NF).

b) Normal ke 2 (2NF) : tabel Pesan sudah pada 1NF dan bergantung

penuh kepada atribut primary key yaitu No_SP dan Kd_Brg, sehingga

sudah normal pada bentuk kedua (2NF).

c) Normal ke 3 (3NF) : tabel Pesan sudah pada 2NF dan semua atribut non

key yaitu Kd_Brg, Jml_Pesan dan Hrg_Pesan tidak tergantung kepada

atribut non key lainnya.

109

3) Relasi Barang

Gambar 4.28Diagram ketergantungan secara fungsional pada relasi Barang


a) Normal ke 1 (1NF) : tabel Barang atribut-atributnya sudah bernilai



b) Normal ke 2 (2NF) : tabel Barang sudah pada 1NF dan bergantung

penuh kepada atribut primary key yaitu Kd_Brg, sehingga sudah

normal pada bentuk kedua (2NF).

c) Normal ke 3 (3NF) : tabel Barang sudah pada 2NF dan semua atribut

non key yaitu Nm_Brg, Satuan, Harsat dan Stok tidak tergantung

kepada atribut non key lainnya.

110

4) Relasi SP

Gambar 4.29Diagram ketergantungan secara fungsional pada relasi SP


a) Normal ke 1 (1NF) : tabel SP atribut-atributnya sudah bernilai tunggal

atau tidak ada pengulangan sehingga sudah normal pada tahap


b) Normal ke 2 (2NF) : tabel SP sudah pada 1NF dan bergantung penuh

kepada atribut primary key yaitu No_SP, sehingga sudah normal pada

bentuk kedua (2NF).

c) Normal ke 3 (3NF) : tabel SP sudah pada 2NF dan semua atribut non

key yaitu tgl_SP,Kd_Supdan NIP tidak tergantung kepada atribut non

key lainnya.

111

5) Relasi Supplier


Supplier


a) Normal ke 1 (1NF) : tabel Supplier atribut-atributnya sudah bernilai



b) Normal ke 2 (2NF) : tabel Supplier sudah pada 1NF dan bergantung

penuh kepada atribut primary key yaitu Kd_Sup, sehingga sudah


112

c) Normal ke 3 (3NF) : tabel Supplier sudah pada 2NF dan semua atribut

non key yaitu Nm_Sup, Alamat, No_Tlp, Faxdan No_rek tidak

tergantung kepada atribut non key lainnya.

6) Relasi TTB

Gambar 4.31Diagram ketergantungan secara fungsional pada relasi TTB


a) Normal ke 1 (1NF) : tabel TTB atribut-atributnya sudah bernilai



113

b) Normal ke 2 (2NF) : tabel TTB sudah pada 1NF dan bergantung penuh

kepada atribut primary key yaitu No_TTB, sehingga sudah normal pada

bentuk kedua (2NF).

c) Normal ke 3 (3NF) : tabel TTB sudah pada 2NF dan semua atribut non

key yaitu Tgl_TTB, No_RefSJ, Tgl_RefSJ, No_RefKwit, Tgl_RefKwit

dan No_SP tidak tergantung kepada atribut non key lainnya.

7) Relasi Retur

Gambar 4.32 Diagram ketergantungan secara fungsional pada relasi Retur


a) Normal ke 1 (1NF) : tabel Retur atribut-atributnya sudah bernilai



b) Normal ke 2 (2NF) : tabel Retur sudah pada 1NF dan bergantung penuh

kepada atribut primary key yaitu No_Retur, sehingga sudah normal

pada bentuk kedua (2NF).

114

c) Normal ke 3 (3NF) : tabel Retur sudah pada 2NF dan semua atribut non

key yaitu Tgl_Retur dan No_TTB tidak tergantung kepada atribut non

key lainnya.

8) Relasi BuktiBayar

Gambar 4.33 Diagram ketergantungan secara fungsional pada relasi Bukti

Bayar


a) Normal ke 1 (1NF) : tabel BuktiBayar atribut-atributnya sudah bernilai



b) Normal ke 2 (2NF) : tabel BuktiBayar sudah pada 1NF dan bergantung

penuh kepada atribut primary key yaitu No_Bukti, sehingga sudah


115

c) Normal ke 3 (3NF) : tabel BuktiBayar sudah pada 2NF dan semua

atribut non key yaitu Tgl_bukti, No_Rekening, JmlBayar dan No_TTB

tidak tergantung kepada atribut non key lainnya.

9) Relasi Kembali


Kembali


a) Normal ke 1 (1NF) : tabel Kembali atribut-atributnya sudah bernilai



b) Normal ke 2 (2NF) : tabel Kembali sudah pada 1NF dan bergantung

penuh kepada atribut primary key yaitu No_Retur dan Kd_brg,

sehingga sudah normal pada bentuk kedua (2NF).

c) Normal ke 3 (3NF) : tabel Kembali sudah pada 2NF dan semua atribut

non key yaitu jml_retur dan ket tidak tergantung kepada atribut non key

lainnya.

116

4.11.5 Spesifikasi Basis Data

Basis data yang telah mempunyai bentuk normal selanjutnya dijelaskan

dalam spesifikasi basis data yang meliputi nama file, media penyimpanan yang

digunakan, isi yang disimpan, organisasi yang digunakan, primary key, panjang

record dan struktur file.

Spesifikasi basis data yang memberikan penjelasan secara detil tentang

masing-masing basis data yang digunakan dalam rancangan sistem informasi

pembelian barang PT. Bank ANZ Indonesia adalah sebagai berikut :

1) Nama File : Pegawai

Media : Hard disk

Isi : Data Pegawai

Organisasi : Index Sequential

Primary Key : NIP

Panjang Record : 42byte

Struktur : Lihat struktur tabel 4.1

Tabel 4.3Spesifikasi Tabel Pegawai

No NamaField Jenis Lebar Desimal Keterangan

1 NIP Text 7 - Nomor Induk

Pegawai

2 Nm_peg Text 30 - Nama Pegawai

117

NIP terdiri dari 7 digit :

P E G 9 9 9 9

a b

Keterangan:

a) 3 digit pertama menunjukkan inisial dari Pegawai.

b) 4 digit terakhir menunjukkan nomor urut Pegawai.

2) Nama File : Pesan

Media : Hard disk

Isi : DataPesan


Primary Key : No_SP dan Kd_Brg

Panjang Record : 19 byte


Tabel 4.4Spesifikasi Tabel Pesan

No Nama

Field

Jenis Lebar Desimal Keterangan

1 No_SP Text 6 - Nomor Surat Pesanan

118

3) Nama File : Barang

Media : Hard disk

Isi : Data Barang


Primary Key : Kd_Brg



Tabel 4.5Spesifikasi Tabel Barang

2 Kd_Brg Text 7 - Kode Barang

3 Jml_Pesan Number 2 0 Jumlah Pesan {99}

4 Hrg_Pesan Number 4 0 Harga Pesan

{99,999,999}

No Nama

Field



2 Nm_brg Text 25 - Nama Barang

3 Satuan Text 10 - Satuan

4 Harsat Number 4 0 Harga Satuan

{99,999,999}

119

Kd_Brg terdiri dari 7 digit :

B R G 9 9 9 9

a b

Keterangan:

a) 3 digit pertama menunjukkan inisial dari Barang.

b) 4 digit kedua menunjukkan nomor urut Barang.

4) Nama File : SP

Media : Hard disk

Isi : Data SP


Primary Key : No_SP



Tabel 4.6Spesifikasi Tabel Surat Pesan

5 Stok Number 2 0 Stok {9999}

No Nama

Field


1 No_SP Text 6 - Nomor Surat Pesan

120

N

o_SSP terdiri dari 6 digit :

S P 9 9 9 9

a b

Keterangan:

a) 2 digit pertama menunjukkan inisial dari SP.

b) 4 digit kedua menunjukkan nomor urut SP.

5) Nama File : Supplier

Media : Hard disk

Isi : Data Supplier


Primary Key : Kd_Sup



2 Tgl_SP Date/Time 8 - Tanggal Surat Pesan

{DD/MM/YYYY}

3 Kd_Sup Text 7 - Kode Supplier

4 NIP Text 7 - Nomor Induk Pegawai

121

Tabel 4.7Spesifikasi Tabel Supplier

kd_S

up terdiri dari 7 digit :

S U P 9 9 9 9

a b

Keterangan:

a) 3 digit pertama menunjukkan inisial dari Supplier.

b) 4 digit kedua menunjukkan nomor urut Supplier.

6) Nama File : TTB

Media : Hard disk

Isi : Data TTB

N

o

Nama

Field

Jeni

s

Lebar Desimal Keterangan

1 Kd_Sup Text 7 - Kode Supplier

2 Nm_Sup Text 30 - Nama Supplier

3 Alamat Text 50 - Alamat

4 No_tlp Text 20 - Nomor Telepon {(999)

99999999}

5 Fax Text 20 - Fax {(999) 99999999}

6 No_rek Text 20 - Nomor Rekening

122


Primary Key : No_TTB



Tabel 4.8Spesifikasi Tabel TTB

No Nama Field Jenis Lebar Desimal Keterangan

1 No_TTB Text 7 - Nomor Tanda Terima

Barang

2 Tgl_TTB Date/Time 8 - Tanggal Tanda

Terima Barang

{DD/MM/YYYY}

3 No_RefSJ Text 15 - Nomor Referensi

Surat Jalan

4 Tgl_RefSJ Date/Time 8 - Tanggal Referensi

Surat Jalan

{DD/MM/YYYY}

5 No_RefKwit Text 15 - Nomor Referensi

Kwitansi

6 Tgl_RefKwit Date/Time 8 - Tanggal Referensi

Kwitansi

{DD/MM/YYYY}

123

NotBTTB terdiri dari 7 digit :

T T B 9 9 9 9

a b

Keterangan:

a) 3 digit pertama menunjukkan inisial dari TTB.

b) 4 digit kedua menunjukkan nomor urut TTB.

7) Nama File : Retur

Media : Hard disk

Isi : Data Retur


Primary Key : No_Retur



Tabel 4.9Spesifikasi Tabel Retur

7 No_SP Text 6 - Nomor Surat Pesan

No Nama

Field


1 No_Retur Text 6 - Nomor Retur

124

No_Retur terdiri dari 6 digit :

R T 9 9 9 9

a b

Keterangan:

a) 2 digit pertama menunjukkan inisial dari Retur.

b) 4 digit kedua menunjukkan no urut Retur.

8) Nama File : BuktiBayar

Media : Hard disk

Isi : Data BuktiBayar


Primary Key : No_Bukti


Jumlah Record : 108 record


Tabel 4.10 Spesifikasi Tabel BuktiBayar

2 Tgl_Retur Date/Time 8 - TanggalRetur

{DD/MM/YYYY}

3 No_TTB Text 7 - Nomor Tanda Terima Barang

No Nama

Field


125

N

o

_

B

ukNo_Bukti terdiri dari 6 digit :

B B 9 9 9 9

a b

a) 2 digit pertama menunjukkan inisial dari BuktiBayar.

b) 4 digit kedua menunjukkan no urut BuktiBayar.

9) Nama File : Kembali

Media : Hard disk

Isi : Data Kembali


Primary Key : No_Retur dan Kd_Brg


Jumlah Record : 36 record

1 No_Bukti Text 7 - Nomor Bukti Bayar

2 Tgl_Bukti Date/Time 8 - Tanggal Bukti Bayar

{DD/MM/YYYY}

3 No_rek Text 20 - Nomor Rekening

4 JmlBayar Number 4 0 Jumlah Bayar

{99,999,999}

5 No_TTB Text 7 - Nomor Tanda Terima

Barang

126


Tabel 4.11Spesifikasi Tabel Kembali

No Nama Field Jenis Lebar Desimal Keterangan

1 No_Retur Text 6 - Nomor Retur


3 Jml_Retur Text 2 - Jumlah Retur {99}

4 Ket Text 50 - Keterangan

f. Estimasi Kebutuhan Simpanan Data

1. Tabel Kebutuhan Simpanan Basis Data Dalam Jangka Waktu 3 Tahun

Tabel Gambar 4.12Tabel Kebutuhan Simpanan Basis Data

No Nama File /

Tabel

Panjang

Record

Jumlah

Record

Jumlah Dalam Byte

1 Pegawai 42 59 2,478

2 Pesan 19 108 2,052

3 Barang 48 115 5,520

4 SP 28 108 3,024

5 Supplier 147 15 2,205

6 TTB 67 108 7,236

7 Retur 21 36 756

8 BuktiBayar 46 108 4,968

9 Kembali 65 36 2,340

Total : 30,579 byte = 1MB

127

2. Tabel Estimasi Kebutuhan Simpanan Data Dalam Jangka Waktu 3

Tahun

Tabel 4.13Tabel Estimasi Kebutuhan Simpanan Data

No Kebutuhan Jumlah

1 Sistem Operasi menggunakan Windows7 Ultimate 16284 MB

2 Program Aplikasi menggunakan PHP 2048 MB

3 My SQL 276 MB

4 Database 1 MB

Total : 18713 MB

Sehingga estimasi simpanan data (storage) yang dibutuhkan dalam jangka

waktu 3 tahun adalah sebesar 18,27 GB.

4.12 Rancangan Antar Muka

Rancangan antar muka atau biasa disebut interface ini merupakan bentuk

tampilan yang dirancang untuk sistem.

4.12.1 Rancangan Layar

1. Rancangan Layar Login

LOGIN

UserName

Password

128

Gambar 4.35Rancangan Layar Form Menu Utama

2. Rancangan Layar Menu File Master

Gambar 4.36Rancangan Layar Sub Menu File Master

3. Rancangan Layar Entry Data Barang

Gambar 4.37Rancangan Layar Entry Data Barang

ANZ

File Master Transaksi Laporan

KODE N .BRNG S. JENIS H.SATUAN K.BARANG S.BRNG

ANZ

KODE BARANG

NAMA BARANG

SATUAN JENIS

HARGA SATUAN

STOCK ARANG

SAVE SAVE AND GO BACK LIST CANCEL

129

4. Rancangan Layar Entry Data Supplier

Gambar 4.38Rancangan Layar Entry Data Supplier

5. Rancangan Layar Entry Data Pegawai

ANZ

Gambar 4.39Rancangan Layar Entry Data Pegawai

ANZ

KODE SUPLIER

NAMA SUPLIER

ALAMAT

NO.TELP

NO FAX

NO REKENING

SAVE SAVE AND GO BACK LIST CANCEL

ANZ

KODE PEGAWAI

NAMA PEGAWAI

ALAMAT

NO.TELP

NO KTP

SAVE SAVE AND GO BACK LIST

CANCEL

130

4.4.1. Pemrograman

Pada tahap pemrograman, penulis menggunakan bahasa pemrograman PHP

sebagai bahasa pemrograman yang membantu dalam proses manipulasi kegiatan yang

ada dalam pembuatan aplikasi sistem informasi pencatatan pembelian barang PT.

Bank ANZ Indonesia.

Sedangkan untuk web server local software yang digunakan dalam pembuatan

aplikasi ini yaitu MySQL (My Structured Query Language) yang berfungsi untuk

penyimpanan data dari setiap perubahan data.

4.4.2. Pengujian Sistem

Pada tahap ini dilakukan pengujian terhadap sistem informasi pencatatan

pembelian barang PT. Bank ANZ Indonesia.Pengujian yang dilakukan adalah

pengujian external (Blackbox Testing).Blackbox Testing yaitu melakukan pengujian

terhadap aplikasi dengan cara memeriksa satu persatu link yang ada dengan

menggunakan tabel pengujian, apakah link tersebut sudah sesuai seperti yang

diharapkan atau belum.

Pengujian proses pemesanan program umroh

Black box testing pada proses Administrasi pembelian barang aktor yang

terlibat adalah Staff PCO, dan managerPCO:

131

1. Pengujian Proses Staff PCO

a. File master

Pengujian form entry data Barang

Actor Staff PCO

Menu Login

Sub Menu Entry data

Aktivitas rancangan proses 1. Login file master sub menu/entry

2. Masukkan informasi data ke dalam

form

Tanda Peringatan

Kesalahan

- Please Enter Required Field

Kesesuaian Sistem - Your data has been successfully stored

into the database.

Hasil Warning Sesuai

Accept Sesuai

Keterangan Tanda peringatan kesalahan dapat

menyesuaikan pada form yang belum diisi.

2.Pengujian Laporan Pembelian Barang

b. File Laporan

Pengujian view Laporan pembelian

Actor Staff PCO

Menu laporan

Sub Menu Laporan Pembelian

Aktivitas rancangan proses a. Klik menu laporan sub menu

laporan pembelian

b. Klik tanggal / bulan ( untuk melihat

laporan per tanggal / per bulan )

c. Klik tahun ( untuk melihat laporan per

tahun )

d. Klik cetak

Tanda Peringatan

Kesalahan

-

Kesesuaian Sistem - Berhasil menmpilkan laporan Pembelian


132

Accept Sesuai

Keterangan ok

b. Laporan Pemesanan Barang


Actor Staff PCO

Menu laporan

Sub Menu Laporan Pemesanan


laporan pemesanan




tahun )

d. Klik cetak

Tanda Peringatan

Kesalahan

-

Kesesuaian Sistem - Berhasil menmpilkan laporan Pemesanan


Accept Sesuai

Keterangan ok

c. Laporan Retur Barang


Actor Staff PCO & Manager PCO

Menu laporan

Sub Menu Laporan Retur


laporan Retur




tahun )

d. Klik cetak

Tanda Peringatan

Kesalahan

-

Kesesuaian Sistem - Berhasil menmpilkan laporan Retur

133


Accept Sesuai

Keterangan ok

134

BAB V

PENUTUP

5.1 Kesimpulan

Berdasarkan uraian dan pembahasan bab-bab sebelumnya maka dapat

disimpulkan bahwa :

1. Penyimpanan data ke dalam database yang terkomputerisasi secara

optimal dan terintegrasi sehingga dapat membantu perusahaan dalam

proses penyimpanan sehingga tidak boros kertas serta rentan akan

kehilangan serta kerusakan data baik itu data pemesanan.

2. Waktu yang cepat dalam proses perekapan data pemesanan karena

sistem telah terintegrasi antara fungsi-fungsi tersebut.

5.2 Saran

Beberapa saran yang peneliti sampaikan dalam perancangan sistem

informasi pemesanan barang, yaitu :

1. Perlu adanya pengembangan dalam sistem informasi pencatatan

pembelian barang hingga sistem informasi pembelian barang.

2. Perlu ditambahkan sistem online untuk berhubungan langsung dengan

supplier.

DAFTAR PUSTAKA

Alwi, Hasan. 2007. Kamus Besar Bahasa Indonesia. Jakarta: Balai Pustaka.

Betha, Sidik 2005. MySQL untuk Pengguna Administrator dan Pengembangan

Aplikasi Web. Bandung: Informatika.

Dennis, Alan., Wixom, Barbara Haley., Tegarden, David. (2005). System Analysis

and Design With UML Version 2.0 : An Object-Oriented Approach 2nd

Edition. United States: John Wiley & Sons.

Kadir, Abdul 2003. Pengenalan Sistem Informasi. Andi, Yogyakarta.

Ladjamudin, bin Al Bahra. 2005. Analisi Dan Desain Sistem Informasi (Edisi

Pertama). Yogyakarta : Graha Ilmu.

Laudon, Kennetch C & Laudon, Jane P. 2004. Management Information System.

(8t edition). New Jersey: Prentice Hall.

McLeod, Raymond, Jr & Schell, Goerge. 2008. Sistem Informasi Manajemen.

(Edisi10 Terjemahan Ali Akbar Yulianto). Jakarta: Salemba Empat.

McLeod, Raymond, (2004), Sistem Informasi Manajemen, jilid 1. PT.

Prenhallindo, Jakarta.

Mathiassen, Lars., Munk-Madsen, Andreas., Nielsen, Peter A., Stage, Jen,. 2000.

Object Oriented Analysisi & Design. Denmark: Forlaget Marko.

Munawar. 2005. Pemodelan Visual dengan UML. Yogyakarta: Graha Ilmu.

Nugroho Bunafit, 2008, Latihan Membuat Aplikasi Web PHP dan Mysql dengan

Dreamwaver, Gaya Media, Yogyakarta

Nickerson, Robert C. 2001. Business and Information Systems. International

Edition. 2nd edition. Prentice-Hall.

Pressman, Roger S. 2002. Rekayasa Perangkat Lunak: Pendekatan Praktis. (Buku

1 Edisi 2 Terjemahan: LN Harningrum). Yogyakarta: Andi.

Phillips, Paul. 2003. E-business Strategy : Text and Case. McGraw – Hill

Education, New York

Peak, P. and N. Heudecker 2006, Hibernate Quickly, Manning Publication Co.

Rizky, Soetam. 2011. Konsep Dasar Rekayasa Perangkat Lunak. Jakarta: Prestasi

Pustaka.

Sukarno, Mohamad. 2006. Membangun website dinamis interaktif dengan PHP-

MySQL. Jakarta: Eskamedia press.

Turban, Efraim., Rainer, R Kelly., Potter, Richard E. 2003. Introduction to

Information Technology. New York: John Wiley & Sons.

Turban, Efraim, Lee, King, dan Chung. (2002). Electronic Commerce 2002: A

Managerial Perspective. Pearson Education Inc., Upper Saddle River,

New Jersey.

LAMPIRAN I

(WAWANCARA)

Wawancara I

Responden : Kurnia Akbar

Jabatan : Leader Staff PCO

Penanya : Muhammad Audri Al Kaisar

Tanggal : 12 Juni 2013

Tema : Profil PT. Bank ANZ Indonesia

Tujuan : Mengetahui tentang sejarah berdirinya PT. Bank ANZ

Indonesia

Poin Utama Wawancara :

1. Bagaimana profil PT Bank ANZ Indonesia ?

2. Bagaimana struktur organisasi PT Bank ANZ Indonesia?

3. Bagaimana alur proses Pembelian Barang yang saat ini berjalan pada PT

Bank ANZ Indonesia

Hasil Wawancara :

Dari hasil wawancara ini, dapat diketahui tentang gambaran umum, visi

misi, struktur organisasi, galeri dan kontak pada PT. Bank ANZ Indonesia Dengan

diketahuinya gambaran umum, visi misi, struktur organisasi tersebut memudahkan

peneliti dalam mempelajari alur dokumen yang ada pada PT. Bank ANZ

Indonesia

Hasil Observasi

Observasi dilakukan pada :

Tempat : PT Bank ANZ Indonesia

Waktu : Juni 2013

Berdasarkan observasi yang penulis lakukan, penulis mengumpulkan informasi

mengenai :

1. Sejarah singkat, visi misi, struktur organisasi.

2. Alur sistem proses Pembelian Barang yang berjalan di PT Bank NZ

Indonesia

Wawancara II

Responden : Bpk Dicka

Jabatan : Staff PCO

Penanya : Muhammad Audri Al Kaisar

Tanggal : 20 Juni 2013

Tema : Proses Pembelian Barang PT Bank ANZ Indonesia

Tujuan : Mengetahui tentang alur proses pemesanan hingga

penyampaian pelaporan dalam informasi pemesnaan program

umroh.

1. Apakah PT. Bank ANZ Indonesia memiliki sistem informasi Pembelian

Barang berbasis komputer?

Hasil Wawancara:

Belum ada, sejauh ini apabila ada Pemesanan dan transaksi Pembelian

barang dilakukan secara manual.

2. Bagaimana dengan dokumentasi data dan disimpan dimana dokumen

tersebut?

Hasil Wawancara :

Untuk data yang berbentuk kertas dikumpulkan menjadi satu binder dan

disimpan di lemari penyimpanan dan untuk softcopy disimpan di computer

dalam bentuk Ms-Word dan Ms-Excel.

LAMPIRAN II

( SURAT)

LAMPILAN III

(CODING)

Admin_Controller

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');

class Admin extends CI_Controller {

public function __construct()

{

parent::__construct();

$this->load->database();

$this->load->helper('url');

$this->load->library('grocery_CRUD');

if(!$this->session->userdata('ID_USER')){header('location:'.base_url());}

}

public function _general_output($output = null)

{

$this->load->view('admin/general_crud.php',$output);

}

public function data_barang(){

$crud = new grocery_CRUD();

$crud->set_theme('dataTables');

$crud->set_table('data_barang');

$crud->display_as('data_barang');

$crud->set_subject('Entry Data Barang');

$crud->required_fields('kode_barang');

$output = $crud->render();

$this->_general_output($output);

}

public function supplier(){



$crud->set_table('supplier');

$crud->display_as('supplier');

$crud->set_subject('Entry Data Supplier');

$crud->required_fields('kode_supplier');



}

public function pegawai(){



$crud->set_table('pegawai');

$crud->display_as('pegawai');

$crud->set_subject('Entry Data Pegawai');

$crud->required_fields('kode_pegawai');



}

public function entry_surat_pesanan(){



$crud->set_table('entry_surat_pesanan');

$crud->display_as('entry_surat_pesanan');

$crud->set_subject('Entry Surat Pesanan');

$crud->display_as('id_pegawai','Nama Pegawai')

->display_as('id_supplier','Nama Supplier')

->display_as('id_barang','Nama Barang');

$crud->set_relation('id_pegawai','pegawai','nama_pegawai');

$crud->set_relation('id_supplier','supplier','nama_supplier');

$crud->set_relation('id_barang','data_barang','nama_barang');



}

public function entry_retur(){



$crud->set_table('entry_retur');

$crud->display_as('Entry Retur');

$crud->set_subject('Entry Retur');

$crud->display_as('id_barang','Nama Barang')

->display_as('id_entry_tanda_terima','No TTB');

$crud->set_relation('id_barang','data_barang','nama_barang');

$crud-

>set_relation('id_entry_tanda_terima','entry_tanda_terima_barang','nomor_ttb');



}

public function entry_bukti_bayar(){



$crud->set_table('entry_bukti_bayar');

$crud->display_as('entry_bukti_bayar');

$crud->set_subject('Entry Tanda Bukti Barang');

$crud->display_as('id_entry_tanda_terima','No TTB');

$crud-

>set_relation('id_entry_tanda_terima','entry_tanda_terima_barang','nomor_ttb');



}

public function entry_tanda_terima_barang(){



$crud->set_table('entry_tanda_terima_barang');

$crud->display_as('entry_tanda_terima_barang');

$crud->set_subject('Entry Tanda Terima Barang');

$crud->display_as('id_surat_pesanan','No SP')

->display_as('nomor_ttb','Nomor TTB')

->display_as('no_ref_sj','No Ref SJ')

->display_as('tanggal_ref_sj','Tanggal Ref SJ')

->display_as('no_ref_kwitansi','No Ref Kwitansi')

->display_as('tanggal_kwitansi','Tanggal Kwitansi');

$crud->set_relation('id_surat_pesanan','entry_surat_pesanan','nomor_sp');



}



$this->load->view('laporan_retur',$data);

}

}

GENERAL_MODUL

<?php

class general_Model extends CI_Model {

function __construct()

{


$this->load->database();

}

public function get_data_ref($table){

$this->db->select('*');

$this->db->from($table);

$this->db->where('active','Yes');

return $this->db->get();

}

public function get_data_select($table,$where=false,$limit=false){



if($where!=false){

$this->db->where($where,null,false);

}

if($limit!=false){

$this->db->limit($limit);

}


}

public function get_combo_data_ref($table,$value,$view){

$combo="";



$this->db->where('active','Yes');

$query=$this->db->get();

foreach($query->result_array() as $row){

$combo .="<option value='".$row[$value]."'>".$row[$view]."</option>";

}

return $combo;

}

public function auth_login($usr,$psw){


$this->db->from('user');

$this->db->where('username',$usr);

$this->db->where('password',$psw);


}

function add_data($table,$data){

return $this->db->insert($table,$data);

}

function update_data($data,$id,$id_primary,$table){

$this->db->where($id_primary, $id);

$this->db->update($table, $data);

return TRUE;

}

}

Grocery Crud

<?php

/**

* PHP grocery CRUD

*

* LICENSE

*

* Grocery CRUD is released with dual licensing, using the GPL v3 (license-gpl3.txt) and the MIT

license (license-mit.txt).

* You don't have to do anything special to choose one license or the other and you don't have to

notify anyone which license you are using.

* Please see the corresponding license file for details of these licenses.

* You are free to use, modify and distribute this software, but all copyright information must remain.

*

* @package grocery CRUD

* @copyright Copyright (c) 2010 through 2012, John Skoumbourdis

* @license https://github.com/scoumbourdis/grocery-crud/blob/master/license-grocery-crud.txt

* @version 1.2

* @author John Skoumbourdis <[email protected]>

*/

// ------------------------------------------------------------------------

/**

* Grocery CRUD Model

*

*

* @package grocery CRUD

* @author John Skoumbourdis <[email protected]>

* @version 1.2

* @link http://www.grocerycrud.com/documentation

*/

class grocery_CRUD_Model extends CI_Model {

protected $primary_key = null;

protected $table_name = null;

protected $relation = array();

protected $relation_n_n = array();

protected $primary_keys = array();

function __construct()

{


}

function db_table_exists($table_name = null)

{

return $this->db->table_exists($table_name);

}

function get_list()

{

if($this->table_name === null)

return false;

$select = "`{$this->table_name}`.*";

//set_relation special queries

if(!empty($this->relation))

{

foreach($this->relation as $relation)

{

list($field_name , $related_table , $related_field_title) = $relation;

$unique_join_name = $this->_unique_join_name($field_name);

$unique_field_name = $this->_unique_field_name($field_name);

if(strstr($related_field_title,'{'))

{

$related_field_title = str_replace("

"," ",$related_field_title);

$select .= ",

CONCAT('".str_replace(array('{','}'),array("',COALESCE({$unique_join_name}.",",

''),'"),str_replace("'","\\'",$related_field_title))."') as $unique_field_name";

}

else

{

$select .= ", $unique_join_name.$related_field_title AS

$unique_field_name";

}

if($this->field_exists($related_field_title))

$select .= ", `{$this->table_name}`.$related_field_title AS '{$this-

>table_name}.$related_field_title'";

}

}

//set_relation_n_n special queries. We prefer sub queries from a simple join for the

relation_n_n as it is faster and more stable on big tables.

if(!empty($this->relation_n_n))

{

$select = $this->relation_n_n_queries($select);

}

$this->db->select($select, false);

$results = $this->db->get($this->table_name)->result();

return $results;

}

public function get_row($table_name = null)

{

$table_name = $table_name === null ? $this->table_name : $table_name;

return $this->db->get($table_name)->row();

}

public function set_primary_key($field_name, $table_name = null)

{

$table_name = $table_name === null ? $this->table_name : $table_name;

$this->primary_keys[$table_name] = $field_name;

}

protected function relation_n_n_queries($select)

{

$this_table_primary_key = $this->get_primary_key();

foreach($this->relation_n_n as $relation_n_n)

{

list($field_name, $relation_table, $selection_table, $primary_key_alias_to_this_table,

$primary_key_alias_to_selection_table,

$title_field_selection_table, $priority_field_relation_table) = array_values((array)$relation_n_n);

$primary_key_selection_table = $this->get_primary_key($selection_table);

$field = "";

$use_template = strpos($title_field_selection_table,'{') !== false;

$field_name_hash = $this->_unique_field_name($title_field_selection_table);

if($use_template)

{

$title_field_selection_table = str_replace(" ", " ",

$title_field_selection_table);

$field .= "CONCAT('".str_replace(array('{','}'),array("',COALESCE(",",

''),'"),str_replace("'","\\'",$title_field_selection_table))."')";

}

else

{

$field .= "$selection_table.$title_field_selection_table";

}

//Sorry Codeigniter but you cannot help me with the subquery!

$select .= ", (SELECT GROUP_CONCAT(DISTINCT $field) FROM

$selection_table "

."LEFT JOIN $relation_table ON

$relation_table.$primary_key_alias_to_selection_table =

$selection_table.$primary_key_selection_table "

."WHERE $relation_table.$primary_key_alias_to_this_table = `{$this-

>table_name}`.$this_table_primary_key GROUP BY

$relation_table.$primary_key_alias_to_this_table) AS $field_name";

}

return $select;

}

function order_by($order_by , $direction)

{

$this->db->order_by( $order_by , $direction );

}

function where($key, $value = NULL, $escape = TRUE)

{

$this->db->where( $key, $value, $escape);

}

function or_where($key, $value = NULL, $escape = TRUE)

{

$this->db->or_where( $key, $value, $escape);

}

function having($key, $value = NULL, $escape = TRUE)

{

$this->db->having( $key, $value, $escape);

}

function or_having($key, $value = NULL, $escape = TRUE)

{

$this->db->or_having( $key, $value, $escape);

}

function like($field, $match = '', $side = 'both')

{

$this->db->like($field, $match, $side);

}

}

function get_edit_values($primary_key_value)

{

$primary_key_field = $this->get_primary_key();

$this->db->where($primary_key_field,$primary_key_value);

$result = $this->db->get($this->table_name)->row();

return $result;

}

function join_relation($field_name , $related_table , $related_field_title)

{

$related_primary_key = $this->get_primary_key($related_table);

if($related_primary_key !== false)

{

$unique_name = $this->_unique_join_name($field_name);

$this->db->join( $related_table.' as '.$unique_name ,

"$unique_name.$related_primary_key = {$this->table_name}.$field_name",'left');

$this->relation[$field_name] = array($field_name , $related_table ,

$related_field_title);

return true;

}

return false;

}

function set_relation_n_n_field($field_info)

{

$this->relation_n_n[$field_info->field_name] = $field_info;

}

protected function _unique_join_name($field_name)

{

return 'j'.substr(md5($field_name),0,8); //This j is because is better for a string to begin with a

letter and not with a number

}

protected function _unique_field_name($field_name)

{

return 's'.substr(md5($field_name),0,8); //This s is because is better for a string to begin with

a letter and not with a number

}

function get_relation_array($field_name , $related_table , $related_field_title, $where_clause,

$order_by, $limit = null, $search_like = null)

{

$relation_array = array();

$field_name_hash = $this->_unique_field_name($field_name);

$related_primary_key = $this->get_primary_key($related_table);

$select = "$related_table.$related_primary_key, ";

if(strstr($related_field_title,'{'))

{

$related_field_title = str_replace(" ", " ", $related_field_title);

$select .= "CONCAT('".str_replace(array('{','}'),array("',COALESCE(",",

''),'"),str_replace("'","\\'",$related_field_title))."') as $field_name_hash";

}

else

{

$select .= "$related_table.$related_field_title as $field_name_hash";

}

$this->db->select($select,false);

if($where_clause !== null)

$this->db->where($where_clause);



if($limit !== null)

$this->db->limit($limit);

if($search_like !== null)

$this->db->having("$field_name_hash LIKE '%".$this->db-

>escape_like_str($search_like)."%'");

$order_by !== null

? $this->db->order_by($order_by)

: $this->db->order_by($field_name_hash);

$results = $this->db->get($related_table)->result();

foreach($results as $row)

{

$relation_array[$row->$related_primary_key] = $row->$field_name_hash;

}

return $relation_array;

}

function get_ajax_relation_array($search, $field_name , $related_table , $related_field_title,

$where_clause, $order_by)

{

return $this->get_relation_array($field_name , $related_table , $related_field_title,

$where_clause, $order_by, 10 , $search);

}

function get_relation_total_rows($field_name , $related_table , $related_field_title, $where_clause)

{



return $this->db->count_all_results($related_table);

}

);

$results = $this->db->get($field_info->relation_table)->result();

$results_array = array();


{

$results_array[$row->{$field_info->primary_key_alias_to_selection_table}] = $row-

>{$field_name_hash};

}

return $results_array;

}

function get_relation_n_n_unselected_array($field_info, $selected_values)

{

$use_where_clause = !empty($field_info->where_clause);

$select = "";

$related_field_title = $field_info->title_field_selection_table;

$use_template = strpos($related_field_title,'{') !== false;

$field_name_hash = $this->_unique_field_name($related_field_title);

if($use_template)

{




}

else

{

$select .= "$related_field_title as $field_name_hash";

}

$this->db->select('*, '.$select,false);

if($use_where_clause){

$this->db->where($field_info->where_clause);

}

$selection_primary_key = $this->get_primary_key($field_info->selection_table);

if(!$use_template)

$this->db->order_by("{$field_info->selection_table}.{$field_info-

>title_field_selection_table}");

$results = $this->db->get($field_info->selection_table)->result();

$results_array = array();


{

if(!isset($selected_values[$row->$selection_primary_key]))

$results_array[$row->$selection_primary_key] = $row->{$field_name_hash};

}

return $results_array;

}

function db_relation_n_n_update($field_info, $post_data ,$main_primary_key)

{

$this->db->where($field_info->primary_key_alias_to_this_table, $main_primary_key);

if(!empty($post_data))

$this->db->where_not_in($field_info->primary_key_alias_to_selection_table ,

$post_data);

$this->db->delete($field_info->relation_table);

$counter = 0;

if(!empty($post_data))

{

foreach($post_data as $primary_key_value)

{

$where_array = array(

$field_info->primary_key_alias_to_this_table =>

$main_primary_key,

$field_info->primary_key_alias_to_selection_table =>

$primary_key_value,

);

$this->db->where($where_array);

$count = $this->db->from($field_info->relation_table)-

>count_all_results();

if($count == 0)

{

if(!empty($field_info->priority_field_relation_table))

$where_array[$field_info-

>priority_field_relation_table] = $counter;

$this->db->insert($field_info->relation_table,

$where_array);

}elseif($count >= 1 && !empty($field_info-

>priority_field_relation_table))

{

$this->db->update( $field_info->relation_table,

array($field_info->priority_field_relation_table => $counter) , $where_array);

}

$counter++;

}

}

}

function db_relation_n_n_delete($field_info, $main_primary_key)

{

$this->db->where($field_info->primary_key_alias_to_this_table, $main_primary_key);

$this->db->delete($field_info->relation_table);

}

function get_field_types_basic_table()

{

$db_field_types = array();

foreach($this->db->query("SHOW COLUMNS FROM `{$this->table_name}`")->result() as

$db_field_type)

{

$type = explode("(",$db_field_type->Type);

$db_type = $type[0];

if(isset($type[1]))

{

if(substr($type[1],-1) == ')')

{

$length = substr($type[1],0,-1);

}

else

{

list($length) = explode(" ",$type[1]);

$length = substr($length,0,-1);

}

}

else

{

$length = '';

}

$db_field_types[$db_field_type->Field]['db_max_length'] = $length;

$db_field_types[$db_field_type->Field]['db_type'] = $db_type;

$db_field_types[$db_field_type->Field]['db_null'] = $db_field_type->Null == 'YES'

? true : false;

$db_field_types[$db_field_type->Field]['db_extra'] = $db_field_type->Extra;

}

$results = $this->db->field_data($this->table_name);

foreach($results as $num => $row)

{

$row = (array)$row;

$results[$num] = (object)( array_merge($row, $db_field_types[$row['name']]) );

}

return $results;

}

function get_field_types($table_name)

{

$results = $this->db->field_data($table_name);

return $results;

}

function db_update($post_array, $primary_key_value)

{


return $this->db->update($this->table_name,$post_array, array( $primary_key_field =>

$primary_key_value));

}

function db_insert($post_array)

{

$insert = $this->db->insert($this->table_name,$post_array);

if($insert)

{

return $this->db->insert_id();

}

return false;

}

function db_delete($primary_key_value)

{


if($primary_key_field === false)

return false;

$this->db->limit(1);

$this->db->delete($this->table_name,array( $primary_key_field => $primary_key_value));

if( $this->db->affected_rows() != 1)

return false;

else

return true;

}

{

if($field->primary_key == 1)

{

return $field->name;

}

}

return false;

}

else

{

return $this->primary_key;

}

}

else

{

if(isset($this->primary_keys[$table_name]))

{

return $this->primary_keys[$table_name];

}

$fields = $this->get_field_types($table_name);

foreach($fields as $field)

{

if($field->primary_key == 1)

{

return $field->name;

}

}

return false;

}

}

function escape_str($value)

{

return $this->db->escape_str($value);

}

}

skripsi -...

Documents