8
BAB 2 LANDASAN TEORI
2.1 Pengertian Sistem Informasi Menurut Whitten, et al. ( 2001, p8 ) sistem informasi adalah susunan dari orang – orang, data, proses – proses, tampilan informasi, dan teknologi informasi yang saling berinteraksi untuk mendukung dan meningkatkan operasi sehari – hari dalam perusahaan bisnis dan juga mendukung pemecahan masalah serta pengambilan keputusan yang dibutuhkan oleh pihak manajemen dan para pengguna lainnya. Menurut Gelinas dan Dull ( 2005, p13 ) sistem informasi adalah sistem yang dibuat oleh manusia yang secara umum terdiri dari sekumpulan komponen – komponen berbasis komputer yang terintegrasi dan juga komponen - komponen manual yang dibentuk untuk mengumpulkan, menyimpan, dan mengatur data serta menyediakan output informasi untuk para penggunanya. Menurut Stair dan Reynolds ( 2006, p4 ) sistem informasi adalah sekumpulan komponen – komponen manual dan berbasis komputer yang saling berinteraksi yang mengumpulkan, memanipulasi, menyimpan, dan menyebarkan data dan informasi serta menyediakan mekanisme umpan balik untuk mencapai suatu tujuan. Jadi dapat ditarik kesimpulan bahwa sistem informasi adalah kumpulan komponen – komponen sumber daya perusahaan untuk mendukung rutinitas operasi perusahaan, menyediakan informasi yang dibutuhkan dan mendukung proses pengambilan keputusan perusahaan serta pemanfaataan umpan balik dalam menilai keberhasilan pencapaian suatu tujuan tertentu.
9 2.2 Pengertian Sistem Informasi Akuntansi Menurut Wilkinson, et al. ( 2000, p7 ) sistem informasi akuntansi adalah kesatuan struktur dalam sebuah entitas, misalnya sebuah perusahaan bisnis, yang menggunakan sumber daya – sumber daya fisik dan komponen – komponen lainnya untuk mengubah data ekonomi menjadi informasi akuntansi, dengan tujuan untuk memenuhi kebutuhan informasi dari berbagai penggunanya. Menurut Gelinas dan Dull ( 2005, p14 ) sistem informasi akuntansi adalah subsistem dari sistem informasi yang bertujuan untuk mengumpulkan, memproses dan melaporkan informasi yang berhubungan dengan aspek keuangan dari suatu kejadian bisnis. Menurut Boockholdt ( 1999, p1 ) sistem informasi akuntansi menganalisa bagaimana kejadian – kejadian yang mempengaruhi sebuah organisasi dicatat, diringkas dan dilaporkan. Kejadian dicatat menggunakan sistem organisasi berupa sumber daya manusia dan komputer, diringkas menggunakan
metode dan tujuan akuntansi, dan
dilaporkan sebagai informasi kepada pihak internal dan eksternal organisasi. Jadi dapat ditarik kesimpulan bahwa sistem informasi akuntansi adalah kumpulan sumber daya manusia dan komputer yang digunakan untuk memproses data keuangan menjadi informasi keuangan, informasi akuntansi dan informasi lainnya untuk memenuhi kebutuhan pengguna internal maupun eksternal perusahaan.
2.3 Sistem Informasi Akuntansi Pembelian dan Persediaan 2.3.1 Sistem Informasi Akuntansi Pembelian Menurut Gelinas dan Dull ( 2005, p420 ) proses pembelian adalah sebuah
10 struktur interaksi antara orang – orang, peralatan, metode – metode dan pengendalian ( kontrol ) yang didesain untuk mencapai fungsi – fungsi utama berikut : -
menangani rutinitas pekerjaan yang berulang – ulang dari departemen pembelian dan departemen penerimaan
-
mendukung kebutuhan pengambilan keputusan dari orang – orang yang mengatur departemen pembelian dan penerimaan
-
membantu dalam penyiapan laporan internal dan eksternal Menurut Wilkinson, et al. ( 2000, p45 ) siklus pengeluaran ( expenditure
cycle ) terdiri dari dua kejadian bisnis atau transaksi bisnis utama yakni pembelian dan pengeluaran kas.
Transaksi pembelian mencakup perolehan sumber daya
ataupun jasa. Menurut Wilkinson, et al. ( 2000, p133 ) kejadian bisnis, dokumen dan file akuntansi dalam siklus pengeluaran adalah seperti ditunjukkan dalam tabel 2.1 berikut: Kejadian bisnis -Permintaan produk atau jasa yang dibutuhkan -Pemesanan produk atau jasa -Penerimaan produk atau jasa -Posting ke Account Payable -Pengeluaran kas
Dokumen dan laporan -Purchase requisition -Purchase order -Supplier’s invoice -Disbursement voucher -Check voucher -Cash disbursement Report
File akuntansi utama -Purchase journal -Cash disbursement journal -Account payable master file
Tabel 2.1 Siklus Pengeluaran ( Sumber : Wilkinson, et al., 2000, p133 )
Menurut Romney dan Steinbart ( 2003, p415-416 ) siklus pengeluaran ( expenditure cycle ) adalah sekumpulan aktivitas – aktivitas bisnis dan pemrosesan
11 data yang berhubungan dengan pembelian dan pembayaran barang dan jasa. Tiga aktivitas bisnis dasar dalam siklus ini adalah : 1. memesan barang, perlengkapan, dan jasa 2. menerima dan menyimpan barang, perlengkapan, dan jasa 3. membayar barang, perlengkapan, dan jasa Dengan demikian, pembelian merupakan bagian dari siklus pengeluaran ( expenditure cycle ) yang melibatkan aktivitas pemilihan pemasok, pemesanan barang atau jasa, penerimaan barang atau jasa dan penyimpanan barang.
2.3.1.1
Unit yang terkait Menurut Wilkinson, et al. ( 2000 ) unit yang terkait dengan siklus
pembelian adalah : 1. inventory management / logistics Dalam perusahaan dagang, tujuan dari fungsi ini adalah untuk mengatur persediaan barang dagang yang perusahaan peroleh untuk dijual kembali. Inventory management juga mencakup pembelian, penerimaan dan penyimpanan. Pembelian secara utama berfokus pada pemilihan pemasok yang paling tepat untuk memesan barang dan jasa. Pemilihan pemasok didasarkan pada faktor – faktor seperti harga unit untuk barang atau jasa, kualitas barang atau jasa, syarat dan tanggal pengiriman yang dijanjikan, dan juga kehandalan dari pemasok.
Bersama dengan
pengendalian persediaan ( yang berada dibawah fungsi akuntansi ), pembelian menjamin kuantitas barang yang akan diterima.
Bagian
Penerimaan memiliki tanggung jawab untuk hanya menerima barang
12 yang
dipesan,
menverifikasi
kuantitas
memindahkan barang ke gudang.
dan
kondisinya,
dan
Bagian Penyimpanan memiliki
tanggung jawab untuk menjaga barang dari pencurian, kehilangan dan pengrusakan dan menyiapkannya dengan tepat waktu ketika terdapat permintaan atas barang tersebut. 2. finance / accounting Dalam hubungannya dengan siklus pembelian, fungsi ini bertugas dalam hal perencanaan dan pengendalian kas perusahaan, mengatur data yang berkaitan dengan pembelian dan akun pemasok, pengendalian persediaan, dan informasi yang berkaitan dengan kas, pembelian dan pemasok.
Bagian inventory control memelihara catatan saldo
persediaan dan menginisiasi pemesanan kembali barang dagang.
2.3.1.2
Dokumen yang Terkait Menurut Wilkinson, et al. ( 2000, p472 ) dokumen yang
digunakan dalam sistem informasi akuntansi pembelian adalah : - purchase requisition merupakan dokumen pertama dalam siklus pembelian yang mengotorisasi pemesanan barang atau jasa - purchase order merupakan dokumen yang berbentuk formal dan berangkap yang dipersiapkan setelah adanya purchase requisition yang mengikat bagi perusahaan pembeli. - receiving report
13 merupakan dokumen yang mencatat penerimaan barang - supplier’s ( vendor’s ) invoice merupakan dokumen penagihan dari pemasok yang menyediakan barang dan jasa bagi perusahaan. - disbursement voucher merupakan dokumen dalam sistem voucher yang mengakumulasi invoice dari pemasok untuk keperluan pembayaran. - disbursement check merupakan dokumen yang menyediakan pembayaran kepada pemasok atas barang atau jasa - debit memorandum merupakan dokumen yang mengotorisasi retur pembelian - new supplier ( vendor ) form merupakan dokumen yang digunakan dalam pemilihan pemasok baru, yang menunjukkan data seperti harga, tipe barang atau jasa yang disediakan, pengalaman, status kredit dan referensi pihak lain. - request for proposal ( atau quotation ) merupakan dokumen yang digunakan dalam prosedur penawaran diantara para pemasok yang bersaing, yang menunjukkan barang atau jasa yang dibutuhkan dan perbandingan harga, syarat dan sebagainya.
2.3.1.3
Laporan yang dihasilkan Menurut Wilkinson, et al. ( 2000, p487-493 ) output informasi
yang dihasilkan dari siklus expenditure ( siklus pembelian ) adalah :
14 1. Laporan dan daftar operasional -
invoice atau voucher register merupakan daftar invoice yang diterima dari pemasok atau daftar voucher yang disiapkan dari faktur
-
check register merupakan daftar semua cek yang telah ditulis
-
open purchase order report merupakan laporan yang menunjukkan semua pembelian yang dimana invoice yang terkait belum disetujui untuk pembayaran
-
open invoice report atau open payable report atau cash requirements report merupakan daftar semua invoice yang telah disetujui tetapi belum dibayar
-
inventory status report merupakan laporan yang memuat kuantitas barang yang diterima, kuantitas barang yang sedang dikirimkan dan kuantitas ditangan
-
overdue deliveries report merupakan laporan yang memuat transaksi pembelian yang telah melewati waktu pengiriman barang yang diinginkan perusahaan dari pemasok
2. inquiry display screens merupakan layar yang menampilkan informasi yang diminta seperti : -
status dari order pembelian tertentu
-
invoice untuk pemasok tertentu
15 -
summary atas open purchase order
3. scheduled managerial reports -
payables aging report merupakan laporan yang menggambaran status invoice atau voucher yang belum dibayar yang dapat disebabkan karena masalah atau pertanyaan dengan pemasok yang belum terselesaikan
-
purchase analysis merupakan
laporan
yang
menggambarkan
tingkat
aktivitas
pembelian untuk setiap pemasok, setiap item persediaan dan setiap pihak peminta barang ( internal perusahaan ) -
vendor performance report merupakan laporan yang menggambarkan kinerja pemasok dalam bentuk pengiriman tepat waktu, kualitas barang, harga unit barang, tingkat pelayanan, dan kondisi barang yang dikirim pemasok
-
critical factors report merupakan laporan yang memuat ukuran – ukuran kinerja seperti jumlah potongan pembelian yang terlewatkan.
4. demand managerial reports merupakan laporan – laporan yang tidak terjadwal yang berisi informasi yang digunakan untuk pengambilan keputusan dan pengendalian manajerial
2.3.2 Sistem Informasi Akuntansi Persediaan Menurut Standar Akuntansi Keuangan ( 2004, SAK No. 14.1 ) persediaan
16 adalah “ aktiva tersedia untuk dijual dalam kegiatan usaha normal; dalam proses produksi dan atau dalam perjalanan; atau dalam bentuk bahan atau perlengkapan ( supplies ) untuk digunakan dalam proses produksi atau pemberian jasa. …Persediaan meliputi barang yang dibeli dan disimpan untuk dijual kembali. … Persediaan juga mencakupi barang jadi yang telah diproduksi, atau barang dalam penyelesaian yang sedang diproduksi perusahaan, dan termasuk bahan serta perlengkapan yang digunakan dalam proses produksi.” Menurut Horngren, et al. ( 2002, p167 ) persediaan mencakup semua barang yang dimiliki oleh perusahaan dan yang diharapkan untuk terjual dalam operasi normal perusahaan. Menurut Boockholdt ( 1999, p523 ) siklus konversi mencakup transaksi – transaksi yang terjadi ketika input diubah ( dikonversi ) menjadi barang atau jasa yang dapat dijual. Gambar 2.1 menunjukkan siklus konversi dalam perusahaan dagang.
17
Inventory System
Expenditure Cycle
Revenue Cycle Merchandise Inventory Shipping System
Receiving System
Payroll System
Gambar 2.1 Siklus Konversi dalam Perusahaan Dagang ( Sumber : Boockholdt, 1999, p524 )
Menurut Boockholdt ( 1999, p653-654 ) sistem persediaan bertujuan untuk memelihara catatan persediaan dan untuk menginformasikan kepada manajer ketika tingkat persediaan tertentu perlu diisi atau dipenuhi kembali. Sistem persediaan terdapat dalam perusahaan dagang dan manufaktur. Sistem persediaan memproses dua macam transaksi sebagai berikut : 1. Pembelian persediaan Entry yang dilakukan untuk mencatat transaksi ini tergantung pada metode yang digunakan untuk akuntansi persediaan. Terdapat dua metode yaitu metode periodik dan metode perpetual. -
metode periodik
18 perusahaan yang menggunakan metode ini tidak memelihara catatan jumlah persediaan di tangan secara terus – menerus.
Perusahaan
menentukan nilai persediaan awal dan akhir dengan perhitungan fisik. -
metode perpetual perusahaan yang menggunakan metode ini memelihara jumlah persediaan ditangan secara terus – menerus. Perusahaan manufaktur menggunakan metode ini karena perusahaan perlu untuk mengetahui apakah persediaan yang terdapat di tangan sudah mencukupi untuk proses manufaktur perusahaan.
2. Penjualan Persediaan Perusahaan mencatat cost of inventory yang terjual dalam akun buku besar yang berjudul cost of goods sold. Dengan metode periodik, tidak ada entry yang dilakukan pada saat penjualan.
Cost of goods sold ditentukan dengan
menambah jumlah pembelian dengan nilai persediaan awal. Dengan metode perpetual, perusahaan mencatat penjualan dengan mengkredit akun persediaan dan mendebit cost of goods sold.
Manajemen Persediaan Menurut Handoko (2001, p334) sistem persediaan adalah serangkaian kebijaksanaan dan pengendalian yang memonitor tingkat persediaan yang bertujuan untuk meminimumkan biaya total. Menurut jenisnya dapat dibedakan menjadi: 1. persediaan bahan mentah
19 Yaitu persediaan barang berwujud yang digunakan dalam proses produksi. 2. persediaan komponen-komponen rakitan Yaitu persediaan barang-barang yang terdiri dari komponen-komponen yang diperoleh dari perusahaan lain, di mana secara langsung dapat dirakit menjadi suatu produk. 3. persediaan bahan baku Yaitu persediaan barang-barang yang diperlukan dalam proses produksi, tetapi tidak merupakan bagian barang jadi. 4. persediaan barang dalam proses Yaitu persediaan barang yang merupakan keluaran dari tiap-tiap bagian dalam proses produksi atau yang diolah menjadi suatu bentuk. 5. persediaan barang jadi Yaitu persediaan barang-barang yang telah selesai diproses atau diolah.
Metode Penilaian Persediaan Menurut Weygandt, Kieso, dan Kimel (2005, p236-238) dalam menilai persediaan, metode yang digunakan yaitu: 1. Metode FIFO ( First In First Out ) FIFO adalah metode penetapan harga pokok persediaan, di mana dianggap bahwa barang-barang yang pertama kali dibeli akan merupakan barang yang dijual pertama kali. Dalam metode ini, persediaan akhir dinilai dengan harga pokok pembelian paling akhir. 2. Metode LIFO ( Last In First Out )
20 LIFO adalah metode penetapan harga pokok persediaan di mana dianggap bahwa barang-barang yang paling akhir dibeli akan merupakan barang yang dijual pertama kali. Dalam metode ini, persediaan akhir dinilai dengan harga pokok pembelian terdahulu. 3. Metode rata-rata (Average) Rata-rata adalah metode penetapan harga pokok persediaan di mana dianggap bahwa harga pokok rata-rata dari barang yang tersedia dijual akan digunakan untuk menilai harga pokok barang yang dijual dan yang terdapat dalam persediaan.
Laporan yang Terkait Menurut Boockholdt ( 1999, p655-656 ) macam – macam laporan yang dihasilkan dari sistem persediaan adalah sebagai berikut : 1. Inventory status report merupakan laporan yang mendaftarkan semua item atau jenis persediaan, kuantitas persediaan ditangan, dan biaya persediaan. 2. Query inventory items report merupakan laporan yang dapat berupa tercetak atau ditampilkan pada komputer. Pada sistem online real-time, karyawan dapat menggunakan laporan ini untuk mengetahui jumlah persediaan ditangan pada saat query ( permintaan ) data dilakukan. 3. Reorder report merupakan laporan yang mengidentifikasi jenis – jenis persediaan yang harus diisi kembali.
Ketika jumlah persediaan ditangan menurun
21 mencapai reorder point ( titik pemesanan kembali ), sistem pengendalian persediaan harus menunjukkan jenis persediaan tersebut dalam laporan ini. 4. Physical inventory report perusahaan secara periodik melakukan perhitungan fisik atas jumlah setiap persediaan yang ada ditangan.
Proses ini menghasilkan
perhitungan cost of goods sold ketika metode periodik digunakan. Dengan metode perpetual , proses ini memampukan perusahaan memperbaiki kesalahan dalam catatan persediaan.
2.4 Pengendalian Internal 2.4.1 Pengertian Committee of Sponsoring Organizations ( COSO ) ( Gelinas dan Dull, 2005, p216 ) mendefinisikan pengendalian internal ( internal control ) sebagai sebuah proses, yang dipengaruhi oleh dewan direksi, manajemen, dan personal lainnya dalam suatu entitas, yang dirancang untuk menyediakan jaminan atau keyakinan yang layak atau memadai sehubungan dengan pencapaian tujuan - tujuan dalam kategori berikut : -
efektivitas dan efisiensi operasi
-
kehandalan laporan keuangan
-
kesesuaian dengan hukum dan peraturan yang berlaku
22 2.4.2 Komponen – Komponen Committee of Sponsoring Organizations ( COSO ) ( Gelinas dan Dull, 2005, p216-217
) mengidentifikasikan lima komponen pengendalian yang saling
berhubungan sebagai berikut : 1. Control environment merupakan komponen yang membentuk suasana suatu organisasi, yang mempengaruhi kesadaran akan pengendalian dari orang – orangnya. Lingkungan pengendalian adalah sebagai dasar untuk semua komponen – komponen pengendalian internal lainnya dengan menyediakan disiplin dan struktur. 2. Risk assessment merupakan pengidentifikasian dan analisa oleh entitas atas resiko – resiko relevan untuk pencapaian tujuan – tujuannya, yang membentuk dasar untuk menentukan bagaimana resiko sebaiknya dikelola. 3. Control activities merupakan kebijakan dan prosedur yang membantu dalam menjamin bahwa perintah manajemen telah dilaksanakan. 4. Information and communication merupakan identifikasi, penangkapan, dan pertukaran informasi dalam suatu bentuk dan kerangka waktu yang memungkinkan orang – orang mampu melaksanakan tanggung jawabnya. 5. Monitoring merupakan suatu proses yang menilai kualitas kinerja pengendalian internal pada suatu waktu.
23 Gambar 2.2 menunjukkan komponen dan pertimbangan utama atas struktur pengendalian internal : StrukturPengendalian Internal
Control Environment subkomponen :
Risk Assesment
Information and Communication
ControlActivities
pertimbangan utama:
- filosofidangayaoperasi - identifikasi resikointernal yangsignifikan manajemen - integritas dannilaietika - identifikasi resikoexternal - komitmen terhadap yangsignifikan kompetensi - menyiapkan analisa resiko - dewandireksidan - manajemen resikoyang komiteaudit relevan - strukturorganisasi
pertimbangan utama: - identifikasi danperolehan informasi yangrelevan denganpelaporan keuangan - komunikasi informasi yangrelevandalam formatyangtepat
Monitoring
pertimbangan utama: - aktivitasyang terusmenerus - evaluasi secaraterpisah
- penetapan wewenang dantanggung jawab - kebijakan danpraktik sumberdayamanusia
aktivitasyang berhubungan dengan pelaporan keuangan
aktivitasyang berhubungan dengan pemrosesan informasi
subkomponen : - desaindokumen yangbaik dandokumen sertarecord bernomor urut
general control
application control
- pemisahan tugas - otorisasitransaksi - ukurankeamanan danperlindungan yangcukup - pengecekan kinerja secaraindependen - pemeriksaan tepat atasjumlahtercatat
Gambar 2.2 Komponen dan Pertimbangan Utama Struktur Pengendalian Internal ( Sumber : Wilkinson, et al., 2000, p236 )
2.4.3 Tujuan Pengendalian Menurut Gelinas dan Dull ( 2005, p230 ), tujuan pengendalian meliputi hal – hal seperti dalam tabel 2.2 berikut ini.
24 Tujuan Pengendalian
Definisi Tujuan Pengendalian dari Proses Operasi Menjamin efektivitas operasi dengan Efektivitas : suatu ukuran sukses dalam mencapai tujuan – tujuan yang telah mencapai satu atau beberapa tujuan dari ditetapkan atas proses operasi proses operasi Menjamin pemanfaatan yang efisien atas Efisiensi : suatu ukuran atas produktivitas sumber daya ( misalnya sumber daya pemakaian sumber daya untuk mencapai manusia, komputer ) tujuan Menjamin keamanan sumber daya ( Keamanan sumber daya : menjaga misalnya kas, data, persediaan ) sumber daya organisasi dari kehilangan, pengrusakan, disclosure, pengkopian, penjualan dan penggunaan tidak benar lainnya. Tujuan Pengendalian dari Pemrosesan Informasi Menjamin validitas input Validitas input : data input disetujui secara tepat dan menggambarkan kejadian ekonomi dan objek yang sebenarnya Menjamin kelengkapan input Kelengkapan input : semua kejadian atau objek yang valid ditangkap dan dimasukkan ke dalam sistem Menjamin keakuratan input Akurasi input : semua kejadian yang valid harus secara benar ditangkap dan dimasukkan dalam sistem Menjamin kelengkapan update Kelengkapan update : semua kejadian yang dimasukkan dalam sistem harus terefleksikan dalam master data ( data induk ) Menjamin keakuratan update Keakuratan update : data yang dimasukkan dalam sistem harus terefleksikan secara benar dalam master data ( data induk ) Tabel 2.2 Tujuan Pengendalian ( Sumber Gelinas dan Dull, 2005, p230 )
25 2.4.4 Pengendalian Internal dalam Pembelian dan Persediaan 2.4.4.1
Tujuan Pengendalian Internal Pembelian dan Persediaan Menurut Wilkinson, et al. ( 2000, p498 ), tujuan pengendalian
dalam siklus pengeluaran ( pembelian dan persediaan ) adalah sebagai berikut : - semua pembelian diotorisasi atas dasar waktu ketika dibutuhkan dan atas dasar perhitungan economic order quantity. - semua barang yang diterima diverifikasi untuk menentukan bahwa kuantitasnya sesuai dengan yang dipesan dan dalam kondisi yang baik. - semua jasa diotorisasi sebelum diterima dan dimonitor untuk menjamin bahwa jasa dilakukan dengan benar - semua faktur dari pemasok di verifikasi berdasarkan waktu dan sesuai dengan barang atau jasa yang diterima - semua diskon pembelian diidentifikasi sehingga potongan tersebut dapat dimanfaatkan jika secara ekonomi menguntungkan. - semua retur pembelian diotorisasi dan dicatat secara akurat dan berdasarkan pengembalian barang yang aktual - semua pengeluaran kas dicatat secara lengkap dan akurat - semua transaksi pembelian kredit dan pengeluaran kas di posting ke akun pemasok yang tepat dalam buku besar hutang dagang - semua catatan akuntansi dan persediaan barang dagang terlindungi
26 2.4.4.2
Unsur Pengendalian Internal Menurut Wilkinson, et al. ( 2000, p500-504 ), komponen control
activities dalam siklus pembelian dan persediaan adalah : 1. pengendalian umum a. pengendalian organisasi pemisahan bagian gudang dan penerimaan dengan bagian yang melakukan pencatatan ( inventory control, account payable, general ledger, dan data processing ). b. pengendalian dokumentasi dokumentasi yang harus lengkap dan up-to-date termasuk rangkap dokumen, flowcharts, record, dan laporan – laporan terkait. c. pengendalian pertanggung jawaban aset catatan atau record atas persediaan barang dagang harus dipelihara dalam buku besar, dengan kuantitas ditangan yang tercatat harus direkonsiliasi dengan perhitungan fisik persediaan secara periodik. d. pengendalian praktik manajemen Karyawan termasuk programer dan akuntan harus mendapat pelatihan.
Pengembangan dan perubahan sistem harus sesuai
dengan prosedur yang jelas, audit atas kebijakan dan prosedur pembelian dan pengeluaran kas, serta manajer harus melakukan review atas analisa periodik, control summaries dan laporan – laporan lainnya. e. pengendalian operasi pusat data ( data center operations )
27 jadwal pemrosesan batch – batch data yang harus jelas. Personel akuntansi dan sistem informasi diawasi dan hasil kerja mereka direview dengan bantuan computer processing control reports ( laporan pengendalian yang diproses komputer ) dan access log ( catatan akses yang pernah dilakukan ). f. pengendalian otorisasi Semua transaksi pembelian harus diotorisasi oleh manajer yang berwenang biasanya oleh inventory manager. g. pengendalian akses - penggunaan password untuk mengakses file – file account payable dan data – data pemasok - terminal
terbatas
hanya
untuk
transaksi
pembelian
dan
pengeluaran kas - log atas semua transaksi - backup data - perlindungan atas gudang penyimpanan persediaan - log atas semua akses ke data 2. pengendalian aplikasi a. pengendalian input - menyiapkan dokumen yang didesain dengan baik dan bernomor urut atas pembelian, penerimaan, hutang, dan pengeluaran kas serta otorisasi dokumen tersebut - validasi data order pembelian dan laporan penerimaan pada saat data tersebut dipersiapkan dan dientry untuk diproses.
28 - memperbaiki error yang terdeteksi selama data entry dan sebelum data diposting ke catatan pemasok dan persediaan. - menghitung jumlah total pada batch control atas data faktur pemasok dan voucher yang telah jatuh tempo untuk pembayaran. b. pengendalian pemrosesan 1. penerbitan
permintaan
pembelian,
order
pembelian,
disbursement voucher, cek dan memo debit sesuai otorisasi 2. verifikasi semua elemen data dan perhitungan dalam permintaan pembelian dan order pembelian 3. menelusuri semua elemen data dan perhitungan dalam faktur pemasok dan membandingkannya dengan order pembelian dan laporan penerimaan 4. memonitor semua transaksi yang masih terbuka seperti pengiriman barang yang belum sepenuhnya atau barang yang ditolak 5. penerbitan memo debit sesuai persetujuan pejabat berwenang 6. merekonsiliasi akun pembantu hutang dagang dan beban dengan akun pengendali dalam buku besar 7. menverifikasi total posting ke akun hutang dagang pada buku pembantu dengan total posting ke buku besar. 8. memonitor syarat pembelian untuk menjamin bahwa potongan pembelian dimanfaatkan, jika ekonomis. 9. mereview bukti – bukti yang mendukung validitas pengeluaran dan kebenaran jumlahnya sebelum penandatanganan cek
29 10. menjamin bahwa jumlah dalam cek tidak akan diubah secara tidak sah sebelum penandatanganan dilakukan 11. jumlah nominal cek yang melebihi jumlah tertentu harus ditandatangani oleh manajer selanjutnya yang berwenang 12. verifikasi jumlah persediaan yang ada ditangan dengan perhitungan fisik minimal sekali setahun, dan merekonsiliasi jumlah hasil perhitungan dengan jumlah tercatat 13. menggunakan imprest system dalam pengeluaran kas kecil 14. membangun kebijakan pembelian dalam jumlah besar atau tidak rutin dengan mengunakan penawaran yang bersaing dari para pemasok ( bidding ) 15. memperbaiki error yang terjadi selama tahap pemrosesan. c. pengendalian output 1.
membangun kebijakan pisah batas penerimaan persediaan dan hutang dagang yang jelas, sehingga persediaan dan hutang dagang dinilai secara wajar pada akhir periode akuntansi
2.
membangun pengendalian anggaran atas pembelian
3.
membandingkan laporan bulanan dari pemasok dengan jumlah yang muncul dalam akun pemasok
4.
menyimpan
kopian
semua
dokumen
pembelian
dan
pengeluaran kas berdasarkan nomor urut dan dilakukan pengecekan nomor urut tersebut secara periodik untuk menemukan adanya gaps ( nomor yang hilang ).
30 5.
mencetak daftar transaksi dan account summary secara periodik untuk menyediakan jejak audit ( audit trail )
2.5 Metode Analisis dan Desain Berorientasi Objek 2.5.1 Pengertian Menurut Mathiassen, et al. ( 2000, p3-4 ) analisis dan desain berorientasi objek adalah sebuah metode yang menggunakan objek – objek dan class – class sebagai konsep utamanya dan membentuk empat prinsip umum untuk analisis dan desain, sebagai berikut : 1. membuat model dari konteks sistem 2. menekankan pada arsitektur sistem 3. menggunakan kembali model – model atau pola – pola yang mengekspresikan ide – ide desain yang telah terbentuk dengan baik 4. menyesuaikan metode dengan setiap situasi pengembangan sistem
2.5.2 Aktivitas Utama Menurut Mathiassen, et al. ( 2000, p15 ) aktivitas utama dan hasilnya dalam analisa dan desain berorientasi objek ditunjukkan dalam gambar 2.3 berikut.
31
Requirements for use
Problemdomain analysis
Model
Component design
Applicationdomain analysis
Specification of components
Specifications of architecture
Architectural design
Gambar 2.3 Aktivitas Utama dan Hasilnya Dalam Analisa dan Desain Objek Berorientasi Objek ( Sumber Mathiassen, et al. , 2000, p15 )
2.5.3 System Definition Menurut Mathiassen, et al.( 2000, p24 ) system definition adalah deskripsi yang ringkas dari suatu sistem terkomputerisasi yang dinyatakan dalam bentuk bahasa alami. System definition mengekspresikan properti dasar untuk pengembangan dan penggunaan sistem.
System definition menggambarkan konteks sistem,
informasi apa yang harus dimiliki sistem, fungsi – fungsi apa saja yang harus dimiliki, dimana sistem harus digunakan, dan kondisi pengembangan yang harus diterapkan.
32 2.5.4 FACTOR Criterion Menurut Mathiassen, et al.( 2000, p39-40 ) FACTOR Criterion terdiri dari enam elemen sebagai berikut : 1. Functionality merupakan fungsi – fungsi sistem yang mendukung tugas application domain. 2. Application domain merupakan bagian – bagian dalam sebuah organisasi yang mengadministrasi, memonitor, atau mengontrol problem domain. 3. Conditions merupakan kondisi – kondisi dimana sistem akan dikembangkan dan digunakan. 4. Technology merupakan teknologi yang akan digunakan untuk mengembangkan dan menjalankan sistem. 5. Objects merupakan objek – objek utama dalam problem domain. 6. Responsibility merupakan tanggung jawab sistem secara keseluruhan dalam hubungannya dengan konteks sistem.
33 2.5.5 Rich Picture Menurut Mahiassen, et al. ( 2000, p26-27 ) rich picture adalah sebuah gambaran informal yang digunakan oleh pengembang sistem untuk menyatakan pemahaman mereka terhadap situasi dari sistem yang sedang berlangsung. Para pengembang sistem perlu memahami situasi masalah yang ada dengan kerjasama yang erat dengan semua pihak yang terlibat dan khususnya dengan pengguna sistem dimasa depan. Para pengguna tidak perlu menggambarkan rich picture atau juga melihatnya. Rich picture merupakan alat utama untuk membantu pengembang sistem mengorganisasikan secara jelas pemahaman mereka. Selain itu rich picture adalah alat yang bermanfaat untuk mempermudah komunikasi dengan para pengguna.
2.5.6 Analisis Problem Domain Menurut Mathiassen, et al. ( 2000, p45 ) problem domain adalah bagian dari sebuah konteks sistem yang di administrasi, dimonitor, atau dikontrol oleh sebuah sistem.
Analisa problem domain berfokuskan pada informasi apa yang harus
ditangani oleh sistem. Analisa problem domain memiliki tiga aktivitas seperti ditunjukkan tabel 2.3 berikut :
34 Aktivitas
Isi
Konsep
Class
Objek dan event mana yang merupakan bagian dari problem domain Bagaimana class dan objek saling berkaitan satu sama lain secara konseptual Properti dinamik mana yang dimiliki objek
Class, objek, dan event
Structure
Behaviour
Generalization, aggregation, association, dan cluster Event trace, behavioural pattern, dan attribute
Tabel 2.3 Aktivitas dalam Analisa Problem Domain ( Sumber Mathiassen, 2000, p48 )
2.5.6.1
Class Menurut Mathiassen, et al. ( 2000 ) Objek adalah sebuah entitas
dengan identitas, status, dan perilaku ( behaviour ).
Event adalah sebuah
kejadian yang terjadi seketika yang melibatkan satu atau lebih objek. Class adalah sebuah deskripsi dari sekumpulan objek – objek yang memiliki struktur, behavioural pattern, dan atribut. Dalam analisa problem domain, sebuah objek merupakan abstraksi dari sebuah fenomena dalam problem domain.
Sebuah event
adalah sebuah abstraksi dari aktivitas atau proses dalam problem domain yang dilakukan atau dialami oleh satu atau lebih objek. Class yang terpilih akan menjadi pusat atau inti dari model problem domain. Kegiatan Class ini akan menghasilkan sebuah Event Table seperti yang terlihat pada tabel 2.4 dibawah ini. Dimensi horizontal berisi class – class yang terpilih, dan dimensi vertikal berisi event – event yang terpilih. Sebuah tanda cek digunakan untuk mengindikasikan bahwa objek – objek dari class terlibat dalam event tertentu.
35
Events Reserved Cancelled Treated Employed Resigned Graduated Agreed
Customer
Assistant
Classes Apprentice
Appointment
Plan
Tabel 2.4 Contoh event table ( Sumber : Mathiassen, et al. , 2000, p50 )
2.5.6.2
Structure Menurut Mathiassen, et al. ( 2000 ) aktivitas structure bertujuan
untuk menggambarkan hubungan struktural antara class - class dan objek – objek dalam sebuah problem domain. Dalam aktivitas ini, pengembang sistem akan memodelkan hubungan yang abstrak dan umum antara class class dan hubungan yang konkrit dan spesifik antara objek – objek. Menurut Mathiassen, et al. ( 2000 ) object – oriented structure bisa dibagi menjadi : 1. Structure antara class Struktur ini menggambarkan hubungan yang statis dan konseptual antara class – class. Structure antar class terdiri dari : a.
Generalization Adalah hubungan antara dua atau lebih class yang lebih spesialisasi ( sub kelas ) dengan sebuah class yang lebih umum ( super kelas ). Dimana hubungan spesialisasi tersebut dapat dinyatakan dengan
36 rumus “ is - a “. Struktur generalisasi menggambarkan pewarisan ( inheritance ) yakni specialized class ( kelas yang terspesialisasi ) mendapatkan properti dan behavioral pattern dari general class ( kelas umum ). Gambar 2.4 menunjukkan contoh generalisasi.
Person
Customer
Employee
Gambar 2. 4 Generalization Structure ( Sumber : Mathiassen, et al., 2000, p74 ) b.
Cluster Adalah kumpulan dari class – class yang berkaitan. memberikan
pemahaman
atas
problem
domain
Cluster dengan
memecahkan problem domain menjadi subdomain yang lebih kecil. Notasi grafis yang digunakan adalah sebuah file folder yang mencakup class – class didalamnya. Class – class dalam sebuah cluster biasanya dihubungkan dengan generalization structure atau dengan aggregation structure. Gambar 2.5 menunjukkan contoh cluster.
37 << cluster>> Cars
Car *
1 Passenger Car
Engine 1 * Cylinder
Taxi
Gambar 2.5 Cluster Structure ( Sumber : Mathiassen, et al., 2000, p75 ) 2. Structure antara objek Struktur ini menggambarkan hubungan yang dinamis antara objek – objek dalam problem domain. Struktur antar objek terdiri dari : a. Aggregation Adalah
hubungan
yang
menggambarkan
objek
superior
(
keseluruhan ) yang terdiri dari sejumlah objek inferior ( bagian ). Hubungan ini dapat dinyatakan dengan rumus “ has - a “ atau “ ispart-of “. Gambar 2.6 menunjukkan contoh agregasi. Terdapat tiga struktur agregasi, yakni : 1. Whole-Part , yang mana objek superior merupakan penjumlahan dari objek inferior; jika objek inferior tersebut ditambah atau dihilangkan, akan mengubah total objek superior. 2. Container-Content, yang mana objek superior adalah container ( penampung ) untuk objek inferior. Objek superior tidak akan
38 berubah jika terjadi penambahan atau penghapusan objek inferior. 3. Union-Member, yang mana objek superior merupakan kesatuan dari anggota – anggota ( objek inferior ). Objek superior tidak akan berubah jika terjadi penambahan atau penghapusan objek inferior, namun tetap memiliki batasan. Car 1
1
1
1
4..*
1
Body
Engine
W heel
Gambar 2.6 Aggregation Structure ( Sumber : Mathiassen, et al., 2000, p76 ) b. Association Adalah hubungan diantara sejumlah objek yang memiliki makna tertentu.
Hubungan ini dapat dinyatakan dengan rumus “knows“
atau “associated-with “. Gambar 2.7 menunjukkan contoh asosiasi. 0..* Car
1..* Person
Gambar 2.7 Association Structure ( Sumber : Mathiassen, et al., 2000, p77 )
Hasil akhir dari aktivitas structure ini adalah class diagram dengan class dan struktur – strukturnya.
39 2.5.6.3
Behaviour Menurut Mathiassen, et al. ( 2000 ) kegiatan behaviour adalah
kegiatan terakhir dalam analisa problem domain yang bertujuan untuk memodelkan apa yang terjadi ( perilaku dinamis ) dalam problem domain sistem sepanjang waktu.
Tugas utama dalam kegiatan ini adalah
menggambarkan pola perilaku ( behavioural pattern ) dan atribut dari setiap class. Behaviour ( perilaku ) dari sebuah objek didefinisikan dengan event trace yang menggambarkan urutan tertentu atas event – event sepanjang waktu. Contoh event trace dari objek class ” Customer ” sebagai berikut : Account opened – amount deposited – amount withdrawn – amount deposited – account closed. Daripada menggambarkan behaviour untuk setiap objek dalam problem domain, dapat digambarkan sebuah behavioural pattern untuk semua objek dalam sebuah class.
Behavioural pattern adalah sebuah
deskripsi dari semua event trace – event trace yang mungkin untuk semua objek dalam sebuah class. Terdapat tiga jenis notasi untuk behavioural pattern yaitu : 1.
sequence, dimana event muncul satu per satu secara berurutan
2.
selection, dimana hanya satu event yang akan terjadi dari sekelompok event yang ada
3.
iteration, dimana sebuah event muncul sebanyak nol atau beberapa kali
40 Hasil akhir dari kegiatan ini adalah statechart diagram seperti ditunjukkan dalam gambar 2.8 account opened ( date )
Customer
account closed ( date )
-name -address -balance
Open amount deposited ( date, amount ) amount withdrawn ( date, amount )
Gambar 2.8 Statechart Diagram untuk Class “ Customer “ ( Sumber : Mathiassen, et al., 2000, p90 )
2.5.7 Analisis Application Domain Menurut Mathiassen, et al. ( 2000 ) application domain adalah sebuah organisasi yang mengadministrasi, memonitor, atau mengontrol sebuah problem domain.
Tujuan dari analisis application domain adalah untuk menentukan
persyaratan penggunaan sistem ( system requirements ). Aktivitas – aktivitas dalam analisis application domain ditunjukkan dalam tabel 2.5 sebagai berikut :
41 Kegiatan Usage
Isi Bagaimana sistem berinteraksi dengan user dan dengan sistem lain dalam konteks? Bagaimana kemampuan sistem dalam memproses informasi ? Apa kebutuhan atau persyaratan dari interface sistem yang ditargetkan ?
Functions
Interface
Konsep Use case dan actor
Function
Interface, user interface, dan system interface
Tabel 2.5 Aktivitas dalam Analisa Application Domain ( Sumber : Mathiassen,et al., 2000, p117 )
2.5.7.1
Usage Menurut Mathiassen, et al. ( 2000 ) usage adalah kegiatan yang
bertujuan untuk menentukan bagaimana actor berinteraksi dengan sebuah sistem. Actor adalah sebuah abstraksi dari para pengguna ( user ) atau sistem lain yang berinteraksi dengan target sistem. Use case adalah sebuah pola interaksi antara sistem dan actor dalam application domain. Hasil akhir dari aktivitas ini adalah deskripsi dari semua use case dan actor seperti ditunjukkan dalam gambar 2.9 sebagai berikut :
42 Au to m atic P aym en t S ys tem paym ent
cash wi t hdr awal Account owner
Li qui di t y m oni t or
m oney t r ansf er
account i nf or mat i o n
cr edi t i nf or mat i on
Adm i ni st r at or
cr edi t or
r egi st r at i on
m oni t or i ng
er r or cor r ect i on
Gambar 2.9 Use Case Diagram dari Automatic Payment System ( Sumber : Mathiassen, et al., 2000, p122 )
2.5.7.2
Functions Menurut Mathiassen, et al. ( 2000 ) kegiatan functions yang
merupakan kegiatan kedua dalam application domain bertujuan untuk menentukan kemampuan sistem dalam pemrosesan informasi. Functions berfokuskan pada apa yang dapat dilakukan oleh sistem untuk membantu actor dalam menjalankan tugas – tugas mereka. Function adalah sebuah fasilitas yang membuat sebuah model menjadi bermanfaat bagi actor. Sebuah fungsi di aktifkan, dieksekusi dan akan menyediakan hasil.
Eksekusi fungsi dapat merubah status dari
komponen model atau membentuk suatu efek reaksi dalam application
43 domain atau problem domain. Fungsi direalisasi melalui operasi program ( program operations ). Functions memiliki empat tipe yang berbeda yaitu : 1. update functions adalah fungsi yang diaktifkan oleh sebuah event dalam problem domain dan menghasilkan perubahan status model ( model’s state ). 2. signal functions adalah fungsi yang diaktifkan karena adanya perubahan dalam status ( state ) model dan menghasilkan reaksi dalam konteks sistem. Reaksi ini dapat berupa display untuk actor dalam application domain atau berupa intervensi langsung dalam problem domain. 3. read functions adalah fungsi yang diaktifkan karena adanya kebutuhan informasi dalam tugas actor dan menghasilkan display berupa informasi mengenai bagian – bagian yang relevan dari sebuah model. 4. compute functions adalah fungsi yang diaktifkan karena adanya kebutuhan informasi dalam tugas actor dan melibatkan perhitungan dengan menggunakan informasi yang disediakan oleh actor ataupun dari model. Hasilnya adalah display atas hasil perhitungan. Cara untuk mengidentifikasikan function adalah dengan melihat deskripsi problem domain yang ditampilkan oleh class dan event, dan melihat deskripsi application domain yang ditampilkan dalam use case. Class dapat menyebabkan munculnya function read dan update.
Event
44 memungkinkan munculnya kebutuhan terhadap function update. Sementara use case dapat menyebabkan munculnya semua jenis function. Hasil akhir dari kegiatan functions adalah list of functions dengan spesifikasi atas complex functions. Contoh function list dapat dilihat pada tabel 2.6 berikut :
45 Function
Kompleksitas
Tipe
Make schedule
Very complex
Update
Calculate schedule consequences
Complex
Signal
Find working hours from previous period
Medium
Read
Enter contents into schedule
Complex
Update
Erase schedule
Simple
Update
Query earlier schedules
Medium
Read
Make appointment
Medium
Update
Cancellation
Simple
Update
Query possible appointments
Complex
Read
Register treatment
Simple
Update
Create customer
Simple
Update
Query customer information
Medium
Read
Employment
Simple
Update
Retirement
Simple
Update
Update apprentice information
Simple
Update
Tabel 2.6 Function List ( Sumber : Mathiassen, et al., 2000, p145 )
2.5.7.3
Interface Menurut Mathiassen, et al. ( 2000 ), kegiatan interface merupakan
kegiatan ketiga dalam application domain.
Interface adalah fasilitas –
fasilitas yang membuat model dan fungsi sistem tersedia untuk actor.
46 Interface merupakan kegiatan untuk menentukan interface dari sistem. Interface digunakan oleh actor untuk berinteraksi dengan sistem. Interface terdiri dari dua macam, yakni ; 1.
user interface merupakan interface yang menghubungkan sistem dengan user
2.
system interface merupakan interface yang menghubungkan suatu sistem dengan sistem lainnya. Terdapat empat jenis pola dialog yang penting dalam menentukan
user interface, yaitu : 1. Menu – selection Merupakan suatu pola yang menampilkan sebuah daftar pilihan – pilihan yang mungkin dalam user interface. 2. Form fill- in Merupakan pola klasik untuk data entry dengan menggunakan terminal yang berbasiskan pada karakter.
User memasukkan data pada
sekumpulan field – field yang saling berhubungan. 3. Command-language Merupakan user interface dimana user memasukkan dan mengaktifkan perintah – perintah ( commands ) yang telah diformat. 4. Direct-manipulation Merupakan user interface dimana user bekerja dengan representasi objek – objek yang ada. User memilih objek – objek yang ada dan
47 melaksanakan fungsi – fungsi dalam objek tersebut dengan hasil yang dapat terlihat dengan segera. Dalam menganalisa system interface, harus diperoleh pemahaman tentang : 1. data yang harus dikirim dari suatu sistem ke sistem lain 2. data yang akan diterima suatu sistem dari sistem lain Dua macam pola system interface yakni : 1. read external device merupakan interface dimana sistem perlu melakukan pembacaan terhadap external device. Sistem sering perlu membaca external device secara regular atau sebagai respon atas event – event dalam problem domain. Sistem dapat bertukar data dengan external device. 2. interaction protocol komunikasi dengan sistem lainnya dapat saja lebih bersifat kompleks dibandingkan hanya bertukar informasi dengan external device karena antar sistem dapat saling mempengaruhi. Sebagai contoh, sebuah sistem dapat mengirimkan permintaan ( query ) kepada sistem lain yang meminta dieksekusinya sebuah fungsi. Hasil akhir dari aktivitas ini adalah berupa user interface dan system interface. Contoh navigation diagram seperti ditunjukkan gambar 2.10
48
Exit
Start
Commands, menu selections, or buttons to change screens or windows
Miniature of screen or window
Gambar 2.10 Navigation Diagram ( Sumber : Mathiassen, et al., 2000, p160 )
2.5.8 Architectural Design Menurut Mathiassen,et al. ( 2000 ) arsitek membuat sistem sesuai dengan fungsi sistem tersebut dan dengan memenuhi kriteria desain tertentu. Arsitektur juga berfungsi sebagai kerangka untuk kegiatan pengembangan yang selanjutnya. Sebuah arsitektur yang tidak jelas akan menghasilkan banyak pekerjaan yang sia – sia . Tujuan dari aktivitas ini adalah untuk menyusun struktur dari sistem yang terkomputerisasi.
Hasil akhir dari aktivitas ini adalah komponen dan proses dari
sebuah sistem. Aktivitas – aktivitas dalam architectural design adalah seperti ditunjukkan dalam tabel 2.7 sebagai berikut :
49 Aktivitas Criteria
Isi Apa kondisi dan kriteria untuk desain ? Bagaimana sistem dibentuk menjadi komponen – komponen ? Bagaimana proses sistem didistribusikan dan dikordinasikan ?
Components
Processes
Konsep Criterion Component architecture dan component Process architecture dan process
Tabel 2.7 Aktivitas dalam Architectural Design ( Sumber : Mathiassen, et al., 2000, p176 )
2.5.8.1 Criteria Menurut Mathiassen, et al. ( 2000 ) criterion adalah propertiproperti yang diinginkan atas sebuah arsitektur. Conditions adalah peluang – peluang dan keterbatasan – keterbatasan dalam hal teknis, organisasi dan sisi manusia yang terkait dengan pelaksanaan suatu tugas.
Untuk
menciptakan sebuah desain yang baik diperlukan pertimbangan mengenai kondisi – kondisi dari setiap proyek yang dapat mempengaruhi kegiatan desain yaitu : 1. Technical, yang terdiri dari pertimbangan : penggunaan hardware, software dan sistem lain yang telah dimiliki dan dikembangkan; pengaruh kemungkinan penggabungan pola – pola umum dan komponen yang telah ada terhadap arsitektur dan kemungkinan pembelian komponen standar. 2. Organizational, yang terdiri dari pertimbangan: perjanjian kontrak, rencana untuk pengembangan lanjutan, dan pembagian kerja antara pengembang.
50 3. Human, yang terdiri dari pertimbangan : keahlian dan pengalaman orang yang terlibat dalam kegiatan pengembangan dengan sistem yang serupa dan dengan platform teknis yang akan didesain. Sebuah desain yang baik memiliki tiga ciri – ciri yaitu : 1. tidak memiliki kelemahan Sebuah desain yang bahkan hanya mengandung satu kelemahan saja dapat menyebabkan desain menjadi tidak bermanfaat dalam praktek nantinya. 2. menyeimbangkan beberapa kriteria Kriteria – kriteria dapat saja saling bertentangan, sehingga kita harus menentukan kriteria mana yang harus ditekankan dan bagaimana menyeimbangkan kriteria – kriteria yang saling bertentangan tergantung pada kondisi yang ada. 3. usable, flexible, dan comprehensible usable adalah derajat sampai dimana desain sistem memenuhi kebutuhan user dan sampai dimana desain sesuai dengan technical platform. Flexible adalah meminimalkan konsekuensi – konsekuensi yang timbul dari perubahan – perubahan yang mungkin akan terjadi. Comprehensible
berarti
menyederhanakan
pemikiran
dengan
mengumpulkan beberapa elemen dalam satu konsep dan hal ini dapat tercapai melalui abstraksi. Hasil akhir dari aktivitas ini adalah kumpulan kriteria. Beberapa kriteria umum yang digunakan dalam kegiatan desain yang berorientasi objek adalah seperti ditunjukkan dalam tabel 2.8:
51 Criterion Usable
Ukuran dari Kemampuan sistem beradaptasi dengan konteks organisasi, konteks yang berhubungan dengan tugas dan konteks teknis. Secure Pencegahan terhadap akses yang tidak terotorisasi atas data dan fasilitas Efficient Penggunaan yang ekonomis atas fasilitas platform teknis ( techincal platform ) Correct Pemenuhan kebutuhan atau persyaratan Reliable Pemenuhan ketelitian atau ketepatan dalam eksekusi fungsi Maintainable Biaya menemukan dan memperbaiki kerusakan sistem Testable Biaya untuk menjamin bahwa sistem yang diterapkan dapat melaksanakan fungsi yang diinginkan Flexible Biaya untuk memodifikasi sistem yang diterapkan Comprehensible Usaha yang dibutuhkan untuk mendapatkan pemahaman atas sistem Reusable Kemungkinan penggunaan bagian – bagian sistem pada sistem lain yang berhubungan Portable Biaya untuk memindahkan sistem kepada technical platform yang berbeda Interoperable Biaya untuk menggabungkan sistem dengan sistem lain Tabel 2.8 Kriteria untuk Kualitas Software ( Sumber: Mathiassen, et al., 2000, p178 )
2.5.8.2 Component Architecture Menurut Mathiassen, et al. ( 2000 ) component architecture adalah sebuah struktur sistem yang terdiri dari komponen – komponen yang saling berhubungan.
Component adalah sebuah kumpulan bagian – bagian
program yang merupakan satu kesatuan dan memiliki tanggung jawab yang telah didefinisikan dengan baik. Beberapa pola umum dalam desain komponen arsitektur yakni : 1. layered architecture pattern merupakan arsitektur yang terdiri dari komponen – komponen yang dinamakan layers ( lapisan – lapisan ). Gambar 2.11 menunjukkan
52 layered architecture pattern. Setiap komponen memiliki tanggung jawabnya masing – masing.
Downward interface menggambarkan
operasi yang dapat diakses komponen atas layer yang ada dibawahnya. Upward interface menggambarkan operasi yang tersedia untuk layer diatasnya. <
>
Layer i+1 upwards interface
<>
Layer i downwards interface
<>
Layer i-1
Gambar 2.11 Layered Architecture Pattern ( Sumber : Mathiassen, et al., 2000, p193 ) 2. generic architecture pattern Pola ini digunakan untuk merinci sistem dasar yang terdiri dari komponen interface, function, dan model. Gambar 2.12 menunjukkan generic architecture pattern . Dimana komponen model terletak pada lapisan yang paling bawah, kemudian dilanjutkan dengan function layer dan paling atasnya komponen interface.
53
<>
interface <>
<>
user intertace
system interface
<>
function
<>
m odel <>
technical platform
<>
UIS
<>
<>
DBS
NS
Gambar 2.12 Generic Architecture Pattern ( Sumber : Mathiassen, et al., 2000, p196 ) 3. client server architecture pattern Pola ini awalnya dikembangkan untuk mengatasi masalah sistem yang terdistribusi diantara beberapa prosesor yang tersebar secara geografis. Gambar 2.13 menunjukkan client server
architecture pattern.
Komponen pada arsitektur ini adalah sebuah server dan beberapa client. Tanggung jawab dari server adalah untuk menyediakan database dan resource yang dapat disebarkan kepada client melalui jaringan. Sementara client memiliki tanggung jawab untuk menyediakan interface lokal untuk setiap user-nya.
Identifikasi komponen, didalam
perancangan sistem atau subsistem, pada umumnya dimulai dengan layer architecture dan client server architecture dimana keduanya merupakan dua layer yang berbeda, tetapi saling melengkapi.
54
<>
<>
Client 1
Client 2
....
<>
Client n
<>
Server
Gambar 2.13 Client Server Architecture Pattern ( Sumber : Mathiassen, et al., 2000, p197 )
Tabel 2.9 menunjukkan bentuk – bentuk distribusi client server architecture. Client U U U+F U+F U+F+M
Server U+F+M F+M F+M M M
Architecture Distributed presentation Local presentation Distributed functionality Centralized data Distributed data
Tabel 2.9 Bentuk – bentuk Client Server Architecture ( Sumber : Mathiassen, et al., 2000, p200 )
2.5.8.3 Process Architecture Menurut Mathiassen, et al. ( 2000 ) process architecture adalah struktur dari eksekusi sistem yang terdiri dari proses – proses yang saling bergantung. Processor adalah sebuah peralatan yang dapat mengeksekusi program.
Program component adalah modul fisik atas kode program.
Active object adalah sebuah objek yang telah diberikan sebuah proses. Hasil akhir aktivitas ini berupa deployment diagram. Sebuah sistem dapat terdistribusi pada beberapa prosesor yang terhubung melalui jaringan. Beberapa pola distribusi adalah : 1. centralized pattern
55 pola ini menyimpan semua data pada server pusat dan user hanya dapat melihat user interface saja.
Gambar 2.14 menunjukkan centralized
pattern. Keuntungannya adalah dapat diimplementasikan pada client dengan murah, semua data konsisten karena hanya berada disatu tempat, strukturnya mudah dimengerti dan diimplementasikan, dan kemacetan jaringannya sedang. Kerugiannya adalah robustness yang rendah ( jika server mengalami masalah ( down ) , maka client tidak dapat melakukan apapun ), waktu akses yang lebih lama dan tidak memfasilitasi back up data.
: Cl i en t u se r i nt e r f ac e
more cl i ent s s y s t e mi nt e r f a c e
: S e r v er
u se r i nt e r f ac e
s y s t e mi nt e r f ac e
f u n ct i o n
m o d el
Gambar 2.14 Centralized Pattern ( Sumber : Mathiassen, et al., 2000, p216 ) 2. Distributed pattern Dalam pola ini semua data terdistribusi ke user atau client dan server hanya menyebarkan model yang telah di-update di antara client.
56 Gambar 2.15 menunjukkan distributed pattern. Setiap kopi dari model yang lengkap ditempatkan pada setiap client. Keuntungannya adalah waktu akses yang rendah, robustness yang maksimal (jika server, network, ataupun client lainnya mengalami masalah ( down ) , maka client masih dapat melakukan fungsinya ), dan backup data yang banyak. Kerugiannya adalah redudansi data sehingga konsistensi data kurang, kemacetan jaringan yang tinggi, persyaratan teknis yang lebih tinggi untuk client, dan arsitektur sulit dipahami dan diimplementasikan. : Client
u s e r interface
system interface
function
model
m ore clients : Server
system interface
Gambar 2.15 Distributed Pattern ( Sumber : Mathiassen, et al., 2000, p217 ) 3. decentralized pattern client Pola ini berada diantara kedua pola diatas. Disini client memiliki data tersendiri sehingga data umum hanya berada pada server. Gambar 2.16 menunjukkan decentralized pattern. Server menyimpan data umum dan fungsi atas data – data tersebut, sedangkan client menyimpan data
57 dimana client sebagai bagian dari application domain. Keuntungannya adalah konsistensi data karena tidak adanya duplikasi data, lalu lintas jaringan yang rendah, dan waktu akses yang rendah. Kerugiannya adalah semua prosesor harus mampu melakukan fungsi yang kompleks dan
memelihara
model
dalam
jumlah
yang
besar,
sehingga
meningkatkan biaya hardware. : C l i en t
u s e r i nt er f ac e
s y s t em i nt er f ac e
f un c t i on
m o d e l ( l oc a l )
m ore c l i en t s : S erv er
u s e r i nt er f ac e
s y s t em i nt er f ac e
f un c t i on
m od el ( c om m on )
Gambar 2.16 Decentralized Pattern ( Sumber : Mathiassen, et al., 2000, p219 )
2.5.9 Component Design Menurut Mathiassen, et al. ( 2000 ) tujuan dari kegiatan component design adalah untuk menentukan implementasi kebutuhan atau persyaratan sistem dalam kerangka arsitektur. Hasil akhir dari aktivitas ini adalah deskripsi dari komponen – komponen sistem.
58 Tabel 2.10 adalah kegiatan dari component design : Aktivitas Model Component Function Component Connecting Component
Isi Bagaimana suatu model digambarkan sebagai kelas dalam sebuah sistem ? Bagaimana function diimplementasikan ? Bagaimana komponen – komponen saling dihubungkan ?
Konsep Model component attribute
dan
Function Component dan Operation Component dan connection
Tabel 2.10 Aktivitas dalam Component Design ( Sumber : Mathiassen, et al., 2000, p232 )
2.5.9.1 Model Component Menurut Mathiassen, et al. ( 2000 ) model component adalah bagian dari sistem yang mengimplementasikan model problem domain. Tujuan dari model component adalah untuk memberikan data saat ini dan data historis pada functions, interface dan user serta sistem lainnya. Hasil dari kegiatan model component adalah revisi dari class diagram dari kegiatan analisis yang terdiri dari kegiatan penambahan class, atribut dan struktur baru yang mewakili event. Gambar 2.17 menunjukkan revised class diagram.
59
Custom er -creditapproval -creditapprovaldate -name
1
1 1..*
1..* Custom er Address -fromdate -address
Account -accountnumber -accountstate -opendate -closedate
1 0..* Transaction -transtype -date -amount
Gambar 2.17 Revised Class Diagram ( Sumber : Mathiassen, et al., 2000, p236 ) Revisi pada class dapat terjadi pada : 1.
Generalization Jika terdapat dua class dengan atribut yang sama maka dapat dibentuk class baru. Gambar 2.18 menunjukkan contoh revisi pada bentuk generalisasi. Ac c o u n t -
Ac c o u n t
acc ount num ber acc ount st at e opendat e cl os edat e
1
0. . *
1
1
0. . *
D ep os it - dat e - am ount
- ac c ount n um ber - ac c ount st at e - open dat e - cl os edat e
W i t hd r aw - dat e - am oun t
s o l us i a w a l
0. . * T r an s a c t i on - t r an st ype - dat e - am ount
s o l us i y a n g l e b i h s e d e r h a n a
Gambar 2.18 Menyusun Kembali Class Diagram ( Sumber : Mathiassen, et al., 2000, p244 )
60 2.
Association Jika terdapat hubungan many – to – many. Gambar 2.19 menunjukkan contoh revisi class atas asosiasi. 0. . . *
0. . . *
G a s S t at i on
C u s t om e r fill ( d a t e, o c tan e , v o lum e , p rice )
fill ( d a t e, o c t an e , v o lum e , p rice ) buy car
c los e
s t ar t
s e ll c a r A c t i ve
O pen
a n a l ys i s m o d e l C u s t om e r
G a s S t at i on
1 1 0. . *
0. . *
F i l l i ng d e s i gn m o d e l
Gambar 2.19 Contoh Revisi Class atas Association ( Sumber : Mathiassen, et al., 2000, p245 ) 3.
Embedded iterations Jika dalam statechart diagram terdapat event – event yang bersifat berulang ( iterative ) maka dapat dibuat class – class baru terhadapnya. Gambar 2.20 menunjukkan revisi atas embedded iterations.
61
treat
birth
hospitalized
Person
Well
Hospitalized
discharge death death
analysis model Person 1 0...*
Hospitalization
1
1
0..*
0...*
Treatment
Discharge
design model
Gambar 2.20 Contoh Revisi Class atas Embedded Iterations ( Sumber : Mathiassen, et al., 2000, p246 )
2.5.9.2 Function Component Menurut Mathiassen, et al. ( 2000 ) function component adalah bagian dari sistem yang mengimplementasikan persyaratan atau kebutuhan sistem. Operations adalah properti dari proses yang dispesifikasikan dalam sebuah class dan diaktifkan melalui objek dari class. Tujuan dari function component adalah untuk memberikan akses bagi user interface dan komponen sistem lainnya ke model sehingga menunjukkan pengimplementasian dari function. Hasil dari aktivitas ini adalah class diagram dengan operations dan spesifikasi dari operation yang kompleks. Empat tipe fungsi dan operation yang terkait yakni : 1. update
62 fungsi ini terhubung secara langsung dengan event – event dalam problem domain.
Fungsi update menerima input data yang
menggambarkan event dan menghasilkan output utamanya yakni mengupdate model. Gambar 2.21 menunjukkan contoh update function.
functions:Function
update()
object1:Model-Class1
object2:Model-Class2
update() update-refused() update-successful()
update() update-refused() failure()
update-successful()
()
Gambar 2.21 Update Function dan Operasinya ( Sumber : Mathiassen, et al., 2000, p255 ) 2. read fungsi ini menggambarkan kebutuhan dari user ataupun sistem lain untuk mendapatkan informasi dari model.
Sistem dilihat sebagai
database dimana informasi yang diinginkan dapat ditemukan sebagai atribut. Fungsi ini menerima input data yang menggambarkan data yang ingin dibaca dan menghasilkan output berupa informasi yang diinginkan yang dibaca dari model. Gambar 2.22 menunjukkan contoh read function.
63
functions:Function
read()
object1:Model-Class1
object2:Model-Class2
read() not-found() result()
read() not-found() result()
result()
Gambar 2.22 Read Function dan Operasinya ( Sumber : Mathiassen, et al., 2000, p257 ) 3. compute fungsi ini menggambarkan bahwa user atau sistem lain membutuhkan pemrosesan data yang dapat juga melibatkan pembacaan model. Input atas fungsi ini berupa angka – angka sebagai bagian dari proses perhitungan dan atribut – atribut yang menggambarkan objek – objek dari model yang relevan. Fungsi ini menghasilkan output berupa hasil dari perhitungan. Gambar 2.23 menunjukkan contoh compute function.
64
functions:Function
compute()
object1:Model-Class1
object2:Model-Class2
read() not-found() result()
read() not-found() result()
result()
Gambar 2.23 Compute Function dan Operasinya ( Sumber : Mathiassen, et al., 2000, p258 ) 4. signal fungsi
ini
menggambarkan
kebutuhan
akan
pemonitoran
atau
pengontrolan. Dalam sistem dimana pemonitoran atau pengontrolan adalah penting, suatu reaksi akan diberikan jika problem domain memasuki suatu kondisi ( state ). Dalam banyak kondisi, fungsi ini tidak menerima input data khusus. Input berasal dari model. Output data berupa pesan kepada user dalam application domain atau impuls pengontrolan secara langsung ke device dalam problem domain. Gambar 2.24 menunjukkan contoh signal function.
65
functions:Function
activate()
object1:Model-Class1
object2:Model-Class2
critical() result()
critical() () result() signal()
Gambar 2.24 Signal Function dan Operasinya ( Sumber : Mathiassen, et al., 2000, p259 )
Untuk menspesifikasikan operasi yang kompleks dapat dilakukan dengan membuat operation specification seperti ditunjukkan dalam tabel 2.11 berikut :
66 Name Category
Register transaction _ Active X Passive
X Update _ Read _ Compute _ Signal Establishes a new transaction for a specific account Account_no, transtype, date, amount
Purpose Input Data Conditions An object of the class Account, with the given account number, exists. The attribute accountstate in this object has the value open A new object of the class transaction is establishes with input Effect data assigned to the attributes. This object is connected to the relevant account object Algorithm Data Structures Placement Account Account, transaction Involved Objects Triggering Amount deposited, amount withdrawn Events Tabel 2.11 Contoh Operation Specification. ( Sumber : Mathiassen, et al., 2000, p265 )