PERAWATAN PESAWAT
PADA MERPATI MAINTENANCE FACILITY
TUGAS AKHIR
Oleh:
Nama : YENDY RACHMATULLOH
NIM : 06.41010.0204 Program : S1 (Strata Satu) Jurusan : Sistem Informasi
SEKOLAH TINGGI
MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA
2012
STIKOM
RANCANG BANGUN APLIKASI ADMINISTRASI PERAWATAN PESAWAT
PADA MERPATI MAINTENANCE FACILITY
TUGAS AKHIR
Diajukan sebagai salah satu syarat menyelesaikan Program Sarjana Komputer
Oleh:
Nama : YENDY RACHMATULLOH
NIM : 06.41010.0204 Program : S1 (Strata Satu) Jurusan : Sistem Informasi
SEKOLAH TINGGI
MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA
2012
STIKOM
Kesuksesan merupakan bagian kecil dari hasil usaha kita, dan bagian besar dari ridho Allah SWT
STIKOM
Kupersembahkan untukmu: Papah Mamah Abang tercinta Seluruh keluarga yang selalu mendukungku Teman- teman yang selalu memberikan semangat
STIKOM
ix DAFTAR ISI
Halaman
ABSTRAK ... vi
KATA PENGANTAR ... vii
DAFTAR ISI ... ix
DAFTAR TABEL ... xi
DAFTAR GAMBAR ... xiv
DAFTAR LAMPIRAN ... xx
BAB I PENDAHULUAN ... 1
1.1 Latar Belakang Masalah ... 1
1.2 Perumusan Masalah ... 2
1.3 Batasan Masalah ... 2
1.4 Tujuan... ... 4
1.5 Sistematika Penulisan ... 4
BAB II LANDASAN TEORI ... 6
2.1 Pesawat ... 6
2.2 Perawatan Pesawat ... 6
2.3 Entitas dalam Perawatan Pesawat ... 10
2.4 Administrasi Perawatan Pesawat... ... 13
2.5 Desain Sistem ... 15
2.6 Interaksi Manusia dan Komputer ... 16
2.6.1Konsep Dasar Interaksi Manusia dan Komputer ... 16
2.6.2Interaksi Manusia dan Komputer pada Web ... 17
2.7 Testing Software ... 20
STIKOM
x
Halaman
2.7.1Test Case ... 21
2.7.2 Black Box Testing ... 23
BAB III PERANCANGAN SISTEM ... 25
3.1 Analisis Sistem ... 25
3.2 Perancangan Sistem ... 31
3.2.1 System Flow ... 31
3.2.2 DataFlow Diagram ... 41
3.2.3 Entity Relationship Diagram ... 49
3.2.4 Perancangan Input / Output ... 68
3.2.5 Perancangan User Level ... 117
3.3 Perancangan Evaluasi dan Uji Coba ... 118
BAB IV IMPLEMENTASI DAN EVALUASI ... 121
4.1 Kebutuhan Aplikasi ... 121
4.1.1 KebutuhanPerangkat Keras ... 121
4.1.2 KebutuhanPerangkat Lunak ... 121
4.2 Implementasi ... 119
4.3 Evaluasi dan Uji Coba Fungsionalitas Aplikasi ... 168
BAB V PENUTUP... 177
5.1 Kesimpulan ... 177
5.2 Saran ...177
DAFTAR PUSTAKA ... 178
LAMPIRAN ... 179
STIKOM
vi
Pesawat udara selama beroperasi pasti mempunyai jadwal untuk perawatan. Perawatan ini harus dilakukan karena setiap komponen mempunyai batas usia tertentu sehingga komponen tersebut harus diganti. Selain itu, komponen juga harus diperbaiki bila ditemukan telah mengalami kerusakan. Merpati Maintenance Facility adalah pusat perawatan pesawat yang melayani
customer dari dalam dan luar negeri. Dalam administrasi pada proses perawatan
pesawat ini terdapat kesulitan menyangkut pencatatan dan pembuatan paket pekerjaan, pencatatan setiap pekerjaan yang telah dilakukan, status setiap pekerjaan yang ada, serta work in progress report untuk setiap pesawat.
Berdasarkan uraian diatas, maka diperlukan aplikasi administrasi yang terkomputerisasi untuk membantu mengatasi permasalahan seperti pencatatan proses-proses administratif dan monitoring status setiap detil pekerjaan yang ada. Aplikasi administrasi ini juga dapat memberikan laporan-laporan mengenai perawatan pesawat yang sedang berjalan seperti pekerjaan yang harus dilakukan, serta work in progress report untuk setiap pesawat.
Dengan Aplikasi Administrasi Perawatan Pesawat ini diperoleh kesimpulan bahwa aplikasi ini mampu memberikan data pendukung untuk project
planner dalam memonitor perkembangan pekerjaan perawatan untuk setiap
pesawat serta memberikan laporan mengenai status setiap pekerjaan yang telah direncanakan.
Kata kunci: aplikasi administrasi, perawatan pesawat
STIKOM
1 BAB I PENDAHULUAN
1.1Latar Belakang Masalah
Merpati Maintenance Facility (MMF) adalah Strategic Business Unit dari PT. Merpati Nusantara Airlines yang bisnis utamanya merupakan pusat perawatan pesawat. Informasi yang cepat dan akurat untuk engineer dan semua yang terlibat dalam proses bisnis pekerjaan perawatan pesawat merupakan sesuatu yang vital sebagai sarana pengawasan terhadap kegiatan perawatan pesawat yang dilakukan, dan informasi yang akurat bisa didapatkan dari proses pencatatan transaksional yang baik. Saat ini aplikasi administratif semakin banyak digunakan untuk otomasi operasional proses bisnis dan pencatatan untuk membantu berjalannya alur proses administrasi serta menyediakan data repository.
Aircraft quotation, task card dan job order, serta progress report dari
pesawat yang sedang dikerjakan baru dapat diketahui oleh bagian marketing,
planner, dan engineer setelah melalui beberapa tahapan proses yang dilakukan
oleh beberapa bagian yang berbeda. Setiap bagian memiliki tanggung jawab, otoritas dan fungsi yang berbeda terhadap semua dokumen dalam alur kerja perawatan pesawat. Proses pencatatan yang bertahap dan dilakukan secara manual akan menjadi masalah ketika dokumen atau informasi yang diperlukan oleh bagian planner masih belum selesai diproses oleh bagian production/engineer, padahal output dari bagian production harus menjadi input di bagian planner untuk dilakukan proses perhitungan progress report lebih lanjut. Output dari proses yang dilakukan oleh planner juga akan menjadi input bagian marketing.
STIKOM
Proses perhitungan untuk progress report dan rekap data berupa fisik yang sangat banyak secara manual membutuhkan ketelitian serta waktu yang lama.
Berdasarkan uraian di atas, maka diperlukan rancang bangun aplikasi administrasi perawatan pesawat untuk membantu menyelesaikan permasalahan yang ada. Dengan adanya aplikasi administrasi diharapkan pencatatan dapat dilakukan dengan konsep paperless atau dengan basis data dan dapat membantu pihak engineer, planner atau PPC, dan marketing untuk berbagi dan mengetahui informasi penting tentang progress report dari tiap pesawat yang masuk ke hangar dan segala status job order baik yang belum atau yang telah dikerjakan oleh
engineer.
1.2Perumusan Masalah
Berdasarkan latar belakang di atas, maka dapat dirumuskan permasalahan yaitu bagaimana merancang dan membangun aplikasi administrasi perawatan pesawat pada Merpati Maintenance Facility.
1.3. Pembatasan Masalah
Batasan masalah adalah sebagai berikut:
1. Aplikasi menggunakan data dari Merpati Maintenance Facility pada semester kedua tahun 2011 sampai semester pertama tahun 2012.
2. Aplikasi administrasi perawatan pesawat mengolah data tentang aircraft
quotation yang dibuat oleh bagian marketing, task card yg dibuat oleh bagian supporting dalam hal ini adalah planner/PPC, aircraft job order yang dibuat
oleh planner/PPC, dan release certificate yang dibuat oleh engineer yang
STIKOM
merupakan acuan bahwa suatu pekerjaan telah selesai dan ditutup oleh
engineer di hangar.
3. Aplikasi administrasi perawatan pesawat meliputi proses sebagai berikut:
a. Maintenance customer, engineer’s legal (rooster), task card, aircraft’s
part number.
b. Proses pembuatan quotation dan repair order (RO). c. Proses pembuatan task card.
d. Proses pembuatan job order dan work pack. e. Proses pengambilan job order oleh engineer. f. Proses inspeksi job order oleh engineer. g. Proses job close.
h. Proses job pending.
i. Job order status monitoring.
j. Work in progress monitoring.
4. Aplikasi administrasi perawatan pesawat tidak mengolah data surat kontrak atau perjanjian proses perawatan pesawat anta pihak customer dan MMF. 5. Aplikasi administrasi perawatan pesawat tidak mengolah data material yang
diperlukan dalam proses perawatan pesawat.
6. Aplikasi administrasi perawatan pesawat tidak memberikan output yang berhubungan dengan penjadwalan dan manajemen sumber daya, baik sumber daya manusia ataupun sumber daya yang lainnya.
7. Aplikasi administrasi perawatan pesawat hanya mengelola administrasi pekerjaan yang berhubungan dengan bagian quality, marketing, supporting/planner, production.
STIKOM
8. Aplikasi administrasi perawatan pesawat tidak mengolah data keuangan dan finansial.
1.4. Tujuan
Tujuan penelitian ini adalah Merancang dan Membangun Aplikasi Administrasi Perawatan Pesawat pada Merpati Maintenance Facility.
1.5. Sistematika Penulisan
BAB I : PENDAHULUAN
Bab ini menjelaskan mengenai latar belakang permasalahan dari sistem yang dibangun, perumusan masalah, pembatasan masalah, tujuan dan sistematika penulisan.
BAB II : LANDASAN TEORI
Bab ini berisi penjelasan teori-teori dasar yang berkaitan dengan aplikasi yang dibangun.
BAB III : PERANCANGAN SISTEM
Bab ini berisi tentang penjelasan langkah-langkah yang ditempuh dalam penyelesaian permasalahan, meliputi analisis permasalahan,
document flow, computerized document flow, data flow diagram
(DFD), entity relationship diagram (ERD) dan desain input
ouput.
BAB IV : IMPLEMENTASI DAN EVALUASI
Bab ini berisi tentang implementasi dan evaluasi sistem yang dibangun apakah telah sesuai dengan tujuan yang diharapkan.
STIKOM
BAB V : PENUTUP
Bab ini berisi uraian kesimpulan dan saran yang dapat diambil sesuai dengan hasil pembahasan.
STIKOM
6 BAB II
LANDASAN TEORI
2.1 Pesawat
Pesawat terbang atau pesawat udara atau kapal terbang atau cukup pesawat saja adalah kendaraan yang mampu terbang di atmosfer atau udara. Pesawat terbang yang lebih berat dari udara disebut aerodin, yang masuk dalam kategori ini adalah autogiro, helikopter, girokopter dan pesawat bersayap tetap.
Pesawat bersayap tetap umumnya menggunakan mesin pembakaran dalam yang berupa mesin piston (dengan baling-baling) atau mesin turbin (jet atau turboprop) untuk menghasilkan dorongan yang menggerakkan pesawat, lalu pergerakan udara di sayap menghasilkan gaya dorong ke atas, yang membuat pesawat ini bisa terbang. Sebagai pengecualian, pesawat bersayap tetap juga ada yang tidak menggunakan mesin, misalnya glider, yang hanya menggunakan gaya gravitasi dan arus udara panas. Helikopter dan autogiro menggunakan mesin dan sayap berputar untuk menghasilkan gaya dorong ke atas, dan helikopter juga menggunakan mesin untuk menghasilkan dorongan ke depan.
2.2 Perawatan Pesawat
Setiap pesawat udara selama beroperasi pasti mempunyai jadwal untuk perawatan. Perawatan ini harus dilakukan karena setiap komponen mempunyai batas usia tertentu sehingga komponen tersebut harus diganti. Selain itu, komponen juga harus diperbaiki bila ditemukan telah mengalami kerusakan. Secara garis besar, program perawatan dapat dibagi menjadi dua kelompok besar,
STIKOM
yaitu perawatan preventif dan korektif. Perawatan preventif adalah perawatan yang mencegah terjadinya kegagalan komponen sebelum komponen tersebut rusak. Sedangkan perawatan korektif adalah perawatan yang memperbaiki komponen yang rusak agar kembali ke kondisi awal.
Perawatan preventif dapat dibagi menjadi 2 jenis yaitu:
i. Perawatan periodik atau hard time, merupakan perawatan yang dilakukan berdasarkan batas waktu dari umur maksimum suatu komponen pesawat. Dengan kata lain, perawatan ini merupakan perawatan pencegahan dengan cara mengganti komponen pesawat meskipun komponen tersebut belum mengalami kerusakan.
ii. Perawatan on-condition, merupakan perawatan yang memerlukan inspeksi untuk menentukan kondisi suatu komponen pesawat. Setelah itu ditentukan tindakan selanjutnya berdasarkan hasil inspeksi tersebut. Bila ada gejala kerusakan, komponen tersebut dapat diganti bila alasan-alasan teknik dan ekonominya memenuhi.
Perawatan korektif dikenal pula dengan nama condition monitoring yaitu perawatan yang dilakukan setelah ditemukan kerusakan pada suatu komponen, dengan cara memperbaiki komponen tersebut. Bila cara perbaikan tidak dapat dilakukan dengan alasan teknik maupun ekonomi, maka harus dilakukan penggantian.
Perawatan pesawat biasanya dikelompokkan berdasarkan interval yang sepadan dalam paket-paket kerja atau disebut dengan clustering. Hal ini dilakukan agar tugas perawatan lebih mudah, efektif dan efisien. Interval yang dijadikan pedoman untuk melaksanakan paket-paket tersebut adalah sebagai berikut:
STIKOM
i. Flight Hours
Merupakan interval inspeksi yang didasarkan pada jumlah jam operasional suatu pesawat terbang.
ii. Flight Cycle
Merupakan interval inspeksi yang didasarkan pada jumlah takeoff-landing yang dilakukan suatu pesawat terbang. Satu kali takeoff-landing dihitung satu cycle. iii. Calendar Time
Merupakan interval inspeksi yang dilakukan sesuai dengan jadwal tertentu. Dari jumlah tugas perawatan atau inspeksi yang dilaksanakan, maintenance dapat dibagi dalam minor maintenance seperti transit check, before departure
check, daily check, weekly check dan heavy maintenance seperti A-Check,
B-Check , C-B-Check dan D-B-Check. Minor maintenance:
i. Transit Check
Inspeksi ini harus dilaksanakan setiap kali setelah melakukan penerbangan saat transit di station mana pun. Operator biasanya memeriksa pesawat untuk memastikan bahwa pada pesawat tidak terdapat satu pun kerusakan struktur, semua sistem berfungsi dengan sebagaimana mestinya, dan servis yang diharuskan telah dilakukan.
ii. Before Departure Check
Inspeksi ini harus dilakukan sedekat mungkin sebelum tiap kali pesawat berangkat beroperasi, maksimal dua jam sebelumnya.
STIKOM
iii. Daily Check (Overnight Check)
Pemeriksaan ini harus dilakukan satu kali dalam jangka waktu 24 jam setelah
daily check sebelumnya dilakukan. Setiap hari pesawat telah diprediksi akan ground stop minimal selama empat jam. Inspeksi ini mencakup pemeriksaan
komponen, pemeriksaan keliling pesawat secara visual untuk mendeteksi ada atau tidaknya ketidaksesuaian, melakukan pengamanan lebih lanjut, dan pemeriksaan sistem operasional.
iv. Weekly Check
Pemeriksaan ini harus telah dilakukan dalam tujuh hari penanggalan. Termasuk dalam inspeksi ini adalah before departure check.
Aircraft maintenance checks adalah periode pemeriksaan yang harus
dilakukan pada pesawat setelah penggunaan pesawat untuk jangka waktu tertentu, digunakan sebagai parameter interval untuk heavy maintenance yang meliputi A-Check, B-A-Check, C-A-Check, dan D-Check.
A-Check dilakukan kira-kira setiap satu bulan. Pemeriksaan ini biasanya dilakukan hingga 10 jam. Pemeriksaan ini bervariasi, bergantung pada tipe pesawat, jumlah siklus (takeoff dan landing dianggap sebagai siklus pesawat, atau jam terbang sejak pemeriksaan terakhir. Perawatan pesawat jenis ini hanya melakukan pemeriksaan pada pesawat terbang untuk memastikan kelaikan mesin, sistem-sistem, komponen-komponen, dan struktur pesawat untuk beroperasi. Untuk Boeing 737 Classic A-check dilakukan setelah 300 jam terbang, Airbus A340 setelah 450 jam terbang, Boeing 747-200 setelah 650 jam.
B-Check bergantung pada masing-masing jenis pesawat, pemeriksaan berkisar antara 9 hingga 28 jam ground time dan biasanya dilakukan kira-kira
STIKOM
setiap lima bulan. Perawatan pesawat dalam skala kecil ini hanya meliputi proses pembersihan, pelumasan, penggantian ban apabila sudah aus, penggantian baterai, dan inspeksi struktur bagian dalam.
C-Check harus dilakukan setelah 15-18 bulan. Bergantung pada tipe pesawat, pemeriksaan ini bisa memakan waktu 10 hari. Perawatan pesawat tipe ini merupakan inspeksi komprehensif termasuk bagian-bagian yang tersembunyi, sehingga kerusakan dan keretakan di bagian dalam dapat ditemukan. Untuk Boeing 737-300 dan 737-500, inspeksi ini dilakukan setiap 4.000 FH. Untuk Boeing 737-400 dilakukan setiap 4.500 FH. Sedangkan untuk Boeing 747-400 dilakukan setiap 6.400 FH dan Airbus A-330-341 dilakukan setiap 21 bulan.
D-Check disebut overhaul. Pemeriksaan jenis ini adalah perawatan yang paling detail, untuk pesawat Boeing 737-300, 737-400 dan 737-500, inspeksi ini dilakukan setiap 24.000 FH. Sedangkan untuk Boeing 747-400 dilakukan setiap 28.000 FH dan untuk Airbus A-330-341 dilakukan setiap 6 tahun. Pada pengecekan jenis ini pesawat diinspeksi secara keseluruhan, biasanya memakan waktu 1 bulan.
2.3 Entitas dalam Perawatan Pesawat
Pada proses perawatan pesawat, ada beberpa entitas yang terlibat didalamnya baik yang secara langsung akan berinteraksi dengan objek, ataupun entitas yang terlibat secara tidak langsung.
1. Line Maintenance (LM). Bagian ini biasanya adalah divisi dari perusahaan customer yang memiliki pesawat yang akan dilakukan proses perawatan.
Divisi LM harus ada di semua perusahaan aviasi, dan harus
STIKOM
bertanggungjawab dalam pengelolaan kebutuhan perawatan semua pesawat yang dimiliki perusahaan.
2. Customer. Sering disebut juga sebagai techrep oleh pihak yang mengadakan
pearawatan pesawat (maintenance facility). Customer adalah perusahaan, atau perwakilan perusahaan, atau perorangan yang memiliki pesawat dan menyerahkan proses perawatannya ke maintenance facility.
3. Marketing. Bagian ini yang akan berhadapan langsung dengan customer.
Komunikasi antara customer dan maintenance facility akan dilakukan melalui divisi marketing.
4. Production planner. Bagian ini adalah penentu dan pengawas terhadap
jalannya proses perawatan pesawat. Planner yang menentukan pekerjaan apa saja yang harus dilakukan oleh engineer di bagian production sesuai dengan komplain dan permintaan dari customer melalui marketing.
5. Production. Bagian ini berisi sekumpulan engineer dengan berbagai bidang
keahlian yang akan mengerjakan detil-detil pekerjaan perawatan pesawat sesuai dengan lingkup yang telah ditentukan oleh planner. Engineer sendiri terdiri dari 3 tingkatan, yaitu supporting staff, inspector, dan certified staff. 6. Material Store. Bagian ini merupakan divisi yang bertugas untuk mengelola
sirkulasi material pesawat yang terlibat. Mulai dari material yang turun dari pesawat, material yang akan dipasang di pesawat, hingga material yang dibutuhkan untuk penggantian. Material Store akan berkomunikasi intensif dengan bagian purchasing sehingga setiap ada material yang diminta/dibutuhkan maka bagian purchasing akan mendapat instruksi untuk melakukan pengadaan terhadap material tersebut.
STIKOM
7. Tool Store. Merupakan divisi yg khusus mengelola semua kebutuhan tool
atau peralatan untuk melakukan perawatan pesawat.
8. Purchasing. Bagian ini merupakan divisi yang harus melakukan pengadaan
terhadap seluruh benda/alat/spare part yang diperlukan dalam kegiatan perawatan pesawat.
9. Finance. Bagian keuangan dalam organisasi perawatan pesawat, divisi ini
yang mengelola semua kebutuhan biaya langsung dan tidak langsung yang ada dalam proses perawatan pesawat.
10. Quality Assurance. Bagian memiliki 2 tugas pokok, yaitu menjamin kualitas
hasil produksi yang dilakukan oleh engineer dan melakukan kontrol terhadap jalannya peraturan yang telah ditetapkan pada proses bisnis perawatan pesawat. Quality Assurance juga mengelola otorisasi engineer yang bekerja di bagian production sehingga setiap detil pekerjaan yang dilakukan oleh
engineer sesuai dengan bidang keahliannya masing-masing, quality assurance harus menjadi filter untuk mencegah orang yang tidak berwenang
untuk mengerjakan sesuatu yang seharusnya tidak boleh dikerjakan.
Struktur organisasi perawatan pesawat dan komponen pesawat yang ada pada Merpati Maintenance Facility dapat dilihat pada gambar 2.1.
STIKOM
Gambar 2.1. Struktur Organisasi pada Merpati Maintenance Facility
2.4 Administrasi Perawatan Pesawat
Administrasi perawatan pesawat (AZ) terdiri dari berbagai pekerjaan dan tugas yang harus dilakukan untuk menjaga kegiatan perawatan pesawat berjalan aman dan efisien. Setiap bagian yang terlibat dengan fungsinya masing-masing saling berkomunikasi dengan intensif dalam pekerjaan administrasi perawatan pesawat.
Beberapa tugas dan kewajiban yang dilakukan oleh AZ adalah: a. Penjadwalan pemeriksaan pesawat udara.
b. Menjaga tren grafik kehandalan sistem kerja pesawat.
c. Mengatur dan menjalankan daftar pustaka, laporan, dan data yang berhubungan dengan perawatan pesawat.
STIKOM
d. Mengeluarkan perintah kerja dan merilis sertifikat inspeksi.
e. Menjalankan tugas administrasi seperti dokuemtasi dan pencetakan. f. Pembuatan laporan hasil perawatan pesawat dan korespondensi. g. Mempertahankan logbooks mesin pesawat dan catatan yang terkait.
Lingkungan kerja untuk pekerjaan administrasi pesawat biasanya merupakan lingkungan kantor yang bersih dan nyaman. Tempat kerja bervariasi tergantung dimana mereka ditugaskan, di darat atau di pantai maupun laut. Tugas mereka memerlukan kerjasama yang erat antar sesama pekerja administrasi perawatan pesawat di tiap bagian yang berbeda-beda fungsinya.
Dokumen dan form yang ada pada kegiatan administrasi perawatan pesawat antara lain:
a. Quotation, berisi work order dari customer, di dalamnya terdiri dari beberapa repair order atau biasa disebut subject.
b. Work pack, adalah paket/kumpulan pekerjaan yang harus dilakukan oleh engineer dalam proyek perawatan pesawat. Work pack terdiri dari pekerjaan routine dan non-routine. Routine berisi basic task card, SIP (Structure Inspection Programme), dan CPCP (Corrosion Prevention and Control Programme). Non-routine berisi EO (Engineering Order), AD-SB (Airwhorthiness Directive-Service Bulletin), HT-CRR (Hard Time-Component Replacement), dan SI (Special Instruction).
c. Task card, adalah standar prosedur atau pekerjaan yang harus dilakukan oleh engineer dalam perawatan pesawat. Setiap jenis pesawat disertai Basic Task Card yang dibuat oleh vendor.
STIKOM
d. Job Order, menunjukkan suatu task card yang harus dikerjakan oleh engineer
dalam perawatan pesawat.
e. CRS (Certificate of Release to Service), merupakan sertifikat yang
dikerluarkan oleh Maintenance Facility sebagai tanda bahwa suatu proyek perawatan pesawat telah selesai. CRS dibuat dan dipertanggungjawabkan secara penuh oleh engineer dengan tingkat certifying staff. CRS diberikan kepada customer saat proyek perawatan telah selesai.
Administrasi perawatan pesawat juga memiliki batasan-batasan terhadap
engineer maupun semua orang yang terlibat pada setiap prosesnya, otorisasi
dalam perawatan pesawat adalah:
a. Supporting Staff, engineer dengan tingkat ini hanya dapat melakukan
pekerjaan berdasar job order yang telah ditentukan.
b. Inspector, engineer dengan tingkat ini selain dapat melakukan pekerjaan
berdasar job order yang telah ditentukan, engineer ini juga dapat melakukan inskpeksi terhadap pekerjaan-pekerjaan tersebut.
c. Certified Staff, engineer tingkat ini dapat melakukan pekerjaan semua
jenjang, mulai dari pengerjaan job order biasa, melakukan inspeksi, melakukan RII Release, hingga membuat CRS.
2.5 Desain Sistem
Setelah tahap analisis dan perancangan sistem selesai dilakukan, maka analis sistem telah mendapatkan gambaran dengan jelas apa yang harus dikerjakan. Lalu tahap selanjutnya adalah desain sistem.
STIKOM
Desain sistem adalah tahap setelah analisis dari siklus pengembangan sistem pendefinisian dari kebutuhan-kebutuhan fungsional dan persiapan untuk rancang bangun implementasi, menggambarkan bagaimana suatu sistem dibentuk.
“Pada tahap desain secara umum, komponen-komponen sistem informasi
dirancang dengan tujuan untuk dikomunikasikan dengan pemakai sistem, bukan pemrogram. Komponen sistem informasi yang didesain adalah model, input,
output, database, teknologi, dan kontrol” (Jogiyanto, 2003:211).
Analisis sistem dapat mendesain model dari sistem informasi yang diusulkan dalam bentuk physical system dan logical model. Bagan alir sistem (system flowchart) merupakan alat yang tepat untuk menggambarkan physical
system. Simbol-simbol bagan alir sistem ini menunjukkan secara tepat arti
fisiknya seperti simbol terminal, harddisk, dan laporan-laporan.
Logical model dari sistem informasi lebih menjelaskan kepada pemakai
sistem bagaimana nantinya fungsi-fungsi pada sistem informasi secara logika akan bekerja. Logical model dapat digambarkan dengan diagram arus data (data flow
diagram). Arus data pada data flow diagram dapat dijelaskan dengan kamus data
atau data dictionary. Sketsa dari physical system dapat menjelaskan kepada pemakai sistem bagaimana nantinya sistem secara fisik akan diterapkan.
Maka dari itulah pada akhirnya physical system dan logical model sangat diperlukan di tahap desain sistem ini, karena sangat berguna untuk menjelaskan kepada pemakai, pemrogram dan ahli teknik yang terlibat tentang kerja sistem.
2.6 Interaksi Manusia dan Komputer
Menurut Shanti (2005), istilah Interaksi Manusia dan Komputer (Human
Computer Interaction) sebenarnya telah lama dipelajari oleh para ahli pada masa
STIKOM
perang dunia kedua dengan munculnya keperluan untuk menghasilkan sistem persenjataan yang efektif sehingga dipelajarilah interaksi manusia dengan mesin pada saat itu. Hal ini kemudian mendorong munculnya ketertarikan para peneliti di bidang ini dan membentuk suatu perkumpulan peneliti di bidang ergonomi (Ergonomi Research Society).
2.6.1 Konsep Dasar Interaksi Manusia dan Komputer
Komputer dan peralatan terkait lainnya harus dirancang dengan pemahaman bahwa penggunanya memiliki tujuan atau tugas khusus dan ingin menggunakannya sesuai dengan karakteristik tugas yang akan diselesaikan. Pada kenyataannya, masih sering kita jumpai kesalahan-kesalahan kecil dalam
pengoperasian suatu sistem yang teraplikasi. Sebagai contoh, menu pilihan “Save”
dan “Delete” diklasifikasikan dalam satu kelompok yang sama sebagai “Operasi
File”, jika user kurang teliti dan memilih menu “Delete” padahal yang dimaksud
adalah pilihan “Save” ditambah dengan tidak adanya mekanisme
konfirmasi/dialog dalam eksekusi proses tersebut maka hal ini dapat merugikan user.
Menurut Shanti (2005) dalam jurnalnya, komputer diperkenalkan sebagai
“user friendly” dan “easy to use”. Agar dua hal tersebut dapat terpenuhi maka perancang sistem perlu mengetahui bagaimana berpikir dalam lingkup tugas user yang sesungguhnya untuk kemudian menerjemahkannya ke dalam sistem.
Tidak mudah merancang sistem yang konsisten dan handal yang dapat mengantisipasi semua ketidaktelitian user. Interface bukanlah aspek yang dapat dibuat pada saat akhir, desainnya merupakan satu kesatuan dengan keseluruhan
sistem. Desainer tidak hanya membrikan suatu tampilan yang “cantik” namun
STIKOM
juga harus dapat mendukung pekerjaan yang dilakukan oleh user dan dapat menghindari kesalahan-kesalahan kecil.
2.6.2 Interaksi Manusia dan Komputer pada Web
Hal-hal yang perlu diperhatikan dalam proses mendesain/menyusun suatu aplikasi berbasis web adalah:
1. Balance
Menyeimbangkan penyusunan komponen di layar. 2. Symmetry
Berbeda dengan balance, kesimetrisan sebuah desain menimbang tiap element di tiap sisi layar.
3. Regularity
Penciptaan sebuah desain dengan ukuran normal dan standarisasi dalam sebuah aplikasi, yaitu meliputi penggunaan ukuran hinga ke jarak antar komponen yang terdapat dalam layar.
4. Predictability
Dengan menyusun komponen yang sederhana dan telah umum digunakan hingga mudah ditebak pengguna yang baru pertama kali menggunakan aplikasi. 5. Sequentiality
Penglihatan yang tertuju pada suatu tempat yang dianggap atraktif. Secara intuitif, pengihatan menuju ke :
a) Kontrol yang lebih terang. b) Element yang terisolasi. c) Gambar daripada teks.
STIKOM
d) Warna yang menyolok. e) Kontrol yang lebih besar. f) Bentuk yang tidak standar. 6. Economy
Memberi style pada font, warna, serta pengaturan yang tidak berlebihan. 7. Unity
Tidak memberi jarak yang berlebih pada sebuah desain aplikasi. 8. Proportion
Sebuah desain yang dianggap proporsional tidak selalu berbentuk bujur sangkar, tetapi harus memiliki perbandingan yang sesuai dengan ukuran layar secara jamak.
9. Simplicity
Melakukan desain yang mengesankan keseragaman sehingga desain terlihat sederhana. Kesederhanaan dapat ditimbulkan dengan melakukan proses
alignment yan tidak terlalu banyak serta bentuk komponen yang umum.
10.Groupings
Pengelompokan komponen berdasarkan fungsi serta penataan visual yang efisien.
Adapun beberapa elemen desain web yang perlu dipahami agar desain web yang dbuat berhasil secara artistik dan juga memenuhi kaidah usability serta user
friendly, adalah:
1. Line
STIKOM
Bukan hanya sekedar garis yang ditampilkan dalam sebuah web, tetapi garis yang secara tidak langsung mampu membentuk batasan antar elemen dan juga kesan sebuah obyek dua dimensi.
2. Color
Khusus untuk pemilihan warna dalam desain web, disarankan untuk memilih warna dalam web safe pallete yang hanya terdiri dari 216 warna.
3. Volume
Diasumsikan sebagai ilusi yang terjadi dari sebuah bentuk dua dimensi. Ilusi tersebut akan terkesan sebagai bentuk 3D bagi pengguna dalam sebuah situs. 4. Movement
Pergerakan tidak hanya ditimbulkan oleh animasi, tetapi juga kesan dinamis yang muncul saat perubahan warna terjadi antar elemen disebuah situs, misalnya elemen atas dengan warna absolute, sedangkan bagian bawah ditempati oleh warna gradasi.
5. Space
Merupakan ruang yang tersisa dari sebuah situs. Sebagai contoh, desain situs yang terletak ditengah dan menyisakan ruang kosong di bagian kanan dan kiri untuk memenuhi prinsip balance dan simetris (Symmetry).
2.7 Testing Software
Menurut Romeo (2003:3) testing software adalah proses mengoperasikan software dalam suatu kondisi yang di kendalikan, untuk verifikasi apakah telah berlaku sebagaimana telah ditetapkan (menurut spesifikasi), mendeteksi error, dan validasi apakah spesifikasi yang telah ditetapkan sudah memenuhi keinginan atau kebutuhan dari pengguna yang sebenarnya. Verifikasi adalah adalah
STIKOM
pengecekan atau pengetesan entitas-entitas, termasuk software, untuk pemenuhan dan konsistensi dengan melakukan evaluasi hasil terhadap kebutuhan yang telah ditetapkan. Validasi adalah melihat kebenaran sistem, apakah proses yang telah dilakukan adalah apa yang sebenarnya diinginkan atau dibutuhkan oleh user. Jadi, dapat disimpulkan bahwa testing merupakan tiap-tiap aktifitas pengumpulan informasi yang dibutuhkan untuk melakukan evaluasi atau mengukur suatu atribut dari software.
Testing software dilakukan untuk mendapatkan informasi reliable terhadap software dengan cara termudah dan paling efektif, antara lain:
1. Apakah software telah siap digunakan? 2. Apa saja resikonya?
3. Apa saja kemampuannya? 4. Apa saja keterbatasannya? 5. Apa saja masalahnya?
6. Apakah telah berlaku seperti yang diharapkan?
2.7.1 Test Case
Test case merupakan suatu tes yang dilakukan berdasarkan pada suatu
inisialisasi, masukan, kondisi ataupun hasil yang telah ditentukan sebelumnya. Adapun kegunaan dari test case ini, adalah sebagai berikut:
1. Untuk melakukan testing kesesuaian suatu komponen terhadap spesifikasi (Black Box Testing).
2. Untuk melakukan testing kesesuaian suatu komponen terhadap desain (White
Box Testing).
STIKOM
Menurut Ganesan (2010) tujuan dasar dari penulisan test case adalah untuk melakukan validasi cakupan testing dari sebuah aplikasi. Test case yang ditulis dengan baik dapat membuat siklus testing menjadi lebih efisien. Sebuah test case yang baik dapat dengan mudah menentukan apakah suatu fitur dari aplikasi bekerja dengan benar.
Tabel 2.1 Contoh Test Case Pada Halaman Login.html
Test Case
Check Item Test case
Objective Steps to Execute Test Data / Input Expected Result TC-001
Log-in Page Leave all fields as blank and click Log-in button Click Log-in
By leaving all fields as blank and on click Log-in button then mandatory symbol ( * ) should appear in front of Username and Password fields
TC-002
Username Enter Invalid Username
NA Username : Jackk By entering invalid Username then an error message should appear as " Please Enter Valid Username "
TC-003
Username Enter valid Username
NA Username : Jack
It should allow the user to proceed
TC-004
Password NA The password
field should display the encrypted format of the text typed as (****)
STIKOM
Test Case
Check Item Test case
Objective Steps to Execute Test Data / Input Expected Result TC-005
Password Enter wrong password
NA Password : *** By entering invalid password then an error message should appear as " Please Enter Correct Password "
TC-006
Password Enter Correct password
NA Password : *******
It should allow the user to proceed TC-007 Log-in button Correct Inputs Click Log-in
It should lead the user to the respect page TC-008 Forgot Password Check hyperlink on Forgot Password label while mouse
over of the label an hand icon should display TC-009 Forgot Password Click Forgot Password User can recover the password using
the Forgot Password link
page
TC-010
Registration Check
hyperlink on Registration label
while mouse
over of the label an hand icon should display
TC-011
Registration Click
Registrati on
On click " Registration " page should redirect to the User
Registration page
2.7.2 Black Box Testing
Black box testing, dilakukan tanpa pengetahuan detil struktur internal dari
sistem atau komponen yang ditest, juga disebut sebagai behavioral testing,
STIKOM
specification-based testing, input / output testing atau functional testing. Black box testing berfokus pada kebutuhan fungsional pada software, berdasarkan pada
spesifikasi kebutuhan dari software. Kategori error yang akan diketahui melalui
black box testing adalah sebagai berikut:
a) Fungsi yang hilang atau tidak benar. b) Error dari antar muka.
c) Error dari struktur data atau akses eksternal database.
d) Error dari kinerja atau tingkah laku.
e) Error dari inisialisasi dan terminasi.
Test di desain untuk menjawab pertanyaan sebagai berikut: 1. Bagaimana validasi fungsi yang akan ditest?
2. Bagaimana tingkah laku kinerja dari sistem yang akan ditest? 3. Kategori masukan apa saja yang bagus digunakan untuk test case? 4. Apakah sebagian sistem sensitif terhadap suatu nilai masukan tertentu? 5. Bagaimana batasan suatu kategori masukan ditetapkan?
6. Sistem mempunyai toleransi jenjang dan volume data apa saja?
7. Apa saja akibat dari kombinasi data tertentu yang akan terjadi pada operasi dari sistem?
STIKOM
25
PERANCANGAN SISTEM
3.1. Analisis Sistem
PT. Merpati Maintenance Facility (MMF) adalah Strategic Business Unit dari PT. Merpati Nusantara Airlines yang bisnis utamanya merupakan pusat perawatan pesawat. Hangar pesawat di MMF memiliki daya tampung hingga empat pesawat besar seperti jenis Boeing 737-500. Selama ini dalam kegiatan administratif perawatan pesawat yang dilakukan MMF, pencatatan dan penyimpanan data saat ada pesawat yang masuk sampai pesawat tersebut keluar masih menggunakan dokumen fisik yang jumlahnya sangat banyak. Data tersebut akan digunakan pada bagian/divisi yang berbeda-beda yaitu bagian marketing,
planner (supporting), production, dan quality untuk rangkaian urutan proses
administrasi dalam kegiatan perawatan pesawat. Hal ini menimbulkan beberapa kendala seperti keakuratan, kontrol terhadap perubahan data, kecepatan dalam pemrosesan data, sampai data penting yang sering hilang dan kesulitan dalam pencarian data yang bersifat historical.
Permasalahan keakuratan data yang terjadi merupakan akibat dari hilangnya data-data pendukung yang sangat diperlukan sebagai input untuk proses di bagian selanjutnya. Input yang tidak akurat akan berlanjut karena aliran data tersebut terus digunakan sampai ke bagian-bagian lain yang terlibat dalam proses perawatan pesawat.
Kendala lain yang dihadapi adalah kecepatan dalam pemrosesan data. Hal ini dikarenakan data berupa fisik dan dokumen yang sangat banyak, sehingga
STIKOM
saat planner akan membuat paket pekerjaan yang diperlukan, planner akan kesulitan dalam melakukan pencarian data quotation dan repair order yang telah dibuat oleh bagian marketing. Padahal paket pekerjaan yang akan dibuat planner tersebut juga diperlukan oleh bagian production sebagai instruksi kerja perawatan pesawat yang ada di hangar. Bagian production juga mengalami kendala yang sama dalam proses pencarian item-item (job order) dalam paket pekerjaan karena paket pekerjaan yang dibuat oleh planner tersebut bisa sangat banyak dan memiliki banyak variabel/karakter yang bebeda-beda.
Permasalahan-permasalahan tersebut pada akhirnya juga akan mempengaruhi pembuatan laporan yang dilakukan oleh bagian planner seperti pembuatan progress report, production report, dan man hours report (jam kerja perawatan pesawat). Hasil analisa sistem dapat dilihat pada document flow pada Gambar 3.1.
Document flow administrasi perawatan pesawat diawali dengan adanya
permintaan perbaikan pesawat oleh customer kepada MMF, semua customer akan selalu berinteraksi dengan bagian marketing. Document flow diakhiri saat
customer menerima Certificate of Release to Service (CRS) yang merupakan
tanda bahwa pesawat telah diakui dan disertifikasi untuk layak terbang kembali, sehingga CRS juga merupakan tanda bahwa proses perawatan pesawat tersebut telah selesai baik tanpa perkecualian ataupun dengan perkecualian (exception).
Document flow administrasi perawatan pesawat ditunjukkan oleh Gambar 3.1.
STIKOM
Marketing Planner Production Quality Customer Start Order perawat an pesawat Membuat Quotation Membuat surat kontrak Waiting Quotation Quotation Disetujui? Memperba rui status Quotation Surat kontrak 1 2 Ya Approved Quotation Surat kontrak yang disetujui Surat kontrak yang disetujui 1 2 Mempelaja ri surat kontrak Memperbarui status Quotation Tidak Canceled Quotation Job Order Task Card Tersedia? Cek ketersediaan Task Card Membuat Job Order Ya Membuat Task Card Task Card Tidak Personel qualification/ rooster Mengerja kan Job Order Accomplished Job Order Mengins peksi Job Order Inspected Job Order Memeriksa keperluan RII release Perlu RII Release? Menutup pekerjaan Tidak Job Order Close RII Release Ya Job Order RII release Membuat Certificate of Release to Service Certificate of Release to Service Certificate of Release to Service 1 2 End
Gambar 3.1. Document flow administrasi perawatan pesawat
Awalnya, customer yang melakukan perawatan pesawat di MMF harus lapor ke bagian marketing lalu pihak marketing akan membuatkan quotation dengan status awal adalah waiting. Marketing akan mencatat complaint dan job
request dari customer di dalam quotation tersebut. Setiap complaint dan job request dari customer biasa juga disebut sebagai repair order (RO) dan dalam satu quotation bisa berisi beberapa repair order.
Negosiasi antara pihak customer dan marketing terus dilakukan sampai tercapainya kesepakatan. Item dalam quotation juga dapat berubah/direvisi sesuai dengan negosiasi yang dilakukan. Setelah tercapai kesepakatan, status pada
quotation akan diganti menjadi approved, dan repair order dapat diproses lebih
STIKOM
lanjut oleh bagian supporting atau planner. Sedangkan apabila tidak tercapai kesepakatan maka status pada quotation akan diganti menjadi cancel, dan tidak ada output berupa repair order yang perlu diproses oleh bagian supporting, namun data quotation tersebut tetap harus disimpan oleh pihak marketing.
Repair order akan diberikan oleh bagian marketing ke bagian supporting
atau planner. Semua data dari quotation dan repair order akan dipelajari lebih lanjut oleh bagian planner untuk dibuatkan paket pekerjaan (work pack) perawatan yang sesuai dan perlu dilakukan terhadap pesawat customer.
Setiap pesawat memiliki standar operasional perawatan yang disertakan oleh vendor pesawat, biasa disebut dengan Basic Task Card. Planner memerlukan semua data task card untuk pesawat yang sesuai, apabila task card belum tersedia maka planner harus membuatnya terlebih dahulu. Dari semua task card yang ada,
planner akan memilih task card yang sesuai saja untuk kemudian dijadikan job order. Job order inilah yang akan menjadi instruksi atau perintah pekerjaan yang
harus dilakukan oleh bagian production atau engineer di hangar.
Kumpulan job order yang telah dibuat oleh bagian supporting atau
planner kemudian diberikan kepada bagian production atau para engineer di
hangar. Job order tidak memberikan instruksi dengan menunjuk langsung kepada
engineer, tetapi di dalam job order tersebut hanya dijelaskan skill atau bidang
keterampilan yang dibutuhkan untuk tiap job order. Dari kumpulan job order yang telah dibuat, engineer bebas memilih job order mana yang akan dikerjakan, sesuai dengan bidang keahlian yang dimiliki masing-masing engineer dan harus memiliki tingkat otoritas minimal sebagai supporting staff.
STIKOM
Engineer mengambil dokumen job order, kemudian engineer
mengerjakan instruksi atau perintah kerja yang sesuai dengan dokumen job order pada pesawat yang sedang dilakukan proses perawatan. Setelah pekerjaan telah selesai dilakukan oleh engineer, engineer harus menuliskan report dan result pekerjaan yang telah dilakukannya pada kolom yang telah disediakan pada lembar
job order. Pada tahap ini job order masih belum dinyatakan selesai atau statusnya
masih open, masih diperlukan proses selanjutnya yaitu proses inspeksi. Inspeksi untuk job order yang telah dikerjakan oleh engineer hanya dapat dilakukan oleh
engineer dengan bidang keahlian atau keterampilan yang sesuai dengan job order
tersebut dan engineer yang hanya memiliki tingkat otoritas sebagai inspector. Sehingga dalam satu job order dimungkinkan apabila dikerjakan dan kemudian diinspeksi oleh engineer yang berbeda, tetapi dimungkinkan juga apabila job
order tersebut dikerjakan dan kemudian diinpeksi oleh engineer yang sama
dengan syarat engineer memiliki tingkat otoritas sebagai inspector.
Job order yang telah dikerjakan dan diinspeksi dapat dinyatakan telah
selesai atau status close apabila job order tersebut tidak mensyaratkan adanya RII
Release. Job order yang statusnya telah close akan dikembalikan ke bagian supporting atau planner. Job order yang mensyaratkan adanya RII Release masih
belum dinyatakan selesai atau close, tetapi masih memerlukan satu kali proses inspeksi lagi oleh engineer dengan bidang keahlian yang sesuai dengan job order dan memiliki tingkat otoritas sebagai certified staff. RII Release biasanya terdapat pada job order yang rumit dan membutuhkan dua tingkat inspeksi oleh engineer yang juga memiliki tingkat otoritas tertinggi.
STIKOM
Kumpulan job order yang telah diselesaikan dan statusnya close akan menjadi pertimbangan bagi engineer yang ditunjuk sebagai pimpinan proyek untuk mengeluarkan Certificate of Release to Service (CRS) yang merupakan tanda bahwa pesawat telah selesai proses perawatannya. Pimpinan proyek merupakan engineer dengan tingkat otoritas sebagai certified staff. Engineer dengan tingkat otoritas sebagai certified staff memiliki hak istimewa untuk merilis
CRS dengan syarat secara administratif yaitu minimal telah ada satu job order
yang telah diselesaikan, engineer yang merilis CRS bertanggungjawab penuh terhadap pesawat yang telah diselesaikan proses perawatannya tersebut, maka dari itu engineer tersebut harus melihat dan menilai dengan baik mana saja job order yang telah diselesaikan atau masih belum dikerjakan. Apabila semua job order yang disusun dan dibuat oleh planner telah sepenuhnya selesai dikerjakan, maka
CRS yang dirilis disebut CRS tanpa perkecualian atau exception, sedangkapn
apabila tidak semua job order telah dikerjakan dan diselesaikan namun certifed
staff menilai bahwa sudah layak untuk dirilisnya CRS maka CRS yang dirilis
disebut CRS dengan perkecualian atau with exception.
CRS dibuat sebanyak dua lembar, satu lembar diberikan ke bagian supporting atau planner dan satu lembar lainnya diberikan kepada customer
bersama dengan pesawat yang telah diselesaikan proses perawatannya.
Skema tahap perubahan dokumen-dokumen yang terjadi dalam proses administrasi perawatan pesawat lebih jelas dapat dilihat pada Gambar 3.2.
STIKOM
Quotation/ Main Job
Order
Work Pack
Job Order (JO) Job Order (JO) Job Order (JO) Repair Order
(RO) Repair Order
(RO)
Work Pack
Job Order (JO) Job Order (JO)
Repair Order (RO)
Work Pack
Job Order (JO)
Certificate of Release to Service
(CRS)
Gambar 3.2. Skema tahap urutan dokumen yang diproses dalam administrasi perawatan pesawat
3.2 Perancangan Sistem
Perancangan sistem dilakukan untuk mengumpulkan informasi yang berkenaan dengan sistem yang dibangun serta untuk memudahkan pemahaman terhadap sistem. Pemodelan yang digunakan dalam perancangan sistem adalah
system flow, data flow diagram (DFD) dan entity relational diagram (ERD).
3.2.1 System Flow
System flow komputerisasi merupakan proses lanjutan dari document flow dimana proses yang masih manual dihilangkan dan basis data dimunculkan.
STIKOM
A. System Flow Pembuatan Quotation dan Repair Order (RO)
System flow pembuatan quotation dan repair order melibatkan dua
entitas yaitu customer dan marketing. Proses dimulai dengan adanya permintaan perawatan pesawat oleh customer kepada MMF melalui bagian marketing.
Customer menyerahkan data customer dan data repair order ke bagian marketing. Marketing akan memasukkan data customer ke dalam database
kemudian akan diproses lebih lanjut untuk pembuatan quotation.
Marketing membuat quotation yang berisi subject atau yang biasa disebut repair order (RO). Dalam satu quotation berisi minimal satu item RO. System flow pembuatan quotation dan repair order dapat dilihat pada Gambar 3.3.
STIKOM
Customer Marketing Start Data Customer Input Data Customer Simpan Data Customer Customer Data Repair
Order Input Data
Quotation Customer Simpan Data Quotation Quotation Menampilkan Data Customer Menampilkan Data Quotation Quotation Input Data Subject/Repair Order Simpan Data Subject/Repair Order Subject Subject_Deta il Simpan Data Quotation Quotation End Simpan Data Quotation AC_Type
Gambar 3.3. System flow pembuatan quotation dan repair order
B. System flow Pembuatan Work Pack
Work pack adalah paket pekerjaan yang berisi satu atau lebih job order. Work pack dibuat oleh bagian supporting atau planner dengan data masukan
berupa repair order yang telah dibuat pada proses sebelumnya oleh bagian
marketing.
STIKOM
Sebelum membuat work pack, planner terlebih dahulu harus memeriksa apakah sudah tersedia task card yang akan digunakan sebagai acuan dalam membuat job order. Planner harus memasukkan data master task card apabila data task card yang diperlukan belum pernah ada di dalam database.
Selain basic task card, dalam work pack juga terdapat detil jenis kategori pekerjaan lainnya seperti engineering order, hard time (HT) atau component
replacement (CRR), dan special instruction (SI). Dari empat detil jenis atau
kelompok pekerjaan tersebut hanya basic task card dan engineering order yang memerlukan data master karena dua jenis pekerjaan tersebut bersifat umum, sehingga data master akan dapat digunakan kembali untuk proyek perawatan pesawat yang lainnya tanpa harus memasukkan kembali data basic task card dan
engineering order yang sama dan sudah pernah digunakan sebelumnya.
Hard time (HT) atau component replacement (CRR) dan special instruction (SI) tidak memerlukan data master karena perintah kerja yang tertera
bersifat sangat spesifik untuk proyek perawatan tertentu, sehingga data tidak akan pernah dipakai lagi untuk proyek perawatan pesawat yang lainnya.
Untuk kelompok pekerjaan yang tidak memerlukan data master, bagian
supporting atau planner dapat langsung memasukkan detil instruksi pekerjaan
tersebut saat proses pembuatan work pack.
Setelah bagian supporting atau planner selesai membuat dan menyusun
work pack, maka akan dihasilkan satu atau lebih job order yang tersimpan dalam database dan didistribusikan ke bagian production dan siap untuk dikerjakan oleh
para engineer. System flow pembuatan work pack dapat dilihat pada Gambar 3.4.
STIKOM
Supporting/PPC Production Start Quotation Subject Subject_Detai l Melihat Repair
Order Repair Order
Input Data Engineering Order Input Data Task
Card Master_Task Master_eo Simpan Task Card Simpan Engineering Order Tidak Task Card
Tersedia? Cek Ketersediaan Task Card Cek Ketersediaan Engineering Order
EO Tersedia? Tidak
Membuat Work Pack
Ya Ya
Menampilkan
Task Card Task Card
Memilih/Upload Task Card Menampilkan Engineering Order Engineering Order Memilih/Upload Engineering Order
[image:42.595.64.551.76.684.2]Input Hard Time (HT)/CRR Simpan Hard Time (HT)/CRR Material_ht Input Special Instruction Simpan Special Instruction Spec_inst Input TSN-TSO-CSN-CSO-TBO Simpan Work Pack Work_pack Material_res erv Melihat Job Order Job Order End Subject AC_Data Masterpart
Gambar 3.4. System flow pembuatan work pack
STIKOM
C. System flow Administrasi Pengerjaan Job Order
Administrasi pengerjaan job order dilakukan oleh masing-masing
engineer yang sesuai di bagian production. Daftar kumpulan job order yang telah
disusun dan dibuat sebelumnya oleh bagian supporting atau planner tampil di menu pilihan job order setelah engineer masuk/login ke aplikasi.
Engineer dapat mengambil satu job order saja dalam satu waktu dan
tidak dapat mengambil job order secara bersamaan atau parallel processing.
Engineer juga hanya dapat mengambil job order yang sesuai dengan skill yang
dimiliki dan memiliki otoritas minimal sebagai supporting staff.
Setelah job order diambil oleh engineer, maka sistem akan mulai melakukan proses perhitungan man hour yang menunjukkan waktu kerja engineer tersebut dalam menyelesaikan job order yang diambil, man hour dalam satuan jam. Setelah engineer mengambil job order, pilihan selanjutnya adalah close dan
pending. Close dipilih apabila engineer telah menyelesaikan dengan baik instruksi
yang ada pada job order, pada saat closing setiap engineer diharuskan menulis
report dan result pada kolom yang telah disediakan. Pending dipilih apabila engineer berhenti sementara saat mengerjakan job order, misalnya saat istirahat. Pending juga akan menghentikan proses perhitungan man hour secara sementara.
Engineer yang melakukan pending terhadap job order yang pernah
diambilnya, tidak dapat mengambil job order lain sampai job order yang pending tersebut diselesaikan terlebih dahulu dan melakukan proses closing.
Job order yang telah diselesaikan oleh memerlukan proses selanjutnya
yaitu inspeksi atau release, dan RII Release bila diperlukan. System flow Administrasi Pengerjaan Job Order dapat dilihat pada Gambar 3.5.
STIKOM
Production
Start
Job Order status Open
Input Data Pending Job Order
Ada JO Pending? Work_Pack
Subject
Menampilkan Job Order dengan status
Open
Quotation
Memilih Job Order untuk Dikerjakan
Job Order yang Siap Dikerjakan Accept Job Order
Job_Order
Cek Apakah Sudah Ada JO yang dikerjakan Engineer
kemudian Pending
Tidak
Cek Apakah Skill Engineer Sesuai dengan Kebutuhan JO Validasi skill terpenuhi? Ya Legal Personel Personel Menampilkan Job Order dengan status
Pending Ya
Job_Order Job Order status
Pending
Work_Pack Memilih Job Order
untuk Dikerjakan
Job Order yang Siap Dikerjakan
Accept Job Order
Menampilkan Pesan Engineer Tidak Legal untuk Mengerjakan
JO Tersebut Tidak
Pesan Engineer Tidak Legal untuk
Mengerjakan JO Tersebut 1 1 Ingin Pending Job? End
Pending Job Order Ya Personel Job_Order Work_Pack 2 2 Close JO Input Result
[image:44.595.53.548.82.711.2]Simpan dan Close JO
Gambar 3.5. System flow Administrasi Pengerjaan Job Order
STIKOM
D. System flow Release dan RII Release Job Order
Job order yang telah selesai dikerjakan oleh engineer di bagian production akan menjadi job order yang selanjutnya harus dilakukan proses
inspeksi oleh engineer dengan bidang keahlian yang sesuai dan tingkat otoritas minimal sebagai inspector. Proses inspeksi terhadap job order disebut sebagai proses release.
RII Release merupakan proses lanjutan terhadap job order yang telah
diinspeksi, tetapi RII Release bukan proses yang diharuskan untuk dilakukan. RII
Release hanya perlu dilakukan apabila dalam job order tersebut ada syarat untuk
harus dilakukan RII Release dan RII Release terdapat pada job order yang rumit dan membutuhkan inspeksi bertingkat agar pekerjaan yang telah dilakukan benar-benar terkontrol dengan baik hasilnya.
Release hanya bisa dilakukan oleh engineer di bagian production dengan skill yang sesuai pada job order dan memiliki tingkat otoritas minimal sebagai inspector, sedangkan RII Release merupakan tingkatan inspeksi yang lebih tinggi
sehingga hanya dapat dilakukan oleh engineer dengan skill yang sesuai dan memiliki tingkat otoritas sebagai certified staff.
Job order yang memerlukan release atau RII Release akan terlihat pada
menu yang telah disediakan dan engineer yang legal untuk melakukan proses administrasi releasing dapat memilih dari daftar job order tersebut. System flow
Release dan RII Release Job Order dapat dilihat pada Gambar 3.6.
STIKOM
Production Start Work_Pack Subject Quotation Job_Order Melihat Job Release Personel
Ada JO yang Perlu Release? End Tidak Memilih JO yang Akan direlease Ya
Legal Perlu RII
Release? Tidak
Memilih jO yang akan di-RII Release Release JO Ya RII Release Work_Pack Job_Order Job Release JO yang Akan direlease JO yang Akan direlease
Gambar 3.6. System flow Release dan RII Release Job Order
E. System flow Administrasi Certificate of Release to Service
Certificate of Release to Service (CRS) dapat dirilis oleh engineer di
bagian production dengan syarat secara administratif yaitu minimal telah ada satu
job order yang telah diselesaikan dan berstatus close.
STIKOM
CRS hanya dapat dirilis oleh engineer yang memiliki skill rating pesawat
yang sesuai dengan tipe pesawat yang akan dirilis CRS-nya dan engineer tersebut memiliki minimal limitation di bidang airframe, selain itu otoritas yang dimiliki adalah harus sebagai certified staff.
CRS akan menutup dan menyelesaikan proyek perawatan pesawat yang
sedang dilakukan dan bila ada job order yang masih tersisa maka job order tersebut menjadi berstatus CRS sehingga tidak perlu dikerjakan lagi oleh engineer.
System flow Administrasi Certificate of Release to Service dapat dilihat pada
Gambar 3.7. Production Start Work_Pack Subject Quotation Job_Order Memilih CRS Standar DGCA atau EASA Personel End Standarisa si DGCA? Memilih Main Job Order yang Akan di-CRS dengan standar DGCA Ya Memilih Main Job Order yang Akan di-CRS dengan standar EASA Tidak Input Work Perform Release Crs Crs_Except ion Ac_Data Planner Marketing CRS Customer
CRS CRS CRS
List Main Job Order
List Main Job Order
Gambar 3.7 System flow Certificate of Release to Service
STIKOM
[image:47.595.50.514.271.731.2]3.2.2. Data Flow Diagram
Diagram aliran data atau DFD yang akan digunakan dalam merancang dan membangun aplikasi administrasi perawatan pesawat ini adalah sebagai berikut:
A. Context Diagram
Context diagram dari aplikasi administrasi perawatan pesawat dapat
dilihat pada Gambar 3.8 di bawah ini.
Production Report
CRS
RII Release Job Order Release Job Order
Accomplis h Job Order Pending Job Order
Historical Job Work in Prog ress Report
Job Order Status Personel Qualification
Job Order
Accept J ob Order
Note Job Order Advise Spec ial Instruc tion Hard Time Eng ineering Order Basic Task Card Job Order Advise Pending
Production Report CRS Job Order Status Work in Prog ress Report
Repair Order
Job Order Status
Work in Prog ress Report Quotation
CRS
Repair Order
Data Cus tomer
Personel Roos ter Personel Qualification
Data Part Number
0
Aplikasi Administras i Perawatan Pes awat
+ Quality Cus tomer Marketing Supporting Production Manag ement
Gambar 3.8. Context Diagram Aplikasi Administrasi Perawatan Pesawat Pada context diagram di atas, terdapat satu proses yaitu Aplikasi Administrasi Perawatan Pesawat dan lima entitas, yaitu:
STIKOM
a. Entitas Customer
Entitas Customer berperan sebagai pemberi data dan input awal ke sistem yang kemudian akan diproses dengan data-data lain untuk menghasilkan data berikutnya yang akan digunakan sebagai acuan dalam proses selanjutnya. b. Entitas Quality
Entitas Quality berperan sebagai pemberi data yang berkaitan langsung dengan empat entitas lainnya, yaitu: marketing, supporting atau planner,
production, dan management.
c. Entitas Marketing
Entitas Marketing memberikan data ke sistem berupa data quotation berdasarkan acuan pada data dari entitas customer.
d. Entitas Supporting
Entitas Supporting memberikan data work pack ke sistem dengan acuan dari data quotation dan repair order yang telah dimasukkan terlebih dahulu. e. Entitas Production
Entitas Production memberikan data-data yang akan merubah status data job
order, yaitu: accept job order, pending job order, accomplish job order, release job order, RII release job order. Entitas Production juga memberikan
data CRS ke sistem. f. Entitas Management
Entitas Management menerima data laporan berupa Production Report yang merupakan hasil rekap maupun perhitungan dari proses dan transaksi dalam sistem.
STIKOM
B. Diagram Berjenjang
1. Aplikasi Administrasi Perawatan Pesawat
[image:50.595.44.540.135.682.2]0 Aplikasi Administrasi Perawatan Pesawat 2 Quotation & Subject 3 Work Pack 4 Perform Aircraft Maintenance Jobs 1 Personel’s Authorizati on 2.1 Input Quotation 3.1 Basic Task 3.2 Engineering Order 3.3 Hard Time 3.4 Special Instruction 4.1 Accept Job Order 4.3 Close Job Order 4.4 Release Job Order 4.5 RII Release Job Order 4.1.1 Task on Progress 4.6 Certificate of Release to Service 5 Reporting 1.1 General License Input 5.2 Work in Progress Report 5.3 Production Report 5.1 Job Order Status 4.2 Pending Job Order 6 Maintenance Data 6.1 Customer Data 6.2 Part Number Data 1.2 AME License Input 1.3 Company Authorizati on Input 1.3 Personel Training Input 2.2 Input Subject / Repair Order
Gambar 3.9. Diagram Berjenjang Aplikasi Administrasi Perawatan Pesawat
STIKOM
C. DFD Level – 0 Aplikasi Administrasi Perawatan Pesawat
DFD Level – 0 aplikasi administrasi perawatan pesawat dapat dilihat pada Gambar 3.10.
STIKOM
Data_P endi ng_T as k Data_P ers o n_Load
Data_S pec _ Ins t
Data_Notic e
P roduc t ion Report J ob Ord er S tatus W ork in P rogres s Report Repair Orde r
J ob Ord er S tatus W ork in P rogres s Report P roduc t ion Report
Note
His toric al J ob W ork in P rogres s Report
J ob Ord er S tatus CRS
Data_J o b_Order J ob Ord er A dvis e
J ob Ord er A dvis e P ending
CRS
Data_J o b_Order Data_CRS Data_W ork_P ac k
CRS RII Releas e J ob Order
Releas e J ob Order P ending J ob Order
A c c omp lis h J o b Order P ers one l Qu alific at ion
J ob Ord er A c c ept J ob Order
Data_W ork_P ac k Data_Le gal Data_W ork_P ac k Data_Materi al_Res erve Data_Materi al_Ht Data_Mas te r_T as k
Data_Mas te r_E o Data_E o_In s truc tio n
Data_A c
S pec ial Ins truc tion Hard T ime E nginee ring Order
B as ic T as k Card
Data_Mas te rpart Data_Le gal
Data_S ubje c t_Detail Data_S ubje c t
Data_Quota tion
Data_S ubje c t_Detail
Data_S ubje c t Data_Quota tion
Data_Mas te rpart
Data_Le gal Quotatio n
Data_Cus to mer Repair Orde r
Data_Id entity
Data_Cus to mer
Data_Le gal
Data Cus tom er
Data_Mas te rpart Data_Le gal
Data_Li mitation
Data_P ers _ Tra ining Data_P ers _ Otr Data_P ers _ Gen _Lic Data_P ers _ Am el_Rating
Data_P ers _ Am el Data P ers on el
P ers one l Ro os ter P ers one l Qu alific at ion Data P art Numb er
S upport ing Quality
Cus tom er
Cus tom er
Marketing
Marketing Marketing
S upport ing S upport ing S upport ing
S upport ing S upport ing S upport ing S upport ing
S upport ing
P roduc t ion P roduc t ion
P roduc t ion
P roduc t ion P roduc t ion P roduc t ion P roduc t ion P roduc t ion P roduc t ion P roduc t ion P roduc t ion
Manage ment
1
Mainten anc e Data P ers on el
Qualific ation
1 P ers one l
2 P ers _A mel
3 P ers _A mel_ Ra ting
4 P ers _Gen_l ic
5 P ers _Otr
6 P ers _T raini ng
7 Limi tation
8 Lega l
9 Mas terp art
2
Mainten anc e Data Cus t omer
10 Cus tom er
11 Iden tity
3
Membua t Qu otation Sub jec t
+
12 Quotatio n
13 S ubjec t
14 S ubjec t _De tail
4
Membua t W ork Pac k
+
15 A c _Data
16 E o_Ins t ruc tion
17 Mas ter_ Eo
18 Mas ter_ Tas k
19 Material _Ht
20 Material _Re s erve
21 W ork_P ac k
5
P engerj aan J ob Ord er
+
23 CRS
25 J ob_ Ord er
6
Reportin g S upport ing
S upport ing
S upport ing
26 Notic e
27 S pec _In s t
28 P ers on_ Load
[image:52.595.71.550.78.731.2]29 P ending _Ta s k
Gambar 3.10. DFD – Level 0 Aplikasi Administrasi Perawatan Pesawat
STIKOM
D.DFD Level – 1 Aplikasi Administrasi Perawatan Pesawat 1. DFD Level – 1 Sub Sistem Pembuatan Quotation
DFD Level – 1 sub sistem pembuatan quotation dapat dilihat pada Gambar 3.11.
Gambar 3.11. DFD Level – 1 Sub Sistem Pembuatan Quotation
2. DFD Level – 1 Sub Sistem Pembuatan Work Pack
DFD Level – 1 sub sistem pembuatan work pack dapat dilihat pada Gambar 3.12.
Data_Quotation
[Data_Subject_Detail] [Data_Subject] [Repair Order]
[Data_Quotation] [Data_M asterpart] [Data_Customer]
[Data_Leg al] [Quotation]
Cus tomer Marketing
10 Cus tomer 8 Legal
9 Masterpart 12 Quotation
13 Subjec t 14 Subjec t_Detail 3.1
Membuat Quotation
3.2 Input Data Subjec t dan
Repair Order
STIKOM
Gambar 3.12. DFD Level – 1 Sub Sistem Pembuatan Work Pack
3. DFD Level – 1 Sub Sistem Pengerjaan Job Order
DFD Level – 1 sub sistem pengerjaan job order dapat dilihat pada Gambar 3.13.
Data_Mas ter_Task Data_EO
[Data_Spec_Ins t]
[Data_Work_Pac k]
[Data_M aterial_Res erve] [Data_M aterial_Ht] [Data_Eo_Instruction] [Data_Ac] [Data_M asterpart] [Data_Leg al] [Data_Subject_Detail] [Data_Subject] [Data_Quotation] [Special Instruction] [Hard Time] [Repair Order] [Data_M aster_Eo]
[Engineering Order]
[Data_M aster_Task] [Basic Task Card]
Supporting SupportingSupporting
SupportingSupporting
12 Quotation 13 Subjec t
14 Subjec t_Detail
8 Legal
9 Masterpart
15 Ac_Data 16 Eo_Ins truction
17 Master_Eo
18 Master_Tas k
19 Material_Ht
20 Material_Reserve
21 Work_Pack 27 Spec _Inst
4.1
Maintenance Data Basic Task Card
4.2
Maintenance Da