Úvod

Nejdůležitější součástí moderních komplexních systémů jsou softwarové produkty – intelektuální složka. Softwarové produkty se dnes používají k řešení problémů řízení téměř ve všech oblastech lidské činnosti: v ekonomice, sociální, vojenské a dalších oblastech. Bezpečnostní Vysoká kvalita domácí softwarové produkty s jejich masový rozvoj a dodávky pro různé aplikace v tuzemsku i na světovém trhu se staly strategickým cílem.

V současné době existují dvě téměř nezávislé oblasti standardizace v softwarovém inženýrství a zajišťování kvality softwarových produktů, které lze podmíněně nazvat profily norem ISO (International Standards Organization) a modely vyspělosti SEI (US Software Engineering Institute). První z nich jsou zcela zastoupeny v [ , ] a druhé - v [ , ]. Hlavní obsah článku je věnován modelům splatnosti.

Aby byla zajištěna konkurenceschopnost ve světě komplexních softwarových produktů a možnost jejich úspěšného exportu, musí být vyvíjeny a certifikovány v souladu s požadavky profily mezinárodních norem na základně ISO 9000:2000 nebo modely zralosti - CMMI:2003(Integrace modelu zralosti schopností – model hodnocení zralosti integrovaného softwarového inženýrství). Tyto dva směry jsou si metodicky velmi blízké a částečně se prolínají vzájemnými odkazy.

Zlepšení technických a ekonomických ukazatelů a kvality softwarových produktů, stejně jako prevence chyb a závad, je zajištěno používáním moderní technologie softwarové inženýrství a systémy počítačově podporovaný design. Jedná se o vysoce výkonné, zdroje šetřící technologie pro vytváření softwarových komplexů vysoké kvality, spolehlivosti a bezpečnosti, zaměřené na snížení celkových nákladů na zdroje pro návrh, implementaci a údržbu softwarových nástrojů (PS). K tomu je v první řadě nutné použít metody a nástroje pro analýzu a návrh, poskytující od počátku konkretizaci a co nejpřesnější reprezentaci cílů, účelů a funkcí. životní cyklus(LC) PS a zamezení šíření případných systémových závad do dalších fází vývoje. Takové technologie softwarového inženýrství umožňují eliminovat nebo výrazně snížit úroveň systémových, algoritmických a softwarových chyb v softwarových produktech přenášených do provozu. Kromě toho jsou účinné při úpravě a údržbě PS a také při změnách vnějšího prostředí.

Pro certifikaci kvality, spolehlivosti a bezpečnosti používání složitých, kritických systémů jsou softwarové produkty v nich používané podrobeny osvědčení certifikovaná, problémově orientovaná testovací centra nebo laboratoře. Takové testy by se měly provádět, když programy řídí složité, kritické procesy nebo zpracovávají informace tak důležité, že jejich závady nebo nedostatečná kvalita mohou způsobit značné škody. Certifikační testy by měly prokázat shodu softwarových komplexů s požadavky dokumentace a umožnit jim provoz v mezích změn parametrů vnějšího prostředí studovaných během testů. Tyto typy testů se vyznačují největší přísností a hloubkou kontrol a měli by je provádět specialisté nezávislí na vývojářích a zákaznících (uživatelích).

Základem pro certifikaci by měly být podrobné a efektivní programy a metody pro testování softwarových balíků pro shodu se standardizovanými požadavky zákazníků, speciálně navržené testovací problémy a generátory pro jejich tvorbu, stejně jako vysoká kvalifikace a autorita testerů. Aplikace u podniků-vývojářů softwarových produktů, certifikované systémy kvality pro zajištění životního cyklu PS na základě požadavků ISO 9000:2000 nebo CMMI:2003, garantuje vysokou, udržitelnou kvalitu řízení procesů a produktů jejich životního cyklu a také umožňuje v mnoha případech usnadnit certifikaci finálního softwarového produktu. Klienti komplexních softwarových projektů proto mají tendenci vybírat si implementační dodavatele, kteří mají certifikáty osvědčující jejich aplikaci systémů zajišťování kvality založených na upravených mezinárodních standardech nebo modelech vyspělosti.

Mezery ve výuce metod softwarového inženýrství nechávají široké pole pro libovůli specialistů při posuzování kvality jejich práce, stejně jako pro výskyt četných defektů a chyb v softwarových projektech. Rostoucí složitost a odpovědnost moderních úloh řešených programy, jakož i možné škody z nedostatečné kvality jejich výsledků, výrazně zvýšily relevanci zvládnutí metod pro úplný, standardizovaný popis požadavků na kvalitativní charakteristiky a metody měření. jejich skutečné, dosažené hodnoty v různých fázích životního cyklu softwaru. Potřeba odborníků znát pojmy, definice a metody hodnocení vlastností kvality softwarových produktů prudce vzrostla.

Rychlý nárůst a komplikace softwarových komplexů vede k vytváření velkých programátorských týmů s odbornou dělbou práce, ve kterých je nutné regulovat koordinovanou činnost skupin specialistů na jediném projektu. Sliby vývojářů ve smlouvách o dodání vysoce kvalitního softwaru v dohodnutých termínech často nejsou dodrženy. Často k tomu dochází proto, že zákazník a dodavatel hodnotí úroveň kvality podle různých kritérií, v této otázce se neshodnou a přístup k hodnocení kvality programů není dostatečně formalizován. Kromě toho někdy chybí schopnost správně posoudit zdroje potřebné k dosažení vysoce kvalitních programů. V důsledku toho zůstává kvalita softwarových produktů na mezinárodním trhu často nízká, nespolehlivá a nekonkurenceschopná. Proto je nejdůležitějším problémem při vývoji a aplikaci mnoho moderní systémy je školení a vzdělávání specialistů v oblasti softwarového inženýrství, používání mezinárodních standardů, které přispívají k vysoké kvalitě softwaru a jeho spolehlivému vyhodnocování s hlavním cílem - vytvořit projektové procesy zvládnutelné, a výsledky jsou předvídatelný. Je nutné umět formalizovat požadavky a dosáhnout konkrétních hodnot vlastností kvality fungování a aplikace komplexních softwarových balíků s přihlédnutím k dostupným zdrojům pro zajištění a zlepšení této kvality.

Model splatnosti CMMI - 1.1 zdokonaluje a vylepšuje předchozí modely CMM(viz ), a také částečně zohledňuje základní požadavky stávajících mezinárodních standardů v oblasti správy softwaru. Značná pozornost v CMMI je věnována vývojovým procesům a účtování iterací při změně požadavků zákazníků, jejich návaznosti na funkce, komponenty, testy a projektovou dokumentaci. V poslední době se objevily informace o modernizaci verze SEI verze 2003. CMMI-1.1 na základě nashromážděných zkušeností a zpětné vazby od podniků. V roce 2006 má vydat novou, výrazně vylepšenou verzi modelu CMMI-1.2, po kterém by měla být verze 1.1 vyřazena. Do konce roku 2007 by měli uživatelé přejít na verzi CMMI-1.2, a v budoucnu se stane povinným pro formalizované posuzování kvality (certifikace) podnikové technologie v oblasti softwarového inženýrství. Doba platnosti certifikátu bude omezena na tři roky. Zákazníci a vývojáři velkých softwarových systémů by se měli na tyto změny připravit před oficiálním zveřejněním verze 1.2 SEI.

Struktura a obsah modelu vyspělosti CMMI - 1.1

Dvě možnosti modelu CMMI-1.1 navržený poskytovat kontinuální hodnocení komplexu procesů v určité oblasti vytvoření softwaru popř fázové hodnocení a zlepšování vyspělosti podniku, jakož i organizování životního cyklu programových komplexů obecně. Modelky CMMI poskytovat pomoc specialistům při organizaci a vylepšování jejich produktů, jakož i při zefektivňování a obsluze procesů vývoje a údržby PS. Koncepce těchto modelů pokrývá řízení a hodnocení vyspělosti komplexních systémů, softwarové inženýrství, ale i procesy tvorby integrovaných softwarových produktů a zlepšování jejich vývoje. Komponenty kontinuálních a fázovaných modelů jsou do značné míry podobné a lze je vybrat a aplikovat v různém složení a pořadí použití v závislosti na vlastnostech a charakteristikách konkrétních projektů.

Možnosti popisu modelu jsou sestaveny podle jediného schématu, které zahrnuje obecné části:

• úvodní slovo;
• 1 oddíl - úvod;
• Sekce 2 - model součásti;
• Sekce 3 - terminologie;
• Sekce 4 - obsah úrovní a hlavní součásti každé verze modelu (vývoj cílů a postupů);
• Sekce 5 - struktura interakce procesů; jsou popsány čtyři kategorie procesů v části 7, jejich obecný přehled a schémata interakce procesů CMMI:
  • řízení procesu;
  • management - projektové řízení;
  • strojírenská technologie);
  • Podpěra, podpora;
• Část 6 – Použití modelu CMMI- stručná doporučení pro uživatele k aplikaci modelu a školení; je zaznamenána kompatibilita a soulad modelových procesů s regulovanými procesy předchozího modelu CMM v částech 2 a 3 normy ISO 15504.
• Sekce 7 je poslední, největší v každé normě, zabírá asi 500 stran z celkového dokumentu, což je přes 700 stran. Tato část poskytuje podrobná doporučení pro implementaci každého z procesů v ní uvedených, která zohledňují vlastnosti konkrétního modelu.

První možnost(kontinuální) model odráží dokument: Capability Maturity Model Integration (CMMI) pro systémové inženýrství/softwarové inženýrství/integrovaný vývoj produktů a procesů, verze 1.1, průběžná reprezentace (CMMI-SE/SW/IPPD, V1.1, kontinuální). Integrované systémové inženýrství/Softwarové inženýrství/Integrované produkty a model hodnocení zralosti procesu vývoje – nepřetržitý pohled. V tomto modelu se sedmá sekce skládá z procesů:

• řízení procesu:
  • organizace školení;
  • organizace transformace (změn) procesů;
  • organizování inovací a expanzí;
• projektový management:
  • plánování projektu;
  • monitorování a kontrola projektových procesů;
  • Řízení rizik;
  • kvantitativní projektové řízení;
• strojírenská technologie):
  • řízení požadavků;
  • vývoj požadavků;
  • technická řešení;
  • integrace produktu;
  • ověření;
  • validace (atestace, schválení);
