En Çok Kullanılan Web Uygulama Mimarileri

8 Ağu

Web uygulama mimarileri, uygulamanın nasıl geliştirildiğinden, nasıl yayına alındığına kadar planlanan adımlar dizisidir. Günümüzde bir çok uygulama, IIS, Tomcat veya Nginx gibi ortamlarda tek bir application domain altında tek bir birimden oluşmuş şekilde çalışabildiği gibi, birden fazla application domaine hatta birden fazla sunucuya dağıtılmış şekilde çalışabilen uygulamalar mevcuttur. Bununla birlikte, tek bir dağıtım birimi ile deploy edilip çalışan uygulamalar bile, mantıksal olarak birkaç katmana ayrılabilmektedir. Yazılım mühendisliğinin amaçlarından biri de çok sık değişen kod ile az değişen kodu birbirinden ayırmaktır.

Genel olarak kullanılan mimariler Monolitik, N-Katmanlı ve Clean architecture olarak adlandırılabilir.

Monolitik (Tek katmanlı) uygulama nedir?

Monolitik uygulamalar, kullanıcı arayüzü ve veri erişim kodunun tek bir programda birleştirildiği tek katmanlı bir uygulama biçimidir. Uygulamanın sunucu ortamlarında dağıtılması tek bir birim şeklindedir. Böyle bir uygulamanın yatay olarak ölçeklenmesi gerekiyorsa, uygulamanın tamamı birden çok sunucu veya sanal makine arasında çoğaltılır.

Monolitik uygulama mimarisi proje yapısı

Bu uygulama mimarisinde, geliştirilen uygulamanın tüm birimleri tek bir projede tutulur, tek bir derlemede derlenir ve tek bir birim olarak dağıtılır.

Projede iş birimlerinden birbirinden ayrılması, klasörleme mantığına göre yapılır. Örneğin MVC pattern uygulanıyorsa Model, View, Controller, Data gibi klasörlere dağıtılmış bir şekilde geliştirme yapılır. Bu düzenlemede, uygulama görünümü ile ilgili detaylar Views klasörüyle, veri erişim uygulama detayları ise Data klasöründe tutulan sınıflarla sınırlandırılmalıdır. İş mantığı, Models klasöründeki servis ve sınıflarda bulunmalıdır.

Uygulanışı her ne kadar basit olsa da bu mimarinin dezavantajları vardır.

  • Teknolojik araçlardan veritabanına yazma işlemlerine, arayüz tasarımına kadar her şey tek bir projededir. Böyle bir ortamda aradığını yerli yerinde bulmak zordur.
  • Projenin boyutu ve karmaşıklığı arttıkça dosya ve klasörlerin sayısı da artar.
  • Kullanıcı arabirimi (UI) iş parçacıkları (Models, Views, Controller) birden fazla klasöre dağılmıştır.
  • UI tarafında, filter, model binder, exception partial modeller eklendikçe klasörler büyümeye ve karmaşıklık artmaya devam eder.
  • Business mantığı Models ve Services klasörleri arasında dağılmış ve hangi klasörlerin hangi sınıflara bağlı olması gerektiğine dair net bir gösterge yoktur.
  • Bir takım halinde çalışma sırasında birden fazla kişinin aynı dosya üzerinde çalışması gerekir ve çakışmalar artar.

Bu durumda uygulanabilirlik azaldıkça, sorunları daha rahat ele alabilmek için uygulamalar, çok projeli yapılara dönüştürülürler.

N-Katmanlı mimari nedir?

Uygulamaların karmaşıklığı arttıkça, bu karmaşıklığı yönetmenin bir yolu, uygulamayı sorumluluklarına veya iş birimlerine göre ayırmaktır. Bu ayrım, seperation of concerns olarak bilinir. Bu yöntem ile geliştiriciler, bir parçanın nerede geliştirildiğini rahatça karar verebilir ve takım geliştirmesi yapıyorlar ise aradıklarını kolayca bulabilirler. Katmanlı mimarinin bir dizi avantajları vardır.

  • Uygulama kodu ve işlevsellikler katmanlara bölündüğünden, kodda yeniden kullanılabilirlik arttırılır. Uygulama da DRY ( Don’t Repeat Yourself) ilkesi sağlanmış olur.
  • Hangi katmanların birbiri ile iletişim kuracağı belirlenerek encapsulation sağlanmış olur. Bir katmanda değişiklik meydana geldiğinde sadece onunla çalışan katman etkilenmelidir. Bu sayede bir değişikliğin uygulamanın tümünü etkilemesi engellenmiş olur.
  • Katmanlar sayesinde uygulama işlevselliğini değiştirmek kolaylaşır. Örneğin bugün Oracle veritabanı ile çalışan sistem bir süre sonra Postgresql ile çalışma ihtiyacı duyduğunda, data interface ile Postgresql implementasyonu yapan yeni bir sınıf ile kodda çok fazla değişkliğe neden olmadan yeni bir altyapı eklenebilir.
  • Test edilebilirliği kolaylaştırır. Uygulamanın gerçek veri katmanına veya UI katmanına ait çalışan testler yazmak yerine, bu katmanlar test zamanında isteklere bilinen yanıtlar sağlayan sahte (Moq) uygulamalarla değiştirilebilir
Uygulama katmanları

Bu mimariye göre kullanıcılar uygulamaya User Interface üzerinden istekte bulunurlar. User Interface katmanı ise yalnızca Business Logic katmanı ile iletişim kurar. Business Logic katmanı da Data Access katmanından veri isteği yapar. User interface doğrudan Data Access katmanına erişemez. Business Logic katmanı da doğrudan veriye erişmemelidir, veri talebini Data Access katmanından yapmalıdır. Yani her katmanın kendine ait sorumluluğu bulunur.

N-Katmanlı uygulama mimarisi proje yapısı

Bu mimari her ne kadar tek projeli yapıyı çok projeli hale dönüştürse de bazı dezavantajları vardır.

  • Derleme zamanı bağımlılıkları (dependencies) yukarıdan aşağıya doğru çalışır. Yeni UI katmanı BLL katmanına, BLL katmanı da DLL katmanına bağlıdır. Bu, genellikle uygulamada en önemli mantığa sahip olan BLL’nin veri erişimi uygulama ayrıntılarına ve hatta bir veritabanının varlığına bağlı olduğu anlamına gelir. Böyle bir mimaride iş mantığını test etmek genellikle zordur ve bir test veritabanı gerektirir.
  • Deployment tek bir birim olarak yapılır. Bu uygulama enterprise amaçlar için birkaç projeye bölünmüş olsa da, tek bir birim olarak dağıtılır ve istemcileri onunla tek bir web uygulaması olarak etkileşime girerler.

Clean architecture nedir?

N katmanlı mimaride bahsedilen yukarıdan aşağı doğru bir derleme bağımlılığını ortadan kaldırmak için çeşitli çalışmalar yapılmıştır. Dependency Inversion ve Domain Driven Design gibi yaklaşımlar aslında benzer bir mimariye ulaşma eğilimindedirler. Bu mimari yıllar içinde birçok isimle anıldı. İlk isimlerden biri Hexagonal Architecture, ardından Ports-and-Adapters oldu. Son zamanlarda, Onion Architecture veya Clean Architecture olarak anıldı.

