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 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’.

Small Releases The minimal useful set of functionality that provides business

value is developed first. Releases of the system are frequen t and

incrementally add functionality to the first release.

Simple Design Enough de sign is carried out to meet the cu rrent requirements

and no more.

Test first development An automated unit test framework is used to write tests for a new

piece of functionality before that functionality itself is

implemented.

Refactoring 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 Developers work in pairs, checking ea ch other’s work and

providing the support to always do a good job.

Collective Ownership 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.

Continuous Integration 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.

Sustainable pace Large amounts of over-time are not considered acceptable as the

net effect is often to reduce code qua lity and medium term

productivity

On-site Customer 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. Youthen have to tell the system how you will pay for it - this can eitherbe through a subscription, through a company account or by creditcard.

After this, you get a copyright form from the system to fill in and,when you have submitted this, the article you want is downloadedonto your computer.

You then choose a printer and a copy of the article is printed. Youtell the system if printing has been successful.

If the article is a print-only article, you can’t keep the PDF versionso 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ı

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 durumu tanımlaması

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

Bir RAD ortamı

Veri tabanı programla

dili

Ara yüz üreteci

Ofis sistemleri

Rapor üreteci

Veri tabanı yönetim sistemi

Hızlı uygulama geliştirme ortamı

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

File Edit Views Layout Options Help

General

Index

Menu componentDate component

Range checking

script

Tree display

component

Draw canvas

component

User prompt

component +

script

12th January 2 000

3.8 76

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

Sonuçların

karşılaş -tırılması

Sistem

prototipi

Uygulama

Farkların

raporlanması

Prototiplendirme aşamaları

Prototip

amaçlarının tespit edilmesi

Prototip işlevselliğinin

tanımlanması

Prototipin geliştirilmesi

Prototipin değerlen-

dirilmesi

Prototiplen- dirme planı

Ana hatların belirlenmesi

Çalıştırılabilir prototip

Değerlendirme

raporu

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

I

e

Input test data

OeOutput test results

System

Inputs causinganomalousbehaviour

Outputs which revealthe presence ofdefects

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)

Componentcode

Testoutputs

Test data

DerivesTests

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

2

3

4

65

7

while bottom <= top

if (elemArray [mid] == key

(if (elemArray [mid]< key8

9

bottom > top

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ğıdan-yukarı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:

– 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

Yukarıdan Aşağıya Bütünleştirme (3)

Level 2Level 2Level 2Level 2

Level 1 Level 1Testing

sequence

Level 2stubs

Level 3stubs

. . .

Aşağıdan Yukarıya Bütünleştirme

• Ö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.

Aşağıdan Yukarıya Bütünleştirme (2)

Level NLevel NLevel NLevel NLevel N

Level N–1 Level N–1Level N–1

Testingsequence

Testdrivers

Testdrivers

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