Anasayfa > Analiz, İş Hayatına Dair > Yazılım Geliştirme Sürecinde Geliştirme Aşaması!!!

Yazılım Geliştirme Sürecinde Geliştirme Aşaması!!!

  • Yazılım geliştirme sürecinin ilk aşaması Gereksinim Analizi’dir.
    Bu aşamada, geliştirilecek yazılımın işlevsel ve operasyonel gereksinimleri belirlenir. Bu gereksinimler Yazılım Gereksinim Tanımları (YGT) ve Arayüz Gereksinim Tanımları (AGT) dökümanları ile belgenir. Belirlenen gereksinimler, geliştirme sürecinin her aşamasında ileriye ve geriye dönük olarak izlenir. Böylece her aşamada geliştirilen ürünlerin gereksinimlerle uyumluluğu sağlanır.

indir

  • Ön Tasarım aşamasında YGT ve AGT’den yola çıkılarak geliştirilecek yazılımın ön tasarımı yapılır.
    Ön tasarım yapılırken, MilSOFT tasarım kriterlerine uyulur. Ön tasarımın sonuçları Yazılım Tasarım Tanımları (YTT) ve Arayüz Tasarım Tanımları (ATT) dökümanları ile belgenir.

  • Ayrıntılı Tasarım aşamasında, yazılımın ayrıntılı tasarımı yapılarak, gerçeklemeye hazır duruma getirilir.
    Ayrıntılı tasarım aşamasının sonuçları, ön tasarım aşamasında üretilen YTT ve ATT dökümanlarına yeni bölümler eklenerek belgelenir. Eğer yazılım sistemi bir veritabanı da içeriyorsa, veritabanının yapısı Veritabanı Tasarım Tanımları (VTTT) dökümanı ile belgelenir.
  • Gerçekleme aşamasında, YGT, AGT, YTT ve ATT dökümanlarından yararlanılarak yazılımın gerçeklemesi yapılır.
    Gerçekleme aşaması; kodlama, derleme, hata ayıklama, insan makina arayüzlerinin oluşturulması, veritabanlarının tanımlanması ve gerekli verilerin bu veritabanlarına doldurulması gibi faaliyetleri kapsamaktadır. Kodlama sırasında her yazılım biriminin konfigürasyon yönetimi yapılır.
  • Birim Testi aşamasında, gerçeklenen her yazılım birimi, diğer birimlerden bağımsız olarak izole birim testinden geçirilir.
    Bu test sırasında, Test Kontrol Listesi hazırlanır ve birimin bu listedeki kriterlere uygunluğuna bakılır. Birim testini geçen yazılım birimleri Birim Bütünleştirme aşamasında bütünleştirilirler. Bu noktada Bütünleştirme Testleri yapılır.

Her aşamada ortaya çıkarılan yazılım ürünlerinin, projenin yazılım geliştirme planına göre Gözden Geçirmesi yapılır. Gözden Geçirme faaliyetini ürünün geliştirilmesinde rol almayan yazılım ya da sistem mühendisleri gerçekleştirir. Gözden Geçirme hem geliştirilme aşamasındaki hem de geliştirilmesi tamamlanmış ürünlere uygulanır. Gözden Geçirmenin temel amacı, üründeki hataları mümkün olduğu kadar erken ortaya çıkarmak ve ürünün hatasız olmasını sağlamaktır.

Geliştirilen yazılım ürünleri, kontrata bağlı olarak müşteri ile birlikte de gözden geçirilir. Bu sayede müşteriden geliştirme faaliyetleri devam ederken geri besleme alınır ve müşterinin de geliştirme sürecine katılması sağlanır.

Günümüz ‘Yazılım Geliştirme’ sürecinde hedeflenen amaçlar:

1)     Üretim döngüsünde yazılım maliyetlerini azaltmak,

2)     Üretilen yazılımın kalitesini arttırmak,

3)     Üretici ve kullanıcı arasındaki iletişimi arttırarak istenilen seviyede ürün elde edilmesi

Şeklinde sıralanabilir.

Bu amaçlara ulaşılabilmesi için gerekli koşullar aşağıdaki gibidir:

1) Prosedür:

Ne yapılması gerekiyor?

Burada yazılım geliştirme süreciyle ilgili nelerin yapılması gerektiği, bunların sonucunda sonuçların neler olacağı ve bu sonuçların detaylı analizinden sonra hangilerinin olmazsa olmaz (proje açısından kritik) olduğunun karar verilmesi aşamasıdır.

