RANCANG BANGUN SISTEM INVENTORY SPARE

PART DENGAN JAVA NETBEAN

Disusun untuk memenuhi tugas mata kuliah bahasa indonesia
Dosen: Hamdan Faudi Rofie, M.Pd

Disusun Oleh:

Ibnu Nur Hidayat : 1441177004025

Yusup Mutaali : 1441177004184

FAKULTAS ILMU KOMPUTER

PRODI TEKNIK INFORMATIKA
UNIVERSITAS SINGAPERBANGSA KARAWANG
2017

i
 KATA PENGANTAR

Assalamu’alaikum Wr. Wb
Segala puji syukur kita panjatkan kepada Allah SWT. Yang telah
memberikan kami kemudahan sehingga dapat menyelesaikan makalah ini.
Shalawat dan salam semoga tetap kita curah limpahkan kepada Baginda Nabi
Muhammad SAW.
Makalah ini disusun untuk memenuhi tugas mata kuliah Bahasa Indonesia
yang kami sajikan berdasarkan pengamatan dari berbagai sumber. Makalah ini
kami susun dengan segala kemampuan dan usaha dengan berbagai kendala.
Namun dengan penuh kesabaran dan terutama pertolongan dari Allah SWT,
akhirnya makalah ini dapat saya selesaikan.
Saya juga mengucapkan banyak terima kasih yang tulus kepada Dosen
Bahasa Indonesia Bapak Hamdan Faudi Rofie, M.Pd yang telah memberikan
tugas ini kepada kami.
Semoga makalah ini dapat memberikan pengetahuan yang lebih luas
kepada pembaca. Walaupun makalah yang kami sajikan memiliki banyak
kekurangan. Oleh karena itu, kami membutuhkan kritik dan saran yang sangat
membangun dari pembaca.
Wassalamu’alaikum Wr. Wb

Karawang, 10 Oktober 2017

Penuli

Daftar Isi
KATA PENGANTAR............................................................................................iii
Daftar Isi...............................................................................................................iv
BAB I PENDAHULUAN.......................................................................................1
1.1 Latar Belakang.......................................................................................1

ii
 1.2. Rumusan Masalah..................................................................................2
1.3. Tujuan Penulisan....................................................................................3
1.4. Batasan Permasalahan............................................................................3
BAB II STUDI LITERATUR................................................................................4
2.1. Kajian Terdahulu....................................................................................4
2.2. Teori Umum...........................................................................................5
2.2.1 Konsep Dasar Berorientasi Obyek...................................................5
2.2.2 Unified Modelling Language (UML)..............................................7
2.2.3 Analisa dan perancangan berorientasi obyek...................................8
2.2.4 Analisa Berorientasi Obyek (Object Oriented Analysis).................8
2.2.5 SDLC...............................................................................................9
2.2.6 Use Case Diagram..........................................................................13
2.2.7 Activity Diagram............................................................................15
2.2.8 Sequence Diagram.........................................................................16
2.2.9 Class Diagram................................................................................16
2.3. Teori Khusus........................................................................................17
2.3.1 Definisi Prototype..........................................................................18
2.3.2 Jenis –Jenis Prototype....................................................................19
2.3.3 Tahapan – Tahapan Prototype........................................................20
2.3.4 Keunggulan dan Kelemahan Prototype..........................................21
2.3.5 Mengapa Memilih Prototype.........................................................23
BAB III METODE PENGEMBANGAN PERANGKAT LUNAK..................24
3.1. Metodologi...........................................................................................24
3.2. Rencana Pengerjaan Project.................................................................24
3.3. Schedule Pembuatan Sistem................................................................27
BAB IV PEMBAHASAN.....................................................................................28
4.1. Analisa Sistem Berjalan.......................................................................28
4.1.1. Uraian Prosedur..............................................................................28
4.1.2. Analisa Proses................................................................................29
DAFTAR PUSTAKA.............................................................................................35

iii
 BAB I
PENDAHULUAN

1.2. Latar Belakang

Pada era globalisasi ini, perkembangan ilmu pengetahuan dan teknologi

sangat pesat, apalagi informasi sekarang sangat cepat menyebar ke penjuru dunia.
Sejalan dengan hal tersebut permasalahan yang kita hadapi juga semakin
kompleks yaitu pada bidang sehari-hari. Dengan kenyataan itu kita dituntut untuk
menyelesaikan permasalahan yang ada dengan memanfaatkan kecanggihan
teknologi serta kecepatan, ketepatan dan keakuratan dalam memberi informasi
sehingga dalam melaksanakan pekerjaan kita akan mendapat hasil yang optimal.
Salah satunya adalah pemanfaatan teknologi komputer. Data yang berukuran besar
jika dikerjakan secara manual membutuhkan tenaga lebih dari satu orang, maka
dengan perlengkapan komputer data tersebut dapat ditangani oleh satu orang saja,
dan juga dengan penggunaan komputer akan lebih cepat dalam penyelesaiannya.
Dengan kemudahan fasilitas yang diberikan komputer akan mempermudah dalam
pembuatan dan penyampaian informasi kepada orang yang membutuhkan.
Dalam suatu perusahaan atau organisasi, data dan informasi adalah suatu
hal yang penting untuk melakukan suatu proses bisnis. Data yang valid adalah
suatu modal bagi terciptanya sebuah informasi yang sangat berguna bagi
kelangsungan sebuah kinerja perusahaan. Nilai data dalam sebuah perusahaan
atau organisasi bisa menjadi sangat mahal bila data tersebut sangat diperlukan.
PT Astra Daihatsu Motor adalah suatu badan usaha di Jakarta yang bergerak di
bidang usaha perakitan Otomotif. Dalam kasus ini akan dibahas lebih ke Spare
part kontrol di Maintenance Departemen.Walaupun sistem Control sudah
menggunakan SAP sistem untuk warehaouse sentralnya, tapi untuk tiap shopnya
masih secara manual, yaitu dengan mengisi form-form sederhana dan dicatat
dalam sebuah buku.

Dengan melihat fenomena yang ada di PT Astra Daihatsu motor, maka

pentingnya untuk menerapkan suattu sistem terhadap pengontrolan sparepart yang
langsung terkoneksi kedalam sistem yang suadah ada. Agar nantinya setiap
transaksi pemakaian dan kedatangan spare part pada tiap shop maintenance lebih

1
 2

terkontrol.Berdasarkan pada hal tersebut penelitian ini bertujuan untuk

