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 masalah-

masalah 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 biaya-

biaya 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 atau barang-barang perlengkapan

(supplier stock)

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 barang-

barang 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 barang-

barang 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 masing-

masing 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, barang-

barang yang telah lama dalam gudang, dan barang-barang yang sudah usang dan

ketinggalan zaman.

• Pengecekan untuk menjamin dapat efektifnya kegiatan rutin. ”.

2.3.7 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

C P

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 menjadi dasar dari seluruh komponen

pengendalian internal lainnya karena lingkungan 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 kesalahan-

kesalahan 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 terus-

menerus 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.

Gambar 2.1 Aktivitas utama dalam OOA&D

( Sumber : Mathiassen L. Et al. , 2000, p15)

Component

Architectural

Application

domain

Problem

domain

Specifications for

Model

Requirements

Specifications for

System Choice

System Definition

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 Fungsi dari suatu sistem yang mendukung tugas-tugas dalam application domain.

Application Domain

Bagian dalam sebuah organisasi yang diadministrasikan, dimonitor, atau dikontrol dalam problem domain.

Conditions Kondisi dimana sistem akan dikembangkan dan digunakan. Technology Teknologi yang digunakan baik untuk mengembangkan sistem

maupun teknologi untuk menjalankan sistem tersebut. Object Object utama dalam problem domain. Responsibility 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 kegiatan-

kegiatan yang dilakukan dalam analisis problem-domain dapat dilihat pada tabel berikut

ini.

Kegiatan Isi Konsep Class Object dan event yang merupakan

bagian dari problem domain Class, object dan event

Structure Bagaimana class dan object saling berkaitan

Generalisasi, agregasi, asosiasi, dan cluster

Behaviour Property dinamik yang dimiliki object

Event trace, behavioural pattern, dan attribute

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.

Kelas Event Customer Assistant Apprentice Appointment Plan Reserved V V V V

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

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

Cancelled V V V Treated V V Employed V V Resigned V V Graduated V Agreed V V V

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.

Union-member, dimana whole merupakan

union/gabungan yang terorganisir dari anggotanya

(parts), sehingga jika terdapat 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*

-c..d*

-a..b*

-c..d*

Ket : a-d adalah multiplicity

Gambar 2.4 Notasi object structure ( Sumber : Mathiassen L. Et al. , 2000, p337)

car person0..* 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 Isi Konsep Usage Bagaimana sistem berinteraksi dengan

orang lain dan sistem lain dalam konteks Use case dan actor

Function Bagaimana kemampuan sistem dalam memproses informasi

Function

Interface Kebutuhan antarmuka dari sistem target 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), post-

condition (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.

manajer penjualan

penjual

sistem akuntansi

sales

membuat batasan

menganalisa risiko

kesepakatan harga

merekam kesepakatan

update rekening

kesepakatan nilai

<<include>>()

<<include>>()

* *

* *

**

* *

* *

**

**

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 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 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 elemen-

elemen 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 garis-

garis 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 Isi Kondisi Criteria Kondisi dan criteria untuk pendesainan Criterion Komponen Bagaimana sistem dibentuk menjadi

komponen-komponen Arsitektur komponen

Proses Bagaimana proses sistem didistribusikan dan dikoordinasi

Arsitektur proses

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 Ukuran dari Usable Kemampuan sistem untuk menyesuaikan diri dengan

konteks, organisasi yang berhubungan dengan pekerjaan dan teknis.

Secure Ukuran keamanan sistem dalam menghadapi akses yang tidak terotorisasi terhadap data dan fasilitas.

Efficient Eksploitasi ekonomis terhadap fasilitas platform teknis. Correct Pemenuhan dari kebutuhan. Reliable Pemenuhan ketepatan yang dibutuhkan untuk melaksanakan

fungsi. Maintainable Biaya untuk menemukan dan memperbaiki kerusakan. Testable Biaya untuk memastikan bahwa system yang dibentuk dapat

melaksanakan fungsi yang diinginkan. Fleksible Biaya untuk mengubah sistem yang dibentuk. Comprehensible Usaha yang diperlukan untuk mendapatkan pemahaman

terhadap sistem. Reusable Kemungkinan untuk menggunakan bagian sistem pada

sistem lain yang berhubungan. Portable Biaya untuk memindahkan sistem ke platform teknis yang

berbeda. Interoperable Biaya untuk menggabungkan sistem ke sistem yang lain.

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.

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» Layer i+1

«component» Layer i

«component» Layer i-1

Upward interface

Downward interface

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»

«component» Technical

«component» Function

«component» Model

«component» User Interface

«component» System Interface

«component» UIS

«component» DBS

«component» NS

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

«component» Client1

«component» Client2

«component» Clientn

«component» Server

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 Context Konsep Model component Bagaimana suatu model digambarkan

sebagai kelas dalam sebuah sistem Model component and attribute

Function component Bagaimana suatu function diimplementasikan

Function component and operation

Connecting component

Bagaimana komponen-komponen dihubungkan

Component and connection

Table 2.8 Kegiatan perancangan komponen ( Sumber : Mathiassen L. Et al. , 2000, p232)

2.5.11.1 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)

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.

Event-event yang hanya terjadi pada urutan (sequence) dan selection

Intergrasikan attribute dari event yang terlibat dalam class. Representasikan event-event ini sebagai suatu class baru, dan hubungkan class tersebut dengan class yang dijabarkan pada statechart diagram dengan menggunakan struktur aggregation. Untuk setiap iterasi, sistem akan menghasilkan suatu object baru.

Event-event yang terjadi berulang-ulang (iteration)

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.

Jika event yang terlibat daam statechart diagram dalam cara yang berbeda, representasikan event tersebut dalam hubungan ke class yang menawarkan representasi paling simple.

Common event 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.