PROSES DESAIN
FAKULTAS ILMU KOMPUTER - UNIVERSITAS BRAWIJAYA 3/14/2017
PROSES PERANGKAT LUNAK
PROSES PERANGKAT LUNAK
• 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
• Dilakukan pada awal pengembangan produk
• Desainer dan pelanggan mencoba untuk mengambil gambaran seperti apa sistem nantinya akan berfungsi
• Kebutuhan pengguna dibuat dari perspektif pelanggan
• Tidak hanya mencakup fungsi yang akan dimiliki oleh perangkat lunak, tetapi juga detail tentang lingkungan di mana sistem tersebut akan beroperasi
• Transformasi dari bahasa alami kebutuhan menjadi bahasa executable merupakan salah satu kunci keberhasilan pengembangan
DESAIN ARSITEKTUR
• Berkonsentrasi pada bagaimana sistem menyediakan layanan
• Menyangkut dekomposisi tingkat tinggi dari sistem menjadi komponen-komponen yang dikembangkan secara terpisah
• Menentukan komponen apa menyediakan layanan apa
• Mendeskripsikan ketergantungan antara komponen yang berbeda
• Harus juga menentukan persyaratan non-fungsional (fitur yang tidak secara langsung terkait dengan layanan): efisiensi, kehandalan, waktu, dan keselamatan
DESAIN RINCI
• Penyempurnaan deskripsi komponen yang didapatkan pada tahap desain arsitektur
• Harus memberikan penjelasan rinci sehingga komponen dapat diimplementasikan dalam bahasa pemrograman
CODING DAN UNIT TESTING
• Mengimplementasikan dalam beberapa bahasa pemrograman executable
• Setelah coding, komponen dapat diuji untuk memverifikasi bahwa komponen tersebut melakukan fungsinya dengan benar
INTEGRASI DAN PENGUJIAN
• Mengintegrasikan komponen seperti yang dijelaskan dalam desain arsitektur
• Dilakukan setelah komponen telah diimplementasikan dan diuji secara individual
• Melakukan pengujian penerimaan (acceptance test) dengan pelanggan untuk memastikan bahwa sistem memenuhi kebutuhan mereka
• Setelah penerimaan sistem yang terintegrasi, akhirnya produk dirilis ke pelanggan
PEMELIHARAAN
• Setelah produk dirilis, sistem berada di tahap pemeliharaan
• Dilakukan koreksi terhadap kesalahan sistem yang ditemukan setelah rilis
• Melakukan revisi layanan sistem untuk memenuhi kebutuhan yang tidak disadari selama perkembangan sebelumnya
• Memberikan feedback kepada semua kegiatan lainnya dalam siklus hidup
PEMELIHARAAN
Requirements specification
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
• Siklus hidup pengembangan di atas menggambarkan proses desain secara runtut
• Pada kenyataannya, proses desain sebenarnya iteratif
THE WATERFALL MODEL
Requirements specification
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
what is wanted
analysis
design
implement and deploy prototype
interviews what is there
vs.
what is wanted
guidelines principles
dialogue notations
precise specification
evaluation heuristics
scenarios task analysis
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
Implementasi dan Deployment
• Setelah proses desain selesai, kita mengimplementasikan desain tersebut dan men-deploy
• Melibatkan:
• Menulis kode
• Membuat hardware
• Menulis dokumentasi dan manual
• Segala sesuatu yang dapat diberikan kepada pengguna
FOKUS PENGGUNA
KETAHUI PENGGUNA ANDA
• Siapakah mereka?
• Mungkin tidak seperti Anda
• Bicara dengan mereka
• Perhatikan mereka
• Gunakan imajinasi Anda
SKENARIO
• Skenario cerita untuk tujuan desain
• Mungkin merupakan representasi desain yang paling sederhana, tetapi salah satu yang paling fleksibel dan powerful
• Contoh skenario yang cukup singkat: 'pengguna bermaksud untuk menekan tombol "save", tapi sengaja menekan “quit" tombol sehingga kehilangan pekerjaannya‘
• Skenario dapat ditambah dengan sketsa, simulasi screen shot, dll.
• Sketsa dan gambar yang disebut storyboard mirip dengan teknik yang digunakan dalam pembuatan film untuk menggambarkan plot cerita
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 memiliki tiga tujuan utama:
• Untuk menilai fungsionalitas sistem
• Untuk menilai user experience
• Untuk mengidentifikasi masalah dengan sistem
• Fungsionalitas sistem penting untuk diukur agar sesuai dengan kebutuhan pengguna
• Menilai user experience termasuk mengukur seberapa mudah sistem tersebut untuk dipelajari, daya guna sistem tersebut, dan kepuasan pengguna terhadap sistem tersebut
• Mengidentifikasi masalah pada sistem mencakup aspek desain yang memberikan hasil yang tidak diharapkan atau kebingungan pada pengguna
• Kita akan membahas dua kategori teknik evaluasi: analisis pakar dan partisipasi pengguna
EVALUASI MELALUI ANALISIS PAKAR
• 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
• Dikembangkan oleh Jakob Nielsen dan Rolf Molich
• Sebuah metode yang menggunakan sekumpulan heuristik yang relatif sederhana dan umum
• Dapat dilakukan pada spesifikasi desain
• Berguna untuk mengevaluasi desain awal
• Karena itu, metode ini menjadi pendekatan yang fleksibel dan relatif murah
• Mekanismenya adalah beberapa evaluator secara independen memberikan kritik tentang sistem terhadap potensi masalah usability
• Untuk membantu evaluator, disediakan 10 heuristik
• Setiap evaluator menilai sistem dan mencatat pelanggaran dari setiap heuristik yang akan menunjukkan potensi masalah usability
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
• Kesepuluh heuristik Nielsen adalah:
1. Reliabilitas sistem
• Selalu informasikan pengguna tentang apa yang sedang terjadi, melalui feedback
• Sebagai contoh, jika operasi sistem akan memakan waktu, memberikan indikasi berapa lama dan berapa banyak selesai
2. Kesesuaian antara sistem dan dunia nyata
• Sistem ini harus menggunakan bahasa pengguna, dengan kata-kata, frase dan konsep familiar bagi pengguna
EVALUASI HEURISTIK
3. Kontrol dan kebebasan pengguna
• Pengguna sering tanpa sengaja memilih fungsi sistem yang salah dan membutuhkan fitur ‘Quit’ untuk meninggalkan fungsi yang tidak diinginkan
• Dukungan ‘undo’ dan ‘redo’
4. Konsistensi dan standar
• Ikuti konvensi platform dan standar yang umum
5. Pencegahan kesalahan
• Buatlah sulit bagi penggunauntuk membuat kesalahan
EVALUASI HEURISTIK
6. Mengenali, bukan mengingat
• Buatlah objek-objek, tindakan-tindakan dan pilihan-pilihan terlihat
• Pengguna tidak perlu mengingat informasi
7. Fleksibilitas dan efisiensi penggunaan
• Memungkinkan pengguna untuk mengubah cara untuk melakukan tindakan yang sering dilakukan
• Accelerators mungkin sering mempercepat interaksi bagi pengguna ahli
8. Desain estetis dan minimalis
• Dialog tidak boleh berisi informasi yang tidak relevan atau jarang dibutuhkan
EVALUASI HEURISTIK
9. Bantu pengguna untuk mengenali, mendiagnosis dan keluar dari kesalahan
• Pesan kesalahan harus ditampilkan dalam bahasa sederhana (tanpa kode), menunjukkan masalah yang terjadi, dan menyarankan solusi
10. Bantuan dan dokumentasi
• Mungkin perlu untuk memberikan bantuan dan dokumentasi
• Setelah masing-masing evaluator menyelesaikan penilaian mereka, semua masalah dikumpulkan dan dihitung rata-rata dari tingkat setiap kesalahan
