» »

Modeli za ocenjevanje zrelosti organizacij razvijalcev programskih sistemov. Standardi ISO, SW-CMM

Novembra 1986 je American Software Engineering Institute (SEI) skupaj z Mitre Corporation začel razvijati raziskavo zrelosti razvojnega procesa. programsko opremo, ki je bil namenjen izboljšanju njihovih notranjih procesov.

Razvoj tega pregleda je spodbudila zahteva zvezne vlade ZDA po metodi za ocenjevanje podizvajalcev za razvoj programske opreme. Prava težava je bila nezmožnost vodenja velikih projektov. V mnogih podjetjih so bili projekti izvedeni znatno pozno in so presegli proračun. Treba je bilo najti rešitev za ta problem.

Septembra 1987 je SEI izdal kratek pregled procesi razvoja programske opreme z opisom njihove zrelosti, pa tudi vprašalnik, namenjen ugotavljanju področij v podjetju, na katerih so bile potrebne izboljšave. Vendar pa je večina podjetij ta vprašalnik obravnavala kot končni model, zaradi česar je bil vprašalnik po 4 letih preoblikovan v pravi model, Capability Maturity Model for Software (CMM). Prvo različico CMM (verzija 1.0), izdano leta 1991, so leta 1992 revidirali udeleženci delovnega srečanja, ki se ga je udeležilo približno 200 strokovnjakov za programsko opremo in člani skupnosti razvijalcev.

Posledično je izšel standard CMM, različica 1.1, ki se še vedno aktivno uporablja po vsem svetu.

riž. 1. Globalni vpliv uporabe SMM

Razlogi za to zanimanje za SMM so jasni. Kljub temu, da se tako razvijalci programske opreme kot njihovo vodstvo pogosto zelo zavedajo svojih nenehnih težav, se ne morejo strinjati, katere spremembe podjetje sploh potrebuje. Brez izdelave enotne strategije izboljšav vodstvo ne more najti medsebojnega razumevanja z zaposlenimi glede najpomembnejših nalog izboljšav. Da bi dosegli največji rezultat vloženega truda v izboljšanje procesov, je potrebna fazna razvojna strategija, ki bo zrelost razvojnih procesov izboljševala postopoma, na evolucijski način.

Nenehno izboljševanje procesov temelji na postopnem gojenju kulture podjetja in ne na uvajanju revolucionarnih novosti. CMM zagotavlja načrt za to postopno izboljšanje, razdeljeno na 5 stopenj zrelosti procesa. Teh 5 stopenj je lestvica za ocenjevanje stopnje zrelosti procesov razvoja programske opreme v podjetju in za merjenje njihovih parametrov.

riž. 2. Načelo postopnega povečevanja stopnje zrelosti: možnosti za razvoj organizacije

Tu so glavne značilnosti vsake stopnje:

  1. Začetno - razvojni proces je kaotičen. Nekaj ​​procesov je opredeljenih in uspeh projektov je odvisen od posameznih akterjev.
  2. Ponovljiv - Vzpostavljeni osnovni procesi vodenja projektov: sledenje stroškov, urnik dela in funkcionalnost. Poenostavljeni nekateri procesi, potrebni za ponovitev prejšnjih dosežkov na podobnih projektih (projekti s podobnimi aplikacijami).
  3. Definirano - razvoj programske opreme in procesi vodenja projektov so opisani in implementirani v enoten sistem procesi podjetja. Vsi projekti uporabljajo standardni proces razvoja programske opreme in podpore za organizacijo, prilagojen določenemu projektu.
  4. Upravljano - Zbira podrobne kvantitativne podatke o delovanju razvojnih procesov in kakovosti končni izdelek. Analizirata se pomen in dinamika teh podatkov.
  5. Optimizacija – Nenehno izboljševanje procesov temelji na kvantitativnih podatkih o procesih in na poskusni implementaciji novih idej in tehnologij.

Uvod v SW-CMM

(Izboljšanje zrelosti procesov razvoja programske opreme na podlagi modela zrelosti zmogljivosti inštituta za programsko inženirstvo za programsko opremo)

