BAB 2

LANDASAN TEORI

2.1 Pengertian Sistem Informasi Akuntansi

Menurut Wilkinson et al. (2000, p7) Sistem Informasi Akuntansi adalah kesatuan

struktur dalam sebuah entitas, seperti perusahaan, yang mempekerjakan sumber –

sumber fisik dan komponen – komponen lain untuk mengubah data ekonomi ke

dalam informasi akuntansi, dengan tujuan untuk memuaskan kebutuhan informasi

dari beragam pemakai.

Menurut Jones dan Rama (2006, p5) Sistem Informasi Akuntansi adalah sebuah

sub sistem dari Sistem Informasi Manajemen yang menyediakan informasi tentang

akuntansi dan finansial dimana informasi tersebut digunakan secara rutin untuk

memproses transaksi akuntansi.

Menurut Bodnar dan Hopwood (2001, p1) Sistem Informasi Akuntansi adalah

kumpulan dari sumber daya, seperti orang dan peralatan, yang dibuat untuk

mengubah data finansial atau data lainnya menjadi sebuah informasi.

2.1.1 Tujuan Sistem Informasi Akuntansi

Menurut Gelinas, Sutton, Hutton (2005, p15) tujuan dari Sistem Informasi

Akuntansi adalah untuk mengumpulkan, memproses, dan melaporkan

informasi yang berkaitan dengan aspek finansial dari bisnis event.

Menurut Boockholdt (1999, p1) studi Sistem Informasi Akuntansi

menganalisa bagaimana kejadian – kejadian yang mempengaruhi sebuah

organisasi dicatat, diringkas, dan dilaporkan. Kejadian dicatat menggunakan

8

sistem organisasi berupa sumber daya manusia dan komputer, diringkas

menggunakan metode dan tujuan akuntansi, dan dilaporkan sebagai informasi

kepada pihak internal dan eksternal organisasi.

Menurut pendapat Wilkinson et al. (2000,p.8), tujuan dan kegunaan sistem

informasi akuntansi adalah :

1. Mendukung operasional sehari-hari.

Transaksi dalam perusahaan merupakan operasi sehari – hari yang

dilakukan secara rutin. Adapun transaksi terdiri dari :

a. Transaksi akuntansi seperti penjualan biasanya menggunakan

sistem informasi akuntansi untuk pemrosesan.

b. Transaksi non akuntansi seperti melakukan pemesanan, pada

akhirnya akan mengarah kepada transaksi akuntansi.

2. Mendukung pengambilan keputusan bagi pengambil keputusan

internal.

Misalnya perusahan menggunakan Sistem Informasi Akuntansi untuk

tugas pemrosesan informasi yang vital seperti ekspektasi pendapatan

yang akan diterima dari proyek tertentu untuk tahun mendatang.

3. Untuk memenuhi kewajiban atau tanggung jawab yang sesuai

dengan jabatannya

Pemakai dari Sistem Informasi Akuntansi dapat berupa pemakai

internal, yaitu manajer, maupun pemakai eksternal, yaitu pelanggan,

pemasok, pemilik saham, kreditor, satuan buruh, pihak bank,

pemerintah, dan para stakeholder lainnya.

9

2.1.2 Komponen dalam Sistem Informasi Akuntansi

Menurut Gelinas et al. (2005, p9-12), Sistem Informasi Akuntansi

memiliki 10 komponen, yaitu :

1. Technology

2. Database

3. Reporting

4. Control

5. Business Operations

6. Events Processing

7. Management Decision Making

8. Systems Development and Operations

9. Communications

10. Accounting and Auditing Principles

Mengacu pada pendapat Romney dan Steinbart (2006, p6), komponen

sistem informasi akuntansi terdiri dari:

a. People: siapa yang mengoperasikan sistem dan melakukan

fungsi-fungsi yang bervariasi.

b. Procedures and instructions: kegiatan organisasi baik secara

manual maupun secara otomatis mengumpulkan, memproses,

dan menyimpan data.

c. Data perusahaan: berisi tentang perusahaan dan proses

bisnisnya.

d. Software yang digunakan oleh perusahaan untuk memproses

data.

10

e. Information technology infrastructure, meliputi komputer dan

jaringan komunikasi.

f. Internal controls and security : Yang menjamin keamanan

data dari Sistem Informasi Akuntansi.

2.2 Sistem Akuntansi Penjualan kredit dan piutang dagang

2.2.1 Penjualan Kredit

Menurut Boockholdt (1999, p520), Penjualan merupakan komponen

terakhir dalam siklus kegiatan bisnis dasar yaitu menjual barang atau jasa,

yang merupakan hasil keluaran dari proses konversi. Penjualan terdiri dari

transaksi penjualan barang atau jasa, baik secara kredit maupun secara tunai.

Menurut Boockholdt (1999, p555) sistem akuntansi penjualan kredit

manual dimulai dengan cara menyiapkan sales order pelanggan oleh

departemen penjualan. Setelah departemen kredit menyetujui kredit untuk

pelanggan, departemen pengiriman mengambil barang dari gudang dan

mengirimkannya. Departemen pengiriman mengirimkan nota kiriman kepada

departemen penagihan, yang mana menyiapkan faktur penjualan.

Standart Akuntansi Keuangan (2004) mendefinisikan, “Penjualan barang

meliputi barang yang diproduksi perusahaan untuk dijual dan barang yang

dibeli untuk dijual kembali seperti barang dagang yang dibeli pengecer atau

tanah properti lain yang dibeli untuk dijual kembali. Dan penjualan jasa

biasanya menyangkut tugas yang secara kontraktual telah disepakati oleh

perusahaan, jasa tersebut dapat diserahkan selam satu periode atau secara lebih

dari satu periode.” (PSAK No.23).

11

Mengacu pada pendapat Wilkinson et al. (2000, p416-417), tujuan sistem

informasi akuntansi penjualan kredit meliputi:

1) Mencatat order penjualan secara akurat dan cepat.

2) Mengidentifikasi pelanggan yang layak mendapatkan kredit.

3) Mengirimkan produk atau melakukan pelayanan pada waktu

yang tepat.

4) Menagih piutang kepada pelanggan pada waktunya.

5) Mencatatat dan mengklasifikasikan penerimaan kas secara

cepat dan akurat.

6) Memposting penjualan dan penerimaan kas ke akun-akun

yang berhubungan di dalam buku besar piutang.

7) Mengamankan produk sampai pengiriman.

8) Mengamankan kas sampai dideposit.

Gelinas, Sutton, dan Hunton (2005, p349-350) mengutarakan terdapat

empat tahap awal dalam order entry / sales processs, yaitu : pre-sales

activities, sales order processing, picking and packing the goods, dan

shipping. Proses order entry / sales merefleksikan pengaruh struktur dari

manusia, peralatan, metode dan kontrol yang dirancang untuk mencapai

tujuan. Fungsi utama dari proses order entry / sales yaitu untuk membuat

aliran informasi yang mendukung :

• Pekerjaan berulang yang rutin pada sales order departement,

