• Rekayasa perangkat lunak (RPL) adalah disiplin untuk memahami proses pengembangan perangkat
lunak
• Salah satu pilar dari rekayasa perangkat lunak adalah siklus hidup perangkat lunak (software life cycle)
• Dalam pengembangan produk perangkat lunak, ada dua pihak utama: (1) pelanggan yang
membutuhkan produk dan (2) desainer yang harus memberikan produk
• Seringkali penting untuk mengidentifikasi pelanggan karena pelanggan tersebut bisa jadi merupakan
orang yang berbeda:
• Pelanggan yang merupakan klien dari perusahaan pengembang
• Pelanggan yang merupakan pengguna akhir dari sistem
• Orang yang bernegosiasi dengan desainer mungkin bukan merupakan pengguna yang sebenarnya
(contoh: aplikasi web)
THE WATERFALL MODEL
Requirements
specification
Architectural
design
Detailed
design
Coding and
unit testing
Integration
and testing
Operation and
maintenance
SPESIFIKASI KEBUTUHAN
Architectural
design
Detailed
design
Coding and
unit testing
Integration
and testing
Operation and
maintenance
VERIFIKASI DAN VALIDASI
• Sepanjang siklus hidup, sistem harus diperiksa untuk memastikan bahwa sistem tersebut memenuhi
persyaratan dan juga lengkap dan konsisten
• Pemeriksaan ini disebut sebagai validasi dan verifikasi
• Verifikasi: mendesain produk dengan benar
• Validasi: mendesain produk yang tepat
THE WATERFALL MODEL
Architectural
design
Detailed
design
Coding and
unit testing
Integration
and testing
Operation and
maintenance
THE WATERFALL MODEL
• Hal ini menunjukkan bahwa aktivitas spefisikasi kebutuhan tidak dijalankan dengan benar
• Atau mungkin kebutuhan untuk sistem tidak dapat ditentukan di awal
SIKLUS DESAIN INTERAKSI
SIKLUS DESAIN INTERAKSI
scenarios
what is task analysis
wanted guidelines
principles
interviews analysis precise
specification
what is there design
vs.
what is wanted dialogue implement
notations and deploy
evaluation
prototype
heuristics
SIKLUS DESAIN INTERAKSI
Requirements
• Apa yang telah ada dan apa yang ingin dibuat
• Contoh: Bagaimana cara orang saat menonton film? Apa jenis peralatan pribadi yang mereka gunakan
saat ini?
• Teknik: Wawancara, rekaman video, melihat dokumen, mengamati secara langsung
Analisis
• Memahami hasil requirements
• Mendapatkan poin-poin penting dari hasil observasi dan wawancara
SIKLUS DESAIN INTERAKSI
Desain
• Berpindah dari apa yang ingin dibuat ke bagaimana membuatnya
• Ada beberapa aturan, pedoman, dan prinsip-prinsip desain yang dapat digunakan untuk membantu hal ini
Iterasi dan Prototyping
• Manusia sangat kompleks dan kita tidak bisa berharap untuk langsung mendapatkan desain yang tepat
• Perlu dilakukan evaluasi desain untuk melihat seberapa baik desain tersebut dan di mana bisa dilakukan
penyempurnaan
• Hampir semua desain user interface melibatkan proses prototyping (memproduksi versi awal dari sistem
untuk dicoba langsung oleh pengguna yang sebenarnya)
• Prototype kemudian dievaluasi untuk melihat apakah dapat diterima dan di mana ada ruang untuk perbaikan
SIKLUS DESAIN INTERAKSI
• Siapakah mereka?
• Mungkin tidak seperti Anda
• Bicara dengan mereka
• Perhatikan mereka
• Gunakan imajinasi Anda
SKENARIO
• Sebagai contoh, kita mendesain pisau Swiss army digital yang memiliki layar LCD kecil dan menggunakan
tusuk gigi sebagai stylus
• Pisau tersebut terhubung ke internet secara nirkabel dan memberikan tips tentang penggunaan pisau
tersebut
• Di LCD tertulis, “Open the stone remover”, lalu, “Now push the blade into the rubber of the grommet”
• Kita melakukan perintah tersebut dan kemudian menunggu instruksi berikutnya
• Lihatlah pisau di tangan Anda ... oops, ibu jari Anda menutupi layar LCD
• Mungkin antarmuka suara akan lebih baik
• Kita dapat melihat seberapa skenario membuat kita untuk berpikir tentang desain secara rinci dan
melihat potensi masalah sebelum masalah tersebut benar-benar terjadi
PERSONA
• Gambaran imajiner yang berisi deskripsi contoh pengguna yang mewakili calon pengguna
• Cukup berhasil dalam membantu tim menghasilkan desain yang berfokus pada pengguna
TEKNIK-TEKNIK EVALUASI
TEKNIK-TEKNIK EVALUASI
• Kita perlu mengukur desain kita dan menguji sistem kita untuk memastikan bahwa mereka benar-benar
berjalan seperti yang kita harapkan dan memenuhi kebutuhan pengguna
• Evaluasi seharusnya tidak dianggap sebagai fase tunggal dalam proses desain
• Idealnya, evaluasi harus terjadi sepanjang siklus hidup desain
• Jauh lebih mudah untuk mengubah desain pada tahap awal pengembangan daripada di tahap-tahap
selanjutnya
• Hasil evaluasi memberikan feedback untuk melakukan modifikasi desain
TEKNIK EVALUASI
• Evaluasi pertama sistem idealnya dilakukan sebelum masuk pada tahap implementasi
• Jika desain itu sendiri dapat dievaluasi, kesalahan mahal dapat dihindari
• Semakin akhir sebuah kesalahan ditemukan, semakin mahal usaha untuk memperbaiki kesalahan
tersebut
• Sejumlah metode telah diusulkan untuk mengevaluasi sistem melalui analisis pakar
• Metode tersebut dapat digunakan pada setiap tahap dalam proses pengembangan sehingga metode
tersebut menjadi pendekatan evaluasi yang fleksibel
• Metode tersebut juga relatif murah karena tidak membutuhkan keterlibatan pengguna
• Kita akan membahas empat pendekatan analisis pakar: cognitive walkthrough, evaluasi heuristik,
penggunaan model dan penggunaan pekerjaan sebelumnya
COGNITIVE WALKTHROUGH
• Diusulkan oleh Polson et al.
• Merupakan upaya untuk mengenalkan teori psikologi ke dalam teknik walkthrough
• Evaluator mengecek urutan aksi-aksi dan memeriksa adanya masalah usability
• Biasanya, fokus utama adalah untuk mengecek seberapa mudah suatu sistem untuk dipelajari
• Untuk melakukan walkthrough, kita perlu empat hal:
• Spesifikasi atau prototipe sistem
• Deskripsi task pengguna yang akan dilakukan pada sistem
• Daftar tertulis dari aksi yang diperlukan untuk menyelesaikan task
• Indikasi pengguna
• Dengan informasi ini, evaluator mengecek urutan aksi dan memberikan kritik tentang sistem
EVALUASI HEURISTIK
• Evaluator menilai tingkat setiap masalah usability menggunakan rating pada skala 0-4:
• 0 = Saya tidak setuju bahwa ini adalah masalah kegunaan sama sekali
• 1 = masalah minor (tidak perlu diperbaiki kecuali ada waktu tambahan pada proyek)
• 2 = masalah usability kecil (perbaikan masalah ini harus diberi prioritas rendah)
• 3 = masalah usability utama (penting untuk diperbaiki sehingga harus diberikan prioritas tinggi)
• 4 = “bencana” usability (penting untuk diperbaiki sebelum produk ini dapat dirilis)
EVALUASI HEURISTIK
• Setelah masing-masing evaluator menyelesaikan penilaian mereka, semua masalah dikumpulkan dan
dihitung rata-rata dari tingkat setiap kesalahan
TUGAS