bab 2 landasan teori - thesis.binus.ac.idthesis.binus.ac.id/doc/bab2/2008-1-00017-aksi bab...

59
8 BAB 2 LANDASAN TEORI 2.1 Pengertian Sistem Informasi Menurut Whitten, et al. ( 2001, p8 ) sistem informasi adalah susunan dari orang – orang, data, proses – proses, tampilan informasi, dan teknologi informasi yang saling berinteraksi untuk mendukung dan meningkatkan operasi sehari – hari dalam perusahaan bisnis dan juga mendukung pemecahan masalah serta pengambilan keputusan yang dibutuhkan oleh pihak manajemen dan para pengguna lainnya. Menurut Gelinas dan Dull ( 2005, p13 ) sistem informasi adalah sistem yang dibuat oleh manusia yang secara umum terdiri dari sekumpulan komponen – komponen berbasis komputer yang terintegrasi dan juga komponen - komponen manual yang dibentuk untuk mengumpulkan, menyimpan, dan mengatur data serta menyediakan output informasi untuk para penggunanya. Menurut Stair dan Reynolds ( 2006, p4 ) sistem informasi adalah sekumpulan komponen – komponen manual dan berbasis komputer yang saling berinteraksi yang mengumpulkan, memanipulasi, menyimpan, dan menyebarkan data dan informasi serta menyediakan mekanisme umpan balik untuk mencapai suatu tujuan. Jadi dapat ditarik kesimpulan bahwa sistem informasi adalah kumpulan komponen – komponen sumber daya perusahaan untuk mendukung rutinitas operasi perusahaan, menyediakan informasi yang dibutuhkan dan mendukung proses pengambilan keputusan perusahaan serta pemanfaataan umpan balik dalam menilai keberhasilan pencapaian suatu tujuan tertentu.

Upload: vandung

Post on 06-Mar-2019

212 views

Category:

Documents


0 download

TRANSCRIPT

8

BAB 2

LANDASAN TEORI

2.1 Pengertian Sistem Informasi

Menurut Whitten, et al. ( 2001, p8 ) sistem informasi adalah susunan dari orang –

orang, data, proses – proses, tampilan informasi, dan teknologi informasi yang saling

berinteraksi untuk mendukung dan meningkatkan operasi sehari – hari dalam perusahaan

bisnis dan juga mendukung pemecahan masalah serta pengambilan keputusan yang

dibutuhkan oleh pihak manajemen dan para pengguna lainnya.

Menurut Gelinas dan Dull ( 2005, p13 ) sistem informasi adalah sistem yang dibuat

oleh manusia yang secara umum terdiri dari sekumpulan komponen – komponen

berbasis komputer yang terintegrasi dan juga komponen - komponen manual yang

dibentuk untuk mengumpulkan, menyimpan, dan mengatur data serta menyediakan

output informasi untuk para penggunanya.

Menurut Stair dan Reynolds ( 2006, p4 ) sistem informasi adalah sekumpulan

komponen – komponen manual dan berbasis komputer yang saling berinteraksi yang

mengumpulkan, memanipulasi, menyimpan, dan menyebarkan data dan informasi serta

menyediakan mekanisme umpan balik untuk mencapai suatu tujuan.

Jadi dapat ditarik kesimpulan bahwa sistem informasi adalah kumpulan komponen

– komponen sumber daya perusahaan untuk mendukung rutinitas operasi perusahaan,

menyediakan informasi yang dibutuhkan dan mendukung proses pengambilan keputusan

perusahaan serta pemanfaataan umpan balik dalam menilai keberhasilan pencapaian

suatu tujuan tertentu.

9

2.2 Pengertian Sistem Informasi Akuntansi

Menurut Wilkinson, et al. ( 2000, p7 ) sistem informasi akuntansi adalah kesatuan

struktur dalam sebuah entitas, misalnya sebuah perusahaan bisnis, yang menggunakan

sumber daya – sumber daya fisik dan komponen – komponen lainnya untuk mengubah

data ekonomi menjadi informasi akuntansi, dengan tujuan untuk memenuhi kebutuhan

informasi dari berbagai penggunanya.

Menurut Gelinas dan Dull ( 2005, p14 ) sistem informasi akuntansi adalah

subsistem dari sistem informasi yang bertujuan untuk mengumpulkan, memproses dan

melaporkan informasi yang berhubungan dengan aspek keuangan dari suatu kejadian

bisnis.

Menurut Boockholdt ( 1999, p1 ) sistem informasi akuntansi menganalisa

bagaimana kejadian – kejadian yang mempengaruhi sebuah organisasi dicatat, diringkas

dan dilaporkan. Kejadian dicatat menggunakan sistem organisasi berupa sumber daya

manusia dan komputer, diringkas menggunakan metode dan tujuan akuntansi, dan

dilaporkan sebagai informasi kepada pihak internal dan eksternal organisasi.

Jadi dapat ditarik kesimpulan bahwa sistem informasi akuntansi adalah kumpulan

sumber daya manusia dan komputer yang digunakan untuk memproses data keuangan

menjadi informasi keuangan, informasi akuntansi dan informasi lainnya untuk

memenuhi kebutuhan pengguna internal maupun eksternal perusahaan.

2.3 Sistem Informasi Akuntansi Pembelian dan Persediaan

2.3.1 Sistem Informasi Akuntansi Pembelian

Menurut Gelinas dan Dull ( 2005, p420 ) proses pembelian adalah sebuah

10

struktur interaksi antara orang – orang, peralatan, metode – metode dan

pengendalian ( kontrol ) yang didesain untuk mencapai fungsi – fungsi utama

berikut :

- menangani rutinitas pekerjaan yang berulang – ulang dari departemen

pembelian dan departemen penerimaan

- mendukung kebutuhan pengambilan keputusan dari orang – orang yang

mengatur departemen pembelian dan penerimaan

- membantu dalam penyiapan laporan internal dan eksternal

Menurut Wilkinson, et al. ( 2000, p45 ) siklus pengeluaran ( expenditure

cycle ) terdiri dari dua kejadian bisnis atau transaksi bisnis utama yakni pembelian

dan pengeluaran kas. Transaksi pembelian mencakup perolehan sumber daya

ataupun jasa.

Menurut Wilkinson, et al. ( 2000, p133 ) kejadian bisnis, dokumen dan file

akuntansi dalam siklus pengeluaran adalah seperti ditunjukkan dalam tabel 2.1

berikut:

Kejadian bisnis Dokumen dan laporan File akuntansi utama-Permintaan produk atau

jasa yang dibutuhkan-Pemesanan produk atau

jasa-Penerimaan produk atau

jasa-Posting ke Account Payable

-Pengeluaran kas

-Purchase requisition-Purchase order-Supplier’s invoice-Disbursement voucher-Check voucher-Cash disbursement Report

-Purchase journal-Cash disbursement journal

-Account payable master file

Tabel 2.1 Siklus Pengeluaran( Sumber : Wilkinson, et al., 2000, p133 )

Menurut Romney dan Steinbart ( 2003, p415-416 ) siklus pengeluaran (

expenditure cycle ) adalah sekumpulan aktivitas – aktivitas bisnis dan pemrosesan

11

data yang berhubungan dengan pembelian dan pembayaran barang dan jasa. Tiga

aktivitas bisnis dasar dalam siklus ini adalah :

1. memesan barang, perlengkapan, dan jasa

2. menerima dan menyimpan barang, perlengkapan, dan jasa

3. membayar barang, perlengkapan, dan jasa

Dengan demikian, pembelian merupakan bagian dari siklus pengeluaran (

expenditure cycle ) yang melibatkan aktivitas pemilihan pemasok, pemesanan

barang atau jasa, penerimaan barang atau jasa dan penyimpanan barang.

2.3.1.1 Unit yang terkait

Menurut Wilkinson, et al. ( 2000 ) unit yang terkait dengan siklus

pembelian adalah :

1. inventory management / logistics

Dalam perusahaan dagang, tujuan dari fungsi ini adalah untuk mengatur

persediaan barang dagang yang perusahaan peroleh untuk dijual

kembali. Inventory management juga mencakup pembelian, penerimaan

dan penyimpanan. Pembelian secara utama berfokus pada pemilihan

pemasok yang paling tepat untuk memesan barang dan jasa. Pemilihan

pemasok didasarkan pada faktor – faktor seperti harga unit untuk barang

atau jasa, kualitas barang atau jasa, syarat dan tanggal pengiriman yang

dijanjikan, dan juga kehandalan dari pemasok. Bersama dengan

pengendalian persediaan ( yang berada dibawah fungsi akuntansi ),

pembelian menjamin kuantitas barang yang akan diterima. Bagian

Penerimaan memiliki tanggung jawab untuk hanya menerima barang

