yazılım sürecinde insan bilgisayar etkileşimi

20.10.2012
YAZILIM SÜRECİNDE
İNSAN BİLGİSAYAR ETKİLEŞİMİ &
TASARIM KURALLARI
YAZILIM SÜRECİNDE
İNSAN BİLGİSAYAR ETKİLEŞİMİ
NİHAT KISACIK-2008639031
TAYFUN COŞKUN-2009639061
2012
• Genel Kavramlar;
• 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.
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
• 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
• 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.
4. Tasarım Mantığı
1
20.10.2012
• 1.1. Yazılım yaşam döngüsündeki aktiviteler;
• 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.
Gereksinimleri
belirleme
Mimari
tasarım
Detaylı
tasarım
• Bu daha sonraki aktivitelerde belirlenecek olan
sistemin beklenen hizmetleri nasıl
karşılayacağından sorusundan farklıdır.
Kodlama ve
Birim testi
Tümleştirme ve
Sistem testi
Kurulum ve
Bakım
Şekil 1: Şelale Modeli Aktiviteleri
• 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.
2
20.10.2012
• 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
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.
• 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.
3
20.10.2012
Formalite boşluğu
Yönetim ve Sözleşme konuları
• 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
• 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.
• Etkileşimli Sistemler ve Yazılım Yaşam Döngüsü
•
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.
• 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ı.
• 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ü
• Etkileşimli Sistemler için Yaşam Döngüsü
Gereksinimleri
belirleme
• 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
Mimari
tasarım
Detaylı
tasarım
Kodlama ve
Birim testi
• Bir çok geri bildirim vardır.
Tümleştirme ve
Sistem testi
Kurulum ve
Bakım
4
20.10.2012
• 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 .
• Geliştirilecek sistemin kullanılabilirliğini ölçebilmek
için, kullanıcı-sistem etkileşimine yoğunlaşan
“Kullanılabilirlik Şartnamesi” oluşturulur.
Kullanılabilirlik mühendisliği;
Bir ürünün kullanılabilirliğini
değerlendirebilmek için hangi kriterler
kullanılacak? sorusuna cevap arar.
• ISO 9241 kullanılabilirlik standartları
- Etkinlik: Yapmak istediğini başarabildin mi?
Ö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
- Verim: Yapacağın işlemi boşa çaba sarf etmeden
yapabildin mi?
- Memnuniyet: Sürecin hoşnutluk düzeyi ne?
Video kaset kaydedici ile Geri alma işleminin örnek
kullanılabilirlik özellikleri
• ISO 9241 ‘ten bazı metrikler
Kullanılabilirlik
kriterleri
Etkinlik
ölçümleri
Verim
ölçümleri
Memnuniyet
ölçümleri
Görev için
uygunluğu
Amaçların gerçekleşme
Memnuniyet
yüzdesi
tamamlama
Yetkin personel
için uygunluğu
Kullanılan etkili
özelliklerin sayısı
Uzman kullanıcıyla Güç özellikleri
karşılaştırıldığında için memnuniyet
verimlilik düzeyi
ölçeği
Öğrenilebilirlik
Öğrenilen işlevlerin
yüzdesi
Öğrenme için
gerekli zaman
Hata toleransı
Hataların başarıyla
düzeltilme yüzdesi
Hataları düzeltmek Hataları düzeltmek
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.
Görevi zamanında
için ölçüt
Öğrenme kolaylığı
için ölçek
5
20.10.2012
• 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
davranışlarına dayanır.
için
çok
kısıtlı
kullanıcı
• 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.
• 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 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.
• 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 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.
• 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.
6
20.10.2012
• Tasarım mantığı türleri;
• 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;
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)
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;
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
7
20.10.2012
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
Öğ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)
3. Sağlamlık (Robustness):
Kullanıcıya hedeflerin başarılı bir şekilde
gerçekleştirilmesinde ve değerlendirilmesinde
sağlanan destektir
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.
8
20.10.2012
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
Sağlamlık (Robustness)
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.
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
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)
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.
9
20.10.2012
STANDARTLAR
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.
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.
Standarts
Underlying
Theory
Change
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
10
20.10.2012
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
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).
Ben Shneiderman
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
11