UAS MMT

Iterative & Incremetal Development Model
(Contoh Kasus Address Book)

Model ini merupakan salah satu model pengembangan perangkat lunak. Model ini merupakan pengembangan dari model Waterfall yang dikombinasikan dengan model Prototyping. Gambar 1 memperlihatkan tahapan-tahapan yang dilakukan pada model ini.

Gambar 1

Seperti yang terlihat pada gambar, model ini merupakan model Waterfall yang diulang-ulang, dan setiap pengulangan (increment) menghasilkan sebuah Prototype yang berfungsi dengan baik sehingga dapat digunakan oleh user. Pada increment pertama, difokuskan pada pembuatan fitur utama dari produk perangkat lunak yang dibuat. Kemudian pada increment-increment berikutnya adalah pembuatan fitur-fitur tambahan dari perangkat lunak tersebut. Increment akan dilakukan terus menerus sampai perangkat lunak menjadi sempurna dan sesuai dengan keinginan user.

Seperti yang disebutkan di atas, tahapan-tahapan dalam sebuah increment merupakan tahapan model Waterfall, yaitu:

1. Analisa
Pada tahapan ini, dilakukan Requirement Gathering yaitu mengumpulkan kebutuhan-kebutuhan dari user. Kegiatan ini (Requirement Gathering) dilakukan dengan beberapa macam metode, seperti wawancara, analisa dokumen, JAD, dll. Bila wawancara adalah kegiatan yang dilakukan dalam mengumpulkan dokumen, maka wawancara tersebut harus didokumentasikan dengan baik, misalnya dalam bentuk seperti Elicitation Notes.

Elicitation Note

Setelah kebutuhan user dikumpulkan, kemudian dilakukan analisa terhadap hasil-hasil Requirement Gathering. Kegiatan ini menghasilkan dokumen Software Requirement Specification (SRS). Dalam dokumen ini dijelaskan mengenai fitur-fitur yang diinginkan oleh user.

SRS

2. Desain
Pada tahapan ini, dilakukan proses desain berdasarkan dokumen SRS. Proses desain ini mendesain beberapa faktor, antara lain detail prosedur (algoritma), desain struktur data, desain tampilan/antarmuka dan arsitektur perangkat lunak. Desain ini kemudian didokumentasikan ke dalam Software Design Specification (SDS).

SDS

3. Coding
Pada tahapan inilah perangkat lunak mulai dibuat dengan menggunakan bahasa pemrograman seperti yang telah disyaratkan dalam dokumen sebelumnya (SDS).

4. Testing
Pada tahapan ini, hasil dari coding diuji untuk mendapatkan kesalahan-kesalahan yang ada, sebelum pada akhirnya perangkat lunak dapat dikirim dan digunakan oleh user. Tahapan ini merupakan kegiatan yang penting dalam menjamin kualitas dari perangkat lunak yang dibuat. Oleh karena itu, testing harus dilakukan secara terstruktur dan terencana agar uji terhadap perangkat lunak dapat dilakukan dengan menyeluruh. Perencanaan terhadap testing dituangkan dalam dokumen Test Scenario, yang memuat skenario uji dari setiap aspek yang ada dalam perangkat lunak.

Test Scenario

Hasil dari satu siklus kegiatan di atas kemudian dikirimkan ke user.

Untuk memastikan bahwa kebutuhan user telah dibuat dan tidak terlewatkan, dibutuhkan sebuah dokumen Requirement Traceability Matrix (RTM). RTM merupakan bagian dar proses verifikasi dalam pengembangan pernagkat lunak.

RTM

JAWABAN UTS

Pada metode incremental, terdapat tahapan-tahapan

Pada tahapan analisa, kegiatan yang dilakukan adalah melakukan requirement gathering (pengumpulan kebutuhan) dan kemudian requirement (kebutuhan) tersebut dianalisa.

Salah satu metode yang dapat dilakukan dalam melakukan pengumpulan kebutuhan adalah analisa terhadap dokumen, dimana pada kasus ini, dokumen tersebut adalah soal UTS. Output yang dihasilkan pada proses pengumpulan kebutuhan adalah elicitation notes. Penulisan elicitation note tidak mempunyai format yang baku dan tergantung dari metode yang digunakan. Elicitation note dengan metode analisa dokumen mempunyai format yang berbeda dengan metode wawancara, Joint Application Development atau questioner. Di bawah ini adalah elicitation note yang dihasilkan.

ELICITATION NOTE
NAMa proyek	SmartParking
DOkUMEN	Soal UTS
tanggal analisa	1 April 2009
versi	1.0
kebutuhan non fungsional
1. Kebutuhan Operasional 1.1. petugas parkir adalah operator yang terdaftar dalam sistem 1.2. petugas parkir yang memasukkan data nomor plat ke dalam sistem (tidak ada scanner nomor plat) 1.3. data yang harus disimpan dalam database adalah data nomor plat kendaraan, data otentikasi petugas parkir (username dan password), jam masuk dan jam keluar kendaraan dan total biaya parkir 1.4. sistem tidak mengatur vallet parking 2. Kebutuhan Performa 2.1. proses pencatatan sampai dengan mencetak karcis parkir pada saat kendaraan akan memasuki area parkir tidak boleh lebih dari 30 detik untuk mencegah antrian yang panjang 2.2. proses pencarian data nomor plat dan penghitungan total biaya parkir untuk kendaraan yang keluar area parkir tidak boleh lebih dari 30 detik untuk menghindari antrian panjang 3. Kebutuhan Keamanan 3.1. harus ada otentikasi petugas parkir
kebutuhan fungsional
1. Otentikasi petugas parkir 1.1. pada saat petugas parkir akan bertugas, maka petugas tersebut harus memasukkan data otentikasi melalui keyboard. 2. Mencatat kendaraan masuk 2.1. pada saat kendaraan akan masuk ke area parkir, nomor plat kendaraan tersebut dimasukkan ke dalam sistem. 2.2. sistem akan mencatat/menyimpan nomor plat, data petugas parkir dan jam masuk kendaraan 2.3. sistem mencetak karcis parkir 3. Mencatat kendaraan keluar 3.1. pada saat kendaraan akan keluar area parkir, nomor plat dan jam keluar dimasukkan ke dalam sistem 3.2. sistem akan menghitung selisih jam keluar dan jam masuk untuk menghitung total biaya parkir

Setelah semua kebutuhan telah dikumpulkan, kemudian dibuat sebuah dokumen SRS (Software Requirement Specification) seperti dapat dilihat di link ini.