KALİTE YÖNETİMİ

Birçok kuruluşun amacı, ürün veya servislerinde yüksek bir kalite seviyesine ulaşmaktır. Kalitesiz ürünleri dağıtmak ve müşteriye dağıtımı yapıldıktan sonra problem ve hataları tamir etmek kabul edilebilir bir durum değildir. Bu anlamda, yazılım da arabalar, televizyonlar veya bilgisayarlar gibi ürünlerden farklı değildir.

Buna rağmen, yazılım kalitesi basit bir yolla tanımlanması mümkün olmayan karmaşık bir kavramdır. Klasik olarak, kalite kavramı, üretilen ürünün belirtimlerini karşılaması gerektiğini ortaya koyar (Crosby, 1979). Gerçek dünyada bu tanım diğer bütün ürünlere uygulanabilir, fakat yazılım sistemleri için bazı sorunlar vardır:

1.       Belirtim, müşterinin istediği ürün özelliklerini karşılayacak şekilde ayarlanmalıdır. Ayrıca, geliştirme kuruluşunun da belirtimde bulunmayan bazı gereksinimleri ( bakım gereksinimleri gibi) olabilir.

2.       Bazı kesin kalite özelliklerinin şüphesiz bir yolla nasıl tanımlanacağı da bilinmemektedir.

3.       Gereksinim mühendisliğini kapsayan 1. Bölüm’de tartıştığım gibi, tamamlanmış yazılım belirtimleri yazmak çok zordur. Bunun için, ürün belirtime uysa bile, kullanıcılar ürünü yüksek kaliteye sahip bir ürün olarak nitelendirmeyebilirler.

Belirtimleri geliştirmek için çalışmalar yapılmaktadır; ancak şu an için bunların mükemmel olamayacağını kabul etmek zorundayız. Mevcut belirtimlerdeki problemleri fark etmeli ve mükemmel olmayan belirtimlerden dolayı oluşan kısıtlamaları karşılayacak yordamlar ortaya koyarak kaliteyi artırmalıyız. Bakım yapılabilirlik, taşınabilirlik veya verimlilik gibi yazılım özellikleri açık olarak tanımlanmamış fakat sistemin ulaşacağı kaliteyi etkileyecek önemli kalite özellikleri olabilir.

Bir kuruluştaki kalite yöneticilerinin sorumluluğu, ürün kalitesinin istenilen seviyeye ulaşmasının garanti edilmesidir. Prensip olarak kalite yönetimi, yazılım geliştirme sürecinde kullanılacak standart ve yordamlarım tanımlanması ve bütün mühendislerin bunları takip etmelerinin kontrol edilmesidir. Buna rağmen, pratikte kalite yönetiminin bundan daha fazla işi vardır.

İyi kalite yöneticileri, ürün geliştirmeden sorumlu herkesin yüksek bir ürün kalitesi seviyesine ulaşmada ortak bir görüşü sahip olacağı bir “kalite kültürü” geliştirmeyi amaçlarlar. Takımları, kendi işlerindeki kalitenin sorumluluğunu üzerlerine almaya ve kalite gelişimi için yeni yaklaşımlar geliştirmeye cesaretlendirirler. Standart ve yordamlar, kalite yönetiminin temelini oluşturmasına rağmen; yazılım kalitesini etkileyen ancak standartlarda bulunamayacak elle tutulamayan kavramların (güzellik, okunabilirlik, vb.) varlığı da deneyimli kalite yöneticileri tarafından fark edilmiştir. Elle tutulamayan bu kavramlarla ilgilenenleri desteklemekte ve bütün takım elemanlarında profesyonel davranışı özendirmektedirler.

Yazılım kalite yönetimi üç temel davranış ile yapılandırılabilir:

1.       Kalite Güvence: Yüksek kaliteye sahip yazılıma götürecek kurumsal yordam ve standartlar çatısının ortaya konması.

2.       Kalite Planlama: Bu çatıdan uygun standart ve yordamların seçimi ve bunların özel bir yazılım projesine uyarlanması.

3.       Kalite Kontrol: Proje kalite standart ve yordamlarının yazılım geliştirme takımı tarafından takip edildiğini garanti eden süreçlerin tanımlanması ve belgelenmesi.

Kalite yönetimi, yazılım geliştirme süreci üzerinde bağımsız bir kontrol sağlar. Yazılım sürecinin çıktıları kalite yönetim sürecinin girdileridir ve kurumsal standart ve hedeflerle tutarlı olmalarının sağlanması amacıyla kontrol edilirler . Kalite güvence ve kontrol takımı bağımsız olursa süreç üzerinde daha tarafsız bir inceleme yapabilir ve kurum yönetimine problem ve zorlukları raporlayabilir.

Kalite yönetimi ve yazılım geliştirme

Kalite yönetimi, proje yönetiminden ayrılmalıdır. Bu şekilde kalite, proje bütçesi ve çizelgesi üzerindeki yönetim sorumluluklarından etkilenmez. Kalite yönetiminden bağımsız bir takım sorumlu olmalı ve proje yöneticisi seviyesinden daha yukarıda bir yönetime rapor sunmalıdır. Kalite yönetimi takımı, herhangi bir geliştirme grubuyla bağlantılı olmamalı, fakat kurum genelinde kalite yönetiminden sorumlu olmalıdır.

Bütün endüstrilerdeki kalite yönetim sistemlerinin geliştirilmesinde kullanılabilecek uluslararası standarda ISO 9000 adı verilmektedir. ISO 9000, üretim endüstrilerinden servis endüstrilerine kadar geniş bir kapsamda kullanılabilecek bir standartlar kümesidir. ISO 9001 bu standartların en genelidir ve ürün tasarımı, geliştirme ve bakım yapan kuruluşlardaki kalite süreçleri ile ilgilidir. Diğer bir destekleyici belge (ISO 9000-3) ise ISO 9000’i yazılım geliştirme için yorumlamaktadır. ISO 9000 standardı ile ilgili birçok kitap mevcuttur (Johnson, 1993; Oskarsson ve Glass, 1995; Peach, 1996).

ISO 9001 kalite sürecinin genel bir modelidir. Bu sürecin çeşitli yanlarını tarif eder ve bir kuruluşta hangi standart ve yordamların bulunması gerektiğini tanımlar. Endüstriye özel olmadığı için bunlar ayrıntılı tanımlanmamıştır. Belirli bir kuruluşun içinde, uygun kalite süreçleri kümesi tanımlanmalı ve kurumsal bir kalite kılavuzunda belgelenmelidir.

