BAB 3 LANDASAN TEORI - thesis.binus.ac.idthesis.binus.ac.id/doc/Bab3/LKN2006-58-Bab 3.pdf ·...
Transcript of BAB 3 LANDASAN TEORI - thesis.binus.ac.idthesis.binus.ac.id/doc/Bab3/LKN2006-58-Bab 3.pdf ·...
BAB 3
LANDASAN TEORI
3.1 Pengertian Kualitas
Konsep kualitas adalah merupakan suatu konsep yang kompleks, karakteristik
dari kualitas yang sesungguhnya merupakan suara dari kebutuhan – kebutuhan
konsumen dan penyesuaian dari harapan – harapan konsumen yang subjektif.
Ekspetasi ini diterjemahkan menjadi karakteristik – karakteristik kualitas pengganti
yang ditentukan dalam konsep kesesuaian dalam mendesain dan memproduksi
produk. ( William J. Kolarik, 1995, p5 )
Dalam konteks pembahasan tentang pengendalian proses statistikal,
terminologi kualitas didefinisikan sebagai konsistensi peningkatan atau perbaikan
dan penurunan variasi karakteristik dari suatu produk (barang dan/atau jasa) yang
dihasilkan, agar memenuhi kebutuhan yang telah dispesifikasikan, guna
meningkatkan kepuasan pelanggan internal maupun eksternal. (Vincent Gaspeerz,
1998, p1)
Pengertian kualitas dalam konteks pengendalian proses statistikal adalah
bagaimana baiknya suatu output ( barang dan/atau jasa ) itu memenuhi spesifikasi
dan toleransi yang ditetapkan oleh bagian desain dari suatu perusahaan perusahaan.
Spesifikasi dan toleransi yang ditetapkan oleh bagian desain produk harus
berorientasi kepada kebutuhan atau keinginan konsumen ( orientasi pasar ). (Vincent
Gaspeerz, 1998, p1)
16
3.2 Definisi Pengendalian Torsi
Definisi pengendalian torsi adalah tekanan poros optimum yang dibutuhkan
oleh masing – masing mur dan baut untuk dirakit. Nilai – nilai pengencangan torsi
yang bervariasi dilengkapi untuk mengukur atau mengendalikan tekanan poros.
Untuk menjamin kualitas dari produk, pengencangan mur dan baut sangat penting
untuk bermacam – macam torsi. Dapat disimpulkan pengendalian torsi adalah
mengencangkan baut dan mur dengan torsi yang sudah diset untuk mengontrol atau
mengendalikan produk. ( Start Up Package Isuzu, 2002, p3 ).
Rumus yang digunakan untuk mengukur torsi adalah sebagai berikut : T = F x L
Keterangan :
T = Torque (kgf-cm, kgf-m)
F = Force Applied (kgf), f stands for force
L = Bar Length (cm, m)
Torsi diindikasikan dengan “kgf • m, Nm”.
Gambar 3.1 Torque Click
Sumber : www.tohnichi.com
3.3 Dasar – Dasar Tightening
Pedoman atau dasar dari proses pengencangan torsi atau tightening torque
menurut prinsip Slope, objek yang diperbaiki dengan gaya dari reaksi baut dan mur.
Rata – rata dari tekanan poros berhubungan atau terkait dengan perubahan torsi yang
17
tergantung pada gesekan pada bidang dukungnya. Ada beberapa gesekan yang
terjadi, yaitu : tekanan pada poros (10%), gesekan pada bidang dukung (50%),
gesekan pada baut (40%). (Start Up Package Isuzu, 2002, p3).
Diagram 3.1 Flowchart Pentingnya Pengencangan Baut dan Mur
Sumber : Start Up Package Isuzu, 2002
18
3.4 Statistical Process Control ( SPC )
Statistical process control dalam pengertiannya secara umum merupakan
kumpulan dari metode – metode produksi dan konsep manajemen yang dapat
digunakan untuk mendapatkan efisiensi, produktifitas, dan kualitas untuk
memproduksi produk yang kompetitif dengan tingkat yang maksimum, SPC
melibatkan penggunaan signal – signal statistik untuk meningkatkan performa dan
untuk memelihara pengendalian dari produksi pada tingkat kualitas yang lebih
tinggi. (Gerald Smith, 1996, p1 )
Pengendalian proses statistical (Statistical Process Control = SPC) adalah
suatu terminologi yang mulai digunakan sejak tahun 1970-an untuk menjabarkan
penggunaan teknik – teknik statistikal (statistical techniques) dalam memantau dan
meningkatkan performansi proses menghasilkan produk berkualitas. Pada tahun
1950-an sampai tahun 1960-an digunakan terminologi Pengendalian Kualitas
Statistikal (Statistical Quality Control = SQC) yang memiliki pengertian sama
dengan Pengendalian Proses Statistikal (Statistical Process Control = SPC).
(Vincent Gasperz, 1998, hal 1).
Pengendalian kualitas merupakan aktivitas teknik dan manajemen, melalui
mana kita mengukur karakteristik kualitas dari output kemudian membandingkan
hasil pengukuran itu dengan spesifikasi output yang diinginkan pelanggan, serta
mengambil tindakan perbaikan yang tepat apabila ditemukan perbedaan antara
performansi aktual dan standar.
Pengendalian proses statistikal merupakan suatu metodologi pengumpulan dan
analisa data kualitas, serta penentuan dan interpretasi pengukuran – pengukuran yang
19
menjelaskan tentang proses dalam suatu sistem industri, untuk meningkatkan
kualitas dari output guna memenuhi kebutuhan dan ekspektasi pelanggan.
3.4.1 Tujuan dari SPC
Berikut merupakan tujuan utama dari SPC : ( Gerald Smith, 1996, p4 )
• Meminimasi biaya produksi.
• Memperoleh kekonsistenan terhadap produk dan servis yang memenuhi
spesifikasi produksi dan keinginan konsumen.
• Menciptakan peluang – peluang untuk semua anggota dari organisasi untuk
memberikan kontribusi terhadap peningkatan kualitas.
• Membantu karyawan management dan produksi untuk membuat keputusan
yang ekonomis mengenai tindakan yang diambil yang dapat mempengaruhi
proses
3.4.2 Teknik – Teknik Statistical Process Control ( SPC )
Teknik – teknik yang penting didalam SPC termasuk penggunaan dari : ( Gerald
Smith, 1996, p6 )
1. Process Control Chart untuk mencapai dan mempertahankan pengendalian
statistik pada tiap tahap dari proses
2. Process Capability Studies yang menggunakan control charts untuk
memperkirakan kapabilas dari proses dalam kaitannya dengan spesifikasi
dari produk dan keinginan dari konsumen
3. Gauge capability study
20
4. SPC tools untuk penyelesaian masalah
3.4.3 Peta Kendali ( Control Chart )
Sebuah peta kendali merupakan sebuah alat grafik yang digunakan untuk
melakukan pengawasan dari sebuah proses yang sedang berjalan. Peta kendali
kadang – kadang juga dikenal sebagai peta kendali Shewhart, ini dikarenakan Walter
A.Shewhart merupakan orang yang pertama kali memperkenalkan teori umum
mengenai ini. Nilai dari karakteristik kualitas diplot sepanjang garis vertikal, dan
garis horizontal mewakili sample atau subgroups ( berdasarkan waktu ) dimana
karakteristik dari kualitas ditemukan. ( Amitava Mitra, 1998, p236 )
3.4.4 Keuntungan dari Penggunaan Peta Kendali
Beberapa keuntungan yang bisa didapat dengan menggunakan peta kendali
diantaranya : ( Amitava Mitra, 1998, p237 )
• Kapan harus melakukan tindakan perbaikan : Sebuah peta kendali dapat
mengindikasikan kapan sesuatu menjadi salah dan tindakan perbaikan dapat
dilakukan
• Tipe dari tindakan perbaikan yang diperlukan : Pola dari peta kendali yang diplot
menganalisa penyebab – penyebab yang mungkin dan mengindikasikan tindakan
perbaikan yang diperlukan.
• Kapan harus meninggalkan sebuah proses : Variasi merupakan bagian dari
sebuah proses. Sebuah peta kendali menunjukkan ketika variasi dikatakan
normal dan menunjukkan tidak ada tindakan perbaikan yang diperlukan
21
• Kapabilitas proses : Apabila peta kendali menunjukkan bahwa sebuah proses
berada dalam kendali statistik, kita dapat memperkirakan kapabilitas dari proses
dan menunjukkan kemampuannya untuk memenuhi kebutuhan dari konsumen
• Kemungkinan untuk melakukan peningkatan kualitas : Peta kendali menyediakan
dasar untuk mengukur peningkatan kualitas. Peta kendali juga menyediakan
informasi yang berguna dengan mempertimbangkan tindakan – tindakan yang
dapat dilakukan untuk melakukan peningkatan kualitas
3.4.5 Penyebab Variasi
Variasi merupakan bagian dari sebuah proses, beberapa faktor atau lebih dapat
kita kendalikan seperti metode, peralatan, manusia, dan material. Faktor lingkungan
juga memiliki kontribusi terhadap variasi. Penyebab dari variasi dapat dibagi
kedalam dua group yaitu penyebab khusus dan penyebab umum. Pengendalian dari
sebuah proses diperoleh melalui pengeliminasian dari penyebab – penyebab khusus.
Peningkatan dari sebuah proses didapatkan melalui pengurangan dari penyebab –
penyebab umum. ( Amitava Mitra, 1998, p237 )
3.4.5.1 Variasi Penyebab Khusus
Dua tipe dari variasi yang harus diperhatikan didalam SPC. Yang pertama
disebut dengan variasi penyebab khusus. Ini mempengaruhi proses dalam cara yang
tidak terduga dan dapat dideteksi dengan teknik – teknik statistik yang sederhana.
Hal ini dapat dihilangkan dari proses oleh operator atau tim pengendali proses yang
bertanggung jawab pada tahap tertentu dari proses, ini disebut sebagai tindakan
22
langsung ( local action ). Ketika semua variasi dari penyebab khusus telah
dieliminasi proses dapat dikatakan berada dalam pengendalian statistik. ( Gerald
Smith, 1996, p40 )
3.4.5.2 Variasi Penyebab Umum
Tipe yang kedua dari variasi disebut dengan variasi penyebab umum, ini
diturunkan dari proses. Ketika variasi penyebab khusus telah dieliminasi, proses
dapat berjalan sebaik mungkin tanpa memerlukan adanya perubahan. Sekitar 85%
dari semua masalah berkaitan dengan variasi penyebab umum. Hanya ada satu cara
untuk menurunkan variasi penyebab umum adalah dengan membuat peningkatan
pada proses manufacturing. Perluasan dari variasi penyebab umum dapat diukur
secara statistik dan dibandingkan dengan spesifikasinya, jika perbaikan improvement
dibutuhkan, tindakan pada proses perlu untuk dilakukan. Tindakan dari manajemen
diperlukan untuk semua perubahan dari proses. ( Gerald Smith, 1996, p41 )
3.4.6 Definisi Data Dalam Konteks SPC
Data adalah catatan tentang sesuatu, baik yang bersifat kualitatif maupun
kuantitatif yang dipergunakan sebagai petunjuk untuk bertindak (Vincent
Gasperz, 1998, hal 43). Berdasarkan data, kita mempelajari fakta – fakta yang
ada dan kemudian mengambil tindakan yang tepat berdasarkan fakta itu. Dalam
konteks pengendalian proses statistik dikenal dua jenis data, yaitu :
• Data atribut, yaitu data kualitatif yang dapat dihitung untuk pencatatan dan
analisis. Contoh dari data atribut karakteristik kualitas adalah : ketiadaan
label pada kemasan produk, kesalahan proses administrasi buku tabungan
23
nasabah, banyaknya jenis cacat pada produk, banyaknya produk kayu lapis
yang cacat karena corelap, dll. Data atribut biasanya diperoleh dalam bentuk
unit – unit nonkonformans atau ketidaksesuaian dengan spesifikasi atribut
yang ditetapkan.
• Data variabel, merupakan data kuantitatif yang diukur untuk keperluan
analisis. Contoh dari data variabel karakteristik kualitas adalah : diameter
pipa, ketebalan produk kayu lapis, berat semen dalam kantong, banyaknya
kertas setiap rim, dll. Ukuran – ukuran berat, panjang, lebar, tinggi, diameter,
volume biasanya merupakan data variabel.
3.4.7 Jenis Peta Kendali ( Control Chart )
Ada dua macam bagan kendali ( control chart ) yaitu bagan kendali data
variabel atau variable control chart dan bagan kendali atribut atau attribute
control chart . Data variabel atau biasa disebut data kontinyu adalah data yang
diperoleh dari hasil pengukuran, misalnya : temperatur, panjang, waktu dan lain
sebagainya, sedangkan data atribut atau biasa disebut data diskrit adalah data
yang diperoleh dengan pengelompokan maupun penghitungan, misalnya jumlah
produksi yang rusak, populasi tipe mobil disuatu pabrik. (Start Up Package
Isuzu, 2002, p4).
24
Diagram 3.2 Skema Pembagian Control Chart
Sumber : Prosedur PT.Panjta Motor ( 2000 )
3.4.8 Peta Kendali x dan R
Peta kendali variabel ini terdiri dari 2 grafik yang terpisah, yang satu
menggambarkan average ( x ), yang satu lagi menggambarkan range ( R ), dari
sejumlah kecil sampel yang berurutan. Ukuran sampel yang diambil biasanya
berjumlah 3 sampai 7 sampel, yang paling umum digunakan adalah sampel yang
berjumlah 4 atau 5. Sampel yang digunakan diambil secara berurutan pada tiap
subgroup dengan tujuan untuk memperoleh variasi dari sampel yang satu ke
sampel yang lain sebagaimana variasi secara keseluruhan dapat diwakilkan
dengan menggunakan data yang ada didalam grafik. Tujuan untuk menggunakan
peta kendali :
• Pertama peta kendali menggambarkan kehadiran dari keadaan - keadaan yang
berada diluar kendali. Eliminasi dari masalah – masalah ini akan membawa
proses kedalam pengendalian statistik.
Jenis Data
AtributVariabel
KecacatanDefective
UkuranSampel Cacat Defect
n>25
σ,x
12<n<25 n<12 n=1 n = tetap
C
n = tetap
U NP Psx, Rx, MRx,
n = tetap n = tetap
25
• Kedua untuk memperluas masalah – masalah yang terkait didalam proses
yang dapat diukur dalam sebuah pembelajaran kapabilitas dari sebuah proses.
Pengukuran dari kualitas dapat terlihat dalam sebuah pembandingan dari
sebaran pengukuran σ3±x dengan spesifikasi dari design.
• Ketiga jika proses tidak kapabel ( jika terlalu banyak memiliki variasi dari
produk dan kualitas produk yang buruk ), peta kendali digunakan untuk
mengukur jumlah dari peningkatan yang dihasilkan ketika perubahan
terhadap proses dilakukan.
• Keempat peta kendali x dan R menyediakan bukti ketika sebuah proses baik
dalam keadaan terkendali dan kapabel.
3.4.9 Prosedur Umum Untuk Peta Kendali x dan R
Prosedur berikut merupakan prosedur untuk membuat peta kendali x dan R :
( Gerald Smith, 1996, p123 )
• Tahap 1. Memilih proses yang akan diukur
Tentukan proses yang kritis untuk dibuat peta kendalinya.
• Tahap 2. Menurunkan Variasi
Menghilangkan semua sumber dari variasi yang secara jelas terlihat sebelum
dilakukannya pembuatan peta kendali. Interpretasi peta kendali harus
konsentrasi pada sumber – sumber masalah – masalah yang sedikit atau tidak
dicurigai.
• Tahap 3. Periksa alat pengukuran
Pastikan alat – alat yang digunakan untuk melakukan pengukuran bekerja
dengan baik dan variasi dari alat pengukuran seminimum mungkin dan dapat
26
diterima. Variasi yang muncul pada grafik harus dapat menggambarkan
variasi dari proses. Variasi dari alat pengukuran yang berlebihan membuat
interpretasi dari variasi proses lebih sulit dan kadang – kadang tidak
mungkin.
• Tahap 4. Membuat sample plan
Merencanakan sebuah sample plan terdiri dari dua bagian. Pertama memilih
jumlah sampel. Sampel yang besar seperti 6 atau 7 sampel dapat membawa
kearah pengukuran yang lebih dapat diandalkan untuk memperkirakan variasi
dan nilai rata – rata nya akan tetapi akan memakan biaya yang lebih besar.
Waktu ekstra akan dibutuhkan untuk mengambil sampel dalam jumlah yang
lebih besar didalam melakukan pengukuran juga dapat menjadi sebuah faktor
yang perlu diperhitungkan
• Tahap 5. Mempersiapkan peta kendali dan catatan tentang proses
Tentukan skala untuk peta kendali x dan untuk peta kendali R. Ketika
menentukan skala, hindari penentuan skala yang terlalu besar atau terlalu
kecil. Simpan sebuah catatan tentang proses selama melakukan pengendalian
dengan peta kendali, dan didalamnya pastikan untuk mencatat waktu dan
membuat komentar mengenai kejadian yang mungkin memiliki efek terhadap
proses ( baik yang efeknya bagus maupun buruk ). Tanggal dan jam-nya
harus disertakan pada setiap sampel. Ketika masalah variasi terjadi,
kombinasi dari catatan mengenai proses dan peta kendali dapat sangat
bermanfaat bagi operator atau tim pengendali proses ketika mereka mencoba
untuk mengisolasi dan mengeliminasi masalah yang terjadi.
27
• Tahap 6. Siapkan tally histogram
Siapkan tally histogram dengan menggunakan batas – batas spesifikasi untuk
menentukan skala pengukuran. Arahkan ke sekitar 10 group tergantung dari
jumlah unit yang berada diantara batas spesifikasi.
• Tahap 7. Ambil sampel dan buat peta kendali
Setelah sampel diambil, tulis pengukuran pada peta kendali dan taruh nilai x
pada tally histogram . Hitung x dan R, masukkan nilainya kedalam grafik.
Jika ini merupakan data dari subgroup grafik peta kendali yang pertama,
untuk melakukan analisa harus menunggu sampai semuanya lengkap
• Tahap 8. Hitung rata – rata dan batas kontrol
Dengan menggunakan formula Shewhart :
Rata rata R kRR Σ
=
Batas kendali RDUCLR 4=
RDLCLR 3=
Rata rata x kxx Σ
=
Batas kendali RAxUCLx 2+=
RAxLCLx 2−=
• Tahap 9. Hitung Kapabilitas
Ketika proses berada dalam batas kendali statistik, tentukan kapabilitas dari
proses.
28
• Tahap 10. Melakukan pengawasan terhadap proses
Ketika proses berada dalam batas kendali dan kapabel, sebuah pengawasan
terhadap proses harus dilakukan, peta kendali yang berkelanjutan dengan satu
atau dua sampel per shift bisa dilakukan.
• Tahap 11. Continuous Improvement
Peningkatan kualitas merupakan sebuah proses yang berkelanjutan. Operator
harus tetap waspada terhadap kejadian yang muncul yang mengarah kepada
kesalahan atau yang berkaitan dengan pengukuran variabilitas.
3.4.10 Interpretasi dari Peta Kendali
Ketika sebuah proses, diluar batas kendali, pola yang terbentuk dari titik
– titik pada peta kendali dapat disebabkan karena suatu hal. Freaks, shifts, trends,
dan cycles adalah beberapa pola dari peta kendali yang dapat dikenali. Satu
peraturan dasar yang harus diingat : selalu berusaha untuk membuat peta kendali
R berada dalam kendali statistik dahulu. Peta kendali x tidak dapat dianalisa jika
peta kendali R berada belum berada didalam kendali statistik.
Berikut beberapa pola yang digunakan untuk melakukan interpretasi terhadap
peta kendali : ( Gerald Smith, 1996, p288 )
1. Freaks
Pola freaks merupakan pola dimana satu titik berada diluar batas kendali. Ini
menunjukkan bahwa sesuatu berubah secara tiba – tiba didalam proses untuk
waktu yang singkat atau ada kesalahan yang terjadi.
2. Shifts
29
Pola shifts merupakan kumpulan dari 7 atau lebih titik yang berurutan yang
berada pada salah satu sisi dari garis tengah / center line . Sesuatu
dimasukkan kedalam proses yang dapat merubah keseluruhan dari proses.
Pola Shifts biasanya sementara.
3. Runs dan Trends
Pola runs muncul ketika beberapa titik secara tetap menaik atau menurun
pada sebuah peta kendali. 7 titik biasanya jumlah yang digunakan untuk
mengindikasikan sebuah pola runs . Pola runs dapat menunjukkan kabar baik
dan juga kabar buruk. Pada peta kendali R, trend yang menurun
mengindikasikan bahwa variasi yang terjadi pada produk menurun. Ini
memberikan tanda adanya peningkatan dari proses karena penggunaan SPC,
training operator yang lebih baik, atau peningkatan perawatan. Trend yang
menaik pada peta kendali R memberikan tanda adanya penurunan dari proses
bahwa variasi yang terjadi pada produk mengalami kenaikan.
4. Cycles
Pola cycles pada sebuah peta kendali merupakan sebuah pola yang berulang.
Pola ini menunjukkan bahwa sesuatu secara sistematik mempengaruhi proses.
Kunci untuk menemukan masalah yang menyebabkan pola cycles adalah
konsentrasi pada faktor – faktor yang merubah proses secara periodik.
5. Grouping
Ini merupakan kasus lain dimana masalah klasifikasi muncul antara satu
dengan yang lainnya. Grouping atau bunching terjadi ketika titik – titik pada
peta kendali muncul dalam cluster.
6. Instability
30
Pola yang teratur yang memiliki fluktuasi yang besar pada sebuah peta
kendali diklasifikasikan sebagai instability atau unstable mixture..
7. Stable mixture
Sebuah pola mixture yang secara teratur naik dan turun mirip seperti dengan
pola instability tapi memiliki beberapa titik yang berada pada bagian tengah
dari peta kendali merupakan sebuah pola Stable mixture.
8. Stratification
Dalam sebuah pola Stratification, titik – titik berada dekat garis tengah pada
sebuah peta kendali. Bagi yang belum terlatih, sebuah pola Stratification akan
diidentifikasi sebagai proses yang berjalan dengan baik. Jika proses benar –
benar telah ditingkatkan, bagaimanapun juga sebuah trend menurun atau shift
pada peta kendali R akan muncul bersamaan dengan pola stratification pada
peta kendali R
3.5 Process Capability Analysis
Process capability mewakili performa dari sebuah proses dalam kondisi
pengendalian secara statistik, ini ditentukan oleh total dari variasi yang ada
karena penyebab – penyebab umum yang ada didalam sistem . (Amitava Mitra,
1998, p374 ). Fungsi utama dari capability analysis adalah untuk menentukan
seberapa baik pengukuran yang telah dilakukan ketika dibandingkan dengan
spesifikasi.
Capability Index
Ada dua versi dari capability index yaitu Cp dan Cpk
31
σ6LSLUSLCp −
=
Ketika Cp digunakan, nilainya akan dibandingkan terhadap nilai tertentu yang
diinginkan. Nilai Cp yang berada di bawah 1 berarti toleransi nya lebih kecil dari
penyebaran pengukuran σ6 dan ada sampel pada populasi yang berada diluar
batas spesifikasi.
Capability index yang kedua yang digunakan yang berhubungan dengan Cp
adalah Cpk. Nilai Cp dibandingkan dengan keseluruhan toleransi σ6 dan
mengindikasikan seberapa baik sebuah proses. Cpk membandingkan yang
terburuk sebagian dari distribusi dengan σ3 .
σ3
min xSLimumCpk
−=
Banyak perusahaan menggunakan standard dari Cpk = 1,33, dan beberapa juga
menentukan Cpk = 2. Jadi, interpretasi dari Cpk adalah kebutuhan nilai Cpk dari
perusahaan lebih besar dari 1,33. jika dibawah 1,33 maka semua usaha harus
dilakukan untuk mencapai angka 1,33. Jika nilai Cpk dibawah 1, maka inspeksi
100 % harus dilakukan karena akan ada produk yang berada di luar batas
spesifikasi yang menjadi masalah
3.5.1 Keuntungan Process Capability Analysis
Berikut beberapa keuntungan dari process capability analysis :
1. Keseragaman dari output
Dengan menggunakan process capability dan melakukan penyesuaian yang
diperlukan pada parameter proses, variabilitas dapat lebih dikendalikan,
32
segala bentuk yang tidak diinginkan dapat distribusi dari karakteristik kualitas
dievaluasi dan perubahan yang memang diperlukan pada parameter dapat
dilakukan lebih cepat.
2. Peningkatan atau pemeliharaan kualitas
Process capability analysis mengindikasikan apakah diperlukan peralatan
yang baru atau tidak. Setelah perubahan ini terjadi maka capability yang baru
dapat ditentukan.
3. Memfasilitasi desain produk dan proses
Informasi yang diperoleh dari process capability analysis menyediakan
umpan balik yang penting untuk desain. Ini sangat penting karena perancang
produk harus waspada terhadap variasi yang muncul secara permanen.
4. Membantu dalam pemilihan dan pengendalian vendor
Perusahaan dapat meminta kepada vendor mereka untuk melakukan pelaporan
mengenai informasi process capability untuk mengarahkan mereka dalam
memilih vendor
5. Pengurangan total biaya
Ini terjadi karena biaya kegagalan internal dan eksternal diturunkan. Dengan
secara teratur mengawasi parameter dari proses, akan lebih sedikit produk
yang tidak sesuai standar diproduksi.
3.6 Diagram Sebab – Akibat ( Cause and Effect Diagram )
Diagram sebab akibat adalah suatu diagram yang menunjukkan hubungan
antara sebab dan akibat, diagram ini digunakan untuk meringkaskan pengetahuan
mengenai kemungkinan sebab – sebab terjadinya variasi dan permasalahan
33
lainnya ( Wayne C. Turner, 2000, p281 ). Berkaitan dengan pengendalian proses
statistikal, diagram sebab akibat dipergunakan untuk menunjukkan faktor –
faktor penyebab ( sebab ) dan karakteristik kualitas ( akibat ) yang disebabkan
oleh faktor – faktor penyebab itu. Diagram sebab akibat ini sering juga disebut
sebagai Diagram Tulang Ikan ( fishbone diagram ) karena bentuknya seperti
kerangka ikan, atau Diagram Ishikawa ( ishikawa diagram )
Diagram sebab akibat digunakan untuk kebutuhan – kebutuhan sebagai berikut :
- Membantu mengindentifikasi akar penyebab dari suatu masalah
- Membantu membangkitkan ide – ide untuk solusi suatu masalah
- Membantu dalam penyelidikan atau pencarian fakta lebih lanjut
Diagram ini merupakan sebuah format untuk secara logis menyelaraskan
penyebab – penyebab yang mungkin dari sebuah masalah. Sebuah cara dasar
untuk mengatur kategori utama adalah dengan menempatkan 4 M yaitu : metode,
mesin, manusia, material.
3.7 Failure Method And Effect Analysis ( FMEA )
FMEA merupakan sebuah metodologi yang digunakan untuk
menganalisa dan menemukan : 1. semua kegagalan – kegagalan yang potensial
terjadi pada suatu sistem. 2. Efek – efek dari kegagalan ini yang terjadi pada
sistem dan 3. Bagaimana cara untuk memperbaiki atau meminimalis kegagalan –
kegagalan atau efek – efek nya pada sistem. ( Perbaikan dan minimalis yang
dilakukan biasanya berdasarkan pada sebuah rangking dari severity dan
probability dari kegagalan ) ( Lewis, 1996, p3 )
34
FMEA biasanya dilakukan selama tahap konseptual dan tahap awal
design dari sistem dengan tujuan untuk meyakinkan bahwa semua kemungkinan
kegagalan telah dipertimbangkan dan usaha yang tepat untuk mengatasinya telah
dibuat untuk meminimasi semua kegagalan – kegagalan yang potensial
Penggunaan jangka pendek :
- untuk mengidentifikasi kondisi yang berbahaya dan kritis
- untuk mengidentifikasi kegagalan – kegagalan yang potensial
- untuk mengidentifikasi kebutuhan jika terjadi kesalahan deteksi
- untuk mengidentifikasi efek – efek dari kegagalan – kegagalan
Pada awalnya FMEA dijalankan selama pada tahap desain, tapi juga mungkin
untuk digunakan pada tahap daur hidup dari produk untuk mengidentifikasi
kemungkinan kegagalan – kegagalan pada saat sistem sudah berjalan cukup lama
FMEA dapat bervariasi pada level detail dilaporkan, tergantung pada detail
yang dibutuhkan dan ketersediaan dari informasi. Sebagaimana pengembangan
terus berlanjut, memperkiraan secara kritis ditambahkan dan menjadi Failure
Mode, Effects and Critically Analysis atau FMECA Ada variasi yang sangat
banyak didalam industri didalam mengimplementasikan analisis FMEA.
Sejumlah standar – standar dan aturan telah dikembangkan untuk menentukan
kebutuhan – kebutuhan untuk analisis dan setiap organisasi dapat melakukan
pendekatan yang berbeda didalam melakukan analisis.
35
3.7.1 Keuntungan FMEA
Keuntungan dari FMEA
- Produk akhir harus “aman”, FMEA membantu desainer untuk mengidentifikasi
dan mengeliminasi atau mengendalikan cara kegagalan yang berbahaya,
meminimasi kerusakan terhadap sistem dan penggunanya.
- Meningkatnya keakuratan dari perkiraan terhadap peluang dari kegagalan yang
akan dikembangkan, khususnya juga data dari peluang realibilitas didapat
dengan menggunakan FMECA.
- Realibilitas dari produk akan meningkat
Waktu untuk melakukan desain akan dikurangi berkaitan dengan melakukan
identifikasi dan perbaikan dari masalah – masalah.
3.7.2 Process FMEA
Process FMEA merupakan sebuah teknik analisis yang digunakan oleh tim
manufacturing yang bertanggung jawab untuk meyakinkan bahwa untuk
memperluas kemungkinan cara – cara kegagalan dan mencari penyebab yang
berkaitan yang telah dipertimbangkan dan dituangkan kedalam bentuk form yang
tepat, sebuah FMEA merupakan ringkasan dari pemikiran tim engineering (
termasuk analisa dari item-item yang dapat berjalan tidak sesuai dengan keinginan
berdasarkan pengalaman dan pemikirian masa lalu ) sebagaimana proses
dikembangkan. ( FMEA Team,1995, p27)
Proses FMEA
- Mengidentifikasi produk yang potensial yang berkaitan dengan cara – cara
kegagalan proses
36
- Memperkirakan efek bagi konsumen yang potensial yang disebabkan oleh
kegagalan
- Mengidentifikasi sebab – sebab yang potensial pada proses perakitan dan
mengidentifikasi variabel – variabel pada proses yang berguna untuk
menfokuskan pada pengendalian untuk mengurangi kegagalan atau
mendeteksi keadaan – keadaan kegagalan
- Mengembangkan sebuah daftar peringkat dari cara – cara kegagalan yang
potensial, ini menetapkan sebuah sistem prioritas sebagai pertimbangan untuk
melakukan tindakan perbaikan
- Mendokumentasikan hasil – hasil dari proses produksi atau proses perakitan
3.7.3 Risk Priority Numbers In FMEA
Metodologi Risk Priority Number ( RPN ) merupakan sebuah teknik untuk
menganalisa resiko yang berkaitan dengan masalah – masalah yang potensial
yang telah diidentifikasi selama membuat FMEA. (Stamatis,D.H, 1995, p445).
Sebuah FMEA dapat digunakan untuk mengidentifikasi cara – cara kegagalan
yang potensial untuk sebuah produk atau proses. Metode RPN kemudian
memerlukan analisa dari tim untuk menggunakan pengalaman masa lalu dan
keputusan engineering untuk memberikan peringkat pada setiap potensial
masalah menurut rating skala berikut :
- severity, merupakan skala yang memeringkatkan severity dari efek – efek
yang potensial dari kegagalan
- occurrence, merupakan skala yang memeringkatkan kemungkian dari
kegagalan akan muncul
37
- Detection, merupakan skala yang memeringkatkan kemungkinan dari
masalah akan dideteksi sebelum sampai ke tangan pengguna akhir atau
konsumen
Skala dari peringkat biasanya dimulai dari 1 -5 atau dari 1 -10, dengan no yang
tertinggi mewakili tingkat yang paling serius atau yang paling beresiko.
Tabel 3.1 Severity scale
Sumber : http://www.reliasoft.com
Setelah pemberian rating dilakukan, nilai RPN dari setiap penyebab kegagalan
dihitung dengan rumus
RPN = Severity x Occurrence x Detection
Nilai RPN dari setiap masalah yang potensial dapat kemudian digunakan untuk
membandingkan penyebab – penyebab yang teridentifikasi selama dilakukan
analisis. Pada umumnya, jika RPN jatuh diantara batas yang ditentukan, tindakan
perbaikan dapat diusulkan atau dilakukan untuk mengurangi resiko. Ketika
menggunakan teknik risk assessment, sangat pening untuk mengingat bahwa
tingkat RPN adalah relatif terhadap analisis tertentu ( dilakukan dengan sebuah
set skala peringkat yang umum dan analisis tim yang berusaha untuk membuat
38
peringkat yang konsisten untuk semua penyebab masalah yang teridentifikasi
selama melakukan analisis). Untuk itu, sebuah RPN didalam satu analisis dapat
dibandingkan dengan RPN yang lainnya didalam analisis yang sama, tapi dapat
menjadi tidak dapat dibandingkan terhadap RPN pada analisis yang lain
Meskipun ada banyak tipe dan standard, kebanyakan FMEA terdiri dari suatu
kumpulan prosedur yang umum. Secara umum, analisis FMEA dipengaruhi oleh
tim yang bekerja secara cross function pada tahap yang bervariasi pada waktu
desain, proses pengembangan dan perakitan dan pada umumnya terdiri dari :
- Item / Process : Mengidentifikasi item atau proses yang akan menjadi
subjek dari analisis, termasuk beberapa penyelidikan terhadap desain dan
karakteristik – karakteristik reabilitas. Untuk analisis FMEA pada produk
atau sistem, analisisnya dapat dilakukan pada sistem, subsistem,
komponen atau level yang pada pada pengaturan sistem
- Function : mengidentifikasi fungsi – fungsi dimana item atau proses
diharapkan untuk bekerja
- Failures : mengidentifikasi kegagalan yang diketahui dan potensial yang
dapat mencegah atau menurunkan kemampuan dari item atau proses
untuk bekerja sesuai dengan fungsinya
- Failure effect : mengidentifikasi efek – efek yang diketahui dan potensial
yang mungkin muncul dari setiap kegagalan yang terjadi
- Failure cause : mengidentifikasi penyebab yang diketahui dan potensial
untuk setiap kegagalan
- Current control : memeriksa mekanisme kontrol yang akan ada untuk
mengeliminasi atau menurunkan kemungkinan kegagalan akan muncul
39
- Recommended action : mengidentifikasi tindakan perbaikan yang perlu
dilakukan yang bertujuan untuk mengeliminasi atau menurunkan resiko
dan dilanjutkan dengan melengkapinya dengan melakukan recommended
action
- Prioritize issues : memprioritaskan tindakan perbaikan yang harus
dilakukan menurut standard yang konsisten yang telah ditentukan oleh
perusahaan. Peringkat RPN adalah metode yang umum untuk
memprioritaskan.
- Other details : tergantung pada situasi tertentu dan petunjuk untuk
melakukan analisa yang diadaptasi oleh perusahaan, keterangan yang lain
mungkin dipertimbangkan selama melakukan analisis, seperti cara
operasional ketika kegagalan muncul.
- Report : Membuat laporan dari analisis dalam bentuk format standard
yang telah ditentukan oleh perusahaan. Ini pada umumnya berbentuk
format tabel. Sebagai tambahan laporan dapat menyertakan diagram
berbentuk blok dan / atau diagram alir untuk mengilustrasikan item atau
proses yang merupakan subjek dari analisis.
Memprioritaskan masalah berdasarkan RPN
Seperti yang telah disebutkan, kebanyakan analisis FMEA termasuk melakukan
usaha untuk memprioritaskan masalah untuk menentukan urutan dan jadwal
waktu untuk melakukan tindakan perbaikan yang akan dilakukan. Meskipun
metode yang digunakan untuk menentukan prioritas ini akan bervariasi
tergantung dari perusahaan, 2 metode yang paling umum digunakan adalah Risk
Priority Numbers dan Critically Analysis
40
Risk Priority Number
Sistem RPN merupakan sebuah sistem yang relatif untuk menentukan rating
yang menentukan angka atau nilai terhadap masing – masing permasalahan
dalam tiga kategori yang berbeda: Severity (S), Occurrence (O), dan Detection
(D). Ketiga kategori dikalikan nilainya untuk menentukan keseluruhan RPN dari
masalah. Skala dari pemeringkatan pada umumnya berkisar antara 1 hingga 5
atau dari 1 hingga 10 dan kriteria yang digunakan pada setiap skala dari
pemeringkatan akan ditentukan berdasarkan keadaan tertentu dari produk atau
proses yang sedang dianalisa. Karena semua permasalahan diperingkatkan
berdasarkan sekumpulan tingkat skala, nilai ini dapat digunakan untuk
membandingkan dan membuat peringkat dari permasalahan yang dianalisis.
Bagaimanapun juga, karena pemeringkatan ditentukan relatif berkaitan dengan
analisis tertentu. Secara umum tidak tepat untuk membandingkan nilai RPN
diantara analisa yang berbeda. RPN dihitung dengan rumus sebagai berikut :
RPN = ( S ) x ( O ) x ( D )
Dimana:
- Severity ( S ) : Sebuah ranking dari severity atau keseriusan dari setiap
efek dari kegagalan yang potensial
- Occurrence ( O ) : Sebuah ranking dari kemungkinan dari kejadian dari
setiap penyebab kegagalan yang potensial
- Detection ( D ) : Sebuah ranking dari kemungkinan untuk mendeteksi
penyebab dari kegagalan
41
3.8 Pengertian Sistem
Definisi sistem menurut Raymond McLeod, Jr. adalah : A system is a group of
elements that are integrated with the common purpose of achieving an objective.
Dengan kata lain sistem adalah suatu integrasi dari unsur – unsur yang bekerja untuk
mencapai suatu tujuan.
Model dasar dari sistem adalah sebagai berikut :
a. Input
Merupakan kumpulan dari data baik dari luar organisasi maupun dari dalam
organisasi yang akan digunakan dalam proses sistem informasi.
b. Process
Merupakan kegiatan konversi, manipulasi, dan analisis dari yang tadinya
hanya berupa data input menjadi lebih berarti bagi penggunanya.
c. Output
Merupakan proses untuk melakukan penyebaran informasi kepada orang atau
kegiatan yang memerlukannya.
d. Feedback
Merupakan output yang dikembalikan lagi kepada orang-orang dalam
organisasi untuk membantu dalam melakukan evaluasi input.
e. Subsistem
Merupakan sebagian dari sistem yang mempunyai fungsi khusus. Masing –
masing subsistem itu sendiri memiliki komponen input, proses, output, dan
feedback.
42
3.9 Pengertian Informasi
Menurut Jogiyanto HM informasi merupakan data yang diolah menjadi
bentuk yang lebih berguna dan lebih berarti bagi yang menerimanya. Informasi
sangat dibutuhkan karena informasi merupakan suatu dasar dalam mengambil
keputusan dalam perusahaan. Sedangkan definisi informasi menurut Steven Alter
adalah : Information is useful data whose form and content are relevant and
appropriate for a particular use.
3.10 Sistem Informasi
Merupakan suatu alat bantu yang dirancang untuk membantu tingkat
manajemen organisasi dengan menyediakan informasi yang berguna di dalam
pengambilan keputusan organisasi baik pada tingkat perencanaan strategis,
perencanaan manajemen maupun perencanaan operasi untuk mencapai tujuan
organisasi. Adapun komponen – komponen dari sistem informasi adalah metode
kerja (work practices), informasi (information), manusia (people), teknologi
informasi (information technologies).
Alasan diperlukannya sistem informasi dalam suatu organisasi ialah
sebagai berikut :
a. Untuk sinkronisasi aktivitas – aktivitas dalam organisasi sehingga semua
sumber daya dapat dimanfaatkan seefektif mungkin.
b. Perkembangan teknologi yang semakin kompleks.
c. Semakin pendeknya waktu untuk pengambilan keputusan.
d. Lingkungan bisnis yang semakin kompetitif.
e. Pengaruh kondisi ekonomi international.
43
f. Meningkatnya kompleksitas dari aktivitas bisnis / organisasi.
Dalam suatu organisasi, sistem informasi memiliki beberapa peranan
dasar yaitu sistem informasi berusaha memberikan informasi aktual tentang
lingkungan dari organisasi tersebut sehingga organisasi mendapat gambaran
yang akurat tentang lingkungannya. Selain itu dengan aliran informasinya, sistem
informasi berusaha agar elemen – elemen di dalam organisasi selalu kompak dan
harmonis dimana tidak terjadi duplikasi kerja dan lepas satu sama lain. Dengan
demikian dapat dilihat bahwa manfaat dari sistem informasi ialah : Menjadikan
organisasi lebih efisien dan lebih efektif, lebih cepat tanggap dalam merespon
perubahan, mengelola kualitas output, memudahkan melakukan fungsi kontrol,
memprediksi masa depan, melancarkan operasi organisasi, menstabilkan
beroperasinya organisasi, membantu pengambilan keputusan.
3.11 Decision Support System (DSS)
Konsep ini dimulai oleh para ahli dari Massachusetts Institute of
Technology (MIT) yaitu : Michael S. Scott Morton, G. Anthony Gorry, dan Peter
G. W. Keen pada tahun 1971. Menurut mereka DSS adalah : Information-
producing system aimed at a particular problem a manager must solve, and
decisions that must be made.
Definisi lain DSS yang dijelaskan oleh Raymond McLeod,Jr. yaitu :
Decision support system is a system that supports a single manager, or a
relatively small group of managers working as a problem solving team, in the
solution of a semistructured problem by providing information or suggestions
concerning specific decisions.
44
DSS memberikan dukungan dalam pengambilan keputusan dengan lebih
aktif melibatkan para manajer. Lain halnya dengan sistem informasi manajemen
yang lebih bersifat pasif dengan hanya menyediakan informasi yang masih harus
diinterpretasikan dan dianalisis oleh manajer. Sistem ini mendukung keputusan
dalam situasi yang semi terstruktur atau tidak terstruktur dengan menyediakan
metode yang fleksibel dalam menampilkan dan menganalisa data serta
memformulasikan dan mengevaluasi alternatif keputusan.
Ada beberapa type dari DSS diantaranya yaitu DSS yang membantu
dalam menampilkan kembali elemen – elemen informasi, dan DSS yang
membantu dalam menyiapkan laporan – laporan standard. Selain kedua tipe DSS
tersebut di atas juga terdapat DSS yang melibatkan penggunaan model
matematis, yaitu DSS yang dapat membantu dalam mengestimasi konsekuensi
dari keputusan yang diambil (model What-If), DSS yang dapat memberikan
usulan solusi, dan DSS yang dapat membuat keputusan. Tipe DSS yang terakhir
ini merupakan DSS yang tertinggi tingkatannya.
Tujuan dari DSS adalah DSS diharapkan dapat :
- Membantu para manajer dalam membuat keputusan untuk menyelesaikan
masalah – masalah semistructured
- Dapat mendukung penilaian para manajer terhadap permasalahan yang
dihadapi dan keputusan yang akan diambil
- Serta dapat meningkatkan efektifitas pengambilan keputusan oleh para
manajer.
45
3.12 Metodologi Pemodelan Berorientasi Objek
3.12.1 Object Orientation
Proses untuk mengembangkan sistem software dimulai dari sebuah tahap
dimana kebutuhan dari produk software yang akan dikembangkan
dikumpulkan dan dianalisa. Tahap yang berikutnya adalah spesifikasi atau
model dari program yang akan dikembangkan dikonstruksi. Spesifikasi ini
harus lengkap, benar dan ekonomis. Pada tahap akhir dari spesifikasi ini
dirubah menjadi program yang dapat dieksekusi. ( C.Pronk, 1994, p5 )
Selama analisis, kebutuhan fungsional dan non fungsional dari sistem
yang akan dikembangkan dikumpulkan, berikut ini merupakan kategori dari
kebutuhan – kebutuhan yang diperlukan :
- Kebutuhan level managemen, seperti : produk harus selesai tepat waktu dan
diantar dengan harga yang tetap
- Kebutuhan level programming, seperti : program harus benar dan sesuai
dengan spesifikasi , data harus dapat diproses dengan benar, dan hasil dari
perhitungan harus tersedia pada waktunya.
- Kebutuhan non fungsional, seperti : program harus disiapkan dimana
nantinya dapat dimaintain, ditest, dimodifikasi, diperluas, dan portable
Selama masa transformasi dari spesifikasi ke implementasi banyak pilihan
yang dibuat , dan sebagian besar dari pilihan ini dipengaruhi oleh kebutuhan
yang non fungsional. Sangat disayangkan proses pengembangan software
menjadi tidak dapat dikendalikan dengan baik karena tidak dapat memenuhi
semua kategori kebutuhan yang diperlukan. Untuk mengatasi masalah ini banyak
46
metode untuk pengembangan software telah dikembangkan dan pada akhirnya
mengarah kepada metode yang baru yang mengarah kepada object orientation.
3.12.2 Object Oriented Methods
Object oriented methods merupakan sebuah teknik untuk memodelkan
sistem, teknik untuk me-manage kekompleksan yang muncul dalam analysis,
design dan implementation, metode ini digunakan dalam hal analisis dan desain
sistem, menyediakan pandangan yang terintegrasi antara software dengan
hardware, dan menyediakan metodologi untuk melakukan pengembangan
sistem ( Henry Lau, 2003 p4 ).
3.12.3 Keuntungan Object Oriented
Berikut beberapa keuntungan dari penggunaan object oriented :
- Merupakan konsep umum yang dapat digunakan untuk memodelkan hampir
semua phenomena dan dapat dinyatakan dalam bahasa yang umum
- Memberikan informasi yang jelas tentang context system
- Mengurangi biaya maintenance
Memudahkan untuk mencari hal yang diubah dan membuat perubahan
menjadi lokal sehingga tidak berpengaruh pada modul yang lainnya.
3.12.4 3 Karakteristik Object Oriented
3.12.4.1 Encapsulation
Menurut Ronald J. Norman, Ph.D., CCP encapsulation adalah A
technique in which data are packaged together with their corresponding
47
procedures. Dengan kata lain merupakan sebuah teknik dimana data disatukan
kedalam paket dengan prosedur yang berkaitan dengannya, pada object
oriented paket itu disebut dengan object dimana interface yang terlibat pada
setiap object dibuat dengan cara sesedikit mungkin dapat diketahui tentang cara
kerja didalamnya. Encapsulation adalah menyembunyikan cara
pengimplementasian suatu benda dari pengguna, sehingga pengguna hanya
tergantung dan berhubungan dengan interface luarnya saja. Ini akan
memungkinkan pengguna untuk mengoperasikan suatu sistem tanpa harus
mengetahui cara/mekanisme implementasi dari antarmukanya.
Gambar 3.2 Encapsulation
Sumber : Object Oriented Analysis Design And Methodology
3.12.4.2 Inheritance
Menurut Ronald J. Norman, Ph.D., CCP inheritance adalah A
mechanism for expressing similarity between things thus simplifying their
definition. Dengan kata lain merupakan sebuah mekanisme untuk
mengekspresikan kesamaan diantara object dan menyederhanakan definisinya.
Object memiliki banyak persamaan, namun ada sedikit perbedan.
Contoh dengan beberapa buah mobil yang mempunyai kegunaan yang
berbeda-beda. Ada mobil bak terbuka seperti truk, bak tertutup seperti sedan
48
dan minibus. Walaupun demikian object-object ini memiliki kesamaan yaitu
teridentifikasi sebagai object mobil, object ini dapat dikatakan sebagai object
induk (parent). Sedangkan minibus dikatakan sebagai object anak (child), hal
ini juga berarti semua operasi yang berlaku pada mobil berlaku juga pada
minibus.
Diagram 3.3 Contoh Inheritance
Sumber : Object Oriented Analysis Design And Methodology
3.12.4.3 Polimorphism
Menurut Ronald J. Norman, Ph.D., CCP polimorphism adalah the ability
to hide different implementations behind a common interface, the ability for
two or more objects to respond to the same request, each in its own way.
Polymorphism dengan kata lain adalah kemampuan dari tipe object yang
berbeda untuk menyadari property dan operasi yang sama dalam hal yang
berbeda.
Contohnya kita mempunyai antar muka bernama printer, dengan operasi
cetak, kita menerapkannya pada object text, graphic, dan image, maka jika
melakukan perintah cetak kepada semua object maka semua object akan
mengimplemetasikan perintah tersebut dengan menghasilkan output yang
bebeda-beda, walaupun dengan satu perintah dari antar muka yang sama.
49
Gambar 3.3 Contoh Polimorphism
Sumber : Object Oriented Analysis Design And Methodology
3.13 Unified Modelling Language (UML)
3.13.1 Sejarah UML
UML (Unified Modeling Language) dikembangkan dengan tujuan
untuk menyederhanakan dan mengkonsolidasikan sejumlah besar metode
pengembangan object oriented yang muncul. Metode pengembangan untuk
bahasa pemrograman tradisional muncul pada tahun 1970 an dan menjadi
menyebar pada tahun 1980 an. Yang paling terkenal diantaranya adalah
structured analysis and structured design [ Yourdon - 79 ] ( James Rumbaugh,
1999, p4 )
Pendekatan analisa & rancangan dengan menggunakan model OO
mulai diperkenalkan sekitar pertengahan 1970 hingga akhir 1980 dikarenakan
pada saat itu aplikasi software sudah meningkat dan mulai komplek. Jumlah
yang menggunakaan metoda OO mulai diuji coba dan diaplikasikan antara
1989 hingga 1994, seperti halnya oleh Grady Booch dari Rational Software
Co., dikenal dengan OOSE (Object-Oriented Software Engineering), serta
James Rumbaugh dari General Electric, dikenal dengan OMT (Object
Modelling Technique).
50
Kelemahan saat itu disadari oleh Booch maupun Rumbaugh adalah
tidak adanya standar penggunaan model yang berbasis OO, ketika mereka
bertemu ditemani rekan lainnya Ivar Jacobson dari Objectory mulai
mendiskusikan untuk mengadopsi masing-masing pendekatan metoda OO
untuk membuat suatu model bahasa yang uniform / seragam yang disebut
UML (Unified Modeling Language) dan dapat digunakan oleh seluruh dunia.
Ada beberapa usaha awal untuk menyatukan konsep diantara berbagai
metode yang muncul. Salah satunya adalah penyatuan yang dilakukan oleh
Coleman dan koleganya [ Coleman – 94 ], yang memasukkan konsep dari
OMT [ Rumbaugh – 91 ], Booch [ Booch – 91 ], dan CRC [ Wirfs-Brock- 90 ].
Dimana usaha tersebut tidak melibatkan pencetus yang aslinya, hasilnya
dianggap sebagai sebuah metode baru yang menggantikan beberapa metode
yang lain. Pada tahun 1996 Object Management Group ( OMG ) memunculkan
permintaan untuk proposal untuk sebuah pendekatan yang standar untuk object
oriented modeling . Pencetus UML Booch, Jacobson dan Rumbaugh mulai
bekerja dengan para metodologis dan pengembang dari perusahaan lain untuk
membuat sebuah proposal yang menarik bagi anggota OMG agar modeling
languange dapat diterima oleh para pencetus, metodologis, dan pengembang.
Akhirnya proposal diserahkan ke OMG pada september 1997. Hasil akhirnya
adalah kolaborasi dari banyak orang, dan pada November 1997 dibuat sebuah
standardnya [ UML – 98 ].
UML adalah standar dunia yang dibuat oleh Object Management Group
(OMG), sebuah badan yang bertugas mengeluarkan standar-standar teknologi
51
object-oriented dan software component. (Booch, Rumbaugh, Jacobson, 1999,
p6 )
3.13.2 Konsep Bahasa UML
Unified Modeling Language (UML) merupakan bahasa modeling visual
yang digunakan untuk menspesifikasi, visualisasi konstruksi, dan dokumentasi
dari sebuah sistem software. UML menangkap keputusan dan pengertian dari
sebuah sistem yang harus dikonstruksi, digunakan untuk mengerti, mendesain,
menelusuri, mengatur, menjaga dan mengendalikan informasi dari sebuah
sistem. Ditujukan untuk digunakan dengan semua metode pengembangan,
tahap lifecycle, application domain, dan media (Booch, Rumbaugh, Jacobson,
1999, p3 )
3.13.3 Kegunaan UML
UML diperuntukan untuk pemakaian sistem software yang intensif.
(Booch, Rumbaugh, Jacobson, 1999, p17), Ada banyak tujuan dibelakang
pengembangan dari UML, yang paling pertama dan penting adalah agar dapat
digunakan oleh semua pengembang atau modelers,dan tujuan akhir dari UML
adalah untuk menjadi sesederhana mungkin selama masih memenuhi
kebutuhan untuk melakukan modeling pada sistem yang akan dibangun.
52
3.13.4 Problem Domain Analysis
3.13.4.1 Class
Class : A description of a collection of objects sharing structure,
behavioural pattern, and attribute ( Mathiassen, Lars., 2000, p53 ). Class
adalah kelompok object yang membagi struktur (instance variables) dan
kelakuan (methods) dan turunan dari object (inheritance).
Gambar 3.4 Contoh Class
Sumber : Object Oriented Analysis Design And Methodology
3.13.4.2 Object
Object : An entity with identity, state, and behaviour ( Mathiassen, Lars.,
2000, p51 ). Dalam analisis object merupakan abstraksi dari situasi yang ada
didalam konteks sistem. Object menggambarkan apa yang menjadi pandangan
user dalam dunia nyata. Object didefinisikan sebagai sebuah entity yang
memiliki identity, state, dan behaviour.
Untuk memanggil sesuatu sebagai object kita harus dapat untuk
mendeskripsikannya sebagai sebuah entity, identity dari object adalah property
53
yang memisahkannya dari object – object yang lainnya, semua object harus
memiliki identity agar kita dapat membedakannya dari object yang lainnya.
State dari object terdiri dari atribut yang bersifat statis dan dinamis. Behaviour
dari object merupakan rangkaian dari event yang baik secara aktif atau pasif
dilakukan oleh object selama daur hidupnya.
3.13.4.3 Event
Event : An instantaneous incident involving one or more objects (
Mathiassen, Lars., 2000, p51 ). Event merupakan abstraksi dari problem
domain activity atau proses yang dilakukan atau dialami oleh satu atau lebih
objects.
3.13.4.4 Class Diagram
Class diagram menggambarkan sekumpulan class, interface, dan
collaboration, dan relasi-relasinya. Class diagram juga menunjukkan atribut
(attribute) dan operasi (operation) dari sebuah object class. Atribut adalah
nama-nama properti dari sebuah kelas yang menjelaskan batasan nilainya dari
properti yang dimiliki oleh sebuah kelas tersebut. Atribut dari suatu kelas
merepresentasikan properti-properti yang dimiliki oleh kelas tersebut. Operasi
adalah implementasi dari layanan yang dapat diminta dari sebuah object dari
sebuah kelas yang menentukan tingkah lakunya. Sebuah operasi dapat berupa
perintah ataupun permintaan. Sebuah permintaan tidak boleh mengubah
kedudukan dari object tersebut. Hanya perintah yang dapat mengubah keadaan
54
dari sebuah object. Keluaran dari sebuah operasi tergantung dari nilai keadaan
terakhir dari sebuah object.
Hubungan antar kelas digambarkan dengan notasi-notasi, antara lain:
• Generalization
Generalization : A general class ( the super class ) describes properties
common to a group of specialized classes ( the subclasses ) ( Mathiassen,
Lars., 2000, p72 ). Menggambarkan hubungan antara dua atau lebih class
dan sebuah class yang lebih general.
Diagram 3.4 Generalization Structure
Sumber : Object Oriented Analysis Design And Methodology (2000)
• Aggregation
Aggregation : A superior object ( the whole ) consists of a number of
inferior objects ( the parts ) ( Mathiassen, Lars., 2000, p76 ).
Menggambarkan hubungan antara dua atau lebih object yang
mengekspresikan bahwa salah satu object adalah dasarnya dan
mendefinisikan bagian yang lainnya.
55
Diagram 3.5 Aggregation Structure
Sumber : Object Oriented Analysis Design And Methodology (2000)
• Composition Structure
Composition adalah strong aggregation. Pada composition, object “bagian”
tidak dapat berdiri sendiri tanpa object “keseluruhan”. Jadi mereka terkait
dengan kuat satu dengan yang lainnya.
Company Departmen
1 * Diagram 3.6 Composition Structure
Sumber : Object Oriented Analysis Design And Methodology (2000)
• Association Structure
Association : A meaningful relation between a number of objects
(Mathiassen, Lars., 2000, p77 ) . Menggambarkan hubungan antara dua
atau lebih object tapi berbeda dengan aggregation dimana object yang
tergabung tidak didefinisikan sebagai properti dari sebuah object.
Umumnya association digambarkan dengan sebuah garis diantara class
yang relevan
56
Diagram 3.7 Association Structure
Sumber : Object Oriented Analysis Design And Methodology (2000)
3.13.4.5 Behavioural Pattern
Behavioural Pattern : A description of possible event traces for all
objects in a class ( Mathiassen, Lars., 2000, p90 ). Object merupakan sebuah
entitas yang memiliki identity, state, dan behaviour. Behaviour merupakan
sekumpulan dari event dalam urutan yang tidak teratur yang melibatkan sebuah
object. Tujuan dari behaviour activity ini 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.13.4.6 Statechart Diagram
Menggambarkan behaviour dari sebuah sistem. Statechart diagram
menunjukkan state-state yang mungkin dijalankan oleh sebuah object dan
bagaimana state object tersebut menjalankannya berubah sebagai hasil dari
event-event yang mencapai object tersebut. Notasi-notasi dalam statechart
diagram dapat dilihat pada contoh statechart untuk customer bank di bawah ini.
57
Open
[amount,date] / Amount deposited
[date,amount] / Amount withdrawn
[date] / Account opened [date] / Amount closed
Diagram 3.8 Statechart Diagram
Sumber : Object Oriented Analysis Design And Methodology (2000)
3.13.4.7 Sequence Diagram
Sequence diagram adalah sebuah interaction diagram yang
menekankan pada urutan waktu penyampaian dari suatu pesan.
Diagram 3.9 Sequence Diagram
Sumber : Object Oriented Analysis Design And Methodology (2000)
3.13.5 Application Domain Analysis
3.13.5.1 Use Case
Use case : A pattern for interaction between the system and actors in the
application domain. ( Mathiassen, Lars., 2000, p120 ).
Actor : An abstraction of users or other systems that interact with the target
system. ( Mathiassen, Lars., 2000, p119 ).
58
Fungsi dari sistem digambarkan dalam use case yang berbeda, mewakilkan
aliran yang khusus dari kejadian (event) dalam sistem. Use case adalah
sekumpulan pola interaksi antara sistem dan actor dan hubungannya.
Gambar 3.5 Use case
Sumber : http://www.soden.ee/~margus2/UML
3.13.5.2 Function
Function : A facility for making a mode useful for actors. ( Mathiassen, Lars.,
2000, p138 ). Sebuah fungsi diaktifkan, dieksekusi dan menyediakan hasil,
eksekusi dari fungsi dapat menciptakan sebuah reaksi pada application domain
atau problem domain. Ada 4 tipe dari fungsi yaitu : Update, Signal, Read, dan
Compute
59
Gambar 3. 6 Function
Sumber : Object Oriented Analysis & Design, (2000).
3.13.5.3 Interface
Interface : Facilities that make a system’s and functions available to actors.
(Mathiassen, Lars., 2000, p151 ). Interface merupakan fasilitas yang membuat
model dan function dapat berinteraksi dengan actor, dimana user interface
merupakan interface yang digunakan untuk berhubungan dengan user.
3.13.6 Architecture Design
Architectural design bertujuan untuk membuat struktur dari sistem yang
terkomputerisasi dengan prinsip menentukan dan memprioritaskan kriteria,
menjembatani kriteria dengan technical platform, mengevaluasi design lebih
dini. Hasilnya adalah struktur untuk sebuah komponen – kompenen sistem dan
proses.
60
Component achitecture: A system structure composed of interconected
components (Mathiassen, Lars., 2000, p190 )
Component : A collection of program parts that constitutes a whole and has
well defined responsibilities (Mathiassen, Lars., 2000, p190 )
Tujuan dari component achitecture adalah untuk menciptakan sebuah
struktur sistem yang komprehensif dan fleksibel dengan mengacu kepada
prinsip : mengurangi kompleksitas dengan memisahkan beberapa bagian yang
perlu diperhatikan, merefleksikan konteks struktur yang stabil, menggunakan
komponen yang sudah ada.
Diagram 3.10 Component Architecture
Sumber : Object Oriented Analysis & Design, (2000).
Deployment diagram merupakan diagram yang menggambarkan konfigurasi
dari node-node run time processing dan komponen-komponen yang berada di
dalamnya.
61
Server:BankServer
:Transactions
«table»AccountDB : Account
Interface1
client:ATMKiosk
:ATM-GUI
Diagram 3.11 Deployment Diagram
Sumber : Object Oriented Analysis & Design, (2000).
3.13.7 Component Design
Component design bertujuan untuk menentukan implementasi dari
kebutuhan – kebutuhan yang berada didalam architectural framework dengan
prinsip tidak mengganggu component architecture , mengadaptasi component
design yang berkaitan dengan hal – hal teknik. Hasilnya adalah sebuah
deskripsi dari system components.