Waterfall’da Karşımıza Çıkan Problemler 2

Waterfall’da Karşımıza Çıkan Problemler 2

 

Bir sonraki adıma geçebilmek için önceki adım bitmelidir

Waterfall adından da anlaşılacağı üzere aslında belirli basamaklardan oluşur. Bir sonraki adıma geçebilmek için önceki adım bitmelidir. Royce’un basit model dediği ve basit model için çizdiği şemayı hatırlarsak “Coding” adımına geçmeden önce “Program Design” adımının tamamlanmış olması gereklidir.

Projenin sonuna kadar değer üretilmez

Geliştirilen projeden, üründen değer elde edilebilmesi için Waterfall modelindeki bütün adımların tamamlanmış olması gerekir. Sistem Gereksinimleri, Yazılım Gereksinimleri, Analiz, Program Dizayn, Kodlama, Test ve Operasyon adımından sonra değer üretilmeye başlanır. Örneğin oniki aylık bir projede ancak onikinci ayın sonunda değer üretilebilir. Halbuki proje daha küçük adımlara bölünürse pazara veya son kullanıcıya çok daha çabuk ulaşılabilir. Oniki ay beklemek yerine birinci ayın sonunda değer elde edilmeye başlanabilir.

Winston Royce ve Waterfall

Kullanıcı ile etkileşim proje başladığında ve sonlandığında vardır

Waterfall ile yönetilen projelerde kullanıcı, projeye ihtiyaçların belirlendiği aşama olan analiz aşamasında dahil olur. Daha sonra gelen geliştirme adımında ise uzunca bir süre kullanıcıyla görüşülmez  ta ki kullanıcı kabul testleri yapılana kadar. Bu dönem içinde pazarda, dünyada, kurumda yaşanan değişiklikler dikkate alınmaz ve geliştirme tamamlanır. Kullanıcı kabul testleri başladığındaysa kullanıcı ile etkileşim tekrar başlar. Geliştirilen ürün kullanıcıya sunulur, kullanıcı testlerini yapar ve görüşlerini belirtir. Bu aşamada genellikle şu durumla karşı karşıya kalınır:

 

1 yıl önce analiz aşamasında projeye dahil olan müşteri ilk önce ne istediğini hatırlayamaz. Analiz dokümanları incelenir ve istenilen ürün hatırlanır. Daha sonra ise kullanıcı hayalinde oluşturduğu ürün ile geliştirilen ürünün birbirine hiç benzemediğini aslında çok daha farklı şeyler istediğini anlatmaya başlar. Bu dönemde farklı tartışmalar baş gösterir ve herkes birbirini suçlamaya başlar. Kullanıcı istediği ürünü geliştirmediği için geliştiriciyi, geliştirici ihtiyaçları doğru belirlemediği için analisti, analist ihtiyaçlarını tam olarak anlatamadığı için kullanıcıyı suçlamaya başlar. Sonuçta elde edilen şey; boşa harcanan emek, enerji, para, zaman ve istenilmeyen bir üründür. Ayrıca yazılım geliştirme işini yapan kişiler ile son kullanıcının arası bozulmuştur ve uzunca bir süre tekrar görüşülmeyecektir ta ki başka bir projeye başlanıncaya kadar. Tabi bu durumda son kullanıcının güveni sarsıldığı için artık projeyi kurum dışında sözde daha iyi olan bir firmaya yaptırmak yada var olan bir ürünü kullanmak-bu ürün isteklerini tamamıyla karşılamasa bile- ister. Bence bu çok büyük bir başarısızlıktır!

 

Değişikliğe açık değildir

Analiz ve tasarım adımları geçildikten sonra kapsamda gerçekleştirilmek istenen değişikliklerin maliyeti çok yüksektir. Aynı örnek üzerinden gidersek bir yıllık bir projenin ilk dört ayı analiz ve dizayn adımları gerçekleştirilir. Altıncı ayda kapsamda yapılan bir değişiklik bu dört aylık süreçte yapılan işlerin hepsinin gözden geçirilmesi demektir.

 

Hata tespiti uzun sürer ve düzeltmek pahalıdır

