CMMI

Giriş

Not 1: Bu yazı ile ilgili olarak MIL-STD_498 başlıklı yazıyı okuyabilirsiniz.
Not 2: CMMI dışında başka Kalite Yönetim Kitapları da var. Bunlar ISO ve AQAP.
Bir çok firma AQAP-160, AQAP-2110, AQAP-2210 belgeleri de alıyor.

AQAP-160 (Allied Quality Assurance Publications)
Belgenin Türkçesi YAZILIM İÇİN ÖMÜR DEVRİ BOYUNCA. BİRLEŞTİRİLMİŞ NATO KALİTE GEREKSİNİMLERİ. Bu bir NATO standardı. Bu belge niçin lazım bilmiyorum.  Denetimler Milli Savunma Bakanlığı Kalite Yönetim Dairesi Denetçileri tarafından yapılır. Bazı firmalar AQAP ile CMMI süreçlerini aynı anda uyguluyorlar. Bu durumda firmanın sürecinin bir kısmı AQAP bir kısmı da CMMI gerektirdiği için yapılır hale geliyor.

ISO 9001
Ayrıca yine bir çok firma ISO 9001:2000 belgesi de alıyor. Bu belge niçin lazım onu da bilmiyorum. ISO 9001 sadece yapılan işi tarif eden bir süreç olmasını gerektiriyor. İş için kullanılan araçlarla ilgilenmiyor. CMMI ile kıyaslanınca daha yüzeysel.

Not 3: Buradaki sunumda şöyle bir cümle geçiyor.

"Yazılımın uluslararası standartlara göre geliştirilmesi, yazılımı geliştiren firma/kurumun ISO9001,AQAP-160, CMMI gibi sertifikalara sahip olması geliştirilen yazılımın ileride sürdürülebilir olması için önemlidir.". 

 Bu yazıyla beraber cümlenin yorumlanmasının daha kolay olacağını umuyorum.



CMMI
Aşağıdaki karikatür aslında kafa karışıklığını çok iyi açıklıyor.

CMMI Neden Model Kelimesini Kullanıyor
Bir çok kitapta Software Process Model ve Software Process (Engineering) Methodology kelimelerini görürüz. Bu kelimeler aynı gibi görünse de aralarında fark var. Fark şu

Software Proess Model şöyle tarif edilmiş.

"A software process model is an abstract representation of a process methodology. Waterfall1 is a process model. Agile is a process model. They don't specify how to do things, but outline the types of things that are done. For example, Waterfall identifies the phases that a project goes through - requirements, design, implementation/unit testing, integration testing, system testing, deployment - without saying what artifacts to produce or what tools to use (although the output of code is implied). Agile defines core values in the form of the Agile manifesto, time-boxed iterations, and continuous response to change, but it doesn't say how long your iterations should be or how you go about responding to change. The Spiral model is a third software process model."

Software Engineering Methodology ise şöyle tarif edilmiş.

"A software process methodology is a specific way of conducting a software project. These are things like the Rational Unified Process and Scrum. They define exactly what, when, and/or how various artifacts are produced. They might not be entirely explicit with all regards - for example, Scrum doesn't identify what documents to produce or not to produce, since it's focus is on delivering value to the customer - but they define, in some way, the actions that members of the project team must deliver."

Ben methodology olarak piyasada halen kullanıldığı için MIL STD 498'i de anmakta fayda görüyorum.

CMMI bir process model. Yani neyi nasıl yapacağımızı söylemez. Sadece yapılıp yapılmadığın bakar.

CMMI ve Felsefe
Frederick Brooks No Silver Bullet başlıklı makalesinde yazılım geliştirirken karşılaşılan sıkıntıları, yazılımın doğasından kaynaklananlar (essential complexity) ve iyileştirilebilecek olanlar (accidental complexity) şeklinde ayırmış. Yazılımın doğasından kaynaklanan complexity, conformity, changeability, invisibility gibi özelliklerin ne yaparsak yapalım giderilemeyeceğini, ancak araç/gereç, insan ve süreçlerin iyileştirilebileceğini söylüyor. 

