Mersis Tanıtım

Mersis Bilgi Teknolojileri Danışmanlık Ltd.
Yazılım Kalitesi ve Standartlar
Meriç Aykol
BT Projeleri ve Sorunlar
•
Gartner Institute’un BT sektörü araştırması
– Projelerin %74’ü başarısız ya da maliyet/zaman hedeflerini aşıyor
– %51’i bütçesini %200 oranında aşıyor
– Hedeflenen özelliklerin %75’ini karşılayabiliyor
•
Standish Group - 2000 (Chaos in the new Millenium 2000)
– Yazılım projelerinin başarıya ulaşma oranı %28
– Diğerleri ya başarısız (%23) ya da zorlanmış (%49) projeler
•
Gartner Institute 2001 BT sektörü araştırması
– Amerika’da her yıl başarısız BT projeleri için 75 milyar dolar harcanıyor
– Başarısızlığın en önemli nedeni, projelerin kötü yönetilmesi
2
BT Projeleri ve Sorunlar
1994
2003
Project Cancelled
31.1%
15%
Project Challenged
52.7% (189% average overrun cost
of their original estimates)
51% (43% avarage cost overrun)
Project Succeeded
16.2%
34%
$140 billion ($80 billion in failed
projects)
$55 billion ($38 billion in failed
projects with another $17 billion in
cost overruns)
Money Wasted
SW Research Center 2007- Jonathan Lee
3
Yazılım Üretimi
Farklı özellikler gösterir
– Ürün sanaldır
– Mühendislik, sanat, zanaat, bilim dalı...
– Üretimde tekrar az, her proje yeni bir iş olma özelliğinde
– Farklı kişilerin ürüne etkileri daha fazla
– Hataları önlemek proje koşul/maliyetleri içinde çok zor
– Ürünün kalitesini, onu üreten sürecin kalitesi belirler, süreç odaklı
kalite yaklaşımı hakimdir
– Müşteriye sağlanan ürün/hizmet, yönetilen süreçlerin çıktıları
– Süreç yönetimi temelli düşünce, metodoloji kullanımını öne
çıkarıyor
4
Performans için Temel Faktörler
Ne
: Teknoloji
Nasıl : Teknikler
Kim
: Sosyoloji
Ürünün maliyeti, zaman ve kaliteyi belirleyici ana faktörler..
5
Kaliteli Yazılım
•
Az hata olması
•
Kullanıcı/Müşteri gereksinimini karşılaması
•
Arızalar arası zamanın uzunluğu
•
Arızaların hızlı giderilmesi
Yazılım Kalitesi İlkeleri
•
Kalite ilkeleri iyi uygulamalar ile oluşmuştur
–
–
–
–
Erken tanı ve erken çözüm maliyeti düşürür
Ürün değil süreç önemlidir
Sürekli iyileştirme hedeflenmelidir
Standart ve ölçüler kullanılmalıdır
Yazılım ve Süreç
•
Süreç bir işi yapma yöntemidir
•
Genellikle altsüreç ve işlemlerden oluşur
•
Amacı, standart oluşturmak, değişkenliği azaltarak iyileşme
sağlamaktır
•
Belgelenmiş ve tekrarlıdır
•
Girdi ve çıktıları vardır
Yazılım Süreci
Aktiviteler
9
Model ve Standartlar
Model Nedir?
•
Etkili süreçlerin karakteristiklerini tanımlar
•
Süreçlerin iyileşmesi için yol haritası verir
Yazılım Geliştirmede Standart ve Modeller
People CMM
SCE
SDCE
SW-CMM
CBA IPI
SCAMPI
CMMI
ISO
15939*
FAAiCMM#
SACMM
TSP
ISO/IEC
15504
SSECMM
PSM
Six
Sigma
PSP
DODSTD7935A
DODSTD2167A
J-STD
016
MIL-STD498
RTCA
DO-178B
FAM**
IPDCMM*
DODSTD2168
Process Stds
Quality Stds
Maturity or
Capability
Models
Appraisal
methods
Guidelines
IEEE/EIA
12207
SE-CMM
Baldrige
EIA/IS
731
SECAM
EIA/IS
632
SAM
IEEE
1220
Q9000
MIL-STD
499B*
ISO 9000
series
ISO/IEC
12207
TL9000
ISO/IEC 15288*
EIA 632
12
www.software.org
Süreç İyileştirme
IDEAL
IDEAL Modeli
•
Yalnızca iyileştirme
süreçlerini
tanımlayan,
planlanması ve
yönetilmesi için yol
gösteren bir
organizasyonel
geliştirme modelidir
•
İsmini içerdiği beş
fazın baş
harflerinden almıştır
•
Organizasyonlara
etkin yazılım
iyileştirmeyi
sağlayan bir altyapı
için rehberlik sağlar
14
IDEAL Modeli
•
Başlangıç Aşaması (Initiating)
•
Teşhis Aşaması (Diagnosing)
–
–
–
–
–
–
•
Bulunulan durum ve hedeflenen durumu
gözönüne alarak, bulguları belirle
Çözüm yollarını belirle
Hazırlık Aşaması (Establishing)
–
–
–
•
Değişiklik hareketini başlat
Kapsamı belirle
Sponsor/sponsorları belirle
Altyapıyı hazırla
Önceki aşamada hazırlanan bulgular
üzerinde öncelikleri belirle
Yaklaşım ve yöntemleri belirle
Önceliklere göre eylem aşamasını detaylı
olarak planla
Eylem Aşaması (Acting)
–
–
–
Çözüm geliştir
Çözümleri gözden geçir, sına
Çözümü uygula