12

yang dipesan, menverifikasi kuantitas dan kondisinya, dan

memindahkan barang ke gudang. Bagian Penyimpanan memiliki

tanggung jawab untuk menjaga barang dari pencurian, kehilangan dan

pengrusakan dan menyiapkannya dengan tepat waktu ketika terdapat

permintaan atas barang tersebut.

2. finance / accounting

Dalam hubungannya dengan siklus pembelian, fungsi ini bertugas dalam

hal perencanaan dan pengendalian kas perusahaan, mengatur data yang

berkaitan dengan pembelian dan akun pemasok, pengendalian

persediaan, dan informasi yang berkaitan dengan kas, pembelian dan

pemasok. Bagian inventory control memelihara catatan saldo

persediaan dan menginisiasi pemesanan kembali barang dagang.

2.3.1.2 Dokumen yang Terkait

Menurut Wilkinson, et al. ( 2000, p472 ) dokumen yang

digunakan dalam sistem informasi akuntansi pembelian adalah :

- purchase requisition

merupakan dokumen pertama dalam siklus pembelian yang

mengotorisasi pemesanan barang atau jasa

- purchase order

merupakan dokumen yang berbentuk formal dan berangkap yang

dipersiapkan setelah adanya purchase requisition yang mengikat bagi

perusahaan pembeli.

- receiving report

13

merupakan dokumen yang mencatat penerimaan barang

- supplier’s ( vendor’s ) invoice

merupakan dokumen penagihan dari pemasok yang menyediakan barang

dan jasa bagi perusahaan.

- disbursement voucher

merupakan dokumen dalam sistem voucher yang mengakumulasi

invoice dari pemasok untuk keperluan pembayaran.

- disbursement check

merupakan dokumen yang menyediakan pembayaran kepada pemasok

atas barang atau jasa

- debit memorandum

merupakan dokumen yang mengotorisasi retur pembelian

- new supplier ( vendor ) form

merupakan dokumen yang digunakan dalam pemilihan pemasok baru,

yang menunjukkan data seperti harga, tipe barang atau jasa yang

disediakan, pengalaman, status kredit dan referensi pihak lain.

- request for proposal ( atau quotation )

merupakan dokumen yang digunakan dalam prosedur penawaran

diantara para pemasok yang bersaing, yang menunjukkan barang atau

jasa yang dibutuhkan dan perbandingan harga, syarat dan sebagainya.

2.3.1.3 Laporan yang dihasilkan

Menurut Wilkinson, et al. ( 2000, p487-493 ) output informasi

yang dihasilkan dari siklus expenditure ( siklus pembelian ) adalah :

14

1. Laporan dan daftar operasional

- invoice atau voucher register

merupakan daftar invoice yang diterima dari pemasok atau daftar

voucher yang disiapkan dari faktur

- check register

merupakan daftar semua cek yang telah ditulis

- open purchase order report

merupakan laporan yang menunjukkan semua pembelian yang

dimana invoice yang terkait belum disetujui untuk pembayaran

- open invoice report atau open payable report atau cash requirements

report

merupakan daftar semua invoice yang telah disetujui tetapi belum

dibayar

- inventory status report

merupakan laporan yang memuat kuantitas barang yang diterima,

kuantitas barang yang sedang dikirimkan dan kuantitas ditangan

- overdue deliveries report

merupakan laporan yang memuat transaksi pembelian yang telah

melewati waktu pengiriman barang yang diinginkan perusahaan dari

pemasok

2. inquiry display screens

merupakan layar yang menampilkan informasi yang diminta seperti :

- status dari order pembelian tertentu

- invoice untuk pemasok tertentu

15

- summary atas open purchase order

3. scheduled managerial reports

- payables aging report

merupakan laporan yang menggambaran status invoice atau voucher

yang belum dibayar yang dapat disebabkan karena masalah atau

pertanyaan dengan pemasok yang belum terselesaikan

- purchase analysis

merupakan laporan yang menggambarkan tingkat aktivitas

pembelian untuk setiap pemasok, setiap item persediaan dan setiap

pihak peminta barang ( internal perusahaan )

- vendor performance report

merupakan laporan yang menggambarkan kinerja pemasok dalam

bentuk pengiriman tepat waktu, kualitas barang, harga unit barang,

tingkat pelayanan, dan kondisi barang yang dikirim pemasok

- critical factors report

merupakan laporan yang memuat ukuran – ukuran kinerja seperti

jumlah potongan pembelian yang terlewatkan.

4. demand managerial reports

merupakan laporan – laporan yang tidak terjadwal yang berisi informasi

yang digunakan untuk pengambilan keputusan dan pengendalian

manajerial

2.3.2 Sistem Informasi Akuntansi Persediaan

Menurut Standar Akuntansi Keuangan ( 2004, SAK No. 14.1 ) persediaan

16

adalah “ aktiva tersedia untuk dijual dalam kegiatan usaha normal; dalam proses

produksi dan atau dalam perjalanan; atau dalam bentuk bahan atau perlengkapan (

supplies ) untuk digunakan dalam proses produksi atau pemberian jasa.

…Persediaan meliputi barang yang dibeli dan disimpan untuk dijual kembali. …

Persediaan juga mencakupi barang jadi yang telah diproduksi, atau barang dalam

penyelesaian yang sedang diproduksi perusahaan, dan termasuk bahan serta

perlengkapan yang digunakan dalam proses produksi.”

Menurut Horngren, et al. ( 2002, p167 ) persediaan mencakup semua barang

yang dimiliki oleh perusahaan dan yang diharapkan untuk terjual dalam operasi

normal perusahaan.

Menurut Boockholdt ( 1999, p523 ) siklus konversi mencakup transaksi –

transaksi yang terjadi ketika input diubah ( dikonversi ) menjadi barang atau jasa

yang dapat dijual. Gambar 2.1 menunjukkan siklus konversi dalam perusahaan

dagang.

17

Expenditure Cycle Revenue Cycle

Gambar 2.1 Siklus Konversi dalam Perusahaan Dagang( Sumber : Boockholdt, 1999, p524 )

Menurut Boockholdt ( 1999, p653-654 ) sistem persediaan bertujuan untuk

memelihara catatan persediaan dan untuk menginformasikan kepada manajer ketika

tingkat persediaan tertentu perlu diisi atau dipenuhi kembali. Sistem persediaan

terdapat dalam perusahaan dagang dan manufaktur.

Sistem persediaan memproses dua macam transaksi sebagai berikut :

1. Pembelian persediaan

Entry yang dilakukan untuk mencatat transaksi ini tergantung pada metode

yang digunakan untuk akuntansi persediaan. Terdapat dua metode yaitu metode

periodik dan metode perpetual.

- metode periodik

Merchandise Inventory

Receiving System

Shipping System

PayrollSystem

InventorySystem

18

perusahaan yang menggunakan metode ini tidak memelihara catatan

jumlah persediaan di tangan secara terus – menerus. Perusahaan

menentukan nilai persediaan awal dan akhir dengan perhitungan fisik.

- metode perpetual

perusahaan yang menggunakan metode ini memelihara jumlah persediaan

ditangan secara terus – menerus. Perusahaan manufaktur menggunakan

metode ini karena perusahaan perlu untuk mengetahui apakah persediaan

yang terdapat di tangan sudah mencukupi untuk proses manufaktur

perusahaan.

2. Penjualan Persediaan

Perusahaan mencatat cost of inventory yang terjual dalam akun buku besar yang

berjudul cost of goods sold. Dengan metode periodik, tidak ada entry yang

dilakukan pada saat penjualan. Cost of goods sold ditentukan dengan

menambah jumlah pembelian dengan nilai persediaan awal. Dengan metode

perpetual, perusahaan mencatat penjualan dengan mengkredit akun persediaan

dan mendebit cost of goods sold.

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

19

Yaitu persediaan barang berwujud yang digunakan dalam proses

produksi.

2. persediaan komponen-komponen rakitan

Yaitu persediaan barang-barang yang terdiri dari komponen-komponen

yang diperoleh dari perusahaan lain, di mana secara langsung dapat

dirakit menjadi suatu produk.

3. persediaan bahan baku

Yaitu persediaan barang-barang yang diperlukan dalam proses produksi,

tetapi tidak merupakan bagian barang jadi.

4. persediaan barang dalam proses

Yaitu persediaan barang yang merupakan keluaran dari tiap-tiap bagian

dalam proses produksi atau yang diolah menjadi suatu bentuk.

5. persediaan barang jadi

Yaitu persediaan barang-barang yang telah selesai diproses atau diolah.

Metode Penilaian Persediaan

Menurut Weygandt, Kieso, dan Kimel (2005, p236-238) dalam

menilai persediaan, metode yang digunakan yaitu:

1. Metode FIFO ( First In First Out )

FIFO adalah metode penetapan harga pokok persediaan, di mana

dianggap bahwa barang-barang yang pertama kali dibeli akan merupakan

barang yang dijual pertama kali. Dalam metode ini, persediaan akhir

dinilai dengan harga pokok pembelian paling akhir.

2. Metode LIFO ( Last In First Out )

20

LIFO adalah metode penetapan harga pokok persediaan di mana

dianggap bahwa barang-barang yang paling akhir dibeli akan merupakan

barang yang dijual pertama kali. Dalam metode ini, persediaan akhir

dinilai dengan harga pokok pembelian terdahulu.

3. Metode rata-rata (Average)

Rata-rata adalah metode penetapan harga pokok persediaan di mana

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.

Laporan yang Terkait

Menurut Boockholdt ( 1999, p655-656 ) macam – macam

laporan yang dihasilkan dari sistem persediaan adalah sebagai berikut :

1. Inventory status report

merupakan laporan yang mendaftarkan semua item atau jenis persediaan,

kuantitas persediaan ditangan, dan biaya persediaan.

2. Query inventory items report

merupakan laporan yang dapat berupa tercetak atau ditampilkan pada

komputer. Pada sistem online real-time, karyawan dapat menggunakan

laporan ini untuk mengetahui jumlah persediaan ditangan pada saat query

( permintaan ) data dilakukan.

3. Reorder report

merupakan laporan yang mengidentifikasi jenis – jenis persediaan yang

harus diisi kembali. Ketika jumlah persediaan ditangan menurun

21

mencapai reorder point ( titik pemesanan kembali ), sistem pengendalian

persediaan harus menunjukkan jenis persediaan tersebut dalam laporan

ini.

4. Physical inventory report

perusahaan secara periodik melakukan perhitungan fisik atas jumlah

setiap persediaan yang ada ditangan. Proses ini menghasilkan

perhitungan cost of goods sold ketika metode periodik digunakan.

Dengan metode perpetual , proses ini memampukan perusahaan

memperbaiki kesalahan dalam catatan persediaan.

2.4 Pengendalian Internal

2.4.1 Pengertian

Committee of Sponsoring Organizations ( COSO ) ( Gelinas dan Dull, 2005,

p216 ) mendefinisikan pengendalian internal ( internal control ) sebagai sebuah

proses, yang dipengaruhi oleh dewan direksi, manajemen, dan personal lainnya

dalam suatu entitas, yang dirancang untuk menyediakan jaminan atau keyakinan

yang layak atau memadai sehubungan dengan pencapaian tujuan - tujuan dalam

kategori berikut :

- efektivitas dan efisiensi operasi

- kehandalan laporan keuangan

- kesesuaian dengan hukum dan peraturan yang berlaku

22

2.4.2 Komponen – Komponen

Committee of Sponsoring Organizations ( COSO ) ( Gelinas dan Dull, 2005,

p216-217 ) mengidentifikasikan lima komponen pengendalian yang saling

berhubungan sebagai berikut :

1. Control environment

merupakan komponen yang membentuk suasana suatu organisasi, yang

mempengaruhi kesadaran akan pengendalian dari orang – orangnya.

Lingkungan pengendalian adalah sebagai dasar untuk semua komponen –

komponen pengendalian internal lainnya dengan menyediakan disiplin dan

struktur.

2. Risk assessment

merupakan pengidentifikasian dan analisa oleh entitas atas resiko – resiko

relevan untuk pencapaian tujuan – tujuannya, yang membentuk dasar untuk

menentukan bagaimana resiko sebaiknya dikelola.

3. Control activities

merupakan kebijakan dan prosedur yang membantu dalam menjamin bahwa

perintah manajemen telah dilaksanakan.

4. Information and communication

merupakan identifikasi, penangkapan, dan pertukaran informasi dalam suatu

bentuk dan kerangka waktu yang memungkinkan orang – orang mampu

melaksanakan tanggung jawabnya.

5. Monitoring

merupakan suatu proses yang menilai kualitas kinerja pengendalian internal

pada suatu waktu.

23

Gambar 2.2 menunjukkan komponen dan pertimbangan utama atas struktur

pengendalian internal :

Struktur Pengendalian Internal

ControlEnvironment

RiskAssesment Control Activities Information and

CommunicationMonitoring

subkomponen :

- filosofi dan gaya operasimanajemen

- integritas dan nilai etika- komitmen terhadap

- dewan direksi dan

- struktur organisasi

- penetapan wewenangdan tanggung jawab

- kebijakan dan praktiksumber daya manusia

kompetensi

komite audit

pertimbangan utama :

- identifikasi resiko internalyang signifikan

- identifikasi resiko externalyang signifikan

- menyiapkan analisaresiko

- manajemen resiko yangrelevan

pertimbangan utama :

- identifikasi dan perolehaninformasi yang relevandengan pelaporan keuangan

- komunikasi informasiyang relevan dalamformat yang tepat

pertimbangan

- aktivitas yangterus menerus

- evaluasi

utama :

secara terpisah

aktivitas yangberhubungan denganpelaporan keuangan

aktivitas yangberhubungan denganpemrosesan informasi

generalcontrol

applicationcontrol

subkomponen :

- desain dokumen yang baikdan dokumen serta recordbernomor urut

- pemisahan tugas- otorisasi transaksi- ukuran keamanandan perlindungan yang cukup

- pengecekan kinerjasecara independen

- pemeriksaan tepatatas jumlah tercatat

Gambar 2.2 Komponen dan Pertimbangan Utama Struktur Pengendalian Internal ( Sumber : Wilkinson, et al., 2000, p236 )

2.4.3 Tujuan Pengendalian

Menurut Gelinas dan Dull ( 2005, p230 ), tujuan pengendalian meliputi hal

– hal seperti dalam tabel 2.2 berikut ini.

24

Tujuan Pengendalian DefinisiTujuan Pengendalian dari Proses Operasi

Menjamin efektivitas operasi dengan mencapai tujuan – tujuan yang telah ditetapkan atas proses operasi

Efektivitas : suatu ukuran sukses dalam mencapai satu atau beberapa tujuan dari proses operasi

Menjamin pemanfaatan yang efisien atas sumber daya ( misalnya sumber daya manusia, komputer )

Efisiensi : suatu ukuran atas produktivitas pemakaian sumber daya untuk mencapai tujuan

Menjamin keamanan sumber daya ( misalnya kas, data, persediaan )

Keamanan sumber daya : menjaga sumber daya organisasi dari kehilangan, pengrusakan, disclosure, pengkopian, penjualan dan penggunaan tidak benar lainnya.

Tujuan Pengendalian dari Pemrosesan InformasiMenjamin validitas input Validitas input : data input disetujui

secara tepat dan menggambarkan kejadian ekonomi dan objek yang sebenarnya

Menjamin kelengkapan input Kelengkapan input : semua kejadian atau objek yang valid ditangkap dan dimasukkan ke dalam sistem

Menjamin keakuratan input Akurasi input : semua kejadian yang validharus secara benar ditangkap dan dimasukkan dalam sistem

Menjamin kelengkapan update Kelengkapan update : semua kejadian yang dimasukkan dalam sistem harus terefleksikan dalam master data ( data induk )

Menjamin keakuratan update Keakuratan update : data yang dimasukkan dalam sistem harus terefleksikan secara benar dalam master data ( data induk )

Tabel 2.2 Tujuan Pengendalian( Sumber Gelinas dan Dull, 2005, p230 )

25

2.4.4 Pengendalian Internal dalam Pembelian dan Persediaan

2.4.4.1 Tujuan Pengendalian Internal Pembelian dan Persediaan

Menurut Wilkinson, et al. ( 2000, p498 ), tujuan pengendalian

dalam siklus pengeluaran ( pembelian dan persediaan ) adalah sebagai

berikut :

- semua pembelian diotorisasi atas dasar waktu ketika dibutuhkan dan atas

dasar perhitungan economic order quantity.

- semua barang yang diterima diverifikasi untuk menentukan bahwa

kuantitasnya sesuai dengan yang dipesan dan dalam kondisi yang baik.

- semua jasa diotorisasi sebelum diterima dan dimonitor untuk menjamin

bahwa jasa dilakukan dengan benar

- semua faktur dari pemasok di verifikasi berdasarkan waktu dan sesuai

dengan barang atau jasa yang diterima

- semua diskon pembelian diidentifikasi sehingga potongan tersebut dapat

dimanfaatkan jika secara ekonomi menguntungkan.

- semua retur pembelian diotorisasi dan dicatat secara akurat dan

berdasarkan pengembalian barang yang aktual

- semua pengeluaran kas dicatat secara lengkap dan akurat