• Podpěra, podpora:
  • správa konfigurace;
  • analýza a rozhodování o změnách;
  • analýza hlavních příčin a řešení problémů (odstranění závad).

Pět příloh uvádí:

ALE- skladba použitých literárních pramenů a dokumentů, která však neuvádí normy ISO;

V- zkratky;

Z- terminologie založená na slovníku ISO používá se pouze ve čtyřech normách ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D - popisy požadavků a návrhy na tvorbu komponent modelu podle úrovní vyspělosti;

E - seznam účastníků rozvoje CMMI- projekt.

V tomto modelu je pozornost zaměřena na organizační procesy, na plánování, řízení a řízení procesů implementace softwarových projektů, na vývoj a řízení požadavků na softwarové produkty. Níže jsou uvedeny příklady podrobností v CMMI někteří z nich.

Plánování projektu v tomto i ve druhém modelu zahrnuje:

• posouzení možné velikosti (měřítka) softwarového produktu;
• posouzení komplexnosti funkcí a charakteristik projektu PS;
• definice modelu a fází životního cyklu softwarového balíku;
• studie proveditelnosti projektu - stanovení ceny, pracnosti a délky životního cyklu rozvodny;
• vypracování harmonogramu práce po etapách a rozpočtu projektu;
• analýza, identifikace a hodnocení rizik projektu;
• plánování a řízení dokumentace procesů a produktů v životním cyklu projektu PS;
• plánování a rozložení technických a lidských zdrojů podle etap životního cyklu PS;
• plánování zajištění znalostí a kvalifikace týmu specialistů pro realizaci projektu;
• zobecnění a analýza souboru plánů pro projekt PS;
• koordinace prací a zdrojů pro etapy životního cyklu developerem se zákazníkem projektu PS;
• dokumentování plánu práce a jeho schválení vedoucím projektového vývojáře.

Procesy vývoje požadavků k softwarovému produktu jsou podobné procesům v obou modelech a zahrnují:

• identifikace skutečných potřeb zákazníka a uživatelů na funkce a vlastnosti softwarového produktu;
• vývoj a koordinace mezi zákazníkem a vývojářem počátečních, základních požadavků na funkce softwarového produktu;
• určení dostupných zdrojů a omezení projektu softwarové sady;
• rozklad základních výchozích požadavků na funkce PS na soubor požadavků na komponenty a testy softwarového balíku;
• formalizace požadavků na rozhraní mezi komponentami, s operačním a vnějším prostředím;
• vývoj koncepce softwarového produktu a scénářů jeho použití;
• vývoj požadavků na zobecněné charakteristiky funkční vhodnosti a využití funkcí softwarového produktu k jeho zamýšlenému účelu.

Správa požadavků oba modely obsahují:

• dosažení jednoznačného pochopení požadavků na projekt PS ze strany zákazníka a vývojářů;
• získání povinností zákazníka od vývojářů splnit všechny jeho požadavky na softwarový produkt;
• řízení změn požadavků na projekt PS dohodnutých mezi zákazníkem a developerem;
• zajištění správnosti změn od obecných požadavků na projekt PS k požadavkům na komponenty a jednotlivé procesy;
• identifikaci a identifikaci nesrovnalostí mezi procesy vývoje projektu a požadavky zákazníků.

Druhá možnost předkládá dokument: Capability Maturity Model Integration (CMMI) pro systémové inženýrství/softwarové inženýrství/integrovaný vývoj produktů a procesů, verze 1.1, etapová reprezentace (CMMI-SE/SW/IPPD, V1.1, Staged). Integrované systémové inženýrství/Softwarové inženýrství/Integrované produkty a model hodnocení zralosti procesu vývoje – fázované zavedení. Model je založen na zachování konceptu pěti úrovní zralosti CMM[ , ]. Složení procesů prakticky opakuje to, co bylo uvedeno výše pro první verzi modelu, ale v trochu jiném sledu a s relativně malými doplňky.

První úroveň se vyznačuje výraznou nejistotou ve skladbě a obsahu procesů v různých relativně jednoduchých projektech, proto není v dokumentu komentována. Proto při objasňování a upřesňování obsahu procesů ve fázované verzi CMMI doporučuje se omezit čtyři hlavní úrovně:

• druhý stupeň- formalizuje základní management projekty:
  • řízení požadavků;
  • plánování projektu;
  • monitorování a kontrola projektů;
  • správa dohod s dodavateli;
  • měření a analýza procesů a produktů;
  • zajištění kvality procesů a produktů;
  • správa konfigurace;
• třetí úroveň- obsahuje standardizaci hlavních procesů:
  • vývoj požadavků;
  • technická řešení;
  • integrace produktu;
  • ověření;
  • validace (certifikace);
  • obsah organizačních procesů;
  • definice organizačních procesů;
  • organizace školení;
  • integrované řízení projektových procesů a produktů;
  • Řízení rizik;
  • integrace vývojového týmu;
  • integrované řízení dodavatelů;
  • analýza a řešení problémů (odstranění závad);
  • organizace prostředí pro integraci;
• čtvrtá úroveň- definuje kvantitativní řízení:
  • organizace reprezentace kvality procesů;
  • kvantitativní řízení celého projektu a zdrojů;
• pátá úroveň- optimalizace, neustálé zlepšování:
  • organizace, inovace, kvantitativní řízení procesů a poskytování zdrojů;
  • analýza příčin závad, zlepšování kvality a řízení procesů a produktů.

Aplikace ve druhé verzi modelu jsou složením podobné výše uvedeným aplikacím pro první model. Doporučuje se aplikovat na každém vyšším stupni zralosti všechny procesy předchozí nižší úrovně. V obou verzích modelu je každý výše zvýrazněný základní proces okomentován podrobnými doporučeními pro jeho praktickou implementaci, která obsahují strukturálně sjednocené popisy na cca 20–30 stran:

• celkové cíle procesu, kterého má být dosaženo;
• úvodní poznámky a obecný popis funkcí procesu;
• specifické cíle procesu;
• řízení procesu;
• vývoj požadavků na proces;
• interakce a rozhraní s jinými procesy;
• praktické cíle - požadované výsledky činností procesu;
• plánování akcí v konkrétním procesu;
• analýza a validace (schvalování) výsledků implementace procesu;
• monitorování a kontrola procesu.

Tato doporučení z hlediska rozsahu, obsahu a úplnosti popisů základních procesů jsou podobná řadě norem pro Profil životního cyklu PS prezentovaných v. Řazení a hodnocení úplnosti používaných procesů v souladu s úrovněmi vyspělosti umožňuje stanovit produkční potenciál podniků - vývojářů softwarových produktů z hlediska predikované kvality procesů a výsledků jejich činnosti a připravenosti k certifikaci pro soulad s určitou úrovní vyspělosti modelu CMMI - 1.1.

Důraz na modely CMMI je dán řídícím procesům projektu PS. Tyto požadavky a procesy modelů prakticky odpovídají regulovaným a podrobným doporučením v normách. ISO 9001:2000 a hlavní složky profilu komplexních standardů životního cyklu PS [ , ]. Požadavky na procesy ve funkčních částech 4-8 norem ISO 9001, ISO 9004, ISO 90003 v modelu lze porovnat řadu obsahově adekvátních oddílů CMMI(na obr. 1 zóna překrytí obsahu). Shodnost procesů a požadavků spočívá v podobnosti: složení, terminologie, struktura, seznam doporučených procesů řízení, plánování, účtování dostupných zdrojů, implementace procesů softwarového inženýrství, hodnocení a organizace specialistů.

Obrázek 1. Shodnost procesů a požadavků standardů a modelů vyspělosti

Z hlediska podpory a regulace celého životního cyklu velkých softwarových projektů nedostatky modelů CMMI o profilu stávajících norem ISO může zahrnovat následující:

Byla vypracována rozsáhlá technická zpráva, která byla původně schválena v roce 1998, aby určila úrovně vyspělosti procesů pro zajištění životního cyklu PS uvedených výše. ISO 15504, skládající se z devíti částí a mnoha aplikací. Nastiňuje model zralosti CMM a osm základní principy softwarové inženýrství založené na standardu ISO 9000:2000. Pak dovnitř ISO tento dokument prošel radikální revizí, redukcí, zjednodušením struktury a obsahu při plném zachování cílů a koncepce a schválen jako standard v pěti dílech.

Standard ISO 15504:1-5:2003-2006 upravuje posuzování a certifikaci vyspělosti procesů tvorby, údržby a zlepšování softwarových nástrojů a systémů prováděných podniky:

• nastolit stát vlastní technologické procesy a jejich zlepšování;
• určit vhodnost vlastních procesů pro splnění specifických požadavků nebo tříd zákaznických požadavků;
• s ohledem na jeho vhodnost pro výkon určité smlouvy se zákazníky PS a systémů.

Norma přispívá k: sebehodnocení vyspělosti podniků, zajištění adekvátního řízení atestovaných procesů, stanovení profilu hodnocení procesů a také vyhovuje jakémukoli rozsahu a velikosti OS a systémů. Aplikace normy je zaměřena na rozvoj podniků a odborníků kultura neustálého zlepšování technologická vyspělost zajištění životního cyklu PS splňující obchodní cíle projektů a optimalizace využití dostupných zdrojů. Posouzení vyspělosti podnikových procesů poskytuje příležitost je porovnat a vybrat je, které jsou pro určité projekty vhodnější:

• pro zákazníky, nákupčí, uživatele softwarových produktů a systémů: schopnost určit aktuální a potenciální vyspělost procesů životního cyklu dodavatele;
• pro dodavatele a vývojáře: schopnost určit současnou a potenciální vyspělost jejich vlastních procesů životního cyklu softwaru a systémů, oblastí a priorit pro zlepšování procesů;
• pro posuzovatele imatrikulací: rámec pro provádění a zlepšování procesů hodnocení.

Schválení v normě je řešeno v dva aspekty: zlepšit procesy životního cyklu PS a systémů konkrétního podniku a zjistit, zda deklarovaná vyspělost projektů nebo procesů podpory podniku odpovídá skutečně používaným procesům. To se odráží v následujících pěti částech normy. ISO 15504:1-5:2003-2006.

Část 1 - Pojem a slovní zásoba. Obsahuje obecné informace o procesech certifikace vyspělosti softwaru a systémů a doporučení pro použití částí normy. Nastíněno Obecné požadavky pro certifikaci, terminologii, strukturu je určen rozsah zbývajících částí normy.

