Kamis, Maret 25, 2010

Analisis Sistem



Suatu sistem akan dirancang oleh satu orang atau sekelompok orang yang membentuk tim. Orang yang merancang sistem ini disebut SISTEM ANALIS.

Ada yang mendefinisikan sistem analis sebagai:
q Seorang yg menggunakan pengetahuan aplikasi komputer yg dimilikinya untuk memecahkan masalah-masalah bisnis, dibawah petunjuk manajer sistem
q Seorang yg bertanggung jawab menterjemahkan kebutuhan kebutuhan sipemakai sistem (user) kedalam spesifikasi teknik yg diperlukan oleh programmer dan diawasi oleh manajemen.

FUNGSI SISTEM ANALIS :
1. Mengidentifikasikan masalah - masalah dari pemakai / user
2. Menyatakan secara spesifik sasaran yg harus dicapai untuk memenuhi kebutuhan user
3. Memilih alternatif - alternatif metode pemecahan masalah
4. Merencanakan dan menerapkan rancangan sistemnya sesuai dgn permintaan user

TUGAS -TUGAS UMUM DARI SISTEM ANALIS :
1. Mengumpulkan & menganalisis formulir, dokumen , file yg berkaitan dgn sistem yg berjalan.
2. Menyusun dan menyajikan laporan perbaikan (rekomendasi ) dari sistem yg berjalan kepada user.
3. Merancang suatu sistem perbaikan dan mengidentifikasikan aplikasi -aplikasi untuk
penerapannya pada komputer.
4. Menganalisis & menyusun biaya-biaya & keuntungan dari sistem yg baru
5. Mengawasi semua kegiatan dalam penerapan sistem yg baru.


TUGAS -TUGAS TEKNIK DARI SISTEM ANALIS :
1. Menyiapkan gambaran kerja dalam menerapkan sistem baru.
2. Menyusun prosedur-prosedur untuk pengawasan.
3. Menyusun data flow diagram (DFD), Structured Analysis and Design Technique (SADT), dan sistem flowchart untuk merancang sistem baru secara detail.
4. Merancang pola pengawasan terhadap data yg bersifat sangat penting
5. Menyusun file-file utk digunakan dalam komputer, agar sistem baru dapat berjalan efektif.
6. Merancang bentuk input/output agar mudah dibaca oleh user
7. Menyusun dokumentasi tentang pekerjaan yg dilakukan oleh sistem analis dlm merancang sistem yg baru.

PRIBADI SISTEM ANALIS
1. Mampu bekerja sama
2. Mampu berkomunikasi dengan baik
3. Mempunyai sopan santun
4. Mempunyai pendirian yang tegas
5. Mampu bersikap dewasa
6. Mampu bersikap tegas
7. Dapat bertindak secara metodik
8. Dapat bersikap akurat dalam memperhitungkan biaya-biaya
9. Mempunyai sifat kreatif

LANGKAH KERJA SISTEM ANALIS
1. Tahap Mengidentifikasikan masalah kebutuhan user
2. Tahap Melaksanakan studi kelayakan
3. Tahap Analisis dan rancang sistem
4. Tahap Penerapan sistem
5. Tahap Evaluasi dan pemeliharaan

Definisi Analisa Sistem :

Analisis Sistem dapat didefinisikan sebagai :
Penguraian dari suatu sistem informasi yang utuh ke dalam bagian-bagian komponennya dengan maksud untuk
mengidentifikasikan dan mengevaluasi permasalahan-permasalahan, kesempatan-kesempatan, hambatan-hambatan
yang terjadi dan kebutuhan-kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan-perbaikan.
Atau secara lebih mudahnya, analisis sistem adalah penelitian atas sistem yang telah ada dengan tujuan untuk
merancang sistem yang baru atau diperbarui. Tahap analisis sistem ini merupakan tahap yang sangat kritis dan sangat penting, karena kesalahan di dalam tahap ini akan menyebabkan juga kesalahan di tahap selanjutnya.


Tugas utama analis sistem dalam tahap ini adalah menemukan kelemahan-kelemahan dari sistem yang berjalan
sehingga dapat diusulkan perbaikannya.


Langkah-langkah di Analisis Sistem :
Langkah-langkah di dalam tahap analisis sistem hampir sama dengan langkah-langkah yang dilakukan dalam
mendefinisikan proyek-proyek sistem yang akan dikembangkan di tahap perencanaan sistem. Perbedaannya pada
analisis sistem ruang lingkup tugasnya lebih terinci.
Didalam tahap analisis sistem terdapat langkah-langkah dasar yang harus dilakukan oleh Analis Sistem Yaitu sbb:

1. Identify, Yaitu mengidentifikasikan masalah
- Mengindentifikasikan penyebab masalah
Seringkali organisasi menyadari masalah yang tejadi setelah sesuatu berjalan dengan tidak benar. Permasalahan
tidak akan muncul dengan sendirinya dan mestinya ada sesuatu penyebab yang menimbulkannya.

- Mengidentifikasikan titik keputusan
Setelah penyebab terjadinya masalah dapat diidentifikasi, selanjutnya juga harus diidentifikasi titik keputusan
penyebab masalah tersebut. Maka selanjutnya perlu diidentifikasi lebih lanjut titik keputusan yang menyebabkan
suatu proses menjadi tidak sempurna. Titik keputusan menunjukkan suatu kondisi yang menyebabkan sesuatu
terjadi. Sebagai dasar identifikasi titik-titik keputusan ini, dapat digunakan dokumen sistem bagan alir formulir
(paperwork flowchart atau form flowchart) bila dokumentasi ini dimiliki oleh perusahaan.

- Mengidentifikasikan personil-personil kunci
Setelah titik-titik keputusan penyebab masalah dapat diidentifikasi beserta lokasi terjadinya, maka selanjutnya
yang perlu diidentifikasi adalah personil-personil kunci baik yang langsung maupun yang tidak langsung dapat
menyebabkan terjadinya masalah tersebut. Identifikasi personil-personil kunci ini dapat dilakukan dengan
mengacu pada bagan alir dokumen yang ada di perusahaan serta dokumen deskripsi jabatan (job description)

2. Understand, Yaitu memahami kerja dari sistem yang ada

Langkah ini dapat dilakukan dengan mempelajari secara terinci bagaimana sistem yang ada beroperasi. Untuk
mempelajari operasi dari sistem ini diperlukan data yang dapat diperoleh dengan cara melakukan penelitian. Bila
di tahap perencanaan sistem juga pernah dilakukan penelitian untuk memperoleh data, penelitian ini sifatnya
adalah penelitian pendahuluan (preliminary survey). Sedang pada tahap analisis sistem, penelitian yang
dilakukan adalah penelitian terinci (detailed survey).


Analis sistem perlu mempelajari apa dan bagaimana operasi dari sistem yang ada sebelum mencoba untuk
menganalisis permasalahan-permasalahan, kelemahan-kelemahan dan kebutuhan-kebutuhan pemakai sistem
untuk dapat memberikan rekomendasi pemecahannya. Sejumlah data perlu dikumpulkan menggunakan teknik
pengumpulan data yang ada, yaitu wawancara, questionares, observasi, procedure analis, document survey.


o Tanya jawab/wawancara (Interviews)


1. Bagaimana metode itu digunakan.

Pemilihan potential interviewees.
Membuat perjanjian terhadap potential interviewees.
Menyiapkan struktur pertanyaan yang lengkap dan jelas.
Memilih person yang diinterview secara pribadi dan merekamnya.

2. Target dari metode interview.

Kunci pribadi dalam proses DFD.
Kadangkala melibatkan orang luar, seperti pelanggan atau vendors.

3. Keuntungan metode interview.

Pewawancara dapat mengukur respon melalui pertanyaan dan menyesuaikannya sesuai
situasi yang terjadi.

Baik untuk permasalahan yang tidak terstruktur, seperti mengapa anda berpikir hal ini
dapat terjadi ?.


Menunjukkan kesan interviewer secara pribadi.
Memunculkan respons yang tinggi sejak penyusunan pertemuan.

4. Kerugian metode interview.

Membutuhkan waktu dan biaya yang tidak sedikit.
Membutuhkan pelatihan dan pengalaman khusus dari pewawancara.
Sulit membandingkan laporan wawancara karena subyektivitas alamiah.

5. Kapan metode tersebut baik digunakan.


Mendapatkan penjelasan atau pandangan dari personel kunci.
Test kredibilitas dari interviewees.
Mencari interview yang unsureness atau contradictions.
Memantapkan kredibilitas team.
Beberapa faktor penting dalam interview yang baik, yaitu objektives, audience, format, weighting dan
combining responses, and docummentation.
o Kuisioner (Questionnaires)


1. Bagaimana metode itu digunakan.

Mendisain dengan menggunakan standar kuesioner.
Kuesioner dikirimkan ke lingkungan kerja end-users.
Struktur respon diringkas dalam statistik distribusi.

2. Target dari metode questionnaires.

Semua end-user dengan wawasannya akan dilibatkan dalam proses solusi pemecahan
sistem.

End-user dihubungkan dengan proses pemakaian simbol-simbol dalam DFD.

3. Keuntungan metode questionnaires. Murah dan cepat dari pada interviews.


Tidak membutuhkan investigator yang terlatih (hanya satu ahli yang dibutuhkan untuk
mendesain kuesioner untuk end-user yang terpilih).
Mudah untuk mensintesis hasil sejak pembuatan kuesioner.
Dengan mudah dapat meminimalkan biaya untuk semua end-user.

4. Kerugian metode questionnaires.
Tidak dapat membuat pertanyaan yang spesifik bagi end-user.
Analis kurang melibatkan kesan sehingga tidak dapat menampakkan pribadi end-user.
Tanggapan yang rendah karena tidak adanya dorongan yang kuat untuk mengembalikan
questioner.
Tidak dapat menyesuaikan pertanyaan ke end-user secara spesifik.

5. Kapan metode tersebut baik digunakan.
Pertanyaannya sederhana, dan tidak memiliki arti mendua.
Membutuhkan wawasan yang luas dari end-user.
Bila memiliki sedikit waktu dan biaya.

o Observasi (Observation)

1. Bagaimana metode itu digunakan.
Secara pribadi seorang analis mengunjungi lokasi pengamatan.
Analis merekam kejadian dalam lokasi pengamatan, termasuk volumen dan pengolahan
lembar kerja.

2. Target dari metode.
Lokasi proses secara geografis ditunjukkan dalam DFD (Data Flow Diagram)

3. Keuntungan metode.
Mendapatkan fakta records daripada pendapat (opinion).
Tidak membutuhkan konstruksi pertanyaan.
Tidak menganggu atau menyembunyikan sesuatu (end-users tidak mengetahui bahwa
mereka sedang diamati).
Analis tidak bergantung pada penjelasan lisan dari end-users.

4. Kerugian metode.
Jika terlihat, analis mungkin mengubah operasi (end-user merasa diamati).
Dalam jangka panjang, fakta yang diperoleh dalam satu observasi mungkin tidak tepat
(representative) dalam kondisi harian atau mingguan.
Membutuhkan pengalaman dan kehlian khusus dari analis.

5. Kapan metode tersebut baik digunakan.
Membutuhkan gambaran kuantitatif seperti waktu, volume dan sebagainya.
Kecurigaan bahwa end-user mengatakan suatu kejadian yang sebenarnya tidak terjadi
(dibuat-buat).