Clean Architecture mimarisi, Business Logic ve Application modelini uygulamanın merkezine (Application Core) koyar. Business Logic veri erişimine veya diğer infrastructure sorunlarına bağlı olması yerine, bu bağımlılık tersine çevrilir: infrastructure ve application ayrıntıları Application Core bağlıdır. Bu işlevselliği sağlamak için Application Core tarafında interface veya abstraction tanımlamaları yapılıp, bu soyut tiplerin implementasyonları da Infrastructure tarafında yapılarak sağlanır. Bu mimariyi görselleştirirken, soğana benzer bir dizi eş merkezli daire kullanmaktır.

Clean Architecture

Bu diyagramda, bağımlılıklar dıştan, en içteki daireye doğru akar. Application Core, adını bu diyagramın merkezindeki konumundan alır. Ve diyagramda, Application Core diğer uygulama katmanlarına bağımlılığı olmadığı görülür. Entity ve Interface tipleri tam merkezdedir. Hemen dışında, ancak yine de Application Core içerisinde, genellikle iç çemberde tanımlanan Interface tiplerini implemente eden domain servisleri bulunur. Application Core dışında, hem UI hem de Infrastructure katmanları, Application Core’a bağlıdır, ancak birbirine bağlı değildir.

Clean Architecture yatay mimari görünümü

Düz okların derleme zamanı bağımlılıklarını, kesikli ok ise yalnızca çalışma zamanı bağımlılığını temsil eder. Clean Architecture ile UI katmanı, derleme zamanında Application Core üzerinde tanımlanan arabirimlerle çalışır ve ideal olarak Infrastructure katmanında tanımlanan uygulama türlerini bilmemelidir. Ancak çalışma zamanında, bu implementasyon türleri uygulamanın yürütülmesi için gereklidir, bu nedenle mevcut olmaları ve bağımlılık ekleme yoluyla Application Core interface tiplerine bağlı olmaları gerekir.

Clean Architecture uygulanan ASP.NET Core uygulaması.

Clean Architecture Katman Yapısı

Katman yapısı oluşturulurken, katmanlara ait projelerin birbirine karışmaması adına öncelikle bir klasör modeli oluşturulabilir.

Daha sonra projeler bu düzene göre kolayca eklenebilir.

Clean Architecture proje yapısı

Presentation

Bu katmanda, kullanıcının uygulama ile iletişim kuracağı ara yüz uygulamaları oluşturulur. Örneğin bir Web Api veya bir desktop uygulama gibi düşünülebilir. Hiç bir katman, en üstte bulunan bu katmana bağımlı olamaz.

Infrastructure

Bu katmanda, uygulamanın dış dünya ile iletişim kurabileceği modüllerin somut implementasyonları yapılır. Örneğin Entity Framework veya NHibernate gibi framework kullanarak veritabanı işlemlerinin gerçekleştirilmesi. Ya da bir SMTP servisine erişerek mail gönderen işlemleri gerçekleştiren sınıfların oluşturulması gibi düşünülebilir.

Core

Bu katmanda Application ve Domain projeleri bulunur.

Domain projesi uygulamanın en soyut ve diğer katmanların hiç birini referans almayan çekirdektir. Entity, Value Objects, Exception ve Enumeration gibi tipleri burada bulunur. Örneğin bir Order entity tipinde, status ve tarih özelliğinin bulunması gibi iş kuralları burada belirlidir.

Application ise uygulama kuralarının belirlendiği projedir. Yani Entity tiplerinin nasıl kullanılacağı burada belirlenir. Application katmanı sadece Domain katmanına bağımlıdır ve oradaki bileşenleri kullanarak iş kuralları oluşturur. Örneğin işimiz ürün satmak ise, sipariş vermek bizim için bir kullanıcı senaryosu olabilir. Bu hizmeti kullanıcıya sunmak için öncelikler ürünün stokta olup olmadığını kontrol etmek ve ardından siparişi oluşturmak gerekir. Bunlar uygulamanın kurallarıdır. Ayrıca uygulamanın interface, abstract gibi business soyutlamaları Application projesinde bulunur. Fakat somut implementasyonları infrastructure katmanında bulunur. Örneğin IProductRepository interface Application projesinde ise, bunu implement eden ProductRepository class Infrastructure projesindedir.

Özet

Tek projeli monolitik yapılar, küçük çaplı ve dağıtık deployment gerektirmeyen proje çözümler için uygundur.

Katmanlı mimari sayesinde tek projeli yapılar birden fazla projeye bölünerek daha yönetilebilir ve takım geliştirmesine uygun hale getirilebilir. Ancak katmanlı mimarilerde core modüllerinin diğer modüllere bağımlılığı oluşmaktadır.

Clean Architecture mimarisi de bu bağımlılığı ortadan kaldırmaktadır. Bağımlılıklar, uygulamanın en önemli parçası olan Application Core katmanına doğru gelişmektedir. Bu sayede katmanlarda test edilebilirlik artar, uygulamanın merkez modülü olan Application Core, soyut bir özellik kazanarak üçüncü parti framework bağımlılıkları ortadan kalkar ve modülü test etmek için her hangi bir database ihtiyacı kalmaz. UI katmanının da aynı şekilde framework ve diğer katmanlar ile sıkı bağı kalmaz. Ancak deployment sırasında uygulamalar bu üç mimaride de bütün olarak deploy edilir.

Not: Uygulamaların önyüz, backend veya feature modüllerini birbirinden ayırarak her birinin ayrı bir servis halinde deploy edilebilmesini sağlayan mimariler, dağıtık mimariler olarak adlandırılır. Dağıtık deploy edilebilen servislerin dağıtık bir şekilde, farklı takımlar ile geliştirilmesi sağlanabilmektedir. Günümüzde dağıtık mimarilerden, özellikle e-ticaret sektöründe en çok tercih edilen mimari, mikro servis mimarisidir. Unutulmamalıdır ki her bir mikroservis özünde monolitik bir uygulamadır. Mikro servisler boyutu küçük olan servisler olarak anlaşılmamalıdır. Tek başına deploy edilebilen servisler olarak anlaşılmalıdır.

Sonuç

İyi mimariler bağımsız modüller yaratmak içindir. İyi yapılandırılmamış bir monolitik uygulama dahi geliştirilemiyorken, probleminize mikroservislerin çözüm olacağını düşünmemek yanlıştır.

Kaynak

https://docs.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures

Karmaşık Yazılım Oluşturmanın Genel Sorunları

19 Oca

Karmaşık yazılımlar denildiğinde akla gelen ilk yöntem Domain Driven Design (DDD) olur. DDD yaklaşımını etki alanına dayalı yazılım olarak tercüme edilebilir. Etki alanı demek üzerinde çalışılan sektör ya da bölüm olarak düşünülebilir. Örneğin finans, e-ticaret, hastane, hava yolu, demir yolu vs gibi alanlar yazılımlar için etki alanları ya da Domain’ler olarak adlandırılabilir.