Uymayan ürünlerin kontrolü                                              Tasarım kontrolü

Yönetim, depolama, paketleme ve dağıtım                       Satın alma

Müşteriye teslim edilen ürünler                                         Ürün tanıma ve izlenebilirlik

Süreç kontrolü                                                                        Denetim ve sınama

Denetim ve sınama gereçleri                                                Denetim ve sınama durumu

Anlaşma gözden geçirmesi                                                  Düzeltici eylem

Belge kontrolü                                                                         Kalite kayıtları

İçsel kalite izlemeleri                                                             Eğitim

Bakım yapma                                                                            İstatistiksel teknikler

ISO 9001 tarafından kapsanan alanları göstermektedir.

Bir kuruluştaki kalite güvence yordamları, kalite sürecinin tanımlandığı kalite kılavuzunda belgelenmiştir. Bazı ülkelerde kalite kılavuzunda yer alan kalite süreçlerinin, ISO 9001 ile uyumluluğunu onaylayan kurullar vardır. Buna ek olarak müşteriler üreticinin ISO 9000 belgesine, bu kuruluşun kaliteyi ne kadar ciddiye aldığının bir göstergesi olarak bakmaktadırlar.

ISO 9000, kalite kılavuzu ve özel proje kalite planları arasındaki ilişkiler aşağıda görülmektedir.

ISO 9000 ve kalite yönetimi

Kalite Güvence ve Standartlar

Kalite güvence (KG) etkinlikleri yazılım kalitesini başarmak için çatı tanımlar. KG süreci, yazılım geliştirme süreci veya yazılım ürününe uygulanacak standartlar seçmeyi veya tanımlamayı içerir. Bu standartlar geliştirme süresince uygulanacak yordam veya süreçlerin içine gömülmüş olabilir. Süreçler, içine kalite standartları bilgisi gömülü araçlar tarafından desteklenebilir.

Kalite güvence sürecinin bir parçası olarak yerleştirilmiş iki tip standart vardır:

1.       Ürün Standartları: Bunlar geliştirilecek yazılım ürününe uygulanacak standartlardır. Üretilebilecek gereksinim belgesinin yapısı gibi belge standartları, bir nesne sınıf tanımlaması için standart yorum başlığı gibi belgeleme standartları ve bir programlama dilinin nasıl kullanılabileceği gibi kodlama standartları bunlara dahildir.

2.       Süreç Standartları: Bunlar yazılım geliştirme süresince takip edilecek süreçleri tanımlayan standartlardır. Belirtim, tasarım ve doğrulama süreçlerinin tanımları ve bu süreçler süresince oluşturulması gereken belgelerin tanımları bunlara dahildir.

Ürün ve süreç standartları arasında çok yakın bir ilişki vardır. Ürün standartları yazılım sürecinin çıktılarına uygulanır ve çoğu durumda, süreç standartları, ürün standartlarına uyulmasını garanti eden özel süreç eylemlerini içerirler.

Yazılım standartlarının önemli olma nedenine dair birçok sebep vardır:

1.       En iyi, en azından en uygun, çalışmaların koruyuculuğunu sağlarlar. Bu bilgi genelde sadece uzun deneme yanılmalar sonucunda elde edilir. Bir standart oluşturmak geçmişteki hataların tekrarlanmasını engeller. Standartlar kuruluş için değerli bir bilgelik tutarlar.

2.       Kalite güvence sürecinin gerçekleştirilebileceği bir çatı sağlarlar. Standartlar en iyi çalışmaları kapsadığından dolayı, kalite kontrol işlemi standartlara uyulup uyulmadığının kontrolü ile kolayca yapılabilir.

3.       Bir işin bir kişi tarafından başlatılıp başak birisi tarafından devam ettiği durumlarda devamlılığın sağlanmasına yardım ederler. Standartlar kuruluştaki bütün mühendislerin aynı çalışmaları benimsemesini garanti eder. Sonuçta, yeni bir işe başlarken gereken öğrenme çabası azaltılır.

Yazılım mühendisliği proje standartları geliştirmek zor ve zaman alıcı bir süreçtir. Amerika Savunma Bakanlığı (USDoD), Amerika Ulusal Standartlar Enstitüsü (ANSI), İngiltere Standartlar Enstitüsü (BSI), NATO ve IEEE gibi ulusal ve uluslar arası kurumlar standartların üretilmesinde aktif görev almaktadırlar. Bunlar genel standartlardır ve bir çok projeye uygulanabilirler. NATO ve diğer savunma kurumları yazılım anlaşmalarında kendi standartlarına uyulmasını isteyebilirler.

Yazılım mühendisliği terminolojisi, Ada ve C++ gibi programlama dilleri, grafik semboller sistemi, yazılım gereksinimleri yazma çıkarma için yordamlar, kalite güvence yordamları ve yazılım doğrulama ve geçerleme süreçlerini (IEEE, 1994) kapsayan ulusal ve uluslar arası standartlar geliştirilmiştir.

Standartlar geliştiren kalite güvence takımları kurumsal standartları ulusal ve uluslar arası standartlara dayandırırlar. Bu standartları başlangıç noktası olarak kullanırsak kalite güvence takımı bir standartlar elkitabı ortaya çıkarmalıdır. Bu kuruluşa uyan standartları tanımlamalıdır.

Tasarım gözden geçirme formu                                          Tasarım gözden geçirme idaresi

Gereksinimler belge yapısı                                   Belgelerin değişim yönetimime sunumu

Yordam başlık formatı                                                           Versiyon yayınlanma süreci

Java programlama stili                                                           Proje planı onaylama süreci

Proje plan formatı                                                  Değişim kontrol süreci

Değişim istek formu                                                              Sınama kayıtlanma süreci

Ürün ve süreç standartları

Yazılım mühendisleri, bazen standartları bürokratik ve yazılım geliştirmenin teknik etkinliğine uygunsuz olarak kabul ederler. Bu standartlar sıkıcı form doldurmalar ve iş kayıtlama gerektirdiği zaman gerçekleşir. Çoğu zaman standartların genel gerekliliğinde anlaşılmasına rağmen mühendisler standartların bazı projelerde gerekli olmamalarına iyi nedenler bulmuşlardır.

