OLGUNLUK YETENEK MODELLERİ Doç Dr Fuat İnce Boğaziçi Üniversitesi YAZILIMDA SÜREÇ OLGUNLUK YETENEK MODELLERİ Doç Dr Fuat İnce Boğaziçi Üniversitesi 23 Aralık 1998

Yazılım Nedir ? Bilim mi ? Endüstri mi ? Mühendislik mi ? Sanat mı ?

Rekabet Gücü Unsurları Verim Kalite Zamanlama (time to market)

Yazılımın mühendislik olması için 1. Standartlara dayanması gerekir. 2. Ölçülebilmesi gerekir. Kalite standartları, kalitenin ölçülebilmesi Verimin standartları, verimin ölçülebilmesi

Tarihsel Gelişmeler (1) Yazılım yeni bir konudur : 50 yıl önce yoktu. 1950ler 1960larda : Yazılım Mühendisliği = Programcılık. “Yazılım Krizi”, ilk olarak 1968, yoğun kullanım 1980ler. 1990lara kadar büyük projelerde başarı oranı çok düşük. ABD’de 1970lerde kamu tarafından sipariş yolu ile satın alınan yazılım ürünlerinin ancak % 5’i kabul edilip kullanılabilmiştir. % 40’ı hiç kullanılamamış, geri kalanı ise maliyet artışı, zaman artışı, performans eksikliği veya özelliklerden taviz verilerek kullanılabilmiştir.

Tarihsel Gelişmeler (2) Yazılımda ilk yaklaşımlar diğer mühendislik dallarından örnek almıştır. - Yapısallaştırma (parçalara ayırma) - Metodolojiler (SSADM, OOM vb.) - CASE ve ICASE

Tarihsel Gelişmeler (3) 1984 ABD DoD girişimi ve SEI kuruluşu (Carnegie Mellon Univ. Software Engineering Institute) Watts Humphrey ve Yetenek Olgunluk Modeli (Capability Maturity Model, CMM ) - ISO 9001, ISO 9000-3, TickIT modelleri - Diğer modeller : Bootstrap (AK), Trillium (Kanada) vb. - SPICE modeli (ISO 15504 taslak standardı) ve ESI

Kalitenin tanımı “tanımı zor, tanıması kolay, ölçmesi imkansız” (Kitchenham) “amaca uygunluk” (Juran) “sıfır hata” (Crosby) “müşteri isteklerini karşılama” “spesifikasyonlara uyum” “Bir ürünün veya hizmetin, belirlenen ihtiyaçları karşılayabilme yeteneğine yönelik özelliklerin bütünü.” (IEEE) (the totality of features and characteristics of a product or service that bears on its ability to satisfy given needs)

Yazılımda Kalite Hata sayısında düşük düzey (sıfıra yaklaşma) Kullanıcı isterlerine cevap (tamamını yapabilme) Arızalar arası zamanın uzunluğu (uzun MTBF) Destek ve gelişme.

Kalitenin Maliyeti - Önlem : Planlama, eğitim, süreç iyileştirme - Denetleme/değerlendirme : tasarım ve kod kontrolu, testler vb. - Hata düzeltme (iç) : kod düzeltme, tekrar test, iç denetleme - Hata düzeltme (dış) : müşteri garantisi, alanda destek vb. Optimum denge önemlidir. Ancak; Hatanın maliyeti iş ilerledikçe artar. Genelde bir hatayı oluşmadan önlemek en ucuz yoldur.

Yazılımda kalite ilkeleri, en iyi pratiklerle (EP) ortaya çıkmıştır. (best practises, BPs, best current practises, BCPs) EPler birer rehberdir (guideline), mutlak koşul değil. Ancak Kabul görmüş kalite modellerinin temelleri bunlar olmuştur. - Erken tanı, erken çözüm maliyeti düşürür. - Ürün değil, süreç önemlidir. Süreç iyileştirilmelidir. - Sürekli iyileşme, gelişme yolu açık olmalıdır. - Standartlar ve ölçütler kullanılmalı. (ölç, referanslı çalış)