credit department, dan shipping department

• Kebutuhan keputusan yang mengatur tentang berbagai fungsi

penjualan dan pemasaran

12

Mengacu pada pendapat Gelinas, Sutton, dan Hunton (2005, p361-365)

terdapat tiga proses dalam penjualan kredit, yaitu:

a. Validate Sales Order

1. Verify Inventory Availability

Berdasarkan customer order, akan dicek ketersediaan produk pada

inventory master data. Jika persediaan on hand, maka akan dibuat

inventory available order. Sebaliknya, jika jumlah persediaan tidak

mencukupi maka dilakukan proses back orders, yaitu proses

pemenuhan customer order dengan membuat back order request ke

departemen pembelian. Jika pelanggan menolak untuk menerima

back order, maka proses penjualan akan di-terminated dan order

ditolak. Informasi tentang order akan dicatat pada marketing data

store.

2. Check credit

Setelah inventory tersedia, maka dilakukan check credit

berdasarkan account receivable master data & sales order master

data. Perusahaan menjadi mudah menentukan jumlah kredit yang

tersedia bagi pelanggan. Tanpa central database, saldo piutang

customer menjadi berlipat yang melampaui batas jumlah penjualan.

Dari proses ini, akan dibuatkan accepted order jika jumlah kredit

masih tersedia bagi pelanggan

3. Complete Sales Order

Pada proses ini, informasi harga barang diperoleh dengan pasti dari

inventory master data. Secara bersamaan juga akan dilakukan :

13

• mengupdate inventory master data untuk mengalokasi kuantitas

order penjualan

• mengupdate sales order master data untuk mengindikasi bahwa

order telah selesai dilakukan

Dari proses pertama “validate sales order” akan dihasilkan dokumen:

• picking ticket : dokumen pengambilan barang oleh gudang untuk

diserahkan ke bagian pengiriman, mengidentifikasi barang yang

diambil, dan biasanya menyatakan lokasi gudang

• customer acknowledgement : akan dikirimkan ke pelanggan

sebagai bukti bahwa order pelanggan diterima dan terdapat tanggal

perkiraan pengiriman

• sales order notification : akan dikirimkan ke bagian penagihan

untuk memberitahukan adanya pengiriman barang yang belum

terlaksana.

b. Complete Picking Ticket

1. Match goods with picking ticket

Dalam proses mencocokkan fisik barang dengan picking ticket,

terdapat dua situasi yang dapat terjadi :

barang yang diambil di gudang tidak sesuai dengan picking ticket

(barang ditempatkan pada lokasi gudang yang salah)

barang tidak tersedia untuk memenuhi order. Situasi ini timbul

ketika barang salah ditempatkan atau saldo persediaan fisik

14

tidak sesuai dengan saldo persediaan dengan perpetual system

yang dinyatakan dalam inventory data.

Pada saat barang yang ada sesuai dengan picking ticket, maka

dibuatkan matched picking ticket.

2. Enter quantity picked

Bagian gudang membuatkan completing picking ticket dan

meneruskannya bersama dengan barang ke bagian pengiriman

c. Execute Shipping Notice

1. Match orders

Bagian pengiriman akan mencocokkan kuantitas produk, kuantitas

dalam picking tickets dan kuantitas dalam sales order master data.

Jika sesuai jumlahnya, maka matched sales order akan diteruskan

ke proses selanjutnya. Jika tidak sesuai, akan reject order

2. Produce shipping notice

Pada saat matched sales order diteruskan, maka akan mengupdate:

inventory master data untuk menggambarkan barang yang sudah

diambil, di-pack, dan dikirimkan

sales order master data untuk mengubah kuantitas pada saat

terjadi sales order, mengurangi kuantitas fisik persediaan.

Dari proses terakhir “execute shipping notice” akan dihasilkan

dokumen :

• shipping billing notification : untuk memberitahukan bagian

penagihan agar memulai proses penagihan

15

• bill of lading : kontrak antara bagian pengiriman dengan

perusahaan pengangkutan dimana perusahaan pengangkut setuju

untuk mengirimkan barang ke pelanggan

• packing slip : ditempelkan pada kemasan barang,

mengidentifikasi pelanggan yang memesan barang tersebut dan isi

dari kemasan tersbut

• general ledger inventory sales order update : untuk

memberitahukan bagian G/L bahwa persediaan barang telah terjual

dan cost of good sold meningkat

2.2.2 Piutang Dagang

Menurut Boockholdt (1999, p538) sistem akuntansi penjualan kredit

terkomputerisasi dimulai dari pemesanan yang kemudian dientry ke dalam

sistem aplikasi. kemudian barang dan jasa dikirim, sistem aplikasi akan

mencatat pengiriman, setelahnya sistem billing akan membuat permohonan

pembayaran, dan terakhir sistem aplikasi penerimaan kas mencatat

pembayaran yang diterima, kadang – kadang billing dan aplikasi penerimaan

kas disebut accounts receivable systems.

Menurut Horngren et al. (2002,p.311) ”receivables is a monetary claims

against a business or individual.”, yang berarti bahwa piutang merupakan

klaim uang pada perusahaan maupun individu.

Menurut Hongren et al. (2002, p315) jika perusahaan tidak mampu

menagih piutang dari pelanggan sehingga menciptakan beban, maka disebut

16

beban piutang tak tertagih. ada 2 cara untuk mengestimasi piutang tak tertagih

yaitu dengan metode persentase penjualan (pendekatan laporan keuangan)

yaitu dengan menghitung beban akun tidak tertagih sebagai persentase dari

penjualan kredit bersih. Metode kedua yang terkenal disebut dengan metode

analisis umur piutang, dimana piutang pelanggan dianalisis berdasarkan

lamanya waktu terutang dari pelanggan.

Menurut Boockholdt (1999, p547-548) untuk mengetahui status piutang

atau sisa piutang yang dimiliki pada tanggal tertentu , setiap bulan perusahaan

menggunakan neraca saldo piutang untuk menyajikan informasi umur piutang

yaitu jumlah piutang yang berumur kurang dari 31 hari, 31 sampai 60 hari, 61

sampai 90 hari dan lebih dari 90 hari. Hal ini diperlihatkan kepada manajer

kredit untuk menentukan apakah harus dilakukan penghapusan piutang atau

tidak akibat tidak tertagih.

Menurut Hongren (2002, p318) metode penghapusan piutang digunakan

oleh perusahaan jika perusahaan setelah menunggu sekian lama sehingga

memutuskan untuk tidak melakukan penagihan kepada pelanggan. Ini disebut

metode direct write off.

Berdasarkan pendapat Warren, Reeve dan Fess (2005, p318), “Piutang

meliputi semua klaim dalam bentuk uang terhadap pihak lainnya, termasuk

individu, perusahaan atau organisasi lainnya. Piutang biasanya memiliki

bagian yang signifikan dari total aktiva lancar perusahaan.” Transaksi paling

umum yang menciptakan piutang adalah penjualan barang atau jasa secara

kredit. Account receivable (piutang usaha) semacam ini normalnya