Test aşamasına gelinip bir hata tespit edildiğinde bu hatanın düzeltilmesi için yine analiz veya kodlama adımına dönülmesi gerekmektedir. Bu adımlara dönülüp hata tespit edilir. Eğer hata kodlama adımında yapılan bir hata ise ve büyük değişikliklere yol açmayacaksa kolay çözülebilir demektir. Fakat analiz aşamasında yapılan bir hata mimari anlamda değişikliklere yol açabilir. Çünkü geliştirme işi yapılan analiz baz alınarak gerçekleştirilmiştir ve temelinde bu analiz bulunmaktadır. Bütün bu geri dönüşlerin maliyetleri projenin bütçesini beklenenin üstüne çıkartır.

 

Yazılım geliştirme süreçlerini birbirinden ayırmak gerçekçi değildir

Yazılım geliştirme temelde soyut bir düşünceden -bir hayalden- kodlar ve bilgisayarlar yardımıyla çalışan bir ürün oluşturma işidir. Böyle soyut bir alanda çalışırken bir iki ay fikirleri kağıt üzerine dökmek daha sonra kağıt üzerindeki bu fikirleri toplayıp bir yapı oluşturmak ve bu yapıyı belirli bir mimariye oturtmak sonrasındaysa bu dokümanlardan ve mimariden yola çıkarak kod geliştirmek ve en sonda da beklenen sonucu elde etmek düşünüldüğü kadar kolay bir iş değildir! Hal böyleyken bütün bu adımlarda farklı birimlerdeki kişilerin farklı zamanlarda çalışması ise bu işi zorlaştıran bir başka etkendir.

 

Aşina olduğumuz bu sahnenin gözümüzde daha iyi canlanması için şunu hayal edin Analiz biriminde çalışan bir analist projenin ihtiyaçlarını belirler. Çözüm Mimarı bölümünden büyükler gelip dizayn yaparlar. Geliştirme biriminden birileri gelip işi geliştirir. Test biriminden birileri testi yapar ve kullanıcı olaya dahil edilir. Eğer Geliştirme biriminden gelen kişi analizde bir sorunla karşılaşıp analizi yapan kişiyi ararsa muhtemelen ulaşamayacaktır. Ulaştığındaysa o projenin analizini 3 ay önce yaptığını ve şuan sorduğu bölümle ilgili hiç birşey hatırlamadığını ama analiz dokümanının eksiksiz, tam ve doğru olduğuna dair hafif serzenişli bir karşılık alacaktır. Bu karşılığı verirken analistin herhangi bir suçu yoktur. 3 ay önce yapılan bir işi hatırlaması beklenemez. Farklı birimlerdeki farklı kişilerin farklı zamanlarda birbirinin devamı olan bir işi yürütmesi ve bu işin sonunda başarılı olunması mucize gibidir.

 

Yazılım geliştirip bu sahneyi yaşamayan var mı?

 

Her adımda doküman oluşturulur

Dokümantasyon, Royce’un makalesinde bahsettiği ve çok önem verdiği bir konudur. Makalesinde tam olarak şu ifade yer almaktadır;

 

“Bir örnek olarak karşılaştırma yapılabilmesi için şunu söylemek istiyorum. Beş milyon dolarlık bir donanımı temin etmek için yeterince detaylı otuz sayfalık bir şartname beklerim. Beş milyon dolarlık bir yazılımı temin etmek içinse bunu başarılı bir şekilde kontrol edebilmem için binbeşyüz sayfalık bir doküman beklerim.”

 

Peki projenin başarılı olabilmesi için gerçekten bu kadar detaylı dokümanlara ihtiyaç var mı? Bu kadar çok ve detaylı doküman oluşturmak için harcanan emek, para, zaman ve enerji çalışan yazılımın başarılı ve kaliteli olması için harcanması daha doğru değil mi?
Benim karşılaştığım problemler bunlar. Eminim ki bunlar ve benzeri durumlarla sizlerde karşı karşıya geldiniz. Bu durum zaten zor olan işi dahada zorlaştırdı. Sadece işi zorlaştırmakla kalmadı iş dışındaki yaşamınızıda etkiledi. Daha doğru daha başarılı ve daha mutlu projeler geliştirmek ve hayatın her alanında mutlu olmak için artık değişim başlamalıdır!

1830total visits,3visits today

Leave a Reply

Your email address will not be published. Required fields are marked *