BAB 2 LANDASAN TEORI

8

BAB 2 LANDASAN TEORI

2.1

Pengendalian Kualitas

2.1.1

Definisi Kualitas Menurut Montgomery (2009, p4) kualitas dapat didefinisikan dengan berbagai

cara. Pengertian kualitas yang konseptual berhubungan dengan satu atau beberapa karakteristik yang diharapkan untuk dapat dipunyai sebuah produk atau jasa. Kualitas merupakan salah satu faktor keputusan yang paling penting bagi pelanggan untuk dapat memilih produk atau jasa dari sekian banyak kompetisi produk/jasa yang ada. Pengertian dan pengembangan kualitas merupakan faktor kunci untuk pertumbuhan, kesuksesan bisnis, dan pencapaian keunggulan kompetitif. Terdapat definisi tradisional dan modern dari kualitas. Menurut Montgomery (2009, p6) Definisi tradisional dari kualitas adalah kecocokan dengan kegunaan. Hal ini terkait dengan dua aspek, yaitu kualitas desain dan kualitas konformansi. Kualitas desain berhubungan dengan ukuran, perjanjian, penampilan, dan performansi. Kualitas konformansi berhubungan dengan sejauh mana produk memenuhi spesifikasi desain yag telah dibuat. Definisi yang lebih modern dari kualitas adalah kebalikan secara proporsional dari variabilitas. Semakin sedikit terjadinya variabilitas dari sebuah produk, maka kualitasnya akan meningkat. Semakin banyak terjadi variabilitas, maka semakin banyak kemungkinan produk di luar standar, sehingga menimbulkan kemungkinan terjadinya rework dan keperluan waktu, tenaga, dan biaya yang lebih besar. Peningkatan kualitas adalah pengurangan variabilitas pada proses dan produk.

9 2.1.2

Dimensi Kualitas Menurut Montgomery (2009, p4-5) kualitas dari suatu produk dapat

dideskripsikan dan dievaluasi dengan berbagai cara. Delapan komponen atau dimensi kualitas : 1. Performance, yaitu seberapa baik suatu produk dapat melakukan tujuan utamanya. 2. Realibility, yaitu seberapa sering kegagalan produk. 3. Durability, yaitu seberapa lama produk tahan untuk dapat tetap digunakan. 4. Serviceability, yaitu seberapa mudah produk dapat diperbaiki. 5. Aesthetics, yaitu mengenai penampilan produk. 6. Features, yaitu apa saja yang dapat dilakukan oleh produk. 7. Perceived Quality, yaitu bagaimana reputasi perusahaan atau produk tersebut. 8. Conformance atau Standards, yaitu bagaiman suatu produk dapat dijadikan sesuai dengan rancangan yang telah dibuat sebelumnya.

2.1.3

Quality Engineering Menurut Montgomery (2009, p8) setiap produk memiliki beberapa elemen yang

mendeskripsikan hal yang pelanggan atau pengguna pikirkan mengenai kualitas. Parameter ini disebut karakteristik kualitas, atau CTQ (Critical-To-Quality). Quality Engineering merupakan suatu set dari aktivitas operasional, manajerial, dan teknik yang digunakan oleh perusahaan untuk meyakinkan bahwa karakteristik kualitas dari sebuah produk telah mencapai tingkat tertentu dan variabilitas di sekitar tingkat yang diharapkan dapat minimum. Kebanyakan perusahan menemukan kesulitan untuk mencapai karakteristik kualitas yang identik dari satu unit ke unit lain. Penyebabnya

10 adalah terjadinya variabilitas. Karena variabilitas hanya dapat dideskripsikan dengan statistic, maka digunakan aplikasi metode statistik untuk quality engineering.

2.1.4

Manajemen Pengendalian Kualitas Menurut Montgomery (2009, p17) quality planning merupakan aktivitas strategis

dan keharusan untuk mencapai kesuksesan bisnis jangka panjang sebagai rencana pengembangan produk, rencana keuangan, rencana pemasaran, dan rencana penggunaan sumber daya manusia. Quality assurance merupakan serangkaian aktivitas yang meyakinkan bahwa tingkat kualitas dari produk dan jasa dapat dijaga dan isu kualitas dari supplier maupun customer dapat diselesaikan. Quality control dan improvement mencakup serangkaian aktivitas yang digunakan untuk meyakinkan bahwa produk dan jasa mencapai ketentuan dan dikembangkan terus-menerus secara mendasar. Menurut Montgomery (2009, p21-22) W. Edwards Deming merekomendasikan Shewhart Cycle, sebuah model untuk menuntun peningkatan dengan empat tahapan siklus, Plan-Do-Check-Action. Joseph M.Juran mencetukan filosofi manajemen yang fokus ke tiga komponen: perencanaan, kontrol, dan peningkatan (improvement) di mana salah satu tool primer yang digunakan adalah SPC. Armand V. Feigenbaum memperkenalkan konsep pengendalian kualitas secara keseluruhan pada perusahaan, dengan bukunya Total Quality Control di mana tiga langkah peningkatan kualitas didefinisikan yaitu kepemimpinan kualitas, teknologi kualitas, dan komitmen kualitas. Deskripsi secara singkat dari filosofi Deming, Juran, dan Feigenbaum memiliki perbedaan dengan caranya masing-masing, tetapi memiliki persamaan dalam penyampaian kepentingan kualitas sebagai senjata kompetitif, di mana pihak manajemen

11 harus ikut berperan dalam menerapkan peningkatan kualitas, dan kepentingan dari teknik dan metode statistik dalam sebuah formasi kualitas di perusahaan.

2.1.5

Konsep Dasar Six Sigma Menurut Liebermann (2011, p53-54), huruf Yunani sigma (σ) memiliki tiga

kegunaan, dua kegunaan yang pertama saling berintegrasi menjadi yang ketiga – yaitu metodologi six sigma : 1. σ = standar deviasi, yaitu ukuran statistik dari variasi. 2. σ = kapabilitas proses, yaitu ukuran statistik dari kemampuan proses untuk mencapai kebutuhan secara spesifk. 3. 6σ = metodologi manajemen/proses, yaitu sebuah metodologi pemecahan masalah dan peningkatan secara terus-menerus, termasuk di dalamnya pengukuran kesuksesan dibandingkan dengan kebutuhan teknik yang ditentukan oleh pelanggan dan target bisnis. Menurut Tjahjono, et.al (2010, p219-222) six sigma merupakan seperangkat tool statistik yang diadopsi dalam manajemen kualitas untuk membangun sebuah kerangka peningkatan proses. Salah satu strategi untuk peningkatan proses adalah dengan membatasi pendekatan six sigma terhadap satu atau dua kebutuhan bisnis yang kritis yang fokus terhadap peluang dan kelemahan yang paling besar. DMAIC merupakan metode yang digunakan dalam pencapaian keberhasilan six sigma yang lebih difokuskan dalam penghematan biaya. Salah satu aspek yang harus dipertimbangkan dalam sebuah proyek six sigma adalah tool-tool yang digunakan akan harus beradaptasi dan berkembang sesuai dengan kematangan proyek. Sangat perlu untuk menggunakan tool yang tepat di waktu yang tepat untuk mencapai hasil yang sukses. Keuntungan dari six

12 sigma adalah mengurangi biaya, meningkatkan hasil, dan meningkatkan integrasi data. Six sigma dapat digunakan untuk menemukan dan mengeliminasi akar penyebab dari suatu masalah, mengurangi variasi pada proses untuk menghindari defect. Menurut Gasperz (2002, p1-3) six sigma Motorola merupakan metode atau teknik pengendalian dan peningkatan kualitas dramatik yang diterapkan oleh perusahaan Motorola sejak tahun 1986, yang merupakan terobosan baru dalam bidang manajemen kualitas. Metode Six Sigma Motorola dikembangkan dan diterima secara luas oleh dunia industri, karena manajemen frustasi terhadap sistem-sistem manajemen kualitas yang ada, yang tidak mampu melakukan peningkatan kualitas secara dramatik menuju tingkat kegagalan nol (zero defect). Prinsip-prinsip pengendalian dan peningkatan kualitas Six Sigma Motorola telah terbukti berhasil dengan pencapaian tingkat kualitas 3,4 DPMO (defects per million opportunities – kegagalan per sejuta kesempatan) setelah implementasi konsep Six Sigma selama kurang lebih 10 tahun. Hasil-hasil peningkatan kualitas dramatik pada perusahaan diukur berdasarkan persentase antara COPQ (cost of poor quality) terhadap penjualan yang ditunjukkan dalam tabel berikut. Tabel 2.1 Tabel Perbandingan Tingkat Sigma, DPMO, COPQ COPQ (Cost Of Poor Quality) Tingkat Pencapaian Sigma

DPMO

COPQ

691.462 Tidak dapat dihitung (sangat tidak kompetitif) 308.538 Tidak dapat dihitung 2-sigma (rata-rata industri Indonesia) 3-sigma 66.807 25-40% dari penjualan 4-sigma 6.210 15-25% dari penjualan 5-sigma 233 5-25% dari penjualan 6-sigma 3,4 <1% dari penjualan Setiap peningkatan atau pergeseran 1-sigma akan memberikan peningkatan keuntungan sekitar 10% dari penjualan. 1-sigma

Sumber: Gasperz (2002, p3)

13 Menurut Gasperz (2002, p9) pada dasarnya pelanggan akan puas apabila mereka menerima nilai sebagaimana yang mereka harapkan. Apabila produk (barang dan/atau jasa) diproses pada tingkat kualitas six sigma, perusahaan boleh mengharapkan 3,4 kegagalan per sejuta kesempatan (DPMO) atau mengharapkan bahwa 99,99966 persen dari apa yang diharapkan pelanggan akan ada dalam produk itu. Dengan demikian six sigma dapat dijadikan ukuran target kinjerja sistem industri tentang bagaimana baiknya suatu proses transaksi produk antara pemasok (industri) dan pelanggan (pasar). Semakin tinggi target sigma yang dicapai, kinerja sistem indutsri akan semakin baik. Sehingga 6sigma otomatis lebih baik daripada 4-sigma, 4-sigma lebih baik daripada 3-sigma. Six sigma juga dapat dianggap sebagai strategi terobosan yang memungkinkan perusahaan melakukan peningkatan luar biasa (dramatic) di tingkat bawah. Six sigma juga dapat dipandang sebagai pengendalian proses industri berfokus pada pelanggan, melalui penekanan pada kemampuan proses (process capability). Terdapat enam aspek kunci yang perlu diperhatikan dalam aplikasi konsep six sigma, yaitu: 1. Identifikasi pelanggan anda 2. Identifikasi produk anda 3. Identifikasi kebutuhan anda dalam memproduksi produk untuk pelanggan anda 4. Definisikan proses anda. 5. Hindari kesalahan dalam proses anda dan hilangkan semua pemborosan yang ada tingkatkan proses anda secara terus-menerus menuju target six-sigma. Menurut Gasperz (2002, p10) pendekatan pengendalian proses 6-sigma Motorola (Motorola’s Six Sigma process Control) mengizinkan adanya pergeseran nilai rata-rata (mean) setiap CTQ individual dari proses industri terhadap nilai spesifikasi target (T) sebesar ±1,5-sigma (baca: plus/minus 1,5-sigma), sehingga akan menghasilkan 3,4

14 DPMO (defects per million opportunities). Proses six sigma dengan distribusi normal yang mengizinkan nilai rata-rata (mean) proses bergeser 1,5-sigma dari nilai spesifikasi target kualitas (T) yang diinginkan oleh pelanggan, ditunjukkan dalam bagan berikut.

Sumber: http://mvpprograms.com/help/perform/ppa/six_sigma_ppm Gambar 2.1 Konsep Six Sigma Motorola dengan Distribusi Normal Bergeser 1,5 sigma

Sumber: http://www.leantransformation.com/six-sigma-quality.html Gambar 2.2 Konsep Six Sigma dengan Distribusi Normal Terpusat Menurut Gasperz (2002, p10) konsep six sigma Motorola dengan pergeseran nilai rata-rata (mean) dari proses yang diizinkan sebesar 1,5-sigma (1,5 × standar deviasi maksimum) adalah berbeda dari konsep six sigma dalam distribusi normal yang umum

