BAB 2 LANDASAN TEORI

BAB 2 LANDASAN TEORI

2.1

Pengertian Sistem Informasi Manajemen Menurut McLeod dn Schell yang diterjemahkan oleh Teguh, H. (2004, h259),

sistem informasi manajemen (SIM) didefinisikan sebagai suatu sistem berbasis komputer yang menyediakan informasi bagi beberapa pemakai dengan kebutuhan serupa. Menurut Laudon dan Laudon (2004, p16), MIS combines the theoretical work of computer science, management science, and operations research with a practical orientation toward developing system solutions to real-world problems and managing information technology resources. (SIM mengkombinasikan pekerjaan-pekerjaan teoritis dari ilmu pengetahuan komputer, manajemen dan penelitian operasi dengan orientasi praktis dalam rangka mengembangkan solusi-solusi yang mengarah pada masalahmasalah nyata dan mengatur sumber daya teknologi informasi. Menurut Turban et al. (2003, p33), management information system accessed, organized, summarized and displayed information for supporting routine decision making

in

the

functional

areas.

(Sistem

informasi

manajemen

mengakses,

mengorganisasi, merangkum dan menampilkan informasi untuk mendukung pengambilan keputusan yang sifatnya rutin dalam area-area fungsional. Berdasarkan definisi-definisi di atas, dapatlah ditarik kesimpulan bahwa sistem informasi manajemen adalah suatu sistem yang memiliki tujuan untuk mengakses, mengelola, menyimpulkan dan meperlihatkan informasi bagi para pemakainya dengan

kebutuhan serupa di dalam suatu organisasi, guna mendukung proses kegiatan pengambilan keputusan pada area fungsional. SIM menggabungkan pekerjaan teoritis dari ilmu komputer, ilmu manajemen dan penelitian operasional dengan orientasi praktis ke arah solusi pembangunan sistem yang berkaitan dengan masalah yang nyata dalam dunia serta mengelola sumber daya teknologi informasi.

2.2

Analisis dan Perancangan Sistem Informasi Manajemen

2.2.1

Pengertian dan Penjelasan Analisis Sistem Analisis Sistem adalah tahapan kedua dari System Development Life Cicyle

(SDLC) atau Daur Hidup Pengembangan Sistem. SDLC sendiri adalah suatu keseluruhan proses pengembangan sistem informasi secara bertahap. Tidak ada suatu pedoman baku akan tahapan yang ada di dalam SDLC, akan tetapi secara umum SDLC terdiri dari: (1) Perencanaan (2) Analisis (3) Perancangan (4) Implementasi, dan (5) Operasi. Menurut Boockholdt (2004, p119), analisis sistem adalah suatu proses meneliti suatu sistem informasi serta lingkungannya, dengan tujuan untuk mengidentifikasi kemungkinan perbaikan yang dapat dilakukan atas sistem tersebut. Analisis atas suatu sistem, mungkin dilakukan apabila perusahaan hendak: 1. Memecahkan masalah yang ada dalam suatu sistem. Contohnya adalah apabila suatu sistem yang ada tidak dapat lagi memenuhi tujuannya. 2. Memenuhi kebutuhan informasi baru atas sistem yang sebelumnya tidak ada. 3. Menerapkan teknologi baru dimana dengan penerapan teknologi baru ini diharapkan kegiatan perusahaan dapat lebih efektif dan efisien.

Tidak ada suatu bentuk yang baku akan apa saja yang terdapat dalam analisis sistem, akan tetapi Boockholdt membagi analisis sistem ini menjadi 2 tahapan, yaitu: 1. Preliminary survey atau survei pendahuluan adalah tahapan penelitian atas sistem berjalan. 2. Feasibility study atau studi kelayakan adalah tahapan di mana ditentukan tujuan dari sistem baru yang diusulkan. Hasil akhir feasibility study adalah suatu laporan kepada manajemen yang berisi rekomendasi tindakan yang perlu atas sistem berjalan. Studi kelayakan tidak dilakukan secara formal dalam penyusunan skripsi ini karena studi kelayakan tersebut akan berkaitan erat dengan tahapan selanjutnya dalam SDLC, yaitu implementasi sistem.

2.2.2

Pengertian dan Penjelasan Perancangan Sistem Boockholdt (2004, p172) mengatakan bahwa perancangan sistem merupakan

suatu proses pengembangan sistem baru berdasarkan rekomendasi yang dibuat selama analisis sistem. Boockholdt kembali membagi tahapan perancangan sistem ini menjadi 2 tahapan, yaitu: 1. Preliminary system design atau perancangan sistem awal, adalah tahapan pengembangan sistem secara konseptual. 2. Detailed specification atau deskripsi mendetil, adalah tahapan pendeskripsian sistem secara mendetil.

2.2.3

Pengertian Analisis dan Perancangan Sistem Informasi Manajemen Dari kedua bagian di atas, kita dapat menyimpulkan bahwa analisis dan

perancangan sistem informasi manajemen adalah proses yang memiliki 3 komponen, yaitu: 1. Meneliti suatu sistem informasi manajemen dan lingkungannya, 2. Mengembangkan sistem informasi manajemen tersebut, 3. Sehingga proses transformasi data-data keuangan perusahaan menjadi informasi keuangan, dapat berjalan dengan baik.

2.3

Sistem Informasi Manajemen Persediaan

2.3.1

Pengertian Persediaan Menurut Assauri (2004, h169) persediaan adalah ” suatu aktiva yang meliputi

barang-barang milik perusahaan dengan maksud untuk dijual dalam suatu periode usaha yang normal, atau persediaan barang-barang yang masih dalam pengerjaan / proses produksi, ataupun persediaan barang baku yang menunggu penggunaannya dalam proses produksi.”. Menurut Standar Akuntansi Keuangan (2004): Persediaan adalah ” aktiva: tersedia untuk dijual dalam kegiatan usaha normal; dalam proses produksi dan atau dalam perjalanan; atau dalam bentuk bahan atau perlengkapan (suppliers) untuk digunakan dalam proses produksi atau pemberian jasa. ... Persediaan meliputi barang yang dibeli dan disimpan untuk dijual kembali ... Persediaan juga mencakup barang jadi yang telah diproduksi, atau barang dalam penyelesaian yang sedang diproduksi perusahaan, dan

termasuk bahan serta perlengkapan yang digunakan dalam proses produksi.” (SAK No. 14.1). Jadi dapat ditarik kesimpulan, persediaan adalah aktiva perusahaan yang meliputi barang jadi yang tersedia untuk dijual kembali, barang dalam penyelesaian yang sedang di produksi dan bahan serta perlengkapan yang digunakan dalam proses produksi.

2.3.2

Jenis - Jenis Persediaan Mengacu pada Assauri (2004) persediaan yang terdapat dalam perusahaan dapat

dibedakan menurut beberapa cara, dilihat dari fungsinya, dan dilihat dari jenis dan posisi barang dalam urutan pengerjaan produk.. 1. Dilihat dari fungsinya 1)

Batch Stok atau Lot Inventory Adalah persediaan yang muncul karena pembelian atau pembuatan barang dalam jumlah yang lebih besar daripada jumlah yang dibutuhkan pada suatu waktu tertentu untuk mendapatkan potongan harga pembelian, biaya pengangkutan yang lebih murah per unitnya dan penghematan dalam biayabiaya lainnya yang mungkin diperoleh.

2)

