SYIFA A.

MUKDAS
1113U015

PART III THE APPLICATION CONTROL FRAMEWORK

(part III Penerapan Pengendalian Kerangka Kerja (framework))

CHAPTER 11 INPUT CONTROLS

(chapter 11 Pengendalian Kontrol)

BATCH CONTROLS

Beberapa kontrol sederhana dan paling efektif terhadap data capture dan entri kegiatan
adalah batch controls. Batching adalah proses pengelompokan transaksi bersama yang
menanggung beberapa jenis transaksi yang menanggung beberapa jenis hubungan satu sama lain.
Berbagi kontrol yang dapat dilakukan selama batch untuk mencegah dan mendeteksi kesalahan
atau penyimpangan.

Jenis Batch

Ada dua tipe pada batch: batch secara fisik dan bacth secara logis. Batch secara fisik
adalah kelompok transaksi yang merupakan unit fisik. Contohnya, sumber dokumen yang
mungkin diperoleh melalui pos, dirakit menjadi batch, dibubuhi dan diikat bersama-sama, dan
kemudian diberikan kepada petugas entri data yang akan dimasukan ke dalam sistem aplikasi di
terminal. Demekian pula, dengan dokumen yang dimasukan kedalam sebuah sistem elektronik
yang mungkin dirakit kedalam batch sebelum mereka dipindai atau difilmkan.

Batch secara logis adalah kelompok transaksi yang terikat bersama-sama pada beberapa
logis yang dasar, dibandingkan dengan fisik berdekatan. Contohnya, perbedaan petugas yang
mungkin menggunakan terminal yang sama untuk memasukan transaksi kedalam sebuah sistem
aplikasi. Petugas tetap mengkontrol total dari transaksi bahwa mereka telah memasukakannya.
Program input yang logis akan masuk kedalam grup transaksi atas dasar nomor identifikasi
pegawai. Setelha beberapa periode telah berlalu, kemudian mempersiapkan kontrol secara total
untuk rekonsiliasi dengan kontrol dari pegawai tersebut.
 Pengertian Kontrol Batch

Dua dokumen dibutuhkan untuk membantu menjalankan kontrol terhadap batch secara
fisik: penutup lembar batch dan kontrol batch yang terdaftar. Selembar penutup batch (Figure
11-7) berisi jenis informasi berikut:

1. Nomber batch yang unik;

2. Kontrol total untuk setiap batch;
3. Data umum untuk berbagai transaksi dalam batch, contohnya, tipe transaksi;
4. Tanggal ketika sebuah batch disiapkan;
5. Informasi yang eror akan teridentifikasi didalam batch;
6. Ruang untuk tanda tangan personil yang menangani batch dalam beberapa cara,
contohnya, seorang yang menyiapkan batch dan orang yang mengetik batch.

Daftar batch kontrol (Figure 11-8) mencatat transit batch secara fisik diantara berbagai
lokasi dalam sebuah organisasi. Setiap orang memungkinkan untuk menangani batch yang ada
pada daftar batch. Dafta tersebut ditanda tangani setiap kali batch tersebut diterima atau dikirim.
Dari beberpa kasus seseorang mangambil alih tanggung jawab untuk sebuah batch dan juga
mengecek isinya. Jika terjadi perselisihan pada likasi batch, maka daftar batch control akan
dapat dikonsultasikan.

Figure 11-7

Figure 11-8

Untuk mengidentifikasi kesalahan atau penyimpangan dikedua batch secara fisik dan
logis, tiga total tipe kontrol dapat dikalkulasikan:

Jenis Kontrol Total Penjelasan

Total keuangan Jumlah total yang dikalkulasikan disetiap lapangan yang
menghitung jumlah uang.
Total hash Jumlah total yang dikalkulasikan untuk setipak kode yang
ada didokumen pada batch, contohnya, nomor seri pada
sumber dokumen dapat mencapai total.
Dokumen/catatan yang terhitung Jumlah total untuk nomor pada dokumen atau catatan pada
batch.
 Didalam kasus batch secara fisik, total tersebut dapat dituliskan di dalam halaman
depan batch dan diketik ke dalam sistem aplikasi sebelum masuk ke transaksi utama dalam
batch. Program masukan kemudian menghitung jumlah batch transaksi yang dimasukkan. Ketika
memasukkan semua transaksi ke dalam batch telah selesai, itu membandingkan total yang
dihitung terhadap total masuk dan sinyal kejanggalan.

Dalam kasus batch logis, orang yang bertanggung jawab untuk memasukkan data harus
menjaga rekaman independen transaksi yang masuk ke dalam sistem aplikasi. Secara berkala,
jumlah batch dihitung dengan program masukan kemudian harus dibandingkan dengan jumlah
angkatan dihitung pada dasar-dasar catatan independen.

Desain Batch

Desain batch melibatkan memilih ukuran yang bersifat d btaches yang akan digunakan.
Tiga pedoman desain utama yang perlu diikuti:

1. Batch harus cukup kecil untuk memudahkan menemukan kesalahan jika kontrol
total tidak seimbang.
2. Batch harus cukup besar untuk consitute unit berukuran cukup kerja.
3. Batch harus merupakan unit lokalmisalnya, sekelompok dokumen semua
mengandung jenis transaksi.
 VALIDASI DATA INPUT

Data yang disampaikan sebagai masukan untuk sistem aplikasi harus divalidasi segera
mungkin setelah itu telah diambil dan dengan jarak sedekat mungkin dengan sumbernya. Maka
kesalahan dapat diperbaiki oleh orang yang cenderung memiliki sebagian pengetahuan tentang
mereka dan sementara keadaan sekitar data yang masih segar dalam pikiran mereka. Kadang-
kadang tujuan ini tidak dapat dicapai. Misalnya, data kesalahan mungkin telah diterima dari
organisasi remote melalui sebuah sistem pertukaran data elektronik. Beberapa waktu bisa berlalu
sebelum organisasi penerima menyelesaikan kesalahan dengan organisasi pengirim.

