CMMI - Requirements Management Süreci

Giriş
Gereksinimlerin tanımlanması ve yazılması zor bir iştir ve bir çok müşteri ne istediğini tam olarak bilmez.

Requirements Management Nedir?
Requirements Management is a process which enables consistent administration (change management, establish traceability) of  the requirements during the project's software development lifecycle.

Yani kısaca yazılımın veya donanımın gerçekleştirilebilmesi için gereksinimlerin yazılması, yönetilmesi ve çift yönlü izlenebilirliğin olması gibi klasik süreci kapsıyor.

REQM Faaliyetleri
Bu alanın yapılmasını istediği maddeler aşağıda.

1 Understand Requirements - Toplantı ve Tutanaklar
Bu faaliyetin temel amacı gereksinimler üzerinde uzlaşma sağlamaktır. Uzlaşma sağlamak için bir çok kez bir araya gelinmesi gerekebilir. Toplantılarda Minutes of Meeting/Toplantı Tutanağı (MoM) tutulur. Yani bir şekilde uzlaşma kayıt altına alınır. MIL STD 498 kullanan projelerde sistem seviyesi gereksinimlere görüş vermek ve konuşmak için System Requirements Review (SRR) toplantısı yapılır.Eğer proje şirket içi bir proje ise, şirketin sürecinde tanımlı olan bir form/belge kullanılabilir.

2. Obtain Commitment to Requirements - Taahhüt/Bağlılık Formu
Obtain Commitment To Requirements maddesini yerine getirmek için bir çok şirket çalışanlarına bir belge imzalatıyor. Sanki imzalamama şansımız varmış gibi düşündürten bir belge işte.
3. Manage Requirements Changes - Araçlar
Proje kapsamında yazılım gereksinimlerinin yönetilmesi genellikle bir başka yazılım aracılığıyla yapılır. IBM Rational Doors, Rational RequisitePro ya da Excel bile kullanıldığını gördüm.

Konuyla ilgili olarak DOORS Notlarıma göz atabilirsiniz.

4 Çift Yönlü İzlenebilirlik - Maintain Bidirectional Traceability Of Requirements
REQM sürecindeki en zor maddelerden birisi çift yönlü izlenebilirlik matrisi tutmak. Bu matriste doküman ile bir üst veya bir alt doküman arasındaki maddeler arasında tablolar oluşturulur.

SRS ve STD Arasında Requirements Traceability Matrix yazısına bakabilirsiniz. 

- Çift yönlü izlenebilirlik matrisi projede kaynak koda kadar inecek kadar bile derinleştirilebiliyor. 

- Ancak en genel manada Kullanım Durumları ve İsterler arasındaki izlenebilirlik kast ediliyor. 

- Bazı projelerde Kullanım Durumu yerine Sistem Gereksinimleri Dokümanı var. O zaman Sistem Gereksinimleri dokümanı ile Yazılım Gereksinimleri Dokümanı arasında çift yönlü izlenebilirlik yapılır.

4.1 Statement Of Work
Sözleşme bir çok belgeden oluşur. Sözleşmenin bazı ekleri yazılım açısından önemlidir. Bunlar genellikle EK-A İş Tanımı (Statement of Work) ve EK-B Teknik Şartname belgeleridir. Teknik Şartname tedarik makamı tarafından hazırlanır.

Yazılım gereksinimleri geliştirilirken, projenin başındaki Statement of Work (SOW) dokümanına da atıfta bulunulur. SOW sözleşme altında sağlanan ürün veya hizmetin yazılı tanımını sağlayan dokümandır.
5 Alignment Between Project Work and Requirements
SRS ile tasarım arasındaki bağlantı. MIL-STD-498-SRS başlıklı yazıya göz atabilirsiniz.

Bazı Sorular
CMMI'da anlamadığım bir nokta Requirements Management sürecinin, Requirements Development'tan önce gelmesi. Aşağıdaki şekilde Requirements Management seviye 2'de tanımlı iken, Requirements Development seviye 3'te gösterilmiş.

