Interaksi Manusia dan Komputer (Proses Desain)

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

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

Verifikasi dan Vasilidasi • Verifikasi • Pendesainan produk secara benar • Validasi • Pendesainan produk yang benar • Jurang formalitas • Validasi akan selalu bergantung pada beberapa perluasan arti subjektif dari bukti yang ada • Manajemen dan Masalah Kontrak • 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 • Diatur oleh organisasi nasional atau internasional untuk memastikan kepastian pemenuhan syarat-syarat tertentu oleh komunitas bear para desainer • Standar memerlukan teori mendasar dan secara pelan mengubah teknologi • Standar perangkat keras lebih umum digunakan dibandingkan dengan standar perangkat lunak • Otoritas tinggi dan level rendah detil • ISO 9241 mendefinisikan tingkat kegunaan sebagi keefektifan, efisiensi dan kepuasan dengan mana pengguna menyelesaikan suatu tugas

Garis Pedoman (guidelines) • Lebih bersifat saran dan umum • Banyak buku teks dan laporan penuh berisikan garis pedoman • Abstrak dari garis pedoman (prinsip) dapat digunakan selama aktifitas awal siklus hidup • Garis pedoman detil (petunjuk gaya – style guides) dapat digunakan selama aktifitas siklus hidup lebih lanjut • 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 : • Atribut / prinsip tingkat kegunaan • Konsep pengukuran • Metode pengukuran • 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

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

Teknik Prototipe • Storyboard (papan cerita) • Tidak perlu harus berbasis komputer • Dapat dianimasikan • Simulasi fungsional terbatas • Beberapa bagian dari fungsionalitas sistem disediakan oleh desainer • Perkakas seperti HyperCard banyak dijumpai sekarang ini • Teknik dari Wizard of Oz • Peringatan mengenai desain berulang • Kelembaman desain – keputusan yang mulanya buruk akan tetap jadi buruk • 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 • Komunikasi melalui siklus hidup • Penggunaan kembali pengetahuan desain melintasi produk-produk • Pelaksanaan disiplin desain • Mempresentasikan argumen untuk nilai yang harus dibayar untuk desain • Mengorganisasikan ruang besar desain potensial • Orientasi Proses • Menjaga urutan pertimbangan dan pembuatan keputusan • Orientasi Struktur • Penekanan pada struktur post hoc alternatif desain yang dipertimbangkan

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

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

Interaksi Manusia dan Komputer (Proses Desain)