Buradaki bir başka soruda da araç/gereç'teki standartlaşmanın halen çok eksik olmasına rağmen epey mesafe kaydettiği belirtilmiş.

CMMI bu felsefe ile yazılım süreçlerini iyileştirerek farklı projelerde bile standart, tahmin edilebilir ve ölçülebilir sonuçlar almayı hedefliyor. 

Açıklaması şöyle

Maturity models are based on consistent, systematic, linear-scale assessments and representations of existing software delivery processes that are applied through standardized methods of evaluation.  This enables maturity quantification of methods, ways of working, and applications of technology in the software delivery processes.

Have Maturity Models Become Irrelevant?
Açıklaması şöyle. Yani artırımsal iyileştirmenin,dolayısıyla Agile süreçleri öne çıkarıyor ancak bence CMMI zaten bu yönlerden geri kalmıyor. Dolayısıyla yazıya katılmıyorum

Relevancy and Relativity

The criticism expressed here is not about the depth, scale, or substance, of current maturity models. Rather, it is about their suitability to effectively assess a fragmented, hybrid, and sometimes global delivery model through a single-process lens. 

Why Is It Important? Why Now?

In the past, maturity models have served as the guiding compass for many organizations' improvement roadmaps, giving measurable milestones in maturity that can be targeted in iterations of process refinement across various areas.

As we’ve gained an understanding that it is not practical or cost-efficient for every organization to hit the top of every maturity model, and we need context on what an organization and its teams need to hit their own ideal maturity, it becomes clear we need to change our approach.  As we’ve seen changes in the software delivery approach with the rise of the Agile and DevOps processes, the increased re-use of components and hyper-connected systems whose quality isn’t always ours to govern, it is becoming clearer that incremental, contextualized, continuous improvement and refinement is a more powerful tool in modern businesses than just trying to progress globally on a one-size-fits-all framework.

Fostering a “culture of innovation” and having the right roadmap (not biting off more than one can chew) that stakeholders will buy into is the new key to keep quality and customer experience increasing in the modern software delivery landscape. This is possible with a more collaborative and compelling trigger for improvement rather than a “that’s the next level of maturity” trigger.

CMMI ve Yazarı
CMMI'ın yazarı olan Watts Humphrey süreci yazarken kitle üretim ve donanım dünyasından esinlendiğini yazıyor. Peki kitle üretim dünyası nasıl çalışıyor? Bu çalışma şeklinde her şeyi kontrol etmek mümkün değil. Üretimde istatistiki yöntemler kullanılıyor. Önemli ölçüm parametreleri belirleniyor. Daha sonra aynı süreç, araç ve insanları kullanarak, ölçüm parametrelerinin kontrol grafikleri çıkarılıyor. Böylece gerçek zamanlı olarak üretimi izlemek mümkün oluyor. Bu yöntemi geliştiren kişilerden önemli isimler Walter Shewhart ve Edwards Deming. 

Deming'e atfedilen şu laf meşhurdur.

"In God we Trust, all others must bring data". -W Edwards Deming

CMMI'da seviye 4-5'te benzer bir şekilde, istatistiki yöntemleri kullanarak, projeyi gerçek zamanlı olarak izlemeyi, gerekirse müdahale ederek iyileştirmeler yapıp bunları yaygınlaştırmayı hedefliyor.

Project Assistant veya Project Management Specialist (PMA) olarak anılan kişilerin görevlerinden birisi de istatistiki bilgi toplamak ve bunları istatistiki bir modele girmektir. Veri toplama işinin otomasyon ile kolaylaştırıldığı şirketler de gördüm.

CMMI ve Tarihçesi
CMMI da diğer tüm süreçler gibi evrim geçirerek günümüze geldi. Buradaki şekilde tarihçesini görmek mümkün.

