Process Statistical Control-Vincent

53
BAB 3 LANDASAN TEORI 3.1. Pengertian Kualitas Kualitas dapat diartikan dalam banyak hal. Secara umum, kualitas adalah pemenuhan kebutuhan, harapan dan kepuasan pelanggan. Menurut Douglas C. Montgomery (2001, p4) pengertian kualitas dahulu (tradisional) dan sekarang (modern) berbeda. Dahulu, kualitas diartikan sebagai “fitness for use”, yaitu berdasarkan pandangan bahwa produk dan jasa harus memenuhi kebutuhompan pengguna. Sedangkan pengertian kualitas sekarang berbanding terbalik dengan variabilitas, di mana bila variabilitas kecil maka kualitas dari produk meningkat.tius Dahulu produk dan jasa diharapkan hanya dapat memenuhi kebutuhan pengguna, sedangkan sekarang ini karakteristik kualitas yang diperhatikan oleh pelanggan bukan hanya penilaian terhadap seberapa baik suatu produk diproduksi, tetapi juga menyangkut hal-hal seperti harga, jasa, syarat pembayaran, gaya, ketersediaan, frekuensi diperbaharui dan ditingkatkan secara dukungan teknik (Pyzdek, 2002, p119). Dalam konteks pembahasan tentang pengendalian proses statistikal, terminologi kualitas didefinisikan sebagai konsistensi peningkatan atau perbaikan dan penurunan variasi karakteristik dari suatu produk (barang atau jasa) yang dihasilkan, agar memenuhi kebutuhan yang telah dispesifikasikan, guna meningkatkan kepuasan pelanggan internal maupun eksternal (Vincent Gaspersz, 1998, p1).

description

Vincent GasperProcess Statistical Control

Transcript of Process Statistical Control-Vincent

BAB 3

LANDASAN TEORI

3.1. Pengertian Kualitas

Kualitas dapat diartikan dalam banyak hal. Secara umum, kualitas adalah

pemenuhan kebutuhan, harapan dan kepuasan pelanggan. Menurut Douglas C.

Montgomery (2001, p4) pengertian kualitas dahulu (tradisional) dan sekarang (modern)

berbeda. Dahulu, kualitas diartikan sebagai “fitness for use”, yaitu berdasarkan

pandangan bahwa produk dan jasa harus memenuhi kebutuhompan pengguna.

Sedangkan pengertian kualitas sekarang berbanding terbalik dengan variabilitas, di mana

bila variabilitas kecil maka kualitas dari produk meningkat.tius

Dahulu produk dan jasa diharapkan hanya dapat memenuhi kebutuhan pengguna,

sedangkan sekarang ini karakteristik kualitas yang diperhatikan oleh pelanggan bukan

hanya penilaian terhadap seberapa baik suatu produk diproduksi, tetapi juga menyangkut

hal-hal seperti harga, jasa, syarat pembayaran, gaya, ketersediaan, frekuensi

diperbaharui dan ditingkatkan secara dukungan teknik (Pyzdek, 2002, p119).

Dalam konteks pembahasan tentang pengendalian proses statistikal, terminologi

kualitas didefinisikan sebagai konsistensi peningkatan atau perbaikan dan penurunan

variasi karakteristik dari suatu produk (barang atau jasa) yang dihasilkan, agar

memenuhi kebutuhan yang telah dispesifikasikan, guna meningkatkan kepuasan

pelanggan internal maupun eksternal (Vincent Gaspersz, 1998, p1).

28

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. Spesifikasi dan

toleransi yang ditetapkan oleh bagian desain produk harus berorientasi kepada

kebutuhan atau keinginan konsumen atau orientasi pasar (Vincent Gaspersz, 1998, pp1-

2).

3.2. Statistical Process Control (SPC)

3.2.1. Pengertian Statistical Process Control (SPC)

Pengendalian Proses Statistikal (Statistical Process Control = SPC)

adalah suatu terminologi yang mulai digunakan sejak tahun 1970-an untuk

menjabarkan penggunaan teknik-teknik statistikal (statistical technique) 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 atau SQC) yang

memiliki pengertian sama dengan Pengendalian Proses Statistikal (Statistical

Process Control = SPC) (Vincent Gaspersz, 1998, p1).

Pengendalian kualitas merupakan aktivitas teknik dan manajemen,

melalui pengukuran 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.

29

Pengendalian proses statistikal merupakan suatu metodologi

pengumpulan dan analisa data kualitas, serta penentuan dan interpretasi

pengukuran – pengukuran yang menjelaskan tentang proses dalam suatu sistem

industri, untuk meningkatkan kualitas dari output guna memenuhi kebutuhan dan

harapan pelanggan.

3.2.2. Tujuan dari Statistical Process Control (SPC)

Menurut Douglas C. Montgomery (2001, p154) Statistical Process

Control (SPC) adalah kumpulan dari tools (seven tools) yang digunakan untuk

pemecahan masalah sehingga tercapai kestabilan proses dan peningkatan

kapabilitas dengan pengurangan variasi.

Berikut adalah beberapa tujuan utama dari SPC menurut Gerald Smith

(1996, p4):

1. Meminimasi biaya produksi.

2. Memperoleh kekonsistenan terhadap produk dan servis yang memenuhi

spesifikasi produk dan keinginan konsumen.

3. Menciptakan peluang-peluang untuk semua anggota dari organisasi untuk

memberikan kontribusi terhadap peningkatan kualitas.

4. Membantu manajemen dan karyawan produksi untuk membuat keputusan

yang ekonomis mengenai tindakan yang diambil yang dapat mempengaruhi

proses.

30

3.3. Definisi Data dalam Konteks Statistical Process Control (SPC)

Menurut Vincent Gaspersz (1998, p43) data adalah catatan tentang sesuatu, baik

yang bersifat kualitatif maupun kuantitatif yang dipergunakan sebagai petunjuk untuk

bertindak.

Berdasarkan data, dipelajari fakta-fakta yang ada dan kemudian diambil tindakan

yang tepat berdasarkan fakta itu. Dalam konteks pengendalian proses statistikal dikenal

dua jenis data, yaitu:

• Data Atribut (Attributes Data), 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 nasabah, banyaknya jenis cacat pada produk, banyaknya produk kayu

lapis yang cacat karena corelap. Data atribut biasanya diperoleh dalam bentuk

unit-unit nonkonformans atau ketidaksesuaian dengan spesifikasi atribut yang

ditetapkan.

• Data Variabel (Variables Data) merupakan data kuantitatif yang diukur untuk

keperluan analisi. Contoh dari data variabel karakteristik kualitas adalah

diameter pipa, ketebalan produk kayu lapis, berat semen dalam kantong,

banyaknya kertas setiap rim, konsentrasi elektrolit dalam persen, dan lain-lain.

Ukuran-ukuran berat, panjang, lebar, tinggi, diameter, volume biasanya

merupakan data variabel.

31

3.4. Variasi

Penyebab utama terjadinya masalah kualitas adalah variasi. Variasi terjadi di

dalam proses, baik proses manufaktur maupun non-manufaktur. Variasi-variasi ini dapat

terjadi dikarenakan adanya variasi dalam elemen-elemen proses, yaitu manusia, mesin,

metode, material dan lingkungan.

Menurut Vincent Gaspersz (1998, pp28-29) variasi adalah ketidakseragaman

dalam sistem produksi atau operasional sehingga menyebabkan perbedaan dalam

kualitas pada output (barang atau jasa) yang dihasilkan. Setiap variasi yang terjadi pasti

akan menimbulkan cacat (defect) pada produk.

Adapun pengertian dari cacat ialah semua kejadian/peristiwa yang

mengindikasikan di mana produk/jasa gagal memenuhi kebutuhan pelanggan atau

