Yinelemeli geliştirim (iterative development) temelli bir yaklaşım ve uygulamaları

Tam metin

(1)KOCAELø ÜNøVERSøTESø * FEN BøLøMLERø ENSTøTÜSÜ. YøNELEMELø GELøùTøRøM (ITERATIVE DEVELOPMENT) TEMELLø BøR YAKLAùIM VE UYGULAMALARI. YÜKSEK LøSANS TEZø Bilgisayar Müh. Onur TAVøLOöLU. Ana Bilim Dalı: Bilgisayar Mühendisli÷i Danıúman: Yrd. Doç. Dr. H. Engin DEMøRAY. KOCAELø, 2008.

(2)

(3) ÖNSÖZ ve TEùEKKÜR Ülkemizde ve dünyada yazılım geliútirme hala bir sorunlar toplulu÷u olarak yer almakta ve bu sorunları çözmek için önerilen çok sayıda farklı yöntem bulunmaktaysa da bunlar içinden fikren do÷ru gözüküp uygulamada sürekli baúarılı sonuçlar verebilenleri sayıca pek azdır. Bu çalıúmada, yöntemlerden küçük yazılım úirketleri için daha uygun oldu÷u görüúü hakim olan yinelemeli geliútirim temel alınır ve farklı yazılım geliútirme süreç aktivitelerinden bir kaçının birleúimi halinde ortaya konulur. Özellikle ülkemizde yazılım süreçlerine uyma konusunda ne yazık ki büyük bir e÷ilim yoktur. Bunun sebebi olarak bir çok sürecin hala yazılım geliútiren firmalar tarafından hantal ve yaptıkları iúi kolaylaútıran bir yöntemden ziyade önlerine koyulan bir engel olarak görülmesi yatmaktadır. Çalıúma ile ortaya koyulan yaklaúım ise bu önyargılara tamamen zıt düúünceleri temel alır. Çalıúma süresince, elektronik ve bilgisayar dünyası hakkındaki geniú vizyonunu benimle paylaúmaktan çekinmeyen, çalıúma konum hakkında benden hiç bir deste÷ini esirgemeyen kıymetli hocam Sn. Yrd. Doç. Dr. Engin DEMøRAY’a, beni her konuda gözleri kapalı desteklemeyi kendilerine görev edinmiú sevgili kardeúim Umut, annem Belgin, babam Ahmet TAVøLOöLU’na, yazılım süreçlerinin de÷iúik büyüklüklerdeki úirketlere ölçeklenirken nasıl de÷iúime u÷ramaları gerekti÷i konusundaki fikirlerini benimle paylaúmaktan çekinmeyen Nortel Netaú Yazılım Mühendislerinden sevgili Serpil øLHAN’a ve çalıúma hayatımdaki deneyimlerle tez çalıúmamın úekillenmesine yardımcı olan AirTies Kablosuz øletiúim, VoIP grubuna teúekkürü bir borç bilirim.. i.

(4) ÖNSÖZ ve TEùEKKÜR............................................................................................... i øÇøNDEKøLER.............................................................................................................ii ùEKøLLER DøZøNø .................................................................................................... vi TABLOLAR DøZøNø ................................................................................................. vii KISALTMALAR...................................................................................................... viii ÖZET .......................................................................................................................... ix øNGøLøZCE ÖZET....................................................................................................... x 1. GøRøù ...................................................................................................................... 1 2. TEMEL KAVRAMLAR ......................................................................................... 5 2.1. Yazılım.................................................................................................................. 5 2.2. øyi Yazılımın Özellikleri ....................................................................................... 6 2.3. Yazılım Mühendisli÷i ........................................................................................... 7 2.4. Yazılım Mühendisli÷indeki Zorluklar .................................................................. 7 3. YAZILIM SÜRECø NEDøR? .................................................................................. 9 3.1. Genel Yazılım Süreç Modelleri ............................................................................ 9 3.1.1. ùelale yaklaúımı (Waterfall) ............................................................................ 10 3.1.2. Yinelemeli ve evrimsel geliútirim .................................................................... 11 3.1.3. Bileúen temelli yazılım mühendisli÷i (Component-based software eng.) ....... 12 3.2. Süreç Aktiviteleri ................................................................................................ 13 3.2.1. Yazılım tanımlama........................................................................................... 14 3.2.2. Yazılım tasarımı ve gerçekleútirim .................................................................. 15 3.2.3. Yazılım do÷rulama........................................................................................... 16 3.2.4. Yazılım evrimi ................................................................................................. 16 3.3. Süreç Yinelemesi ................................................................................................ 17 3.3.1. Artımlı teslim ................................................................................................... 17 3.3.2. Spiral geliútirim................................................................................................ 18 3.4. Birleútirilmiú Süreç (Unified Process/UP) .......................................................... 19 3.4.1. RUP’un fazları ................................................................................................. 20 3.4.2. UP Disiplinleri nelerdir? .................................................................................. 20 3.4.3. RUP Temelleri ................................................................................................. 21 3.4.4. RUP Kilometre Taúları .................................................................................... 22 4. ÇEVøK GELøùTøRøM............................................................................................ 24 4.1. Çevik Bildiri (The Agile Manifesto)................................................................... 24 4.2. Çevik Prensipler (The Agile Principles) ............................................................. 24 4.3. Çevik Modelleme Nedir?.................................................................................... 25 4.3.1. Çevik birleútirilmiú süreç (Agile unified process) nedir? ................................ 26 4.3.2. Süreci düzenlemek ........................................................................................... 27 4.4. Evrimsel Gereksinimler ...................................................................................... 27 4.4.1. Evrimsel ve úelale gereksinimlerinin farkları .................................................. 28 4.5. Nasıl Evrimsel Analiz ve Tasarım Yapılır? ........................................................ 28 4.6. Yinelemeli Yöntemlerde Kullanım Vakalarıyla Nasıl Çalıúılır? ........................ 31 4.6.1. Kullanım vakaları ve di÷er úartnameler ........................................................... 32 4.6.2. De÷iúik UP artifektleri ne zaman yaratılmalı?................................................. 33 4.6.3. Baúlangıç aúamasında kullanım vakaları nasıl yazılır?.................................... 34 4.6.4. Olgunlaúma evresinde kullanım vakaları nasıl yazılır? ................................... 34 4.6.5. ønúa evresinde kullanım vakaları nasıl yazılır? ................................................ 35 4.6.6. Gereksinimleri bulmanın önemi nedir? ........................................................... 35 4.7. Gereksinimlerin Tipleri ve Kategorileri Nelerdir? ............................................. 36 4.7.1. Gereksinimler UP artifektleri olarak nasıl yapılandırılırlar? ........................... 37 ii ....