CMMI ve Çalışma Kültürü
CMMI çoğu işyeri için çalışma kültürünün tamamen değiştirilmesi anlamını taşımakta. Sırf aşağıdaki şekil bile yazılım dünyasında kullanılan süreçlerin nasıl çorba haline geldiğini gösteriyor. Şekli buradan aldım

Aşağıdaki şekil ise CMMI'ın ne kadar teferruatlı olabileceğini gösteriyor. Şekli buradan aldım.

Neden CMMI?
Peki neden CMMI ve neden başka bir süreç değil ? İlk başta şunu vurgulamak lazım. CMMI sertifikası alma isteği genellikle yukarıdan aşağıya doğru yani üst yönetimden teknik ekiplere doğru gerçekleşir. Şimdiye kadar teknik ekiplerden, üst yönetime doğru böyle bir talebin geldiğine şahit olmadım.

Bence bir çok firmanın CMMI sertifikası almak için çaba göstermesinin en mühim sebebi askeri ve devlet ihalelerinde artık asgari CMMI Seviye 3 sertifikasına sahip olmanın zorunlu olmaya başlaması. İlk olarak Amerikan Savunma Bakanlığı'nın ön ayak olduğu (DoD) bu uygulama diğer ülkelere de yayılıyor.

Projeleri daha iyi, daha kaliteli yapalım isteği de elbette önemli bir faktördür, ancak başka süreçler yerine illaki CMMI sertifikasına sahip olma isteğinin arkasındaki rüzgar bu zorunluluktan kaynaklanmaktadır.

Aşağıdaki resimden de görüldüğü gibi Carnegie Mellon Institute tarafından geliştirilen CMMI olgunluk modeli basamaklı bir yapıya sahiptir ve Seviye 3'e çıkıldığı zaman sürecin tüm organizasyon için tanımlı olduğu ve gelen projeye göre uyarlama yapıldığı görülebiliyor.

Buradan aldığım şekilde de görüldüğü gibi tüm basamaklar arasında sayıca en fazla gruplaşma seviye 3'te bulunuyor.

Türkiye ve CMMI
Türkiye'de CMMI 3 ve üstü seviyede sertifikaya sahip 22 tane firma var. SEI tarafından sertifika verilmiş firmaların listesini Published Appraisal Results başlıklı yazıda bulmak mümkün. Bunlardan bazıları.

Firma	Appraiser	Sponsor
Ayesaş	Norman Hammock	Levent Tanrıdağ
Aselsan MGEO	Wayne LittleField	Ömer Faruk Ilter
Cybersoft C/S Information Technologies, Ltd.	Wayne LittleField	Yenal Göğebakan
Havelsan	Lemis Altan	Ayşegül Kalaycıoğlu,Ömer Faruk Yarman
Meteksan Savunma	Norman Hammock	Murat Erciyes
MilSOFT Information Communication Technologies	Norman Hammock	Tunç Torosdağlı
MilSOFT Software Technologies	Norman Hammock	İsmail Başyiğit
STM Savunma Teknolojileri Muhendislik ve Tic. A.S.	Norman Hammock	Recep Barut
TÜBITAK-BILGEM UEKAE	Norman Hammock	Tevfik Alparslan Babaoğlu

2012 senesinde bu furyaya Havelsan da katıldı ve seviye 3 sertifikasını aldı. Savunma ve Havacılık Dergisi 2012/6 sayısında çıkan "Havelsan'dan Daha Güçlü Rekabet Kabiliyeti" başlıklı yazıya da göz atabilirsiniz.

Süreç Sahibi ve CMMI
CMMI ile oluşturulan süreçlerin sürekli olarak değişikliklere göre uyarlanması ve geliştirilmeleri gerekiyor. Bunun için de process owner (süreç sahibi) kavramı geliştirilmiş. Süreç sahibi örneği olarak Meteksan Savunma'daki listeye göz atılabilir.

