Yazılım Kalite Güvencesi ve Standartlar

1.1. Yazılım Kalite Yönetimi Nedir?

Yazılım Kalite Yönetimi, kullanıcıların yazılımı kullandıkları zaman onun performansından memnun olmaları için gerekli yazılım kalitesi seviyesini sağlayan bir süreçtir. Bu süreç kalite güvencesini, kalite planlamasını ve kalite kontrolünü içerir.

Yazılım geliştirme uzmanları için yazılım kalite yönetimini anlamaları önemlidir. Özellikle yazılım kalite yöneticilerine, yazılım testi uzmanlarına ve yazılım geliştiricilerin işine yarayacaktır.

1.2. Yazılım Kalite Temelleri

Kalite yazılımı, makul bir hata veya kusursuz olan, zaman içinde ve belirtilen bütçe dâhilinde teslim edilen, gereksinimleri ve / veya beklentileri karşılayan ve bakımı mümkün olan bir yazılımı ifade eder. Yazılım mühendisliği bağlamında, yazılım kalitesi hem fonksiyonel kaliteyi hem de yapısal kaliteyi yansıtmaktadır.

Yazılım İşlevsel Kalitesi

İşlevsel gereksinimlere veya özelliklere bağlı olarak belirli bir tasarımı ne kadar iyi karşıladığını ifade eder.

Yazılım Yapısal Kalitesi

Sağlamlık veya sürdürülebilirlik gibi fonksiyonel gereksinimlerin sunulmasını ve yazılımın doğru şekilde üretilme derecesini destekleyen işlevsel olmayan gereksinimlerin ele alınmasıyla ilgilenir.

Yazılım Kalite Güvencesi

Yazılım Kalite Güvencesi (SQA), kaliteli yazılım ürünleri ile sonuçlanan yazılım mühendisliği süreçlerinde kaliteyi sağlamak için yapılan faaliyetler dizisidir. Bu faaliyetler, ürünler üreten süreçleri belirler ve değerlendirir. Bu da süreç odaklı eylemi içerir.

Yazılım Kalite Kontrolü

Yazılım Kalite Kontrolü (SQC), yazılım ürünlerindeki kaliteyi sağlamak için kullanılan bir aktiviteler dizisidir. Bu faaliyetler üretilen gerçek ürünlerde kusurları tespit etmeye odaklanmaktadır. Ürün odaklı eylem içerir.

1.3. Peki, Neden Kalite Önemlidir?

Kaliteli ve güvenilir bir yazılım ürününün, istenilen gereksinim ve beklentileri belirlenen bütçeye göre zamanında teslim edilen bir ürün olduğunu söylüyoruz hep. Ayrıca, yazılım ürününün sürdürülebilir olmasının da önemli olduğu vurgulanıyor. Bu unsurların önemini yazılımda yapılan hataların örnekleri üzerinden görelim.

Yıl 1962, Mariner 1 roketi

Hatanın sonucu: Venüs’e giden Mariner 1 roketi, fırlatıldıktan hemen sonra rotasından saptı. Düşme riski çok yüksek olduğu için NASA mühendisleri kendi kendini imha etme emrini verdi. Roket havada 293 saniye sürdü. Kayıplar 18,5 milyon dolar olarak gerçekleşti.

Sebep: Programcı, el yazısıyla yazılmış formülü yanlış bir şekilde sembolün üstündeki satırı atlayarak bilgisayar koduna gömdü. Bu özellik kenar yumuşatmadan sorumlu olduğu için, yazılım belirli bir hızdan kritik olarak normal sapmaları algıladı. Sonuç olarak, roketteki bilgisayar yanlış düzenlemeler yaptı ve roketi rotasından saptırdı.

Yıl 1987, Hartford Coliseum salonunun çöküşü

Hatanın sonucu: İki basketbol takımının karşılaşmasının ardından birkaç saat geçmedi, çünkü stadyumun çelik çatısı ıslak kar ağırlığı altında çöktü. Kayıplar – 70 milyon dolar ve 20 milyona yakın yerel ekonomiye zarar.

Sebep: CAD programcısı, stadyumu tasarlamak için kullanılan yazılım ile çatı desteklerinin sadece küçüleceğini öne sürdü. Bu nedenle, bir tanesi karın ağırlığı altında çöktüğünde, zincir reaksiyonu başlattı ve çatı bir domino gibi art arda düştü.

1985, Tıbbi Therac-25 cihazı

Hatanın sonucu: Radyasyon tedavisi için Therac-25 tıbbi cihaz saptadı ve hastalara ölümcül dozda radyasyon verdi. Dört kişi öldü, iki kişinin sağlığına ise ciddi zarar verdi.

Sebep: Cihazın iki çalışma modu vardı – elektron ışını direkt olarak hastaya küçük dozlarda gönderildiğinde, ikincisi ise ışın ilk olarak radyasyon ışınlarına dönüşen ve hastaya iletilen metal bir “hedefe” yöneldiğinde. Cihazın önceki modellerinde, ikinci mod, yerinde “hedef” bulunan fiziksel dedektörlerle donatılmıştır, böylece ışınlar doğrudan hastaya büyük dozlarda yönlendirilmeyecekti. Therac-25’te, fiziksel dedektörler yazılım dedektörleri ile değiştirildi. Ne yazık ki, yazılım “aritmetik yüklenmeye” tabi tutuldu – sistem dahili hesaplarda kullanılmaya başlandı ve bu sayı onunla yapılan işlemler için çok büyük bir sayıydı. Bu esnada operatörün makineyi yapılandırması halinde güvenlik kontrolleri başarısız oldu ve “hedef” yerine oturmadı. Sonuç olarak, hasta 100 kat daha yüksek bir radyasyon dozu aldı.

1993, Pentium ve ondalık sayı hatası

Hata Sonucu: Intel’in yeni Pentium işlemcisi, belirli bir aralıktaki ondalıklı sayıları bölerken zaman zaman hata yaptı. Örneğin, 4195835.0 / 3145727.0 sonucu 1.33382 yerine 1.33374 sonucunu verdi. Bu da % 0.006’lık bir hata. Sorun az sayıda kullanıcıyı etkiledi, ancak Halkla İlişkiler hizmetlerinin kâbusu haline geldi. Kullanımda yaklaşık 5 milyon bozuk çip vardı. Intel başlangıçta, bu çipleri sadece yüksek hassasiyete ihtiyaç duyduğunu kanıtlayanlara değiştirmeyi teklif etti, ancak sonuç olarak tüm çipler değiştirildi. Kayıplar – 475 milyon dolara mâl oldu, bu da şirketin itibarına büyük hasara yol açtı.

Sebep: bölme tablosundaki bir hata, her bin göstergenin yaklaşık 5’inin eksik olmasıyla sonuçlandı ve yuvarlama hatasına neden oldu.

Yıl 1996, Ariane roketi

Hatanın sonucu: İnsansız füze Ariane fırlatıldıktan birkaç saniye sonra imha edildi. Roketle birlikte, dünyanın manyetik alanının güneş rüzgârıyla etkileşimini incelemek için kullanılan dört bilimsel uydu da imha edildi. Zararlar 500 milyon dolar (uydular) artı 8 milyar dolarlık Ariane geliştirme maliyetidir.

Sebep: Araç bilgisayarı roketin hızını 64 bit biçiminden 16 bit olana dönüştürmeyi denedi. Sonuç çok büyüktü ve bilgisayar başarısız oldu. Füzenin kontrolü, aynı algoritmayı kullanan güvenlik modülüne aktardı, ancak o da bir süre sonra kapandı.

Yıl 1998, Mars Climate Orbiter

Hatanın sonucu: uçuşunun 286. gününde, Mars Climate Orbiter uydusu, Mars eliptik yörüngesine geçiş başladı. Cihaz motorları fren yapmak için çevirdi ve yörüngeye “uçtu”. Büyük ihtimalle, Mars’ın atmosferine girdi ve çöktü. Kayıplar 125 milyon dolara ulaştı.

Sebep: motorun itiş gücünü kontrol eden yazılım, Newton’un ölçü birimi olarak pound kuvveti ölçü birimini kullanmıştır. Uydu rotasında bir sapmaya yol açan motor itme komutları ise ölçü birimi olarak Newton’ları kabul ediyordu.

Yıl 2008, Heathrow Havaalanı

Hatanın sonucu: Yeni Heathrow terminalinde çok sayıda ürünü taşımak için tasarlanmış ultra modern bir bagaj kontrol sistemi kurdular. Sistem 12 binden fazla çanta ve valizlerle kapsamlı bir şekilde test edilmiştir. Sonuç olarak, terminalin açılış gününde, sahipleriyle birlikte uçmadan 42 bin valiz kayboldu. 500’den fazla uçuş iptal edildi. Diğer uçuşlar için check-in geçici olarak askıya alındı.

Sebep: Sistem, bazı nedenlerle test sırasında test edilmeyen gerçek senaryolarla başa çıkamamıştır. Örneğin, valizlerin manuel olarak çıkarılması (yolcunun aniden valizde değerli ve gerekli bir şey olduğunu hatırlaması) programı çıldırtıyor ve kapatıyordu.

1.4. Yazılım Kalite Güvencesinin Kullanıldığı Ortamlar

Birçok kişi tarafından geliştirilen ve farklı durumlarda geliştirilen yazılım çeşitli ihtiyaçları karşılar:

Öğrenciler yazılımı eğitimlerinin bir parçası olarak geliştirir. Yazılım amatörleri yazılımı bir hobi olarak geliştirir. Mühendislik, ekonomi, yönetim ve diğer alanlardaki uzmanlar, yazılımı işlerinde yardımcı olmak, hesaplamalar yapmak, araştırma ve anket aktivitelerini özetlemek gibi işleri için yazılım geliştirir. Yazılım geliştirme uzmanları (sistem analistleri ve programcıları), yazılım şirketlerinde veya yazılım şirketlerinin istihdam edilmesinde, büyük ve küçük sanayi, finans ve yazılım geliştirme ve bakım birimlerinde ( ekipler, departmanlar, vb. ) çalışarak profesyonel bir kariyer hedefi olarak yazılım ürünleri veya yazılım geliştirir.

Bu etkinliklere katılan herkesin, yazılım kalite problemleriyle (“hata”) ilgilenmesi gerekmektedir. Bununla birlikte, çok ciddi olan kalite sorunları profesyonel yazılım geliştirmeye yol açar.

Büyük çaplı projelerde, yazılım geliştirme sürecinde sadece yazılıma yönelik planlama, kodlarını yazma, yazılan kodları test etme gibi önemli unsurlar yer almamaktadır. Bunlar dışında, projenin yönetilmesiyle ilgili, proje bütçesinin takip edilmesiyle ilgili ve geliştirilen ürünün müşterinin beklentilerini karşılayıp karşılamadığını kontrol etmek, dolayısıyla müşteri ile sürekli bir iletişimde olmak, geliştirici takımların arasındaki ve / veya tedarikçiler arasındaki işbirliği, kısaca, iş akışı unsurlarının da kontrol edilmesi gerekmektedir.

Aşağıda, büyük çaplı bir projede karşılaşılan sözleşme koşulları, müşteri ile tedarikçi ilişkileri, takım çalışması ve diğer geliştirici ekipleriyle işbirliği ile koordinasyon gibi önemli konular açıklanmıştır. Gösterimi ise Şekil 2’de verilmiştir.

Şekil 3. Büyük çaplı projelerdeki yazılım ekibinin işbirliği ve koordinasyon şekli

1. Sözleşme koşulları

Yazılım geliştirici ve müşteri arasındaki sözleşmede tanımlanan taahhütler ve koşullar sonucunda, yazılım geliştirme ve bakım faaliyetlerinin aşağıdakileri başa çıkması gerekir:

Geliştirilen yazılımın ve bakımın yerine getirilmesi gereken fonksiyonel gereksinimlerin tanımlanmış bir listesi.
Proje bütçesi.
Proje takvimi.

Yazılım geliştirme ve bakım projelerinin yöneticileri, sözleşmenin şartlarını yerine getirmek için faaliyetlerin denetlenmesinde önemli miktarda çaba harcamalıdır.

Yazılım Kalite Kontrolü – Yazılım Kalite Kontrolü (SQC), yazılım ürünlerindeki kaliteyi sağlamak için kullanılan bir aktiviteler dizisidir. Bu faaliyetler üretilen gerçek ürünlerde kusurları tespit etmeye odaklanmaktadır. Ürün odaklı eylem içerir.

2. Müşteri-tedarikçi ilişkisi

Yazılım geliştirme ve bakım süreci boyunca, faaliyetler müşterinin gözetimi altındadır. Proje ekibi sürekli olarak müşteriyle işbirliği yapmak zorundadır: değişiklik talebini değerlendirmek, projenin çeşitli yönleri ile ilgili eleştirilerini tartışmak ve geliştirme ekibi tarafından başlatılan değişiklikler için onayını almak zorundadır. Yazılım uzmanı olmayanlar tarafından geliştirilen yazılımlarda bu tür ilişkiler genellikle mevcut değildir.

3. Takım çalışması

Üç faktör genellikle projeyi bir profesyonele vermek yerine proje ekibinin kurulmasını motive eder:

Zaman çizelgesi gereksinimleri. Diğer bir deyişle, proje süresi içinde üstlenilen iş yükü, projenin zamanında tamamlanması halinde birden fazla kişinin katılımını gerektirmektedir.
Projeyi yürütmek için çeşitli uzmanlıklara duyulan ihtiyaç.
Proje kalitesinin artırılması için profesyonel destek ve gözden geçirme isteği.

4. Diğer yazılım ekipleriyle işbirliği ve koordinasyon

Projelerin, özellikle büyük ölçekli projelerin, birden fazla ekip tarafından taşınması, yazılım sektöründe çok yaygın bir olaydır. Bu durumlarda aşağıdakiler ile işbirliği gerekebilir:

Aynı kuruluştaki diğer yazılım geliştirme ekipleri.
Aynı organizasyonda donanım geliştirme ekipleri.
Diğer tedarikçilerin yazılım ve donanım geliştirme ekipleri.
Projenin geliştirilmesinde yer alan müşterinin yazılım ve donanım geliştirme ekipleri. Geliştirme ekibinin perspektifinden görüldüğü gibi, işbirliği ihtiyaçlarının bir taslağı Şekil 2’de gösterilmiştir.

5. Diğer yazılım sistemleri ile arayüzler

Günümüzde çoğu yazılım sistemi diğer yazılım paketleriyle arayüzler içermektedir. Bu arayüzler, elektronik sistemlerdeki verilerin, diğer yazılım sistemleri tarafından işlenen verilerden bağımsız olarak, yazılım sistemleri arasında akmasına izin verir. Aşağıda bazı arayüz türleri ifade edilmiştir:

Diğer yazılım sistemlerinin yazılım sisteminize veri aktardığı giriş arayüzleri.
Yazılım sisteminizin işlenmiş verileri diğer yazılım sistemlerine aktardığı çıktı arabirimleri.
Tıbbi ve laboratuvar kontrol sistemlerinde, metal işleme ekipmanlarında vs. olduğu gibi, makinenin kontrol paneline giriş ve çıkış arayüzleri.
Tüm bu geliştirme aşamalarına kulak verilmesi önemlidir. Geliştirme sürecindeki bu aşamaların takip edilmesi müşteri memnuniyetine yol açar. Müşterinin beklentileri ve istekleri karşılandığı zaman bir proje başarılı olarak sayılır. Geliştirilen ürün gereken zamanda ve anlaşma yapılan maliyete uygun bir şekilde tamamlanarak, istenilen işlevleri eksiksiz olarak yerine getiriyorsa başarılı bir iş yapılmış olur. Başarılı bir proje elde edilir.
Bu tarz zamanında tamamlanmış ve görevlerini yerine getiren başarılı projelerinin artırılması ise – yazılım mühendisliğinin amacıdır. Yazılım mühendisliğine önem veren ve bu alanın içerdiği kavram ve yöntemleri kendi projelerinde uygulayan geliştiriciler projeden olan beklentilerinin karşılığını alabilirler. Hem proje beklentileri karşılanmış olur hem de daha kaliteli, güvenilir ve bakımı kolay bir ürün ortaya çıkar.
Bir yazılım ürünü, tasarım, kodlama, test etme gibi süreçlerden sonra kullanıma sunulur. Ayrıca, kullanıma sunulduktan sonra bakıma ihtiyacı var. Bu süreçlerin birçok uygulanma şekli (ya da modelleri) var. Günümüzde kullanılan örnek modeller: Waterfall, Sripal, Big Bang, Agile vb. modellerdir. Daha detaylı olarak bu modeller Bölüm 3’te verilmiştir.
İleriki bölümlerde, yazılımın kaliteli olması için neler yapılmalı, neler dikkat edilmeli? Yazılımın Kalite güvencesi nedir ve buna nasıl başlanır? konuları incelenmiştir. Yazılım geliştirme sürecinde karşılaşılabilecek hata türleri daha detaylı olarak anlatılmış ve onların önlenmesi için neler kullanıldığı konusunda bilgiler verilmiştir. Ayrıca, yazılım geliştirme sürecini kolaylaştırmak amacıyla kullanılabilecek araçlardan bahsedilmiştir. Geliştirilen yazılım iyileştirilebilmesi için kullanılabilecek yöntemler de verilmiştir. Böylece, bu konuların anlatımı ile, Kaliteli Yazılım nasıl geliştirilir? Yazılım Geliştirme süreci aşamaları nelerdir? Yazılım Kalite Standartları nedir ve nelerdir?, kısaca, Yazlım Kalite Güvencesi ve Standartları konusunda bilgi vermek amaçlanmıştır.

Yazılımda Yapılan Hata Türleri 2.bölüm

Thomas Edison’un zamanından bu yana, mühendisler geliştirdikleri sistemdeki hatalara değinmek için “bug” kelimesini kullandılar. Bu kelime çok sayıda olası problemi tanımlayabilir. “Bilgisayar hatası” nın ilk belgelenmiş hali, 1947’de Harvard Üniversitesi’nde Mark II bilgisayarının bir rölesinde tutulan güveyi içeriyordu. Bilgisayar operatörü Grace Hopper, böceği laboratuvar kayıtlarına “bir hatanın bulunduğuna dair ilk gerçek ( ya da somut ) durumu” şeklinde yapıştırarak belirtmişti. 1950’lerin başında, bilgisayarlara ve bilgisayar programlarına uygulanan “hata” ( “bug” ), “hata ayıklama” ( “debug” ve “debugging” ) terimleri, popüler basında yer almaya başladı.

Yazılım ürünlerinden olan önemli beklentilerinin biri güvenilirlik olduğunu belirtilmişti. Yazılım güvenilirliğinin temel kavramları ise hata, kusur/aksaklık ve arızalardır. Mesleki konuşmalar arasında, yazılım destekli sistemlerdeki sorunları anlatabilmek için “sistem çöktü”, “sistem bozuldu”, ”tasarımcı hatası” gibi ifadeler kullanılır. Bu kavramların anlamlarına ve tanımlarına bakalım.

Hata ( Error )
Yanlış bir sonuç üreten bir insan eylemi

(ISO 24765) [ISO 17a]

Kusur ( Defect )
Bir uygulamanın başarısız olmasına veya hatalı sonuçlar üretmesine neden olabilecek bir düzeltilmemiş sorun ( “fault” eşanlamı ).

(ISO 24765) [ISO 17a]

Fault: kusur, Bir işlevsel birimin, istenen bir işlevi yerine getirme yeteneğini azaltan ya da bu yeteneğin tamamen ortadan kalkmasına neden olabilen normal dışı durum.

[TSE Bilim Terimleri Sözlüğü]

Arıza ( Failure )
Bir işlevsel birimin, talep edilen bir işlevi yerine getirebilme yeteneğinin sona ermesi.

[TSE Bilim Terimleri Sözlüğü]

Verilen tanımlara göre, eğer bir kusur ( içeren yazılım ) çalıştırılırsa, bu yazılımın veya sistem bileşeninin arızalanmasına neden olabilir. Kusur ile arıza arasındaki ilişkisi, “arıza modeli” şeklinde TSE Bilişim Terimleri Sözlüğünde verilmiştir ve gösterimi Şekil 1’de verilmiştir.

Şekil 1 “Arıza Modeli”, (b) IEC 50 ( 191 ), TSE Bilişim Terimleri Sözlüğü

Yazılımda yapılan çoğu hatalar insan kaynaklıdır. Yazılım geliştirme aşamalarının her birinde yapılan bu hataların kodlama aşamasında yapılanlarını inceleyelim.

2.1. Uygulama Geliştirme Aşamasında Yapılan Hatalar

Hatalar yazılım geliştirme sürecinde kaçınılmazdır. Geliştiricinin kendi kendine test ettiği zamanları bile kolay kolay ortaya çıkmayabilirler. Hiç hata içermeyen bir yazılım geliştirmek imkânsızdır, yalnız, doğru bir hata yönetimi ile hataları azaltabiliriz.

Uygulama geliştirme aşamasında yapılan hatalar şu şekilde gruplanabilir:

Sözdizimi hatalarıÇalışma zamanı hatalarıMantık hataları

2.1.1. Sözdizimi Hataları (Syntax Errors)

Kullanılan programlama dilinin kurallarına aykırı olan ifadelerinin kullanılmasından kaynaklanır. Bazı durumlarda hemen fark edilebilir, yalnız, gözden kaçtığı durumlar da olabilir. Bu durumlarda derleyici tarafından yapılan uyarılar vasıtasıyla, hatanın yapıldığı satır numarasını öğrenebiliriz. Ayrıca, günümüzde kullanılan çeşitli IDE ( Integrated Development Environment )’ler sayesinde bu hatalar hemen fark edilmektedir ve / veya otomatik olarak düzeltilmektedir. Kodlama esnasında yapılan hatalarının fark edilmesi ve düzeltilmesi için, bu hatalar farklı dikkat çekici renklerle belirmektedir. Bazı geliştirme ortamları, aşağıdaki özellikleri de içermektedir:

– bağlamsal yardımın mekanizması (anahtar kelimeyi yazdıktan sonra, giriş işlemcisinin veya kullanılan prosedürün argüman listesinin tam sözdiziminin gösterildiği bir pencere görünür);

– eleman listesinin otomatik olarak gösterilmesi (örneğin, kontrolün isminden sonra, istenen özelliklerin seçilebileceği tüm özellikler ve metotların bir listesi görünür).

Ayrıca, bu söz dizimi hataları sorunu çözmek için çeşitli hata bulma teknikleri de kullanılmaktadır. Sözdizimi hatasına bir örnek verelim.

Bir yazılım için Ruby programlama dili kullanılıyor ise ve bir metni ekrana yazdırmak için kullanılan “print” komutu yerine “pint” diye yazılırsa, bu bir sözdizimi hatası olur. Bunun bir hata olduğunu gösteren örnek bir IDE Şekil 2’deki gibi bir renklendirme kullanmaktadır.

.1.2. Çalışma Zamanı Hataları (Run Time Errors)

Çalışma zamanı ( “run time” ya da “compile time” ) hataları, programın çalıştırıldığı anda ve / veya yazılımın müşterinin makinesine kurulduğu anda ortaya çıkan hatalardır. Genelde, bir fonksiyon belirli varsayımlar üzerine kodlanır, ancak kullanıcının programı çalıştırdığı zaman istenilen o şartlar sağlanmadığı için bu hatalar oluşur. Dolayısıyla, bu tür hataların ne zaman oluşabileceğini tahmin etmek zordur. Günümüzde, bu tür hataları önleyebilmek için “istisnai durumlar” oluşturulmaktadır. Olmayan bir dosyaya veri yazmaya çalışmak; olmayan bir dosyayı okutmak; yazılım içerisinde istenilen dosyanın belirtilen yerde bulunamaması gibi durumlar bu tür hataların birer örneğidir.

Çalışma zamanında oluşan hatalar, farklı programlama dillerinde farklı hata numaraları içermektedirler. Hata numaraları ile hatanın çözümünü araştırmak ve bulmak daha kolaydır. Böylece, hata numaraları sayesinde hata nedenini ve çözüm yolları bulunabilir; bu hatalar ve numaraları bazı programlama dillerinin kendi kitapçıklarında belirtilebilir.

2.1.3. Mantıksal Hatalar (Logical Errors)

Programın kendisinden beklendiği sonuçlardan farklı sonuçlar üretmemesi ve beklenenden farklı bir sırada çalışması diyebiliriz. Ayrıca, yazılım geliştirme esnasında tasarlanan yanlış bir algoritmik gidişat da mantıksal hatalara yol açar. Dolayısıyla, algoritmanın doğru bir yol izleyecek şekilde tasarlanması önemlidir. Çünkü mantıksal hataların tespit edilmesi zordur. Örneğin; matematiksel bir hesabın yapılması gereken bir uygulamada, kodlama esnasında * ( çarpı ) yerine yanlışlıkla + ( artı ) ifadesinin kullanılması, yanlış sonuçlar vererek, buna bağlı olan tüm diğer hesapları da yanlış sonuçlar vermesine neden olur. Bu tür hatalar, örneğin, bordro işlerinde büyük sorunlar yaratabilir. Yazılımda yapılan bu tarz mantıksal hataları düzeltmek amacıyla yama ( patch ) yazılımları üretilir ve kullanıcıların yazılımlarının güncellenmesi beklenir.

Bu tarz hatalar yazılımın yapılandırılmasında her zaman oluşabilir. McConnell, “Kod Tamamlama” ( “Code Complete” ) kitabının önemli kısmını kaliteli kaynak kod yazmak için etkili teknik ve yöntemleri anlatmaktadır. Genel programlama hatalarını ve verimsizliklerini anlatmaktadır. McConnell’a göre tipik programlama hatalarının listesinde yer alan bazı hatalar aşağıdaki gibidir:

Yanlış programlama dili seçimiKarmaşıklık yönetiminin en baştan gösterilmemesiTasarım belgelerinin yetersiz anlaşılması/yorumlanmasıAnlamsız soyutlamalarDöngü ve koşul hatalarıVeri işleme hatalarıGirilen verilerin yetersiz denetimi

2.2. Mimari ve Tasarım Hataları

Yazılım tasarımcıları, müşterinin istek ve gereksinimlerini yazılıma çevirdiği zaman çeşitli hatalar yapmaktadır. Yaygın ve tipi olarak yapılan hataların bazıları şu şekildedir:

Geliştirilecek olan yazılımın eksik ve yetersiz incelenmesi
Her bir yazılım bileşeninin ( sorumluluk, iletişim ) net olmayan rolü
Belirtilmemiş birincil veri ve veri işleme sınıfları
Gereksinimleri yerine getirmek için kullanılan yanlış algoritmalar
Yanlış iş veya işleme sırası
İş süreç tasarımının zayıf kalması
Geliştirilen uygulamanın % 80’inin istisnai durumlar ve hatalar üretmesi
2.3. Yetersiz İnceleme ve Test
Yazılım İncelemelerin ve testlerinin yapılmasının amacı, yazılımdaki hataları tespit etmek ve bu hataların ortadan kaldırılıp kaldırılmadığını kontrol etmektir. Yazılım incelemeleri “codeview” olarak da bilinir. Bu “codeview” aşaması, yapılan hataya göre uzun bir süre ve zaman çalabilmektedir. Birden fazla geliştirici ile birlikte yapıldığı zaman ise, diğer yapılması gereken işlerin aksamasına yol açar. Dolayısıyla, bu “codeview” toplantılarının planlı bir şekilde yapılması gerekmektedir. Bunun kararı ise, proje geliştirme kapsamında seçilen ve uygulanmakta olan yazılım geliştirme modeli tarafından belirlenmektedir. Ayrıca, test aşamalarının da nasıl yapılacağı belirlenir ve yazılım testinin de sağlam bir şekilde yapılması beklenir. Bu aşama etkili bir şekilde yapılmazsa, müşteriye teslim edilen yazılımın arızalı olacağının ihtimali yüksektir.
2.4. Belgelendirme Hataları
Bir kuruluşta kullanılan yazılım için eski veya eksik belgelerin yaygın bir sorun olduğu kabul edilmiştir. Dolayısıyla birkaç geliştirme ekibinin, belgelerin hazırlanması ve gözden geçirilmesi için zaman ayırmaları önemlidir.
Yazılan kodlar, ortalama olarak 3 – 6 ay içerisinde unutulmaktadır. Dolayısıyla, bir hata ile karşılaşınca, bakılması gereken koda en son 6 önce bakıldı ise, hatanın nerden geldiğini bulmak ve hatta hangi fonksiyonun ne işe yaradığını anlamak zaman alır. Ancak, geliştiricinin elinde ilgili kod parçası hakkında ne iş yaptığı, neyi ve nasıl hesapladığı konusunda bilgiler içeren bir belge olursa, hem hatırlaması kısa zaman alır hem hatayı daha hızlı bulma imkânı olur. Özellikle de, bu geliştirici ekibe yeni gelen birisi ise, kod hakkında bir belgenin olmaması onun durumunu daha da zorlaştıracaktır. Bu yüzden, yazılım geliştirme sürecinin önemli ve olmazsa olmaz aşamalarının birisidir belgelendirme. Belgelendirme aşaması daha detaylı olarak “Yazılım Tasarımı ve Yazılması” başlıklı Bölüm 4’te anlatılmıştır.

2.5. Peki, Bu Hatalar Nasıl Önlenir? Nasıl Çözülür?

Hepimiz hata yaparız. Örneğin, evden ayrılmadan önce ışıkları söndürmeyi unutuyor olabiliriz. Ya da bir yazılım geliştiricisi olarak, ekip ile birlikte üzerinde çalıştığı en yeni yazılım projesine yanlışlıkla bir kusur getirilebilir. Geliştirme sırasında kusurlar kaçınılmaz olsa da, bir üretim ortamına ulaşmadan önce tamamen ( uzun bir sürede olsa bile ) tespit edilebilmekte, sabitlenebilmekte ya da önlenebilmektedir. Şu ana kadar yazılım hata türleri incelendi, şimdi ise genel yazılım kalitesini artıracak, gerileyen sorunları azaltacak, ekipler arası iletişimi geliştirecek ve müşteri memnuniyetini artıracak olan üretim hatalarını azaltmak için birkaç yöntem inceleyeceğiz. Bu yöntemler şu şekildedir.

Toplum / Topluluk Düşüncesi ( Groupthink ) ile ilgili kusurları değiştirmek
Hatalar, genel yazılım geliştirme yaşam döngüsü boyunca bir noktada kaçınılmazdır, ancak geleneksel olarak yönetilen birçok kuruluş, kusur ve hata yönetimini, hataları geri almak için temel olarak ikili bir savaş olarak gösterir. Kusurların mahsur kaldığı ve gelişiyle mücadele edecek sağlıklı süreçlerin planlanması ve yürütülmesi gerektiği konusunda kabuller nadiren vardır. Gelişimdeki kusurlar mutlaka istenmeyen birer kötülük olsa da, amaç sadece hataları ortadan kaldırmak olmamalıdır, kusurların tanımlanmasını, hata ayıklanmasını ve çözümünü basitleştiren uygulamalar ve prosedürleri geliştirmek de amaçlanmalıdır. Daha da önemlisi, bu süreçler gelişim yaşam döngüsünün erken döneminde uygulanmalı ve sürekli olarak geliştirilmelidir. Yerinde ve zamanında sağlıklı uygulamaların kullanılması ile, kusurlar artık kaçınılmazlık olarak kabul edilmeyen bir şey haline gelebilir. Tam tersine, ancak nadir bir sürpriz olarak – bunu beklemiyordunuz, ama onu gördüğünüze çok sevindiniz ve daha fazla araştırmak için bir arzu olur.

Özellikle tutumlar üzerinde daha geleneksel bakış açılarına alışmış sağlam kuruluşlar için bu tutumdaki değişim zor olabilir, ancak tutumdaki değişim yukarıdan aşağı doğru bir süreç olmalıdır. Yürütücü ile yöneticiler, kusurların ( özellikle üretimde ) kaçınılmaz olduğunu ve bunun yerine hataları istisna olarak gördüklerine dair algılarını değiştirmelidir. Algıdaki bu değişim sonunda, şirket genelinde aşağı doğru hareket edecek ve sonuç olarak grupların kusurlarla ilgili tutumlarında bir paradigma kaymasına yol açacaktır. Bu, kuruluşun sorunları nasıl ele aldığına dair değişikliklere yol açacak ve sonuçta üretim hatalarında büyük bir düşüş sağlanacaktır.

Yazılım Gereksinimlerini İyice Analiz Etmek
Düzenli olarak ( haftalık, aylık, çeyreklik, vb. şekilde ) uygun bir zaman bloğunu bir kenara koymak ve projenin detaylı yazılım gereksinimlerini tartışmak için ekip boyunca yöneticiler ile geliştirici liderleri ile görüşmek gerekir. Bu süreç, genel uygulama için tam olarak hangi gereklilikleri, ayrıca detaylı bileşen veya özellik-odaklı gereklilikleri belirtilmelidir. Bu uygulamanın en büyük yararı, potansiyel tuzakların açığa çıkarılması ve aksi takdirde, yolun herhangi bir yerinde ortaya çıkabilecek büyük bir eksikliğin önlenmesidir.

Örneğin, ekibinizle tanışan bir yazılım gereksinimleri analizi sırasında, daha önce planlanmış olan (Azure gibi) veri katmanı uygulamasının gerekli bir üçüncü taraf bileşenle çalışmayabileceği sonucuna varılabilir, bu nedenle gereksinimler başka bir çözümle değiştirilmelidir (örn., AWS – Amazon Web Service gibi). Bu tür bir sorunu yazılım geliştirme yaşam döngüsünün erken dönemlerinde tespit edememek, çoğu zaman acı verici sorunlara yol açacaktır ve yeterince uzun bir süre ihmal edilirse, daha önceden kolayca önlenebilecek fakat artık önlenmesi zor olabilecek bir dizi üretim hatasına neden olabilir. Bir uygulamanın geliştirilmesi sırasında ortaya çıkan kusurların büyük çoğunluğu, yazılım gereksinimi planlaması sırasında gerçekleşen hatalar ile ilişkili olduğundan, gerçek kodlama ve uygulama sorunlarının aksine, bu gereksinimlerin planlanma işleminin ciddiye alınması ve hem erken hem de sık olarak gerçekleştirilmesi önemlidir.

Kod Düzeltmeleri Sık Sık Uygulamak
Sağlam yazılım gereksinimlerini oluşturmak için sunulan sağlam bir planla birlikte, bir sonraki alışkanlık, kuruluş çapında kod iyileştirme uygulamalarını uygulamak olmalıdır. Refactoring, temel davranışını değiştirmeden mevcut kodun yapısını geliştirmeyi ve yeniden tasarlamayı amaçlamaktadır. Refactoring’in basit örnekleri, yanlış ad değişkenlerini veya yöntemlerini sabitlemeyi ve tekrarlanan kodları tek bir yönteme ( method ) veya işleve ( fonksiyona ) indirgemeyi içerir.

Koddaki bu kendi kendine inceleme süreci ayrıca akran değerlendirmesi ( peer review ) de içermelidir. Pek çok şirket, çift programlama ( pair programming ) tekniklerinde büyük başarılar elde eder, bu teknikte iki kişi gerçek kod geliştirme sırasında bir araya gelirler, birisi kod yazan geliştirici ve diğeri ise kodun yazılmasını izleyen bir gözlemci olarak çalışır. Bu uygulama, herhangi bir kod çalışmasını tamamlamak için gereken insan saatlerini artırırken, ikili programlardan üretilen kodun, solo programcıların ürettiği kodlardan yaklaşık % 15 daha az kusur içereceğini göstermektedir.

Herhangi bir kodun gözden geçirilmesi yoluyla üretim hatalarını azaltmanın en iyi yolu, kuruluşun oluşturduğu süreçlerin sık sık uygulandığından emin olmaktır – tekrarlama, üretim ortamına ulaşmadan önce olası problemleri ve mevcut kusurları sürekli olarak yakalayan alışılmış süreçler yaratacaktır.

Agresif Regresyon Testini Gerçekleştirmek
Regresyon testi, bileşenlerin değişikliklere uğramasından sonra, bu yazılım bileşenlerinin işlevselliğini onaylayan veya reddeden bir yazılım testi türüdür. Bir yazılım bileşeninde bir değişikliğin yapılması ve bir kusurun bulunması durumunda, konuyu doğrulamak ve çözümlemeye çalışmak için regresyon testi gereklidir. Regresyon testi, her değişiklik sonunda, her günün sonunda, haftada bir, iki haftada bir, vb. şeklinde düzenli bir program veya temele göre gerçekleştirilmelidir. Regresyon testleri, daha önce keşfedilen bir sorun düzeltildiğinde de tipik olarak gerçekleştirilmelidir. Genel olarak, ne kadar daha sık regresyon testi meydana gelirse, daha fazla sorun keşfedilebilir ve daha fazla sorun çözülebilir ve uygulamada daha da stabil olmaya başladıkça, üretim hataları da önemli ölçüde azalacaktır.

Hata Analizi Yapmak
Her zaman, yazılım geliştirme yaşam döngüsünün bir noktasında bazı kusurlar görünecektir, bu yüzden ekibin sağlanan bu avantajlardan tam anlamıyla yararlanması önemlidir. Özellikle, bir kusur yazılımın etkilenen bileşenleri üzerinde derin analiz yapma ve etkilenen tüm alanlara iyileştirmeler yapma fırsatı sunar. Kuruluşun analiz yapmayı nasıl seçeceği, ekibe ve uygulamaya özel olacaktır, ancak belirli bir kusurun kök nedenini ele alırken akılda tutulması gereken birkaç temel ilke vardır:

Kaliteyi Artırmayı Amaçlamak: Her şeyden önce, ortaya konan tüm ipuçlar ve uygulamalar, yazılımın kalitesini gelecekteki iterasyonlar ile üretim sürümleri boyunca iyileştirmeyi amaçlamaktadır. Böylelikle, hata analizi hem kusurları hem de çatlaklardan kaymakta olanlar için bunları mümkün olduğunca erken tespit etmeyi amaçlamalıdır.

Uzman Ekip Üyelerine güvenmek: Kalite Güvence bölümleri, özellikle büyük projeler için faydalıdır ve genellikle gereklidir, ancak geliştirme ekibinin kusuruna neden olan kodları yazma veya bileşenleri üretme ile ilgili üyeleri ihmal etmemek gerekir. Bu üyeleri tespit etmenin amacı, herhangi bir yargılamaktan ya da onları utandırmaktan ziyade, problemi analiz etmek ve en zarif çözümler ortaya çıkarmak için bu kişileri güçlendirmektir.

Sistematik Kusurları Önceliklendirmek: Tipik gelişim yaşam döngüsü boyunca, ekibin en iyi çabalarına rağmen, bir avuç kusur olma eğilimi olacaktır, bu – tekrar tekrar ortaya çıkan sorunlar olan regresif kusurlardır. Bu tür sistematik kusurlar, analiz süreci sırasında önceliklendirilmeli ve büyük ölçüde, genel hata oranları üzerinde en büyük etkiye sahip olacağı için, üzerinde yoğunlaşılmalıdır.

Sürekli Değişikliklerin İncelenmesi
Sürekli entegrasyon, sürekli dağıtım, sürekli dağıtım ve benzeri kavramlar sadece yaygın olan moda sözcükleri değildir. Bunlar, yinelemeli sürümler ve dağıtımlardan baş ağrısının çoğunu alarak yazılım kalitesini önemli ölçüde artırabilecek son derece etkili uygulamalardır.

Sürekli entegrasyon, genel temele göre yazılım ürününü düzenli olarak ve otomatik olarak oluşturma ve test etme uygulamasıdır. Test sıklığı iş gereksinimlerine bağlı olacaktır, ancak şu anda mevcut olan birçok güçlü araçla, bu işlem her yükleme ( build ) için veya hatta paylaşılan depoya ( repository ) yapılan her bir taahhütte ( commit ) de meydana gelebilir.

Sürekli teslimat ( delivery ) bir uygulamadan daha çok bir kavramdır: kod tabanının ( base ) her zaman kullanıma hazır olması gerektiği fikridir. Bunun anlamı tartışmalı olmakla birlikte, çoğu uygulamadaki temel fikir, uygulamanın bir aşama veya üretim ortamına tek tıklamayla (single – click) ( veya planlanmış ve otomatik olarak ) tam olarak serbest bırakılması için hazır olması gerektiğidir.

Son olarak, sürekli uygulama ( deploy ) bu sürekli uygulamaların ( practices ) doruk noktasıdır ve dağıtımların serbest bırakmalarının ya da yamaların gerçek dağıtımının gerçekleştiği ve daha geniş kullanım için mevcut olduğu ( aşamalandırma, üretim, vb.) durumudur. Bazı kurumlar, bu süreçleri hızlandırmayı tercih ederler. Böylece, yeni, güncellenmiş yapıları günlük olarak üretim ortamına uygulamaktadırlar.

Yazılım hatalarının önlenmesi zor bir iş olabilir. Hatalar, hatalı test veya dağınık koddan iletişim eksikliğine veya yetersiz teknik özellik belgelerine kadar her türlü problemden kaynaklanabilir. Yazılım hatalarını önlemek için kullanılan birkaç basit tekniğin nasıl uygulanacağını ve bir ekibin yazılım hatalarını kendi projelerinde önlemesine bu tekniklerin nasıl yardımcı olabileceğini inceleyelim.

Dağınık kod ( Messy kod )
Dağınık kod (yaygın olarak “smelly code” veya “code smell” olarak bilinir), kodun alt kısmında daha büyük bir konuya işaret eden bir kod tabanı ile küçük, yüzey seviyesi problemini tanımlamak için kullanılan bir terimdir. Çoğu durumda, geliştiriciler ve diğer ekip üyeleri, bir problem yaşanmadan önce çok daha büyük sorunları önleyerek, deneyim ve uygulama ile bir kokuyu alabiliyorlar. Ancak, uygulamayı son tarihine yetiştirmek için geliştirme sürecinin hızlandırılması gerekmektedir, bu da kasıtsız hataların ortaya çıkmasına neden olmakta. Bu da kod dağınık kodun büyümesine ve onun daha büyük özellikleri etkilemesine neden olur.

Önleme ( Prevention )
Test odaklı geliştirme ( Test Driven Development – TDD ) , code smell’in neden olduğu hataları önlemek için başka inanılmaz bir tekniktir. Test odaklı geliştirme, kod tabanını daha temiz ve ayrık kaygılar haline getirmeye teşvik etmektedir. Aynı zamanda kodu sık sık gözden geçirmeyi ve yeniden gözden geçirmeyi destekliyor. Kombine edildiğinde, bu teknikler code smell’den kaynaklanan hataların sıklığını önemli ölçüde azaltır.

Test odaklı gelişim, geliştirmenin normalde “kodlama, test etme, hata ayıklama, tekrarlama” ( “code, test, debug, repeat” ) sırasından geriye doğru çalıştığı yaygın bir uygulamadır. Bunun yerine, test odaklı geliştirme (ya da TDD), başlangıçta yazılımın işlemesi gereken tam işlevselliği tanımlayan ve test eden başarısız testler oluşturmaya odaklanır. Testler yapıldıktan sonra, sadece daha önce başarısız olan testleri başarılı bir şekilde geçiren kod yazılır. Kod bir testi geçemezse, tüm sınamalar geçene kadar değiştirilir, bu kodun gerekeni yapması gerektiğini gösteren güçlü bir göstergedir.

Test odaklı geliştirme, yazılımdaki uygulama hatalarını önlemeye veya azaltmaya çalışırken son derece faydalı bir tekniktir. Regresyon hataları durumunda, TDD, bir ekibin geliştirme yaşam döngüsü boyunca sabit bir kod tabanını koruyabilmesi için birincil araçtır. İlk önce uygun testler yaparak ve daha sonra bu testleri geçen kodu yazarak, regresif hataların ortaya çıkma ihtimali dramatik bir şekilde düşer.

Test odaklı geliştirme döngüsü, yazılım geliştirme yaşam döngüsü boyunca tekrar tekrar kullanılan beş basit adımdan oluşur. Bu adımların (ve genel olarak test odaklı geliştirmenin bütünü) amacı, tüm işlevsel iş gereksinimlerini karşılarken, kodun basit ve verimli olmasını sağlamaktır. Bu adımlar şu şekildedir:

Test Yazmak ( Write a Test )
Testlerin Başarısız Olduğunu Doğrulamak ( Confirm the Test Fails )
Testi Geçmek için Kod Yazmak ( Write Code to Pass Test )
Testi Geçtiğini Onaylamak ( Confirm the Test Passes )
Elden Geçirme ( Refactor )

Test odaklı geliştirmenin avantajları:

Hata ayıklamaya olan bağımlılığı azaltır
Kullanıcı deneyimini dikkate alır
Genel geliştirme süresini düşürebilir

Test odaklı geliştirmenin dezavantajları:

Büyük Resim tasarımını zorlaştırır
Tüm durumlarda uygulanması zordur
Ek zaman yatırımını gerektirir

Bu bölümde, kodlama aşamasında yapılan ve kaçınılmaz olan yazılım hataları ve onların giderilmesi için uygulanabilen bazı yöntemler incelendi. Ancak bu yöntemler, büyük bir resmin küçücük bir parçasıdır. Bu yöntemler dışında, yazılım kusurlarının giderilmesini ve yazılı kalitesini artırmayı amaçlayan, yazılım geliştirme sürecinin önemli aşamalarının test aşaması da mevcuttur. Bu test aşaması konusu ve mevcut olan test stratejileri hakkında bilgiler ise, “Yazılım Test Stratejileri” bölümünde ( Bölüm 6 ) detaylı olarak anlatılmıştır. Alfa, Beta, Maymun, Stres, Kullanılabilirlik, Kıyaslama ve Revizyon Test gibi test çeşitleri vb. anlatılmıştır.

Yazılım Geliştirme Hayat Döngüsü 3.bölüm

Bir proje geliştirilirken öncelikle bunu kabul etmemiz lazım: yazılımı tek başına yazmak artık mümkün değil, bu yüzden ortak çalışmalıyız. Bunun için ise ekip içerisinde proje geliştirme aşamasındaki uyulması gereken kuralların belirlenmesi gerekmektedir.

Toplantılar nasıl gerçekleşecek: sabah mı? akşam mı? Bazı projelerdeki toplantılar ayakta yapılmaktadır; çünkü insanlar otururken konuşmaya meyillidir. Codeview toplantıları yapılacak mı? Bu Codeview toplantıları güzel ama maliyetlidir. Bu tarz etkinliklerin yazılım geliştirme sürecinde ne şekilde yapılması gerektiği konusunda bir takım anlaşmalar olmalıdır. Başka bir ifadeyle, sistem gereksinimlerini yerine getirmek amacıyla geliştirme aşamasında çözümler üretme sitemini belirlenmesi önemlidir. Bu sistem, bir yazılımın nasıl geliştirileceği, nasıl destekleneceği, nasıl değiştirilmesi gerektiği ya da nasıl iyileştirileceği konularında detaylı planlamalar içermektedir. Yani, yaşam döngüsü bir yazılımın ve bu yazılımın geliştirme sürecinin tamamının kalitesini artırmak amacıyla bir yöntembilim ( methodology ) belirler.

Yaşam döngüsü modeli, sistemin yaşam boyu gerekli işlevselliğini karşılayabilmesini sağlamaya yardımcı olan bir çerçeve olarak tanımlanmaktadır. Bir örnek yaşam döngüsü modeli aşağıdaki tabloda verilmiştir.

Kavrama

Geliştirme

Üretim

Kullanım

Destek

Kullanımdan Kaldırmak

Tabloda verilen aşamalar birbirinden ayrı olarak belirtilse de pratikte birbirine bağlıdır ve birbiriyle örtüşmektedir. Bu aşamalar zaman akışına göre sırasıyla art arda gerçekleştirilmemektedir. Şekil 1, bu aşamaların pratikte olan örtüşmesini göstermektedir.

Şekil 1 Yazılım model döngüsü ve olası ilerlemeler

ekilde görüldüğü gibi aşamalar arası geri dönme ve aşamaların tekrarlanması mümkündür. Yaşam döngüsü yönetiminin önemli bir yönü, her aşamanın, bu aşamadan ilerlemeye izin verilmeden önce yerine getirilmesi gereken çıkış kriterleri gerektirmesidir. Aşamalar arası karmaşık bir iletişimi olduğu görülmektedir, dolayısıyla, aşamaların kullanımı, daha fazla ilerlemeye izin vermeden önce tatmin edici karar kriterlerinin yerine getirilmesi beklenir.

Şekil 2’de genel olarak karşılaşılan yazılım döngü aşamaları amaçlarıyla birlikte gösterilmiştir.

Yaşam modeli ile ilgili 4 genel ilke şu şekilde sıralanabilir:

Hedeflenen yazılım ürününü geliştirmek için iyi tanımlanmış, yapılandırılmış aşamaların dizisidir Yazılım Geliştirme Hayat Döngüsü (Software Development Life Cycle). Metin içerisinde kısaltımı olan SDLC ifadesi kullanılacaktır. Etkili bir yazılım ürünü geliştirmek ve tasarlamak için bir takım aşamaları sunmaktadır SDLC. SDLC aşağıdaki adımlardan oluşmaktadır:

İletişim; Gereksinimlerin toplanması; Yapılabilirlik çalışması; Sistem analizi; Yazılım tasarımı; Kodlama; Test etme; Entegrasyon; Gerçekleme; Kullanım ve Bakım; Kullanımdan kaldırma

İletişim: Kullanıcının istenen bir yazılım ürünü için isteği başlattığı ilk adımdır. Servis sağlayıcısıyla iletişim kurar ve şartları müzakere etmeye çalışır. Talebini yazılı olarak hizmet veren kuruluşa sunar.

Gereksinimlerin Toplanması: Bu adımda, yazılım geliştirme ekibinin projeyi yürütmek için gerekli çalışmalar sürdürülmektedir. Ekip, sorunlu alandan çeşitli paydaşlarla tartışmalar yürütür ve gerekliliklerine göre olabildiğince fazla bilgi vermeye çalışılır. Bu gereklilikler tasarlanır ve kullanıcı gereksinimleri, sistem gereksinimleri ve fonksiyonel gereksinimlere ayrılır. Bu gereksinimler, aşağıda verilen bir dizi pratik bilgiler kullanılarak toplanır;

Mevcut veya eski sistem ve yazılımı incelemek,
Kullanıcılar ve geliştiriciler ile konuşmalar / toplantılar yapmak,
Veritabanına başvurarak veya
Anketlerden cevaplar toplamak.
Yapılabilirlik Çalışması: Gereksinimlerin toplanmasından sonra, ekibin elinde yazılım süreci ile ilgili kaba bir plan olur. Bu aşamada, ekip, kullanıcının tüm gereksinimlerini yerine getirmek için bir yazılımın yapılıp yapılamayacağını, yazılımın daha fazla yararlı olma ihtimalinin bulunup bulunmadığını ve bu yazılımın ileride hiç kullanılmayacak hale gelme ihtimalinin olup olmadığını analiz eder. Projenin finansal olarak, organizasyonun üstlenilmesi için pratik ve teknolojik açıdan uygun olduğu görülmüştür. Geliştiricilerin bir yazılım projesinin fizibilitesini tamamlamalarına yardımcı olan birçok algoritma vardır.
Sistem Analizi: Bu aşamada geliştiriciler planlarının bir yol haritasını kararlaştırır ve proje için en uygun yazılım modelini ortaya çıkarmaya çalışırlar. Sistem analizi, yazılım ürün kısıtlamalarını, sistemle ilgili problemleri veya önceden mevcut sistemlerde yapılacak değişiklikleri anlamak, projenin organizasyon ve personel üzerindeki etkisini belirlemek vb. konuları içerir. Proje ekibi projenin büyüklüğünü / kapsamını analiz eder ve ona göre kaynak kullanımı ile iş programını hazırlar.
Yazılım Tasarımı: Bir sonraki adım, ihtiyaçların ve analizlerin tüm bilgisini masaya koymak ve yazılım ürününü tasarlamaktır. Kullanıcılardan gelen bilgiler ve ihtiyaç toplama aşamasında toplanan bilgiler bu adımın girdileridir. Bu adımın çıktısı iki tasarım türü şeklinde olur; mantıksal tasarım ve fiziksel tasarım. Mühendisler meta veri ve veri sözlükleri, mantıksal diyagramlar, veri akışı diyagramları ve bazı durumlarda sözde kodlar üretirler.
Kodlama: Bu adım ayrıca programlama aşaması olarak da bilinir. Yazılım tasarımının çalıştırılması/uygulanması ( implementation ), uygun programlama dilini seçme ve onunla kod yazarak hatasız çalıştırılabilir programlar geliştirmekle başlar.
Test Etme: Bir tahmin, tüm yazılım geliştirme sürecinin% 50’sinin test edilmesi gerektiğini söylüyor. Hatalar, yazılımı kritik seviyeden ortadan kaldırılmasına kadar bozabilir. Yazılım testleri, geliştiriciler tarafından kodlama yapılırken yapılır ve kapsamlı testler, uzmanlar tarafından modül testi, program testi, ürünün test edilmesi ve ürünün kullanıcı tarafından test edilmesi gibi çeşitli seviyelerde test edilir. Hataların erken keşfedilmesi ve onların çözülmesi güvenilir yazılımın anahtarıdır.
Entegrasyon: Yazılımın kütüphaneler, veritabanları ve diğer program ya da programlarla entegre edilmesi gerekebilir. SDLC’nin bu aşaması, yazılımın dış dünya varlıklarıyla entegre edilmesini de içerir.
Gerçekleme: Bu, yazılımı kullanıcı makinelerine yüklemek anlamına gelir. Zaman zaman, yazılımın kullanıcı tarafına kurulum sonrasında gerekli yapılandırmalara ihtiyacı olur. Yazılım taşınabilirlik ve uyumluluk açısından test edilmiş ve uygulama sırasında entegrasyonla ilgili sorunlar çözülmüş olur.
Kullanım ve Bakım: Bu aşama yazılım işleminin daha fazla verimlilik ve daha az hata açısından doğrulandığını göstermektedir. Gerekirse, kullanıcılar yazılımın nasıl çalıştırılacağı ve yazılımın nasıl çalışır durumda tutulacağı konusunda eğitilir ya da bunlarla ilgili dokümantasyonlarla desteklenir. Zaman zaman kullanıcı son ortamı veya teknolojisinde meydana gelen değişikliklere göre yazılımın kodu güncellenerek bakımı yapılır. Bu aşamada gizli hatalardan ve gerçek dünyadaki tanımlanamayan sorunlardan dolayı zorluklarla karşılaşılabilir.
Kullanımdan kaldırma: Zaman geçtikçe, yazılım performans cephesinde düşebilir. Yazılımda kullanılan teknolojiler tamamen ortadan kaldırılabilir, modası geçebilir veya yazılım yoğun bir yükseltilmeye ihtiyaç duyabilir. Bu nedenle, sistemin büyük bir bölümünü ortadan kaldırmak için acil bir ihtiyaç ortaya çıkmaktadır. Bu aşamada, verileri arşivleme ve ilgili yazılım bileşenleri ile sistemi kapatma, harekat etkinliğini planlama ve sistemi uygun zamanda sonlandırma planları yapılır.

3.1. Yazılım Geliştirme Modelleri

Yazılım geliştirme paradigması, geliştiricinin yazılımı geliştirmek için bir strateji seçmesine yardımcı olur. Bir yazılım geliştirme paradigması, açıkça ifade edilen ve yazılım geliştirme yaşam döngüsünü tanımlayan kendi araçları, yöntemleri ve prosedürlerin kümesini içerir. Birkaç yazılım geliştirme paradigması veya işlem modeli aşağıdaki gibi tanımlanmıştır.

3.1.1. Çağlayan (Waterfall) Modeli

Çağlayan modeli, yazılım geliştirme paradigmasının en basit modelidir. Şelale Modeli, klasik model, klasik çevrim, geleneksel model olarak da bilinir. Günümüzde mevcut olan modern modellere ilham olmuştur. Yaygın olarak kullanılan bir modeldir ve diğer geliştirme sistemlerinde örnek olarak alınan bir modeldir. Yazılım geliştirme sürecinin tüm aşamalarının birbiri ardına doğrusal bir şekilde işleyeceğini söylüyor. Başka bir deyişle, ikinci aşama ancak ilk aşama bittiğinde başlayacak ve bu şekilde devam edecektir.

Geliştiriciler, geçmişte benzer yazılımları tasarlayıp geliştirdiler ise ve tüm etki alanlarının farkında iseler, ya da gereksinimler analizini çok iyi yapılmışlar ise, geliştirecekleri yazılım için bu model en uygundur.

Bu model, her şeyin bir önceki aşamada planlandığı gibi gerçekleştirildiğini varsayar ve bir sonraki aşamada ortaya çıkabilecek geçmiş sorunları düşünmeye gerek olmadığını kabul eder. Önceki adımda bazı sorunlar varsa, bu model sorunsuz çalışmaz. Modelin ardışık olma doğası, bize geri dönmemize ve eylemlerimizi geri almamıza ya da tekrar etmemize izin vermez. Çünkü sorunları çözmek amacıyla geriye dönmek ek zaman ve ekstra maliyet ister. Şekil 3’te Çağlayan ( Waterfall ) modeli gösterilmektedir.

Çağlayan modeli yaygın bir şekilde kullanılan ve kullanılmaya devam eden bir model olmasına rağmen bazı eksileri mevcuttur. Bu eksiler aşağıda madde madde olarak verilmiştir:

Çağlayan modelinin kullanıldığı bir projede, onun uygulama aşamalarında, bir önceki aşamalara dönmek mümkündür, ancak bu geri dönme ve düzeltmeleri yapma işlemleri ekstra bir maliyet, zaman ister. Bunun yanında projenin zamanında tamamlanmasına engel olarak gecikmelere yol açacaktır.
Bulunan aşamadan bir önceki aşamaya hataları düzeltmek için yapılan geri dönüşler proje ekibi arasında kopukluk oluşturabilir.
Temelinde bu modeli kullanan bir proje çok uzun bir zaman sonra müşteriye teslim edilmektedir. Bu yüzden müşteri geri bildirimi çok geç yapılabilir. Bu da müşteri memnuniyetsizliğine yol açabilir.
Müşteri projeyi kullandıktan sonra bazı isteklerde bulunabilir, bazı gereksinimlere olan ihtiyaçlarını bildirebilir. Bu yeni istek ve gereksinimleri projeye eklenmek istendiği zaman ortaya çeşitli sorunlar çıkmaktadır.

Avantajları

Basit ve anlaşılması ile kullanımı kolay
Modelin sertliği nedeniyle yönetilmesi kolaydır. Her aşamanın belirli çıktıları ve onların incelenme süreci vardır.
Aşamalar işlenir ve birer birer tamamlanır.
Gereksinimlerin çok iyi anlaşılan küçük projeler için iyi çalışır.
Açıkça tanımlanmış aşamalar.
Görevlerin düzenlenmesi kolaydır.
Süreç ve sonuçları iyi belgelenir.

Dezavantajları

Yaşam döngüsünün sonuna kadar çalışan bir yazılım üretilmez.
Yüksek miktarda risk ve belirsizlik var.
Karmaşık ve nesnel yönelimli projeler için iyi bir model değildir.
Uzun ve devam eden projeler için zayıf bir modeldir.
İhtiyaçların orta dereceden yüksek bir değişim riskine sahip olduğu projeler için uygun değildir. Dolayısıyla bu süreç modelinde risk ve belirsizlik yüksektir.
Aşamalı ilerlemeyi ölçmek zordur.
Değişen gereksinimler karşılanamaz.
Yaşam döngüsü sürecinde, proje kapsamını değiştirmek projeyi sonlandırabilir.
Entegrasyon, bir “büyük patlama” olarak yapılır. Herhangi bir teknolojik veya iş darboğazı veya zorlukları tespit edilemeyen bir zamanda, en sonunda.

3.1.2. Tekrarlayan (Iterative) Model

Bu model, yazılım geliştirme sürecini iterasyonlarda yönlendirir. SDLC sürecinin her döngüsünden sonra her adımı tekrarlayan döngüsel bir şekilde geliştirme sürecini yansıtan bir modeldir. Bu modelin gösterimi Şekil 4’te verilmiştir.

Yazılım ilk önce çok küçük ölçekte geliştirilir ve göz önüne alınan tüm adımlar takip edilir. Ardından, sonraki her yinelemede, daha fazla özellik ve modül yazılımı tasarlanır, kodlanır, test edilmiş olur ve yazılıma eklenir. Her döngü kendi içinde eksiksiz olan ve bir öncekinden daha fazla özellik ve kapasiteye sahip bir yazılım üretir.

Her iterasyondan sonra yönetim ekibi risk yönetimi konusunda çalışmalar yapabilir ve bir sonraki iterasyona hazırlanabilir. Bir döngü tüm yazılım sürecinin küçük bir bölümünü içeriyor, dolayısıyla, geliştirme sürecini yönetmek daha kolaydır, ancak daha fazla kaynak tüketir.

Avantajları

Bazı çalışma işlevleri yaşam döngüsünde hızlı ve erken geliştirilebilir.
Sonuçlar erken ve periyodik olarak elde edilir.
Paralel gelişme planlanabilir.
İlerleme ölçülebilir.
Kapsamı / gereksinimleri değiştirmek için daha az maliyetli.
Daha küçük yineleme sırasında test ve hata ayıklama kolaydır.
Riskler iterasyon sırasında tanımlanır ve çözülür.
Riski yönetmek daha kolay -> İlk önce yüksek riskli bölüm yapılır.
Her artışla, operasyonel ürün teslim edilir.
Bir tekrarda ( iteration ) belirlenen sorunlar, zorluklar ve riskler bir sonraki tekrara uygulanabilir.
Risk analizi daha iyidir.

Dezavantajları

Daha fazla kaynak gerekebilir.
Değişim maliyeti daha az olsa da, değişen ihtiyaçlar için çok uygun değildir.
Yönetime daha fazla dikkat gereklidir.
Sistem mimarisi veya tasarım sorunları ortaya çıkabilir çünkü tüm gereksinimler yaşam döngüsünün başlangıcında toplanmaz.
Tekrarların tanımlanması, tüm sistemin tanımını gerektirebilir.
Daha küçük projeler için uygun değildir.
Yönetim karmaşıklığı daha fazladır.
Riskli olan proje sonu bilinemeyebilir.
Risk analizi için çok yetenekli kaynaklar gereklidir.
Projelerin ilerlemesi, risk analizi aşamasına büyük ölçüde bağlıdır.

3.1.3 Döngüsel (Spiral) Model

Spiral modeli – Sarmal model olarak da bilinir. Spiral modeli, hem tekrarlamalı model hem de diğer bir yazılım geliştirme modelinin kombinasyonudur. Bir yazılım geliştirme süreç modelini seçip döngüsel süreçle ( Tekrarlamalı model ile ) birleştirdiğinizde elde edilir.

Şekil 5’te gösterilen bu model, çoğu diğer model tarafından sıklıkla fark edilmeyen riski ele alır. Model, bir iterasyonun başlangıcında yazılımın amaçlarını ve kısıtlamalarını belirleyerek başlar. Bir sonraki aşama yazılımın prototipidir. Bu risk analizini içerir. Daha sonra yazılımı oluşturmak için bir standart yazılım geliştirme süreci modeli kullanılır. Son olan dördüncü aşamada, geliştirilen ürün müşteri kullanımına sunulur ve geri bildirimlerle müşteri ( ve / veya kullanıcı) değerlendirmelerini inceler. Bir sonraki iterasyonun planı dördüncü aşamada hazırlanır. Böylece, bu model dört aşamadan oluşur. Bu aşamalar planlama, risk çözümlemesi, mühendislik ve değerlendirme aşamalarıdır.
Avantajları

Değişen ihtiyaçlar karşılanabilir.
Prototiplerin yaygın kullanımını sağlar.
Gereksinimler daha doğru bir şekilde yakalanabilir.
Kullanıcılar sistemi erkenden görüyor.
Geliştirme, daha küçük parçalara bölünebilir ve risk yönetimine daha da yardımcı olarak, riskli parçalar önceden tespit edilebilir.

Dezavantajları

Yönetim daha karmaşıktır.
Projenin sonu erken bilinemez.
Küçük veya düşük riskli projeler için uygun değildir ve küçük projeler için pahalı olabilir.
İşlemler karmaşıktır
Spiral süresiz devam edebilir.
Çok sayıda olan ara aşamaları çok fazla dokümantasyon gerektirir.

3.1.4. Prototipleme Modeli

Yazılım projeleri müşterinin istekleri, beklentileri ve gereksinimlerine göre şekil alır. Bazı müşteriler ise yazılım projesinden ne beklediğini, ne istediğini, yazılımın hangi girdiler alacağını ve / ya da girdilere göre nasıl bir sonuç ve rapor vereceğini bilemez. Dolayısıyla, projeye başlayabilmek için geliştirici de gereksinim analizini yapamaz.

Bu tarz projeler için müşteri ile geliştiricinin birlikte hareket etmesi gerekir. Birlikte daha hızlı bir şekilde proje gereksinimleri belirlenir. Onların ışığında da projeye başlanılır. Daha sonra, elde edilen gereksinimlere göre projenin bir prototipi geliştirilir. Bu geliştirilen prototip müşterinin değerlendirmesi için teslim edilir. Müşteriden gelen geri bildirimlere göre proje yeniden şekillendirilir. Bu adımlar müşterinin ne istediği tam olarak anlaşılana kadar devamlı bir şekilde gerçekleştirilir. Müşteri istekleri belirlendikten sonra proje geliştirilmeye başlanır.

3.1.5. V Modeli

Çağlayan modelinin en büyük dezavantajı, ancak bir önceki aşamayı geçtikten sonra bir sonraki aşamaya geçiyoruz ve daha sonraki aşamalarda bir şeylerin yanlış bulunması halinde geriye gitme şansımız olmuyor. V Modeli, temelini Çağlayan ( Waterfall ) modelinden alarak oluşturulmuştur. Ancak, Çağlayan modelinden farklı olarak test işlemlerini içerir. V Model, her aşamada yazılımın tersine test edilmesini sağlar ( each stage in inverse manner ). Yani, geliştirme sürecinin her aşamasının tamamlanmasından sonra, o ilgili aşamanın testi yapılır. Bu model Şekil 6’da gösterilmiştir.

Her aşamada, ürünü o aşamaya göre doğrulamak ve onaylamak için test planları ve test senaryoları oluşturulur. Örneğin, gereksinimleri belirleme/toplama aşamasında, test ekibi tüm test örneklerini gereksinimlere uygun olarak hazırlar. Daha sonra, ürün geliştirildiği ve teste hazır olduğu zaman, bu aşamadaki test senaryoları, yazılımın bu aşamadaki gereksinimlere karşı geçerliliğini doğrular.

Bu, hem doğrulama hem de onaylama işlemini paralel yapar. Aynı zamanda bu model doğrulama ve onaylama modeli olarak da bilinir. Gereksinimleri net ve belirsizlikleri az olan projelerde kullanılarak başarılı sonuçlar elde eden bir modeldir.
Avantajları

Bu çok disiplinli bir modeldir ve
Her seferinde birer aşama tamamlanır.
Gereksinimlerin çok iyi anlaşıldığı küçük projeler için iyi çalışır.
Basittir, anlaşılması ve kullanımı kolaydır.
Modelin sertliği nedeniyle yönetilmesi kolaydır. Her aşamanın belirli çıktıları ve bir inceleme süreci vardır.

Dezavantajları

Yüksek risk ve belirsizlik var.
Karmaşık ve nesnel yönelimli projeler için iyi bir model değildir.
Uzun ve devam eden projeler için zayıf bir modeldir.
İhtiyaçların orta dereceden yüksek bir değişim riskine sahip olduğu projeler için uygun değildir.
Bir uygulama test aşamasındayken, geri dönüp işlevselliği değiştirmek zordur.
Yaşam döngüsünün sonuna kadar çalışan bir yazılım üretilmez.

3.1.6. Evrimsel (Big Bang) Model

Bu model kendi formunda en basit modeldir. Çok az planlama, çok sayıda programlama ve çok sayıda sermaye gerektirir. Bu model, evrenin büyük patlama etrafında kavramsallaştırılmıştır. Bilim adamları dedikleri gibi, büyük patlamadan sonra birçok galaksi, gezegen ve yıldız bir olay olarak gelişti. Aynı şekilde, birçok programlama ve sermayeyi bir araya getirseniz, en iyi yazılım ürününü elde edebilirsiniz. Evrimsel ( Big Bang ) Modeli Şekil 7’de gösterilmiştir.

Bu model için çok az miktarda planlama gereklidir. Herhangi bir süreci takip etmez, veya zaman zaman müşteri gereksinimler ve gelecekteki ihtiyaçlarından emin değildir. Böylece, giriş şartları keyfidir.

Evrimsel modelini temel alarak geliştirilen projeler ürünleri sürüm şeklinde üretirler. Proje ilk önce hızlı bir şekilde geliştirilir. Daha sonra, kullanıma sunulur. Kullanıcı ve / veya müşterilerin geri bildirimlerine göre projeye yeni gereksinimler eklenir. Dolayısıyla, ilk sürümün başarılı olması önemlidir. Çünkü bir sonraki sürümler, ilk sürüme bağlı olarak ortaya çıkmaktadır.

Örneğin, bir öğrenci bilgi sistemi projesini geliştirmek için bu model temel olarak alınacaksa, geliştirilen projeyi üniversitenin tamamında denemek yerine, ilk önce bir bölümde ya da fakültede denemek daha iyi olur. Böylece, Evrimsel model büyük yazılım projeleri için uygun değildir, ancak öğrenme ve denemeler için iyidir.

Avantajları

Bu çok basit bir modeldir.
Az ya da hiç planlama gerektirmez.
Yönetilmesi kolay.
Çok az kaynak gereklidir.
Geliştiricilere esneklik kazandırır.
Yeni gelenler veya öğrenciler için iyi bir öğrenme yardımcısıdır.

Dezavantajları5

Çok yüksek risk ve belirsizlik var.
Karmaşık ve nesnel yönelimli projeler için iyi bir model değildir.
Uzun ve devam eden projeler için zayıf bir modeldir.
Gereksinimlerin yanlış anlaşılması durumunda çok pahalıya dönüşebilir.

3.1.7. Artımlı (Incremental) Model

Bu geliştirme modelinin gereksinimlerinin hepsinin belli olduğu projelerde kullanılması uygundur. İlk olarak en temel gereksinimlerin olduğu ana sürüm ortaya çıkartılır. Bu ana sürüm sistemin temel yapısını oluşturur, yalnız bazı gereksinimleri yerine getirebilme durumunda değildir. Daha sonra, oluşturulan ana sürümler üzerine eklemeler yapılarak yeni sürümler oluşturulur. Yeni sürümler ise, diğer gereksinimleri karşılayabilme durumunda olur. Artımlı model ile evrimsel model birbirine çok benzer olarak düşünülse de oldukça farklıdır. Çünkü artımlı modele göre geliştirilen projelerin sürümlerinde hep bir eksiklik mevcuttur. Dolayısıyla, kullanılabilir ürünler değildir. Bu modelin avantajı – bir ürünü az sayıda yazılımcı ile geliştirmeyi mümkün kılmasıdır.

3.2. Agile (Çevik) Yazılım Nedir?

Yazılım geliştirmede ortaya çıkan çeşitli ( projeyi zamanında bitirememe gibi ) sorunları önlemek için geleneksel yazılım geliştirme süreçleri yetersiz kalmaktadır. Buna çözüm olarak, yazılım ürününü etkileyebilecek tüm değişikliklere karşı esnekliği sağlayan Agile süreci benimsenmektedir.

Çevik model, her projenin farklı bir şekilde ele alınması gerektiğine ve mevcut yöntemlerin proje gereksinimlerine göre en uygun şekilde uyarlanması gerektiğine inanmaktadır. Agile’de, sürümün belirli özelliklerini sunmak için görevler zaman kutularına (küçük zaman dilimlerine) bölünür.

Yinelemeli yaklaşım alınır ve her bir yinelemeden sonra çalışmakta olan bir yazılım oluşturulmaktadır. Çevik yazılım geliştirme yöntemindeki modeller, ürünü küçük küçük yapılara bölünmesiyle tasarlanır. Bu işlemler ise iterasyonlar ile gerçekleştirilir. Her yineleme genel olarak yaklaşık 1 ile 3 hafta sürer. Her yineleme, aşağıdaki gibi çeşitli alanlarda aynı anda çalışmakta olan ekipleri içerir:

Gereksinim analizi birimi, Planlama birimi, Tasarım birimi, Kodlama birimi, Birim test birimi, Kabul test birimi vb. Böylece, her aşamadaki uygulama özellik açısından artırılabilir. Dolayısıyla, son uygulama, müşterinin istediği tüm özellikleri içerir.

En meşhur Çevik ( Agile ) yöntemleri bunlardır: Rasyonel Birleştirilmiş Süreç ( Rational Unified Process ) (1994), Scrum (1995), Crystal Clear, Aşırı Programlama ( Extreme Programming ) (1996), Uyarlamalı Yazılım Geliştirme ( Adaptive Software Development ), Özellik Odaklı Geliştirme ( Feature Driven Development ) ve Dinamik Sistem Geliştirme Yöntemi ( Dynamic Systems Development Method – DSDM) (1995). Bunların hepsi birer Çevik Metodolojisi olarak bilinir.

Agile Manifesto prensipleri bu şekildedir:

Bireyler ve etkileşimler ( Individuals and interactions ) : Çevik modelinde, ortak konum ve ikili programlama gibi etkileşimli çalışmaların önemli olduğu gibi motivasyon ile öz-örgütlenme de önemlidir.
Çalışma yazılımı ( Working software ) : Demo çalışma yazılımı önemlidir. Diğer sözlerle bir prototiptir. Sadece belgelere bağlı olmaktan ziyade, gereksinimlerini anlamak için müşterilerle en iyi iletişim aracı olarak kabul edilir.
Müşteri İşbirliği (Customer collaboration) : Genellikle, gereksinimler proje başlangıcında tam olarak toplanamamaktadır. Bu nedenle, müşteri ile sürekli bir etkileşim halinde olmak, istenilen ürün gerekliliklerini yerine getirmek için çok önemlidir.
Değişime yanıt vermek ( Responding to change ) : Agile modeli, değişime ve sürekli gelişime açık bir modeldir. Ürün gereksinimlerine dinamik olarak uyum sağladığı için, gerekli değişikliklere hızlı tepkiler vemeye odaklanır.

Çevik yazılım süreci adaptif yazılım geliştirme yöntemlerine dayanmaktadır. Çağlayan modeli gibi geleneksel yazılım geliştirme süreçleri ise öngörücü bir yaklaşıma dayanmaktadır. Bu geleneksel modellerde genellikle detaylı planlama ile çalışılır ve birkaç ay içinde ya da ürün yaşam döngüsü boyunca teslim edilecek olan tam görevlerin ve özelliklerin tam bir tahmini yapılır. Bu tahmin yöntemleri tamamen en başta yapılan ihtiyaç analizine ve planlamaya bağlıdır. Eklenecek herhangi bir değişiklik ise, sıkı bir değişim kontrol yönetimi ve önceliklendirmeye göre gerçekleştirilir.

Çevik modelinde ayrıntılı bir planlama yoktur. Gelecekteki görevler hakkında hangi özelliklerin geliştirilmesi gerektiğine dair netlik bulunan adaptif bir yaklaşım kullanır. Özellik odaklı gelişim var ve ekip değişen ürün gereksinimlerine dinamik olarak uyum sağlıyor. Ürün çok sık olarak test edilir ( uygulama çalıştırma döngüleri yoluyla ) ve böylece, gelecekte herhangi bir büyük arıza riskini en aza indirir.

Müşteri Etkileşimi, bu Çevik (Agile) yöntembiliminin temelidir. Minimum dokümantasyon ile müşteriyle iletişime açık olmak, Çevik yazılım geliştirme modelinin tipik özellikleridir. Çevik yazılım geliştirme sürecinde, ekipler birbirleriyle yakın işbirliği içinde çalışırlar ve çoğunlukla aynı coğrafi bölgede bulunurlar.

Avantajları

Yazılım geliştirmeye çok gerçekçi bir yaklaşımdır.
Takım çalışmasını teşvik eder.
İşlevsellik hızlı bir şekilde geliştirilebilir ve gösterilebilir.
Kaynak gereksinimleri minimumdur.
Sabit veya değişen gereksinimlere uygundur.
Kısmi çalışma çözümleri erken sunar.
Sürekli değişen ortamlar için iyi bir modeldir.
Dokümantasyon kolayca kullanılır ve kurallar azdır.
Az ya da hiç planlama gerektirmez.

Dezavantajları

Karmaşık bağımlılıkları ele almak için uygun değildir.
Sürdürülebilirlik, süreklilik ve genişletilebilirlikte daha fazla risk vardır.
Genel bir plan, çevik bir lider ve çevik bir Proje Yönetimi uygulaması bir zorunluluktur.
Sıkı teslimat yönetimi, son teslim tarihlerini karşılamak için kapsamı, teslim edilecek işlevselliği ve ayarlamaları belirler.
Müşteri etkileşimlerine büyük ölçüde bağlıdır, bu nedenle müşteri net değilse, ekip yanlış yönde sürülebilir.
Az dokümantasyon oluşturulduğu için çok yüksek bir bireysel bağımlılık vardır.
Yazılımın yeni ekip üyelerine aktarılması, dokümantasyon eksikliği nedeniyle oldukça zor olabilir.

3.3. Proje Yönetimi

Yazılım geliştirme üzerine çalışan şirketlerde iş kalıbı aşağıdaki gibi ikiye ayrılmaktadır:

Yazılım GeliştirmeYazılım Proje Yönetimi

Proje, bir amaca ulaşmak için, bir takım işlevleri ( örneğin yazılım geliştirmek ve kullanıcıya teslim etmek ) sırasıyla gerçekleyen iyi tanımlanmış bir görevdir. Bir projenin belirli bir hedefi vardır ve başlangıç ile bitiş tarihleri bellidir; maddi kaynağa ve belirli malzemelere ihtiyaç duyar.

Bir Yazılım Projesi ise, istenen yazılım ürününü elde etmek için belirli bir süre içerisinde, yürütme yöntembilimlerine göre yürütülen ve yazılım geliştirmenin, gereksinim toplama aşamasından test etme ile bakım aşamasına kadar olan tüm prosedürlerin tamamıdır.

Proje Yönetimi neden gereklidir?

Bazı kaynaklarda yazılımın maddi olmayan bir ürün olduğu söylenir. Yazılım geliştirme, dünyadaki yeni akışların birisidir ve yazılım ürünleri oluşturma konusunda çok az deneyim vardır. Çoğu yazılım ürünü müşterinin gereksinimlerine uyacak şekilde tasarlanmıştır. Temel teknolojinin çok sık ve hızlı bir şekilde değişmesi ve ilerlemesi, bir ürünün deneyiminin diğerine uygulanamamasına yol açmaktadır. Bu tür tüm iş ve çevre kısıtlamaları yazılım geliştirmede risk oluşturmaktadır, dolayısıyla yazılım projelerini verimli bir şekilde yönetmek çok önemlidir.

Yazılım ürününün kaliteli bir şekilde sunulması, maliyeti müşterinin bütçesine göre tutulması ve projeyi planlanan zamana göre teslim edilmesi önemlidir. Bunlara etki eden hem iç hem de dış faktörler mevcuttur. Dolayısıyla, kullanıcı gereksinimlerini bütçe ve zaman kısıtlamaları ile birleştirmek için yazılım proje yönetimi çok önemlidir.

Yazılım Tasarımı ve Yazılması bölüm 4

Bölüm Hedefi

Bir önceki bölümde Yazılım Hayat Döngüsü anlatılmıştır. Onların çeşitli modelleri incelenmiştir. Bu bölümde ise, yazılım geliştirme sürecinin aşamaları ve daha detaylı bir şekilde anlatılmıştır. Bir yazılım geliştirilirken sorulması gereken sorular düşünülmüş, dikkat edilmesi gereken aşamalar belirtilmiş ve bu aşamalarda kullanılabilecek yardımcı araçlar anlatılmıştır.

Yazılım tasarımı, yazılım geliştirme sürecinin önemli aşamalarının birisidir. Öncellikle, bir yazılım projesinin geçmesi gereken aşamaları inceleyelim. Yazılım ürünü geliştirme sürecinde uygulanması gereken bu tasarım, kullanım gibi aşamaların bütününe yazılım geliştirme aşamaları veya yazılım geliştirme süreci denilmektedir. Aşağıdaki Şekil 1’de yazılım geliştirme aşaması gösterilmiştir.

Şekil 1 Yazılım geliştirme aşamaları

Yazılım geliştirme aşamasının ilk adımı olan analiz, proje gereksinimlerinin analizini yapılan aşamadır. Yazılım projelerinin birden çok gereksinimi mevcuttur. Gereksinimler müşterinin yazılım içerisinde olmasını istediği ve yazılımdan beklediği her şey demek. Müşterinin memnuniyetini kazanmak ve yazılım projelerinin başarılı olmasını sağlamak için mutlaka gereksinimlerin belirlenmesi ve iyi bir gereksinimler analizinin yapılması gerekmektedir. Ayrıca, ortaya kaliteli bir yazılımın çıkması için de bütün gereksinimlerin dikkate alınması büyük önem taşımaktadır. Başarısız olarak sonuçlanan yazılım projelerinin büyük bir kısmında ya gereksinim analizi yapılmamış ya da eksik bir şekilde yapılmıştır.

4.1. Gereksinim Türleri

Gereksinim analizinin daha iyi yapılması için ve sayesinde çözümlerin elde edilmesi için gereksinimler birçok yönden gruplara ayrılmaktadır. En çok kullanılan gereksinim türleri aşağıdaki gibi alt başlıklar şeklinde verilmiştir.

Açıklamaları görmek için başlıklara tıklayınız.

Müşteri – Kullanıcı Gereksinimleri

Kullanıcı – insan etmeni olarak da bilinen bu gereksinim türü, projenin tamamlandığı zaman kullanımıyla ilgili olan gereksinimleri içermektedir. Müşteri-Kullanıcı gereksinimi analizi yapılırken belirli soruların cevaplanması gerekir. Bu sorular aşağıda maddeler şeklinde verilmiştir:

Sistemi kim kullanacak?
Sistemi kullanacak olan kullanıcılar arasında olan farklılıklar nelerdir?
Sistemi kullanacak olan kullanıcıların becerileri aynı mı?
Sistemin nasıl kullanılacağı konusundaki anlatımlar nasıl bir şekilde sunulmalıdır? Nasıl bir yol izlenmelidir? Ne tür eğitimler verilmelidir?
Fonksiyonel Gereksinimler
İşlevsel ya da fonksiyonel ( functional ) gereksinimler, sistemin “ne” yapacağını ortaya çıkaran gereksinimlerdir. Diğer bir deyişle, sistemde hangi hizmetin sunulacağını belirleyen gereksinimlerdir.
Fonksiyonel Olmayan Gereksinimler
Sistemin “ne” yapacağı fonksiyonel gereksinimler ile belirlenir iken, sistemin “nasıl” olacağına fonksiyonel olmayan gereksinimler karar vermektedir. İşlevsel olmayan ( nonfunctional ) gereksinim analizi kendi içerisinde projenin kalite unsurları, güvenlik unsurları, arayüz seçenekleri gibi faktörleri barındırmaktadır.

4.2. Yazılım Tasarımı

Yazılım tasarımı, kullanıcı gereksinimlerini yazılım kodlaması ve uygulamasında programcıya yardımcı olan uygun bir forma dönüştüren bir süreç olarak tanımlanmaktadır. Kullanıcı gereksinimlerini değerlendirmek için, bir SRS ( Software Requirement Specification – Yazılım Gereksinimi Şartnamesi) belgesi oluşturulurken, kodlama ve uygulama için yazılım terimlerinde daha özelleştirilmiş ( specific ) ve ayrıntılı olan gereksinimlere ihtiyaç vardır. Bu işlemin çıktısı programlama dillerinde doğrudan uygulanabilir.

Yazılım tasarımı, problemi problem alanından çözüm alanlarına taşıyan Yazılım Tasarımı Yaşam Döngüsündeki ( Software Development Life Cycle ) ilk adımdır. SRS’de belirtilen şartları nasıl yerine getireceğini belirtmeye çalışır.
Yazılım tasarımı üç düzey sonuç verir:

Mimari Tasarım – Mimari tasarımı, sistemin en soyut halidir. Yazılımı, birbiriyle etkileşime giren birçok bileşen içeren bir sistem olarak tanımlar. Bu seviyede, tasarımcılar önerilen çözüm fikirlerini alırlar.

Üst Düzey Tasarım – Üst düzey tasarım, “tek varlık-çoklu bileşen” ( single entity-multiple component ) mimari tasarım kavramını alt sistem ve modüllerin daha az soyutlanmış görüntüsüne ayırır ve birbirleriyle etkileşimlerini gösterir. Üst düzey tasarım, sistemin tüm bileşenlerini birer modül halinde nasıl uygulanabileceğine odaklanır. Her bir alt sistemin modüler yapısını ve birbirleri arasındaki ilişkileri ile etkileşimini tanır.

Detaylı Tasarım – Ayrıntılı tasarım, önceki iki tasarımda bir sistem ve alt sistemleri olarak görülen aşamaların çalıştırma ve uygulama kısmı ile ilgilenir. Modüller ve onların uygulamalarına göre daha detaylıdır. Her bir modülün mantıksal yapısını ve onun diğer modüller ile iletişim kurabilmesi için gerekli arayüzleri tanımlar.

4.3. Modüllere Ayırma

Bir yazılım sistemini, bağımsız olarak görev (ler) i gerçekleştirme kapasitesine sahip olan ayrık ve bağımsız modüllere bölmek için kullanılan bir tekniktir. Bu modüller, tüm yazılım için temel yapılar olarak çalışabilir. Tasarımcılar bu modülleri, ayrı ayrı ve bağımsız olarak yürütülebilecek ve/veya derlenebilecek şekilde tasarlamaya çalışırlar.

Modüler tasarım, istemsizce “böl ve fethet / yönet” ( divide and conquer ) problem çözme stratejisinin kurallarını izler; bunun nedeni, bir yazılımın modüler tasarımı ile bağlantılı birçok başka faydalarının olmasıdır.

4.4. Eşzamanlılık

Zaman içinde, tüm yazılımlar sırayla yürütülür. Ardışık yürütme ile kodlanmış komutun birbiri ardına yürütüldüğünü ve herhangi bir zamanda, programın sadece bir kısmının aktive edildiğini gösterir. Bir yazılımın birden fazla modüle sahip olduğunu varsayalım, o zaman, herhangi bir zamanda tüm modüllerden sadece biri etkin olarak bulunabilir.

Yazılım tasarımında eşzamanlılık, yazılımı, modül modül olarak paralel bir şekilde yürütmek ve çalıştırmak gibi bağımsız yürütme birimlerine bölmek suretiyle gerçekleştirilir. Diğer bir deyişle, eşzamanlılık, yazılımın, birbirine paralel olarak birden fazla kod parçasını yürütme yeteneğini sağlar. Programcılar ve tasarımcılar için paralel olarak yürütülebilecek modüllerin tespit edilmesi önemlidir.

4.5. Birleştirme

Bir yazılım programı modüllere ayırdığı zaman, görevleri belirli özelliklere dayalı olarak birkaç modüle ayrılır. Bildiğimiz gibi, bazı görevlerin yerine getirilmesi için modüllerin bir araya getirilmesi gerekmektedir. Modüller, tek bir varlık olarak kabul edilirler, fakat birlikte çalışmak için birbirlerine başvurabilirler. Bir modül tasarımının niteliği ve bu modüllerin aralarındaki etkileşimin ölçülebileceği kriterler vardır. Bu kriterler birleştirme ve uyum olarak adlandırılır.

4.6. Tasarım Doğrulama

Yazılım tasarım sürecinin çıktısı, tasarım dokümantasyonu, sözde kodlar, ayrıntılı mantık diyagramları, süreç diyagramları ve tüm işlevsel veya fonksiyonel olmayan gereksinimlerin ayrıntılı açıklamasıdır. Yazılımın çalıştırılması ve uygulanması olan bir sonraki aşama, belirtilen bu tüm çıktılara bağlıdır.

Daha sonra bir sonraki aşamaya geçmeden önce çıkışı doğrulamak gerekir. Çünkü herhangi bir hata erkenden tespit edilebilir, ya da ürünün test edilmesine kadar tespit edilemeyebilir. Tasarım aşamasının çıktıları grafiksel gösterim biçimindeyse, doğrulama için ilgili araçları kullanılmalıdır aksi halde doğrulama ve onaylama için kapsamlı bir tasarım incelemesi kullanılabilir.

Yapılandırılmış doğrulama yaklaşımıyla, denetleyiciler bazı koşullara bağlı olarak ortaya çıkabilecek kusurları algılayabilir. Tasarımım iyi bir şekilde incelemesi ve iyi yazılım tasarımı, doğrulanma ve kalite için önemlidir.

Yazılım analizi ve tasarımı, gereksinim şartlarının uygulamaya dönüştürülmesine yardımcı olan tüm etkinlikleri içerir. Gereksinim özellikleri yazılımdan tüm işlevsel ve fonksiyonel olmayan beklentileri belirtmektedir. Bu gereksinim özellikleri, insan tarafından okunabilir ve anlaşılabilir belgeler biçimindedir.

Yazılım analizi ve tasarımı, insan tarafından okunabilir gereksinimlerin gerçek koda dönüştürülmesine yardımcı olan orta aşamadır. Yazılım tasarımcıların kullandığı birkaç analiz ve tasarım araçlarını inceleyelim:

4.7. Veri Akış Diyagramı (Data Flow Diagram)

Veri akışı diyagramı, bir bilgi sisteminde veri akışının grafiksel ve biçimsel gösterimidir. Gelen veri akışını, giden veri akışını ve depolanmış verileri gösterebilir. Yalnız, verilerin sistemden nasıl geçtiği hakkında bir şey söylemez.

Veri Akış Diyagramı ve Akış Şeması arasında belirgin bir fark vardır. Akış Şeması, program modüllerinde kontrol akışını gösterir. Veri akış diyagramları ise, sistemdeki verilerin akışını çeşitli seviyelerde göstermektedir. Herhangi bir kontrol veya dal unsuru içermez. Mantıksal ve Fiziksel olarak iki tür Veri Akış Diyagramı ( VAD ) mevcuttur.

Mantıksal VAD – sistem işlemine ve sistemdeki veri akışına odaklanır. Örneğin bir Bankacılık yazılım sisteminde, verilerin farklı varlıklar arasında nasıl taşındığına odaklanır.

Fiziksel VAD – veri akışının gerçekte sistemde nasıl uygulandığını gösterir. Daha özelleştirilmiş ve uygulamaya yakındır.

Şekil 2 Veri Akış Diyagramının Bileşenleri

Veri Akış Diyagramlarına ait ve Şekil 2’de verilen bileşenler şu şekildedir:

Varlık ( Entity ) – Varlıklar bilgi verilerinin kaynağı ve hedefidir. Varlıklar, kendi adlarına sahip bir dikdörtgenlerle temsil edilir.

Proses ( Process ) – Veriler üzerinde gerçekleştirilen faaliyetler ve eylemler Daire veya Yuvarlak kenarlı dikdörtgenler ile temsil edilir.

Veri Deposu ( Data Store ) – İki farklı veri depolama çeşidi vardır – ya her iki küçük tarafın yokluğunda bir dikdörtgen, ya da yalnızca bir tarafı eksik olan bir açık kenarlı dikdörtgen olarak gösterilebilir.

Veri Akışı ( Data Flow ) – Verilerin hareketi sivri oklarla gösterilmiştir. Veri hareketi, okun tabanından, ok yönüne doğru hedef olarak gösterilir.

Veri Akış Diyagram Türlerini inceleyelim.

4.8. Yapısal Çizelgeler

Tüm sistemi en düşük fonksiyonel modüllere ayırır, sistemin her modülünün işlevlerini ve alt işlevlerini daha ayrıntılı bir şekilde açıklar. Örnek çizelgeler Şekil 3 ve Şekil 4’te verilmiştir.

Şekil 3 Koşula göre bir yapısal çizelge

Şekil 4 Döngüsel çizelge

4.9. HIPO Çizelgeler

HIPO ( Hierarchical Input Process Output ) modeli 1970 yılında IBM tarafından geliştirilmiştir. HIPO diyagramı, yazılım sistemindeki modüllerin hiyerarşisini temsil eder. Analist, sistem işlevlerinin üst düzey görünümünü elde etmek için HIPO diyagramını kullanır. Bu diyagram fonksiyonları hiyerarşik bir şekilde alt işlevlere ayırır. Sistem tarafından gerçekleştirilen işlevleri tasvir eder.

HIPO diyagramları belgeleme amaçlı kullanılmaktadır. Grafiksel gösterimleri, tasarımcıların ve yöneticilerin sistem yapısına dair resimsel bir fikir edinmelerini kolaylaştırır. Örnek bir HIPO diyagramı Şekil 4’te gösterilmiştir.

Şekil 4 Örnek bir HIPO diyagramı

4.10. Yapısal İngilizce (Structured English)

Grafikler veya diyagramlar kullanan diğer yöntem türleri, bazen farklı insanlar tarafından farklı şekilde yorumlanabilir. Ayrıca zaman alıcıdır. Dolayısıyla, tasarımcılar Yapısal İngilizce gibi yöntem ve araçlara başvurmaktadır. Yapılandırılmış İngilizce, yapılandırılmış programlama paradigmasında sade İngilizce kelimelerini kullanır.

Örnek:
IF … THEN … ELSE …;
DO … WHILE …

4.11. Sözde / Kaba Kod (Pseudo Code)

Sözde kod, programlama diline daha yakın yazılmaktadır. Yorum ve açıklamalarla dolu bir programlama dili olarak düşünülebilir.

Sözde kod, değişken bildirimi önler ancak C, Fortran, Pascal vb. Gibi bazı gerçek programlama dilleri kullanılarak yazılır. Yapılandırılmış İngilizce’den daha fazla programlama bilgisi içerir. Bir bilgisayarı kod yürütüyormuş gibi görevi gerçekleştirmek için bir yöntem sağlar.

4.12. Kullanıcı Arayüzü (User Interface)

Kullanıcı arayüzü, yazılımı kullanmak için kullanıcının etkileşimde bulunduğu uygulamanın görünümüdür. Kullanıcı, yazılımı, yanı sıra donanımı kullanıcı arayüzü aracılığıyla yönetebilir ve kontrol edebilir. Günümüzde kullanıcı arayüzü, dijital teknolojinin bulunduğu hemen hemen her yerinde kullanılmaktadır. Örneğin, bilgisayarlarda, cep telefonlarında, arabalarda, uçaklarda, gemilerde vb.

Kullanıcı arayüzü yazılımın bir parçasıdır ve kullanıcının onu kolay bir şekilde anlayabileceği şekilde tasarlanır. Kullanıcının bu arayüz üzerinden yazılımı algılaması beklenir. Bu nedenle, kullanıcı arayüzü insan-bilgisayar etkileşimi için temel bir platformdur.

Bir arayüz, donanım ve yazılım birleşimine bağlı olarak grafiksel, metin tabanlı, ses-video tabanlı olabilir. Ayrıca, donanım veya yazılım veya her ikisinin bir kombinasyonu şeklinde olabilir. Arayüzün çekici, kullanımı kolay, duyarlı ve kısa sürede cevaplayan, anlamak için kolay ve net ve kullanıcı ekranlarına uyumlu olması yazılımın yaygın olarak kullanılmasına yardımcı olur. Genelde iki tür arayüz kullanılır:

GUI – Graphical User Interface ( Grafiksel Kullanıcı Arayüzü )
CLI – Command Line Interface ( Komut Satırı Arayüzü )

4.13. Komut Satırı Arayüzü (Command Line Interface)

Komut satırı, bilgisayarlarla etkileşimin temel aracıdır. Video ekran monitörleri ortaya çıkana kadar yaygın olarak kullanılmaktaydı. Günümüzde ise birçok teknik kullanıcı ve programcının ilk tercihidir komut satırı arayüzü.

Kullanıcı, komutlarını kullandığı sistemin komut istemcisine yazar. Kullanıcının komutun sözdizimini ve kullanımını hatırlaması gerekir. Komut kullanımı ile ilgili bilgiler edinmek için dokümantasyonlara başvurulmalıdır. Kullanıcının çalışmasını kolaylaştırmak için makrolar gibi birçok komut dosyaları gibi yöntemler vardır. Komut satırı arayüzü, grafiksel kullanıcı arayüzüne kıyasla daha az miktarda bilgisayar kaynağı kullanıyor.

Örnek, dosyaları ( . ile başlayan gizli dosya ve dizinleri de ) listeleyen ve onlarla ilgili geniş bilgiler veren komut:

~$: ls -al

Burada, ~$: kısmını bir komut satırı olarak düşünelim; ls – komutun kendisi, -al ise komutla birlikte kullanılabilecek parametrelerdir. Bu ls komutunun ve diğer parametrelerinin kullanımı ve çalışması aşağıdaki tabloda verilmiştir.

Komut ve Parametre	Ne İş Yapar?
Ls	Bulunduğunuz dizindeki dosya ve dizinleri yatay olarak listeler.
ls –l	Bulunduğunuz dizindeki dosya ve dizinleri dikey ve ayrıntılı olarak listeler. Alfabetik sırada listeler.
ls –a	Bulunduğunuz dizindeki dosya ve dizinleri yatay olarak listeler. Ek olarak gizli dosya ve dizinleri de gösterir.
ls -l –a	Bulunduğunuz dizindeki dosya ve dizinleri dikey ve ayrıntılı olarak listeler. Ek olarak gizli dosya ve dizinleri de gösterir.
ls -l –h	Bulunduğunuz dizindeki dosya ve dizinleri dikey ve ayrıntılı olarak listeler. Listelenen dosya ve dizin boyutunu KB-MB-GB cinsinden gösterir.
ls –o	Bulunduğunuz dizindeki dosya ve dizinleri dikey ve ayrıntılı olarak listeler. ls -l komutundan farkı olarak, kullanıcı grubunu göstermez.
ls -l –t	Bulunduğunuz dizindeki dosya ve dizinleri dikey ve ayrıntılı olarak listeler. Zamana göre sıralı bir şekilde listeler. Listeye en son oluşturulandan başlar.
ls -l -t –r	Bulunduğunuz dizindeki dosya ve dizinleri dikey ve ayrıntılı olarak listeler. Zamana göre sıralı bir şekilde listeler. Buradaki -r parametresi sayesinde zamanın tersinde sıralar. Diğer bir ifadeyle, listeye ilk oluşturulandan başlar.
ls -l –r	Bulunduğunuz dizindeki dosya ve dizinleri dikey ve ayrıntılı olarak listeler. ls -l komutu alfabetik sıraya göre listelerken, buradaki -r parametresi, alfabetik sıraya göre tersten sıralar.
ls -l –d	Sadece bulunduğunuz dizinin ayrıntılarını verir. Dosyaları göstermez..
ls -l hedef1 hedef2	hedef1 ve hedef2 dizinlerinin içindekileri aynı anda dikey ve ayrıntılı olarak listeler.

4.14. Grafiksel Kullanıcı Arayüzü (Graphical User Interface)– 1 – –

Grafiksel Kullanıcı Arayüzü, sistemle etkileşime geçmek için kullanıcıya grafiksel bir görünüm sunan araçtır. Grafiksel arayüz, hem donanım hem de yazılımın kombinasyonu olabilir. Grafiksel arayüzü kullanarak, kullanıcı yazılımı çalıştırır.

Genellikle, grafiksel arayüz, komut satırı arayüzünden daha fazla bilgisayar kaynağı tüketir. Gelişen teknolojileri kullanarak, programcılar ve tasarımcılar karmaşık grafiksel arayüzleri daha verimli, daha doğru ve daha hızlı olacak şekilde tasarlamaktadırlar.

Tipik bir grafiksel arayüzde:

pencerelerin açma/kapatma ve aşağı alma tuşları
pencere içerisinde sekmeler
uygulamaya ait araçlar çubuğu
çeşitli simgeler
kaydıraklar

gibi elemanlar mevcuttur.

Ayrıca, uygulamanın özelliklerine göre: metin giriş kutucukları, seçmeli listeler, birden fazla seçmeli kutucuklar, yuvarlak/dikdörtgen kutucuklar, “Tamam” ve/veya “Gönder” gibi komutlar için tıklama butonları kullanılabilir.

Arayüz geliştirme ortamları

Komut satırı arayüzlerinin tasarımı için betiklerin ve makroların yazılması yeterlidir. Grafiksel arayüzleri ise hem kodlar yazarak hem de sadece fareye tıklayarak tasarlanabilir.

Grafiksel arayüz tasarım araçları mobil arayüzü geliştirme, masaüstü uygulama arayüzü geliştirme, dokunmatik ekran arayüzü geliştirme vb. şeklinde ayrılabilir.

Örnek arayüz geliştirme ortamları:

AppInventor (Android)
Visual Studio
Ruby Shoes
Qt

4.15. Programlama Stili (Programming Style)

rogramlama stili, tüm programcıların takip ettiği kodlama kurallarıdır. Aynı yazılım projesi üzerinde çalışırken, çoğu geliştirici başka bir geliştirici tarafından yazılan program kodu ile çalışmalıdır. Programı kodlamak için bazı standart programlama stilleri takip edilmezse, programı anlamak uzun süre alır ve sıkıcı olur veya bazen imkânsızlaşır.

Bir programlama stili, iyi yerleştirilmiş girinti nasıl olur, amaçlanan görevle ilgili işlev ve değişken isimleri nasıl kullanılmalı, okuyucunun rahatlığı ve genel kod anlatımı için yorum kodu nasıl yazılmalı konusunda belirli kurallar içerir. Bu, program kodunu herkes tarafından okunabilir ve anlaşılabilir kılar; bu da hata ayıklama ve hata çözümlemeyi kolaylaştırır. Ayrıca, uygun bir kodlama stili dokümantasyonu ve ileride düzeltmeler yapmayı kolaylaştırır.

Kodlama Kuralları

Programlama stili uygulaması şirket ve kuruluşlara, işletim sistemlerine ve kodlama diline göre değişir. Aşağıdaki kodlama elemanları bir kuruluşun kodlama kuralları altında tanımlanabilir:

Adlandırma kuralları – işlevlerin, değişkenlerin, sabitlerin ve genel değişkenlerin nasıl adlandırılacağını tanımlar. Örn. Sabit isimleri hep büyük harften oluşsun; ve/ya da proje geliştirme kapsamında Camel Case kullanılsın gibi kurallar.

Girintiler – Bir satırın başında kalan boşluk sayısıdır, genellikle 2-8 boşluk olarak belirlenir.

Boşluk – Genellikle satırın sonunda ihmal edilir.

Operatörler – Matematiksel ve mantıksal işleçleri yazma kurallarını tanımlar. Örneğin, atama operatörü ‘=’, “x = 2” deki gibi, atama operatöründen önce ve sonra birer boşluk bırakılmalıdır.

Kontrol Yapıları – If-then-else yapısını yazma kuralları, switch-case, do-while ve for döngü ifadeleri için yazılmış kurallar.

Fonksiyonlar – Parametreli ve parametresiz fonksiyonların nasıl bildirilmesi ve çağrılması gerektiğini tanımlar.

Değişkenler – Farklı veri tiplerinin değişkenlerinin nasıl tanımlanması gerektiğini belirtir.

Yorumlar – Kodda yer alan yorumlar kodun gerçekte ne yaptığını ve diğer tüm ilişkili açıklamaları açıkladığından dolayı önemli bir bileşendir. Ayrıca diğer geliştiriciler için yardımcı dokümantasyonlarının oluşturulmasına yardımcı olur.

Programlama stiline ve kodlama kurallarına bir örnek verelim. C Programlama dilinde geleneksel olarak bir “Merhaba Dünya!” mesajını yazdıralım. Kodları Şekil 5 ve Şekil 6’da verilmiştir.

Şekil 5 C programlama dilinde bir “Merhaba Dünya!” mesajı

Şekil 6 C programlama dilinde bir diğer “Merhaba Dünya!” mesajı

Şekil 5 ile Şekil 6’da verilen her iki kod aynı işlevi yapmaktadır. Her ikisi “Merhaba Dünya!” yazısını yazdırmaktadır. Ancak, Şekil 5’teki kod daha okunaklı ve daha kolay anlaşılır bir koddur. Diğer kod parçası ise, anlaşılması için daha fazla zaman ve odak ister. Bu durum büyük projeler için düşünülürse ve o proje üzerinde çalışmakta olan geliştiriciler sayısı da düşünülürse ve her geliştiricinin de kodu kendi tarzına göre yazdığı kabul edilirse, kodlarda büyük anlaşmazlıklar ortaya çıkar ve geliştiriciler ekibi içerisinde büyük sorunlar yaşanabilir. Dolayısıyla, bir yazılım geliştirilmesi sürecinde, kod yazılırken, ekip üyelerinin uyması gereken kodlama kurallarının olması önemlidir.

Bir if-else-then yapısı, C programlama dilinde nasıl kullanılabildiğine bakalım. Kullanımları şu şekilde olur:

if (koşul)
{
yapılacaklar;
}
else
{
yapılacaklar;
}

ya da şu şekilde:

if (koşul){
yapılacaklar;
}else{
yapılacaklar;
}

Burada, ufak bir fark var. Süslü parantezlerin ( { } ) koşuldan ( bir fonksiyon da olabilir ) hemen sonra ya da onun altına yerleştirilmesi seçeneği. Bu da, ufak bir fark olmasına rağmen, büyük çaplı projelerde bu durumun faklı şekillerde ( birini ilk örnekteki gibi, diğer birini ise ikinci örnekteki gibi ) kullanılması kod anlaşılırlığını azaltır.

4.16. Test Etme

Yazılım testi, yazılımın değerlendirilmesidir. Yazılım, kullanıcı ve sistem özelliklerinin gereksinimlerine karşı test edilir. Yazılım testi, yazılım geliştirme yaşam döngüsündeki bir aşaması olarak ya da program kodunda modüllere ayırma seviyesinde gerçekleştirilir. Yazılım testi doğrulama ( validation ) ve onaylamadan / doğrulamadan ( verification ) oluşur:

Doğrulama, kullanıcı gereksinimlerine yoğunlaşmaktadır.Onaylama ise tasarım ile sistem özelliklerine odaklanır.

Bir testin hedefi, hata, kusur ve arızaları tespit etmektir.

Hatalar – Geliştiricilerin yaptığı kodlama hatalarıdır. Yazılım çıktıları istenen çıktıdan farklı ise, bu bir hata olarak kabul edilir. Sözdizim hatası ya da Mantıksal bir hata olabilir.

Kusurlar – Hatalar olursa, sistemde bir kusur oluşur. Bu kusurlar çalıştırılırsa sistemin arızalanmasına neden olur.

Arızalar – Sistemin istenen görevi yerine getirememesidir. Arıza, sistemde kusurlar olduğu zaman oluşur.

( Hatalar daha detaylı bir şekilde Bölüm 2’de anlatılmıştır. )

Bu hata tespit işlemleri elle ya da otomatik olarak yapılabilir. Elle yapılan testler zaman alıcıdır. Fakat testlerin çoğu elle yapılır. Bir sunucunun aynı anda bir milyon kullanıcıya hizmet verip veremeyeceğini denemek gibi durumlarda manuel testler yapılamaz ve onların yerine otomatik testler uygulanır.

İşlevsellik, gerçek uygulamayı dikkate almadan test edildiğinde, kara kutu testi olarak bilinir. Yalnızca işlevselliğin test edilmediği, ancak uygulanma şeklinin de analiz edildiği durum ise beyaz kutu testi olarak bilinir.

Kapsamlı testler, mükemmel bir test için en çok istenen yöntemdir. Giriş ve çıkış değerleri aralığında her olası değer test edilir. Değer aralığı büyükse, gerçek dünya senaryosundaki her değeri test etmek mümkün değildir.

Test süreci yazılım geliştirmeye paralel olarak çalışır ve yazılım geliştirme sürecinin çeşitli aşamalarında yapılabilir. Bir aşamadan bir sonraki aşamaya geçmeden önce, ilgili aşama test edilir, doğrulanır, onaylanır ve sonradan bir sonraki aşamaya geçiş yapılır.

Testleri ayrı bir şekilde yapılmasının nedeni yazılımda gizlenmiş ve fark edilmesi zor olan hataların erkenden tespit edilmesinin istenmesidir. Ayrı şekilde yapılan bu testler birim testi, entegrasyon testi ve sistem testi olarak bilinir.

Birim Testi
Programcı ve geliştiricilerin kodlama aşamasında her kod birimine yaptıkları testlerdir. Her bir birimin doğru ve istendiği şekilde çalıştığından emin olmak için yapılan bir testtir. İlgili birimin, verilen girdilere karşı beklenen sonucun vermesi beklenir.

Entegrasyon Testi
Birimlerin kendi başlarına çalışıyor olması bir yazılım için yeterli değildir. Bu birimlerin entegre edildiği, birleştirildiği ve birbirleriyle bağlaştırıldığı zaman da çalışıyor olması beklenir.

Sistem Testi
Artık bir ürün haline gelmiş sistemin tamamı test edilir. Örneğin, performans açısından, sahip olduğu özellikler açısından ya da taşınabilirlik açısından test edilebilir.

Daha önce de belirtilen, kara-kutu/beyaz-kutu testleri, birim testi, entegrasyon testi, sistem testi ve kabul testi gibi test yöntemleri mevcuttur. Bu test stratejileri Bölüm 6’da daha detaylı olarak açıklanmıştır.

Yazılımda yapılan testlerin de belgelenmesi ve arşivlenmesi önemlidir. Test yapılmadan önceki durum, test esnasında karşılaşılan durumlar ve test sonrası elde edilen sonuçların hepsi belgelenmelidir.

4.17. Versiyonlama

Sürekli değiştirilmekte ve geliştirilmekte olan yazılımın takip edilmesi geliştiricilere birçok kolaylık sağlar. Hangi aşamada neler yapıldığı, hangi özelliklerin eklendiği konusunda haberdar olmak yazılımın geliştirilmeye devam etmesine yardımcı olur. Yalnız, sistemin büyümesi ve gelişmesiyle birlikte, sistemde kullanılan modüller sayısı artar. Bu modüllere göre sürümlerin çıkartılması ise çok karışık bir durum yaratır. Dolayısıyla, Semantic Versioning gibi bir sürüm numaralandırma sisteminin kullanılmasında fayda var.

Semantic Versiyonlama sistemi şu şekildedir:

1.2.3

1 -> major: geriye doğru uyumsuzdur. Gerekli kurulumlar yapılmalı.
2 -> minor: yeni özellikler var demek ve kullanım kılavuzu var.
3 -> patch: ya da bugfix, sadece ve sadece hata düzeltimi.

Başka bir ifadeyle, semantik versiyonlamada, MAJOR.MİNOR.PATCH şeklinde bir sürüm isimlendirilmesi yapılmaktadır. Bu versiyonlama sistemi geliştiricilere yazılım ürünü ile ilgili bazı bilgiler vermektedir. Dolayısıyla gerekli ve önemlidir.

Ancak, bu versiyon sayıları son kullanıcıya karışık gelebilir. Örneğin, Microsoft Office 2.1.5 gibi bir isimlendirme yerine Microsoft Office 2013 isminin kullanılması, kullanıcıya ismin hatırlamasında büyük bir kolaylık sağlar.

Fakat geliştiricilerin üründe yaptıkları kendi değişiklikleri bir şekilde görebilmeleri gerekmektedir. İşte burada, yazılım projelerinin olmazsa olmazı olan versiyon kontrol sistemleri devreye girmektedir.

Git, SVN gibi versiyon kontrol sistemleri, geliştiricilerin yaptıkları değişiklikleri kayıt altında tutarak, eski veya bir önceki sürümler ile güncel sürüm arasındaki farkları göstererek, aynı kod üzerinde birden fazla geliştiricinin çalışabilmesine imkan sunarak, proje geliştirilmesinde takip ve takım üyeleri arasında işbirliği kolaylığını sağlayan araçlardır. Bu sürüm kontrol araçları, Bölüm 9’da anlatılan CASE araçları arasında, yapılandırma yönetimi araçları grubu altında yer almaktadır.

Yazılım geliştirmede nerdeyse her aşamasının belgelenmesinin ve arşivlenmesinin önemli olduğu vurgulanmıştır. Yapılan değişikliklerinin kaydını tutan ve güncel sürümler ile öncekiler arasındaki farkı gösteren sürüm yönetim araçlarının kullanılmasıyla belgelendirme aşamasının da kolaylaşacağı görülmektedir.

4.18. Belgelendirme

Yazılım ürünü geliştirme sürecinin önemli aşamalarının birisidir belgelendirme. Yazılımın işleyişi konusunda anlatım yazıları içerir. Ayrıca, iyi bir belgelendirme yazılım ürünü kullanım kılavuzunu da içermelidir.

İyi bir belgelendirmede yazılımda kullanılan fonksiyonların ne işe yaradığı açık şekilde yazılmış olmalıdır; yazılımın kodlanmasında kullanılan kuralların neler olduğu da belirtilmelidir. Kısaca, bir belgelendirmede, yazılım tasarımı ve yazılımın içerdiği kodlar konusunda kolay anlaşılabilir bilgiler sunulmalıdır.

Yazılım tasarımı aşamasında kullanılan akış diyagramlar, sözde kodlar ve hipo çizelgeler gibi şekillerin belgelenmede kullanılması ve onların açık bir şekilde anlatılması önemlidir. Ayrıca, ürünün geliştirilmesinde kullanılan programlama stili belirtilmelidir, ya da kodlama aşamasında kullanılan kuralların belirtilmesi gerekmektedir.

Yazılım geliştirme aşamalarının arşivlenmesinin önemli olmasının nedenlerinin biri, yeni gelen bir geliştiricinin mevcut olan ürünü çabuk tanıyabilmesini ve inceleyebilmesini sağlar. Bu da, geliştiricinin oturup her şeyi ne anlama geldiğini kendi başına öğrenmesinden kurtarır ve böylece zaman kazandırır.

Aynı şekilde, son kullanıcının da sistemi çabuk anlaması ve kullanabilmesi önemlidir. Dolayısıyla, belgelendirmede kullanım kılavuzların yazılmasına da dikkat edilmelidir. Belgelendirmede kullanım kılavuzlarının yanında kullanım anlatım videoları da yer alabilir.

Yazılım Güvenilirliği bölüm 5

Bölüm Hedefi

Kaliteli bir yazılım ürünü geliştirebilmek için, o ürünün güvenilir ve güvenli olmasının gerektiği birçok kalite konulu yazı ve belgelerde belirtilmektedir. Yalnız, ilk bakışta karıştırılabilen bu kelimelerinin anlamları nedir? İşte bu bölümde, yazılım güvenirliği ile yazılım güvenliği konuları açıklanmıştır. Ayrıca, risk analizlerine de yer verilmiştir.

İlk bakışta karıştırılabilir olan güvenilirlik ve güvenlik kelimeleri Türkçe’de etimolojik olarak aynı kökten gelmektedir. Belki de bu yüzden bu iki kelimeyi karıştırabiliriz, bazen birbirleri yerine kullanabiliriz ve / veya biri olmadan, diğerinin de olmayacağını düşünebiliriz. Ancak, bu kelimelerin İngilizce’deki karşılıkları şu şekildedir: Güvenillirlik – Reliability, Güvenlik ise Security kelimelerinden gelmektedir. Böylece, bu iki kelime farklı anlamlar taşımaktadır. Bu kelimelerin tanımlarını inceleyelim.

Türk Standartları Enstitüsü’nün Bilişim Terimler Sözlüğünde, güvenilirlik ( reliability ), bir işlevsel birimin, belirli bir zaman aralığında ve verilen şartlar altında istenen işlevi yerine getirme yeteneği olarak tanımlanmaktadır.

Aynı Bilişim Terimler Sözlüğünde, güvenlik şu şekilde tanımlanmaktadır: bilgisayar güvenliği ( computer security ), veri ve kaynakları, uygun işlemleri yerine getirerek, kazara veya art niyetli yapılan ihlal eylemlerinden korumadır. NOT: Bu ihlal eylemleri, yetkilendirilmemiş kişilerce yapılan değişiklik, tahrip, erişim, ortaya çıkarma veya elde etme olabilir.

Dolayısıyla, bu iki kelimenin karıştırılmamasına ve yerine göre kullanılmasına dikkat edilmelidir. Yazılım geliştirme sürecinde önemli bir yer kaplayan bu iki kavramı ayrı ayrı ve daha detaylı olarak inceleyelim.

5.1. Yazılım Güvenirliği (Software Reliability)

Yazılım güvenilirliği, yazılım geliştirme sürecinin en iyi şekilde işlemesi, yazılım ürününün daha iyi ve kaliteli olmasını sağlar. Yazılımın iyi olması için taşıması gereken özelliklere bakılırsa, yazılımın neler sunduğuna ve ne kadar rahat ve kolay kullanım sunduğuna bakılır. Temel olarak, müşteri memnuniyeti yazılımın taşınabilir, bakımı kolay ve çalışabilir olmasıyla sağlanır. Çalışmakta olan bir yazılımın aynı zamanda güvenilir olması beklenir. Peki, güvenilirlik nedir?

IEEE Yazılım Mühendisliği Sözcüklerinin Standart Sözlüğünde, güvenilirlik; sistem veya bileşenlerinin belirli bir ortamda, belirli bir zaman dilimi içinde kendilerinden beklenilen işlevleri yerine getirebilme olasılığı olarak tanımlanmaktadır. Yani, söz konusu yazılımın güvenilirliği olunca ürünün istenilen şekilde çalışması beklenmektedir. Örneğin, yaşamsal önemi olan yazılımların geliştirilmesinde, güvenilirliğinin sağlanması ve onun üzerine çalışmaların yapılması gerekmektedir. Çünkü hastalık tespiti amacıyla yapılan tahliller ve çeşitli cihazlarla yapılan kontroller sonucunda elde edilen verilerin çoğu sayısaldır. Dolayısıyla, onların doğru bir şekilde tespit edilmesi ve doğru bir şekilde işlenmesi doğru sonuçların üretilmesine ve hastanın hayatını kurtarmaya yardımcı olur.

Güvenilirlik ( Reliability )
Bir işlevsel birimin, belirli bir zaman aralığında ve verilen şartlar altında istenen işlevi yerine getirme yeteneği.

TSE (Türk Standartları Enstitüsü) Bilişim Terimleri Sözlüğü

Yazılım güvenilirliğinin temel kavramları hata, kusur ve arızalardır. Yazılım arızaları hataların, belirsizliklerin, yazılımın tatmin edici olması, yazım kurallarında dikkatsizlik veya yetersizlik, yazılımın yanlış veya beklenmedik kullanımı veya diğer öngörülemeyen problemlerin yanlış anlaşılmasından veya yanlış yorumlanmasından kaynaklanabilir. Dolayısıyla, tüm bu yanlış ve yetersizliklerin sayısını indirgemek amacıyla çeşitli testler yapılmakta.

Yazılım geliştirme aşamalarında yapılan çeşitli testler hakkında önceki bölümlerde bahsedildi. Bu testler, genellikle, birim testi, entegrasyon testi ve sistem testi olarak bilinmektedir. Peki, test nedir?

Test bir değerlendirmedir. Testin genel tanımı, sonradan kazanılmış yetenek, bilgi ve becerileri ölçmeye ve anlamaya yarayan bir sınamadır. Kod iyileştirilmesi, hataların tespit edilmesi, sistemin geliştirilmesi vb. için birim testi, entegrasyon ve sistem testleri mevcut olduğu gibi, yazılım güvenilirliği için de kendi testleri bulunmaktadır.

Yazılım güvenilirliği testi, bir yazılımın, yazılım tasarımında ve işlevselliğindeki sorunları ortaya çıkarmaya yardımcı olacak şekilde, çevresel koşullara bağlı olarak işlevini yerine getirme yeteneğini test eden bir test tekniğini test eder.

Yazılım Güvenilirliği ve Donanım Güvenilirliği arasında bir benzetme yapmak cazip gelmekte, yazılım ve donanımlarda arıza mekanizmalarında onları farklı kılan temel farklılıklar bulunmaktadır. Donanım hataları çoğunlukla fiziksel hatalardır, yazılım hataları ise görselleştirmek, sınıflandırmak, saptamak ve düzeltmek zor olan tasarım hatalarıdır.

Zaman geçtikçe, donanımda ortaya çıkan arıza özellikleriyle ilgili eğri Şekil 1’de verilmiştir.

Şekil 1 Donanım Güvenilirliği ile ilgili eğri

Yazılım ile donanım özelliklerin aynı olmamasına rağmen, yazılım ile donanım güvenilirliği aynı özelliklere sahiptir. Aynı eksenlerde yazılım güvenilirliğini yansıtırsak, olası bir eğri Şekil 2’de gösterilmektedir.

Şekillerde gösterilen donanım ve yazılım eğrileri arasında iki büyük fark vardır. Bir fark, son aşamada, yazılımın donanımın arttıkça artan bir başarısızlık oranına sahip olmamasıdır. Bu aşamada yazılım eskimeye yaklaşıyor; yazılımda herhangi bir güncelleme veya değişiklik için motivasyon yoktur. Bu nedenle, başarısızlık oranı değişmeyecektir.

İkinci fark, faydalı ömür aşamasında yazılımın, her yükseltme ve güncelleme yapıldığında, arıza oranlarında büyük bir artış yaşayacağıdır. Başarısızlık oranı, kısmen, yükseltmelerden sonra bulunan ve giderilen hatalar nedeniyle aşamalı olarak azalmaktadır.

Şekil 1 Donanım Güvenilirliği ile ilgili eğri

Gerçekten de tasarım hatalarının düzeltilmesi zordur. Çünkü ürünün nasıl çalışacağını ve istenilen gereksinimlerin yerine getirip getiremeyeceğini belirleyen yazılım tasarımı, yazılım geliştirmenin kodlama aşamasına geçmeden önce oluşturulmalıdır. Yalnız hataların yapılması kaçınılmaz bir durumdur. Tasarım aşamasında yapılan hatalar ise, doğal olarak, insan faktörleri ve katı bir anlayışımız olmayan tasarım süreci ile ilişkilidir. Donanımda da tasarım hataları mevcut olabilir. Yalnız, donanımda fiziksel hatalar tasarım hatalarına kıyasla daha baskındır. Donanım üretim süreci olarak “imalat” eylemini düşünebiliriz, yazılımda, buna eşdeğer olarak, yazılım modüllerinin yüklenmesini kabul edebiliriz. Yalnız, donanımdan farklı olarak, yazılımdaki bu modül yüklemelerin sayısı belli değildir. Bu nedenle, yazılımın kalitesi depoya yüklendikten ve çalışmaya başladığında değişmez. Tasarım hatalarını içeren bir sistemde, aynı yazılım modüllerini kopyalayarak daha yüksek güvenilirlik elde etmeye çalışmak işe yaramaz. Donanımla karşılaştırıldığında yazılımın farklı özelliklerinin bazıları aşağıda listelenmiştir.

Hata nedeni: Yazılım kusurları temel olarak tasarım kusurlarıdır.

Aşınma: Yazılımda enerji ile ilgili aşınma durumu yoktur. Uyarı yapılmadan hatalar meydana gelebilir.

Onarılabilir sistem kavramı: Periyodik olarak sistemin yeniden başlatılması, yazılım sorunlarını düzeltmeye yardımcı olabilir.

Zaman bağımlılığı ve yaşam döngüsü: Yazılım güvenilirliği, çalıştırılma süresinin bir işlevi değildir.

Çevresel faktörler: Yazılım güvenilirliğini etkilemez, ancak program girdilerini etkileyebilir.

Güvenilirlik tahmini: Yazılım güvenilirliği, tasarımdaki insan faktörlerine tamamen bağlı olduğu için, herhangi bir fiziksel temelden tahmin edilemez.

Artıklık: Aynı yazılım bileşenleri kullanılması yazılım güvenilirliğini geliştiremez.

Arayüzler: Yazılım arayüzleri tamamen görselden ibarettir.

Hata oranı motivasyonları: Genellikle ayrı açıklamaların analizinden tahmin edilemez.

Standart bileşenler ile üretilmesi: İyi anlaşılmış ve kapsamlı olarak test edilmiş standart parçalar, bakımı ve güvenilirliği geliştirmeye yardımcı olacaktır. Ancak yazılım sektöründe bu eğilim gözlemlenemedi. Kodun yeniden kullanılması bir süredir var ama çok sınırlı bir oranda. Standart olarak, bazı standart mantık yapıları dışında, yazılım için standart bir parça yoktur.

Yeni teknolojilerin gelişmesiyle birlikte insanların istekleri ve beklentileri artmaktadır. Dolayısıyla yazılım ürünlerinin daha fazla özelliklere sahip olması beklenmektedir. Bu durum yazılımdaki kod satırlarını artırmaktadır. Kod satırlarının artması, kodların daha karmaşık hale gelmesini işaret etmektedir.

Kodların kolay anlaşılması ise, kodun anlaşılmasını, yazılımın dokümantasyon ve bakım aşamalarını kolaylaştırır. Bu yüzden, kod karmaşıklığının artması istenmeyen bir durumdur. Ancak geniş kapsamlı ya da ticari olan ve / veya günümüzde istenilen yazılım ürünlerinde bu kaçınılmazdır. Bu nedenle, oluşan bu karmaşıklığı yönetmek önemlidir.

Yazılım tasarımı ise, tam da oluşan bu karmaşıklığı yönetmek için kullanılan bir uygulama olduğu söylenebilir. Karmaşıklığın azaltılması, anlaşılması ve meydana gelen hatalar sayısının indirgenmesi üzerine çalışır. İyi bir yazılım güvenilirlik modelinin sahip olması gereken özellikler aşağıdaki gibidir:

Gelecekte oluşacak hatalara ait iyi bir kestirime olanak vermesi
Yararlı nicelikleri hesaplaması
Basit olması
Geniş bir uygulama alanının bulunması
Kabul edilebilir varsayımları desteklemesi
Parametrelerinin kolay hesaplanması
5.1. Yazılım Güvenirliği (Software Reliability) (Devamı)
Aynı şekilde, yazılım güvenilirliği mühendisliğinin çalışma süreci şekil 3’te özetlenmiştir.
Şekil 3 Yazılım güvenirliği mühendisliği süreci

Örnek olarak, donanım geliştirilmesinde, ürün ve kalıpların tasarım aşamasında kullanılan CAD ve CAM sistemleri kullanılmaktadır. Teknolojinin gelişmesiyle birlikte, dijital ortamın birçok kolaylık sağladığı görülmektedir.

Bilgisayar tabanlı CAD ( Computer Aided Design ) ve CAM ( Computer Aided Manufacture ) sistemleri karmaşık donanım modellerinin tasarlanmasında kullanılmaktadır. Bir köprü tasarımından diş tedavileri için gerekli tasarımlarına kadar yardımcı olmaktadır. Yazılım geliştirme sürecinde, kodda oluşan karmaşıklıkları yönetmek için yazılım tasarım modelleri kullanılırken, bu CAD ve CAM sistemleri, donanım tasarımında oluşan karmaşıklıklarının yönetiminde yardımcı olmaktadır.

Yazılım güvenilirliği mühendisliği süreci incelendiğinde ( Şekil 3 ), “Uygun Yazılım Güvenilirlik Modelinin Seçilmesi” aşamasını görebiliriz. Bu aşama, oldukça önemli bir aşamadır. Yazılım güvenilirlik modeli, geliştirilmekte olan yazılım türüne ve gereksinimlerine göre değişen bir tasarımdır. İlgili yazılım ürünü için mevcut olan birçok güvenilirlik modellerin arasından en uygununun seçilmesi önemlidir.

Donanım geliştirilmesinde, öncellikle kullanılacak malzeme türleri belirlenir, donanım tasarımları oluşturulur ve daha sonra çeşitli unsurlara bağlı olarak, maliyet hesabı yapılır. Aynı süreç ufak değişikliklerle yazılım için de geçerlidir. Bu süreçlerin sonucunda gereksinim ve beklentileri yerine getiren bir ürünün ortaya çıkması beklenir. Ürünün imalatı sonrasında beklenmedik hatalar oluşabilir ya da gözden kaçmış küçük / büyük eksiklikler akla gelebilir. Ancak bu tarz hataların imalat sonrası düzeltilmesi zor ve zahmetli olabilir. Dolayısıyla, ürünün çalışmamasından ya da müşteri isteklerini yerine getirmemesi gibi durumlar, müşteri ve zaman kaybına da neden olur. Bu tür olumsuz durumlarla karşılaşmamak için ya da en azından bu tarz durumlarla karşılaşma ihtimalleri azaltmak için yazılım ölçümünün yapılması gerekmektedir.

Yazılım ölçümü, yazılım geliştirme sürecinin daha verimli olmasını sağlamaktadır. Yazılım ölçümü ile ilgili yapılan bir genel bakış çalışmasında yazılım ölçümünün gerekliliği ve sağladığı faydalar aşağıdaki şekilde özetlenmiştir:

Kalite hedeflerine ulaşılmasını sağlar
Yazılımın değiştirilmesi sürecinde kalitenin izlenmesini sağlar
Karmaşıklığı sınırlar
Hataların analiz edilmesini sağlar
Yazılım proje ve ürünlerinin anlaşılmasını sağlar
Yazılım ile ilgili tahminlerin yapılmasını kolaylaştırır
Yazılım projelerinde, süreçlerin izlenmesi, değerlendirilmesi, analizi ve denetimini sağlar.

Yazılım geliştirme aşamalarında yapılan etkinliklerinin ölçümlerini alarak, onların sonuçlarına göre yazılım tasarımı veya kodlamasında (ya da ilgili aşamasında) belirli değişiklikler yaparak, üretim sürecinden sonra karşıya çıkabilecek sorunlar önlenmiş olur. Böylece, yazılım kalitesi artırılmış olur. Bu yolu izlerken, hesaplanması gereken ve dikkat edilmesi gereken noktalar Şekil 4’teki gibi verilmiştir.

Şekil 4 Yazılım ölçütleri

Geliştirilmekte olan sistemin, müşterinin isteklerini ve beklentilerini karşılayabilmesi için, yazılım geliştirme aşamalarında ölçümlere göre hareket edilmesi olumlu sonuçların elde edilmesine yardımcı olur. Böylelikle müşteri memnuniyeti ve üretilen ürünün kaliteli bir yazılım olması sağlanır.

Zamanın geçmesiyle (2-6 ay), bir geliştirici daha önce kendisinin yazdığı kodları unutmaktadır. Kodları karmaşık olan bir sistemde ise karmaşık kodların hatırlanması ve anlaşılması daha da zorlaşır. Yazılım güvenilirliği, yazılım kalitesinin önemli bir parçasıdır. Yazılım güvenilirliği çalışması üç bölüm halinde kategorize edilebilir: modelleme, ölçme ve iyileştirme.

Yazılım güvenilirliği modellemesi, problem için uygun modellerin uygulanmasıyla anlamlı sonuçların elde edilebileceği noktasında olgunlaşmıştır. Birçok model vardır, ancak tek bir model yazılım özelliklerinin gerekli bir miktarını yakalayamaz. Sorunu basitleştirmek için varsayımlar ve soyutlamalar yapılmalıdır. Tüm durumlara evrensel olan tek bir model yoktur.

Yazılım güvenilirlik ölçümü saftır. Ölçüm, diğer mühendislik alanlarında olduğu gibi, yazılımda yaygın olandan uzaktır. “Yazılım kantitatif olarak ne kadar iyi?” Soru kadar basit, hala iyi bir cevap yoktur. Yazılım güvenilirliği doğrudan ölçülemez, bu nedenle yazılım güvenilirliğini tahmin etmek ve ürünleri karşılaştırmak için diğer ilgili faktörler ölçülür. Geliştirme süreci, hatalar ve arızalar, yazılım güvenilirliği ile ilgili tüm faktörlerdir.

Yazılım güvenilirliğini iyileştirmek zordur. Problemin zorluğu, yazılım güvenilirliğinin yetersizliği ve genel olarak yazılımın özelliklerinden kaynaklanmaktadır. Şimdiye kadar yazılımın karmaşıklık problemini fethetmenin iyi bir yolu yok. Orta derecede karmaşık bir yazılım modülünün tam testi mümkün değildir. Kusursuz yazılım ürünü garanti edilemez. Zamanın ve bütçenin gerçekçi kısıtları, yazılım güvenilirliğini geliştirmeye yönelik çabaları ciddi ölçüde sınırlar.

Daha fazla yazılım gömülü sistemlere sızdıkça, felaketlere gömülmediklerinden emin olmalıyız. Dikkatli düşünülmezse, yazılım güvenilirliği tüm sistemin güvenilirlik darboğazı olabilir. Yazılım güvenilirliğini sağlamak kolay bir iş değildir. Sorun olduğu kadar, daha güvenilir bir yazılıma yönelik umut verici ilerlemeler hala devam ediyor. Yazılım mühendisliği alanında daha standart bileşenler ve daha iyi süreçler tanıtılmaktadır.

5.2. Yazılım Güvenliği (Software Security)

Günümüzde başarı ile tamamlanan projelerin çoğunluğu, yazılımların güvenlik açısından incelendiği raporlara göre, başarılı projeler olarak görülmesine rağmen birçok güvenlik sorunlarını içerdiği ve programlama hatalarına sahip olduğu gerçeği görülmektedir.

Müşteri ve / veya kullanıcı istek ve beklentilerinin artmasıyla birlikte, ihtiyaçların karşılanması için yazılımların karmaşıklığı ve genişleyebilirliği gittikçe artmakta. Bu nedenle de, hataların olma olasılığı da oldukça artmaktadır.

Yazılım güvenliği amacı, yazılım geliştirme sürecinde, yazılım ürününün sürdürülebilir işlevlere sahip olacak şekilde yapılandırmaktır. Yazılım geliştirme hayat döngüsü süresince uygulanması gereken tasarım aşamasını güvenli yapmak, kodlama aşamasında ise – güvenli kodlama ilkelerine uymak, yazılımın güvenli olup olmadığını test etmek, tasarım geliştiricileri güvenlik konusunda eğitmek gibi birçok güvenlik aşamasını kapsar.

Uygulama güvenliği, hataları daha çok, hataların belirmeye başladıktan sonra onları bularak çözmeye dayanır. Yazılım güvenliği ise, bu olabilecek hataların en başta tespit ederek, bu hatalara karşı dirençli ya da bu hataları önleyici bir yazılım geliştirmeyi amaçlar.

NASA’ya göre, bir güvenlik güvencesi programı en azından aşağıda listelenen aktiviteleri kapsamalıdır:

Güvenlik risk analizi;
Geliştirilmekte ve / veya bakılmakta olan yazılım ve veri için güvenlik gereksinimlerin değerlendirilmesi;
Geliştirme ve / veya bakım aşaması için güvenlik gereksinimlerinin değerlendirilmesi;
Tüm yazılımı gözden geçirme ve denetimlerinde güvenlik gereksinimlerinin değerlendirilmesi
Konfigürasyon yönetimi ve düzeltici faaliyet süreçlerinin var olan yazılım için güvenliği sağlaması ve değişim değerlendirme süreçlerinin güvenlik ihlallerini önlemesi;
Yazılım ve veri için fiziksel güvenliğin uygun olması;
Var olan süreç modelleri ve standartlar.

Bir güvenlik test yazılım geliştirme süreç modellerinde bulunması gereken aşamalar aşağıda gibi verilmiştir:

Güvenlik ekibi yazılım geliştirme kuruluşu bünyesinde oluşturulmalı bu yüzden tüm proje ekibi üyelerine güvenlik eğitimi verilmelidir. Gerekirse, bu sürece güvenlik uzmanı da dâhil edilmelidir.
Güvenlik gereksinimleri belirlenmeli ve kötüye kullanım senaryoları oluşturulmalıdır.
Tasarım aşamasında gerçekleştirilmesi gereken güvenlik eylemlerine değinilerek en iyi tasarıma karar verilmelidir.
Risk analizi yapılmalıdır.
Kodlama standartlarına ve güvenli kodlama ilkelerine uyulmalı, birim testleri yazılmalıdır.
Statik analiz araçları kullanılmalıdır.
Kod ve tasarım gözden geçirme yapılmalıdır.
Kod yeniden yapılandırma ile güvenlik eklemeleri, düzeltmeleri yapılmalıdır.
Güvenlik dokümanları oluşturulmalıdır. Bu dokümanlar kullanıcının hata yapmaması için kullanıcı kılavuzu gibi güvenlik sorunlarını önlemede ve geliştirici için tasarım dokümanları, yorumlarla desteklenmiş kaynak kod ve test senaryoları gibi güvenlik geliştirmesinde etkili olabilecek dokümanlardır.

5.3. Risk Analizi

Risk analizi sistemdeki riskleri değerlendirip analiz etmeye yönelik bir aktivitedir. Risk analizi yapılırken yazılımın gereksinimleri, tasarımı, mimari dokümanları, veri hassasiyeti gibi konuların üzerine yeterli araştırmanın yapılması ve bu konularda bilgi sahibi olunmalıdır.

Kuruluşun değerlerini tehlikeye düşürebilecek potansiyel tehditler ve bunlara ilişkin riskler analiz edilir. Tehlikenin gerçekleşmesi durumunda ne tür etkilere neden olacağına dair analizler yapılır. Riskler etkilerine göre önceliklendirilir. riskleri azaltmak için belirli önlemlerin alınması gerekmektedir.

Risk analizi yapılırken özet olarak organizasyonun değerleri, bu değerlere karşı olabilecek tehditler, olabilecek sistem açıkları ve riskler belirlenir. Risk analizi planlı, olaya dayalı veya ihtiyaca dayalı bir şekilde yapılabilir.

Tehditler sistemin ve değerlerin korunmasını ve güvenlik ilkelerini ihlal eden tehlikedir. Tehditler kod kırıcıları ve casuslar tarafından kaynaklanan bilinçli tehditler olabileceği gibi veri giriş hataları, programlama hataları veya eğitim yetersizliğinden kaynaklanan istenmeden yapılan hatalar da olabilir. İstenmeden yapılan programlama hataları da bu içsel tehditlere dâhildir. Risk yönetimi – yazılım hayat döngüsü süresince riskleri yeniden değerlendiren sürekli bir işlemdir.

Projenin başlangıç aşamasında değerler tanımlanır ve bu değerlerin zarar göreceği zaman ne tür etkilerin ortaya çıkabileceği belirlenir. Riskler, sistem gereksinimleri ve güvenlik işlemleri kavramı açısından değerlendirilir. Geliştirme aşamasında, belirlenen riskler yazılımın güvenlik analizine destek sağlar.

Yazılımın uygulanma aşamasında, risk yönetimi, sistemin işlevsel ortamda gereksinimlere göre gerçekleştiriminin değerlendirilmesine destek sağlar. Bakım aşamasında, periyodik olarak yapılan sistemin yeniden yetkilendirilmesi ( veya onaylanması ) veya yazılımda büyük değişiklikler yapılması durumlarında yeniden güvenliği değerlendirip sağlamak adına risk yönetimi faaliyetleri gerçekleştirilir.

Değerler, tehditler ve olası sistem açıkları belirlendikten sonra yazılımın saldırılara açık olan alanlarını en aza indirgeyecek şekilde bir tasarım yapılır. Tehdit alanları, kod parçası, arayüz, servis, protokol ( iletişim kuralları ) ve özellikle yetkisiz kullanıcılar olmak üzere tüm kullanıcılara açık olan uygulamalar olarak tanımlanmıştır. Bu alanı minimize etmek ise yazılımda oluşabilecek olası saldırıları azaltmak anlamına gelmektedir.

Yazılım Test Stratejileri

Bölüm Hedefi

Yazılım geliştirme süreci önemlidir. Bu bölümde, bu sürecin Test aşaması anlatılmıştır. Alfa, Beta, Maymun, Stres, Kullanılabilirlik, Kıyaslama ve Revizyon Test çeşitleri vb. incelenmiştir. Ayrıca, yazılım geliştirme ve / veya yazılım testi hizmeti veren şirket ve kurumlarında kullanılan teknik terimlere aşina olma amacıyla bu terimlerin İngilizce ile Türkçe’deki karşılıkları ile tanımları listesi verilmiştir.

Önceki bölümlerde de belirtildiği gibi, yazılım geliştirme sürecinin önemli aşamalarının birisi yazılımın test edilmesidir. Yazılımın test edilmesi, sistemde bulunan hataların erkenden tespit edilmesi demektir. Hataların erkenden keşfedilmesi ise güvenli bir yazılımın anahtarıdır.

Sistemin test edilmesi, sistemin değerlendirilmesidir. Bu değerlendirme, yazılım ürünü, kullanıcı ve sistem özelliklerinin gereksinimlerine karşı test edilmesiyle gerçekleştirilir. Bu aşama etkili bir şekilde yapılmazsa, müşteriye teslim edilen yazılımın arızalı olacağının ihtimali yüksektir.

Testin yapılması, yazılımın müşteriye teslim edilmesinden önce kontrol edilmesi için kullanılan ilk kalite güvencesi aracıdır. İlk başta, sistemin test edilmesi geliştirme sürecinin son aşaması olarak kabul edilmekteydi. Daha sonra, hataların erkenden keşfedilmesinin önemli olmasından dolayı, yazılım kalite güvencesi uzmanları testlerini yazılım ürününün kodlanması testine kadar genişleme cesaretini etmişler. Bu da birim testi ile entegrasyon testine kadar götürdü.

Test kesinlikle yazılım kodlarına uygulanan tek yazılım kalite güvencesi aracı değildir. Kod denetimleri ve kod örnekleri, kod çıktısı üzerine uygulanan yöntemler de yazılım kalite güvencesi araçlarıdır ve bu tarz ek araçlar aslında program çalıştırılmadan kod üzerine uygulanır. Bu prosedürler tasarım denetiminde ve kod geliştirme aşamasında uygulanmaktadır. Bunun sayesinde kod hatalarını tanımlama konusunda iyi sonuçlar elde edilmektedir. Yine de bu araçlar, sadece belgelerin gözden geçirilmesine dayanıyorlar, bu yüzden asla yazılım ürününün işlevselliğini inceleyen testin yerini alamazlar. Çünkü yazılım ürününün işlevselliği test edilirken, gerekli incelemeler ürünün müşteri tarafından kullanılacak şekilde yapılır.

Gün geçtikçe bilgisayarın ve bilgisayar yazılımlarının kullanılmadığı sektör sayısı azalmaktadır. Sektör sayısının çok olması nedeniyle de, her sektörün kendi farklı yazılım ürünlerine ihtiyacı vardır.

Geliştirilen yazılım ürünlerinin hataları birçok çeşit kayıplara yol açmaktadır. Tıp gibi hayati sektörlerde kullanılan yazılım hataları, hayat kayıplarıyla sonuçlanabilecek kadar ciddi konumdadırlar. Bununla birlikte, banka gibi önemli parasal kurumlarında kullanılan yazılımlar, hataları içerdiği zaman maddi kayıplara yol açabilir. Dolayısıyla, yazılım test süreci – yazılım geliştirme sürecindeki en önemli aşamalarından bir tanesidir. Yazılım testinin amacı, geliştirilmekte olan ürünün ileride içerebileceği hatalar sayısını mümkün olduğu kadar en aza indirgemek ve yazılım kalitesinin arttırılmasını sağlamaktır. Bu sayede kullanıcı memnuniyeti arttırılacaktır. Hatta yazılım hatalarından kaynaklanan hayat ve para kayıpları da önlenebilecektir. Yazılım test süreci, yazılım geliştirme aşamasıyla birlikte ne kadar erken evrede başlarsa, geliştirilecek olan yazılımın en az sayıda hata içermesi ve üründen istenilen performansın da daha iyi olma olasılığı artmaktadır.

TSE (Türk Standartları Enstitüsü) bilişim terimler sözlüğünde “test” kelimesini arayarak, bilişim dünyasında mevcut olan birçok test türünü öğrenebilirsiniz. Konumuz ile ilgili olan testlerin bazıları aşağıdaki şekilde tanımlanmıştır.

Bilgisayar Destekli test ( Computer – Aided testing )
bilgisayar destekli test, Bir ürün ya da onun bir parçasının veri işleme sistemlerinin kullanımıyla denetlenmesi ve test edilmesi. NOT: Bilgisayar destekli deneme bilgisayar destekli kalite güvencesinin bir türevidir.
Kabul testi ( Acceptance test )
kabul testi, Bir sistemin ya da işlevsel birimin sözleşme koşullarını yerine getirdiğini göstermek için satıcının katılımıyla sistemin kurulmasından sonra alıcının önerisi doğrultusunda test edilmesi.
Zorlama testi ( Stress test )
zorlama testi, Muhtemel bozuklukları tespit etmek ya da bozuklukların konumlarını belirlemek için mevcut çalışma şartlarının ilgili değer aralıklarında değiştirilerek gerçekleştirilen test.
Birleştirme testi ( Integration test )
birleştirme testi, Programların ya da modüllerin, sistemin bütünü içinde düzgün işlediklerininin garanti edilmesi amacıyla adım adım test edilip birleştirilmesi.
Sistem testi ve değerlendirme planı ( System test and evaluation plan )
sistem testi ve değerlendirme planı. Bir sistemin detaylı özelliklerini, kriterlerini, genel uygulama yöntemini, sorumluluklarını ve sistemin test edilip değerlendirilmesi için gerekli genel planları oluşturan plan.

Test ve bakım programı ( Test and maintenance program )
test ve bakım programı, Bir işlevsel birimi temel olarak bakım ve doğrulama amacıyla test etmek için tasarlanmış program
Test dili ( Test language )
test dili, [07.01.41], Donanım ya da yazılım bileşenlerini test etmek için yöntemler sağlayan problem yönelimli dil. ÖRNEKLER: ATLAS, ATOLL, DETOL, DMAD.
Birim testi ( Unit test )
birim test, Çözümleme ve programlama hatalarından kaçınmak için programların ya da modüllerin ayrı ayrı testi.
Kullanılabilirlik testi ( Usability test )
kullanılabilirlik testi, Gerçekleştirilen sistemin; kullanıcılar tarafından belirlenen işlevsel amaçları yerine getirip getirmediğini belirlemek için yapılan test.
Geçerleme testi ( Validation test )
geçerleme (test), Gerçekleştirilmiş bir sistemin belirlenmiş ihtiyaçları karşılayıp karşılamadığını belirlemek üzere yapılan test.
Doğrulama testi ( Verification test )
doğrulama (test), Sistemin gerçekleştirilmesinin belirli bir aşamasında sistemin belirlenmiş tüm gereksinimleri karşılandığını göstermek için sistem testi

TSE (Türk Standartları Enstitüsü) Bilişim Terimleri Sözlüğü

Yazılım testi, yazılım geliştirme süreç adımlarından en önemlilerinin bir tanesi olduğunu daha önce belirtmiştik. Bu testlerdeki amaç, yazılım projelerinde daha az hatalı ürünler üretmektir. Yazılım test mühendisliği ise, bir programın davranışlarını inceler. Birçok test durum içerisinden belirli sayıda test durumları kullanılarak programın ne tür sonuçlar ürettiğine bakılır ve onların değerlendirilmesi yapılır. Bununla birlikte bir yazılım ürününün zayıf yönleri de tespit edilmeye çalışılır. Bu bölümde birçok yazılım testi türleri verilmiştir. Bu testler dışında, yazılımın ne kadar güvenli olduğunu görmek için güvenlik açıklarını (sistemin zafiyetler) testinden de bahsedilmiştir.

Bu testler sonucunda, geliştirilmekte olan yazılım ürününün güvenilirliği ve güvenliği test edilmiş olmaktadır. ( Yazılım Güvenilirliği ile Yazılım Güvenliği kavramları daha detaylı olarak Bölüm 5’te verilmiştir )

6.1. Proaktif ve Reaktif Test Teknikleri

Günümüzde, belirli test yaklaşımları mevcuttur. Test yaklaşımı olarak da bilinen test stratejisi, testin nasıl uygulanacağını tanımlamaktadır. Test yaklaşımının iki tekniği vardır:

Açıklamaları görmek için başlıklara tıklayınız.

Proaktif

Test tasarım sürecinin, yapının oluşturulmasından önce kusurları bulmak ve düzeltmek için mümkün olduğu kadar erken başlatıldığı bir yaklaşım. Yani, yazılım geliştirirken yapılan birim testleri, modüllerin testi, entegrasyon testleri ve ürün tamamlandıktan sonra yapılan sistem testlerini içeren tekniktir. ( “Incremental Test” olarak da bilinir. )

Reaktif

Test ve kodlama tamamlanana kadar testin başlatılmadığı bir yaklaşım. Yazılım ürününün tüm modülleri ve kendisi tamamen hazır olduktan sonra yapılan test tekniğidir. Ayrıca, “big bang test” olarak da bilinir.

Proaktif test tekniği kendi içerisinde ikiye ayrılır: top-down ( tepeden aşağı doğru ) ve bottom-up ( dipten yukarı doğru ) olarak. Top-down şeklinde yapılan testlerde ilk başta ana modülün testi yapılır, daha sonra alt modüllerin testi yapılır. Bottom-up olarak yapılan testlerde ise tam tersi, önce alt modüllerin testi yapılır, daha sonra ana modülün testi yapılır.

Şekil 1 ve Şekil 2’de 11 mödül içeren bir yazılım geliştirme projesinde, bottom-up yaklaşımı ile top-down yaklaşımlarının kullanıldığı test şekli örnekleri verilmiştir.

Bottom-up yaklaşımı örneğini gösteren Şekil 1’ deki aşamalar şöyledir:

Aşama 1 ( Stage 1 ): 1-7 modüllerinin birim testlerinin yapılması

Aşama 2 ( Stage 2 ): 1. aşamada geliştirilmiş ve test edilmiş 1 ve 2 modüllerinin, bu aşamaya ait olan modül 8 ile birleştirilmesi ve birleştirme sonrası A entegrasyon testinin yapılması

Aşama 3 ( Stage 3 ): İki farklı entegrasyon testinin gerçekleştirilmesi: 3,4,5 ve 8 modüllerinin modül 9 ile birleştirerek yapılan B entegrasyon testi; ve 6 ile 7 modüllerinin modül 10 ile entegre edilerek yapılan C testinin yapılmasıAşama 3 ( Stage 3 ): İki farklı entegrasyon testinin gerçekleştirilmesi: 3,4,5 ve 8 modüllerinin modül 9 ile birleştirerek yapılan B entegrasyon testi; ve 6 ile 7 modüllerinin modül 10 ile entegre edilerek yapılan C testinin yapılması

Aşama 4 ( Stage 4 ): B ile C’nin bu aşamada geliştirilen modül 11 ile birleştirilmesi sonrası sistem testi yapılır

Şekil 1 Dipten yukarı doğru( bottom-up ) test yaklaşımı

Şekil 2 Tepeden aşağı doğru ( top-down ) test yaklaşımı]

Şekil 2’de verilen top-down yaklaşımında ise 6 aşama mevcuttur. Bunlar:

Aşama 1 ( Stage 1 ): Modül 11’in birim testlerinin yapılması

Aşama 2 ( Stage 2 ): Bu aşamaya ait olan 9 ve 10 modülleriyle birleştirerek A entegrasyon testinin yapılması

Aşama 3 ( Stage 3 ): Bu aşamada geliştirilen modül 8 ile A’nın birleştirilmesi ve B entegrasyon testinin yapılması

Aşama 4 ( Stage 4 ): Bu aşamada geliştirilen modül 6 ve 7 ile B’nin birleştirilmesi ve C entegrasyon testinin yapılması

Aşama 5 ( Stage 5 ): Bu aşamada geliştirilen modül 1 ve 2 ile C’nin birleştirilmesi ve D entegrasyon testinin yapılması

Aşama6 ( Stage 6 ): Bu aşamada geliştirilen 3, 4, ve 5 modüllerinin D ile birleştirilmesi ve sistem testinin yapılması

Bu şekillerde verilen aşamalar, ilgili projede izlenebilecek olası birçok aşamanın sadece ikisidir. Bu aşamalar farklı yollarla da izlenebilirdi.

Proaktif testi için stub ( koçan / artık ) ve driver ( sürücü )’ler

Stub ve sürücüler, modüller için gerekli yazılım değiştirme simülatörleridir. Bir birim veya bir entegrasyon testi yaparken kullanılamayan modüller yerine kullanılmaktadırlar. Örneğin, “Sahte modül” olarak da bilinen stub’lar, erişilemeyen alt modüller yerine kullanılmaktadırlar. Stub’lar tamamlanmamış bir sistemde top-down testinin yapılabilmesi için gereklidir.

Koçan / Artık ( Stub )

Koçan, bir programda ilerleme sağlanabilmesi için geçici olarak kullanılan yedek bileşen. ÖRNEK: Derleme ya da test işleminde, bir koçan gerçek bileşen kullanılabilir oluncaya kadar kullanılır.

TSE (Türk Standartları Enstitüsü) Bilişim Terimleri Sözlüğü

Daha önce de örnek olarak verilen projeyi, bu sefer stub’ların kullanılmasıyla geliştirilen proje olarak örneği Şekil 3’te verilmiştir. Şekil 3’te, top-down yaklaşımı ile geliştirilen Şekil 2’deki şemanın 3. Aşamasına stub’ların uygulanma durumu gösterilmiştir. Burada, test edilmekte olan modül 8 numaralı modüldür. Testin gerçekleştirilebilmesi için, alt modülleri şu şekil kullanılmıştır: modül 1 yerine bir stub ve modül 2 yerine bir diğer stub kullanılmakta.

Şekil 3 Stub’ların kullanım örneği ( Şekil2’deki 3.aşamaya uygulanmıştır )

Stub’ların olduğu gibi, sürücüler de bir modülün test edilmesi için belirli modül ile değiştirilmek içindir, yalnız üst modül yerine kullanılmaktadır. Test edilmekte olan modüle test verilerini girdi olarak verir ve o girdilere göre yapılan hesabı testin sonucu olarak kabul eder. Sürücüler, bottom-up testlerinde, üst modüllerin geliştirilene ve kodlanana kadar gereklidir.

Sürücülerin kullanılmasıyla ilgili örnek Şekil 4’te verilmiştir. Şekil 4’te, bottom-up yaklaşımı ile geliştirilen Şekil 1’deki şemanın 2. Aşamasına sürücülerin uygulanma durumu gösterilmiştir. Burada, test edilmekte olan modül 8 numaralı modüldür. Alt modüller olan modül 1 ile modül 2’nin testleri yapılmış durumdadır. Bu aşamadaki modül 8’in test edilebilmesi için, modül 9 yerine bir sürücü ( driver ) kullanılmaktadır.

Şekil 4 Sürücü ( driver )’lerin kullanım örneği ( Şekil 1’deki 2.aşamaya uygulanmıştır )

Bottom-up stratejisinin ana avantajı, onun performansıdır. Temel dezavantajı ise programı bir bütün olarak tamamlamada gecikmesidir. Top-down ( yukarıdan – aşağıya ) stratejisinin temel avantajı programın tüm işlevlerini, üst modüller tamamlandıktan sonra nasıl çalışacağını kısaca gösterebilmesidir. Bu özelliği birçok durumda algoritmasıyla ilgili olan analiz ile tasarım hataların ve işlevsel gereksinimlerin vs. erkenden tanımlanmasını sağlar. Bu stratejinin ana dezavantajı, gerekli stub’ların hazırlanmasının zor olmasıdır. Bu stub’ların hazırlanması genellikle çok karmaşık programlama gerektirir. Bir diğer dezavantajı ise, testlerin sonuçlarını analiz etmenin nispeten güçlüğüdür.

Test uzmanları hala bu iki stratejinin hangisinin daha kullanışlı olduğunu tartışmaktadırlar. Yalnız, bu stratejilerden hangisinin kullanılacağı, geliştiricinin seçtiği geliştirme yöntemine bağlıdır. Kısaca, testçiler geliştiriciye göre hareket etmelidirler, çünkü bir modülün kodlandıktan sonra test edilmesi önemlidir. Ayrıca, geliştirme stratejisinden farklı olarak kullanılan test stratejileri, test sürecini geciktirir.

Proaktif ile Reaktif test stratejilerinin karşılaştırılması

Küçük çaplı projelerde kullanılmadığı sürece, reaktif yani big bang testlerinin kullanılması birçok dezavantaj içermektedir. Tüm sistemin testi yapıldığı için test karmaşık hale gelir. Ayrıca, bulunan hataların düzeltilmesi de oldukça zor olur. Proaktif yani incremental testlerinin dezavantajı ise, birim ve entegrasyon testlerini yapabilmek için gerekli stub ve sürücü(driver)’lerin programlamaya ihtiyacı olmasıdır. Bir diğer büyük dezavantajı ise birçok testin gerçekleştirilmesidir. Aynı program için büyük sayıda testlerin yapılmasıdır. Mevcut dezavantajlarına rağmen, genellikle proaktif testi tercih edilmektedir.

Kabul edilebilir kalite seviyesine ulaşabilmek için programın işlevselliğinin sadece onun çıktıların göre test edilebilirliği konusunda tartışmalar yapılmaktadır. Bazıları ise, yazılımın iç yapısı ile hesaplama yönteminin de teste dahil olması gerektiğini iddia etmektedirler. Bu sayede, iki test yöntemi geliştirilmiştir.

Kara Kutu Testi ( işlevsellik ): Sistemdeki hataları, hatalı çıktıları üreten arızalı yazılıma göre belirlemektedir. Çıktıların doğru olduğu durumlarda, kara kutu testi hesaplamaların yolunu ve gerçekleştirilen işlemleri ihmal eder.

Beyaz Kutu Testi ( yapısal ): Hataları tespit etmek için program içerisinde kullanılan hesaplamalar yolunu kullanır. Basit olarak, bu testin özelliği – kod yapısının doğruluğunu araştırır.

İşlevselliğe göre yapılan testlerin sınıflandırılması aşağıdaki tabloda verilmiştir:

Tablo 1 Testlerin sınıflandırılması

Kalite gereksinim faktörleri	Test sınıfı
Doğruluk	Belgelendirme testleriErişilebilirlik (tepki zamanı) testi
Güvenilirlik	Güvenilirlik testleri
Verimlilik	Stres (yük ve dayanıklılık) testleri
Bütünlük	Yazılım sistem güvenliği testleri
Kullanılabilirlik	Eğitim kullanılabilirlik testi Operasyonel kullanılabilirlik testi

6.2. Belgelendirme Testleri

Çoğu durumda ihmal edilen belgelendirme testleri, tasarım belgelerinin denetimi ve kodların test edilmesi kadar önemli olduğu düşünülmelidir. Belgelendirme aşamasında, temel olarak sistemi tanımlayan bir belge, sistemin kurulumu ile ilgili bir kılavuz, sistemin kullanımıyla ilgili kılavuzlar ve geliştiriciler için gerekli belgeler hazırlanmalıdır.

Bununla birlikte, belgenin doğruluğu, belgenin tamamlanıp tamamlanmadığı ve belge stili ile düzenlemelerin doğruluğu denetlenmelidir. Ayrıca, ayarların nasıl yapılması gerektiği hakkında bilgileri içeren kurulum kılavuzu; sistemin nasıl çalıştığı ve özelliklerin nasıl kullanıldığı konusunda yönlendiren kullanıcı kılavuzu; ürünün program yapısı, mantıksal olarak hangi algoritmaya göre çalıştığı, hangi iyileştirmelerin yapılabileceği ve hataların nasıl giderilebileceği konusunda yardımcı olan geliştirici kılavuzu gibi belgeler de denetlenmelidir.

Belgelendirme denetimlerinde, ilgili belgenin içerdiği yazım hatalarına, ilgili belgenin tamamlanıp tamamlanmadığına ve belgenin belirlenmiş standarda göre hazırlanıp hazırlanmadığına bakılır.

.3. Maymun Testi (Monkey Test)

Maymun Testi, rastgele girdilerle ilgilenen test türü olarak tanımlanır. Şimdi ise, “Neden Maymun testi denir?” sorusu diye düşünmüşsünüzdür. Nedenlerine bakalım:

Maymun testinde kullanılan test cihazı (bazen de geliştirici) “Maymun” olarak kabul edilir.
Eğer bilgisayarı bir maymun kullanıyorsa, o bir şey anlamadan, sistem üzerindeki herhangi bir görevi rasgele çalıştırır.
Tıpkı bir test cihazının, herhangi bir test vakasını önceden tanımaksızın hataları bulmak için test edilen sisteme rastgele test senaryoları uyguladığı gibi.

Ayrıca, bazı durumlarda, Maymun testi – Birim testine veya GUI testine ayrılmıştır.

Şekil 5 Maymun ( Monkey ) testi kategorileri

Maymun testi uygulamanın şekline göre birkaç kategoriye ayrılmıştır. ( Şekil 5’te gösterilmiştir ) Bu kategoriler şu şekildedir:

Aptal Maymun: Testçilerin sistem ve işleyişi hakkında hiçbir fikri yoktur. Ayrıca test vakasının geçerliliği konusunda da bir güvence yoktur.
Akıllı Maymun: Testçiler sistem ve işleyişi hakkında kesin bir fikre sahiptir. Test cihazı sistemde dolaşır ve test için geçerli girdileri verir.
Pırlanta Maymun: Testçiler, kullanıcıların davranışına göre test yapar ve meydana gelebilecek bazı hata olasılıklarını belirtebilir.

Maymun Testi Android için de kullanılabilir. Depolama, ağ, veri, hareket ve daha fazlasını işleme zaman zaman sorunlar oluşturabilmektedir. Her mobil uygulamanın yük testi yapması önemlidir. Örneğin, bir mobil uygulamanın performansı, aşırı ısınan cihazların aşırı ısınması altında test etmenin etkinliği manuel test edicilere göre maymun test araçları kullanılarak gerçekleştirilebilir.

Testler, araçların kullanımıyla verimli olabilir. Diğer test türleri gibi daha fazla hata bulmak için de kullanılabilir. Maymun testi nispeten yeni bir testtir. Otomatik, etkili ve verimli hale getirebilmek için araçlar kullanılabilir. Bu araçlar adım adım şöyle oluşturulmalıdır:

Diğer test araçları gibi yazılım özel bir sunucuya kaydedilir.
Test paketi oluşturmak için gerekli tüm referansların iyi hazırlandığından emin olunur.
Oluşturulan test takımı çalıştırılır.
Test sonuçlarını kaydetmek için log dosyası oluşturulur.
Sistem, eylemin günlük dosyasına kaydedildiği kilitlenme noktasına gelene kadar test devam eder.
Son olarak test raporu ilgili kişi ile paylaşılır ve test verileri ileride referans olarak saklanabilir ve kullanılabilir.

Maymun testinin avantajları:

Yeni tür hatalar tespiti: Testçiler, daha önce belirtilen senaryolar haricinde, kendi anlayışına göre test uygulamalarına tam hâkimiyet gösterebilir. Böylece sistemde mevcut olan yeni hatalar tespit edilebilir.
Yürütülmesi kolay: Rasgele verilere karşı rastgele testler düzenler. Yani, sistemi test etmek kolaydır.
Daha az yetenekli insanlar: Maymun Testi, genellikle yetenekli testçiler olmadan yapılabilir.
Daha az maliyetli: Test durumlarını kurmak ve yürütmek için önemli ölçüde az maliyet gerektirir.

Maymun testinin dezavantajları:

Hiçbir hata üretilemez: Test cihazı rastgele bir şekilde rastgele verilerle testler gerçekleştirdiğinde, herhangi bir hata veya hata üretilmesi mümkün olmayabilir.
Daha Az Doğruluk: Test cihazı, tam test senaryosunu tanımlayamaz ve hatta test durumlarının doğruluğunu garanti edemez.
Çok iyi teknik uzmanlığı gerektirir: Her zaman doğruluktan ödün vermek gerekmez, bu yüzden test vakalarını daha hassas hale getirmek için testçilerin alan hakkında iyi teknik bilgiye sahip olması gerekir.
Daha az hata ve zaman alıcı: Bu test, önceden tanımlanmış testler olmadığından daha uzun sürebilir ve sistemde boşluklara neden olabilecek daha az sayıda hata bulabilir.
6.4. Erişilebilirlik (Tepki Zamanı) Testi
Diğer bir değişle, Erişilebilirlik – geliştirilen uygulamanın hizmet sürekliliğidir. Süreklilikle birlikte, uygulamanın sunduğu hizmet süresince veri kaybı yaşamaması ve kesintiye uğramaması beklenir. Bir sistemin, özellikle sistem gerçek zamanlı bir sistem ise, erişilebilirliğinin test edilmesi zordur.

6.5. Güvenilirlik Testi (Reliability Test)

Bir yazılım sisteminin güvenilirlik gereksinimleri, belirli bir zaman sonra gerçekleşenlerle ilgilidir. Mesela, arızalar arasındaki ortalama zaman (örneğin 700 saat); bir sistem arızalandığında, onun kurtarılması için harcanan süre (örneğin 20 saat). Ayrıca, güvenilirliğin donanıma, işletim sistemine ve veri iletişim sistemlerin bağlı olduğu unutulmamalıdır.

6.6. Alfa Testi (Alpha Test)

Alpha testi, yazılım geliştirmede kullanılan en yaygın yazılım test stratejilerinin birisidir. Özellikle ürün geliştirme kuruluşları tarafından kullanılır.

Bu test geliştiricinin sitesinde gerçekleşir. Geliştiriciler kullanıcıları gözlemler ve problemleri not eder.
Alfa testi, geliştirme tamamlanmak üzere olduğunda bir uygulamanın test edilmesidir. Küçük tasarım değişiklikleri hala alfa testi sonucunda yapılabilir.
Alfa testi tipik olarak tasarım ekibinden bağımsız bir grup tarafından gerçekleştirilir, ancak yine de şirket içinde, örneğin, bir şirket içi yazılım test mühendisleri veya yazılım QA ( Quality Assurance – Kalite Güvencesi ) mühendisleri tarafından da gerçekleştirilir.

Alpha testi, yazılımın genel halka yayınlanmasından önce yapılan nihai bir testtir. İki aşaması vardır:

Alfa testinin ilk aşamasında, yazılım kurum içi geliştiriciler tarafından test edilir. Hata ayıklayıcı yazılımı veya donanım destekli hata ayıklayıcıları kullanılır. Buradaki amaç hataları hızlı bir şekilde yakalamaktır.
Alfa testinin ikinci aşamasında, yazılım, kullanım amacına benzer bir ortamda ek testler için yazılım kalitesi güvencesi (QA) personeline teslim edilir.

Alfa testi, potansiyel kullanıcılar / müşteriler veya geliştiricilerin sitesindeki bağımsız bir test ekibi tarafından simüle edilmiş veya gerçek işlevsel (operational) testlerdir. Alpha testi, yazılımın beta testine geçmesinden önce, dâhili bir kabul testi olarak hazır yazılım için sıklıkla kullanılır.

6.7. Beta Testi

Beta Testi de saha testi olarak bilinir. Müşterinin sitesinde gerçekleşir. Sistemi / yazılımı yükleyen kullanıcılara gönderir ve gerçek dünya çalışma koşulları altında kullanılır.

Bir beta testi, hedeflenen kitlenin bir örnekleminin ürünü denediği yazılım testinin ikinci aşamasıdır. ( Beta, Yunan alfabesinin ikinci harfidir ) İlk olarak, alfa testi terimi, yazılım geliştirme sürecinde testin ilk aşamasını ifade eder. İlk aşamada birim testi, bileşen testi ve sistem testi bulunur. Beta testi ise “yayın öncesi bir test” olarak değerlendirilebilir.

Beta testinin amacı, uygulamanızın nihai sürümünüzde yayınlamak istemeyeceğiniz kullanıcı bakış açısıyla ilgili kusurları veya sorunları bulmaktır. Bu sorunların bulunması için uygulamanın kendi mühendislik ekibi dışında olan gerçek kullanıcıların ellerine yerleştirilmesi gerekmektedir. Örnek: Microsoft ve diğer birçok kuruluş, kullanıcıların test etmesi için beta sürümlerini piyasaya sürdü.

Beta testinin avantajları:

Başvurunuzu genel halka yayınlamadan önce ilk kullanıcıların ellerine yayma ve deneme fırsatınız var.
Kullanıcılar, bu beta test döneminde uygulamayı yükleyebilir, uygulamanızı test edebilir ve size geri bildirim gönderebilir.
Beta test kullanıcıları, uygulamanızla ilgili kafa karıştırıcı uygulama akışı ve hatta çökmeler gibi fark etmemiş olabileceğiniz sorunları keşfedebilir.
Bu kullanıcılardan aldığınız geri bildirimleri kullanarak, sorunları herkese açık hale getirmeden önce düzeltebilirsiniz.
Gerçek kullanıcı sorunlarını çözen daha fazla sorun olduğunda, genel kamuya açıkladığınızda uygulamanızın kalitesi o kadar yüksek olur.
Genel halka açık olduğunuzda daha kaliteli bir uygulamaya sahip olmak müşteri memnuniyetini artıracaktır.
Uygulamanızın erken uygulayıcıları olan bu kullanıcılar, uygulamanızla ilgili heyecan yaratacaktır.

6.8. Zorlama Testleri (Stress Test)

Stres testi, temel olarak iki testten oluşmaktadır. Bunlar yük (load) ve dayanıklılık / sağlamlık ( durability ) testleridir. Yük testleri, örneğin, “ilgili sistemde, saniyede ne kadar veri iletimi yapılır?”, “aynı anda en fazla kaç kullanıcıya hizmet verilebilir?” gibi soruların cevabını verir. Bu tarz ölçüleri bulabilmek için gerekli testleri manuel olarak yapmak nerdeyse imkânsızdır.

Dayanıklılık ise, daha çok donanımın dayanıklılığı ile ilgilidir. Havaların soğuk/sıcak ya da nemli/kuru olmasından dolayı ortaya çıkan durumlara bakar. Bu testler, genelde, silah sistemleri, uzun yolculuk araçları ve meteoroloji gibi gerçek zamanlı olarak kullanılan sistemlerde yapılır. Ayrıca, sistem aşırı koşullar altında çalışmaya başlayınca etkin hata yönetimine sahip olup olmadığını ve istenilen hata mesajlarını iletip iletmediğini kontrol eder.

Stres testi, sistemin satabildiğini ve güvenilirliğini test etmek için kullanılır. Bu testin asıl amacı; sistemin, çok ağır yük koşullarında ne kadar sağlam olduğunu belirlemek. Bu ağır yük koşullarında ortaya çıkan hataları idare edebiliyor mu? – buna bakmaktır. Bir sistemin anormal bir duruma uğradıktan sonraki davranışının analizini yaparak, sistemin eski haline dönmesini sağlamak. Bu esnada, duruma uygun hata mesajların verilmesi de sağlanmalıdır. Bir sistemin normal çalışma koşullarından daha zor koşullar altında nasıl çalıştığını gözlemleyen ve değerlendiren Stres testi, sistemin bu şekilde sıkıştığı durumlarda kendisini toparlayabileceğini görmek için yapılır. Örneğin, bir öğrenci bilgi sistemi olan bir sitede, ders kayıtları zamanında ya da bu tarz aşırı kullanıcı olduğu zamanlarda sistemin çökmemesi ve stabil çalışması için stres testi yapılmış olmalıdır. Aksi takdirde, sistemin bu tür zor ve anormal koşullarda çalışmasını durdurulabilir. Bu da çeşitli kayıplara (örneğin, para) neden olur.

İstemci-sunucu sistemine kullanılan Stres testi şu şekilde çalışır:

Stres sunucusu tüm istemcilere stres testini uygular ve buna göre, müşterilerin davranışlarını inceler. Stres sunucusu, kendisine bağlantıyı kuran her istemciye test için gerekli verileri sırasıyla gönderir. Eğer istemciden yanıt sinyalleri gelmez ise, sistemde bazı hataların olduğu ve onların düzeltilmesinin gerektiği görülür.

Stres testi çeşitleri söyle listelenebilir:

Uygulama Stres Testi: Bu test türü, bir uygulamadaki verilerin engellenmesi ve / veya kilitlenmesi ile ilgili kusurları bulma üzerine yöneliktir. Bununla birlikte, ağ sorunları ile performans sorunlarındaki kusurları da bulmaya çalışmaktadır.

İşlemsel Stres Testi: Birden fazla uygulama arasındaki birden çok işlem sayısı üzerinde stres testinin uygulanmasıdır. Genellikle, sistemin optimizasyonu üzerine yoğunlaşan bir testtir. Sistemik Stres Testi: Bu test, aynı sunucu üzerinde çalışan ve birçok sistemde test edilebilen bir entegre stres testidir. Bir uygulamanın verisi başka bir uygulamanın çalışmasını engellediği zaman ortaya çıkan kusurlarla hataları bulmaya yönelik bir testtir.

Keşif Stres Testi: Bu stres test türü ise, gerçek bir senaryoda gerçekleşmesi çok zor olan olağandışı parametreler ve olağandışı durumlar ile sistem testini yapmak için kullanılan bir testtir. Bu testler, aynı anda tüm makinelere bir virüsün bulaşması, bir web sitesinden erişilmeye çalışılan veri tabanının kapalı durumuna geçmesi, veri tabanına aynı anda çok büyük bir miktarda verilerin eklenmesi gibi beklenmeyen durumlarda ortaya çıkan kusur ve hataları bulmak amacıyla kullanılan testlerdir.

6.9. Yazılım Sistem Güvenliği Testleri

Yazılım güvenliği bileşenleri, sisteme veya sistemin bölümlerine yetkisiz erişimleri engellemek, yetkisiz erişimleri ve yapılan sızma testleri tespit etmek ve yetkisiz sızma testlerinin meydana getirdiği zararları onarmayı hedeflemektedir.

Yazılım güvenliği bileşenlerinin yaptığı temel ve genel işlemler şu şekildedir:

Sistemin arızalanma durumu olasılığına karşı, kurtarmanın yapılabilmesi için gerekli olan yedekleri denetlemektedir.Yapılan işlemler, erişim denemeleri ve sistem kullanımı gibi bilgilerin kaydını tutmaktadır ( logging ).

.10. Sızma (Penetration) Testi

Penetrasyon testi, sistemin veya uygulamanın güvenli olmayan alanlarını test etmek için kullanılan bir Güvenlik Testi türüdür. Bu sınamanın amacı, sınanmakta olan sistemde bulunan tüm güvenlik açıklarını bulmaktır. Güvenlik açığı, bir saldırganın sisteme veya içerdiği herhangi bir veriye izinsiz erişimini veya erişimini ele geçirme riskidir. Ayrıca sızma testi veya pen test olarak da adlandırılır.

Güvenlik açıkları (ya da zafiyetleri) genellikle yazılım geliştirme ve uygulama aşamasında kaza ile ortaya çıkar. Yaygın olan güvenlik açıkları – tasarım hataları, yapılandırma hataları, yazılım hataları vb.

Seçilen penetrasyon testinin tipi genellikle kapsama ve organizasyonun / kuruluşun bir çalışanının, Network Admin’inin (Dahili Kaynaklar) veya Harici Kaynakların bir saldırısını simüle etmek isteyip istemediğine bağlıdır. Üç tip Penetrasyon testi vardır ve bunlar aşağıdaki gibidir:

Kara Kutu Testi ( Black box testing )Beyaz Kutu Penetrasyon testi ( White box testing )Gri Kutu Penetrasyon Testi ( Grey box testing )

Kara kutu penetrasyon testinde, test cihazının test edilecek sistemler hakkında bilgisi yoktur. Hedef ağ veya sistem hakkında bilgi toplamaktan sorumludur.

Beyaz kutu penetrasyon testinde, test cihazı genellikle IP adresi şeması, kaynak kodu, işletim sistemi detayları, vb. dâhil olmak üzere test edilecek ağ veya sistemlerle ilgili eksiksiz bir bilgi ile sağlanır. Bu, bir saldırının simülasyonu olarak düşünülebilir. Herhangi bir dâhili kaynak ( Kuruluşun Kendi Çalışanları ) tarafından gerçekleştirilen bir test olarak düşünülebilir.

Gri kutu penetrasyon testinde, test cihazının kısmi bilgisi ile sağlanır. Bir kuruluşun ağ altyapısı belgelerine gayri meşru erişim kazanmış harici bir saldırgan tarafından bir saldırı olarak kabul edilebilir.

Sızma testini gerçekleme aşamaları

Planlama aşaması
1. Görevin Kapsamı ve Stratejisi belirlenir
2. Mevcut güvenlik politikaları, kapsamı tanımlamak için standartlar kullanılır
Keşif aşaması
1. Sistemdeki veriler, kullanıcı adları ve hatta şifreler dâhil olmak üzere sistem hakkında mümkün olduğunca fazla bilgi toplayın. Bu aynı zamanda FINGERPRINTING olarak adlandırılır
2. Portların taranması ve kullanılmaya denenmesi
3. Sistemin güvenlik açıklarının kontrol edilmesi
Saldırı Aşaması
1. Sistemden ele geçirmek için önemli güvenlik yetkilerinin kullanılabileceği çeşitli güvenlik açıkların bulunması.
Raporlama Aşaması
1. Rapor ayrıntılı bulgular içermelidir
2. Güvenlik açıklarının riskleri ve iş üzerindeki etkileri
3. Öneriler ve çözümler, eğer varsa

Penetrasyon testindeki asıl görev, sistem bilgilerini toplamaktır. Bilgi toplamak için iki yol var:

Sunucuya göre ‘bire bir’ ( ‘one to one’ ) veya ‘bire çok’ ( ‘one to many’ ) model: Bir test cihazı, ya bir hedef ana bilgisayara ya da hedef ana bilgisayarların (ör. Bir alt ağ) mantıksal gruplamasına karşı doğrusal bir şekilde teknikler gerçekleştirir.
‘Çoktan bire’ ( ‘many to one’ ) veya ‘çoktan çoğuna’ ( ‘many to many’ ) modeli: Test cihazı, bilgi toplama tekniklerini rastgele, hız sınırlamalı ve doğrusal olmayan şekilde yürütmek için birden çok ana bilgisayar kullanır.

Penetrasyon Testi, sistemdeki tüm güvenlik açıklarını bulamayabilir. Zaman, bütçe, kapsam… Penetrasyon Testlerinin beceri sınırlamaları vardır.

Penetrasyon testi yapılırken aşağıdaki yan etkiler olacaktır:

Veri Kaybı
Zaman alıcıdır
Maliyetleri artırır

Test cihazları gerçek bir bilgisayar korsanı gibi davranmalı ve uygulamayı veya sistemi test etmelidir. Ayrıca, kodun güvenli bir şekilde yazılıp yazılmadığını kontrol etmelidir. İyi uygulanmış bir güvenlik politikası varsa, bir penetrasyon testi etkili olacaktır. Penetrasyon testi politikası ve metodolojisi, penetrasyon testini daha etkili hale getirecek bir yer olmalıdır.

6.11. Güvenlik Açığı Değerlendirilmesi (Vulnerability Assessment)

Bir güvenlik açığı, sistem güvenlik prosedürlerinde, tasarımında, uygulamasında veya sistemin güvenlik politikasının ihlali ile sonuçlanabilecek herhangi bir iç denetimde meydana gelen herhangi bir hata veya zayıflıktır. Diğer bir deyişle, güvenlik açıkları izinsiz erişim için izinsiz giriş yapma olasılıklarıdır.

İzinsiz erişim tarzındaki olayların olasılığını azaltmak için sistemde yer alan risklerin ani artışını değerlendirmek amacıyla gerçekleştirilen bir yazılım test tekniğidir Güvenlik Açığı Değerlendirmesi. İstenmeyen olayların azaltılması şu iki mekanizmaya bağlıdır:

1. Güvenlik Açığı Değerlendirmesi
2. Penetrasyon ( ya da Sızma ) Testi

Bu güvenlik açıkların değerlendirilmesinin yapılma gereği nedenleri şu şekildedir:

Kurum güvenliği için önemlidir.Güvenlik sorunlarının tespit edilmesi ve çözülmesini sağlayan güvenlik açıklarını bulma işlemi ve raporlama işlemi, bu güvenlik açığından yararlanılmadan önce güvenlik açıklarını bulup listeler. Başka bir ifadeyle, saldırı gerçekleşmeden önce güvenlik açığı olduğuna dair raporlama yapılır.Bu süreçte, uygunsuz yazılım tasarımı, güvenli olmayan kimlik doğrulama vb. gibi güvenlik açıklarının ortaya çıkmasını sağlamak için işletim sistemleri, uygulama yazılımları ve ağ taranır.

Güvenlik açığı değerlendirme süreci şu şekilde ilerlemektedir:

Hedefler ve Amaçlar – > Kapsam – > Bilgi Toplama – > Zafiyet Tespiti – > Bilgi Analizi ve Planlama

1. Hedefler ve Amaçlar: – Güvenlik Açığı Analizinin amaçlarını ve hedeflerini tanımlar.

2. Kapsam: – Değerlendirme ve Test yapılırken, Değerlendirmenin Kapsamı açıkça tanımlanmalıdır.

Aşağıdaki üç olası kapsam vardır:

Kara Kutu Testi:
– İç ağ ve sistemler hakkında önceden bilgi sahibi olmadan harici bir ağdan test etme.

Gri Kutu Testi:
– Dahili ağ ve sistem bilgisi ile harici veya dahili ağlardan test etme. Hem Kara Kutu Testi hem de Beyaz Kutu Testi’nin birleşimidir.

Beyaz Kutu Testi:
– İç ağ ve sistem bilgisi ile iç ağda test etme. Dahili Test olarak da bilinir.

3. Bilgi Toplama: – Ağlar, IP Adresi, İşletim Sistemi Sürümü, vb. gibi Bilgi Teknolojileri ortamı hakkında çok fazla bilgi edinme işlemidir. Kara Kutu Testi, Gri Kutu Testi ve Beyaz Kutu Testi gibi üç tür Kapsam için de geçerlidir.

4. Zafiyet Tespiti: – Bu süreçte, güvenlik açığı tarayıcıları kullanılır, Bilgi Teknolojileri ortamını tarar ve güvenlik açıklarını tespit eder.

5. Bilgi Analizi ve Planlama: – Belirlenen güvenlik açıklarını analiz eden, ağa ve sistemlere girmeye yönelik bir plan tasarlama aşamasıdır.

Güvenlik açığı değerlendirmesinin avantajları aşağıda verilenlerdir:

Açık kaynak araçları mevcuttur.
Neredeyse tüm güvenlik açıklarını tanımlar.
Taramayı otomatik yapabilir.
Düzenli olarak çalıştırmak için kolaydır.

Güvenlik açığı değerlendirmesi dezavantajları ise şunlardır:

False positive oranı yüksektir.
Saldırı Tespit Sistemi (Intrusion Detection System), Güvenlik Duvarı (Firewall) tarafından kolayca tespit edilebilir.
Çoğu zaman en son güvenlik açıklarını fark edemez.

Güvenlik açığı tarayıcı çeşitleri aşağıdaki gibidir:

Makine ( Ana Bilgisayar ) Tabanlı ( Host Based ) :

Ana bilgisayardaki veya sistemdeki sorunları tanımlar.
İşlem, sunucu tabanlı tarayıcılar kullanılarak gerçekleştirilir ve güvenlik açıkları tespit edilir.
Ana bilgisayar tabanlı araçlar, hedef sisteme bir aracı yazılım yükler. Böylece olayları izler ve güvenlik analistine bildirir.

Ağ Tabanlı ( Network Based ) :

Açık bağlantı noktasını algılayacak ve bu bağlantı noktalarında çalışan bilinmeyen hizmetleri tanımlar.
Daha sonra, bu hizmetlerle ilişkili olası güvenlik açıkları bulur. Bu işlem ağ tabanlı tarayıcılar kullanılarak yapılır.

Veritabanı Tabanlı ( Database Based ) :

SQL enjeksiyonlarından korunmak için araçlar ve teknikler kullanarak veritabanı sistemlerinde güvenlik açıklarını belirler. (SQL enjeksiyonları: – Veritabanındaki hassas verileri okuyabilen ve veritabanındaki verileri güncelleyebilen kötü niyetli kullanıcılar tarafından SQL deyimlerinin veritabanına enjekte edilmesi işlemidir. )
Güvenlik açığı taraması için kullanılabilen araçlar aşağıdaki Tablo 2’de listelenmiştir.
Tablo 2 Zafiyet Değerlendirilmesi ile Sızma testlerinin karşılaştırılması

Karşılaştırma Kısıtları	Zafiyet Değerlendirilmesi (Vulnerability Assessment)	Sızma Testi (Penetration testing)
Çalışma	Güvenlik açıklarını keşfeder.	Güvenlik açıklarını tanımlar ve kullanır.
Mekanizma	Keşif ve tarama	Simülasyon
Odak Nokta	Derinlik üzerinde genişlik	Genişlik üzerinde derinlik
Tamlık Kapsamı	Yüksek	Düşük
Maliyet	Orta – Düşük	Yüksek
Gerçekleştiren Kişiler	Evde çalışanlar	Saldırgan veya pentest uzmanları
Testçi Bilgisi	Yüksek	Düşük
Ne Sıklıkta Çalışır?	Tüm araçlar yüklendikten sonra	Yılda bir kez
Sonuç	Güvenlik açıkları hakkında kısmi ayrıntılar verir.	Güvenlik açıklarının tüm ayrıntılarını elde eder.

Güvenlik Açığı Testi, Güvenlik Açığı Değerlendirmesi ve Sızma Testi olmak üzere iki mekanizmaya bağlıdır. Her iki test, yaptıkları güç ve görevler bakımından birbirinden farklıdır. Bununla birlikte, Güvenlik Açığı Testi ile ilgili kapsamlı bir rapor elde etmek için, her iki prosedürün kombinasyonu önerilir.

6.12. Kullanılabilirlik (Usability) Testleri

Verilen Tablo 1’de, Kullanılabilirlik testinin ikiye ayrıldığı görülmektedir: Eğitim kullanılabilirlik testi ve Operasyonel kullanılabilirlik testi.

Açıklamaları görmek için başlıklara tıklayınız.

Eğitim kullanılabilirlik testi

Bir sistemi çalıştırmada çok sayıda kullanıcı yer aldığında, test edilebilirlik gereksinimleri test gündemine eklenir. Eğitimin kullanılabilirliği kapsamı, yeni bir çalışanı eğitmek için gerekli olan kaynaklarla tanımlanır, başka bir deyişle, yeni bir çalışanın sistemle tanımlanmış bir düzeyde tanışması veya belirli bir saatlik üretim oranına ulaşması için kaç saat eğitim gerekir? Bu testlerin detayları, diğer tüm sistemler gibi, sistem özelliklerine, daha da önemlisi, çalışan özelliklerine dayanmaktadır. Testlerin sonuçları, gelişmiş kurslar ve takip, gelişmiş yönler veya yazılım sistemi operasyonu için daha da gelişmiş bir plana ilham vermelidir.

Operasyonel kullanılabilirlik testi

Bu sınama sınıfının odak noktası, operatörün üretkenliğidir, yani, sistem operatörlerinin düzenli olarak gerçekleştirdiği performansı etkileyen veya çoğunlukla birçok kullanıcıya hizmet veren bilgi sistemleri için uygulanan sistem yönleridir. Sistemin çalışmalarının, kullanıcıların verimliliğini önemli ölçüde etkileyebileceği durumlarda, bu testler büyük önem taşımaktadır. Bu testin uygulanması, temel olarak üretkenlik ile ilgilidir. Doğal olarak bu test, büyük bir kullanıcı grubu için temel mesleki araçlar olarak hizmet eden sistemler için son derece önemlidir.

Operasyonel kullanılabilirlik testleri, zaman çalışmalarıyla elle gerçekleştirilebilir. Verimlilik verilerine ek olarak, bu manuel testler (yüksek veya düşük) performans seviyelerine ilişkin nedenler hakkında bilgi verir ve iyileştirmeler için fikirleri başlatır. Doğru performans kayıtları, tüm kullanıcı aktivitelerinin değiştikleri sürece kaydeden otomatik takip yazılımı ile sağlanabilir. Bu türdeki yazılım paketleri, belirli etkinlik, zaman aralığı ve endüstri gibi farklı değişkenler için performans istatistikleri ve karşılaştırmalı rakamlar sağlar.

6.13. Kıyaslama (Benchmark) Testi

Kıyaslama ( benchmark ), bir ürün veya bir hizmet kalitesini değerlendirmek amacıyla kullanılan bir metrik, bir ölçü veya bir referans noktasıdır [29]. Bu metrik sayesinde, hangi ürünün veya hangi hizmetin seçilmesinin daha iyi olacağı gösterilmiş olur. Yani, diğer bir deyişle, bunun bir ürünün veya hizmetin kalitesini belirlemeye yardımcı olan bir standart olduğu söylenebilir. Örneğin, bir burs veren kurumunda, burs kazanmak isteyen bir öğrenciye burs verilme durumu bir kıyas ölçütüne göre gerçekleştirilmektedir. Kıyaslama için belirlenen not ortalaması, son beş yılda katıldığı olimpiyat yarışmaları ve / veya çeşitli diğer yarışmalarda kazandığı dereceler, ya da bir sosyal etkinliklere katılma sayısı, çeşitli katılım belgeler sayısı; belki de aile durumları vb. olabilir. Yazılım endüstrisinde de, yanı şekilde yazılım kalitesini değerlendirmek amacıyla bir yazılım ürününü veya hizmetini belirli kıyas ölçütlerine göre kıyaslanabilir.

Kıyaslama testi, belirli işlev için mevcut veya gelecekteki yazılım sürümlerinin temel olarak karşılaştırılabildiği, tekrarlanabilir ve ölçülebilir niceliksel sonuç kümesi sağlamak için yapılan bir test türüdür. Sistem Test Altında – System Under Test (SUT) olarak da bilinen yazılım veya donanım sisteminin performansını karşılaştırmak için kullanılan bir işlemdir. SUT, web tabanlı bir uygulama olabilir.

Kıyaslama tekrar edilebilir olmalıdır. Örneğin, yük testinin her yinelemesiyle, yanıt süreleri çok değişiyorsa, sistem performansı kıyaslanabilir. Farklı yük koşulları arasında tepki süresi sabit olmalıdır. Bir ölçüt ölçülebilir olmalıdır. Örneğin, kullanıcı deneyimi sayı olarak belirlenemez, ancak bir kullanıcı iyi bir kullanıcı arayüzü (UI) nedeniyle bir web sayfasında zaman harcayabilir.

Kıyaslama testleri, aslında sadece yazılım testlerinde değil, aynı zamanda donanım testlerinde de kullanılan testlerin bir türüdür.

Karşılaştırma testi aşağıdaki hizmetler için yapılabilir:

Tarayıcı uyumluluğu ( Browser compatibility )
Bozuk bağlantılar ( Broken Links )
HTML uyumluluğu ( Browser compatibility )
Yükleme zamanı ( Load Time )
Ulaşılabilirlik ( Accessibility )
Bağlantı popülerliği ( Link Popularity )

6.13.1. Kıyaslama Testinin Önemi

İş seviyesinde, benchmark testi şunları belirleme konusunda yardımcı olabilir:

Rakiplere göre web tabanlı bir uygulama ne kadar iyi performans gösteriyor?
Farklı müşteri türleri, bir sitenin yanıt süresini ve kullanılabilirliğini nasıl deneyimliyor?
Web sitelerinin standartlara uygun olmasını sağlar.
Sözleşmeli bir kararı vermeden önce başka üçüncü taraf hizmet sağlayıcıları değerlendirir.
Kaçınılması gereken hataları anlamaya izin verir.

6.13.2. Kıyaslama Testinin Aşamaları

Karşılaştırma Testinin dört aşaması vardır. Bunlar:

Planlama aşaması:

Standartları ve gereksinimleri belirleme ve öncelik sıralamasına sokma
Karşılaştırma ölçütlerini belirleme
Kıyaslama testi sürecini tanımlama

Analiz aşaması:

Kaliteyi iyileştirmek için hatanın ana nedenini belirleme
Test süreci için hedef belirleme

Entegrasyon Aşaması:

İlgili kişi ile sonuçları paylaşma ve onay alma
Fonksiyonel hedefler belirleme

Eylem Aşaması:

Test planı ve dokümantasyon geliştirme
Önceki aşamalarda belirtilen eylemleri uygulama ve ilerlemeyi izleme
Süreci sürekli çalıştırma

6.13.3. Kıyaslama Testi Çerçeveleri (Framework)

Kıyaslama test çerçeveleri, performans kontrolü için bazı temel görevleri yerine getirmeye yardımcı olur. Bu temel görevler şunlardır:

Veritabanı Erişimi
Sunucu tarafı kompozisyonu
JSON Serileştirme
Yapılandırma

En çok kullanılan Kıyaslama çerçeveler – Benchmark Framework 2.0 ve TechEmpower isimli Benchmark test çerçeveleridir. TechEmpower’ın göze çarpan özellikleri şunlardır:

Kıyaslama görevleri gerçekleştirmek için açık kaynaklı bir çerçevedir.
Kıyaslama ortamının doğru yapılandırılmasına ihtiyaç duyar.
Sonuçların karşılaştırılması için Kıyaslama Modu ( Benchmark Mode ) ve uzman olmayanlar için Doğrulama Modu ( Verify Mode ) gibi iki modu vardır.
Eşsiz olan ve sisteme göre değiştirebilen birkaç dosya vardır.
Test talimatları seti ve benchmark programı için meta verileri tanımlayan ‘Benchmark Config File’ dosyasıni içerir.
Java, Python, Ruby, PHP, JavaScript, Perl, C, Groovy, Haskell, Scala vb. gibi birçok dile dayanmaktadır.
Veritabanlara erişimin sağlanması için, JSON Serileştirme vb. üzerinde test yapmak için Nesne – İlişkisel Haritalama ( Object – Relation Mapper – ORM ) teknolojisi kullanılmaktadır.

6.13.4. Kıyaslama Testinin Bileşenleri

Bir Kıyaslama testi yapılırken dikkat edilmesi gerekenler aşağıda madde halinde verilmiştir:

Tutarlılık ve kontrol, karşılaştırma testi yapmak için önemli önlemlerdir.
Test kriterlerini ve test verilerini tasarlamak için sistem mimarisini anlamak gerekir.
İlk statik verileri incelemek ve kullanıcı sayısına göre güncellemek gerekmektedir.
Gereken her yerde ‘Sıfırlama’ işlevi kontrol edilmeli ve ikinci işlem oranına göre tanımlanmalıdır.
Sistem elemanları işlevine göre ayırılmalıdır.
Her sistem farklı bir mimariye ve tasarıma sahiptir, bu da Benchmark Testini yaparken göz önünde bulundurulması gereken önemli bir durumdur.

Farklı sistemler farklı derecelerde karmaşıklığa sahiptir ve uygulamayı test etmek için farklı teknikler gerektirir. Benchmark testinin üç ana bileşeni vardır. Bunlar:

İş Yükü Özellikleri: Test edilen sisteme gönderilecek olan istek tipi ve sıklığını belirleme.
Metriklerin Özellikleri: Ölçülecek olan elemanların belirlenmesi. Örneğin; indirme hızı gibi.
Ölçümlerin özellikleri: Uygun değerleri bulmak için belirtilen elemanların nasıl ölçüleceğini belirleme

Başarılı bir benchmark testi yapmak için dikkate aşağıdakiler alınmalıdır.

Tüm yazılım bileşenlerinin çalışır durumda olduğundan emin olun.
İşletim sistemi ve destekleyici sürücüler doğru çalışmalıdır.
Karşılaştırma testini çalıştırmadan önce sistemden prefetch ve geçici dosyaları kaldırın.
Arka planda çalışan tüm işlemleri ve uygulamaları kapatın.
İşletim sistemi güncellemelerini ve yapılandırmalarını kontrol edin.

Kıyaslama testi için kullanılan araçlar şunlardır:

Windows işletim sisteminde kullanılabilecek kıyaslama araçları:

Prime95
NovaBench
3DMark
SiSoftware Sandra

CPU performansını test etmek için kullanılabilecek araçlar:

Cinebench
Geekbench
SuperPI

Sistemin hızı ve mobil cihaz pillerini test etmek için kullanılabilecek araçlar:

Phoronix ( Linux )
CPU – M ( CPU Benchmark Testi )
Vellamo ( Web tarama performansı )

Farklı makineler arasında kıyaslama testi yapmak için kullanılabilecek araçlar:

Everest Ultimate Edition
Fresh Diagnose

Böylece, kıyaslama (benchmark) testi, bir sistemin performansının ölçünümde önemli bir yer kapladığını görmüş olduk. Örneğin, DDoS ( Distributed Denial of Service (DoS) attack ) saldırısına karşı yük koşullarını ve sistem davranışını belirlemeye yardımcı olabilir. Kıyaslama testinin ana bileşenleri bunlardır: iş yükü özellikleri, metriklerin özellikleri ve ölçümlerin özellikleridir. Bu ölçme testlerinin hızlı ve verimli bir şekilde yapılması için çeşitli araçlar ve çerçeveler ( örneğin, TechEmpower Framework’ü ) kullanılır. Ayrıca, kıyaslama testleri mobil cihazlar için de kullanımaktadır.

6.14. Revizyon Testi

Anlatılan testler dışında, yazılım revizyon testi de mevcuttur. Yazılımın kolay bir şekilde revize edilmesi, bir yazılım paketinin başarılı, uzun hizmet ve daha büyük kullanıcı popülasyonlarına başarılı satışını garantileyen temel bir faktördür. Bu özellikler ile ilgili olarak, revizyon test sınıfları şu şekildedir:

Bakım yapılabilirlik testiEsneklik testiTest edilebilirlik testi

Bu testler dışında taşınabilirlik (portability), tekrardan kullanılabilirlik (reusability) ve birlikte çalışabilirlik (interoperability) testleri de yapılmaktadır. Bir yazılım testi araçları, planlama, gereksinimler, kurulumun yapılması, testin geçekleştirilmesi, kusurların kaydı ve test analizi gibi bir veya daha fazla test faaliyetini destekleyen bir ürün olarak tanımlanabilir.

6.15. Yazılım Test Sürecinde Sıkça Karşılaşılan Terimler Listesi

Aşağıda verilen terimler, test sürecinde ve gereksinimlerin analiz çalışmalarında sık kullanılan kelimelerdir. Bu deyimlere aşina olmanızda yardımcı olmak amacıyla aşağıdaki terimleri listesi verilmiştir. Bu terimleri dersi daha kolay anlamak için kullanabilirsiniz. Günümüzdeki birçok yazılım geliştirme üzerine çalışan ve / veya yazılım testi hizmeti veren şirketlerdeki teknikler (kullandıkları aşamalar, işler vs.) İngilizce isimlendirilmiş kelimeleri kullanmaktadırlar. Dolayısıyla, terimlerin önce İngilizce halleri daha sonra Türkçedeki karşılıkları verilmiştir.

Acceptance testing ( Kabul testi ): En son yapılan test türüdür. Geliştirilen uygulamanın yayınlanmasından önce, kullanıcıların bu sistemi kabul etme veya reddetmesi amacıyla yapılır.
Actual result ( Gerçek sonuç ) : Yapılan test sonucunda ortaya çıkan sistem durumu veya davranışı olarak bilinir. Bir anomali veya sapma durumları ise, gerçek sonuçların beklenen sonuçlardan farklı olduğu durumlardır.
Ad hoc testing ( Ad hoc testi ) : Testlerin resmi olarak gerçekleştirildiği durumdur. Artık test senaryoları veya diğer yazılı test talimatlarına gerek yoktur.
Agile development ( Çevik gelişme ) : Çevik modelinin uygulandığı projelerdeki kısa yinelemelerde olan çalışmayı / gelişmeyi vurgulayan bir geliştirme yöntemidir. Genelde bu modelde otomatik testler kullanılır. Bu modeldeki gereksinimler ile çözümler, hem müşteri hem de tedarikçi taraflarını temsil eden ekip üyeleri arasındaki yakın bir işbirliği sayesinde gelişmektedir.
Alpha testing ( Alfa testi ) : Tarafsızlık oluşturabilmek için yapılan bir testtir. Alfa testini yapanlar sistemin geliştirilmesinde yer alan ekipten olmamalıdır. Potansiyel kullanıcılar, müşteriler veya bağımsız bir test ekibi tarafından gerçekleştirilir. Bazen, satıcı olan şirket, bu alfa testini kabul testi olarak kullanır.
Anomaly ( Anomali ) : Gereksinim özelliklerine, tasarım belgelerine, standartlara ve benzeri durumlara dayalı olan beklentilerden başka sonuçlar veren herhangi bir durum. Bu sapmaları (ya da anomalileri) bulmanın ver gidermenin iyi bir yolu yazılımı test etmektir.
· Beta testing ( Beta testi ) : Alfa testlerinden sonra gerçekleştirilen testtir. Beta testi, sistemi oluşturan kuruluşun dışındaki kişiler tarafından gerçekleştirilir. Beta testi değerli bir testtir, çünkü kullanılabilirlik kusurlarını ve yapılandırma sorunlarını bulmak için kullanılır.
· Big – bang integration ( Bing bang entegrasyonu ) : Bir entegrasyon testi stratejisidir. Entegrasyon (ya da tümleştirme) testi ise, sistemin her bileşeninin bir araya getirildiği ve bu bileşenlerin birlikte test edilmesidir. Sistem bileşenlerini her seferinde bir araya getiren diğer entegrasyon test stratejilerinden farklıdır Big – bang entegrasyonu.
· Black box testing ( Siyah kutu testi ) : Test edilen sistemin bir “kara kutu” olarak görülmesi, yani test edilmekte olan sistemin içyapısı ile ilgili bir bilgisi olmayan bir test sistemidir. “Beyaz kutu” testi ise, bu test sisteminin tam tersidir.
· Bottom up integration ( Aşağıdan yukarıya entegrasyon ) : Bir entegrasyon test stratejisidir. Bu strateji, sistem bileşenlerini, sistem mimarisinin en düşük seviyesinden en üst seviyesine doğru entegre etmeye başlayan bir entegrasyon testi stratejisidir.
· Boundary value analysis ( Sınır değer analizi ) : Bir “kara kutu” testi tasarım tekniğidir. Bir kenarın her iki tarafındaki izin verilen veya en küçük artımlı mesafenin kenarında bulunan giriş veya çıkış değerlerini test eden bir kara kutu testi tasarım tekniğidir. Örneğin, 1 ile 10 karakter arasında bir metni kabul eden bir giriş alanı altı sınır değerine sahiptir. Bu sınır değerleri 0, 1, 2, 9, 10 ve 11 karakterleridir.
· BS 7925 – 1: Test terimleri sözlüğü içeren bir test standartları belgesidir. BS, British Standard ( İngiliz Standardı ) anlamına gelir.
· BS 7925 – 2: Öncelikle bileşen testine odaklanan test sürecini tanımlayan bir test standartları belgesidir. BS, British Standard ( İngiliz Standardı ) anlamına gelir.
· Bug: Hata, kusur gibi terimler için yazılımda kullanılan farklı bir kelime olarak bilinir.Başlangıçta bilgisayarların önündeki mekanik cihazlarda arızalara neden olan fiili böcekleri tanımlamak için kullanılmıştır. Uluslararası Yazılım Test Yeterlilikler Kurulu (ISTQB) sözlüğünde “bir insanın program kodunda veya bir belgede bir hata üreten bir kusur oluşturabileceğini” açıklamaktadır. Koddaki bir hata yürütüldüğünde, sistem yapması gerekenleri yapamaz veya olmaması gereken bir şey yapar. Bu durumda bir arıza veya kusur meydana gelebilmektedir. Yazılımdaki, sistemdeki veya belgelerindeki kusurlar hatalarla sonuçlanabilir, ancak tüm kusurlar bunu yapmaz.

· Capture / playback tool ( Yakalama / oynatma aracı ) : Kayıt ve Oynatma araçları, tarayıcıya bir uzantı ekleyerek veya bir yazılım parçasını cihaza yükleyerek çok fazla gecikme yapmadan teste başlama imkânı sağlamaktadır. Ancak, bir değişiklik yapıldığında uygulamanın tüm özelliklerinin düzenlenmesi ve yeniden kaydedilmesi için harcanan zaman gereği tüm durumlar tehlikeye girer.

· CAST: Otomatik test araçları için kullanılan genel bir terimdir. Bilgisayar destekli yazılım testi ( Computer Aided Software Testing ) için kısaltma olarak kullanılmaktadır.

· Change control board ( Kontrol değişim heyeti ) : Bir Bilgi Teknolojileri ( BT ) sistemindeki istenen değişiklikleri değerlendirmek, önceliklendirmek, onaylamak ve reddetmekle sorumlu bir gruptur.

· Change request ( Değişiklik isteği ): Sistem üzerinde gerekli veya istenen bir değişikliğin yapılmasını açıklayan bir belge türüdür.

· Checklist ( Kontrol Listesi ): Daha basit bir test vakası formudur. Genellikle kısa test talimatlarından oluşmaktadır. Kontrol listelerinin bir avantajı, geliştirilmelerinin kolay olmasıdır. Dezavantajı ise; test durumlarından daha az yapılandırılmış olmalarıdır. Kontrol listeleri test durumlarını iyi bir şekilde tamamlayabilir. Keşif testinde, test senaryoları yerine kontrol listeleri kullanılır.

· CMMI: Capability Maturity Model Integration ( Yetenek Olgunluk Modeli Entegrasyonu ) kısaltılmasıdır. Sistem geliştirme ve bakımda süreç verimliliğini geliştirmek için kullanılan bir araçtır.

· Code coverage ( Kod kapsamı): Test tarafından yürütülen bir sistemdeki kodun oranını ölçen analiz yöntemleri için genel bir terimdir. Yüzde olarak ifade edilir, örneğin% 90 kod kapsamı gibi.

· Code standard ( Kod standardı ): Bir programlama dilinin bir kuruluşta nasıl kullanılmasının açıklaması durumudur.

· Compilation ( Derleme): İnsan tarafından okunabilir bir programlama dilinde yazılan kod satırlarının bilgisayar tarafından çalıştırılabilen makine koduna çevrilmesidir.

· Component ( Bileşen ): Sınıf veya bir Dinamik Link Kütüphanesi (Dynamic Link Library DLL ) gibi sistemin en küçük öğesidir.

· Component integration testing ( Bileşen entegrasyon testi ): Entegrasyon testi için kullanılan bir başka terimdir.

· Component testing ( Bileşen testi ): Sistemin en küçük elemanlarını değerlendiren test seviyesidir. Birim testi, program testi ve modül testi olarak da bilinir.

· Configuration management ( Konfigürasyon yönetimi ): Belgeleri ve yazılım kodunun sürüm kontrolünü takip eder. Ayrıca çoklu sistem sürümlerini yönetmeye yarar.

· Configuration testing (Konfigürasyon testi): Sistemin farklı tarayıcılar kullanarak bir web sitesinin test edilmesi gibi farklı donanım ve yazılım yapılandırmalarında çalıştığını onaylayan bir test tekniğidir.

· Context driven testing ( İçerik odaklı test ): Gerçek kullanım koşullarından esinlenen hata ayıklama tekniklerini kullanan testlerdir. Test kullanıcılarının, belirli bir durumun çok özel ayrıntılarına dayanarak test fırsatlarını geliştirmelerini teşvik eden bir test metodudur.

· COST: Commercial Off the Shelf kısaltılmasıdır. Açık pazarda satın alınabilen yazılım. Ayrıca paketlenmiş yazılım olarak da adlandırılır.
· Daily build ( Günlük derleme ): Günlük test yapmaya izin vermek için test nesnesinin her gün derlendiği bir süreçtir. Hata raporlarının erken ve düzenli olarak raporlanmasını sağlarken, otomatik test desteği gerektirir.
· Debugging ( Hata ayıklama ): Geliştiricilerin bulunan hataları tanımladığı, teşhis ettiği ve düzelttiği süreçtir.
· Decision table ( Karar tablosu ): Bir test tasarımı ve şartname tekniği olarak bilinir. Bir karar tablosu, bir sistem için mantıksal koşulları ve kuralları açıklar. Test cihazları, tabloyu test senaryoları oluşturmak için temel olarak kullanır.
· Defect ( Kusur ): Bileşen veya sistemde gerekli işlevi yerine getirememesine neden olabilecek bir aksaklık olarak bilinmektedir. Bir kusur, yürütme sırasında karşılaşılırsa, bileşen veya sistemde bir arızaya neden olabilir.
· Defect report ( Kusur raporu ): Bir bileşen, sistem veya tasarımda bir kusuru bildirmek için kullanılan bir raporlama belgesidir. Bir olay raporu olarak da bilinir.
· Deliverable ( Teslimi mümkün ): Ürünün yazarı dışındaki birine teslim edilmesi gereken herhangi bir üründür. Teslim edilebilir örnekler dokümantasyon, kod ve sistemdir. Teslim edilmesinde bir sakınca yoktur.
· Desk checking ( Masa kontrolü ): Test sorumlusunun kod veya bir şartnamede okuduğu ve aklında yürütülen bir statik test tekniğidir.
· DSDM: Dynamic Systems Development Method kısaltılmasıdır. Yinelemeli bir gelişim yaklaşımıdır.
· Dynamic testing ( Dinamik test ): Sistem çalışırken test işleminin gerçekleştirilmesidir. Test vakalarının yürütülmesi dinamik test için güzel bir örnektir.

· End to end testing ( Uçtan uca test ): Bir uygulamanın baştan sona kadar performansının kendisinden beklenen davranışa uygun olup olmadığını sınamak için kullanılan test olarak bilinir. Bu test tekniği, sistem bağımlılıklarını tanımlamak ve farklı sistem bileşenleri arasında kalan veri aktarımının bütünlüğünü doğrulamak için kullanılmaktadır.

· Entry criteria ( Giriş kriterleri ): Test senaryolarını ve test planlarını tamamlandıktan sonra testi başlatabilmek için yerine getirilmesi gereken kriterler giriş kriterleri olarak bilinir.

· Equivalence partitioning ( Eşit bölümlere ayırma ): Bir sistemdeki verilerin aralıklarla bölmede olduğu gibi sınıflara bölünerek yönetilmesine dayanan bir test tasarım tekniğidir. Bu test tekniğinde, her denklik sınıfında sadece tek bir değeri test etmeniz gerekir. Örneğin, bir hesap makinesinin tüm ekleme işlemlerini aynı şekilde gerçekleştirdiğini varsayalım. Bu durumda bir ekleme işlemini test edilirse, tüm denklik sınıfını test edilmiş olur.

· Error ( Hata ): Yanlış bir sonuç üreten bir insan eylemidir.

· Error description ( Hata tanımlaması ): Test cihazının gerçekleştirdiği test adımlarını, sonucun ne olduğunu, hangi sonuca ulaştığını ve sorun gidermede yardımcı olacak ek bilgileri açıkladığı bir hata raporunun bölümüdür.

· Error guessing ( Hata tahmini ): Test cihazının beceri ve sezgisine dayanarak test senaryoları geliştirdiği deneyime dayalı test tasarım tekniğidir.

· Execute ( Gerçekleştirmek ): Bir başka deyişle programın koşması veya yürütülmesidir. Bir program yürütüldüğünde, programın çalıştığı anlamına gelir. Bir test vakası yürütüldüğünde veya koşturulduğunda, test vakası çalıştırılmış olur.

· Exhaustive testing ( Yorucu test ): Tüm olası giriş ve çıkışların test edildiği bir test yaklaşımıdır.

· Exit criteria ( Çıkış kriteri ): Tüm yüksek öncelikli test vakalarının yürütülmesi ve açık yüksek öncelikli kusurun kalmaması gibi testin tamamlanmış olarak değerlendirilmesi için gerekli olan kriterlerdir. Aynı zamanda tamamlama kriterleri olarak da bilinir.

· Expected result ( Beklenen sonuç ): Test adımı tamamlandıktan sonra test nesnesinin beklenen durumu veya davranışının bir açıklamasıdır. Test vakasının en önemli bir parçasıdır.

· Exploratory testing ( Keşif testi ): Test cihazının deneyimini temel alan bir test tasarım tekniğidir. Test cihazı, sistemi tanıyıp testleri yürütürken test durumlarını yaratıp testi gerçekleştirir.

· External supplier ( Dış tedarikçi ): Tedarikçinin müşteri ile aynı kuruluşta olmaması durumudur.

· Extreme programming ( Aşırı programlama ): İki geliştiricinin program kodunu birlikte yazdığı ikili programlamanın önemini vurgulayan çevik bir geliştirme yöntemidir. Bu metodoloji sık teslimatlar ve otomatik testler gerektirmektedir.

Factory acceptance test ( Fabrika kabul testi ): Müşterinin sisteminde ve müşterinin kendisinin katılımıyla yapılan kabul testinin aksine, tedarikçinin tesisinde gerçekleştirilen kabul testlerine verilen isimdir. FAT (Factory Acceptance Test) kısaltılmış halidir.
Failure ( Başarısızlık ): Test edilen bileşen veya sistemin beklenen sonuçtan sapmasıdır.
Fault Injection ( Hata Enjeksiyonu ): Farklı kod yollarını, özellikle hataları işleyen ve gözlemlemek imkânsız olanları test etmek için hatalı kasıtlar yerleştirerek test kapsamını geliştirmek için kullanılan bir test tekniğidir.
Formal review ( Resmi inceleme ): Toplantıları, resmi rolleri, gerekli hazırlık aşamalarını ve hedefleri gözden geçirebilecek bir belge inceleme sürecine göre ilerleyen bir gözden geçirme sürecidir. İnceleme, resmi bir gözden geçirme tekniğine örnektir.
Functional integration ( Fonksiyonel entegrasyon ): Sistemin bir seferde bir işlevi entegre ettiği bir tümleştirme testi stratejisidir. Örneğin, “müşteri arama” fonksiyonu için gereken tüm bileşenler bir araya getirilerek tek tek test edilir.
Functional testing (Fonksiyonel test ): Sistemin işlevselliğini ve davranışını test etmedir. Fonksiyonel olmayan testlerin tersidir.

Gray box testing ( Gri kutu testi ): Test cihazının bilgisi sınırlı olan bir sistemde yazılım hata ayıklama işlemini gerçekleştirmek için beyaz kutu ve kara kutu test tekniklerinin bir kombinasyonunu kullanan test tekniğidir.

· IEEE 829: IEEE organizasyonu tarafından yayınlanan test belgeleri için uluslararası bir standarttır. Standardın tam adı Yazılım Test Belgeleri için IEEE standardıdır. Test planı, çeşitli test raporları ve teslim belgeleri için şablonlar içerir.

· Impact analysis ( Etki analizi ): Bir değişikliğin etkisini değerlendiren tekniklerdir. Gerekli regresyon testlerinin seçimini ve kapsamını belirlemek için kullanılır.

· Incident ( Olay ): Beklenenlerden farklı bir durumun görülmesi durumudur. Gerekliliklerden veya test durumlarından bir sapmanın meydana gelmesidir.

· Incident report ( Olay raporu ): Kusur raporu ( Defect report ) gibi düşünülebilir.

· Independent testing ( Bağımsızlık testi ): Tarafsızlıklarını sürdürebilmek için test edenin sorumluluklarının ayrıldığı bir tür test tekniğidir. Bunu yapmanın bir yolu, farklı testlere farklı roller verilmesidir. Sistemi farklı bakış açılarından test etmek için farklı test senaryoları kullanılmaktadır.

· Informal review ( Gayri resmi inceleme ): Test esnasında resmi bir prosedüre dayanmayan incelemeye denir.

· Inspection ( Teftiş ): Resmi bir gözden geçirme tekniği örneğidir.

· Installation test ( Kurulum testi ): Sistemin kurulum ve kaldırma gerekliliklerini karşılayıp karşılamadığını değerlendirmek anlamına gelen bir test türüdür. Bu test işlemiyle, doğru dosyaların bilgisayara kopyalanıp kopyalanmadığı ve uygulama menüsünde bir kısayol oluşturulup oluşturulmadığı kontrol edilmeye çalışılır.

· Instrumentation code ( Enstrümantasyon kodu ): Kodun yürütülmesi sırasında sistemin davranışıyla ilgili bilgileri izlemeyi sağlayan koddur. Örneğin, kod kapsamı ölçülürken bu tarz kodlar kullanılır.

· Integration testing ( Entegrasyon testi ): Bir test seviyesidir. Sistemin bileşenlerinin birbiriyle çalıştığını göstermek için kullanılmaktadır. Bu testin amacı, ara yüzlerde problemler ve bileşenler arasındaki iletişimi bulmaktır.

· Internal supplier ( İç tedarikçi ): Geliştirici ile müşterinin aynı kuruluşa ait olması durumudur. Şirketlerin Bilgi Teknolojileri ( BT ) bölümü genellikle iç tedarikçidir.

· ISTQB: International Software Testing Qualifications Board’ın kısaltılmasıdır. Test mühendisliği üzerine sertifika almak isteyenlerin sertifikasyon işlemleri için uluslararası programlardan ISTQB sorumludur.

· Iteration ( İterasyon ): Bir BT sisteminin bir kısmının sunulmasından, gereksinimlerin formüle edilmesine kadar bir dizi aşamadan oluşan bir geliştirme döngüsü olarak adlandırılır. İterasyon içerisinde ortak aşamalar analiz, tasarım, geliştirme ve testtir. Yinelemelerde (iterasyonlarda) çalışma pratiği tekrarlı gelişim olarak adlandırılır.
JUnit: Java programlama dilindeki bileşenlerini otomatik olarak test etmeye yarayan bir kütüphanedir ( framework ).

Load testing ( Yük testi ): Bir bileşenin veya sistemin davranışının, örneğin yükün artmasıyla birlikte davranışını değerlendirmek için gerçekleştirilen bir tür performans testidir. Bir sistemin eşzamanlı kullanıcı sayısı, belirli bir zamanda yapılan işlem sayısı parametreleri yük testine örnek verilebilir. Bileşen veya sistem tarafından hangi yükün kullanılabileceğini belirlemek için kullanılır. Bir başka ifadeyle sistem hangi aşamaya kadar cevap verebiliyor bunun ölçülmesi hedeflenmektedir.

Maintainability ( Bakım kolaylığı veya bakılabilirlik ): Belirli bir yazılım kodu parçasının kusurlarını düzeltmek, iyileştirmek veya işlevselliği arttırmak için ne kadar kolay değiştirileceğinin bir ölçütüdür.
Maintenance ( Bakım ): Yazılım ürününün piyasaya sürüldükten sonra bir sistemi yönetmeye yönelik faaliyetlerdir. Ürünün kusurlarını düzeltmek ya da işlevselliği arttırmak ya da ürüne yeni eklentiler eklemek bunlara örnek olarak verilebilir.
Module testing ( Modül testi ): Sistemin en küçük elemanlarını değerlendiren test seviyesidir. Birim testi, program testi ve olarak da bilinir. Ayrıca bileşen testi de kullanılmaktadır.
MTBF: Mean Time Between Failures’ın kısaltmasıdır. Bir sistemin veya arızaları arasındaki ortalama süreye denir.

Naming standard ( Adlandırma veya isimlendirme standardı ): Değişkenler, işlevler ve benzeri gibi bir programın diğer bölümleri için ad oluşturma standardı olarak bilinir. Örneğin strAdı, sAdı ve Adı bir değişken için teknik olarak geçerli isimler olabilmektedir. Ancak projenin geliştirilmesi esnasında standart olarak bir yapıya uyulmuyorsa, projenin bakımı çok zor olacaktır.
Negative testing ( Negatif test ): Doğru kullanılmasa bile sistemin iyi çalıştığını göstermeyi amaçlayan bir test türüdür. Örneğin, kullanıcı sayısal bir alana metin girerse, sistem çökmemelidir.
Non-functional testing ( İşlevsel olmayan test ): Kullanılabilirlik, güvenilirlik, sürdürülebilirlik ve performans gibi sistemin işlevsel olmayan yönlerinin test edilmesidir. Fonksiyonel testin tam tersidir.
NUnit: Microsoft. Net uygulamalarındaki bileşenlerin otomatik testi için açık kaynaklı bir kütüphanedir.

Open source ( Açık kaynak ): Yazılımın ücretsiz olarak sunulduğu bir lisans şeklidir. Açık kaynaklı yazılımlar, www.sourceforge.net adresinden indirilebilir. Birçok açık kaynaklı yazılım test aracı da mevcuttur.
Operational testing ( Operasyonel test ): Sistem işletim sistemi ortamında veya simüle edilmiş operasyonel ortamda kurulduğunda veya başka şekilde canlıya alınıp hazır olduğunda yapılan testlerdir. Sistemin operasyonel yönlerini test etmek amaçlanmaktadır. Örneğin geri kazanılabilirlik, diğer sistemlerle birlikte çalışabilmeye uyum ve kaynak tüketimi örnek olarak gösterilebilir.
Outcome ( Sonuç ): Bir test vakası yapıldıktan sonra alınan sonuçtur.

Pair programming ( Eşli programlama ): Yeni bir sistem programlanırken iki geliştiricinin bir bilgisayara oturduğu bir yazılım geliştirme yaklaşımıdır. Bir geliştirici kodlama yaparken, diğeri ürün üzerinde yorumlar ve gözlemlerde bulunur. Sürekli kod gözden geçirilmesi olduğu için bu tekniğin daha yüksek kaliteye ulaştığı hakkında söylemler mevcuttur. Hataların kod yazılırken ekip tarafından yakalanması muhtemel olduğu için hatalar ve bugların görülmesi oldukça zordur.
Pair testing ( Eşli test ): İki kişinin test işlemi üzerinde çalıştığı test yaklaşımıdır. Örneğin iki testçi, bir geliştirici ve bir test cihazı veya bir son kullanıcı ve bir test cihazı kusurları bulmak için birlikte çalışarak test işlemi gerçekleştirilir.
Performance testing ( Performans testi ): Sistemin yanıt süresi veya işlem sıklığı gibi performans gereksinimlerini karşılayıp karşılamadığını değerlendirmek için yapılan bir test yaklaşımıdır.
Positive testing ( Pozitif test ): Test nesnesinin normal durumlarda doğru çalıştığını göstermeyi amaçlayan bir test yaklaşımıdır. Geçerli bir test verisi kullanılırken yeni bir müşteriyi kaydetme işleminin doğru çalıştığını gösteren bir test pozitif teste örnek olarak verilebilir.
Postcondition ( hedefşart ): Bir test veya test çalışması yapıldıktan sonra yerine getirilmesi gereken çevresel ve durum koşullarıdır.
Preconditions ( Ön koşul ): Bileşen veya sistem test edilmeden önce yerine getirilmesi gereken çevresel ve durum koşullarıdır. Teknik ortama veya test nesnesinin durumuna bağlı olabilir. Ön koşullar, test öncesi yapılan hazırlıklar olarak da bilinir.
Priority ( Öncelik ): Bir kusurun birden fazla sebebi olabilir. Bu nedenle kusura sebep olan her bir nedene önem skoru verilmelidir.
Professional tester ( Profesyonel testçi ): Tek işi test olan bir kişiye verilen adlandırmadır.
Program testing ( Program testi ): Bileşen ve modül testinin bir başka adlandırma şeklidir.

Quality ( Kalite ): Bir bileşenin, sistemin veya sürecin belirli gereksinimleri ve kullanıcı ihtiyaçlarını, beklentilerini karşılama derecesidir.
Quality assurance ( Kalite güvencesi ): Yazılım mühendisliği literatüründe QA olarak kısaltmasına çok yerde rastlanılmaktadır. Asgari kalite standartlarına ulaşma olasılığını en üst düzeye çıkarmak için bir bileşenin veya sistemin çeşitli yönlerinin sistematik olarak izlenmesi ve değerlendirilmesidir.

Record and playback tool ( Kayıt ve oynatma aracı ): Regresyon testinin otomasyonunu desteklemek için sıklıkla kullanılan test senaryolarının kaydedilmesi ve oynatılması için kullanılan bir test yürütme aracıdır. Yakalama / oynatma ( Capture / playback tool ) olarak da bilinmektedir.
Regression testing ( Regresyon testi ): Önceden kusurlar giderildiğinde ortaya çıkan veya keşfedilen kusurların tespit edilmesi için, genel olarak sistemin her yeni sürümü ile bağlantılı olarak yürütülen bir test faaliyetidir.
Release ( Yayımlama ): Test edilmiş kullanıma hazır bir sistemin yeni bir sürümünün çıkmasıdır. Yayımlama, geliştiricilerden test kullanıcılarına yapılan bir dâhili sürüm veya sistemin müşteriye bırakılması olabilir. Tüm sistemin yeni sürümlerini oluşturmak için tasarlanmış bir dizi etkinliğe yayımlama yönetimi adı verilmektedir. Her bir sürüm ayrı bir sürüm numarasıyla tanımlanır.
Release testing ( Yayımlama testi ): Sistem yeni bir hedef ortama kurulduğunda, kritik işlevleri herhangi birindeki detaylara girmeden doğrulamak için küçük bir test seti kullanılarak yapılan ve kapsamlı olmayan test türüdür. Ayrıca duman testi de denilmektedir. Duman testi denilmesinin sebebi, sistemin ateşe yakalanmadığı veya sigara içmediği sürece, testi geçtiğini söylemek için yazılım test literatüründe böyle denilmektedir.
Requirements management ( Gereksinim analizi ): Bir BT sistemi için ihtiyaçların toplanması, açıklanması, dokümantasyonu, önceliklendirilmesi, kalite güvencesi ve yönetimini kapsayan bir dizi faaliyetlere verilen isimdir.
Requirements manager ( Gereksinim yöneticisi ): Gereksinim yönetiminden sorumlu kişidir. Ayrıca gereksinim lideri veya iş analisti olarak da bilinir.
Re-testing ( Yeniden test): Önceden bildirilen bir kusurun veya hatanın düzeltildiğini doğrulayan bir teste denir.
Retrospective meeting ( Geriye dönük toplantı ): Bir projenin sonunda, ekip üyelerinin çalışmayı değerlendirdiği ve bir sonraki projeye veya süratle uygulanabilecek dersleri öğrenen bir toplantıya denilmektedir.
Review ( Gözden geçirme veya inceleme ): Projenin incelenmesiyle, kusurlarını bulmak ve iyileştirmeler önermek için bir metnin yapısal bir şekilde okunarak yapılmasıyla elde edilen statik bir test tekniğidir. İncelemeler, gereksinim analizi belgelerini, test doküman belgeleri, proje kaynak kodu ve diğer materyalleri kapsayabilir. Resmi veya resmi olmayandan incelemeler olabilir.
Reviewer ( eleştirmen ): Proje üzerinde incelenmede bulunan, öğedeki tutarsızlıkları tanımlayan, belgeleyen ve inceleme sürecine dâhil olan kişiye denir. Değerlendirme uzmanları, farklı uzmanlık alanları, paydaş grupları ve analiz türlerini temsil etmek için seçilmiştir.
Risk ( Risk ): Gelecekteki olumsuz sonuçlara yol açabilecek bir neden veya nedenlere risk denir. Genellikle etki ve olasılık olarak ifade edilir.
Risk based testing ( Risk tabanlı test ): Test durumlarının risklere göre seçildiği yapılandırılmış bir test yaklaşımıdır. Sınır değer analizi ve denklik bölümlemesi gibi test tasarım teknikleri risk temelli test tekniklerine örnek olarak verilebilir. Esasında tüm test teknikleri risk temelli olmalıdır.
RUP: Rasyonel Birleştirilmiş Süreç’in ( Rational Unified Process ) kısaltılmasıdır. IBM şirketinde kullanılmaktadır.

· Sandwich integration ( Sandviç entegrasyonu ): Yazılım sistemin hem yukarıdan aşağıya hem de aşağıdan yukarıya aynı anda birleştirilerek test edildiği bir entegrasyon testi stratejisidir. Bu birleştirme testinde zamandan tasarruf edilebilir, ancak karmaşıktır bir yapıdadır.

· Scalability testing ( Ölçeklenebilirlik testi ): İşlevsel olmayan testlerin bir bileşenidir. İşlevsel olmayan özelliklerine göre yazılımın kapasitesini yukarı veya aşağı ölçeklendirmek için kullanılır.

· Scenario ( Senaryo ): Sisteme giriş yapma, müşterinin sisteme kaydolması, ürün sipariş etme, fatura yazdırma ve benzeri gibi birçok olayın yazılacak sistemde olması durumunda gerçekleştirilen bir dizi etkinliktir. Özellikle yüksek test seviyelerinde senaryo oluşturmak için test senaryoları birleştirilmelidir.

· Scrum: Çevik yazılım geliştirmede yaygın olarak kullanılan proje yönetimi için yinelemeli, artımlı bir modelin oluşturulmasını sağlayan bir araçtır.

· Session based testing ( Oturum tabanlı test ): Test aktiviteleri kesintisiz ve oldukça kısadır. Test tasarımı ve yürütme seanslarının planlandığı test etme yaklaşımıdır. Genellikle keşif testi ile birlikte kullanılır.

· Severity ( önem derecesi ): Bir kusurun, bir bileşenin veya sistemin geliştirilmesi veya çalıştırılması üzerindeki etkisine denilmektedir.

· Site acceptance testing ( Site kabul testi ): Kısaltılmış hali SAT’tır. Kabul testi, geliştiricinin yerine, müşterinin bulunduğu yerde ve sisteminde gerçekleştirilir. Bunun tam tersi yani geliştiricinin sitesinde yapılan test, fabrika kabul testi (Factory Acceptance Testing ( FAT ) ) olarak adlandırılır.

· State transition testing ( Durum geçiş testi ): Bir sistemin bir dizi durum olarak görüntülendiği bir test tasarım tekniğidir. Bu durumlar arasında geçerli ve geçersiz geçişler ve durum değişikliklerine neden olan girdiler ve olaylar yer almaktadır.

· Static testing ( Statik test ): Test sistemi yazılım çalıştırmadan gerçekleştirilirse statik test olarak adlandırılır. Belge incelemesi, statik bir test örneğidir.

· Stress testing ( Stres testi ): Stres testi, sistemin belirtilen gereksinimlerini aşan iş yüklerine nasıl tepki vereceğini değerlendirmek için kullanılan test tekniğidir. Stres testi sayesinde hangi sistem kaynağının ilk önce başarısız olduğu bulunur ve gösterilir. Bellek, bant genişliği ve benzeri yapılar sistem kaynaklarına örnek verilebilir.

· Supplier ( Tedarikçi ): Bir BT sistemini bir müşteriye veya kullanıcıya tedarik eden kuruluş olarak bilinir. Dâhili veya harici tedarikçi olmak üzere ikiye ayrılmaktadır.

· System ( Sistem ): Donanım, yazılım ve belgeler bir araya gelerek sistem oluşturulur.

· System integration testing ( Sistem entegrasyonu testi ): Bir sistemin diğer sistemlerle başarılı bir şekilde entegre edilip edilemeyeceğini değerlendirmek için tasarlanmış bir test seviyesidir. Sistem düzeyinde testin bir parçası olarak dâhil edilebilir ya da sistem testi ile kabul testi arasında ayrı bir test seviyesi olarak gerçekleştirilebilir. Örneğin, test edilen sistemin finans sistemi ile iyi çalışıp çalışmadığı güzel bir sistem bütünleşme testine örnektir.

· System testing ( Sistem testi ): Bütünleşmiş sistemi test etmeyi amaçlayan test seviyesidir. Hem fonksiyonel hem de fonksiyonel olmayan testler olmak üzere iki farklı şekilde yapılır.

· Test automation ( Test otomasyonu ): Manuel test, test adımlarını dikkatlice yürüten bir bilgisayarın önünde oturan bir insan tarafından gerçekleştirilir. Manuel testin aksine test otomasyonu, test senaryolarını ve test durumlarını yürütmek için bir otomasyon aracı kullanılarak yapılan test anlamına gelir.

· Test basis ( Test temeli ): Test durumlarının dayandığı belgelerdir.

· Test case ( Test durumu ): Test adımı, beklenen sonuç önkoşulları ve bitiş koşulları dâhil olmak üzere, bir fonksiyonun veya özelliklerin nasıl test edilmesi gerektiğini açıklayan yapılandırılmış bir test komut dosyasına denir.

· Test data ( Test verisi ): Test adımlarında testin gerçekleşmesi için bazı değerlerin sisteme girdi olarak verilmesi gerekmektedir. Test adımlarının tamamlanması için bu bilgilere ihtiyaç duyulmak zorundadır. Sisteme girdi olarak verilmesi gereken bu değerlere test verisi adı verilmektedir. Örneğin bir müşteriyi sisteme eklediğiniz bir test vakasında, test verileri müşteri adı ve adresi olabilir. Test verileri ayrı bir test veri dosyasında veya bir veri tabanında tutulabilir.

· Test driven development ( Test odaklı gelişim ): Yazılım geliştiricilerin herhangi bir kod yazmadan önce test senaryoları yazdığı bir geliştirme yaklaşımıdır.

· Test driver ( Test sürücüsü ): Yazılım mimarisinin üst düzey bileşenlerini taklit etmek için entegrasyon testi sırasında kullanılan bir yazılım bileşenidir. Örneğin, bir test sürücüsü testler sırasında kullanıcı ara yüzünü taklit ederek çalışabilir.

· Test environment ( Test ortamı ): Donanım, yazılım ve test araçları dâhil olmak üzere testlerin yürütüldüğü teknik ortama test ortamı denir. Test planında veya test stratejisinde test ortamının nasıl olacağı belgelenmiştir. Buna göre test ortamı hazırlanarak test işlemi takip edilir.

· Test execution ( Testin gerçeklemesi ): Test nesnesinin test edilerek çalıştırma sürecine denir.

· Test level ( Test seviyesi ): Belirlenen hedefleri karşılamak için bir grup test faaliyetinin düzenlenmesi ve gerçekleştirilmesidir. Test seviyelerinin örnekleri bileşen, entegrasyon, sistem ve kabul testidir.

· Test log ( Test kaydı ): Kronolojik sırayla test faaliyetlerini tanımlayan bir belgedir.

· Test manager ( Test yöneticisi ): Test faaliyetlerini belirli bir test seviyesinde planlamaktan sorumlu kişidir. Genellikle test planı ve test raporunun yazılmasından sorumludur. Çoğu zaman test senaryolarını yazmaktan da sorumludur.

· Test object ( Test nesnesi ): Test edilecek sistemin parçası veya alt bölümüdür. Test nesnesi bir bileşen, alt sistem veya bütün olarak sistem olabilmektedir.

· Test planning ( Test planlaması ): Test işleminin kim tarafından, ne zaman, nasıl ve neden test edilmesi gerektiğini açıklayan bir belgedir. Örneğin, bir sistemin belirli bir sürümü için sistem testini açıklayan test planı zamanla sınırlandırılmıştır.

· Test policy ( Test politikası ): Bir kuruluşun test süreçlerini nasıl yüksek düzeyde yürüttüğünü açıklayan bir belgedir. Seçilen yaşam döngüsü modeline, rollere ve sorumluluklara göre test seviyelerinin bir tanımını içerebilir.

· Test process ( Test süreci ): Test planlamasından testin tamamlanmasına kadar olan tüm test aktivitelerini kapsamaktadır. Test süreci genellikle test politikasında açıklanmaktadır.

· Test report ( Test raporu ): Bir test süresinin sonunda test faaliyetlerinin sürecini ve sonucunu özetleyen bir belgedir. Test yöneticisinin önerilerini içerir. Bu da test etkinliklerinin hedeflerine ulaşma derecesine dayanır. Test özeti raporu da denir.

· Test running ( Testin çalıştırılması ): Bir test seviyesindeki testler, genellikle bir dizi test, tekrar testi ve regresyon testinden oluşan iki haftalık döngü halinde gruplandırılır. Her seri bir test çalışması olabilir.

· Test script ( Test komut dosyası ): Test takımının bir test otomasyon aracı yardımıyla oluşturduğu otomatik test vakasıdır. Bazen bir manuel test vakasına veya bir dizi birbirine bağlı test vakasına başvurmak için de kullanılmaktadır.

· Test specification ( Test şartnamesi ): Sistemi hazırlamak ve sıfırlamak için gerekli adımları içeren bir dizi test vakası içeren bir belgedir. Çok büyük bir sistemde, her bir alt sistem için bir test şartnamesi olabilir.

· Test strategy ( test stratejisi ): Bir sistemin genellikle nasıl test edildiğini açıklayan belgeye denilmektedir.

· Test stub ( test koçanı ): Alt seviye bileşenleri taklit etmek için entegrasyon testi sırasında kullanılan bir test programıdır. Örneğin, bir veri tabanı çağrıldığında sabit kodlanmış bir yanıt sağlayan bir test kodu kullanılabilir.

· Testing ( Test yapma ): Yazılımın gereksinimlerine uyup uymadıklarını belirlemek, amaçlara uygun olup olmadıklarını ve kusurları bulmak için yazılım ve diğer çıktıları değerlendirmek amacıyla yapılan faaliyete denir.

· Third party component ( Üçüncü parti bileşen ): Tedarikçi tarafından geliştirilmek yerine paketlenmiş komple bir ürün olarak satın alınan bir BT sisteminin parçasıdır.

· Top down integration ( Yukarıdan aşağı entegrasyon ): Test ekibinin sistemin bileşenlerini sistem mimarisinin en üst düzeyinden başlayarak entegre etmeye başladığı bir entegrasyon testi stratejisidir.

· TPI: Test Süreci İyileştirme’nin ( Test Process Improvement ) kısaltmasıdır. Kuruluşun test ile ilgili olgunluğunu ölçme ve iyileştirme yöntemidir.

· Traceability ( İzlenebilirlik ): Bir önceki olaylar zincirinin analizi ve çeşitli sürümlerde bir belge veya bir program gibi bir nesneyi takip etme yeteneğidir. İzlenebilirlik, bir izlenebilirlik matrisi geliştirdiğiniz varsayılarak, gereksinimdeki bir değişikliğin etkisini belirlemenize olanak tanır. Gereksinimler, test senaryoları veya hata raporları gibi iki veya daha fazla belge arasındaki ilişkiyi gösteren bir tabloya ise izlenebilirlik matrisi adı verilmektedir. Bir değişikliğin dokümantasyon ve yazılım üzerinde ne gibi etkileri olacağını değerlendirmek için kullanılır. Örneğin, verilen şartlar değiştiğinde hangi test durumlarının çalıştırılması gerektiği bu matrise bakılarak öğrenilebilir.

UML: Birleşik Modelleme Dili’nin ( Unified Modeling Language ) kısaltılmış halidir. Sistemin kullanım durumları şeklinde tanımlanması için bir teknikdir.
Unit test ( Birim test ): Bileşen testi olarak da bilinmektedir.
Unit test framework ( Birim test kütüphanesi ): Geliştiricilerin normal programlama dilinde test kodu yazmasını sağlayan yazılım veya sınıf kütüphaneleridir. Bileşen ve entegrasyon testlerini otomatikleştirmek için kullanılmaktadır.
Usability ( Kullanılabilirlik ): Yazılımın kullanıcı için anlaşılması, öğrenilmesi, kullanılması ve cazip olması durumudur.
Usability testing ( Kullanılabilirlik testi ): Bir sistemin kullanılabilirliğini değerlendirmek için yapılan test tekniğidir. Genellikle sistemde görev yapan kullanıcılar düşünce süreçlerini yüksek sesle açıklarken bu test işlemi gerçekleştirilir.
Use case ( Kullanım durumu ): Gereksinimlerin sistemdeki çeşitli aktörlerin sistemle nasıl etkileşimde bulunduğunu açıklayan diziler halinde yazıldığı bir gereksinim belgesi türüdür.

V model ( V modeli ): Gereksinim yönetimi, geliştirme ve farklı düzeylerde test etme konularını açıklayan bir yazılım geliştirme yaşam döngüsü modelidir.
Validation ( Doğrulama ): Geliştiricilerin doğru sistemi oluşturduğunu göstermek için tasarlanmış testlerdir. Bir başka ifadeyle sistemin doğru şekilde yapılıp yapılmadığını test etmek anlamına gelir. Kabul testi sırasında çok sayıda doğrulama etkinliği gerçekleşmektedir.

Waterfall model ( Şelale modeli ): Bir dizi aşamadan oluşan sıralı bir geliştirme yaklaşımıdır. Yazılım geliştirme adımları tek tek gerçekleştirilmektedir ve tek yönlüdür. Bu yaklaşım, birçok doğal sorun nedeniyle önerilmemektedir.
White box testing ( Beyaz kutu testi ): Test cihazının test nesnesinin içyapısı hakkında bilgi sahibi olduğu bir test türüdür. Beyaz kutu test sorumluları, program kodunu okuyarak, veri tabanı modelini inceleyerek veya teknik özellikleri gözden geçirerek sisteme kendilerini tanıtabilirler. Kara kutu testinin tam tersi olan tekniktir.

Yazılım Kalitesi

Bölüm Hedefi

Bu bölümde Yazılım Kalitesinin ne olduğu tanımlanmış ve özellikleri incelenmiştir. Yazılım Güvencesi nedir? Kalite güvenceye nasıl başlanır? soruları cevaplanmıştır. Ayrıca, yazılım kalitesi için, yazılım geliştirme aşamasında kulak verilmesi gereken müşteri görüşü, geliştirici görüşü ve proje yöneticisi görüşlerinin incelenmesine yer verilmiştir.

Giriş

Her gün çalışmamızda, “yazılım kalitesi” kavramının oldukça soyut bir konseptiyle karşı karşıyayız ve bir testçiye ya da programcıya “kalite nedir?” sorusunu sorarsanız, o zaman herkes kendi yorumlarını bulacak. Uluslararası standartlar bağlamında “yazılım kalitesi” tanımına bakalım:

Yazılım Kalitesi ( Software Quality )
Yazılım kalitesi, yazılımın istenen özellik kombinasyonuna sahip olduğu derecedir.

[1061-1998 IEEE Standard for Software Quality Metrics Methodology]

Yazılım Kalitesi ( Software Quality )
Yazılım kalitesi, belirtilen ve algılanan ihtiyaçları karşılayabilme yeteneği ile ilgili yazılım özelliklerinin bir birleşimidir.

[ISO 8402:1994 Quality management and quality assurance]

7.1. Yazılım Kalitesi Özellikleri

İşlevsellik ( Functionality ) – yazılımın belirli koşullar altında, kullanıcının sabit ve algılanan ihtiyaçlarını karşılayan görevleri çözme yeteneğiyle belirlenir. Yani, bu özellik, yazılımın düzgün ve doğru bir şekilde çalışmasını, birlikte çalışabilirliği, endüstri standartlarını karşıladığından ve yetkisiz erişime karşı korunmasından sorumludur.

Güvenilirlik ( Reliability ) – yazılımın belirli bir süre veya belirli bir sayıda işlem için belirlenen koşullarda gerekli görevleri gerçekleştirme yeteneğidir. Bu özelliğin nitelikleri, tüm sistemin tamlığı ve bütünlüğü, arızalardan sonra bağımsız ve doğru şekilde kurtarma yeteneği ve hata toleransıdır.

Kullanılabilirlik ( Usability ) – kullanıcı için kolayca anlama, öğrenme, kullanma ve çekici yazılım kullanma becerisidir.

Verimlilik ( Efficiency ) – yazılımın, tahsis edilen kaynaklara, zamana ve diğer belirlenmiş koşullara göre istenen performans düzeyini sağlaması.

Sürdürülebilirlik ( Maintainability ) – yazılımın analiz edilebilme, test edilme, kusurları düzeltecek şekilde değiştirilebilme, yeni gereksinimlerin yerine getirilmesi, daha fazla bakımın kolaylaştırılması ve mevcut ortama uyum sağlama kolaylığıdır.

Taşınabilirlik ( Portability ) – yazılımı bir ortamdan (yazılım / donanım) diğerine aktarma kolaylığı açısından tanımlar.

Şu anda, ISO 9126 standart setinde sunulan, en yaygın ve kullanılan çok seviyeli yazılım kalitesi modelidir. Üst düzeyinde, yazılım kalitesinin 6 ana özelliği tanımlanmıştır, her biri daha fazla değerlendirme için ilgili ölçülere sahip olan bir dizi özellik ile tanımlanmıştır (bknz. Şekil 1).

Şekil 1 Yazılım Kalite Modeli (ISO 9126-1)

7.2. Yazılım Kalite Güvencesi (Software Quality Assurance)

Kalite güvencesi ( Quality Assurance – QA ), ürün veya hizmetin iyi işleyeceğinin kesinliğidir. Ürünün beklentileri ve / veya gereksinimlerini sorunsuz bir şekilde yerine getireceğini garanti eder. Bir kuruluşun müşterilere mümkün olan en iyi ürünü veya hizmeti sunması aktivitesidir. Kalite güvencesi, kalite ürünlerini müşteriye ulaştırmak amacıyla süreçlerin iyileştirilmesi ile ilgilenir.

Bir kuruluş, işlemlerin verimli ve etkili olmasını yazılım ürünlerine yönelik tanımlanan kalite standartlarına uygun bir şekilde sağlamalıdır. Kalite güvencesi, P D C A döngüsü veya Deming döngüsü olarak adlandırılan bir döngüye sahiptir. Bu döngünün aşamaları sırasıyla şu şekildedir:

Planla (Plan): Bu iterasyonda, kuruluşlar, süreçle ilgili hedeflerin planlarını hazırlamalı ve yüksek kalitede bir nihai ürün sunmak için gerekli olan süreçlerin neler olacağını belirlemelidir.
Yap/Hayata Geçir (Do): Kuruluşlar, süreçlerin geliştirilmesini ve test edilmesini sağlamalı ve aynı zamanda süreçlerde değişiklikleri yapmalıdır.
Kontrol Et (Control): Bu iterasyonda, süreçlerin izlenmesi, değiştirilmesi ve önceden belirlenmiş hedeflere ulaşılıp ulaşılmadığına bakılması ve bunların kontrol edilmesi gerekmektedir.

Harekete Geç (Act): Süreçlerdeki iyileştirmeleri gerçekleştirmek için gerekli olan eylemler uygulanır.

Bu döngü, takip edilen süreçlerin periyodik olarak değerlendirilmesini ve iyileştirilmesini sağlamak için tekrarlanır.

7.3. McCabe Karmaşıklık Ölçütü

Yazılım karmaşıklığı, proje ölçüm / kilometre taşı ( milestone ) durumu ve rapor edilen sistem hataları gibi dolaylı yazılım önlemlerinin aksine, yazılım özniteliklerinin doğrudan ölçülmesine odaklanan bir yazılım metrikleri dallarından biridir. Kaynak kod satırı gibi basitten, değişken tanımı / kullanımı ilişkilerinin sayısı gibi bir duruma gelene kadar, yüzlerce yazılım karmaşıklığı ölçüsü vardır.

McCabe (1976) tarafından geliştirilen döngüsel karmaşıklık ölçümleri, bir programın tam kapsamını elde etmek için gereken maksimum bağımsız yol sayısını belirlerken aynı zamanda, programın veya modülün karmaşıklığını da ölçer. Ölçüm, çizge kuramına dayanır ve böylece program akış grafiğiyle ( çizgeyle ) yakalanan program özelliklerine göre hesaplanır. Bağımsız bir yol, biriken bağımsız yolların ardına referansla tanımlanır, yani: “Program akış grafiğinde, eski bağımsız yollardan herhangi birinde bulunmayan en az bir kenar içeren herhangi bir yol”. Bu karmaşıklık ölçütünün hesabı, program kodlarının hataya ne kadar meyilli olduğunu gösterir.

McCabe karmaşıklık ölçütünü hesaplamak için, ilk olarak, ilgili programı bir akış diyagramına dönüştürmek gerekir. Akış diyagramı için kullanılan işlem şekilleri şöyledir:

Ardışık işlemler şekli

if-then yapısı şekli if-then-else yapısı şekli, if-then-else yapısı şekli, while ( for ) döngüsü

Daha sonra, bu şekillerle programın akış diyagramları hazır olduktan sonra, karmaşıklık ölçütünü hesaplayabiliriz. Bunun için aşağıdaki formül kullanılmalıdır.

V (G) = e – n + 2 * p ( CC – Cyclomatic Complexity )

e: Akış diyagramdaki toplam kenar çizgi sayısı (number of edge)
n: Akış diyagramdaki toplam düğüm sayısı (number of node)
p: programdaki modül sayısı (number of module, equals to 1 as initial)

Not: programda herhangi bir alt program veya modül kullanılmadı ise p=1. Örneğin, 2 tane modül kullanıldıysa p=3.

Elde edilen sonuç, Yazılım Mühendisliği Enstitüsü (Software Engineering Institute – SEI) tarafından kabul edilen değerlendirme ile değerlendirilir. Değerlendirme tablosu şu şekildedir:

Karmaşıklık Ölçütü	Risk Değerlendirmesi
1 – 10	Fazla riskli olmayan basit bir modül
11 – 20	Orta riskli ve biraz karmaşık modül
21 – 50	Yüksek riskli karmaşık bir modül
51 – …	Çok riskli test edilemez bir modül

Örneğin, bir kodun McCabe karmaşıklık ölçütünün hesaplanmasına bakalım:

Kod:
if (koşul)//n1
{
yapılacaklar; //n2
}else
{
yapılacaklar; //n3
}
yapılacaklar; //n4

Akış diyagramı:

Karmaşıklık ölçütünün hesaplanması:

Formül: V (G) = e – n + 2 * p ;
e = 4; n = 4; p = 1;
V (G) = 4 – 4 + 2*1
V (G) = 2

Bu da, yazılan kodun fazla riskli olmayan basit bir modül olduğunu göstermektedir.

7.4. Kalite Güvenceye Nasıl Başlanır?

Bir kalite yönetimi organizasyonu oluşturmak aşağıdaki adımlarla başlar. Uygulaması nispeten kolaydır ve gerçek somut faydalar sağlarlar:

Kullanılacak genel şablonlarda anlaşmak
Eylem sırasını belirle
Standartların ve süreçlerin kullanıldığından emin olun
Tamamlanmış projeleri analiz edin
Hata verilerini kullanarak analiz edin ve öğrenin
Öğrendiklerinizi kullanın

Kalite güvencesi bir öğrenme sürecidir: neyin yanlış çalıştığını ve nasıl düzeltileceğini öğrenmek; neyin doğru çalıştığını ve hangi şartlar altında çalıştığını ve her yeni projeyle birlikte işinizi nasıl daha iyi yapmaktır.

Kalite Güvence sürecine dahil olan herhangi bir organizasyon sürekli olarak eğitilmektedir. İlk adımı – Kalite Güvencesini ürün geliştirmenin ayrılmaz bir parçası yapmaktır. Kalite yönetimi adımlarını daha yakından inceleyelim.

7.4.1. Kullanılacak Genel Şablonlarda Anlaşmak

Paylaşılan şablonlar, tüm ekip üyelerine işbirliği için önemli bir temel sağlar. Her kişi görevi kendi yolunda gerçekleştirdiğinde, işbirliğini unutabilirsiniz. Çoğu zaman, geliştirici başka birinden yardım istemekten korkuyor, çünkü yaklaşımını kabul etmeyebilir. İşbirliği olmadığı zaman, yaklaşımlardaki bu farklılıklar, ortak anlayışı ve bilgi ve deneyimin birikimini engelleyebilir.

Genel şablonlar teknik çalışmanın geliştirilmesine katkıda bulunur. Görevlerini kendi yoluyla yapan bir geliştirici, önemli ayrıntıları veya bilgileri kolayca gözden kaçırabilir. İş standartlaştırıldığında, yapılan işin içermesi gerekenler konusunda hiçbir soru kalmaz.

7.4.2. Eylem Sırasını Belirle

Süreçlerin, yani izlenecek olan aşamaların ve prosedürlerin belirlenmesi önemlidir. Görünür yüksek kaliteli süreçler, işlerin daha akıcı olmasına katkıda bulunur. İhtiyaçlarınızı karşılıyorlar mı? Hedeflerine ulaşıyorlar mı? Geliştirme ekibi ve müşteriler arasında yeterli etkileşime katkıda bulunuyorlar mı? gibi sorularla süreçlerin kalitesine önem verilmelidir.

Tabi ki de kurulan süreçlere uyma kalitesine de dikkat edilmelidir. Görevlerinizi yanlış ve tutarsız bir şekilde yaparsanız, anlaşmaları göz ardı ederseniz, iyi süreçlerden bile hiçbir fayda elde edemezsiniz. Kalite güvence süreçlerinin tutarlı kullanımı ne anlama geliyor? Bu, her bireyin onları nasıl takip edeceğini, ne zaman ve nasıl yapacağını bildiği ve bunları kesinlikle yerine getirmesi ve uygulamasıdır. Doğal olarak, bu davranış tüm takımdan bekleniyor.

7.4.3. Standartların ve Süreçlerin Kullanıldığından Emin Olun

Seçilen standartların ve süreçlerin kullanımından yararlanmak için, her şeyin kurulu bir anlaşmaya göre yapıldığı sürekli olarak izlenmeli ve denetlenmelidir. Ancak bu şekilde planladığınız sonucu elde edersiniz. Düzenli olarak kullanılmayan her şey, er ya da geç yok olur. Bu insan davranışının yasasıdır. Örneğin, Çevik ( Agile ) model veya SCRUM gibi kullanılan projelerde bir eğitmen çalışır.

7.4.4. Tamamlanmış Projeleri Analiz Edin

Yapılan işlere bakarak, “Neler iyiydi ve gelecekte aynı şeyi nasıl yapabilirim?” ve “Neler yanlıştı ve bu yanlışlar nasıl önlenebilir?” sorularının cevapları çalışmanızın daha kaliteli olmasına yardımcı olan güçlü bir yöntemdir.

7.4.5. Hata Verilerini Kullanarak Analiz Edin ve Öğrenin

Kusurların listesini oluşturmak da aynı şekilde kalitenin iyileştirilmesinde büyük rol oynar. Yapılan kusurların analizi yapılırken, en çok hangi kusurların ortaya çıktığı, bu kusurların nedenlerine, nasıl ve ne kadar sürede ortadan kaldırıldığına ve bunun maliyetinin ne olduğuna bakılır. Bu maliyeti yüksek olan kusurun ileride nasıl kaçınılacağına ya da en azından, geliştirme sürecinin erken aşamalarında nasıl tespit edilebileceğine çareler arama yaklaşımı gerçekten de kalitenin iyileştirilmesine yol açar.

7.4.6. Öğrendiklerinizi Kullanın

Birçok Kalite Güvencesi aktivitesi, geliştirilmekte olan ürünün kalitesini geliştirme kabiliyetiniz hakkında inanılmaz miktarda bilgi sağlayacaktır. Ancak bu bilgi tek başına istenilen kaliteyi garanti etmez. Öğrenmiş olduğunuz her şeyi düzenli bir şekilde uygulamaya koymalısınız. Şekil 2’de Yazılım Kalitesini iyileştiren Kalite Temelleri, Kalite Yönetim İşlevleri ve Pratik Düşünceler bölümlendirilmiştir.

Şekil 2 Yazılım Kalitesi

Mühendisler, kalite kavramına yatırılan anlamı, geliştirilmekte olan ya da sürdürülen yazılımla ilişkili kalitenin özelliklerini ve değerini anlamalıdır. Yazılım mühendislerinin, yazılım kalite sorunlarını profesyonel kültürlerinin bir parçası olarak algılaması bekleniyor.

7.5. Yazılım Ürününün Kalitesi

Bir yazılım ürününün kalitesi ( software quality ), bir yazılım ürününün tüm özellik ve özelliklerinin bir bütünüdür; bu, yerleşik veya algılanan ihtiyaçları karşılama yeteneğini ifade eder.

Her kalite karakteristiğinin önemi, yazılım sınıfına göre değişir. Örneğin, muharebe yazılımı için güvenilirlik çok önemlidir, gerçek zamanlı sistem yazılımı için verimlilik en önemlisidir ve pratiklik ise son kullanıcı diyalog yazılımı için en önemli olanıdır. Her kalite özelliğinin önemi de kabul edilen bakış açılarına bağlı olarak değişir.

7.5.1. Kullanıcı Görüşü

Kullanıcılar esas olarak yazılım kullanımı, performansı ve kullanım sonuçları ile ilgilenir. Kullanıcılar, yazılımı kendi iç yönlerini incelemeden veya yazılımın nasıl oluşturulduğunu merak etmeden değerlendirir.

Kullanıcıları aşağıdaki sorular ilgilendirebilir:

Yazılımda gerekli fonksiyonlar var mı?
Yazılım ne kadar güvenilir?
Yazılım ne kadar etkili?
Yazılım kullanıcı dostu mı? Kullanımı kolay ve anlaşılır mı?
Yazılımın diğer ortamlara taşınması ne kadar kolay?

7.5.2. Geliştirici Görüşü

Oluşturma süreci, kullanıcı ve geliştiricinin, gereksinimleri ve kabulü oluşturmak için kullanıldığından, aynı yazılım kalitesi özelliklerini kullanmasını gerektirir. Örneğin, satış için yazılım geliştirirken, kalite gereksinimleri ilgili ihtiyaçları yansıtmalıdır.

Geliştiriciler, kalite gereksinimlerini karşılaması gereken yazılımları oluşturmaktan sorumlu olduklarından, ara ürünlerin kalitesinin yanı sıra nihai ürünlerin kalitesiyle de ilgilenirler. Geliştirme döngüsünün her aşamasında ara ürünlerin kalitesini değerlendirmek için, geliştiriciler aynı özellikler için farklı metrikler kullanmalıdır, çünkü aynı metrikler yaşam döngüsünün tüm aşamaları için geçerli değildir.

Örneğin, kullanıcı, tepki süresi açısından verimliliği anlar, geliştirici ise tasarım spesifikasyonundaki rota uzunluğu ve gecikme süresini ve erişim şartlarını kullanır. Ürünlerin harici arayüzü için kullanılan metrikler, yapısı için kullanılan metriklerle değiştirilebilir.

Metrik ( Metrics )
Bir metrik, nicel bir ölçek ve ölçmek için kullanılabilecek bir yöntemdir.

[ISO 14598]

7.5.3. Yönetici Görüşü

Bir yönetici, belirli bir kalite özelliğinden genel kaliteye daha fazla ilgi gösterebilir ve bu nedenle bireysel özellikler için ticari gereksinimleri yansıtan değerlerin önemini belirlemelidir.

Yöneticinin, kalite iyileştirmesini, planlı gecikme veya maliyet aşımları gibi kontrol edilebilirlik kriterleri ile karşılaştırması gerekebilir, çünkü kaliteyi sınırlı bir maliyet, insan gücü ve ayarlanan süre içinde optimize etmek ister.

7.6. Proje Kalitesi

Kalite, projenin üstlenildiği hedeflere uygun olmasını sağlayan tüm proje faaliyetlerini içerir. Bu nedenle, kalite yönetimi hem projeye hem de proje ürününe uygulanabilir.

Kalite kritik olarak önemlidir çünkü amaçları belirler ve onları dile getirir, onları belgelendirir (resmi hale getirir). Sonuç olarak, kalite, bir projenin yapısını yönetmenin kritik bir bileşenidir. Kalite için her şey ölçülebilir.

7.7. Proje Kalite Yönetimi

Kalite yönetimi bir organizasyonun sadece tek biriminde yoğunlaşırsa, evrensel olmayacaktır. Proje yöneticisi, kalite yönetiminden diğer bazı çalışanları da sorumlu tutabilir. Ancak, nihai sorumluluk proje yöneticisi elinde tutulur.

Kalitenin prensipleri (ISO 9000):

Müşteri odaklı olmasıYönetim sorumluluğuİnsanların katılımıSüreç yaklaşımıYönetime olan sistematik yaklaşımSürekli iyileştirmeGerçeklere dayanan kararlar verme ( facts )Yararların karşılıklı olduğu tedarikçi ilişkileri

Yazılım kalitesi, müşteriler, geliştiriciler ve kullanıcılar bakış açısına bağlı olarak farklı şekilde kabul edilir. Bazen, yazılımı almaktan sorumlu olan müşteri ile onu eninde sonunda kullanacak olan kullanıcıları birbirinden ayırmak gerekir. İleriki bölümlerde anlatılan iş modellerine göre de “kalitenin” tanım ve anlayışının değiştiği görülebilir.

Kullanıcılar, diğer şeylerin yanı sıra işlevsellikler, performans, yeterlilik, doğru sonuçlar, güvenilirlik ve kullanılabilirlik arayışındadır. Müşteriler genellikle en iyi fiyata en iyi çözümü sunarak maliyetlere ve teslim tarihlerine daha fazla odaklanırlar. Bu, kalite açısından dışsal bir bakış açısı olarak düşünülebilir.

Yazılım uzmanlarına gelince, ayrılan bütçeye dayanan yükümlülükleri yerine getirmeye daha çok odaklanırlar. Bu nedenle yükümlülüklerini, bağlayıcı gereklilikler ve sözleşmenin hüküm ve koşulları açısından görürler. Doğru araçların ve modern tekniklerin seçimi genellikle endişelerin özünde yer alır ve bu nedenle, motor teknolojisine ilgi duyan ve onu ayrıntılı olarak bilen bir tamircinin bakış açısına benzer. Ona göre, bileşenlerin seçimi ve montajı önemli olduğu gibi, bundan bağımsız olarak kalite de aynı derecede önemlidir.

Müşterinin yazılım ( veya daha genel olarak her tür sistem ) ihtiyacı dört seviyede tanımlanabilir:

Gerçek ihtiyaçlar ( True Needs )
İfade edilen ihtiyaçlar ( Expressed needs )
Özelleştirilmiş ihtiyaçlar ( Specified needs )
Elde edilen ihtiyaçlar ( Achieved needs )
Her bu seviye için, müşteri gereksinimlerinin memnuniyetini etkileyebilecek tipik faktörleri aşağıdaki tabloda açıklanmıştır.

Gereksinim türü	İfadenin kökeni	Farkın başlıca nedenleri
Gerçek ihtiyaçlar	Paydaşların görüşü	Gerçek gereksinimlere aşina olmama Gereksinimlerin kararsızlığı Parti ve kullanıcı siparişi konusunda farklı bakış açıları
İfade edilen ihtiyaçlar	Kullanıcı gereksinimleri	Tamamlanmamış şartname Standartların eksikliği Sipariş veren parti ile yetersiz veya zor iletişim Yetersiz kalite kontrol
Özelleştirilmiş ihtiyaçlar	Yazılım Şartname Belgesi	Yönetim ve üretim yöntemlerinin, tekniklerinin ve araçlarının uygunsuz kullanımı
Elde edilen ihtiyaçlar	Belgeler ve Ürün Kodu	Yetersiz testler Yetersiz kalite kontrol teknikleri

7.8. Metriklerin Analizi

Geliştirme süreci üzerinde ve özellikle de test süreci üzerinde kontrolü geliştirmek için metriklerin kullanılması gereklidir. Testin yapılabilmesi için öncellikle gerekli olan bilgiler toplanır (hem elle hem de otomatik olarak) ve durumu değerlendirmek ve kapsama (örneğin gereksinimleri kapsayan veya testleri içeren kod) veya çıkış ölçütleri (örneğin, son kriterleri test etmek) gibi kararlar vermek için kullanılır. Metrikler ayrıca planlanan iş ve bütçe uygulamasının ilerlemesini değerlendirmek için de kullanılabilir.

Daha açık bir netlik için, bu ölçümleri (metrikleri) kalite güvencesine katkıda bulunmasına ve yazılım testine dahil olan türlerine göre gruplandırmak anlamlıdır:

1) Test Durumları Metrikleri ( Test Cases )
2) Hata / Kusur Metrikleri ( Bug/Defect metrics )
3) Görev Metrikleri ( Task Metrics )
Her birine daha yakından bakalım:
Test Durumları Metrikleri

Adı	Tanımı
Başarılı/Başarısız Test Durumları ( Passed/Failed Test Cases )	Metrik, test senaryolarının geçme sonuçlarını, yani tamamlanmış olanların sayısının hatalarla tamamlanma oranını gösterir. İdeal durumda, projenin sonunda, başarısız testlerin sayısı sıfıra inmektedir.
Çalıştırılmayan test durumları ( Not Run Test Cases )	Metrik, bu test aşamasında hala yapılması gereken test vakalarının sayısını gösterir. Bu bilgiler ışığında testin yapılmama nedenlerini analiz edebilir ve tespit edebiliriz.

Hata / Kusur Metrikleri

Adı	Tanımı
Açık / Kapalı Hatalar ( Open/Closed Bugs )	Metrik açık hataların sayısının kapalıya oranını gösterir (düzeltilmiş ve tekrar kontrol edilmiş)
Yeniden Açılmış / Yeniden Kapatılmış Hatalar ( Reopened/Closed Bugs )	Metrik, tekrar açılmış hataların sayısının kapalıya oranını gösterir (düzeltilmiş ve tekrar kontrol edilmiş)
Reddedilen/Açılan Hatalar ( Rejected/Opened Bugs )	Metrik, reddedilen hataların sayısının açık olanlara oranını gösterir.
Öneme Göre Hatalar ( Bugs by Severity )	Önemine göre hata sayısı
Önceliğe Göre Hatalar ( Bugs by Priority )	Önceliklere göre hata sayısı

Görev Metrikleri

Adı	Tanımı
Uygulama yükleme görevleri ( Deployment tasks )	Metrik, uygulama yüklemelerinin sayısını ve sonuçlarını gösterir. Test ekibi tarafından reddedilen versiyonların sayısının kritik düzeyde yüksek olması durumunda, sorunun en kısa zamanda çözümlenmesinin yanı sıra acilen analiz edilmesi ve tespit edilmesi tavsiye edilir.
Hâlâ açıkta olan görevler ( Still Opened Tasks )	Metrik, hala açık olan görevlerin sayısını gösterir. Projenin sonunda tüm görevler kapatılmalıdır. Görevler gereği, aşağıdaki çalışma türlerini kastediyoruz: belgelendirme yazıları (mimari, gereksinimler, planlar), yeni modüllerin uygulanması veya değişim talepleri için mevcut olanların değiştirilmesi, standların kurulması, çeşitli çalışmalar ve çok daha fazlası.

Ayrıca, zaman zaman projenin durumundaki değişikliği yansıtan gerekli metriklerin ve grafiklerin kullanılmasının, yalnızca test sürecini değil, aynı zamanda bir bütün olarak geliştirmeyi de iyileştirir. Aynı zamanda, tamamlanmış projenin analiz edilmesine yönelik prosedürü de kolaylaştıracaktır, bu da yapılmış hataların tekrarlanmasını önler.

Yazılım Kalitesi konusu kapsamında kullanılan terimler listesi

Aşağıda tanımı verilen terimler yazılım kalitesi konusu ile ilgili kelimelerdir. Ders kapsamında ve yazılım kalitesi konuları kapsamında kullanılan bu terimler, konuyu daha iyi kavramak amacıyla verilmiştir.

Yazılım geliştirme süreci: planlanmış bir iş akışıdır. Planlanmış bir iş akışı, geliştirilmekte olan yazılımın zamanında ve kaliteli bir şekilde elde edilmesinin sağlanmasında yardımcı olur.

Süreç: işlevlerin belirli bir taslağa uygun bir şekilde ve belirli bir sonuca varacak biçimde düzenlenmesi ve sıralanmasıdır. Bir şeyin işlenme, yapılış ve üretiliş biçimini oluşturan sürekli eylemler dizisidir. Aralarında birlik olan veya belli bir düzen veya zaman içinde tekrarlanan, ilerleyen, gelişen olay ve hareketler dizisidir.

Yazılım Süreci: Bir yazılım ürününün üretmesini sağlayan birbiriyle tutarlı faaliyetler grubudur. Ne yapılmak istendiğini tüm uygulama detaylarına girmeden tanımlar. Yazılım süreci, yazılım mühendisliğinin yazılım üretmeye yönelik yol haritasıdır.

TSP ( Team Software Process for Secure Software Development ) : İyi yapılandırılmış yazılım mühendisliği ilkelerini desteklemek için tasarlanmış işlevsel bir süreçtir.

PSP ( Personal SoftwareProcess ) : Bir kişisel yazılım sürecidir. Bu sürecin konuları: entegrasyon testi, sistem testi, saha testi ve müşteri kullanımında hata tespit etme olarak sıralanır. Buradaki amaç, yazılım kodlarındaki hata sayısını azaltmaktır.

Risk analizi: Bir sistemdeki riskleri değerlendirip analiz etmeye yönelik bir aktivitedir.

Değer: Organizasyonun korunan değerleri, veri bileşeni veya tüm sistem.

Risk: Bir değerin olumsuz bir etkiden değer kaybına uğrayacağının olasılığı. Birçok faktör bunu belirleyebilir: uygulamanın kolaylığı, saldırganın motivasyonu ve kaynakları, sistemin varolan açıkları.

Tehdit: Zararlı etkenin neden olacağı tehlike.

Sistem açığı: Hata, zayıflık.

Etki: Riskin gerçekleşmesi durumunda organizasyona etkisi. Parasal veya itibarla ilgili olabilir veya kanun, düzenleme, sözleşme ihlalleri ile sonuçlanabilir. Olasılık: Verilen olayın gerçekleşme olabilirliği / ihtimali.

Tehditler: Sistemin ve değerlerin korunmasını ve güvenlik ilkelerini ihlal eden tehlikedir.

Risk yönetimi: Yazılım yaşam döngüsü boyunca riskleri yeniden değerlendiren sürekli bir işlemdir.

Tehdit alanları: Kod parçası, arayüz, servis, protokol ( iletişim kuralları ) ve özellikle yetkisiz kullanıcılar olmak üzere tüm kullanıcılara açık olan uygulamalar olarak tanımlanmıştır.

Capability Maturity Model ( CMM ) : Bir yazılım sürecini tanımlayan disiplinli bir sürece giden bir yol haritasını çizen normlardır.

Capability Maturity Model Integration ( CMMI ) : Performans arttırmaya yönelik etkili bir süreç iyileştirme yaklaşımıdır. CMMI, kurumların kurumsal fonksiyonlarının entegre edilmesine, süreç iyileştirmede amaç ve önceliklerinin belirlenmesine, kalite iyileştirme süreçlerine rehberlik edilmesine ve mevcut süreçlerin değerlendirilmesine yönelik bir referans yaratmayı hedefler.

Yazılım Kalite Güvencesi ve Sertifikalar

Bölüm Hedefi

Bir önceki bölümde Yazılım Kalitesi ne olduğu anlatılmış ve yüzeysel bir şekilde Yazılım Kalite Güvencesinden bahsedilmiştir. Bu bölümde ise, Yazılım Kalite Güvencesi daha detaylı bir şekilde anlatılmıştır ve onun standartları incelenmiştir. ISO 9001 ve ISO 9000-3 sertifikaları nedir? CMM / CMMI nedir? konularına yer verilmiştir.

Profesyonellerin kendilerine şu soruları sordukları kolayca hayal edebilir: SQA standartları organizasyonumuzda ve yazılım projelerinde neden uygulanmalıdır? Tecrübelerimizi ve profesyonel bilgimizi uygulamak, organizasyonumuza en uygun prosedür ve metodolojilerden yararlanmaya devam etmek daha çok tercih edilmez mi ki?

Bu tür konuların ele alınmasının meşruluğuna rağmen, standardizasyondan elde edilen faydaların mesleki bağımsızlıktan çok daha ötesinde olduğu yaygın olarak kabul görmektedir.

Kalite Güvencesi ( Quality Assurance )
Kalite Güvencesi, Bir sistemin ya da sistem bileşenlerinin belirlenmiş teknik gereksinimlere uygunluğunu garanti etmek amacıyla yapılan planlı sistematik çalışmalar.

TSE ( Türk Standartları Enstitüsü ) Bilişim Terimleri Sözlüğü

Kalite Güvencesi ( Quality Assurance )
1) Bir ürünün veya ürünün belirlenmiş teknik gerekliliklere uygun olduğuna dair yeterli güvence sağlamak için gerekli tüm eylemlerin planlı ve sistematik bir şekli;
2) ürünlerin geliştirildiği veya üretildiği süreci değerlendirmek için tasarlanmış bir dizi etkinlik;
3) Kalite sistemi içerisinde uygulanan planlı ve sistematik faaliyetler ve bir işletmenin kaliteye yönelik gereklilikleri yerine getireceğine dair yeterli güvence sağlamak için ihtiyaç duyulduğu kanıtlanmıştır.

ISO 24765 [ISO 17a]

Yazılım Kalite Güvencesi ( Software Quality Assurance – SQA)
Yazılım süreçlerinin, amaçlanan amaçlar için uygun kalitede yazılım ürünlerine uygun olduğunu ve üretebildiğine dair güven veren kanıtlar sağlamak için yazılım süreçlerinin yeterliliğini tanımlayan ve değerlendiren bir dizi faaliyet. SQA’nın temel bir özelliği, SQA fonksiyonunun projeye ilişkin objektifliğidir. SQA fonksiyonu da organizasyondan bağımsız olarak projeden bağımsız olabilir ve teknik, yönetsel ve finansal baskılardan da özgürdür.

IEEE 730 [IEE 14]

Aslında, Yazılım Güvencesi, paydaşların istek ve ihtiyaçlarını karşılayamayan ve bütçe ile program dahilinde beklentileri karşılamayan bir yazılım geliştirme risklerini azaltmak için uygulanmaktadır. Yazılım Güvencesinin bu bakış açısı, yazılım geliştirme açısından aşağıdaki unsurları içerir:

Bir ürünün veya hizmetin kalite yönlerini planlama ihtiyacı;
Yazılım yaşam döngüsü boyunca, belirli düzeltmelerin gerekli olduğunu söyleyen sistematik faaliyetler;
Kalite sistemi, kalite yönetimi bağlamında, kalite politikasının oluşturulmasına ve sürekli iyileştirmeye izin vermesi gereken eksiksiz bir sistemdir;
Kullanıcılara güven sağlamak için ulaşılan kalite seviyesini gösteren Kalite Güvencesi ( QA ) teknikleri;
Proje için, değişiklik veya yazılım departmanı tarafından belirlenen kalite gereksinimlerinin karşılanması.

Standartların Kullanım Faydaları

Yazılım geliştirme ve bakım metodolojilerini ve en yüksek profesyonel seviyedeki prosedürleri uygulama becerisi
Geliştirme ekipleri arasında özellikle kalkınma ve bakım ekipleri arasında daha iyi karşılıklı anlayış ve koordinasyon
Yazılım geliştiricisi ve projedeki harici katılımcılar arasında daha fazla işbirliği
Sözleşmenin bir parçası olarak bilinen geliştirme ve bakım standartlarının benimsenmesine dayalı olarak tedarikçiler ve müşteriler arasında daha iyi bir anlayış ve işbirliği

Bu avantajlar, artan karmaşıklık ve yazılım projelerinin kapsamı ile birlikte endüstride standartların daha geniş bir şekilde uygulanmasını sağlamıştır.

Standart geliştirme ile ilgili organizasyonlar şu şekildedir:

IEEE ( Institute of Electrical and Electronics Engineers ) Computer Society
ISO ( International Organization for Standardization )
DOD ( US Department of Defense )
ANSI ( American National Standards Institute )
IEC ( International Electrotechnical Commission )
EIA ( Electronic Industries Association )
Yazılım Test ve Kalite Değerlendirme Laboratuvarı ( YTKDL ), TÜBİTAK BİLGEM

8.1. SQA Standartlarının Sınıflandırılması

Yazılım kalite güvence standartları iki ana sınıfa ayrılabilir:

Sertifika ve değerlendirme metodolojileri ( kalite yönetimi standartları ) dâhil olmak üzere yazılım kalite güvence yönetim standartları
Yazılım proje geliştirme süreci standartları ( proje süreci standartları ).

8.2. Kalite Yönetim Standartları

Bunlar, kuruluşun SQA sistemine, altyapısına ve gereksinimlerine odaklanırken, yöntem ve araç seçimi kuruluş tarafından belirlenir. Kalite yönetim standartlarına uyarak, kuruluşlar yazılım ürünlerinin kabul edilebilir bir kalite seviyesine ulaştığından emin olabilirler. ISO 9000-3 ve Yetenek Olgunluk Modeli ( CMM – Capability Maturity Model ) gibi standart bu sınıfa ait bir metodolojinin örnekleridir. Bazı mevcut yazılım geliştirme ihaleleri, katılımcıların kalite yönetim standartlarından birine göre sertifikalandırılmasını gerektirmektedir.

8.3. Proje Süreç Standartları

Bunlar, yazılım geliştirme ve bakım projelerini gerçekleştirme metodolojilerine, yani bir yazılım projesinin nasıl uygulanacağına odaklanmaktadır. Bu standartlar, atılacak adımlar, tasarım dokümantasyonu gereksinimleri, tasarım dokümanlarının içeriği, tasarım gözden geçirmeleri ve gözden geçirme konuları, gerçekleştirilecek yazılım testleri ve test konuları ve benzerlerini tanımlar.

Doğal olarak, özellikleri nedeniyle, bu sınıftaki birçok SQA standardı, yazılım mühendisliği standartları olabilir ve tam tersi de olabilir. Bu iki sınıfın özellikleri aşağıdaki tabloda özetlenmiştir.

Özellikler	Kalite yönetim standartları	Proje süreç standartları
Hedef birim	Yazılım geliştirme ve / veya bakım veya spesifik SQA birimleri yönetimi	Bir yazılım geliştirme ve / veya bakım proje ekibi
Ana odak noktası	SQA sistemlerinin organizasyonu, altyapısı ve gereksinimleri	Yazılım geliştirme ve bakım projeleri yürütmek için metodolojiler
Standardın objektifi	“Neyi” başarmak?	“Nasıl” gerçekleştirmek?
Standardın amacı	Tedarikçinin yazılım kalitesini sağlamak ve yazılım süreci yeteneğini değerlendirmek	Belirli bir yazılım projesinin kalitesinin güvence altına alınması
Örnek Standartlar	ISO 9000-3; SEI’nin CMM’i	ISO/IEC 12207; IEEE Std 1012-1998

8.4. Standartların Kullanım Örnekleri

ISO 9000-3 ve IEEE / IEA 12207, sırasıyla yazılım kalite yönetiminin ve yazılım geliştirme yaşam döngüsünün tüm yönlerini kapsayan kapsamlı standartların örnekleridir. Her iki sınıfın özel standartlarına ilişkin örnekler, yazılım kalite güvence planları için IEEE Std 730-1998, yazılım doğrulama ve doğrulama için IEEE Std 1012-1998 ve yazılım verimliliği metrikleri için IEEE Std 1045-1992 gibi IEEE yazılım mühendisliği standartlarında bulunabilir.

Standartların gelişmekte olan kuruluşların ortak standartlar yayınlama eğiliminin artması, standartların uluslararasılaşmasını teşvik eden bir eğilimdi. Bu “ortak girişimlerin” örnekleri IEEE / ANSI, ISO / IEC ve IEEE / ISO tarafından verilen standartlardır. Beş enstitüyü kapsayan bir “birleşme” örneği, IEEE, IIAE / EIA 12207 olarak adlandırılan EIA ve ANSI tarafından 1996 yılında kabul edilen standart ISO / IEC 12207: 1995’tir. Bir başka paralel ve büyüyen eğilim, uluslararası standartların ulusal standartlar enstitüleri tarafından ulusal standartlar olarak benimsenmesidir. Bu eğilim uluslararasılaşmayı daha da desteklemektedir.

Yukarıdaki gelişmeler dünya çapında yazılım endüstrisi standartlarının uygulanmasına yönelik bir trend başlattı. Bu eğilim, yazım sırasında gözlemlendiği gibi, aşağıdaki standartların evrensel olarak kabul edilen araçlar haline gelmesini garantilemek için üç tamamlayıcı yöne doğru yönlendirilir:

ISO/IEC 9000-3 – Yazılım geliştirme ve bakım organizasyonları için kalite sertifikası standartları

ISO/IEC 15504 – Kurumsal yazılım işlev kabiliyeti / kapasitesi değerlendirilmesi

ISO/IEC/IEEE 12207 – Yazılım geliştirme uygulamaları.

8.5. ISO 9001 ve ISO 9000-3

Uluslararası Standardizasyon Örgütü ( ISO – International Organization for Standardization ) tarafından sunulan Kılavuzlar ( ISO 9000-3 ), kalite yönetimi ISO 9000 Standartlarının genel metodolojisinin özel yazılım geliştirme ve bakım durumu için uygulanmasını temsil etmektedir. Hem ISO 9001 hem de ISO 9000-3, her 5-8 yılda bir gözden geçirilir ve güncellenir, her biri ayrı ayrı ele alınır.

ISO 9000-3 kalite yönetim sistemi: yol gösterici prensipler

Sekiz ilke yeni ISO 9000-3 standardını yönlendirir; bunlar aslen aşağıdaki şekilde ISO 9000: 2000 standardında ( ISO, 2000b ) belirlenmiştir:

(1) Müşteri odaklılık. Organizasyonlar müşterilere bağlıdır ve bu nedenle mevcut ve gelecekteki müşteri ihtiyaçlarını anlamalıdır.

(2) Liderlik. Liderler kuruluşun vizyonunu belirler. İnsanların belirlenen hedefler doğrultusunda kurumun hedeflerine ulaşma konusunda tam olarak yer alabilecekleri bir iç ortam oluşturmalı ve sürdürmelidirler.

(3) İnsanların katılımı. İnsanlar bir örgütün özüdür; Kuruluşun tüm seviyelerindeki insanların tam katılımı, organizasyonun yararına uygulanabilmelerini sağlar.

(4) Süreç yaklaşımı. Faaliyetler ve kaynaklar bir süreç olarak yönetildiğinde, istenen sonuç daha verimli bir şekilde elde edilir.

ISO 9000-3: gereksinimleri

Kalite yönetim sistemiYönetim sorumlulukları Kaynak yönetimiÜrün gerçekleştirmeYönetim, analiz ve iyileştirme

8.6. ISO 9000-3 Sertifikasyon Süreci

ISO 9000-3 sertifikasyon süreci, bir kuruluşun yazılım geliştirme ve bakım süreçlerinin standartların gereksinimlerine tam olarak uyduğunu doğrular. ISO 9000 standartları birçok ülkede ulusal standartlar olarak kabul edildiğinden, yazılım endüstrisi de dahil olmak üzere, birçok endüstride ISO 9000’e göre sertifikasyona dünya çapında ilgi artmaktadır. Sertifikalandırma hizmeti, Uluslararası Standartlaştırma Örgütü ( ISO ) tarafından, akreditasyon kuruluşları ve belgelendirme kuruluşları aracılığıyla yetkilendirilmiş dünya çapında bir sertifikasyon hizmetleri ağı tarafından organize edilmektedir. Her akreditasyon kuruluşu, diğer meslek kuruluşlarını belgelendirme (sertifikalandırma ) kuruluşları olarak yetkilendirmek için ISO tarafından lisanslanmıştır.

Sayıları ülkeye göre değişebilen belgelendirme kuruluşları, fiili sertifikasyon denetimlerini gerçekleştirir ve hak kazanan kuruluşları onaylar.

ISO 9000-3 sertifikası almak isteyen kuruluşlar aşağıdakileri tamamlamamaları gereklidir:

Kendi kuruluşun SQA sistemini geliştirmek
Kendi kuruluşun SQA sistemini uygulamak
Sertifika denetimlerine uğrar.

Bu gereksinimlerin yerine getirilmesi, sertifikasyonla sonuçlanan faaliyetlerin gerçekleştirilmesi için gerekli yapıların ve kaynakların kapsamlı bir şekilde planlanmasını gerektirir.

Bu süreç tasarım ve bakım faaliyetleri ile belgelendirme kuruluşlarının özelliklerine bağlı olarak kuruluştan kuruluşa farklılık gösterebilir. Temel şekli diğer sertifika standartlarının talep ettiği sürece paraleldir.

Yönetim, yazılım geliştirme ve bakım faaliyetleri için ISO 9000-3 sertifikası alma kararını verdiğinde, bir eylem planına ihtiyaç duyar. ISO 9000-3 sertifikalandırılma süreci Şekil 1’de gösterilmiştir.

Sertifika alabilmek için, mevcut SQA sisteminin bir iç araştırması ile onun nasıl uygulandığına bakmak, başlamak için iyi bir yerdir. Öncellikle, kurumla ilgili aşağıdaki konular hakkında bilgi verecek bir ön çalışma yapılmalıdır:

Halihazırda istihdam edilen SQA ile gerekli prosedürler arasındaki boşluklar: yetersiz prosedürlere ek olarak eksik prosedürler.
SQA prosedürleri ve SQA araçları ile ilgili gerekli personelin bilgiler eksiği.
Geliştirme faaliyetlerinin yanı sıra bakım faaliyetleriyle ilgili eksikler.
Yazılım konfigürasyon sistemi yetenekleri ve uygulanması ile ilgili eksiklikler.
Proje ilerleme kontrolü için istenen yönetim uygulamaları ile ilgili eksikler.
SQA birim organizasyonu ve yetenekleri ile ilgili boşluk.
Bu ön çalışmadaki analizi tamamladıktan sonra sertifikasyon alma planı oluşturulabilir. Şekil 1’de ISO 9000-3 Sertifikalandırma süreci detaylı bir şekilde gösterilmiştir.
Şekil 1 ISO 9000-3 sertifikalandırma süreci

8.6.1. Kuruluşun SQA Sisteminin Geliştirmesi

Daha sonra, kuruluşun SQA yönetim sistemi, ISO 9000-3 gereksinimlerini karşılayacak düzeyde geliştirilmelidir. Bunun için şunların dikkate alınması gereklidir:

Kaliteli bir kılavuz ve kapsamlı SQA prosedürlerinin geliştirilmesi.
Diğer SQA altyapısının geliştirilmesi:
- Personel sertifika programları dahil personel eğitimi ve öğretim programları
- Önleyici ve düzeltici eylem prosedürleri
- Yazılım değişikliği kontrol yönetim birimi dahil, konfigürasyon yönetimi hizmetleri
- Belgeler ve kalite kayıt kontrolleri
Bir proje ilerleme kontrol sisteminin geliştirilmesi
8.6.2. Kuruluşun SQA Sistemini Uygulaması
SQA yönetim sisteminin bileşenleri belgelendirme taleplerine uygun hale geldiğinde, sistemin uygulanmasına yönelik çabalar yapılmaktadır. Bunlar arasında, SQA araçlarını uygularken ortaya çıkabilecek problem çözme görevine uygun bir personel talimatı programı ve destek hizmetleri bulunmaktadır.
Bu düzenlemeler, özellikle kendi birimleri tarafından uygulanan uygulama çabalarını takip etmesi ve desteklemesi beklenen takım liderleri ve birim yöneticileri için hedeflenmiştir.
Bu aşama boyunca, uygulamadaki başarının doğrulanması ve ek dikkat gerektiren birimler ile SQA konularının belirlenmesi için iç kalite denetimleri gerçekleştirilmektedir. İç kalite denetim bulguları, kurumun tatmin edici bir uygulama seviyesine ulaşıp ulaşmadığının belirlenmesini sağlayacaktır.

8.6.3. Sertifika Denetimlerinin Yapılması

Sertifika denetimleri iki aşamada gerçekleştirilir:

(1) Kuruluş tarafından geliştirilen kalite kılavuzu ve SQA prosedürlerinin gözden geçirilmesi. İnceleme, eksiksizliği ve doğruluğu tespit eder. Standartlara uyumsuzluk durumunda, organizasyonun, sertifikasyonun ikinci aşamasına ilerlemeden önce düzeltmeleri tamamlaması zorunludur.

(2) Kalite kılavuzu ve SQA prosedürlerinde kuruluş tarafından belirlenen şartlara uygunluğun doğrulanması. Cevaplanması gereken başlıca sorular:

Personel SQA konuları hakkında yeterli şekilde bilgilendirilmiş mi? Tatmin edici bir bilgi seviyesi sergilemekteler mi?İlgili prosedürler ( proje planları, tasarım incelemeleri, ilerleme raporları vb. ) geliştirme ekipleri tarafından doğru ve eksiksiz bir şekilde uygulandı mı?Belge gereksinimleri tam olarak gözlemlendi mi?

Belgelendirme denetimleri için ana bilgi kaynakları: ( a ) denetlenen birim üyeleriyle yapılan görüşmeler ve ( b ) proje planları, tasarım belgeleri, test planları ve prosedürleri ile tasarım inceleme kayıtları gibi belgelerin incelenmesidir. Güvenilir sonuçlar sağlamak ve önyargılı sonuçlardan kaçınmak için, denetimler rastgele bir proje ve/veya rastgele takım seçimine dayanır.

Sertifika alındıktan sonra, ISO 9000-3 gerekliliklerine sürekli uyumu doğrulamak için genellikle yılda bir veya iki kez gerçekleştirilen periyodik yeniden belgelendirme denetimleri gerçekleştirilir. Bu denetimler sırasında kuruluşun, kalite ve verimlilik performansı iyileştirmelerini ve SQA yönetim sisteminin sürekli gelişimini göstermesi gerekmektedir.

8.7. Yapılandırılmış Test: McCabe Karmaşıklık Ölçütünü Kullanan Bir Test Metodolojisi

Bu metodoloji, NIST’in ( National Institute of Standards and Technology – Ulusal Standartlar ve Teknoloji Enstitüsü) özel bir yayınıdır. NIST’in Bilgisayar Sistemleri Laboratuvarı ( Computer Systems Laboratory – CSL ), çeşitli standartlar ve yönergeler geliştirir, teknik destek sağlar ve bilgi teknolojisi kaynaklarının daha etkin kullanımı için bilgisayar ve ilgili telekomünikasyon sistemleri için araştırmalar yapar. Bilgisayar Sistemleri Laboratuvarının sorumlulukları arasında, federal bilgisayarlarda işlenen hassas sınıflandırılmamış bilgilerin maliyet etkin güvenlik ve gizliliği için teknik, yönetim, fiziksel ve idari standartların ve kılavuzların geliştirilmesi yer alır.

McCabe Karmaşıklık Ölçütünü Kullanan Bir Test Metodolojisi belgesinin amacı, aynı zamanda temel yol testi olarak da bilinen, yazılım testi için yapılandırılmış test metodolojisini tanımlamaktır. McCabe’nin karmaşıklık ölçüsüne dayanarak, yapılandırılmış test, yol kapsamı kriterlerini oluşturmak için yazılımın kontrol akış yapısını kullanır. Elde edilen test setleri, ifade ve yüzeysel bir anlatımdan daha kapsamlı bir test sağlar. Entegrasyon testleri ve nesne yönelimli sistemler için temel yapılandırılmış test tekniklerinin uzantıları da sunulmaktadır. Birkaç ilgili yazılım karmaşıklığı metriği açıklanmıştır. Bu çalışmada, teknik makaleler özetleri, örnek olay incelemeleri metodolojinin eklerde sunulmuştur.

8.8. Capability Maturity Model Integration (CMMI)

1986 yılında Carnegie Mellon Üniversitesinin Yazılım Mühendisliği Enstitüsü ( Software Engineering Institute ), bir yetenek olgunluk modeli ( CMM ) olarak adlandırılan şeyin gelişimine yönelik ilk adımları attı. 1990’ların sonlarında ise yeni bir gelişim yönü alındı – Integrated CMM ( Bütünleşik CMM ) modellerinin geliştirilmesi.

Capability Maturity Model Integration ( CMMI ), Türkçede “Bütünleşik Yetenek Olgunluk Modeli” olarak bilinmektedir. Bu model, birçok alan için etkili süreçleri içeren bir modeldir. Düzensiz süreçleri daha düzenli ve disiplinli süreçler haline getirmeyi amaçlar.

CMM değerlendirmesi aşağıdaki kavram ve prensiplere dayanmaktadır:

Nicel yaklaşımlara dayalı daha ayrıntılı yönetim yöntemlerinin uygulanması, kuruluşun kaliteyi kontrol etme ve yazılım geliştirme sürecinin verimliliğini artırma kapasitesini artırır.Model, bir kuruluşun başarılarını değerlendirmesini ve iyileştirme gerektiren süreç alanlarını belirleyerek bir sonraki yeterlilik seviyesine ulaşmak için gereken çabaların belirlenmesini sağlar.İşlem alanları geneldir; “Nasıl”ı değil, “Ne”yi belirler. Bu yaklaşım, modelin çok çeşitli uygulama organizasyonlarına uygulanmasını sağlar çünkü:Herhangi bir yaşam döngüsü modelinin kullanılmasına izin verir;Herhangi bir tasarım metodolojisi, yazılım geliştirme aracı ve programlama dilinin kullanılmasına izin verir;Belli bir belge standardı belirtmez.

Model üç bileşenden oluşmaktadır, bunlar: gerekli, beklenen ve bilgi amaçlı bileşenleridir.

Gerekli bileşenler: bir kuruluşun özel ve genel amaçlarıdır.

Beklenen bileşenler: bir kuruluşun kendi amacına ulaşabilmesi için yapması gerekenlerdir. Bunlar özel ve genel uygulamalardır.

Bilgi Amaçlı bileşenler: bir kuruluşun amacına ve beklenen uygulamasına nasıl ulaşılabilir konusunda bilgileri içeren uygulama notları, alt programlar ve iş ürünleri gibi bileşenlerdir.

Bu süreç alanı bileşenleri Şekil 2’de gösterilmiştir.

CMM (Capability Maturity Model ) normları, aşağıdaki aşağıda madde madde şeklinde verilen yazılımın yanında farklı alanlar için de tanımlamıştır,

Yazılım mühendisliği;
Tümleşik ürün geliştirme;
Sistem mühendisliği;
Tedarik yönetimi.
8.9. CMMI Sertifika Seviyeleri

Seviye 1: Initial – Baslangıç Yazılım geliştirme süreci, genel olarak kaotik bir ortamda yol almaktadır. Bu yolda amaca doğru ilerlerken başarı ancak kişisel çabalar ile sağlanmaktadır. Herhangi bir kriz durumunda, olsa bile tüm planlar unutulur, hatırlanmaz; yok sayılır. Destek sağlanacak yetenekler, beyin fırtınaları önceden düşünülmez.

Seviye 2: Repeat – Tekrarlama Projeler planlıdır, başarı adım adım gelir. Süreçler ölçülür ve kontrol edilir. İş dağılımı yapılmış, ekip birbirleri ile haberdar, sağlıklı bir iletişim ortamı oluşturulmuştur. Yazılım süreçindeki tüm işlevlerin gereksinimleri, çıktıları yönetilmektedir. Projedeki tüm paydaşların talep ve değişiklik istekleri anında göz önüne alınmakta ve değişiklikler sürekli revize edilerek işlevsellik sağlanmaktadır.

Seviye 3: Define – Tanım Tüm süreçler standartlar, prosedürler, normlar ile açıklanır. Standartlaşan süreç işlevleri organizasyonel boyutta kabul görmüş ve tutarlıdır. Projeler, yaşayan organizmalara dönüştürülmüştür. Tüm işlevler özenli ve detaylı olarak tanımlanmıştır.

Seviye 4: Manage – Yönetme Süreçler ve işlevler istatistiksel ve diğer ölçüm teknikleri ile kontrol edilir. Kalite ve süreç performansı yönetimde bir kriter olarak kullanılır. Ölçeklendirilmiş hedefler, paydaşların ihtiyaç ve istekleri, temel alınarak belirlenir. Süreçler ölçülür ve zarfsal yani genişliği değişken sınırlar içerisinde gerçek veriler baz alınarak öngörüde bulunulur.

Seviye 5: Optimize – İyileştirme, Hassas işlevlerin belirlenmesi, özellikle kaotik davranışı başlatacak hassas süreçlerde, sayısal geri beslemeler ve teknolojilerden yararlanılarak sürekli iyileştirilme yapılır. Tüm organizasyon süreç iyileştirmeye odaklanmıştır. Yazılım geliştirme süreç yeteneği “Sürekli İyileşen” olarak tanımlanabilir. Bu seviye, süreç değişkenliğinin nedenlerini bulma ile ilgilenir. ( bknz. Şekil 2 )

Şekil 3 Süreç Alanı bileşenleri şeması

CMM’ye göre seviye 5 değerlendirmesine ulaşan şirketler tarafından bildirilen başarı hikayelerini, yatırım çabalarını ve kazanılan faydaları gözden geçirmeye değer.

Bu örnek durumlar: Boeing’in Uzay Taşımacılığı Sistemleri Yazılımı; Tata Danışmanlık Hizmetleri ( TCS ); Telcordia Teknolojileri; Gartner A.Ş.

Örneğin, Boeing’in Uzay Taşımacılığı Sistemleri Yazılımı

Wigle ve Yamamura (1999), Boeing için CMM seviye 5’i ortaya çıkaran üç yıllık kademeli kalite güvence iyileştirme sürecini tartışmaktadır. Seviye 5 projelerinde gerçekleştirilen iyileştirmeler şunları içermektedir:

Çeşitli gözden geçirme yöntemlerinin uygulanmasıyla % 83 erken saptamaya kadar yapılan testlerle % 89 geç saptamadan arıza tespitinde önemli bir değişiklik.
Arızaların daha erken tespit edilmesi, yeniden çalışma çabalarında % 31’lik bir azalmaya neden oldu.
Sürümün yayımlanmasından önce kusurların giderilmesi % 94’ten % 100’e yükseldi.
Genel üretkenlikte % 140’lık bir artış.

CMMI genellikle Bilgi Teknolojileri sektöründe ve özellikle yazılım geliştirme konularında uygulamaya yönelik referans normlar geliştirmektedir.

CASE Araçları ve Onların Yazılım Kalitesine Olan Katkısı

9.bölüm

Bölüm Hedefi

Hayatımızı kolaylaştıran yazılımların geliştirilmesi oldukça zordur. Ancak, bu yazılımların geliştirilmesini kolaylaştıran araçlar da mevcuttur. Bu bölümde, tam da bu CASE araçlarından ve onların türlerinden bahsedilmiştir.

CASE kısaltımının açılımı Computer Aided Software Engineering’dir, yani Bilgisayar Destekli Yazılım Mühendisliği. Yazılım projelerinin geliştirilmesi ve bakımı çeşitli otomatik yazılım araçlarının yardımıyla da yapılabileceği görülmektedir. CASE araçları, yazılım geliştirme sürecinin otomatik olarak yapılabilmesine yardımcı olan yazılım uygulamalarından oluşmaktadır.

Yazılım geliştirme yaşam döngüsünün çeşitli aşamalarını basitleştirmek için Analiz araçları, Tasarım araçları, Proje yönetim araçları, Veri Tabanı Yönetimi araçları, Belgeleme araçları gibi birçok CASE aracı vardır.

CASE araçlarının kullanımı, istenen sonucu üretmek için projenin gelişimini hızlandırır. Ayrıca, yazılım geliştirmede bir sonraki aşamaya geçmeden önce kusurları ortaya çıkarmaya yardımcı olur.

Etkileşimli hata ayıklayıcılar ( debugger ), derleyiciler ve proje gelişme yönetim sistemleri gibi yazılım geliştirmeye destek veren araçları klasik CASE araçları olarak düşünülebilir. Ancak, gerçek CASE araçlarına bakıldığı zaman, geleneksel olarak üst seviyeCASE araçları ( analiz ve tasarım aşamaları için ), alt seviye CASE araçları ( kodlama aşaması için ) ve entegre edilmiş CASE araçları ( tasarım ve kodlama aşamalarına yardımcı olmak için ) şeklinde incelenir. CASE araçlarının seviyelere ayrılması Şekil 1’de incelenebilir.

Şekil 1 CASE araçlarının ayrıştırılması

Şekilde, yazılım geliştirme sürecinin Planlama, Analiz etme ve Tasarım aşamalarında üst seviye (upper) CASE araçları; Uygulama ve Çalıştırma ( implementation ), Test etme (testing) ve bakım ( maintenance ) aşamalarında alt seviye (lower) CASE araçları; Gerçek CASE araçlarının ana bileşeni olan depo ( repository ), proje ile ilgili tüm bilgileri saklar. Proje geliştirilmeye devam ettikçe, üzerinde yapılan tüm değişiklik ve ilerlemeler depoda saklanmaktadır. Kullanılan bu CASE araçları her zaman projeye dair güncel belgelendirmenin indirilmesi imkânını sunar. Bazı alt seviye ve entegre edilmiş CASE araçları, depoda mevcut olan tasarım bilgilerini kod haline çevirebilmektedirler.

Bazı alt seviye CASE araçları ile entegre edilmiş CASE araçları, depoda mevcut olan tasarım bilgilere dayanarak otomatik olarak kod üretebilir. Ayrıca, tersine mühendislik ( re-engineering ) araçları da gerçek CASE araçları olarak düşünülebilir. Kullanılmakta olan ( ya da “eski” (legacy) ) yazılımın kurtarılma ve kopyalanma gibi işlemlerini sistem kodunu kullanarak gerçekleştirir. Tersine mühendislik araçları, genel CASE araçlarının çalışma akışının ters yönünde çalışır. Başka bir ifadeyle, CASE araçları depodaki tasarım bilgilerine göre kod üretirken, tersine mühendislik araçları, mevcut olan sistem kodlarına göre güncel bir depo ve tasarım belgelerini oluşturur.

9.1. CASE Aracının Yazılım Ürün Kalitesine Olan Katkısı

CASE araçları, yazılım geliştirme aşamasının her birinde karşılaşılan hataların sayısını azaltarak, geliştirilmekte olan yazılım ürününün daha kaliteli olmasında yardımcı olur. CASE araçlarının kullandığı depolarda proje aşamalarının kayıtlarının tutulduğu belirtilmişti. Kayıtlar arasında proje gereksinimleriyle ilgili bilgiler de saklanmaktadır. Dolayısıyla, yerine getirilmesi gereken bu gereksinimler, CASE araçları tarafından otomatik olarak hatırlatılmaktadır ya da bir hata / sorun olarak gözükmektedir. Bu da, geliştiricinin işini kolaylaştırır.

Ayrıca, alt seviye CASE araçlarının otomatik kod tamamlama özellikleri, kodlamadaki olası hataları büyük sayıda indirgemektedir. Bu da, geliştiricinin hata yapma olasılığını azaltarak, projenin ilerlemesine yardımcı olur.

Otomatik belgelendirmede yardımcı olan CASE araçları, belgelendirme sürecinin ve belgelerin daha az hata içermesine yol açar. Şekil 2’de, yazılım geliştirme sürecinde CASE araçlarından faydalanılarak ve CASE araçlarından faydalanmadan hareket edilen yazılım hayat döngüleri gösterilmiştir.

Şekil 2 CASE araçlarından faydalanılan ve faydalanılmayan geliştirme süreçleri

9.2. CASE Araçların Türleri

Diyagram Araçları ( Diagram Tools )

Bu araçlar, çeşitli yazılım bileşenleri ve sistem yapısı arasındaki bileşenleri, verileri ve kontrol akışını grafik bir biçimde temsil etmek için kullanılır. Örneğin, akış şemaları oluşturmak için Akış Şeması Oluşturucusu ( Flow Chart Maker ) aracı kullanılabilir.

Süreç Modelleme Araçları ( Process Modeling Tools )

Süreç modelleme, yazılımı geliştirmek için kullanılan yazılım sürecinin modelini oluşturmak için kullanılan bir yöntemdir. Süreç modelleme araçları, yöneticilerin bir süreç modelini seçmelerine veya yazılım ürününün gereksinimine göre değiştirmelerine yardımcı olur. Örneğin, EPF Composer uygulaması

Proje Yönetim Araçları ( Project Management Tools )

Bu araçlar proje planlama, maliyet ve çaba tahmini, proje planlama ve kaynak planlaması için kullanılır. Yöneticiler, yazılım proje yönetiminde sözü edilen her adımla, proje uygulamasına sıkı sıkıya uymak zorundadırlar. Proje yönetim araçları, proje bilgilerini proje süresince gerçek zamanlı olarak saklama ve paylaşma konusunda yardımcı olur. Örneğin, Creative Pro Ofisi, Trac Project ve Basecamp.

Belgelendirme Araçları ( Documentation Tools )

Bir yazılım projesindeki belgeleme yazılım sürecinden önce başlar, geliştirme sürecinin tüm aşamalarında ve projenin tamamlanmasından sonra da devam eder.

Belgeler, teknik kullanıcılar ve son kullanıcılar için ayrı ayrı belgeler oluşturur. Geliştirme ekibinin teknik kullanıcılarının çoğu sistem el kitabına, başvuru kılavuzuna, eğitim kılavuzuna, kurulum kılavuzlarına vb. başvuruda bulunan profesyonelleridir. Son kullanıcı belgeleri ise, sistemin kullanıcı el kitabıdır. Sistemin işleyişini ve istenilen işlevin nasıl yapıldığını anlatır. Örneğin, belgeleme için Doxygen, DrExplain, Adobe RoboHelp vb. kullanılabilir.

Analiz Araçları ( Analysis Tools )

Bu araçlar, gereksinimlerin toplanmasına yardımcı olur, herhangi bir tutarsızlığı, diyagramlardaki yanlışlıkları, veri yedeklerini veya hatalı ihmalleri otomatik olarak kontrol eder. Örneğin, gereksinim analizi için Accept 360, Accompa, CaseComplete, toplam analiz için Visible Analyst.

Tasarım Araçları ( Design Tools )

Bu araçlar, yazılım tasarımcılarının, yazılımın blok yapısını tasarlamalarına yardımcı olur; bu, ise, iyileştirme tekniklerinin kullanımıyla daha küçük modüllere ayrıştırılabilir. Bu araçlar her modülün detaylarının tutulmasını ve modüller arası bağlantılarının olmasını sağlar. Örneğin, Animated Software Design.

Yapılandırma Yönetimi Araçları ( Configuration Management Tools )

Yazılımın bir örneği tek bir sürüm altında yayınlanır. Yapılandırma Yönetimi araçları aşağıdakiler ile ilgilenir:

Versiyon ve revizyon yönetimi
Temel yapılandırma yönetimi
Değişiklikler denetiminin yönetimi

Bu konularda, CASE araçları, otomatik kayıt, sürüm yönetimi ve yayınlama yönetim yöntemleriyle yardımcı olur. Örneğin, Fossil, Git, Accu REV.

Değişiklikleri Denetleme Araçları ( Change Control Tools )

Bu araçlar, yapılandırma yönetimi araçlarının bir parçası olarak kabul edilir. Yazılımın temeli sabitlendikten sonra yapılan değişikliklerle veya yazılımın ilk kez yayınlandıktan sonra yapılan değişikliklerle uğraşır. CASE araçları değişiklik izleme, dosya yönetimi, kod yönetimi ve daha fazlasını otomatik hale getirir. Ayrıca organizasyonun politika ve kurallarında değişiklik yaparak güçlendirilmesinde de yardımcı olur.

Programlama Araçları ( Programming Tools )

Bu araçlar, IDE ( Integrated Development Environment – Entegre Geliştirme Ortamı ) gibi geliştirme araçlardan, kod içerisinde bulunan yerleşik modüllerin kütüphanesi ve simülasyon araçları gibi programlama ortamlarından oluşmaktadır. Bu araçlar, yazılım ürününün oluşturulmasında kolaylık sağlamakta ve simülasyon ile testler için gerekli özellikleri içerir. Örneğin, Cscope, Eclipse’de C kodunu aramak için kullanılan bir araç.

Prototip Araçları ( Prototype Tools )

Yazılım prototipi, geliştirilmesi amaçlanan yazılım ürününün örnek ve simüle edilmiş halidir. Prototip, ürünün ilk görünümünü ve hissini sağlar ve gerçek ürünün birkaç yönünü simüle eder. Bu prototip CASE araçları esas olarak grafik kütüphaneleri ile ortaya gelir. Donanıma bağımsız kullanıcı arayüzleri tasarlayabilirler. Bu araçlar mevcut bilgilere dayanarak prototipleri hızlı bir şekilde oluşturmamıza yardımcı olur. Örnek araçlar, Serena prototype composer, Mockup Builder vb.

Web Geliştirme Araçları ( Web Development Tools )

Bu araçlar, web sayfalarını tüm form, metin, komut dosyası, grafik gibi birleşik elemanlarıyla birlikte tasarlamaya yardımcı olur. Web araçları ayrıca nelerin geliştirildiğini ve tamamlandıktan sonra nasıl görüneceğini canlı olarak sunar. Örneğin, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.

Kalite Güvence Araçları ( Quality Assurance Tools )

Bir yazılım kuruluşunda kalite güvencesi, kuruluş standartlarına göre kalitenin uygunluğunu sağlayan bir yazılım ürününü geliştirmek için kabul edilen yöntemleri izlemektedir. Kalite Güvence araçları, yapılandırma ve değişiklik kontrol araçları ile yazılım test araçlarından oluşur. Örneğin, SoapTest, AppsWatch, JMeter.

Bakım Araçları ( Maintenance Tools )

Yazılım bakımı, yazılım ürününün müşteriye teslim edildikten sonra üzerinde yapılan değişiklikleri içerir. Bu bakım aşamasında yazılım kurumuna yardımcı olan birkaç CASE aracı vardır. Örneğin, hata kayıtları için kullanılan Bugzilla

9.3. CASE Aracının Yazılım Bakımı Sürecindeki Katkısı

Otomatik olarak kayıt tutan CASE araçları, yazılım geliştirme sürecinin kodlarda değişiklik, planlamalarda değişiklik, gereksinimlerde yapılan değişiklikler ve belgelendirme gibi önemli aşamalarında yapılan gelişme ve güncelleme bilgilerini saklamaktadır. Dolayısıyla, bu değişikliklerin sonucunda oluşan başarı ve başarısızlıklar, ileriki aşamalarda doğru yol gösterir. Bakım sürecinde de bu kayıtlı olan bilgiler ışığında, hata yapılan aşamaya geri dönerek yeniden düzeltmeler yapılabilir.

9.4. CASE Aracının Gelişmiş Proje Yönetimine Olan Katkısı

Genellikle, CASE araçlarının kullanımının amacı proje geliştirme sürecini hızlandırmak ve proje için gerekli mali kaynağı azaltmaktır. Projede yapılan değişiklikleri takip ederek, hata yapma olasılığını azaltabilmesiyle, CASE araçlarının, zaman tablosu ile kaynak denetimini kısmen yaptığı söylenebilir. Yalnız, tam da zaman tablosuna ve kaynak yönetimine odaklı araçların geliştirilmesi gerekir.

9.5. Bir Yazılım Projesinde CASE Araçlarının Kullanım Örneği

Bir A şirketi olsun. Bu şirkette uzun süredir ( yaklaşık 10-15 sene diyelim ) bir yazılım ürünü üzerinde çalışılmaktadır. Bildiğimiz üzere birçok yazılım ürün çeşidi vardır. Piyasada en çok geliştirilenlerden ise masaüstü uygulamaları, web siteleri ve mobil uygulamalarıdır.

A şirketi ise, artık yaygın olarak kullanılmaya başlayan bulut bilişim hizmetlerinden faydalanmaktadır ve onlardan biri olan PaaS sistemi üzerinde bir web sitesini çalıştırmaktadır.

Hizmet olarak Platform – Platform As A Service ( PaaS ), bir web uygulamasının yaşam döngüsü sürecinde gerekli olan tüm kaynakları sağlamaktadır. Örneğin, sunucu, depolama ve ağ gibi altyapıları sunmaktadır. Ayrıca, sistemin test edilebilmesi, güncellenebilmesi ve yönetilebilmesi gibi önemli aşamalarda desteklemektedir. Ancak, konumuz PaaS değildir ve örneğe devam edelim.

A şirketi, web sitesini Java programlama dili kullanarak geliştirmiş olsun. Kullandıkları sunucuya sürekli olarak yeni gelişmeleri göndererek, onları mevcut olan kodlarla birleştirmektedir. Bu işlemler sürecinde, kodlarda yapılan değişiklikler Git versiyon kontrol sistemiyle denetleniyor ve değişikliklerin kaydı tutuluyor; geliştiriciler arasındaki görev paylaşımı, yani işlerin paylaştırılması Redmine isimli iş kontrol sistemiyle yapılıyor. Aynı zamanda, sistem testçileri tarafından web uygulamanın çalışıp çalışmadığı kontrol edilerek, sorunlu kısımlar düzeltilmesi amacıyla geliştiricilere bildirilir.

Örnek olarak verilen A şirketinin sahip olduğu yazılımın bu tarz bakım süreçlerinde ismi geçen araçlar birer CASE aracıdır. Bunlara alternatif olarak kullanılabilecek araç sayısı çoktur.

Yazılım Kalite Yönetim Bileşenleri bölüm 10

Bölüm Hedefi

Bu bölümde bir yazılım projesinin nasıl yönetilmesi gerektiği konusu anlatılmıştır. Proje geliştirme aşamasında dikkat edilmesi gereken noktalar vurgulanmıştır. Çünkü proje geliştirme sürecinde, ortaya kaliteli bir ürün üretilebilmesi için projenin temin ettiği bütçe, kaynak gibi unsurların da dikkate alınması ve ölçümlerinin hesaplanması gerekmektedir. Bu da, bu bölümde bahsedilen Yazılım Kalite Yönetiminin önemini vurgulamaktadır.

Proje aşamalarını tamamlamadaki gecikme süreleri ve yüzde onluk bütçe aşımlarını aşmalar bir proje yönetimi için “kırmızı bayraklar” dır. Esas olarak yönetimin kendisinde olan bu olaylar, aşağıdaki gibi durumlardan kaynaklanır:

Aşırı veya hatta körü körüne iyimser planlama ve bütçeleme ( genellikle teklif başlangıç aşamasında ).Profesyonel olmayan yazılım riski yönetimi, yazılım risklerine karşı talihsiz veya uygunsuz reaksiyonlar olarak ifade edilir.Planın ve bütçe zorluklarının gecikmeli olarak tespit edilmesi ve / veya kapsamlarının azımsanması.

İlk tipteki durumlar sözleşme inceleme ve proje planlama araçları kullanılarak önlenebilir. Proje ilerleme kontrolünün ikinci ve üçüncü tip durumları engellemesi beklenir.

Tasarım incelemeleri, teftişler ve yazılım testleri bir projenin profesyonel ( teknik-işlevsel ) yönlerine odaklanırken, proje ilerleme kontrolü, temel olarak takvim hazırlama, insan ve diğer kaynaklar, bütçe ve risk yönetimi gibi yönetsel yönleriyle ilgilidir.

10.1. Proje İlerleme Kontrolü Bileşenleri

Proje ilerleme kontrolü ( CMM “yazılım proje takibi” terimini kullanır ) çabucak yapılması gereken bir hedefe sahiptir: düzensiz olayların erken tespiti. Algılama, problem çözme yanıtlarının zamanında başlatılmasını teşvik eder. İlerleme kontrolü ile ilgili birikmiş bilgiler, başarılar ve aşırı başarısızlıklar da uzun vadeli bir amaca hizmet eder: düzeltici eylemlerin başlatılması.

Proje ilerleme kontrolünün ana bileşenleri şunlardır:

Risk yönetimi faaliyetlerinin kontrolü
Proje çizelgesi kontrolü
Proje kaynak kontrolü
Proje bütçe kontrolü.
10.2. Risk Yönetimi Faaliyetlerinin Kontrolü
Risk yönetimi faaliyetlerinin kontrolü, sözleşme incelemesi ve proje planı belgelerinde belirtilen yazılım risk maddelerine ilişkin olarak atılan ve projenin ilerlemesi sırasında daha sonra tespit edilen risk unsurları ile ilgili eylemleri ifade eder. Uygulamada, yazılım geliştirme ekibi sistematik risk yönetimi faaliyetleri uygulayarak riski azaltmaya çalışır. Yönetim bu çalışmaları periyodik raporların gözden geçirilmesi ve ilerleme bilgisinin değerlendirilmesi yoluyla kontrol eder. Bu ilerleme kontrolü bileşeni doğrudan projenin işlevsel ve teknik hedeflerine ulaşılmasına katkıda bulunur.
Açıklamaları görmek için başlıklara tıklayınız.
Proje çizelgesi kontrolü
Proje çizelgesi kontrolü, projenin onaylanmış ve sözleşmeli programlarına uygun olarak ilgilenir. İzleme, planlanan faaliyetlerin tamamlanmasında gecikmelerin tespit edilmesini sağlayan periyodik raporlara ek olarak kilometre taşlarına dayandırılmaktadır. Sözleşmede belirtildiği gibi, müşteri tarafından talep edilen kilometre taşlarına özel önem verilmektedir. Yönetim, projenin tamamlanma tarihlerini önemli ölçüde etkilemekle tehdit eden kritik gecikmeler üzerinde denetimi odaklama eğilimindedir.
Proje kaynak kontrolü
Proje kaynak kontrolü profesyonel insan kaynaklarına odaklanır; Ayrıca, gerçek zamanlı yazılım sistemleri ve ürün yazılımı tarafından genellikle gerekli olan yazılım geliştirme ve test olanakları ile ilgilenir. Yönetim, mevcut proje ilerlemesi açısından bakılması gereken, kullanılan kaynakların periyodik raporlarına dayanarak kontrolü kullanır.

Proje bütçe kontrolü

Proje bütçe kontrolü, planlanan maliyetlerle mevcut maliyetlerin karşılaştırılmasına dayanır. Kontrol edilecek ana bütçe kalemleri şunlardır:

İnsan kaynakları
Geliştirme ve test tesisleri
COTS yazılımının satın alınması
Donanım alımı
Alt yüklenicilere yapılan ödemeler.

Bütçe kontrolü, dönüm noktalarının yanı sıra dönemsel raporlarla iletilen girdileri gerektirir. Bu raporlar, proje karlılığını etkileyen bütçe aşımlarının erken tespitine izin verir. İlerleme kontrolünün diğer bileşenlerinin önemsenmemesi, proje ilerleme kontrolünün etkinliğini önemli ölçüde azaltması beklenmektedir. Süreç kontrolünün diğer bileşenlerinin, bütçe kontrolünün yapabildiğinden önceki sapma durumlarını tespit etmesi beklenir.

COTS Yazılımı ( COTS Software )
Commercial Off The Shelf (COTS), Türkçesi “Hazır Ticari Ürün”. Bir COTS ürünü, genellikle belirli kullanımlar için hazırlanmış ve genel kullanıma açık bir bilgisayar donanımı veya yazılım ürünüdür. Bu tür ürünler kolayca temin edilebilecek ve kullanıcı dostu olacak şekilde tasarlanmıştır. Bir COTS ürününün tipik bir örneği Microsoft Office veya antivirüs yazılımıdır. Bir COTS ürünü genellikle rafta mevcut olan ve kurulumdan önce özel bir geliştirme gerektirmeyen herhangi bir üründür.

Techopedia Sözlüğü

10.3. Proje İlerleme Kontrol Rejimlerinin Uygulanması

Proje ilerleme kontrolü genellikle aşağıdakileri belirleyen prosedürlere dayanır:

Proje özellikleri için, boyut dahil olmak üzere, uygun olan süreç kontrol görevlerinin yerine getirilmesi için sorumluluk paylaşımı:İlerleme kontrol görevlerini yürütmekten sorumlu kişi veya yönetim birimiHer bir projenin biriminden ve idari seviyeden gerekli raporlama sıklığıProje liderlerinin yönetimi hemen rapor etmesini gerektiren durumlarÜst yönetimine acil raporlama durumları için daha düşük yönetim gerektiren durumlar.Temel olarak, proje ilerlemesinin yönetim denetimleri bunlar ile ilgilenir: proje liderleri ve alt düzey yöneticiler tarafından üst düzey yöneticilere ne kadar ilerleme raporları iletilir;başlatılacak olan özel yönetim kontrol faaliyetleri.

Büyük yazılım geliştirme organizasyonlarında, proje ilerleme kontrolü, yazılım departmanı yönetimi, yazılım bölümü yönetimi ve üst yönetim gibi çeşitli yönetim düzeylerinde gerçekleştirilebilir.

Her bir seviyenin kendi proje ilerleme kontrol rejimini tanımlaması beklense de, projenin o bölgeden ilerlemesini değerlendirmek için yeterli kabul edilen parametreleri yansıtan bir unsur olsa da, ilerlemenin etkili olabilmesi için çeşitli seviyeler arasındaki koordinasyon zorunludur.

Raporlama zincirinin tamamı en düşük yönetim seviyesinden – proje liderinin periyodik ilerleme raporundan – bilgi risklerinin durumunu, proje programını ve kaynak kullanımını, yani ilerleme kontrolünün ilk üç bileşenini özetleyen bilgileri iletir. Proje lideri, takım liderlerinden toplanan bilgilere ilişkin ilerleme raporunu dayandırır. Bir proje liderinin proje ilerleme raporunun bir örneği Şekil 1’de sunulmuştur.

Şekil 1 Bir proje ilerleme raporu örneği

10.4. Proje İlerleme Kontrolü İçin Bilgisayar Araçları

Yazılım proje ilerleme kontrolü için kullanılan bilgisayar araçları, bir yandan projelerin artan büyüklüğü ve karmaşıklığı ve yanlarında getirdikleri faydalar göz önünde bulundurulduğunda açık bir gerekliliktir. Uzun yıllardır piyasada bulunan kapsamlı proje yönetim araçları, yazılım projelerinin kontrol bileşenlerinin çoğuna oldukça etkili ve verimli bir şekilde hizmet edebilir. Bu genel amaçlı paketlerin çoğunluğu PERT / CPM analizini uygular, böylece sonuç raporları faaliyetlerin etkileşimi ve her bir faaliyetin kritikliği dikkate alınır. Bu paketler genellikle sundukları çok çeşitli seçenekler sayesinde belirli durumlara kolayca uyarlanabilir. Bilgisayarlı araçların sağlayabileceği servis örnekleri aşağıdaki gibidir.

Risk yönetimi faaliyetlerinin kontrolü

Kategoriye göre yazılım risk maddelerinin listesi ve planlanan çözüm tarihleri.
Yazılım risk maddelerinin istisnaları listesi – proje tamamlanma tarihini etkileyebilecek taşma çözüm tarihleri.

Proje zamanlaması kontrolü

Gecikmiş faaliyetlerin sınıflandırılmış listeleri.
Kritik faaliyetlerin gecikmeli sınıflandırılmış listeleri – düzeltilmediği takdirde projenin tamamlanma tarihini etkileyebilecek gecikmeler.
İlerleme raporlarına ve uygulanan düzeltme önlemlerine göre oluşturulan güncellenmiş etkinlik çizelgelerin ( takımlar, geliştirme birimleri vb. için ).
Gecikmiş aşamaların sınıflandırılmış listeleri.
İlerleme raporlarına ve uygulanan düzeltici önlemlere göre oluşturulan ölçülerin güncellenmiş zaman çizelgeleri ( takımlar, geliştirme birimleri vb. için ).
Program Değerlendirme ve Gözden Geçirme Tekniği
( PERT ( Program Evaluation and Review Technique ) Analyzing )
Program Değerlendirme ve Gözden Geçirme Tekniği (PERT), belirli bir projeyi tamamlamakla ilgili görevleri analiz etmek ve temsil etmek için bir proje planlama tekniğidir. Etkinlik süresi değişkenliğini içerir ve kritik yol yöntemi (CMP) ile benzer kavramlara dayanır.
PM Knowledge Center
Kritik Yol Yöntemi
( CMP (Critical Path Method) Analyzing )
Kritik Yol Yöntemi (CPM), belirli bir projeyi tamamlamakla ilgili görevleri analiz etmek ve temsil etmek için bir proje planlama tekniğidir. Bir faaliyetin süresi ve maliyeti arasında bir takas içerir ve program değerlendirme ve gözden geçirme tekniğine (PERT) benzer kavramlara dayanır.
PM Knowledge Center

10.5. Kalite Metrikleri

Yazılım Kalite Yönetimi bileşenlerinin bir diğeri metriklerdir. Tom DeMarco’nun “Ölçemediğin şeyi kontrol edemezsin” sözü, yazılım sektöründe kalite ölçütlerini geliştirmeye ve uygulamaya çalışan yazılım kalitesi uzmanlarının sloganı oldu.

Metrik ( Metrics )
Bir metrik, nicel bir ölçek ve ölçmek için kullanılabilecek bir yöntemdir.

[ISO 14598]

Yaygın olarak, diğer sektörlerde olduğu gibi, kalite ölçümlerinin, üç temel alanda yönetime yardımcı olmak için kullanılan temel araçlar arasında, yazılıma dahil edilmesi gerektiğine inanılmaktadır: yazılım geliştirme projelerinin kontrolü ve yazılım bakımı, karar alma desteğinin alınması ve düzeltici eylemlerin başlatılması. Metrik verilerinin; istatistiksel analizinin, yeni geliştirme araçlarının, değişen prosedürlerin ve diğer müdahalelerin uygulanması sonucunda başlatılan ( tanımlayıcı ve istatistiksel olarak anlamlı ) değişiklikleri saptaması beklenmektedir.

Örneğin, McCabe’in karmaşıklık ölçütünün hesaplanması bir kalite metriği olarak sayılır. Bu ölçüt, bir program kodunun hatalara meyilli olduğunu gösterir. Bu da, kodların riskli olduğunun anlamına gelmektedir. Bu karmaşıklık, döngüsel karmaşıklık ( Cyclomatic complexity ) olarak da bilinir.

Döngüsel Karmaşıklık, tek bir yazılım modülünde karar mantığı miktarını ölçer. Yapılandırılmış test metodolojisinde iki bağlantılı amaç için kullanılır. İlk olarak, yazılım için önerilen testlerin sayısını verir. İkincisi, yazılımın güvenilir, test edilebilir ve yönetilebilir olmasını sağlamak için tasarımdan başlayarak yazılım yaşam döngüsünün tüm aşamalarında kullanılır. ( Bölüm 7’de daha detaylı olarak anlatılmıştır. )

Yazılım kalite metriklerinin temel amacı

(1) Yönetim kontrolünün yanı sıra uygun yönetimsel müdahalelerin planlanmasını ve yürütülmesini kolaylaştırmak. Bu hedefin başarısı aşağıdakilerle ilgili metriklerin hesaplanmasına dayanır: Planlanan performanstan gerçek fonksiyonel (kalite) performansın sapmaları Planlanan performanstan gerçek zaman çizelgesi ve bütçe performansının sapmaları. (2) Organizasyon genelinde uygulamaya konan önleyici veya düzeltici eylemler biçiminde geliştirme veya bakım süreci iyileştirme gerektiren ya da etkinleştiren durumları tespit etmek. Bu hedefin başarısı aşağıdakilere dayanmaktadır: Takımların, birimlerin vb. performanslarına ilişkin metrik bilgilerinin toplanması.

Karşılaştırma, yönetimin metriklerin uygulanması ve genel olarak SQA iyileştirmesi için pratik bir temel sağlar. Metrikler, performans verilerinin göstergelerle, niceliksel değerlerle karşılaştırılması için kullanılır:

Belirlenen yazılım kalite standartları
Kurumlar veya bireyler için belirlenen kalite hedefleri
Önceki yılın kalite başarıları
Önceki projenin kalite başarıları
Benzer geliştirme ortamlarında aynı geliştirme araçlarını uygulayan diğer ekipler tarafından elde edilen ortalama kalite seviyeleri
Kuruluşun ortalama kalite başarıları
Kalite gereksinimlerini karşılamak için endüstri uygulamaları.

Yazılım kalitesi metrikleri birkaç kategoriye girebilir. Burada iki seviyeli bir sistem kullanılıyor.

1) Birinci sınıflandırma kategorisi, yaşam döngüsü ve yazılım sisteminin diğer aşamaları arasında ayrım yapar:

Yazılım geliştirme süreciyle ilgili süreç metrikleri
Yazılım bakımı ile ilgili ürün ölçüleri

2) İkinci sınıflandırma kategorisi, ölçümlerin konularını ifade eder:

Kalite
Zaman Çizelgesi
Verimlilik (hata giderme ve bakım servislerinin)
Üretkenlik

Ayrıca, bu metriklerin yazılım test türlerine göre olan gruplandırılması yapılmıştır (7.Bölüm).

Aynı şekilde,

10.6. Yazılım Kalite Maliyeti

Yazılım kalite ölçümlerinin maliyetinin uygulanması, yönetimin SQA faaliyetleri ve sonuçları üzerinde ekonomik kontrol elde etmesini sağlar. Yazılım kalite ölçümlerinin maliyetinin hedefleri, ekonomik veriler temelinde yönetim müdahaleleri ile ilgilidir:

Hata önleme ( meydana gelmeden önce ) ve hataların tespiti ile ilgili maliyetleri kontrol etmek.SQA bütçesinin revize edilmesi ve güncellenmesi için yazılım arızaları ve önleme ve değerlendirme maliyetlerinin ekonomik zararlarının kapsamını değerlendirmek.SQA faaliyetlerinde planlı artış veya düşüşlerin ekonomik değerlendirmesini veya geçmiş ekonomik performansa dayalı olarak yeni veya güncellenmiş SQA altyapısına yatırım yapmayı kolaylaştırmak.

Bir kuruluşta yazılım kalite sisteminin maliyetinin uygulanması aşağıdakilerin yapılmasını gerektirir:

Modelin maliyet alt sınıflarından biriyle ilişkili her bir kalite maliyet kalemi ile belirli bir kuruluş için yazılım kalite modelinin maliyetinin belirlenmesi.Her bir maliyet kalemi için maliyet verisi toplama yönteminin belirlenmesi.Takip prosedürleri de dahil olmak üzere, planlanan yazılım kalite sisteminin maliyeti.Maliyet modelinin bulgularına dayanarak eylemler yapmak.

Yazılım kalite ölçümlerinin maliyetinin hedefleri, yönetim müdahaleleri ile ilgili olduğu belirtilmişti. Bu müdahalelerinin biri de hataların önlenmesidir. Bu hata ayıklama değildir, hatalar meydana gelmeden önce, onların tespit edilmesi ve önlenmesidir. Bu konuda başarılı olabilmek için tamamlanmış yazılım geliştirme projesi uygulamaları örnek olarak ele alınmalıdır. Bu tamamlanmış olan projelerde karşılaşılan kusur ve hatalar kaynak olarak kullanılır. Onları düzeltme yöntemleri ve bu düzeltmelerin maliyetleri araştırılır. Ayrıca denetim çıktıları da elde edilir.

Dolayısıyla, kaynak olarak, geliştirilmekte olan projeye benzer bir tamamlanmış projenin seçilmesi daha doğru sonuçlar verir. Hataları önleme yaklaşımına göre Kalite Güvence Etkinliği ile Verimliliğinin başarı kriterlerinin tabloları aşağıda verilmiştir.

	Hesaplama	Çıktı değeri	Sonuç
Kalite güvence *etkinliğinin*başarı ölçütleri		< hedef değer	Başarısız
>= hedef değer	Başarılı
Kalite güvence *verimliliğinin*başarı ölçütleri		< hedef değer	Başarısız
>= hedef değer	Başarılı

Yazılım Kalite Yönetim Standartları bölüm 11

Bölüm Hedefi

Bu bölümde Kalite Yönetiminde önemli olan McCall Faktör Modeli, onun alternatifleri olan Evans ve Marciniak’ın faktör modeli ile Deutsch ve Willis’in faktör modeli anlatılmıştır. Ayrıca, bazı güvenilirlik modelleri ile bakım yapılabilirlik modelleri incelenmiştir ve ISO/IEC 9126 ile ISO/IEC 25010 Standartları anlatılmıştır.

Türk Dili Kurumu tarafından, “ölçmek” kelimesi bu iki şekilde tanımlanmaktadır:

En, boy, hacim, süre gibi nicelikleri kendi cinslerinden seçilmiş bir birimle karşılaştırıp kaç birim geldiklerini belirtmekAşırı olmamasına dikkat etmek, kontrol etmek

Yani, ölçme, bir şeyin ölçülmesi eylemidir. Bir nesnenin diğer nesnelerle ( veya olaylarla ) karşılaştırılabilir olacak şekilde o nesnenin ( veya olayın ) bir özelliğine bir sayının atanmasıdır. Resmi olarak, gerçek dünyadaki varlıkların özniteliklerine sayılar veya sembollerin atanması süreci, açıkça tanımlanmış kurallara göre tanımlanacak şekilde tanımlanabilir.

Ölçme günlük hayatta hepimiz tarafından kullanılır. Bir mağazada veya bakkalda, fiyat, bir öğenin değerinin bir ölçüsü olarak davranır. Benzer şekilde, uzunluk ve boyut ölçümleri, kıyafetin düzgün şekilde uyup uymayacağını gösterir. Böylece, ölçüm bir öğeyi diğeriyle karşılaştırmamıza yardımcı olmaktadır.

Ölçüm, varlıkların nitelikleri hakkında bilgi alır. Bir özellik, bir insanın boyu, bir yolculuğun maliyeti gibi örnekler, bir varlığın bir özelliğidir. Gerçek hayatta, nesneleri ölçtüğümüzü düşünüyor olsak da, aslında bu nesnelerin niteliklerini ölçüyoruz.

Öznitelikler çoğunlukla sayılar veya sembollerle tanımlanır. Örneğin, fiyat Türk lirası veya dolar olarak belirtilebilir, giyim büyüklüğü küçük ( Small ), orta ( Medium ), büyük ( Large ) olarak belirtilebilir.

Bir ölçümün doğruluğu ölçüm aletinin ve yanı sıra ölçümün tanımına da bağlıdır. Ölçümleri aldıktan sonra, bunları analiz etmeliyiz ve varlıklar hakkında sonuç çıkarmak zorundayız.

Ölçüm, doğrudan bir miktardır. Fakat bazı formülleri kullanarak farklı ölçümleri birleştirdiğimiz ve hesapladığımız zaman dolaylı bir ölçüm elde edilir.

Yazılım Mühendisliği, yazılım ürünlerini yönetmeyi, maliyetlendirmeyi, planlamayı, modellemeyi, analiz etmeyi, belirlemeyi, tasarlamayı, uygulamayı, test etmeyi ve sürdürmeyi içerir. Bu nedenle, yazılım mühendisliğinde ölçüm önemli bir rol oynamaktadır. Bir yazılım ürününün niteliklerini ölçmek için titiz bir yaklaşım gerekli olacaktır.

Geliştirme projelerinin çoğunda:

Yazılım ürünlerimiz için ölçülebilir hedefler belirleyemiyoruz;
Yazılım projelerinin maliyet bileşenlerini anlamakta ve ölçmekte zorluk çekiyoruz;
Ürettiğimiz ürünlerin kalitesini ölçmüyor veya öngörmüyoruz.

Böylece, yazılım ürünlerini kontrol etmek için, niteliklerin ölçülmesi gereklidir. Her ölçüm eylemi belirli bir amaç ya da açıkça tanımlanmış ve kolay anlaşılır bir ihtiyaç tarafından motive edilmelidir. Ölçme hedefleri belirli olmalı, yöneticilerin, geliştiricilerin ve kullanıcıların bilmesi gerekenlere dayanmalıdır. Projenin, ürünün, süreçlerin ve kaynakların durumunu değerlendirmek için ölçüm gereklidir.

Yazılım mühendisliğinde, ölçüm aşağıdaki üç temel etkinlik için gereklidir :

Gelişim ve bakım sırasında neler olduğunu anlamak
Projede neler olup bittiğini kontrol etmek
Süreçleri ve hedefleri geliştirmek

Yazılımı etkileyen çeşitli faktörlere yazılım faktörleri denmektedir. Geniş olarak iki kategoriye ayrılabilirler. Faktörlerin ilk kategorisi, mantıksal hataların sayısı gibi doğrudan ölçülebilenler ve ikinci kategori faktörleri yalnızca dolaylı olarak ölçülebilen faktörlerdir. Örneğin, sürdürülebilirlik, ancak her bir faktör, içeriği ve kalite kontrolünü kontrol etmek için ölçülmelidir.

Yıllar boyunca çeşitli yazılım kalite faktörleri modelleri ve bunların sınıflandırılması önerilmiştir. Klasik yazılım kalitesi faktörleri modeli McCall tarafından önerilmiştir. Bu model 11 adet kalite faktörden oluşmaktadır. McCall faktör modeli, yazılım gereksinimlerini sınıflandırmak için pratik ve güncel bir yöntem sunar.

11.1. McCall Faktör Modeli

Bu model tüm yazılım gereksinimlerini 11 yazılım kalite faktörüne göre sınıflandırmaktadır. 11 faktör üç kategoriye ayrılır – ürün çalışma, ürün revizyonu ve ürün geçiş faktörleri.

Ürün çalışma faktörleri – Doğruluk, Güvenilirlik, Verimlilik, Bütünlük, Kullanılabilirlik.
Ürün revizyon faktörleri – Bakım, Esneklik, Test Edilebilirlik.
Ürün geçiş faktörleri – Taşınabilirlik, Yeniden Kullanılabilirlik, Birlikte Çalışabilirlik.

Şekil 1’de McCall Faktör Modelini ağaç yapısı şeklinde inceleyebilirsiniz.

Şekil 1 McCall Faktör Modelinin Ağaç şeklinde gösterimi

Ürün çalışma faktörleri ( Doğruluk, Güvenilirlik, Verimlilik, Bütünlük, Kullanılabilirlik )

McCall’ın modeline göre, ürün çalışma faktörleri kategorisi, yazılımın günlük işleyişini doğrudan etkileyen gereklilikleri ele alan beş yazılım kalitesi faktörünü içerir. Onlar aşağıdaki gibidir.

Doğruluk

Bu gereksinimler, yazılım sisteminin çıktısının doğruluğu ile ilgilenir ve aşağıdakileri içerir:

Çıktı işi ( örn. Satış fatura çıktısı )
Hatalı verilerden olumsuz etkilenebilecek çıktı veya hatalı hesaplamalar için gerekli doğruluk.
Eksik bilgiden etkilenebilecek çıkış bilgilerinin eksiksizliği.
Etkinlik ile yazılım sistemi tarafından verilen yanıt arasındaki zaman olarak tanımlanan bilgilerin güncelliği.
Bilgilerin kullanılabilirliği.
Yazılım sistemini kodlama ve belgeleme standartları.
Güvenilirlik
Güvenilirlik gereksinimleri servis başarısızlığı ile ilgilenir. Yazılım sisteminin izin verilen maksimum hata oranını belirlerler ve tüm sisteme veya ayrı işlevlerinden birine veya daha fazlasına başvurabilirler.
Verimlilik
Yazılım sisteminin farklı işlevlerini yerine getirmek için gereken donanım kaynakları ile ilgilenir. İşleme yeteneklerini ( MHz’de verilmiştir ), depolama kapasitesini ( MB veya GB’de verilmiştir ) ve veri iletişim yeteneğini ( Mbps veya Gbps’de verilmiştir ) içerir.
Ayrıca, taşınabilir bilgisayarlarda bulunan bilgi sistemi birimleri veya dışarıda yerleştirilmiş meteorolojik birimler gibi sistemin taşınabilir ünitelerinin yeniden şarj edilmesi arasındaki süreyi de ele alır.
Bütünlük
Bu faktör, yazılım sistemi güvenliğiyle ilgilenir, yani yetkisiz kişilere erişimi engellemek, ayrıca okuma izni verilmesi yanı sıra okutulacak kişi grubu arasında ayrım yapmaktır.
Kullanılabilirlik
Kullanılabilirlik gereksinimleri, yeni bir çalışanı eğitmek ve yazılım sistemini çalıştırmak için gereken personel kaynakları ile ilgilenir.

11.1.1. Ürün Revizyon Faktörleri (Bakım, Esneklik, Test Edilebilirlik)

McCall’ın modeline göre, ürün revizyon kategorisinde üç yazılım kalite faktörü yer almaktadır. Bu faktörler aşağıdaki gibidir.

Açıklamaları görmek için başlıklara tıklayınız.

Bakım

Bu faktör, kullanıcıların ve bakım personelinin, yazılım arızalarının nedenlerini tanımlamaları, hataları düzeltmeleri ve düzeltmelerin başarısını doğrulamaları için ihtiyaç duyulacak çabaları dikkate almaktadır.

Esneklik

Bu faktör, yazılımın uyarlanabilir bakım faaliyetlerini desteklemek için gereken yetenek ve çabalarla ilgilenir. Bunlar, mevcut yazılımı, yazılımı değiştirmeden ek koşullara ve müşterilere uyarlamayı içerir. Bu faktörün gereksinimleri, hizmetlerini iyileştirmek ve firmanın teknik veya ticari ortamındaki değişikliklere uyarlamak için, yazılımda yapılan değişiklikler ve eklemeler gibi mükemmel bakım faaliyetlerini de destekler.

Test Edilebilirlik

Test edilebilirlik gereksinimleri, yazılım sisteminin test edilmesinin yanı sıra, çalışmasıyla da ilgilenir. Sistemin tüm bileşenlerinin çalışır durumda olup olmadığını tespit etmek ve tespit edilen arızalar hakkında bir rapor elde etmek için önceden tanımlanmış ara sonuçları, kayıt dosyalarını ve ayrıca sistemi başlatmadan önce yazılım sistemi tarafından gerçekleştirilen otomatik tanılamayı içerir. Bu gereksinimlerin başka bir türü, yazılım arızalarının nedenlerini tespit etmek için bakım teknisyenleri tarafından uygulanan otomatik teşhis kontrolleri ile ilgilidir.

11.1.2. Ürün Geçiş Faktörleri (Taşınabilirlik, Yeniden Kullanılabilirlik, Birlikte Çalışabilirlik)

McCall’ın modeline göre, yazılımın diğer ortamlara uyarlanması ve diğer yazılım sistemleriyle etkileşimi ile ilgilenen ürün geçiş kategorisinde üç yazılım kalitesi faktörü yer almaktadır. Bu faktörler aşağıdaki gibidir.

Açıklamaları görmek için başlıklara tıklayınız.

Taşınabilirlik

Taşınabilirlik gereksinimleri, bir yazılım sisteminin farklı donanım, farklı işletim sistemleri ve benzerlerinden oluşan diğer ortamlara adapte olma eğilimindedir. Yazılım, aynı temel yazılımı çeşitli durumlarda kullanmaya devam edebilmelidir.

Yeniden Kullanılabilirlik

Bu faktör, şu anda geliştirilmekte olan yeni bir yazılım projesinde bir proje için orijinal olarak tasarlanmış yazılım modüllerinin kullanımını ele almaktadır. Ayrıca, gelecekteki projelerin belirli bir modülü veya şu anda geliştirilmiş yazılımın bir grup modülünü kullanmasını sağlayabilirler. Yazılımın yeniden kullanılmasının, geliştirme kaynaklarını kurtarması, geliştirme süresini kısaltması ve daha yüksek kaliteli modüllerin sağlanması bekleniyor.

Birlikte Çalışabilirlik

Birlikte çalışabilirlik gereksinimleri, diğer yazılım sistemleriyle veya diğer donanım yazılımı ile arayüz oluşturmaya odaklanır. Örneğin, üretim makinesi ve test ekipmanının ürün yazılımı, üretim kontrol yazılımı ile arayüz oluşturur.

11.2. ISO/IEC 9126 ve ISO/IEC 25010 Standartları

ISO/IEC 9126 standardı 6 adet kalite faktörünü ele alır. Bunlar: işlevsellik, güvenilirlik, bakım, taşınabilirlik, kullanılabilirlik ve verimlilik. Hata düzeltme veya test süresi gibi doğrudan ölçülemeyen metrikler birtakım kabullere dayanmaktadır.

ISO/IEC 25010 standardı ise ISO/IEC 9126 standardının güncellenmiş halidir. ISO/IEC 25010 standardından farklı olarak, doğrudan ölçülebilir metrikleri ele almaz ve ek olarak kalite faktörleri arasında uyumluluk ve güvenliği içerir.

11.3. Evans Ve Marciniak’ın Faktör Modeli

Bu model tüm yazılım gereksinimlerini 12 yazılım kalite faktörüne göre değerlendirir. Bu faktörler ise 3 kategoriye göre sınıflandırılmaktadır. McCall modelinden farklı olarak, doğrulanabilirlik ve genişletilebilirlik kalite faktörlerini içerir.

Açıklamaları görmek için başlıklara tıklayınız.

Doğrulanabilirlik (Deutsch ve Willis tarafından da önerilmiştir)

Doğrulanabilirlik gereksinimleri tasarımın ve programlamanın etkin bir şekilde doğrulanmasını sağlayan tasarım ve programlama özelliklerini tanımlar. Doğrulanabilirlik gereksinimlerinin çoğu, modülerliği, basitliği ve dokümantasyon ve programlama kurallarına uymayı ifade eder.

Genişletilebilirlik (Deutsch ve Willis tarafından da önerilmiştir)

Genişletilebilirlik gereksinimleri, daha geniş nüfusa hizmet etmek, hizmeti geliştirmek veya kullanılabilirliği geliştirmek için yeni uygulamalar eklemek için gerekli olacak gelecekteki çabaları ifade eder. Bu gereksinimlerin çoğu McCall’ın esneklik faktörü tarafından karşılanmaktadır.

11.4. Deutsch ve Willis’in Faktör Modeli

Bu model 4 farklı kategoriye göre sınıflandırılan 15 adet yazılım kalite faktöründen oluşmaktadır. McCall modelinden farklı olarak, doğrulanabilirlik, genişletilebilirlik, güvenlik, yönetilebilirlik ve sürdürülebilirlik kalite faktörlerini içerir.

Doğrulanabilirlik ile genişletilebilirlik kalite faktörleri Evans ve Marciniak’ın faktör modeli altında tanımlanmıştır. Diğer kalite faktörleri ise aşağıda verilmiştir.

Açıklamaları görmek için başlıklara tıklayınız.

Güvenlik (Security)

Güvenlik gereklilikleri, süreç kontrol yazılımındaki hataların bir sonucu olarak, ekipmanın operatörleri için tehlikeli olan koşulları ortadan kaldırmaya yöneliktir. Bu hatalar, tehlikeli durumlara uygunsuz reaksiyonlarla veya yazılım tarafından tespit edilen tehlikeli koşullar ortaya çıktığında alarm sinyallerinin sağlanamamasıyla sonuçlanabilir.

Yönetilebilirlik (Manageability)

Yönetilebilirlik gereksinimleri, yazılım geliştirme ve bakım dönemlerinde, yapılandırma yönetimi, yazılım değişikliği prosedürleri ve benzeri gibi yazılım değişikliklerini destekleyen yönetim araçlarına atıfta bulunur.

Yaşanabilirlik (Survivability)

Sürdürülebilirlik gereksinimleri hizmetin sürekliliğine işaret eder. Bunlar, sistemin arızaları ile hizmetin geri kazanılması için izin verilen azami süre arasındaki süreyi, hizmet sürekliliğine ilişkin iki faktör tanımlar. Bu gereklilikler, hizmetlerin toplam ve kısmi başarısızlıklarına ayrı olarak atıfta bulunsa da, bunlar özellikle temel işlevlerin veya hizmetlerin başarısızlığına yöneliktir. McCall’ın modelinde açıklanan dayanıklılık faktörü ve güvenilirlik faktörü arasında önemli benzerlikler vardır.

11.5. Rome Laboratuvarı (Rome Laboratory / Rome Labs) Modeli

Rome Laboratuvarı Modeli güvenilirlik odaklı bir yazılım kalite modelidir. Bu model yazılım güvenilirliği öngörümü ( prediction ) ve tahminine ( estimation ) yönelik yaklaşımlar sunar. Bir yazılım projesinin sistem gereksinimlerinin toplanması aşamasından bakım sürecine kadar olan tüm adımlarda yazılım hakkında toplanan çeşitli verilere göre yazılımın hata yoğunluğunu öngörür ve sistem arızası oranını tahmin eder.

Hata yoğunluğu ( Error density )
Bir yazılımın satır sayısı başına içerdiği hata sayısıdır.

Sistem arızası oranı ( System failure rate )
Belirli bir zaman sonra sistem arızasının oluşmasına neden olan yazılımsal hatalar.

Bu modelde, yazılım geliştirmedeki ekip yapısı, yazılım geliştirme sürecinin dokümantasyon aşaması ve yazılımın kodları gibi önemli unsur ve aşamalardan gerekli veri ve bilgilerin yardımıyla güvenilirlik değerleri hesaplanır. Aşağıdaki Şekil 2’de Rome Laboratuvarı Modelinin Hata Yoğunluğu öngörüm metrikleri gösterilmiştir.

11.6. Full-Scale Yazılım Güvenilirlik Modeli

Bu model 3 aşamada, kapsam genişletilerek uygulanabilir. Modelde çoğunlukla günümüz yazılımlarından elde edilen çıkarımlar kullanılmaktadır. Dolayısıyla güncel bir modeldir. Güvenilirlik analizlerinin yapılabilmesinin önemli ve buna ihtiyacı olan daha çok emniyet gibi kritik yazılımlar için tercih edilen bir modeldir. Kamu yazılımlarının değerlendirilmesi için ise bu maliyetli olabilir. Bu nedenle, düşük maliyetli ya da ücretsiz açık kaynak kodlu yazılımların incelenmesine ihtiyaç duyulmuştur.

11.7. Bakım Yapılabilirlik Modeli (Software Improvement Group (SIG))

SIG Bakım Yapılabilirlik Modeli yalnızca kodun incelenmesi ile yazılımın bakım yapılabilirliğini derecelendiren bir modeldir. Avrupa’daki bir sertifkasyon kuruluşu bu modeli kullanarak yazılımlara “Bakım Yapılabilirlik” sertifikası vermektedir.

Bu modelde, bir yazılım analiz edilebilirlik, değiştirilebilirlik, test edilebilirlik ve kararlılık gibi faktör ve kriterleri yönünden derecelendirilir. Bu derecelendirme ise, yazılımın projesinin büyüklüğü ve karmaşıklığı, kod tekrarı oranı gibi büyüklüklerin ölçülmesiyle hesaplanır. Bu hesaplar yapılırken yazılım birimlerinin satır sayıları, genel birim satır sayısına oranlanmaktadır. Sonuç ise yazılım bakım yapılabilirliğinin 1 (en düşük) ile 5 (en yüksek) arasında bir not ile ifade edilmektedir.

Yazılım geliştirme süreci boyunca, sürecin çeşitli kalite faktörlerinin gerekliliklerine uygunluğu, tasarım incelemeleri, yazılım incelemeleri, yazılım testleri ve benzerleri ile incelenir. Ayrıca, yazılım ürününün çeşitli kalite faktörlerine ait gereksinimlere uygunluğu, yazılım kalite ölçütleri, uyumluluk derecesini ölçen önlemlerle ölçülür. Uygun uyum ölçümlerine olanak tanımak için, yazılım kullanımının çeşitli özelliklerini ve özellik çeşitlerini temsil eden kalite faktörleri için alt faktörler tanımlanmıştır. Bu alt faktörlerin her biri için yazılım kalite ölçütleri önerilir. Bu ölçütlere göre yapılan değerlendirmeler yazılım verimliliğinin arttırılması için önemlidir.

Bazı alt faktörler birden fazla faktörü etkileyebilmektedir. Bu, bazı özelliklerin, yazılım kullanımının birden fazla yönüne başarılı bir şekilde uyum sağlamasına katkıda bulunduğunu yansıtmaktadır. Örneğin, basitlik (bir alt faktör), sürdürebilirlik, esneklik, yeniden kullanılabilirlik ve genişletilebilirlik faktörlerine katkıda bulunur.

11.8. Toplam Kalite Yönetimi

Kaliteli ürün ile kaliteli hizmetin sunulması yanında sürekli gelişmeyi ve maliyetin düşmesini sağlamak için kullanılan diğer bir yaklaşım – toplam kalite yönetimidir. ISO 9000 Kalite Yönetim Sistemi Serisinin asıl amacı, yapılan işleri çalışmakta olan bireylere bağlı olmayacak şekilde sürdürülmesini sağlamaktır. Böylece, yapılacak olan her hangi bir iş, her zaman hangi birey çalışırsa çalışsın aynı şekilde yapılması sağlanarak, kalite güvencesi kontrol altına alınmış olur.

Bunun için, bir kuruluşun kalite sistemi kurulmalıdır ve bu kalite sisteminde, ISO 9001 Kalite Sisteminin Dokümantasyon Elemanları muhafaza edilmelidir. Bu Kalite Sistemi Dokümantasyon Yapısı aşağıdaki unsurları içermelidir:

Politikalar: Ne isteniyor?Prosedürler: Kim? Ne? Ne zaman? Niçin? Nerede?İş talimatları: Prosedürler nasıl uygulanacak?Ekipman Çalıştırma: El Kitapları: Ekipman nasıl çalıştırılır? Nasıl onarılır?Kalite Sistem Kayıtlar: Yukarıdakilerin hepsinin belgelenmesi ve elde edilen sonuçlar neler?

Yazılım kalitesi, müşteriler, geliştiriciler ve kullanıcılar bakış açısına bağlı olarak farklı şekilde kabul edilir ( Detaylı olarak Bölüm 7’de anlatılmıştır ). Bu yüzden, bir kuruluşun başarılı bir şekilde yönetilebilmesi için, ISO 9000 Standardının prensiplerini hatırlamakta fayda var.

ISO 9000 Standardının Kalite prensipleri:

Müşteri odaklı olması
Yönetim sorumluluğu ( Liderlik )
İnsanların katılımı
Süreç yaklaşımı
Yönetime olan sistematik yaklaşım
Sürekli iyileştirme
Gerçeklere dayanan kararlar verme (facts)
Yararların karşılıklı olduğu tedarikçi ilişkileri

Bir kuruluş, Kalite yönetim sisteminin benimsenmesi konusunda stratejik bir kararı almalıdır. Kuruluşun kalite yönetim sisteminin tasarımı ile uygulanması, kuruluşun çeşitli ihtiyaçlarına, kuruluşun özel hedeflerine, onun sunduğu ürünlere ve o kuruluşun büyüklüğü ile yapısına bağlıdır. Şekil 3’te, kuruluşlarda uygulanabilecek Kalite Yönetim Sisteminin İyileştirilmesi ve Geliştirilmesi sürecinin gösterimi verilmiştir.

Proses, girdiler kümesini, çıktı (lar) kümesine dönüşümünün sağlanması için yönetilen faaliyet olarak değerlendirilebilir. Genellikle, bir prosesin çıktısı, bir sonraki prosesin girdisi oluyor. Bir kuruluş içinde bu proseslerin tanımlanması, onların etkileşimleri ve yönetilmesi ise ” proses yaklaşımı” olarak adlandırılır. Bu proses yaklaşımı, kuruluşun etkin çalışması için gerekli birçok bağlantılı faaliyetleri tanımlayıp onları yönetmelidir. Bu standart yanlış anlaşılmamalıdır. Kalite yönetim sisteminin yapısının tek türden olmasını veya dokümantasyonunu tek türden olmasını hedeflemiyor.

Proses yaklaşımı, hem prosesler sistemi dâhilindeki bireysel prosesler arası bağlantı ve hem de bunların bileşimi ve aralarındaki etkileşimleri üzerinde sürekli bir kontrol sağlamaktadır. Bu da onun büyük avantajıdır ve böyle bir yaklaşımın, bir kuruluşun kalite yönetim sisteminde kullanılması, aşağıdaki madde halinde verilmiş işlevlerin önemini vurgulamaktadır:

Şartların anlaşılması ve yerine geliştirilmesi önemlidir;
Proseslerin değer katma açısından dikkate alma gereksinimi önemlidir;
Proses performansı ve proses etkinliğinin sonuçlarının elde edilmesi önemlidir;
Objektif ölçüme dayanan proseslerin sürekli iyileştirilmesi de önemlidir.

Yapılan bu araştırma ve derlemeler sonucunda, kaliteli bir yazılım geliştirebilmek için dikkat edilmesi ve kontrol edilmesi gerekenlerin listesi örneği oluşturuldu.

11.9. Kaliteli Bir Yazılım İçin Bir Örnek Kontrol Listesi

Verilen görevleri yerine getiriyor mu? ( işlevsellik )Belirli ( belki de beklenmeyen ) koşullarda görevlerini yapıyor mu? ( güvenilirlik )Kolayca anlaşılıyor mu? Kullanımı kolay mı? ( kullanılabilirlik )İstenilen zaman içerisinde istenilen performans sağlanıyor mu? ( verimlilik )Hatalar düzeltilebilir mi? Yeni özellikler eklenebilir mi? ( sürdürülebilirlik )Kurulumu basit mi? Başka bir yazılım/donanım sisteminde çalışır mı? ( taşınabilirlik )

Yukarıda verilen örnek kontrol listesindeki maddelerin hepsi olumlu olarak cevaplandı ise, kaliteli bir yazılım geliştirilmiştir demek. Bu maddelerin olumlu olarak cevaplanabilmesi için izlenmesi gereken yol örneği ise şu şekildedir:

Amaç nedir? Yazılımdan neler bekleniyor? Hangi görevleri yapmalıdır?İzlenecek yol, tasarım, plan hazır mı?Bir yazılım geliştirme süreci seçildi mi?Bu yazılım geliştirme süreci uygulanıyor mu?Yazılım testleri yapıldı mı?Hem kodlar, hem test sonuçları belgelendi mi? Kullanım kılavuzları hazırlandı mı?Kullanıcı gereksinimleri karşılandı mı? Müşteri memnun mu?İstenilen değişiklikler, eklemeler yapıldı mı?

Örneğin bir web uygulamasını düşünelim. Onun kaliteli bir web sitesi olması için aşağıdaki sorular sorulmalıdır ve bu sorular doğrultusunda düzeltmeler ile eklemeler yapılmalıdır.

Kullanıcılar siteyi uygun boyutta ve uygun çözünürlükte görüntüleyebiliyor mu? Örneğin, cep telefonlarından bağlandığı zaman web sitenin görüntüsü bozuluyor mu?
Web sitesi kişiselleştirilebiliyor mu? Bu hem kullanıcı memnuniyeti kazandırır hem de çevrimiçi pazarlamaya büyük katkılar sağlar.
Web sitedeki menüler, butonlar kolay bulunabiliyor mu? Onların etkileşimi kolayca anlaşılıyor mu? Bunlar, kullanıcıya kullanım kolaylığı sağlar.
Aynı şekilde, web sitedeki içerikler de kolay bulunabiliyor mu?
Yazı tipleri, boyutları ve renkleri uyumlu mu? Kullanılan renkler göz yorucu mudur?
Kullanılan resimler anlaşılır mı? Konuyla ilgili midir? İlgi çekici midir? Animasyon resimleri varsa, süreleri çok uzun mudur?
Bir çevrimiçi ödemeler içeren, ya da bir form doldurmayı ya da çeşitli sorgulamaları içeren bir web site ise, kullanıcı tarafından yapılan sorgu ve istekleri kısa sürede cevaplıyor mu? İçerik ile resimler kısa zamanda görüntülenebiliyor mu?

Bu soruların bir web sitesi geliştirme esnasında dikkate alınması gereklidir. Çünkü bu sorular kaliteli ürünün geliştirilmesine yol açar. Ayrıca, bir web sitesi için şu kurallar da göz önünde bulundurulmalıdır. Bir kullanıcı,

site hakkında ilk 5 saniyede bilgi edinir;
ilk 2 saniyede ise girdiği sitede kalma veya gitme kararını verir;
sitenin görsel tasarımın % 20 sinden % 80 oranda etkilenir;
aradığı bilgiyi ortalama 3 tık ile bulamazsa siteden çıkar;
menülerdeki seçenek sayısı ortalama 7 tane olmalıdır, çünkü bir insanın yakın zaman hafızası aynı anda 5 ila 9 olguyu hatırlar.

Aynı şekilde, diğer masaüstü uygulamalarının ve / veya mobil uygulamalarının geliştirilmesinde de bu tarz sorular listesinin hazırlanması ve bu tarz kuralların dikkate alınması önemlidir ve uygulamanın geliştirilmesinde de bu listelere bakılması gereklidir.

IEEE Yazılım Mühendisliği Standartları

12.1. IEEE/EIA Std 12207 – Yazılım Hayat Döngüsü Süreçleri

IEEE/EIA Std 12207, yazılım yaşam döngüsü süreçlerinin tüm yelpazesini içeren bir çerçeve sunar. IEEE ve EIA tarafından belirlenen IEEE/EIA Std 12207’nin amaçları şu şekilde özetlenebilir:

Dünya çapında yazılım endüstrisi tarafından referans verilebilecek yaygın olarak kabul görmüş bir yazılım yaşam döngüsü süreci modeli oluşturmak.

İş ortakları arasında yaygın olarak tanınan süreçler, faaliyetler ve görevlerin uygulanmasıyla anlayışı geliştirmek.

12.2. 12207 Standardının Yazılım Hayat Döngüsü Mimarisi

Standartta belirtilen yazılım yaşam döngüsü mimarisi, aşağıdakilerden oluşan dört seviyeli bir ağaç olarak yapılandırılmıştır:

Süreç sınıfları
Süreçler
Etkinlikler
Görevler.

Üç işlem sınıfı:

1) Birincil yaşam döngüsü süreçleri (“Primary processes”)
2) Yaşam döngüsü süreçlerinin desteklenmesi (“Supporting processes”)
3) Kurumsal yaşam döngüsü süreçleri (“Organizational processes”).

Standart süreç mimarisinin süreç sınıfları ve bunların kurucu süreçleri bir kılçık diyagramında gösterilebilir (bknz. Şekil 1).

IEEE Std 1012-1998 (IEEE, 1998), bir yazılım ürününün gereksinim özelliklerine ( doğrulama ) uygun olup olmadığının ve kullanım amacının yerine getirilip getirilmediğini ( onaylama ) belirleme süreçlerini ele alır. Standart, yazılım yaşam döngüsü boyunca kullanılabilen çeşitli doğrulama ve onaylama (V & V) yöntemlerinin talep ettiği geniş bir uygulama yelpazesini benimser. Alandaki gelişmelere karşılık olarak, mevcut standart 1986 yılında geliştirilen versiyonundan büyük ölçüde genişletilmiştir.

IEEE 1012-1998’in amaçları şunlardır:

Tüm yazılım yaşam döngüsü süreçleri için V & V faaliyetleri ile görevleri için ortak bir çerçeve oluşturmak
Girdi ve çıktıları dâhil olmak üzere V & V gereksinimlerini tanımlamak için
Yazılım bütünlüğü seviyelerini ve her biri için uygun V & V görevlerini tanımlamak
SVVP ( Software V & V Plan – Yazılım Doğrulama ve Onaylama Planı ) belgesinin içeriğini tanımlamak için.

Doğrulama ( Verification )
Doğrulama, Bir faaliyet, süreç veya ürünün karşılık gelen kurallar veya özelliklerle karşılaştırılması. ÖRNEK: Bir özelliğin güvenlik politikası modeli ile veya nesne kodunun kaynak kodu ile karşılaştırılması.

Doğrulama testi ( Verification test )
Doğrulama (test), Sistemin gerçekleştirilmesinin belirli bir aşamasında sistemin belirlenmiş tüm gereksinimleri karşılandığını göstermek için sistem testi.

TSE (Türk Standartları Enstitüsü) Bilişim Terimleri Sözlüğü

Geçerleme testi ( Validation test )
Geçerleme (test), Gerçekleştirilmiş bir sistemin belirlenmiş ihtiyaçları karşılayıp karşılamadığını belirlemek üzere yapılan test.

TSE (Türk Standartları Enstitüsü) Bilişim Terimleri Sözlüğü

IEEE 1012-1998’de ifade edilen kavramlar 10 temel konuya cevap vermektedir:

Açıklamaları görmek için başlıklara tıklayınız.

1. V & V faaliyetlerinin geniş tanımı.

Bu, standardın yazılım yaşam döngüsü boyunca gerçekleştirilen tüm kontrol ve soruşturma faaliyetlerini benimsemesini sağlar: inceleme, test, yöntem değerlendirmesi, tehlike tespit etme ve risk analizi.

2. Yazılım bütünlüğü seviyeleri ve onun V & V gereksinimleri.

Standart, bir yazılım işlevinin, modülünün veya ünitesinin kritikliğine göre aşağıdaki gibi dört bütünlük seviyesini tanımlar:

“Yüksek ( High )” – kritik sistem performansını etkileyen bir işlev.
“Önemli ( Major )” – önemli sistem performansını etkileyen bir işlev.
“Orta ( Moderate )” – sistem performansını etkileyen bir işlev; Bununla birlikte, alternatif bir operasyon yönteminin kullanılabilirliği, sistemin ilgili zorlukların üstesinden gelmesini sağlar.
“Düşük ( Low )” – sistem performansını yalnızca kullanıcıyı rahatsız ederek etkileyecek bir işlev.

3. Önleyici gereksinimler.

IEEE Std 1012-1998, yazılım yaşam döngüsü boyunca başlatılan her etkinlik sırasında gerçekleştirilecek görevleri listelemesi bakımından kuralcı bir standarttır. Bu görevlerin her biri için, standart aşağıdaki bilgileri sağlar:

Performans metodolojisinin ayrıntılı açıklaması
Gerekli girdiler
Gerekli çıktılar
Görevin performansının zorunlu olmadığı bütünlük düzeylerinin tanımı
Seçilen yaşam döngüsü işlemi sırasında gerçekleştirilecek isteğe bağlı V & V görevleri.
4. Yönetsel bağımsızlık ( Managerial independence ).
Bağımsız IV & V ( Independent V & V ) faaliyetlerinin yerine getirilmesinin sorumluluğunun kalkınma projesinin genel yönetiminin sorumluluğundan ayrı olmasını gerektirir. IV & V takımı, hangi V & V yöntemlerinin uygulanacağına bağımsız olarak karar verir; Buna göre, sonuçların değerlendirilmesi için tek sorumluluk taşır. Bu, en azından teoride, ekibin proje yönetimi tarafından uygulanabilecek herhangi bir baskıdan yalıtılmış olduğu anlamına gelir.
5. Teknik bağımsızlık ( Technical independence ).
Kullanılan analitik araçlarla birlikte V & V ekibinin durumunu ifade eder. Teknik bağımsızlık, ekibin mensuplarının, yazılımın geliştirilmesine dâhil edilmemesini talep eder; bu, projenin bağımsız bir anlayışını “yeni bir bakış açısı” olarak formüle etmelerini sağlamayı amaçlayan bir gerekliliktir. Ayrıca V & V ekibinin, geliştirme ekibi tarafından kullanılanlardan ayrı olarak kendi analiz ve test araçlarını geliştirmesini gerektirir.
6. Mali bağımsızlık ( Financial independence ).
V & V bütçesi üzerindeki kontrolün kalkınma departmanına verilmemesini ve proje planında tanımlanan bütçenin bağımsız bir parçası olarak belirlenmesini gerektirir. Gerçek hayattaki yazılım geliştirme projelerinin yüzeysel gözlemi bile, çeşitli bağımsız bileşenler ve ilgili bağımsızlık seviyelerini açıklar. Bu nedenle, karışıklığı önlemek ve sadece o anki duruma göre karar vermeyi en aza indirmek için standart, SVVP’nin bir parçası olarak V&V bağımsızlığının derecesinin önceden belirlenmesini gerektirmektedir.
7. Uluslararası standartlara uygunluk ve uyumluluk.
Uluslararası standartlara ve IEEE standartlarına uygun ve uyumlu olması önemlidir.
8. Yeniden kullanılabilir yazılım V & V’nin özel özellikleri.
IEEE 1012-1998, yeniden kullanılabilir yazılımlar ( yazılım kitaplığından yazılım, COTS yazılımı vb. ) için V & V aktiviteleri gerçekleştirme zorluklarını sunar. Ayrıca bu faaliyetlerin performansını kolaylaştırmak için muhtemel yönleri gösterir.

9. V&V metrikleri uygulaması.

IEEE 1012-1998’e göre iki sınıf metrik gerçekleştirilmelidir:

Yazılım geliştirme süreçleri ve ürünlerinin değerlendirilmesi için metrikler.
Bu metrik sınıfı, geliştirme sürecini ve ürünlerini ölçer.
V & V faaliyetlerinin kalitesi ve kapsamının değerlendirilmesi için metrikler.
Bu metrik sınıfı, V&V faaliyetlerinin etkinliği ve birinci sınıfa ait metrikler gibi özellikleri keşfetmeye kendini adamıştır.

12.4. IEEE Std 1028 Gözden Geçirme Üzerine (On Reviews)

IEEE Std 1028-1997 ( IEEE, 1997 ) kendisini “sistematik bir incelemenin nasıl yapılacağı” konusunu sınırlandırmaktadır. Standartlara göre, sistematik bir gözden geçirme, bir ekip tarafından belgelendirilmiş sonuçlar üreten belgelenmiş bir prosedüre göre yapılan bir gözden geçirme olarak tanımlanmaktadır. Bir incelemenin ne zaman yapılacağı veya en uygun inceleme türünün ne olduğu gibi metodolojik konular, başka standartlar veya proje yönetimi tarafından belirlenecek şekilde ters çevrilir. Kapsanan beş sistematik derleme türü şunlardır:

Yönetim yorumları ( Management reviews )
Teknik incelemeler ( Technical reviews )
Denetlemeler ( Inspections )
Üstünden hızlı geçme ( Walkthroughs )
Denetimler ( Audits ).

IEEE Std 1028-1997’nin amacı, aşağıdakileri içeren sistematik gözden geçirme prosedürlerini tanımlamaktır:

Yazılım ömrü boyunca gerçekleştirilen incelemeler için geçerlidir.
Diğer standartlar tarafından tanımlanan gözden geçirme koşullarına uyumludur.

Lean ve Altı Sigma Yönetim Sistemleri

13.1. Lean Yaklaşımı

Bu konsept, yüksek kaliteli ürünlerin veya hizmetlerin minimum maliyetle “zamanında teslim edilmesi” için gereken minimum kaynak miktarının kullanımına odaklanmıştır. “Lean” kavramının ana hedefi, aşağıdaki yedi tür kaybı azaltarak herhangi bir sürecin hızını arttırmaktır:

1) aşırı işlem, müşterinin veya işin bakış açısından değer katmayan bir ürün veya hizmetin üretiminde bir eylemdir;
2) ulaştırma – tekrarlanan veya gereksiz hareketler;
3) hareket – gereksiz personel hareketi;
4) yeniden yapma – zaten yapılan işi yeniden yapma veya yapılan işi tekrar yapma;
5) stoklar – artan mallar veya devam eden işler;
6) beklemek – basit bir süreç, zaman içinde gecikmeleri;

7) aşırı üretim – gerekli olanı aşan bir şeyin üretilmesi.
“Lean” yaklaşımında, sürecin gereksiz karmaşıklığını ve standartlaşmasını en aza indirgeme olayı, kaynakların korunmasına ve olası kusurların giderilmesine yardımcı olur. Süreç iyileştirme aşağıdaki temel aşamalardan oluşmaktadır:
Açıklamaları görmek için başlıklara tıklayınız.
1. İş açısından ve iç ile dış müşteri açısından değerlerin belirlenmesi.
Bir müşterinin bakış açısından, bir işletmenin yaptığı her şey ya değer yaratıyor ya da yaratmıyor. Değer yaratma, müşteri memnuniyetine doğrudan katkıda bulunan herhangi bir eylemdir. Değersiz bir eylem, zaman veya kaynak tüketen ve değer yaratmayan her şeydir. Çoğu işlem sadece eylemlerin %10’unda değer yaratır, eylemlerin %90’ı ise kaynakların verimsiz kullanımıdır.
2. Değer yaratma akışının analizi.
Her işlem, müşteriye değer eklemeyen çok miktarda iş içerir. “Lean” yöntemi kayıpları tanımlamak ve ortadan kaldırmak içindir. Değer katmayan unsurları iyileştirmektense daha çok, değer katmayan kayıplardan kurtulmaya odaklanma olayı iyileştirme sürecini daha başarılı kılar.
3. Çekme sisteminin organizasyonu.
Çekme, alt pazardaki tüketicinin bunu kendisine bildirmesine kadar, üst tedarikçinin hiçbir şey üretmediği bir üretim sistemidir. Prensibi, iç müşteriye gerekli kaynaklarla yalnızca ihtiyaç duyulduğu anda tedarik etmektir. Çekme sistemi akış hücrelerini bir araya getirir, bu arada iş besleme hızı işlem verimine eşittir.
4. Değer yaratma akışının organizasyonu.
Akış, malzemelerin ve bilginin, bir tüketici için ürün veya hizmet haline dönüşümü sürecindeki hareketidir. Bir ürün veya hizmet olduğunda – bir akış vardır demek. Herhangi bir aktivite bir akışa dönüştürülebilir. Aynı anda, kayıpları tespit etmek ve ortadan kaldırmak, arıza süresini azaltmak, değer yaratmayan adımları en aza indirmek, sürecin tamamlanmasından itibaren sürecin sürekliliğini sağlamak önemlidir.
Çoğunlukla, başlangıç süreci, çalışanların sadece işlevlerini yerine getirmeye odaklanmaları, süreç boyunca işin önemini görmemeleri şeklinde yapılandırılmıştır. Departmanlar ve yönetim bölümleri tarafından organize edilmekte ve gerekli performans göstergeleri ya mevcut değildir ya da süreç sonucunda değil de belirli bir işleve odaklanmaktadır. Bu şekilde düzenlenen sürecin adımları arasındaki girdiler ve çıktılar tutarlı değildir, bu da hatalara ve gereksiz dâhili döngülere yol açar.
Bu durumda sürecin, süreç içindeki adımlar arasındaki ilişkilerin açıkça tanımlanacağı şekilde yeniden yapılandırılması gerekir: girdi ve çıktılar, veri gereksinimleri – operasyonların yürütülmesi ve kararların alınması için gereklidir. Beklemek, gereksiz işlem yapmak, hareket etmek gibi kayıpları en aza indirmeye odaklanmak gerekir. Gereksiz karmaşıklığın ortadan kaldırılması, süreç adımlarının sayısının azaltılması ve standartlaştırılmasıyla sağlanabilir. Toplu işlemeyi genellikle tek bir ürün akışı işlemesiyle değiştirmek daha iyidir.
5. Mükemmelliğe ulaşma.
Sürekli iyileştirme süreci standardizasyon ve sürekli iyileştirme ile sağlanır – kaizen. Yalın üretim, çoğu sürecin yalın olmadığı ve %10’dan daha az bir işlem döngüsü verimliliğine sahip olduğu gerçeğine dayanır. Bu koşullar altında, devam eden çalışma hacmindeki azalma büyük önem taşımaktadır, her bir proses çekme sistemine göre çalışmalıdır ve itme sistemine göre çalışmamalı, bu da teslim süresindeki değişimin ortadan kaldırılmasına izin verecektir.
13.2. Six Sigma Yaklaşımı
Altı Sigma, varyasyonların, yüksek kaliteli hizmetlerin istikrarlı bir şekilde sağlanmasını engellediğini kabul ederek, tüketicinin bakış açılarından, olasılıkların ve kusurların giderilmesinin bilincine odaklanmaktadır. “Altı Sigma” sisteminin odaklandığı ürün kalitesi, herhangi bir işletmenin faaliyetlerinin en önemli özelliklerinden biridir.
Bireysel bir işletme için kalite seviyesinin yükseltilmesi, rekabet avantajı elde etmenizi sağlar ve ulusal ekonomi için bir bütün olarak, ihracat potansiyeli ve devlet otoritesinde bir artışa neden olur. Altı Sigma sisteminin araç takımı, kalite seviyesinin belirlenmesine ve önemli ölçüde iyileştirilmesine olanak tanır. Birçok işletme, ortalama ürünlerin değerini gerekçe göstererek kaliteli ürünler ürettiğine veya mükemmel hizmet sunduğuna inanmaktadır.
Süreç iyileştirme projelerinin amacı, varyasyonların nedenlerini tanımlamak ve gelecekte meydana gelmelerini önlemek. Sürecin değişkenliği nedir ve neden en aza indirilmelidir? Sorusunun cevaplarına bakalım:
1. Varyasyonların mevcut olmalarının genel nedenleri, sürecin rasgele olduğunu yansıtan sabit varyasyon ile ilişkilidir. Örneğin, dünyada iki benzer kar taneleri yoktur.
2. Varyasyonların tanımlanmış nedenleri, sürecin istatistiksel dağılım parametrelerindeki değişikliklere neden olan etkilerdir. Bunlar rastlantısal olmayan varyasyon nedenleridir. Örneğin, makine programlama hatası veya operatör hatası.

Yazılım Kalite Güvencesi ve Standartlar

Analiz Araçları ( Analysis Tools )

Tasarım Araçları ( Design Tools )

Yapılandırma Yönetimi Araçları ( Configuration Management Tools )

Değişiklikleri Denetleme Araçları ( Change Control Tools )

Programlama Araçları ( Programming Tools )

Prototip Araçları ( Prototype Tools )

Web Geliştirme Araçları ( Web Development Tools )

Kalite Güvence Araçları ( Quality Assurance Tools )

Bakım Araçları ( Maintenance Tools )

Bunu beğen:

İlgili

Bir yanıt yazın Yanıtı iptal et

Analiz Araçları ( Analysis Tools )

Tasarım Araçları ( Design Tools )

Yapılandırma Yönetimi Araçları ( Configuration Management Tools )

Değişiklikleri Denetleme Araçları ( Change Control Tools )

Programlama Araçları ( Programming Tools )

Prototip Araçları ( Prototype Tools )

Web Geliştirme Araçları ( Web Development Tools )

Kalite Güvence Araçları ( Quality Assurance Tools )

Bakım Araçları ( Maintenance Tools )

Bunu paylaş:

Bunu beğen:

İlgili

Bir yanıt yazın Yanıtı iptal et