Você está na página 1de 11

Antarmuka pemakai (User Interface) merupakan mekanisme komunikasi antara

pengguna (user) dengan sistem. Antarmuka pemakai (User Interface) dapat menerima
informasi dari pengguna (user) dan memberikan informasi kepada pengguna (user) untuk
membantu mengarahkan alur penelusuran masalah sampai ditemukan suatu solusi.user
interface, berfungsi untuk menginputkan pengetahuan baru ke dalam basis pengetahuan
sistem pakar (ES), menampilkan penjelasan sistem dan memberikan panduan pemakaian
sistem secara menyeluruh step by step sehingga user mengerti apa yang akan dilakukan
terhadap suatu sistem. Yang terpenting dalam membangun user interface adalah kemudahan
dalam memakai/ menjalankan sistem, interaktif, komunikatif, sedangkan kesulitan dalam
mengembangkan/ membangun suatu program jangan terlalu diperlihatkan.

Saat ini telah banyak terdapat perangkat lunak yang dapat digunakan dalam proses
mempermudah user. Tujuan utama mata kuliah ini adalah bagaimana membuat/merancang
suatu antarmuka bagi aplikasi yang ‘user friendly’. Salah satu kriteria yang harus dimiliki
oleh aplikasi yang ‘user friendly’ adalah mempunyai antarmuka yang:

ü       Enak dilihat

ü       Mudah dioperasikan

ü       Mudah dipelajari

ü       User merasa senang menggunakan/menjalankan

Untuk membuat antarmuka yang memenuhi kriteria di atas, maka sistem harus dapat
menangani piranti-piranti yang terhubung dengan sistem, misalnya piranti masukan
(keyboard, mouse, dll), dan juga piranti keluaran, misalnya layar dan printer.

Saat ini alat bantu untuk membuat antarmuka sudah banyak tersedia. Banyaknya compiler-
compiler bahasa pemrograman visual seperti Visual dBase, Visual Basic, Visual Delphi,
Visual J/J++, Visual C/C++,  merupakan bahasa pemrograman yang dapat dipakai
mengembangkan aplikasi sekaligus membuat antarmuka berbasis grafis yang mudah
digunakan.

Penggunaan alat bantu mempunyai kelebihan antara lain :

1. Antarmuka yang dihasilkan lebih baik, karena:

ü       Bisa membuat prototipe

ü       Perubahan cepat dilakukan

ü       Sebuah aplikasi dapat mempunyai lebih dari antarmuka

ü       Tampilan antarmuka lebih konsisten

ü       Dapat merancang antarmuka sesuai keinginan

1
ü       Memungkinkan pekerjaan dibagi sesuai keahian yang dimiliki

1. Program untuk antarmuka mudah ditulis karena sebagian besar ditangani oleh
software yang bersangkutan.

ü       Prinsip modularitas

ü       Antarmuka bersifat ‘reuseable’ karena dapat memakai satu rancangan antarmuka untuk
beberapa dialog

ü       Spesifikasi dialog lebih mudah dinyatakan, divalidasi, dimodifikasi

1.4. Peran Interaksi Manusia Komputer dalam Daur Hidup Pengembangan Sistem

Peran pemakaian Interaksi manusia-komputer pada daur hidup pengembangan sistem dapat
dilihat pada gambar 1.2, 1.3 dan 1.4

Gambar 1.2. Daur hidup pengembangan sistem konvensional

Gambar 1.2. memperlihatkan daur hidup pengembangan Sistem tradisional sebagai suatu
proses yang berkelanjutan. Beberapa variasi tahapan proses desain secara berurutan,
meskipun iterasinya dapat diharapkan pada saat tahap implementasi dan debugging dan
mungkin juga termasuk pada pada saat analisis sistem, pengembangan dan produksi jika

2
memang ada masalah desain yang cukup serius. Dokumentasi pada semua tahapan perlu
dilakukan untuk meyakinkan peralihan yang terjadi pada setiap tahapan dan untuk
mendokumentasikan sistem secara keseluruhan.

Pada gambar 1.3. menunjukkan bagaimana suatu kesadaran akan aspek interaksi manusia-
komputer dapat dieksploitasi pada berbagai tahapan dalam pengembangan sistem.

Gambar 1.3. Daur hidup pengembangan sistem dengan menyertakan kesadaran akan adanya
interaksi manusia-komputer.

