Kalite Evi Nedir? Neden ve Nasıl Kullanılır?

Blog ziyaretçimden gelen soruyla öğrendiğim ve hoşuma giden bu bilgiyi sizlerle de paylaşmak istedim. Daha önceden BABOK veya PMI Gereksinim Yönetimi kitaplarında görmediğim Kalite eksenli bir konu ve Yazılım çalışmalarında Gereksinim Yönetimi için de kullanılabilecek görünüyor.

Kalite evinin esası müşterinin istek ve beklentilerini karşılayan ürünlerin tasarlanması düşüncesidir.Japonca’da, “Hinshitsu Kino Tenkai”, İngilizce’de ise “QFD” olarak biliniyor. Türkiye’de ise uygulayan şirketler “Kalite evi” tanımını yapıyor. 1970’li yıllarda Japonya’da geliştirildi. O dönemde büyük ilgi gördü, ABD’li şirketler tarafından da uygulandı. Türkiye’de ise son dönemde yaygınlaşıyor. Çok sayıda şirket, sessiz, ancak derinden gidiyor. İşin özünde ise son müşteriyi dinleyerek, tasarımdan üretime, bütün ürün geliştirme süreçlerini değiştirme var.

Kaynak ve ek bilgi: http://www.capital.com.tr/gelecek-trendler/kalite-evi-nasil-calisir-haberdetay-1816

 

Kalite evi fonksiyonlar arası planlama ve iletişimi sağlayan bir tür kavramsal haritadır. Değişik problemleri ve sorumlulukları olan insanlar evin çatısı altındaki bilgi motiflerinden tasarım önceliklerini kolayca belirleyebilirler.

Kalite evi, tanımlanmış müşteri ihtiyaçlarını “NELER” ve buna karşılık gelen mühendislik spesifikasyonlarının “NASILLAR” olarak isimlendirilerek ilişkilendirildiği, matris tarzında bir şemadır. 6 ana bloktan oluşur.

Bu bloklar ise 12 parçadan oluşur. Bu alt bloklar aşağıda sıralanmıştır:

1. Müşteri Gereksinim ve Beklentileri
2. Müşteri Gereksinim ve Beklentilerinin Anlamı
3. Rakip Karşılaştırmaları
4. Müşteri Gereksinim ve Beklentilerine İlişkin Diğer Kriterler
5. Ürün ya da Proje Özellikleri
6. Müşteri Gereksinim ve Beklentileri ile Ürün ya da Proje Özellikleri İlişkisi
7. Ürün ya da Proje Özelliklerinin Anlamı
8. Ürün ya da Proje Özelliklerinin Rekabet Karşılaştırması
9. Ürün ya da Proje Özelliklerine İlişkin Diğer Kriterler
10. Ürün ya da Proje Özelliklerinin Optimizasyon Yönü
11. Ürün ya da Proje Özelliklerinin Karşılıklı Etkileşimi
12. Ürün ya da Proje Özelliklerine İlişkin Hedef Değerler

Kalite Evinin Oluşturulması

Kalite evinin oluşturulmasını adım adım incelemeden önce bütününe bakacak olursak;

Şimdi kalite evini oluşturan bu birimleri nasıl dolduracağımızı incelersek;

Aşama 1: Müşteri Beklentileri Listesi

Kalite evinin oluşturulmasındaki birinci adım Müşteri Beklentileri Listesinin oluşturulmasıdır. Bu liste müşterinin ihtiyaçları ve üründe bulunmasını beklediği özelliklerden oluşur. Birincil müşteri beklentileri olarak adlandırılan bölümde, özellikler, genel kavramlarla ifade edilir. İkincil müşteri beklentileri bölümünde ise birincil bölümdeki maddeler detaylandırılır.

Müşteri beklentilerinin, hiyerarşik bir yapı içerisinde detaylandırılması, beklentilerin mühendislik aşamasında kullanılabilecek şekilde ifade edilmesini sağlar. Örneğin birincil müşteri beklentisinin “güvenilirlik” olması halinde; ikincil müşteri beklentilerini sağlamlık, uzun kullanım süresi ve iyi bir bakım hizmeti olabilir.

Gerek müşterilerle doğrudan görüşerek gerekse soru formları kullanılarak müşteri önem seviyeleri saptanır. Müşteri beklentileri ve isteklerine, önem seviyesine göre 1 ile 5 arasında not verilir. İşletmenin anket çalışmasından elde ettiği müşteri istekleri bulguları, aynı zamanda NELER’ in yapılması gerektiğini de ortaya koymaktadır.

 

Aşama 2: Teknik Tanımlamalar Listesi