Fluctuation Stock Adalah persediaan yang diadakan untuk menghadapi fluktuasi permintaan konsumen yang tidak dapat diramalkan. Jadi apabila terdapat fluktuasi permintaan yang sangat besar maka persediaan (fluktuation stock) yang dibutuhkan sangat besar pula untuk menjaga kemungkinan naik turunnya permintaan tersebut.

3)

Anticipation Stock Adalah persediaan yang diadakan untuk menghadapi fluktuasi permintaan yang dapat diramalkan yaitu berdasarkan pola musiman yang terdapat dalam satu tahun dan untuk menghadapi penggunaan atau penjualan permintaan yang meningkat. Disamping itu anticipation stock dimaksudkan pula untuk menjaga kemungkinan sukarnya diperoleh bahan-bahan sehingga tidak mengganggu jalannya produksi atau menghindari kemacetan produksi.

2. Dilihat dari jenis dan posisi produk dalam urutan pengerjaan produk: 1)

Persediaan bahan baku (Raw Materials Stock) Adalah persediaan barang-barang berwujud yang digunakan dalam proses produksi yang dapat diperoleh dari sumber-sumber alam, dibeli dari supplier atau perusahaan yang menghasilkan bahan baku bagi perusahaan pabrik yang menggunakannya.

2)

Persediaan bagian produk atau parts yang dibeli (purchase parts / component stock) Adalah persediaan barang-barang yang terdiri dari parts yang diterima dari perusahaan lain, yang dapat secara langsung di-assembling dengan sukucadang lain, tanpa melalui proses produksi sebelumnya. Jadi bentuk barang yang merupakan parts ini tidak mengalami perubahan dalam operasi.

3)

Persediaan bahan-bahan pembantu (supplier stock)

atau

barang-barang

perlengkapan

Adalah persediaan barang-barang atau bahan-bahan yang diperlukan dalam proses produksi untuk membantu berhasilnya produksi atau yang dipergunakan dalam bekerjanya suatu perusahaan, tetapi tidak merupakan bagian atau komponen dari barang jadi. 4)

Persediaan barang setengah jadi atau barang dalam proses ( work in process / progress stock) Adalah merupakan barang-barang yang belum berupa barang jadi, akan tetapi masih merupakan proses lebih lanjut lagi di pabrik sehingga menjadi barang jadi yang sudah siap untuk dijual kepada konsumen atau pelanggan.

5)

Persediaan barang jadi (finished goods stock) Adalah persediaan barang-barang yang telah selesai diproses atau diolah dalam pabrik dan siap untuk dijual kepada pelanggan atau perusahaan lain.

2.3.3

Dokumen Yang Digunakan Berhubungan dengan Persediaan Menurut Assauri (2004) pencatatan dalam pengawasan persediaan adalah semua

pencatatan atau pembukuan mengenai penerimaan, persediaan di gudang dan pengeluaran bahan baku dan bahan-bahan lainnya serta hasil produksi dalam suatu perusahaan. Pencatatan-pencatatan tersebut diperlukan untuk menjamin bahan-bahan atau barangbarang dipergunakan secara efisien dan perusahaan dapat mengikuti perkembangan persediaannya dengan baik. Menurut Assauri (2004) pada dasarnya terdapat lima catatan yang paling penting atau utama dalam sistem pengawasan persediaan:

•

Permintaan Untuk Dibeli (purchase requisition) Dokumen permintaan pembelian bahan-bahan atau barang-barang dalam jumlah

tertentu yang ditujukan kepada bagian pembelian. Permintaan tersebut dia adakan dengan tujuan untuk menjamin tersedianya persediaan yang cukup dari bahan-bahan atau barangbarang tersebut atau mengisi kembali persediaan bila persediaan bahan-bahan tertentu yang ada akan mendekati titik yang terandah atau minimum yang telah ditentukan lebih dahulu. •

Laporan Penerimaan (receiving report) Dokumen yang memberikan informasi mengenai penerimaan atas barang yang telah dipesan.

•

Catatan Persediaan (balance of stores record) Merupakan istilah lain dari: perpetual inventory card, stock record card, stored ledger sheet, balance of stores form, stores balance sheet, dan material ledger sheet. Informasi yang terdapat dalam “balance of stores card” berbeda-beda tergantung

dari perusahaan pabrik yang menggunakannya. Akan tetapi data-data yang biasanya terdapat dalam daftar ini adalah: a. Gambaran atau deskripsi lengkap dari bahan-bahan tersebut b. Jumlah dari bahan-bahan yang tersedia di gudang, yang dipesan dan yang dialokasikan untuk produksi c. Jumlah bahan-bahan yang alan atau harus dibeli bila waktunya telah tiba untuk mengadakan pemesanan baru. d. Harga bahan-bahan itu per unit

e. Jumlah yang dipakai selama suatu periode atau jangka waktu tertentu f. Nilai dari persediaan yang ada •

Daftar Permintaan Bahan (material requisition form) Formulir yang dibuat oleh petugas gudang untuk dipergunakan oleh bagian pembelian dalam mengadakan pemesanan bahan-bahan yang perlu dibeli kembali.

•

Perkiraan Pengawasan (control accounting) Catatan yang digunakan oleh Bagian Akuntansi untuk mengawasi setiap pencatatan mutasi persediaan yang dilakukan oleh bagian gudang. Semua pembelian akan didebit dan semua pemakaian akan dikredit dalam perkiraan ini. Saldo perkiraan pengawasan harus sama dengan saldo yang terdapat pada “perpetual

inventory

cards.”

Tidak

sesuainya

saldo

antara

keduanya

mengharuskan diadakannya penyelidikan selanjutnya.

2.3.4

Metode Pencatatan Persediaan Mengacu pada Dedhy Sulistiawan dan Yie Ke Feliana (2006) terdapat dua

macam metode pencatatan persediaan: 1. Metode pencatatan periodik Pada metode ini, nilai persediaan ditentukan secara periodic dalam kurun waktu tertentu. Kurun waktu ini bisa 1 tahun atau hanya 1 bulan. 2. Metode Perpetual Pada metode ini, nilai persediaan selalu diperbarui, sehingga perusahaan bisa mengetahui nilai persediaan dan HPP setiap saat.

2.3.5

Metode Penilaian Persediaan Mengacu pada Assauri (2004) ada beberapa cara yang dapat digunakan untuk

menilai suatu persediaan, diantaranya dengan: 1. Cara First-In, First-Out (FIFO Method) Adalah cara penilaian persediaan yang berdasarkan atas asumsi bahwa harga barang yang sudah terjual dinilai menurut harga pembelian barang yang terdahulu masuk. Dengan demikian persediaan akhir dinilai menurut harga pembelian barang yang akhir masuk. 2. Cara Rata-rata tertimbang (Weighted Average Method) Adalah cara penilaian persediaan yang berdasarkan atas harga rata-0rata dimana harga tersebut dipengaruhi oleh jumlah barang yang diperoleh pada masingmasing harganya. 3. Cara Last-In, First-Out (LIFO Method) Adalah cara penilaian persediaan berdasarkan atas asumsi bahwa barang yang telah terjual dinilai menurut harga pembelian barang yang terakhir masuk. Sehingga persediaan yang masih ada atua stock dinilai berdasarkan harga pembelian barang yang terdahulu.