membangun suatu sistem inventory control di shop Maintenace PT Astra Daihatsu
Motor.

1.3. Rumusan Masalah

Pada saat ini, setelah penulis melakukan penelitian pada sistem yang sudah
ada atau yang sedang berjalan, maka permasalahan yang sering terjadi dalam
proses pencatatan persediaan barang pada Maintenance Departemen adalah
sebagai berikut :
a. Terjadinya kesalahan pencatatan data sehingga informasi yang didapat
tidak akurat
b. Pembuatan laporan yang masih secara manual sehingga lama dalam
penyajian laporan dan pengambilan keputusan oleh pimpinan.
c. Masih manualnya penyimpanan data sehingga menemui kesulitan jika
sewaktu-waktu diperlukan
d. Data in dan out spare part yang kurang terkontrol, sehingga aktual dan
kekuatan stok kurang termonitor.
Dari hambatan / masalah di atas maka perlu dicari jalan keluarnya. Salah
satu cara untuk mengatasinya adalah dengan menggunakan komputer sebagai alat
bantu untuk memperbaiki sistem manual yang sedang berjalan saat ini.
Diharapkan dengan adanya sistem informasi yang baru ini, maka semua kegiatan
pencatatan persediaan barang Maintenance Departemen dapat berjalan lebih baik.
Alasan lain dilakukannya penggunaan komputer adalah semakin ketatnya
persaingan dan perkembangan yang cepat, sehingga diharapkan perusahaan /
instansi dapat bergerak lebih cepat dalam segala hal untuk membantu kelancaran
sistem yang sedang berjalan.

1.4. Tujuan Penulisan

Selain merupakan salah satu syarat untuk untuk menyelesaikan Tugas
Kelompok Mata Kulia Analis Desain Berorientasi Objek, penulisan ini bertujuan
untuk menganalisa sistem yang sedang berjalan dan juga kebutuhan dari
Maintenance departemen untuk yang akan datang yang kemudian dilihat
permasalahannya sehingga dapat dicari sebuah solusi berdasarkan prinsip-prinsip
ilmu sistem informasi yang selama ini penulis pelajari. Solusi yang didapat adalah
 3

dengan mencoba membuat suatu rancangan sistem yang telah terkomputerisasi

sehingga dapat memberikan solusi yang bertujuan untuk :
a. Mengurangi risiko kesalahan yang terjadi pada sistem yang lama.
b. Mempermudah proses pengolahan data sehingga dapat secara cepat
membuat laporan-laporan dengan hasil yang akurat.
c. Meningkatkan mutu keamanan dan pengarsipan data sehingga data dapat
disimpan dan terkontrol dengan baik
d. Proses kontrol spare part termonitor dan ordering spare part yang habis
bisa cepat dilakukan.

1.5. Batasan Permasalahan

Sistem informasi yang dibuat hanya akan meliputi kegiatan-kegiatan yang
terkait dengan proses pencatatan persediaan barang secara langsung seperti
1. Input dan report Good Issue
2. Input dan report Good Received
3. Input dan Report Transfer barang
4. Input dan Report Order Barang
5. Input dan Report Status Stok
6. Input danReport STO (Stock Taking Opname)
Sistem yang dibuat tidak akan meliputi
1. Fungsi pembukuan seperti perhitungan harga pokok barang,
2. Nilai penyusutan barang
3. Fungsi-fungsi akuntasi lainnya.
 BAB II
STUDI LITERATUR

Kajian Terdahulu
Judul Penelitian PERANCANGAN Perancangan Sistem PERANCANGAN
SISTEM SISTEM
Inventory Sparepart
INFORMASI INFORMASI
MANAJEMEN Motor Pada CV. INVENTORY
PERSEDIAAN SPAREPART MESIN
Surya Jaya Jepara
BARANG FOTOCOPY
“ELECTROLUX DENGAN
MENGGUNAKAN
AUTHORIZED
VISUAL DELPHI 7
SERVICE CV. (Studi Kasus di UD.
MOMENTUM Eka Taruna Madiun)
TEKNIK”
Peneliti Dewi Sawitri Januar Yoga A Fatim Nugrahanti
Lembaga dan Universitas Universitas Dian STT Dharma Iswara
Tahun Gunadarma Tahun Nuswantoro Tahun Madiun Tahun 2015
2011 2013
Masalah “Electrolux CV. Surya Jaya permasalahan
Authorized Service Jepara dalam inventori sering
Penelitian
CV. Momentum menyajikan data menjadi kendala
Teknik” yang yang dibutuhkan harus keluar masuk
menggunakan oleh bengkel masih barang. Penanganan
pendokumentasian manual, dalam data menggunakan
data barang masuk hal ini dalam system manual
dan barang keluar mengendalikan mengakibatkan
secara manual persediaan stok sering terjasdi
sehingga sparepart atau
kesalahan.
membuat lambatnya keluar masuknya
kinerja perusahaan. jumlah sparepart
Data-data tersebut masih kurang
tidak terintegrasi dan efisien sehingga
tidak terkonsolidasi banyak sekali
kesulitan yang ada
apalagi data yang
harus diolah banyak
dikarenakan stok
sparepart yang
terdiri dari berbagai
macam sparepart.

Tujuan Penelitian Perancangan sistem sistem informasi mempermudah proses

informasi manajemen
persediaan stok monitoring stock

4
 5

persediaan barang sparepart barang yang masuk

secara komputerisasi maupun keluar
Teori Perencanaan sistem Merancang sistem Merancang sistem
hingga
informasi dengan informasi dengan data
tahap perancangan
sistem yang rinci, data diagram diagram konteks dan
mencakup
konteks dan data data flow diagram
perancangan
database, flow diagram
perancangan kontrol,
perancangan input
output, hingga
teknologinya
Metode Penelitian Menggunakan Penelitian Penelitian
metode
menggunakan menggunakan metode
System Development
metode kuantitatif kuantitatif dengan
Life Cycle (SDLC)
dengan pendekatan pendekatan survey
survey dan dan wawancara
wawancara
Hasil Penelitian Aplikasi Inventory Aplikasi kasi aplikasi
program yang dapat
dengan pengontrolan inventory dengan
melakukan kontrol
Keuangan laporan dan retur
persediaan sparepart
pembelian
dan memberikan
laporan update stok

1.2. Teori Umum

2.2.1. Konsep Dasar Berorientasi Obyek