Tečaj je namenjen:
Za vodje podjetij za razvoj programske opreme, vodje oddelkov in projektov za razvoj programske opreme ter strokovnjake za kakovost, ki jih zanima:

  • izboljšanje preglednosti obstoječih proizvodnih procesov;
  • povečanje produktivnosti procesov in podjetja kot celote;
  • znižanje stroškov proizvodnje in obsega obstoječe »skrite« proizvodnje;
  • izboljšanje ugleda podjetja v profesionalnem okolju;
  • odpiranje novih trgov za izdelke.

    2.1 Stroški, trajanje in rezultati. Statistika industrije
    2.2 Donosnost naložbe v CMM

    3.1 TQM (Popolno upravljanje kakovosti), SPI (izboljšanje procesov programske opreme) in najboljše poslovne prakse kot osnova CMM
    3.2 Osnovni koncepti TQM. Uporaba pristopov TQM v proizvodnji programskih izdelkov
    3.3 Prednosti in tveganja modela za izboljšanje procesa CMM
    3.4 Koncept procesa. Glavne sestavine procesnega pristopa
    3.5 Stopnje zrelosti procesa

    9.1 Sistem standardov za IT industrijo (načrt)
    9.2 Razmerje med ISO in CMM, Racionalni poenoten proces, vodenje projektov
    9.3 Aplikacija CMM za majhne organizacije
    9.4 Česa ni v SMM
    9.5 Dokumenti in postopki

    10.1 Končni pregled SW-CMM. Porazdelitev po svetu. Glavne težave
    10.2 CMMI (Integracija modela zrelosti zmogljivosti) - nadaljnji razvoj CMM modeli

    Komplet diapozitivov, praktična učna gradiva, dodatna gradiva za samostojno učenje.

    Celoten nabor dokumentov o SW-CMM (besedilo standarda, metode ocenjevanja, industrijske statistike, primeri dokumentov)

    Praktični tečaj o tehnologiji implementacije modela SW-CMM v IT podjetja

    Kratka opomba:
    Namen tega tečaja je pomagati podjetjem, da samostojno in kompetentno načrtujejo in izvajajo delo pri implementaciji modela izboljšanja zrelosti procesa, pomagajo preprečiti pogoste napake in težave, ki so nastale med izvajanjem.

    Tečaj je namenjen:
    Tečaj je namenjen vodjem podjetij in oddelkov, ki se ukvarjajo z razvojem programske opreme, vodjem projektov, vodjem kakovosti in drugim, ki jih zanima izboljšanje kakovosti svojega razvoja in certificiranje svojih procesov za CMM.

  • Pregled priznanih standardov na področju vodenja kakovosti za IT (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)
    17. Na CMM prek ISO?

    • Kakovost programskih izdelkov je morda eden najresnejših problemov v programski industriji. Kakovost je veliko več kot le odsotnost napak. Vključuje nabor različnih značilnosti: zanesljivost, vdljivost, prilagodljivost, združljivost, vzdržljivost, prenosljivost, učinkovitost itd. Ni presenetljivo, da je v industriji programske opreme tako raznolika kakovost standardov kakovosti.

    Kakovost je bilo enostavno izmeriti: ali smo bili plačani ali pa ne.
    Dean Leffingwell, Don Widrig.
    Upravljanje zahtev programske opreme

    CMM/CMMI

    Morda je najbolj znan standard kakovosti treba šteti za model zrelosti sposobnosti (CMM) - model za ocenjevanje stopnje zrelosti razvojnih procesov skupaj z njegovimi izpeljankami. Ustvaril ga je SEI (Software Engineering Institute), ki ga financira ameriško ministrstvo za obrambo in je strukturna enota univerze Carnegie Mellon. Prva uradna različica standarda je bila izdana leta 1993, čeprav se je delo na njej začelo veliko prej - njegove glavne določbe so bile objavljene že leta 1986.

    Uspeh CMM je bil vnaprej določen z več dejavniki. Ta standard je bil eden prvih, ki je sprva upošteval posebnosti razvoja programske opreme. Izkazalo se je, da je dokaj preprost in pregleden tako za razumevanje kot za uporabo ter je urejal "kaj" in ne "kako" narediti, zato je bil primeren za različne razvojne metodologije in ni nalagal nobenih omejitev glede standardov dokumentacije, orodij, okolje in jeziki, ki se uporabljajo v projektih. In morda je bil glavni dejavnik, ki je vnaprej določil priljubljenost CMM, sodelovanje SEI z ministrstvom za obrambo ZDA, kar je dejansko pomenilo uporabo standarda pri izvajanju projektov, ki jih je naročil ta oddelek.

    Model CMM (Tabela 1) predvideva pet stopenj zrelosti, od katerih vsaka ustreza določenim ključnim procesnim področjem (Key Process Areas, KPA).

    Tabela 1. Sloji modela CMM
    številka stopnje Ime stopnje Ključna procesna področja
    1 Osnovno Če je organizacija na tej ravni, potem zanjo ni ključnih procesnih področij
    2 ponavljajoče se Upravljanje konfiguracije programske opreme Zagotavljanje kakovosti izdelkov programske opreme Vodenje pogodbe z izvajalcem Spremljanje napredka projekta Načrtovanje projektov programske opreme Upravljanje zahtev.
    3 Definitivno Strokovne ocene Usklajevanje interakcij med projektnimi skupinami Inženiring programski izdelek.Programsko integrirano upravljanje.Program usposabljanja osebja.Opredelitev organizacijskega procesa.Obseg organizacijskega procesa
    4 Upravljano Upravljanje kakovosti programske opreme Upravljanje procesov na podlagi kvantitativnih metod
    5 Optimiziran Upravljanje sprememb procesa. Upravljanje tehnoloških sprememb. Preprečevanje napak

    Razdelitev na nivoje in opredelitev KPA za vsako od njih omogoča dosledno izvajanje CMM, ob uporabi standarda kot vodila, ki lahko zagotovi nenehno izboljševanje v procesu razvoja.

    Standard CMM se je izkazal za zelo uspešnega, nato pa je na njegovi podlagi nastala cela vrsta standardov (tabela 2). Poleg tega je prejel novo ime - SW-CMM (Capability Maturity Model for Software), ki natančneje odraža njegov položaj v precej veliki družini standardov.

    Tabela 2. Razvoj standardov CMM
    Ime standarda Opis
    Sistemski inženiring CMM (SE-CMM) Osredotoča se na vprašanja sistemskega inženiringa - razvoj izdelkov (analiza zahtev, načrtovanje in integracija produktnih sistemov) in njihova proizvodnja (planiranje in delovanje proizvodne linije)
    Zaupanja vreden CMM (T-CMM) Zasnovan za servisiranje občutljivih in zaprtih programski sistemi ki zahtevajo visoko kakovostno zagotavljanje programske opreme
    Sistemski varnostni inženiring CMM (SSE-CMM) Osredotoča se na varnostne vidike programskega inženiringa, zagotavlja varen razvojni proces, vključno z varnostjo članov ustvarjalne ekipe
    Ljudje CMM (P-CMM) Razmišlja o vprašanjih razvoja osebja v programskih organizacijah
    CMM za pridobitev programske opreme (SA-CMM) Zajema nakup programskih izdelkov od zunanjih organizacij
    CMM za integriran razvoj izdelkov (IPD-CMM) Služi kot okolje za integracijo razvojnih prizadevanj v vseh fazah življenjskega cikla in iz vsakega oddelka v podjetju

    Vendar je praktična uporaba standardov serije CMM pokazala, da ne zagotavljajo brezpogojnega uspeha pri razvoju programske opreme. Ti standardi med seboj niso bili dobro usklajeni - hkratna implementacija različnih modifikacij CMM bi lahko bila precejšen izziv in zbegala strokovnjake organizacij, ki so se soočale z njim.

    Pomemben problem CMM je tudi potreba po "poravnavi" vseh procesov. Če organizacija poskuša certificirati na določeni ravni, mora zagotoviti, da se ustrezna raven uporablja za vse njene procese. Tudi če posebnosti, metodologija ali razvojne značilnosti nimajo določenih procesov, ki bi jih bilo treba izvesti, certificiranje to zahteva.

    Drugo težavo povzroča položaj, ki so ga standardi CMM zavzeli v sodobni industriji programske opreme. Ker mora organizacija z visoko stopnjo v skladu s CMM zagotavljati višjo zmogljivost programskega produkta od tistih, ki so certificirani na nižjih ravneh, se je standard začel uporabljati kot izbirno merilo za sodelovanje na razpisih za razvoj programske opreme ali projekte zunanjega izvajanja. Povpraševanje po certificiranih organizacijah je povzročilo predlog za "hitro in neboleče certificiranje".

    To stanje je postalo možno zaradi pomanjkljivosti postopka certificiranja. Certificiranju ni predmet celotne organizacije kot celote, temveč le določen projekt. Nič ne preprečuje organizaciji, da ustvari "vzoren" projekt, ki se izvaja ob upoštevanju vseh zahtev visokih ravni. Standard CMM, pridobijo ustrezno raven certifikata in izjavijo, da vsi izdelki izpolnjujejo to raven standarda.

    Reši večino težav, ki jih je zasnovan CMM nov standard SEI - Capability Maturity Model Integrated (CMMI) - Integrirani model za ocenjevanje stopnje zrelosti razvojnih procesov. Standard CMMI je bil prvotno ustvarjen tako, da se združuje obstoječe možnosti CMM in odpraviti morebitna protislovja pri njeni praktični uporabi na različnih področjih dejavnosti visokotehnoloških podjetij.

    Da bi odpravili potrebo po "usklajevanju" procesov organizacije in se bolj prilagajali njenim poslovnim potrebam in ne obratno, ima standard CMMI dve obliki predstavitve - klasično, večnivojsko, ki ustreza CMM, in novo, neprekinjeno. Kontinuirana oblika predstavitve ne upošteva stopnje zrelosti (Maturity Levels), temveč ravni zmogljivosti, ki se ocenjujejo za posamezna procesna področja (Process Areas, PA). V tabeli. 3 prikazuje preslikavo ravni zrelosti standarda CMM, kot tudi ravni zrelosti večplastne predstavitve CMMI in ravni zmogljivosti neprekinjene predstavitve CMMI.

    SEI se odmika od CMM in v zameno aktivno promovira CMMI, obljublja poostritev nadzora nad certifikacijskim postopkom, uvedbo novih razredov za zmanjšanje stroškov in njegovo privlačnost za manjše organizacije; zagotavljanje združljivosti s standardi ISO. Vendar ostaja dejstvo, da v sodobnih razmerah prisotnost certifikata določene stopnje CMM / CMMI ni tako pomemben dejavnik, kot je bil pred nekaj leti, in je sprejet brez dodatnih vprašanj, razen morda pri projektih, ki se izvajajo po vladnem naročilu.

    5 evolucijskih stopenj pri upravljanju organizacijskih procesov. Razlaga modela zrelosti zmogljivosti. CMM

    Model zrelosti zmogljivosti CM-CEI je organizacijski model, ki opisuje 5 evolucijskih stopenj (ravneh), na katerih se upravljajo procesi v organizaciji.

    Prvotno ustvarjen za razvoj programske opreme, bistvo modela zrelosti zmogljivosti je, da mora biti organizacija sposobna sprejeti in podpreti svoje programske aplikacije. Model predlaga tudi konkretne korake in pobude, ki bodo organizaciji pomagale pri rasti na naslednjo raven.

    5 stopenj modela zrelosti sposobnosti

    Začetni (procesi so ad hoc, kaotični ali pa jih je v resnici nekaj definiranih) Ponovljivi (osnovni procesi so vzpostavljeni in obstaja disciplina, da se teh procesov držimo) Definirani (vsi procesi so definirani, dokumentirani) , poenoteni in integrirani) Upravljani ( procesi se merijo z združevanjem podrobnih podatkov o procesih in njihovi kakovosti) Optimiziranje (Optimiziranje) ( stalen razvoj proces s kvantitativnimi povratnimi informacijami in testiranjem novih idej in tehnologij)

    Model razvoja programske opreme

    CMM opisuje načela in prakse, ki so osnova koncepta zrelosti programskega procesa. Zasnovani so tako, da pomagajo podjetjem za razvoj programske opreme in prodajnim podjetjem, da izboljšajo sofisticiranost svojih procesov programske opreme na evolucijski način. Začenši od ad hoc, kaotičnih procesov, naprej do zrelih, discipliniranih procesov programske opreme. Poudarek je na prepoznavanju ključnih procesnih področij in zglednih praks, ki lahko tvorijo disciplinirane procese programske opreme. Koncept zrelosti CMM ustvarja kontekst, v katerem:

      Vaje je mogoče ponoviti. Če neke operacije ne ponovite, je ne bi smeli izboljšati. Obstajajo pravila, postopki in prakse, ki prisilijo organizacijo k izvajanju in doslednemu izvajanju. Najboljše prakse organizacije proizvodno delo se lahko hitro porazdeli med skupine. Prakse so opredeljene tako, da omogočajo izmenjavo med projekti in s tem zagotavljajo nekaj standardizacije za organizacijo. Odstopanja pri izvedbi teh metod so čim manjša. Za naloge so postavljeni kvantitativni cilji; meritve pa so vzpostavljene, izdelane in vzdrževane kot osnova za vrednotenje. Prakse se nenehno izboljšujejo za izboljšanje zmogljivosti (optimizacija).

    Model zrelosti zmogljivosti je uporaben ne le za razvoj programske opreme, ampak tudi za opis evolucijskih ravni organizacij na splošno in za opis ravni upravljanja, ki jo je organizacija uvedla ali želi doseči.

    Struktura modela razvoja značilnosti

      Stopnje zrelosti so večplasten koncept, ki zagotavlja doslednost discipline, ki je potrebna za doseganje nenehnih izboljšav. Tu je pomembno omeniti, da organizacija razvije sposobnost vrednotenja posledic nove prakse, tehnologije ali orodja. Zato ne gre za sprejemanje teh inovacij, temveč za to, kako ta inovativna prizadevanja vplivajo na obstoječe prakse. Podpira projekte, skupine in organizacije, tako da jim daje osnovo za sprejemanje informiranih odločitev. Ključna procesna področja – Ključno procesno področje (KPA) opredeljuje skupino povezanih dejavnosti, ki ob skupnem izvajanju dosegajo številne pomembne cilje. Cilji – Cilji ključnega procesnega področja opisujejo določbe, ki morajo obstajati za to ključno procesno področje. Predpise je treba izvajati na učinkovit in varen način. Obseg, v katerem so cilji izpolnjeni, kaže, kakšne sposobnosti je organizacija vzpostavila na tej ravni odličnosti. Cilji določajo obseg, meje in namen vsakega ključnega področja procesa. Splošne značilnosti – Splošne značilnosti vključujejo prakse, ki izvajajo in institucionalizirajo ključna procesna področja. Teh 5 vrst splošne značilnosti vključujejo: zavezanost izvajanju, sposobnost izvajanja, pobude, ki jih je treba izvesti, merjenje in analize ter nadzor izvajanja. Ključne prakse – Ključne prakse opisujejo infrastrukturne elemente in prakse, ki najbolj učinkovito prispevajo k izvajanju in institucionalizaciji ključnih procesnih področij.

    Merila za opredelitev procesa

    Merila za opredelitev procesa so nabor procesnih elementov, ki jih je treba vključiti v opis procesa programske opreme, da jih ljudje lahko uporabljajo v praksi. Za določitev meril morate zastaviti vprašanje - "Katere informacije o procesu programske opreme so potrebne za dokumentacijo?"

    Organizacije, ki delujejo na področju razvoja, dostave, implementacije in vzdrževanja programske opreme in sistemske integracije, vse bolj čutijo, da njihova konkurenčnost temelji na kakovosti in nizkih stroških, izdelljivosti.

    Vodje takšnih organizacij niso vedno sposobni oblikovati strategije za izboljšanje in razvoj tehnologije dejavnosti svojega podjetja; na trgu dela očitno ni dovolj strokovnjakov s potrebnimi kvalifikacijami. Hkrati pa mednarodne izkušnje na področju izboljševanja tehnoloških procesov za razvoj in delovanje programske opreme že vrsto let niso dovolj posplošene in formalizirane. Šele v zgodnjih devetdesetih letih je Ameriški inštitut za programsko inženirstvo (SEI) oblikoval model tehnološke zrelosti organizacij CMM (Capability Maturity Model), ki je opredelil stopnje tehnološke zrelosti in njihove posebnosti. V desetletju je bil CMM preizkušen v številnih organizacijah, njegovo učinkovitost in zanesljivost pa so preverile organizacije naročanja, prodajalci programske opreme, podjetja za razvoj programske opreme po meri in programiranje na morju.

    Danes ima na zahodu razvojno podjetje tako rekoč velike težave pri pridobivanju naročil, če ni certificirano s strani SMM. Stranke zahtevajo jamstva izvajalca o izdelljivosti, jamstva, da izvajalec ne more zagotoviti nekvalitetne storitve.

    Oceno tehnološke zrelosti podjetij lahko uporabimo:

    naročnik pri izbiri najboljših izvajalcev (na primer na razpisu);

    · programska podjetja, da sistematično ocenjujejo stanje svojih tehnoloških procesov in izberejo področja za njihovo izboljšanje;

    · podjetja, ki se odločijo za certificiranje za oceno »razsežnosti katastrofe«, t.j. vaše trenutno stanje;

    revizorji, da določijo standardni postopek certificiranja in izvedejo potrebne ocene;

    · svetovalne družbe, ki se ukvarjajo s prestrukturiranjem podjetij in ponudnikov storitev informacijske tehnologije in povezanih storitev.

    Ko se tehnološka zrelost organizacije povečuje, postajajo procesi za ustvarjanje in vzdrževanje programske opreme bolj standardizirani in dosledni. Hkrati formalizacija procesov omogoča standardizacijo pričakovanih rezultatov njihovega izvajanja in zagotavlja predvidljivost rezultatov izvajanja projekta.

    Zrelost procesa (zrelost procesa programske opreme)- to je stopnja njihove obvladljivosti, obvladljivosti in učinkovitosti. Povečanje zrelosti tehnologije se nanaša na možnost povečane odpornosti procesov in kaže na stopnjo učinkovitosti in doslednosti pri uporabi procesov razvoja in vzdrževanja programske opreme v celotni organizaciji. Prava uporaba procesov je nemogoča brez njihove dokumentacije in obveščanja osebja organizacije, brez stalnega spremljanja in izboljševanja njihovega izvajanja. Zmogljivosti dobro zasnovanih procesov so v celoti opredeljene. Povečanje tehnološke zrelosti procesov pomeni, da se lahko učinkovitost in kakovost rezultatov njihovega izvajanja nenehno povečujeta.


    V organizacijah, ki so dosegle tehnološko zrelost, procesi ustvarjanja in vzdrževanja programske opreme dobijo status standarda, se učvrstijo v organizacijskih strukturah in določajo proizvodne taktike in strategijo. Njihova uvedba v status zakona pomeni potrebo po izgradnji potrebne infrastrukture in oblikovanju zahtevane kultura podjetja panoge, ki vzdržujejo ustrezne metode, operacije in postopke za poslovanje, tudi potem, ko tisti, ki so vse to ustvarili, zapustijo organizacijo.

    Model CMM razvija določila o sistemu kakovosti organizacije in oblikuje merila za njegovo popolnost – pet stopenj tehnološke zrelosti, ki jih razvojna organizacija načeloma lahko doseže. Najvišja – četrta in peta stopnja – je pravzaprav značilnost organizacij, ki so obvladale metode kolektivnega razvoja, v katerih so procesi ustvarjanja in vzdrževanja programske opreme celovito avtomatizirani in tehnološko podprti.

    Od leta 1990 je SEI s podporo ameriških vladnih agencij in organizacij za razvoj programske opreme nenehno razvijal in izboljševal ta model, pri čemer je upošteval vse najnovejše dosežke na področju ustvarjanja in vzdrževanja programske opreme.

    CMM je metodološko gradivo, ki opredeljuje pravila za oblikovanje sistema vodenja za ustvarjanje in vzdrževanje programske opreme ter metode za postopno in nenehno izboljševanje proizvodne kulture. Namen SMM je organizacijam razvijalcev zagotoviti potrebna navodila o izbiri strategije za izboljšanje kakovosti procesov z analizo stopnje njihove tehnološke zrelosti in dejavnikov, ki najbolj vplivajo na kakovost izdelkov. Z osredotočanjem pozornosti na manjše število najbolj kritičnih operacij ter sistematičnim povečevanjem učinkovitosti in kakovosti njihovega izvajanja lahko organizacija tako dosega stalno nenehno izboljševanje kulture ustvarjanja in vzdrževanja programske opreme.

    CMM je opisni model v smislu, da opisuje bistvene (ali ključne) lastnosti, ki določajo, na kateri stopnji tehnološke zrelosti je organizacija. Gre za normativni model v smislu, da podroben opis metodologij določa raven organizacije, ki je potrebna za izvajanje projektov različne kompleksnosti in trajanja po pogodbah z vladnimi agencijami ZDA. CMM ni recept, ne predpisuje, kako naj se organizacija razvija. CMM opisuje značilnosti organizacije za vsako stopnjo tehnološke zrelosti, ne da bi dal kakršna koli navodila, kako se premakniti z stopnje na raven. Organizacija lahko traja nekaj let, da se premakne s prve na drugo raven, in zelo malo časa, da se premakne od stopnje do stopnje naprej. Proces izboljševanja tehnologije razvoja programske opreme se odraža v strateških načrtih organizacije, njeni strukturi, uporabljenih tehnologijah, splošni družbeni kulturi in sistemu vodenja.

    Na vsaki ravni so določene zahteve, pod katerimi se doseže stabilizacija najpomembnejših kazalnikov procesov. Doseganje posamezne stopnje tehnološke zrelosti je posledica pojavljanja določenega števila komponent v procesih razvoja programske opreme, kar posledično vodi v povečanje njihove produktivnosti in kakovosti. Na sl. Slika 1.7 prikazuje pet stopenj tehnološke zrelosti CMM.

    riž. 1.7. Pet stopenj tehnološke zrelosti SMM

    Napisi na puščicah opredeljujejo značilnosti izboljševanja procesov pri prehodu z nivoja na raven.

    Stopnje od druge do pete je mogoče označiti z operacijami, ki so namenjene standardizaciji in (ali) posodobitvi procesov ustvarjanja programske opreme, ter z operacijami, ki sestavljajo same procese njenega ustvarjanja. Hkrati je prva raven tako rekoč osnova, temelj za primerjalna analiza zgornjih ravneh.

    Na ravni 1 (začetna) so osnovni procesi ustvarjanja in vzdrževanja programske opreme naključni in kaotični. Uspeh projekta je v celoti odvisen od individualnih prizadevanj osebja. Na tej ravni organizacija praviloma nima stabilnega okolja, potrebnega za ustvarjanje in vzdrževanje programske opreme.

    Uspeh projekta je v tem primeru praviloma v celoti odvisen od stopnje energije in izkušenj vodstva in strokovni ravni izvajalci. Lahko se zgodi, da energičen vodja premaga vse ovire v procesu projekta in doseže izdajo resnično uspešnega programskega produkta. Toda potem, ko tak vodja zapusti svoje mesto, ni nobenega zagotovila, da bo naslednji tak projekt uspešen. V odsotnosti potrebne ravni vodenja projektov tudi napredna tehnologija ne bo mogla rešiti položaja.

    Za procese na prvi ravni je značilna nepredvidljivost zaradi dejstva, da se njihova sestava, namen in zaporedje v procesu izvajanja projekta naključno spreminjajo glede na trenutno stanje. Posledično so dodeljena sredstva preveč porabljena in urniki dela so moteni. Sposoben za usposabljanje in usposobljeni strokovnjaki v organizacijah je glavni pogoj za uspeh na vseh stopnjah zrelosti, na prvi stopnji pa je edina priložnost za doseganje vsaj pozitivnih rezultatov.

    Na ravni 2 (raven ponovljivih procesov) procesi vodenja projekta zagotavljajo stalen nadzor stroškov projekta, urnika in opravljenih funkcij. Disciplina projekta je takšna, da je mogoče predvideti uspešnost projektov izdelave podobnih programskih izdelkov.

    Na tej ravni načrtovanje in vodenje novih projektov temelji na izkušnjah uspešno izvedenih podobnih projektov. Glavna značilnost druge stopnje je prisotnost formaliziranih in dokumentiranih učinkovitih procesov vodenja projektov, ki omogočajo uporabo pozitivnih izkušenj uspešno zaključenih projektov. Učinkoviti procesi so tisti, ki so dokumentirani, dejansko uporabljeni, merljivi in ​​jih je mogoče nadgraditi. Bistveno je, da je osebje usposobljeno za njihovo uporabo.

    Za vsako raven CMM, začenši z drugo, je značilna prisotnost številnih tako imenovanih ključnih procesnih skupin (KPA). Model CMM vsebuje 18 takih skupin, zadnja različica modela CMMI vsebuje 20 skupin. Za stopnjo 2 CMM je značilna prisotnost naslednjih procesov v organizaciji (njihova imena ustrezajo CMMI):

    upravljanje zahtev;

    upravljanje konfiguracije;

    načrtovanje projektov;

    spremljanje in nadzor projekta;

    upravljanje pogodb;

    merjenje in analize;

    zagotavljanje kakovosti postopka in izdelka.

    Postopke na drugi ravni lahko označimo kot poenostavljene, saj so vnaprej načrtovani in je njihovo izvajanje strogo nadzorovano, zaradi česar je dosežena predvidljivost rezultatov projekta. S povečanjem in kompleksnostjo projektov se pozornost preusmerja s tehničnih vidikov njihovega izvajanja na organizacijske in vodstvene vidike. Izvajanje procesov od ljudi zahteva učinkovitejše in bolj usklajeno delo, kar pa zahteva preučevanje dokumentiranih najboljših praks za izboljšanje strokovne odličnosti.

    Na 3. stopnji (stopnja standardiziranih procesov) so procesi razvoja programske opreme dokumentirani, standardizirani in predstavljajo enoten tehnološki sistem, ki je obvezen za vse oddelke organizacije. Vsi projekti uporabljajo enotno tehnologijo za ustvarjanje in vzdrževanje programske opreme, ki je bila preizkušena, odobrena in povzdignjena v status standarda.

    Na tej ravni se procesom na ravni 2 dodajo naslednji procesi:

    specifikacija zahtev;

    integracija izdelkov;

    preverjanje;

    certificiranje;

    standardizacija organizacijskih procesov;

    · izobraževanje;

    integrirano vodenje projektov;

    · obvladovanje tveganj;

    Analiza in odločanje.

    Glavno merilo za uporabo in po potrebi prilagajanje procesov na tej ravni je pomoč vodstvu in tehničnim strokovnjakom pri izboljšanju učinkovitosti izvajanja projekta. Na tej ravni se v organizaciji, ki je odgovorna za sestavo operacij, ki sestavljajo procese, ustvari posebna skupina – procesna skupina programskega inženiringa (SEPG).

    Na podlagi ene same tehnologije za vsak projekt je mogoče razviti lastne procese ob upoštevanju njegovih značilnosti. Takšni procesi v CMM se imenujejo "projektno usmerjeni razvojni procesi programske opreme" (projektno "s definiran programski proces).

    Opis vsakega procesa vključuje pogoje za njegovo izvedbo, vhodne podatke, standarde in postopke za izvedbo, mehanizme preverjanja (npr. strokovna mnenja), izhodnih podatkov in pogojev zaključka. Opis procesa vključuje tudi informacije o orodjih, potrebnih za njegovo dokončanje, in navedbo vloge, ki je odgovorna za njegovo izvedbo.

    Glavni namen 4. stopnje (stopnja vodenih procesov) je trenutni nadzor nad procesi. Vodstvo mora zagotoviti, da se procesi izvajajo v okviru določene kakovosti. Lahko pride do neizogibnih izgub in začasnih vrhov merjenih rezultatov, ki zahtevajo posredovanje, vendar mora biti sistem na splošno stabilen.

    Na ravni 4 so dodani naslednji procesi:

    upravljanje uspešnosti in produktivnosti;

    Kvantitativno vodenje projektov.

    Na tej ravni se v praksi uporablja podrobna ocena kakovosti tako procesov ustvarjanja kot samega programskega produkta. V tem primeru se uporabljajo merila kvantitativnega vrednotenja.

    V okviru celotne organizacije se razvija enoten program za kvantitativni nadzor produktivnosti izdelave programske opreme in njene kakovosti. Za lažjo analizo procesov je za vse projekte, ki se izvajajo v organizaciji, ustvarjena enotna baza procesov za izdelavo in vzdrževanje programske opreme. Razvijajo se univerzalne metode za kvantificiranje produktivnosti procesov in kakovosti njihovega izvajanja. To omogoča kvantitativno analizo in vrednotenje procesov ustvarjanja in vzdrževanja programske opreme.

    Rezultati procesov na četrtem nivoju postanejo predvidljivi, saj so merljivi in ​​se spreminjajo v danih količinskih omejitvah. Na tej ravni je mogoče vnaprej načrtovati določeno kakovost procesov in končnih izdelkov.

    Glavni namen stopnje 5 (stopnja optimiziranih procesov) je dosledno izboljševanje in posodabljanje procesov ustvarjanja in vzdrževanja programske opreme. Za namen načrtovane posodobitve tehnologije razvoja programske opreme organizacija ustvarja posebna enota, katerega glavne pristojnosti so zbiranje podatkov o izvajanju procesov, njihova analiza, posodobitev obstoječih in ustvarjanje novih procesov, njihovo preizkušanje na pilotnih projektih in dajanje statusa standardov podjetja.

    Na stopnji 5 so dodani naslednji procesi:

    uvajanje tehnoloških in organizacijskih novosti;

    analiza vzrokov in posledic in reševanje problemov. Za procese ustvarjanja in vzdrževanja programske opreme so značilni

    kot dosledno izboljševanje, saj si organizacija nenehno prizadeva za njihovo posodabljanje. Ta izboljšava se razteza tako na identifikacijo dodatnih zmogljivosti uporabljenih procesov kot na ustvarjanje novih optimalnih procesov in uporabo novih tehnologij.

    Inovacije, ki lahko prinesejo največjo korist, so standardizirane in prilagojene v tehnološki sistem v celotni organizaciji. Osebje, ki sodeluje pri izvedbi projekta, analizira napake in ugotovi vzroke za njihov nastanek. Procesi razvoja programske opreme se ocenjujejo, da se preprečijo ponovitve situacij, ki vodijo do okvar, rezultati ocenjevanja pa se upoštevajo pri nadaljnjih projektih.

    Vsaka naslednja raven dodatno zagotavlja popolnejšo vidljivost procesov ustvarjanja in vzdrževanja programske opreme.

    Na prvi ravni so procesi amorfni (»črne skrinjice«) in njihova vidljivost je zelo omejena. Že od samega začetka sestava in namen delovanja praktično nista opredeljena, kar povzroča velike težave pri določanju statusa projekta in njegovega napredka. Zahteve za izvajanje procesov se postavljajo nenadzorovano. Razvoj programske opreme v očeh menedžerjev (predvsem tistih, ki sami niso programerji) včasih izgleda kot črna magija.

    Na drugi stopnji se nadzoruje izpolnjevanje zahtev uporabnikov in izdelava programske opreme, saj je definirana osnova za procese vodenja projektov. Proces ustvarjanja programske opreme lahko gledamo kot zaporedje "črnih skrinjic", ki jih je mogoče nadzorovati na prehodnih točkah iz ene "škatle" v drugo - fiksne stopnje. Tudi če vodja ne ve, kaj se dela »znotraj škatle«, je natančno določeno, kaj naj bi bil rezultat procesa, in so določene kontrolne točke za njegov začetek in konec. Zato lahko vodstvo prepozna težave na točkah interakcije črne skrinjice in se nanje pravočasno odzove.

    Na tretji ravni je definirana notranja struktura »črnih skrinjic«, tj. naloge, ki sestavljajo procese. Notranja struktura je način, na katerega se standardni procesi v organizaciji uporabljajo za posebne projekte. Vodstvena povezava in izvajalci poznajo svoje vloge in odgovornosti v projektu do zahtevane stopnje podrobnosti. Vodstvo je vnaprej pripravljeno na tveganja, ki lahko nastanejo pri izvajanju projekta. Ker standardizirani in dokumentirani procesi postanejo "transparentni" za pregled, lahko zaposleni, ki niso neposredno vključeni v projekt, pravočasno prejmejo točne informacije o njegovem trenutnem stanju.

    Na četrti ravni je izvajanje procesov togo vezano na orodja, kar omogoča določanje kvantitativne značilnosti njihova kompleksnost in kakovost izvedbe. Vodje, ki imajo objektivno bazo kvantitativnih meritev, dobijo možnost, da natančno načrtujejo faze in faze projekta, napovedujejo napredek projekta ter se lahko pravočasno in ustrezno odzovejo na nastajajoče težave. Z zmanjševanjem možnih odstopanj od danih rokov, stroškov in kakovosti v procesu izvajanja projekta se njihova sposobnost napovedovanja rezultatov nenehno povečuje.

    Na peti ravni, da bi izboljšali kakovost izdelkov in povečali učinkovitost njegovega ustvarjanja, se nenehno in sistematično izvaja delo za ustvarjanje novih izboljšanih metod in tehnologij za ustvarjanje programske opreme. Pozornost pritegnejo ne le že uporabljeni, temveč tudi novi, učinkovitejši procesi in tehnologije. Vodje lahko kvantificirajo vpliv in učinkovitost sprememb v tehnologiji razvoja in vzdrževanja programske opreme.

    Četrta in peta raven sta v industriji programske opreme redki. Če je torej več sto podjetij na svetu doseglo tretjo raven, je bilo pete stopnje (po podatkih SEI za leto 2002) 62 podjetij, četrte pa 72 podjetij. Nekaterih ne zanima oglaševanje svojih organizacijskih tehnologij, drugi pa certificiranje izvajajo preprosto pod pritiskom stranke.

    Traja deset let ali več, da dosežemo najvišjo raven SMM. Toda tudi stopnja 3 vam omogoča, da pogumno vstopite v mednarodno prizorišče. Za uporabo SMM podjetju ni treba iskati zaposlenih z nekaterimi edinstvenimi sposobnostmi, dovolj je, da razume splošno idejo. Opis modela CMM podrobno določa, kaj je treba storiti, da se razvije v skladu s tem modelom. Vsak menedžer srednjega razreda je sposoben slediti urejenim dejanjem CMM.

    Najnovejša različica CMM 1.1 je namenjena predvsem velikim podjetjem, ki se ukvarjajo z izvajanjem velikih projektov, lahko pa jo uporabljajo tudi skupine po dve ali tri osebe ali posamezni programerji za dokončanje manjših projektov (do treh mesecev). V takih primerih ima lahko CMM model ključno vlogo, saj je prejemanje novih naročil v veliki meri odvisno od kakovosti izvedbe prejšnjih projektov. Majhne skupine bodo s stopnjo 2 precej zadovoljne, saj je za majhen projekt odstopanje od roka nekaj tednov nepomembno.

    Od leta 2002 se uradno distribuira posebna integracijska različica CMMI. Gre za nov razvoj SEI, ki zajema vse vidike dejavnosti podjetja: od razvoja in izbire izvajalca do usposabljanja, implementacije in vzdrževanja. Poleg tega je model CMMI razširjen s pristopi sistemskega inženiringa. Ta model je vključeval razvoj, narejen med zasnovo CMM 2.0 (ni bil dokončan), katerih glavne spremembe so bile usmerjene v razjasnitev procesov za podjetja četrte in pete ravni, kar je najbolj pomembno za obsežne ameriške projekte.

    Model CMM je precej tehten in pomemben, vendar ga ne smemo uporabljati kot edino podlago, ki določa celoten proces razvoja programske opreme. Namenjen je bil predvsem podjetjem, ki razvijajo programsko opremo za ameriško obrambno ministrstvo. Za te sisteme je značilna velika velikost in dolga življenjska doba ter kompleksnost vmesnika s strojno in drugo programsko opremo. Na ustvarjanju tovrstnih sistemov, ki morajo biti v skladu z zahtevami in standardi, ki jih je razvilo Ministrstvo za obrambo, delajo precej velike ekipe programerjev.

    Slabosti SMM vključujejo naslednje:

    1. Model se osredotoča izključno na vodenje projektov in ne na proces ustvarjanja programskega produkta. Model tega ne upošteva pomembnih dejavnikov, kot je uporaba določenih metod, kot so izdelava prototipov, formalne in strukturne metode, orodja statične analize itd.

    2. Model nima analize tveganj in odločitev, kar preprečuje odkrivanje težav, preden vplivajo na razvojni proces.

    3. Obseg modela ni opredeljen, čeprav avtorji priznavajo, da je univerzalen in primeren za vse organizacije. Vendar avtorji ne ločijo jasnega med organizacijami, ki lahko ali pa tudi ne uporabljajo SMM v svojih dejavnostih. Manjšim podjetjem se zdi ta model preveč birokratski. Kot odgovor na te kritike so bile razvite strategije za izboljšanje procesov za majhne organizacije.

    glavni cilj Pri ustvarjanju modela CMM je bil namen ameriškega ministrstva za obrambo oceniti zmogljivosti prodajalcev programske opreme. Trenutno ni jasnih zahtev za doseganje določene stopnje razvoja razvojnih organizacij. Vendar pa je splošno sprejeto, da bo organizacija, ki je dosegla visoko raven, bolj verjetno zmagala na razpisu za dobavo programske opreme. Kot alternativa CMM je predlagana posplošena klasifikacija procesov izboljšanja tehnološke zrelosti, ki je primerna za večino organizacij in projektov programske opreme. Možno je identificirati več pogoste vrste izboljšavnih procesov.

    1. neformalni proces. Nima jasno opredeljenega modela izboljšav. Uspešno ga lahko uporablja ločena razvojna ekipa

    cov. Neformalnost procesa ne izključuje formalnih dejavnosti, kot je upravljanje konfiguracije, vendar same dejavnosti in njihovi odnosi niso vnaprej določeni.

    2. Upravljan proces. Ima pripravljen model, ki vodi proces izboljšav. Model definira dejavnosti, njihov urnik in odnose med njimi.

    3. Metodično dober postopek. Predpostavlja se, da so bile določene metode vzpostavljene (na primer, sistemsko se uporabljajo metode objektno usmerjenega načrtovanja). Za to vrsto procesa bodo uporabna orodja za podporo načrtovanju in analizi (CASE-orodja).

    4. Proces neposrednega izboljšanja. Ima jasno opredeljen cilj izboljšanja tehnološkega procesa, za kar je v proračunu organizacije posebna vrstica ter opredeljeni normativi in ​​postopki za uvajanje novosti. Del takega procesa je kvantitativna analiza procesa izboljšav.

    Te klasifikacije ni mogoče imenovati jasne in izčrpne - nekateri procesi lahko hkrati pripadajo več vrstam. Na primer, neformalnost procesa je izbira razvojne ekipe. Ista ekipa lahko izbere določeno razvojno metodologijo, hkrati pa ima vse možnosti za neposredno izboljšanje procesa. Ta postopek je razvrščen neformalno, metodično utemeljeno, neposredno izboljšanje.

    Potreba po tej klasifikaciji je posledica dejstva, da zagotavlja osnovo za celovito izboljšanje tehnologije razvoja programske opreme in organizaciji omogoča izbiro različnih vrst procesov izboljšav. Na sl. 1.8 prikazuje razmerje med različni tipi programski sistemi in procesi za izboljšanje njihovega razvoja.

    riž. 1.8. Uporabnost procesov izboljšav

    Poznavanje vrste izdelka, ki se razvija, bo omogočilo ujemanje programskih sistemov in procesov izboljšav, prikazanih na sl. 1.8 uporabno pri izbiri izboljšave procesa. Na primer, ustvariti morate program, ki podpira prehod programske opreme z ene računalniške platforme na drugo. Tak program ima dokaj kratko življenjsko dobo, zato njegov razvoj ne zahteva standardov in posebna uprava proces izboljšav, kot pri ustvarjanju dolgoživih sistemov.

    veliko tehnoloških procesov trenutno imajo podporo za CASE, zato jih je mogoče poklicati podprti procesi. Metodično upravičenih procesov podprto z orodji za analizo in načrtovanje. Učinkovitost podpornega orodja je odvisna od uporabljenega postopka izboljšanja. Na primer, v neformalnem procesu se lahko uporabljajo tipična podporna orodja (orodja za izdelavo prototipov, prevajalnike, orodja za odpravljanje napak, urejevalnike besedil itd.). Malo verjetno je, da se bodo v neformalnih procesih stalno uporabljala bolj specializirana podporna orodja.

    Model SMM ni edinstven. Skoraj vsak veliko podjetje razvija lastne tehnologije za ustvarjanje programske opreme, včasih te tehnologije postanejo javno dostopne in zelo priljubljene. Široka priljubljenost modela HMM je povezana z njegovim državna podpora, vendar dejansko učinkovitost SMM kritizirajo številni vodilni strokovnjaki. Ena glavnih pomanjkljivosti HMM je povezana s nepotrebno togo zahtevo, da se ne odstopa od načel tega modela, tudi če zdrava pamet kaže drugače. Takšne trditve o posedovanju absolutne resnice ne morejo le vzbuditi suma, zato so med malimi in srednje velikimi podjetji bolj priljubljeni pristopi, ki puščajo veliko več svobode za individualno in kolektivno ustvarjalnost. Spodaj obravnavana metodologija SPMN zavzema vmesno mesto med togimi, "težkimi", učinkovitimi za velike organizacije rešitvami, kot je CMM, in najbolj fleksibilnimi tehnologijami. Pojavi se najboljša možnost za podjetja, ki po eni strani želijo racionalizirati svoje menedžersko dejavnost, po drugi strani pa nameravajo v prihodnosti doseči mednarodni ravni kjer je certificiranje CMM zelo zaželeno.

    Z uporabo definiranega procesa razvoja programske opreme imajo organizacije dosleden načrt za proces, ki ga lahko prilagodijo svojim posebnim potrebam. Nezdružljive potrebe po prilagajanju in standardizaciji je mogoče rešiti z izgradnjo strukture procesa, ki jo sestavljajo standardni moduli ali "osnovni" koraki, in pravila, ki se uporabljajo za opis in vzpostavitev odnosov med temi koraki. V tem primeru se prilagoditev doseže z združevanjem v procesni model.

    Vodenje kakovosti programskih projektov praviloma temelji na znanju iz treh virov:

    Programski inženiring (ACM, IEEE);

    Vodenje projektov (PMI);

    Kakovost (ASQ).

    Inštitut za programsko inženirstvo (SEI) na univerzi Carnegie Mallon združuje vse tri te vire.

    Model zrelosti funkcij (ZmogljivostZrelostModel, SMM), služi kot "okvir" za proces razvoja programske opreme. Ta model temelji na dejanjih in odraža najboljše rezultate posameznikov, ki delajo na izboljšanju procesa razvoja programske opreme in izvajajo evalvacijsko analizo procesa. V nadaljevanju se bomo osredotočili na to, kako upravljanje kakovosti programskih projektov ustreza modelu SEI CMM. Ker je model CMM dobro znan v skupnosti za razvoj programske opreme, ga ni treba posebej definirati. Predstavili bomo le kratek opis le-tega, da bi prikazali potrebo po uporabi življenjskega cikla v razvojnem procesu. Spodaj je kratek posplošen opis stopenj razvoja funkcionalnih zmožnosti modela HMM.

    Model CMM je diagram, v katerem razvojne faze ustrezajo petim stopnjam razvoja funkcionalnosti, na podlagi katerih se izvaja nenehno izboljševanje razvojnega procesa. Ko govorimo o stopnji razvoja funkcionalnosti, običajno pomenijo strogo določeno stopnjo razvoja, ki je namenjena pridobitvi celotnega procesa razvoja programske opreme. Z razdelitvijo modela CMM na pet ravni se daje prednost izboljšavnim aktivnostim, potrebnim za dokončanje razvoja funkcionalnosti procesa. Teh pet ravni lahko na kratko opišemo tako, da jim dodelimo naslednje značilnosti.

    Vir. Proces razvoja programske opreme lahko opišemo kot ad hoc, po meri in včasih kaotičen. Določiti je mogoče le majhno število procesov, uspeh pa je odvisen od posameznikovega truda in odločnega ukrepanja.

    Ponavljajoč. Osnovni procesi vodenja projektov so ustvarjeni za spremljanje stroškov, urnika in funkcionalnosti. Tu se upošteva potreben vrstni red izvedbe procesa, ki je zasnovan tako, da ponovi dosežke, pridobljene prej pri izvajanju podobnih projektov.

    Definitivno. Vsi projekti uporabljajo preizkušeno, prilagojeno različico standardnega procesa razvoja programske opreme organizacije.

    Upravljano. Zbrani so podrobni kazalniki procesa razvoja programske opreme in kvalitativne značilnosti izdelka. Upravljanje procesa razvoja programskih izdelkov se izvaja na kvantitativni ravni.

    Stopnja optimizacije. Nenehno izboljševanje razvojnega procesa se doseže s kvantitativnimi povratnimi informacijami.

    Ta povezava je dosežena z izvajanjem samega procesa, pa tudi na podlagi inovativnih idej in tehnologij. Vsaka stopnja zrelosti je razčlenjena na več ključnih procesnih področij, ki kažejo, katere ukrepe je treba še izvesti za izboljšanje procesa razvoja programske opreme. Vsak ključno procesno področje (ključprocesobmočje,KPA) definira niz medsebojno povezanih dejanj, potrebnih za optimizacijo tega procesa.

    KPA 2. stopnje obravnavajo vprašanja, ki se pojavijo med izvajanjem projekta programske opreme in so povezana z vzpostavitvijo osnovnih kontrol upravljanja projektov. V tej fazi razprave moramo vedeti, da iterativni proces (2. stopnja) omogoča optimizacijo strukturiranja in upravljanja v organizaciji. S takšno definicijo se oblikuje skupen jezik, olajšana so prehodna obdobja, ko so v proces vključeni razvijalci, še posebej, če na tem področju nimajo dovolj izkušenj.

    Vendar pa ponavljajoči se proces (2. stopnja) ne vodi nujno do dobro zasnovanega procesa. Na splošno se izboljšanje procesa zgodi, ko organizacija doseže raven 3. 3. raven se nanaša na reševanje tako projektnih kot organizacijskih vprašanj, saj organizacija vzpostavi infrastrukturo, ki zagotavlja učinkovito programsko opremo in upravljanje za vse projekte. V predmetno področje spadata dve področji KPA, definicija organizacije procesov in integrirano upravljanje programa življenjski cikli.

    Namen definicije organizacijska struktura Področje procesa CPA na 3. stopnji je razvoj in vzdrževanje niza prednosti procesa razvoja programske opreme, ki je enostaven za uporabo, ki izboljšujejo učinkovitost procesov v različnih projektih. Opredelitev procesa vključuje razvoj in vzdrževanje standardnega razvojnega procesa organizacije ter z njim povezane vrednostne predloge procesa. Namen definiranja organizacijske strukture procesa je razviti in vzdrževati standardni proces razvoja programske opreme za dano organizacijo.

    Dejavnosti, ki oblikujejo proces gradnje organizacijske strukture, vključujejo dokumentiranje in vzdrževanje opisnih značilnosti. življenjski cikli razvoja programske opreme. Cilj integriranega upravljanja programov na območju KPA na ravni 3 je združiti inženiring programske opreme in dejavnosti upravljanja v koherentno opredeljen proces razvoja programske opreme, ki je posledica prilagoditve standardnega procesa razvoja programske opreme v tej organizaciji in s tem povezanih dragocenih lastnosti procesa, opisanih v " Opredelitev procesa na ravni njegove strukture.

    CMM se nanaša na skupino modelov procesov programske opreme, razvitih na široki osnovi, ki jo vzdržuje skupnost za razvoj programske opreme. Ker imamo opravka z modelom, gre za poenostavitev dejanskega inženirskega procesa. Model CMM, ki predstavlja standard, identificira zmožnosti organizacije, ki spada v kategorijo določene stopnje zrelosti.

    Organizacije, ki uporabljajo ta model kot mehanizem za merjenje in izboljševanje procesov, bi morale uporabljati sprejemljivo interpretacijo področij znanja procesov v smislu poslovnih ciljev. Ko se uporablja kot orodje za ocenjevanje in merjenje procesov, postane ta model načrt za uspešno izboljšanje procesa. Na splošno lahko na model CMM gledamo kot na niz dobro artikuliranih inženirskih in upravljavskih konceptov, ki temeljijo na dokazanih načelih zagotavljanja. V procesu razvoja programske opreme, kjer je treba znanje ustrezno ovrednotiti in zaščititi, je treba načelom zagotavljanja kakovosti posvetiti veliko pozornost. SMM model ne je zbirka receptov za vse priložnosti. Ne določa, kako naj organizacija nastavi atribute procesa. Poleg tega njegova uporaba ne zagotavlja takojšnjega uspeha. Proces izvajanja izboljšav zahteva čas in stalen trud v celotni organizaciji. Ob tem so še posebej pomembna izvršna uprava in dodeljena sredstva. Model CMM je težko uvrstiti med univerzalne metodologije, ko "ena velikost ustreza vsem priložnostim." Prvi korak pri uporabi tega modela je prilagoditev ravni zrelosti aplikacije, da bo ustrezala vaši organizaciji in obstoječim projektom. SEI je razvil druge modele zrelosti zmogljivosti, ki so uporabni za organizacijsko osebje, pridobivanje programske opreme, sistemski inženiring, integriran razvoj programskih izdelkov in proces osebne programske opreme.

    Ker je programsko opremo, tako kot vsak drug kapital, mogoče predstaviti v obliki materializiranega znanja, pa tudi zaradi dejstva, da je znanje sprva nesistematizirano, negotovo in na splošno nepopolno, je vsak program mogoče predstaviti kot proces. socialno učenje. Ta proces se izvaja v obliki dialoga, med katerim se potrebno znanje materializira v obliki končnega programskega izdelka. Hkrati se izvaja komunikacija med uporabniki in razvijalci, izvaja se interakcija med uporabniki in potrebnimi orodji (tehnologija). Ta proces je ponavljajoč, pri čemer uporabljena orodja tvorijo okolje, v katerem poteka komunikacija. Vsak nov krog dialoga prispeva k pridobivanju vse več uporabnega znanja od vključenih strokovnjakov.

    Ena od glavnih aplikacij modela HMM je opredeliti, kaj pomeni proces, ki je dosegel določeno stopnjo zrelosti. Glede na programsko opremo lahko rečemo, da ima zrel proces naslednje lastnosti:

    Definirano - označuje "metodo, potrebno za dokončanje primera";

    Dokumentirano - zasnovano tako, da ga je mogoče poznati in uporabljati v prihodnosti;

    Naučeno – učenje na podlagi dokumentacije;

    Praktično - se lahko uporablja v praksi in ne odlaša za nedoločen čas;

    Vzdrževanje - na voljo, revidirano in izboljšano;

    Kontrolirano - spremembe odobrijo "udeleženci skupne zadeve";

    Preverjeno - proces teče pravilno;

    Preverjeno - izvede se točno tisti postopek, ki je potreben;

    Izmerjeno - ocenjena učinkovitost se uporablja kot osnova za nadzor in izboljšanje procesa;

    Sposobnost izboljšanja – fleksibilnost in sposobnost spreminjanja.

    Programski inženiring spada v področje ključnih procesov za stopnjo 3, tj. "gotovo". Do leta 1968 se izraz "programski inženiring" sploh ni uporabljal. Programski inženiring je praktična uporaba znanstvenih spoznanj v procesu oblikovanja in razvoja računalniških programov. Ta postopek se imenuje tudi razvoj programske opreme oz produkcija programa.

    Prvi pojav razširjene programske opreme sega v leto 1890. V tem času so se v ameriških centrih za popisovanje pojavile luknjene karte Hermana Choleritha (1860-1929), Massachusetts Institute of Technology, Cambridge, Massachusetts.

    Hkrati je prišlo do prve prekoračitve stroškov po krivdi »računalnikov«. Rezultati ameriških cenzusnih centrov so bili prvotno prikazani v tabeli z mehanskimi pripomočki; mehanski tabulatorji Hermana Holleritha. Hkrati se je začela razvijati proizvodnja luknjanih kartic. Sredstva, porabljena za tabeliranje teh popisnih centrov, so bila 98 % višja od podobnih stroškov, ki so nastali v preteklosti. To je deloma posledica dejstva, da je bila predloga, uporabljena za tabeliranje podatkov, zasnovana zelo podrobno in je količina podatkov v tabeli presegla minimalno zahtevano količino. Čeprav je bil sam postopek tabele bistveno pospešen. Hkrati so se pojavile luknjene kartice, katerih branje je potekalo električno.

    Če se vrnemo k modelu CMM, ugotavljamo, da je na ravni 2 proces razvoja programske opreme lahko predstavljen kot niz "črnih škatel" z določenimi kontrolnimi točkami (fazami). Kot je prikazano na sl. 2.1 so zahteve vključene v proces in gladko "tečejo" v niz "črnih skrinjic".

    riž. 2.1. Postopek 2. stopnje

    Rezultati izračuna se ustvarijo za vsako polje, mejniki in mejniki pa se uporabljajo za spremljanje procesa razvoja programskega izdelka. Sledi faza izvajanja politik, standardov in postopkov. Ta izkušnja je kvantificirana z uporabo osnovnega metričnega sistema, uporabljenega v tem projektu. Nadzor se izvaja z uporabo formalnih praks, vključenih v proces vodenja projekta. Spremljajo se tudi stroški, urniki in nabor funkcij. Glavni subjekti procesa so programske zahteve in delovni produkti, njihovo celovitost pa nadzira sistem za upravljanje konfiguracije. Za projekte so značilni tesni odnosi s podporo strankam. Razvija tudi sposobnost izvajanja programskih procesov.

    Na 3. stopnji, tj. "definirano", dokumentira in dosledno uporablja standardni proces, ki se uporablja za razvoj in vzdrževanje programske opreme v organizaciji, kar je shematično prikazano na sl. 2.2.

    riž. 2.2. Postopek 3. stopnje

    V okviru projektov se standardne programske procese organizacije prilagajajo za njihovo konkretizacijo. Integrirani so tudi procesi upravljanja in programskega inženiringa. Sposobnost izvedbe standardnega procesa je standardna, razvojna ekipa pa je odgovorna za aktivnosti, ki se izvajajo v programski projekt. Naslednja so območja KPA za tretjo stopnjo zrelosti:

    1) obseg organizacijskega procesa;

    2) opredelitev organizacijskega procesa;

    3) inženiring programskih izdelkov;

    4) integrirano upravljanje programske opreme;

    5) interakcija med skupinami;

    6) strokovne ocene;

    7) kurikulum.

    Na stopnji 3 proces razvoja programske opreme sledi dobro opredeljenemu procesu. Zavedanje vlog in odgovornosti v procesu je potrebno. Med izvajanjem programskega procesa je prikazan proizvodni proces programskega izdelka.

    4. stopnja (slika 2.3), tj. "upravljan" vključuje dve področji KPA: kvantitativno upravljanje procesov in upravljanje kakovosti programske opreme.

    riž. 2.3. Postopek 4. stopnje

    Z uporabo razširjenega metričnega sistema se zbirajo rezultati podrobnih ocen procesa razvoja programske opreme in zagotavljanja kakovosti programskih izdelkov. Izvaja se kvantitativno vrednotenje in kontrola programskih procesov in produktov. Proces upravljanja temelji na objektivnih merilih, oblikovanih za sprejemanje odločitev in ocenjevanje uspešnosti znotraj danih meja.

    Na ravni 5 ("optimizacija") se področja KPA osredotočajo na faze upravljanja tehnoloških sprememb, upravljanja sprememb procesov in preprečevanja napak. Z nenehnim izboljševanjem procesa, kvantitativno Povratne informacije v zvezi s procesom razvoja programske opreme. Na tej ravni je mogoče v organizaciji preizkusiti nove ideje in tehnologije za izboljšanje kakovosti programskega izdelka, kar je shematično prikazano na sl. 2.4.

    riž. 2.4. Postopek 5. stopnje

    Z upravljanimi spremembami obstoječega procesa se uvede organizacijski pristop, ki omogoča nenehno izboljševanje procesa. Organiziranje teh sprememb je pomembno iz naslednjih razlogov:

    1) proces mora biti kulturno pomemben za organizacijo;

    2) vodstvo je dolžno prispevati k dvigu stopnje kulture;

    3) kultura naj spodbuja uvajanje vzornikov in nagrajevanja.

    Če povzamemo, je model CMM nekakšen "načrt", ki zagotavlja uspešno izboljšanje procesa. Njegova interpretacija in uporaba se izvajata v okviru poslovnih ciljev organizacije. Trenutno je v organizacijah, ki se ukvarjajo z razvojem programske opreme, model CMM najpogostejša metoda (in ta trend je značilen za številne države in številna področja uporabe). Ta model je normativen, nepredpisujoč in ga zaznamuje tudi velika meja stabilnosti. Njegov razvoj in podporo izvajajo številni razvijalci, združeni v skupnost strokovnjakov.