arsitektur desain data pada rpl

24
LAPORAN RPL METODE DESAIN Di Susun Oleh: Yarliansyah .A. Yeyen Susianti .M. JOIN PROGRAM PENDIDIKAN BA-MALANG PPGT/VEDC MALANG 2005

Upload: ari-alfian

Post on 15-Aug-2015

23 views

Category:

Education


0 download

TRANSCRIPT

Page 1: Arsitektur desain data pada RPL

LAPORAN RPL

METODE DESAIN

Di Susun Oleh:

Yarliansyah .A.

Yeyen Susianti .M.

JOIN PROGRAM PENDIDIKAN BA-MALANG

PPGT/VEDC MALANG

2005

Page 2: Arsitektur desain data pada RPL

DAFTAR ISI

Daftar isi iiKata pengantar iii

METODE DESAIN 11.1 Desain Data 1

1.2 Desain Arsitektur 21.2.1 Kontributor 21.2.2 Area Aplikasi 2

1.3 Proses Desain Arsitektur 21.3.1 Aliran Transformasi 31.3.2 Aliran Transaksi 3

1.4 Pemetaan Transformasi 3

1.5 Pemetaan Transaksi 4

1.6 Pasca Pemerosesan Desain 4

1.7 Optimasi Desain Arsitektur 5

1.8 Desain Interface 51.8.1 Desain Interface Pemakai Internal dan Eksternal 61.8.2 Desain Interface Pemakai 6

1.9 Desain Interface Manusia-Mesin 61.9.1 Model – model Desain Interface 61.9.2 Pemodelan dan Analisis Tugas 71.9.3 Masalah – masalah Desain 81.9.4 Peranti Implementasi 101.9.5 Evaluasi Desain 10

1.10 Pedoman Desain Interface 111.10.1 Interaksi Umum 111.10.2 Tampilan Informasi 111.10.3 Input Data 12

Page 3: Arsitektur desain data pada RPL

Kata Pengantar

Rekasaya perangkat lunak dikenal sebagai disiplin yang sah, layak mendapatkan

penelitian yang serius. Studi yang sungguh-sungguh dan diskusi yang matang sepanjang

Industri “rekayasa perangkat lunak” telah menggantikan progrmer. Model proses

perangkat lunak, metode-metode rekayasa perangkat lunak, dan alat-alat perangkat lunak,

telah diadopsi dengan sukses dibabyak spektrum aplikasi industri.

Laporan ini dibuat bertujuan untuk melengkapi laporan-laporan dari pembahasan

materi rekayasa perangkat lunak semester II. Meteri yang disampaikan pada laporan ini

diambil dari beberapa sumber daintaranya buku berjudul “ rekayasa perangkat lunak”

(Rogers.Pressman,Ph.D).

Laporan ini menyajikan konsep-konsep yang diperlukan untuk bab-bab

selanjutnya, selain itu juga menyajikan topik-topik yang relevan bagi mereka yang

merencanakan, mengelola, dan mengontrol sebuah proyek pengembangan perangkat

lunak. Dalam laporan ini berisi metode-metode analisis, desain dan pengujian yang

dipandang sebagai sekolah konversional dari rekaysa perangkat lunak.

Penyusunan laporan ini diharapkan para pembaca dapat memahami secara mudah

metode desain pada RPL dan dapat langsung mempraktekkannya setelah membaca.

Dengan selesainya laporan ini kami ucapkan teima kasih kepada pihak-pihak yang

telah membantu. Sehingga dapat mempermudah penyusun dalam menyelesaikan laporan

ini.

Penyusun

Page 4: Arsitektur desain data pada RPL

METODE DESAIN

1.1 DESAIN DATA

Desain data adalah aktivitas pertama ( dan beberapa sering mengatakan yang

terpenting ) dari empat aktivitas desain yang dilakukan selama rekayasa perangkt

lunak.

Proses desain data dirangkum oleh Wasserman[WAS80]:

Aktivitas utama selama desain data adalah memilih representasi logis dari objek