2) Metotlar:

Amaca nasıl ulaşabiliriz?

Burada belirlenmesi gereken ana hususlar, ilk seviye aktiviteleri, bunların sonuçları ve iş sahiplerine yapılacak sunuş yöntemleri şeklindedir.

3)     Araç Gereksinimleri

Amaca ulaştıracak araçlar nelerdir?

Burada değişik karakteristik özelliklerine göre hangi araçların yazılım geliştirme sürecinde kullanacağı ve bunların maliyet/performans analizlerinin tamamlanması aşamasıdır.

Bütün bu yukarıdaki aşamalar seviyesinde ana aktivite alanları ise:

  1. Yazılım Geliştirme
  2. Kalite Kontrol
  3. Konfigürasyon Yönetimi
  4. Proje Yönetimi

Şeklindedir.

Toparlayacak olursak bir yazılımın ilk seviye geliştirilmesi hususunda gerekli ve temel şartlar yukarıda sıralandırılmıştır. Bu seviyeleri ve aktiviteleri uygulanabilirlik koşullarında sağlayan değişik süreçler ve terminolojiler tanımlanmıştır. Bahsedilen süreçler açısından uygulanabilirliği en kolay olan ve gerektirdiği maliyetler açısından en uygun olan model V-Modeli’dir. V-Modeli yazılım geliştirme sürecini koordine eden bütünleşik ve birleştirici methodların toplamıdır. Ana aktivite alanlarının birbirleri arasında koordinasyonunu sağlayan, tüm aktiviteleri içerik bakımından tanımlayan, proje kapsamında üretilecek tüm yazılım hakkında dokümentasyon bilgileri içeren ve bu dokümentasyonlar hakkında detaylı açıklama getiren ve son olarak da her seviye arasında problemin tanımlandığı andan ürün sürümüne kadar geçen tüm aşamalarda içsel kontrollü bir methodolojiler toplamıdır.

 Yazılım Geliştirme Süreç Modelleri

En çok ismi geçen yazılım geliştirme süreç modeli “ŞELALE” (Waterfall)dır

En önemli dezavantajı, bir safhanın tamamlandığına karar verildikten sonra o safhaya geri dönmenin zor olmasıdır. Örnek olarak, gerekler safhası tamamlanıp tasarım safhasına geçildiği zaman, yazılım gereklerinin tamamen belirlendiği kabul edilmekte ve gerekler sabitlenmektedir. İlk seferde gereklerin tam, doğru ve eksiksiz olarak belirlendiğini düşünmek genelde gerçeği yansıtmamaktadır. Projeyi bu modelde olduğu gibi esnek olmayan safhalara ayırmak doğru değildir. Bu nedenlerden dolayı, sadece gereklerin tam ve kesin olarak belirlendiği projelerde (ki böyle müşteri isteklerinin ve gereklerin başlangıçta sabitlenebildiği projeler pek görülmez) bu model kullanılabilmektedir. Bu model kullanıp, ilk versiyon teslimat safhasına geldiğinizde yeni bir yazılım gereğine cevap vermeniz pek mümkün olamayabilir çünkü bütçenin %90’ına yakınını sarf etmiş olabilirsiniz.

Bir diğer model ise “PROTOTİP” kullanımıdır. Bu model hakkında geniş bilgiyi “Yazılım Geliştirme Süreci ve Prototipler” başlıklı yazımda vermiştim.

Çoğu yazılım projelerinde evrimsel bir süreç işlemektedir. Safhalar tekrarlanarak yazılım ürünü sürekli geliştirilmektedir. Bu yaklaşım ile ilgili farklı 2 model öne çıkmaktadır. Bunlarda ilki “ARTIMSAL” yazılım geliştirme süreç modelidir, diğeri ise “SPİRAL” modeldir.

Artımsal modelde, tek teslimatta tüm sistemi teslim etmektense, sistemi fonksiyonel birimlere ayırtıp, teslimatları ARTIMSAL fonksiyonel birimler halinde yapmak tercih edilir. Bu modellemede, kullanıcı gerekleri önceliklendirilir ve önceliği yüksek olan gerekler ilk versiyon teslimatlarda müşteriye sunulur. Bir ARTIMın geliştirilmesine başlandığında bir sonraki artıma kadar kullanıcı gereklerinin donduğu (değişmediği) kabul edilir. Bu model ile, her yeni gelecek kullanıcı isteği artımsal olarak sisteme eklenebilmektedir.