definisi yang lain adalah suatu kondisi dari suatu produk/jasa yang tidak dapat

memenuhi spesifikasi yang telah ditetapkan oleh standar yang berlaku atau tidak dapat

digunakan dengan baik oleh pelanggan (fitness for use) karena tidak memenuhi

satu/beberapa persyaratan kualitas pelanggan (Critical to Quality).

Penyebab dari variasi dapat dibagi menjadi dua kelompok, 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 umum.

32

3.4.1. Variasi Penyebab Khusus (Special Causes)

Variasi ini mempengaruhi proses dalam cara yang tidak terduga dan

dapat dideteksi dengan teknik-teknik statistik yang sederhana. Variasi ini dapat

dihilangkan dari proses oleh operator atau tim pengendali proses yang

bertanggung jawab pada tahap tertentu dari proses, dengan melakukan tindakan

langsung (local action), di mana hampir 15% dari semua permasalahan proses

dapat diatasi dengan tindakan ini. Ketika semua variasi dari penyebab khusus

telah dieliminasi, proses dapat dikatakan berada dalam pengendalian statistik

(Gerald Smith, 1996, p40).

3.4.2. Variasi Penyebab Umum (Common Causes)

Variasi penyebab umum 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 mengurangi variasi penyebab umum,

yaitu dengan membuat peningkatan pada proses manufakturing.

Perluasan dari variasi penyebab umum dapat diukur secara statistik dan

dibandingkan dengan spesifikasinya, jika perbaikan dibutuhkan, tindakan pada

proses perlu untuk dilakukan. Tindakan dari manajemen diperlukan untuk semua

perubahan dari proses (Gerald Smith, 1996, p40).

33

3.5. Metode DMAIC (Define, Measure, Anaylze, Improve dan Control)

Metode DMAIC (Define, Measure, Anaylze, Improve dan Control)

merupakan salah satu penerapan six sigma, di mana metode DMAIC ini

merupakan sebuah proses untuk peningkatan yang dilakukan terus menerus,

bersifat systematic, scientific and berdasarkan dengan data yang ada (fact based).

DMAIC adalah proses berulang (closed-loop process) yang bertujuan

untuk mengurangi atau menghilangkan proses produksi yang tidak produktif yang

berfokus pada pengukuran yang baru dan mengaplikasikan teknologi untuk

meningkatkan kualitas.

Selain DMAIC penerapan six sigma lainnya menggunakan metode

DMADV (Define, Measure, Anaylze, Design dan Verify). DMAIC digunakan

untuk meningkatakan proses bisnis yang sedang berjalan, sedangkan DMADV

digunakan untuk membuat rancangan produk baru atau merancang proses baru

yang hasilnya lebih baik, bisa diprediksi dan bebas cacat.

Berikut adalah penjelasan dari tahapan DMAIC:

1. Define, mendefinisikan tujuan-tujuan dalam usaha untuk meningkatkan proses

yang sesuai dengan permintaan pelanggan dan tujuan perusahaan.

2. Measure, mengukur proses produksi sekarang dan mengumpulkan data yang

dibutuhkan ke depannya untuk perbandingan.

3. Analyze, menganalisa kapabilitas proses produk kemudian mencari hubungan

sebab akibat dari faktor penyebab permasalahan yang ada.

4. Improve, meningkatkan proses berdasarkan analisis menggunakan tools yang

ada.

34

5. Control, mengontrol untuk menjalankan usulan-usulan yang diberikan dan

kemudian melakukan pengukuran kembali (kapabilitas proses).

Tahapan DMAIC dilakukan secara berulang dan membentuk siklus

peningkatan kualitas six sigma seperti dilihat pada Gambar 3.1 di bawah ini.

Siklus DMAIC didasarkan dan dikembangkan pada siklus orisinil PDCA (Plan-

Do-Check-Act) yang dibuat oleh William Edward Deming.

Gambar 3.1 Siklus DMAIC

3.6. Tools yang digunakan

3.6.1. Histogram

Histogram merupakan salah satu alat yang membantu untuk menemukan

variasi. Histogram merupakan suatu gambaran dari proses yang menunjukkan

distribusi dari pengukuran dan frekuensi dari setiap pengukuran itu.

Histogram dapat digunakan sebagai suatu alat untuk mengkomunikasikan

informasi tentang variasi dalam proses dan membantu manajemen dalam

membuat keputusan-keputusan yang berfokus pada usaha perbaikan terus-

menerus (continous improvement efforts).

35

3.6.2. Pareto Diagram

Diagram pareto adalah grafik batang yang menunjukkan masalah

berdasarkan urutan banyaknya kejadian. Masalah yang paling banyak terjadi

ditunjukkan oleh grafik batang pertama yang tertinggi serta ditempatkan pada sisi

paling kiri dan seterusnya sampai pada masalah yang paling sedikit paling terjadi

ditunjukkan oleh grafik batang terakhir yang terendah serta ditempatkan di sisi

paling kanan.

Analisis Pareto didasarkan pada hukum 80/20, di mana 80 persen

pengeluaran atau kerugian di dalam sebuah organisasi dibuat oleh hanya 20 persen

masalah. Angkanya tidak selalu tepat sama 80 dan 20, tetapi efek yang

ditimbulkannya seringkali sama. Pada dasarnya diagram pareto dapat digunakan

sebagai alat interpretasi untuk:

• Menentukan frekuensi relatif dan urutan pentingnya suatu masalah-

masalah atau penyebab-penyebab dari masalah yang ada.

• Memfokuskan perhatian pada isu-isu kritis dan penting melalui

pembuatan ranking terhadap masalah-masalah atau penyebab-penyebab

dari masalah itu dalam bentuk yang signifikan.

3.6.3. SIPOC Diagram

Dalam manajemen dan perbaikan proses, diagram SIPOC merupakan

salah satu teknik yang paling berguna dan juga paling sering digunakan.

36

Diagram SIPOC merupakan singkatan dari Supplier – Input – Process –

Output – Customer, yang digunakan untuk menampilkan ‘sekilas’ dari aliran

kerja. SIPOC didefinisikan sebagai berikut:

1. Supplier adalah orang atau sekelompok orang yang memberikan

informasi kunci, material atau sumber daya lain kepada proses. Supplier

dapat juga merupakan proses sebelum proses yang menjadi fokus.

2. Input adalah segala sesuatu yang diberikan pemasok kepada proses.

3. Process adalah sekumpulan langkah yang mengubah input sehingga

memberikan nilai tambah pada input.

4. Output adalah produk atau proses final, bisa berupa barang ataupun jasa

yang dihasilkan lewat suatu proses.

5. Customer adalah orang atau sekelompok orang atau proses yang

menerima output.

Seringkali ditambahkan juga persyaratan – persyaratan (requirements)

kunci dari Input dan Output sehingga membuat SIPOC menjadi SIRPORC.

Manfaat dari SIPOC adalah:

1. Melihat proses dihubungkan dengan pelanggan.

2. Menunjukkan sekumpulan aktivitas lintas fungsional.

3. Menggunakan kerangka kerja yang dapat diterapkan pada proses dengan

semua ukuran, bahkan untuk organisasi secara keseluruhan.

4. Memfokuskan analisa lebih lanjut hanya pada bagian yang diperlukan.

37

3.6.4. Voice of Costumer (VOC)

Voice of Customer (VOC) berupa data seperti komplain, survei,

komentar, riset pasar yang mencerminkan pandangan atau kebutuhan para

pelanggan sebuah perusahaan. VOC ini harus diterjemahkan ke dalam persyaratan

yang dapat diukur untuk proses.

3.6.5. Project Charter

Project Charter digunakan untuk memfokuskan proyek perbaikan