CMMI - Verification Süreci - Doğrulama

Verification - Doğrulama
Bu alanın yapılmasını istediği maddeler aşağıda.

Specific Practices by Goal
SG 1 Prepare for Verification
  SP 1.1 Select Work Products for Verification
  SP 1.2 Establish the Verification Environment
  SP 1.3 Establish Verification Procedures and Criteria
SG 2 Perform Peer Reviews
  SP 2.1 Prepare for Peer Reviews
  SP 2.2 Conduct Peer Reviews
  SP 2.3 Analyze Peer Review Data
SG 3 Verify Selected Work Products
  SP 3.1 Perform Verification
  SP 3.2 Analyze Verification Results

Verification Nedir? (Doğrulama)
Verification yazılım ekibinin bir yazılım parçasının tasarlandığı şekilde çalıştığını doğrulanmasıdır. Burada dikkat edilmesi gereken nokta bir şeyin tasarlandığı gibi çalışması, aslında tasarımın arzu edilen tasarım olmasını garanti etmemesi. Tasarımın arzu edilen tasarım olduğunu onaylama işi Validation kapsamına giriyor. Aşağıdaki cümle verification'ının ne olduğunu çok güzel özetliyor.

"It works as I thought it would" or "You built it right"

Validation Nedir? (Onaylama/Geçerli Kılma)
Validation - Onaylama/Geçerli Kılma ise.

"You built the right thing"

Doğrulama için yöntem olarak test, inspection, analysis, demonstration kullanılabilir.

Inspection için görsel duyu kullanılabileceği gibi, static analiz (static analysis) aracı da kullanılabilir.

Verification ve İstatistik
Doğrulama faaliyeti birden çok tekrarlandığı müddetçe ürünün hatasız olduğu anlaşılır. Tabi elle yapılan doğrulama faaliyetleri bu tür şeyler için uygun değil. Hatayı tekrarlamak için kaç kere daha koşulması gerektiğini bulmak için istatistikten faydalanılabilir. Açıklaması şöyle

The simple way to monitor how confident you are in the fix is to run the reproduction steps over and over, logging how many times you (hopefully!) don't encounter the issue.

SG - 1 Doğrulamaya Hazırlık - Prepare for Verification

SP 1.1 Select Work Products for Verification
CMMI her ürünün doğrulanmasını şart koşmaz. Doğrulanması istenen şeyler projenin başında "seçilir".

SP 1.3 Establish Verification Procedures and Criteria
Yeniden kullanılacak (re-use) ürünlerde doğrulama adımları atlanabilir. Ancak bu atlanan kriterlerin tanımlı olması gerektiğini belirtir.

"What are the criteria we use to determine when a verification level can be skipped"

SG 2 - Peer Review Nasıl Yapılır?
CMMI'da verification (doğrulama) için kullanılan başlıca araç gözden geçirmeler (Peer Review). Aşağıdaki cümlede  görülebilir.

In CMMI, peer reviews are used as a principle means of verification in the Verification process area

Dolayısıyla, gözden geçirmelerin daha kolay ve düzenli olması için, gözden geçirilecek her türlü belgenin bir kontrol listesi (checklist) var. Zaman içinde bu belgeler katlanarak artıyorlar.

Şekilde gözden geçirmelerin kalite üzerindeki etkisi görülebilir. Gözden geçirme toplantılarında toplantıyı yönetecek bir gözden geçirme lideri (peer review leader) olmasında fayda var.

SG - 3 Verify Selected Work Products
Örneğin projemiz için doğrulama olarak Unit test veya Unit Integration Test yöntemini seçebiliriz.

Test araçlarının çıktıları doğrulama için kullanılabilir. Gözden geçirme sonucundaki bulguların yerine getirildiği gösterilebilir.

Verification ve Agile
Bir kitapta şöyle bir soru gördüm

- How do you identify defects for removal and get recommendations for other changes that are needed?

Cevap:

- We demonstrate our products early and often to our customers
- We meet daily with our teammates and discuss openly the work we are doing. Our products are cheked into a library every day where others can see them and are encouraged to provide feedback. And they do.