- semua transaksi pembelian kredit dan pengeluaran kas di posting ke akun

pemasok yang tepat dalam buku besar hutang dagang

- semua catatan akuntansi dan persediaan barang dagang terlindungi

26

2.4.4.2 Unsur Pengendalian Internal

Menurut Wilkinson, et al. ( 2000, p500-504 ), komponen control

activities dalam siklus pembelian dan persediaan adalah :

1. pengendalian umum

a. pengendalian organisasi

pemisahan bagian gudang dan penerimaan dengan bagian yang

melakukan pencatatan ( inventory control, account payable, general

ledger, dan data processing ).

b. pengendalian dokumentasi

dokumentasi yang harus lengkap dan up-to-date termasuk rangkap

dokumen, flowcharts, record, dan laporan – laporan terkait.

c. pengendalian pertanggung jawaban aset

catatan atau record atas persediaan barang dagang harus dipelihara

dalam buku besar, dengan kuantitas ditangan yang tercatat harus

direkonsiliasi dengan perhitungan fisik persediaan secara periodik.

d. pengendalian praktik manajemen

Karyawan termasuk programer dan akuntan harus mendapat

pelatihan. Pengembangan dan perubahan sistem harus sesuai

dengan prosedur yang jelas, audit atas kebijakan dan prosedur

pembelian dan pengeluaran kas, serta manajer harus melakukan

review atas analisa periodik, control summaries dan laporan –

laporan lainnya.

e. pengendalian operasi pusat data ( data center operations )

27

jadwal pemrosesan batch – batch data yang harus jelas. Personel

akuntansi dan sistem informasi diawasi dan hasil kerja mereka

direview dengan bantuan computer processing control reports (

laporan pengendalian yang diproses komputer ) dan access log (

catatan akses yang pernah dilakukan ).

f. pengendalian otorisasi

Semua transaksi pembelian harus diotorisasi oleh manajer yang

berwenang biasanya oleh inventory manager.

g. pengendalian akses

- penggunaan password untuk mengakses file – file account

payable dan data – data pemasok

- terminal terbatas hanya untuk transaksi pembelian dan

pengeluaran kas

- log atas semua transaksi

- backup data

- perlindungan atas gudang penyimpanan persediaan

- log atas semua akses ke data

2. pengendalian aplikasi

a. pengendalian input

- menyiapkan dokumen yang didesain dengan baik dan bernomor

urut atas pembelian, penerimaan, hutang, dan pengeluaran kas

serta otorisasi dokumen tersebut

- validasi data order pembelian dan laporan penerimaan pada saat

data tersebut dipersiapkan dan dientry untuk diproses.

28

- memperbaiki error yang terdeteksi selama data entry dan sebelum

data diposting ke catatan pemasok dan persediaan.

- menghitung jumlah total pada batch control atas data faktur

pemasok dan voucher yang telah jatuh tempo untuk pembayaran.

b. pengendalian pemrosesan

1. penerbitan permintaan pembelian, order pembelian,

disbursement voucher, cek dan memo debit sesuai otorisasi

2. verifikasi semua elemen data dan perhitungan dalam permintaan

pembelian dan order pembelian

3. menelusuri semua elemen data dan perhitungan dalam faktur

pemasok dan membandingkannya dengan order pembelian dan

laporan penerimaan

4. memonitor semua transaksi yang masih terbuka seperti

pengiriman barang yang belum sepenuhnya atau barang yang

ditolak

5. penerbitan memo debit sesuai persetujuan pejabat berwenang

6. merekonsiliasi akun pembantu hutang dagang dan beban dengan

akun pengendali dalam buku besar

7. menverifikasi total posting ke akun hutang dagang pada buku

pembantu dengan total posting ke buku besar.

8. memonitor syarat pembelian untuk menjamin bahwa potongan

pembelian dimanfaatkan, jika ekonomis.

9. mereview bukti – bukti yang mendukung validitas pengeluaran

dan kebenaran jumlahnya sebelum penandatanganan cek

29

10. menjamin bahwa jumlah dalam cek tidak akan diubah secara

tidak sah sebelum penandatanganan dilakukan

11. jumlah nominal cek yang melebihi jumlah tertentu harus

ditandatangani oleh manajer selanjutnya yang berwenang

12. verifikasi jumlah persediaan yang ada ditangan dengan

perhitungan fisik minimal sekali setahun, dan merekonsiliasi

jumlah hasil perhitungan dengan jumlah tercatat

13. menggunakan imprest system dalam pengeluaran kas kecil

14. membangun kebijakan pembelian dalam jumlah besar atau tidak

rutin dengan mengunakan penawaran yang bersaing dari para

pemasok ( bidding )

15. memperbaiki error yang terjadi selama tahap pemrosesan.

c. pengendalian output

1. membangun kebijakan pisah batas penerimaan persediaan dan

hutang dagang yang jelas, sehingga persediaan dan hutang

dagang dinilai secara wajar pada akhir periode akuntansi

2. membangun pengendalian anggaran atas pembelian

3. membandingkan laporan bulanan dari pemasok dengan

jumlah yang muncul dalam akun pemasok

4. menyimpan kopian semua dokumen pembelian dan

pengeluaran kas berdasarkan nomor urut dan dilakukan

pengecekan nomor urut tersebut secara periodik untuk

menemukan adanya gaps ( nomor yang hilang ).

30

5. mencetak daftar transaksi dan account summary secara

periodik untuk menyediakan jejak audit ( audit trail )

2.5 Metode Analisis dan Desain Berorientasi Objek

2.5.1 Pengertian

Menurut Mathiassen, et al. ( 2000, p3-4 ) analisis dan desain berorientasi

objek adalah sebuah metode yang menggunakan objek – objek dan class – class

sebagai konsep utamanya dan membentuk empat prinsip umum untuk analisis dan

desain, sebagai berikut :

1. membuat model dari konteks sistem

2. menekankan pada arsitektur sistem

3. menggunakan kembali model – model atau pola – pola yang

mengekspresikan ide – ide desain yang telah terbentuk dengan baik

4. menyesuaikan metode dengan setiap situasi pengembangan sistem

2.5.2 Aktivitas Utama

Menurut Mathiassen, et al. ( 2000, p15 ) aktivitas utama dan hasilnya

dalam analisa dan desain berorientasi objek ditunjukkan dalam gambar 2.3

berikut.

31

Problem-domainanalysis

Application-domainanalysis

Componentdesign

Architecturaldesign

Model

Requirements foruse

Specification ofcomponents

Specifications ofarchitecture

Gambar 2.3 Aktivitas Utama dan Hasilnya Dalam Analisa dan Desain Objek Berorientasi Objek

( Sumber Mathiassen, et al. , 2000, p15 )

2.5.3 System Definition

Menurut Mathiassen, et al.( 2000, p24 ) system definition adalah deskripsi

yang ringkas dari suatu sistem terkomputerisasi yang dinyatakan dalam bentuk

bahasa alami.

System definition mengekspresikan properti dasar untuk pengembangan

dan penggunaan sistem. System definition menggambarkan konteks sistem,

informasi apa yang harus dimiliki sistem, fungsi – fungsi apa saja yang harus

dimiliki, dimana sistem harus digunakan, dan kondisi pengembangan yang harus

diterapkan.

32

2.5.4 FACTOR Criterion

Menurut Mathiassen, et al.( 2000, p39-40 ) FACTOR Criterion terdiri dari

enam elemen sebagai berikut :

1. Functionality

merupakan fungsi – fungsi sistem yang mendukung tugas application domain.

2. Application domain

merupakan bagian – bagian dalam sebuah organisasi yang mengadministrasi,

memonitor, atau mengontrol problem domain.

3. Conditions

merupakan kondisi – kondisi dimana sistem akan dikembangkan dan

digunakan.

4. Technology

merupakan teknologi yang akan digunakan untuk mengembangkan dan

menjalankan sistem.

5. Objects

merupakan objek – objek utama dalam problem domain.

6. Responsibility

merupakan tanggung jawab sistem secara keseluruhan dalam hubungannya

dengan konteks sistem.

33

2.5.5 Rich Picture

Menurut Mahiassen, et al. ( 2000, p26-27 ) rich picture adalah sebuah

gambaran informal yang digunakan oleh pengembang sistem untuk menyatakan

pemahaman mereka terhadap situasi dari sistem yang sedang berlangsung.

Para pengembang sistem perlu memahami situasi masalah yang ada dengan

kerjasama yang erat dengan semua pihak yang terlibat dan khususnya dengan

pengguna sistem dimasa depan. Para pengguna tidak perlu menggambarkan rich

picture atau juga melihatnya. Rich picture merupakan alat utama untuk membantu

pengembang sistem mengorganisasikan secara jelas pemahaman mereka. Selain itu