terhadap sesuatu masalah yang akan diteliti atau dipecahkan. Elemen-elemen yang

ada pada Project Charter adalah:

a. Business Case merupakan latar belakang permasalahan yang terjadi saat

ini dalam lingkup yang lebih global.

b. Problem Statement merupakan pernyataan masalah saat ini secara

spesifik dan terukur (specific dan measurable).

c. Goal Statement merupakan pernyataan tujuan yang akan dicapai setelah

proyek diselesaikan. Pernyataan tujuan ini haruslah spesifik, terukur,

realistik dan dapat dimengerti (specific, measurable, realistic dan

understandable).

d. Project Scope merupakan batasan-batasan di mana proyek perbaikan atau

pemecahan masalah yang akan difokuskan.

e. Role of Team Member merupakan daftar tugas dan tanggung jawab setiap

anggota tim yang terlibat dalam proyek perbaikan.

38

f. Milestone atau batas waktu yang ditetapkan pada tim proyek untuk dapat

menyelesaikan proyeknya, beserta rincian kegiatan waktu demi waktu

jika diperlukan.

3.6.6. Peta Kontrol (Control Chart)

Peta kontrol pertama kali diperkenalkan oleh Dr. Walter Andrew

Shewhart dari Bell Telephone Laboratories, Amerika Serikat pada tahun 1924

dengan maksud untuk menghilangkan variasi tidak normal melalui pemisahan

variasi yang disebabkan oleh penyebab khusus (special-causes variation) dari

variasi yang disebabkan oleh penyebab umum (common-causes variation).

Pada dasarnya semua proses menampilkan variasi, namun manajemen

harus mampu mengendalikan proses dengan cara menghilangkan variasi penyebab

khusus dari proses itu, sehingga variasi yang melekat pada proses hanya

disebabkan oleh variasi penyebab umum.

Peta kontrol merupakan sebuah alat yang digunakan untuk melakukan

pengawasan dari sebuah proses yang sedang berjalan. Nilai dari karakteristik

kualitas diplot sepanjang garis vertikal dan garis horizontal mewakili sample atau

subgroups (berdasarkan waktu) di mana karekteristik dari kualitas ditemukan.

Beberapa keuntungan yang bisa didapat dengan menggunakan peta

kontrol, yaitu:

• Memantau proses terus-menerus sepanjang waktu agar proses tetap stabil

secara statistikal dan hanya mengandung variasi penyebab umum.

39

• Menentukan kemampuan proses (process capability). Setelah proses

berada dalam pengendalian statistikal, batas-batas dari variasi proses

dapat ditentukan dan menunjukkan kemampuan dari proses untuk

memenuhi kebutuhan dari konsumen.

• Menentukan apakah suatu proses berada dalam pengendalian statistikal.

Dengan demikian peta-peta kontrol digunakan untuk mencapai suatu

keadaan terkendali secara statistikal, di mana semua nilai rata-rata dan

range dari sub-sub kelompok (subgroups) contoh berada dalam batas-

batas pengendalian (control limits).

Ada dua macam peta kontrol, yaitu peta kontrol untuk data variabel atau

variable control chart dan peta kontrol untuk data atribut atau attribute control

chart. Data variabel sering disebut sebagai data kuantitatif dan bersifat kontinu

yang diperoleh dari hasil pengukuran, contohnya adalah diameter, berat, panjang,

tinggi, lebar, volume, dll.

Sedangkan data atribut sering disebut sebagai data kualitatif dan bersifat

diskrit yang diperoleh dengan pengelompokkan atau perhitungan, contohnya

adalah warna, kebersihan, penampilan, dll. Berikut adalah penjelasannya:

40

Gambar 3.2 Penggunaan Peta Kontrol

1. Peta Kontrol Untuk Data Variabel.

- Peta Kontrol x dan R digunakan untuk memantau proses yang

mempunyai karakteristik berdimensi kontinu, yang menjelaskan

perubahan-perubahan yang terjadi dalam ukuran titik pusat (central

tendency) atau rata-rata dari suatu proses.

- Peta kontrol x dan MR diterapkan pada proses yang menghasilkan

output yang relatif homogen, pada proses produksi yang sangat lama

dan menggunakan 100% inspeksi.

2. Peta Kontrol Untuk Data Atribut.

- Peta kontrol p digunakan untuk mengukur proporsi ketidaksesuaian

(penyimpangan atau sering disebut cacat) dari item-item dalam

kelompok yang sedang diinspeksi.

- Peta kontrol np merupakan peta kontrol yang hampir sama dengan

peta kontrol p, kecuali bahwa dalam peta kontrol np tidak terjadi

perubahan skala pengukuran (n=tetap).

41

- Peta kontrol c diterapkan pada titik spesifik yang tidak memenuhi

syarat dalam produk itu sehingga suatu produk dapat saja dianggap

memenuhi syarat meskipun mengandung satu atau beberapa titik

spesifik yang cacat.

- Peta kontrol u digunakan untuk mengukur banyaknya ketidaksesuaian

dalam periode pengamatan tertentu yang mungkin memiliki ukuran

contoh atau banyaknya item yang diperiksa.

3.6.7. Kapabilitas Proses

3.6.7.1. Kapabilitas

Kapabilitas adalah kemampuan dari proses dalam

menghasilkan produk yang memenuhi spesifikasi. Jika proses memiliki

kapabilitas yang baik, proses itu akan menghasilkan produk yang berada

dalam batas-batas spesifikasi.

Sebaliknya apabila proses memiliki kapabiltias yang jelek,

proses itu akan menghasilkan banyak produk yang berada di luar batas-

batas spesifikasi, sehingga menimbulkan kerugian karena banyak poduk

akan ditolak. Apabila ditemukan banyak produk yang ditolak atau

terdapat banyak scrap, hal itu menunjukkan bahwa proses produksi

memiliki kapabilitas yang rendah.

42

3.6.7.2. Pengertian Kapabilitas Proses

Kapabilitas proses mewakili performa dari sebuah proses dalam

kondisi pengendalian secara statistik. Kapabilitas proses ditentukan oleh

total dari variasi yang ada karena penyebab-penyebab umum yang ada

dalam sistem.

Analisis kapabilitas proses adalah ilmu teknik yang digunakan

untuk memperkirakan kapabilitas proses, yang meliputi perkiraan nilai

mean dan standard deviasi dari karakteristik kualitas sebuah proses.

Fungsi utama dari analisis kapabilitas proses adalah untuk

menentukan seberapa baik pengukuran yang telah dilakukan ketika

dibandingkan dengan spesifikasi.

3.6.7.3. Indeks Kapabilitas

Ada dua versi dari indeks kapabilitas proses yaitu:

1. 6σ

LSLUSLpC −=

Ketika Cp digunakan, nilainya akan dibandingkan terhadap

nilai tertentu yang diinginkan. Nilai Cp yang berada di bawah 1

berarti toleransinya lebih kecil dari penyebaran pengukuran 6σ

dan ada sample pada populasi yang berada di luar batas

spesifikasi.

43

2. ⎟⎠⎞

⎜⎝⎛ −

=3σLSLμ,

3σμ-USL minimum pkC

Bila nilai Cp dibandingkan dengan keseluruhan toleransi 6σ dan

mengindikasikan seberapa baik sebuah proses, maka Cpk

membandingkan yang terburuk sebagian dari distribusi dengan

3σ .

Kriteria (rule of thumb) dari indeks kapabilitas adalah:

1. Cp > 1,33, maka kapabilitas proses dianggap baik (capable).

2. 1,00 < Cp < 1,33, maka kapabilitas proses dianggap baik namun

perlu pengendalian ketat apabila Cp telah mendekati 1,00

(capable with tight control as Cp approaches 1,00).

3. Cp < 1,00, maka kapabilitas proses dianggap tidak baik/rendah

