|
BAB 2
LANDASAN TEORI
2.1
Sistem Informasi Akuntansi
2.1.1 Pengertian Sistem informasi Akuntansi
Menurut
Bodnar,
Hopwood
(2001,
p1),
sistem informasi
akuntansi
adalah
kumpulan sumber daya, seperti manusia dan peralatan yang diatur untuk mengolah
data menjadi informasi. Sedangkan menurut Jones dan Rama (2006, p4),
"Accounting information system is subsystems from management information
systems that provides accounting and financial information as well as other
information obtained in the routine processing of accounting transactions". Dapat
diterjemahkan sistem informasi akuntansi adalah subsistem dari sistem
informasi
manajemen
yang
menyediakan
informasi
akuntansi
dan
finansial
juga
informasi
lain yang diperoleh dari pemrosesan rutin transaksi akuntansi.
Adapun
menurut
Romney
dan
Steinbart
(2006,
p6),
sistem
informasi
akuntansi
adalah
suatu
sistem yang
mengumpulkan,
merecord,
menyimpan
dan
memproses data untuk menghasilkan informasi bagi pembuat keputusan. Dan
menurut
Mcleod
(2001,
p.4),
sistem
informasi
akuntansi
adalah
sistem yang
bertugas
untuk
mengumpulkan
data
yang menjelaskan
kegiatan
perusahaan,
mengubah data tersebut menjadi informasi, serta menyediakan informasi bagi
pemakai di dalam maupun di luar perusahaan.
Dari
definisi-definisi
tersebut
dapat
diketahui
bahwa
sistem informasi
akuntansi merupakan sekumpulan sumber daya yang saling berkerja sama dengan
|
|
9
tujuan menghasilkan informasi khususnya yang berhubungan dengan transaksi
keuangan yang terjadi pada suatu perusahaan untuk berbagai kepentingan.
2.1.2 Tujuan dan Kegunaan Sistem Informasi Akuntansi
Menurut Romney dan Steinbart (2006, p7), kerjasama dari keenam
komponen
sistem informasi
sebagaimana
yang
telah
disebutkan
diatas
memungkinkan sistem
informasi akuntansi
untuk memenuhi 3
fungsi bisnis yang
penting yaitu:
1)
Mengumpulkan dan
menyimpan
data
mengenai aktivitas organisasi, sumber
daya dan personel.
2) Mengubah data menjadi informasi yang berguna untuk pengambilan keputusan
sehingga manajemen dapat merencanakan, melaksanakan, mengendalikan, dan
mengevaluasi aktivitas, sumber daya, dan personel.
3)
Menyediakan pengendalian yang memadai untuk melindungi aset organisasi,
termasuk
datanya,
untuk
menjamin
bahwa aset dan data tersedia ketika
dibutuhkan dan datanya akurat dan dapat diandalkan.
Selain itu Romney dan Steinbart (2006, p12) juga mengemukakan bahwa
sebuah sistem
informasi akuntansi
yang
dirancang
dengan baik
dapat
melakukan
hal – hal berikut ini :
1) Meningkatkan kualitas dan menurunkan biaya dari barang dan jasa.
2) Meningkatkan efisiensi.
3) Berbagi pengetahuan.
4) Meningkatkan efisiensi dan efektivitas dari supply chainnya.
|
|
10
5) Meningkatkan struktur pengendalian internal
6) Meningkatkan pembuatan keputusan.
Menurut pendapat Wilkinson et al. (2000, p8),
tujuan dan kegunaan sistem
informasi akuntansi adalah :
1) Mendukung operasional sehari-hari.
2) Mendukung pengambilan keputusan bagi pengambil keputusan internal.
3) Untuk memenuhi kewajiban atau tanggung jawab yang sesuai dengan
jabatannya
Menurut Wilkinson et al. (2000, p8), suatu sistem informasi akuntansi yang
efektif melakukan beberapa fungsi kunci sebagai berikut:
1) Pengumpulan data
Fungsi pengumpulan data (yang dilakukan selama
tahapan input)
melibatkan beberapa langkah seperti mengambil
data
transaksi,
mencatat
data
tersebut
kedalam formulir,
menvalidasi
dan
mengedit
data
untuk
menjamin
keakuratan dan kelengkapannya.
2) Pemeliharaan data
Fungsi pemeliharaan data (yang dilakukan selama tahap pemrosesan)
melibatkan langkah-langkah sebagai berikut:
o
Mengklasifikasi, atau
menempatkan data
yang telah dikumpulkan ke dalam
kategori preestablished.
o
Mentranskrip, atau mengcopy atau mereproduksi data menjadi dokumen atau
media lain.
|
|
11
o
Mengurutkan, atau mengatur elemen data berdasarkan
satu atau lebih
karakteristik.
o
Batching, menjadikan satu
sekelompok transaksi
yang
memiliki
sifat
yang
sama.
o
Merging, atau mengkombinasikan dua atau
lebih batches atau file- file dari
data.
o
Mengkalkulasi,
atau
melakukan
operasi
penjumlahan,
pengurangan,
perkalian, dan pembagian.
o
Meringkas, atau mengumpulkan elemen data kuantitatif.
o
Membandingkan, atau
memeriksa
item dari batches atau file
yang terpisah
untuk menemukan yang sesuai atau untuk menentukan perbedaannya.
3) Manajemen data
Fungsi manajemen data terdiri dari 3 tahapan yaitu:
o
Storing (menyimpan)
Melibatkan
menempatkan
data
dalam penyimpanan yang disebut files ato
database.
Data
harus
sering
disimpan
untuk referensi
di
masa
yang
akan
datang; selain
itu data yang telah diproses menjadi informasi mungkin akan
disimpan sementara sampai dibutuhkan oleh user.
o
Maintaining (memelihara)
Melibatkan mengatur data yang disimpan untuk merefleksikan event, operasi,
atau keputusan yang baru terjadi.
|
|
12
o
Retrieving (menggunakan)
Terdiri dari
mengakses dan
mengekstrak data, baik
untuk pemrosesan lebih
lanjut atau untuk pelaporan kepada user.
4) Pengendalian data
Fungsi pengendalian data mempunyai 2 tujuan dasar:
o
Untuk melindungi dan mengamankan aset perusahaan, termasuk data.
o
Untuk
menjamin
bahwa
data
yang diambil
adalah
akurat dan
lengkap
dan
diproses dengan benar.
5) Menghasilkan informasi
Fungsi menghasilkan informasi melibatkan langkah-langkah seperti
mengintepretasikan, melaporkan, dan mengkomunikasikan informasi.
2.1.3 Komponen Sistem Informasi Akuntansi
Menurut Romney dan Steinbart (2006, p6), terdapat 6 komponen dari sistem
informasi akuntansi, yaitu:
1) Orang yang mengoperasilkan sistem dan melakukan berbagai macam fungsi.
2)
Prosedur
dan
instruksi,
baik
manual maupun otomatis. Dilibatkan dalam
pengumpulan, pemrosesan, dan penyimpanan data mengenai aktivitas
organisasi.
3) Data tentang organisasi dan proses bisnisnya.
4) Software yang digunakan untuk memproses data organisasi.
|
|
13
5) Infrastruktur
teknologi
informasi,
termasuk
komputer,
peralatan
disekelilingnya, dan peralatan komunikasi jaringan yang digunakan untuk
mengumpulkan,
menyimpan,
memproses, dan mengirimkan data dan
informasi.
6) Pengendalian internal dan pengukuran keamanan yang mengamankan data
dalam sistem informasi akuntansi.
2.1.4 Siklus Sistem Informasi Akuntansi
Menurut Wilkinson et al. (2000, p45), siklus sistem informasi akuntansi yang
merupakan siklus transaksi akuntansi (transaction cycles) terdiri dari:
1) General Ledger and Financial Reporting Cycle
Merupakan pusat dari siklus lainnya. Siklus ini
unik dimana pemrosesan
transaksi individual bukanlah merupakan fungsi keseluruhannya maupun
fungsinya yang penting. Selain itu, juga lebih banyak bekerja
sama
dengan
pemrosesan yang berhubungan dengan akuntansi daripada kejadian bisnis. Arus
masuk utamanya timbul dari output siklus transaksi lainnya. Sebagai tambahan,
siklus ini meliputi transaksi non rutin dan penyesuaian yang timbul selama atau
pada akhir tiap periode akuntansi.
2) Revenue Cycle
Siklus
ini
meliputi
tiga kejadian bisnis atau
transaksi kunci:
permintaan
atas proyek, eksekusi proyek dan pengiriman (penjualan), dan penerimaan kas.
|
|
14
3) Expenditure Cycle
Siklus
ini
meliputi
dua
kejadian
bisnis atau
transaksi
kunci:
pembelian
dan pengeluaran kas.
4) Resources-management Cycle
Siklus ini terdiri dari semua aktivitas yang berhubungan dengan sumber
daya fisik perusahaan. Jadi melibatkan kejadian bisnis sebagai berikut:
o
Memperoleh
modal
dari
berbagai
sumber
(termasuk
pemilik),
menginvestasikan modal dan membayar modal ke penerimanya.
o
Memperoleh, memelihara, dan menyingkirkan fasilitas (aset tetap).
o
Memperoleh, menyimpan, dan menjual persediaan (barang dagangan).
o
Memperoleh,
memelihara, dan
membayar personel (seperti pegawai,
manager, konsultan dan pihak luar lainnya).
5) Other Transaction Cycles
Siklus ini merupakan siklus-siklus lain selain yang telah dijelaskan diatas,
yang tergantung dari jenis perusahaan. Misalnya pada perusahaan manufaktur
menambahkan siklus produksi atau konversi (production/conversion cycle).
Sedangkan menurut Boockholdt (1999, p521), Secara umum, siklus transaksi
dapat dikelompokkan menjadi 4 sebagai berikut:
1) Financial Cycle
Siklus finansial terdiri dari transaksi akuntansi yang merecord akuisisi
modal dari pemilik dan kreditor, penggunaan modal tersebut untuk memperoleh
asset
yang
produktif,
dan
pelaporan
pada
pemilik
dan
kreditor
tentang
bagaimana hal tersebut digunakan.
|
|
15
2) Expenditure Cycle
Siklus
ini
terdiri
dari
transaksi-transaksi
yang timbul
dari
perolehan
material
dan
item-item overhead yang
akan
digunakan
dalam
proses konversi
dari bisnis. Siklus ini memproses
transaksi yang mewakili kejadian bisnis:
permintaan atas item-item, penerimaan
item-item,
merecord
kewajiban
untuk
membayar item-item, dan membayarnya.
3) Revenue Cycle
Siklus ini terdiri dari transaksi akuntansi yang merecord perolehan
pendapatan dari output pada proses konversi.
Empat
kejadian
ekonomis
yang
menghasilkan
pendapatan:
memperoleh order dari pelanggan, mengirimkan
barang atau jasa kepada pelanggan, meminta pembayaran dari pelanggan, dan
menerima pembayaran.
4) Conversion Cycle
Siklus
ini
terdiri
dari transaksi
yang timbul
ketika
input
dikonversikan
menjadi
barang
atau
jasa
yang
dapat
dijual.
Satu
kejadian
ekonomis
timbul
dalam siklus
konversi. Material,
tenaga
kerja,
dan
overhead
digunakan
dalam
proses konversi.
Menurut pendapat Rommney dan Steinbart (2006, p30), siklus pemrosesan
transaksi pada sistem adalah suatu rangkaian aktivitas
yang dilakukan perusahaan
dalam melakukan
bisnisnya,
mulai
dari
proses
pembelian,
produksi,
hingga
penjualan barang atau jasa. Siklus transaksi pada perusahaan dapat dibagi kedalam
lima subsistem yaitu:
|
|
16
1) Revenue cycle (Siklus Pendapatan),
yang terjadi dari
transaksi pembelian dan
penerimaan kas.
2) Expenditure Cycle (Siklus Pengeluaran), yang
terdiri dari peristiwa pembelian
dan pengeluaran kas.
3) Human Resoure
/
Payroll Cycle
(Siklus Sumber
Daya
Manusia), yang terdiri
dari peristiwa yang berhubungan dengan perekrutan dan pembayaran atas
tenaga kerja.
4) Production Cycle (Siklus Produksi), yang terdiri dari peristiwa yang
berhubungan
dengan
pengubahan
bahan
menyah
menjadi
produk
/
jasa
yang
siap dipasarkan.
5)
Financing
Cycle
(Siklus
Keuangan
Perusahaan),
yang
terdiri
darpi
peristiwa
yang berhubungan dengan penerimaan modal dari investor dan kreditor.
2.2
Sistem Informasi Akuntansi Pembelian
2.2.1 Aktivitas Bisnis dan prosedur dalam Expenditure Cycle
Menurut Romney dan Steinbart (2006, p411), terdapat 3 aktivitas bisnis
utama dalam expenditure cycle:
1)
Memesan barang, supplies dan jasa.
2)
Menerima dan menyimpan barang, supplies, dan jasa.
3)
Membayar untuk barang, supplies, dan jasa.
|
   17