data (struktur data) yang didefinisikan selama tahap definisi persyaratan dan

spesifikasi. Proses pemilihan dapat melibatkan analisis algoritmik terhadap struktur

alternative untuk menentukan desain yang pling efisien atau hanya melibatkan

penggunaan serangkaian modul (sebuah paket) yang memberikan operasi yang

diperlukan pada beberapa reprsentsi suatu objek.

Wasserman [WAS80] mengusulkan serangkaian prinsip yang dapat digunakan

untuk menentkan dan mendesain data. Serangkaian prinsip itu adalah sebagai

berikut;

1. Prinsip analisis sistematik yang di apliksikan pada fungsi dan perilaku

seharusnya diaplikasikan juga pada data.

2. Semua struktur data dan operasi yang akan dilakukan pada masing – masing

struktur data harus diidentifikasi.

3. Kamus data harus dibangun dan digunakn untuk menentukan baik data

maupun desain program.

4. Keputusan desain data tingkat rendah harus ditunda sampai akhir proses

desain.

5. Representasi struktur data hanya boleh diketahui oleh modul – modul yang

harus menggunkan secara langsung data yang didisikan didalam struktur

tersebut.

6. Pustaka struktur data danoperasi yang digunakan yang dapat diaplikasikan

pada struktur data tersebut harus dikembangkan.

7. Desain perangkat lunak dan bahasa pemerograman harus mendukung

spesifikasi dan realisasi dari tipe – tipe data abstrak.

Page 5: Arsitektur desain data pada RPL

1.2 DESAIN ARSITEKTUR

Desain arsitektur adalah untuk mengembangkan struktur program modular dan

merepresentasikan hubungan control antar modul.

Metode desain yang disajikan pada bagian ini mendorong prekayasa perangkat

lunak untuk berkosentrasi pada desain arsitektur sebelum mencemaskan masalah

perpipaan.

1.2.1 KONTRIBUTOR

Desain arsitektur berakar dari konsep esain yang lebih awal yang menekankan

pada modularitas [DEN73], desain topdown[WIR71],dan pemerograman

terstruktur[DAH72,LIN70]. Steven, Myers, dan Constantine [STE74], adalah perintis

desain perangkat lunak yang didasarkan pada aliran data melalui sebuah sistem.

1.2.2 AREA APLIKASI

Masing – masing metode desain mempunyai kelemahan dan kelebihan. Factor

seleksi yang penting untuk suatu metode desain adalah luasnya apliksi dimana

aplikasi dapat di aplikasikan. Desain berorientasi pada alira dat dapat menyetujui

rentang area aplikasi yang luas.

1.3 PROSES DESAIN ARSITEKTUR

Desain yang berorientasi pada aliran data merupakan suatu metode desain

arsitektur yang mengijinkan transisi yang baik dari model analisis ke deskripsi desain

dari struktur program. Trnsisi dari aliran informasi (yang ditujukan sebagai diagram

aliran data) kestruktur dilakukan bagian dari proses 5 langkah:

1. Tipe aliran informasi dibangun.

2. Batas aliran diindikasikan.

3. DFD dipetakan didalam struktur program.

4. Hirarki kontrol ditentukan dengan pemfaktoran.

5. struktur resultan disaring atau diperhalus dengan menggunakan

pengukuran desain dan heuristik.

Pada bagian ini kita akan mengamati 2 tipe aliran.

Page 6: Arsitektur desain data pada RPL

1.3.1 ALIRAN TRANSFORMASI

Informasi memasuki system bersama dengan jalur yang mentransformasikan data

eksternal kedalam bentuk internal dan akan didefinisikan sebagai aliran masuk. Pada

inti perangkat lunak terjadi transisi. Data yang masuk dilewatkan melalui pusat

transformasi dan mulai bergerak sepanjang jalur yang sekarang mengarah keluar dari

perangkat lunak. Data yang mengalir disepanjang jalur – jalur disebut aliran keluar.