(not capable), sehingga perlu ditingkatkan performansinya

melalui perbaikan proses itu.

3.6.7.4. Keuntungan Analisis Kapabilitas Proses

Keuntungan dari analisis kapabilitas proses menurut Amitava

Mitra (1998, p294), yaitu:

1. 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 standard

diproduksi (nonconforming products).

44

2. Keseragaman dari output.

Dengan menggunakan kapabilitas proses dan melakukan

penyesuaian yang diperlukan pada parameter proses, variabilitas

dapat lebih dikendalikan, segala bentuk yang tidak diinginkan

dari pendistribusian karakteristik kualitas dievaluasi dan

perubahan pada parameter proses dapat dilakukan lebih cepat.

3. Peningkatan atau pemeliharaan kualitas.

Analisis kapabilitas proses mengindikasikan apakah diperlukan

peralatan yang baru atau tidak. Setelah perubahan ini terjadi

maka kapabilitas yang baru dapat ditentukan.

4. Memfasilitasi desain produk dan proses.

Informasi yang diperoleh dari analisis kapabilitas proses

memberikan umpan balik yang penting dari bagian manufaktur

untuk desain. Ini sangat penting karena perancang produk harus

waspada terhadap variasi yang muncul secara permanen.

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

45

3.6.8. Diagram Sebab Akibat (Cause and Effect Diagram)

Diagram sebab akibat diperkenalkan pertama kali oleh Kaoru Ishikawa,

Ph.D. pada tahun 1943 dan sering juga disebut sebagai diagram Ishikawa, karena

bentuknya seperti kerangka ikan, diagram sebab akibat ini sering juga disebut

sebagai Diagram Tulang Ikan (fishbone diagram).

Diagram sebab akibat digunakan untuk menyelidiki atau mempelajari

sebab-sebab kesalahan/kegagalan yang digunakan untuk tindakan perbaikan.

Dengan cara ini, dapat diketahui penyebab apa yang mengakibatkan masalah yang

paling serius

Diagram sebab akibat berkaitan dengan pengendalian proses statistikal,

di mana dapat diidentifikasi penyebab suatu proses out of control. Sebaliknya bila

proses stabil, dapat digunakan untuk memberikan petunjuk pada penyebab untuk

diteliti lebih lanjut sehingga meningkatkan proses.

Diagram sebab akibat digunakan untuk kebutuhan – kebutuhan sebagai

berikut:

- Menganalisis kondisi aktual yang bertujuan untuk memperbaiki /

meningkatkan kualitas barang atau jasa, memanfaatkan sumber daya

secara efisien dan meminimasi biaya.

- Mengeliminasi / menghilangkan hal-hal yang menyebabkan produk cacat

dan ketidakpuasan pelanggan.

- Membuat standard dari operasi yang ada dan yang akan diusulkan.

- Mendidik dan melatih personil yang ada dalam membuat keputusan dan

dalam membuat perbaikan.

46

3.6.9. Failure Mode and Effect Analysis (FMEA)

FMEA adalah sebuah metodologi yang digunakan untuk menganalisa dan

menemukan semua kegagalan-kegagalan yang potensial terjadi pada suatu sistem,

menemukan efek-efek dari kegagalan yang terjadi pada sistem dan kemudian

mencari cara bagaimana untuk memperbaiki atau mengurangi kegagalan-

kegagalan atau efek-efeknya pada sistem.

Perbaikan dan pengurangan yang dilakukan biasanya berdasarkan pada

sebuah ranking dari severity dan probability dari kegagalan. Beberapa keuntungan

dari FMEA adalah:

Membantu desainer untuk mengidentifikasi dan mengeliminasi atau

mengendalikan cara kegagalan yang membahayakan serta mengurangi

kerusakan terhadap sistem dan penggunanya.

Meningkatnya keakuratan dari perkiraan terhadap peluang dari kegagalan

yang akan dikembangkan.

Realibilitas dari produk akan meningkat, karena waktu untuk melakukan

desain akan dikurangi berkaitan dengan melakukan identifikasi dan

perbaikan dari masalah-masalah.

47

Gambar 3.3 Contoh FMEA

Definisi serta pengurutan/pemberian ranking dari berbagai terminologi dalam

FMEA adalah sebagai berikut:

1. Mode Kegagalan Potensial (Potential Failure Mode – Quality Risk)

adalah kegagalan atau kecacatan dalam desain yang menyebabkan sistem

itu tidak berfungsi sebagaimana mestinya.

2. Penyebab Potensial dari Kegagalan (Potential Effect of Failure) adalah

kelemahan-kelemahan desain dan perubahan dalam variabel yang akan

mempengaruhi proses dan menghasilkan kecacatan produk.

3. Severity (S) adalah suatu perkiraan subyektif atau estimasi tentang tingkat

parahnya kerusakan atau bagaimana buruknya pengguna akhir akan

merasakan akibat dari kegagalan tersebut. Berikut adalah kriteria dari

severity yang ditunjukkan pada Tabel 3.1 di bawah ini.

48

Tabel 3.1 Kriteria Severity

Effect Criteria ( Severity of Effect) Rank

Berbahaya, tanpa peringatan

Memungkinkan untuk membahayakan mesin atau operator, ranking sangat tinggi apabila berhubungan dengan penggunaan kendaraan secara aman atau tidak sesuai dengan peraturan pemerintah. Kegagalan akan timbul tanpa peringatan

10

Berbahaya, dengan peringatan

Memungkinkan untuk membahayakan mesin atau operator, ranking sangat tinggi apabila berhubungan dengan penggunaan kendaraan secara aman atau tidak sesuai dengan peraturan pemerintah. Kegagalan akan timbul dengan adanya peringatan

9

Sangat tinggi

Gangguan utama pada lini produksi, semua hasil produksi (100%) harus dibuang, produk kehilangan fungsi utama. Konsumen sangat tidak puas.

8

Tinggi Gangguan minor pada lini produksi, produksi harus dipilih dan sebagian besar produk (dibawah 100%) harus dibuang, fungsi produk menurun. Konsumen tidak puas.

7

Sedang Gangguan minor pada lini produksi, sebagian kecil produk harus dibuang, produk dapat digunakan, namun kenyamanan terganggu. Konsumen kurang puas

6

Rendah Gangguan minor pada lini produksi, 100% produk mungkin harus di-rework. Produk dapat digunakan namun kemampuan rendah. Konsumen merasa sedikit kecewa

5

Sangat Rendah

Gangguan minor pada lini produksi, produk jadi harus dipilah – pilih dan sebagian kecil harus di-rework. Ketidaksesuaian produk kecil, kerusakan dapat dideteksi oleh kebanyakan konsumen

4

Minor Sebagian kecil produk harus di-rework, namun dilakukan di lini produksi dan di luar stasiun kerja, kerusakan diketahui oleh sebagian besar konsumen.

3

Sangat Minor

Sebagian kecil produk harus di-rework, namun dilakukan di lini produksi dan di dalam stasiun kerja, kerusakan diketahui oleh sangat sedikit konsumen.

2

Tidak ada Tidak ada Efek 1

4. Occurence (O) adalah suatu perkiraan mengenai kemungkinan dari

penyebab yang akan terjadi dan menghasilkan modus kegagalan yang

menyebabkan akibat tertentu. Tabel 3.2 menunjukkan skala rating

occurrence.

49

Tabel 3.2 Kriteria Occurrence

Probability Of Failure Possible Failure rate Cpk Rank

>=1 dari 2 < 0,33 10 Sangat Tinggi : Kegagalan hampir tak dapat dihindari 1 dari 3 >= 0,33 9

1 dari 8 >= 0,51 8 Tinggi: Kegagalan sangat mirip dengan beberapa kegagalan sebelumnya yang memang sering sekali gagal 1 dari 20 >= 0,67 7