17

diperkirakan akan tertagih dalam periode waktu yang relatif pendek, seperti 30

atau 60 hari. Piutang usaha diklasifikasikan di neraca sebagai aktiva lancar.

Menurut Gelinas, Sutton, dan Hunton (2005, p393), proses penagihan

terdiri atas tiga bagian penting, yaitu :

• billing customer

• managing customer account, dan

• securing payment for good sold or service rendered

Menurut Gelinas et al, (2005, P394) Proses billing / account receivable /

cash receipt merupakan struktur yang saling berinteraksi antara manusia,

peralatan, metode dan kontrol yang dirancang untuk membuat aliran informasi

dan bertujuan :

mendukung pekerjaan berulang yang rutin pada bagian kredit, kasir dan

bagian piutang.

mendukung proses pemecahan masalah untuk manajer keuangan

membantu dalam persiapan laporan internal dan eksternal

Menurut Gelinas et al. (2005, p402-407) terdapat tiga proses dalam billing /

Account Receivable / Cash Receipt, yaitu :

i) Perform billing

1) Compare

2) Prepare invoice

ii) Manage customer accounts

1) Validate return

2) Prepare credit memo

18

3) Prepare journal voucher

4) Prepare customer statements

5) Prepare bad debts journal voucher

iii) Receive payment

1) Compare check and remittance advice

2) Endorse check

3) Prepare deposit

4) Record customer payment

2.2.3 Laporan dari Sistem Informasi Akuntansi Penjualan kredit dan piutang

dagang

Menurut Boockholdt (1999, p544) terdapat tiga bentuk laporan dari siklus

penghasilan, yaitu :

1. Control reports

2. Registers

3. Special purpose reports, dapat dibagi lagi menjadi empat yaitu :

a. Customer statement

b. The aged accounts receivable trial balance

c. The remittance list

d. Sales Analysis Reports

19

2.3 Pengendalian Internal

2.3.1 Pengertian

Menurut Gelinas et al. (2005, p237) Pengendalian internal adalah sebuah

sistem yang terintegrasi antara orang, struktur, proses, dan prosedur, yang

menampilkan dan menyediakan metode yang menjanjikan sehingga

perusahaan dapat mencapai tujuannya dalam proses bisnisnya. Design dan

operasi dari pengendalian internal merupakan tanggung jawab dari top

management, oleh karena itu harus :

Mencerminkan perhatian management terhadap resiko yang dapat

menggangu perusahaan

Tetap berpegang pada evaluasi management yang berbasis cost vs

keuntungan

Tetap melihat pada etika bisnis dan personel integrity

Menurut Romney and Steinbart (2006, p192) pengendalian internal adalah

perencanaan organisasi dan metode sebuah bisnis yang digunakan untuk

mengamankan dan melindungi aset, memaintain records yang berhubungan

dengan aset perusahaan, menyediakan informasi yang akurat dan handal,

menyediakan laporan keuangan yang sesuai dengan GAAP, meningkatkan

efektifitas dan efisiensi operasi dan mendukung ketaatan terhadap kebijakan

manajemen yang berlaku.

Menurut Boockholdt (1999, p397) internal kontrol adalah sebuah proses

yang dipengaruhi oleh bagian – bagian dari perusahaan seperti direktur,

manajemen, dan personel lain, yang di desain untuk menyediakan hal yang

dibutuhkan perusahaan agar mencapai tujuan.

20

Menurut Jones dan Rama (2006, p103) pengendalian internal adalah

proses yang dipengaruhi oleh direktur, manajemen, dan staf lainnya, yang

didesain untuk memastikan tercapainya tujuan dalam : operasional yang

efektif dan efisien, laporan keuangan yang reliabel dan kesesuaian dengan

hukum dan peraturan.

Menurut Bodnar dan Hopwood (2001, p182) pengendalian internal adalah

sebuah proses yang dipengaruhi oleh para dewan direksi dari sebuah

perusahaan, manajemen, dan personel lain yang dirancang untuk menyediakan

keyakinan yang masuk akal berkaitan dengan pencapaian tujuan dalam

kategori : kehandalan pelaporan keuangan, efektivitas dan efisiensi

operasional, dan kepatuhan akan hukum dan peraturan yang berlaku.

2.3.2 Komponen – komponen pengendalian internal

Lima element dalam proses pengendalian internal menurut Bodnar dan

Hopwood (2001, p185-197) adalah :

1. Control Environment, adalah kumpulan dari beberapa faktor dalam

menganalisa, mengatur, dan membuat efektif dari peraturan dan

prosedur yang ada.

2. Risk Assessment, adalah proses untuk mengidentifikasi, menganalisa,

dan memanage resiko – resiko yang dapat mempengaruhi perusahaan

dalam mencapai tujuannya.

3. Control Activities, adalah peraturan dan prosedur yang membantu

untuk memastikan bahwa tujuan perusahaan dapat tercapai dengan

baik.

21

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 adalah kegiatan memantau proses yang terjadi untuk

menjaga kualitas dari internal kontrol perusahaan sepanjang waktu

dan melakukan corrective actions jika dibutuhkan.

Berikut adalah komponen dan pertimbangan utama atas struktur pengendalianinternal :

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 wewenang

dan tanggung jawab- kebijakan dan praktik

sumber 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.1 komponen dan pertimbangan utama struktur pengendalian internal ( Sumber : Wilkinson, et al., 2000, p236 )

22

2.3.3 Tujuan Sistem Pengendalian Internal

Menurut Wilkinson et al. (2000, p235) Pengendalian internal dimaksudkan

untuk mencapai tujuan tertentu dari organisasi. Tujuan organisasi dibagi

menjadi tiga kategori :

a. Efektifitas dan efisiensi operasi

b. Reliabilitas / kehandalan pelaporan keuangan

c. Kesesuaian dengan hukum dan peraturan yang berlaku

2.3.4 Kegiatan Pengendalian Internal

Menurut Boockholdt (1999, p404) kegiatan pengendalian terdiri dari

empat kategori :

1. Prosedur untuk mengotorisasi transaksi

2. keamanan untuk aset dan catatan

3. Pemisahan tugas

4. Kecukupan atau kelengkapan dokumen - dokumen dan

catatan – catatan

2.3.5 Pengendalian Internal dalam sistem penjualan kredit dan piutang dagang

Menurut Wilkinson et al. (2000, p451-453) Unsur pengendalian internal

dalam sistem penjualan kredit meliputi :

1. Pengendalian Umum

a. Pengendalian Organisasi

Harus ada pemisahan tugas antara bagian operasional dengan

bagian pencatatan

23

b. Pengendalian Dokumen

Dokumen harus lengkap dan up-to-date

c. Pengendalian Asset Accountability

Buku besar pembantu piutang harus dipertahankan dan

direkonsiliasi secara berkala dengan rekening kontrol yang ada di

buku besar. Demikian juga halnya dengan catatan persediaan.

d. Pengendalian Praktik Manajemen

Karyawan, termasuk programmer harus diberikan pelatihan. Audit

