Pertemuan 15

Minggu ke-8

Final Project: Workshop 2

Pembuatan Test Case

Daftar Isi
1. 2. 3. 4. 5. 6. 7. Tujuan Mendefinisikan Proses Bisnis dengan Narasi Use-Case Work 1: Definisi Proses Bisnis Work 2: Mockup UI Work 3: Implementasikan CDM ke Access Work 4: Buat form di access sesuai mockup UI Luaran yang diharapkan

[ MANAJEMEN BASIS DATA]

Jurusan Sistem Informasi - Fakultas Tekonologi Informasi Institut Teknologi Sepuluh Nopember
Rully Hendrawan eraha_id@yahoo.com, eraha@is.its.ac.id

1. Tujuan Fokus aktivitas Final Project minggu ini adalah membuat dan menjelaskan kasus penggunaan (use-case) dari sistem yang Anda usulkan sebagai FP. Dengan asumsi, sudah memiliki bayangan yang cukup detil tentang FP yang dibuat, mulai dari sketsa UI sampai dengan desain konseptual (CDM) dari basisdata.

Setiap kelompok membuat 3 use-case yang nantinya akan dipakai oleh kelompok lain untuk menguji sistem yang Anda bangun.

Karena keterbatasan waktu, selama 2.5 jam Anda memiliki waktu untuk menyelesaikan sebuah use case dengan dipandu dan dibimbing oleh Asisten FP.

Terbagi kedalam 4 sesi dalam dua iterasi, yaitu dua kali

1. 2. 3. 4. Work 1: Definisi Proses Bisnis (15 menit) Work 2: Mockup UI (15 menit) Work 3: Implementasikan CDM ke Access (5 menit) Work 4: Buat form di access sesuai mockup UI (25 menit)

Ketika waktu habis, langsung lanjutkan ke proses berikutnya.

Sisa use-case dilanjukan secara terpisah, silakan berkoordinasi dan memohon petunjuk kepada Asisten FP terkait.

2. Mendefinisikan Proses Bisnis dengan Narasi Use-Case Apa itu Use-case? Misal kita memiliki sebuah handphone, handphone ini beraneka ragam rasa bentuk dan yang paling penting adalah cara menggunakannya /memanfaatkannya. HP (singkatan dari henfon, saya juga tidak tahu kenapa tidak disingkat menjadi HF) bisa dipakai untuk mengganjal pintu, menjaga kertas supaya tidak betebaran ditiup angin, menidurkan bayi dengan melantukan nada2 dering, dan seterusnya bergantung pada kreativitas pemilik. Kasus pendayagunaan itulah yang kita sebut dengan use-case. Perlukah kita mencantumkan semua Use-case? Tidak disarankan dan jangan! Sampai kiamat berakhir juga tidak akan selesai. Yang perlu dikonsepkan adalah main use-case, atau use-case utama. Karena kesepakatan bersama inilah, istilah use-case selalu merujuk kepada adalah kasus pendayagunaan yang paling umum. Seperti pada contoh HP, use-case HP bukanlah untuk pengganti batu pengusir setan pada saat lempar jumroh. Sepakat?! Ok, kalau begitu apakah use-case HP? Menelfon, meng-sms?? ... juga bukan. Layanan komunikasi suara dan pesan singkat adalah FITUR! Fitur diturunkan dari use-case. Use-case HP secara abstrak adalah untuk komunikasi langsung maupun tak langsung. Salah satu use-casenya yaitu menyampaikan pesan yang tidak genting (seringnya juga tidak penting). Fitur yang digunakan dalam use-case ini adalah SMS, bisa juga MMS, email, ataupun SMAIL.