Kesadaran akan karakteristik dasar manusia (persepsi, kognitif, dan motor skill- akan dibahas
tersendiri) memungkinkan isu tambahan faktor manusia yang dilakukan pada tahap studi
kelayakan, analisis sistem dan tahap pengembangan. Pada tahap ini, perlu adanya panduan
pembuatan dialog (pada jenis-jenis dialog, karakteristik dan gaya dialog) dimana desain
antarmuka menjadi hal yang mendasar. Beberapa panduan disertai dengan evaluasi empiris
sistem secara praktis.

Evaluasi informal menyediakan panduan bagaimana metode yang dapat digunakan untuk
perkiraan yang valid tentang desain antarmuka, pengecakan validasi, dan menyediakan
informasi kondisi sistem sesegera mungkin pada setiap tahapan pengembangan sistem.

Gambar 1.4. Daur Hidup pengembangan sistem dengan menambahkan praktisi dan spesialis
IMK

Gambar 1.4. menunjukkan berbagai cara dari level pengetahuan seorang praktisi atau
spesialis diaplikasikan dalam daur hidup pengembangan sistem. Teknik ini biasanya paling
baik diterapkan pada suatu proyek multidisipliner yang mengikutsertakan berbagai orang
dengan disiplin yang berbeda-beda.

3
1.5. Strategi Pengembangan Antarmuka

Dari daur hidup pengembangan sistem di atas dapat dilihat bahwa ada dua bagian penting
suatu aplikasi, yaitu

a. Antarmuka, yang merupakan dialog yang menghubungkan komputer dengan


pengguna.
b. Aplikasi, yang merupakan pengolah data yang menghasilkan informasi.

Pada pengembangan suatu sistem informasi, pengembangan antarmuka tidak lebih sederhana
dari pengembangan aplikasinya sendiri.

Secara garis besar, pengembangan antarmuka perlu memperhatikan hal-hal sebagai berikut:

ü       Pengetahuan tentang mekanisme fungsi manusia sebagai pengguna komputer;


menyangkut faktor psikologi, kognitif, tingkat perseptual dan kemampuan motorik pengguna

ü       Informasi yang berhubungan dengan karakteristik dialog; seperti jenis dialog, struktur,
isi teks dan grafis, dan kecepatan.

ü       Penggunaan prototipe sebagai spesifikasi formal yang didiskusikan dengan calon
pengguna serta perlunya memakai alat bantu.

ü       Teknik evaluasi yang digunakan dengan ujicoba berbagai kasus dan data empiris, tanya
jawab, kuisenair. Untuk antarmuka bagi sistem besar perlu melibatkan ahli antarmuka dan
praktisi.

Pengujian GUI

Meluasnya penggunaan GUI untuk berinteraksi dengan perangkat lunak mengarah ke


pembangunan GUI yang lebih kompleks dan lebih. Dengan meningkatnya kompleksitas
datang tantangan dalam menguji kebenaran GUI dan software yang mendasarinya. Kami
menyajikan sebuah teknik baru untuk secara otomatis menghasilkan kasus uji untuk GUI
yang mengeksploitasi perencanaan, teknik baik dikembangkan dan digunakan dalam
kecerdasan buatan. Mengingat satu set operator, kondisi awal, dan sebuah negara tujuan,
perencana menghasilkan urutan operator yang akan mengubah keadaan awal ke negara
tujuan. uji kasus kami teknik generasi memungkinkan aplikasi yang efisien perencanaan
dengan terlebih dahulu menciptakan sebuah model hirarkis GUI berdasarkan strukturnya.
Kami menerapkan sistem uji kasus kami generasi, yang disebut Perencanaan Assisted Tester
untuk antarmuka pengguna grafis Systems (PATHS) dan eksperimen dievaluasi kepraktisan
dan keefektifannya. Kami menjelaskan implementasi prototipe PATHS dan melaporkan hasil
eksperimen yang terkontrol untuk menghasilkan uji kasus untuk Microsoft WordPad.

Introduction

Graphical User Interface (GUI) telah menjadi cara yang penting dan diterima berinteraksi
dengan perangkat lunak saat ini. Meskipun mereka membuat perangkat lunak mudah
digunakan dari sudut pandang pengguna, mereka mempersulit proses pengembangan

