untuk memperoleh pemahaman yang lebih rinci mengenai apa yang bekerja, apa yang tidak bekerja, dan apa yang dibutuhkan.
Menurut Ariesto 2002, analisis sistem adalah proses menentukan kebutuhan sistem apa yang harus dilakukan sistem untuk memenuhi kebutuhan klien, bukan
bagaimana sistem tersebut diimplementasikan. Tahap analisa dimulai ketika adanya permintaan akan sistem baru atau perbaikan
dari sistem yang telah ada. Permintaan ini disebabkan karena kinerja yang tidak memadai.Tim analisa sistem kemudian mendefinisikan kebutuhan informasi sistem
yang sedang berjlana dengan melakukan wawancara atau membagikan kuesioner serta melakukan pengamatan. Informasi yang dikumpulkan terutama mengenai
kelebihan dan kekurangan sistem yang berjalan.
2.7.2.2 Perancangan Sistem
a. Pengertian Perancangan Sistem
Nugroho 2005 menyatakan bahwa selama proses analisis, perhatian kita adalah apa yang harus dikerjakan. Selama perancangan, keputusan dibuat tentang bagaimana
pemecahan masalah akan dikerjakan, pertama pada sistem dengan peringkat yang lebih tinggi kemudian secara bertahap ke sistem yang memiliki peringkat lebih
rendah. Menurut Nugroho 2005, perancangan sistem adalah tahap awal dimana
pendekatan awal untuk menyelesaikan masalah dipilih. Selama perancangan sistem, struktur keseluruhan diputuskan.
2.7.3 Rich Picture
Rich picture merupakan sebuah gambaran informal yang mempresentasikan
pemahaman illustrator dari suatu situasi Mathiassen et al, 2000. Dengan demikian, dapat digunakan untuk memfasilitasi komunikasi di antara pemakai dalam sistem dan
mendapatkan sebuah gambaran dari situasi dengan cepat. Untuk memulai rich picture adalah dengan menggambarkan entitas yang
penting, seperti orang, objek fisik, organisasi, peran, dan tugas. Orang dapat berupa pengembangan sitem system developer, pengguna user, pelanggan, dan lain-lain.
Objek fisik dapat berupa mesin, perangkat, atau persediaan di gudang.Tempat mendeskripsikan lokasi orang dan benda. Organisasi dapat berupa keseluruhan
perusahaan, departemen atau proyek yang melibatkan beberapa perusahaan. Peran dan tugas mengikat orang kepada organisasi yang merefleksikan tanggung jawab atas
tugas-tugas spesifik Mathiassen et al, 2000. Setelah entitas yang relevan dideskripsikan, lalu hubungan di antara entitas-
entitas tersebut di deskripsikan. Proses merupakan hubungan yang paling mendasar di antara entitas dalam suatu rich picture. Sebuah proses mendeskripsikan aspek-aspek
dari situasi yang berubah, tidak stabil, atau di bawah pengembangan. Secara grafis, proses dapat diilustrasikan dengan arah panah. Proses meliputi pekerjaan, produksi,
pemrosesan informasi, perencanaan, pengendalian, proyek pengembangan, dan perubahan organisasi Mathiassen et al, 2000.
Guru SMAN 46
3. GuruBertemu Pegawai tatausaha
Guru SMAN 46Jakarta
1. Guru Membutuhkan File Dokumen knowlede guru
5.Guru Mendapatkan file dokumen knowledge guru
yang dibutuhkan
Database Tata Usaha SMAN 46 Jakarta
9. Pegawai Tata Usaha Menyimpan
ke dalam database 4. Pegawai tata usaha
Mengambil file database yang dibutuhkan guru
2. Guru Mendatangi bagian tata usaha
Tata Usaha SMAN 46
Jakarta
6. Guru Ingin menyimpan
File Dokumen knowledge guru
Bagian Tata Usaha
7. Guru mendatangi Bagian tata usaha
8. Guru bertemu Pegawai tatausaha
Gambar 2.4 Rich Picture
Penjelasan dari Rich Picture di atas adalah sebagai berikut: 1. Guru membutuhkan file dan dokumen knowledge guru
2. Guru mendatangi bagian tata usaha untuk mendapatkan file dan dokumen knowledge guru.
3. Guru bertemu pegawai tata usaha menanyakan file dan dokumen yang dibutuhkan.
4. Pegawai tata usaha mengambil file dan dokumen yang dibutuhkan guru dalam database
yang tersedia. 5. Guru telah mendapatkan file dan dokumen yang dibutuhkan.
6. Guru ingin menyimpan file dan dokumen knowledge guru. 7. Guru mendatangi bagian tata usaha.
8. Guru bertemu pegawai tata usaha dengan menyerahkan file dan dokumen knowledge
untuk disimpan. 9. Pegawai tata usaha menyimpan file dan dokumen knowledge guru yang
diterima dari guru.
2.7.4 Metodologi Pengembangan Sistem
Metodologi adalah kesatuan metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturan-aturan dan postulat-postulat yang digunakan oleh suatu ilmu
pengetahuan, seni atau disiplin lainnya. Sedangkan metode adalah suatu cara, teknik yang sistematik untuk mengerjakan sesuatu. Metodelogi pengembangan sistem
berarti adalah metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturan- aturan dan postulat-postulat yang akan digunakan untuk pengembangan suatu
informasi Jogiyanto, 2005.
2.7.4.1 SDLC System Development Life Cycle
Dalam rekayasa sistem dan rekayasa perangkat lunak, SDLC adalah proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan
untuk mengembangkan sistem-sistem yang tediri dari tahap-tahap: rencana planning, analisis analysis, desain design, implementasi implementation, uji
coba testing dan pengelolaan maintenance Britton Jill, 2001. Dalam rekayasa perangkat lunak, konsep SDLC mendasari berbagai jenis metodologi pengembangan
perangkat lunak. Metodologi-metodologi ini membentuk suatu kerangka kerja untuk perencanaan dan pengendalian pembuatan sistem informasi, yaitu proses
pengembangan perangkat lunak. Terdapat 3 jenis metode sisklus hidup sistem yang
paling banyak digunakan, yakni: siklus hidup sistem tradisional traditional system life cycle
, siklus hidup menggunakan prototyping life cycle prototyping, dan siklus hidup sistem orientasi objek object-oriented system life cycle Britton Jill, 2001.
2.7.4.2 RAD Rapid Application Development
Metode pengembangan sistem yang penulis gunakan adalah metode Rapid Application Development
RAD. RAD adalah suatu pendekatan berorientasi objek terhadap pengembangan sistem yang mencakup suatu metode pengembangan
perangkat lunak. RAD secara konseptual bertujuan mempersingkat waktu yang biasanya diperlukan dalam Siklus Hidup Pengembangan Sistem SHPS tradisional
antara perancangan dan penerapan sistem informasi. Kendall dan Kendall, 2008
Requirement Planning Phase
User Design Phase
Construction Phase
Cutover Phase
Gambar 2.5 Fase RAD Martin Kendall dan Kendall, 2008
Pada Gambar 2.5 kita dapat melihat konseptualisasi dari fase RAD James Martin. Pada fase pertama Martin mendiskusikan requirement planning perencanaan
kebutuhan. Disini high-level user memutuskan fungsi dari aplikasi yang akan ditampilkan.
Pada fase kedua, merupakan fase user design, Martin mengkarakterisasi user untuk saling berhubungan dalam mendiskusikan aspek nontechnical design pada
sistem, dengan dukungan analysts. RAD fase Design Workshop menggabungkan fase
user design dan fase construction menjadi satu, karena interaksi yang tinggi dan
proses sifat visual design-and-refine dibutuhkan di dalam interaktif. Di fase construction berjalan banyak aktifitas yang berbeda. Desain yang
buat pada fase sebelumnya akan dikembangkan oleh tools RAD. Setelah fungsi baru telah ada, fungsi akan memperlihatkan pada user untuk berinteraksi, berkomentar,
dan me-review. Dengan tools RAD, analyst dapat membuat perubaha berkelanjutan pada desain aplikasi.
Pada Martin fase keempat, yaitu fase cut over, aplikasi baru yang telah dikembangkan akan menggantikan sistem yang lama. Selama sistem berjalan secara
paralel dengan aplikasi yang lama, sistem yang baru akan diuji, user dilatih, dan prosedur organisasi berubah sebelum customer berlangsung.
Berikut keunggulan dan kelemahan RAD: a. Keunggulan Model RAD
1. Setiap fungsi mayor dapat dimodulkan dalam waktu tertentu kurang dari 3 bulan dan dapat dibicarakan oleh tim RAD yang terpisah dan kemudian
diintegrasikan sehingga waktunya lebih efisien. 2. RAD mengikut tahapan pengembangan system seperti umumnya, tetapi
mempunyai kemampuan untuk menggunakan kembali komponen yang ada reuseable object sehingga pengembang tidak perlu membuat dari awal lagi
dan waktu lebih singkat. 3. Memerlukan biaya yang lebih sedikit dan mementingkan dari segi bisnis dan
teknik.
4. Berkonsentrasi pada sudut pandang user dan menyediakan perubahan secara cepat sesuai permintaan user.
5. Menghasilkan jarak kesesuaian yang kecil antara kebutuhan user dan spesifikasi sistem.
6. Waktu, biaya, dan effort minimal. b. Kelemahan Model RAD
1. RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
2. RAD menuntut pengembangan dan pelanggan yang memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapai sebuah sistem,
di dalam kerangka waktu yang sangat diperpendek. 3. Kecepatan yang tinggi dengan biaya minimal kemungkinan besar hasil
kualitasnya rendah. 4. Proyek mungkin berakhir dengan lebih banyak tambahan kebutuhan daripada
yang telah dipenuhi. 5. Potensial adanya penambahan fitur karena fitur yang sekarang hasilnya asal-
asalan. 6. Potensial tidak sesuainya desain dan implementasi.
7. Potensial tidak konsistennya penamaan dan dokumentasi. 8. Sangat sulit membuat modul yang dapat digunakan kembali.
b. Kondisi Sesuai RAD 1. Proyek dengan skala kecil sampai medium dengan waktu pendek
2. Fokus pada lingkup tertentu, misalnya pada objek bisnis yang telah didefiniskan dengan baik.
3. Bukan aplikasi dengan komputasi yang kompleks. 4. User tahu pasti area yang harus dimiliki aplikasi.
5. Manajemen memiliki komitmen terhadap keterlibatan user. 6. Spesifikasi kebutuhan sudah benar-benar diketahui.
7. Anggota tim memiliki keahlian yang baik. 8. Komposisi tim stabil.
9. Ada kontrol proyek yang efektif. d. Kondisi Tidak Sesuai RAD
1. Proyek yang terlalu besar dan kompleks. 2. Proyek yang bersifat aplikasi real-time atau menangani hal-hal kritis.
3. Sistem dengan komputasi tinggi. 4. Lingkup dan objek bisnis proyek belum jelas.
5. Pengumpulan spesifikasi kebutuhan membutuhkan waktu lama. 6. Banyak orang yang harus terlibat dalam proyek.
7. Membutuhkan lingkup daerah yang luas. 8. Tim proyek besar dengan koordinasi tinggi.
9. Komitmen pihak manajemen dengan user rendah. 10. Banyak teknologi baru digunakan untuk membangun aplikasi.
2.8 Pengertian OOA Object Oriented Analysis