Her süreç bir alanın içine düşüyor. Alanları renklendirdim ve süreçlerin isimlerinde de aynı renkleri kullandım

• Process Management
• Project Management
• Engineering 
• Support

Süreç Varlıkları
CMMI - Süreç Varlıkları başlıklı yazıya taşıdım.

Bazı CMMI Seviye 2 Süreçleri

CMMI Seviye 2 kapsamında bazı süreç alanları aşağıda bulunabilir. Seviye 2'de süreçler projeye seviyesindedir, henüz daha organizasyon çapında ve seviyesinde süreçler yoktur.

CMMI bir olgunluk modeli olduğu için proje yönetiminin temeli olan kalite, zaman, maliyet gibi unsurların nasıl önceliklendirileceğine (triage) karışmaz hatta yapılması gerektiğini bile belirtmez.

Bu unsurlar, mahir bir proje yöneticisi veya ekip elinde daraltılıp genişletilebilir.

PP (Project Planning)
Konuyu CMMI - Project Planning Süreci başlıklı yazıya taşıdım.
  
CM (Configuration Management) - Konfigürasyon Yönetimi
Konuyu Software Configuration Management Süreci başlıklı yazıya taşıdım.


REQM (Requirements Management) - Gereksinim Yönetimi

Konuyu CMMI - Requirements Management başlıklı yazıya taşıdım.

Bazı CMMI Seviye 3 Süreç Alanları

Seviye 3'e gelince süreç tanımlıdır ve standart hale getirilmiştir. Süreç idame ettirilir, iyileştirilir, öğrenilir. Herkes aynı süreci kullanır

CMMI Seviye 3 kapsamında bazı süreç alanları aşağıda bulunabilir. Seviye 3 ile süreçler organizasyon seviyesinde uygulanmaya başlanır.

Özellikle dikkatimi çeken nokta Engineering ile ilgili süreçlerin hep seviye 3'te bulunması. Sanki bu seviyeye gelinceye kadar hiç mühendislikle ilgili bir şey yok!.

Requirements Development
Requirements Development is a process which includes activities to capture (collect) analyze, specify (elaborate) and validate (review) requirements. Requirements Management ile sadece gereksinimler yönetilirken bu süreç ile gereksinimler bir şekilde daha detaylandırılıyor. Ancak konuyu tam anlayamadığım için örnek veremiyorum:)

Technical Solution
Teknik Çözüm ve Kodlama Standardı (Coding Standard)
Kullanılacak kodlama standardı, şirketin her zaman kullandığı standarttan farklı ise, bunu Tailoring Check List (TCL) içinde belirtmek gerekir.

TCL içinde ayrıca "Organizational Tool Set" bulunur. Bu tüm firma çapında kullanılan araçların ismi, versiyon numarası ve ne işe yaradıklarını belirten bir listedir. Genellikle uzun bir listedir ve bazı araçların ne işe yaradığı kim tarafından kullanıldığı bile bilinmez :)

Bu konunun CMMI ile alakası yok ama kodlama standardı projelerde olursa iyi olur. Bu belgede aşağıdakine benzer bir sınıflandırma bazen kullanılıyor.

Rule -> Mutlaka uyulması gereken kural. Aksi durumda waiver doldurmak gerekir.
Recommendation -> Uyulmaması durumunda, review esnasında neden uyulmadığı açıklanır. Waiver gerekmez.
Suggestion -> Uyulması tavsiye edilen durum. Herhangi bir açıklama yapmak gerekmez.

Code Banner'ı
Firmalar kodlara bir banner konulmasını istiyorlar. Bence burada sadece telif hakkı bilgisi (copyright) ve firmanın ismi olmalı. Kodu yazan kişinin ismi vs. olmamalı. Ancak Pragmatic Programmer kitabında, kodlayanın isminin olması tavsiye edilmiş.