Tip praktis dalam melakukan observasi :
a. Jangan mengamati dalam waktu yang lama.
b. Terdapat dua alasan, yaitu : dengan waktu yang lama akan mengacau operasi yang sedang
diamati, dan akan membiaskan permasalahan yang sebenarnya.
c. Buat catatan yang ringkas.
d. Sebelum observasi, beritahukan kepada supervisor dan pemakai yang terlibat tentang apa
yang akan dikerjakan dan mengapa dikerjakan, sehingga akan mengurangi gangguan.
e. Gunakan checklist yang singkat tentang informasi yang dibutuhkan bersama.
f. Jangan melakukan observasi tanpa rencana

o Prosedur analisis (Procedure Analysis)

1. Bagaimana metode itu digunakan.

Dengan prosedur operasi dapat mempelajari dan mengidentifikasikan aliran dokumen kunci
melalui sistem informasi, yaitu dengan data flow diagram (DFD).
Setiap aliran dokumen kunci menjelaskan prosedur operasi sistem.
Melalui observasi, analis mempelajari kenyataan daripada mendeskripsikan volume
distribusi (tinggi, rendah, sedang) dan apa yang selanjutnya dikerjakan terhadap salinan
dari dokumen aslinya.
2. Target dari metode.

Dokumen utama dalam DFD (Data Flow Diagram)
Proses dalam DFD.

3. Keuntungan metode.

Evaluasi prosedur dapat dikerjakan dengan campur tangan (interferences) yang minimal
dan tidak mempengaruhi operasi pemakai.
Prosedur aliran dapat menjadi sebuah struktur checklist untuk melakukan observasi.

4. Kerugian metode.
Prosedure mungkin tidak lengkap dan tidak -up to date lagi.
Mempelajari bagan aliran dokumen membutuhkan waktu dan keahlian analis.

5. Kapan metode tersebut baik digunakan.
Memutuskan apakah masalah kegagalan sistem dapat membantu perancangan yang baik.
Tim analis tidak secara total familiar dengan aliran dokumen.
Mendeskripsikan aliran dokumen yang menganggu kerjanya fungsi.

o Pengamatan dokumen (Document Survey)

1. Bagaimana metode itu digunakan.
Mengidentifikasikan dokumen utama dan laporan (physical data flow diagram).
Mengumpulkan salinan dokumen aktual dan laporan.
Setiap dokumen atau laporan, digunakan untuk record data, meliputi field (ukuran dan tipe),
frekuensi penggunaan dan struktur kodingnya (coding structure).

2. Target dari metode.
Aliran data kunci ditunjukkan dalam data flow diagram (DFD).

3. Keuntungan metode.
Meminimalkan interupsi dari fungsi operasionalnya.
Permulaan elemen kamus data.
Seringkali, dapat mempertimbangkan modifikasi major procedural.

4. Kerugian metode.
Membutuhkan waktu yang cukup (terdapat organisasi bisnis yang mengalami kebanjiran
dokumen dan laporan).

5. Kapan metode tersebut baik digunakan.

Harus dikerjakan jika sebuah sistem akan didesain (selama kegiatan analisis, dalam
memperjelas desain sistem yang baru dan analisis dokumen dapat membantu untuk
menentukan tugas perancangan selanjutnya).

Merencanakan jadual penelitian
Langkah kedua dari tahap analisis sistem dapat terdiri dari beberapa tugas yang perlu dilakukan, yaitu sebagai
berikut ini :

· Menentukan jenis penelitian
· Merencanakan jadwal penelitian
- Mengatur jadwal wawancara
- Mengatur jadwal observasi
- Mengatur jadwal pengambilan sampel
· Membuat penugasan penelitian
· Membuat agenda wawancara
· Mengumpulkan hasil penelitian

3. Analyze, Yaitu Menganalis Sistem

- Menganalisis kelemahan Sistem
o Menganalisis Distribusi Pekerjaan
o Menganalisis Pengukuran Pekerjaan
o Menganalisis Keandalan
o Menganalisis Dokumen
o Menganalisis Laporan
o Menganalisis Teknologi
- Menganalisis kebutuhan Informasi pemakai / manajemen

Walaupun menganalisis kelemahankelemahan dan permasalahan-permasalahan yang terjadi merupakan tugas
yang perlu, tetapi tugas ini saja belumlah cukup. Tugas lain dari analis sistem yang masih diperlukan
sehubungan dengan sasaran utama sistem informasi, yaitu menyediakan informasi yang dibutuhkan bagi para
pemakainya perlu dianalisis.

4. Report, Yaitu membuat laporan hasil analisis. Tujuan :
- Pelaporan bahwa analisis telah selesai dilakukan
- Meluruskan kesalah-pengertian mengenai apa yang telah ditemukan dan dianalisis oleh analis sistem tetapi
tidak sesuai menurut manajemen
- Meminta pendapat-pendapat dan saran-saran dari pihak manajemen
- Meminta persetujuan kepada pihak manajemen untuk melakukan tindakan Selanjutnya
Akurat berarti valid, yaitu data tersebut benar-benar mengukur dengan sebenarnya apa yang harus diukur. Misalnya,
data tentang jumlah kemiskinan harus dapat menggambarkan kemiskinan yang ada di daerah tersebut.
Data yang akurat tidak hanya diartikan dari sisi pengadaannya, melainkan juga dari sisi penyajiannya, yaitu bagaimana
data tersebut ditampilkan. Oleh karena itu, perlu ada format standar.

Sumber : http//blackantzz.bloggspot.com
Read rest of entry

Sabtu, Maret 20, 2010

Prototyping

PARADIGMA, PRINSIP, DAN PROSES DESAIN

Paradigma Interaksi
Kemajuan dalam bidang IMK diperoleh dari usaha eksplorasi dan kreatifitas rancangan yang dibuat. Pada bagian ini akan dibahas kelebihan-kelebihan dari sisi tehnik dan rancangan pada beberapa sistem interaksi yang dianggap sebagai kemajuan dalam bidang IMK.

Time-Sharing
Pada tahun 1940 dan 1950-an, terjadi perkembangan yang siginifikan dalam teknologi perangkat keras komputer. Hingga pada tahun 1960-an, perkembangan
teknologi hardware yang cepat ini kelihatan menjadi sia-sia jika tidak diimbangi dengan pemanfaatannya, dan mendorong para peneliti untuk mencari ide-ide baru yang akan diaplikasikan pada perkembangan teknologi perangkat keras komputer yang cepat tersebut.
Salah satu kontribusi yang besar pada masa itu adalah konsep time-sharing yang memungkinkan sebuah komputer mampu mendukung / dapat digunakan oleh
banyak (multiple) user. Sebelumnya, user / programmer dibatasi oleh pemrosesan batch, dengan memberikan data atau instruksi yang akan dijalankan dalam bentuk punched card atau paper tape kepada operator yang akan memasukkannya ke dalam komputer.
Pada konsep time-sharing, komputer diperuntukan bagi individual user dan peningkatan keluaran (throughput) sistem menjadikan user lebih reaktif dan kolaboratif. Dapat dikatakan bahwa time-sharing memungkinkan interaksi interaktif antara manusia dengan komputer.

Video Display Units (VDU)
Pada pertengahan tahun 1950-an, para peneliti bereksperimen untuk dapat menampilkan / mempresentasikan dan memanipulasi informasi pada komputer dalam
bentuk citra (image) pada video display unit (VDU). Tampilan pada layar merupakan media yang lebih baik daripada cetakan pada kertas untuk menyajikan informasi strategis dalam jumlah besar yang digunakan pada pemrosesan cepat.
Hingga pada tahun 1962, Ivan Sutherland menciptakan sebuah software “Sketchpad” yang dapat digunakan lebih dari sekedar pemrosesan data. Software ini
memungkinkan user melakukan abstraksi data dalam beberapa tingkat detail, memvisualisasikan dan memanipulasi representasi yang berbeda dari informasi yang sama. Sehingga dengan adanya “Sketchpad “ ini interaksi antara manusia dengan komputer menjadi lebih baik dengan informasi yang dihasilkan oleh komputer menjadi lebih mudah dipahami oleh manusia / user.

Programming Toolkits (Alat Bantu Pemrograman)
Sekitar awal tahun 1950-an, komputer dianggap sebagai suatu teknologi yang kompleks sehingga hanya orang dengan intelektualitas tertentu saja yang mampu
memanipulasinya. Douglas Engelbart, sesorang lulusan UCLA Berkeley, berpendapat bahwa dengan meningkatkan kemampuan manusia, berarti bertambah pula kapabilitas manusia untuk memecahkan masalah yang kompleks. Oleh karena itu, peralatan komputasi untuk membantu manusia dalam memecahkan masalah perlu dilengkapi dengan alat bantu (tools) yang tepat. Untuk itu, diadakan riset dengan sebuah tim untuk membangun alat bantu pemrograman (programming tools). Dari alat bantu pemrograman ini dapat dibuat alat bantu lain yang lebih besar cakupannya dan akhirnya programer dapat membangun sistem interaktif atau sistem lain yang lebih kompleks.

Komputer Pribadi (Personal Computing)
Programming toolkit telah menjadi alat bagi mereka yang memiliki kemampuan komputasi atau para pemrogram untuk meningkatkan produktivitasnya. Namun
Engelbart mempunyai visi bahwa komputer tidak hanya diperuntukkan bagi mereka yang mengerti komputer (computer literate) saja. Salah satu hasil awalnya adalah software LOGO yang dibuat oleh Seymour Papert. Software ini mengajarkan anak-anak bahasa pemrograman grafis yang mudah dengan menggunakan analogi cursor dalam bentuk ekor kura-kura dan frasa bahasa Inggris. Dengan mengadaptasi bahasa pemrograman grafis yang dapat dimengerti dan digunakan oleh anak-anak, menunjukkan bahwa nilai utama dari sebuah interaksi tidak terletak pada sistem yang tangguh / canggih namun pada mudahnya sistem tersebut digunakan.
Hasil software LOGO tersebut mempengaruhi pemikiran Alan Kay yang mempunyai visi bahwa komputasi di masa depan adalah penggunaan mesin berukuran kecil yang tangguh (powerful) yang dirancang untuk user tunggal, yang disebut personal computers. Bersama dengan sekelompok peneliti dari Xerox Palo Alto
Research Center (PARC), Kay memadukan lingkungan pemrograman visual yang sederhana namun tangguh, Smalltalk dengan perangkat lunak komputasi personal (personal computing), yang disebutnya sebagai Dynabook.

Sistem Window dan interface WIMP (Windows, Icons, Menus and Pointers)
Manusia mampu berpikir mengenai lebih dari satu hal pada satu waktu. Dan dalam mengerjakan tugasnya, manusia sering menginterupsi pekerjaannya dan
mengerjakan pekerjaan lain yang berkaitan. Jika personal computer dibuat dengan mengharuskan usernya mengerjakan pekerjaan dalam urutan yang tidak bisa dialihkan dari awal hingga selesai maka hal tersebut tidak pola kerja manusia yang telah disebutkan sebelumnya. Maka agar komputer dapat menjadi rekan kerja yang efektif, harus dibuat fleksibel untuk berganti topik seperti halnya manusia.
Karena user terlibat dalam berbagai tugas dalam satu waktu tertentu, menjadi sulit bagi komputer untuk menjaga status pekerjaan (threads) yang overlapping. Perlu dipisahkan berdasarkan konteks masing-masing threads dan dialognya sehingga user dapat membedakannya. Salah satu mekanisme presentasi untuk membagi dialog adalah dengan memisahkan secara fisik presentasi threads logik percakapan user-komputer yang berbeda pada layar yang disebut sebagai window. Dan kini pada sistem window ini, semakin banyak digunakan WIMP (Window, Icon, Menu, Pointer) interface.