Bazı EPler - Müşteri tatmin araştırması yap. - Proje kestrim araçları kullan. - Süreçlerini iyi belgele. - Metodoloji kullan ve iyi belgele. - Krıtik tasarım değerlendirmesi (CDR) yap. - Kod denetlemesi (walkthrough, inspection) yap. - Konfigürasyon yönetimi aracı kullan. - Hataları ve güvenilirliği ölç, kaydet, analiz yap - Hataları ve güvenilirliği tahmin modelleri kullan. - Temel nedenlere (root cause) in. (ürün değil süreç) - Proje sonrası değerlendirme yap.

Olgun Olmayan ve Olgun Yazılım Organizasyonları Olgun organizasyonun karakteristikleri yazılım geliştirme ve bakımını yönetecek organizasyon çapında yetenek mevcut. yazılım süreci çalışanlara ve yeni elemanlara doğru bir şekilde iletiliyor. Aktiviteler plana uygun icra ediliyor. Tanımlı süreçlerde roller ve sorumluluklar tüm projede ve organizasyonda belirlenmiş. Disiplinli bir süreç takip ediliyor. Katılan herkes bunun değerini biliyor. 6

Olgun Olmayan ve Olgun Yazılım Organizasyonları Olgun olmayan organizasyonun karakteristikleri yazılım süreçleri belgelenmemiştir. yazılım süreçleri proje sırasında yönetici ve uygulayıcılar tarafından doğaçlanır. bir yazılım süreci, belirtimi yapılmış olsa bile, kuvvetle takip edilmez ve mecbur tutulmaz. yöneticiler sürekli kriz çözmekle meşguldür. ürün kalitesini ölçmek için nesnel bir temel yoktur. kaliteyi yükseltici etkinlikler (gözden geçirme, test gibi), projeler gecikince, çoğu kez atlanır. 6

değişkenliği azaltmak, YAZILIM VE SÜREÇ - Süreç bir işi yapma usulüdür. - Genelde, (altsüreç), adım ve işlemlerden oluşur. - Sürecin amacı bir standart oturtmak, değişkenliği azaltmak, iyileşmeye yol açmaktır. - Yazılı ve grafiksel belgelenmiştir. - Tekrarlanırdır. - Girdileri çıktıları vardır. - Büyük (karmaşık) veya küçük (basit) tanımlanabilir. örnek: İsterlerin analizi süreci alt süreçlere ayrılabilir. pazar araştırması, müşteri isteklerinin belirlenmesi, fizibilite çalışması, spesifikasyonların belirlenmesi, ister modellemesi. vb.

Süreç İyileştirme ve Yetenek Belirleme Modelleri CMM TickIT SPICE

CMM (Capability Maturity Model) SOFTWARE ENGINEEERING INSTITUTE (SEI) VERSION 1.1 SOFTWARE ENGINEEERING INSTITUTE (SEI) BTAE 1

CMM Genel bakış CMM 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 evrimsel bir yol çizer. CMM yazılım sürecinin olgunluğu üzerine hüküm vermek ve endüstrideki pratiklerle karşılaştırmak için bir ölçüm aracıdır. 3

CMM Süreç Olgunluk Çerçevesi Organizasyon çapında yazılım sürecinin tanımlı olmadığı durumlarda, projelerde başarının tekrarı kişilere bağımlıdır; bu durum, uzun süreli verimliliği ve kaliteyi iyileştirmeye olanak vermez. Sürekli iyileşme ancak, etkin yazılım mühendisliği ve yönetim pratiklerinden oluşan bir süreç altyapısı inşa ederek mümkündür. CMM olgun bir yazılım organizasyona giden aşamaları, öncelik sırasıyla veren bir modeldir. 5

Yazılım Süreç Olgunluk Seviyeleri Optimize Edilen (5) Sürekli iyileştirilen Yönetilen (4) Ön kestirim yapılabilir Tanımlı (3) Standart tutarlı Tekrarlanabilir (2) Disiplinli Başlangıç (1) 13