Product Integration
Detay yaz

Verification - Doğrulam
Konuyu CMMI - Verification yazısına taşıdım.

Validation - Onaylama
Aşağıdaki karikatür durumu çok güzel anlatıyor.

DAR (Decision Analysis and Resolution) - Support
Konuyu CMMI - DAR Süreci başlıklı yazıya taşıdım.

IPM (Integrated Project Management) - Project Management

IPM (Türkçesi : Tümleşik Proje Yönetimi) CMMI Seviye 3 olan firmaların yapması gereken süreç alanlarından birisidir (process area).Bu seviyedeki firmanın artık tanımlı ve standart bir süreci olduğu farz edildiği için, yeni başlanılan projelerde tanımlı olan bu sürecin gerektiği kadarının, yeni projeye özgün şekilde özelleştirileceği farz ediliyor.

Bu süreç alanı anlaması ve uygulaması en zor şeylerde birisi. Bir sürü dokümanın önceden üretilmiş olması ve bunların özelleştirilmesi gerekiyor. Örneğin Tailoring Check List (TCL) dolduruluyor. TCL içinde "Toolset" ve "Defined Process" başlıkları altında hangi süreç ve araçların kullanılacağı veya kullanılmayacağı belirtiliyor.

Bir diğer önemli faaliyet ise aylık olarak PMR (Project Management Review) toplantılarının yapılması. Bu toplantılarda önemli kilometre taşları, durum ve açık işlem maddeleri (Action Item List) görüşülüyor. Ayrıca aylık olarak bütçe, Earned Value Management (EVA) değerleri de görüşülür. PMR raporu daha çok üst yönetim için yapılır.

PMR yanında Planned Project Review Meeting  (PPRM) de yapılarak açık işlem maddelerinin üzerinden geçilir.

Schedule Performance Index
EVA ile Schedule Performance Index (SPI) - yani takvimin gerisinde veya önünde olunup olunmadığı - gösterilir. SPI değerinin 1'den küçükse olması takvimin geride, büyük olması önünde olmamız anlamına gelir. 1 olması ise takvime uygun ilerlediğimizi gösterir. Rakamın genellikle 0.9 ve 1.1 arasında olması arzu edilir. Eğer 0.7 gibi kabul edilebilir bir rakamın dışındaysa önlem almak gerekir. Aşağıdaki şekil durumu özetliyor.

Cost Performance Index
Cost Performance Index (CPI) - yani bütçenin gerisinde veya önünde olunup olunmadığı - gibi değerler grafiksel olarak gösterilir.


RSKM (Risk Management) - Project Management

Bu kısmı Risk Yönetimi başlıklı yazıya taşıdım.

OT (Organizational Training) - Process Management
OT (Türkçesi : Organizasyonel Eğitim) CMMI Seviye 3 olan firmaların yapması gereken süreç alanlarından birisidir. Bu seviyede artık bir eğitim stratejisi bulunduğu ve planlı eğitimler yapılarak sonuçlarının değerlendirildiği farz ediliyor.

OT ve Eğitim Stratejisi

CMMI ve Eğitim ile alakalı olarak bu yazıya bakabilirsiniz. Tüm CMMI süreçlerinde olduğu gibi her şeyi bir sürü dokümana nasıl çevirebilirizin çok güzel bir örneği. Üretilen dokümanlar bakınca insan inanamıyor

• Eğitim Politikası (Training Policy)
• Eğitim Süreci (Training Process)
• Eğitim Planı (Training Plan)
• Eğitim Plan Şablonu (Training Plan Template)
• Eğitim Değerlendirme Formu (Training Evaluation Form)
• Eğitim Muafiyet Formu (Training Waiver Form)
• Yönlendirme Kontrol Listesi (Orientation Checklist)
• İşbaşı Eğitimi (On The Job Training)
• Eğitim Metrikleri (Training Metrics)
• Eğitim Metrikleri Şablonu (Training Metrics Template)
• Eğitim Sertifikası (Training Certificate):