2.3.6

Pengawasan Persediaan Menurut Assauri (2004, h176) ”...suatu sistem pengawasan persediaan harus

memenuhi persyaratan-persyaratan sebagai berikut: •

Terdapatnya gudang yang cukup luas dan teratur dengan pengaturan tempat bahan atau barang yang tetap dan identifikasi bahan atau barang tertentu.

•

Sentralisasi kekuasaan dan tanggung jawab pada satu orang yang dapat di percaya, terutama penjaga gudang.

•

Suatu sistem pencatatan dan pemeriksaan atas penerimaan bahan atau barang.

•

Pengawasan mutlak atas pengeluaran bahan atau barang.

•

Pencatatan yang cukup teliti yang mneunjukkan jumlah yang dipesan, yang dibagikan atau dikeluarkan dan yang tersedia didalam gudang.

•

Pemeriksaan fisik bahan atau barang yang ada dalam persediaan secara langsung.

•

Perencanan untuk menggantikan barang-barang yang telah dikeluarkan, barangbarang yang telah lama dalam gudang, dan barang-barang yang sudah usang dan ketinggalan zaman.

•

2.3.7

Pengecekan untuk menjamin dapat efektifnya kegiatan rutin. ”.

Metode Pengendalian Persediaan

2.3.7.1 Economic Order Quantity Menurut Weston dan Brigham (1990, p 509), EOQ merupakan suatu rumus untuk menentukan kuantitas pesanan yang akan meminimumkan biaya persediaan total. Perhitungan EOQ menggunakan rumus : EOQ = √ 2 F S CP Dimana : EOQ = jumlah optimal pemesanan barang F

= biaya tetap melakukan pemesanan dan menerima barang yang masuk.

S

= penjualan tahunan dalam unit.

C

= biaya penyimpanan yang dinyatakan sebagai suatu persentase atas nilai persediaan.

P

= harga beli per unit persediaan yang harus dibayar oleh perusahaan.

2.3.7.2 Reorder Point Menurut Render dan Heizer (2001, p324), ROP adalah saat persediaan mencapai sebelum nol, perusahaan memesan lagi dan dengan seketika barang yang dipesan diterima. Perhitungan ROP menggunakan rumus : ROP = d x L Dimana : ROP = titik pemesanan ulang d

= permintaan per hari

L

= lead time, waktu pengiriman

2.3.7.3 Safety Stock Menurut Weston dan Brigham (1990, p 512), safety stock adalah persediaan tambahan yang dimiliki untuk berjaga-jaga terhadap perubahan tingkat penjualan atau keterlambatan produksi/pengiriman.

2.3.8

Biaya – biaya Persediaan Mengacu pada Freddy Rangkuti (2004), Perhitungan total biaya persediaan secara

keseluruhan dapat dipengaruhi oleh faktor – faktor pembentuk biaya dari persediaan seperti : 1. Biaya penyimpanan ( holding cost atau carrying cost )

Biaya yang bervariasi secara langsung dengan kuantitas persediaan. Biaya penyimpanan per periode akan semakin besar apabila kuantitas bahan yang dipesan semakin banyak atau rata – rata persediaan semakin tinggi. Yang termasuk adalah biaya fasilitas penyimpanan, biaya modal, biaya keusangan, biaya penghitungan fisik, biaya asuransi persediaan, biaya pajak persediaan, biaya pencurian, kerusakan atau pengrampokan, dan biaya penanganan dan sebagainya. 2. Biaya pemesanan atau pembelian ( ordering cost atau procurement costs ). Biaya – biaya ini meliputi : pemrosesan pesanan dan biaya ekspedisi, upah, biaya telepon, pengeluaran surat menyurat, biaya pengepakan dan penimbangan, biaya pemeriksaan ( inspeksi ) penerimaan, biaya pengiriman ke gudang, biaya utang lancar dan sebagainya. 3. Biaya penyiapan ( manufacturing ) atau set up cost Hal ini terjadi apabila bahan – bahan tidak dibeli tetapi diproduksi sendiri dalam pabrik perusahaan, biaya – biaya tersebut terdiri dari : biaya mesin menganggur, biaya persiapan tenaga kerja langsung, biaya penjadwalan, dan biaya ekspedisi dan sebagainya. 4. Biaya kehabisan atau kekurangan bahan ( shortage costs ) Biaya yang timbul apabila persediaan tidak mencukupi adanya permintaan bahan. Biaya – biaya yang termasuk yaitu : kehilangan penjualan, kehilangan pelanggan, biaya pemesanan khusus, biaya ekspedisi, selisih harga, terganggunya operasi, dan tambahan pengeluaran kegiatan manajerial dan sebagainya.

2.4

Pengendalian Internal Sebuah sistem informasi manajemen yang baik, sebaiknya merupakan suatu sistem yang relatif tertutup. Pengendalian internal merupakan komponen yang memampukan suatu sistem menjadi sistem yang relatif tertutup.

2.4.1

Pengertian Pengendalian Internal Menurut Boockholdt (2004, p397), pengendalian internal adalah suatu proses

yang dipengaruhi oleh dewan komisaris, manajemen, dan pihak-pihak lainnya, yang didesain untuk menyediakan jaminan memadai (reasonable assurance) atas: 1. Efektivitas dan efisiensi kegiatan operasi. 2. Reliabilitas laporan keuangan. 3. Ketaatan atas hukum dan peraturan serta kebijakan manajemen. Menurut Romney and Steinbart (2004, p195) 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.” Menurut Jones dan Rama (2004, p15) 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 thef.”

2.4.2

Komponen Pengendalian Internal Pengendalian internal, memiliki 5 komponen, yaitu:

1.

Lingkungan pengendalian (control environment).

Lingkungan pengendalian

pengendalian internal

lainnya

menjadi karena

dasar

dari

lingkungan

seluruh

komponen

pengendalian

akan

memberikan suatu gambaran bagaimana suatu organisasi atau perusahaan melakukan tindakan-tindakan tertentu dalam mencapai tujuannya Lingkungan pengendalian ini terdari dari 7 faktor, yaitu: •

Integritas dan etika. Suatu pengendalian internal tidak akan berjalan dengan baik tanpa didukung oleh integritas dari pihak manajemen perusahaan (khususnya Manajemen Puncak) karena pihak Manajemen Puncak-lah yang membuat, menjalankan serta mengawasi pengendalian internal. Integritas dan etika ini merupakan hasil dari culture atau budaya perusahaan, dimana budaya ini dibentuk oleh tindakan atau pilihan-pilihan manajemen secara keseluruhan.

•

Komitmen akan kompetensi (commitment to competence). Kompetensi memiliki arti bahwa karyawan memiliki pengetahuan serta keahlian yang cukup sehingga mereka dapat menjalankan tugasnya dengan baik. Apabila manajemen memiliki komitmen akan kompetensi, maka manajemen akan secara berkala meningkatkan kompetensi karyawan secara keseluruhan, yang pada akhirnya akan dapat mengurangi kesalahankesalahan yang mungkin timbul (dan pada akhirnya meningkatkan keefektifan pengendalian internal).

