Interaksi Manusia dan Komputer (Proses Desain)

Presentasi berjudul: "Interaksi Manusia dan Komputer (Proses Desain)"— Transcript presentasi:

1 Interaksi Manusia dan Komputer (Proses Desain)

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

3 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

4 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

5 Verifikasi dan Vasilidasi
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

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

7 Menggunakan Aturan Desain
Aturan desain menyarankan bagaimana meningkatkan tingkat kegunaan

8 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 mendefinisikan tingkat kegunaan sebagi keefektifan, efisiensi dan kepuasan dengan mana pengguna menyelesaikan suatu tugas

9 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

10 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

11 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

12 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

13 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

14 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

15 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