ÖZELLİK GÜDÜMLÜ PROGRAMLAMA ( FEATURE DRIVEN PROGRAMMING )

ÖZELLİK GÜDÜMLÜ PROGRAMLAMA ( FEATURE DRIVEN PROGRAMMING ) Hazırlayan: 20122196 Melih KANDEMİR Hacettepe Üniversitesi Bilgisayar Mühendisliği Bölümü IV.Sınıf Öğrencisi İçerik 1.Çevik Programlama Paradigması 2.Çeviklik İlkeleri 3.Çevik Programlama Ekibi Bireylerinde Bulunması Gereken Nitelikler Nelerdir? 4.Çevik Programlama Modelleri 5.Bir Çevik Programlama Modeli Örneği: Özellik Güdümlü Programlama 5.1 Roller 5.2 Süreçler 5.2.1 Süreç #1: Genel Sistem Modelini Geliştir. 5.2.2 Süreç #2: Özellik Listesi Oluştur 5.2.3 Süreç #3: Özellik Güdümlü Planla 5.2.4 Süreç #4: Özellik Güdümlü Tasarla 5.2.5 Süreç #5: Özellik Güdümlü Geliştir 5.3 İlerlemenin Takibi ve Zaman Yönetimi Açısından Özellik Güdümlü Programlama 6.Sonuç 7.Kaynakça 1.Çevik Programlama Paradigması( Agile Programming Paradigm ) 2001 yılında, Kent Beck önderliğinde, bir grup bilişimci, Çevik Yazılım Yaklaşımı Manifestosu nu imzaladılar. Bu bildirgede; Bireylerin ve etkileşimlerinin, süreçler ve araçlara; Çalışan yazılımın, kapsamlı belgelemeye; Müşteriyle işbirliğinin, sözleşmeye dayalı görüşmelere; Değişime cevap vermenin, bir planı takip etmeye

göre daha değerli olduğunu dile getirdiler. Bu bildirge aracılığıyla, çevik programlama paradigması, zaten geçtiğimiz onyıldan bu yana yazılım mühendisliğinin ilgilendiği ve çözmeye çalıştığı sorunları içermesine rağmen, bir hareket olarak kendini gösterdi. Bu yeni paradigma, geleneksel yazılım mühendisliği yaklaşımının uygulamadaki zayıflıklarını açıkça dile getirmekte ve yeni yöntemler ortaya atmaktadır. 2.Çeviklik İlkeleri( Agility Principles ) Çevik programlamacılar, çevikliğin elde edilebilmesi için uyulması gereken 12 ilke öne sürdüler.bu ilkeler: 1) Birincil öncelik, müşteriyi, sık ve devamlı olarak işe yarar yazılım sürümleriyle destekleyerek tatmin etmektir. 2) Değişen gereksinimler, geliştirme sürecinin ileri evrelerinde ortaya çıksa bile, müşterinin rekabet gücünü artırmak için kullanılarak bir avantaja dönüştürülmelidir. 3) Birkaç haftadan birkaç aya kadar değişen zaman aralıklarıyla, yazılımın çalışan sürümleri kullanıcıya sunulmalıdır. 4) Alan uzmanlarıyla( Domain experts ) yazılım geliştiriciler, proje boyunca birlikte çalışmalıdır. 5) Bireyler cesaretlendirilmeli, ve proje bireylere dağıtılmalıdır. Ortam onlara devredilmeli, ihtiyaçları giderilmeye çalı- Şılmalı ve onlara güvenilmelidir. 6) Geliştirme takımı içinde en etkin ve en etkili bilgi aktarma yolu yüzyüze iletişimdir. 7) İlerlemenin birincil ölçütü çalışan bir yazılım sürümüdür. 8) Çevik programlama süreçleri, sürdürülebilirliği destekler. Sponsorlar, geliştiriciler ve kullanıcılar sabit bir süreç hızını beraberce benimsemeli ve sürdürmelidir. 9) Teknik yetkinliğe(excellence) sürekli özen gösterilmesi ve iyi tasarım, çevikliğe gereksinim duyar. 10) Yalınlık(simplicity) yapılmasına gerek kalmayan iş miktarını maksimize etme sanatı - esastır. 11) En iyi mimariler, gereksinimler ve tasarımlar, kendi içinde organize olan takımlardan çıkar. 12) Takım, belirli aralıklarla, daha etkin nasıl olunabileceğini kararlaştırarak gerekli iç ve dış uyumu kendi kendine sağlar. Çevik programlama, geleneksel yazılım mühendisliği yaklaşımına bir karşı iddia olarak ortaya çıkmış gibi gözükmektedir. Teorik açıdan bu doğrudur, yani yazılım mühendisliği ve çevik programlama yaklaşımları, birbirine zıt varsayımlar üzerine kurulmuştur.

