standar proses ucd untuk sistem interaktif

Merencanakan Design untuk Pengguna ( Plan For Human Centered Design)

Rasionalitas design (design rasionality) adalah informasi yang menjelaskan alasan mengapa suatu keputusan dalam suatu tahap perancangan / desain sistem komputer dibuat atau diambil, termasuk deskripsi struktural atau arsitektural dan deskripsi fungsi atau perilakunya.

Beberapa keuntungan rasionalitas desain:

  1. Dalam bentuk yang eksplisit rasionaitas desain menyediakan makanisme komunikasi diantara anggota tim desain sehingga pada tahapan desain atau pemeliharaan( maintenance), anggota tim memahami keputusan kritis/penting mana yang telah dibuat,alternatif  apa saja yang telah diteliti, dan alasan apa yang menyebabkan suatu alternatif  dipilih diantara alternatif  lain. 

 2. Akumulasi pengetahuan dalam bentuk rasionalitas desain untuk suatu set produk dapat digunakan kembali untuk mentransfer hal yang berhasil dalam suatu situasi ke siatuasi yang lainnya yang mirip. 
3. Usaha yang diperlukan untuk menghasilkan sebuah rasionalitas desain  memaksa desainer untuk bersikap hati-hati dalam mengambil suatu keputusan desain.

Pada area IMK, rasionalitas desain secara khusus memiliki arti penting untuk beberapa alasan:

1.   Umumnya tidak ada satu alternative desain yang terbaik. Desainer dihadapkan pada kondisi trade-off antara alternatif  berbeda yang ada. Rasionalitas desain digunakan untuk mendaftar pilihan yang ada dan mengkomunikasikan pilihan tersebut.

2.  Meskipun terdapat solusi yang optimal, ruang lingkupnya terlalu besar untuk langsung dapat ditemukan. Sehingga perlu dasainer mengindikasikan semua alternatif  yang telah diselidiki.

3. Usability sistem interaksi sangat bergantung pada konteks penggunaannya. Memperhatikan konteks keputusan perancangan yang dibuat akan membantu proses perancangan sistem yang baru nantinya. Jika konteksnya sama dengan yang lama, maka rasionalitas desain dapat di adopsi tanpa revisi, sebaliknya jika konteksnya berubah, maka rasionalitas desain ditelaah kembali dan dihilangkan alternatif yang tidak sesuai.

  Memahami dan menentukan konteks pengguna ( Understand and Specify the context of use )

a. Karakteristik pengguna yang diharapkan

b. Pekerjaan yang dilakukan pengguna

c. Pemecahan secara hirarki atas pekerjaan global

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

e. Deskripsi harus mencakup alokasi aktifitas dan langkah operasional antara manusia dan sumberdaya teknologi

f. Pahami lingkungan tempat pengguna akan menggunakan sistem

g. Sangat penting awal langkah untuk menentukan kebutuhan sistem minimal dan optimal.

Menentukan kebutuhan pengguna dan Organisasi ( Spesifiy the user and organizational requirement)

Dalam UCD penting untuk memperluas aktivitas kebutuhan fungsional sistem  dengan membuat pernyataan eksplisit kebutuhan pengguna dan organisasi, dalam hubungannya dengan konteks diskripsi penggunaan dalam hal:

1.    Kualitas perancangan interaksi manusia dan komputer serta workstation,

2.   Kualitas dan isi tugas pengguna ( termasuk alokasi tugas diantara kategori penguna yang berbeda ),

3.     Kinerja tugas yang efektif khususnya dalam hal transparasi aplikasi ke pengguna,

4.  Kerjasama dan komunikasi yang efektif diantara pengguna dan pikah ketiga yang relevan,

5.     Dibutuhkan kinerja sistem baru terhadap tujuan finansial.

Solusi perancangan yang dihasilkan ( Produxt design solution)

1.  Dengan memgunakan pengetahuan yang ada untuk mengembangkan suatu proposal solusi perancangan.