Setiap kesalahan diidentifikasi yang tidak segera diperbaiki harus ditulis untuk
kesalahan. Jika tidak, pengguna mungkin lupa untuk memperbaiki kesalahan. Input subsistem
harus menggunakan file error untuk mengingatkan pengguna ketika mereka belum diperbaiki
kesalahan secara tepat waktu. pesan pengingat dapat ditampilkan pada layar atau dicetak pada
laporan hard copy.

Figure 11-9

Jenis Input Cek Data Validasi

Untuk beberapa jenis input data pemeriksaan validasi dilakukan tergantung pada sifat
dari metode input data yang digunakan. Sebagai contoh, jika dokumen dipindai melalui
perangkat, orang yang bertugas sebagai kontrol kualitas harus bertanggung jawab untuk
memeriksa gambar dokumen untuk mereka bandingkan terhadap dokumen asli, dan menolak
gambar atau melakukan pekerjaan pembersihan jika kualitasnya tidak diterima.

Untuk menggambarkan sifat cek validasi input data, bagaimanapun, mempertimbangkan

empat jenis yang bisa dilakukan ketika input data mengetik di terminal: (1) cek lapangan, (2)
catatan pemeriksaan, (3) cek batch, (4) cek file. Setiap dibahas secara singkat dalam subbagian
berikut:

Cek Lapangan
 Dengan cek lapangan, tes validasi diterapkan tidak tergantung pada bidang lain dalam
catatan masukan lainnya. Sebagai contoh, kita dapat memeriksa wheter bidang yang seharusnya
berisi data numerik hanya tidak, pada kenyataannya, hanya berisi karakter numerik. Berikut jenis
pemeriksaan lapangan dapat diterapkan:

Jenis Bidang yang Diperiksa Penjelasan

Data yang hilang / kosong Apakah ada data yang hilang di lapangan? Misalnya, jika
kode harus berisi dua tanda hubung, meskipun mereka
mungkin berada dalam posisi vaiable, hanya satu
dideteksi?
Abjad / numerik Apakah lapangan berisi kosong ketika data selalu harus
hadir?
Jarak Apakah bidang yang harus berisi hanya abjad atau numerik
berisi karakter alfanumerik?
Set keanggotaan Apakah data untuk jatuh lapangan dalam rentang nilai yang
diijinkan nya?
Pemeriksaan digit Jika satu set diperbolehkan nilai. Misalnya, salah satu dari
enam kode diskon penjualan valid?
Referensi master Apakah cek digit berlaku untuk nilai di lapangan?
Ukuran Jika bidang panjang variabel yang digunakan dan satu set
ukuran diperbolehkan didefinisikan, apakah lapangan
pembatas menunjukkan lapangan menjadi salah satu
ukuran valid?
Format mask Data yang dimasukkan ke lapangan mungkin harus
menyesuaikan format tertentu. misalnya, tanggal mungkin
untuk dimasukkan sebagai tahun diikuti oleh bulan diikuti
oleh hari.

Ketika entri data tidak didasarkan pada dokumen sumber, biasanya terbaik untuk ada
operator entri data secara langsung (misalnya, melalui "bip") ketika error pada cek lapangan
muncul. Operator kemudian dapat mencoba untuk memperbaiki kesalahan sebelum pindah ke
kolom berikutnya. Jika data diketik dari sumber dokumen, bagaimanapun, mungkin lebih baik
untuk menunggu sampai operator lengkap dan upaya untuk membuang layar menjadi terhenti.
Tempat dimana terjadi error akan memberitahu mereka tentang dimana kesalahan tersebut. Jika
tidak, ritme keying mereka mungkin menjadi terlalu terganggu. Bidang dalam kesalahan dapat
ditunjukkan oleh, katakanlah, berkedip tenda con atau menggunakan warna yang berbeda untuk
menampilkan isinya. Ketika operator memindahkan kursor ke lapangan dalam kesalahan, pesan
kesalahan yang relevan dapat ditampilkan.

Rekam Cek

Dengan tergantung pada cek catatan, tes validasi diterapkan contoh lapangan,
keterkaitan logis bidang lain lapangan di rekor. Adalah tor wajar dapat memeriksa apakah
rentang nilai gaji dalam satu bidan diberi nilai bidang lain yang menunjukkan senioritas
seseorang. Jenis pemeriksaan record dapat diterapkan:

Jenis Pemeriksaan Catatan Penjelasan

Kewajaran Meskipun nilai field mungkin melewati pemeriksaan
kisaran, isi bidang lain mungkin menentukan apa adalah
nilai wajar lapangan. Misalnya, kisaran gaji berlaku untuk
karyawan mungkin bergantung pada posisi mereka dalam
hirarki organisasi.
Tanda numerik yang sah Isi satu bidang mungkin menentukan bidang yang
menunjukkan bidang numerik. Sebagai contoh, jika
pembayaran tunai jenis transaksi telah diterima dari
pelanggan, jumlah lapangan harus memiliki, mengatakan,
tanda positif.
Ukuran Jika catatan panjang variabel yang digunakan, ukuran
catatan adalah fungsi dari ukuran bidang variabel-panjang
atau ukuran bidang yang opsional mungkin dihilangkan
dari catatan. Ukuran diperbolehkan catatan tetap dan
variabel-panjang juga mungkin bergantung pada lapangan
yang menunjukkan jenis catatan.
Cek urutan Sebuah catatan logis mungkin terdiri lebih dari satu record
fisik. Misalnya, beberapa layar mungkin akan diminta
untuk memasukkan semua data tentang suatu peristiwa,
dan data dari setiap layar mungkin disimpan sebagai
catatan fisik. Program masukan mungkin memeriksa urutan
 catatan fisik yang diterimanya.

Ketika entri data tidak didasarkan pada dokumen sumber, seperti pemeriksaan lapangan
biasanya terbaik untuk memberitahu operator segera ketika kesalahan rekor cek muncul. Jika
data mengetik dari dokumen sumber, bagaimanapun, lagi seperti cek lapangan, mungkin lebih
baik untuk menunggu sampai operator lengkap dan upaya untuk di menimbulkan layar sebelum
memberitahu mereka tentang kesalahan catatan-cek.

