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

İNSAN BİLGİSAYAR ETKİLEŞİMİ
YAZILIM SÜRECİNDE
İNSAN BİLGİSAYAR ETKİLEŞİMİ
Murat ÇINAR
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.
2/40
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
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
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.
5/40
YAZILIM YAŞAM DÖNGÜSÜ
• 1.1. Yazılım yaşam döngüsündeki aktiviteler;
Gereksinimleri
belirleme
Mimari
tasarım
Detaylı
tasarım
Kodlama ve
Birim testi
Tümleştirme ve
Sistem testi
Kurulum ve
Bakım
Şekil 1: Şelale Modeli Aktiviteleri
6/40
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
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
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.
9/40
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
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
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
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ı
13/40
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
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
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
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.
17/40
YAZILIM YAŞAM DÖNGÜSÜ
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
18/40
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.
19/40
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
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ı.
21/40
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
22/40
YAZILIM YAŞAM DÖNGÜSÜ
• Etkileşimli Sistemler için Yaşam Döngüsü
Gereksinimleri
belirleme
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
23/40
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
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
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.
Ö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
Video kaset kaydedici ile Geri alma işleminin örnek kullanılabilirlik özellikleri
26/40
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
KULLANILABİLİRLİK MÜHENDİSLİĞİ
• 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
yüzdesi
Görevi zamanında
tamamlama
Memnuniyet
için ölçüt
Yetkin personel
için uygunluğu
Kullanılan etkili
özelliklerin sayısı
Uzman kullanıcıyla
karşılaştırıldığında
verimlilik düzeyi
Güç özellikleri
için memnuniyet
ölçeği
Öğrenilebilirlik
Öğrenilen işlevlerin
yüzdesi
Öğrenme için
gerekli zaman
Öğrenme kolaylığı
için ölçek
Hata toleransı
Hataların başarıyla
düzeltilme yüzdesi
Hataları düzeltmek
için harcanan zaman
Hataları düzeltmek
için ölçek
28/40
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
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
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
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
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
YİNELEMELİ TASARIM VE PROTOTİPLENDİRME
 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.
34/40
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
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
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
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
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
TEŞEKKÜRLER
40/40