Ancak uygulamada böyle bir zıtlıktan söz edilemez. Tersine, bu iki yaklaşım, birbirinin tamamlayıcısı olarak kullanılmaktadır. Yapılması önerilen, projenin ve yazılım ekibinin niteliklerine uygun, çevik bir yazılım mühendisliği süreci tanımlamak ve uygulamaktır. Bu, yazılım mühendisliği ve çevik programlama arasında bir arayol bulunarak gerçekleştirilmelidir. Çevik Programlama Geleneksel Yazılım Mühendisliği Yazılım mühendisliğinin çok temel ilkelerinden vazgeçilip, çevik programlama yaklaşımının uygulanmasına karar verilirken, söz konusu projenin kapsamının aşağıda bahsedilen nitelikleri taşıdığından emin olunmalıdır: a) Yazılım gereksinimlerinde hangi ölçüde ve ne gibi değişiklikler olabileceğini, ve müşterinin önceliklerini önceden kestirmek açıkça olanaksız olmalı. b) Tasarım ve gerçekleştirim evrelerinin birarada ya da iç içe zamanlarda yürütülmesi gerekmeli. Ne ölçüde ve genel hatlarıyla nasıl bir tasarım gerekeceğini, gerçekleştirim yapılarak emin olmaksızın kestirmek çok güç olmalı. c) Çözümleme, tasarım, gerçekleştirim ve test aşamalarının zaman planlamasını yapmak açıkça çok güç olmalı. d) Yazılım ekibinde, 4.bölümde bahsedilen nitelikler bulunmalı. Peki, kestirilemezliği(unpredictability) yönetebileceğimiz bir süreç nasıl mümkün olabilir? Anahtar kelime uyarlanabilirlik tir(adaptability). Uyarlanabilir süreçler tanımlanmalıdır. Uyarlanabilirlik ise, artırımsal (incremental) sürümler aracılığıyla, müşteri geri bildiriminden en iyi şekilde yararlanarak sağlanabilir. 3.Çevik Programlama Ekibi Bireylerinde Bulunması Gereken Nitelikler Nelerdir? 1) Ekip elemanları ortalama bir analitik ve teknik nitelik ve bilgi düzeyine sahip olmalı.( COMPETENCE ) 2) Ekibin, birbirinden farklı ögrevleri olan bireylerinin hepsi, aynı amaca odaklanmış olmalıdır.( COMMON FOCUS ) 3) Ekibin elemanları, birbirleriyle, müşteriyle ve alan uzmanlarıyla işbirliği içinde olmalıdır.( COLLABORATION ) 4) Ekip, koşulları göz önünde bulundurarak karar verebilme yeteneğine sahip olmalı( DECISION-MAKING ABILITY ) 5) Ekip, belirsizlik ve kestirilemezlik altında sorun çözebilme yeteneğine sahip olmalı( FUZZY PROBLEM-SOLVING ABILITY ) 6) Ekip elemanları, karşılıklı güven ve saygıya dayalı iletişim içinde olmalı( MUTUAL TRUST AND RESPECT ) 7) Ekip, kendi kendini, yapılacak iş için, zaman ve kaynak kısıtlarını gözönünde bulundurarak organize edebilmeli( SELF-ORGANIZATION )