Etki Alanına Dayalı Tasarım (DDD), Eric Evans tarafından “Domain Driven Design: Tackling Complexity in the Heart of Software” adlı eserle ortaya atılan bir geliştirme felsefesidir. DDD, ekiplerin karmaşık sorun etki alanları için yazılımın geliştirilmesi ve bakımının etkin bir şekilde yönetmesini sağlayan bir yazılım geliştirme yaklaşımıdır. Bu yöntem bir programlama paradigması veya kodlama yöntemi değildir. Bu yöntem kodlamadan önce, çalışılacak iş ortamını(domain) tanımak, çalışma alanındaki gerçek dünyayı anlayarak düzgün bir şekilde tasnif etmektir diyebiliriz. Yazılımda yaşanan sorunların çoğu domain içinde saklıdır.

Karmaşık yazılımın zorlukları

Heyecanla ve pembe hayallerle başlanan karmaşık iş uygulamalarının modeli, zamanla en popüler yazılım mimari tasarım modeli olan Big Ball of Mud (BBoM) modeline dönüşür. Bu model Brian Foote ve Joseph Yoder tarafından yazılan bir makalede “gelişigüzel yapılandırılmış, özensiz, koli bandı ve balya teli yumağı, spagetti kodu ormanı” diye tarif edilmiştir. Bu modelde ayırt edilebilir mimariye sahip olmayan uygulamalar için kullanılır. (Bir tabak spagettiyi hayal edebilirsiniz.)

Şekil-1 de görüldüğü üzere yazılımdaki karmaşanın iki sebebi vardır.

  • Yazılımın karmaşık ve yönetilmesinin zor olmasının ana nedenlerinden biri, alan karmaşıklıklarının teknik karmaşıklıklarla karıştırılmasıdır.
  • İş akışındaki rutin değişiklikler ve küçük özellik geliştirmelerinin, mevcut kodu okuma ve anlamadaki zorluklar nedeniyle uygulanmasının zor olması.
Şekil-1 Yazılımdaki karmaşıklık.

Ortak Bir Dil Olmadan Oluşturulan Kod

İş uzmanlarıyla çalışan ekiplerin domain ortamında kullanılan kavramları, zengin kelime dağarcığı ile doğru bir şekilde yazılım ekiplerine aktarması gerekir. Aksi halde yeni domain kavramları ortaya çıkarılamaz veya geç ortaya çıkarılır maliyetler artar. Bu noktada, iş uzmanları ile geliştirme ekipleri arasında ortak bir dil oluşur. Ortak bir dile odaklanma eksikliği ve sorunlu domain bilgisi neticesinde, çalışan ancak işletmenin amacını ortaya çıkarmayan bir kod tabanı ortaya çıkar. Bu, kod tabanlarının okunmasını ve yönetilmesini zorlaştırır. Çünkü analiz modeli ile kod modeli arasındaki çeviriler maliyetli ve hataya açık olabilir. Sonuçta işletmenin analiz modelinden uzaklaşan kod yapısı ile uygulama bir BBoM modeline dönüşebilir.

İşletme analiz modeli nedir?

Yazılımın nasıl inşa edildiğini anlamak için teknik olmayan kişilerin kavramsallaştırabileceği yazılımın temsilidir. UML gibi modelleme dilleri kullanılarak temsil edilebilir. Bir yazılım uygulamasının mantıksal tasarımını ve yapısını tanımlamak için bir analiz modeli kullanılır.

Organizasyon Eksikliği

BBoM’ye dönüşen bir sistemin ilk üretimi çok hızlıdır. Belli bir domain etrafında kavramsallaştırılmamış uygulamalarda yeni geliştirmeler eklemek veya var olan özellikleri değiştirmek zahmetlidir. Kod tabanı, değişikliği yönetilebilir kılmak için iş davranışıyla gerekli uyumdan yoksundur. Problemin karmaşıklığı, teknik çözümün karmaşıklığı ile karıştırılır.

Şekil-2 Kod çürümesi.

BBoM Deseninin Gelişimi Engellemesi

Spagetti benzeri bir desenle ısrar etmeye devam etmek, özellik geliştirme hızını yavaşlatır. Kod tabanının anlaşılmaz karmaşası nedeniyle, ürünün yeni sürümleri çıktığında hatalar oluşabilir. Zamanla, geliştirme ekibi böylesine bir karmaşa içinde çalışmanın zorluğundan giderek daha fazla şikayet eder. Projeye iş gücü kaynakları eklense bile hız, işi tatmin edecek seviyeye çıkarılamaz. Sonunda, durumdan bıkmış olarak, uygulamanın yeniden yazılması talebi kabul edilir. Başlangıçta hızlı geliştirilen ve teslim edilen uygulama, sonuçta olarak bir kabusa dönüşür.

Problem Alanına(Domain) Odaklanamama

Üzerinde çalıştığınız iş alanını anlamadan geliştirdiğiniz projeler başarısız olur. Yazılım projelerinin yapılması zor veya tıkandığı yer kodlama değildir. Kodlama, sürecin kolay bir bölümüdür. Zor olan, üzerinde çalışılan iş alanına faydalı, istekleri tam olarak yerine getirebilen bir yazılım modelini oluşturmak ve sürdürebilmektir.

İş alanınızı anlamaya ne kadar çok yatırım yaparsanız, iş sorunlarını çözmek ve onu yazılımda modellemek için o kadar donanımlı olursunuz.

Problem alanı(domain) nedir?

Problem alanı, üzerinde çalıştığınız ve yazılım geliştirdiğiniz alanı ifade eder. DDD bize karmaşık iş alanları için yazılım oluşturmaya çalışırken, her şeyden önce problem alanına odaklanmayı önerir. Faydalı bir yazılımın ortaya çıkabilmesi için alanında uzman kişiler yazılım ekipleriyle birlikte çalışır. Örneğin, sağlık sektöründe hasta kayıt yazılımı için doktor kadar bilgi sahibi olmaya gerek yoktur. Bilinmesi gereken, ilgili sağlık terimleri, kavramları, farklı departmanların hastalara ne tür işlemler yaptırdığı ve doktorların hastalardan neler talep ettiğidir.

Kaynaklar

  • Patterns, Principles, and Practices of Domain-Driven Design
  • Domain-Driven Design: Tackling Complexity in the Heart of Software

Yazılımda Arayüz Değerlendirmesi

21 Haz

Bir sistemin değelendirilmesi, sistemin kalitesi hakkındaki bilgilerin toplanması ile gerçekleştirilebilir. Sistemin kalitesi belli değerlendirme kriterleri neticesinde ortaya çıkan bir disiplindir. Kaliteli bir sistem, müşteriye işin ciddiyetini ve önemini yansıtan bir göstergedir.

Genel olarak bir sistemin kalitesini ortaya koyan kriterler şu şekildedir:

  1. Fonksiyonellik: Sistemin istenen fonksiyonları içermesi ve yerine getirebilmesidir.
  2. Kullanılabilirlik: Sistemin iş süreçlerinde görevlerini yerine getirebilmesidir.
  3. Bakılabilirlik: Sistemin desteklenmesi ve gerekli değişikliklerin yapılabilmesi imkanıdır.
  4. Güvenilirlik: Sistemin her zaman aynı doğrulukta ve yeterlikte sonuçlar verebilmesidir.
  5. Taşınabilirlik: Sistem farklı ortamlara adapte olabiliyor mu?

Bu özellikleri taşıyan bir sistem kaliteli bir sistem olarak değerlendirilir.

Yazılımda Arayüz Değerlendirme İlkeleri