(5) 4.7.2. Artifektler için do÷ru format nedir?................................................................. 38 4.8. Aykırı Programlama (Extreme Programming - XP)........................................... 38 4.8.1. XP aktiviteleri .................................................................................................. 39 4.8.1.1. Kodlama........................................................................................................ 39 4.8.1.2. Test................................................................................................................ 40 4.8.1.3. Dinlemek....................................................................................................... 40 4.8.1.4. Tasarlamak .................................................................................................... 41 4.8.2. XP Uygulamaları ............................................................................................. 41 5. SÜRECøN TEMELø VE SÜRECø OLUùTURAN PARÇALAR.......................... 44 5.1. Basitçe Sürecin øúleyiúi ve Bir Örnek ................................................................. 44 5.1.1. Kullanım vakalarını (Use Case) tanımlamak................................................... 44 5.1.2. Bir etki alanı (domain) modeli tanımlanır ....................................................... 45 5.1.3. Nesnelere sorumluluk atamak, etkileúim (interaction) diyagramlarını çizmek 45 5.1.3. Tasarım sınıf diyagramlarını tanımlamak ........................................................ 46 5.1.4. Çevik modellemede UML’in yeri .................................................................... 47 5.1.5. Programlamaya baúlamadan önce UML’e zaman ayırmak ............................. 48 5.2. Kullanım Vakaları............................................................................................... 49 5.2.1. Neden kullanım vakalarına ihtiyaç duyarız?.................................................... 49 5.2.2. Kullanım vakası nedir? .................................................................................... 50 5.2.3. Fonksiyonel gereksinimler olarak kullanım vakaları....................................... 52 5.2.4. Kullanım vakaları ve kullanım vakası modeli ................................................. 52 5.2.5. Üç aktör çeúidi nelerdir? .................................................................................. 53 5.2.6. En sık kullanılan kullanım vakası biçimleri nelerdir? ..................................... 54 5.2.7. Tam giydirilmiú stil örne÷i............................................................................... 55 5.2.8. Bölümlerin Anlamları ...................................................................................... 58 5.2.8.1. Kapsam ......................................................................................................... 58 5.2.8.2. Seviye............................................................................................................ 58 5.2.8.3. Ana aktör....................................................................................................... 59 5.2.8.4. Paydaúlar ve ilgileri listesi ............................................................................ 59 5.2.8.5. Önúartlar ve baúarı garantileri ....................................................................... 59 5.2.8.6. Ana Baúarı senaryosu ve adımları................................................................. 60 5.2.8.7. Uzantılar (veya alternatif akıúlar) ................................................................. 61 5.2.9. Baúka bir kullanım vakasının iúletilmesi ......................................................... 62 5.2.10. Özel gereksinimler ......................................................................................... 62 5.2.11. Teknoloji ve veri de÷iúiklik listesi................................................................. 62 5.2.12. Kullanım vakası yazarken dikkat etmemiz gerekenler .................................. 63 5.2.12.1. Özü yazmak, kullanıcı arayüzü detaylarından sakınmak............................ 63 5.2.12.2. Kısa ve öz kullanım vakaları....................................................................... 64 5.2.12.3. Kara kutu kullanım vakaları yazın .............................................................. 64 5.2.13. Bir aktör belirleyin ve aktör-hedef bakıú açısını temel alın........................... 65 5.2.14. Kullanım vakalarını bulmak .......................................................................... 65 5.2.15. Sistem sınırlarını belirleyin (scope) ............................................................... 66 5.2.16. Ana aktörleri ve hedeflerini bulmak .............................................................. 67 5.2.16.1. Aktörleri ve hedeflerini belirlememize yardımcı olacak sorular ................ 67 5.2.16.2. Aktörleri ve hedeflerini düzenlemek (fonksiyonel kapsam)....................... 68 5.2.16.3. Aktör hedefleri ve kullanım vakaları iliúkisi .............................................. 68 5.2.16.4. Olay analizi (aktör ve hedeflerini bulmada kullanılacak di÷er yöntemler) 69 5.2.17. Kullanım vakalarını tanımlamak.................................................................... 70 5.2.18. Kullanıúlı kullanım vakaları bulmak için hangi testler uygulanabilir?.......... 70 iii.

(6) 5.2.18.1. Patron testi .................................................................................................. 70 5.2.18.2. Temel iúletme süreci testi............................................................................ 70 5.2.18.3. Boyut testi ................................................................................................... 71 5.2.19. Yinelemeli yaklaúımlarda kullanım vakalarıyla çalıúmak ............................. 71 5.2.20. UP baúlangıç aúamasında kullanım vakası nasıl yazılır? ............................... 72 5.2.21. UP Olgunlaúma Aúamasında Kullanım Vakaları Nasıl Yazılır? ................... 73 5.2.22. ønúa aúamasında kullanım vakaları nasıl yazılır?........................................... 74 5.2.23. Di÷er gereksinimler ....................................................................................... 75 5.2.23.1. Yardımcı tanımlamalar ............................................................................... 75 5.2.23.2. Kalite özellikleri.......................................................................................... 76 5.2.23.3. Yardımcı tanımlamalarda fonksiyonellik ................................................... 76 5.2.23.4. Uygulamaya has etki alanı (iú) kuralları ..................................................... 77 5.2.23.5. ølgi duyulan alanlarla ilgili bilgiler ............................................................. 77 5.2.23.6. Di÷erleri ...................................................................................................... 77 5.3. Etki Alanı (Domain) Modelleri........................................................................... 78 5.3.1. Etki alanı modeli nedir? ................................................................................... 78 5.3.2. Kavramsal sınıflar nelerdir?............................................................................. 79 5.3.3. Düúük temsilsel fark ........................................................................................ 80 5.3.4. Etki alanı modeli nasıl yaratılır........................................................................ 80 5.3.5. Kavramsal sınıflar nasıl bulunur...................................................................... 81 5.3.5.1. Var olan modelleri iyileútirmek .................................................................... 81 5.3.5.2. Bir kategori listesi kullanmak ....................................................................... 81 5.3.5.3. Kavramsal sınıfları isimlerden çıkarmak ...................................................... 82 5.3.6. Etki alanı terimlerini kullanın .......................................................................... 83 5.3.7. Açıklama sınıflarını kullanarak modelleme..................................................... 84 5.3.8. Gerçek olmayan dünyayı modellemek............................................................. 85 5.3.9. øliúkiler ............................................................................................................. 86 5.3.10. Yinelemeli ve evrimsel etki alanı modelleme................................................ 87 5.3.11. UP’de etki alanı modelleri ............................................................................. 88 5.3.11.1. Baúlangıç fazında etki alanı modelleri ........................................................ 88 5.3.11.2. Olgunlaúma fazında etki alanı modelleri .................................................... 88 5.3.12. UP iú nesne modeli ve etki alanı modeli ........................................................ 88 5.4. Sistem Akıú Diyagramları................................................................................... 89 5.4.1. Sistem akıú diyagramları nelerdir?................................................................... 89 5.4.2. Neden bir sistem akıú diyagramı çizeriz? ........................................................ 90 5.4.3. Sistem akıú diyagramları ve kullanım vakaları aralarındaki iliúki................... 90 5.4.4. Sistem olaylarını ve operasyonlarını isimlendirmek........................................ 91 5.4.5. Yinelemeli ve evrimsel sistem akıú diyagramları ............................................ 92 5.5. Operasyon Kontratları......................................................................................... 92 5.5.1. Operasyon kontratları bölümlerinin açıklamaları ............................................ 93 5.5.2. Sistem operasyonu nedir? ................................................................................ 93 5.5.3. Sonra durumunun detaylıca açıklanması ......................................................... 94 5.5.4. Kontratlar nasıl hazırlanır ................................................................................ 95 5.5.5. UP’de operasyon kontratları ............................................................................ 96 5.6. Tasarıma Geçiú.................................................................................................... 96 5.6.1. Mantıksal mimari ve katmanları nelerdir? ....................................................... 96 5.6.2. Katmanlarla tasarlamak ................................................................................... 97 5.6.3. Etki alanı modeli ve etki alanı katmanı arasındaki iliúki ................................. 99 5.6.4. Sistem akıú diyagramlar, sistem operasyonları ................................................ 99 iv.

(7) 5.6.5. Nesneleri tasarlamak........................................................................................ 99 5.6.6. Dinamik nesne modellemesi .......................................................................... 100 5.6.7. Statik nesne modellemesi............................................................................... 100 5.6.8. Etkileúim ve sınıf diyagramları arasındaki iliúki ........................................... 100 5.7. Nesnelere Sorumluluklar Atamak..................................................................... 101 5.7.1. Nesneye yönelik tasarımın süreçten gelen girdileri ....................................... 102 5.7.2. Nesne tasarımında yapılan aktiviteler nelerdir?............................................. 103 5.7.3. Tasarım sonucunda elimize neler geçer? ....................................................... 103 5.7.4. Sorumluluklar ve sorumluluk güdümlü tasarım ............................................ 103 5.7.4.1. “Yapma” tipindeki sorumluluklar............................................................... 104 5.7.4.2. “Bilme” tipindeki sorumluluklar................................................................. 104 5.7.5. Sorumlulukları bulmak .................................................................................. 104 5.7.6. GRASP (Genel Sorumluluk Atama Yazılım Prensipleri).............................. 105 5.7.7. Sorumluluklar, GRASP ve UML diyagramları arasındaki ba÷ ..................... 105 5.7.8. GRASP prensipleri......................................................................................... 106 5.7.8.1. Yaratıcı (Creator) ........................................................................................ 106 5.7.8.2. Bilgi uzmanı (Information expert) .............................................................. 107 5.7.8.3. Düúük ba÷ımlılık (Low coupling)............................................................... 109 5.7.8.4. Kontrolcü (Controller) ................................................................................ 111 5.7.8.5. Yüksek bütünlük (High cohesion) .............................................................. 113 5.7.8.6. Çok úekillilik (Polymorphism).................................................................... 115 5.7.8.7. Saf üretim (Pure fabrication) ...................................................................... 117 5.7.8.8. Dolaylama (Indirection).............................................................................. 118 5.7.8.9. Korunan de÷iúim (Protected variations) ..................................................... 119 5.7.9. Di÷er prensipler ve yöntemler ....................................................................... 122 5.8. Sözde Kodla Programlama Süreci .................................................................... 122 5.8.1. Sözde kodla programlama süreciyle sınıfları gerçeklemek ........................... 122 5.8.1.1. Fonksiyonu tasarlamak ............................................................................... 124 5.8.1.2. Fonksiyonu kodlamak................................................................................. 125 5.8.2. Sözde kodla programlama sürecini kendi sürecimize entegre etmek ............ 126 6. SONUÇLAR VE ÖNERøLER ............................................................................. 127 KAYNAKLAR......................................................................................................... 129 ÖZGEÇMøù.............................................................................................................. 132. v.

