İnsan Bilgisayar Etkileşimi

İnsan Bilgisayar
Etkileşimi
Yazılım Sürecinde İnsan
Bilgisayar Etkileşimi
Hasan Türksoy
Tanımlar

Yazılım Mühendisliği :Yazılım sistemlerinin geliştirilmesi için
gerekli teknik ve yönetimsel aktivitelerle ilgilidir.

Yazılım Yaşamdöngüsü : Yazılımın başlangıçtaki kavramsal
oluşumundan, son fazına ve kurulumuna kadar gerçekleşen
aktiviteler...

Müşteri (Customer) : Ürünle ilgili isterleri belirleyen kişi/grup.

Tasarımcı (Designer) : Ürünü geliştirmekle sorumlu kişi/grup.
Yazılım Yaşam Döngüsü
Gereksinim Belirleme
Mimari Tasarım
Detaylı Tasarım
Kodlama ve Birim Testi
Entegrasyon ve Test
Kurulum ve Bakım
Şelale Modeli Aktiviteleri
Gereksinim Belirleme

Son ürünün “ne” yapması bekleniyor. “Nasıl”
yapacağının detaylarına girilmiyor.

Müşteriden temin edilecek bilgiler:




Çalışma ortamı
Uygulamadan beklenen fonksiyonlar
Çalışma alanı (domain)
 Etkilenebilecek insanlar/sistemler
 Varolan sistemlerle etkileşimi
Müşteriden alınan bilginin, işletilebilir uygulama
diline en az kayıpla aktarımı başarım oranını artırır.
Mimari Tasarım

Hedeflenen sistemin bileşenlere ayrılması.

Bu bileşenler arasındaki etkileşim ve kaynak
paylaşımı da tanımlanır.

Fonksiyonel gereksinimler – Fonksiyonel
olmayan gereksinimler
Detaylı Tasarım

Bileşenlerin mimari tasarımda tanımlanan
davranışların detaylandırılması

Bu detaylandırma işlemi birden fazla şekilde
sonuçlanabilir.


En çok fonksiyonel olmayan gereksinimi karşılayabilen
detay tasarım en iyisi...
Önerilen tasarım seçenekleri, nihai olarak karar
verilen seçenekler ve nedenleri kaydedilmeli
Kodlama ve Birim Testi

Bileşenlerin kodlanması ve belirlenen test
kriterlerine göre doğru çalışıp çalışmadığının
testi.

İki tür yaklaşım:


Detaylı tasarımdan, gerçekleştirime (kodlamaya)
geçiş tamamen otomatize edilebilir. (teoride)
Belirlenen kodların doğru çalışıp çalışmadığını
kontrol edecek testlerin otomatik üretilmesi.
Entegrasyon ve Test

Bileşenlerin mimari tasarımda belirtildiği şekilde
entegre edilmesinden sonra oluşan sistemin testi.

Kabul testleri müşteri ile de yapılabilir

Son sistemin bazı otoritelerce sertifikasyonu
gerekebilir

ISO9241: ofis ortamlarındaki iş istasyonlarının kullanışlılık
sertifikası
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...

Yaşam döngüsünün büyük bölümü bakımdan oluşur.

Bakım aşamasında daha önceki adımlara geri
dönüşler sağlar.
Geçerlilik Denetimi ve
Doğrulama

Geçerlilik Denetimi (Validation)
 Müşteri ile anlaşılan gereksinimler gerçekleştirilmiş mi?
 “doğru şey” mi tasarlanmış?
 HCI gereksinimleri için değerlendirme şeklinde yapılır. [Ch9]

Doğrulama (Verification)
 Gereksinimler doğru, tam ve tutarlı olarak karşılanmış mı?
 Tasarlanan şey “doğru mu”?

Tasarımcının sorumluluğu:
 1 – isterlerin iç tutarlılığını kontrol etmek
 2 – gereken tüm davranışların tanımlandığından emin olmak
Geçerlilik Denetimi ve
Doğrulama (2)

Geçerlilik Denetimi (Validation)