Arayüz yazılımın kullanıcı ile iletişim halinde olan bölümüdür. Bu nedenle arayüz değerlendirmesi daha çok sistemin kullanıcı tarafından algılanan kalitesini incelemeyi hedefler. Yukarıda tanımlanan kalite kriterleri kullanıcı tarafından yazılım arayüzünde değerlendirilir. Değerlendirmenin doğru yapılması ile sistem daha kullanılabilir ve faydalı geliştirmelerin sistem üzerinde yapılabilmesi sağlanır.

Bir arayüzün değerlendirmesi ilgili kriterlere uygunluğun incelenmesi ve kullanıcı kabul testlerinin yapılması adımlarını içerir. Yalnızca kullanıcı testleri ya da prensiplere uygunluğun değerlendirilmesi yeterli değildir. Arayüz tasarımının farklı aşamalarında arayüz değerlendirilmesi yapılır. İdeal olarak birinci değerlendirme herhangi bir uygulama programı yapılmaya başlamadan gerçekleştirilmelidir. Son değerlendirme ise sistemin aktif olarak kullanımı sırasında yapılmalıdır. Bunlara ek olarak tüm tasarım ve uygulama sürecinde, sürekli olarak çeşitli aşamalarda arayüz değerlendirmesi yapılmalıdır.

Buluşsal (Heuristic) Değerlendirme

Bir arayüz tasarımının buluşsal değerlendirmesi, göreceli olarak basit kılavuz kurallara göre bu kurallara uygunluğun belirlenmesi biçiminde gerçekleştirilir. Bu kılavuz kurallar yardımı ile sistem farklı değerlendiriciler tarafından değerlendirilir. Bu değerlendiriciler genellikle kullanıcı arayüz tasarımı ve insan bilgisayar etkileşimi konularında tecrübeli uzmanlardan seçilir. Programcı veya sitemin gerçek hayattaki kullanıcıları olmak zorunda değildir.

Buluşsal değerlendirme, tasarımın ilk aşamalarında gerçekleştirilmelidir, çünkü ciddi kullanım problemlerinin erken aşamada bulunması, bu problemlerin daha kolay çözümlenmesini ve bazı durumlarda göz ardı edilmemesini sağlar.

Problemin ciddi boyutları değerlendirilmeli ve tasarımcılarla problemin ortadan kaldırmanın zorluğu hakkında tartışılmalıdır.

Değerlendirme Kuralları

1- Sistem Durumunun Görünürlüğü

Kullanıcılar sistemde ne olup bittiği hakkında bilgilendirilmelidir. Arayüze yerleştirilen durum göstergeleri, ilerleme çubukları gibi görev tamamlama durumunu ifade eden arayüz bileşenleri kullanılabilir.

2-Gerçek Hayat ve Sistem Arasındaki Uyum

Kullanıcının gerçek hayatta kullandığı kelimelerin seçilmesine özen gösterilmelidir. Tasarımcı olarak kendi anlayacağımız ifadeleri kullanıcıya sunmamız hatalı sonuçlara yol açabilir.

Örneğin arayüzdeki düğmelerde veya araç çubuklarında kullanılan ikonlar gerçek hayata dair figürler içerir. İnternet tarayıcılarında, geçmişte kullanılan sayfalar menüsüne ait düğmeler saat veya zaman ifade eden resimler içerirler. Ya da bir bankamatik arayüzünde kullanılan metinler ve düğmeler yaşlı-genç her yaştan kullanıcının bu sistemi kullanabileceği hesap edilerek tasarlanmalıdır.

3-Kullanıcı Kontrolü ve Özgürlüğü

Arayüzlerde geri alma ve yeniden yapma işlemlerinin desteklenmesi ve ihtiyaç halinde kullanıcılara “acil çıkış”, “geri dönüş” gibi olanakların sağlanması gereklidir. Böylece hata durumlarında kullanıcılar yaptığı işleri geri alabilir ve hata yapmaktan korkmazlar. Aksi halde kullanıcı kendini güvende hissedemeden hareket edecektir.

4-Tutarlılık ve Standartlara Uygunluk

Aynı platform üzerinde farklı yorumlara yol açmayacak anlamlı bileşenler kullanılmalıdır. Kullanıcılar aynı anlama gelen farklı kelimelerin aynı işi mi yoksa farklı işi mi yaptığını çözmeye uğraşmamalıdır. Arayüzde kullanılan ikon ve arayüzler de dahil olmak üzere bir standarta uygun olmalıdır.

Örneğin yenile butonunda bulunan ifade hemen hemen bütün yazılımlarda aynı resimle veya metinle ifade edilir. İnternet Explorer ve Google Chrome kullanıcıları sayfayı yeniden yükleme, ileri, geri gibi işlemlerine farklı platformlar olsa da hemen adapte olabilmektedirler. Her iki platformda da ikonlar üzerindeki ifadeler aynıdır.

5-Hata Önleme

Tasarımlar yapılan hataların düzeltilmesi hedeflenerek değil, hataların daha yapılmadan engellenmesi hedeflenerek gerçekleştirilmelidir.

Örneğin bir işlem sırasında kullanılmayacak olan komut düğmelerinin pasif durumda olması yanlış kullanıcının işlemler yapmasını engeller. Ancak düğmenin aktif olarak bırakılıp kullanıcı tıkladığında “Bu işlemi bu aşamada gerçekleştiremezsiniz!” şeklinde uyarı vermek doğru değildir.

6-Hata Fark Etme

Hatırlamadan daha çok fark etme ve seçmeye ağırlık verilmelidir. Nesneler, aksiyonlar, komutlar ve opsiyonlar kolayca görülür bir biçimde sunulmalıdır.

Örneğin menü ve araç çubuklarında kullanıcıların kolayca fark edeceği  seçenekler sunulur.

7-Kullanımın Esnekliği ve Verimliliği

Arayüzler tek düzey kullanıcılara hitap edecek şekilde tasarlanmamalıdır. Hem deneyimli kullanıcıların, hem de deneyimsiz kullanıcıların kendilerince kolay kullanabilecekleri biçimde tasarlanmalıdır. Sık kullanılan komutlar ve komut bileşimleri için kişiselleştirme olanakları tanınmalıdır.

Örneğin kullanıcı bir komutu menüden seçebilir, kısa yol tuşu kullanabilir ya da hızlandırma tuşları ile klavye yardımıyla fare kullanmadan menüdeki aynı komutu seçebilir. Deneyimli kullanıcıların daha çok kısa yol tuşlarını kullandıkları gözlenmektedir.

8-Estetik ve Minimalist Tasarım Yaklaşımı

Çok fazla ihtiyaç duyulmayan ya da arada bir ihtiyaç duyulan bilgiler her seferinde ekranda gösterilmemelidir. Kullanıcıya olabildiğince az sayıda seçenek sunulur ancak ihtiyaç duyulduğunda bir düğme yardımıyla ek seçenekler görüntülenir.

9-Hata Mesajları

Kullanıcıların hatalarını fark etmeleri, çözümlemeleri ve bu hataları düzeltebilmeleri için gerekli yardım yapılmalıdır. Bu amaçla hata mesajları, kullanıcıya neyi yanlış yaptığını bildiren ve nasıl düzeltebileceğini açıklayan bilgiler içermelidir. Bu mesajlar kullanıcının diliyle kullanıcıya verilmelidir. Aksi halde ingilizce bilmeyen biri ingilizce bir mesajı anlayamayacaktır.

