Monthly Archives: March 2016

Yazılım Projelerinde Gecikmenin Maliyeti

Yazılım Projelerinde Gecikmenin Maliyeti

Üretim ortamında bulunmayan kodlardan değer üretemezsiniz. Bu kadar vurucu bir cümleyle yazıya giriş yapmam okuyanların konunun önemini anlamalarına yardımcı olmak içindir.  İşlerinizi önceliklendirirken pazara çıkış zamanıyla elde edeceğiniz kazanç, yasal zorunluluk, iş değeri gibi kavramlardan yararlanabilirsiniz. Bunların yanında dikkate almanız gereken diğer bir konuysa Gecikmenin Maliyeti’dir. Gecikmenin maliyeti, bir özelliği üretim ortamına almayı geciktirerek kaybedilecek değerdir.

 

Gecikmenin maliyeti işlerin önceliklendirilmesinde nasıl bir öneme sahip? Gecikmenin maliyetini nasıl hesaplayabiliriz? Farklı senaryolar üzerinden şimdi görelim.

Continue reading Yazılım Projelerinde Gecikmenin Maliyeti

Yazılım Projelerinde Karar Almada Ortamın Önemi

Yazılım Projelerinde Karar Almada Ortamın Önemi

Bu yazıma bugün yaşadığım ilginç bir deneyimi anlatarak başlamak istiyorum. Bugün izlediğim bir futbol maçında dikkatimi çeken bir forvet oyuncusu bulunuyordu. Bu oyuncu takımının yakaladığı fırsatları bir bir harcadı. Kale önünde, altı pas içinde topu kaleciye nişanladı, çektiği şutlar defans oyuncularına çarptı, verdiği paslar arkadaşlarına ulaşmadan rakipler tarafından kapıldı. Maçın bir bölümünde rakip takım korner kullandı. Kornerden dönen top, kornerin kullanıldığı köşeye geri dönerken bizim ünlü forvetimiz rakip takımdan birini takip ediyordu. O anda bu topun dönüp gol olacağını düşündüm. Çünkü bu adam tam bir başarısızlık abidesiydi ve ne yapsa takımına negatif bir şekilde geri dönüyordu. Eminim demek istemiyorum ama rakibi takip etmese ve rakip boş bir pozisyonda orta yapsa o top bence gol olmayacaktı. Bu topun gol olması rakibin şansı bizim forvetimizin şanssızlığı değildi. Buna eminim. Bizim forvetimiz dışarıdan bakıldığından elinden geleni yapıyor, çok çalışıyor, canını dişine takmış ve herşeyini veriyor gibi görünüyor. Tek birşey dışında bunları yaparken doğru yolu izlemiyor. Çünkü doğru kararlar veremiyor. Dahil olduğu her pozisyonda işleri daha da karışık hale getiriyor ve bunun sonucu da takımına olumsuz olarak geri dönüyor.

Bunları neden anlattım. Çünkü yazılım projelerinde görev alanlarda bu yaklaşımı sergiliyor. Tabi kişinin sahip olduğu role göre yaptığı etkide ortamda farklı oranda değişikliklere neden oluyor. Örneğin bir futbolcu hata yaptığında bu çok önemli olmayabilir ve hatadan geri dönülebilir. Hatalı bir pas verip topu rakibe kaptırabilirsiniz. Biraz sonra topu rakipten geri alabilirsiniz ve bu çok büyük bir sorun olmayabilir. Bu tıpkı bir yazılımcının test senaryoları üzerinden geçerken birini atlaması gibi geliyor. Fakat teknik direktör maçı kaybederken ve gol atması gerekirken bir forvet çıkarıp bir savunma oyuncusu alıyorsa çok ciddi sıkıntılar var demektir. Bırakın oyunu okumayı bu teknik direktör skor tabelasını bile okuyamıyor diye düşünebiliriz. Aynı şekilde bir projenin planlamasında yada ilerlemesinden sorumlu kişilerin aldığı aksiyonlarda böyledir. Bazen hepimizin içinden geçiyordur. Bu adam ne yaptığını bilmiyor dediğiniz olmuştur. Örneğin beş altı ay sonra geliştirilecek bir proje için gerekli bilgilerin şimdiden toplanması yada bir projede çalışacak kişilerin projenin geliştirilmesi için gerekli olan teknik ve ortam bilgilerinden eksik olması gibi. Continue reading Yazılım Projelerinde Karar Almada Ortamın Önemi

Yazılım Projelerinde Değişiklik Maliyeti

Yazılım Projelerinde Değişiklik Maliyeti

 