4
software [1], [2]. Secara khusus, pengujian GUI lebih kompleks dari pengujian perangkat
lunak konvensional, karena tidak hanya perangkat lunak yang mendasari harus diuji tetapi
GUI itu sendiri harus dilaksanakan dan diuji untuk memeriksa apakah itu menegaskan untuk
spesifikasi GUI. Bahkan ketika alat-alat yang digunakan untuk menghasilkan GUI secara
otomatis [3], [4], [5], alat-alat ini sendiri mungkin mengandung kesalahan yang dapat
memanifestasikan dirinya dalam GUI yang dihasilkan menyebabkan kegagalan perangkat
lunak. Oleh karena itu, pengujian GUI terus tetap menjadi aspek penting dari pengujian
perangkat lunak.

GUI Testing adalah daerah berkembang penting, menghadapi sejumlah tantangan berat.
Beberapa metode telah diajukan untuk testing GUI. Namun masih belum jelas bagaimana
mendefinisikan kasus GUI test dan berapa banyak tindakan harus terdiri dari batu ujian GUI.
Dalam tulisan ini kami mengusulkan suatu pendekatan yang mendefinisikan GUI kasus uji
sebagai urutan tindakan GUI primitif dan memperlakukan suite GUI tes sebagai hirarki dalam
bahasa formal. Ini bukan hanya teori utuh, tetapi juga praktis nyaman. Dimensi dari test suite
GUI dan urutan kasus uji GUI dapat didefinisikan secara unik. Sebuah prosedur yang nyaman
tersedia yang menghasilkan kasus-kasus tingkat tinggi uji dari uji kasus lebih rendah-order.
percobaan testing Tiga dengan browser internet dunia nyata mengungkapkan bahwa orde
kedua uji kasus dapat secara signifikan mengungguli uji kasus orde pertama dalam testing
GUI dan harus dihasilkan untuk menjalankan fungsi tertentu GUI. Selain itu, jumlah tindakan
yang diterapkan selama testing harus digunakan untuk mengganti jumlah testing yang
dilakukan selama testing untuk mengevaluasi efektivitas proses testing GUI. Makalah ini
menyediakan link potensial antara teori bahasa formal dan testing GUI.

Introduction

Graphical user interface (GUI) telah secara luas diadopsi dalam sistem perangkat lunak saat
ini. GUI dapat merupakan sebanyak 45-60% dari total kode software [1]. Maka dari itu
pentingnya GUI terlihat jelas [2]. sejumlah definisi kasus uji dapat ditemukan dalam literatur
yang ada pengujian perangkat lunak. Meyer mendefinisikan kasus uji sebagai input dengan
output yang diharapkan [11]. Binder [12] mendefinisikan test case terdiri dari keadaan pretest
perangkat lunak yang diuji (termasuk lingkungannya), urutan masukan uji, dan laporan hasil
tes diharapkan. Memon et al [13] mendefinisikan kasus uji terdiri dari sebuah keadaan awal
dan urutan tindakan hukum.

Untuk aplikasi GUI, karena beberapa jendela diperbolehkan dan mungkin ada “banyak cara”
dan “banyak cara keluar” penanganan jendela, uji kasus tidak dapat didefinisikan secara jelas.
Jika tindakan satu pengguna atau rangkaian tindakan pengguna didefinisikan sebagai single
test case? Jika suatu peristiwa yang tidak diminta atau tidak terkendali seperti tampilan
jendela dialog pencetakan diperlakukan sebagai bagian dari ujian atau sebagian output
melaksanakan test case? Haruskah tindakan atau peristiwa yang termasuk dalam ujian akan
disinkronisasi atau tidak? Bagaimana mungkin definisi kasus uji mempengaruhi efektivitas
pengujian GUI?

Pada bagian ini, kita pertama-tama akan memperkenalkan beberapa konsep yang terkait
dalam pengujian GUI, termasuk peristiwa, event handler dan uji kasus GUI. Kemudian,
konsep cakupan handler berbasis diusulkan, yang menggambarkan hubungan berbagi data
antara event handler.

5
Dalam Gambar 1, kami menyajikan contoh sederhana aplikasi GUI. Aplikasi ini menghitung
nilai sinus atau kosinus dari masukan angka oleh pengguna. Dengan setting “Radian”
checkbox atau menonaktifkan, jumlah input dapat diperlakukan sebagai radian atau gelar.
Kita bisa mendapatkan nilai sinus atau kosinus jumlah masukan pada kotak masukan dengan
Klik tombol “SIN” atau “COS” tombol. Klik tombol “Tentang” tombol akan menampilkan
tentang dialog. Event handler lima (bernama h1, h2, h3, h4, dan h5) akan ditampilkan dalam
bingkai di sekitar jendela.