Bu problemleri önlemek için standartları koyan kalite yöneticileri yeterli miktarda kaynağa sahip olmalı ve aşağıdaki adımları izlemelidir.

1.       Ürün standartlarının geliştirilmesinde yazılım mühendisleri görev almalıdır. Bu kişiler standartların geliştirilmesinin arkasındaki nedeni anlamalı ve standartları üstlenmelidir. Standart belgesi sadece uyulacak standardı ortaya koymamalı, ayrıca standardizasyon kararlarının neden alındığını anlatan bir açıklama da kapsamalıdır.

2.       Düzenli olarak değişen teknolojileri yansıtacak standart inceleme ve değişimleri yapılmalıdır. Daha önceleri geliştirilen standartlar bir şirket standartlar elkitabında saklanmaktaydı ve bunları değiştirmekte bir isteksizlik vardı. Bir standartlar elkitabı gereklidir fakat değişen durumlar ve teknoloji ile geliştirilmelidir.

3.       Mümkün olan her yerde standartları destekleyecek yazılım araçları sağlanmalıdır. Birçok şikayetin sebebi uygulanması sırasında zahmetten dolayı büro içindeki standartlardır. Eğer araç desteği varsa, bu standartların geliştirilmesi sırasında  büyük bir ek çalışma gerekmez.

Eğer geliştirme takımına uygulanması zor bir süreç yüklenirse, süreç standartları zorluklara sebep olabilir. Böyle standartlar genellikle proje yöneticileri tarafından yorumlanması gereken kılavuzlardır. Bir proje veya proje takımı için uygun olmayan bir çalışma şeklinin emredilmesine hiç gerek yoktur. Her proje yöneticisi süreç standartlarını şartlara göre değiştirebilecek otoriteye sahip olmalıdır. Bununla birlikte, ürün kalitesiyle ilgili ve dağıtım sonrası süreçle ilgili standartlar sadece dikkatli bir gözden geçirilme sonrasında değiştirilmelidir.

Proje yöneticisi ve kalite yöneticisi, dikkatli bir kalite planlaması ile uygun olmayan standartların problemlerini engelleyebilirler. Elkitabındaki standartlardan hangilerinin değiştirilmeden kullanılacağına, hangilerinin değiştirilmesi gerektiğine ve hangilerinin görmezlikten gelineceğine karar vermelidirler. Belirli bir proje gereksinimine tepki olarak yeni standartlar geliştirilmek zorunda kalınabilir. Örneğin, daha önceki projelerde kullanılmayan resmi belirtimler için standartlar gerekebilir. Bu yeni standartların proje sırasında geliştirilmesine izin verilmelidir.

Belgeleme Standartları

Bir yazılım projesindeki belgeleme standartları özellikle önemlidir, çünkü bunlar bir yazılım ve yazılım sürecinin tanımlanmasının elle tutulabilen tek yoludur. Standardize edilen belgeler karalı bir görünüm, yapı ve kaliteye sahiptir ve bu yüzden okunması ve anlaması kolaydır.

Belgeleme standartlarının üç tipi vardır:

1.       Belgeleme süreç standartları: Bu standartlar belge üretiminde takip edilecek süreci tanımlamaktadır.

2.       Belge standartları: Bunlar, belgelerin sunumu ve yapısını yöneten standartlardır.

3.       Belge değiş tokuş standartları: Bu standartlar belgelerin bütün elektronik kopyalarının birbirine uyumlu olmasını garanti eden standartlardır.

Süreç standartları belge üretirken kullanılan süreci tanımlar. Bu belge geliştirme de kullanılan yordamları ve belge üretmede kullanılan yazılım araçlarını tanımlamak anlamına gelir. Yüksek kaliteli belgeler üretilmesini garanti edecek kontrol ve ilave yordamları da tanımlanmalıdır.

Belge süreç kalite standartları esnek olmalı ve bütün belge tipleri ile başa çıkabilmelidir. Çalışma kağıtları ve küçük notlar için açık bir kalite kontrole gerek yoktur.  Bununla birlikte, bu belgelerin geliştirmede kullanılacak resmi belgeler olması durumunda veya müşterilere dağıtılacaksa resmi bir kalite süreci benimsenmelidir.

Kalite kontrolleri dahil olan bir belge üretim süreci

Taslaklama, kontrol, yeniden gözden geçirme ve yeniden taslaklama iteratif bir süreçtir. Kabul edilebilir kalitede bir belge üretilene kadar bu işlem devam eder. Kabul edilebilir kalite belgenin tipine ve belgenin potansiyel okuyucularına bağlıdır.

Belge standartları, yazılım geliştirme yolunda üretilen bütün belgelere uygulanmalıdır. Belgelerin tutarlı bir biçim ve görünüşü olmalıdır ve aynı tipteki belgeler tutarlı bir yapıya sahip olmalıdır. Özel projelerin gereksinimleri doğrultusunda belge standartları uyarlanabilmesine rağmen bir kuruluş içinde üretilen belgelerde aynı biçimin kullanılması iyi bir davranıştır.

Geliştirilebilecek belge standartlarının bazı örnekleri:

1.       Belge kimlik standartları: Büyük sistem projeleri binlerce belge oluşturabileceğinden dolayı her belge ayrı ayrı tanınmalıdır. Resmi belgeler için bu tanımlayıcı, konfigürasyon yöneticisi tarafından tanımlanan resmi tanımlayıcı olmalıdır. Resmi olmayan belgeler içinse, belge tanımlayıcının biçimi proje yöneticisi tarafından tanımlanabilir.

2.       Belge yapı standartları: Bir yazılım projesi süresince oluşturulacak her belge sınıfı  standart bir yapıya sahip olmalıdır. Yapı standartları, eklenecek bölümleri tanımlamalı ve sayfa numaralama, sayfa başlık ve altbilgisi, bölüm ve altbölüm numaralama ile ilgili kuralları belirlemelidir.

3.       Belge sunum standartları: Belge sunum standartları belgeler için bir içsel biçim tanımlamalı ve belge tutarlılığına katkıda bulunmalıdır.  Belgedeki yazı tipleri ve biçimlerin tanımını, logoların ve şirket adlarının kullanımını, belge yapısını işaret etmek için kullanılan renkleri içerirler.

