Yetenek Olgunluk Modeli - Capability Maturity Model

Yetenek Olgunluk Modeli ( CMM ) ile sözleşmeli olduğu kuruluşlardan toplanan verilerin bir çalışma sonrasında 1986 yılında oluşturulan bir gelişme modeli ABD Savunma Bakanlığı araştırma finanse. "Olgunluk" terimi , geçici uygulamalardan resmi olarak tanımlanmış adımlara, yönetilen sonuç ölçütlerine ve süreçlerin aktif optimizasyonuna kadar süreçlerin formalite ve optimizasyon derecesi ile ilgilidir .

Modelin amacı, mevcut yazılım geliştirme süreçlerini iyileştirmektir , ancak diğer süreçlere de uygulanabilir.

2006 yılında, Carnegie Mellon Üniversitesi Yazılım Mühendisliği Enstitüsü , CMM'nin yerini alan ve bazı dezavantajlarını gideren Yetenek Olgunluk Modeli Entegrasyonunu geliştirdi .

Genel Bakış

Yetenek Olgunluk Modeli başlangıçta, devlet yüklenicilerinin süreçlerinin sözleşmeli bir yazılım projesini uygulama becerisini objektif olarak değerlendirmek için bir araç olarak geliştirilmiştir . Model, ilk olarak IEEE Yazılımında ve daha sonra Watts Humphrey tarafından yazılan 1989 Yazılım Sürecini Yönetme kitabında açıklanan süreç olgunluk çerçevesine dayanmaktadır . Daha sonra 1993'te bir raporda ve 1995'te aynı yazarlar tarafından bir kitap olarak yayınlandı.

Model, yazılım geliştirme alanından gelse de, genel olarak iş süreçlerine yardımcı olmak için bir model olarak da kullanılmaktadır ve ayrıca devlet dairelerinde, ticarette ve endüstride dünya çapında yaygın olarak kullanılmaktadır.

Tarih

Yazılım süreçleri için öncelikli ihtiyaç

1980'lerde bilgisayar kullanımı daha yaygın, daha esnek ve daha az maliyetli hale geldi. Organizasyonlar bilgisayarlı bilgi sistemlerini benimsemeye başladı ve yazılım geliştirmeye olan talep önemli ölçüde arttı. Yazılım geliştirmeye yönelik birçok süreç, tanımlanmış birkaç standart veya " en iyi uygulama " yaklaşımı ile emekleme dönemindeydi .

Sonuç olarak, büyümeye artan acılar eşlik etti: proje başarısızlığı yaygındı, bilgisayar bilimi alanı hala ilk yılındaydı ve proje ölçeği ve karmaşıklığı için hedefler, planlanan bir bütçe dahilinde yeterli ürünleri sunma pazar kapasitesini aştı. Gibi Bireyler Edward Yourdon , Larry Constantine , Gerald Weinberg , Tom DeMarco ve David Parnas yazılım geliştirme süreçlerini profesyonelleştirmek amacıyla araştırma sonuçları ile makaleler ve kitaplar yayınlamaya başladı.

1980'lerde, yazılım taşeronlarını içeren birkaç ABD askeri projesi bütçeyi aştı ve planlanandan çok daha sonra tamamlandı. Bunun neden olduğunu belirlemek amacıyla, Birleşik Devletler Hava Kuvvetleri , Yazılım Mühendisliği Enstitüsü'nde (SEI) bir çalışmayı finanse etti.

Öncü

Aşamalı olgunluk modelinin BT'ye ilk uygulaması CMU / SEI tarafından değil , 1973'te BT kuruluşları için büyüme modelinin aşamalarını yayınlayan Richard L. Nolan tarafından yapıldı .

Watts Humphrey , IBM'deki 27 yıllık kariyerinin sonraki aşamalarında süreç olgunluğu kavramlarını geliştirmeye başladı.

Yazılım Mühendisliği Enstitüsünde Geliştirme

Modelin ABD Savunma Bakanlığı Yazılım Mühendisliği Enstitüsü (SEI) tarafından aktif olarak geliştirilmesi, 1986'da Humphrey'in IBM'den emekli olduktan sonra Pittsburgh, Pennsylvania'daki Carnegie Mellon Üniversitesi'nde bulunan Yazılım Mühendisliği Enstitüsüne katılmasıyla başladı . ABD Hava Kuvvetlerinin talebi üzerine, sözleşmelerin bir parçası olarak yazılım yüklenicilerinin kapasitesini değerlendirmede ABD Savunma Bakanlığı'na yardımcı olmak için Süreç Olgunluk Çerçevesini resmileştirmeye başladı.

