Değişiklik Maliyeti

Bu yazımda sizlere yazılım projelerinde değişiklik maliyeti konusunu 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)

Çevik Yaklaşımlar ve Waterfall’da Değişiklik Maliyeti Eğrisi

Aşağıda verilen grafik Software Engineering adlı makalede 1976 yılının Aralık ayında yayınlamıştır. Boehm, aynı makaleyi 1981 yılında yayınlanan ve adı Software Engineering Economics olan kitabında da kullanmıştır.

Buna göre Boehm, TRW, IBM ve GTE’de geliştirilen projeleri inceleyerek Waterfall modelindeki adımları baz alan çalışmasında her adımda maliyetin eksponansiyel olarak artığını söylemektedir. Yani ihtiyaçların belirlendiği analiz aşamasındayken bir hata bulunursa bu hatayı düzeltmenin maliyeti 1x birimken aynı hata tasarım aşamasında 5x birim maliyete, kodlama aşamasına geçildiğinde ise 10x birim maliyete, operasyon aşamasındayken yani ürün kullanıcılar tarafından kullanılıyorken >200x birim maliyete düzeltilebilmektedir.

Ayrıca Boehm, Software Engineering Economics kitabıyla aynı adı taşıyan makalesinde ise birçok farklı konuyu ele almış olsa da özellikle dikkatimi çekenlerden biri Software Cost Estimation adlı üçüncü bölümde yazılım maliyetini tahmin ederken kullanılabilecek farklı tekniklerden bahseder. Bu tekniklerin güçlü ve zayıf olduğu yönlerini ele alırken aslında günümüzde Çevik yaklaşımlarda kullanılan maliyet belirleme tekniklerine de değinmektedir tabi bu makale yayınlandığında Çevik yaklaşımlar daha doğmamıştır. Bu teknikler:

• Algorithmic Model
• Expert Judgment
• Analogy
• Parkinson
• Price to win
• Top – down
• Bottom – up

Bu yaklaşımların hiç birinin tek başına başarılı olamayacağını vurgularken Top-down ve Bottom-up yaklaşımlarının birbirlerini tamamladığını yinelemeli bir şekilde beraber kullanılmaları gerektiğini anlatır. Buna rağmen kontratların imzalandığı tekniğinse Price to win tekniği olduğundan bahseder ki aslında bu tekniğin uygulanabilirliğinin olmadığını vurgular.
Asıl konumuza dönersek Çevik yaklaşımlardan eXtreme Programming’in yaratıcısı Kent Beck, Değişiklik Maliyeti Eğrisi’ni Çevik yaklaşımlar için aşağıdaki gibi belirlemiştir.

Bu eğriye göre Çevik yaklaşımlar, Çevik Pratikleri kullanarak hataları çok daha çabuk ve dolayısıyla maliyet artmadan bulunmasını sağlıyor. Eğride verilenlerden kısaca bahsetmek istiyorum.

Çevik yaklaşımlar hataları bulmaya çalışırken kullanılan teknikler:

• Eşli Programlama ile kodlamada yaptığınız hataları anında bulma şansınızı artırırsınız
• Sürekli Entegrasyon kullandığınız build’lerde Eşli Programlama’da gözlerden kaçan hataları yakalarsınız
• Tasarım yada kodlamada yaptığınız hataları Test Driven Development ile yakalayabilirsiniz
• İhtiyaçların belirlenmesinde ve tasarımda yapılan hataları proje paydaşlarının aktif katılımı sayesinde projede çokta ilerlemeden bulursunuz
• Analiz ve tasarımda yapılan hataları modelleme tekniğini kullanarak ürünün tamamını bitirmeden ortaya çıkartabilirsiniz
• En son olarak paralel testler ile hataları yakalayabilirsiniz

Geleneksel proje yönetiminde hataları bulmaya çalışırken kullanılan teknikler:

• Projede analiz, tasarım aşamaları geçilmiş ve geliştirme aşamasının sonuna doğru yapılan incelemede hatalar bulunur
• Geliştirme aşaması tamamlandıktan sonra başlayan büyük test aşamasında tasarım ve kodlamada yapılan hatalar bulunur
• Analizde yapılan hatalar kullanıcı kabul testinin yapıldığı adım ve projenin son bölümü olan adımda bulunur.

Yukarıdaki bilgiler ışığında geleneksel proje yönetimi hataları, hataların yapılmasının üzerinden çok büyük zaman geçtikten -ne kadar çok zaman geçerse hatırlaması o kadar zor olur- bulmaya çalışırken Çevik yaklaşımlar hataları anında tespit etmeye çalışır. Dolayısıyla Değişiklik Maliyeti daha az olur.

(1)http://csse.usc.edu/csse/about/people/faculties/BarryBoehm.html

(2) http://csse.usc.edu/csse/TECHRPTS/1984/usccse84-500/usccse84-500.pdf

(3) http://www.agilemodeling.com/essays/costOfChange.htm#Figure2

(4) http://www.ambysoft.com/essays/whyAgileWorksFeedback.html