•

Partisipasi Dewan Komisaris dan Komite Audit. Apabila Komite Audit secara aktif turut memantau kebijakan serta praktik manajemen (sebagai watchdog), maka pengendalian internal akan lebih dapat membantu pencapaian tujuan organisasi.

•

Filosofi manajemen dan gaya operasi. Apabila Manajemen Puncak menerapkan gaya operasi yang terusmenerus menekan manajemen di bawahnya agar mampu mencapai target yang cukup sulit dicapai, maka pengendalian internal perusahaan perlu diperketat. Karena seiring dengan hal tersebut, ada kemungkinan Manajemen Menengah dan Bawah berupaya melakukan tindakan-tindakan menyimpang yang membuat kinerja mereka terlihat lebih baik.

•

Struktur organisasi. Struktur organisasi menjadi kerangka keseluruhan bagi kegiatan perencanaan, pelaksanaan, pengendalian, serta pemantauan yang dilakukan manajemen.

Struktur

organisasi

yang

baik

akan

mempermudah

pengendalian internal. •

Pembagian otoritas dan tanggung jawab. Pembagian otoritas dan tanggung jawab membuat setiap bagian dalam perusahaan bertanggung jawab atas tindakan-tindakan tertentu yang menjadi otoritasnya. Tanpa pembagian otoritas dan tanggung jawab ini, setiap bagian tidak

dapat

dituntut

pertanggungjawabannya

yang

pada

akhirnya

memperburuk pengendalian internal serta pencapaian tujuan perusahaan.

•

Kebijakan dan praktik sumber daya manusia. Departemen Sumber Daya Manusia (SDM) dapat turut membantu tercapainya suatu pengendalian internal yang baik, apabila mereka merekrut karyawan

yang

kompeten,

memberikan

pelatihan,

memperlakukan

karyawan dengan sepatutnya, serta memberikan kompensasi yang layak. Selain itu, Departemen SDM ini juga dapat mempengaruhi pengendalian internal dengan kebijakan rotasi dan pemberian liburan bagi para karyawan. 2.

Pengendalian resiko (risk assessment). Pengendalian resiko adalah suatu proses yang dilakukan manajemen dalam mengidentifikasi dan menganalisis resiko-resiko yang ada, yang dapat menghalangi perusahaan dalam mencapai tujuannya (Boockholdt, 1999, p403). Dengan pengendalian resiko ini, maka pihak manajemen akan dapat mengambil langkah-langkah yang perlu untuk meminimalkan resiko tersebut dan membuat pengendalian internal lebih baik.

3.

Aktivitas pengendalian (control activities). Aktivitas pengendalian adalah kebijakan dan prosedur yang dipilih manajemen untuk menghasilkan jaminan memadai sehingga tujuan manajemen dapat dicapai. Aktivitas pengendalian ini umumnya digolongkan menjadi empat bagian, yaitu: •

Prosedur otorisasi transaksi; yang dapat digolongkan lagi menjadi 2, yaitu: - Prosedur otorisasi umum. - Prosedur otorisasi khusus.

•

Keamanan aset dan catatan-catatan; yang kembali dapat dibagi menjadi: - Keamanan fisik. - Penetapan tanggung jawab.

•

Pemisahan tugas (segregation of duties). Yang menjadi pokok permasalahan dalam pembagian tugas ini adalah adanya pemisahan tugas antara pihak-pihak yang melakukan otorisasi, pencatatan, dan penyimpanan secara fisik atas aset perusahaan. Dengan adanya pemisahan antara ketiga fungsi tersebut, pengendalian internal akan menjadi jauh lebih baik.

•

Dokumen-dokumen dan catatan-catatan yang mencukupi. Dokumen dan catatan yang mencukupi, akan membuat pengendalian internal menjadi lebih baik karena dari dokumen dan catatan tersebut dapat diperoleh informasi yang lengkap atas suatu peristiwa ekonomi.

4.

Informasi dan komunikasi (information and communication). Sebagaimana telah dibahas, informasi diperlukan dalam pengambilan keputusan pada seluruh tingkatan organisasi; dan informasi ini tidak terlepas dari komunikasi, yaitu proses pertukaran informasi itu sendiri. Dengan adanya informasi dan komunikasi ini, Manajemen dapat mengambil keputusan yang penting bagi perusahaan, para pemegang saham (stockholder) ataupun pemilik kepentingan (stakeholder) dapat mengetahui kinerja perusahaan, dan lain sebagainya. Dengan demikian, pengendalian internal akan lebih baik karena adanya pihak-pihak “pengawas” tersebut.

5.

Pengawasan (monitoring). Pengawasan adalah suatu proses penilaian atas kualitas kinerja pengendalian internal seiring dengan berjalannya waktu. Pengawasan ini dapat dijalankan dengan 2 cara, yaitu: •

Aktivitas pengawasan yang berkelanjutan (ongoing monitoring activities).

•

Evaluasi yang terpisah (separate evaluations); misalnya melalui: - Auditor independen. - Auditor internal.

2.5

Metode Analisis dan Desain Berorientasi Obyek

2.5.1

Pengertian Object Object merupakan dasar dalam object oriented analysis and design (00A&D).

Menurut Mathiassen L., et al (2000, p4) object adalah “ an entity with identity, state, and behaviour.” Setiap object tidak digambarkan secara sendiri - sendiri, melainkan istilah kelas digunakan untuk menggambarkan kumpulan-kumpulan object – object.

2.5.2 Object-Oriented Menurut Mathiassen L., et al (2000, pp5-6), keuntungan dari object-oriented adalah : •

Merupakan konsep umum yang dapat digunakan untuk memodelkan hampir semua fenomena yang ada di dunia dengan menggunakan bahasa alami. o Noun menjadi object atau class.

o Verb menjadi behaviour. o Adjective menjadi attributes. •

Menyediakan informasi yang jelas mengenai context dari sistem.

•

Mengurangi biaya maintenance atau development.

2.5.3

Object-Oriented Analysis and Design (00A&D) Menurut Mathiassen L., et al (2000, pp14-15), terdapat 4 aktivitas utama dalam

OOA&D, yaitu Problem Domain Analysis, Application Domain Analysis, Architectural Design, dan Component Design.

System Choice System Definition

Proble m domain

Requiremen ts

Applicatio n domain

Compon ent Model

Specifications for

Specifications for

Architectura l

Gambar 2.1 Aktivitas utama dalam OOA&D ( Sumber : Mathiassen L. Et al. , 2000, p15)

2.5.4

Rich Picture Menurut Mathiassen L. Et al. (2000, p26), 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. Rich picture difokuskan pada aspek-aspek penting dari sisem tersebut, yang ditentukan sendiri oleh pengembang sistem dengan mengunjungi perusahaan untuk melihat bagaimana perusahaan beroperasi, berbicara dengan banyak orang untuk mengetahui apa yang harus terjadi atau seharusnya tejadi, dan mungkin melakukan beberapa wawancara formal.

