BAB I PENDAHULUAN
2.6. Metode Pengumpulan Data
Dalam penulisan skripsi ini penulis memerlukan data baik data primer maupun sekunder. endapatkan data yang valiuntuk md, penulis melakukan teknik pengumpulan data sebagai berikut:
a. Studi Pustaka
Studi pustaka dilakukan dengan cara mengkaji sumber teknis tertulis seperti dokumen, laporan tahunan, peraturan perundangan, makalah, dan sumber lainnya.(Dwiyanto,2008:2)
b. Studi Literature
Studi Literature4, yaitu mempelajari buku-buku referensi dan hasil penelitian sejenis sebelumnya yang pernah dilakukan oleh orang lain.
4
Tujuannya ialah untuk mendapatkan landasan teori mengenai masalah yang akan diteliti. Teori merupakan pijakan bagi peneliti untuk memahami persoalan yang diteliti dengan benar dan sesuai dengan kerangka berpikir ilmiah. Bagian ini akan dikaji lebih mendalam pada BAB II.
c. Observasi
Observasi adalah merupakan teknik atau pendekatan untuk mendapatkan data primer dengan cara mengamati langsung obyek datanya (Jogiyanto, 2008:89)
d. Wawancara
Wawancara adalah komunikasi 2 (dua) arah untuk mendapatkan data dari responden. (Jogiyanto, 2008:65)
2.7 Metode Pengembangan Sistem
Pada penelitian ini, penulis menerapkan metode pengembangan sistem Rapid Application Development (RAD) yang pertama kali dikembangkan oleh IBM yang dikemukakan oleh James Martin (K.K.Aggarwal, 2005:27). Rapid Aplication Development (RAD) merupakan model incremental dari proses pengembangan perangkat lunak yang menekankan pada sedikitnya atau siklus pengembangan yang pendek. Model RAD merupakan adaptasi yang cepat dari model sekuensial yang didapatkan RAD dari penggunaan pengembangan berbasiskan komponen.(Pressman,2001:32)
2.7.1 Tahapan-tahapan RAD
Tahapan-tahapan Rapid Application Development (RAD) yang dijabarkan oleh K.K. Aggarwal (Software Engineering, 2005:28) adalah sebagai berikut:
1. Requirement Planning
Requirement Planning (juga dikenal sebagai Concept Definition) terdiri dari pertemuan antara tim perencanaan dan klien pengguna. Rapat berfokus daftar persyaratan awal serta menetapkan cakupan proyek. Tim perencanaan mengidentifikasi fungsi-fungsi bisnis utama dan awalnya memecah mereka ke departemen-departemen atau pengguna akhir (seperti Produk, Penjualan, Perusahaan, Sales Person).
2. User Design/User Description
Selama tahap User Design (juga dikenal sebagai User Description) tim analisis bertemu dengan pengguna akhir dalam rapat Joint Application Development (JAD). Selama rapat tim analisis memberikan hasil analisa secara lebih rinci, mengembangkan entitas yang dikembangkan dalam Requirement Planning menjadi model data (Entity Relationship Diagram), peraturan bisnis, mengembangkan rencana tes, dan menciptakan arus dan tata letak interface (tampilan) untuk bagian-bagian penting sistem. Dalam rangka menjaga iterasi pembangunan sesingkat mungkin, dan untuk mendapatkan manfaat yang maksimal dari RAD,
persyaratan inti harus diidentifikasi dan ditargetkan untuk prototipe awal, dan kebutuhan sekunder harus diidentifikasi.
3. Construction
fase atau tahapan ini menggabungkan tahapan desain, coding dan testing pada proses model waterfall. pada tahapan ini tim pengembang memberikan prototipe perangkat lunak kepada pengguna untuk mendapatkan masukan.
4. Implementation (Cut Over)
Pada tahapan ini pengembang melakukan tiga kegiatan yaitu; testing kepada pengguna, instalasi sistem, dan pelatihan terhadap user.
Gambar 2.6. Tahapan-tahapan RAD (K.K.Aggarwal, 2005:28)
2.7.2 Alasan Penggunaan Metode RAD
Dalam penelitian ini, penulis memutuskan untuk menggunakan metode pengembangan sistem Rapid Application Development (RAD), dengan alasan :
a. Penelitian yang dilakukan masih berskala kecil. (pressman, 2001:32). Lingkup penelitian hanya di unit III perum perhutani.
b. Waktu pengembangan singkat hanya 60-90 hari. (pressman, 2001:32)
c. Visual Basic mendukung untuk pengembangan dengan menggunakan metode pengembangan sistem RAD5.
2.7.3 Perbandingan Dengan Metode Pengembangan Sistem Lainnya
Perbandingan metode RAD dengan metode pengembangan sistem lainnya dapat dilihat pada tabel berikut ini :
Tabel 2.1. Perbandingan Metode
SDLC RAD
OPEN
SOURCE
OBJECTS JAD Prototyping End user
Kontrol Formal SIM Lemah Standar Gabungan Pengguna Pengguna
Time Panjang Pendek Menengah Tergantung
Project Menengah Pendek Pendek
Pengguna Banyak Beberapa Beberapa Varies Beberapa Satu atau
dua Satu
Staff Sistem Informasi Manajemen
Banyak Beberapa Ratusan Split Beberapa Beberapa Tidak Ada
Transaksi
/ DSS
Transaksi Keduanya Keduanya Keduanya DSS DSS DSS
Interface Minimal Minimal Lemah Windows Kritis Kritis Kritis
Dokumentasi
& Pelatihan
Penting Terbatas Internal Pada obyek Terbatas lemah Tidak ada
Integritas &
Keamanan Penting Penting
Tidak
diketahui
Pada obyek Terbatas Lemah Lemah
Reusability Terbatas Ada Mungkin Penting Terbatas Lemah Tidak ada
(Sumber : Post dan Anderson, 2006:67)
5
2.8 Unified Modelling Language (UML) 2.8.1 Definisi
UML didefinisikan sebagai notasi diagram untuk menggambarkan artefak dari Objects-Oriented Analysis Design (OOAD). Melalui UML kita dapat membayangkan, menentukan, membangun dan membuat dokumen aplikasi perangkat lunak. Ketika sistem perangkat lunak menjadi semakin besar dan semakin kompleks kita perlu mengelola kompleksitas itu, dalam arti, menyederhanakannya sehingga kita memiliki pemahaman yang lebih baik lagi. (Barclay dan Savage, 2004 : 3).
Dengan menggunakan diagram-diagram notasi UML, developer dapat melakukan pemrograman kode yang biasa dikenal dengan sebutan forward engineering6, yaitu proses tradisional mengubah abstraksi tingkat tinggi, desain logical dan implementasi mandiri ke dalam implementasi fisik dalam sebuah sistem.
Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented
6
Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).
(Dharwiyanti, 2003:2)
Diagram-diagram yang terdapat di dalam pemodelan UML dan digunakan penulis dalam pembuatan aplikasi ini adalah sebagai berikut :
1. Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem.
(Dharwiyanti, 2003:5)
Gambar 2.7. Contoh use case diagram (Dharwiyanti, 2003:5)
2. Class Diagram
Class diagram adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class diagram menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). (Dharwiyanti, 2003:5). Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Classdiagram memiliki tiga area pokok :
1. Nama (dan stereotype) 2. Atribut
3. Metoda
Gambar 2.8. Contoh Class Diagram (Dharwiyanti, 2003:5)
3. Statechart Diagram
Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya
statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram)
(Dharwiyanti,2003:7).
Gambar 2.9. Contoh Statechart Diagram (Dharwiyanti,2003:7)
4. Activity Diagram
Activity diagram menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara
eksak atau tepat, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. (Dharwiyanti, 2003:7)
Gambar 2.10. Contoh Activity Diagram (Dharwiyanti, 2003:8)
5. Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).
Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respon dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang menjadi trigger aktivitas tersebut, proses
dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. (Dharwiyanti, 2003:8)
Main ui Object1 Object1 Object2
Message1 Message2 Message1 Message2 Message1 Message2 Actor1 Message1 Message2 Message1
Gambar 2.11. Contoh Sequence Diagram (Sun Services, 2003:115)
6. Collaboration Diagram
Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message.
Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama. (Dharwiyanti, 2003:9)
Gambar 2.12. Contoh Collaboration Diagram (Dharwiyanti, 2003:9)
7. Component Diagram
Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.
Gambar 2.13. Contoh Component Diagram (Dharwiyanti, 2003:10)
8. Deployment Diagram
Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisik. Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan
requirement dapat juga didefinisikan dalam diagram ini. (Dharwiyanti, 2003:10)
Gambar 2.14. Contoh Deployment Diagram (Dharwiyanti, 2003:11)
Pada penelitian ini, penulis menggunakan perangkat lunak eDraw 5.0 dan Microsoft Visio 2007 dalam merancang aplikasi.
Tabel 2.2. Notasi UML
No Notasi Keterangan
1 Class Diagram, digunakan untuk mengambarkan kelas-kelas program. Terdiri atas nama kelas-kelas, atribute yaitu properties yang dimiliki oleh kelas, dan operation yaitu aktifitas yang dapat dilakukan oleh kelas tersebut
2 Relationship merupakan hubungan antar class. Dapat berupa one to one, one to many, maupun many to one 3 Aktor merupakan pelaku-pelaku yang terlibat di dalam
sistem.
4 Use case merupakan penjelasan kegiatan-kegiatan yang ada di dalam sistem
5 Initial node digunakan sebagai notasi awal dari proses yang dijalankan.
6 Action merupakan notasi yang menggambarkan aksi yang terjadi di dalam suatu proses
7 Activity Final Node merupakan notasi yang melambangkan akhir dari sebuah proses
8 Activity merupakan aktifitas yang ada di dalam sistem. Biasa digunakan pada proses yang melibatkan proses lainnya.
9 Activity dengan parameter biasa digunakan pada proses yang melibatkan proses lainnya serta mengambil parameter dari proses tersebut.
10 Lifeline merupakan state dari sebuah proses yang ada di dalam sistem. Nantinya, setiap bagian dari proses akan berhenti pada lifeline yang sesuai.