Blog sayfamızın sayfa düzeni bozulduğu için blog hizmetini  değiştirdik.

Yeni Blog adresimiz: http://bote427.blogspot.com/

Volkan YILDIZ
Fatih UZEL
Kadir KILIÇ

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

a.      Gerekli aktivite ve ürünlerin seçilmesi,

b.      Proje için gereken diğer ayarlamaların yapılması,

c.      Proje rehberinin oluşturulması,

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

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.

 Kaynaklar:

www.btom.org.tr/Duyuru/BTOM-VMODEL.doc

http://www.programlama.com/sys/c2html/view.php?DocID=2081

www.milsoft.com.trsoftware_development_tr.php

Volkan YILDIZ

Fatih UZEL

Kadir KILIÇ

 Tasarım raporu projemizin yapılandırılması, kullanıcı ile içerik arasında bir bağlantı kurulması ve bilginin organize edilmesi üzerinedir. Web site mimarisinde kullanıcı merkezli tasarım düşünülerek sitenin tasarımında ilgili konvansiyon ve protokollere en uygun çözümler üretilmiştir.Detaylı bilgi aşağıda açıklanmaktadır.

Tasarım, algı ile kavram arasında bir bağlama aracıdır. Nesnel gerçeklik ile doğrudan ilişkisi bulunmaz.  Bu nedenle önemsiz ayrıntılar yerine, önemli özelliklere dikkat çeker.  Bunun sonucu olarak ta algılardan genelleştirme yapılarak kanılara varılır.

Bir tasarım kendi içinde bir yapıya ve bu yapı arkasında bir planlamaya sahip olmalıdır. Bütün sanatların temelinde  bir tasarım olgusu bulunmaktadır. Tasarlama eylemi, oluşturulacak yapının organizasyonu ile ilgili her türlü faaliyeti içine almaktadır.

Uygulamalı tasarım dallarını üç ana başlıkta toplamak mümkündür: Endüstri tasarımı, Çevre tasarımı ve Grafik tasarımı. Endüstri tasarımı üç boyutlu nesnelerin tasarlanması ve geliştirilmesiyle ilgilidir. Makineler, araç-gerçler, mutfak malzemeleri ve diğer birçok ürün endüstri tasarımına girer. Çevre tasarımcısı ise bina, peyzaj ve iç mekan tasarımını kapsayan oldukça geniş bir çalışma alanıdır. Bu alanda da  tasarımcını görevi dayanıklı, işlevsel ve estetik olanı bulmaktır. Grafik tasarımcı ise genel olarak, okunan ve izlenen görüntülerin tasarımında sorumludur. Afişler, kitaplar, bilgi ve uyarı işaretleri, broşürler vb. grafik tasarımı etkinlik alanı içine girer.  Grafik tasarımın amacı da gerek iletişim, gerekse estetik kaliteyi en üst düzeye çıkarmaktır.

Tasarım genel olarak site içeriğinin kullanıcıya görsel materyaller kullanılarak aktarılması amacıyla tasarlanır. Kullanıcılar için kullanabilirlik önemli olduğu için tasarım aşamasında bu noktaya dikkat etmemiz gerekir. Tasarımı renk, şekil, doku, biçim, ölçü açısından da dikkate alınmalıdır.

 Tasarım aşamasının bir web sitesinde kodların ve site içeriğinin buluştuğu bir köprü olarak düşünürsek önceki ve sonraki aşamalar arasında önemli rol oynar. Bu yüzden tasarım aşaması iyi analiz edilmelidir.

Tasarımımızın amacı,

• Bölümün tarzına ve hedeflerine uygun bir web sitesi tasarlamak. 