rich picture adalah alat yang bermanfaat untuk mempermudah komunikasi dengan

para pengguna.

2.5.6 Analisis Problem Domain

Menurut Mathiassen, et al. ( 2000, p45 ) problem domain adalah bagian dari

sebuah konteks sistem yang di administrasi, dimonitor, atau dikontrol oleh sebuah

sistem. Analisa problem domain berfokuskan pada informasi apa yang harus

ditangani oleh sistem.

Analisa problem domain memiliki tiga aktivitas seperti ditunjukkan tabel

2.3 berikut :

34

Aktivitas Isi KonsepClass Objek dan event mana yang

merupakan bagian dari problem domain

Class, objek, dan event

Structure Bagaimana class dan objek saling berkaitan satu sama lain secara konseptual

Generalization, aggregation, association, dan cluster

Behaviour Properti dinamik mana yang dimiliki objek

Event trace, behavioural pattern, dan attribute

Tabel 2.3 Aktivitas dalam Analisa Problem Domain( Sumber Mathiassen, 2000, p48 )

2.5.6.1 Class

Menurut Mathiassen, et al. ( 2000 ) Objek adalah sebuah entitas

dengan identitas, status, dan perilaku ( behaviour ). Event adalah sebuah

kejadian yang terjadi seketika yang melibatkan satu atau lebih objek. Class

adalah sebuah deskripsi dari sekumpulan objek – objek yang memiliki

struktur, behavioural pattern, dan atribut.

Dalam analisa problem domain, sebuah objek merupakan

abstraksi dari sebuah fenomena dalam problem domain. Sebuah event

adalah sebuah abstraksi dari aktivitas atau proses dalam problem domain

yang dilakukan atau dialami oleh satu atau lebih objek. Class yang terpilih

akan menjadi pusat atau inti dari model problem domain.

Kegiatan Class ini akan menghasilkan sebuah Event Table seperti

yang terlihat pada tabel 2.4 dibawah ini. Dimensi horizontal berisi class –

class yang terpilih, dan dimensi vertikal berisi event – event yang terpilih.

Sebuah tanda cek digunakan untuk mengindikasikan bahwa objek – objek

dari class terlibat dalam event tertentu.

35

EventsClasses

Customer Assistant Apprentice Appointment PlanReserved Cancelled Treated

Employed Resigned

Graduated Agreed

Tabel 2.4 Contoh event table( Sumber : Mathiassen, et al. , 2000, p50 )

2.5.6.2 Structure

Menurut Mathiassen, et al. ( 2000 ) aktivitas structure bertujuan

untuk menggambarkan hubungan struktural antara class - class dan objek –

objek dalam sebuah problem domain. Dalam aktivitas ini, pengembang

sistem akan memodelkan hubungan yang abstrak dan umum antara class -

class dan hubungan yang konkrit dan spesifik antara objek – objek.

Menurut Mathiassen, et al. ( 2000 ) object – oriented structure

bisa dibagi menjadi :

1. Structure antara class

Struktur ini menggambarkan hubungan yang statis dan konseptual

antara class – class.

Structure antar class terdiri dari :

a. Generalization

Adalah hubungan antara dua atau lebih class yang lebih spesialisasi

( sub kelas ) dengan sebuah class yang lebih umum ( super kelas ).

Dimana hubungan spesialisasi tersebut dapat dinyatakan dengan

36

rumus “ is - a “. Struktur generalisasi menggambarkan pewarisan (

inheritance ) yakni specialized class ( kelas yang terspesialisasi )

mendapatkan properti dan behavioral pattern dari general class (

kelas umum ). Gambar 2.4 menunjukkan contoh generalisasi.

Person

Customer Employee

Gambar 2. 4 Generalization Structure( Sumber : Mathiassen, et al., 2000, p74 )

b. Cluster

Adalah kumpulan dari class – class yang berkaitan. Cluster

memberikan pemahaman atas problem domain dengan

memecahkan problem domain menjadi subdomain yang lebih kecil.

Notasi grafis yang digunakan adalah sebuah file folder yang

mencakup class – class didalamnya. Class – class dalam sebuah

cluster biasanya dihubungkan dengan generalization structure atau

dengan aggregation structure. Gambar 2.5 menunjukkan contoh

cluster.

37

<< cluster>>Cars

Car

TaxiCylinder

PassengerCarEngine

1*

1*

Gambar 2.5 Cluster Structure( Sumber : Mathiassen, et al., 2000, p75 )

2. Structure antara objek

Struktur ini menggambarkan hubungan yang dinamis antara objek –

objek dalam problem domain.

Struktur antar objek terdiri dari :

a. Aggregation

Adalah hubungan yang menggambarkan objek superior (

keseluruhan ) yang terdiri dari sejumlah objek inferior ( bagian ).

Hubungan ini dapat dinyatakan dengan rumus “ has - a “ atau “ is-

part-of “. Gambar 2.6 menunjukkan contoh agregasi.

Terdapat tiga struktur agregasi, yakni :

1. Whole-Part , yang mana objek superior merupakan penjumlahan

dari objek inferior; jika objek inferior tersebut ditambah atau

dihilangkan, akan mengubah total objek superior.

2. Container-Content, yang mana objek superior adalah container (

penampung ) untuk objek inferior. Objek superior tidak akan

38

berubah jika terjadi penambahan atau penghapusan objek

inferior.

3. Union-Member, yang mana objek superior merupakan kesatuan

dari anggota – anggota ( objek inferior ). Objek superior tidak

akan berubah jika terjadi penambahan atau penghapusan objek

inferior, namun tetap memiliki batasan.

1

1

1

4..*

Car

Body Engine W heel

1

1

Gambar 2.6 Aggregation Structure( Sumber : Mathiassen, et al., 2000, p76 )

b. Association

Adalah hubungan diantara sejumlah objek yang memiliki makna

tertentu. Hubungan ini dapat dinyatakan dengan rumus “knows“

atau “associated-with “. Gambar 2.7 menunjukkan contoh asosiasi.

Car Person

0..* 1..*

Gambar 2.7 Association Structure( Sumber : Mathiassen, et al., 2000, p77 )

Hasil akhir dari aktivitas structure ini adalah class diagram

dengan class dan struktur – strukturnya.

39

2.5.6.3 Behaviour

Menurut Mathiassen, et al. ( 2000 ) kegiatan behaviour adalah

kegiatan terakhir dalam analisa problem domain yang bertujuan untuk

memodelkan apa yang terjadi ( perilaku dinamis ) dalam problem domain

sistem sepanjang waktu. Tugas utama dalam kegiatan ini adalah

menggambarkan pola perilaku ( behavioural pattern ) dan atribut dari setiap

class.

Behaviour ( perilaku ) dari sebuah objek didefinisikan dengan

event trace yang menggambarkan urutan tertentu atas event – event

sepanjang waktu. Contoh event trace dari objek class ” Customer ” sebagai

berikut :

Account opened – amount deposited – amount withdrawn – amount

deposited – account closed.

Daripada menggambarkan behaviour untuk setiap objek dalam

problem domain, dapat digambarkan sebuah behavioural pattern untuk

semua objek dalam sebuah class. Behavioural pattern adalah sebuah

deskripsi dari semua event trace – event trace yang mungkin untuk semua

objek dalam sebuah class.

Terdapat tiga jenis notasi untuk behavioural pattern yaitu :

1. sequence, dimana event muncul satu per satu secara berurutan

2. selection, dimana hanya satu event yang akan terjadi dari sekelompok

event yang ada

3. iteration, dimana sebuah event muncul sebanyak nol atau beberapa kali

40

Hasil akhir dari kegiatan ini adalah statechart diagram seperti ditunjukkan

dalam gambar 2.8

-name-address-balance

Customer

Open

amount deposited( date, amount )

amount withdrawn( date, amount )

account opened (date )

account closed( date )

Gambar 2.8 Statechart Diagram untuk Class “ Customer “( Sumber : Mathiassen, et al., 2000, p90 )

2.5.7 Analisis Application Domain

Menurut Mathiassen, et al. ( 2000 ) application domain adalah sebuah

organisasi yang mengadministrasi, memonitor, atau mengontrol sebuah problem

domain. Tujuan dari analisis application domain adalah untuk menentukan

persyaratan penggunaan sistem ( system requirements ).

Aktivitas – aktivitas dalam analisis application domain ditunjukkan dalam

tabel 2.5 sebagai berikut :

41

Kegiatan Isi KonsepUsage Bagaimana sistem

berinteraksi dengan userdan dengan sistem lain dalam konteks?

Use case dan actor

Functions Bagaimana kemampuan sistem dalam memproses informasi ?

Function

Interface Apa kebutuhan atau persyaratan dari interfacesistem yang ditargetkan ?

