Analysis, Modelling and Design (1)

Post Comment

Sebelum kita beranjak untuk kembali mengingat apa itu Analysis, Modelling and Design , ada baiknya kita mencoba memilah bidang spesifik ilmu yang berada di rumpun komputer yaitu :


Information System atau sistem informasi adalah kombinasi manusia, data, proses, penayangan informasi dan teknologi informasi yang saling beriteraksi untuk mendukung dan melandasi operasi harian dalam bisnis sebaik dukungan dalam pemecahan masalah dan kebutuhan pengambilan Keputusan dari manajemen dan pengguna. [2]


Information Technology atau teknologi informasi adalah istilah sementara yang menggambarkan kombinasi teknologi komputer (perangkat keras dan perangkat lunak) dengan teknologi telekomunikasi (data, citra dan jaringan suara). [2]

Software Engineering atau yang diterjemahkan ke dalam bahasa Indonesia menjadi Rekayasa Perangkat Lunak, mencakup banyak bidang salah satunya adalah Project Management atau Manajemen Proyek. Lantas, mengapa manajemen proyek penting untuk dipelajari? Karena kebanyakan dari kita belajar hanya untuk ‘mroyek’ alias mengerjakan suat proyek tanpda didasari ilmu yang jelas bagaimana mengaturnya agar efektif dan efisien. [1]

Untuk bisa mengatur jalannya sebuah proyek (dalam hal ini khusus proyek perangkat lunak), tentu kita harus mengetahui alur terciptanya perangkat lunak sejak awal, yang dikenal dengan istilah SDLC (Software Development Life Cycle). Adapun SDLC yang banyak kita dengar, kita pelajar dan di praktekkan adalah SDLC model klasik, yang terdiri dari 5 tahapan proses seperti tergambar pada tangga proses berikut yang naik secara bertahap :



Banyak analis yang kurang berpengalaman membuat kesalahan kritis setelah menyelesaikan fase analisa masalah. Mereka lalu mulai melihat solusi alternatif. Satu dari banyaknya kesalahan yang muncul pada sistem informasi baru adalah mengilustrasikan pernyataan. Fase analisa kebutuhan menetapkan kebutuhan dari sebuah sistem baru. Kunci dari fase analisa kebutuhan adalah APA, buka BAGAIMANA. Analis sering kali disibukkan dengan solusi teknis yang kurang menegaskan kebutuhan bisnis. Fase ini harus menjawab pertanyaan “APA yang pengguna butuhkan dan inginkan sari sebuah sistem ?”. Fase ini sangat penting dalam menentuka kesuksesan sistem informasi. Dalam metodologi yang berbeda, fase analisa kebutuhan mungkin disebut fase definisi atau fase rancangan logika. [2]

Tugas utama dari fase analisa kebutuhan adalah untuk mengidentifikasi kebutuhan. [2] Yang terbagi menjadi dua jenis yaitu :
  1. Functional Requirement : yaitu gambaran aktivitas dan layanan yang harus sistem sediakan.
  2. Non Functional Requirement : yaitu gambaran fitur lain, karakteristik dan batasan yang menggambarkan sistem yang memuaskan.


Dalam pengembangan perangkat lunak ada dua macam cara umum yang dipakai yaitu :
  1. Blue Print based : seperti yang ditunjukkan pada gambar tangga proses diatas. Proses pembuatan secara bertahap, di mana setiap tahap harus ada persetujuan dan dokumentasi yang berisi konfigurasi dari tiap bagian terkecil perangkat lunak. Contoh dari cara ini adalah metode waterfall, incremental dan lain sebagainya.
  2. Agile based : berbeda dari cara blue print, agile lebih menekankan pada pemahaman terhadap kebutuhan perangkat lunak. Dikenal dengan convention / understanding. Contoh cara ini adalah : TDD (Test Driven Development), Extreme Programming dan Scrum.

Pada Blue Print Based tentunya akan menggunakan salah satu jenis pemodelan. Contohnya UML (Unified Modelling Language), namun meskipun menggunakan bahasa pemodelan yang sama, metodologinya bisa saja berbeda seperti yang dijelaskan pada grafik berikut :

Tentunya kita akan bertanya-tanya, jika bahasa pemodelannya sama mengapa harus ada dua metodologi yang berbeda? Hal tersebut lumrah untuk dipertanyakan karena selalu ada hal yang mendasarinya. Kemajuan industri rekayasa perangkat lunak sejalan dengan kemajuan industri IT pada umumnya yang didorong dari penelitian dan kebutuhan penrusahaan dan pengembang swasta. Bisa kita lihat diatas dua metodologi tersebut menggunakan tools yang berbeda pula karena di kembangkan oleh dua perusahaan yang berbeda.
Dalam mengkomunikasikan kebutuhan perangkat lunak kepada klien, tentunya tidak semua dapat dilakukan secara langsung dengan menggunakan bahasa pemodelan seperti UML, karena meskipun tim pengembang akan selalu dapat memahami apa maksud dari UML, tapi belum tentu terjadi pada klien. Adapun jenis – jenis klien menurut buku System Analysis and Design Methods adalah :
  1. Expert User : yaitu pengguna komputer berpengalaman yang menghabiskan sebagian besar waktunya menggunakan program aplikasi yang spesifik. Jenis pengguna ini biasanya menikmati untuk mengekplorasi dan membiarkan sedikit waktunya untuk memcoba memahami sebuah program aplikasi.
  2. Novice User :  terkadang disebut casual user,  ialah pengguna yang kurang berpengalaman dengan komputer yang hanya menggunakan komputer untuk sedikit kepentingan saja.

Maka dari itu, jika kita melihat lebih dalam terutama untuk para novice user tentunya akan muncul masalah dalam menyampaikan ide dan saran untuk pembuatan perangkat lunak. Maka GUI (Graphical User Interface) bisa jadi langkah yang sangat membantu dalam menyampaikan gambaran besar program. Dalam membuat rancangan GUI bisa dilakukan melalui program aplikasi khusus sepersti Microsoft Visio, Balsamiq Mockups dan lain sebagainya. Namun jika dilakukan secara manual pun (menggunakan sketsa kasar), tidak menjadi masalah karena yang penting adalah bagaimana ide dan keinginan klien dapat dihimpun.
Sehingga, pembuatan perangkat lunak yang tadi sudah dijelaskan melalui tangga tahapan SDLC, dapat kita lihat secara lebih jelas dari alur berikut ini :



Sekarang, mari kita beralih kepada bagaimana cara membuat use case yang baik (USE CASE NARATIVE)
1.      Ingat konsep tic tac toe antara actor dan system yang harus bisa saling memberi
2.      Narasi maksimal 2 paragraf, jika lebih bagi menjadi 2
3.      Masukkan tahap per tahap GUI
4.      Terdiri dari :
a.      sunny day schema, yaitu skema yang menampilkan langkah-langkah jika program berjalan normal. Contoh : sukses login, masuk ke beranda
b.      rainy day schema, yaitu skema yang menampilkan langkah-langkah jika program tidak berjalan normal. Contoh : gagal login, program menampilkan keterangan nama pengguna atau kata sandi yang salah



Sumber :
  1. Kuliah perdana “Analysis, Modelling and Design” , S2 Sistem Informasi ITS oleh Pak Radityo
  2. Buku “System Analysis and Design Methods : Fifth Edition” , Jeffrey L Whitten, Lonnie D Bentley.



Tags:

Share:

0 komentar