2.) Apa saja yang perlu dicek pada kegiatan 'Rencana Penerimaan'?
Jawab :
Tujuan dari penerimaan adalah mendapatkan pernyataan
tertulis dari user bahwa produk (dalam hal ini sistem) yang dikirim sesuai
dengan yang dijanjikan. Berikut langkah-langkah “Rencana Test Penerimaan” :
· PERIODE
PERCOBAAN ATAU PARALLEL RUN
(THE TRIAL PERIOD OR
PARALLEL RUN)
Periode percobaan atau parallel
run adalah pendekatan yang paling umum untuk penerimaan.
Menggunakan pendekatan „Periode Percobaan‟ tim proyek mudah memasang sistem
baru untuk dicoba oleh user. Pendekatan ‘Parallel
Run’ menambahkan dimensi untuk peralihan sistem lama yang sudah
berjalan dengan baik sebagai perbandingan dan cadangan. Dalam kedua kasus ini
klien menggunakan sistem baru selama „X‟ hari. Jika tidak ada masalah maka user
menerimanya, jika ada masalah maka tim proyek berusaha memperbaikinya dan
melakukan kembali percobaan selama „X‟ hari.
· PENERIMAAN
YANG LENGKAP SEDIKIT DEMI SEDIKIT
(SOLUTION : A THOROUGH
BUT PIECEMEAL ACCEPTANCE)
Pendekatan yang lebih baik adalah menemukan serangkaian tes
yang mendemonstrasikan semua fungsi yang dijanjikan. Penerimaan akan dilakukan
secara resmi melalui seluruh tes ini kepada pelanggan. Keberhasilan tes
diakhiri satu per satu. Jika sebuah tes gagal, Tim proyek dengan penuh harapan
memperbaiki masalah langsung di tempat pengujian. Jika itu masalah utama maka
tes ditunda sampai masalah dapat diperbaiki. Dalam teori hanya tes yang gagal
yang diulang, walaupun user memiliki hak untuk menjalankan kembali tes yang
diterimanya sesudah perbaikan.
Serangkaian tes dan perintah yang dijalankan sistem
disebut Rencana Tes Penerimaan (Acceptance Test Plan / ATP).
· MEMASTIKAN
BAHWA SEMUA YANG DIJANJIKAN AKAN DIUJI
(ENSURING THAT ALL THE
PROMISES ARE TESTED)
Untuk memastikan semua yang dijanjikan akan dites langsung
melalui Spesifikasi Fungsi halaman demi halaman, paragraf demi paragraf, dan
buat daftar semua fungsi yang dapat dites.
· MENGGUNAKAN
DESAIN (USING THE DESIGN)
Anda mungkin berfikir mengapa saya menyarankan mengerjakan
ATP setelah disain dikerjakan. Sesungguhnya anda hanya memerlukan Spesifikasi
Fungsi untuk menghasilkan ATP. Tetapi, disain membantu untuk menggelompokkan
tes ke dalam serangkaian tes yang mendemonstrasikan fungsi utama dari sistem.
Anda dapat menjalankan tes pada perintah atas bawah yang sama seperti TLD, yang
dapat dimengerti dengan baik oleh user anda. Pendekatan sistem ABC seperti
dalam TLD (gambar 7.1), anda dapat mendemonstrasikan semua menu, kemudian
seluruh keterangan yang diminta, diikuti dengan semua update, dsb. Cara lain
untuk mengelompokkan kumpulan tes adalah dengan fungsi. Melalui semua fungsi
Registrasi, diikuti oleh fungsi Administrator, dsb
· MENULIS
PERCOBAAN (WRITING TEST)
Anda sudah siap menentukan bagaimana anda akan menguji item
ketika pengisian pada METODE PERCOBAAN
· DAFTAR
RENCANA TES PENERIMAAN
(THE ACCEPTANCE TEST PLAN
CHECKLIST)
Gunakan hal berikut sebagai daftar pengecekkan untuk semua
kegiatan yang diperlukan untuk rencana penerimaan :
1. Hasilkan Fungsi vs.
Tabel Percobaan dan semua FS yang dijanjikan telah dialamatkan.
2. Definiskan percobaan
dan kumpulan percobaan.
3. Tetapkan tanggung
jawab untuk menulis percobaan.
4. Klien dan Tim proyek
mengetahui bahwa ATP akan ditinjau kembali, direvisi jika perlu, dan
ditandatangani oleh user. Klien mengetahui bahwa keberhasilan penyelesaian dari
percobaan akan mempengaruhi penerimaan sistem. Lihat bentuk contoh ATP pada
bagian 10 di Appendix A.
5. Tanggung jawab untuk
percobaan data telah ditetapkan. Data untuk percobaan seharusnya disediakan
oleh tim proyek dan juga user. Jika user dapat menyediakan data yang sesuai
dengan keadaan yang sebenarnya, percobaan terhadap sistem akan berjalan dengan
baik, ditambah user akan merasa nyaman dengan keakuratan percobaannya.
· KESIMPULAN
UNTUK RENCANA TES PENERIMAAN
(CONCLUSION TO THE
ACCEPTANCE TEST PLAN)
Menganjurkan user untuk menulis ATP jika dia mampu. Hal ini
akan memberikan dia perasaan mengawasi – tim proyek harus membangun sistem
melalui percobaan.
· KESIMPULAN
UNTUK TAHAP DISAIN
(CONCLUSION TO THE DESIGN
PHASE)
Pada akhir tahap disain kita menempuh beberapa kejadian
penting sebagai berikut :
1. Dokumen Spesifikasi Disain memuat disain akhir tingkat
atas melalui disain tingkat menengah.
2. Tanggung jawab ATP disahkan dan dimulai. Ini tidak perlu
diselesaikan sampai tahap penerimaan.
3. Rencana proyek, khususnya perkiraan perlu ditinjau
kembali. Walaupun anda sedang memperkirakan hanya 4 tahap yang telah
disebutkan, tahap pemrograman mungkin akan menjadi tahap yang sangat mahal dan
membutuhkan waktu yang sangat banyak dalam keseluruhan kerja proyek. Disain
memberikan anda perkiraan perhitungan jumlah modul-modul dan kerumitannya.
Sekarang anda mungkin tahu siapa programmer-programmer yang dapat diandalkan,
sehingga anda dapat mempertimbangkan faktor produktivitas mereka. Dengan informasi
ini waktu pemrograman yang diperlukan dapat dengan mudah diperkirakan (lihat
BAB 13). Statistik menunjukkan bahwa pada akhir tahap disain diperkirakan
seharusnya tidak lebih dari 10%.
Sumber : rudity.staff.gunadarma.ac.id/Downloads/.../bab+8.doc