Kitaba göre peer review sayılabilecek bu faaliyetler verification yapıldığını gösterirmiş.

CMMI - Project Planning Süreci

Project Planning Süreci
Bu alanın yapmasını istediği maddeler aşağıda.

"What","Who","When","How" and "How Much" sorularına cevap verir. Bu sorular arasında bağımlılık sırası vardır. "Who" sorusu (gereken kaynaklar) "What" (ne üretmem gerek) sorusuna bağlıdır. "How Much" sorusunun cevabı da diğer bütün parçaların bir araya gelmesinden sonra ortaya çıkar.

SG 1 Establish Estimates
  SP 1.1 Estimate the Scope of the Project
  SP 1.2 Establish Estimates of Work Product and Task Attributes
  SP 1.3 Define Project Lifecycle Phases
  SP 1.4 Estimate Effort and Cost
SG 2 Develop a Project Plan
  SP 2.1 Establish the Budget and Schedule
  SP 2.2 Identify Project Risks
  SP 2.3 Plan Data Management
  SP 2.4 Plan the Project's Resources
  SP 2.5 Plan Needed Knowledge and Skills
  SP 2.6 Plan Stakeholder Involvement
  SP 2.7 Establish the Project Plan
SG 3 Obtain Commitment to the Plan
  SP 3.1 Review Plans that Affect the Project
  SP 3.2 Reconcile Work and Resource Levels
  SP 3.3 Obtain Plan Commitment

SG 1 Establish Estimates
Projenin çerçevesini çıkarabilmek için yapılması gereken adımlardan birisi kestirimde bulunmak.

Kestirim
Software Estimation yazısına taşıdım

WBS
Kestirim için WBS (work breakdown structure) yani iş kırılımı yapısının çıkarılması kullanılabilir. Çevik yöntemlerde Story Point kullanılıyor. WBS sonunda Murphy Kanunları dikkate alınabilir.

To figure out how long something will take, figure out how long it should take and double it. Then, move up to the next higher unit of time. Thus, we allocate two weeks for a one-day project.

Judge yöntemini daha fazla kullanıyoruz. Bu yöntemle yapılan ağ yönetimi projesi 120 adam/ay çıktı.
WBS Nasıl Oluşturulur?
WBS şu elementlerden oluşur : Safhalar/Fazlar (Phase) , her safhanın faaliyet konuları (Activity) ve her faaliyet alanının işleri (Task). WBS yukarıdan aşağıya (top down) veya aşağıdan yukarıya (bottom up) oluşturulabilir. WBS oluştururken Schedule Management Technique'lerinden birisi olan işler arasına tedbir amaçlı boşluklar (slack time) koymaya dikkat edilmelidir. Eğer herhangi bir iş uzarsa tüm takvimin ve projenin ileriye kayması engellenebilir.

Yapılacak iş kırılımına numara verirken, numaralar sırayla da artabilir veya, içinde olması planlanan iterasyon/release numarası da kullanılabilir. Örneğin Proje-AMesajı-Iter1, Proje-AMesajı-2 diye bölersem A mesajını işlemeyi iki iterasyonda yapmayı planladığımı belirtirim.

Bu faaliyet için de bağlılık/taahhüt formu imzalatılıyor.
WBS için Not : 
Bu alanı açıklamadan önce küçük bir noktaya değinmek lazım. Çevik yaklaşımlarda, takvim ister user story isterse başka bir şey için olsun takım tarafından belirleniyor. CMMI ise WBS benzeri bir yaklaşım kullanıyor. WBS geleneksel olarak proje yöneticisi tarafından hazırlandığı için , takımın girdisi ile hazırlansa dahi , insanın kafasında sürekli güncellenen ve üzerinde düşünülen bir şey yerine, bir kere hazırlanıp uyulmaya çalışılan bir plan kavramını çağrıştırıyor.

Ayrıca proje tanım olarak tekildir. Eğer sürekli tekrarlayan işlerden oluşan operasyonel bir durum varsa (örneğin tahakkuk yapmak, fatura basmak gibi) bu tür işleri proje olarak değerlendirmek gerekmez . Örneğin hiç bir operasyonel iş için WBS çıkarıldığına şahit olmadım.

CMMI - DAR Süreci

Giriş
CMMI yazısının Decision Analysis and Report (DAR) hakkında olan kısmını buraya taşıdım. CMMI seviye 3'te  sürecin tüm kurum aynı olması gerekir.

DAR Nedir?
DAR,  (Türkçesi Karar Analizi ve Çözümleme) CMMI Seviye 3 olan firmaların yapması gereken süreç alanlarından birisidir (process area). Amacı ise kullanılabilecek alternatifleri bir değerlendirme işlemine tabi tutarak, en uygun olanını seçmektir.

Zorunlu DAR Nedir?
Normalde DAR herhangi bir karar için yapılabilir ancak bazı kurumlar, süreçlerini geliştirirken yapılmasını zorunlu kıldıkları DAR'ları tanımlıyorlar.

Süreç tarafından zorunlu olabilecek konu örnekleri:

1. Kullanılacak RAHAT (Rafta Hazır Ticari Ürün) yazılımın seçilmesi. (COTS software selection)
2. Kullanılacak RAHAT (Rafta Hazır Ticari Ürün) donanımın seçilmesi.(COTS hardware selection).
3. Kullanılacak yazılım geliştirme yaşam döngüsü modelinin seçilmesi (Software Development Life-cycle selection)
4. Altyüklenici seçilmesi (Subcontractor selection)
5. Mimari seçimi (Architecture selection)

1. DAR ve RAHAT Yazılım

Eğer kullanılabilecek RAHAT yazılım varsa, aralarında seçim yapmak için kullanılır. Örneğin İşletim Sistemi (Linux/Windows), Veritabanı (Oracle, MySql) seçimi için kullanılır.

2. DAR ve RAHAT Donanım

Eğer kullanılabilecek RAHAT donanım varsa, aralarında seçim yapmak için kullanılır. Örneğin Bilgisayar, Modem modeli seçimi için kullanılır.

3. DAR ve Yazılım Yaşam Döngüsü Modeli

Normalde kurumun süreci projeye özel olmamalıdır. Böylece çalışanlar süreci kolayca anlayıp her projeye daha iyi uyum sağlarlar. Ancak bazen projeye özgü yaşam modeli seçmek gerekebilir. DAR bu yüzden yapılır.

4. DAR ve Altyüklenici Seçilmesi

Altyükleniciler aralarında seçim yapmak için kullanılır.

5. Yazılım Mimarisi DAR
Diğer mimari seçeneklerinin değerlendirildiği ve alınan kararların neden alındığının açıklandığı bir belge olması beklenir. Burada bence en zor kısım "diğer" seçeneklerin değerlendirilmesi. İnsanın "diğer" mimarileri iyi bilmesi ve kullanmış olması gerekiyor ki artı ve eksileriyle mukayese edebilsin. Ancak bir çok "yazılım mimarının" zaten bu kadar tecrübesi olmadığı için, mukayese bence hakkının vererek yapılamıyor.

Zorunlu DAR İçinde Neden Geliştirme Ortamına Ait Bir Şey Yok 
Bence yazılım firmalarının en büyük eksikliği bu. Nadiren de olsa bazı firmalar bu gibi durumlarda da DAR yapıyor, ancak çoğu  zaman yazılıma ait önemli kararlar - mesela hangi framework'ün kullanılacağı - hem bir bilene sorularak seçiliyor.

DAR Kriterlerinin imzalanması

Bazı kurumlar süreçlerini DAR kriterlerini belirledikten sonra, DAR ekibi tarafından imzalanması şeklinde tasarlamışlar. 

DAR ve Puanlama
Kriterlere göre puanlama yapılıyor.Yapılan puanlamalar neticesinde en uygun alternatif seçiliyor.

DAR Waiver Formu
Zorunlu olan bir DAR yapılmayacaksa gerekçesi bu forma yazılır. Genellikle gerekçe olarak