2.     Membuat solusi perancangan lebih konkrit ( dengan simulasi, prototipe, dll )

3.  Memperlihatkan prototipe ke pengguna dan mengamatinya saat melakukan tugas spesifik, dengan atau tanpa bantuan evaluatur.

4.     Menggunakan umpan balik untuk perbaikan rancangan,

5.     Mengulang proses ini sampai tujuan perancangan dipenuhi.

Evaluasi Perancangan terhadap kebutuhan pengguna ( Evalute Design againts requirements)

1. Formative: menyediakan umpanbalik yang dapat digunakan untuk memperbaiki rancangan.

2.   Summative: melakukan penilaian apakah tujuan pengguna dan organisasi telah tercapai.

System meets specified organizational, user and functional requirements. (Sistem memenuhi pengguna organisasi, tertentu dan fungsional persyaratan)

UCD adalah pendekatan untuk desain yang melibatkan langsung pengguna dengan berbicara langsung dengan pengguna pada tahap-tahap penting suatu projek. Tujuannya adalah  menghasilkan produk yang sesuai dengan kebutuhan pengguna. Pengguna adalah pusat dari dua lingkaran adalah lingkaran dalam adalah konteks, tujuan, lingkungan dan sasaran serta Lingkaran luar adalah detil tugas, isi tugas, pengelolaan tugas dan aliran tugas.

Sistem pada UCD melakukan cara pendekatan secara langsung kepada pengguna dengan cara bertanya langsung, survey yang dapat dilakukan agar mengetahui karakter pribadi pengguna, setelah melakukan riset dengan pendekatan pengguna pada saat sistem selesai dibuat, pengguna di harapkan melakukan tes pada sistem tersebut disitulah yang penting apakah sistem tersebut berhasil membuat seperti apa yang pengguna tersebut inginkan atau malah membingungkan, tujuan dari produk atau sistem dibuat agar pengguna nyaman dengan adanya metode UCD akan ada relasi antar pembuat dan pengguna sehingga keakuratan pembuatan sistem tidak memerlukan waktu lama dan sesuai keinginan pengguna karena tidak mungkin membuat sistem yang hanya dapat di pakai oleh pembuatnya saja, tujuan produk di ciptakan adalah mempermudah pekerjaan pengguna jadi anggap saja pengguna itu sebagai raja, sangat bermanfaat sekali UCD kerja juga tidak memerlukan berkali kali untuk menemukan goal, karena belum tentu pemikiran pembuat sistem dengan pemakai sama mungkin bisa 2x maintenance dari proses pembuatan lalu dilakukan tes dan ternyata hasilnya masih sangat kurang memuaskan pengguna lalu tinggal sedikit sentuhan agar pengguna dapat menemukan goalnya, biasanya setelah dilakukan UCD di awal dengan cara pendekatan tersebut sistem tidak meleset jauh dari permintaan pengguna. itu bisa juga di pakai survey dengan cara kuisioner tapi kalau penggunanya banyak karena pada hasil kuisioner tersebut dapat digunakan sebagai acuan rata rata karakter pemakai karena biasanya beda pemakai beda pemikiran.

Referensi :

http://aldiimk.blogspot.co.id/p/proses-ucd.html

http://dokumen-itku.blogspot.co.id/2010/08/proses-user-centered-design-ucd.html

http://adipw-imk.blogspot.co.id/2010/08/1-proses-ucd.html

V Model

Pengertian V Model

       Merupakan model pengembangan perangkat lunak yang didasarkan pada hubungan antara setiap fase pengembangan siklus hidup yang tercantum dalam model Watterfall yang merupakan pengembangan perangkat lunak dan fase yang terkait pengujian. Bisa dikatakan 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.

Tahapan dalam  V Model