Keseluruhan aliran data terjadi dalam cara yang berurutan dan mengikuti satu atau

hanya beberapa jalur”garis lurus”. Bil segmen dari diagram aliran data menunjukkan

karakteristik tersebut, maka disitu ada aliran transformasi.

1.3.2 ALIRAN TRANSAKSI

Aliran transaksi ditandai dengan pergerakan data sepanjang jalur masuk yang

mengkonversi informasi dunia eksternal kedalam suatu transaksi. Transaksi tersebut

dievaluasi, dan berdasarkan nilai, aliran sepanjang satu daribeberapa jalur aksi

diinisiasi. Pusat aliran informasi dari mana banyak jalur aksi berasal disebut pusat

transaksi.

1.4 PEMETAAN TRANSFORMASI

Pemetaan transformasi adalah serangkaian langkah desain yang mengijinkn

sebuah DFD dengan karakteristik aliran transformasi untuk dipetakan ke dalam

template yang telah ditentukan sebelumnya untuk struktur program.

Langkah – langkah desain pemetaan transformasi:

1 kajilah model sistem fundamental.

2 Kajilah dan saringlah diagram aliran data untuk perangkat.

3 Tentukan apakah DFD memiliki karakteristik aliran transformasi

dan transaksi.

4 Isolasi pusat transformasidengan mengkhususkan batas aliran

masuk dan keluar.

5 Lakukan”pemfaktoran tingkat pertama”

6 Lakukan”pemfaktoran tingkat kedua”

Page 7: Arsitektur desain data pada RPL

7 Saringlah struktur program iterasi pertama dengan menggunakan

heuristic desain bagi kualitas perangkat lunak yang telah

ditingkatkan.

1.5 PEMETAAN TRANSAKSI

Pada banyak aplikasi perangkat lunak, item data tunggal memicu satu atau

sejumlah aliran informasi yang mempengaruhi suatu fungsi yang diimplikasikan oleh

pemicu item data. Item data yang disebut transaksi, dan karakteristik alirannya yang

terkait.

Langkah – langkah desain pemetaan transaksi:

1. Kaji model sistem fundamental.

2. Kaji dan saring diagram aliran data untuk perangkat lunak.

3. Tentukan apakah DFD memiliki karakteristik aliran transformasi atau

transaksi.

4. Identifikasi pusat transaksi dan karakteristik aliran sepanjang masing –

masing jalur aksi.

5. Petakan DFD pada sebuah struktur program yang sesuai dengan

pemerosesan transaksi.

6. faktorkan dan saringlah struktur transaksi dan struktur masing – masing

jalur aksi.

7. saringlah strutur program iterasi pertama dengan menggunakan heuristic

desain untuk kualitas perangkat lunak yang dikembangkan.

1.6 PASCA PEMEROSESAN DESAIN

Aplikasi dari pemetaan transaksi dan transformasi yang berhasil kemudian

ditambahkan pada dokumentasi tambahan yang dibutuhkan sebagai bagian dari

desain arsitektur. Setelah struktur dikembangkan dan disaring, tugas – tugas berikut

harus dilakukan:

Mengembangkan narasi pemerosesan untuk masing – masing modul.

Menyediakan deskripsi interface untuk masing – masing modul.

Menentukan struktur data local dan global.

Page 8: Arsitektur desain data pada RPL

Mencatat semua batasan desain.

Mengkaji desain.

Mempertimbangkan “optimasi” (bila perlu dan dibenarkan).

1.7 OPTIMASI DESAIN ARSITEKTUR

Desainer perangkat lunak harus memperhatikan perkembangan representasi

perangkat lunak yang akan memenuhi semua fungsi dan persyaratan kinerja dan

penerimaan jasa berdasarkan pengukuran desain kualitas. Oleh karena itu cukup

beralasan untuk mengusulkan pendekatan berikut ini untuk perangkat lunak kinerja –

kritis.

1. Kembangkan dan saringlah struktur program tanpa memperhatikan optimasi

