5. Yazılım Projesi Geliştirme Modelleri

Özlü Söz

Yazılım espri gibidir, açıklamak zorundaysanız kötüdür….

 

 

Kazanımlar

1. Yazılım geliştirmede farklı yaklaşımları öğrenebilir.

2. Yazılımı daha hızlı, daha verimli, daha güvenli bir hale getirmek için hangi metodolojilerin kullanılması gerektiğini öğrenebilir.

3. Yazılım geliştirmede farklı öncelikleri belirleyebilir.

4. Doğrusal modeller/Çevik modeller karşılaştırılmasını yapabilir.

5. Hangi yazılımda hangi modelin kullanılacağını anlayabilir.

 

Birlikte Düşünelim

1. Neden birçok farklı yazılım gelştirme modeli bulunmaktadır?

2. Yazılım geliştirme modelleri arasındaki belirgin farklar nelerdir?

3. Sıklıkla karşımıza çıkan Şelale Modeli/Çevik Model arasındaki faklar nelerdir?

4. Bir yazılımın hangi model kullanılarak geliştirildiği, yazılımın özelliklerini etkiler mi?

5. Yazılım geliştirme modelleri arasında en iyisi hangisidir. böyle bir belirleme yapılabilir mi?

 

 

Başlamadan Önce

Yazılım geliştirme sadece bir programlama veya kodlama işi değildir. Mühendisin yazılım ürününün iyi çalışması için gereksinimleri tam olarak tanımlayıp bu gereksinimleri karşılayacak bir tasarım üretmesini, böylece projenin zamanında ve bütçeyi aşmadan planlanmasını ve tamamlanıp teslim edilmesini gerekli kılar. Bu da literatürde farklı yazılım geliştirme modellerinin doğmasına sebep olmuştur. Yazılım çeşitlerinin gelişmeye başlaması ile birlikte yazılım geliştirme modellerinin de çeşitlenmesi sonucunda kod eksenli geliştirme modeli, doğrusal geliştirme modelleri, yinelemeli geliştirme modelleri, çevik geliştirme modelleri, modüler geliştirme modelleri ve servis tabanlı geliştirme modeller, gibi farklı yazılım geliştirme modelleri ortaya çıkmıştır.

bu bölümde en çok kullanılan bu yazılım geliştirme modelleri, aralarındaki farklar, önemli noktaları, kendilerine özgü özellikleri anlatılacaktır.

 

5. 1. Kod Eksenli Geliştirme Modeli

Kimi zaman “kodla ve düzelt” olarak da adlandırılan bu yaklaşım, kullanıcının istediğini hemen gerçekleştirmeye çalışan plansız bir yaklaşımdır ve esasında çoğu kişi tarafından bir model olarak da görülmez. Buna karşın pratik olmasından dolayı sıklıkla kullanılır.

Bu yaklaşımda proje ihtiyaç analizi tam olarak bitmeden veya ihtiyaç analizi kısmen tamamlandıktan sonra tasarım yapmadan hemen kodlamaya başlanır. Sistemin baştan düzgün bir şekilde tasarlanmaması, sonraki aşamalarda sürekli değişim ve sorunlara sebep olur.

Bu sorunları düzeltmeye çalışan yazılım geliştiriciler kullanıcı ihtiyaçlarını anlamakta zorluk çekmeye başlar. Bu yaklaşım eğitim gerektirmez ve müşteri beklentisine uygun olarak üretime ve geliştirmeye hemen başlanmış izlenimi verir. Bu yaklaşımda geliştirme süreci görünürde analiz, tasarım ve kodlama şeklindedir ancak birçok projede farkında olmadan analiz ile tasarım birleştirilir. Bu yaklaşım genellikle plansız ve kısa vadeli olarak çalışan ortamlarda kullanılan, hemen bir işin tamamlanması hedeflenen, işle ilgili analizlerin yapılmadı bir yaklaşımdır. Bazı kısa vadeli planlar yapılsa da bu planlar da kullanıcı istek ve hata düzeltmeleriyle sürekli bölünerek bir süre sonra geçerliliğini yitirir. Bu yaklaşımda sağlıklı bir yönetimden bahsetmek mümkün değildir. Bu modelin olumlu ve olumsuz yanları aşağıda (Şekil 8) sunulmuştur.

