Testing dan Implementasi Sistem Informasi : Bab 7

PERANGKAT PENGUJIAN

Perangkat pengujian digunakan untuk membantu menentukan apakah factorfaktor
pengujian telah cukup dilakukan pada fase kebutuhan. Rekomendasi
yang diberikan untuk penggunaan perangkat pengujian adalah alat Bantu
walkthrough dan alat Bantu Mantriks Resiko.

Walkthrough
Tujuan penggunaan alat Bantu walkthrough menciptakan sebuah situasi
dimana suatu tim terdiri dari individu yang terlatih yang dapat menolong tim
proyek dalam pengembangan solusi proyek.
Walk through menggunakan pengalaman dan keputusan review tim sebagai
tambahan atau bantuan dalam proses pembangunan, berorientasi pada
bimbingan dalam pemecahan masalah dibandingkan dengan pemenuhan
pelaksanaan metodologi.

Lima langkah penggunaan alat bantu Walkthrough :
1. Menyusun aturan-aturan dasar
Aturan dasar bersifat umum, walkthrough paling produktif ketika aturan
dasar diterapkan sebelum walkthrough yang seseungguhnya. Aturan dasar
harus dimengerti oleh tim proyek maupun tim walkthrough.

Aturan dasar terdiri dari :
1. Ukuran dan susunan tim walkthrough
2. Tanggung jawab tim walkthrough (terbatas pada rekomendasi dan
pertanyaan)
3. Kewajiban tim proyek menjawab seluruh pertanyaan dan merespon
rekomendasi
4. Perkiraan waktu dan lokasi walkthrough
5. Kerahasiaan informasi yang didiskusikan
6. Aspek sistem yang tidak dapat dihadapi dan didiskusikan
7. Siapa yang akan menerima hasil walkthrough dan bagaimana hasil
tersebut dapat digunakan

2. Memilih tim/memberitahu partisipan
Tim walkthrough harus diseleksi berdasarkan tujuan yang akan dicapai.
Beberapa pihak yang terlibat (misalnya : user, service information dan senior
management) dapat merekomendasikan partisipan tim walkthrough. Hal ini
berdasarkan kepentingan proyek. Partisipan yang umum ada di dalam tim,
adalah :
1. Information Services Project Manager/analis sistem
2. Senior management
3. Operations management
4. User
5. Management
6. Konsultan yang sesuai. (Konsultan auditor internal, administrator
database, konsultan komputer independen)

3. Presentasi proyek
Tim proyek mempresentasikan kebutuhan proyek kepada tim walk through,
yang direpresentasikan adalah :
1. Pernyataan sasaran dan tujuan proyek,
2. Latar belakang informasi, termasuk statistic bisnis yang tepat dalam area
aplikasi yang sedang berjalan dan yang diajukan
3. Daftar pengecualian yang dibuat oleh tim proyek,
4. Mendiskusikan tentang alternative yang ada dan yang akan dipilih
5. Kebutuhan walkthrough menggunakan transaksi representative sebagai
basis untuk walkthrough

4. Pertanyaan/Rekomendasi
Tujuan pertanyaan/rekomendasi adalah untuk membangkitkan diskusi

5. Laporan akhir (optional)
Matriks Resiko
Matriks resiko adalah suatu alat bantu yang dirancang untuk menilai kecukupan
pengendalian dalam sistem komputer. Kendali disini berarti bahwa semua
mekanisme. Metode dan prosedur yang digunakan dalam aplikasi. Diperkirakan
bahwa sistem otomatisasi dalam pengendaliannya memerlukan setengah
usaha dari pengembangan secara keseluruhan. Oleh karena itu, usaha yang dikeluarkan untuk memastikan kelengkapan kendali merupakan hal yang penting bagi kesuksesan dan kredibilitas sistem aplikasi.

Empat langkah alat bantu matriks resiko :
1. Identifikasi tim resiko
Kunci untuk memperoleh matriks resiko yang benar adalah penetapan tim
resiko yang benar, siapa yang akan bertanggung jawab untuk melengkapi
matriks. Tujuan dari pelengkapan matriks adalah untuk menentukan
kelengkapan kebutuhan dan rencana kendali untuk mengurangi resiko
hingga level yang dapat diterima.

Tim resiko harus memiliki minimum keahlian :
1. Memiliki pengetahuan mengenai aplikasi user,
2. Mengerti konsep resiko,
3. Mampu mengidentifikasi kendali,
4. Terbiasa dengan resiko aplikasi dan resiko information services,
5. Mengerti konsep layanan informasi dan perancangan sistem,
6. Mengerti prosedur operasi komputer

Kandidat yang termasuk dalam tim resiko minimal satu dari user dan yang
lainnya dari : Internal auditor, konsultan resiko, pemroses data, petugas
keamanan, dan manajer operasi computer

2. Identifikasi resiko
Tujuan pertama dari tim resiko adalah untuk mengidentifikasi resiko
berorientasi aplikasi, bukan lingkungan, berkaitan dengan sistem aplikasi.
(Resiko yang berkaitan dengan seluruh aplikasi).
Terdapat dua metode untuk mengidentifikasi resiko :
a) Skenario analisis resiko
Tim resiko melakukan brainstorming resiko aplikasi yang potensial dengan
menggunakan pengalaman, penilaian dan pengetahuan mengenai wilayah
aplikasi.
b) Ceklist resiko
Tim resiko diberi sejumlah resiko yang kerap muncul dalam sebuah
aplikasi otomasi. Dari daftar tersebut, tim akan memilih resiko yang
mungkin.

3. Menetapkan objektif pengendalian (tahap requirement)
Tujuan pengendalian untuk setiap resiko harus ditetapkan, ketika kendali
dapat dinyatakan secara terukur, maka pengendallian tersebut untuk
mencapai tujuan memiliki kebutuhan untuk menggunakan kendali
keputusan. Kecukupan kendali tidak dapat diuji sampai tingkat kehilangan
resiko dapat diterima.

4. Mengidentifikasikan kendali pada setiap segmen sistem (Tahap perancangan)
Selama tahap perancangan, tim resiko akan mengidentifikasikan kendali
pada setiap tahap dari setiap aplikasi untuk setiap resiko yang diidentifikasi,
yaitu :
a) Keaslian : pembuatan dokumen sumber ditambah dengan otorisasi
berkaitan dengan transaksi keaslian tersebut
b) Masukan data : transfer informasi ke media yang dapat dibaca mesin
c) Komunikasi : perpindahan data dari satu titik dalam system ke titik yang
lain (perpindahan dapat berupa manual atau elektronik)
d) Pemrosesan : aplikasi logika system ke data
e) Penyimpanan : penyimpanan data, baik untuk waktu sementara maupun penyimpanan tetap
f) Keluaran : translasi data dari media computer ke median yang dapat dimengerti dan digunakan oleh manusia
g) Penggunaan : keputusan bisnis tergantung dari hasil pemrosesan system Penilaian yang digunakan dalam matriks resiko

1. Sangat Lengkap : tim proyek telah melakukan lebih dari yang diharapkan
untuk kriteria tersebut
2. Evaluasi yang lengkap : tim proyek telah melakukan kerja yang cukup untuk
memastikan kendali yang layak untuk kriteria tsb
3. Penilaian yang tidak lengkap : tim proyek belum melakukan kerja yang cukup
dan harus melakukan kerja lebih dalam daerah kriteria
4. Tidak dapat dipagai (Not Applicable – NA) : berkaitan dengan tipe aplikasi
atau filosofi perancangan sistem dimana implementasi kriteria tidak dapat
dipakai untuk aplikasi tersebut.

Iklan

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s