Purchase Order
Open
Purchase
Various
Departments
Requests
Copy of
PO
Suppliers
1.0
Order
Goods
Requests
Copy of PO
Inventory
Control
Order
Inventory
Goods
and
Copy
of PO
Requests
Back
Orders
Production
Cycle
Suppliers
Packing
Slip
General
Ledger
Accounts
Payable
2.0
Receive
and
Store Goods
Receipts
Revenue
Cycle
Goods and
Receiving
Reports
Inventory
Stores
(Warehouse)
Invoices
Payments
3.0
Pay for
Goods
Receiving
Report
Copy of PO
Gambar 2.1 Data flow diagram level 0 dalam expenditure cycle
(Romney dan Steinbart, 2006, p411)
Menurut
Hall
et
al (2001,
p240),
prosedur
dalam
sistem
pemrosesan
pembelian adalah sebagai berikut:
1) Fungsi pembelian dimulai dengan timbulnya kebutuhan
untuk
menambah
kembali persediaan melalui observasi dari catatan persediaan. Tingkat
persediaan menurun baik melalui penjualan
langsung
ke pelanggan
(aktivitas
siklus pendapatan), maupun transfer ke dalam proses manufaktur (aktivitas
siklus konversi). Informasi kebutuhan persediaan dikirimkan pada proses
pembelian dan account payable (AP).
|
|
18
2)
Proses
pembelian
menentukan
jumlah
untuk
dipesan,
memilih
pemasok
dan
mempersiapkan purchase order (PO). Informasi dikirimkan pada suplier dan
proses PO.
3) Setelah beberapa waktu, perusahaan menerima item persediaan dari pemasok.
Barang
yang
diterima
diperiksa kualitas
dan
kuantitasnya
dan
dikirimkan
ke
tempat penyimpanan atau gudang.
4) Informasi
mengenai
persediaan
yang
diterima
digunakan
untuk
mengupdate
catatan persediaan.
5) Proses AP menerima invoice dari pemasok.
AP merekonsiliasikannya dengan
informasi lain yang telah dikumpulkannya atas transaksi dan mencatat
kewajiban
untuk membayar di
masa
yang akan datang, tergantung dari
syarat
perdagangan dengan pemasok. Biasanya, pembayaran akan dilakukan pada hari
terakhir yang mungkin untuk mengambil keuntungan penuh dari bunga dan
diskon yang ditawarkan.
6) General ledger menerima informasi yang telah dirangkum dari account payable
(jumlah
peningkatan
dalam kewajiban)
dan
inventory
control
(jumlah
pengingkatan
dalam persediaan).
Informasi
ini
akan
direkonsiliasi
untuk
keakuratannya dan diposting ke akun utang dan persediaan.
2.2.2 Manajemen Bahan Baku
Menurut Hall et al (2001, p21-22), tujuan dari manajemen bahan baku adalah
untuk merencanakan dan mengontrol persediaan bahan baku perusahaan. Sebuah
perusahaan manufaktur harus memiliki
persediaan yang cukup di tangan untuk
memenuhi kebutuhan persediaannya dan tetap harus menghindari tingkat
|
|
19
persediaan
yang
berlebih.
Setiap
uang
yang
diinvestasikan
dalam persediaan
merupakan uang yang tidak memberikan pendapatan. Selanjutnya, persediaan yang
menganggur dapat menjadi usang atau dicuri.
Idealnya, sebuah perusahaan akan mengkoordinasi persediaan yang datang
dari pemasok sedemikian sehingga mereka langsung dipindahkan ke proses
produksi. Namun demikian, semata-mata agar praktis, kebanyakan organisasi
mempertahankan persediaan pengaman untuk
menyimpan
persediaan
itu
selama
waktu
tunggu,
antara
waktu
pesanan
persediaan dengan waktu datangnya
persediaan. Kita dapat melihat bahwa
manajemen
bahan
baku
memiliki
tiga
subfungsi yaitu:
•
Pembelian bertanggung jawab untuk memesan persediaan dari para pemasok
ketika tingkat persediaan mencapai titik pemesanan kembali (reorder point).
•
Penerimaan adalah tugas untuk
menerima persediaan
yang sebelumnya dipesan
oleh bagian pembelian. Aktivitas penerimaan meliputi perhitungan dan
pengecekan kondisi fisik item-item tersebut.
• Penyimpanan
meliputi
pengawasan
fisik
atas
persediaan
yang
diterima
dan
mengeluarkan persediaan tersebut ke proses produksi, sesuai kebutuhan.
Adapun
istilah-istilah
yang
terkait dengan
manajemen
bahan
baku
adalah
sebagai berikut :
1) Reorder Point (ROP)
Menurut Render dan Heizer (2001, p324), ROP merupakan suatu titik dimana
pemesanan harus dilakukan kembali oleh perusahaan untuk menggantikan
persediaan yang telah digunakan.
|
|
20
2) Economic Order Quantity (EOQ)
Menurut Keown et al (2000, p752), Model EOQ mencoba menentukan ukuran
pemesanan
yang akan meminimisasi biaya persediaan total. Masalah kuantitas
pemesanan
melibatkan
menentukan
ukuran pemesanan optimal untuk jenis
persediaan dengan penggunaan yang diperkirakan, biaya penyimpanan, dan
biaya pemesanan.
3) Safety Stock
Menurut Keown
et
al
(2000, p754), safety stock
atau stok keamanan adalah
persediaan yang dipegang untuk mengakomodasi penggunaan yang luar biasa
dan tidak diharapkan selama waktu pengiriman
4) Lead Time
Menurut
Render
dan
Heizer
(2001,
p324), lead
time atau
waktu
pengiriman
adalah waktu antara dilakukannya pemesanan.
2.2.3 Tujuan Expenditure Cycle
Menurut Wilkinson et al. (2000, p469), tujuan utama dari siklus pengeluaran
adalah untuk memfasilitasi pertukaran antara kas dengan suplier (vendor) untuk
barang dan jasa yang dibutuhkan. Tujuan dalam lingkup yang lebih luas adalah:
1) Untuk
menjamin bahwa semua barang dan jasa
telah
dipesan sesuai
dengan
yang dibutuhkan.
2) Menerima
semua
barang
yang
dipesan dan
menjamin bahwa barang tersebut
berada dalam kondisi yang baik.
3) Untuk mengamankan barang sampai dibutuhkan.
|
|
21
4) Menentukan bahwa invoice yang berkaitan dengan barang dan jasa adalah valid
dan benar.
5) Merecord dan mengklasifikasikan pengeluaran secara tepat dan benar.
6) Memasukkan kewajiban dan pengeluaran kas ke dalam akun supplier yang tepat
dalam accounts payable ledger.
7) Menjamin bahwa semua pengeluaran kas berhubungan dengan pengeluaran
yang telah diotorisasi.
8) Untuk merecord dan mengklasifikasikan pengeluaran kas secara tepat dan
benar.
2.2.4 Unit/fungsi yang terkait dalam Expenditure Cycle
Menurut Wilkinson et al. (2000, p470), unit/fungsi organisasi yang terkait
dalam siklus pengeluaran adalah:
1) Manajemen persediaan / logistik
Dalam manajemen persediaan, selain tanggung jawab perencanaan, juga
melibatkan pembelian, penerimaan, dan penyimpanan. Pembelian berfokus
terutama pada pemilihan vendor atau suplier yang paling tepat untuk pemesanan
barang dan jasa berdasarkan berbagai faktor. Bersamaan dengan dengan
pengendalian
persediaan
(yang
berada di
bawah
fungsi
akuntansi),
bagian
pembelian
memastikan kuantitas dari barang
yang akan diperoleh. Penerimaan
bertanggungjawab hanya menerima barang-barang yang dipesan, memverifikasi
kuantitas dan kondisinya, dan memindahkan barang ke tempat penyimpanan.
Penyimpanan
bertanggungjawab
dalam
mengamankan barang
dari
pencurian,
|
 22