Gambar 1. A GUI application and its event handlers

Dua GUI aplikasi yang digunakan dalam percobaan, bernama RichEdit dan TerpSpreadsheet
(versi 3.0).

RichEdit adalah program contoh termasuk dalam Borland C + + Builder © 6. Itu digunakan
dalam penelitian sebelumnya dilaporkan dalam [3]. kode Its mengandung sekitar 750 baris
kode C + + didasarkan pada VCL (Visual Component Library, kerangka kerja berorientasi
objek untuk pengembangan aplikasi GUI yang dikembangkan oleh Borland). Ini adalah
sebuah aplikasi yang mirip dengan Microsoft WordPad, yang fungsinya meliputi editing,
memformat, menyimpan dan mencetak dokumen.

TerpSpreadsheet adalah aplikasi GUI seperti Excel termasuk dalam suite 3.0 TerpOffice
dikembangkan oleh Dr Atif 2004 Memon Teman kelas Spring Rekayasa Perangkat Lunak di
Universitas Maryland [7]. Program ini digunakan sebagai aplikasi GUI yang diuji dalam [5].
Ini adalah sumber berbasis Java aplikasi spreadsheet yang terbuka dengan sekitar 15.000

6
baris kode. Fungsinya termasuk manajemen data, menyortir data, menyimpan data,
pencetakan data, memproses data, dan generasi grafik.

Proses percobaan pada RichEdit ditunjukkan pada Gambar 2. Pertama, kami menghasilkan
sebuah kolam uji (Langkah 1 dalam gambar). Kedua, kolam uji diperlakukan sebagai test
suite dan dikurangi dengan menggunakan kriteria cakupan yang berbeda (Langkah 2 dalam
gambar). Dalam tulisan ini, tiga kriteria cakupan yang dipelajari: cakupan handler berbasis
diusulkan (dinotasikan sebagai HC) dan dua kriteria cakupan berdasarkan aktivitas [13]:
liputan acara (E1) dan acara liputan interaksi (E2). Kemudian, kami membandingkan
efektivitas suite uji yang dihasilkan dalam hal kemampuan deteksi mereka kesalahan dan
cakupan pernyataan mereka (Langkah 3 dan Langkah 4 dalam Gambar 4).

Gambar 2. Proses eksperimen

Proses percobaan pada TerpSpreadsheet mirip dengan yang ditunjukkan pada Gambar 2,
kecuali bahwa kolam uji TerpSpreadsheet di-download dari [8], yang juga digunakan dalam
[6]. Kolam uji berisi 1.000 kasus uji. Kasus-kasus uji dihasilkan oleh traversal dalam grafik
event-aliran aplikasi [10].

Result

Dalam tulisan ini, kami juga menggunakan cakupan pernyataan sebagai ukuran efektivitas
suite uji. Sebuah test suite yang mencakup laporan lebih mungkin mampu membawa orang
keyakinan yang lebih tinggi pada keandalan dari aplikasi perangkat lunak [18]. Umumnya,
kita dapat mengatakan bahwa test suite yang baik harus dapat mencakup sebagai pernyataan
yang lebih mungkin.

Meskipun jumlah kesalahan yang terdeteksi per kasus uji / peristiwa TE1 lebih tinggi dari
TE2 dan THC, kriteria cakupan acara (E1) tidak cukup dalam pengujian. Kemampuan deteksi
kesalahan TE1 terlalu rendah. Sebagai contoh, pada percobaan TerpSpreadsheet, kurang dari
50% kesalahan dapat dideteksi oleh TE1.

7
Dengan mempertimbangkan baik ukuran dan kemampuan deteksi kesalahan, THC adalah
yang terbaik di kedua dari dua percobaan. Hal ini dapat mendeteksi lebih dari 90% dari cacat
menggunakan kasus uji jauh lebih sedikit dibandingkan dengan kolam pengujian awal. Jadi,
pengendali berbasis kriteria yang diusulkan coverage handler-base coverage (HC) adalah
pilihan yang baik dalam pengujian GUI.

Discussion and Recommendations