Metapora (Metaphor)
Metapora telah cukup sukses digunakan untuk mengajarkan konsep baru dengan terminologi yang telah dipahami sebelumnya. Dan mekanisme pengajaran ini
digunakan untuk memperkenalkan peralatan komputer yang relatif memiliki tehnik interaksi yang berbeda dengan peralatan yang telah ada.
The Xerox Alto and Star adalah workstation pertama yang menggunakan metaphor dari office desktop. Sebagian besar tugas manajemen terkait dengan
manipulasi file. Dengan mengaitkan tugas-tugas manipulasi file tersebut dengan lingkungan kerja di kantor membuat pekerjaan dengan komputer tersebut menjadi mudah. Contoh lain dalam domain personal komputing adalah spreadsheeet yang merupakan metapora dari model akuntansi dan keuangan, kemudian ada keyboard yang merupakan metapora dari mesin ketik manual.
Namun tidak selalu semua pekerjaan yang dilakukan dengan komputer dapat diasosiasikan dengan keadaan dunia nyata. Dan hal ini dapat menjadi masalah.
Namun terlepas dari hal tersebut, kini sukses secara komersial telah diraih dari penggunaan metaphor ini, seperti yang kita lihat pada windows, menu, button, icon, dan pallete.

Manipulasi Langsung (Direct Manipulation)
Pada awal tahun 1980-an, dengan harga hardware grafik yang memiliki kemampuan dan kualitas yang tinggi menurun, para perancang mulai menyadari bahwa aplikasinya akan meningkat popularitasnya seiring dengan bertambahnya fungsi visualisasi. Pada interaksi command-line standar, satu-satunya cara untuk
mendapatkan hasil interaksi sebelumnya adalah dengan bertanya menggunakan perintah (command) dan harus tahu bagaimana memberikan perintah tersebut.
Dengan adanya umpan balik (feedback) atau respon cepat secara visual dan audio pada layar dengan resolusi tinggi dan sistem suara berkualitas akan
memudahkan pemberian informasi mengenai setiap aksi user yang dieksekusi. Dan tehnik ini dikenal sebagai direct manipulation (manipulasi langsung). Sukses komersial pertama yang mendemonstrasikan direct manipulation ini adalah personal computer macintosh dari Apple Computer Inc. Manipulasi langsung ini memungkinkan user untuk mengubah keadaan internal sistem dengan cepat.
Contoh lain dari direct manipulation adalah konsep WYSIWYG (what you see is what you get). Apa yang user lihat pada layar display pada saat menggunakan word processing misalnya, adalah bukan dokumen sebenarnya yang nantinya dihasilkan pada tahap akhir. Namun merupakan representasi atau rendering dari bagaimana rupa dokumen final nantinya. Implikasi dari WYSIWYG ini adalah perbedaan antara representasi dan hasil akhir adalah minimal, dan user dapat dengan mudah memvisualisasikan hasil akhir dari representasi yang diberikan komputer.

Bahasa vs. Aksi (Language versus Action)
Gambaran bentuk komunikasi dari direct manipulation adalah interface menggantikan sistem yang berada didalamnya sehingga user tidak perlu memahami
artinya pada level yang lebih rendah yaitu level sistem. Bentuk lain adalah interface sebagai mediator antara user dan sistem. User memberikan instruksi kepada interface dan menjadi tanggung jawab interface untuk menjamin terlaksananya instruksi tersebut. Komunikasi seperti ini menggunakan mekanisme indirect language.
Terdapat dua interpretasi dari bentuk komunikasi ini, pertama, user diharuskan mengerti keadaan fungsi sistem dan interface sebagai mediator tidak perlu terlalu banyak melakukan penerjemahan, dalam hal ini berarti kembali lagi seperti keadaan sebelum adanya direct manipulation; kedua, user tidak perlu memahami keadaan fungsi sistem dan interface menjalankan peran yang aktif untuk menerjemahkan operasi yang diinginkan oleh user menjadi operasi sistem. Contoh model yang kedua adalah pada sistem pencarian informasi (information retrieval system). Kita tidak perlu tahu bagaimana informasi diorganisasikan, pencarian dilakukan dengan pertanyaan yang ada pada konsep user.
Paradigma bahasa (language) memiliki kelebihan dan kekurangan dibandingkan dengan paradigme aksi (action). Pada paradigma aksi, lebih mudah melakukan tugas yang sederhana tanpa adanya resiko melakukan kesalahan, sebagai contoh dengan mengenali dan menunjuk obyek secara langsung mengurangi kesulitan
identifikasi dan kemungkinan misidentifikasi. Namun pada pekerjaan yang kompleks, paradigma aksi lebih rumit untuk melakukannya karena membutuhkan pengulangan prosedur yang sama dengan hanya sedikit modifikasi. Pada paradigma bahasa, dimungkinkan untuk mendeskripsikan prosedur generik misalnya mekanisme looping, sekali saja dan dapat dijalankan tanpa intervensi lebih jauh dari user.

Hypertext
Pada tahun 1945, Vannevar Bush mengkoordinasi 6000 ilmuwan merasa kesulitan besar dari penelitian yang dilakukan saat itu adalah sulit untuk mendapatkan literatur yang terus bertambah. Saat itu, paper diorganisasikan dalam bentuk linear, dan kadangkala ada bagian dari paper tersebut yang menyebabkab pembaca perlu menggali lebih dalam lagi. Penyimpanan informasi dalam format linear ini tidak banyak mendukung pengaksesan informasi secara random dan browsing asosiatif.
Kemudian dia membangun sebuah inovasi dalam penyimpanan informasi dan mekanisme pengambilannya yang disebut sebagai memex yang bertujuan untuk meningkatkan kemampuan menyimpan dan mengambil informasi dengan link asosiasi random. Memex ini intinya adalah sebuah desk yang mampu memproduksi dan
menyimpan salinan fotografik dari dokumen informasi dalam jumlah besar dan dapat menyimpan trak dari link dari dokumen yang berbeda.
Hingga akhrnya, pada pertengahan tahun 1960-an, Ted Nelson memberikan istilah Hypertext bagi metode penyimpanan informasi dalam format non-linear yang
memungkinkan akses atau browsing secara non-linear atau random ini.

Multi-Modality
Sistem interaktif multi-modality adalah sistem yang tergantung pada penggunaan beberapa (multiple) saluran (channel) komunikasi pada manusia. Dengan definisi ini, semua sistem interaktif dapat dianggap sebagai sistem muti-modality, karena manusia selalu menggunakan saluran / indera visual dan haptic pada saat memanipulasi komputer. Bahkan kita sering menggunakan saluran audio untuk mendengarkan apakah komputer benar beroperasi dengan semestinya.
Sistem multi-modality modern sangat besar melibatkan penggunaan banyak (multiple) saluran komunikasi secara simultan baik untuk input maupun output.
Normalnya, manusia memproses informasi menggunakan beberapa saluran komunikasi secara simultan. Para perancang sistem ini mencoba meniru fleksibilitas
observasi dan artikulasi yang dimiliki oleh manusia dengan meningkatkan kemampuan ekspresi input dan output pada sistem interaktif.
Multi-modal, multi-media, dan virtual reality adalah contoh dari penelitian dalam bidang sistem interaktif yang dikategorikan dalam bidang sistem multi sensor (multi-sensory system).

Computer-Supported Cooperative Work (CSCW)
Perkembangan komputasi lain pada tahun 1960-an adalah jaringan komputer yang memungkinkan komunikasi antara beberapa mesin (personal computer) yang terpisah dalam satu kesatuan grup. Dengan adanya jaringan komputer ini, komputer personal tetap mampu bekerja secara individu dan dapat berhubungan dengan
komputer lain di lingkungan kerjanya bahkan dengan seluruh dunia. Keadaan ini memunculkan perlunya kolaborasi antar individu melalui komputer yang dikenal
sebagai Computer-Supported Cooperative Work (CSCW).
Perbedaan utama antara sistem CSCW dengan sistem interaksi individual adalah tidak dapat diabaikannya aspek sosial kelompok dari user yang tergabung.
Sistem CSCW dibangun untuk memungkinkan interaksi antara user melalui komputer sehingga kebutuhan sekian banyak user tersebut harus terpenuhi dalam satu produk.
Salah satu contoh sistem CSCW ini adalah electronic mail (email). Email merupakan sistem CSCW yang bersifat asynchronous yang tidak mengharuskan user bekerja pada waktu yang bersamaan. Penerima mail tidak harus membuka suratnya pada waktu yang sama dengan terkirimnya surat. Sebaliknya sistem CSCW synchronous membutuhkan partisipasi simultan dari para usernya. Materi CSCW ini akan dibahas pada bab tersendiri.

Prinsip Yang Mendukung Pendayagunaan
Pada bagian ini dibahas prinsip umum yang dapat diaplikasikan pada rancangan sistem interaktif untuk meningkatkan daya gunanya. Prinsip ini terdiri dari
tiga kategori utama, yaitu :
• Learnability : kemudahan yang memungkin-kan user baru berinteraksi secara efektif dan dapat mencapai performance yang maksimal
• Flexibility : menyediakan banyak cara bagi user dan sistem untuk bertukar informasi
• Robustness: tingkat dukungan yang diberi-kan agar user dapat menentukan keberhasil-annya atau tujuan (goal) yang diinginkan.

Learnability
Learnability menyangkut fitur sistem interaktif memungkinkan user baru memahami bagaimana menggunakannya pada saat awal dan mempertahankan kinerja
pada level yang maksimal. Berikut ini adalah prinsip-prinsip yang mendukung learnability.

Tabel 3.1 Prinsip yang Mempengaruhi Kemampuan Belajar (Learnability)

Prinsip Definisi Prinsip yang Terkait
Predictability Mendukung user untuk menentukan efek dari aksi selanjutnya / ‘future action’ berdasarkan catatan / sejarah interaksi sebelumnya Operation visibility
Synthesizability Mendukung user untuk memperkirakan efek dari operasi sebelumnya pada keadaan saat ini Immediate/ Eventual Honesty
Familiarity Pengetahuan dan pengalaman user dalam domain berbasis komputer atau dunia nyata lainnya dapat diterapkan ketika berinteraksi dengan sistem yang baru Guessability Affordance
Generalizability Mendukung user untuk menambah pengetahuan dari interaksi spesifik di dalam dan di luar aplikasi aplikasi ke situasi lainnya yang mirip nbsp;
Consistency Kemiripan dalam perilaku input/output yang muncul dari situasi atau tugas obyektif yang sama nbsp;

Flexibility
Flexibility berkaitan dengan banyaknya cara yang dapat ditempuh oleh end-user untuk bertukar informasi atau berkomuniaksi dengan sistem. Terdapat beberapa aspek yang berkontribusi pada sifat fleksibilitas interaksi seperti yang diganbarkan pada tabel berikut ini.

Tabel 3.2 Prinsip yang Mempengaruhi Fleksibilitas

