» »

Yazılım sistemleri geliştiren kuruluşların olgunluğunu değerlendirmek için modeller. ISO standartları, SW-CMM

Kasım 1986'da, Amerikan Yazılım Mühendisliği Enstitüsü (SEI), Mitre Corporation ile birlikte, geliştirme süreçlerinin olgunluğuna ilişkin bir genel bakış geliştirmeye başladı. yazılım bu onların iç süreçlerini iyileştirmeye yardımcı olmayı amaçladı.

Böyle bir anketin geliştirilmesi, ABD federal hükümetinden yazılım geliştirme için taşeronları değerlendirmek için bir yöntem talebiyle başlatıldı. Asıl sorun büyük projeleri yönetememekti. Birçok şirkette projeler önemli gecikmelerle ve planlanan bütçenin üzerinde tamamlandı. Bu soruna bir çözüm bulmak gerekiyordu.

Eylül 1987'de SEI, kısa inceleme olgunluk düzeylerini açıklayan yazılım geliştirme süreçleri ve şirkette iyileştirmeye açık alanları belirlemek için bir anket. Ancak, çoğu şirket bu anketi bitmiş model Bunun sonucunda 4 yıl sonra anket gerçek bir model olan Yazılım için Yetenek Olgunluk Modeli'ne (CMM) dönüştürülmüştür. 1991 yılında piyasaya sürülen CMM'nin ilk versiyonu (Sürüm 1.0), 1992 yılında yaklaşık 200 yazılım uzmanının ve geliştirici topluluğu üyesinin katıldığı bir çalıştayda katılımcılar tarafından revize edildi.

Sonuç olarak, tüm dünyada hala aktif olarak kullanılan CMM standardı Sürüm 1.1 yayınlandı.

Pirinç. 1. SMM kullanmanın küresel etkisi

SMM'ye olan bu ilginin nedenleri açıktır. Hem yazılım geliştiriciler hem de yönetimleri, süregelen problemlerinin çoğu zaman çok iyi farkında olmalarına rağmen, ilk etapta şirketin hangi değişikliklere ihtiyaç duyduğu konusunda anlaşamazlar. İyileştirmeler yapmak için birleşik bir strateji geliştirmeden yönetim, iyileştirme için en yüksek öncelikli görevler hakkında çalışanları ile karşılıklı anlayış bulamaz. Süreçleri iyileştirmek için harcanan çabalardan maksimum sonucu elde etmek için, geliştirme süreçlerinin olgunluğunu aşamalı olarak evrimsel bir şekilde iyileştirecek aşamalı bir geliştirme stratejisine sahip olmak gerekir.

Sürekli süreç iyileştirme, devrim niteliğindeki yeniliklere değil, bir şirketin kültürünün kademeli olarak yetiştirilmesine dayanır. CMM, bu artımlı iyileştirme için 5 süreç olgunluğu düzeyine bölünmüş bir çerçeve sağlar. Bu 5 seviye, bir şirketteki yazılım geliştirme süreçlerinin olgunluk seviyesini değerlendirmek ve parametrelerini ölçmek için bir ölçeği temsil eder.

Pirinç. 2. Olgunluk düzeyinde sürekli artış ilkesi: organizasyonun gelişimi için fırsatlar

Her seviyenin ana özellikleri şunlardır:

  1. Başlangıç ​​- Geliştirme süreci kaotiktir. Süreçlerden sadece birkaçı tanımlanmıştır ve projelerin başarısı bireysel sanatçılara bağlıdır.
  2. Tekrarlanabilir - Ana proje yönetimi süreçleri oluşturulmuştur: izleme maliyetleri, zamanlama ve işlevsellik. Benzer projelerde (benzer uygulamalara sahip projeler) önceki başarıları tekrarlamak için gereken bazı süreçleri kolaylaştırdı.
  3. Tanımlı - Yazılım geliştirme ve proje yönetimi süreçleri şurada tanımlanır ve uygulanır: birleşik sistemşirket süreçleri. Tüm projeler, belirli bir projeye uyarlanmış standart bir yazılım geliştirme ve destek organizasyon süreci kullanır.
  4. Yönetilen - Geliştirme süreci performansı ve kalitesi hakkında ayrıntılı nicel veriler toplayın son ürün... Bu verilerin önemi ve dinamikleri analiz edilir.
  5. Optimizasyon - Sürekli süreç iyileştirme, nicel süreç verilerine ve yeni fikirlerin ve teknolojilerin pilot uygulamasına dayanır.

SW-CMM'ye Giriş