Mengoreksi kesalahan yang diidentifikasi selama pemeriksaan catatan lebih sulit ketika
silang validasi layar terjadi. Jika nilai-nilai dalam satu bidang tergantung pada nilai-nilai di
bidang lain yang terletak pada layar yang berbeda, operator mungkin harus halaman bolak-balik
antara layar untuk mengidentifikasi penyebab kesalahan. Untuk alasan ini, lebih baik untuk
memiliki data yang logis berhubungan yang dikelompokkan bersama-sama pada satu layar.

Batch Cek

Dengan cek batch, tes validasi memeriksa apakah characteris- yang tics dari batch
catatan masuk adalah kongruen dengan karakteristik menyatakan bets. Sebagai contoh, auditor
dapat memeriksa apakah total dari semua Bidang follow di batch catatan sama dengan total
grand diberikan untuk batch. jenis melenguh pemeriksaan batch dapat diterapkan:

Jenis Pemeriksaan Batch Penjelasan

Kontrol total Apakah akumulasi lapangan di semua catatan dalam batch
atau jumlah record dalam batch berdamai dengan jumlah
yang ditentukan untuk batch?
Tipe transaksi Semua catatan masukan dalam batch mungkin harus
menyertakan nomor seri semua masukan mungkin harus
menjadi tipe tertentu.
Batch nomor seri Semua catatan masukan dalam batch mungkin harus
menyertakan nomor seri yang telah ditetapkan pada
pesanan.
Cek urutan Catatan masukan dalam batch mungkin harus mengikuti
urutan tertentu.
 Beberapa kesalahan batch tidak dapat diidentifikasi sampai semua catatan yang
berkaitan dengan batch yang telah dimasukkan. misalnya, total kontrol dihitung tidak adalah
nilai yang diharapkan. jenis lainnya dapat diidentifikasi segera setelah data masuk ke dalam
lapangan. misalnya, jenis transaksi yang salah untuk batch.

Cek Berkas

Dengan cek berkas, tes validasi memeriksa apakah karakteristik file yang digunakan
selama entri data adalah kongruen dengan karakteristik menyatakan file. Sebagai contoh, jika
auditor memvalidasi beberapa karakteristik dari data yang disesuaikan kedalam sistem aplikasi
terhadap file induk, mereka dapat memeriksa apakah mereka menggunakan versi terbaru dari file
induk. Berikut jenis pemeriksaan file dapat diterapkan:

Jenis Pemeriksaan File Penjelasan

Label Internal Program validasi input memeriksa untuk melihat bahwa itu
mengakses file yang memiliki nama yang benar.
Jumlah generasi Program validasi input memeriksa untuk melihat bahwa itu
mengakses generasi yang benar dari file yang
digunakannya.
Tanggal retensi Program validasi input memeriksa untuk melihat bahwa itu
tidak menggunakan sebuah file yang tanggal retensi
berakhir. total kontrol dapat dihitung untuk file berdasarkan
isi file.
Kontrol total Program validasi input memeriksa untuk bahwa itu
menggunakan file dengan total kontrol yang benar.

Kesalahan file-cek biasanya dapat diidentifikasi segera setelah file diakses. Misalnya,
label internal file dapat diperiksa segera setelah file tersebut diakses oleh program validasi input.

Pelaporan Kesalahan Data Input

Kesalahan harus dilaporkan oleh program validasi input dengan cara yang fasilitator tes
yang cepat dan akurat koreksi kesalahan yang diberi sinyal melalui buzzer atau kursor juga dapat
dibuat untuk flash untuk menunjukkan item data dalam kesalahan. Pesan kemudian harus
ditampilkan untuk menunjukkan sifat kesalahan dan kemungkinan tindakan korektif yang
mungkin dilakukan. Pesan kesalahan harus hati-hati dirancang untuk menjadi:

1. telinga dan ringkas. Pesan harus menggunakan singkat, bermakna, dan kata-kata
familiar menghindari pasif, menghindari kontraksi dan singkatan, dan instruksi
masalah dalam urutan yang harus diikuti.
2. Pesan sopan dan netral harus menghindari keakraban, sopan dan instruktif,
hindari humor atau penghukuman, dan membantu pengguna untuk memecahkan
masalah bahkan jika kesalahan berulang yang dibuat.

Program validasi input juga mungkin memberikan berbagai tingkat pesan kesalahan,
seperti pesan singkat-bentuk untuk pengguna berpengalaman dan penjelasan yang lebih rinci
untuk pemula atau pengguna jarang. Pengguna harus dapat menginstruksikan program untuk
menampilkan tingkat pesan kesalahan yang mereka butuhkan.
 INSTRUKSI INPUT

Memastikan kualitas input instruksi ke sistem aplikasi yang tujuan lebih sulit dicapai
daripada memastikan kualitas input data. input data cenderung mengikuti pola standar.
Kesalahan atau penyimpangan yang mungkin terjadi biasanya dapat diantisipasi. Selama
masukan instruksi, namun, pengguna sering mencoba untuk berkomunikasi tindakan kompleks
yang mereka ingin sistem untuk melakukan. Di satu sisi, subsistem input harus memberikan
fleksibilitas yang cukup sehingga pengguna dapat mencapai tujuan pengolahan mereka. Di sisi
lain, ia harus melakukan kontrol hati atas tindakan yang mereka lakukan. The aproaches
digunakan untuk berkomunikasi instruksi untuk sistem aplikasi cenderung trade off fleksibilitas
dengan kontrol.

Bahasa Berbasis Menu

Yang paling sederhana bagi pengguna untuk memberikan petunjuk ke ssystem aplikasi
adalah cara (gambar 11-10) menyajikan pengguna dengan daftar pilihan Pengguna kemudian
memilih opsi dalam beberapa cara. misalnya, dengan mengetikkan nomor atau huruf untuk
menunjukkan pilihan mereka, posisi kursor pada pilihan dan tekan. ing tombol kembali,
menekan atau melepaskan tombol pada mouse, menggunakan pena cahaya, atau menyentuh layar
dengan jari mereka.

