1 / 38

YZM 320 - Yazılım Doğrulama ve Geçerlileme

YZM 320 - Yazılım Doğrulama ve Geçerlileme. Hazırlayan:Emin BORANDAĞ. Test Dokümanında neler olmalıdır?. Test planı Kalite hedefleri, kaynak ihtiyacı Yöntemler Test durumları Giriş ve beklenen çıktıları. Hata raporları Örneğin, Bugzilla web tabanlı bug tracker.

tamar
Download Presentation

YZM 320 - Yazılım Doğrulama ve Geçerlileme

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. YZM 320 - Yazılım Doğrulama ve Geçerlileme Hazırlayan:Emin BORANDAĞ

  2. Test Dokümanında neler olmalıdır? • Test planı • Kalite hedefleri, kaynak ihtiyacı • Yöntemler • Test durumları • Giriş ve beklenen çıktıları. • Hata raporlarıÖrneğin, Bugzilla web tabanlı bug tracker. • Kullanılan Test araçları ve otomasyon Ölçümleri, istatistik ve özetleri • Çözümlenmemiş hata sayısı, bir hata, vb tamir süresi

  3. Yazılım Proje Çalışanları • Proje yöneticileri • Programı yönetmek, kritik kararları vermek, ürüne ait yazılımları belirle. • Yazılım mimarları, sistem mühendisleri • Tasarım, yazılım, programcılar ile yakın bir çalışma • Programcılar, geliştiriciler, kodlayıcılarHata düzeltme, kod yazma • Test, kalite güvence personeli olmalı • Hataları tespit, hataları belgele, hataları takip, çözümleme ile ilgili ilerlemeyi takip • Konfigürasyon yöneticileriPaketleme versiyon oluşturma, belgeler in yazımı

  4. Yazılım Geliştirme Yaşam döngüleri • Code and Fix • Waterfall • Spiral

  5. Hangi konulara baktık… • Yazılım Test uzmanının görevleri nelerdir? • Yazılımda test hangi aşamalarda olmalı? • Yazılım geliştirmenin en önemli safhası nedir? • Test dokümanı nasıl olmalıdır? • Yazılım geliştirme yaşam döngüleri nelerdir?

  6. 2.Bölüm Yazılım Testine Giriş

  7. Alıntı • Bilimsel bir modelin rasyonel olması, o modelin doğru olduğu sonucunu içermez. • Bilim bazen kaotik bir yol izleyebilir.

  8. Yazılım ve Güvenliği Kritik Uygulamalar • Güvenliğin önemli olduğu pek çok yerde(Hataya tahammülün olmadığı yada çok az olduğu yerlerde), “safety-critical” güvenlik açısından kritik yazılımlar kullanmaktayız. • Eğer bu yazılımlar doğru olarak çalışmaz ise çok büyük sıkıntılarla karşılaşa biliriz. • Nükleer reaktörler • Uçuş kontrol sistemleri • X-ray makinelerde yazılım kontrolörleri

  9. Yazılım ve Güvenliği Kritik Uygulamalar • Güvenlik öncelikli uygulamalarda • Kapsamlı testler, Kod incelemesi ve yazılım geliştirme yöntemleri daha titizlikle uygulanmalıdır. • Şu ana kadar yapılan güvenlik öncelikli yazılımlardaki hata oranları diğer yazılımlara oranla daha düşüktür. Fakat • Teknolojik olarak ve ekonomik olarak bu tarz yazılımları oluşturmak zordur.

  10. Buhar motorları kısa tarihi • İskenderiye’de Heron, 60 MS buhar gücünü kullanmayı denedi. • Thomas Savery ilk buhar gücü ile çalışan motoru üretti. • 16-17 YY. buhar motorlarına olan ilgi arttı. • Newcomen 1700 yılında bu motorların yaygın kullanımını için bir silindir ve piston tasarladı. • 1786, James Watt büyük Newcomen diye adlandırılan motoru üretti.

  11. Buhar motorları kısa tarihi • Bu arada İngiltere’nin kuzeyinde sanayi devrimi ile ilgili büyük bir potansiyel vardı. • Watt and Matthew Boulton isimli üreticiler yeni motor tasarımlarını bu bölgede geliştirdiler (Ağır sanayi atılımı). • 1800 yılında Watt’ın patent süresi sona erdi ve yüksek basınçlı buhar motorlarını isteyen herkes üretebilecek hale geldi. (HPSEs) • İki tasarım geliştirildi. UK & USA • Ayrı kondansatörler yerine buharın direk pistonları itebilecek şekilde geliştirilmesi sağlandı.

  12. Buhar motorları kısa tarihi • İlk başarılı kullanım buharlı teknelerde oldu. • Oldukça başarılı idi. • Verimliydi, Ucuzdu. • Tekne yolculukları ucuzlamıştı. • Ekonominin büyümesini sağlamış ve tekne şirketleri bu işlerden büyük paralar kazanmışlardı. • BOOM!!!! • Buharlı teknelerdeki yolcular ve mürettabat havaya uçtu. • Tekne içerisindeki basınç miktarı olması gereken oranı aştı….

  13. Sorun neydi? • Yeterli eğitimi olmayan kişiler tarafından kullanım. • Hızlı ve ucuz malzeme kullanımı ve üretimi. • Kötü eğitimli operatörler. • Kötü kalite kontrolü. Niye böyle oldu? • Sadece para odaklı olarak üretim yapıldı.

  14. Patlamadan sonra neler oldu? • USA’da akademisyenlerden ve mühendislerden oluşan bir grup. Kallite standartları belirlemeye çalıştı. • UK’da Watt and Boulton şirketi bir erken uyarı sistemi geliştirdi. Ancak geliştirdikleri bu sistemi kendi buhar motorları sistemine adapte edemediler.

  15. Buhar teknolojisi… • Bu teknolojinin zayıf noktası (Aşhil topuğu) kazanların buhar nedeni ile patlaya bilecekleri gerçeği. • Kazan teknolojisi buharlı motor teknolojisinin gerisinde kalmış olması. • Maliyeti uygun olmayan geliştirme çalışmaları yapılmış.

  16. Süreç içerisinde • Yüksek basıncı altında çalışabilen, korozyona ve çürümeye dayanıklı malzeme kullanmaya ne gerek var; Ar-Ge çokta önemli değil.

  17. Sonuç • Boom!!! • Buharlı kazanlar patlamaya devam etti. • Neden? • Mühendisler hala yüksek basınç altında kazanların ne şekilde çalışması gerektiğini bilmiyorlardı. Ayrıca tasarım mühendisleri, sistemlerinin kullanımının nasıl olacağı anlamadı:- Yükleme ortamı- Operatör eğitimi - Açgözlülük, aşırı ve güven.

  18. Peki kim suçlandı? • İşciler (Operatörler) Peki kim suçlanmadı? • Tasarım Mühendisleri

  19. Hükümetin müdahalesi • İşler çözümlenecek garantisi verildi. • Firmalar denetlenecek denildi. • Sonuç? • BOOM!!! • Sonrasında daha fazla buharlı motor üretildi. • 1817 yılında UK’da komisyon kuruldu ve buharlı motorların tehlikeleri araştırıldı. • Komite kazanların daha fazla denetlenmesine karar verdi.

  20. Ağır Kayıp • Sadece Amerika’da 1816 ile 1848 yılları arasında. • 233 Kazan patladı • 2562 İnsanöldü • 2097 İnsan yaralandı • Yaklaşık $3,000,000 maddi kayıp oldu.

  21. Araştırma • Philadelphia, the Franklin Institute 6 yıl patlamalar ile ilgili araştırma yapılır. USA devleti maddi olarak destekledi. Araştırma Sonucunda • Üretimi düzenleyen bir mevzuat komite tarafından onaylandı. • Tararım için temel bazı kurallar geliştirildi. • Ölenlerin ailelerine tazminatlar verildi.

  22. BOOM!!! • Patlamalar devam etti. • Toplumun hükümet üzerindeki baskısı arttı. • Ve mevzuata son şekli verildi! • Nihayet, 1852 yılında, ABD kongre vapur kazanları ile ilgili ağır şartlar gerektiren bir yasayı onayladı.Bu mevzuat ağır test şartlarını da içermekeydi. • Vapur kazan patlamaları azalmaya başlar!... ancak güvensiz HPSEs hala lokomotif ve ağır sanayide kullanılıyor.

  23. Daha sert standartları • Daha sonra, İngiltere'de parlamento standartları geliştiren bir tasarıyı onaylar. • 1905 yılında, ölümlerin sayısı HPSE azalır.14 Türkiye383 Amerika Birleşik DevletleriEn sonunda, • USA üretim ile ilgili standartları detaylandırır ve test işine daha fazla önem veren bir standart oluşturur.

  24. Yazılımlarla olan ilişkisi??? • Biz bilgisayar çağındayız artık. • Bunların güvenlik açısından kritik yazılımla ne ilişkisi var. Paralelik nedir? (Yazılımlar patlar mı?)

  25. Analogies • Buhar motorları teknolojisi kazan geliştirilme teknolojisinin gerisinde kaldı. • Yazılım ile olan ilişkisi………………………….....

  26. Ne yapılmalı? • Zaman testleri yapılmalı ve iyi mühendislik ilkeleri kullanılmalı: • Doğrulama testleri, onaylama testleri yapılmalı. İkili ve üçlü kontrol sistemleri kullanılmalı. • Süreçleri durdurmadan süreçler üzerinde kontroller yapılmalı.

  27. Yazılım Mühendisliği Temelleri. • Kazan patlamaların nedenleri; çok az bilimsel anlayış vardı.Benzer şekilde, Yazılım mühendisliği disiplini çok yeni ve biz hala temeller üzerinde çalışıyoruz. • İyi bir tasarım nedir? • Yazılım bileşenlerinin belirleme. • Güvenlik kritik sistemler. • Formüllerle ve resmi yöntemlerin rolü • Doğrulama ve onaylama • Sistem evrim

  28. Sorunlar. • Bilginin paylaşılmaması (Şirketlerin bilgi paylaşımlarından korkmaları.) Analitik veri yok yada çok az!!! • Bilgi teknolojisi çok hızlı ilerliyor. Bunun sonucu pek çok farklı alanda yazılımlar kullanılıyor. (İsterler artıyor karmaşıklık artıyor.) • Yazılımları kontrol etmek,değerlendirmek ve geliştirmek için çok kısa bir zamanımız var.

  29. Mühendislik temelleri üzerinde çalışılmalı! • Kimse yenilik ve buluşların hayati olduğunu reddetmiyor, ama aynı zamanda mühendislik temeller üzerinde çalışmak gerekir: • Temel kuralları, ilkeleri ve yapısı • Değerlendirme kriterleri • Karşılaştırma yoluyla • Teorik sınırlarını ve yeteneklerini belirle • Üretim araçlarını belirle • Matematiksel modeller kullan ama gerçek dünyada örnekler üzerine kullanılacağını unutma.

  30. Sorgulanan yeni yöntemler. • "Örgün yöntemlerde matematik vardır. Doğru matematik yöntemleri süreçleri iyileştirir. Bu nedenle, biçimsel yöntemler yazılım kalitesini arttıracaktır. “ • Bu doğru olduğunu net değil! • Hangi yöntem ile yazılım geliştirilecek? • Uygulayıcıların eğitim? • Siyasi konular? Maliyeti? Ölçek? • Aracı olgunluk ve uygunluğu? • Daha iyi sonuç sistemleri var mı? Güvenli? Daha küçük? • Büyük? Daha anlaşılır?

  31. Nedenler • Patlamalar için geliştirilen güvenlik özelliği; düzgün bir tasarıma sahip olmadığı ve bilimsel anlayıştan uzak olduğu için işe yaramadı. • Proje geliştirilmeden önce detaylı inceleme yapılması gerekir! • Bir alanda kullanılan iyi bir fikir başka alanda işe yaramaya bilir.

  32. Yazılım Analojisi. • Yazılım analog N-sürümü programlama (NVP) denir: • Bizim N tane yazılım ekibimiz var. Her biriside yazılım ile ilgili ihtiyaçları bağımsız olarak kodluyorlar. • Her bir yazılım çalıştırılıyor ve bunların her biri bir oy alıyor.

  33. NVP’lerin potansiyel sorunu nedir? • Tüm yazılım arızaları tasarım hatalarından kaynaklanmaz. • Genellikle, programcılar hataları yanlış yorumlayabilirler. • Gereksinimler; genellikle yanlış anlaşılır. Bu nedenle N ekipleri aslında doğru yorumu yapan grup sayıyı genellikle 0 yada 1 dir.

  34. Algoritmayı Kurtarmak için temel olarak yapılması gerekenler. • Ortak hataları azaltmaz için algoritmayı parçalar halinde oluştur. • Kabul testlerini kodlayan kişi dışında bağımsız başka bir yazılımcıya oluştur. • Kodlama standartları belirle.

  35. Hatalara Karşı • Hata toleransı = Kullanıcının rastgele bulduğu hatalardan ibaret olsun(Kodlayıcı yada test sorumlusu bulduğu bir hatayı göz ardı etmesin) • Buharlı motorları üreten mühendisler çok ağır masayı saatlerinde çalışıyorlardı(Onlarca sorun ortaya çıktı). Bu nedenle yazılım oluşturmada masayı saatleri belirle(Örnek Extreme Programming pratiği haftada40 Saat). • Yazılım mühendisinin proje bilgisi çok iyi olmalı.Oluşabilecek sıkıntıları erkenden fark edip ekibini kurtarmalı.

  36. Güvenli yazılım geliştirilmesinin temel adımı. • Tehlikeleri erkenden fark et ve önlem al (Eğer yangından koruyorsan yangına dayanıklı materyal kullan.) • Dezavantajı maliyet,zaman • Tehlike meydana geldiğinde var olan prosedürleri uygula eğer yok ise proje ekibi ile prosedürleri oluştur. • Dezavantajı maliyet,zaman • Varsa deneyimlerden yararlanıp pratikleri uygula.(Her bir sistemin ihtiyaçları ve gereksinimleri farklı olduğunu unutma) • Dezavantajı Risk,maliyet,zaman,performans

  37. Hangi konulara baktık… • Yazılım doğrulaması ile buhar motorları arasında bir tarihsel analoji yaptık. • Güvenliğin önde olduğu yazılımlar ve özelliklerini inceledik. • Yazılım güvenliğine giriş yaptık. • Algoritma kurtarmak için yapılanlara baktık.

More Related