Gambar 4.34 Cluster Jadwal Produksi. jadwal produksi oleh Kepala Pabrik. Seperti yang sudah dijelaskan dalam system

Transkripsi

1 274 Gambar 4.34 Cluster Jadwal Produksi Cluster jadwal produksi berisi class-class yang berhubungan dengan pembuatan jadwal produksi oleh Kepala Pabrik. Seperti yang sudah dijelaskan dalam system definition, jadwal produksi berfungsi sebagai petunjuk bagi karyawan Bagian Produksi dalam menentukan jenis pigura yang harus diproduksi, jumlahnya, dan spesifikasi khusus yang perlu diperhatikan selama proses produksi. Selain itu masing-masing jadwal produksi terdiri dari instruksi produksi yang merupakan panduan bagi karyawan Bagian Produksi dan Bagian Pengemasan dalam menjalankan proses produksi dan nilainilai target yang harus dipenuhi selama proses pengendalian kualitas. Karena itu hubungan antara jadwal produksi dan instruksi produksi merupakan hubungan agregasi. Gambar 4.35 Cluster Mesin Cluster mesin hanya terdiri dari 1 class, yaitu mesin. Class ini menjelaskan mesin-mesin yang digunakan selama proses produksi pigura di PT Decorindo Raya.

2 275 Masing-masing class dalam tabel 4.47 memiliki aktivitasnya masing-masing. Beberapa aktivitas yang dilakukan oleh class-class tersebut berhubungan dengan sistem informasi yang akan dibangun. Aktivitas-aktivitas seingkali disebut sebagai event dan perlu diidentifikasi sebelum sistem informasi dibuat. Sama seperti dalam mendefinisikan class, pertama-tama perlu dicari event candidate yang diperoleh dari kata kerja yang terdapat dalam system definition. Tabel 4.48 Event Candidate Sistem Pengendalian Kualitas Usulan 1. Memasukkan data pesanan 2. Membaca pesanan 3. Membuat jadwal produksi 4. Membuat instruksi produksi 5. Membaca jadwal produksi 6. Membaca instruksi produksi 7. Dinyatakan lulus uji kualitas 8. Menghasilkan pigura berkualitas 9. Memudahkan 10. Mengoperasikan mesin 11. Menyimpan 12. Dievaluasi 13. Memeriksa pigura 14. Membuat laporan pigura cacat 15. Diproduksi 16. Dicatat 17. Dikelompokkan 18. Dikembalikan 19. Diperbaiki Sumber : Hasil Analisa dan Pembahasan 20. Membuat laporan rework 21. Dilakukan 22. Mencakup 23. Mengetahui 24. Digunakan 25. Mengajukan komplain 26. Membuat laporan bahan baku cacat 27. Diakses 28. Dibutuhkan 29. Membaca laporan 30. Meningkatkan kualitas 31. Dicetak 32. Merugikan 33. Dideteksi 34. Diatasi 35. Dibangun 36. Ditambah 37. Diubah 38. Dihapus Dari event candidate, dipilih beberapa di antaranya yang berhubungan dengan class-class yang sudah ditentukan sebelumnya. Selain itu, event-event yang dipilih harus bersifat instan dan dapat diidentifikasi saat terjadinya. Event-event tersebut antara lain :

3 276 Tabel 4.49 Event Sistem Pengendalian Kualitas Usulan 1. Memasukkan data pesanan 2. Membaca pesanan 3. Membuat jadwal produksi 4. Membuat instruksi produksi 5. Membaca jadwal produksi 6. Membaca instruksi produksi 7. Membuat laporan pigura cacat 8. Membuat laporan rework Sumber : Hasil Analisa dan Pembahasan 9. Membuat laporan bahan baku cacat 10. Dicetak 11. Mengelola data konsumen 12. Mengelola data supplier 13. Mengelola data pigura 14. Mengelola data bahan baku 15. Mengelola data mesin Dari tabel 4.49 di atas, terlihat ada beberapa event tambahan yang sebenarnya bukan merupakan kata kerja di dalam system definition, yaitu nomor pada 12 sampai 15. Bila diperhatikan, kesembilan event tersebut melibatkan 5 objek, yaitu konsumen, supplier, pigura, bahan baku, dan mesin. Kelimanya memiliki event yang sama yaitu mengelola. Karena event tersebut dilakukan oleh class yang berbeda, maka harus dipisahkan berdasarkan objek yang terlibat. Hubungan antara setiap event dengan classclass yang ada dapat dilihat pada event table berikut :

4 277 Class Tabel 4.50 Event Table Sistem Pengendalian Kualitas Usulan Event Memasukkan data pesanan Membaca pesanan Membuat jadwal produksi Membuat instruksi produksi Membaca jadwal produksi Membaca instruksi produksi Membuat laporan pigura cacat Membuat laporan rework Membuat laporan bahan baku cacat Dicetak Mengelola data konsumen Mengelola data supplier Mengelola data pigura Mengubah data bahan baku Mengelola data mesin General Manager * * * * Pesanan + + Konsumen + Pigura + Kepala Pabrik * * * * * * * Jadwal produksi + * Instruksi produksi + + Bagian Produksi * * * Mesin + Bagian Pengemasan * * Pigura cacat + + Rework + + Supervisor * Bahan baku + Bahan baku cacat + + Supplier * Keterangan : + sekali * berulang Sumber : Hasil Analisa dan Pembahasan

5 278 Seperti yang terdapat pada perusahaan-perusahaan pada umumnya, data-data karyawan PT Decorindo Raya juga disimpan dalam database. Karena masing-masing karyawan memiliki atribut yang sama, maka dapat dibuat hubungan generalisasi antara karyawan-karyawan tersebut. Dengan demikian, terdapat tambahn class baru yaitu Karyawan yang menampung atribut-atribut General Manager, Kepala Pabrik, Supervisor, Bagian Produksi, dan Bagian Pengemasan. Class Karyawan dibuat dan diupdate oleh seorang administrator. Dengan kata lain, masing-masing karyawan tidak memiliki hak akses untuk mengubah atribut karyawan lainnya. Dengan memperhatikan event table dalam tabel 4.50, terlihat bahwa setiap event yang dilakukan oleh sebuah class melibatkan class lainnya. Class-class yang terlibat dalam sebuah event bisa berjumlah dua atau lebih. Hubungan antar class tersebut dapat digambarkan secara struktural melaui class diagram sebagai berikut :

6 279 Karyawan -Kode Karyawan : String -Password : String +Nama Karyawan : String #Alamat Karyawan : String #No Telp Karyawan : String -Gaji per Jam : Integer +dikelola() General Manager Supervisor Kepala Pabrik Bagian Pengemasan Bagian Produksi Memasukkan data pesanan() +Mencetak() +Mengelola data konsumen() +Mengelola data supplier() Membuat laporan bahan baku cacat() 1 1 +Membaca pesanan() +Membuat jadwal produksi() +Membuat instruksi produksi() +Mencetak() 1 1 +Mengelola data pigura() +Mengelola data bahan baku() +Mengelola data mesin() 1 +Membaca instruksi produksi() +Membuat laporan pigura cacat() 1 * +Membaca jadwal produksi() +Membaca instruksi produksi() +Membuat laporan rework() * 1 0..* 1..* 1 1..* Konsumen -Kode Konsumen : String +Nama Konsumen : String #Alamat Konsumen : String #No Telp Konsumen : String +Dikelola() Pesanan -Kode Pesanan : String +Tanggal Pesanan : Date -Kode Konsumen : String -Kode Pigura : String +Jumlah Pigura : Integer +Keterangan : String +Dibaca() +Dimasukkan() 1..* 0..* Supplier -Kode Supplier : String +Nama Supplier : String #Alamat Supplier : String #No Telp Supplier : String +Dikelola() 1..* 1..* Bahan Baku -Kode Bahan Baku : String -Tanggal Pengiriman : Date +Nama Bahan Baku : String #Kode Supplier : String #Harga Bahan Baku : Integer #Volume Per Kemasan : Integer Bahan Baku Cacat -Kode Bahan Baku : String -Jumlah Cacat : Integer -Volume Diterima : Integer -Keterangan : String +Dicetak() * 1..* 0..* * * 1..* Pigura -Kode Pigura : String -Kategori Pigura : String +Jenis Pigura : String -Warna Pigura : String -Jenis Profil : String +Harga per Meter : Integer +Dikelola() -Kode Mesin : String -Nama Mesin : String -Kode Bahan Baku : String -Biaya Listrik per Jam : Integer -Bahan Baku per Jam : Integer +Dikelola() Mesin 1..* 0..* 0..* 1 Pigura Cacat -Kode Cacat : String -Tanggal Cacat : Date -Kode Produksi : String #Kode Karyawan : String -Kategori Cacat : String -Jumlah Cacat : Integer +Dicetak() 1 1 Rework Jadwal Produksi -Kode Produksi : String -Tanggal Produksi : Date -Kode Pigura : String -Jumlah Pigura : Integer +Dibuat() +Dibaca() -Kode Rework : String -Tanggal Rework : Date -Kode Karyawan : String -Kode Cacat : String -Penyebab Cacat : String -Keterangan Cacat : String 1 1..* -Kode Mesin : String 0..* -Durasi Rework : Integer -Biaya Kualitas : Integer * 0..* +Dibuat() +Dicetak() 1 0..* * Instruksi Produksi +Kode Mesin : String #Setting Mesin : String -Nilai Target Pigura : String 1 0..* Gambar 4.36 Class Diagram Sistem Informasi Pengendalian Kualitas Usulan

7 280 Dari class diagram dan event table yang sudah dibuat, selanjutnya dapat diketahui perilaku umum dari masing-masing class beserta atributnya. Atribut ini adalah data dan informasi yang terlibat dalam event yang dilakukan oleh sebuah class. Hubungan antara class dan atributnya dapat dilihat dalam bentuk state diagram. Berdasarkan sifat dari suatu hubungan agregasi, class turunan memiliki atribut dan event yang sama dengan class induknya. Oleh karena itu state diagram yang digambar cukup class induknya saja. State diagram yang didapat dari class diagram pada gambar 4.30 adalah sebagai berikut : / mengelola_data_konsumen / memasukkan_data_pesanan / mencetak Aktif / mengelola_data_supplier Gambar 4.37 State Diagram General Manager Tabel 4.51 Event dan Attribute Class General Manager Event Attributes kode_pesanan, tanggal_pesanan, kode_konsumen, memasukkan_data_pesanan kode_pigura, jumlah_pigura, keterangan kode_konsumen, nama_konsumen, alamat_konsumen, mengelola_data_konsumen no_telp_konsumen kode_supplier, nama_supplier, alamat_supplier, mengelola_data_supplier no_telp_supplier kode_bahan_baku, kode_bahan_baku_cacat, harga_bahan_baku, kode_supplier, tanggal_pengiriman, jumlah_cacat, keterangan, kode_pigura, kode_cacat, mencetak kode_produksi, tanggal_cacat, kode_karyawan, kategori_cacat, jumlah_cacat, kode_rework, tanggal_rework, penyebab_cacat, keterangan_cacat, durasi_rework, biaya_kualitas Sumber : Hasil Analisa dan Pembahasan

