Simple Interaction Desain Model

Gambar. Simple Interaction Desain Model


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 di Desain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah rancangan tersebut dievaluasi.


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 ang valid

Dalam desain interaksi terdapat empat kegiatan utama, yaitu :
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)

STAR LIFECYCLE MODEL

Memahami apa kegiatan yang terlibat dalam desain interaksi adalah langkah pertama untuk

mampu melakukannya, tetapi juga penting untuk mempertimbangkan bagaimana kegiatan terkait dengan

satu sama lain sehingga proses pengembangan penuh dapat dilihat. Siklus hidup jangka

Model ini digunakan untuk mewakili model yang menangkap serangkaian kegiatan dan bagaimana mereka

terkait. Model canggih juga menggabungkan deskripsi tentang kapan dan bagaimana untuk bergerak

dari satu kegiatan ke depan dan deskripsi dari kiriman untuk setiap kegiatan.

Alasan model seperti yang populer adalah bahwa mereka memungkinkan pengembang, dan khususnya

manajer, untuk mendapatkan gambaran menyeluruh dari upaya pembangunan sehingga kemajuan yang dapat

dilacak, kiriman ditentukan, sumber daya yang dialokasikan, target ditetapkan, dan sebagainya.

Model yang ada memiliki berbagai tingkat kecanggihan dan kompleksitas. untuk proyek

melibatkan hanya beberapa pengembang berpengalaman, proses yang sederhana mungkin akan

memadai. Namun, untuk sistem yang lebih besar yang melibatkan puluhan atau ratusan pengembang dengan

ratusan atau ribuan pengguna, proses yang sederhana saja tidak cukup untuk menyediakan

struktur manajemen dan disiplin yang diperlukan untuk merancang sebuah produk yang dapat digunakan. jadi

sesuatu yang diperlukan yang akan memberikan formalitas lebih dan lebih disiplin. Perhatikan bahwa

ini tidak berarti inovasi yang hilang atau kreativitas yang menahan. Ini hanya berarti bahwa

Tentang waktu yang sama bahwa mereka yang terlibat dalam rekayasa perangkat lunak sedang mencari

alternatif untuk siklus hidup air terjun, demikian juga orang-orang yang terlibat dalam HCI mencari

alternatif cara untuk mendukung desain antarmuka. Pada tahun 1989, Star siklus hidup model yang

diusulkan oleh Hartson dan Hix seperti yang ditunjukkan pada gambar.

Hal ini muncul dari beberapa pekerjaan empiris mereka melihat bagaimana desainer antarmuka

pergi tentang pekerjaan mereka. Mereka mengidentifikasi dua mode yang berbeda dari aktivitas: modus analitik

dan sintetis modus. Yang pertama ditandai dengan pengertian seperti top-down,

pengorganisasian, peradilan, dan formal, bekerja dari pandangan sistem terhadap pengguna

pandangan, yang terakhir ditandai dengan pengertian seperti bottom-up, bebas berpikir, kreatif

dan adhoc, bekerja dari pandangan pengguna terhadap pandangan sistem. antarmuka

desainer bertugas di desainer perangkat lunak.

Berbeda dengan model siklus hidup diperkenalkan di atas, siklus hidup bintang tidak menentukan apapun

pemesanan kegiatan. Bahkan, kegiatan yang sangat saling berhubungan: Anda dapat memindahkan

dari kegiatan apapun kepada lainnya, asalkan Anda pertama kali pergi melalui kegiatan evaluasi.

Hal ini mencerminkan temuan dari studi empiris. Evaluasi merupakan pusat model ini,

dan setiap kali suatu kegiatan selesai, hasilnya (s) harus dievaluasi. Jadi proyek

mungkin mulai dengan pengumpulan persyaratan, atau mungkin mulai dengan mengevaluasi yang ada

situasi, atau dengan menganalisis tugas yang ada, dan sebagainya.

Siklus hidup Usability Rekayasa

Siklus hidup Teknik Usability diusulkan oleh Deborah Mayhew pada tahun 1999.

Banyak orang telah menulis tentang rekayasa kegunaan, dan sebagai Mayhew sendiri mengatakan, "Saya

tidak menciptakan konsep Siklus Hidup Rekayasa Usability. Aku juga tidak menemukan satu puntugas Usability Teknik termasuk dalam siklus hidup

Simple Interaction Desain Model

Gambar. Simple Interaction Desain Model


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 di Desain rancangan tersebut dibangun dan harus interaktif. Setelah itu barulah rancangan tersebut dievaluasi.


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 ang valid

Dalam desain interaksi terdapat empat kegiatan utama, yaitu :
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

V-Model

