BAB 2 LANDASAN TEORI 2.1. Konsep Kualitas Menurut Wilton (1994,p2), kualitas adalah keseluruhan fitur dan sifat dari sebuah produk atau jasa yang bergantung pada kemampuannya untuk memuaskan suatu keadaan atau memenuhi kebutuhan. Menurut Evans et al (2001, p11-16) kualitas tidak mempunyai definisi yang pasti, dimana kualitas memiliki definisi yang berbeda jika dilihat sudut pandangan yang berbeda. Kualitas dapat dilihat dari beberapa patokan : a.
Ukuran pertimbangan (Judgmental Criteria), kualitas mencakup hal-hal yang mutlak dan dikenal diseluruh dunia, sebuah tanda dari ukuran yang tidak dapat berkompromi dan pencapaian yang tinggi.
b.
Ukuran dari segi produk (Product-Based Criteria), kualitas adalah sebuah fungsi dari sebuah variabel yang khusus dan terukur dan perbedaan dalam kualitas menggambarkan perbedaan dalam kuantitas dari beberapa perlengkapan produk, seperti jumlah jahitan per inci pada sebuah baju atau jumlah dari linkaran pada mesin. Tafsiran ini menyatakan bahwa semakin tinggi level atau jumlah dari sifat khas dari produk sejalan dengan tingginya level kualitas. Ini tidak berarti kualitas berhubungan dengan harga.
c.
Ukuran dari segi pemakai (User-Base Criteria), kualitas ditentukan atas apa yang diinginkan oleh pelanggan. Kualitas di definisikan sebagai kecocokan untuk tujuan yang ingin dicapai, atau seberapa baik produk menjalankan fungsi yang diinginkan.
8 d.
Ukuran dari segi nilai (Value-Base Criteria), kualitas produk adalah satu produk yang berguna seperti produk pesaing dan dijual pada harga yang rendah, atau yang menawarkan kegunaan yang lebih atau kepuasan pada harga yang cocok.
e.
Ukuran
berdasarkan
manufaktur
(Manufacturing-Based
Criteria),
kualitas
didefinisikan sebagai hasil yang diinginkan oleh insinyur dan praktisi manufaktur, atau kesesuaian terhadap spesifikasi. Spesifikasi adalah sasaran dan toleransi yang ditentukan oleh perancang dari produk dan jasa. Tujuan adalah nilai yang ideal untuk dicapai produksi, toleransi di ditetapkan karena tidak mungkin untuk selalu mencapai target dalam produksi. Contoh Toleransi, pada produksi pembuatan tiang penyangga dengan ukuran 0,236 ± 0,003 cm, maksudnya jika ukuran yang dihasilkan diantara 0,233 sampai 0,239 masih bisa termasuk produk yang berkualitas. Contoh lain dalam perusahaan Coca-cola, kualitas adalah bagaimana memproduksi produk yang dapat diandalkan oleh manusia pada saat kapan saja mereka menginginkannya, menurut Donal R. Keough, bekas presiden dan kepala petugas operasi. Kualitas dilihat dari pelanggan (Customer-Driven Quality), definisi kualitas distandarisasi pada tahun 1978 oleh American National Standards Institute (ANSI) dan the American Society for Quality (ASQ). Kelompok ini mendefinisikan kualitas sebagai keistimewaan secara total dan kekhasan dari sebuah produk atau jasa yang tahan akan kemampuannya untuk memenuhi kebutuhan yang diberikan. Pada akhir tahun 1980, banyak perusahaan mulai menggunakan definisi yang sederhana dan kuat definisi kualitas dari segi pelanggan, kualitas adalah memenuhi atau melebihi harapan pelanggan. Integrasi pandangan dalam kualitas dapat dilihat pada gambar 2.1.
9
Transcendent Quality and Product-Based Quality
Customer
User-Based Quality
Marketing Value-Based Quality Design
Manufacturing Distribution Information flow
ManufacturingBased Quality
Product flow
Gambar 2.1 Pandangan Kualitas dalam Siklus Produksi dan Distribusi
2.1.1. Jaminan Kualitas, Pengendalian Kualitas dan Peningkatan Kualitas (Quality Assurance, Quality Control, And Quality Improvement) Jaminan kualitas ( HEQC, 1994c: 61 ) (Brown, 2004, p173) dapat didefinisikan sebagai semua yang direncanakan dan aktifitas yang teratur untuk menyediakan kepercayaan yang cukup bahwa produk atau pelayanan akan memenuhi syarat yang diperlukan untuk kualitas. Menurut Evans et al (2001, p4) jaminan kualitas adalah tindakan-tindakan yang ditujukan untuk memberikan produk (barang dan jasa) kepada pelanggan dengan kualitas yang tepat. Menurut Wilton (1994, p3) jaminan kualitas adalah semua yang direncanakan dan langkah-langkah sistematis yang diperlukan untuk menjamin bahwa sebuah produk atau jasa akan memenuhi syarat-syarat kualitas.
10 Menurut Wilton (1994, p3) pengendalian kualitas adalah teknik-teknik atau aktivitas-aktivitas operasional yang digunakan untuk memenuhi persyaratan untuk kualitas. Pengendalian kualitas lebih berhubungan dengan proses dan teknik-teknik operasional untuk mencapai dan menyokong kriteria-kriteria kualitas yang direncanakan, dengan menggunakan timbal balik dari pemeriksaan pada berbagai macam tahap dalam proses. Jaminan kualitas lebih kearah penyediaan keyakinan kepada pelanggan luar atau pihak yang berhubungan bahwa produk dan jasa akan memenuhi standar dan memenuhi kebutuhan. Contoh pada sebuah perusahaan, pengendalian kualitas adalah sistem (secara mekanik atau manual) untuk membuat tanda pada produk-produk dengan label atau nomor pengenal. Jaminan kualitas adalah dokumentasi dari prosedur-prosedur untuk memastikan sistem bekerja dengan semestinya, dan tanggung-jawab ditempatkan dan dimengerti dengan benar, dan ada sebuah sistem untuk memeriksa apakah tipe dari pengenal sesuai dengan persyaratan pelanggan, dan sistem ditinjau dan diperiksa secara teratur untuk mempertahankan keefektipan sistem. Menurut Montgomery (2001, p6) peningkatan kualitas adalah pengurangan variasi dalam proses-proses dan produk. Di perusahaan jasa, masalah kualitas mungkin disebabkan oleh error atau kesalahan, perbaikan akan memerlukan usaha dan biaya, dengan meningkatkan proses pelayanan, penyia-nyiaan usaha dan biaya dapat dihindari.
2.1.2. Alat-Alat untuk Pengendalian Kualitas Menurut Okes et al (2001, p100-110) alat-alat yang dapat dipakai dalam pengendalian kualitas : 1. Pareto Chart, dipakai untuk menunjukkan tingkatan cacat dari yang terbesar sampai terkecil, contoh pareto chart dapat dilihat pada gambar 2.2.
11 2. Flowchart, gambaran dari urutan langkah-langkah dan pusat keputusan dalam proses, contoh dapat dilihat pada gambar 2.4.
Gambar 2.2 Pareto Chart Cause-and-Effect Diagram Material
Policies
H allw ay Lay out
M andatory D epartment Location
S ign Location
S ignage Limitations
C heck-in F orgets to P rov ide D irections C heck-in Training C row ded H allw ay s
Methods
Policies
Gambar 2.3 Cause and Effect Diagram 3. Cause and Effect Diagram, disebut juga diagram Ishikawa atau diagram fishbone, digunakan untuk menunjukkan penyebab-penyebab yang berhubungan dengan suatu masalah. Diagram ini digunakan untuk menunjukkan suatu cara
12 dalam mengatur apa yang mungkin menjadi penyebab kerusakan, contoh dapat dilihat pada gambar 2.3. 4. Check Sheet, dipakai untuk mengumpulkan informasi pada penyebab-penyebab utama, contoh dapat dilihat pada gambar 2.5. 5. Control Chart, dipakai untuk : (1) menunjukkan kapan suatu proses dipengaruhi oleh suatu sebab khusus, menyebabkan kondisi diluar kendali, dan (2) menunjukkan proses berjalan setiap waktunya (over time), contoh dapat dilihat pada gambar 2.6. 6. Histogram, menyediakan gambaran grafik dari frekuensi distribusi data, contoh dapat dilihat pada gambar 2.7. 7. Scatter diagram, untuk menunjukkan apakah ada hubungan/korelasi antara dua variabel, contoh dapat dilihat pada gambar 2.8.
13 Flowchart process Audit process
Correct problems
Yes
Problems ?
Collect data Analyze data No
In control?
Plot histogram Estimate process capability
Sort product
No
Capable?
Improve capability
Gambar 2.4 Flowchart Switch Assembly Op 236 Plastic footer Chart began July 12, 1995 Week 1 Burns Misrun Bad finish porosity flash color
Gambar 2.5 Check Sheet
Operator Totals
14
Upper control limit (UCL)
Central line (X)
Lower control limit (LCL)
Gambar 2.6 Control Chart
Gambar 2.7 Histogram
.
. . . . .
Kekuatan gunting
. ..
.
. . .
.
.
Suhu perawatan
Gambar 2.8 Scatter Diagraim
15 2.1.3. Failure Mode and Effect Analysis (FMEA) Menurut Bass (2000), Failure Mode and Effect Analysis (FMEA) adalah sebuah teknik tehnik untuk mendefinisikan, mengidentifikasi dan menghilangkan masalahmasalah yang potensial dalam sebuah sistem. FMEA adalah sebuah proses yang harus dilakukan sejalang dengan mulainya perancangan pertama sampai akhir dari suatu produk. Failure mode adalah sebuah fungsi dari suatu nomor dari bagian. Secara umum, setiap nomor bagian dari komponen pada sebuah sistem dianalisis untuk menentukan kemungkinan kegagalan yang mungkin terjadi ( buka, hubungan singkat, kegagalan mesin, dan sebagainya). Setiap bagian memiliki banyak kemungkinan kegagalan dan secara teori tidak ada batasan seberapa dalam kegagalan tersebut dapat berlanjut. Secara praktek, tidak ada titik pengembalian pengurangan dimana biaya yang ditambahkan melewati keuntungan yang didapatkan. Kita boleh menggabungkan beberapa kemungkinan kegagalan jika merekan memiliki effect yang sama, dan juga dapat dibedakan untuk pemecahan yang lebih baik di masa depan jika diperlukan. Permulaan FMEA harus mencakup semua komponen dari sistem yang akan diperbaiki atau diganti selama tahap pemeliharaan. Komponen lain dan kegagalan lain harus ditambahkan ketika kegagalan terjadi. Pengaruh dari kegagalan bagian bergantung pada fungsi dari bagian tersebut dalam sistem. Dua katup mungkin memiliki nomor bagian yang sama tetapi pengaruh dari kegagalan akan bergantung pada katup mengendalikan apa. Oleh karena itu, sangat penting untuk setiap komponen dalam sistem ditempatkan pada simbol yang unik dan atau perancangan yang sepenuhnya bebas dari nomor bagian. Skematis sistem adalah dokumen kunci yang digunakan untuk menentukan pengaruh kegagalan dari suatu
16 bagian, dalam sebuah kegagalan. FMEA mempertimbangkan setiap bagian dan menentukan pengaruh dari setiap kegagalan yang akan mempengaruhi keseluruhan sistem. Severity dari sebuah kegagalan potensial diwakili dengan variabel S dan dikasih nilai dari 1 sampai 10 atau 1 sampai 5, dimana 10 adalah yang paling hebat pengaruhnya. Kemungkinan terjadinya suatu kegagalan dilambangkan dengan variabel O (Probability) dan diberikan nilai antara 1 sampai 10 atau 1 sampai 5, dimana 10 adalah yang paling mungkin terjadi. Kemampuan untuk mendeteksi kegagalan akan terjadi dilambangkan dengan variabel D (Detection) dan diberikan nilai antara 1 sampai 10 atau 1 sampai 5, dimana 10 adalah yang paling sulit untuk dideteksi. Tingkat kepentingan dari suatu kegagalan dilambangkan dengan RPN (Risk Priority Number) yang dihitung dengan rumus RPN = S * O * D. Proses FMEA mengembangkan beberapa database yang menyediakan pabrik dengan alat-alat dasar yang diperlukan untuk mengendalikan kualitas dari produk mereka. Laporan RPN adalah Kegagalan yang diurutkan berdasarkan nomor dari RPN untuk mengidentifikasi dan mementingkan persoalan yang harus ditetapkan sebagai potensi pengembangan dari produk. Laporan FMEA menyediakan catatan dari berbagai kemungkinan kegagalan dari suatu sistem. Database FMEA dapat di queri untuk menghasilkan laporan khusus yang mempertimbangkan performa dari sistem.
2.2. Konsep Sistem Menurut O’Brien (2003, p8) Sistem adalah kumpulan dari elemen-elemen yang saling berhubungan dan berinteraksi satu sama lain yang membentuk satu kesatuan. Menurut McLeod et al. (2001, p9-10) Sistem adalah kumpulan elemen-elemen yang
17 bersatu dengan tujuan yang sama dalam mencapai sasaran tertentu. Sistem dibagi dalam dua : 1.
Sistem terbuka yaitu sistem yang tidak ada mekanisme pengendali, timbal balik, dan tujuan seperti pada gambar 2.9.
2.
Sistem tertutup yaitu sistem yang memiliki tiga elemen pengendali ( tujuan, mekanisme pengendali, dan timbal balik ) seperti pada gambar 2.10. Input
Transformasi
Output
Gambar 2.9 Sistem Terbuka Tujuan
Mekanisme Pengendali
Input
Transformasi
Gambar 2.10 Sistem Tertutup
Output
18 2.2.1. Sistem Informasi Menurut O’Brien (2003, p6) area-area dari pengetahuan sistem informasi yang dibutuhkan pelaku bisnis yang profesional yaitu foundation concepts, information technologies, business aplications, development processes, management challenges, seperti pada gambar 2.11.
Management Challenges Business Applications
Information Systems
Development Processes
Information Technologies
Foundation Concepts
Gambar 2.11 Area-Area Pengetahuan Sistem Informasi yang Diperlukan Pelaku Bisnis Profesional Foundation concepts mencakup tingkah laku, teknis, bisnis, dan konsep kepemimpinan pokok tentang komponen-komponen dan peranan dari sistem informasi. Information Technologies mencakup konsep, pengembangan dan isu manajemen secara garis besar dalam teknologi informasi yaitu perangkat keras, perangkat lunak, jaringan, manajemen sumber data, dan teknologi berbasis internet yang lain. Business Applications mencakup penggunaan sistem informasi untuk operasi, manajemen, keuntungan persaingan dari sebuah perusahaan e-business termasuk bisnis elektronik,
19 perdagangan, kerja sama, pembuatan keputusan menggunakan internet, intranet, dan extranet. Development Processes mencakup bagaimana bisnis profesional dan ahli informasi merencanakan, mengembangkan, dan mengimplementasikan sistem informasi untuk
memenuhi
kesempatan
e-business
menggunakan
beberapa
pendekatan
pengembangan aplikasi. Management Challenges mencakup tantangan dari mengatur teknologi, strategi dan keamanan e-business pada pengguna akhir, perusahaan, dan tingkatan-tingkatan bisnis secara efektif dan pantas. Menurut O’Brien (2003, p7) Sistem informasi adalah kombinasi dari manusia, perangkat keras, perangkat lunak, jaringan komunikasi, dan sumber-sumber data yang mengumpulkan, mengubah, dan menyebarkan informasi di dalam sebuah organisasi, seperti terlihat pada gambar 2.12. Menurut Turban, et al. (2001, g-9) Sistem informasi adalah sebuah sistem yang mengumpulkan, memproses, menyimpan, dan menganalisis data dan menyebarkan informasi untuk suatu tujuan tertentu.
Manusia Perangkat Lunak
Data
Sumber Sistem Informasi
Perangka Keras
Jaringan
Gambar 2.12 Sumber Sistem Informasi Sumber manusia mencakup: 1. Para ahli seperti system analyst, software developer, system operators.
20 2. Penguna akhir yaitu semua yang menggunakan sistem informasi.
Sumber perangkat keras mencakup: 1. Mesin-mesin seperti komputer, monitor video, magnetic disk drives, printers, optical scanner. 2. Media seperti floppy disks, magnetic tape, optical disks, plastic cards, paper forms. Sumber perangkat lunak mencakup: 1. Program seperti program sistem operasi, program spreadsheet, program word processing, program pembayaran. 2. Prosedur seperti prosedur pemasukan data, prosedur perbaikan error, prosedur distribusi paycheck. Sumber data mencakup dekripsi dari produk, catatan pelanggan, berkas pelanggan, database inventaris. Sumber jaringan mencakup media komunikasi, processor komunikasi, akses jaringan dan pengendalian software. Menurut O’Brien (2003, p14) aktifitas dari sistem informasi antara lain : 1. Input, mengambil data dari aktifitas yang ada dengan mengisi formulir yang ada. 2. Processing, mengolah data yang ada seperti menghitung, membandingkan, menyusun, menggolongkan, dan meringkat. 3. Output, hasil dari pengolahan informasi seperti laporan. 4. Storage, menyimpan data dalam tempat penyimpanan 5. Control, menghasilkan feedback dari aktifitas input, processing, output, dan storage. Menurut O’Brien (2003, p20) peranan sistem informasi terbagi atas tiga tingkatan yaitu mendukung strategi untuk keuntungan persaingan pada tingkatan eksekutif, mendukung strategi untuk pembuatan keputusan pada tingkatan manajemen, dan
21 mendukung operasi dan proses bisnis pada tingkat operator seperti penyimpanan data, menyimpan data inventaris dan sebagainya. Gambar peranan dari aplikasi bisnis sistem informasi dapat dilihat pada gambar 2.13.
Mendukung Strategi untuk Keuntungan Persaingan Mendukung Pembuatan Keputusan Bisnis
Mendukung Operasi dan Proses Bisnis Gambar 2.13 Peranan dari Aplikasi Bisnis Sistem Informasi Menurut O’Brien (2003, p24) klasifikasi sistem informasi dibagi atas dua yaitu sistem penunjang operasi dan sistem penunjang manajemen, sistem penunjang operasi dibagi atas sistem proses transaksi, sistem pengendalian proses, dan sistem kolaborasi perusahaan, sedangkan sistem penunjang manajemen dibagi atas sistem informasi manajemen, sistem penunjang keputusan dan sistem informasi eksekutif. Klasifikasi sistem informasi dapat dilihat pada 2.14. Sistem penunjang operasi menghasilkan variasi dari produk informasi untuk keperluan internal dan external, tetapi tidak menekankan pada menghasilkan produk informasi yang khusus yang dapat digunakan oleh manajer. Sistem penunjang operasi
22 adalah operasi pada sistem penunjang operasi yang menyimpan dan mengolah hasil data dari transaksi bisnis. Sistem pengendalian proses memonitor dan mengendalikan proses physical. Sistem kolaborasi perusahaan mempertinggi komunikasi dan produktivitas dari tim dan kelompok kerja yang sering juga disebut sistem automasi kantor. Sistem penunjang manajemen berpusat pada penyediaan informasi dan mendukung pengambilan keputusan yang efektif oleh manajer dan bisnis profesional yang lain. Sistem informasi manajemen menyediakan informasi dalam bentuk laporan untuk ditunjukkan pada manajer dan bisnis profesional yang lain. Sistem penunjang keputusan memberikan dukungan komputer langsung terhadap manajer selama proses pembuatan keputusan. Sistem informasi eksekutif menyediakan informasi yang genting dari variasi sumber-sumber internal dan external dalam tampilan yang mudah digunakan oleh eksekutif dan manajer. Klasifikasi lain dari sistem informasi yang dapat mendukung operasi dan manajemen antara lain : Expert system dapat menyediakan saran ahli untuk tugas operasional seperti analisis peralatan, atau keputusan manajerial seperti manajemen portfolio. Knowledge management systems adalah sistem informasi berbasis pengetahuan yang mendukung pembuatan, organisasi, dan penyebaran dari pengetahuan bisnis kepada karyawan-karyawan dan manajer-manajer ke seluruh perusahaan. Functional business systems yaitu sistem informasi yang berpusat pada aplikasi operasional dan manajerial dalam mendukung fungsi bisnis yang umum seperti akuntanasi atau marketing. Lalu strategic information systems menggunakan teknologi informasi pada produk perusahaan, jasa, atau proses bisnis untuk membantu dalam memperoleh keuntungan persaingan atas pesaingnya.
23
Sistem Informasi Sistem Penunjang Operasi
Sistem Transaksi Proses
Sistem Pengendalian Proses
Sistem Kolaborasi Perusahaan
Sistem Penunjang Manajemen
Sistem Informasi Manajemen
Sistem Penunjang Keputusan
Sistem Informasi Eksekutif
Gambar 2.14 Klasifikasi Sistem Informasi
2.2.2. Analisis Sistem ( System Analysis ) Menurut McLeod et al.(2001,p128) analisis sistem adalah pembelajaran dari sistem yang ada untuk merancang sistem yang baru dan lebih baik. Menurut Turban et al. (2001, p479) analisis sistem adalah pemeriksaan dari masalah bisnis yang direncanakan untuk diselesaikan oleh organisasi dengan mengunakan sistem informasi. Menurut Whitten et al.(2004, p186) analisis sistem adalah sebuah teknik pemecahan masalah yang membagi-bagi sistem dalam komponen-komponen kecil untuk dipelajari berapa baik bagian-bagian dari komponen tersebut berjalan dan berinteraksi untuk mencapai tujuan mereka. Dari pengertian di atas dapat disimpulkan bahwa analisis sistem adalah pemeriksaan terhadap sistem yang ada untuk menilai baik tidaknya sistem yang berjalan dan diperbaiki untuk meningkatkan sistem yang ada atau membuat sistem baru yang lebih baik.
24 2.2.3. Perancangan Sistem ( System Design ) Menurut Turban et al.(2001, p482) perancangan sistem adalah penggambaran bagaimana sistem akan menyelesaikan tugas yang di dapat dari analisis sistem. Menurut McLeod et al.(2001, p130) perancangan sistem adalah penetapan proses dan data yang akan dipakai di sistem yang baru. Menurut whitten et al. (2004, p472) perancangan sistem adalah spesifikasi dari solusi berbasis komputer yang rinci.
2.2.4. Unified Modelling Language (UML) Menurut Whitten et al(2004, p430) UML adalah sebuah kumpulan dari ketentuanketentuan penggambaran (modeling conventions) yang digunakan untuk menetapkan atau menggambarkan sebuah sistem software dalam bentuk objek-objek. Berdasarkan Whitten et al.(2004,p441-442) UML menawarkan sembilan diagram-diagram / baganbagan yang dikelompokkan dalam lima pandangan yang berbeda untuk memodelkan sebuah sistem, seperti cetak biru yang dipakai untuk membuat sebuah rumah.Adapun pandangan-pandangan dalam diagram pada UML : a.
Use-Case Model Diagrams Yang termasuk dalam kelompok ini adalah use-case diagram. Use-case diagram adalah sebuah diagram yang mengambarkan interaksi antara sistem dan external sistem dan pengguna. Dengan kata lain, menggambarkan secara grafik siapa yang akan menggunakan sistem dan dalam cara apa pengguna akan berinteraksi dengan sistem.
b.
Static Structure Diagrams UML menawarkan dua bagan untuk memodelkan static structure dari sistem informasi, yaitu :
25 1.
Class diagram menggambarkan struktur objek dari sistem. Bagan ini menunjukkan objek class-class dari sistem yang terdiri dari hubungan antara objek class-class tersebut.
2.
Object diagrams mirip dengan class diagram, tetapi daripada menggambarkan objek class-class, bagan ini memodelkan instance dari objek yang sebenarnya, menampilkan nilai dari atribut-atribut dari instance objek tersebut.
c.
Interaction Diagrams Interaction diagrams menggambarkan sebuah interaksi, terdiri dari kumpulan objek-objek, hubungan mereka, dan pesan-pesan yang dikirim di antara mereka. Bagan ini menggambarkan tingkah laku dinamis dari sistem yang ada, UML menawarkan dua diagram untuk tujuan ini, yaitu : 1.
Sequence diagrams menggambarkan secara grafik bagaimana objek-objek berinteraksi satu sama lain melalui pesan-pesan dalam pelaksanaan sebuah usecase atau sebuah operasi. Bagan ini menggambarkan bagaimana pesan-pesan dikirim dan diterima diantara objek-objek dan dalam urutan apa.
2.
Collaboration diagrams mirip dengan sequence diagrams, tetapi tidak memusatkan pada tempo (timing) atau urutan dari pesan-pesan, melainkan menggambarkan interaksi atau kerja sama (collaboration) antara objek-objek dalam bentuk jaringan. Kedua diagram ini bersifat isomorphic, yang artinya kita dapat mengubah dari satu bagan ke bagan yang lain.
d.
State Diagrams State diagrams juga menggambarkan tingkah laku dinamis dari sistem. UML mempunyai bagan-bagan untuk menggambarkan tingkah laku yang kompleks dari
26 sebuah objek dan bagan untuk menggambarkan tingkat laku dari use case atau sebuah method, yaitu : 1.
Statechart diagrams digunakan untuk menggambarkan tingkah laku rumit dari sebuah objek. Bagan ini menggambarkan siklus hidup dari objek, keadaan yang bervariasi yang objek dapat ambil dan kejadian-kejadian yang dapat menyebabkan perubahan dari satu kondisi ke kondisi yang lain.
2.
Activity diagrams digunakan untuk menggambarkan secara grafik urutan aliran dari aktivitas-aktivitas baik dari proses bisnis ataupun use case. Bagan ini juga dapat digunakan untuk menggambarkan tindakan-tindakan yang akan dilakukan ketika sebuah operasi sedang dijalankan, disertai hasil dari tindakantindakan tersebut.
e.
Implementation Diagrams Implementation diagrams juga menggambarkan struktur dari sistem informasi, yang terdiri dari : 1.
Component diagrams digunakan untuk menggambarkan organisasi dan ketergantungan dari komponen-komponen sistem software. Bagan ini juga dapat digunakan untuk menggambarkan bagaimana pembubuhan kode (programming code) yang dibagi-bagi dalam modul-modul atau komponenkomponen.
2.
Deployment diagrams menggambarkan arsitektur fisik (physical architecture) dalam bentuk nodes untuk perangkat keras dan perangkat lunak dalam sistem. Bagan ini menggambarkan konfigurasi dari komponen-komponen sistem, procesor-procesor dan alat-alat saat software sedang berjalan yang membangun arsitektur dari sistem.
27 2.2.5. Konsep Berbasis Objek (Object Oriented) Konsep berbasis objek terdiri dari pembahasan tentang class, objek, atribut, tingkah laku (behaviour/methods), encapsulation, pewarisan (inheritance), dan perubahan bentuk (polymorphism). Menurut Mathiassen et al.(2000,p4) objek adalah sesuatu yang mempunyai identitas, keadaan dan tingkah laku, dan class adalah gambaran dari kumpulankumpulan objek-objek yang mempunyai struktur, pola-pola tingkah laku, dan atributatribut yang sama. Menurut Whitten et al.(2004,p431-432) objek adalah sesuatu yang dapat dilihat, disentuh atau dapat dirasakan, yang pengguna gunakan untuk menyimpan data dan tingkah laku yang berhubungan. Class adalah kumpulan dari objek-objek yang mempunyai atribut-atribut dan tingkah laku yang sama. Atribut adalah data yang mewakili sifat khas dari kepentingan atas sebuah objek. Methods / behavior adalah kumpulan hal-hal yang sebuah objek dapat lakukan dan cocok untuk memfungsikan suatu tindakan terhadap data atau atribut dari objek. Encapsulation adalah pembungkusan dari beberapa barang menjadi satu kesatuan. Inheritance adalah konsep dimana methods atau atribut-atribut yang didefinisikan dalam sebuah class dapat diwariskan atau digunakan kembali oleh class lain. Polymorphism secara harfiah berarti banyak bentuk, maksudnya objek-objek yang berbeda dapat merespon terhadap pesan (message) yang sama dalam cara yang berbeda. Menurut Mathiassen et al.(2000,p5) keuntungan dari berbasis objek adalah kemudahan dalam menggambarkan kejadian-kejadian yang umum, berbeda dengan cara tradisional yang memakai fungsi, data dan aliran data sebagai kunci dari konsep yang hanya cocok untuk menggambarkan kejadian-kejadian di kantor-kantor dan sistem terkomputerisasi. Contoh pada kalimat “Rumah itu terlihat bagus setelah Bob
28 mengecatnya”. Ini sesuai dengan konsep berorientasi objek. Ada dua objek ( rumah dan Bob ), kejadian yang umum ( mengecat rumah ) dan salah satu dari objek telah berubah keadaannya ( rumah telah menjadi bagus ). Selain itu, konsep berorientasi objek juga menyediakan informasi yang jelas tentang konteks dari sistem. Keuntungan lainnya yaitu kedekatan antara analisis berorientasi objek, perancangan berorientasi objek, layar pengguna (user interfaces) berorientasi objek, dan pemograman (programming) berorientasi objek. Objek-objek dapat berupa model sosial, ekonomi, dan kondisi organisasi, juga tampilan-tampilan, fungsi-fungsi, proses-proses dan komponenkomponen sistem. Dalam analisis, developer-developer menggunakan objek untuk menentukan syarat sistem (system requirements). Dalam perancangan, developerdeveloper menggunakan objek untuk menggambarkan sistem itu sendiri. Developerdeveloper juga menggunakan objek sebagai konsep utama dalam pemograman. Objekobjek memberikan hubungan material terhadap arsitektur sistem. Objek-objek memberikan developer sebuah jalan yang alami dalam memikirkan masalah-masalah yang menyangga yang membantu abstraksi tanpa memaksakan pandangan satu pihak. Menurut Mathiassen et al.(2000,p12-14) Konsep berorientasi objek ini dipakai dalam analisis dan perancangan berorientasi objek (Object-Oriented Analysis and Design / OOAD). OOAD menggambarkan empat pandangan pada sebuah sistem dan konteksnya : isi informasi dari sistem, bagaimana sistem akan digunakan, sistem sebagai satu kesatuan, dan komponen-komponen sistem. Sistem dilihat dari empat sudut pandang (perspectives) : a.
Sudut pandang informasi : Sistem harus menawarkan sebuah model yang berguna dari problem domain. Sistem harus mengandung model yang sesuai dengan elemenelemen dari problem-domain yang membuat pengguna dapat mengatur, menjaga
29 (monitor), dan mengendalikan problem domain. Sudut pandang informasi ini penting saat melakukan analisis. Tetapi sudut pandang ini juga penting dalam perancangan karena sistem harus membuat model tersedia secara efisien dan berguna. b.
Sudut pandang pengguna : Sistem harus terintegrasi dalam application domain. Kita harus mengerti manusia, alat-alat dan sistem lain yang sistem akan berinteraksi dengan, dan fungsi-fungsi apa yang akan menawarkan hal ini. Hubungan seperti bagaimana, bagaimana cepat, seberapa sering dan dalam pola apa pelaku-pelaku (actors) yang berbeda harus berinteraksi dengan sistem sangat penting terhadap bisa-tidak dipakainya (usability) sistem. Sebuah sistem yang berfungsi dengan baik adalah yang terintegrasi dengan sistem yang lain dan dibiasakan (adapted) terhadap organisasi dan kebiasaan di dalam application domain.
c.
Sudut pandang arsitektur : Sistem harus dapat berjalan pada technical platform tertentu. Bagaimana sistem seharusnya dibagi-bagi dalam komponen-komponen? Pertimbangan-pertimbangan penting termasuk proses-proses physical, unit-unit dan hubugan-hubungan yang membuat technical platform. Bagaimana seharusnya sistem menggunakan platform ini ? sebuah structur membantu kita dalam menentukan betapa pentingnya untuk mengambil keuntungan dari kemampuan platform dan mengatasi batasan-batasannya.
d.
Sistem sebagai satu kesatuan : Sistem seharusnya merupakan unit yang bekerja dengan baik dari bagian-bagian yang bekerja sama. Komponen-komponen individual dan tampilan (interfaces) untuk saling berhubungan dan berinteraksi harus di rancang harus menjadi dasar untuk implementasi sistem.
30 Sudut pandang (perspectives) ini diliputi dengan aktivitas-aktivitas utama OOAD : analisis problem-domain, analisis application-domain, perancangan arsitektur, dan perancangan komponen. Aktivitas-aktivitas utama OOAD dan hasilnya dapat dilihat pada gambar 2.15. Hasil nyata dari analisis dan perancangan adalah dokumentasi, yang membantu kita secara praktek mengurus aktivitas analisis dan perancangan yang sebenarnya. Dokumentasi menyediakan referensi untuk developer-developer, dan sebuah tempat untuk menyimpan dan mengatur hasil-hasil menengah (intermediate results). Dokumentasi juga berisi persetujuan di antara peserta-peserta dalam proyek. Dokumentasi membantu kelancaran selama pengembangan sistem, demikian juga kualitas yang tinggi. Pada saat yang sama dokumentasi harus jelas dan singkat. Untuk membuat dokumentasi yang berkualitas tinggi diperlukan usaha yang keras dan perancangan dokumentasi yang terlalu rinci tidak akan mengilhami kreativitas dan efektivitas dalam programmers. OOAD menghasilkan dokumentasi analisis dan perancangan.
Problemdomain analysis
model
Requirements for use
Applicationdomain analysis
Component design Specification of components Specification of architecture
Architectural design
Gambar 2.15 Aktivitas-Aktivitas Utama OOAD dan Hasilnya
31 2.2.6. Unified Process dan Notation Menurut Mathiassen et al.(2000,p15) OOAD bisa dilakukan dalam dua pendekatan yaitu : pendekatan tradisional top-down dan use-case-driven. Pendekatan tradisional topdown dapat dilihat pada gambar 2.16, pendekatan use-case-driven, architecture-centric dan incremental dapat dilihat pada gambar 2.17. Menurut Mathiassen et al.(2000,p16-18) OOAD membedakan pedoman untuk proses-proses dan untuk notation. Hal ini membuat kita dapat memilih buku apa saja untuk object oriented yang kita pilih. OOAD juga membedakan prinsip-prinsip yang umum dan teknik-teknik dasar. Penekanan utama OOAD adalah pada prinsip-prinsip, kita
menggunakan
teknik-teknik
untuk
meilustrasikan
bagaimana
mengimplementasikan prinsip-prinsip. Problem-domain analysis Application-domain analysis Architectural design Component design Programming Quality assurance
Software Phase 1
Phase 2
Phase 3
Gambar 2.16 Pendekatan Tradisional, Top-down berdasarkan OOAD
untuk
32
Problem-domain analysis Application-domain analysis Architectural design Component design Programming Quality assurance
Software release n
Software release 1 Phase 1
.................
Phase n
Gambar 2.17 Pendekatan Use-Case Driven, Architecture-Centric, dan Incremental berdasarkan OOAD Keuntungan dari penyajian berdasarkan prinsip-prinsip adalah kita dapat mengganti dengan teknik kita sendiri jika tugas atau syarat-syarat (terms) memerintahkannya. Dan untuk notation OOAD memakai bagian utama dari UML. Keuntungan memakai UML dalam notation OOAD ini adalah : pertama, UML juga dibangun atas bagian-bagian antara proses dan notation, jadi tidak ada pedoman proses yang sudah ada dalam UML yang perlu untuk diperhatikan. Kedua, dukungan UML yang luas memberikan kita akses ke pasar yang luas dari alat-alat pengembangan yang cocok dengan UML. Proses pengembangan unified software berkaitan dengan UML tetapi berdiri sendiri. Proses unified mewakili satu cara untuk mengatur proyek berorientasi objek yang use-case driven, architecture-centric, iterative dan incremental. Use case adalah teknik-teknik khusus yang digunakan dalam analisis application-domain. Seperti terlihat pada gambar 2.16 dan 2.17 kita dapat melihat persamaan dan perbedaan dari kedua pendekatan yang ada. Pendekatan tradisional dimulai pertama kali dari analisis problem-
33 domain, sedangkan pendekatan unified dimulai pertama kali dari analisis applicationdomain (dengan use-case). Pendekatan tradisional menekankan pada analisis, perancangan dan pemograman dari keseluruhan sistem, sedangkan pendekatan unified adalah bertahap, memusatkan pada analisis, perancangan dan pemograman dari satu bagian sistem pada satu waktu.
2.2.7. Analisis Berbasis Objek (Object-Oriented Analysis) dengan Menggunakan UML Berdasarkan Whitten et al.(2004,p430-431) analisis berbasis objek terdiri dari banyak konsep. Beberapa dari konsep ini memerlukan sebuah cara baru untuk memikirkan tentang sistem dan proses pengembangan. Analisis berbasis objek memperhatikan bagaimana memdefinisikan struktur yang tetap dan model jalan yang dinamik dari sistem informasi daripada mendefinisikan data dan model proses, yang merupakan hasil dari pendekatan perkembangan tradisional. Analisis berbasis objek digunakan untuk mempelajari objek-objek yang sudah ada untuk melihat apakah mereka dapat digunakan kembali atau disesuaikan untuk kegunaan yang baru dan mendefinisikan objek yang baru atau yang telah dimodifikasi yang akan dikombinasi dengan objek yang sudah ada ke dalam sebuah aplikasi bisnis yang dapat bersaing di pasar. Aktivitas-aktivitas dalam analisis berorientasi objek: 1. Memodelkan fungsi-fungsi dari sistem, disini dibuat use case yang berisikan informasi umum tentang kejadian bisnis, activity diagram dari use-case tersebut.
34 2. Menemukan dan mengidentifikasi objek-objek bisnis, di sini kita membuat class diagram yang berhubungan. 3. Mengatur objek-objek dan mengidentifikasi hubungan-hubungan mereka, class diagram dilengkapi dengan hubungan-hubungan seperti asosiasi, generalisasi dan multiplicity.
2.2.8. Pemodelan dan Perancangan Berorientasi Objek (Object-Oriented Design and Modeling) dengan Menggunakan UML Menurut Whitten et al(2004, p686) Perancangan berorientasi objek adalah pendekatan yang digunakan untuk menentukan pemecahan secara software dalam hal kerja sama dari objek-objek, atribut-atribut mereka, dan methods mereka. Aktivitas-aktivitas dalam perancangan berorientasi objek : 1. Memperbaiki (refining) model-model use-case untuk menggambarkan lingkungan implementasi. 2. Memodelkan interaksi dan tingkah laku antar objek yang mendukung skenario use-case. 3. Memperbaharui model objek untuk menggambarkan lingkungan implementasi. Di aktivitas ini kita membuat perancangan class diagram (design class diagram) yaitu sebuah diagram yang menggambarkan class-class yang sesuai dengan komponen-komponen software yang digunakan untuk membangun aplikasi software. Sebuah design class diagram biasanya mencakup : class, hubungan asosiasi, generalisasi / spesifikasi, dan agregasi, atribut dan informasi
tipe
dependencies.
atribut,
method
dengan
parameter,
navigability,
dan
