İ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. [Müşteri <> Kullanıcı?] İsterleri belirleyen, pazarlıkları yapan, tasarımcıyla masaya oturan kişilerle yazılımı kullanacak kişiler aynı olmayabilir.

Yazılım Yaşam Döngüsü Şelale Modeli Aktiviteleri 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. “Nasıl” yapılacağı sonraki adımlarda ortaya konacak. Müşteriden alınan (doğal dilde, ifade gücü yüksek fakat muğlak olabilen) bilginin, (daha net fakat ifade gücü az) programlama 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 Bu adımdan itibaren sistemin “nasıl” çalışacağı ile ilgili çalışmalar başlıyor. Bileşenler varolan birtakım sistemlerden sağlanabileceği gibi, sıfırdan da geliştirilebilir. Sadece fonksiyonel işlevlere (sağlayacakları servislere) göre sistem bileşenlerinin ayrıştırılması yetmez. Fonksiyonel olmayan gereksinimler: sistemin sağlayacağı servislerle doğrudan ilgisi olmayan fakat çalışacağı ortamda etkileneceği gereksinimler. (etkinlik[verimlilik], güvenilirlik, süre kısıtları, güvenlik gereksinimleri) + etkileşim özellikleri (in CH7)

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 - Bir programlama dilinde geliştirilebilecek düzeyde detaya iniliyor bu aşamada.

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. ... Önceki aktivitelerin çıktılarına göre testler üretiliyor...

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ı Doğru davranışlar, sistem kaynaklarının paylaşımı Sağlık ve güvenlik düzenlemeleri + ISAO9241 = tasarımcıların geliştirecekleri sistemlerde göz önünde bulundurmaları gereken HCI etkileri

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. - Bu geri dönüşler oluşan bazı hatalar yada öngörülemeyen gereksinimlerdir...

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 Örneğin bir maaş hesaplama bileşeninin doğrulaması: tasarımcı, geliştirilen algoritmanın, çalışanın maaşından kesilecek vergiyi doğru hesaplamasından sorumludur. Tasarımcı, detaylı tasarım aşamasında, gereksinimlerin geçerliliğini (iç tutarlılığı) ve genel tasarımda belirtilen tüm davranışların tanımlandığını kontrol etmekle yükümlüdür.

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. Konuşma diline özgü durumlarla, net ve planlanmış geliştirme süreci sonucunda oluşacak durumlar arasında mutlaka bir kayma olacaktır. = “formality gap” “Formality gap”’i 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.

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... İlk kelime işlemci tasarımı örneği... Outline’ing facility... Grafik çizim programı... Gölgeleme efekti...

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 Bu değerler ve metodlar bir takım kullanılabilirlik metriklerinden faydalanılarak oluşturuluyor. Whiteside, Bennet ve Holtzblatt’ın ölçüm kriterleri listesi... ISO 9241 : gereksinim şartnameleri ile birlikte, kullanılabilirlik şartnamelerinin kullanılmasını önerir. Bunun için birtakım kullanılabilirlik metrikleri oluşturulmuştur. Kullanılabilirlik, Etkinlik, Verimlilik ve Memnunluk kategorilerinde...

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. Tasarımcı bu durum ve davranışların ne olacağını bilseydi, zaten sistemi onlara göre tasarlardı. Fakat tasarımın başında bu bilgi yok. VCR’da doğrudan undo yapmak yerine neden problemin kaynağını belirleme yoluna gidilmedi? Metrikte undo için az işlem, başarılı görülüyor... Gerçekten öyle mi?

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ı 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.

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 --