Dalam proses model Waterfall dasar melihat beberapa kelemahan atau keterbatasan dalam model yang mulai model SDLC baru. Seperti yang kita lihat dalam model Waterfall isu-isu yang ditemukan di akhir SDLC, hal ini disebabkan pengujian yang terjadi pada tahap akhir dari SDLC Anda. Untuk mengatasi masalah ini V-Model yang datang ke dalam gambar. Itu selalu lebih baik untuk memperkenalkan pengujian dalam tahap awal SDLC, seperti dalam model ini kegiatan pengujian akan dimulai dari tahap awal SDLC.
Sebelum memulai pengujian yang sebenarnya, tim pengujian harus bekerja pada berbagai kegiatan seperti penyusunan Strategi Uji, Uji Perencanaan, Penciptaan kasus Uji & Test Scripts yang bekerja paralel dengan kegiatan pembangunan yang membantu untuk mendapatkan tes diserahkan tepat waktu.
Dalam Model Pengembangan Perangkat Lunak Siklus Hidup V, berdasarkan informasi yang sama (persyaratan spesifikasi dokumen) kegiatan pembangunan & pengujian dimulai. Berdasarkan dokumen persyaratan tim pengembang mulai bekerja pada desain & setelah selesai pada desain mulai implementasi aktual dan tim pengujian mulai bekerja pada perencanaan pengujian, menulis uji kasus, script pengujian. Kedua kegiatan bekerja sejajar satu sama lain. Dalam model Waterfall & V-model mereka cukup mirip satu sama lain. Karena itu adalah Uji Perangkat Lunak paling populer Hidup Model Siklus sehingga sebagian besar organisasi mengikuti model ini.
V-model juga disebut sebagai Verifikasi dan model Validasi. Kegiatan pengujian tampil dalam setiap fase dari fase Siklus Hidup Uji Perangkat Lunak. Di paruh pertama model kegiatan validasi pengujian terintegrasi dalam setiap fase seperti kebutuhan pengguna review, dokumen Sistem Desain & di babak berikutnya kegiatan pengujian Verifikasi datang dalam gambar.
Khas V-Model menunjukkan kegiatan Pengembangan Perangkat Lunak di sisi kiri dari model dan sisi kanan dari Fase Pengujian model yang sebenarnya dapat dilakukan.
Dalam proses ini “Do-Prosedur” akan diikuti oleh tim pengembang dan “Check-Prosedur” akan diikuti oleh tim pengujian untuk memenuhi persyaratan yang disebutkan.
Dalam siklus V-Model hidup pengembangan perangkat lunak langkah yang berbeda yang diikuti Namun di sini kita akan mengambil jenis yang paling umum dari V-model contoh. V-model biasanya terdiri dari beberapa tahap sebagai berikut:

1. Unit Pengujian: Persiapan Kasus Uji Satuan
2. Integrasi Pengujian: Persiapan Uji Kasus Integrasi
3. Sistem Pengujian: Persiapan kasus uji Sistem
4. Penerimaan Pengujian: Persiapan Uji Kasus Penerimaan

V-model dikembangkan di Jerman untuk aplikasi pertahanan. Didalam V-model terdapat 3 kompomen kerja yang pokok yakni Project Definition yakni mendefenisian project apa yang akan dibuat, Time yakni waktu yang dibutuhkan dalam pengimplementasiannya dan Project Test And Integration atau pengujian dan integrasi project tersebut.
Model ini berpusat pada user. Dimana pengulangan selalu dibutuhkan jika kebutuhan untuk user belum terpenuhi “ketidaktahuannya” tanpa harus memberikan software dengan lingkungan yang baru. Resiko pada setiap tahap dalam pengembangan dapat dikurangi dengan memahami kebutuhan user.
Didalam pendefenisian project terdapat aktivitas Concept Operation (konsepsi project) yakni menentukan tujuan yang akan di capai dalam pembuatan project tersebut. Requirement and Architecture (persyaratan dan arsitektur) yakni harus dapat menjelaskan apa saja yang diinginkan dan diperlukan oleh user. Untuk itu diperlukan adanya psroses klarifikasi, perbaikan, penentuan kelengkapan, dan ruang lingkup. Sebagai masukannya dapat berupa dokumen persyaratan dan keluarannya adalah ketetapan persyaratan. Terdapat bermacam-macam persyaratan yang dapat dihasilkan :
· Fungsional : menjelaskan tentang apa saja yang dapat dilakukan oleh system
· Non fungsional : dapat berupa ukuran memori, jangka waktu respon.
· Data : data apa saja yang perlu disimpan dan bagaimana penyimpanannya.
Detailed Design yakni memperincikan desain sebuah aplikasi yang akan dibuat.
Selanjutnya setelah Project tersebut telah ditetapkan maka Diimplementasikan lah atau di jalankan. Selanjutnya dalam tahap Project Test and Integration aplikasi/software yang telah dilakukan Integration test and Verification yang mana dalam tahap ini aplikasi yang telah diimplementasikan di lakukan verifikasi atau ditinjuau kegunaan nya apakah sesaui dengan kebutuhan user.
Selanjutnya Operation and Maintenance yakni melakukan perbaikan atas apa yg telah di verifikasi dan di sesuaikan dengan kebutuhan user. Dan pada akhirnya dalam model ini akan dilakukan proses Verivikasi dan Validitas kepada user apakah sudah bekerja sesuai dengan yang diharapkan dan apakah rancangan sesuai dengan apa nyang diinginkan