8 281 Gambar 4.38 State Diagram Pesanan Tabel 4.52 Event dan Attribute Class Pesanan Event Attributes dimasukkan kode_pesanan, tanggal_pesanan, kode_konsumen, kode_pigura, jumlah_pigura, keterangan dibaca kode_pesanan, tanggal_pesanan, kode_konsumen, kode_pigura, jumlah_pigura, keterangan disimpan kode_pesanan, tanggal_pesanan, kode_konsumen, kode_pigura, jumlah_pigura, keterangan Sumber : Hasil Analisa dan Pembahasan Gambar 4.39 State Diagram Konsumen Tabel 4.53 Event dan Attribute Class Konsumen Event Attributes ditambah kode_konsumen, nama_konsumen, alamat_konsumen, no_telp_konsumen dikelola nama_konsumen, alamat_konsumen, no_telp_konsumen dihapus kode_konsumen, nama_konsumen, alamat_konsumen, no_telp_konsumen Sumber : Hasil Analisa dan Pembahasan

9 282 Gambar 4.40 State Diagram Pigura Tabel 4.54 Event dan Attribute Class Pigura Event Attributes ditambah kode_pigura, kategori_pigura, jenis_pigura, warna_pigura, jenis_profil, harga_per_meter dikelola harga_per_meter dihapus kode_pigura, kategori_pigura, jenis_pigura, warna_pigura, jenis_profil, harga_per_meter Sumber : Hasil Analisa dan Pembahasan Gambar 4.41 State Diagram Kepala Pabrik

10 283 Tabel 4.55 Event dan Attribute Class Kepala Pabrik Event Attributes kode_pesanan, tanggal_pesanan, kode_konsumen, membaca_pesanan kode_pigura, jumlah_pigura, keterangan kode_produksi, tanggal_produksi, kode_pigura, membuat_jadwal_produksi jumlah_pigura kode_pigura, kategori_pigura, jenis_pigura, mengelola_data_pigura warna_pigura, jenis_profil, harga_per_meter kode_mesin, nama_mesin, kode_bahan_baku, mengelola_data_mesin biaya_listrik_per_jam, bahan_baku_per_jam kode_bahan_baku, nama_bahan_baku, mengelola_data_bahan_baku kode_supplier, harga_bahan_baku, volume_diterima kode_bahan_baku, kode_bahan_baku_cacat, harga_bahan_baku, kode_supplier, tanggal_pengiriman, jumlah_cacat, keterangan, kode_pigura, kode_cacat, kode_produksi, mencetak tanggal_cacat, kode_karyawan, kategori_cacat, jumlah_cacat, kode_rework, tanggal_rework, penyebab_cacat, keterangan_cacat, durasi_rework, biaya_kualitas Sumber : Hasil Analisa dan Pembahasan Gambar 4.42 State Diagram Jadwal Produksi Tabel 4.56 Event dan Attribute Class Jadwal Produksi Event Attributes dibuat kode_produksi, tanggal_produksi, kode_pigura, jumlah_pigura dibaca kode_produksi, tanggal_produksi, kode_pigura, jumlah_pigura disimpan kode_produksi, tanggal_produksi, kode_pigura, jumlah_pigura Sumber : Hasil Analisa dan Pembahasan

11 284 Gambar 4.43 State Diagram Bagian Produksi Tabel 4.57 Event dan Attribute Class Bagian Produksi Event Attributes kode_produksi, tanggal_produksi, kode_pigura, membaca_jadwal_produksi jumlah_pigura kode_rework, tanggal_rework, kode_karyawan, membuat_laporan_rework kode_cacat, penyebab_cacat, kode_mesin, durasi_rework, biaya_kualitas Sumber : Hasil Analisa dan Pembahasan Gambar 4.44 State Diagram Mesin Tabel 4.58 Event dan Attribute Class Mesin Event Attributes ditambah kode_mesin, nama_mesin, kode_bahan_baku, biaya_listrik_per_jam, bahan_baku_per_jam dikelola biaya_listrik_per_jam dihapus kode_mesin, nama_mesin, kode_bahan_baku, biaya_listrik_per_jam, bahan_baku_per_jam Sumber : Hasil Analisa dan Pembahasan Gambar 4.45 State Diagram Bagian Pengemasan

12 285 Tabel 4.59 Event dan Attribute Class Bagian Pengemasan Event Attributes kode_produksi, tanggal_produksi, kode_pigura, membaca_instruksi_produksi kode_instruksi, kode_mesin, setting_mesin, nilai_target_pigura kode_pigura, kode_cacat, kode_produksi, membuat_laporan_pigura_cacat tanggal_cacat, kode_karyawan, kategori_cacat, jumlah_cacat Sumber : Hasil Analisa dan Pembahasan Gambar 4.46 State Diagram Rework Tabel 4.60 Event dan Attribute Class Rework Event Attributes kode_rework, tanggal_rework, kode_karyawan, dibuat kode_cacat, penyebab_cacat, keterangan_cacat, kode_mesin, durasi_rework, biaya_kualitas kode_rework, tanggal_rework, kode_karyawan, dicetak kode_cacat, penyebab_cacat, keterangan_cacat, kode_mesin, durasi_rework, biaya_kualitas Sumber : Hasil Analisa dan Pembahasan Gambar 4.47 State Diagram Supervisor Tabel 4.61 Event dan Attribute Class Supervisor Event Attributes kode_bahan_baku, nama_bahan_baku, membaca_data_bahan_baku kode_supplier, harga_bahan_baku, volume_diterima kode_bahan_baku, kode_bahan_baku_cacat, membuat_laporan_bahan_baku_cacat kode_supplier, tanggal_pengiriman, jumlah_cacat, keterangan Sumber : Hasil Analisa dan Pembahasan

13 286 Gambar 4.48 State Diagram Supplier Tabel 4.62 Event dan Attribute Class Supplier Event Attributes ditambah kode_supplier, nama_supplier, alamat_supplier, no_telp_supplier dikelola nama_supplier, alamat_supplier, no_telp_supplier dihapus kode_supplier, nama_supplier, alamat_supplier, no_telp_supplier Sumber : Hasil Analisa dan Pembahasan Application Domain Analysis Pada tahap problem domain, diketahui permasalahan-permasalahan yang ada di perusahaan. Dari permasalahan tersebut, dibuat suatu model sistem usulan sehingga dapat meningkatkan kinerja karyawan yang bersangkutan. Setelah mendapatkan model dari sistem yang akan dibangun, selanjutnya perlu dirancang bagaimana karyawan perusahaan dapat berinteraksi dengan sistem tersebut sebagai user. Interaksi tersebut dapat digambarkan melalui use case diagram sebagai berikut :

14 287 Sistem Informasi Pengendalian Kualitas di PT Decorindo Raya Login Pengelolaan Password Pengelolaan Data Konsumen dan Supplier General Manager Pengelolaan Data Pigura, Bahan Baku, dan Mesin Penerimaan Pesanan Pelaporan Bahan Baku Cacat Kepala Pabrik Supervisor Pembuatan Jadwal Produksi Pembuatan Instruksi Produksi Pelaporan Produk Cacat Bagian Produksi Pelaporan Hasil Rework Bagian Pengemasan Pencetakan Laporan Gambar 4.49 Use Case Diagram Sistem Informasi Pengendalian Kualitas Usulan

15 288 Seperti yang terlihat dalam gambar 4.49, use case diagram terdiri dari beberapa use case yang memiliki proses bisnis dan aktor yang berbeda-beda. Masing-masing use case tersebut dapat dijelaskan sebagai berikut : Use Case Brief Description Pre Condition Basic Flow Alternative Flow Special Requirement Post Condition Tabel 4.63 Use Case Analysis Login Login Use case ini menjelaskan tentang bagaimana karyawan melakukan login untuk masuk ke dalam sistem. - Kode dan data-data karyawan sudah terisi dengan lengkap dan tersimpan ke dalam sistem 1. Karyawan masuk ke layar Login. 2. Karyawan memasukkan kode karyawan dan password. 3. Sistem akan mengecek kesesuaian kode karyawan dan password yang dimasukkan user dengan yang tersimpan di database. 4. Jika datanya sesuai, maka karyawan akan langsung masuk ke halaman utama. Bila datanya tidak sesuai, sistem akan memberikan peringatan kepada karyawan dan layar Login akan direset kembali. 5. Use case selesai. - Kode karyawan tidak boleh ada yang sama - Kode karyawan tidak dapat diubah-ubah lagi, hanya dapat dihapus - Password Karyawan akan masuk ke halaman utama dari sistem. Sumber : Hasil Analisa dan Pembahasan

16 289 Tabel 4.64 Use Case Analysis Pengelolaan Password Use Case Brief Description Pre Condition Basic Flow Alternative Flow Special Requirement Post Condition Pengelolaan Password Use case ini menjelaskan tentang bagaimana Karyawan melakukan perubahan passwordnya masing-masing. - Kode dan data-data karyawan sudah terisi dengan lengkap dan tersimpan ke dalam sistem 1. Karyawan masuk ke layar Pengelolaan Password. 2. Karyawan memasukkan kode konsumen, password lama, dan password baru. 3. Sistem akan mengecek kesesuaian kode karyawan dan password yang dimasukkan user dengan yang tersimpan di database. 4. Jika datanya sesuai, maka sistem akan memberikan pesan bahwa perubahan password berhasil dan karyawan akan kembali ke halaman utama. Bila datanya tidak sesuai, sistem akan memberikan peringatan kepada karyawan dan layar Pengelolaan Password akan direset kembali. 5. Use case selesai. - Password Password baru akan disimpan ke dalam database dan karyawan akan kembali ke halaman utama dari sistem. Sumber : Hasil Analisa dan Pembahasan

