Interaksi Manusia dan Komputer Proses Desain Rahma Dwi

Interaksi Manusia dan Komputer (Proses Desain) Rahma Dwi Wahyuni, S. Kom

Siklus Hidup Perangkat Lunak � Model air terjun (waterfall) Requirements Specification Architectural Design Detail Design Coding and Testing Integration and Testing Operation and Maintenance

Aktifitas Dalam Siklus Hidup � Spesifikasi Kebutuhan v Desainer dan pengguna (customer) mencoba untuk menangkap apa yang di harapkan pada suatu sistem untuk ada/tersedia v Dapat dinyatakan dalam bahasa alami/sehari-hari atau bahasa yang labih presisi seperti halnya analisis tugas yang akan di sediakan � Desain Arsitektur v Deskripsi tingkat tinggi tentang bagaimana suatu sistem akan menyediakan pelayanan yang dibutuhkan v Memilah sistem kedalam komponen-komponen utama sistem dan bagaimana mereka saling berhubungan v Perlu untuk memenuhi baik kebutuhan fungsional maupun yang non fungsional � Desain Detail v Penghalusan komponen-komponen arsitektur dan hubungannya untuk mengidentifikasi modul-modul yang akan diimplementasikan secara terpisah v Penghalusan ditentukan oleh kebutuhan-kebutuhan non fungsional

� Pengkodean dan Test Unit v Implementasi dan Pengetesan modul-modul individu dalam suatu bahasa pemrograman yang dapat dieksekusi � Integrasi dan Pengetesan v Mengkombinasikan modul-modul untuk menghasilkan komponen dari deskripsi arsitektur � Operasi dan Pemeliharaan v Produk diantarkan kepada pengguna (customer) dan semua masalah / perbaikan disediakan oleh desainer saat produk tersebut masih dipakai v Bagian terbesar dari siklus hidup

Verifikasi dan Vasilidasi � Verifikasi v Pendesainan produk secara benar � Validasi v Pendesainan produk yang benar � Jurang formalitas v Validasi akan selalu bergantung pada beberapa perluasan arti subjektif dari bukti yang ada � Manajemen dan Masalah Kontrak v Desain dalam konteks komersial dan legal

Siklus Hidup Untuk Sistem Interaktif � Tidak dapat mengasumsikan suatu urutan aktifitas linier sederhana seperti diasumsikan pada model air terjun

Menggunakan Aturan Desain � Aturan desain menyarankan bagaimana meningkatkan tingkat kegunaan

� Standar v Diatur oleh organisasi nasional atau internasional untuk memastikan kepastian pemenuhan syarat-syarat tertentu oleh komunitas bear para desainer v Standar memerlukan teori mendasar dan secara pelan mengubah teknologi v Standar perangkat keras lebih umum digunakan dibandingkan dengan standar perangkat lunak v Otoritas tinggi dan level rendah detil v ISO 9241 mendefinisikan tingkat kegunaan sebagi keefektifan, efisiensi dan kepuasan dengan mana pengguna menyelesaikan suatu tugas

� Garis Pedoman (guidelines) v Lebih bersifat saran dan umum v Banyak buku teks dan laporan penuh berisikan garis pedoman v Abstrak dari garis pedoman (prinsip) dapat digunakan selama aktifitas awal siklus hidup v Garis pedoman detil (petunjuk gaya – style guides) dapat digunakan selama aktifitas siklus hidup lebih lanjut v Pemahaman pembeneran untuk garis pedoman ini akan membantu dalam hal penyelesaian konflik yang terjadi

Rekayasa Tingkat Kegunaan � � Tes akhir tingkat kegunaan berdasarkan pada pengukuran pengalaman pengguna Rekayasa tingkat kegunaan meminta pengukuran tingkat kegunaan spesifik harus dibuat secara eksplisit/jelas sebagai suatu kebutuhan � Spesifikasi tingkat kegunaan : v Atribut / prinsip tingkat kegunaan v Konsep pengukuran v Metode pengukuran v Level kekinian/kasus terburuk/level perencanaan/kasus terbaik � Permasalahan Spesifikasi tingkat kegunaan membutuhkan level detil yang mungkin tidak bisa didapat di awal desain Pemenuhan spesifikasi tingkat kegunaan tidak berarti harus memenuhi tingkat kegunaan itu sendiri v v

Desain Berulang dan Prototype � � � Desain berulang (iteratif) mengatasi permasalahn yang melekat pada kebutuhan yang tidak lengkap Prototipe v Simulasi atau animasi dari beberapa fitur dari bakal sistem v Berbagai jenis prototipe Ø Throw-away (sekali pakai, buang) Ø Incrementasi (bertingkat) Ø Evolutionary (evolusi) Masalah Manajemen v Waktu v Perencanaan v Fitur non – fungsional v kontrak

Teknik Prototipe � Storyboard (papan cerita) v Tidak perlu harus berbasis komputer v Dapat dianimasikan � Simulasi fungsional terbatas v Beberapa bagian dari fungsionalitas sistem disediakan oleh desainer v Perkakas seperti Hyper. Card banyak dijumpai sekarang ini v Teknik dari Wizard of Oz � Peringatan mengenai desain berulang v Kelembaman desain – keputusan yang mulanya buruk akan tetap jadi buruk v Pendiagnosisan permasalahan derajat kegunaan nyata dalam prototipe dan bukan hanya sekedar gejala-gejalanya

Dasar Pemikiran Desain � Dasar pemikiran desain adalah informasi yang menjelaskan mengapa suatu sistem komputer seperti itu adanya � Keuntungan – keuntungan dari dasar pemikiran desain v Komunikasi melalui siklus hidup v Penggunaan kembali pengetahuan desain melintasi produk-produk v Pelaksanaan disiplin desain v Mempresentasikan argumen untuk nilai yang harus dibayar untuk desain v Mengorganisasikan ruang besar desain potensial � Orientasi Proses v Menjaga urutan pertimbangan dan pembuatan keputusan � Orientasi Struktur v Penekanan pada struktur post hoc alternatif desain yang dipertimbangkan

Teknik-teknik Dasar Pemikiran Desain � Sistem informasi Berbasis Isu (Issue-based Information System - IBIS) v Dasar dari banyak riset dasar pemikiran desain v Berorientasi proses v Struktur hirarki dari isu-isu, dengan satu akar isu v Posisi adalah pemecahan potensial dari suatu isu v Argumen memodifikasi hubungan diantara posisi da n isu v g. IBIS adalah versi grafik dari IBIS � Analisis Ruang desain v Berorientasi struktur v QOC – stuktur hirarki Ø Pertanyaan (dan sub-pertanyaan) merepresentasikan isu utama dari suatu desain Ø Berbagai opsi menyediakan solusi alternatif pada petanyaanpertanyaan Ø Kriteria adalah makaud/arti dari penaksiran berbagai variasi opsi dalam rangka membuat suatu pilihan v DRL – serupa dengan QOC dengan bahasa yang lebih besar dan semantik yang lebih formal

� Dasar Pemikiran Desain Secara Psikologis v Untuk mendukung daur tugas-artefak dalam mana tugas pengguna dipengaruhi oleh sistem yang mereka gunakan v Bertujuan untuk membuat konsekuensi eksplisit dari desain untuk pengguna v Desainer mengidentifikasi tugas-tugas, sistem akan mendukung v Skenario disarankan untuk mengetes tugas v Pengguna diobservasi pada sistem v Klaim psikologis sistem dibuat secara eksplisit v Aspek negatif desain dapat digunakan untuk meningkatkan iterasi desain selanjutnya