Şekil 8. Kod Eksenli Geliştirme Modeli Olumlu – Olumsuz Yanları

5. 2. Doğrusal Geliştirme Modelleri

Doğrusal Geliştirme Modelleri, yazılım sürecindeki aşamaların, birbirini ileriye doğru takip ettiği ve fazla bir geri dönüş yaşanmayacağı varsayımından yola çıkarak önerilen modellerdir. Yazılım geliştirmede en sık kullanılan model türü olarak kabul edilebilir. Bu ana kategori içerisinde yer alan modeller, diğer bazı modellerle hibrit (melez) yapılar da oluşturabilir ve bir projede tamamen kullanılmasa da belli kısımlarında kullanılabilir.

Bu modellerin en ünlüleri “Şelale Modeli” ve “V Model”dir.

5. 2. 1. Şelale Modeli

Şelale Modeli’nde yazılımların sırasıyla planlama, analiz, tasarım, gerçekleştirme, test ve devreye alma aşamalarından oluştuğu ve projenin ilk aşama olan planlama aşamasından son aşama olan devreye alma aşamasına kadar doğrusal bir şekilde ilerlediği, pek fazla osilasyon yapmadığı kabul edilir. Planlama aşamasında daha önceki bölümlerde açıklanan kapsam planı, entegrasyon planı, risk planı, zaman planı, kaynak planı, maliyet planı, kalite güvence planı, test planı, eğitim planı ve devreye alma planı gibi planların arasından uygun olanların gerçekleştirilmesi hedeflenmektedir. Analiz aşamasında kullanıcı ihtiyaçları ve istekleri, ardından bu istek ve ihtiyaçları yerine getirebilmek için yazılım ekibinin ihtiyaç ve istekleri analiz edilir. Yazılımın iki tarafı arasında yapılacaklar konusunda anlaşmaya varıldıktan sonra tasarım aşamasına geçilir. Tasarım aşamasında genellikle yazılımın veri tabanı yapısı, sorgular, akış şemaları, UML şemaları, Gantt şemaları, arayüzler, kod modülleri arasındaki ilişkiler gibi teknik tarafları ve dokümantasyonu tasarlanır. Bu tasarım tamamen doğru ve bitmiş kabul edilerek gerçekleştirme aşamasına başlanır. Gerçekleştirme aşaması, kodların implemente edildiği bir aşamadır. Test aşaması; yazılımların, yan ürünlerin, dokümantasyonların ve bir yazılım projesinde yer alan tüm elemanların çeşitli açılardan test edildiği aşamadır. Yazılımlarda sıklıkla gerçekleştirilen bazı test çeşitleri güvenlik testleri, performans testleri, kullanıcı kabul testleri, uyumluluk testleri ve entegrasyon testleridir. Tüm bu aşamalar tamamlandıktan ve yazılımın başarılı bir şekilde tamamlandığına ve müşteri isteklerine uyumlu olduğuna kanaat getirildikten sonra yazılımın müşterinin sistemlerine yüklenmesi anlamına gelen devreye alma aşamasına geçilir. Bu modelin sağlıklı çalışabilmesi için ihtiyaç analizinin değişken olmaması ve projenin ilk aşamasında analizin büyük ölçüde tamamlanması gerekir. Görsel 5.1’de Şelale Modeli yapısı gösterilmiştir.

Görsel 5. 1. Şelale Modeli Yapısı

Şelale Modeli ilk anda yapılacakların tümünün planlanmasını hedef alan bir modeldir ancak yazılım projeleri çok değişken bir yapıya sahip oldukları için bu genellikle mümkün olmaz ve daha sonraki süreçlerde ciddi sapmalar görülür ve bu sapmalar planın takibini zorlaştırır. Bu sorunları gidermek için analiz ve tasarım gibi her aşamanın başında plan tekrar gözden geçirilip ayrıntılı hale getirilmelidir. Şelale Modeli kullanılan projelerde ana gözden geçirme noktaları plan içerisinde aşamaların başlarına veya sonlarına eklenmelidir. Bu modelin olumlu ve olumsuz yanları aşağıda (Şekil 9) sunulmuştur.

Şekil 9. Şelale Modeli Olumlu – Olumsuz Yanları

5. 2. 2. V Model