kinerja – kritis.

2. Gunakan peranti CASE yang mensimulasi kinerja run – time untuk menisolasi

area inesifiensi.

3. selama iterasi desain selanjutnya, pilihlah modul yang dicurigai “time hot”

dan dengan hati – hati kembangkanlah prosedur(algoritma – algoritma) untuk

efisiensi waktu.

4. Kodekan sebuah bahasa pemerograman yang sesuai.

5. Instrumentasikan perangkat lunak untuk mengisolasi modul yang menjelaskan

utilisasi proses yang berat.

6. Bila perlu, Desain ulang atau kodekan kembali bahasa yang tergantung pada

mesin untuk meningkatkan efisiensi.

1.8 DESAIN INTERFACE

Desain interface memfokuskan diri pada 3 area perhtian:

1. Desain interface antara modul – modul perangkat lunak.

2. Desain interface antara perangkat lunak dan produser dan konsumen

informasi bukan manusia lainnya (yakni entitas eksternal lainnya).

3. Desain interface antara pemakai dan komputer.

Page 9: Arsitektur desain data pada RPL

1.10.4 DESAIN INTERFACE PEMAKAI INTERNAL DAN EKSTERNAL

Desain interface program internal, yang kadang disebut desain interface

intermodular, dikendalikn oleh data yang harus mengalir diantara modul – modul dan

karakteristik bahasa pemerograman dimana perangkat lunak akan diimplementasikan.

Secara umum, model analisis berisi banyak informasi yang dibutuhkan bagi desain

interface intermodular.

Desain interface eksternal dimulai dengan evaluasi terhadap masing – masing

entitas eksternal yang di representasikan pada DFD model analisis. Persayaratan data

dan kontrol dari entitas eksternal ditentukan, dan dirancang interface eksternal yang

sesuai. Desain interface eksternal bagi masing – masing sensor didasarkan item

kontrol dan data spesifik yang dibutuhkan untuk sensor tersebut.

Baik desain interface eksternal maupun internal harus dirangkai dengan validasi

data dan algoritma penanganan kesalahan dalam sebuah modul. Karena efeksamping

menyebar melalui interface program, maka penting untuk mengecek semua aliran

data dari modul ke modul (atau ke dunia luar) untuk memastikan bahwa data sesuai

dengan batas yang telah ditentukan selama analisis persyaratan.

1.8.2 DESAIN INTERFACE PEMAKAI

Desain interface pemakai berkaitan dengan study terhadap manusia, juga terhadap

isu – isu teknologi. Siapakah para pemakainya? Bagaimana pemakai belajar

berinteraksi dengan sistem berbasis komputer yang baru? Bagaimana pemakai

menginterpresentasikan informasi yang dihasilkanoleh sistem? Apakah yang

diharapkan dari sistem tersebut? Itu hanya sebagian kecil dari banyak pernyataan

yang harus diajukan dan dijawab sebagai bagian dari desain interface pemakai.

1.11 DESAIN INTERFACE MANUSIA-MESIN

1.11.1 MODEL – MODEL DESAIN INTERFACE

Ada empat model yang berbeda pada saat manusia-komputer/ human-komputer

interface (HCL) akan didesain. Perekayasa perangkat lunak menciptakan sebuah

model desain, perekayasa manusia ( atau perekayasa perangkat lunak) membangun

model pemakai, pemakai akhir mengembangkan citra mental yang sering disebut

Page 10: Arsitektur desain data pada RPL

user’s model atau perception, dan implementer sistem menciptakan system image

[RUB88].

Model desain dari keseluruhan sistem menggabungkan data, arsitektur, interface,

dan representasi prosedural dari perangkat lunak.

Model pemakai menggambarkan profil para pemakai akhir dari sistem. Untuk

membangun interface pemakai yang efektif,”semua desain harus dimulai dengan

suatu pemahaman terhadap pemakai yang dimaksudkan, meliputi profil, usia, jenis