Kalite evinin amacı, müşteri beklentilerini karşılayacak ürün tasarlamak ya da mevcut tasarımları geliştirmektir. Bu amaca yönelik bir uygulamada en önemli nokta, müşteri beklentilerinin mühendislik aşamasında kullanılabilecek teknik tanımlamalara dönüştürülmesidir. Teknik tanımlamalar, kalite evinin ikinci katını ve tavanını oluşturmaktadır. Yani, pazarlama grubu NELER’ in yapılacağını belirledikten sonra bunların NASIL yapılacağı AR-GE grubu tarafından tanımlanır. Bu aşamada grup üyeleri her bir müşteri beklentisini gerçekleştirecek birkaç ölçülebilir tasarım unsurunu belirleyecek ve bu şekilde kalite evi matrisi hazırlanacaktır.

Kalite evi matrisinde, satırlar müşteri beklentilerini ve bunların göreli önem derecesini, sütunlar ise bu beklentileri gerçekleştirecek mühendislik özelliklerini içerir.

Aşama 3: Müşteri Beklentileri ile Teknik Tanımlamalar Arasındaki İlişkiyi Gösteren Matris

Kalite Evinin hazırlanmasında 3. Adım ise, her bir teknik özelliğin hangi müşteri gereksinimini karşılamaya ne derece etkisi olduğunu gösteren ilişki matrisinin oluşturulmasıdır. Bu kısım kalite evinin gövdesini oluşturur.

Bu amaçla kalite evi matrisinde NE’ler ve NASIL’lar arasındaki ilişkiler genelde sembollerle gösterilir.

İlişki matrisi oluşturulduktan sonra yapılacak işlem boş kalan satır ve sütunların incelenmesidir. Boş bir satır ilgili müşteri beklentisinin herhangi bir teknik tanımla ilişkilendirilmediğinin göstergesidir. Bu durumda yapılması gereken matrise yeni bir teknik tanım eklemek ve karşılanmamış olan müşteri beklentisini en az bir teknik tanımla ilişkilendirmektir.

Matriste boş kalmış olan sütunlar ise, ilgili tanımın hiçbir müşteri beklentisini etkileyemediğini gösterir. Bu teknik tanımlar dikkatli bir inceleme sonrasında hala ilişkilendirilemezlerse matristen çıkarılmalıdırlar.

Her teknik gereksinim için müşteri memnuniyetini en üst düzeye çıkaracak ve müşteri için en olumlu nitelikte olan bir gelişim yönü vardır. Geliştirme yönü “daha … olması gerekli” terimindeki boşluk doldurularak belirlenir.

Derecelendirme sembollerinin veya harflerinin sayısal bir değere eşitlenmesi, ileride yapılacak trade-off ve mutlak ağırlık hesaplamaları için gereklidir.

G=9 (güçlü)

M=3 (orta)

V=1 (zayıf)

Aşama 4: Teknik Göstergeler Arasındaki Korelasyon Matrisi

Kalite evinin çatısını oluştururken üçgen biçimindeki korelasyon matrisi, teknik tanımların kendi aralarındaki iç ilişkilerini göstermek amacıyla kullanılır.

+1 = Pozitif

0 = Orta

-1 = Negatif

Aşama 5: Rekabet Matrisleri

Rekabet matrisleri kuruluşun kendi ürünü ile rakip kuruluşların ürünleri arasındaki farkı görebilmesi amacıyla oluşturulur. Kalite evinde rekabet ortamının değerlendirilmesi için müşteri ve teknik tanımlar bazında rekabet matrisleri oluşturulur.

• Müşteri Bazlı Rekabet Matrisi: Kalite evinin sağ tarafına yer alan sütunlardan oluşur. Matristeki hücreler, kuruluşun kendisinin ve rakiplerinin ürünlerinin müşteri beklentilerini karşılama durumunu belirlemek için kullanılır. Bu hücrelere 1-5 arası puanlar verilerek, farklı ürünlerin farklı beklentileri karşılama dereceleri saptanır (1=en kötü, 5=en iyi).
• Teknik Bazlı Rekabet Matrisi: Teknik tanımların, piyasadaki farklı ürünler üzerindeki etkilerinin gözlenmesi amacıyla oluşturulan matristir. Kalite evinin giriş katını oluşturan bu bölüm, ilişki matrisinin altına çizilen satırlardan meydan gelir. Her teknik tanımın farklı ürünle eşleştirilmesiyle oluşan hücrelere 1-5 arası puanlar verilir.