RAHAT Donanım
DAR için harcanacak efor, ürünün kendisinden çok daha maliyetli olacağı için DAR yapılmadı.

Yaşamsal Döngü Modeli
Default kurum süreci kullanılacağı için DAR yapılmadı

Yazılım Mimarisi DAR
Tekrar kullanılacak yazılım mimarisi olduğu için DAR yapılmadı.

gibi gerekçeler yazılabilir.

Sonuç
Bu süreç alanı anlaması ve uygulaması en kolay şeylerden birisi. Proje alternatifler ve seçimler silsilesi olarak düşünülürse aslında bu süreç alanı CMMI olmayan projelerde bile bilinçli veya bilinçsiz şekilde zaten uygulanıyor.

Birçok süreç alanı için piyasada çok çeşitli yazılımlar bulunmakta ancak DAR kayıtlarını basit bir excel tablosu olarak tutmanın bile yeterli olduğunu düşünüyorum.

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.


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.
  

MIL STD 498

Not : Bu yazı ile ilgili olarak CMMI başlıklı yazıyı okuyabilirsiniz.

MIL-STD-498

Savunma sanayimizin öncü kuruluşlarından olduğunu iddia eden bir çok firmada kullanılan yazılım geliştirme standardı MIL-STD-498. Vakti zamanında (1994 yılında) başlatılan bu standart 1998 yılında iptal edilmiş olmasına rağmen, maalesef iç piyasamızda halen kullanım görmekte. Bu sürecin yerini IEEE 12207 aldı. IEEE 12207,  daha fazla yaşam döngüsü odaklı.

Sürecin ne kadar High Ceremony ( ki bence hantal kelimesinin daha kibarca söylenmiş hali ) olduğunu gösteren bir şekli buradan aldım.

Süreç boyunca üretilen bazı dokümanları gösteren bir şekli ise buradan aldım.

Her ne kadar yukarıdaki şekilde iterative (tekrarlamalı/yinelemeli) yaklaşımdan bahsedilse bile hiç bir zaman kullanıldığına şahit olmadım.

2012 yılında bile yazılımların şelale modelinde geliştirilmesine sebep olan bu süreci kullanmaya devam eden (bir doküman bir kere onaylanınca kimse geriye dönüp onunla bir daha oynamak istemiyor, dolayısıyla ister istemez şelale yöntemine doğru kayılıyor) firmaları anlayamıyorum !

Türk Silahlı Kuvvetlerini Güçlendirme Vakfı firmaları (Aselsan, Roketsan, Havelsan, İşbir, Aspilsan) sırtlarını vakfa dayadıkları için ticari kaygıları diğer firmalara göre daha az. Ancak vakıfın iştiraki olmayan ticari müesseselerin bu hantal model ile esnekliklerini kaybetmelerine rağmen, ısrarla bu alışkanlıktan vazgeçmemeleri bence çok yazık !.

Data Item Description (DID)
DID üretilmesi beklenen belge anlamında düşünülebilir. MIL-STD-498 tam 22 tane DID tanımlıyor. Her DID'in içeriği ve şekli belirli. Her ne kadar belgenin şeklini değiştirmek mümkün olsa da, tüm DID'lerin gerçekten işe yaradığını söyleyebilmek ve hakkını vererek yazıldığını söyleyebilmek çok zor. Bu DID'lerden hangilerinin müşteriye teslim edileceği, CDRL belgesinden tanımlanır.

Örnek Proje Takvimi

• Proje Başlangıcı : T0
• SRR (Sistem Gereksinimlerini Gözden Geçirme Toplantısı) : T0 + 3
• PDR (Ön Tasarım Gözden Geçirme Toplantısı) : T0 + 6
• CDR (Kritik Tasarım Gözden Geçirme Toplantısı) : T0 + 8
• Ön Entegrasyon 1 : T0 + 10
• Ön Entegrasyon 2 : T0 + 13
• FAT : T0 + 19
• Kesin Kabul : T0 + 27

Bazı Kelimeler ve Türkçeleri

