İNSAN BİLGİSAYAR ETKİLEŞİMİ

... konulu sunumlar: "İNSAN BİLGİSAYAR ETKİLEŞİMİ"— Sunum transkripti:

1 İNSAN BİLGİSAYAR ETKİLEŞİMİ
YAZILIM SÜRECİNDE İNSAN BİLGİSAYAR ETKİLEŞİMİ Murat ÇINAR

2 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. 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. 2/40

3 YAZILIM SÜRECİNDE İNSAN BİLGİSAYAR ETKİLEŞİMİ
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 isterleri belirleyen kişi/grup Tasarımcı (Designer); Ürünü geliştirmekle sorumlu kişi/grup 3/40

4 YAZILIM SÜRECİNDE İNSAN BİLGİSAYAR ETKİLEŞİMİ
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ığı 4/40

5 YAZILIM YAŞAM DÖNGÜSÜ 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. Yazılımın hem üretim, hem de kullanım süreci boyunca geçirdiği tüm aşamalar yazılım geliştirme yaşam döngüsü olarak tanımlanır. 5/40

6 1.1. Yazılım yaşam döngüsündeki aktiviteler;
YAZILIM YAŞAM DÖNGÜSÜ 1.1. Yazılım yaşam döngüsündeki aktiviteler; Şekil 1: Şelale Modeli Aktiviteleri Gereksinimleri belirleme Mimari tasarım Detaylı Kodlama ve Birim testi Tümleştirme ve Sistem testi Kurulum ve Bakım Yazlımı yaşam döngüsünün daha detaylı tarifi şekil 1’de gösterilmiştir. Grafiksel gösterim, her bir aktivitenin doğal olarak bir sonrakine sürüklendiği bir şelaleye benzetilmiştir. Şelale benzeşimi, aktiviteler arasındaki gerçek ilgiyi tamamen yansıtmasa da aktivitelerin mantıksal akışı konuşmak için iyi bir başlangıç noktası sağlar. Bu nedenle yazılım yaşam döngüsünün bir şelale modeli şeklinde anlatılacaktır. 6/40

7 1. Basamak: Gereksinimleri Belirleme
YAZILIM YAŞAM DÖNGÜSÜ 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. 7/40

8 1. Basamak: Gereksinimleri Belirleme
YAZILIM YAŞAM DÖNGÜSÜ 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. 8/40

9 2. Basamak: Mimari Tasarım
YAZILIM YAŞAM DÖNGÜSÜ 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. Ayrıştırma var olan ya da sıfırdan bağımsız olarak geliştirilen bir yazılıma göre yapılabilir. 9/40

10 2. Basamak: Mimari Tasarım
YAZILIM YAŞAM DÖNGÜSÜ 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. 10/40

11 3. Basamak: Detaylı Tasarım
YAZILIM YAŞAM DÖNGÜSÜ 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. 11/40

12 4. Basamak: Kodlama ve Birim Testi
YAZILIM YAŞAM DÖNGÜSÜ 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) 12/40

13 5. Basamak: Bütünleştirme ve Sistem Testi
YAZILIM YAŞAM DÖNGÜSÜ 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ı Sistemin beklenen görevleri karşılayıp karşılamadığından emin olmak için sistemin kabul testleri müşteri ile birlikte yapılabilir. Sistemin kabul edilir biçimde entegrasyonun ardından ürün sonunda müşteriye sunulur. 13/40

14 6. Basamak: Kurulum ve Bakım
YAZILIM YAŞAM DÖNGÜSÜ 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. 14/40

15 6. Basamak: Kurulum ve Bakım
YAZILIM YAŞAM DÖNGÜSÜ 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. 15/40

16 1.2. Geçerlilik ve Doğrulama
YAZILIM YAŞAM DÖNGÜSÜ 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. 16/40

17 1.2. Geçerlilik ve Doğrulama
YAZILIM YAŞAM DÖNGÜSÜ 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. Ö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. Örneğin çalışanların ücret bordrosunu hesaplama sisteminin bir bileşenin detaylı tasarımında tasarımcının, çalışanların brüt maaşından düşecek vergileri hesaplamak için algoritmanın doğruluğunu sağlaması ve mimari tasarımda ise bu bileşene giren ve bu bileşenden çıkan bilginin genel özellikleri belirlenmesi doğrulukla ilgilidir. 17/40

18 Formalite boşluğu YAZILIM YAŞAM DÖNGÜSÜ
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 Formalite boşluğu, geçerlilik ispatının nesnel olarak belirli ölçülerde yapılamamasına dayanır. Formalite boşluğunu en aza indirebilmek için, geçerlilik denetiminde alan uzmanlarından faydalanılır. Alan uzmanının tasarım notasyonlarını bilmesi zorunlu değil. O yüzden, tasarımdaki ifadelerin, uzmanın değerlendirebileceği açıklıkta olması önemlidir. 18/40