kelamin”[SHN87]. Para pemakai juga dapat dikategorikan sebagai:

Orang baru

Pemakai intermiten yang banyak pengetahuan

Pemakai yang banyak pengetahuan dan sering

Persepsi sistem (model pemakai) merupakan citra sistem yang ada dikepala

seorang pemakai akhir. Sebgai contoh, bila pemakai pengelola kata tersebut, persepsi

sistem akan menuntun respon tersebut.

Citra sistem merangkai manifestasi bagian luar dari sistem berbasis computer

(tampilan luar dan “rasa” interface), dengan semua informasi yang mendukung

(buku-buku, manual, pita video) yang menggambarkan sintaksis dan semantik sistem.

1.11.2 PEMODELAN DAN ANALISIS TUGAS

Pemodelan dan analisis tugas dapat diaplikasikan untuk memahami tugas – tugas

yang sedang dilakukan oleh banyak orang (jika menggunakan pendekatan manual

atau semi-otomatis) dan kemudian memetakannya kedalam serangkaian tugas yang

mirip (tetapi tidak bener – benar identik) yang diimplementasikan dalam konteks

HCI.

Perekayasa harus lebih dahulu menetapkan dan mengklarifikasi tugas – tugas.

Salah satu pendekatan adalah elaborasi stepwise. Sebagai contoh, kita asumsikan

sebuah perusahaan perangkat lunak kecil perlu membangun sistem computer-aided

secara eksplisit untuk desainer interior.

Sekali tugas atau aksi yang ditentukan, maka desain interface dimulai. Langkah

pertama dalam proses desain interface [NOR86] dapat dilaksanakan dengan

menggunakan pendekatan berikut:

Page 11: Arsitektur desain data pada RPL

1. Tentukan tujuan untuk tugas itu.

2. Petakan masing – masing tujuan untuk serangkaian aksi khusus.

3. tentukan urusan aksi saat tindakan akan dieksekusi pada tingkat interface.

4. indikasi keadaan sistem

5. tentukan mekanisme kontrol.

6. perlihatkan bagaimana mekanisme kontrolmempengaruhi keadaan sistem.

7. indikasi bagaimana pemakai menginterpretasi keadaan sistem dari

informasi yang diberikan melalui interface.

1.11.3 MASALAH – MASALAH DESAIN

Pada saat interface pemakai berkembang, hampir muncul empat masalah desain

umum, yaitu: waktu respon sistem, fasilitas help pemakai, penanganan informasi

kesalahan, dan pelabelan perintah.

waktu respon sistem mempunyai dua karakteristik penting: panjang dan

variabilitas. Bila jarak (panjang) eaktu untuk respon sistem terlalu panjang, stres dan

frustasi pemakai akan menjadi hal yang dapat dihindari. Tetapi, waktu respon yang

sangat pendek juga dapat menggangu bila pemakai ditinggak interface.

Variabilitas mengacu pada penyimpangan terhadap waktu respon rata – rata, dan

dalam banyak hal variabilitas lebih penting dari karakteristik waktu respon.

Ada dua tipe fasilitas help yang berbeda: integrated dan add-on[RUB88].fasilitas

help integrated didesain kedalam perankat lunak sejak awal.peralatan itu sering

menjadi sensitif konteks, yang memungkinkan pemakai memilih topik – topik yang

relevan dengan kegiatan yang sedang dilakukan. Fasilitas help add-on ditambahkan

ke perangkat lunak seetelah sistem tersebut dibangun.dalam banyak hal fasilitas

tersebut benar – benar

Merupakan manual pemakai on-linebdengan kapabilitas query yang terbatas.

Pemakai mungkin harus mencari daftar yang berisi ratusan topik untuk mendapatkan

pedomn yang sesuai, sering membuat banyak kesalahan dan menerima informasi

yang tidak relevan.

Ada sejumlah masalah desain [RUB88] yang harus ditekankn bila fasilitas help

dipertimbangkan:

Page 12: Arsitektur desain data pada RPL