4.       Belge güncelleme standartları:Eğer bir belge sistemdeki değişiklikleri göstermek için değiştirilirse, belge değişimlerini göstermenin tutarlı bir yolu bulunmalıdır. Yeni belge versiyonunu belirtmek için değişik kapak renkleri kullanılabilir ve değiştirilmiş yada eklenmiş paragrafları göstermek için sayfa kenarında çubuklar kullanılabilir.

Belgelerin elektronik kopyalarının değiş tokuşu sırasında belge değiş tokuş standartları önemlidir. Değiş tokuş standartlarının yararı belgelerin elektronik olarak transferinin ve orijinal biçimlerinde tekrar yaratılmasının sağlanmasıdır.

Eğer hangi araçların standart olarak kullanılması gerektiği süreç standardında belirtildiğini varsayarsak değiş tokuş standartları bu araçları kullanmada ki kuralları tanımlar. Değiş tokuş standartları yazı tipi ve yazı biçimlerini de yazıcı ve ekran yeterliliklerinin değişmesinden dolayı sınırlandırabilir.

Süreç ve Ürün Kalitesi

Kalite yönetimi ile ilgili altta yatan varsayımlardan biri de geliştirme sürecinin kalitesinin ürünün kalitesini doğrudan etkilediğidir. Bu varsayım, ürün kalitesinin kesin olarak üretim sürecine bağlı olduğu üretim sistemlerinden çıkarılmıştır. Aslında daha önceden kabul edilebilir bir süreç kalite seviyesini sağlandığı otomatik kütle üretim sistemlerinde ürün kalitesi doğal olarak gelir.

Süreç tabanlı kalite

Süreç kalitesi yazılım geliştirmede çok önemlidir. Bunu nedeni bakım yapılabilirlik gibi yazılım özelliklerini yazılımı uzun süre kullanmadan ölçmenin zor olmasıdır. Kalite iyileştirme, kaliteli ürünleri ayırt etme, bu ürünleri geliştirmekte kullanılan süreçleri inceleme ve daha sonra bu süreçleri geniş bir proje yelpazesine uygulanabilecek şekilde genelleştirmeye odaklanır. Bununla birlikte, yazılım süreci ve yazılım ürün kalitesi arasındaki ilişki karmaşıktır. Süreci değiştirmek her zaman ürün kalitesinde bir ilerlemeye yol açmayabilir.

Üretim alanında süreç ve ürün kalitesi arasında açık bir bağlantı vardır, çünkü süreç göreceli olarak daha kolay izlenebilir ve standardize edilebilir. Üretim sistemleri bir kere ayarlandıktan sadece tekrar tekrar yüksek kaliteli ürünler üretmek için kullanılırlar. Yazılım üretilmez, tasarlanır. Yazılım geliştirme mekaniksel sürece göre daha yaratıcı olduğundan dolayı bireysel yetenek ve deneyim önemlidir. Yeni bir uygulanma veya daha erken bir ürün çıkarma ile ilgili piyasa baskısı gibi dış faktörler ürün kalitesini kullanılan sürece bakılmaksızın etkiler.

Bununla birlikte, süreç kalitesinin yazılımın kalitesi üzerinde kesin bir etkisi vardır. Süreç kalite yönetimi şunları gerektirir:

1.       İncelemelerin ne zaman ve nasıl yapılacağının belirtildiği süreç standartları tanımlamak.

2.       Standartlara uyulduğunun garanti edilmesi için geliştirme sürecini izlemek.

3.       Yazılım sürecini proje yönetimine ve yazılımın alıcısına rapor etmek.

Süreç tabanlı kalite güvencedeki bir tehlike de önceden tanımlanan sürecin geliştirilecek yazılımla uygun olmamasıdır. Örneğin, süreç kalite standartları bir belirtimin uygulama başlamadan önce tamamlanmış ve onaylanmış olması gerektiğini söyleyebilir. Bununla birlikte, bazı sistemler program uygulanmasını gerektiren prototip oluşturmayı gerektirebilir. Kalite takımı prototip oluşturmanın kalitenin izlenemeyeceğinden dolayı yapılmaması gerektiğini önerebilir. Böyle durumlarda üst yönetim, kalite sürecinin ürün geliştirmeyi engellemekten çok desteklemesini sağlamak amacıyla işe karışmalıdır.

Kalite Planlama

Kalite planlama yazılım sürecinin erken bir evresinde başlamalıdır. Kalite planı istenen ürün kalitelerini ortaya koyar. Bunlara nasıl değer biçileceğini de tanımlamalıdır. Bu yüzden yüksek kaliteli yazılımın gerçekte ne anlama geldiğini tanımlar. Böyle bir tanım olmazsa, farklı mühendisler zıt yönlerde çalışabilirler böylece farklı ürün özellikleri eniyilenir. Kalite planlama sürecinin sonucu bir proje kalite planıdır.

Kalite planı, yapılacak projeye ve geliştirme sürecine uygun kurumsal standartları seçmelidir. Eğer projede yeni yöntem ve araçlar kullanılıyorsa yeni standartlar tanımlanmak zorunda kalınabilir. Humprey (1989) yazılım mühendisliği üzerine yazdığı klasik kitabında kalite planı için şu taslak yapısını önermiştir:

1.       Ürün başlangıcı Ürünün, sunulacak pazarın ve ürün için kalite beklentilerinin tanımı

2.       Ürün planları Önemli sürüm tarihleri ve ürün sorumlulukları yanında dağıtım ve ürün bakım planları

3.       Süreç tanımlamaları Ürün geliştirme ve yönetimi için kullanılacak geliştirme ve bakım süreçleri

4.       Kalite hedefleri Önemli ürün kalite özelliklerinin de tanımlandığı ürün kalite hedef ve planları

5.       Riskler ve risk yönetimi Ürün kalitesini etkileyebilecek anahtar riskler ve bu riskleri karşılayan eylemler.

Kalite planları yazılırken bunların olabildiğince kısa olmasına dikkat edilmelidir. Belge çok uzun olursa mühendisler bunu okumazlar ve bu da bir kalite planı oluşturmanın amacını zedeler.

Kalite planlama sürecinde göz önünde bulundurulması gereken birçok olası yazılım kalite özellikleri mevcuttur Genelde bütün bu özelliklerin aynı anda eniyilenmesi mümkün değildir. Önemli kalite özelliklerini seçmek ve bunların nasıl yapılacağının planlanması, kalite planlamanın önemli kısımlarından biridir.