Anahtar Süreç Alanları CMM’in Yapısı Olgunluk Seviyeleri (maturity levels) Süreç Yeteneği Anahtar Süreç Alanları (key process areas) Hedefler Ortak Öznitelikler (common features) Gerçekleştirme veya Kurumsallaştırma Anahtar Uygulamalar (key practices) Etkinlikler 11

Olgunluk Seviyesine Göre Anahtar Süreç Alanları Eniyileştirilen (5) Süreç Değişimi Yönetimi Teknoloji Değişim Yönetimi Hata Önleme Yönetilen (4) Yazılım Kalite Yönetimi Nicel Süreç Yönetimi Tanımlı (3) 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ı Tekrarlanabilir (2) Yazılım Konfig. Yönetimi Yazılım Kalite Güvencesi Yazılım Taşaron Yönetimi Yazılım Projesi İzlemesi Yazılım Proje Planlaması İsterler Yönetimi Başlangıç (1) 26

The TickIT Guide 1

TickIT Scheme Kalite Sistemi Standartları TickIT içinde kullanılan anahtar dokümanlar: ISO 9001:1994, Kalite Sistemi Standardı, tasarım, geliştirme, kurma (installation) ve servis için bir model tanımlar. ISO 9002:1994, Kalite Sistemi Standardı ikinci bölümüdür. ISO 9001’den farkı tasarım aktivitelerini içermez. ISO 9000-3:1991, yazılım için kalite sistemlerinin uygulayıcıları ve denetimcileri için özel rehberlik bilgileri verir. ISO 9000 serisi standartlar, dünyada geniş bir sektör tabanında, giderek organızasyonların kalite sistemleri için model olarak uygulanması 5 4

TickIT Scheme Sertifikasyon Süreci Değerlendirme en az iki aşamalı bir süreçtir: Organizasyonun kalite sistemi, standarda (TickIT için: ISO 9001) göre muhakeme edilir. Organizasyon, pratikte gerçekten kendi kalite sistemine ve standarda uyumlu çalışıp çalışmadığı denetlenir, ve kalite sisteminin etkinlik derecesine bakılır. ISO 9000 serisi standartlar, dünyada geniş bir sektör tabanında, giderek organızasyonların kalite sistemleri için model olarak uygulanması 18 15

SPICE (ISO 15504) Software Process Imrovement and Capability dEtermination) ISO/IEC JTC1/SC7 WG10 tarafından 1991’de çerçeve üst model oluşturma kararı alındı. Çalışmalar 1993’te başladı. İlk versiyon Haziran 1995’te, ikinci versiyon 1996 Kasımda yayınlandı. Üçüncü versiyon Ocak 1998’de çıktı. İki boyutlu bir modeldir. Birinci boyutta süreçler ikinci boyutta yetenek düzeyleri vardır.

SPICE Amacı 1. Süreç İyileştirme (içe dönük) 2 SPICE Amacı 1. Süreç İyileştirme (içe dönük) 2. Yetenek Belirleme (dışa veya içe dönük)

SPICE Kapsamı : Yazılım satın alma, tedarik, geliştirme, işletim, bakım ve destek için: planlama, yönetim, icra, denetim ve iyileşme aracı.

SPICE İlkeler - Diğer modelleri destekleyen, uyum sağlayabilen - Ortak, modellerüstü, uluslararası kapsamlı çerçeve - Diğer modelleri destekleyen, uyum sağlayabilen - Her organizasyona, endüstriye, duruma uyabilen - Büyük küçük projelere, gruplara, firmalara uygun - İyileşmeyi, gelişmeyi ölçebilen - Nesnel, tutarlı ve tekrarlanabilir - Sertifikasyon amacı taşımayan - Bir süreç standardı, ürün standardı değil.

SPICE Temel Model İki boyutludur: - Süreçler - Yetenek Düzeyi YD 5 - S1 S2 S3

SÜREÇ GRUPLARI Müşteri-satıcı (customer-supplier) süreçleri Mühendislik (engineering) süreçleri Yönetim (management) süreçleri Destek (support) süreçleri Örgüt (organisation) süreçleri