Apakah help akan dapat diperoleh untuk smua fungsi sistem dan pada

keseluruhan waktu selama interaksi sistem? Pilihan mencakup help hanya

untuk suatu sub-kumpulan dari semua fungsi dan aksi, dan help untuk

semua fungsi.

Bagaimana pemakai memperoleh help? Pilihan meliputi menu help, kunci

fungsi khusus, dan sebuah perintah help.

Bagaimana help akan direpresentasikan? Pilihan mencakup sebuah jendela

terpisah, reperensi untuk dokumen yang dicetak (kurang ideal), dan satu

atau dua baris usulan yng dibuat pada suatu lokasi layar yang tetap.

Bagaimana pemakai kembali keinteraksi normal?pilihan mencakup tombol

return yang ditanpilkan pada layar dan kunci fungsi atau urutan kontrol.

Bagaimana informasi help distruktur? Pilihan mencakup struktur “datar”

dimana semua informasi diakses melalui sesuatu kata kunci, hirarki

informasi bertingkat yang memberikn detail tambahan pada saat pemakai

melangkah kedalam struktur tersebut, dan kegunaan hiperteks.

Secara umum setiap pesan atau peringatan kesalahan yang dihasilkan oleh sebuah

sistem intraktif harus memiliki karakteristik sebagai berikut:

Pesan harus menggambarkan masaalah dalam istilah yang dapat dipahami

oleh pemakai.

Pesan harus memberinasehat intruktif untuk membetulkan kesalahan.

Pesan harus mengindikasikan kosekuensi negatif dari kesalahan.

Pesan harus disertai oleh isarat visual atau audibel.

Pesan harus tidak “menghakimi”, yaitu penyusunan kata tidak boleh

menyalahkan pemakai.

Ada sejumlah isu desain yang muncul pada saat perintah diberikan sebagai sebuah

mode interaksi:

Apakah setiap pilihan menu akan memiliki perintah yang sesuai?

Bagaimanakah bentuk yang akan diambil oleh perintah tersebut?

Seberapa sulitkah mempelajari dan mengimgat perintah – perintah tersebut?

Dapatkah dikostumasi atau disingkat oleh pemakai?

Page 13: Arsitektur desain data pada RPL

1.11.4 PERANTI IMPLEMENTASI

Proses desain interface pemakai adalah iteratif; yaitu, sebuah model desain

dibuat,diimplementasikan sebagai sebuah prototipe, diuji oleh pemakai dan

dimodifikasi berdasarkan pendapat mereka.

Dengan menggunakan perangkat lunak yang dikemas sebelumnya yang dapat

digunakan secara langsung oleh desainer dan implementor atau pemakai interface,

UIDS memberi mekanisme built-in [MYE89] untuk:

Mengatur perangkat input.

Memvalidasi input pemakai.

Menangani kesalahan dan menampilkan pesan kesalahan.

Memberi umpan balik.

Menyediakan help dan prompt.

Penanganan jendela dan field, scrolling pada jendela.

Membangun koneksi antara perangkat lunak aplikasi dan interface.

Mengisolasi aplikasi dari fungsi – fungsi managemen interface.

Memungkinkan pemakai mengkostumasi interface.

1.11.5 EVALUASI DESAIN

Sekali prototipe interface pemakai operasional diciptakan, maka prototipe itu

harus dievaluasi untuk menentukan apakah memenuhi kebutuhan pemakai.evaluasi

dapat memenuhi spektrum formalitas yang terentang dari “ test drive” informal

dimana seorang pemakai memberi umpan blik mendadak sampai study yang

dirancang secara formal yang menggunakan metode statistik untuk mengevaluasi

kuesioner yang dikerjakan oleh populasi pemakai akhir.

Bila sebuah model desain interface telah diciptakan, maka sejumlah kriteria

evaluasi [MOR81] dapat diaplikasikan selama kajian desain awal:

1. Panjang dan kompleksitas spesifikasi tertulis dari sistem dan interfacenya.