Eğitim stratejisini temsil eden aşğıdaki şekli buradan aldım.

Örnek şekilde de görüldüğü üzere, çalışanlar stratejik gruplara ayrılmışlar ve işlerinde ihtiyaç duyacakları eğitim planlanmış. Eğitim firma içi uzmanlar tarafından verilebildiği gibi, firma dışından hizmet olarak ta satın alınabilir.

CMMI Seviye 3 denetimlerinde eğitimle alakalı olarak sadece kayıtlara bakılıyor. Yani eğitim strateji planının olup olmadığı, eğitimi veren ve katılımcılar listesi, eğitim değerlendirme formları gibi kayıtların olup olmadığına bakılıyor.

Bu süreç alanı için web üzerinden doldurulan eğitim değerlendirme formlarının başarıyla kullanıldığını müşahede ettim.

OPF (Organizational Process Focus) - Process Management
CMMI - Organizational Process Focus Süreci yazısına taşıdım.

Bazı CMMI Seviye 4 Süreçleri  
Seviye 4'ten itibaren ölçüm ve veri toplanmaya başlanır. Kalite Kontrol işinde 7 tane çok kullanılan araç var. Toplanan veri bu araçlardan uygun olanı ile gösterilebilir.

OPP (Organization Process Performance)
Amaç aşağıda görüldüğü gibi neyin ölçüleceğini belirlemek ve performansı ölçme amaçlı veri toplamak.

Toplanabilecek bazı metriklere örnekler

SLOC
Geliştirilen kod satır sayısı, Birim Testi satır sayısı, Test Aracı satır sayısı

Değişiklik/Düzeltme Sayısı
Önemli dokümanlar için açılan değişiklik/düzeltme isteği yoğunluğu ölçülebilir. Bu belgeler SSS, SRS, SSDD ve SDD olabilirler.
Aşağıda her 1000 satır (KLOC) için Defect Density grafiği var. Hedef KLOC için 20 +/- 5 defect olarak konulmuş. İlk başta hedef tutturulamamış ancak daha sonra gerekli önlemler alındıktan sonra hedefe yaklaşıldığı görülmüş. Burada 850 milyon satır açık kaynak kod incelenmiş, ve 1K SLOC için 0.69 defect density bulunmuş.

Bazı CMMI Seviye 5 Süreçleri  

CAR (Causal Analysis and Resolution) 
CAR ile problemin kök sebebi bulunmaya çalışılır. Amaç aşağıda.

Kök sebebi bulmak için her verilen cevaba karşılık 5-6 defa daha "peki o neden/niçin oldu" sorusu sorulur ve esas sebebe erişilmeye çalışılır. Arzu edilirse fishbone diyagramları ile sebepler ve sonuçlar görsel hale getirilebilir. Bazen kök sebep olarak sadece "bilgi eksikliği" bile bulunabilir. Uzman olmadığı alanlara giren firmaların başına gelebilecek kök sebeplerden birisidir.

Burada ilginç olan bir nokta problemin tespit edilmesi için neden 5. seviyeye erişilmiş olması gerektiği ? Daha aşağıdaki seviyelerde hiç problem olmuyor mu ve kök sebebi bulmak gerekmiyor mu ? 

Anladığım kadarıyla CAR süreci toplanan metrik verisine dayandırılmış. Aynı fabrikalardaki kontrol grafikleri izleniyor. Eğer veri üst ve alt sınırların dışına çıkmış ise veya eğilim çıkma yönünde ise, yani sapma varsa, CAR süreci işletiliyor ve  kök sebep bulunarak düzeltilmeye çalışılıyor. Eğer veri çok başarılı sonuç gösteriyor ise yine CAR süreci işletilip, başarının sebebi bulunarak, organizasyona yayılması da sağlanabilir.