Část 2 - Výkon (výroba) certifikace. Obsahuje podrobné požadavky na provádění certifikačních procesů jako podkladu pro zlepšování a stanovení úrovně vyspělosti technologických procesů pro zajištění životního cyklu PS a systémů. Dokument definuje procesy pro provádění atestace, modely pro doporučené procesy pro atestaci a ověřování procesů tak, aby byly objektivní, smysluplné a reprezentativní.

Část 3 - Návod na výrobu certifikace. Poskytuje přehled o technologii pro provádění procesů posuzování zralosti a interpretaci implementace požadavků. Odráží: výkon certifikace; měřicí nástroje pro určování procesů zralosti; výběr a použití certifikačních nástrojů; posuzování způsobilosti certifikátorů; ověření shody atestace s deklarovanými požadavky. Validační nástroje mohou podniky využívat při plánování, správě, monitorování, kontrole a zlepšování softwarových produktů a systémů, při jejich získávání, vývoji, aplikaci a údržbě.

Část 4 – Uživatelský návod pro zlepšování procesů a vyspělost procesů v těchto dvou aspektech. Doporučuje se řada kroků, které zahrnují: použití výsledků validačních procesů; stanovení cílů pro hodnocení zralosti; stanovení počátečních údajů pro certifikaci; posouzení možného snížení výsledných rizik; kroky ke zlepšení procesů; kroky k určení úrovně zralosti; porovnání výsledků kvalifikační analýzy s požadavky.

Část 5 - Vzorový model atestačních procesů pro shodu s požadavky uvedenými v části 2. Rozsáhlý dokument (162 stran) poskytuje praktické příklady předchozích částí standardu pro organizování, hodnocení a zlepšování hodnocení zralosti procesů životního cyklu pro různé aplikační oblasti, softwarové projekty a podniky.

Při praktické realizaci projektů a zajištění životního cyklu komplexního softwaru je někdy pro vývojáře a dodavatele obtížné identifikovat a vyzdvihnout výhody modelů pro aplikaci. CMMI. V závislosti na tradicích podniku a vlastnostech velkého projektu je často vhodné použít PS jako hlavní plný standardní profilISO a pro hodnocení zákazníků úroveň zralosti management, organizační a technologická podpora projektů PS uplatňují konkrétní doporučení CMMI. Tyto pokyny lze efektivně využít v certifikace kvality procesu u podniků zajišťujících životní cyklus PS, alternativně nebo spolu s certifikací podle souboru norem managementu ISO 9000, v závislosti na specifikách projektu a požadavcích žadatele o certifikaci softwarového produktu nebo technologie pro zajištění jeho životního cyklu.

Organizace certifikace softwarových produktů

Certifikace se skládá z řady organizačních procesů, které tvoří certifikačního systému, tyto procesy jsou podpořeny regulovanými postupy a dokumenty a musí je provádět kvalifikovaní, certifikovaní odborníci - inspektoři. Pro certifikaci podniku-vývojáře a výsledků jeho činnosti - softwarové produkty, modely CMMI nebo standardní profily ISO[ , ] je doporučena určitá disciplína, která by měla být přizpůsobena specifickým vlastnostem objektů a prostředí životního cyklu PS. Níže uvedené procesy a dokumenty jsou určeny pro velké projekty a v jednodušších případech mohou být omezeny dohodou mezi vývojáři, zákazníky a certifikačními společnostmi.

Certifikační práce začíná akreditací orgánu nebo zkušební laboratoře, vytvořením a předložením žádosti a souboru dokumentů Centrálnímu certifikačnímu orgánu k rozhodnutí o proveditelnosti akreditace. Pokud jsou výsledky testů pozitivní, je vystaveno a vystaveno osvědčení o akreditaci.

Předpisy o certifikačním orgánu nebo laboratoři je hlavním dokumentem, který stanoví předmětnou oblast akreditace, právní postavení, funkce, strukturu, práva a povinnosti, způsoby, prostředky a organizaci zkoušek. Pas certifikační laboratoře (střediska) musí obsahovat informace o zařízení počítačová věda nezbytné pro testování, na personální a personální vybavení, vybavení testovacími nástroji, zajištění regulačních, technických a metodických dokumentů, jakož i dalších prostředků nezbytných pro testování.

