MODEL DESAIN INTERAKSI
MODEL
BRAINSTORMING
Brainstorming adalah
teknik yang sangat berguna untuk mengembangkan solusi kreatif dalam
menghadapi sebuah permasalahan. Teknik ini cukup populer dan sering
digunakan dalam pekerjaan di kantor, juga dalam aktivitas keseharian
lainnya.
Brainstorming adalah proses berpikir lateral, mengajak setiap orang datang dengan ide-ide dan pemikiran yang terkesan gila dan tidak masuk akal pada awalnya. Namun, kemudian ide “gila” ini harus mampu diubah atau diperbaiki menjadi ide-ide yang bermanfaat.
Selama sesi brainstorming tidak boleh ada pihak yang mengkritik ide pihak lain. Hal tersebut sangat dikeramatkan karena sesi ini bertujuan membuka segala kemungkinan dan memecah anggapan yang keliru soal batasan masalah. Jika ide mulai “mengering”,
Anda dapat memancingnya dengan “kata acak”.
Ide-ide yang muncul hanya dievaluasi pada akhir sesi. Anda lalu dapat mencari pemecahan masalah yang lebih lanjut dengan menggunakan pendekatan konvensional.
Individual Brainstorming
Ketika melakukan brainstorming seorang diri (individual brainstorming), Anda cenderung menghasilkan banyak gagasan dibandingkan group brainstorming. Anda tidak perlu khawatir dengan ego ataupun pendapat orang lain, sebab itu Anda bisa lebih leluasa berkreasi dan berfantasi. Saat brainstorming sendiri, peta pikiran Anda dapat membantu mengatur dan mengembangkan ide-ide.
Group Brainstorming
Brainstorming secara berkelompok dapat menjadi sangat efektif karena menggunakan pengalaman dan kreativitas semua anggota kelompok. Ketika salah satu anggota mencapai batas idenya, kreativitas dan pengalaman anggota yang lain dapat melanjutkan dan membawa ke tahap berikut. Group brainstorming cenderung bermanfaat untuk menggali ide-ide secara mendalam daripada individual brainstorming.
Brainstorming dalam kelompok dapat berisiko bagi setiap individu. Ide yang berharga tapi aneh mungkin terdengar “bodoh” pada awalnya. Karena itu, Anda perlu sesi awal yang lebih intensif agar orang-orang yang sulit menerima ide-ide “di luar kotak” tidak merusak sesi brainstorming dan meninggalkan kesan memalukan bagi anggota kelompok lain di akhir sesi.
Untuk menjalankan sesi group brainstorming secara efektif, lakukanlah hal-hal berikut:
- tentukan secara jelas masalah yang ingin dipecahkan, dapat juga ditambah beberapa kriteria yang harus dipenuhi;
- arahkan setiap diskusi dan pendapat terpusat pada masalah yang hendak dibedah;
- pastikan tidak ada pihak yang mengkritik atau mengevaluasi ide-ide pihak lain selama sesi berlangsung. Kritik dapat menghambat seseorang untuk menyampaikan ide dan sarannya sehingga menghambat kreativitas dan melumpuhkan sesi brainstorming yang baik;
- mendorong antusiasme dengan cara mengajak semua orang berkontribusi dan mengembangkan ide, termasuk anggota yang paling diam di kelompok;
- ciptakan suasana menyenangkan pada sesi brainstorming. Dorong setiap anggota untuk datang dengan ide dan saran sebanyak mungkin. Mulai dari ide dan saran yang bersifat praktis maupun tidak, bahkan ide yang paling “liar” sekalipun;
- pastikan juga tidak ada rangkaian ide yang diikuti terlalu lama. Hal ini dapat membatasi ide dan kreativitas;
- mendorong anggota mengembangkan ide anggota lainnya, atau menggunakan ide-ide lain untuk menciptakan ide-ide baru;
- menunjuk satu orang untuk mencatat ide-ide yang keluar saat sesi berlangsung—cara yang baik adalah dengan menggunakan flip chart. Hal ini dapat dipelajari dan dievaluasi setelah sesi brainstorming berakhir.
Kesimpulannya, brainstorming adalah cara yang bagus untuk menghasilkan ide-ide radikal dan solusi-solusi “di luar kotak”. Selama proses berlangsung tidak boleh ada kritik terhadap gagasan yang dilontarkan oleh setiap anggota. Hal ini akan membuat sesi group brainstorming menyenangkan dan menciptakan semangat kebersamaan yang lebih kuat di dalam tim.
Individual brainstorming adalah sesi yang baik untuk menghasilkan banyak ide, tapi cenderung kurang efektif untuk dikembangkan karena hanya terpaku oleh satu kepala. Group brainstorming cenderung membahas ide yang lebih sedikit, tetapi setiap ide yang dibahas sangat mudah untuk dikembangkan karena banyak kepala yang ikut terlibat memikirkannya. Group brainstorming membutuhkan aturan formal dan kesepakatan bersama di awal sesi untuk kelancaran diskusi dan hasil yang optimal.
sumber: https://marketing.co.id/brainstorming-teknik-menghasilkan-ide-ide-radikal-dan-bermanfaat/
MODEL
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.
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:
- 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.
- Requirement: pada fase ini klien mendapatkan gambaran atau diminta memberikan gambaran kebutuhan yang diharapkan dapat dipenuhi oleh software, baik kebutuhan fungsional maupun non fungsional.
- 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.
- Perancangan Sistem: pada tahapan ini akan dibuat rancangan software secara lebih terinci sesuai spesifikasi yang sudah disepakati.
- Unit Design: merancang setiap elemen/unit software termasuk rancangan modul/program, antarmuka, database dan lain-lain.
- 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:
- Performance – apakah kinerja sistem sesuai dengan target yang sudah didefinisikan sebelumnya.
- Volume – apakah software/sistem dapat menampung volume informasi yang cukup besar.
- Stress – apakah software/sistem dapat menampung sejumlah informasi pada waktu-waktu tertentu.
- Documentation – apakah semua dokumentasi penting sudah disiapkan.
- 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.
Kekuranagn 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?
- Dalam proyek teknologi informasi di Jerman
- V Model dibandingkan dengan CMM
- V Model didesain untuk mengembangkan sistem yang didalamnya terdapat dua komponen
- Pengembangan V Model dalam bidang industri dapat dilakukan dengan muda
MODEL
WATERFALL
Sejarah Model Waterfall
Model Waterfall ini awalnya ditemukan oleh Winston W. Royce pada tahun 1970 . Dia menulis sebuah artikel ilmiah yang berisi pandangan pribadinya pada pengembangan perangkat lunak . Pada paruh pertama dari artikel, ia membahas sebuah proses yang dia sebut ” megah ” . Dia bahkan menggambar sosok model , dan lain yang menunjukkan mengapa hal itu tidak bekerja ( karena persyaratan selalu berubah ) . Model ini adalah air terjun . Dia menggunakannya sebagai contoh dari proses yang sama sekali tidak bekerja. Di paruh kedua artikel ia menggambarkan proses berulang-ulang bahwa ia dianggap jauh lebih baik .
Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini 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. Berikut gambar model waterfall.
Model Waterfall ini awalnya ditemukan oleh Winston W. Royce pada tahun 1970 . Dia menulis sebuah artikel ilmiah yang berisi pandangan pribadinya pada pengembangan perangkat lunak . Pada paruh pertama dari artikel, ia membahas sebuah proses yang dia sebut ” megah ” . Dia bahkan menggambar sosok model , dan lain yang menunjukkan mengapa hal itu tidak bekerja ( karena persyaratan selalu berubah ) . Model ini adalah air terjun . Dia menggunakannya sebagai contoh dari proses yang sama sekali tidak bekerja. Di paruh kedua artikel ia menggambarkan proses berulang-ulang bahwa ia dianggap jauh lebih baik .
Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini 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. Berikut gambar model waterfall.
Gambar:
Model Waterfall
Pengertian Waterfall
Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan.
Langkah-langkah yang harus dilakukan pada metodologi Waterfall
1. Requirement Analysis
Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.
2. System Design
Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.
3. Implementation
Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.
4. Integration & Testing
Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.
5. Operation & Maintenance
Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.
Keuntungan Waterfall
Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan.
Langkah-langkah yang harus dilakukan pada metodologi Waterfall
1. Requirement Analysis
Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.
2. System Design
Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.
3. Implementation
Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.
4. Integration & Testing
Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.
5. Operation & Maintenance
Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.
Keuntungan 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.
Kapan Model Waterfall digunakan?
Teori-teori lama menyimpulkan ada beberapa hal, yaitu:
Teori-teori lama menyimpulkan ada beberapa hal, yaitu:
- Ketika semua persyaratan sudah dipahami dengan baik di awal pengembangan.
- Definisi produk stabil dan tidak ada perubahan saat pengembangan untuk alasan apapun seperti perubahan eksternal, perubahan tujuan, perubahan anggaran atau perubahan teknologi. Untuk itu, teknologi yang digunakan pun harus sudah dipahami dengan baik.
- Menghasilkan produk baru, atau versi baru dari produk yang sudah ada. Sebenarnya, jika menghasilkan versi baru maka sudah masuk incremental development, yang setiap tahapnya sama dengan Waterfall kemudian diulang-ulang.
- Porting produk yang sudah ada ke dalam platform baru.
Dengan demikian, Waterfall dianggap pendekatan yang lebih cocok digunakan untuk proyek pembuatan sistem baru. Tetapi salah satu kelemahan paling dasar adalah menyamakan pengembangan perangkat keras dengan perangkat lunak dengan meniadakan perubahan saat pengembangan. Padahal, galat diketahui saat perangkat lunak dijalankan, dan perubahan-perubahan akan sering terjadi.
SUMBER: hudrindo77.blogspot.com/2014/12/pengertian-v-model.html
MODEL
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.
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 pun
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 pun
SUMBER:http://5000an.blogspot.com/2013/01/star-lifecycle-model.html
MODEL
SIMPLE INTERACTION DESIGN
MODEL WINOGRAD (1997)
- Pengertian Simple Interaction
- Prinsip User-Centered Design
- Fokus pada pengguna dan tugas
- Pengukuran empiris
- Desain Interatif
Penjelasan Tahapan dari model Simple Interaction:
- Mengidentifikasi kebutuhan dan persyaratan mendirikan untuk pengalaman pengguna
- Mengembangkan alternatif desain yang memenuhi persyaratan
- Membangun versi interaktif dari desain
- Mengevaluasi apa yang sedang dibangun di seluruh proses dan pengalaman pengguna yang menawarkan
SUMBER: http://imksemester5.blogspot.com/2015/11/simple-interaction-design-model.html
Tidak ada komentar:
Posting Komentar