Sıra | DOSYA ADI | Format | Bağlantı |
---|---|---|---|
01. | Doğrulama Ve Geçerleme | pptx | Sunumu İndir |
Transkript
YMT 312-Yazılım Tasarım Ve Mimarisi Doğrulama ve GeçerlemeF ı r a t Ü n i v e r s i t e s i Ya z ı l ı m M ü h e n d i s l i ğ i B ö l ü m ü1
Bu Haftaki KonularDoğrulama Ve Geçerleme…….………..………………….…………...5Sınama Kavramları…………………………………….…….…………...21Doğrulama ve Geçerleme Yaşam Döngüsü………..............27Sınama Yöntemleri………………………………………………………..29Sınama ve Bütünleştirme Stratejileri……………….………….…34Sınama Planlaması…………………………………………………………47Sınama Belirtimleri……………………………………………………..…48Yaşam Döngüsü Boyunca Sınama Etkinlikleri…………..….…502
AmaçlarDoğrulama ve Geçerleme Kavramlarını ÖğrenmekDoğrulama Tekniklerini ÖğrenmekSınama Kavramları Hakkında Bilgi EdinmekDoğrulama ve Geçerleme Yaşam Döngüsünün Önemini KavramakBütünleştirme Sınamasında \koçan\ KullanımıYazılım Yaşam Döngüsü Boyunca Sınama EtkinlikleriniÖğrenmekYMT312 YAZILIM TASARIM VE MİMARİSİ 5
Giriş4 Geliştirilecek bilgi sistemi yazılımının doğrulanması ve geçerlenmesi, üretim süreci boyunca süren etkinliklerden oluşur. Söz konusu etkinlikler: Yazılım belirtimlerinin ve proje yaşam sürecindeki her bir etkinlik sonunda alınan çıktıların, tamam, doğru, açık ve önceki belirtimleri tutarlı olarak betimler durumda olduğunun doğrulanması. Proje süresince her bir etkinlik ürününün teknik yeterliliğinin değerlendirilmesi ve uygun çözüm elde edilene kadar aktivitenin tekrarına sebep olması. Projenin bir aşaması süresince geliştirilen anahtar belirtimlerinöncekibelirtimlerle karşılaştırılması. Yazılım ürünlerinin tüm uygulanabilir gerekleri sağladığının gerçeklenmesi için sınamaların hazırlanıp yürütülmesi.biçiminde özetlenebilir.
Doğrulama ve GeçerlemeDoğrulamaGeçerlemeDoğru ürünü mü üretiyoruz ?Ürünü doğru olarak mı üretiyoruz?Ürünü kullanacak kişilerin isteklerinin karşılanıp karşılanmadığına dairetkinliklerden oluşur.Ürünün içsel niteliğine ilişkin izlemeve denetim etkinliklerinden oluşur.5Doğrulama ve geçerleme işlemleri temel olarak çeşitli düzeylerde sınama, gözden geçirme, denetim ve hata giderme süreçlerinden oluşur.
Bağımsız Doğrulama ve Geçerleme6Tüm D&G işlemleri bir başka şirket tarafından yapılır. Kurum içi başka bir bölüm/grup tarafından da yapılabilir.Avantajları– Konusunun uzmanları tarafından yapılır– Kurum içi siyasetten etkilenmezDezavantajları– Daha pahalıdır– Daha sıkı koordinasyon gerektirir
Doğrulama Teknikleri7Gözden Geçirme◦Yönetim◦Teknik◦Arkadaş◦MasaüstüÜstünden GeçmeDenetlemeİnceleme
Gözden Geçirme - Yönetim8 Amaç: [IEEE1028-97]◦Durum izlemek◦Planların ve takvimin durumlarını belirlemek◦Gereksinimleri ve sistem kaynaklarını onaylamak◦Yönetim şeklinin hedefe uygunluğunu değerlendirmek Yöntem:◦Proje Yöneticisi veya Lideri tarafından yöneticilere sunumKatılımcılar:◦Karar verme yetkisi olan yöneticilerNeler:Raporlar (Denetleme, Durum, Sonuçlar, ...) Planlar (Risk, Proje, Konfigürasyon, …) Beklenen Sonuçlar:Yapılması planlanan değişikliklere ve iyileştirme kararlarına destek ve onay almak Plan, takvim, ve gereksinimlerin yeterliliğini belirlemekProjenin yolunda gidip gitmediğini belirlemek
Gözden Geçirme - Teknik9 Amaç: [IEEE1028-97]◦Ürünün kullanıma uygunluğunu değerlendirmek◦Ürünün onaylanmış gereksinimlere uymayan yanlarını belirlemek Yöntem:◦Teknik Lider tarafından sunumNeler:Ürüne ait: Amaç ve hedefler Proje yönetim planı Problem listesi Katılımcılar:◦Karar verme yetkisi olan yöneticiler,◦Gözden geçirme sorumlusu,◦Kaydedici,◦Teknik Uzmanlar Beklenen Sonuçlar: Ürünün beklentilere ve standartlara uygun olup olmadığını yöneticilere göstermek Değişiklikleri kontrol etmek, Devam edip etmeme kararını almak
Gözden Geçirme - Arkadaş10 Amaç:◦ Ürünün kullanıma uygunluğunu değerlendirmek◦ Ürünün onaylanmış gereksinimlere uymayan yanlarını belirlemek. Yöntem:◦ Ürün konuya hakim bir takım arkadaşına verilir ve bulunan hatalar/düzeltmeler ürün sahibine açıklanır Katılımcılar:◦ Konusunda uzman takım elemanı◦ Ürün sahibiNeler:◦ Gereksinimler, tasarım dokümantasyonu, kaynak kodu◦ Planlar (Proje, Yazılım Geliştirme, Test, ...)Beklenen Sonuçlar:◦ Bulunan hatalar/düzelmeler/tavsiyeler belgenin üzerine yazılır ve yazara açıklanır
Gözden Geçirme – Masa Üstü11 Amaç:◦ Ürünün kullanıma uygunluğunu değerlendirmek◦ Ürünün onaylanmış gereksinimlere uymayan yanlarını belirlemek. Yöntem:◦ Ürün konuya hakim uzmanlara dağıtılır ve bulunan hatalar/düzeltmeler ürünün bir kopyası üzerine kaydedilir Katılımcılar:◦ Uzmanlar◦ Belgenin müşterileri◦ Belgenin sahibiNeler:◦ Gereksinimler, tasarım dokümantasyonu, kaynak kodu◦ Planlar (Proje, Yazılım Geliştirme, Test, ...)Beklenen Sonuçlar:◦ Bulunan hatalar/düzelmeler/tavsiyeler belgenin üzerine yazılır ve yazara açıklanır
Üstünden Geçme12 Amaç: [IEEE1028-97]◦Ara veya son ürünü değerlendirmek,◦Katılımcıları eğitmek Yöntem:◦Konu ile ilgili proje elemanlarına sunum Katılımcılar:◦Yazar (Sunucu)◦Konusunda uzmanlar◦Ürünün müşterileriNeler:Sistem Gereksinim Belirtimleri (SRS) TasarımProje Planı Beklenen Sonuçlar:Bulgu listesiİyileştirme ve alternatif tavsiyeleri
Denetleme13 Amaç: [IEEE1028-97]◦Ürünün ve süreçlerin bağımsız uzmanlar tarafından değerlendirilip regülasyonlara,standartlara, kılavuzlara, planlara ve protokollere uygunluğunun belirlenmesi. Yöntem:◦Bağımsız bir uzman takımı tarafından değerlendirme Katılımcılar:◦Bağımsız uzmanlarNeler:◦Gereksinimler, Sistem Mimarisi, Tasarımlar◦Proje PlanıBeklenen Sonuçlar:◦Bulgu listesi◦İyileştirme ve alternatif tavsiyeleri
İnceleme14 Amaç: [IEEE1028-97]◦Üründeki hata ve anormallikleri belirlemek. Yöntem:◦İnceleme toplantısı düzenlenir◦Katılımcılar toplantıdan önce ürünü detaylı olarak değerlendirir◦Toplantı sırasında ürün satır satır okunarak bulgular tartışılır Katılımcılar : (Yöneticiler katılmaz)◦İnceleme sorumlusu (Uzlaştırıcı)◦Yazar,◦Okuyucu,◦Kayıtçı,◦İnceleyiciler◦ Tekrar İncelenmesi gerekirNeler:Gereksinimler, tasarım ve kaynak kod Beklenen Sonuçlar: Hata listesi Kabul Durumu:Olduğu gibi veya önemi düşük düzeltmelerle kabulÖnemli değişikliklerle kabul
İncelemenin Önemi15İnceleme maliyeti artırır. Faydası nedir?Sonraki aşamalarda, özellikle Test ve Müşteri tarafından bulunanhataların onarılması maliyeti daha fazla etkilerBu hataları giderirken, başka hataların sisteme girme olasılığı artarTest ve Müşteri tarafından hataların düzeltilmesi proje süresini artırırMüşterinin ürün ve firma hakkındaki fikirleri zedelenirProje elemanlarının işlerinden tatmini azalır
İnceleme Yapmayan Bir Proje16Proje büyüklüğü aşağıdaki rakamlarla verilmiştir:◦Gereksinimler : 300 sayfa◦Tasarım : 150 sayfa◦Kaynak Kodu : 10 000 satırVarsayımlar:◦Gereksinim, Tasarım ve Kodlama aşamaları 100’er hata yapıyor◦Tüm hatalar Test ve Müşteri tarafından bulunuyor◦Testin Hata Bulma Etkinliği (HBE) %75 ve geriye kalan hataların hepsi müşteritarafından bulunuyor◦Test tarafından bulunan hataların onarılması Gereksinim, Tasarım ve Kodlamahataları için sırasıyla 3, 2.5, ve 2 gündür◦Müşteri tarafından bulunan hataların onarılması Gereksinim, Tasarım ve Kodlama hataları için sırasıyla 4, 3.5, ve 3 gündür
İnceleme Yapmayan Bir Proje (Devam)17
Aynı Proje – Gereksinimler İncelenirse18İnceleme için varsayımlar:◦Gereksinim İncelemesi hızı 15 sayfa/saat◦İnceleme Takımı 5 kişi◦İncelemenin HBE %75◦İncelemede bulunan hataların onarılma süresi ½ adam-gün◦İş Günü 8 saatİncelemenin maliyeti(300/15)x5 = 100 saat = 12.5 günİncelemede bulunan hataları onarma süresi75x0.5 = 37.5 günToplam12.5+37.5 = 50 gün
Aynı Proje – Gereksinimler İncelenirse (Devam)Test ve Müşteri Tarafından Bulunan Hataların Onarılma Maliyeti19
İncelemenin faydaları20Hataların Onarılması:◦İncelemesiz : 825 dam-gün◦İnceleme ile : 631 adam-gün◦Kazanılan zaman : 194 adam-gün39 adam-hafta9 adam-ayMaliyet azaldıTakvim kısaldıKalite arttıMüşteri memnun (Neden?)Proje elemanları memnun (Neden?)Yöneticiler memnun (Neden?)
Sınama Kavramları21 Sınama ve bütünleştirme işlemlerinin bir strateji içinde gerçekleştirilmesi, planlanması ve tekniklerin seçimi gerekmektedir. Bütünleştirme işleminde, en küçük birimlerden başlanarak sistem düzeyine çıkılmaktadır. Bu değişik düzeylere hitap edecek sınama yöntemleri olmalıdır. Sınamalar, hatalardan kurtulmanın bir güvencesi değildir. Hatalardan bütünüyle arınıldığı gibi bir kanı edinilmemelidir. Yalnızca, sınamalar uzadıkça hata bulma sıklığı azalır, daha zor bulunacak hatalar gizli kalmağa devam eder. Ne kadar hata sıklığına erişildiğinde sınama işleminin durdurulacağı, maliyet vekalite arasında bir en iyileştirme yapma gereğini öne çıkarır. Aynı zamanda vakit de önemli bir unsurdur. Daha uzunca süreler vakitler harcanarak daha az hatalar bulunmaya devam eder. Yazılımın kritiklik düzeyine göre, sınamaya ayrılan süre ve çaba artar.
Sınama KavramlarıBirim SınamaAlt Sistem SınamaSistem Sınama22Kabul Sınama
Birim Sınama23 Bağlı oldukları diğer sistem unsurlarından bütünüyle soyutlanmış olarakbirimlerin doğru çalışmalarının belirlenmesi amacıyla yapılır. Birimler, ilişkili yapıtaşlarının bütünleştirilmesinden oluşurlar.
Alt Sistem Sınama24 Alt sistemler, modüllerin bütünleşmesi ile ortaya çıkar. Yine bağımsızolarak sınamaları yapılmalıdır. Bu düzeyde en çok hata arayüzlerde bulunmaktadır, arayüz hatalarınayönelik sınamalara yoğunlaşılmalıdır.
Sistem Sınama25 Üst düzey bileşenlerin sistem ile olan etkileşimlerinde çıkacak hatalararanmaktadır. Ayrıca belirtilen ihtiyaçların doğru yorumlandıkları da sınanmalıdır.
Kabul Sınama26 Çalıştırılmadan önce sistemin son sınamasıdır. Artık yapay veri yerine gerçek veriler kullanılır. Bu sınama türü alfa sınaması ve beta sınaması olarak ta bilinir. Alfa sınamada, tanımında, sınamanın geliştirici organizasyonunyerleşkesinde, kullanıcıların da gelerek katkıda bulunması içerilir. Daha sonra ürünün pazarlama işlemi sırasında beta sınama denilen,sınama kullanıcının kendi yerleşkesinde geliştirici gözetiminde yapılır.
Doğrulama ve Geçerleme Yaşam Döngüsü27 Doğrulama ve geçerleme işlemleri yazılım üretim yaşam döngüsünün tümsüreçlerinde ve bu süreçlere koşut olarak sürer. Gerçekleştirim aşamasına kadar olan süreçlerde doğrulama ve geçerlemeişlemlerinin planlaması yapılır. Planlama, genel olarak, birim, alt sistem, bütünleştirme, sistem ve kabul sınamalarının tasarımlarını içerir. Gerçekleştirim aşamasının sonunda ise söz konusu planlar uygulanır. Uygulama sonucu elde edilen bulgular, Yazılım Doğrulama ve Geçerleme raporları biçiminde sürekli olarak raporlanır. Bu bilgiler, değişiklik denetim sistemi ve sorun yönetim sistemlerinde girdi olarak kullanılır. Değişiklik Denetim sistemi, sınama süresince elde edilen bulguların izlenmesi amacıyla oluşturulan bir sistemdir. Bu sistemde, sınama sonucu elde edilen bulgular ve bunlara karşı sorun yönetimi tarafından alınan önlemler izlenir.
Doğrulama ve Geçerleme Yaşam Döngüsü28
Beyaz Kutu Sınaması29Beyaz kutu sınaması tasarlanırken, birimin süreç belirtiminden yararlanılır.Sınamaları yürütürken sınırlı çabamızı yerinde kullanmamız gerekir.Yapılabilecek denetimler arasında:•Bütün bağımsız yolların en azından bir kere sınanması,•Bütün mantıksal karar noktalarında iki değişik karar için sınamaların yapılması,•Bütün döngülerin sınır değerlerinde sınanması,•İç veri yapılarının denenmesi bulunur.Bunun için hataların bazı özelliklerinin bilinmesinde yarar vardır:•Bir program kesiminin uygulamada çalıştırılma olasılığı az ise o kesimde hata olması ve bu hatanın önemli olması olasılığı fazladır.•Çoğu zaman, kullanılma olasılığı çok az olarak kestirilen program yolları, aslında çok sıkça çalıştırılıyor olacaktır.•Yazım hataları rasgele olarak dağılır. Bunlardan bazılarını derleyiciler bulur, bazıları da bulunmadan kalır.
Temel Yollar Sınaması30Daha önce çevrimsellik karmaşıklığı konusunda gördüğümüz hesap yöntemi ile bir programdaki bağımsız yollar bulunduktan sonra, bu kadar sayıda sınama yaparak programın her birimini bir şekilde sınamalara dahil etmiş oluruz.Bağımsız yolların saptanması için önce, program çizgesel bir biçimeçevrilir.Bunu yapmak için ise, program iş akış şemaları diyagramları iyi birbaşlangıç noktasıdır.
Temel Yollar SınamasıBir Programın İş Akış Şeması31
Temel Yollar Sınaması32Program akış diyagramları matematiksel titizlik ile tanımlanmayan daha serbestçe program yapılarını alt düzeyde modelleyen çizimlerdir. Akış diyagramları ise Çizge Teorisi dalında kabul görecek şekilde bir \Çizge\dir.Her çizgede olduğu gibi burada da düğümler ve dallar (veya kirişler) bulunur.Program akış diyagramından akış diyagramına geçmek için süreç kutuları ortadan kaldırılır, koşul baklavaları yerine düğümler çizilir ve her koşul düğümüne karşı düşecek birleştirme düğümleri eklenir.Birleştirme düğümleri, koşul kollarının kapandığı noktaya konur.Artık bu çizge üzerinden temel yol sayısını da verecek olan çevrimsellik karmaşıklığı sayısını hesaplayabiliriz:Bağımsız temel yol sayısı kadar temel yolları çizge üzerinde (sonunda programa yansıtılmak üzere) veya program üzerinde işaretlenir. Sonra bu yolların hepsinin koşturulacağı sınama programları tasarlanır.E - N + 2E: toplam dal sayısıN: toplam düğüm sayısı
Temel Yollar SınamasıProgramın Grafik Diyagramı33Formüle göre bağımsız yol sayısı: 11 - 9 + 2 = 4Bunun anlamı da şöyle açıklanabilir: Çizgedeki her dal sınama işleminde kapsanmalıdır. Bu, sınama sırasında her işlemin çalıştırılması demektir. Her dalın en az bir kere kapsanacağı ve en az sayıda yollar bulunmalıdır. Programaortadan giremeyeceğimize göre de bu yollar başlangıç noktasından bitiş noktasına kadar uzanmalıdır. Son olarak da minimum sayıda yol ile bu şartları sağlamalıyız. Bu sayının 4 olduğu, daha önce yukarıdaki formülde hesaplanmıştı.
Sınama ve Bütünleştirme Stratejileri34Genellikle sınama stratejisi, bütünleştirme stratejisi ile birliktedeğerlendirilir. Ancak bazı sınama stratejileri bütünleştirme dışındaki tasalarıhedefleyebilir.Örneğin, yukarıdan aşağı ve aşağıdan yukarı stratejileri bütünleştirmeyöntemine bağımlıdır.Ancak işlem yolu ve gerilim sınamaları, sistemin olaylar karşısında değişik işlem sıralandırmaları sonucunda ulaşacağı sonuçların doğruluğunu ve normal şartların üstünde zorlandığında dayanıklılık sınırını ortaya çıkarır.
Yukarıdan Aşağı Sınama ve Bütünleştirme35Yukarıdan aşağı bütünleştirmede, önc sistemin en üst düzeylerinin sınanması ve sonra aşağıya doğru olan düzeyleri, ilgili modüllerin takılarak sınanmaları söz konusudur.En üst noktadaki bileşen, bir birim/modül/alt sistem olarak sınandıktan sonraalt düzeye geçilmelidir.Ancak bu en üstteki bileşenin tam olarak sınanması için alttaki bileşenlerle olan bağlantılarının da çalışması gerekir.Alt bileşenler ise bu stratejiye göre henüz hazırlanmış olamazlar.Bunların yerine üst bileşenin sınaması için kullanılmak üzere 'koçan' programları yazılır.Koçanlar, bir alt bileşenin, üst bileşen ile ara yüzünü temin eden, fakat işlevsel olarak hiç bir şey yapmayan, boş çerçeve programlarıdır.Üst bileşenin sınanması bittikten sonra bu koçanlar, içleri doldurularak kendi kodlama ve birim sınama işlemlerini tamamladıktan sonra üst bileşen ileyeniden sınanırlar.
Bütünleştirme Sınamasında \koçan\ KullanımıA, B, C birimlerinden oluşan ve birim şeması (a) şıkkında belirtilen bir sistemin bu tür koçan kullanılaraksınanması (b) şıkkı ve şekil (c) şıkkında belirtilmektedir.İlk adımda A ve B birimleri bütünleştirilir; C için bir \koçan\ yazılır. İkinci adımda ise \koçan\ kaldırılır ve C ileyer değiştirilerek A-B-C bütünleştirilir.Yukarıdan aşağıya doğru bütünleştirme işleminde iki yaklaşım izlenebilir:1. Yaklaşım: Düzey Öncelikli Bütünleştirme (En üst düzeyden başlanır, öncelikle aynı düzeylerdeki birimlerbütünleştirilir. )2. Yaklaşım: Derinlik Öncelikli Bütünleştirme (En üst düzeyden başlanır. Birim şemasında bulunan her dal soldan sağa olma üzere ele alınır. Bir dala ilişkin bütünleştirme bitirildiğinde diğer dalın bütünleştirmesi başlar.)36
1. Yaklaşım: Düzey Öncelikli Bütünleştirme37
1. Yaklaşım: Düzey Öncelikli Bütünleştirme38
1. Yaklaşım: Düzey Öncelikli Bütünleştirme39
1. Yaklaşım: Düzey Öncelikli Bütünleştirme40
2. Yaklaşım: Derinlik Öncelikli Bütünleştirme41
2. Yaklaşım: Derinlik Öncelikli Bütünleştirme42
2. Yaklaşım: Derinlik Öncelikli Bütünleştirme43
2. Yaklaşım: Derinlik Öncelikli Bütünleştirme44
Aşağıdan Yukarıya Sınama ve Bütünleştirme45Aşağıdan yukarı bütünleştirmede ise, önceki yöntemin tersine uygulama yapılır.Önce en alt düzeydeki işçi birimleri sınanır ve bir üstteki birimle sınama edilmesigerektiğinde bu üst bileşen, bir 'sürücü' ile temsil edilir.Yine amaç, çalışmasa bile arayüz oluşturacak ve alt bileşenin sınanmasını sağlayacakbir birim edinmektir.Bu kez kodlama, bütünleştirme ve sınama aşağı düzeylerden yukarı düzeylere doğru gelişir ve yukarı düzeylerde önce sürücü olarak yazılan birimler sonra gerçekleriyle yer değiştirerek o düzeyin birimleri/alt sistemleri olurlar.Bütünleştirme yukarı doğru yapıldıkça daha az sürücü gereği duyulur.Uygulamada, hem aşağıdan yukarıya, hem de yukarıdan aşağıya sınama stratejilerinin iki stratejinin birleştirildiği de olur. 'Sandviç' adı verilen bu karma yaklaşımda hem üstten hem alttan sınama etkinliği sürer.
Aşağıdan Yukarıya Sınama ve BütünleştirmeŞekilde;1. Belirli bir yazılım alt işlevini gören alt düzey birimler kümeler biçiminde oluşturulurlar,2.Denetim amaçlı bir sürücü programı sınama işlemi için girdi ve çıktı oluşturmak amacıyla yazılır,3. Sürücüler aşağıdan yukarı kaldırılır ve gerçek birim ya da birim kümeleriyle değiştirilereksınama işlemi sürdürülür.46
Sınama Planlaması47Sınama işlemi çok kapsamlıdır.Bir plan güdümünde gerçekleştirilmelidir.Böyle bir planın temel bileşenleri önceki sayfalarda belirtilmiştir.Yazılım yaşam döngüsünün süreçlerine koşut olarak, farklı ayrıntı düzeylerinde birden fazla sınama planı hazırlanır. Sınama planları;◦Birim (Modül) Sınama Planı,◦Alt Sistem Sınama Planları,◦Bütünleştirme Sınama Planları,◦Kabul Sınama Planları,◦Sistem Sınama Planları biçimindedir.Her sınama planı, sınama etkinliklerinin sınırlarını, yaklaşımını, kaynaklarını ve zamanlamasını tanımlar. Plan neyin sınanacağını, neyin sınanmayacağını, sorumlu kişileri ve riskleri göstermektedir. Sınama planları, sınama belirtimlerini içerir.
Sınama Belirtimleri48Sınama belirtimleri, bir sınama işleminin nasıl yapılacağına ilişkin ayrıntıları içerir. Buayrıtılar temel olarak:◦ sınanan program modülü ya da modüllerinin adları,◦ sınama türü, stratejisi (beyaz kutu, temel yollar vb.),◦ sınama verileri,◦ sınama senaryolarıtüründeki bilgileri içerir.Sınama verilerinin elle hazırlanması çoğu zaman kolay olmayabilir ve zaman alıcı olabilir. Bu durumda, otomatik sınama verisi üreten programlardan yararlanılabilir.Sınama senaryoları, yeni sınama senaryosu üretebilmeye yardımcı olacak biçimde hazırlanmalıdır.Zira sınama belirtimlerinin hazırlanmasındaki temel maç, etkin sınama yapılması için bir rehber oluşturmasıdır. Sınama işlemi sonrasında bu belirtimlere,◦ sınamayı yapan,◦ sınama tarihi,◦ bulunan hatalar ve açıklamalarıtüründeki bilgiler eklenerek sınama raporları oluşturulur.
Sınama Belirtimleri49Sınama raporları, sınama bitiminde imzalanır ve yüklenici ile iş sahibiarasında resmi belge niteliği oluşturur.Sınama planları; Birim (Modül) Sınama Planı, Alt Sistem SınamaPlanları, Bütünleştirme Sınama Planları, Kabul Sınama Planları, Sistem Sınama Planları biçimindedir.Her sınama planı, sınama etkinliklerinin sınırlarını, yaklaşımını, kaynaklarını ve zamanlamasını tanımlar.Plan neyin sınanacağını, neyin sınanmayacağını, sorumlu kişileri ve riskleri göstermektedir. Sınama planları, sınama belirtimlerini içerir.
Yazılım Yaşam Döngüsü Boyunca Sınama EtkinlikleriPlanlamaÇözümlemeTasarımGerçekleştirimKurulumSistem SınamaPlanıAlt SistemSınama Planları• Modül Sınama Planı• Sınama Belirtimleri• Sınama Eğitim Kılavuzları• Modül Sınama• BütünleştirmeSınama• Sınayıcı Eğitimi• Kullanıcı Sınama• Sınama RaporlarıPlanlama Aşamasında genel sınama planı oluşturulur. Söz konusu plan tüm sınama etkinliklerini çok genel hatlarıyla tanımlar ve sınama planlamasında verilen bilgileri içerir.Çözümleme aşamasında, sistemler ve alt sistemler ortayaçıkarılır ve sınama planı alt sistemler bazında ayrıntılandırılır.Tasarım aşaması, tüm yazılım modüllerinin ortaya çıkarıldığı aşamadır. Bu aşamanın başlangıcında yazılım modülleri için sınama planı detaylandırılır ve sınama belirtimleri hazırlanır. Söz konusu belirtimler, kullanıcı kılavuzları ile birlikte sınamaya ilişkin eğitim için temel bilgileri oluşturur.Gerçekleştirim aşamasında teknik sınamalar yapılır, sınamaraporları hazırlanır ve kullanıcı eğitilir.Kurulum aşamasından hemen sonra kullanıcısınamaları yapılarak sınama raporu hazırlanır.50
Yazılım Yaşam Döngüsü Boyunca Sınama Etkinlikleri51Hazırlanan sınama raporları, doğrulama ve geçerleme yaşam döngüsü işlemleri gereği \sorun yönetimi \’ne iletilir. Bu bölümde hatalar kaydedilir ve bulunan hatalara karşı yapılacak işlemler planlanır.Sınamalar sırasında bulunan her bulgu ya da hata olarak belirtilen her durumgerçekte hata olmayabilir.Farklı sınayıcılardan biri, bir durumu hata olarak nitelerken diğeri aynı durumu doğru olarak değerlendirebilir.Bu nedenle sınama raporlarında hata olarak bildirilen her durum hemendüzeltilmek üzere ele alınmaz.Önce çözümlenir, kullanıcı çelişkileri giderilir ve gerçekten hata olduğuna karar verilirse düzeltilir. Söz konusu karar kullanıcı temsilcileri ile birlikte alınır.Sınama sırasında bulunan her hata için, değişiklik kontrol sistemine (DKS), \Yazılım Değişiklik İsteği\ türünde bir kayıt girilir.
Yazılım Yaşam Döngüsü Boyunca Sınama Etkinlikleri52 Hatalar, DKS kayıtlarında aşağıdaki gibi gruplara ayrılabilir: Onulmaz Hatalar: BT projesinin gidişini bir ya da birden fazla aşama gerileten ya dadüzeltilmesi mümkün olmayan hatalardır. Büyük Hatalar: Projenin kritik yolunu etkileyen ve önemli düzeltme gerektiren hatalardır. Küçük Hatalar: Projeyi engellemeyen, ve giderilmesi az çaba gerektiren hatalardır. Şekilsel Hatalar: Heceleme hatası gibi önemsiz hatalardır.
Uygulama : Görsel Yazılım Geliştirme Ortamında Sınama53 Bu kısımda, gerçek yaşam ortamında, Oracle Designer CASE aracı ve Developer görsel yazılım geliştirme platformu kullanılarak geliştirilen yazılım modüllerinin sınanması işleminin nasıl yapılacağı ve buraya kadar açıklanan sınamayöntemlerinin nasıl uygulandıkları bir örnek üzerinde anlatılmaktadır. Oracle Developer kullanılarak geliştirilen her yazılım formlardan oluşur. Bir form, bir ekran ve bu ekranda yapılan işlemlere karşılık gelen PL/SQL kodları biçiminde tanımlanır. Bu örnekte elimizde, sınama işlemine koşulacak ve uygulamanın çeşitli işlevlerine ilişkin bir dizi form olduğunu düşünebiliriz. Bu örnekte söz edilen uygulama, 2000'den fazla kullanıcısı olan, ülkenin çeşitli yörelerine dağılmış birimlerde çalışacak biçimde tasarlanmış ve 1000'den fazla Developer formundan oluşmaktadır. Uygulamanın sınama aşamasına gelmesi, 2 yıllık bir süre ve yaklaşık 100 kişi-yıl'lık bir iş gücü gerektirmiştir. Uygulama beş ana kümeye bölünmüş ve her küme belirli sayıda bilgi sistemini içermektedir. Toplam olarak 30 bilgi sistemi bulunmaktadır. Uygulama sıra düzeni bir sonraki slaytta gösterilmektedir.
Uygulama : Görsel Yazılım Geliştirme Ortamında Sınama Şimdi böyle kapsamlı bir uygulamanın sınama aşamasında kullanılan yöntemlerive metodolojiyi bir sonraki slaytta inceleyelim.54
Sınama Ortamı Oluşturulması55Üretimin etkilenmemesi amacıyla, yalnızca sınayıcıların kullanacakları ve ayrı bilgisayarlardan oluşan bir sınama ortamı oluşturuldu.Oluşturulan sınama ortamı ile üretim ortamının bir bir aynıolması sağlandı.Üretimi biten yazılım parçaları, bir kayıt düzeni içerisindesınama ortamına alındı.
Sınama Yöntemlerine Karar Verilmesi56 Uygulamada kullanılacak sınama yöntemleri aşağıdaki gibidir: Teknik Sınama Biçimsel Sınama İşletimsel Sınama Senaryo Sınama Kullanıcı Sınama
Teknik Sınama57 Üretim ortamında yapılacak sınama olarak karar verildi. Bu sınama, modül sınaması ve bütünleştirme sınaması olarak üretim ekipleritarafından gerçekleştirildi. Modül sınama yöntemi olarak ‘Beyaz kutu’ sınama yöntemi uygulandı. Tüm program deyimleri en az bir kez, tüm döngüler en az 10 kez yinelenecek biçimde sınama yapıldı. Bütünleştirme sınama yöntemi olarak ‘yukarıdan aşağıya sınamayöntemi’ ve ‘derinlik öncelikli bütünleştirme’ stratejisi uygulandı.
Biçimsel Sınama58 Üretim ekiplerinden bağımsız olarak, sınama ekipleri tarafından yapılan sınamadır. Bu sınama, Developer formları üzerinde görsel olarak yapıldı. Amaç, formların, önceden kararlaştırılan standartlara uygunluğunun saptanmasıydı. Örneğin, form alanları, kararlaştırılan uzunlukta mı? Başlıklar istenilen gibi koyu mu? Yardım düğmesi hep aynı yerde mi vb. Sınama, formlar işletilmeden yapılır. Tüm formlar tek tek incelenir ve standartlarauygun olmayanlar belirlenip, düzeltilmek üzere üretim ekibine geri iletilir. Biçimsel sınamaların yapılması amacıyla denetim listeleri hazırlanır ve sınama sırasında bu listeler kullanılır. Listelere kaydedilen her sonuç DKS’ye aktarılır. Bu yolla üretim ekiplerinin performansı izlenebilir.
İşletimsel Sınama59 Üretim ekiplerinden bağımsız olarak, sınama ekipleri tarafından yapılan sınamadır. Biçimsel sınama işlemi bittikten sonra yapılır. Bu sınamada her form ayrı ayrı çalıştırılarak işlem yapılır. Amaç, formun çalışıp çalışmadığının belirlenmesidir. Form alanlarının sınır değerlerle çalışıp çalışmadığı, aykırı değerverildiğinde uygun hata iletisi alınıp alınmadığı vb. belirlenmeye çalışılır.
Senaryo Sınama60 Sınama ekipleri tarafından yapılan sınamadır. Ancak, senaryoların hazırlanması sırasında üretim ekipleri ile birlikteçalışılır. Amaç, birden fazla formun bir arada sınanmasıdır. Bu amaçla,‘senaryo’lar hazırlanır. Her senaryo, çözümleme aşamasında belirlenen bir iş fonksiyonunakarşılık gelecek biçimde hazırlanır.
Kullanıcı Sınaması61 Kullanıcılar tarafından yapılması öngörülen sınamadır. Senaryo sınamasının kullanıcı tarafından yapılan biçimi olarakdüşünülebilir.
Kullanıcı Sınama Eğitimi62 Sınama yapılacak kullanıcı sınayıcılarına, sınamaların nasıl yapılacağına ilişkin eğitim verilmesi gerekmektedir. Eğitim kitapçıklarının hazırlanması amacıyla, senaryo sınamalarındakullanılan \senaryo\lar ve kullanıcı kitapçıkları kullanılır.
Sınamaların Yapılması63 Sınamalar sırasında yapılan her işlem, DKS'de izlenir. Özellikle kullanıcı sınamalarının izlenmesi ve ortaya çıkabilecek tartışmaların önlenmesi bu yolla sağlandı. Yaklaşık 100 kullanıcı sınayıcısının, birbirinden farklı yerlerde yaptıklarısınamalar için \haftalık sınama sonuçları\ formları toplandı. Yerinde destek elemanları, sürekli olarak kullanıcı sınayıcılarını ziyaretederek sınama sonuçlarının düzenli olarak toplanmasını sağladı. Bu formlar DKS'ye aktarılarak, daha sonra Yazılım Doğrulama ve Geçerleme Raporları için önemli girdiler oluşturdu.
Özet64Doğrulama: Doğru ürünü mü üretiyoruz ?◦Ürünü kullanacak kişilerin isteklerinin karşılanıp karşılanmadığına dair etkinliklerden oluşur.Geçerleme: Ürünü doğru olarak mı üretiyoruz?◦Ürünün içsel niteliğine ilişkin izleme ve denetim etkinliklerinden oluşur.Doğrulama ve geçerleme işlemleri temel olarak çeşitli düzeylerde sınama, gözden geçirme, denetim ve hata giderme süreçlerinden oluşur.Doğrulama Teknikleri: Gözden Geçirme, Üstünden Geçme, Denetleme veİncelemedir.Sınama planları;◦Birim (Modül) Sınama Planı,◦Alt Sistem Sınama Planları,◦Bütünleştirme Sınama Planları,◦Kabul Sınama Planları,◦Sistem Sınama Planları biçimindedir.
Özet65Hatalar, DKS kayıtlarında aşağıdaki gibi gruplara ayrılabilir:◦ Onulmaz Hatalar: BT projesinin gidişini bir ya da birden fazla aşama gerileten ya da düzeltilmesi mümkün olmayan hatalardır.◦ Büyük Hatalar: Projenin kritik yolunu etkileyen ve önemli düzeltme gerektiren hatalardır.◦ Küçük Hatalar: Projeyi engellemeyen, ve giderilmesi az çaba gerektiren hatalardır.◦ Şekilsel Hatalar: Heceleme hatası gibi önemsiz hatalardır.Uygulamada kullanılacak sınama yöntemleri aşağıdaki gibidir:◦ Teknik Sınama◦ Biçimsel Sınama◦ İşletimsel Sınama◦ Senaryo Sınama◦ Kullanıcı Sınama
Sorular661. Doğrulama ile Geçerleme arasındaki farklılıkları belirtiniz. Birer örnekle açıklayınız.2. Sınama Yöntemlerini açıklayınız.3. \Beyaz Kutu\ sınama ile \Temel Yollar Sınama\ yöntemleri arasındaki farlılıklarıbelirtiniz.4. Sınama Yöntemleri ile sınama belirtimleri arasındaki farkı belirtiniz.5. Yukarıdan aşağıya doğru bütünleştirme ve aşağıdan yukarıya bütünleştirmeyöntemlerinin zorluklarını ve kolaylıklarını belirtiniz.6. Sınama belirtimlerinin önemi nedir.7. Kullanıcı sınaması sırasında yaşanabilecek sorunları belirtiniz.
Kaynaklar67“Software Engineering A Practitioner’s Approach” (7th. Ed.), Roger S. Pressman, 2013.“Software Engineering” (8th. Ed.), Ian Sommerville, 2007.“Guide to the Software Engineering Body of Knowledge”, 2004.” Yazılım Mühendisliğine Giriş”, TBİL-211, Dr. Ali Arifoğlu.”Yazılım Mühendisliği” (2. Basım), Dr. M. Erhan Sarıdoğan, 2008, İstanbul: Papatya Yayıncılık.Kalıpsiz, O., Buharalı, A., Biricik, G. (2005). Bilgisayar Bilimlerinde Sistem Analizi ve TasarımıNesneye Yönelik Modelleme. İstanbul: Papatya Yayıncılık.Buzluca, F. (2010) Yazılım Modelleme ve Tasarımı ders notları(http://www.buzluca.info/dersler.html)Hacettepe Üniversitesi BBS-651, A. Tarhan, 2010.Yazılım Proje Yönetimi, Yrd. Doç. Dr. Hacer KARACAN
Ödev Yazılım Mimarileri Hakkında Araştırma Yapınız. İki Katmanlı ve Üç Katmanlı Mimarilerle yapılmış örneksistemleri araştırınız.47