LANDASAN TEORI
2.1. Teknik Industri
Menurut Wignjosoebroto (2003, p1), Teknik Industri merupakan suatu disiplin ilmu keteknikan yang baru, lahir melalui suatu proses evolusi yang lama sejak Revolusi Industri yang berlangsung sekitar dua abad lampau. Disiplin ini muncul dan berkembang untuk memenuhi kebutuhan akan tenaga-tenaga yang terampil dalam hal perencanaan, pengorganisasian, pengoperasian serta pengendalian suatu sistem produksi/industri yang luas dan kompleks. Kebutuhan untuk meningkatkan efektivitas, efisiensi maupun produktivitas sistem produksi merupakan pendorong utama munculnya disiplin Teknik Industri.
Menurut Wignjosoebroto (2003,p2), Secara definitif industri bisa diartikan sebagai suatu lokasi/tempat di mana aktivitas produksi akan diselenggarakan, sedangkan aktivitas produksi bisa dinyatakan sebagai sekumpulan aktivitas yang diperlukan untuk mengubah satu kumpulan masukan (human resources, materials, energy, informasi, dan lain-lain) menjadi produk keluaran (finished product atau service) yang memiliki nilai tambah.
Menurut IIE (Institute of Industrial Engineering) yang dikutip oleh Turner et al.
(2000, p21) Teknik Industri memiliki definisi sebagai sesuatu yang memiliki hubungan dengan perancangan, pengembangan, dan penginisiasian dari sistem yang terintegrasi dari orang, material, informasi, peralatan dan energi. Yang diambil dari ilmu-ilmu tertentu dan kemampuan di bidang matematika, fisika, pengetahuan sosial dan bersama
dengan prinsip-prinsip dan metoda dari analisa teknik dan perancangan untuk menspesifikasikan, memperkirakan dan mengevaluasi hasil yang didapatkan dari sistem tersebut.
2.2. Simulasi
2.2.1. Pengertian Simulasi
Menurut Kakiay (2004, p1), simulasi merupakan salah satu cara untuk memecahkan berbagai persoalan yang dihadapi di dunia nyata (real world). Banyak metode yang dibangun dalam Operational Research dan System Analyst untuk kepentingan pengambilan keputusan dengan menggunakan berbagai analisis data.
Menurut Harrell et al.(2000, p5) yang juga mengemukakan bahwa simulasi adalah imitasi dari sistem dinamis dengan menggunakan model komputer untuk mengevaluasi dan meningkatkan performansi sistem
2.2.2. Keuntungan dan Kerugian Simulasi
Menurut Render et al. (2003, p603), simulasi mempunyai keuntungan dan kerugian. Keutungannya antara lain adalah:
Simulasi relatif mudah dan fleksibel.
Perkembangan akhir dalam dunia software memungkinkan beberapa model simulasi sangat mudah untuk dikembangkan.
Simulasi dapat digunakan untuk menganalisa situasi dunia nyata yang kompleks dan luas yang tidak dapat diselesaikan oleh model analisis kuantitatif konvensional.
Simulasi memungkinkan analisa what-if. Dengan bantuan komputer, manajer mampu mencoba beberapa kebijakan keputusan dalam hitungan menit.
Simulasi tidak mempengaruhi sistem dunia nyata.
Simulasi memungkinkan peneliti untuk mempelajari efek interaktif dari komponen individu ataupun variabel untuk menentukan yang mana yang penting.
Simulasi memungkinkan time compression.
Simulasi memungkinkan terlibatnya beberapa komplikasi yang terjadi di dunia nyata, yang mana tidak dimungkinkan oleh model analisis kuantitatif pada umumnya.
Sedangkan menurut Render et al. (2003, p604), kekurangan dari simulasi adalah:
Model simulasi yang baik untuk situasi kompleks pada umumnya sangat mahal. Proses pembuatannya memakan waktu yang lama dan merupakan proses yang kompleks.
Simulasi tidak menghasilkan solusi yang optimal untuk suatu permasalahan seperti teknik analisis kuantitatif lainnya. Simulasi merupakan pendekatan trial and error, yang memberikan solusi yang berbeda setiap pengulangannya.
Manager harus membangkitkan kondisi dan batasan berkaitan dengan solusi yang hendak dicapai.
Masing-masing model simulasi bersifat unik. Solusi dan keputusan simulasi tidak selalu dapat diaplikasikan untuk permasalahan lain.
2.2.3. Kriteria Waktu yang Tepat dalam Penggunaan Simulasi
Merurut Harrell et al. (2000, p12), simulasi sendiri memiliki batasan yang harus diperhatikan sebelum memutuskan penggunaanya terhadap sebuat situasi. Beberapa pentunjuk umum tentang kriteria yang cocok dalam menggunakan simulasi:
Keputusan operasional (logis maupun kuantitatif) dibutuhkan.
Proses yang akan dianalisa terdefinisi dengan baik dan berulang-ulang.
Aktivitas dan kejadian menunjukkan sifat ketergantungan dan keanekaragaman.
Biaya akibat penerapan keputusan lebih besar dibandingkan biaya pembuatan simulasi
Biaya eksperimen pada sistem aktual lebih besar dibandingkan biaya pembuatan simulasi
2.2.4. Klasifikasi Simulasi
Menurut Suryani (2006, p6), simulasi dapat diklasifikasikan sebagai berikut:
1. Menurut waktu:
o Simulasi statis. Pada simulasi ini output model tidak dipengaruhi waktu
Contoh: simulasi yang dilakukan oleh George L.Leclere.
o Simulasi dinamis. Pada simulasi ini output model dipengaruhi waktu. Waktu bertindak sebagai variabel bebas.
Contoh: model populasi yang berkembang sepanjang waktu, laju penjualan, tingkat penjualan.
2. Menurut perubahan status variabel
o Simulasi kontinyu, merupakan model simulasi yang status variabel berubah secara kontinyu.
Contoh: model-model level cairan yang rate-nya (lajunya) berubah setiap saat.
o Simulasi diskrit, merupakan model yang status variabelnya berubah pada saat-saat tertentu.
Contoh: model-model inventory yang materialnya datang dan diambil pada waktu tertentu.
3. Menurut derajat ketidakpastiannya
o Simulasi deterministik merupakan model yang outputnya bisa ditentukan secara pasti.
Contoh: model-model matematis, model EOQ
o Simulasi stokastik, yaitu model yang tidak bisa ditentukan secara pasti (mengandung ketidakpastian).
Contoh: doagram pohon keputtusan.
2.2.5. Tahapan Melakukan Simulasi
Menurut Suryani (2006, p11), terdapat beberapa langkah yang perlu dilakukan dalam simulasi, yaitu:
1. Pendefinisian sistem. Langkah ini meliputi: penentuan batasan sistem dan identifikasi variabel yang significant.
2. Formulasi model: merumuskan hubungan antar komponen-komponen model.
3. Pengambilan data: identifikasi data yang diperlukan oleh model sesuai dengan tujuan pembuatan model.
4. Pembuatan model. Dalam penyusunan model perlu disesuaikan dengan jenis bahasa simulasi yang akan digunakan.
5. Verivikasi model: proses pengecekan terhadap model apakah sudah bebas dari error.
6. Validasi model merupakan proses pengujian terhadap model apakah model yang dibuat sudah sesuai dengan sistem nyatanya. Yaman Barlas dalam jurnalnya yang berjudul “Multiple Test for Validation of Systems Dynamic Type of Simulation Model”, menjelaskan dua cara pengujian, yaitu:
a. Perbandingan rata-rata (Mean Comparison)
A_ _) _ A S E1=( −
Di mana:
_S = Nilai rata-rata hasil simulasi A_= Nilai rata-rata data aktual
Model dianggap valid bisa E1≤ 5%
b. Perbandingan Variasi Amplitudo (Amplitude Variation Comparison)
Untuk membandingkan variasi antara output simulasi dan data historis yang tersedia, kita dapat menghitung standard deviasi model (Ss) dan standar deviasi historis (Sa). Kedua standard
deviasi ini kemudian dibandingkan dengan menggunakan
“Percent Error in the Variations” atau E2, dengan rumus sebagai berikut:
Sa Sa Ss
E2 −
=
Model dianggap valid bila 2E ≤ 30%
7. Skenarioisasi: penyusunan skenario terhadap model. Setelah model valid, maka langkah selanjutnya adalah membuat beberapa skenario (eksperimen) untuk memperbaiki kinerja sistem sesuai dengan keinginan.
Secara umum jenis-jenis skenario dapat kita bedakan menurut dua jenis:
a. Skenario parameter yang dilakukan dengan jalan mengubah nilai parameter model. Skenario jenis ini relatif mudah dilakukan karena kita hanya melakukan perubahan terhadap nilai paramter model dan melihat dampaknya terhadap output model.
b. Skenario struktur dilakukan dengan jalan mengubah struktur model. Skenario jenis ini memerlukan pengetahuan yang cukup tentang sistem agar struktur baru yang diusulkan/dieksperimenkan dapat memperbaiki kinerja sistem.
8. Interpretasi model. Proses ini merupakan penarikan kesimpulan dari hasil output model simulasi.
9. Implementasi merupakan penerapan model pada sistem.
10. Dokumentasi merupakan proses penyimpanan hasil output model.
2.2.6. Pengertian Random Number dan Generator Random Number
Menurut Kakiay (2004, p21) Random Number Generator adalah suatu algoritma yang digunakan untuk menghasilkan urutan-urutan atau sequence dari angka-angka sebagai hasil dari perhitngan dengan komputer yang diketahui distribusinya sehingga angka-angka tersebut muncul secara random dan digunakan terus-menerus.
Menurut Suryani (2006, p23), bilangan random merupakan bilangan yang berdistribusi uniform antara 0 dan 1.
Menurut Kakiay (2004, p22), dalam penentuan random number pada umumnya terdapat beberapa sumber yang dipergunakan, antara lain:
Tabel Random Number
Tabel Random ini sudah banyak ditemukan mulai dari enam digit sampai dengan dua belas digit.
Electronic Random Number
Electronic Random Number ini juga banyak digunakan dalam percobaan penelitian.
Congruential Pseudo Random Number Generator Random Number Generator ini terdiri dari tiga bagian:
o Additve (Arithmatic) Random Number Generator o Multiplicative Random Number Generator o Mixed Congruential Random Number Generator
2.2.7. Simulasi Monte Carlo
Menurut Kakiay (2004, p113), simulasi Monte Carlo dikenal juga dengan istilah Sampling Simulation atau Monte Carlo Sampling Technique. Sampling simulasi ini
menggambarkan kemungkinan penggunaan data sampel dalam metode Monte Carlo dan juga sudah dapat diketahui atau diperkirakan distribusinya. Simulasi ini menggunakan data yang sudah ada (historical data) yang sebenarnya dipakai pada simulasi untuk tujuan lain. Dengan kata lain apabila menghendaki model simulasi yang mengikutsertakan random dan sampling dengan distribusi probabilitas yang dapat diketahui dan ditentukan, maka secara simulasi Monte Carlo ini dapat dipergunakan.
Metode simulasi Monte Carlo ini cukup sederhana di dalam menguraikan ataupun menyelesaikan persoalan, termasuk dalam penggunaan program-programnya di komputer.
Menurut Render et al. (2003, p604), ketika sebuah sistem memiliki elemen- elemen yang menunjukkan adanya suatu peluang dalam sifat variabelnya, metode dari simulasi Monte Carlo ini dapat diaplikasikan.
Ide dasar dari simulasi Monte Carlo ini adalah menghasilkan suatu nilai untuk membentuk suatu model dari variabelnya dan dipelajari. Ada banyak sekali variabel- variabel di dalam sistem nyata ini yang merupakan probabilitas secara alami dan yang mungkin ingin kita simulasikan.
Berikut adalah beberapa contoh dari variabel-variable berikut:
1. Persediaan permintaan harian atau mingguan
2. Waktu menunggu untuk pemesanan persediaan sampai tiba ke kita 3. Waktu diantara breakdown mesin
4. Waktu antar kedatangan di fasilitas pelayanan 5. Waktu pelayanan
6. Waktu untuk menyelesaikan suatu proyek
7. Jumlah karyawan yang tidak hadir setiap harinya.
Dasar dari simulasi monte carlo adalah percobaan dari peluang (probabilitas) elemen melalui penarikan contoh acak (random sampling).
Berikut ini Lima langkah-langkah untuk melakukan simulasi monte carlo : 1. Membuat suatu distribusi probabilitas dari variabel pentingnya
2. Kemudian menyusun distribusi probabilitas kumulatifnya dari setiap variabel yang berasal dari langkah 1.
3. Membuat suatu interval angka acak dari setiap variabelnya.
4. Mengenerate angka acak
5. Dan terakhir lakukan simulasi secara berkala untuk percobaan- percobaannya.
2.2.8. Normal Distribution
Menurut Taha (2003, p651), teori limit terpusat menyatakan bahwa jumlah dari angka random sebanyak n yang berdiri sendiri dan terdistribusi secara serupa akan menjadi normal dengan jumlah n yang cukup. Kita dapat menggunakannya untuk menghasilkan sample dari pendistribusian normal dengan nilai rata-rata dan simpangan baku.
Menurut Taha (2003, p652), teori di atas disempurnakan oleh teori Box-Muller yang menetapkan bahwa hasil perhitungan random number dari sebuah data yang terdistribusi normal adalah: y=μ+σx. Formula ini dianggap efisien karena Box-Muller menambahkan formula di awal dengan memproduksi sample N (0,1), yang menggantikan cos(2πR1) dengan sin(2πR2). Ini berarti bahwa dua random number (R1
dan R2) akan menghasilkan dua sample N (0,1). Untuk perhitungannya dapat menggunakan rumus:
2) σ(x 2 μ
y
1) σ(x 1 μ
y
2) sin(2πi 1)
2ln(R x2
2) cos(2πo 1)
2ln(R x1
+
= +
=
×
−
=
×
−
=
2.3. Model
2.3.1. Pengertian Model
Menurut Suryani (2006, p1), model merupakan representasi sistem dalam kehidupan nyata yang menjadi fokus perhatian dan menjadi pokok permasalahan.
Pemodelan dapat didefinisikan sebagai proses pembentukan model dari sistem tersebut dengan menggunakan bahasa formal tertentu.
Menurut Kakiay (2004, p6), untuk kepentingan evaluasi model diperlukan beberapa faktor yang perlu diperhatikan, yaitu:
Penggunaan biaya relatif yang lebih efisien dari model tersebut.
Model tersebut dapat dipergunakan untuk berkomunikasi di antara orang teknik itu sendiri dan juga antara orang teknik dengan pelaksana di lapangan.
Adanya keterbatasan di dalam menggunakan model tersebut.
2.3.2. Klasifikasi Model
Menurut Kakiay (2004, p6), setiap penjelasan tentang cara memodelkan suatu persoalan pasti terdiri dari dua bagian, yaitu:
Bagian pertama yang menguraikan tentang format, di mana model ini akan ditunjuk atau diekspresikan.
Bagian kedua dapat menguraikan jalan keluar, yang mana model tersebut dapat dipergunakan untuk membuat prediksi ataupun mendapatkan solusi yang optimal.
Menurut Kakiay (2004, p7), beberapa klasifikasi dari model adalah:
Model deskriptif
Model yang memiliki banyak batasan dan memiliki biaya pembuatan yang cukup rendah.
Model fisik
Model fisik menyediakan kemudahan untuk berkomunikasi dengan orang-orang yang tidak memiliki background teknik, tetapi model ini memerlukan biaya yang tinggi.
Model simbolik
Model ini digunakan sama seperti simbol-simbol matematik sehingga biayanya relatif murah. Biasanya dibagi menjadi dua metode lagi:
o Pendekatan interaktif o Pendekatan Monte Carlo
2.3.3. Prinsip Dasar Pengembangan Model
Menurut Suryani (2006, p2), pengembangan suatu model dapat dilakukan dengan menggunakan aturan-aturan diantaranya yaitu:
1. Elaborasi
Pengembangan model sebaiknya dimulai dari yang paling sederhana kemudian secara bertahap dielaboras menjadi model yang representative.
Penyederhanaan permasalahan dapat dilakukan dengan menggunakan asumsi-asumsi yang diperlukan, sesuai dengan tujuan pembuatan modelnya.
2. Analogi
Pengembangan model dapat dilakukan dengan menggunakan prinsip- prinsip dan teori-teori yang sudah dikenal luas.
3. Dinamis
Pengembangan model bukanlah suatu proses mekanis dan linear, sehingga dalam tahap pengembangannya mungkin saja terdapat proses pengulanga.
2.4. Logistik
2.4.1. Definisi Logistik
Menurut Ghiani et al. (2004, p1), logistik berhubugan dengan perencanaan dan mengontrolan aliran material dan informasi yang berhubungan di perusahaan, baik di bagian umum dan privat. Misinya adalah untuk mendapatkan material yang tepat di tempat yang tepat dan di waktu yang tepat.
Menurut Ghiani et al. (2004, p14), ketika menyusun strategi logistik, biasanya tujuan manajer adalah untuk menjadi titik yang optimal diantara tiga bagian utama, yaitu:
Pengurangan modal
Pengurangan biaya
Peningkatan level pelayanan
Menurut Ghani et al. (2004, p18), ketika merancang dan mengoperasikan sistem logistik, seseorng butuh untuk membuat beberapa keputusan daasar. Keputusan logistik secara tradisional dapat diklasifikasikan menjadi: strategi, taktikal dan operasional.
Menurut Ghiani et al. (2004, p19), dalam mengambil keputusan untuk sistem logistik terdapat beberapa metode pendukung pengambilan keputusan, yaitu:
Quantititative analysis
Bencmarking
Simulation
Optimization
Menurut Rushton et al. (2000, p116), biaya-biaya yang biasa dibutuhkan di dalam pendistribusian fisik antara lain adalah:
Harga bangunan (sewa, bunga, depresiasi) : 24%
Jasa Bangunan (pemanasan , pencahayaan) : 16%
Peralatan (sewa, kontrak, perawatan) : 13%
Pekerja (langsung) : 38%
Manajemen dan pengaturan : 9%
Menurut Rushton et al. (2000, p424), model yang bisa digunakan untuk menggerakan dan pernjadwalan cukup bervariasi tergantuk situasi dan tingkat kesulitan dari permasalahan, dan baik pendekatan manual dan komputer dapat digunakan. Salah satu metodenya dapat disebut sebagai algoritma. Algoritma yang paling umum diketahi adalah metode penghematan. Yang dapat digambarkan di bawah ini.
Gambar 2.1. Metode Penghematan
Depot O melayani dua titik pengiriman, yaitu A dan B. Jarak dari O ke A, O ke B dan A ke B adalah a,b,c secara berurutan. Ketika setiap kali pengiriman dilakukan dengan menggunakan satu kendaraan dari depot, maka total jarak adalah: 2a+2b. Jika satu kendaraan menggunakan satu jalur saja, maka jarak yang akan ditempuh adalah a+b+c. Maka penghematan yang dilakukan adalah: (2a+2b)-(a+b+c), atau a+b-c.
2.5. Sistem Informasi
2.5.1. Pengertian Sistem
Menurut O’Brien (2005, p22), sistem dapat didefinisikan secara mudah sebagai sebuah group yang terhubung atau elemen-elemen yang mempengaruhi satu sama lain dan membetul satu kesatuan. Sistem di bidang Sistem Informasi dapat didefinisikan lebih tepat sebagai group yang terdiri dari komponen yang saling berhubungan satu sama lain yang bekerja sama untuk mencapai tujuan bersama dengan menerima masukan (input) dam memproduksi hasil (output) dalam proses pengubahan yang terorganisasi.
Sistem yang pada umumnya disebut sebagai sistem yang dinamik memiliki tiga dasar komponen atau fungsi yang berhubungan satu sama lain, yaitu:
Input. Mencakup mendapatkan dan mengatur komponen atau elemen yang masuk ke sistem untuk diproses. Contohnya mencakup bahan mentah, data, usaha manusia.
Proses. Mencakup proses transformasi yang mengubah input menjadi output. Contohnya mencakup proses manufaktur, perhitungan matematis, dan lain sebagainya.
Output. Mencakup elemen yang telah melalui proses transformasi.
Contohnya mencakup jasa, produk dan informasi.
Selain ketiga komponen dasar tersebut, terdapat dua lagi komponen tambahan, yaitu:
Feedback. Yang merupakan data tentang performa dari sistem tersebut.
Contohnya adalah data tentang performa penjualan adalah data feedback kepada seorang manajer penjualan.
Control. Yang mencakup pengawasan dan evaluasi dari feedback untuk mengetahui bila sistem bergerak menuju tujuan yang telah ditetapkan.
2.5.2. Pengertian Informasi
Untuk memahami konsep informasi, diperlukan pemahaman mengenai data terlebih dahulu. Kata data merupakan bentuk jamak dari kata datum. Menurut O’Brien (2005, 26), data merupakan fakta mentah berdasarkan pengamatan, biasanya berupa kejadian fisik atau transaksi bisnis.
Menurut O’Brien (2005, 27), informasi dapat didefinisikan sebagai data yang telah diubah menjadi sesuatu yang lebih berarti dan berguna untuk orang-orang tertentu.
2.5.3. Pengertian Sistem Informasi
Menurut Turban et al. (2003, p15), sistem informasi adalah pengumpulan, pengolahan, analisa, dan penyebarann informasi untuk tujuan yang spesifik. Sistem informasi terdiri dari input (data dan instruksi) dan output (laporan dan kalkulasi). Dari input yang telah diolah, maka akan dihasilkan output yang akan dikirim ke pengguna akhir ataupun sistem lainnya.
Menurut O’Brien (2005, p6), sistem informasi merupakan sebuah kombinasi yang terorganisir dan terdiri dari orang, hardware, software, jaringan komunikasi dan sumber data yang dikumpulkan, diubah dan menyebarkan informasi di dalam sebuah organisasi.
Komponen dari sistem informasi adalah:
Manusia, perangkat keras, perangkat lunak, data, dan jaringan adalah lima sumber utama dari sistem informasi.
Sumber manusia meliputi pengguna akhir dan spesialis sistem informasi, sumber perangkat keras meliputi mesin dan media, sumber perangkat lunak terdiri dari program dan prosedur, dan sumber jaringan adalah media komunikasi dan jaringan.
Sumber data diubah oleh kegiatan pengubahan informasi menjadi berbagai variasi produk dari informasi yang dapat langsung digunakan oleh pengguna akhir.
Pengubahan informasi terdiri dari input, proses, output, penyimpanan, dan kegiatan pengendalian.
Diambil dari: O’Brien (2005, p7) Gambar 2.2. Komponen Sistem Informasi
Menurut O’Brien (2005, p12), sistem informasi dapat digolongkan menjadi 3 tipe, yaitu:
Operation Support Systems
Merupakan sistem operasi yang memproses data yang digunakan dalam operasi bisnis menjadi informasi yang dapat digunakan baik untuk keperluan internal maupun eksternal tanpa penekanan mengenai kegunaannya bagi manajemen (atau manajer). Fungsinya adalah untuk mengefisienkan transaksi bisnis, mengontrol proses bisnis, mendukung komunikasi dan kolaborasi serta update database. Yang termasuk dalam Operation Support System adalah:
o Transaction Processing System
Mengolah data yang didapat dari transaksi bisnis, mengupdate database operasional, dan menghasilkan dokumen bisnis.
o Process Control System
Memonitor dan mengontrol proses industri.
o Enterprise Collaboration Systems
Mendukung kolaborasi dan kerja sama serta komunikasi dalam kegiatan perushaaan, tim dan kelompok kerja.
Management Support Systems
Merupakan sistem informasi yang berfokus pada penyediaan informasi untuk mendukung pengambilan keputusan yang efektif bagi para manajer.
Yang termasuk dalam Management Support Systems adalah:
o Management Information Systems
Menyediakan informasi dalam bentuk laporan dan tampilan yang mendukung proses pembuatan keputusan bisnis.
o Decision Support Systems
Menyediakan dukungan ad hoc untuk proses pengambilan keputusan bagi manajer dan profesional bisnis lainya.
o Executive Information Systems
Menyediakan informasi yang kritis dari berbagai sumber untuk memenuhi kebutuhan informasi bagi kaum eksekutif perusahaan.
Sistem Informasi lainnya yang dapat mendukung operasi maupun kegiatan manajemen seperti:
o Expert Systems
Sistem berbasis knowledge (pengetahuan) yang memberikan masukan atau nasihat dari sudut pandang ahli di bidang tersebut.
o Knowledge Management Systems
Sistem berbasis knowledge yang mendukung penciptaan, pengorganisasian, dan penyebaran business knowledge dalam perusahaan.
o Strategic Information Systems
Mendukung proses manajemen dan operasi yang memberikan perusahaan kemampuan strategis dalam mendapatkan keuntungan bersaing.
o Functional Business Systems
Mendukung berbagai aplikasi operasional dan manajemen untuk fungsi bisnis mendasar dalam suatu perusahaan.
2.5.4. Sistem Informasi Berbasis Komputer
Menurut Turban et al. (2003, p16), sistem informasi berbasis komputer adalah sistem informasi yang menggunakan komputer dan teknologi telekomunikasi untuk mengerjakan tugas-tugas. Komponen dasar dari sistem informasi berbasi komputer terdiri dari :
Perangkat keras: yaitu kumpulan dari perangkat, seperti prosesor, monitor, keyboard, dan printer yang menerima data dan informasi, kemudian diolah dan ditampilkan.
Perangkat lunak: yaitu kumpulan dari program komputer yang memungkinkan perangkat keras untuk memproses data.
Database: yaitu kumpulan dari file atau record yang saling berhubungan dan disimpan.
Jaringan: yaitu sistem yang menghubungkan banyak komputer dan memungkinkan untuk membagi data di antara komputer yang terhubung.
Prosedur: yaitu strategi, kebijakan, metode, dan peraturan dalam menggunakan sistem informasi.
Manusia: merupakan elemen paling penting dalam sistem informasi, meliputi manusia yang bekerja dengan sistem informasi ataupun menggunakan output dari sistem informasi.
2.5.5. Keunguntungan Sistem Informasi
Turban et al. (2003,p17), sistem informasi harus dapat:
Menyediakan proses transaksi yang cepat dan akurat.
Menyediakan penyimpanan data dan informasi dengan kapasistas yang besar dan dapat diakses dengan cepat.
Menyediakan sarana komunikasi yang cepat, baik dari mesin ke mesin maupun dari manusia ke manusia.
Mengurangi informasi yang berlebihan (misalnya sistem informasi eksekutif yang menyediakan informasi terstruktur yang disesuaikan untuk eksekutif berdasarkan faktor penentu keberhasilannya).
Meminimalkan batasa-batasan (misalnya SCM yang dapat meminimalkan siklus waktu untuk pengiriman produk, mengurangi persediaan, dan meningkatkan kepuasan pelanggan).
Menyediakan pendukung pengambilan keputusan.
Menyediakan senjata persaingan, karena saat ini sistem informasi dapat dilihat sebagai sumber keuntungan yang diharapkan dapat memberikan keuntungan dan dapat mengungguli kompetitor.
2.5.6. Dicision Support Systems
Menurut O’Brien (2005, p294), terdapat beberapa level dari pengambilan keputusan menejerial yang didukung oleh informasi teknologi di dalam sebuah organisasi yang sukses, yaitu:
Strategic Management
Biasanya terdiri dari rapat pimpinan dan komisi eksekutif dari CEO dan eksekutif petinggi yang membuat goal perusahaan secara keseluruhan, strategi, kebijakan dan tujuan dari proses perancangan strategi. Mereka juga mengawasi perfoma strategi dari organisasi dan keseluruhannya di bidang politik, ekonomi dan linkungan persaingan bisnis.
Tactical Management
Secara meningkat, pekerja profesional bisnis di dalam teamnya sendiri dan juga manajer bisnis unit yang membangun perancangan jangka pendek dan menengah, penjadwalan dan keuangan dan menentukan peraturan, prosedur dan tujuan bisnis untuk subunit perusahaan mereka.
Mereka juga mengalokasikan sumber dan mengawasi performa dari subunit perusahaan mereka, termasuk departemen, divisi, tim proses, tim proyek, dan kelompok kerja lainnya.
Operational Management
Bagian dari tim yang diatur sendiri atau manajer operasional yang membangun perancangan jangka pendek seperti penjadwalan produksi mingguan. Mereka menggunakan secara langsung sumber dan performa dari tugas sesuai dengan prosedur, budget dan jadwal yang mereka tetapkan untuk tim dan kelompok kerja lainnya dalam perusahaan.
Menurut O’Brien (2005, p301), Decision Support Systems (DSS) merupakan sistem informasi berbasiskan komputer yang menyediakan informasi interaktif yang mendukung manajer dan bisnis profesional selama proses pembuatan keputusan.
Di buku Turban & Aroson (2001, p96) dapat dikutip beberapa definisi dari DSS:
Little (1970) mendefinisikan DSS sebagai satu set model basis yang terdiri dari prosedur untuk memproses data dan penilaian untuk membantu manajer dalam pembuatan keputusan. Dia beragumen bahwa sistem tersebut haruslah sederhana, kokoh dan mudah untuk dikontrol, adaptif, melengkapi permasalahan yang penting, dan mudah untuk dikomunikasikan.
More dan Chang (1980), mendefinisikan DSS sebagai perpanjangan sistem yang memiliki kemampuan untuk mendukung analisis data ad hoc dan pemodelan pembuatan keputusan, berorientasi kepada perancangan masa depan, dan digunakan secara tidak teratur, dan dengan interval yang tidak direncanakan.
Bonczek (1980), mendefinisikan DSS sebagai sistem berbasiskan komputer yang terdiri dari tiga komponen yang berinteraksi : language system (mekanisme yang menyediakan komunikasi diantara pengguna dan komponen lainnya di dalam DSS), knowledge systems (tempat penyimpanan pengetahuan problem domain yang dibagin di DSS sebagai data atau prosedur).
Keen (1980), mendefinisikan DSS sebagai produk dari proses pengembangan di mana pengguna DSS, pembangun DSS dan DSS itu sendiri memiliki kemampuan dalam mempengaruhi satu sama lain, memiliki hasil di dalam evolusi sistem dan pola dalam penggunaan.
Menurut Turban & Aronson (2001,p98), kapabilitas utama dari DSS adalah:
1. DSS menyediakan dukungan dalam pembuatan keputusan yang kebanyakan terdapat di situasi yang semi terstruktur atau tidak terstruktur dengan membawa bersama penilaian manusia dan informasi pada komputer. Untuk permasalahan yang tidak dapat diselesaikan (secara tepat) dengan sistem terkomputerisasi atau dengan metode kuantitatif standar atau peralatan.
2. Dukungan yang tersedia untuk bermacam tingkat manajemen, dari eksekutif tingkat atas hingga manajer biasa.
3. Mendukung penyediaan untuk individual maupun tim. Permasalahan yang kurang terstruktur sering membutuhkan campur tangan dari beberapa individual dari departemen yang berbeda dan level organisasi atau bahkan dari organisasi yang berbeda.
4. DSS menyediakan beberapa pengambilan keputusan yang saling berhubungan. Keputusannya dapat dibuat sekali, beberapa kali atau secara berulang-ulang.
5. DSS mendukung semua fase dari proses pembuatan keputusan, intelijen, perancangan, pemilihan dan pengimplementasian.
6. DSS mendukung variasi dari proses dan gaya pembuatan keputusan.
7. DSS dapat menyesuaikan dari waktu ke waktu. Pembuat keputusan harus bersifat reaktif dan dapat menghadapi perubahan kondisi secara cepat, dan dapat mengadaptasikan DSS kepada perubahan ini. DSS bersifat fleksibel, sehingga pengguna dapat menambah, menghapus dan menggabungkan, atau mengatur elemen dasarnya.
8. Pengguna harus merasa seperti di rumah dengan DSS. kemudahan dalam penggunaan, kemampuan yang baik dalam pembuatan grafik, dan kemampuan komunikasi yang baik dapat meningkatkan keefektifitasan dari DSS.
9. DSS berusaha untuk peningkatkan keefektifitasan dari pembuatan keputusan (akurasi, ketepatan waktu dan kualitas) dibandingkan efisiensi (harga dari pembuatan keputusan).
10. Pembuat keputusan harus mengontrol pada seluruh langkah dari proses pengambilan keputusan dalam menyelesaikan permasalahan. DSS khususnya. DSS secara khusus bertujuan untuk mendukung dan tidak mengantikan pembuat keputusan.
11. Pengguna harus dapat menkonstruksi dan memodifikasi sistem sederhana sendiri. Sistem yang lebih besar dapat dibangun dengan pertolongan dari spesialis sistem informasi.
12. DSS biasanya menggunakan model untuk menganalisa situasi pengambilan keputusan. Kemampuan modeling memungkinkan percobaan dengan strategi yang berbeda di dalam konfigurasi yang berbeda.
Diambil dari: Turban & Aronson (2001,p99) Gambar 2.3. Kapabilitas dari DSS
Menurut Turban & Aronson (2001, p100), aplikasi DSS terndiri dari beberapa subsistem, yaitu:
Data management subsystem
Subsistem manejemen data yang termasuknya adalah database, yang mengandung data yang relevan untuk situasi dan diatur oleh software yang disebut sebagai database management system (DBMS). Subsistem
manejemen data dapat terhubung dengan data warehouse perusahaan, yaitu tempat penyimpanan untuk perusahaan yang hal-hal yang berhubungan dengan data pembuatan keputusan.
Model management subsystem
Adalah paket software yang termasuk di dalamnya adalah keuangan, statistik, management science, atau model kuantitatif lainnya yang menyediakan kemampuan analitikal dan software menejemen yang cocok untuk perusahaan
Knowledge-based management subsystem
Subsistem ini dapat mendukung subsistem lainya atau bertindak sebagai komponen yang berdiri sendiri. Dia menyediakan ilmu untuk ditambahkan kepada keputusan yang dibuat sendiri. Dia dapat terhubung dengan tempat penyimpanan pengetauan dari perusahaan, yang disebut sebagai organizational knowledge base.
User interface subsystem
Pengguna berkomunikasi dengan perintah di DSS dengan menggunakan subsistem ini. User juga dianggap sebagai bagian dari sistem ini.
2.6. Analisa dan Perancangan Sistem Informasi Berorientasi Objek
Menurut Mathiassen et al. (2000, p3), Object Oriented Analysis and Design (OOAD) merupakan metode untuk menganalisa dan merancang suatu sistem informasi dengan menggunakan objek dan kelas sebagai konsep dasarnya.
Sedangkan menurut Whitten et al. (2004, p31), Object Oriented Analysis and Design (OOAD) merupakan kumpulan alat dan teknik untuk mengembangkan sistem dengan menggunakan teknologi objek untuk membuat sebuah sistem dan programnya.
2.6.1. Konsep Dasar Analisa dan Perancangan Berorientasi Objek
Terdapat beberapa konsep dasar dalam OOAD:
1. Objek
Menurut Lau (2001, p1), objek merupakan abstraksi baik untuk hal-hal konseptual maupun fisik. Objek memiliki keadaan dan identitas yang melekat. Objek mencapai tingkah laku tertentu melalui suatu kumpulan operasi yang didefinisikan di awal, yang mana dapat masuk atau merubah keadaannya.
Menurut Mathiassen et al. (2000, p4), objek adalah suatu entitas dengan identitas, keadaan (tingkatan hidup) dan tingkah laku. Objek merupakan dasar dalam OOAD.
2. Kelas
Menurut Mathiassen et al. (2004, p4), kelas merupakan penggambaran dari kumpulan objek yang berbagi struktur, pola sifat dan atribut.
3. Atribut
Menurut Mathiassen et al. (2000, p92 ), atribut adalah penjelasan properti dari sebuah kelas atau sebuah kejadian. Di dalam OOA (Objek Oriented Analysis), spesifikasi dari atribut adalah sebagai bagian dari kelas untuk mendefinisikan dan menjadi dasar pengertian kita dari sifat objek.
Prinsipnya adsalah dengan mengambil atribut kelas dari pola sifat.
4. Operasi
Menurut Mathiassen et al. (2000, p252), operasi adalah proses properti dispesifikasikan di dalam kelas dan diaktifkan melalui objek dari kelas tersebut.
Di dalam perancangan, kita mengimplementasikan fungsi sebagai operasi di dalam kelas-kelas. Pusat pertanyaan dari perancangan adalah:
Pengoperasian yang mana yang dibutuhkan untuk mengimplementasikan fungsi yang telah diberikan? Jawabannya didasarkan dari berbagai macam tipe fungsi. Prinsip dasar dari operasi adalah mendasari perancangan dengan tipe fungsi.
Menurut Mathiassen et al. (2000, p5), OOAD memiliki beberapa kelebihan, yaitu:
Konsep OOAD sangat cocok untuk menggambarkan fenomena dalam ruang lingkup kantor dan sistem terkomputerisasi.
OOAD memberikan informasi yang jelas mengenai context sistem.
OOAD dapat menangani data yang seragam dalam jumlah yang besar dan mendistribusikannya ke seluruh bagian organisasi.
OOAD berhubungan erat dengan analisa berorientasi objek, perancangan berorientasi objek, tampilan pengguna berorientasi objek, dan pemrograman berorientasi objek.
2.6.2. Teknik Dasar Analisa dan Perancangan Berorientasi Objek
Di dalam proses analisa dan perancangan berorientasi objek, terdapat tiga buah konsep dasar, antara lain:
1. Encapsulation
Enkapsulasi di dalam pemrograman menurut Indrajani dan Martin (2004, p11), adalah suatu mekanisme untuk menyembunyikan atau memproteksi suatu proses dari kemungkinan interferensi atau penyalahgunaan sistem itu sendiri. Akses internal sistem diatur sedemikian rupa melalui seperangkat interface.
2. Inheritance
Menurut Indrajani dan Martin (2004, p12), pewarisan merupakan suatu proses di mana suatu class diturunkan dari class lainnya sehingga ia mendapatkan ciri atau sifat dari class tersebut.
3. Polymorphism
Menurut Indrajani dan Martin (2004, p 14), polymorphism dapat diartikan sebagai sebuah konsep di mana memungkinkan untuk digunakannya suatu interface yang sama untuk memerintah suatu objek agar melakukan suatu aksi atau tindakan yang mungkin secara prinsip sama tetapi secara proses berbeda.
2.7. Aktivitas Utama Analisa dan Peracangan Berorientasi Objek
Menurut Mathiassen et al. (2000, p 14) OOAD dapat dibagi menjadi empat buah kegiatan utama, yaitu:
Analisis Problem Domain
Analisis Application Domain
Architectural Design
Component Design
Diambil dari: Mathiassen et al.(2000, p15) Gambar 2.4. Aktivitas Utama dari OOAD
2.7.1. System Definition
Menurut Mathiassen et al. (2000, p24), pada awal dari pembuatan projek, seringkali terjadi ketidakjelasan tentang hal yang paling penting dari sistem tersebut.
Perancangan sistem dimulai dengan mengumpulkan ide-ide mengenai sistem yang dibutuhkan serta mengumpulkan informasi mengenai situasi yang sedang dihadapi.
Kegiatan ini dapat disebut sebagai preliminary analysis, di mana pada tahap ini dilakukan perembukan demi tujuan pengumpulan ide mengenai sistem atau keadaan
yang ada saat ini dari berbagai sudut pandang pihak-pihak yang terlibat di dalamnya serta ide-ide berkaitan dengan sistem yang diinginkan dan dibutuhkan.
Dari hasil kegiatan tersebut didapatkan system definition. Menurut Mathiassen et al. (2000, p 24), system definition memiliki arti sebagai penggambaran singkat dari sistem terkomputerisasi yang diekspresikan dengan bahasa natural. System definition dapat digambarkan dalam bentuk rich picture dan penentuan FACTOR.
Menurut Mathiassen et al. (2000, p26) rich picture merupakan sebuah gambaran yang berisi informasi, yang menggambarkan pemahaman dari sebuah situasi. Rich picture berisi sebuah pandangan menyeluruh dari people, object process, structure, dan problem dalam system problem dan application domain. People dapat berupa system developer, user, pelanggan, atau pemain lain. Object dapat berupa banyak benda seperti mesin, dokumen, lokasi, departemen, dan yang lainnya. Process menguraikan aspek dari sebuah situasi yang berubah, tidak stabil, atau di bawah pengembangan. Secara grafik, process diilustrasikan dengan simbol panah. Structure menguraikan aspek dari sebuah situasi yang terlihat stabil atau sulit untuk diubah. Secara grafik, structure diuraikan dalam satu dari dua cara: menggambar garis antara elemen-elemen atau menempatkan elemen-elemen yang berhubungan dalam sebuah figur umum, seperti segi empat atau lingkaran.
Diambil dari : Mathiassen et al. (2000, p28) Gambar 2.5. Contoh Rich Picture
Menurut Mathiassen et al. (2000, p39), terdapat enam kritera yang ditentukan oleh FACTOR:
Functionality. Fungsi dari sistem yang mendukung kegiatan dalam application domain.
Application domain. Bagian dari organisasi yang mengatur, mengawasi dan mengontrol problem domain.
Conditions. Kondisi di mana sistem akan dikembangkan dan digunakan.
Technology. Teknologi yang digunakan baik untuk mengembangkan sistem dan juga teknologi yang memungkinkan dan mendukung jalannya sistem.
Objects. Objek utama dalam problem domain.
Responsibility. Tanggung jawab sistem secara keseluruhan dalam hubungannya dengan konteksnya.
Mathiassen et al. (2000, p40) juga menyataan bahwa FACTOR dapat digunakan dalam dua cara. Yang pertama adalah FACTOR dapat digunakan untuk mendukung kegiatan pembuatan system definition, di mana keenam kriteria FACTOR dipertimbangkan formulasinya. Pada tahap ini, FACTOR terlebih dahulu didefinisikan baru kemudian ditentukan system definitionnya. Cara kedua adalah dengan mendefinisikan terlebih dahulu system definition dan kemudian menggunakan keenam kriteria FACTOR untuk mengetahui bagaimana system definition yang dibuat telah memenuhi keenam faktor tersebut.
2.7.2. Analisis Problem Domain
Problem domain merupakan bagian dari situasi yang diatur, diawasi, dan dikendalikan oleh sistem. Tujuan melakukan analisa problem domain adalah mengidentifikasi dan memodelkan problem domain. Mathiassen et al (2000, p46).
Menurut Mathiassen et al (2000, p46), analisis problem domain terbagi menjadi tiga aktivitas, yaitu:
Memilih objek, kelas dan event yang akan menjadi elemen model problem domain.
Membangun model dengan memusatkan perhatian pada relasi struktural antara kelas dan objek.
Mendiskripsikan properti dinamis dan atribut untuk setiap kelas.
Diambil dari: Mathiassen et al. (2000, p46) Gambar 2.6. Aktivitas Analisis Problem Domain
2.7.2.1. Aktivitas Classes
Pada aktivitas classes, langkah aktivitas awal yang perlu dilakukan adalah menentukan class candidates. Class akan menggambarkan objek-objek dan event-event yang mana saja yang akan menjadi bagian dari problem domain. Kemudian dari kandidat class yang telah dipilih, ditentukan mana yang akan mnejadi class dalam sistem.
Langkah berikutnya adalah membuat sebuah event candidates. Setelah itu, event candidates kemudian dipilih mana event yang akan menjadi event dari tiap class, dan dibuatlah event table yang dapat membantu menentukan event-event yang dimiliki oleh setiap class. Subaktivitas dalam memilih classes dan events pada problem domain ditunjukan pada gambari di bawah ini. Mathiassen (2000, p55)
Diambil dari : Mathiassen et al. (2000, p55)
Gambar 2.7. Subaktivitas Pemilihan Problem Domain classes & events
Menurut Mathiasses et al. (2000, p57), penggunaan nama kelas sebaiknya :
Sederhana dan mudah dimengerti
Sesuai dengan problem domain
Menunjukan satu kejadian
2.7.2.2. Aktivitas Structure
Pada akivitas structure, class-class yang telah ditentukan sebelumnya akan dihubungkan berdasarkan tiga jenis hubungan yaitu: generalisasi, agregasi atau asosiasi sehingga menjadi sebuah skema yang disebut class diagram. Subaktivitas dalam pemodelan structure pada problem domain ditunjukan pada gambar di bawa ini.
Mathiassen et al. (2000, p72).
Diambil dari: Mathiassen et al. (2000, p72)
Gambar 2.8. Subaktivitas Pemodelan Problem Domain structure
2.7.2.3. Aktivitas Behaviour
Dan pada aktivitas behavior, definisi class dalam class diagram akan diperluas dengan menambahkan deskripsi pola perilaku dan atribut dari masing-masing kelas.
Subaktivitas dalam pemodelan behaviour dari objek ditunjukan pada gambar di bawah ini. Mathiassen et al. (2000, p89).
Diambil dari: Mathiassen et al. (2000, p92) Gambar 2.9. Subaktivitas Pemodelan object-behaviour
Menurut Mathiassen et al. (2000, p93), terdapat pola perilaku dari kelas dan terdiri dari tiga jenis, yaitu:
sequence: event yang terjadi secara berurutan satu per satu.
Selection: pemilihan salah satu dari beberapa event yang terjadi.
Iteration: event yang terjadi berulang kali.
Hasil dari aktivitas behaviour adalah sebuah statechart diagram yang menunjukkan perubahan status dari masing-masing class yang dikarenakan oleh event tertentu mulai dari initial state sampai dengan final state.
2.7.3. Analisis Application Domain
Application domain merupakan organisasi yang mengatur, mengawasi, atau mengendalikan problem domain. Tujuan dilakukannya analisa application domain adalah untuk menentukan kebutuhan penggunaan sistem. Mathiassen et al. (2000, p115).
Analisis application domain terdiri dari beberapa aktivitas antara lain:
Menentukan penggunaan sistem dan bagaimana sistem berinteraksi dengan user.
Menentukan fungsi dan kemampuan sistem dalam mengolah informasi.
Menentukan kebutuhan interface sistem dan merancang interface.
Berikut ini merupakan gambaran aktivitas-aktivitas yang dilakukan pada saat melakukan analisis application domain.
Diambil dari: Mathiassen et al. (2000, p117) Gambar 2.10. Aktivitas Analisis Application Domain
2.7.3.1. Aktivitas Usage
Di dalam aktivitas usage, hal pertama yang harus dilakukan adalah membuat actor table yang dapat membantu menentukan actor dan use case yang berkaitan.
Langkah selanjutnya adalah membuat use case diagram sehingga interaksi antar actor dengan masing-masing use case terlihat lebih jelas. Subaktivitas usage ditunjukan pada gambar di bawah ini. Mathiassen et al. (2000, p 119).
Diambil dari: Mathiassen et al. (2000, p120) Gambar 2.11. Subaktivitas dari Usage
2.7.3.2. Aktivitas Function
Function merupakan fasilitas sistem yang menjadikan sistem tersebut berguna bagi actor. Subaktivitas dari analisa function ditunjukan pada gambar di bawah ini.
Mathinassen et al. (2000, p139).
Diambil dari: Mathiassen et al. (2000, p139) Gambar 2.12. Subaktivitas dari Analisis Function
Menurut Mathiassen et al. (2000, p138), function terdiri dari empat jenis, yaitu:
Update : fungsi update diaktifkan oleh event problem domain dan menghasilkan perubahan status model.
Signal : fungsi signal diaktifkan oleh perubahan status model dan menghasilkan reaksi di dalam context.
Read : fungsi read diaktifkan oleh kebutuhan actor akan informasi dan menghasilkan tampilan model sistem yang relevan.
Compute : fungsi compute diaktifkan oleh kebutuhan actor akan informasi dan berisi perhitungan yang dilakukan baik oleh actor maupun oleh model. Hasilnya adalah tampilan dari hasil perhitungan yang dilakukan.
2.7.3.3. Aktivitas Interface
Aktivitas interface mencakup pembuatan navigation diagram yang merupakan skema yang menunjukkan tampilan dari sistem dan relasi antar interface. Subaktivitas analisis interface ditunjukan pada gambar di bawah ini. Mathiassen et al.(2000, p159).
Diambil dari: Mathiassen et al. (2000, p153) Gambar 2.13. Subaktivitas dari Analisis Interface
Manurut Mathiassen et al. (2000, p151), interface adalah fasilitas yang membuat system model dan functions dapat digunakan oleh actor. Tujuannya adalah untuk menetapkan system interfaces. Hasil dari interfaces adalah:
User interface : Tipe dialog dan form presentasi, daftar lengkap dari elemen user interface, window diagram dan navigation diagram.
System interface: Class diagram untuk peralatan luar dan protokol- protokol untuk berinteraksi dengan sistem lain.
2.7.4. Architectural Design
Architectural design berfungsi sebagai kerangka kerja dalam aktivitas pengembangan sistem serta menghasilkan struktur komponen dan proses sistem. Tujuan dari architectural design adalah untuk menstrukturisasi sebuah sistem yang terkomputerisasi. Mathiassen et al. (2000, p173).
Menurut Mathiassen et al. (2000, p175), tahap dari architectural design terdiri dari tiga aktivitas:
criteria component architecture
component architecture
process architecture
Diambil dari: Mathiassen et al. (2000, p176) Gambar 2.14. Aktivitas Architectural Design
2.7.4.1. Aktivitas Criteria
Criteria merupakan properti yang dipilih dan diinginkan dari sebuah arsitektur.
Tabel di bawah ini menunjukan criterion yang telah ditentukan oleh para peneliti untuk menentukan kualitas dari sebuah perangkat lunak (software). Mathiassen et al. (2000, p177)
Diambil dari: Mathiassen et al. (2000, p179) Gambar 2.15. Determinasi kriteria dalam perancangan
Tabel 2.1. Kriteria Klasik untuk Menentukan Kualitas Software
Criterion Measure of
Usable Kemampuan sistem beradaptasi dengan context
organisasional dan teknikal.
Secure Pencegahan akses ilegal terhadap data dan fasilitas.
Efficient Eksploitasi ekonomis dari fasilitas technical platform.
Correct Kesesuaian dengan kebutuhan.
Reliable Fungsi yang dijalankan secara tepat.
Maintainable Biaya untuk mencari dan memperbaiki kerusakan sistem.
Testable Biaya untuk menjamin bahwa sistem melakukan fungsinya.
Flexible Biaya memodifikasi sistem.
Comprehensible Usaha yang diperlukan untuk memahami sistem.
Reusable Penggunaan bagian dari sistem ke dalam sistem lain yang berkaitan.
Portable Biaya memindahkan sistem ke technical platform lain.
Interoperable Biaya pemasangan sistem dengan sistem lain.
Mathiassesn et al. (2000, p179) menyebutkan bahwa kriteria useable, flexible, dan comprehensible tergolong sebagai kriteria umum yang harus dimiliki oleh sebuah sistem dan menentukan baik tidaknya suatu rancangan sistem.
2.7.4.2. Aktivitas Component Architecture
Component architecture adalah struktur sistem dari komponen-komponen yang berkaitan. Mathiassen et al.(2000, p189).Subaktivitas dari perancangan komponen arsitektur ditunjukan pada gambar di bawah ini.
Diambil dari: Mathiassen et al. (2000, p192)
Gambar 2.16. Subaktivitas dalam perancangan komponen arsitektur
Di dalam aktivitas ini, perlu ditentukan pola arsitektural yang paling sesuai dengan model sistem. Mathiassen et al.(2000, p193).Pola-pola tersebut, yaitu:
Layered Achitecture Pattern
Arsitektur ini memiliki beberapa komponen yang dirancang dalam bentul lapisan-lapisan di mana terdapat antarmuka atas dan bawah. Antarmua atas mendeskripsikan operasi yang disediakan oleh komponen-komponen di lapisan atas sementara antarmuka bawah mendeskripsikan operasi yang dapat diakses oleh komponen dari lapisan di bawahnya.
Generic Architecture Pattern
Arsitektur ini terdiri model sistem yang terletak di lapisan paling bawah, diikuti dengan function di atasnya dan kemudian interface di lapisan teratas. Perangkat teknis bisa diletakkan di bawah model di mana perangkat teknis ini terhubung dengan model dan interface.
Client-server Architecture Pattern
Pattern ini dibangun untuk mengatasi sistem yang terdistribusi di beberapa proses yang tersebar. Arsitektur ini terdiri dari sebuah server dan beberapa client. Server memiliki kumpulan operation yang dapat digunakan oleh client. Client menggunakan server secara indenpenden.
Bentuk distribusi dari bagian sistem harus diputuskan antara client dan server. Identifikasi komponen di dalam perancangan sistem atau subsistem, pada umumnya memulai dengan layer architecture yang menggunakan interface, function, dan model component.
Client-server Architecture dibagi menjadi beberapa bentuk yang berbeda, yang dijelaskan pada tabel di bawah ini.
Tabel 2.2. Jenis Arsitektur Client-Server
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
2.7.4.3. Aktivitas Process Architecture
Proses architecture adalah sebuah strutur eksekusi sistem yang terdiri dari proses-proses yang saling tergantung satu sama lain. Subaktivitas dari process architectecture design ditunjukan pada gambar di bawah ini. Mathiassen et al. (2000, p 209).
Diambil dari: Mathiassen et al. (2000, p212) Gambar 2.17. Subaktivitas dalam proses architecuture design.
Menurut Mathiassen et al. (2000, p215), dalam aktivitas ini juga perlu menentukan pola distribusi yang sesuai dengan model siste. Pola-pola distribusi tersebut, antara lain:
Centralized Pattern
Distributed Pattern
Decentralized Pattern
Hasil dari aktivitas ini adalah sebuah deployment diagram yang menunjukan processor dengan komponen program dan active objects.
2.7.5. Component Design
Component design bertujuan untukmenentukan implementasi kebutuhan di dalam kerangka kerja arsitektural. Hasil dari component design adalah desktripsi mengenai komponen-komponen sistem. Mathiassen et al. (2000, 231).
Berikut ini adalah gambar yang menunjukan component design.
Diambil dari: Mathiassen et al. (2000, p232) Gambar 2.18. Component Design
Component design terdiri dari tiga aktivitas, yaitu:
1. Aktivitas Model Component 2. Aktivitas Function Component 3. Aktivitas Connecting Component
2.7.5.1. Aktivitas Model Component
Merupakan bagian sistem yang mengimplementasikan model problem domain.
Dalam aktivitas ini dihasilkan sebuah class diagram yang telah direvisi. Berikut ini adalah gambar yang menunjukkan subaktivitas dari model component design.
Mathiassen et al. (2000, 235).
Diambil dari: Mathiassen et al. (2000, p239) Gambar 2.19. Subaktivitas Model Component design
2.7.5.2. Aktivitas Function Component
Merupakan bagian sistem yang mengimplementasikan kebutuhan fungsional.
Gambar di bawah ini menunjukkan subaktivitas dari function component design.
Mathiassen et al. (2000, p251).
Diambil dari: Mathiassen et al. (2000, p252) Gambar 2.20. Subaktivitas Function Component Design
Hasil dari aktivitas ini adalah class diagram dengan operasi dan fungsi-fungsinya.
2.7.5.3. Aktivitas Connecting Component
Merupakan perancangan hubungan antar komponen untuk memperoleh rancangan yang fleksibel dan mudah dimengerti. Mathiassen et al.(2000, p271).
Diambil dari: Mathiassen et al. (2000, p274)
Gambar 2.21. Subaktivitas Perancangan Hubungan antar Komponen
Hasil dari aktivitas ini adalah class diagram yang berhubungan dengan komponen-komponen sistem.
2.8. Unified Modeling Language (UML)
Menurut Roff (2003, p5), UML adalah sebuah bahasa untuk memodelkan sebuah sistem. Dalam penggunaan UML, perlu untuk menambahkan metoda ke dalamnya. Ada beberapa metode yang telah dirancang, tetapi yang paling terkenal dan mungkin yang pertama kali berurusan dengan UML adalah Rational Unified Process (RUP), yang biasa disebut sebagai Unified Process.
Menurut Whitten et al. (2004, p430), UML atau Unified Modeling Language adalah satu set konvensi pemodelan yang digunakan untuk menggambarkan atau menspesifikasikan sebuah sistem software dalam bentuk objek – objek. UML bukanlah suatu metode untuk pengembangan sistem, melainkan hanya notasi yang berisi diagram standard yang digunakan untuk mengembangkan OOAD (Object Oriented Analysis and Design).
Menurut Roff (2003, p7), sebuah proses pengembangan software adalah satu kumpulan dari fase yang memungkinkan sebuah produk menjadi ada. Terdapat 4 fase proses tersebut di dalam Unified Process, yaitu:
Inception
Mendefinisikan sistem yang hendak dikembangkan, termasuk yang berada dan permasalahan dalam bisnis tersebut.
Elaboration
Menampilkan rancangan detail dan mengidentifikasi dasar dari sistem.
Construction
Menulis softwarenya.
Transition
Mengirimkan sistem ke pengguna, biasanya disebut sebagai rolling out.
Menurut Roff (2003, p9), sejarah dari terbentuknya UML berasal dari penggabungan Grady Booch dan Jim Rumbaugh menjadi satu team dan menciptakan notasi baru di tahun 1994. Mereka menawarkan metode perancangan mereka, yaitu metode Booch dan Object Modeling Technique (OMT). Di tahun 1995, Dr. Ivar Jacobson bergabung dengan mereka dan menawarkan metode baru, Object Oriented Software Engineering (OOSE). Mereka berkerjasama untuk menentukan UML dan membuat standarisasi di dalam pembuatan model untuk objek. UML pertama yang digunakan adalah UML 0.8. Setelah dilakukan penyebaran, maka ketiga orang tersbut meminta masukan dari pihak luar atas hasil kerja mereka. Di tahun 1995, perjanjian telah dibuat oleh Object Management Group (OMG) untuk mestandarisasikan UML.
Pada tahun 1997 UML 1.0 dijadikan standard. Untuk saat ini yang biasa digunakan adalah UML 1.4, tetapi UML 2.0 sudah akan diresmikan di masa yang akan datang.
2.9. Diagram dalam Analisa dan Perancangan Berorientasi Objek
2.9.1. Class Diagram
Mathiassen et al. (2000, p336), menjelaskan bahwa class diagram adalah gambaran struktur objek dari sistem. Class diagram menunjukan kelas objek yang membentuk sistem dan hubungan struktural diantara kelas objek tersebut. Sedangkan menurut Whitten et al. (2004, p455), menyatakan bahwa class diagram adalah gambaran secara grafis dari sistem statis struktur objek, yang menunjukkan objek dari kelas dari sistem yang dihubungkan antara objek dari kelas tersebut.
Menurut Whitten et al. (2004, p455), terdapat tiga jenis hubungan antar kelas yang biasa digunakan dalam class diagram, yaitu:
1. Asosiasi dan multiplicity
Asosiasi merupakan hubungan statis antar dua objek atau kelas.
Hubungan ini menggambarkan apa yang perlu diketahui oleh sebuah kelas mengenai kelas lainnya. Hubungan ini memungkinkan sebuah objek atau kelas mereferensikan objek atau kelas lain dan saling mengirimkan pesan. Sedangkan multiplicity adalah notasi yang menjelaskan hubungan antara kelas yang telah dihubungkan tersebut.
Sumber: Whitten et al. (2004, p461)
Gambar 2.22. Contoh Hubungan Asosiasi dan Multiplicity 2. Generalisasi atau spesialisasi
Dalam hubungan generaslisasi, terdapat dua jenis kelas, yaitu kelas supertype dan kelas subtype. Kelas supertype atau kelas induk memiliki atribut dan behavior yang umum dari hirarki tersebut. Kelas subtype atau kelas anak memiliki atribut dan behavior yang unik dan juga memiliki atribut dan behavior milik kelas induknya. Kelas induknya merupakan
generalisasi dari kelas anaknya, sedangkan kelas anak merupakan spesialisasi dari kelas induknya.
Sumber: Whitten et al. (2004, p434) Gambar 2.23. Contoh Hubungan Generalisasi
3. Agregasi
Agregasi merupakan hubungan yang unik di mana sebuah objek merupakan bagian dari objek lain. Hubungan agregasi adalah hubungan tidak simetrik, di mana jika objek B merupakan bagian dari objek A, tetapi objek A bukan merupakan bagian dari objek B. Pada hubungan ini, objek yang menjadi bagian dari objek tertentu tidak akan memiliki atribut atau behavior dari objek tersebut (berbeda dari generalisasi).
Sumber: Whitten et al. (2004, p439) Gambar 2.24. Contoh Hubungan Agregasi
Sumber: Whitten et al. (2004, p461) Gambar 2.25. Contoh Class Diagram
2.9.2. Statechart Diagram
Menurut Whitten et al. (2004, p700) statechart diagram merupakan sebuah diagram UML yang menjelaskan kombinasi dari status objek dalam siklus hidupnya, yang dipicu oleh event sehingga status dapat berubah – ubah.
Sedangkan Mathiassen et al. (2000, p341), menguraikan bahwa Statechart Diagram merupakan pemodelan perilaku dinamis dari sebuah objek dalam sebuah class yang spesifik dan berisi state dan transition.
Whitten et al. (2004, p700), menguraikan langkah-langkah pembuatan Statechart diagram adalah sebagai berikut:
1. Mengidentifikasi initial dan final state
2. Mengidentifikasi status objek selama masa hidup objek tersebut 3. Mengidentifikasi event pemicu perubahan status objek
4. Mengidentifikasi jalur perubahan status.
Sumber: Mathiassen et al. (2004, p358) Gambar 2.26. Contoh Statechart Diagram
2.9.3. Use case Diagram
Menurut Whitten et al. (2004, p441), use case diagram merupakan gambaran interaksi antara sistem dan user. Sedangkan Mathiassen et al. (2000, p343) menyatakan bahwa use case diagram adalah deskripsi secara grafis yang menggambarkan hubungan antara actors dan use case. Penjelasan use case biasa ditambahkan untuk menjelaskan langkah-langkah interaksi.
obtain customer
Deposit
deposit
cash withdrawal
Customer establishment Bank employee
Loan
maintain
payments
Sumber: Mathiassen et al. (2000, p129) Gambar 2.27. Contoh Use Case Diagram
Setelah pembuatan use case diagram, kemudian dilanjutkan dengan narasi dari masing-masing use case. Narasi dari masing-masing use case ditujukan sebagai dokumentasi mengenai apa yang harus dilakukan oleh actor terhadap sistem (actor action) dan bagaimana sistem merenspon tindakan actor (system respons). Selain itu, narasi tersebut juga menggambarkan hubungan antara actor dengan objek dalam suatu
use case. Jadi, secara keseluruhan, use case specification merupakan penggambaran secara rinci dari setiap use case yang telah digambarkan dalam use case diagram.
Berikut ini adalah contoh dari pembuatan dokumentasi dari masing-masing use case, atau yang biasa disebut sebagai use case specification.
2.9.4. Sequence Diagram
Bennett et al. (2006, p253) mengemukakan bahwa sequence diagram menunjukkan interaksi antar objek yang diatur berdasarkan urutan waktu. Sequence diagram dapat digambarkan dalam berbagai level of detail yang berbeda untuk memenuhi tujuan yang berbeda-beda pula dalam daur hidup pengembangan sistem.
Aplikasi sequence diagram yang paling umum adalah untuk menggambarkan interaksi antar objek yang terjadi pada sebuah use case atau sebuah operation.
Menurut Roff (2003, p13), Sequence Diagram biasanya digunakan untuk menunjukan interaksi antara aktor dan objek dan objek lainnya. Pesan-pesan dikirim dari aktor ke objek, dari objek ke objek, dan dari objek ke aktor untuk menunjukkan aliran pengontrolan dari sistem. Sequence diagram digunakan untuk merealisasikan use case- use case dengan mendokumentasikan bagaimana use case diselesaikan dengan menggunakan rancangan sistem yang sekarang. Model sequence diagram merupakan interaksi diantara instansi kelas high level. dengan memberi detail lebih lanjut mengenai proses kontrol yang ada di setiap tingkatan dari proses komunikasi. Sequence diagram dapat digunakan untuk menunjukan seluruh jalan yang memungkinkan terjadi di dalam interaksi, atau menunjukan jalan melalui interaksi.
Menurut Roff (2003, p96), terdapat 4 macam pesan di dalam sequence diagram, yaitu:
Synchronous
Menandakan aliran akan terus ada sampai pesanya selesai tersampaikan.
Return
Memberikan gambaran bahwa aliran kontrol dari pemanggilan objek yang dilakukan telah dikembalikan.
Asynchronous
Menggunakan untuk mengirimkan pesan tetapi dari objek yang aktiv yang tidak menunggu tanggapan.
Flat
Antara synchronous dan asynchronous.
Diambil dari Roff (2003, p96)
Gambar 2.28. Tipe Pesan dalam Sequence Diagram
Bennet et al. (2006, pp253-254) menyatakan bahwa setiap sequence diagram harus diberikan frame yang memiliki heading dengan menggunakan notasi sd yang merupakan kependekan dari sequence diagram. Bennett et al. (2006, p270) juga
menyatakan bahwa terdapat beberapa notasi penulisan heading pada setiap frame yang terdapat dalam sequence diagram, antara lain:
alt
Notasi alt merupakan kependekan dari alternatives yang menyatakan bahwa terdapat beberapa buah alternatif jalur eksekusi untuk dijalankan.
opt
Notasi opt merupakan kependekan dari optional dimana frame yang memiliki heading ini memiliki status pilihan yang akan dijalankan jika syarat tertentu dipenuhi.
loop
Notasi loop menyatakan bahwa operation yang terdapat dalam frame tersebut dijalankan secara berulang selama kondisi tertentu.
break
Notasi break mengindikasikan bahwa semua operation yang berada setelah frame tersebut tidak dijalankan.
par
Merupakan kependekan dari parallel yang mengindikasikan bahwa operation dalam frame tersebut dijalankan secara bersamaan.
seq
Notasi seq merupakan kependekan dari weak sequencing yang berarti operation yang berasal dari lifeline yang berbeda dapat terjadi pada urutan manapun.
strict
Notasi strict merupakan kependekan dari strict sequencing yang menyatakan bahwa operation harus dilakukan secara berurutan.
neg
Notasi neg merupakan kependekan dari negative yang mendeskripsikan operasi yang tidak valid.
critical
Frame yang memiliki heading critical menyatakan bahwa operasi-operasi yang terdapat di dalamnya tidak memiliki sela yang kosong.
ignore
Notasi ini mengindikasikan bahwa tipe pesan atau parameter yang dikirimkan dapat diabaikan dalam interaksi.
consider
Consider menyatakan pesan mana yang harus dipertimbangkan dalam interaksi.
assert
Merupakan kependekan dari assertion yang menyatakan urutan pesan yang valid.
ref
Notasi ref merupakan kependekan dari refer yang menyatakan bahwa frame mereferensikan operation yang terdapat di dalamnya pada sebuah sequence diagram tertentu.
Sumber: Bennett et al. (2006, p254) Gambar 2.29. Contoh Sequence Diagram
2.9.5. Navigation Diagram
Menurut Mathiassen et al. (2000, p344) navigation diagram merupakan statechart diagram khusus yang berfokus pada user interface. Diagram ini menunjukkan window–window serta transisi di antara window–window tersebut.
Sebuah window dapat digambarkan sebagai sebuah state. State ini memiliki nama dan berisi gambar miniatur window. Transisi antar state dipicu oleh ditekannya sebuah tombol yang menghubungkan dua window.
Sumber: Mathiassen et al. (2000, p366) Gambar 2.30. Contoh Navigation Diagram
2.9.6. Component Diagram
Menurut Whitten et al. (2004, p442) component diagram merupakan diagram implementasi yang digunakan untuk menggambarkan arsitektur fisik dari software sistem. Diagram ini dapat menunjukkan bagaimana coding pemrograman terbagi menjadi komponen-komponen dan juga menunjukkan ketergantungan antar komponen tersebut. Sedangkan menurut Mathiassen et al. (2000, p190), component diagram adalah sebuah diagram yang menjelaskan hubungan antara komponen. Komponen itu sendiri
Sumber: Bennett et al. (2006, p254) Gambar 2.29. Contoh Sequence Diagram
2.9.5. Navigation Diagram
Menurut Mathiassen et al. (2000, p344) navigation diagram merupakan statechart diagram khusus yang berfokus pada user interface. Diagram ini menunjukkan window–window serta transisi di antara window–window tersebut.
Sebuah window dapat digambarkan sebagai sebuah state. State ini memiliki nama dan berisi gambar miniatur window. Transisi antar state dipicu oleh ditekannya sebuah tombol yang menghubungkan dua window.