Artımsal modelin en büyük avantajı, müşterinin süreç içerisinde daha fazla yer almasının sağlanabilmesidir. Kullanıcı, sistemin gereklerinin tek tek yerine getirildiğini gözlemleyebilmekte, varsa değişiklik önerisini hemen verebilmektedir. Örneğin ŞELALE modelinde, müşteri son safhaya kadar sistemi görememekte, sürece katılımı minimum düzeyde kalmakta idi. Doğru yazılım ürünlerinin geliştirilebilmesi için müşterinin yeterli düzeyde süreç içerinde yerini alması ve sürece katılması gerekmektedir. Bu kural PROTOTİP modelinde bir ölçüde yerine getirilebilmekte, bununla beraber evrimsel süreçlerde tam anlamı ile gerçekleştirilebilmektedir. Müşterinin süreç içerisinde yerini alması projenin başarısızlık riskini azaltan bir olaydır. Bu modelin bir diğer avantajı ise, yüksek öncelikli gereklerin erken geliştirilerek, daha fazla test edilebilmesine olanak sağlanmasıdır.

Süreç içerisinde yer alan aktivitelerin zincirleme olarak gelişmesinden farklı olarak SPİRAL şeklinde de gerçekleşmesi mümkündür. Bunlar sırasıyla;

  1. Yaşam Döngüsü Planı
    2. Gerek Planı
    3. Geliştirme Planı
    4. Entegrasyon ve Test Planı
    5. Kapsam
    6. Gereklerin Belirlenmesi ve Geçerlilenmesi
    7. Tasarım ve Geçerlileme
    8. Entegrasyon, Ünite Testleri ve Kabul Testleri
    9. Son ÜrünÖzellikleri sabitlenmiş hiçbir tur yoktur. Turun başında yapılan risk analizi ve bir önceki tur sonunda yapılan değerlendirme sonucunda, turun safhası (özellikleri) ortaya çıkmaktadır. Süreç içerisinde o an neye ihtiyaç duyuluyorsa, ihtiyacı karşılamak üzere tur atılır. Her bir tur için çeşitli hedefler konulmakta ve gerçekleştirilmeye çalışılmaktadır. Turun başlarında yapılan risk analizi ile projenin başarısızlık riski azaltılmaktadır.

    Son olarak “TEKRAR KULLANIM” (RE-USE) modelinden kısaca bahsedeceğim. Organizasyon tarafından daha önce hazırlanmış veya dışarıdan temin edilmiş yazılımların (veya yazılım parçalarının) kullanılması ile geliştirme yapılması son yıllarda popülaritesi artan bir yaklaşımdır. Organizasyonların olgunlukları arttıkça, bu tür uygulamalar yapabilmek için alt yapı kurulmuş olmaktadır.

    Bu yaklaşımın popülaritesinin sürekli artmasına karşın, yazılım endüstrisinde bu yönde hizmet veren firmalar kısıtlı biçimde yer almaktadır. Örneğin, gerçek zamanlı ve/veya gömülü yazılım geliştiren firmalar için bu yönde kısıtlı (belirli donanımlara özgü) hizmet veren organizasyonlar bulunmaktadır. Bu sürecin aşamaları:
    • Bileşen analizi,
    • Gereklerin modifikasyonu,
    • Tekrar Kullanım ile sistem tasarımı,
    • Geliştirme ve entegrasyondur.

    Büyük sistemlerin geliştirilme süreci esnasında yukarıda bahsettiğimiz yazılım geliştirme modellerinden herhangi biri herhangi bir zamanda kullanılabilir. Böyle bir modellemenin ön gereksinimi, bunun baştan planlanmış, tasarlanmış ve kontrollü şekilde gerçekleştiriliyor olmasıdır. Ön gerekler sağlandığı taktirde, birden fazla model tek yazılım geliştirme planı içerisinde yer alabilmektedir. Bunlar tamamen organizasyonların yapılarına bağlıdır.

    Eğer organizasyonda bir çok takım çıkarabilecek kadar çalışan sayısı ve niteliğine sahip iseniz, artımsal modeli paralel olarak birden fazla takım ile işletebilirsiniz. Benzer şekilde ayrı takımlarda paralel şekilde işleyen ayrı modeller kullanılabilir. Bu noktada, ayrı takımlar tarafından ortaya çıkartılan yazılım ürünlerinin sistem entegrasyonu önem kazanmaktadır. Özellikle yazılım ara yüzlerinin testlerinde dikkatli ve titiz çalışmalar yapmak gerekmektedir.