kehilangan, kemerosotan, dan menempatkannya dengan tepat ketika timbul
permintaan atau kebutuhan.
2) Akuntansi / keuangan
Sehubungan dengan expenditure cycle, tujuan dari manajemen akuntansi
atau finansial terbatas pada perencanaan dan pengendalian kas, data yang
berhubungan dengan pembelian dan akun suplier, pengendalian persediaan, dan
informasi yang berhubungan dengan kas dan pembelian dan suplier.
Gambar 2.2 Hubungan unit organisasi dalam fungsi siklus pengeluaran
(Wilkinson et al., 2000, p471)
2.2.5 Dokumen-dokumen yang Terkait
|
|
23
2.2.5 Dokumen-dokumen yang Terkait
Menurut Wilkinson et al. (2000, p472), dokumen-dokumen yang terkait
dalam siklus pengeluaran adalah sebagai berikut:
1. Purchase requisition
Formulir
yang
mengawali siklus pengeluaran yang
mengotorisasi penempatan
pemesanan barang atau jasa.
2. Purchase order
Formulir formal dan rangkap banyak yang dipersiapkan dari Purchase
requisition yang mengikat perusahaan yang mendapatkan.
3. Receiving report
Dokumen yang mencatat penerimaan barang.
4. Supplier’s (vendor’s) invoice
Dokumen penagihan dari pemasok yang menyediakan barang atau jasa.
5. Disbursement voucher
Dokumen di dalam
sistem
voucher
yang mengakumulasikan invoice pemasok
untuk pembayaran.
6. Disbursement check
Dokumen
akhir
dari
siklus
pengeluaran
yang
menyediakan
pembayaran pada
supplier untuk barang atau jasa.
7. Debit memorandum
Dokumen yang mengotorisasi pengembalian pembelian atau retur.
|
|
24
8. New supplier (vendor) form
Formulir yang digunakan dalam seleksi pemasok baru, yang menunjukkan data
seperti
harga, tipe barang
atau
jasa yang
disediakan,
pengalaman,
pemberian
kredit, dan referensi.
9. Request for proposal (quotation)
Formulir
yang
digunakan
dalam prosedur
tawar-menawar
yang
kompetitif,
memperlihatkan barang atau jasa yang diperlukan
dan
perbandingan
harga,
syarat, dan lain-lain.
2.2.6 Manajemen Data
Menurut
Wilkinson
et
al.
(2000,
p103),
terdapat
dua
orientasi
yang
dapat
digunakan dalam memodel data yaitu:
1) File-oriented systems
Dalam sistem
file-oriented,
setiap
aplikasi
memiliki
jumlah
user
yang
terbatas
yang
terlibat dalam pemrosesan data tipe khusus
yang diperoleh dan
menggunakan outputnya untuk kebutuhan khususnya. Hirarki sistem ini terdiri
dari data element, record, dan file.
2) Database systems
Dalam sistem database, data dipandang sebagai sumber daya pusat dan
sama-sama digunakan untuk semua user yang berkepentingan dan aplikasinya.
Fokusnya adalah data sebagai asset. Aplikasi yang memproses data diberikan
lebih sedikit prioritas. Hirarki dari sistem ini adalah data set dan data base.
|
|
25
2.2.7 Laporan-laporan yang dihasilkan
Menurut Wilkinson et al. (2000, p487), laporan yang dihasilkan sebagai
bagian integral atau hasil tambahan dari pemrosesan siklus pengeluaran
dibutuhkan
untuk
memimpin operasi perusahaan dan membantu dalam keputusan
perencanaan dan pengendalian. Output informasi yang dihasilkan adalah sebagai
berikut:
1) Operational listings and reports
Berbagai register dan jurnal membantu memelihara bukti audit. Laporan
operasional membantu dalam mengendalikan
operasi
dengan
memfokuskan
pada dokumen yang masih terbuka (open document). Laporan operasional
lainnya mungkin melibatkan persediaan dan aktivitas penerimaan.
2) Inquiry display screens
Inquiries dari personel klerikan seringkali cukup spesifik dan
melibatkan data
yang terbatas. Inquiries dari pegawai yang profesional cenderung analitis.
Inquiries yang dibuat oleh manager dapat analitis dan berorientasi pada
keputusan.
3) Scheduled managerial reports
Berbagai macam laporan, seperti laporan status persediaan, dapat dipersiapkan
berdasarkan jadwal untuk digunakan oleh manager persediaan atau keuangan.
Contoh lainnya seperti
laporan umur utang, analisis pembelian, laporan
performa pemasok, dan laporan faktor kritis.
|
|
26
4) Demand managerial reports
Merupakan laporan khusus yang tidak terjadwal. Informasi yang dikandungnya
biasanya digunakan terutama untuk pengambilan keputusan managerial.
2.3
Sistem Pengendalian Internal
2.3.1 Pengertian Sistem Pengendalian Internal
Menurut Boockholdt (1999, p397), pengendalian internal (internal control)
adalah
suatu proses,
yang
dipengaruhi
oleh
Board of Directors,
manajemen dan
personel lainnya, yang dirancang untuk
menyediakan keyakinan yang memadai
berkaitan dengan pencapaian tujuan-tujuan dalam kategori sebagai berikut:
¾
Keefektifan dan keefisienan operasi
¾
Pelaporan keuangan yang dapat diandalkan
¾
Kepatuhan terhadap hukum dan peraturan yang berlaku
Menurut
Horngren
et
al.
(2002,
p267), pengendalian internal adalah
perencanaan
organisasi
dan
semua pengukuran
yang berhubungan
yang diadopsi
oleh suatu entitas untuk melindungi asset, memacu ketaatan kebijakan perusahaan,
meningkatkan efisiensi operasional, dan menjamin keakuratan dan keandalan
record akuntansi.
2.3.2 Tujuan Sistem Pengendalian Internal
Menurut Hall et al (2001, p150), pengendalian internal merangkum pada
kebijakan, praktek, dan prosedur yang digunakan untuk mencapai 4 tujuan utama,
yaitu :
|
|
27
1) Untuk menjaga aktiva perusahaan
2) Untuk
memastikan
akurasi
dan
dapat
diandalkannya
catatan
dan
informasi
akuntansi
3) Untuk mempromosikan efisiensi operasi perusahaan
4) Untuk
mengukur kesesuaian dengan kebijakan dan prosedur yang telah
ditetapkan oleh manajemen
2.3.3 Aktivitas Pengendalian Internal
Menurut Wilkinson et al. (2000, p5), aktivitas pengendalian intern meliputi:
1) General Control
•
Organizational Controls
Harus dilakukan pemisahan fungsi antara yang melakukan operasional dengan
bagian yang menangani pencatatan.
•
Documentation Controls
Dokumentasi yang ada harus lengkap dan up-to-date.
•
Asset Accountabillity Controls
Buku besar
pembantu utang harus dimaintainin dan direkonsiliasi secara
berkala dengan rekening kontrol utang yang ada dibuku besar. Demikian juga
halnya dengan catatan persediaan dan keseimbangan atas saldo bank dan kas
di buku besar.
•
Management Practices Controls
Karyawan, termasuk programmer dan akuntan harus diberikan pelatihan;
perkembangan sistem dan perubahannya harus mengikuti prosedur yang jelas;
|
|
28
audit harus dilakukan terhadap kebijakan pembelian dan pengeluaran kas.
Manajer
harus
melakukan review terhadap
analisis
periodik
dan
laporan
–
laporan
mengenai
kegiatan
akuntansi dan
transaksi
yang
disahkan
melalui
komputer
•
Data Center Operation Controls
Staf TI dan akuntansi harus diawasi secara aktif dan kinerja mereka direview
dengan bantuan laporan kontrol proses komputer dan pencatatan akses
•
Authorization Controls
Semua transaksi pembelian kredit harus diotorisasi oleh manajer yang telah
ditetapkan.
•
Access Controls
Menggunakan password, Terminal yang khusus untuk fungsi yang
bersangkutan,
melakukan log terhadap semua transaksi pembelian dan
pengeluaran kas pada saat dientry ke
dalam
sistem,
melakukan back-up,
terhadap file utang dan persedian ke dalam
media penyimpanan
lain, gudang
dan
tempat
penyimpanan
cek
kosong yang terlindung secara
fisik, log
yang
memantau semua akses data tersimpan dalam file.
2) Application Controls
Tujuan dari application controls untuk
membantu memastikan bahwa
semua
transaksi
diotorisasi
secara
sah dan
tepat,
dicatat,
dikelompokkan,
diproses, dan dilaporkan. Application controls terdiri dari :
•
Input Controls
Transaksi – transaksi harus dicatat secara akurat, lengkap, dan tepat.
|
|
29
•
Processing Controls
Untuk memastikan bahwa data diproses dengan tepat dan lengkap, tidak
termasuk transaksi
yang tidak diotorisasi,
hanya file dan program yang benar
dimasukkan, sehingga semua transaksi dapat dengan mudah ditelusuri.
•
Output Controls
Outputs
menyediakan sebuah sistem informasi yang lengkap dan dapat
diandalkan serta disampaikan kepada penerima informasi yang tepat.
2.3.4 Komponen Sistem Pengendalian Internal
Dalam buku
Boockholdt
(1999,
p400),
menurut COSO
report,
komponen
pengendalian internal terdiri dari 5 yaitu:
1) Control environment (Lingkungan Pengendalian)
Control environment mengatur sifat dari organisasi. Menyediakan
disiplin dan struktur, merupakan pondasi bagi komponen lain dari pengendalian
internal. Hal ini dipengaruhi oleh sejarah dan budaya organisasi dan memiliki
pengaruh yang pervasif pada bagaimana organisasi mencapai tujuannya. Faktor-
faktor yang mempengaruhi control environment:
o
Integritas dan nilai kesopanan
o
Komitmen pada kompetensi
o
Partisipasi Board of Directors dan komite audit
o
Filosofi manajemen dan gaya operasi
o
Struktur organisasi
o
Penugasan otoritas dan tanggung jawab
|
|
30
o
Kebijakan dan praktek sumber daya manusia
2) Risk assessment (Penilaian Resiko)
Risk
assessment
merupakan
proses
manajemen
dalam mengidentifikasi
dan
menganalisis
resiko yang
mungkin
mencegah
organisasi
dalam mencapai
tujuannya. Risk assessment dapat berasal dari:
o
Faktor eksternal yang mempengaruhi organisasi secara keseluruhan.
o
Faktor internal yang berhubungan dengan aktifitas spesifik dari organisasi.
3) Control activities (Aktivitas Pengendalian)
Control activities merupakan kebijakan dan prosedur
yang diambil oleh
manajemen
untuk
menyediakan
keyakinan
yang
memadai
bahwa
pengarahan
dan perintah dari
manajemen dilaksanakan.
Terdapat 4 tipe dari control
activities antara lain:
o
Prosedur untuk mengotorisasi transaksi
o
Keamanan dari assets dan records
o
Pemisahan tanggung jawab
o
Kecukupan dokumen dan records
4) Information and communication (Informasi dan Komunikasi)
Informasi dibutuhkan oleh semua level dalam organisasi untuk membuat
keputusan organisasi, untuk pelaporan keuangan dan untuk kepatuhan.
Informasi diidentifikasikan, diambil, diproses dan dilaporkan oleh sistem
informasi.
Komunikasi
melekat
dalam sistem
informasi.
Bagaimanapun,
komunikasi mencakup lebih dari pemrosesan data finansial sampai meliputi
bentuk internal dan eksternal lainnya.
|
 31
5) Monitoring (Pemantauan)
Monitoring, adalah proses yang menilai kualitas dari performa
pengendalian internal sepanjang waktu.
Membantu
manajemen
dalam
menentukan
modifikasi
terhadap
sistem yang
diperlukan
seiring
dengan
perubahan kondisi.
2.3.5 Pengendalian Internal pada Sistem Pembelian
Menurut
Romney
dan
Steinbart (2006, p425), prosedur pengendalian yang
dapat diterapkan dalam berbagai ancaman utama dalam siklus pengeluaran adalah
sebagai berikut:
Tabel 2.1 Ancaman dan Pengendalian dalam Siklus Pengeluaran
(Romney dan Steinbart, 2006, p411)
Proses /
Aktivitas
Ancaman
Prosedur pengendalian yang dapat
diterapkan
Pemesanan
barang
1. mencegah
kehabisan stok atau
persediaan yang
berlebihan.
2. Memesan item
yang tidak
diperlukan.
3.
Membeli barang
pada harga yang
melambung.
4. Membeli barang
yang bermutu
rendah.
Sistem pengendalian persediaan,
catatan persediaan secara perpetual,
teknologi bar-code, penghitungan
periodik atas persediaan.
Catatan persediaan perpetual yang
akurat, persetujuan atas permintaan
pembelian.
Daftar harga, permintaan penawaran
yang
kompetitif, menggunakan
pemasok yang sudah disetujui,
persetujuan atas pemesanan
pembelian(PO), pengendalian
anggaran.
Menggunakan pemasok yang sudah
disetujui, persetujuanatas
pemesanan
pembelian(PO), memantau performa
pemasok, pengendalian anggaran.
|
 32
5. Membeli dari
pemasok yang
tidak sah.
6. kickbacks
Persetujuan
atas pemesanan
pembelian(PO), pembatasan akses ke
master
file pemasok,
pembatasan
atas
penggunaan kartu procurement.
Kebijakan yang menentang
penerimaan hadiah dari pemasok,
training, penggiliran kerja,
menyelenggarakan liburan untuk agen
penjualan, mengharuskan pegawai
pembelian untuk menyertakan
keterkaitan finansial dengan pemasok,
audit pemasok.
Penerimaan
dan
penyimpanan
barang
7. Menerima barang
yang tidak
dipesan.
8. Membuat
kesalahan dalam
menghitung barang
yang diterima.
9. Mencuri
persediaan.
Mengharuskan
pegawai
penerimaan
dermaga untuk menverifikasi
keberadaan PO yang valid.
Menggunakan teknologi bar-code,
mendokumentasikan performa
pegawai, insentif untuk penghitungan
yang akurat.
Pengendalian akses fisik, penghitungan
periodik atas persediaan dan
rekonsiliasi perhitungan fisik ke
catatan, mendokumentasikan semua
transfer
persediaan, pemisahan
tanggung jawab yang benar.
Menyetujui
dan
membayar
invoice dari
pemasok
10. Gagal dalam
mendeteksi error
dalam invoice
pemasok.
11. Membayar untuk
barang yang tidak
diterima.
12. Gagal untuk
menggunakan
diskon pembelian
yang tersedia.
Pengecekan 2 kali atas keakuratan
invoice, pelatihan pada staff utang,
menggunakan ERS.
Hanya membayar invoice yang
didukung oleh laporan penerimaan asli,
menggunakan ERS, pengendalian
anggaran.
Pengisian yang benar, anggaran arus
kas.
|
 33
