Bugün benim doğum günüm. Tam 32 sene önce bugün dünyaya geldim. Türkçe blogumda da 100. yazım. Çok fazla yazan bir adam değilim. Bir şeyler yazmak için hele ki sektör ile ilgili olacaksa ilham gelmesi yada birilerinin beni kızdırması lazım. Ancak o zaman sular seller gibi yazabiliyorum. Tabii birde yazdıklarımın kalitesi ve doğruluğu mümkün olduğu kadar yüksek olmalı.
Bu doğum günü ve 100. yazı olması vesilesi ile önemli bir şeylerden bahsedeyim.
Yazılım geliştirme alanında gereksinim analizi aşamasını bilirsiniz. Müşterinin ihtiyaçlarını veya problemlerini analiz ederek bilgisayar ortamında nasıl çözüm bulacağınızı araştırırsınız. Müşterinin farkında olduğu veya olmadığı tüm gereksinimlerini ortaya çıkarır çeşitli yöntemler ile bunları dosyalar ve sistemi modellemeye çalışırsınız. Bu gereksinimleri ne kadar iyi yönetirseniz sonuçta ortaya çıkacak üründe o kadar hatasız olacaktır.
Gereksinim Yönetimi
Gereksinim analizi sırasında ortaya çıkabilecek ürünlere bir bakalım.
- Senaryolar
- İş akışı diyagramları
- İş kuralları
- Hedef ve Kapsam belgesi
- Data definition diyagramları
- Dahili ve harici arayüz gereksinimleri
- Çeşitli UML diyagramları
- Sistem gereksinimleri spesifikasyonları
- Test senaryoları
- Prototipler
- Sürüm politikası
- Değişiklik istek belgesi
- Güvenlik politikası
- Risk dökümanı
Bu listeyi daha uzatmak mümkün. Bunlar ilk etapta aklıma gelen şeyler. Daha kod yazmaya geçmeden elimizde bir sürü döküman oluşuyor. Müşteri isteklerini değiştirebilir, yenilerini ekleyebilir veya bazı gereksiz gördüğü kısımları silebilir. Bu kadar fazla ürünün yönetilmesi kesinlikle mecburidir. Aksi takdirde ipin ucunu kaçırırsak ve bazı gereksinimleri müşterinin istediği gibi değiştirmezsek bu proje salıncak hikayesine döner.
Müşteri odaklı bir yazılım firmasının en büyük bilgi kaynağı müşteridir. Çünkü işi bilen ve her türlü girdi çıktısını tanımlayabilecek tek kişidir. Programı hatasız yazabilmek için müşteriyi sürecin her türlü aşamasına sokmanız gerekir ve müşterinin ağzından çıkan her türlü bilgi kayıt edilmeli ve iyi yönetilmelidir.
Bunlar yazılı döküman olduğuna göre rahatça bir kelime işlem programı (Word, wiki, Open Offıce vs.) ile hazırlayacağınız şablonları kullanarak belli bir biçimde kayıt edilmelerini sağlayabilirsiniz. Her türlü dökümanın bir şablonu olunca işler biraz daha kolaylaşır.
İkinci aşamada bunların sürüm kontrolünü yapmalısınız. Böylece kim ne değiştirmiş görmek mümkün olur. Örneğin wiki ortamında kimin ne değiştirdiğini görmek kolay olur yada Subversion gibi bir program ile sürüm kontrolünü yapabilirsiniz.
Değişikliklerin onaylanması içinde bir iş akışı düzenleyip belgelere uygulanacak değişikliklerin onaylanmasını sağlayabilirsiniz. Onay ya müşteriden yada bu iş ile ilgili firma içindeki birimden gelecektir. Değişiklik ancak onaylanırsa (değişiklik istek belgesi bu iş içindir) esas belge içine gömülür.
Son hali onaylanan belgeler üzerinde değişiklik istenirse; bu değişikliğin etkilediği diğer alanlar çok iyi tanımlanmalıdır. Eğer maliyeti ve zamanı arttıran bir değişiklik ise başka bir sürüme bırakılabilir. Bu da sürüm politikası belgesinde belirtilmelidir.
Her yazılan fonksiyonun hangi senaryoda nasıl kullanıldığını gösterecek akış şemaları ile koddan gereksinimlere doğru takibi kolaştıracak UML diyagramları oluşturmalısınız. İlk sürüm verildiğinde boşuna yazılmış kod var mı yada boşuna üretilmiş bir senaryo var mı analiz edebilirsiniz. Bu size ürettiğiniz ürünün gereksinimleri ne kadar kapsadığı hakkında bilgi verir.
Evet, toparlamak gerekirse gereksinim yönetimi çok önemli bir konu ve önümüzü görerek kod yazmak istiyorsak şart. Düşünün petrol yüklü bir tankeri yönetiyorsunuz ve sis içinde yol alıyorsunuz. Bir yere çarpsanız hem çevre kirliliğine hemde para kaybına neden olacaksınız. Ayrıca kaybedeceğiniz itibar da cabası. Böyle bir riski almaktansa bir iki radar sistemine yatırım yapmak yada sisin kaybolması için beklemek en akıllıca iş olur. Gereksinimleri akıllıca yönetirsek üstesinden gelemeyeceğimiz proje yok değil mi?