(8) ùEKøLLER DøZøNø ùekil 3.1. Spiral Geliútirim...................................................................................... 19 ùekil 3.2 UP Disiplinleri.......................................................................................... 21 ùekil 4.1. Simutel uygulaması için kısmi Etki Alan Modeli ................................... 45 ùekil 4.2. Yazılım nesneleri arasındaki sekans diyagramı...................................... 46 ùekil 4.3. Kısmi Tasarım Sınıf Diyagramı............................................................. 47 ùekil 5.1. Codec açıklaması ve sınıf iliúkisi........................................................... 85 ùekil 5.2. øliúkiler..................................................................................................... 86 ùekil 5.3. SimuTel arama yapma sistem akıú diyagramı......................................... 89 ùekil 5.4. Sistem akıú diyagramları ve senaryolarla iliúkileri.................................. 91 ùekil 5.5 NumaraÇevir Akıú Diyagramı.................................................................. 101 ùekil 5.6 Akıú diyagramından çıkan nesneler.......................................................... 101 ùekil 5.7. AramaPlanı nesnesinin sorumlulu÷u ..................................................... 105 ùekil 5.8 Sistem tasarımımızın en son görünümü.................................................. 116. vi.

(9) TABLOLAR DøZøNø Tablo 3.1 Örnek UP artifact zamanlamaları............................................................ ... 33 Tablo 5.1 Cockburn(2000)’ün kullanım vakası tasla÷ı........................................... ... 55 Tablo 5.2. SimuTel için “Arama Yap” Kullanım Vakası........................................... 56 Tablo 5.3. Kara kutu tarzı kullanım vakaları .............................................................. 64 Tablo 5.4. øçerde-Dıúarda Listesi................................................................................ 66 Tablo 5.5. Aktör-hedef bulma soruları....................................................................... 67 Tablo 5.6. Aktörler ve hedefleri................................................................................ 68 Tablo 5.7. Olay-aktör-hedef iliúkisi............................................................................ 69 Tablo 5.8. Kavramsal sınıflara örnekler..................................................................... 81 Tablo 5.9. Kavramsal sınıfları isimlerden çıkarmak.................................................. 82 Tablo 5.9. Numara çevirme operasyon kontrat örne÷i............................................... 93 Tablo 5.10 Süreç boyunca yaptıklarımız.................................................................. 102. vii.

(10) KISALTMALAR UP RUP UML GRASP. : Unified Process : Rational Unified Process : Unified Modeling Language : General Responsibility Assignment Software Patterns. viii.

(11) YøNELEMELø GELøùTøRøM (ITERATIVE DEVELOPMENT) TEMELLø BøR YAKLAùIM VE UYGULAMALARI Onur TAVøLOöLU Anahtar Kelimeler: Yazılım Mühendisli÷i, Atik Modelleme, Yazılım Süreçleri, Nesneye Yönelik Analiz ve Tasarım, Yinelemeli Geliútirim Özet: Yazılım geliútiriminde var olan bir çok farklı yöntemden otoriteler tarafından küçük çaplı yazılım úirketleri (5-50 geliútiriciye sahip olanlarının) için en uygun olanı olarak kabul görmüú olan, yinelemeli geliútirim yaklaúımını, atik modelleme ve sözde kodla programlama süreciyle bir araya getirip, esnek ve ölçeklenebilir yapısıyla tüm yazılım firmalarına uyabilecek bir yaklaúım olarak ortaya koyulur.Nesneye yönelik tasarım ilkeleri de çalıúmada detaylı úekilde prensipler halinde ele alınmıútır. Anlatılan bu prensipler sayesinde süreç içerisinde atik modellemeyi kullanırken sorumlulukları nesnelere nasıl atayaca÷ımızı ve nelere dikkat etmemiz gerekti÷i vurgulanır. Son prensipler içinde yer alan sözde kodla programlama sürecinden bahsedilirken de, geliútirme esnasında uygulayaca÷ımız basit bir yaklaúımın nasıl daha önce verilmiú tasarım kararlarını kolayca kontrol etmenize yardımcı olaca÷ı gösterilir. Çalıúmada kendine yer bulamayan tek yazılım süreci aktivitesi yapılan geliútirimi do÷rulamak için yapmamız gereken testlerdir. Bu aktivitenin yer almama sebebi de, çalıúmanın baúlarında yazılım geliútirimi hakkında bilgi verilirken bahsi geçen test türlerinin sürecimize kolayca uygulanabilecek olması ve test güdümlü geliútirim temel alınmadı÷ı için özel bir açıklamaya da ihtiyaç duymamalarıdır.. ix.

(12) AN APPROACH BASED ON ITERATIVE DEVELOPMENT AND ITS APPLICATIONS Onur TAVøLOöLU Keywords: Software Engineering, Agile Modeling, Software Processes, Object Oriented Analysis and Design, Iterative Development Abstract: According to authorities the most appropriote software process for small software companies is iterative development. Iterative development is merged with agile modeling and the pseudocode programming process, presenting a scalable approach that becomes applicable for most software companies. Also, object oriented design basics are explained in detail within principles (or patterns). By using these principles, a solution is explained for the problem of assigning responsibilities to objects while using the methodoligies that are recommended by agile modeling. And after explaining the pseudocode programming process we will see that, we will be able to check our design decisions while applying pseudocode programming process. All activities in the process (that are relevant to actual software developlment) are all explained in detail. The only exception is the testing. Testing is not explained in detail at the last section where all the activities explained. The reason for this is, the approach recommended here is not based on test driven development. And all testing methods that are applicable to our software process are mentioned in the basic concepts section.. x.

(13) 1. GøRøù. Yazılım dünyasının günümüzdeki en büyük problemlerinden birisi istenilen yazılımı geliútirmek için harcananan eme÷in, dökülen paraların sonucunda ortaya hasbelkader çıkan yazılımın gerçekten istenilen úeyleri yapamamasıdır. Tam olarak istenilen iúi yapan yazılım geliútirildiyse de ileride baúka sorunlara da sebep olmaması gerekir. Geliútirilen yazılım üzerinde daha sonradan bir takım de÷iúiklikler yapılması gerekebilir. Uygulamanın, benzer ama tamamen aynı olmayan ihtiyaçlarının karúılanması için talep eden (çalıúma boyunca yazılımın paydaúlarından úeklinde isimlendirilecek olan) baúka bir müúteri için de÷iútirilmesi gerekti÷inde; geliútirilen yazılımdan bizim de beklentilerimizin oldu÷u konusu ortaya çıkmaktadır ki, verilen örnek durum için bu beklenti, sürdürülebilirlik ve tekrar kullanılabilirlik olarak karúımıza çıkar. Yani geliútirilen yazılımın de÷iútirilip baúka ihtiyaçları karúılayacak úekilde de÷iútirebilmesi nasıl mümkün olur. Ufak tefek de÷iúiklikler için bir çok úeyin baútan mı yapılması gerekecek? Bu sorunun cevabı kesinlikle hayır olmalıdır. Geliútirilen yazılımın kendisi hakkında var olan tüm bu beklentileri gerçeklemesi sa÷lanabilir mi? Peki sa÷lanabilirse, nasıl? øúte yapılan çalıúma bu sorulara cevap niteli÷indedir. Var olan tüm beklentileri, gereksinimleri karúılayan yazılımın geliútirilmesi aúama aúama, ölçeklenebilir bir süreç içerisinde anlatılmıú, süreç içerisinde yer alan aktiviteler bir konu üzerinde örneklenmiútir. Paydaúların. (stakeholders). beklentilerinin. úekillendirilip. gereksinimlerin. oluúturulması konusunda Damian (2007), Glinz ve Wieringa (2007)’in çalıúmaları yol gösterici olmuútur. Paydaúların yazılım geliútirimine katkılarının ne yönde olabilece÷i konusunda da Decker ve di÷. (2007)’nin çalıúmasından faydalanılmıútır. 1.