Rekabet matrisleri kuruluşun kendi ürününün piyasadaki yerini görmesi açısından büyük önem taşır. Kalite evinin farklı yerlerinde bulunmalarına rağmen her iki matris de birbirleriyle orantılıdır. Müşteri beklentilerini fazlasıyla karşılayabilen bir ürünün teknik tanımlar bakımından da diğer ürünlere göre üstün olması gerekir. Eğer yapılan değerlendirmeler sonucunda çıkan yorum bu teorinin aksini işaret ediyorsa, değerlendirmenin hatalı olduğu söylenebilir.

Aşama 6: Öncelikli Müşteri İsteklerinin ve Teknik Özelliklerin Belirlenmesi

Önceliklendirilmiş müşteri beklentileri, kalite evinin sağ tarafında müşteri bazlı rekabet matrisine bitiştirilmiş kolonlarda ifade edilir. Bu kolanlar müşteri için önem değeri, hedef değer, scale-up faktörü, satış noktası ve mutlak ağırlık olarak sınıflandırılmıştır.

• Önem Değeri: Kalite fonksiyon yayılımı ekibinin, müşteri beklentilerinden hangilerinin önemli hangilerinin önemsiz olduğunu belirlemek amacıyla oluşturacağı bu kolon 1’den 10’a en önemsizden çok önemliye doğru puanlandırılır. Beklentilerin önceliklendirilmesi hangi alanlara daha çok ağırlık verilmesi gerektiğini belirler ve trade-off kararlarının alınmasını kolaylaştırır.

 

• Hedef Değer: Hedef değer kolonunun puanlanma yöntemi müşteri bazlı rekabette olduğu gibi 1-5 arasındadır (1-en kötü, 5-en iyi). Bu bölüm kalite yayılım fonksiyonu ekibinin ürün için yapmayı planladığı değişiklikleri gösterir.

• Scale-Up Faktörü: Scale-up faktörü hedef değerin, müşteri rekabet matrisindeki ürün puanına oranıdır. Bu değerlendirmenin amacı ürünün şu andaki seviyesiyle hedeflenen seviyesinin arasındaki farkın görülmesi ve geri kalınmış ya da eksik olan karakteristiklerin belirlenmesidir. Bu aşamada dikkat edilmesi gereken husus hedef değerinin gerçekçi olarak tespit edilmesidir. Aksi takdirde ortaya çıkacak olan scale-up faktörü yanıltıcı olacaktır ve bu da kuruluşun yanlış alanlarda zaman kaybetmesine yol açar.

 

• Satış Noktası: Satış noktası, ürünün piyasadaki satış performansının ve ürüne olan ilginin göstergesidir. Bu değer ürünün satışını etkileyebilecek müşteri beklentilerinin belirlenmesi amacıyla kullanılır. Satış noktası için optimal bir değer tespit edildikten sonra puanlama bu normalize edilmiş değer üzerinden yapılır.

• Mutlak Ağırlık ve Oran: Bu son kolon; önem değeri, scale-up faktörü ve satış noktası değerlerinin çarpılmasıyla hesaplanır.

Mutlak ağırlık = (önem değeri) * (scale-up faktörü) * (satış noktası)

Mutlak ağırlık değeri tüm müşteri beklentileri için ayrı ayrı hesaplandıktan sonra, beklentiler arasındaki oran rahatlıkla gözlenebilir. Mutlak ağırlık değerleri ve beklentiler arasındaki oranlar planlama aşamasında ve ürünün geliştirilmesinde dikkate alınması gereken en önemli verilerdir.

Anlatılanların genel olarak kalite evi üzerinde gösterimine bakacak olursak daha iyi kavranılabilir.

Teorik bilgi dışında örnek uygulamaların/hesaplamaların olduğu kaynakları ve yazımda yararlandığım kaynakları sizlerle paylaşmak istiyorum. Umarım faydası olur 🙂

Kaynakça : https://industryolog.com/kalite-evi/

Örnek Uygulama 1: http://mmfdergi.uludag.edu.tr/article/viewFile/5000082727/5000076927

Örnek Uygulama 2: https://view.officeapps.live.com/op/view.aspx?src=http://debis.deu.edu.tr/userweb/k.yaralioglu/dosyalar/kal_fonk.doc

Örnek Uygulama 3: http://www.capital.com.tr/gelecek-trendler/kalite-evi-nasil-calisir-haberdetay-1816

Reklam

Mock Up ve WireFrame Araç Önerileri

 

Yazılım projelerinde arayüz gereksinimlerini dokümante etmek gerektiğinde uzun zaman alan sayfalarca analiz dokümanı üretmek yerine geliştirme çalışmalarında yaşanacak değişiklikleri de en aza indirecek ekran tasarımı taslak çizim programları kullanmak benim önerimdir. İşte araştırmalarımla ulaştığım araçlar öneri sırasına göre aşağıdaki gibidir.

 

