Doğrulama ve Geçerlilik

1. Doğrulama ve Geçerlilik

2. Doğrulama ve Geçerlilik • Doğrulama: “Ürün doğru mu geliştiriliyor?" • Yazılım, belirteçlere uygun geliştirilmelidir • Geçerlilik: “Doğru ürün mü geliştiriliyor?" • Yazılım kullanıcı isteklerini yerine getirmelidir • Doğrulama ve Geçerlilik (Validation & Verification) yöntemleri yazılım sürecinin her adımına uygulanmalıdır • İki önemli hedef: • Sistemdeki kusurların (defect) bulunması • Sistemin kullanıcı için yararlı olabileceğinin kestirimi

3. V & V amaçları • Doğrulama ve geçerlilik, kullanıcıda yazılımın amacına uygun olması güvenini oluşturmalıdır • Ama bu güven yazılımın bütünlükle kusursuz olacağı anlamına gelmez • Gereken güvenin seviyesi yazılımın kullanım amacına bağlıdır: • Uçağın kontrolü yazılımı ve restoranda masa rezervasyonu yazılımı

4. V & V güveni • Sistemin amacına, kullanıcı beklentilerine ve pazarlama ortamına bağlıdır • Yazılım işlevi • Güven seviyesi, yazılımın kullanılacağı ortam (kurum) için ne kadar önemli olmasına bağlıdır • Kullanıcı beklentileri • Bazı yazılımlar için kullanıcıların beklentileri düşük olabilir • Pazarlama ortamı • Ürünün kusurlu halde erken pazara sürülmesi, kusurların bulunmasından bazen daha önemli olabilir

5. Statik ve dinamik V&V • STATİK – yazılımı gözden geçirme • Sorunları bulmak için statik sistem çözümlemesi • Araç desteği ve kod çözümlemesi • DİNAMİK – yazılımın denenmesi • Ürünün davranışının izlenilmesi • Sistem deneme verileri ile çalıştırılır ve onun davranışı gözlemlenir

6. Statik ve dinamik V&V Statik doğrulama Gereksinimlerin belirteci yüksekseviye tasarımı formal belirteç ayrıntılı tasarım program prototip Dinamik geçerlilik

7. V & V planlama • Deneme ve gözden geçirme süreçlerinden daha iyi sonuç ala bilmek için ciddi planlama gerekmektedir • Planlama geliştirme sürecinin erken aşamalarında başlanılmalıdır • Plan, statik doğrulama ve deneme arasındaki dengeyi tanımlamalıdır • Deneme planlamasında deneme süreci için standartlar tanımlanmalıdır

8. Geliştirme için V-model Gereksinim belirteci sistem belirteci sistem tasarımı ayrıntılı tasarım Modül kodlama ve deneme teslim denemesi planı sistem bütünleşme denemesi planı alt sistemlerin bütünleşme deneme planı Hizmetler teslim denemesi sistem bütünl. denemesi altsistem büt. denemesi

9. Yazılımın gözden geçirilmesi • Sapmaları ve kusurları ortaya çıkarmak için kaynakların incelenmesi • Sistemin yürütülmesini gerektirmez • Çalıştırmadan önce kullanıla bilir • Kusurlar • Mantıksal hatalar • Kodlardaki sapmalar( örn., başlangıç değer verilmemiş değişken) • Standartlarla uyumsuzluk • Sistemin her türlü kaynaklarına uygulana bilir • gereksinimler, tasarım, deneme verileri ve s. • Hataları ortaya çıkarmak için etkili yöntem • Basit gözden geçirme ile çok farklı kusurları ortaya çıkarmak mümkündür • Alan ve programlama bilgilerinin yeniden kullanımı • Gözden geçirenler, sıklıkla ortaya çıka bilecek kusurları seze bilirler

10. Gözden geçirme ve deneme • Gözden geçirme ve deneme biri birini tamamlar • Her ikisi V & V sürecinde kullanılır • Gözden geçirme, müşterinin gerçek gereksinimlerine uyumluluğu değil, belirteçlere uyumluluğu yoklar; • Gözden geçirme işlevsel olmayan niteliklerin (başarım, kullanılabilirlik) denemesini yapamaz

11. Gözden geçirme grubu • En azı 4 kişi • Kodun yazarı • Gözden geçiren(Inspector) hataları ve uyumsuzlukları bular • Okuyucu (Reader) kodu grup üyelerine anlatır • Yönetici (Moderator) toplantılara başkanlık yapar ve hataları kaydeder

12. Gözden geçirme grubu-devamı • Sistem, gözden geçirme grubuna anlatılır • Kod ve uygun belgeler grup üyelerine dağıtılır • Gözden geçirme zamanı bulunan hatalar kaydedilir • Bulunan hataları gidermek için güncellemeler yapılır

