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.