https://www.axure.com/

 

https://balsamiq.com/

 

http://mockupbuilder.com/

 

https://mockflow.com/

 

https://www.lucidchart.com

 

https://gomockingbird.com/home

 

https://www.invisionapp.com/

 

https://www.uxpin.com/

 

https://proto.io/

 

https://moqups.com/

 

https://www.mockplus.com

 

https://www.justinmind.com/

 

https://marvelapp.com/

 

http://origami.design/

Kamuda İnovasyon

Kamuda İnovasyon

Kamu kurumlarında,
•daha fazla değer yaratmak,
•sorun çözmek,
•ihtiyaçlara daha etkin cevap vermek,
•kaynakları en etkin ve verimli şekilde kullanmak,
•mensuplarının ve vatandaşların yaşam kalitesini yükseltmek amacıyla

hizmetleri, ürünleri ve bunların sunuluş biçimlerini; süreçleri ve organizasyonu iyileştirmeye ve geliştirmeye odaklı fikirlerin geliştirilip uygulanması faaliyetidir.

Küreselleşmeye bağlı ekonomik ve toplumsal gelişmeler, iş dünyası için olduğu kadar kamu kurumları için de üstesinden gelinmesi gereken önemli güçlükleri ve yakalanması gereken fırsatları beraberinde getirmektedir. Küresel pazarlar, uluslararası ortaklıklar, dış kaynak kullanımları, uluslararası rekabet ve buna bağlı müşterilerin değişen ve artan talepleri firmaların hızla inovasyon yapmalarını gerektirirken, yine çoğunlukla küreselleşmeye atfedilen gelişmeler ve vatandaşların beklenti ve taleplerindeki artış, kamu kurumlarında da inovasyonu kaçınılmaz kılmaktadır. Birleşmiş Milletler’e göre bu zorunluluk üç ana boyutu ilgilendirmektedir:
1.Daha az kaynak ve sınırlı operasyonel kapasiteyle çok daha geniş kesimlere daha yüksek kalitede hizmet sağlama gereği (ki bu, kaynakların daha etkin kullanımı ve kapasitenin daha etkin oluşturulmasıyla sınırlı kalmayıp daha yaratıcı ve farklı çözümlerin geliştirilmesini de gerektirmektedir),
2.Vatandaş-yönelimli kamu yönetimiyle daha hesap verebilir, sorumluluk sahibi ve etkin bir yapıya kavuşma zorunluluğu,
3.Vatandaşların taleplerine daha iyi yanıt verme gereği.

Kamu kurumlarında inovasyon kültürünü oluşturmayı ve inovasyon yönetim sistemlerini kurmayı gerektiren bu zorunluluklar, yeni bir yönetim yaklaşımının benimsenmesini, yeni iş yapış yöntemlerinin oturtulmasını, farklı prensiplerin ve stratejilerin geliştirilip uygulanmasını kaçınılmaz hale getirmektedir. Yeni kamu yönetim yaklaşımı da bu gerekliliklerden yola çıkılarak benimsenmeye başlanan bir olgudur.

Kaynak: http://www.inomer.org/Inovasyon/Kamuda-Inovasyon

Yazılım Testi Metodolojileri

Yazılım Testi Metodolijileri – Yazılım Test Metodları

 

Yazılım testi kullanmak, yazılım geliştirme yaşam döngüsünün önemli parçalarından biridir. Etkin ve efektif test kodu oldukça önemlidir. Peki yazılım testi ne demektir ?

Yazılım testi, önceden belirtilen gereksinimleri karşılayıp karşılamadığını, doğru çıktıyı üretip üretmediğinikontrol eden yapıdır. Çok sayıda test durumu ve test stratejisi hazırlanır, bu testlerin hepsi belirli hedefleri (tüm sorunları kaldırmak,yazılımın hatasız çalışmasını sağlamak ve en iyi çıktıyı elde etmek) için uğraşır. Çok sayıda test tekniği ve metodolojisi bulunur. Yazılım test metodolojisi, yazılım testi tekniklerinden farklıdır.

 

 

Yazılım Test Metodları

Black-Box Test

Black-box test kod ya da tasarım ile ilgilenmez. Testler gereksinim ve fonksiyonellik üzerinedir. Black-box test aynı zamanda, Fonksiyonellik testi, Closed Box testi ya da Opaque testi olarak adlandırılır.

Black-Box testi, fonksiyonelliğe uygun veri seçimine ve seçilen verinin programın normal ve ya anormal davranış gösterimini izleme temeline dayanır.