13. Otomatik statik çözümleme • STATİK çözümleyiciler –kaynak kodu işlemek için yazılım araçları • Onlar program metnini taramakla olası hatalı koşulları bulmaya çalışır ve bu hataları V&V grubuna bildirir • Gözden geçirme sürecinde çok etkilidir. • Gözden geçirme yerine kullanılamaz

14. Statik çözümleme-hata türleri

15. Statik çözümleme adımları • Denetim akışlarının çözümlenmesi • Çok girişli veya çıkışlı döngüleri yoklamalı, erişilemeyen kodları bulmalı ve s. • Verilerin kullanımının çözümlenmesi • Başlangıç değerler verilmemiş, tanımlanmış, ama hiç zaman kullanılmayan değişkenlerin ve s. bulunması • Arayüzü çözümlenmesi • Altprogram ve yordamların belirtilmesi ve kullanımındaki tutarlılığının yoklanılması • Bilgi akışının çözümlenmesi • Çıkış değişkenlerinin bağımlılığının tanımlanması • Yol çözümlenmesi • Programdaki yolların ve bu yollarda yürütülen komutların araştırılması

16. Kusur denemesi ve kod ayıklama farklı süreçlerdir Denemenin amacı programda kusurların varlığını tespit etmektir Kod ayıklama hataları yerelleştirmek ve aradan kaldırmak içindir Deneme ve kod ayıklama-Testing and debugging

17. Deneme • Denemenin amacı, hataların var olmasını araştırmaktır • Denemenin başarısı ,onun hatayı bulması ile ölçülür • Deneme, işlevsel olmayan gereksinimlerin geçerliliğini değerlendirmenin tek yöntemidir • Statik doğrulama ile birlikte kullanıla bilir

18. Deneme türleri • Kusur denemesi • Sistemin kusurlarını bulmak için tasarlanır. • Başarılı kusur denemesi sistemde hataların varlığının belirlenmesinde çok önemlidir • İstatistiksel deneme • Güvenilirliği değerlendirmek için; • Kullanıcı girişlerinin sıklığını ifade etmek; • Güvenliğin tahmini için kullanılır

19. Yazılım deneme planının yapısı • Deneme süreci • Gereksinimlerin izlenebilirliği • Denenen birimler • Deneme zaman çizelgelemesi • Deneme yordamları • Donanım ve yazılım gereksinimleri • Kısıtlamalar

20. Önemli hususlar • Doğrulama ve geçerlilik aynı şey değildir. • Doğrulama sistemin belirtece uygunluğunu gösteriyor • Geçerlilik, programın müşteri isteklerini karşılamasını gösteriyor • Deneme sürecini yerine getirmek ve kontrol etmek için deneme planları hazırlanır • Statik doğrulama yöntemleri hataları bulmak için programın çözümlenmesini kapsar • Programın gözden geçirilmesi, hataları bulmak için çok etkili yoldur • Gözden geçirme zamanı program kodu küçük grup tarafından kontrol edilir • Statik çözümleme araçları program sapmalarını bula biliyor

21. YAZILIM KALİTESİYAZILIM HATALARIDENEME Sarı arka planlı sayfalar bilgi amaçlıdır; içeriği sınav soruları kapsamına dahil değil

22. Yazılım Hataları ve ya “Böcek”(Bug) Yazılım hataları- ürününün kalitesinin gereksiz veya sebepsiz yere düşmesine neden olan her şey Yazılım «böceği» bilgisayar programı veya sisteminde oluşan, yanlış, beklenmedik sonuçlara neden olan hatalar, kusurlardır. Böceklerin büyük kısmı insan hatalarından (kaynak kodları ve tasarım hataları) kaynaklanmaktadır. Az bir kısmı ise doğru kod üretmeyen derleyici hatalarından kaynaklanıyor. Programda oluşmuş «böcekler» hakkında bilgiler hata (kusur) raporlarında yer alıyor.

23. «Böcek» tarihçesi There is somecontroversyovertheorigin of theterm "debugging." In 1946, whenHopperwasreleasedfromactiveduty, shejoinedthe Harvard Faculty at theComputationLaboratorywhereshecontinued her work on theMark IIandMark III. Operatorstraced an error in the Mark II to a mothtrapped in a relay, coiningthetermbug. Thisbugwascarefullyremovedandtapedtothelogbook. Stemmingfromthefirstbug, todaywecallerrorsorglitch's in a program a bug. TheOxford English Dictionaryentryfor "debug" quotestheterm "debugging" used in referencetoairplane engine testing in a 1945 article in theJournal of theRoyalAeronauticalSociety, Hopper'sbugwasfound on the 9th of September in 1947. Thetermwas not adoptedbycomputerprogrammersuntiltheearly 1950s. TheseminalarticlebyGill in 1951 is theearliest in-depthdiscussion of programmingerrors, but it does not usetheterm "bug" or "debugging". IntheACM'sdigitallibrary, theterm "debugging" is firstused in threepapersfrom 1952 ACM NationalMeetings