YETENEK DÜZEYLERİ 0. Eksik (incomplete) düzey 1. Varolan (performed) düzey 2. Yönetilen (managed) düzey 3. Yerleşmiş (established) düzey 4. Kestirilebilir (predictable) düzey 5. Eniyileşen (optimizing) düzey

SPICE Belgeleri Part 1 : Kavramlar ve Giriş Part 2 : Referans Modeli (zorunlu model) Part 3 : Değerlendirme İsterleri Part 4 : Değerlendirme Rehberi Part 5 : Uyumlu Model Part 6 : Değerlendiricilerin Nitelikleri Rehberi Part 7 : Süreç İyileştirme Rehberi Part 8 : Yetenek Belirleme Rehberi Part 9 : Sözlük

UYUMLU (ÖRNEK) MODEL (PART 5) SPICE değerlendirmesi referans modeline göre değil, uyumlu bir modele göre yapılır. SPICE belgeleri kendi içinde uyumlu bir model vermiştir. Başka uyumlu modeller de vardır, veya olabilir. (uyumlu Bootstrap vb.) Bir süreç değerlendirme modelinin uyumlu olabilmesi için : - en az bir süreci kapsaması, - en az iki yetenek düzeyini, 0’dan başlayarak ve kesintisiz, kapsaması. - referans modeline bire bir izdüşüm (mapping) bulunması, - modelle referans modeli arasında not dönüştürme mekanizması olması.

Süreç Boyutu Değerlendirme modelinde her sürecin eksiksiz tanımı şu bilgileri içerir: sürecin amacının tanımı (Referans Model ile aynı) amacın tanımını güçlendirici açıklayıcı notlar sürecin temel pratikler (base practices); sürecin amacına ulaşması için gerekli aktiviteler ve görevler her süreç ile ilgili girdi/çıktı iş ürünleri (work products) her iş ürününün karakteristikleri

Süreç kategorileri ve süreçler Müşteri-satıcı süreç kategorisi CUS.1 Yazılım edin (acquire software) CUS.2 Müşteri ihtiyaçlarını yönet CUS.3 Yazılım sağla (supply software) CUS.4 Yazılımı işlet (operate software) CUS.5 Müşteri hizmeti sağla

Süreç kategorileri ve süreçler Destek süreç kategorisi SUP.1 Dokümantasyon geliştir SUP.2 Konfigürasyon yönetimi yap SUP.3 Kalite güvencesi sağla SUP.4 İş ürünlerini doğrula (verify) SUP.5 iş ürünlerini sağla (validate) SUP.6 Ortak gözden geçirmeler yap SUP.7 Denetimler yap SUP.8 Problemleri çözümle

Süreç kategorileri ve süreçler Mühendislik süreç kategorisi ENG.1 Sistem isterlerini ve tasarımını geliştir ENG.2 Yazılım isterlerini geliştir ENG.3 Yazılım tasarımını geliştir ENG.4 Yazılım tasarımını uygula ENG.5 Yazılımın entegrasyonu ve testini yap ENG.6 Sistem entegrasyonu ve testini yap ENG.7 Sistemin ve yazılımın bakımını yap

Süreç kategorileri ve süreçler Yönetim süreç kategorisi Man.1 Projeyi yönet Man.2 Kaliteyi yönet Man.3 Risk yönetimi yap Man.4 Taşaronları yönet

Süreç kategorileri ve süreçler Organizasyon süreç kategorisi ORG.1 İşin mühendisliğini yap (engineer the business) ORG.2 Süreci tanımla ORG.3 Süreci iyileştir ORG.4 Kaliteli iş gücü temin et ORG.5 Yazılım mühendisliği altyapısı sağla

Süreç Tanımları ve Temel Pratikler ENG.2 Yazılım isterlerini geliştir Sürecin amacı, sistemin yazılım bileşeni için isterlerin saptanmasıdır. Sürecin başarıyla uygulanması sonucu olarak: Sistemin yazılım bileşenlerine ve arabirimlerine ayrılan (allocated) isterleri, müşterinin yazılı veya ima edilen ihtiyaçlarına uygun olarak, tanımlanacak Analizi yapılmış, doğru ve test edilebilir yazılım isterleri geliştirilecek 18