(Yazılım Mühendisliği Enstitüsü Yetenek Olgunluk Modeli'ne dayalı olarak yazılım geliştirme süreçlerinin olgunluğunun iyileştirilmesi)

Kurs aşağıdakilere yöneliktir:
Yazılım şirketlerinin başkanları, departman ve yazılım geliştirme projelerinin başkanları ve aşağıdakilerle ilgilenen kalite uzmanları için:

  • mevcut üretim süreçlerinin şeffaflığının iyileştirilmesi;
  • süreçlerin ve bir bütün olarak şirketin verimliliğini artırmak;
  • üretim maliyetini ve mevcut "gizli" üretim hacmini azaltmak;
  • profesyonel ortamda şirketin itibarını artırmak;
  • ürünler için yeni pazarlar açmak.

    2.1 Maliyet, süre ve elde edilen sonuçlar. endüstri istatistikleri
    2.2 CMM'de yatırım getirisi

    3.1 TKY (Toplam Kalite Yönetimi), SPI (Yazılım Süreç İyileştirmesi) ve CMM'nin temeli olarak En İyi İş Uygulamaları
    3.2 Temel konseptler TKY. Yazılım ürünlerinin üretiminde TKY yaklaşımlarının uygulanması
    3.3 CMM süreç iyileştirme modelinin doğasında bulunan faydalar ve riskler
    3.4 Süreç kavramı. Süreç yaklaşımının ana bileşenleri
    3.5 Süreç olgunluk seviyeleri

    9.1 BT endüstrisi için standartlar sistemi (Yol Haritası)
    9.2 CMM ile ISO ilişkisi, Rational Unified Process, Proje Yönetimi
    9.3 Küçük Kuruluşlar için CMM Uygulaması
    9.4 SMM'de ne eksik
    9.5 Belgeler ve süreçler

    10.1 SW-CMM modeline son bakış. Dünyadaki dağıtım. ana zorluklar
    10.2 CMMI (Yetenek Olgunluk Modeli Entegrasyonu) - Daha fazla gelişme CMM modelleri

    Bir dizi slayt, pratik alıştırmalar için materyaller, kendi kendine çalışma için ek materyaller.

    SW-CMM ile ilgili eksiksiz bir belge seti (standart metni, değerlendirme yöntemleri, sektörle ilgili istatistiksel materyaller, belge örnekleri)

    BT şirketlerinde SW-CMM modelini uygulama teknolojisi üzerine uygulamalı kurs

    Kısa açıklama:
    Bu kurs, şirketlerin bağımsız ve yetkin bir şekilde süreçlerin olgunluğunu iyileştirmek için bir modelin uygulanmasına ilişkin çalışmaları yürütmelerine yardımcı olmayı amaçlamaktadır. tipik hatalar ve uygulama sorunları.

    Kurs aşağıdakilere yöneliktir:
    Kurs, yazılım geliştirme ile ilgilenen işletme ve departman yöneticileri, proje yöneticileri, kalite yöneticileri ve geliştirmelerinin kalitesini iyileştirmek ve süreçlerini CMM'ye göre belgelendirmekle ilgilenen diğer kişilere yöneliktir.

  • BT için tanınan kalite yönetimi standartlarının gözden geçirilmesi (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)
    17. ISO aracılığıyla CMM'ye?

    • Yazılım ürünlerinin kalitesi belki de yazılım endüstrisindeki en büyük sorunlardan biridir. Kalite, hataların olmamasından çok daha fazlasıdır. Bir dizi farklı özelliği varsayar: güvenilirlik, hack direnci, uyarlanabilirlik, uyumluluk, bakım kolaylığı, taşınabilirlik, verimlilik vb. Yazılım endüstrisinde bu kadar çeşitli kalite standartlarının olması şaşırtıcı değildir.

    Kaliteyi ölçmek kolaydı: Ya bize para ödendi ya da alınmadı.
    Dekan Leffingwell, Don Widrig.
    Yazılım Gereksinim Yönetimi

    CMM / CMMI

    Muhtemelen en seçkin kalite standardı, türevleriyle birlikte geliştirme süreçlerinin olgunluk düzeyini değerlendirmek için bir model olan Yetenek Olgunluk Modeli (CMM) olarak düşünülmelidir. ABD Savunma Bakanlığı tarafından finanse edilen ve Carnegie Mellon Üniversitesi'nin yapısal bir birimi olan SEI (Yazılım Mühendisliği Enstitüsü) tarafından oluşturulmuştur. Standardın ilk resmi versiyonu 1993'te yayınlandı, ancak üzerinde çalışmalar çok daha erken başladı - ana hükümleri 1986'da yayınlandı.

    Birkaç faktör CMM'nin başarısını önceden belirlemiştir. Bu standart, başlangıçta yazılım geliştirmenin özelliklerini dikkate alan ilk standartlardan biriydi. Hem anlama hem de kullanım için oldukça basit ve şeffaf olduğu ve “nasıl” yapılacağını değil “ne” yapılacağını düzenlediği ve bu nedenle çeşitli geliştirme metodolojilerine uygun olduğu ve belgelendirme standartları, araçları, ortamı üzerinde herhangi bir kısıtlama getirmediği ortaya çıktı. ve projelerde kullanılan diller. Ve belki de, CMM'nin popülaritesini önceden belirleyen ana faktör, SEI'nin ABD Savunma Bakanlığı ile işbirliğiydi; bu, fiili olarak bu departman tarafından görevlendirilen projeleri uygularken standardın kullanılması anlamına geliyordu.

    CMM modeli (Tablo 1), her biri belirli kilit süreç alanlarına (Anahtar Süreç Alanları, KPA) karşılık gelen beş olgunluk düzeyi sağlar.

    Tablo 1. CMM modelinin seviyeleri
    Seviye No. Seviye adı Anahtar süreç alanları
    1 İlköğretim Organizasyon bu seviyedeyse, bunun için kilit süreç alanları yoktur.
    2 tekrarlayan Yazılım Konfigürasyon Yönetimi Yazılım Kalite Güvencesi Yüklenici Sözleşmelerinin Yönetimi Proje İlerleme İzleme Yazılımı Proje Planlama Gereksinim Yönetimi
    3 kesin Uzman değerlendirmeleri Proje ekipleri arasındaki etkileşimlerin koordinasyonu Mühendislik yazılım ürünü.Kapsamlı yazılım yönetimi Personel eğitim programı Organizasyonel sürecin tanımı Organizasyonel sürecin kapsamı
    4 Yönetilen Yazılım kalite yönetimi - nicel yöntemlere dayalı süreç kontrolü
    5 optimize edilebilir Süreç değişikliği yönetimi Süreç değişikliği yönetimi Kusur önleme

    Seviyelere bölünme ve her biri için KPA'ların tanımı, standardı geliştirme sürecinin sürekli iyileştirilmesini sağlayabilecek bir kılavuz olarak kullanarak CMM'nin tutarlı bir şekilde uygulanmasına izin verir.

    CMM standardının çok başarılı olduğu kanıtlandı ve ardından temelinde bir dizi standart oluşturuldu (Tablo 2). Ayrıca, oldukça çok sayıda standart ailesindeki konumunu daha doğru bir şekilde yansıtan SW-CMM (Yazılım için Yetenek Olgunluk Modeli) adını aldı.

    Tablo 2. CMM standartlarının geliştirilmesi
    Standardın adı Açıklama
    Sistem Mühendisliği CMM (SE-CMM) Sistem mühendisliği konularına odaklanmış - ürün geliştirme (gereksinim analizi, ürün sistemleri tasarımı ve entegrasyonu) ve bunların üretimi (üretim hattı planlaması ve işletimi)
    Güvenilir CMM (T-CMM) Hassas ve kapalı hizmet vermek için tasarlanmıştır yazılım sistemleri yüksek kaliteli yazılım garantisi gerektiren
    Sistem Güvenliği Mühendisliği CMM (SSE-CMM) Yazılım mühendisliğinin güvenlik yönlerine odaklanır, ekip üyelerinin güvenliği de dahil olmak üzere güvenli bir geliştirme süreci sağlar
    İnsanlar CMM (P-CMM) Yazılım organizasyonlarında personel geliştirme konularını dikkate alır
    Yazılım Edinimi CMM (SA-CMM) Harici kuruluşlardan yazılım ürünleri satın alma konularını kapsar
    Entegre Ürün Geliştirme CMM (IPD-CMM) Yaşam döngüsünün tüm aşamalarında ve şirketin her departmanında geliştirme çabalarının entegrasyonu için bir ortam görevi görür.

    Ancak CMM serisi standartların pratikte uygulanması, yazılım geliştirmede koşulsuz başarı sağlamadıklarını göstermiştir. Bu standartlar birbirleriyle iyi koordine edilmedi - CMM'nin çeşitli değişikliklerinin aynı anda uygulanması oldukça zor bir görev olabilir ve bununla karşılaşan kuruluşların uzmanlarını karıştırabilir.

    Ayrıca, CMM ile ilgili önemli bir sorun, tüm süreçleri "hizalama" ihtiyacıdır. Bir kuruluş belirli bir seviyeye kadar belgelendirmeye çalışıyorsa, tüm süreçleri için uygun seviyeyi sağlamalıdır. Spesifiklik, metodoloji veya tasarım özellikleri belirli süreçlerin yürütülmesini desteklemese bile, sertifikasyon bunu gerektirir.

    Bir diğer sorun da CMM standartlarının günümüz yazılım endüstrisinde almış olduğu konumdan kaynaklanmaktadır. CMM'ye göre üst düzeyde olan bir kuruluşun, alt düzeyde belgelendirilenlere göre yazılım ürünlerinde daha yüksek performans göstermesi gerektiğinden, standart, yazılım geliştirme veya dış kaynak projeleri ihalelerine katılım için bir seçim kriteri olarak kullanılmaya başlandı. Sertifikalı kuruluşlara olan talep, “hızlı ve acısız sertifikalandırma” önerisini doğurdu.

    Bu durum, sertifikasyon sürecinin eksiklikleri ile mümkün olmuştur. Bir bütün olarak organizasyonun tamamı sertifikaya tabi değildir, sadece belirli bir projeye tabidir. Hiçbir şey, bir kuruluşun yüksek seviyelerin tüm gerekliliklerini dikkate alarak yürütülen bir "vitrin" projesi oluşturmasını engellemez. CMM standardı, uygun sertifika düzeyine sahip olun ve tüm ürünlerin bu düzeyde bir standardı karşıladığını beyan edin.

    Sorunların çoğunu çözmek için CMM, yeni standart SEI - Entegre Yetenek Olgunluk Modeli (CMMI) - Geliştirme süreçlerinin olgunluk düzeyini değerlendirmek için entegre bir model. CMMI standardı, orijinal olarak birleştirilecek şekilde oluşturulmuştur. mevcut seçenekler CMM ve yüksek teknoloji şirketlerinin çeşitli faaliyet alanlarındaki pratik uygulamasındaki çelişkileri hariç tutun.

    Kuruluşun süreçlerini "hizalama" ihtiyacını ortadan kaldırmak ve bunun tersini değil, iş ihtiyaçlarına daha uygun hale getirmek için CMMI standardının iki sunum biçimi vardır - klasik, çok düzeyli, CMM'ye karşılık gelen ve yeni, sürekli. Sürekli sunum, Olgunluk Düzeylerini değil, bireysel Süreç Alanları (PA) için değerlendirilen Yetenek Düzeylerini dikkate alır. Tablo Şekil 3, CMM standardının olgunluk seviyeleri ile CMMI katmanlı sunumun olgunluk seviyeleri ve CMMI sürekli sunum kabiliyeti seviyeleri arasındaki yazışmayı gösterir.

    SEI, CMM'den uzaklaşıyor ve buna karşılık olarak CMMI'yi aktif olarak teşvik ediyor, maliyetleri azaltmak ve küçük kuruluşlar için daha çekici hale getirmek için yeni sınıflar getirerek sertifikasyon süreci üzerindeki kontrolü sıkılaştırma sözü veriyor; ISO standartlarıyla uyumluluğun sağlanması. Ancak gerçek şu ki: içinde modern koşullar belirli bir düzeyde CMM / CMMI sertifikasının varlığı, birkaç yıl önce olduğu kadar önemli bir faktör değildir ve bir devlet emriyle yürütülen projeler dışında, ek soru sorulmadan kabul edilir.

    Organizasyonel süreçlerin yönetiminde 5 evrimsel aşama. Yetenek Olgunluk Modelinin Açıklaması. CMM

    CM-CEI Yetenek Olgunluk Modeli, bir organizasyondaki süreçlerin yönetildiği 5 evrimsel aşamayı (seviyeyi) tanımlayan bir organizasyon modelidir.

    Orijinal olarak yazılım geliştirme için tasarlanan Yetenek Olgunluk Modelinin arkasındaki mantık, bir organizasyonun yazılım uygulamalarını kabul edip destekleyebilmesi gerektiğidir. Model ayrıca, organizasyonun bir sonraki seviyeye büyümesine yardımcı olacak somut adımlar ve girişimler önermektedir.

    Yetenek Olgunluk Modelinin 5 Aşaması

    Başlangıç ​​(süreçler ad hoc, kaotik veya aslında çok azı tanımlanmıştır) Tekrarlanabilir (temel süreçler oluşturulur ve bu süreçlere bağlı kalmak için bir disiplin vardır) Tanımlı (tüm süreçler tanımlanır, belgelenir, birleştirilir ve entegre edilir) Yönetilen (süreçler, ayrıntılı süreç verileri ve bunların kalitesi toplanarak ölçülür) Optimizasyon ( Sürekli gelişim nicel geri bildirim kullanan ve yeni fikirleri ve teknolojileri test eden süreç)

    Yazılım geliştirme modeli

    CMM, yazılım süreci olgunluğu kavramının altında yatan ilke ve uygulamaları tanımlar. Yazılım geliştirme ve pazarlama şirketlerinin yazılım süreçlerinin karmaşıklığını evrimsel bir şekilde geliştirmelerine yardımcı olmak için tasarlanmıştır. Özel, kaotik süreçlerden olgun, disiplinli yazılım süreçlerine. Odak noktası, disiplinli yazılım süreçlerinin oluşturabileceği kilit süreç alanlarını ve en iyi uygulamaları belirlemektir. CMM olgunluk kavramı, aşağıdakileri içeren bir bağlam oluşturur:

      Uygulamalar tekrar edilebilir. Bir işlemi tekrarlamazsanız, iyileştirmemelisiniz. Bir organizasyonu uygulamaya ve tutarlı bir şekilde uygulamaya zorlayan kurallar, prosedürler ve uygulamalar vardır. En İyi Organizasyon Yöntemleri üretim işleri gruplar arasında hızla dağıtılabilir. Uygulamalar, projeler arasında değiş tokuşa izin verecek şekilde tanımlanır, böylece kuruluş için bir miktar standardizasyon sağlanır. Bu yöntemlerin performansındaki sapmalar en aza indirilir. Hedefler için nicel hedefler belirlenir; ve ölçümler, değerlendirmenin temelini oluşturmak üzere oluşturulur, üretilir ve sürdürülür. Yetenekleri (optimizasyon) geliştirmek için uygulamalar sürekli olarak geliştirilmektedir.

    Yetenek olgunluk modeli sadece yazılım geliştirme için değil, aynı zamanda genel olarak organizasyonların evrimsel seviyelerini ve organizasyonun uyguladığı veya ulaşmak istediği yönetim seviyesini tanımlamak için de faydalıdır.

    İşlevsellik Geliştirme Modeli yapısı

      Olgunluk seviyeleri, sürekli iyileştirme sağlamak için gereken disiplin tutarlılığını sağlayan katmanlı bir kavramdır. Burada, kuruluşun yeni bir uygulamanın, teknolojinin veya aracın sonuçlarını değerlendirme yeteneğini geliştirdiğini belirtmek önemlidir. Dolayısıyla, bu yeniliklerin kabul edilmesi değil, bu yenilikçi çabaların mevcut uygulamaları nasıl etkilediği meselesidir. Projeleri, grupları ve organizasyonları, onlara bilinçli seçimler yapmaları için temel vererek destekler. Anahtar süreç alanları - Anahtar süreç alanı (KPA), birlikte gerçekleştirildiğinde bir dizi önemli hedefe ulaşan bir grup ilgili faaliyeti tanımlar. Hedefler - Bir kilit süreç alanının amaçları, o anahtar süreç alanı için var olması gereken hükümleri tanımlar. Düzenlemelerin etkin ve güvenilir bir şekilde uygulanması gerekmektedir. Hedeflere ne ölçüde ulaşıldığı, organizasyonun bu mükemmellik düzeyinde ne tür bir fırsat hazırladığını gösterir. Hedefler, her bir kilit süreç alanının faaliyet alanlarını, sınırlarını ve amacını ana hatlarıyla belirtir. Ortak özellikler - Ortak özellikler, kilit süreç alanlarını uygulayan ve kurumsallaştıran uygulamaları içerir. Bu 5 tür Genel özellikleri Bunlar: Uyum Taahhüdü, Uyum Yeteneği, Gerçekleştirilen Girişimler, Ölçüm ve Analiz ve Uygulama Kontrolü. Temel Uygulamalar - Kilit Uygulamalar, kilit süreç alanlarının uygulanmasına ve kurumsallaşmasına en etkin şekilde katkıda bulunan altyapı ve uygulama unsurlarını tanımlar.

    Süreci tanımlama kriterleri

    Bir süreci tanımlama kriterleri, insanların bunları pratikte kullanabilmeleri için bir yazılım sürecinin tanımına dahil edilmesi gereken bir süreç unsurları topluluğudur. Kriterleri belirlemek için şu soruyu sormanız gerekir: "Belgeleme için program süreci hakkında hangi bilgilere ihtiyaç var?"

    Yazılım ve sistem entegrasyonunun geliştirilmesi, teslimi, uygulanması ve bakımı alanında çalışan kuruluşlar, kalite ve düşük maliyet, üretimin üretilebilirliğinin rekabet edebilirliklerinin merkezinde olduğunu giderek daha fazla hissetmektedirler.

    Bu tür kuruluşların liderleri, şirketlerinin faaliyetlerinin teknolojisini iyileştirmek ve geliştirmek için her zaman bir strateji formüle edemezler; işgücü piyasasında gerekli niteliklere sahip uzmanların yeterli olmadığı açıktır. Aynı zamanda, yazılım geliştirme ve çalıştırmanın teknolojik süreçlerini iyileştirme alanında, uzun yıllara dayanan uluslararası deneyim yeterince genelleştirilmemiş ve resmileştirilmemiştir. Amerikan Yazılım Mühendisliği Enstitüsü (SEI) ancak 1990'ların başında, teknolojik olgunluk düzeylerini ve ayırt edici özelliklerini tanımlayarak kuruluşların Yetenek Olgunluk Modelini (CMM) oluşturdu. On yıl boyunca, SMM bir dizi kuruluşta test edildi, etkinliği ve güvenilirliği, sipariş veren kuruluşlar, yazılım tedarikçileri, özel yazılım geliştiren ve açık deniz programlaması yapan şirketler tarafından doğrulandı.

    Bugün batıda bir geliştirme şirketi, CMM tarafından sertifikalandırılmamışsa sipariş almakta büyük zorluklar yaşıyor. Müşteriler, yürütücü şirketin üretilebilirlik garantisini talep eder, yüklenicinin düşük kaliteli bir hizmet veremeyeceğini garanti eder.

    Şirketlerin teknolojik olgunluğunun değerlendirilmesi kullanılabilir:

    · Müşteri tarafından en iyi performans gösterenlerin seçiminde (örneğin bir ihalede);

    · Teknolojik süreçlerinin durumunun sistematik olarak değerlendirilmesi ve iyileştirilmesi için yön seçimi için yazılım şirketleri;

    · "Afetin boyutunu" değerlendirmek için sertifika almaya karar veren şirketler, yani. mevcut durumu;

    · Denetçilerin standart bir belgelendirme prosedürü belirlemesi ve gerekli değerlendirmeleri yapması;

    · Şirketleri ve bilgi teknolojisi sağlayıcılarının hizmetlerini ve ilgili hizmetleri yeniden yapılandıran danışmanlık firmaları.

    Kuruluşun teknolojik olgunluğu arttıkça, yazılım oluşturma ve sürdürme süreçleri daha standart ve tutarlı hale gelir. Aynı zamanda, süreçlerin resmileştirilmesi, bunların uygulanmasının beklenen sonuçlarını standartlaştırmayı ve proje uygulama sonuçlarının öngörülebilirliğini sağlamayı mümkün kılar.

    Yazılım süreci olgunluğu kontrol edilebilirlik, kontrol edilebilirlik ve verimlilik derecesidir. Artan teknolojik olgunluk, artan süreç esnekliği potansiyelini gösterir ve yazılım geliştirme ve bakım süreçlerinin kuruluş genelinde etkin ve tutarlı bir şekilde kullanılma derecesini gösterir. Süreçlerin gerçek kullanımı, onları belgelemeden ve kuruluş personelinin dikkatine sunmadan, uygulamalarının sürekli izlenmesi ve iyileştirilmesi olmadan imkansızdır. İyi tasarlanmış süreçler tam olarak tanımlanmıştır. Süreçlerin teknolojik olgunluğunun artması, uygulama sonuçlarının verimliliğinin ve kalitesinin sürekli olarak artabileceği anlamına gelir.


    Teknolojik olgunluğa erişmiş kuruluşlarda yazılım oluşturma ve sürdürme süreçleri bir standart haline gelir, organizasyon yapılarında sabitlenir ve üretim taktiklerini ve stratejisini belirler. Kanun statüsüne girmeleri, gerekli altyapıyı inşa etme ve gerekli koşulları yaratma ihtiyacını beraberinde getirir. şirket kültürü uygun iş uygulamalarını, operasyonları ve prosedürleri destekleyen endüstriler, onları oluşturanlar kuruluştan ayrıldıktan sonra bile.

    CMM modeli, kuruluşun kalite sistemi ile ilgili hükümleri geliştirir ve mükemmelliği için kriterleri oluşturur - prensipte gelişen kuruluş tarafından elde edilebilecek beş teknolojik olgunluk seviyesi. En yüksek - dördüncü ve beşinci seviyeler - aslında, yazılım oluşturma ve bakım süreçlerinin kapsamlı bir şekilde otomatikleştirildiği ve teknolojik olarak desteklendiği toplu geliştirme yöntemlerine hakim olan kuruluşların özellikleridir.

    1990'dan beri SEI, ABD devlet kurumlarının ve yazılım geliştirme kuruluşlarının desteğiyle, yazılım oluşturma ve sürdürme alanındaki en son başarıları dikkate alarak bu modeli sürekli olarak geliştirmekte ve iyileştirmektedir.

    SMM, yazılımın oluşturulması ve bakımı için bir yönetim sisteminin oluşturulmasına ilişkin kuralları ve üretim kültürünün kademeli ve sürekli iyileştirme yöntemlerini tanımlayan metodolojik bir materyaldir. SMM'nin amacı, kalkınma organizasyonları sağlamaktır. gerekli talimatlar teknolojik olgunluk derecesini ve ürünlerin kalitesini en çok etkileyen faktörleri analiz ederek süreçlerin kalitesini iyileştirmek için bir strateji seçimi konusunda. Kuruluş, en kritik operasyonların az bir kısmına odaklanarak ve bunların yürütülmesinin verimliliğini ve kalitesini sistematik olarak artırarak, yazılım oluşturma ve sürdürme kültüründe sürekli ve sürekli bir gelişme sağlayabilir.

    CMM, bir organizasyonun hangi teknolojik olgunluk düzeyinde olduğunu belirleyen temel (veya anahtar) nitelikleri tanımlaması anlamında tanımlayıcı bir modeldir. Metodolojinin ayrıntılı bir açıklamasının, ABD devlet kurumlarıyla yapılan sözleşmeler kapsamında değişen karmaşıklık ve süreye sahip projeleri yürütmek için gereken organizasyon düzeyini belirlemesi anlamında normatif bir modeldir. CMM bir reçete değildir, bir organizasyonun nasıl gelişeceğini belirlemez. CMM, seviyeden seviyeye nasıl geçileceğine dair herhangi bir talimat vermeden, teknolojik olgunluk seviyelerinin her biri için organizasyonun özelliklerini tanımlar. Bir organizasyonun birinci kademeden ikinci kademeye geçmesi birkaç yıl alabilir ve kademeden kademeye geçiş çok az zaman alabilir. Yazılım geliştirme teknolojisini geliştirme süreci, organizasyonun stratejik planlarına, yapısına, kullanılan teknolojilere, genel sosyal kültüre ve yönetim sistemine yansır.

    Gereksinimler, yerine getirilmesi üzerine süreçlerin en temel göstergelerinin stabilizasyonunun sağlandığı her seviyede belirlenir. Her teknolojik olgunluk seviyesinin elde edilmesi, yazılım geliştirme süreçlerinde belirli sayıda bileşenin ortaya çıkmasının bir sonucudur ve bu da üretkenliklerinde ve kalitesinde artışa yol açar. İncirde. 1.7, SMM'nin beş teknolojik olgunluk seviyesini gösterir.

    Pirinç. 1.7. SMM'nin beş teknolojik olgunluk seviyesi

    Ok uçları, seviyeden seviyeye geçerken süreçlerin iyileştirilmesinin özelliklerini tanımlar.

    İkinciden beşinciye kadar olan seviyeler, yazılım oluşturma süreçlerini standartlaştırmayı ve (veya) modernleştirmeyi amaçlayan işlemler ve oluşturma süreçlerini oluşturan işlemler aracılığıyla karakterize edilebilir. Ayrıca, birinci seviye, adeta temel, temeldir. Karşılaştırmalı analizüst seviyeler.

    1. seviyede (başlangıç), yazılım oluşturma ve sürdürmenin ana süreçleri rastgele ve kaotiktir. Projenin başarısı tamamen personelin bireysel çabalarına bağlıdır. Bu düzeyde, bir kural olarak, kuruluş, yazılımı oluşturmak ve sürdürmek için gerekli olan kararlı bir ortama sahip değildir.

    Projenin başarısı, kural olarak, tamamen liderliğin enerji derecesine ve deneyimine bağlıdır ve profesyonel seviye sanatçılar. Enerjik bir lider, proje sürecindeki tüm engelleri aşabilir ve gerçekten uygulanabilir bir yazılım ürününün piyasaya sürülmesini sağlayabilir. Ancak böyle bir lider görevinden ayrıldıktan sonra, bir sonraki projenin başarılı olacağı garantisi ortadan kalkar. Gerekli proje yönetimi seviyesinin yokluğunda, ileri teknoloji ile bile durum kurtarılamaz.

    Birinci düzeydeki süreçler, proje yürütme sürecindeki kompozisyonları, amaçları ve sıralarının mevcut duruma bağlı olarak rastgele değişmesi nedeniyle öngörülemezlikleri ile karakterize edilir. Sonuç olarak, tahsis edilen fonlar gereğinden fazla harcanmakta ve çalışma programları kesintiye uğramaktadır. Hazırlama kabiliyetine sahip ve bilgili profesyoneller organizasyonlarda tüm olgunluk seviyelerinde başarı için ana ön koşuldur, ancak ilk seviyede en azından bazı olumlu sonuçlar elde etmek için tek fırsattır.

    2. düzeyde (tekrarlanabilir süreçlerin düzeyi), proje yönetimi süreçleri proje maliyetlerinin, zaman çizelgesinin ve işlevlerinin sürekli kontrolünü sağlar. Proje disiplini öyledir ki, benzer yazılım ürünleri oluşturmak için projelerin başarısını tahmin etmek mümkündür.

    Bu seviyede, proje çalışmalarının planlanması ve yeni projelerin yönetimi, başarıyla tamamlanmış benzer projelerin deneyimine dayanmaktadır. İkinci seviyenin ana özelliği, başarıyla tamamlanmış projelerin olumlu deneyimlerini kullanmayı mümkün kılan resmileştirilmiş ve belgelenmiş etkin proje yönetimi süreçlerinin varlığıdır. Etkin süreçler, belgelenmiş, fiilen kullanılan, ölçülebilir ve modernizasyona uygun süreçler olarak tanımlanabilir. Personelin kullanımları konusunda eğitilmesi önemlidir.

    HMM'nin ikinciden başlayarak her seviyesi, bir dizi anahtar işlem alanının (KRA) varlığı ile karakterize edilir. CMM modeli bu tür 18 grup içerir, CMMI modelinin en son sürümü 20 grup içerir. Seviye 2 CMM, kuruluşta aşağıdaki süreçlerin varlığı ile karakterize edilir (isimleri CMMI'ye karşılık gelir):

    · İhtiyaç Yönetimi;

    · Konfigürasyon yönetimi;

    · Proje planlaması;

    · Projenin izlenmesi ve kontrolü;

    · Sözleşme Yönetimi;

    · Ölçümler ve analizler;

    · Proses ve ürün kalitesinin sağlanması.

    İkinci seviyedeki süreçler, önceden planlanmaları ve proje sonuçlarının öngörülebilirliğinin sağlanması nedeniyle uygulamalarının sıkı bir şekilde kontrol edilmesi nedeniyle sıralı olarak karakterize edilebilir. Projelerin artması ve karmaşıklığı ile dikkat, uygulamalarının teknik yönlerinden organizasyon ve yönetim yönlerine kaymaktadır. Süreçlerin yürütülmesi, personelin daha verimli ve koordineli çalışmasını gerektirir ve bu da mesleki becerileri geliştirmek için belgelenmiş en iyi uygulamaların incelenmesini gerektirir.

    Seviye 3'te (standartlaştırılmış süreçler seviyesi), yazılım geliştirme süreçleri belgelenir, standartlaştırılır ve organizasyonun tüm departmanları için zorunlu olan tek bir teknolojik sistemi temsil eder. Tüm projeler, yazılım oluşturmak ve sürdürmek için kanıtlanmış, onaylanmış ve standartlaştırılmış birleşik bir teknoloji kullanır.

    Bu düzeyde, 2. düzey süreçlere aşağıdaki süreçler eklenir:

    · Gereksinim belirtimi;

    · Ürün entegrasyonu;

    · Doğrulama;

    · Belgelendirme;

    · Organizasyonel süreçlerin standardizasyonu;

    · Eğitim;

    · Entegre proje yönetimi;

    · Risklerin yönetimi;

    · Analiz ve karar verme.

    Bu düzeyde süreçlerin kullanılması ve gerekirse ayarlanması için ana kriter, proje uygulamasının verimliliğini artırmak için yönetim bağlantısına ve teknik uzmanlara yardımcı olmaktır. Bu düzeyde, süreçleri oluşturan operasyonların bileşiminden sorumlu kuruluşta özel bir grup oluşturulur - yazılım mühendisliği süreç grubu (SEPG).

    Her proje için tek bir teknoloji temelinde, özellikleri dikkate alınarak kendi süreçleri geliştirilebilir. CMM'deki bu tür süreçlere "proje odaklı yazılım geliştirme süreçleri" (projenin tanımlı yazılım süreci) denir.

    Her sürecin tanımı, uygulama koşullarını, girdi verilerini, uygulama standartlarını ve prosedürlerini, doğrulama mekanizmalarını (örneğin, uzman değerlendirmeleri), çıkış ve sonlandırma koşulları. Sürecin açıklaması, aynı zamanda, onu gerçekleştirmek için gerekli araçlar hakkında bilgi ve uygulanmasından sorumlu rolün bir göstergesini de içerir.

    4. seviyenin (kontrol edilen proseslerin seviyesi) temel amacı proseslerin izlenmesidir. Yönetim, süreçlerin belirlenen kalitede yürütülmesini sağlamalıdır. Müdahale gerektiren ölçülebilir sonuçlarda kaçınılmaz kayıplar ve geçici zirveler olabilir, ancak genel sistem kararlı olmalıdır.

    Seviye 4, aşağıdaki süreçleri ekler:

    · Performans ve verimlilik yönetimi;

    · Nicel proje yönetimi.

    Bu seviyede, uygulamada, hem oluşturma süreçlerinin hem de oluşturulan yazılım ürününün kalitesinin ayrıntılı bir değerlendirmesi uygulanır. Bu durumda nicel değerlendirme kriterleri uygulanır.

    Kuruluş genelinde yazılım geliştirme üretkenliği ve kalitesinin nicel kontrolü için birleşik bir program geliştirilmektedir. Süreçlerin analizini kolaylaştırmak için, organizasyonda yürütülen tüm projeler için birleşik bir yazılım geliştirme ve bakım süreçleri veritabanı oluşturulur. Süreçlerin üretkenliğini ve uygulama kalitesini nicel olarak değerlendirmek için evrensel yöntemler geliştirilmektedir. Bu, yazılım geliştirme ve bakım süreçlerinin nicel analizine ve değerlendirilmesine izin verir.

    Dördüncü seviyedeki işlemlerin yürütülmesinin sonuçları, ölçülebilir oldukları ve belirtilen nicel sınırlar içinde değiştiği için tahmin edilebilir hale gelir. Bu seviyede, proseslerin ve nihai ürünlerin belirtilen kalitesini önceden planlamak mümkün hale gelir.

    Düzey 5'in (optimize edilmiş süreçlerin düzeyi) temel amacı, yazılım oluşturma ve sürdürme süreçlerini sürekli olarak iyileştirmek ve modernize etmektir. Yazılım geliştirme teknolojisinin planlı modernizasyonu amacıyla kuruluş, özel birim, ana sorumlulukları süreçlerin yürütülmesi hakkında veri toplamak, analiz etmek, mevcut süreçleri modernize etmek ve yeni süreçler oluşturmak, bunları pilot projelerde kontrol etmek ve onlara kurumsal standartlar statüsü kazandırmaktır.

    Seviye 5, aşağıdaki süreçleri ekler:

    · Teknolojik ve organizasyonel yeniliklerin tanıtılması;

    · Sebep-sonuç analizi ve problem çözümü. Yazılım oluşturma ve sürdürme süreçleri aşağıdakilerle karakterize edilir:

    Kuruluş bunları modernize etmek için sürekli çaba sarf ettiğinden, sürekli olarak iyileştirildi. Bu iyileştirme, hem kullanılan süreçlerin ek yeteneklerinin tanımlanmasına hem de yeni optimal süreçlerin yaratılmasına ve yeni teknolojilerin kullanımına kadar uzanır.

    En büyük faydayı sağlayabilecek yenilikler standardize edilir ve organizasyon genelinde teknoloji sistemine uyarlanır. Projenin uygulanmasına dahil olan personel, kusurları analiz eder ve bunların oluşum nedenlerini belirler. Hataya neden olan durumların tekrarlanmaması için yazılım geliştirme süreçleri değerlendirilir ve sonraki projelerde değerlendirme sonuçları dikkate alınır.

    Sonraki her seviye ayrıca yazılım oluşturma ve sürdürme süreçlerinin daha eksiksiz bir görünürlüğünü sağlar.

    İlk seviyede, süreçler şekilsizdir (“kara kutular”) ve görünürlükleri çok sınırlıdır. En başından beri, operasyonların bileşimi ve amacı pratik olarak tanımlanmamıştır, bu da projenin durumunu ve ilerlemesini belirlemede önemli zorluklar yaratır. Süreçlerin yürütülmesi için gereksinimler kontrolsüz bir şekilde belirlenir. Yazılım geliştirme bazen yöneticilerin (özellikle kendileri programcı olmayanların) gözünde kara büyü gibi görünür.

    İkinci seviyede, proje yönetim süreçlerinin temeli belirlendiğinden, kullanıcı gereksinimlerinin karşılanması ve yazılımların oluşturulması kontrol edilir. Yazılım geliştirme süreci, bir "kutu"dan diğerine - sabit aşamalara geçiş noktalarında kontrol edilebilen bir "kara kutular" dizisi olarak görülebilir. Yönetici “kutunun içinde” ne yapıldığını bilmese bile, sürecin sonucunun ne olması gerektiği kesin olarak belirlenir ve başlangıcı ve bitişi için kilometre taşları tanımlanır. Bu nedenle yönetim, "kara kutuların" etkileşim noktalarındaki sorunları tanıyabilir ve bunlara zamanında yanıt verebilir.

    Üçüncü düzeyde, "kara kutuların" iç yapısı tanımlanır; süreçleri oluşturan görevler. İç yapı, bir kuruluştaki standart süreçlerin belirli projelere uygulanma şeklidir. Yönetim ekibi ve icracılar, proje içindeki rollerini ve sorumluluklarını gerekli ayrıntı derecesine kadar bilirler. Yönetim, proje süresince ortaya çıkabilecek risklere karşı önceden hazırlıklıdır. Standartlaştırılmış ve belgelenmiş süreçler şeffaf hale geldiğinden, projeye doğrudan dahil olmayan çalışanlar, projenin mevcut durumu hakkında zamanında doğru bilgi alabilirler.

    Dördüncü seviyede, süreçlerin yürütülmesi, belirlemeyi mümkün kılan araçlara sıkı sıkıya bağlıdır. nicel özellikler karmaşıklıkları ve uygulama kalitesi. Nicel ölçümlerin nesnel bir temeline sahip olan yöneticiler, projenin aşamalarını ve aşamalarını doğru bir şekilde planlama, projenin ilerlemesini tahmin etme ve ortaya çıkan sorunlara zamanında ve yeterli şekilde yanıt verme fırsatına sahip olurlar. Proje süresince belirlenen termin, maliyet ve kaliteden olası sapmaların azalması ile sonuçları tahmin etme yetenekleri sürekli artmaktadır.

    Beşinci düzeyde, ürünlerin kalitesini iyileştirmek ve yaratım verimliliğini artırmak için, yazılım oluşturmak için yeni geliştirilmiş yöntemler ve teknolojiler oluşturmak için sürekli ve sistematik olarak çalışmalar yapılır. Aynı zamanda, yalnızca halihazırda kullanımda olanlara değil, aynı zamanda yeni, daha verimli süreçlere ve teknolojilere de dikkat çekilir. Liderler, yazılım geliştirme ve bakım teknolojisindeki değişikliklerin etkisini ve etkinliğini ölçebilir.

    Yazılım endüstrisinde dördüncü ve beşinci seviyeler nadirdir. Böylece, dünyadaki birkaç yüz şirket üçüncü seviyeye ulaşırken, beşinci seviyede (2002'deki SEI'ye göre) 62 firma ve dördüncü - 72 firma vardı. Tüm şirketlerin olgunluk seviyelerini açıklamadığını unutmayın. Bazıları organizasyonel teknolojilerinin reklamını yapmakla ilgilenmezken, diğerleri sadece müşterinin baskısı altında sertifikalandırma gerçekleştirir.

    SMM'nin en yüksek seviyelerine ulaşmak on veya daha fazla yıl alır. Ancak 3. seviye bile uluslararası arenaya cesurca girmenizi sağlar. SMM'yi kullanmak için bir şirketin benzersiz yeteneklere sahip çalışanları araması gerekmez, yalnızca genel fikri anlaması gerekir. CMM modelinin açıklamasında bu modele uygun olarak geliştirilmesi için yapılması gerekenler detaylı olarak belirtilmiştir. Herhangi bir orta sınıf yönetici, SMM'nin düzenlenmiş eylemlerini takip edebilir.

    CMM 1.1'in en son sürümü esas olarak büyük projelerin uygulanmasında yer alan büyük şirketlere yöneliktir, ancak iki veya üç kişilik gruplar veya bireysel programcılar tarafından küçük projeleri (üç aya kadar) yürütmek için kullanılabilir. Bu gibi durumlarda, yeni siparişler büyük ölçüde önceki projelerin kalitesine göre belirlendiğinden, SMM modeli hayati bir rol oynayabilir. Küçük gruplar 2. seviyeden oldukça memnun kalacaklardır, çünkü küçük bir proje için son teslim tarihinden birkaç hafta sapmak önemli değildir.

    2002'den beri, CMMI'nin özel bir entegrasyon versiyonu resmi olarak dağıtılmıştır. Bu, SEI'den şirketin faaliyetlerinin tüm yönlerini kapsayan yeni bir gelişmedir: geliştirme ve yüklenici seçiminden eğitim, uygulama ve desteğe kadar. Ek olarak, CMMI modeli sistem mühendisliğinden gelen yaklaşımlarla genişletilir. Bu model, CMM 2.0 versiyonunun tasarımı sırasında yapılan gelişmeleri içeriyordu (tamamlanmadı), ana değişiklikler büyük ölçekli Amerikan için en uygun olan dördüncü ve beşinci seviyelerdeki şirketler için süreçleri netleştirmeyi amaçlıyordu. projeler.

    HMM modeli oldukça ağır ve önemlidir, ancak tüm yazılım geliştirme sürecini belirleyen tek temel olarak kullanılmamalıdır. Öncelikle ABD Savunma Bakanlığı için yazılım geliştiren şirketlere yönelikti. Bu sistemler, büyük boyutları ve uzun hizmet ömürlerinin yanı sıra, donanım ve diğer yazılım sistemleri ile arayüzün karmaşıklığı ile karakterize edilir. Oldukça büyük programcı ekipleri, Savunma Bakanlığı tarafından geliştirilen gereksinimlere ve standartlara uyması gereken bu tür sistemlerin oluşturulması üzerinde çalışıyor.

    SMM'nin dezavantajları şunları içerir:

    1. Model, bir yazılım ürünü oluşturma sürecine değil, yalnızca proje yönetimine odaklanır. Model böyle bir şeyi hesaba katmaz. önemli faktörler, belirli yöntemlerin kullanımı olarak, örneğin prototipleme, resmi ve yapısal yöntemler, statik analiz araçları vb.

    2. Model, risklerin ve kararların analizinden yoksundur, bu da sorunların geliştirme süreci üzerinde bir etkisi olmadan önce tespit edilmesine izin vermez.

    3. Yazarlar, evrensel ve tüm kuruluşlar için uygun olduğunu kabul etse de, modelin kapsamı tanımlanmamıştır. Ancak yazarlar, faaliyetlerinde SMM uygulayan veya uygulayamayan kuruluşlar arasında net bir ayrım yapmamaktadır. Küçük şirketler bu modeli fazla bürokratik buluyor. Bu eleştiriye yanıt olarak, küçük kuruluşlar için iş akışı iyileştirme stratejileri geliştirilmiştir.

    ana hedef SMM modelinin yaratılması, ABD Savunma Bakanlığı'nın yazılım satıcılarının yeteneklerini değerlendirme amacıydı. Şu anda, kalkınma organizasyonlarının belirli bir gelişim düzeyine ulaşmak için net bir gereklilik yoktur. Ancak, genel olarak yüksek seviyeye ulaşmış bir kuruluşun yazılım tedariki ihalesini kazanma olasılığının daha yüksek olduğu kabul edilmektedir. HMM'ye alternatif olarak, çoğu organizasyon ve yazılım projesi için uygun olan, teknolojik olgunluk iyileştirme süreçlerinin genelleştirilmiş bir sınıflandırması önerilmektedir. Bir kaç tane var Ortak türler iyileştirme süreçleri.

    1. Gayri resmi süreç. Açıkça tanımlanmış bir iyileştirme modeli yoktur. Ayrı bir geliştirme ekibi tarafından başarıyla kullanılabilir.

    kov. Sürecin kayıt dışılığı, konfigürasyon yönetimi gibi resmi eylemleri dışlamaz, ancak eylemlerin kendisi ve ilişkileri önceden belirlenmemiştir.

    2. Kılavuzlu süreç.İyileştirme sürecini yönlendiren hazırlanmış bir modeli vardır. Model, faaliyetleri, programlarını ve aralarındaki ilişkiyi tanımlar.

    3. Metodik olarak sağlam süreç. Belli tekniklerin yürürlükte olduğu anlaşılmaktadır (örneğin, nesne yönelimli tasarım teknikleri sistematik olarak uygulanmaktadır). Bu tür süreçler için süreç tasarımı ve analiz destek araçları (CASE araçları) faydalı olacaktır.

    4. Doğrudan iyileştirme süreci. Kuruluşun bütçesinde ayrı bir satır bulunan ve yeniliklerin tanıtılması için norm ve prosedürlerin tanımlandığı, açıkça tanımlanmış bir teknolojik süreci iyileştirme hedefi vardır. Bu sürecin bir kısmı iyileştirme sürecini ölçmektir.

    Bu sınıflandırma net ve kapsamlı olarak adlandırılamaz - bazı işlemler aynı anda birkaç türe ait olabilir. Örneğin, sürecin kayıt dışılığı geliştirme ekibinin seçimidir. Aynı ekip, sürecin doğrudan iyileştirilmesi için tüm fırsatlara sahipken belirli bir geliştirme metodolojisi seçebilir. Böyle bir süreç sınıflandırmaya girer gayri resmi, metodik temelli, doğrudan iyileştirme.

    Yukarıdaki sınıflandırmaya duyulan ihtiyaç, yazılım geliştirme teknolojisinde kapsamlı bir iyileştirme için bir temel sağlaması ve bir organizasyonun farklı iyileştirme süreçleri türlerini seçmesini mümkün kılması gerçeğinden kaynaklanmaktadır. İncirde. 1.8 arasındaki ilişkiyi gösterir farklı şekiller geliştirmelerini iyileştirmek için yazılım sistemleri ve süreçleri.

    Pirinç. 1.8. İyileştirme süreçlerinin uygulanabilirliği

    Geliştirilmekte olan ürünün türünü bilmek, yazılım sistemleri ile Şekil 1'de gösterilen iyileştirme süreçleri arasındaki yazışmayı yapacaktır. 1.8 iyileştirme sürecini seçmede faydalıdır. Örneğin, yazılımın bir bilgisayar platformundan diğerine geçişini desteklemek için bir program oluşturmanız gerekir. Böyle bir programın hizmet ömrü oldukça kısadır, bu nedenle gelişimi standartlar gerektirmez ve özel yönetim uzun ömürlü sistemlerin yaratılmasında olduğu gibi iyileştirme süreci.

    Birçok teknolojik süreçlerşu anda CASE destek araçlarına sahipler, böylece çağrılabilirler desteklenen süreçler metodik olarak ses süreçleri analiz ve tasarım araçlarıyla desteklenir. Destek aracının etkinliği uygulanan iyileştirme sürecine bağlıdır. Örneğin, resmi olmayan bir süreçte, tipik destek araçları (prototip oluşturma araçları, derleyiciler, hata ayıklama araçları, kelime işlemciler vb.) kullanılabilir. Gayri resmi süreçlerde sürekli olarak daha özel destek araçlarının kullanılması pek olası değildir.

    CMM benzersiz değildir. Neredeyse her büyük şirket yazılım oluşturmak için kendi teknolojilerini geliştirir, bazen bu teknolojiler genel olarak kullanılabilir ve çok popüler hale gelir. SMM modeli, sahip olduğu özellikler nedeniyle yaygın olarak bilinmektedir. devlet desteği ancak SMM'nin gerçek etkinliği birçok önde gelen uzman tarafından eleştirildi. SMM'nin ana dezavantajlarından biri, sağduyu aksini önerse bile, bu modelin ilkelerinden sapmamak için aşırı katı bir gereklilikle ilişkilidir. Mutlak gerçeğe sahip olma iddiaları şüphe uyandırmaktan başka bir şey değildir, bu nedenle bireysel ve kolektif yaratıcılığa çok daha fazla özgürlük bırakan yaklaşımlar küçük ve orta ölçekli şirketler arasında daha popülerdir. Aşağıda ele alınan SPMN metodolojisi, büyük kuruluşlar için etkili olan SMM gibi katı, "ağır" çözümler ile en esnek teknolojiler arasında bir ara yeri kaplar. kendini tanıtıyor en iyi seçenek bir yandan faaliyetlerini modernize etmek isteyen şirketler için Yönetim aktiviteleri, diğer yandan da girmeyi planlıyorlar. Uluslararası seviye SMM sertifikasının son derece arzu edildiği yerlerde.

    Kuruluşlar, tanımlanmış bir yazılım geliştirme süreci kullanarak, kendi özel ihtiyaçlarına uyarlayabilecekleri bu sürecin tutarlı bir akışını elde ederler. Özelleştirme ve standardizasyon için uyumsuz ihtiyaçlar, standart modüller veya “temel” adımlardan oluşan bir süreç yapısı ve bu adımlar arasındaki ilişkileri tanımlamak ve kurmak için kullanılan kurallar oluşturularak ele alınabilir. Bu durumda uyum, bunların bir süreç modelinde birleştirilmesiyle sağlanır.

    Tipik olarak, yazılım projelerinin kalite yönetimi üç kaynaktan gelen bilgilere dayanır:

    Yazılım Mühendisliği (ACM, IEEE);

    Proje Yönetimi (PMI);

    Kalite (ASQ).

    Carnegie Mallon Üniversitesi'ndeki Yazılım Mühendisliği Enstitüsü (SEI) bu üç kaynağı bir araya getiriyor.

    İşlevsellik olgunluk modeli (KabiliyetOlgunlukmodeli, CMM), yazılım geliştirme sürecinin bir "iskeleti" olarak hizmet eder. Bu model eyleme dayalıdır ve yazılım geliştirme sürecini iyileştirmek için çalışan ve bu sürecin değerlendirmeli analizini yapan bireylerin en iyi sonuçlarını yansıtır. Aşağıda, yazılım projelerinin kalite yönetiminin CMM SEI modeline nasıl karşılık geldiğine değineceğiz. HMM, yazılım geliştirme topluluklarında iyi bilindiğinden, onu tanımlamaya çok az ihtiyaç vardır. Geliştirme sürecinde yaşam döngüsünü kullanma ihtiyacını göstermek için yalnızca kısa bir açıklamasını sağlayacağız. Aşağıda, HMM modelinin işlevsel yeteneklerinin gelişim düzeylerinin kısa bir genelleştirilmiş açıklaması yer almaktadır.

    HMM, geliştirme aşamalarının, geliştirme sürecinin sürekli iyileştirilmesinin gerçekleştirildiği beş işlevsellik geliştirme düzeyine karşılık geldiği bir diyagramdır. İşlevsellik geliştirme düzeyinden bahsetmişken, genellikle eksiksiz bir yazılım geliştirme süreci elde etmeyi amaçlayan kesin olarak tanımlanmış bir geliştirme aşaması anlamına gelir. HMM'yi beş seviyeye ayırırken, süreç işlevselliği geliştirme çalışmasını tamamlamak için gereken iyileştirme eylemlerine odaklanılır. Bu beş seviye, onlara aşağıdaki özellikler atanarak özetlenebilir.

    Orijinal. Yazılım geliştirme süreci, özel, uyarlanmış bir süreç ve bazen de kaotik olarak nitelendirilebilir. Yalnızca az sayıda süreç tanımlanabilir ve başarı, bireysel çabaya ve alınan kararlı eyleme bağlıdır.

    tekrarlayan. Maliyetleri, çizelgeyi ve işlevselliği izlemek için temel proje yönetimi süreçleri oluşturulur. Burada, benzer projelerin uygulanmasında daha önce elde edilen başarıları tekrarlamak için tasarlanan sürecin gerekli sırası gözlenir.

    kesin. Tüm projeler, kuruluşun standart yazılım geliştirme sürecinin test edilmiş, özelleştirilmiş bir sürümünü kullanır.

    Yönetilen. Yazılım geliştirme sürecinin ayrıntılı göstergeleri ve ürün kalite özellikleri toplanır. Yazılım geliştirme sürecinin yönetimi nicel düzeyde gerçekleştirilir.

    Optimizasyon seviyesi. Geliştirme sürecinin sürekli iyileştirilmesi, nicel geri bildirim yoluyla sağlanır.

    Bu bağlantı, yenilikçi fikirler ve teknolojiler temelinde olduğu kadar, sürecin kendisinin uygulanmasıyla da sağlanır. Her olgunluk seviyesi, yazılım geliştirme sürecini iyileştirmek için hala yapılması gerekenleri gösteren birkaç kilit süreç alanına bölünmüştür. Her biri anahtar süreç alanı (Anahtarişlemalan,KPA) bu süreci optimize etmek için gereken birbiriyle ilişkili bir dizi eylemi tanımlar.

    2. seviyedeki KPA alanları, temel proje yönetimi araçlarının oluşturulmasıyla ilişkili bir yazılım projesinin yürütülmesi sırasında ortaya çıkan sorunlarla ilgilidir. Tartışmanın bu noktasında, yinelemeli bir sürecin (seviye 2) bir organizasyondaki yapılandırmayı ve yönetimi optimize edebileceğini bilmemiz gerekir. Böyle bir tanımla ortak bir dil oluşturulmakta ve özellikle bu alanda yeterli deneyime sahip olmayan geliştiriciler sürece dahil edildiğinde geçiş dönemleri kolaylaştırılmaktadır.

    Ancak, tekrar eden bir sürecin varlığı (seviye 2) kesinlikle iyi tasarlanmış bir sürece yol açmaz. Genel olarak süreç iyileştirme, bir kuruluş Seviye 3'e ulaştığında gerçekleşir. CPA'nın iki alanı, süreç organizasyonu tanımı ve entegre program yönetimi konu alanıyla ilgilidir. yaşam döngüsü.

    Tanımın amacı örgütsel yapı 3. seviyedeki süreç alanı KPA, bir dizi projenin yürütülmesinde sürecin verimliliğini artıran, yazılım geliştirme sürecinin kullanımı kolay bir dizi yararlı özelliğini geliştirmek ve sürdürmektir. Bir süreç tanımı, kuruluşa özgü bir standart geliştirme sürecinin ve ilgili süreç değeri özelliklerinin geliştirilmesini ve sürdürülmesini içerir. Sürecin organizasyon yapısını belirlemenin amacı, belirli bir organizasyon için standart bir yazılım geliştirme süreci geliştirmek ve sürdürmektir.

    Bir organizasyon yapısı oluşturma sürecini şekillendiren faaliyetler, tanımlayıcı özelliklerin belgelenmesi ve sürdürülmesini içerir. yazılım geliştirmenin yaşam döngüleri. CRA alanında 3. seviyede entegre yazılım yönetiminin amacı, yazılım mühendisliği ve yönetim faaliyetlerini, belirli bir organizasyondaki standart yazılım geliştirme sürecinin uyarlanmasından ve ilgili değerli "Yapısı düzeyinde bir süreç tanımlama" bölümünde açıklanan süreç özellikleri.

    CMM, yazılım geliştirme topluluğu tarafından desteklenen geniş bir tabandan geliştirilen bir grup yazılım süreç modelini ifade eder. Bir modelle uğraştığımız için, gerçek mühendislik sürecinin bir basitleştirmesi var. Bir normu temsil eden CMM modeli, bir veya başka bir olgunluk derecesi kategorisine giren bir organizasyonun yeteneklerini tanımlar.

    Bu modeli süreçleri ölçmek ve iyileştirmek için bir mekanizma olarak kullanan kuruluşlar, iş hedefleri açısından süreç bilgisi alanlarının kabul edilebilir bir yorumunu kullanmalıdır. Bir süreç değerlendirme ve ölçme aracı olarak kullanıldığında, bu model başarılı süreç iyileştirme için bir yol haritası haline gelir. Genel olarak konuşursak, CMM, kanıtlanmış güvence ilkelerine dayalı olarak iyi ifade edilmiş mühendislik ve yönetim kavramlarının bir koleksiyonu olarak görülebilir. Yazılım geliştirme sürecinde bilginin doğru bir şekilde değerlendirilmesi ve korunması gerektiğinde kalite güvencesi ilkelerine büyük önem verilmelidir. CMM modeli olumsuzluk tüm durumlar için reçeteler topluluğudur. Kuruluşun süreç özniteliklerini nasıl ayarlaması gerektiğini belirtmez. Ayrıca, uygulanması anında başarıyı garanti etmez. İyileştirmeleri uygulama süreci, kuruluş genelinde zaman ve sürekli çaba gerektirir. Aynı zamanda, üst yönetim ve tahsis edilen fonlar özel bir önem taşımaktadır. CMM modeli, "her duruma uyan tek bir boyut" olduğunda, evrensel bir metodoloji olarak pek sınıflandırılamaz. Bu modeli kullanmanın ilk adımı, belirli organizasyonunuz ve proje grubunuz için olgunluk düzeyi uygulamaları özelleştirmektir. SEI, kurumsal personel, yazılım edinimi, sistem mühendisliği, entegre yazılım ürünü geliştirme ve kişisel yazılım için geçerli olan başka yetenek olgunluk modelleri geliştirmiştir.

    Yazılım, diğer herhangi bir sermaye gibi, somutlaştırılmış bilgi biçiminde temsil edilebildiğinden ve ayrıca bilginin başlangıçta sistemsiz, belirsiz ve genel olarak eksik olması nedeniyle, herhangi bir program bir süreç olarak temsil edilebilir. sosyal öğrenme... Bu süreç, gerekli bilginin bitmiş bir yazılım ürünü şeklinde somutlaştırıldığı bir diyalog şeklinde gerçekleştirilir. Aynı zamanda kullanıcılar ve geliştiriciler arasındaki iletişim gerçekleştirilir, kullanıcılar ile gerekli araçlar (teknoloji) arasındaki etkileşim gerçekleşir. Süreç, iletişimin gerçekleştiği ortamı oluşturan araçlarla yinelemelidir. Her yeni diyalog turu, ilgili uzmanlardan giderek daha fazla yararlı bilgi edinilmesine katkıda bulunur.

    HMM modelinin ana kullanımlarından biri, belirli bir olgunluk derecesine ulaşmış bir sürecin ne anlama geldiğini tanımlamaktır. Yazılıma uygulandığında, olgun bir sürecin aşağıdaki özelliklere sahip olduğunu söyleyebiliriz:

    Tanımlı - "vakayı tamamlamak için gereken yöntemi" belirtir;

    Belgelenmiş - gelecekte bilinebilecek ve kullanılabilecek şekilde tasarlanmış;

    Öğrenilmiş - belgeye dayalı öğrenme;

    Pratik - pratikte uygulanabilir ve arka brülöre konmaz;

    Bakımlı - mevcut, revize edilmiş ve iyileştirilmiş;

    Kontrollü - değişiklikler "ortak işteki katılımcılar" tarafından onaylandı;

    Doğrulandı - işlem doğru çalışıyor;

    Kontrol edildi - tam olarak ihtiyaç duyulan işlem gerçekleştiriliyor;

    Ölçülen - Tahmini performans, sürecin izlenmesi ve iyileştirilmesi için bir temel olarak kullanılır;

    İyileştirme yeteneği - esneklik ve değişme yeteneği.

    Yazılım ürünlerinin mühendisliği, seviye 3, yani anahtar süreçler alanına aittir. "belirli". 1968 yılına kadar "yazılım mühendisliği" terimi hiç kullanılmadı. Yazılım Mühendisliği bilgisayar programlarının tasarımı ve geliştirilmesi için bilimsel bilginin pratik bir uygulamasıdır. Bu işleme de denir yazılım geliştirme veya programların üretimi.

    Yaygın yazılımların ilk ortaya çıkışı 1890 yılına dayanmaktadır. Bu süre zarfında, Herman Cholerit (1860-1929), MIT, Cambridge, MA tarafından Punch Kartları Amerikan Sayım Merkezlerinde ortaya çıktı.

    Aynı zamanda, "bilgisayarların" hatası nedeniyle ilk maliyet aşımları meydana geldi. ABD Sayım Merkezlerinin sonuçları başlangıçta mekanik yardımlarla tablolaştırıldı; Herman Hollerith'in mekanik tabloları. Aynı zamanda delikli kart üretimi de gelişmeye başladı. Sayım merkezlerinden gelen verilerin tablolaştırılması için harcanan fonlar, geçmişte yapılanlardan %98 daha fazlaydı. Bunun nedeni kısmen, tablolama verileri için kullanılan şablonun çok ayrıntılı olarak geliştirilmiş olması ve tablolaştırılmış veri miktarının gereken minimum miktarı aşmasıdır. Her ne kadar tablolama sürecinin kendisi önemli ölçüde hızlandırılmış olsa da. Aynı zamanda, okuması elektrikle yapılan delikli kartlar ortaya çıktı.

    HMM modeline dönersek, 2. seviyede, yazılım geliştirme sürecinin belirli kontrol noktaları (aşamalar) ile bir dizi "kara kutu" olarak temsil edilebileceğini not ediyoruz. Şekilde gösterildiği gibi. 2.1, gereksinimler sürece dahil edilir ve bir dizi "kara kutu" içine sorunsuz bir şekilde "akar".

    Pirinç. 2.1. 2. seviye süreç

    Her kutu için hesaplama sonuçları oluşturulur ve yazılım geliştirme sürecini izlemek için aşamalar ve kontrol noktaları uygulanır. Bunu, politikaların, standartların ve prosedürlerin uygulanması aşaması takip eder. Bu deneyim, bu projede kullanılan temel metrik sistem kullanılarak ölçülmektedir. Kontrol, proje yönetimi sürecinde yer alan resmi uygulamaların uygulanması yoluyla gerçekleştirilir. Maliyetler, grafikler ve bir dizi işlevsel özellik de izlenir. Sürecin ana konuları yazılım gereksinimleri ve iş ürünleridir ve bunların bütünlüğü bir konfigürasyon yönetim sistemi kullanılarak izlenir. Projeler, müşteri desteği ile yakın ilişkiler ile karakterize edilir. Ayrıca yazılım süreçlerini uygulama becerisini de geliştirir.

    3. seviyede, yani. "tanımlanmış", kuruluşta yazılımın geliştirilmesi ve bakımı için kullanılan standart süreç, Şek. 2.2.

    Pirinç. 2.2. Seviye 3 süreci

    Projeler çerçevesinde organizasyonun standart yazılım süreçleri, bunları somutlaştıracak şekilde ayarlanmaktadır. Yönetim ve yazılım mühendisliği süreçleri de entegre edilmiştir. Standart bir süreci yürütme fırsatları standarttır ve geliştirme ekibi, içinde gerçekleştirilen faaliyetlerden sorumludur. yazılım projesi... Aşağıdakiler, üçüncü olgunluk düzeyi için CRA alanlarıdır:

    1) organizasyonel sürecin kapsamı;

    2) organizasyon sürecini tanımlamak;

    3) yazılım ürünlerinin mühendisliği;

    4) entegre yazılım yönetimi;

    5) gruplar arası etkileşim;

    6) uzman değerlendirmeleri;

    7) müfredat.

    3. seviyede, yazılım geliştirme süreci iyi tanımlanmış bir sürece dayanmaktadır. Sürecin uygulanması sırasında rol ve sorumlulukların farkındalığı gereklidir. Bir yazılım ürününün üretim süreci, yazılım sürecinin yürütülmesi sırasında görüntülenir.

    Seviye 4 (Şekil 2.3), yani. "Kontrollü", CRA'nın iki alanını içerir: nicel süreç yönetimi ve yazılım kalite yönetimi.

    Pirinç. 2.3. 4. seviye süreç

    Genişletilmiş metrik sistemin kullanımı sayesinde, yazılım geliştirme sürecinin ayrıntılı değerlendirmelerinin sonuçları ve yazılım ürününün kalite güvencesi toplanır. Yazılım süreçlerinin ve ürünlerinin nicel bir değerlendirmesi ve kontrolü gerçekleştirilir. Yönetim süreci, belirli sınırlar içinde kararlar almak ve performansı ölçmek için formüle edilmiş objektif kriterlere dayanmaktadır.

    5. seviyede ("optimizasyon"), CPA alanları teknoloji değişikliği yönetimi, süreç değişikliği yönetimi ve kusur önleme aşamalarına odaklanır. Sürekli süreç iyileştirme sayesinde, nicel Geri bildirim Yazılım geliştirme süreci ile ilgili olarak. Bu seviyede kuruluş, Şek. 3'te şematik olarak gösterilen yazılım ürününün kalitesini artıran yeni fikirleri ve teknolojileri test edebilir. 2.4.

    Pirinç. 2.4. Seviye 5 süreci

    Mevcut bir süreçte kontrollü değişiklikler yoluyla, sürekli süreç iyileştirmeyi sağlamak için organizasyonel bir yaklaşım getirilir. Bu değişiklikleri organize etmek aşağıdaki nedenlerden dolayı önemlidir:

    1) süreç, organizasyonun kültürel gelenekleri ile tutarlı olmalıdır;

    2) yönetim, kültür seviyesinin iyileştirilmesine katkıda bulunmakla yükümlüdür;

    3) kültür, rol modellerin ve ödüllerin tanıtılmasını teşvik etmelidir.

    Özetlemek gerekirse, SMM modelinin başarılı süreç iyileştirmeyi garanti eden bir tür "yol haritası" olduğu belirtilebilir. Yorumlanması ve uygulanması, kuruluşun iş hedefleri bağlamındadır. Şu anda, yazılım geliştirmeyle uğraşan kuruluşlarda en yaygın yöntem CMM modelidir (ve bu eğilim birçok ülke ve çok çeşitli uygulama alanları için tipiktir). Bu model normatiftir, kuralcı değildir ve ayrıca geniş bir istikrar marjı ile karakterize edilir. Geliştirme ve desteği, profesyonellerden oluşan bir toplulukta birleşmiş birçok geliştirici tarafından gerçekleştirilir.