Mulai dari use-case dulu atau fitur? Dalam membuat SISTEM informasi, selalu mulailah dari use-case. Anda harus yakin bahwa setiap fitur yang akan dibangun selalu bermanfaat dalam menjawab permasalahan bisnis yang ada. Bayangkan pada tempat duduk WC ada tombol untuk mengeluarkan odol pasta gigi di sebelah tombol untuk menyiram air. Tidak penting bukan? Fitur adalah REALISASI dari use-case. Kalau Anda memulai dari Fitur, sangat mudah untuk melupakan tujuan pembuatan fitur tersebut. Bagaimana menjelaskan use-case kepada orang lain? Notasi yang umum digunakan saat ini adalah use-case diagram pada UML. Namun dalam mata kuliah kali ini kita belum saatnya belajar UML, sehingga yang kita gunakan adalah use-case naration. Apa itu use-case naration? Adalah penjabaran bagaimana kasus pendayagunaan dilakukan. Ada dua subjek yang berperan yaitu pengguna dan sistem. Pengguna dan sistem akan berinteraksi secara timbal balik sampai sebuah use-case selesai dilakukan. Bisa dicontohkan sebuah use-case naration? Contohnya use-case pengambilan uang pada ATM. Apakah sistemnya? ... Mesin ATM. Siapakah pengguna sistem? ... Orang yang butuh uang Nasabah. 1. Sistem menampilkan iklan-iklan tidak mutu dan kadang memunculkan tulisan "Silakan masukkan kartu ATM" 2. Nasabah memasukkan kartu ATM ke Sistem 3. Sistem memunculkan "Silakan masukkan 6 digit PIN Anda" 4. Nasabah menggunakan keypad untuk memasukkan PIN 5. Sistem menampilkan pilihan menu, menu ke 53 adalah untuk penarikan uang

6. Nasabah memilih menu 53 7. Sistem menampilkan menu cepat, sejumlah uang yang biasa ditarik (100rb, 500rb, 1jt, 100m, dst) atau jumlah yang lain 8. Nasabah memilih memasukkan jumlah lain menggunakan keypad numerik 9. Sistem menanyakan berapa jumlah uang yang diambil 10. Nasabah memasukkan sesuai niatnya (misal 1000 Rp) kemudian menekan ENTER 11. Sistem menanyakan apakah butuh nota cetak (YA/TIDAK) 12. Nasabah menekan tombol YA 13. Sistem mengeluarkan sejumlah uang, satu kartu ATM, dan satu bukti cetakan disertai tulisan terimakasih serta do'a agar uang yang diambil ini menjadi berkah dan dipakai di jalan yang benar. Bagaimana jika terjadi kegagalan / kecelakaan / kejanggalan? Narasi use-case selalu menceritakan kisah pendayagunaan yang sukses. Apabila ada kegagalan baik karena pengguna maupun sistem, tuliskan ke dalam catatan perkecualian (exception). Misal: - PIN ditolak karena tidak sama dengan data yang ada disistem, atau pengguna lupa cuci tangan. - Jika PIN tertolak tiga kali (sudah 2 kali ditolak, masih nafsu aja) sistem akan memblokir akses pengguna demi keamanan dan kenyamanan (memangnya enak, menolak 3 kali??). - Jika uang yang ditarik kurang dari saldo maka tampilkan tulisan "Mohon maaf rejeki Anda belum mencukupi" dan kembali ke menu awal.

3. Work 1: Definisi Proses Bisnis Waktu: 15 menit

Definisikan proses bisnis dari use-case yang paling penting Sistem dipakai siapa? Untuk apa? Dalam bentuk narasi pemakaian Sekali lagi, utamakan use-case yang paling penting

4. Work 2: Mockup UI Waktu: 15 menit

Ambil selembar (boleh lebih), kertas A4. Tips: Lipat menjadi 2 bagian kemudian lipat lagi menjadi 2. Sehingga kertas terbagi menjadi 8 lokasi yang bisa dibayangkan sebagai 8 form.

Sesuai dengan definisi use-case buatlah form2 yang saling berhubungan, sesuai dengan bayangan Anda. Contoh form mockup:

Alur Form untuk Pembeli

Alur Form untuk Penjual *)

*) Sam Ruby, Dave Thomas, David Heinemeier Hansson, Agile Web Development with Rails, Fourth Edition,

5. Work 3: Implementasikan CDM ke Access Waktu: 5 menit

Buka kembali CDM yang telah Anda buat. Pilih lah entitas-entitas yang berkaitan dengan use-case yang telah dibuat, diskusikan dengan Asisten. Generate CDM menjadi PDM Generate PDM menjadi Access TIPS: 1. Apabila ada tabel yang hilang, kemungkinan besar karena tipe data yang didefinisikan di PDM tidak ada di Access. Cek kembali tipe data. 2. Tidak bisa membuat DSN di ODBC? Generate PDM menjadi sql script (crebas.sql), copy dan paste ke dalam Access pada form SQL dan eksekusi!

6. Work 4: Buat form di access sesuai mockup UI Waktu: 25 menit

Buatlah form-form sesuai dengan mockup yang telah dibuat. Mulailah dari form yang paling sulit. Jika form tersebut membutuhkan form lain (lookup / sub form), tinggalkan sejenak form itu dan selesaikan sesegera mungkin form yang dibutuhkan.

7. Luaran yang diharapkan Lanjutkan Final Project Anda, dengan membuat minimal 3 contoh use-case dalam sistem yang Anda buat. Ada dua bentuk laporan yang harus dikumpulkan, yang pertama adalah untuk Asisten sebagai nilai evaluasi Progress FP. Yang kedua, dipakai untuk melaksanakan pengujian di minggu berikutnya.

BAGIAN 1

Paling lambat hari Sabtu, 22 Oktober 2011 Sebagai bahan evaluasi minggu ini, kumpulkan dokumen yang anda hasilkan di setiap langkah ke Asisten FP masing-masing. Asisten FP juga berperan sebagai evaluator. Dokumen yang harus disertakan untuk setiap use-case adalah: 1. Proses bisnis dalam bentuk use-case naration (fisik, atau soft copy) 2. Mockup UI (fisik) Minimal 3 use case, sehingga masing-masing dokumen diatas akan ada 3. Setiap kelompok juga harus menyertakan versi terakhir dari: 1. CDM 2. Access (accdb)

Kriteria penilaian untuk pembuatan use-case: 1. Berapa use-case yang terbentuk 2. Apakah narasi use-case cukup detil dalam menjawab kebutuhan 3. Mockup UI dapat menjelaskan dan sesuai dengan proses bisnis dalam use-case 4. Perkembangan / improvisasi CDM

5. Apakah Form access sesuai dengan Mockup UI dan kebutuhan

BAGIAN 2

Paling lambat hari Senin, 31 Oktober 2011 Ingat! Dokumen use-case ini yang nanti akan dipakai oleh kelompok lain untuk menguji sistem yang Anda buat. Pengujian peer (antar kelompok) dilaksanakan pada P17. Dokumen diserahkan dalam bentuk softcopy (docx). Struktur isi dokumen bebas, yang penting terstruktur dengan rapi. Dokumen berisikan penjelasan testing untuk setiap use-case: Proses bisnis dalam bentuk use-case naration Urutan penyelesaian (boleh instruksi tertulis, atau menggunakan ilustrasi mockup UI sebelumnya jika form dan mockup ternyata sama, atau screenshot form access) Nama file diawali dengan kode kelas dan nomor urut kelompok (dipisah dash, tanpa spasi). Misal: B-01-terserah_anda.docx Dikumpulkan di 10.126.10.20

Kriteria penilaian uji sistem (dipakai minggu depan): 1. Definisi fungsionalitas (berapa use case yang siap diuji dan kualitasnya, berapa tabel / form yang dibuat) 2. Realisasi fungsionalitas (berapa form yang bisa dipakai, apakah sesuai dengan use-case / kebutuhan)

Akhir Dokumen