BAB 18-Pengembangan dan Implementasi Perangkat Lunak

Testing Conventional Applications

What is a “Good” Test?

·         Sebuah tes yang baik memiliki probabilitas tinggi untuk menemukan kesalahan

·         Sebuah tes yang baik adalah tidak berlebihan.

·         Sebuah tes yang baik harus "best of breed“

·         Sebuah tes yang baik harus tidak terlalu sederhana atau terlalu kompleks

Internal and External Views

Semua Produk dapat di tes dengan 2 cara :

·         Mengetahui Fungsi Produk sesuai dengan apa kegunaan produk pada saat dibuat.

·         Mengetahui cara kerja internal suatu produk, tes dapat dilakukan untuk memastikan bahwa apakah ada error atau tidak

Deriving Test Cases

·         Menggunakan desain atau kode sebagai dasar, menggambar grafik aliran yang sesuai.

·         Menenentukan kompleksitas siklomatik dari grafik aliran yang dihasilkan.

·         Menentukan basis set jalur linear independen.

·         Menyiapkan kasus uji yang akan memaksa pelaksanaan setiap jalur di basis set.

Graph-Based Methods

·         Untuk memahami objek yang dimodelkan dalam perangkat lunak dan hubungan yang menghubungkan obyek

Perbandingan dalam Pengujian

·         Digunakan hanya pada saat reliabilitas software tersebut benar-benar penting. (contoh : Human-rated settings)

Perbandingan dalam Pengujian

·         Digunakan hanya pada saat reliabilitas software tersebut benar-benar penting. (contoh : Human-rated settings)

Orthogonal Array Testing

·         Digunakan ketika jumlah parameter input kecil dan nilai-nilai masing-masing parameter yang dapat diambil jelas dibatasi

Model-Based Testing

·         Menganalisis model perilaku yang ada untuk perangkat lunak

·         Menentukan input yang akan memaksa perangkat lunak untuk melakukan transisi

·         Mereview perilaku model dan mencatat outputnya

·         Menjalankan tes

Membandingkan hasil aktual dan yang diharapkan dan mengambil tindakan korektif yang diperlukan 

BAB 17-Pengembangan da Implementasi Perangkat Lunak

Strategi Pengujian Perangkat Lunak
“Pendekatan Strategis dalam Pengujian Perangkat Lunak”

Gambaran Umum

·         Strategi pengujian perangkat lunak menyediakan petunjuk yang menjelaskan langkah-langkah yang harus dilakukan sebagai bagian dari pengujian

·         Perangkat lunak diuji untuk menentukan kesalahan yang dibuat secara tidak sengaja saat perangkat lunak tersebut dirancang dan dibangun

·         Pengujian adalah serangkaian kegiatan yang direncanakan dan dilakukan secara sistematis. Untuk alasan ini, pola baku atau template untuk pengujian perangkat lunak sebaiknya di definisikan dalam proses  perangkat lunak

Pendekatan Strategis dalam Pengujian Perangkat Lunak

·         Untuk melakukan pengujian yang efektif, anda harus melakukan tinjauan teknis yang efektif

·         Pengujian dimulai pada tingkat komponen dan bekerja ke arah luar menuju integrasi sistem berbasis komputer secara keseluruhan

·         Teknik pengujian yang berbeda tepat untuk pendekatn rekayasawan perangkat lunak yang berbeda pula dan pada waktu yang berbeda

·         Pengujian dilakukan oleh pengembang perangkat lunak daro kelompok penguji independen

·         Pengujian dan debugging adalah aktifitas yang berbeda, namun debugging harus terakomodasi dalam setiap strategi pengujian

Verifikasi dan Validasi

·         Verifikasi merunjuk pada sekumpulan tugas yang memastikan bahwa perangkat lunak benar menerapkan fungsi yang ditentukan

·         Validasi merujuk ke sekumpulan tugas yang berbeda yang memastikan bahwa perangkat lunak yang telah dibangun dapat dilacak berdasarkan persyaratan pelanggan

·         Meliputi beragam kegiatan SQA (Kegiatan Jaminan Kualitas Perangkat Lunak)

Kegiatan Jaminan Kualitas Perangkat Lunak

Melakukan Pengujian Perangkat Lunak

·         Para pengembang perangkat lunak selalu bertanggung jawab untuk menguji masing-masing komponen dari program yang dikembangkannya dan memastikan bahwa setiap komponen melakukan fungsi seperti apa yang telah dirancang