17 290 Tabel 4.65 Use Case Analysis Pengelolaan Data Pigura, Bahan Baku, dan Mesin Use Case Brief Description Pre Condition Basic Flow Alternative Flow Special Requirement Post Condition Pengelolaan Data Pigura, Bahan Baku, dan Mesin Use case ini menjelaskan tentang bagaimana Kepala Pabrik mengelola data-data pigura, bahan baku, dan mesin yang tersimpan dalam database. - Kepala Pabrik memiliki data-data yang lengkap mengenai pigura, bahan baku, dan mesin 1. Kepala Pabrik masuk ke layar Pengelolaan Data. 2. Kepala Pabrik memilih data apa yang ingin dikelola. 3. Untuk menambah data baru, Kepala Pabrik memasukkan data-data berupa nama, jenis, warna, dan lain-lain. 4. Untuk mengubah data yang sudah ada, Kepala pabrik memasukkan kode pigura, bahan baku, atau mesin yang ingin diubah. Setelah itu Kepala Pabrik tinggal mengubah data-data tersebut, dan sistem akan melakukan update terhadap database. 5. Penghapusan data dilakukan berdasarkan kode pigura, bahan baku, atau mesin di mana semua data-data yang berhubungan dengan kode tersebut akan dihapus. 6. Use case selesai. - Kode pigura, bahan baku, dan mesin baru dibuat secara otomatis oleh sistem - Kode pigura, bahan baku, dan mesin tidak dapat diubah-ubah lagi, hanya dapat dihapus - Kode bahan baku dibedakan berdasarkan kode supplier dan tanggal pengirimannya. Bahan baku dengan jenis yang sama namun tanggal pengirimannya berbeda akan memiliki kode bahan baku yang berbeda juga - Kategori pigura hanya dapat bertipe boolean dan hanya dapat dipilih dari combo box di mana terdapat 2 pilihan, yaitu standar dan batangan - Harga bahan baku, harga per meter pigura, dan biaya listrik per jam dinyatakan dalam satuan Rupiah - Volume diterima dan bahan baku per jam harus berupa angka dan boleh berbentuk desimal Database pigura, bahan baku, dan mesin akan diupdate. Sumber : Hasil Analisa dan Pembahasan

18 291 Use Case Brief Description Pre Condition Basic Flow Alternative Flow Special Requirement Post Condition Tabel 4.66 Use Case Analysis Penerimaan Pesanan Penerimaan Pesanan Use case ini menjelaskan tentang bagaimana data-data pesanan konsumen yang diterima oleh General Manager akan dimasukkan ke dalam sistem informasi. Selanjutnya data-data pesanan tersebut akan dibaca oleh Kepala Pabrik sebagai dasar dalam menyusun jadwal dan instruksi produksi. - General Manager sudah menerima data-data pesanan dari konsumen dengan lengkap - Kode pesanan sudah terisi secara otomatis oleh sistem 1. General Manager masuk ke layar Penerimaan Pesanan 2. Sistem akan secara otomatis membuat kode pesanan baru dan mengisi tanggal pesanan berdasarkan tanggal pada saat itu 3. General Manager akan melihat database pigura, kemudian memasukkan kode pigura berdasarkan karakteristik pigura yang dipesan oleh konsumen 4. General Manager akan melihat database konsumen, kemudian memasukkan kode konsumen 5. General Manager akan memasukkan jumlah pigura yang dipesan beserta keterangan tambahan. Keterangan ini berisi tentang permintaan khusus yang diajukan oleh konsumen 6. Sistem akan memberikan sinyal kepada Kepala Pabrik sebagai tanda bahwa ada pesanan baru yang masuk ke sistem 7. Use case selesai 3. Untuk konsumen yang sudah sering memesan pigura di PT Decorindo Raya, biasanya mereka juga mengetahui kode pigura yang mereka pesan. Oleh karena itu General Manager tidak perlu melihat kode pigura di dalam database lagi melainkan langsung dari pesanan konsumen 5. Bila tidak ada permintaan khusus dari konsumen, maka bagian keterangan tidak perlu diisi - Kode pesanan tidak boleh ada yang sama - Kode konsumen dan kode pigura harus terisi - Jumlah pigura harus dimasukkan dalam satuan meter dan boleh dalam bentuk desimal Data pesanan konsumen tersimpan ke dalam sistem dan dapat dibaca ulang. Sumber : Hasil Analisa dan Pembahasan

19 292 Use Case Brief Description Pre Condition Basic Flow Alternative Flow Special Requirement Post Condition Tabel 4.67 Use Case Analysis Pelaporan Bahan Baku Cacat Pelaporan Bahan Baku Cacat Use case ini menjelaskan tentang bagaimana Supervisor melaporkan bahan baku cacat yang diterima dari supplier. - Data-data supplier beserta bahan baku yang disuplainya sudah dimasukkan dengan lengkap oleh General Manager dan disimpan dalam database supplier 1. Supervisor masuk ke layar Pelaporan Bahan Baku Cacat. 2. Supervisor melihat ke dalam database bahan baku untuk melihat kode bahan baku berdasarkan nama bahan baku 3. Supervisor memasukkan data jumlah bahan baku yang cacat beserta keterangannya ke dalam database bahan baku cacat. 4. Use case selesai. 2. Sama seperti supplier, beberapa kode bahan baku yang sering digunakan dalam proses produksi juga sudah dihafal secara manual sehingga tidak perlu melihat ke dalam database terlebih dulu. - Tanggal pengiriman harus diisi - Kode bahan baku cacat dibuat oleh sistem secara otomatis - Jumlah cacat harus diisi dalam bentuk angka dan boleh berupa desimal Data-data bahan baku cacat tersimpan dalam database. Data tersebut sewaktu-waktu dapat dilihat kembali oleh General Manager dan Kepala Pabrik, serta dapat dicetak dalam bentuk laporan. Sumber : Hasil Analisa dan Pembahasan

20 293 Use Case Brief Description Pre Condition Basic Flow Alternative Flow Special Requirement Post Condition Tabel 4.68 Use Case Analysis Pembuatan Jadwal Produksi Pembuatan Jadwal Produksi Use case ini menjelaskan tentang bagaimana data-data pesanan konsumen dibaca oleh Kepala Pabrik dan dijadikan sebagai dasar dalam menyusun jadwal produksi. - Data-data pesanan konsumen sudah tersimpan dalam database - Kode jadwal produksi sudah terisi secara otomatis oleh sistem - Sistem memberikan sinyal kepada Kepala Pabrik sebagai tanda bahwa ada pesanan baru yang masuk ke sistem 1. Kepala Pabrik masuk ke layar Pembuatan Jadwal Produksi. 2. Kepala Pabrik akan melihat database pigura untuk melihat karakteristik pigura yang dipesan oleh konsumen berdasarkan kode pigura yang tercantum dalam pesanan. Selain itu Kepala Pabrik juga dapat melihat database mesin untuk mengecek data-data mesin yang akan digunakan selama proses produksi. 3. Kepala Pabrik akan membuat jadwal produksi yang berisi tentang tanggal produksi harus dimulai, jenis-jenis pigura yang harus diproduksi beserta jumlahnya. 4. Sistem akan memberikan sinyal kepada Bagian Produksi sebagai tanda bahwa ada jadwal produksi baru yang masuk ke sistem. 5. Use case selesai. 3. Untuk jenis-jenis pigura yang sering dipesan, Kepala Pabrik tidak perlu melihat lagi ke dalam database melainkan langsung membuat instruksi produksi. - Kode produksi tidak boleh ada yang sama - Kode pigura harus terisi - Jumlah pigura harus dimasukkan dalam satuan meter Jadwal produksi tersimpan ke dalam sistem dan dapat dibaca ulang oleh Kepala Pabrik. Sumber : Hasil Analisa dan Pembahasan

21 294 Use Case Brief Description Pre Condition Basic Flow Alternative Flow Special Requirement Post Condition Tabel 4.69 Use Case Analysis Pembuatan Instruksi Produksi Pembuatan Instruksi Produksi Use case ini menjelaskan tentang bagaimana Kepala Pabrik membuat instruksi produksi untuk jadwal produksi yang sudah dibuat sebelumnya. - Data-data jadwal produksi sudah tersimpan dalam database - Kode instruksi produksi sudah terisi secara otomatis oleh sistem 1. Kepala Pabrik masuk ke layar Pembuatan Instruksi Produksi. 2. Kepala Pabrik akan mengecek data jadwal produksi di dalam database berdasarkan kode produksi. 3. Kepala Pabrik akan melihat database mesin untuk melihat jenisjenis mesin yang ada dan digunakanselama proses produksi pigura. 4. Kepala Pabrik membuat instruksi produksi yang mencakup mesinmesin apa saja yang digunakan selama produksi, setting untuk tiap mesin tersebut, dan nilai target yang diharapkan dari pigura. Masing-masing mesin dibuat dalam instruksi produksi yang berbeda-beda. 5. Use case selesai. 3. Untuk jenis-jenis pigura yang sering dipesan, Kepala Pabrik tidak perlu melihat lagi ke dalam database melainkan langsung membuat instruksi produksi. - Kode instruksi tidak boleh ada yang sama - Masing-masing instruksi produksi harus memiliki kode produksi - Kode mesin dan setting mesin harus terisi - Nilai target pigura harus terisi dan berbentuk numerik Instruksi produksi tersimpan ke dalam sistem dan dapat dibaca ulang oleh Kepala Pabrik. Sumber : Hasil Analisa dan Pembahasan