Hava Kuvvetleri çalışmasının sonucu, ordunun yazılım taşeronlarının süreç yeterlilik olgunluğunun objektif bir değerlendirmesi olarak kullanması için bir modeldi. Humphrey bu çerçeveyi, Philip B. Crosby tarafından "Quality is Free" adlı kitabında geliştirilen daha önceki Kalite Yönetimi Olgunluk Tablosuna dayandırdı . Humphrey'in yaklaşımı, organizasyonların süreçlerini belirli bir sırayla çözme sürecine dayalı aşamalar halinde olgunlaştırdığına dair benzersiz anlayışı nedeniyle farklılık gösterdi. Humphrey yaklaşımını, her bir ayrı geliştirme sürecinin olgunluğunu bağımsız olarak ölçmek yerine, bir organizasyon içindeki yazılım geliştirme uygulamaları sisteminin aşamalı evrimine dayandırdı. CMM bu nedenle farklı kuruluşlar tarafından genel iş süreci performansını anlamak ve ardından iyileştirmek için genel ve güçlü bir araç olarak kullanılmıştır.

Watts Humphrey's Capability Maturity Model (CMM) 1988'de ve 1989'da Managing the Software Process'de kitap olarak yayınlandı .

Kuruluşlar başlangıçta bir süreç olgunluk anketi ve Humphrey ve Yazılım Mühendisliği Enstitüsü'ndeki meslektaşları tarafından tasarlanan bir Yazılım Yeteneği Değerlendirme yöntemi kullanılarak değerlendirildi.

Yetenek Olgunluk Modelinin, beş olgunluk seviyesinin her birindeki tanımlanmış süreç alanları ve uygulamalardan oluşan bir dizi olarak tam temsili 1991'de başlatıldı ve Versiyon 1.1, Ocak 1993'te tamamlandı. yazarlar, Mark C. Paulk, Charles V. Weber, Bill Curtis ve Mary Beth Chrissis. Amerika Birleşik Devletleri New York, ABD.

Yetenek Olgunluk Modeli Entegrasyonu

CMM modelinin yazılım geliştirmedeki uygulaması bazen sorunlu olmuştur. Bir organizasyon içinde ve genelinde entegre olmayan birden fazla modelin uygulanması, eğitim, değerlendirme ve iyileştirme faaliyetlerinde maliyetli olabilir. Entegre Yetenek Olgunluk Modeli (CMMI) projesi yazılım geliştirme süreçleri için birden modellerini kullanarak sorununu çözmek için kuruldu CMM modeli kullanılan genel bir teorik süreç yeterlilik modeli olmaya devam rağmen, böylece CMMI modeli, CMM modelin yerini kamu malı.

Diğer süreçlere uyarlanmıştır

CMM, başlangıçta devlet yüklenicilerinin sözleşmeli bir yazılım projesini gerçekleştirme becerisini değerlendirmek için bir araç olarak tasarlanmıştı. Yazılım geliştirme alanından gelmesine rağmen , IS / IT (ve diğer) organizasyonlarında sürecin olgunluğunun (örneğin, BT hizmet yönetimi süreçleri) genel bir modeli olarak yaygın şekilde uygulanabilir, uygulanmıştır ve uygulanmaya devam etmektedir .

Model konuları

Olgunluk modelleri

Bir olgunluk modeli , bir organizasyonun davranışlarının, uygulamalarının ve süreçlerinin güvenilir ve sürdürülebilir bir şekilde gerekli sonuçları ne kadar iyi üretebileceğini açıklayan bir dizi yapılandırılmış seviye olarak görülebilir.

Bir olgunluk modeli, karşılaştırma için bir kıyaslama ölçütü olarak ve anlamaya yardımcı olarak kullanılabilir - örneğin, karşılaştırma için temel olarak kullanılabilecek ortak bir şeyin olduğu farklı kuruluşların karşılaştırmalı değerlendirmesi için. CMM durumunda, örneğin, karşılaştırma için temel, kuruluşların yazılım geliştirme süreçleri olacaktır.

Yapısı

Model beş yönü içerir:

Olgunluk Seviyeleri: 5 seviyeli bir süreç olgunluk sürekliliği - burada en üst (5.) seviye, proses optimizasyonu ve sürekli proses iyileştirmenin bir kombinasyonu ile proseslerin sistematik olarak yönetileceği kavramsal ideal bir durumdur.
Anahtar Süreç Alanları: Bir Anahtar Süreç Alanı, birlikte gerçekleştirildiğinde, önemli olduğu düşünülen bir dizi hedefe ulaşan ilgili faaliyetler kümesini tanımlar.
Hedefler: Kilit bir süreç alanının hedefleri, o kilit süreç alanının etkili ve kalıcı bir şekilde uygulanması için var olması gereken durumları özetler. Hedeflere ne ölçüde ulaşılmış olduğu, kuruluşun o olgunluk düzeyinde ne kadar kapasite oluşturduğunun bir göstergesidir. Hedefler, her bir temel süreç alanının kapsamını, sınırlarını ve amacını belirtir.
Ortak Özellikler: ortak özellikler, temel bir süreç alanını uygulayan ve kurumsallaştıran uygulamaları içerir. Beş tür ortak özellik vardır: gerçekleştirme taahhüdü, gerçekleştirme yeteneği, gerçekleştirilen etkinlikler, ölçüm ve analiz ve uygulamayı doğrulama.
Temel Uygulamalar: Temel uygulamalar, alanın uygulanmasına ve kurumsallaşmasına en etkili şekilde katkıda bulunan altyapı ve uygulama unsurlarını tanımlar.

Seviyeler

Modelin sürekliliği boyunca tanımlanan beş seviye vardır ve SEI'ye göre: "Bir organizasyonun yazılım süreçlerinin tahmin edilebilirliği, etkinliği ve kontrolünün, organizasyon bu beş seviye yukarı çıktıkça gelişeceğine inanılmaktadır. Kesin olmamakla birlikte, ampirik kanıtlar bugüne kadar bu inancı destekliyor ".

Başlangıç (kaotik, geçici, bireysel kahramanlık) - yeni veya belgelenmemiş bir tekrar sürecinin kullanımının başlangıç noktası.
Tekrarlanabilir - süreç, en azından aynı adımların tekrarlanmaya çalışılabileceği şekilde yeterince belgelenmiştir.
Tanımlanmış - süreç, standart bir iş süreci olarak tanımlanır / onaylanır
Yetenekli - süreç, üzerinde anlaşılan ölçülere göre nicel olarak yönetilir.
Verimli - süreç yönetimi, bilinçli süreç optimizasyonunu / iyileştirmesini içerir.

Bu olgunluk seviyelerinin her biri içinde, o seviyeyi karakterize eden Anahtar Süreç Alanları vardır ve bu tür alanların her biri için beş faktör vardır: hedefler, bağlılık, yetenek, ölçüm ve doğrulama. Bunlar CMM'ye özgü olmak zorunda değildir ve - yaptıkları gibi - kuruluşların olgunlaşma yolunda geçmesi gereken aşamaları temsil eder.

Model, süreç olgunluğunun bir seviyeden diğerine aşamalı olarak geliştirilebildiği teorik bir süreklilik sağlar. Seviyeleri atlamaya izin verilmez / uygulanabilir.

Seviye 1 - Başlangıç: Bu seviyedeki süreçlerin özelliği, (tipik olarak) belgelenmemiş ve dinamik bir değişim durumunda, kullanıcılar veya olaylar tarafından geçici , kontrolsüz ve reaktif bir şekilde yürütülme eğilimindedir . Bu, işlemler için kaotik veya dengesiz bir ortam sağlar. (Örnek - yeni bir ameliyatı az sayıda yapan bir cerrah - olumsuz sonuç seviyeleri bilinmemektedir).

Seviye 2 - Tekrarlanabilir: Bazı süreçlerin muhtemelen tutarlı sonuçlarla tekrarlanabilir olması bu olgunluk düzeyinin bir özelliğidir. Süreç disiplininin katı olması pek olası değildir, ancak mevcut olduğu durumlarda, mevcut süreçlerin stresli zamanlarda sürdürülmesini sağlamaya yardımcı olabilir.