Black-Box test stratejisinde, kullanıcı sistemin gereksinimlerini ve bu gereksinimlere nasıl cevap vereceğini bilmelidir. Black-Box testlerini iki gruba ayırabiliriz, bunlardan biri kullanıcı gereksinimi duymayan testler, diğeri ise kullanıcının gerekli olduğu testlerdir.

 

Kullanıcı Gereksinimi Duymayan Test Metodları

• Fonksiyonellik Testi: Fonksiyonel gereksinimleri test etmek için yazılmıştır.Eğer uygulama beklendiği gib davranırsa,testlerin yazılmasına sıralı bir şekilde devam edilir.

 

• Stres Testi: Çok sayıda veri girişi,büyük nümerik değerler,çok sayıda sorgu olduğu zaman kullanılır ve uygulamanın dayanıklılığını belirler.

 

• Yükleme Testi: Bir sistemin performansını derecelendirmek ve ya ağır yükler ve çok sayıda veri girişinde sistemin hangi noktada çakılacağını tespit etmek için kullanılır.

 

• Ad-Hoc Testi: Geçerli bir test yaratılmadan önceden kullanım için uygundur. Bu test diğer testlerin kapsama alanını ve diğer testlerin süresinin belirlenmesinde yararlı olur.

 

• Araştırma Testi: Ad-Hoc testine benzer ve uygulamayı öğrenmemizi sağlar. Uygulama hakkkında ön bilgimiz olur.

 

• Kullanılabilirlik Testi: Kullanıcı dostu test olarakta bilinir. Eğer kullanıcı arayüzü önemli bir yere sahipse ve ihtiyaçlar belirli bir kullanıcıya göre belirleniyorsa uygundur.

 

• Duman Testi: Mantık testi olarakta bilinir.Bu test,uygulamanın büyük testlere hazır olup olmadığını belirler ve küçük testleri başarı ile geçtiğini gösterir.

 

• Yenilenme Testi: Uygulamanın herhangi bir hataya karşı ne kadar sürede eski haline geleceğini test eder.Sistem gereksinimlerine göre,tip ve yenileme hızı belirlenir.

 

• Seviye Testi: Uygulamanın etkinliği ile ilgilenir.Uygulama tarafından çok büyük veri işlemi yapılırken, sistemin uç limitlerini kontrol eder.

 

 

Kullanıcının Gerekli Olduğu Testler

• Kullanıcı Kabul Testi: Kullanıcının sistemi test edip, gereksinimleri karşılayıp karşılamadığının incelenmesini sağlar.

 

• Alfa Testi: Kullanıcı geliştirme merkezine çağrılır. Geliştiriciler programı kullanır ve program hakkında not alır ya da kullanıcı işlemleri gerçekleştirir.

 

• Beta Testi: Kullanıcılara beta versiyon dağıtılır ve test etmesine izin verilir. Kullanıcılar sistemi inceler,herhangi bir sorun bulduğunda,geliştiriciye bildirir.

 

 

White-Box Test

Uygulamanın kodunu temel almaktadır.Kodun koşullarını, alanlarını ve açıklamalarını temel alır. White-Box testi, cam, açık kutu, temiz kutu olarak adlandırılmaktadır. Bu testte, testi yapan kişi sorunlu kısmı bulmak için kodu incelemelidir.

 

 

Avantajları

• Kodun optimizasyonunu sağlar.
• Ekstra kod parçasını kaldırır ve tek bakışta gözükmeyen sorunları ortaya çıkarır.
• Hangi verinin kodu en iyi şekilde test edeceğini tespit eder.

 

 

Dezavantajları

• Belirli özelliklere sahip test yapıldığında maliyet artar.
• Kodun inceleyip tek tek hata bulmak çok zor bir işlemdir.

 

 

White-Box Test Metodları

• Birim Test: Çalışan bir kod parçası ya da modül için, geliştiriciler tarafından gerçekleştirilir.Düşük seviyede işlem gerçekleştirir.

 

• Statik ve Dinamik Analiz: Statik analiz kodu sıralı bir şekilde inceler ve hataları araştırır. Dinamik analiz,kodun çalışmasını ve çıktıyı analiz eder.

 

• Açıklama Kapsamı: Açıklamaların test edilmesiyle ilgilenir.Her bir açıklama en az bir kez test edilir. Tüm açıklamaların sorun yaşamadan çalıştığını garanti altına alır.

 

• Sınıf Kapsamı: Hiçbir yazılım uygulaması sürekli olarak kodlanmaz, bazı noktalarda, kodun dağılışı incelemeli ve belirli bir fonksiyonu çalıştırılmalıdır. Tüm sınıflar doğrulanmasına yardım eder ve uygulamanın anormal davranış göstermesini engeller.

 

