Standar Proses UCD untuk Sistem Interaktif

UCD ( User Centered Design ) merupakan paradigma baru dalam pengembangan sistem berbasis web. Perancangan berbasis pengguna ( User Centered Design / UCD ) adalah istilah yang digunakan untuk menggambarkan filosofi perancangan. Konsep dari UCD adalah User sebagai pusat dari proses pengembangan sistem, tujuan, sifat-sifat, dan lingkungan sistem semua didasarkan dari pengalaman pengguna. 

Proses dari User Centered Design ( UCD ) terdapat lima proses yaitu seperti gambar dibawah :

1.      Plan the human-centered design process

Pada tahap ini dilakukan diskusi terhadap orang-orang yang akan mengerjakan proyek, untuk mendapatkan komitmen bahwa proses pembangunan proyek adalah berpusat kepada pengguna atau user. Proyek akan memiliki waktu dan tugas untuk melibatkan pengguna atau user dalam awal dan akhir proses atau di mana mereka dibutuhkan. Dan juga orang-orang yang mengerjakan proyek harus mengetahui betul tentang metode User Centered Design (UCD) ini melalui studi literatur, pelatihan atau seminar. metode ini dilakukan dengan cara membaca dan memahami buku - buku referensi, jurnal, dan media lain yang berkaitan dengan pengolahan data secara  umum yang mendukung dan mempertegas teori - teori yang ada, sehingga dapat menanamkan komitmen bahwa perancangan menggunakan User Centered Design (UCD) dapat memenuhi keinginan pengguna.

2.      Understand and Specifying the Context of Use

Pada tahap ini, Proses UCD Mengidentifikasi orang yang akan menggunakan produk. Ini akan menjelaskan untuk apa dan dalam kondisi seperti apa mereka akan menggunakan produk. Dalam memahami dan menentukan konteks pengguna meliputi :

·         Karakteristik pengguna yang diharapkan

·         Pekerjaan yang dilakukan pengguna

·         Pemecahan secara hirarki atas pekerjaan global

·    Tujuan global penggunaan sistem untuk setiap kategori pengguna, termasuk karakteristik tugas yang mungkin mengganggu penggunaan dalam scenario   khusus, seperti frekuensi dan lama kinerja.

·   Deskripsi harus mencakup alokasi aktifitas dan langkah operasional antara   manusia dan sumber daya teknologi.

·       Pahami lingkungan tempat pengguna akan menggunakan system.

·      Sangat penting awal langkah untuk menentukan kebutuhan sistem minimal dan optimal dengan memperhatikan.

3.      Specify  the user and organizational requirements

Mengidentifikasi kebutuhan pengguna dan kebutuhan organisasi.  pada tahap ini adalah tahap penggalian informasi atau data untuk menggumpulkan kebutuhan dari pengguna, kemudian setelah informasi/data telah terkumpul, dilakukanlah penataan informasi dari data kebutuhan pengguna tersebut, lalu kebutuhan pengguna digambarkan ke dalam berbagai bentuk/teknik, seperti narasi, gambar, atau diagram, dll. Dalam hubungannya dengan konteks pengguna yaitu :

·         Kualitas perancangan interaksi manusia dan komputer serta workstation.

·         Kualitas dan isi tugas pengguna ( termasuk alokasi tugas diantara kategori pengguna yang berbeda ).

·         Kinerja tugas yang efektif khususnya dalam hal transparansi aplikasi ke pengguna.

·         Kerjasama dan komunikasi yang efektif diantara pengguna dan pihak ketiga yang relevan.

·         Dibutuhkan kinerja sistem baru terhadap tujuan finansial.

4.      Produce Design Solutions

Tahap ini merupakan tahap perancangan solusi. Dimana peneliti akan membangun desain sebagai solusi dari sistem yang sedang dianalisis dengan teknik prototyping yang digunakan untuk membuat ide-ide terlihat dan memfasilitasi komunikasi yang efisien dengan pengguna. Ini mencegah kemungkinan kebutuhan dan biaya tinggi yang terkait untuk pengerjaan ulang produk pada langkah berikutnya dari siklus hidup. Ketika solusi desain disajikan kepada pengguna, mereka juga harus diperbolehkan untuk melaksanakan tugas-tugas. Umpan balik pengguna yang dikumpulkan harus dimasukkan dalam perbaikan solusi desain. Ini harus iterasi terus sampai tujuan desain telah dipenuhi

