![]() |
|
|
![]() |
|
..:::: Reklam ::::..
|
 |
|
![]() |
|
|
![]() |
|
..:::: Duyuru ::::..
|
|
|
|
|
|
|
Yazılım Geliştirme Süreç Modelleri
| Organizasyonlarda temel olarak, yazılım sistemlerinin gereklerinin belirlenmesi, tasarlanması, kodlanması, test vb. aktivitelerinin gerçekleştirilmesi amacı ile çeşitli süreçler uygulanmaktadır. Uygulanan yazılım geliştirme sürecinin yanı sıra, örneğin yazılım ölçüm süreci de paralelde işletilebilmektedir. Bu yazıda, bilinen çeşitli yazılım geliştirme süreç modellerinden bahsedeceğim. | En çok ismi geçen yazılım geliştirme süreç modeli “ŞELALE” (Waterfall)dır. Bu model Şekil 1’de de görülebileceği gibi, gereklerin analiz edilmesi ve belirlenmesi, tasarım, kodlama ve ünite testi, entegrasyon ve sistem testi, işletme ve bakım onarım safhalarından oluşmaktadı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. Şekil 2’de bu modelin süreç şemasını görülmektedir.
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. Şekil 3 ‘te yer alan spiral modelin her bir turu, süreçte yer alan herhangi bir safhayı temsil edebilmektedir.
Şekilde gözüken numaraların açıklamaları şöyledir.
0. Yaşam Döngüsü Planı
1. Gerek Planı
2. Geliştirme Planı
3. Entegrasyon ve Test Planı
4. Kapsam
5. Gereklerin Belirlenmesi ve Geçerlilenmesi
6. Tasarım ve Geçerlileme
7. Entegrasyon, Ünite Testleri ve Kabul Testleri
8. 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. Şekil 4 ‘te bu modelin işleyişi kısaca görülmektedir.
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.
Her konuda görüşlerinizi bana e-posta yolu ile iletebilirsiniz.
Özgür ERALP
www.yazilimci.gezegeni.com
oeralp@aselsan.com.tr
YAZARIN DİĞER YOLLADIĞI DOKÜMANLAR:
|
| » |
Çalışanlar Gözüyle Yazılımda Yönetim Prensipleri 2008-09-28 (978)
 |
| |
Bahsi geçen yazıda cevabı aranan temel sorular: Yazılım sektöründe çalışan mühendisler yöneticileri nasıl görmek istiyor? Çalışanların bakış açısı ile yönetim ilkeleri neler olmalı? |
| » |
Fazla Mesai Yapmadan Bitirilebilen Yazılım Projesi 2008-09-28 (1225)
|
| |
Ana soru: ’Proje aktivitelerini nasıl iyileştirebiliriz? Neler yapmalı ki herşey yolunda gitsin, projedeki tüm hedefler tutturulabilsin?’ Bu konuda yazılmış sayısız makale var, ve bunları okumuş sayısız yazılımcı. Belirli noktalarda ve pratiklerde uzlaşı grupları da oluşmuş durumda. Fakat, hep aynı sorun karşımıza çıkıyor. Hiç fazla mesai yapmadan bitirilebilmiş bir yazılım projesi var mı? |
| » |
Test mi, Sınama mı? Odaklı mı, Yönelik mi? 2008-03-17 (1035)
|
| |
Bu pratiğin orijinal ismi "Test Driven Development - TDD". Sonuç olarak herkesin üzerinde uzlaştığı bir karşılık belirleyememiştik. Öne çıkan adaylar ise; "Test Tarafından Yönlendirilen", "Teste Yönelik", "Test Odaklı", "Test Güdümlü" idi. |
| » |
Patent, ArGe, Polemik ve Araştırma 2008-03-17 (790)
|
| |
Patent kapma peşinde, yazdığı her kaynak kod satırında acaba patentlik değeri var mı? diye düşünen yazılımcılar dolaşmakta etrafımızda. Düşüncelerin temelinde iki soru var. Bu kod parçası hangi problemi çözüyor? Benden önce birileri bu çözümü düşünmüş mü? Bu sorulara yanıt bulabiliyorsanız, ciddi ciddi "patent alma" çalışmalarına girebilirsiniz. |
| » |
Tekrar Kullanılan Modüller 2008-03-06 (917)
|
| |
Yazılımlara gereksinim duyan teknolojiler o kadar hızlı değişiyor ki sizin bu değişimin arkasında kalmamanız için en az onun kadar hızlı ürün geliştirebiliyor olmanız gerekiyor. Günümüz yazılım organizasyonlarının bir çoğunda çeşitli alanlarda hizmet sağlıyabilmeleri için ellerinde sahip oldukları çekirdek modüller bulunmakta. Yeni bir ürün geliştirirken, bu sürecin hızlı işleyebilmesi için bu çekirdek üzerinde çalışıyorlar. |
|
EN YENİ 5 DOKÜMAN:
|
| » |
Ar-Ge ve yazılım 2009-09-15 (805)
|
| |
Bilgi Teknolojileri (Information Technologies) sektöründe AR-GE denildiği zaman ilk aklımıza gelenler ihtiyaçların analiz edilmesi, ürünün tasarlanması ve geliştirilmesi olarak söylenebilir. AR-GE kelimesini Araştırma ve Geliştirme olarak iki başlık halinde açıklayabiliriz. |
| » |
Platform Sanallaştırma (Virtualization) 2009-09-10 (449)
 |