V Model, Şelale Modeli’nin kontrol safhaları daha organize edilmiş hali olarak görülebilir. Her aşama kendi kontrol aşamasıyla eşleştirilerek “V” harfine benzer şekilde gösterildiği için bu isme sahip olan modelde analiz ile kabul testi, tasarım ile sistem bütünleştirme testi, kodlama ile birim testi eşleştirilmiştir. V Modelin yazılımın geliştirme aşamalarının tanımlanma şekline göre birçok gösterimi vardır. Görsel 5.2’de V Modelin yapısı gösterilmiştir.

Görsel 5. 2. V Model Yapısı

Bu modelin olumlu ve olumsuz yanları aşağıda (Şekil 10) sunulmuştur.

Şekil 10. V Model Olumlu – Olumsuz Yanları

5. 3. Yinelemeli Geliştirme Modelleri

Yinelemeli, iteratif veya aşamalı modeller olarak isimlendirilen bu modeller yazılımı tek bir defada değil, çeşitli sürümlere bölerek geliştirmeyi hedefler. Özellikle günümüzün büyük çaplı yazılımları için uygun bir yaklaşımdır. Genel olarak yapılan işlem; seçilmiş bir özellikler kümesini içeren temel bir sürüm geliştirmek, sonra bu sürüme adım adım yeni özellikler ekleyerek kullanıcının ihtiyacını karşılayacak nihaî sürümlere ulaşmaktır.

Yinelemeli modelde tekrar olgunlaşmayı, artım ise gelişmeyi sağlar. Yinelemeli bir model kullanıldığında kullanıcı yazılımı daha erken kullanmaya başlayabilir. Sürümler adım adım test edilerek olgunlaşacağından hatalar kolay bulunur. Belirsizliklerin fazla olduğu ilk aşamada ihtiyaç analizi ve tasarımın tek seferde oluşturulmasının ortaya çıkardığı riskler azalır. Yazılım geliştirme ve oluşturma yükü, aşamalar arasında paylaştırıldığından yazılım ekibi üzerindeki planlama baskısı da azalır. İstenen sürede yazılımın tümünün bitirilemeyeceği açıksa proje aşamalara bölünür. Bu modellerin ortak olumlu ve olumsuz yanları aşağıda (Şekil 11) sunulmuştur.

Şekil 11. Yinelemeli Geliştirme Modelleri Olumlu – Olumsuz Yanları

En çok kullanılan yinelemeli modeller:Artımlı Geliştirme Modeli, Evrimsel Geliştirme Modeli ve Sarmal Model’dir.

5. 3. 1. Artımlı Geliştirme Modeli

Artımlı Geliştirme Modeli, ihtiyaç analizi büyük ölçüde belli olduktan sonra yazılım geliştirme sürecindeki işlemin sürümlere bölünerek ve her sürümde ihtiyacın bir kısmı karşılanarak gerçekleştirilmesidir. Bu modeli kullanan yazılım ürünü her sürümde yeni eklenen özelliklerle daha gelişmiş hale gelir. Görsel 5.3’te Artımlı Geliştirme Modeli yapısı gösterilmiştir.

Görsel 5.3. Artımlı Geliştirme Modeli Yapısı

Toplam proje süresine göre değişmekle beraber genellikle birkaç haftada bir, sistemin çalışan yeni sürümü ortaya çıkartılır. Sürümler geliştirilir, test edilir ve kullanıcılara veya proje ekibine gösterilir. Bu sayede hataların kısa sürede ortaya çıkması ve sürecin sürekli islenmesi sağlanır. Elbette burada sürümlerin özelliklerinin hedef kitle göz önüne alınarak belirlenmesi gerektiği belirtilmelidir. Bu sürümler arasında bazı sürümler proje ekibinin, bazı sürümler kurum üst yöneticilerinin, bazı sürümler ise da son kullanıcıların ihtiyaçlarına yönelik geliştirilir. Artımlı geliştirmede proje planı; sürümlerin özellikleri, sürüm oluşturma sıklığı, sürüm tamamlama tarihleri ve bunların birbirleriyle bağlantıları düşünülerek yapılmalıdır.

Bu yöntemin olumlu ve olumsuz yanları aşağıda (Şekil 12) sunulmuştur.