Yazılım kalite özellikleri

Emniyet                                    Anlaşılabilirlik                      Taşınabilirlik

Güvenlik                                   Sınanabilirlik                        Kullanılabilirlik

Güvenilirlik                              Uyarlanabilirlik                    Yeniden kullanılabilirlik

Esneklik                                    Modülerlik                              Verimlilik

Sağlamlık                                  Karmaşıklık                           Öğrenebilirlik

Kalite planı geliştirilecek ürün için en önemli olan kalite özelliklerini tanımlar. Verimlilik en üstte kabul edilebilir ve diğer etmenlerden bunu sağlamak için fedakarlık edilebilir. Eğer bu planda yer alırsa  geliştirmede çalışan mühendisler bunu sağlamak için işbirliği yapabilirler. Plan ayrıca kalite değerlendirme sürecini de tanımlamalıdır. Bu bir kalitenin, mesela bakım yapılabilirlik, üründe olup olmadığının değerlendirmenin standart bir yoludur.

Kalite Kontrol

Kalite kontrol, kalite güvence yordam ve standartlarına uyulmasını garanti etmek için yazılım geliştirme sürecinin gözden geçirilmesini gerektirir. Daha önce de tartışıldığı gibi yazılım sürecinin ara ürünleri, kalite kontrol sürecinde daha önceden tanımlanmış proje standartlarına karşı kontrol edilmektedir.

Kalite kontrol sürecinin yazılım geliştirme sırasında kullanılması gereken kendi yordam ve rapor kümesi vardır. Bu yordamlar yazılımı geliştiren mühendisler tarafından düzgün ve kolaylıkla anlaşılabilir olmalıdır. 

Kalite kontrole iki çeşit tamamlayıcı yaklaşım vardır:

1.       Yazılımı geliştirmek için kullanılan belgeleme ve süreçlerin kalite incelemesi bir grup insan tarafından yapılır. Bu kişiler proje standartlarının izlenmesinin ve yazılım ile belgelerin  standartlara uygunluğunun kontrolünden sorumludur. Standartlardan sapmalar kayıtlanmalı ve proje yönetiminin dikkatine sunulmalıdır.

2.       Üretilen yazılım ve standartların bir program tarafından yapılır ve geliştirme projesine uygulanan standartlarla karşılaştırılırsa buna otomatikleştirilmiş yazılım değerlendirme adı verilir. Otomatikleştirilmiş değerlendirme bazı yazılım özelliklerinin nicel ölçümlerini gerektirir.

Kalite Gözden Geçirmeleri

Bir süreç veya ürünün kalitesini geçerlemede en çok kullanılan yöntem gözden geçirmelerdir. Olası problemleri keşfetmek amacıyla bir grup insan, yazılım sürecinin bir kısmını yada tamamını, sistemi veya ilgili belgeleri incelerler. Gözden geçirme hakkındaki yorumlar resmi olarak kayıtlanmalı ve yazara yada keşfedilen problemlerin düzeltilmesinden sorumlu kişiye iletilmelidir.

Tasarım veya program denetimleri                                       Gereksinimlerdeki, tasarımlardaki veya koddaki detaylı hataları saptamak. Gözden geçirme, olası hatalardan oluşan bir kontrol listesi aracılığı ile yapılabilir.

Yordam gözden geçirmeleri                                                   Yönetime projenin genel yordam bilgisini sağlamak için. Bu hem süreç hem ürün gözden geçirmesidir ve maliyetler, planlar ve çizelgeler ile ilgilenir.

Kalite gözden geçirmeleri                                                      Ürün bileşenlerinin veya belgelerinin teknik analizlerini yapmak ve belirtim ile bileşen tasarımı, kod veya belgeler arasındaki uyumsuzlukları bulmak ve tanımlı kalite standartlarına uyumun garanti arasına alınması.

Gözden geçirme tipleri

Gözden geçirme takımının amacı hataları, tutarsızlıkları tespit etmek ve bunları tasarımcı yada belge yazarına bildirmektir. Gözden geçirmeler belge tabanlıdır ancak belirtimler, tasarımlar ve kodlarla sınırlı değildir. Süreç modelleri, sınama planları, konfigürasyon yönetimi yordamları, süreç standartları ve kullanıcı kılavuzları gibi belgelerin hepsi gözden geçirmelidir.

Gözden geçirme takımı etkili bir katkı yapacak proje elemanlarını da içermelidir. Örneğin, eğer bir alt sistem tasarımı gözden geçirilecekse ilgili alt sistemin tasarımcıları da gözden geçirme takımına dahil olmalıdır.

Gözden geçirme takımı, baş gözden geçiriciler olarak seçilmiş 3-4 kişilik bir çekirdeğe sahip olmalıdır. Bunlardan biri önemli teknik kakarları veren baş tasarımcılardan biri olmalıdır.  Baş gözden geçiriciler diğer proje elemanlarını gözden geçirmeye katılmaları için davet edebilir. Bütün belgeyi incelemekle zorunlu olmayabilirler. Bunu yerine işlerini etkileyen parçalara konsantre olabilirler. Alternatif olarak gözden geçirme takımı belgeyi gözden geçirme için dağıtabilir ve diğer proje elemanlarının yazılı yorumlarını isteyebilir.

Gözden geçirilecek belgeler, gözden geçirmenin yararı için gözden geçiricilere okuyacak ve anlayacak zaman bırakacak şekilde iyi dağıtılmalıdır. Bu ertelemenin geliştirme sürecini uzatabilmesine rağmen, gözden geçirme takımının gözden geçirme başlamadan önce belgeleri iyi anlamamış olması verimsiz bir gözden geçirmeye yol açar.

Gözden geçirme tek başına kısa olmalıdır (en fazla iki saat). İncelenecek belgenin yazarı, gözden geçirme takımı ile beraber belgeyi incelemelidir. Bir takım üyesi gözden geçirmeyi yönetmeli, bir diğeri ise alınan bütün gözden geçirme kararlarını resmi olarak kaydetmelidir. Gözden geçirme süresince yöneten kişi bütün yazılı yorumların ele alındığından emin olmalıdır. Gözden geçirme tamamlanması sırasında eylemler kaydedilmeli ve eylemler ile yorumları kayıtlayan formlar tasarımcı ve gözden geçirme yöneticisi tarafından imzalanmalıdır. Bunlar daha sonra resmi proje belgelendirmesinin bir parçası olarak dosyalandırılmalıdır. Eğer sadece küçük problemler keşfedildiyse daha ayrıntılı başka bir incelemeye gerek yoktur. Yönetici istenen değişikliklerin gerçekleştirildiğinden emin olmalıdır. Eğer büyük değişiklikler gerekiyorsa izleyecek bir gözden geçirme ayarlanmalıdır.