Bilgi Aşaması (Learning)

Önceki deneyimlere ait veri topla ve verileri analiz
et, doğrula

Sonraki iyileştirmeye yönelik veri topla, önerileri
hazırla/değerlendir
Software Engineering Body of Knowledge (SWEBOK)
•
1997 –
•
Katılımcılar:
–
–
–
–
IEEE Computer Society
Association for Computing Machinery
NITS (ABD), NRC (Kanada)
Boeing, SAP Labs Canada, Raytheon, Bell Canada
•
www.swebok.org
•
Amaç
–
–
–
–
YM disiplininin kapsamını ve sınırlarını tanımlamak
YM literatürüne erişimi kolaylaştırmak
YM mesleğine tutarlı ve evrensel bir görünüm kazandırmak
Ders programları ve sertifikasyon için temel oluşturmak
Software Engineering Body of Knowledge (SWEBOK)
Kapsam
Yazılım Mühendisliği
Yazılım
Yazılım
Yazılım
Yazılım
Yazılım
gereksinimleri
tasarımı
gerçekleştirme
sınama
bakımı
Yazılım Yönetimi
Yazılım
Yazılım
Yazılım
Yazılım
Yazılım
konfigürasyon yönetimi
mühendisliği yönetimi
süreç mühendisliği
araç ve yöntemleri
kalitesi
ISO / IEC - 12207
ISO / IEC - 12207
•
Amaç “Yazılım Yaşam Döngüsü” için ortak bir çerçeve sunmak
– Satın alma, yazılım sağlama, geliştirme, işletim ve bakım
– Yönetim, kontrol ve iyileştirme
•
Yazılım yaşam döngüsü için tanım
12207 Süreçleri
Primary Processes
Acquisition
Supporting Processes
Documentation
Configuration Management
Supply
Quality Assurance
Verification
Operation
Development
Validation
Joint Review
Maintenance
Audit
Problem Resolution
Organizational Life Cycle Processes
20
Management
Infrastructure
Improvement
Training
12207 Süreçleri
Süreçler aktivitelerden oluşur
Geliştirme süreci aktiviteleri
21
•
process implementation
•
software integration
•
system requirements analysis
•
software qualification testing
•
system architectural design
•
system integration
•
software requirements analysis
•
system qualification testing
•
software architectural design
•
software installation
•
software detailed design
•
software acceptance testing
•
software coding and testing
SPICE Nedir?
Yazılım
Software
Process
Improvement
Süreci
İyileştirme
and
Capability
ve
dEtermination
Yeterlilik
Belirleme
22
ISO 15504 (SPICE) Nedir
•
1993’te Uluslararası Standartlar Örgütü (ISO), tarafından başlatılan bir
çalışmanın ürünüdür
•
Yazılım süreç değerlendirmesi için bir çerçeve oluşturur
•
Süreç iyileştirme veya yetenek belirleme amaçlarıyla kullanılabilir
•
İki boyutlu bir modeldir: Süreç boyutu ve yetenek boyutu
•
Süreç yeteneği 6 düzeyde ölçülür:
–
–
–
–
–
–
0: Eksik (incomplete)
1: Yerine getirilen (performed)
2: Yönetilen (managed)
3: Kurulmuş (established)
4: Kestirilebilir (predictable)
5: Sürekli iyileşen (optimizing)
23
ISO 15504 (SPICE) Süreçleri
•
Tanımlanan süreç alanları beş kategoride gruplandırılmıştır:
– Müşteri-Sağlayıcı: Yazılım Edinme, Yazılım Sağlama (satış vb.),
Gereksinimlerin Toplanması, İşletme
– Mühendislik: Geliştirme, Bakım
– Destek: Dokümantasyon, Konfigürasyon Yönetimi, Kalite Güvence,
Doğrulama (verification), Geçerleme (validation), Ortak Gözden
Geçirme, Denetleme, Sorun Çözme
– Yönetim: Yönetim, Proje Yönetimi, Kalite Yönetimi, Risk Yönetimi
– Kurumsal: Kurumsal Yönlenme, Süreç İyileştirme, İnsan Kaynakları,
Altyapı, Ölçüm, Yeniden Kullanım
24
SPICE (ISO 15504) Modeli Kapsamı
–
–
–
–
Yazılım satın alma
Yazılım geliştirme
İşletim
Bakım ve destek süreçleri için
Planlama, yönetim, gerçekleştirme, denetim ve iyileştirme aracıdır
25
Süreç Nitelikleri
1.Düzey “Yapılan”
1.1 Süreç performansı
2.Düzey “Yönetilen”
2.1 Performans yönetimi
2.2 İş ürünü yönetimi
3.Düzey “Kurumsallaşmış” 3.1 Süreç tanımı
3.2 Süreç kaynakları
4.Düzey “Kestirilebilen”
4.1 Ölçümleme
4.2 Süreç denetimi
5.Düzey “Eniyilenen”
5.1 Süreç değişimi
5.2 Sürekli iyileştirme
26
ISO/IEC 15504
Süreç Kategorileri (ISO 12207)
ANA SÜREÇLER
DESTEKLEYEN SÜREÇLER
MÜŞTERİ
DESTEK
MÜHENDİSLİK
ORGANİZASYON SÜREÇLERİ
PROJE
27
ORGANİZASYON
CMMI
28
CMM Nedir
•
1989’da Carnegie Mellon Üniversitesi’nin ABD Savunma
Bakanlığı sponsorluğundaki Yazılım Mühendisliği
Enstitüsü (SEI) tarafından ortaya konan “Yetenek
Olgunluk Modeli”
•
Etkin bir yazılım sürecinin anahtar elemanlarını
tanımlayan bir çerçeve modeldir. Olgun olmayan bir
süreçten olgun ve disiplinli bir sürece giden bir yol çizer
– “Yetenek olgunluğa bağlıdır”
– “Olgunluk zamanla gelişir ve ölçülebilir”
29
CMM Nedir
•
Yazılım sürecinin olgunluğunu değerlendirmek ve diğer
organizasyonlarla karşılaştırmak için bir ölçüm aracıdır
•
5 olgunluk düzeyi ve 17 anahtar süreç alanı
tanımlanmıştır
•
Her olgunluk düzeyi için belirlenen anahtar süreç
alanlarını başaran firmalar, o olgunluk düzeyinin notunu
alır
30
CMMI Nedir?
•
1987 yılında ABD Savunma Bakanlığı’nın kurduğu Software Engineering
Institute (SEI), bu alanda bir öncü kurum olarak yazılımdan sonra değişik
alanlar için küçük farklarla ayrı birer CMM modeli çıkarmıştır:
–
–
–
–
Yazılım mühendisliği için CMM (Software CMM v2.0c)
Tümleşik ürün geliştirme için CMM (IPD-CMM v0.98)
Sistem mühendisliği için CMM (EIA/IS 731 SECM)
Temin prosesi için çeşitli modeller (SA-CMM v1.01)
•
CMMI modelinin bir amacı bunları birleştirmektir
•
CMMI bir taraftan da ISO 15504 uyumlu olma amacını güder
•
CMMI süreç tanımlama, süreç iyileştirme ve yetkinlik değerlendirmesi için
rehberlik sağlar
•
CMMI, önceki modeller gibi en iyi uygulamaların organize bir birikimidir
31
CMM Düzeyleri Dağılımı
Mart 2002 – 1158 Şirket
Mart 2008 - 2674 Şirket
Seviye 1
%25
290 Şirket
%1,5
40 Şirket
Seviye 2
%40
463 Şirket
%32,9
880 Şirket
Seviye 3
%24
278 Şirket
%41,9
1.120 Şirket
Seviye 4
%6
70 Şirket
%3,3
88 Şirket
Seviye 5
%5.5
64 Şirket
%12,3
329 Şirket
%8
214 Şirket
Açıklanmayan
Mart 2002’de yayınlanan SEI`in yaptığı araştırmaya göre 1997 - 2001 arası CMM
değerlendirmelerine katılmış 1158 şirket ve Mart 2008’de yayınlanan SEI`a rapor edilmiş 2674
şirkete ait değerlendirme sonuçları
32
33
34
35
36
CMMI’ın Genel Yapısı
•
CMMI tek bir modeli iki değişik biçimde temsil eder:
– Sürekli Temsil
– Basamaklı Temsil
•
Tek model, yazılım üreten gruplarda (firmalarda) süreçlerin
varlığını, yetenek ve olgunluk düzeylerini değerlendirir
– Basamaklı model önceki CMM modeline benzer. Yazılım üreten firmalar,
firma olarak olgunluk düzeyi notu alır
– Sürekli model ise SPICE modeline benzer. Süreçler tek tek
değerlendirilerek bir süreç yetenek düzeyi notu alırlar
37
CMMI’ın Genel Yapısı
CMMI bu iki temsil biçimini ilişkilendirmiştir.
– Süreç alanı yeteneği

