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% Money Wasted $140 billion ($80 billion in failed projects) $55 billion ($38 billion in failed projects with another $17 billion in cost overruns) 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 SDCE SCAMPI ISO 15939* Six Sigma EIA/IS 731 PSM SCE EIA 632 CBA IPI CMMI IPD- CMM* EIA/IS 632 People CMM SA- CMM SECAM SW-CMM FAAiCMM # FAM** IEEE 1220 SE-CMM PSP ISO/IEC 15504 SAM SSE- CMM MIL-STD 499B* TSP Baldrige 12 Q9000 DOD- STD- 7935A J-STD 016 RTCA DO-178B TL9000 www.software.org DOD- STD- 2167A MIL-STD- 498 ISO 9000 series DOD- STD- 2168 IEEE/EIA 12207 Process Stds Quality Stds Maturity or Capability Models Appraisal methods Guidelines ISO/IEC 12207 ISO/IEC 15288*
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) Değişiklik hareketini başlat Kapsamı belirle Sponsor/sponsorları belirle Altyapıyı hazırla 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) Ö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 gereksinimleri Yazılım tasarımı Yazılım gerçekleştirme Yazılım sınama Yazılım bakımı Yazılım Yönetimi Yazılım konfigürasyon yönetimi Yazılım mühendisliği yönetimi Yazılım süreç mühendisliği Yazılım araç ve yöntemleri Yazılım 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 Supply Supporting Processes Documentation Configuration Management Quality Assurance Development Operation Maintenance Verification Validation Joint Review Audit Problem Resolution Organizational Life Cycle Processes Management Improvement Infrastructure Training 20
12207 Süreçleri Süreçler aktivitelerden oluşur Geliştirme süreci aktiviteleri process implementation system requirements analysis system architectural design software requirements analysis software architectural design software detailed design software integration software qualification testing system integration system qualification testing software installation software acceptance testing software coding and testing 21
22 SPICE Nedir? Yazılım Software Process Improvement and Capability determination Süreci İyileştirme ve Yeterlilik Belirleme
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
25 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
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
27 ISO/IEC 15504 Süreç Kategorileri (ISO 12207) ANA SÜREÇLER MÜŞTERİ DESTEKLEYEN SÜREÇLER DESTEK MÜHENDİSLİK ORGANİZASYON SÜREÇLERİ PROJE 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 Açıklanmayan %8 214 Şirket 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 Sürekli temsil Organizasyonel olgunluk 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
Süreç Alanı Yeteneği CMMI ın Genel Yapısı Sürekli Basamaklı ML5 SA SA Tek bir süreç alanı için SA ML2 ML 1 ML4 ML3 Organizasyonun olgunluğu (süreç alanları grubu) için 39
CMMI ın Genel Yapısı Süreç Yetenek Düzeyleri (CL) Firma Olgunluk Düzeyleri (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) (quantitatively managed) 5 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 1 Yerine Getirilen 0 Eksik 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. Paydaşlar tanımlanıyor ve sürece dahil ediliyor. 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 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. 0 Eksik
CMMI ın Genel Yapısı 5 İyileşen 4 Niceliksel Yönetilen 3 Tanımlı 2 Yönetilen 1 Yerine Getirilen 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. 0 Eksik
Süreç Alanı Bileşenleri Süreç Alanı (PA) Sürecin Amacı Tanıtıcı Bilgiler İlgili Süreç Alanları Özel Hedefler (SG) Genel Hedefler (GG) Tipik İş Ürünleri Özel Uygulamalar (SP) Alt uygulamalar Alt uygulamalar Genel Uygulamalar (GP) Genel Uygulama Açıklamaları Zorunlu Beklenen Bilgilendirici
CMMI Olgunluk Düzeyleri Yazılım Olgunluk Düzeyi Başlangıç Tekrarlanabilir Tanımlı Yönetilen Eniyileşen Olgunluk Düzeyinin Tanımı 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 geliştirme süreci organizasyon çapında belgelenmiş, standartlaştırılmıştır. Yazılım süreci ve ürün kalitesinin ayrıntılı ölçümleri toplanmaktadır. 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. Anahtar Süreçler 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 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ı Yazılım Kalite Yönetimi Nicel Süreç Yönetimi Süreç Değişimi Yönetimi Teknoloji Değişim Yönetimi Hata Önleme
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ı GG5: Sürekli İyileşen Bir Sürecin Kurumsallaştırılması GP 4.1: GP 4.2: GP 5.1: GP 5.2: Süreç İçin Sayısal Hedfeler Tanımla Alt Süreç Performanslarını Stabilize Et 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