(14) Bununla birlikte Woolridge ve di÷. (2007) risk önceliklendirmesi konusundaki çalıúması ise konunun geniúletilebilirlik açısından katı sınırlara sahip olmadı÷ını göstermiútir. Jacobson (1992)’den ise gereksinimlerin projenin gidiúatını nasıl etkileyebilece÷i konusunda faydalanılmıútır. Ne var ki kullanım vakalarını hakkında ortaya koydu÷u eúsiz bilgilerle Cockburn (2000) eúsiz bir yol gösterici olmuútur. Çalıúmanın ikinci bölümünde tez boyunca anlatılan yöntemle yazılım geliútirilmesi esnasında karúılaúılan problemler ve konular hakkında sahip olunması gereken temel kavramlar açıklanmıútır. Aynı bölümde yazılım mühendisleri olarak çözmemiz geren sorunların yanısıra bu sorunları çözmeye çalıúan yöntemlerden de temel olarak bahsedilmiútir. Çalıúmanın üçüncü bölümünde, ilk bölümde anlatılan problemleri çözmek için kullanılması önerilen yazılım geliútirme sürecinin, hangi süreçlerden etkilendi÷i ve modeller arasında hangisine uydu÷u da bu bölümde ele alınırken alternatif yöntemler yine bu bölümde anlatılıp farklılıkları gösterilmiútir. Dördüncü bölümde bahsi geçen sürecin temellerinden olan çevik geliútirim tanıtılırken, tasarlanan sürece nasıl dahil oldu÷u ve süreci nasıl etkiledi÷i anlatılmıútır. Hunt (2006) ise çevik geliútirim hakkında detaylı bilgilere ulaúmak için kullanılmıú. Basili ve Turner (1975)’in çalıúması ise yinelemeli süreçlerin uygulanması hakkında fikir vermiútir. Önceki bölümlerde sürecin nasıl ortaya çıktı÷ı açıklanırken nihayet beúinci bölümde sürecin kendisini anlatılmıútır. Çalıúmanın bütününün daha iyi anlaúılabilmesi için ilk olarak sürecin aúamalarının kaba taslak halde nasıl iúledi÷inden bahsedilip sonra bahsi geçen her aúamanın detayları verilmiútir. Ayrıca süreç içerisinde yer alan temel aktivitelerin detaylı açıklamaları yine bu bölümde verilir. Bu aktiviteler çalıúmanın bütünsel olarak daha iyi algılanabilmesi için yazılım geliútirirken uygulanma sıralarına (sıralama tabi ki çalıúmada bahsi geçen sürece göre yapılmıútır) göre anlatılmıútır. Bu sıralamaya göre ilk olarak sistem gereksinimlerinin belirlenmesi için yapılan çalıúmalar detaylandırılmıútır. Ardından tasarıma geçmeden önce yapılan gereksinim çalıúmalarının tasarımı nasıl etkiledi÷i anlatılıp tasarımın nasıl 2.

(15) yapılaca÷ına geçilmiútir. Tasarımın süreç içerisindeki konumu ve süreç tarafından nasıl yapılması gerekti÷i konusunda nasıl görüldü÷ü vurgulandıktan sonra tasarımı yaparken göz önünde bulundurmamız gereken prensipler de yine bu bölümde anlatılmıútır. Deitel ve Deitel (2001) ve Altıntaú (2003) çalıúmalarıyla da farklı programlama dillerinin nesneye yönelik yaklaúımı nasıl destekledi÷i konusunda faydalanılmıútır. Çalıúma boyunca anlatılan yaklaúımın uygulanması ise SimuTel adını verdi÷im bir internet telefonu simulasyon programıyla yapılmıútır. Bu uygulama açık kaynak kodlu. OPAL. (www.opalvoip.org). kütüphanesini. kullanarak. geliútirilmiútir.. Aberdour (2007) ile Martin ve Hoffman (2007)’ın çalıúmaları ise açık kaynak kodlu projelerin çekinmeden kullanılması konusunda cesaret verici olmuútur. Altıncı ve son bölümde ise çalıúma sonucunda hangi problemlere çözümler getirildi÷i açıklanırken bu çözümü kimlerin neden benimsemesi gerekti÷inden kısaca bahsedilmiútir. Ayrıca Brock ve McKean (2002), Larman (2005) ve Parnas (1972) sorumlulukların nesnelere nasıl atanaca÷ı konusuna ıúık tutarken. Gamma ve di÷erleri (1995)’nin çalıúmasında tasarım desenlerinin sorumluluk atama kuralları için mükemmel örnekler oluúturdu÷u görülmüútür. Yazılımın gerçeklenmesi esnasında tasarımın nasıl úekillenebilece÷i McConnel (2004) ve McConnel (1993) çalıúmalarının verdi÷i bilgilerle belirginleúmiútir. Ayrıca Pollice (2004)’de küçük yazılım úirketlerinin kullanabilece÷i bir yaklaúım olarak burdaki çalıúmayla hemen hemen aynı temeller üzerinde duran bir yaklaúımın ortaya atıldı÷ı görülmüútür. Sommerville (2007) yazılım mühendisli÷indeki temel problemlerin anlaúılması açısından faydalı bir kaynak olmuútur.. 3.

(16) Nesneye yönelik tasarımın insan tarafından daha rahat yapılabilmesini sa÷layan UML diyagramlarının Fowler ve Scott (1999) sayesinde karıúıklı÷a yer bırakmadan açıkça anlaúılması sa÷lanmaútır. Kalıpsız ve di÷. (2008) çalıúması ismi geçen bir çok yabancı terimin Türkçe karúılıklarının bulunması için kullanılabilecek az sayıdaki kaynaktan biri olmuútur.. 4.

(17) 2. TEMEL KAVRAMLAR Çevik modelleme ve yinelemeli geliútirimin yazılım süreçleri içinde ele alınmasından önce bazı temel kavramları açıklamak gerekir. Yazılım: Bilgisayar programları ve iliúkili tüm dökümanlarla birlikte programın düzgün úekilde çalıúmasını sa÷layacak konfigurasyon verilerinin tamamına yazılım adı verilir. Yazılım Mühendisli÷i: Yazılım üretmenin bütün yönleriyle ilgilenen bir mühendislik disiplinidir. Bu noktada bilgisayar bilimlerinin, yazılım mühendisli÷inden ne farkı vardır sorusuna cevap olarak úu açıklamayı yapmak uygun olur: Bilgisayar bilimleri, teori ve temellerle ilgilenirken; yazılım mühendisli÷i yazılımın geliútirilmesi ve kullanıma hazır hale getirilmesiyle ilgilenir. Yazılımın geliútirilmesi ve/veya de÷iútirilmesi amacıyla yapılan etkinliklerin tamamına yazılım süreci denirken, süreçlerin belli bir perspektiften gösterilen basitleútirilmiú haline ise yazılım süreci modeli denir.. 2.1. Yazılım. Bir çok insan yazılım kelimesini bilgisayar programlarıyla eú anlamlı kullanıyor. Aslında bu son derece kısıtlayıcı bir bakıú açısıdır. Yazılım bilgisayar programlarının yanında dökümantasyon ve programın do÷ru çalıúmasını sa÷layacak konfigurasyon verilerinin tamamına verilen isimdir. Temelde iki tip yazılım ürünü vardır: 1. Genel Ürünler: Piyasada herhangi bir müúterinin satın alabildi÷i yazılım tipidir (Veritabanları, kelime iúlemcileri örnek olarak bu gruba sokulabilir). 5.

