Dokümansız proje

Hayır, öyle olağanüstü bir şey henüz icat olmadı. Şimdi çevik metodoloji kitabı okumuş birkaç arkadaş o metodoloji bu metodoloji diye atlar ama, bu sefer bir okurun sorusuna cevap vereceğim öncelikle. Taner Mutlu soruyor: eldeki projenin gereksinim dokümanı yoksa nasıl hareket etmeli?
 
Sorunun vurguladığı temel sorun, geliştirilmiş proje için başa dönüp gereksinim dokümanı çıkarmanın yüksek maliyeti. Dokümantasyon maliyeti haliyle çok yüksek bir faaliyet bu yüzden her bir satırının varlık sebebi sorgulanmalı. Bu durumda zaten geliştirilmiş bir ürün ya da tamamlanmış proje için gereksinim dokümanı hazırlanır mı?Bu soruya cevap vermek için öncelikle proje ya da ürünün yarınını sorgulamak lazım. Eğer ürünün geleceği yoksa (örneğin bir defalık veri toplama gibi bir iş için geliştirilmiş ve görevini ifa eder etmez emekli edilecek vs.) ya da projeyi tamamıyla devrediyorsanız ve devir alan mevcut dokümantasyon ile almaya razıysa başa dönmenin manası olmayacaktır. Ancak ürünün gelecek sürümleri olacak veya projenin bakımı ya da devamı söz konusu ise o zaman durum değişir. Özellikle ürün kurumsal bir şirkette belli bir iş için kritik işleve sahipse geçen zaman üzerinde çok sayıda değişikliğe neden olacağından gereksinim dokümantasyonun sağlıklı şekilde bulunmasının önemi ciddi şekilde artar.
 
Bu durumu 2008 senesi içinde çok önemli bir otomotiv üreticimizde yaşadık. 10 sene önce geliştirilen ve bugüne kadar sürekli olarak iç ve dış kaynaklarla desteklenerek değişiklik ve eklentilere maruz kalan bir ürünün yeni nesil bir çözüm ile güncellenmesi söz konusu olduğunda canlı gereksinim dokümanının olmaması büyük bir sorun olarak karşımıza çıktı.
 
Yaşanan sıkıntılar özetle yönetsel olarak:
  • yönetimin kapsama hakim olamaması nedeniyle yeni projenin boyut ve maliyet tahmininde zorlanması,
  • hazır ürün önerilerini mevcut ürünle sağlıklı şekilde karşılaştıramamak,

ve teknik olarak:

  • zaman içinde yapılan eklentilerden dolayı ortaya çıkan mercan adası sorunu
  • geliştirme ekiplerinde kaynak yönetimi sorunu, kişiye bağlılık
  • diğer dokümanların eksiği olarak tezahür eden temel faaliyet (analiz/tasarım) eksiği neticesi görülen teknik arızalar (performans ve yönetilirlik vs)

Peki çözüm? Karşılaştığımız senaryoda birkaç yüz adam aylık eforla geliştirilmiş, 10 senedir kullanımda ve düzenli olarak revizyonlara tabi kalmış ve daha da önemlisi bir süre içinde emekli edilecek bir ürün vardı. Bu ürün için büyük bir yatırımla tüm dokümantasyonun baştan çıkarılması hem anlamsız bir yatırım olurdu. Önümüzü açacağımıza inandığımız farklı bir yol izledik.

Mevcut ürünlerin gereksinim dokümantasyon eksikliğini gidermek için "best practice" olarak önerebileceğim çalışmada, kurumun standart olarak saptadığı gereksinim dokümanlarını, sadece iskelet oluşturacak şekilde ürettik. İskelettem kastim, tüm gerekli başlık ve alt başlıkların saptanması ve dokümandaki yerlerine yerleştirilmesi suretiyle dokümanın ana yapısının oluşması ancak gövdeyi oluşturacak detaylı açıklamaların bulunmaması şekliyle ortaya çıkan sonuçtur. Bu bağlamda başlıkları özetle açıklayacak miktarda bilgi verilmiş ancak tüm detaya girmekten kaçınılmıştır.

Burada önemli olan "ihtiyaç -> özellik -> işlev -> gereksinim" piramitini kurgulayacak yapının oluşturulmasıdır. Başlıkları yakalamak ve doğru olarak tanımlamak için projeyi/ürünü anlamak yeterli olacaktır. Projeyi tanıyan bir analistin kısa sürede yapabileceği bu iş için yabancı bir analist mülakat gibi temel tekniklere başvurmalıdır. Ayrıca ürünün elinde olduğunuzu unutmayın, işlemleri önyüzleri takip ederek tanımlamak kadar kolayı yoktur. Bu şekilde makul bir sürede "iskeleti" kurabilirsiniz.

Peki sonrası? Neden gereksinimleri dokümante ediyoruz hatırlayalım: geliştirirken ne yapacağımızı, değiştirirken yeni nasıl değiştireceğimizi gereksinim dokümantasyonu söyleyecek. Devam eden geliştirme çalışmalarında hangi kısımları değiştiriyorsanız, değişikliğin tanımı ve tasarımı sırasında iskeletin bu bölümünü ele alıp ürünün son halini yansıtacak şekilde düzenleyin. Sonrasında bu düzeltilmiş kısımları güncel tutun.

Yukarıda özetlediğim İskeleti çıkart, gerektikçe altını doldur yaklaşımı ile elinizdeki mevcut dokümansız ürünleri kurumsal gereksinim yönetimine dahil edebilirsiniz.

Tabii tek yöntem bu önerdiğim değildir. Reverse engineering yeteneklerine sahip araçları kullanarak daha kısa zamanda sonuç elde etmeniz mümkündür. Kullanımı takip ederek davranış profili oluşturmak ve buna dayalı modeller üretmek bazı araçları kullanarak mümkündür.

Reklamlar
Bu yazı Yazılım mühendisliği içinde yayınlandı. Kalıcı bağlantıyı yer imlerinize ekleyin.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google fotoğrafı

Google hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s