4.Çevik Süreç Modelleri( Agile Process Models ) Çevik programlamanın gerçekleştirilebilmesi için, daha önce denenmiş ve başarıyla sonuçlanmış bazı süreç modelleri mevcuttur. Bu modellerin hepsi, çevik programlama paradigmasıyla ortaya çıkmış, ancak farklı ortamlarda ortaya çıkmış farklı gereksinimler sonucu bir noktadan sonra özelleşmiştir. Bu belgede, bu süreç modellerinden bir tanesi ayrıntılı olarak tanımlanıp açıklanacak, diğerlerinin başlıkları verilmekle yetinilecektir. 1) Sınırsal Programlama( Extreme Programming - XP ) 2) Uyarlamaya Dayalı Yazılım Geliştirme( Adaptive Software Development ASD ) 3) Devingen Sistem Geliştirme Yöntemi( Dynamic Systems Development Method DSDM ) 4) Scrum 5) Crystal 6) Özellik Güdümlü Programlama( Feature Driven Programming ) 5. Bir Çevik Süreç Modeli Örneği: Özellik Güdümlü Programlama Özellik güdümlü programlama; planlama, öncelik belirleme, tasarlama ve geliştirme süreçlerini, özellik (feature) adı verilen, müşteri için bir anlam ifade eden küçük, işlevsel gereksinim parçacıkları taban alınarak gerçekleştirme yaklaşımıdır. Artırımsal değil, devingen olan süreç, özellik lerin gerçekleştiriminin müşteri tarafından değerlendirilmesi aracılığıyla, artırıma gerek kalmadan, küçük yinelemelerle geri bildirim almayı amaçlamaktadır. Bir projeyi 150 civarında özelliğe bölerek, değişimleri, özellik kapsamına sıkıştırarak yan etkilerinden kurtulmak hedef alınmaktadır. 5.1 Roller Eşgüdümün ve yönetimin sağlanması için, işbölümü gereklidir. Özellik güdümlü programlamada işbölümünün nasıl sağlanması gerektiği, roller bağlamında ele alınmıştır. Proje Yöneticisi( Project Manager ) Yazılım projesinin yürütülmesi, ve başarıyla sonuca ulaşmasına yönelik tüm tedbirleri almaktan sorumludur. Özellik güdümlü programlama bağlamında, özellik ve modelleme takımlarını oluşturma gibi görevleri vardır. Baş Programcı( Chief Programmer ) Özellik güdümlü tasarlama(ögt) ve özellik güdümlü gerçekleştirim(ögg) aşamalarını yöneten, özelliklerin bir altkümesinin gerçekleştirimini,adım adım takip

eden, denetleyen ve kendi sorumluluğundaki sınıf sahiplerine gerekli olduğunda akıl hocalığı(mentoring) yapan kişidir. Belli sayıda sınıf sahibinden oluşan ekibiyle birlikte yerine getirmekle yükümlü olduğu bir özellikler listesi vardır. Kendisine de aynı zamanda, birkaç sınıfın sahibi durumundadır. Projenin gerçekleştirim hızı, baş programcı sayısıyla,bir dereceye kadar doğru orantılıdır. Zaman kısıtı söz konusu olduğunda, baş programcı sayısını artırma yoluna gidilmelidir.baş programcılar seçilirken, daha yetenekli, bilgili ve tecrübeli geliştiricilerin seçilmesine dikkat edilmelidir. Sınıf Sahibi( Class Owner ) Sınıf sahibi, bir sınıfın tasarımı ve gerçekleştiriminden sorumlu olan geliştiricidir.burda amaç, geliştiricinin, sınıfın tamamen kendine ait olduğunu hissetmesi sayesinde motivasyonu artırmaktır. Bu çeşit bir organizasyonun bir başka yararı da, bir kod parçasına dokunan sadece bir kişinin olmasıdır. Bu, bakımı kolaylaştırmaktadır. Özellik güdümlü programlamada her sınıf, tek bir geliştiriciye aittir.ancak bir geliştirici, birden fazla sınıfın sahibi durumundadır. Algoritmik açıdan zorluk ve karmaşıklık düzeyi yüksek sınıfları için, sınıf sahibinin yanına bir de algoritma tasarımcısı atanabilir. Alan Uzmanları( Domain Experts ) Müşteri kuruluşun dahil olduğu alanın uzman kişileridir. Müşteri kuruluşun personelidirler, ve söz konusu proje için ilgili yazılım şirketiyle birlikte çalışmak üzere görevlendirilmişlerdir. Özellik Takımları Baş programcı, kendisini bir özellikler kümesi atandıktan sonra, bu özellikleri bir ya da iki haftada gerçekleştirebileceği bir özellik takımı kurar. Bu takım, yukarıda sözü edildiği gibi, sınıf sahiplerinden oluşur. Sınıf sahipleri, aynı anda birden fazla özellik takımına dahil olabilirler. Örneğin, bir geliştiricinin sorumluluğunda üç tane sınıf varsa, bu sınıflardan iki tanesi bir özellik takımına, kalan bir tanesi ise başka bir özellik takımına ait olabilir. Aşağıda bu durumu açıklayan bir çizim bulunmaktadır:

Yineleme 1 Yineleme 2 Çizim 5.1 Özellik takımı üyeliği her yinelemede değişebilir. 5.2 Süreçler Özellik güdümlü programlama süreci, beş temel alt süreçten oluşur. Birinci süreçte, oluşturulacak yazılım sisteminin biçimsel olmayan genel bir modeli çıkartılır. İkinci süreçte, bu modelden yararlanarak, alan uzmanlarının da yardımıyla özellikler listesioluşturulur. Üçüncü süreçte proje yöneticisi, özellik tabanında planlama yapar. Bu planlama, hangi baş programcının ekibi tarafından, hangi özelliğin hangi tarihe kadar gerçekleştirileceğini kapsar.bu andan itibaren özellik takımları söz konusudur. Dördüncü ve beşinci süreçler yinelemeli süreçlerdir. Baş programcı sorumluluğunda, özellikler bir bir gerçekleştirilir ve müşteriye sunulur. Müşteriden alınan geri bildirime göre yeni özellikler ortaya çıkar, değişikliklere göre yeniden özellik takımları oluşturularak dördüncü ve beşinci süreçler yinelenir. 5.2.1 Süreç #1: Genel Sistem Modelini Geliştir BAŞLAMA ÖLÇÜTÜ Alan uzmanları, baş programcılar ve proje yöneticisi belirlenmiş olmalıdır. GÖREVLER 1.1 Modelleme takımı nın oluşturulması. (Zorunlu) Aktörler : Proje yöneticisi Modelleme takımı, alan uzmanları ve geliştiricilerden oluşan sürekli elemanlardan meydana gelir.bu takım, proje yöneticisi tarafından belirlenir. Bu takımın görevi genel sistem modelini oluşturmaktır.bu model, alan uzmanlarının anlayabileceği, yani teknolojik tanım ve belirtimler içermeyen bir tanım olmalıdır. Herhangi bir modelleme dilinden yararlanılarak oluşturulabilir( UML, Data Flow Charts vs...) Modelleme takımına seçilmemiş, projede görevli diğer personelin de, modelleme takımının oturumlarına döngüsel biçimde katılması sayesinde herkesin süreci yapıldığı anda görmesi ve sürecin her anında öneri sunabilmesi sağlanır. 1.2 Proje ekibinin alana genel bir bakış(domain walkthrough) kazanmasının sağlanması. (Zorunlu) Aktörler: Modelleme takımı Bir alan uzmanı, modellemenin yapılacağı alan hakkında, tüm modelleme takımına genel bir bilgi verir. 1.3 Belgelerin incelenmesi. (İsteğe Bağlı) Aktörler: Modelleme takımı Modelleme takımı, kaynak ya da gereksinim belgelerini inceler.bu belgeler, nesne modelleri, işlevsel gereksinimler,veri modelleri, ya da

kullanım kılavuzları olabilir. 1.4 Modelin geliştirilmesi. (Zorunlu) Aktörler: Modelleme takımının elemanlarından oluşan küçük gruplar Üçten az kişiden oluşan küçük gruplar oluşturulur. Üç kişiden birisi alan uzmanı olmalıdır. Bu grupların her birisi, kendi sistem modelini çıkarır. Proje yöneticisinin kendisi de bir model önerebilir. Grupların tümü modellemeyi tamamladığında, grupların herbirinin bir elemanı, kendi modelinin sunumunu yapar. Modelleme takımı önerilen modellerden birisini seçer ya da modellerden birkaçındaki fikirleri birleştirerek yeni bir model tasarlar. 1.5 Genel nesne modelinin güncellenmesi.(zorunlu) Aktörler: Proje yöneticisi ve modelleme takımı. Genel nesne modelinin, her yinelemede, 4.adımda izlenen yöntem tekrarlanarak günlenmesi gereklidir. 1.6 Model notlarının yazılması.( Zorunlu ) Aktörler: Proje yöneticisi ve baş programcılar. Ayrıntılı ve karmaşık model şekilleri ve önemli model alternatifleri hakkında, ileride belge olarak kullanılmak üzere ayrıntılı açıklamalar yazılır. DOĞRULAMA( Verification ) 1.7 İç ve dış onayın(internal & External Assessment) alınması.( Zorunlu ) Aktörler: Modelleme takımı ve müşteri İç onay, alan uzmanlarının aktif katılımıyla gerçekleşir.uzmanların modelin gereksinimleri karşıladığını onaylamasına denir. Dış onay ise sadece gerekli durumlarda, müşteriyle görüşerek alınır. ÇIKIŞ KOŞULLARI Bu sürecin sonunda bir Nesne Modeli ortaya çıkmış olmalıdır. Sınıf çizenekleri( Class Diagrams ) Sınıfların davranış ve özellikleri Ardıl işlem çizenekleri.(sequence Diagram) Model notları hazırlanmış olmalıdır. 5.2.2 Süreç #2: Özellik Listesi Oluştur BAŞLAMA ÖLÇÜTÜ Alan uzmanları, baş programcılar ve proje yöneticisi. GÖREVLER 2.1 Özellikler Listesi Takımı nın oluşturulması. ( Zorunlu ) Aktörler: Proje yöneticisi Proje yöneticisi, modelleme takımı ndaki baş programcılardan oluşan bir özellikler listesi takımı seçer.

