BAB 2 LANDASAN TEORI

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

Control Environment subkomponen : - filosofi dan gaya operasi manajemen - integritas dan nilai etika - komitmen terhadap kompetensi - dewan direksi dan komite audit - struktur organisasi

Risk Assesment

Control Activities

Information and Communication

pertimbangan utama :

pertimbangan utama :

- identifikasi resiko internal yang signifikan

- identifikasi dan perolehan informasi yang relevan dengan pelaporan keuangan - komunikasi informasi yang relevan dalam format yang tepat

- identifikasi resiko external yang signifikan - menyiapkan analisa resiko - manajemen resiko yang relevan

Monitoring pertimbangan utama : - aktivitas yang terus menerus - evaluasi secara terpisah

- penetapan wewenang dan tanggung jawab - kebijakan dan praktik sumber daya manusia

aktivitas yang berhubungan dengan pelaporan keuangan

aktivitas yang berhubungan dengan pemrosesan informasi

subkomponen : - desain dokumen yang baik dan dokumen serta record bernomor urut

general control

application control

- pemisahan tugas - otorisasi transaksi - ukuran keamanan dan perlindungan yang cukup - pengecekan kinerja secara independen - pemeriksaan tepat atas 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, p241247), 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.

b.

2.

Identify operations process goals : •

Effectiveness goals

•

Efficiency goals

•

Security goals

Identify information process goals : •

Input goals ( input validity, completeness, dan accuracy)

•

Update goals ( Update completeness, dan accuracy)

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)

Recommended Plans

