Waterfall Yazılım Geliştirme

0 3.400

Merhaba;

Bu yazımda waterfall yazılım geliştirme modeline değineceğim; güçlü ve zayıf yönlerini anlatmaya çalışacağım.

Yazılımlarda birçok versiyon geçiş modeli bulunmaktadır. Bunlardan en sık kullanılanlardan biri de Şelale modelidir. Şelale modeli tüm sürecin aşama aşama yapıldığı ve bir önceki aşamaya dönüşün zor olduğu ve her aşamanın sorunsuz ve tam bir şekilde tamamlanması gereken bir modeldir.

Bu modelin kullanılabilmesi için; müşteri ihtiyaçlarının tam bir şekilde anlaşılmış olması gerekmektedir. Sonradan ortaya çıkacak bir ihtiyaç projenin mevcut kapsamında değil farklı kapsamda yapılmasını sağlayacaktır.

Bu modelin bir diğer dezavantajı ise; analiz süreçlerinin uzun olduğu durumlarda müşterinin bu süre boyunca ihtiyacının değişebilir olmasıdır. Günümüzde teknoloji çok hızlı ilerlemektedir.Bu nedenle bu süre çok uzun tutulmamalıdır.

Şelali modelini kullanmak için; öncelikle müşterinin ihtiyaçlarını net anlamış olmamız gerekmektedir. Bu model genellikle büyük projelerde kullanılmaktadır. Her projeyi bölümlere ayırmak doğru olmayabilir, bu nedenle bu kararı vermek için proje çok iyi analiz edilmelidir.

​​
Bu modelde; doküman üretmenin çok maliyetli olduğu yapılan bir araştırma da belirtilmiş, bunun neden de yapılan her değişikliğin ve işin dokümanda güncelleme gerektirmesi olarak gösterilmiştir.

Analiz Süreci
Sistemden ne istenildiği ve kısıtların belirlendiği aşamadır. Bu aktivite “Gereksinim Mühendisliği (Requierements Engineering)” olarak da adlandırılmaya başlanmıştır. Kritik bir aşamadır. Yazılım geliştirme sürecinin başında olması nedeniyle bundan sonraki tüm süreçleri de doğrudan etkilemektedir.

Analiz süreci yazılım geliştirmenin sürecinin başlangıcı olduğu için tüm ihtiyaçların doğru şekilde anlaşılmış olması gerekmektedir. Burada müşteriye de yazılım geliştiren firmaya da (Bunlar aynı firmada olabilir) çok büyük rol düşmektedir. Burada yazılımın nasıl geliştirileceğine değil, müşterinin asıl ihtiyacının ne olduğuna odaklanılmalıdır. Burada yapılacak bir yanlış, diğer tüm süreçlerin yanlış ilerlemesine ve buna ek olarak geri dönüşlerde ciddi maliyet ve zaman kaybına sebep olacaktır.

Analiz dokümanları yalın bir şekilde hazırlanmalı ve herkesin anlayabileceği şekilde yazılmalıdır. Çünkü bu dokümanlara istinaden;

Yazılım geliştirme ekibinin müşterinin tam ihtiyacını anlaması için yardımcı olur,
Tasarım ekibine; bu analize istinaden sistemin nasıl tasarlanacağına yardmcı olur,
Test ekibine; bu analizlere istinaden hangi test case lerinin koşulacağına yardımcı olur.
Analiz sürecinde dikkat edilmesi gereken bir diğer kısım ise; müşteri ihtiyaçlarının uygun bütçe ve teknoloji içerisinde olup olmadığıdır. Müşteriler mevcut teknolojiden daha üstün birşey istiyor olabilir veya mevcut bütçenin karşılayamacağı detayda bir istekte bulunmuş olabilir. Bu detaylar müşteriye aktarılmalı ve hem geliştirici firma hem de müşteri için en uygun yöntem seçilmelidir. Bazen müşterinin yakalayamadığı alternatif çözümleri geliştirici firmanın tecrübesi yönlendiricilik yapılabilmektedir.

Gereksinimler tanımlandıktan sonra bunlar bir önceliklendirme sırasına konulmalıdır. Müşterilere göre çoğu zaman tüm gereksinimler en önceliklidir fakat bu detay müşteri ile konuşulmalı ve bir sıralama yapılmalıdır.

Gereksinimler hazırlanırken akış süreçleri çizimlerle desteklenmeli ve müşterinin ve diğer ekiplerin anlayacağı şekilde iş akış modelleri çizilmelidir. Bu iş modelleri tüm süreçleri şeffaf ve anlaşılabilir şekilde göstermelidir.