10-Dokümantasyon ve Yardım

Kolayca arama yapılabilir bir yardım sunulmalı, bu yardım kullanıcının yapmakta olduğu işe yönelik özelleştirilmiş olmalıdır. Örneğin F1 tuşu neredeyse tüm programlarda ortak bir şekilde kullanıcıya “yardım “ekranını gösterir.

Buluşsal Değerlendirmenin Tamamlanması

Buluşsal değerlendirmede izlenmesi gereken dört adım vardır.

Adım-1

Değerlendirme yapan kişinin sistemin konusu hakkında ve değerlendirilen konu hakkında yeterli bilgi sahibi olması gerekmektedir. Eğer bilgi sahibi değilse bu konuda kesinlikle bilgilendirilmelidir.

Adım-2

Değerlendirmelerin değerlendiriciler tarafından birbirinde bağımsız olarak yapılması mutlaka sağlanması gereken şarttır. Bağımsız olarak yapılan değerlendirmeler daha sonradan birleştirilmelidir. Her değerlendirici görmüş olduğu problemin bir listesini hazırlamalıdır.  Örnek: “Font rengi ve boyutunun sayfasan sayfaya farklılık arzetmesi, tutarlılık ve standartlara uyum ilkesini ihlal etmektedir.” Önerilen çözüm ortak font stilinin oluşturulmasıdır.

Adım-3

Her probleme, problemin ciddiyetini belirleyen bir numara verilmelidir. Örnek numaralandrıma:

  • 0: Değerlendiriciler arasında problemin arayüz problemi olup olmadığı konusunda hemfikir olamadıkları hafif problemler.
  • 1: Kozmetik problem.
  • 2: Küçük kullanılabilirlik problemi.
  • 3: Ciddi kullanılabilirlik problemi. Düzeltilmesi çok önemlidir.
  • 4: Felaket derecede problem. Mutlaka düzeltilmelidir.

Örneğin:

  • Problem: Silme işleminde uyarı mesajı verilmiyor.
  • İhlal Edilen Değerlendirme Kuralı: 1
  • İhlal Edilen Ciddiyet: 2
  • Not: Tasarımcının bunu düzeltmesi rica edilir.

Adım-4

Tasarım ekibi ile tartışma oturumu yapılır. Bu tartışmada kullanılabilirlik problemlerinin düzeltilmesi için izlenecek adımlar veya bunu düzeltmenin zorluğu ve maliyeti hesaplanır.

Buluşsal değerlendirmenin, hızlı değerlendirme yapabilme ve yüksek getiri sağlayan bir yönü vardır. Ancak değerlendiricilerin uzmanlık alanı uyuşmazlığı sebebiyle bazı problemler gözden kaçabilir.

Yazılımda Bakım Süreci ve IEEE 1219 Standardı

16 Haz

Sınama işlemleri bitirilen yazılımın kullanıcı ortamına yüklenmesi ve uygulamanın başlatılması gerekmektedir. Kullanıcı ortamı sunucu, desktop veya mobil platformalar olabilir. Yazılım devreye alındıktan sonra, yaşam döngüsünün en önemli ve hiç bitmeyecek aşaması olan “bakım” aşaması başlar.

Maintenance-Job

Müşteriye teslim edilmiş ve devreye alınmış çalışmakta olan yazılımın üç tür bakım gereksinimi bulunmaktadır.

1-Düzeltici bakım

Bir yazılımın 100% sınanabilmesi teorik olarak mümkün olsa da pratikte pek mümkün değildir. Bu nedenle hata ile karşılaşabilme olasılığı her zaman vardır. Zamanla ortaya çıkan hataların düzeltilmesi “düzeltici bakım” olarak adlandırılır.

2-Uyarlayıcı bakım

Uygulamaya alınmış yazılımlar kurumların, şirketleri veya kişilerin günlük hayattaki işlerini bilgisayar ortamında takip etmesini sağlayan araçlardır. Gün geçtikçe iş süreçlerinde yeni gereksinimler veya var olan gereksinimlerin iptali söz konusu olabilmektedir. Örneğin mevzuatların değişmesi, bir kurum yazılımında ilgili bölümün değişmesi anlamına gelmektedir. Bu tür uyarlamalar yazılımda “uyarlayıcı bakım” olarak adlandırılır.

3-En iyileyici bakım

Uygulama yazılımının performansının zamanla arttırılması gerekebilir. Bu tür bakımlar “en iyileyici bakım” olarak adlandırılır.

Yazılım bakımı, uluslararası standart belirleme organizasyonu olan IEEE(i triple e) tarafından belirli kriterlere ve aşamalara göre gerçekleştirilmektedir. Bakıma ilişkin standart IEEE 1219-1998 baz alınarak gerçekleştirilmektedir. IEEE tarafından sunulan bakım süreci şu adımları içermektedir:

  1. Sorun tanımlama süreci
  2. Çözümleme süreci
  3. Tasarım süreci
  4. Gerçekleştirim süreci
  5. Sistem test süreci
  6. Kabul test süreci
  7. Kurulum süreci

Bu adımlar aslında yazılım geliştirme yaşam döngüsünün çekirdek adımlarının tekrarlanması şeklindedir. Ancak tekrarlanan kısım sadece değişiklik isteklerinin mevcut koda aktarılması amacıyla yapılmaktadır.

Adsız

Süreç adımları IEEE 1219-1998 tarafından girdi, çıktı ve kontrol şeklinde belirlenmiştir.

1- Sorun Tanımlama Süreci

Adsız

Girdi: Sürecinin temel girdisi, “bakım isteği” şeklindedir. Örneğin;

  • Sistemde beklenen ve yeni düzenlemelere ilişkin değişiklikler.
  • Yeni fonksiyonel talepler.

İşlem/Süreç: Bakım isteği oluşturulduğunda yapılması gereken işlemlerdir.

  1. Değişiklik isteğine bir tanım numarası atamak.
  2. Değişiklik türünü belirlemek.
  3. Değişiklik isteğinin kabul edilmesi ya da ayrıntılı incelenmesine karar verilmesi.
  4. Değişiklik isteği ile ilgili zaman/boyut/işgücü kestirimi yapılması.
  5. Değişiklik isteğinin önceliklendirilmesi.
  6. Değişiklik isteğinin diğerleri ile birlikte zaman ve iş planına kaydedilmesi.

Bu adımların uygulanmasına değişiklik talebinde bulunan müşteri, kullanıcı temsilcileri, yazılım mühendisleri ve iş uzmanları ile birlikte çalışılarak karar verilir.

Denetim: Sorun tanımlama aşamasında ise değişiklik talebinin daha önceden yapılıp yapılmadığı denetlenir ve tek olduğu belirlenir. Mükerrer iş yapmaktan kaçınmak adına daha önceki değişiklik talepleri taranır.

Çıktı: Doğrulanmış, geçerlenmiş ve karar verilmiş “bakım İsteğidir”. Bakım isteğinin ayrıntıları bir veritabanında saklanır ve isteğe ait bilgiler şu şekilde olmalıdır:

  1. Sorun ya da yeni gereksinimin tanımı,
  2. Sorun ya da gereksinimin değerlendirmesi,
  3. Başlangıç önceliği,
  4. Geçerleme verisi (Düzeltici bakım için gereklidir),
  5. Başlangıç kaynak gereksinimi,
  6. Mevcut ve gelecekte kullanıcılar üzerindeki etkileri,
  7. Yararlı ve aksak yönleri

