Yazılım Sürecinde İnsan Bilgisayar Etkileşimi BTÖ711 – İnsan Bilgisayar Etkileşimi 2018 - Bahar Recep BAŞARICI.

... konulu sunumlar: "Yazılım Sürecinde İnsan Bilgisayar Etkileşimi BTÖ711 – İnsan Bilgisayar Etkileşimi 2018 - Bahar Recep BAŞARICI."— Sunum transkripti:

1 Yazılım Sürecinde İnsan Bilgisayar Etkileşimi BTÖ711 – İnsan Bilgisayar Etkileşimi 2018 - Bahar
Recep BAŞARICI

2 Yazılım Mühendisliği ve Etkileşimli Sistemlerde Tasarım
Sunum Planı Yazılım Mühendisliği ve Etkileşimli Sistemlerde Tasarım Kullanılabilirlik Mühendisliği Yinelemeli Tasarım ve Prototipleme Tasarım Mantığı

3 Yazılım Mühendisliği ve Yazılım Yaşam Döngüsü
Bilgisayar biliminin önemli alt disiplinlerinden birisi, yazılım geliştirme süreçlerinde yönetsel ve teknik konuları ele alan yazılım mühendisliğidir. Yazılım mühendisliğinin köşe taşlarından birisi ise yazılım yaşam döngüsüdür. Yazılım yaşam döngüsü, başlangıçtaki kavramsal oluşumdan yazılımın sonlandırılması ve işe koşulmasına kadar tüm süreçleri kapsar.

4 Şelale Modeli Gereksinimlerin belirlenmesi Mimari tasarım
Detaylandırılmış tasarım Kodlama ve birimlerin test edilmesi Entegrasyon ve test İşletim ve bakım

5 Gereksinimlerin Belirlenmesi
Mimari tasarım Detaylandırılmış tasarım Kodlama ve birimlerin test edilmesi Entegrasyon ve test İşletim ve bakım Bu aşamada, tasarımcı ile kullanıcı (müşteri ), tasarımı yapılacak sistem ile ilgili beklentileri kararlaştırırlar. (NE? NASIL?) Burada sadece sistem ile ilgili değil aynı zamanda çalışacağı ortam ya da çalışma alanı ile ilgili bilgi sağlanır. Kullanıcının dili ile ifade edilen beklentiler tasarım sırasında matematiksel dil yapısında olan yazılım diline çevrilir.

6 Bunun için hedeflenen sistem bileşenlere ayrılarak işe başlanır.
Mimari Tasarım Gereksinimlerin belirlenmesi Mimari tasarım Detaylandırılmış tasarım Kodlama ve birimlerin test edilmesi Entegrasyon ve test İşletim ve bakım Bir önceki aşamada belirlenen gerekliliklerin nasıl gerçekleştirileceğinin belirlendiği ilk aşamadır. Bunun için hedeflenen sistem bileşenlere ayrılarak işe başlanır. Bu bileşenler arasındaki etkileşimin ve kaynak paylaşımının nasıl olacağı tanımlanır. Fonksiyonel gereksinimler – Fonksiyonel olmayan gereksinimler

7 Detaylandırılmış Tasarım
Gereksinimlerin belirlenmesi Mimari tasarım Detaylandırılmış tasarım Kodlama ve birimlerin test edilmesi Entegrasyon ve test İşletim ve bakım Belirlenen gereksinimleri, mimari tasarımda yer aldığı şekliyle karşılayan bileşenlerin ayrı ayrı tanımlandığı aşamadır. (Refinement) Bu aşamada kararlar alınırken, fonksiyonel olmayan gereksinimler ön plana alınmalıdır.

8 Kodlama ve Birimlerin Test Edilmesi
Gereksinimlerin belirlenmesi Mimari tasarım Detaylandırılmış tasarım Kodlama ve birimlerin test edilmesi Entegrasyon ve test İşletim ve bakım Tanımlanan bileşenler bu aşamada, seçilen programlama diliyle kodlanır. Daha sonra, tasarlanan bileşen, belirlenen kriterlere göre test edilir.

9 Entegrasyon ve Test Gereksinimlerin belirlenmesi Mimari tasarım Detaylandırılmış tasarım Kodlama ve birimlerin test edilmesi Entegrasyon ve test İşletim ve bakım Gerçekleştirilen ve ayrı ayrı test edilen bileşenler, mimari tasarımda öngörüldüğü şekliyle entegre edilir ve bu entegre edilmiş sistem ayrıca test edilir. Bazı kabul testleri kullanıcıyla (müşteriyle) birlikte de gerçekleştirilebilir. Sertifikasyon gerekebilir  Ofis çalışma ortamlarında kullanılabilirliği tanımlayan ISO 9241 standardı

