PROSES DESAIN FAKULTAS ILMU KOMPUTER - UNIVERSITAS BRAWIJAYA 3/14/2017

Transkripsi

1 PROSES DESAIN FAKULTAS ILMU KOMPUTER - UNIVERSITAS BRAWIJAYA 3/14/2017

2 PROSES PERANGKAT LUNAK

3 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)

4 THE WATERFALL MODEL Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance

5 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

6 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

7 DESAIN RINCI Penyempurnaan deskripsi komponen yang didapatkan pada tahap desain arsitektur Harus memberikan penjelasan rinci sehingga komponen dapat diimplementasikan dalam bahasa pemrograman

8 CODING DAN UNIT TESTING Mengimplementasikan dalam beberapa bahasa pemrograman executable Setelah coding, komponen dapat diuji untuk memverifikasi bahwa komponen tersebut melakukan fungsinya dengan benar

9 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

10 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

11 PEMELIHARAAN Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance

12 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

13 THE WATERFALL MODEL Siklus hidup pengembangan di atas menggambarkan proses desain secara runtut Pada kenyataannya, proses desain sebenarnya iteratif

14 THE WATERFALL MODEL Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance

15 THE WATERFALL MODEL Hal ini menunjukkan bahwa aktivitas spefisikasi kebutuhan tidak dijalankan dengan benar Atau mungkin kebutuhan untuk sistem tidak dapat ditentukan di awal

16 SIKLUS DESAIN INTERAKSI

17 SIKLUS DESAIN INTERAKSI what is wanted interviews what is there vs. what is wanted scenarios task analysis analysis evaluation heuristics dialogue notations prototype guidelines principles design precise specification implement and deploy

18 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

19 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

20 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

21 FOKUS PENGGUNA

22 KETAHUI PENGGUNA ANDA Siapakah mereka? Mungkin tidak seperti Anda Bicara dengan mereka Perhatikan mereka Gunakan imajinasi Anda

23 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

24

25 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

26

27 PERSONA Gambaran imajiner yang berisi deskripsi contoh pengguna yang mewakili calon pengguna Cukup berhasil dalam membantu tim menghasilkan desain yang berfokus pada pengguna

28

29 TEKNIK-TEKNIK EVALUASI

30 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

31 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

32 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

33 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

34 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

35 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)

36 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

37 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

38 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

39 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

40 TERIMA KASIH