Şekil 12. Artımlı Geliştirme Modeli Olumlu – Olumsuz Yanları

5. 3. 2. Evrimsel Geliştirme Modeli

Evrimsel Geliştirme Modeli; projenin ihtiyaç analizinden başlayarak geliştirme ve teste kadar tüm aşamaları içine alan ve giderek büyüyen çevrimler şeklinde geliştirilmesidir.

Her çevrim önceki çevrimlere bağlantılı küçük bir şelale modeli gibidir. Görsel 5.4’te Evrimsel Geliştirme Modeli yapısı verilmiştir.

Görsel 5. 4. Evrimsel Geliştirme Modeli Yapısı

Evrimsel Geliştirme Modeli’nde her sürümde tekrar ihtiyaç analizi yapılır. Projenin her aşamasında kapsamlı değişiklikler istenmesi durumuna karşı üretilmiş bir çözümdür.

Bu sebeple her çevrimin (proje süresine göre değişmekle birlikte) en fazla bir ay gibi kısa sürelerde yapılması önerilir. Her çevrim sonucunda kapsamlı bir doğrulama ve onaylama çalışması gerekir. Bu modelin olumlu ve olumsuz yanları aşağıda (Şekil 13) sunulmuştur.

Şekil 13. Evrimsel Geliştirme Modeli Olumlu – Olumsuz Yanları

5. 3. 3. Sarmal (Spiral) Model

Sarmal (Spiral) Model, Yinelemeli Geliştirme Modelleri ve Şelale Modeli’nin genel üstünlüklerini risk temelli bir yaklaşımla birleştirir. Bu modelin iki temel özelliği olduğu kabul edilir:

• Sistem netleşir, anlaşılır ve gerçekleştirilen kısmı büyürken risk azalır.

• Tanımlanan kilometre taşları vasıtasıyla geliştirilen sistemin ihtiyaçlarıyla uygunluğu konusunda müşterilerle mutabakat sağlanır ve böylece müşteri memnuniyeti artar.

Bu modelde her sürüm bir dairesel çevrimdir ve geliştirilmesi kendi içerisinde Şelale Modeli özelliği taşır. İlk sürümler daha çok prototip ve kullanıcı ihtiyaçlarını anlamayı hedeflerken sonraki sürümler geliştirilmesi düşünülen uygulamaya yakın özel fonksiyonlara sahip olmaya başlar. Modelde her sarmal (spiral), yaklaşık eşit gösterilmekle birlikte projede yapılması planlananlara göre gerçek hayatta bazı sarmallar (spiraller) daha dar, daha geniş veya düzgün olmayan şekillerde olabilir. Bu modelde sarmal (spiral) modelde sistem bir seri evrimsel sürüm şeklinde geliştirilir, daire yayının uzunluğuna dayalı uzaklık o tarihe kadar ki bitirilen işler için harcanan toplam maliyeti, açısal uzaklık sarmalın her dönüşünü tamamlamayla sağlanan ilerlemeyi gösterir. Görsel 5.7’de Sarmal (Spiral) Model yapısı gösterilmiştir.

Görsel 5. 7. Sarmal (Spiral) Model Yapısı

Bu modelde sarmalın (spiralin) her çevrimi için risk analizini de içeren bir tablo da kullanılır. Döngü yazılımla iyileştirilebilecek özel kurumsal işlerin varlığına dayanan bir varsayım ve risk analiziyle başlar. Riskleri azaltacak bir planlama yapılır. Tablo 5.7’de yeni devreye alınacak örnek bir avans projedeki ilk sarmalda (spiralde) yapılacak işlemleri ifade edecek şekilde doldurulmuştur. Alternatifler kısmı, her aşamada seçilebilecek farklı yöntem ve araçları göstermektedir. Örneğin istihdam kalemi kendi yapmak veya satın alma arasındaki seçimi gösterir. Her aşama ayrıntılı bir gözden geçirme aşamasıyla sonlanır. Tablo 5.7’de bu tabloya bir örnek verilmiştir.

Tablo 5.7. Yeni Devreye Alınacak Örnek Bir Avans Projedeki İlk Sarmalda Yapılacak İşlemler Örneği

