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