(18) 2. Müúteriye özel ürünler: Belli bir müúteri tarafından yaptırılan yazılımlardır (hava trafik kontrol sistemleri gibi). Bu iki tip yazılım arasındaki temel fark, genel ürünlerde yazılım özelliklerini geliútirici firma belirlerken, di÷erinde genellikle yazılımı yaptıran firma belirler.. 2.2. øyi Yazılımın Özellikleri. Sundukları hizmetlerin yanında yazılım ürünlerinin yazılımın kalitesini yansıtan bir takım özellikleri vardır. Bu hizmetler yazılımın ne yaptı÷ıyla do÷rudan ilgili de÷ildir. Aksine çalıúırken ki davranıúlarıyla ve kaynak kodun organizasyonu ve yapısıyla ilgilidir. Aúa÷ıdaki özellikler iyi tasarlanmıú bir yazılım sisteminin karakteristi÷ini gösterir: Sürdürülebilirlik (Maintainability) : Yazılım de÷iúen ihtiyaçları karúılamak üzere yeniden yazılabilir yapıda olmalıdır. Güvenilirlik (Dependability) : Güvenilirlik, “sa÷lamlık (reliability), security ve safety” kavramlarını kapsar. Güvenilir yazılım bir hata durumunda fiziksel ya da ekonomik bir zarara sebep olmamalıdır. Verimlilik (Efficiency) : Yazılım, bellek ve iúlemci çevrimleri gibi sistem kaynaklarını boúa harcamamalıdır. Dolayısıyla verimlilik tepki verebilirlik, iúleme zamanı ve bellek kullanımı gibi konuları kapsar. Kullanılabilirlik (Usability) : Yazılım kimler için tasarlandıysa o kullanıcılar tarafından lüzumsuz gayrete gerek kalmadan, kullanılabilir olmalıdır. Yazılım mühendisli÷i genellikle bu özelliklerden ikisiyle ilgilenir, sürdürülebilirlik ve güvenilirlik. Bu çalıúmada da bahsi geçen yazılım geliútirme sürecinin bu iki özelli÷i olumlu yönde nasıl etkileyebilece÷i gösterilmiútir.. 6.

(19) 2.3. Yazılım Mühendisli÷i. Yazılım, üretmenin bütün yönleriyle, sistem tanımlamadan, kullanıma girdikten sonraki bakımına kadar ilgilenen bir mühendislik disiplinidir. Bu cümlede iki tane anahtar ifade vardır: 1. Mühendislik disiplini : Mühendisler bir takım úeyleri, sistemleri çalıútırırlar. Teorileri, yöntemleri ve araçları uygun oldukları yerde uygular ve seçerek kullanır ve onları destekleyecek teori veya yöntem yoksa da çözümler geliútirirler. Mühendisler aynı zamanda organizasyonel ve finansal kısıtlamaları da göz önüne alırlar. 2. Yazılım üretiminin bütün yönleri : Yazılım mühendisli÷i yalnızca yazılım geliútirmenin teknik süreçleriyle de÷il aynı zamanda yazılım projesi yönetimi ve yazılım. üretimini. desteklemek. için. araçların,. yöntemlerin. ve. teorilerin. geliútirilmesiyle de ilgilenir.. 2.4. Yazılım Mühendisli÷indeki Zorluklar. Heterojen Yapılar : Günümüzde sistemlerin, da÷ıtık olarak farklı tipteki bilgisayarlar üzerinde ve farklı tipteki destek sistemleriyle çalıúabilmesi istenmektedir. Aslında heterojenlik meselesinin özü, bu heterojenlikle baúa çıkabilecek güvenilir yazılımların geliútirilmesidir. Miras Sorunu : Bugün kullanılmakta olan yazılım sistemlerinin bir ço÷u kritik iúleri yapmalarına ra÷men, yıllar önce geliútirilmiúlerdir. Miras sorunu bu yazılımları sürdürmek ve güncellemekle ve bu iúleri yaparken maliyetleri en alt seviyede tutup önemli iú hizmetlerinin sunulmasına devam edilmesiyle ilgilidir. Teslim Sorunu : Geleneksel yazılım mühendisli÷i tekniklerinin bir ço÷u zaman alıcıdır. Aldıkları zaman yazılım kalitesini artırmak için kullanılır ama artık bu süreçlerin istenilenlere hemen tepki verebilecek ve esnek yapıda olmaları gerekir. 7.

(20) Teslim problemi, büyük ve karmaúık sistemlerin sistem kalitesinden ödün vermeden teslim sürelerini kısaltmakla ilgilidir.. 8.

(21) 3. YAZILIM SÜRECø NEDøR?. Bir yazılım ürününü ortaya çıkaran aktivitelerin bütünüdür. Bu aktiviteler genellikle yazılım mühendisleri tarafından yapılır. Dört temel süreç aktivitesi vardır ki bunlar bütün yazılım süreçlerine temel teúkil ederler, bunlar : 1. Yazılım tanımlama : Yazılımın fonksiyonelli÷i ve operasyonları üzerindeki kısıtlamalar tanımlanmalıdır. 2. Yazılım geliútirme : Tanımlamaları karúılayan yazılım üretilmelidir. 3. Yazılım do÷rulama : Yazılım, müúterinin isteklerini tam olarak yerine getirebiliyor mu diye kontrol edilmelidir. 4. Yazılımın de÷iútirilmesi : Yazılım, de÷iúen müúteri ihtiyaçlarına adapte olabilmelidir. Farklı yazılım süreçleri bu aktiviteleri farklı yollarla organize eder. Her aktivitenin zamanlaması bu aktivitenin sonucuna göre de÷iúir.. 3.1. Genel Yazılım Süreç Modelleri. Bir yazılım süreci modeli, bir yazılım sürecini belli bir açıdan sunan basitleútirilmiú tanımıdır. Modeller do÷aları gere÷i basitleútirmelerdir. Böylelikle bir yazılım süreç modeli bahsi geçen gerçek sürecin bir soyutlaması halini alır. Süreç modelleri yazılım sürecinin, yazılım ürünlerinin ve yazılım mühendisli÷iyle ilgili kiúilerin bir parçası oldukları aktiviteleri içerebilir. Üretilecek yazılım süreç modellerine örnek olarak aúa÷ıdaki modeller verilebilir: 9.

(22) 1. øú akıúı modeli : Süreçteki aktivitelerin giriúlerini, çıkıúlarını ve ba÷ımlılıklarını gösterir. Bu modeldeki aktiviteler insan eylemlerini temsil eder. 2. Veriakıúı veya aktivite modeli : Veri dönüúümlerini gerçekleútiren bazı aktivite gruplarını gösteren modeldir. Sürecin giriúlerinin nasıl çıktıya dönüútü÷ünü tasarımsal olarak gösterir. Burdaki aktiviteler düúük seviyeli aktivitelerdir. ønsanlar ya da bilgisayarlar tarafından yapılan veri dönüúümlerini gösteriyor olabilir. 3. Rol/Eylem Modeli : Yazılım sürecine dahil olan insanların sorumlu oldukları aktivitelerdeki rollerini gösteren modeldir. Yazılım geliútirmede bir kaç tane genel model vardır: 1. ùelale Yaklaúımı (Waterfall) : Burada yukarıda bahsi geçen aktiviteler alınır ve gereksinim belirlenmesi, yazılım tasarımı, gerçekleútirme, test etme gibi ayrı süreç aúamaları olarak sunulur. Her aúamadan sonra, o aúamanın iúi bitmiú olarak iúaretlenir ve geliútirmeye bir sonraki aúamayla devam edilir. 2. Evrimsel Geliútirim (Evolutionary Development) : Bu yaklaúım; tanımlama, geliútirme ve do÷rulama aktivitelerini kesik kesik úekilde birleútirir. Bir baúlangıç sistemi hızlıca çok soyut tanımlamalardan ortaya çıkarılır. Bu daha sonradan müúteri verilerine bakılarak ihtiyaçlarını karúılayacak úekilde iyileútirilir. Sistem sonra teslim edilebilir veya ihtiyaca göre daha yapısal bir yaklaúım kullanılarak daha sürdürülebilir ve dayanıklı bir sistem üretme amacıyla tekrar geliútirilebilir. 3. Bileúen Tabanlı Yazılım Mühendisli÷i(Component-based Software Engineering): Bu yaklaúımda sistemin parçalarının zaten var oldu÷u varsayılır. Sistem geliútirme süreci her úeyi baútan geliútirmektense bu parçaları birleútirmekle ilgilenir.. 3.1.1. ùelale yaklaúımı (Waterfall). 10.

