BAB 3
LANDASAN TEORI
3.1 Pengertian Kualitas
Salah satu faktor yang paling utama untuk menentukan kinerja dari suatu
perusahaan adalah kualitas dari produk dan jasa yang dihasilkan perusahaan
tersebut. Selain itu kualitas juga berpengaruh terhadap daya minat konsumen
terhadap produk dan jasa tersebut.
Gasperz (1998,p1) mendefinisikan kualitas sebagai konsistensi
peningkatan atau perbaikan dan penurunan variasi karakteristik dari suatu produk
(barang/jasa) yang dihasilkan, agar memenuhi kebutuhan yang telah
dispesifikasikan guna meningkatkan kepuasan pelanggan internal maupun
eksternal.
Spesifikasi dan toleransi yang ditetapkan oleh bagian desain produk yang
disebut sebagai kualitas desain (quality of design) harus berorientasi kepada
kebutuhan atau keinginan konsumen (orientasi pasar).
3.2 Performansi Kualitas
Pada dasarnya performansi kualitas dapat ditentukan dan diukur
berdasarkan karakteristik kualitas yang terdiri dari beberapa sifat atau dimensi
sebagai berikut : Gasperz (1998,p5)
• Fisik : panjang, berat, diameter, tegangan, kekentalan, dll.
16
• Sensory (berkaitan dengan panca indera) : rasa, penampilan, bentuk, warna,
dll.
• Orientasi waktu : keandalan (reliability), kemampuan pelayanan
(serviceability), kemudahan pemeliharaan (mantainability), dll.
• Orientasi biaya : berkaitan dengan dimensi biaya yang menggambarkan harga
atau ongkos dari suatu produk yang harus dibayarkan oleh konsumen.
Gasperz (1998,p6) Pengukuran performansi kualitas dapat dilakukan
pada tiga tingkat, yaitu:
• Pengukuran pada tingkat proses
Mengukur setiap langkah atau aktivitas dalam proses dan karakteristik input
yang diserahkan oleh supplier yang mengendalikan karakteristik outputyang
diinginkan.tujuan dari pengukuran pada tingkat ini adalah mengidentifikasi
perilaku yang mengatur setiap langkah dalam proses, dan menggunakan
ukuran – ukuran ini untuk mengendalikan operasi serta memperkirakan
output yang akan dihasilkan sebelum output itu diproduksi atau diserahkan
ke pelanggan.
• Pengukuran pada tingkat output
Mengukur karakteristik output yang dihasilkan dibandingkan terhadap
spesifikasi karakteristik yang diinginkan pelanggan. Misalnya mengukur
tingkat karakteristik kualitas dari produk yang dihasilkan.
• Pengukuran pada tingkat outcome
Mengukur bagaimana baiknya suatu produk memenuhi kebutuhan dan
ekspektasi pelanggan, mengukur tingkat kepuasan pelanggan dalam
17
mengkonsumsi produk yang diserahkan. Pengukuran pada tingkat outcome
merupakan tingkat tertinggi dalam pengukuran performansi kualitas.
Misalnya mengukur banyaknya keluhan yang diterima dari pelanggan.
3.3 Definisi Statistical Process Control (SPC)
Menurut Gasperz (1998, p1) Statistical Process Control adalah suatu
terminology yang mulai digunakan sejak tahun1970-an untuk menjabarkan
penggunaan teknik – teknik statistical dalam memantau dan meningkatkan
performansi proses menghasilkan produk berkualitas.
Berdasarkan uraian diatas SPC dapat didefinisikan sebagai suatu
metodologi pengumpulan dan analisis data kualitas, serta penentuan dan
interpretasi pengukuran – pengukuran yang menjelaskan tentang proses dalam
suatu system industri, untuk meningkatkan kualitas dari output guna memenuhi
kebutuhan dan ekspektasi pelanggan.
. Sasaran utama dari Statistical Process Control adalah mengadakan
pengurangan terhadap variasi atau kesalahan-kesalahan proses. Selain itu, tujuan
utama dari Statistical Process Control adalah mendeteksi adanya penyebab
khusus (assignable cause atau special cause) dalam variasi atau kesalahan proses
melalui analisis data dari masa lalu maupun masa mendatang. Variasi proses
sendiri terdiri dari dua macam penyebab, yaitu penyebab umum (random cause
atau chance cause atau common cause) yang sudah melekat pada proses, dan
penyebab khusus (assignable cause atau special cause) yang merupakan
kesalahan yang berlebihan.
18
3.4 Definisi Variasi dalam SPC
Berdasarkan Gaspersz (1998, p29) Variasi adalah ketidakseragaman
dalam sistem produksi atau operasional sehingga meinmbulkan perbedaan dalam
kualitas pada output barang / jasa yang dihasilkan. Pada dasarnya dikenal dua
sumber atau penyebab timbulnya variasi yang diklasifikasikan sebagai berikut :
1. Variasi penyebab khusus (Special cause variation)
Adalah kejadian – kejadian di luar sistem yang mempengaruhi variasi
dalam sistem. Penyebab khusus dapat bersumber dari faktor – faktor
manusia, peralatan, material, lingkungan, metode kerja, dll. yang
mengambil pola – pola nonacak sehingga dapat diidentifikasi / ditemukan,
sebab mereka tidak selalu aktif dalam proses tetapi memiliki pengaruh yang
lebih kuat pada proses sehingga menimbulkan variasi. Dalam konteks
pengendalian proses statistikal menggunakan peta – peta kendali , jenis
variasi ini sering ditandai dengan titik – titik pengamatan yang melewati
atau keluar dari batas – batas pengendalian yang didefinisikan .
2. Variasi penyebab umum (Common cause variation)
Adalah faktor – faktor di dalam sistem atau yang melekat pada proses yang
menimbulkan variasi dalam sistem serta hasil – hasilnya. Karena penyebab
umum ini selalu melekat pada sistem, untuk menghilangkannya kita harus
menelusuri elemen – elemen dalam sistem itu dan hanya pihak manajemen
yang dapat memperbaikinya, karena pihak manajemenlah yang
mengendalikan sistem itu. Dalam konteks pengendalian proses statisitkal
dengan menggunakan peta – peta kendali jenis variasi ini sering ditandai
19
dengan titik – titik pengamatan yang berada dalam batas – batas
pengendalian.
3.5 DMAIC
Tabel 3.1 DMAIC
Perbaikan Proses Define • Identifikasi masalah
• Definisikan kebutuhan • Tetapkan tujuan
Measures • Pertegas masalah/proses • Membenarkan pengetahuan tujuan • Ukur langkah – langkah inti/masalah
Analyze • Kembangkan hipotesis • Identifikasi akar penyebab masalah • Validasi hipotesis
Improve • Kembangkan ide untuk menghilangkan akar penyebab permasalahan
• Uji solusi • Tetapkan solusi/hasil pengukuran
Control • Buat standar pengukuran untuk memelihara kinerja kerja • Bereskan permasalahan sesuai dengan tujuan yang
diinginkan. Sumber : Peter S. Pande (2000, p39)
3.6 Critical To Quality (CTQ)
CTQ adalah sebuah karakteristik pengukuran suatu produk atau proses
dimana kinerja standar atau batas spesifikasi harus mampu memuaskan
pelanggan. Kita menyesuaikan pengembangan atau perbaikan sesuai dengan
kebutuhan customer.
20
CTQ mewakili karakteristik produk atau jasa yang diinginkan oleh
customer (internal maupun external). Karakteristik ini bisa saja meliputi batas
atas dan batas bawah sebuah spesifikasi atau faktor-faktor lain yang berhubungan
dengan produk atau jasa. sebuah CTQ harus diterjemahkan dari pernyataan
customer yang bersifat kualitatif menjadi sebuah spesifikasi bisnis yang bersifat
kuantitatif dan dapat dilakukan.
Sederhananya, CTQ adalah harapan customer terhadap sebuah produk,
keinginan sebuah customer. Customer bisa saja mengungkapkan keinginan
mereka dalam bahasa sehari-hari, namun pada akhirnya tergantung pada kita
untuk merubahnya menjadi measurable terms dengan menggunakan tools seperti
FMEA dan lain-lain.
3.7 Voice of Customer (VOC)
Voice of the Customer (VOC) adalah suatu istilah yang digunakan dalam
bisnis untuk menjelaskan suatu proses menangkap keinginan pelanggan.
Walaupun konsep ini terkesan mudah dimengerti, namun sebenarnya cukup
rumit. Tidak mudah untuk mengumpulkan data-data yang tidak bias dalam
proses survei, focus group, dan wawancara . Orang-orang seringkali menganggap
bahwa mereka memberikan jawaban yang diinginkan oleh pewawancara, namun
berlawanan dengan opini mereka yang sebenarnya. hal ini berujung pada hasil
yang tidak merefleksikan keinginan sebenarnya dari pelanggan.
Voice of the Customer tools juga terkadang tidak menggunakan suatu
indikator untuk mengukur kepuasan dari pelanggan. Banyak perusahaan
mengumpulkan data VOC yang reaktif dalam bentuk sebuah form yang berisi
21
kumpulan keluhan atau database. Dalam beberapa kasus, data ini digunakan oleh
pihak manajemen untuk mengerti pelanggan mereka lebih baik dan
mengembangkan program pengembangan berkala dalam rangka memenuhi
keinginan pelanggan.
Pelanggan terkadang tidak tahu, atau tidak dapat mengkomunikasikan
keinginan dan kebutuhan mereka yang sesungguhnya. Hal ini merupakan
tantangan utama dalam menghadapi dunia bisnis saat ini.
Karena hal ini, dunia bisnis harus terus mencari cara yang lebih kreatif
dalam memahami keinginan pelanggan.lebih jauh, dan untuk mengembangkan
peningkatan yang berkelanjutan untuk mengaplikasikan kebutuhan pelanggan.
Pelangan sering tidak tahu, atau tidak dapat berkomunikasi secara efektif
mengenai kebutuhan mereka yang sebenarnya. Inilah salah satu tantangan yang
dihadapi bisnis sekarang. Karena ini, bisnis harus terus mencari cara-cara yang
lebih kreatif untuk mengerti lebih jauh tentang kebutuhan pelanggan.
3.8 Cost Of Poor Quality (COPQ)
COPQ berisi biaya-biaya yang dikeluarkan sebagai hasil memproduksi
material cacat.
Biaya ini termasuk biaya yang harus dikeluarkan untuk memenuhi gap
antara kualitas produk atau jasa yang dinginkan dengan hasil sesungguhnya. dan
juga termasuk biaya hilangnya kesempatan yang disebabkan hilangnya sumber
daya yang digunakan memperbaiki cacat. Biaya ini termasuk biaya pekerja,
pengerjaan ulang, pengaturan, dan bahan baku yang harus ditambahkan kedalam
22
unit sampai pada titik penolakan. COPQ tidak meliputi biaya pendeteksian dan
pencegahan.
Supplier dapat mempengaruhi biaya pada perusahaan meliputi produk
cacat yang dihasilkannya, dan material yang rusak selama pengiriman.
3.9 Peta kendali (Control chart)
Peta kendali menggambarkan perbaikan kualitas. Perbaikan kualitas
terjadi pada dua situasi. Situasi pertama adalah ketika peta kendali dibuat, proses
dalam kondisi tidak stabil. Kondisi yang diluar batas kendali terjadi karena sebab
khusus (assignable cause / Special cause variation), kemudian dicari tindakan
perbaikan sehingga proses menjadi stabil. Hasilnya adalah adanya perbaikan
proses.
Peta kendali dibuat berdasarkan pada tipe datanya. Dalam konteks
pengendalian proses statistik, dikenal 2 (dua) jenis data, yaitu:
1. Data variabel (variables data)
Data variabel atau biasa disebut data kontinu adalah data kuantitatif yang
diukur untuk keperluan analisis. Contoh data variabel yaitu, temperatur,
panjang, waktu, berat, dan lain-lain, Dalam pengendalian mutu proses
statistik dengan menggunakan data variabel, dikenal 2 macam peta kontol
untuk mempermudah analisa, yaitu :
• X dan R
Digunakan untuk memantau proses yang mempunyai karakteristik
berdimensi kontinyu, sehingga peta kontrol X dan R sering disebut
23
sebagai peta kontrol untuk data variabel. Peta kontrol X menjelaskan
kepada kita tentang apakah perubahan – perubahan telah terjadi dalam
ukuran titik pusat dari sebuah proses. Sedangkan peta kontrol R (Range)
menjelaskan tentang apakah perubahan – perubahan telah terjadi dalam
ukuran variasi, dengan demikian berkaitan dengan perubahan
homogenitas produk yang dihasilkan melalui suatu proses.
Gaspersz(1998, p112)
• Individual X dan MR
Digunakan apabila ukuran contoh yang digunakan untuk pengendalian
proses adalah hanya satu (n=1). Hal ini sering terjadi apabila pemeriksaan
dilakukan secara otomatis, dan juga terjadi pada tingkat produksi yang
sangat lambat, sehingga sukar untuk mengambil ukuran contoh (n) lebih
dari 1. Gaspersz(1998, p133).
2. Data atribut (attributes data)
Data atribut adalah data kualitatif yang dapat dihitung untuk pencatatan dan
analisis. Contoh dari data atribut yaitu ketiadaan label pada kemasan,
banyaknya jenis cacat pada produk, dan lain-lain.
Dalam pengendalian mutu proses dengan menggunakan data atribut, dapat
menggunakan 4 buah peta kontrol untuk mempermudah analisa terhadap
proses, yaitu :
• Peta Kontrol p
Peta kontrol p digunakan untuk mengukur proporsi ketidaksesuaian,
penyimpangan atau cacat dari item – item dalam kelompok yang sedang
24
diinspeksi. Dengan demikian peta kontrol p digunakan untuk
mengendalikan proporsi dari produk yang cacat yang dihasilkan dalam
suatu proses. Jika item – item itu tidak memenuhi standar pada satu atau
lebih karakteristik kualitas yang diperiksa, item – item itu digolongkan
sebagai tidak memenuhi syarat spesifikasi atau cacat.
• Peta konrol np
Peta kontrol np hampir serupa dengan peta kontrol p. Peta kontrol np
menggunakan ukuran banyak item yang tidak memenuhi spesifikasi atau
banyaknya yang tidak sesuai dalam suatu pemeriksaan. Namun peta np
hanya dapat digunakan saat ukuran sampel tetap, bila bervariasi , harus
menggunakan peta kontrol p.
• Peta kontrol C
Peta kontrol C didasarkan pada titik spesifik yang tidak memenuhi syarat
dalam produk itu, sehingga suatu produk dapat saja dianggap memenuhi
syarat meskipun mengandung satu atau beberapa titik spesifik yang cacat.
• Peta Kontrol U
Peta kontrol U merupakan rata – rata jumlah cacat per unit, dimana
berfungsi sangat mirip dengan peta kontrol C dalam penggunaannya.
3.10 Diagram Pareto
Diagram pareto adalah grafik batang yang menunjukkan masalah
berdasarkan urutan banyaknya kejadian. Masalah yang paling banyak terjadi
ditunjukkan oleh grafik batang pertama yang tertinggi serta ditempatkan pada
25
sisi paling kiri, dan seterusnya sampai masalah yang paling sedikit terjadi
ditunjukkan oleh grafik batang terakhir yang terendah serta ditempatkan pada sisi
paling kanan.
Vilfredo Pareto, seorang ahli ekonomi dari Italia pada abad ke-19
mengemukakan aturan 80/20 yang kemudian sering disebut sebagai Prinsip
Pareto. Prinsip ini menjelaskan bahwa 80% dari semua masalah disebabkan oleh
20% dari penyebabnya. Analisa Pareto bertujuan untuk mengurutkan dan
memprioritaskan penyebab atau hasil secara sistematis serta hubungannya
dengan performansi lalu sehingga dapat membantu analis untuk
memvisualisasikan penyimpangan distribusi. (Kolarik, 1999, p562)
3.11 Diagram SIPOC (Supplier – Input – Output – Process – Customer)
SIPOC adalah alat yang paling banyak digunakan dan penting dalam
manajemen dan peningkatan proses. SIPOC merupakan singkatan dari Supplier –
Input – Process – Output – Customer dan didefinisikan sebagai berikut:
1. Supplier adalah orang atau sekelompok orang yang memberikan material,
informasi kunci, atau sumber daya lain kepada proses. Supplier dapat juga
merupakan proses sebelum proses yang menjadi fokus.
2. Input adalah segala sesuatu yang diberikan pemasok kepada proses.
3. Process merupakan sekumpulan langkah yang mentransformasi input
sehingga nilainya bertambah.
4. Output adalah produk, baik berupa barang atau jasa yang dihasilkan dari
suatu proses.
26
5. Customer adalah orang atau sekelompok orang atau sub-proses yang
menerima Output.
Gambar 3.1 SIPOC Diagram
3.12 Diagram sebab akibat (Cause effect/fishbone diagram)
Diagram sebab akibat atau yang sering disebut sebagai diagram tulang
ikan (fishbone diagram) atau diagram Ishikawa (Ishikawa’s diagram)
diperkenalkan oleh Prof. Kaoru Ishikawa dari Universitas Tokyo pada tahun
1953. Diagram sebab akibat ini merupakan diagram yang menunjukkan
hubungan antara sebab dan akibat secara sistematis.
Kegunaan cause and effect (fishbone diagram) adalah untuk
menampilkan bentuk gambar dari hal yang diidentifikasi dan mengorganisasi
kemungkinan-kemungkinan akar masalah, atau faktor-faktor yang diperlukan
untuk kesuksesan suatu aktivitas. Diagram ini adalah sebuah alat yang efektif
untuk melihat kaitan antar elemen dalam mempelajari proses, sistuasi dan untuk
perencanaan.
Diagram sebab akibat dapat dipergunakan untuk berbagai kebutuhan berikut:
1. Membantu mengidentifikasi akar penyebab dari suatu masalah
2. Membantu membangkitkan ide-ide untuk solusi suatu masalah
3. Membantu dalam penyelidikan atau pencarian fakta lebih lanjut
27
Dalam menggambar cause and effect (fishbone diagram) ada beberapa
kategori umum sumber penyebab berdasarkan prinsip 7M, yaitu : Gasperz (2002,
pp241-243)
1. Manpower (tenaga kerja)
Berkaitan dengan kekurangan dalam pengetahuan (tidak terlatih, tidak
berpengalaman), kekurangan dalam ketrampilan dasar yang berkaitan dengan
mental dan fisik, kelelahan, stress, ketidakpedulian, dll.
2. Machines (mesin-mesin)
Berkaitan dengan tidak ada sistem perawatan preventif terhadap mesin-mesin
produksi, termasuk fasilitas dan peralatan lain, tidak sesuai dengan
spesifikasi tugas, tidak dikalibrasi, terlalu complicated, terlalu panas, dll.
3. Methods (metode kerja)
Berkaitan dengan tidak ada prosedur dan metode kerja yang benar, tidak
jelas, tidak diketahui, tidak terstandarisasi, tidak cocok, dll.
4. Materials (bahan baku)
Berkaitan dengan ketiadaan spesifikasi kualitas dari bahan baku dan bahan
penolong yang digunakan, ketidaksesuaian dengan spesifikasi kualitas bahan
baku dan bahan penolong yang ditetapkan, ketiadaan penanganan yang
efektif terhadap bahan baku dan bahan penolong itu, dll.
5. Media
Berkaitan dengan tempat dan waktu kerja yang tidak memperhatikan aspek –
aspek kebersihan, kesehatan dan keselamatan kerja, dan lingkungan kerja
yang kondusif, kekurangan dalam lampu penerangan, ventilasi yang buruk,
kebisingan yang berlebihan, dll.
28
6. Motivation (motivasi)
Berkaitan dengan ketiadaan sikap kerja yang benar dan professional (tidak
kreatif, bersikap reaktif, tidak mampu bekerja sama dalam tim, dll), yang
dalam hal ini disebabkan oleh system balas jasa dan penghargaan yang tidak
adil kepada tenaga kerja.
7. Money (keuangan)
Berkaitan dengan ketiadaan dukungan finansial (keuangan) yang mantap
guna memperlancar proyek peningkatan kualitas.
Gambar 3.2 Fishbone Diagram
3.13 Failure Modes and Effect Analysis (FMEA)
Berdasarkan Melinda (2006, p121), FMEA merupakan seperangkat
pedoman, proses dan format untuk mengidentifikasikan dan memprioritaskan
masalah penting (kegagalan).
29
Berdasarkan Gasperz (2002, p246), FMEA adalah suatu prosedur
terstruktur untuk mengidentifikasi dan mencegah sebanyak mungkin mode
kegagalan (failure modes).
Suatu mode kegagalan adalah apa saja yang termasuk dalam kecacatan
atau kegagalan dalam desain, kondisi diluar batas spesifikasi yang telah
ditetapkan, atau perubahan – perubahan dalam produk yang menyebabkan
terganggunya fungsi dari produk itu.
Penggunaan FMEA akan paling efektif apabila diterapkan pada produk
atau proses – proses baru, atau produk dan proses sekarang yang akan mengalami
perubahan – perubahan besar dalam desain sehingga dapat mempengaruhi
keandalan dari produk atau proses situ.
Langkah – langkah FMEA :
• Identifikasi proses atau produk/jasa
• Daftarkan masalah – masalah yang mungkin timbul.
• Beri skala pada masalah berdasarkan kerumitannya, kemungkinan terjadi
atau kemampuan terdeteksi.
• Hitung RPN (Risk Priority Number) dan tindakan yang diutamakan.
• Ambil tindakan untuk mengurangi risiko.
Definisi serta pengurutan atau pemberian ranking dari berbagai
terminologi dalam FMEA adalah sebagai berikut:
1. Akibat potensial adalah akibat yang dirasakan atau dialami oleh pengguna
akhir.
30
2. Mode kegagalan potensial adalah kegagalan atau kecacatan dalam desain
yang menyebabkan cacat itu tidak berfungsi sebagaimana mestinya.
3. Penyebab potensial dari kegagalan adalah kelemahan-kelemahan desain dan
perubahan dalam variabel yang akan mempengaruhi proses dan
menghasilkan kecacatan produk.
4. Occurance (O) adalah suatu perkiraan tentang probabilitas atau peluang
bahwa penyebab akan terjadi dan menghasilkan modus kegagalan yang
menyebabkan akibat tertentu.
Tabel 3.2 Rating Occurrence Rangking Kriteria Verbal ProbabilitasKegagalan
1 Tidak mungkin penyebab ini mengakibatkan kegagalan
1 dalam 1000000
2 3
Kegagalan akan jarang terjadi 1 dalam 20000 1 dalam 4000
4 5 6
Kegagalan agak mungkin terjadi 1 dalam 1000 1 dalam 400 1 dalam 80
7 8
Kegagalan adalah sangat mungkin terjadi
1 dalam 40 1 dalam 20
9 10
Hampir dapat dipastikan bahwa kegagalan akan terjadi
1 dalam 8 1 dalam 2
Catatan : probabilitas kegagalan berbeda beda tiap produk, oleh karena itu pembuatan rating disesuaikan dengan proses dan berdasarkan pengalaman dan pertimbangan rekayasa (engineering judgement) Sumber : Gasperz, 2002, p251
5. Severity (S) adalah suatu perkiraan subyektif atau estimasi tentang bagaimana
buruknya pengguna akhir akan merasakan akibat dari kegagalan tersebut.
31
Tabel 3.3 Severity
Rangking Kriteria Verbal
1 Neglible Severity, kita tidak perlu memikirkan akibat ini akan berdampak pada kinerja produk. Pengguna akhir tidak akan memperhatikan kecacatan atau kegagalan ini.
2 3
Mild Severity, akibat yang ditimbulkan hanya bersifat ringan, pengguna akhir tidak merasakan perubahan kinerja.
4 5 6
Moderate Severity, pengguna akhir akan merasakan akibat penurunan kinerja atau penampilan namun masih berada dalam batas toleransi.
7 8
High Severity, pengguna akhir akan merasakan akibat buruk yang tidak dapat diterima, berada di luar batas toleransi.
9 10
Potential Safety Problem, akibat yang ditimbulkan adalah sangat berbahaya dan bertentangan dengan hukum.
Catatan : Tingkat severity berbeda beda tiap produk, oleh karena itu pembuatan rating disesuaikan dengan proses dan berdasarkan pengalaman dan pertimbangan rekayasa (engineering judgement)
Sumber: Gasperz, 2002, 250
6. Detectibility (D) adalah perkiraan subyektif tentang bagaimana efektivitas dan
metode pencegahan atau pendeteksian.
32
Tabel 3.4 Detectability Rangking Kriteria Verbal Tingkat Kejadian Penyebab
1 Metode pencegahan atau deteksi sangat efektif. Tidak ada kesempatan bahwa penyebab akan muncul lagi.
1 dalam 1000000
2 3
Kemungkinan bahwa penyebab itu terjadi adalah sangat rendah.
1 dalam 20000 1 dalam 4000
4 5 6
Kemungkinan penyebab bersifat moderat, Metode deteksi masih memungkinkan kadang kadang penyebab itu terjadi.
1 dalam 1000 1 dalam 400 1 dalam 80
7 8
Kemungkinan bahwa penyebab itu masih tinggi. Metode pencegahan atau deteksi kurang efektif, karena penyebab masih berulang lagi
1 dalam 40 1 dalam 20
9 10
Kemungkinan bahwa penyebab itu terjadi sangat tinggi. Metode deteksi tidak efektif. Penyebab akan selalu terjadi
1 dalam 8 1 dalam 2
Catatan : tingkat kejadian penyebab berbeda beda tiap produk, oleh karena itu pembuatan rating disesuaikan dengan proses dan berdasarkan pengalaman dan pertimbangan rekayasa (engineering judgement) Sumber: Gasperz, 2002, p254
7. Risk Priority Number (RPN)
Gabungan dari ranking Severity (S), Occurrence(O), dan Detection (D) dengan
rumus :
RPN = (S) x (O) x (D)
Nilai ini harus digunakan untuk mengurutkan perhatian yang harus diberikan
pada proses tersebut, misal untuk diagram Pareto. RPN ini akan bernilai antara 1
dan 1000. Untuk RPN yang besar, team harus mampu menurunkan nilai resiko,
umumnya perhatian tertinggi harus diberikan pada Severity (S) tertinggi.
33
3.14 Pengertian Sistem
Menurut McLeod (2001, p11), sistem adalah sekelompok elemen yang
terintegrasi dengan maksud yang sama untuk mencapai suatu tujuan.
Mathiassen et al. (2000, p9). Sistem adalah sekumpulan elemen yang
mengimplementasikan kebutuhan model, functions, dan interfaces.
3.15 Elemen Sistem
Sistem memiliki elemen – elemen dasar yang saling berinteraksi yaitu
input, process, output. Input mencakup komponen atau unsur yang akan masuk
ke dalam system untuk diproses. Process adalah perubahan bentuk atau
transformasi dari input menjadi ouput. Output adalah hasil akhir dari process
yang telah sesuai dengan tujuan.
Contoh elemen sistem pada perusahaan manufaktur, sumder daya input
adalah bahan mentah, yang diubah menjadi barang jadi atau jasa melalui proses
manufaktur.
3.16 Pengertian Data
Menurut McLeod (2001, p15), Data adalah fakta – fakta yang dan angka–
angka yang relatif tidak berarti bagi pemakai. Sedangkan menurut O’Brien
(2002, p13), Data adalah fakta mentah atau penelitian tentang fenomena fisik
atau transaksi bisnis.
3.17 Pengertian Informasi
Informasi adalah salah satu jenis utama sumber daya yang tersedia bagi
manajer. Informasi ini dapat dikelola seperti halnya sumber daya yang lain, dan
34
perhatian pada topik ini bersumber dari dua pengaruh. Pertama, bisnis telah
menjadi semakin rumit, dan kedua adalah komputer telah mencapai kemampuan
yang semakin baik.
Output informasi dari komputer digunakan oleh para manajer, non-
manajer, serta orang - orang dan organisasi – organisasi dalam lingkungan
perusahaan. Manajer berada pada semua tingkat organisasional perusahaan, dan
dalam semua bidang fungsional. Manajer melaksanakan berbagai fungsi dan
peran, dan untuk berhasil, manajer memerlukan keahlian da;am komunikasi dan
pemecahan masalah. Manajer perlu mengerti komputer (computer literate), tetapi
yang lebih penting mereka perlu mengerti informasi (information literate).
Sangat bermanfaat jika manajer mampu melihat unitnya sebagai suatu
sistem yang terdiri dari beberapa subsistem dan berada dalam supersistem yang
lebih besar. Perusahaan adalah suatu sistem yang bersifat fisik, namun dikelola
dengan menggunakan suatu sistem konseptual. Sistem konseptual itu terdiri dari
suatu pengolah informasi yang mengubah data menjadi informasi dan
menggambarkan sumber daya fisik.
Menurut McLeod (2001, p15) Informasi merupakan data yang telah
diproses atau data yang memiliki arti. Sedangkan menurut O’Brien (2002, p13),
informasi adalah data yang telah dikonversikan menjadi bentuk yang bermakna
dan berguna bagi pengguna akhir. Dari definisi yang disebutkan, informasi dapat
disimpulkan sebagai data yang telah diolah yang mempunyai arti dalam
pengambilan keputusan bagi pihak yang bersangkutan.
35
3.18 Sistem Informasi
Menurut O’Brien (2002, p7) Sistem Informasi adalah kombinasi dari
sumber daya manusia, perangkat keras, perangkat lunak, jaringan komunikasi,
dan sumber data yang mengumpulkan , merubah, dan menyebarkan informasi
dalam sebuah organisasi.
Manusia telah bergantung pada sistem informasi untuk berkomunikasi
antara satu dengan lainnya menggunakan peralatan fisik (Hardware),
serangkaian instruksi dan prosedur (Software), jaringan komunikasi ( network ),
dan juga data yang tersimpan (Data Resources) sejak berkembangnya sistem
Informasi.
3.19 Analisa dan Perancangan Berorientasi Objek
Secara umum, perkembangan sistem informasi yang banyak diketahui
adalah perkembangan dari sistem informasi yang berorientasi proses hingga
sistem informasi yang berorientasi objek. Objek merupakan sebuah entitas yang
memiliki identitas, status, dan perilaku (Mathiassen et al., 2000,p4).
Gambar 3.3 Evolusi Metodologi Sistem Informasi
Sumber : http://www.embarcadero.com/support/uml_central.asp.
36
Object Oriented Analysis and Design merupakan tahap awal dalam
pembuatan software berbasis objek, Tujuan dari analisa dan desain ini adalah
untuk mengembangkan garis besar dari keseluruhan kebutuhan sistem dan
sebagai landasan utuk implementasi sistem. Analisa lebih berfokus kepada
konteks sistem, sedangkan desain lebih berfokus pada sisi teknis dari
perancangan software itu sendiri. Mathiassen(2000,p13).
Mathiassen et al. (2000, pp14-15). Empat aktifitas utama pada Object
Oriented analysis and design, yaitu Problem Domain Analysis, Application
Domain Analysis, Component Design, Architectural Design.
Sumber : Mathiassen et al. (2000, p15).
Gambar 3.4 Aktifitas Utama dalam OOAD
37
3.20 Object Oriented Methods
Metode ini digunakan untuk membuat suatu sistem yang dimodelkan oleh
objek, dimana objek tersebut berinteraksi.
3.20.1 Keuntungan dan Kelemahan Object Oriented Methods
Mathiassen et al. (2000, pp5-6) menyebutkan bahwa terdapat keuntungan
menggunakan OOAD diantaranya adalah:
1. OOAD dapat memberikan informasi yang jelas mengenai context sistem.
2. OOAD dapat menangani data yang seragam dalam jumlah yang besar dan
mendistribusikannya ke seluruh bagian organisasi.
3. Berhubungan erat dengan analisa berorientasi objek, perancangan
berorientasi objek, user interface berorientasi objek, dan pemrograman
berorientasi objek.
Terdapat beberapa kelemahan dari OOAD yang berhasil diidentifikasi
oleh Raymond McLeod, Jr (2001, p615) yaitu:
1. Diperlukan waktu lama untuk memperoleh pengalaman pengembangan.
2. Kesulitan metodologi untuk menjelaskan sistem bisnis yang rumit.
3. Kurangnya pilihan peralatan pengembangan yang khusus disesuaikan
untuk sistem bisnis.
38
3.20.2 Karakteristik Object Oriented Methods
• Encapsulation
Adalah suatu objek yang dapat menyembunyikan suatu informasi yang
penting sehingga tidak dapat diakses oleh objek lain yang tidak memiliki
kepentingan serta hak akses pada objek yang bersangkutan.
• Inheritance
Penurunan atau inheritance adalah kemampuan yang dimiliki oleh suatu
objek untuk mewariskan sifat, atribut, metode, variabel kepada kelas
turunannya. Inheritance juga dapat dikatakan dengan menciptakan kelas baru
yang memiliki sifat kelas induknya, serta ditambahkan dengan karakteristik
yang khusus dari kelas itu sendiri.
• Polymorphism
Adalah suatu kemampuan untuk mendefinisikan beberapa kelas dengan
fungsi yang berbeda tetapi memiliki metode dan properti yang sama. Dapat
menyembunyikan banyak detil penerapan yang berbeda dari dan dengan
menggunakan suatu interface yang sama, juga merupakan pengembangan
konsep enkapsulasi.
3.21 Unified Modelling Languange (UML)
Unified Modelling Language (UML) dikembangkan dengan tujuan untuk
menyederhanakan dan mengkonsolidasikan sejumlah besar metode
pengembangan object oriented yang muncul.
39
Unified Modelling Language (UML) adalah sebuah bahasa yang
berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan,
membangun, dan pendokumentasian dari sebuah sistem pengembangan software
berbasis OO (Object Oriented). Pendekatan analisa dan rancangan dengan
menggunakan model OO mulai diperkenalkan sekitar pertengahan 1970 hingga
akhir 1980 dikarenakan pada saat itu aplikasi software sudah meningkat dan
mulai komplek. Sebelum tahun 1980 awal, dimana C dan C++ berkembang,
developer software masih menggunakan sistem pemrograman struktural.
Pemrograman yang umum digunakan adalah Cobol di tahun 1967 dan
berkembang dengan pesat di tahun 1970. Sejak penggunaan OOAD (Object
Oriented Analysis and Design) pertama di bahasa pemrograman Smalltalk di
awal tahun 1980, banyak metode OOAD yang mulai muncul, diantaranya seperti
Shlaer/Mellor, Coad/Yourdon, Booch, Rumbaugh, dan lainnya.
Pada tahun 1994, Booch dan Rumbaugh bergabung di Rational Software
Corp dan membentuk sebuah standar yang baru. Pada awal tahun 1996, OMG
(Object Management Group) mengajukan proposal untuk bertanggung jawab
pada pengembangan dan penyatuan metode pengembangan berbasis objek, inilah
yang terus dikembangkan menjadi UML. Jumlah yang menggunakan metoda OO
mulai diuji cobakan dan diaplikasikan antara tahun 1989 hingga tahun 1994,
seperti halnya oleh Grady Booch dari Rational Software Co. yang dikenal
dengan OOSE (Object-Oriented Software Engineering) dan James Rumbaugh
dari General Electric yang dikenal dengan OMT (Object Modelling Technique).
Kelemahan saat itu mulai disadari oleh Booch maupun Rumbaugh, ketika
mereka bertemu rekan lainnya, Ivar Jacobson dari Objectory. Kelemahan saat itu
40
adalah tidak adanya standar penggunaan model yang berbasis OO, sehingga
mereka mulai mendiskusikan untuk mengadopsi masing-masing pendekatan
metoda OO untuk membuat suatu model bahasa yang seragam, yaitu UML
(Unified Modeling Language) dan dapat digunakan oleh seluruh dunia.
Secara resmi bahasa UML dimulai pada bulan oktober 1994, ketika
Rumbaugh bergabung dengan Booch untuk membuat sebuah proyek pendekatan
metoda yang seragam dari masing-masing metoda mereka. Saat itu baru
dikembangkan draft metoda UML version 0.8 dan diselesaikan, serta di release
pada bulan oktober 1995. Bersamaan dengan saat itu, Jacobson bergabung dan
UML tersebut diperkaya ruang lingkupnya dengan metoda OOSE sehingga
muncul release version 0.9 pada bulan Juni 1996. Hingga saat ini, sejak Juni
1998 UML version 1.3 telah diperkaya dan direspons oleh OMG (Object
Management Group), Anderson Consulting, Ericsson, Platinum Technology,
Object Time Limited, dan lain-lain, serta di pelihara oleh OMG yang dipimpin
oleh Cris Kobryn. UML adalah standar dunia yang dibuat oleh Object
Management Group (OMG), sebuah badan yang bertugas mengeluarkan standar-
standar teknologi object oriented dan software component.
41
Gambar 3.5 Terbentuknya Unified Modelling Language (UML)
Sumber : Dharwiyanti, Wahono, http://ikc.tuxed.org/umum/yanti-uml.php, 2003.
3.21.1 Definisi UML
UML adalah sebuah modeling language, bukanlah sebuah method.
Sebagian besar method, setidaknya dalam prinsipnya, terdiri dari sebuah
modeling language dan sebuah proses. Modeling language adalah notasi
(terutama grafikal) yang digunakan method untuk mengekspresikan rancangan.
Proses adalah nasihat atas langkah-langkah apa yang perlu diambil dalam
menjalankan sebuah rancangan.
3.21.2 Kegunaan UML
UML diperuntukan untuk pemakaian sistem software yang intensif. UML
banyak digunakan terutama untuk (Booch, Rumbaugh, Jacobson, 1999, p17) :
• Sistem informasi perusahaan
• Layanan perbankan dan financial
42
• Telekomunikasi
• Transportasi
• Pertahanaan / angkasa luar
• Perdagangan
• Alat-alat elektronik medis
3.22 System Definition
System definition (Mathiassen et al., 2000, p24) adalah suatu deskripsi
yang jelas namun singkat dari sebuah system yang terkomputerisasi dan
diekspresikan dengan kata-kata. Sebuah System Definition menjelaskan property
mendasar dari pengembangan sebuah system dan kegunaannya. System
Definition menjelaskan system dalam konteks, informasi apa saja yang harus
dimiliki, fungsi apa saja yang harus tersedia, dimana harus digunakan dan dalam
kondisi apa pengembangan bisa dilakukan.
3.23 Rich Picture
Rich picture merupakan suatu penggambaran dari sistem yang membantu
untuk mengerti keadaan dari sistem yang sedang berjalan maupun sistem yang
akan diusulkan.
Menurut Mathiassen et al. (2000, p27) sebuah rich picture berfokus pada
aspek-aspek penting dari keadaan yang berjalan, yang ditentukan sendiri oleh
sang illustrator.
43
3.24 FACTOR
Menurut Mathiassen et al. (2000, p39) FACTOR criterion memiliki 6 elemen:
• Functionality
Merupakan fungsi dari system yang mendukung tugas dari application
domain.
• Application domain
Bagian dari organisasi yang mengurus, mengawasi atau mengontrol
problem domain.
• Conditions
Kondisi seperti apa yang sedang berjalan ketika sistem dikembangkan
dan digunakan.
• Technology
Teknologi yang digunakan dalam mengembangkan sistem dan teknologi
yang dibutuhkan untuk menjalankan system.
• Objects
Objek utama dari problem domain.
• Responsibility
Merupakan kegunaan sistem secara keseluruhan .
44
3.25 Problem Domain Analysis
Mathiassen et al. (2000, pp14-15). Problem domain merupakan bagian dari
situasi yang diatur, diawasi, dan dikendalikan oleh sistem. Tujuan melakukan
analisis problem domain adalah mengidentifikasi dan memodelkan problem
domain.
Sumber : Mathiassen et al. (2000, p46)
Gambar 3.6 Aktifitas Analysis Problem Domain
3.25.1 Class
Menurut Mathiassen et al. (2000, p4), Class adalah gambaran dari
sekumpulan objek yang mempunyai kesamaan struktur, pola operasi, dan atribut.
+move()+resize()+display()
-originShape
Gambar 3.7 Contoh Class
45
3.25.2 Object
Objek merupakan suatu abstraksi dari situasi yang ada di dalam suatu
sistem. Objects mendeskripsikan apa yang menjadi perspektif penggun dalam
dunia nyata. Objek dapat didefinisikan sebagai sebuah entitas yang memiliki
identitas, state serta behaviour. Mathiassen et al. ( 2000, p51 )
3.25.3 Event
Event merupakan abstraksi dari problem domain activity atau proses yang
dilakukan atau dialami oleh satu atau lebih objek. Mathiassen et al. ( 2000,p51 )
3.25.4 Class Diagram
Class Diagram menggambarkan struktur objek dari sistem. Class
diagram menunjukkan sekumpulan class yang membentuk sistem dan hubungan
struktural diantara class tersebut (Mathiassen et al., 2000, p336).
Dalam Class Diagram ini dapat digambarkan hubungan berikut :
• Generalization
Mathiassen et al. (2000, p72). Class induk (Super Class) menjelaskan
properties yang umum yang dimilikinya kepada class khusus dibawahnya
(subclasses).
46
Passenger Car
Taxi Private car
Sumber : Mathiassen et al. ( 2000,p73 )
Gambar 3.8 Contoh Generalization
• Association
Mathiassen et al. (2000, pp 76-77). Yaitu hubungan antar dua atau lebih
objek. Dan hubungan komunikasi antara satu class dengan class lain.
Hubungan ini menggambarkan apa yang perlu diketahui oleh sebuah class
mengenai class lainnya.
Sumber : Mathiassen et al. ( 2000,p77 )
Gambar 3.9 Contoh Association
• Aggregation
Mathiassen et al. (2000, pp 75-75). Merupakan hubungan antar dua atau lebih
objek. Objek superior (the whole) terdiri dari beberapa objek inferior (the
parts). Hubungan yang unik diman sebuah objek merupakan bagian dari
objek lain.
47
Engine Wheel
Cam Shaft
Car
Body
Cylinder
1
1
1
1
1
1..*
1
1..*
11..*
Sumber : Mathiassen et al. ( 2000,p76 )
Gambar 3.10 Contoh Aggregation
• Multiplicities – Yaitu hubungan satu class dengan banyak class.
Class Diagram ini juga dapat disebut sebagai Static Digram, karena dalam
Class Diagram ini tidak terdapat deskripsi yang berkaitan dengan waktu,
seperti di Sequence diagram.
48
Gambar 3.11 Contoh Class Diagram
3.25.5 Behavioral Pattern
Behavioral Pattern: A description of possible event traces for all objects
in a class. (2000, p90). Tujuan dari behaviour activity adalah untuk memodelkan
keadaan problem domain yang dinamis dengan memperluas class definition yang
ada didalam class diagram dengan menambahkan behavioural pattern untuk
setiap class.
3.25.6 Statechart Diagram
Statechart Diagram digunakan untuk memodelkan perilaku dinamis dari
sebuah objek dalam sebuah class yang spesifik dan berisi state dan transition
(Mathiassen et al., 2000, p341).
Statechart diagram mendeskripsikan behavior dari sebuah sistem.
Statechart Diagram menunjukkan state yang mungkin dijalankan oleh sebuah
49
objek dan bagaimana state objek tersebut menjalankannya berubah sebagai hasil
dari event yang mencapai objek tersebut.
Sumber: Mathiassen et al. (2000, p425)
Gambar 3.12 Contoh StateChart Diagram
3.25.7 Sequence Diagram
Bennet 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.
Bennet et al. (2006, pp253-254) menyatakan bahwa setiap sequence diagram
harus diberikan frame yang memiliki heading dengan menggunakan notasi sd
50
yang merupakan kependekan dari sequence diagram. Bennet et al. (2006, p270)
juga menyatakan bahwa terdapat beberapa notasi penulisan heading pada setiap
frame yang terdapat dalam sequence diagram, antara lain:
a. alt
Notasi alt merupakan kependekan dari alternatives yang menyatakan bahwa
terdapat beberapa buah alternatif jalur eksekusi untuk dijalankan.
b. opt
Notasi opt merupakan kependekan dari optional dimana frame yang memiliki
heading ini memiliki status pilihan yang akan dijalankan jika syarat tertentu
dipenuhi.
c. loop
Notasi loop menyatakan bahwa operation yang terdapat dalam frame tersebut
dijalankan secara berulang selama kondisi tertentu.
d. break
Notasi break mengindikasikan bahwa semua operation yang berada setelah
frame tersebut tidak dijalankan.
e. par
Merupakan kependekan dari parallel yang mengindikasikan bahwa operation
dalam frame tersebut dijalankan secara bersamaan.
f. seq
Notasi seq merupakan kependekan dari weak sequencing yang berarti operation
yang berasal dari lifeline yang berbeda dapat terjadi pada urutan manapun.
51
g. strict
Notasi strict merupakan kependekan dari strict sequencing yang menyatakan
bahwa operation harus dilakukan secara berurutan.
h. neg
Notasi neg merupakan kependekan dari negative yang mendeskripsikan operasi
yang tidak valid.
i. critical
Frame yang memiliki heading critical menyatakan bahwa operasi-operasi yang
terdapat di dalamnya tidak memiliki sela yang kosong.
j. ignore
Notasi ini mengindikasikan bahwa tipe pesan atau parameter yang dikirimkan
dapat diabaikan dalam interaksi.
k. consider
Consider menyatakan pesan mana yang harus dipertimbangkan dalam interaksi.
l. assert
Merupakan kependekan dari assertion yang menyatakan urutan pesan yang valid.
m. ref
Notasi ref merupakan kependekan dari refer yang menyatakan bahwa frame
mereferensikan operation yang terdapat di dalamnya pada sebuah sequence
diagram tertentu.
52
Campaign Manager :Client
getName()
listCampaigns()
:Campaign
getCampaignDetails()
:Advert
loop [for all client’s campaigns]
listAdverts()
getAdvertDetails()loop [for all campaign’s adverts]
addNewAdverts()
AdvertnewAd:Advert
Sumber: Bennet et al. (2006, p254)
Gambar 3.13 Contoh Sequence Diagram
3.25.8 Navigation Diagram
Mathiassen et al.(2000, p344). Navigation Diagram merupakan
statechart diagram khusus yang berfokus pada user interface. Diagram ini
menunjukkan window-window dan transisi diantara window-window tersebut.
53
3.26 Application Domain Analysis
Application domain merupakan organisasi yang mengatur, mengawasi,
atau mengendalikan problem domain. Tujuan dilakukannya analisis application
domain adalah untuk menentukan kebutuhan penggunaan sistem.
Sumber: Mathiassen et al. (2000, p117)
Gambar 3.14 Application Domain Analysis
3.26.1 Usecase Diagram
Use case diagram mendeskripsikan hubungan antara actors dan use case
(Mathiassen et al., 2000, p343).
Actor1
UseCase1
Actor2
Gambar 3.15 Contoh Usecase Diagram
3.26.2 Function
Function : a facility for making a mode useful for actors. Mathiassen et
al. (2000, p138). Sebuah fungsi diaktifkan, dieksekusi dan menyediakan hasil,
54
eksekusi dari fungsi dapat menciptakan sebuah reaksi pada application domain
atau problem domain.
Function memiliki beberapa tipe, setiap tipe dari sebuah function
merupakan ekspresi atau penggambaran dari hubungan ang terjadi antara model
dan konteks sistem dan setiap function memiliki karakteristik yang dapat
membantu ketika ingin mendefinisikan suatu function, tipe dari function antara
lain (Mathiassen et al, 2000, p138) :
• Update
Function ini diaktifkan oleh problem domain event dan dapat
menghasilkan sebuah perubahan dalam model state.
• Signal
Function ini diaktifkan dengan merubah model state dan menghasilkan
suatu reaksi dari dalam sistem, reaksi dapat dilihat oleh actor dalam
application domain.
• 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.
55
3.26.3 Interface
Interface : facilities that make a system’s and functions available to
actors. Mathiassen et al (2000, p151 ). Interface merupakan fasilitas yang
membuat model dan function dapat berinteraksi dengan actor, dimana user
interface merupakan interface yang digunakan untuk berhubungan dengan
server.
3.27 Architectural Design
Architectural design berfungsi sebagai kerangka kerja dalam aktivitas
pengembangan sistem dan menghasilkan struktur komponen dan proses sistem.
Tahap architectural design terdiri dari tiga aktivitas yaitu criteria,
component architecture, dan process architecture.
Sumber : Mathiassen et al. (2000, p176)
Gambar 3.16 Architectural Design
3.27.1 Criteria
Mathiassen et al (2000, p151 ). Criterion : a preferred property of an
architecturing.
56
Tabel 3.5 Kriteria untuk 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.
Sumber : Mathiassen et al. (2000, p178)
Mathiassen et al. (2000, pp179-182) menyebutkan bahwa kriteria usable,
flexible, dan comprehensible tergolong sebagai kriteria umum yang harus
dimiliki oleh sebuah sistem dan menentukan baik tidaknya suatu rancangan
sistem.
3.27.2 Component Architecture
Mathiassen et al (2000, p190). Component architecture : a system
structure composed of interconnected components.
57
Mathiassen et al (2000, p190). Component : a collection of program parts
that constitutes a whole and has well-defined responsibilities.
Component architecture yang baik dapat membuat sistem menjadi lebih
mudah dimengerti, dan mengorganisasi design work dan juga merefleksikan
stabilitas dari sistem. Mathiassen et al (2000, p189).
Dalam aktivitas ini, perlu ditentukan pola arsitektural yang paling sesuai
dengan model sistem. Pola-pola arsitektural tersebut antara lain:
• Layered Architecture Pattern
• Generic Architecture Pattern
• Client-Server Architecture Pattern
Hasil dari aktivitas ini adalah sebuah component diagram yang
merupakan class diagram yang dilengkapi dengan spesifikasi komponen yang
kompleks.
Sumber : Mathiassen et al. (2000, p190)
Gambar 3.17 Contoh Component Architecture
58
3.27.3 Process Architecture
Mathiassen et al (2000, p211). Process architecture adalah sebuah
struktur eksekusi sistem yang terdiri dari proses-proses yang saling tergantung
satu sama lain. Dalam aktivitas ini juga perlu menentukan pola distribusi yang
sesuai dengan model sistem. Pola-pola distribusi yang ada antara lain:
• Centralized Pattern
• Distributed Pattern
• Decentralized Pattern
Hasil dari aktivitas ini adalah sebuah deployment diagram yang
menunjukkan processor dengan komponen program dan active objects.
3.28 Component Design
Component design bertujuan untuk menentukan implementasi kebutuhan
di dalam kerangka kerja arsitektural. Hasilnya adalah deskripsi mengenai
komponen-komponen sistem. (Mathiassen et al., 2000, p231).
Component design terdiri dari tiga aktivitas, yaitu:
a. Model component
Merupakan bagian sistem yang mengimplementasikan model problem
domain. Dalam aktivitas ini dihasilkan sebuah class diagram yang
telah direvisi (revised class diagram).
b. Function component
Merupakan bagian sistem yang mengimplementasikan kebutuhan
fungsional. Hasilnya adalah class diagram dengan operasi dan fungsi-
59
fungsinya. Terdapat empat pola eksplorasi untuk merancang function
component, yaitu: Model-Class Placement, Function-Class
Placement, Startegy, Active Function.
c. Connecting component
Hasilnya adalah class diagram yang berhubungan dengan komponen-
komponen sistem.
Sumber : Mathiassen et al. (2000, p232)
Gambar 3.18 Aktivitas Component Design
3.29 Component Diagram
Menggambarkan organisasi dan dependensi diantara sekumpulan
komponen-komponen. Umumnya komponen terbentuk dari beberapa class dan
atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.
Komponen juga dapat berupa interface, yaitu kumpulan layanan yang disediakan
sebuah komponen untuk komponen lain.
60
Sumber: Mathiassen et al. (2000, p201)
Gambar 3.19 Contoh Component Diagram
3.30 Deployment Diagram
Menurut Mathiassen et al. (2000, p340), deployment diagram
menunjukkan konfigurasi sistem dalam bentuk processor dan objek yang
terhubung dengan processor tersebut.
Menggambarkan node dalam membentuk topologi perangkat keras yang
akan digunakan dan konfigurasi komponen-komponen yang ada di dalam sistem.
Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan
untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar
node dan requirement dapat juga didefinisikan dalam diagram ini.
61
:Client
UserInterface
SystemInterface
Function
Model
:Server
SystemInterface
more clients
Sumber: Mathiassen et al. (2000, p217)
Gambar 3.20 Contoh Deployment Diagram
Top Related