• Geliştirilen yazılımın kullanıcı ara yüzünün kolay ve kullanışlı olması tamamen profesyonel bir ekip işidir. Yazılımı kullanacak kişilerin yazılımı zorlanmadan kullanabilmeleri ve kullanırken de sıkılmamaları önemli unsurlardır. Tasarım aşaması, yazılımın hem kullanıcı ara yüzünü hem de programın omurgasını ortaya koymaktadır.

  Tasarım aşamasının diğer teknik unsurları şöyle sıralanabilir:

   

  A. Veri tabanı seçimi ve tasarımı

  · Veri tablolarının belirlenmesi.

  · Sahaların belirlenmesi (Kayıt deseni).

  · İndeks ve anahtar alanların belirlenmesi.

  · Tablolar arası ilişkilerin kurulması(İlişkisel veri tabanı tasarımı).

  · Tetikleyici ve prosedür kodlarının tasarımı.

  · Veri tabanı seçimi.

   

  B. Ara yüzlerin tasarımı ve geliştirme araçları

  · Yazılımın adı.

  · İkon tasarımı.

  · Kapak resmi (ya da açılış resmi).

  · Kullanılacak derleyici ya da yorumlayıcı tespiti.

  · Kodlama ve iş akış diyagramlarının hazırlanması.

  · Veri giriş ekranlarının tasarlanması.

  · Sorgulama (ya da arama) ekranlarının tasarlanması.

  · Yazıcı ve ekran raporlarının tasarlanması.

   

  Yukarıdaki işlerden de anlaşılacağı gibi, tasarım iki ana başlık altında toplanmıştır. Buna göre, yazılımın alt yapısı olarak adlandırılan, veri tabanı tasarımı ve görsel kanadı oluşturan ara yüz tasarımı ve araçların seçimi, yazılımın tasarım sürecindeki ana hatlardır.

   

  Veri tabanı seçimi ve tasarımı

  Birçok yazılım ürünü, çok iyi görsel araçlara sahip olmasına rağmen, ne yazık ki zamanla yok olup gitmiştir. Bunun nedeni ise, çok kullanıcılı ortamlara aktarılamaması ya da aşırı veri yoğunluğunu destekleyememesi gibi nedenlerdir.

  Veri tabanı tasarımı ve seçiminde, tasarım ekibi, analizden gelen bilgiler doğrultusunda maksimum değerleri göz önüne almalıdır. Örneğin; yazılımın kullanılması ile müşterinin bir yıl sonra milyonlarca kayda ulaşması bekleniyorsa, veri tabanı bu desteği verebilecek şekilde seçilmeli ve tasarlanmalıdır.

  Yeri gelmişken bir konuya da değinmek gerekir, günümüzde en basit uygulama dahi açık sistem veri tabanı kullanılarak üretilmektedir. Desen gizlemek, artık müşteri için bile olumsuz bir opsiyon olarak değerlendirilmektedir. Müşteri doğal olarak, ileride karşılaşabileceği olumsuz durumlar için açık sistem veri tabanlarını tercih etmektedir.

  Bunun yanı sıra, elektronik ticaretin gelecekte alacağı yeri düşünecek olursak, veri tabanı tasarımı ve seçiminin önemli bir unsur olduğu daha iyi anlaşılır.

   

  Ara yüz tasarımı ve geliştirme aracı seçimi

  Bazen öyle uygulamalar tasarlanıyor ki, uygulamayı kapatmak için dakikalarca uğraşmak gerekebiliyor. İyi tasarlanmış ara yüze sahip uygulamalarda, hem kullanıcı kolaylık yaşar hem de firmanın destek ekibi rahat olur. Ayrıca, programcıların hâkim olduğu ya da destekleyebilecekleri kodlama araçları ile çalışılmalıdır.

   Unutulmaması gereken nokta, tasarımının sadece müşteri için değil, firmanın destek birimi de düşünülerek yapılması gerektiğidir. Hiçbir müşteri, yeterli destek alamayacağını bildiği bir uygulama yazılımını satın almak istemez.

   

  Projemizin tasarım aşamasında neler yapılmalı?

  İçerikle bir bütün olabilmesi ve kullanıcı için kullanışlı bir tasarım olması gerekiyor. Diğer yandan bölümün sitesini ziyaret edecek kullanıcıların isteklerini karşılayacak sayfalar ve dokümanların ulaşılabilir olması gerekir.

  Bundan dolayı farklı üniversitelerin aynı bölümlerinin site içeriklerini kontrol edip bizim ihtiyacımız olan kısımları örnek alarak tasarım için gerekli materyalleri toparlayıp tasarım aşamasına başlayacağız.

  
  

  Kaynakça:

  1. http://www.ayosis.com.tr/ozhan/Yazilim%20Gelistirme%20Sureci.pdf

  2. http://cisn.odtu.edu.tr/ozel/pamuk.php
  

  
  

  //VNYZ