Mungkin judulnya sedikit membingungkan, karena saya nggak bisa nemuin kata-kata yang cocok lagi buat judul. seperti yang ditulis di atas, seberapa penting rencana tes penerimaan sistem? tentu hal ini sangat penting karena dengan penerimaan ini berarti user telah mengakui bahwa sistem yang kita buat telah sesuai dengan kebutuhan dan permintaan user kepada kita. dengan kata lain pengakuan ini bisa membuktikan bahwa user puas dengan hasil milik kita. kenapa saya bisa mengatakan bahwa dengan pengakuan berarti user sudah puas? mari kita andaikan seperti kita membeli mobil. apabila kondisi dan performa mobil yang kita kehendaki sesuai dengan yang kita inginkan tentu kita akan puas dan mengakui kehebatan mobil tsb, tetapi bila tidak sesuai dengan yang kita inginkan maka kita akan kecewa dan akan mengajukan komplain kepada penjualnya. sama seperti dalam kasus kita ini, apabila sistem yang telah kita buat memiliki kekurangan atau kesalahan yang membuat user kecewa maka kita harus segera memperbaiki sistem tsb. kita perbaiki hingga benar-benar layak untuk digunakan oleh user terutama di sini adalah end-user.
apabila kita telah mendapat pengakuan secara tertulis dari user maka kita dapat menagih biaya pembuatan sistem tersebut kepada user. tentu saja ujung-ujungnya uang yang berperan dalam hal ini. bagaimana kita bisa mendapatkan pengakuan dari user? tentu saja kita harus mendemostrasikan kepada user sistem yang telah kita buat dan membuat user percaya bahwa sistem yang kita telah buat telah sesuai dengan kesepakatan yang telah dibuat sebelumnya.
beberapa hal yang dilakukan untuk Rencana Tes Penerimaan Sistem.
1. perdiode percobaan
dalam periode ini kita memberikan waktu kepada user untuk menggunakan sistem yang telah kita buat, apabila dalam periode waktu tersebut tidak ada kesalahan atau eror maka user dapat mempercayai sistem kita dan memberikan pengakuan terhadap sistem kita. bila terdapat eror atau salah dalam sistem kita maka kita harus langsung memperbaiki bagian sistem yang bermasalah tersebut dan memberikan periode kembali untuk user mencobanya. kelemahan dari cara ini adalah kita tidak tahu seberapa banyak kekurangan yang mungkin ada dalam sistem kita yang membuat user kurang puas, apabila hal ini terus berlanjut maka akan menghabiskan waktu yang sangat lama untuk periode percobaan.
2. solusi : penerimaan yang lengkap sedikit demi sedikit
ini adalah solusi yang dapat digunakan untuk menghadapi cara yang pertama di atas. dalam cara ini kita akan mendemostrasikan semua fungsi yang telah dijanjikan kepada user. serangkaian tes dan perintah yang dijalankan sistem disebut Rencana Tes Penerimaan (Acceptance Test Plan/ATP). kelebihan dari cara ini adalah kita dapat mendemostrasikan semua fungsi yang dijanjikan kepada user secara lengkap, kita juga dapat mengetahui langsung sumber masalah apabila terjadi kesalahan atau eror, dan user dapat nyaman karena dimbing untuk menggunakan sistem dengan benar dan tepat. kekurangan dari cara ini mungkin banyak pengerjaan untuk menulis ATP, selain itu user merasa asing juga dengan cara ini.
3. Pastikan semua yang dijanjikan akan diuji
kita harus memastikan apa yang dibutuhkan user dan yang kita sediakan telah ada semua dan harus diuji penggunaannya.
4. menulis percobaan
kita sudah tahu apa yang akan kita coba dari poin sebelumnya, maka pada bagian ini akan menulis bagaimana cara kita melakukan percobaan fungsi sistem tsb lalu menulis cara dan hasilnya.
5. daftar rencana tes penerimaan
Gunakan hal berikut sebagai daftar pengecekkan untuk semua kegiatan yang diperlukan untuk rencana penerimaan :
* Hasilkan Fungsi vs. Tabel Percobaan dan semua FS yang dijanjikan telah dialamatkan.
* Definiskan percobaan dan kumpulan percobaan.
* Tetapkan tanggung jawab untuk menulis percobaan.
* 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.
* 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.
6. kesimpulan untuk rencana tes penerimaan
anjurkan kepada user untuk menulis ATP dengan begitu user akan merasa bahwa mereka mengawasi sistem yang dia beli.
7. kesimpulan untuk tahap desain
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. Statistik menunjukkan bahwa pada akhir tahap disain diperkirakan seharusnya tidak lebih dari 10%.
0 komentar:
Posting Komentar