Berbagai jenis menu dapat digunakan. Menu bar berisi item yang selalu muncul di layar.
Mereka memberikan bimbingan besar bagi pengguna ketika antar bertindak dengan layar. menu
pull-down berisi item yang jarang digunakan. Mereka menghilang, misalnya, ketika pengguna
merilis tombol mouse. menu pull-down sering mengarah ke cascading menu di mana menyoroti
salah satu item menu mengarah ke daftar item anak menu kemudian ditampilkan. Pop-up menu
yang digunakan untuk menyediakan pengguna dengan seperangkat terbatas tindakan spesifik
untuk tempat tertentu di mana mereka berada pada layar atau tindakan tertentu mereka
mengambil.

Semakin, menu sedang terdiri dari ikon daripada kata-misalnya, sebuah ikon dengan
"gunting" gambar untuk mengaktifkan "memotong" perintah daripada kata "memotong" dalam
daftar item menu. Pilihan ikon untuk digunakan dalam menu harus dibuat dengan hati-hati
sehingga maknanya dikomunikasikan dengan jelas kepada pengguna suatu sistem. Kadang-
kadang mereka dipilih karena mereka telah menjadi secara luas diakui sebagai berdiri untuk
tindakan tertentu yang harus diambil. misalnya, tombol menampilkan printer untuk menunjukkan
itu mengaktifkan perintah cetak. Kadang-kadang, bagaimanapun, mereka dirancang dalam
konteks metafora tertentu yang telah dipilih untuk memudahkan interaksi pengguna dengan
sistem misalnya, satu set kartu indeks dan tindakan pada mereka untuk mewakili penyimpanan
dan manipulasi data dalam database. Setiap kali metafora yang digunakan, namun, seperti ikon,
mereka harus hati-hati dirancang dan diuji secara menyeluruh untuk memastikan bahwa mereka
membantu bukan menghalangi interaksi pengguna dengan sistem (lihat, misalnya, Weinschenk
dan Yeo 1995).

Figure 11-10

Pedoman berikut harus mengurangi jumlah kesalahan yang mungkin terjadi

menggunakan input menu (lihat, selanjutnya, Shneiderman 1992):

1. Item menu harus dikelompokkan secara logis sehingga mereka bermakna dan
mudah diingat.
2. Menu dengan luas lebih besar dan kurang mendalam biasanya lebih cepat untuk
digunakan dan kurang rawan kesalahan dari menu dengan lebih mendalam dan
kurang luasnya.
3. item Menu harus mengikuti urutan alam yang ada. Jika tidak ada tatanan alam
ada, menu pendek sering terbaik diperintahkan oleh frekuensi kejadian dan
menu panjang dengan urutan abjad.
4. Menu item yang muncul di lebih dari satu menu harus mempertahankan tion
posisi- sama dalam menu yang berbeda.
5. item menu harus sepenuhnya dibilang harus, jelas, ringkas, kata kerja atau kata
benda atau mengudara kata kerja kata benda.
6. dasar untuk memilih item menu harus jelas. misalnya, nomor (dimulai dengan
satu, tidak nol), singkatan mnemonic, atau tombol radio.
7. Dimana output lainnya ditampilkan pada layar, menu harus jelas dibedakan
untuk. Atau, pull-down atau menu pop-up dapat digunakan untuk
menyembunyikan beberapa atau semua menu. Efektivitas dan efisiensi isu yang
penting ketika menu yang digunakan.
 Sedangkan menu memfasilitasi pemula 'penggunaan sistem aplikasi, mereka
menghambat ahli' penggunaan cepat dari sistem. Ada berbagai cara untuk membantu pengguna
ahli. Menu dapat digunakan bersama dengan perintah (dibahas kemudian). Pengguna kemudian
dapat memilih opsi menu atau menentukan nama perintah. Menu nama menu dapat digunakan
untuk memungkinkan pengguna untuk drop melalui hirarki menu ke menu tertentu. Fitur mundur
harus ada untuk memungkinkan pengguna untuk kembali ke tingkat menu yang lebih tinggi,
terutama ketika mereka ingin memulai kembali serangkaian pilihan.

Dialog Pertanyaan dan Jawaban

Dialog tanya jawab digunakan terutama untuk memperoleh input data. Sistem penera-
mengajukan pertanyaan tentang nilai dari beberapa item data, dan pengguna merespon. Namun
demikian, tanya jawab dialog juga dapat digunakan untuk memperoleh masukan struction di-
dalam hubungannya dengan input data. Sebagai contoh, Gambar 11-11 menunjukkan bahwa
pengguna ingin proyek yang akan dievaluasi dengan menggunakan teknik nilai sekarang bersih.
Masuknya "NPV" kemudian mengarahkan sistem untuk meminta jenis tertentu dari input data.

Jika jawaban yang akan diberikan dalam dialog tanya jawab yang tidak jelas, pengguna
bisa membuat kesalahan ketika mereka memberikan instruksi (atau data) masukan. Sebuah
dialog tanya jawab yang dirancang dengan baik membuat jelas set jawaban yang valid. Dalam
kasus-kasus di mana jawaban yang dibutuhkan tidak jelas, fasilitas bantuan dapat digunakan
untuk membantu pengguna berpengalaman.

Seperti menu, efektivitas dan efisiensi masalah adalah perhatian utama dengan dialog
tanya jawab. Mereka paling berguna ketika pengguna sedang dialami. Untuk pengguna
berpengalaman, namun, jawaban yang akan diberikan mungkin tidak selalu jelas. Selain itu, bagi
pengguna yang berpengalaman, urutan bolak tanya jawab mungkin membosankan. dialog
mungkin mengizinkan pengguna berpengalaman untuk jawaban stack. yaitu, memberikan
beberapa jawaban pada saat yang sama-atau untuk mengubah ke mode bahasa lain.

Bahasa Perintah

Bahasa perintah mengharuskan pengguna untuk menentukan perintah untuk memohon

beberapa proses dan seperangkat argumen yang menentukan dengan tepat bagaimana proses
harus dijalankan. Misalnya, SOL adalah bahasa interogasi database yang menggunakan format
perintah-bahasa. Untuk mencetak nomor pelanggan para pelanggan yang memiliki lebih dari
sepuluh transaksi lebih dari $200, mengikuti urutan perintah SQL mungkin ditentukan:

SELECT CUSTNO
FROM TRANS
WHERE AMOUNT ? 200
GROUP BY CUSTNO
HAVING COUNT (*) > 10;
Dalam contoh ini, "SELECT" adalah perintah, dan "CUSTNO" adalah sebuah argumen.

Dua keputusan penting harus dibuat dalam desain bahasa perintah: pertama, apakah
akan menggunakan sejumlah besar perintah dengan sejumlah kecil argumen atau sejumlah kecil
perintah dengan sejumlah besar argumen; dan kedua, apakah akan menggunakan kata kunci atau
posisi untuk menentukan argumen. Keputusan-keputusan ini mempengaruhi bagaimana mudah
bahasa adalah dengan menggunakan dan cenderung untuk membuat jumlah kesalahan pengguna.

Dalam kebanyakan situasi, tampaknya lebih baik menggunakan bahasa perintah dengan
sejumlah kecil perintah dan sejumlah besar argumen. Tak pelak, pengguna tampaknya
mempekerjakan hanya sebagian kecil dari perintah yang tersedia dalam perintah lan mungkin
karena mereka mengalami kesulitan mengingat semua perintah.

Dengan demikian, tampaknya lebih baik untuk membuat perintah ini kuat dengan
menyediakan daftar ekstensif argumen. apakah argumen harus ditentukan oleh kata kunci atau
posisi tampaknya tergantung pada keahlian pengguna dengan bahasa perintah. Dengan sedikit
pengalaman, mungkin sebagian besar pengguna lebih memilih untuk ketik berikut:

COPY MYFILE YOURFILE

daripada

COPY FROM = MYFILE TO = MYFILE

Namun demikian, sebagai daftar argumen menjadi lebih lama, mengingat posisi setiap argumen
dan apakah itu wajib atau opsional menjadi lebih sulit. Spesifikasi kunci argumen mungkin
kemudian lebih disukai.
 Untuk memudahkan mengingat perintah, nama perintah harus bermakna. Selain itu,
perintah yang menentukan tindakan yang berlawanan harus kongruen dengan satu sama lain
dalam arti penggunaan sehari-hari dari perintah. Misalnya ketika pengguna ingin menambah
karakter atau menghapusnya dari file, mereka cenderung lebih memilih perintah INSERT /
DELETE untuk perintah INSERT / TINGGAL (Carroll 1982).

Untuk mengurangi usaha mengetik, itu harus mungkin untuk memotong perintah.
Strategi ini lebih mudah untuk menerapkan ketika hanya sejumlah kecil perintah yang digunakan
karena truncations cenderung unik. Ada beberapa cara untuk memotong perintah. misalnya,
menggunakan huruf pertama dan terakhir dari perintah atau menghapus vokal dari perintah.
Apapun strategi pemotongan digunakan, itu harus diterapkan secara konsisten di semua perintah
(Benbasat dan Wand 1984).

Anjuran dan default mengurangi jumlah kesalahan yang dibuat menggunakan bahasa
perintah. Misalnya, jika pengguna tidak dapat mengingat argumen terkait dengan perintah,
mereka harus mampu mengetik "?" atau tekan tombol lain untuk mendapatkan prompt dari
bahasa pada setiap argumen yang dibutuhkan. Demikian pula, bahasa perintah mengurangi upaya
mengetik jika persediaan nilai kemungkinan dari sebuah argumen sebagai default. Sebagai
contoh, beberapa bahasa perintah spreadsheet menggunakan posisi sel saat ini sebagai nilai
default di banyak perintah. default hanya bisa ditimpa jika tidak nilai yang diperlukan.

Bentuk Berbasis Bahasa

Bentuk berbasis bahasa mengharuskan pengguna untuk menentukan perintah dan data
dalam con. teks baik beberapa masukan atau bentuk output. Sebagai contoh, Gambar 11-12
menunjukkan perintah yang dikeluarkan dalam Query. Contoh bahasa database interogasi untuk
mencetak nomor bagian dari setiap item yang terletak di gudang 1. Perhatikan bagaimana
perintah input disediakan dalam konteks bentuk masukan yang cermin yang tersambung dalam
database. Demikian pula, jika output beberapa jenis grafik, pengguna mungkin menggunakan
pena cahaya untuk memilih perintah yang menunjukkan mereka ingin timbangan dari sumbu
harus diubah.

Bahasa berbasis bentuk dapat berhasil jika pengguna memecahkan masalah dalam
konteks bentuk input dan output. Dalam kasus ini sintaks dari bahasa sesuai dengan cara
pengguna berpikir tentang masalah. Akibatnya, kesalahan input dikurangi, dan bahasa yang
cenderung digunakan secara efektif dan efisien. Ketika fungsi yang harus dilakukan tidak mudah
dipetakan ke dalam konteks bentuk input dan output, bagaimanapun, bahasa berbasis bentuk
cenderung canggung dan berat untuk digunakan.

Bahasa Alami

Antarmuka bahasa alami masih terutama subjek penelitian dan upaya pengembangan
substansial. Namun demikian, produk komersial sedikit yang sekarang tersedia. Auditor, oleh
karena itu, mungkin menghadapi mereka semakin di se lected domain aplikasi dan diminta untuk
mengevaluasi kemampuan mereka. Tujuan utama dari penelitian pada antarmuka bahasa alami
adalah untuk memungkinkan relatif bebas-bentuk interaksi bahasa alami terjadi antara pengguna
dan sistem aplikasi, mungkin melalui perangkat produksi pidato / pengakuan. Untuk beberapa
jenis aplikasi, tujuan ini mungkin patut dipuji. bahasa alami mungkin bukan yang terbaik dari
interface, namun, untuk semua jenis aplikasi. Secara khusus, banyak macam aplikasi yang
cenderung perhatian auditor mungkin tidak cocok untuk antarmuka bahasa alami.

Antarmuka bahasa alami saat ini memiliki beberapa keterbatasan:

1. Mereka tidak selalu mengatasi dengan baik dengan ambiguitas dan redundansi hadir dalam
bahasa alami. Misalnya, makna dari kalimat "waktu berlalu." berbeda tergantung pada
apakah "waktu" adalah kata benda dan "berlalu" adalah kata kerja atau sebaliknya.
2. Upaya substansial kadang-kadang harus dikeluarkan untuk membangun leksikon untuk
antarmuka bahasa alami. Pengguna harus mendefinisikan semua kemungkinan kata mereka
bisa menggunakan, dan pekerjaan ini harus diulang setiap kali domain aplikasi baru yang
akan diakses melalui bahasa alami.
3. penyimpangan Bahkan minor luar leksikon didirikan untuk domain aplikasi dapat
menyebabkan masalah. Pengguna mungkin tidak menyadari batas-batas yang tepat dari
domain dan dihambat dalam perintah mereka mengeluarkan dalam kasus mereka melintasi
batas-batas tersebut.
4. Jika database yang pengguna berinteraksi tunduk perubahan definisi sering, antarmuka
bahasa alami dapat dengan cepat menjadi bermasalah. leksikon harus mampu berkembang
dalam terang perubahan definisi. leksikon saat ini tidak selalu beradaptasi dengan baik
terhadap perubahan dalam definisi database.
5. Pengguna mungkin tidak menyadari ambiguitas yang bisa eksis dalam bahasa alami re
sponses bahwa sistem memberikan kepada perintah mereka mengeluarkan. Misalnya,
pertanyaan "Berapa banyak toko di Tasmania yang memiliki menawarkan penjualan papan
selancar?" mungkin membangkitkan respon dari "tidak ada." Jika tidak ada toko di Tasmania
menjual windsurfing, bagaimanapun, respon ini mungkin menyesatkan.
6. Hal ini masih belum jelas pada hingga dari bahasa alami mengarah ke interaksi yang tidak
efektif dan tidak efisien dengan sistem aplikasi. Jika pengguna ingin mengungkapkan
perintah, oleh karena itu, dengan cara formal, dibatasi, atau disingkat antarmuka bahasa
alami harus dapat menerima bentuk masukan.
7. Pengguna masih membutuhkan beberapa pelatihan ketika mereka menggunakan wajah
bahasa alami. Jika tidak, mereka mungkin bertanya pertanyaan yang antarmuka bahasa
alami dengan bahkan leksikon luas mungkin tidak dapat menafsirkan (Dekleva 1994).

Sampai ini masalah teknis telah diatasi, auditor harus di evaluasi mereka dari antarmuka
bahasa alami. Jika sangat penting bahwa presisi mutlak harus dicapai dalam perintah dan data
input yang diberikan ke sistem aplikasi dan dalam respon yang diperoleh dari sistem, jenis lain
dari antarmuka mungkin lebih baik.

Antarmuka Manipulasi Langsung

Beberapa user interface untuk sistem aplikasi menggunakan manipulasi langsung yang
memasukkan perintah dan data. Shneiderman (1992) mengidentifikasi tiga atribut dari antarmuka
manipulasi langsung: (1) visibilitas objek yang menarik, (2) cepat reversibel, tindakan tambahan,
dan (3) penggunaan perangkat manipulasi langsung (misalnya mouse) daripada bahasa perintah
sintaks untuk memanipulasi obyek yang menarik.

Beberapa contoh interface manipulasi langsung:

1. Spreadsheet elektronik. Pengguna melihat gambar visual dari spreadsheet dan nilai sel yang
terkait. Mereka dapat mengubah nilai sel dengan menggunakan mouse untuk memindahkan
kursor ke sel yang akan diubah dan kemudian memasukkan dalam nilai baru. Hasil
pengujian perubahan adalah jelas karena semua nilai sel tergantung menyesuaikan.
2. Tata Ruang manager data. Pengguna melihat grafik atau peta pada satu tingkat detail.
Mereka dapat "memperbesar" untuk menurunkan atau tingkat yang lebih tinggi detail
menggunakan joystick.
3. Desktop elektronik. Pengguna melihat gambar dari desktop dengan di dalam keranjang, di
luar keranjang, keranjang sampah, satu set file, Rolodex nama file-dan-alamat, dan
sebagainya. Mereka dapat memanipulasi objek-objek ini menggunakan mouse, joystick, atau
beberapa jenis alat penunjuk. Misalnya, file yang akan dihapus dapat dipindahkan ke
keranjang sampah.

Antarmuka manipulasi langsung menawarkan keuntungan besar: Pengguna sering

sangat termotivasi untuk menguasai sistem; mereka menikmati belajar dan menjelajahi aspek
yang lebih kuat dari sistem; mereka bekerja secara efektif dan efisien; dan mereka dengan cepat
mendapatkan kepercayaan menggunakan sistem. Mungkin kelemahan paling besar adalah
menemukan gambar yang sesuai atau ikon dari objek yang akan dimanipulasi, terutama di mana
sebuah sistem aplikasi memiliki sejumlah besar objek yang akan dimanipulasi. Untuk berbagai
jenis data akuntansi, misalnya, sulit untuk memikirkan sebuah ikon yang tepat untuk
menggunakan: Bagaimana seharusnya pembayaran dari piutang digambarkan sebagai gambar?
Namun demikian, setiap kali manipulasi langsung dapat digunakan, sering menyediakan lebih
antarmuka bebas dari kesalahan, efektif, dan efisien daripada antarmuka menu tradisional atau
perintah berorientasi.
 VALIDASI INSTRUKSI INPUT

Seperti input data, instruksi masukan mengadakan sistem aplikasi juga harus divalidasi.
Auditor mungkin memiliki sedikit kekhawatiran tentang validitas masukan instruksi ketika (1)
petunjuk yang disediakan sebagai bagian dari paket perangkat lunak aplikasi banyak digunakan
(misalnya, menu dalam rekening paket piutang) atau (2) petunjuk diinterpretasikan melalui
bahasa pemrograman tingkat tinggi (misalnya, SOL perintah dalam paket sistem manajemen
database). Dimana dalam masukan struction dirancang dan dilaksanakan secara khusus untuk
sistem aplikasi tertentu, bagaimanapun, auditor harus mengevaluasi cara petunjuk divalidasi
lebih hati-hati.

Jenis Instruksi Masukan Cek Validasi