22 295 Use Case Brief Description Pre Condition Basic Flow Alternative Flow Special Requirement Post Condition Tabel 4.70 Use Case Analysis Pelaporan Produk Cacat Pelaporan Produk Cacat Use case ini menjelaskan tentang bagaimana Bagian Pengemasan menggunakan instruksi produksi untuk memeriksa pigura-pigura yang sudah selesai diproduksi, kemudian mencatat data-data pigura yang tidak sesuai dengan nilai target. - Data-data karakteristik pigura sudah dibuat dengan lengkap dan disimpan dalam database pigura - Jadwal dan instruksi produksi sudah dibuat dengan lengkap oleh Kepala Pabrik dan disimpan dalam database 1. Bagian Produksi masuk ke layar Pelaporan Produk Cacat. 2. Bagian Pengemasan melihat instruksi produksi yang sudah disimpan dalam database berdasarkan kode produksinya masingmasing. 3. Pada instruksi produksi hanya tercantum kode pigura yang diproduksi. Oleh karena itu Bagian Pengemasan perlu melihat database berdasarkan kode pigura tersebut untuk mengetahui karakteristik pigura. 4. Bagian Pengemasan akan memasukkan data-data mengenai pigura yang cacat ke dalam sistem. Cacat bisa berupa ketidaksesuaian dengan karakteristik pigura (misalnya warna, jenis profil, dll) ataupun ketidaksesuaian dengan nilai target pigura. Sistem akan secara otomatis membuat kode cacat yang baru dan memasukkan tanggal cacat berdasarkan tanggal pada saat itu. 5. Apabila terdapat kategori cacat yang bersifat reusable, sistem akan mengirimkan sinyal kepada Bagian Produksi. Sinyal ini sebagai tanda bahwa terdapat produk yang harus diperbaiki. 6. Use case selesai. 2. Untuk jenis-jenis pigura yang sering dipesan, Bagian Pengemasan tidak perlu melihat lagi ke dalam database melainkan langsung memeriksa produk dan membuat laporan bila terjadi cacat - Kode karyawan yang memasukkan data-data cacat harus diisi - Kode produksi harus diisi untuk menunjukkan produksi mana yang menghasilkan pigura tersebut - Satu kode cacat hanya dapat menampung satu kode karyawan - Kategori cacat bertipe boolean, di mana hanya terdapat 2 pilihan yaitu reusable dan non-reusable - Jumlah cacat harus dimasukkan dalam satuan meter Data-data produk cacat tersimpan dalam database. Data tersebut sewaktuwaktu dapat dilihat kembali oleh General Manager dan Kepala Pabrik, serta dapat dicetak dalam bentuk laporan. Sumber : Hasil Analisa dan Pembahasan

23 296 Use Case Brief Description Pre Condition Basic Flow Alternative Flow Special Requirement Tabel 4.71 Use Case Analysis Pelaporan Hasil Rework Pelaporan Hasil Rework Use case ini menjelaskan tentang bagaimana Bagian Produksi membaca data-data pigura pigura yang harus diperbaiki dan melaporkan hasil perbaikannya. - Data-data pigura cacat sudah dimasukkan dengan lengkap dan disimpan dalam database pigura cacat - Data-data mesin dan sumber daya yang dibutuhkan sudah dibuat dengan lengkap dan disimpan dalam database mesin - Sistem memberikan sinyal kepada Bagian Produksi sebagai tanda bahwa ada pigura cacat yang harus diperbaiki 1. Bagian Produksi masuk ke layar Pelaporan Hasil Rework. 2. Bagian Produksi memeriksa database pigura cacat berdasarkan kode cacat untuk memeriksa apabila terdapat pigura cacat yang harus diperbaiki. 3. Sistem akan secara otomatis membuat kode rework dan memasukkan tanggal rework berdasarkan tanggal pada saat itu. 4. Setelah menerima pigura cacat dari Bagian Pengemasan, Bagian Produksi akan memeriksanya dan memasukkan penyebab cacat dan keterangannya ke dalam sistem. 5. Pada umumnya Bagian Produksi hanya mengenali berdasarkan nama mesin. Oleh karena itu Bagian Produksi akan melihat kode mesin berdasarkan namanya di database mesin. 6. Bagian Produksi akan memasukkan kode mesin yang digunakan ke dalam database rework. 7. Pada saat proses pengerjaan ulang selesai dilakukan, Bagian Produksi akan memasukkan durasi waktu yang sudah digunakan. 8. Sistem akan secara otomatis menghitung biaya kualitas yang ditimbulkan akibat kegiatan pengerjaan ulang yang sudah dilakukan. 9. Use case selesai. 5. Beberapa karyawan Bagian Produksi sudah lama bekerja di PT Decorindo Raya. Mereka sudah menghafal masing-masing nama mesin beserta kodenya dan tidak perlu lagi melihat database mesin. - Sebuah kode rework harus memiliki sebuah kode cacat - Kode karyawan yang melakukan rework harus diisi, di mana satu kode rework dapat melibatkan lebih dari satu orang karyawan - Penyebab cacat hanya dapat dipilih dari combo box dan terdapat 4 pilihan, yaitu Man, Machine, Method, dan Material - Durasi rework harus diisi dengan satuan jam dan dapat berupa desimal - Biaya kualitas dipengaruhi oleh beberapa faktor yaitu gaji karyawan, biaya listrik, dan biaya bahan baku dan dinyatakan dalam satuan Rupiah Sumber : Hasil Analisa dan Pembahasan

24 297 Tabel 4.71 Tabel Use Case Analysis Pelaporan Hasil Rework (lanjutan) Use Case Pelaporan Hasil Rework Post Data-data rework tersimpan dalam database. Data tersebut sewaktu-waktu Condition dapat dilihat kembali oleh General Manager dan Kepala Pabrik, serta dapat dicetak dalam bentuk laporan. Sumber : Hasil Analisa dan Pembahasan Tabel 4.72 Use Case Analysis Pencetakan Laporan Use Case Brief Description Pre Condition Pencetakan Laporan Use case ini menjelaskan tentang bagaimana General Manager dan Kepala Pabrik melihat data-data pigura cacat, bahan baku cacat, dan hasil rework kemudian mencetaknya sebagai laporan. - Data-data bahan baku cacat sudah dimasukkan dengan lengkap oleh Supervisor dan disimpan dalam database bahan baku cacat - Data-data pigura cacat sudah dimasukkan dengan lengkap oleh Bagian Pengemasan dan disimpan dalam database pigura cacat - Data-data rework sudah dimasukkan dengan lengkap oleh Bagian Produksi dan disimpan dalam database rework Sumber : Hasil Analisa dan Pembahasan

25 298 Tabel 4.72 Tabel Use Case Analysis Pencetakan Laporan (lanjutan) Use Case Pencetakan Laporan Basic Flow 1. General Manager dan Kepala Pabrik masuk ke layar Pencetakan Laporan. 2. Untuk mencetak laporan bahan baku cacat, General Manager dan Kepala Pabrik memasukkan tanggal pengiriman yang dikehendaki. Tanggal yang dimasukkan ada 2, yaitu tanggal awal dan akhir. 3. Sistem akan mencari data-data bahan baku cacat yang tersimpan di database bahan baku cacat kemudian mencetaknya dalam bentuk laporan dengan format yang dikehendaki oleh user. 4. Untuk mencetak laporan pigura cacat, General Manager dan Kepala Pabrik memasukkan tanggal cacat yang dikehendaki. Tanggal yang dimasukkan ada 2, yaitu tanggal awal dan tanggal akhir. 5. Sistem akan mencari data-data pigura cacat yang tersimpan di database pigura cacat kemudian mencetaknya dalam bentuk laporan dengan format yang dikehendaki oleh user. 6. Untuk mencetak laporan rework, General Manager dan Kepala Pabrik memasukkan tanggal rework yang dikehendaki. Tanggal yang dimasukkan ada 2, yaitu tanggal awal dan tanggal akhir. 7. Sistem akan mencari data-data rework yang tersimpan di database rework dalam jangka waktu yang dikehendaki, kemudian mencetaknya dalam bentuk laporan dengan format yang dikehendaki oleh user. Selain itu sistem juga akan secara otomatis menghitung dan menampilkan total biaya kualitas selama jangka waktu tersebut. 8. Use case selesai. Alternative 2. Selain berdasarkan tanggal pengiriman, General Manager dan Flow Kepala Pabrik juga dapat mencari data-data bahan baku cacat berdasarkan kode bahan baku. Special - Tanggal awal dan tanggal akhir harus diisi Requirement - Data-data laporan harus dapat disajikan dalam bentuk grafik, yaitu run chart, control chart, dan pareto diagram Post Data-data laporan tercetak. Data tersebut masih tersebut masih tersimpan Condition di dalam database dan sewaktu-waktu dapat dicetak ulang. Sumber : Hasil Analisa dan Pembahasan Use Case Diagram menggambarkan struktur aktor-aktor yang terlibat di dalam sistem informasi beserta proses bisnisnya. Masing-masing proses bisnis terdiri dari langkah-langkah yang dilakukan dengan berurutan, di mana langkah-langkah dari setiap proses bisnis dapat digambarkan melalui sequence diagram. Masing-masing proses

26 299 bisnis tersebut dapat dibagi lagi menjadi fungsi-fungsi yang lebih kecil, di mana tiap fungsi memiliki tingkat kompleksitas yang berbeda-beda dan digambarkan melalui function list. Oleh karena itu masing-masing sequence diagram juga memiliki function list yang berbeda-beda. Berikut adalah sequence diagram dan function list dari masingmasing use case yang terdapat pada gambar Gambar 4.50 Sequence Diagram Login Tabel 4.73 Function List Login Functions Complexity Type entrykodekaryawan Simple Read entrypassword Simple Read Sumber : Hasil Analisa dan Pembahasan

27 300 Gambar 4.51 Sequence Diagram Pengelolaan Password Tabel 4.74 Function List Pengelolaan Password Functions Complexity Type entrykodekaryawan Simple Read entrypassword Simple Read entrynewpassword Simple Update Sumber : Hasil Analisa dan Pembahasan

28 301 UI : Pengelolaan Data Konsumen Supplier General Manager open() searchkodekonsumen() getkodekonsumen() deletedatakonsumen() update() UI : Setup Konsumen setupdatakonsumen() open() adddatakonsumen() update() close() X searchkodesupplier() getkodesupplier() deletedatasupplier() update() UI : Setup Supplier setupdatasupplier() open() adddatakonsumen() update() close() close() X X Gambar 4.52 Sequence Diagram Pengelolaan Data Konsumen dan Supplier

29 302 Tabel 4.75 Function List Pengelolaan Data Konsumen dan Supplier Functions Complexity Type searchkodekonsumen Simple Read deletedatakonsumen Simple Update adddatakonsumen Simple Update searchkodesupplier Simple Read deletedatasupplier Simple Update adddatasupplier Simple Update Sumber : Hasil Analisa dan Pembahasan

30 Gambar 4.53 Sequence Diagram Pengelolaan Data Pigura, Bahan Baku, dan Mesin 303

31 304 Tabel 4.76 Function List Pengelolaan Data Pigura, Bahan Baku, dan Mesin Functions Complexity Type searchkodepigura Simple Read deletedatapigura Simple Update adddatapigura Simple Update searchkodebahanbaku Simple Read deletedatabahanbaku Simple Update adddatabahanbaku Simple Update searchkodemesin Simple Read deletedatamesin Simple Update adddatamesin Simple Update Sumber : Hasil Analisa dan Pembahasan