Gereksinimler tamamlandıktan sonra dokümantasyonu müşteri ile mutabık kalınmalı ve bu doküman üzerinden müşteriden onay alınmalıdır. Bu onay süreci çok önemlidir; diğer aşamalarda hatta yazılım geliştirme devreye alımından sonra bile bir sorun çıktığında bu doküman referans alınabilmekte ve istenilen şey kapsam dışı ise ek talep olarak değerlendirilmektedir.

Tasarım Süreci
Yazılımın temelini yani mimarisini oluşturmak için; ihtiyaçları çalışır sisteme çevirmek gerekmektedir.

Tasarım süreci; müşterinin ihtiyaçlarının nasıl yazılım geliştirme yapılacağını teknik olarak tasarlandığı süreçtir. Bu süreç daha tekniktir ve hem yazılım ekibinin hem de müşterinin anlayacağı şekilde yazılmalıdır.

Bu süreç iki farklı adımdan oluşmaktadır.

a) Sistemin net belirlenmesi: Müşteriye sistemin ne yapacağını anlatır. Buna “Kavramsal Sistem Tasarım” denir. Sistemin fonksiyonlarını müşterinin anlayacağı dilde teknik jargon kullanmadan ifade etmelidir.

b) Teknik Tasarım: Müşteri kavramsal sistem tasarımı uygun görürse sistem kurucularına, programcılara yazılım ve donanım kurmalarına izin veren “Teknik Tasarım” hazırlanır. Teknik tasarım; sistem mimarisi (donanım parçalarının fonksiyonları), yazılım yapısı (yazılım unsurları fonksiyonları), veri (veri yapısı ve akışı) içermelidir.

Tasarım sürecinde; eğer analiz sürecinde anlaşılmayan bir kısım varsa kesinlikle bu soru işareti analistlerle görüşülerek giderilmelidir. Hiçbir süreç varsayım üzerine yapılmamalıdır.

Müşteri ile uzlaşılmış tüm istekler ve ortaya çıkabilecek tüm kısıtlar gereksinim olarak düşünülmelidir.

Tasarım sürecinde; hem yazılım ekibinin hem IT ekiplerinin hem de müşterinin kodlama aşamasında hiçbir soru işareti kalmayacak şekilde yapılmalı ve tüm detaylar bu dokümana eklenmelidir. Bu doküman çizimlerle ve tasarım araçları ile desteklenmelidir.

Analiz sürecinde olduğu gibi; tasarım sürecinde de tasarım tamamlandıktan sonra doküman müşteriye onaylatılmalı ve bu onay sonrasında bir sonraki safhaya geçilmelidir.

Yazılım Geliştirme Süreci
Tasarım dokümanına istinaden yazılım geliştiriciler tarafından yazılım kodlama işlemi yapılmaktadır. Bu kodlama da firma standart procedürlerinin olması çok önemlidir. Bu procedürlere istinaden yazılım geliştiriciler belirli bir standartta kodlama yapmalı ve herşey aynı bakış açısı ile geliştirmelidir. Burada koordinasyon eksikliği ve takım çalışmasının olmadığı durumda geliştirilen yazılımda birçok fonksiyonunda sorunlar çıkabilmektedir.

Hangi kaynaktan geldiği belirsiz kodların bilinçsizce çalıştırılması sonucu her gün binlerce sistem milyonlarca dolarlık hasara uğramaktadır.  Yazılım geliştirme sürecinde yazılım ekibi ihtiyaç duyduğu her anda tasarım ekibinden destek alabilmeli ve beraber ilerlemelidirler. Burada yazılım geliştiricilerin de tecrübeleri çok önemlidir. Çünkü yazılım geliştirme sırasında yapılacak her bir hata yazılımın doğru şekilde çalışmamasına ve test ekibine ek iş yüküne sebep olacaktır. Hatta bu hata test ekibinin gözünden kaçıp canlı sisteme taşınabilir ve müşteride memnuniyetsizliğe sebep olabilmektedir. Her ne kadar kısa bir süreç olarak görünse de; yazılım geliştirme süreci işin somut hale dönüştüğü bir süreç olduğundan en önemli safhalarından biridir. Kodlama tamamlandıktan sonra her yazılımcı geliştirdiği kod parçacığının doğru şekilde çalışıp çalışmadığı ile ilgili birim testini mutlaka yapmalıdır.

Test Süreci
Yazılım test süreci; geliştirilen paketin test ekibi tarafından oluşturulan senaryolar eşliğinde testlerin koşulduğu safhadır. Yazılım testlerinin asıl amacı; yazılımdaki hataları bulmak değil, yazılımın kalitesini ölçmektir.