Sebelumnya mari kita definisikan dulu pengertian obyek. Obyek adalah
“benda” secara fisik atau konseptual, yang dapat kita temui di sekeliling kita.
Obyek adalah riil. Contoh obyek adalah orang, hardware, software, dokumen dan
lain-lain.
Setiap obyek mempunyai dua ciri, yaitu atribut (property atau data) yang
menjadi ciri khas dari suatu obyek (what they have) dan method
(behavior/function), yaitu apa yang dapat dilakukan oleh obyek (what they do).
 6

Berorientasi Obyek (object oriented) berarti permasalahan didefinisikan

melalui istilah dari obyek yang mengkapsulasi data (atribut) dan perilaku
(behavior), yaitu melalui paradigma/pendekatan obyek.
Selain object, ada beberapa istilah yang akan membantu untuk memahami
pengertian kita dalam skripsi ini:
a. Class, yaitu kumpulan obyek yang sejenis. Secara lebih lugas obyek
adalah instant dari sebuah class, atau dengan pengertian lain dengan class
kita menggambarkan property dan behavior dari tipe obyek.
b. Inheritance, adalah penurunan atribut atau method dari suatu obyek class
ke obyek class lainnya.
c. Polymorphisme, berasal dari bahasa Yunani yang berarti banyak bentuk.
d. Dalam konsep ini memungkinkan digunakannya suatu interface yang sama
untuk memerintah suatu obyek untuk melakukan suatu aksi atau tindakan
yang mungkin secara prinsip sama tetapi secara proses berbeda. Secara
sederhana bisa juga disebut : satu interface, banyak aksi.
Metodologi adalah cara sistematis untuk mengerjakan pekerjaan analisis
dan desain. Metodologi berorientasi obyek adalah metode penyelesaian masalah
dengan menggunakan pendekatan berorientasi obyek.
 Metodologi berorientasi obyek pertama kali muncul pada pertengahan
tahun 1970 dan terus berkelanjutan dikembangkan sampai saat ini. Pada tahun
1994 ada 72 lebih metode object oriented. Dengan berkembang pesatnya metode
ini maka masyarakat object oriented menyadari perlunya standarisasi.

2.2.2. Unified Modelling Language (UML)

Pada Oktober 1994 Dr. James Rumbaugh yang mengembangkan Object
Modelling Technique (OMT) bergabung dengan perusahaan Rational
Software. Sebelumnya juga bergabung Grady Booch yang mengembangkan
Object Modelling Design (OOD). Duet mereka pada Oktober 1995
menghasilkan Unified Method versi 0.8, yang menjadi cikal bakal dari UML
(Unified Modelling language) sebagai bahasa pemodelan standar untuk aplikasi object oriented. (A Suhendar dan Hariman G, Visual
Modeling Menggunakan UML dan Relational Rose, cetakan pertama, Informatika Bandung, 2002.)

Pada tahun 2002 lahir UML versi 2.0 dengan penambahan dan
penggantian diagram menjadi 13 buah diagram. Diagram-diagram ini terbagi
menjadi 3 kategori :
a. Structural diagrams : menggambarkan elemen dari spesifikasi yang
mengabaikan waktu. Terdiri dari : Class Diagram, Object Diagram,
Component Diagram, Deployment Diagram, Composite Structure
Diagram dan Package Diagram.
b. Behavior diagram : menggambarkan ciri-ciri behavior/method/function
dari sebuah system atau business process. Terdiri dari : Use Case Diagram,
Activity Diagram dan State Machine Diagram.
c. Interaction diagram : bagian dari behavior diagram yang menggambarkan
object interactions. Terdiri dari : Communication Diagram, Interaction
Overview Diagram, Sequence Diagram dan Timing Diagram.

Karena UML sangat fleksibel, ada juga cara melihat diagram UML berdasar
kategori berikut :
a. Static Diagram : menunjukkan segi static dari system. Kategori ini sama
dengan structural diagram.
b. Dynamic Diagram : menunjukkan bagaimana system berkembang setiap
waktu. Meliputi state-machine diagram dan timing diagram.

7
 8

c. Functional Diagram : menunjukkan detail dari perilaku (behavior) dan

algoritma bagaimana system memenuhi perilaku yang diinginkannya.
Kategori ini termasuk use case, interaction dan activity diagram.
(Unified Modelling language) sebagai bahasa pemodelan standar untuk aplikasi object oriented. (A Suhendar dan Hariman G,
Visual Modeling Menggunakan UML dan Relational Rose, cetakan pertama, Informatika Bandung, 2002.)

2.2.3. Analisa dan perancangan berorientasi obyek

Analisa dan desain berorientasi obyek berarti merumuskan dan
menyelesaikan masalah serta menghasilkan suatu hipotesa dan diagnosa (solusi),
memodelkannya dengan pendekatan/paradigma obyek (obyek adalah riil punya
atribut/data dan perilaku).
Dalam melakukan analisa dan perancangan sistem berorientasi obyek
penulis menggunakan UML (Unified Modelling Language) untuk
memodelkannya. Sedangkan alat (tool) visual modelling yang digunakan untuk
menggambarkan model analisa dan perancangan adalah Microsoft Visio 2007.
Implementasi perangkat lunak menggunakan bahasa pemrograman PHP.

2.2.4. Analisa Berorientasi Obyek (Object Oriented Analysis)

Object oriented analysis adalah metode analisis yang memeriksa
requirements (syarat atau keperluan yang harus dipenuhi suatu sistem)
(Suhendar dan Hariman, 2002:11)
Dalam tahap ini kegiatan-kegiatan yang dilakukan dalam menganalisa
sistem sebagai berikut :
 Menganalisa sistem yang ada dan mempelajari apa yang dikerjakan
oleh sistem yang ada.
 Menspesifikasikan sistem yaitu spesifikasi masukan yang digunakan
database yang ada, proses yang dilakukan dan keluaran yang
dihasilkan.

Tujuan dari analisa berorientasi obyek yaitu untuk menentukan kebutuhan

pemakai secara akurat.
Pendekatan-pendekatan yang dipakai dalam analisa berorientasi obyek
antara lain :
 9

 Pendekatan top down, yaitu memecahkan masalah ke dalam bagian-

bagian terkecil atau per level sehingga mudah untuk diselesaikan.
 Pendekatan modul, yaitu membagi sistem ke dalam modul-modul yang