(23) ùelale sürecinin yaúam çevriminde gereksinimlerin bütününü ya da büyük bir kısmını programlamaya baúlamadan önce tanımlama giriúimi vardır. Genellikle de kapsamlı bir tasarım da programlamadan önce yapılır. Aynı úekilde güvenilir bir plan (ya da zaman çizelgesi) da baúlamaya yakın hazırlanır. Genel aúamaları aúa÷ıdaki úekildedir: 1. Gereksinim analizi ve tanımlanması: Süreç içerisinde geliútirmeye baúlarken ilk olarak yapılan aktivite gereksinimlerin tamamının incelenmesi ve tanımlanmasıdır. 2. Sistem ve Yazılım tasarımı: Bütün gereksinimler tanımlandıktan sonra, bunlara bakılarak sistemin (yazılımın) tasarımı yapılır. 3. Gerçekleútirim. ve. birim. testler:Yazılım. tasarımın. yapılmasıyla. birlikte. gerçekleútirmeye yani kod yazma kısmına geçilir. Gerçekleútirme yapılırken her parçanın kendi içinde test edildi÷i birim testlere tabi tutulur. 4. Entegrasyon ve sistem testi: Gerçekleútirim kısmı bitince, yazılan modüllerin ya da alt kısımların bir araya getirilip entegre edilmesi ve sistemin bütün olarak test edilmesi iúlemi gerçekleútirilir. 5. Yürütme ve bakım: Tüm bu aúamalar gerçekleútirildikten sonra sistemin kullanıma sunulup gelen taleplere göre yeniden ele alınıp, gerekiyorsa yeni özelliklerle donatılması veya karúılaúılan sorunları bertaraf etmek için bakıma alınması gerekir.. 3.1.2. Yinelemeli ve evrimsel geliútirim. De÷iúim büyük yazılım projelerinde kaçınılmazdır. Sistem gereksinimleri, sistemi talep edenlerin gereksinlerimleriyle birlikte de÷iúir. ødari öncelikler de÷iúir, teknoloji de÷iúir tüm bunlar de÷iútikçe tasarım ve gerçekleme de de÷iúir. Bu da demektir ki yazılım süreci bir oldu-bitti iúi de÷ildir, aksine süreç aktiviteleri sistem üzerinde çalıúırken tekrarlanır. 11.

(24) Bir çok modern yazılım geliútirme yöntemindeki (UP-Unified Process gibi) temel uygulama yinelemeli geliútirmedir. Bu yaúam çevrimi yaklaúımında; geliútirme yineleme adı verilen, kısa, sabit uzunlukta küçük projeler halinde yapılandırılır. Her bir yineleme sonucunda, test edilmiú, entegre ve çalıútırılabilir sistem parçaları ortaya çıkar. Her yineleme kendi analiz, tasarım, gerçekleútirme ve test aktivitelerini içerir. Yinelemeli yaúam çevrimi, bir sistemin çoklu yinelemeyle geniúlemesini ve iyileútirilmesini temel alır. Çevrimsel geribesleme ve adaptasyon uygun bir sistemin ortaya çıkmasını sa÷layan temel ögelerdir. Sistem zaman geçtikçe yineleme ardına yinelemeyle büyür ve bu sebepten bu yaklaúım yinelemeli ve artımlı geliútirme (Iterative and Incremental Development) olarak adlandırılır. Ben de çalıúmamda bu geliútirme yaklaúımının, yazılımın tasarımına ve geliútirilmesine (dolayısıyla kalitesine) nasıl do÷rudan etkide bulundu÷unu gösterece÷im. Bu yaklaúımda kesinlikle kodlamaya geçmek için acele edilmedi÷i gibi bütün detayları kusursuzlaútırmayı deneyen uzun uzadısıya bir tasarım adımı da yer almaz. ølk olarak hızlıca ve kabataslak úekilde tasarımı yansıtan ön-düúünce çalıúması yapılır. Her yinelemenin sonucu çalıúabilir ama tamamlanmamıú sistemdir. Üretime gönderilecek kadar hazır de÷ildir. Sistem 10-15 yinelemeye kadar üretim için hazır hale gelemeyebilir. Her yinelemenin çıktısı deneysel ya da prototip de÷ildir. Aksine çıktı sistemin son halinin üretime hazır ayardaki bir parçasıdır.. 3.1.3. Bileúen temelli yazılım mühendisli÷i (Component-based software eng.). Bu yaklaúım sistemlerin iyi tanımlanmıú arayüzlerle fonksiyonel ve mantıksal bileúenlere bölünmesini esas alır. Bu iyi tanımlanmıú arayüzler bileúenler arasında iletiúimin gerçekleúmesi amacıyla kullanılırlar. Bileúenler, nesnelerden daha yüksek seviyede bir soyutlama olarak kabul edilir.. 12.

(25) Bir yazılım bileúeni daha önceden tanımlanmıú bir hizmeti veya olayı sunan ve di÷er bileúenlerle haberleúebilen bir sistemdir. Szyperski (2002) her yazılım bileúeninin tanıma uyması için beú kriteri sa÷laması gerekti÷ini söylerler: 1. Çoklu kullanımı destekleyen 2. Belli bir alana özel olmayan 3. Di÷er bileúenlerle birleútirilebilen 4. Kapsüllenmiú ve arayüzleri üzerinden incelenemeyen. 5. Versiyonlamadan ve sürümden ba÷ımsız birimler olan. Daha basit bir tanım úöyle yapılabilir: Bir bileúen belli bir tanıma göre yazılmıú nesnedir. Nesne tanıma uydu÷u sürece tanımın ne oldu÷u önemli de÷ildir COM, CORBA, Java Beans ... Temel olarak iki úeye dayanır: 1. Geniú bir tekrar kullanılabilir yazılım toplulu÷una. 2. Bu bileúenleri bir araya getirmekte kullanılacak bir çatıya (framework). Aúamaları ise gereksinim tanımlama, bileúen analizi, gereksinim modifikasyonu, sistem tasarımı (yazılım tekrar kullanımı) , geliútirim ve entegrasyon, ve son olarak do÷rulamadır.. 3.2. Süreç Aktiviteleri. Dört temel süreç aktivitesi vardır. 1. Tanımlama 2. Geliútirme 3. Do÷rulama 4. Evrim. 13.

(26) Bu aktiviteler farklı geliútirim süreçlerinde farklı úekilde organize edilirler. ùelale yaklaúımında sırayla ele alınırlarken, evrimsel geliúitirimde ise aktiviteler kesilerek ertelenir. Bu aktivitelerin nasıl organize edildi÷i yazılımın tipine, insanlara ve organizasyonal yapıya göre de÷iúir. Bu aktiviteleri do÷ru ya da yanlıú úekilde organize etmek diye bir úey yoktur.. 3.2.1. Yazılım tanımlama. Yazılım tanımlama veya gereksinim mühendisli÷i sistemin hangi hizmetleri verece÷ini ve sistemin iúleyiúindeki ve geliútirilmesindeki kısıtlamaları tanımlama iúi yapar. Gereksinim mühendisli÷i yazılım sürecinin kritik bir parçasıdır çünkü bu aúamada yapılacak hatalar ilerde tasarım ve gerçekleútirimde sorunlara sebep olacaktır. Gereksinim mühendisli÷i sürecinin dört ana aúaması vardır: 1. Fizibilite araútırması: Belirlenen kullanıcı ihtiyaçlarının bugünkü yazılım ve donanımlarla yapılıp yapılamayaca÷ı hakkındaki kestirimdir. 2. Gereksinimlerin türetilmesi ve analiz: Bu aúama, sistem ihtiyaçlarını var olan sistemleri gözlemleyerek, potansiyel kullanıcılarla tartıúarak türetme aúamasıdır. 3. Gereksinimlerin tanımlanması: Bir önceki aúamada elde edilen verilerin bir araya getirilip gereksinim kümesi úeklinde dokumante edilmesidir. Bu dokumanda iki tip gereksinim olabilir: a.. Kullanıcı gereksinimleri: Müúteri ve sistemin son kullanıcısını ilgilendiren. sistem ihtiyaçlarının taslak olarak ifade edilmesidir. b.. Sistem gereksinimleri: Fonksiyonelli÷in daha detaylı úekilde tanımlanmasıdır.. 4. Gereksinim do÷rulama: Gereksinimlerin gerçekçi, tutarlı ve tam oldu÷unun kontrol edildi÷i aktivitedir.. 14.