Prinsip Definisi Prinsip yang Terkait
Dialogue/Initiative Memungkinkan user terbebas dari kendala-kendala buatan (artificial) pada dialog input yang dipaksakan oleh sistem System/User preemtiveness
Multi-Treading Kemampuan system untuk mendukung interaksi user yang berhubungan dengan lebih dari satu task pada suatu saat/waktu Concurrent vs. interleaving, multi-modality
Task Migratability Kemampuan untuk melewatkan/memberikan kontrol dari eksekusi task yang diberikan sehingga menjadi task internal user atau sistem atau berbagi antara keduanya nbsp;
Substitutivity Memungkinkan nilai-nilai (values) ekuivalen antara input dan output yang masing- masing secara bebas dapat disubstitusi Representasi perkalian, kesamaan kesempatan (opportunity)
Customizability Kemampuan user interface untuk dimodifikasi oleh user atau system Adaptivity, Adaptability

Robustness
User menggunakan komputer untuk mencapai sekumpulan tujuan yang terkait dengan pekerjaannya atau area tugas tertentu. Fitur robustness dari sebuah interaksi meliputi hal-hal yang mendukung keberhasilan pencapaian dan penilaian pencapaian tujuan tersebut, seperti yang tercantum pada tabel di bawah ini.

Tabel 3.3 Prinsip yang Mempengaruhi Robustness

Prinsip Definisi Prinsip yang Terkait
Observability Kemampuan user untuk mengevaluasi keadaan internal system dari representasi yang dapat dimengerti /
dirasakan
Browsability, static/dynamic defaults, reachability, persistence, operation visibility
Recoverability Kemampuan user untuk melakukan koreksi bila sebuah error (kesalahan) telah dikenali Reachability, forward/backward recovery commensurate effort
Responsiveness Bagaimana user mengetahui / menyadari laju komunikasi dengan sistem Stability
Task Conformance Tingkatan dimana sistem pelayanan mendukung semua tasks yang user ingin lakukan dan dengan cara yang user ketahui Task completeness, task adequacy

PROSES DESAIN

Pendahuluan
Tujuan perancangan adalah memberikan tehnik yang dapat dihandalkan untuk perancangan secara berulang dari sistem interaktif yang sukses dan berdaya guna. Di ilmu komputer, terdapat sebuah sub disiplin besar yang membahas isu manajemen dan tehnik dari pengembangan software yang dikenal sebagai rekayasa perangkat lunak (software engineering). Salah satu hal dasar dalam rekayasa perangkat lunak adalah daur hidup perangkat lunak (software life cycle) yang mendeskripsikan aktifitas yang terjadi mulai dari pembentukan konsep awal hingga tahap penggantian sistem dan implementasi.
Isu interaksi manusia dan komputer yang menyangkut daya guna (usability) sistem interaktif relevan dengan seluruh aktifitas pada software life cycle. Sehingga software engineering untuk sistem interaktif bukan semata-mata menambahkan sebuah tahapan pada software life cycle namum lebih pada melibatkan tehnik yang berada sepanjang software life cycle.

Sofware Life Cycle
Software life cycle adalah sebuah usaha untuk mengidentifikasi aktifitas yang terjasi selama pengembangan sebuah perangkat lunak. Aktifitas ini kemudian diurutkan sesuai dengan waktu pelaksanaannya pada proyek pengembangan manapun dan diaplikasikan tehnik yang tepat pada setiap aktifitasnya.
Pada pengembangan produk perangkat lunak, kita memperhatikan dua buah pihak, yaitu pelanggan (customer) yang akan menggunakan produk dan desainer yang menghasilkan produk. Umumnya pelanggan dan desainer adalah sekelompok orang, dan pada beberapa hal customer dapat menjadi desainer sekaligus. Kadang penting untuk membedakan customer yang memberikan kerja atau menjadi klien bagi desainer dengan customer yang merupakan user yang benar-benar akan menjalankan sistem. Kedua peran tersebut dapat dipegang oleh orang atau kelompok orang yang berbeda.

Aktifitas Pada Life Cycle
Aktifitas life cycle direpresentasikan dalam grafik pada gambar 3.1 berikut ini. Bagan ini dikenal sebagai model waterfall karena mengikuti bentuk air terjun dengan satu aktifitas menuju ke aktifitas berikutnya.

Requirement Specification
Pada tahap requirement specification, desainer dan customer mencoba menangkap deskripsi seperti apa nantinya sistem yang sebenarnya akan dibangun. Aktifitas ini melibatkan pencarian informasi dari customer mengenai lingkungan kerja tempat sistem ini nantinya akan diimplementasikan.

Gb31

Gambar 3.1 Aktifitas Pada Siklus Hidup Software Model Waterfall

Architectural Design
Aktifitas ini memfokuskan pada bagaimana sistem menyediakan layanan seperti yang diharapkan. Aktifitas pertama adalah high-level decomposition yang membagi sistem menjadi komponen-komponen sesuai dengan fungsinya. Pembagian ini dapat didasarkan pada pembagian yang sudah ada di sistem yang lama atau membuat dari baru. Architectural design tidak hanya meliputi pembagian fungsi sistem yang nantinya akan menyediakan layanan, namun juga mendeskripsikan keterhubungan dan pemakaian bersama sumber daya antara komponen tersebut.

Detailed Design
Architectural design menghasilkan dekomposisi deskripsi sistem yang memungkinkan pengembangan komponen secara terpisah untuk kemudian diintegrasikan kembali nantinya. Agar dapat diimplementasikan dengan bahasa pemrograman, desainer harus melengkapi deskripsi tersebut dengan deskripsi yang lebih detail. Oleh karena itu, tahap detailed design adalah perbaikan dari deskripsi komponen yang dihasilkan oleh architectural design. Perilaku yang ditunjukkan oleh deskripsi pada level di atasnya, harus terdapat pula di deskripsi detailnya.

Coding and Unit Testing
Hasil dari detailed design harus dalam bentuk yang dapat diimplementasikan ke executable programming language. Setelah coding, setiap komponen diuji untuk
memverifikasi apakah berjalan dengan benar sesuai dengan kriteria yang yang telah ditetapkan pada tahap-tahap awal.

Integration and Testing
Setelah komponen-komponen diimplementasikan dan diuji secara individual, maka komponen tersebut harus diintegrasikan seperti yang dideskripsikan pada architectural design. Pengujian lebih lanjut dilakukan untuk memastikan perilaku yang benar dan tidak ada konflik penggunaan sumber daya bersama. Pada tahap ini juga dimungkinkan untuk melakukan tes (acceptance test) dengan customer untuk memastikan sistem yang dibuat memenuhi kebutuhan mereka. Setelah acceptance test maka produk dapat di-release kepada customer.

Maintenance
Setelah produk di-release, semua pekerjaan yang dilakukan terhadap sistem dianggap sebagai pemeliharaan (maintenance) sampai produk memerlukan desain ulang
menjadi versi baru atau produk tidak terpakai lagi. Maintenance melibatkan koreksi terhadap kesalahan / errror yang ditemui pada sistem setelah di-release dan dilakukan perbaikan terhadap sistem. Sehingga tahap maintenance memberikan feedback pada semua aktifitas lain pada life cyle, seperti yang ditunjukkan pada gambar 3.2.

Gb32
Gambar 3.2 Feedback dari Maintenance ke Aktifitas Perancangan Lainnya

Validasi dan Verifikasi
Selama life cycle, rancangan harus dicek untuk memastikan produk memenuhi kebutuhan customer (high-level requirement), lengkap, dan konsisten. Proses
pengecekan ini disebut sebagai validasi dan verifikasi. Boehm memberikan definisi yang membedakan validasi sebagai desigining “the right thing”, dan verifikasi sebagai designing “the thing right”.
Verifikasi dari suatu desain umumnya akan terjadi pada satu aktifitas life cycle atau antara dua aktifitas yang berurutan sedangkan validasi dilakukan pada berbagai aktifitas yang membutuhkan kepuasan customer. Validasi lebih bersifat subyektif dibandingkan verifikasi. Hal ini utamanya disebabkan karena adanya perbedaan antara bentuk bahasa deskripsi kebutuhan (requirement) dengan bahasa perancangan. Pada bidang IMK, validasi ini sering disebut sebagai evaluasi yang dapat dilakukan secara terpisah oleh desainer atau bekerja sama dengan user.

Sistem Interaktif dan Software Life Cycle
Software life cycle tradisional muncul pada tahun 1960-an dan 1970-an untuk menyediakan struktur bagi pengembangan sistem software besar. Saat itu mayoritas dari sistem-sistem besar tersebut merupakan aplikasi pemrosesan data bisnis. Dan sistem-sistem tersebut tidak bersifat interaktif melainkan merupakan sistem dengan pemrosesan batch. Seiring dengan perkembangan komputer personal, kini sistem cenderung semakin interaktif.
Life cycle yang diterangkan sebelumnya mempresentasikan proses perancangan dalam urutan dari atas ke bawah. Dalam kenyataannya, meskipun sistem pemrosesan bacth, proses perancangannya dilakukan secara iteratif, yaitu pekerjaan yang dilakukan pada satu aktifitas mempengaruhi aktifitas sebelum dan setelahnya pada siklus pengembangan, seperti yang tergambar pada gambar 3.3.
Software life cycle tradisional cocok dengan pendekatan prinsipal terhadap proses perancangannya, yaitu jika kita mengetahui dari awal apa yang akan kita
bangun maka kita dapat menjalani perancangan dengan struktur yang terurut untuk mencapai tujuan yang ditetapkan. Namun dalam prakteknya tidak semua kebutuhan user dapat kita daftar pada tahap awal mulainya pembangunan sistem. Oleh karena itu seperti pada gambar 3.3, penemuan fakta pada suatu tahap dapat membawa tahap tersebut beriterasi ke tahap sebelumnya. Terlebih lagi pada sistem interaktif, tidak semua kebutuhan / persyaratan sistem (system requirement) dapat diperoleh pada tahap awal. Sehingga sistem harus dibangun dengan berinteraksi dengan user, diobservasi dan dievaluasi untuk meningkatkan daya guna (usability) sistem tersebut. Hasil evaluasi ini dapat menjadi masukan untuk proses iterasi perancangan ke tahap sebelumnya.

Gb33

Gambar 3.3 Representasi Iterasi Pada Software Life Cycle Model Waterfall

Aturan Perancangan
Salah satu masalah pada proses perancangan berpusat pada user adalah bagaimana membuat desainer memiliki kemampuan untuk menentukan konsekuensi terhadap usability dari keputusan perancangan yang mereka ambil. Maka dibutuhkan aturan perancangan (design rules) yang dapat diikuti untuk meningkatkan usability dari produk software yang dibangun. Kita dapat mengklasifikasikan aturan tersebut berdasarkan dua dimensi yaitu berdasarkan autoritas (authority) dan generalitasnya (generality). Berdasarkan autoritas mengindikasikan apakah aturan tersebut harus diikuti atau disarankan dalam suatu proses perancangan. Berdasarkan generalitas menunjukkan apakah aturan tersebut dapat diaplikasikan pada semua situasi perancangan atau hanya terbatas pada situasi perancangan tertentu. Terdapat dua jenis aturan yang terkait dengan keterangan diatas, yaitu standard dan guideline. Secara umum, standard memiliki autoritas yang tinggi namun terbatas pada pengimplementasiannya. Sedangkan guideline cenderung memiliki autoritas yang rendah namun lebih banyak (umum) pengimplementasiannya. Aturan desain sistem interaktif dapat didukung oleh disiplin ilmu psikologi, kognitif, ergonomi, sosiologi, ekonomi maupun teori komputasi.