• Güvenlik Testi: Sistemin izinsiz erişimler, kod bozulması, hacklenme gibi olaylardan nasıl korunacağı ile ilgilenir. Karmaşık test metotları gerekir.

 

• Değişim Testi: Belirli bir hata düzeltildikten sonra yapılan bir testtir.Hangi kodun, stratejinin geliştirmeye yardımcı olacağını belirlemeyi sağlar.

 

 

Bazı testler hem White-Box hem de Black-Box kapsamında incelenebilir. Bunlara örnek verecek olursak;

 

• Fonksiyonellik Testi:Kodla birlikte fonksiyonelliği test eder.

 

• Birleştirme Testi:Uygulamaya yeni eklenen kod ile işbirliği yapar.

 

• Performans ve Yükleme Testi:Kodun hangi kısmının sistemin kaynaklarını yönettiğini ve performansı verilişini belirler.

Ahmet Sami Küçük

Kaynak:http://www.iztim.com/Blog/YazilimTeknolojisi/YAZILIM-METODOLOJI

Corporate Modeler – Tasarım Günlüğü Çalışması

Kullanılabilirlik ve İnsan – Bilgisayar Etkileşimi için, Tasarımını ve kullanımını incelediğim Casewise-Corporate Modeler için hazırladığım sunumu sizlerle paylaşıyorum.

Norman ve Nielsen prensiplerine göre de analiz edilen ürün için ayrıca 10 gerçek kullanıcının da bilgi ve tecrübelerine başvurulmuştur.

Çalışma için mail ile irtibata geçebilirsiniz: emrealic@live.com

İNSAN – BİLGİSAYAR ETKİLEŞİMİ

 Dizayn kuralları, kullanıcı için yazılım veya donanım kullanılabilirliğini maksimuma çıkarmak için kullanılır.(maximum usability)
 Dizayn kuralları, o kuralın uygulanma zorunluluğuna(authority) ve genele uygulanabilmesine(generality) bakılarak sınıflandırılabilir.
 3 tip dizayn kuralı bulunmaktadır ve bunlar :
1. Prensipler (Principles)
2. Standartlar (Standards)
3. Rehberler (Guidelines)
PRENSİPLER (PRINCIPLES)
 Bu kural tipi en soyut olanıdır.
 Genele uygulanabilirliği (generality) yüksek olup; uygulama zorunluluğu (authority) düşüktür.
 İlke kurallar da 3’e ayrılır:
1. Öğrenebilirlik
2. Esneklik
3. Dayanıklılık
ÖĞRENEBİLİRLİK
 Öğrenebilirliğin temel amacı; interaktif bir sistemin, deneyimsiz kullanıcıların o sistemi en baştan kullanabilmeleri ve en yüksek verimi almalarını saylağan özellikleridir.
 Öğrenebilirliği destekleyen 5 adet özel prensip vardır.
 Bunlar tahmin edilebilirlik, sentezlenebilirlik, aşinalık, genellenebilirlik, süreklilik.
 Tahmin edilebilirlik
 Kullanıcının, geçmiş etkileşimlere dayanarak gelecekteki hareketin yapacağı etkiyi tahmin edebilmesini sağlamaktır.
 Sentezlenebilirlik
 Kullanıcının, geçmiş operasyonların şu anki durum üzerine olan etkisini değerlendirebilmesini sağlamaktır.
ÖĞRENEBİLİRLİĞİ DESTEKYELEN PRENSİPLER
 Aşinalık
◦ Kullanıcının, diğer bilgisayar tabanlı sistemlerdeki bilge ve tecrübesinin yeni bir interaktif sistemde ne kadar uygulanabildiğidir.
 Genellenebilirlik
◦ Kullanıcının, spesifik bir etkileşim hakkındaki bilgisini diğer uygulamalardaki benzer durumlar için kullanabilmesini sağlamaktır.
 Süreklilik
◦ Benzer durumlarda benzer girdi-çıktı davranışının ortaya çıkmasıdır.
◦ Örnek olarak uçaklarda mürettebata yönelik uyarılar ;
◦ Kırmızı : Anında eylem
◦ Sarı : Nihai eylem
◦ Yeşil : Eylem gereksiz (Tavsiye)
ESNEKLİK
 Esneklik, son kullanıcı ve sistem arasında çeşitli yollardan yapılan bilgi alışverişlerinin tümüne verilen addır.
 Esnekliği etkileyen 5 faktör vardır.
 Bunlar diyalog başlatıcı, çoklu kullanım, !task migratability!, yerini alabilme, düzenlenebilirlik.
ESNEKLİĞİ ETKİLEYEN FAKTÖRLER
 Diyalog başlatıcı