Kvalitní průvodce obsahuje prohlášení o zásadách, popis metod a postupů spojených s prováděním hlavních funkcí a úkolů certifikačního orgánu nebo laboratoře, zajištění kvality zkoušek a důvěry ve výsledky hodnocení, zkoušek a přezkoušení. Příručka kvality obvykle obsahuje části [ TWLSC$

• politika v oblasti zajišťování kvality testování a zkoušek;
• vybavení centra příslušnými metodickými materiály a softwarem a testovacími nástroji;
• formalizace požadavků na testovací objekty;
• politika v oblasti technického vybavení střediska a rozvoje zaměstnanců;
• archivace a bezpečnostní kontrola dokumentace výsledků certifikace.

Pro hodnocení výrobků nebo procesů podléhajících certifikaci žadatel zasílá žádost certifikačnímu orgánu ve formě přijaté v certifikačním systému. Certifikační orgán provádí práce na přípravě a organizaci certifikace produktu na základě žádosti. Tato práce zahrnuje:

• výběr certifikačního schématu s přihlédnutím ke specifikům produktů (objem, technologie, požadavky regulačních dokumentů atd.) a návrhům vývojáře;
• stanovení počtu a pořadí odběrů vzorků a zkoušených složek, pokud to není stanoveno v normách;
• výběr a identifikace akreditované zkušební laboratoře pro provádění zkoušek;
• příprava návrhu smlouvy o provedení práce.

Přípravná část práce na certifikaci končí vydáním rozhodnutí ve formě přijaté v certifikačním systému. Rozhodnutí je spolu s návrhem smlouvy o provedení práce zasláno žadateli. Při organizaci certifikačních zkoušek, výběru a studiu aktuálních regulačních dokumentů pro výrobky deklarované k certifikaci se provádějí metody zkoušení a vyhodnocování výsledků.

Žadatel činí konečná rozhodnutí, které prvky systému jakosti, oblasti a druhy organizačních a technických činností podléhají ověřování při certifikaci v daném časovém intervalu. Žadatel musí vytvořit podmínky a předložit doklady k zajištění ověřovacích procesů. Certifikačnímu orgánu může předkládat protokoly o zkouškách provedených při vývoji a výrobě výrobků, doklady o zkouškách provedených cizími zkušebnami a další doklady prokazující shodu technologie nebo výrobků se stanovenými požadavky. Certifikační orgán může na základě analýzy doložených dokladů o shodě svých výrobků se stanovenými požadavky předložených k žádosti rozhodnout o omezení rozsahu zkoušek nebo o vydání certifikátu.

Zkoušky provádějí zkušební laboratoře akreditované k provádění pouze těch zkoušek, které jsou uvedeny v jejich regulačních akreditačních dokumentech. Není-li možné provést zkoušky na zkušebně akreditované laboratoře, mohou zkoušky provést pracovníci této laboratoře u výrobce nebo spotřebitele tohoto výrobku s využitím vlastních zařízení zkušebny nebo zkušebních zařízení dostupných u dodavatele. .

Proces certifikace softwarových produktů a podnikových systémů kvality zahrnuje:

• analýza a výběr vývojářem nebo zákazníkem (žadatelem) orgánu kompetentního v této oblasti a certifikované laboratoře k provádění certifikačních zkoušek;
• předložení žádosti o přezkoušení žadatelem certifikačnímu orgánu a přijetí rozhodnutí o žádosti certifikačními orgány, výběr certifikačního schématu, uzavření certifikační dohody;
• identifikace požadavků na podnikový systém jakosti a/nebo na verzi softwarového produktu, který má být testován;
• provádění certifikačních testů systému jakosti společnosti nebo verze softwarového produktu certifikační laboratoří;
• analýza získaných výsledků a rozhodování laboratoře a/nebo certifikačního orgánu o možnosti vydání certifikátu shody žadateli;
• vydává certifikační orgán žadateli - certifikát a licenci k užívání značky shody a vydávání certifikovaných produktů - verze softwarového produktu;
• provádění inspekční kontroly certifikačním orgánem certifikovaného systému jakosti podniku a/nebo výrobků;
• provedení nápravných opatření žadatelem v případě porušení shody procesů systému jakosti a/nebo výrobků se stanovenými požadavky a v případě nesprávného použití značky shody.

Při kontrole odpovědnosti vedení vývojáře za kvalitu produktu by mělo být stanoveno, že podnik nebo projekt má zdokumentovanou politiku, cíle a závazky v oblasti kvality, jakož i míru, do jaké je tato politika chápána, implementována a udržována. v provozuschopném stavu na všech úrovních organizace. Mělo by být stanoveno, že podnik má zástupce vedení, který má bez ohledu na jiné povinnosti pravomoc a odpovědnost za průběžné provádění požadavků norem a regulačních dokumentů systému jakosti. Měla by být kontrolována dostupnost požadavků, postupů, nástrojů a vyškoleného personálu pro praktickou implementaci procesů systému jakosti, stejně jako relevance a systematická dokumentace všech součástí, požadavků a ustanovení systému jakosti, což je integrovaný proces v celém životní cyklus PS. Kontroly systému jakosti by měla obsahovat definici:

• dostupnost a úplnost technologické dokumentace a plnění jejích požadavků v praxi;
• stav technologických zařízení a dostupnost systému pro jejich údržbu;
• existence a účinnost systému kontroly a testování;
• stav měřicích a zkušebních přístrojů;
• dostupnost systému pro identifikaci a odstranění zjištěných nedostatků v produktech nebo technologii.

Na základě zkoušek jsou vyhodnoceny získané výsledky a zdůvodněny závěry o shodě či neshodě výrobků nebo procesů s požadavky regulačních dokumentů. Protokoly o zkouškách se předkládají certifikačnímu orgánu a také žadateli na jeho žádost. Protokoly o zkouškách podléhají uchovávání po dobu stanovenou v pravidlech systémů certifikace výrobků a v dokumentech zkušební laboratoře, nejméně však tři roky.

Po obdržení a kontrole úplnosti a kvality dokumentace by měli provést odborníci zkušebny prověření míry skutečného uplatňování systému jakosti v podniku. Testování začíná vývojem programu testování systému jakosti, který by měl sloužit jako pracovní plán pro následnou práci. Program je interním pracovním dokumentem zkušebny a měl by obsahovat soupis prací, podrobně rozepsaný v souladu se specifiky developerského podniku, včetně analýzy úplnosti a kvality předložených podkladů a míry jejich praktické aplikace. při návrhu, vývoji a dodání softwaru. Přezkoumání uplatňování postupů systému jakosti provádí zkušební laboratoř na pracovištích podniku, který zajišťuje životní cyklus PS. Jsou prováděny kontroly přítomnosti specialistů-tvůrců příslušných dokumentů na pracovišti a úplnosti využívání jejich ustanovení a doporučení. Přezkoumání stavu projektu a interní audity systému jakosti, procesů a/nebo produktů by měli provádět pracovníci nezávislí na osobách přímo odpovědných za provádění těchto prací.

Metody kontroly kvality vývoje by měly být poskytnuty potřebné zdroje pro implementaci testovacího programu, metod plánování a vývoj soukromých testovacích procedur. Metody by měly obsahovat: objekty a cíle testování; hodnocené ukazatele kvality; podmínky a postup testování; metody zpracování, analýzy a vyhodnocení výsledků zkoušek; technická podpora testování a podávání zpráv. Měl by být uveden hardware a software použitý během zkoušek a zkušebního postupu, jakož i očekávané výsledky kontrol. Měly by být vyvinuty metody pro kontrolu oprav, opatření k nápravě závad, pokud takový požadavek obdrží služba řízení auditu. Služba správy testovacího programu by měla zavést postupy pro zachování důvěrnosti jakýchkoliv testovacích informací, jakož i dat uchovávaných hodnotiteli.

Testovací zprávy předloženy žadateli a certifikačnímu orgánu. Žadatel může certifikačnímu orgánu předložit protokoly o zkouškách s přihlédnutím k lhůtám jejich platnosti, provedených při vývoji a výrobě výrobků, nebo doklady o zkouškách provedených tuzemskými nebo zahraničními zkušebnami akreditovanými nebo uznanými v certifikačním systému. Na základě protokolů certifikačních zkoušek jsou vyhodnoceny získané výsledky a zdůvodněny závěry o shodě či neshodě výrobků s požadavky regulačních dokumentů.

Závěr o výsledcích certifikačních zkoušek je vyvinut certifikačními orgány a obsahuje zobecněné informace o výsledcích testů a zdůvodnění vydání certifikátu. V případě získání negativních výsledků certifikačních zkoušek je rozhodnuto o odmítnutí vydání certifikátu shody. Po dokončení certifikovaného výrobku nebo systému jakosti lze zkoušky opakovat. Výsledky analýzy stavu technologie nebo kvality produktu jsou vypracovány aktem, která uvádí odhady pro všechny pozice Zkušebního programu a obsahuje závěry včetně obecného posouzení stavu výroby a výrobků, potřeby nápravných opatření. Zákon slouží certifikačnímu orgánu spolu se zkušebními protokoly, žádostí o vydání a stanovení doby platnosti certifikátu pro softwarový produkt, četnosti inspekční kontroly a také pro vypracování nápravných opatření.

Na základě výsledků certifikačních zkoušek a přezkoumání dokumentace je rozhodnuto o vydání certifikátu. V případě získání negativních výsledků certifikačních zkoušek je rozhodnuto odmítnutí vydání osvědčení dodržování. Kromě toho lze žádajícímu podniku zaslat návrhy na odstranění údajných příčin negativních výsledků testů, po dokončení certifikovaných výrobků lze testy opakovat.

Certifikační orgán po rozboru protokolů o zkouškách, vyhodnocení výroby, certifikaci systému jakosti, rozboru dokumentace uvedené v rozhodnutí o žádosti, posoudí shodu výrobků se stanovenými požadavky, vystaví certifikát na základě posudku odborníků a zaregistruje to. Při provádění změn v projektové nebo provozní dokumentaci, které mohou ovlivnit kvalitu systému nebo softwarového produktu certifikovaného při certifikaci, musí žadatel tuto skutečnost oznámit certifikačnímu orgánu, aby mohl rozhodnout o potřebě dodatečných zkoušek. Po registraci certifikát vstoupí v platnost a je zaslán žádající společnosti. Současně s vydáním certifikátu může být vydán žádající podnik licence za právo používat značku shody.

U certifikovaných softwarových produktů po dobu jejich provozu po celou dobu platnosti certifikátu shody, inspekční kontrola. Inspekční kontrola se provádí formou periodických a neplánované kontroly dodržování požadavků na kvalitu technologie a certifikovaných výrobků. Předmětem kontroly v závislosti na certifikačním schématu jsou certifikované produkty, systém jakosti nebo stabilita produkce vývojky. Při určování četnosti a rozsahu kontroly se berou v úvahu tyto faktory: míra potenciální nebezpečnosti softwarového produktu, stabilita výroby, objem uvolnění, dostupnost a aplikace systému jakosti při vývoji, informace o výsledcích zkoušek výrobku a jeho výroby provedených výrobcem, orgány státní kontroly a dozoru.

Výsledky inspekční kontroly jsou vypracovány aktem, která vyhodnocuje výsledky zkoušek vzorků a dalších kontrol, činí obecný závěr o stavu výroby certifikovaných výrobků a možnosti zachování platnosti vydaného certifikátu. Zákon je uložen v certifikačním orgánu a jeho kopie jsou zasílány zpracovateli a organizacím, které se účastnily inspekční kontroly. Na základě výsledků inspekční kontroly může certifikační orgán pozastavit nebo zrušit platnost certifikátu a odejmout licenci na právo používat značku shody v případě neshody výrobků s požadavky regulačních dokumentů kontrolovaných při certifikaci. a také v následujících případech:

• zásadní změny v modelu splatnosti, profilu norem, výrobkových předpisech nebo zkušební metodě;
• změny v designu (složení), kompletnost výrobků;
• změny v organizaci nebo technologii vývoje a výroby;
• nesouladu s požadavky technologie, způsobů kontroly a zkoušení, systému jakosti, pokud uvedené změny mohou způsobit nesoulad výrobků s požadavky kontrolovanými při certifikaci.

Rozhodnutí o pozastavení platnosti certifikátu a licence pro právo užívat značku shody není přijato, pokud prostřednictvím nápravných opatření dohodnutých s certifikačním orgánem, který je vydal, může žadatel odstranit zjištěné příčiny neshody a potvrdit , bez opětovného testování v akreditované laboratoři, shodu výrobku nebo procesů s normativními dokumenty. Pokud to nelze provést, je platnost certifikátu zrušena a licence na právo užívat značku shody je zrušena. Informaci o pozastavení nebo zrušení certifikátu podává žadateli, spotřebitelům a dalším zainteresovaným organizacím certifikační orgán, který jej vydal. Platnost certifikátu a právo označovat výrobky značkou shody lze obnovit, pokud developerský podnik splní následující podmínky:

• identifikace příčin nesouladu a jejich odstranění;
• předložení zprávy certifikačnímu orgánu o práci vykonané pro zlepšení a zajištění kvality produktu;
• provádění dalších zkoušek výrobků podle metod a pod kontrolou certifikačního orgánu a získávání pozitivních výsledků.

Dokumentace procesů a výsledků certifikace softwarových produktů

Složení a obsah dokumentace pro certifikaci systému jakosti podniky závisí na vlastnostech návrhu, vývoje a modifikace softwaru, jakož i na požadavcích na jejich kvalitu a vlastnostech technologického prostředí. Proto by měl být pro každý podnik nebo projekt vybrán a přizpůsoben potřebný soubor dokumentů ve vztahu k těmto charakteristikám. Ukazateli systému kvality hodnocenými při certifikaci jsou dostupnost relevantních dokumentů a praktické plnění požadavků určité úrovně modelu vyspělosti. SMMI nebo upravený profil norem založený na ISO 9000:2000, jakož i vytvořené na jejich základě, popis práce specialisty podnikového vývojáře. Žadatel musí připravit a předložit zkušební laboratoři soubor dokumentů dohodnutých mezi zákazníkem a vývojářem a schválených k ověření jejich spolehlivosti, dostatečnosti složení a provedení v souladu s regulačními dokumenty.

Orientační soubor základních dokumentů pro certifikaci se skládá ze tří skupin:

• základní předpisy systémy jakosti v souladu s nomenklaturou a obsahem profilu norem na základě ISO 9000:2000 nebo modely zralosti SMMI, jakož i program, manuál a pokyny připravené vývojáři na jejich základě, předložené testerům (odborníkům) systému jakosti nebo produktů auditovaného podniku;
• zdrojové dokumenty charakterizující konkrétní podnik nebo projekt, jakož i životní cyklus softwarového nástroje, připravené vedením projektu k certifikaci jeho kvality;
• reportovací dokumenty testerů odrážející výsledky auditu (certifikace) podnikového systému jakosti a/nebo softwarového produktu předložené certifikačnímu orgánu, žadateli a vedení auditovaného podniku.

Softwarový produkt nebo podnikový systém kvality předložený k certifikaci musí být předložen spolu s příslušnou dokumentací. Výčet a přibližný obsah skupin těchto dokumentů je zaměřen na obecný případ kontroly systémů jakosti podniků, které zajišťují životní cyklus velkých softwarových produktů. Soubor dokumentů může být omezen a upraven podle dohody mezi žadatelem, certifikačním orgánem a vedením auditovaného podniku v souladu s charakteristikami softwarových projektů. Některé dokumenty lze kombinovat do integrovaných zpráv s jasnou odpovědností určitých specialistů za jejich implementaci.

Základní dokumenty podnikového systému jakosti a životního cyklu softwaru

1. Koncepce, terminologie, požadavky a návod pro zlepšování výkonnosti - systémy managementu kvality - ISO 9000:2000 nebo verze modelu vyspělosti CMMI.
2. Upravené verze nebo seznam oddílů a doporučení norem ISO 12207, ISO 15504, jejich změny a aplikační směrnice, vybrané při adaptaci a závazné pro použití v systému jakosti konkrétního podniku nebo projektu softwarového produktu.
3. Upravená verze nebo seznam oddílů a doporučení normy ISO 900003, vybrané při adaptaci a povinné pro použití v systému jakosti podniku vyrábějícího softwarový produkt.
4. Základní charakteristiky a kvalitativní atributy projektu PS, identifikované, upravené a specifikované na základě norem ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Upravená verze a schválené vydání příručky pro správu údržby a konfigurace na základě doporučení norem ISO 14764, ISO 10007, ISO 15846.
6. Soubor popisů práce, které definují odpovědnost, pravomoc a postup pro interakci všech řídících, vykonávajících a kontrolujících práci pracovníků zapojených do postupů podnikového systému jakosti pro konkrétní projekt PS.

Zdrojové dokumenty odrážející vlastnosti životního cyklu konkrétního softwarového nástroje

1. Popis charakteristik softwarových produktů vytvářených v podniku, systému a vnějšího prostředí jejich životního cyklu, nezbytných pro přizpůsobení a přípravu pracovních verzí norem a požadavků projektu PS a podnikového systému kvality v souladu s tzv. doporučení norem ISO 12207, ISO 15504, ISO 90003 a ISO 9126.
2. Popis cílů, požadavků a povinností podniku-vývojáře v oblasti systému jakosti, kritérií kvality procesů a produktů vývoje, dodávky a podpory celého životního cyklu softwaru.
3. Soubor provozních dokumentů dodávaných zákazníkovi a uživatelům k zajištění životního cyklu a používání konkrétní verze softwarového produktu na základě upravených standardů ISO 9294, ISO 15910, ISO 18019.
4. Dokumentační a automatizační nástroje pro návrh, vývoj, úpravy, řízení a testování používané k zajištění životního cyklu softwarového produktu.
5. Plány a metody testování aplikace a hodnocení účinnosti procesů systému jakosti podniku a softwarového produktu.
6. Způsoby údržby, identifikace komponent a dokumentace softwarových produktů, analýza a schvalování verzí softwaru a datových komplexů.
7. Metodika pro správu konfigurací, schvalování, ukládání, ochranu, kopírování verzí softwarových produktů a doprovodných dokumentů, jakož i shromažďování a ukládání dat o kvalitativních charakteristikách evidovaných v podnikovém archivu během životního cyklu verzí softwarových produktů.

Výsledné zkušební dokumenty - certifikace systému jakosti podniku a/nebo softwarového produktu

1. Zpráva o dostupnosti, relevanci a systematickém provádění dokumentace přizpůsobené požadavkům a ustanovením podnikového systému kvality, která poskytuje integrovaný proces zajišťování kvality v průběhu celého životního cyklu softwarového produktu.
2. Výsledky monitorování a testování stavu a aplikace systému jakosti, prováděné periodicky za účelem zjištění jeho vhodnosti a účinnosti.
3. Zpráva o dostupnosti a udržování metod provádění kontrol a doložené zprávy o výsledcích dosahované kvality plnění požadavků certifikační smlouvy se zákazníkem.
4. Výsledky evidence dosažených kvalitativních znaků softwarového balíku: identifikace, shromažďování, ukládání evidovaných údajů o vlastnostech a atributech kvality softwarového produktu a jeho součástí.
5. Výsledky realizace plánu rozvoje, doložené vstupní a výstupní údaje vývojových etap a protokoly pro kontrolu realizace životního cyklu PS.
6. Výsledky praktické realizace programu jakosti a realizace regulovaných činností v oblasti jakosti ve všech fázích životního cyklu PS.
7. Výsledky certifikace simulátorů prostředí a testovacích generátorů, jakož i posouzení jejich dostatečnosti pro provádění certifikačních testů softwarového produktu.
8. Výsledky rozborů realizace plánů a zkušebních metod, protokoly o zkouškách, posouzení souladu výsledků zkoušek s požadavky, jakož i výsledky zkoušek schválené zástupci žadatele, zákazníka a dodavatele.
9. Akt výsledků ověření skutečných charakteristik životního cyklu softwarového systému a systému jakosti podniku, závěry o jejich souladu s požadavky na certifikaci výroby softwarového produktu.
10. Certifikát systému jakosti podniku a/nebo softwarového produktu a zajištění jeho životního cyklu, licence na používání značek shody.

Literatura

V.V. Lipaev -- Profily standardů životního cyklu softwaru. -- Jet Info, Newsletter, N 12, 2005

K. Milman, S. Milman -- SMMI je krokem do budoucnosti. -- otevřené systémy., N 5-6. (2005), N2. (2006), 2005, 2006

Posuzování a certifikace vyspělosti procesů tvorby a údržby softwarových nástrojů a informačních systémů ISO IEC TR 15504-CMMI. Za. z angličtiny -- M.: Kniha a obchod, 2001

V.V. Lipaev -- Procesy a standardy životního cyklu komplexního softwaru. Adresář.-- M.: SINTEG, 2006

V.V. Lipaev -- Metody zajištění kvality rozsáhlého softwaru.-- M.: RFBR. SINTEG, 2003

"; antisource: "Softwarové produkty se nyní používají k řešení problémů řízení téměř ve všech oblastech lidské činnosti: v ekonomice, sociální, vojenské a dalších oblastech. Zajištění vysoké kvality tuzemských softwarových produktů při jejich hromadném vývoji a dodávkách pro různé aplikace v tuzemsku i na světovém trhu se stalo strategickým úkolem."; stav: 1]$

Anotace: Podrobně je studován okruh myšlenek, které jsou základem pravděpodobně nejznámější metodologie zlepšování vývojových procesů. software- SMM. Je analyzována logika a struktura HMM. Je ukázáno spojení mezi HMM a dříve studovanými procesními modely.

Nádherný praktický nástroj vytvořený v rámci procesní přístup k popisu činnosti organizace designu zejména organizace, která se rozvíjí Informační systémy , demonstruje metodiku HMM. CMM je zkratka pro Capability Maturity Model, což zhruba znamená „model vyspělosti systému řízení“. V literatuře je CMM častěji označován jako model organizační zralosti a já se této tradice budu také držet.

Historie vzniku SMM je následující. Na konci 80. let. minulé století, americké ministerstvo obrany objednalo institut softwarového inženýrství 1Eng. SEI - Institut softwarového inženýrství Carnegie Mellon University pracuje na systému kritérií pro výběr subdodavatelů v projektech vývoje softwaru. Práce byly dokončeny v roce 1991 a výsledkem byl CMM. Musíme okamžitě učinit výhradu, že model neobsahuje žádné finanční, ekonomické, politické, organizační výběrová kritéria subdodavatele, stejně jako kritéria pro možnost přijetí k tajné práci (takové úkoly pravděpodobně stanoveny nebyly). Hovoříme pouze o kritériích, která popisují schopnosti potenciálního subdodavatele z hlediska vývoje softwarových systémů.

Struktura CMM

Tvůrci modelu vzali procesy organizace za základ pro hodnocení schopnosti organizace odvádět kvalitní práci, která (schopnost) byla nazývána zralostí. Poté učinili několik netriviálních předpokladů, které byly následně přijaty a uznány za spravedlivé mnoha IT profesionály (a možná většinou z nich).

Předpoklad 1. Existují kvalitativně různé úrovně zralosti organizace designu rozvíjející se Informační systémy(v modelu HMM je pět takových úrovní).

Předpoklad 2. Každá rozvojová organizace má zájem posunout se na vyšší úroveň vyspělosti (nejen proto, aby zvýšila své šance v boji o zakázky ministerstva obrany, ale také aby se zdokonalila).

Předpoklad 3. Přechod je možný pouze do další úrovně v pořadí. Úroveň nelze „přeskočit“ (přesněji současně prudce rostou rizika pro organizaci).

Úrovně tedy tvoří „žebřík“, po kterém organizace stoupá vlastní vývoj. Každá úroveň se vyznačuje určitým složením a vlastnostmi procesů organizace. SMM „Level Ladder“ byl široce přijímán a šířen. Tady je, jak vypadá.

Úroveň 1 "Začátečník". Výrobní proces jako celek je charakterizován jako vytvářený pokaždé pro konkrétní projekt a někdy až chaotický. Je definováno pouze několik procesů a úspěch projektu závisí na úsilí jednotlivců.

Úroveň 2 "Opakovatelné". Byly zavedeny hlavní procesy projektového řízení, které umožňují sledovat náklady, sledovat harmonogram prací a funkčnost vytvářeného softwarového řešení. Zavedl procesní disciplínu potřebnou k replikaci minulých úspěchů v podobných projektech vývoje aplikací.

Úroveň 3 "Určitá". Výrobní proces je dokumentován a standardizován pro oba manažerská práce stejně jako pro design. Tento proces je integrován do standardního výrobního procesu organizace. Všechny projekty používají schválenou přizpůsobenou verzi standardního provozního procesu organizace.

Úroveň 4 "Spravováno". Shromažďují se podrobné kvantitativní ukazatele výrobního procesu a kvality vytvářeného produktu. Výrobní proces i produkty jsou hodnoceny a kontrolovány z kvantitativního hlediska.

Úroveň 5 "Optimalizace". Neustálé zlepšování procesu je dosahováno prostřednictvím kvantitativního zpětná vazba s procesem a implementací pokročilých nápadů a technologií v něm.

Navzdory nedostatku přísnosti výše uvedená definice intuitivně nejčastěji nevyvolává námitky. Zkušení specialisté navíc chápou, proč jsou přechody možné pouze na další úroveň, a také proč stojí za to o takový přechod vůbec usilovat. Model HMM přitom neobsahuje žádné kvantitativní či dokonce formální zdůvodnění takového přístupu, což však neubírá na jeho přednosti.

Dále, jak se říká, je to otázka technologie. Je definována struktura modelu (obrázek 7.1), jsou uvedeny definice a začíná pečlivá práce s přesným popisem každého procesu na každé úrovni. Abychom mohli posoudit praktickou hodnotu toho, co bylo uděláno, projdeme část této cesty.

Rýže. 7.1.

Na Obr. 7.1 obsahuje následující pojmy.

Skupina klíčových procesů. Jak je uvedeno v (Paulk, et al., 1995), „každá skupina klíčových procesů definuje blok souvisejících činností, v jejichž důsledku je dosahováno souboru cílů významných pro zvýšení produktivity výrobního procesu. například pro skupinu klíčových procesů " Správa požadavků"(Viz obrázek 7.2) cílem je sladit požadavky projektu vývoje softwaru mezi zákazníkem a vývojářem."

V CMM nejsou žádné individuální procesy. Místo toho existují jednotlivá díla, nazývané klíčové postupy (viz níže), vzájemně propojené vstupy a výstupy a sloužící jako zdrojový materiál pro stavební procesy. CMM neposkytuje návod, jak by měly být procesy strukturovány, tj. spojovat klíčové postupy do logických sekvencí. Soubory klíčových postupů se nazývají skupiny klíčových procesů.

Rýže. 7.2.

Skupiny klíčových procesů v CMM jsou mapovány na úrovně vyspělosti (obrázek 7.2), tj. všechny postupy na úrovni se vzájemně ovlivňují pouze navzájem a neinteragují s postupy na jiných úrovních. To vám umožňuje zaručit plný výkon všech procesů na konkrétní úrovni, a proto korelovat úroveň s dokončenou fází rozvoje organizace.

Přídavné jméno „klíč“ znamená, že existují procesní skupiny(tj. soubory praktik), které nejsou klíčové z hlediska konkrétní úrovně vyspělosti, tedy nesouvisejí s dosahováním cílů této úrovně (viz níže). Model HMM nepopisuje vše procesní skupiny vztahující se k vývoji a údržbě softwaru . Popisuje pouze ty skupiny, které jsou identifikovány jako klíčové determinanty produktivity výrobního procesu.

Cíle. Cíle v CMM nejsou spojeny s procesy, ale se skupinami klíčových procesů. Jak bylo uvedeno výše, cílů je dosahováno prostřednictvím implementace klíčových postupů. V CMM dosažení cíle znamená, že za prvé, po implementaci klíčových postupů, je dosaženo požadovaného výsledku, a za druhé, je dosaženo zcela konzistentně. Způsob, jakým je dosahováno cílů skupiny klíčových procesů, se může lišit projekt od projektu kvůli rozdílům v předmětová oblast nebo prostředí.

Pokud jsou tyto cíle realizovány u všech projektů, pak to znamená, že organizace dosáhla úrovně vyspělosti výrobního procesu, která koreluje s touto skupinou klíčových procesů.

Kapitola. Sekce (je jich pět na každé úrovni a jsou vždy stejné) představují vlastnosti skupin klíčových procesů, které je třeba na odpovídající úrovni implementovat. Tyto vlastnosti popisují, jak jsou procesy implementovány a do jaké míry jsou v organizaci legalizovány, tedy oficiálně schváleny a koordinovány s firemními postupy, politikami a dalšími procesy. Zde je pět oddílů.

Povinnosti plnění

Popište akce, které musí organizace podniknout, aby zajistila, že proces je zaveden a stabilní. Povinnosti týkající se výkonu se obvykle týkají stanovení organizačních zásad a podpory ze strany nejvyššího vedení.

Předpoklady

Popište předpoklady, které musí projekt nebo organizace splnit pro kompetentní implementaci výrobního procesu; se obvykle týkají zdrojů, organizačních struktur a požadovaného školení.

Probíhající operace

Část Probíhající operace popisuje podstatnou práci, která musí být provedena na této úrovni. Prováděné operace obvykle zahrnují vytváření plánů a implementaci specifických operací, provádění a sledování práce a přijímání nápravných opatření podle potřeby.

Měření a analýzy

Sekce "Měření a

"Každá skupina klíčových procesů je vyjádřena klíčovými postupy, jejichž implementace přispívá k dosažení cílů skupiny. Klíčové postupy popisují infrastrukturu a operace, které nejvíce přispívají k efektivní implementaci a ustavení skupiny klíčových procesů."

Každý klíčový postup se skládá z jedné věty, po které často následuje podrobnější popis, který může obsahovat příklady a vysvětlení. Klíčové postupy, někdy označované jako klíčové postupy nejvyšší úrovně, stanovují základní zásady, postupy a operace pro skupinu klíčových procesů. Složky s podrobným popisem se často označují jako dílčí postupy."

Klíčové postupy popisují, CO je třeba udělat, ale neměly by být brány jako dogma o tom, JAK by mělo být dosaženo cílů. Cílů skupiny klíčových procesů lze dosáhnout prostřednictvím alternativních postupů. Interpretace klíčových postupů by měla být rozumná, umožňující dosažení cílů skupiny klíčových procesů efektivní způsob, i když možná formálně a odlišně od doporučeného CMM.

Poněkud exoticky vypadá na první pohled pohled na aktivity IT managementu, ve kterých se místo procesů uvažuje o jejich komponentách – klíčových praktikách a procesy jsou přítomny pouze virtuálně, jako něco, co lze z klíčových praktik postavit. Doposud byl úkol zlepšit řízení IT řešen zaváděním hotových procesů z referenčního procesního modelu. Nyní existuje sada úrovní obsahujících nesourodé (tj. neintegrované do procesů) klíčové postupy a doporučené pořadí procházení úrovněmi. Řízení IT se podle CMM zlepšuje s přechodem na vyšší úroveň vyspělosti. Co se stane s touto propagací?

V definicích úrovní (viz obrázek 7.2) se objevilo něco jako „výrobní proces“. Je přítomen i v definici skupiny klíčových procesů a není to náhoda. Výrobní proces, nebo jak se v CMM trefně nazývá, Standard Výrobní proces Organizace (OSS) je jedním z ústředních konceptů celého modelu.

V listopadu 1986 začal American Software Engineering Institute (SEI) ve spojení s Mitre Corporation vyvíjet Software Development Process Maturity Review, který měl pomoci zlepšit jejich interní procesy.

Vypracování této revize bylo vyvoláno žádostí federální vlády USA o metodu hodnocení subdodavatelů pro vývoj softwaru. Skutečným problémem byla neschopnost řídit velké projekty. V mnoha společnostech byly projekty dodány výrazně pozdě a přes rozpočet. Bylo nutné najít řešení tohoto problému.

V září 1987 vydala SEI krátká recenze procesy vývoje softwaru s popisem úrovně jejich vyspělosti a také dotazník určený k identifikaci oblastí ve společnosti, ve kterých je potřeba zlepšení. Většina společností však považovala tento dotazník za hotový model, v důsledku čehož byl dotazník po 4 letech převeden na reálný model, Capability Maturity Model for Software (CMM). První verze CMM (verze 1.0), vydaná v roce 1991, byla revidována v roce 1992 účastníky pracovního setkání, kterého se zúčastnilo asi 200 softwarových specialistů a členů vývojářské komunity.

1. Základní. Nejprimitivnější status organizace. Organizace je schopna vyvíjet software. Organizace nemá vyloženě vědomý proces a kvalita produktu je zcela určena individuálními schopnostmi vývojářů. Jeden přebírá iniciativu a tým se řídí jeho pokyny. Úspěch jednoho projektu nezaručuje úspěch jiného. Na konci projektu nejsou evidovány údaje o mzdových nákladech, harmonogramu a kvalitě.
2. opakovatelný. Do určité míry je proces monitorován. Vedou se záznamy o mzdových nákladech a plánech. Funkčnost každého projektu je popsána písemně. V polovině roku 1999 bylo pouze 20 % organizací úrovně 2 nebo vyšší.
3. Instalováno. Mít definovaný, zdokumentovaný a zavedený proces pracovat nezávisle na jednotlivcích. Tedy domluveno profesionální standardy a vývojáři je implementují. Takové organizace jsou schopny poměrně spolehlivě předvídat náklady na projekty podobné těm, které byly dokončeny dříve.
4. Podařilo se. Mohou přesně předvídat načasování a cenu práce. Existuje databáze nashromážděných měření. Se vznikem nových technologií a paradigmat však nedochází k žádným změnám.
5. Optimalizováno. Existuje neustálý postup pro hledání a osvojování nových a vylepšených metod a nástrojů.

Rozvoj

Použití modelu v praxi odhalilo nejednoznačnost v přístupech k dosažení vyšších úrovní organizace procesů vývoje softwaru. Proto jsou do roku 2002 vypracována doporučení pro zlepšení procesu vývoje, která jsou tzv CMMI (integrace modelu zralosti schopností). V současné době Nejnovější verze CMMi - 1.3 (publikováno v listopadu 2010) .

viz také

Odkazy

Fórum studentů MIT > Hlavní sekce > Testy > Simulace řídicích systémů

Pohled plná verze: Simulace řídicích systémů

Vyřešil jsem všechny moduly, vše prošel na 4 a závěrečný na 2, teď za tři dny zkusím projít znovu, nebyl tam ani jeden stejný dotaz. Pokusil jsem se opravit závěrečný test, ale zkontrolujte, nemohu ručit za správnost. Vystavuji vše, co mám, možná to někdo zvládne lépe než já. Pokud má někdo druhý, třetí pokus, dejte, pokud vám to nevadí, disciplínu, opravdu velmi těžké.:eek:

Závěrečný test 100 ze 100

Je výsledek pokaždé jiný?

Další otázky, které zde nejsou uvedeny a zastihly mě. Odpovědi jsem nehledal, protože bez toho jsem prošel 4. Kdo se chce zmást, zbytek nahrajte sem 🙂

Modul 1:
Co by nemělo být považováno za charakteristický znak obchodního procesu?

Přidaná hodnota

Vyberte jednu odpověď:
Produkt procesu, který ztělesňuje dříve stanovené cíle

Vyberte jednu odpověď:

Ve finále (předáno 4.

Co je to model zralosti schopností? (CMM)

Tyto otázky + ty již na fóru):
1. Vyberte správné tvrzení.
Vyberte jednu odpověď:
Obchodní proces divizí se skládá z různých hodnotových řetězců (UNSURE)
End-to-end obchodní proces se skládá z obchodních procesů různé organizace
Mezifunkční podnikový proces se zpravidla skládá z podnikových procesů oddělení

2. Co není součástí univerzálního vývojového diagramu obchodních procesů?
Vyberte jednu nebo více odpovědí:
Procesní prostředky
Rizika
Činnosti řízení obchodních procesů
Faktory prostředí
Aktivita převodu vstupů na výstupy

3. Materiální zdroje jako základní prvek procesů jsou:
Vyberte jednu odpověď:
Aktivní subjekty činnosti sdružené v systémech interagujících mezi sebou a jinými zdroji
Kontrolní akce řízené subjekty činnosti na předměty činnosti, které určují cíle a výsledky procesů
Pasivní zařízení a činnosti používané k provádění procesů (NENÍ JISTO)

28.03.2014, 10:07

Modul 1:
Co by nemělo být považováno za charakteristický znak obchodního procesu? Vyberte jednu nebo více odpovědí:
Převod vstupů na výstupy
Dodání produktu externímu spotřebiteli
Přidaná hodnota
Tvorba nadbytečné a/nebo užitné hodnoty

Výsledky jako základní prvky procesů jsou:
Vyberte jednu odpověď:
Aktivní subjekty činnosti sdružené v systémech interagujících mezi sebou a jinými zdroji
Produkt procesu, který ztělesňuje dříve stanovené cíle Pasivní zařízení a činnosti používané k provádění procesů
Soubor hmotných, energetických a informačních objektů nezbytných k dokončení procesu

Co je zpětná vazba v obchodním procesu?
Vyberte jednu odpověď:
Účelné a vědomé ovlivnění procesu, navržené tak, aby zajistilo požadovaný výsledek
Analýza a porovnání výsledků procesu s dříve stanovenými cíli
Vliv na systém objektů a faktorů prostředí, které jsou zdrojem různých druhů odchylek ve fungování systému
Tak jsem odpověděl! ale stejně to vyšlo 4

Ve finále - Tyto otázky + ty, které již existují:
1 Vyberte ze seznamu nedostatky cílových struktur návrhu.

2 Ze seznamu vyberte příklady použití příkazů.
Kvalitní hrnky
výbory
Pracovní týmy

3 Vyberte ze seznamu podmínky pro použití organických organizačních struktur.
Pracovníci jsou motivováni komplexními potřebami
Cíle jsou rozmazané a dynamicky se mění
Moc je zpochybňována a testována, vyžaduje potvrzení od podřízených

4 Vyberte ze seznamu výhody projektových organizačních struktur.
přímá podřízenost zaměstnanců projektovému manažerovi a tím je dosaženo jednoznačnosti směru snažení těchto zaměstnanců

5 podpůrných procesů:
Poskytnout efektivní implementace hlavní procesy

Konečná známka 5
Otázka 1
Vyberte si ze seznamu příkladů použití příkazů.

Kvalitní hrnky
výbory
Pracovní týmy

otázka 2
K čemu slouží zprostředkovatelé v rámci funkční struktury?

Integrovat činnost různých strukturálních divizí

Otázka 3
Pojmenujte typy vztahů v modelu SADT:
Řízení
výstupní mechanismus
Vstupní zpětná vazba

Otázka 4
Který z následujících obchodních procesů je nejkratší?
Obchodní proces divize

Otázka 5
Jaké metody, metodiky a nástroje lze použít k vytvoření informačních modelů podnikových procesů?

Gein-Sarsonova metodologie
Modelovací jazyk Chena a Barkera

Otázka 6
Která reprezentace obchodních procesů odpovídá nejnižší úrovni (z uvedených)?

Operace obchodních procesů

Otázka 7
Délka obchodního procesu:

Je to subjektivní

Otázka 8
Materiální zdroje jako základní prvek procesů jsou:

Pasivní prostředky a předměty činnosti používané k provádění procesů

Otázka 9
Vyberte ze seznamu výhody projektových organizačních struktur.

Je realizována přímá podřízenost zaměstnanců projektovému manažerovi a tím je dosaženo jednoznačnosti směru úsilí těchto zaměstnanců

Otázka 10
Vyberte ze seznamu výhody maticových organizačních struktur.

Možnost flexibilního přizpůsobení Organizační struktura v širokém spektru: od slabé po silnou matrici

Otázka 11
Co zahrnuje druhá smyčka řízení podnikového systému?

Subsystém řízení provozu
subsystém řízení vývoje

Otázka 12
Obecný procesní model obchodního systému zahrnuje následující prvky:

Výstup
proces
Vchod
Rušení

Otázka 13
Který standard IDEF umožňuje modelovat aktivity, toky a stav objektů?

Otázka 14
Jaké jsou pravomoci projektového manažera v silné maticové struktuře?

Střední až vysoká

Otázka 15
Co lze přičíst hlavním prvkům investičních a finančních procesů?

Investoři
Věřitelé

Otázka 16
Vyberte ze seznamu nedostatky návrhových cílových struktur.

Snížená vyrobitelnost ve funkčních oblastech

Control Systems Modeling.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

Jaké je pořadí dominance v SADT diagramech?
Odpověď: Nejdominantnější funkce jsou umístěny v levém horním rohu.

pomoc 3školení kdo to má pliz

Přidáno po 1 minutě
Prosím o 3 školení od každého, kdo má Modelování řídicích systémů

vBulletin® v3.8.7, Copyright 2000-2018, vBulletin Solutions, Inc.

Překlad, který můžete říci:

Metodika rozvoje IS. Model zralosti CMM/CMMI.

V roce 1991 Ústav softwarového inženýrství univerzity

Carnegie Mellon (Software Engineering Institute, SEI) vytvořil model zralosti CMM (Capability Maturity Model) pro vývoj softwarových produktů. Postupem času byla vydána celá rodina modelů:

SW-CMM - pro softwarové produkty, SE-CMM - pro systémové inženýrství, Acquisition CMM - pro nákup, People CMM - pro řízení lidských zdrojů, ICMM - pro integraci produktů.

Ukázalo se, že různé modely jsou poměrně obtížné na pochopení a implementaci. Od té doby, co byly vytvořeny různé skupiny specialistů, obsah těchto modelů nebyl vždy konzistentní jak mezi sebou, tak s

požadavky mezinárodních norem. Proto v roce 2002 SEI zveřejnila nový model CMMI (Capability Maturity Model Integration), který kombinuje dříve vydané modely a zohledňuje požadavky

mezinárodní standardy. CMMI je soubor modelů (metodologií) pro zlepšování procesů v organizacích různých velikostí a činností. CMMI rozlišuje tyto skupiny oblastí zlepšování: procesní řízení, projektové řízení, inženýrské oblasti, servis

oblasti. V tomto případě jsou všechny oblasti specifikovány ve formě požadavků, které neurčují způsob jejich implementace, ale požadavky na rozhraní. Z toho plynou dva důsledky.

Důsledek 1. CMMI umožňuje různé implementace a není metodikou vývoje softwaru jako MSF, Scrum, RUP atd. Poslední jmenovaný lze použít při jeho implementaci. Například ve VSTS pro CMMI existuje speciální šablona procesu s názvem MSF pro CMMI.

Důsledek 2. CMMI se používá k certifikaci společností pro vyspělost jejich procesů. Zpočátku, koncem 80. a začátkem 90. let, byl CMM (tehdy ještě ne CMMI) vytvořen právě jako prostředek certifikace

federální subdodavatelé. A teprve později, když se rozšířil ve světě, začal se používat a poté se zaměřil na zlepšování procesů. Všimneme si ještě jednoho důležitá vlastnost CMMI. Je určen nejen pro vývoj softwarových systémů. Mnoho velké společnosti nevytvářejí software, ale cílové produkty, kde je software zahrnut jako nedílná součást.

Například letectví, letecký průmysl. Tedy vývoj softwaru

vyskytuje se spolu s inženýrskými pracemi jiných typů. A často se stává, že do jednoho projektu jsou zapojeny více než dva různé typy inženýrství. Úkolem CMMI je poskytnout takovým projektům a společnostem jednotnou platformu pro organizaci vývojového procesu.

Na rozdíl od klasického modelu CMM, který byl přísně hierarchický a umožňoval pouze sekvenční zlepšování procesů po úrovních, má model CMMI dvě dimenze – sekvenční, např.

stejné jako v CMM a kontinuální, umožňující do určité míry libovolným způsobem zlepšovat procesy v organizaci. Zde se zaměříme na sekvenční model. Má 5 úrovní

procesní zralost (obr. 1).

První úroveň(úroveň splatnosti 1) je úroveň, na které se podle definice nachází jakákoli společnost. Na této úrovni je vývoj softwaru víceméně chaotický.

Spravovaná úroveň(úroveň zralosti 2) - již se zde objevují zásady a postupy pro organizaci procesů schválených na úrovni společnosti. Celý rozsah procesů však existuje pouze v rámci jednotlivých projektů.

Určitá úroveň(stupeň zralosti 3) - zde se objevuje standardní proces na úrovni celé společnosti jako celku.

Co je to Capability Maturity Model (CMM)? Co jsou úrovně CMM?

Jedná se o velký a neustále rostoucí soubor procesních aktiv: šablony dokumentů,

modely životního cyklu, softwarové nástroje, postupy atd. Jakýkoli specifický proces se získá vyříznutím z této normy.

Kvantitativní úroveň(stupeň vyspělosti 4) implikuje vznik systému měření v podniku, která probíhají na základě standardního procesu a umožňují kvantitativní řízení rozvoje.

Úroveň optimalizace(úroveň zralosti 5) znamená neustálé zlepšování vývojových procesů, jak přírůstkových, přírůstkových, tak revolučních. Tyto změny přitom nejsou vynucené, ale proaktivní problémy a obtíže. Proces se sám o sobě zlepšuje a neustále jsou zaváděny vhodné mechanismy.

Mnoho lidí zná zkratku CMMI, mnoho lidí ví, že se jedná o model, tzn. soubor doporučení, jak zlepšit procesy související například s vývojem softwaru. Málokdo však ví, že existuje několik modelů CMMI. Nejznámější z nich je CMMI for Development (CMMI-DEV), která je skutečně v mnoha ohledech spjata s činností vývojových společností (tedy těch společností a organizací, které vyvíjejí a dodávají určitý softwarový produkt nebo jiný komplexní software a hardware). řešení).