Amaçlar	Personelin avans alma işlemini elektronik ortama taşıyarak hızlandırmak için personel avans giriş yazılımı
Kısıtlar	Belirlenmiş uygun bir maliyet ve sürede şirket kültürüne uygun bir şekilde üst yönetimin kullanabileceği pratiklikte geliştirilmesi
Alternatifler	Yönetim: Proje, kurum, politika, planlama Personel: İstihdam, Eğitim Teknoloji: Entegre yazılım geliştirme ortamı, veri tabanı
Riskler	Analizin hatalı yapılması
Risk çözümlemeleri	Prototiplerle analizin gözden geçirilmesi
Sonraki aşamanın planı	Avans talep işleminin iş akış ortamına taşınması
Yapılması onaylanan işler	Personel giriş ekranı ve raporu, avans giriş ekranı

Sarmal (Spiral) modelin olumlu ve olumsuz yanları Şekil 14’te verilmiştir.

Şekil 14. Sarmal (Spiral) Model Olumlu – Olumsuz Yanları

5. 4. Çevik Geliştirme Modelleri

Çevik Geliştirme Modelleri, süreç ve belgeleme yerine doğrudan yazılımın kendisine yoğunlaşan ve yinelemeli geliştirmeye dayanan tekniklerdir. Çevik Geliştirme Modelleri’nin temel prensipleri şu şekilde ortaya konmaktadır:

• Kişiler ve kişilerarası etkileşime, süreç ve araçtan daha çok önem verilir.

• Çalışan yazılıma ayrıntılı belgelemeden daha çok önem verilir.

• Müşteriyle doğrudan iletişim dolaylı yollara tercih edilir.

• Planı katı şekilde takip etmek yerine değişimlere cevap verilir.

Çevik Geliştirme Modelleri’nde projenin süresine göre değişmekle beraber her tekrarın süresi çok kısa, hatta bir gün bile olabilir. Çevik Geliştirme Modelleri’nin birçok alt modeli bulunmaktadır. Bu modeller genel hatları ile aşağıdaki şekilde tanımlanmıştır:

• Aşırı Programlama (Extreme Programming): Aşırı Programlama sadece bir sonraki artımda geliştirilecek gereksinimler tanımlanır ve her artım genellikle bir aydan daha kısa sürede tamamlanır.

• Scrum: Scrum modelde geliştirme süreci bir aydan kısa süren koşulara bölünür. Scrum kullanıldığında Şelale Modeli’ne benzer şekilde müşteri istekleri bir koşul içinde değiştirilemez.

Çevik Geliştirme Modelleri’nde proje, kısa süreli plan ve anlık kararlarla ilerlediğinden yönetim proje yöneticisinin kişisel saygınlık ve etkinliğine bağlıdır ancak son yıllarda teknolojideki hızlı değişime cevap verebilmek için aşırı esneklik gerekmesi, bu süreçlerin CMMI (Capability Maturity Model Integrated – Entegre Yeteneklilik Olgunluğu Modeli) gibi resmî belgeye dayalı süreç yönetim modelleri içerisine dahi eklenmesine sebep olmuştur. Böylece Çevik Geliştirme Modelleri daha kurallı bir yapıya kavuşmuş ve yönetimi kolaylaşmıştır. Çevik yöntemlerin birçok ilkesi vardır bu ilkeler:

• Yazılımın en önemli önceliği, değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.

• Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir.

• Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.

• İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdır.

• Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.

• Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüz yüze iletişimdir.

• İlerlemenin birincil ölçütü çalışan yazılımdır.

• Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmelidir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.

• Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.

• En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.

• Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Bu modellerin olumlu ve olumsuz yanları aşağıda (Şekil 15) sunulmuştur:

Şekil 15. Çevik Geliştirme Modelleri Olumlu – Olumsuz Yanları

5. 5. Modüler Geliştirme Modelleri

