Analiz, karmaşıklığın çözümlenmesidir. Bütünü parçalara ayırırken oluşturulan her parçanın da anlamlı olmasına dikkat edilmelidir. Hepimizin çok iyi bildiği analitik bakış açısı herkes için en önemli yeteneklerden bir tanesidir.

Gereksinim Analizi

Daha önce olgunlaşmış bir fikir gerekliliğinden ve bu fikrin fizibilitesinin yapılmasında bahsetmiştik. Bu aşamalar; iş birimi, talep sahibi, proje sponsoru, iş analisti veya proje yöneticisi tarafından yapılabilir.

Bir sonraki aşamamız ise gereksinim analizidir. Fikri analiz edip gereksinimleri netleştirmek ve yazılımcılara ne yapılması gerektiğini ifade etmek bu aşamada yapılması gerekendir. Bu açıdan baktığımızda hepimizin en azından duyduğu tümdengelim (genelden özele) bakış açımız olmalıdır. Analiz bu açıdan Black-box’tan White-box’a uzanan bir süreçtir. (Analiz sürecinden bu şekilde bahsederken şu hatırlatmayı yapalım; test ise tam tersi bir süreç olarak özelden genele ilerlemelidir.)

Gereksinim analizini yaparken önemli olan öncelikleri doğru belirlemektir. Waterfall bir projede oluşturulacak çözümün tamamı için yapılacak analiz, agile süreçler söz konusu olduğundan doğru şekilde bölünmelidir. Agile için doğru bölümleme ise Core’u doğru belirleyerek, bu core üzerine modüller şeklinde bir yapı oluşturmak, tüm paydaşların işini kolaylaştıracaktır.  Core, çalışacak en küçük parçayı ifade ederken üzerine eklenecek her bir modül de çalışabilir ve UAT’ye (User Acceptance Test) çıkabilir parçalar olarak seçilmelidir.

Gereksinim analizi yazılım geliştirme sürecinin ilk aşamasıdır. Bu analiz genel bir kapsam planlayıp, bu kapsamın sınırlarına sadık kalınarak da yapılabilir veya bu ara popüler olduğu şekliyle adam/gün bazlı faturalandırma ile çalışan şirketler için sürekli iteratif ve sonu görünmeyen biçimde ilerleyen bir süreç de olabilir. Eğer sonu görünmeyen bir süreç ile çalışılıyorsa en azından nerede durulup, oluşturulan projenin bir değer olarak sunulacağı mutlaka kararlaştırılmalıdır. Yoksa işi yapanın da projenin de performansı ölçülemez.

Gereksinim Türleri

Gereksinimler farklı başlıklarla değerlendirilebilir. Bu farklı başlıklardan en popüler olanlar aşağıda listelenmiştir ve tamamı tek bir analistin sorumluluğunda olmayabilir.

  • İş / Kullanıcı Gereksinimleri (Business Requirements) (İş analisti tarafından yapılır)
  • İşlevsel Gereksinimler (İş analisti tarafından yapılır)
    • Fonksiyonel Gereksinimler
    • Fonksiyonel olmayan Gereksinimler
  • Yazılım Gereksinimleri (Software Requirements) (Teknik analist veya yazılımcı tarafından yapılır)
    • Mimari Gereksinimler
    • Yapısal Gereksinimler
    • Sistemsel Gereksinimler

İlgili başlıkların tamamı veya daha fazlası hakkında internette fazlasıyla bilgi bulunmaktadır. Özellikle geçiş gereksinimleri mutlaka ortaya konulmalıdır. Bu analizler user story, use case, aktivite/veri akış diyagramları, etkileşim diyagramları gibi farklı teknikler ile ortaya konulabilir. Scrum ile ilerleyen ve zaman kısıdının fazla olduğu projelerde timeboxing gibi teknikler uygulanabilir.

Gereksinimler belirlenirken kullanıcı arayüzleri (UI) mutlaka belirlenmelidir. Bir mock-up uygulaması veya daha basit olarak visio ile bunları çizmeniz gerekebilir.

