BAB 2 LANDAS AN TEORI
2.1 Pengertian Sistem M enurut Hall (2001,p.5), sistem adalah sekelompok dua atau lebih komponen yang saling berkaitan atau subsistem – subsistem yang bersatu untuk mencapai tujuan yang sama. M enurut Romney dan Steinbart (2006,p.4), ”system is a set of two or more interrelated components that interact to achieve a goal” Jadi dapat disimpulkan bahwa sistem merupakan sekelompok komponen / elemen yang saling berhubungan satu dengan yang lainnya untuk mencapai tujuan yang sama.
2.2 Pengertian Sistem Informasi M enurut O’Brien (2005,p5), sistem informasi dapat merupakan kombinasi teratur apa pun dari orang – orang , hardware, software, jaringan komunikasi, dan sumber daya data yang mengumpulkan, mengubah, dan menyebarkan informasi dalam sebuah organisasi. M enurut Hall (2001,p.7), sistem informasi adalah sebuah rangkaian prosedur formal dimana data dikumpulkan, diproses menjadi informasi dan didistribusikan kepada para pemakai.” Dilihat dari dua definisi diatas dapat ditarik kesimpulan bahwa sistem informasi merupakan kombinasi dari orang, perangkat, data dan sumber daya lainnya yang dapat menghasilkan informasi yang dibutuhkan bagi pemakainya.
10 2.3 Sistem Informasi Akuntansi 2.3.1
Pengertian Sistem Informasi Akuntansi M enurut Wilkinson, Cerullo, Vasant and Bernard (2000, p.7), ”Accounting
information system is a unifed structure within an entity, such as a business firm, that employs physical resources and other components to transform economic data into accounting information, with the purpose of satisfying the information needs of a variety of users”. Kutipan diatas dapat diterjemahkan, sistem informasi akuntansi adalah sebuah struktur kesatuan di dalam suatu entitas, seperti perusahaan bisnis, yang mempekerjakan sumber daya fisik dan komponen – komponen lainnya untuk mengubah data ekonomi ke dalam informasi akuntansi. M enurut Romney dan Steinbart (2006,p.6), ” Accounting information system is a system that collect, record, stores, and prosesess data to produce information for decition makers” , yang dapat diterjemahkan bahwa sistem informasi akuntansi adalah sistem yang menggumpulkan, mencatat, menyimpan, dan memproses data menjadi informasi untuk pengambilan keputusan. Dari beberapa definisi diatas dapat disimpulkan bahwa sistem informasi akuntansi merupakan suatu sistem yang merupakan suatu kesatuan dari entitas yang mampu mengumpulkan, mencatat, menyimpan dan memproses data menjadi informasi yang berguna bagi pemakainya dalam mengambil keputusan penting dalam perusahaan.
11 2.3.2
Tujuan dan Kegunaan Sistem Informasi Akuntansi M enurut Wilkinson et al. (2000, p.8), tujuan dan kegunaan dari Sistem
Informasi Akuntansi adalah : 1. M endukung operasional sehari – hari 2. M endukung pengambilan keputusan bagi pengambil keputusan internal. 3. Untuk memenuhi kewajiban atau tanggung jawab yang sesuai dengan jabatannya. M enurut Romney dan Steinbart (2006,p.8-9), sebuah Sistem Informasi Akuntansi yang dirancang dengan baik dapat melakukan hal – hal berikut ini : 1. M eningkatkan kinerja dan menurunkan biaya dari barang dan jasa. 2. M eningkatkan efisiensi. 3. M eningkatkan pengambilan keputusan. 4. M embagi pengetahuan.
2.3.3
Komponen – Komponen Sistem Informasi Akuntansi M enurut pendapat Romney dan Steinbart (2006,p.6-7) dapat disimpulkan
bahwa, ” Sistem Informasi terdiri dari enam komponen, yaitu : 1. People, yang mengopersikan sistem dan menampilkan berbagai fungsi. 2. Prosedures and instructions, baik manual maupun otomatis termasuk dalam kegiatan pengumpulan, pemprosesan, dan penyimpanan data tentang kegiatan organisasi 3. Data, tentang organisasi dan proses bisnis organisasi. 4. Software, digunakan untuk memproses data organisasi.
12 5. Information technology infrastucture, termasuk komputer, peripheral devices, dan peralatan jaringan komunikasi yang digunakan untuk mengumpulkan, memproses, meyimpan dan mentransformasikan data dan informasi. 6. Internal control and security meansures, yang menjaga keamanan data dalam Sistem Informasi Akuntansi.”
2.4
Sistem Informasi Akuntansi Penjualan , Piutang Usaha dan Penerimaan Kas
2.4.1
Pengertian Penjualan M enurut Standar Akuntansi Keuangan (2007), “Pendapatan dari penjualan
barang harus diakui bila seluruh kondisi berikut dipenuhi : a) Perusahaan telah memindahkan risiko secara signifikan dan memindahkan manfaat kepemilikan barang kepada pembeli; b) Perusahaan tidak lagi mengelola atau melakukan pengendalian efektif atas barang yang dijual; c) Jumlah pendapatan tersebut dapat diukur dengan andal; d) Besar kemungkinan manfaat ekonomi yang dihubungkan dengan transaksi akan mengalir kepada perusahaan tersebut; dan e) Biaya yang terjadi atau yang akan terjadi sehubungan transaksi penjualan dapat diukur dengan modal.” (P SAK no 23 paragraf 13) M enurut Warren, Reeve dan Fees (2002,p.231), ” revenue from merchandise sales is usually identified in the ledger as Sales.
13 M aka dapat disimpulkan bahwa penjualan merupakan transaksi antara penjual dan pembeli yang menyebabkan terjadinya perpindahaan barang atau pelayanan jasa yang dapat dilakukan secara tunai maupun kredit.
2.4.2
Pengertian Piutang Usaha Pengertian piutang usaha menurut Bodnar dan Hopwood (2004,p.727) adalah
” account receivable represents the money owned by customers for merchandise sold or service rendered on account” yang dapat diterjemahkan sebagai berikut piutang usaha merupakan uang yang terhutang oleh konsumen atas barang yang telah dijual atau jasa yang diberikan kepadanya. Piutang menunjukkan kredit konsumen dan informasi mengenai pembayaran yang telah dilakukan, yang bermanfaat bagi administrasi kebijakan kredit perusahaan secara keseluruhan. M enurut
Keiso,
Weygandt,
Warfield
(2004,p318),
piutang
usaha
didefinisikan sebagai ”claims held against customers and others for money, goods, or services.”, yang berarti bahwa piutang usaha merupakan klaim terhadap konsumen atas yang lainnya untuk uang, barang atau jasa. Dari dua definisi diatas dapat disimpulkan bahwa piutang usaha merupakan klaim uang terhadap konsumen atas barang yang telah dijual atau jasa yang telah diberikan.
2.4.3
Tujuan dan Kegunaan Sistem Informasi Akuntansi Penjualan M enurut pendapat Wilkinson et al. (2000,p.416) tujuan dari sistem informasi
akuntansi siklus pendapatan secara umum adalah : 1. M encatat order penjualan secara akurat dan cepat
14 2. M engidentifikasi pelanggan yang layak mendapat kredit 3. M engirimkan produk atau melakukan pelayanan pada waktu yang tepat 4. M enagih piutang usaha kepada pelanggan tepat pada waktunya 5. M encatat dan mengklasifikasi penerimaan kas secara tepat dan akurat. 6. M emposting penjualan dan penerimaan kas ke akun – akun yang berhubungan ke dalam buku besar piutang 7. M engamankan produk sampai pengiriman 8. M engamankan kas sampai di deposit
2.4.4
Dokumen Yang Berhubungan Dengan Siklus Pendapatan M enurut pendapat Wilkinson et al. (2000,p.419), dokumen yang dibutuhkan
pada penjualan adalah : 1. Customer Order M erupakan purchase order yang diterima oleh customer
atau form
yang
disiapkan oleh bagian penjualan dari perusahaan penjual 2. Sales Order Sebuah form yang formal, multicopy yang disiapkan dari customer order 3. Order Acknowledgment Biasanya copy dari sales order dikirimkan ke pelanggan untuk memperoleh dokumen penerimaan pesanan 4. Picking List M erupakan copy dari sales order atau dokumen terpisah yang dikirimkan ke gudang untuk digunakan dalam pengambilan barang yang dipesan 5. Picking Slip
15 Adalah copy dari sales order atau picking list yang ditempelkan bersama barang ketika dipersiapkan untuk pengiriman. 6. Billing of Lading Dokumen yang digunakan untuk perusahaan pengiriman yang akan mengirimkan produk 7. Shipping Notice Biasanya copy dari sales order atau dokumen pengiriman terpisah yang berfungsi sebagai bukti bahwa barang telah dikirimkan 8. Sales Invoice Dokumen yang dikirimkan kepada pelanggan untuk menyatakan berapa jumlah penjualan. 9. Remittance Advice Dokumen yang menunjukkan jumlah penerimaan kas dari pelanggan 10. Deposit Slip Dokumen yang menyertai penyetoran uang ke bank 11. Back Order Dokumen yang dipersiapkan ketika kuantitas dari persedia tidak mencukupi jumlah yang diminta pada sales order 12. Credit Memo Dokumen
yang
memungkinkan
pengurangan
kredit
pelanggan
pengembalian penjualan atau penyisihan penjualan. 13. Credit Application Form yang dipersiapakan ketika pelanggan baru mengajukan kredit 14. Salesperson Call Report
untuk
16 Form yang digunakan untuk menggambarkan panggilan yang dibuat oleh salesperson kepada pelanggan potensial dan mengidentifikasi hasil dari panggilan tersebut. 15. Delinquent notice Catatan yang dikirimkan kepada pelanggan yang melewati batas saldo kredit 16. Write-off Notice Dokumen yang dipisahkan oleh manajer kredit ketika akun dinyatakan tidak dapat di tagih 17. Cash Register Reciept Form yang menunjukkan kas yang diterima, yang digunakan retailer.
2.4.5
Fungsi – Fungsi Yang Terkait M enurut Wilkinson et al. (2000,p.417), unit – unit yang terkait dalam
penjualan adalah : 1. Marketing / Distribution Unit / bagian marketing mempunyai fungsi untuk meriset pasar dengan cara mempelajari sikap dan daya beli pelanggan, mempromosikan dan mengiklankan produk sesuai dengan strategi promosi yang telah dibuat, menangani permintaan dan keluhan pelanggan, mengembangkan dan merancang produk meliputi gaya, kemasan dan kinerja produk, konsentrasi penjualan pada peramalan penjualan yang telah dibuat, dan pengevaluasian hasil kinerja penjualan, pengapalan dan transportasi untuk mendistribusikan barang sesuai dengan order pelanggan pada waktu yang tepat, tidak rusak, dan sesuai dengan permintaan pelanggan.
17 2. Financial / Accounting Unit / bagian ini mempunyai tanggung jawab antara lain : budgeting dan cash planning membuat anggaran jangka pendek dan panjang serta melakukan peramalan kas, kredit dan collections mengembangkan kebijakan kredit dan penagihan serta pengaturan agar kebijakan kredit tersebut dipatuhi oleh masing – masing pelanggan; cash receipts menangani masalah penerimaan kas; billing menyiapkan sales invoice; inventory control memelihara keseimbangan persediaan; general ledger memelihara buku besar dari semua akun neraca dan rugi laba yang berasal dari laporan keuangan yang disiapkan.
2.4.6
Prosedur – Prosedur Terkait Dalam Penjualan dan Piutang Usaha M engacu pada Wilkinson et al. (2000, p.422), prosedur dalam yang tekait
dalam penjualan adalah : 1. order entry Setiap pemesanan dari pelanggan dientri kedalam sebuah form penjualan, pengentrian dilakukan berdasarkan customer order dari pelanggan atau pemesanan dari telepon oleh pelanggan. Langkah pertama yang dilakukan dalam mengentri pesanan adalah pengecekan apakah jumlah barang yang dipesan tersedia. Apabila jumlah barang yang ada tidak mencukupi, dilakukan proses back order, yaitu suatu proses dimana dibuat suatu form back order yang akan dikirim kepada pemasok terpilih untuk memesan barang yang dibutuhkan. Kemudian dilakukan pengecekan kepada status kredit pelanggan. Apabila semua kebijakan kredit terpenuhi maka dibuat order acknowledgment untuk pelanggan, dan picking list untuk bagian gudang.
18 2. shipping Apabila barang yang dipesan telah disiapkan oleh bagian gudang, maka proses selanjutanya adalah proses pengiriman. Dalam pengiriman barang, perlu diperhatikan beberapa dokumen pengapalan, seperti packing slip, bill of lading, dan shipping notice. 3. billing setelah shipping notice diterima, pada hari itu juga dibuat sales invoice, pendebatan piutang usaha sejumlah tertagih, jumlah persediaan berkurang sejumlah barang yang dikirimkan, sales order di tutup ke sales history file, record baru dibuat dalam sales invoice file, jumlah penjualan dan piutang diposting ke buku besar bersangkutan. Sales invoice yang telah dibuat akan dikirim kepada pelanggan sebagi tagihan atas piutang.
2.4.7
Laporan Yang Terkait Dengan S istem Informasi Akuntansi Penjualan, Piutang Usaha dan Penerimaan Kas M enurut Wilkinson et al. (2000,p.437), laporan – laporan yang terkait dengan
siklus penjualan dan piutang usaha adalah : 1. Monthly statement M erupakan daftar dari semua sales invoice (tagihan) yang ada untuk pelanggan. 2. Open order report M enunjukkan semua sales order (pesanan pelanggan) yang belum dikirim dan ditagih. 3. Sales invoice register M erupakan daftar semua sales invoice yang diatur bersadasarkan nomornya.
19 4. Shipping register M erupakan daftar dari semua pengiriman yang diatur berdasarkan tanggal pengirimannya. 5. Cash receipt journal M erupakan daftar dari nilai yang diterima, dan diatur secara kronologis. 6. Credit memo register M erupakan daftar dari semua retur penjualan, yang diatur berdasarkan berdasarkan nomor memo kredit.
2.4.8
Analisa Kredit Dalam Pemberian Kredit Kepada Pelanggan Dalam melaksanakan penjualan kredit, perusahaan melakukan analisa
terhadap kredit yang akan diberikan kepada pelanggan. M enurut M unawir (2004, p.235 – 236), dapat disimpulkan bahwa, ” Syarat – syarat pemberian kredit dikenal dengan 5C , dengan penjelasan sebagai berikut : 1.
Character Keterangan mengenai sifat – sifat pribadi pelanggan dalam memenuhi
kewajiban keuangannya. Karakter ini mencerminkan kejujuran seseorang. Para manajer kredit sering kali mencari informasi dari rekan – rekan kerja, pegawai dan saingan mengenai reputasi, kebiasaan pelanggan dan pergaulan sosialnya. 2.
Capacity Hal ini menyangkut kemampuan pemimpin perusahaan pelanggan beserta
stafnya, baik kemampuan dalam manajemen maupun kemampuan dalam bidang usahanya. Kapasitas pelanggan dapat dilihat dari angka penjualan dan
20 pembeliannya, angka hasil produksi, perhitungan laba rugi perusahaan, dan data financial lainnya. 3.
Capital Hal ini mengacu kepada kondisi umum bisnis pelanggan secara keseluruhan
yang ditunjukkan pada laporan keuangan. M anajer kredit biasanya memberikan perhatian khusus kepada solvabilitas, likuiditas, dan rentabilitas pelanggan terhadap kewajiban – kewajibannya. 4.
Colateral Ini merupakan jaminan. Hal ini menunjukan besarnya aktiva yang akan
dikaitkan sebagai jaminan atas kredit yang diberikan kepada pelanggan 5.
Condition of economic Hal ini mengacu kepada kondisi secara umum dan kondis i kepada sektor
usaha si pelanggan yang dapat mempengaruhi kemampuan pelanggan untuk membayar. Contohnya: pada saat resesi ekonomi, manajer kredit akan memperketat limit kredit atas penjualan sebagai antisipasi terhadap kemungkinan turunnya kemampuan membayar si pelanggan.
2.5
Pajak Pertambahan Nilai 2.5.1
Definisi M enurut Undang-Undang Nomor 18 Tahun 2000 Tentang Perubahan Kedua
atas Undang-Undang Nomor 8 Tahun 1983 Tentang Pajak Pertambahan Nilai Barang dan Jasa dan Pajak Penjualan atas Barang M ewah pasal 1 nomor 25,
21 ”23 Pajak Keluaran adalah Pajak Pertambahan Nilai terutang yang wajib dipungut oleh Pengusaha Kena Pajak yang melakukan penyerahan Barang Kena Pajak, penyerahan Jasa Kena Pajak, atau ekspor Barang Kena Pajak. “
2.5.2
Objek Pajak Pertambahan Nilai M enurut Undang-Undang Nomor 18 Tahun 2000 Tentang Perubahan Kedua
atas Undang-Undang Nomor 8 Tahun 1983 Tentang Pajak Pertambahan Nilai Barang dan Jasa dan Pajak Penjualan atas Barang M ewah :
"Pasal 4 Pajak Pertambahan Nilai dikenakan atas : a. penyerahan Barang Kena Pajak di dalam Daerah Pabean yang dilakukan oleh Pengusaha. b. impor Barang Kena Pajak. c. penyerahan Jasa Kena Pajak di dalam Daerah Pabean yang dilakukan oleh Pengusaha. d. pemanfaatan Barang Kena Pajak tidak berwujud dari luar Daerah Pabean di dalam Daerah Pabean. e. pemanfaatan Jasa Kena Pajak dari luar Daerah Pabean di dalam Daerah Pabean; atau f. ekspor Barang Kena Pajak oleh Pengusaha Kena Pajak."
22 2.5.3
Tarif Pajak Pertambahan Nilai M enurut Undang-Undang Nomor 8 Tahun 1983 Tentang Pajak Pertambahan
Nilai Barang dan Jasa dan Pajak Penjualan atas Barang M ewah : “Pasal 7 (1) Tarif Pajak Pertambahan Nilai berjumlah 10% (sepuluh persen). (2) Atas ekspor Barang dikenakan pajak dengan tarif 0% (nol persen) (3) Dengan Peraturan Pemerintah, tarif pajak sebagaimana ditentukan dalam ayat (1) dapat diubah menjadi serendah – rendahnya 5% (lima persen) dan setinggi – tingginya 15% (lima belas persen)”
2.6
Pajak Penghasilan Pasal 23 M enurut Undang – Undang Republik Indonesia dengan perubahan keempat dari
Undang - Undang Nomor 36 Tahun 2008 tentang Pajak Penghasilan, ”Pasal 23 (1) Atas penghasilan tersebut dibawah ini dengan nama dan dalam bentuk apapun yang dibayarkan disediakan untuk dibayarkan, atau telah jatuh tempo pembayarannya oleh badan pemerintah ,subjek pajak badan dalam negeri, penyelenggara kegiatan , bentuk usaha tetap, atau perwakilan perusahaan luar negeri lainnya kepada Wajib Pajak dalam negeri atau bentuk usaha tetap, dipotong oleh pihak yang wajin membayarkan : a. Sebesar 15% (lima belas persen) dari jumlah bruto atas : 1) Dividen sebagaimana dimaksud dalam Pasal 4 atay (1) huruf g ; 2) Bunga, sebagaimana dimaksud dalam Pasal 4 ayat(1) huruf f ; 3) Royalti; dan
23 4) Hadiah dan penghargaan, bonus, dan sejenisnya selain yang telah dipotong Pajak Penghasilan sebagaimana dimaksud dalam Pasal 21 ayat (1) huruf e; b. Dihapus c. Sebesar 2% (dua persen) dari jumlah bruto atas: 1) Sewa dan penghasilan lain sehubungan dengan penggunaan harta, kecuali sewa dan penghasilan sebagimana dimaksud dalam Pasal 4 ayat (2); dan 2) Imbalan sehubungan dengan jasa teknik, jasa manajemen, jasa kontruksi, jasa konsultan, dan jasa lain selain jasa yang telah dipotong Pajak Penghasilan sebagaimana dimaksud dalam Pasal 21. (2) Ketentuan lebih lanjut mengenai jenis jasa lain sebagaimana dimaksud pada ayat(1) huruf c angka 2 diatur dengan atau berdasarkan Peraturan M enteri Keuangan. (3) Orang Pribadi sebagai Wajib Pajak dalam negeri dapat ditunjuk oleh Direktur Jenderal Pajak untuk memotong pajak sebagaimana dimaksud pada ayat (1). (4) Pemotongan pajak sebagimana dimaksud pada ayat (1) tidak dilakukan atas : a. Penghasilan yang dibayar atau terutang kepada bank; b. Sewa yang dibayarkan atau terutang sehubungan dengan sewa guna usaha dengan hak opsi; c. Dividen sebagaimana dimaksud dalam pasal 4 ayat (3) huruf f dan dividen yang diterima oleh orang pribadi sebagaimana dimaksud dalam pasal 17 ayat (2c) d. Dihapus;
24 e. Bagian laba sebagaimana dimaksud dalam pasal 4 ayat (3) huruf i; f. Sisa hasil usaha koperasi yang dibayarkan oleh koperasi kepada anggotanya; g. Dihapus; h. Penghasilan yang dibayar atau terutang kepada badang usaha atas jasa keuangan yang berfungsi sebagai penyaluran pinjaman dan/atau pembiayaan yang diatur dengan Peraturan M enteri Keuangan.”
2.7
Sistem Pengendalian Internal
2.7.1 Pengertian Sistem Pengendalian Internal M enurut Wilkinson et al.(2000,p.234), pengendalian internal adalah sebuah sistem, struktur atau proses yang diimplementasikan oleh dewan direksi perusahaan, manajemen, dan personal lainnya, dengan maksud untuk menyediakan kepastian yang masuk akal tentang pencapaian tujuan pengendalian dalam kategori sebagai berikut : 1. efektivitas dan efisiensi dari operasi 2. keandalan dari laporan keuangan 3. kepatuhan terhadap hukum dan peraturan yang diterapkan. M enurut COSO yang disebutkan dalam Romney dan Steinbart dalam bukunya (2006,p192), pengendalian internal adalah suatu proses karena memenuhi sebuah aktivitas operasional organisasi dan merupakan bagian integral dari dasar aktivitas manajemen. Pengendalian internal menyediakan kepastian yang masuk akal daripada absolute, karena kemungkinan kesalahan manusia, kolusi, dan kesalahan pengelolaan manajemen membuat proses menjadi tidak sempurna.
25 Jadi dapat disimpulkan bahwa pengendalian internal merupakan suatu pengendalian yang dilakukan oleh manajemen dalam upaya melindungi seluruh asset perusahaan dari hal – hal kecurangan , serta mengecek kandalan dari suatu informasi dan juga ada otorisasi sebagai penanggung jawab atas setiap transaksi dalam upaya mencapai tujuan perusahaan.
2.7.2 Aktivitas Pengendalian Internal M enurut Wilkinson et al. (2000,p.269-289), menyatakan bahwa ada beberpa aktivitas dalam pengendalian internal meliputi : 1. General Control •
Organizational Controls Harus dilakukan pemisahan fungsi antara yang melakukan operasional dengan bagian yang menangani pencatatan
•
Documentation Controls Dokumentasi yang ada harus lengkap dan up-to-date
•
Asset AccountabillityControls Buku besar pembantu piutang harus dipelihara dan direkonsiliasi secara berkala dengan rekening control yang ada dibuku besar. Demikian juga halnya dengan pencatatan persediaan
•
Management Practices Controls Karyawan termasuk programer dan akuntan harus diberikan pelatihan audit yang harus dilakukan terhadap kebijakan penjualan dan penerimaan kas. M anajer harus melakukan review terhadap analisis periodik dan laporan –
26 laporan mengenai kegiatan – kegiatan akuntansi dan transaksi yang disahkan melalui komputer. •
Data Center Operation Control Staff TI dan Akuntansi harus diawasi dan kinerja mereka direview dengan bantuan laporan control proses komputer dan pencatatan akses.
•
Authorization Controls Semua transaksi penjualan kredit harus di otorisasi oleh manajer kredit
•
Access Controls M enggunakan password , gudang dan kas yang terlindung secara fisik, melakukan back up terhadap file piutang dan persediaan ke dalam media lainnya.
2. Application Control •
Input Control ¾ Dokumen – dokumen yang terkait dengan penjualan dan pengiriman barang bernomor urut tercetak dan diotorisasi oleh orang yang berwenang ¾ Validasi data pesanan penjualan ketika data dimasukkan kedalam proses ¾ M emperbaiki error yang terdeteksi ketika entry data sebelum data diposting ke file pelanggan danpersediaan
•
Processing Control ¾ Perpindahan barang dari gudang barang jadi dan pengiriman barang hanya atas dasar otorisasi tertulis
27 ¾ Pengiriman faktur ke pelanggan dilakukan atas dasar notifikasi dari departemen pengiriman mengenai barang yang sudah dikirim ¾ Penerbitan memo kredit atas retur penjualan hanya dilakukan kalo barang sudah dikembalikan ¾ Verifikasi semua catatan komputer terhadap faktur penjualan sebelum diposting ke file pelanggan, untuk menyakinkan bahwa barang yang dipesan sesuai dengan yang dikirim. ¾ Simpanan kas negara setelah diterima untuk menghindari penyelewengan dana. •
Output Control ¾ M enyiapkan laporan bulanan yang harus dikirimkan kepada semua pelanggan yang berhutang ¾ Copy file dari semua dokumen yang berkaitan dalam transaksi penjualan dengan nomor yang berurut, untuk mengecek apakah ada nomor yang terlewat. ¾ M encetak daftar ringkasan transaksi dan akuntasi secara periodik sebagai dasar untuk melakukan review.
2.7.3 Komponen – Komponen Pengendalian Internal Dalam buku Rama dan Jones (2006,p.105), COSO report mengidentifikasikan lima komponen pengendalian internal yang berpengaruh terhadap kemampuan organisasi untuk mencapai tujuan pengendalian internal, yaitu :
28 1. Control Environment Berhubungan dengan beberapa faktor yang disusun organisasi untuk mengontrol kesadaran pada karyawannya. Faktor tersebut berhubungan dengan integritas, nilai etika, filosofi, manajemen, dan operating sytle. Hal ini juga termasuk cara manajemen
menetapkan
otorisasi dan tanggung jawab,
mengatur
dan
mengembangkan sumber daya manusia serta perhatian dan petunjuk dari board of directors. 2. Risk Assessment M erupakan proses identifikasi dan analisis terhadap resiko yang dapat menghambat pencapaian tujuan pengendalian internal 3. Control Activities M erupakan kebijakan dan prosedur
yang dikembangkan organisasi untuk
menangani resiko. Control activities meliputi : •
Performance review Kegiatan yang berhubungan dengan analisis terhadap kinerja, misalnya dengan membandingkan hasil yang didapat dengan anggaran, standar perhitungan dan data pada periode sebelumnya.
•
Segregation of duties Terdiri dari penetapan tanggung jawab untuk mengotorisasi transaksi, melakukan transaksi, mencatat transaksi, menjaga asset yang dilakukan oleh karyawan yang berbeda.
•
Application controls Berhubungan dengan aplikasi sistem informasi akuntansi.
29 •
General controls Pengawasan yang lebih luas berhubungan dengan berbagai aplikasi.
4. Information and communication Sistem informasi dalam perusahaan merupakan kumpulan prosedur (manual dan otomatis)
dan
pencatatan
dalam memulai,
mencatat,
memproses
dan
melaporakan atas kejadian atau proses – proses yang terjadi dalam organisasi. Dan komunikasi berhubungan dengan menyediakan pemahaman atas peraturan dan tanggung jawab individual 5. Monitoring M anajemen
harus
mengawasi pengendalian
internal untuk
memastikan
pengendalian internal oraganisasi harus tetap berjalan sesuai dengan tujuan yang telah ditetapkan.
2.8 2.8.1
Object Oriented Analysis dan Design (OOAD) Pengertian Object M enurut Bennett, M cRobb dan Farmer (2001), ”Object , an abstraction of
sometihing in a problem domain, reflecting the capabilities of the system to keep information about it, interact with it, or both.” Sedangkan menurut M athiassen, M adsen, Nielsen dan Stage (2000,p.4 ), ”object is an entity with identity, state, and behavior.” Berdasakan definisi diatas dapat disimpulkan bahwa object merupkan sesuatu yang nyata dalam bentuk data dan prosesnya, dimana objek ini memiliki identitas, state dan behavior
30 2.8.2
Object Oriented M enurut M athiassen (2000,p.5 ), keuntungan dari object oriented adalah :
1. M erupakan konsep yang sesuai untuk menjelaskan model fenomena dalam sebuah kantor atau pun sistem komputerisasi yang dibuat dengan menggunakan bahasa sehari – hari (natural language) 2. M emberikan informasi yang jelas tentang konteks dari sistem 3. M engurangi biaya perawatan (maintenance).
2.8.3
Object Oriented Analysis and Design (OOAD) M enurut M athiassen et al. (2000,p.15) Object Oriented Analysis and Design
(OOA&D) terbagi dalam empat aktivitas utama, yaitu problem – domain, application – domain, architecture design, dan component design. Yang dapat terlihat dengan jelas pada gambar berikut ini :
31
Gambar 2.1 Aktivitas Utama dan Hasil dalam OOAD Sumber : Mathiassen et al. (2000,p.15)
2.8.4
Criteria FACTOR Kriteria FACTOR menurut M athiassen et al. (2000,p.39) terdiri dari 6
elemen, yaitu : 1. Functionality : fungsi dari suatu sistem yang mendukung tugas – tugas application domain. 2. Application Domain : bagian dari organisasi yang mengadministrasi, memonitor atau mengontrol problem domain. 3. Condition : dalam kondisi seperti apa sistem akan dibangun dan digunakan.
32 4. Technology : teknologi yang digunakan untuk menghasilkan sistem dan dengan teknologi seperti apa sistem akan berjalan. 5. Object : objek utama pada problem domain. 6. Responsibility : tanggung jawab keseluruhan sistem yang berhubungan dengan kontek.
2.8.5
Problem Domaim Analysis M enurut M athiassen et al. (2000,p.45) problem domain adalah bagian dari
konteks yang diatur, dimonitor, atau dikontrol oleh sistem. Analisa Problem Domain dibagi menjadi tiga aktivitas, yaitu :
Gambar 2.2 Aktivitas dalam Problem Domain modeling Sumber Mathiassen et al. (2000,p.46)
33 Dapat dilihat dengan jelas setiap aktivitas dari isi dan konsepnya seperti table 2.1 seperti dibawah ini : Table 2.1 Activities in problem domain analysis Aktivitas Classes
Isi Objek – objek dan event – event yang mana yang merupakan bagian dari problem domain? Structure Bagaimana class – class dan objek secara konseptual digabungkan bersama? Behavior Propeerti – properti dinamik yang mana yang seharusnya dimiliki obejk? Sumber : M athiassen et al. (2000, p48)
Konsep Class, object, dan event
Generalization, aggregation, association, dan cluster Event trace, behavioral pattern, dan attribute
2.8.5.1 Classes M enurut M athiassen et al. (2000, p.49-65), kegiatan class merupakan kegiatan pertama dalam analisis problem domain. Ada beberapa tugas dalam kegiatan ini, yaitu : 1. Klasifikasi Object dan Event Object adalah sebuat entity dengan identitas, state, behavior. Event adalah kejadian yang meliputi satu atau lebih object. Class merupakan deskripsi dari kumpulan object yang termasuk structure, behavioral pattern, dan attributes. 2. M enemukan Class Pemilihan class dilakukan pada saat awal dan bertujuan untuk mendefinisikan dan membatasi
problem domain. Class biasanya
merupakan kata benda dan bermakna tunggal. Kegiatan class akan
34 menghasilkan event table. Dimensi horizontal dari event table berisi class – class yang terpilih, sementara dimensi vertikal berisi event – event yang terpilih dan tanda cek digunakan untuk mengidentifikasi objek – objek dari class yang berhubungan dalam event tertentu. 3. M enemukan Event Pemilihan kumpulan event yang dialami atau dilakukan oleh satu atau lebih objek bertujuan untuk membedakan tiap – tiap class dalam problem domain. Event merupakan kata kerja dan mengindikasikan kejadian tunggal. 4. Evaluasi Sistem Pada bagian ini dilakukan evaluasi kriteria dari class dan event yang sudah ditemukan. Berikut merupakan gambaran event table yang dapat dilihat pada Table 2.2 dibawah ini : Table 2.2 Contoh event table Events Classes Customer Assistant Apprentice Appointment Plan reserved * * + * cancelled * * + treated * + Employed + + Resigned + + Graduuated + Agreed * * * Sumber : M athiassen et al. (2000, p100)
35 2.8.5.2 Structure M engacu pada M athiassen et al ( 2000,p69 ), Sturcture merupakan kegiatan kedua dalam problem domain. Tujuannya adalah untuk mencari hubungan struktural antara class – class dan objek – objek dalam problem domain. Hasil dari kegitan structure adalah membuat class diagram. Dua konsep pada structure adalah : 1. Class Stucture a. Generalization Kelas umum (superclass) yang menggambarkan properti – properti yang umum terhadap sekelompok kelas khusus (subclass). Hubungan dalam generalization dapat dikatakan sebagai hubungan ”is – a”, yang berarti subclass akan menpunyai attribute dan operation yang sama dengan superclass. Stuktur generalization dapat dilihat pada gambar 2.3 berikut ini :
Gambar 2.3 Generalization stucture
b. Cluster Kumpulan dari class – class yang berhubungan. Berikut gambar yang dapat melihatkan suatu cluster :
36
Gambar 2.4 Contoh Cluster – 1
Gamabar 2.5 Clusters – 2
37 2. Object Stucture a. Aggregation Objek superior (keseluruhan) yang terdiri dari beberapa objek (bagian – bagiannya). Hubungan aggregation dirumuskan sebagai hubungan ” hasa” atau ”is-part-of”. M enurut M athiassen
et
al (2000,p.79)
ada tiga tipe struktur
aggregation,yaitu: •
Whole – part, objek superior adalah jumlah dari objek inferior, jika dilakukan penambahan atau penghapusan objek inferior, maka akan mengubah pokok objek superior.
•
Container – content, objek superior adalah container bagi objek inferior, jika melakukan penambahan maupun penghapusan objek inferior, tidak akan mengubah pokok objek superior.
•
Union – member, objek superior adalah container bagi objek inferior yang terorganisasi. Tidak akan terjadi perubahan pada objek superior apabila melakukan penambahan atau penghapusan objek inferior tetapi ada batasannya.
b. Association Hubungan yang berarti antara beberapa objek. Stuktur association dapat dilihat pada gambar 2.6 dibawah ini :
38
Gambar 2.6 Association Sumber : Mathiassen et al (2000,p.69)
Perbedaan antara aggregation dan association adalah : •
Hubungan antar class pada aggregation mempunyai hubungan yang kuat sedangkan association tidak.
•
Aggregation structure melukiskan hubungan yang defensif dan fundamental, sedangkan association structure melukiskan hubungan yang tidak tetep.
2.8.5.3 Behavior M engacu kepada M athiassen et al (2000,p.89), kegiatan utama dalam problem domain adalah kegiatan behaviour, yang bertujuan memodelkan apa yang akan terjadi dalam sistem problem domain sepanjang waktu. Behaviour bertujuan untuk membuat model yang dinamis dari problem domain. Hasil dari kegiatan behaviour adalah membuat statechart diagram, yang dapat di lihat pada gambar 2.7 berikut :
39
Gambar 2.7 Contoh dari Statechart Diagram Sumber : Mathiassen et al. (2000,p.90)
Konsep – konsep pada aktivitas behaviour mencakup : a. Event trace, yang merupakan rangkaian event yang melibatkan objek tertentu b. Behaviour pattern, merupakan deskripsi dari event trace yang mungkin untuk semua object dalam sebuah class. Ada tiga jenis notasi untuk behaviour pattern, yaitu : •
Sequence dimana event muncul satu per satu secara berurutan;
•
Selection dimana terjadi pemilihan satu event dari sekumpulan event yang muncul;
•
Iteration dimana sebuah event muncul sebanyak nol atau beberapa kali
c. Attribute, merupakan properti deskriptif dari sebuah class dan event.
40 2.8.6
Application Domain Analysis M enurut M athiassen et al (2000,p.117), application domain adalah organisasi
yang mengadministrasi, memonitor, atau mengontrol problem domain. Analisa application domain dibagi menjadi tiga aktivitas, yaitu :
Gambar 2.8 Application domain analysis Sumber : Mathiassen et al. (2000,p.117)
Table 2.3 Aktivitas, Isi, dan Konsep dari Application domain analysis Aktivitas Isi Konsep Usage
Bagaimana sistem berinteraksi dengan orang dan sistem dalam konteks? Functions Apa kemampuan sistem dalam memproses informasi? Interfaces Apa kebutuhan – kebutuhan tampilan layar sistem targetkan? Sumber : M athiassen et al. (2000, p117)
Use case dan actor
function
Interface, user interface, dan system interface
41 2.8.6.1 Usage M engacu pada M thiassen et al (2000,p.119), usage merupakan kegiatan pertama dalam analisis application domain yang bertujuan untuk menentukan bagaimana actor – actor yang merupakan pengguna atau sistem lain berinteraksi dengan sistem yang dituju. Interaksi antara actor dengan sistem tersebut dinyatakan dalam use case.
•
Use case M erupakan pola interaksi antara sistem dan aktor di dalam application
domain. Use case dapat digambarkan dengan menggunakan spesifikasi use case, dimana use case dijelaskan dengan singkat namun jelas dan dapat disertai dengan keterangan objek sistem yang terlibat dan function dari use case tersebut atau dengan diagram statechart karena use case adalah sebuah fenomena yang dinamik.
•
Actor Adalah abstraksi dari pengguna atau sistem lain yang berinteraksi dengan
sistem target. Cara untuk mengidentifikasi actor adalah dengan mengetahui alasan yang berbeda untuk menggunakan sistem. M asing – masing actor memiliki alasan yang berbeda untuk menggunakan sistem. Cara lainnya yaitu dengan melihat peran dari aktor seperti yang dinyatakan oleh use case dimana actor tersebut terlibat. M asing – masing actor memiliki peran yang berbeda – beda. Actor dapat digambarkan dalam spesifikasi actor yang
42 memiliki 3 bagian yaitu tujuan, karakteristik, dan contoh dari actor tersebut. Tujuan merupakan peran dari actor dalam sistem target. Sementara karakteristik menggambarkan aspek – aspek yang penting dari actor.
•
Explore pattern Use case pattern dapat digunakan untuk mengidentifikasikan dan menggambarkan use case terdiri atas : (1) the procedural pattern, (2) the material pattern
Berikut adalah contah dari use case :
Gambar 2.9 Use Case
43 2.8.6.1.1
Sequence M enurut Bennet et al.(2006, p.252-253), ”the sequence diagram is
semanticly equivalent to a communication diagram for simple interactions. A Sequence diagram show an interaction between objects arranged in a time sequence.” Dengan demikian, sequence diagram ekuivalen secara semantik dengan diagram komunikasi untuk interaksi yang sederhana. Sebuah sequence diagram menunjukkan interaksi antara objek yang disusun dalam satu sequence. Sequence diagram dapat digambarkan pada tingkat detail mana saja untuk mencapai berbagai tujuan pada beberapa tahapan pada siklus hidup pengembangan. Aplikasi sequence diagram yang paling umum adalah untuk mempresentasikan interaksi objek secara detail untuk satu use case atau
satu
operation.
Ketika
sequence
diagram
digunakan
untuk
menggambarkan model behaviour use case yang dinamis, sequence diagram dapat dilihat sebagai spesifikasi detail dari use case. M enurut M athiassen et al.(2000,p.340), ”Sequence diagaram menjelaskan tentang interaksi diantara beberapa objek dalam jangka waktu tertentu. Sequence diagaram melengkapi class diagram, yang menjelaskan situasi yang umum dan
statis. Sebuah sequence diagaram
dapat
mengumpulkan rincian situasi yang kompleks dan dinamis melibatkan beberapa dari kebanyakan objek yang digeneralisasikan dari class pada class diagram.”
44 2.8.6.2 Function M engacu pada M athiassen et al. (2000,p.137-146), function adalah sebuah fasilitas untuk membuat model berguna bagi aktor. Kegiatan function memfokuskan pada bagaimana cara sebuah sistem dapat membantu aktor dalam melaksanakan pekerjaan mereka. 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, meyatakan kebutuhan kolektif dari pelanggan dan actor dan harus konsisten dengan use case. Function memilki 4 tipe yang berbeda, yaitu : •
Update, function ini disebabkan oleh event problem domain dan menghasilkan perubahan dalam state atau keadaan dari model tersebut.
•
Signal, function ini disebabkan oleh perubahan keadaan atau state dari model yang dapat menghasilkan reaksi pada konteks. Reaksi ini dapat berupa tampilan bagi actor dalam application domain, atau intervensi langsung dalam problem domain.
•
Read, function ini disebabkan oleh kebutuhan informasi dalam pekerjaan actor dan mengakibatkan sistem menampilkan bagian yang berhubungan dengan informasi dalam model.
•
Compute, function ini disebabkan oleh kebutuhan informasi dalam pekerjaan actor dan berisi perhitungan yang melibatkan informasi yang
45 disediakan oleh actor atau model, hasil dari function ini adalah tampilan dari hasil komputasi. Cara yang
baik
untuk
mengidentifikasi
function
adalah
memberikan pertanyaan yang berkaitan dengaan empat jenis function tersebut, seperti : •
M enggunakan ekspresi matematika, yaitu berhubungan dengan input dan output data dispesifikasi sebagai 0 = f(i)
•
Algoritma,
yang secara
khusus
disketsa
dengan
menggunakan
pseudocode •
M embagi function, sehingga bisa memberikan pandangan yang lebih baik Dalam mencari function perlu mempertimbangkan sumber untuk
pencarian function dan juga tingkat rincian. Sumber pencarian function merupakan bagian dari deskripsi problem domain, yang ditampilkan oleh kelas dan event, dan merupakan bagian dari deskripsi application domain yang ditampilkan oleh use case. Classes biasanya menimbulkan read dan update function, sedangkan event menimbulkan update function, dan use case menimbulkan semua jenis function.
2.8.6.3 Interface Kegiatan ketiga dari analisis application domain, yang bertujuan untuk menentukan system’s interface digunakan oleh aktor untuk berinteraksi dengan sistem. M enurut M athiassen et al. (2000,p.151), activity interface mempunyai tiga konsep, yaitu :
46 1. Interface, yaitu fasilitas yang membuat model sistem dan fungsi dapat digunakan oleh aktor 2. User interface, adalah interface untuk user 3. System interface, adalah interface untuk sitem lain. Salah satu user interface yang baik adalah dapat beradaptasi dengan tugas dan memiliki pemahaman user terhadap sistem. Kualitas user interface ditentukan oleh kegunaan atau usability interface tersebut bagi pengguna. Usability bergantung pada yang menggunakan dan situasi sistem tersebut pada saat digunakan. Sehingga dapat dikatakan bahwa usability bukan merupakan sebuah yang pasti dan objektif. Terdapat empat jenis pola dialog yang penting dalam menentukan user interface, yaitu : 1. Pola menu – selection, yang terdiri dari daftar pilihan – pilihan yang mungkin dalam interface diagram. 2. Pola fill – in , yang merupakan pola klasik untuk entri data. 3. Pola command – language, dimana pengguna memasukkan atau memulai format sendiri. 4. Pola direct – manipulation dimana user memilih objek dan melaksanakan function atas objek dan melihat hasil dari interaksi mereka tersebut. Hasil dari kegiatan interface adalah sebuah deskripsi elemen user interface yang lengkap. Dimana kelengkapan sistem ini menunjukkan pemenuhan kebutuhan pengguna. Hasil dari kegiatan user interface berupa form presentasi dan dialogue style, daftar lengkap dari elemen user interface, diagram window terpilih, dan diagram navigasi. Sedangkan hasil dari system
47 interface berupa class diagram untuk peralatan dan protokol eksternal untuk berinteraksi dengan sistem yang lain.
2.8.7
Architectu re Design M engacu pada M athiassen et al.(2000,p.176), keberhasilan suatu sistem
ditentukan oleh kekuatan desain arsitekturnya. Arsitektur membentuk sistem sesuai dengan fungsi sistem tersebut dan dengan memenuhi kriteria desain tertentu. Architecture design memiliki tiga kegiatan, yaitu :
Gambar 2.10 Aktivitas dalam architectural design Sumber : Mathiassen et al. (2000,p.176)
Table 2.4 Kegiatan, Isi dan Konsep Architecture Design Kegiatan Isi Kondisi Criteria Kondisi dan criteria untuk Criterion pendesainan Component Bagaimana sistem dibentuk Arsitektur komponen menjadi komponen – komponen Process Bagaimana proses sistem Arsitektur porses didistibusikan dan dikoordinasi Sumber : M athiassen et al. (2000, p176)
48 2.8.7.1 Criteria M engacu
pada
M athiassen
et
al.
(2000,p.177-181),
untuk
menciptakan sebuah desain yang baik diperlukan pertimbangan mengenai kondisi – kondisi dari setiap proyek yang dapat mempengaruhi kegiatan desain yaitu : •
Technical, yang teridiri dari pertimbangan : penggunaan hardware, software, dan sistem lain yang telah dimiliki dan dikembangkan; pengaruh kemungkinan penggabungan pola – pola umum dan komponen yang telah ada terhadap arsitektur dan pembelian komponen standar.
•
Conceptual, yang terdiri dari pertimbangan : perjanjian kontrak, rencana untuk pengembangan lanjutan, pembagian kerja antara pengembang.
•
Human, yang terdiri dari pertimbangan : keahlian dan pengalaman orang yang terlibat dalam kegiatan pengembangan dengan sistem yang serupa dan dengan platform teknis yang akan didesain. Karena tidak ada cara – cara tertentu atau cara yang mudah untuk menghasilkan suatu desain yang baik, banyak perusahaan menciptakan suatu standar dan prosedur untuk memberikan jaminan terhadap kualitas dari sistem. Disinilah kegiatan criteria dapat membantu dengan menetapkan prioritas untuk setiap proyek tertentu Sebuah desain yang baik memiliki tiga ciri – ciri yaitu :
•
Tidak memiliki kelemahan Syarat ini menyebabkan adanya penekanan pada evaluasi dari kualitas berdasarkan review dan eksperimen, dan membantu dalam menentukan
49 prioritas dari kriteria yang akan mengatur dalam kegiatan desain yang berorientasi objek. Tabel 2.5 di bawah ini menunjukkan kriteria umum untuk sebuah desain Table 2.5 Classical critesia for software quality Criterion Ukuran dari Usable Kemampuan sistem untuk menyesuaikan dengan kontek, 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 Maintainable Biaya untuk menemukan dan memperbaiki kerusakan Testable Biaya untuk memastikan bahwa sistem yang dibentuk dapat melaksanakan fuungsi yang diinginkan Flexible Biaya untuk mengubah sistem yang dibentuk Comprehensable 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 ke sistem yang lain. Sumber : M athiassen et al. (2000, p178)
•
M enyeimbangkan beberapa criteria Konflik sering terjadi antara criteria, oleh sebab itu untuk menentukan criteria mana yang akan diutamakan dan bagaimana cara untuk menyeimbangkan dengan criteria – criteria yang lain bergantung pada situasi sistem tertentu.
50 •
Usable,flexible, dan comprehensible Kriteria – kriteria ini bersifat universal dan digunakan pada hampir setiap proyek pengembangan sistem.
2.8.7.2 Component M engacu pada M athiassen et al. (2000,p.190), arsitektur komponen adalah struktur sistem yang terdiri atau bentuk dari komponen – komponen yang salling terhubung. Komponen merupakan kumpulan dari bagian – bagian program yang membentuk suatu kesatuan dan memiliki fungsi yang jelas. Sebuah arsitektur komponen yang baik membuat sistem menjadi mudah
untuk
dipahami,
mengorganisasikan
pekerjaan
desain,
menggambarkan stabilitas dari konteks sistem dan mengubah desain menjadi beberapa tugas yang lebih tidak komplek. Beberapa pola umum dalam desain komponen arsitektur : a. Arsitektur Layered M enurut M athiassen et al. (2000,p.193), merupakan bentuk yang paling umum dari software seperti berikut ini :
51
Gambar 2.11 layered architecture pattern Sumber : Mathiassen et al. (2000,p.193) Contoh dari model ini adalah OSI yang sudah menjadi ISO untuk model jaringan. Sebuah arsitektur layered terdiri dari beberapa komponen yang dibentuk menjadi lapisan – lapisan dimana lapisan yang diatas bergantung kepada lapisan yang berada dibawah.
b. Arsitektur Generic M enurut M athiassen et al. (2000,p.196), pola ini digunakan untuk merinci pola dasar yng terdiri dari antar muka, function, dan komponen- komponen model, seperti terlihat pada gambar berikut ini :
52
Gambar 2.12 Generic architecture pattern dalam sebuah sistem Sumber : Mathiassen et al. (2000,p.196)
Dimana komponen model terletak pada lapisan yang paling bawah, diikuti dengan function sistem dan komponen interface diatasnya.
c. Arsitektur Client – server M enurut M athiassen et al. (2000,p.197), pola ini awalnya dikembangkan untuk mengatasi masalah distribusi sistem diantara beberapa prosesor yang tersebar secara geografis. Komponen pada arsitektur ini adalah sebuah sever dan beberapa client, seperti dapat dilihat pada gambar berikut ini :
53
Gambar 2.13 The client – server architecture pattern Sumber : Mathiassen et al. (2000,p.197)
Tanggung jawab daripada server adalah untuk menyediakan database dan resource yang dapat disebarkan kepada client melalui jaringan. Sementara client memiliki tanggung jawab untuk menyediakan antarmuka local untuk setiap penggunanya. Ada dua macam metode dalam membagi komponen client dan server yaitu : •
Client dan server dianggap sebagai subsistem tunggal yang masing – masing memiliki komponen, yaitu: user interface(U), function(F), dan model (M ).
•
Atau masing – masing dapat dianggap sebagai layer yang berbeda dalam sistem yang sama. Berikut ini beberapa jenis distribusi dalam arsitektur client – server
dimana user interface(U), function(F), dan model(M) :
54 Table 2.6 Different forms of distribution in a client – server architecture Server Architectu re Client U U+F+M Distributed Presentation U F+M Local Presentation U+F F+M Distributed Functionality U+F M Centralized Data U+F+M M Distributed Data Sumber : M athiassen et al. (2000, p200)
2.8.7.3 Process M engacu pada M athiassen et al.(2000,p.209), arsitektur proses adalah struktur eksekusi sistem yang dibentuk dari proses – proses yang saling berkaitan / bergantungan. Untuk mengeksekusi atau menjalankan sebuah sistem dibutuhkan prosesor. Sedangkan external device adalah prosesor khusus yang tidak dapat menjalankan program. Arsitektur proses harus dapat memastikan bahwa sistem dapat dijalankan secara memuaskan dengan mengunakan prosesor yang sudah tersedia. Kegiatan arsitektur proses bermula dari komponen logic yang dihasilkan oleh kegiatan komponen dan bertujuan untuk menentukan struktur fisik dari sebuah sistem dengan : •
mendistribusikan komponen – komponen program ke prosesor yang akan digunakan untuk mengeksekusi sistem,
•
mengkoordinasi pembagian sumber daya dengan aktif objek
•
dan menghasilkan arsitektur yang tidak memiliki hambatan.
Sumber daya yang sering digunakan secara bersama yaitu :
55 1. Processor terjadi apabila ada dua atau lebih proses yang dieksekusi secara bersamaan pada satu prosesor 2. Program komponen terjadi bila terdapat dua atau lebih prosesor yang secara bersamaan memanggil operasi pada komponen 3. External device M isalnya, pada penggunaan printer yang terhubung memalui network.
Beberapa pola distribusi dalam kegiatan desain process architrcture: 1. Centralized pattern Pola ini menyimpan semua data pada server pusat dan user hanya bisa melihat user interface saja. Keuntungan dari pola ini adalah dapat diimplementasikan pada client secara murah, semua data konsisten karena hanya berada di satu tempat saja, strukturnya mudah dimengerti dan diimplementasikan, dan kemacetan jaringannya moderat. Berikut gambaran dari pattern ini :
56
Gambar 2.14 deployment diagram for the centralized pattern Sumber : Mathiassen et al. (2000,p.216)
2. Distributted pattern Pada pola ini, semua terdistribusi ke user atau client dan server hanya menyebarkan model yang telah di – update di antara client. Keuntungan utama dari pola ini adalah waktu akses yang rendah, sehingga tidak terjadi kemacetan jaringan, kinerja lebih maksimal, dan back – up data yang banyak. Kerugian pada pola ini adalah banyaknya data yang redundant sehingga konsentrasi data terancam, kemacetan jaringan yang tinggi karena update harus disebar kepada semua client, kebutuhan teknis yang canggih, arsitekturnya lebih sulit dimengerti dan diimplementasikan. Berikut gambar dari Distributted pattern
57
Gambar 2.15 Deployment diagram for the distributed pattern Sumber : M athiassen et al. (2000,p.217)
3. Decentralized pattern Pola ini berada diantara kedua pola diatas. Pada pola ini client memiliki data tersendiri sehingga data umum dan function atas data – data tersebut, sedangkan client menyimpan data yang merupakan milik bagian application – domain client tersebut. Keuntungan pola ini adalah konsentrasi data , karena tidak ada duplikasi data antara client dengan client lain maupun dengan server, lalu lintas jaringan jarang karena jaringan hanya digunakan
58 ketika data umum di server terupdate. Kekurangan pola ini adalah bahwa semua prosesor harus mampu melakukan fungsi yang kompleks dan memelihara model dalam jumlah yang besar, sehingga akan meningkatakan biaya hardware.
Gambar 2.16 deployment diagram for the decentralized pattern Sumber : Mathiassen et al. (2000,p.219)
59 2.8.8
Component Design M engacu pada M athiassen et al.(2000,p.232), tujuan dari desain komponen
ini adalah untuk menentukan implementasi kebutuhan dalam rangka arsitektural. Kegiatan desain komponen bermula dari spesifikasi arsitektural dan kebutuhan sistem, sedangkan hasil dari kegiatan ini adalah spesifikasi dari komponen yang saling berhubungan.
Gambar 2.17 Component design Sumber : Mathiassen et al.(2000,p.232)
Table 2.7 Kegiatan, konteks, dan Konsep dari Component Design Kegiatan Konteks Konsep Model component Bagaimana suatu model Model component dan digambarkan sebagai class attribute dalam sebuah sistem Function component Bagaimana sebuah function Function component dan diimplementasikan operation Connecting component Bagaimana komponen – Component dan connection komponen dihubungkan Sumber : M athiassen et al. (2000, p252)
60 2.8.8.1 Model Component M engacu pada M athiassen et al. (2000,p.236-245), model analisis problem domain menggambarkan kebutuhan sistem. Kebutuhan sistem kemudian diimplentasikan dalam komponen model. Oleh karena itu dapat disimpulkan bahwa komponen model adalah bagian dari sistem yang diimplentasikan model problem domain. Tujuan dari komponen model adalah untuk mengirimkan data sekarang dan historic ke function, interface, dan pengguna sistem lain. Konsep utama dalam desain komponen model adalah stucture. Hasil dari kegiatan komponen model adalah revisi dari class diagram dari kegiatan analisis. Kegiatan revisi ini biasanya terdiri dari kegiatan menambahkan class, attribut dan struktur baru yang mewakili event Restrukturisasi class dapat teerjadi pada : •
Generalization Jika terdapat dua class dengan attribute yang sama maka dapat dibentuk class baru (revised class)
•
Association Jika terdapat hubungan many – to – many
•
Embedded iteration Embedded iteractions merupakan embedded di dalam statechart diagram. M isalnya jika sebuah class terdapat statechart diagram yang mempunyai tiga iterative events, maka kita dapat membentuk tiga class di dalam perancangan model.
61 2.8.8.2 Function Component M engacu pada M athiassen et al (2000,p.252), komponen function adalah
bagian
dari sistem yang
mengimplementasaikan
kebutuhan
fungsional. Tujuan dari function component adalah untuk memberikan akses bagi user interface dan komponen sistem lainnya ke model, oleh karena itu function component adalah pernghubung antara model dan usage. Function didesain dan diimplementasikan dengan menggunakan operasi dari kelas sistem. Operasi adalah proses yang dispesifikasikan dalam sebuah class dan dijalankan melalui objek dari class tersebut. Hasil utama dari kegiatan ini adalah class diagram untuk komponen function dan perpanjangan dari class diagram komponen model. Sub kegiatan dalam component function akan menghasilkan kumpulan operasi yang dapat mengimplementasikan fungsi sistem seperti yang ditentukan dalam analisis problem domain dan function list. Berikut adalah sub kegiatan dalam component function : •
merancang function sebagai operation
•
menelusuri pola yang dapat membantu dalam implemantasi function sebagaii operation.
•
spesifikasi operasi yang kompleks.
2.8.8.3 Connecting Component M engacu pada M athiassen et al. (2000,p.274), untuk menghubungkan komponen, kita harus mendesain koneksi (hubungan) diantara komponen dan
62 class yang saling bergantungan. Sehingga mereka dapat mempertahankan kekohensifaannya tapi pada saat yang bersamaan juga menjamin bahwa koneksi ini memiliki coupling yang rendah. Adapun aktivitas yang terkait dalam mendesain koneksi antara komponen adalah : a. menghubungkan class – class b. mengeksplorasi polanya c. melakukan evaluasi terhadap koneksi yang ada.
2.8.9
Diagram dalam Analisi dan Perancangan M enurut M athiassen et al. (2000,p.334-344), ada delapan diagram yang
digunakan untuk menggambarkan empat tahap atau aktivitas utama dalam analisis dan perancangan berorientasi objek adalah sebagai berikut : 1. Rich picture, menggambarkan sebuah pandangan menyeluruh dari people, objek, process, structure, dan problem domain, system problem dan application domain. 2. Class digaram, meenggambarkan kumpulan dari class dan hubungan struktural yang saling timbal balik 3. Statechart diagram menggambarkan behavioural yang digunakan pada semua objek dalam sebuah class khusus dan diuraikan oleh state dan transisi lainnya. 4. Use case diagram, model yang digunakan untuk interaksi antara sistem dan aktor dalam application domain. Pada use case diagaram berisi aktor dalam sebuah sistem.
63 5. Sequence diagram menggambarkan secara grafis bagaimana objek – objek berinteraksi satu sama lain melalui message – message yang dilakukan dari suatu use case digaram atau operasi. 6. Navigation
diagram
adalah
sebuah
statechart
diagram
khusus
yang
memfokuskan pada keseluruhan user interface yang dinamis. Navigation diagram menggambarkan semua user interface dan hubungan dinamisnya 7. Deployment diagram menguraikan sebuah konfigurasi sistem dalam bentuk processor dan object yang dihubungkan ke processor. Deployment diagram menggambarkan komponen sistem program, external device dan hubungan struktural timbal balik. 8. Window diagram adalah sebuah konstruksi dari sebuah window tunggal dan deskripsi dari kegunaannya.
2.8.9.1 Rich picture M enurut M athiassen et al.(2000,p.26), ”Rich picture adalah sebuah gambaran informal yang digunakan oleh pengembang sistem untuk menyatakan pemahaman mereka terhadap situasi sistem yang sedang berlangsung”. Rich picture juga dapat digunakan sebagai alat yang berguna untuk memfasilitasi komunikasi yang baik antara pengguna dalam sistem. Rich
picture difokuskan pada aspek – aspek penting dari sistem
tersebut, yang ditentukan sendiri oleh
pengembang sistem dengan
mengunjungi perusahaan untuk melihat bagaimana perusahaan beroperasi, berbicara dengan banyak orang untuk mengetahui apa yang harus terjadi atau seharusnya terjadi, dan mungkin melakukan beberapa wawancara formal.
64 2.8.9.2 Class diagram M ennurut M athiassen et al.(2000,p.49-65), ” Kegiatan kelas merupakan kegiatan utama 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; pemilihan class dan event; pemilihan class dan event yang akan dipelihara informasinya oleh sistem. M enurut M athiassen et al. ”Class is a description of a collection of objects sharing stucture, behavioural pattern, and attribute”. M aka class ini merupakan
sebuah
deskripsi objek
yang menggambarkan
struktur,
behavioural pattern, dan atribut.
2.8.9.3 Statechart diagram M enurut M athiassen et al. (2000,p.341), ”Statechart diagram menjelaskan tentang behavior umum dari semua objek dalam sebuah kelas yang spesifik dan berisikan state dan transition di antara meraka”. Statechart diagram adalah bagian dari UM L. Statechart diagram dapat juga menjelaskan use case, dimana transition melambangkan action.
2.8.9.4 Use case diagram M engacu kepada M athiassen et al.(2000,p.119-134), kegiatan usage merupakan kegiatan pertama dalam analisis application domain yang bertujuan untuk menentukan bagaimana aktor – aktor yang merupakan
65 pengguna atau sistem lain berinteraksi dengan sistem yang dituju. Interaksi antara aktor dengan sistem tersebut dinyatakan dalam use case. Use case adalah pola interaksi antara sistem dan aktor di dalam application domain. Use case dapat digambarkan dengan menggunakan spesifikasi use case, dimana use case dijelaskan secara singkat namun jelas dan dapat disertai dengan keterangan objek sistem yang terlibat dan function dari use case tersebut atau dengan diagram statechart karena use case adalah sebuah fenomena yang dinamik. Pendapat M athiassen et al.(2000,p.343), mengatakan bahwa use case diagram menggambarkan hubungan antara actor dengan use case. Setiap use case menunjukkan beberapa sequence yang memungkinkan dalam interaksi di antara actor dan system.
2.8.9.5 Sequence diagram M enurut
M athiassen
et
al.(2000,p340),
sequence
diagaram
menjelaskan tentang interaksi di antara beberapa objek dalam jangka waktu tertentu. Sequence diagram melengkapi class diagram, yang menjelaskan situasi yang umum dan
statis.
Sebuah
sequence diagram
dapat
mengumpulkan rincian situasi yang kompleks dan dinamis melibatkan beberapa dari kebanyakan object yang digeneralisasikan dari class pada class diagram.
66 2.8.9.6 Navigation diagram M enurut M athiassen et al.(2000,p.344), sebuah navigation diagram adalah sejenis statchart diagram yang spesial yang berfokus pada kedinamisan user interface secara keseluruhan. Navigation diagram tidak terdapat di dalam UM L. Sebuah window mempresentasikan sebuah state dan state mempunyai nama dan berisikan icon (sebuah window miniatur). State transition berkoresponden pada sebuah switch di antara dua window.
2.8.9.7 Deployment diagram M enurut M athiassen et al. (2000,p.340), Deployment diagram menjelaskan tentang system configuration dalam bentuk prosesor dan objek yang diattach pada prosessor.
