GUI Tasarım İpuçları

Kaynağı: http://bryant2.bryant.edu/~dgannon/cis314/data/guttip.html

Akış - 1

• Akış dikey ya da yatay olmalı. En önemli bilgiler ekranın sol üst köşesinde yer almalı.
  
• İlişkili kontroller bir çerçeve ile bir arada tutulmalı.
  
• Küçük marginler ile kontrolleri bir arada tutmalı.
  

Komut Düğmeleri - 2

• Komut düğmelerini ekranın altında ortada ya da üst/alt sağ köşelerde tutmalı.
  
• Ekranda 6 dan fazla komut düğmesi barındırmamalı.
  
• En önemli düğmeyi ilk sırada kullanmalı.
• Komut düğmeleri diğerlerine göre daha ebatlı olmalı(görünürlüğü sağlanmalı)
• Eğer komut düğmeleri ekranın altında ortalı ise her düğme aynı yükseklikte olmalı ama farklı genişliklerde olabilir.
• Eğer komut düğmeleri bir köşede yığılmışlarsa, hepsi aynı yükseklikte ve genişlikte olmalılar.
  

Düğmeler - 3

• Düğmelere anlamlı metinler yazın.
  
• En az bir ya da en fazla 3 kelime tek satırda olmak üzere düğme metinleri oluşturun.
  
• Düğme metinlerinde baş harfleri büyük olmalı.
  

Etiketler - 4

• Arayüzdeki her kontrolü etiketle. Tek satırda en fazla üç kelime olsun.
  
• Her etiketi sola ve kontrolün ister üstüne ister soluna yerleştir.
  
• Etiketi ":" işareti izlesin ve ilk harf büyük olmalı.

Pencere - 5

• Pencere kenarının 2 veya 3 nokta berisinden başlamalır.
• Kontroller arasında 2 den 4 e kadar nokta aralıklarla konumlanmalı.

Resimler - 6

• İnsan gözü metinlerden önce resimleri farkeder. Eğer gerekliyse grafik kullanmak dikkat çekici olur, kullanımı hızlandırır.
• Estetik olmasını istiyorsanız küçük resimler kullanın ki dikkat dağıtıcı olmasın.
  

Yazı Tipleri - 7

• 8, 10, ya da 12 punto fontlar kullanmalı.
• Bir ya da iki font boyutları kullanılmalı.
  
• Sans Serif font tipini metinlerde kullanmalısınız.
  
• Tüm metinler için sadece bir font tipi kullanmalısınız.
  
• Eğik ve altı çizgili yazılardan uzak durmalısınız.
  

Renkler - 8

• İnsan gözü siyah beyaz renklerinden önce renklilere dikkat eder.
  
• Arayüzde siyah beyaz ve gri renkleri öncelikle kullanmalı, sonra gerçekten kullanmak için iyi bir nedeniniz varsa renklileri ekleyebilirsiniz.
  
• İster beyaz, kirli beyaz, açık gri, uçuk mavi(pastel mavi) veya pastel sarı renklerini uygulamanın arka planı için kullanıp metinleri siyah renk tercih etmeli.
  

Renkler - 9

• Daima koyu renkleri metinler için açık renkleri arka planlar için kullamalısınki okunması kolay olsun.
  
• Asla koyu renkli arka plana açık renkli metinler kullanma.
• Kullanacağın renkleri 3e kadar sınırla (siyah beyaz ve griden başka)
• Asla arayüz elemanlarının tanımlamasında renkleri kullanma.

Küçük Notlar...

Çevik metodolojiler:

• eXtreme Programming,
  
• Adaptive Software Development,
  
• Crystal Clear,
  
• Feature Driven Development,
• Lean Software Development.

Scrum, fazla dokümantasyon yapmadan, kısa periyotlarda geliştirme yapılıp, sonuçların müşteriye sıkça gösterildiği ve geribeslemeler doğrultusunda geliştirmelerin yönünün sürekli değiştiği, gereksiz geliştirmelerin minimuma indirilmeye çalışıldığı bir sürecin yönetimini üstlenir.

Scrum Süreçleri:

• Product Backlog, ( Projenin kapsamıdır.Proje sonunda beklenen sistemin özellik ve fonksiyonlarının önceliklerine göre yazıldığı bir liste dokümanıdır.Proje süresince bu doküman proje sponsoru tarafından sürekli güncellenir; yeni fonksiyon ve özellikler listeye eklenir, mevcut fonksiyon ve özelliklerin öncelikleri değiştirilebilir. )
• Sprint Backlog, ( Proje takımı, proje yöneticisi ile her sprint başlangıcında masaya oturarak yeni “sprint” dahilinde geliştirilecek özellik ve fonksiyonları belirler.Hiçbir zaman önceliği düşük bir özellik veya fonskyon önceliği yüksek bir özellik veya fonskyiondan önce geliştirilemez. Seçilen özellik ve fonksiyonlar Sprint Backlog denilen ikinci bir listeye aktarılır. )
  
• Sprint, ( Proje takımı bir sonraki sprint başlangıcına kadar bir daha Product Backlog’a bakmaz, o sprint dahilinde sadece ilgili Sprint Backlog listesine odaklanır.Sprint Backlog dahilindeki her özellik veya fonsksiyon için maksimum 3 günlük geliştirme süresi verilir. Bu sürede sözkonusu elemanın geliştirmesinin tamamlanmasına çalışılır. )
  
• Scrum toplantıları ( Scrum takımı her sabah Scrum Master eşliğinde “Scrum” denilen günlük toplantısını yapar. Bu toplantıya tüm takım üyeleri katılmak zorundadır. Scrum toplantısına proje takımı dışındaki diğer proje paydaşları da katılabilir; ancak onların toplantı sırasında kesinlikle konuşma hakları yoktur; sadece dinleyici olabilirler. Konuşan paydaşlar bir sonraki “Scrum” toplantısına alınmaz. Scrum toplantılarında kimse oturmaz; herkes ayaktadır. Scrum toplantısında bir önceki gün yapılanlar, o gün yapılacaklar, karşılaşılan ve karşılaşılabilecek riskler tartışılır. Scrum toplantısı en fazla 15 dakika sürer. )

Sprint Raporu:
Her sprint sonunda sprint raporu çıkarılır. Bu rapor, dikey ekseni Sprint Backlog’da bulunan ve daha geliştirilmemiş özellik ve fonskyion sayısını, yatay ekseni sprint gün sayısını gösteren iki eksenli basit bir rapordur. Her sprint için bir adet sprint raporu çıkarılır ve günlük olarak Scrum Master tarafından güncellenir. Sprint’in ilk günü yatay eksendeki değer en yüksektir, sprint sonuna doğru aşağıya doğru eğimli bir çizgi oluşur.

XP Practices

xp practice

Collective ownership
• Nobody owns any part of the code
• Anyone can work on anything
• Anyone’s code can be changed / deleted by anyone else

On-site customer
• Customer is considered to be an essential part of the team in XP
• Customer is a domain expert
• Always available (”on site”) to answer queries or make small-scale decisions
• Takes business and scheduling decisions
• May act on behalf of many users of system

Stories
• Customers or users write stories
• Each story captures one requirement scenario
• Typically recorded on standard index card for ease of management

A story card


Acceptance tests


Planning game

• Planning happens once at the start of each iteration
• Plan for just one iteration at a time
• Planning game is the main interface between customer and development team

How it works

• Customer provides all the story cards that have been written
• Developers write on each card an estimate of how long it will take to implement
• Developers provide an estimate of available developers X time (= “velocity”)
• Customer chooses stories by priority to fill the available time

Load factor

• Load factor is the multiplier that connects how long you think things will take to how long they actually take
• e.g. you think 2 days, it takes 6, so load factor is 3 (which is fairly typical!)
• You probably don’t need load factor calcs in this workshop because time units are small

Ideal time

• When load factor is in use, estimate in “ideal time” e.g. ideal days
• Divide velocity by load factor
• Commit to this amount of work per iteration
• After iteration, divide real time spent by ideal time estimated to get new load factor

Pair programming

• You probably noticed there’s only half as many computers as people...
• XP advises pair programming

Advantages

• Problems are solved much faster by 2 people
• Most trivial but annoying mistakes are caught immediately
• People learn from their partner
• coding techniques
• new parts of the system

Roles in a pair