Ale co ti, kteří nedodávají produkt, ale služby (například podpora produktu s nevýznamným podílem vývoje na celkových nákladech práce nebo vůbec žádné)? Pro ně existuje také soubor doporučení – model CMMI for Services (CMMI-SVC). Například IT oddělením může tento model (přesněji jeho doporučení) pomoci pochopit, co je třeba udělat, aby se například stejná doporučení ITIL stala běžným procesem, a ne nějakou „posvátnou praxí“.

Model vyspělosti schopností (CMM)

Je zvláštní, že doporučení tohoto modelu jsou zcela univerzální a „nezavírají“ pouze na Informační technologie. Pilotní zavedení praktik tohoto modelu proběhlo ... v jedné z nemocnic ve Spojených státech (ostatně i lékařská péče je služba).

Je však lepší se naučit kterýkoli z uvedených modelů. A pokud je několik stovek lidí vyškolených v modelu CMMI-DEV pro celé CIS (cca 250-300 lidí), pak je v CIS pouze 6 lidí vyškolených v modelu CMMI-SVC. Mluvíme o vyškolených, ne o instruktorech. Přesně to byl hlavní problém až do prosince 2011: pro CMMI-DEV byl na celém světě pouze jeden rusky mluvící instruktor certifikovaný SEI (CMMI model developer) a pro ostatní modely nebyl vůbec žádný! Nyní se objevil i takový instruktor podle vzoru CMMI-SVC (proto prvních 6 vyškolených). Tento instruktor je autorem této publikace, který je k dispozici pro zodpovězení jakýchkoliv dotazů ohledně zmíněných modelů a formálního školení. Dotázat se!

