100. yazımdan sonra Gürol Beyden aşağıdaki e-postayı aldım. Birilerinin bu tür konulara kafa yorduğunu görmek sevindirici.
|
SAYIN GÜRKAN BEY, Yeni yaşınızı kutlar, nice güzel yaşları sevdiklerinizle geçirmenizi temenni ediyorum. 100.yazınızla ilgili bir sorum olacaktı. Burada bahsi geçen “gereksinim yönetimi”, yazılım kalite güvencesi içerisinde bir parça olarak mı algılanmalı yoksa, yazılım çalışmaları yapan kişilerin oluşturacakları bir kontrol mekanizması olarak mı algılanması gerekmektedir? Böyle bir yönetim kavramı veya bunun geliştirilmesi şirketlerin hangi birimi tarafından uygulanmalıdır? Bir sorumda, önereceğiz bir kitap varmı bunlarla ilgili olarak? Daha önce vermiş olduğunuz öneriler için de teşekkür ederim. İYİ ÇALIŞMALAR SEVGİ VE SAYGILARIMLA GÜROL GÜRSES |
Kutlaman için teşekkür ederim.
Gereksinim Analizi basit olarak müşterinin ihtiyaçlarını analiz ettiğimiz adım diyebiliriz. Projenin başında müşteri gelir ve problemlerini anlatır sende oturup bunları analiz edersin. Yönetimini ise Business Analyst yada Analist Yazılım Uzmanı yapar. Üretilen her türlü döküman belli onay kademelerinden geçeceği ve zaman içinde değişikliğe uğrayacağı için bu şarttır.
Bunun kalite kontrolü içinse üretilen her türlü senaryonun müşteri tarafından onaylanması gerekir. Böylece ortaya çıkardığımız her gereksinimin müşterinin ihtiyacı olan gereksinimler olduğunu söyleyebiliriz. Boşuna ürettiğimiz bir şey olmaması gerekir. Gereksinim Yönetimi Yazılım Kalite Güvencesi içinde bir parça olarak algılanabilir. Örneğin IEEE 829 (Yazılım testi dökümantasyonu) gibi bir standardı uyguluyorsak birde bunların doğru kullanılıp kullanılmadığını tetkik edecek denetleme mekanizmaları oluşturmamız gerekir. Bu mekanizmalar Yazılım Kalite Güvencesi kapsamına girer. Yani bir uyguladığımız metod var birde bu metodun doğru uygulanıp uygulanmadığını test edecek başka bir metod var. Örneğin çeşitli dökümanlar için belli şablonlar var ve bunlar kullanılarak dökümantasyon oluşturmanız gerekiyor. Ama tabii zaman içinde ekibin yada kişilerin karşı koyması ile bazılarını değiştirdiniz yada tamamı ile ortadan kaldırdınız. İşte o zaman metodoloji polisi gelip size hesap sorar.
Yazılım Geliştirme süreci içinde hangi metodu kullanırsak kullanalım, her adımdan sonra bir test koyarak üretilen materyallerin doğruluğunu ölçebiliriz. Kimi zaman müşteri, kimi zaman test ekipleri yada genel konuşmak gerekirse projede payı olan herkes bir nevi test yapmalıdır ki sonuçta üretilecek yazılım hem müşterinin ihtiyaçlarına tam olarak vecap verebilsin hemde yazılım olarak doğru çalışsın.
Örneğin Master of Software Engineering okurken Verification & Validation diye bir ders gördük. Bu derste V&V programlarını mevcut metodoloji içine nasıl entegre edeceğimizi, Risk yönetimini, Inspection yöntemlerini ve IEEE 829 kurallarını gördük. TQM konularına da girdik. Sonuçta elde ettiğim pratik yöntemleri günlük hayatımda kullanıyorum. Okuduğumuz kitaplardan bir tanesi “V&V of Modern Software Systems” yazarlar SchulmeyerveMacKenzie. Alıp okumanı tavsiye ederim.
Projenin boyutuna ve firmanın finansman yeterliliğine göre bence bir Quality Assurance uzmanı muhakkak gerekli. Firma içinde kullanılan yazılım geliştirme metodolojisini çok iyi bilmelidirler ki kalite kontrol aşamalarını entegre edebilsinler. Ayrıca projeya katkısı olan herkes ile doğrudan konuşurlar. Bu işin outsource (taşeron) edilmesi düşünülemeyecek bir konu. Hem fikirleriniz çalınabilir hemde taşeronun kalitesinden emin olamayabilirsiniz. QA uzmanı birden fazla projeye de bakıyor olabilir. QA uzmanını her türlü testleri yapacak kişi olarak görmemek lazım. Örneğin oturup kullanılabilirlik testlerini yapmaz. bunun için HCI uzmanları vardır. Ama kullanılabilirlik testlerinin sonuçlarını değerlendirmek kesinlikle işleri arasındadır.
Gereksinim Yönetimi için yazılımlar da mevcuttur. Gartner raporlarından “Agile Requirements Definition and Management Will Benefit Application Development” raporunda belirtilen yazılımları aynen listeliyorum.
En çok bilinen/kullanılan gereksinim yönetimi araçları
- IBM Rational Requisite Pro (Bunu kullandım fakat Rational SoDA olmadan raporlamak çok güç)
- Borland CaliberRM (Bunun bir de VS Team System eklentisi var, trial indirip kurdum harika bir şey)
- Serana Requirements / Traceability Management
- Telelogic DOORS
Daha az bilinen araçlar ise:
- Apptero 2004
- Axure Software Solutions Rapid Prototyper
- Compuware Reconcile (QA Center ve DevPartner ile kullanılıyor)
- Goda Software Analyst Pro
- iRise Application Simulator
- MKS Requirements 2005 (Integrity Manager ile)
- Sofea Profesy
- SpeeDev RM
- SteelTrace Catalyze
- TCP Integral Requisite Analyzer
Sistem Mühendisliği üzerine gereksinim yönetimi araçları:
- 3SL Cradle
- UGS Teamcenter
- ViewSet Pace
- Vitech Core
Maalesef hepsinin linklerini veremiyorum. Google’dan aratabilirsiniz.
Yukarıda bahsettiğim rapordan bir alıntı yapayım. Raporu sitede verecektim fakat lisans olayı yüzünden dokunmayayım dedim. Gartner avukatları ile uğraşmak istemem 
. İsteyen olursa raporu e-posta ile gönderebilirim.
Gereksinimlerin toplanması ve yönetimindeki esneklik, yazılım geliştirme sürecinin ne kadar disiplinli olduğunu gösterir. Gereksinim toplama ve yönetme işlerini otomatize etmiş yazılım geliştirme firmaları değişiklik kontrolünü daha iyi destekler, testlerde verimlilik kazanır ve gelecekte ortaya çıkacak bakım ve değişiklik işlerinin yükünü azaltırlar. |
Öte yandan kalite subjektif bir olgudur. Kişiden kişiye değişir. Bir kişinin sevdiğini diğeri beğenmez. Pirsig ikilemlerinde şöyle laflar geçer:
Eğer bir nesne kaliteli ise neden bilimsel araçlar ile kaliteyi ölçemiyoruz?
Eğer kalite subjektif ise ve sadece gözlemcinin kanısı ise o zaman kalite sadece neyi beğendiğinize verilecek şık bir sıfattır.
IEEE ise olaya biraz daha açıklık getirmiş:
Bir sistemin, modülün yada sürecin tanımlanmış gereksinimlere yada müşteri veya kullanıcı ihtiyaç ve beklentilerine uyma derecesidir.
Weinberg ise hataların bulunmadığı durumları kaliteli olarak varsaymıştır.
Umarım anlattıklarım yararlı olur yada daha fazla soru sormanız için zemin hazırlar.