5.      Evaluate design against requirements

Tahap ini merupakan tahap evaluasi terhadap perancangan yang telah disesuaikan dengan kebutuhan pengguna. Evaluasi ini dilakukan untuk mengetahui sejauh mana perancangan yang dihasilkan sesuai dengan kebutuhan pengguna dengan teknik kuesioner. Tujuannya adalah untuk menghasilkan umpan balik untuk lebih meningkatkan produk dan untuk menentukan apakah desain memenuhi kebutuhan pengguna yang ditentukan, tujuan kegunaan dan sesuai dengan pedoman kegunaan umum. Siklus proses UCD terus berlangsung selama tujuan kegunaan belum dipenuhi.

Referensi :

       http://dyahindriatna.blogspot.co.id/2017/12/standar-proses-ucd-untuk-sistem.html

            

Star Lifecycle Model (Hartson & Hix, 1989)

 Star Lifecycle Model (Hartson & Hix, 1989)

               

Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design ) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama aka lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user. Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.

– Analisa
Identifikasi kemampuan user, strategi yang digunakan untuk meningkatkan ketrampilannya, alat yang saat ini dipakai, masalah-masalah yang dialami, perubahan yang diinginkan baik dalam ketrampilan maupun peralatan.
Metode : tanya kemampuan user dan buat daftar dengan skala prioritas, observasi ketrampilan di lapangan.

– Evaluasi kompetisi
Tentukan kekuatan dan kelemahan rancangan
Metode : pengguna diminta untuk mencoba menggunakan berbagi produk dan minta untuk menyebutkan kelebihan dan kelemahan dari masing-masing produk.

-Rancang sambil jalan
Gunakan hasil analisa untuk membuat alternatif solusi, minta masukan sampai dengan penentuan pilihan yang terbaik.
Metode : tanyai user sehubungan dengan pengalaman menggunakan prototipe.

– Evaluasi dan validasi
Secara periodik user memberikan masukan selama pengembangan dan perancangan akan diulang berdasarkan masukan tadi.
Metode : amati kebutuhan pokok user dalam menggunakan sistem.

– Benchmark
Memadukan hal-hal terbaik yang dimiliki pesaing untuk diterapkan dalam sistem yang dibangun Metode : menggali informasi dari user hal-hal yang sebaiknya ada dibandingkan dengan kompetitor, contoh : situs IBM.

Sumber  :

• https://rickyagustinus51.wordpress.com/2015/06/03/model-pada-life-cycle/

Simple Interaction Design Model

   

        Simple Interaction Design Model

gambar simple interaction design model

       Pada model rancangan interaksi sederhana ini input atau masukan hanya memiliki satu titik. yang mana masukan tersebut diidentifikasikan apakah sesuai engan kebutuhan, lalu didesain sesuia dengan persyaratan yang telah ditetap kan. Setelah diDesain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah racangan tersebut dievaluasi.

    Evaluasi dapat dilaukan dimana saja, rancangan yang telah di evakuasi dapat kambali didesain ulang atau apakah rancanagn tersebut tidak sesuai dengan kebutuhan user, maka alur tersebut akan terus berbupar hingga pada tahap evaluasi tidak lagi terjadi kesalahan, baik dalam penetapan kebutuhan user maupun pendesainannya, sehingga pada tahap evaluasi terciptalah sebuah hasil akhir yang valid.

Terdapat dua sisi pengertian yang dapat digunakan terkait dengan desain interaksi :

·         Sebagai suatu proses untuk mencapai suatu tujuan dengan pencarian berbagai solusi melalui ruang lingkup sistem, materi, biaya dan kemungkinan penyelesaiannya (feasibilitas), sebagai wujud kreativitas dan pengambilan keputusan untuk menyeimbangkan trade-off

·         Sebagai representasi suatu perencanaan pengembangan yang berisikan sekumpulan elaborasi alternatif dan suksesif.
Empat kegiatan utama dalam desain interaksi :

