RPL - Analisis dan Design Sistem

Kegiatan Analisis Sistem

Kegiatan untuk melihat sistem yang sudah berjalan, melihat bagian mana yang bagus dan tidak bagus, dan kemudian mendokumentasikan kebutuhan yang akan dipenuhi dalam sistem yang baru.

Analisis dan desain sering kali dilakukan secara bersamaan.

1.       Teknik Wawancara

Panduan dalam melakukan wawancara memperoleh data :

1. Buatlah jadwal wawancara dengan narasumber dan beritahukan maksud dan tujuan wawancara
2. Buatlah panduan wawancara yang akan anda jadikan arahan agar pertanyaan fokus kepada hal-hal yang dibutuhkan
3. Gunakan pertanyaan yang jelas dan mudah dipahami
4. Cobalah untuk menggali mengenai kelebihan dan kekurangan sistem yang telah berjalan sebelumnya
5. Anda boleh berimprovisasi dengan mencoba menggali bagian-bagian tertentu yang menurut anda penting
6. Catat hasil wawancara tersebut

Keuntungan :

1. Lebih mudah dalam menggali bagian sistem mana yang dianggap baik dan bagian mana yang dianggap kurang baik
2. Jika ada bagian tertentu yang menurut anda perlu untuk digali lebih dalam, anda dapat langsung menanyakan kepada narasumber
3. Dapat menggali kebutuhan user secara lebih bebas
4. User dapat mengungkapkan kebutuhannya secara lebih bebas

Kerugian :

1. Wawancara akan sulit dilakukan jika narasumber kurang dapat mengungkapkan kebutuhannya
2. Pertanyaan dapat menjadi tidak terarah, terlalu fokus pada hal-hal tertentu dan mengabaikan bagian lainnya

2.       Teknik Observasi

Petunjuk dalam melakukan observasi :

1. Tentukan hal-hal apa saja yang akan diobservasi agar kegiatan observasi menghasilkan sesuai dengan yang diharapkan
2. Mintalah izin kepada orang yang berwenang pada bagian yang akan diobservasi
3. Berusaha sesedikit mungkin agar tidak mengganggu pekerjaan orang lain
4. Jika ada yang anda tidak mengerti, cobalah bertanya. Jangan membuat asumsi sendiri

Keuntungan :

1. Analis dapat melihat langsung bagaimana sistem lama berjalan
2. Mampu menghasilkan gambaran lebih baik jika dibanding dengan teknik lainnya

Kelemahan :

1. Membutuhkan waktu cukup lama karena jika observasi waktunya sangat terbatas maka gambaran sistem secara keseluruhan akan sulit untuk diperoleh
2. Orang-orang yang sedang diamati biasanya perilakunya akan berbeda dengan perilaku sehari-hari (cenderung terlihat baik). Hal ini akan menyebabkan gambaran yang diperoleh selama observasi akan berbeda dengan perilaku sehari-hari
3. Dapat mengganggu pekerjaan orang-orang pada bagian yang sedang diamati

3.       Teknik Kuisioner

Teknik dalam membuat kuisioner yang baik :

1. Hindari pertanyaan isian, lebih baik pilihan ganda, karena responden biasanya malas untuk menulis banyak, dan jika responden menuliskan sesuatu sering kali susah untuk dipahami. Dan juga dengan pertanyaan pilihan ganda, akan memudahkan anda untuk melakukan rekapitulasi data hasil kuisioner
2. Buatlah pertanyaan yang tidak terlalu banyak
3. Buatlah pertanyaan yang singkat, padat dan jelas

Keuntungan :

1. Hasilnya lebih objektif, karena kuisioner dapat dilakukan kepada banyak orang sekaligus
2. Waktunya lebih singkat

Kelemahan :

1. Responden cenderung malas untuk mengisi kuisioner
2. Sulit untuk membuat pertanyaan yang singkat, jelas dan mudah dipahami

Kebutuhan (requirement) yang dikumpulkan dengan menggunakan wawancara, observasi, kuisioner, atau gabungan dari ketiga hal tersebut dapat dikelompokkan menjadi kategori sebagai berikut :

1. Functional requirement

Kebutuhan yang terkait dengan fungsi produk, misalnya sistem informasi harus mampu mencetak laporan, sistem informasi harus mampu menampilkan grafik, dll

2. Development requirement

Kebutuhan yang terkait tools untuk pengembangan sistem informasi baik perangkat keras maupun perangkat lunak, misalnya sistem informasi dikembangkan dengan menggunakan alat bantu Eclipse untuk pengembangan dan StarUML untuk pemodelan

3. Deployment requirement

Kebutuhan terkait dengan lingkungan dimana sistem informasi akan digunakan baik perangkat lunak maupun perangkat keras

4. Performance requirement

                Kebutuhan terkait dengan ukuran kualitas maupun kuantitas khususnya terkait dengan kecepatan, skalabilitas, dan kapasitas.

5. Documentation requirement

Kebutuhan ini terkait dengan dokumen apa saja yang disertakan pada akhir produk akhir

6. Support requirement

Kebutuhan yang terkait dukungan yang diberikan setelah sistem informasi digunakan. Dukungan teknis tersebut misalnya adanya pelatihan bagi calon pengguna

7. Miscellaneous requirement

Kebutuhan ini adalah kebutuhan-kebutuhan tambahan lainnya yang belum tercakup pada beberapa kategori kebutuhan yang telah terdefinisi di atas.

DEFINISI DESAIN SISTEM

Desain atau perancangan dalam pembangunan perangkat lunak

Merupakan upaya untuk mengkonstruksi sebuah sistem yang memberikan kepuasan (mungkin informal) akan spesifikasi kebutuhan fungsional, memenuhi target, memenuhi kebutuhan secara implisit atau eksplisit dari segi performansi maupun penggunaan sumber daya, kepuasan batasan pada proses desain dari segi biaya, waktu, dan perangkat.