Standar
Standar bagi sistem interaktif umumnya diatur oelh badan nasional atau internasional untuk menjamin penerimaan aturan tersebut oleh sekelompok besar komunitas. Standar sistem interaktif dapat dibuat untuk bidang hardware maupun software. Ada dua karakteristik yang membedakan standar untuk hardware dengan standar software, yaitu :
1. Teori yang mendasari, standar hardware didasarkan pada pemahaman terhadap psikologi, ergonomi, dan hasilnya relatif bersifat tetap, sudah diketahui, dan mudah beradaptasi dengan desain hardware yang ada. Sedangkan standar software didasarkan pada pemahaman terhadap psikologi atau ilmu kognitif, dan bentuknya kurang formal, masih berkembang, dan tidak mudah diinterpretasikan pada bahasa perancangan.
2. Perubahan, hardware lebih sulit dan mahal untuk berubah dibandingkan software yang fleksibel.

Guideline
Ketidaklengkapan teori yang mendasari perancangan mengakibatkan sulitnya menetapkan standar yang spesifik dan autoritatif. Sebagai akibatnya, mayoritas aturan perancangan bagi sistem interaktif bersifat pemberian saran (suggestive) dan lebih umum. Fokus kita dalam memeriksa guideline adalah dengan menentukan kemampuan diaplikasikannya guideline tersebut dalam berbagai tahap perancangan. Guideline yang bersifat lebih abstrak, akan semakin mendekati dengan prinsip yang dibahas pada bab sebelumnya, dan akan cocok pada tahap requirement spesification. Guideline yang bersifat lebih spesifik, lebih sesuai untuk detailed design. Guideline ini juga dapat diperluas hingga batas tertentu, dan menyediakan mekanisme untuk menerjemahkan spesifikasi detailed design menjadi implementasi aktual.

Rekayasa Daya Guna (Usability Engineering)
Pendekatan lain pada perancangan yang berpusat pada user adalah penetapan tujuan rekayasa daya guna (usability engineering) pada proses perancangan. Proses rekayasa melibatkan interpretasi terhadap arti secara bersama, tujuan yang disetujui bersama, dan pemahaman mengenai bagaimana mengukur pencapaian kepuasan. Penekanan usability engineering adalah mengetahui dengan pasti kriteria apa yang akan digunakan untuk menilai kegunaan produk. Pengujian usability suatu produk didasarkan pada pengukuran pengalaman user dengan produk tersebut.
Terkait dengan software life cycle, satu fitur penting usability engineering adalah spesifikasi daya guna (usability specification) yang merupakan komponen-komponen interaksi user dengan sistem yang memberikan kontribusi pada usability sebuah produk. Usability specification dijadikan bagian dari spesifikasi kebutuhan (requirement specification). Berikut ini adalah contoh usability specification dari perancangan panel kendali (control panel) Video Cassette Recorder (VCR).

Tabel 3.4 Contoh usability specification untuk fungsi undo pada VCR

Attribute : Backward recoverability
Measuring Concept : Undo an erroneous programming sequence
Measuring Method : Number of explicit user action to undo current program
Now Level : No current product allows such an undo
Worst Case : As many actions as it takes to program in mistake
Planned Level : A maximum of two explicit user action
Best Case : One explicit cancel action

Measuring concept adalah penjabaran dari atribut yang akan diukur, pada contoh di atas attribute backward recoverability merupakan aksi mengembalikan keadaan semula dari urutan pemrograman yang salah (undo an erroneous programming sequence). Measuring method menunjukkan bagaimana atribut akan diukur. Now level mengindikasikan keadaan saat ini dari sistem yang ada di pasaran. Nilai worst case adalah nilai terendah yang dapat diterima dari hasil pengukuran. Planned level adalah target perancangan sedangkan best case adalah kondisi yang dianggap sebagai hasil terbaik yang mungkin dihasilkan dari pengukuran teknologi yang ada pada saat itu.

Tabel 3.5 berikut ini menunjukkan daftar kriteria pengukuran yang dapat digunakan sebagai measuring method, sedangkan tabel 3.6 menunjukkan beberapa cara menentukan worst case serta best case. Pengukuran seperti yang dilakukan oleh usability engineering ini juga dikenal sebagai usability metric.

Tabel 3.5 Kriteria untuk Measuring Method Usability Engneering
1 Time to complete a task
2 Percent of task completed
3 Percent of task completed per unit time
4 Ratio of successes to failures
5 Time spent in errors
6 Percent of number of errors
7 Percent of number of competitors better than it
8 Number of commands used
9 Frequency of help and documentation use
10 Percent of favourable/unfavourable user comments
11 Number of repetition of failed commands
12 Number of runs of successes and of failures
13 Number of times interface misleads the user
14 Number of good and bad features recalled by users
15 Number of available commands not invoked
16 Number of regressive behaviours
17 Number of users preferring your system
18 Number of times users need to work around a problem
19 Number of times the user is disrupted from a work task
20 Number of times user loses control of the system
21 Number of times user expresses frustration or satisfaction

Tabel 3.6 Beberapa Cara untuk Menentukan Level Pengukuran (worst case serta best
case)
Set levels with respect to information on
1. An existing system or previous version
2. Competitive system
3. Carrying out the task without use of a computer system
4. An absolute scale
5. Your own prototype
6. User’s own earlier performance
7. Each component of a system separately
8. A successive split of the difference between best and worst values
observed in user test

Tabel 3.7 mendeskripsikan contoh usability metric ISO 9241 yang dikelompokkan berdasarkan kontribusinya terhadap tiga kategori usability, yaitu efektifitas (effectiveness), efisiensi (efficiency), dan kepuasan (satisfaction).

Tabel 3.7 Contoh Usability Metric dari ISO 9241

Usability Objective Effectiveness Measures Efficiency Measures Satisfaction Measures
Suitability for the task Percentage of goals achieved Time to complete a task Rating scale for satisfaction
Appropriate for trained user Number of power features used Relative efficiency compared with an expert user Rating scale for satisfaction with power features
Learnability Percentage of functions learned Time to learn criterion Rating scale for ease learning
Error tolerance Percentage of errors corrected successfully Time spent on correcting errors Rating scale for error handling

Desain Iteratif dan Prototyping
Seperti yang telah dikemukakan di depan bahwa spesifikasi kebutuhan sistem
interaksi tidak dapat dilengkapi di awal life cycle. Satu-satunya cara untuk memastikan tercakupnya fitur-fitur yang potensial adalah dengan membangunnya kemudian dites pada user. Kesalahan desain yang ditemukan pada saat testing kemudian dikoreksi.

Inilah inti dari desain iteratif.
Pada sisi tehnik, desain iteratif dideskripsikan dengan pengunaan prototype. Prototype merupakan alat yang mensimulasikan beberapa (tidak semua) fitur dari
sistem yang akan dibuat. Terdapat tiga pendekatan utama prototyping, yaitu :

• Throw-away : prototype dibuat dan ditest. Pengalaman yang diperoleh dari pembuatan prototype tersebut digunakan untuk membuat produk akhir (final),
kemudian prototype tersebut dibuang (tak dipakai)

Gb34

Gambar 3.4 Prototype Model Throw-away

• Incremental : produk finalnya dibuat sebagai komponen-komponen yang terpisah. Desain produk finalnya secara keseluruhan hanya ada satu, tetapi dibagi-bagi dalam komponen-komponen lebih kecil yang terpisah (independent).

Gb35

Gambar 3.5 Prototype Model Incremental

• Evolutionary : Pada metode ini, prototypenya tidak dibuang tetapi digunakan untuk iterasi desain berikutnya. Dalam hal ini, sistem atau produk yang sebenarnya dipandang sebagai evolusi dari versi awal yang sangat terbatas menuju produk final atau produk akhir.

Gb36

Gambar 3.6 Prototype Model Evolutionary

Disisi manajemen, terdapat beberapa masalah potensial yang terkait dengan prototyping, seperti :
• Waktu, membangun prototype membutuhkan waktu, sehingga seringkali prototype dipakai jika waktunya cepat. Hingga muncul istilah rapid prototyping.
• Rencana, sebagian manajer proyek tidak memiliki pengalaman untuk menyatukan proses prototyping dengan keseluruhan rencana perancangan.
• Fitur Non-fungsional, seringkali fitur sistem yang paling penting merupakan fitur non-fungsional seperti safety dan reliability, tidak disertakan dalam prototyping.
• Kontrak, proses desain kadang dibatasi oleh kontrak antara desainer dengan customer yang mempengaruhi aspek tehnik dan manajerial.

Tehnik-tehnik Prototyping
Terdapat beberapa tehnik yang dapat dipergunakan untuk membuat rapid prototype, seperti :
• Storyboard, adalah bentuk prototype yang paling sederhana berupa gambaran secara grafis dari tampilan sistem yang akan dibangun tanpa fungsi dari sistem.
• Simulasi Fungsi Terbatas, fungsi sistem disertakan pada prototype tidak sekedar gambar tampilannya saja.
• High-level Programming Support, HyperTalk adalah contoh dari special-purpose high-level programming language yang memudahkan desainer membuat fitur tertentu dari sebuah sistem interaktif.

Rasionalitas Desain (Design Rationale)
Dalam merancang sistem komputer manapun, diambil keputusan-keputusan yang terkait dengan perancangan untuk mengakomodasi kebutuhan user ke dalam sistem. Kadangkala sulit untuk mengungkapkan kembali alasan atau rasionalitas yang melandasi keputusan-keputusan tersebut.
Rasionalitas desain (design rationale) adalah informasi yang menjelaskan alasan mengapa suatu keputusan dalam suatu tahap perancangan / desain sistem komputer dibuat atau diambil, termasuk deskripsi struktural atau arsitektural dan deskripsi fungsi atau perilakunya.

Beberapa keuntungan rasionalitas desain :
• Dalam bentuk yang eksplisit, rasionalitas desain menyediakan mekanisme komunikasi di antara anggota tim desain sehingga pada tahapan desain dan atau pemeliharaan (maintenance), anggota tim memahami keputusan kritis / penting mana yang telah dibuat, alternatif apa saja yang telah diteliti, dan alasan apa yang menyebabkan suatu alternatif dipilih diantara alternatif lainnya.
• Akumulasi pengetahuan dalam bentuk rasionalitas desain untuk suatu set produk dapat digunakan kembali untuk mentransfer hal yang berhasil dalam suatu situasi ke situasi lainnya yang mirip.
• Usaha yang diperlukan untuk menghasilkan sebuah rasionalitas desain memaksa desainer untuk bersikap hati-hati dalam mengambil suatu keputusan desain.
Pada area IMK, rasionalitas desain secara khusus memiliki arti penting untuk beberapa alasan :
• Umumnya tidak ada satu alternatif desain yang terbaik. Desainer dihadapkan pada kondisi trade-off antara alternatif berbeda yang ada. Rasionalitas desain digunakan untuk mendaftar pilihan yang ada dan mengkomunikasikan pilihan tersebut.
• Meskipun terdapat solusi yang optimal, ruang lingkupnya terlalu besar untuk langsung dapat ditemukan. Sehingga perlu desainer perlu mengindikasikan semua alternatif yang telah diselidiki.
• Usability sistem interaktif sangat bergantung pada konteks penggunaannya. Memperhatikan konteks keputusan perancangan yang dibuat akan membantu proses perancangan sistem yang baru nantinya. Jika konteksnya sama dengan yang lama, maka rasionalitas desain dapat diadopsi tanpa revisi, sebaliknya jika konteksnya berubah, maka rasionalitas desain ditelaah kembali dan dihilangkan alternatif yang tidak sesuai.