1 dari 80 >= 0,83 6 1 dari 400 >=1,00 5

Sedang: Dapat dikaitkan dengan kegagalan sebelumnya yang sering terjadi, namun tidak dalam proporsi besar 1 dari 2000 >=1,17 4 Rendah: Kegagalan yang terisolasi dan dapat diasosiasikan dengan beberapa proses yang serupa

1 dari 15000 >= 1,33 3

Sangat Rendah: Hanya kegagalan - kegagalan terisolasi yang serupa dengan proses yang identik.

1 dari 150000 >= 1,50 2

Sangat kecil: Kegagalan hampir tidak mungkin, belum pernah terjadi kegagalan serupa di proses lain yang identik

<=1 dari 1500000 >= 1,67 1

5. Detection (D) adalah perkiraan subyektif tentang kemungkinan untuk

mendeteksi penyebab dari kegagalan yang ada sebelum produk tersebut

keluar dari proses produksi. Untuk dapat menentukan angka Detection

dapat dilihat pada Tabel 3.4.

6. Risk Priority Number (RPN) merupakan hasil perkalian antara rating

severity, detection dan rating occurance dengan rumus:

RPN = (S) x (O) x (D).

Nilai ini harus digunakan untuk mengurutkan perhatian yang harus

diberikan pada proses tersebut. Untuk RPN yang besar, team harus

mampu menurunkan nilai resiko, umumnya perhatian tertinggi harus

diberikan pada Severity (S) tertinggi.

50

Tabel 3.3 Kriteria Detection

Detection Kriteria: Keberadaan dari cacat dapat dideteksi oleh kontrol proses sebelum koponen atau hasil produksi

lolos ke proses selanjutnya. Rank

Hampir tidak mungkin Tidak ada kontrol yang tersedia untuk jenis kegagalan ini 10

Sangat kecil kemungkinannya

Sangat tidak mungkin untuk kontrol yang ada dapat mendeteksi kegagalan ini 9

Kecil kemungkinannya

Tidak mungkin kontrol yang ada tidak dapat mendeteksi kegagalan yang ada 8

Sangat rendah Sangat rendah kemungkinan untuk kontrol yang ada dapat mendeteksi kegagalan ini 7

Rendah Rendah kemungkinan untuk kontrol yang ada dapat mendeteksi kegagalan ini 6

Sedang Ada kemungkinan untuk kontrol yang ada dapat mendeteksi kegagalan ini 5

Agak tinggi Cukup kemungkinan untuk kontrol yang ada dapat mendeteksi kegagalan ini 4

Tinggi Mungkin untuk kontrol yang ada dapat mendeteksi kegagalan ini 3

Sangat tinggi Sangat mungkin untuk kontrol yang ada dapat mendeteksi kegagalan ini 2

Hampir pasti terdeteksi

Hampir pasti kontrol yang ada dapat menangkap kegagalan proses seperti ini, karena sudah diketahui dari proses yang serupa.

1

7. Recommended Action adalah satu atau lebih tindakan yang dibuat

untuk mengatasi permasalahan dan meningkatkan Risk Priority

Number (RPN).

51

3.7. Sistem

Menurut James A. O’Brien. (2003, p8), sistem adalah integrasi dari komponen-

komponen yang saling bekerja sama untuk mencapai satu tujuan dengan merubah input

menjadi output melalui proses perubahan. Sistem juga dapat diartikan sebagai kumpulan

komponen yang saling berinteraksi dengan tujuan tertentu.

Dari pengertian ini, dapat diketahui karakteristik sistem yaitu harus terdiri dari dua

atau lebih item, komponen dari sistem merupakan item yang tidak dapat menjadi sistem

yang lebih kecil atau item merupakan bentuk dasar/komponen yang berbentuk sistem

kecil, komponen-komponen dari sistem beroperasi dengan suatu hubungan tertentu di

antaranya, dan sistem harus mempunyai tujuan.

Hirarki dari sistem menunjukkan semua sistem terdiri dari sub sistem karena

sistem terdapat dalam sebuah sistem lain yang lebih besar. Misalnya, sekolah merupakan

suatu sistem yang berada dalam sistem pendidikan nasional dimana dalam sistem

sekolah terdapat sistem yang lebih kecil seperti sistem pengajaran dan sistem absensi.

Interaksi dan koneksi antar sub sistem disebut interface. Pada umumnya sistem dibagi ke

dalam tiga bagian yaitu input, proses, dan output. Ketiga bagian ini dikelilingi oleh

lingkungan sekitarnya dan juga mekanisme feedback. Dasar dari sistem adalah:

a. Input.

Meliputi pengumpulan data baik dari dalam maupun dari luar organisasi yang

akan digunakan dalam proses sistem informasi. Contohnya adalah raw materials,

data dan energi.

52

b. Process.

Meliputi proses transformasi (perubahan) yang merubah input menjadi output

sehingga menjadi berguna bagi user. Contohnya adalah proses manufaktur,

perhitungan matematika.

c. Output.

Merupakan proses untuk melakukan penyebaran informasi dan elemen-elemen

kepada orang atau kegiatan yang membutuhkannya. Contohnya adalah barang jadi

yang nantinya dikirimkan ke konsumen.

d. Feedback.

Feedback adalah aliran informasi dari komponen output kepada pengambil

keputusan mengenai output sistem atau kinerja dari sistem. Pengambil keputusan

membandingkan output dengan yang ditargetkan kemudian menyesuaikan input

dan proses sehingga sistem dapat menghasilkan output yang mendekati target.

e. Lingkungan

Lingkungan (environment) terdiri dari beberapa elemen yang berada diluar sistem

dan bukan merupakan input, output, atau proses.

Suatu elemen dikatakan berada dalam lingkungan jika dan hanya jika elemen

mempengaruhi tujuan sistem dan pengambil keputusan tidak dapat memanipulasi

elemen. Elemen lingkungan dapat berupa bidang ekonomi, fiskal, legal, politik,

dan sosial.

53

Gambar 3.4 Struktur Sistem

3.8. Informasi

Menurut James A. O’Brien (2003), informasi adalah data yang telah diolah

menjadi bentuk yang lebih berguna dan berarti bagi yang menggunakannya (end users).

Informasi sangat dibutuhkan karena informasi merupakan suatu dasar dalam mengambil

keputusan dalam perusahaan.

3.9. Sistem Informasi

Sistem informasi adalah sistem yang bertujuan untuk menyimpan, memproses dan

mengkomunikasikan informasi. Sistem informasi menerima input dan memproses data

untuk menyediakan informasi bagi pengambil keputusan dan membantu pengambil

keputusan mengkomunikasikan hasil putusannya.

54

Sistem Informasi 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.

3.10. Unified Modelling Language (UML)

3.10.1. Sejarah UML

Unified Modeling Language (UML) 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.

Pendekatan analisa dan rancangan dengan menggunakan metode Object

Oriented mulai diperkenalkan sekitar pertengahan 1970 hingga akhir 1980

dikarenakan pada saat itu aplikasi software sudah meningkat dan mulai kompleks.

Jumlah yang menggunakan metode OO mulai diuji coba dan diaplikasikan antara

1989 hingga 1994 , seperti halnya oleh Grady Booch dari Rational Software Co.

yang dikenal dengan OOSE (Object-Oriented Software Engineering), serta James

Rumbaugh dari General Electric, dikenal dengan OMT (Object Modelling

Technique).

55

Kelemahan saat itu mulai disadari oleh Booch maupun Rumbaugh, ketika

mereka bertemu rekan lainnya, Ivar Jacobson dari Objectory. Kelemahannya

adalah tidak adanya standar penggunaan model yang berbasis OO, sehingga