2.5.5

System Definition Menurut Mathiassen et al. (2000,p24), “System definition is a concise description

of a computerized system expressed in natural language.” Pengertian ini menjelaskan bahwa system definition merupakan gambaran menyeluruh mengenai sebuah sistem komputer yang dinyatakan kedalam sebuah bahasa umum. Aktivitas yang dilakukan dalam system definition pertama kali adalah menggambarkan situasi dari sistem yang ada, yaitu mengenai proses, struktur, dan masalah yang berhubungan dengan pengembangan sistem dalam perusahaan. Setelah itu, ciptakan ide-ide baru untuk pengembangan. Dan, gambarkan kemungkinan-kemungkinan yang terjadi dari rencana tersebut untuk dapat memilih sebuah rencana akhir.

2.5.6

Kriteria FACTOR Kriteria FACTOR (Mathiassen et al., 2000) adalah sebagai berikut:

Functionality Application Domain Conditions Technology Object Responsibility

Fungsi dari suatu sistem yang mendukung tugas-tugas dalam application domain. Bagian dalam sebuah organisasi yang diadministrasikan, dimonitor, atau dikontrol dalam problem domain. Kondisi dimana sistem akan dikembangkan dan digunakan. Teknologi yang digunakan baik untuk mengembangkan sistem maupun teknologi untuk menjalankan sistem tersebut. Object utama dalam problem domain. Tanggung jawab sistem secara keseluruhan sesuai dengan konteks. Tabel 2.1. Kriteria FACTOR

Kriteria FACTOR dapat digunakan dalam dua cara, user dapat menggunakannya untuk mendukung pengembangan sistem, mempertimbangkan dengan baik bagaimana ke enam

elemen

tersebut

harus

diformulasikan,

atau

user

dapat

memulai

mengidentifikasikan dengan merinci sistemnya dan kemudian menggunakan kriteria untuk melihat bagaimana, definisi sistem memuaskan ke enam FACTOR tadi.

2.5.7

Problem Domain Analysis Menurut Mathiassen L. Et al. (2000, p45) problem domain adalah bagian dari

konteks yang diatur, dimonitor, atau dikendalikan oleh sistem. Analisis problem-domain memfokuskan pada informasi apa yang harus ditangani oleh system dan menghasilkan sebuah model yang merupakan gambaran dari kelas-kelas, objek-objek, struktur dan perilaku (behaviour) yang ada dalam problem domain. Untuk lebih jelasnya kegiatankegiatan yang dilakukan dalam analisis problem-domain dapat dilihat pada tabel berikut ini.

Kegiatan Class Structure Behaviour

Isi Konsep Object dan event yang merupakan Class, object dan event bagian dari problem domain Bagaimana class dan object Generalisasi, agregasi, asosiasi, saling berkaitan dan cluster Property dinamik yang dimiliki Event trace, behavioural pattern, dan attribute object Tabel 2.2. Kegiatan problem-domain analysis ( Sumber : Mathiassen L. Et al. , 2000, p48)

2.5.7.1 Class Menurut Mathiassen L. Et al. (2000, p4) , class adalah “a description of collection of objects sharing structure, behavioural pattern, and attributes.”. Menurut Mathiassen Et al. (2000, pp49-50) 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 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 dilakukan oleh satu atau lebih objek bertujuan untuk membedakan tiap-tiap kelas dalam problem domain Kegiatan kelas akan menghasilkan table event. Dimensi horizontal dari table event berisi kelas-kelas yang terpilih, sementara dimensi vertical berisi event-event terpilih dan tanda cek digunakan untuk mengindikasikan objek-objek dari kelas yang berhubungan dalam event tertentu. Untuk lebih jelasnya, table event dapat dilihat pada tabel berikut ini. Event Reserved

Kelas Customer V

Assistant V

Apprentice

Appointment V

Plan V

Cancelled Treated Employed Resigned Graduated Agreed

V V

V

V V

V V

V V V V V Tabel 2.3. Contoh event table ( Sumber : Mathiassen L. Et al. , 2000, p50)

V

2.5.7.2 Structure Menurut Mathiassen Et al. (2000, pp69-70), tujuannya adalah untuk mendeskripsikan hubungan struktural antara class dan object. Sumber dari tahap ini adalah event table yang dihasilkan dari tahap sebelumnya, sedangkan hasil akhirnya adalah membuat Class Diagram, yaitu diagram yang menyediakan gambaran ikhtisar problem domain yang bertalian secara logis dengan menggambarkan seluruh hubungan struktural antara classes dan objects di dalam model. Menurut Mathiassen Et al. (2000, pp72-77), terdapat dua tipe struktur dalam Object-Oriented, yaitu : •

Class Structure, mengekspresikan hubugan konseptual yang statis antar class. Hubungan statis ini tidak akan berubah, kecuali terjadi perubahan pada deskripsinya. Class structure dibagi menjadi dua macam yaitu : o Generalization Strucuture, merupakan hubungan antara dua atau lebih subclass dengan satu atau lebih superclass Mathiassen Et al. (2000, p72). Sebuah class yang umum (superclass) mendeskripsikan property umum kepada group dari special class (subclass). Atau dengan kata lain, terjadi penurunan attributes dan behaviour dari superclass, tetapi subclass juga diperkenankan untuk memiliki attributes dan behaviour

tambahan. Secara ilmu bahasa, generalization structure diekspresikan dengan formula “is a”. passenger car

taxi

private car

Gambar 2.2 Generalization Strucuture ( Sumber : Mathiassen L. Et al. , 2000, p73)

o Cluster,

merupakan

kumpulan

dari

class

yang

berhubungan