Rasionalitas Desain Beorientasi Proses (Process-oriented Design Rationale)
Sebagian besar rasionalitas desain mengadaptasi bentuk issue-based information system (IBIS) yang merepresentasikan dialog perencanaan dan desain dan dikembangakan pada tahun 1970-an oleh Rittel. IBIS dibuat dalam bentuk hirarki, issue sebagai akar dan merepresentasikan masalah utama atau pertanyaan yang
dituju oleh argument. Berbagai position dihubungkan secara langsung dengan issue sebagai solusi potensial. Masing-masing position ditunjang oleh argument. Hirarki ini dapat berkembang ke level berikutnya dengan berkembanganya issue menjadi beberapa sub-issue.

Versi grafis dari IBIS kemudian dikembangkan oleh Conklin dan Yakemovic dan disebut sebagai gIBIS, seperti yang ditunjukkan pada gambar 3.7 berikut.

Gb37

Gambar 3.7 Struktur gIBIS Design Rationale

IBIS dimaksudkan untuk digunakan selama pertemuan atau diskusi yang dilakukan pada saat proses perancangan. IBIS dipakai sebagai alat untuk merekam dan menstrukturkan masalah yang diangkat serta keputusan yang diambil terhadap masalah tersebut.

Analisis Ruang Desain (Design Space Analysis)
MacLean dan rekan-rekannya mengembangkan pendekatan rasionalitas desain yang lebih detail dengan menekankan pada struktur post hoc dari ruang alternatif
desain yang muncul pada proyek perancangan. Pendekatan ini disusun dalam bentuk Question, Option, dan Criteria (QOC) dan disebut sebagai design space analysis.
Struktur ruang desain ini dimulai dengan Question yang merupakan masalah utama dalam perancangan. Option memberikan alternatif solusi terhadap question.
Option yang ada dinilai berdasarkan beberapa criteria untuk menentukan mana yang paling menguntungkan. Struktur design space analysis dapat dilihat pada gambar 3.8 berikut.

Gb38

Gambar 3.8 QOC ( Questions, Options, Criteria) Notation

Kunci dari design space analysis yang efektik terletak pada pemilihan question yang benar dan criteria yang tepat untuk menilai option. Question awal yang diangkat harus cukup umum sehingga dapat mengakomodasi sebagian besar ruang desain yang mungkin namun juga spesifik sehingga dapat diberikan option yang jelas. Menentukan criteria terhadap suatu option yang tepat dapat menjadi suatu hal yang sulit. Tehnik QOC menyarankan untuk menggunakan criteria yang umum seperti prinsip usability.

Rasionalitas Desain Psikologis (Psychological Design Rationale)
Kategori rasionalitas desain yang terakhir adalah psychological design rationale yang mencantumkan secara eksplisit aspek psikologis dari usability sistem interaktif untuk membuat produk yang sesuai dengan tugas yang dilakukan user. Psychological design rationale bertujuan untuk menunjukkan konsekuensi dari desain terhadap tugas yang dilakukan user.
Tahap awal dari psychological design rationale adalah mengidentifikasi tugas yang akan dilayani oleh sistem dan mengkarakteristikan tugas tersebut dalam
pertanyaan user dalam rangka mengerjakan tugas tersebut. Sebagai contoh, dalam perancangan program bantuan untuk mengoperasikan Smalltalk, programer akan
melakukan tugas yang menjawab pertanyaan-pertanyaan berikut :
• Apa yang dapat saya lakukan ? Operasi atau fungsi apa yang dapat dilakukan pada lingkungan pemrograman ini ?
• Bagaimana program ini bekerja ? Bagaimana fungsi-fungsi yang ada bekerja ?
• Bagaimana saya menggunakannya ? Begitu saya mengetahui operasi yang akan saya lakukan, bagaimana membuat programnya ?
Untuk setiap pertanyaan, dibuat sekumpulan skenario perilaku user dan sistem untuk menjawab pertanyaan tersebut. Dengan membuat psychological design rationale diharapkan desainer akan semakin memperhatikan sifat tugas yang dilakukan user dan memanfaatkan konsekuensi suatu desain untuk memperbaiki rancangan berikutnya.

Read rest of entry

Senin, Maret 15, 2010

Dialog dan Notasi 2

Masalah yang timbul terjadi pada interface manipulasi langsung (direct manipulation interface) misalnya :

Dialog berbarengan 1 : Dialog sederhana dengan tiga penukar kondisi (toggle)
Dialog berbarengan 2 : STN individual untuk bold, italic dan underline


Dialog berbarengan 3 : STN kombinasi untuk bold dan italic


Dialog berbarengan 4 : STN kombinasi untuk bold, italic dan underline. Disebut juga dengan ledakan kombinatorial yang terdiri dari N toggle dan 2n state.


Tombol ESC pada keyboard berfungsi sebagai tombol pembatalan (cancelling key) atau dalam lingkungan web sering menggunakan back. Usahakan menghindari pemisahan panah ESC di setiap submenu.


Tombol ESC mempunyai persamaan dengan menu HELP yang merupakan suatu subdialog ekstra pada STN.

PETRI NET
Merupakan salah satu formulasi lama pada ilmu komputer yang menggambarkan suatu penalaran tentang kesamaan aktivitas. Sistem dapat mempunyai lebih dari satu kondisi pada waktu yang sama dan sering digunakan untuk menggambarkan interaksi berbasis web client.

Petri Net menggambarkan suatu interaksi dengan diagram alir yang berhubungan dengan :
1. Place : suatu bit seperti state STN
2. Transition : suatu bit seperti panah STN
3. Counter : berada pada place dan dapat berbarengan pada state dialog



HERAL’S STATE CHART
Diagram dibangun untuk menspesifikasikan secara visual, sistem reaktif yang komplek dan mampu mengakomodasi masalah seperti concurrency dan escape. Diagram ini memiliki struktur hirarki dengan karakter diagram tunggal dan membagi elemen yang merepresentasikan kondisi alternatif serta aktivitas konkuren.

Gambar di atas merupakan diagram kondisi dari panel kendali televisi yang terdiri dari lima tombol ON, OFF, MUTE, SEL dan RESET. Televisi tersebut hanya berada pada kondisi ON atau standby. Misal kita mulai dengan posisi standby, menekan tombol ON atau RESET akan menyebabkan TV menyala dan tombol OFF akan menyebabkan TV kembali ke posisi standby.

Pada saat TV menyala, user dapat mengendalikan suara dengan tombol MUTE yang mengatur suara menjadi ON atau OFF dan saluran TV (channel) dengan tombol SEL untuk memilih salah satu dari empat saluran yang ada.

Garis putus-putus dan AND menyatakan bahwa kedua subdialog dapat dijalankan bersama-sama dalam urutan bebas. Subdialog SOUND mempunyai lingkaran kecil hitam dengan garis lengkung yang menunjukkan kondisi awal dan nilai default yaitu ON.

Subdialog CHANNEL mempunyai tanda H (history) yang mengindikasikan akan mengingat posisi channel terakhir yang diaktifkan user dan pada saat TV dihidupkan akan dimulai pada channel 1. RESET akan mengembalikan kondisi ke default awal dan tombol OFF berfungsi sebagai escape.

FLOWCHART
Diagram alir sangat baik untuk menjelaskan dialog yang sederhana dan menggunakan berbagai jenis kotak untuk merepresentasikan berbagai jenis aktivitas yang berbeda, namun lebih merefleksikan sudut pandang pemrogram dibanding user.




Pada umumnya flowchart sangat akrab dengan pemrograman dan digunakan untuk dialog tetapi tidak untuk algoritma internal, misalnya untuk suatu proses penghapusan entitas dalam database dapat dibuat flowchart sebagai berikut :


Perbedaan utama antara menggunakan flowchart untuk perancangan dialog dengan pemrograman adalah tingkat detail pada sisi program.

JACKSON STRUCTURED DESIGN (JSD)
Digunakan untuk berbagai aspek dari analisis tugas dan notasi dialog, misal :



Diagram JSD di atas terbagi menjadi tiga bagian yaitu LOGIN, TRANSACTION dan LOGOUT. Urutan pengoperasiannya berjalan dari kiri ke kanan. Tanda asterik (*) merepresentasikan iterasi atau pengulangan. Tanda (o) merepresentasikan pilihan atau opsional.

NOTASI TEKSTUAL
Pada notasi tekstual terdapat tiga metode yang menjelaskan suatu dialog, yaitu :
1. Grammars (tata bahasa)
2. Production Rules (aturan produksi)
3. CSP (Communicating Sequential Processes) dan proses aljabar

TATA BAHASA (GRAMMAR)
Mempunyai arti sebagai aturan dalam menggunakan suatu bahasa. Pada IMK, tata bahasa merupakan suatu ekspresi reguler yang menjelaskan suatu maksud dari suatu kalimat. Salah satu bentuk formal yang sering digunakan untuk notasi dialog tekstual adalah BNF (Backus Naur Form) dan ekspresi reguler.
BNF dan ekspresi reguler berfokus pada aksi yang dilakukan user dimana ekspresi reguler lebih sering digunakan untuk mendeskripsikan kriteria pencarian tekstual yang lebih komplek dan analisis leksikal bahasa pemrograman.

BNF diperluas untuk dialog desain yang meliputi urutan seperti pembuatan polyline pada STN yang direpresentasikan dengan SELECT-LINE CLICK CLICK* DOUBLE-CLICK. BNF tidak baik untuk menangani interface berbasis grafik dan tidak bisa menangani dialog berbarengan atau escape

ATURAN PRODUKSI
Aturan ini menggunakan kondisi IF kondisi THEN aksi. Bila semua aturan aktif dan sistem cocok dengan bagian dari kondisi maka kondisi selanjutnya tidak akan diperiksa. Atruran produksi sangat baik digunakan untuk tugas yang berbarengan tetapi tidak baik digunakan untuk tugas berurutan.

Atruran produksi memiliki dua tipe, yaitu :
1. Event-oriented Rule
Pada event ini terdapat tiga tipe yaitu USER EVENT (begin in upper case), INTERNAL EVENT (begin in lower case) dan system response event (shown in angle brackets), contoh :


2. State-oriented Rule
Merupakan aturan yang hanya berorientasi pada setiap kondisi. Misalnya :



CSP dan PROSES ALJABAR
Baik digunakan untuk dialog berurut, contoh :

Pada deskripsi di atas digunakan beberapa simbol operator, seperti :
 Simbol ? adalah event yang berupa aksi mouse yang dilakukan user. Event lain yang tidak diberi simbol merupakan even internal sistem.
 Simbol = digunakan untuk membangun deskripsi yang berarti “didefinisikan sebagai”
 Simbol → berarti urutan (sequence)
 Simbol ; menunjukkan urutan proses
 Simbol [ ] untuk menunjukkan pilihan
 Semua nama event pada dialog ditulis dalam huruf kecil, sedangkan nama proses dengan huruf besar
 Selain itu terdapat operator | | yang mengindikasikan kondisi paralel dan dapat dijalankan bergantian

DIALOG SEMANTIK
Pada dialog semantik terdapat dua aspek dialog, yaitu aplikasi dan user. Pendekatan yang dilakukan untuk menghubungkan dialog semantik adalah :
1. Spesifikasi notasi semantik merupakan bentuk semantik dengan tujuan khusus yang didesain sebagai bagian dari notasi dialog
2. Berhubungan dengan bahasa pemrograman dengan menyertakan sebagian pengkodean bahasa pemrograman ke dalam notasi dialog
3. Berhubungan dengan spesifikasi notasi formal