2.2 Özellikler Listesi oluştur. ( Zorunlu ) Aktörler: Proje yöneticisi, Özellik listesi takımı Özellikler listesi takımı, süreç #1 de elde edilen bilgileri kullanırak bir özellikler kümesi tanımlar. İşe, alan uzmanlarının, alanı temel konulara bölmeleriyle başlanır. Bu bölümlemeden yararlanılarak sistemin, basit işlevsel bölümlemesi yapılır. Bu bölümlerin her birisi, bir iş aktiviteleri (Business Activities) kümesinden oluşur. Her iş aktivitesi ise, bir dizi basamak (step) olarak tanımlanır. Bu basamakların her birisine özellik ( feature ) denir. Özellikler, aşağıdaki şablon kullanılarak tanımlanır: ÖZELLİK := <sonuç> <nesne><eylem> Örneğin, Toplam satış hesapla. Burada <sonuç> = toplam, <nesne> = satış ve <eylem> = hesapla dır. Her bir özellik, bir iş aktivitesi basamağına karşılık gelir. Her bir iş aktivitesine karşılık ise bir Özellik Kümesi (feature set) tanımlanır. ÖZELLİK KÜMESİ := <nesne><eylem>-mek(-mak) Örneğin; Satış yapmak. <nesne> = satış, <eylem>= yapmak. Her bir temel konuya karşılık ise, ana özellik kümesi tanımlanır.(major feature set). ANA ÖZELLİK KÜMESİ := <nesne> yönetimi. Örneğin; Satış yönetimi ibaresi, bir ana özellik kümesine karşılık gelmektedir. Alan uzmanlarıyla geliştirme ekibi arasındaki iletişim, işte bu biçimsel sözel ifadeler aracılığıyla sağlanır. Özellik listesi takımında yer alan bir alan uzmanı bir iş aktivitesinden bahsederken, baş programcılardan birisi hemen, bu ifadenin özellik kümesi olarak biçimsel karşılığını yazar. Böylece bir özellik listesi oluşturulur. Bundan sonraki süreçlerin işleyişi, bu özellikler üzerinden planlanacak ve denetlenecektir. DOĞRULAMA( Verification ) 2.3 İç ve dış onayın(internal & External Assessment) alınması.( Zorunlu ) Aktörler: Özellik listesi takımı ve müşteri Süreç#1 dekiyle aynı biçimde yürütülür. ÇIKIŞ KOŞULLARI Sürecin sonucu bir Özellikler Listesi dir. Bir temel konular listesi Her temel konu için bir iş aktiviteleri listesi Her iş aktivitesi adımı için, ilişkili bir özellik. 5.2.3 Süreç #3: Özellik Güdümlü Planla BAŞLAMA ÖLÇÜTÜ Süreç #2 tamamlanmış olmalıdır. GÖREVLER 3.1 Planlama Takımı oluşturulur.(zorunlu) Aktörler: Proje yöneticisi Planlama takımı, proje yöneticisi ve baş programcılardan oluşur.