dapat beroperasi tanpa ketergantungan.
 Penggunaan alat-alat bantu dalam bentuk grafik dan teks sehingga
mudah untuk dimengerti serta dikoreksi apabila terjadi perubahan.
Pendekatan dalam analisa berorientasi obyek dilengkapi dengan alat-alat
dan teknik-teknik yang dibutuhkan dalam pengembangan sistem, sehingga hasil
akhir dari sistem yang dikembangkan akan didapatkan sistem yang terdefinisi
dengan baik dan jelas.

2.2.5. SDLC
SDLC (Systems Development Life Cycle, Siklus Hidup Pengembangan
Sistem) atau Systems Life Cycle (Siklus Hidup Sistem), dalam rekayasa sistem
dan rekayasa perangkat lunak, adalah proses pembuatan dan pengubahan sistem
serta model dan metodologi yang digunakan untuk mengembangkan sistem-sistem
tersebut. Konsep ini umumnya merujuk pada sistem komputer atau informasi.
SDLC juga merupakan pola yang diambil untuk mengembangkan sistem
perangkat lunak, yang terdiri dari tahap-tahap: rencana(planning), analisis
(analysis), desain (design), implementasi (implementation), uji coba (testing) dan
pengelolaan (maintenance).[1] Dalam rekayasa perangkat lunak angsyat Ä,
konsep SDLC mendasari berbagai jenis metodologi pengembangan perangkat
lunak. Metodologi-metodologi ini membentuk suatu kerangka kerja untuk
perencanaan dan pengendalian pembuatan sistem informasi, yaitu proses
pengembangan perangkat lunak. Terdapat 3 jenis metode siklus hidup sistem yang
paling banyak digunakan, yakni: siklus hidup sistem tradisional(traditional system
life cycle), siklus hidup menggunakan prototyping (life cycle using prototyping),
dan siklus hidup sistem orientasi objek (object-oriented system life cycle).

1. Metode Waterfall
Waterfall adalah suatu metodologi pengembangan perangkat lunak
yang mengusulkan pendekatan kepada perangkat lunak sistematik dan
 10

sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis,
design, kode, pengujian dan pemeliharaan.
Langkah-langkah yang dapat digunakan untuk membuat sistem
dengan metode ini, yaitu :
1. Requirements Definition (definisi kebutuhan)
2. Design (rancangan)
3. Development
4. Integration & Test
5. Installation & Acceptance

Kelebihan Metode Waterfall :

 Mudah untuk dimengerti dan mudah untuk digunakan
 Dapat digunakan untuk staff yang belum berpengalaman
 Kualitas dari sistem yang dihasilkan akan baik.
 Document pengembangan sistem sangat terorganisir, karena setiap fase
harus terselesaikan dengan lengkap sebelum melangkah ke fase
berikutnya.

Kekurangan Metode Waterfall :

 Diperlukan majemen yang baik.
 Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak
awal pengembangan.
 Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak
dapat mengakomodasi ketidakpastian pada saat awal pengembangan.

2. Metode Incremental
Model Incremental, merupakan model pengembangan system yang
dipecah sehingga model pengembangannya secara increment/bertahap.

Kelebihan Metode Incremental :

 Bersifat interatif atau perulangan.
 Mampu mengakomodasi perubahan secara fleksibel.
 Prioritas tinggi pada pelayanan system adalah yang paling diuji.
 11

 Produk yang dihasilkan semakin lama semakin lengkap, hingga versi akhir
dari sebuah produk akan dianggap paling lengkap dan sempurna karena
mengalami perbaikan yang berkesinambungan.
 Model ini cocok jika jumlah anggota tim pengembangan/pembangunan
software terbatas.
 Pelanggan dapat memakai inkremen yang pertama sebagai bentuk
prototype dan mendapatkan pengalaman yang dapat menginformasikan
persyaratan untuk inkremen system berikutnya.
 Resiko untuk kegagalan proyek secara keseluruhan lebih rendah

Kekurangan Metode Incremental :

 Inkremen harus relative lebih kecil (tidak lebih dari 20.000 baris kode) dan
setiap inkremen harus menyediakan sebagian dari fungsional system.
 Adanya kesulitan untuk memetakan persyaratan pelanggan pada inkremen
dengan ukuran yang benar.
 Butuh waktu yang relatif lebih lama untuk menghasilkan produk yang
lengkap

3. Rapid Application Development (RAD)

Metode merupakan model pengembangan system yang melakukan
beberapa penyesuaian terhadap SDLC pada beberapa bagian sehingga lebih
cepat untuk sampai ke tangan pengguna system.

Kelebihan Metode RAD

 Waktu pengembangan yang lebih singkat.
 Biaya yang relatif lebih murah

Kekurangan Metode RAD

 Tidak cocok untuk proyek skala besar
 Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
 Sistem yang tidak bisa dimodularisasi tidak cocok untuk model
 12

 Resiko teknis yang tinggi juga kurang cocok untuk model ini

4. Prototyping Model
Metode ini biasa digunakan jika apabila klien hanya memberikan
kebutuhan umum software saja, tanpa memberikan detail berupa input, proses,
dan output. Namun dalam prosesnya cenderung lambat karena user akan
menambah komponen dari luar sistem. Sehingga kepastian penyelesaian
project pun tidak jelas.

Kelebihan Prototyping Model :

 Adanya komunikasi baik antara pengembang dengan pelanggan.
 Pengembang dapat bekerja lebih baik untuk memenuhi kebutuhan
pelanggan.
 Pelanggan berperan aktif dalam pengembangan sistem.
 Menghemat waktu dalam pengembangannya.
 Penerapan lebih mudah karena pemakai akan mengetahui apa yang
diharapkan.

Kelemahan Prototyping Model :

 Kualitas sistem kurang baik karena hanya mengedepankan aspek
kenyamanan user.
 Pengembang kadang-kadang menggunakan implementasi yang
sembarangan.
 Tidak mencerminkan proses perancangan yang baik

5. Metode Spiral
Model Spiral, merupakan model pengembangan system yang
digambarkan berupa spiral. Model spiral ini tidak merepresentasikan rangkaian
tahapan dengan penelusuran balik (back-tracking), tidak ada fase-fase tahapan
yang tetap seperti spesifikasi atau perancangan. Setiap untaian pada pada spiral
menunjukkan fase software process.
 13

Kelebihan Metode Spiral :

 Dapat digunakan untuk sistem yang besar
 Sangat cocok sebagai mekanisme mengurangi resiko