Ölçüt: Sorun tanımlama sırasında kullanılabilecek ölçütler

  • Bakım taleplerinde kabul edilmeyen madde sayısı,
  • Gelen bakım istekleri sayısı,
  • Sorunun aşılması için harcanan kaynak ve zaman biçimindedir.

Bu adımların tamamlanmasıyla birlikte çözüm süreci başlatılabilir.

2- Çözümleme Süreci

Çözümleme sürecinde, veri tabanında saklanmış ve geçerlenmiş bakım isteği girdi olarak alınır, projeye ilişkin bilgi ve belgeleri kullanarak söz konusu isteğin yerine getirilmesi için gerekli genel plan yapılır.

Girdi: Çözümleme sürecinin girdileri:

  1. Geçerlenmiş bakım isteği,
  2. Başlangıç kaynak gereksinimleri ve diğer veriler ve
  3. Mevcut proje yada sistem bilgi ve belgeleri biçimindedir.

İşlem/Süreç: Çözümleme süreci temel olarak iki aşamadan oluşur. Bunlar olurluk aşaması ve ayrıntılı çözümleme aşamasıdır.

Olurluk çalışmasında, yapılan değişikliğin etkileri, güvenlik ve emniyet zorunlulukları, insan faktörleri, kısa ve uzun vadeli maliyetler ve yapılacak olan değişikliğin yararları değerlendirilir.

Ayrıntılı çözüm aşamasında, değişiklik isteği için ayrıntılı gereksenim tanımlaması yapılır. Bu çalışmada etkilenen yazılım öğeleri (yazılım tanımları, yazılım gereksinimleri, tasarım, kod, vb) belirlenir. Yazılım bileşenlerinin değişmesi gereken kısımları belirlenir. Bu aşamada en az üç düzeyli test stratejisi (birim testleri, bütünleştirme testleri ve kabul kabul testleri) oluşturulur. Bu aşamada kullanıcıya en az etki yapacak şekilde değişiklik gereksinimlerinin nasıl karşılanacağı bilgilerini içeren “Başlangıç gerçekleştirim planı” da hazırlanır.

Denetim: Çözümleme çalışmasının denetiminde gerçekleştirilen işlemler şu şekildedir.

  1. Gerekli proje yada sistem bilgi/belgelerine erişimin sağlanması.
  2. Önerilen değişikliklerin  ve çözümleme çalışmasının teknik ve ekonomik olurluğunun gözden geçirilmesi,
  3. Güvenlik ve emniyet konularının tanımlanması,
  4. Önerilen değişikliğin, mevcut yazılımla bütünleştirilmesinin dikkate alınması,
  5. Proje belgelerinin düzgün olarak günlendiğinin denetimi,
  6. Çözümleme belgelerinin düzgün olarak hazırlanmasının sağlanması,
  7. Sınama stratejilerinin uygun olarak belirlenmesi.

Çıktı: Çözümleme çalışmasının çıktıları:

  • Değişiklik isteklerine ilişkin olurluk çalışması,
  • Ayrıntılı çözümleme raporu,
  • İzlenebilirlik listesini içeren günlenmiş gereksinim tanımları,
  • Başlangıç değişiklik listesi,
  • Sınama stratejisi,
  • Gerçekleştirim planı şeklindedir.

Ölçüt: Çözümleme çalışmasında kullanılabilecek ölçütler:

  1. Gereksinimlerdeki değişiklik sayısı,
  2. Belgeleme hata oranı,
  3. Her işlev alanı için gerekecek işgücü,
  4. Toplam zaman biçimindedir.

3- Tasarım Süreci

Tasarım aşamasında, değişiklikten etkilenebilecek tüm proje bilgi ve belgeleri üzerinde çalışma yapılıp söz konusu bilgi ve belgeler değişiklikle ilgili olarak güncellenir.

Girdi: Tasarım çalışmasının girdileri:

  1. Çözümleme çalışması çıktıları,
  2. Ayrıntılı çözümleme,
  3. Güncellenmiş gereksinim tanımları,
  4. Başlangıç değişiklik listesi,
  5. Sınama stratejisi,
  6. Gerçekleştirim planı,
  7. Sistem ve proje belgeleri ve
  8. Var olan kaynak kodları ve veritabanları biçimindedir.

İşlem/Süreç: Tasarım için gerekli temel işlemler aşağıda belirtilmektedir.

  1. Etkilenen yazılım modüllerinin tanımlanması,
  2. Yazılım modül belgelerinin değiştirilmesi,
  3. Yeni tasarım için, güvenlik ve emniyet konularını da içeren test senaryolarının hazırlanması,
  4. İlişki testleri tanımlanması,
  5. Kullanıcı belgelerinin güncelleme gereksinimlerinin tanımlanması,
  6. Değişiklik listesinin güncellenmesi şeklindedir.

Denetim: Tasarımın belirlenen standartlara uygunluğunun denetlenmesi gerekmektedir.

Çıktı: Bakım tasarımı çalışmasının çıktıları:

  1. Gözden geçirilmiş değişiklik listesi,
  2. Güncellenmiş tasarım
  3. Güncellenmiş test planları,
  4. Güncellenmiş ayrıntılı çözümleme,
  5. Güncellenmiş gereksinimler,
  6. Gözden geçirilmiş gerçekleştirim planı,
  7. Risk ve kısıtlar listesi biçimindedir.

Ölçüt: Tasarım çalışması için kullanılabilecek ölçütler aşağıda verilmektedir.

  • Yazılım karmaşıklığı,
  • Tasarım değişiklikleri
  • Her işlev alanı için gerekecek işgücü,
  • Toplam zaman,
  • Sınama yönerge ve plan değişiklikleri,
  • Önceliklendirmedeki hata oranları,
  • Varolan kodda, eklenen, çıkarılan ve değiştirilen satır sayısı,
  • Uygulama sayısı.

4- Gerçekleştirim Süreci

Gerçekleştirim sürecinde, temel olarak tasarım çıktılarını ve kaynak kodları girdi olarak alınmakta ve değişiklik isteğini gerçekleştiren kod parçaları ile güncellenmiş yazılım kodları üretilmektedir.  Güncellenmiş yazılıma ilişkin test bilgi ve belgelerinin ve eğitim belgelerinin üretimi de bu süreçte yapılmaktadır.

Girdi: Gerçekleştirim sürecinin girdileri:

  1. Tasarım çalışması sonuçları,
  2. Varolan kaynak kodlar, açıklamalar, belgeler ve
  3. Proje ve sistem belgeleri biçimindedir.

İşlem/Süreç: Gerçekleştirim sürecinin dört ana işlemi vardır:

  1. Kodlama ve birim testleri
  2. Bütünleştirme
  3. Risk çözümleme
  4. Sınama hazırlığı gözden geçirme

Kodlama işleminde, değişiklik isteğini karşılayan yazılım kodları, varolan yazılıma eklenmektedir. İşlem sonucunda elde edilen yeni, değişmiş modüllere birim testleri uygulanmaktadır.  Birim test işlemini, bütünleştirme testleri izlemekte, tüm sistem yeniden test edilmektedir.Uygulamadaki riskleri gidermek amacıyla, gerçekleştirim aşamasında sürekli risk çözümleme yapılmaktadır.

