Embed Size (px)
Citation preview
6
BAB 2
LANDASAN TEORI
2.1 Teori – teori Dasar/Umum
2.1.1 Pengertian Sistem Informasi
Sistem menurut O’Brien (2001, p8) merupakan kumpulan dari komponen –
komponen yang saling berhubungan yang bekerja sama menuju suatu tujuan dengan
menerima input dan menghasilkan output melalui proses transformasi yang terorganisir.
Sistem menurut Mathiassen et al (2000, p9) mengatakan bahwa sistem adalah
sekumpulan komponen yang mengimplementasi persyaratan modelling, functions, dan
interfaces. Dari pengertian – pengertian tersebut, dapat disimpulkan bahwa pengertian
sistem secara umum adalah sekumpulan komponen yang saling terintegrasi yang
mengimplementasi persyaratan modelling, functions dan interfaces untuk mencapai
suatu tujuan melalui transformasi.
Informasi menurut Mcleod (2001, p15) adalah data yang telah diproses atau data
yang memiliki arti. Laudon dan Laudon (2003, p7) mengatakan bahwa informasi adalah
data yang telah diubah menjadi suatu bentuk yang lebih berarti dan berguna bagi
manusia. Berdasarkan definisi–definisi di atas dapat disimpulkan bahwa informasi
merupakan data yang mengalami pemrosesan sehingga menjadi lebih berguna bagi
pihak yang membutuhkan.
Sistem Informasi menurut Laudon dan Laudon (2003, p7) adalah komponen –
komponen yang saling berhubungan dan bekerja sama untuk mengumpulkan,
memproses, menyimpan dan mendistribusikan informasi untuk mendukung pengambilan
keputusan, koordinasi, kontrol, analisis, dan visualisasi dalam suatu organisasi. Sistem
informasi dapat berupa kombinasi sumber daya – sumber daya yang terorganisir dari
7
manusia, perangkat keras, piranti lunak, jaringan komunikasi, dan data yang
mengumpulkan, mengubah, dan mendistribusikan informasi pada suatu organisasi
(O’Brien, 2001, p7). Jadi Sistem Informasi adalah sekumpulan komponen yang saling
berinteraksi guna mengumpulkan, memproses, menyimpan dan mendistribusikan
informasi dalam suatu organisasi.
2.1.2 Pengertian Sistem Informasi Manajemen
Menurut Laudon dan Laudon (2003, p43) Sistem Informasi Manajemen adalah
Sistem Informasi pada tingkat fungsi manajemen dengan menyediakan laporan-laporan
untuk manajer atau dengan akses langsung ke dalam kegiatan terakhir dan data-data
sebelumnya. Sistem Informasi Manajemen menyediakan informasi dalam bentuk
laporan dan menyajikannya bagi manajer dan para profesional bisnis (O’Brien, 2001,
p29). Berdasarkan pengertian-pengertian di atas, dapat ditarik kesimpulan bahwa Sistem
Informasi Manajemen adalah Sistem Informasi yang menyajikan informasi berupa
laporan untuk mendukung pihak manajemen.
2.1.3 Pengertian Analisis Sistem
Analisis sistem menurut McLeod (2001, p190) adalah penelitian atas sistem yang
telah ada dengan tujuan untuk merancang sistem baru atau diperbarui. Analisis lebih
menekankan pada penyelidikan atas suatu masalah daripada bagaimana sebuah solusi
didefinisikan (Larman, 1998, p6). Dari beberapa pendapat di atas, maka dapat
disimpulkan bahkan analisis sistem secara umum adalah penelitian atas sistem yang
telah ada dengan lebih menekankan pada masalahnya untuk mendapatkan informasi
yang diperlukan guna merancang sistem yang baru.
8
2.1.4 Pengertian Perancangan Sistem
Rancangan sistem adalah penentuan proses dan data yang diperlukan oleh sistem
baru (McLeod, 2001, p192). Dalam bukunya, Whitten et al (2001, p13) mengatakan
bahwa perancangan sistem merupakan spesifikasi atau konstruksi dari solusi teknikal
berbasis komputer bagi persyaratan bisnis yang diidentifikasikan dalam analisis sistem.
Dengan demikian, dapat disimpulkan bahwa perancangan sistem adalah penentuan
spesifikasi yang diperlukan oleh sistem baru sebagai solusi teknikal dari permasalahan
yang diidentifikasikan dalam analisis sistem.
2.1.5 Object-Oriented
Dari tahun 1950 sampai dengan tahun 1970-an, perusahaan-perusahaan
menekankan proses saat mengembangkan Sistem Informasi dan menggunakan alat-alat
pembuatan model proses seperti bagan arus (flowchart) dan diagram arus data (Data
Flow Diagram). Selama tahun 1970-an dan 1980-an, penekanan bergeser ke data,
dengan menggunakan diagram hubungan entitas (Entitas Reationship Diagram – ERD)
dan kamus data. Selama tahun 1990-an, kecenderungan berubah ke mengkombinasikan
proses dan data menjadi object (McLeod, 2001, p330).
Keuntungan Object-Oriented menurut Mathiassen et al (2000, p5-6) adalah :
1. Merupakan konsep umum yang dapat digunakan untuk memodelkan hampir semua
fenomena yang ada di dunia dengan menggunakan bahasa alami.
- Noun menjadi object atau class
- Verb menjadi behavior
- Adjective menjadi attributes
2. Menyediakan informasi yang jelas mengenai context dari sistem
9
3. Mengurangi biaya maintenance atau development
2.1.6 Object-Oriented Analysis and Design (OOA&D)
Object-Oriented Analysis and Design (OOA&D) berusaha untuk menggabungkan
data dan proses menjadi suatu gagasan tunggal yang diebut objects. OOA&D
memperkenalkan object diagrams yang mengdokumentasikan sistem dipandang dari
segi objects dan interaksinya (Whitten et al, 2001, p97). Menurut Larman (1998, p6)
intisari dari OOA&D adalah penekanan pada pertimbangan Problem Domain dan solusi
logis dari persepsi objects (sesuatu, konsep, entitas).
Menurut Mathiassen et al (2000, pp14-15) terdapat 4 aktivitas utama dalam
OOA&D, yaitu Problem Domain Analysis, Application Domain Analysis, Architectural
Design, dan Component Design.
10
Component Design- Model Component
- Function Component- Connecting Component
Problem DomainAnalysis- Classes
- Structure- Behavior
ApplicationAnalysis- Usage
- Functions- Interface
Architectural Design- Criteria
- Components- Processes
SystemDefinition
Model
Requirements foruse
Spesifications ofcomponents
Spesification ofarchitecture
Gambar 2.1 Aktivitas utama dalam OOA&D(Mathiassen et al, 2000, p15 & p332)
2.1.7 System Choice
Sebuah proyek pengembangan berawal dari berbagai macam ide yang berbeda
tentang sistem yang diinginkan. System Choice didasarkan pada tiga subaktivitas.
Subaktivitas yang pertama dipusatkan pada tantangan-tantangan, kita mencoba
mendapatkan kedua gambaran umum dari situasi dan berbagai cara orang-orang
menginterpretasikannya. Subaktivitas yang kedua adalah menciptakan dan mengevaluasi
ide-ide untuk perancangan sistem. Metode kita menawarkan berbagai urutan teknik-
teknik untuk mendukung kreativitas dan memperkenalkan cara baru dalam berpikir.
Dalam aktivitas yang ketiga, kita memformulasikan dan memilih system definition,
11
membicarakan dan mengevaluasi alternatif system definitions dalam hubungannya pada
situasi yang kita hadapi (Mathiassen et al, 2000, p25).
2.1.8 System Definition
System definition merupakan deskripsi singkat dari sebuah sistem komputerisasi
yang dinyatakan dalam bahasa alami (Mathiassen et al, 2000, p24). Sebuah system
definition menyatakan bagi pengembangan sistem dan penggunaannya. Yang juga
menggambarkan sistem dalam hubungannya, informasi apa yang harus dikandungnya,
fungsi mana yang harus disediakan, dimana akan digunakan dan kondisi pengembangan
apa yang akan diterapkan.
System definitions dapat membantu untuk menampung pandangan umum dari
pilihan yang berbeda-beda, dan bisa digunakan untuk perbandingan alternatif. System
definition yang akhirnya dipilih harus menyediakan landasan-landasan yang baik untuk
kelangsungan analisa dan aktivitas perancangan.
2.1.9 Problem Domain Analisys
Pada tahap ini dilakukan pengidentifikasian informasi-informasi yang harus ada
pada suatu sistem untuk menghasilkan sebuah model sistem. Problem Domain
merupakan bagian dari keadaan yang akan diatur, dipantau, dan dikontrol oleh sistem
(Mathiassen et al, 2000, p6). Sumber dari aktivitas ini adalah system definition, yaitu
deskripsi singkat dan jelas dari sistem terkomputerisasi dengan menggunakan bahasa
alami (Mathiassen et al, 2000, p24).
Terdapat tiga subaktivitas yang harus dilakukan untuk membuat system definition,
yaitu usaha untuk mendapatkan pandangan menyeluruh dari situasi, membuat dan
12
mengevaluasi ide-ide untuk pendesainan sistem, dan diakhiri dengan memformulasi dan
mengevaluasi system difinition sesuai dengan situasi yang ada (Mathiassen et al, 2000,
p25).
Rich Picture dapat memperjelas pandangan user mengenai situasi, permasalahan,
dan mendapatkan pandangan keseluruhan situasi dengan cepat, Rich Picture adalah
gambar informal yang mempresentasikan pemahaman ilustrator mengenai situasi
(Mathiassen et al, 2000, p26).
Menurut Cosgrave, Rich Picture menggambarkan orang-orang yang terlibat,
tujuan, keinginan dan ketakutan mereka (biasanya dalam balon-balon pikiran). Rich
Picture juga menggambarkan detil lingkungan dengan lebih banyak dibanding
kebanyakan diagram (aktivitvas manusia, seperti proses-proses, melewati batas
organisasional), serta menggambarkan bagaimana elemen-elemen sejalan atau
bertentangan. Rich Picture adalah kartun – rich picture bisa lucu, sedih, politikal dan
lebih baik lagi jika semuanya menjadi satu. Berikut ini merupakan karakteristik dari rich
picture :
1. Harus diungkapkan sendiri dan mudah dimengerti
2. Tidak ada cara yang benar dalam menggambarkan rich picture karena
merupakan proses yang subjektif
3. Tidak terstruktur
4. Bagian-bagiannya meliputi fakta, benda, orang, aktor eksternal, hubungan,
pertentangan, kebingunan.
5. Perlu mengidentifikasi tugas utama bagi sistem
Mathiassen (2000, pp39-40) menulis bahwa di dalam system definition terdapat
enam elemen kriteria FACTOR, yaitu :
13
1. Functionality : fungsi-fungsi sistem yang mendukung tugas-tugas Application
Domain
2. Application Domain : bagian dari organisasi yang mengatur, memonitor atau
mengontrol suatu Problem Domain.
3. Conditions : kondisi dimana suatu sistem dikembangkan dan digunakan
4. Technology : teknologi yang digunakan untuk mengembangkan sistem dan
teknologi saat sistem dijalankan
5. Objects : object-object utama di dalam Problem Domain
6. Responsibility : tanggung jawab seluruh sistem dalam hubungannya dengan
konteks.
Mathiassen (2000, pp46-47) di dalam bukunya menulis bahwa terdapat tiga
subaktivitas dalam Problem Domain Analysis, yaitu :
Classes Behavior
Structure
System Definition
Model
Gambar 2.2 Aktivitas dalam Problem Domain Analysis(Mathiassen et al, 2000, p46)
14
1. Classes
Merupakan tahapan dilakukannya pemilihan class dan event dari system definition
untuk menghasilkan event table. Class adalah deskripsi dari kumpulan object yang
mempunyai structure, behavioural pattern, dan attributes yang sama. Object adalah
suatu entitas yang memiliki identity, state, dan behaviour (Mathiassen et al, 2000, p4).
Pada tahap analisis, biasanya sebuah class cukup dideskripsikan dengan namanya saja,
tetapi dapat juga ditambahkan detail attributes dan operation. Event adalah kejadian
bersifat instan yang melibatkan satu atau lebih object (Mathiassen et al, 2000, p51).
+operation()-attribute
Class
Class Object : Class
Class with attributes andoperation
Gambar 2.3 Notasi dasar dari class( Mathiassen et al, pp337 - 339)
Menurut Mathiassen et al (2000, pp53-55) untuk menjalankan aktivitas classes
dapat dimulai dengan mengidentifikasikan kandidat/calon yang mungkin untuk classes
dan events dalam model Problem Domain. Setelah itu, evaluasi dan pilih secara kritis
classes dan events yang benar-benar relevan dengan konteks sistem.
2. Structure
Tujuannya adalah untuk mendeskripsikan hubungan struktural antara class dan
object. Sumber dari tahap ini adalah event table yang dihasilkan dari tahap sebelumnya,
sedangkan hasil akhirnya adalah membuat Class Diagram, yaitu diagram yang
menyediakan gambaran ikhtisar Problem Domain yang bertalian secara logis dengan
menggambarkan seluruh hubungan struktural antara classes dan objects di dalam model
(Mathiassen et al, 2000, pp69-70).
15
Vehicle
Truck
Wheel
Owner
1
*
* 1
Gambar 2.4 Class Diagram
Menurut Mathiassen et al (2000, pp72-77) terdapat dua tipe structure dalam
Object-Oriented, yaitu :
1. Class Structure, mengekspresikan hubungan konseptual yang statis antar class.
Hubungan statis ini tidak akan berubah, kecuali terjadi perubahan pada deskripsinya.
Class structure dibagi menjadi dua macam, yaitu :
a. Generalization Structure, merupakan hubungan antara dua atau lebih subclass
dengan satu atau lebih superclass (Mathiassen et al, 2000, p72). Sebuah class
yang umum (superclass) mendeskripsikan properti umum kepada group dari
spesial class (subclass). Atau dengan kata lain, terjadi penurunan attributes dan
behaviour dari superclass, tetapi subclass juga diperkenankan untuk memiliki
attributes dan behaviour tambahan. Secara ilmu bahasa, generalization structure
diekspresikan dengan formula “is a”.
16
Passenger Car
Taxi Private Car
Gambar 2.5 Generalization Structure
(Mathiassen et al, 2000, p73)
b. Cluster, merupakan kumpulan dari class yang berhubungan (Mathiassen et al,
2000, p74). Cluster digambarkan dengan notasi file folder yang melingkupi
class-class yang saling berhubungan di dalamnya. Class-class dalam satu cluster
biasanya memiliki hubungan berupa generalization atau aggreagation.
Sedangkan hubungan class dengan cluster yang berbeda biasanya berupa
association structure.
<<cluster>>
Generalization
Gambar 2.5 Notasi Class Structure(Mathiassen et al, 2000, p337)
17
<<Clusters>>Cars
Car
Engine PassengerCar
Cylinder Taxi
<<Clusters>>People
Owner
Clerk
Gambar 2.6 Cluster Stucture (Mathiassen et al, 2000, p75)
2. Object Structure, mengekspresikan hubungan dinamis dan konkret antar object.
Hubungan ini dapat berubah secara dinamis tanpa mempengaruhi perubahan pada
deskripsinya. Biasanya terdapat multipicity yang menspesifikasikan jumlah dari
object yang berelasi. Multiplicity dapat berupa string of numbers dan penyebaran
interval dengan koma, seperti “0,3,7,9..13,19..*”; “*” disebut many; dan 0..*”. Ada 2
macam object structure yaitu :
a. Aggregation Structure, mendefinisikan hubungan antara dua atau lebih object.
Sebuah superior object (whole) memiliki beberapa object (parts) (Mathiassen et
al, 2000, p76). Secara ilmu bahasa, aggregation structure diekspresikan dengan
formulasi “has a”, “a-part-of’, atau “is-owned-by”. Terdapat 3 tipe aggregation
structure (Mathiassen et al, 2000, p79) yaitu :
• Whole-part, dimana whole merupakan jumlah dari parts, sehingga jika salah
satu parts dihilangkan maka secara tidak langsung telah mengubah whole.
18
• Container-content, dimana whole adalah kontainer (tempat tampung) dari
parts-nya, sehingga bila terdapat penambahan atau pengurangan terhadap
isinya (parts), tidak akan mengubah pengertian dari whole-nya.
• Union-member, dimana whole merupakan union/gabungan yang terorganisir
dari anggotanya (parts), sehingga jika terdapat penambahan atau
pengurangan anggota, tidak akan mengubah union-nya. Terdapat batasan
jumlah anggota terendah, karena tidak mungkin sebuah union tanpa anggota.
b. Association Structure, mendefinisikan hubungan antara dua atau lebih object,
tetapi berbeda dengan aggregation (Mathiassen et al, 2000, p76). Hubungan
antar class-class pada aggregation mempunyai pertalian yang kuat sedangkan
pada association tidak kuat. Secara ilmu bahasa, association structure
diekspresikan dengan formulasi “knows” atau “associated-with”.
-a..b*
-c..d
*
-a..b*
-c..d
*
Ket : a - d adalah multipicity
Gambar 2.7 Notasi Object Structure(Mathiassen et al, 2000, p337)
Car Person0..* 1..*
Gambar 2.8 Association Structure (Mathiassen et al, 2000, p77)
19
3. Behavior, tujuan dari aktivitas ini adalah untuk memodelkan keadaan problem
domain yang dinamis dengan memperluas definisi class yang terdapat dalam Class
Diagram, yaitu dengan menambahkan behavioural patterns dan attributes untuk
setiap class. Sumber dari tahap ini adalah event table dan class diagram yang telah
dihasilkan dari tahap-tahap sebelumnya. Sedangkan hasil akhirnya adalah behavioral
patterns yang diekspresikan secara grafis dalam Statechart Diagram (Mathiassen et
al, 2000, p89-p90).
Dalam class activity, behavior dipandang sebagai kumpulan events yang tidak
berurutan yang meliputi suatu object. Sedangkan dalam behavior activity, behavior
secara lebih tepat dideskripsikan dengan menambahkan waktu terjadinya events.
Object behavior diidentifikasikan dengan event trace, yaitu serangkaian events
yang berurutan yang meliputi suatu object. Events trace antara satu object mungkin
berbeda dengan object lain meskipun kedua object tersebut berada dalam class yang
sama. Hal ini disebabkan karena sifat event trace yang unik untuk object tertentu.
Deskripsi dari event trace yang mungkin untuk seluruh object dalam sebuah class
disebut behavioral pattern (Mathiassen et al, 2000, p90).
Dalam memodelkan Problem Domain, dilakukan pengidentifikasian requirements
untuk data-data yang akan disimpan oleh sistem. Untuk menspesifikasikan data tersebut
digunakan attributes, yaitu deskripsi properti dari class atau events (Mathiassen et al,
2000, p92).
Menurut Mathiassen et al (2000, p93) behavioral pattern memiliki struktur kontrol
sebagai berikut :
- Sequence adalah suatu set events yang akan terjadi satu per satu (secara berurutan).
Notasinya : “+”.
20
- Selection adalah satu event yang terjadi dari suatu set events. Notasinya : “|”
- Iteration adalah satu event yang terjadi berulang-ulang kali. Notasinya : “*”.
Jika menghadapi situasi behavior patterns yang kompleks, akan sulit sekali untuk
mengekspresikannya dalam notasi-notasi umum sehingga untuk pengekspresiannya
lebih cenderung menggunakan Statechart Diagram.
Gambar 2.8 Notasi dasar Statechart Diagram(Mathiassen et al, 2000, p341)
Initial State Final State
State
event(attributes)[condition] Transition with event andcondition
Gambar 2.9 Struktur Kontrol Statechart Diagram(Mathiassen et al, 2000, p95)
State 1
State 1
State n
State
.
.
.
. . .
TransitionSequence Selection
21
2.1.10 Application Domain Analysis
Tahap ini mendefinisikan requirements dari suatu sistem. Application Domain
merupakan bagian yang mengatur, memantau, atau mengontrol Problem Domain
(Mathiassen et al, 2000, p6). Atau dengan kata lain, berhubungan dengan aktivitas yang
dikerjakan/dijalankan oleh sistem. Prinsip dari Application Domain analysis adalah
bekerja sama dengan user untuk menentukan usage, function dan interface. Sumber dari
aktivitas ini adalah system definition dan model dari tahap sebelumnya.
Usage Interfaces
Funtions
System Definition andModel
Requirements
Gambar 2.10 Aktivitas dalam Application Domain Analysis(Mathiassen et al, 2000, p117)
Menurut Mathissen et al (2000, p117) terdapat tiga subaktivitas dalam Application
Domain Analysis, yaitu :
1. Usage
Hasil akhir dari aktivitas ini adalah membuat deskripsi dari actors dan use cases,
dimana relasinya diekspresikan dengan menggunakan actor table atau use case
Diagram. Actor merupakan abstaksi dari user atau sistem lain yang berinteraksi dengan
sistem (Mathiassen et al, 2000, p119). Sedangkan use case adalah pola interaksi antara
22
sistem dengan actors dalam application domain (Mathiassen et al, 2000, p120).
Hubungan antara actor dan use case adalah association.
System
Actor
UseCase
Actor..
* * * *
Gambar 2.11 Use Case Model(Schmuller,1999, p76)
Menurut Armour dan Miller (2001, p7) untuk mendokumentasikan actors dapat
menggunakan actor specifications yang berisi informasi mengenai actor name (nama
actor), abstract (menjelaskan peranan actor sebagai abstract actor atau bukan), dan
description (menjabarkan peranan actor dalam sistem). Abstract actor menggambarkan
behavior yang sama antara dua actor atau lebih.
Actor Spesifications Template
Actor name : <nama> Abstract : <Yes/No>
Description : <deskripsi dari peran aktor>
Tabel 2.1 Actor Specification(Armour and Miller, 2001, p16)
Adanya use case description dapat mempermudah pemahaman mengenai interaksi
antra actors dan sistem serta tanggung jawab dan behavior sistem dalam responsnya
terhadap interaksi tersebut (Armour dan Miller, 2001, p90) use case description berisi
23
informasi mengenai nama use case, use case ID, actor yang terlibat dan description
(menjelaskan garis besar dari use case tersebut). Deskripsi use case harus dapat
memungkinkan para developer untuk mengidentifikasi kebutuhan elemen function dan
interface.
Actor
UseCase1
Usecase : Nama usecaseusercaseID : ID usecaseActor(s) : nama actor yang berinteraksi dengan sistemDescription : deskripsi cara actor dan sistem berinteraksi serta tanggungjawab sistem
Tabel 2.2 Initial Use Case Template(Armour dan Miller, 2001, p90)
Representasi use case dapat menggunakan base use case description yang
mengidentifikasi behavior yang spesifik dan interaksi yang terjadi antara actor dan
sistem di dalam batasan urutan kejadian (flow of events) dari use case (Armour dan
Miller, 2001, p107).
Use Case Name: <nama dari use case> Unique Use Case <identitas unik untuk use case> ID: Primary Actor(s): <nama dari primary actor atau actors yang berinteraksi dengan sistem> Secondary Actor(s): <nama dari secondary actor atau actors yang berinteraksi dengan sistem>
24
Brief Description: <deskripsi dari Use case> Preconditions: <state sistem ketika use case dipicu> Flow of Events <aktivitas-aktivitas dan interaksi-interaksi yang dilakukan ketika use case dilakukan> Postcondition: <state ketika use case meninggalkan sistem> Priority: <prioritas pengembangan use case yang relatif> Alternative flows <alternatif mayor atau pengecualian yang mungkin terjadi di and exceptions: dalam flow of events> Nonbehavioral <kebutuhan seperti pertunjukan, keamanan, dll> requirements: Assumptions: <asumsi-asumsi yang dibutuhkan> Issues: <isu-isu yang menonjol> Source: <rapat, wawancara, dokumen, dll yang merupakan asal dari use case>
Tabel 2.3 Base Use Case Description Template (Armour dan Miller, 2001, p110)
2. Function
Tujuan dari aktivitas ini adalah untuk menentukan kemampuan pemrosesan dari
suatu sistem sehingga menghasilkan suatu function list beserta spesifikasi untuk
function yang kompleks. Function memfokuskan pada apa yang bisa dilakukan oleh
sistem untuk membantu actor. Dengan kata lain, function merupakan fasilitas untuk
membuat sebuah model berguna bagi actor (Mathiassen et al, 2000, p138).
Menurut Mathiassen et al (2000, p138) terdapat empat tipe utama dari function,
dimana masing-masing tipe mengekspresikan hubungan antara model dan konteks
sistem. Keempat tipe tersebut antara lain update function, signal function, read function,
dan compute function.
Sumber untuk mengidentifikasi function berasal dari deskripsi Problem Domain,
yang diekspresikan oleh class dan events, dan juga dari deskripsi application Domain,
yang diekspresikan oleh use case. Tipe function yang berasal dari classes biasanya
25
adalah read dan update function. Sedangkan dari events adalah update function. Use
cases memungkinkan untuk semua tipe function (Mathiassen et al, 2000, p139-p144).
Pemahaman mengenai functions yang kompleks akan lebih jelas dengan adanya
detail spesifikasi baik dalam format mathematical expresison, algorithm in structured
language, maupun functional partitioning in the function list (Mathiassen et al, 2000,
p145).
3. Interface
Tujuan dari aktivitas ini adalah menentukan antar muka (interface) dari sistem yang
sedang dikembangkan. Interface adalah fasilitas yang membuat model sistem dan
function tersedia bagi actor (Mathiassen et al, 2000, p151). Adanya interface
memungkinkan actor untuk berinteraksi dengan sistem. Sumber aktivitas berasal dari
Class Diagram, Use cases, dan Function List.
Menurut Mathiassen et al (2000, p152) terdapat dua macam interface :
1. User Interface, menghubungkan human actor (manusia) dengan sistem. Dalam
merancang user interface dibutuhkan feedback dari user. Terdapat empat Usre
Interface Pattern, yaitu : menu selection (diekspresikan sebagai daftar pilihan
pada user interface), form filling (pola klasik untuk entri data), command
language (dibutuhkan daya ingat user untuk mengoperasikan sistem), dan direct
manipulation (memungkinkan manipulasi langsung dengan representasi objects)
(Mathiassen et al, 2000, p154-p155).
2. System Interface, menghubungkan system actor (sistem lain) dengan sistem yang
sedang di-develop. Sistem lain bisa berupa : external device (misal: sensor,
switch, dll) dan sistem komputer yang kompleks sehingga dibutuhkan suatu
protokol komunikasi. Biasanya interface ini tidak dipakai untuk sistem
26
administratif tetapi lebih sering untuk monitoring and controlling system
(Mathiassen et al, 2000, p163-p164).
Untuk menentukan elemen dari user interface dapat mengunakan object dan class
pada model serta functions. Elemen tersebut harus direpresentasikan dalam bentuk yang
mudah dipahami oleh user, seperti icon, fields, tables, diagrams, windows, button.
Sedangkan untuk kasus yang kompleks, dapat mengunakan Sequence Diagram untuk
merelasikan interaksi antara elemen interface dengan use case-nya. Sequence Diagram
mendeskripsikan langkah-langkah interaksi individual dan menghubungkannya dengan
window yang relevan. Diagram ini juga menggambarkan functions yang akan diaktivasi
selama interaksi terjadi (Mathiassen et al, 2000, pp156-158).
Deskripsi dari user interface dapat mengunakan Navigation Diagram, dimana
menyediakan gambaran keseluruhan dari elemen user interface dan transisi di antaranya.
Diagram ini terdiri dari gambar yang diperkecil di setiap window, panah yang
menunjukkan bagaimana mengunakan button dan seleksi lain yang akan mengaktivasi
function atau membuka window lain (Mathiassen et al, 2000, p159).
Untuk menggambarkan elemen-elemen user interface dalam prototype atau
menspesifikasikannya lebih detail dapat menggunakan Window Diagram. Diagram ini
mendeskripsikan tampilan dari single window yang mencakup bentuk detail dari elemen-
elemen window (Mathiassen et al, 2000, pp159-161 & p344).
2.1.11 Architectural Design
Pada tahap ini, akan dilakukan penstrukturan sistem berdasarkan bagian-
bagiannya dan pemenuhan beberapa criteria desain. Tahap ini juga merupakan suatu
framework bagi aktivitas pengembangan selanjutnya. Aktivitas architectural design
bertujuan untuk menstrukturkan suatu sistem yang terkomputerisasi. Hasil yang
27
diperoleh berupa struktur dari komponen – komponen dan proses – proses sistem. Tahap
Architectural Design memiliki tiga subaktivitas yaitu (Mathiassen et al, 2000, p173). :
CriteriaComponent
Architecture
ProcessArchitecture
AnalysisDocument
ArchitecturalSpesification
Gambar 2.13 Aktivitas dalam Architectural Design(Mathiassen et al, 2000, p176)
1. Criteria
Criteria adalah suatu prioritas dari arsitektur (Mathiassen et al, 2000, p176). Tujuan
aktivitas criteria adalah untuk menentukan prioritas desain. Hasil yang diperoleh dari
tahap ini adalah kumpulan criteria untuk desain yang telah diprioritaskan.
CRITERIA PENGUKURAN DARI
Usable Kemampuan adaptasi sistem tehadap konteks organisasi, hubungan kerja dan teknikal Secure Suatu pencegahan melawan akses yang tidak terotorisasi terhadap fasilitas-fasilitas yang ada Efficient Penggunaan yang ekonomis terhadap fasilitas technical platform Correct Pemenuhan terhadap persyaratan-persyaratan Reliable Pemenuhan terhadap eksekusi function yang benar-benar tepat Maintainable Besarnya usaha untuk melokasikan dan memperbaiki kecacatan sistem
Testable Besarnya usaha untuk memastikan bahwa sistem menampilkan
28
fungsi-fungsi yang telah ditentukan Flexible Besarnya usaha untuk memodifikasi sistem Comprehensible Usaha yang dibutuhkan untuk mendapatkan pengertian yang masuk akal terhadap sistem Reusable Potensi penggunaan bagian-bagian sistem dalam sistem lain yang terhubung Portable Besarnya usaha untuk memindahkan sistem ke technical platform Interoperable Besarnya usaha untuk menggabungkan suatu sistem ke sistem lain
Tabel 2.4 Criteria klasik untuk mengukur kualitas software (Mathiassen et al, 2000, p178)
2. Components
Component Architecture adalah sebuah struktur sistem yang terdiri dari komponen -
komponen yang saling terhubung. Component adalah kumpulan dari bagian - bagian
program yang membentuk sistem dan memiliki tanggung jawab yang telah
terdefinisikan dengan jelas (Mathiassen et al, 2000, p190).
Menurut Mathiassen et al (2000, pp193 – 198), terdapat beberapa pola umum yang
dapat digunakan untuk mendesain suatu component architectrure yaitu :
The Layered Architecture Pattern
Arsitektur ini terdiri dari beberapa components yang didesain sebagai layers. Desain
dari setiap component menggambarkan tanggung jawabnya masing-masing serta
interface bagian atas maupun bagian bawah. Interface bagian atas akan menggambarkan
operasi yang tersedia untuk layer dibawahnya.
The Generic Architecture Pattern
Model Component merupakan dari sistem object yang diletakkan pada layer yang
paling bawah, kemudian diikuti dengan layer sistem function, dan yang paling atas
29
merupakan component interface. Layer interface dapat dibagi menjadi dua bagian
yaitu user interface dan system interface.
Gambar 2.14 The Generic Architecture Pattern
(Mathiasen et al, 2000, p196)
The Client Server Architecture Pattern
Komponen dari arsitektur sebuah server dan beberapa clients. Server memiliki
kumpulan operasi yang tersedia bagi client. Server bertanggung jawab untuk
menyediakan hal – hal yang umum bagi client-nya, seperti database atau sumber daya
lain yang bisa digunakan bersama. Server menyediakan operasinya bagi client melalui
suatu jaringan. Client bertanggung jawab untuk menyediakan interface lokal bagi para
user (Mathiassen et al, 2000, p197).
«component» Interface
«component» Technical platform
«component» Function
«component» Model
«component» User Interface
«component» System Interface
«component» UIS
«component» DBS
«component» NS
30
Gambar 2.15 The Client – Server Architecture Pattern
(Mathiassen et al, 2000, p197)
3. Process
Tahap ini menentukan bagaimana suatu proses sistem didistribusi dan
dikoordinasikan. Tujuan dari tahap ini adalah untuk mendefinisikan struktur fisikal dari
suatu sistem. Hasil yang akan diperoleh berupa sebuah deployment digram. Processor
adalah suatu bagian peralatan yang dapat mengeksekusi sebuah program(Mathiassen et
al, 2000, pp211 – 212).
Deployment Diagram, menggambarkan unit - unit teknologi (khususnya perangkat
keras seperti processor dan penyimpanan besar, beserta hubungan komunikasi fisiknya)
dimana sistem akan diimplementasi. Deployment Diagram juga dapat memodelkan
bagaimana perangkat keras akn didistribusikan di antara unit –unit teknologi terpilih,
dengan cara menambahkan komponen perangkat lunak dan hubungannya, ke dalam
deployment diagram yang menggambarkan teknologi fisikal asli (Jones, 2000, p202).
«component» Client1
«component»Client2
«component»Clientn
«component»Server
31
<<Processor>>Node 1
Component1
Component2
<<Device>>Node 2
Depedency
Gambar 2.16 Deployment Diagram
(Schmuller, 1999, p383)
2.1.12 Component Design
Tujuannya adalah untuk menentukan implementasi dari kebutuhan di dalam
kerangka arsitektur. Yang menjadi titik awal dari tahap ini adalah architectural
specification dan system requirement yang akan menghasilkan connected component
specification. Menurut Mathiassen et al (2000, p232), terdapat dua subaktivitas dalam
component design, yaitu :
32
Gambar 2.17 Subaktivitas dalam Component Design
(Mathiassen et al, 2000, p232)
2.1.12.1 Design of Components
Merupakan tahapan untuk merancang komponen sistem, yaitu :
2.1.12.1.1 Model Component
Model Component adalah bagian dari sistem yang mengimplementasi model
problem domain (Mathiassen et al, 2000, p236). Tujuan dari model component
design adalah untuk menggambarkan model dari problem domain. Model tersebut
merupakan hasil dari kegiatan ini yang digambarkan oleh class diagram yang telah
direvisi dari hasil kegiatan analisis.
Revisi class diagram dapat dilakukan dengan memperhatikan private events dan
common events. Private events adalah event yang melibatkan hanya satu object
domain (Mathiassen et al, 2000, p239).
Design of components
Design of Components Connections
Architecture Specification
Component Specification
33
Representasikan event-event ini sebagai state attribute
Event-event yang pada class yang dijabarkan oleh statechart diagram. hanya terjadi pada Setiap kali ada kejadian yang melibatkan salah satu Urutan/sequence event tersebut, maka sistem akan menugaskan dan selection yang baru kepada state attribute Integrasikan attribute dari event yang terlibat ke dalam class Representasikan event-event ini sebagai suatu class
baru, dan hubungkan class tersebut dengan class yang
Event-event yang dijabarkan pada statechart diagram dengan terjadi berulang- menggunakan struktur aggregation. Untuk setiap ulang (iteration) iterasi, sistem akan menghasilkan suatu object baru
Integrasikan attribute event ke dalam class yang baru
Tabel 2.5 Guidelines atau panduan dalam merepresentasikan private events
(Mathiassen et al, 2000, p241)
Jika suatu event adalah common /umum sehingga mempengaruhi beberapa
object, maka event tersebut perlu dihubungkan dengan salah satu object dan dibuat
hubungan struktural dengan object lain agar tetap dapat mengaksesnya.
Jika event yang terlibat dalam statechart diagram dalam cara yang berbeda, representasikan event tersebut dalam hubungan Common ke class yang menawarkan representasi paling simple. Event Jika event yang terlibat dalam statechart diagram dalam cara yang sama, pertimbangkan alternatif representasi yang mungkin dapat digunakan
Tabel 2.6 Guidelines untuk merepresentasikan common events (Mathiassen et al, 2000, p241)
Untuk menyederhanakan class diagram yang telah direvisi dari hasil tahapan
sebelumnya, dilakukan restrukturisasi class baik melalui generalization, association,
maupun embedded iteration.
34
2.1.12.1.2 Function Component
Function component adalah bagian sistem yang mengimplementasikan
kebutuhan fungsional (Mathiassen et al, 2000, p252). Tujuannya adalah agar user
interface dan komponen – komponen sistem lainnya dapat mengakses model.
Sedangkan tujuan dari function component design adalah menentukan implementasi
functions. Hasil dari kegiatan ini adalah class diagram dengan operations dan
spesifikasi dari operations yang komlpleks.
Langkah pertama yang harus dilakukan adalah mendesain functions sebagai
operations, yaitu mengidentifikasi tipe utama dari functions tersebut. Ada empat tipe
functions (Mathiassen et al, 2000, pp255-260), yaitu : Update, Read, Compute, dan
Signal.
Patterns (pola) dapat membantu memilih functional design yang mana dapat
digunakan dari beberapa pilihan yang dapat membantu merealisasikan functions
sebagai sekumpulan operations. Empat pola menurut Mathiassen et al (2000, pp260-
264) adalah :
a. Model Class Plecement.
Pola ini menempatkan operation dalam model component class dan berguna
ketika sebuah operation mengakses hanya sebuah single object atau struktur
aggregation yang sederhana. Pola ini juga dapat digunakan ketika beberapa object
terlibat namun hanya jika tanggung jawab operation tersebut dapat dengan jelas
ditempatkan pada salah satu dari model class.
b. Function Class Placement
35
Pola ini digunakan ketika tanggung jawab operation tidak dapat dengan jelas
ditempatkan dalam model class. Sebaliknya satu atau lebih functional-component
class dapat digambarkan dengan menempatkan operation yang merealisasikan
function.
c. Strategy
Pola ini digunakan untuk mendefinisikan sekumpulan operations yang umum
terenkapsulasi dan dapat dipertukarkan.
d. Active Function.
Active signal function dapat direalisasikan sebagai operation yang secara
permanen aktif dan berkala memberikan sinyal kepada interface. Active function
ditempatkan sebagai active object dan performance-nya tergantung dari state pada
model component.
Apabila terdapat operation yang kompleks harus dideskripsikan dengan lebih
detail lagi sehingga di dalam desain tidak ada ketidakpastian yang penting. Menurut
Mathiassen et al (2000, pp265-266) ada 3 (tiga) cara untuk melakukannya, yaitu
operation specification, sequence diagram, dan statechart diagram.
2.1.12.2 Connecting Components
Tujuan dari aktivitas ini adalah menghubungkan komponen-komponen sistem
yang akan menghasilkan class diagram dari komponen-komponen tersebut. Jadi pada
aktivitas ini, hubungan antara komponen-komponen dirancang untuk mendapatkan
desain yang fleksibel dan comperehensible. Untuk itu dibutuhkan evaluasi dari coupling
dan cohesion.
Coupling adalah ukuran tentang seberapa dekat dua classes atau components
dihubungkan (Mathiassen et al, 2000, p272). Cohesion adalah ukuran tentang seberapa
36
baik sebuah class atau component terikat bersama (Mathiassen et al,2000, p273).
Prinsipnya adalah: “highly cohesive classes and loosely coupled components”.
Hasil dari aktivitas connecting components ini adalah class diagram yang dimana
dependencies-nya berubah menjadi connections. Tiga bentuk connections menurut
Mathiassen et al (2000, p275, p281) adalah:
• Class aggregation, yaitu mengagregasikan class-class dari component lain. Koneksi
ini berguna ketika class definition sudah ada di dalam component lain. Umumnya
coupling-nya rendah, namun sulit mencapai cohesive.
Contoh :
<<component>>Function
<<component>>Model
AccountManagement
Account
1
1..*
Gambar 2.18 Koneksi oleh class agregation
(Mathiassen et al, 2000, p275)
• Class specialization, yaitu menspesialisasikan public class dari component lain.
Contoh :
37
<<component>>User Interface
<<component>>UI Library
PersonW SessionW
Window
Gambar 2.19 Koneksi oleh class specialization
(Mathiassen et al, 2000, p276)
• Operation call, yaitu memanggil public operations di dalam object-object dari
component lain. Umumnya coupling-nya rendah dan cohesion-nya tinggi.
Contoh :
<<component>>Model
<<component>>System Interface
Engine
throttle positionthrottle setting
position
Throttle
read<<call>>
Gambar 2.20 Koneksi dalam memanggil sebuah operasi
(Mathiassen et al, 2000, p277)
38
2.2 Teori Khusus
2.2.1 Definisi Pembelian
Definisi pembelian menurut Mulyadi (1997, p301) adalah pengadaan barang yang
diperlukan perusahaan.
Pembelian merupakan salah satu fungsi yang penting dalam berhasilnya operasi
suatu perusahaan yang di bebani tanggung jawab untuk mendapatkan kuantitas dan
kualitas bahan – bahan yang tersedia pada waktu dibutuhkan dengan harga yang sesuai
dengan harga yang berlaku (Assauri, 1993, p205).
Secara umum pembelian dapat didefinisikan sebagai usaha pengadaan barang atau
jasa dengan tujuan untuk mendapatkan kuantitas dan kualitas bahan – bahan yang
tersedia pada waktu dibutuhkan dengan harga yang sesuai, untuk kepentingan proses
produksi maupun untuk dijual kembali.
Jenis transaksi pembelian dapat digolongkan menjadi 2 (dua) menurut Mulyadi
(1997, p301), yaitu :
1. Pembelian Lokal
Pembelian lokal merupakan pembelian dari pemasok dalam negeri
2. Pembelian Impor
Pembelian Impor merupakan pembelian dari pemasok luar negeri
2.2.2 Tugas dan Tanggung Jawab Fungsi Pembelian
Menurut Hammer dan Usry yang diterjemahkan oleh Sirait, A (1996), tugas dan
fungsi pembelian adalah sebagai berikut :
1. Menerima surat permintaan pembelian untuk bahan, perlengkapan dan peralatan.
2. Mencari informasi tentang sumber- sumber pasokan, harga, pengiriman dan jadwal
penyerahan.
39
3. Menyiapkan dan mengirimkan surat order pembelian.
4. Menyusun laporan yang memadai dan sistematik antara departemen pembelian,
penerimaan dan akuntansi.
Mulyadi (1997, p302) menyebutkan bahwa tanggung jawab dan fungsi pembelian
adalah untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang
dipilih dalam pengadaan barang dan mengeluarkan order pembelian kepada pemasok
yang dipilih.
2.2.3 Fungsi yang terkait dalam Sistem Pembelian
Menurut Mulyadi (1997, p302) fungsi yang terkait dalam sistem pembelian adalah
sebagai berikut :
1. Fungsi Gudang, yang bertanggung jawab untuk mengajukan permintaan pembelian
sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang
yang telah diterima oleh fungsi penerimaan.
2. Fungsi Pembelian, bertanggung jawab untuk memperoleh informasi mengenai harga
barang, menentukan pemasok yang dipilih dalam pengadaan berang, dan
mengeluarkan order pembelian kepada pemasok yang dipilih.
3. Fungsi Penerimaan, bertanggung jawab untuk melakukan pemeriksaan terhadap
jenis, mutu, dan kuantitas barang yang diterima dari pemasok guna menentukan
dapat atau tidaknya barang tersebut diterima perusahaan.
4. Fungsi Akuntansi, ini berkaitan dengan transaksi pembelian adalah fungsi pencatatan
hutang yang bertanggung jawab untuk mencatat transaksi pembelian ke register
bukti kas keluar dan untuk menyelenggarakan arsip dokumen sumber bukti kas
keluar dan untuk menyelenggarakan arsip dokumen sumber bukti kas keluar yang
40
berfungsi sebagai catatan hutang atau menyelenggarakan kartu hutang sebagai buku
pembantu hutang.
2.2.4 Prosedur Pembelian yang Lazim
Mengacu pada pendapat Mulyadi (1997, p322-p324), prosedur pembelian yang
lazim diterapkan oleh perusahaan diuraikan sebagai berikut :
1. Jika persediaan sudah mencapai titik pemesanan kembali (reorder point), maka
Bagian Gudang membuat Surat Permintaan Pembelian 2 (dua) rangkap yang
didistribusikan kepada :
a. Rangkap ke-1 didistribusikan kepada Bagian Pembelian
b. Rangkap ke-2 di simpan oleh Bagian Gudang sebagai arsip
2. Berdasar Surat Permintaan Pembelian dari Bagian Gudang, Bagian Pembelian
membuat Surat Permintaan Penawaran Harga yang ditujukan kepada berbagai
pemasok, untuk memeperoleh informasi mengenai harga barang dan berbagai syarat
pembelian yang lain.
3. Bagian Pembelian menerima Surat Penawaran Harga dari berbagai pemasok, Bagian
Pembelian menyeleksi pemasok berdasarkan penawaran harga yang paling
menguntungkan.
4. Bagian Pembelian membuat Surat Order Pembelian (SOP) 5 (lima) rangkap yang
akan didistribusikan kepada :
a. Rangkap ke-1 diberikan kepada pemasok yang dipilih, sebagai order pembelian
resmi yang dikeluarkan oleh perusahaan.
b. Rangkap ke-2 didistribusikan kepada Bagian Gudang sebagai bukti bahwa
barang yang dimintanya telah dipesan.
41
c. Rangkap ke-3 didistribusikan kepada Bagian Penerimaan sebagai otorisasi untuk
menerima barang yang jenis, spesifikasi, mutu, kuantitas dan pemasoknya seperti
yang tercantum dalam dokumen tersebut.
d. Rangkap ke- 4 didistribusikan kepada Bagian Akuntasi sebagai salah satu
dokumen dasar yang akan digunakan untuk mencatat transaksi pembelian
tersebut ke dalam catatan akuntansi yang terkait.
e. Rangkap ke-5 disimpan oleh Bagian Pembelian menurut nama pemasok, sebagai
dasar untuk mencari informasi mengenai pemasok, apabila diperlukan
dikemudian hari.
5. Pemasok mengirimkan barang kepada perusahaan dan diterima oleh Bagian
Penerimaan. Bagian Penerimaan melakukan pemeriksaan terhadap jenis, spesifikasi,
mutu, dan kuantitas barang yang diterima dari pemasok dan mencocokkannya
dengan yang tercantum dalam Surat Order Pembelian guna menentukan dapat atau
tidaknya barang tersebut diterima oleh perusahaan, maka Bagian Penerimaan
membuat Laporan Penerimaan Barang (LPB) 4 (empat) rangkap, yang akan
didistribusikan kepada :
a. Rangkap ke-1 didistribusikan kepada Bagian Pembelian
b. Rangkap ke-2 didistribusikan kepada Bagian Gudang beserta barang.
c. Rangkap ke-3 didistribusikan kepada Bagian Akuntansi
d. Rangkap ke-4 disimpan oleh Bagian Penerimaan sebagai arsip.
Jika barang tidak sesuai dengan keinginan perusahaan, maka barang tersebut akan
dikembalikan kepada supplier.
42
6. Bagian Gudang melakukan penyimpanan barang dan mencocokkan SOP dengan
LPB, lalu mencatat kuantitas barang yang diterima kedalam Kartu Gudang,
kemudian mengarsipkan kedua dokumen tersebut.
7. Bagian Pembelian menerima faktur dari pemasok dan memeriksa faktur tersebut,
kemudian mengirimkan faktut kepada Bagian Akuntansi.
8. Bagian Akuntansi mencocokkan faktur dengan SOP dan LPB. Jika telah sesuai,
Bagian Akuntansi mencatat transaksi pembelian tersebut kedalam Jurnal Pembelian
dan Kartu Utang, serta mencatat harga pokok persediaan barang yang dibeli ke
dalam kartu persediaan. Faktur dari pemasok diarsipkan sementara menurut tanggal
jatuh tempo pembayaran, untuk digunakan kembali dan diproses dalam transaksi
pembayaran faktur pada saat jatuh tempo, sedangkan SOP dan LPB diarsipkan
menurut nomor atau tanggal dokumen tersebut dibuat.
Dari prosedur pembelian diatas, dapat disimpulkan bahwa terdapat praktik yang
sehat antara lain meliputi sebagai berikut :
a. Bagian gudang mengajukan Surat Permintaan Pembelian hanya jika tingkat
persediaan di gudang telah mencapai titik pemesanan kembali.
b. Bagian pembelian melakukan pembelian hanya berdasarkan SPP.
c. Pemasok dipilih berdasarkan perbandingan penawaran harga bersaing dari berbagai
pemasok, tidak berdasarkan hubungan istimewa dan pribadi diantara Bagian
Pembelian dengan pemasok. Dengan cara ini, kemungkian pengadaan barang yang
lebih tinggi dari harga yang normal dapat dihindari.
d. Barang hanya diterima dan diperiksa oleh Bagian Penerimaan, jika bagian itu telah
menerima tembusan SOP dari Bagian Pembelian.
43
e. Bagian Penerimaan melakukan pemeriksaan barang yang diterima dari pemasok
dengan cara menghitung dan menginspeksi barang tersebut dan membandingkannya
dengan tembusan Surat Order Pembelian.
f. Pembayaran faktur dilakukan sesuai dengan syarat pembayaran guna mencegah
hilangnya kesempatan untuk memperoleh potongan tunai. Jika perusahaan
memperoleh potongan tunai dari pemasok karena melunasi kewajibannya dalam
jangka waktu potongan( cash discount period ) berarti dapat menghemat kekayaan
perusahaan.
2.2.5 Pengertian Persediaan
Persediaan dalam suatu perusahaan adalah faktor pendukung penting dalam
menjalankan operasi perusahaan. Berikut beberapa pendapat para ahli tentang
persediaan :
• Persediaan merupakan sejumlah bahan-bahan yang disediakan dan bahan-bahan
dalam proses yang terdapat dalam perusahaan untuk proses produksi, serta barang -
barang jadi/produksi yang disediakan untuk memenuhi permintaan dari konsumen
atau langganan setiap waktu (Assouri 1993, p219).
• Persediaan menunjukkan barang yang dimiliki untuk dijual dalam kegiatan normal
perusahaan (Handoko, 1994,p333-334). Pada umumnya persediaan barang dagangan
diterapkan untuk barang-barang yang dimiliki oleh perusahaan dagang apabila
perusahaan tersebut diperoleh dalam keadaan siap untuk dijual kembali. Sedangkan
persediaan barang produksi termasuk barang dari hasil produksi perusahaan itu yang
belum didistribusikan ke konsumen.
44
Dari definisi persediaan tersebut maka dapat disimpulkan bahwa persediaan adalah
aset yang sangat penting karena persediaan merupakan barang yang tersedia untuk dijual
(barang dagangan/barang jadi), barang yang masih dalam proses produksi untuk
diselesaikan dan dijual(barang dalam proses pengolahan) dan barang yang akan
dipergunakan untuk produksi barang jadi yang akan dijual (bahan baku dan bahan
pembantu) dalam kegiatan usaha normal perusahaan.
2.4.6. Perencanaan Persediaan
Persediaan mempermudah atau memperlancar jalannya operasi perusahaan pabrik
yang harus dilakukan secara berturut-turut untuk memprodusir barang-barang serta
selanjutnya menyampaikannya pada langganan atau konsumen (Assouri, 1993, p177).
Persediaan dikatakan sangat penting bagi perusahaan karena persediaan berguna untuk :
a. Menghilangkan resiko datangnya keterlambatan barang
b. Menghilangkan resiko dari produk yang dipesan tidak bagus atau rusak
c. Untuk menumpuk bahan-bahan yang dihasilkan secara minimum sehingga dapat
dipergunakan bila barang tersebut tidak ada dalam pasaran
d. Mempertahankan stabilitas operasi perusahaan atau menjamin kelancaran arus
produksi
e. Mencapai penggunaan mesin yang optimal
f. Memberikan pelayanan kepada pelanggan dengan sebaik-baiknya dimana keinginan
langganan pada setiap waktu dapat terpenuhi atau memberi jaminan tetap
tersedianya barang tersebut
g. Membuat pengadaan atau produksi tidak perlu sesuai dengan penggunaan atau
penjualannya
45
2.4.7. Pengendalian Internal Atas Persediaan
Pengendalian Internal Atas Persediaan merupakan hal yang sangat penting karena
persediaan adalah bagian yang amat penting dari suatu perusahaan dagang. Menurut
Render dan Heizer (2001, p318) elemen yang harus ada untuk mendukung pengendalian
internal yang baik atas persediaan adalah :
1. Pemilihan karyawan,pelatihan, dan disiplin yang baik. Hal-hal ini tidak pernah
mudah dilakukan, tetapi sangat penting dalam bisnis makanan, perdagangan besar,
dan operasi bisnis eceran di mana karyawannya mempunyai akses kepada barang-
barang yang langsung dikonsumsi.
2. Pengendalian yang ketat atas barang yang datang. Melalui sistem kode batang (bar
code)
3. Pengendalian yang efektif atas semua barang yang ke luar dari fasilitas.
2.4.8. Metode Pencatatan Persediaan
Ada dua sistem yang dikenal dalam menentukan jumlah persediaan pada akhir
suatu periode menurut Mulyadi (1997, p558), yaitu dengan :
1. Metode Mutasi Persediaan
Dalam metode mutasi persediaan, setiap mutasi persediaan dicatat dalam kartu
persediaan
2. Metode Persediaan Fisik
Dalam Metode Persediaan Fisik, hanya tambahan persediaan dari pembelian saja
yang dicatat, sedangkan mutasi berkurangnya persediaan karena pemakaian tidak
dicatat dalam kartu persediaan
46
2.4.9. Metode Penilaian Persediaan
Dalam menilai persediaan metode yang digunakan (Soemarso, 1995, p424), adalah
sebagai berikut :
1. Metode LIFO
LIFO adalah metode penetapan harga pokok persediaan dimana dianggap bahwa
barang-barang yang paling akhir dibeli dan merupakan barang yang dijual pertama
kali. Dalam metode ini persediaan akhir akan dinilai dengan harga pokok pembelian
terdahulu.
2. Metode FIFO
LIFO adalah metode penetapan harga pokok persediaan dimana dianggap bahwa
barang-barang yang pertama dibeli akan merupakan barang yang dijual pertama kali.
Dalam metode ini persediaan akhir akan dinilai dengan harga pokok pembelian yang
paling akhir.
3. Metode Rata-rata (Average)
Rata-rata dalam penetapan harga pokok persediaan dimana dianggap bahwa harga
pokok rata-rata dari barang yang tersedia dijual akan digunakan untuk menilai harga
pokok barang yang dijual dan yang terdapat dalam persediaan.
2.3.10 Manajemen Persediaan
Menurut Handoko (2001, p334) sistem Persediaan adalah serangkaian
kebijaksanaan dan pengendalian yang memonitor tingkat persediaan yang bertujuan
untuk meminimumkan biaya total. Menurut jenisnya dapat dibedakan menjadi :
1. Persediaan bahan mentah, yaitu persediaan barang berujud yang digunakan dalam
proses produksi
47
2. Persediaan komponen-komponen rakitan, yaitu persediaan barang-barang yang
terdiri dari komponen-komponen yang diperoleh dari perusahaan lain, dimana secara
langsung dapat dirakit menjadi suatu produk
3. Persediaan bahan pembantu atau penolong, yaitu persediaan barang-barang yang
diperlukan dalam proses produksi, tetapi tidak merupakan bagian barang jadi
4. Persediaan barang dalam proses, yaitu persediaan barang-barang yang merupakan
keluaran dari tiap-tiap bagian dalamproses produksi atau yang diolah menjadi suatu
bentuk
5. Persediaan barang jadi, yaitu persediaan barang-barang yang telah selesai
diprosesatau diolah
2.3.11 Lead Time, Safety Stock, Reorder Point, EOQ dan Minimum Stock
a. Lead Time
Beberapa definisi lead time :
• Render dan Heizer (2001,p324), lead time adalah waktu antara dilakukannya
pemesanan
• Handoko (2001, p341), lead time adalah waktu antara pesanan dilakukan dan
barang-barang diterima, adalah konstan
Berdasarkan definisi di atas maka dapat ditarik kesimpulan bahwa lead time
merupakan waktu yang dihitung sejak satu pesanan pembelian pada suplier dilakukan
sampai saat barang tersebut diterima oleh pembeli
b. Safety Stock
48
Untuk menghadapi permintaan yang bervariasi perusahaan biasanya mempunyai
tingkat persediaan tertentu sebagai pengaman yang disebut safety atau buffer stocks.
Safety stock ini menyediakan sejumlah persediaan selama lead time, Handoko(2001,
p355).
c. ROP
Definisi Re-order Point, antara lain :
• Render dan Heizer (2001, p324), ROP adalah saat persediaan mencapai nol
sebelum perusahaan memesaan lagi dan dengan seketika barang yang dipesan
diterima
• Weston dan Brigham (1990,p511), ROP adalah suatu titik dimana pemesanan
harus dilakukan lagi untuk fungsi persediaan. Titik pemesanan kembali ini
menunjukkan kepada bagian pembelian untuk melakukan pemesanan kembali
untuk menggantikan persediaan yang telah digunakan.
Perhitungan ROP menggunakan rumus :
ROP = d x L
ROP = Titik Pemesanan Ulang
d = Permintaan per hari
L = Lead Time, waktu pengiriman
Jadi dapat disimpulkan bahwa ROP adalah kuantitas dimana persediaan harus
ditambahkan untuk menandai pemesanan ulang
49
d. EOQ
Menurut Render dan Heizer (2001, p320), EOQ merupakan salah satu teknik
pengendalian tertua dan paling terkenal. Teknik ini relatif mudah digunakan,
tapi didasarkan pada beberapa asumsi:
1. Tingkat permintaan diketahui dan bersifat konstan
2. Lead Time, diketahui dan bersifat konstan
3. Persediaan diterima dengan segera
4. Tidak mungkin diberi diskon
5. Biaya variabel yang muncul hanya biaya pemasangan atau pemesanan dan
biaya penahanan atau penyimpanan sepanjang waktu
6. Keadaan kehabisan stok (kekurangan) dapat dihindari sama sekali bila
pemesanan dilakukan pada waktu yang tepat
Perhitungan EOQ menggunakan rumus :
EOQ = √ 2 DS H
EOQ = Jumlah Optimal Pemesanan Barang
D = Permintaan Tahunan Barang Persediaan, dalam unit
S = Biaya Pemesanan untuk setiap Pesanan
H = Biaya Penyimpanan per unit per tahun
50
Berdasarkan pengertian EOQ yang telah dibahas diatas maka EOQ dapat
diartikan sebagai konsep yang penting dalam pembelian bahan mentah dan
penyimpanan barang jadi
e. Minimum Stock
Persediaan Minimum merupakan batas persediaan yang paling kecil yang harus
ada untuk suatu jenis barang oleh karena itu, persediaan minimum ini
dimasukkan untuk menghindari kemungkinan kekurangan persediaan, maksud
persediaan minimum merupakan persediaan cadangan untuk menjamin
keselamatan operasi atau kelancaran produksi perusahaan yang karena itu
persediaan ini sering disebut persediaan pengaman jadi persediaan minimum
dalam suatu perusahaan hendaknya sama dengan besarnya persediaan
pengaman.