Bu yazımda sizlere yazılım projelerinde değişiklik yapıldığında bunun proje bütçesine olan etkisini anlatmaya çalışacağım. Diğer bir deyişle proje gerçekleştirilirken yapılan hatanın organizasyona olan maliyetini anlatacağım. Böylece yazılım geliştirilirken aslında her bir aktivitenin ne kadar önemli olduğunu göreceğiz. Aktiviteler kullandığımız yaklaşıma bağlı olarak değişmektedir. Örneğin geleneksel yazılım geliştirme yaklaşımında Eşli Programlama diye bir aktivite bulunmazken aslında hatalar yapılır yapılmaz yakalanma şansı kaçırılmaktadır. Halbuki Çevik yaklaşımları kullanan takımlar Eşli Programlama’yı kullanarak hatalar yapılır yapılmaz yakalamakta ve gerekli değişikliği yapabilmektedir. Projenin tamamı düşünülerek bu açıdan bakıldığında Çevik yaklaşımlar büyük bir israfın önüne geçilebileceğini göstermektedir.

 

Yazılım projelerinde değişikliğin maliyetini hesaplayan çalışmayı yapan kişi Barry W. Boehm’dur. Boehm, Waterfall modelini ilk defa bilimsel makalesinde anlatan Royce gibi TRW için çalışan aynı zamanda Güney Kaliforniya Üniversitesi’nde hocalık yapan bir profesordür. 1957’de Hardvard’ta lisans eğitimini tamamlamıştır. Yüksek lisans ve doktora derecelerini 1961 ve 1964 yıllarında Kaliforniya Üniversitesi’nden almıştır. 1989 – 1992 yılları arasında Amerika Savunma Bakanlığı’nda Direktör olarak çalışmıştır. 1973 – 1989 yılları arasında TRW’de Savunma Sistemleri Şefi olarak görev yapmıştır. Yazılım geliştirme süreçlerini etkileyen birçok çalışması bulunmakla birlikte en büyük etkiyi WinWin Spiral Model ve Software Engineering Economics adlı çalışmalarıyla yapmıştır.(1)

Continue reading Yazılım Projelerinde Değişiklik Maliyeti

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.

Winston Royce ve Waterfall

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. Continue reading Waterfall’da Karşımıza Çıkan Problemler 2

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

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

Bu yazımda son 40 yıldır yazılım geliştiren herkesin enaz bir defa karşısına çıkan Waterfall’dan bahsedeceğim. İster küçük bir yazılım evinde ürün geliştiriyor olun ister kurumsal bir organizasyonda görev alın Waterfall size dokunmuştur. İster bir veriambarı projesi yapın, ister bir B2B projesi geliştirin herkesin desteklediği ama bilgisinin olmadığı ve üzerine düşünmediği bir konudur, geleneksel yazılım geliştirme süreci.

 

40 yıldır bu yaklaşımla proje geliştiren kişilerin bu yaklaşımı savunmasını anlıyorum, anlayamadığım konu çalışmaya sadece birkaç yıl önce başlamış kişilerin adeta fanatik bir şekilde bu yaklaşımı savunmalarıdır. İlk önce analizi bitirmeliyiz analiz bittikten sonra geliştirmeye başlanabilir geliştirmeyi bitirdikten sonrada testçi arkadaşlar test etmeye başlayacak diye seslerini yükseltmelerini şaşkınlık içinde izlediğim çok olmuştur. Bu sahneleri izleyince Uğur MUMCU’nun şu sözü gelir aklıma “Bilgi sahibi olmadan fikir sahibi olunmaz!”. Gerçekten bilgi sahibi olmadan fikir sahibi olan bu arkadaşların fanatik yapısı neden kaynaklanmaktadır. İnsanoğlu neden öğrendiği ilk şeyin hep doğru olduğunu düşünür? İlk öğrendiğini benimser ve sahiplenir? Çünkü ego -psikoloji biliminde kullanılan anlamıyla- değişimin kötü olduğunu düşünür ve insan içgüdüsel olarak kendini koruması gerektiğini varsayar. Bu içgüdüsel yaklaşım bir savunma mekanizmasını tetikler ve değişime karşı yumruklar sıkılır.
Konuyu daha fazla ilginçleştirmeden ve dağıtmadan Waterfall ile geliştirilen ürünlerin geliştirme sürecinde karşıma çıkan problemleri anlatacağım. Sizinde karşınıza çıkan gözlemlediğiniz, yaşadığınız ve ilginç olduğunu düşündüğünüz problemleri duymayı çok isterim. Continue reading Waterfall’da Karşımıza Çıkan Problemler