BIL 304 YAZILIM MÜHENDİSLİĞİ Süratli Yazılım Geliştirme Yrd Doç. Dr. Turgay İBRİKÇİ Uç (Extreme) programlama Bir çevik geliştirme metodolojisi 1990'ların ortalarında Kent Beck tarafından düzenlendi. Onların "aşırı" için alınan 12 anahtar uygulama kümesi Geliştiriciler ve müşteriler için bir hızlı yazılım üretme zihniyeti 12 XP Pratiği: - Planlama Oyunu - Küçük ve kısa aralıklı sürümler - Sistem metaforu - Basit tasarım - Test - Yeniden tasarım - Eşle Programlama - Ortak Kod Sahipliği - Sürekli Tümleştirme - 40 saat/hafta - Müşteride geliştirme - Kodlama Standartları Uç (Extreme) programlama Muhtemelen en çok bilinen ve en geniş kullanıma sahip çevik metottur Uç programlama (XP) tekrarlanan geliştirmeye bir uç yaklaşımdır. Yeni versiyonlar bir günde birkaç kere inşa edilebilir; Artışlar müşteriye her iki haftada teslim edilir. Bütün testler her inşa için çalıştırılmak zorundadır ve inşa sadece testler başarılı bir şekilde çalıştığında kabul edilmelidir. XP sürüm(release) döngüsü Uç programlama örneği 1 Incremental planning Small Releases Simple Design Test first development Refactoring Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these Stories into development Tasks. The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Enough de sign is carried out to meet the current requirements and no more. An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. All developers are expected to refactor the code con tinuously as soon as possible code improvements are found. This keeps the code simple and maintainable.
Uç programlama örneği 2 Pair Progra mming Collective Ownership Continuous Integration Sustainable pace On-site Customer Developers work in pairs, checking ea ch other s work and providing the support to always do a good job. The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything. As soon as work on a task is complete it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Large amounts of over-time are not considered acceptable as the net effect is often to reduce code qua lity and medium term productivity A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming p rocess, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation. XP ve çevik yöntemler Artışlı geliştirme küçük, yaygın sistemleri piyasaya çıkarırken desteklenir. Müşteri dahil etmenin manası müşterinin takım ile tam zamanlı meşguliyetidir. İnsanlar çift programlama, ortak mülkiyet ve uzun mesai saatlerinden kaçınan süreçleri devam ettirmiyorlar. Değişim düzenli sistem sürümlerince desteklenir. Kodun sabit yeniden üretimi (constant refactoring) sırasında sadeliğinin korunması. Gereksinim senaryoları XP de, kullanıcı gereksinimleri senaryolar veya kullanıcı hikayeleri olarak ifade edilir. Bunlar kartlar üzerine yazılır ve geliştirme takımı bunları gerçekleme görevlerine parçalar. Bu görevler plan ve maliyet hesaplamasının temelini oluştururlar. Müşteri öncelik ve plan değerlendirmelerine göre sonraki sürüme dahil edilecek öyküleri(stories) seçer. Doküman yükleme için hikaye kartı(story card) Downloading and printing an article First, you select the article that you want from a displayed list. You then have to tell the system how you will pay for it - this can either be through a subscription, through a company account or by credit card. After this, you get a copyright form from the system to fill in and, when you have submitted this, the article you want is downloaded onto your computer. You then choose a printer and a copy of the article is printed. You tell the system if printing has been successful. If the article is a print-only article, you can t keep the PDF version so it is automatically deleted from your computer. Uç Programlama (XP) ve değişim Yazılım mühendisliğinde, değişimlere göre tasarım yapmak kabul görmektedir. Yazılım sürecindeki masrafları azalttığı için beklenen değişiklikler üzerinde çaba sarf etmek ve zaman harcamak önemlidir. Ancak XP, değişimler güvenilir bir şekilde tahmin edilemediği sürece bunun harcanan emeğe değmeyeceğini savunur. Daha çok, yazılan bir kodda gerçekleştirilecek büyük değişiklikleri toplu olarak başka bir kod yardımı ile yapmayı önerir (Refactoring). Uç Programlamada Test Test öncelikli geliştirme Senaryolardan artırımsal test geliştirme Test geliştirme ve onaylamaya kullanıcının dahil edilmesi. Her yeni sürüm yapıldığında tüm bileşen testlerinin çalıştırılması için otomatikleştirilmiş test donanımları kullanılmaktadır.
Doküman indirmek için görev kartları Test durumu tanımlaması Görev 1: Ana iş akışını gerçekleştir Görev 2: Makale kataloğunu ve seçimini gerçekleştir Görev 3: Ödeme tahsilatını gerçekleştir Ödeme üç farklı şekilde yapılabilir. Kullanıcı ödeme yapmak istediği yolu seçer. Eğer kullanıcıların kütüphane aboneliği varsa, sistem tarafından kontrol edilecek şifrelerini girebilirler. Alternatif olarak, kurumsal bir hesap numarası girebilirler. Eğer geçerliyse, makale ücretinin borcu bu hesaba kaydedilir. Son olarak 16 basamaklı bir kredi kartı numarası ve bitiş tarihi girebilirler. Bunlar geçerlilik için kontrol edilmelidir ve geçerli ise bu kredi kartı hesabına borç postalanır. Test 4: Kredi kartı geçerliliğini test et Girdi: Kredi kartı numarasını temsil eden bir string ve kredi kartının bittiği ayı ve yılı temsil eden iki integer Test: Stringdeki tüm baytların rakam olduğunu kontrol et ay ın 1 ve 12 arasında olduğunu ve yıl ın bu yıla eşit ya da bu yıldan büyük olduğunu kontrol et Kredi kartı numarasının ilk 4 basamağını kullanarak, kredi kartı çıkaranlar listesine bakıp, kredi kartını çıkaranın geçerliği olduğunu kontrol et Kredi kartını çıkarana kart numarasını ve bitiş tarihini beyan ederek kartın geçerliliğini kontrol et Çıktı: Hata mesajı veya kredi kartının geçerliliğini gösteren Tamam mesajı Test öncelikli geliştirme Kodun gerçekleştirilecek gereksinimleri açığa çıkarmasından önce testlerin yazılmasıdır. Testler, otomatik olarak çalıştırılabilmeleri için tercihen veri olarak değil de program olarak yazılırlar. Test, doğru çalıştığının anlaşılması için bir denetim içerir. Yeni bir özellik eklendiğinde tüm eski ve yeni testler otomatik olarak çalışır. Böylece yeni özelliğin, hata ortaya çıkarıp çıkarmadığı denetlenir. Eşli programlama (Pair programming) XP disiplininde, iki programcının aynı bilgisayar üzerinde kod geliştirmesidir. Bu, kodun ortak mülkiyette gelişmesini ve takım içerisinde bilgi yayılmasını sağlar. Yazılan her satır kodun birden fazla programcı tarafından izlenmesiyle, resmi olmayan bir gözden geçirme aşaması niteliği taşır. Yapılan değerlendirmelere göre eşli programlamanın sağladığı geliştirme verimliliği, iki programcının ayrı ayrı çalışmasıyla elde edilecek verim ile aynıdır. Hızlı uygulama geliştirme (RAD) Çevik metotlar çok dikkat çekmiştir, fakat uzun yıllardır hızlı uygulama geliştirme üzerine diğer yaklaşımlar kullanılmaktadır. Bunlar, veri-yoğun işletme uygulamaları geliştirmek için tasarlanmıştır ve veritabanını kullanarak programlama ve enformasyon sunumuna dayanırlar. RAD araçları Veritabanı programlama dili Ara yüz üreteci Ofis uygulamalarıyla bağlantı Rapor üreteçleri
Veri tabanı programla dili Bir RAD ortamı Ara yüz üreteci Ofis sistemleri Veri tabanı yönetim sistemi Hızlı uygulama geliştirme ortamı Rapor üreteci Ara yüz üretimi Bir çok uygulamanın temelinde kompleks formlar vardır ve bu formları manüel olarak geliştirmek çok zaman tüketen bir faaliyettir. RAD ortamları ara yüz üretimi için aşağıdaki gibi destekler içerir: Sürükle bırak teknikleri kullanarak etkileşimli form tanımlamaları; Formların gösterim sırasının belirlendiği form birleştirilmesi; Form alanlarındaki izin verilen sahalarda form doğrulamasının tanımlanması. Görsel programlama Visual Basic gibi script dilleri, standart nesnelerden kullanıcı ara yüzü oluşturulup bileşenlerin bu nesnelerle ilişkilendirilerek prototip geliştirilmesini destekler. Bu tür geliştirmeyi desteklemek için bileşenlerin büyük bir kütüphanesi yer alır. Bu kütüphaneler, spesifik uygulama gereksinimlerine uyarlanır. Yeniden kullanımlı görsel programlama Date component Range checking script Draw canvas component File Edit Views Lay out Options Help 12th January 2 000 3.8 76 Tree display component General Index Menu component User prompt component + script Görsel geliştirmedeki problemler Takıma dayalı geliştirmede koordinasyon zorluğu. Net bir sistem mimarisi yoktur. Program parçaları arasındaki kompleks bağımlılıklar bakım problemlerine yol açar. Ticari olarak kullanıma hazır malzemelerin (COTS) yeniden kullanımı Hızlı geliştirmeye bir başka etkin yaklaşım da ticari olarak kullanıma hazır sistemlerin yapılandırılması ve bağlanmasıdır. Örneğin, bir gereksinim yönetimi sistemi, Gereksinimleri depolayan bir veri tabanı; Gereksinimleri kaydetmek ve raporları biçimlendirmek için bir kelime işlemci; İzlenebilirlik yönetimi için bir çizelge programı (Excel, Lotus, ); kullanılarak gerçekleştirilmelidir.
Bileşik dokümanlar Bazı uygulamalarda bileşik dokümanlar geliştirilerek bir prototip oluşturulabilir. Bu, kullanıcının hesaplama yapmasına izin veren aktif elemanları içeren (çizelge programları gibi) bir dokümandır. Her aktif eleman, kendisi seçildiğinde çağırılan ilişkili bir uygulamaya sahiptir. Dokümanın kendisi farklı uygulamalar için toplayıcıdır (integrator). Uygulamaların bağlanması Yazılım prototiplendirme Prototip, bir sistemde fikirlerin gösterildiği ve tasarım seçeneklerinin denendiği başlangıç versiyonudur. Bir prototip; Gereksinim mühendisliği sürecinde, gereksinimlerin ortaya çıkması ve onaylanması; Tasarım sürecinde, seçeneklerin incelenmesi ve kullanıcı ara yüzü tasarımının geliştirilmesi; Test sürecinde, birbiri ardına gelen testlerin çalıştırılmasında kullanılabilir. Prototiplendirmenin yararları Sistem kulianılabilirliğinin iyileştirilmesi. Kullanıcının gerçek ihtiyaçlarının daha iyi anlaşılabilmesi. Tasarım niteliklerinin iyileştirilmesi. Bakım kolaylığının iyileştirilmesi. Geliştirme harcamalarının azaltılması. Arka arkaya test etme Verinin test edilmesi Prototiplendirme aşamaları Sistem prototipi Uygulama Prototip amaçlarının tespit edilmesi Prototip işlevselliğinin tanımlanması Prototipin geliştirilmesi Prototipin değerlendirilmesi Sonuçların karşılaş - tırılması Prototiplendirme planı Ana hatların belirlenmesi Çalıştırılabilir prototip Değerlendirme raporu Farkların raporlanması
Atılan prototipler Prototipler üretildikten sonra eğer üretim için iyi bir temel oluşturmuyorlarsa atılmalıdırlar: Sistemi fonksiyonel olmayan gereksinimleri karşılaması için ayarlamak mümkün olmayabilir; Prototipler normalde belgelendirilmezler; Prototip yapısı, hızlı değişimler boyunca genellikle indirgenir; Prototip muhtemelen kurumsal kalite standartlarını karşılamayacaktır. Önemli Noktalar Yazılım geliştirmeye iteratif bir yaklaşım yazılımın daha hızlı dağıtılmasına öncülük eder. Çevik metotlar, geliştirme masraflarını azaltmayı böylece yazılımı daha hızlı üretmeyi amaçlayan iteratif geliştirme metotlarıdır. Uç programcılık; sistematik test etme, sürekli geliştirme ve müşterinin dahil edilmesi gibi pratikler içerir. XP de test etme, kod yazılmadan önce çalıştırılabilir testler geliştirildiği için kısmi bir güçtür. Önemli Noktalar Hızlı uygulama geliştirme ortamları; veri tabanı programlama dilleri, form üretme araçları ve ofis uygulamalarına bağlantılar içerir. Atılan prototipler gerçekleştirilirken, en az anlaşılan gereksinimlerle başlanır; artırımsal geliştirmede ise en iyi anlaşılan gereksinimlerle başlanır. Yazılım Doğrulama ve Geçerleme Giriş Geliştirilecek bilgi sistemi yazılımın doğrulanması ve geçerlenmesi işlemi üretim süreci boyunca süren etkinliklerden oluşur. Bu etkinlikler; Her bir etkinlik sonunda alınan çıktıların tamam, doğru, açık ve tutarlı olduğunun doğrulanması. Her etkinlikte ürünün teknik yeterliliğinin değerlendirilmesi ve uygun çözüm elde edilene kadar aktivitelerin tekrarlanması. Geliştirilen belirtimlerin önceki belirtimlerle karşılaştırılması. Yazılım ürünlerinin tüm uygulanabilir gereklerinin sağlandığının gerçeklenmesi için sınamaların Doğrulama vs Geçerleme Doğrulama: Doğru ürünü mü üretiyoruz? Geçerleme: Ürünü doğru mu üretiyoruz? Doğrulama ürünü kullanacak kişilerin isteklerinin karşılanıp karşılanmadığını test eden etkinliklerden, Geçerleme ise ürünün içsel niteliğine ilişkin izleme ve denetim etkinliklerinden oluşur.
Sınama Kavramları Sınama ve Bütünleştirme işlemlerinin bir strateji içinde gerçekleştirilmesi, planlanması ve tekniklerinin seçilmesi gerekmektedir. Sınama işlemleri dört ana sınıfta incelenebilir: Birim sınama Alt-sistem sınama Sistem sınama Kabul sınaması Birim Sınama Bağlı oldukları diğer sistem unsurlarından tümüyle soyutlanmış olarak birimlerin doğru çalışmalarının belirlenmesi amacıyla yapılır. Alt-sistem Sınama Alt-sistemler modüllerin bütünleştirilmeleri ile ortaya çıkarlar. Yine bağımsız olarak sınamaları yapılmalıdır. Bu aşamada en çok hata arayüzlerde bulunmaktadır. Bu yüzden arayüz hatalarına doğru yoğunlaşılmalıdır. Sistem Sınaması Üst düzeyde, bileşenlerin sistem ile olan etkileşiminde çıkacak hatalar aranmaktadır. Ayrıca, belirtilen ihtiyaçların doğru yorumlandıkları da sınanmalıdır. Kabul Sınaması Çalıştırılmadan önce sistemin son sınamasıdır. Artık, yapay veriler yerine gerçek veriler kullanılır. Bu sınama türü alfa sınaması veya beta sınaması olarak ta bilinir. Alfa vs Beta Sınaması Alfa Sınamada; sistemin geliştirildiği yerde kullanıcıların gelerek katkıda bulunması sistemi test etmesi amaçlanmaktadır. Beta Sınamasında; kullanıcı, geliştirilen sistemi kendi yerleşkesinde, bir gözetmen eşliğinde yapar.
Sınama (Devam) Sınamalar, hatalardan kurtulmanın bir güvencesi değildir. Hatalardan bütünüyle arınıldığı gibi bir kanı elde edilmemelidir. Ne kadar hata sıklığına erişildiğinde sınama işlemlerinin durdurulacağına, maliyet ve kalite arasında yapılacak bir en iyileme çalışması ile ulaşılır. Yazılımın kritiklik düzeyine göre sınamaya ayrılan süre ve çaba artar. Doğrulama ve Geçerleme Yaşam Döngüsü Gerçekleştirim aşamasına kadar olan süreçlerde doğrulama ve geçerleme işlemlerinin planlaması yapılır. Planlama genellikle; 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 plan uygulanır. Sınama Yöntemleri Her yazılım Mühendisliği ürünü iki yoldan sınanır: Kara kutu testi (Black-Box testing ): Sistemin tümüne yönelik işlevlerin doğru yürütüldüğünün testidir. Sistem şartnamesinin gerekleri incelenir. Beyaz Kutu Testi (White Box testing ): İç işlemlerin belirtimlere uygun olarak yürütüldüğünün bileşenler tabanında sınanmasıdır. Kara Kutu Testi Input test data Output test results System I e O e Inputs causing anomalous behaviour Outputs which reveal the presence of defects Beyaz Kutu Testi Bütün bağımsız yolların en az bir kez sınanması gerekir. Bütün mantıksal karar noktalarında iki değişik karar için sınamalar yapılır. Bütün döngülerin sınır değerlerinde sınanması İç veri yapılarının denenmesi Beyaz Kutu Testi (2) Tests Test data Derives Component code Test outputs
Beyaz Kutu Testi (3) class BinSearch { public static void search ( int key, int [] elemarray, Result r ) { int bottom = 0 ; int top = elemarray.length - 1 ; int mid ; r.found = false ; r.index = -1 ; while ( bottom <= top ) { mid = (top + bottom) / 2 ; if (elemarray [mid] == key) { r.index = mid ; r.found = true ; return ; } // if part else { if (elemarray [mid] < key) bottom = mid + 1 ; else top = mid - 1 ; } } //while loop } // search } //BinSearch Beyaz Kutu Testi (4) 1 bottom > top 8 9 2 3 5 while bottom <= top if (elemarray [mid] == key 4 7 (if (elemarray [mid]< key 6 Beyaz Kutu Testi (5) 1, 2, 3, 8, 9 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 3, 4, 6, 7, 2, 8, 9 Test değerleri bütün bu farklı path lerin test edilmesini sağlayacak şekilde seçilmelidir. Beyaz Kutu Testi (5) Input array (T) Key (Key) Output (Found, L) 17 17 true, 1 17 0 false,?? 17, 21, 23, 29 17 true, 1 9, 16, 18, 30, 31, 41, 45 45 true, 7 17, 18, 21, 23, 29, 38, 41 23 true, 4 17, 18, 21, 23, 29, 33, 38 21 true, 3 12, 18, 21, 23, 32 23 true, 4 21, 23, 29, 33, 38 25 false,?? Sınama ve Bütünleştirme Stratejileri Genellikle Sınama Stratejisi, bütünleştirme stratejisi ile birlikte değerlendirilir. Ancak bazı sınama stratejileri bütünleştirme dışındaki hataları hedefleyebilir. Örneğin, yukarıdan-aşağı ve aşağıdanyukarıya stratejileri bütünleştirme yöntemine bağlıdır. Yukarıdan Aşağıya Bütünleştirme Yukarıdan-aşağıya bütünleştirmede önce sistemin üst düzeylerinin sınanması ve sonra aşağıya doğru olan düzeylere ilgili modülleri takılarak sınanması söz konusudur. En üst noktadaki bileşen sınandıktan sonra alt düzeye geçilmelidir. Alt bileşenler henüz hazırlanmamışlardır. Bu sebeple Koçanlar kullanılır. Koçan: Bir alt bileşenin, üst bileşen ile arayüzünü temin eden, fakat işlevsel olarak hiçbir şey yapmayan çerçeve programlardır.
Yukarıdan Aşağıya Bütünleştirme (2) İki temel Yaklaşım vardır: Yukarıdan Aşağıya Bütünleştirme (3) Testing Level 1 Level 1 sequence... Düzey Öncelikli Bütünleştirme: En üst düzeyden başlanır ve aynı düzeydeki birimler bütünleştirilir. Derinlik Öncelikli Bütünleştirme: En üst düzeyden başlanır ve her dal soldan sağa olmak üzere ele alınır. Örnek Şekil 7.6 Level 2 stubs Level 3 stubs Level 2 Level 2 Level 2 Level 2 Aşağıdan Yukarıya Bütünleştirme Aşağıdan Yukarıya Bütünleştirme (2) Önceki yöntemin tersine uygulama yapılır. Önce en alt düzeydeki işçi birimler sınanır ve bir üst düzey ile sınanması gerektiğinde bu düzey bir sürücü ile temsil edilir. Bu kez kodlama, bütünleştirme ve sınama, aşağı düzeylerden yukarı düzeylere doğru gelişir. Test drivers Test drivers Level N Level N 1 Level N Level N Level N Level N Level N 1 Level N 1 Testing sequence Yaşam Döngüsü Boyunca Sınama Sistem Sınama Planı Altsistem Sınama planları Modül Sınama Planı Sınama Belirtimleri Sınama Eğitim Klavuzu Modül Sınama Bütünleştirici Sınama Sınayıcı Eğitim Kullanıcı Sınaması Sınama Raporları P Ç T G K P: Planlama Ç: Çözümleme T: Tasarım G: Gerçekleştirim K:Kurulum