Tento materiál je soukromý záznam člena komunity Club.CNews.
Redakce CNews nenese odpovědnost za její obsah.

Zvážíme vývoj modelů zajišťování kvality na základě „modelu zralosti procesu“ nebo „modelu zlepšování kapacity“ CMM (Capability Maturity Model). I když model SMM je zaměřen na zajištění kvality softwaru, jeho metodické aspekty jsou aplikovatelné na modely pro zajištění kvality jakéhokoli produktu (zboží, díla, služby).

Hlavní v modelu SMM je koncept organizační vyspělosti.

nezralý je považována za organizaci, ve které proces vývoje softwaru závisí pouze na konkrétních interpretech a manažerech a rozhodnutí se často dělají „za běhu“. V tomto případě je vysoká pravděpodobnost překročení rozpočtu nebo nedodání projektu, a proto jsou manažeři nuceni zabývat se pouze řešením okamžitých problémů.

Zralý Má se za to, že organizace splňuje následující podmínky:

• – existují dobře definované postupy pro tvorbu softwarových produktů a projektové řízení, které jsou zpřesňovány a zdokonalovány pilotní projekty analýzou složek „náklady – zisk“;
• – odhady času a nákladů na provedení práce jsou založeny na nashromážděných zkušenostech, a jsou proto poměrně přesné;
• – společnost má standardy pro procesy vývoje, testování a implementace softwaru, pravidla pro návrh finálního programového kódu, komponent, rozhraní atd. To vše tvoří infrastrukturu a firemní kultura který podporuje proces vývoje softwaru.