19 Yönetim ve Sözleşme konuları
YAZILIM YAŞAM DÖNGÜSÜ 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 pazarlanabilirliği, personel eğitimi ve yeterlilik düzeyi gibi yönetimsel ihtiyaçlar daha geniş bir perspektifte ele alınmalıdır. Örnek olarak çok sayıda yazılım alt ünitesi olan bir uçak gelişimini ele alalım. Uçak şirketi, mevcut ürün gelişimiyle ilgili herhangi bir karar vermeden önce genellikle 10 yıla kadar olan kavram değerlendirme periyodunu gözden geçirir. Öncelikle hangi tip uçağın geliştirileceğine karar verilir. Yolcu uçağı tasarımı durumunda yolcu kapasitesi ve uçuş aralığı gibi esnek konuları daha açık tasarım aktiviteleri izler. Bu bağlantı analizleri, uçağın özellikleri ve eğitim ihtiyaçlarını içerir. uçağın mimari özellikleri tam olduktan sonra sistem gelişimi belirlenecektir.uçuş yönetim sistemi ya da eğitici simülatör yazılım yaşam döngüsünün daha erken evrelerinde tarif edildiği gibi dizayn edilmelidir. Tipik olarak bu 4-5 yıl sürer. Tasarım herhangi bir hava yolu şirketine teslim edilmeden önce ayrı olan yazılım sisteme entegre edilir hava ve yerdeki testleri yapılıp sertifikasyon sağlanır. Bir uçak modelinin işletme ömrü 20 ile 40 yıl arasındadır. Piyasadan çekilme ömrü ise 55 yılı bulmaktadır. Yazılım yaşam döngüsünde bahsedilen uygulamalar ise 4-5 yıllık zaman dilimini kapsamaktadır. 19/40

20 Yönetim ve Sözleşme konuları
YAZILIM 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. 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. 20/40

21 Etkileşimli Sistemler ve Yazılım Yaşam Döngüsü
YAZILIM YAŞAM DÖNGÜSÜ 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ı. O günlerde geniş ölçekli sistemler iş ortamında veri işleme uygulamaları dikkate alınarak üretiliyordu. Bu sistemler yüksek etkileşimli olmayan yığın işleme sistemleriydi. Sonuç olarak son kullanıcı açısından kullanılabilirlik ile ilgili konuların tümü önemli değildi. 21/40

22 Etkileşimli Sistemler ve Yazılım Yaşam Döngüsü
YAZILIM YAŞAM DÖNGÜSÜ 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 sistemlerin önem kazanmasından sonra Sutton ve Sprague’nin yaptığı bir araştırmaya göre (1978): tasarımcının zamanının yarısı kullanıcı ara yüzü tasarlamakla geçiyor. 22/40

23 Tümleştirme ve Sistem testi
YAZILIM YAŞAM DÖNGÜSÜ Etkileşimli Sistemler için Yaşam Döngüsü Bir çok geri bildirim vardır. Gereksinimleri belirleme Mimari tasarım Detaylı Kodlama ve Birim testi Tümleştirme ve Sistem testi Kurulum ve Bakım Şelale modelindeki gibi doğrusal bir akış beklenmemelidir. Süreç boyunca değişen şartlara uyum sağlayabilmek için yinelemeler vardır. Ve her aşama bir diğerini etkiler. 23/40

24 KULLANILABİLİRLİK MÜHENDİSLİĞİ
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 . 24/40

25 KULLANILABİLİRLİK MÜHENDİSLİĞİ
Kullanılabilirlik mühendisliği; Bir ürünün kullanılabilirliğini değerlendirebilmek için hangi kriterler kullanılacak? sorusuna cevap arar. 25/40

26 KULLANILABİLİRLİK MÜHENDİSLİĞİ
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 Bu değerler ve metodlar bir takım kullanılabilirlik metriklerinden faydalanılarak oluşturuluyor. Whiteside, Bennet ve Holtzblatt’ın ölçüm kriterleri listesi... 26/40

27 KULLANILABİLİRLİK MÜHENDİSLİĞİ
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? 27/40

28 KULLANILABİLİRLİK MÜHENDİSLİĞİ
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 28/40

29 KULLANILABİLİRLİK MÜHENDİSLİĞİ
Kullanılabilirlik testleri en uygun biçimde İnsan Bilgisayar Etkileşimi araştırmaları için kurulmuş olan laboratuarlarda yapılmalıdır. 29/40

30 KULLANILABİLİRLİK MÜHENDİSLİĞİ
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. 30/40

31 YİNELEMELİ TASARIM VE PROTOTİPLENDİRME
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. 31/40

32 YİNELEMELİ TASARIM VE PROTOTİPLENDİRME
Prototiplendirme türleri: Evrimsel (Evolutionary); Prototip atılmaz, sonraki iterasyon bunun üzerine inşa edilir. Son ürün, her iterasyonda 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. 32/40

33 YİNELEMELİ TASARIM VE PROTOTİPLENDİRME
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. 33/40

34 YİNELEMELİ TASARIM VE PROTOTİPLENDİRME
Prototiplendirme Teknikleri Hikaye Kartları Bilgisayar sisteminde olmayabilir. Sistemin akışının yada etkileşim noktalarının hikaye edilmesi Limitli işleve sahip simülasyonlar Uygulamanın çalışmasını daha iyi gösterebilir. Etkileşim fazladır. Ü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. 34/40

35 TASARIM MANTIĞI Sistem neden böyle tasarlandı? (yapısal, mimarisel, fonksiyonel ve davranış olarak) 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. 35/40

36 HCI açısından faydaları;
TASARIM MANTIĞI 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. 36/40

37 Tasarım mantığı türleri; Sürece odaklanan;
TASARIM MANTIĞI 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. 37/40

38 Tasarım mantığı türleri; Yapıya odaklanan;
TASARIM MANTIĞI 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) 38/40

39 Tasarım mantığı türleri;
TASARIM MANTIĞI 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 39/40

40 TEŞEKKÜRLER 40/40