bab 2 landasan teori 2.1. teknik industri -...

BAB 2

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

24

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.

25

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.

26

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.

27

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.

28

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

29

deviasi ini kemudian dibandingkan dengan menggunakan

“Percent Error in the Variations” atau E2, dengan rumus sebagai

berikut:

aSaSsS

2E−

=

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.

30

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

31

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.

32

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:

33

)2σ(xμ2y

)1σ(xμ1y

)2sin(2πi)12ln(R2x

)2cos(2πo)12ln(R1x

+=

+=

×−=

×−=

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.

34

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:

35

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.

36

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%

37

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.

38

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.

39

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.

40

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

41

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:

42

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.

43

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.

44

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:

45

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.

46

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.

47

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.

48

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.

49

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

50

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.

51

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.

52

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.

53

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:

54

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

55

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.

56

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.

57

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.

58

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)

59

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

60


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


Gambar 2.9. Subaktivitas Pemodelan object-behaviour

61

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.

62


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


Gambar 2.11. Subaktivitas dari Usage

63

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


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.

64

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


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.

65

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


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)

66


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.

67

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.


Gambar 2.16. Subaktivitas dalam perancangan komponen arsitektur

68

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.

69

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


Gambar 2.17. Subaktivitas dalam proses architecuture design.

70

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.


Gambar 2.18. Component Design

71

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


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

72


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


Gambar 2.21. Subaktivitas Perancangan Hubungan antar Komponen

Hasil dari aktivitas ini adalah class diagram yang berhubungan dengan

komponen-komponen sistem.

73

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.

74

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.

75

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

76

generalisasi dari kelas anaknya, sedangkan kelas anak merupakan

spesialisasi dari kelas induknya.


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

77


Gambar 2.24. Contoh Hubungan Agregasi


Gambar 2.25. Contoh Class Diagram

78

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

79

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 Bank employeeestablishment

Loan

maintain

payments


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

80

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.

81

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

82

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.

83

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.

84

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.

85


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

84

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.

86

adalah sebuah kumpulan yang berisi bagian–bagian program yang dibentuk dalam satu

kumpulan dan memiliki tanggung jawab.

Sebuah komponen digambarkan dalam UML sebagai sebuah kotak dengan dua

kotak kecil di sebelah kirinya. Ketergantungan antar dua komponen menunjukkan

bagaimana kedua komponen tersebut saling berkomunikasi.


Gambar 2.31. Contoh Component Diagram

2.9.7. Deployment Diagram

Menurut Mathiassen et al. (2000, p340), deployment diagram menunjukkan

konfigurasi sistem dalam bentuk processor dan objek yang terhubung dengan processor

tersebut. Sedangkan menurut Whitten et al. (2004, p442) deployment diagram

merupakan diagram implementasi yang menggambarkan arsitektur fisik sistem.

Deployment diagram tidak hanya menggambarkan arsitektur fisik software saja,

melainkan software dan hardware. Diagram ini menggambarkan komponen software,

processor, dan peralatan lain yang melengkapi arsitektur sistem

87

Setiap kotak dalam deployment diagram menggambarkan sebuah node yang

menunjukkan sebuah hardware. Hardware dapat berupa PC, mainframe, printer, atau

bahkan sensor. Software yang terdapat di dalam node digambarkan dengan simbol

komponen. Garis yang menghubungkan node menunjukkan jalur komunikasi antar

device.


Gambar 2.32. Contoh Deployment Diagram

2.10. Software Pendukung

2.10.1. Eclipse

Eclipse merupakan komunitas open source yang projeknya berfokus pada

membangun platform pengembangan yang lebih tinggi, baik di bidang pembangunan

rancangan kerja, tapi juga di pembangunan dan pengaturan software di dalam

keseluruhan lingkaran kehidupan software. Pada umumnya diketahui sebagai IDE

(Integrated Development Environment) Java, tapi bisa juga digunakan untuk bahasa

pemrograman lain seperti : C/C++, Cobol, Phyton, Perl, PHP, dll. Diambil dari :

88

http://en.wikipedia.org/wiki/Eclipse_java

http://www.eclipse.org/home/newcomers.php )

2.10.2. Oracle 10g

Oracle Database atau biasa disebut Oracle teridri dari sistem manajemen

database relasional yang diproduksi dan dipasarkan oleh Oracle Corporation.

Oracle 10g merukan versi dari software Oracle yang diluncurkan pada tahun 2007.

Diambil dari : http://en.wikipedia.org/wiki/Oracle_Database

2.10.3. Poseidon for UML

Poseidon for UML adalah software aplikasi yang digunakan untuk membuat

model dengan UML. Pada awalnya berasal dari proyek ArgoUML, lalu berkembang

menjadi proyek komersial yang memiliki perbedaan yang sangat besar sehingga

namanya dirubah.

Proyek yang dibuat dari Poseidon dapat berdiri sendiri dari proyek Eclipse, tetapi

tetap memiliki hubungan yang dekat. Proyek dari poseidon dapat disimpan sebagai

bagian dari proyek Eclipse, tetapi file .zuml dapat dibuka dan di-edit seperti berdiri

sendiri. Setiap proyek Eclipse dapat memiliki satu proyek Poseidon.

Karena proyek Poseidon merupakan bagian dari proyek Eclipse, maka sumber

direktori yang digunakan di Eclipse dapat menjadi sumber direktori yang digunakan di

Poseidon. Diambil dari : http://en.wikipedia.org/wiki/Poseidon_for_uml dan

http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon_users_guide/

startposeidonineclipse.html

bab 2 landasan teori 2.1. teknik industri -...

Documents