·         ITG (Independent Test Group) berperan untuk menghapus masalah yang melekat sehubungan dengan membiarkan pembangun menguji apa yang telah dibangunnya dan menghilangkan konflik kepentingan

·         Pengembang dan ITG harus dapat bekerja sama di seluruh proyek perangkat lunak untuk memastikan bahwa pengujian bersifat menyeluruh

·         ITG terlibat selama analisis dan perancangan serta tetap terlibat pada keseluruhan proyek

Strategi Pengujian Perangkat Lunak

Langkah-langkah Pengujian Perangkat Lunak

Kriteria untuk Penyempurnaan Pengujian

·         Kapan selesai melakukan pengujian ?

·         Bagaimana kita tahu bahwa kita telah cukup melakukannya ?

·         “Anda tidak akan pernah selesai melakukan pengujian; beban ini haya bergeser dari rekayasawan perangkat lunak kepada pengguna akhir”

Pendekatan Cleanroom Software Engineering menyarankan penggunaan teknik statistik yang melakukan serangkaian pengujian yang berasal dari sampel statistik dari semua program yang dieksekusi oleh pengguna dari suatu populasi yang ditargetkan. 

BAB 16-Pengembangan dan Implementasi Perangkat Lunak

Pekerjaan, Sasaran dan Metrik SQA

Pekerjaan SQA

• ·         Tugas dari kelompok SQA pada dasarnya adalah untuk membantu tim perangkat lunak dalam menghasilkan produk berkualitas tinggi
• ·         Mempersiapkan suatu rencana SQA untuk proyek
• ·         Berpartisipasi dalam pengembangan deskripsi proses perangkat lunak yang dilaksanakan proyek
• ·         Menuju aktivitas-aktivitas rekayasa perangkat lunak untuk memverifikasi kesesuaiannya dengan proses perangkat lunak yang telah didefinisikan sebelumnya
• ·         Memastikan bahwa penyimpangan pada pekerjaan perangkat lunak dan produk-produk kerja telah terdokumentasi dengan baik dan telah ditangani dengan cara yang sesuai
• ·         Mencatat setiap ketidaksesuaian dan melaporkannya kepada manajemen puncak
• ·         Kualitas kebutuhan
• ·         Kualitas perancangan
• ·         Kualitas kode
• ·         Efektivitas kendali kualitas 

BAB 15-Pengembangan dan Implementasi Perangkat Lunak

Teknik Peninjauan

Tinjauan Teknis yang Bersifat Formal (Formal Technical Review (FTR))

·         Suatu aktifitas kendali kualitas yang dilakukan oleh rekayasawan-rekayasawan perangkat lunak

·         Sasaran FTR :

1.       Untuk menyingkap kesalahan-kesalahan dalam fungsi, logika atau dalam implementasi perangkat lunak

2.       Untuk melakukan verifikasi apakah perangkat lunak yang ditinjau sudah sesuai dengan spesifikasi kebutuhan yang telah ditentukan

3.       Untuk memastikan bahwa perangkat lunak telah direpresentasikan dengan cara yang sesuai dengan standar yang telah ditentukan

4.       Membuat proyek perangkat lunak yang lebih mudah untuk dikelola

5.       Dasar untuk rekayasawan perangkat lunak yang belum berpengalaman untuk melakukan observasi

Pertemuan – Pertemuan Peninjauan

Batasan Peninjauan Produk Kerja :

·         Suatu tinjauan teknik seharusnyaa melibatkan 3 hingga 5 orang (yang paling umum)

·         Masing-masing orang sebaiknya tidak menghabiskan waktu lebih dari 2 ja kerja untuk melakukan peninjauan

·         Lamanya waktu pertemuan peninjauan teknis sebaiknya kurang dari 2 jam saja

Pada akhir peninjauan produk perangkat lunak, semua orang yang terlibat dalam FTR harus memutuskan apakah :

1.       Menerima produk tanpa perlu melakukan modifikasi lebih lanjut

2.       Menolak produk karena kesalahan-kesalahan fatal yang ada dalam produk

3.       Menerima produk secara sebagian (kesalahan-kesalahan minor, tetapi tidak memerlukan tinjauan lebih lanjut)

Pelaporan Hasil Peninjauan dan Pemeliharaan Catatan Hasil Peninjauan

Suatu laporan kesimpulan peninjauan produk kerja perangkat lunak pada dasarnya menjawab 3 pertanyaan berikut :

1.       Apa yang ditinjau ?

