Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
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.