İnsan Bilgisayar Etkileşimi

Slides:



Advertisements
Benzer bir sunumlar
Yazılım Geliştirme Süreci
Advertisements

YAZILIM GELİŞTİRME SÜRECİ
Sistem Analizi ve Planlama
PROJE YÖNETİMİ VE RİSK ANALİZİ
Maltepe Üniversitesi Mühendislik Fakültesi
Yazılım Mühendisliği Bölüm - 7 Yazılım Doğrulama ve Geçerleme
END3061 SİSTEM ANALİZİ VE MÜHENDİSLİĞİ
BELGELEME Ian Sommerville, “Software Documentation”,
Burcu Musaoğlu Data Sistem A.Ş..
SÜREÇ YÖNETİMİ Dr. Selami ERARSLAN İstanbul 2011.
BENZETİM Prof.Dr.Berna Dengiz 4. Ders Modelleme yaklaşımları
Yazılım Test Süreci. Yazılım test süreci Test Hazırlık Adımında Neler Yapılmalıdır? Test edilecek yazılıma ait analiz ve teknik tasarım aşamaları ile.
Sistem Geliştirme Sistemin tanımı. Sistemin Temel özellikleri
Yazılım Proje Yönetimi
ŞEHİRCİLİĞE GİRİŞ PLANLAMA SÜRECİNDE FONKSİYONLAR
24. MÜHENDİSLİK DEKANLARI KONSEYİ TOPLANTISI Mayıs 2012, Ege Üniversitesi Mühendislik Fakültesi Mühendislik Eğitiminde Tasarım Dersleri Prof. Dr.
Afyon Kocatepe Üniversitesi
İNSAN BİLGİSAYAR ETKİLEŞİMİ
Şişecam S ayısal Yönetimle Verim VIII. "Türkiye'de İnternet" Konferansı 20 ARALIK 2002 Canan Özcan Türkiye Şişe ve Cam Fab. A.Ş.
İHTİYAÇ BELİRLEME VE ANALİZİ
SİSTEM ANALİZİ VE TASARIMI
İNSAN BİLGİSAYAR ETKİLEŞİMİ
END3061 SİSTEM ANALİZİ VE MÜHENDİSLİĞİ
ERP Projelendirme Süreci
END3061 SİSTEM ANALİZİ VE MÜHENDİSLİĞİ
Kalite Yönetim Prensipleri (Devam)
DENEME.
KARAR ALICI OLARAK YÖNETİCİ.
Grup üyeleri: Selen ERGÜ Galip Kaya Nazgül BARPİEVA
ENF 204 Bilgisayar Programlama Algoritma ve Akış Diyagramları
Şahin BAYZAN Kocaeli Üniversitesi Teknik Eğitim Fakültesi
AYDIN ÇEVRE VE ŞEHİRCİLİK İL MÜDÜRLÜĞÜ
Süreç Yönetimi.
ISO ÇEVRE YÖNETİM SİSTEMİ TEMEL EĞİTİMİ
ISO 9001:2015 KALİTE YÖNETİM SİSTEMİ ŞARTLAR
Sistem Analizi Yaşam Döngüsü
Proje Yönetim Döngüsü: -Aşamaları -Rol ve Sorumluluklar
SİSTEM VE YAZILIM Bilgisayar sistemleri donanım, yazılım ve bunları işletmek üzere gerekli işlemlerden oluşur. Yazılım, bilgisayar sistemlerinin bir bileşeni.
Üniversiteler İçin Proje Yönetim Bilgi Sistemi
Proje Oluşturma ve Yönetimi
 Projeler üç nedenle sona erdirilirler. 1. Proje amaçlarına ulaşılmış ve başarılı olarak tamamlanmıştır. 2. Projenin durdurulması gerekmektedir. 3. Proje.
URUN GELıSTıRME KALıTE GUVENCESı VE STANDARDLARı SUMEYRA CELıK ZıRVE UNıVERSıTESı DıSTıCARET BOLUMU 1 NıSAN 2016.
DENEYSEL YAKLAŞIM (Kullanıcı Testleri)
Yazılım Müh.[YYurtaY 7.hft]1. 2 Bir yazılım ürünün testi ; ürünü son kullanıcıya teslim edilmeden önce yazılımın tüm yönleriyle kontrol edilmesidir. 
İNSAN BİLGİSAYAR ETKİLEŞİMİ: BİLİŞSEL BOYUT II. Algı açısından baktığımızda, insanın bilişsel sistemi, etrafımızdaki dünyayı gelen bilgileri  Bağlam.
 Bir projeyi yönetmek üzere görevlendirilen ve projeyi, mümkün olan en yüksek üretkenlik, en düşük belirsizlik ve risk ile yürütmekten sorumlu kişidir.
BÖLÜM 11 DEĞERLENDİRME. BÖLÜM 11 DEĞERLENDİRME.
Bilgisayar Mühendisliğindeki Yeri
ÇEVİK (Agile) SÜREÇLER Değişen gereksinimler, teknik riskler gibi önceden belirlenemeyen durumlara ve yazılım ürününü etkileyebilecek her tür değişikliğe.
Geleneksel Tasarım Araçları
Yazılım Mühendisliği YYurtaY. Ekip çalışması
Sistem Analizi ve Tasarımı
TÜRK EĞİTİM SİSTEMİ VE OKUL YÖNETİMİ Ders Notları
İNSAN BİLGİSAYAR ETKİLEŞİMİ: BİLİŞSEL BOYUT II
Kalite Yönetim Prensipleri (Devam)
SİSTEM ANALİZİ VE TASARIMI
Yazılım Bakımı Yazılım Mühendisliği.
ERP Projesinin Aşamaları İzmir. ERP Projesinin Aşamaları SatışSatış - Başlangıç – Kurulum – Analiz – Plan – Uyarlama – Eğitim – Geliştirme.
Problem Çözme Yaklaşımları
ONTOLOJİ GELİŞTİRME ALANINDA ÇEVİK YAKLAŞIMLAR
İnsan Bilgisayar Etkileşimi Teoriler ve Yaklaşımlar – 2
Hikaye tahtası.
Yazılım Mühendisliği Temel Süreçler - Sistem Analizi
Yazılım Mühendisliği Temel Süreçler – PLANLAMA II
Öğretim Teknolojileri ve Materyal Geliştirme
BENZETİM 2. Ders Prof.Dr.Berna Dengiz Sistemin Performans Ölçütleri
Yazılım Sürecinde İnsan Bilgisayar Etkileşimi BTÖ711 – İnsan Bilgisayar Etkileşimi Bahar Recep BAŞARICI.
İLERİ VERİ TABANI UYGULAMALARI
102 - Çoklu Algoritma Desteğine Dayalı E-İmza Uygulaması (E-Signat)
Sunum transkripti:

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