2.       Siapa yang melakukan peninjauan ?

3.       Permasalahan-permasalahan apa yang ditemukan dan bagaimana cara-cara untuk mengatasinya ?

Laporan peninjauan perangkat lunak seringkali berupa form satu halaman dan dapat disebarkan ke elemen yang terkait dalam satu perusahaan

Panduan – panduan Peninjauan

1.       Lakukan peninjauan pada produk perangkat lunak, bukan pada yang menghasilkannya.

2.       Mengatur agenda

3.       Batasi debat-debat dan ketidaksetujuan-letidaksetujuan karena hanya akan menghabiskan waktu

4.       Perjelas area permasalahan

5.       Lakukan pencatatan

6.       Batasi jumlah peserta pertemuan dan lakukan persiapan yang memadai

7.       Kembangkan daftar tinjauan untuk masing-masing produk perangkat lunak

8.       Lakukan alokasi sumber daya dan jadwal waktu untuk FTR

9.       Lakukan pelatihan yang bermanfaat pada semua peninjau.

10.   Lakukan peninjauan atas peninjauan-peninjauan sebelumnya

Peninjauan yang Dikendalikan oleh Contoh

Thelin menyarankan proses ini, dimana semua produk perangkat lunak dinspeksi untuk dapat menentukan produk-produk kerja mana saja yang paling mungkin mengandung kesalahan di dalamnya. Langkah –langkah di bawah ini dapat digunakan :

1.       Lakukan inspeksi untuk mendapatkan nilai pembagi (ai) untuk setiap produk kerja perangkat lunak. Catat jumlah kesalahan (fi) yang ditemukan

2.       Kembangkan prakiraan kasar untuk jumlah kesalahan di dalam produk kerja dengan melakukan perkalian fi dengan 1/ai.

3.       Urutkan produk-produk kerja secara descending mengikuti perkiraan kasar jumlah kesalahan yang akan ditemukan di dalam masing-masing produk kerja perangkat lunak yang akan ditinjau

Fokuskan sumber daya peninjauan yang tersedia pada produk-produk kerja yang memiliki kemungkinan jumlah kesalahan yang besar di dalamnya

BAB 14-Pengembangan dan Implementasi Perangkat Lunak

Konsep-konsep Kualitas

Apa itu Kualitas?

·         Kualitas perangkat lunak adalah dimana perancangan memenuhi fungsi dan fitur yang dispesifikasi melalui model kebutuhan.

·         Kualitas kesesuaian berfokus pada implementasi perancangan dan menghasilkan perangkat lunak yang sesuai dengan sasaran.

·         Kualitas produk merupakan fungsi dari seberapa besar pengaruh produk tersebut terhadap pangsa pasar.

·         Kepuasan Pelanggan = Produk yang sesuai + Kualitas bagus + diserahkan sesuai anggaran dan jadwal

Kualitas Perangkat Lunak

1.       Proses perangkat lunak efektif

Menetapkan infrastruktur  yang mendukung setiap usaha untuk mengembangkan produk PL yang berkualitas tinggi

2.       Produk yang bermanfaat

Didalamnya terdapat fungsi, isi , fitur yang diinginkan oleh pengguna akhir

3.       Penambahan nilai pada produsen maupun pengguna

·         Hasil akhirnya adalah:

1.  Keuntungan produk perangkat lunak yang lebih besar .

2. Tingkat keuntungan produk perangkat lunak yang lebih baik

3.Memperbaiki ketersediaan informasi yang penting bagi bisnis

Matra Kualitas menurut Garvin

·         Kualitas Kinerja

Apakah PL didalamnya memiliki semua isi, fungsi, fitur yang dispesifikasi sebagai bagian dari model kebutuhan dengan cara memberi nilai akhir kepada pengguna?

·         Kualitas Fitur

Menyediakan fitur yang mengejutkan bagi para pengguna akhir saat pertama kali digunakan?

·         Keandalan

Apakah PL didalamnya memiliki semua fitur dan kemampuan tampa kegagalan?

·         Kesesuaian

Apakah PL yang dikembangkan telah sesuai dengan standar PL yang bersifat lokal  serta standar PL eksternal yang relevan?

·         Durabilitas

Dapatkah perangkat lunak diubah atau dikoreksi tanpa menimbulkan imbas yang tidak diinginkan?

·         Kemampuan untuk melakukan layanan

Dapatkah perangkat lunak diubah atau doperbaiki dalam jangka waktu pendek?

