Yazılım Sürecinde İnsan Bilgisayar Etkileşimi Bölüm 6 Yazılım Sürecinde İnsan Bilgisayar Etkileşimi

Konu Başlıkları Yazılım mühendisliği ve etkileşimli sistemler için tasarım süreci Usability engineering Iterative design and prototyping Design rationale

Yazılımın Yaşam Döngüsü Tasarımın başlıca amacı etkileşimli sistemlerin başarılı ve kullanılabilir olarak tasarlanabilmesi için güvenilir teknikler geliştirmektir. Yazılım mühendisliği, yazılımın tasarım sürecini ya da yaşam döngüsünü anlamayı sağlayan bir disiplindir. Bir sistemin kullanılabilirlik (usability) için tasarlanması yaşam döngüsünün belli bir evresi yerine tüm evrelerini içerir.

Yazılımın Yaşam Döngüsü Bir sistemin tasarımında iki ana taraf vardır. Bunlardan birisi kullanıcı diğeri ise tasarımcıdır. Tasarım sürecinde her iki tarafın üstlendiği roller farklıdır. Genellikle her iki tarafı farklı kişiler temsil eder.

The waterfall model Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance

Yaşam Döngüsünün Aşamaları Gerekenlerin Belirlenmesi Tasarımcı ile kullanıcı tasarımı yapılacak sistem ile ilgili beklentileri kararlaştırırlar.Beklentiler sadece sistem ile ilgili değil aynı zamanda çalışacağı ortam ile ilgilidir. Beklentilerin kararlaştırılması kullanıcının dilinde yapılır. Tasarım sırasında ise matematiksel dil yapısında olan yazılım diline çevrilir. Bu çevirim başarılı tasarımın anahtarıdır. Mimarisel Tasarım Sistem için gerekli olan servisler, bileşenler, fonksiyonel ve fonksiyonel olmayan ihtiyaçlar belirlenir. Bu kısım yazılım mühendisliği alanına girmektedir. Detaylandırılmış Tasarım Mimarisel bileşenler ve bileşenler arası ilişkiler gözden geçirilerek geliştirilir. Mimarisel bileşenlerin geliştirilmesinde birden çok seçenek vardır. Bunlar arasıdan en iyisinin seçilmesi sistemin fonksiyonel olmayan gerekliliklerinin sağlanmasıyla mümkündür.

Yaşam Döngüsünün Aşamaları Kodlama ve Bileşenlerin Test Edilmesi Detaylandırılmış tasarımdan sonra şimdiye kadar yapılanlar programlama diliyle ifade edilir. Çalıştırılabilir programlama diline çevrilir. Buna kodlama denir. Kodlamadan sonra bileşenlerin doğru ve istenildiği kriterlerde çalışıp çalışmadığı test edilir. Bütünleştirme ve Test Edilmesi Bileşenler kodlandıktan ve test edildikten sonra mimarisel tasarımla bütünleştirilmesi gerekir. Bu aşamadan sonra bileşen istenildiği gibi çalışıp çalışmadığı ve kabul edilebilir olup olmadığı açısından test edilir. Düzeltme Bu aşamada sistemde var olan ve şimdiye kadar yapılan aşamalarda gözden kaçan hatalar düzeltilir. Sistem ve bileşenlerinin revizyonu yapılır. Düzeltme aşaması yaşam döngüsündeki diğer aşamalara geri besleme (feedback) sağlamaktadır.