(27) Tabii ki bu gereksinim sürecindeki aktiviteler sırayla iúlenmek zorunda de÷ildir. Gereksinim analizi tanımlama ve belirtim aúamalarında da devam eder ve yeni gereksinimler süreç esnasında gün ıúı÷ına çıkabilir. Bu sebepten analiz, tanımlama ve belirtim iç içe geçmiú durumdadır. Aykırı Programlama (Extreme Programming) gibi çevik modellerde gereksinimler artımlı olarak geliútirilir.. 3.2.2. Yazılım tasarımı ve gerçekleútirim. Yazılım sürecinin gerçekleútirim aúaması, sistem belirtimlerinin çalıútırılabilir bir sisteme dönüútürme aúamasıdır. Her zaman yazılım tasarımı ve programlama aúamalarını içerir ama; e÷er geliútirimde evrimsel bir yaklaúım kullanılıyorsa yazılım belirtiminde iyileútirmeler de içerebilir. Tasarım süreç aktiviteleri úunlardır: 1. Mimari tasarım: Sistemi oluúturan alt-sistemler ve iliúkileri belirlenir ve dökümente edilir. 2. Soyut tanımlama: Her alt sistem için, servislerinin ve kısıtlamalarının soyut bir tanımlaması yapılır. 3. Arayüz tasarımı: Her alt sistem için di÷er alt sistemlere olan arayüzü tasarlanır ve dökümente edilir. Arayüz tanımlaması karıúıklıklara sebep olmamalıdır. 4. Bileúen tasarımı: Hizmetler bileúenlere verilir ve bu bileúenlerin arayüzleri tasarlanır. 5. Veri yapıları tasarımı: Sistem gerçekleútirilmesinde kullanılan veri yapıları detaylıca tasarlanır ve belirtilir. 6. Algoritma tasarımı: Hizmetleri sa÷layacak algoritmalar detaylıca tasarlanır.. 15.

(28) 3.2.3. Yazılım do÷rulama. Do÷rulama daha genel olarak, yazılımın kendi içinde do÷ru oldu÷unu ve gerçekten istenileni yapıp yapmadı÷ını kontrol etme (verification ve validation) olarak iki úekilde ele alınır. Do÷rulama aúamasının amacı sistemin tanımlamaları tam olarak karúılayıp karúılayamadı÷ının kontrolü úeklindedir. Test sürecindeki iúlemler: 1. Bileúen testi: Her ayrı bileúenin do÷ru olarak çalıúıp çalıúmadı÷ını kontrol etme amacıyla her bileúen di÷erlerinden ba÷ımsız úekilde ayrı teste tabi tutulur. Bileúenler sınıf, fonksiyon gibi basit varlıklar olabilir. 2. Sistem testi: Bileúenler sistemi oluúturmak maksadıyla bir araya getirilir. Bu noktada bileúenler, birbirleriyle olan uyumsuzluklarından dolayı çıkabilecek sorunlara karúı kontrol edilmelidir. Aynı zamanda sistemin gereksinimleri karúılayıp karúılamadı÷ını görmek de bu testin yapılma amaçlarından biridir. Geniú sistemler için, bileúenlerin alt sistemleri oluúturdu÷u ve bunların ayrı ayrı test edildi÷i çok aúamalı bir süreç úeklinde bu testi uygulamak mümkündür. 3. Kabul görme testi: Bu kısım sistemin kullanılmaya baúlamadan önce gördü÷ü son testtir. Artık sistem simule edilmiú verilerle de÷il de kullanıcıların sahip oldu÷u gerçek verilerle test edilir. Kabul görme testi sistem gereksinim tasarımındaki eksikleri veya hataları ortaya çıkarır. Kabul görme testine bazen alfa testi de denir. Alfa testleri kullanıcı sistemden memnun kalıp da geliútiriciyle anlaúana kadar devam eder.. 3.2.4. Yazılım evrimi. Yazılım sistemlerinin büyük ve karmaúık sistemlerin içine günden güne artarak girmesinin en önemli sebebi esneklikleridir. Donanımla ilgili tasarımsal bir karar verildikten sonra donanımı de÷iútirmek çok pahalıya mal olur. Ne var ki, de÷iúim hem geliútirme esnasında hem de geliútirmeden sonra yazılımın içindedir. Geleneksel olarak yazılımın geliútirilmesiyle evrimi (yazılımın bakımı da denebilir) ayrı olarak 16.

(29) ele alınmıútır. Günümüzde ise yazılımın geliútirilmesiyle bakımı arasındaki sınır ortadan kalkmaktadır. Yazılım mühendislerinin bu iúlemleri iki ayrı süreç olarak düúünmek yerine, yazılımın gereksinimlerle ve müúteri ihtiyaçlarıyla birlikte sürekli de÷iúti÷i evrimsel tek bir süreç olarak düúünmesi daha do÷ru olacaktır.. 3.3. Süreç Yinelemesi. økinci bölümde yinelemeli ve artımlı geliútirimden bahsedilmiúti. øúte bahsi geçen yaklaúımın temel olarak kabul etti÷i yöntem úudur: mini yazılım projeleri kabul edilen her bir yineleme, içerisinde dört temel süreç aktivitesini tekrar tekrar çalıútırarak sonuca ulaúmaya çalıúır. Süreç tekrarını destekleme maksadıyla tasarlanmıú iki süreç modeli vardır: 1. Artımlı teslim (Incremental Delivery) 2. Spiral Geliútirim (Spiral Development).. 3.3.1. Artımlı teslim. ùelale modeli bir sistemin müúterilerinin tasarım öncesinde gereksinimlerini belirlemelerini gerektirir. Böylelikle tasarımcı bu gereksinimleri göz önüne alarak geliútirim. yapar.. Gereksinimlerdeki. de÷iúiklikler. yeni. baútan. tasarım. ve. gerçekleútirime neden olur. Evrimsel yaklaúım ise gereksinim ve tasarım kararlarının ertelenmesine böylelikle de yazılımın zayıf úekilde yapısallaúmasına ve anlaması, bakımı güç hale gelmesine neden olur. Artımlı teslim iki modelin de faydalarını birleútiren bir ara yaklaúımdır. Bir artımlı geliútirme sürecinde müúteriler özetle sistem tarafından sunulacak hizmetleri belirler. Hangi hizmetlerin önemli ya da önemsiz oldu÷una da yine müúteriler karar verir. Daha sonra bazı teslim artımları tanımlanır ve bu artımlarda hangi alt sistemlerin önce geliútirilece÷i belirlenir.Sistem artımları belirlendikten sonra ilk artımda sunulacak hizmetlerin gereksinimleri detaylıca tanımlanır ve o artım gerçeklenmeye (geliútirilmeye) baúlanır. Geliútirim esnasında daha sonraki artımlar için gereksinim 17.

(30) analizleri yapılabilir ama üzerinde çalıúılan artım için gelen gereksinim de÷iúikliklerin de÷erlendirilmesi daha sonraki yinelemelere bırakılabilir.Ne zaman ki artım tamamlanır ve ortaya çıkan ürün teslim edilir, yazılım hemen müúterinin hizmetine sunulur. Bu úu anlama gelir: müúteriler sistem fonksiyonelli÷inin teslimini erkenden alırlar ve sistemin gereksinimlerini tatmin edip etmede÷ini erkenden görüp test edebilirler. Bu sayede ileriki adımlarda müúterinin taleplerinin gerçeklenmesi mümkün olacaktır.. 3.3.2. Spiral geliútirim Boehm (1988) tarafından ortaya atılan yazılım sürecinin spiral modeli ùekil 3.1’de görülmektedir. Bu modele göre, süreç birbirini sırayla izleyen aktiviteler serisi olarak de÷il de bir spiral olarak sunulmuútur. Spiraldeki her bir çevrim yazılım sürecinin bir fazını gösterir. Yani, en içteki çevrim sistem fizibilitesi ile, bir sonraki çevrim gereksinim tanımlanmasıyla, sonraki çevrim ise tasarımla ilgilenirken her çevrimde farklı bir süreç fazı ele alınır. Her çevrim dört sektöre ayrılır: 1. Hedef koyma: øçinde bulunulan faz için. hedefler belirlenir. Bu hedeflere. ulaúırken ortaya çıkabilecek riskler de bu sektörde belirlenir. 2. Risk de÷er biçme ve azaltma: Belirlenen her risk için detaylı bir analiz yapılır. Riski azaltmak için adımlar atılır. 3. Geliútirim ve do÷rulama: Risk de÷erlendirmesinden sonra, sistem için bir geliútirme modeli seçilir. 4. Planlama: Proje tekrar gözden geçirilir ve spiralin bir sonraki çevrimiyle devam edilip edilmeyece÷ine karar verilir. E÷er devam edilecekse, projenin bir sonraki fazıyla ilgili planlar yapılır. 18.