2. Jumlah perintah atau aksi yang ditentukan dan jumlah rata – rata argumen

per perintah atau per individual per aksi.

3. Jumlah aksi, perintah dan keadaan sistem yang diindikasikan oleh model

desain, menunjukkan beban memori pada pemakai sistem.

Page 14: Arsitektur desain data pada RPL

4. Gaya interface, fasilitas help, dan protokol penanganan kesalahan

memberikan suatu indikasi umum mengenai kompleksitas interface dan

tingkat dimana interface akan diterima oleh pemakai.

1.12 PEDOMAN DESAIN INTERFACE

Ada tiga kategori pedoman desain HCI: interaksi umum, tampilan informasi, dan

entry data.

1.12.1 INTERAKSI UMUM

Pedoman bagi interaksi umum sering melewati batasan kedalam tampilan

informasi, entridata, dan kontrol sistem keseluruhan. Dengan demikian pedoman itu

mencakup keseluruhan dan bila diabaikan akan menimbulkan resiko besar. Pedoman

berikut berfokus pada interaksi umum:

Konsisten

Berikan umpan balik yang sangat berarti

Mintalah verifikasi terhadap sembarang aksi destrutif yang signifikan

Ijin kemudahan pembatalan sebagian besar aksi

Kurangi jumlah informasi yang harus diingat diantara aksi – aksi

Usahakan adanya efisiensi dalam dialog, gerakan, dan pemikiran

Memaafkan kesalahan

Kategorikan aktifitas menurut fungsi dan atur geografi layar secar sesuai

Sediakan fasilitas help dan sensitif konteks

Gunakan verbal aksi yang sederhana atau frase verbal pendek untuk

menamai perintah

1.12.2 TAMPILAN INFORMASI

Bila informasi yang disajikan oleh HCI tidak lengkap, ambigu, atau tidak dapat

dimengerti, makaapliksi tersebut akan gagal memenuhi kebutuhan pemakai. Infomsi

“ditampilkan” dalam banyak cara yang berbeda: dengan teks, gambar dan suara;

dengan penempatan, gerakan dan ukuran; dan dengan menggunakan warna, resolusi,

dan bahkan penghilangan.pedoman berikut berfokus pada tampilan informasi:

Page 15: Arsitektur desain data pada RPL

Menampilkan hanya informasi yang relevan dengan konteks yang ada

Jangan membanjiri pemakai dengan data, gunakn format representasi yang

memungkinkan asimilasi informasi yang cepat.

Gunakan label – label yang konsisten, penyingkatan standar, dan warna

yang dapat diprediksi

Ijinkan pemakai untuk memelihara konteks visual

Hasilkan pesan kesalahan yang berarti

Gunakan huruf besar dan kecil, indentasi, dan pengelompokkan teks untuk

membantu pemahaman.

Gunakan jendela untuk menggolongkan tipe – tipe informasi yang berbeda

Gunakan tampilan analog untuk mempresentasikan informasi yang lebih

mudah diasimilasikan dengan bentuk representasi ini

Pertimbangkan ketersediaan geografi layar tampilan dan gunakan secara

efisien

1.12.3 INPUT DATA

Dalam banyak aplikasi, keybord menjadi medium input yang utama, tetapi mouse,

digitizer, dan bahkan sistem pengenaln suara secara cepat menjadi alternatif yang

efektif. Pedoman – pedoman berikut berfokus pada input data:

Minimalkan jumlah aksi input pyang dibutuhkan dari pemakai.

Jagalah konsistensi diantara tampilan informasi dan input data

Ijinkan pemakai mengkostumasi input

Interaksi harus fleksibel tetapi juga diatur kemode input yang disukai

pemakai

Non aktifkan perintah yang tidak sesuai didalam konteks aksi yang sedang

berlangsung

Biarkan pemakai mengontrol aliran interaktif

Silakan help untuk membantu semua aksi input

Hilangkan input “mickey mouse”

Page 16: Arsitektur desain data pada RPL