Tahapan pada V Model dibagi menjadi 2 garis besar yaitu tahap Verifikasi dan Validasi atau testing.
Tahap Verfiikasi mengacu kepada usaha penyesuaian spesifikasi software dengan kebutuhan klien/konsumen, tahapan ini meliputi serangkaian kegiatan sebagai berikut:

1. Business Case: Merupakan tahapan awal yang menggambarkan kebutuhan/harapan konsumen terhadap sistem yang akan dikembangkan, termasuk manfaat sistem terhadap konsumen dan perkiraan biaya yang harus disediakan.
2. Requirement: pada fase ini klien mendapatkan gambaran atau diminta memberikan gambaran kebutuhan yang diharapkan dapat dipenuhi oleh software, baik kebutuhan fungsional maupun non fungsional.
3. Analisis Informasi: Setelah diperoleh spesifikasi sistem dari fase requirement, selanjutnya aktivitas difokuskan bagaimana cara kerja software untuk memenuhi kebutuhan tersebut, termasuk metode, hardware dan software apa saja yang diperlukan untuk mencapai kebutuhan yang sudah didefinisikan.
4. Perancangan Sistem: pada tahapan ini akan dibuat rancangan software secara lebih terinci sesuai spesifikasi yang sudah disepakati.
5. Unit Design: merancang setiap elemen/unit software termasuk rancangan modul/program, antarmuka, database dan lain-lain.
6. Development: merealisasikan hasil rancangan menjadi satu aplikasi/program tertentu.

Tahapan Validasi merupakan serangkaian tahapan yang mengacu kepada kesesuaian software dengan spesifikasi yang sudah ditetapkan. Tahapan ini dicapai melalui serangkaian pengujian/testing sebagai berikut:

• Unit test: menguji setiap komponen/unit program apakah sesuai dengan rancangan unit yang sudah ditetapkan. Secara teoritis seharusnya pengujian dilakukan oleh orang tertentu yang bertugas sebagai software tester, tetapi dalam kenyataannya seringkali unit testing dilakukan oleh programmer sendiri.
• Interface test: setelah semua komponen diuji secara terpisah, tahapan selanjutnya dilakukan interface test untuk melihat sejauh mana setiap komponen dapat berinteraksi satu sama lain sesuai dengan fungsi yang diharapkan.
• System test: setelah semua interface berjalan dengan baik, selanutnya dilakukan system test untuk melihat sejauh mana sistem/software dapat memenuhi kebutuhan secara keseluruhan. System testing bersifat menyeluruh dan tidak dapat dilakukan berdasarkan fungsionalitas sistem yang diuji secara terpisah. Aktivitas pada system testing termasuk melakukan pengujian hal-hal berikut:
1. Performance – apakah kinerja sistem sesuai dengan target yang sudah didefinisikan sebelumnya.
2. Volume – apakah software/sistem dapat menampung volume informasi yang cukup besar.
3. Stress – apakah software/sistem dapat menampung sejumlah informasi pada waktu-waktu tertentu.
4. Documentation – apakah semua dokumentasi penting sudah disiapkan.
5. Robustness – apakah software/sistem cenderung stabil pada berbagai kondisi diluar dugaan/ekstrim.

• Acceptance test merupakan aktivitas untuk menguji sejauh mana sistem/software dapat membantu memecahkan business case, dalam artian apakah sistem/software tersebut sudah sesuai dengan harapan konsumen/klien dan sejauh mana manfaat sistem/software ini bagi klien. Test ini sering kali disebut sebagai User Acceptance Test (UAT).
• Release testing: test ini dilakukan untuk menguji sejauh mana sistem/software dapat mendukung aktivitas organisasi dan berjalan dengan harmonis sesuai dengan kegiatan rutin organisasi. Beberapa pertanyaan coba dijawab pada fase ini misalnya apakah software tersebut mempengaruhi sistem lain? Apakah software tersebut kompatibel dengan sistem lain? Bagaimana kinerja sistem sebenarnya di dalam organisasi?

 Kelebihan V model