Temel Pratikler ENG.2 ENG.2.1 Yazılım isterlerinin belirtimini yap ENG.2.2 İşletim çevresinin etkilerini belirle ENG.2.3 İsterleri müşteri ile değerlendir ENG.2.4 Sürüm stratejisi belirle ENG.2.5 Bir sonraki iterasyon için isterleri güncel yap ENG.2.6 Yazılım isterlerini ilet 20

Süreçler ve ilgili iş ürünleri ENG.2 Yazılım isterlerini geliştir Girdi Çıktı Müşteri İsterleri Yazılım isterleri Bakım isterleri Analiz sonuçları Müşteri isteği Değişiklik isteği Sistem tasarımı/yapısı Problem raporları İletişim mekanizması 21

Yetenek Düzeyleri (YD) YD 0 : Eksik (incomplete) YD 1 : Varolan (performed) YD 2 : Yönetilen (managed) YD 3 : Yerleşmiş (established) YD 4 : Kestirilebilir (predictable) YD 5 : Eniyileşen (optimizing)

Yetenek Düzeyleri (YD) - SPICE, yetenek düzeyini daha ayrıntılı, tekrarlanabilir ve nesnel notlama amacıyla, alt düzeyde, süreç nitelikleri (process attributes) tanımlamıştır. - Yetenek Düzeyi boyutunda temel pratikler ve dokuz süreç niteliği vardır. - Her yeni nitelik yükselen yetenek düzeyini gösterir. - Süreç Yeteneği Düzeyi başarılan niteliklerle belirlenir.

Süreç nitelikleri Süreç nitelikleri, süreç yeteneğinin ölçümünü veren, ve bir başarı skalasında değerlendirilebilen, özelliklerdir. Her süreç niteliği, sürecin amacına ulaşması için, o sürecin etkinliğini iyileştirme ve yönetme yeteneğinin bir yönünü tanımlar. Bir yetenek seviyesi, bir süreci yerine getirme yeteneğinde önemli artış sağlayan, nitelikler kümesidir. 24

YD 1 : 1.1 Süreci Yerine Getirme (process performance) niteliği YD 2 : 2.1 Başarım Yönetim (performance management) niteliği 2.2 İş ürünü Yönetim (work product management) niteliği YD 3 : 3.1 Süreç Tanım (process definition) niteliği 3.2 Süreç Kaynak (process resource) niteliği YD 4 : 4.1 Süreç Ölçüm (process measurement) niteliği 4.2 Süreç Denetim (process control) niteliği YD 5 : 5.1 Süreç Değişim (process change) niteliği 5.2 Sürekli İyileşme (continuous improvement) niteliği

Süreç nitelikleri Örnek- 2. seviyenin süreç niteliklerini PA 2.1: Performans yönetimi niteliği Kendisinden beklenen ürünleri belirtilen zaman ve kaynak gereksinimleri dahilinde verebilmesi için sürecin, ne ölçüde iyi yönetildiği PA 2.2: İş ürünü yönetimi niteliği Ortaya çıkardığı iş ürünlerinin dokümante edilmiş, kontrol altında, işlevsel isterlerini karşılayan, istenen kalitede olması için, süreç ne ölçüde iyi yönetildiği 26

Yönetim pratikleri Her süreç niteliği için, yeterli düzeyde yerine getirildikleri zaman, o niteliğin karakteristiklerini başaran, bir dizi yönetim pratikleri tanımlanmıştır. Yönetim pratikleri genel amaçlı yönetim aktivitleridir ve tüm süreçlere uygulanabilir olmaları amaçlanmıştır. 27

Yönetim pratikleri Yönetim pratikleri, planlama, örgütleme, kaynak sağlama ve kontrol etme gibi temel yönetim işlevlerinin başarılması etrafında tasarlanmışlardır. Her süreç niteliği için genel olarak dört yönetim pratiği vardır. 28