Takže standard SMM je model zajišťování kvality, který se skládá z kritérií pro posouzení vyspělosti organizace a receptů na zlepšení stávajících procesů. V modelu SMM je definováno pět úrovní vyspělosti organizací, jejichž charakteristiky jsou uvedeny na Obr. 5.3.

Rýže. 5.3. Pět úrovní zralosti modeluSMM

První úroveň (počáteční úroveň) je základem pro rozvoj podniku na následujících úrovních. Předpokládá se, že v podniku na základní úrovni organizace neexistují stabilní podmínky pro vytváření vysoce kvalitního softwaru. Výsledek každého projektu tedy zcela závisí na osobních kvalitách manažera a zkušenostech programátorů. To znamená, že úspěch v jednom projektu lze opakovat pouze tehdy, jsou-li stejní manažeři a programátoři přiřazeni k dalšímu projektu. Pokud však z podniku odejdou manažeři nebo programátoři, kteří získali zkušenosti s projekty, pak s jejich odchodem kvalita vyrobeného softwaru prudce klesá.

Je třeba si uvědomit, že na počáteční úrovni, ve stresových situacích, velká závislost na lidský faktor vývojový proces je redukován na psaní kódu a jeho minimální testování.

Dosažení druhého opakovatelná úroveň (opakovatelná úroveň) je dáno implementací technologie projektového řízení v podniku. Plánování a projektové řízení v podniku je založeno na nashromážděných zkušenostech, pro vyvíjený software jsou a jsou používány standardy, jejichž dodržování kontroluje speciální skupina pro zajištění kvality. Předpokládá se, že druhá úroveň může poskytnout příležitosti pro další zlepšení (přechod na třetí úroveň) a nevylučuje možnost regresivního návratu kvality procesu vývoje softwaru na počáteční úroveň za kritických podmínek.