– Organizasyonel olgunluk 
Sürekli temsil
Basamaklı temsil
İki temsil biçimi arasındaki Eşdeğerlik (equivalent staging)
ilişkisi ile olgunluk notu, belirli süreçlerde alınan yetenek
notlarından elde edilebilir.
Süreçler 6 düzeyinde yetenek notu alabilir.
Firmaların aldığı olgunluk notu için ise 5 düzey belirlenmiştir.
38
CMMI’ın Genel Yapısı
Basamaklı
Sürekli
Süreç Alanı
Yeteneği
ML5
ML4
ML3
ML2
ML 1
SA
SA
SA
Organizasyonun olgunluğu
(süreç alanları grubu) için
Tek bir süreç alanı için
39
CMMI’ın Genel Yapısı
Süreç Yetenek Düzeyleri
Firma Olgunluk Düzeyleri
(CL)
(ML)
0
Eksik (incomplete)
-
1
Yerine getirilen (performed)
Başlangıç (initial)
2
Yönetilen (managed)
Yönetilen (managed)
3
Tanımlı (defined)
Tanımlı (defined)
4
Nicel yönetilen
Nicel yönetilen
(quantitatively managed)
5
(quantitatively managed)
Sürekli iyileşen (optimizing)
Sürekli iyileşen (optimizing)
40
CMM Olgunluk Düzeyleri
•
1992 yılından itibaren CMM bazlı yazılım süreç iyileştirme
çalışmalarına başlayan şirketlere ait veriler baz alınarak
–
–
–
–
CMM L2’ye ulaşmak 24 ay
CMM L3’e ulaşmak 22 ay
CMM L4’e ulaşmak 32 ay
CMM L5’e ulaşmak 16 ay sürmektedir
»Bu süreler ortama 300 çalışanlı bir yazılım şirketi için doğrudur
»Süreler çalışan sayısı ile doğrudan ilintili
(Software Engineering Institute, Carnegie Mellon University, March 2002, Process Maturity Profile of the
SW Community 2001 Year End Update, page29)
CMMI’ın Genel Yapısı
5 İyileşen
4 Niceliksel Yönetilen
3 Tanımlı
2 Yönetilen
1 Yerine Getirilen
0 Eksik
CMMI’ın Genel Yapısı
5 İyileşen
4 Niceliksel Yönetilen
3 Tanımlı
2 Yönetilen
1 Yerine Getirilen
0 Eksik
Süreç yerine
getirilmiyor veya
kısmen yerine
getiriliyor.
Süreç alanın özel
amaçlarından biri
veya daha fazlası
sağlanamıyor.
CMMI’ın Genel Yapısı
5 İyileşen
4 Niceliksel Yönetilen
3 Tanımlı
2 Yönetilen
1 Yerine Getirilen
0 Eksik
Süreç alanı özel
amaçlarını
sağlıyor.
Belirlenen girdi iş
ürünleri
kullanılarak
belirlenen çıktı iş
ürünleri elde
ediliyor.
CMMI’ın Genel Yapısı
5 İyileşen
4 Niceliksel Yönetilen
3 Tanımlı
2 Yönetilen
Süreci yerine getirmek için;
• Organizasyonel politikalar var
• Planlar yapılıyor.
• Gerekli kaynak sağlanıyor.
• Çalışanlar eğitiliyor.
Sürecin performansı planlara
göre izleniyor.
Sürecin iş ürünlerinin
konfigürasyonu yönetiliyor.
1 Yerine Getirilen
Paydaşlar tanımlanıyor ve
sürece dahil ediliyor.
0 Eksik
Süreç planlara göre
değerlendiriliyor.
Daha yüksek seviyeli yönetim
tarafından süreç gözden
geçiriliyor.
CMMI’ın Genel Yapısı
5 İyileşen
4 Niceliksel Yönetilen
3 Tanımlı
2 Yönetilen
1 Yerine Getirilen
0 Eksik
Süreç, organizasyonun
uyarlama rehberlerine
göre standart
süreçlerinden
uyarlanmış yönetilen
süreçtir.
Sürecin gelecekte
kullanımını desteklemek
için uygulanması
sırasında gelişen
iyileştirme bilgileri
toplanır.
CMMI’ın Genel Yapısı
5 İyileşen
4 Niceliksel Yönetilen
3 Tanımlı
2 Yönetilen
1 Yerine Getirilen
0 Eksik
Niceliksel yönetilen
süreç kalite ve süreç
performansı için
istatiksel ve niceliksel
teknikler ile kontrol
altında tutalan tanımlı
süreçtir.
Süreç performansı
tahmin edilebilir.
CMMI’ın Genel Yapısı
5 İyileşen
4 Niceliksel Yönetilen
3 Tanımlı
2 Yönetilen
1 Yerine Getirilen
0 Eksik
Süreç performansını
sürekli iyileştirmeye
odaklanılır.
Süreç o anki ve
gelecekteki iş
hedeflerini karşılamak
için değişir ve adapte
olur.
Süreç Alanı Bileşenleri
Süreç Alanı (PA)
Sürecin
Amacı
İlgili
Süreç Alanları
Tanıtıcı
Bilgiler
Özel Hedefler (SG)
Genel Hedefler (GG)
Özel
Uygulamalar
(SP)
Tipik İş
Ürünleri
Alt uygulamalar
Genel
Uygulamalar
(GP)
Alt uygulamalar
Zorunlu
Beklenen
Bilgilendirici
Genel Uygulama
Açıklamaları
CMMI Olgunluk Düzeyleri
Yazılım
Olgunluk
Düzeyi
Başlangıç
Olgunluk Düzeyinin Tanımı
Anahtar Süreçler
Yazılım süreci gelişi güzel yerine getirilir. Başarı
kişiseldir.
Proje yönetim politikaları ve bunları uygulamak için
prosedürler oturmuştur.
Yazılım Konfigürasyon Yönetimi
Yazılım Kalite Güvencesi
Yazılım Altyüklenici Yönetimi
Yazılım Projesi İzlemesi
Yazılım Proje Planlaması
İsterler Yönetimi
Tanımlı
Yazılım geliştirme süreci organizasyon çapında
belgelenmiş, standartlaştırılmıştır.
Gözden Geçirme (peer review)
Grup İçi Düzenlemesi
Yazılım Ürünü Mühendisliği
Tümleşik Yazılım Yönetimi
Eğitim Programı
Organizasyon Süreç Tanımı
Organizasyon Süreç Odaklanması
Yönetilen
Yazılım süreci ve ürün kalitesinin ayrıntılı ölçümleri
toplanmaktadır.
Yazılım Kalite Yönetimi
Nicel Süreç Yönetimi
Eniyileşen
Süreçten gelen nicel geri besleme ve yeni teknoloji ve
buluşlardan pilot uygulamalarla uyarlayarak sürecin
sürekli iyileşmesi sağlanır.
Süreç Değişimi Yönetimi
Teknoloji Değişim Yönetimi
Hata Önleme
Tekrarlanabilir
CMMI Anahtar Süreç Alanları
•
•
•
II. Düzey
–
–
–
–
–
–
–
Gereksinimlerin Yönetimi
Proje Planlama
Proje İzleme ve Kontrol
Tedarikçi Sözleşme Yönetimi
Ölçümleme ve Analiz
Süreç ve Ürün Kalite Güvence
Konfigürasyon Yönetimi
IV. Düzey
–
–
Organizasyonel süreç başarımı
Niceliksel proje yönetimi
V. Düzey
–
–
Organizasyonel yenilenme ve
yaygınlaştırma
Nedensel analizler ve çözümleme
•
III. Düzey
–
–
–
–
–
–
–
–
–
–
–
–
–
Gereksinimleri Geliştirme
Teknik çözüm
Ürün entegrasyonu
Doğrulama
Onaylama (geçerlileme)
Organizasyonel süreç odaklanması
Organizasyonel süreç tanımlama
Organizasyonel eğitim
IPPD (entgre ürün ve süreç geliştirme)
için tümleşik proje yönetimi
Risk yönetimi
Tümleşik takım yaklaşımı
Tümleşik tedarikçi yönetimi
Entegrasyon için organizasyonel altyapı
Genel Hedef ve Pratikler
Genel Hedefler
Genel Pratikler
GG1: Spesifik Hedeflerin
Başarımı
GP 1.1:
Spesifik Pratikleri Yerine Getir
GG2: Yönetilen Bir
Sürecin
Kurumsallaştırılması
GP 2.1:
GP 2.2:
GP 2.3:
GP 2.4:
GP 2.5:
GP 2.6:
GP 2.7:
GP 2.8:
GP 2.9:
GP 2.10:
Organizasyonel Bir Politika Oluştur
Süreci Planla
Kaynakları Sağla
Sorumlulukları Ata
İnsan Kaynağını Eğit
Konfigürasyonları Yönet
İlgili Paydaşları Tanımla
Süreci İzle ve Kontrol Et
Bağlılığı Değerlendir
Durumu Üst Yönetim İle Değerlendir
GG3: Tanımlı Bir Sürecin
Kurumsallaştırılması
GP 3.1:
GP 3.2:
Tanımlı Bir Süreç Oluştur
İyileştirme Verlerini Topla
GG4: Niceliksel Yönetilen
Bir Sürecin
Kurumsallaştırılması
GP 4.1:
GP 4.2:
Süreç İçin Sayısal Hedfeler Tanımla
Alt Süreç Performanslarını Stabilize Et
GG5: Sürekli İyileşen Bir
Sürecin
Kurumsallaştırılması
GP 5.1:
GP 5.2:
Sürekli İyileştirmeden Emin Ol
Problemlere Yönelik Kök Nedenleri Ortadan Kaldır
Adapted from
Cepeda Systems &
Software Analysis, Inc.
CMMI için Kritik Başarı Faktörleri
•
•
•
•
•
•
•
•
•
Kurumsal başarı için, süreçlerin kurumsal politikalara dayalı olarak
tanımlanması, kurulması, uygulanması ve iyileştirilmesinde mutlaka
üst yönetimin desteği gerekir.
Süreçler ancak belgelenmişse ve onları bilen ve uygulayan kişiler
olduğu sürece var kabul edilir.
Her bir çalışan için süreç eğitimi gereklidir. Koçluk ve liderlik son
derece önemlidir.
Yönetimin her kademesinin işin içinde olması kritik ve önemlidir.
Süreç iyileştirme faaliyetlerinin takibine odaklanmak önemlidir.
Belgelenen süreç stabilize olur ve her zaman tekrar edilebilir.
Tekrar edilen süreç ölçülebilir.
Ölçülebilen süreç iyileştirilebilir
Amaç iyileştirilmiş süreçtir. (dolayısiyle kalite, müşteri
memnuniyeti, karlılık, vb.)
53
KAYNAKLAR
•
CMMI® for Development, Version 1.2,
http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html
•
Process Maturity © 2008 by Carnegie Mellon University Profile - March
2008, http://www.sei.cmu.edu/appraisal-program/profile/profile.html
•
CMMI® Version 1.2 and Beyond …a Tutorial by Carnegie Mellon
University, March 2006, http://www.sei.cmu.edu/programs/acquisitionsupport/presentations/cmmiv2beyond.pdf
•
CMMI http://www.sei.cmu.edu/cmmi/
•
SPICE http://www.sqi.gu.edu.au/spice/suite/download.html
•
ISO http://www.sqi.gu.edu.au/sc7-mirror/index_e_frameset.html
•
Avrupa Yazılım Enstitüsü http://www.esi.es/
•
IDEAL Model http://www.sei.cmu.edu./ideal/ideal.html
54