Verification and validation Real-world requirements and constraints The formality gap Yaşam döngüsü boyunca sistemin hem kullanıcının isteklerine cevap vermesi hem de tamamlanmış ve içsel tutarlığı sağlıyor olması gerekir. Bu şartların kontrolü verification ve validation ile sağlanır. Verification Ürünün doğru ve düzgün olarak tasarlanmasıdır. Genellikle tek yaşam döngüsünde veya ardışık iki aktivite arasında meydana gelir.Örnek olarak detaylandırılmış tasarım aşamasında tasarımcının algoritmada ki bir yanlışlığı düzeltmesi gibi. Verification’nın ispatı matematiksel dilin yapısına ve semantic’ine dayandığı için formal olarak yapılabilmektedir. Validation Ürünün kabul edilebilir olarak tasarlanmasıdır. Validation verification’a göre daha özneldir. Validation’ın ispatı iki dilin birbirine dönüşümünü kapsar. Validation’ın temelinde kullanıcının gerçek dünya ile ilgili gereklilikleri vardır. Bu gereklilikler matematiksel dünya da bulunmamaktadır. Bu nedenle gerçek dünyanın informal durumları tam olarak formal hale dönüştürülememektedir. Bu durum The formality gap olarak isimlendirilir. The formality gap validation’ın ispatının nesnel olarak belli bir ölçüde yapılmasına dayanır.  

Yönetimsel ve Anlaşımsal (contractual) Sonuçlar Programın bitirileceği zaman, Ekonomik harcamalar, Personelin eğitim ihtiyacı, Kullanıcı ile tasarımcı arasında imzalanan anlaşmayı içerir. Kullanıcı ile tasarımcı arasında anlaşma imzalanması hukuki açıdan yarar sağlasa da etkileşimli sistemlerin tasarımında esneklik açısından zorluk yaşanmasına neden olabilir.

Etkileşimli Sistemler için Yaşam Döngüsü The waterfall modelindeki gibi aktivite sırasında lineer bir akış beklenmemelidir. İterative’dir. Bir aşama diğerini etkiler. Bir çok geri besleme (feedback) vardır. Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance

Usability engineering Mühendislik kodlama, amaçları gerçekleştirme ve memnun edici bir şekilde sistemi nasıl tamamlayacağına karar vermektir. Usability mühendisliği ürünün tasarımında usability için hangi kriterlerin uygulanacağının bilinmesidir. Ürünün usability testi tamamen kullanıcının tecrübesinin ölçümüne dayanmaktadır. Yazılımsal yaşam döngüsü usability mühendisliğine, usability spesifikasyonlarının, gerekliliklerin ve sistemin usability’sine katkı da bulunmak için kullanıcı-sistem etkileşiminin özeliklerinin belirlenmesinde katkı da bulunur.

Usability specification measuring concept: Backward recoverability tanımlanmıştır. measuring method: Attribute’ın nasıl ölçüleceği ile ilgilidir. Bu durumda kullanıcıların hangi programlama sırasında olduklarına bakılmadan dışarıdan bir çok kullanıcının işlemini iptal etmesinin gerekliliğin içerir. now level: Bilgisayar tabanlı olsun ya da olmasın var olan sistemin ölçülen değeridir. worst case: Bir görev için ölçülen kabul edilebilir en düşük değerdir. Son üründe neyin kabul edilip neyin edilemeyeceği ile ilgili net bir ayırım yapılmasını sağlar. planned level: Tasarım için hedeflenendir. best case: Geliştirilen araçlar ve teknoloji için ölçülen en iyi değerdir.

part of a usability specification for a VCR Attribute: Backward recoverability Measuring concept: Undo an erroneous programming sequence Measuring method: Number of explicit user actions to undo current program Now level: No current product allows such an undo Worst case: As many actions as it takes to program-in mistake Planned level: A maximum of two explicit user actions Best case: One explicit cancel action

ISO usability standard 9241 Genel olarak kullanılan usabilty kategorileri: effectiveness Yapmak istediğini başarabildin mi? efficiency Yapacağın işlemi boşa çaba sarf etmeden yapabildin mi? satisfaction Süreçten eğlendin mi?