15 dipahami selama ini yang tidak mengizinkan pergeseran dalam nilai rata-rata (mean) dari proses. Perbedaan ini ditunjukkan pada tabel 2.2. Tabel 2.2 Perbedaan True 6-Sigma dengan Motorola’s 6-Sigma True 6-Sigma Process (Normal Distribution Centered) Batas Spesifikasi Persentase DPMO (USL-LSL) 68,27% 317.300 ± 1-Sigma 95,45% 45.500 ± 2-Sigma 99,73% 2.700 ± 3-Sigma 99,9937% 63 ± 4-Sigma 99,999943% 0.57 ± 5-Sigma 0.002 ± 6-Sigma 99,9999998% Sumber: Gasperz (2002, p10)

Motorola’ 6-Sigma (Normal Distribution Shifted 1,5-sigma) Batas Spesifikasi Persentase DPMO (USL-LSL) 30,23% 697.700 ± 1-Sigma 69,13% 308.700 ± 2-Sigma 93,32% 66810 ± 3-Sigma 99,3790% 6210 ± 4-Sigma 233 ± 5-Sigma 99,97670% 3,4 ± 6-Sigma 99,99966%

Menurut Gasperz (2002, p13-14) dalam konteks pengendalian proses statistical dikenal dua jenis data, yaitu: 1. Data Atribut (attributes data) merupakan data kualitatif yang dihitung menggunakan daftar pencacahan untuk keperluan pencatatan dan analisis. Jika suatu catatan hanya merupakan suatu ringkasan atau klasifikasi yang berkaitan dengan sekumpulan persyaratan yang telah ditetapkan, maka catatan tersebut disebut sebagai “atribut”. Contoh data atribut karakteristik kualitas adalah ketiadaan label pada kemasan produk dan banyaknya jenis cacat pada produk. Data atribut biasanya diperoleh dalam bentuk unit-unit nonkonfirmasi/ketidaksesuaian atau cacat/kegagalan terhadap spesifikasi kualitas yang ditetapkan. 2. Data Variabel (variables data) merupakan data kuantitatif yang diukur menggunakan alat pengukuran tertentu untuk keperluan pencatatan dan analisis. Data variabel bersifat kontinyu. Jika suatu catatan dibuat berdasarkan keadaan aktual, diukur secara langsung, maka karakteristik kualitas yang diukur itu disebut sebagai variabel.

16 Contoh data variabel karakteristik kualitas adalah diameter pipa, ketebalan produk, berat semen dalam kantong, dan sebagainya. Menurut Gasperz (2002, p50) DMAIC digunakan untuk meningkatkan proses bisnis yang telah ada. DMAIC terdiri atas lima tahap utama: 1. Define – Mendefinisikan secara formal sasaran peningkatan proses yang konsisten dengan permintaan atau kebutuhan pelanggan dan strategi perusahaan. 2. Measure – Mengukur kinerja proses pada saat sekarang (baseline Measurements) agar dapat dibandingkan dengan target yang ditetapkan. 3. Analyze

– Menganalisis hubungan sebab-akibat berbagai faktor yang dipelajari

untuk mengetahui faktor-faktor dominan yang perlu dikendalikan. 4. Improve – Mengoptimalisasikan proses menggunakan analisis-analisis untuk mengetahui dan mengendalikan kondisi optimum proses. 5. Control – Melakukan pengendalian terhadap proses secara terus-menerus untuk meningkatkan kapabilitas proses menuju target six sigma.

Menurut Gasperz (2002, p31-294) detail per tahapan DMAIC dijelaskan sebagai berikut: 1. Define Define (D) merupakan langkah operasional pertama dalam program peningkatan kualitas six sigma. Sebelum membahas hal ini lebih jauh, perlu dikemukakan bahwa istilah “program peningkatan kualitas six sigma” digunakan untuk lingkup keseluruhan organisasi yang dilaksanakan secara terus-menerus, sedangkan istilah “proyek peningkatan kualitas six sigma” digunakan untuk prosesproses inti dalam organisasi yang ingin ditingkatkan kinerjanya serta pelaksanaannya

17 tergantung pada kebutuhan dari organisasi itu. Suatu proyek di bidang tertentu dapat saja berakhir, kemudian dilanjutkan dengan proyek pada bidang lain, sedangkan program peningkatan kualitas six sigma tidak pernah berakhir (never-ending improvement). Terhadap setiap proyek six sigma yang ditentukan, harus didefinisikan proses-proses kunci, sekuens proses beserta interaksinya, serta pelanggan yang terlibat dalam setiap proses itu. Pelanggan di sini dapat menjadi pelanggan internal maupun eksternal. Sebelum mendefinisikan proses kunci beserta pelanggan dalam proyek six sigma, perlu diketahui model proses “SIPOC (SuppliersInputs-Process-Outputs-Customers).” SIPOC merupakan suatu alat yang berguna dan paling banyak dipergunakan dalam manajemen dan peningkatan proses. Nama SIPOC merupakan akronim dari lima elemen utama dalam sistem kualitas, yaitu: a. Supliers – merupakan orang atau kelompok orang yang memberikan informasi kunci, material, atau sumber daya lain kepada proses. Jika suatu proses terdiri dari beberapa sub-proses, maka sub-proses sebelumnya dapat dianggap sebagai pemasok internal (internal suppliers). b. Inputs – adalah segala sesuatu yang diberikan oleh pemasok (suppliers) kepada proses. c. Processes – merupakan sekumpulan langkah yang mentranformasi dan secara ideal, menambah nilai kepada Inputs (proses transformasi nilai tambah kepada Inputs). Suatu proses biasanya terdiri dari beberapa sub-proses. d. Outputs – merupakan produk (barang dan/atau jasa) dari suatu proses. Dalam industri manufaktur Outputs dapat berupa barang setengah jadi maupun barang jadi (final product). Termasuk ke dalam Outputs adalah informasi-informasi kunci dari proses.

18 e. Customers – merupakan orang atau kelompok orang, atau sub-proses yang menerima Outputs. Jika suatu proses terdiri dari beberapa sub-proses, maka subproses sesduahnya dapat dianggap sebagai pelanggan internal (internal customers). Proses berikut merupakan pelanggan (the next process is your customers). Kemudian diidentifikasi langkah-langkah aktivitas beserta deskripsinya dalam suatu proses yang terkait dengan proyek six sigma dengan menggunakan form diagram alir proses (process flowcharts).

Sumber: http://www.innovationmanagement.org/Wiki/index.php?title=SIPOC Gambar 2.3 SIPOC Diagram dalam Kasus Pembelian Mobil 2. Measure Measure (M) merupakan langkah operasional kedua dalam program pengingkatan kualitas six sigma. Terdapat tiga hal pokok yang harus dilakukan

19 dalam tahap MEASURE (M), yaitu: (1) memilih atau menentukan karakteristik kualitas (CTQ) kunci yang berhubungan langsung dengan kebutuhan spesifik dari pelanggan, (2) mengembangkan suatu rencana pengumpulan data melalui pengukuran yang dapat dilakukan pada tingkat proses, output, dan/atau outcome, dan (3) mengukur kinerja sekarang (current performance) pada tingkat proses, output, dan/atau outcome untuk ditetapkan sebagai baseline kinerja (performance baseline) pada awal proyek six sigma) Karakteristik kualitas (Critical-to-quality = CTQ) kunci yang ditetapkan seyogianya berhubungan langsung dengan kebutuhan spesifik dari pelanggan, yang diturunkan secara langsung dari persyaratan-persyaratan output dan pelayanan. 3. Analyze Analyze (A) merupakan langkah operasional ketiga dalam program peningkatan kualitas six sigma. Pada tahap ini kita perlu melakukan beberapa hal berikut: (1) menentukan stabitilitas (stability) dan kapabilitas (capability) dari proses, (2) menetapkan target-target kinerja dari karakteristik kualitas kunci (CTQ) yang akan ditingkatkan dalam proyek six sigma, (3) mengidentifikasi sumber-sumber dan akar penyebab kecacatan atau kegagalan, dan (4) mengkonversikan banyak kegagalan ke dalam biaya kegagalan kualitas (cost of poor quality). Pemahaman yang baik tentang metode-metode statistika dan perilaku proses industri akan mampu meningkatkan kinerja sistem industri. Pemahaman ini mengenai: (1) perilaku proses industri (statistical thinking), dan (2) alat-alat statistika (statistical tools) merupakan dua hal utama yang harus dimiliki oleh tim proyek six sigma. Jadi, pemahaman tentang proses industri ini disebut dengan “statictical thinking” yang harus dibedakan dengan “statictical tools”. Dengan demikian penggunaan metode statistika dalam

20 industri bukan sekadar menerapkan alat-alat statistika (statistical tools), tetapi lebih diutamakan untuk mengendalikan dan meningkatkan proses industri guna meningkatkan kinerja sistem industri itu menuju target kegagalan nol (statistical thinking). Variasi

adalah

ketidakseragaman

dalam

sistem

industri

sehingga

menimbulkan perbedaan dalam kualitas pada produk (barang dan/atau jasa) yang dihasilkan. Pada dasarnya dikenal ada dua sumber atau penyebab timbulnya variasi, yang diklasifikasikan sebagai berikut : a. Variasi penyebab-khusus (special-causes variation) adalah kejadian-kejadian di luar sistem industri yang mempengaruhi variasi dalam sistem industri itu. Penyebab khusus mengambil pola-pola nonacak (nonrandom patterns) sehingga dapat diidentifikasi/ditemukan, sebab mereka tidak selalu aktif dalam proses tetapi memiliki pengaruh yang lebih kuat pada proses sehingga menimbulkan variasi. b. Variasi penyebab-umum (common-causes variation) adalah faktor-faktor di dalam sistem industri atau yang melekat pada proses industri yang menyebabkan timbulnya variasi dalam sistem indutri serta hasil-hasilnya. Penyebab umum sering disebut juga sebagai penyebab acak (random causes) atau penyebab sistem (system causes). Oleh karena penyebab umum ini selalu melekat pada sistem, maka untuk menghilangkannya harus menelusuri pada elemen-elemen dalam sistem itu dan hanya pihak manajemen industri yang dapat memperbaikinya, karena pihak manajemen industri yang mengendalikan sistem industri itu.

21 Kontribusi utama dari penggunaan metode statistika dalam pengendalian sistem industri adalah memisahkan variasi total proses ke dalam dua sumber di atas, Suatu sistem industri disebut berada dalam pengendalian statistical apabila sistem itu terbebas dari variasi yang ditimbulkan oleh penyebab khusus. Kinerja dari sistem industri akan dapat diprediksi dengan baik. Untuk dapat menemukan akar penyebab dari suatu masalah, maka kita perlu memahami dua prinsip yang berkaitan dengan hukum sebab-akibat, yaitu: a. Suatu akibat terjadi atau ada hanya jika penyebabnya itu ada pada titik yang sama dalam ruang dan waktu. b. Setiap akibat mempunyai paling sedikit dua penyebab dalam bentuk: (a) penyebab yang dapat dikendalikan (Controllable causes). Penyebab yang dapat dikendalikan berarti penyebab itu berada dalam lingkup tanggung jawab dan wewenang

kita

sehingga

dapat

diambil

tindakan

(actionable)

untuk

menghilangkan penyebab itu. Sebaliknya penyebab yang tidak dapat dikendalikan berada di luar pengendalian. Penyebab yang tidak dapat dikendalikan (berada di luar kontrol) terdiri dari paling sedikit dua penyebab, yaitu (b1) penyebab yang dapat diperkirakan (predictable causes) sehingga memungkinkan kita untuk mengantisipasi dan mencegahnya, dan (b2) penyebab yang tidak dapat diperkirakan karena belum ada referensi atau pengetahuan tentang kejadian itu sebelumnya. Apabila kita mengumpulkan jawaban dari penyebab yang dapat dikendalikan dan jawaban dari penyebab yang tidak dapat dikendalikan namun dapat diperkirakan, maka dua tindakan solusi masalah berikut dapat diambil, yaitu: (1) menghilangkan akar penyebab yang dapat dikendalikan, dan (2) mengantisipasi melalui tindakan