harus dilakukan terhadap kebijakan penjualan dan penerimaan

kas. Manajer harus melakukan review terhadap analisis periodik

dan laporan – laporan mengenai kegiatan akuntansi dan transaksi

yang disahkan melalui komputer

e. Pengendalian Data Center Operation

Staf IT dan akuntansi harus diawasi, dan kinerja mereka di-review

dengan bentuan laporan kontrol proses komputer dan pencatatan

akses

f. Pengendalian Otorisasi

Semua transaksi penjualan kredit harus diotorisasi oleh manajer

kredit

g. Pengendalian Akses

Menggunakan password untuk hak akses, melindungi gudang dan

kas secara fisik.

24

2. Pengendalian Aplikasi

a. Pengendalian Input

i. Dokumen yang disiapkan untuk penjualan, pengiriman, dan

penerimaan kas diberi nomor berurut, dan setiap dokumen

harus mendapat persetujuan dari pihak yang berotorisasi.

ii. Validasikan data pada pemesanan penjualan dan bukti kas

masuk saat data disiapkan dan dientry untuk di proses.

iii. Memperbaiki error yang terdeteksi selama data entry dan

sebelum data diposting ke dalam catatan pelanggan dan

persediaan.

iv. Masukkan total batch yang berhubungan dengan data penting

pada sales invoice dan bukti kas masuk. Dalam kasus

penerimaan kas, total dari bukti kas masuk harus

dibandingkan dengan total dari slip deposito.

b. Pengendalian Processing

i. Pindahkan barang pesanan dari gudang dan kirimkan barang

hanya berbasiskan otorisasi tertulis seperti stock request

copies.

ii. Berikan faktur kepada pelanggan hanya pada saat terdapat

notifikasi dari departemen pengiriman tentang jumlah

kuantitas yang dikirim.

iii. Terbitkan nota kredit untuk retur penjualan hanya setelah

terbukti barang tersebut telah dikembalikan.

25

iv. Verifikasi semua perhitungan pada faktur penjualan sebelum

dikirim atau diposting ke dalam akun pelanggan. Bandingkan

juga faktur penjualan dengan shipping notices.

v. Verifikasi semua jumlah total yang diposting ke dalam akun

piutang dari transaksi batch , kemudian posting jumlah total

pada akun buku besar.

vi. Setorkan semua kas yang diterima dengan batas penundaan

yang minimum untuk menghindari penggunaan kas secara

tidak sah oleh karyawan.

vii. Membetulkan kesalahan yang terjadi selama proses, biasanya

berupa kesalahan posting ke dalam accounts dan pengentrian

data yang benar.

c. Pengendalian Output

i. Siapkan laporan bulanan yang harus dikirimkan kepada semua

pelanggan kredit

ii. Semua kopian dari dokumen transaksi penjualan kredit sampai

penerimaan kas diberi nomor urut dan setiap nomor diperiksa

secara periodik untuk menghindari adanya gaps.

iii. Siapkan daftar printed transaction , dan account summary

secara periodik untuk dapat dilakukan audit

Menurut Bodnar dan Hopwood (2001, p205) terdapat unsur

pengendalian internal lain yang harus ada, yaitu :

a. Preventative Controls, yaitu tindakan untuk mencegah kesalahan

dan kecurangan sebelum terjadi

26

b. Detective Controls, yaitu tindakan untuk meng-uncovered

kesalahan dan kecurangan yang terjadi

c. Corrective Controls, yaitu tindakan untuk memperbaiki

kesalahan.

Berdasarkan pada pendapat Gelinas, Sutton, dan Hunton (2005, p241-

247), terdapat dua unsur pengendalian internal :

a. Control goals of operation processes

• effectiveness : ukuran kesuksesan dari satu atau lebih tujuan

proses yang merefleksikan kriteria yang digunakan untuk menilai

efektivitas berbagai proses bisnis

• efficiency : ukuran produktivitas sumber daya yang digunakan

untuk mencapai tujuan

• security of resources : perlindungan proses organisasi dari

kerugian, kebangkrutan, penyingkapan, peniruan, dan

penyalahgunaan lainnya.

b. Control goals of information processes

• input validity : tujuan pengendalian yang menjamin bahwa

masukan data yang disetujui secara tepat dan menunjukkan objek

dan keadaan ekonomi saat ini.

• input completeness : pengendalian yang menjamin bahwa semua

kejadian atau objek valid yang dimasukkan ke dalam sistem

27

• input accuracy : tujuan pengendalian yang menjamin bahwa

kejadian secara benar dimasukkan ke dalam sistem

• update completeness : tujuan pengendalian yang menjamin

bahwa semua kejadian yang dimasukkan dalam komputer dan

direfleksikan masing-masing dalam master data

• update accuracy : tujuan pengendalian yang menjamin bahwa

data yang dimasukkan dalam komputer, direfleksikan secara

benar ke masing-masing master data

2.4 Control Matrix

Menurut Gelinas et al. (2005, p301) Control matrix adalah alat yang di desain

untuk membantu dalam menganalisa hubungan sistem flowchart yang ada dan

bentuk narasinya.

Langkah – langkah dalam menyiapkan control matrix menurut Gelinas et al

(2005, p301-308) adalah :

1. Specifying control goals

Review flowchart yang ada dan bentuk deskripsi narasinya agar semakin

mengerti tentang sistemnya. Identifikasi proses bisnis, sumber daya yang

relevan, inputnya, penyimpanannya (jika ada), master data yang akan

diupdate. Specifying control goals dapat dibagi menjadi tiga, yaitu :

28

a. Identify operations process goals :

• Effectiveness goals

• Efficiency goals

• Security goals

b. Identify information process goals :

• Input goals ( input validity, completeness, dan accuracy)

• Update goals ( Update completeness, dan accuracy)

2. Recommending control plans

Daftar rekomendasi rencana pengendalian yang sesuai dengan proses

yang sedang dianalisa. Daftar harus terhubung antara operations process

dengan information procesing methods.

a. Annotating “Present” control plans

Dengan meletakkan P-1, P-2, sampai dengan P-n selain

penginputan manual, simbol manual dan komputerise proses.

Dimulai dari kolom kiri atas dari flowchart dan ikuti proses

logic sekuensial dari flowchart.

b. Evaluating “Present” control plans

Dengan memberikan nomor dan nama rencana di control

matrix, dan menjelaskan nature dan extent dari rencana

pengendalian dalam matrix

29

c. Identify and evaluate missing control plans

i. Examining the controls matrix

Analisa control matrix dan lihat apabila ada control goals

yang tidak terdapat dalam rencana pengendalian sekarang.

ii. Evaluating the systems flowchart

Analisa sistem flowchart agar dapat menambahkan

pengendalian lain atau kekuatan untuk pengendalian

30

Contoh dari control matrix untuk prosedur penjualan kredit (hal 376 - 377) adalah :

Tabel 2.1 Control matrix untuk proses bisnis dari penjualan (Sumber : Gelinas et. al., 2005 p376 – 377)

A B C D IV IC IA UC UA IV IC IA UC UAPresent Controls

