yazilim sÜrecİnde İnsan bİlgİsayar etkİleŞİmİ & tasarim ... · •kullanılabilirlik...
TRANSCRIPT
20.10.2012
1
YAZILIM SÜRECİNDE İNSAN BİLGİSAYAR ETKİLEŞİMİ &
TASARIM KURALLARI
2012
NİHAT KISACIK-2008639031 TAYFUN COŞKUN-2009639061
YAZILIM SÜRECİNDE İNSAN BİLGİSAYAR ETKİLEŞİMİ
• Genel Kavramlar; • Yazılım mühendisliği, tasarım sürecinin yapısının
anlaşılmasını ve bu tasarım sürecinin etkileşimli sistem tasarımı içerisindeki etkinliğini belirlemeye çalışır.
• Kullanılabilirlik mühendisliği, genel olarak insan bilgisayar etkileşimi, özel olarak yüksek kullanılabilirliğe sahip kullanıcı dostu insan bilgisayar ara yüzlerinin tasarımında baz alınacak kriterlerin belirlenmesiyle ilgilenen bir alandır.
• Genel Kavramlar; • Tasarım mantığı ; tasarım mantığı, bilgisayar sistemi
tasarımında yapısal ya da mimarisel ve işlevsel ya da davranışsal olarak neden böyle bir yol izlendiğinin bilgisidir.
• Müşteri (Customer) ; Ürünle ilgili istekleri belirleyen kişi/grup
• Tasarımcı (Designer); Ürünü geliştirmekle sorumlu kişi/grup
Konu Başlıkları; 1. Yazılım Yaşam Döngüsü
2. Kullanılabilirlik Mühendisliği
3. Yinelemeli Tasarım ve Prototiplendirme 4. Tasarım Mantığı
• Yazılım yaşam döngüsü, yazılım geliştirme sürecindeki aktiviteleri belirleme girişimidir.
• Bir yazılım ürünün gelişimde; ürün ile ilgili
gereksinimleri belirleyen müşteri ve ürünü tedarik eden tasarımcı olmak üzeri 2 temel öğe vardır.
• Ayrıca, tasarım şirketinden ürünü talep eden müşteri ile ürünün nihai kullanıcısı olan müşterinin ayrımını yapmak çok önemlidir.
20.10.2012
2
• 1.1. Yazılım yaşam döngüsündeki aktiviteler;
Şekil 1: Şelale Modeli Aktiviteleri
Gereksinimleri belirleme
Mimari tasarım
Detaylı tasarım
Kodlama ve Birim testi
Tümleştirme ve Sistem testi
Kurulum ve Bakım
• 1. Basamak: Gereksinimleri Belirleme • Gereksinimlerinin belirlenmesi aşamasında,
tasarımcı ve müşteri nihai sistemden ne beklenildiği ile ilgili bir açıklama yakalamaya çalışır.
• Bu daha sonraki aktivitelerde belirlenecek olan sistemin beklenen hizmetleri nasıl karşılayacağından sorusundan farklıdır.
• 1. Basamak: Gereksinimleri Belirleme
• Bu aşama; müşteriden nihai ürünün faaliyet göstereceği iş çevresi ya da alanı bilgisinin çıkarılmasını içerir
• Beklentilerin kararlaştırılması kullanıcının dilinde yapılır. Tasarım sırasında ise sistematik olarak yazılım diline çevrilir. Bu çevrim başarılı tasarımın anahtarıdır.
• 2. Basamak: Mimari Tasarım
• Mimari tasarımda sistemden beklenen görevlerin nasıl yerine getirileceği üzerinde durulur.
• Bu aşamadaki ilk aktivite sistemin yüksek bir seviyede bileşenlerine ayrıştırılmasıdır.
• 2. Basamak: Mimari Tasarım • Bu ayrıştırmada, sistem bileşenlerinin sağladığı
hizmetler gibi işlevsel gereksinimler kadar sistemin çalışacağı ortamdan kaynaklanan etkinlik, güvenirlik, süre kısıtlamaları gibi işlevsel olmayan gereksinimleri de dikkate almak gerekir.
• Mimari tasarımda sadece sistem bileşenlerinin hangi hizmetleri sunacağı değil, ayrıca ayrı bileşenler arasındaki etkileşimler ve paylaşılacak kaynaklar da belirlenir.
• 3. Basamak: Detaylı Tasarım
• Mimari tasarımda belirlenen bileşenlerin gerçekleştireceği görevlerin detaylandırılmasıdır.
• Detaylı tasarımda sistem bileşenlerin özellikleri bir
programlama dilinde tasarlanacak kadar detaylandırılmalıdır.
• Birçok detay tasarım modeli arasından fonksiyonel olmayan gereksinimleri de karşılayan detay tasarımı seçmek uygun olacaktır.
20.10.2012
3
• 4. Basamak: Kodlama ve Birim Testi
• Sistemin bileşenlerinin detaylı tasarımının ardından sonra bileşenlerin gerçekleştirdiği görevler işletilebilir programlama dilinde ifade edilir buna kodlama denir.
• Kodlamanın ardından mimari tasarımda belirlenen test ölçütlerine göre bileşenin üstlendiği görevi doğru olarak yerine getirip getirmediği test edilir. (Birim Testi)
• 5. Basamak: Bütünleştirme ve Sistem Testi
• Her bir bileşen test edilip kendisinden beklenen görevi yeterli olarak yerine getirdiğinden emin olunduktan sonra tüm bileşenler mimari tasarımda belirtildiği gibi birleştirilir.
• Bir sonraki test, sistemin doğru olarak çalıştığını ve kaynakların uygun olarak paylaşıldığını anlamak için yapılır.
• Son sistemin bazı otoritelerce sertifikasyonu gerekebilir.
• ISO9241: ofis ortamlarındaki iş istasyonlarının kullanışlılık sertifikası
• 6. Basamak: Kurulum ve Bakım • Sistemin kabul testlerini geçişinden sonra gerçek
ortama kurulumu ve anlaşmalar çerçevesinde bakım aşamasına geçişi başlar.
• Ürünün teslim edilmesinden sonra, tasarımcıdan sistemin yeni bir versiyonun tasarlanması istenene ya da ürünün kullanımdan kademeli olarak çekilmesine kadar sistem ile ilgili tüm işler bakım kategorisi altında düşünülür.
• 6. Basamak: Kurulum ve Bakım
• 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.
• Yaşam döngüsünün büyük bölümü bakımdan oluşur.
1.2. Geçerlilik ve Doğrulama
• Yaşam döngüsü boyunca tasarımın hem kullanıcının isteklerine cevap vermesi hem de tamamlanmış ve içsel tutarlığı sağlıyor olması gerekir. Bu kontroller sırasıyla geçerlilik ve doğrulama olarak adlandırılır.
• Boehm, geçerlilik ve doğrulama arasındaki farkı kullanışlı bir tarifle özetlemiştir. Geçerlilik doğru şeyin tasarlanması; Doğrulama ise bir şeyin doğru tasarlanmasıdır.
1.2. Geçerlilik ve Doğrulama
• Doğrulama, genellikle tek yaşam döngüsünde veya ardışık iki aktivite arasında meydana gelir. Ürünün doğru ve düzgün olarak tasarlanmasıdır. Doğrulamanın ispatı matematiksel dilin yapısına ve anlamına dayandığı için formal olarak yapılmaktadır.
• Geçerlilik, ürünün kabul edilebilir olarak tasarlanmasıdır. Geçerlilik doğrulamaya göre daha özneldir. Geçerliliğin temelinde kullanıcının gerçek dünya ile ilgili gereklilikleri vardır.
20.10.2012
4
Formalite boşluğu
• Doğal dilde ifade edilen gereksinimlerin karşılanıp karşılanmadığını objektif olarak kontrol etmek çok zordur. Sonuç olarak, doğal dile özgü durumlarla, net ve planlanmış geliştirme süreci sonucunda oluşacak gerçek durumlar arasında mutlaka bir kayma olacaktır. = “formalite boşluğu”
Gerçek
gereksinimler ve kısıtlamalar
Formalite boşluğu
Yönetim ve Sözleşme konuları • Yazılım yaşam döngüsü daha çok yazılımın teknik
konularıyla ilgilenirken, zaman kısıtlamaları, ekonomiklik gibi tasarımın yönetimsel konuları bu süreç içerisinde çok da önemli değildir.
• Sistemin gelişimsel faaliyetleri dışında sistemin pazarlana bilirliği, personel eğitimi ve yeterlilik düzeyi gibi yönetimsel ihtiyaçlar daha geniş bir perspektifte ele alınmalıdır.
• Yönetim ve Sözleşme konuları -Programın bitirileceği zaman, -Ekonomik harcamalar, -Personelin eğitim ihtiyacı,
gibi kullanıcı ile tasarımcı arasında imzalanan anlaşma
kapsamındaki konuları 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 zorluk yaşanmaması için anlaşma konularında esneklik sağlanması fayda sağlar.
• Etkileşimli Sistemler ve Yazılım Yaşam Döngüsü
• Geleneksel yazılım mühendisliği yaşam döngüsü büyük yazılım sistemlerine bir zemin oluşturmak için 1960’larda ve 1970’lerde ortaya çıktı.
• 1970'lerin sonlarında kişisel bilgisayarın çıkması, geniş bir kitle tarafından kabul görmesi ve ardından gelen büyük ticari başarısıyla ; bugün herhangi bir sistemin başarısı için hayati önem taşıyan kolay kullanımlı daha modern ve daha etkileşimli sistemler geliştirilmeye başlandı.
• Etkileşimli Sistemler ve Yazılım Yaşam Döngüsü
• Tasarımların kullanışlılığının artırılması için;
– Sistem devingen geliştirilmeli ve kullanıcıların etkileşimi gözlemlenip değerlendirilmeli.
– Bu deneme ortamları gerçek ortama olabildiğince yakın olmalı.
• John Carroll: sistemin çok ince bir detayı kullanışlılığını
etkileyebilir. Bu yüzden, kaba tahminlerin gerçek ortamda çalışacak sistemin kullanışlılığına katkısı olmayacaktır
• Etkileşimli Sistemler için Yaşam Döngüsü
• Bir çok geri bildirim vardır.
Gereksinimleri belirleme
Mimari tasarım
Detaylı tasarım
Kodlama ve Birim testi
Tümleştirme ve Sistem testi
Kurulum ve Bakım
20.10.2012
5
• Kullanılabilirlik ????
– Bir uygulamada belirlenen işlerin kullanıcılar tarafından, gerekli eğitimin ve teknik desteğin verilmesinin ardından, uygun çevre koşullarında kolaylıkla ve etkili biçimde kullanılabilmesi olarak tanımlanabilmektedir .
Kullanılabilirlik mühendisliği; Bir ürünün kullanılabilirliğini değerlendirebilmek için hangi kriterler kullanılacak? sorusuna cevap arar.
• Geliştirilecek sistemin kullanılabilirliğini ölçebilmek için, kullanıcı-sistem etkileşimine yoğunlaşan “Kullanılabilirlik Şartnamesi” oluşturulur.
Video kaset kaydedici ile Geri alma işleminin örnek
kullanılabilirlik özellikleri
Özellik: Geriye dönük hata kurtarımı
Ölçülen davranış: Hatalı bir program akışını geri alma
Ölçüm metodu: Hatalı program durumunu geri alabilmek için gerekli
kullanıcı eylemi sayısı
Şu anki düzey: Şu anda bu işleve sahip bir ürün yok
En kötü durum: Hatadan kurtulabilmek için kaç adım gerekiyorsa
Planlanan düzey: En fazla 2 eylem
En iyi düzey: Tek bir vazgeçme işlemi
• ISO 9241 kullanılabilirlik standartları
- Etkinlik: Yapmak istediğini başarabildin mi?
- Verim: Yapacağın işlemi boşa çaba sarf etmeden yapabildin mi?
- Memnuniyet: Sürecin hoşnutluk düzeyi ne?
• ISO 9241 ‘ten bazı metrikler
Kullanılabilirlik Etkinlik Verim Memnuniyet kriterleri ölçümleri ölçümleri ölçümleri
Görev için Amaçların gerçekleşme Görevi zamanında Memnuniyet uygunluğu yüzdesi tamamlama için ölçüt
Yetkin personel Kullanılan etkili Uzman kullanıcıyla Güç özellikleri için uygunluğu özelliklerin sayısı karşılaştırıldığında için memnuniyet verimlilik düzeyi ölçeği
Öğrenilebilirlik Öğrenilen işlevlerin Öğrenme için Öğrenme kolaylığı yüzdesi gerekli zaman için ölçek
Hata toleransı Hataların başarıyla Hataları düzeltmek Hataları düzeltmek düzeltilme yüzdesi için harcanan zaman için ölçek
• Kullanılabilirlik testleri en uygun biçimde İnsan Bilgisayar Etkileşimi araştırmaları için kurulmuş olan laboratuvarlarda yapılmalıdır.
20.10.2012
6
• Kullanılabilirlik Mühendisliği ile ilgili problemler
• Deneyimler sonucu oluşan ve tasarım sürecinin başında
belirlenen metrikler. Gerçek ortamda uygulandığında farklı sonuçlar çıkabilir.
• Çok kısıtlı durumlar için çok kısıtlı kullanıcı davranışlarına dayanır.
• Kullanılabilirlik değil, geliştirilen bazı metrikler karşılanıyor aslında tasarımcı ne zaman hangi eylem ya da durumun olacağını kestiremeyebilir.
• Her geçişte son ürünün biraz daha olgunlaşması...
• Prototiplendirme türleri: – Atılacak (throw away);
• Geliştirilen bir prototip sonucu elde edilen tasarım bilgilerinden faydalanılır fakat geliştirilen prototip ilerki safhalarda kullanılmaz.
– Artırımlı (Incremental); • Son ürünle ilgili genel bir bakış açısı var. Her
yinelemede ayrı bir alt bileşen geliştirilir.
• Prototiplendirme türleri:
– Evrimsel (Evolutionary); • Prototip atılmaz, sonraki itarasyon bunun
üzerine inşa edilir. Son ürün, her itarasyonda biraz daha olgunlaşarak oluşur.
• Prototiplendirme etkileşimli sistemlerde de
gerçek kullanıcının yaklaşımlarını görebilmek açısından önemlidir.
• Prototiplendirme problemleri:
– Yönetici açısından; • Zaman kısıtı • Planlama güçlüğü • Fonksiyonel olmayan özellikler
prototiplendirmede genelde göz ardı edilir. • Sözleşmeler; prototipleme legal bir sözleşme
için temel olamaz. Prototiplendirme sonuçlarının bağlayıcılığı olabilmesi için dökümantasyonu sağlanıp anlaşılması gerekir.
Prototiplendirme Teknikleri
o Hikaye Kartları • Bilgisayar sisteminde olmayabilir. Sistemin akışının yada
etkileşim noktalarının hikaye edilmesi o Limitli işleve sahip simülasyonlar
• Uygulamanın çalışmasını daha iyi gösterebilir. Etkileşim fazladır.
o Üst düzey programlama desteği • UIMS(UserInterfaceManagementSystem), arka tarafta
işleyecek sistem işlevlerinden bağımsız ve sunum tarafının geliştirilmesi.
• Faydaları;
– Tasarım ekibinin verilen tasarım kararlarından, sebeplerinden, alternatiflerinden haberi olur.
– Bilgi birikimi sağlanır. Bir proje ekibinin karşılaştığı durumlar karşısında aldığı kararlar, bir başka ekibe yol gösterebilir.
– Bir tasarımın gerekçeleri ortaya konurken, üzerinde biraz daha düşünülmüş ve irdelenmiş olur.
20.10.2012
7
• HCI açısından faydaları;
– Tasarım alternatiflerinin karşılaştırılması ve seçim kriterlerinin paylaşılması.
– Tasarımcının herhangi bir şekilde göremediği çözüm alternatiflerinin ortaya çıkması sağlanabilir.
• Tasarım mantığı türleri;
Sürece odaklanan; – Rittel’in IBIS (issue-based information system) stili
temel (tasarım gösterimi & diyalog planlaması) – Tasarım toplantılarında, üzerinde durulan konular ve
alınan kararların kaydedilmesinde kullanılıyor. – Farklı ürünler için kullanılabilecek şekilde tasarım
bilgisinin genelleştirilmesinden ziyade, o ürüne özel karar sürecini kaydeder.
• Tasarım mantığı türleri;
Yapıya odaklanan;
– Bir tasarım projesindeki tasarım alternatiflerinin yapısallaştırılmasına vurgu yapar
– Yapıya odaklandığı için tasarım toplantısında sorulan soruların aynısı kullanılmak zorunda değil
– Anahtar; doğru soruların oluşturulması ve seçenekleri değerlendirebilmek için gereken doğru kriterlere karar verilmesi.(QOC notasyonu)
• Tasarım mantığı türleri; Psikolojik;
– Tasarımcıların sistemin desteklemesi gerektiğine inandıkları görevleri kaydedip, daha sonra bu görevleri yerine getirecek sistemi geliştirmeleri ile işler.
– Tasarımcılar sistem kullanıcılarının gözlemlenmesinde kullanılacak görevler için bir takım senaryolar önerirler.
– Kullanıcı gözlemleri, sistemin o versiyonunun gerçek tasarımı için gereken bilgiyi sağlar.
– Tasarımcının önemli görevlerle ilgili varsayımlarının sonuçları, gerçek kullanıma karşı değerlendirilerek, tasarımı şekillendirme ve geliştirme önerilerinde kullanılır
TASARIM KURALLARI Tasarım Kuralları
Otorite Genelleme
20.10.2012
8
Tasarım kuralları, tasarımcıya hazırladığı yazılım ürününün kullanılabilirliğini arttırmada yardım eden kurallardır. Bu kuralları iki boyutta ele alınır: otorite ve genelleme.
• Otorite ile, tasarımda hangi kuralların takip edilip edilmeyeceği ya da hangilerinin önerildiği ifade edilir.
• Genelleme ile ise, kuralın hangi tasarım durumlarında uygulanıp uygulanmayacağı ya da daha sınırlı uygulama durumlarında kullanılıp kullanılmayacağı anlatılır.
3 tip tasarım kuralı vardır:
1. İlkeler (Principles) soyut tasarım kurallarıdır, yüksek genellenebilirlikleri
ve düşük otoriteleri vardır
2. Standartlar (Standards) spesifik tasarım kurallarıdır, yüksek otoriteli ve
uygulamada sınırlıdırlar
3. Rehberler (Guidelines) otoritede düşük olma eğilimindedirler ve uygulamada
daha geneldirler.
KULLANILABİLİRLİĞİ DESTEKLEYEN İLKELER
1. Öğrenilebilirlik (Learnability): Yeni kullanıcıların etkili etkileşime başlamaları ve
maksimum performans göstermeleri kolaylığıdır
2. Esneklik (Flexibility): Kullanıcı ve sistemin bilgiyi değiş-tokuş edebilecekleri
yolların çokluğudur
3. Sağlamlık (Robustness): Kullanıcıya hedeflerin başarılı bir şekilde
gerçekleştirilmesinde ve değerlendirilmesinde sağlanan destektir
Öğrenilebilirlik
• Öğrenilebilirlik, etkileşimli sistemlerde acemi kullanıcıların ilk başlangıçta sistemi nasıl kullanacaklarını anlamalarıyla ve sonra da nasıl daha yüksek performans gösterebilecekleriyle ilgili özelliklerdir. Öğrenilebilirlik beş ilkeyi içerir: – Tahmin edilebilirlik (Predictability) – Sentezlenebilirlik (Synthesizability) – Aşinalık (Familiarity) – Genellenebilirlik (Generalizability) – Tutarlılık/Uyum (Consistency)
Tahmin edilebilirlik (Predictability) Kullanıcının etkileşim bilgisin, gelecekteki etkileşim
sonuçlarını belirlemeye yeterli olmasıdır. Yani kullanıcının gelecekteki hareketlerini belirlemek geçmiş etkileşimine dayanır.
Sentezlenebilirlik: Kullanıcının eskiden yaptığı işlemlerin o anki durumunu
etkilediğini anlayabilme yeteneğidir. Aşinalık: Yeni bir kullanıcı için, etkileşimli bir sistemin aşinalığı
kullanıcıda var olan bilgiler ile etkili bir etkileşim için gerekli bilgi arasındaki ilişkinin ölçülmesidir.
Genellenebilirlik:
Kullanıcının spesifik bir etkileşim bilgisini benzer durum ya da durumlar için kullanmasıdır.
Tutarlılık/Uyum:
Benzer durum ya da görevlerin birbirlerine benzer olmalarıdır. “Tutarlı olun!”. Tasarımda çok geniş kullanım alanı olan bir ilkedir.
20.10.2012
9
Esneklik (Flexibility)
Kullanıcı ve sistemin bilgiyi değiş-tokuş edebilecekleri yolların çokluğudur. – Diyalog İnisiyatifi (Dialogue initiative) – Çoklu İşbölümü (Multi-threading) – Görev Geçişgenliği (Task migratability) – Yerine Geçebilirlik (Substitutivity) – Uyarlanabilirlik (Customizability)
Diyalog İnisiyatifi : Sistemle kullanıcı arasındaki etkileşim başladığında,
eşlerden hangisinin diyalogda inisiyatif sahibi olduğudur.
System pre-emptive: Sistem diyalogu başlatır ve kullanıcının bilgiye
ulaşması için talepte bulunması gerekir. User pre-emptive: Kullanıcı sisteme karşı herhangi bir fiilde bulunmakta
serbesttir. Çoklu İşbölümü (Multi-threading) Sistemin, kullanıcının aynı anda birden fazla görevle
etkileşimini destekleyebilme yeteneğidir
Görev Geçişgenliği (Task migratability):
Sistem ve kullanıcının task uygulamalarının birbirlerine verilmesi sorumluluğudur. Otomatik pilota geçme gibi
Yerine Geçebilirlik (Substitutivity):
Birbirlerine eşit olan giriş ve çıkış değerlerinin, birbirleri yerine geçebilmesidir. Çizgi çizip, uzunluğun program tarafından verilmesi ya da koordinatların verilip, çizginin program tarafından çizilmesi.
Uyarlanabilirlik (Customizability): Kullanıcı ara yüzünün kullanıcı tarafından
programlama bilgisi dahilinde (adaptability) ya da sistem tarafından (adaptivity) değiştirilebilmesidir.
Sağlamlık (Robustness)
Kullanıcıya hedeflerin başarılı bir şekilde gerçekleştirilmesinde ve değerlendirilmesinde sağlanan destektir.
Gözlenebilirlik (Observability) Geri alıp-düzeltilebilirlik (Recoverability) Görev Uyumu (Task conformance) Yanıt Verme (Responsiveness)
Gözlenebilirlik: Kullanıcıya sistemin iç durumunu değerlendirme
izninin verilmesidir. Browsability: Sistemin geçerli iç durumunun ara
yüzün sınırlılığı ile araştırılma imkanının sağlanmasıdır Defaults: Kullanıcının hata yapmasını önlemeye
yöneliktir Reachability: Kullanıcının verilen herhangi bir
sistemden diğer herhangi bir sisteme geçiş yapabilmesidir
Persistence: İletişimin etkisinin devamlılığı ve kullanıcının bu etkiyi kullanabilmesidir
Operation visibility: Kullanıcının bir sonraki işlemde nasıl bir performans gösterebileceğidir
Geri alıp-düzeltilebilirlik: Kullanıcının yaptığı hatayı geri alıp
düzeltebilmesidir. İleri – geri tuşları Forward-Backward: Metin editörlerinde bir hata
durumunda işlemi geri adımlamak için undo komutunu tetikleyen buton kullanabilir. Adımlama ileriye doğru da olabilir.
Reachability: Düzeltilebilirlik erişilebilirlikle
ilgilidir. Kullanıcıya mevcut durumundan hedeflediği bir duruma geçebilmesine imkan tanınmasıdır.
20.10.2012
10
Görev Uyumu: Sistem hizmetlerinin kullanıcının işlemlerinin
tümünü destekleme derecesidir. Görevlerin tamamlanabilmesi için sistem ara yüzlerinin anlaşılır olması gerekir.
Yanıt Verme: Kullanıcı ile sistem arasındaki iletişimin
(communication) oranıdır.
Cevap verme zamanı: Sistemin kullanıcıya durum değişikliğini bildirene kadar geçen zamandır.
İstikrar: Aynı / Benzer durumlardaki değişmezliğin sürdürülmesidir.
STANDARTLAR
Standarts
Underlying Theory
Change
Underlying Theory:
Donanım için kullanılan standartlar ergonomi/insan faktörü ve psikolojiye dayanır, iyi bilinirler ve donanım tasarımına kolayca uyarlanabilirler.
Yazılım standartları ise psikolojiye ve bilişsel bilime dayanırlar, nispeten daha az bilinirler ve yazılıma uyarlanmaları kolay değildir.
Change:
Donanımın güncellenmesi yazılıma göre daha pahalı ve daha zordur. Donanım için değişiklik isteği yazılımdaki gibi sıklıkla ortaya çıkmaz. Standartlar nispeten sabit olduklarından dolayı yazılımlardan çok donanımlar için uygundurlar.
ISO 9241’de kullanışlılık
etkililik, yeterlilik, memnuniyet ile kullanıcıların belirli çevrelerde hedeflerini başarmaları
şeklinde tanımlanmıştır.
Etkililik: Doğruluk ve tamlık (eksiksizlik) ile kullanıcıların belirli çevrelerde hedeflerini başarmaları
Yeterlilik: Kaynakların, hedeflerin doğru ve eksiksiz olarak başarılmasına yönelik harcanması
Memnuniyet: Kullanıcı ve o sistemin kullanılmasından etkilenen insanlar için sistemin konfor ve kabul edilebilirliği
YÖNERGELER
Yönergeler otoritede düşük olma eğilimindedirler
ve uygulamada daha geneldirler.
Daha genel ve daha öneri şeklindedirler.
Tasarıma başlamadan önce tasarımcıya fikir
verme amaçlıdırlar.
Birçok rehber bulunurken bunlara en tipi örnek Smith ve Mosier tarafından ortaya konmuştur. Bu rehber temel kategorileri şunlardır:
Veri girişi
Veri görüntüleme
Dizi kontrolü
Kullanıcı rehberliği
Veri aktarımı
Veri koruma
20.10.2012
11
Shneiderman’ın 8 Altın Kuralı
Tutarlılık için gayret etmek Kullanıcılara sık kullandıkları eylemlere yönelik
kısayol / macro / tuş kombinasyonları sağlama ve kullanma imkanı verme
Bilgilendirici geri dönütler sunma Bir görevi tamamlayan kullanıcıya bilgilendirici
diyaloglar tasarlamak Hataların önlemesi ve basit hataların yönetilmesi Hareketlerin kolayca geri alınmasına izin vermek İç kontrolün desteklenmesi Kısa süreli hafıza yüklemesini azaltmak
Ben Shneiderman
Norman’ın 7 Kuralı
Kafanızdaki ve çevrenizdeki bilgileri birlikte kullanmak Görevlerdeki yapıyı basitleştirme (Yüksek düzeyli bellek yüklemesinden ya
da karmaşık problem çözme becerilerinden kaçınmak için görev yapıları basitleştirilmelidir. Basitleştirme, zihinsel yardım sağlayarak, görevler hakkında daha fazla bilgi ve daha iyi dönütler veren teknolojiden yararlanılarak, görevi yada görevin bir bölümünü otomatikleştirerek ya da görevin doğasını değiştirerek yapılabilir.)
Nesneleri görünür yapma (Uygulama ile değerlendirme arasında bağlantı olmalıdır.)
Haritalamaları doğru yapma (Kullanıcının hareketleri sistem kontrollerinde ayrıntılarıyla planlanmalıdır. Böylece neyin ne kadar yapıldığı daha açık bir hale gelir.)
Hem doğal hem yapay sınırlamaların gücünden yaralanma. Hata için tasarım (Kullanıcıların yapmaları muhtemel hataları önceden
tahmin edip, sistem içinde geri almaları da tasarlamak gerekir.) Ara yüzde küçük farklılıklar olabilir ama kritik kontrol öğeleri herkesin
alışageldiği şekilde olmalıdır (otomobil örneği).
HCI Şablonları / Örüntüleri
Tasarıma başlamanın bir yolu daha önce başarısını kanıtlamış örneklerden yararlanmaktır yani bir sistem ya da paradigmayı başarılı kılan unsurları tekrar kullanmaktır.
Örüntü: Belirli bir kurala göre dizilmiş şekil veya sayı dizisidir. Örüntü yaklaşımında, başarılı tasarımların yeni durumlarda tekrar tekrar kullanılabilen temel bilgilerinin özetleri alınarak tekrar kullanılır.
Örüntüler, psikolojik teorilerden değil başarılı uygulamaların sonuçlarından üretilirler ve tasarımcıya bir şeylerin nasıl yapılacağını değil, nelerin neden yapılması gerektiğini anlatırlar.
TEŞEKKÜRLER