22 pencegahan terhadap penyebab yang tidak dapat dikendalikan namun dapat diperkirakan itu. Selanjutnya akar-akar penyebab dari masalah yang ditemukan melalui bertanya “mengapa” dimasukkan ke dalam diagram sebab-akibat yang mengkategorikan sumber-sumber penyebab berdasarkan prinsip 7M, yaitu : a. Manpower (tenaga kerja): berkaitan dengan kekurangan dalam pengetahuan (tidak terlatih, tidak berpengalaman), kekurangan dalam keterampilan dasar yang berakitan dengan mental dan fisik, kelelahan, stress, ketidakpedulian, dll. b. Machines (mesin-mesin) dan peralatan: berkaitan dengan tidak ada sistem perawatan preventif terhadap mesin-mesin produksi, termasuk fasilitas dan peralatan lain, tidak sesuai dengan spesifikasi tugas, tidak dikalibrasi, terlalu kompleks, terlalu panas, dll. c. Methods (metode kerja): berkaitan dengan tidak adanya prosedur kerja yang benar, tidak jelas, tidak diketahui, ditak terstandardisasi, tidak cocok, dll. d. Materials (bahan baku dan bahan penolong): berkaitan dengan ketiadaan spesifikasi kualitas dari bahan baku dan bahan penolong yang digunakan, ketiadaan penanganan yang efektif terhadap bahan baku dan penolong itu, dll. e. Media: berkaitan dengan tempat dan waktu kerja yang tidak memperhatikan aspek-aspek kebersihan, kesehatan dan keselamatan kerja, dan lingkungan kerja yang kondusif, kekurangan dalam lampu penerangan, ventilasi yang buruk, kebisingan yang berlebihan, dll. f. Motivation (motivasi): berkaitan dengan ketiadaan sikap kerja yang benar dan profesional (tidak kreatif, bersikap reaktif, tidak mampu bekerja sama dalam tim, dan lain-lain), yang dalam hal ini disebabkan oleh sistem balas jasa dan penghargaan yang tidak adil kepada tenaga kerja.

23 g. Money (keuangan): berkaitan dengan ketiadaan dukungan finansial (keuangan) yang mantap guna memperlancar proyek peningkatan kualitas six sigma yang akan diterapkan. FMEA (failure mode and effect analysis) adalah suatu prosedur terstruktur untuk mengidentifikasi dan mencegah sebanyak mungkin mode kegagalan (failure modes). Suatu mode kegagalan adalah apa saja yang termasuk dalam kecacatan/kegagalan dalam desain, kondisi di luar batas spesifikasi yang telah ditetapkan,

atau

perubahan-perubahan

dalam

produk

yang

menyebabkan

terganggunya fungsi dari produk itu. 4. Improve Setelah sumber-sumber dan akar-akar penyebab dari masalah kualitas teridentifikasi, maka perlu dilakukan rencana tindakan (action plan) untuk melaksanakan peningkatan kualitas six sigma. Pada dasarnya rencana-rencana tindakan (action plan) akan mendeskripsikan tentang alokasi sumber-sumber daya serta prioritas dan/atau alternative yang dilakukan dalam implementasi dari rencana itu. Bentuk-bentuk pengawasan dan usaha-usaha untuk mempelajari melalui pengumpulan data dan analisis ketika implementasi dari suatu rencana, juga harus direncanakan. 5. Control Control (C) merupakan tahap operasional terakhir dalam proyek peningkatan kualitas six sigma. Pada tahap ini hasil-hasil peningkatan kualitas didokumentasikan dan disebarluaskan, praktek-praktek terbaik yang sukses dalam meningkatkan proses distandardisasikan dan disebarluaskan, prosedur-prosedur didokumentasikan dan dijadikan

prosedur

kerja

standar.

Tujuan

dari

standardisasi

adalah

24 menstandardisasikan sistem kualitas six sigma yang telah terbukti menjadi terbaik dalam bisnis kelas dunia. Hasil-hasil yang memuaskan dari proyek peningkatan kualitas six sigma harus distandardikasikan, dan selanjutnya dilakukan peningkatan terus-menerus pada jenis masalah yang lain melalui proyek-proyek six sigma yang lain mengikuti konsep DMAIC. Standardisasi dimaksudkan untuk mencegah masalah yang sama atau praktek-praktek

lama

terulang

kembali.

Terdapat

dua

alasan

melakukan

standardisasi: a. Apabila tindakan peningkatan kualitas atau solusi masalah itu tidak distandardisasikan, terdapat kemungkinan bahwa setelah periode waktu tertentu, manajemen dan karyawan akan kembali menggunakan cara-cara kerja lama sehingga memunculkan kembali masalah yang sudah pernah diselesaikan itu. b. Apabila tindakan peningkatan kualitas atau solusi masalah itu tidak distandardisasikan dan didokumentasikan, maka terdapat kemungkinan setelah periode waktu tertentu apabila terjadi pergantian manajemen dan karyawan, orang-orang baru akan menggunakan cara-cara kerja yang memunculkan kembali masalah yang sudah pernah diselesaikan oleh manajemen dan karyawan terdahulu itu.

Menurut Haftl (2007, p4) sepuluh elemen yang harus diperhatikan untuk sebuah implementasi six sigma yang sukses: 1. Dukungan dan komitmen manajemen yang terlihat. 2. Kesesuaian program dengan strategi bisnis. 3. Kesesuaian program dengan harapan dan permintaan pelanggan.

25 4. Edukasi dan training. 5. Sebuah sistem manajemen proses yang diterapkan dengan baik. 6. Infrastruktur untuk mengelola program. 7. Kemampuan untuk siap dalam mengkomitmenkan orang yang terbaik ke program. 8. Sistem penghargaan dan pengakuan untuk anggota tim. 9. Pengertian yang dibagikan mengenai inti proses bisnis dan karakteristik kritikalnya. 10. Mengkomunikasikan pengalaman kesuksesan dan kegagalan.

2.2

Model, Korelasi dan Anova

2.2.1

Pembangunan Model Menurut Aczel (2009, p440) sebuah model statistik merupakan serangkaian dari

formula dan asumsi matematik yang mencerminkan situasi di dunia nyata. Sebuah model diharapkan dapat menjelaskan sebanyak mungkin mengenai proses berdasarkan data. Bagaimanapun juga, berdasarkan pada sifat yang mendasar pada situasi dunia nyata, yaitu ketidakpastian, model ini mungkin tidak dapat menjelaskan seluruhnya, dan akan selalu ada kesalahan (error) yang tetap muncul. Error ini merupakan faktor luar yang tidak diketahui yang mempengaruhi proses dalam mengenerasi data. Menurut Aczel (2009, p441) sebuah model statistik yang baik bersifat parsimonious, yang berarti menggunakan sesedikit mungkin batasan matematik untuk mendeskipsikan situasi nyata. Sebuah model menangkap perilaku sistematis dari data, meninggalkan faktor yang tidak sistematis dan tida dapat diprediksi, yaitu error. Diasumsikan bahwa random error

berdistribusi normal.

Menurut Aczel (2009, p219-222) selang kepercayaan merupakan rentang nilai yang dipercaya untuk memasukkan sebuah parameter populasi yang tidak diketahui.

26 Selang ini merupakan sebuah ukuran keyakinan. Dalam bisnis dan aplikasi lainnya, selang kepercayaan 95% secara umum digunakan.

2.2.2

Model Simpel Regresi Linear Menurut Aczel (2009, p230) persamaan aljabar dari sebuah garis liris adalah Y =

A+BX, di mana A merupakan intersep (faktor yang menahan) dan B merupakan slope (lekuk) dari sebuah garis. Pada simple regresi linear, hubungan antara dua variabel X dan Y dimodelkan dengan sebuah garis lurus. Oleh karena itu, model harus mencakup dua parameter yaitu parameter intersep dan parameter slope. Notasi untuk populasi intersep adalah βo , dan notasi untuk populasi slope adalah β1 . Jika error dimasukkan, populasi model regresinya sebagai berikut: Y=βo + β1 X + di mana Y merupakan variabel dependen, variabel yang diharapkan dapat diprediksi; X merupakan variabel independen, disebut juga variabel predictor; dan adalah faktor error, satu-satunya komponen acak pada model dan sumber dari keacakan Y. Asumsi dari model sebagai berikut : 1. Hubungan antara X dan Y merupakan hubungan garis lurus. 2. Nilai dari variabel independen X diasumsikan pasti (tidak acak); satu-satunya keacakan Y berasal dari faktor error 3. Error

.

berdistribusi normal dengan nilai tengah 0 dan bervariansi konstan σ2 . Error

tidak berhubungan satu sama lain.

27 Berikutnya adalah memperhitungkan garis least-square, yaitu garis yang meminimasi SSE. SSE merupakan sum squares of error (jumlah kuadrat error). Kalkulus digunakan untuk menemukan nilai dari b0 (atau βo ) dan b1 (atau β1 ) yang meminimasi SSE. Persamaan normalnya sebagai berikut: n

n

Yi = nb0 + b1 i=1

Xi i=1

Definisi dari sums of squares dan hubungan antar produk yang digunakan di analisis regresi sebagai berikut: 2

SSx =

(∑x) xn

2

SSy =

(∑y) yn

SSxy =

2

2

xy-

( ∑ x )( ∑ y ) n

Perkiraan least-square untuk b0 dan b1 sebagai berikut : Perkiraan regresi least-squares untuk slope b1 =

SSxy SSx

Dan intersepnya b0 =y-b1 x

Menurut Groebner, Shannon, Smith, & Fry (2001, p425) scatter Plot – sebuah bidang dua dimensi yang menunjukkan nilai untuk suatu kejadian penggabungan dari dua variabel. Scatter plot dapat digunakan untuk mewakilkan secara grafis sebuah hubungan/relasi antara dua variabel. Disebut juga dengan scatter diagram. Scatter plot

28 menggambarkan hubungan potensial di antara nilai sebuah variabel dependen, y, dan sebuah variabel independen, x. Variabel dependen, yaitu variabel yang akan diprediksi atau dijelaskan dengan sebuah model regresi. Variabel ini diasumsikan untuk berhubungan secara fungsional dengan variabel independen. Variabel independen, yaitu variabel yang berhubungan dengan variabel dependen dalam sebuah persamaan regresi. Variabel independen digunakan pada sebuah model regresi untuk memperkirakan nilai dari variabel dependen.

2.2.3

Koefisien Korelasi Menurut Groebner, Shannon, Smith, & Fry (2001, p430) koefisien korelasi

adalah sebuah ukuran kuantitatif dari kekuatan sebuah hubungan linear antara dua variabel. Rentang nilai korelasi adalah -1.0 sampai +1.0. Korelasi ±1.0 mengindikasikan sebuah relasi linear yang sempurna, dimana korelasi 0 menunjukkan tidak adanya hubungan linear. Sebuah koefisien korelasi dari dua variabel dapat diperkirakan dengan sampel data menggunakan persamaan aljabar : r=

∑ (x-x )(y-y) n ∑ x2 - ∑ x

2

- n ∑ y2 - ∑ y

2

r = koefisien korelasi sampel n = ukuran sampel x = nilai dari variabel independen y = nilai dari variabel dependen Koefisien korelasi sampel yang digunakan dengan persamaan tersebut disebut sebagai Pearson Product Moment Correlation.

29 2.2.4

Tes Signifikan untuk Korelasi Besarnya nilai koefisien korelasi harus dianalisa lebih lanjut. Menurut Groebner,

Shannon, Smith, & Fry (2001, p430-442) walaupun nilai koefisien korelasi, misalnya 0.8325 kelihatannya cukup tinggi (dibandingkan dengan 0), nilai yang didasarkan hanya dari sampel 12 data dapat saja menjadi kesalahan sampling. Karena itu, sebuah prosedur uji hipotesis normal dibutuhkan untuk menentukan apakah memang ada hubungan antara dua variabel terkait. Digunakan simbol Yunani ρ (rho) untuk mewakili koefisien korelasi populasi. H0 : ρ = 0.0 (tidak ada korelasi) H1 : ρ > 0.0 (ada hubungan korelasi) Harus diuji apakah sampel data mendukung untuk dapat menolak hipotesis nol. Prosedur tesnya menggunakan t-statistic dengan persamaan berikut : t=

r 1-r2 n-2

df = n-2 t = nilai perkiraan standar deviasi r dari 0 r = koefisien korelasi sampel n = ukuran sampel

Uji t untuk menentukan apakah korelasi populasinya sama sekali bukan 0 mengasumsikan bahwa kedua variabel (x dan y) memiliki distribusi bivariate normal. Dua variabel dikatakan bivariate normal apabila distribusi gabungannya berdistribusi normal.

30 Menurut Groebner, Shannon, Smith, & Fry (2001, p806) derajat kebebasan merupakan angka dari nilai data independen yang dapat digunakan untuk memperkirakan standar deviasi populasi. Jika sejumlah k parameter harus diperkirakan sebelum sebuah standar deviasi dapat dihitung dari sejumlah sampel sebanyak n, derajat kebebasannya sebesar n-k. Nilai dari derajat bebas (df atau degrees of freedom) yang digunakan untuk tes ini adalah n-2 karena satu derajat kebebasan telah digunakan untuk memperkirakan nilai tengah populasi dari dua variabel di persamaan r sebelumnya.

2.2.5