13. Membayar invoice
yang sama 2 kali.
14. Mencatat dan
memposting error
dalam utang.
15. Menggelapkan
kas, cek atau
EFTs.
Hanya membayar invoice yang
didukung paket voucher asli,
pembatalan paket voucher selama
pembayaran, menggunakan ERS,
pengendalian
akses
ke
master file
pemasok.
Berbagai
macam entri
data
dan
pengendalian edit pemrosesan.
Akses
yang terbatas pada
cek
kosong,
mesin penanda cek, terminal transfer
EFT, pemisahan tanggung jawab utang
dan kasir, rekonsiliasi akun bank oleh
seseorang yang independen dari proses
pengeluaran kas, pengukuran
perlindungan cek termasuk positive
pay, review regular dari transaksi EFT.
Isu
pengendalian
umum
16. Kehilangan,
penggantian, atau
penelusuran
yang
tidak sah atas data.
17. Performa yang
buruk.
Label file, rencana backup dan
pemulihan dari bencana, pengendalian
akses fisik dan logis, konfigurasi dari
sistem ERP
untuk
menyelenggarakan
pemisahan tanggung jawab yang benar,
enkripsi, pengendalian transmisi data.
Mengembangkan dan review periodik
atas laporan performa yang tepat.
|
|
34
2.4
Object Oriented Analysis and Design
2.4.1 Pengertian Object Oriented Analysis and Design (OOA&D)
Menurut
Mathiassen
et
al
(2000,
p4),
dalam OOA&D,
blok
pembangun
dasarnya adalah objek. Objek adalah kesatuan dengan identity,
state dan
behaviour. Object oriented analysis menekankan
pada
penemuan
dan
mendeskripsikan
objek
atau
konsep pada
problem domain.
Sedangkan
object
oriented
design menekankan
pada
pendefinisian
software
object
yang
diimplementasikan pada bahasa pemrograman.
Intisari dari OOA&D adalah
penekanan pada pertimbangan Problem Domain dan solusi logis dari persepsi
objek (sesuatu, konsep, entitas).
Menurut Whitten et al (2004, p31 ), ”Object Oriented Analysis and Design is
a
collection of tools and techniques for system development that will utilize object
technologies to construct a system and its software.” dapat diterjemahkan bahwa
OOA&D adalah sekumpulan dari alat-alat dan teknik-teknik untuk pengembangan
sistem yang akan memanfaatkan teknologi obyek untuk membangun sebuah sistem
dan perangkat lunaknya.
Dari definisi
diatas dapat disimpulkan
bahwa object
oriented
analysis
and
design
merupakan
kegiatan
untuk
menentukan
problem
domain dan
kemudian
mencari pemecahan masalah yang logical yang berbasiskan objek.
|
|
35
2.4.2 System Definition
Menurut Mathiassen et al (2000, p24), System definition merupakan deskripsi
singkat dari sebuah sistem terkomputerisasi yang dinyatakan dalam bahasa alami.
Suatu system definition mengekspresikan property-properti
yang
fundamental
untuk pengembangan dan penggunaan sistem. Hal tersebut mendeskripsikan sistem
dalam konteks, informasi apa yang harus dikandungnya, function mana yang harus
tersedia,
dimana
hal
tersebut
akan digunakan, dan
kondisi
pengembangan
mana
yang diterapkan. Tujuan dari system definition adalah untuk menerangkan berbagai
intepretasi
dan
kemungkinan
yang
berbeda. System definitions
membantu
menangani gambaran umum dari berbagai pilihan-pilihan yang berbeda, dan dapat
digunakan
untuk
membandingkan berbagai
alternatif.
System definition
yang
akhirnya
dipilih harus menyediakan
pondasi
yang
sangat
diperlukan
untuk
melanjutkan aktivitas analisis dan desain.
2.4.2.1 Kriteria FACTOR
Menurut Mathiassen et al (2000, p39), criteria FACTOR terdiri dari 6
elemen:
1) Functionality
: Fungsi dari sistem yang mendukung tugas-tugas
application- domain.
2) Application-domain
: Bagian dari organisasi yang mengadministrasi,
memonitor, atau mengontrol suatu problem domain.
3) Conditions
:
Kondisi dimana
sistem akan dikembangkan
dan
digunakan.
|
|
36
4) Technology
: Teknologi yang digunakan untuk mengembangkan
sistem dan teknologi dimana sistem akan berjalan.
5) Objects
: Objek utama dalam problem domain
6) Responsibility
:
Tanggung
jawab
keseluruhan dari
sistem dalam
hubungannya dengan konteksnya.
Kriteria FACTOR dapat digunakan dalam 2 cara:
a)
Dapat
digunakan
untuk
mendukung
pengembangan system
definition,
secara
hati-hati
mempertimbangkan
bagaimana
masing-masing
dari keenam elemen
seharusnya diformulasikan.
b)
Atau,
dapat
memulai
definisi dengan
mendeskripsikan sistem dan kemudian
menggunakan
criteria
untuk
melihat
bagaimana system
definition
memuaskan masing-masing dari keenam factor.
2.4.2.2 Rich Picture
Menurut Mathiassen et al (2000, p26), Rich picture adalah sebuah gambaran
informal yang mewakili pemahaman ilustrator terhadap situasi dari sistem. Dengan
membuat rich picture, kita dapat menerangkan pandangan
user yang penting dari
sebuah situasi,
memfasilitasi pembahasan, dan memperoleh
gambaran
umum dari
situasi dengan cepat. Tujuan pembuatannya bukan untuk membuat deskripsi yang
mendetail
dari
semua
keadaan
yang
mungkin, tetapi lebih untuk memperoleh
gambaran umum.
|
|
37
4) Technology
: Teknologi yang digunakan untuk mengembangkan
menyeluruh
dari people,
object,
process,
sructure,
dan problem domain, system
problem dan application domain.
2.4.3 Aktivitas utama dalam OOA&D
Menurut Mathiassen et al (2000, p15),
OOA&D
mencakup
4
perspektif
melalui
4
aktivitas utamanya
yaitu Problem
Domain Analysis,
Application
Domain
Analysis,
Architectural
Design,
dan
Component
Design.
Keempat
aktivitas
utama
tersebut
adalah tugas
abstrak
yang
dapat
dilakukan
secara
bersama-sama
dengan
tugas
lainnya
dalam suatu praktek
proyek
pengembangan
sistem
.
2.4.3.1 Problem Domain analysis
Mengacu
pada
Mathiassen
et
al
(2000),
“Problem-domain
analysis adalah
analisa terhadap sistem bisnis dalam dunia nyata yang dapat diatur, dimonitor, atau
dikendalikan
oleh
sistem.
Tujuan
dari aktivitas
ini
adalah
membangun
sebuah
model yang dapat digunakan untuk merancang dan mengimplementasikan sebuah
sistem yang dapat memproses, berkomunikasi dan menyajikan informasi mengenai
problem domain. Hasil dari problem domain analysis adalah
class diagram.
Menurut Mathiassen ( 2000, p46-47 ) terdapat tiga subaktivitas dalam
Problem Domain Analysis, yaitu :
|
 38
1) Classes
Menurut Mathiassen et al (2000, p53), class adalah
gambaran
atau
deskripsi
kumpulan
dari objek
yang berbagi structure,
behaviour
pattern,
dan
attribute yang sama. Pemilihan
class bertujuan untuk mendefinisikan dan
membatasi problem-domain,
sedangkan
pemilihan
event
bertujuan
untuk
membedakan
tiap-tiap class dalam problem-domain. Menurut
Mathiassen
et al
(2000, p51), “Event merupakan kejadian secara terus menerus yang melibatkan
satu
atau
lebih dari
suatu
object.”
Kegiatan
class
akan
menghasilkan
suatu
event table.
2) Structure
Gambar 2.3 Notasi dasar dari class
(Mathiassen et al, p337-339)
Menurut Mathiassen et al (2000, p336), Structure adalah hubungan
antara class dengan object pada problem domain secara keseluruhan. Hasil dari
kegiatan
structure
adalah
membuat class
diagram.
Class
diagram
menggambarkan kumpulan dari classes dan hubungan yang terstruktur.
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 :
|
 39
Gambar 2.4 Notasi Class Structure
(Mathiassen et al, 2000, p337)
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 special class ( subclass ).
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.
Gambar 2.6 Cluster Structure
(Mathiassen et al,2000,p75)
|
 40
2. Object
structure,
mengekspresikan
hubungan
dinamis
dan
konkret
antar
object. Biasanya terdapat multiplicity yang menspesifkasikan jumlah dari
object yang berealisasi. Multiplicity
dapat berupa string of numbers dan
penyebaran internal dengan koma,
seperti
“0,3,7,9..,13,19..*”,
“*”
disebut
many; dan 0..*. Ada 2 macam object structure yaitu :
Aggregation
Association
(logical)
Gambar 2.7 Notasi Object Structure
(Mathiassen et al, 2000, p337)
a)
Aggregation
Structure,
mendefinisikan
hubungan
antara
dua
atau
lebih
object. Sebuah superior object ( whole ) memiliki beberapa object (parts)
(Mathiassen et al, 2000, p72). Secara
ilmu bahasa, aggregation structure
dieskpresikan dengan formulasi “has a”, “a-part-of”, atau “is-owned-by”.
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”
|
 41
3)
Behavior
Gambar 2.8 Association Structure
(Mathiassen et al, 2000, p77)
Mengacu pada pendapat Mathiassen et al (2000, p89), kegiatan behaviour
bertujuan
untuk
memodelkan apa
yang
terjadi
(perilaku
dinamis) dalam
problem-domain sistem sepanjang waktu. Tugas utama dari kegiatan ini adalah
menggambarkan
pola
perilaku
(behavioural
pattern)
dan
attribut
dari setiap
class. Hasil dari kegiatan ini adalah behavioral pattern yang diekspresikan
secara grafis dalam statechart diagram.
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 : “+”.
• 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.
Menurut Mathiassen (2000, p 341), State chart diagram menjelaskan tentang
|
 42