Yazılım testleri; aslında yazılım geliştirme sürecinin her safhasında yapılmalıdır, analiz ve tasarım sürecinde mantıksal bir hata var mı, yazılım geliştirme sırasında kodsal bir sorun var mı, devreye alım sırasında sistemsel bir problem var mı gibi süreçlerde bu testlerin içerisine dahil edilmelidir.

Yazılımda öncelikle; yazılım geliştirme ekibi tarafından birim testleri yapılmaktadır. Bunlar da geliştirilen kod parçacıklarının doğru çalışıp çalışmadığının kontrol edilmesidir. Sonrasında geliştirilen kod parçacığının diğer kodlarla uyumlu bir şekilde çalışıp çalışmadığı kontrol edilmelidir. Ardından test ekibi tarafından hazırlanan test senaryolarına istinaden tüm süreçler test edilmelidir.

En son olarak da; kullanıcıların yani müşterinin kabul testi yapılması beklenmektedir. Bu kabul testi de teknik detaya girmeden kullanıcının istediği temel fonksiyonların geliştirilen yazılıma doğru şekilde uyarlanıp uyarlanmadığıdır. Bu kabul testleri çok önemlidir. Kullanıcılar bu aşamaya kadar herhangibir somut birşey görmedikleri için bu testler sonunda müşterinin ihtiyacının ne kadarının doğru tasarlandığı ortaya çıkmaktadır. Kullanıcı kabul testinin onayı kesinlikle alınmalıdır. Bu testler de tamamlandıktan sonra sistem devreye alım için hazır hale gelmektedir.

Bazı firmalarda; yazılım testleri için test otomasyonları kullanılmaktadır. Bu test otomasyonlarını devreye almak için öncelikle yazılımın fonksiyonlarının çok iyi biliniyor olması gerekmektedir. Bu otomasyonlar her firma için uygun değildir, bu nedenle öncelikle bu uygunluk araştırılmalıdır. Maliyetlerinin yüksek olması sebebiyle genelikle büyük ölçekli yazılım firmalarında bu otomasyonlar kullanılmaktadır. Fakat tek başına otomosyonlar yeterli olmamakta her zaman test ekibinin koşacağı testlere de ihtiyaç duyulmaktadır.

Devreye Alım Süreci
Geliştirilen yazılımın doğru sistemde ve doğru süreçte devreye alınması sürecidir. Yapılan yazılımın doğru topoloji ile canlı sisteme taşınması ve imkan varsa öncelikle pilot uygulamasının yapılması gerekmektedir. Eğer pilot uygulama başarılı olursa sistemin yaygınlaştırılmasına başlanması doğru süreçtir.

Bu süreçte dokümantasyon çok önemlidir. Kullanıcıların sahada yapılan yazılımı nasıl kullanacakları ile ilgili ; yazılımın kapsamına göre eğitim organize edilmeli ve eğitime ek olarak dokümantasyon yapılmalıdır. Günümüzde herkesin hayatında yazılımlar olduğu için ve yeni geliştirilen yazılımlar neredeyse aynı standartlarda yapıldığı için kullanım kolaylıkları mevcuttur. Fakat yazılım ne kadar basit olursa olsun dokümantasyonu kesinlikle olmalıdır.

İzleme ve Bakım Süreci
Devreye alım tamamlandıktan sonra yazılımın bir süre izlenmesi ve tüm akışın canlı sistem üzerinde doğru şekilde işlendiğinden emin olması gerekmektedir. Birim testler, Test senaryoları ile koşulmuş testler ve Kullanıcı kabul testlerinde atlanmış noktalar olabilir. Unutulmamalıdır ki, en iyi testi sahadaki son kullanıcı gerçek hayatta kullanarak yapmaktadır. Bu nedenle çıkabilecek olan yazılım hatalara hızlı ve kalıcı müdaheleler bu süreçte çok önemlidir.

Bu süreç projenin büyüklüğüne göre değişmektedir. Saha stabil hale geldiğinde ve artık sorun yaşanmadığında sonlandırılabilmekte ve artık standart bakım süreci devam etmektedir.

Yazılımlarda bakım anlaşmaları yazılımın sahadaki önemine göre yazılımcı firma ile müşteri arasında yapılmaktadır. Bu anlaşmalar çok önemlidir, çünkü vaadedilen sürelere uyulmadığı taktirde cezai yaptırımı mevcuttur. Bu nedenle yazılım firmaları bu anlaşmalara göre kaynak ve planlama yapmak zorundadırlar.

Email adresiniz yayınlanmayacaktır.