Doğal dilde ifade edilen gereksinimlerin karşılanması
kontrol edileceği için, çok sıkı ve objektif olarak
gerçekleştirilmesi imkansız. = “formality gap”
Doğrulama (Verification)

Zaman ve maliyet etkenleri nedeniyle, tüm isterlerin tam
olarak doğrulanması mümkün olamıyor. Hangilerinin tam
olarak doğrulanacağı, hangilerinin de belirli şartları
sağlayınca olmuş kabul edileceği belirleniyor daha çok. Bu
aşama ne kadar otomatize edilirse, doğrulama maliyeti o
kadar düşecektir.
Yönetim ve Sözleşme
Sorunları

Yeni bir uçağın geliştirilmesi


4-5/50yıl yazılım yaşam döngüsü
En başta tüm gereksinimleri görebilmek
imkansız!
Etkileşimli Sistemler ve Yazılım
Yaşamdöngüsü

Geleneksel yazılım yaşamdöngüsü, HCI’ın
önemli olmadığı zamanlarda geliştirildi.

Sutton ve Sprague’nin araştırması (1978):
tasarımcının zamanının yarısı kullanıcı
arayüzü tasarlamakla geçiyor.
Etkileşimli Sistemler ve Yazılım
Yaşamdöngüsü (2)

Tasarımların kullanışlılığının artırılması için;



Sistem 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 ve Yazılım
Yaşamdöngüsü (3)

Etkileşimli sistem tasarımı yaklaşımı; Kullanıcının
sistemde gerçekleştireceği görevlerin önceden
anlaşılabilmesi.

Fakat bu ancak, kullanıcı, sistemin tamamını
kullandığı zaman ortaya çıkacak

= tavuk – yumurta problemi...

Üstelik; kullanıcının sistemde yaptığı kimi işlemler,
tasarımcının aslında planlamadığı şekilde
gerçekleştiriliyor da olabilir...
Etkileşimli Sistemler ve Yazılım
Yaşamdöngüsü (4)

Geleneksel yazılım yaşamdöngüsü,
etkileşimli sistemlerle ilgili kullanıcı
gereksinimlerini yansıtacak notasyon ve
teknikleri içermiyor.

Eğer tasarım gereksinimlerinde kullanıcı
etkileşimi ile ilgili bilgiler bulunmuyorsa,
bilişsel gereksinimlerin belirlenmesi çok
zordur.
Kullanılabilirlik Mühendisliği

Bir ürünün kullanılabilirliğini
değerlendirebilmek için hangi kriterler
kullanılacak?

Fiziksel aktivitelerin ötesini (sistemin geri
kalan kısmını yada kullanıcının bilişsel
kapasitesini) ölçmek zor olduğu için,
kullanılabilirlik mühendisliğinin uygulama
alanı da sınırlıdır.
Kullanılabilirlik Mühendisliği
(2)

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
Kullanılabilirlik Mühendisliği
(3)


Bu metrikler;
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.
Yinelemeli Tasarım ve
Prototiplendirme


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.
Yinelemeli Tasarım ve
Prototiplendirme (2)

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.
Artırımlı (Incremental);
 Son ürünle ilgili genel bir bakış açısı var. Her yinelemede
ayrı bir alt bileşen geliştirilir.
Prototiplendirme etkileşimli sistemlerde de gerçek
kullanıcının yaklaşımlarını görebilmek açısından
önemlidir.
Yinelemeli Tasarım ve
Prototiplendirme (3)

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ümante edilip
anlaşılması gerekir.
Prototiplendirme Teknikleri

Hikaye Kartları


Limitli işleve sahip simülasyonlar


Bilgisayar sisteminde olmayabilir. Sistemin akışının yada
etkileşim noktalarının hikaye edilmesi.
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.
Tasarım Mantığı


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.
Tasarım Mantığı (2)

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.
Etkileşimli sistemlerin kullanılabilirliği, bulundukları
bağlama çok bağlı. Bir tasarım kararı alınırken
bağlamın iyi anlaşılması çok önemli.
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 (2)

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 (3)

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.
-- SON --