Interface, user interface, dan system interface

Tabel 2.5 Aktivitas dalam Analisa Application Domain( Sumber : Mathiassen,et al., 2000, p117 )

2.5.7.1 Usage

Menurut Mathiassen, et al. ( 2000 ) usage adalah kegiatan yang

bertujuan untuk menentukan bagaimana actor berinteraksi dengan sebuah

sistem.

Actor adalah sebuah abstraksi dari para pengguna ( user ) atau

sistem lain yang berinteraksi dengan target sistem. Use case adalah sebuah

pola interaksi antara sistem dan actor dalam application domain.

Hasil akhir dari aktivitas ini adalah deskripsi dari semua use case

dan actor seperti ditunjukkan dalam gambar 2.9 sebagai berikut :

42

Autom aticPaym entSystem

payment

cash wi t hdrawal

money t r ansfer

account i nfor mat i on

cr edi t i nf ormat i on

r egi st r at i on

moni t or i ng

er r or cor r ect i on

Account owner

cr edi t or

Li qui di t y moni t or

Admi ni st r ator

Gambar 2.9 Use Case Diagram dari Automatic Payment System( Sumber : Mathiassen, et al., 2000, p122 )

2.5.7.2 Functions

Menurut Mathiassen, et al. ( 2000 ) kegiatan functions yang

merupakan kegiatan kedua dalam application domain bertujuan untuk

menentukan kemampuan sistem dalam pemrosesan informasi. Functions

berfokuskan pada apa yang dapat dilakukan oleh sistem untuk membantu

actor dalam menjalankan tugas – tugas mereka.

Function adalah sebuah fasilitas yang membuat sebuah model

menjadi bermanfaat bagi actor. Sebuah fungsi di aktifkan, dieksekusi dan

akan menyediakan hasil. Eksekusi fungsi dapat merubah status dari

komponen model atau membentuk suatu efek reaksi dalam application

43

domain atau problem domain. Fungsi direalisasi melalui operasi program (

program operations ).

Functions memiliki empat tipe yang berbeda yaitu :

1. update functions

adalah fungsi yang diaktifkan oleh sebuah event dalam problem domain

dan menghasilkan perubahan status model ( model’s state ).

2. signal functions

adalah fungsi yang diaktifkan karena adanya perubahan dalam status (

state ) model dan menghasilkan reaksi dalam konteks sistem. Reaksi ini

dapat berupa display untuk actor dalam application domain atau berupa

intervensi langsung dalam problem domain.

3. read functions

adalah fungsi yang diaktifkan karena adanya kebutuhan informasi dalam

tugas actor dan menghasilkan display berupa informasi mengenai

bagian – bagian yang relevan dari sebuah model.

4. compute functions

adalah fungsi yang diaktifkan karena adanya kebutuhan informasi dalam

tugas actor dan melibatkan perhitungan dengan menggunakan informasi

yang disediakan oleh actor ataupun dari model. Hasilnya adalah display

atas hasil perhitungan.

Cara untuk mengidentifikasikan function adalah dengan melihat

deskripsi problem domain yang ditampilkan oleh class dan event, dan

melihat deskripsi application domain yang ditampilkan dalam use case.

Class dapat menyebabkan munculnya function read dan update. Event

44

memungkinkan munculnya kebutuhan terhadap function update. Sementara

use case dapat menyebabkan munculnya semua jenis function.

Hasil akhir dari kegiatan functions adalah list of functions

dengan spesifikasi atas complex functions. Contoh function list dapat dilihat

pada tabel 2.6 berikut :

45

Function Kompleksitas Tipe

Make schedule Very complex Update

Calculate schedule consequences Complex Signal

Find working hours from previous period

Medium Read

Enter contents into schedule Complex Update

Erase schedule Simple Update

Query earlier schedules Medium Read

Make appointment Medium Update

Cancellation Simple Update

Query possible appointments Complex Read

Register treatment Simple Update

Create customer Simple Update

Query customer information Medium Read

Employment Simple Update

Retirement Simple Update

Update apprentice information Simple Update

Tabel 2.6 Function List( Sumber : Mathiassen, et al., 2000, p145 )

2.5.7.3 Interface

Menurut Mathiassen, et al. ( 2000 ), kegiatan interface merupakan

kegiatan ketiga dalam application domain. Interface adalah fasilitas –

fasilitas yang membuat model dan fungsi sistem tersedia untuk actor.

46

Interface merupakan kegiatan untuk menentukan interface dari sistem.

Interface digunakan oleh actor untuk berinteraksi dengan sistem.

Interface terdiri dari dua macam, yakni ;

1. user interface

merupakan interface yang menghubungkan sistem dengan user

2. system interface

merupakan interface yang menghubungkan suatu sistem dengan sistem

lainnya.

Terdapat empat jenis pola dialog yang penting dalam menentukan

user interface, yaitu :

1. Menu – selection

Merupakan suatu pola yang menampilkan sebuah daftar pilihan –

pilihan yang mungkin dalam user interface.

2. Form fill- in

Merupakan pola klasik untuk data entry dengan menggunakan terminal

yang berbasiskan pada karakter. User memasukkan data pada

sekumpulan field – field yang saling berhubungan.

3. Command-language

Merupakan user interface dimana user memasukkan dan mengaktifkan

perintah – perintah ( commands ) yang telah diformat.

4. Direct-manipulation

Merupakan user interface dimana user bekerja dengan representasi

objek – objek yang ada. User memilih objek – objek yang ada dan

47

melaksanakan fungsi – fungsi dalam objek tersebut dengan hasil yang

dapat terlihat dengan segera.

Dalam menganalisa system interface, harus diperoleh pemahaman

tentang :

1. data yang harus dikirim dari suatu sistem ke sistem lain

2. data yang akan diterima suatu sistem dari sistem lain

Dua macam pola system interface yakni :

1. read external device

merupakan interface dimana sistem perlu melakukan pembacaan

terhadap external device. Sistem sering perlu membaca external device

secara regular atau sebagai respon atas event – event dalam problem

domain. Sistem dapat bertukar data dengan external device.

2. interaction protocol

komunikasi dengan sistem lainnya dapat saja lebih bersifat kompleks

dibandingkan hanya bertukar informasi dengan external device karena

antar sistem dapat saling mempengaruhi. Sebagai contoh, sebuah sistem

dapat mengirimkan permintaan ( query ) kepada sistem lain yang

meminta dieksekusinya sebuah fungsi.

Hasil akhir dari aktivitas ini adalah berupa user interface dan

system interface. Contoh navigation diagram seperti ditunjukkan gambar

2.10

48

Gambar 2.10 Navigation Diagram( Sumber : Mathiassen, et al., 2000, p160 )

2.5.8 Architectural Design

Menurut Mathiassen,et al. ( 2000 ) arsitek membuat sistem sesuai dengan

fungsi sistem tersebut dan dengan memenuhi kriteria desain tertentu. Arsitektur

juga berfungsi sebagai kerangka untuk kegiatan pengembangan yang selanjutnya.

Sebuah arsitektur yang tidak jelas akan menghasilkan banyak pekerjaan yang sia –

sia . Tujuan dari aktivitas ini adalah untuk menyusun struktur dari sistem yang

terkomputerisasi. Hasil akhir dari aktivitas ini adalah komponen dan proses dari

sebuah sistem.

Aktivitas – aktivitas dalam architectural design adalah seperti ditunjukkan

dalam tabel 2.7 sebagai berikut :

StartExit

Miniatureof screenor window

Commands, menu selections,or buttons to change screensor windows

49

Aktivitas Isi KonsepCriteria Apa kondisi dan kriteria

untuk desain ?Criterion

Components Bagaimana sistem dibentuk menjadi komponen –komponen ?

Component architecture dan component

Processes Bagaimana proses sistem didistribusikan dan dikordinasikan ?

Process architecture dan process

Tabel 2.7 Aktivitas dalam Architectural Design( Sumber : Mathiassen, et al., 2000, p176 )

2.5.8.1 Criteria

Menurut Mathiassen, et al. ( 2000 ) criterion adalah properti-

properti yang diinginkan atas sebuah arsitektur. Conditions adalah peluang

– peluang dan keterbatasan – keterbatasan dalam hal teknis, organisasi dan

sisi manusia yang terkait dengan pelaksanaan suatu tugas. Untuk

menciptakan sebuah desain yang baik diperlukan pertimbangan mengenai

kondisi – kondisi dari setiap proyek yang dapat mempengaruhi kegiatan

desain yaitu :

1. Technical, yang terdiri dari pertimbangan : penggunaan hardware,

software dan sistem lain yang telah dimiliki dan dikembangkan;

pengaruh kemungkinan penggabungan pola – pola umum dan