mereka mulai mendiskusikan untuk mengadopsi masing-masing pendekatan

metoda OO untuk membuat suatu model bahasa yang seragam, yaitu Unified

Modeling Language (UML) dan dapat digunakan oleh seluruh dunia.

Gambar 3.5 Terbentuknya Unified Modelling Language (UML)

Sumber: Dharwiyanti, Wahono, http://ikc.tuxed.org/umum/yanti-uml.php/

Ada beberapa usaha awal untuk menyatukan konsep diantara berbagai

metode yang muncul. Salah satunya adalah penyatuan yang dilakukan oleh

Coleman dan koleganya yang memasukkan konsep dari OMT, Booch (Booch –

91), dan CRC. Dimana usaha tersebut tidak melibatkan pencetus yang aslinya,

hasilnya dianggap sebagai sebuah metode baru yang menggantikan beberapa

metode yang lain.

56

Pada tahun 1996 Object Management Group (OMG) memunculkan

permintaan untuk proposal untuk sebuah pendekatan yang standar untuk object

oriented modelling Pencetus UML Grady Booch, Ivar Jacobson dan James

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 object oriented dan software component.

3.10.2. Konsep Bahasa UML

Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah

menjadi standar dalam industri untuk visualisasi, merancang dan

mendokumentasikan sistem piranti lunak (software). UML menawarkan sebuah

standar untuk merancang model sebuah sistem. Dengan menggunakan UML dapat

dibuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut

dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis

dalam bahasa pemrograman apapun.

57

Tetapi karena UML juga menggunakan class dan operation dalam konsep

dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa-bahasa

berorientasi objek seperti C++, Java, C# atau VB.NET. Walaupun demikian,

UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C.

Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan

syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk

menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna

tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat

dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada

sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT

(Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented

Software Engineering).

3.10.3. Kegunaan UML

UML diperuntukan untuk pemakaian sistem software yang intensif. 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.

58

3.11. Object Oriented Analysis and Design (OOAD)

Menurut Lars Mathiassen (2000, pp3-4), OOAD merupakan metode untuk

menganalisa dan merancang suatu sistem informasi dengan menggunakan objek dan

class sebagai konsep dasarnya. Analisis di sini adalah kegiatan melakukan investigasi

terhadap masalah yang ada, desain adalah solusi logis dari permasalahan yang ada dan

implementasi adalah penerapannya.

Metode ini digunakan dalam hal analisis dan desain sistem, menyediakan

pandangan yang terintegrasi antara software dengan hardware dan menyediakan

metodologi untuk melakukan pengembangan sistem.

3.11.1. Karakteristik Object Oriented Analysis and Design (OOAD)

Encapsulation, Inheritance dan Polymorphism merupakan karakteristik

pemrograman berbasis objek, di mana sebuah pemrograman berbasiskan objek

harus memenuhi kriteria tersebut. Berikut adalah pengertian dari masing – masing

kriteria tersebut :

1. Encapsulation dalam OOAD adalah pengelompokan funsgi atau

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.

59

2. Inheritance merupakan kemampuan objek untuk menurunkan sifat,

metode, atribut, dan variabel yang dimiliki oleh class dasarnya tanpa

menggunakan banyak kode program, serta dapat ditambahkan metode,

atribut, dan variabel baru.

3. Polymorphism merupakan kemampuan untuk mendefinisikan beberapa

class dengan fungsi yang berbeda, namun memiliki nama metode dan

properti yang identik dan dapat digunakan secara bergantian pada saat

program dijalankan.

3.11.2. Keuntungan Object Oriented Analysis and Design (OOAD)

Menurut Lars Mathiassen Mathiassen (2000, pp5-6) keuntungan

menggunakan OOAD di antaranya adalah:

1. Merupakan konsep umum yang dapat digunakan untuk memodelkan

hampir semua fenomena dan dapat dinyatakan dalam bahasa yang umum.

2. OOAD memberikan informasi yang jelas mengenai context sistem.

3. Dapat menangani data yang seragam dalam jumlah yang besar dan

mendistribusikannya ke seluruh bagian organisasi.

4. Berhubungan erat dengan analisa berorientasi objek, perancangan

berorientasi objek, user interface berorientasi objek, dan pemrograman

berorientasi objek.

60

3.12. Aktivitas Utama Object Oriented Analysis and Design (OOAD)

Sistem secara nyata mempunyai beberapa komponen di dalamnya. Arsitektur dari

komponen sistem merefleksikan konteks dari sistem. Berikut adalah Gambaran

mengenai konteks dari sistem dan arsitektur dari sistem yang ditunjukkan oleh Gambar

3.6 dan 3.7.

Gambar 3.6 System Context

Gambar 3.7 System Architecture

Aktivitas di dalam OOAD terdiri dari 4 aktivitas utama, problem domain analysis,

application domain analysis, architectural design dan component design. Keempat

aktivitas ini merupakan aktivitas analisis dan perancangan pada daur hidup dalam

pengembangan sistem.

61

Sebelum aktivitas analisis dan desain dilakukan, aktivitas preliminary analysis

dilakukan pada daur hidup pengembangan sistem dalam bentuk system choice Gambar

3.8 di bawah ini akan menjelaskan aktivitas OOAD yang menunjukkan berbagai

aktivitas tersebut serta hubungannya.

Gambar 3.8 Aktivitas-Aktivitas dalam OOAD

3.12.1. System Choice

Awal dari suatu proyek pengembangan sistem informasi adalah pengumpulan

ide yang berbeda-beda mengenai sistem yang diinginkan. System choice ini dapat

dilakukan dengan terlebih dahulu mendeskripsikan sistem yang akan dibuat. Dalam

pembuatan sistem ini perlu dilakukan pengamatan terhadap kondisi situasi yang terkait

dan orang-orang yang berhubungan. Sistem yang diinginkan dapat dibuat dalam bentuk

narasi ataupun gambar. Apabila sistem ingin dibuat dalam narasi maka digunakan

system definition, sedangkan bila dalam bentuk gambar maka sistem digambarkan dalam

bentuk rich picture. Rich picture adalah sebuah gambaran informal yang digunakan oleh

pengembang sistem untuk menyatakan pemahaman mereka terhadap situasi dari sistem

yang sedang berlangsung.

62

Selain itu dilakukan pengujian dengan menganalisa 6 kriteria yang sering

disingkat menjadi FACTOR. Keenam elemen tersebut adalah functionality, application

domain, conditions, technology, objects serta responsiliility. FACTOR dapat juga

menjadi kriteria yang dapat memberikan penilaian kepuasan dari system definition.

3.12.2. Problem Domain Analysis

Tujuan dari problem domain analysis adalah untuk mengidentifikasi dan

menjelaskan tujuan dari sistem. Aktivitas yang dilakukan dalam problem domain

analysis ini adalah aktivitas mendefinisikan classes, stucture dan behavior.

3.12.2.1. Classes

Aktivitas dalam mendefinisikan classes ini bertujuan untuk mencari

bagian-bagian yang terdapat dalam problem domain, yaitu objects, classes dan

events.

Object adalah suatu entity yang mempunyai identitas, state dan

behavior. Identity dari object adalah property yang memisahkannya dari object-

object lainnya, di mana semua object memiliki identitas supaya dapat dibedakan

antara satu object dengan object lainnya. State dari object terdiri dari atribut yang

bersifat statis dan dinamis. Behavior dari object merupakan rangkaian dari event

baik secara aktif atau pasif dilakukan oleh object selama masa hidupnya.

Menurut Lars Mathiassen (2000, p53), class deskripsi dari kumpulan

object yang mempunyai struktur, behavior pattern dan attribute yang sama.

Event adalah kejadian yang terjadi seketika yang melibatkan satu atau lebih