32 305 UI : Penerimaan Pesanan Pesanan Konsumen Pigura General Manager open() searchkodepesanan() getkodepesanan() deletedatapesanan() update() UI : Setup Pesanan setupdatapesanan() open() searchkodekonsumen() getkodekonsumen() searchkodepigura() getkodepigura() adddatapesanan() update() close() close() X X Gambar 4.54 Sequence Diagram Penerimaan Pesanan

33 306 Tabel 4.77 Function List Penerimaan Pesanan Functions Complexity Type searchkodekonsumen Simple Read searchkodepigura Medium Read updatedatapesanan Simple Update Sumber : Hasil Analisa dan Pembahasan UI : Pelaporan Bahan Baku Cacat Bahan Baku Bahan Baku Cacat Supervisor open() searchkodebahanbaku() getkodebahanbaku() UI : Setup Bahan Baku Cacat setupdatabahanbakucacat() open() adddatabahanbakucacat() update() close() close() X X Gambar 4.55 Sequence Diagram Pelaporan Bahan Baku Cacat Tabel 4.78 Function List Pelaporan Bahan Baku Cacat Functions Complexity Type searchkodebahanbaku Simple Read adddatabahanbakucacat Simple Update Sumber : Hasil Analisa dan Pembahasan

34 307 UI : Pembuatan Jadwal Produksi Pigura Jadwal Produksi Kepala Pabrik open() searchkodepigura() getkodepigura() searchkodeproduksi() getkodeproduksi() UI : Setup Jadwal Produksi setupdatajadwalproduksi() open() adddatajadwalproduksi() update() close() close() X X Gambar 4.56 Sequence Diagram Pembuatan Jadwal Produksi Tabel 4.79 Function List Pembuatan Jadwal Produksi Functions Complexity Type searchkodepigura Simple Read searchkodeproduksi Simple Read adddatajadwalproduksi Simple Update Sumber : Hasil Analisa dan Pembahasan

35 308 UI : Pembuatan Instruksi Produksi Jadwal Produksi Instruksi Produksi Mesin Kepala Pabrik open() searchkodeproduksi() getkodeproduksi() searchkodeinstruksi() getkodeinstruksi() UI : Setup Instruksi Produksi setupdatainstruksiproduksi() open() searchkodemesin() getkodemesin() adddatainstruksiproduksi() update() close() close() X X Gambar 4.57 Sequence Diagram Pembuatan Instruksi Produksi Tabel 4.80 Function List Pembuatan Instruksi Produksi Functions Complexity Type searchkodeproduksi Simple Read searchkodeinstruksi Simple Read searchkodemesin Simple Read adddatainstruksiproduksi Simple Update Sumber : Hasil Analisa dan Pembahasan

36 309 UI : Pelaporan Produk Cacat Pigura Cacat Pigura Instruksi Produksi Bagian Pengemasan open() searchkodepiguracacat() getkodepiguracacat() UI : Pigura viewdatapigura() open() searchkodepigura() getkodepigura() close() UI : Instruksi Produksi X viewdatainstruksi() open() searchkodeinstruksi() getkodeinstruksi() close() UI : Setup Pigura Cacat X setupdatapiguracacat() open() adddatapiguracacat() update() close() close() X X Gambar 4.58 Sequence Diagram Pelaporan Produk Cacat

37 310 Tabel 4.81 Function List Pelaporan Produk Cacat Functions Complexity Type searchkodepiguracacat Simple Read searchkodepigura Simple Read searchkodeinstruksi Simple Read adddatapiguracacat Simple Update Sumber : Hasil Analisa dan Pembahasan Gambar 4.59 Sequence Diagram Pelaporan Hasil Rework

38 311 Tabel 4.82 Function List Pelaporan Hasil Rework Functions Complexity Type searchkodecacat Simple Read searchkoderework Simple Read searchkodemesin Simple Read adddatarework Simple Update countbiayakualitas Complex Compute Sumber : Hasil Analisa dan Pembahasan Seperti terlihat dalam tabel 4.82, use case Pelaporan Hasil Rework mengandung sebuah fungsi yang bersifat kompleks, yaitu countbiayakualitas. Oleh karena itu fungsi tersebut harus dijabarkan lagi menggunakan operation specification sebagai berikut :

39 312 Name Category Purpose Input data Condition Effect Algorithm Tabel 4.83 Operation Specification Fungsi countbiayakualitas countbiayakualitas - read - Active - update x Passive x compute - signal Menghitung jumlah biaya kualitas yang ditimbulkan akibat suatu proses pengerjaan ulang terhadap pigura yang cacat. kode_mesin, durasi_rework, biaya_listrik_per_jam, gaji_per_jam, kode_bahan_baku, harga_bahan_baku, bahan_baku_per_jam kode_rework terisi Hasil perhitungan biaya kualitas ini akan dimasukkan ke dalam database rework sesuai kode_rework yang bersangkutan. Sistem akan menghitung biaya kualitas dengan 3 variabel, yaitu biaya listrik, biaya bahan baku, dan gaji karyawan. Jumlah biaya kualitas didapatkan dengan perhitungan sebagai berikut : Biaya listrik = (biaya_listrik_per_jam 1 + biaya_listrik_per_jam biaya_listrik_per_jam x )*durasi_rework bahan_baku_per_jam1 * harga_bahan_baku1 Biaya bahan baku= ( + volume _ diterima bahan_baku_per_jam 2 * harga_bahan_baku volume _ diterima bahan_baku_per_jam x * harga_bahan_baku...+ volume _ diterima x *durasi_rework Gaji karyawan = gaji_per_jam *durasi_rework Biaya kualitas = biaya listrik + biaya bahan baku + gaji karyawan kode_mesin : string durasi_rework : integer biaya_listrik_per_jam : integer Data gaji_per_jam : integer Structure kode_bahan_baku : string harga_bahan_baku : integer bahan_baku_per_jam : integer Placement Rework Involved Mesin, Bahan Baku, Bagian Produksi Triggering Event Pelaporan Produk Cacat Sumber : Hasil Analisa dan Pembahasan x )

40 313 UI : Pencetakan Laporan Bahan Baku Bahan Baku Cacat Pigura Pigura Cacat Jadwal Produksi Rework General Manager, Kepala Pabrik open() searchkodebahanbaku() getkodebahanbaku() searchtanggalpengiriman() getdatabahanbakucacat() plotrunchartbahanbaku() createrunchartbahanbaku() plotpchart() createpchart() UI : Laporan Bahan Baku Cacat printdatabahanbakucacat() create() close() searchkodepigura() X getkodepigura() searchtanggalcacat() getdatapiguracacat() getjumlahproduksi() plotrunchartpigura() plotuchart() createrunchartpigura() createuchart() UI : Laporan Pigura Cacat printdatapiguracacat() create() close() searchtanggalrework() getdatarework() X plotparetodiagramrework() createparetodiagramrework() plotrunchartrework() createrunchartrework() plotxbarchart() UI : Laporan Rework createxbarchart() printdatarework() create() close() close() X X Gambar 4.60 Sequence Diagram Pencetakan Laporan

41 314 Tabel 4.84 Function List Pencetakan Laporan Functions Complexity Type searchkodebahanbaku Simple Read searchtanggalpengiriman Simple Read plotrunchartbahanbaku Medium Compute plotpchart Complex Compute printdatabahanbakucacat Simple Read, Signal searchkodepigura Simple Read searchtanggalcacat Simple Read plotrunchartpigura Medium Compute plotuchart Complex Compute printdatapiguracacat Simple Read, Signal searchtanggalrework Simple Read plotparetodiagramrework Complex Compute plotrunchartrework Medium Compute plotxbarchart Complex Compute printdatarework Simple Read, Signal Sumber : Hasil Analisa dan Pembahasan Untuk beberapa fungsi yang bersifat kompleks, masing-masing akan dijabarkan ke dalam operation specification sebagai berikut :

42 315 Tabel 4.85 Operation Specification Fungsi plotpchart Name Category Purpose Input data Condition Effect plotpchart - read - Active - update x Passive x compute - signal Menghitung peta kendali P yang menggambarkan proporsi jumlah bahan baku yang cacat terhadap jumlah bahan baku yang diterima. kode_bahan_baku, volume_diterima, kode_bahan_baku_cacat, jumlah_cacat, kode_supplier, tanggal_pengiriman kode_bahan_baku_cacat terisi Hasil perhitungan peta kendali P ini akan ditampilkan dalam bentuk grafik pada user interface Laporan Bahan Baku Cacat. jumlah cacat CL = volume diterima UCL = CL + 3 CL *(1- CL) volume diterima per hari Algorithm LCL = CL - 3 CL *(1- CL) volume diterima per hari Data Structure P = jumlah cacat per hari volume diterima per hari Selanjutnya nilai P akan dibandingkan dengan nilai UCL dan LCL. Bila ada nilai P yang lebih besar dari UCL atau lebih kecil dari LCL, maka sistem akan memberikan sinyal peringatan kepada user melalui laporan yang dicetak. kode_bahan_baku : string kode_bahan_baku_cacat : string jumlah_cacat : integer kode_supplier : string tanggal_pengiriman : string volume_diterima : integer user interface Laporan Bahan Baku Cacat Bahan Baku, Bahan Baku Cacat Placement Involved Triggering Pelaporan Bahan Baku Cacat Event Sumber : Hasil Analisa dan Pembahasan

43 316 Tabel 4.86 Operation Specification Fungsi plotuchart Name Category Purpose Input data Condition Effect plotuchart - read - Active - update x Passive x compute - signal Menghitung peta kendali U yang menggambarkan proporsi jumlah pigura yang cacat terhadap jumlah produksi. kode_produksi, kode_pigura, jumlah_pigura, kode_cacat, tanggal_cacat, kategori_cacat, jumlah_cacat kode_cacat terisi Hasil perhitungan peta kendali U ini akan ditampilkan dalam bentuk grafik pada user interface Laporan Pigura Cacat. jumlah cacat CL = jumlah pigura UCL = CL + 3 CL jumlah produksi per hari Algorithm LCL = CL 3 CL jumlah produksi per hari Data Structure U = jumlah cacat per hari jumlah produksi per hari Selanjutnya nilai U akan dibandingkan dengan nilai UCL dan LCL. Bila ada nilai U yang lebih besar dari UCL atau lebih kecil dari LCL, maka sistem akan memberikan sinyal peringatan kepada user melalui laporan yang dicetak. kode_produksi : string kode_pigura : string jumlah_pigura : integer kode_cacat : string tanggal_cacat : date kategori_cacat : string jumlah_cacat : integer user interface Laporan Pigura Cacat Pigura Cacat, Jadwal Produksi Placement Involved Triggering Pelaporan Pigura Cacat Event Sumber : Hasil Analisa dan Pembahasan