some metrics from ISO 9241 Usability Effectiveness Efficiency Satisfaction objective measures measures measures Suitability Percentage of Time to Rating scale for the task goals achieved complete a task for satisfaction Appropriate for Number of power Relative efficiency Rating scale for trained users features used compared with satisfaction with an expert user power features Learnability Percentage of Time to learn Rating scale for functions learned criterion ease of learning Error tolerance Percentage of Time spent on Rating scale for errors corrected correcting errors error handling successfully

Usability Mühendisliği İle İlgili Problemler Usability metrics, çok belirgin durumlarda çok belirgin kullanıcı aktivitelerini ölçer. Tasarımcı ne zaman hangi eylem ya da durumun olacağını bildiği zaman, amaçlarını gözlemlerine göre belirler.

Iterative design and prototyping Iterative tasarım, tamamlanmayan gerekliliklerden doğan mirassal problemlerin üstesinden gelmektedir. Iterative tasarım prototype kullanımı ile sağlanır. Prototypes: Sistem ile ilgili bazı özellikleri görselleştirir. Çeşitleri: throw-away: Bu prototype oluşturup ve test eder. Son ürünü oluşturduktan sonra gerçek prototype’ı yok ediyor. Final requirements’a gelindiğinde tasarım sürecinin kalınına devam ediliyor. Incremental:Son ürün ayrı bir bileşen olarak oluşturulmuş. Son sistem için bileşenlerin birbirinden bağımsız ve küçük olduğu ayrıntılı tasarım yapılmış. Evolutionary:Bu prototype’da yok etme bulunmamaktadır. Her bir aşama tasarımın diğer iterasyonları için temel oluşturur.

Management issues Zaman: Prototype oluşturmak zaman almaktadır ve eğer prototype olarak thow away kullanılırsa real design task’a kadar bir çok değerli zaman boşa harcanmış olur. Prototype’in değeri hızlı olmasına bağlıdır. Protoype’ın hızlı oluşturulması yanlış ve hatalı durumlara yol açmamalıdır. Planlama: Çoğu proje yöneticisinin prototype’ı da içeren tasarım süreci ile ilgili planlama ve ödemeler konusunda tecrübesi bulunmamaktadır. Fonksiyonel olmayan özellikler: Güvenlik ve güvenirlik gibi fonksiyonel olmayan özellikler genellikle prototype hazırlanırken göz ardı edilir. Prototype’ın özelliklerinin kullanılabilirliği değerlendirilirken ürünün kabulü ile ilgili problem çıkabilmektedir. Contracts: Tasarım sürecinin bütünü için kullanıcı ile tasarımcı anlaşma imzalanmaktadır. Fakat prototype için böyle bir anlaşma imzalanmamaktadır. Anlaşma olmadığı için küçük değişiklikler prototype’larda çok hızlı değiştirilebilirken aynı durum tasarımın geneline uygulanamamaktadır.

Techniques for prototyping Storyboards Prototype hazırlanmasında kullanılan en basit tekniktir. Oluşturulmasında bilgisayarın kullanılması gerekmemektedir. Storyboard’ların temelinde film endüstrisi bulunmaktadır. Storyboardlar etkileşimli sistemlerin tasarımında etkileşimi artırmak amacıyla ara yüzde kullanılabilmektedir. Gelişen teknoloji ile storyboard’lar el yerine bilgisayar kullanılarak tasarlanabilmektedir. Limited functionality simulations Hyper Card sistem için grafiklerin oluşturulduğu animasyon araçlarıdır. Aynı zamanda HyperTalk Programlama ile yazılan script’leri birleştirerek etkileşim oluşturabilmektedir. Simülasyon için diğer bir teknikte Wizard of Oz’dur. Bu teknikten yararlanarak tasarımcılar sınırlı sayıda fonksiyonlara sahip prototype’lar oluşturabilir.