Control goals of the OE/S Business Process Control Goals of the Operations Process Control goals of the information process Ensure Ensure Effective of Ensure efficient For sales For shipping For sales order For sales order security of employment of order notice inputs and inventory inputs Control resources resources(people, master (i.e.,shipment master (i.e.,customer operations (inventory, orders),Ensure: data,ensure: computers) data,ensure: data),ensure: A B C D IV IC IA UC UA IV IC IA UC UA

Present Controls P-1 Enter customer order close to where the order is received P-2 Preformatted screens P-3 Online prompting P-4 Interactive feedback check P-5 Customer credit check P-6 Populate inputs with master data P-7 Programmed edit checks P-8 One for one checking of picking tickets with the goods P-9 receive&inputs turnaround document (picking ticket)

P-1 P-1 P-2 P-2 P-3 P-3

P-1 P-2 P-3

P-1 P-2 P-3

P-5 P-6 P-6

P-6

P-7 P-7

P-7

P-7

P-8

P-8

P-9

P-9

P-5

P-5

P-6

P-6

P-8

P-1 P-1 P-2 P-3

P-1

P-4

P-4

P-1 P-2 P-3 P-4

P-6

P-6

P-7

P-7

P-4

P-6

P-6

P-8

P-8

P-9

P-9

P-6

31

Tabel 2.2 Control matrix untuk proses bisnis dari penjualan (Lanjutan) (Sumber : Gelinas et. al., 2005 p376 – 377) Control goals of the OE/S Business Process Control Goals of the Operations Process Control goals of the information process For sales For shipping For sales order For sales order Ensure Ensure Effective of Ensure efficient security of order notice inputs and inventory inputs employment of master (i.e.,shipment master (i.e.,customer resources(people, resources Recommended Control (inventory, data),ensure: data,ensure: orders),Ensure: data,ensure: computers) operations Plans A B C D IV IC IA UC UA IV IC IA UC UA P-10 Independent shipping authorization P-10 P-10 P-11 Compare input with master data P-11 P-11 P-11 P-11 P-11 P-12 one for one checking of goods, picking ticket,sales order P-12 P-12 P-12 P-12 Missing-control M-1 Independent customer master data M-1 M-1 M-1 M-2 Review open sales order(tickler file) M-2 M-2 M-2 Legend : Effectiveness goals : IV = Input Validity A= Provide timely response to customer inquiries IC = Input Completeness B=Provide timely acknowledgment of customer orders IA = Input Accuracy C=Provide assurance of customer`s creditworthiness UC = Update completeness D=Provide timely shipment of goods to customers. UA = Update Accuracy

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

Requirements for use

Problemdomain analysis

Model

Component design

Applicationdomain analysis

Specification of components

Specifications of architecture

Architectural design

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

Kegiatan Class

Structure

Tabel 2.3 Kerangka Problem Domain Analysis ( Sumber Mathiassen, 2000, p48 ) Isi Konsep Objek dan event mana yang merupakan Class, Objek, Event bagian problem domain Bagaimana class dan objek saling terkait satu sama lain secara konseptual

Behaviour Properti dinamik mana yang dimiliki objek

Generalisasi, Agregasi, Asosiasi, dan Cluster 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

Events Reserved Cancelled Treated Employed Resigned Graduated Agreed

Tabel 2.4 Contoh Event Tabel ( Sumber : Mathiassen, et al. , 2000, p50 ) Classes Customer Assistant Apprentice Appointment 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9

Plan 9

9

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 “isa”.

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 *

1

Engine

Passenger Car

1 * Cylinder

Taxi

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 Car 1

1 Body

1

1

4..*

1 Engine

Wheel

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 0..* Car

1..* Person

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 account opened ( date )

Customer

account closed ( date )

-name -address -balance

Open amount deposited ( date, amount ) amount withdrawn ( date, amount )

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:

Kegiatan Usage Function Interface

Tabel 2.5 Kerangka Application Domain ( Sumber : Mathiassen,et al., 2000, p117 ) Isi Konsep Bagaimana sistem berinteraksi dengan orang Usecase dan Actor lain dan dengan sistem lain dalam konteks Bagaimana kemampuan sistem dalam Function memproses informasi 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 Automatic Payment System payment

cash withdrawal

Liquidity monitor

Account owner

money transfer

account informatio n

credit information

Administrator

creditor

registration

monitoring

error correction

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

Function

Tabel 2.6 Function List ( Sumber : Mathiassen, et al., 2000, p145 ) 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

pembacaan terhadap external device.

perlu

melakukan

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

mempengaruhi.

karena

antar

sistem

dapat

saling

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:

Kegiatan

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

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

Konsep

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 Criterion

( Sumber: Mathiassen, et al., 2000, p178 ) 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

more clients system interface

: Server

user interface

system interface

function

model

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

user interface

system interface

function

model

more clients : Server

system interface

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

meningkatkan biaya hardware.

jumlah

besar

sehingga

55 : Client

user interface

system interface

function

model ( local )

more clients : Server

user interface

system interface

function

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 Bagaimana suatu model digambarkan Model component and Model Component sebagai kelas dalam sebuah sistem attribute Bagaimana suatu function Function Component Function component diimplementasikan and operation Connecting Component Bagaimana komponen – komponen Component and dihubungkan 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. Customer -creditapproval -creditapprovaldate -name

1

1

1..* Customer Address -fromdate -address

1..* Account -accountnumber -accountstate -opendate -closedate

1 0..* Transaction -transtype -date -amount

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

Account

-account number -accountstate -opendate -closedate

-account number -accountstate -opendate -closedate

1

1

1

0..*

0..*

0..*

Deposit

Transaction

Withdraw

-date -amount

-transtype -date -amount

-date -amount

solusi yang lebih sederhana

solusi awal

Gambar 2.16 Menyusun kembali class diagram ( Sumber : Mathiassen, et al., 2000, p244 )

2. Association Jika terdapat hubungan many-to-many 0...*

0...*

Gas Station

Customer fill ( date, octane, volume, price )

fill ( date, octane, volume, price ) buy car

close

start

sell car Active

Open

analysis model Customer

Gas Station

1 1 0..*

0..*

Filling 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

treat

birth

hospitalized Well

Person

Hospitalized

discharge death death

analysis model Person 1

1

1

0..*

0...*

0...*

Hospitalization

Treatment

Discharge

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

update()

object1:Model-Class1

object2:Model-Class2

update() update-refused() update-successful()

update() update-refused() failure()

update-successful()

()

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

read()

object1:Model-Class1

object2:Model-Class2

read() not-found() result()

read() not-found() result()

result()

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

compute()

object1:Model-Class1

object2:Model-Class2

read() not-found() result()

read() not-found() result()

result()

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

activate()

object1:Model-Class1

object2:Model-Class2

critical() result()

critical() () result() signal()

Gambar 2.22 Signal function dan operasinya ( Sumber : Mathiassen, et al., 2000, p259 )