Uji Regresi Menurut Groebner, Shannon, Smith, & Fry (2001, p439-440) salah satu ukuran

dari kecocokan regresi adalah dengan mean square error (MSE). MSE memperkirakan variansi dari regresi sebenarnya dan mengukur variasi data terhadap garis regresi. Selain itu dibutuhkan ukuran relatif dari derajat variasi data terhadap garis regresi. Ukuran relatif lainnya yang membandingkan variasi Y dengan garis regresi, dengan variasi Y tapa regresi, yang disebut koefisien determinasi (r2). Koefisien determinasi r2 merupakan ukuran deskriptif dari kekuatan hubungan regresi, ukuran sebagaimana baik garis regresi cocok dengan data. Koefisien korelasi r dapat bernilai antara -1 sampai 1. Kuadratnya, r2 dapat bernilai 0 sampai 1. Interpretasi dari r2 adalah persentase dari variasi Y yang dapat dijelaskan dengan regresi. Jika r2=1, diketahui bahwa 100% Y dijelaskan dengan X. Ini berarti bahwa semua data terletak pada garis regresi, dan tidak terdapat error. Walaupun r2 tidak dapat bernilai negatif (dari r2 tidak terlihat apakah garis regresi terus naik atau terus turun (arahnya dapat diketahui dari b1 atau r), dari r2 dapat diketahui bahwa garis memberikan kecocokan yang sempurna dengan data. Kasus seperti ini tidak terjadi dalam bisnis dan ekonomi. Pada faktanya, ketika tidak ada error, tidak ada variasi

31 alami, tidak diperlukan statistik. Semakin tinggi nilai r2, semakin cocok data dan semakin tinggi keyakinan pada regresi yang telah dibuat. Nilai r2 0.9 atau lebih sangat baik, lebih dari 0.8 baik, 0.6 atau lebih dapat memuaskan di beberapa aplikasi, 0.5 atau kurang, prediksinya tidak baik. Jika hanya dipentingkan mengenai adanya hubungan antara variabel-variabel nilai r2 yang rendah dapat saja diterima, dengan kondisi model tersebut tidak akan dapat banyak menjelaskan hubungan antar variabel. Menurut Aczel (2009, p810) dalam regresi sering ditemukan istilah residual. Residual adalah perbedaan dari nilai variabel dependen secara nyata dengan nilai yang diprediksi dengan model regresi. Berikutnya, dengan ANOVA (Analysis of Variance) dipertimbangkan deviasi dari perlakuan yang diberikan, deviasi dari nilai tengah kelompok dari nilai tengah keseluruhan. ANOVA digunakan untuk menguji apakah ada perbedaan signifikan dari populasi yang dibandingkan. Ketentuan yang digunakan untuk menentukan keputusan adalah, tolak H0 bila statistik sampel jatuh pada daerah kritis. Jika tes menggunakan pendekatan p-value, H0 ditolak apabila p-value lebih kecil dari taraf nyata; selain itu H0 tidak ditolak. Dalam melakukan perhitugan ANOVA digunakan tabel ANOVA, sebagai berikut: Tabel 2.3 ANOVA 1 Interaksi Source of Variation

Sum of Squares

Degrees of Freedom

Mean Square

F Ratio F

Treatment

SSTR

r-1

MSTR

Error

SSE

n-r

MSE

Total

SST

n-1

32 r

ni (xi -x)

SSTR=

2

i=1 ni

r

(xij -xi )2

SSE= i=1 j=1

SST=SSTR+SSE MSTR MSE= F=

SSTR r‐1 E n-r

MSTR MSE Tes statistik dari ANOVA yaitu uji F = F(r-1,n-r) di mana r adalah jumlah kelas

dari populasi dan n adalah jumlah populasi. Terima H0 jika F>F(r-1,n-r) .

2.2.6

Metode Solver Excel untuk Regresi Menurut Groebner, Shannon, Smith, & Fry (2001, p458) Metode Solver di

Microsoft Excel dapat digunakan untuk memaksa regresi mencapai titik tertentu di mana dibuat suatu batasan nilai untuk dicapai. Kriteria dari titik line terbaik pada metode Solver meminimalisasi sum of squared errors (SSE).

2.2.7

Uji Chi-Square Goodness-of-Fit Menurut Groebner, Shannon, Smith, & Fry (2001, p458) uji goodness-of-fit dapat

digunakan untuk menentukan apakah data sampel cocok dengan distribusi tertentu. Logika dalam pengujian ini berdasarkan penentuan sejauh mana frekuensi observasi dari frekuensi yang diharapkan.

33 k 2

X= i=1

oi -ei ei

2

df=k-1 k = jumlah kategori atau sampel oi = nilai observasi ei = nilai harapan Ketentuan pengambilan keputusannya adalah, H0 diterima jika nilai X2 lebih kecil dari nilai kritisnya. Nilai kritis yang ditentukan adalah X2(df).

2.3

Analisa dan Perancangan Sistem Informasi

2.3.1

Definisi Sistem Informasi Menurut O’Brien (2005, p5) sistem informasi merupakan kombinasi teratur apa

pun dari orang-orang, hardware, software, jaringan komunikasi, dan sumber daya data yang mengumpulkan, mengubah, dan menyebarkan informasi dalam sebuah organisasi. Orang bergantung pada sistem informasi untuk berkomunikasi antara satu sama lain dengan menggunakan berbagai jenis alat fisik (hardware), perintah (software), saluran komunikasi (jaringan), dan data yang disimpan (sumber daya data) sejak permulaan peradaban. Menurut O’Brien (2005, p39-41) aktivitas sistem informasi diklasifikasikan menjadi lima: 1. Input. Input biasanya berbentuk aktivitas entri data seperti pencatatan dan pengeditan. Para pemakai akhir biasanya memasukkan data secara langsung ke dalam sistem komputer, atau mencatat data mengenai transaksi dalam beberapa jenis

34 media fisik seperti formulir kertas. Hal ini biasanya meliputi berbagai aktivitas edit untuk memastikan bahwa data telah dicatat dengan benar. 2. Pemrosesan. Data biasanya tergantung pada aktivitas pemrosesan seperti perhitungan, perbandingan, pemilahan, pengklasifikasian, dan pengikhtisaran. Aktivitas-aktivitas ini mengatur, menganalisis, dan memanipulasi data, hingga mengubahnya ke dalam informasi bagi para pemakai akhir. Kualitas data apa pun yang disimpan dalam sistem informasi juga harus dipelihara melalui proses terusmenerus dari aktivitas perbaikan dan pembaruan. 3. Output. Informasi dalam berbagai bentuk dikirim ke pemakai akhir dan disediakan untuk mereka dalam aktivitas output. Tujuan dari sistem informasi adalah untuk menghasilkan produk informasi yang tepat bagi para pemakai akhir. Produk informasi umum meliputi pesan, laporan, formulir, dan gambar grafis, yang dapat disediakan melalui tampilan video, respons audio, produk kertas, dan multimedia. 4. Penyimpanan. Penyimpanan dalah komponen sistem dasar sistem informasi. Penyimpanan adalah aktivitas sistem informasi tempat data dan informasi disimpan secara teratur untuk digunakan kemudian. 5. Pengendalian. Sistem informasi harus menghasikan umpan balik mengenai aktivitas input, pemrosesan, output, dan penyimpanan. Umpan balik ini haris diawasi dan dievaluasi untuk menetapkan apakah sistem dapat memenuhi standar kinerja yang ditetapkan.

2.3.2

Analisa dan Desain Sistem Menurut Satzinger, Jackson, & Burd (2005, p3-4) sistem informasi merupakan

faktor yang sangat penting untuk kesuksesan dari organisasi bisnis modern. Sistem yang

35 baru secara konstan dikembangkan untuk membuat bisnis menjadi lebih kompetitif. Kunci untuk pengembangan sistem yang sukses adalah melalui analisis dan desain sistem untuk dapat mengerti kebutuhan bisnis dari sistem informasi. Analisis sistem berarti mengetahui dan menspesifikasikan detil dari apa yang sistem informasi harus lakukan. Sistem desain berarti menspesifikasikan ke dalam detail bagaimana banyak komponen dari sistem informasi harus diterapkan secara fisik.

2.3.3

Sistem Informasi Menurut Satzinger, Jackson, & Burd (2005, p6-8) sistem merupakan sekumpulan

dari komponen yang saling berhubungan yang bekerja sama untuk meraih suatu hasil tertentu. Sistem informasi yaitu sekumpulan dari komponen yang saling berhubungan yang mengumpulkan, memproses, menyimpan, dan mendukung keluaran informasi yang diperlukan untuk melengkapi suatu tugas bisnis. Sebuah sistem dapat memiliki beberapa subsistem. Subsistem merupakan sebuah sistem yang merupakan bagian dari sistem lain. Setiap sistem, sebaliknya, merupakan bagian dari sistem yang lebih besar, yang disebut supersistem. Setiap sistem memiliki batasan (boundary) di antara sistem tersebut dan lingkungannya. Menentukan input dan output merupakan bagian yang penting dari analisis dan desain sistem. Dalam sebuah sistem informasi, orang-orang merupakan komponen kunci, dan orang-orang ini melakukan suatu pekerjaan yang akan diselesaikan oleh suatu sistem. Jadi, terdapat batasan lain yang penting untuk seorang system analyst, yang disebut automation boundary.

36 2.3.4

Jenis – Jenis Sistem Informasi Menurut Satzinger, Jackson, & Burd (2005, p9-10) Transaction processing

systems (TPS) yaitu sistem yang menangkap dan menyimpan informasi mengenai transaksi yang mempengaruhi perusahaan. Management information systems (MIS) yaitu sistem yang mengambil informasi yang telah ditangkap oleh TPS dan memproduksi laporan yang manajemen butuhkan untuk perencanaan dan pengendalian bisnis. MIS mungkin dibuat karena informasi telah ditangkap oleh TPS dan disimpan ke dalam database perusahaan. Executive information systems (EIS) menyediakan informasi untuk digunakan oleh eksekutif dalam mengawasi lingkungan kompetitif dan untuk perencanaan strategis. Beberapa informasinya berasal dari data perusahaan, tetapi banyak informasi berasal dari sumber eksternal, misalnya pesaing laporan saham, peramalan ekonomi, dan sebagainya. Decision support systems (DSS) memungkinkan user ntuk memerika akibat dari beberapa pilihan atau keputusan. Kadang proses ini disebut analisis “bagaimana jika” (“what-if” analysis) karena user menanyakan ke sistem untuk dapat menjawab pertanyaan user mengenai peramalan situasi tertentu, misalnya berapa armada yang diperlukan untuk dapat mengelola distribusi pada periode berikutnya. Communication support systems memungkinkan karyawan untuk dapat berkomunikasi satu sama lain dan dengan customer dan supplier. Misalnya wireless personal digital assistants (PDA), ponsel dengan fitur pesan dan PDA, video conference, dan sebagainya. Office support systems yang membantu karyawan untuk membuat dan membagi dokumen, termasuk laporan, penawaran, dan catatan lain. Office support systems dapat juga membantu pengelolaan jadwal kerja, perjanjian, dan meeting.

37 2.3.5

Unified Process (UP) Menurut Satzinger, Jackson, & Burd (2005, p50-51) Unified Process (UP)

merupakan sebuah metodologi pengembangan sebuah sistem object-oriented yang sangat berpengaruh dan paling banyak digunakan. Siklus hidup Unified Process termasuk di dalamnya fase penyelesaian proyek dari waktu ke waktu, tetapi setiap fase siklus hidup melalui satu atau lebih iterasi, yaitu tahap analisis, desain, dan implementasi untuk bagian dari sistem. Pada akhir dari setiap iterasi, tim proyek menggunakan siklus hidup UP yang telah lengkap dan beberapa bagian software yang telah dievaluasi dengan use dari sistem. Empat fase dari siklus hidup UP dinamakan inception, elaboration, construction, dan transition.

Sumber: Satzinger, Jackson, & Burd (2005, p45) Gambar 2.4 Sikus Hidup Pengembangan Sistem Unified Process Pada tahap inception, developer mengembangkan dan menentukan pandangan dari sistem yang baru untuk menunjukkan bagaimana sistem tersebut akan meningkatkan operasi dan menyelesaikan permasalahan saat ini. Pada tahap elaboration, dilengkapi identifikasi dan definisi untuk semua kebutuhan sistem. Di tahap construction, desain sistem diteruskan dan sistem diimplemetasikan. Di tahap transition, sistem yang dikembangkan telah siap untuk dioperasikan.

38

Sumber: Satzinger, Jackson, & Burd (2005, p53) Gambar 2.5 Disiplin UP Yang Digunakan Dalam Berbagai Tingkat Kebutuhan di Setiap Iterasi Menurut Satzinger, Jackson, & Burd (2005, p55) enam disiplin dari pengembangan UP adalah : business modelling, requirements, design, implementation, testing, dan deployment. Garis besar dari pengembangan disiplin UP sebagai berikut : 1. Business Modelling Tujuan

utama

dari

disiplin

ini

adalah

untuk

mengerti

dan

mengkomunikasikan sifat alami dari lingkungan bisnis di mana sistem akan disiapkan. Permasalahan saat ini dan peningkatan potensial yang dapat dilakukan oleh sistem harus dapat dimengerti. UML diagram dapat digunakan untuk mendokumentasikan aspek lingkungan dari sistem yang

39 akan dikembangkan dengan pemodelan aliran kerja, objek bisnis, dan fungsi dasar yang harus didukung oleh sistem. 2. Requirements Tujuan

utama

dari

disiplin

ini

adalah

untuk

mengerti

dan

mendokumentasikan kebutuhan bisnis dan proses bagi sistem yang akan dikembangkan. Problem domain - daerah di mana user membutuhkan penyelesaian

sisem

informasi

didefinisikan.

Kebutuhan

fungsional

digambarkan dengan use case dan description, dan langkah interaksi user dengan siste digambarkan dengan UML diagram. 3. Design Tujuan dari disiplin ini adalah untuk mendesain solusi sistem berdasarkan kebutuhan yang telah ditentukan sebelumnya. User interface, komponen software, database, dan lingkungan operasional ditentukan. 4. Implementation Disiplin ini termasuk pembangunan sistem yang diperlukan secara nyata. Aplikasi dapat dikembangkan dengan beragam teknik. 5. Testing Disiplin testing ditentukan dengan menjalankan tes dan menggunakan sampel data untuk mengevaluasi sistem dalam berbagai kondisi tertentu. 6. Deployment Disiplin deployment mennjuk kepada aktivitas untuk membuat sistem diterapkan secara operasional, termasuk pemasangan hardware dan software, instalasi komponen, pelatihan karyawan, dan pengkonversian data.

40 7. Project Management Disiplin ini bertujuan untuk mendukung team pengembang, dalam hal finalisasi sistem dan lingkup proyek sampai kepada pengawasan dan pengendalian

penjadwalan,

komunikasi

internal

dan

eksternal,

dan

penyelesaian isu resiko. 8. Configuration and Change Management Disiplin ini termasuk pengembangan prosedur kontrol dan manajemen model dan komponen software. 9. Environment Disiplin ini dijalankan dengan pengelolaan lingkungan sistem dan fasilitas terkait.

2.3.6

Model dan UML Menurut Satzinger, Jackson, & Burd (2005, p47) Setiap kali seseorang perlu

untuk menyimpan atau mengkomunikasikan informasi, sangat diperlukan untuk membentuk sebuah model. Sebuah model merupakan representasi dari aspek penting pada dunia nyata. Model digunakan untuk pengembangan sistep termasuk representasi dari input, output, proses, data, objek, interaksi objek, lokasi, jaringan, perangkat, dan lain-lain. Sebagian besarnya merupakan model grafis, disebut diagram atau chart. Menurut Satzinger, Jackson, & Burd (2005, p47) diagram yang dibuat untuk menunjukkan model sistem digambar mengikuti notasi yang telah ditentukan melalui Unified Modelling Languange (UML). UML merupakan seperangkat standar dari model yang dibangun dan dinotasikan secara khusus untuk pengembangan object-oriented.

41 Dengan menggunakan UML, analisis dan end user dapat mengerti variasi diagram yang digunakan dalam proyek pengembangan sistem.

2.3.7

Pendekatan Object-Oriented Menurut Satzinger, Jackson, & Burd (2005, p60) pendekatan object-oriented

terhadap pengembangan sistem adalah melihat sebuah sistem informasi sebagai suatu serangkaian interaksi objek yang bekerja sama untuk menyelesaikan suatu tugas tertentu. Secara konsep, tidak ada proses atau program yang terpisah, tidak ada entitas data atau file yang terpisah. Sebuah sistem dalam suatu operasi berisikan objek-objek. Sebuah objek merupakan sesuatu dalam sistem komputer yang memiliki kemampuan untuk merespon sebuah pesan. Pendekatan object-oriented memandang sebuah sistem informasi sebagai sekumpulan objek yang saling berinteraksi. Object-Oriented Analysis (OOA) menentukan tipe-tipe objek yang diperlukan oleh user untuk bekerja dengan dan menunjukkan interaksi user yang diperlukan untuk menyelesaikan suatu pekerjaan. Object-Oriented Design (OOD) menentukan tipe tambahan dari objek yang biasanya digunakan untuk berkomunikasi dengan orang-orang dan perangkat dalam suatu sistem, menujukkan bagaimana objek saling berinteraksi dalam menyelesaikan suatu pekerjaan, dan memperjelas asti dari setiap tipe objek sehingga dapat digunakan dengan bahasa atau lingkungan yang spesifik. Object-Oriented Programming (OOP) berisikan bagaimana menuliskan suatu pernyataan dalam bahasa pemrograman untuk menentukan apa yang dilakukan oleh setiap tipe objek.

42 2.3.8

Keuntungan dari Pengembangan Object-Oriented Menurut Satzinger, Jackson, & Burd (2005, p61) dua alasan utama mengapa

object-oriented digunakan untuk pengembangan sistem : 1. Objek bersifat lebih alami Kealamian dari pendekatan object-oriented menunjuk ke arah fakta yang biasanya dipikirkan oleh seseorang mengenai dunia mereka dengan sudut pandang objek, jadi ketika orang-orang bebicara mengenai pekerjaan dan mendiskusikan kebutuhan sistem, seringkali mereka cenderung menentukan class dari objek yang terkait. Jadi, pendekatan object-oriented cocok dengan cara tipikal manusia melihat dunia mereka. OOA, OOD, dan OOP semuanya berkaitan dengan memodelkan class dari objek, jadi forkusnya tertap pada objek sepanjang proses pengembangannya. 2. Class dari Objek dapat digunakan lagi Selain itu, kemampuan untuk menggunakan lagi class dan objek merupakan keuntungan dari pengembangan object-oriented. Reuse atau penggunaan ulang berarti class dan objek dapat diciptakan sekali dan digunakan berulang kai. Ketika pengembang telah menentukan sebuah class, misalnya class pelanggan, class tersebut dapat digunakan lagi di banyak sistem lain yang juga menggunakan objek pelanggan. Jika sistem baru memiliki jenis khusus dari pelanggan, class pelanggan yang sekarang juga dapat digunakan untuk class baru sebagai subclassnya dengan mewarisi semua sifat pelangga dan kemudian menambahkan karakteristikkarakteristik yang baru. Class dapat digunakan lagi pada situasi ini pada saat di analisis, desain, atau saat pemrograman. Saat melakukan pemrograman, developer tidak perlu melihat sumber code dari class yang digunakanlagi, karena sifat pewarisan yang ada.

43 2.3.9

Konsep Object-Oriented Menurut Satzinger, Jackson, & Burd (2005, p61-62) sebuah objek dalam sistem

komputer seperti objek pada dunia nyata, yaitu sesuatu yang memiliki atribut dan behavior. Sebush sistem komputer dapat memiliki beberapa jenis objek, seperti objek user interface yang membuat user interface dan objek sistem yang fokus kepada tugas di lingkungannya. Atribut merupakan karakteristik dari objek yang memiliki nilai tertentu. Method merupakan behavior atau operasi yang mendeskripsikan apa yang dapat dikerjakan oleh suatu objek.

2.3.10 Class dan Objek Menurut Satzinger, Jackson, & Burd (2005, p63) class merupakan sebuah pengelompokkan di mana semua objek yang sama tergabung di dalamnya. Dalam pemprograman komputer dan objek, objek dapat merupakan instansi dari sebuah class. Ketika objek dibuat untuk class, dapat dikatakan bahwa class terinisiasi. Objek-objek saling berinteraksi satu sama lain, menanyakan objek lain untuk meminta atau mengeluarkan satu dari sekian banyak method yang dimilikinya. Dengan kata lain, objek user interface seperti form dengan tombol dan text box dapat megirimkan pesan dengan menanyakan class untuk membuat instansi baru dari dirinya sendiri. Instansi baru dari pesanan dapat mengirim pesan kepada pelanggan, misalnya Susan, menginformasukan bahwa pelanggan tersebut membuat order baru.

2.3.11 Asosiasi dan Multiplicity Menurut Satzinger, Jackson, & Burd (2005, p66-67) objek-objek saling berinteraksi dengan mengirimkan pesan, tetapi harus ada asosiasi (hubungan) di

44 antaranya. Asosiasi objek secara konsep sama dengan relasi dalam pemodelan database, kecuali setiap objek bertanggung jawab untuk mengelola hubungannya dengan objek lain. Asosiasinya dapat satu ke satu, misalnya ketika satu pesanan terhubung ke satu pelanggan, dan beberapa yang lain dapat satu ke banyak, misalnya ketika seorang pelanggan membuat banyak pesanan. UML yang berhubungan dengan nilai/angka yang menunjukkan asosasi ini disebut multicpicity dari sebuah asosiasi.

Sumber: Satzinger, Jackson, dan Burd (2005, p66) Gambar 2.6 Contoh Asosiasi Encapsulation berarti, objek memiliki atribut dan method yang digabungkan ke dalam suatu unit. Mengkombinasikan atribut dan method berarti struktur internal dari objek terhadap pesan tidak perlu diketahui, tetapi hanya perlu diketahui apa yang objek tersebut dapat lakukan untuk pengembangnya. Encapsulation menyembunyikan struktur internal dari objek, dan menjaganya dari korupsi. Inilah yang dimaksud konsep information hiding dari pendekatan object-oriented. Suatu class dapat memliki karakteristik dari suatu class lain dan mengkhususkannya (extend), konsep ini disebut inheritance. Misalnya terdapat suatu objek person (orang). Objek person dapat memiliki atribut nama dan alamat. Class Customer (pelanggan) merupakan jenis khusus dari person dengan atribut tambahan untuk shipping address (alamat pengiriman) dan informasi credit-card. Objek SalesClerk juga merupakan person, yang dapat didefinisikan dengan meng-extend class person, dan menambahkan atribut jabaran dan

45 gaji. Pada kasus ini, class person merupakan superclass, dan baik class pelanggan maupun SalesClerk merupakan subclass.

Sumber: Satzinger, Jackson, dan Burd (2005, p66) Gambar 2.7 Contoh Multiplicity Hasil dari meng-extend suatu class umum (class person) ke class yang lebih spesifik (class Customer dan SalesClerk) disebut dengan generalisasi/hirarki spesialisasi, disebut juga hirarki inheritance (pewarisan). Atribut bukan satu-satunya karakteristik yang diwariskan dari superclass. Subclass juga mewarisi method dan hubungan asosiasi. Konsep yag berhubungan dengan hirarki generalisasi/spesiaisasi dari method adalah polymorphism yang berarti “banyak form”. Dalam pendekatan object oriented, polymorphism menunjuk ke konsep bahwa objek yang berbeda dapa merespon pesan yang sama dengan caranya masing-masing. Misalnya, sebuah dialog box, sebuah koneksi jaringan, dan sebuah dokumen dapat menerima pesan untuk close. Setiap objek mengetahui bagaimana menjalankan close dan menjalankannya dengan caranya masingmasing ketika pesan close diberikan.

2.3.12 Pendokumentasian dengan Activity Diagram Menurut Satzinger, Jackson, & Burd (2005, p144-145) mengamati cara berjalan proses bisnis akan membantu dalam pemahaman fungsi bisnis. Ketika informasi proses

46 bisnis telah dikumpukan, misalnya dengan mewawancara user dan mengamati proses, hasilnya perlu didokumentasikan. Salah satu cara yang efektif untuk menangkap informasi ini adalah dengan menggunakan diagram. Diagram diperlukan untuk menggambarkan aliran kerja yang berjalan sekarang. Sebuah workflow atau aliran kerja merupakan langkah dari tahapan proses yang menangani suatu transaksi bisnis atau permintaan pelanggan. Workflow dapat simple atau kompleks. Tidak ada metode tertentu yang harus standar digunakan untuk memodelkan workflow. Metodologi tertentu yang umumnya digunakan termasuk flowchart dan activity diagram. Banyak analis menggunakan jenis diagram workflow yang disebut activity diagram. Activity diagram merupakan sebuah diagram yang menggambarkan aktivitas dari beragam user atau sistem, siapa yang melakukan aktivitas, dan aliran urutan dari aktivitas.

Sumber: Satzinger, Jackson, & Burd (2005, p145) Gambar 2.8 Contoh Activity Diagram Simbol oval mewakilkan aktivitas individu pada workflow. Panah penghubung menunjukkan urutan dari aktivitas. Lingkaran hitam digunakan untuk menandakan milai dan berakhirnya workflow. Diamond meupakan titik keputusan dimana aliran proses

47 akan mengikuti satu atau langkah lain dari pilihan yang ada. Garis tebal merupakan synchronizarion bar, yang bisa memisahkan langkah kebeberapa langkah atau mengombinasikan ulang beberapa langkah yang ada. Swimlane mewakilkan agen yang menjalankan akivitas. Pada workflow, umunya memiliki beberapa agen berbeda (berupa orang tertentu) yang menjalankan langkah yang berbeda dari proses workflow. Simbol swimlane memisahkan aktivitas workflow ke group, menunjukkan agen mana yang menjalankan aktivitas tersebut.

Sumber: Satzinger, Jackson, & Burd (2005, 145) Gambar 2.9 Simbol pada Activity Diagram

2.3.13 Events Menurut Satzinger, Jackson, & Burd (2005, p167) sebuah event (kejadian) terjadi pada satu waktu dan tempat yang spesifik, dapat digambarkan, dan harus diingat oleh

48 sistem. Event menggerakkan atau memicu semua proses yang dilakukan sistem, jadi mendaftar event dan menganalisa event diperlukan ketika kebutuhan sistem harus ditentukan dengan menentukan use case. Menurut Satzinger, Jackson, & Burd (2005, p173-174) salah satu teknik yang digunakan untuk menentukan event mana yang diaplikasikan untuk mengontrol sistem adalah asumsi bahwa teknologi sempurna. Perfect technology assumption menyatakan bahwa event harus dimasukkan saat pendefinisian kebutuhan hanya jika sistem dibutuhkan untuk merespon di dalam kondisi yang sempurna, misalnya perlengkapan tidak pernah rusak, kapasitas penyimpanan data tidak terbatas, dan dengan orang yang mengoperasikan sistem sangat jujus dan tidak pernah membuat kesalahan. Dengan perfect technology assumption, analisis dapat mengeliminasi event misalnya seperti back up database, dan sebagainya. Saat mengembangkan daftar event, analisis juga harus mencatat setiap informasi tambahan tentang suatu event. Menurut Satzinger, Jackson, & Burd (2005, p175) event meyebabkan sistem harus melakukan sesuatu. Trigger merupakan signal yang memberitahu sistem bahwa event tertentu telah terjadi. Untuk external event, trigger nya adalah kedatangan data yang harus diproses oleh sistem. Misalnya, ketika customer melakukan pemesanan, detail pesanan baru disimpan sebagai input. Source dari data juga penting untuk diketahui. Pada kasus pemesanan, source dari pesanan baru adalah customer – seorang external agent. Untuk temporal event, trigger nya adalah titik waktu tertentu. Misalnya, akhir setiap hari, sistem mengetahui bahwa itu adalah waktu untuk memproduksi suatu laporan ringkasan transaksi yang telah dilakukan. Use case merupakan apa yang dilakukan sistem ketika suatu event terjadi (reaksi atas event). Ketika customer melakukan pemesanan, sistem digunakan untuk mengeluarkan sebuah use case misanya

49 “create a new order”. Ketika sudah waktunya meproduksi laporan ringkasa transaksi, sistem digunakan untuk mengeluarkan use case yaitu “produce transaction summary”. Response merupakan output dari sistem. Saat sistem memproduksi laporan ringkasan transaksi, laporan tersebut merupakan outputnya. Satu use case dapat menghasulkan beberapa respon. Misalnya, ketika sistem membuat pesanan baru, sebuah kondirasi pesanan diberikan ke customer, detail pesanan diberikan ke pengiriman, dan transaksi tersebut diberikan ke bank. Destination merupakan tempat dimana tanggapan/respon tertentu (output) dikirim, misalnya ke external agent. Kadang sebuah use case tidak men-generate response. Misalnya, customer ingin mengupdate informasi account, informasi disimpan di database, tetapi tidak ada output yang diproduksi lagi. Tabel 2.4 Contoh Event Table Event

Trigger

Source

Use Case

Customer wants to

Item

check item

inquiry

Customer

Look up item availability

availability

Response

Destination

Item availability

Customer

details

Sumber: Satzinger, Jackson, & Burd (2005, p175)

2.3.14 Domain Model Class Diagram Menurut Satzinger, Jackson, & Burd (2005, p183-184) pada pendekatan objectoriented, sesuatu yang perlu disimpan karena penting untuk sistem disebut problem domain class. Class-class ini dimodelkan dengan sebuah model class diagram. Domain model class diagram adalah sebuah UML diagram yang menunjukkan hal-hal yang penting dalam pekerjaan user: problem domain class, hubungan di antaranya dan atributatributnya. Notasi UML class diagram digunakan untuk domain model class diagram

50 dan design class diagram. Sebuah kotak mewakili class, dan garis yang menghubungkan antara kotak menunjukkan hubungan di antara class-class. Simbol class adalah kotak dengan tiga bagian. Bagian teratas memuat nama class, bagian tengah memuat daftar atribut dari class, dan bagian bawah memuat daftar method yang penting untuk class. Method tidak ditunjukkan pada domain model class diagram. Sesungguhnya, simbol class seing situnjukkan dengan hanya dua bagian untuk mengindikasikan bahwa itu adalah sebuah domain model. Sebagai contoh adalah class customer dan order (pesanan). Terlihat bahwa setiap pelanggan dapat meletakkan banyak order, dan setiap order diletakkan oleh satu pelanggan. Model dari contoh menunjukkan bahwa customer dapat meletakkan minimum nol dan maksimum banyak order. Dibaca dari arah sebaliknya, dikatakan bahwa order diletakkan oleh sekurang-kurangnya satu customer dan hanya satu customer. Batasan ini merefeleksikan aturan bisnis yang telah ditentukn user atau manajemen. Analis tidak menentukan batasan ini, tetapi user atau manajemenlah yang menentukannya.

Sumber: Satzinger, Jackson, & Burd (2005, p186) Gambar 2.10 Contoh Pemakaian Simbol Multiplicity

Menurut Satzinger, Jackson, & Burd (2005, p186) jenis-jenis multiplicity : 0..1

: zero or one

1

: one and only one

51 1..1

: one and only one alternate

0..*

: zero or mor

*

: zero or more alternate

1..*

: one or more

2.3.15 Hirarki Pada Notasi Class Diagram Menurut Satzinger, Jackson, & Burd (2005, p189-191) terdapat dua cara tambahan yang yang distrukturisasi dari pemahaman terghadap domain class di dunia nyata yaitu hirarki generalisasi / spesialisasi dan hirarki whole-part. 1. Notasi generalisasi / spesialisasi Hirarki generalisasi / spesialisasi didasarkan pada ide bahwa seseorang mengklasifikasikan sesuatu dengan persamaan dan perbedaannya. Generalisasi merupakan sebuah penilaian yang mengelompokkan jenis yang sama dari suatu hal tersebut; misalnya banyak jenis dari motor vehicle (kendaraan bermotor) – car (mobil), truck (truk), tractors (traktor), dan sebagainya. Semua motor vehicles memiliki karakteristik umum, jadi motor vehicle merupakan class umum. Spesialisasi adalah penilaian bahwa mengelompokkan berbagai jenis benda – misalnya, jenis special dari car adalah sport car, sedan, dan sport utility vehicle. Tipe car ini sama dalam beberapa hal, dan juga berbeda di lain hal. Jadi, sport car merupakan jenis special dari car.

52

Sumber: Satzinger, Jackson, & Burd (2005, p190) Gambar 2.11 Contoh Hirarki Generalisasi/Spesialisasi Hirarki generalisasi/spesialisasi digunakan untuk membuat struktur atau memberikan benda-benda ini dari yang lebih umum ke yang lebih spesial. Setiap class pada hirarki tersebut mungkin memiliki class yang lebih umum di atasnya, disebut superclass. Pada saat yang sama, class mungkin memiliki class yang lebih spesial di bawahnya, yang disebut subclass. Notasi UML class diagram menggambarkan superclass dan subclass dengan segitiga kecil pada garis yang menunjuk ke superclass. Inheritance (pewarisan) memungkinkan subclass untuk berbagi karakteristik dengan superclass nya. Subclass mewarisi karakteristik-karakteristik. Pada pendekatan object-oriented, inheritance merupakan konsep kunci yang mungkin karena adanya hirarki generalisasi / spesialisasi ini. Seringkali hirarki ini menunjuk pada hirarki inheritance. 2. Notasi hirarki whole-part Cara lain seseorang untuk menstrukturisasi informasinya adalah dengan menentukannya berdasarkan bagian-bagiannya. Misalnya mempelajari sistem komputer mungkin termasuk mengenali komputer yang merupakan kumpulan part –

53 processor (prosesor), main memory (memori utama), keyboard, disk storage, dan monitor. Keyboard bukan merupakan jenis khusu dari komputer, tetapi merupakan bagian dari komputer. Hirarki whole-part menangkap hubungan bahwa orang-orang mengidentifikasi hubungan antara objek dengan komponennya. Terdapat dua jenis dari hirarki whole-part. Agregasi digunakan untuk menggambarkan hubungan whole-part antara aggregate (whole) dan komponennya (part) di mana part dapat berdiri terpisah.

Sumber: Satzinger, Jackson, & Burd (2005, p192) Gambar 2.12 Contoh Hirarki Whole-Part Jenis kedua dari hirarki whole-part adalah komposisi. Komposisi digunakan untuk menggambarkan hubungan whole-part yang lebih kuat, dimana komponen (part) nya, ketika dihubungkan, tidak lagi dapat berdiri terpisah. Simbol diamond digunakan untuk menunjukkan komposisi. Hirarki whole-part, baik agregasi dan komposisi memungkinkan analis untuk mengeskpresikan perbedaan yang lebih halus antara hubungan antar class.

54 2.3.16 CRUD Matrix Menurut Satzinger, Jackson, & Burd (2005, p199) terdapat sebuah matrix yang dapat dibuat untuk menekankan kebutuhan akses. Salah satu pendekatan adalah dengan mendata use case dan domain class pada sebuah ide case domain class matris. Matrix ini menunjukkan use case mana yang dapat mengakses setiap domain class. Informasi ini diperlukan ketika mendesain interaksi objek untuk setiap usecase. Membuat matrix untuk merangkum informasi ini akan sangat berguna. Huruf C berarti use case membuat data baru, R berarti use case membaca data, U berari use case mengupdate data, dan D berarti use case dapat menghapus data. Akromin CRUD (Create, Read, Update, Delete) sering digunakan untuk menggambarkan jenis matrix ini. Tabel 2.5 Contoh CRUD Matrix Use Cases

Domain Classes Customer

Inventory Item

Look up item

Order

R

availability Create new order

CRU

RU

C

Update order

RU

RU

RUD

Sumber: Satzinger, Jackson, & Burd (2005, p200)

2.3.17 Definisi Detail Kebutuhan Object-Oriented Menurut Satzinger, Jackson, & Burd (2005, p212) untuk dapat menangkap kebutuhan sistem, analis menggunakan sekumpulan model yang didasarkan pada use case dengan pendekatan object-oriented. Empat model use case diagram, use case description, activity diagram, dan system sequence diagram digunakan untuk menggambarkan use case sistem dari berbagai sudut pandang. Pendekatan untuk

55 menentukan kebutuhan sistem dengan cara ini disebut dengan “use case driven”. Pendekatan dasarnya adalah utnuk membicarakan use case, satu demi satu, dan menjabarkan kebutuhan secara lebih detail. Model lainnya adalah statechart diagram. Statechart diagram bukan merupakan “use case driven” melainkan “object driven”.

2.3.18 Use Case Diagram Menurut Satzinger, Jackson, & Burd (2005, p213) use case diagram membuat sebuah daftar isi dari aktivitas event bisnis yang harus didukung oleh sistem. Use case diagram digunakan untuk mengidentifikasi kegunaan (uses), atau menggunakan case dari sistem baru – dengan kata lain, untuk mengidentifikasikan bagaimana sistem akan digunakan dan actor mana yang akan terkait dengan use case tertentu. Setiap use case harus memuat penggambaran secara detail. Salah satu caraya adalah dengan menuliskan deskripsi dari setiap langkah yang dilakukan bersama baik oleh user dan sistem untuk menyelesaikan setiap use case. Menurut Satzinger, Jackson, & Burd (2005, p214-215) use case disimbolkan dengan sebuah oval dengan nama use case di dalamya. Garis yang menghubungkan antara actor dan use case menandakan bahwa actor mana yang akan menangani use case tertentu. Walaupun tangan bukan merupakan bagian dari standardisasi notasi UML, actor pada diagram ini digambarkan dengan tangan untuk mengingatkan bahwa actor ini harus memiliki akses langsung ke sistem.

56

Sumber: Satzinger, Jackson, & Burd (2005, p215) Gambar 2.13 Contoh Use Case Menurut Satzinger, Jackson, & Burd (2005, p220-225) pengembangan sistem membutuhkan analis untuk lebih detail lagi dalam setiap level deskripsi diagram. Karena itu dibuat sebuah use case description. Use case description ditulis pada tiga tingkat detail brief description, intermediate description, dan fully developed description. 1. Sebuah brief description dapat digunakan untuk setiap use case secara simpel, khususnya ketika sistem yang akan dibangun kecil, dan aplikasinya mudah dimengerti. Tabel 2.6 Create new order description When the customer calls to order, the order clerk and system verify customer information, create new order, add items to the order, verify payment, create the order transaction, and finalize the order. Sumber: Satzinger, Jackson, & Burd (2005, p221) 2. Intermediate Description Intermediate-level use case description memperluas brief description untuk memuat aliran internal aktivitas yang digambarkan untuk use case. Jika ada beberapa scenario, masing-masing aliran aktivitas harus digambarkan. Kondisi perkecualian

57 dapat didokumentasikan jika diperlukan. Setiap langkah diidentifikasikan dengan angka untuk membuatnya lebih mudah untuk dibaca. Tabel 2.7 Contoh Intermediate Description Flow of activities for scenario of Order Clerk creates telephone order Main Flow : 1. Customer calls and gets order clerk. 2. Order clerk verifies customer information. If a new customer, invoke Maintain customer account information use case to add a new customer. 3. Clerk initiates the creation of a new order. 4. etc Exception Conditions : 1. if an item is not in stock, then customer can a. choose not to purchase item, or b. request item be added as a back-ordered item. 2. etc Sumber: Satzinger, Jackson, & Burd (2005, p221) 3. Fully Developed Description Fully developed description merupakan metode yang paling resmi untuk mendokumentasikan sebuah use case. Walaupun perlu lebih banyak waktu untuk menentukan semua komponen pada tingkat ini, ini merupakan metode yang lebih banyak digunakan untuk mendeskripsikan setiap aktivitas dari use case. Kesulitan dari pengembang software adalah memerlukan pemahaman yang dalam dari kebutuhan user. Tetapi jika sebuah fully developed use case description dibuat, kemungkinan akan meningkat bahwa anals telah mengerti proses bisnis dan bagaimana sistem harus mendukung proses tersebut. Ruang pertama dan kedua digunakan untuk mengidentifikasi use case dan scenario yang terjadi dalam use case. Pada proyek yang lebih formal, identifikator unik

dapat

ditambahkan,

misalnya

pengembang

sistem.

Ruang

ketiga

mengidentifikasikan situasi yang memicu dimulasinya use case, dssebut trigger Trigger ini sama dengan trigger yang telah digambarkan pada event table.

58 Ruang keempat adalah brief description dari use case atau scenario. Ruang kelima mengidentifikasi actor. Ruang keenam mengidentifikasi use case lain dan bagaimana use case tersebut berkaitkan dengan use case yang digambarkan. Ruang stakeholders mengidentifikasi bagian yang bertanggung jawab, dan dapat juga yang akan terpengaruh akan hasil dari use case ini. Dua ruang selanjutnya memuat informasi kritis dari state sistem sebelum dan sesudah use case dijalankan, disebut preconditions dan postconitions. Preconditions menyatakan kondisi seperti apa yang harus ditemui sebelum sebuah use case dapat dimulai, atau informasi apa yang harus ada sebelum memulai use case. Precondition biasanya memuat hal-hal seperti objek apa yang harus ada di dalam sistem atau database, relasi khusus apa yang harus ada di antara objek, dan nilai spesifik apa yang harus diidentifikasi terlebih dahulu. Postcondition mengidentifikasikan apa yang harus selesai atau ada saat use case selesai dijalankan. Item yang digunakan untuk mendeskripsikan precondition harus dimasukkan pada pernyataan di postcondition. Dua ruang terakhir mendeskripsikan detail aliran aktivitas dari use case. Ruang terakhir memuat aktivitas alternative dan perkecualian. Tabel 2.8 Contoh Fully Developed Description Create new order Create new telephone order Customer telephones to purchase items from the catalog. When customer calls to order, the order clerk and system verify customer information, create a new order, add items to the order, verify payment, create new order transaction, and finalize the order. Telehone sales clerk Actors : Includes : Check item availability Related Use Cases : Sumber: Satzinger, Jackson, & Burd (2005, p223) Use Case Name : Scenario : Triggering Event : Brief Description :

59

Tabel 2.9 Contoh Fully Developed Description (lanjutan) Stakeholders :

Preconditions :

Postconditions :

Flow of Events :

Sales department : to provide primary definition Shipping department : to verify that information content is adequate for fulfillment Marketing department : to collect customer statistics for studies of buying patterns Customer must exist. Catalog, Products, and Inventory items must exist for requested items. Order and order line items must be created. Order transation must be created for the order payment. Inventory items must have the quantity on hand updated. The order must be related (associated) to a customer. Actor System 1. Sales clerk answer telephone and connects to a customer. 2. Clerk verifies customer information 3. Clerk initiates the creation of a new order. 4. etc 3.1 Create new order 2.1 If customer does not exist, then ….. etc

Exception Conditions Sumber: Satzinger, Jackson, & Burd (2005, p223)

2.3.19 System Sequence Diagram Menurut Satzinger, Jackson, & Burd (2005, p226) System sequence diagrams (SSDs) digunakan untuk menentukan input dan output dan urutan perintah dari input dan output. Dalam sequence diagram, aliran informasi yang masuk dan keluar disebut messages. Pada pendekatan object-oriented, aliran informasi dijalankan dengan mengirimkan messages dari dan ke actors, atau di antara external objects. Jadi, sebuah dokumen SSD digunakan untuk mmendeskripsikan aliran informasi ke dan dari sistem.

60 SSD merupakan jenis interaction diagram. Pada use case diagram, digambarkan apa yang dilakukan actor yang berhubungan dengan sistem, tetapi dalm SSD digambarkan bagaimana actor tersebut berinteraksi dengan sistem dengan memasukkan input data dan menerima output data. Idenya adalah sama pada kedua diagram ini, tapi memiliki level detail yang berbeda. Kotak yang bertuliskan :System merupakan sebuah objek yang mewakilkan seluruh sistem yang terotomatsasi. SSD menggunakan notasi objek. Notasi objek mengindikasikan bahwa bentuk kotak mengarah ke sebuah objek individu dan bukan seluruh class dari objek yang sama tersebut. Notasinya adalah sebuah kotak dengan nama objek yang digarisbawahi. Tanda titik dua sebelum nama yang bergaris bawah seringkali digunakan tapi bisa tidak digunakan. Pada SSD, objek yang terkait digambarkan untuk mewakili keseluruhan sistem. Di bawah actor dan :System terdapat garis putus-putus vertical yang disebut lifeline. Sebuah lifeline, atau object lifeline, menunjukkan bahwa baik objek maupun actor sepanjang rentang waktu SSD. Tanda panah di antara lifeline menunjukkan messages yang dikirim atau diterima oleh actor atau sistem. Setiap panal memiiki sumber dan sebuah tujuan. Sumber dari message merupakan actor atau object yang mengirim message tersebut. Actor atau objek tujuan dari message diindikasikan dengan lifeline yang disentuh oleh kepala panah. Kegunaan dari lifeline adalah untuk mengindikasikan tahapan urutan messages yang dikirim dan diterima oleh actor dan object. Urutan ini dibaca dari atas ke bawah pada diagram ini. Menurut Satzinger, Jackson, & Burd (2005, p229) sebuah message dituliskan baik tujuan message maupun input data yang dimasukkan. Sintaks dari meesage memiliki beberapa pilihan; cara yang paling simpel terlihat pda gambar. Sebuah message dapat diartikan sebagai sebuah aksi yang meminta ke objek yang dituju, seperti perintah. Bentuk sintaks ini digambarkan dengan panah penuh. Balasan dari message memiliki

61 format dan arti yang sedikit berbeda. Panahnya merupakan panah putus-putus. Sebah panah putus-putus digunakan untuk mengindikasikan sebuah respon atau jawaban, dan secara segera message yang mendahuluinya. Format dari label nya juga berbeda. Karena merupakan sebuah respon, hanya dituliskan data yang dikembalikan. Misalnya list dari informasi yang dikembalikan, seperti deskripsi, harga, dan jumlah item. Versi penyingkatan dari informasi juga memuaskan. Pada kasus ini informasi yang dikembalikan bernama item information. Dokumentasi tambahannya diperlukan untuk menunjukkan detail informasi tersebut. Pada gambar, informasi tambahan ini ditunjukkan dengan sebuah note. Note dapat ditambahkan ke berbagai UML diagram untuk menambahkan penjelasan. Detail dari informasi juga dapat didokumentasikan dengan narasi pendukung atau direferensikan dengan atribut.

Sumber: Satzinger, Jackson, & Burd (2005, p229) Gambar 2.14 Contoh System Sequence Diagram Bagian 1 Seringkali message yang sama dikirim beberapa kali. Misalnya, ketika actor mengentri item ke order, message “add item” ke order dapat dilakukan berkali-kali. Pada gambar ditunjukkan notasi yang menunjukkan operasi yang berulang ini. Dengan sebuah kotak yang lebih kecil di dalamnya dideskripsikan tulisan untuk mengontrol behavior dari message. Kondisi “loop for all items” mengindikasikan bahwa message di

62 dalam kotak akan berulang berkali-kali atau berhubungan dengan banyaknya item yang akan dipesan.

Sumber: Satzinger, Jackson, & Burd (2005, p230) Gambar 2.15 Contoh System Sequence Diagram Bagian 2

2.3.20 Statechart Diagram Menurut Satzinger, Jackson, & Burd (2005, p237) statechart diagram, atau statechart, menggambarkan sekumpulan state dari setiap objek. Karena objek nyata ditiru didalam sistem komputer, seringkali kondisi status dari objek nyata tersebut merupakn bagian yang penting dari informasi yang dapat digunakan analis untuk membantu menentukan aturan bisnis yang harus diterapkan di sistem komputer. Misalnya, pesanan customer tidak akan komplit sebelum ada shipping (pengiriman). Sebuah state pada statechart untuk objek sama dengan kondisi status dari objek. Statechart dapat digunakan untuk class yang memiliki behavior yang kompleks atau kondisi status yang perlu dideteksi. Bagaimanapun juga, tidak semua class memerlukan statechart. Jika suatu objek tidak memiliki proses status yang akan mengontrol proses, suatu statechart mungkin tidak diperlukan. Misalnya, class order mungkin membutuhkan

statechart,

tetapi

class

order

Transaction

kemungkinan

tidak

63 memerlukannya. Sebuah order transaction dibuat ketiak pembayaran telah dilakukan dan hanya itu saja; tidak ada kondisi yang perlu dideteksi lagi.Statechart diagram dibentuk dari bentuk oval yang mewakili status dari objek dan panah yang mewakili transisinya. Pada gambar ditunjukkan statechart simpel untuk printer. Tanda mulainya statechart dilambangkan dengan titik hitam, disebut pseudostate. Oval pertamanya merupakan state (status) dari printer. Dalam kasus ini, printer mulai pada state off. State digambarkan dengan kotak dengan ujung siku dengan nama state di dalamnya. Menurut Satzinger, Jackson, & Burd (2005, p238) sebuah state dari objek adalah kondisi yang terjadi pada saat hidupnya dan memenuhi kriteria tertentu, melakukan aksi tertentu, atau menunggu event tertentu. Setiap state memiliki nama yang unik. State merupakan kondisi semipermanen dari objek. State dapat dideskripsikan sebagai kondisi semipermanen karena external event dapat menginterupsinya. Sebuah objek tetap pada state sampai suatu event menyebabkannya berpindah ke state lainnya. Penamaan kondisi status membantu mengidentifikasi state yang valid. Untuk mengidentifikasi state, dapat dipikirkan kondisi yang mungkin diperlukan untuk dilaporkan kepihak manajemen atau customer. Panah yang meninggalkan state disebut transition (transisi). Transition merupakan sebuah perpindahan sebuah objek dari state satu ke state lainnya. Transition diperhatikan memilik durasi yang pendek, dibandingkan dengan statem dan tidak dapat diinterupsi. Guard-condition menunjukkan kondisi yang harus benar saat transisi berjalan. Transition-name merupakan nama dari message event yang memicu transisi dan mengakibatkan objek meninggakan state sebelumnya. Action-expression merupakan expression prosedural yang mengeksekusi saat transition berjalan. Dengan kata lain, mendeskripsikan aksi yang dijalanakan. Salah satu dari ketiga komponen ini transitionname, guard-condition, atau action-expression dapat saja kosong.

64

Sumber: Satzinger, Jackson, & Burd (2005, p237) Gambar 2.16 Contoh Statechart Diagram

2.3.21 Deployment Environment Menurut Satzinger, Jackson, & Burd (2005, p264) sebagian besar perusahaan telah memiliki sistem pendukung yang kompleks untuk beragam sistem informasi. Analis harus bisa menentukan apakah arsitektur tersebut dapat mendukung sistem baru dan perubahan yang diperlukan. Analis harus dapat mengadaptasikan sistem dengan arsitektur yang ada saat ini, membungkusnya dengan sistem yang ada saat ini, dan mengantisipasi sistem di masa mendatang. Menurut Satzinger, Jackson, & Burd (2005, p270-271) deployment environment memuat mengenai hardware, software sistem, dan lingkungan jaringan dimana sistem akan dioperasikan. Single-computer architecture menggunakan sebuah sistem komputer tunggal dan berhubungan dengan sebuah perangkat tertentu yang merupakan sebuah aplikasi yang berinteraksi denga user melalui perangkat yang memiliki fungsi terbatas yang langsung berhubungan dengan komputer. Kapasitas komputer tunggal tidak dapat diterapkan untuk sistem informasi yang besar.

65 2.3.22 Jaringan Komputer Menurut Satzinger, Jackson, & Burd (2005, p272) sebuah jaringan komputer merupakan seperangkat jalur transmisi, hardware yang terspesialisasi, dan protocol komunikasi yang memungkinkan komunikasi di antara berbagai user dan sistem komputer berbeda. Sebuah LAN (Local Area Network) biasanya berjarak sekitar satu kilometer dan dapat menghubungkan user di dalam suatu bangunan atau lantai tertentu. WAN (Wide Area Networks) dapat menggambarkan sebuah jaringan lebih dari satu kilometer, bahkan yang lebih luas, seperti antar kota, negara, benua, dan seluruh dunia.

2.3.23 Model Design Objet-Oriented Menurut Satzinger, Jackson, & Burd (2005, p300) pada gambar berikut ditunjukkan mana model requirement yang akan menentukan desain model tertentu. Pada sisi sebelah kiri – use case diagram, use case description dan activity diagram, domain model class diagram, sistem sequence diagram dan statechart diagram semua itu telah dikembangkan pada saat pemodelan requirement. Pada sisi sebelah kanan design class diagram, interaction diagram, statechart diagram, dan package diagram akan dikembangkan pada saat pemodelan desain sistem. Informasi desain memiliki dua sumber domain model class diagram dan interaction diagram. Pada kenyataanya, dapat diperhatikan bahwa panah antara design class diagram dan interaction diagram merupakan dua arah. Hal ini mengindikasikan bahwa sebagin informasi pada design class diagram diperlukan untuk melengkapi interaction diagram, dan sebaliknya.

66

Sumber : Satzinger, Jackson, & Burd (2005, p300) Gambar 2.17 Model Requirement

2.3.24 Design Class Diagram Menurut Satzinger, Jackson, & Burd (2005, p303-304) terdapat empat jenis class standar: 1. Entity class, yang datang dari sebuah domain model. Objek ini pasif, menunggu sebuah event bisnis untuk terjadi sebelum objek trsebut melakukan sesuatu. 2. Boundary class, class yang didesign untuk hidup pada boundary otomatisasi sistem. Pada sistem desktop, class ini bisanya merupakan window dan class lain yang terhubung dengan user interface.

67 3. Control class, yaitu class yang menjadi penghubung antara boundary class dan entity class. Bertanggung jawab untuk menangkap pesan dari class objek dan mengirimkannya ke class entity objek yang tepat. Berperan sebagai controller antara view layer dan domain layer. 4. Data access class, digunakan untuk mendapatkan kembali data dari dan ke database, termasuk SQL (Structured Query Language) Statements ke method entity class, sebuah layer pemisah antara class untuk mengakses database yang digunakan pada desain sistem.

Sumber: Satzinger, Jackson, & Burd (2005, p304) Gambar 2.18 Class Pada Design Class Diagram

2.3.25 Detail System Sequence Diagram Menurut Satzinger, Jackson, & Burd (2005, p314) sebuah system sequence diagram – SSD, dikembangkan sebagai bagian pada saat tahap requirement, tetapi hanya menunjukkan message yang ditujukan ke sistem. Pada tahap desain, harus ditetapkan objek mana yang akan menerima message ini. Untuk menyederhanakan proses ini, desainer sistem biasanya membuat sebuah class baru yang akan melayani pengumpulan message yang dituju oleh message yang masuk, disebut sebagai use case controllers. Misalnya, pada use case Look up item availability, mungkin dibuat sebuah class controller yang dinamakan AvailabilityHandeler. Sebuah use case controller sungguh

68 merupakan class tiruan yang dibuat oleh seseorang yang mendesain sistem. Kadang class ini disebut artifacts, yang berarti sesuatu yang dibuat untuk tujuan tertentu hanya karena diperlukan. Terdapat beberapa cara untuk membuat use case controller. Sebuah use case controller dapat ditentukan untuk semua use case. Sekumpulan tanggung jawab diberikan untuk dapat dibawa oleh use case tersebut. Desain yang lebih baik menggunakan beberapa use case controller, masing-masing dengan beberapa tanggung jawabnya sendiri. Use case controller dan problem domain class untuk use case termasuk dalam sebuah design class diagram. Menurut Satzinger, Jackson, & Burd (2005, p315-316) Sebuah SSD menangkap interaksi antara sistem dan dunia luar yang diwakilkan oleh actor. Sistem itu sendiri akan diperlakukan sebagai sebuah objek tunggal yang dinamakan :System. Sebuah detail SSD akan menggunakan semua elemen yang sama dari SSD. Perbedaannya adalah, objek :System akan digantikan oleh semua objek internal dan message di dalam sistem. Dengan kata lain, pada SSD, sistem diperlakukan sebagai suatu kotak tertutup, dan pemrosesan internal tidak dapat dilihat. Tujuan dari desain ini adalah untuk membuka kotak terttutup itu dan menentukan proses internal yang harus terjadi di antara sistem yang terotomatisasi. Langkah pertama untuk mengembangkan SSD adalah menntukan objek lain apa saja yang diperlukan untuk menyelesaikan suatu use case tertentu. Berikutnya adalah menentukan use case controller, kemudian menambahkan objek lain yang akan berkaitan dengan use case. Langkah berikutnya adalah menentukan message apa yang harus dikirim, termasuk objek mana yang menjadi sumber dan tujuan dari sebuah message. Pada contoh yang disajikan, Objek Catalog merupakan hirarki paling atas dari informasi yang diperlukan. Jadi, :ActivityHandler akan memberikan message ke objek

69 :Catalog.

Objek

:Catalog

akan

mengirimkan

pesan

ke

:ProductItem

dan

:CatalogProduct untuk memperoleh description dan price. Bagaimanamun juga, :Catalog tidak memiliki navigation visibility yang langsung ke :InventoryItem, jadi message lain akan dikirikan ke :ProductItem untuk meminta bantuan memperoleh informasi quantity. Objek :ProductItem mengetahui bahwa :InventoryItem memiliki informasi quantity, sehingga mengirimkan pesan tersebut dan mengumpulkan informasi quantity. :Catalog mengumpulkan semua infromasi dan mengembalikannya ke :ActivityHandler, yang mengirimkannya kembali kepada Clerk.

Sumber: Satzinger, Jackson, & Burd (2005, p315) Gambar 2.19 Contoh Detail System Sequence Diagram Sebuah simbol baru disertakan pada diagram, yaitu sebuah kotak vertikal panjang yang terlihat pada objek :ActivityHandler dan :Catalog, disebut activation lifeline. Sebelumnya, lifreline ditunjukkan dengan sebuah garis vertikal putus-putus. Sebuah objek dikatakan aktif apabila sedang mengeksekusi sebuah method dan akan tidak aktif (inactive) apabila mertide tersebut berhenti dilaksanakan. Di dalam sequence diagram, kotak menunjuk kepada objek dan bukan class. Nama di dalam kotak diberikan garis bawah mengindikasikan objek. Kadang, penting

70 untuk memperhatikan objek secara spesifik. Identifikasi spesifik digunakan ketika sebuah referensi dari objek dibuuhkan pada bagian lain dari diagram. Misalnya, C:Catalog, aC merupakan identifikasi dari sebuah objek catalog. Saat objek diintansiasi, dan dikenali. Kemudian objek tersebut pergi ke database, untuk membaca dan mendapatkan kembali data dari database, yaitu dengan mengirimkan message ke :CatalogDA. Salah satu keuntungan mengembangkan sequence diagram dengan dua langkah adalah first cut akan fokus hanya ke objek domain, tidak ada masalah untuk perlu lebih meninjau kerumitan akses data. Communication diagram dan sequence diagram sama-sama merupakan interaction diagram, dan menangkap informasi yang sama. Model mana yang akan digunakan tergantung dari preferensi desainer.

2.3.26 Package Diagram Menurut Satzinger, Jackson, & Burd (2005, p339-342) design class diagram dapat dikembangkan untuk setiap layer. Pada view layer dan data access layer, beberapa class baru harus dispesifikasikan. Package diagram pada UML merupakan diagram tingkat lanjut yang memungkinkan desainer untuk menghubungkan setiap class ke kelompok tertentu. Pada contoh digambarkan view layer, domain layer, dan data access layer. Pada saat desainer perlu untu mendokumentasikan perbedaan atau pesamaan dari relasi objek pada layer yang berbeda ini, misalnya mengelompokkan berdasar distribusi proses dara, informasi ini dapat ditampilkan dengan menunjukkan setiap layer sebagai package yang terpisah. Notasi package adalah kotak yang memiliki tab. Nama package biasanya dituliskan pada tab, atau bila tidak ada detail dalam package, maka nama tab dapat dituliskan di dalam tab. Untuk mengembangkan package diagram ini, biaanya informasi diambil dari design class diagram dan interaction diagram untuk setiap use

71 case. Simbol lain yang digunakan adalah panah putus-putus yang mewakilkan dependency relationship. Ekor panah dihubungkan ke package yang dependent, dan kepala panah ke package yang independent. Sebuah cara pikir mengenai dependency relationship ini adalah, jika ada perubahan terhadap elemen tertentu (independent element), maka elemen lainnya (dependent element) akan juga mengalami perubahan. Dependency relationship dapat terjadi anatar package atau antara class dalam satu package. Misalnya, jika terjadi perubahan pada class Order, maka harus dievaluasi perubahan pada class OrderWindow. Ini tidak berlaku pada kondisi kebalikannya. Perubahan pada view layer biasanya tidak akan mempengaruhi domain layer. Menurut Satzinger, Jackson, & Burd (2005, p342) secara singkat, package diagram digunakan untuk menunjukkan relasi dan ketergantungan (dependency) antar komponen. Secara umum, package diagram digunakan untuk menghubungkan class atau komponen sistem lain seperti network nodes, untuk memisahkan sistem ke dalam beberapa subsistem dan untuk menunjukkan rangkaian di dalam package.

2.3.27 Deployment Diagram Menurut Mathiassen, Munk-Madsen, Nielsen, & Stage (2000, p209-210) arsitektur proses mengarahkan lebih dekat ke tingkat fisik sistem. Selain fokus terhadap distribusi dan eksekusi, proses dan objek, seorang analis sistem juga menentukan mengenai perangkat fisik apa dalam sistem yang akan dipertimbangkan. Perencanaan aktivitas proses ini menghasilkan sebuah deployment diagram yang mendeskripsikan ditribusi dan kolaborasi komponen-komponen yang berjalan di dalam sebuah sistem.