·         Estetika

·         Persepsi

Tiga Aspek Penting dari Produk Perangkat Lunak :

·         1. Karakteristik Operational

·         2. Kemampuan untuk segera berubah

·         3. Kemampuan untuk beradaptasi terhadap lingkungan yang baru

Faktor kualitas menurut McCail

·         Kebenaran : Bagaimana program memberikan hasil sesuai dengan spesifikasi

·         Keandalan : Bagaimana program dapat melakukan fungsi tertentu sesuai dengan tingkat ketelitian yang diinginkan

·         Efisiensi : Jumlah sumber daya komputasi dan kode yang diperlukan progran

·         Intregritas : Bagaimana akses ke perangkat lunak

·         Penggunaan : Besarnya usaha yang dperlukan untuk mengoperasikan input dan menafsirkan output

·         Maintainability : Besarnya usaha untuk melokalisasi kesalahan dalam program

·         Fleksibilitas : Usaha untuk memodifikasi program yang berifat operasional

·         Testability : Usaha untu melakukan pengujian program

·         Portability : Usaha untuk mentrasfer program dari perangkat keras

·         Reusability : Program dapat digunakan ulang diaplikasi lainnya

·         Interoperabilitas : Usaha untuk menggantikan bagian suatu sistem dengan bagian sistem lainnya

Faktor Kualitas menurut ISO 9126

·         Fungsionlitas : Bagaiman perangkat lunak memenuhi kebutuhan yang telah ditetapkan sebelumnya

·         Keandalan : Jumlah waktu penggunaan perangkat lunak

·         Kemudahan penggunaan

·         Efisiensi

·         Kemudahan pemeliharaan : Bagaiman perbaikan yang mungkin dilakukan pada perangkat lunak

·         Portabilitas : Kemudahan bagaimana perangkat lunak dapat dipindahkan dari lingkungan operasional ke lingkungan lainnya

Faktor Kualitas yang menjadi target

·         Intuitif : Derajat bagaimana antarmuka pengguna mengikuti pola penggunaan yang diharapkan.

·         Efisiensi : Derajat bagaimana operasi dan informasi dapat ditemukan dan dilaksankan

·         Ketangguhan : Kemampuan perangkat lunak untuk menangani input data yang buruk

·         Kekayaan : Derajat bagaimana antarmuka pengguna menyediakan sejumlah fitur yang kaya 

BAB 12-Pengembangan dan Implementasi Perangkat Lunak

Taktik Pengujian

Dasar – dasar Pengujian Perangkat Lunak

·         Tujuan pengujian : menemukan kesalahan

·         Pengujian yang baik adalah pengujian yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya.

·         Testabilitas perangkat lunak 

Seberapa mudah sebuah program komputer dapat diuji.

·         Karakteristik perangkat lunak yang dapat diuji :

ü  Operabillity

ü   Observability

ü   Controlability

ü   Decomposability

ü   Simplicity

ü   Stability

ü   Understandability

·         Karakteristik Pengujian

ü  Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.

ü  Pengujian yang baik tidak redundan.

ü  Pengujian yang baik seharusnya “jenis terbaik”.

ü  Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks.

Pengujian White Box dan Black Box

·         Setiap produk rekayasa dapat diuji melalui satu atau dua cara, yaitu:

1.       Dengan mengetahui kerja internal dari suatu produk, maka pengujian dapat dilakukan untuk memastikan bahwa operasi internal bekerja sesuai dengan spesifikasi dan semua komponen internal telah diamati dengan baik. Pendekatan pengujian ini disebut pengujian white-box.

2.       Mengetahui fungsi spesifik dari suatu produk yang ditentukan dimana produk dirancang untuk melakukannya. Pendekatan pengujian ini disebut pengujian black-box.

·         Konsep desain test case yang menggunakan struktur control yang digambarkan sebagai bagian dari desain komponen-level untuk mendapatkan test case.

·         Didasarkan pada pengamatan yang teliti terhadap detail prosedural.

·         Test Case yang dihasilkan :

1.       Menjamin bahwa semua jalur kecil yang independen di dalam modul telah dijalankan paling tidak satu kali.

2.       Menjalankan semua keputusan logic berdasarkan true dan false.

3.       Mengeksekusi semua loop pada batasannya dan dalam batas operasional.

4.       Menjalankan struktur data internal untuk meyakinkan validitasnya.

Pengujian Basis Path

·         Teknik pengujian white-box yang pertama kali diusulkan oleh Tom McCabe