behavior umum dari semua object dalam sebuah class yang spesifik dan
berisikan state dan transition di antara mereka.
Gambar 2.9 Notasi Dasar Statechart Diagram
(Mathiassen et al, 2000, p341)
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 ).
2.4.3.2 Application Domain analysis
Mengacu pada Mathiassen et
al (2000, p117),
”Application Domain
adalah
suatu organisasi yang mengatur, memonitor, atau mengendalikan problem-domain.
Application
domain
analysis
memfokuskan
pada
bagaimana
target
sistem akan
digunakan
dengan
menentukan
kebutuhan
function
dan interace.”
Prinsip
dari
Application Domain Analysis adalah bekerja sama dengan user untuk menentukan
usage, function, dan interface.
Menurut Mathiassen et al (2000, p117) terdapat tiga subaktivitas dalam
Application Domain Analysis, yaitu :
|
|
43
1) Usage
Mengacu pada pendapat Mathiassen et al (2000), tujuan dari kegiatan
usage
adalah untuk menentukan bagaimana aktor-aktor yang merupakan
pengguna
atau
sistem lain
berinteraksi
dengan
sistem yang
dituju.
Interaksi
antara actor dan
sistem dinyatakan
dalam
use
case.
Mathiassen
et
al
(2000,
p119-120)
menyatakan,
”Use case is a pattern for interaction the system and
actor in application domain.”, sedangkan “Actor is an abstraction of user or
other systems that interact with target system.”
Hasil akhir dari aktivitas ini
adalah
membuat
deskripsi
dari actors
dan
use
cases,
dimana
relasinya
diekspresikan dengan menggunakan actor table atau use case diagram.
2) Function
Mathiassen
et
al
(2000,
p138)
menyatakan,
”Function
is a facility
for
making a model useful for actors.” Function memfokuskan pada apa yang bisa
dilakukan
sistem untuk
membantu
actor
dalam pekerjaan
mereka.
Hasil
dari
kegiatan function adalah daftar dari function (function list) yang
lengkap,
yang
merinci function-function yang kompleks. Function list dibuat berdasarkan use
case description.
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:
o
Update
Function ini disebabkan oleh event problem-domain dan
menghasilkan
perubahan dalam state atau keadaan dari model tersebut.
|
|
44
o
Signal
Function ini disebabkan oleh perubahan keadaan atau state dari
model
yang dapat menghasilkan reaksi pada konteks.
o
Read
Function ini disebabkan oleh kebutuhan informasi dalam pekerjaan
actor dan mengakibatkan sistem
menampilkan bagian yang
berhubungan dengan informasi dalam model.
o
Compute
Function ini disebabkan oleh kebutuhan informasi dalam pekerjaan
actor dan berisi perhitungan yang melibatkan informasi yang disediakan
oleh actor atau model, hasil dari function ini adalah tampilan dari hasil
komputasi.
3) Interface
Interface digunakan
oleh
aktor
untuk
berinteraksi
dengan
sistem.
Mathiassen et al (2000, p151) menyatakan, “Interface is a facilities that make a
system’s
model
and
functions
available
to
actor.”
Dapat
diartikan Interface
adalah
suatu
fasilitas
yang
membuat
suatu
sistem model
dan
fungsi-fungsi
tersedia bagi
aktor.
Adanya interface memungkinkan actor
untuk berinteraksi
dengan sistem. Dari interface ini dapat dibuatlah navigation diagram yang
berisi interface-interface sistem perusahaan dari awal login hingga logout.
|
 45
2.4.3.3 Architectural Design
Berdasarkan Mathiassen et al (2000, p173) keberhasilan suatu sistem
ditentukan dari kekuatan desain arsitekturalnya. Arsitektur membentuk sistem
yang
sesuai
dengan
sistem tersebut
dengan
memenuhi
kriteria
desain
tertentu.
Arsitektur berfungsi sebagai kerangka untuk pengembangan selanjutnya.
Desain
arsitektur sangat
iterative. Aktivitas-aktivitas dalam desain arsitektur
adalah sebagai berikut:
1) Criteria
Criteria adalah suatu prioritas
dari
arsitektur
(Mathiassen
et
al, 2000,
p176). Tujuan aktivitas criteria adalah
untuk
menentukan prioritas dari sebuah
perancangan. Hasil yang diperoleh dari tahap ini adalah kumpulan criteria
untuk perancangan yang telah diprioritaskan.
Tabel 2.2 Tabel Kriteria Klasik untuk mengukur kualitas software
(Mathiassen et al, 2000, p178)
CRITERIA
PENGUKURAN DARI
Usable
Kemampuan
adapatasi
sistem
terhadap
konteks organisasi, berhubungan dengan kerja
dan teknikal.
Secure
Suatu pencegahan melawan akses
yang tidak
terotorisasi terhadap data dan fasilitas-fasilitas
yang ada.
Efficient
Eksploitasi
yang
ekonomis terhadap
fasilitas
technical platform.
Correct
Pemenuhan terhadap persyaratan-persyaratan.
|
 46
Reliable
Pemenuhan
terhadap
ketelitian
yang
dibutuhkan dalam eksekusi fungsi.
Maintanable
Besarnya
usaha
atau
biaya
untuk
menempatkan dan memperbaiki kecacatan
sistem.
Testable
Besarnya usaha atau biaya untuk memastikan
bahwa
sistem yang
dikembangkan
menjalankan fungsi-fungsi yang
dimaksudkan.
Flexible
Besarnya
usaha
atau
biaya
untuk
memodifikasi sistem yang dikembangkan.
Comprehensible
Usaha yang dibutuhkan untuk mendapatkan
pengertian yang logis terhadap sistem.
Reusable
Potensi
penggunaan
bagian-bagian
sistem
dalam sistem lain yang terhubung.
Portable
Besarnya usaha untuk memindahkan sistem
ke technical platform lainnya.
Interoperable
Besarnya usaha
untuk
menggabungkan suatu
sistem ke sistem lain.
2) Component Architecture
Component
Architecture
adalah
struktur
sistem yang
terdiri
dari
komponen yang saling berhubungan. Component adalah kumpulan dari bagian-
bagian
program yang
membentuk
sistem dan
memiliki tanggung jawab
yang
telah didefinisikan dengan jelas (Mathiassen et al, 2000, p190).
Component
Architecture
membuat
sistem lebih
mudah
dimengerti,
menyederhanakan desain dan mencerminkan kestabilan sistem. Hasil dari suatu
|
 47
component
architecture
adalah
component
diagram
yang
menunjukkan
hubungan antara komponen (dalam hal ini adalah server dan beberapa client).
Menurut
Mathiassen
et
al
(
2000, pp193-198),
terdapat
beberapa
pola
umum
yang dapat
digunakan
untuk
mendesain
suatu component
architecture
yaitu :
• The Layered Architecture Pattern
Dalam bentuk yang sederhana, arsitektur ini terdiri dari beberapa component
yang didesain sebagai layers. Desain dari setiap component menggambarkan
tanggung
jawabnya
masing-masing serta
interfacenya
ke
arah
atas
maupun
ke arah bawah.
Gambar 2.10 Layered Architecture Pattern
(Mathiassen et al, 2000, p193)
• The Generic Architecture Pattern
Model komponen
mengandung
model dari sistem object, yang dapat berupa
layer yang paling bawah, kemudian diikuti dengan layer sistem function, dan
yang paling atas merupakan component interface. Layer interface dapat
|
 48
dibagi
menjadi
dua
bagian
yang
terpisah
yaitu user
interface
dan
system
interface.
Gambar 2.11 The Generic Architecture Pattern
(Mathiassen et al, 2000, p196)
• The Client Server Architecture Pattern
Pola arsitektur client-server sebenarnya dikembangkan untuk menangani
distribusi
dari
sistem diantara
beberapa
processors
yang
tersebar
secara
geografis. Komponen dari arsitektur ini adalah 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. Client
bertanggung
jawab
untuk
menyediakan
interface
lokal
bagi
para user
(Mathiassen et al, 2000, p197).
|
 49