• Typically, programmers take it in turns
• One codes or writes tests
• The other watches for mistakes, gives advice or thinks about the bigger picture
• They often talk about what they are working on and the next step they will take
• Is this what you’re experiencing?

Automated testing

• Testing is important in ensuring software is reasonably reliable
• If you release frequently a manual testing phase is a serious overhead
• In some scenarios it is difficult to reproduce test cases by hand
• Better to automate your tests and run them regularly (even almost continuously)

Simple design

• What’s the simplest thing that could possibly work?
• 90% of the time this is all you need
• It is easier to add complexity than to take it away
• Problems become more clear-cut when you already have a partial solution

Coding standards

• The code is the only guaranteed-correct documentation for a system
• You may have other documents and comments, but:
• these can get out of date
• they can become misleading

Refactoring

• Changing the way code is written / structured without changing what it does
• Enables
• readability improvements
• restructuring for testing
• just-in-time design
• Use tests to back up refactoring steps

40-hour week

• Don’t work more than a 40-hour week
• Long hours make more productivity only for a very short time
• System quality suffers a lot through long hours over long periods
• In XP, you go fast by maintaining the quality & fluidity of system

Practice interactions

Yazılım Mühendisliği

Burada yazacaklarım okuduğum "Yazılım Mühendisliği" kitabından ve internetten faydalandığım sunum dosyalarından küçük alıntılardır.Esasen kendime not etmekten öte bir gayem olmayıp doğru bilginin yayılmasında bir parça katkıda bulunmak içindir.

Konuyu daha derinlemesine öğrenmek için kitabı satın almanızı ve interneti kurcalamanızı tavsiye ederim.

Ekonomi	Tamlık	Yeniden Kullanılabilirlik	Etkinlik	Bütünlük
Güvenirlik	Modülerlik	Belgeleme	Kullanılabilirlik	Temizlik
Değiştirilebilirlik	Geçerlilik	Esneklik	Genellik	Sınanabilirlik
Taşınabilirlik	Bakılabilirlilik	Anlaşılabilirlik	Birlikte Çalışabilirlik

Yazılım Yaşam Döngüsü Temel Adımları:

1. Planlama
2. Çözümleme
3. Tasarım
4. Gerçekleştirim
5. Bakım

Yazılım Üretim Yaşam Döngüsü Kronolojik Olarak 5 Sınıfta İncelenir:

1. Gelişigüzel Model (60'lı yıllarda tek kişilik üretim ortamlarında kullanılan yöntemdir)
   
2. Barok Modeli
3. Çağlayan Modeli
4. V Modeli
5. Helezonik Model ve Uyarımları

Barok Modeli

1. İnceleme
2. Analiz
3. Tasarım
4. Kodlama
5. Modül Testleri
6. Altsistem Testleri
7. Sistem Testi
8. Belgeleme
9. Kurulum

Yaşam döngüsü temel adımlarının doğrusal bir şekilde geliştirildiği model.
70’li yıllar.
Belgelemeyi ayrı bir süreç olarak ele alır, ve yazılımın geliştirilmesi ve testinden hemen sonra yapılmasının öngörür.
Halbuki, günümüzde belgeleme yapılan işin doğal bir ürünü olarak görülmektedir.
Aşamalar arası geri dönüşlerin nasıl yapılacağı tanımlı değil.
Gerçekleştirim aşamasına daha fazla ağırlık veren bir model olup, günümüzde kullanımı önerilmemektedir.

ŞELALE MODELİ (http://en.wikipedia.org/wiki/Waterfall_model)

• Yaşam döngüsü temel adımları baştan sona en az bir kez izleyerek gerçekleştirilir.
• İyi tanımlı projeler ve üretimi az zaman gerektiren yazılım projeleri için uygun bir modeldir.
• Geleneksel model olarak da bilinen bu modelin kullanımı günümüzde giderek azalmaktadır.
• Barok modelin aksine belgeleme işlevini ayrı bir aşama olarak ele almaz ve üretimin doğal bir parçası olarak görür.
• Barok modele göre geri dönüşler iyi tanımlanmıştır.
• Yazılım tanımlamada belirsizlik yok (ya da az) ise ve yazılım üretimi çok zaman almayacak ise uygun bir süreç modelidir.
  

Sorunları:

• Gerçek yaşamdaki projeler genelde yineleme gerektirir.
• Genelde yazılımın kullanıcıya ulaşma zamanı uzundur.
• Gereksinim tanımlamaları çoğu kez net bir şekilde yapılamadığından dolayı, yanlışların düzeltilme ve eksiklerin giderilme maliyetleri yüksektir.
• Yazılım üretim ekipleri bir an önce program yazma, çalıştırma ve sonucu görme eğiliminde olduklarından, bu model ile yapılan üretimlerde ekip mutsuzlaşmakta ve kod yazma dışında kalan (ve iş yükünün %80’ini içeren) kesime önem vermemektedirler.
• Üst düzey yönetimlerin ürünü görme süresinin uzun oluşu, projenin bitmeyeceği ve sürekli gider merkezi haline geldiği düşüncesini yaygınlaştırmaktadır.

V MODELİ

V süreç modelinin temel çıktıları;

• Kullanıcı Modeli
• Geliştirme sürecinin kullanıcı ile olan ilişkileri tanımlanmakta ve sistemin nasıl kabul edileceğine ilişkin sınama belirtimleri ve planları ortaya çıkarılmaktadır.
• Mimari Model
• Sistem tasarımı ve oluşacak altsistem ile tüm sistemin sınama işlemlerine ilişkin işlevler.
• Gerçekleştirim Modeli
• Yazılım modüllerinin kodlanması ve sınanmasına ilişkin fonksiyonlar.
• Belirsizliklerin az, iş tanımlarının belirgin olduğu BT projeleri için uygun bir modeldir.
• Model, kullanıcının projeye katkısını arttırmaktadır.
• BT projesinin iki aşamalı olarak ihale edilmesi için oldukça uygundur:
• İlk ihalede kullanıcı modeli hedeflenerek, iş analizi ve kabul sınamalarının tanımları yapılmakta,
• İkinci ihalede ise ilkinde elde edilmiş olan kullanıcı modeli tasarlanıp, gerçeklenmektedir.

HELEZONİK MODEL

• Planlama
• Üretilecek ara ürün için planlama, amaç belirleme, bir önceki adımda üretilen ara ürün ile bütünleştirme
• Risk Analizi
• Risk seçeneklerinin araştırılması ve risklerin belirlenmesi
• Üretim
• Ara ürünün üretilmesi
• Kullanıcı Değerlendirmesi
• Ara ürün ile ilgili olarak kullanıcı tarafından yapılan sınama ve değerlendirmeler

Avantajları:

1. Kullanıcı Katkısı
• Üretim süreci boyunca ara ürün üretme ve üretilen ara ürünün kullanıcı tarafından sınanması temeline dayanır.
• Yazılımı kullanacak personelin sürece erken katılması ileride oluşabilecek istenmeyen durumları engeller.
2. Yönetici Bakışı
• Gerek proje sahibi, gerekse yüklenici tarafındaki yöneticiler, çalışan yazılımlarla proje boyunca karşılaştıkları için daha kolay izleme ve hak ediş planlaması yapılır.
3. Yazılım Geliştirici (Mühendis) Bakışı
• Yazılımın kodlanması ve sınanması daha erken başlar.
• Risk Analizi Olgusu ön plana çıkmıştır.
• Her döngü bir fazı ifade eder.
• Doğrudan tanımlama, tasarım,... vs gibi bir faz yoktur.
• Yinelemeli artımsal bir yaklaşım vardır.
• Prototip yaklaşımı vardır.
  

Evrimsel Geliştirme Süreç Modeli

• İlk tam ölçekli modeldir.
• Coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir (banka uygulamaları).
• Her aşamada üretilen ürünler, üretildikleri alan için tam işlevselliği içermektedirler.
• Pilot uygulama kullan, test et, güncelle diğer birimlere taşı.
• Modelin başarısı ilk evrimin başarısına bağımlıdır.

Örnek:

• Çok birimli banka uygulamaları.
• Önce sistem geliştirilir ve Şube-1’e yüklenir.
• Daha sonra aksaklıklar giderilerek geliştirilen sistem Şube-2’ye yüklenir.
• Daha sonra geliştirilen sistem Şube-3’e,…. yüklenir.
• Belirli aralıklarla eski şubelerdeki güncellemeler yapılır.

Aksaklığı:

• Değişiklik denetimi
• Konfigürasyon Yönetimidir
• Sürüm Yönetimi
• Değişiklik Yönetimi
• Kalite Yönetimi

Artırımsal Geliştirme Süreç Modeli

• Üretilen her yazılım sürümü birbirini kapsayacak ve giderek artan sayıda işlev içerecek şekilde geliştirilir.
• Öğrencilerin bir dönem boyunca geliştirmeleri gereken bir programlama ödevinin 2 haftada bir gelişiminin izlenmesi (bitirme tezleri).Her geliştirme süreci ile "henüz yazılmadı" içerikli özellikler sisteme eklenmiş olur.
  
• Uzun zaman alabilecek ve sistemin eksik işlevlikle çalışabileceği türdeki projeler bu modele uygun olabilir.
• Bir taraftan kullanım, diğer taraftan üretim yapılır.
• Her artımdan sonra çekirdek sürekli olarak gözden geçirilmekte ve bir sonraki artım bir öncekini içerecek tarzda üretim yapılmaktadır.Bu nedenlerle değişiklik yönetimi oldukça önem kazanmaktadır (Revizyon kontrol sistemlerinin kullanımı ve kod dokümantasyonu burada yüksek öneme sahiptir).
  

• Yap-at prototipi olarak ta bilinir.
• Araştırma ortamları bütünüyle belirsizlik üzerine çalışan ortamlardır.
• Yapılan işlerden edinilecek sonuçlar belirgin değildir.
• Geliştirilen yazılımlar genellikle sınırlı sayıda kullanılır ve kullanım bittikten sonra işe yaramaz hale gelir ve atılır.
• Model-zaman-fiyat kestirimi olmadığı için sabit fiyat sözleşmelerinde uygun değildir.

Örnek:

• En Hızlı Çalışan asal sayı test programı!
• En Büyük asal sayıyı bulma programı!
• Satranç programı!

METODOLOJİLER

1. Metodoloji: Bir BT projesi ya da yazılım yaşam döngüsü aşamaları boyunca kullanılacak ve birbirleriyle uyumlu yöntemler bütünü.
2. Bir metodoloji,
1. bir süreç modelini ve
1. belirli sayıda belirtim yöntemini içerir
3. Günümüzdeki metodolojiler genelde Çağlayan ya da Helezonik modeli temel almaktadır

Bir Metodolojide Bulunması Gereken Temel Bileşenler (Özellikler)
Ayrıntılandırılmış bir süreç modeli	Konfigürasyon yönetim modeli
Ayrıntılı süreç tanımları	Maliyet yönetim modeli
İyi tanımlı üretim yöntemleri	Kalite yönetim modeli
Süreçlerarası arayüz tanımları	Risk yönetim modeli
Ayrıntılı girdi tanımları	Değişiklik yönetim modeli
Ayrıntılı çıktı tanımları	Kullanıcı arayüz ve ilişki modeli
Proje yönetim modeli	Standartlar

Bir Metodolojide Bulunması Gereken Temel Bileşenler

Metodoloji bileşenleri ile ilgili olarak bağımsız kuruluş (IEEE, ISO, vs.) ve kişiler tarafından geliştirilmiş çeşitli standartlar ve rehberler mevcuttur. Kullanılan süreç modelleri ve belirtim yöntemleri zaman içinde değiştiği için standart ve rehberler de sürekli güncellenmektedir. Bir kuruluşun kendi metodolojisini geliştirmesi oldukça kapsamlı, zaman alıcı ve uzmanlık gerektiren bir faaliyet olup, istatistikler yaklaşık 50 kişi/ay’lık bir iş gücü gerektirdiğini göstermektedir.

Bir Metodoloji Örneği
Yourdan Yapısal Sistem Tasarımı Metodolojisi.
Kolay uygulanabilir bir model olup, günümüzde oldukça yaygın olarak kullanılmaktadır.
Çağlayan modelini temel almaktadır.
Bir çok CASE aracı tarafından doğrudan desteklenmektedir.

Yourdon Yapısal Sistem Tasarım Metodolojisi