Tiga jenis pemeriksaan validasi dapat dilakukan atas instruksi masukan: (1) cek leksikal,
(2) pemeriksaan sintaksis, dan (3) pemeriksaan semantik. Setiap dibahas secara singkat dalam
subbagian berikut.

Validasi Leksikal

Selama validasi leksikal, sistem mengevaluasi setiap "kata" yang dimasukkan oleh
pengguna. Tiga jenis kata dapat ditemui: (1) pengidentifikasi (label, vari ables), (2) terminal
(operator, kata dicadangkan), dan (3) literal (konstanta numerik, string). Karena kata-kata yang
terbentuk dari karakter, sistem harus menetapkan aturan dimana string karakter diakui sebagai
kata-kata diskrit. Biasanya pengakuan ini terjadi melalui karakter batas dan pembatas. Sebagai
contoh, sebuah ruang atau operator (*, /, +, -) mungkin membatasi kata.

Untuk menggambarkan analisis leksikal, menganggap perintah SQL berikut ini en tered
oleh pengguna:
SELECT name
FROM employee
WHERE salary > 15000

Analisa leksikal dalam sistem akan membaca perintah, karakter dengan arang acter, dan
berusaha untuk mengidentifikasi kata yang dimasukkan. Sebagai contoh, akan melihat bahwa
ruang berakhir karakter S, E, L, E, C, dan T dan string karakter "SELECT" adalah kata
dicadangkan dalam bahasa. Demikian pula, ruang ter- minates variabel "gaji," konstanta "15000"
dibatasi oleh simbol tanda kutip, dan variabel "gaji dan konstan '15000' dipisahkan oleh operator
Jika analisa leksikal tidak dapat mengenali kata yang valid, itu harus mencetak atau
menampilkan pesan kesalahan sehingga pengguna dapat melakukan tindakan perbaikan.

Sintaksis Validasi

Selama validasi sintaksis sistem membaca string dari kata-kata diidentifikasi dan
divalidasi oleh penganalisa leksikal dan upaya untuk menentukan urutan operasi yang string dari
kata-kata ini dimaksudkan untuk memanggil misalnya, di struction diterbitkan dalam bahasa
perintah interaktif mungkin berikut.:

INTERN = (OLDBAL + DEPOSITS WITHDRAWS) * INTEREST

Kurung menyiratkan urutan tertentu dari operasi yaitu:

Add DEPOSITS to OLDBAL

Subtract WITHDRAWS from the result
Multiply the results by INTEREST
Store the result in INTERN (interest earned)

Tanpa tanda kurung, tindakan pertama dipanggil mungkin untuk memperbanyak menarik diri
oleh BUNGA.

Sintaks analyzer memvalidasi sintaks dari instruksi dengan parsing string dari kata yang
dimasukkan untuk menentukan apakah itu sesuai dengan aturan tertentu dalam tata bahasa.
Dengan demikian, kualitas validasi sintaksis tergantung pada memiliki deskripsi formal dan
lengkap dari tata bahasa yang bahasa didasarkan dan membuat pilihan yang baik sehubungan
dengan skema parsing dipilih. Jika tidak, kesalahan dalam instruksi dimasukkan mungkin tidak
diidentifikasi atau pesan kesalahan ditampilkan atau dicetak mungkin tidak bermakna.

Validasi Semantic

Selama validasi semantik, sistem selesai analisisnya tentang makna instruksi

dimasukkan. Batas antara validasi sintaksis dan validasi semantik sering tidak jelas. Selama
validasi semantik, bagaimanapun, bahasa mungkin memeriksa, misalnya, apakah dua variabel
yang akan dikalikan bersama-sama adalah jenis numerik dan jenis tidak abjad atau alfanumerik.
Demikian pula, sistem mungkin mencegah perbandingan dua nilai numerik yang akan menjadi
tidak berarti. misalnya, gaji karyawan dengan berat badan mereka.

Kualitas analisis semantik tergantung pada seberapa baik kendala yang berhubungan
dengan data yang petunjuk mengoperasikan dapat dinyatakan. sistem manajemen database yang
menyediakan fasilitas definisi data yang luas, misalnya, memungkinkan berkualitas tinggi
validasi semantik yang akan dilakukan. Sistem ini dapat memeriksa bahwa operasi yang akan
dilakukan pada item data atau hasil yang dihasilkan sesuai dengan kendala dinyatakan dalam
kaitannya dengan item data dalam definisi data.

Pelaporan Instruksi Kesalahan Input

Pedoman untuk kesalahan pelaporan dibahas sebelumnya untuk validasi data berlaku
juga untuk instruksi validasi. Pesan kesalahan harus berkomunikasi dengan pengguna sebagai
benar-benar dan bermakna mungkin sifat kesalahan yang dibuat selama input instruksi. Karena
petunjuk yang pengguna masukkan bisa beragam dan rumit, waktu substansial dapat hilang jika
pesan kesalahan tidak memungkinkan pengguna untuk menentukan kesalahan dengan cepat.
Beberapa tingkat pesan kesalahan mungkin disediakan untuk memenuhi berbagai tingkat
keahlian pengguna. Selain itu, jika sistem gagal untuk mengidentifikasi kesalahan, unbreaknown
kepada pengguna, hasil berarti dapat diproduksi.
 KONTROL AUDIT TRAIL

Jejak audit dalam subsistem masukan mempertahankan kronologi kejadian dari waktu
data dan instruksi ditangkap dan dimasukkan ke dalam sistem aplikasi sampai waktu mereka
dianggap valid dan diteruskan ke subsistem lainnya dalam sistem aplikasi (misalnya, subsistem
komunikasi atau pengolahan subsistem).

Akuntansi Audit Trail

1. Dalam kasus input data, akuntansi audit trail harus mencatat asal-usul, isi, dan waktu
transaksi menandatangani sistem aplikasi. Jenis data yang dikumpulkan adalah sebagai
berikut:
2. Identitas orang (organisasi) yang merupakan sumber data,
3. Identitas orang (organisasi) yang masuk data ke dalam sistem,
4. Waktu dan tanggal saat data ditangkap,
5. Identifikasi dari perangkat fisik yang digunakan untuk memasukkan data ke dalam sistem,
6. akun atau merekam diperbarui oleh transaksi,
7. Data berdiri diperbarui oleh rincian transaksi,
8. Jumlah batch fisik atau logis yang milik siapa transaksi tersebut.