| |
Platform kelimesinin Türkçe karşılığı \\\"düzlem\\\", bilişim sektöründe sık kullanılan bir kelime. Geliştirilen yazılımın(programın) çalışmasına olanak sağlayan donanım mimarilerini veya yazılım çerçevelerini(uygulama çerçeveleri dahil) ifade etmek için kullanılır. Tipik platformlar bir bilgisayarın mimarisini, işletim sistemini, programlama dillerini ve çalışma anında kullanılan yazılım kütüphanelerini ya da grafiksel ara yüzü dahil ederler. |
| » |
İşi Bütün Olarak Düşünme 2009-09-10 (375)
|
| |
Şirketin “işi bütün olarak düşünme” bakış açısına sahip olması.
Şirket yönetiminin tek bir kaynaktan şirketin detaylı olarak çok boyutlu görüntüsüne sahip olabilmesi.
Ne oldu?
Neden oldu? |
| » |
Uygulama Sanallaştırma 2009-09-09 (588)
|
| |
Uygulama sanallaştırma bilişim sektöründe kullanılan genel bir terim. Birbiri ile ilişkili içerikleri tek bir çatı altında toplar. Örneğin: Kırmızının farklı çeşitleri vardır. Al, Parlak Kırmızı, Şarap Rengi gibi. Bu renkler kırmızının altında gruplanır. |
| » |
EMS ve ERP Farkı 2009-08-26 (429)
|
| |
İngilizce karşılığı Enterprise Management System(EMS) olan Kurumsal Yönetim Sistemi işletme genelinde, yöneticilerin finansal ve finansal olmayan ihtiyaçlarına yöneliktir. Planlama ve Analiz aşamalarında iş modellerini oluşturmak için şirketin organizasyon yapısından ve stratejik planlarından yararlanır. Kurumsal Yönetim Sistemi tüm şirket tarafından erişilebilir. Web’den erişim imkanları kullanıcıların önemli raporlara erişmesine ve internet bağlantısı ile herhangi bir yerden araçları görüntülemesine imkan sağlar. |
|
|
Bu dökümanı nasıl buldunuz?
|
|
|
volkan AÇIKGÖZ
- 2004-06-01 10:34:06
|
| güzel |
|
|
mtn shn
- 2004-05-29 23:44:48
|
| Herhangi bir yazilimi yapmadan once yapacaginiz yazilim analiz etmeniz gerekmektedir. Bunun icinde cesitli programlar vardir ornegin FCO-IM, ER, ve UML gibi. Analizi yaptiginiz zaman sistem zaten bunu hangi database altina koyacaginizi sorar hangi dili kullanacaginizi sorar. Ornek: Access, SQl, Oracle gibi. |
|
|
Fazıl Öztürk
- 2004-03-13 17:49:38
|
| Oğlum Kapasitemiz almadı Kısa ve öz olsun. |
|
|
Mert Bal
- 2003-11-13 12:30:38
|
Gerçekten çok iyi buldum,fakat kapsamının daha da genişletilmesi gerektiğini düşünmekteyim.Bunun nedeni bu konuda yazılmış Türkçe kaynağa ihtiyaç duyulmasıdır.
Bu konuda yapmış olduğunuz çalışmaları tebrik eder,başarılar dilerim. |
|
| |
|
Ücretsiz Üye Ol
