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
Jenis Data
Atribut
Variabel
Ukuran Sampel
Kecacatan Defective
Cacat Defect
n>25
12
n<12
n=1
x, σ
x, s
x, R
x, MR
n = tetap
n = tetap
n = tetap
n = tetap
C
U
NP
P
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.
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 x ± 3σ 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 :
ΣR k
Rata rata R
R=
Batas kendali
UCLR = D4 R LCL R = D3 R
Σx k
Rata rata x
x=
Batas kendali
UCLx = x + A2 R LCL x = x − A2 R
•
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
Cp =
USL − LSL 6σ
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σ .
Cpk =
min imum SL − x 3σ
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
-
3.7.3
Mendokumentasikan hasil – hasil dari proses produksi atau proses perakitan
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 : Informationproducing 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
mengekspresikan
bahwa
antara
salah
satu
mendefinisikan bagian yang lainnya.
dua
atau
object
lebih adalah
object
yang
dasarnya
dan
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
[date,amount] / Amount withdrawn
[date] / Account opened
[date] / Amount closed Open
[amount,date] / Amount deposited
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 «table» AccountDB : Account
:Transactions
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.