2. seviyenin yönetim pratikleri performans yönetimi 2.1.1 süreci planlamak ve izlemek için kaynak gereksinimlerini belirle 2.1.2 süreç aktivitelerini belirleyerek, ayrılan kaynaklarla sürecin icrasını planla 2.1.3 sürecin amacına ulaşması için, tanımlanan aktiviteleri uygula 2.1.4 belirtilen zaman ve kaynak gereksinimleri içinde iş ürünlerini çıkarmak için, aktivitelerin icrasını yönet 29

2. seviyenin yönetim pratikleri iş ürünü yönetimi 2.2.1 iş ürünlerinin kalitesi ve bütünlüğü için isterleri belirle 2.2.2 iş ürünlerinin kalite ve bütünlük isterlerini başarmak için gerekli aktiviteleri belirle 2.2.3 bütünlüklerini güvenceye almak için iş ürünlerin konfigürasyonunu yönet 2.2.4 İşlevsel ve diğer isterleri karşıladıklarını güvenceye almak için ürünlerin kalitesini yönet 30

Notlama dört not üstünden yapılır N : (not achieved) yapılmıyor. P : (partly achieved) kısmen yapılıyor. L : (largely achieved) büyük oranda yapılıyor. F : (fully achieved) tam yapılıyor. Değerlendirme sonucu bir profildir. Tek bir not değildir. Profilin yatay ekseni değerlendirilen süreçleri, dikey ekseni de değerlendirme sonucunu, verilen notları, gösterir.

SÜREÇLERİN KARŞILAŞTIRILMASI YAPI ISO 9001 CMM SPICE 2 düzey 5 düzey 2 boyut, çok düzey

ANA AMAÇ: ISO 9001 CMM SPICE sertifikasyon yetenek belirleme iyileş(tir)me ve (dış) ve sertifikasyon yetenek belirleme (iç ve dış) (iç ve dış)

BELGELER: ISO 9001 CMM SPICE kısa uzunca uzun soyut somutça somut ve ayrıntılı genel kökenli yazılıma özgü yazılıma özgü (ISO 9000) ABD bağımsız gelişme ISO üst model

DEĞERLENDİRME (1) ISO 9001 CMM SPICE denetleme değerlendirme değerlendirme soyut krıter somut krıter somut krıter dış uzman iç - dış uzman iç - dış uzman kısa öz uzun ayrıntılı uzun ayrıntılı hata arayan gerçek arayan kanıt isteyen gösterge isteyen negatif tutum positive tutum karşı güçler işbirlikçi savunmacı saydam

DEĞERLENDIRME (2) ISO 9001 CMM SPICE kapsamlı kapsamlı küçük çapta yada değerlendirme değerlendirme kapsamlı olabilir tüm organizasyon tüm org. için -her süreç için tek not tek değerlendirme -her proje için alır yapılır -her grup için ayrı yapılabilir

İYİLEŞTİRME AMAÇLI OLARAK: ISO 9001 CMM SPICE rehber değil rehber olma rehber olma niteliği var niteliği var çok sınırlı iyileşme yolu var -esnek iyileşme yolları (corrective action) (improvement path) -amaca göre iyileşme

SONUÇLARIN YORUMLANMASI ISO 9001 CMM SPICE basit kolay zorca, model bilgisi gerektirir. süreçlere bağımlı doğrudan karşılaştırılamaz.

TÜRKİYEDE DURUM ISO 9001 sertifikasyonu almış bir firma vardı. Ancak? MAM’ın ESI ile işbirliği MAM, SPICE değerlendirmesi yapmakta (15 kadar firma oldu) MAM’ın MAK içinde değerlendirme / sertifikasyon merkezi olma planları var

DÜNYA’DA DURUM ABD’de CMM yaygın ve tek İngiltere, Hindistan ve kısmen Avrupanın bazı ülkelerinde ISO 9001 ve TickIT yaygın Avrupa’da CMM ve SPICE yayılmakta SPICE’ın 1998’de tam ISO standardı olması ABD’nin geciktirmesi ile 2001’e kalmış gibi Sonuçta ISO 15504 (SPICE) üst model olacak. Tüm diğer modeller SPICE uyumlu olacak.

Teşekkür Ederim Fuat İNCE