Yazılım Ölçümü ve Ölçütleri

Yazılım ölçümü, bir yazılım ürünü veya yazılım sürecinin bazı özellikleri için bir sayısal değer çıkarma ile ilgilenir. Bu değerleri, birbirleriyle ve kuruluşta bulunan standartlarla kıyaslayarak yazılımın veya yazılım sürecinin kalitesi hakkında yorumlar çıkarılabilir.Örneğin bir kuruluşun yeni bir yazılım sınama aracı kullanacağını düşünelim. Aracı kullanmaya başlamadan önce belli bir zamandaki yazılım hatalarının sayısı kaydedilir ve araç kullanılmaya başlandıktan sonra süreç tekrarlanır. Eğer aynı zamanda daha fazla hata fark edilmiş ise aracı kullanmanın yazılım doğrulama sürecine kullanışlı bir destek sağladığı söylenebilir.

Hewlett-Packard ve AT&T gibi büyük şirketler ölçüt programları kullanmaktadır ve toplanan ölçütleri kalite yönetim süreçlerinde kullanmaktadırlar. İlginin büyük çoğunluğu program hatalarını gösteren ölçütlerin toplanması ile doğrulama ve değerlendirme süreçlerine yöneliktir.

Buna rağmen sistematik yazılım ölçüm ve ölçütlerinin kullanımı hala nadirdir. Faydalarının açık olmamasından dolayı ölçümlere geçmekte bir isteksizlik vardır. Bir çok şirketteki sebeplerden biri, kullanılan yazılım süreçlerinin kötü düzenlenmesi ve bu ölçümlerden yararlanılabilecek yeterli olgunluğa ulaşılamamış olmasıdır. Diğer bir neden ise ölçümler için standartlar olmaması ve bu yüzden veri toplama ve analizi için sınırlı destek olmasıdır. Böyle standartlar ve araçlar ulaşılabilir olmadan bir çok şirke ölçümleri kullanmaya hazırlanmayacaktır.

Bir yazılım ölçütü, yazılım sistemi, süreci yada ilgili belgeler ile ilgili bir ölçüm tipidir. Bir ürünün kod satırı cinsinden büyüklüğü, yazılı belgenin okunabilirliğinin ölçüsü, dağıtılan bir yazılım ürünündeki rapor edilen hatalar ve bir sistem elemanını geliştirmek için gereken insan-gün oranı, ölçümlere örneklerdir.

Ölçütler, kontrol ölçütleri yada tahminleyici ölçütler olabilir. Kontrol ölçütleri genellikle yazılım süreçleri ile; tahminleyici ölçütler ise yazılım ürünleri ile ilgilidir. Kontrol yada süreç ölçütlerinin örnekleri ortalama çaba ve rapor edilmiş hataları düzeltmek için gereken süre olabilir. Tahminleyici ölçütlerin örnekleri ise bir birimin döngü karmaşıklığı, bir programdaki ayraçların ortalama uzunluğu ve bir tasarımdaki nesnelerle ilişkilendirilmiş özellik ve işlemlerin sayısı olabilir.

Tahminleyici ve kontrol ölçütleri

Genelde yazılım kalite özelliklerini doğrudan ölçmek imkansızdır. Bakım yapılabilirlik, karmaşıklık ve anlaşılabilirlik gibi özellikler bir çok değişik etkenden etkilenir ve bunlar için doğrudan ölçütler yoktur. Bunu yerine yazılımın baçı içsel özellikleri (büyüklüğü gibi) ölçülmekte ve ölçtüğümüz ile bilmek istediğimiz arasında bir ilişki olduğunu kabul ederiz. İdeal olarak iç ve dış yazılım özellikleri arasında açık ve doğrulanmış bir ilişki olmalıdır.

Aşağıdaki şekil ilgilenilebilecek bazı dış kalite özelliklerini ve bu özelliklerle ilişkilendirilebilecek ve ölçülebilir iç özellikleri göstermektedir. Şekil, iç ve dış özellikler arasında bir ilişki olması gerektiğini önermekte fakat bunu ne olduğunu söylememektedir.

İç ve dış yazılım özelliklerinin ilişkileri

Eğer iç özelliğin ölçütü, dış yazılım özelliğine yararlı bir tahminci is, üç koşula dikkat edilmelidir (Kitchenham, 1990):

1.       İç özellik tam olarak ölçülmelidir.

2.       Ölçebildiğimiz ile dış davranış özelliği arasında bir ilişki olmalıdır.

3.       Bu ilişki, anlaşılmış, doğrulanmış ve bir formül veya model olarak ifade edilebilir olmalıdır.

Model formülasyonu, modelin fonksiyonel formunun toplanan verilerin analizi ile tanımlanmasını (doğrusal, üstel, vb.), modele dahil olan parametrelerin tanımlanmasını ve mevcut verinin ince ayarlama gerektirir. Böyle bir model geliştirme istatistiksel tekniklerde belirli bir deneyim gerektirir. Süreç içinde profesyonel bir istatistikçi bulunmalıdır.

Ölçüm Süreci

Sistemdeki bileşenlerden her biri ayrı ayrı analiz edilmeli ve ölçütlerin farklı değerleri birbirleriyle ve önceki projelerden toplanan veri ölçümleri ile karşılaştırılmalıdır. Anormal ölçümler, kalite güvence çalışmasındaki kalite problemi bulunan bileşenler üzerine yoğunlaşmak için kullanılabilir.

Ürün ölçüm süreci

Bu süreçteki anahtar evreler:

1.       Yapılacak ölçümleri seç: Ölçümün neye cevap vereceği konusundaki sorular formüle edilmelidir ve bu soruları cevaplandırmak için gereken ölçümler tanımlanmalıdır. Bu sorularla doğrudan uyumlu olmayan ölçümlerin toplanması gerekli değildir. Bir sonraki bölümde tartışılacak Basili’nin HSÖ (Hedef-Soru, Ölçüt) paradigması hangi verinin toplanacağına karar vermede kullanmak iyi bir yaklaşımdır.