3.2 Geliştirme sürecinin akışını belirlenir. ( Zorunlu ) Aktörler: Planlama takımı Planlama takımı, her iş aktivitesi için bir bitiş tarihi belirler.( sadece yıl ve ay olarak ). Bu tarih belirlenirken, sınıf sahipleri arasında yük dengeleme, gerçekleştirilecek özelliklerin karmaşıklığı gibi ölçütler gözününde bulundurulmalıdır. 3.3 Baş programcılara iş aktiviteleri atanır.( Zorunlu ) Aktörler: Planlama takımı Planlama takımı, her baş programcıyı bir iş aktivitesinin sorumlusu olarak atar. Atama yapılırken aşağıdakilere dikkat edilmelidir: Geliştirme akışı( Development sequence ) İlgili sınıfların özellikleri arasındaki bağımlılıklar. Sınıf sahipleri arasında yük dengeleme Gerçekleştirilecek özelliklerin karmaşıklığı. 3.4 Geliştiricilere sınıf ataması yapılır. ( Zorunlu ) Aktörler: Planlama takımı Planlama takımı, geliştiricilere sınıf ataması yapar. Bir geliştirici birden fazla sınıfın sahibi olabilir. Atama yapılrken aşağıdakilere dikkat edilmelidir: Geliştiriciler arasında yük dengeleme Sınıfların karmaşıklığı Sınıfların kullanım oranı Geliştirme akışı DOĞRULAMA 3.5 İç onayın alınması.(zorunlu) Aktörler: Planlama takımı Planlama, bir takım çalışması olarak yapıldığından, iç onay, proje yöneticisi ve baş programcıların katılımıyla verilen bir karardır. ÇIKIŞ KOŞULLARI Bu sürecin sonunda, aşağıdakileri içeren bir Geliştirme Planı ortaya çıkarılır: Bitiş tarihleriyle birlikte iş aktiviteleri.( ay ve yıl ) Baş programcı-iş aktivitesi atamaları. Temel konular ve bitiş tarihleri. Sınıf-geliştirici ataması. 5.2.4 Süreç #4: Özellik Güdümlü Tasarla BAŞLAMA ÖLÇÜTÜ Süreç #3 tamamlanmış olmalıdır. GÖREVLER 4.1 Özellik Takımı oluşturulması. ( Required ) Aktörler: Baş Programcı

Baş Programcı, genel sistem modelini kullanarak, kendisine atanmış özellikler kümesinin ilişkili olduğu sınıfların listesini çıkarır. Sınıf sahipliği listesinden yararlanarak da, bu sınıfların sahibi olan geliştiricileri tespit eder. Bu geliştiriciler topluluğu ve baş programcı, bir özellikler altkümesinin gerçekleştirilmesi için birlikte çalışacak olan bir özellik takımı oluşturmuş olurlar. 4.2 Proje ekibinin alana genel bir bakış(domain walkthrough) kazanmasının sağlanması. (İsteğe Bağlı) Aktörler: Alan uzmanları Bir alan uzmanı, modellemenin yapılacağı alan hakkında, tüm modelleme takımına genel bir bilgi verir. 4.3 Kaynak belgelerin incelenmesi. ( İsteğe Bağlı ) Aktörler: Özellik Takımı Özellik takımı, tasarlanacak olan özellikle ilgili kaynak gösterilen belgeleri,grafiksel arayüz tasarımları gibi yardımcı dokümanları inceler. 4.4 Ardıl işlem çizeneklerinin oluşturulması. ( Zorunlu ) Aktörler: Planlama Takımı Tasarlanacak özellik için gerekli ardıl işlem çizenekleri oluşturulur. 4.5 Nesne modelinin geliştirilmesi.(zorunlu) Aktörler: Baş Programcı Baş Programcı, özelliklerin tasarımı sırasında nesne modelinin günlenmesine ihtiyaç duyabilir. 4.6 Sınıfların ve metod prototiplerinin oluşturulması. ( Zorunlu ) Aktörler: Özellik Takımı Özellik tasarımı sonucu oluşturulması kararlaştırılan sınıflar ve bu sınıfların metodlarını prototipleri, sınıf sahiplerince belirlenir. Bu belirtimler metoddan dönen değer türleri, parametre türleri, aykırı durumlar ve görüntülecek uyarı iletilerini içermelidir. Her geliştirici kendi sınıflarının tasarımını yapmayı tamamladıktan sonra baş programcı bu bilgileri birleştirerek bir API dokümantasyonu hazırlar ve tasarım aşamasının bir yinelemesi(iteration) tamamlanmış olur. DOĞRULAMA 4.7 Tasarımın Denetlenmesi.(Zorunlu) Aktörler: Özellik Takımı Bir özellik takımınca yapılan tasarım, aynı takımın tüm elemanlarının katılımıyla kendi kendine, ya da başka özellik takımından çağrılan elemanlarca denetlenir. Denetlemeye karar verme yetkisi bir özellik takımının baş programcısındadır. Tasarımın kabulu halinde, etkilenen her sınıf için bir yapılacaklar listesi( to-do list ) hazırlanır. Her takım elemanı kendi işlerini, bu listeye tarihleriyle birlikte yazarak planlar.