P-2 Preformatted screens P-2 P-2 P-2 P-2 P-2 P-2P-3 Online prompting P-3 P-3 P-3 P-3 P-3 P-3

P-8 One for one checkingof picking tickets with thegoods P-8 P-8 P-8 P-8 P-8

P-9P-9

P-6 P-6P-6P-6

P-7

P-6 P-6

P-7P-7

P-6

P-9 P-9

P-6

P-7 P-7

P-5 P-5 P-5

P-4 P-4P-4 P-4

P-6 Populate inputs withmaster dataP-7 Programmed editchecks

P-9 receive&inputsturnaround document(picking ticket)

P-6

P-4 Interactive feedbackcheckP-5 Customer creditcheck

P-7

P-6

P-1P-1 P-1

Control goals of the information processFor sales order

inputs (i.e.,customer

orders),Ensure:

For sales order and inventory

master data,ensure:

For shipping notice inputs (i.e.,shipment data),ensure:

For sales order

master data,ensure:

Control Goals of the Operations Process

Recommended ControlPlans

Ensure Effective of

operations

Ensure efficient employment of

resources(people, computers)

Ensure security of resources

(inventory,

Control goals of the OE/S Business Process

P-1 Enter customer orderclose to where the order isreceived P-1 P-1 P-1 P-1 P-1

31

Tabel 2.2 Control matrix untuk proses bisnis dari penjualan (Lanjutan) (Sumber : Gelinas et. al., 2005 p376 – 377)

A B C D IV IC IA UC UA IV IC IA UC UA

Missing-control

Legend :Effectiveness goals :

UC = Update completenessUA = Update Accuracy

P-12

M-2

A= Provide timely response to customer inquiriesB=Provide timely acknowledgment of customer ordersC=Provide assurance of customer`s creditworthinessD=Provide timely shipment of goods to customers.

IV = Input ValidityIC = Input CompletenessIA = Input Accuracy

M-2

P-12 P-12

P-11P-11

P-10

M-1

P-10

P-11

P-12

M-1

P-11

M-1

M-2

P-11

M-2 Review open salesorder(tickler file)

P-10 Independentshipping authorizationP-11 Compare input withmaster dataP-12 one for one checkingof goods, pickingticket,sales order

M-1 Independentcustomer master data

Recommended ControlPlans

Control Goals of the Operations Process Control goals of the information processEnsure Effective of

operations

Ensure efficient employment of

resources(people, computers)

Ensure security of resources

(inventory,

For sales order inputs

(i.e.,customer orders),Ensure:

For sales order and inventory

master data,ensure:

For shipping notice inputs (i.e.,shipment data),ensure:

For sales order

master data,ensure:

Control goals of the OE/S Business Process

32

2.5 Pengertian Object Oriented Analysis and Design ( OOA&D )

Mengacu pada pendapat Mathiassen, Munk-Madsen, Nielsen dan Stage (2000,

p.12), “OOA&D is a collection of general guidelines for carrying out analysis and

design. OOA&D ‘s main activities: problem-domain analysis, application-domain

analysis,a rchitectural design, and component design.”.

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.1 Aktifitas Utama

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

analisa dan desain berorientasi objek ditunjukkan dalam gambar berikut.

33

Problem-domainanalysis

Application-domainanalysis

Componentdesign

Architecturaldesign

Model

Requirements foruse

Specification ofcomponents

Specifications ofarchitecture

Gambar 2.2 Aktivitas utama dan hasilnya dalam analisa dan desain

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

2.5.2 Rich Picture

Menurut Mathiassen et al.(2000, p26-27) Rich Picture adalah sebuah

gambaran informal yang digunakan oleh pengembang system untuk

menyatakan pemahaman mereka terhadap situasi dari system yang sedang

berlangsung.

Rich picture berfokus pada aspek – aspek yang penting dari situasi yang

ada. Meskipun begitu, rich picture harus menggambarkan secara keseluruhan

dari situasi yang ada, yang dapat menimbulkan interpretasi alternatif

2.5.3 System Definition

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

ringkas dari sistem terkomputerisasi yang diekspresikan dalam bahasa natural.

Tujuan system definition adalah untuk memilih sistem aktual yang akan

dikembangkan. Hal ini dilakukan dengan mengklarifikasi interpretasi,

kemungkinan dan konsekuensi dari beberapa solusi alternatif secara sistematis.

34

2.5.4 FACTOR Criterion

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

enam elemen, yaitu :

1. Functionality : Fungsi – fungsi system yang mendukung tugas

application domain

2. Application domain : Bagian – bagian dalam organisasi yang

mengadministrasi, memonitor, atau mengendalikan sebuah problem

domain.

3. Conditions : Kondisi – kondisi yang dibawahnya sistem akan

dikembangkan dan digunakan.

4. Technology : Teknologi yang digunakan untuk mengembangkan sistem

dan teknologi yang daripadanya sistem akan dijalankan.

5. Objects : Objek – objek utama dari problem domain.

6. Responsibility : Tanggung jawab keseluruhan sistem yang berkaitan

dengan konteksnya.

2.5.5 Problem Domain Analysis

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

konteks yang diatur, di monitor, atau dikendalikan oleh sistem. Analisa

problem domain memfokuskan pada informasi apa yang harus ditangani oleh

sistem dan menghasilkan sebuah model yang merupakan gambaran dari class,

objek, struktur dan perilaku (behaviour) yang ada dalam problem domain.

Aktivitas yang dilakukan pada analisis problem domain, yaitu:

35

Tabel 2.3 Kerangka Problem Domain Analysis ( Sumber Mathiassen, 2000, p48 )

Kegiatan Isi Konsep Class Objek dan event mana yang merupakan

bagian problem domain Class, Objek, Event

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

Generalisasi, Agregasi, Asosiasi, dan Cluster

Behaviour Properti dinamik mana yang dimiliki objek Event trace, Behavioural pattern, dan Attribute

2.5.5.1 Class

Menurut Mathiassen et al. (2000, p49), Class adalah sekumpulan

objek yang membagikan struktur, behavioural pattern, dan atribut.

Kegiatan class merupakan kegiatan pertama dalam analisis problem

domain. Ada beberapa tugas utama dalam kegiatan ini, yaitu : abstraksi

fenomena dari problem domain dalam objek dan event; klasifikasi objek

dan event; seleksi class dan event yang akan dipelihara informasinya

oleh sistem.

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

yang memiliki identitas, status, dan perilaku (behaviour). Event adalah

kejadian secara terus – menerus yang melibatkan satu atau lebih objek.

Kegiatan Class akan menghasilkan sebuah Event Table. Seperti yang

terlihat pada tabel 2.3 dibawah. Dimensi horisontal berisi class – class

yang terpilih, dimensi vertikal berisi event – event terpilih. Sebuah tanda

cek digunakan untuk mengindikasikan objek – objek dari class yang

berhubungan dalam event tertentu.

36

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

Classes Events Customer Assistant Apprentice Appointment Plan

Reserved Cancelled Treated

Employed Resigned

Graduated Agreed

2.5.5.2 Structure

Menurut Mathiassen et al. (2000, p69) kegiatan kedua dalam analisis

problem domain ini bertujuan untuk mencari hubungan struktural yang

abstrak dan umum antara class – class serta mencari hubungan yang

konkrit dan spesifik antara objek – objek dalam problem domain.

Menurut Mathiassen et al. (2000, p70) object-oriented structure bisa

dibagi menjadi :

1. 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). Di mana hubungan

spesialisasi tersebut dapat dinyatakan dengan rumus “is-

a”.

37

Person

Customer Employee

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

b. Cluster adalah kumpulan class yang saling berkaitan.

cluster digambarkan dengan notasi file folder yang

mencakup class – class di dalamnya. Class dalam cluster

yang sama dihubungkan dengan generalization ataupun

aggregation, sedangkan class yang berada pada cluster

yang berbeda dihubungkan dengan association.

<< cluster>>Cars

Car

TaxiCylinder

PassengerCarEngine

1*

1*

Gambar 2.4 Cluster Structure

( Sumber : Mathiassen, et al., 2000, p75 )

2. Structure antar objek, terdiri dari :

a. Aggregation adalah objek superior (keseluruhan) yang

terdiri dari sejumlah objek inferior (bagian). Hubungan ini

dapat dinyatakan dengan rumus “has-a” atau “is-part-of”.

Terdapat tiga struktur agregasi, yaitu :

38

1

1

1

4..*

Car

Body Engine Wheel

1

1

Gambar 2.5 Aggregation Structure

( Sumber : Mathiassen, et al., 2000, p76 )

Whole part, yang mana objek superior merupakan

penjumlahan dari objek inferior, jika objek inferior

tersebut ditambah atau dihilangkan, akan mengubah total

objek superior.

Container-Content, yang mana objek superior

adalah container untuk objek inferior. Objek superior

tidak akan berubah jika terjadi penambahan atau

penghapusan objek inferior.

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.

b. Association adalah hubungan antara sejumlah objek yang

memiliki arti di mana objek – objek yang saling

berhubungan tersebut bukan merupakan bagian dari objek

yang lainnya.

39

Car Person0..* 1..*

Gambar 2.6 Association Structure

( Sumber : Mathiassen, et al., 2000, p77 )

Hasil dari kegiatan struktur ini adalah class diagram, yakni ringkasan

model problem domain yang jelas dengan menggambarkan semua

struktur hubungan static antar class dan objek yang ada dalam model dari

sistem yang berubah – ubah.

2.5.5.3 Behaviour

Menurut Mathiassen et al. (2000, p89) 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 (behavioral pattern) dari event trace,

mempelajari events yang sering digunakan, dan atribut setiap class dari

behavioural patterns. Hasil dari kegiatan ini adalah statechart diagram

yang dapat dilihat pada gambar 2.7 :

40

-name-address-balance

Customer

Open

amount deposited( date, amount )

amount withdrawn( date, amount )

account opened (date )

account closed( date )

Gambar 2.7 Statechart diagram untuk class “ Customer “

( Sumber : Mathiassen, et al., 2000, p90 )

Perilaku dari suatu objek ditentukan oleh urutan event – event (event

trace) yang harus dilewati oleh objek tertentu tersebut sepanjang waktu.

sebagai contoh : kelas ”pelanggan” harus melalui event trace : account

opened – amount deposited – amount withdrawn – amount deposited –

account closed sepanjang masa hidupnya.

Menurut Mathiassen et al., (2000, p93) Tiga jenis notasi untuk

behavioural pattern yaitu :

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

2. Selection, dimana terjadi pemilihan satu event dari sekumpulan

event yang muncul

3. Iteration, dimana sebuah event muncul sebanyak nol atau

beberapa kali.

2.5.6 Application Domain Analysis

Menurut Mathiassen et al (2000, p115) Application domain adalah

organisasi yang mengadministrasi, memonitor, dan mengontrol problem

domain. Analisa Application domain memfokuskan pada bagaimana target

41

sistem akan digunakan dengan menentukan kebutuhan function dan antarmuka

sistem. Hasilnya berupa daftar yang lengkap tentang kebutuhan sistem secara

keseluruhan.

Aktivitas yang dilakukan pada application domain, yaitu:

Tabel 2.5 Kerangka Application Domain ( Sumber : Mathiassen,et al., 2000, p117 )

Kegiatan Isi Konsep Usage Bagaimana sistem berinteraksi dengan orang

lain dan dengan sistem lain dalam konteks Usecase dan Actor

Function Bagaimana kemampuan sistem dalam memproses informasi

Function

Interface Kebutuhan antarmuka dari sistem target Interface, User interface, dan sistem interface

2.5.6.1 Usage

Menurut Mathiassen et al. (2000, p119) kegiatan usage merupakan

kegiatan pertama dalam analisa application domain yang bertujuan

untuk menentukan bagaimana aktor – aktor yang merupakan pengguna

atau sistem lain berinteraksi dengan sistem yang dituju.

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.

Interaksi antara aktor dengan sistem tersebut dinyatakan dalam

usecase. Usecase dapat dimulai oleh aktor atau oleh sistem target. Hasil

dari analisa kegiatan usage ini adalah deskripsi lengkap dari semua

usecase dan aktor yang ada yang digambarkan dalam tabel aktor atau

usecase diagram.

42

AutomaticPaymentSystem

payment

cash withdrawal

money transfer

account information

credit information

registration

monitoring

error correction

Account owner

creditor

Liquidity monitor

Administrator

Gambar 2.8 Use case diagram dari automatic payment system

( Sumber : Mathiassen, et al., 2000, p122 )

2.5.6.2 Function

Menurut Mathiassen et al. (2000, p137) kegiatan function merupakan

kegiatan kedua dalam application domain. Function memfokuskan pada

bagaimana cara sebuah sistem dapat membantu actor dalam

melaksanakan pekerjaan mereka.

Menurut Mathiassen et al. (2000, p138) 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 domain atau problem

43

domain. Fungsi direalisasi melalui operasi program ( program

operations ).

Tujuan dari kegiatan function adalah untuk menentukan kemampuan

sistem memproses informasi. Hasil dari kegiatan ini adalah sebuah daftar

function – function yang merinci function – function yang kompleks.

Daftar function harus lengkap, menyatakan kebutuhan kolektif dari

pelanggan dan aktor dan harus konsisten dengan usecase.

Function memiliki empat tipe yang berbeda, yaitu :

1.Update function : disebabkan oleh event problem domain dan

menghasilkan perubahan dalam state model tersebut.

2. Signal function : disebabkan oleh perubahan keadaan atau state

dari model yang dapat menghasilkan reaksi pada konteks. Reaksi

ini dapat berupa tampilan bagi aktor dalam application domain,

atau intervensi langsung dalam problem domain.

3. Read function : disebabkan oleh kebutuhan informasi dalam

pekerjaan aktor dan mengakibatkan sistem menampilkan bagian

yang berhubungan dengan informasi dalam model.

4. Compute function : disebabkan oleh kebutuhan informasi dalam

pekerjaan aktor dan berisi perhitungan yang melibatkan informasi

yang disediakan oleh aktor atau model, hasil dari function ini

adalah tampilan dari hasil komputasi.

44

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

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

2.5.6.3 Interface

Interface merupakan kegiatan ketiga dalam application domain.

Menurut Mathiassen et al. (2000, p151) interface digunakan oleh actor

untuk berinteraksi dengan sistem.

Kegiatan interface memiliki tiga konsep, yaitu :

45

1. Interface, yaitu fasilitas yang membuat model sisten dan

fungsi dapat digunakan oleh aktor

2. User Interface, adalah interface yang menghubungkan

user dengan sistem

3. System Interface, adalah interface yang menghubungkan

sistem satu dengan sistem lain.

Terdapat empat jenis pola dialog yang penting dalam menentukan

user interface, yaitu :

1. Menu-selection yang menampilkan pilihan – pilihan menu

dalam user interface

2. Form fill in yang merupakan pola klasik untuk entri data

3. Command language dimana user memasukkan dan

mengaktifkan format perintah sendiri

4. Direct manipulation dimana user memilih objek dan

melaksanakan function atas objek dan melihat hasil dari

interaksi mereka tersebut.

Kegiatan analisa user interface ini berdasarkan pada hasil dari

kegiatan analisa lainnya yaitu model problem domain, kebutuhan

functional dan usecase. Hasil dari kegiatan ini adalah sebuah

deskripsi elemen – elemen user interface dan system interface yang

lengkap, dimana kelengkapan menunjukkan pemenuhan kebutuhan

pengguna. Hasil dari kegiatan user interface berupa form presentasi

dan dialogue style, diagram window terpilih, dan diagram navigasi.

Sedangkan hasil dari system interface berupa class diagram untuk

46

peralatan dan protocol eksternal untuk berinteraksi dengan sistem

yang 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.

2.5.7 Architectural Design

Menurut Mathiassen et al. (2000, p173) keberhasilan suatu sistem

ditentukan oleh kekuatan desain arsitekturalnya. Arsitektur membentuk 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

47

untuk menyusun struktur dari sistem yang terkomputerisasi. Hasil akhir dari

aktivitas ini adalah komponen dan proses dari sebuah sistem.

Aktivitas yang dilakukan pada architecture design, yaitu:

Tabel 2.7 Aktivitas dalam architectural design ( Sumber : Mathiassen, et al., 2000, p176 )

Kegiatan Isi Konsep

Kriteria Kondisi dan kriteria untuk pendesainan Criterion

Komponen Bagaimana sistem dibentuk menjadi komponen – komponen

Arsitektur komponen

Proses Bagaimana proses sistem didistribuasikan dan dikoordinasi

Arsitektur proses

2.5.7.1 Criteria

Menurut Mathiassen et al. (2000, p177) Karena tidak ada cara – cara

tertentu atau mudah untuk menghasilkan suatu desain yang baik, banyak

perusahaan menciptakan suatu standard dan prosedur untuk memberikan

jaminan terhadap kualitas sistem. Disinilah kegiatan kriteria dapat

membantu dengan menetapkan prioritas desain untuk setiap proyek

tertentu.

Menurut Mathiassen et al. (2000, p177-181) Sebuah desain yang baik

memiliki tiga ciri – ciri, yaitu :

1. Tidak memiliki kelemahan

Syarat ini menyebabkan adanya penekanan pada evaluasi dari kualitas

berdasarkan review dan eksperimen dan membantu dalam

menentukan prioritas dari kriteria yang akan mengatur dalam kegiatan

pendesainan.

48

Dibawah ini adalah beberapa kriteria umum yang digunakan dalam

kegiatan desain yang berorientasi objek :

Tabel 2.8 Kriteria Umum

( Sumber: Mathiassen, et al., 2000, p178 ) Criterion Ukuran dari

Usable Kemampuan sistem untuk menyesuaikan diri dengan konteks, organisasi yang berhubungan dengan pekerjaan dan teknis

Secure Ukuran keamanan sistem dalam menghadapi akses yang tidak terotorisasi terhadap data dan fasilitas

Efficient Eksploitasi ekonomis terhadap fasilitas platform teknis

Correct Pemenuhan dari kebutuhan

Reliable Pemenuhan ketepatan yang dibutuhkan untuk melaksanakan fungsi

Maintanaibel Biaya untuk menemukan dan memperbaiki kerusakan

Testable Biaya untuk memastikan bahwa sistem yang dibentuk dapat melaksanakan fungsi yang diinginkan

Fleksible Biaya untuk mengubah sistem yang dibentuk

Comprehensible Usaha yang diperlukan untuk mendapatkan pemahaman terhadap sistem

Reusable Kemungkinan untuk menggunakan bagian sistem pada sistem lain yang berhubungan

Portable Biaya untuk memindahkan sistem ke platform teknis yang berbeda

Interoperable Biaya untuk menggabungkan sistem ke sistem yang lain.

2. Menyeimbangkan beberapa criteria

Konflik sering terjadi antar criteria, oleh sebab itu untuk menentukan

criteria mana yang akan diutamakan dan bagaimana cara untuk

menyeimbangkannya dengan criteria – criteria yang lain bergantung

pada situasi sistem tertentu.

49

3. Usable, flexible, dan comprehensible

Kriteria – criteria ini bersifat universal dan digunakan pada hampir

setiap proyek pengembangan system.

2.5.7.2 Component Architecture

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

adalah sebuah struktur sistem yang terdiri dari komponen – komponen

yang saling berhubungan. Component architecture membuat sistem lebih

mudah untuk dimengerti, menyederhanakan desain, dan mencerminkan

kestabilan sistem. Hal ini dikarenakan komponen merupakan subsistem

dari sebuah sistem. Component adalah sebuah kumpulan bagian – bagian

program yang merupakan satu kesatuan dan memiliki tanggung jawab

yang telah didefinisikan dengan baik.

Menurut Mathiassen et al. (2000, p193-197) beberapa pola umum

dalam desain komponen arsitektur adalah :

1. Layered-architecture pattern

Merupakan bentuk yang paling umum dalam software. Sebuah

arsitektur layered terdiri dari beberapa komponen yang dibentuk

menjadi lapisan – lapisan dimana lapisan yang berada di atas

bergantung kepada lapisan yang ada di bawahnya. Perubahan

yang terjadi pada suatu lapisan akan mempengaruhi lapisan di

atasnya.

50

Gambar 2.9 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. Dimana komponen

model terleteak pada lapisan yang paling bawah, kemudian

dilanjutkan dengan function layer dan paling atasnya komponen

interface.

Gambar 2.10 Generic Architecture Pattern

( Sumber : Mathiassen, et al., 2000, p196 )

3. Client-server architecture pattern

Pola ini awalnya dikembangkan untuk mengatasi masalah sistem

yang terdistribusi di antara beberapa prosessor yang tersebar

51

secara geografis. Komponen pada arsitektur ini adalah sebuah

server dan beberapa client. Tanggung jawab daripada 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, di dalam

perancangan sistem atau subsistem, pada umumnya dimulai

dengan layer architecture dan client server architecture dimana

keduanya merupakan dua layer yang berbeda, tetapi saling

melengkapi.

Gambar 2.11 Client Server Architecture Pattern

( Sumber : Mathiassen, et al., 2000, p197 )

Menurut Mathiassen et al. (2000, p200) terdapat beberapa jenis

distribusi dalam arsitektur client server dimana U (User Interface), F

(Function), M (Model).

Tabel 2.9 Jenis Arsitektur Client-Server

( Sumber Mathiassen et al., 2000, p200 )

Client Server Architecture

U U+F+M Distributed Presentation

U F+M Local Presentation

52

U+F F+M Distributed Functionality

U+F M Centralized Data

U+F+M M Distributed Data

2.5.7.3 Process Architecture

Menurut Mathiassen et al. (2000, p209) Process architecture adalah

stuktur dari eksekusi system yang terdiri dari proses – proses yang saling

bergantung. Hasilnya berupa deployment diagram. 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 deploymeny diagram.

Menurut Mathiassen et al. (2000, p215-219) terdapat tiga jenis pola

distribusi, yaitu :

1. Centralized pattern

Pola ini menyimpan semua data pada server pusat dan user hanya

bisa melihat user interface saja. Keuntungan adalah dapat

diimplementasikan pada client secara murah, semua data

konsisten karena hanya berada di satu tempat, strukturnya mudah

dimengerti dan diimplementasikan, dan kemacetan jaringannya

moderat.

53

: Client

user interface

system interface

: Server

function

user interface system interface

model

moreclients

Gambar 2.12 Centralized Pattern

( Sumber : Mathiassen, et al., 2000, p216 )

2. Distributed pattern

Semua data terdisribusi ke user atau client dan server hanya

menyebarkan model yang telah di update diantara client.

Keuntungannya adalah waktu akses yang rendah kinerja lebih

maksimal, dan back-up data banyak. Kerugiannya adalah

redundansi data sehingga konsistensi data terancam, kemacetan

jaringan tinggi, arsitektur sulit dipahami dan diimplementasikan.

54

: Client

: Server

system interface

function

user interface system interface

model

moreclients

Gambar 2.13 Distributed Pattern

( Sumber : Mathiassen, et al., 2000, p217 )

3. Decentralized pattern client

Pola ini berada di antara kedua pola di atas. Di sini client

memiliki data tersendiri sehingga data umumnya berada pada

server. Server menyimpan data umum dan fungsi atas data – data

tersebut, sedangkan client menyimpan data milik application

domain client. Keuntungannya adalah konsistensi data, tidak ada

duplikasi data, lalu lintas jaringan jarang karena jaringan hanya

digunakan data umum di server di update. Kekurangannya adalah

semua processor harus mampu melakukan fungsi yang kompleks

dan memelihara model dalam jumlah besar sehingga

meningkatkan biaya hardware.

55

: Client

function

user interface system interface

model ( local )

moreclients

: Server

function

user interface system interface

model ( common )

Gambar 2.14 Decentralized Pattern

( Sumber : Mathiassen, et al., 2000, p219 )

2.5.8 Component Design

Menurut Mathiassen et al. (2000, p231) Tujuan dilakukannya component

design adalah untuk menentukan implementasi kebutuhan dalam kerangka

arsitektural. Kegiatan component design bermula dari spesifikasi arsitektural

dan kebutuhan sistem, sedangkan hasil dari kegiatan ini adalah spesifikasi dari

komponen yang saling berhubungan.

Aktivitas yang dilakukan dalam component design, yaitu :

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

Kegiatan Isi Konsep Model Component Bagaimana suatu model digambarkan

sebagai kelas dalam sebuah sistem Model component and

attribute Function Component Bagaimana suatu function

diimplementasikan Function component

and operation Connecting Component Bagaimana komponen – komponen

dihubungkan Component and

connector

56

2.5.8.1 Model Component

Menurut Mathiassen et al. (2000, p236) 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.

-creditapproval-creditapprovaldate-name

Customer

-fromdate-address

Customer Address-accountnumber-accountstate-opendate-closedate

Account

-transtype-date-amount

Transaction

1

1..*

1

1..*

10..*

Gambar 2.15 Revised class diagram

( Sumber : Mathiassen, et al., 2000, p236 )

Menurut Mathiassen et al. (2000, p243-246) Revisi class dapat terjadi

pada :

1. Generalization

Jika terdapat dua class dengan atribut yang sama maka dapat

dibentuk class baru (revised class).

57

-account number-accountstate-opendate-closedate

Account

-date-amount

Deposit

-date-amount

Withdraw-transtype-date-amount

Transaction

-account number-accountstate-opendate-closedate

Account

1

0..*

1

0..*

1

0..*

solusi awal solusi yang lebih sederhana Gambar 2.16 Menyusun kembali class diagram

( Sumber : Mathiassen, et al., 2000, p244 )

2. Association

Jika terdapat hubungan many-to-many

Gas Station0...* 0...*

Customer

Open Active

fill ( date, octane,volume, price )

start close buy carsell car

fill ( date, octane,volume, price )

Gas Station Customer

Filling

10..*

1

0..*

analysis model

design model Gambar 2.17 Contoh revisi class atas association

( Sumber : Mathiassen, et al., 2000, p245 )

3. Embedded iterations

Merupakan embedded di dalam ststechart diagram. Misalnya jika

sebuah class terdapat statechart diagram yang mempunyai tiga

iterated events maka kita dapat membentuk tiga class di dalam

perancangan model.

58

Person

Hospitalization Treatment Discharge

1

0..*1

0...* 0...*

1

Person Well Hospitalizedbirth hospitalized

discharge

treat

deathdeath

analysis model

design model Gambar 2.18 Contoh revisi class atas embedded iterations

( Sumber : Mathiassen, et al., 2000, p246 )

2.5.8.2 Function Component

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

bagian dari sistem yang mengimplmentasikan kebutuhan fungsional.

Operations adalah properti dari proses yang dispesifikasikan dalam

sebuah class dan diaktifkan melalui objek dari class.

Hasil utama dari kegiatan ini adalah class diagram dengan operation

dan specification dari operation yang kompleks.

Menurut Mathiassen et al. (2000, p255-260) terdapat empat tipe

fungsi dan operation yang terkait yakni :

1. Update

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.

59

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

update() update()

update-refused()

update-successful()

update()

update-refused()

update-successful()failure()

()

Gambar 2.19 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.

60

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

read()

not-found()

result()

read()

not-found()

result()result()

read()

Gambar 2.20 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.

61

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

read()

not-found()

result()

read()

not-found()

result()result()

compute()

Gambar 2.21 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.

62

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

critical()

result()

critical()

result()

signal()

activate()

()

Gambar 2.22 Signal function dan operasinya

( Sumber : Mathiassen, et al., 2000, p259 )