Gambar 2.12 The Client-Server Architecture Pattern
( Mathiassen et al, 2000, p197)
Pada
dasarnya
ada
2
metode
yang berbeda
untuk
memisahkan
komponen
client
dan server:
client
dan
server
dapat
dipandang
sebagai
subsistem
individual dengan
model,
function
dan
interface
nya
sendiri
atau
dapat
dipandang sebagai layer yang berbeda dalam suatu sistem tunggal.
Table 2.3 Berbagai bentuk distribusi dalam arsitektur client-server
(Mathiassen et al, 2000, p200)
Client
Server
Architecture
U
U+F+M
Distributed presentation
U
F+M
Local presentation
U+F
F+M
Distributed functionality
U+F
M
Centralized data
U+F+M
M
Distributed data
|
|
50
3) Process Architecture
Menurut Mathiassen et al (2000, p211), Process architecture adalah
sistem yang terdiri atau
tersusun dari proses
yang saling bergantungan. Untuk
mengeksekusi
atau
menjalankan
sebuah
sistem dibutuhkan
processor.
Processor adalah suatu bagian peralatan yang dapat mengeksekusi sebuah
program (Mathiassen
et
al,
2000,
pp211-212).
Arsitektur
proses
harus
dapat
memastikan
bahwa
sistem dapat
dijalankan
secara
memuaskan
dengan
menggunakan processor yang telah tersedia.
Tahap
ini
menentukan
bagaimana
suatu
proses
sistem didistribusi
dan
dikoordinasi. Tujuan dari tahap ini adalah untuk mendefinisikan struktur fisikal
dari suatu sistem.
Hasil
yang akan diperoleh berupa sebuah deployment
diagram.
Beberapa pola distribusi dalam kegiatan desain process architecture :
1)
Centralized pattern
Mengacu
pada
Mathiassen
et
al. (2000,
p215),
pada
pola
ini
semua
data
ditempatkan
pada
server
dan
client hanya
menghandle
user
interface saja.
Keseluruhan
model
dan
semua
fungsi
bergantung
pada
server,
dan client
hanya berperan seperti terminal.
2)
Distributed pattern
Mengacu pada Mathiassen et al. (2000,p217) pola ini merupakan kebalikan
dari
centralized pattern. Pada pola ini, semua didistribusikan kepada client
dan server hanya diperlukan untuk melakukan update model diantara client.
|
|
51
3)
Decentralized pattern
Mengacu pada Mathiassen et al. (2000, p219) pola ini dapat dikatakan
merupakan
gabungan
dari
kedua
pola
sebelumnya. Pada pola ini, client
mengimplementasikan
model
yang local,
sedangkan
servernya
memakai
model common (umum).
2.4.3.4 Component Design
Menurut Mathiassen et al. (2000,
p231-233), desain komponen bertujuan
untuk
menentukan
implementasi kebutuhan dalam kerangka arsitektural. Kegiatan
desain komponen bermula dari spesifikasi
arsitektural dan kebutuhan sistem,
sedangkan
hasil
dari kegiatan
ini
adalah spesifikasi dari
komponen
yang
saling
berhubungan. Aktivitas pada desain komponen :
1)
Model Component
Menurut Mathiassen et al. (2000, p236), komponen model adalah bagian
dari sistem yang
mengimplementasikan
model problem
domain.
Tujuan dari
komponen
model
adalah
untuk
mengirimkan data sekarang dan historic ke
function, interface dan pengguna dan sistem yang lain. Konsep
utama dalam
desain komponen model adalah struktur.
Hasil dari kegiatan komponen model adalah revisi dari class diagram dari
kegiatan analisis. Kegiatan revisi biasanya terdiri dari kegiatan menambahkan
kelas, attribute dan struktur baru yang mewakili event.
|
 52
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).
Tabel 2.4 Panduan dalam merepresentasikan private events
(Mathiassen et al, 2000, p241)
Event-event
yang
hanya terjadi pada
sequence dan
selection
• Representasikan
event-event
ini
sebagai
state
attribute
pada class yang digambarkan oleh
statechart diagram. Setiap kali ada salah satu dari
events
yang
terlibat
timbul,
maka
sistem akan
menugaskan nilai yang baru kepada state attribute
•
Integrasikan attribute
dari
event
yang terlibat
ke
dalam class
Event-event
yang
terjadi
berulang-
ulang (iteration)
•
Representasikan
event-event
ini
sebagai
suatu
class
baru, dan hubungkan
class tersebut dengan
class yang dijabarkan pada
statechart
diagram
dengan
menggunakan struktur aggregation.
Untuk
setiap
iterasi,
sistem akan
menghasilkan
suatu object baru dari class.
•
Integrasikan attribute
event ke
dalam
class
yang
baru.
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.
|
 53
Tabel 2.5 Panduan untuk merepresentasikan common events
(Mathiassen et al, 2000, p241)
Common Event
• Jika event yang terlibat dalam statechart diagram
dalam cara
yang
berbeda,
representasikan
event
tersebut
dalam hubungannya ke class yang
menawarkan representasikan paling sederhana.
• Jika event yang terlibat dalam statechart diagram
dalam
cara
yang
sama,
pertimbangkan
alternatif
representasi yang mungkin antara satu sama lain.
Untuk
menyederhanakan class
diagram
yang
telah
direvisi
dari
hasil
tahapan sebelumnya, dilakukan restrukturisasi class baik melalui generalization,
association, maupun embedded iteration.
2) Function Component
Menurut Mathiassen et al. (2000, p252), komponen function adalah
bagian dari sistem
yang
mengimplementasikan
kebutuhan
fungsional. Tujuan
dari
komponen
function
adalah
untuk
memberikan
akses
bagi
user
interface
dan komponen
sistem lainnya
ke
model, oleh
karena
itu komponen
function
adalah
penghubung
antara
model
dan usage.
Sedangkan
tujuan dari function
component
design
adalah
menentukan
implementasi functions.
Hasil
dari
kegiatan
ini
adalah
class
diagram dengan
operations
dan
spesifikasi
dari
operations yang kompleks.
|
|
54
Function didesain dan diimplementasikan dengan menggunakan operasi
dari kelas sistem.
Operasi adalah proses
yang
dispesifikasikan
dalam sebuah
class dan dijalankan melalui objek dari kelas tersebut
Sub kegiatan dalam component function akan
menghasilkan kumpulan
operasi yang dapat mengimplementasikan fungsi sistem
seperti yang
ditentukan dalam analisis problem domain dan function list.
Berikut adalah sub kegiatan dalam component function :
a)
Merancang function sebagai operation.
yaitu
mengidentifikasi
tipe
utama
dari
functions tersebut.
Ada
empat
tipe
functions
(Mathiassen et al,
2000,
pp255-260),
yaitu
:
Update,
Read,
Compute, dan Signal.
b)
Menelusuri
pola
yang
dapat
membantu
dalam
implementasi function
sebagai operation.
c)
Spesifikasikan operasi yang kompleks.
Menurut
Mathiassen
et
al
(2000, pp265-266)
ada
3
(tiga)
cara
untuk
melakukannya,
yaitu operation spesification, sequence
diagram, dan
statechart diagram.
3)
Connecting Component
Menurut Mathiassen et al. (2000, p271), Connecting component
digunakan
untuk
menghubungkan
komponen
–
komponen
sistem yang
akan
menghasilkan class
diagram dari komponen-komponen
tersebut.
Jadi
pada
aktivitas ini, hubungan antara komponen-komponen dirancang untuk
|
|
55
mendapatkan desain
yang
fleksibel dan comprehensible. Pada Connecting
component ada dua konsep yaitu :
•
Coupling adalah suatu ukuran yang digunakan untuk
menentukan
bagaimana
dekatnya
hubungan
antara
dua class atau
component.
(Mathiassen et al, 2000, p272).
•
Cohesion
merupakan
ukuran seberapa kuatnya keterikatan dari suatu class
atau component. (Mathiassen et al, 2000, p273)
Adapun
aktivitas
yang
terkait
dalam mendesain
koneksi
diantara
komponen adalah :
a
Menghubungkan class – class
b
Mengekslorasi polanya
c
Melakukan evaluasi terhadap koneksi yang ada
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 beguna ketika class definition sudah ada di dalam component
lain. Umumnya coupling-nya rendah, namun sulit mencapai cohesive.
• Class specialization, yaitu
menspesialisasikan public class dari component
lain.
• Operation call, yaitu
memanggil public operations di dalam object-object
dari
component
lain. Umumnya
coupling-nya
rendah
dan
cohesion-nya
tinggi.
|
|
56
2.4.4 Activity Diagram
Menurut Lethbridge dan Laganiere (2002, p284), an activity diagram is used
to understand the flow of work that an object or component perform, yang dapat
diterjemahkan bahwa sebuah activity diagram digunakan
untuk mengetahui aliran
kerja yang dilakukan oleh sebuah objek atau komponen.
|