Event handler berbasis cakupan kriteria yang diusulkan dalam makalah ini memiliki
keuntungan sebagai berikut:
• Hal ini dapat digunakan tanpa melaksanakan uji kasus. Informasi cakupan dapat diperoleh
dengan menganalisis kode sumber dan uji kasus. Tidak instrumentasi kode sumber yang
terlibat.
• Jumlah persyaratan cakupan yang dibutuhkan oleh mereka lebih kecil dari kriteria cakupan
berdasarkan aktivitas. Umumnya, persyaratan cakupan lebih sedikit berarti test suite yang
lebih kecil. Pada saat yang sama, kesalahan deteksi kemampuan suite uji dikurangi dengan
cakupan kriteria yang diusulkan relatif tinggi.

Kelemahan dari cakupan yang diusulkan juga jelas, seperti


• Tidak memperhitungkan kode di perpustakaan. Beberapa interaksi data yang tercantum
dalam perpustakaan mungkin akan terjawab dalam pengujian.
• Kode analisis diperlukan, yang mungkin melibatkan biaya lebih tinggi dari nilai
berdasarkan aktivitas.

TUJUAN
tujuan utama

Interaksi manusia dan komputer pada dasarnya adalah untuk memudahkan manusia dalam
mengoperasikan komputer dan mendapatkan berbagai umpan balik yang ia perlukan selama
ia bekerja pada sebuah sistem komputer. Artinya sistem tersebut dapat berfungsi dengan baik 
bisa untuk mengembangkan dan meningkatkan keamanan (safety), utilitas (utility),
ketergunaan (usability), efektifitas (efectiveness) dan efisiensi (eficiency)

Dengan kata lain, bertujuan untuk membangun produk reliable;

 mudah dipelajari
 berkesan jika digunakan
 menghasilkan sistem yang bermanfaat (usable)
 aman (safe),dan
 memberi kepuasan serta pengalaman yang menyenangkan

Para perancang antarmuka manusia dan komputer berharap agar sistem komputer yang
dirancang dapat mempunyai sifat yang akrab dan ramah dengan users. Namun untuk
merancang sistem yang mudah digunakan users, para perancang harus memahami aspek-
aspek psikologi yang dimiliki oleh users, karena setiap users mempunyai ciri-ciri khusus dan
kebiasaan yang berbeda dalam menggunakan sebuah sistem komputer

8
Manusia, Komputer dan Interaksi

MANUSIA

Manusia memiliki keterbatasan dalam memproses informasi dan hal ini mempunyai implikasi
pada desain.

1.       Informasi diterima dan direspon melalui sejumlah saluran input dan output

 Saluran Visual (visual channel)


 Saluran Pendengaran (auditory channel)
 Saluran Peraba (haptic channel)
 Pergerakan (movement)

2.       Informasi disimpan pada memory

 Memory Sensor
 Memory Jangka Pendek
 Memory Jangka Panjang

3.       Informasi diproses dan diaplikasikan

 Penalaran
 Pemecahan masalah
 Skill acquisition
 Kesalahan

KOMPUTER

Sistem komputer terdiri dari berbagai macam elemen, yang masing-masing memiliki
pengaruh terhadap user. Peralatan input untuk penggunaan secara interaktif memungkinkan
user untuk memasukkan teks, menggambar, dan memilih obyek pada layar.

 Text entry : keyboard, speech, handwriting.


 Pointing : secara umum adalah mouse.

Peralatan output untuk penggunaan secara interaktif secara umum adalah beberapa jenis layar
serta output dengan suara.

Output dan input dalam bentuk kertas : paperless office dan less-paperless office.

Memory

 Memory jangka pendek : RAM


 Memory jangka panjang : magnetic dan optical disk
 Keterbatasan kapasitas penyimpanan dokumen dan video
 Metode akses yang membatasi dan membantu user

Proses

9
 Effek dari sistem yang berjalan cepat dan lambat
 Keterbatasan kecepatan pemrosesan
 Jaringan dan pengaruhnya terhadap kinerja sistem

INTERAKSI

Model interaksi membantu kita untuk memahami apa yang terjadi pada interaksi antar user
dan sistem. Model mengakomodasi apa yang diinginkan user dan yang dilakukan sistem.

Ergonomi mencakup karakter fisik interaksi dan bagaimana hal tersebut mempengaruhi
efektifitas.

Dialog antar user dan sistem dipengaruhi oleh gaya interaksi.

Interaksi terjadi pada konteks sosial dan organisasi mempengaruhi user dan sistem.

10
11

Você também pode gostar