Kekurangan Metode Spiral :

 Terlalu banyak memikirkan resiko yang akan terjadi
 Masih jarang digunakan
 Metode ini lambat dan mahal karena setiap tahapan yang dilalui harus
menikutsertakan pemesan.

2.2.6. Use Case Diagram

Use case diagram menggambarkan kebutuhan sistem dari sudut pandang
user. Digunakan untuk menggambarkan hubungan antara internal sistem dan
eksternal sistem atau hubungan antara use case dan aktor.
(Nugroho, Adi. 2005. Star uml Untuk Pemodelan Berorientasi Objek. Bandung: Informatika.)

1. Actor
Actor adalah sesuatu (entitas) yang berhubungan dengan sistem
dan berpartisipasi dalam use case. Actor menggambarkan orang, sistem
atau entitas eksternal yang secara khusus membangkitkan sistem dengan
input atau masukan kejadian-kejadian, atau menerima sesuatu dari sistem.
Actor dilukiskan dengan peran yang mereka mainkan dalam use case,
seperti Staff, Kurir dan lain-lain.

Gambar BAB II STUDI LITERATUR-1. Bentuk Actor dalam UML

Dalam use case diagram terdapat satu aktor pemulai atau initiator
actor yang membangkitkan rangsangan awal terhadap sistem, dan mungkin
 14

sejumlah aktor lain yang berpartisipasi atau participating actor. Akan

sangat berguna untuk mengetahui siapa aktor pemulai tersebut.

2. Use Case
Use case yang dibuat berdasar keperluan aktor merupakan
gambaran dari “apa” yang dikerjakan oleh sistem, bukan “bagaimana”
sistem mengerjakannya. Use case diberi nama yang menyatakan apa hal
yang dicapai dari interaksinya dengan aktor.
Dalam UML use case dinotasikan dengan gambar :

Gambar BAB II STUDI LITERATUR-2. Bentuk Use Case dalam UML

3. Relationship
Relasi (relationship) digambarkan sebagai bentuk garis antara dua
simbol dalam use case diagram. Relasi antara actor dan use case disebut
juga dengan asosiasi (association). Asosiasi ini digunakan untuk
menggambarkan bagaimana hubungan antara keduanya.
Relasi-relasi yang terjadi pada use case diagram bisa antara actor
dengan use case atau use case dengan use case.

Gambar BAB II STUDI LITERATUR-3. Bentuk Relationship dalam UML

Relasi antara use case dengan use case :

a. Include, pemanggilan use case oleh use case lain atau untuk
menggambarkan suatu use case termasuk di dalam use case lain
(diharuskan). Contohnya adalah pemanggilan sebuah fungsi
program. Digambarkan dengan garis lurus berpanah dengan tulisan
<<include>>.
 15

b. Extend, digunakan ketika hendak menggambarkan variasi pada

kondisi perilaku normal dan menggunakan lebih banyak kontrol
form dan mendeklarasikan ekstension pada use case utama. Atau
dengan kata lain adalah perluasan dari use case lain jika syarat atau
kondisi terpenuhi. Digambarkan dengan garis berpanah dengan
tulisan <<extend>>.
c. Generalization/Inheritance, dibuat ketika ada sebuah kejadian yang
lain sendiri atau perlakuan khusus dan merupakan pola
berhubungan base-parent use case. Digambarkan dengan garis
berpanah tertutup dari base use case ke parent use case.

2.2.7. Activity Diagram

Diagram aktivitas menggambarkan proses bisnis dan urutan aktivitas-
aktivitas yang mendukung penggambaran tindakan sistem baik yang bersifat
kondisional maupun paralel. Tindakan kondisional dilukiskan dengan cabang
(branch) dan penyatuan (merge).
Sebuah branch memiliki sebuah transition masuk atau yang disebut
dengan incoming transition dan beberapa transition keluar atau yang disebut
dengan outgoing transition dari branch yang berupa keputusan-keputusan. Hanya
satu dari outgoing transition yang dapat diambil, maka keputusan-keputusan
tersebut harus bersifat mutually exclusive. [else] digunakan sebagai keterangan
singkat yang menunjukkan bahwa transition “else” tersebut harus digunakan jika
semua keputusan yang ada pada branch salah.
Sebuah merge memiliki banyak input transition dan sebuah output. Merge
menandakan akhir dari suatu kondisi yang diawali dengan sebuah branch. Selain
branch dan merge, di dalam diagram aktivitas terdapat pula fork dan join. Fork
memiliki satu incoming transition dan beberapa outgoing transition. Sedangkan
pada join, outgoing transition diambil atau digunakan hanya ketika semua state
pada incoming transition telah menyelesaikan aktivitasnya
(Nugroho, Adi. 2005. Star uml Untuk Pemodelan Berorientasi Objek. Bandung: Informatika.).

2.2.8. Sequence Diagram

Diagram yang menggambarkan bagaimana obyek berinteraksi dengan
obyek lainnya melalui pesan (message) yang disampaikan, disusun dalam urutan
kejadian atau waktu dan secara khusus berasosiasi dengan use case.
 16

2.2.9. Class Diagram

Class diagram merupakan bagian yang paling penting dalm analisa dan
perancangan berorientasi obyek. Dalam UML diagram kelas digunakan untuk
memodelkan static structure dari sistem informasi.
Kelas merupakan himpunan dari obyek yang sejenis yang mempunyai
atribut (attribute) dan perilaku (behaviors/method) yang sama. Atribut adalah
sebuah nilai data karakteristik yang dimiliki oleh obyek sebuah kelas sedangkan
method adalah perilaku atau operasi yang dikenakan oleh suatu kelas. Pada
gambar kelas terdapat tiga bagiannya.
(A Suhendar dan Hariman G, Visual Modeling Menggunakan UML dan Relational Rose, cetakan pertama,
Informatika Bandung, 2002)

Gambar BAB II STUDI LITERATUR-4. Bentuk Class dalam UML

Diagram kelas menggambarkan struktur obyek sistem, dimana

diperlihatkan hubungan amtar mereka. Diagram kelas merupakan fondasi untuk
component diagram dan deployment diagram.
Secara garis besar terdapat 3 jenis class. Ketiga jenis class tersebut
dikelompokkan berdasarkan fungsi dan karakternya masing-masing, yaitu :
a. Entity Class Diagram
Merupakan paket utama dari sistem yang berisi kumpulan kelas berupa
entitas-entitas yang membentuk sistem dan menjadi landasan untuk
menyusun basis data pada model data konseptual.