komponen yang telah ada terhadap arsitektur dan kemungkinan

pembelian komponen standar.

2. Organizational, yang terdiri dari pertimbangan: perjanjian kontrak,

rencana untuk pengembangan lanjutan, dan pembagian kerja antara

pengembang.

50

3. Human, yang terdiri dari pertimbangan : keahlian dan pengalaman orang

yang terlibat dalam kegiatan pengembangan dengan sistem yang serupa

dan dengan platform teknis yang akan didesain.

Sebuah desain yang baik memiliki tiga ciri – ciri yaitu :

1. tidak memiliki kelemahan

Sebuah desain yang bahkan hanya mengandung satu kelemahan saja

dapat menyebabkan desain menjadi tidak bermanfaat dalam praktek

nantinya.

2. menyeimbangkan beberapa kriteria

Kriteria – kriteria dapat saja saling bertentangan, sehingga kita harus

menentukan kriteria mana yang harus ditekankan dan bagaimana

menyeimbangkan kriteria – kriteria yang saling bertentangan tergantung

pada kondisi yang ada.

3. usable, flexible, dan comprehensible

usable adalah derajat sampai dimana desain sistem memenuhi

kebutuhan user dan sampai dimana desain sesuai dengan technical

platform. Flexible adalah meminimalkan konsekuensi – konsekuensi

yang timbul dari perubahan – perubahan yang mungkin akan terjadi.

Comprehensible berarti menyederhanakan pemikiran dengan

mengumpulkan beberapa elemen dalam satu konsep dan hal ini dapat

tercapai melalui abstraksi.

Hasil akhir dari aktivitas ini adalah kumpulan kriteria. Beberapa

kriteria umum yang digunakan dalam kegiatan desain yang berorientasi

objek adalah seperti ditunjukkan dalam tabel 2.8:

51

Criterion Ukuran dariUsable Kemampuan sistem beradaptasi dengan konteks

organisasi, konteks yang berhubungan dengan tugas dan konteks teknis.

Secure Pencegahan terhadap akses yang tidak terotorisasi atas data dan fasilitas

Efficient Penggunaan yang ekonomis atas fasilitas platform teknis ( techincal platform )

Correct Pemenuhan kebutuhan atau persyaratanReliable Pemenuhan ketelitian atau ketepatan dalam eksekusi

fungsiMaintainable Biaya menemukan dan memperbaiki kerusakan sistemTestable Biaya untuk menjamin bahwa sistem yang diterapkan

dapat melaksanakan fungsi yang diinginkanFlexible Biaya untuk memodifikasi sistem yang diterapkanComprehensible Usaha yang dibutuhkan untuk mendapatkan pemahaman

atas sistemReusable Kemungkinan penggunaan bagian – bagian sistem pada

sistem lain yang berhubunganPortable Biaya untuk memindahkan sistem kepada technical

platform yang berbedaInteroperable Biaya untuk menggabungkan sistem dengan sistem lain

Tabel 2.8 Kriteria untuk Kualitas Software( Sumber: Mathiassen, et al., 2000, p178 )

2.5.8.2 Component Architecture

Menurut Mathiassen, et al. ( 2000 ) component architecture adalah

sebuah struktur sistem yang terdiri dari komponen – komponen yang saling

berhubungan. Component adalah sebuah kumpulan bagian – bagian

program yang merupakan satu kesatuan dan memiliki tanggung jawab yang

telah didefinisikan dengan baik.

Beberapa pola umum dalam desain komponen arsitektur yakni :

1. layered architecture pattern

merupakan arsitektur yang terdiri dari komponen – komponen yang

dinamakan layers ( lapisan – lapisan ). Gambar 2.11 menunjukkan

52

layered architecture pattern. Setiap komponen memiliki tanggung

jawabnya masing – masing. Downward interface menggambarkan

operasi yang dapat diakses komponen atas layer yang ada dibawahnya.

Upward interface menggambarkan operasi yang tersedia untuk layer

diatasnya.

<<component>>

Layer i+1

<<component>>

Layer i

<<component>>

Layer i-1

upwards interface

downwards interface

Gambar 2.11 Layered Architecture Pattern( Sumber : Mathiassen, et al., 2000, p193 )

2. generic architecture pattern

Pola ini digunakan untuk merinci sistem dasar yang terdiri dari

komponen interface, function, dan model. Gambar 2.12 menunjukkan

generic architecture pattern . Dimana komponen model terletak pada

lapisan yang paling bawah, kemudian dilanjutkan dengan function layer

dan paling atasnya komponen interface.

53

<<component>>user intertace

<<component>>

function

<<component>>system interface

<<component>>

interface

<<component>>

m odel

<<component>>technical platform

UIS<<component>> <<component>>

DBS NS<<component>>

Gambar 2.12 Generic Architecture Pattern( Sumber : Mathiassen, et al., 2000, p196 )

3. client server architecture pattern

Pola ini awalnya dikembangkan untuk mengatasi masalah sistem yang

terdistribusi diantara beberapa prosesor yang tersebar secara geografis.

Gambar 2.13 menunjukkan client server architecture pattern.

Komponen pada arsitektur ini adalah sebuah server dan beberapa client.

Tanggung jawab dari server adalah untuk menyediakan database dan

resource yang dapat disebarkan kepada client melalui jaringan.

Sementara client memiliki tanggung jawab untuk menyediakan interface

lokal untuk setiap user-nya. Identifikasi komponen, didalam

perancangan sistem atau subsistem, pada umumnya dimulai dengan

layer architecture dan client server architecture dimana keduanya

merupakan dua layer yang berbeda, tetapi saling melengkapi.

54

<<component>>Client 1

<<component>>Client 2

<<component>>Client n....

<<component>>Server

Gambar 2.13 Client Server Architecture Pattern( Sumber : Mathiassen, et al., 2000, p197 )

Tabel 2.9 menunjukkan bentuk – bentuk distribusi client server architecture.

Client Server ArchitectureU U + F + M Distributed presentationU F + M Local presentationU + F F + M Distributed functionalityU + F M Centralized dataU + F + M M Distributed data

Tabel 2.9 Bentuk – bentuk Client Server Architecture( Sumber : Mathiassen, et al., 2000, p200 )

2.5.8.3 Process Architecture

Menurut Mathiassen, et al. ( 2000 ) process architecture adalah

struktur dari eksekusi sistem yang terdiri dari proses – proses yang saling

bergantung. Processor adalah sebuah peralatan yang dapat mengeksekusi

program. Program component adalah modul fisik atas kode program.

Active object adalah sebuah objek yang telah diberikan sebuah proses.

Hasil akhir aktivitas ini berupa deployment diagram.

Sebuah sistem dapat terdistribusi pada beberapa prosesor yang

terhubung melalui jaringan. Beberapa pola distribusi adalah :

1. centralized pattern

55

pola ini menyimpan semua data pada server pusat dan user hanya dapat

melihat user interface saja. Gambar 2.14 menunjukkan centralized

pattern. Keuntungannya adalah dapat diimplementasikan pada client

dengan murah, semua data konsisten karena hanya berada disatu tempat,

strukturnya mudah dimengerti dan diimplementasikan, dan kemacetan

jaringannya sedang. Kerugiannya adalah robustness yang rendah ( jika

server mengalami masalah ( down ) , maka client tidak dapat melakukan

apapun ), waktu akses yang lebih lama dan tidak memfasilitasi back up

data.

: Cl ien t

u se r int e r f ace

sy s t e m int e r f a ce

: Ser v er

f u n ct i o n

u se r int e r f ace sy s t e m int e r f ac e

mo d el

morecl ient s

Gambar 2.14 Centralized Pattern( Sumber : Mathiassen, et al., 2000, p216 )

2. Distributed pattern

Dalam pola ini semua data terdistribusi ke user atau client dan server

hanya menyebarkan model yang telah di-update di antara client.

56

Gambar 2.15 menunjukkan distributed pattern. Setiap kopi dari model

yang lengkap ditempatkan pada setiap client. Keuntungannya adalah

waktu akses yang rendah, robustness yang maksimal (jika server,

network, ataupun client lainnya mengalami masalah ( down ) , maka

client masih dapat melakukan fungsinya ), dan backup data yang

banyak. Kerugiannya adalah redudansi data sehingga konsistensi data

kurang, kemacetan jaringan yang tinggi, persyaratan teknis yang lebih

tinggi untuk client, dan arsitektur sulit dipahami dan diimplementasikan.

: Cl ient

: Server

system interface

function

user interface system interface

mode l

m oreclients

Gambar 2.15 Distributed Pattern( Sumber : Mathiassen, et al., 2000, p217 )

3. decentralized pattern client

Pola ini berada diantara kedua pola diatas. Disini client memiliki data