2.       Değerlendirilecek bileşenleri seç: Bir yazılım sistemindeki bütün bileşenlere ölçütler değerlendirmek gerekli veya istenen bir şey olmayabilir. Bazı durumlarda bileşenleri örnekleyen bir seçimi ölçüm için seçilebilir. Diğerlerinde, neredeyse sabit kullanımda olan çekirdek bileşenleri gibi bileşenler de değerlendirilebilir.

3.       Bileşen karakteristiklerini ölç: Seçilen bileşenler ölçülmeli ve ölçütler hesaplanmalıdır. Bu normalde otomatik bir veri toplama aracı kullanarak bileşen sunumunu (tasarım, kod, vb.) gerektirir.bu özel olarak yazılabilir yada kuruluş tarafından kullanılan CASE araçları arasında bulunabilir.

4.       Anormal ölçümleri ayırt et: Bileşen ölçümleri yapıldıktan sonra bunlar birbirleriyle ve ölçüm veritabanında kayıtlanan önceki ölçümlerle karşılaştırılmalıdır. Her ölçütteki olağandışı yüksek veya alçak değerlere bakılmalıdır. Çünkü bunlar bu bileşenlerde bir problem olduğunu gösterebilir.

5.       Anormal bileşenleri analiz et: Daha önce bazı ölçütlerde anormal değerlere sahip bileşenler ayırt edilmişti. Bu bileşenler, anormal ölçüt değerlerinin bileşenin kalitesini tehdit edip etmediğine karar vermek için incelenmelidir. Karmaşıklıktaki anormal bir ölçüt değeri kötü kaliteli bir bileşen olmayı gerektirmez. Yüksek değer için başka sebepler olabilir ve bu bileşende kalite problemleri olduğu anlamına gelmez.

Toplanan veri bir kurumsal kaynak gibi değerlendirilmeli ve bütün projelerin önceki kayıtları da özel bir projede kullanılmıyorsa bile değerlendirilmelidir. Büyük bir ölçüm veritabanı kurulursa projeler arası karşılaştırmalar yapılabilir ve kurumsal ihtiyaçlara göre özel ölçütler geliştirilebilir.

Ürün Ölçütleri

Ürün ölçütleri yazılımın karakteristikleri ile ilgilidir. Büyüklük ve dairesel karmaşıklık gibi kolayca ölçülebilen yazılım karakteristiklerinin anlaşılabilirlik ve bakım yapılabilirlik gibi kalite özellikleri ile açık ve evrensel bir ilişkisi yoktur. İlişkiler, geliştirme süreçleri ve teknolojisi, geliştirilecek sistemin tipine bağlı olarak değişir. Ölçümle ilgilenen kuruluşlar  bir geçmiş veritabanı oluşturmalıdır. Bu yazılım ürün özelliklerinin kuruluşun ilgi alanındaki kalitelerle nasıl ilişkili olduğunu keşfetmekte kullanılır.

Ürün ölçütleri iki sınıfa ayrılır:

1.       Çalışan bir programdan toplanan ölçümlerdeki hareketli ölçütler.

2.       Tasarım, program veya belgeleme gibi sistem işaretlerinin ölçümlerinden toplanan durağan ölçütler.

Farklı tiplerdeki ölçütler farklı kalite özellikleri ile ilgilidir. Hareketli ölçütler bir programın verimlilik ve güvenilirliğini değerlendirmeye yardımcı olurken, durağan ölçütler bir yazılım sisteminin karmaşıklık, anlaşılabilirlik ve bakım yapılabilirliğini değerlendirmeye yardımcı olur.

Hareketli ölçütler genellikle yazılım kalite özellikleri ile yakın ilgilidir. Bazı fonksiyonlar için gerekli çalışma zamanını ölçmek ve bir sistemi başlatmak için gerekli zamanı değerlendirmek göreceli olarak kolaydır. Bu doğrudan sistemin verimliliği ile ilgilidir. Ayrıca benzer olarak sistem hata sayıları ve hata tipi kayıtlanabilir ve doğrudan Bölüm 16’da anlatıldığı gibi yazılımın güvenilirliği ile ilgilidir.

Diğer taraftan durağan ölçütlerin kalite özellikleri ile doğrudan olmayan bir ilişkisi vardır. Bu ölçütlerin büyük bir bölümü önerilmiş ve bu ölçütler ile sistem karmaşıklığı, anlaşılabilirliği ve bakım yapılabilirliği ile ilişkileri çıkarılmaya ve doğrulanmaya çalışmak için deneyler yapılmıştır. Bunlardan program veya bileşen uzunluğu ve kontrol karmaşıklığı anlaşılabilirlik, sistem karmaşıklığı ve bakım yapılabilirlik ile en uygun tahminleyicilerdir.

Çağrılan/Çağıran                                       Çağrılan diğer bir fonksiyonu (örneğin X) çağıran fonksiyon sayısının ölçümüdür. Çağıran bir X fonksiyonu tarafından çağrılan fonksiyon sayısıdır. Yüksek bir çağrılan değeri X’in tasarımın geri kalanı ile yakın bir birleşmeye sahip olduğunu ve X’teki değişikliklerin büyük etkileri olduğunu gösterir. Yüksek bir çağıran değeri X’in genel karmaşıklığının bileşenleri koordine eden kontrol mantığının karmaşıklığından dolayı yüksek olabileceğini gösterir.

Kod uzunluğu                                            Bu programın büyüklüğünün bir ölçüsüdür. Genel olarak, bir program bileşeninin büyüklüğü bu bileşenin ne kadar çok karmaşık ve hataya eğilimli olduğunu gösterir.

Döngü karmaşıklığı                                   Bu bir programın kontrol karmaşıklığının ölçütüdür. Bu kontrol karmaşıklığı programın anlaşılabilirliği ile ilgili olabilir.

Tanımlayıcıların uzunluğu                       Bu bir programdaki ayrı tanımlayıcıların ortalama uzunluğunun ölçütüdür. Tanımlayıcılar ne kadar uzunsa o kadar anlamlı olurlar ve böylece program daha anlaşılır olur.

Koşullu yuvalanma derinliği                   Bu bir programdaki if cümlelerinin derinliğinin ölçüsüdür. Derin olarak iç içe geçmiş if cümleleri zor anlaşılırdır ve hatalara açıktır.

