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.