·         Memungkinkan perancang test case untuk mendapatkan penghitungan logika yang kompleks dari suatu desain procedural dan menggunakan penghitungan ini sebagai pedoman untuk menetapkan basis set dari jalur eksekusi.

·         Test case didapatkan untuk menguji apakah basis set dapat menjalankan setiap perintah pada program paling tidak satu kali selama pengujian

·         Catatan Diagram Alir

Diagram alir harus digambar hanya ketika struktur logika dari suatu komponen sangat kompleks.

·        

·        

·         Flowgraph

·         Jalur Independen

ü  Jalur yang melalui program yang mengintroduksi sedikitnya satu rangkaian statemen proses baru atau suatu kondisi baru.

ü  Bila dinyatakan dengan terminologi grafik alir, jalur independen harus bergerak sepanjang paling tidak satu edge yang tidak dilewatkan sebelum jalur tersebut ditentukan.

ü  Kompleksitas siklomatis adalah matriks perangkat lunak yang memberikan pengukuran kuantitatif terhadap kompleksitas logis suatu program.

ü  Nilai yang terhitung untuk kompleksitas siklomatis menentukan jumlah jalur independen dalam basis set suatu program dan memberi batas atas bagi jumlah pengujian yang harus dilakukan untuk memastikan bahwa semua statemen telah dieksekusi sedikitnya satu kali.

·         Langkah untuk mendapatkan basis set:

1.       Menggunakan desain atau code sebagai dasar, menggambar flow graph yang sesuai

2.       Menentukan kompleksitas siklomatis dari flow graph resultan

3.       Menentukan basis set dari jalur independen secara linier

4.       Menyiapkan test case yang akan memaksa adanya eksekusi dari setiap path pada basis set

·         Matriks Grafik :

ü  Merupakan matriks persegi yg ukurannya sama dg jumlah node pd flow graph

ü  Setiap baris&kolom sesuai dg node

ü  Anggota matriks sesuai dg koneksi antar node

·         Jenis kesalahan pada suatu kondisi meliputi :

ü  Kesalahan operator boolean(ada operator boolean yang salah, hilang,atau kelebihan)

ü  Kesalahan variabel boolean

ü  Kesalahan paranthesis

ü  Kesalahan operator relsional

ü  Kesalahan persamaan aritmetika

·         Pengujian Loop

Pengujian loop merupakan teknik pengujian white-box yang secara exclusive berfokus pada validitas konstruksi loop.

Macam-macamnya :

1.       Simple loop

2.       Nested Loop

3.       Concantenated  loop

4.       Unstrustured loop

BAB 11-Pengembangan dan Implementasi Perangkat Lunak

User interface design

Definisi User Interface Design

·         Suatu bentuk komunikasi antara penguna (user) dengan komputer. Bagaimana pengguna berinteraksi dengan komputer dengan menggunakan tampilan antar muka yang ada di layar komputer.

Tujuan dari User Interface Design

·         Merancang interface yang efektif untuk sistem perangkat lunak.

·         Kebutuhan disini adalah kebutuhan penggunanya.Pengguna sering menilai sistem dari interface, bukan dari fungsinya melainkan dari user interfacenya. Jika desain user interfacenya yang buruk, maka itu sering jadi alasan untuk tidak menggunakan software.

·         interface yang buruk menyebabkan pengguna membuat kesalahan fatal.

Prinsip-prinsip UID

·         User familiarity