tersendiri sehingga data umum hanya berada pada server. Gambar 2.16

menunjukkan decentralized pattern. Server menyimpan data umum dan

fungsi atas data – data tersebut, sedangkan client menyimpan data

57

dimana client sebagai bagian dari application domain. Keuntungannya

adalah konsistensi data karena tidak adanya duplikasi data, lalu lintas

jaringan yang rendah, dan waktu akses yang rendah. Kerugiannya

adalah semua prosesor harus mampu melakukan fungsi yang kompleks

dan memelihara model dalam jumlah yang besar, sehingga

meningkatkan biaya hardware.

: C l i en t

f un c t i on

u se r i nt er f ac e s ys t em i nt er f ac e

m o d e l ( l oc a l )

m o rec l ien ts

: S erv er

f un c t i on

u s er i nt er f ac e s ys t em i nt er f ac e

m o d el ( c o m m o n )

Gambar 2.16 Decentralized Pattern( Sumber : Mathiassen, et al., 2000, p219 )

2.5.9 Component Design

Menurut Mathiassen, et al. ( 2000 ) tujuan dari kegiatan component design

adalah untuk menentukan implementasi kebutuhan atau persyaratan sistem dalam

kerangka arsitektur. Hasil akhir dari aktivitas ini adalah deskripsi dari komponen –

komponen sistem.

58

Tabel 2.10 adalah kegiatan dari component design :

Aktivitas Isi KonsepModel Component

Bagaimana suatu model digambarkan sebagai kelas dalam sebuah sistem ?

Model component dan attribute

Function Component

Bagaimana functiondiimplementasikan ?

Function Component dan Operation

Connecting Component

Bagaimana komponen –komponen saling dihubungkan ?

Component dan connection

Tabel 2.10 Aktivitas dalam Component Design( Sumber : Mathiassen, et al., 2000, p232 )

2.5.9.1 Model Component

Menurut Mathiassen, et al. ( 2000 ) model component adalah

bagian dari sistem yang mengimplementasikan model problem domain.

Tujuan dari model component adalah untuk memberikan data saat ini dan

data historis pada functions, interface dan user serta sistem lainnya.

Hasil dari kegiatan model component adalah revisi dari class

diagram dari kegiatan analisis yang terdiri dari kegiatan penambahan class,

atribut dan struktur baru yang mewakili event. Gambar 2.17 menunjukkan

revised class diagram.

59

-creditapproval-creditapprovaldate-name

Custom er

-fromdate-address

Custom er Address-accountnumber-accountstate-opendate-closedate

Account

-transtype-date-amount

Transaction

1

1..*

1

1..*

10..*

Gambar 2.17 Revised Class Diagram( Sumber : Mathiassen, et al., 2000, p236 )

Revisi pada class dapat terjadi pada :

1. Generalization

Jika terdapat dua class dengan atribut yang sama maka dapat dibentuk

class baru. Gambar 2.18 menunjukkan contoh revisi pada bentuk

generalisasi.

- account number- account stat e- opendat e- cl osedat e

Ac co un t

- dat e- amount

D ep os i t- dat e- amount

W i t hd r aw- t r anst ype- date- amount

T r an sact i on

- account number- account st at e- opendate- cl osedat e

Acco u n t

1

0. . *

1

0. . *

1

0. . *

s o l us i a w a l s o l us i ya n g leb i h s e d e rh a n a

Gambar 2.18 Menyusun Kembali Class Diagram( Sumber : Mathiassen, et al., 2000, p244 )

60

2. Association

Jika terdapat hubungan many – to – many. Gambar 2.19

menunjukkan contoh revisi class atas asosiasi.

G a s S tat ion0. . . * 0. . . *

C u stom er

Open Act i ve

f i l l ( date, octane,vo lum e, price )

star t c lose buy carse ll car

fil l ( date, oc tane,vo lum e, price )

G a s S tat ion C u stom er

F i l l ing

10. . *

1

0. . *

a na lys is m od e l

de s ign m o d el

Gambar 2.19 Contoh Revisi Class atas Association( Sumber : Mathiassen, et al., 2000, p245 )

3. Embedded iterations

Jika dalam statechart diagram terdapat event – event yang bersifat

berulang ( iterative ) maka dapat dibuat class – class baru terhadapnya.

Gambar 2.20 menunjukkan revisi atas embedded iterations.

61

Person

Hospitalization Treatment Discharge

1

0..*1

0...* 0...*

1

Person Well Hospitalizedbirth hospitalized

discharge

treat

deathdeath

analysis model

design model

Gambar 2.20 Contoh Revisi Class atas Embedded Iterations( Sumber : Mathiassen, et al., 2000, p246 )

2.5.9.2 Function Component

Menurut Mathiassen, et al. ( 2000 ) function component adalah

bagian dari sistem yang mengimplementasikan persyaratan atau kebutuhan

sistem. Operations adalah properti dari proses yang dispesifikasikan dalam

sebuah class dan diaktifkan melalui objek dari class.

Tujuan dari function component adalah untuk memberikan akses

bagi user interface dan komponen sistem lainnya ke model sehingga

menunjukkan pengimplementasian dari function. Hasil dari aktivitas ini

adalah class diagram dengan operations dan spesifikasi dari operation yang

kompleks.

Empat tipe fungsi dan operation yang terkait yakni :

1. update

62

fungsi ini terhubung secara langsung dengan event – event dalam

problem domain. Fungsi update menerima input data yang

menggambarkan event dan menghasilkan output utamanya yakni

mengupdate model. Gambar 2.21 menunjukkan contoh update function.

functions:Function object1:Model-Class1 object2:Model-Class2

update() update()

update-refused()

update-successful()

update()

update-refused()

update-successful()failure()

()

Gambar 2.21 Update Function dan Operasinya( Sumber : Mathiassen, et al., 2000, p255 )

2. read

fungsi ini menggambarkan kebutuhan dari user ataupun sistem lain

untuk mendapatkan informasi dari model. Sistem dilihat sebagai

database dimana informasi yang diinginkan dapat ditemukan sebagai

atribut. Fungsi ini menerima input data yang menggambarkan data

yang ingin dibaca dan menghasilkan output berupa informasi yang

diinginkan yang dibaca dari model. Gambar 2.22 menunjukkan contoh

read function.

63

functions:Function object1:Model-Class1 object2:Model-Class2

read()

not-found()

result()

read()

not-found()

result()result()

read()

Gambar 2.22 Read Function dan Operasinya( Sumber : Mathiassen, et al., 2000, p257 )

3. compute

fungsi ini menggambarkan bahwa user atau sistem lain membutuhkan

pemrosesan data yang dapat juga melibatkan pembacaan model.

Input atas fungsi ini berupa angka – angka sebagai bagian dari proses

perhitungan dan atribut – atribut yang menggambarkan objek – objek

dari model yang relevan. Fungsi ini menghasilkan output berupa hasil

dari perhitungan. Gambar 2.23 menunjukkan contoh compute function.

64

functions:Function object1:Model-Class1 object2:Model-Class2

read()

not-found()

result()

read()

not-found()

result()result()

compute()

Gambar 2.23 Compute Function dan Operasinya( Sumber : Mathiassen, et al., 2000, p258 )

4. signal

fungsi ini menggambarkan kebutuhan akan pemonitoran atau

pengontrolan. Dalam sistem dimana pemonitoran atau pengontrolan

adalah penting, suatu reaksi akan diberikan jika problem domain

memasuki suatu kondisi ( state ). Dalam banyak kondisi, fungsi ini

tidak menerima input data khusus. Input berasal dari model. Output

data berupa pesan kepada user dalam application domain atau impuls

pengontrolan secara langsung ke device dalam problem domain.

Gambar 2.24 menunjukkan contoh signal function.

65

functions:Function object1:Model-Class1 object2:Model-Class2

critical()

result()

critical()

result()

signal()

activate()

()

Gambar 2.24 Signal Function dan Operasinya( Sumber : Mathiassen, et al., 2000, p259 )

Untuk menspesifikasikan operasi yang kompleks dapat dilakukan

dengan membuat operation specification seperti ditunjukkan dalam tabel

2.11 berikut :

66

Name Register transactionCategory _ Active X Update

X Passive _ Read_ Compute_ Signal

Purpose Establishes a new transaction for a specific accountInput Data

Account_no, transtype, date, amount

Conditions An object of the class Account, with the given account number, exists.The attribute accountstate in this object has the value open

Effect A new object of the class transaction is establishes with input data assigned to the attributes.This object is connected to the relevant account object

Algorithm -Data Structures

-

Placement AccountInvolved Objects

Account, transaction

Triggering Events

Amount deposited, amount withdrawn

Tabel 2.11 Contoh Operation Specification.( Sumber : Mathiassen, et al., 2000, p265 )