Denetim: Gerçekleştirim sürecinde oluşturulacak denetim yapısı, aşağıdaki özellikleri sağlamalıdır:

  • Belirlenen standartlara uygun olarak kod ve yazılım gözden geçirmeleri yapılması,
  • Birim ve bütünleştirme testleri ile ilgili bilgilerin derlenmesi ve kaydedilmesinin sağlanması,
  • Test belgelerinin güncellenmesi ve oluşturulmasının sağlanması,
  • Test hazırlıklarının gözden geçirilmesi sırasında risk çözümlemenin yapılması,
  • Yeni yazılımın, yazılım ortam yönetimi altında kaydedilmesi ve denetlenmesinin sağlanması,
  • Teknik ve eğitim belgelerinin güncellenmesi,

Çıktı: Gerçekleştirim süreci aşağıdaki çıktıları vermelidir:

  1. Güncellenmiş Yazılım,
  2. Güncellenmiş tasarım bilgi/belgeleri,
  3. Güncellenmiş sınama belgeleri,
  4. Güncellenmiş kullanıcı belgeleri,
  5. Güncellenmiş eğitim kılavuzları,
  6. Riskler ve kullanıcılara etkileri,
  7. Sınama hazırlığı gözden geçirme raporu

Ölçüt: Gerçekleştirim çalışmasında kullanılabilecek ölçütler kodlama ile ilgili olması gerekmektedir. Bu nedenle teknik ölçütler kullanılmaktadır:

  1. Değişiklik oranı
  2. Hata oranı

5- Sistem Test Süreci

Değişikliklerin mevcut yazılıma yansıtılmasından sonra elde edilen yeni yazılım sürümünün belirlenen standartlara uygun olarak tümüyle bütünleşik sistem üzerinde testlerin yapılması gerekmektedir.  Sistem testlerinin, kullanıcı ve üretici ekiplerin tanıklığında bağımsız bir yapı tarafından gerçekleştirilmeleri önerilmektedir.

Girdi: Sistem test sürecinin girdileri:

  1. Test hazırlık raporu
  2. Belgeler
  3. Sistem test planları,
  4. Sistem testleri,
  5. Sistem test yönergeleri,
  6. Kullanıcı kılavuzları,
  7. Tasarım
  8. Güncellenmiş sistem biçimindedir.

İşlem/Süreç: Sistem testleri, tümüyle bütünleşik bir sistem üzerinde yapılmalıdır. Bu aşamada, işlevsel sistem testi, arayüz testi, regresyon testi ve test hazırlık raporunun gözden geçirilmesi işlemleri yapılır.

Denetim: Sistem testleri, üretici ve kullanıcılardan bağımsız bir grup tarafından gerçekleştirilmelidir. Yazılım kodları ve her türlü bilgi belge, yazılım ortam yönetimi tarafından saklanır.

Çıktı: Bu aşamanın temel çıktıları:

  1. Tümüyle test edilmiş bütünleşik bir sistem,
  2. Test raporu,
  3. Gözden geçirilmiş test hazırlık raporu şeklindedir.

Ölçüt: Bu aşamada kullanılabilecek ölçütler, üretilen ve düzeltilen hata oranlarıdır.

6- Kabul Test Süreci

Kabul test süreci, kullanıcılar ya da kullanıcı temsilcileri tarafından gerçekleştirilen bir süreçtir.  Kullanıcıların, değişiklikleri içeren yeni yazılımı test etmeleri ve kabul etmeleri beklenmektedir.

Girdi: Kabul test sürecinin girdileri:

  1. Gözden geçirilmiş test hazırlık raporu,
  2. Tümüyle bütünleşik sistem,
  3. Kabul test planları,
  4. Kabul testleri ve
  5. Kabul test yönergeleri biçimindedir.

İşlem/Süreç: Kabul test işlemleri:

  1. İşlevsel kabul testlerinin yapılması,
  2. Birlikte çalışabilirlik testleri,
  3. Regresyon testleri biçimindedir.

Denetim: Kabul testleri sırasında denetimi aşağıdaki işlemleri içermektedir.

  1. Kabul testlerinin uygulanması,
  2. Sınama sonuçlarının raporlanması,
  3. İşlevsel denetim yapılması,
  4. Yeni sistemin oluşturulması,
  5. Kabul test belgelernin yazılım konfigürasyonuna yerleştirilmesi.

Çıktı: Kabul testlerinin çıktıları, yeni sistem, işlevsel konfigürasyon denetim raporu ve kabul  sınaması raporudur.

Ölçüt: Bu aşamada kullanılabilecek ölçütler: üretilen ve düzeltilen hata oranlarıdır.

6- Kurulum Süreci

Kurulum süreci, geliştirilen ya da  değiştirilmiş yeni yazılım sürümünün, uygulama sahasına aktarılma işlemlerini içerir.

Girdi: Bu sürecin temel girdisi, tümüyle sınanmış ve kabul edilmiş yeni yazılım sürümüdür.
İşlem/Süreç: Bu sürecin işlemleri:

  • Fiziksel ortam denetiminin yapılması,
  • Kullanıcıların bilgilendirilmesi,
  • Mevcut sistemin yedeklerinin alınması,
  • Kullanıcı tarafında kurulum ve eğitimlerin yapılması şeklindedir.

Denetim: Denetim işlemleri:

  1. Fiziksel ortam denetiminin yapılması,
  2. Sistem ile ilgili bilgi ve belgelerin kullanıcıya ulaştırılması,
  3. Sürüm Tanımlama raporunun tamamlanması,
  4. Yazılım konfigürasyon ortamına aktarımın sağlanması şeklindedir.

Çıktı: Bu sürecin temel çıktıları, fiziksel ortam denetim raporu ve Sürüm tanımlama raporudur.

Ölçüt: Bu süreçte kullanılabilecek ölçüt, belgeleme değişiklikleridir.

Tüm süreçlerin tamamlanmasıyla yazılım bakım döngüsü tamamlanmış ve müşteri istekleri eksiksiz yerine getirilmiş olmaktadır. Tekrar belirtmekte fayda var ki bu standartlar dizisi IEEE tarafından belirlenmiştir.

Kullanıcı Dostu Yazılım Nasıl Anlaşılır?

13 Haz

Yazılımda kullanıcı dostu (user friendly) kavramı arayüzle ilgili bir kavramdır. İçgüdüsel olarak, yazılımımız kullanıcının hoşuna giden rahat bir kullanıma sahipse kullanıcı dostudur denir. Ancak bu durumun ispatlanabilir ve bilimsel olarak ifade edilebilir olması gerekmektedir. Aksi halde yazılımınızın kullanıcı dostu olup olmadığı havada duran bir ifade olarak kalır.

Bir yazılımın kullanıcı dostu olup olmadığı, arayüz değerlendirmesi kabul testleri ile meydana çıkan bir kavramdır. Yazılımın analiz aşamasında, yazılım performansının değerlendirilebilmesi amacıyla objektif ve ölçülebilir hedeflerin belirlenmesi gereklidir. Değerlendirme yapılırken niyeti açık bir şekilde ortaya koyan kabul kriterleri oluşturulur ve bunlar genellikle aşağıdaki maddeleri içerir:

  • Öğrenme süresi
  • Hata oranı
  • Görevin tamamlanma hızı
  • Akılda kalıcılık