Menggunakan istilah, konsep dan kebiasaan user bukan computer (misal: sistem perkantoran gunakan istilah letters, documents, folders bukan directories, file, identifiers. -- jenis document open office

·          Consistency

Konsisten dalam operasi dan istilah di seluruh sistem sehingga tidak membingungkan. -- layout menu di open office mirip dgn layout menu di MS office.

·          Minimal surprise

Operasi bisa diduga prosesnya berdasarkan perintah yang disediakan.

·          Recoverability

Recoverability ada dua macam: Confirmation of destructive action (konfirmasi terhadap aksi yang merusak) dan ketersediaan fasilitas pembatalan (undo)

·          User guidance

 Sistem manual online, menu help, caption pada icon khusus tersedia

·          User diversity

Fasilitas interaksi untuk tipe user yang berbeda disediakan. Misalnya ukuran huruf bisa diperbesar

Graphical User Interface (GUI)

·         Gampang dipelajari oleh pengguna yang pengalaman dalam menggunakan komputer cukup minim

·         Berpindah dari satu layar ke layar yang lain tanpa kehilangan informasi

·         Dimungkinkan akses penuh pada layar dengan segera untuk beberapa macam tugas/keperluan

Karakteristik GUI

User Centered Design

·         Konsep dari UCD adalah user sebagai pusat dari proses pengembangan sistem, dan tujuan/sifat-sifat, konteks dan lingkungan sistem semua didasarkan dari pengalaman pengguna.

·         Desain harus bersifat user-centered, artinya pengguna sangat terlibat dalam proses desain. Karena itu ada proses evaluasi yang dilakukan oleh pengguna terhadap hasil desain.

Proses Merancang User Interface

Menggambarkan proses yang dilakukan dalam melakukan desain user interface. Proses perulangan yang terjadi menjelaskan bahwa proses-proses tersebut dilakukan hingga menghasilkan desain yang diinginkan oleh pengguna.

User Interaction

·         Perancang sistem menghadapi dua masalah penting yaitu:

1. Bagaimana informasi dari user bisa disediakan untuk sistem komputer – misalnya pada saat input data

 2. Bagaimana informasi dari sistem komputer ditampilkan untuk user – hasil dari pemrosesan data

5 tipe utama interaksi untuk user interaction

1.       Direct manipulation

Pengoperasian secara langsung: interaksi langsung dengan objek pada layar. Misalnya delete file dengan memasukkannya ke trash. Contoh: Video games.

·          Kelebihan: Waktu pembelajaran user sangat singkat, feedback langsung diberikan pada tiap aksi sehingga kesalahan terdeteksi dan diperbaiki dengan cepat

·          Kekurangan : Interface tipe ini rumit dan memerlukan banyak fasilitas pada sistem komputer

2.       Menu selection

Pilihan berbentuk menu: Memilih perintah dari daftar yang disediakan. Misalnya saat click kanan dan memilih aksi yang dikehendaki.

·         Kelebihan : User tidak perlu ingat nama perintah. Pengetikan minimal. Kesalahan rendah.

·          Kekurangan :Tidak ada logika AND atau OR. Perlu ada struktur menu jika banyak pilihan.

3.       Form fill-in

 Mengisi area-area pada form. Contoh: Stock control.

·         Kelebihan : Masukan data yang sederhana. Mudah dipelajari

·         Kekurangan : Memerlukan banyak tempat di layar. Harus menyesuaikan dengan form manual dan kebiasaan user.

4.        Command language

Menuliskan perintah yang sudah ditentukan pada program. Contoh: operating system

·         Kelebihan : Perintah diketikan langsung pada system. Misal UNIX, DOS command. Kombinasi perintah bisa dilakukan. Misal copy file dan rename nama file.

·         Kekurangan:Perintah harus dipelajari dan diingat cara penggunaannya tidak cocok untuk user biasa.

5.        Natural language

Perintah dengan bahasa alami: Gunakan bahasa alami untuk mendapatkan hasil. Contoh: search engine di Internet.

·         Kelebihan: Perintah dalam bentuk bahasa alami, dengan kosa kata yang terbatas (singkat) – misalnya kata kunci yang kita tentukan untuk dicari oleh search engine. Ada kebebasan menggunakan kata-kata.

·         Kekurangan: Tidak semua sistem cocok gunakan ini. Jika digunakan maka akan memerlukan banyak pengetikan.

User Support

·         User guidance meliputi semua fasilitas sistem untuk mendukung user termasuk on-line help, error messages, user manual.

·         User guidance perlu disatukan dengan UI untuk bantu user saat membutuhkan informasi tentang sistem atau saat ada kesalahan.

·         Help System dan sistem message (pesan kesalahan) adalah bentuk dari user guidance.

·         Error Messages sangat penting, karena error message yang buruk cenderung ditolak oleh user dan error message sebaiknya berpedoman pada faktor-faktor pada Tabel dibawah ini.

Faktor dalam Desain Error Message

Error Message dengan orientasi yang berbeda

Penjelasan

·        Pada pesan yang berorientasi pada sistem, pesan membuat pengguna merasa tidak berdaya karena tidak ada jalan keluar yang jelas, bahasa yang digunakan adalah bahasa teknis yang tidak berarti apa-apa.

·         Pada pesan yang berorientasi pada pengguna, pesan lebih jelas dan memberikan alternatif jalan keluar. Sekalipun informasi yang diberikan lebih banyak dan terkesan penuh, tapi pengguna merasa tertolong.