object.

63

Mengacu pada Mathiassen (2000, p49) aktivitas ini akan menghasilkan

event table, di mana dalam tabel ini dimensi horizontal berisi kelas-kelas yang

terpilih sedangkan dimensi vertical berisi event-event terpilih dan tanda cek

digunakan untuk mengidentifikasikan objek-objek dari kelas yng berhubungan

dalam event tertentu. Seperti yang terlihat pada Tabel 3.4 di bawah ini.

Tabel 3.4 Contoh Event Table

Class

Event

Customer Assistant Apprentice Appoinment Plan

Reserved v v v v Cancelled v v v Treated v v Employed v v Resigned v v Graduated v Agreed v v v

3.12.2.2. Structure

Aktivitas ini bertujuan untuk membuat model dengan didasarkan pada

hubungan struktural antara class dan object. Setelah mengetahui class dan object

yang ada, event table dapat dibuat untuk menggambarkan hubungan struktural

antara class dan object tersebut. Lalu, struktur antara class dan object dapat

digambarkan lewat Class Diagram.

Class diagram menggambarkan sekumpulan class, interface,

collaboration dan relasi-relasinya. Class diagram juga menunjukkan atribut dan

operasi dari sebuah object class. Class diagram dapat dikatakan sebagai diagram

64

dari problem domain yang menggambarkan seluruh hubungan struktural antara

class dan object yang terdapat di dalam model sistem yang telah ditetapkan.

Terdapat dua jenis hubungan struktural yang dapat menggambarkan

hubungan antar object, yaitu aggregation dan association. Berikut adalah

penjelasannya:

a. Aggregation.

Menggambarkan hubungan antara dua atau lebih object yang

menyatakan bahwa salah satu object adalah dasarnya dan

mendefinisikan bagian yang lainnya.

Gambar 3.9 Contoh Aggregation Structure

b. Association.

Menggambarkan hubungan antara dua atau lebih object tapi berbeda

dengan aggregation di mana object yang tergabung tidak didefinisikan

sebagai property dari sebuah object. Umumnya association

digambarkan dengan sebuah garis di antara class yang relevan.

65

Gambar 3.10 Contoh Assocation Structure

Untuk class dapat digambarkan dua jenis hubungan, yaitu

generalization dan cluster. Berikut adalah penjelasannya:

a. Generalization.

Merupakan hubungan antara 2 atau lebih kelas yang lebih khusus (sub

class) dengan sebuah kelas yang lebih umum (super class), di mana

hubungan spesialiasi tersebut dinyatakan dengan rumus “is-a”.

Gambar 3.11 Contoh Generalization Structure

b. Cluster.

Cluster adalah kumpulan kelas yang saling berhubungan yang

membantu memperoleh dan menyediakan ringkasan problem domain.

Cluster menggambarkan hubungan sebuah kumpulan dari class yang

saling berhubungan.

66

Gambar 3.12 Contoh Cluster Structure

3.12.2.3. Behavior

Behavior merupakan sekumpulan dari event dalam urutan yang tidak

teratur yang melibatkan sebuah object. Behavior perlu dibuat untuk semua class

dan dapat dibuat dengan membuat event trace sebelumnya. Event trace adalah

urut-urutan event yang meliputi suatu object tertentu. Sedangkan behavioral

pattern adalah penjelasan dari event trace untuk seluruh object dalam sebuah

class, yang ditampilkan dalam bentuk state chart diagram.

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. Berikut adalah

contoh dari state chart diagram yang ditunjukkan pada Gambar 3.13 di bawah

ini.

67

Gambar 3.13 Contoh Statechart Diagram

3.12.3. Application Domain Analysis

Application domain merupakan organisasi yang mengatur, mengawasi, atau

mengendalikan problem domain. Application domain analysis bertujuan untuk

menentukan kebutuhan pengguna sistem dan mendefinisikan fungsi dan interface dari

sistem. Aktivitas yang dilakukan dalam application domain analysis ini adalah aktivitas

mendefinisikan usage, function dan interface.

3.12.3.1. Usage

Usage didefinisikan untuk menentukan bagaimana aktor berinteraksi

dengan sistem. Actor adalah abstraksi dari user atau sistem lain yang berinteraksi

dengan target sistem. Hasil dari usage adalah use case. Use case merupakan

interaksi antara sistem dengan actor di dalam application domain. Hasil dari

aktivitas usage ini adalah deskripsi dari semua use case dan actor dalam bentuk

use case specification dan actor specification.

68

Use case specifications akan menjelaskan bagaimana use case itu

bekerja, dan juga objek dan fungsi apa saja yang berhubungan langsung dengan

use case tersebut, sedangkan actor spesification akan menjelaskan bagaimana

cara actor berinteraksi dengan sistem.

Penggambaran hubungan antara actor dan use case dapat digambarkan

lewat use case diagram ataupun dalam bentuk actor table. Use case diagram

menggambarkan interaksi antara sistem dan user. Selain itu Use Case Diagram

mendeskripsikan secara grafis hubungan antara actors dan use case. Berikut

adalah contoh dari use case diagram yang ditunjukkan pada Gambar 3.14 di

bawah ini.

Gambar 3.14 Contoh Use Case Diagram

69

Setelah use case diagram digambarkan, maka tahap selanjutnya adalah

penggambaran sequence diagram. Menurut Simon Bennett (2006, p253)

sequence diagram menunjukkan interaksi antar objek yang diatur berdasarkan

urutan waktu. Sequence diagram dapat digambarkan dalam berbagai level of

detail yang berbeda untuk memenuhi tujuan yang berbeda-beda pula dalam daur

hidup pengembangan sistem. Simon Bennett menyatakan bahwa setiap sequence

diagram harus diberikan frame dengan menggunakan notasi sd yang merupakan

kependekan dari sequence diagram. Selain itu juga terdapat beberapa notasi

penulisan heading pada setiap frame yang terdapat dalam sequence diagram,

yaitu:

a. alt

Notasi ini merupakan kependekan dari alternatives yang menyatakan

bahwa terdapat beberapa buah alternatif jalur eksekusi untuk

dijalankan.

b. opt

Notasi opt merupakan kependekan dari optional dimana frame yang

memiliki heading ini memiliki status pilihan yang akan dijalankan jika

syarat tertentu dipenuhi.

c. loop

Notasi loop menyatakan bahwa operation yang terdapat dalam frame

tersebut dijalankan secara berulang selama kondisi tertentu.

70

d. break

Notasi ini menyatakan bahwa semua operation yang berada setelah

frame tersebut tidak dijalankan.

e. par

Notasi par merupakan kependekan dari parallel yang mengindikasikan

bahwa operation dalam frame tersebut dapat dijalankan secara

bersamaan.

f. seq

Notasi ini merupakan kependekan dari weak sequencing yang berarti

operation yang berasal dari lifeline yang berbeda dapat terjadi pada

urutan manapun.

g. strict

Notasi strict merupakan kependekan dari strict sequencing yang

menyatakan bahwa operation harus dilakukan secara berurutan.

h. neg

Notasi neg merupakan kependekan dari negative yang

mendeskripsikan operasi yang tidak valid.

i. critical

Frame yang memiliki heading critical menyatakan bahwa operasi-

operasi yang terdapat di dalamnya tidak memiliki sela yang kosong.

j. ignore

Notasi ini mengindikasikan bahwa tipe pesan atau parameter yang

dikirimkan dapat diabaikan dalam interaksi.

71

k. consider

Consider menyatakan pesan mana yang harus dipertimbangkan dalam

interaksi.

l. assert

Merupakan kependekan dari assertion yang menyatakan urutan pesan

yang valid.

m. ref

Notasi ref merupakan kependekan dari refer yang menyatakan bahwa