25. Ayıklama-Debugging Beklenen hedefleri sağlamaları amacıyla bilgisayar programında veya donanım parçalarında kusurları (böcekleri) bulmak veya azaltmak için yapılan süreç Ayıklamanın, özellikle sıkı birleşimli altsistemlerde yapılması zordur; bir altsistemdeki değişmeler diğerlerinde pek çok “böceğe” sebep olabilir

26. Kalite nedir? Gereksinimlere uymak Gerçek gereksinimler (yazılı veya yazılı olmayan) Bir ürünün özellikleri bütünü Belirli bir ihtiyacı karşılama yeteneği Ürün ve hizmetlerin müşteri isteklerini karşılaması Ürünün ve hizmetin içeriği…

27. • güvenilirlik • kullanılabilirlik • bakımı yapılabilirlik • denene bilirlik • işlevsellik/yetenek • işlem hızı • ölçeklenebilirlik • yerelleştirile bilirlik • belgelene bilirlik • öğrenile bilirlik • teknik desteklenebilirlik Kalitenin çokboyutluluğu

29. Kaliteye farklı bakış açıları Yerelleştirme Yöneticisi (Localization Manager): İyi ürünün diğer bir ülkeye,dile, kültüre uygun değiştirilmesi çok kolay olmalıdır Teknik Belgeleyici (Tech Writers): İyi ürün kolaylıkla anlatıla bilmelidr. Her türlü belirsizlikler, tutarsızlıklar ve açıklamalardaki zorluklar ,ürünün kalitesini düşürecektir. Pazarlama (Marketing): İyi ürünleri alıcılar satın almakta isteklidirler ve bu ürünü almak için diğerlerini de teşvik ederler. Müşteri Hizmeti (Customer Service): İyi ürün destekleyici olmalıdır: insanlara kendi sorunlarını çözmekte yardımcı olmalıdır. Programcı (Programmers): İyi program kodu bakımı yapılabilir olmalı, kolay anlaşılmalı, hızlı çalışmalı ve kompakt olmalıdır.

30. DENEME DENEME STRATEJİLERİ

31. Yazılım testi, bir yazılımın bütününün veya kodun belli bir kısmının gereksinimleri karşılayıp karşılamadığını, uygun şekilde hazırlanmış testler sayesinde öğrenme amaçlı yapılan birim çalışmalardır. • Yazılım testinin yapılma amaçları olarak; ileriye dönük kodun geliştirilme masraflarını azaltmak, ürün çalıştırılmadan önce kalitesini ve senaryolara uygunluğunu denetlemek, geliştirme sırasında gözden kaçan yanlışları bularak bu yanlışların ileride de tekrarlanmasını önleyerek zaman ve maliyet tasarrufu yapmak sayılabilir.

32. Yazılım projeleri değerlendirilirken test sürecine gelen ürünler, süreçlere uygun olarak teste tabi tutulur fakat ideal bir test süreci kodlama sürecinden ayrı değerlendirilmemelidir. İdeal bir test sürecinde olması gereken kodlama ve test süreçlerinin birbirinden koparılmamasıdır. Bu süreçte analiz, tasarım, teste hazırlık süreci, kodlama süreci, dinamik test süreci, testin bitirilmesi ve yazılımın ürün haline gelmesi şeklinde değerlendirilebilir.

33. Yazılım Denemesine Strateji Yaklaşım • Deneme- önceden planlaştırılan ve düzenli yapılan girişimler kümesi • Deneme modül seviyesinde başlar ve “içten dışa” doğru tüm bilgisayarlı sistemi kapsar • Farklı geliştirme süreçlerinde farklı deneme teknikleri uygulana bilir • Deneme ve Kod ayıklama (debugging) farklı girişimlerdir ve kod ayıklama her bir deneme stratejisinde kullanıla bilir • Deneme yazılım geliştirici tarafından ve (büyük projeler için) bağımsız deneme grubu tarafından gerçekleştirilir

34. Yazılım Kalitesinin Sağlanması Ölçme Formal Teknik İnceleme Yazılım Mühendisliği Yöntemleri Yazılım sistemi Deneme Yazılım Kalite Yöneticiliği ve Yazılım kalite Güvencesi Standartlar ve Yöntemler