Dialog semantik mempunyai bentuk sebagai berikut :
1. Spesifikasi Notasi Semantik
Bentuk ini didesain sebagai bagian dari notasi dialog, misalnya adalah Augmented Transmission Networks (ATN), contoh :

2. Berhubungan dengan Bahasa Pemrograman
Notasi dialog sering melampirkan bahasa pemrograman konvensional. Input tool merupakan suatu ekspresi berbasis notasi yang menggunakan bahasa C dalam mengekspresikan dialog semantik. Penandaan dengan menggunakan notasi ; , pilihan menggunakan notasi + dan kondisi dengan notasi :|, contoh :









3. Berhubungan dengan Spesifikasi Notasi Normal
SPI (Specifying and Prototyping Interactioni) dibagi menjadi dua bagian :
a. EventCSP yang merupakan suatu urutan dialog murni,
b. EventISL yang merupakan suatu semantik bebas target,

DESAIN DAN ANALISIS DIALOG
Terdapat tiga isu yang berkaitan dengan analisis properti dialog, yaitu :
1. Berfokus pada aksi yang dilakukan oleh user, apakah dispesifikasikan dengan cukup konsisten
2. Memperhatikan kondisi dialog, menyangkut kondisi yang diinginkan dan yag ingin dihilangkan
3. Isu presentasi dan leksikal, bagaimana tampilan dan fungsi sebuah tombol

PROPERTI AKSI
Ada tiga aksi dasar yaitu :
1. Select from menu
2. Click on a point
3. Double-click on a point

Ada tiga karakteristik dialog yang berhubungan dengan properti aksi yaitu :
1. Kelengkapan
Berupa antisipasi bagaimana perilaku sistem pada kondisi yang tidak diperkirakan atau pada setiap kondisi khusus, misal dengan peringatan atau pembatalan proses yang sedang dilakukan
2. Determinasi
Aturan dasar untuk mengatasi dua aturan yang diaktifkan oleh sebuah kejadian.
3. Konsistensi
Aksi yang sama pada situasi yang berbeda akan melakukan hal yang sama pula.



PRESENTASI DAN PROPERTI LEKSIKAL
Perancangan dialog harus terpisah (independent) dari perancangan detail dari presentasi dan interface leksikal. Seorang desainer harus menentukan fungsi sistem terlebih dulu baru kemudian menggunakan model kognitif. Desain dialog harus tidak terikat pada detail presentasi dialog, oleh karena itu perlu dihindari :
1. "Tekanan" (suara atau pesan) keran menyalahkan user
2. Pesan terlalu generik, misalnya WHAT? Atau SYNTAX ERROR
3. Pesan yang sulit dimengerti, misal FAC RJCT 004004400400

Kesalahan diklasifikasikan sebagai berikut :
1. Mistakes
Merupakan suatu aksi yang diambil berdasarkan keputusan yang salah, misal menggeser icon harddisk ke recycle bin yang berarti menghapus semua file dari harddisk
2. Slips
Suatu kesalahan yangtidak disengaja
3. Capture error
Kesalahan karena terlalu sering atau kebiasaan, misal pada editor vi, perintah save (w) menjadi save&quit (wq)
4. Description error
Kesalahan dalam melakukan aksi pada objek yang salah, misal klik tanda x untuk menutup editor tetapi yang di-klik adalah jendela aplikasi
5. Data-driven error
Kesalahan karena pengaruh data dari area edit, misal menyimpan file dengan sesuatu yang terbaca di sekitar window bukan yang diinginkan
6. Assosiative-activation error
Kesalahan karena pengaruh data yang ada di dalam pikiran user saat itu, misal misal menyimpan file dengan sesuatu yang ada di pikiran kita saat itu
7. Loss-of-activation error
Kesalahan karena lupa apa yang harus dilakukan, misal lupa apa yang ingin di-search
8. Mode error
Kesalahan akibat lupa ada di ‘dunia’ mana, misal mengetik perintah padahal sedang berada di dalam ruang pengeditan teks
9. Keliru
Aksi salah diambil berdasarkan keputusan yang salah

DESAIN NON ANTROPOMORFIK
Merupakan suatu dialog singkat dan praktis yang digunakan pada interface untuk mempertimbangkan hal-hal sebagai berikut :
1. Atribut ‘bebas’ dapat membingungkan atau ‘menyesatkan’ user
2. Pentingnya perbedaan yang jelas antara orang dan komputer
3. Walaupun menarik bagi beberapa orang, suatu interface antropomorfik dapat menimbulkan keragu-raguan

Antropomorfik artinya memanusiakan mesin, misalnya pesan “Saya akan menunggu Anda memasukkan input” berubah menjadi “Masukkan input!”





Tugas Design dan Notasi Dialog ini, untuk memenuhi tugas IMK untuk bulan Maret.

daftar pustaka : http://aqwamrosadi.staff.gunadarma.ac.id/Downloads/files/12721/pertemuan+9.doc
Read rest of entry

Rabu, Maret 10, 2010

Dialog dan Notasi

Dialog adalah pertukaran instruksi dan informasi yang mengambil tempat antara user dan sistem komputer
Notasi dialog pada IMK *interkasi manusia & Komputer* terdiri dari :

1. Diagramatik
Dengan menggunakan teknik State Transtition Network (jaringan transisi kondisi dan status), flowchart (diagram alir) dan diagram JSD (Jackson Structured Design)

2. Tekstual
Dengan menggunakan teknik Formal Grammar (tata bahasa formal), Production Rules (aturan produksi) dan CSP

Pada dasarnya gaya interaksi dan dialog menggunakan menggunakan sistem tanya jawab. Sistem memerlukan input dari user dan sistem akan menjawabapa kebutuhan dari user. Agar user mengerti cara berkomunikasi maka user perlu memahami bahasa komputer.

Bahasa komputer mempunyai tingkatan sebagai berikut :
1. Leksikal
Merupakan tingkat yang paling rendah, misalnya bentuk ikon pada layar atau tombol ditekan. Pada bahasa manusia ekuivalen dengan bunyi atau ejaan suatu kata
2. Sintaktik
Urutan dan struktur input output. Pada bahasa manusia ekuivalen dengan tatabahasa dari suatu kalimat
3. Semantik
Makna dari percakapan yang berhubungan dengan pengaruhnya pada struktur data internal komputer. Kondisi internal berasal dari dialog user dan sistem.

STRUKTUR DIALOG MANUSIA

Dialog antara manusia dan komputer bersifat terstruktur sedangkan dialog manusia dengan manusia tidak terstruktur tetapi formal, misal :

Dosen : Apakah matakuliah kalkulus itu sulit ?
Mahasiswa : Ya, pak !
Dosen : Apakah matakuliah Interaksi Manusia dan Komputer itu sulit ?
Mahasiswa : Ya, pak !
Dosen : Apa pelajaran yang tidak sulit bagi kalian ? (mulai kesal)
Mahasiswa : Semuanya sulit, pak !
Dosen : Semuanya keluarkan kertas, kita ulangan… (dengan nada kesal)

Pelajaran dari dialog di atas :
1. Kuliah adalah suatu pelayanan
2. Skrip dibagi menjadi tiga bagian
3. Pembahasan tentang kesulitan
4. Beberapa kontribusi tetap – Ya, pak !
5. Variabel lain – siapa yang selalu mengatakan Iya
6. Instruksi – Keluarkan kertas

Jika ada yang mengatakan Tidak, pak maka akan timbul dialog alternatif seperti :

Dosen : Apakah matakuliah kalkulus itu sulit ?
Mahasiswa : Ya, pak !
Dosen : Apakah matakuliah Interaksi Manusia dan Komputer itu sulit ?
Mahasiswa : Tidak, pak !
Dosen : Apakah cuma kalkulus yang sulit ?
Mahasiswa : Ya, pak !
Dosen : Baik. Sekarang kita lanjutkan pelajaran


Struktur dialog manusia kadang dipengaruhi oleh emosi, situasi serta berbagai faktor lain. Oleh karena itu struktur dialog manusia mengandung ketidak konsistenan. Dialog dengan komputer biasanya terstruktur dan terbatas.

Beberapa karakteristik yang ditemukan pada sebuah dialog manusia dengan komputer diantaranya adalah :
1. Partisipan harus menyebutkan dialognya dalam urutan tertentu
2. Beberapa dialog diantaranya telah ditetapkan sebelumnya
3. Beberapa bagian tertentu dari dialog dilakukan secara bersamaan (concurrently)
4. Dialog berikutnya pada umumnya tergantung tergantung pada respon dari partisipan
5. Dialog dengan komputer mungkin saja tidak mengakomodasi semua kejadian yang mungkin
6. Deskripsi dialog biasanya tidak langsung menuju pada arti kata-katanya (semantik) tetapi pada level sintaksis
Ada beberapa hal yang perlu diperhatikan dalam perancangan dialog, yaitu :
1. Rangkaian dialog menggambarkan struktur tugas
2. Beberapa rangkaian dialog tambahan digunakan untuk user support misal help system atau tutorial sub-system
3. Rangkaian dialog diurutkan sesuai struktur tugas

Prinsip yang digunakan dalam desain dialog adalah membagi sistem menjadi beberapa bagian yang disebut dengan modul, misalnya pembagian modul dalam sebuah sistem pemesanan buku di perpustakaan seperti gambar berikut :

Ada empat alasan utama penggunaan deskripsi pemisahan dialog, yaitu :
1. Mudah dianalisis
2. Pemisahan elemen interface dari semantik
3. Dapat dilakukan sebelum program ditulis dan memberi dampak pada desain program
4. Kadang menggunakan prototipe tool

Kondisi merupakan sesuatu pada saat sekarang yang berhubungan dengan masa lalu dan mempengaruhi masa yang akan datang.
Ada dua masalah pada kondisi, yaitu :
1. Terlalu sedikit kondisi
Ada beberapa elemen yang hilang dari spesifikasi sehingga perlu diwaspadai, misal dialog pada tingkat spekulasi
2. Terlalu banyak state (keadaan)
Bila state terlalu kompleks mungkin akan terjadi redudansi dan ekstensibilitas

NOTASI DIAGRAMATIK
Merupakan bentuk yang sering digunakan dalam notasi dialog. Kelebihannya adalah memungkinkan desainer untuk melihat secara sekilas struktur dialog. Kelemahannya adalah sulit untuk menjelaskan struktur dialog yang lebih luas dan kompleks.

Metode yang digunakan dalam notasi ini adalah :
1. State Transition Network (STN)
2. Petri Net
3. Heral’s State Chart
4. Flowchart
5. Jackson Structured Design (JSD) Diagram

STATE TRANSITION NETWORK (STN)
STN atau kondisi transisi jaringan digunakan sejak tahun 1940-an. Metode ini menggunakan circle atau state yang dihubungkan satu dengan yang lain dengan anak panah yang menandakan suatu aksi atau kejadian.

Aturan dalan STN adalah :
1. Dimulai dari START state
2. State tengan berhubungan dengan arah panah
3. State kadang berputar (iterasi)
4. State mungkin meliputi pilihan user
5. Diakhiri dengan FINISH state

Contoh :

Dari gambar di atas dapat disimpulkan bahwa STN dapat merepresentasikan beberapa hal yang terkait dengan dialog, yaitu :
1. Urutan (sequence) dari aksi yang dilakukan user dan respon yang diberikan oleh sistem
2. Pilihan bagi user (choice)
Dari kondisi menu, user dapat memilih circle sehingga sistem berpindah ke circle-1 dan pilihan circle pada menu di-highlight. Alternatif lain, user dapat memilih line sehingga sistem berpindah ke kondisi line-1
3. Iterasi (iteration)
Pada kondisi line-2, transisi dapat kembali ke line-2 jika user menambahkan titik baru pada polyline dan akan berpindah ke kondisi finish hingga user melakukan double-click