10 Yaşam döngüsünün büyük bir kısmı bakım aşamasında geçer.
İşletim ve Bakım Gereksinimlerin belirlenmesi Mimari tasarım Detaylandırılmış tasarım Kodlama ve birimlerin test edilmesi Entegrasyon ve test İşletim ve bakım Tasarım gerçekleştirildikten sonra kurulum ve bakım aşaması devreye girer. Yaşam döngüsünün büyük bir kısmı bakım aşamasında geçer. Bu aşama, yazılım yaşam döngüsündeki diğer tüm aşamalara geribildirim sağlar.

11 Geçerlik (Validation) ‘the right thing’  Doğru ürün tasarlandı mı?
Geçerlik ve Doğrulama Geçerlik (Validation) ‘the right thing’  Doğru ürün tasarlandı mı? Doğrulama (Verification) ‘the thing right’  Ürün doğru şekilde tasarlandı mı? Gerçek dünya gereksinimleri ve kısıtları (The formality gap)

12 Yinelemeli (iterative) tasarım
Etkileşimli Sistemler ve Yazılım Yaşam Döngüsü Geleneksel yazılım mühendisliği ve yazılım yaşam döngüsü 1960 ve ’lerin ihtiyaçları temel alınarak oluşturulmuştu. (Veri işleme / Yığın işleme  Son kullanıcı açısından tasarım) Yinelemeli (iterative) tasarım Gereksinimlerin belirlenmesi Mimari tasarım Detaylandırılmış tasarım Kodlama ve birimlerin test edilmesi Entegrasyon ve test İşletim ve bakım

13 Kullanılabilirlik Mühendisliği
Kullanılabilirlik mühendisliğinde odak nokta, kullanılabilirlik hakkında yargıya varmak için ele alınacak kriterlerin belirlenmesidir (ISO-9241’den örnekler):

14 ISO-9241’den örnek metrikler:
Kullanılabilirlik Mühendisliği ISO-9241’den örnek metrikler: Usability Effectiveness Efficiency Satisfaction objective measures measures measures Suitability Percentage of Time to Rating scale for the task goals achieved complete a task for satisfaction Appropriate for Number of power Relative efficiency Rating scale for trained users features used compared with satisfaction with an expert user power features Learnability Percentage of Time to learn Rating scale for functions learned criterion ease of learning Error tolerance Percentage of Time spent on Rating scale for errors corrected correcting errors error handling successfully

15 Bunu sağlamanın bir yolu yinelemeli (iterative) tasarımdır.
Yinelemeli Tasarım ve Prototipleme Etkileşimli bir sistem tasarlanmasında, gereksinimlerin tam anlamıyla yerine getirilebilmesi, tasarımın gerçek kullanıcılar aracılığıyla denenmesi sayesinde mümkün olabilir. Bunu sağlamanın bir yolu yinelemeli (iterative) tasarımdır. Yinelemeli tasarım, prototipler kullanılarak gerçekleştirilir. Üç ana prototipleme yaklaşımı bulunmaktadır: Throw-away Incremental Evolutionary

16 Yinelemeli Tasarım ve Prototipleme
Throw-away

17 Yinelemeli Tasarım ve Prototipleme
Incremental

18 Yinelemeli Tasarım ve Prototipleme
Evolutionary

19 Tasarım Mantığı (Design Rationale)
Herhangi bir etkileşimli sistem tasarlanırken, birçok aşamada, çeşitli kararlar almak gerekir. Bu kararları alırken tasarım mantığı yaklaşımları kullanılabilir. Bu sayede; Tasarım ekibi, verilen kararlardan, bu kararların sebeplerinden ve alternatiflerinden haberdar 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 daha fazla düşünülmüş olur.

20 Tasarım Mantığı (Design Rationale)
Ayrıca, İnsan Bilgisayar Etkileşimi alanında 'tasarım mantığı' kullanımı çeşitli nedenlerle önemlidir: 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.

21 Tasarım Mantığı (Design Rationale)
Süreç Odaklı Temelinde, Rittel tarafından geliştirilen IBIS (Issue Based Information System) yaklaşımı yer alır. Tasarım toplantılarında üzerinde durulan konular / alt konular ve alınan kararların kaydedilmesinde kullanılmaktadır. Tasarım bilgisinin, farklı ürünler için kullanılabilecek şekilde genelleştirilmesi yerine, o ürüne özel karar sürecini kaydetmekte kullanılır.

22 IBIS - (Issue Based Information System)
Tasarım Mantığı (Design Rationale) IBIS - (Issue Based Information System) Sub-issue Issue Position Argument responds to objects to supports questions generalizes specializes

23 Tasarım Mantığı (Design Rationale)
Yapı Odaklı Tasarım alternatifleri arasında karar vermenin nasıl yapısallaştırıldığına odaklanır. Doğru soruların oluşturulmasını ve seçenekleri değerlendirebilmek için doğru kriterlere karar verilmesini amaçlar.

24 QOC Notation Tasarım Mantığı (Design Rationale) Consequent Question
Criterion Option Question Option Criterion Option Criterion … Consequent Question … Question

25 Teşekkürler..