◦ Kullanıcıya girdi girmede yeterliği özgürlüğün sağlanması anlamına gelmektedir.
 Çoklu Kullanım
◦ Sistemin birden fazla kullanıcı etkileşimini desteklemesine çoklu kullanım denir.
 Task Migratability
◦ Görev kontrolünün sistem ve kullanıcı arasında değişebilmesidir.
 Yerini alabilme
◦ Eşit değerlerin birbirinin yerini alabilmesine denir.
◦ Örnek olarak bir arayüze 1.5 inç girildiği zaman bu özelliğe sahip bir arayüzün bunun 3.81 cm olduğunu anlaması gerekmektedir.
 Düzenlenebilirlik
◦ Bir yazılımın kullanıcı arayüzünün kullanıcının isteğine göre sınırlı da olsa değiştirebilmesine olanak tanınmasıdır.
DAYANIKLILIK
 Bu prensip kullanıcının bir etkileşim sırasında ve sonucunda ulaşmak istediği hedeflere ulaşmasını sağlayan tüm özelliklere denir.
 Dayanıklılığı etkileyen 4 faktör vardır.
 Bunlar, gözlenebilirlik, kurtarılabilirlik, duyarlılık, görev uyumluluğu.
DAYANIKLILIĞI ETKİLEYEN FAKTÖRLER
 Gözlenebilirlik
◦ Bir sistemin iç durumunun arayüzdeki farkedilebilir simgelerle ortaya konmasıdır.
 Kurtarılabirlik
◦ Kullanıcının yapılan hatayı farkettikten sonra o hataya sebep olan eylemi geri alabilmesidir.
 Duyarlılık
◦ Kullanıcı ile sistem arasındaki iletişim hızına denir.
 Görev Uyumluluğu
◦ Sistem hizmetlerinin kullanıcının yerine getirmek istediği görevleri ve onları anlamasını sağlama derecesine denir.
STANDARTLAR
 Bu kural tipi daha spesifik olup kısıtlı uygulaması bulunmaktadır.
 Uygulama zorunluluğu (authority) ise daha yüksektir.
 Standartlar genel olarak bir interaktif sistem yaratmak için kullanılan donanım veya yazılımlarda kullanılır.
 Randall B. Smith, donanım ile yazılım arasındaki dizayn standartlarını etkileyen karakteristik farkları belirtmiştir.
 Donanım için belirlenen standartlar, fizyoloji veya ergonomik faktörleri anlamak üzerine kurulmuştur.
 Yazılım için belirlenen standartlar ise; psikoloji veya kavramsal bilime dayanmaktadır.
 Donanım ve yazılım arasındaki bir diğer farklılık da “değişim” den kaynaklanmaktadır.
 Donanım yazılıma göre değiştirilmesi daha zor ve pahalıdır. Sonuç olarak da donanım için değişim ihtiyacı yazılım için olduğundan çok daha az olmaktadır.
 Standartlar da stabil olduğundan donanım için yazılıma göre daha uygundur.
 Giriş
 Gövde Ebadı
 Gövde dayanıklılığı ve mukavemeti
 Çalışma yeri tasarımı
 Gerilim ve tehlikeler
 Görüş ve ışıklandırma
 Görsel ekran
 İşitsel bilgilendirme
 Sesli iletişim
 Kontroller
 Sürdürülebilir tasarım
 Sistemler
 Bu maddelerden sadece son 3’ü yazılım ile ilgilenmektedir.
 ISO 9241 kullanılabilirliği
 Etkililik
 Verimlilik
 Memnuniyet olmak üzere 3 başlıkla vermektedir.
 Bir standardın gücü onun ne kadar geniş bir kitleyi uymaya mecbur kılabildiğindedir.
REHBERLER
 Daha tavsiyeci ve genele uygulanabilir.
 Birçok rapor rehberlerle doludur.
 Kavramsal rehberler erken yaşam döngüsü için uygulanabilir.
 Spesifik rehberler geç yaşam döngüsü için uygulanabilir.
 Birçok rehber bulunurken bunlara en tipi örnek Smith ve Mosier tarafından ortaya konmuştur.
 Bu rehber temel kategorileri şunlardır:
1. Veri girişi
2. Veri görüntüleme
3. Dizi kontrolü
4. Kullanıcı rehberliği
5. Veri aktarımı
6. Veri koruma
ALTIN KURALLAR VE BULUŞSAL YÖNTEMLER
 Geniş yelpazeli tasarım kuralları
 Tasarım kuralları için kullanışlı bir kontrol listesi
 Hiçbirşey kullanmamaktansa bu kuralları kullanarak dizayn yapmak daha iyidir.
 Bunlara ik adet örnek:
◦ Norman’ın 7 Prensibi
◦ Shneiderman’in 8 altın kuralı
NORMAN’IN 7 PRENSİBİ
1. Hem dünyadaki hem de kafadaki bilgiyi kullan.
2. Görevlerin yapısını basitleştir.
3. Herşeyi görünür yap.
4. Atamaları doğru yap.
5. Kısıtlamarın gücünü sömür ; hem doğal hem de yapay olanların.
6. Hata için tasarla.
7. Diğer herşey çöktüğünde, standartlaştır.
Shneiderman’in 8 altIn kuralI
1. Tutarlılık için çabala.
2. Sık kullanıcıların kısayol kullanmasını sağla.
3. Bilgilendirici geribildirim sağla.
4. İletileri kapanış sağlayacak şekilde tasarla.
5. Hata önleme ve basit hata düzeltme sağla.
6. Eylemlerin kolay gerialımına izin ver.
7. Kontrolün içsel konumunu destekle.
8. Kısa dönem hafıza yükünü azalt.
HCI TASARIM DESENLERİ
 Başarılı tasarım çözümleri hakkındaki bilgilerin tekrar kullanılmasına yönelik bir yaklaşım.
 Mimari kaynaklı : Alexander örneği
 Bir desen belirli bir konu içerisindeki tekrarlayan problemlere değişmeyen bir çözümdür.
 Örnekler:
◦ Her odanın iki tarafındaki ışık (mimari)
◦ Güvenli bir yere geri dön (HCI)
 Desenler izole durumda değildir. Bunun yerine birbirine komple tasarım yaratabilecek dillerle bağlıdır.
DESEN KARAKTERİSTİKLERİ
 Tasarım pratiğini yakalar teoriyi değil.
 İyi tasarım örneklerinin ortak gerekli özelliklerini yakalar.
 Çeşitli seviyelerde tasarım bilgisi sunar.
 Değerleri somutlaştırır ve arayüz tasarımında neyin insancıl olduğunu belirtir.
 Girişimci ve okunabilirdir. Böylece tüm ilgili kişiler ile iletişime geçebilir.
 Bir desen dili yaratıcı olmalı ve komple tasarımların geliştirilmesine yardımcı olmalı.

*Zekeriya Sezgin BİRSURED’in derleme çalışmasından alıntı yapılmıştır. Kendisine Teşekkürler.

300 Milyon Dolarlık Buton

300 Milyon Dolarlık Buton

 

300 Milyon Dolarlık buton, kullanılabilirlik testi sonrasında sorunlu olduğu ortaya çıkarılıp üzerinde bulunan ‘Kayıt Ol’ yazısı ‘Devam Et’ ile değiştirilerek bulunduğu sitenin ilk ay 15 Milyon $, ilk yıl da 300 Milyon $ kazanmasını sağlayan butondur.

Kullanıcıların basit bir giriş formu ile kayıt olup alışveriş yapmasını bekleyen site sahipleri gerekli satış olmaması ve hatta satışların azalması sebebiyle kullanılabilirlik testi yaptırmaya karar veriyorlar. Test sonrasında ise kullanıcıların e-ticaret sitesinde “buraya alışveriş yapmaya geldim, biriyle ilişkiye başlamaya değil” düşüncesi ile kayıt olmaya direniyor oldukları ortaya çıkıyor.

Site istatistiklerine baklıdığında ise tüm kullanıcılarının %45′inin birden fazla hesaba sahip olduğu bazılarının ise en az 10 hesabı olduğu ortaya çıkıyor. Ayrıca günde ortalama 160.000 kadar kullanıcı da ‘Şifremi Unuttm’ linki ile şifresini hatırlamak için talepte bulunuyor.

Tün bu sonuçların sonunda alışveriş sayfası sonrasında ödeme yapmak için çıkan formda ‘Kayıt Ol’ butonu yerini ‘Devam Et’ butonuna bırakıyor. Formun altına da bir açıklama ekleniyor:

“Alışveriş yapmak için kayıt olmak zorunda değilsiniz. ‘Devam Et’ butonuna tıklayıp ödeme bölümüne geçebilirsiniz. Sonraki alışverişlerinizi daha hızlı yapmak için isterseniz ödeme adımında kayır olabilirsiniz.”

Kaynak: http://www.uie.com/articles/three_hund_million_button

Ten Usability Heuristics

by Jakob Nielsen

These are ten general principles for user interface design. They are called “heuristics” because they are more in the nature of rules of thumb than specific usability guidelines.

Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Match between system and the real world
The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
User control and freedom
Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
Recognition rather than recall
Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Flexibility and efficiency of use
Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.