SDP : Software Development Plan
SDP başlıklı yazıya göz atabilirsiniz.

CSCI : Computer Software Configuration Item. Official definition of CSCI (Computer Software Configuration Item) başlılı soruya göz atılabilir. Aselsan'da Yazılım Konfigürasyon Birimi (YKB) kelimesi kullanılıyor. Kabaca geliştirilen uygulama anlamına geliyor. Bir proje altında birden fazla uygulama olabilir Her CSCI CSC'lerden oluşur. Her CSCI için SRS ve SDD gerekir.

CSCI versiyon numaraları genellikle X.Y.Z (Major.Minor.Patch) şeklinde verilir. Açıklaması ise aşağıda.

Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

ICD : Interface Control Document. Yazılım Arayüzü başlıklı yazıya göz atabilirsiniz.

IDD : Interface Design Document. Yazılım Arayüzü başlıklı yazıya göz atabilirsiniz.

Sözleşme : Kontrat, Tender Document gibi isimlerle anılır. Sözleşme bir çok eklerden oluşabilir. Bir çok gereksinimim, çıkış noktası sözleşme ve ekleridir.

ECP: Engineering Change Proposal. Mühendislik Değişikliği Önerisi. Sözleşme kapanmadan yapılan değişikliği belirtir. ECP'ler ECP-1, ECP-2 olarak adlandırılır. Toplantı tutanağıyla kayıt altına alınır.

MKN : Mühendislik Koordinasyon Notu

FAR : Fault Analysis Report

SRS :
Software Requirements Specification başlıklı yazıya taşıdım.

SSDD: System/Subsytem Design Document
SSDD başlıklı yazıya taşıdım.

SDD :
SDD başlıklı yazıya taşıdım.

SBM : Software Build Manual. CM tarafından adım adım takip edilerek doğrulanır. Bazı şirketler SBM belgesinde izlenebilirlik istiyorlar. Ayrıca SBM gözden geçirilir ve yayınlanır.


CDR :
CDR başlıklı  yazıya taşıdım.

UITD : Unit Integration Test Description

UTD :
Unit Test Description başlıklı yazıya taşıdım.

STP :
Software Test Plan başlıklı yazıya taşıdım.

STD :
Software Test Document başlıklı yazıya taşıdım.

STR : Software Test Report. Aselsan'da Yazılım Test Raporu (YTER) kelimesi kullanılıyor. Koşturulan testler ve sonuçlarını gösteren rapor.

Kısaltmalardan sonra akışa bir göz atacak olursak aşağıdakine benzer bir silsile izleniyor. Aşamalar projelere göre farklı isimler alabiliyor. Farklı yöntemler de izlenebilir. Sadece örnek olsun diye yazıyorum.

Belgelerde Kullanılan Gizlilik Seviyeleri
Çok Gizli -> Top Secret
Gizli -> Secret
Özel -> Confidential
Hizmete Özel -> Restricted
Tasnif Dışı -> Unclassified

----------------------------------------------------------------------------------------------------
T0 (Proje Başlangıcı) --> Genellikle bir avans alınır.

SRR (System Requirements Review. Türkçesi Sistem Gereksinimleri Gözden Geçirme Toplantısı)
Sistem gereksinimlerinin ortaya konulduğu aşama
SRR'da teslim edilen bazı belgeler şunlar.

SSS : System/Subsystem Specification

PDR (Preliminary Design Review. Türkçesi Ön Tasarım Gözden Geçirme Toplantısı)
Ön Tasarım yapıldıktan sonra gelinen aşama. PDR'da teslim edilen bazı belgeler şunlar.

SSDD : System/Subsystem Design Document
SRS : Software Requirements Specification
ICD : Interface Control Document

Not : PDR'dan önce bu belgelerde izlenebilirlik (traceability ) bilgisinin olması, gözden geçirilmiş olup, baseline yapılmış olması gerekir. Baseline (anahat) için bazen aşağıdaki kelimeler de kullanılır.