(Mathiassen L. Et al. (2000, p74). Cluster digambarkan dengan notasi file folder yang melingkupi class-class yang saling berhubungan didalamnya. Class-class dalam satu cluster biasanya memiliki hubungan

antara

generalization

atau

aggregation.

Sedangkan

hubungan class dengan cluster yang berbeda biasanya berupa association structure.

generalization

Gambar 2.3 Notasi Class Structure ( Sumber : Mathiassen L. Et al. , 2000, p337) •

Object structure, mengekspresikan hubungan dinamis dan konkret antar object. Hubungan ini dapat berubah secara dinamis tanpa mempengaruhi perubahan

deskripsinya.

Biasanya

terdapat

multiplicity

yang

menspesifikasikan jumlah dari object yang berelasi. Multiplicity dapat berubah string of numbers dan penyebaran interval dengan koma, seperti “0,3,7,9,.. 13,19,*”,”*” disebut many ; dan 0..*”. Ada 2 macam object structure yaitu : o Aggregation structure, mendefinisikan hubungan antara dua atau lebih object. Sebuah superior object (whole) memiliki beberapa object (parts)

(Mathiassen L. Et al. (2000, p76). Secara ilmu bahasa,

aggregation structure diekspresikan dengan formulasi “has a”, “a part-of”, atau “is-owned-by”. Terdapat 3 buah tipe aggregation structure (Mathiassen L. Et al. (2000, p79), yaitu : ƒ

Whole-part, dimana whole merupakan jumlah dari parts, sehingga jika salah satu parts dihilangkan maka secara tidak langsung telah mengubah whole.

ƒ

Container-content, dimana whole adalah kontainer (tempat tampung) dari parts-nya sehingga bila terjadi penambahan atau pengurangan terhadap isinya (parts), tidak akan mengubah pengertian dari whole-nya.

ƒ

dimana

Union-member, union/gabungan (parts),

yang

sehingga

jika

whole

terorganisir terdapat

dari

merupakan anggotanya

penambahan

atau

pengurangan anggota , tidak akan mengubah union-nya. Terdapat batasan jumlah anggota terendah, karena tidak mungkin sebuah union tanpa anggota.

o Association structure, mendefiniskan hubungan antar dua atau lebih object, tetapi berbeda dengan aggregation (Mathiassen L. Et al. (2000, p76). Hubungan antar class-class pada aggregation mempunyai pertalian yang kuat sedangakn pada association tidak kuat. Secara ilmu bahasa, association structure diekspresikan dengan formula “knows” atau “associated-with”.

*

-a..b

*

-a..b

*

-c..d

*

-c..d

Ket : a-d adalah multiplicity Gambar 2.4 Notasi object structure ( Sumber : Mathiassen L. Et al. , 2000, p337)

car

person 0..*

1..*

Gambar 2.5 Association Structure ( Sumber : Mathiassen L. Et al. , 2000, p77)

2.5.7.3.Behaviour Menurut Mathiassen Et al. (2000, pp89-93) kegiatan behaviour adalah kegiatan terakhir dalam analisa problem-domain yang bertujuan untuk memodelkan apa yang terjadi (perilaku dinamis) dalam problem-domain system sepanjang waktu. Tugas utama dalam kegiatan ini adalah : menggambarkan pola perilaku (behavioral

pattern) dan attribute dari setiap kelas. Hasil dari kegiatan ini adalah statechart diagram yang dapat dilihat pada gambar dibawah ini :

Gambar 2.6 Contoh statechart diagram ( Sumber : Mathiassen L. Et al. , 2000, p90) Perilaku dari suatu objek ditentukan oleh urutan event-event (event trace) yang harus dilewati oleh objek tertentu tersebut sepanjang waktu. Sebagai contoh : kelas “pelanggan” harus melalui event trace : account opened – amount deposited – amount withdrawen – amount deposited – account closed sepanjang hidupnya. Tiga jenis notasi untuk behavioral 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.8

Application Domain Analysis Menurut pada Mathiassen Et al. (2000, pp115-117) application domain adalah

organisasi yang mengatur, memonitor, atau mengendalikan problem domain. Analisis application-domain memfokuskan pada bagaimana target sistem 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. 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 system interface Table 2.4 kegiatan analisis application domain ( Sumber : Mathiassen L. Et al. , 2000, p117)

2.5.8.1 Usage Menurut Mathiassen Et al. (2000,p119) 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. Menurut Fowler, Martin (2005, p141), use case adalah teknik untuk merekam persyaratan fungsional sebuah sistem.. Use case mendeskripsikan interaksi tipikal antara para pengguna sistem dengan sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana sistem tersebut digunakan. Menurut Mathiassen Et al. (2000, p120) 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 actor atau use case diagram. Cara untuk mengidentifikasi aktor adalah dengan mengetahui alasan aktor menggunakan sistem. Masing-masing aktor memiliki alasan yang berbeda untuk menggunakan sistem. Cara lainnya yaitu dengan melihat peran dari actor seperti yang

dinyatakan oleh use case dimana actor tersebut terlibat. Masing-masing aktor memiliki peran yang berbeda-beda. Setiap aktor akan berkorespondensi dengan kelas dalam problem domin yang berbeda karena mereka memiliki pola behavioural objek yang berbeda-beda. Actor dapat digambarkan dalam spesifikasi actor yang memiliki 3 bagian yaitu tujuan, karakteristik, dan contoh dari actor tersebut. Tujuan merupakan peran dari actor dalam sistem target. Sementara karakteristik menggambarkan aspek-aspek yang penting dari actor. 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. Menurut Bennet Et al. (2003) cara untuk mendokumentasikan use case adalah menggunakan template yang terdiri dari beberapa bagian yaitu nama dari use case, pre-condition (hal yang harus benar sebelum use case dapat berlangsung), postcondition (hal yang harus benar setelah usecase berlangsung), purpose (hal yang ingin dicapai oleh use case), description (ringkasan dari dokumentasi use case), normal course (kegiatan yang harus dilakukan oleh actor sepanjang transaksi atau fungsi tertentu), dan alternative course (kegiatan yang harus dilakukan actor pada saat terjadi kesalahan). Bennet Et al. juga mengungkapkan use case diagram mempunyai dua jenis hubungan (relationship) yaitu : extend dan include. Hubungan extend digunakan ketika ingin menunjukkan bahwa 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.

membuat batasan

update rekening

*

*

* * sistem akuntansi

manajer penjualan

menganalisa risiko <>() *

*

kesepakatan nilai <>() kesepakatan harga

*

*

*

* * merekam kesepakata n

penjual

* * * sales

Gambar 2.7 Contoh use case diagram (Sumber : Fowler, Martin , 2005, p141))

2.5.8.2 Sequence diagram Menurut 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 sequence diagram yang masing-masing diagram tersebut dapat lebih atau kurang memenuhi kebutuhan dari use case. Menurut Fowler, Martin (2005, p81) sebuah sequence diagram,secara khusus, menjabarkan behaviour sebuah skenario tunggal. Diagram tersebut menunjukkan

sejumlah objek contoh dan pesan-pesan yang melewati objek-objek ini di dalam use case.

2.5.8.3 Function Menurut Mathiassen Et al. (2000, pp138-139) kegiatan function memfokuskan pada bagaimana cara sebuah sistem dapat membantu aktor dalam melaksanakan pekerjaan mereka. Function memiliki empat type yang berbeda yaitu : •

Update,

function

ini

disebabkan

oleh

event

problem-domain

dan

menghasilkan perubahan dalam state atau keadaan dari model tersebut. •

Signal, function ini disebabkan oleh perubahan keadaan atau state dari model yang dapat menghasilkan reaksi pada konteks. Reaksi ini dapat berupa tampilan bagi aktor dalam application domain, atau intervensi langsung dalam problem domain.

•

Read, function ini disebabkan oleh kebutuhan informasi dalam pekerjaan aktor dan mengakibatkan sistem menampilkan bagian yang berhubungan dengan informasi dalam model.

•

Compute, function ini disebabkan oleh kebutuhan informasi dalam pekerjaan actor dan berisi perhitungan yang melibatkan informasi yang disediakan oleh actor 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 function-function yang kompleks. Daftar function harus lengkap, menyatakan kebutuhan kolektif dari pelanggan dan aktor dan harus konsisten dengan use case.

Menurut Mathiassen Et al. (2000, p142) cara untuk mengidentifikasikan function adalah dengan melihat deskripsi problem domain yang dinyatakan dalam kelas dan event, dan melihat deskripsi application domain yang dinyatakan dalam use case. kelas dapat menyebabkan munculnya function baca dan update. Event memungkinkan munculnya kebutuhan terhadap function update. Sementara use case dapat menyebabkan munculnya segala macam tipe function.

2.5.8.4 User Interface Menurut Mathiassen Et al. (2000, pp151-155) 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. Sebuah user interface yang baik harus dapat beradaptasi dengan pekerjaan dan pemahaman user terhadap sistem. Kualitas antar muka pengguna ditentukan oleh kegunaan atau usability interface tersebut bagi pengguna. Usability bergantung pada siapa yang menggunakan dan situasi pada saat system tersebut digunakan. Oleh sebab itu usability bukan sebuah ukuran yang pasti dan objektif. Ada empat jenis pola dialog yang penting dalam menentukan interface pengguna yaitu : pola menu-selection yang terdiri dari daftar pilihan yang mungkin dalam interface pengguna; pola fill in yang merupakan pola klasik untuk entri data; pola commandlanguage dimana user memasukkan dan memulai format perintah sendiri; pola direct manipulation dimana user memilih objek dan melaksanakan function atas objek dan melihat hasil dari interkasi 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 deskripsi elemen-elemen interface pengguna dan interface system 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 elemenelemen tersebut.

2.5.9

Navigation Diagram Navigation Diagram menyediakan ulasan dari elemen-elemen user interface dan

transisi di antara elemen-elemen tersebut dalam sebuah sistem. Navigation Diagram terdiri atas gambar-gambar dari tiap window yang telah diperkecil ukurannya dan garisgaris panah yang menggambarkan bagaimana sebuah button atau seleksi lainnya dapat mengaktifkan fungsi atau window lainnya.

2.5.10 Architecture Design Menurut Mathiassen L. Et al. (2000, p173) keberhasilan suatu sistem ditentukan oleh kekuatan desain arsitekturalnya. Arsitektur membentuk sistem sesuai dengan fungsi sistem tersebut dan dengan memenuhi kriteria desain tertentu. Arsitektur juga berfungsi sebagai kerangka untuk kegiatan pengembangan yang selanjutnya. Dan sebuah arsitektur yang tidak jelas akan menghasilkan banyak pekerjaan yang sia-sia. Untuk lebih jelasnya, kegiatan-kegiatan yang dilakukan selama tahap desain arsitektur dapat dilihat pada tabel berikut ini.

Kegiatan Criteria Komponen Proses

Isi Kondisi Kondisi dan criteria untuk pendesainan Criterion Bagaimana sistem dibentuk menjadi Arsitektur komponen komponen-komponen Bagaimana proses sistem didistribusikan dan Arsitektur proses dikoordinasi Table 2.5 Kegiatan desain arsitektur ( Sumber : Mathiassen L. Et al. , 2000, p176)

2.5.10.1 Criteria Menurut Mathiassen Et al. (2000, pp177-184) dalam menciptakan sebuah desain yang baik diperlukan pertimbangan mengenai kondisi-kondisi dari setiap proyek yang dapat mempengaruhi kegiatan desain yaitu : •

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.

•

Conceptual, yang terdiri dari pertimbangan : perjanjian kontrak, rencana untuk pengembangan lanjutan, pembagian kerja antara pengembang.

•

Human, yang terdiri dari pertimbangan : keahlian dan pengalaman orang yang terlibat dalam kegiatan pengembangan dengan sistem yang serupa dan dengan platform teknis yang akan didesain. Karena tidak ada cara-cara tertentu atau mudah untuk menghasilkan suatu

desain yang baik. Banyak perusahaan menciptakan suatu standar prosedur untuk

memberikan jaminan terhadap kualitas sistem. Disinilah kegiatan criteria dapat membantu dengan menetapkan perioritas desain untuk setiap proyek tertentu. Sebuah desain yang baik memiliki tiga ciri-ciri yaitu : •

Tidak memiliki kelemahan. Syarat ini menyebabkan adanya penekanan pada evaluasi dari kualitas berdasarkan review dan eksperimen dan membantu dalam menentukan prioritas dari criteria yang akan mengatur dalam kegiatan pendesainan. Table dibawah ini adalah beberapa criteria umum yang digunakan dalam kegiatan desain yang berorientasi objek :

Criterion Usable

Secure Efficient Correct Reliable Maintainable Testable Fleksible Comprehensible Reusable Portable Interoperable

Ukuran dari Kemampuan sistem untuk menyesuaikan diri dengan konteks, organisasi yang berhubungan dengan pekerjaan 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 melaksanakan fungsi. Biaya untuk menemukan dan memperbaiki kerusakan. Biaya untuk memastikan bahwa system 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 platform teknis yang berbeda. Biaya untuk menggabungkan sistem ke sistem yang lain. Table 2.6 Beberapa kriteria dalam perancangan ( Sumber : Mathiassen L. Et al. , 2000, p178)

•

Menyeimbangkan beberapa criteria. Konflik sering terjadi antar criteria, oleh sebab itu untuk menentukan criteria

mana

yang

akan

diutamakan

dan

bagaimana

cara

untuk

menyeimbangkannya dengan criteria-criteria yang lain bergantung pada situasi sistem tertentu. •

Usable, flexible, dan comprehensible. Kriteria-kriteria ini bersifat universal dan digunakan pada hampir setiap proyek pengembangan sistem.

2.5.10.2

Component Architecture

Menurut Mathiassen Et al. (2000, pp190-200) 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 lebih 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 : •

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 kepada lapisan

yang ada dibawahnya. Perubahan yang terjadi pada suatu lapisan akan mempengaruhi lapisan diatasnya.

«component» Layer i+1

Upward interface

«component» Layer i

Downward interface

«component» Layer i-1

Gambar 2.8 Arsitektur Layered ( Sumber : Mathiassen L. Et al. , 2000, p193) •

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, diikuti dengan function sistem dan komponen interface diatasnya.

«component» «component» User Interface

«component» System Interface «component» Function «component» Model

«component» Technical «component» UIS

«component» DBS

«component» NS

Gambar 2.9 Arsitektur generic ( Sumber : Mathiassen L. Et al. , 2000, p196) •

Arsitektur client-server Pola ini awalnya dikembangkan untuk mengatasi masalah distribusi sistem di antara beberapa processor yang tersebar secara geografis. Komponen pada arsitektur ini adalah sebuah server dan beberapa client. Tanggung jawab daripada server adalah untuk menyediakan database dan resources yang dapat disebarkan kepada client

melalui jaringan. Sementara client memiliki

tanggung jawab untuk menyediakan antarmuka lokal untuk setiap penggunanya.

«component» Client1

«component» Client2

«component» Clientn

«component» Server

Gambar 2.10 Arsitektur client-server ( Sumber : Mathiassen L. Et al. , 2000, p197) Berikut adalah beberapa jenis distibusi dalam arsitektur client-server dimana U adalah user interface, F adalah function, M adalah model. Client

Server

architecture

U

U+F+M

Distributed presentation

U

F+M

Local presentation

U+F

F+M

Distributed functionality

U+F

M

Centralized data

U+F+M M

Distributed data

Table 2.7 Client-server architecture ( Sumber : Mathiassen L. Et al. , 2000, p200)

2.5.10.3

Process Architecture

Menurut Mathiassen Et al. (2000, pp 209-212) arsitektur proses adalah struktur dari eksekusi sistem yang terdiri dari proses-proses yang saling tergantung. Untuk mengeksekusi atau menjalankan sebuah system 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 logic yang dihasilkan oleh kegiatan komponen dan bertujuan untuk menentukan struktur fisik dari sebuah sistem dengan : mendistribusikan komponen-komponen program ke processor yang akan digunakan untuk eksekusi sistem, mengkoordinasi pembagian sumber daya dengan active objek dan menghasilkan arsitektur yang tidak memiliki hambatan. Sumber daya yang pada umumnya digunakan secara bersama, yaitu : •

Processor Terjadi apabila ada dua atau lebih proses yang dieksekusi secara bersamaan pada satu processor.

•

Program component Terjadi bila terdapat dua atau lebih proses yang secara bersamaan memanggil operasi pada komponen.

•

External device Misalnya, pada penggunaan printer yang terhubung melalui network.

2.5.11 Component Design Menurut Mathiassen L. Et al. (2000, pp231-232) tujuan dari kegiatan desain komponen ini adalah untuk menentukan implementasi kebutuhan dalam rangka 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

Konsep Model component and attribute Function component Function component and operation Bagaimana komponen-komponen Component and Connecting dihubungkan component connection Table 2.8 Kegiatan perancangan komponen ( Sumber : Mathiassen L. Et al. , 2000, p232)

2.5.11.1

Context Bagaimana suatu model digambarkan sebagai kelas dalam sebuah sistem Bagaimana suatu function diimplementasikan

Model Component Menurut Mathiassen Et al. (2000, p236) model analisis problem domain

menggambarkan kebutuhan system. Kebutuhan system 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 historical ke function, interface dan 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,

attribute dan struktur baru yang mewakili event .Revisi class diagram dapat dilakukan dengan memperhatikan private events dan common events. Private events adalah event yang melibatkan hanya satu object domain (Mathiassen Et al. (2000, p239) Event-event yang hanya terjadi pada urutan (sequence) dan selection

Representasi event-event ini sebagai state attribute pada class yang dijabarkan oleh statechart diagram. Setiap kali ada kejadian yang melibatkan salah satu event tersebut, maka sistem akan menugaskan yang baru kepada state attribute. Intergrasikan attribute dari event yang terlibat dalam class. Event-event yang Representasikan event-event ini sebagai terjadi berulang-ulang suatu class baru, dan hubungkan class (iteration) tersebut dengan class yang dijabarkan pada statechart diagram dengan menggunakan struktur aggregation. Untuk setiap iterasi, sistem akan menghasilkan suatu object baru. Integrasikan attribute event ke dalam sebuah class yang baru. Tabel 2.9 Panduan untuk mempresentasikan private events ( Sumber : Mathiassen L. Et al. , 2000, p241) Jika suatu event adalah common, sehingga mempengaruhi beberapa object, maka event tersebut perlu dihubungkan dengan salah satu object dan dibuat hubungan struktural dengan object lain agar tetap dapat mengaksesnya.

Common event

Jika event yang terlibat daam statechart diagram dalam cara yang berbeda, representasikan event tersebut dalam hubungan ke class yang menawarkan representasi paling simple. Jika event yang terlibat dalam statechart diagram dalam cara yang sama, pertimbangkan alternatif representasi yang mungkin dapat digunakan

Tabel 2.10 Panduan untuk mempresentasikan common events ( Sumber : Mathiassen L. Et al. , 2000, p241) Untuk menyederhanakan class diagram yang telah direvisi dari hasil tahapan sebelumnya, dilakukan restrukturisasi class baik melalui generalization, association, maupun embedded iteration.

2.5.11.2 Function Component Menurut Mathiassen Et al. (2000, pp251-252) 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 suatu 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

mengimplementasikan fungsi sistem seperti yang ditentukan dalam analisis problem domain dan function list. •

Merancang function sebagai operation. Ada empat tipe function menurut Mathiassen Et al. (2000, pp255-256), yaitu :

Update, Read, Compute, dan Signal. •

Menelusuri pola yang dapat membantu dalam implementasi function sebagai operation. Patterns dapat membantu memilih functional design yang mana dapat digunakan dari beberapa pilihan yang dapat membantu merealisasikan functions sebagai sekumpulan operations. Empat pola menurut (Mathiassen Et al. (2000, pp260-264), yaitu : o Model Class Placement Pola ini menempatkan operation dalam model component class dan berguna ketika sebuah operation mengakses hanya sebuah single object atau struktur aggregation yang sederhana. Pola ini juga dapat digunakan ketika beberapa object terlibat namun hanya jika tanggung jawab operation tersebut dapat dengan jelas ditempatkan pada salh satu model class. o Function Class Placement Pola ini digunakan ketika tanggung jawab operation tidak dapat dengan jelas ditempatkan dalam model class. Sebaliknya satu atau lebih

functional-component

class

dapat

digambarkan

dengan

menempatkan operation yang merealisasikan function. o Strategy Pola ini digunakan untuk mendefinisikan sekumpulan operations yang umum terenkapsulasi dan dapat dipertukarkan.

o Active function Active signal function dapat direalisasikan sebagai operation yang secara permanent aktif dan berkala memberikan sinyal kepada interface. Active function ditempatkan sebagai active object dan performance-nya tergantung pada state pada model component. •

Spesifikasikan operasi yang kompleks. Apabila terdapat operation yang kompleks yang harus dideskripsikan dengan lebih detail lagi sehingga di dalam desain tidak ada ketidakpastian yang penting.

Menurut Mathiassen Et al. (2000, pp265-266), ada 3 cara untuk

melakukannya , yaitu : operation specification, sequence diagram, dan statechart diagram.

2.5.12 Connecting components Tujuan dari aktivitas ini adalah menghubungkan komponen-komponen sistem yang akan menghasilkan class diagram dari komponen-komponen tersebut, jadi pada aktivitas ini, hubungan antara komponen-komponen dirancang untuk mendapatkan desain yang fleksibel dan comperehensible. Untuk itu dibutuhkan evaluasi dari coupling dan cohesion. Coupling adalah ukuran tentang seberapa dekat dua classes atau components dihubungkan (Mathiassen Et al. (2000, p272). Cohesion adalah ukuran tentang seberapa baik sebuah class atau component terikat bersama (Mathiassen Et al. (2000, p273). Prinsipnya adalah “highly cohesive classes, loosely coupled components”.

Hasil dari aktivitas connecting components ini adalah class diagram yang dimana dependencies-nya berubah menjadi connections. Tiga bentuk connections menurut (Mathiassen Et al. (2000, p275,p281) adalah : •

Class aggregation, yaitu mengagregasikan class-class dari component lain. Koneksi ini berguna ketika class definition sudah ada di dalam component lain. Umumnya coupling-nya rendah , namun sulit mencapai cohesive.

•

Class specialization, yaitu menspesialisasikan public class dari component lain.

Operation call, yaitu memanggil public operation di dalam object-object dari component lain. Umumnya coupling rendah dan cohesion-nya tinggi.

2.5.13

Implementation Tahap akhir dalam perancangan sebuah sistem adalah pembangunan prototype

dari sistem tersebut. Prototype dibangun dengan menggunakan sebuah program berorientasi object.