44 317 Name Category Purpose Input data Condition Effect Algorithm Tabel 4.87 Operation Specification Fungsi plotparetodiagramrework plotparetodiagramrework - read - Active - update x Passive x compute - signal Menghitung persentase jumlah cacat untuk masing-masing penyebab cacat kemudian menggambarkan persentase kumulatif dalam bentuk diagram Pareto. kode_rework, tanggal_rework, penyebab_cacat, jumlah_cacat kode_rework terisi Hasil perhitungan diagram Pareto ini akan ditampilkan dalam bentuk grafik pada user interface Laporan Rework. Data-data jumlah cacat akan dikelompokkan berdasarkan penyebab cacatnya. Kemudian masing-masing kelompok tersebut akan dihitung jumlahnya dan dihitung persentasenya terhadap jumlah cacat total. jumlah cacat per penyebab cacat persentase cacat = jumlah cacat total Masing-masing kelompok cacat tersebut akan diurutkan dari yang persentasenya terbesar hingga terkecil, kemudian dihitung persentase kumulatifnya secara keseluruhan. persentase kumulatif n = n persentase cacat t= 1 kode_rework : string Data Structure tanggal_rework : date penyebab_cacat : string jumlah_cacat : integer Placement user interface Laporan Rework Involved Rework, Pigura Cacat Triggering Event Pelaporan Hasil Rework Sumber : Hasil Analisa dan Pembahasan t

45 318 Tabel 4.88 Operation Specification Fungsi plotxbarchart Name Category Purpose Input data Condition Effect Algorithm - Active x Passive plotxbarchart - read - update x compute - signal Menghitung peta kendali X yang menggambarkan kendali perusahaan terhadap data-data biaya kualitas yang timbul akibat kegiatan pengerjaan ulang. kode_rework, tanggal_rework, biaya_kualitas kode_rework terisi Hasil perhitungan peta kendali X ini akan ditampilkan dalam bentuk grafik pada user interface Laporan Rework. R = biaya kualitas terbesar per hari - biaya kualitas terkecil per hari jumlah R R = jumlah hari jumlah biaya kualitas CL = jumlah hari UCL = CL + (0.577 * R) LCL = CL (0.577 * R) Data Structure Selanjutnya data biaya kualitas per hari akan dibandingkan dengan nilai UCL dan LCL. Bila ada data biaya kualitas yang lebih besar dari UCL atau lebih kecil dari LCL, maka sistem akan memberikan sinyal peringatan kepada user melalui laporan yang dicetak. kode_rework : string tanggal_rework : date biaya_kualitas : integer user interface Laporan Rework Rework Placement Involved Triggering Pelaporan Hasil Rework Event Sumber : Hasil Analisa dan Pembahasan Selanjutnya berdasarkan sequence diagram, interaksi antara user dengan sistem informasi usulan akan digambarkan dalam bentuk sketsa yang disebut navigation diagram. Karena terdapat 5 jenis user yang terlibat dengan sistem dan masing-masing memiliki event yang berbeda-beda, maka masing-masing user memiliki navigation diagram yang berbeda-beda.

46 Gambar 4.61 Navigation Diagram untuk General Manager 319

47 Gambar 4.62 Navigation Diagram untuk Kepala Pabrik 320

48 Gambar 4.63 Navigation Diagram untuk Supervisor 321

49 Gambar 4.64 Navigation Diagram untuk Bagian Produksi 322

50 323 Gambar 4.65 Navigation Diagram untuk Bagian Pengemasan Architectural Design Architectural design bertujuan untuk menggambarkan struktur dari sistem informasi usulan yang akan digunakan di PT Decorindo Raya. Pertama-tama, ditetapkan kriteria yang harus dipenuhi oleh sistem informasi tersebut.

51 324 Tabel 4.89 Prioritas Kriteria pada Sistem Informasi Pengendalian Kualitas Usulan Criterion Very Important Important Usable V Secure V Efficient Correct V Reliable V Maintainable V Testable V Flexible V Comprehensible V Reusable V Portable Interoperable Sumber : Hasil Analisa dan Pembahasan Less Important V V Irrelevant V Easily Fulfiled Berikut adalah penjelasan dari masing-masing kriteria tersebut : - Usable. Sistem informasi yang akan dibangun harus dapat diimplementasikan dengan cepat dan mudah. Kecepatan dalam implementasi sistem dibutuhkan khususnya dalam mendukung fungsi-fungsi seperti penyampaian pesanan konsumen dari General Manager kepada Kepala Pabrik, pendokumentasian kegiatan pengendalian kualitas di perusahaan, serta penyimpanan data-data perusahaan yang penting lainnya. Sedangkan kemudahan implementasi dibutuhkan mengingat sebagian besar karyawan perusahaan belum terbiasa untuk mengoperasikan komputer. - Secure. Seperti sistem yang berjalan di perusahaan-perusahaan lain pada umumnya, keamanan adalah hal yang mutlak. Keamanan yang dimaksudkan di sini mencakup beberapa hal. Di antaranya adalah pembatasan hak akses, di mana hanya orang-orang tertentu yang boleh mengakses data-data perusahaan. Dalam hal ini, General Manager dan Kepala Pabrik adalah orang yang berhak untuk

52 325 melihat data-data internal perusahaan seperti data konsumen, supplier, dan bahan baku. Sistem yang dibangun harus menunjang pembatasan hak akses tersebut dengan password untuk masing-masing user di mana password tersebut hanya diketahui oleh orang yang bersangkutan dan pihak administrator. Selain itu sistem informasi yang dibangun juga harus aman dari pihak-pihak luar yang tidak berhubungan dengan proses bisnis perusahaan. Hal ini disebabkan karena sistem yang dibangun harus diakses melalui internet sehingga lebih rawan untuk diakses secara ilegal oleh pihak-pihak yang tidak bertanggung jawab. - Efficient. Kriteria efisiensi dari sisi ekonomis tidak terlalu penting bagi perusahaan karena tujuan utama dari perusahaan adalah meningkatkan kualitas produk-produk yang dihasilkannya. Hal itu dapat tercapai apabila didukung oleh sistem informasi yang dirancang dengan baik dan dapat berfungsi secara maksimal. - Correct. Dalam sistem informasi yang dibangun, terdapat beberapa pengolahan data. Pengolahan data ini harus sesuai dengan kebutuhan dari pihak manajemen perusahaan, khususnya yang berhubungan dengan kegiatan pengendalian kualitas. Informasi-informasi yang dibutuhkan di antaranya perhitungan biaya kualitas, jumlah cacat, dan sebagainya. Informasi-informasi tersebut digunakan oleh pihak manajemen perusahaan sebagai bahan analisa dan pendukung pengambilan keputusan. Karena itu data-data yang diolah dan dicetak harus akurat dan mencerminkan kondisi yang sebenarnya di pabrik. - Reliable. Sistem yang dibangun memiliki fungsi-fungsi tertentu yang dapat diakses oleh beberapa karyawan yang bersangkutan. Fungsi-fungsi tersebut dapat berupa melihat, menambah, mengubah, dan menghapus isi database, serta

53 326 mencetak laporan. Untuk mendukung proses bisnis perusahaan, maka masigmasing fungsi tersebut harus dapat dijalankan dan menghasilkan output yang sesuai dengan hasil rancangan sebelumnya. - Maintainable. Agar dapat digunakan dalam jangka panjang, maka sistem informasi yang dibangun harus dapat dimaintain dengan mudah. Terlebih lagi karena sistem tersebut menyimpan data-data perusahaan yang penting dan krusial bagi proses bisnis perusahaan seperti data-data supplier, konsumen, pesanan, dan sebagainya. Kemudahan yang dimaksudkan berarti bahwa sistem dapat diperbaiki dengan cepat dan dengan biaya yang relatif rendah. - Testable. Untuk memastikan bahwa sistem informasi yang dibangun dapat berfungsi sebagaimana mestinya dan sesuai dengan kebutuhan perusahaan, maka sistem tersebut harus dapat diuji. Pengujian ini dilakukan sebelum sistem benarbenar diimplementasikan dalam perusahaan sehingga dapat mengantisipasi terjadinya error yang dapat merugikan perusahaan nantinya. - Flexible. Berdasarkan situasi dan kondisi bisnis yang dinamis dan berkembang dengan pesat, maka sistem informasi yang dibangun juga harus fleksibel dan dapat beradaptasi terhadap situasi dan kondisi tersebut. Fleksibilitas dari sistem dapat dilihat dari biaya dan waktu yang diperlukan untuk melakukan modifikasi terhadap sistem. Semakin sedikit biaya dan waktu yang diperlukan, semakin tinggi tingkat fleksibilitas dari sistem tersebut. - Comprehensible. Selama ini kegiatan pengendalian kualitas yang dilakukan di PT Decorindo Raya dilakukan secara manual. Penggunaan komputer hanya sebatas pencetakan surat jalan, faktur, dan dokumen-dokumen standar lainnya. Hal ini menunjukkan bahwa sebagian besar karyawan yang ada belum terbiasa

54 327 untuk bekerja dengan bantuan komputer. Karena itu tampilan dari sistem informasi usulan harus dibuat sesederhana mungkin, dan fitur-fitur yang tersedia harus dapat digunakan dengan mudah tanpa membutuhkan training khusus - Reusable. Selain pengendalian kualitas, sistem keseluruhan yang berjalan di perusahaan sangat luas dan kompleks. Dengan kata lain sistem informasi yang dibangun hanya merupakan sebagian kecil dari sistem tersebut. Untuk dapat berfungsi secara maksimal, maka sistem informasi tersebut harus dapat diintegrasikan dengan sistem-sistem perusahaan lainnya. Walaupun sementara ini sistem lainnya masih sebagian besar dijalankan secara manual, namun tidak menutup kemungkinan bahwa suatu saat semua sistem di perusahaan akan terkomputerisasi. Karena itu sistem informasi yang dibangun harus dapat mendukung adanya kemungkinan tersebut. - Portable. Seperti yang sudah dijelaskan sebelumnya, sistem informasi usulan akan dibangun berbasiskan internet. Berhubungan dengan perkembangan internet yang sangat pesat, maka sistem informasi yang dibangun harus dapat berjalan dengan baik walaupun digunakan dalam platform yang berbeda-beda. Walaupun demikian, kriteria ini kurang penting karena penggunaan komputer yang masih minimal di perusahaan sehingga kemungkinan terjadinya perpindahan platform sangat kecil. - Interoperable. Kriteria ini berfokus pada biaya yang diperlukan untuk mengintegrasikan sistem informasi usulan dengan sistem informasi yang sudah ada di perusahaan. Saat ini penggunaan komputer di PT Decorindo Raya masih sangat minimal. Sebagian besar sistem masih dijalankan secara manual. Dengan kata lain, sistem informasi yang dibangun tidak akan diintegrasikan dengan