Sis endeksi                                                Bu dokümanlardaki kelime ve cümlelerin ortalama ölçüsüdür. Sis endeksi ne kadar yüksekse belge o kadar zor anlaşılırdır.

Yazılım ürün ölçütleri

Kalıtım ağacı derinliği                                              Bu, altsınıfların üst sınıftaki özellik ve metotlarını içerdiği kalıtım ağacındaki ayrı seviyelerin sayısıdır. Kalıtım ağacı ne kadar derinse tasarım o kadar karmaşık olur ve nesne sınıflarının dallarındaki nesnelerin anlaşılması gerekir.

Metot çağrılan/çağıran                                           Bu daha önce anlatılan çağrılan ve çağıran ile tamamen aynıdır. Buna rağmen, nesne içindeki diğer metotlar arasındaki çağrılar ve dış metotların  çağrıları arasındaki bir ayrım yapmak uygundur.

Sınıf başına ağırlıklı metotlar                                  Bu bir sınıftaki her metottaki karmaşıklığın ağırlıklandırılmasının içerildiği metotların sayısıdır. Bu yüzden, basit bir metot 1 karmaşıklığına sahiptir ve daha büyük ve karmaşık bir metot daha yüksek değer almaktadır. Bu ölçütün değerinin artması nesne sınıfının daha karmaşık olduğunu gösterir. Karmaşık nesnelerin anlaşılması da daha zordur. Bunlar mantıksal olarak yapışık olmayabilirler ve bir kalıtım ağacındaki üstsınıflar etkili olarak yeniden kullanılamaz.

Üstün gelen işlerin sayısı                                        Bunlar bir üstsınıftaki bir altsınıfta üstün gelinmiş işlemlerin sayısıdır. Bu ölçütün yüksek olması kullanılan üstsınıfın altsınıf için uygun bir kök olmayacağını gösterir.

Nesne tabanlı ölçütler

Uygun olan ölçütler projeye, kalite yönetim takımının hedefine ve geliştirilecek yazılımın tipine göre değişir. Kuruluşlar, yazılım ölçümlerini kalite yönetim sürecinin bir parçası olarak kullanırken hangi ölçütlerin ihtiyaçlarına uygun olduğunu bulmak zorundadırlar.

Ölçümlerin Analizi

Yazılım ve yazılım projeleri hakkında nicel veri toplamada ki problemlerden biri de verinin gerçekte ne anlama geldiğinin anlamaktır. Veriyi yanlış yorumlamak ve yanlış çıkarımlar yapmak kolaydır. Gerçekte ne anlama geldiklerini anlamak için ölçümler dikkatli analiz edilmelidir.

Toplanan verinin nasıl yorumlanabileceğini göstermek için aşağıdaki senaryoyu düşünelim:

Bir yönetici, bir müşteri tarafından yapılan değişiklik istekleri sayılarını izlemek için değişiklik istekleri ve ürün kullanılabilirlik ve uyumluluğu arasındaki ilişki olduğu varsayımını kullanmaya karar veriyor. Değişiklik isteği sayısı arttıkça yazılımın müşteri isteklerine uyumluluğu azalmaktadır.

Değişiklik isteklerini işlemek ve yazılımı değiştirmek pahalıdır. Bu yüzden kuruluş müşteri memnuniyetini artırmak için sürecini değiştirmiştir ve aynı zamanda değişiklik maliyetlerini azaltmıştır. Süreç değişikliklerinin daha iyi süreçlere ve daha az değişiklik isteğine yol açacağı düşünülmüştür.

Süreç değişiklikleri, yazılım tasarım sürecinde  daha çok müşteri katılımı gerektirecek şekilde başlatılmıştır. Bütün ürünlerde deneme testleri yapılmış ve istenen müşteri değişiklikleri dağıtılan ürüne eklenmiştir. Bu değiştirilmiş süreç ile geliştirilen yeni yazılım versiyonları dağıtılmıştır. Bazı durumlarda değişiklik isteği sayısı düşmüş, diğerlerinde artmıştır. Yönetici şaşırmış ve süreç değişikliklerinin ürün kalitesine etkisini değerlendirememiştir.

Böyle bir şeyin neden olduğunu anlamak için değişiklik isteklerinin neden yapıldığını anlamak gereklidir. Bir sebep dağıtılan yazılımın müşterinin yapmasını istediği şeyleri yapmaması. Diğer olasılık ise yazılımın aslında tasarım amaçları içinde yer almayan nedenler için çok iyi ve geniş olarak kullanılması. Programın bir çok kişi tarafından kullanılmasından dolayı daha çok daha çok değişiklik isteği yaratılması doğaldır.

Üçüncü olasılık ise yazılımı geliştiren şirketin müşterilerin değişiklik isteklerine karşılık vermesidir. Bu yüzden müşteriler aldıkları hizmetten memnundurlar. Bir çok değişiklik isteği yaratılırlar çünkü bunların ciddiye alınacağını bilirler. Önerileri büyük olasılıkla yazılımın sonraki versiyonlarında yer alacaktır.

Değişiklik istek sayıları azalabilir çünkü süreç değişiklikleri etkili olmuştur ve yazılımı daha kullanılabilir ve uyumlu hale getirmiştir. Sayı düşebilir çünkü ürün rakip bir ürüne karşı pazar payı kaybetmiştir. Sonuçta daha az ürün kullanıcısı kalmıştır. Değişiklik isteği sayısı artabilir çünkü daha çok kullanıcı vardır, çünkü deneme test süreci kullanıcıları şirketin değişiklik yapmaya istekli olduğuna inandırmıştır.

Değişiklik istek verisini analiz etmek için değişiklik isteği sayısını bilmemiz gerekmez. Değişikliği kimin istediğini, yazılımı nasıl kullanacağını ve isteğin neden yapıldığını bilmemiz gerekir. Ayrıca istek yordamına veya etkisi olabilecek pazar değişiklikleri gibi dış etkenleri bilmeliyiz. Bu bilgi ile süreç değişikliklerinin ürün kalitesini artırmada etkili olup olmayacağını bulmak mümkündür.

Bu, bir ürün veya süreç hakkındaki nicel verinin yorumlanmasının kesin olmayan bir süreç olduğunu gösterir. Ölçülecek süreç ve ürünler ortamlarından ayrılmamıştır ve ortamdaki değişiklikler verinin kıyaslanmasını değersiz yapar.