Püf Noktalar

Analiz soru sorma işidir. En iyi analist doğru soruları sorandır. Analist için bir diğer önemli nokta ise nerede duracağını bilmektir çünkü sorarak asla dibi bulunmaz bir kuyuya dalmaya başlamış olabilir. Durulacak noktaları doğru belirlemek de analizde ne kadar yetkin olunduğunu ifade etmek için büyük önem arz etmektedir.

Gözlem gücü bir diğer önemli noktadır. Bunu bir örnek ile açıklayayım; bir programı değiştirmeye karar veren bir firmada mevcutta kullanılmakta olan  programın geliştirilebilecek yönlerine dair bir araştırma yaptığınızı düşünelim. Son kullanıcının yanına gidip, bir görebilir miyiz nasıl çalışıyorsunuz dediniz. Kullanıcı “başlat>tüm programlar” programı açmaya koyuldu. Analistin ilk düşünmesi gereken “Masaüstünde bir kısayolu yok, demek ki çok kullanılmıyor” olmalıdır.

Bütün projelerin gereksinimleri vardır. Burada önemli olan proje paydaşlarının ihtiyaçlarını, isteklerini ve beklentilerini (needs, wants, expectations) doğru adresleyebilmektir. Bunu yaparken varsa tespit edilen riskleri de belirtmek işin başında beklenmedik durumların ortaya konulmasını sağlar. Eğer analiz aşamasında ortaya konulmasa bile analizi okuyan ilgililerin nerede risk olduğunu göreceği kadar açık bir analiz oluşturmak proje hızını ve projeye analist katkısını arttıracaktır.

Gereksinimleri toplamada; workshoplar, brainstorming aktiviteleri, mind maps, anketler, gözlemleme, grup kararları, tarihsel kayıtları inceleme, benchmark gibi farklı teknikler kullanılabilir. Hangi teknik (veya teknikler) ile ilerleneceği proje özelinde seçilir.

Analiz dokümanınızı mümkün olduğunca kısa ve anlaşılır tutmak ise analistin misyonu olmalıdır. Unutmayın analiziniz ile eğer yoksa kapsam onayı alınacaktır ve tüm paydaşlar yapılan analiz ile projeye hakim olacaklardır. Kimsenin iş hayatında 900 sayfalık bir analiz okuduğunu görmedim. Dolaysıyla her paydaşa ilgilendiği alana dair yeterli bilgiyi sunarken kimseyi doküman okuma yükü altında ezmemek gerekir. Hazırladığınız analizi okumak yerine, size sormak daha kolay gelirse; proje süresince bu yükün altında ezileceksiniz demektir 🙂

Yeterli detay düzeyine de bir örnek vereyim ve değerlendirmenize bırakayım. Daha önce üzerinde çalıştığım bir projede hücresel gösterim ve hücre dolu/boşun renk ile ifade edilmesi şeklinde bir çalışma vardı. Yazılımda ilk gelen prototipi incelediğimizde dolu hücrelerin yeşil, boş hücrelerin ise kırmızı ile ifade edildiğini gördük. Yani bazen çalıştığınız insanlar tüm insanlığın kabullerine kırmızı ile yeşili ters kullanarak meydan okumak isteyebilir. (Hala bu durumu düşünmeden yapacak kadar malak olduklarını kabullenmek istemiyorum.)

Analizde asıl olan neye ihtiyaç olduğunu doğru anlamak ve anlatmaktır. Bir teknik kullanımı bilmek gibi konular her zaman ikinci planda olmalıdır. Yazılım dünyasından aşina olduğumuz üzere; bir metodoloji, teknik ya da framework’ü yapılması gereken işin önüne geçirmeye çalışmak, bilişim sektörünün insanları yıpratmasının en büyük sebebi ve  saçmalığıdır.

CEVAP VER

Please enter your comment!
Please enter your name here