(31) ùekil 3.1. Boehm (1988)’de yer alan Spiral Geliútirim Modeli. Spiral geliútirimle di÷er yazılım süreç modelleri arasındaki temel fark spiral modelde riskin açıkça algılanmasıdır. Gayri resmi olarak, risk basitçe yanlıú gidebilecek úeyler demektir.. 3.4. Birleútirilmiú Süreç (Unified Process/UP). Unified Process (UP) nesneye yönelik sistemler geliútirmek için ortaya çıkmıú popüler bir yinelemeli yazılım geliútirme sürecidir.. Özellikle UP’un detaylı bir. úekilde iyileútirilmeden geçirilmiú hali olan Rational Unified Process ya da kısaca RUP yaygın olarak kabul görmüútür. UP, çok esnektir ve di÷er yinelemeli yöntemlerden (Extreme Programming ve Scrum gibi) gelecek olan uygulamalara açıktır. UP di÷er yaklaúımları küçümsemez, aksine onlardan faydalanmaya çalıúır ki bu çalıúmada da bir çok teknikten faydalanılmıútır. RUP’a göre yazılım bir kaç fazda geliútirilir ki her fazda bir ya da daha fazla yineleme yer alır. 19.

(32) 3.4.1. RUP’un fazları. RUP dört fazını (Inception, Elaboration, Construction ve Transition) devam eden bir proje olarak görür. Inception (Baúlangıç): Bu aúama, vizyon oluúturmak, iúin maksadını belirlemek ve destek alabilmek amacıyla bir yazılım prototipi geliútirmek ya da kısmi bir çözüm getirmekten ibarettir. Elaboration (Olgunlaúma): Bu aúama çalıútırılabilir bir yazılımın elde edilmesiyle biter ki bu aúamada kilit mimari kararlar verilmiú ve riskler azaltılmaya çalıúılmıútır. Construction. (ønúa):. Bu. aúama,. mimaride. belirlenmiú. fonksiyonellikleri. gerçekleútirmeyi içeriri. Transition (Geçiú): Bu aúama yazılımın kullanıcılarına sunulmasıyla ilgilenir.. 3.4.2. UP Disiplinleri nelerdir?. UP, use case (kullanım vakası) yazmak gibi bir takım aktiviteleri disiplinler içinde ele alır. Gereksinim analizindeki aktiviteler gibi bir konu alanındaki aktiviteler kümesi bir disiplin altında yer alır. UP’de tanımlanmıú ùekil 3.2’de görülen farklı farklı disiplinler vardır ama biz süreci anlamak maksadıyla úu üçüne odaklanaca÷ız: 1. øú Modelleme: Etki alan modeli (Domain Modeli), uygulamanın ilgilendi÷i alanla ilgili önemli kavramları görselleútirmeye yarar. 2. Gereksinim: Kullanım Vakası (Use-Case) modelleri ve Yardımcı Tanımlamalar iúlevsel gereksinimleri ve iúlevsel olmayan gereksinimleri ortaya çıkarır. 3. Tasarım: Tasarım modeli, yazılım nesnelerini tasarlamaya yarar. 20.

(33) Ayrıca, UP’den ayrı olarak bahsedilmiú olan ama tez boyunca anlatılan süreç içinde kullanabilece÷imiz bir takım gerçekleútirim tüyolarından da bahsedilmiútir.. ùekil 3.2 Ambler (2005)’ın UP Disiplinleri gösterimi Disiplinler ve Fazlar arasındaki iliúki nedir, sorusuna cevap olarak: ùekil 2.1’de gösterildi÷i gibi bir iterasyon bütün disiplinlerden veya ço÷undan bir takım iúleri içerir. Ne varki disiplinlerin arasındaki göreceli çalıúma miktarları zamanla de÷iúmektedir. ølk yinelemeler gereksinime ve tasarıma yönelik göreceli olarak daha fazla çalıúma içerirken ilerleyen yinelemelerde temel tasarım ve gereksinim çalıúmaları geridönüú ve adaptasyonla sabitlenir.. 3.4.3. RUP Temelleri. RUP genel olarak, “kimin” “neyi yaratmak” için “ne yapması” gerekti÷ini tanımlar. Roller: RUP, “kimin” kısmını rollerle tanımlar. Aktiviteler: “Ne yapmak” kısmı RUP tarafından aktivitelerle açıklanır. Aktiviteler rollerle iliúkilendirilir ve girdileri çıktıları vardır. Aktivitelerin amacı gözlemlenebilir sonuçlar elde etmektir. Bunun için “artifektler” (artifacts) yaratılır, de÷iútirilir. RUP bir takım rehberler ve kontrol noktaları sunarak belli aktiviteleri yapmaya yardımcı olur. 21.

(34) “Artifektler” yazılım mühendisli÷i sürecinde RUP’un “neyi yaratmak” kısmını oluúturur.. 3.4.4. RUP Kilometre Taúları. RUP yazılım geliútirme yaúam çevriminin dört fazının her birinin ayrı kilometre taúları ve nerede bittiklerini tanımlayan hedefleri vardır. Baúlangıç fazının hedefleri: 1. Bütün paydaúlar (paydaú ifadesi, ingilizcedeki “stakeholder” kelimesinin karúılı÷ı olup yazılımın baúarısından ya da baúarısızlı÷ından bir úekilde etkilenen herkesi ifade etmektedir; müúteri, proje yöneticisi, geliútiriciler ve kullanıcılar gibi) neyin yapılması gerekti÷ini, bunun ne kadar sürece÷ini ve ne kadara mal olaca÷ını anlamalı ve üzerinde anlaúmalıdırlar. 2. Paydaúlar beklentilerini ve önceliklerini belirlemelidirler. 3. Bütün riskler anlaúılmalı ve de÷erlendirilmelidir. Baúlangıç fazının artifekt’leri: Vizyon, iú durumu (business case), risk listesi... Olgunlaúma fazının hedefleri: 1. Ne üretece÷imizi bildi÷imiz sa÷lam bir mimari, sa÷lam gereksinimlerin belirlenmesi. 2. Mimari risklerin belirlenmesi ve etkilerinin azaltılması. 3. Sa÷lam ve kararlı bir yapıya sahip planlar ortaya çıkması. 4. Bütçenin belirlenmesi. ønúa fazının hedefleri: Yazılımın bir alpha sürümünün hazır hale gelmesi.. 22.

(35) Geçiú fazının hedefleri: Ürünün son kullanıcılara teslim edilebilecek yapıya kavuúturulması.. 23.

(36) 4. ÇEVøK GELøùTøRøM. Çevik geliútirim yöntemleri genellikle zamanla sınırlanmıú yinelemeli ve evrimsel geliútirim uygular, adaptif planlamayı tercih eder, artımlı teslimi teúvik eder ve de÷iúime hızla ve esneklikle cevap verebilen çevikli÷i teúvik eden bir takım baúka de÷erleri içerir.. 4.1. Çevik Bildiri (The Agile Manifesto). 1. Bireyler ve etkileúimleri, sürece ve araçlara 2. Çalıúan yazılım, kapsamlı dokümantasyona 3. Müúteri iúbirli÷i, sözleúme görüúmelerine 4. De÷iúime cevap verebilme, bir planı takip etmeye tercih edilir.... 4.2. Çevik Prensipler (The Agile Principles). Çevik bildiride anlatılanlar aúa÷ıdaki prensiplerle daha da detaylandırılabilir: 1. En önemli öncelik müúteriyi, devamlı úekilde iúe yarar yazılım teslim ederek memnun etmektir. 2. Gereksinimlerin de÷iúmesini, geliútirimin sonlarında dahi olsa kucaklayabilmek. 3. Çalıúan yazılımı her yinelemenin sonunda. olacak úekilde sık sık (bir kaç. haftadan bir kaç aya kadar olabilecek sürelerde – her zaman daha kısa süreleri terceh etmemiz gerekir) teslim etmek. 4. øúletmede çalıúanlar ve geliútiriciler proje boyunca birlikte çalıúmalı. 5. Projeyi iyi motive edilmiú çalıúanlarla geliútirin. øhtiyaçları olan ortamı ve deste÷i verin ve iúi bitirebileceklerine inanın.. 24.