ÇIKIŞ KOŞULLARI Bu sürecin sonucu olarak ortaya başarılı bir Tasarım Paketi çıkması istenir. Bu tasarım paketi aşağıdakileri içermelidir: Tasarım paketinin genel bir açıklamasını sunan genel kapsamlı kısa bir belge. Ardıl işlem çizenekleri Belirlenen tasarım alternatifleri Nesne modelinin günlenmiş şekli Her sınıf için yapılacaklar listesi Paket geliştirilirken kaynak olarak kullanılan dokümanların listesi 5.2.5 Süreç #5: Özellik Güdümlü Geliştir BAŞLAMA ÖLÇÜTÜ Süreç #4 tamamlanmış olmalıdır. Yani, tasarım paketi denetlemeden onay almış olmalıdır. GÖREVLER 5.1 Sınıfların ve metodların kodlanması.( Zorunlu ) Aktörler: Özellik Takımı Sınıf sahibi geliştiriciler kendi sınıflarını, tanımlanan gereksinimleri karşılayacak biçimde kodlarlar. 5.2 Kod Denetimi.(Zorunlu) Aktörler: Özellik Takımı Kod denetimi, özellik takımı üyeleri ya da diğer proje elemanları tarafından, birim testinden( unit test ) önce ya da sonra yapılır. Kod denetiminin yapılış biçimi ve zamanı konusundaki kararları Baş Programcı verir. 5.3 Birim Testi.(Zorunlu) Aktörler: Özellik Takımı Bir sınıf sahibi geliştiricinin, yazdığı kodun, kendi sınıfının karşılaması gereken tüm gereksinimleri karşıladığını test etmesine birim testi denir. Özellik Takımı seviyesinde birim testi yapılmasına ise Baş Programcı karar verir. 5.4 Paketin yapılandırılmasına geçilmesi( Promote to build ). ( Zorunlu ) Aktörler: Baş Programcı, Özellik Takımı Baş Programcı bütün sınıf kodlarını alır ve bir paket oluşturacak şekilde yapılandırır.(building). DOĞRULAMA 5.5 Kod Denetimi ve Birim Testi.(Zorunlu) Aktörler: Baş Programcı,Özellik Takımı Kod denetimi ve birim testinin olumlu çıkması, bu sürecin çıktısını doğrular. ÇIKIŞ KOŞULLARI Bu sürecin çıktısı, aşağıdakilerdir: Kod denetiminden başarıyla geçmiş sınıflar ve metodlar.

Yapılandırılmış sınıflar.( Bütün sınıfların yapılandırılması.örneğin, bir makefile kütüğü. ) Özelliğin gerçekleştiriminin tamamlanması. 6.3 İlerlemenin Takibi ve Zaman Yönetimi Açısından Özellik Güdümlü Programlama Yukarıda, özellik güdümlü programlamayla proje gerçekleştirmek için izlenmesi gereken basamaklara değinilmiştir. Peki bu basamaklardan hangisi üzerinde ortalama ne kadar vakit harcanacaktır? Zaman, yazılım geliştirme sürecinde, anlamlı tek maliyet olduğundan, projenin durumunun izlenebilirliği de ayrı bir yazılım mühendisliği problemidir. Bir yazılım geliştirme modeline güvenilebilmesi için, zaman yönetimini ve izlenebilirliği, kendi paradigmasına uygun şekilde desteklemelidir. Bu bölümde, özellik güdümlü programlamanın, zaman yönetimi ve projenin durum izlenebilirliği bağlamında sunduğu önerilere değineceğiz. Aşağıda, özellik güdümlü programlamanın, amacına ulaşması,yani anlamlı olması için her süreçte ortalama harcanması gereken zaman, projenin gerçekleştirilmesi için gerekli toplam zamanın yüzdeleri olarak verilmiştir. Yukarıdaki şekle göre, özellik güdümlü programlama yaklaşımının getirdiği yük, 33% kadar zaman almaktadır. Yani projenin tasarım ve gerçekleştirimi dışında, özellik güdümlü organizasyon için harcanan zaman bu kadardır. Bu, diğer modellere göre çok düşük bir yüzdedir. Bunun anlamı, özellik güdümlü programlama, tasarım ve gerçekleştirime çok daha fazla zaman bırakmayı amaçlamaktadır. Tasarım ve gerçekleştirim evreleri evrimseldir. Bu evrimsellik, özellik güdümlü programlamaya, projenin gerçekleştirimi sırasında değişen kullanıcı gereksinimlerine kolay uyum sağlama yeteneği kazandırır. Özellik güdümlü programlamada her iki haftada bir yeni bir evrimsel yinelemeye başlanır. Yani değişen dış şartlara uyum sağlama süresi, özellik güdümlü programlamayla ortalama iki haftadır.aşağıda, tasarım ve gerçekleştirim evrelerinin alt evreleri ve bu alt evrelerin zaman ağırlıklarını gösteren bir çizenek sunulmaktadır:

Şimdi, özellik güdümlü programlamada ilerlemenin nasıl takip edildiğini göreceğiz. Aşağıda bir özellik takip formu bulunmaktadır.bu formda amaç zaman yönetimidir. Her özelliğin, hangi tarihte sürecin hangi alt evresinde olması gerektiği ve şu an ne durumda olunduğu bilgisini taşımaktadır. Bu sayede, proje personeli, zaman planlaması yapabilir ve projenin zaman planlaması açısından şu an ne durumda olduğunu genel hatlarıyla görebilir. Şekildeki ikinci form, özellik kümesi ve ana özellik kümesi takip formudur. Bu form, özellik kümesi düzeyi zaman planlaması ve mevcut durumun incelenmesi içindir,yani işlevsel olarak yukarıdakiyle aynı, sadece ölçekçe farklıdır.

Aşağıdaki renkli grafikler, mevcut durumun etkin biçimde izlenebilmesini sağlamaktadır. Bu grafikler yardımıyla, hangi özelliğin gerçekleştiriminde hangi durumda bulunulduğu, planlanan zamanın önünde,gerisinde ya da çok gerisinde bulunulduğu gibi bilgiler rahatlıkla algılanabilmektedir. Örneğin, planlanandan çok geri durumdaki özellikler kırmızı ile gösterilmekte, böylece yöneticiler, özelliklerin kritik durumda bulunanlarını kolaylıkla tespit edip etkin ve etkili risk yönetimi yapabilmektedirler. Bu grafikler, genelde, mevcut durumla ilgili verilerin tutulduğu bir veri tabanı yardımıyla günlenmektedir. Bu raporlama sisteminin etkin kullanılması için modellemesinin ve otomasyonunun yapılması önemlidir. Günümüzde, özellik güdümlü programlama sürecine destek sağlayan dağıtık yazılımlar mevcuttur.

7.Sonuç Yazılım sektöründe gereksinimler ve teknoloji, çok hızlı ve birbirine paralel değişen iki boyutu simgelemektedir. Bu başdöndürücü hız, gelişen teknolojinin herhangi bir anında iş çözümü üretme kararı alan ve uzun vadeli projeler teslim alan yazılım girişimleri için önemli bir sorundur. Çünkü, bir yazılımın geliştirilmesi tamamlandığında, yazılımın üzerinde çalışmak üzere tasarlandığı donanım mimarisi eskimek üzere olabilmektedir. Bundan öte, geliştirme sürecinin ileri bir safhasında sektör, geliştirmeye başlamadan öncekinden çok farklı bir durumda bulunmaktadır. Günümüzde ortalama bilişim sistemi projesi bitirme süresinin 1 yıl mertebesinde olması, işlerin yolunda gitmediğinin göstergesinin. Yazılım projelerinin yavaş yürümesinin temelinde, klasik yazılım mühendisliği yaklaşımının önerdiği mükemmel raporlamanın gerçekleştirimi

kolaylaştırdığı varsayımının doğru sanılmasının olduğunu düşünen bir grup, çevik programlama adı verilen yeni bir iş süreci modelleme paradigması ortaya attılar. Özellik güdümlü programlama da, bu paradigmanın bir alt alanıdır. Çevik programlama paradigmasının sunduğu değişik modellerden herhangi birisinin diğerine üstünlüğü, deneyimle görülmüş değildir. Özellik güdümlü programlama, hızlı bir yazılım geliştirme süreci vaadeden, diğerlerine karşı bazı durumlarda üstün olup bazı durumlarda zayıf düşen alternatif bir yazılım geliştirme süreç modelidir. 8.Kaynakça www.featuredrivendevelopment.com www.pcoad.com/download/fdd/fddslides20.pdf servlet.java.sun.com/javaone/javaone2000/pdfs/bus-1016.pdf www.featuredrivendevelopment.com/files/fddprocessesa4.pdf. Software Engineering: A Practitioner s Approach Roger Pressman, Prentice Hall, 2004,ISBN: 007301933X Java Modeling Color With UML Peter Coad, Eric Lefebvre, Jeff De Luca, Prentice Hall, 2002, ISBN: 013011510X