=Paper=
{{Paper
|id=Vol-1980/UYMS17_paper_86
|storemode=property
|title=Bir CMMI Seviye 5 Organizasyonel Performans Yonetim Projesi Ornegi: Kod Kalitesini Iyilestirmek (A CMMI Level 5 Organizational Performance Management Project Example: Improving Code Quality)
|pdfUrl=https://ceur-ws.org/Vol-1980/UYMS17_paper_86.pdf
|volume=Vol-1980
|authors=Deniz Gungor,Yasemin Yigit Kuru,Pinar Orgun,Esma Elbir
|dblpUrl=https://dblp.org/rec/conf/uyms/GungorKOE17
}}
==Bir CMMI Seviye 5 Organizasyonel Performans Yonetim Projesi Ornegi: Kod Kalitesini Iyilestirmek (A CMMI Level 5 Organizational Performance Management Project Example: Improving Code Quality)==
https://ceur-ws.org/Vol-1980/UYMS17_paper_86.pdf
Bir CMMI Seviye 5 Organizasyonel Performans Yönetim
Projesi Örneği: Kod Kalitesini İyileştirmek
Deniz GUNGOR, Yasemin Yiğit KURU, Pinar ORGUN, Esma ELBİR
Huawei Turkey Research & Development Center Software Quality Department, Istanbul/Tur-
key
deniz.gungor@huawei.com, yasemin.yigit.kuru@huawei.com,
pinar.orgun@huawei.com, esma.ayan@huawei.com
Özet. Yazılım süreçleri için Bütünleşik Yetenek Olgunluk Modeli olan CMMI’a
göre, bir organizasyonun kendi iş hedeflerini yakalayabilmesi için o
organizasyonun performansını proaktif bir şekilde yönetmek gerekmektedir. Bu
deneyim bildirisi, yazılımda geliştirmeler yapan Huawei Türkiye Arge
Merkezi’nin CMMI 5.olgunluk seviyesi süreç alanlarından Organizasyonel
Performans Yönetimi kapsamında gerçekleştirdiği yazılım kod kalitesini
iyileştirme projesini içermektedir. İyileştirme projesi, Huawei Türkiye Arge’nin
iş hedeflerine bağlı kalite süreç performans hedeflerinden biri olan Teslimat
Sonrası Hata Yoğunluğu’nu azaltma hedefi doğrultusunda kod kalitesini
iyileştirme üzerine hazırlanmıştır. Aynı zamanda projenin amacı, yapılan
analizler, aksiyon planı ve sonuç değerlendirmesi hakkında bilgi verilmiştir. Bu
deneyim bildirisinin yazılım kod kalitesini iyileştirmek isteyen ve CMMI Seviye
5 sertifikası almış veya alacak olan kurum/kuruluşlara örnek olacağı tahmin
edilmektedir.
Anahtar Kelimeler: Süreç İyileştirme, CMMI Seviye 5, Organizasyonel Performans Yö-
netimi, Yazılım Kod Kalitesi
A CMMI Level 5 Organizational Performance
Management Project Example: Improving Code Quality
Deniz GUNGOR, Yasemin Yiğit KURU, Pinar ORGUN, Esma ELBİR
Huawei Turkey Research & Development Center Software Quality Department, Istanbul/Tur-
key
deniz.gungor@huawei.com, yasemin.yigit.kuru@huawei.com,
pinar.orgun@huawei.com, esma.ayan@huawei.com
495
Abstract. According to CMMI, a Capability Maturity Model Integration for soft-
ware processes, to achieve the business goals of an organization, it is necessary
to proactively manage the performance of an organization. This experience report
contains a project to improve the code quality of the Huawei Turkey Research
and Development Center which is developing software, within the Organiza-
tional Performance Management process area of the CMMI 5th level. The im-
provement project is based on improving the software code quality in line with
the reducing Post-Delivery Defect Density (Downstream Defect Density) which
is one of the Huawei Turkey Research and Development Center's quality process
performance objective that is connected with the business goal. Meanwhile, in-
formation was given about the purpose of the project, analysis that has been
made, action plan and the outcome evaluation. It is anticipated that this experi-
ence statement will be an example for institutions / organizations that would like
to improve their software code quality and get certified or will get certify CMMI
Level 5.
Keywords: Process Improvement, CMMI Level 5, Organizational Performance
Management, Software Code Quality.
1 Giriş
CMMI Organizasyonel Performans Yönetimi’nde amaç periyodik olarak iş hedeflerini
kalite süreçperformans hedefleriyle birlikte gözden geçirmek ve gerekirse revize et-
mektir. İş hedeflerinin günün şartlarına göre halen güncel olduğundan ve iş stratejileri
ile aynı doğrultuda olduğundan emin olmak için hedeflerin değerlendirilmesi büyük
önem taşır [1].
İş hedeflerine ulaşıldığının takibinin ve değerlendirmesinin yapılması için bu iş hedef-
leri ile bağlantılı olan başlıca süreç metriklerinin organizasyonda belirlenmiş olması
gerekmektedir. Hedeflerin gözden geçirilmesi aşamasına kadar belirlenen metriklerin
veri alabilme frekansına göre toplanması gerekmektedir. Örnek olarak; belirli miktarda
verisi olan metrikler yıllık bazda değerlendirilebilir, değerlendirme sırasında önceden
belirlenmiş limitlerin ve hedeflerin içinde olup olmadığı kontrol edilir. Kontrol sonu-
cunda limit dışında çıkan ve iş hedeflerini en çok etkileyen metrikler verilerle analiz
edilir ve bu metrikler için iyileştirme projeleri gerçekleştirilebilir. Ayrıca üst yönetim
o yıl odaklanılacak iş hedeflerini stratejik olarak belirleyebilir. Yönetimin stratejik ka-
rarı ve hedefleri etkileyen metrik analiz sonuçları göz önünde bulundurularak iyileş-
tirme projeleri belirlenir. Bu deneyim bildirisinde bilgisi verilen iyileştirme projesinin
amacı, kaliteli ürün teslimatının başlıca hedefine ulaşmak ve iş hedefleriyle aynı doğ-
rultuda olan organizasyonel düzeydeki iyileştirmeleri süreç odaklı ve sistematik bir şe-
kilde uygulamaktır. Bu bildiri, Huawei Türkiye Arge Merkezi’nin süreç hedeflerinden
olan Kaliteli Ürün Teslimatı’nı doğrudan etkileyen Teslimat Sonrası Hata Yoğunluğu
metriğini konu almıştır.
496
2 İş Hedefleri ile Değerlendirme
Huawei Türkiye Arge Merkezi’nde her yıl ana odaklanılacak ana iş alanları ve hedefleri
belirlenir. Bu alanların belirlenmesinde Çin’de konumlanmış olan idare merkezi (He-
adquarter) ve üst yönetim rol oynar. Bu iyileştirme projesinin gerçekleştirildiği yıl olan
2016’da belirlenen ana odaklanılacak iş hedefleri ise Müşteri Memnuniyeti ve Müşte-
ride 0 Kritik Kalite Kazası idi. Bu hedefler aşağıda kısaca açıklanmıştır:
Müşteri Memnuniyeti: Müşteri Memnuniyeti HTRDC’de (Huawei Türkiye Arge
Merkezi) yönetilen ürün veya projelerin çeşitli özellikleri konusunda müşteri beklenti-
sini ve mevcut memnuniyeti anlamak için kullanılan bir ölçüttür.
Müşteride 0 Kritik Kalite Kazası: Bu hedefin amacı teslim edilen ürünler için
müşteride 0 kalite kazası hedefini yakalamaktır. Kritik kalite kazaları, ciddi bir şekilde
son kullanıcıyı etkileyen, müşteri yararına ve itibarına önemli kayıplar getiren, takibi
için acil olarak kaynak tahsis edilmesini gerektiren kritik problemlerdir. Aşağıdaki şekil
Müşteri Memnuniyeti ve Müşteride 0 Kritik Kalite Kazası iş hedeflerinin akışını özet-
ler. (bkz.Şekil. 1)
Şekil. 1. Müşteri Memnuniyeti ve Müşteride 0 Kritik Kalite Kazası İş Hedefleri Akış Şeması
Analizler: 2015 ve 2016 yıllarına ait Teslimat Sonrası Hata Yoğunluğu ve Teslimat
Sırasında Bilinen Hata Yoğunluğu metrikleri hesaplanıp aşağıdaki analiz yapılmıştır.
(bkz.Şekil. 2)
Teslimat Sonrası Hata Yoğunluğu = [(Teslimat Sırasın Bilinen Hata Sayısı + Müşte-
ride Bulunan Hata Sayısı) * 1000 ] / İncelenen Yazılım Paketinin Kod Satırı (1)
Teslimat Sırasında Bilinen Hata Yoğunluğu = (Teslimat Sırasında Açık Kalan Hata
Sayısı * 1000) / İncelenen Yazılım Paketinin Kod Satırı (2)
497
Şekil. 2. Yıllık Teslimat Sonrası Hata Yoğunluğu ve Teslimat Sırasında Bilinen Hata Yoğun-
luğu Trendleri
Yorum:Yıl bazındaki verilere bakıldığında Teslimat Sonrası Hata Yoğunluğunun, Tes-
limat Sırasında Bilinen Hata Yoğunluğundan daha fazla olduğu görülmektedir.
3 Problem Analizi
3.1 Genel Hata Analizi
2016 yılında HTRDC bazında yapılan süreç yetkinlik analizine göre, toplam tüm hata-
lar içerisinde teslimat sonrası hataların yüzdesi yüksektir. Hedeflere göre teslimat son-
rası hataların kritik ve major hata içermeyecek şekilde tüm hatalar içindeki yüzdesinin
%5’ten fazla olmaması gerekmektedir. Ancak, mevcut süreç yetkinlik analizi [2] (PCB)
teslimat sonrası hataların, tüm hatalar içindeki yüzdesinin %18 olduğunu göstermekte-
dir. Organizasyonel bazda yapılan kök-neden analizine göre; teslimat sonrası hataların
(Downstream Defect) artmasının nedeni, teslimat sırasında bilinen hatalardan (Delive-
red Open Defect) ve kod gözden geçirme (code review) & geliştirme testi (development
test) aşamalarında kaçan hataların Sistem Tasarım Doğrulama Testi (SDV) ve müşteri
bulgu (post-delivery) hatası olarak sızmasıdır. Organizasyonel bazda analizi yapılan
projelerin süreç yaşam döngülerinde inceleme ve test aşamaları sırasıyla; Gereksinim-
lerin Gözden Geçirilmesi, Tasarımın Gözden Geçirilmesi, Kod Gözden Geçirme, Ge-
liştirme Testi ve Sistem Tasarım Doğrulama Testi şeklindedir. Kaliteli Teslimatı iyi-
leştirmek için, kod gözden geçirme & geliştirme testi süreçlerinin verimliliğini %30
iyileştirmek gerekmektedir (Bkz.Bölüm 3.4). Böylece bu süreçlerden kaçan hataların,
sistem tasarım doğrulama testi ve müşteri bulgu hatası olarak kaçması engellenebilir.
(Teslimat sonrası hatalarda %30 azalma ile). Ayrıca teslimat sonrasına hata sızmasını
azaltmak için teslimat sırasında bilinen hatalar analiz edilerek erken fazlarda önleyici
aksiyonlar alınmalıdır.
2016 yılında yapılmış olan HTRDC süreç yetkinlik analizine göre; tüm hatalar içeri-
sinde (Teslimat sonrası hatalar dahil) SDV fazında bulunan hataların payı en yüksek
oran olan %27’dir. Bu analizde, kod gözden geçirme ve geliştirme testi fazlarında bu-
lunan hataların oranı SDV’ye göre daha azdır.
3.2 Pareto Analizi
Aşağıdaki Pareto Analizi [3] grafiğinde (bkz.Şekil. 3) SDV hatalarının nedenleri çıka-
rılmış ve bu hataların frekansı analiz edilmiştir.
498
Şekil. 3. SDV Hatalarının Sebepleri için Pareto Analizi
Yorum: SDV hataları için yapılan Pareto Analizi grafiği, çoğu SDV hatasının sebebi-
nin kodun mantığı yansıtmaması ve geliştirme testinin yetersiz olması olarak gösteri-
yor.
3.3 Problem Tanımı
Kaliteli teslimatı iyileştirmek için, Kalite Departmanı kod gözden geçirme ve geliştirme
testi fazlarının verimliliğinin %30 artmasını ve böylece SDV ve teslimat sonrası hata-
ların azalacağı sonucuna varmıştır. Analiz edilecek problem, SDV ve teslimat sonrası
hataların sebebini bulmaktır. Ayrıca istatiksel bir programda (Minitab) yapılan İlişki-
lendirme Analizlerine (Correlation Analysis) [4] göre aşağıdaki ilişkiler tespit edilmiş-
tir:
* Teslimat sonrası hatalar ile Kod Gözden Geçirme Hataları arasında negatif yönlü
kuvvetli bir ilişki,
* Teslimat sonrası hatalar ile Geliştirme Testi Hataları arasında negatif yönlükuvvetli
bir ilişki,
* Teslimat sonrası hatalar ile SDV öncesi hatalar arasında negatif yönlü kuvvetli bir
ilişki,
* Teslimat sonrası hatalar ile SDV hataları arasında negatif yönlü kuvvetli bir ilişki
olduğu görülmüştür.
Negatif yönlü ilişki, bir değerin artarken diğerinin azaldığını gösterir. Yapılan analiz-
lerde pozitif yönlü ilişkiye rastlanılmamıştır. İlişkinin negatif/pozitif olduğunun tespi-
tinde korelasyon katsayısının [5] işaretine bakılır; ilişki şiddetini anlamak için ise ko-
relasyon katsayısının değerine bakılır.
3.4 Hedef Belirleme
Projelerde tanımlanan aksiyonlar uygulandığında kod gözden geçirme ve geliştirme
testi süreçlerinde %30 daha fazla efor harcanacağı öngörülmüştür. Efordaki bu artış,
kod gözden geçirme ve geliştirme test süreçlerinde iyileştirme yapılıp, bu aktivitelere
daha fazla vakit harcanacağı içindir. Revize edilmiş (kod gözden geçirme ve geliştirme
testi aşamalarındaki iyileştirmelerin uygulandığı varsayılıyor) hedeflerle birlikte (bkz.
Tablo 1) süreçperformans modeli (PPM) [6] ile yapılan tahminlemeye göre teslimat
sonrası hatalar ve teslimat sırasında bilinen hatalar 0 olarak tahminlenmektedir. (Süreç
Performans Modeli (PPM), Crystal Ball programı ve eski verileri kullanarak tahmin
499
yapabilen istatiksel bir programdır.) Ayrıca SDV hataları duyarlılık analizine [7] göre
(sensivity analysis) artık iç hatalar içerisinde en çok paya sahip değildir ve kod gözden
geçirme & geliştirme test hatalarının payı artmıştır. (bkz. Şekil. 4)
Şekil. 4. SüreçPerformans Modeli ile Revize Edilen Hedeflerle Yapılan Analiz
Yorum: Organizasyon bazında yapılan duyarlılık analizine (sensivity analysis) göre,
erken fazlarda hataların büyük kısmının yakalandığında, SDV’de ve teslimat sonra-
sında daha az hata bulunacağı görünmektedir. SüreçPerformans Modelinde (PPM) re-
vize edilmiş hedeflerle ile tahmin edilen (SüreçPerformans Modeli ile simülasyon ya-
pılarak istenen metriklerin tahminlenmesi) teslimat sonrası hatalar 0’dır, bu da HTRDC
organizasyonel kalite hedefi ile uyuşmaktadır.
İyileştirme projesinde odak noktası olan süreçlere bağlı metriklerin belirlenen hedef-
leri, Tablo 1’de gösterilmiştir. Tablo 1’de bulunan Hedef sütunundaki metrikler, bir
önceki proje hedeflerine göre %30 artmış veya azalmıştır. Kod gözden geçirme ve ge-
liştirme testi hata yoğunluklarının artmasının sebebi, bu fazlarda daha fazla hata yaka-
lanacağının hedeflenmesidir; SDV hata yoğunluğunun azalmasının sebebi ise, bu erken
fazlarda daha fazla hata tespit edileceği ve SDV fazında daha az hata yakalanacağı için-
dir. Hata Yoğunluğu metriğinin birimi ise, Hata Sayısı / 1000 Kod Satırıdır (Kilo Lines
of Code).
Hata Yoğunluğu = Aktivitede Tespit Edilen Hata Sayısı / (İncelenen Yazılım Paketinin
Kod satırı / 1000)
(3)
Tablo 1. SüreçHedefleri
Alt Süreçler Metrik Hedef
Kod Gözden Geçirme Kod Gözden Geçirme 3.76 (Kod Gözden Geçirme
Hata Yoğunluğu Hata Yoğunluğu 30% artış)
Geliştirme Testi Geliştirme Testi Hata Yo- 2.86 (Geliştirme Testi Hata
ğunluğu Yoğunluğu 30% artış)
Sistem Tasarım Doğru- Sistem Tasarım Doğru- 3.24 (SDV Hata Yoğunluğu
lama (SDV) lama Hata Yoğunluğu 30% azalma)
(SDV)
500
4 SüreçAnalizi
4.1 Kök-Neden Analizi
Kalite Departmanı ve ilgili proje yöneticileri veri toplayıp, Teslimat sonrası hataların
ve SDV hatalarının nedenini anlamak için detaylı kök-neden analizi yapmıştır. Kök-
neden analizinde balık kılçığı yöntemi [8] kullanılmıştır. (Bu yöntemde önerilen kök-
nedenler belli kategori başlıkları altında toplanır.) Belirlenen kök-nedenler değerlendi-
rilerek içerisinde çözüm üretilebilecek olanlar seçilmiştir. Seçilen kök-nedenler Tablo
2’de görüldüğü gibidir:
Tablo 2. Kök-Nedenler
İnsan Kaynaklı Kök- Metot Kay- Çevre Kay- ÖlçüKay- AraçKay-
Nedenler naklı Kök- naklı Kök- naklı Kök- naklı Kök-
Nedenler Nedenler Nedenler Nedenler
*Kod gözden geçirme *Ürün bazlı *Manuel pa- *Teslimat *Geliştirme
uzmanının azlığı kod gözden ket derleme sonrası oluşan testinde bir
*Geliştiricilerin kod geçirme kont- problemi kay- hataları ölç- otomasyon ol-
standartlar kılavuzları rol listesinin naklı eksik pa- mek için bir maması
hakkında bilgi sahibi olmaması ket içeriği ol- metriğin ol- *Statik Kod
olmaması *Benzer hata- ması maması kontrolüprog-
*Geliştiricilerin kod ların örnek ramının olma-
standart kuralları hak- alınacağı bir ması
kında az bilgi sahibi ol- veritabanının
ması olmaması
*Kompleks hataları çö-
zecek uzman bir takım
üyesinin olmaması
*Statik kod kontrolü
için bir program olma-
ması
4.2 Çözüm Seçimi
Organizasyonel seviyedeki balık kılçığında seçilen kök-nedenler için bir çok çözüm
önerisi listelenmiştir. Bu çözümler arasında seçim yapılırken, çözümlere maliyet/risk,
yarar ve yarar-maliyet oranına göre 1-10 arası puanlar verilmiştir. Puanlandırma sonu-
cunda, en ideal puanı alan (maliyeti makul, eforu orta/az ölçekli/yararı fazla) çözümler
uygulanmak üzere seçilmiştir.
4.3 Aksiyon Planlama
Önerilen çözüm önerileri değerlendirildikten sonra, seçilen çözümler için Tablo 3’de
görüldüğü gibi aksiyon planı oluşturulmuştur.
501
Tablo 3. Aksiyon Planı
Aksiyon Etkilenen Sorumlu Hedeflenen Tamam- Statü
Süreç Tamam- lanma Ta-
lanma Tarihi rihi
Çalışanların yetkinli- Yetkinlik İlgili De- 23.03.2016 25.03.2016 Kapalı
ğini arttırmak için Yönetimi partman
kod standardı eğitim- Yöneticisi
leri düzenlenecektir.
Kod gözden geçirme İnsan Yö- İlgili De- 23.03.2016 25.03.2016 Kapalı
için uzman havuzu netimi partman
oluşturulacak. Yöneticisi
Statik kod gözden ge- Yazılım İlgili De- 13.04.2016 13.04.2016 Kapalı
çirme programı, kod Kodlama partman
gözden geçirme kap- Prosedürü Yöneticisi
samını arttırmak için
sisteme entegre edile-
cek.
Yazılım geliştiricile- Yazılım İlgili De- 13.04.2016 13.04.2016 Kapalı
rinin kendi yazdığı Kodlama partman
kodu gözden geçir- Prosedürü Yöneticisi
mesi için ürün bazlı
kod gözden geçirme
kontrol listesi hazırla-
nacak.
Geliştirme Testi aşa- Geliş- İlgili De- 21.04.2016 21.04.2016 Kapalı
masında seçilen bir tirme partman
Test Otomasyon Testi Yöneticisi
Programı kullanıla-
cak.
HTRDC seviyesinde Yazılım İlgili De- 21.04.2016 21.04.2016 Kapalı
bilinen hatalar veri ta- Kodlama partman
banı oluşturulacak. Prosedürü Yöneticisi
4.4 Maliyet-Yarar Analizi
SüreçPerformans Model’inde Kod Gözden Geçirme Hata Yoğunluğu, Geliştirme Testi
Hata Yoğunluğu değerleri %30 arttırılarak ve SDV Hata Yoğunluğu %30 azaltılarak
1000 kod satırında yapılan tahminleme sonucunda Üretim Sonrası Hata Yoğunluğu de-
ğerinin 12’den 0’a düştüğü gözlemlendi. Bu durumda, eski metrik verileri baz alınarak
hesap yapıldığında, 1000 kod satırı için harcanabilecek hata çözüm eforunun azaldığı
ve bir saatlik efora denk gelen ortalama Amerikan doları sabiti ile kazanılan efor baz
alınarak maliyet hesabı yapıldığında önemli miktarda kazanım sağlanabileceği öngö-
rülmüştür.
502
5 Sonuçlar
Planlanan aksiyonlar belirlenmiş olan bir pilot, iki yaygınlaştırma projesinde
denenmiştir. Bu denemeler aşamalı olarak devam etmiştir. Öncelikle pilot proje seçilip
aksiyonlar bu projede uygunlanmıştır. Projenin bitiminde aksiyonların verimliliği,
hedeflere ulaşılıp ulaşılmadığı yapılan istatiksel analizlerle –hipotez testi- [9] belir-
lenmiştir. (Hipotez testi, istatiksel bir analiz programında yapılabilen ve eski-yeni veri
karşılaştırmasını yapıp, istatiksel bir şekilde bu iki veri arasındaki farkı gösterebilen bir
testtir. Bu test sonuçlarına göre, sonraki verinin önceki veriden veya hedeften ne kadar
farklı olduğuna bakılarak yorum yapılır.) Bu analizler sonucunda, pilot projenin SDV
fazında daha az hata bulunmuş ve aksiyonlar uygulanmadan önceki duruma göre bu
fazdaki hata bulmak ve çözmek için harcanacak 9 saatlik efor kazanılmış ve önemli
ölçüde maliyet karı elde edilmiştir. (Şirket gizliliği gerekçesiyle gerçek değer ver-
ilmemiştir.)
Uygulamaların pilot projede başarılı olduğu görüldüğünde, belirlenmiş aksiyonlar ve
süreç güncellemeleri yaygınlaştırma projelerinde uygulanmıştır. Bu projelerin
bitiminde de hipotez testi yapılarak aksiyonların verimliliği kontrol edilmiştir. Hipotez
testi sonucuna göre bu projelerde de 9’ar saatlik efor kazanılmış ve önemli ölçüde mali-
yet karı elde edilmiştir. Ayrıca müşteride çıkabilecek hata riski (yoğunluğu) düşmüş,
daha güvenli ve sorunsuz ürün gönderimi yapılmaya başlanmıştır.
Pilot ve yaygınlaştırma uygulamaları sonucunda, yapılan iyileştirme projesinin başarılı
olduğu sonucuna varılmış ve bu aksiyonların standart süreç haline getirilmesi
kararlaştırılmıştır. Standart süreç olan bu aksiyonların tüm organizasyon genelinde uy-
gulanmasına karar verilmiştir.
Referanslar
1. Chaudhary,M, Chopra,A : CMMI for Development: Implementation Guide (2017)
2. Nandyal,R.S. : Key Features of a Good Process Capability Baseline Report (2015)
3. Litten,D : Project Risk and Risk Management (2010)
4. Doc.Dr.Seval Kul Sayfası, http://www.p005.net/analiz/korelasyon-analizi, son erişim
2017/09/12
5. Hacettepe Üniversitesi Biyoistatistik Sayfası, http://www.biyoistatistik.hacettepe.edu.tr/li-
sans/eczacilik/Korelasyon_Regresyon.pps, son erişim 2017/09/12
6. Stoddard, R.W, Linders,B, Sapp,E.M :Exactly What are Process Performance Models in the
CMMI? (2007)
7. Oracle Crystal Ball Information Page, http://www.oracle.com/technetwork/midd-
leware/crystalball/overview/sensitivity-chart-128074.pdf, son erişim 2017/09/12
8. Tr Wikipedia Sayfası, https://tr.wikipe-
dia.org/wiki/Bal%C4%B1k_k%C4%B1l%C3%A7%C4%B1%C4%9F%C4%B1_diyag-
ram%C4%B1, son erişim 2017/09/12
9. En Wikipedia Sayfası, https://en.wikipedia.org/wiki/Statistical_hypothesis_testing, son
erişim 2017/09/12
503