V-Modelin Avantajları

1)     Sonuç ürünün iş sahipleri tarafından proje başında arzu edilen ürün olması

2)     İçerdiği kaliteli teknik dokümentasyon sayesinde kişilerden bağımsız olması. (Bu sistem ile yazılım geliştirici mühendislerin herhangi bir sebepten dolayı gerek proje üretim aşamasında gerekse sürüm sonrası ayrılmaları durumunda mevcut dokümentasyon ile yeni başlayan mühendislerin hızlı adaptasyonu ile sağlanan kişilerden bağımsızlık)

3)     Paralel yürüyebilecek işlerin aynı zamanlamalarla yapılması sayesinde işin kollektif metotlara göre çok daha hızlı sonuca ulaşması.

4)     Proje sürecinin herhangi bir yerinde iş sahibi tarafından yeni gereksinim istenmesi durumunda bunların projeye kolayca entegrasyonunun sağlanması.

5)     Geliştirme sırasında ortaya çıkabilecek sorun ve  hususların çok daha önceden belirlenebilmesi.

6)     Standartlara bağlı geliştirme süreci sayesinde programın uygulanabilirliğinin yüksek ve modüler yapıda olması.

7)     Sorunsuz bilgi aktarımı sayesinde kolayca uygulanabilen Risk Yönetimi.

8)     İlerideki düşünülebilecek yeni modüllerin mevcut tasarıma uygun ve kolay adapte edilebilir şekilde entegrasyonuna izin vermesi.

9)     Halen yürürlükte olan EURO-METHOD ile birebir uygunluk arzettiğinden Avrupa Birliği standartlarına uygunluk.

10)Avrupa Birliği yüksek güvenlik seviyeli yazılımlar standartlarına uygunluk.

11)Bakım maliyetlerinin en az seviyeye çekilmesi.

YAZILIM UYGULAMA GELİŞTİRME PROJELERİNE ADAPTASYON

 V-Model uygulamalarının en önemli özelliklerinden biri de herhangi büyüklükte ve ölçekteki bir uygulama yazılım projesine adapte edileblir olma özelliğidir.

Bu süreçte takip edilmesi gereken aşamalar ise:

1)     V-Modelinin belirlenmesi,

2)     İş sahipleriyle çalışılarak model hakkındaki tavsiyelerin ve çıkarımların belirlenmesi,

3)     Proje biçimlendirme çalışmaları sırasında:

  1. Gerekli aktivite ve ürünlerin seçilmesi,
  2. Proje için gereken diğer ayarlamaların yapılması,
  3. Proje rehberinin oluşturulması,
  4. Teknik çalışmalar sonucu değerlendirme ve maliyet analizi yapılması,

4)     Proje Planının hazırlanması

Şeklindedir.

Not edilmesi gereken bir husus da yukarıda bahsi geçen rollerin projenin büyüklüğüne göre diğer bazı rollerle birleştirilmesinin mümkün olduğudur. Böyle bir durumda sistemin adı ‘Overloaded V-Model’ anlamına gelen küçük ve orta ölçekli yazılım uygulama projeleri için yüklü V-Modeli’dir.

V-Model Kullanım Alanları:

1)     E-Devlet uygulamaları

2)     Askeri ve Savunma Sanayii Yazılım Projeleri

3)     Finansal Yazılımlar

4)     Anahtar Teslimi Yazılım Uygulama Projeleri

5)     Avrupa Birliği yazılım geliştirme standardına uygun projelerde

 

SONUÇLAR:

Yukarıda anlatılan Yazılım Geliştirme Sürecindeki V-Model metodu günümüz yazılım projelerinde artık standart halini almış, karmaşık ve kompleks sistemlerde başarıyla denenmiş bir metodolojiler bütünüdür.

Bu yazı;bote427.blogcu.com sitesinden alıntıdır.

  1. Henüz yorum yapılmamış.
  1. No trackbacks yet.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Connecting to %s

%d blogcu bunu beğendi: