7 BAB 2 LANDASAN TEORI
2.1
Pengertian Sistem Informasi Akuntansi Sistem informasi akuntansi adalah “a computer based system designed to transform accounting data into information” (Bodnar and Hopwood, 2004, p.1). Menurut Jones and Rama (2003, p5) sistem informasi akuntansi adalah ”a subsystem of management information system that provides accounting and financial information, as well as, other information obtained in the routine processing of accounting transactions. Menurut McLeod (2001,p219) sistem informasi akuntansi adalah sistem yang
mengolah
data
perusahaan
dengan
mengumpulkan
data
yang
menggambarkan kegiatan perusahaan, mengubahnya menjadi informasi, dan membuat informasi tersebut tersedia bagi pemakai yang berada baik di dalam maupun di luar perusahaan. Jadi dapat ditarik kesimpulan bahwa sistem informasi akuntansi adalah sistem berbasis komputer yang dirancang untuk menyediakan informasi akuntansi, keuangan atau informasi lain yang diperoleh dari pengumpulan data dan pemrosesan berbagai transaksi perusahaan.
2.2
Sistem Informasi Akuntansi Penjualan Dan Penerimaan Kas 2.2.1
Proses bisnis Menurut Bodnar and Hopwood (2004) seluruh kegiatan perusahaan yang
berhubungan secara finansial dapat dipandang sebagai bagian dari proses bisnis
8 yang sangat beragam. Proses bisnis adalah sekumpulan tugas yang saling berhubungan yang melibatkan data, unit organisasi, dan urutan waktu yang logis. Juga diungkapkan bahwa siklus transaksi merupakan alternatif lain untuk memandang kegiatan-kegiatan yang dilakukan perusahaan. Siklus transaksi secara tradisional dapat dikelompokkan ke dalam empat siklus yang umum yaitu: 1. Siklus pendapatan yang terdiri dari event-event yang berhubungan dengan kegiatan pendistribusian barang dan jasa ke entitas yang lain dan kegiatan pengumpulan pembayaran atas pendistribusian barang yang telah dilakukan. 2. Siklus pengeluaran yang terdiri dari event-event yang berhubungan dengan kegiatan perolehan barang dan jasa dari entitas lain dan penyelesaian kewajiban dari kegiatan perolehan tersebut. 3. Siklus produksi yang terdiri dari event-event yang berhubungan dengan kegiatan pengubahan sumber daya menjadi barang dan jasa. 4. Siklus keuangan yang terdiri dari event yang berhubungan dengan perolehan dan manajemen dana kapital, termasuk kas. 2.2.1.1
Penjualan. Menurut Standar Akuntansi Keuangan (2004, PSAK No.23.1),
penjualan barang meliputi barang yang diproduksi perusahaan untuk dijual kembali, seperti barang dagang yang dibeli pengecer atau tanah atau properti lain yang dibeli untuk dijual kembali, sedangkan penjualan jasa menyangkut pelaksanaan tugas yang secara kontraktual telah disepakati untuk dilaksanakan selama suatu periode waktu yang disepakati perusahaan. Jasa tersebut dapat diserahkan selama satu periode atau selama lebih dari satu periode.
9 2.2.1.2
Pengertian piutang Menurut Horngren, Harrison, dan Bamber (2002, p G-1), piutang
adalah sebuah perjanjian untuk menerima kas dari pelanggan yang kepada pelanggan tersebut perusahaan telah menjual dan menyerahkan barang atau jasa. Menurut Kieso, Weygandt, dan Warfield (2001, p320), piutang diakui pada saat: diberikan discount (trade dan cash discount) oleh perusahaan dalam arti jika pembeli dapat melakukan pembayaran dalam jumlah hari tertentu setelah pembelian, maka akan diberikan potongan sekian persen lamanya waktu antara penjualan yang terjadi dengan jatuh tempo pembayaran (yang menimbulkan elemen bunga). Menurut Bodnar and Hopwood (2004, p.251), ”there are two basic approaches to an accounts receivable application: open item and balance-forward processing. In Open item processing, a separate record is maintained in the account receivable system for each of the customer’s unpaid invoices. As customer remmitance are received, they are matched to the unpaid unvoices. In Balance-forward processing, a customer remittance are apllied against the customer’s total outstanding balance rather than against the customer’s individual invoices.” .
10 2.2.2 Dokumen yang berhubungan dengan siklus pendapatan Mengacu pada Wilkinson, Cerullo, Reval, dan Wong-On-Wing (2000) berikut adalah dokumen-dokumen yang dibutuhkan dalam siklus pendapatan perusahaan dagang: 1. Customer order Adalah purchase order yang diterima dari pelanggan atau form yang dipersiapkan oleh karyawan penjualan dari perusahaan penjual. 2. Sales order Adalah form formal, yang memiliki banyak copy yang disiapkan dari customer order. 3. Picking ticket Adalah copy dari sales order, dokumen terpisah yang dikirim ke gudang dan dalam pengambilan barang yang dipesan. 4. Packing slip Adalah copy dari sales order atau picking list yang ditempelkan bersama barang ketika dipersiapkan untuk pengiriman. 5. Shipping notice Biasanya merupakan copy dari sales order atau dokumen pengiriman terpisah yang berfungsi sebagai bukti bahwa barang telah dikirimkan. 6. Sales invoice Adalah dokumen yang dikirimkan ke pelanggan untuk menyatakan berapa jumlah penjualan. 7. Remittance advice Adalah dokumen yang menunjukan jumlah penerimaan kas dari pelanggan.
11 8. Deposit slip Adalah dokumen yang menyertai penyetoran kas ke bank 9. Back order Adalah dokumen yang dipersiapkan ketika kuantitas dari persediaan tidak mencukupi sales order. 10. Credit memo Adalah dokumen yang memungkinkan pengurangan kredit pelanggan untuk pengembalian penjualan / penyisihan penjualan. 11. Credit application Adalah sebuah form dipersiapkan ketika pelanggan baru mengajukan kredit. 12. Sales person call report Adalah form yang digunakan untuk menggambarkan pangggilan yang dibuat oleh sales person kepada pelanggan potensial dan mengidentifikasi hasil dari panggilan tersebut. 13. Delinquent notice Adalah catatan yang dikirimkan kepada pelanggan yang melewati batas saldo kredit. 14. Right of notice Adalah dokumen yang dipersiapkan oleh manajer kredit ketika akun dinyatakan tidak dapat ditagih. 15. Cash register receipt Adalah form yang digunkan oleh retailer untuk mencerminkan kas yang diterima.
12 16. Bill of ladding Adalah dokumen pengiriman yang digunakan untuk perusahaan pengiriman yang akan mengirimkan produk.
2.2.3 Proses sistem pada penjualan dan penerimaan kas 2.2.3.1 Proses sistem pada penjualan kredit Mengacu pada Wilkinson et al. (2000), langkah-langkah proses sistem pada penjualan kredit adalah : 1. Order Entry Setiap purchase order dimasukkan ke sebuah preformatted screen pada suatu terminal yang on-line yang secepatnya diterima oleh sales order clerk pada divisi pemasaran. Entry bisa dari pesanan pelanggan atau dari phone call pelanggan atau salesperson. Jika kekurangan jumlah dari produk yang tersedia, sales order clerk dapat menetapkan suatu back order untuk disiapkan pada sistem komputer. Kemudian, sebuah credit checking program menentukan bila pelanggan adalah creditworthy. Check tersebut, didapat dengan membandingkan batas kredit pada catatan pelanggan dengan current balance ditambah estimasi jumlah penjualan pada order transaction. 2. Shipping Setelah pesanan produk sudah diambil dari warehouse, picking list ditandatangani oleh picker dan sudah dapat menunjukan adanya perubahan (antara lain, items out of stock, substitutions). Produk dipindahkan ke shipping dock, dimana seorang clerk menghitungnya
13 dan masuk ke jumlah yang sudah siap untuk pengiriman dari picking list. Suatu shipping program mempersiapkan dokumen yang diperlukan (packing slip, bill of lading, and shipping notice) untuk pengiriman. Ketika produk ditimbang dan dikemas, bersamaan dengan packing slip, dan akan diantar ke pengangkutan untuk pengiriman. dengan disertai copy of the bill of lading. 3. Billing Ketika menerima nota pengiriman, seorang billing clerk menghitung dan masuk batch totals. Seorang clerk juga mengkonversi setiap pesanan ke dalam suatu faktur dengan calling up pesanan pada layarnya, mengacu pada nota pengiriman yang dicetak untuk jumlah yang dikirimkan, memilih harga produk dari pricing file, dan memasukan data yang diperlukan ke sebuah preformatted invoice screen. Semua data yang dimasukan divalidasi dengan edit program. Kemudian data dari semua faktur yang disiapkan akan disimpan untuk sementara pada suatu billing file hingga waktu untuk memproses sebuah batch. Ketika :
Faktur dicetak
Setiap account pelanggan didebet dengan billed amount
Mencatat persediaan yang dikurangi dengan jumlah yang dikirimkan
Order penjualan ditutup untuk sales history file
Sebuah record baru diciptakan pada sales invoice file
14
Jumlah total batched mempengaruhi account penjualan dan account receivables diposkan ke general ledger account
4. Preparing Analyses and Reports Pada akhir dari setiap hari, invoice register dan account receivable summary dicetak. Invoice register adalah sebuah sales transaction listing, yang mempengaruhi sales journal, yang terdiri dari kunci data mengenai tiap sales invoice yang disiapkan selama sehari. Account receivable summary menunjukan perubahan pada account balances pelanggan yang terjadi via post hari itu, ditambah total jumlah post pada batches. 5. Handling Sales Returns and Allowances Sales returns terjadi ketika pelanggan yang tidak puas mengembalikan semua atau sebagian barang-barang yang dipesan. Sales allowances adalah penyesuaian ke dalam prices granted untuk pelanggan sebagai kompensasi untuk kerusakan barang, shortages atau definisi yang spesifik. 6. Processing Back Orders Back Orders diperlukan ketika jumlah inventory on hand yang tidak mencukupi untuk mengisi semua pesanan. Back ordering meliputi persiapan dari back order form, menunjukkan pelanggan yang melakukan pemesanan, nomor order, kuantitas yang diperlukan, dan data request.
15 2.2.3.2 Proses sistem pada penerimaan kas Mengacu pada Wilkinson et al. (2000), langkah-langkah proses sistem pada penerimaan kas adalah : 1. Remittance Entry Cek dan remmitance advices diterima pada mail room pada sebuah batch setiap pagi hari. Seorang mail room clerk menguasakan cek “For Deposit Only” dan memverifikasi bahwa jumlah pada setiap cek sama dengan jumlah remittance advice. Clerk ini kemudian menyiapkan batch total dari remittance advice, mencakup total dari seluruh amounts yang diterima dari remittances. Clerk yang lain memasukkan batch total dan list seperti remittance data sebagai cash receipt amount, customer number, dan sales invoice number untuk setiap penerimaan, menggunakan sebuah preformatted cash receipts screen. 2. Depositing Receipts Satu copy dari remittance list dan cek dikirimkan ke bagian kasir, yang akan di bandingkan dan direkonsiliasi. Kasir kemudian mengentri cek yang diterima dari sumber lain dibandingkan dengan mail room melalui terminal. Ketika semua cek sudah dibukukan, kasir akan memberitahu program penerimaan kas, untuk mencetak daily deposit slip (dalam 3 copy) dan sebuah cash receipts transaction listing (jurnal) dalam 2 copy. Pada suatu waktu yang telah ditentukan kasir membawa 2 copy dari deposit slip ke bank, bersama dengan semua cek. Bank mengembalikan validated deposit slip ke manajer accounting, yang mana merekonsiliasi slip dengan sebuah copy dari cash receipts listing.
16 3. Post Receipts Sebelum meng update customer account, accounts receivable clerk harus memasukkan koreksi yang dibutuhkan untuk cash receipts transactions list pada pengecualian dan summary report. Clerk boleh menggunakan variasi dari referensi untuk membuat koreksi, termasuk customer dan sales printouts seperti halnya on line files. Dengan penuh harapan, semua koreksi dapat dibuat sepanjang hari selama penerimaan kas. Jika perlu, mereka dapat dipindah ke hari berikutnya. 4. Preparing Analyses and Reports Pada akhir dari setiap hari, ringkasan dari kegiatan account receivable dicetak. Itu bisa di kombinasikan dengan ringkasan account receivable tersebut pada prosedur credit sales atau bisa menjadi sebuah separate. Accounting clerk atau manajer membandingkan totalnya dengan remmitance listing dan dengan general ledger posting. Perbedaan apapun direkonsiliasi dengan bantuan dari cash receipts transaction listing (jurnal). 5. Collecting Delinquent Accounts Banyak pelanggan membayar outstanding balances, atau membuat installment payment, atas receiving statement. Tetapi, bagaimanapun, prosedur collection diperlukan pada kasus slow paying customer. Biasanya, prosedur dimulai dengan peringatan kedua dari balance yang sudah jatuh tempo. Kemudian delinquency notices akan dikirim. Jika pembayaran masih belum diterima, perusahaan dapat menyewa collection agency, faktor yang diterima dengan financing agency, atau
17 secepatnya menghapuskan balances. Langkah terakhir meliputi persiapan dari write off notice. 2.2.4 Sasaran dari siklus pendapatan Menurut Wilkinson et al. (2000) tujuan utama dari siklus pendapatan adalah untuk memfasilitasi pertukaran barang atau jasa dengan sejumlah uang tertentu pelanggan. Berikut adalah sasaran dari siklus pendapatan secara umum: 1. Untuk mencatat pesanan pelanggan secara cepat dan tepat. 2. Untuk memverifikasi bahwa pelanggan layak mendapatkan kredit. 3. Untuk mengirimkan produk pada tanggal telah disetujui. 4. Untuk melakukan penagihan atas produk atau jasa secara tepat pada waktunya dan dengan prosedur yang benar. 5. Untuk mencatat dan mengklasfikasikan penerimaan kas secara cepat dan tepat. 6. Untuk posting penjualan dan penerimaan kas ke akun pelanggan yang tepat dalam jurnal khusus penjualan dan penerimaan kas. 7. Untuk mengamankan produk sampai dikirim. 8. Untuk mengamankan kas sampai disetor. 2.3 Pengendalian Internal Menurut Jones and Rama (2003, p.15) pengendalian internal adalah “the rules, policies, procedures, and information system used to ensure that a company’s financial data are accurate and reliable and to protect a company’s assets from loss or theft.”. Pengendalian internal adalah “a process affected by an entity’s board of directors, management, and other personel designed to provide reasonable assurance regarding the achievement of objective in the following categories:
18 reliablility of financial reporting, effectiveness and efficiency of operations, and compliance with applicable laws and regulation.” (Bodnar and Hopwood, 2004, p.108) Menurut Romney and Steinbart (2003, p.195) pengendalian internal adalah “the plan of organization and the method a business used to safe guard assets, provide accurate and reliable information, promote and improve operational efficiency and encourage adherence to prescribed management policies”. Jadi dapat ditarik kesimpulan bahwa pengendalian internal adalah aturan, kebijakan, prosedur dan sistem informasi yang dirancang untuk memastikan data keuangan perusahaan tepat dan dapat diandalkan, untuk meningkatkan efisiensi dan efektifitas operasi dan untuk memenuhi ketaatan terhadap hukum dan peraturan yang berlaku.
2.4
Pengendalian Internal Sistem Informasi Penjualan Dan Penerimaan Kas Mengacu pada Romney dan Steinbart (2003), beberapa ancaman yang sering ditemui dalam sistem informasi akuntansi penjualan dan penerimaan kas adalah order penjualan yang tidak lengkap atau tidak tepat, pemberian kredit kepada pelanggan yang memiliki catatan kredit yang tidak baik, kegagalan dalam menagih pelanggan, dan lain-lain. Beberapa prosedur pengendalian yang dapat diterapkan untuk mengatasi ancaman-tersebut adalah pemeriksaan input data, pemisahan fungsi pengiriman dan penagihan, persetujuan kredit oleh manajer kredit bukan oleh fungsi penjualan, dan lain-lain. Untuk lebih jelasnya, beberapa ancaman dan prosedur pengendalian untuk mengatasi ancaman-ancaman dalam kegiatan penjualan dan penerimaan kas dapat dilihat pada Tabel 2.1 berikut ini:
19 Proses / kegiatan Entri Order Penjualan
Ancaman 1. Order penjualan yang tidak lengkap atau tidak tetap 2. Memberikan kredit kepada pelanggan yang memiliki status kredit yang tidak baik 3. Otorisasi order 4. Kehabisan stock, carrying cost, dan markdown 1. Kesalahan pengiriman: barang, jumlah dan alamat yang salah 2. Ancaman persediaan
Pengiriman
Penagihan dan piutang
1. Gagal untuk menagih pelanggan
2. Kesalahan dalam penagihan 3. Posting kesalahan dalam mengupdate piutang Penagihan kas
1. Pencurian kas
Isu-isu pengendalian Umum
1. Kehilangan data 2. Kinerja yang buruk
Prosedur kontrol yang applicable Pemeriksaan data entri Persetujuan kredit oleh manajer kredit, bukan oleh fungsi penjualan Catatan saldo pelanggan yang lengkap Tanda tangan pada kertas dokumen Tanda tangan digital dan sertifikat digital untuk e- bussiness Sistem pengendalian persediaan Rekonsiliasi order penjualan dengan picking ticket dan packing slip; bar code scanner, pengendalian aplikasi entri data Hindari akses fisik dengan persediaan, dokumentasi dari segala transfer internal persediaan, pemeriksaan fisik secara periodik dengan jumlah catatan Pemisahan fungsi pengiriman dan penagihan, seluruh dokumen pengiriman bernomor urut tercetak dan rekonsiliasi secara per Iodik dengan faktur, rekonsiliasi picking ticket dan surat jalan dengan order penjualan Pengendalian pemeriksaan entri data daftar harga Rekonsiliasi jurnal pembantu piutang dengan jurnal umum state ement bulanan ke pelanggan Pemisahan tugas, minimasi penanganan kas, pengaturan lockbox persetujuan tepat waktu, deposit setiap penerimaan, rekonsiliasi secara periodik rekening koran dengan catatan yang dibuat oleh dengan catatan yang dibuat oleh pihak yang tidak terlibat dalam pemrosesan penerimaan kas Prosedur backup dan pemulihan terhadap bencana, pengendalian akses (secara fisik dan logis) Mempersiapkan dan mengkaji-ulang laporan kinerja
Tabel 2.1 Pengendalian Internal Sistem Informasi Akuntansi Penjualan Dan Penerimaan Kas
20 2.5
Analisa dan Perancangan Berorientasi Objek 2.5.1
Orientasi Objek Objek merupakan dasar dalam Object Oriented Analysis and Design (OOA&D). Menurut Mathiassen, Munk- Madsen, Nielsen, dan Stage (2000) object adalah “an entity with identity, state, and behaviour.” (p. 4). Setiap objek tidak digambarkan secara sendiri-sendiri, melainkan istilah kelas digunakan untuk menggambarkan kumpulan objek-objek. Menurut Mathiassen L., et.al (2000) class adalah “a description of collection of objects sharing structure, behavioural pattern, and attributes.” (p. 4).
2.5.2 Metodologi 2.5.2.1 Pre – Analysis 2.5.2.1.1 Rich Picture Mengacu pada Mathiassen L ,et al. (2000), rich picture adalah
sebuah
gambaran
informal
yang
digunakan
oleh
pengembang sistem untuk menyatakan pemahaman mereka terhadap situasi dari sistem yang sedang berlangsung. Rich picture juga dapat digunakan sebagai alat yang berguna untuk memfasilitasi komunikasi yang baik antara pengguna dalam sistem.
$
$
21
Gambar 2.1 Contoh Rich Picture 2.5.2.1.2 System Definition Mengacu pada Mathiassen et al. (2000) System Definition adalah suatu penjelasan dari suatu sistem yang terkomputerisasi yang
diwujudkan
dalam
bentuk
natural
language.
Menggambarkan properti dasar untuk pengembangan dan penggunaan
sistem,
dengan
menyediakan
fungsi,
dimana
digunakan dan kapan kondisi yang tepat untuk pengembangannya.
22
Situation Ideas
Systems System definition
Gambar 2.2 Sub kegiatan untuk memilih sebuah sistem 2.5.2.1.3 Factor Mengacu pada Mathiassen et al. (2000), Factor terdiri atas enam elemen yakni: 1.
Functionality : Fungsi sistem yang digunakan untuk mendukung tugas dari application domain
2.
Application Domain : Bagian – bagian yang terdapat dalam suatu organisasi yang menjalankan, mengawasi, atau mengendalikan sebuah problem domain.
3.
Condition : Kondisi – kondisi yang terdapat ketika sistem tersebut akan dibangun dan digunakan.
4.
Technolog : Teknologi yang digunakan untuk membangun sistem dan teknologi yang digunakan untuk menjalankan sistem tersebut.
23 5.
Objects : objek utama yang ada dalam problem domain
6.
Responsibility :Tanggung jawab sistem secara umum dalam kaitannya dengan konteks yang ada.
2.5.2.2 Problem Domain Analysis Mengacu pada Mathiassen et al. (2000) problem domain adalah bagian dari konteks yang diatur, di monitor, atau dikendalikan oleh sistem. Analisis problem-domain memfokuskan pada informasi apa yang harus ditangani oleh sistem dan menghasilkan sebuah model yang merupakan gambaran dari kelas-kelas, objek-objek, struktur dan perilaku (behavior) yang ada dalam problem domain. Untuk lebih jelasnya, kegiatankegiatan yang dilakukan dalam analisis problem-domain dapat dilihat pada tabel berikut ini. Kegiatan Kelas Struktur Behaviour
Isi Objek dan event yang merupakan bagian dari problem domain Bagaimana kelas dan objek saling terkait bersama-sama Properti dinamik yang dimiliki objek
Konsep Kelas, objek, event Generalisasi, agregasi asosiasi, dan cluster Event trace, behavioural pattern, dan atribut
Tabel 2.2 Kegiatan problem-domain analysis 2.5.2.2.1 Class Mengacu pada Mathiassen et al. (2000) kegiatan kelas merupakan kegiatan pertama dalam analisis problem domain. Ada beberapa tugas utama dalam kegiatan ini yaitu: abstraksi fenomena dari problem domain dalam objek dan event; klasifikasi
24 objek dan event; pemilihan kelas-kelas dan event-event yang akan dipelihara informasinya oleh sistem. Pemilihan
kelas-kelas
tersebut
bertujuan
untuk
mendefinisikan dan membatasi problem domain. Sementara pemilihan kumpulan event yang dialami atau di lakukan oleh satu atau lebih objek bertujuan untuk membedakan tiap-tiap kelas dalam problem-domain.Kegiatan kelas akan menghasilkan tabel event.
Gambar 2.3 Contoh Class Diagram 2.5.2.2.2 Structure Mengacu pada Mathiassen et al. (2000) kegiatan kedua dalam analisis problem-domain ini bertujuan untuk mencari hubungan struktural yang abstrak dan umum antara kelas-kelas dan mencari hubungan yang konkrit dan spesifik antara objekobjek dalam problem-domain.
25 Terdapat dua jenis struktur antar kelas yaitu generalisasi dan cluster. Generalisasi adalah hubungan antara dua atau lebih kelas yang lebih khusus (sub kelas) dengan sebuah kelas yang lebih umum (super kelas). Dimana hubungan spesialisasi tersebut dinyatakan dengan rumus “is-a”. Cluster adalah kumpulan kelas yang saling berhubungan yang membantu memperoleh dan menyediakan ringkasan problem-domain. Sebagai contoh: cluster “mobil” berisi semua kelas yang berhubungan dengan jenis kelas dan komponenkomponennya. Terdapat dua jenis hubungan antar objek yaitu: agregasi dan asosiasi. Agregasi adalah hubungan antara sejumlah objek inferior yang merupakan bagian (the parts) dari sebuah objek superior yang merupakan dasar (the whole) bagi beberapa objek inferior tersebut. Dimana hubungan tersebut dapat dinyatakan dengan rumus “has-a”. Asosiasi adalah hubungan antara sejumlah objek yang memiliki arti dimana objek-objek yang saling berhubungan tersebut tidak merupakan bagian dari objek yang lainnya. Hasil dari kegiatan struktur ini adalah class diagram. Class diagram menghasilkan ringkasan model problem-domain yang jelas dengan menggambarkan semua struktur hubungan statik antar kelas dan objek yang ada dalam model dari sistem yang berubah-ubah.
26
Gambar 2.4 Contoh Cluster 2.5.2.2.3 Behavior Mengacu pada Mathiassen et al. (2000) kegiatan behavior adalah kegiatan terakhir dalam analisa problem-domain yang bertujuan untuk memodelkan apa yang terjadi (perilaku dinamis) dalam problem-domain sistem sepanjang waktu. Tugas utama dalam kegiatan ini adalah: menggambarkan pola perilaku (behavioral pattern) dan atribut dari setiap kelas. Hasil dari kegiatan ini adalah statechart diagram yang dapat dilihat pada gambar dibawah ini:
/ account opened
/ account closed Open / amount deposited / amount withdrawn
Gambar 2.5 Contoh statechart diagram
27
Perilaku dari suatu objek di tentukan oleh urutan eventevent (event trace) yang harus dilewati oleh objek tertentu tersebut sepanjang waktu. Sebagai contoh: kelas “pelanggan” harus melalui event trace: account opened - amount depositedamount withdrawn - amount deposited -account closed sepanjang masa hidupnya. Tiga jenis notasi untuk behavioural 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
2.5.2.3 Application Domain Analysis Mengacu pada Mathiassen et al. (2000) application domain adalah organisasi yang mengatur, memonitor, atau mengendalikan problem domain. Analisis application-domain memfokuskan pada bagaimana target system akan digunakan dengan menentukan kebutuhan function dan antarmuka sistem. Untuk lebih jelasnya kegiatan-kegiatan yang dilakukan dalam analisis application-domain dapat dilihat pada tabel berikut ini.
28 Kegiatan Usage Function
Interface
Isi Bagaimana sistem berinteraksi dengan orang lain dan sistem lain dalam konteks Bagaimana kemampuan sistem dalam memproses informasi Kebutuhan antarmuka dari sistem target
Konsep Use case dan actor Function Interface, user interface dan sistem interface
Tabel 2.3 Kegiatan application domain analysis 2.5.2.3.1 Usage Mengacu pada Mathiassen et al. (2000) kegiatan usage merupakan kegiatan pertama dalam analisis application domain yang bertujuan untuk menentukan bagaimana aktor-aktor yang merupakan pengguna atau sistem lain berinteraksi dengan sistem yang dituju. Interaksi antara aktor dengan sistem tersebut dinyatakan dalam use case. Use case dapat dimulai oleh aktor atau oleh sistem target. Hasil dari analisis kegiatan usage ini adalah deskripsi lengkap dari semua use case dan aktor yang ada yang digambarkan dalam table aktor atau use case diagram.. 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. Mengacu pada Bennet et al. (2003) cara untuk mendokumentasikan use case adalah menggunakan template yang
29 terdiri dari beberapa bagian yaitu nama dari use case, precondition (hal yang harus benar sebelum usecase dapat berlangsung), post-condition (hal yang harus benar setelah usecase berlangsung), purpose (hal yang ingin dicapai oleh usecase), description (ringkasan dari dokumentasi usecase), normal course (kegiatan yang harus dilakukan oleh aktor sepanjang transaksi atau fungsi tertentu) dan alternative course (kegiatan yang harus dilakukan oleh aktor pada saat terjadi kesalahan). Bennett et al. juga mengungkapkan use case diagram mempunyai dua jenis hubungan (relationship) yaitu: extend dan include. Hubungan extend digunakan ketika ingin menunjukan bahwa sebuah use case menyediakan fungsi tambahan yang mungkin digunakan oleh use case lain. Sedangkan hubungan include digunakan ketika terdapat urutan behaviour yang sering kali digunakan oleh sejumlah use case dan ingin dihindari pengkopian deskripsi yang sama ke setiap use case yang akan menggunakan perilaku tersebut
30
Gambar 2.6 Contoh Use Case
Mengacu pada Bennet et al. (2003) sequence diagram membantu seorang analis kebutuhan mengidentifikasikan rincian dari kegiatan yang dibutuhkan untuk menjalankan fungsi dari sebuah use case. Tidak ada suatu sequence diagram yang benar untuk use case tertentu, melainkan ada sejumlah kemungkinan sequence diagram yang masing-masing diagram tersebut dapat lebih atau kurang memenuhi kebutuhan dari use case.
31
Gambar 2.7 Contoh Sequence Diagram
2.5.2.3.2 Function Mengacu pada Mathiassen et al. (2000) kegiatan function memfokuskan pada bagaimana cara sebuah sistem dapat membantu aktor dalam melaksanakan pekerjaan mereka. Function memiliki empat tipe yang berbeda yaitu: a.
Update, function ini disebabkan oleh event problemdomain dan menghasilkan perubahan dalam state atau keadaan dari model tersebut.
b.
Signal, function ini disebabkan oleh perubahan keadaan atau state dari model yang dapat menghasilkan reaksi pada konteks. Reaksi ini dapat berupa tampilan bagi aktor dalam application domain, atau intervensi langsung dalam problem domain.
32 c.
Read, function ini disebabkan oleh kebutuhan informasi dalam
pekerjaan
aktor
dan
mengakibatkan
sistem
menampilkan bagian yang berhubungan dengan informasi dalam model. d.
Compute,
function
ini
disebabkan
oleh
kebutuhan
informasi dalam pekerjaan aktor dan berisi perhitungan yang melibatkan informasi yang disediakan oleh aktor atau model, hasil dari function ini adalah tampilan dari hasil komputasi. Tujuan dari kegiatan function adalah untuk menentukan kemampuan sistem memproses informasi. Hasil dari kegiatan ini adalah sebuah daftar function-function yang merinci functionfunction yang kompleks. Daftar function harus lengkap, menyatakan kebutuhan kolektif dari pelanggan dan aktor dan harus konsisten dengan use case. 2.5.2.3.3 User Interface Mengacu pada Mathiassen et al. (2000) interface menghubungkan sistem dengan semua aktor yang berhubungan dalam konteks. Ada dua jenis dari interface antar muka yaitu: antar muka pengguna yang menghubungkan pengguna dengan sistem dan antar muka sistem yang menghubungkan sistem dengan sistem yang lainnya. Ada empat jenis pola dialog yang penting dalam menentukan interface pengguna yaitu: pola menu-selection yang
33 terdiri dari daftar pilihan-pilihan yang mungkin dalam interface pengguna; pola fill in yang merupakan pola klasik untuk entri data; pola command-language dimana user memasukkan dan memulai format perintah sendiri; pola direct manipulation dimana user memilih objek dan melaksanakan function atas objek dan melihat hasil dari interaksi mereka tersebut. Kegiatan analisis user interface ini berdasarkan pada hasil dari kegiatan analisis lainnya yaitu model problem domain, kebutuhan functional dan use case. Hasil dari kegiatan ini adalah sebuah deskprisi elemen-elemen interface pengguna dan interface sistem
yang
lengkap,
dimana
kelengkapan
menunjukkan
pemenuhan kebutuhan pengguna. Hasil ini harus dilengkapi dengan sebuah diagram navigasi yang menyediakan sebuah ringkasan dari elemen-elemen user interface dan perubahan antara elemen-elemen tersebut. 2.5.2.4 Architecture Design Keberhasilan suatu sistem ditentukan oleh kekuatan desain arsitekturalnya. Arsitektur membentuk sistem sesuai dengan fungsi sistem tersebut dan dengan memenuhi kriteria desain tertentu. Arsitektur juga berfungsi sebagai kerangka untuk kegiatan pengembangan yang selanjutnya. Untuk lebih jelasnya, kegiatan-kegiatan yang dilakukan selama tahap desain arsitektur dapat dilihat pada tabel berikut ini.
34 Kegiatan Kriteria
Isi
Kondisi
Kondisi dan kriteria untuk pendesaian
Criterion
Bagaiman sistem dibentuk menjadi komponenKomponen
komponen
Arsitektur komponen
Bagaimana proses sistem didistribusikan dan Proses
Arsitektur proses
dikoordinasi
Tabel 2.4 Kegiatan architecture design 2.5.2.4.1 Criteria Mengacu
pada
Mathiassen
et
al.
(2000)
dalam
menciptakan sebuah desain yang baik diperlukan pertimbangan mengenai kondisi-kondisi dari setiap proyek yang dapat mempengaruhi kegiatan desain yaitu: a.
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.
b.
Conceptual, yang terdiri dari pertimbangan: perjanjian kontrak,
rencana
untuk
pengembangan
lanjutan,
pembagian kerja antara pengembang c.
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.
35 Sebuah desain yang baik memiliki tiga ciri-ciri yaitu: 1.
Tidak memiliki kelemahan. Syarat ini menyebabkan adanya penekanan pada evaluasi dari kualitas berdasarkan review dan eksperimen dan membantu dalam menentukan prioritas dari kriteria yang akan mengatur dalam kegiatan pendesainan. Tabel dibawah ini adalah beberapa kriteria umum yang digunakan dalam kegiatan desain yang berorientasi objek:
Criterion Usable
Secure Efficient Correct Reliable Maintainabe Testable Flexible Comprehensible Reusable Portable Interoperable
Ukuran dari Kemampuan sistem untuk menyesuaikan diri dengan konteks, organisasi yagn berhubungan dengan peker jaan dan teknis Ukuran keamanan sistem dalam menghadapi akses yang tidak terotorisasi terhadap data dan fasilitas Eksploitasi ekonomis terhadap fasilitas platform teknis Pemenuhan dari kebutuhan Pemenuhan ketepatan yang dibutuhkan untuk melaksa nakan fungsi Biaya untuk menemukan dan memperbaiki kerusakan Biaya untuk memastikan bahwa sistem yang dibentuk dapat melaksanakan fungsi yang diinginkan Biaya untuk mengubah sistem yang dibentuk Usaha yang diperlukan untuk mendapatkan pemahaman terhadap sistem Kemungkinan untuk menggunakan bagian sistem pada sistem lain yang berhubungan Biaya untuk memindahkan sistem ke paltform teknis yang berbeda Biaya untuk menggabungkan sistem ke sistem yang lain
Tabel 2.5 Kriteria-kriteria umum 2.
Menyeimbangkan beberapa kriteria Konflik sering terjadi antar kriteria, oleh sebab itu untuk menentukan kriteria mana yang akan diutamakan dan bagaimana cara untuk menyeimbangkannya dengan
36 kriteria-kriteria yang lain bergantung pada situasi sistem tertentu. 3.
Usable, flexible, dan comprehensible Kriteria-kriteria ini bersifat universal dan digunakan pada hampir setiap proyek pengembangan sistem.
2.5.2.4.2 Component Architecture Mengacu pada Mathiassen et al. (2000) arsitektur komponen adalah sebuah struktur sistem yang terdiri dari komponen-komponen yang saling berhubungan. 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 tugas desain menjadi beberapa tugas yang lebih tidak kompleks. Beberapa pola umum dalam desain komponen arsitektur: a.
Arsitektur layered Merupakan bentuk yang paling umum dalam software. Contoh dari pola ini adalah model OSI yang sudah menjadi ISO untuk model jaringan. Sebuah arsitektur layered terdiri dari beberapa komponen yang dibentuk menjadi lapisan-lapisan dimana lapisan yang berada di atas bergantung ke pada lapisan yang ada di bawahnya.
37 Perubahan
yang
terjadi
pada
suatu
lapisan
akan
mempengaruhi lapisan di atasnya. b.
Arsitektur generic Pola ini digunakan untuk merinci sistem dasar yang terdiri dari antar muka, function, dan komponen-komponen model. Dimana komponen model terletak pada lapisan yang paling bawah, di ikuti dengan function sistem dan komponen interface diatasnya.
c.
Arsitektur client-server Pola ini awalnya dikembangkan untuk mengatasi masalah distribusi sistem di antara beberapa prosesor yang tersebar secara geografis. Komponen pada arsitektur ini adalah sebuah server dan beberapa client. Tanggung jawab daripada server adalah untuk menyediakan database dan resource yang dapat disebarkan kepada client melalui jaringan. Sementara client memiliki tanggung jawab untuk menyediakan antarmuka lokal untuk setiap penggunanya. Berikut adalah beberapa jenis distribusi dalam arsitektur
client-server dimana U adalah user interface, F adalah function, M adalah model.
38 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.6 Client-server architecture 2.5.2.4.3 Process Architecture Mengacu pada Mathiassen et al. (2000) arsitektur proses adalah struktur dari eksekusi sistem yang terdiri dari prosesproses yang saling tergantung. Untuk mengeksekusi atau menjalankan sebuah sistem dibutuhkan processor. Sedangkan external device adalah processor khusus yang tidak dapat menjalankan program. Arsitektur proses harus dapat memastikan bahwa sistem dapat dijalankan secara memuaskan dengan menggunakan processor yang telah tersedia. Objek-objek yang terlibat dalam sistem berorientasi objek yang berjalan dapat dibagi menjadi dua yaitu: Active objek yang telah diberikan sebuah proses dan aktif selama sistem dijalankan; dan komponen program, sebuah modul fisik dari kode program yang pasif selama eksekusi sistem kecuali pada saat dipanggil sebagai bagian dari eksekusi proses sampai eksekusi proses tersebut selesai dijalankan. Kegiatan arsitektur proses bermula dari komponen logik yang dihasilkan oleh kegiatan komponen dan bertujuan untuk menentukan
struktur
fisik
dari
sebuah
sistem
dengan:
mendistribusikan komponen-komponen program ke prosesor yang
39 akan
digunakan
untuk
eksekusi
sistem,
mengkoordinasi
pembagian sumber daya dengan active objek dan menghasilkan arsitektur yang tidak memiliki hambatan. 2.5.2.5 Component Design Tujuan dari kegiatan desain komponen ini adalah untuk menentukan implementasi kebutuhan dalam kerangka arsitektural. Kegiatan desain komponen bermula dari spesifikasi arsitektural dan kebutuhan sistem, sedangkan hasil dari kegiatan ini adalah spesifikasi dari komponen yang saling berhubungan. Berikut adalah beberapa kegiatan dari desain komponen: Kegiatan Model Component
Context
Konsep
Bagaimana suatu model digambarkan
Model component
sebagai kelas dalam sebuah sistem
and attribute
Function Component
Bagaimana suatu function diimplementasikan.
Function Component
Connecting Component
Bagaimana komponen-komponen dihubungkan.
& Operation Component and connection
Tabel 2.7 Kegiatan perancangan komponen 2.5.2.5.1 Model Component Mengacu pada Mathiassen et al. (2000) model analisis problem domain menggambarkan kebutuhan sistem. Kebutuhan sistem kemudian diimplementasikan dalam komponen model. Oleh karena itu dapat disimpulkan bahwa komponen model adalah bagian dari sistem yang mengimplementasikan model problem domain. Tujuan dari komponen model adalah untuk mengirimkan data sekarang dan historik ke function, interface dan
40 pengguna dan sistem yang lain. Konsep utama dalam desain komponen model adalah struktur. Hasil dari kegiatan komponen model adalah revisi dari class diagram dari kegiatan analisis. Kegiatan revisi biasanya terdiri dari kegiatan menambahkan kelas, atribut dan struktur baru yang mewakili event. 2.5.2.5.2 Function Component Mengacu pada Mathiassen et al. (2000) komponen function adalah bagian dari sistem yang mengimplementasikan kebutuhan fungsional. Tujuan dari komponen function adalah untuk memberikan akses bagi user interface dan komponen sistem lainnya ke model, oleh karena itu komponen function adalah penghubung antara model dan usage. Function
didesain
dan
diimplementasikan
dengan
menggunakan operasi dari kelas sistem. Operasi adalah proses yang dispesifikasikan dalam sebuah kelas dan dijalankan melalui objek dari kelas tersebut. Hasil utama dari kegiatan ini adalah class diagram untuk komponen function dan perpanjangan dari class diagram komponen model. Berikut adalah sub kegiatan dalam perancangan komponen function adalah: Sub kegiatan ini menghasilkan kumpulan operasi yang dapat mengimplemenatiskan fungsi sistem seperti yang ditentukan dalam analisis problem domain dan function list.
41 1.
Merancang function sebagai operation.
2.
Menelusuri
pola
yang
dapat
membantu
dalam
implementasi function sebagai operation. 3.
Spesifikasikan operasi yang kompleks.
2.5.2.5.3 Connecting Component Mengacu pada Mathiassen et al. (2000) Connecting Component untuk menggambarkan adanya hubungan antara komponen untuk menciptakan suatu rancangan yang fleksibel dan komprehensif serta mudah untuk dipahami. Fleksibel dan komprehensif adalah ukuran yang abstrak, sehingga harus dibuat suatu ukuran yang akan menghasilkan design criteria menjadi tidak abstrak. Ukurannya yaitu cohesion dan coupling. 1.
Coupling, yaitu sebuah ukuran untuk mengetahui seberapa dekatnya hubungan antara dua class atau component.
2.
Cohesion, yaitu sebuah ukuran untuk mengetahui seberapa baiknya hubungan antara sebuah class atau component yang digabungkan.
Adanya tiga bentuk dari connection , yakni : 1.
Aggregating kelas komponen lainnya
2.
Specializing kelas komponen public lainnya.
3.
Memanggil operation public dalam objek komponen yang lain.