1- Öğrenme Süresi
Bir kullanıcının, sistemi öğrenme süresi yazılımın kullanılabilirliği açısından önemli bir ölçümdür. Karmaşık bir arayüze sahip yazılımın öğrenme süresi ve dolayısıyla müşteriye olan maliyeti yüksektir. Bu istenmeyen bir durumdur.

2- Hata oranı
Sistemin kullanımı sırasında meydana gelen toplam hata veya belli bir süre içerisinde oluşan hata sayısıdır. Çok fazla hata uyarısı vermek veya istenmeyen hataların(exception) oluşması , kullanıcı üzerinde hoş bir izlenim bırakmaz.

3- Görevin Tamamlanma Hızı
Görevin tamamlanma hızı yazılımın bir işi bitirme hızı yani yazılımın performans göstergesi değildir. Kullanıcının arayüzü kullanabilemsi ile ilgili gözlenen hızdır. Örneğin bir yeni bir kaydın eklenebilmesi kullanıcının ne kadar zamanını aldığını gösteren hızdır.

4- Akılda Kalıcılık
Zaman içinde arayüzün akılda kalıcılığı ile ilgilidir. Arayüzün kısa bir süre içinde unutulmaması gerekir.

Örnek bir kabul testi nasıl olmalıdır?

  • Bir saatlik eğitim sonunda, banka görevlisi yeni bir müşteri kaydını hatasız olarak yapabilmelidir.
  • Beş saatlik eğitim sonunda, banka görevlisi müşteriler arasında para transferini hatasız bir şekilde gerçekleştirebilmelidir.

Sistemin tasarımı ve kodlanması tamamlandıktan sonra, analiz aşamasında belirlenmiş olan hedeflere bakılarak kullanıcı kabul testleri gerçekleştirilir. Arayüzün testi sırasında, ölçülebilir kriterlerin incelenmesi büyük önem taşır. Böylece bilimsel temeli olmayan “kullanıcı dostu olup olmama” tartışmalarından kaçınılmış olur. Yani kullanıcı dostu (user friendly) diye tabir edilen ama tarif edilemeyen kriterin anlaşılabilir bir şekilde ortaya koyulmuş ve bu kriteri ölçebilen bir ölçek oluşturulmuş olur. Kabul testinin amacı, gereksinim dökümanlarında belirtilmiş olan şartların yerine getirilip getirilmediğini kontrol etmektir. Sistem bu testleri geçtikten sonra, seri üretime geçilir ve aktif olarak kullanımı sırasında da incelenmesi devam edecektir.

Yazılım Sistemlerinde Soyutlamalar

13 Kas

Bir arabaya bindiğimizde aracı hareket ettirebilmek için gerekli bilgilere sahipsek aracı çalıştırıp yolumuza gidebiliriz. Aracı hareket ettirebilmemiz için bize öğretilen kurallar dizisi, aracın hareketini sağlayan mekanik aksamlardan arındırılmıştır. Yani şoför koltuğuna oturduğumuzda motordan tekerlere iletilen gücün, motora giden yakıtın veya aküde ki elektrik dağılımının yönetimi ile ilgilenmeyiz. Bu süreçler mühendisler tarafından tasarlanmış ve sürücüden soyutlanmıştır. Sürücüye sadece sisteme gerekli komutları vermek kalmıştır.

Arabaların donanımsal özelliklerinde yapılan değişiklikler sürücüleri etkilemez . Örneğin benzinli bir araç LPG yakıta dönüştürüldüğünde sürücüler, yeniden araç kullanma eğitimi almak zorunda kalmazlar.

Soyutlama işlemi, karmaşık sistemlerin uygulama alanındaki detaylarını kullanıcılardan gizlemek için uygulanır. Ayrıca karmaşık sistemlerin basitleştirilmesi ve kolayca anlaşılması için benimsenmiş ilkelerden biridir.

Yazılım sistemlerinde soyutlamalar mimari düzeyde yapılabildiği gibi kod düzeyinde de yapılabilmektedir.

Bir yazılım sisteminde mimari düzeyde yapılan soyutlamalar, yazılımı mimari katmanlar şeklinde sorumluluklara ayırarak yapılır. Böylece bir katman diğeri ile birlikte çalışır, fakat biri diğerinin çalışma alanını etkilemez. Hem de Separation of Concerns diye adlandırılan tasarım prensibine de uyulmuş olur. (Concern kelimesini burada “katmanlar” veya “işlevler” olarak değerlendirebiliriz).

Mimari Soyutlamalar
Mimari Seviyede Soyutlama

 

Yukarıdaki resimden de anlaşılacağı üzere, bir kullanıcı sadece Presentation Layer ile etkileşir. Bütün isteklerini bu katman üzeriden talep eder. Diğer katmanlardan haberdar değildir. Bu katmanların her birini farklı takımların geliştirdiğini varsayacak olursak, geliştiricilerin de sadece sorumlu olduğu katman içerisinde sorumlu olduğunu söyleyebiliriz. Bu şekilde izolasyon sağlanmış olur. Yazılım sistemlerinde kod seviyesinde yapılan soyutlamalar, nesneye yönelik programlama teknikleri ve tasarım desenlerinin doğru bir şekilde uygulanarak kod birimlerinin sınıflar şeklinde sorumluluklara ayrılması ile gerçekleştirilir. Örneğin üst seviye sınıfların alt seviye sınıflara bağımlı olması kodun gelişime kapalı olmasına yol açar.

 

Somut Nesne Kullanımı
Somut Nesne Kullanımı

 

Bunun yerine üst seviye sınıfları alt seviye sınıflara soyut nesnelerle bağlarız. Bu sayede üst seviye sınıflar alt seviye sınıfları tanımazlar. Interface, Abstract Class gibi soyut nesneleri tanırlar.

Soyut Nesne Kullanımı
Soyut Nesne Kullanımı

 

Bu örnek, kod seviyesinde yapılan soyutlamalara verilebilecek örneklerden sadece biridir. Kod seviyesinde yapılan soyutlamalarla nesneler arasındaki ilişkilerin ve bağımlılıkların düzenlenmesi de sağlanmış olur. Programcı, iş birimlerini somut sınıflara kodlarken, somut sınıfları soyut tipler aracılığı ile kullandırırlar. Bu sayede kullanıcılar, işleyiş detaylarını bilmeden ihtiyaçlarını karşılayabilirler.

Soyutlama kavramı, yazılım geliştirme sırasında oluşan bazı Anti-Pattern durumlarını da bertaraf eder. Aceleci ve plansız yaklaşımlar ile her şeyin birbirine girdiği projeler Anti-Pattern durumları doğurur. Yazılımda Anti-Pattern durumları, bir gömleğin ilk düğmesinin yanlış iliklenip diğerlerinin de yanlış iliklenmesine benzetirim. Yani başlangıçta düzensiz ve plansız başlanan işlerin zamanla, birikmiş hatalar yığınına dönüşeceği açıktır.

Anti-Pattern durumlardan arınmış projeler dileğiyle, tekrar görüşmek üzere.