Techniques for prototyping High Level Programming Hyper talk özel amaçlar için kullanılan yüksek seviyeli programlama dilidir.Tasarımcı bu dili kullanarak cevap hızını ve boşluk etkinliği gibi özellikleri kolaylıkla programlayabilir. Etkileşimli sistem tasarımının zor taraflarından bir tanesi donanımın kontrol edilmesidir. Yüksek seviyeli programlama dilleri kullanıcıya bu açıdan kolaylık sağlar. Kullanıcı arayüzü yönetim sistemi (UIMS) yüksek seviyeli programlamayı destekler.

Iterative Tasarım ile İlgili Uyarılar Iterative tasarımda proje teslim zamanını aşmadan hızlı prototype tasarlanması, değerlendirilmesi ve modifiye edilmesi ideal olandır. Fakat iki problem ile karşılaşabiliriz: Prototype sürecinin çok başında tasarım kararının alınması yanlıştır. Değerlendirme sürecinde tasarımın kullanımı ile ilgili bir sorun çıkarsa, önemli olan bu sorunun kaynağını anlamaktır.

Design rationale Design rationale bilgisayar sisteminin tasarım için neden bir yol olduğunun bilgisidir. Yapısal, mimarisel, fonksiyonel veya davranışsal desciption’ları içerir.Design rational yaşam döngüsü boyunca oluşan yansıma ve dokümantasyon ile ilişkilidir.Design rationale çok büyük ve tasarım alanının zaman içerisindeki değişimini açıklayan kompleks bir sistemdir. Design rationale’ın faydaları: Yaşam döngüsü yoluyla iletişimi sağlar Ürünler arası bilginin tasarım için tekrar kullanımını sağlar. Tasarım için kararların daha dikkatli verilmesi için tasarımcıları zorlar. Alternatiflerin değerlendirilmesinin doğr biçimde yapılmasını sağlar. Geniş tasarım alanlarını organize eder. İçeriksel bilgiyi yakalar.

Design rationale Design Rational çeşitleri: Process-oriented Dağıtım ve karar verme sırasını muhafaza eder (preserve). Structure-oriented Düşünülen tasarım alternatiflerinin post hoc yapısını vurgular. Örnek: Issue-based information system (IBIS) Design space analysis

Issue-based information system (IBIS) Design rationale’da yapılan çoğu işin temelinde IBIS(Issue Based Information System) vardır. Temel elemanları: issues – Bir kök issue ile ilgili hiyerarşik yapıdır. positions – Bir issue’nın potansiyel çözümleridir. arguments Pozisyonlar ile issues arasındaki ilişkinin modifiye edilmesidir. gIBIS grafiksel versiyonudur.

structure of gIBIS Sub-issue Issue Position Argument supports responds to objects to supports questions generalizes specializes

Design space analysis QOC – hierarchical structure: MacLean ve meslektaşı tarafından space tasarım alternatiflerinin post hoc yapısının vurguladığı sorular, seçenekler ve kriterlere dayalı bir yaklaşımdır. QOC – hierarchical structure: questions (and sub-questions) – Tasarımın büyük issue’larını temsil eder. options – Sorulara alternatif çözümler sağlar. criteria – Seçim yapmak için seçeneklerin değerlendirilmesi anlamına gelir. Decision Representation Language (DRL) – QOC benzer yapıdadır fakat daha geniş ve daha formal semantic yapıda bir dildir.

the QOC notation Criterion Option Question Option Criterion Option … Consequent Question … Question

Psychological design rationale Kullanıcılar için hangi işlemi gerçekleştireceğini anlayan dışsal bir tasarım yapmayı amaçlar. Psychological design rationale’ı ilk aşaması sistemin önerdiği ve kullanıcının cevaplarını doğru bir şekilde vermeye çalıştığı sorularla karakterize ettiği task’ın belirlenmesidir. scenarios task’ın test edilmesini önerir. Kullanıcılar sistem üzerinde gözlemlenirler. Sistem psikolojik ideaları explicit olarak yapar. Tasarımın olumsuz tarafları tasarımın diğer bir versiyonunu geliştirmek için kullanılır.