55 328 sistem-sistem lainnya dalam waktu dekat ini. Karena itu kriteria ini dinyatakan tidak berhubungan. Berdasarkan kriteria yang sudah ditentukan untuk sistem informasi usulan, selanjutnya dibuat arsitektur untuk menggambarkan sistem informasi yang dibangun. Arsitektur tersebut dibedakan menjadi 2 bagian, yaitu : - Arsitektur komponen Arsitektur komponen bertujuan untuk memudahkan dalam memahami sistem, mengatur pengerjaan desain, dan menggambarkan stabilitas dalam konteks sistem. Arsitektur komponen digambarkan dalam bentuk component diagram. Dalam diagram tersebut, masing-masing komponen dari sistem usulan digambarkan dalam bentuk packages yang saling berhubungan. Tiap packages dapat memiliki dari user interface (UI), function (F), dan system interface (SI). Dari hasil analisa ditentukan bahwa jenis arsitektur yang digunakan pada sistem informasi usulan adalah centralized data. Dalam tipe arsitektur ini masingmasing user hanya memiliki user interface dan function, sedangkan semua database disimpan dalam server secara terpusat. Alasan pemilihan tipe arsitektur ini adalah proses pembuatannya yang mudah dan cepat diimplementasikan ke dalam sistem perusahaan. Selain itu data-data yang ditampilkan juga lebih konsisten karena hanya disimpan di satu tempat. Akan tetapi jenis arsitektur ini juga memiliki beberapa resiko. Di antaranya adalah koneksi ke database yang lambat apabila ada beberapa user sekaligus yang mengakses database secara bersamaan. Resiko lainnya adalah resiko kehilangan data. Karena hanya disimpan di satu tempat terpusat, maka diperlukan back up secara rutin sebagai cadangan apabila data yang asli rusak atau terhapus.

56 329 <<Component>> Client General Manager <<Component>> Client Kepala Pabrik User Interface User Interface Function Function <<Component>> Web Server System Interface System Interface System Interface <<Component>> Client Bagian Produksi Model <<Component>> Client Supervisor User Interface User Interface Function Function System Interface System Interface <<Component>> Client Bagian Pengemasan User Interface Function System Interface Gambar 4.66 Component Diagram Sistem Informasi Pengendalian Kualitas Usulan

57 330 - Arsitektur proses Setelah membuat arsitektur komponen, selanjutnya perlu dibuat arsitektur proses yang lebih menggambarkan bentuk fisik daripada bentuk logis dari sistem. Arsitektur komponen digambarkan daam bentuk deployment diagram. Client General Manager Client Kepala Pabrik User Interface User Interface Function Function Active Object System Interface Web Server System Interface Active Object System Interface Printer General Manager Printer Kepala Pabrik Model Client Bagian Produksi Client Supervisor User Interface User Interface Function Function System Interface System Interface Client Bagian Pengemasan User Interface Function System Interface Gambar 4.67 Deployment Diagram Sistem Informasi Pengendalian Kualitas Usulan

58 331 Dengan memperhatikan deployment diagram di atas, terlihat bahwa arsitektur proses memiliki bentuk yang sama dengan arsitektur komponen. Perbedaannya hanyalah pada arsitektur proses, terdapat hubungan antara user dengan processor eksternal. Hubungan ini terjadi dengan bantuan active object (AO) sebagai perantaranya. Dalam sistem usulan, processor eksternal yang berhubungan adalah printer. Sesuai dengan use case yang dibuat sebelumnya, printer digunakan untuk kegiatan pencetakan laporan. Kegiatan ini hanya dapat dilakukan oleh Kepala Pabrik dan General Manager. Oleh karena itu hanya kedua user tersebut yang memiliki hubungan terdahadap printer melalui active object sebagai perantara Component Design Setelah arsitektur dari sistem informasi usulan dibuat, perancangan sistm dilanjutkan pada tahap component design. Kegiatan perancangan komponen ini dilakukan melalui 2 tahap : - perancangan model component Model component menggambarkan problem domain dalam class, objek, dan sruktur serta perilaku mereka berdasarkan konsep pemrograman berorientasi objek. Hasil akhir dari aktivitas ini adalah sebuah class diagram yang sudah direvisi.

59 332 Gambar 4.68 Revised Class Diagram Sistem Informasi Pengendalian Kualitas Usulan

60 333 Revised class diagram merupakan hasil perubahan dari class diagram sebelumnya. Perubahan yang terjadi hanya sebatas penambahan detil class pesanan, mesin, instruksi produksi, dan rework. Hubungan antara class dengan detilnya dinyatakan dalam hubungan agregasi. Sebagai akibat dari penambahan detil class tersebut, beberapa atribut yang dimiliki class induknya akan dipindahkan ke class turunannya. Selain itu class-class karyawan juga dihilangkan karena class-class tersebut bukan merupakan bagian dari sistem informasi usulan, melainkan objek yang mengakses dan mengoperasikan sistem tersebut. Sehingga lebih tepat apabila class-class karyawan ditempatkan sebagai actor di dalam application domain. - perancangan function component Function component dirancang dengan cara merancang fungsi sebagai operasi berdasarkan jenisnya. Dari kegiatan ini dihasilkan operasi-operasi yang dapat mengimplementasikan fungsionalitas sistem informasi usulan.

61 334 Gambar 4.69 Function Class Placement Sistem Informasi Pengendalian Kualitas Usulan

62 335 Function component di atas dirancang berdasarkan function class placement karena terdapat beberapa operasi yang sifatnya umum namun melibatkan oleh dua class atau lebih. Operasi-operasi tersebut di antaranya pencetakan laporan dan pengelolaan data. Pencetakan laporan dapat dilakukan terhadap class bahan baku cacat, pigura cacat, dan rework. Sedangkan operasi pengelolaan data dapat dilakukan terhadap class konsumen, supplier, pigura, bahan baku, dan mesin. Kelima class tersebut sama-sama dikelola, akan tetapi actor yang melakukannya berbeda. Class konsumen dan supplier dikelola oleh General Manager, sedangkan class pigura, bahan baku, dan mesin dikelola oleh Kepala Pabrik. Walaupun berbeda actornya namun tiap-tiap pengelolaan data tersebut memiliki fungsi-fungsi yang sama Pengembangan Aplikasi Sistem Pada tahap perancangan sistem informasi, dilakukan analisa terhadap permasalahan-permasalahan yang terjadi di PT Decorindo Raya khususnya yang berhubungan dengan kegiatan pengendalian kualitas. Dari berbagai masalah tersebut, selanjutnya diusulkan suatu sistem informasi yang dapat membantu meningkatkan kinerja dari perusahaan. Sistem informasi diusulkan berfungsi sebagai media komunikasi antara pihak kantor dengan pihak pabrik PT Decorindo Raya khususnya dalam pengendalian kualitas. Selain itu sistem informasi tersebut juga memfasilitasi kegiatan dokumentasi terhadap jenis-jenis cacat dan kegiatan rework yang ditimbulkan, sehingga dapat dilihat ulang untuk tujuan analisa. Pada subbab sebelumnya, dijelaskan rancangan dari sistem informasi usulan dengan menggunakan diagram UML. Selanjutnya dilakukan pengembangan aplikasi sistem untuk mengubah hasil rancangan menjadi sebuah sistem informasi yang nyata

63 336 dan benar-benar dapat digunakan di perusahaan. Karena akan dijalankan berbasis web, pengembangan aplikasi sistem ini dilakukan dengan ASP.NET. Berikut adalah tampilantampilan layar dari sistem informasi yang dibuat beserta penjelasannya. Gambar 4.70 Window Login Merupakan layar yang pertama kali muncul pada saat sistem informasi dijalankan. Pada layar ini, user harus memasukkan user name dan password mereka masing-masing, kemudian mengklik tombol enter untuk masuk ke dalam sistem. Untuk alasan keamanan, setiap user hanya boleh salah memasukkan password sebanyak maksimal 3 kali. Apabila lebih dari 3 kali, maka sistem akan memblock hak akses user itu untuk sementara dan tidak dapat digunakan sebelum diaktifkan kembali oleh administrator.

64 337 Gambar 4.71 Window Menu Utama Merupakan layar utama yang tampil setelah user berhasil melakukan login. Pada menu di sebelah kanan atas, terdapat 3 pilihan yaitu welcome untuk kembali ke menu utama, change password untuk merubah password user, dan logout untuk keluar dari sistem. Sedangkan di sebelah kiri terdapat kategori-kategori fitur yang dapat digunakan oleh user, di antaranya security untuk mengatur privilege dan user, data processing untuk pengelolaan data-data perusahaan, dan report untuk menghasilkan laporan bagi General Manager dan Kepala Pabrik. Di bagian bawah terdapat ruang kosong yang digunakan untuk menampilkan signal-signal yang berhubungan dengan tanggal login dan harus diperhatikan oleh user yang bersangkutan. Sinyal tersebut dapat berupa pesanan, jadwal produksi, atau pigura cacat yang baru diinput ke sistem pada hari itu.

65 338 Gambar 4.72 Window Pengelolaan Password Merupakan layar yang digunakan user untuk mengubah passwordnya masingmasing. Apabila user tidak jadi mengubah passwordnya, dapat menekan tombol cancel. Untuk alasan keamanan, maka password masing-masing user hanya diketahui oleh mereka sendiri dan dienkripsi sebelum disimpan ke database.

66 339 Gambar 4.73 Window Pengelolaan Privilege Layar ini digunakan untuk mengatur privilege yang digunakan dalam sistem informasi usulan. Privilege merupakan pembatasan hak akses user terhadap sistem sesuai dengan pembagian tugasnya masing-masing. Masing-masing privilege memiliki nama dan deskripsinya masing-masing. Layar ini bersifat rahasia dan hanya dapat diakses oleh administrator.

67 340 Gambar 4.74 Window Setup Privilege Merupakan kelanjutan dari layar pengelolaan privilege, di mana pada layar ini administrator dapat memasukkan jenis-jenis privilege baru dan mengatur pembatasan hak aksesnya masing-masing. Untuk melakukannya, administrator tinggal mengaktifkan checkbox yang terdapat di kolom sebelah kanan.