Setiap lingkaran menandakan kondisi dari sistem, misalnya menu adalah kondisi sistem yang menunggu user untuk memilih circle atau line. Circle-2 adalah kondisi setelah user memilih sebuah titik sebagai pusat lingkaran dan menunggu user menentukan titik akhir lingkaran. Diantara kondisi tersebut terdapat tanda panah yang disebut transisi. Tanda panah diberi label yang menjelaskan tentang tindakan user yag menyebabkan transisi perpindahan kondisi dan respon dari sistem.

Kondisi circle-1 adalah kondisi sistem menunggu user untuk memilih pusat lingkaran. Jika user telah meng-klik pusat lingkaran maka kondisi sistem akan berpindah ke circle-2 dan direspon oleh sistem dengan menggambar rubber band.

Pada hirarki STN, pengaturan dialog yang lebih kompleks dan penamaan sub dialog adalah seperti contoh berikut :

Struktur hirarki STN dapat digunakan untuk sistem yang besar dan memiliki tambahan berupa gabungan kondisi (composite state) yang digambarkan persegi panjang dengan gambar struktur STN berukuran kecil didalamnya. Masing-masing persegi panjang ini menggambarkan submenu yang berkaitan.

STN sangat baik untuk merepresentasikan percontohan, pilihan dan bagian alternatif dari suatu desain namun sangat buruk dalam menangani dialog yang terdiri dari bagian yang sama, misalnya bentuk teks bold, underline, italic dan kombinasi lainnya.

sumber : http://blackantzz.blogspot.com
Read rest of entry

Senin, Februari 22, 2010

Usability

Usability Adalah masalah optimasi penggunaan sistem oleh pengguna, dimana seluruh fungsi nya tergantung dari pengguna. Jika pengguna tidak dapat secara penuh menggunakan sistem,maka sistem itu hanya sampai "disitu". Berbeda jika penggunan mampu mengoptimasikan sistem yang ada, maka sistem itu sangat berdaya guna pakai. Dalam kata lain, Sistem yang baik akan dipergunakan secara maksimal oleh pengguna sehingga semua kemampuan sistem dapat termanfaatkan.

Pengukuran Usability
Untuk mengukur usabilty dapat menggunakan cara-cara berikut:

ISO dan DIX (1993)

Usability dari ISO 9241
(Alan Dix Et all, 1993)`

Sasaran usability
Efektivitas
Efisiensi
Kepuasan
Kesesuaian terhadap pekerjaan
Persentase tujuan tercapai
Waktu utk menyelesaikan tugas
Skala kepuasan tercapai
Kecocokan untuk user terlatih
Cacah fitur canggih terpakai
Relatif efisiensi dibanding pengguna ahli
Skala kepuasan dengan fitur canggih
Kemudahan dipelajari
Persentase fungsi2/fitur dipelajari
Waktu utk belajar
Skala kepuasan untuk kemudahan dipelajari
Error tolerance
Persentase error terkoreksi dengan baik
Waktu untuk mengkoreksi error
Skala kepuasan untuk penanganan error

Prinsip Usability
Dix (1993)

• Learnability : kemudahan bahwa pengguna baru dapat menggunakan interaksi secara efektif dan memperoleh maximal kinerja.
• Flexibility : ragam cara user dan sistem dapat bertukar informasi
• Robustness : dukungan untuk user agar dapat mencapai tujuan dengan baik.

Prinsip Learnability

•Predictability
–Kemampuan untuk menentukan efek dari tindakan yang akan dilakukan berdasarkan pada interaksi sebelumnya/yang pernah dilakukan
– operation visibility

•Synthesizability
–Penilaian atas efek tindakan yang telah dilakukan
– Immediate vs. eventual honesty

• Familiarity
– Bagaimana pengetahuan sebelumnya dapat diaplikasikan pada sistem yang baru
–guessability; affordance

•Generalizability
–Pegembangan pengetahuan interaksi spesifik terhadap situasi yang baru

•Consistency


Prinsip Flexibility
• Dialogue initiative
– Kebebasan dari sistem untuk menentukan batasan pada dialog input

• Multithreading
- Kemampuan sistem untuk mendukung lebih dari satu interaksi pengguna pada saat yang sama

• Task migratability
–Melewatkan tanggung jawab eksekusi tugas antara pengguna dan sistem.

• Substitutivity
– Mengijinkan nilai yang setara dari input dan output dapat disubstitusikan
– representation multiplicity; equal opportunity

• Customizability
– Kemampuan antarmuka pengguna untuk dapat dimodifikasi oleh pengguna (adaptability) atau system (adaptivity).

Kemantapan sistem
• Pengguna dapat mengkoreksi “error” setelah “error’ tsb diketahui
• Pengguna merasa waktu tanggap sistem cukup baik
• Sistem dapat memenuhi pelayanan yang diharapkan pengguna

Bagian ini menjelaskan beberapa prinsip dasar di balik petunjuk teknis yang lebih spesifik direkomendasikan dalam dokumen ini. Kami percaya bahwa prinsip-prinsip ini penting bagi semua pengembangan aplikasi.


Desain untuk Orang

Ingat bahwa tujuan dari aplikasi perangkat lunak apapun untuk memungkinkan beberapa kelompok orang untuk menyelesaikan rangkaian tugas-tugas tertentu. Jadi, hal pertama yang didirikan ketika merancang aplikasi Anda adalah:

* siapa penggunanya ?
* apa saja yang di izinkan untuk mereka lakukan ?

Sebagai contoh, Anda mungkin akan merancang sebuah aplikasi yang akan memungkinkan insinyur (perangkat lunak, listrik, atau mekanik) untuk membuat diagram. Anda mungkin merancang sebuah aplikasi yang akan memungkinkan administrator sistem untuk mengkonfigurasi dan memonitor web server. Anda mungkin merancang sebuah aplikasi yang akan membantu siswa sekolah dasar untuk belajar matematika.

Yang penting adalah bahwa Anda mengenal target pasar Anda, dan Anda memahami tujuan mereka berdua dan tugas-tugas yang diperlukan untuk mencapai tujuan tersebut. Ada sejumlah besar interaksi profesional desainer yang menulis buku dan mengajar kursus tentang metode desain yang dapat membantu proses ini, banyak yang sangat berguna. Sebagian besar metode ini, bagaimanapun, didihkan bawah untuk memahami cara-cara khusus pengguna Anda, memahami tugas-tugas anda ingin membantu mereka capai, dan mencari cara untuk mendukung tugas-tugas dalam aplikasi Anda.

Jangan Batasi Pengguna basis anda.

Jika Anda merancang aplikasi untuk digunakan oleh para insinyur, atau oleh anak-anak, atau oleh administrator sistem, pastikan untuk menciptakan aplikasi yang dapat digunakan oleh semua insinyur, anak-anak, atau administrator sistem, termasuk mereka yang cacat atau mereka yang are mampu mengenali dari bahasa yang berbeda dari Anda. Sadar akan isu-isu aksesibilitas dan internasionalisasi dan lokalisasi masalah, banyak di antaranya ditujukan oleh panduan dalam dokumen ini.

Aksesibilitas

Aksesibilitas berarti memungkinkan orang-orang cacat dan semacamnya untuk berpartisipasi dalam kegiatan hidup: dalam kasus ini, secara khusus untuk menggunakan perangkat lunak Anda.

Contoh:

* Pengguna Buta warna mungkin tidak dapat menggunakan aplikasi Anda jika Anda hanya bergantung pada kode warna untuk membedakan jenis informasi yang berbeda.


* Pengguna dengan gangguan pendengaran mungkin tidak dapat menggunakan aplikasi Anda jika Anda mengandalkan suara untuk menunjukkan informasi penting.

* Pengguna dengan gerakan terbatas mungkin tidak dapat menggunakan aplikasi Anda jika Anda tidak memberikan persamaan untuk perintah keyboard

Perangkat lunak Anda juga harus digunakan dengan antarmuka suara, seperti pembaca layar gnopernicus, alternatif perangkat input, dan teknologi bantu lainnya. GNOME standar perpustakaan melakukan sebagian besar pekerjaan ini untuk Anda, tetapi dengan sedikit usaha ekstra Anda dapat membuat aplikasi Anda setiap bit berguna bagi pengguna yang mengandalkan teknologi tersebut atau untuk mereka yang tidak menggunakannya.

Informasi lebih lanjut tentang aksesibilitas di GNOME dapat ditemukan pada GNOME Accessibility Project.


Internasionalisasi dan Localisasi.


Internasionalisasi adalah merancang perangkat lunak sehingga dapat berfungsi dalam lingkungan bahasa yang berbeda.Lokalisasi adalah proses benar-benar menerjemahkan pesan, label, dan lain elemen antarmuka aplikasi ke bahasa lain.

GNOME memiliki dukungan yang sangat baik untuk kedua internasionalisasi (juga disebut sebagai i18n) dan localization (juga disebut sebagai l10n). Dalam kebanyakan kasus, cukup menggunakan GNOME standar API untuk menampilkan teks dan pesan akan memungkinkan Anda atau orang lain pelokalan aplikasi Anda untuk locales lain. Untuk informasi lebih lanjut tentang bagaimana membuat aplikasi Anda dilokalisasi, lihat halaman proyek Pango (Pango adalah GNOME internasionalisasi perpustakaan untuk rendering teks), di halaman Terjemah GNOME, dan halaman Proyek Terjemahan GNOME.

MenCocokan Antara Aplikasi Anda dan Dunia Nyata

Selalu menggunakan kata-kata, frasa, dan konsep yang akrab bagi pengguna daripada istilah dari sistem yang mendasarinya. Gunakan istilah yang berhubungan dengan pengguna pengetahuan tentang tugas mendukung aplikasi Anda. Sebagai contoh, dalam kedokteran, kertas folder yang berisi semua informasi tentang pasien tertentu disebut "tabel." Oleh karena itu, aplikasi medis akan merujuk pada catatan pasien yang berisi informasi yang sama sebagai kertas grafik sebagai "grafik pasien" daripada sebagai "catatan database pasien."

Anda dapat sering mengambil keuntungan dari pengguna Anda "pengetahuan tentang dunia nyata dengan menggunakan metafora-yaitu, sebuah konsep asing dari dunia luar-untuk mewakili unsur-unsur di dalam aplikasi Anda.

Contoh:

* gambar dari folder file menyarankan sebuah wadah di mana dokumen dapat ditempatkan
* keranjang sampah menyarankan sebuah wadah ke item yang dapat ditempatkan ketika mereka tidak lagi diperlukan

Bila menggunakan metafora, bagaimanapun, adalah penting untuk tidak mengambil metafora terlalu harfiah, maupun untuk memperluas metafora di luar penggunaan yang wajar. Sebagai contoh, kapasitas folder file tidak boleh terbatas pada kapasitas folder file fisik, yang barangkali hanya dapat berisi beberapa dokumen sebelum menjadi berat. Di sisi lain, sebuah keranjang sampah tidak boleh digunakan untuk apapun selain tempat sampah. Tidak boleh digunakan, misalnya, untuk mengeluarkan removable disk seperti disket atau CD.
Read rest of entry
 

My Blog List

Term of Use