Functional Baseline (SSS)
Allocated Baseline (SRS,IRS)
Design Baseline (SSDD,SDD)
Product Baseline (Nihai ürün)

Müşteri ile gerçek PDR toplantısı yapmadan önce, ekip içinde çatlak ses çıkmaması için bir prova yapılmasında fayda var.


Bu aşamada yazılım gereksinimleri doğrulanır. PDR genellikle ödeme kilometre taşıdır. Bazen seçilen donanımın onayı da bu aşamada verilir. Projenin %25-30 arası bedeli bu kilometre taşı geçildikten sonra ödenir. Dolayısıyla güvenilirlik ve maddi açıdan önemlidir. PDR tamanlanınca ve açık işlem maddeleri kapatılınca, resmi yazı ile PDR'ın başarı ile tamamlandığı bildirilir.

PDR'ı takiben CDR yapılır.


CDR  (Critical Design Review. Türkçesi Kritik Tasarım Gözden Geçirme Toplantısı)

Müşteri ile gerçek CDR toplantısı yapmadan önce, ekip içinde çatlak ses çıkmaması için bir prova yapılmasında fayda var.

Bazı projelerde CDR aşamasında artık nihai karar verildiği için sistemle/yazılımla ilgili ölçümler verilebilir veya talep edilebilir.

Development -->
Bir çok farklı test kademesi kullanmak faydalı. Özellikle pahalı donanımların olduğu projelerde gerçek donanıma gelmeden önce mümkün olduğunda simülatör, emülatörlerle testler koşturmak gerekir.

Ön Entegrasyon : FAT testinden önce yapılan tümleşim testi. Sistemi daha küçük parçalar halinde birleştirmek için kullanılır. Ön entegrasyon testinden önce kod için ayrı bir branch açmak iyi bir fikir olabilir. Geliştirme devam ederken, testte çıkan hatalar da branch üzerinde düzeltilebilir. Ön entegrasyon testi bittikten sonra tutanak tutulur.

FAT (Fabrika Kabul Test) : Fabrika/Laboratuvar ortamında yapılan test provası --> Tüm paydaşların hazır olduğu noktada başlanabilir. Geciken bir paydaş, tüm takvimi öteleyebilir.

FAT-SYS, SEL vs. gibi farklı isimler olan bir aşama : Bu aşamada tüm sistem bir araya getirilerek gerçek sensörler simüle ediliyorlar. Bu aşamaya projesine göre farklı isimler veriliyor.-->
Konuyu FAT Testi yazısına taşıdım.

HAT : Eğer gerekiyorsa gerçek sensörlerin kullanıldığı aşama -->

SAT (Örneğin geminin denize açılıp test yapması veya mevzide test yapılması). SAT testleri genelde stresli olurlar. Bu aşamada konu başlıklarına göre testlerin yapılması işleri hızlandırabilir.

Donanım Tederaik Aşaması:
Önce RFQ (Request for Quote) istenir. RFQ yanıtları sonrası BAFO (Best and Final Offer)

CMMI - Organizational Process Focus Süreci

OPF (Organizational Process Focus) - Process Management

• SG 1 Determine Process Improvement Opportunities
  • SP 1.1 Establish Organizational Process Needs
  • SP 1.2 Appraise the Organization's Processes
  • SP 1.3 Identify the Organization's Process Improvements
• SG 2 Plan and Implement Process Improvements
  • SP 2.1 Establish Process Action Plans
  • SP 2.2 Implement Process Action Plans
• SG 3 Deploy Organizational Process Assets and Incorporate Experiences
  • SP 3.1 Deploy Organizational Process Assets
  • SP 3.2 Deploy Standard Processes
  • SP 3.3 Monitor the Implementation
  • SP 3.4 Incorporate Experiences into Organizational Process Assets

SG 1
SG 1 kapsamında daha iyi ne yapabiliriz soru sorulur. 

Lessons Learned
Lessons Learned - Öğrenilen Dersler yazısına taşıdım

SG 3 

SG 3 proje çapında iyi yapılan işlerin veya çıkarılan derslerin kurumsallaştırılmasını vurguluyor.