gereks*n*m de****m kontrolü

GEREKSİNİM DEĞİŞİM
KONTROLÜ
Sevilay Tanış
Konular
1. Yazılım Gereksinim Değişimlerinin Sınıflandırılması
2. Business Process Model
Yazılım Gereksinim
Değişimlerinin Sınıflanadırılması
• Değişik sınıflandırma metotları olmasına rağmen
bunların izlenebileceği ve yönetilebileceği metot
yoktur. Bu kısımda gereksinimler sınıflandırılarak
değişiklik yönetimi anlatılacaktır. Sınıflar:
Market(Pazar)
Organizasyon
Proje Vizyonu
Spesifikasyonlar
Çözüm
Giriş
• Yazılım gereksinimleri yazılım geliştirme süresince
devam eder.
• Bu kısımdaki amaç değişikleri sınıflandırarak
ölçülebilir hale getirmektir.
Kaynak Alanlarının
Açıklaması
Yapılan Çalışmada
Cevaplanacak Sorular
1. Değişiklik maliyeti nedir?
2. Değişiklik değeri nedir?
3. Şans yüzdesi ve ilgili değişiklik kusurları nelerdir?
4. Gerekli paydaşların sayısı ne olmalıdır?
5.Değişiklikler bulunurken gerçekleşen aktiviteler
nelerdir?
6. Proje yönetim kontrol seviyesi nedir?
Goal QuestionMetric (GQM) metrikleriyle bu sorular
cevaplanır. UML modelleme kullanarak sonuçlar
gösterilir.
İlgili Çalışma
Çalışma Tasarımı:
Analiz değişiklikleri ele alındı
İlgili Çalışma
Çalışma İçeriği:
Organizasyon: Araştırmadaki firmanın 300 personeli var
ve BT çözümleri sunmaktadır.
Proje:
Devlet sektöründe geliştirilen proje ele alınmıştır.
Tahmini maliyet 1.000.000 poundu aşmaktadır.
15 yazılımcı ve analist bulunmaktadır.
Waterflow yaşam döngüsü kullanılmıştır.
Proje Nisan 2009 da başlayıp, Ağustos 2010 da sona
ermiştir.
Veriler yaşam döngüsü süresince toplanmıştır.
İlgili Çalışma
Veri Belirleme:
Akademik çalışma olduğundan dolayı değişiklik
yönetimi veri tabanından veriler toplandı.
GQM(Goal Question Metric) araştrıcılar ve 2 proje
yöneticisi tarafından kullanıldı.
Maliyetle ilgili sorular(1-2), Yönetimle ilgili sorular(2-6)
değişiklikleri yönetmek adına oluşturuldu.
İlgili Çalışma
Veri Toplama Protokolü:
Değişiklik bulunduğunda veriler analist ya da proje
yöneticisi tarafından excelde toplanır. Başlangıç
aşamasında iki ayda bir toplantılar düzenlenerek
değişiklikler gözden geçirilir.
İlgili Çalışma
Veri Doğrulama:
Her bir kayıt için doğru verilerin toplanıp toplanmadığı
için araştırmalar yapılır.
İlgili Çalışma
Veri İnceleme Süreci:
Veri toplantılarında veri doğrulamanın yanında her bir
değişiklik alanında tekrar gözden geçirme gerekiyorsa
sınıflandırma değişikliği yapılır. Örneğin «New Maket
Technology» değişikliği «Market » alanına eklenir.
İlgili Çalışma
Analiz İşlemleri:
Hipotezler araştırma sorularını ifade eder. Örneğin:
S1: Değişiklik alanına dayanarak maliyette farklılıklar
var mıdır?
C1: Değişiklik alanları arasında önemli maliyet farklılıklar
vardır.
İlgili Çalışma
Sonuçlar
Geliştirme Aşamasında Genel Görünüm:
Proje başlangıcında 16 aylık sürede 282 gereksinim
değişikliği görülmüştür.
2405.5 gün maliyet ortaya çıkmış buda proje maliyetini
%50 aşmıştır.
Sonuçlar
Tabloda bulunan değişiklikler ve değişiklik kaynak
alanları gösterilmektedir. Şekilde görüldüğü gibi genel
olarak UAT ve D&C aşamalarında değişiklikler daha
fazla görülmüştür
Sonuçlar
Değişiklik Maliyeti:
Şekildeki gibi değişiklik maliyeti eşit olarak
dağılmamıştır.
Sonuçlar
Tabloda değişiklik alanlarındaki maliyet gösterilmiştir.
Maliyetin çoğu başlangıç aşamasında olmasına
rağmen UAT aşamasında da yüksek maliyet elde
edilmiştir.
Sonuçlar
Şekilde her bir değişim alanındaki maliyet gösterilmiştir.
Eğer tüm maliyet gereksinim alanının maliyetinden
büyükse , değişiklikler ortalama maliyetten çok daha
pahalıdır.
Sonuçlar
S1: Değişiklik maliyeti nedir?
C1: Değişim maliyeti değişim alanına göre
değişmektedir. En maliyetli değişim Organizasyon
alanındayken en az maliyet Çözüm alanında
gerçekleşmiştir.
Sonuçlar
Değer Değişimi:
Değişikliklerin yarısı «Very Low» değerindedir. Bu
gereksinimlerin %74’ü gereksinim alanında
oluşturulmaktadır.
Sonuçlar
S2: Değişiklik değeri nedir?
C2: Büyük değer değişikliği organizasyon aşamasında
oluşurken en azı sonuç alanında oluştu.
Sonuçlar
Bulgu:
Değişiklik sistem fonksiyoneletisindeki hataları
düzeltmek için bir fırsattır.
Değişiklik 1677 gün olarak hesaplanmış
Bulgu 559 gün maliyeti olarak hesaplanmıştır,
bulguların %56 sı çözüm alanında oluşmaktadır.
Sonuçlar
S3: Şans yüzdesi ve ilgili değişiklik kusurları nelerdir?
C3: Bulgular alanlara göre eşit dağılmamıştır. Değişim
genel olarak organizasyon ve vizyonda görünürken,
bulgu en çok gereksinim spesifikasyon ve çözüm
aşamasında görülmektedir.
Sonuçlar
Paydaş Sayısı:
Değişiklik bir paydaş tarafından yada müşterisiz verilmiş
karar olabilir. Paydaş sayısı 3 demek 3 veya daha fazla
paydaş değişikliği kabul etmiştir anlamına gelir. Paydaş
sayısı arttıkça maliyette artar.
Sonuçlar
S4:Gerekli paydaşların sayısı ne olmalıdır?
C4: Hipoteze göre paydaş dağılımı eşit değildir. En çok
organizasyon ve vizyonda değişiklik için paydaş
kullanılmıştır.
Sonuçlar
Bulgu Aktiviteleri:
Sonuçlar
S5:Değişiklikler bulunurken gerçekleşen aktiviteler
nelerdir?
C5: Yetersiz veriden ötürü test edilemedi.
Sonuçlar
Proje Yönetim Kontrolü
Waterflow yaşam döngüsü kullanıldığından tüm
gereksinimler başlangıç aşamasında belirlendi. Proje
yönetimi için bu gereksinimlerin ne kadar erken
keşfedildiği önemlidir.
Sonuçlar
Sonuçlar
S6: Proje yönetim kontrol seviyesi nedir?
C6: Proje Yönetimi(PM) her alanda farklılık
göstermektedir.
Sonuçlar
Yapılan çalışmada gereksinimlerde yapılan değişiklikler
nekadar geç olursa, yazılım projesine vereceği zarar
okadar büyük olacağı anlaşılmaktadır.
Öyleyse gereksinimlerin doğru çıkarılması ve
olabilecek değişikliklerin tahmininin iyi yapılması yazılım
projelerinde tehlikeyi daha az seviyelere indirir.
Business Process Model kullanarak gereksinim
değişimindeki tehlikeyi azaltabiliriz.
Konular
• 1. Yazılım Gereksinim Değişimlerinin Sınıflandırılması
• 2. Business Process Model
Yazılım Projelerinde
Değişiklik
• Yazılım projelerinde değişiklik herzaman olacaktır.
• Eğer bu değişiklikler uygun şekilde engellenmezse
yazılım kalitesi üzerine negatif etkileri olabilir.
• Negatif etkiler: maliyet aşımı,gecikmeler, memnun
kalmayan müşteriler ve en kötü ihtimalle iptal olan
projelerdir.
Yazılım Projelerinde
Değişiklik
Değişiklik örnekleri:
• Teknoloji değişiklikleri
• Geliştirme aşamasında problemin daha iyi
anlaşılmasından kaynaklanan değişiklikler
• Prosedüre binayen kullanıcı değişiklik istekleri
• Piyasadaki değişiklikler
• Kanuni değişiklikler
Business Modelling
• Business modelling iş fonksiyonlarının nasıl olduğunu
belirten soyuttur.
• Başlangıç aşamasında business modelling
kullanarak basit çizimler ile iletişim daha rahat
sağlanır. Sistem simule edilebilir.
Business Modelling
Faydaları
•
•
•
•
Kullanıcı katılımı artırılır
Modelleme formal ya da informal olabilir.
Şimdiki ve ilerki durumlar modellenebilir.
Yazılım geliştirmenin başka alanlarında kullanılabilir.
Business Modelling ve
Yazılım Geliştirme
• Business modelling yazılım geliştirme sürecinin
başlangıç aşamasında kullanılır, böylece uzun
vadeli, güçlü kaliteli yazılımlar oluşturulur.
• Brier et al’e göre gereksinim mühendisliği müşteri
paydaşları, yazılım geliştiricilerine kadar
genişletilmelidir, yani yazılım büyük sosyal teknik
sistemidir.
Business Modelling ve
Yazılım Geliştirme
• Business modelling iş içeriğini amacını kurallarını
görselleştirir, buda gereksinimlerin elde edilmesinde
önemli rol alır.
• Business modelling kullanarak istenilen sistemin nasıl
olması gerektiği belirtilerek, paydaşların teknik
kararlarını almalarında yardımcı olur.
Business Modelling ve
Yazılım Geliştirme
• Şekilde görüldüğü gibi problem anlamadaki
değişiklik, gereksinim değişikliğine yansır.
Business Modelling ve
Yazılım Geliştirmer
BPM kullanarak geleneksel yazılım geliştirmeye göre
problem daha iyi anlaşılır.
Business Modelling ve
Yazılım Geliştirme
• BPM kullanılarak paydaşlar arası iletişim daha rahat
sağlanabilir.
BPM Örneği
Sonuç
• Değişimler erken teşhis edilirse, yazılım projeleri daha
az zarar görür.
• BPM kullanarak daha az maliyetli ve kaliteli yazılımlar
elde edilir.
Referanslar
[1] Eystein Mathisen, Kjell Ellingsen, Terje Fallmyr «Using business process
modelling to reduce the effects of requirements changes in software
projects», 2009 2nd International Conference on Adaptive Science &
Technology
[2] Study Sharon McGee1 and Des Greer2 School of Electronics,
Electrical Engineering and Computer Science Queens University Belfast,
United Kingdom {1smcgee08|2des.greer}@qub.ac.uk
«Software Requirements Change Taxonomy: Evaluation by Case « , 2011
IEEE 19th International Requirements Engineering Conference
[3]Muhammad Wasim Bhatti,Farah Hayat, Nadeem Ehsan «A
Methodology to Manage the Changing Requirements of a Software
Project»2010 International Conference on Computer Information
Systems and Industrial Managment Applications