Gambar BAB II STUDI LITERATUR-5. Bentuk Entity Class dalam UML

b. Control Class Diagram

 17

Berisi kumpulan kelas yang menjadi kontrol program termasuk koneksi

dengan basis data dan merupakan kelas perantara atau penghubung antara
entity class dengan kelas antar muka pemakai (interface).

Gambar BAB II STUDI LITERATUR-6. Bentuk Control Class dalam UML

c. Boundary Class Diagram

Berisi kumpulan kelas yang menjadi interface antara pemakai (user)
dengan sistem, seperti tampilan form untuk pencetakan.

Gambar BAB II STUDI LITERATUR-7. Bentuk Boundary Class dalam

UML

1.3. Teori Khusus

2.2.1. Definisi Prototype

Prototyping merupakan salah satu metode pengembangan perangat lunak
yang banyak digunakan. Dengan metode prototyping ini pengembang dan
pelanggan dapat saling berinteraksi selama proses pembuatan sistem.Prototyping
dapat diartikan sebagai proses yang digunakan untuk membantu pengembang
perangkat lunak dalam membentuk model dari perangkat lunak yang harus dibuat.

Model tersebut dapat berupa tiga bentuk:

1. Bentuk prototype di atas kertas/model berbasis komputer yang
menggambarkan interaksi manusia yang mungkin terjadi.
2. Working prototype, yang mengimplementasikan sebagian dari fungsi yang
ditawarkan perangkat lunak.
3. Program jadi yang melakukan sebagian atau seluruh fungsi yang akan
dilakukan, tapi masih ada fitur yang masih dikembangkan.

Sering terjadi seorang pelanggan hanya mendefinisikan secara umum apa

yang dikehendakinya tanpa menyebutkan secara detal output apa saja yang
 18

dibutuhkan, pemrosesan dan data-data apa saja yang dibutuhkan. Sebaliknya disisi
pengembang kurang memperhatikan efesiensi algoritma, kemampuan sistem
operasi dan interface yang menghubungkan manusia dan komputer. Untuk
mengatasi ketidakserasian antara pelanggan dan pengembang , maka harus
dibutuhakan kerjasama yanga baik diantara keduanya sehingga pengembang akan
mengetahui dengan benar apa yang diinginkan pelanggan dengan tidak
mengesampingkan segi-segi teknis dan pelanggan akan mengetahui proses-proses
dalm menyelasaikan sistem yang diinginkan. Dengan demikian akan
menghasilkan sistem sesuai dengan jadwal waktu penyelesaian yang telah
ditentukan.
Kunci agar model prototype ini berhasil dengan baik adalah dengan
mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan dan
pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan
kebutuhan. Prototype akan dihilangkan sebagian atau seluruhnya dan perangkat
lunak aktual aktual direkayasa dengan kualitas dan implementasi yang sudah
ditentukan.
Prototyping merupakan Javascript Framework yang dibuat untuk lebih
memudahkan proses dalam membangun aplikasi berbasis web. Metode protyping
sebagai suatu paradigma baru dalam pengembangan sistem informasi, tidak hanya
sekedar suatu evolusi dari metode pengembangan sistem informasi yang sudah
ada, tetapi sekaligus merupakan revolusi dalam pengembangan sistem informasi
manajemen.

Karakteristik metode prototyping meliputi langkah-langkah:

1. Pemilahan fungsi
2. Penyusunan Sistem Informasi
3. Evaluasi
4. Penggunaan Selanjutnya

Kegunaan prototype yaitu antara lain:

a) Evaluasi dan feedback pada rancangan interaktif.
b) Stakeholder (dalam hal ini user) dapat melihat, menyentuh, berinteraksi
dengan prototype.
c) Anggota tim dapat berkomunikasi secara efektif.
d) Para perancang dapat mengeluarkan ide-idenya.
e) Memunculkan ide-ide secara visual dan mengembangkannya.
f) Dapat menjawab pertanyaan untuk membantu pemilihan di antara
alternatif-alternatif.
 19

2.2.2. Jenis –Jenis Prototype

Jenis-jenis prototyping meliputi:
1. Feasibility prototyping
Feasibility prototyping – digunakan untuk menguji kelayakan dari
teknologi yang akan digunakan untuk system informasi yang akan disusun.
2. Requirement prototyping
Requirement prototyping – digunakan untuk mengetahui kebutuhan
aktivitas bisnis user.
3. Desain Prototyping
Desain Prototyping - digunakan untuk mendorong perancangan system
informasi yang akan digunakan.
4. Implementation prototyping
Implementation prototyping – merupakan lanjytan dari rancangan protipe,
prototype ini langsung disusun sebagai suatu system informasi yang akan
digunakan.

Teknik-teknik prototyping meliputi:

 Perancangan Model
 Perancangan Dialog
 Simulasi

2.2.3. Tahapan – Tahapan Prototype