Seviye 3 - Tanımlı: Bu seviyedeki süreçlerin özelliği, oluşturulmuş ve zaman içinde bir dereceye kadar iyileştirmeye tabi olan tanımlanmış ve belgelenmiş standart süreçlerin olmasıdır. Bu standart süreçler mevcuttur. Süreçler sistematik veya tekrar tekrar kullanılmamış olabilir - kullanıcıların yetkin hale gelmesi veya işlemin bir dizi durumda doğrulanması için yeterli. Bu, gelişimsel bir aşama olarak düşünülebilir - daha geniş bir aralıktaki koşullarda kullanım ve kullanıcı yetkinliği geliştirme ile süreç, bir sonraki olgunluk düzeyine kadar gelişebilir.

Seviye 4 - Yönetilebilir (Yetenekli): Süreç ölçütleri kullanılarak süreç hedeflerine etkin bir şekilde ulaşılmasının bir dizi operasyonel koşulda kanıtlanabilmesi, bu seviyedeki süreçlerin bir özelliğidir. Sürecin birden fazla ortamda uygunluğu test edilmiş ve süreç iyileştirilmiş ve uyarlanmıştır. Süreç kullanıcıları, süreci çok sayıda ve çeşitli koşullarda deneyimlemiş ve yetkinliklerini gösterebilmiştir. Süreç olgunluğu, ölçülebilir kalite kayıpları veya spesifikasyonlardan sapmalar olmaksızın belirli projelere uyarlamalara olanak tanır. Süreç Yeteneği bu seviyeden kurulur. (Örnek - sıfıra yaklaşan negatif sonuç seviyeleri ile yüzlerce kez bir ameliyat yapan cerrah).

Seviye 5 - Optimize Etme (Verimli): Odak noktasının hem artan hem de yenilikçi teknolojik değişiklikler / iyileştirmeler yoluyla süreç performansını sürekli olarak iyileştirmeye odaklanması bu seviyedeki süreçlerin bir özelliğidir. Olgunluk seviyesi 5'te süreçler , süreç performansını iyileştirmek için süreç varyasyonunun istatistiksel olarak yaygın nedenlerini ele almak ve süreci değiştirmekle (örneğin, işlem performansının ortalamasını kaydırmak için) ilgilenir . Bu, belirlenen nicel süreç iyileştirme hedeflerine ulaşma olasılığını sürdürmekle aynı zamanda yapılacaktır.

2008 ve 2019 arasında, verilen değerlendirmelerin yaklaşık% 12'si 4. ve 5. vade seviyesindeydi.

Eleştiri

Model, başlangıçta devlet müteahhitlerinin bir yazılım projesi gerçekleştirme kabiliyetini değerlendirmeyi amaçlıyordu. Bu amaç için kullanılmış ve uygun olabilir, ancak eleştirmenler CMM'ye göre süreç olgunluğunun başarılı bir yazılım geliştirme için zorunlu olmadığına işaret etti.

Yazılım süreci çerçevesi

Belgelenen yazılım süreci çerçevesi, bir kuruluşun veya projenin Anahtar Süreç Alanları ile tutarlılığını değerlendirmek isteyenlere rehberlik etmeyi amaçlamaktadır. Her olgunluk seviyesi için beş kontrol listesi türü vardır:

Tür	Açıklama
Politika	Temel Süreç Alanları tarafından önerilen politika içeriğini ve KPA hedeflerini açıklar.
Standart	Anahtar Süreç Alanlarında açıklanan belirli iş ürünlerinin önerilen içeriğini açıklar.
İşlem	Anahtar Süreç Alanları tarafından önerilen süreç bilgisi içeriğini açıklar. Bunlar, aşağıdakiler için kontrol listelerinde rafine edilmiştir: Roller, giriş kriterleri, girdiler, faaliyetler, çıktılar, çıkış kriterleri, incelemeler ve denetimler, yönetilen ve kontrol edilen iş ürünleri, ölçümler, dokümante edilmiş prosedürler, eğitim ve araçlar
Prosedür	Anahtar Süreç Alanlarında açıklanan dokümante edilmiş prosedürlerin önerilen içeriğini açıklar.
Düzeye genel bakış	Tüm olgunluk düzeyine genel bir bakış sağlar. Bunlar aşağıdakiler için kontrol listelerinde daha da rafine edilmiştir: Anahtar Süreç Alanları amaçlar, hedefler, politikalar ve standartlar; süreç açıklamaları; prosedürler; Eğitim; araçlar; incelemeler ve denetimler; iş ürünleri; ölçümler

Languages

In other projects