35. Yazılımın Denenmesi Mekanizmasının oluşturulması • Yapıcı işler- yazılım çözümleme ve tasarım • “Dağıtıcı” iş- deneme • Yazılım geliştirici program birimlerinin (modüllerinin) denenmesinde sorumludur • Geliştirici, bütünleme denemesine de katılır • Yazılım Mimarisi bittikten sonra bağımsız deneme grubu devreye girer

36. Yazılım Deneme Adımları gereksinimler Sistem Denemesi Bütünleme Denemesi tasarım Birim d. kod Deneme yönü

37. Deneme Belirteci • Denemenin Kapsamı • Deneme Planı • Deneme Yordamı • Bütünleme sırası • Modüller için Birim denemesi • Deneme Ortamı • Deneme Durumu verileri • Beklenen sonuçlar • Gerçek Deneme Sonuçları

38. Deneme Ölçekleri • Arayüzü bütünlüğü • İşlevsel geçerlilik • Bilgi tamlığı • Başarım

39. Kusurların denenmesi • Sistem kusurlarının varlığını ortaya çıkaran deneme programları

40. Kusur denemesi sureci deneme durumları deneme verileri deneme sonuçları deneme raporları Deneme durumlarının deneme verilerinin hazırlanması deneme verileri ile durum sonuçlarının Tasarlanması programın çalıştırılması karşılaştırılması

41. Birim Denemesi: • Ayrı-ayrı program bileşenlerinin denenmesi • Genelde bileşenin geliştiricisi sorumludur (kritik sistemler dışında) • Denemeler geliştiricinin deneyimlerine dayanmaktadır Amaç:Altsistemlerin doğru kodlaştırıldığının ve gereken işlevleri yerine getirdiğinin doğrulanması

42. Birim Denemesi • Birim Denemesi yazılım ürününün en küçük birimi üzere doğrulama işlemlerini yapmak içindir Arayüzü Yerel veri yapısı Sınır koşulları Bağımsız yollar Modul Deneme durumları

43. Bütünleme Denemesi: • Geliştirici tarafından yerine getirilir • Sistemi veya altsistemi oluşturmak için bir araya getirilmiş bileşenler grubunun denenmesi • Bağımsız deneme grubu sorumludur • Deneme sistem belirteçleri üzere gerçekleştirilir • Amaç:Altsistemler arasında arayüzlerinin denenmesi

44. Sistem Denemesi: • Sistem geliştirici tarafından yerine getirilir • Amaç: Sistemin, gereksinimleri (işlevsel ve genel) karşıladığının belirlenmesi • Türleri: Kurtarma (recovery) Denemesi Güvenirlik (security) Denemesi Stres Denemesi Başarım Denemesi

45. Geçerlilik (validation) Denemesi • Geliştiricinin teslim ettiği sistemin değerlendirilmesi • Kara kutu denemeleri ardışıklığı • Geçerlilik denemesi sonucu: • işlev veya başarım belirteçlere uygundur; kabul edilir • belirteçten sapmalar var ve yetersizlik listesi oluşturulur • Amaç:Sistemin gereksinimleri karşıladığını ve kullanım için hazır olduğunu göstermek

46. Deneme öncelikleri • Yalnız “tepeden-tırnağa” deneme, programın kusurlarının olmadığını göstere bilir. Ama , böyle deneme mümkün değil. • Deneme ilk öncelikle bileşenlerinin değil, sistemin kendisinin yeteneklerinin sınanmasına yönelmelidir • Tipik durumların denenmesi, sınır değerlerine uygun durumlarındenemesinden daha önemlidir

47. Deneme verileri ve deneme durumları • Deneme verisi-Sistem denemesi için giriş değerleri • Deneme durumları-Sistemi denemek için giriş verileri ve eğer sistem, belirtecine uygun işlerse, bu veriler sonucu öngörülen çıkışlar

48. Eşit parçalama • Sistemin giriş ve çıkışlarının “eşit kümelere” parçalanması • Eğer giriş 10,000 ve 99,999 arasında 5 rakamlı tam sayıdırsa , eşdeğerli kısımlar <10,000, 10,000-99, 999 ve > 10, 000 olacak • Deneme durumlarını bu kümelerin sınırlarında seçmeli 00000, 09999,10000, 10001, 99999, 100000

49. Eşit parçalama-örnek

50. İkili arama programı için koşullar procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; önkoşul -- dizide en az bir eleman vardır T’FIRST <= T’LAST sonkoşul -- aranan eleman bulunmuştur ve dizinin L.ci elemanıdır ( Found ve T (L) = Key) veya -- aranan eleman dizide yoktur ( not Found ve not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))