Tahapan-tahapan dalam Prototyping adalah sebagai berikut:
1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh
perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar
sistem yang akan dibuat.
2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang
berfokus pada penyajian kepada pelanggan (misalnya dengan membuat
input dan format output).
3. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah
dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai
maka langkah 4 akan dia`mbil. Jika tidak prototyping direvisi dengan
mengulangi langkah 1, 2 , dan 3.
4. Mengkodekan system
Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke
dalam bahasa pemrograman yang sesuai.
 20

5. Menguji system
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus
dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White
Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.
6. Evaluasi Sistem.
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai
dengan yang diharapkan . Juka ya, langkah 7 dilakukan; jika tidak, ulangi
langkah 4 dan 5.
7. Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk
digunakan.

Teknik-teknik yang digunakan:

 Storyboard
adalah bentuk prototype yang paling sederhana berupa gambaran secara
grafis dari tampilan sistem yang akan dibangun tanpa fungsi dari sistem.
 Simulasi Fungsi Terbatas
fungsi sistem disertakan pada prototype tidak sekadar gambar tampilannya
saja.
 High-Level Programming Support
HyperTalk adalah contoh dari special-purpose high-level programming
language yang memudahkan desainer membuat fitur tertentu dari sebuah
sistem interaktif.

2.2.4. Keunggulan dan Kelemahan Prototype

1. Keunggulan Prototype
 Adanya komunikasi
yang baik antara pengembang dan pelanggan
 Pengembang dapat
bekerja lebih baik dalam menentukan kebutuhan pelanggan
 Pelanggan berperan
aktif dalam pengembangan system
 Lebih menghemat
waktu dalam pengembangan syste
 Penerapan menjadi
lebih mudah karena pemakai mengetahui apa yang diharapkannya.

2. Kelemahan Prototype
 21

a. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak

yang ada belum mencantumkan kualitas perangkat lunak secara
keseluruhan dan juga belum memikirkan kemampuan pemeliharaan
untuk jangja waktu lama.
b. Pengembang biasanya ingin cepat menyelesaikan proyek. Sehingga
menggunakan algoritma dan bahasa pemrograman yang sederhana
untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih
lanjut bahwa program tersebut hanya merupakan cetak biru sistem.
c. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak
mencerminkan teknik perancangan yang baik

Prototyping bekerja dengan baik pada penerapan-penerapan yang berciri

sebagai berikut:
1. Resiko tinggi
Yaitu untuk masalah-masalah yang tidak terstruktur dengan baik, ada
perubahan yang besar dari waktu ke waktu, dan adanya persyaratan data yang
tidak menentu.
2. Interaksi pemakai penting
Sistem harus menyediakan dialog on-line antara pelanggan dan komputer.
3. Perlunya penyelesaian yang cepat
4. Perilaku pemakai yang sulit ditebak.
5. Sitem yang inovatif
Sistem tersebut membutuhkan cara penyelesaian masalah dan penggunaan
perangkat keras yang mutakhir.
6. Perkiraan tahap penggunaan sistem yang pendek

2.2.5. Mengapa Memilih Prototype

Karena dalam proyek sistem ini kami (salah satu anggota) mengetehui
prosedur kerja yang telah berjalan sebelumnya. Sehingga dalam
pengembangannya akan lebih mudah karena kebutuhan dalam pengembangan
sistem lebih cepat diketahui.
 22

BAB III
METODE PENGEMBANGAN PERANGKAT LUNAK

1.4. Metodologi
Pada perancangan kami mengambil metodelogi prototype

1.5. Rencana Pengerjaan Project

Dengan adanya analisis dan rencana pengujian sistem program pada
bengkel spare part ini diharapkan diketahui kekurangan-kekurangan sehingga
dapat dilakukan perbaikan dan pengembangan sistem dan rencana implementasi
sistem informasi datang dan keluar suku cadang pada bengkel diharapkan
kegiatan- kegiatan yang berkaitan dengan bengkel tersebut dapat berjalan
dengan lebih efektif dan efisien.
Tahap perencanaan ini merupakan tahapan awal pengembangan sistem
yang mendefinisikan perkiraan kebutuhan-kebutuhan konsumen, seperti :
perangkat fisik, metode dan anggaran yang sifatnya masih umum. Dalam tahap ini
juga dilakukan langkah-langkah berupa : mendefinisikan masalah, menentukan
tujuan sistem, mengidentifikasi kendala-kendala sistem dan membuat studi
kelayakan.
Kebanyakan sistem penyimpanan sparepart saat ini masih menggunakan
cara manual. Dimana dalam melakukan pendataan barang yang masuk dan keluar
user jharus mendata barang secara manual, kemudian dicatat dibuku stock barang.
sehingga mungkin saja terjadi kesalahan-kesalahan antara lain penghitungan yang
kurang akurat dan waktu yang cukup lama dalam pengolahannya. Oleh sebab itu
kamu merancang program inventory sparepart.
Perlu adanya sistem yang terkomputerisasi serta aplikasi yang mendukung
sehingga dapat digunakan oleh bagian arsip untuk mengatasi
permasalahan/kelemahan yang ada seperti kesalahan dalam menghitung stok
barang dan meninput jumlah barang yang baru di stok
Penghematan waktu dalam mencari jumlah stok barang yang ada di
gudang bila suatu saat diperlukan, karena menambahkan pengarsipan dokumentasi
 23

dengan soft copy sehingga lebih efisien.

Berikut kami jelaskan rencana apa yang akan kita lakukan pada tiap tahap
dalam metode prototype ini :

1. Pengumpulan Kebutuhan
Pada tahapan ini akan melaksanakaan Studi Kasus Kontrol spare
Part di Tiap Shop PT Astra Daihatsu Motor. yang nantinya sebagai
perancang dan pemakai aplikasi Sistem Inventory Spare Part mengenai
kelebihan dan kekurangan dengan sistem control spare part yang sedang
berjalan sekarang.

2. Membangun Prototyping
Pada tahap pembangunan prototyping, pengembang dan pembuat
sistem bersama-sama membuat format input maupun output yang akan
dihasilkan oleh sistem yang dibuat.Pada tahapan ini data yang di peroleh
dari pengumpulan kebutuhan di olah untuk memperoleh kesimpulan
tentang hal-hal apa saja yang perlu di inputkan oleh pengguna sehingga
sistem Inventory spare part ini dapat berjalan dan hasil dari pemrosesan
inputan tersebut yang menghasilkan output yang diharapkan
Adapun Tahapan dari perancanagn ini dimulai dari:
1. Analisis Sistem Yang Sedang berjalan
2. Perencanaan Diagram UML, meliputi Use case Diagram, Activity
Diagram, Sequence Diagram, Colaboration Diagram, dan Class
Diagram
3. Perencanaan Tampilan layar menggunakan WEB PAGE MAKER.

3. Evaluasi Prototyping
Selanjutnya, setelah tahap pembangunan prototyping, prototype
yang telah dirancang akan dievaluasi, apabila dalam perancangan
prototype sesuai yang diharapkan maka akan lanjut ke tahap pengkodean
system, namun jika belum sesuai yang diharapkan maka akan kembali ke
tahap pengumpulan kebutuhan untuk menggali lagi kebutuhan yang
dibutuhkan. Selanjutnya ke tahap pembangunan prototyping kembali dan
dievaluasi kembali hingga perancangan prototype ini sesuai yang
diharapkan sehingga bisa lanjut pada tahap selanjutnya.
 24

4. Mengkodekan System
Pada tahap ini, sistem yang ingin dibuat akan dibuatkan kedalam
bahasa pemprogramaan java, kemudian unruk menghasilkan interface dan
juga fungsional aplikasi tsb. Selain itu untuk menghasilkan website bagi
admin yang menggunakannya juga akan dibuat ke dalam bahasa
pemrogaman HTML.

5. Menguji System
Pengujian merupakan bagian yang penting dalam pembangunan
sebuah perangkat lunak. Rencana pengujian yang akan dilakukan dalam
pembangunan sistem Inventory Spare Part ini menggunakan metode
pengujian black box. Pengujian black box ini menitikberatkan pada fungsi
sistem. Metode ini digunakan untuk mengetahui apakah perangkat lunak
berfungsi dengan benar atau tidak.

6. Evaluasi System
Evaluasi system bukanlah evaluasi prototyping, melainkan
mengevaluasi system atau perangkat lunak yang sudah jadi apakah sudah
sesuai dengan keinginan pelanggan atau belum. Jika belum, maka system
akan direvisi kembali dan kembali ketahap pengkodean sistem selanjutnya
dilakukan pengujian sistem kembali. Jika system sudah dikatakan OK
maka system siap dilanjutkan pada tahap selanjutnya yaitu penggunaan
sistem.

7. Menggunakan System
Pada tahapan ini aplikasi yang telah selesai dibuat dan telah lulus
uji di implementasikan pada pengguna Sistem untuk digunakan sebagai
Sistem Kontrol Spare part yang baru.

1.6. Schedule Pembuatan Sistem

Berdasarkan rencana yang akan kami lakukan pada tiap tahap dalam
metode pengembangan prototype maka kami akan membuat jadwal pelaksanaan
 25

agar pembuatan sistem ini lebih terkontrol. Berikut shedule pada tiap tahap
metode prototype :

Gambar 3-1. Tahap dalam Prototype

BAB IV
PEMBAHASAN

1.7. Analisa Sistem Berjalan

Analisa sistem berjalan perlu dilakukan terlebih dahulu dengan tujuan
memahami proses bisnis yang telah ada supaya dapat menentukan ruang lingkup
perancangan sistem.

2.2.1. Uraian Prosedur

Dalam melakukan kegiatanya di bidang spare part kontrol, maintenance
departemen melakukan berbagai kegiatan melalui tahap-tahap berikut:
a. Foreman akan memisahkan barang consumabe, slow moving dan fast
moving
 26

b. Member akan mengambil dan mencatat barang ( spare part ) yang

diambil
c. Member akan mengecek persediaan barang, kemudaian apabila dirasa
stok minim atau kosong akan mengajukan form order
d. Member akan melakukan stock taking untuk evaluasi penggunaan dan
data aktual spare part.

2.2.2. Analisa Proses

Analisa proses bertujuan untuk mengetahui flow proses pkontrol spare part
maintenance Departement PT Astra Daihatsu otor. Analisa proses ini dapat dilihat
dari activity diagram sistem yang berjalan berikut ini.

Gambar. 4-1. Activity Diagram Pengambilan part

 27

Gambar 4-2. Activity Diagram Pengajuan Pengadaan Barang

Gambar 4-3. Activity Diagram Penerimaan Barang

 28

Gambar. 4-4. Activity Diagram Pengeluaran Barang

Gambar 4-5 Activity Diagram Penghitungan anual Stok

 29

Dari Sistem yang ada, beberapa Kelemahan-kelemahan yang terbagi dalam

6 Analisis. Dari Kelemahan tersebutakan ditawarkan Solusi-solusiuntuk Sistem
Baru di Warehouse PT Astra Daihatsu Motor.

1. Analisis Performance

Analisa Kelemahan Solusi

Proses Input Input Transaksi Dibuatkan Inventory Spare Part
Semua Transaksi berpotensi terjadi
Masih Manual kesalahan
Kesulitan Dalam Pendataan Spare Part Dibuatkan Database untuk
Pendataan Spare Untuk Tiap Shop Masih Menyimpan semua data
Part dari pembukuan Manual Transaksi.
Biasa.

2. AnalisisInformasi

Analisa Kelemahan Solusi

Dengan Sistem Inventory Spare
Sistem Pengarsipan untuk
Part ini, selain menginputkan
Tiap Shop Tidak ada
Akurat Transaksi yang ada Sitem akan
datanya, karena dari Shop
menyimpan ke database sehingga
hanya submit data input
kapanpun data dibutuhkan mudah
manual ke Central
untuk diketahui.
Warehouse.

3. Analisis Ekonomi
 30

Analisa Kelemahan Solusi

Membutuhkan/ Membuang
DFengan Sistem Inventory
Kertas, karena sebelumnya
Spare Part, Bisa Dikontrol untuk
Ekonomi semua transaksi dari shop
Penggunaan hard Copynya,
menggunakan Paper.
karena Semua sudah di arsipkan
di database.

4. Analisi Control

Kelemahan Solusi
Membutuhkan Pengarsipan untuk data- Dengan Sistem Invebtory Spare Part
data Inventory Spare Part di tiap shop. segala Bentuk Pengarsipan akan
Hal Ini akan Mempersulit Kerja tersimpan dalam data base
Member

5. Analisis Efisiensi

Kelemahan Solusi
Keseluruhan Rangkaian Proses Dengan Sistem Inventory spare part ini
Transaksi yang terjadi di Warehouse lebih cepatkarena keseluruhan
Shop Masih Menggunakan Sistem prosesnya sudah terkomputerisasi.
manual sehingga memakan waktu yang
lama

6. Analisi Service

Tahap Sistem Inventory Usulan Sistem

Transaksi 1. Input Good Issue
2. Input Good Received
3. Input TransferBarang
4. Input Order Barang
 31

5. Input Status Stok

6. Input sto

1. Report good Issue

2. Report Good Received
Report 3. Report Transfer Barang
4. Report Order Barang
5. Report Status Stok
6. Report STO

DAFTAR PUSTAKA

A.O’Brien.James. Management Information System Managing Techonology

in The E-Business Enterprise. McGraw Hill, 2002.
 32

A Suhendar dan Hariman G, Visual Modeling Menggunakan UML dan

Relational Rose, cetakan pertama, Informatika Bandung, 2002.
Jogiyanto HM. Sistem Informasi Berbasis Komputer, Yogyakarta : BPFE
Yogyakarta, 1997.
Kendall & Kendall, 2006, Aji Supriyanto, 2005: 272 tentang SDLC
Kreger, H., 2001, Web-services Conceptual Architecture (WSCA 1.0), IBM
Software Group, USA
Nugroho, Adi. 2005. Star uml Untuk Pemodelan Berorientasi Objek.
Bandung: Informatika.