•  V model sangat fleksibel. V model ini bisa digunakan untuk project tailoring serta penambahan pengurangan method dan tool secara dinamik.

•   V model dikembangkan dan di maintain oleh publik. User dari V model berpartisipasi dalam change board yang memproses semua change request terhadap V model.

Kekurangan V model

•  V model hanya bisa digunakan sekali dalam suatu proyek hal tersebut disebabkan kerena V model merupakan model yang project oriented.

• V model bersifat terlalu fleksibel sehingga mengakibatkan beberapa aktivitas-aktivitas yang digambarkan dalam V model menjadi terlalu abstrak. Hal tersebut mengakibatkan tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.

Dimana saja V Model Diterapkan?

1. Dalam proyek teknologi informasi di Jerman
2. V Model dibandingkan dengan CMM
3. V Model didesain untuk mengembangkan sistem yang didalamnya terdapat dua komponen
4. Pengembangan V Model dalam bidang industri dapat dilakukan dengan mudah

Referensi

http://citrahuang99.wordpress.com/2013/01/21/citrahuang09-tugas-imk-model-siklus-hidup-software-wordpress-com/

http://imk-a.blogspot.com/2013/06/topik-3-paradigma-interaksi-prinsip.html

Star Lifecycle Model (Hartson & Hix, 1989)

Model Siklus Hidup Star (Hartson & HIx,1998bangan Software ( Siklus Hidup Software )

Star life cycle model merupakan proses pengembangan software dengan memperhatikan tahapan-tahapan berbentuk bintang melalui proses analisa, evaluasi, rancangan jalan, validasi dan benchmark yang dimana dilakukan proses pengujian secara terus menerus

–          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.

 C.    Pengujian

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.

Referensi :

– http://en.wikipedia.org/wiki/Waterfall_model

– http://mega19boy.files.wordpress.com/2011/03/model-rad.pdf

– http://ayip7shortcutsharing.blogspot.com/2013/06/pengertian-model-v-keuntungan-model-v.html

– http://chellessie.blogspot.com/2013_01_01_archive.html

–http://ayuputrimahadi.blogspot.com/2013/01/tugas-interaksi-manusia-komputer-teori.html

– http://densi8040110056.blogspot.com/2013/01/star-lifecycle-model.html

– Buku Software Engineering by Roger S. Pressman

simple interaction design model ( model rancangan interaksi sederhana )

Simple Interaction Design Model 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. Dan Sebagai representasi suatu perencanaan pengembangan yang berisikan sekumpulan elaborasi alternatif dan suksesif.

Pada model rancangan interaksi sederhana ini input atau masukan hanya memiliki satu titik. yang mana masukan tersebut, lalu lakukan langkah-langkah berikut :

–          Identifikasi kebutuhan dan persyaratan sistem disini suatu sistem akan di identifikasi sesuai dengan kebutuhan sistem itu sendiri.

–          Pengembangan desain alternatif (desain konseptual dan fisikal)

–          Membuat versi interaktif dari desain yang dihasilkan

–          Mengevaluasi desain (usabilitas dan user experience)

     Evaluasi

Evaluasi dapat dilakukan dimana saja, rancangan yang telah di evakuasi dapat kambali 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 pendesainannya, sehingga pada tahap evaluasi terciptalah sebuah hasil akhir yang valid.

Referensi

 http://en.wikipedia.org/wiki/Waterfall_model

– http://mega19boy.files.wordpress.com/2011/03/model-rad.pdf

– http://ayip7shortcutsharing.blogspot.com/2013/06/pengertian-model-v-keuntungan-model-v.html

– http://chellessie.blogspot.com/2013_01_01_archive.html

–http://ayuputrimahadi.blogspot.com/2013/01/tugas-interaksi-manusia-komputer-teori.html

– http://densi8040110056.blogspot.com/2013/01/star-lifecycle-model.html

– Buku Software Engineering by Roger S. Pressman

waterfall model

MASIH KOSONG