WATERFALL METODLARDA CR (CHANGE REQUEST) YÖNETİMİ

Projelerin deadline’ında bitmesine en çok etki eden, re-worklerin azaltılmasındaki en önemli unsur, analizler sırasında veya sonrasında müşteri tarafından iletilen CR’ların (change request) yönetimi konusudur.

CR'lar yeni bir talep olabileceği gibi, değiştirilen gereksinimler de olabilirler.

CR'ların oluşma nedenleri nelerdir?

1.Analist kaynaklı (eksik analiz yapılması sebebi ile oluşan) CR'lar:

a.İhtiyacın doğru sorularla çözümlenememiş olmasından kaynaklı, belirlenememiş gereksinimlerin neden olduğu CR’lar: Müşterinin ihtiyaçlarının çözümlendiği gereksinim belirleme aşamasında analistin rolü çok önemlidir.İyi bir analist doğru sorularla ihtiyacı çözümleyebilir. Ama doğru soruları sorabilmek için yeterli hazırlık yapmayan bir analistin soracağı sorular ve onun çıktısı alacağı cevaplar yetersiz olur. Analiz eksik olarak tamamlanır. Bu da CR oluşmasına neden olur.

b.Analistin iş ürününün geliştirileceği sistemi(entegrasyon noktalarını, kısıtlarını, bağımlılıklarını) tanımaması sebebi ile oluşan Cr’lar: İş ürününün sistemde nasıl handle edileceğini bilmeyen analist, doğru soruları soramayacağından, eksik analiz yapılmasına neden olabilir. Sistemde işin ne şekilde handle edileceğini kurgulayabilen, sistemin kısıtlarını bağımlılıklarını değerlendirebilen bir analist, nitelikli gereksinimler ortaya çıkarır ve CR çıkma olasılığı minimize edilmiş olur.

2.Müşterinin, konusuna hakim olmaması sebebi ile, ihtiyaçların eksik iletilmesinden kaynaklanan CR’lar: Bence CR oluşmasında en çok etkili olan faktör de budur. Müşteriler iş ürünü ile ilgili bilgiye sahip olmadıklarında, ne istediklerini de doğru şekilde iletemezler.Bu sebeple; gereksinim analizi yapıldığı aşamada, talep sahibi müşterinin konu hakkında bilgi sahibi olması, analitik düşünmeye yatkın olması ve karar alabilen yetkinlikte olması önemlidir.

CR kabulü neye göre yapılmalıdır?

CR kabulünün neye göre yapılacağının bilinmesi gerekir. Analizin belli bir aşamasında, müşteri ile anlaşarak gereksinimlerle ilgili bir baseline almak gerekir.
İş ürünü prod’a çıkana kadar, ya da analiz bitene kadar, CR’ları kabul etmek doğru bir yaklaşım değildir.

•Çünkü prod’a çıkana kadar geçen sürede analiz, tasarım, kodlama, test aşamalarından birinde bir CR iletilmesi, o aşamaya gelene kadar yapılan tüm çalışmalarda re- work’e neden olabilir. Ve yazılım mühendislik süreci aşamalarının hangi aşamasında çıktığına göre de maliyeti artar.(Sırasıyla: Analiz,Tasarım,Yazılım,Test) Örneğin test aşamasında çıkmış bir CR ‘ın maliyeti, analiz aşamasında iletilen bir CR’ın maliyetinden daha yüksektir.

•Analiz aşaması boyunca CR iletilmesini kabul etmek de doğru bir yaklaşım değildir. Müşteri analiz bitene kadar sürekli değişiklik yaparsa, bu sefer analizler proje takviminde belirtilen sürede tamamlanamaz.

CR yönetimi yapabilmek için, gereksinimlerle ilgili baseline’ın alınması gereken en doğru zaman, detay analize geçilmeden, gereksinimlerin netleştirilip kapsamın belirlendiği aşama olmalıdır.

Bu aşamadan sonra prod.’a çıkana kadar geçen sürede iletilen, her yeni gereksinim veya, gereksinimlerle ilgili baseline alındığı zamanda belirtilen gereksinimlerle ilgili her değiştirilen gereksinim, CR olarak kabul edilmelidir.