Software development life cycle yazılım geliştirme yaşam döngüsü
•Als PPTX, PDF herunterladen•
5 gefällt mir•5,338 views
Yazılım geliştirme yaşam döngüsü hakkında kalite ve test bakışı açısından kısa bir sunum.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Software development life cycle yazılım geliştirme yaşam döngüsü
Ähnlich wie Software development life cycle yazılım geliştirme yaşam döngüsü (20)
Software development life cycle yazılım geliştirme yaşam döngüsü
- 1. SDLC Software Development Life Cycle
- 2. Geliştirme Boyunca Test SDLC Nedir? Test Nedir? Test Türleri Yazılım Geliştirme Modelleri
- 3. 1. SDLC Nedir? SDLC Software Development Life Cycle – Yazılım Geliştirme Yaşam Döngüsü Yazılım isteğinin doğmasından kullanıcılara sunulmasına kadar geçen süreç Çeşitli ‘Yazılım Uzmanlığı’ roller vardır
- 4. 1. SDLC Nedir? SDLC - Aşamaları İstek, Kanun Değişikliği, vb. ortaya çıkması Kullanıcı Gereksinimlerinin Belirlenmesi Sistem Gereksinimlerinin Belirlenmesi Üst Düzey Tasarım Çıktıları Detay Tasarım Çıktıları Yazılım Geliştirme Aşaması Test Süreçleri Yayınlama
- 5. 2. Test Nedir? Sürücü Testi Test süreçlerini anlamak için kulllanılır Nedir? Eğer sürücü çeşitli yolları deneyerek bir rotayı takip eder ve çeşitli manevralar yaparak rotasını güvenli bir şekilde tamamlar ise sürücü testi başarılıdır denir. Sürüş sırasında rotanın tamamlanmasına engel olabilecek tek bir ciddi hata tüm sürüşün başarısız olmasına sebep olur fakat sürüş sırasında birçok küçük hata şürüşün başarılı sayılmasına engel değildir.
- 6. 2. Test Nedir? ISTQB’ye Göre Test: ISEB - IEEE Sürücü analojisinden yola çıkarak testin açıklamasını şu parçalara bölmek gerekir: Proses (process) SLDC boyunca Test Yapılır Statik (static) ve Dinamik (dynamic) testler vardır Plan (planning) Hazırlanma (preparation) Değerlendirme (eveluation)
- 7. 2. Test Nedir? James Bach ve Michael Bolton: Test ile Kontrolün Fakı Testing is the process of evaluating a product by learning about it through experimentation, which includes to some degree: questioning, study, modeling, observation and inference. Süreç, öğrenme, sorgulama, modelleme, gözlem, çıkarım Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product Süreç, kural, gözlem
- 8. 3. Test Türleri Neler test edilir? Yazılımdan istenilenler yerinde ve yapılmış mı? Yazılım istenilen işlevleri yerine getiriyor mu? Yazılım işlevleri yaparken hata veriyor mu? Yazılım istenilen hızda yapıyor mu? Yazılım istenilen kadar işlev yapabiliyor mu? Yazılım istenilen işlevleri en çok ne kadar yapıyor? Yazılım istenileni kolay yapıyor mu? Yazılım istenilen işlevleri güvenli yapıyor mu? Yazılım işlevleri her zaman yapabiliyor mu? … validation verificaion reliability performance load stress usability security compatibilty İnter-operatability maintainability availability accessibility
- 9. Test Design Technics Static Review İnspection Walkthroughs Desk Checking Static Analysis Dynamic Structural (White Box) Data Flow Sybolic Execution Definition Use Control Flow Statament Branch Decision Branch Condition Branch Condition Combination LCSAJ Arcs Behavioural (Black Box) Non-functional Usability Performance Functional Equavalence Partitioning Boundary Value Analysis Cause-effect Graphing Random State Transition Gray-Box Performance Load Stress Endurance Spike API
- 10. 4. Yazılım Geliştirme Modelleri? Waterfall (Şelale) Modeli İstek, Kanun Değişikliği, vb Kullanıcı Gereksinimleri Sistem Gereksinimleri Üstdüzey Tasarım Detay Tasarım Kod Geliştirme Test Big-Bang
- 11. Test Neden Gerekli? Hatanın Maliyeti SDLC Gereksinim Tasarım Geliştirme Test Yayınlama Kısaca iyi test Ciddi hataları erken bulmaktır! Özay Civelek, testurk.com
- 12. 4. Yazılım Geliştirme Modelleri? V-Modeli İstek, Kanun Değişikliği, vb Kullanıcı Gereksinimleri Sistem Gereksinimleri Üstdüzey Tasarım Detay Tasarım Kod Geliştirme İstek, Kanun Değişikliği, vb Kullanıcı Gereksinimleri Sistem Gereksinimleri Üstdüzey Tasarım Detay Tasarım Kod Geliştirme Birim Testi Birim Entegrasyon Testi Sistem Testi Sistem Entegrasyon Testi Kullanıcı Kabul Testi
- 13. 4. Yazılım Geliştirme Modelleri? V-Modeli: Geç Test (early testing) İstek, Kanun Değişikliği, vb Kullanıcı Gereksinimleri Sistem Gereksinimleri Üstdüzey Tasarım Detay Tasarım Kod Geliştirme Birim Testi Birim Entegrasyon Testi Sistem Testi Sistem Entegrasyon Testi Kullanıcı Kabul Testi TEST TEST TEST TEST TEST
- 14. 4. Yazılım Geliştirme Modelleri? İteratif Yazılım Geliştirme Bir yaklaşımdır İşi fazlara bölmeye dayanır
- 15. 4. Yazılım Geliştirme Modelleri? Agile Yazılım Geliştirme Modeli Manifesto – 2001 http://agilemanifesto.org/ Daha fazla insan odaklı Dökümantasyon çok çalışan işe önem verir Müşteri odalılık Daha hızlı cevap verme Pratikleri Rational Unified Process (RUP) Scrum Extrem Programming (XP)
- 16. 4. Yazılım Geliştirme Modelleri? Toyotist vs Fordist Taiichi Ohno Toyota üretim sisteminin kurucusu “In the American system, a lathe operator is always a lathe operator and a welder is always a welder to finish. In the Japanese system, an operator has a wide range of possibilities. You can work with a lathe, use a drill and operate a milling machine.) Who can say which system is better ” (Ohno, 1991, p. 41).
- 17. 4. Yazılım Geliştirme Modelleri? Hangi model daha uygun Agile Küçük projeler Değişken gereksinimler Zaman kısa Deneyimli kadro Waterfall Gereksinimler net ve değişmiyor Büyük proje V-Model Değişken gereksinimler Büyük proje Aşamalarda onay isteniyorsa Risk fazla
- 18. Teşekkürler.
Hinweis der Redaktion
- SDLC (Software Development Life Cycle – Yazılım Geliştirme Yaşam Döngüsü) boyunca test etmek niçin gerekli bu ünitede tartışılacak. Yazılım geliştirme methodları neler olduğu ve farklı methodlarda nasıl daha iyi test edileceği yine bu ünitenin konusu içerisindedir.Kaynaklar:http://agilemanifesto.orghttp://www.istqb.org/downloads/viewdownload/16/15.htmlhttp://www.satisfice.com/blog/archives/856http://www.jitbm.com/Volume2No1/waterfall.pdfhttp://newunionism.wordpress.com/2012/02/16/employment-relations-quality-assurance/http://www.akimoo.com/2012/fordism-to-toyotism/http://en.wikipedia.org/wiki/Agile_software_development
- Sürücü Testi Nedir?Eğer sürücü çeşitli yolları deneyerek bir rotayı takip eder ve çeşitli manevralar yaparak rotasını güvenli bir şekilde tamamlar ise sürücü testi başarılıdır denir.Sürüş sırasında rotanın tamamlanmasına engel olabilecek tek bir ciddi hata tüm sürüşün başarısız olmasına sebep olur fakat sürüş sırasında birçok küçük hata şürüşün başarılı sayılmasına engel değildir. Yazılım testi açısından bakıldığında, yazılım birçok küçük hatalar olabilir hatta bunları bulmak uzman test mühendisleri için dahi zor olabilir, yazılım testi bu tip hatalardan ziyade yazılımın konusuna ve önemine göre dikkat alınacak olan ciddi hataların bulunması ve raporlanması olarak açıklanabilir. Hatalardan tamamen ayıklanmış bir yazılım sadece hayal ürünüdür fakat hataların kontrol edildiği, risk değerlendirilmesi yapıldığı ve raporlandığı test anlayışı daha uygulanabilir bir test anlayışıdır.
- Proses (process)Test tek bir aktiviteden ziyade bir süreçtir. Belli kaideleri vardır ve herbir olgu bu kurallar içinde değerlendirilir. Sürecin kalitesi aslında işletilen testin de kalitesini verir. Test kalite içerisinde en önemli başlıktı fakat test bir süreç dahilinde işletiliyorsa.SLDC boyunca Test YapılırTest sadece geliştirme tamamlandıktan sonra yapılan ve burada biten bir activite değil SDLC’nin her bir evresinde değişik test tipleri işletilerek yazılım sürecine katkıda bulunulur. Unutmayınızki iyi SDLC’nin erken evrelerinde bulunan hatalar kolay çözülebilir ve daha düşük maliyetler harçanır.Statik (static) ve Dinamik (dynamic) testler vardırTest sadece kara kutu (black box) değil aynı zamanda beyaz kutu (white box) ve gri kutu (gray box) testleride kapsamaktadır. Testin alanı sadece ekran karşısından bilenin fonksiyonların doğru çalışmasını kontrol etmek değil ilerde değinileceği gibi daha geniş bir kapsamı vardır.Planlama (planning)Test planı teste hazırlık kısmında yapılır ve buna bağlı kalmak şarttır.Hazırlanma (preparation)Testle ilgili herşey bu evrede hazırlanır ve teste başlama kriterlerinin (start enterance criteria) oluşmasıyla teste başlanır. Test sonlandırma kriterleri (test exit criteria) ile de test sonlandırılır.Değerlendirme (eveluation)Test sonladırılması ile test sonuçları değerlendirilir.
- http://www.satisfice.com/blog/archives/856
- Sürekli genişleme eğiliminde, örneğin en son eklenen ‘accessibility’ kavramı özürlü insanların da yazılımları kullanabilmesi için veya yazılımı özürlüler için daha kullanılabilir yapmak için gerekli özellikler denebilir. Yani kullanıcı kullanıcı kitleniz içerisinde bu türden bir grup var ise buna dikkat etmek gerekir.
- Şelale modeline göre yazılım geliştirme süreçleri birbirini takip eden farklılaşmış yazılım uzmanlık alanlarından oluşmaktadır. Yazılımın ihtiyaç duyulması (İstek, Kanun Değişikliği, vb) aşamasından başlar en sondaki aşama olan test ile sonlanır ve yazılım devreye alınır. Yani her bir aşamada kendisine iş gelene kadar beklemektedir. Burada karşılaşılan en büyük sorun ise zamanlama sorunudur. Yazılıma başlanırken uygulanan plana bağlı kalınmadığı durumlarda, örneğin test aşamasına gelene kadar her aşamadaki aşamadaki ufakda olsa geçikmeler kümülatif olarak toplandığında test için ayırılan sürenin kısalması veya olmaması durumuyla karşı karşıya kalınabilir. Şelale modelinde özellikle analizde oluşan hatalar testte yakalandığında hatanın maliyeti çok yüksek olmaktadır. Yani hatalı durum için yeniden analiz-tasarım-kodlama-test süreçlerinin işletilmesi gerekmekte ve planlanan süreyi uzatmaktadır. Genel olarak büyük projelerde şelale modelinin uygulanması önerilmemektedir.
- Yazılım Geliştirme Hayat Döngüsü (SDLC)Gereksinimlerin müşterilerden toplanarak analiz edilip daha sonra tasarım, geliştirme, test ve yayınlama gibi evrelerinden oluşan bir döngüdür. Bu döngü içerisinde hatanın bulunduğu yere göre yazılıma maliyeti farklılık göstermektedir. Son evrelerde yakalanan hatanın maliyeti, erken evrelerde yakalanan hatanın maliyetine zamanın karesiyle (exponential) orantılı olarak artmaktadır. Bu testin önemini arttırmaktadır. Kısaca iyi test Ciddi hataları erken bulmaktır! – Özay Civelek, Testurk.com.
- Şekilde görünen yazılım geliştirme modeli şeklinde dolayı V-Model ismini almıştır. Buradaki süreçler test açısından iki kısıma ayrılabilir. Birinci kısım İstek Toplama – Kod Geliştirme ve ikinci kısım ise Kod Geliştirme – Kullanıcı Kabul Testleri’ne kadar olan kısımdır. Diğer bir adıyla ilk kısım sağlama (validation) yani isteklerin yerinde olup olmadığı ile ilgilidir. Burada bahsi geçen her bir maddenin veya gereksinimin test edilebilir olması gerekir. Test edilemeyecek kadar net olmayan gereksinimlerin bu döngüde bir sonraki aşamaya geçmemesi gerekir. İkinci kısımda ise doğrulama (verification) adımıdır burada ise sağlaması yapılmış gereksinimlerin gerçekten istenildiği gibi yapılıp yapılmadığı kontrol edilir. V-Modeline göre herbir yazılım sürecine farklı test yöntemleri uygulanır böylece ortaya çıkabilecek hataları daha önce bulma yeteneği kazanır. Böylece test aktivitesi yazılım geliştirme hayat döngüsü boyunca uygulanmış olur.
- Erken test modelinde test aktivitesi daha erken başlamaktadır. İsteklerin alıdığı aşamadan itibaren test aktivitesi test tasarımı ve model base test şeklinde gerçekleştirilebilir. Yani gereksinimler toplanmasıyla birlikte gereksinimler test edilebilir veya analiz çıktıları ortaya çıktığında süreç içerisinde mantıksız, muallak veya işletilmesi anlamsız olan süreçler çıkartılarak daha kod geliştirme sürecinde yazılımcı için daha açık ve net analiz çıktıları sağlanabilir. Daha sonra hazırlanan test caseler, test case çalıştırma aşamasında hızla çalıştırılarak süreç daha hızlı işletilebilir. Bu model ile süreç toptan iyileştirilmiş ve test aşamasına daha olgun yazılımın gelmesine fayda sağlayabilir.
- Esasında bir metodoloji değil bir yaklaşımdır. İteratif yazılım geliştirme yöntemi, şelale modelinin (geleneksel yöntemler) alternatifi olarak düşünülebilir. Çünkü şelale modelini ele aldığımızda tüm yazılım süreci tek bir iterasyondan oluşmakta ve en son adımda test süreci bir patlama şeklinde herşeyi test etmeyi amaçlamaktadır. İteratif yazılım geliştirme modelinde ise tüm yazılımı tek bir iterasyondan öte süresi belli olan ve bu süre içerisinde yazılımı ilgili parçalara bölerek belirlenen süre içerisinde bitirmeyi amaçlamaktadır. İteratif modelde her iterasyonun süresi bellidir yazılım içerisindeki tüm roldeki kişiler bu zamanlamanın farkındadır ve olası geçikmeler sadece ilgili iterasyonu etkiler. Bu sebepten yönetilebilirliği diğer modellere göre daha iyidir.
- Agile metodu iteratif yazılım geliştirmesinden esinlenilmiştir. Daha fazla insan odaklıdır çünkü konuların (işlerin) günlük olarak yapılan kısa toplantılarda üzerinden geçilir ve yazılımcının canını sıkan durumlar var ise onlar dile getirilir ve paylaşılır. Agile bir yazılım geliştirme metodolojisidir ve pratikte farklı alt başlıklar altında uygulamaları vardır. XP (extreme programming) yöntemi ise öncelikle test caseler için scriptler yazılır ve bu scriptler zaman zaman çalıştırılarak tamamen hatasız geçene kadar yazılım geliştirilir. Yani önce test scripleri yazılır sonra ürün kodu. Bunun içindir ki bu yöntemde herkes biraz test mühendisidir, test mühendisleride yazılım uzmanıdır; yani herkes yazılım uzmanı olarak değerlendirilir. Scrum’da ise yazılım geliştirme işi küçük gruplar halinde ortaya çıkartılır. Günün belli bir saatinde ‘dailystandup’ denilen toplantılar yapılarak; ‘dün ne yaptım, bugün ne yapacağım ve engeller ne’ sorularının cevabı kısaca verilir. Detaylara girilmez ve çözüm aranmaz. Herkes yazılım uzmanıdır, test veya analist gibi farklı uzmanlıklar harici hizmet vermek adına istek üzerine gruba dahil olur. Scrum’da roller şu şekildedir: Product Owner, Development Team, Scrum Master, Stakeholders, Managers. RUP’ta ise bir uygulama türünden çok bir geliştirme framework sunar ve başlama, değerlendirme, geliştirme ve geçiş süreçleri vardır. Her bir süreçte modelleme, gereksinim belirleme, geliştirme, test, deployment aşamaları bulunur fakat işin başında modelleme, sonunda ise deployment daha fazla olur. Bu uygulama türünde ise yapı (structure) önemlidir ve bu yüzden use-case modelleri sık kullanılır ve riskin fazla olduğu parçalar daha önceden belirlenerek hızla çıkılması sağlanır.
- Henry Ford tarafından kurgulanan sisteme Fordist üretim sistemi denir. Fordist üretim Marksisekoniminin getirdiği daha fazla üretimi desteklemek adına sisteminde işçiler bir işte uzmanlaştırılır ve daha hızlı yapmaları için gerekli makine/süreç iyileştirilmesi yapılarak en fazla verime odaklanır. Toyota sisteminde ise işçilerden ziyade bir gruptan ve grubun çıkartacağı isten bahsedilir. Grup içerisindeki işlerde bir işçi çeşitli fonksiyondaki işleri yapma yeteneği vardır. Yani Fordist sisteminden sistemde işçi genelde vasıfsızdır ve yönetim tarafından emredileni yapar kişinin yaptığı işten sonrası için herhangi bir kaygısı yoktur. Toyota siteminde ise grubun çıkartacağı işin kalitesi önemlidir, bu yüzden ‘kalite’ den bahsedilir. Yazılımda bunun yeri ise, agile yaklaşımında görülür. Kanbanmethodu yine Toyota’nın uyguladığı bir metottur ve yazılıma da girmiştir. Agile ile bireysellikten uzaklaşıp daha fazla bir grup olgusu vardır ve çıkarılan işin kalitesi gruptaki her bireyin kaygısıdır.