frame mereferensikan operation yang terdapat di dalamnya pada

sebuah sequence diagram tertentu.

Campaign Manager :Client

getName()

listCampaigns()

:Campaign

getCampaignDetails()

:Advert

loop [for all client’s campaigns]

loop [for all campaign’s adverts]

checkCampaignBudget

getCost

sd Check campaign budget

Gambar 3.15 Contoh Sequence Diagram

72

3.12.3.2. Function

Function didefinisikan untuk mengetahui apa yang dapat dilakukan

sistem untuk membantu actor. Function adalah fasilitas yang membuat suatu

model bermanfaat bagi actor. Sebuah fungsi akan diaktifkan, dieksekusi dan

akhirnya memberikan hasil, di mana eksekusi yang dilakukan terhadap fungsi

dapat merubah perubahan di problem domain dan application domain.

Ada 4 tipe dari fungsi yaitu update, signal, read dan compute yang

ditunjukkan pada Gambar 3.15. Penjelasan dari empat tipe function dijelaskan di

bawah ini:

a. Update.

Function ini disebabkan oleh event problem domain dan menghasilkan

perubahan dalam state atau keadaan dari model tersebut.

b. Signal.

Function ini disebabkan oleh perubahan keadaan atau state dari model

yang dapat menghasilkan reaksi pada konteks. Reaksi ini dapat berupa

tampilan bagi actor dalam application domain atau intervensi langsung

dari problem domain.

c. Read.

Function ini disebabkan oleh kebutuhan informasi dalam pekerjaan

actor dan mengakibatkan sistem menampilkan bagian yang

berhubungan dengan informasi dalam model.

73

d. Compute.

Function ini disebabkan oleh kebutuhan informasi dalam pekerjaan

actor dan berisi perhitungan yang melibatkan informasi yang

disediakan oleh actor atau model, hasil dari function adalah tampilan

dari hasil komputasi.

Hasil dari aktivitas function adalah daftar dari function atau function

list yang merinci function-function yang kompleks. Function list dibuat

berdasarkan dari use case description. Kompleksitas dari function list dimulai

dari yang simple sampai yang very complex.

Gambar 3.16 Function

3.12.3.3. Interface

Interface adalah suatu fasilitas yang membuat model dan function

dapat berinteraksi dengan actor. Interface menghubungkan sistem dengan semua

aktor yang berhubungan dalam konteks. Interface digunakan oleh actor untuk

berinteraksi dengan sistem.

74

Kegiatan analisis user interface ini berdasarkan pada hasil dari kegiatan

analisis lainnya yaitu model problem domain, kebutuhan functional dan use case.

Interface terdiri dari user interface dan system interface. Hasil dari aktivitas ini

adalah sebuah deskripsi elemen-elemen user interface dan elemen-elemen system

interface yang ditunjukkan lewat pembuatan tampilan (form), navigation

diagram dan lainnya.

Menurut Lars Mathiassen (2000, p344), Navigation Diagram

merupakan statechart diagram khusus yang berfokus pada user interface.

Diagram ini menunjukkan window-window dan transisi diantara window-window

tersebut. Sebuah window dapat digambarkan sebagai sebuah state. State ini

memiliki nama dan berisi gambar miniatur window. Transisi antar state dipicu

oleh ditekannya sebuah tombol yang menghubungkan dua window.

3.12.4. Architectural Design

Architectural design berfungsi sebagai kerangka kerja dalam aktivitas

pengembangan sistem dan menghasilkan struktur komponen dan proses sistem, yang

bertujuan untuk membuat struktur dari sistem yang terkomputerisasi. Architectural

design terdiri dari 2 bagian yaitu Component Architecture dan Process Architecture.

Component architecture adalah struktur sistem yang terdiri dari komponen-komponen

yang saling berhubungan. Process architecture adalah struktur sistem eksekusi yang

terdiri dari proses yang interdependen. Lewat Process architecture ini ditentukan pola

arsitektural yang paling sesuai dengan model sistem. Aktivitas yang dilakukan dalam

Architectural design adalah mendefinisikan criteria, components dan processes.

75

3.12.4.1. Criteria

Criteria adalah property yang diinginkan dari sebuah arsitektur.

Kriteria umum bagi suatu desain adalah usable, secure, efficient, correct,

reliable, maintainable, testable, flexible, comprehensible, reusable, portable dan

interoperable.

Ada 3 prinsip bagi desain yang baik, yaitu desain yang baik tidak

mempunyai kelemahan utama dan memiliki beberapa kriteria yang seimbang

serta kriteria bagi desain yang baik mencakup 3 kriteria, yaitu usable, flexible

dan comprehensible.

3.12.4.2. Component Architecture

Tujuan dari aktivitas ini adalah untuk membuat struktur sistem yang

mudah dimengerti dan flexible. Components adalah suatu kumpulan dari bagian-

bagian program yang mempunyai tugas yang telah ditentukan. Ada 3 macam

pola (pattern) yang digunakan untuk merancang component architecture yaitu

layered architecture pattern, generic architecture pattern atau client-server

architecture pattern.

Hasil dari aktivitas ini adalah pembuatan Component Diagram, yang

merupakan diagram implementasi yang digunakan untuk menggambarkan

arsitektur fisik dari software sistem. Diagram ini dapat menunjukkan bagaimana

coding pemrograman terbagi menjadi komponen-komponen dan juga

menunjukkan ketergantungan antar komponen tersebut. Berikut adalah contoh

Component Diagram yang ditunjukkan pada Gambar 3.17 di bawah ini.

76

Gambar 3.17 Contoh Component Diagram

3.12.4.3. Process Architecture

Process adalah sekumpulan operasi yang dieksekusi dalam urutan

terbatas dan terhubung. Hasil yang diharapkan dari aktivitas ini adalah

deployment diagram, yaitu diagram yang menggambarkan konfigurasi dari node-

node run time processing dengan komponen-komponen yang berada di dalamnya

dan active objects. Deployment diagram tidak hanya menggambarkan arsitektur

fisik software saja, melainkan software dan hardware. Diagram ini

menggambarkan komponen software, processor, dan peralatan lain yang

melengkapi arsitektur sistem. Berikut adalah contoh dari deployment diagram

yang ditunjukkan oleh Gambar 3.18.

77

Gambar 3.18 Contoh Deployment Diagram

3.12.5. Component Design

Tujuan dari aktivitas ini adalah untuk menentukan kebutuhan bagi implementasi

dalam suatu kerangka arsitektur tetapi tidak menganggu component architecture. Hasil

yang diinginkan dari component design adalah deskripsi dari system components.

3.12.5.1. Model Component

Model component adalah bagian dari sistem yang

mengimplementasikan model dari problem domain. Tujuan dari aktivitas ini

adalah untuk menampilkan model dari sebuah problem domain. Konsep utama

pada model component adalah structure.

78

Hasil dari model component adalah revised class diagram yang

mencakup penambahan class baru, attributes dan structure yang

menggambarkan events.

3.12.5.2. Function Component

Merupakan bagian sistem yang mengimplementasikan kebutuhan

fungsional. Hasilnya adalah class diagram dengan operasi dan fungsi-fungsinya.

Terdapat empat pola eksplorasi untuk merancang function component, yaitu:

1. Model-Class Placement

2. Function-Class Placement

3. Strategy

4. Active Function

79

3.11.2.1. Classes 62 3.11.2.2. Structure 63 3.11.2.3. Behavior 66

3.11.3.1. Usage 67 3.11.3.2. Function 72 3.11.3.3. Interface 73

3.11.4.1. Criteria 75 3.11.4.2. Components 75 3.11.4.3. Processes 76

3.11.5.1. Model Component 77 3.11.5.2. Function Component Error! Bookmark not defined.