Data ini harus dikumpulkan terlepas dari apakah data itu pertama kali ditangkap pada dokumen
sumber, masuk atau membaca langsung ke dalam sistem aplikasi, atau diterima dari organisasi
lain melalui beberapa jenis sistem informasi antarorganisasi (katakanlah, sebuah sistem data
interchange elektronik).

Ketika input data divalidasi, waktu dan tanggal cap harus dilampirkan sehingga waktu
validasi data, koreksi kesalahan, dan resubmission kesalahan selanjutnya dapat ditentukan.
Dalam beberapa kasus, referensi pengolahan mungkin melekat pada input data untuk
menunjukkan program yang dilakukan tes validasi. Dalam sistem terdistribusi, misalnya,
perangkat lunak input validasi dapat direplikasi dan dilaksanakan di beberapa situs. Mungkin
penting untuk mengetahui contoh dari perangkat lunak melakukan tes validasi, terutama jika
keraguan ada konsistensi antara ulangan.

Jika program validasi input mengidentifikasi kesalahan yang tidak dapat diperbaiki
segera, harus menghasilkan dan melampirkan nomor kesalahan unik untuk data dalam kesalahan.
nomor kesalahan ini harus dikaitkan dengan data sampai diperbaiki. Ini harus dicetak atau
ditampilkan pada laporan, dimasukkan pada dokumen sumber yang digunakan untuk
memperbaiki kesalahan, atau mengetik di terminal jika data tersebut selanjutnya diambil dari file
error dan diperbaiki secara interaktif. Dengan cara ini sejarah data yang salah dapat ditelusuri
sampai saat koreksi

Dalam kasus masukan instruksi, jejak audit mungkin merekam jenis data berikut:

1 Identitas pencetus instruksi,

2 Waktu dan tanggal ketika instruksi dimasukkan,
3 Identifier dari perangkat fisik yang digunakan untuk memasukkan instruksi,
4 Jenis instruksi masuk dan argumen, dan
5 hasil yang dihasilkan dalam terang instruksi.
Seperti data, instruksi dimasukkan dalam kesalahan dapat juga diberi nomor kesalahan
yang unik dengan program yang melakukan validasi. Tidak seperti data, instruksi namun keliru
sering tidak tercatat pada file error yang harus dibersihkan. Sebaliknya, pengguna cukup masuk
kembali instruksi ketika mereka telah menentukan sifat kesalahan yang telah mereka buat. Jika
mereka tidak masuk kembali di struction, instruksi tersebut "hilang." Catatan dari kesalahan
instruksi biasanya digunakan untuk tujuan lain. misalnya, analisis frekuensi yang berbagai jenis
kesalahan instruksi yang dibuat.

Operasi Audit Trail

Karena subsistem masukan sering melibatkan kegiatan padat karya, operasi audit trail
data merupakan sarana penting untuk meningkatkan efektivitas dan efisiensi subsistem.
Beberapa jenis data operasi audit trail yang mungkin dikumpulkan berikut:

1. Waktu untuk memasukkan dokumen sumber atau instruksi di terminal

2. Jumlah kesalahan membaca yang dilakukan oleh perangkat pemindaian optik,
3. Jumlah mengetik kesalahan diidentifikasi selama verifikasi,
4. Frekuensi dengan yang instruksi dalam bahasa perintah yang digunakan, dan
5. Waktu diambil untuk memohon instruksi menggunakan pena cahaya dibandingkan mouse

Dengan menganalisis data ini, kegiatan rawan kesalahan atau masukan tidak efisien dapat
diidentifikasi dan tindakan perbaikan yang dilakukan. Misalnya, waktu yang dibutuhkan untuk
memasukkan data melalui layar dapat menunjukkan bahwa pelatihan pengguna lebih dibutuhkan
atau yang mendesain ulang layar diperlukan. Demikian pula, perbandingan kali diambil untuk
memasukkan data atau instruksi menggunakan perangkat yang berbeda yang sama dapat
digunakan untuk mendorong pengguna untuk menggunakan perangkat yang lebih efisien.
 KEBERADAAN KONTROL

Keberadaan kontrol yang berhubungan dengan data dalam subsistem masukan sangat
penting. Dalam file induk sistem aplikasi dihancurkan atau rusak, pemulihan dapat melibatkan
akan kembali ke versi sebelumnya dari file induk dan pemrosesan kembali masukan terhadap
file-file ini. Pemulihan tidak dapat dilakukan kecuali input file yang tersedia. Oleh karena itu,
input file harus disimpan dengan aman, dan salinan cadangan harus dipertahankan pada lokasi
situs off.

Dalam situasi kasus terburuk di mana file masukan juga hancur atau rusak bersama
dengan file induk sistem aplikasi, pemulihan mungkin harus dilakukan dari dokumen sumber
jika mereka tersedia atau hard daftar transaksi copy jika mereka tersedia. Dengan demikian,
dokumen sumber atau daftar transaksi harus disimpan dengan aman sampai mereka tidak lagi
diperlukan untuk tujuan cadangan. Catatan, mereka mungkin harus disimpan dengan aman untuk
waktu yang lebih lama untuk alasan lain. misalnya, sesuai dengan persyaratan hukum.

Keberadaan kontrol untuk input instruksi biasanya kurang kritis dari yang dibutuhkan
untuk input data. Jika, katakanlah, sebuah instruksi membangkitkan update ke database, maka
akan dicatat pula sebagai bagian dari log transaksi input. Jika itu tidak mempengaruhi database.
misalnya, itu hanya interogasi dari nilai item data. memulihkan catatan input instruksi mungkin
kurang penting. Meskipun demikian, memulihkan instruksi tidak harus diberhentikan sebagai
tidak perlu. Kadang-kadang penting untuk mengidentifikasi siapa diinterogasi database ketika
masalah keamanan yang mungkin sedang diselidiki atau ketika database ditemukan dalam
keadaan yang keliru.