Třetí, určitou úroveň (definováno vlevo) vyznačující se tím, že standardní proces tvorby a údržby softwaru je plně zdokumentován, od vývoje softwaru až po projektové řízení. Hypotézou zavedení této úrovně je, že v procesu standardizace podnik přechází na nejúčinnější postupy a technologie. Pro vytvoření a udržení fungování standardů pro vývoj softwaru a projektové řízení v organizaci by měla být vytvořena speciální skupina. Předpokladem pro dosažení třetí úrovně je přítomnost programu trvalého profesního rozvoje a vzdělávání zaměstnanců v podniku. Předpokládá se, že počínaje touto úrovní přestává organizace záviset na kvalitách konkrétních vývojářů a nemá tendenci sklouznout ve stresových situacích na nižší úroveň.

Na čtvrtém, řízená úroveň (spravovaná úroveň) podnik stanovuje kvantitativní ukazatele kvality - jak pro softwarové produkty, tak pro procesy jejich tvorby obecně. Lepšího projektového řízení je tedy dosaženo snížením odchylek různých ukazatelů projektu. Zároveň jsou odděleny smysluplné (signální) variace implementovaných procesů vývoje softwaru a náhodné (šumové) variace procesu.

Pátý (nejvyšší), optimalizační úroveň (úroveň optimalizace) vyznačující se tím, že zlepšovací opatření jsou aplikována nejen na stávající procesy, ale také k posouzení účinnosti zavádění nových technologií. Hlavním úkolem podniku na této úrovni je neustálé zlepšování stávajících procesů. Zlepšení procesů by přitom mělo pomoci předcházet možné chyby a vady. Zároveň by se mělo pracovat na snížení nákladů na vývoj softwaru.

5 evolučních fází v řízení organizačních procesů. Vysvětlení modelu zralosti schopností. CMM

CM-CEI Capability Maturity Model je organizační model, který popisuje 5 evolučních stupňů (úrovní), na kterých jsou procesy v organizaci řízeny.

Původně vytvořený pro vývoj softwaru, smyslem modelu zralosti schopností je, že organizace by měla být schopna přijímat a podporovat své softwarové aplikace. Model také navrhuje konkrétní kroky a iniciativy, které pomohou organizaci růst na další úroveň.

5 fází modelu zralosti schopností

Počáteční (procesy jsou ad hoc, chaotické, nebo ve skutečnosti je jich definováno jen málo) Opakovatelné (základní procesy jsou zavedeny a je třeba se jich držet disciplína) Definované (všechny procesy jsou definovány, zdokumentovány), sjednocené a integrované) Řízené ( procesy jsou měřeny agregováním podrobných dat o procesech a jejich kvalitě) Optimalizace (nepřetržitý vývoj procesů prostřednictvím kvantitativní zpětné vazby a testování nových nápadů a technologií)

Model vývoje softwaru

CMM popisuje principy a postupy, které jsou základem konceptu vyspělosti softwarového procesu. Jsou navrženy tak, aby pomohly firmám zabývajícím se vývojem softwaru a prodejem zlepšit sofistikovanost jejich softwarových procesů evolučním způsobem. Počínaje ad hoc chaotickými procesy, přechodem k vyspělým, disciplinovaným softwarovým procesům. Důraz je kladen na identifikaci klíčových oblastí procesů a příkladných postupů, které mohou představovat disciplinované softwarové procesy. Koncept zralosti CMM vytváří kontext, ve kterém:

Cvičení lze opakovat. Pokud nějakou operaci neopakujete, neměli byste ji vylepšovat. Existují pravidla, postupy a praktiky, které nutí organizaci zavádět a důsledně provádět. Osvědčené postupy pro organizaci produkční práce lze rychle sdílet mezi skupinami. Postupy jsou definovány tak, aby umožňovaly výměnu mezi projekty, čímž poskytují organizaci určitou standardizaci. Odchylky v provádění těchto metod jsou minimalizovány. Pro úkoly jsou stanoveny kvantitativní cíle; a měření jsou zaváděna, vytvářena a udržována tak, aby tvořila základ pro hodnocení. Postupy se neustále zlepšují, aby se zlepšila schopnost (optimalizace).

Model vyspělosti schopností je užitečný nejen pro vývoj softwaru, ale také pro popis evolučních úrovní organizací obecně a pro popis úrovně řízení, které organizace implementovala nebo chce dosáhnout.

Struktura modelu vývoje funkcí

Úrovně zralosti jsou vrstveným konceptem, který poskytuje konzistenci disciplíny, která je potřebná k dosažení neustálého zlepšování. Zde je důležité poznamenat, že organizace rozvíjí schopnost vyhodnotit důsledky nové praxe, technologie nebo nástroje. Nejde tedy o přijetí těchto inovací, ale spíše o to, jak tyto inovační snahy ovlivňují stávající postupy. Podporuje projekty, skupiny a organizace tím, že jim dává základ pro informovaná rozhodnutí. Oblasti klíčových procesů – Oblast klíčových procesů (KPA) definuje skupinu souvisejících činností, které při společném provádění dosahují řady důležitých cílů. Cíle – Cíle klíčové oblasti procesu popisují ustanovení, která musí existovat pro tuto klíčovou oblast procesu. Předpisy je třeba provádět účinným a bezpečným způsobem. Rozsah, v jakém jsou cíle splněny, ukazuje, jaký druh schopnosti organizace na této úrovni excelence vytvořila. Cíle vymezují rozsah, hranice a účel každé klíčové oblasti procesu. Obecné charakteristiky – Obecné charakteristiky zahrnují postupy, které implementují a institucionalizují klíčové oblasti procesů. Těchto 5 typů obecné charakteristiky zahrnují: Závazek k výkonu, Schopnost k výkonu, Iniciativy, které mají být provedeny, Měření a analýza a Kontrola implementace. Klíčové postupy – Klíčové postupy popisují prvky infrastruktury a postupy, které nejúčinněji přispívají k implementaci a institucionalizaci klíčových oblastí procesů.

Kritéria pro definování procesu

Kritéria pro definování procesu jsou souborem procesních prvků, které musí být zahrnuty do popisu softwarového procesu, aby je lidé mohli používat v praxi. Chcete-li nastavit kritéria, musíte si položit otázku - „Jaké informace softwarový proces potřebné pro dokumentaci?