·         Identifikasi kebutuhan dan persyaratan sistem

·         Pengembangan desain alternatif (desain konseptual dan fisikal)

·         Membuat versi interaktif dari desain yang dihasilkan

·         Mengevaluasi desain (usabilitas dan user experience)

Tiga karakter utama dari keempat kegiatan diatas yang perlu diperhatikan :

·         Terfokus pada users dan evaluasi artifak

·         Identifikasi, dokumentasi dan kesepakatan terhadap usability yang telah ada dan tujuan dari user experience

·         Adanya perulangan dalam desain karena perlunya bereksplorasi terlebih dahulu terhadap desain yang ada terkait dengan user
Ada teknik yang dapat digunakan untuk memilih dari sekian banyak solusi yang ada, diantaranya :

-   Mengavaluasi desain bersama user

-   Feasibilitas teknik

-   Threshold, tujuan usabilitas yang penilaiannya menggunakan kriteria  usabilitas

Pada model rancangan interaksi sederhana ini input atau masukan hanya memiliki satu titik. yang mana masukan tersebut diidentifikasikan apakah sesuai dengan kebutuhan, lalu didesain sesuai dengan persyaratan yang telah ditetapkan. Setelah diDesain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah rancangan tersebut dievaluasi. Evaluasi dapat dilakukan dimana saja,rancangan yang telah di evaluasi dapat kembali didesain ulang atau apakah rancangan tersebut tidak sesuai dengan kebutuhan user, maka alur tersebut akan terus berputar hingga pada tahap evaluasi tidak lagi terjadi kesalahan, baik dalam penetapan kebutuhan user maupun pendisainnya, sehingga pada tahp evaluasi terciptalah sebuah hasil akhir yang valid,

Sumber :

• http://riosilvianto92.blogspot.co.id/2014/06/simple-interaction-design-model.html
• http://yosuartrosihan.blogspot.co.id/2014/12/simple-interaction-design-model.html

V-Model

Pengertian Model V

Model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

Berikut penjelasan masing-masing tahap beserta tahap pengujiannya:

      1. Requirement Analysis & Acceptance Testing

Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan pengguna.

Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.

      2. System Design & System Testing

Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.

      3.  Architecture Design & Integration Testing

Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti: pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.

      4.  Module Design & Unit Testing

Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.

      5.  Coding

Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.

1.1 Keuntungan V Model

ü  Bahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa formal. Contoh : dengan menggunakan objek model ataupun frame-frame • Meminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnya

ü  Penyesuaian yang cepat pada projek yang baru

ü  Memudahkan dalam pembuatan dokumen projek

ü   Biaya yang murah dalam perawatan dan modifikasinya

ü   V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dan tool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.

ü   V Model dikembangkan dan di-maintain oleh publik. User dari V Model berpartisipasi dalam change control board yang memproses semua change request terhadap V Model.

1.2 Kerugian V Model

ü  Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi. V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan keseluruhan organisasi.

ü  Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.

ü  Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang lebih baik.

ü  oolnya tidak selengkap yang dibicarakan. SDE (Software Development Environment).Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud adalah “software yang mendukung pengembangan atau pemeliharaan / modifikasi dari system IT.

ü  V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.

ü  V Model terlalu fleksibel dalam arti ada beberapa activity dalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak. http://khoreullumam.blogspot.com/2013/02/v-model.html

Waterfall Model

WATERFALL

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Secara umum tahapan pada model waterfall dapat dilihat pada gambar berikut :

Gambar di atas adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:

• System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.
• Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
• Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
• Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
• Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
• Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.
• Keuntungan  Metode Waterfall
  • Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.
  • Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi  setiap fase atau tahapan akan mempunyai dokumen tertentu.
  • Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.
  
  
  Kelemahan waterfall
  • Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.
  • Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.
  • Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.
  • Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.
  • Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru.

Sumber :

• Buku Software Engineering by Roger S. Pressman
• http://en.wikipedia.org/wiki/Waterfall_model
• https://tonyjustinus.wordpress.com/2007/11/11/waterfall-process-model/
• http://d-in4matika.blogspot.co.id/2013/04/metode-waterfall-kelebihan-dan-kelemahan.html

jika ada masalah yang ingin ditanyakan hubungi:

WA:085273504542