68 341 Gambar 4.75 Window Pengelolaan User Layar ini digunakan untuk mengelola user-user mana saja yang dapat mengakses sistem beserta jenis privilegenya masing-masing. Seperti yang terlihat pada gambar di atas, masing-masing user juga memiliki status. Apabila statusnya aktif, maka mereka masih dapat mengakses sistem dan menggunakan fitur-fitur yang ada. Sedangkan apabila statusnya tidak aktif, maka hak aksesnya sudah diblock dan untuk sementara tidak dapat mengakses sistem.

69 342 Gambar 4.76 Window Setup User Merupakan kelanjutan dari layar pengelolaan user, di mana administrator dapat menambahkan user baru dan menentukan jenis privilegenya masing-masing. Pada saat suatu user baru dibuat, password awal akan ditentukan oleh administrator. Setelah itu user dapat mengubah passwordnya masing-masing.

70 343 Gambar 4.77 Window Pengelolaan Karyawan Layar ini digunakan untuk melihat data-data karyawan yang bekerja di PT Decorindo Raya. Masing-masing karyawan dibedakan jabatannya berdasarkan jenis privilegenya masing-masing. Pada gambar di atas terlihat bahwa masing-masing karyawan memiliki salary per jam yang dinyatakan dalam satuan Rupiah.

71 344 Gambar 4.78 Window Setup Karyawan Merupakan kelanjutan dari layar pengelolaan karyawan, di mana administrator dapat menambahkan data-data karyawan baru. Setelah selesai mengisi data, tombol add ditekan dan data-data tersebut akan tersimpan di dalam database.

72 345 Gambar 4.79 Window Pengelolaan Data Merupakan layar yang digunakan untuk mengelola data-data perusahaan. Datadata tersebebut mencakup data konsumen, supplier, bahan baku, pigura, dan mesin. Sesuai dengan pembagian tugas, maka General Manager dapat mengelola data konsumen dan supplier. Sedangkan Kepala Pabrik dapat mengelola data bahan baku, pigura, dan mesin.

73 346 Gambar 4.80 Window Setup Data Merupakan kelanjutan dari layar pengelolaan data, di mana user dapat menambahkan data-data baru. Setelah semua terisi, tombol add ditekan dan data-data tersebut tersimpan ke dalam database.

74 347 Gambar 4.81 Window View Data Pada gambar 4.79 terlihat bahwa di sebelah kanan masing-masing item data terdapat 3 tombol. Yang paling kiri berbentuk kaca pembesar dan bila ditekan akan menampilkan layar view data. Layar ini hanya berfungsi untuk menampilkan data secara lengkap. Pada layar ini user tidak dapat melakukan update ataupung menghapus isi data, karena itu semua field yang tersedia bersifat tidak aktif.

75 348 Gambar 4.82 Window Update Data Selain tombol view, di sebelah kanan dari masing-masing item data juga terdapat tombol yang berbentuk pensil. Apabila tombol tersebut ditekan, maka layar update data akan muncul. Pada layar ini semua field bersifat aktif dan semua data dapat diubah-ubah oleh user, kecuali kode data itu sendiri. Kode data merupakan primary key sehingga tidak dapat diubah-ubah lagi, kecuali dihapus secara keseluruhan.

76 349 Gambar 4.83 Window Pengelolaan Bahan Baku Cacat Layar ini digunakan melihat data-data bahan baku yang cacat. Pada saat pertama kali layar ini ditampilkan, sistem akan langsung menampilkan semua data-data bahan baku yang cacat. Kemudian user dapat menggunakan fasilitas search untuk mencari data-data bahan baku yang ingin dicari berdasarkan kode bahan baku atau nama bahan baku.

77 350 Gambar 4.84 Window Setup Bahan Baku Cacat Merupakan kelanjutan dari layar pengelolaan bahan baku cacat. Layar ini digunakan oleh Supervisor untuk memasukkan data-data bahan baku cacat yang baru. Tanggal cacat akan secara otomatis terisi pada tanggal hari itu, tapi user dapat menyesuaikannya dengan data sebenarnya. Pada saat tombol add ditekan, maka datadata tersebut akan tersimpan di database.

78 351 Gambar 4.85 Window Pengelolaan Pigura Cacat Layar ini berfungsi untuk menampilkan data-data pigura cacat yang ada di database. Sama seperti pada pengelolaan bahan baku cacat, layar ini juga dilengkapi dengan fitur search untuk mencari data-data yang dibutuhkan. Pencarian data pigura cacat dapat dilakukan berdasarkan kode cacat, kode produksi, atau kode karyawan.

79 352 Gambar 4.86 Window Setup Pigura Cacat Merupakan kelanjutan dari layar pengelolaan pigura cacat. Layar ini digunakan oleh karyawan Bagian Pengemasan untuk memasukkan data-data pigura yang cacat. Tanggal cacat akan secara otomatis terisi pada tanggal hari itu, tapi user dapat menyesuaikannya dengan data sebenarnya. Pada saat tombol add ditekan, maka datadata tersebut akan tersimpan di database.

80 353 Gambar 4.87 Window Pengelolaan Rework Layar ini menampilkan data-data kegiatan rework yang sudah dilakukan selama ini. Layar ini juga dilengkapi dengan fitur search untuk mencari data-data yang dibutuhkan. Pencarian data rework dapat dilakukan berdasarkan tanggal rework atau kode cacat.

81 354 Gambar 4.88 Window Setup Rework Merupakan kelanjutan dari layar pengelolaan rework. Layar ini digunakan oleh karyawan Bagian Produksi untuk melaporkan data-data rework untuk setiap pigura yang cacat. Tanggal rework akan secara otomatis terisi pada tanggal hari itu, tapi user dapat menyesuaikannya dengan data sebenarnya. Satu kegiatan rework dapat menggunakan berbagai jenis mesin dengan durasi yang berbeda-beda oleh karyawan yang berbedabeda juga. Karena itu layar ini dilengkapi dengan list yang menampilkan detil dari masing-masing mesin, durasi, dan karyawan yang bersangkutan dengan rework tersebut. List ini dapat ditambah ataupun dihapus sebelum disimpan ke dalam database.

82 355 Gambar 4.89 Window Pengelolaan Pesanan Layar ini digunakan untuk melihat data-data pesanan konsumen yang masuk ke Pt Decorindo Raya. Layar ini memiliki fitur search untuk mencari data-data yang dibutuhkan. Pencarian data pesanan dapat dilakukan berdasarkan kode pesanan, kode konsumen, atau tanggal pesanan.

83 356 Gambar 4.90 Window Setup Pesanan Merupakan kelanjutan dari layar pengelolaan pesanan. Layar ini digunakan oleh General Manager untuk memasukkan data-data pesanan baru. Dalam satu pesanan bisa terdapat lebih dari satu jenis pigura dengan jumlah yang berbeda-beda. Karena itu layar ini juga dilengkapi dengan list untuk menampung item-item pesanan tersebut. Isi dari list tersebut dapat ditambah atau dihapus sebelum disimpan ke dalam database.

84 357 Gambar 4.91 Window Pengelolaan Jadwal Produksi Layar ini digunakan untuk melihat jadwal-jadwal produksi yang selama ini sudah dilakukan di PT Decorindo Raya. Untuk memudahkan dalam melihat data, layar ini juga dilengkapi dengan fitur search di mana user dapat mencari data-data jadwal produksi berdasarkan kode produksi, tanggal produksi, atau kode pigura.

85 358 Gambar 4.92 Window Setup Jadwal Produksi Merupakan kelanjutan dari layar pengelolaan jadwal produksi. Layar ini digunakan oleh Kepala Pabrik untuk memasukkan data-data jadwal produksi yang baru. Karena produksi langsung dilakukan dalam jumlah banyak, maka satu jadwal produksi hanya dibuat untuk satu kode pigura.

86 359 Gambar 4.93 Window Pengelolaan Instruksi Produksi Layar ini digunakan untuk melihat data-data instruksi produksi yang sudah dibuat untuk masing-masing jadwal produksi. Untuk memudahkan pencarian data, layar ini dilengkapi dengan fitur search untuk mencari data-data instruksi produksi berdasarkan kode instruksi atau kode produksi.

87 360 Gambar 4.94 Window Setup Instruksi Produksi Layar ini merupakan kelanjutan dari layar pengelolaan instruksi produksi. Layar ini digunakan oleh Kepala Pabrik untuk memasukkan data-data instruksi produksi yang baru. Masing-masing instruksi produksi dibuat berdasarkan jadwal produksi yang sudah ada. Dalam suatu kegiatan produksi, digunakan berbagai mesin dengan setting dan nilai target yang berbeda-beda. Karena itu layar ini juga dilengkapi dengan list untuk menampung jenis-jenis mesin yang digunakan beserta setting dan nilai targetnya. Isi dari list ini dapat ditambah atau dihapus sebelum disimpan ke database.

88 361 Gambar 4.95 Window View Laporan Layar ini dapat digunakan oleh General Manager dan Kepala Pabrik. Tujuannya adalah melihat laporan dari kinerja perusahaan selama ini, khususnya yang berhubungan dengan cacat yang terjadi selama proses produksi. Karena itu laporan dibedakan menjadi 3 jenis, yaitu laporan bahan baku cacat, laporan pigura cacat, dan laporan rework. Masing-masing dapat laporan dicari berdasarkan tanggal terjadinya cacat, kemudian ditampilkan dalam bentuk grafik untuk mempermudah dalam analisa data-data tersebut. Grafik yang dapat disajikan di antaranya run chart dan control chart. Sedangkan untuk laporan rework dilengkapi dengan pareto diagram untuk melihat persentase biaya kualitas berdasarkan penyebab cacat yaitu Man, Machine, Method, dan Material.

89 362 Gambar 4.96 Window Print Laporan Layar merupakan kelanjutan dari layar view laporan. Layar ini muncul pada saat tombol export diklik, dan langsung menampilkan laporan yang sedang aktif dalam bentuk tabel. Laporan ini disajikan dengan bantuan Microsoft Excel, dan dapat disesuaikan oleh user sebelum dicetak. Selain merancang layar user interface, pada tahap ini juga dilakukan perancangan terhadap database yang digunakan untuk mendukung penyimpanan dan pengolahan data-data dan informasi dari sistem informasi yang dibuat. Database tersebut dibuat menggunakan software Microsoft Access. Berikut adalah hasil perancangan database.