Modüler Geliştirme Modelleri, yazılımları tek bir parça olarak değil; birçok bütünleşik parçadan oluşacak şekilde düşünür ve geliştirir. Modül kendi içinde bütünlüğü olan ve gerekirse tek başına çalışabilecek büyük ölçekli yazılım parçası olarak tanımlanabilir. Günümüz yazılımlarının çok büyük çaplı olarak düşünüldüğünde modüler yapıların ne kadar önemli olduğu net bir biçimde görülebilir. Büyük bir sistemi en başından küçük sistemlere bölmek, bu sistemi hiyerarşik olarak bölüp yönetmekten farklıdır. Modüler yöntemde analizin ilk hedefi yazılımın bütünleşik parçalarını yani modüllerini tespit etmektir. Bu aşamadan sonra her modül ayrı bir proje olarak ele alınır. Her biri için ayrı bir ekip oluşturulabilir. Sonrasında her modül doğrusal veya yinelemeli gibi istenen bir yöntemle planlanır ver gerçekleştirilir. Bu modellerde planın basitleşmesi, izlenebilmesi için anlamlı parçalara bölünmesi gerekir. Modülerlik ekibin yönetimini kolaylaştırır. Büyük projelerde yüzlerce hatta binlerce kişiden oluşan ekipler vardır. Böylesi bir ekibi yönetebilmek için daha küçük ekiplere bölmek gerekir. Ekip modül yapısına göre bölünebilir. Her modülü ayrı bir ekip geliştirir. Her ekibe ayrı bir yönetici atanabilir.

Aynı mekânda çalışma imkanı olmayan ekipler de farklı modüllerde görevlendirilerek iletişim sorunları azaltılabilir. Bu modellerin olumlu ve olumsuz yanları aşağıda (Şekil 16) sunulmuştur:

Şekil 16. Modüler Geliştirme Modelleri Olumlu – Olumsuz Yanları

5.6. Servis Tabanlı Geliştirme Modelleri

Yazılım platformları arası iletişim ve entegrasyon, yazılım dünyasının en önemli sorunlarından birisidir. Bu ihtiyaca çözüm olarak firmalar Corba (Common Object Request Broker Architecture – Ortak Nesne İstem Aracısı Mimarisi) ve Microsoft COM (Component Object Model) gibi birçok öneri sunmuştur. Bu öneriler çeşitli uygulama ihtiyaçlarına cevap vermekle birlikte firmaya bağımlı ve zor kullanıldıkları için herkesin kabul ettiği standartlar haline gelememiştir. Son yıllarda internetin gelişmesiyle birlikte web servisi yazılımlar arası iletişim ve entegrasyonda en fazla tercih edilen çözüm olmuştur. Servis, verilen bir web adres üzerinden standart bir mesajlaşma protokolüyle çağırılabilen platform bağımsız bir yazılım bileşenidir ve tüm yapı XML (Extensible Markup Language – Genişletilebilir İşaretleme Dili) dili üzerine standartlaştırılmıştır. Bu standart yapı sayesinde servis, kod değişikliğine gerek kalmaksızın farklı platformlarda geliştirilen uygulamalardan kolayca çağırılabilmektedir. Servis Tabanlı Mimari, analizden tasarıma ve koda dönüşümü sağlayan araçlar da içermektedir. Bu araçlar temelde üç seviyededir:

• BPA: (Business Process Analysis – İş Süreç Analiz Araçları): İş analizlerinin şematik gösterimiyle yapıldığı görsel araçlardır. Hedefleri sadece analizin yapılmasıyla sınırlıdır. Analizin yazılıma dönüşmesi elle (manuel) veya harici araçlarla yapılmaktadır.

• BPM: (Business Process Management – İş Süreç Yönetim Araçları): İş analizlerinin yazım şeklinde yapıldığı ve iş akışlarını çalıştırma ortamı sunan araçlardır.

• BPMS: (Business Process Management Suite – Bütünleşik İş Süreç Yönetim Araçları): Analizden kodlamaya kadar tüm işlemleri bütünleşik olarak servis altyapısında sunan araçlardır.

Bu modelin olumlu ve olumsuz yanları aşağıda (Şekil 17) sunulmuştur.

Şekil 17. Servis Tabanlı Geliştirme Modelleri Olumlu – Olumsuz Yanları

 

Bölüm Özeti

•  Bir yazılım projesini geliştirmek konusunda pek çok farklı yazılım geliştirme modeli söz konusudur. Bu modeller temel olarak Kod Eksenli Yazılım Geliştirme Modeli, Doğrusal Geliştirme Modelleri, Yinelemeli Geliştirme Modelleri, Çevik Geliştirme Modelleri, Modüler Geliştirme Modelleri ve Servis Tabanlı Yazılım Geliştirme Modelleri olarak gruplandırılabilir. Her ana grubun altında birçok alt model mevcuttur. Her modelin kendine özgür olumlu ve olumsuz yanları bulunmaktadır. Bir yazılım için hangi modelin/modellerin uygun olduğuna karar vermek için bu olumlu/olumsuz yanlara bakılabilir. Bu sayede bir yazılımın özellikleri, geliştirileceği alan, hedef kitlesi, zaman ve maliyet özellikleri, teknolojik özellikleri gibi unsurlara ve modellerin sahip olduğu özelliklere bakılarak uygun yazılım için uygun model eşleştirmesi yapılabilir. Bu modeller aşağıda kısaca açıklanmıştır:

▶ Kod Eksenli Geliştirme Modeli: Kimi zaman “kodla ve düzelt” olarak da adlandırılan bu yaklaşım, kullanıcının istediğini hemen gerçekleştirmeye çalışan plansız bir yaklaşımdır. Çoğu kişi tarafından bir model olarak da görülmez. Buna karşın pratik olmasından dolayı sıklıkla kullanılır.

▶ Doğrusal Geliştirme Modelleri: Yazılım sürecindeki aşamaların, birbirini ileriye doğru takip ettiği ve fazla bir geri dönüş yaşanmayacağı varsayımından yola çıkarak önerilen modellerdir. Yazılım geliştirmede en sık kullanılan model türü olarak kabul edilebilir.

▶ Yinelemeli Geliştirme Modelleri: Bu modeller yazılımı tek bir defada değil, çeşitli sürümlere bölerek geliştirmeyi hedefler. Özellikle günümüzün büyük çaplı yazılımları için uygun bir yaklaşımdır.

▶ Çevik Geliştirme Modelleri: Süreç ve belgeleme yerine doğrudan yazılımın kendisine yoğunlaşan ve yinelemeli geliştirmeye dayanan tekniklerdir. Çevik geliştirme modellerinde projenin süresine göre değişmekle beraber her tekrarın süresi çok kısa, hatta bir gün bile olabilir.

▶ Modüler Geliştirme Modelleri: Yazılımları tek bir parça olarak değil, birçok bütünleşik parçadan oluşacak şekilde düşünen ve geliştiren modellerdir. Büyük bir sistemi en başından küçük sistemlere bölmek, bu sistemi hiyerarşik olarak bölüp yönetmekten farklıdır. Modüler yöntemde analizin ilk hedefi yazılımın bütünleşik parçalarını yani modüllerini tespit etmektir.

▶ Servis Tabanlı Geliştirme Modelleri: Yazılım platformları arası iletişim ve entegrasyonu ele alan modellerdir. Servis tabanlı mimari, analizden tasarıma ve koda dönüşümü sağlayan araçlar da içermektedir.

 

Kaynakça

Barutçugil, İ. (2008). Proje Yönetimi. Kariyer Yayınları.

Çevik Yazılım Geliştirme Manifestosu, http://agilemanifesto.org/iso/tr/manifesto.html, 20.04.2017.

Gencer, C. ve Kayacan, A. (2017). Yazılım Proje Yönetimi: Şelale Modeli ve Çevik Yöntemlerin Karşılaştırılması. Bilişim Teknolojileri Dergisi, Cilt: 10, Sayı: 3, Sayfa: 335 – 352.

Goldratt, E. M. ve Cox, J. (2006). Amaç. Optimist Yayın Dağıtım.

Naghizade, K. ve Erkollar, A. (2020). Yazılım Projelerinde Kullanılan Proje Yönetimi Standartları ve Karşılaştırmaları.4th International Student Congress – 4. Uluslararası Öğrenci Kongresi, Sayfa 483 – 489.

Project Management Institute (2017). A guide to the Project Management Body of Knowledge (PMBOK guide).

Türkan, Y. S. (2015). Proje Yönetiminde Planlama ve Kontrol Teknikleri. Doğu Kütüphanesi Yayınevi.

Yılmaz, H. Ç. (2018). Çevik Proje Yönetiminin Teknoloji Sektöründe Prince2 Proje Yönetim Metodolojisi İle Karşılaştırılması. Maltepe Üniversitesi Sosyal Bilimler Enstitüsü Yüksek Lisans Tezi.