Správa konfigurace v softwarovém projektu. Správa konfigurace

Účelem procesu správy konfigurace je zabránit nekontrolovanému vývoji projektu. Byla přijata řada mezinárodních a národních norem, které regulují proces správy konfigurace v různých průmyslových odvětvích.

08.08.2013 Nikita Nalyutin

Účelem procesu správy konfigurace je zabránit nekontrolovanému vývoji projektu zajištěním toho, že všechny změny jsou zohledněny a autorizovány v souladu s přijatou vývojovou technologií. Byla přijata řada mezinárodních a národních norem, které regulují proces správy konfigurace v různých průmyslových odvětvích.

Při vývoji softwarových systémů vzniká mnoho vzájemně souvisejících objektů: požadavky, zdrojové kódy, objektové soubory, popisy testů atd. - jejichž koordinované sady se obvykle nazývají konfigurace a proces udržování jejich změn a integrity během životního cyklu projektu - správa konfigurace. Hlavním účelem zavedení procesu správy konfigurace do projektu je zabránit nekontrolovanému vývoji projektu a zajistit, že všechny provedené změny budou zohledněny a schváleny. Správa konfigurace zahrnuje postupy pro identifikaci prvků návrhu, správu změn a udržování sledovatelnosti objektů, stejně jako činnosti na podporu auditů stavu a monitorování stavu konfigurace.

Objekt konfigurace(Configuration Item, CI): zdrojové kódy, zkompilované programy, zdrojové kódy programů, dokumentace, hardwarové prvky, postupy a školicí materiály atd. - základní koncept procesu konfiguračního managementu Obvykle však pod konfigurační management spadají pouze výsledky projektových činností: software a související dokumentace, požadavky a dokumentace rozhraní, výstupní soubory získané z použití projektových nástrojů, dokumenty o proveditelnosti a záznamy uživatelských požadavků, projektový management plány, nástroje a uživatelské příručky, záznamy o historii projektu, plány testování, postupy a jednotlivé testovací případy.

Když jsou konfigurační objekty kombinovány, jsou vytvořeny konfigurace- jakákoliv strukturovaná sada objektů vývoje softwarového systému, prezentovaná ve formě CI, nebo soubor procesů a technologických řetězců projektu vývoje softwarového systému, jejichž popisy mohou být prezentovány i ve formě CI. Proces správy konfigurace v různých průmyslových odvětvích je regulován mezinárodními a národními normami: GOST R 51904, DO-178, AS9100, AS9006, ISO10007, ISO/IEC TR 15846, ISO/IEC 15408, IEEE 1042 atd. Při vývoji vysoce kritických systémů , použití procesu správy konfigurace je nezbytně nutné - náklady na opravu defektů v takových systémech mohou být velmi vysoké.

Norma GOST R 51904 byla přijata státní normou Ruska v roce 2002 a upravuje požadavky na vývoj a dokumentaci vestavěných systémů. Proces konfiguračního managementu je v něm klasifikován jako skupina ucelených procesů nezbytných pro zajištění kvality vývojových procesů a jejich výstupních dat. Integrální procesy běží souběžně s vývojovými procesy a poskytují nepřetržitou podporu vývoje. Hlavními cíli procesu správy konfigurace podle GOST 51904 je zajistit:

• definovaná a spravovaná konfigurace softwaru v průběhu celého životního cyklu;
• integrita při replikaci spustitelného objektového kódu pro výrobu softwaru nebo v případě potřeby jeho regenerace pro výzkum nebo modifikaci;
• řízení procesních vstupních a výstupních dat v průběhu celého životního cyklu, což zaručuje konzistenci a opakovatelnost práce v procesech;
• referenční bod pro ověření, vyhodnocení stavu a kontrolu změn řízením konfiguračních položek a definováním základní linie;
• zajištění toho, že závadám a chybám bude věnována pozornost a změny budou zaznamenány, schváleny a provedeny;
• posouzení souladu softwaru s požadavky;
• spolehlivá fyzická archivace, obnova a údržba položek konfigurace.

Proces je rozdělen do několika podprocesů. Identifikace jedinečně označuje každou položku konfigurace a následné verze, aby vytvořila základ pro řízení a odkaz na položky konfigurace. Pro tento účel je přijato identifikační schéma, které definuje pravidla pro označování různých typů konfiguračních prvků, jejich verze, revize a stav. Podproces kontroly konfigurace sestává ze stanovení sady pravidel, jimiž se řídí přístup ke konfiguračním prvkům různých skupin uživatelů, a také z protokolování všech akcí pro přístup a změnu konfiguračních prvků.

Dalším dílčím procesem je definování základní linie vývoje pro vytvoření „snímku“ stavu konfigurace v daném okamžiku. Základní linii pak lze použít buď jako výchozí bod pro vytváření nových konfigurací nebo pro definování prvků systému, které mají být předloženy k certifikaci certifikačnímu orgánu.

V procesu konfiguračního managementu připravuje vývojový tým a další účastníci projektu defektní hlášení obsahující popisy nesrovnalostí vyvíjeného systému s požadavky nebo nesouladu vývojových procesů s přijatými standardy. Vedení hlášení závad musí zajistit, aby nápravná opatření k odstranění závad byla dokončena kvalitně a včas.

Kontrola změn je nezbytná pro zabránění samovolnému vývoji systému – všechny změny v něm provedené musí být zaznamenány, posouzeny, přezkoumány a schváleny. Takové změny nenarušují integritu systému a konfiguraci. Současně probíhá archivace konfigurace - to je hlavní dílčí proces, který zajišťuje schválení všech CI v konfiguraci a autorizaci změn v nich. Toho je dosaženo vymezením přístupových práv ke CI a definováním pravidel pro jejich změnu různými skupinami vývojářů. Vývojář nebude mít přístup k CI, pokud tento přístup nebude autorizován.

Kromě toho existují také podprocesy hlášení stavu konfigurace, které jsou nezbytné

• určit plány rozvoje, úzká místa a stanovit termíny;
• řízení načítání softwaru, v důsledku čehož je z CI vytvořena konfigurace určená k vydání a/nebo nahrání do vestavěného systému (této konfiguraci je přiděleno registrační číslo a je určen hardware, na kterém má systém běžet);
• kontrola prostředí životního cyklu, která zajistí, že všechny projektové nástroje jsou identifikovány, spravovány, kontrolovány a lze je získat z databáze projektu.

Téměř všechny procesy správy konfigurace definované normou GOST R 51904 vyžadují sledování stavů životního cyklu objektů umístěných v konfiguraci. Řízení konfigurace tedy znamená, že režim přístupu k CI se může měnit v závislosti na jejich stavu. K vytváření základních linií dochází pouze tehdy, když všechny CI v nich zahrnuté dosáhnou určitého stavu. Hlášení závad je řízeno na základě informací o stavu závady a závady samotné a zda byla odstraněna. Zpráva o stavu konfigurace musí obsahovat informace o stavech CI. Archivační konfigurace mohou také změnit svůj stav. Proces monitorování zátěže softwaru je automatizován vytvořením základní linie CI, které dosáhly určitého stavu. Prostředí životního cyklu je monitorováno na základě informací o stavu projektových nástrojů a o tom, zda vyžadují aktualizaci.

V jádru GOST R 51904, jehož rozsahem jsou jakékoli vestavěné systémy, je založen na mezinárodním standardu DO-178, který se používá při vývoji leteckých systémů. Systémy navržené podle této normy mohou být certifikovány tak, aby splňovaly požadavky na letovou způsobilost.

Obecně je cílem procesu správy konfigurace, na který se vztahuje norma DO-178, zachovat integritu dat vytvořených během všech fází životního cyklu produktu. Hlavním specifikem procesu řízení konfigurace regulovaného touto normou je vzít v úvahu aspekty certifikace letové způsobilosti, kterým musí projít veškerý software používaný v palubních systémech letadla. Data z procesu řízení konfigurace se používají jako primární data, o která mají zájem certifikační orgány, kterým jsou poskytovány konfigurační indexy – seznamy jednoznačně identifikovaných prvků (zdrojový kód, datové soubory, objekt a spustitelný kód) obsažených v softwaru. Pro potvrzení shody kvality softwaru s danou úrovní kritičnosti softwaru na palubě jsou uvedeny výsledky jeho testování provedeného v souladu s požadavky pro tuto úroveň. Konfigurace zahrnuje propojení mezi požadavky, zdrojovými kódy, testy, jejich výsledky a dalšími vývojovými objekty, což zajišťuje jejich sledovatelnost.

K dosažení certifikace musí mít všechny konfigurační položky stav, který indikuje, že jsou připraveny k certifikaci, a všechny problémy, které se vyskytnou během vývoje, musí být tak či onak vyřešeny. Tento aspekt certifikace je podporován poskytováním informací o správě problémů a zahrnutím zpráv o problémech a souvisejících požadavků na změny do konfiguračního indexu.

Z pohledu ISO 10007 je management konfigurace disciplínou managementu aplikovanou po celý životní cyklus produktu, aby byla zajištěna viditelnost a kontrola funkčních a fyzických charakteristik. Tato činnost je způsob, jak uspokojit určité požadavky obsažené v jiných mezinárodních normách řady ISO 9000. Podle této normy zahrnuje proces správy konfigurace následující činnosti: identifikace konfigurací, sledování konfigurací, hlášení stavu konfigurací, ověřování konfigurací. Rozsah tohoto standardu je širší než předchozí dva – nejde pouze o vývoj softwaru, ale také o veškeré výsledky činnosti společnosti, které lze řídit v souladu s principy konfiguračního managementu.

Existují také normy AS 9100/AS9006, které specificky přizpůsobují požadavky systému řízení kvality ISO leteckému průmyslu.

Všechny uvedené normy (uvedené v tabulce) mají téměř stejné požadavky na identifikaci CI, sledovatelnost a výpočet stavu. Obecně lze zaznamenat tendenci ke zpřísňování jimi předepsaných požadavků, především týkajících se integrace rozvojových procesů a řídících činností.

Nikita Nalyutin([e-mail chráněný]) - Manažer pro zajištění kvality, Experian (Moskva).

Plán řízení konfigurace ve standardech

Management plán je nejdůležitějším dokumentem procesu. Celkově je to jediný dokument procesu řízení. Složení a obsah plánu managementu jsou definovány v některých normách, ale ve většině případů jsou výrazně upraveny tak, aby vyhovovaly potřebám konkrétní organizace nebo projektu při zavádění procesů životního cyklu PS. Všechny standardy diskutované v této knize definují proces a role, ale ne všechny definují a klasifikují plány managementu. Podívejme se blíže na požadavky norem na obsah plánů hospodaření:

Faktory ovlivňující strukturu plánu řízení konfigurace a jeho detail

Samotný plán je při jeho vývoji ovlivněn mnoha faktory. Struktura plánu řízení a jeho obsah závisí na faktorech, jako je typ projektu a doba jeho trvání, úroveň formalizace procesů, velikost týmu (přítomnost regionálně rozmístěných skupin), počet subdodavatelů, a mnoho dalších. To znamená, že struktura plánu a skladba žádostí se mohou lišit v poměrně velkých mezích při zachování jednoho „ducha“.

Zpočátku bylo vše jednoduché. Mládí, nadšení. Na projektu pracovalo několik programátorů. Všichni kódovali, zkopírovali kód na sdílený virtuální počítač, když byli připraveni, a občas postrčili administrátora, aby doručil nějaký balíček nebo opravil konfiguraci. Jakmile si uvědomili, že je vše hotovo, šli udělat vydání. Nejprve záloha, pak nejstarší shromáždil všechnu svou chladnou hlavu v pěst, zkopíroval projekt na produkční server a s pomocí admina se ujistil, že tam funguje. Tým počkal dva dny, ujistil se, že tam není fronta vděčných uživatelů se sekerami, a s pocitem hrdosti na odvedenou práci šel pít pivo.

Pak všichni trochu povyrostli. Objevily se a začaly se nějak používat Redmine/jira/etc, git/svn, jenkins, spinx-docs/rubydoc/doxygen/etc, wiki, unit testy. Objevily se podprojekty, stánek rostl. Nyní existuje několik produkčních serverů. Admin zvedl salt/puppet/atd, monitoring, sedí ve svém doupěti jako pavouk, upravuje konfigurace na salt-master a stahuje odtud state.highstate.

Život

Existuje pouze sedm fází životního cyklu.

1. Koncepční design. V této fázi musíte pochopit Co obecně by se mělo udělat.
2. Architektonický design. V této fázi musíte pochopit Jak toto je potřeba udělat.
3. Implementace. To přímo souvisí s kódováním a testováním jednotek.
4. Ověření. Kontrola, zda program provádí všechny zamýšlené funkce.
5. Validace. Kontrola, zda lze program stále používat. Z předchozího odstavce to najednou nevyplývá.
6. Uvedení do provozu. Obvykle zahrnuje zavádění vydání, migraci dat a školení uživatelů.
7. Vlastně samotná operace.
8. Vyřazení z provozu

Toto je základní schéma používané v systémovém inženýrství. V závislosti na měřítku, specifikách průmyslu a náboženském přesvědčení PM lze etapy přejmenovat, slepit nebo naopak rozdělit, ale rozumný proces lze vždy korelovat s tímto schématem. Pokud tým přijal agilní, pak diagram popisuje životní cyklus samostatného příběhu.

K čemu to všechno je? V tomto kontextu je správa konfigurace procesem udržování produktu v integrálním stavu. Začíná někde kolem dokončení první etapy a končí až smrtí projektu. Navíc, pokud je tento proces zanedbán, smrt může být náhlá.

Co se může zlomit?

Nesoulad verze komponenty. Někteří používají libbase, jiní libManagementFacade. Během toho se ukázalo, že libbase-1.14.3 má malou, ale zákeřnou chybu. Povídali jsme si, opravovali, zapomínali. Testováno na libbase-1.14.4 a byla vydána libbase-1.14.3.

Změna konfigurace prostředí. Jeden požadavek POST najednou začal trvat dlouho. Podívali jsme se, to není tak důležité, nechme to pracovat samo. Zvýšili jsme timeout v nginx pro čekání na backendovou odpověď. Admin na stánku to opravil a zapomněl. Vykulili jsme se a zase chytli staré chyby, ale teď v boji podmínky.

Změna konstrukčních řešení. Začali jsme to dělat pod Windows, pak jsme se inspirovali myšlenkami RMS a rozhodli jsme se přejít na Ubuntu, ale rozhodnutí nebylo sděleno všem. Začali jsme sbírat, každý přinesl deb balíčky a někdo, kdo byl v tanku, exe chlap.

Ztráta funkčnosti, která má pro uživatele smysl. Přinesli novou verzi, dlouho mluvili o změně designu, o nových frameworkech, o pokročilých algoritmech. Uživatelé naslouchali, kývali hlavami a říkali: „To je všechno v pořádku, ale na naši žádost jste nám vyrobili formu. Dříve to byla pátá podpoložka ve třetí položce nabídky, kde je teď? Ztraceno při nějaké žádosti o sloučení.

Co dělat

1. Určete všechny součásti, které jsou potřebné pro fungování projektu, a ujistěte se, že jsou správně verzovány. Konfigurace, pro první přiblížení, je seznam komponent a jejich verzí.
2. Pochopte, jak se konfigurace přenáší ze stojanu do výroby.
3. Začněte spravovat požadavky. Obecně lze říci, že správa požadavků je samostatný proces. V rámci správy konfigurace se musíte ujistit, že ke každé komponentě zahrnuté v sadě vydání je připojena dokumentace, která přesně popisuje požadavky předložené této komponentě a jejich stavy: splněno, nesplněno, částečně splněno, s výhradami.
4. A obecně by každá komponenta měla mít dokumentaci, která popisuje, co, jak a proč dělá.

Na jevišti architektonický design, když architekt řekl, jak to vidí, je třeba se ujistit, že tuto vizi vytáhne z hlavy, vloží do dokumentace a nalepí štítek s verzí. Pokud se jedná o sešitový list se schématem, musíte jej naskenovat, vložit do myčky souborů (nebo wiki) a vytvořit na něj odkaz.

Na jevišti rozvoj musíte se ujistit, že kód je zdokumentován. Je dobré vytvořit samostatné dokumenty pro moduly (v git), které popisují požadavky na ně a jejich behaviorální funkce. V redmine/jira byste neměli zanechávat mnoho informací. Po dokončení velké funkce, před jejím sloučením do hlavní, se musíte ujistit, že její popis z nástroje pro sledování úloh je správně přenesen do dokumentace. Jednoduše proto, že po nějaké době v rámci jiného úkolu se chování může změnit a shromažďování dokumentace pro několik úkolů bude obtížné. Sledování úkolů neposkytuje úplný obrázek.

Uživatelskou dokumentaci je dobré udělat ve fázi vývoje. Udržujte (pokud je to možné) v git a upravujte souběžně s kódem. Pokud na to nebudou speciální techničtí spisovatelé, kontext zmizí, všichni zapomenou, dokumentace rozhodně nebude.

Na ověření Kontroluje se soulad programu s uvedenými požadavky. Na konci se musíte ujistit, že všem požadavkům je přiřazen stav splněno/nevyhověno.

Na jevišti Validace, zkontroluje, zda lze program použít. Musíte se ujistit, že všechny změny provedené v chování programu se okamžitě projeví v dokumentaci.

Na jevišti úvod pro vykořisťování Kontroluje se správnost přípravy a uvedení do provozu. Musíte se ujistit, že jsou v něm obsaženy všechny součásti správných verzí. Hlavní vliv zde má sůl/loutka. Můžete to udělat bez nich, pouze vydáním pokynů k instalaci, ale s nimi je to jednodušší. Musí být připraveny správně a včas.

O jevišti úkon vše jasné. Stačí se řídit pokyny výrobce.

Ve fázi vyřazování z provozu se musíte ujistit, že jsou odstraněna všechna potřebná data.

O montáži a soli/loutce. Toto je druhá linie obrany (hned po git). Pracovní schéma aplikace je asi toto:

1. Ujistěte se, že situace u každého balíčku třetí strany je jasná: odkud pochází, jaká verze, jaké záplaty byly použity. Pokud nějaká ředkev (špatný člověk) vloží identické verze do fyzicky odlišných souborů, musí být přesvědčen, že se mýlí, nebo musí na všechny své produkty nalepit další verzi.
2. Pokud jsou všechny rpm uloženy do jednoho úložiště, musíte se ujistit, že je jasné, která verze bude spuštěna. Dobrou možností je mít skript pro opětovné sestavení celého úložiště a vložit verzi do celého úložiště. Další možností je pro explicitní označení verze v souboru manifest/sls.Mimochodem, puppet má chybu, zdroj balíčku neví, jak verzi downgradovat. Proč se nestydí, nevím.
3. Všechny soubory manifestů/sls jsou uloženy v git. V pilíři pro sůl nebo třídních parametrech pro loutku je zahrnuto pouze to, co odlišuje stojan od výroby. Takovými věcmi jsou například ulrs webových služeb, parametry jako shared_buffers pro postgres, příznaky, které umožňují režim ladění.Vše ostatní je nemilosrdně pevně zakódováno. Parametry se nastavují jednou při nasazení stojanu a poté se mění jen zřídka. sls soubory jsou vnímány jako kód, ten je narolován na stojan, testován a v nezměněné podobě převeden do výroby.

• Předmluva k materiálu
• Úvod do správy konfigurace softwaru
  • Základní pojmy a prvky
• Správa konfigurací ve standardech
  • Typy norem

Předmluva k materiálu

Dříve nebo později jakýkoli dlouhodobý projekt související s vývojem softwaru naroste do nesmírných rozměrů, stává se obtížně řiditelným a obtížně předvídatelným. Management již není schopen sledovat konkrétní aktivity podřízených. Ale možná nejdůležitějším problémem je, že manažerský tým nemá jasnou představu o kvalitě vyráběného produktu. Podřízení jsou zase ochuzeni o komplexní porozumění zadaným projektovým úkolům, přičemž jsou ve své práci vedeni nikoli vědeckým základem, ale inspirací a podněty duše.

Je pravděpodobné, že i v tomto případě je možná určitá kontrola nad projektem s různou mírou úspěšnosti. Je pravda, že je obtížné určit úroveň kvality výstupního produktu, jak je v průmyslové výrobě zvykem.

Zde vzniká potřeba posunout se na další kvalitativní úroveň. A to nejen proto, že vedení společnosti chce z altruistických důvodů zvyšovat úroveň kvality výrobků – to vůbec ne! Zvyšování kvality je důležitou podmínkou pro přežití IT společností v podmínkách moderního trhu.

Jednou z disciplín, která výrazně zlepší jak kvalitu samotného vývojového procesu, tak kvalitu výstupního produktu, je Software Configuration Management. Disciplína zahrnuje správu jak verzí softwaru (softwaru), tak změn.

Bohužel v ruském tisku a na ruském internetu prakticky neexistují žádné hodné knihy a články, které by podrobně odhalovaly cíle a záměry procesu a popisovaly je (všechny materiály jsou buď komerční nebo banální přetisky slovo od slova standardů). Navíc je zde nízká kultura vývojářů, kteří považují CC za jakousi totální kontrolu nad sebou samými (ne-li násilí). To je jejich mylná představa. Jakýkoli formalizovaný proces není násilí, ale prospěch, a doufáme, že to vysvětlíme. K naší radosti se situace v Rusku z hlediska postoje k procesu řízení za poslední rok začala dramaticky měnit: začíná vývoj velkých softwarových produktů, jejichž vývoj je bez tohoto procesu nemožný.

Tento materiál je výběrem kapitol z knihy, kterou autoři psali během posledního roku a půl. Knihy se většinou nepíšou rychle, proto bylo rozhodnuto materiál zveřejnit na internetu a sbírat zpětnou vazbu od potenciálních čtenářů.

Článek popisuje historii Configuration Management a základní koncepty, na kterých je tento proces založen. Hlavní aspekty tohoto procesu jsou také diskutovány v prizmatu mezinárodních norem, jako jsou ISO-12207 a CMM. Materiál obsahuje citace z požadavků norem s komentářem autora.

Užitečné odkazy před čtením, abyste se dostali do rychlosti: Problémy vývoje softwaru, Povědomí o potřebě QM, Co je RUP)

Užijte si čtení.

Úvod do správy konfigurace softwaru

Správa konfigurace je základní disciplínou, která určuje, jak jsou spravovány a kontrolovány pracovní položky projektu, jejich změny a stavové informace o jednotlivých úkolech a celém projektu. Úspěch projektu do značné míry závisí na tom, jak dobře je postaven proces správy konfigurace, což může projekt buď zachránit, nebo jej pohřbít, pokud samotný proces CM funguje špatně.

Historie vývoje disciplíny konfigurační management

Prvním významným krokem ve vývoji konfiguračního managementu (zkráceně CM) byl vynález mikrometru v roce 1636 (William Gascoigne). Toto zařízení sehrálo důležitou roli v průmyslové revoluci a přechodu k hromadné výrobě. Tento nástroj umožnil použití vyměnitelných dílů v různých zařízeních, což byl významný důvod pro použití postupů správy konfigurace.

První inženýrské koncepty, které vedly ke vzniku disciplíny konfiguračního managementu, se začaly formovat na počátku 20. století a reálnou podobu získaly v 60. letech minulého století.

Zpočátku sledovali tvůrci konceptu konfiguračního managementu cíl zlepšit metody vývoje a údržby softwarových nástrojů (Software). „Otcové zakladatelé“ správy konfigurací chtěli vytvořit disciplínu, která by zajistila, že vyvinutý software bude splňovat potřeby uživatelů, pro které byl vyvinut. Studovali úspěšné projekty a shrnuli zkušenosti s používáním těch technologií, které se osvědčily. Dalším důležitým cílem bylo zajistit snadnou modifikaci a údržbu softwaru a (protože „otcové zakladatelé“ pracovali hlavně pro vládní agentury) možnost pro zákazníka softwaru změnit vývojáře, aniž by musel projít celým cyklem vývoje softwaru od nuly. .

Kromě toho bylo jako další cíl považováno poskytnutí hodnocení stavu projektu na základě vykazování klíčových indikátorů. Zaměřili se na dosahování dlouhodobých cílů a neočekávali, že z používání technologií, které vyvinuli, okamžitě uvidí zřejmé výhody. Je třeba poznamenat, že přínosy tohoto druhu je obtížné kvantifikovat, protože při úspěšném použití správy konfigurace organizace jednoduše přestane plýtvat zdroji na zbytečnou práci. Například znovu opravit chybu, která již byla dříve opravena, ale znovu se objevila kvůli skutečnosti, že při sestavování softwaru byl omylem nahrazen správný kód nesprávným.

Otcové zakladatelé si uvědomili, že nejprve potřebují kontrolovat, jaké části šly do hotového produktu (produkt může znamenat jak hardware, tak vybavení a v širokém slova smyslu jakýkoli produkt sestávající z různých dílů) a jak jsou vzájemně propojeny, a také sledovat změny v jednotlivých částech produktu a v jejich vzájemných vztazích. Zvolili slovo „konfigurace“ ve významu „relativní uspořádání částí“. Slovo „management“ bylo svým významem docela vhodné a výsledkem bylo „řízení konfigurace“.

Vznik základních pojmů správy konfigurace

Poté bylo rozhodnuto, že vyvíjený konečný produkt se bude jmenovat „ konfigurační objekt» ( konfigurační položka). Konfigurační objekty (KO) mohou být stůl nebo letadlo, pokud uvažujeme hardware, nebo software ve formě instalačních balíčků, pokud mluvíme o softwaru.

Jak ale můžete spravovat konfiguraci objektu? Toho lze dosáhnout řízením dokumentů, které popisují konfigurační objekt, jeho požadavky, jeho architekturu a výkresy (nebo model). Tvůrci disciplíny konfigurační management si uvědomili, že takové dokumenty jsou nejdůležitější součástí vývojového procesu a že konfiguraci objektu lze spravovat správou obsahu dokumentů, které tuto konfiguraci popisují.

Spíše než předpokládat, že takové dokumenty lze vytvořit a přesně popsat konfiguraci, bylo nutné záruka. Bylo rozhodnuto, že nejdůležitějším výsledkem procesu správy konfigurace by mělo být zajištění toho, aby byla vytvořena dokumentace, která přesně popisuje konfiguraci aktiva v kterémkoli okamžiku v průběhu projektu. Tvůrci disciplíny QM vycházeli z předpokladu, že pokud máte sadu přesné a aktuální dokumentace, můžete na jejím základě vždy vytvořit novou kopii produktu.

Poté se pustili do identifikace sady dokumentů, které jsou zásadní pro úspěšný vývoj. Takový soubor dokumentů musí obsahovat minimálně požadavky, specifikace, návrhy, modely (výkresy), seznam komponent, zkušební dokumentaci, zdrojové kódy a uživatelskou dokumentaci. K identifikaci některého nebo všech těchto dokumentů popisujících konfigurační objekt pro projekt libovolné velikosti byl zapotřebí společný výraz. Protože hlavním účelem těchto dokumentů bylo „identifikace konfigurace“ objektu, byla tato sada dokumentů nazvána „ identifikace konfigurace» ( identifikace konfigurace). V té době se to zdálo rozumné, ale jen málo lidí si dnes myslí, že „identifikace konfigurace“ znamená „dokumenty“.

Dalším důležitým konceptem, který definuje sadu dokumentů, je „ základní verze» ( základní linie). Základní verze je kompletní sada dokumentů, které tvoří identifikaci konfigurace, odpovídající konkrétnímu časovému okamžiku, tzn. "snímek" konfigurace. Časový okamžik, ve kterém je základní verze vytvořena, obvykle odpovídá nějaké plánované události, jako je dokončení fáze životního cyklu produktu nebo fáze projektu.

Bylo tedy zjištěno, že přesná dokumentace je nejdůležitějším bodem správy konfigurace. Záměrně přitom nebyly uvedeny dokumenty, které by měly vzniknout (kromě dokumentů s náležitostmi).

Základní postupy správy konfigurace

Po stanovení požadavků tedy účastníci projektu pro každý určili seznam zbývajících dokumentů, které tvoří specifikaci konfigurace. Jak ale můžete zajistit, aby byly tyto dokumenty vyrobeny ve správné kvalitě a detailech?

Typicky se používá metoda dekompozice požadavků (neboli „funkční dekompozice“) - požadavky jsou rozloženy na jednotlivé prvky a rozpracovány v dalším vývojovém kroku (návrhu). Detailování pak pokračuje v dalším kroku a tak dále, dokud není dosaženo požadované úrovně detailů.

Dalším způsobem je porovnat vyvíjený dokument s dokumenty vyšší úrovně, které byly schváleny dříve v procesu vývoje. Pro tuto práci byl použit pojem „revize“ s přidáním slova „konfigurace“. " Revize konfigurace"(kontrola konfigurace) je porovnání dokumentu nižší úrovně s jeho předchůdcem nebo dokumentem nejvyšší úrovně, aby se zajistilo, že dokument nižší úrovně splňuje všechny požadavky obsažené v dokumentu nejvyšší úrovně a že nedojde k žádným neočekávaným dodatkům. To umožňuje, aby požadavky na vysoké úrovni byly postupně a pečlivě podrobně rozpracovány do dokumentů nižší úrovně, přičemž se zpřesňuje identifikace konfigurace při vývoji konfiguračního objektu.

Revize konfigurace se také používá ke kontrole funkčnosti produktu na základě dokumentu příslušné úrovně. Například revize zdrojového kódu slouží k tomu, aby byl zdrojový kód napsán v souladu se stanovenými pravidly. Revize konfigurace tedy slouží jak k ověření správné dekompozice dokumentů na všech úrovních, tak ke kontrole těchto dokumentů z hlediska jejich souladu s pravidly, šablonami a formáty používanými pro tvorbu takových dokumentů.

Podobná technika k ověření, že produkt je vytvořen podle zavedených pravidel a požadavků, se používá při provádění „ konfigurační audit» ( konfigurační audit). Audit konfigurace je podobný procesu auditu s tím rozdílem, že objektem auditní aplikace je konfigurační objekt nebo koncový produkt, který je porovnáván s dokumentací, která tvoří jeho identifikaci konfigurace. Předmětem auditní aplikace jsou jednotlivé dokumenty.

Dalším způsobem, jak zajistit přesnost specifikace konfigurace, je mít vyhrazenou skupinu (třeba složenou z jednoho specialisty), která sleduje všechny navrhované změny produktu a zamítá je nebo schvaluje. Tato aktivita se jmenovala " kontrola konfigurace» ( kontrola konfigurace). Skupiny, které provádějí funkce řízení konfigurace, se obvykle nazývají " Změnit kontrolní tým» ( Vyměňte řídící desku) nebo " Kontrolní skupina konfigurace» ( Kontrolní deska konfigurace, zkráceně CCB). Mezi důležité funkce takové skupiny patří sledování, že všechny dokumenty jsou v každém okamžiku relevantní a že při provedení změny se nejprve změní konfigurační identifikační dokumenty a teprve poté samotný objekt změny (zdrojový kód, model , atd.). Změna předmětu po změně jeho popisu je přínosná i v tom, že umělec provádějící změnu na předmětu bude mít možnost seznámit se s popisem této změny před zahájením práce.

Další oblastí odpovědnosti za správu konfigurace bylo podávání zpráv o stavu produktu a stavu schválených změn v průběhu práce. Tato aktivita se jmenovala " účtování stavu konfigurace» ( účtování stavu konfigurace)

Základní pojmy a prvky

Nelze říci, že takové metody práce ještě nikdo nepoužíval. Vývoj dříve probíhal souběžně s dokumentací. Audity dokumentů byly prováděny již dříve. Testování a testování výrobků na shodu s požadavky bylo prováděno již dříve. Reporting se v projektech používal již dříve. Zakladatelé disciplíny konfigurační management udělali něco jiného – všechny tyto techniky používané ve vývoji spojili, uspořádali a pojmenovali tak, že skončili u samostatné disciplíny – konfiguračního managementu.

Během formování disciplíny konfiguračního managementu do ní byly vtěleny následující důležité koncepty:

1. Dokumenty jsou vytvářeny k popisu produktu a jsou prostředkem pro správu konfigurace produktu.
2. Změny produktu jsou řízeny řízením změn dokumentace.
3. Změny produktu se neprovádějí, dokud nejsou provedeny v dokumentaci.
4. Změny musí být před implementací do dokumentace a produktu formálně schváleny.
5. Všechny změny je třeba sledovat.
6. Konfigurační objekty (produkty), dokumenty a jejich verze jsou číslovány a pojmenovány jednotně a jednoznačně (nebo jednoznačně).
7. Hlášení je vedeno o stavu změn, dokumentů a produktů.
8. Každý dokument je pravidelně porovnáván s odpovídajícím dokumentem nejvyšší úrovně, aby se zjistily nesrovnalosti.
9. Produkt jako celek je porovnáván s jeho popisem (identifikace konfigurace) a musí tomuto popisu odpovídat.

Pomocí výše uvedené terminologie správy konfigurace byly tyto koncepty seskupeny do následujících čtyř prvků správy konfigurace:

1. Identifikace konfigurace (Koncept 1)
2. Řízení konfigurace (koncepty 2, 3, 4, 5, 6)
3. Účtování stavu konfigurace (koncept 7)
4. Revize a audit konfigurace (koncepty 8 a 9)

To byl původní koncept správy konfigurace pro software i hardware. Zde prezentovanou původní terminologii pro disciplínu konfiguračního managementu lze nalézt také ve standardu IEEE-STD-610. Dále se podíváme na standardy, které definují základní principy a terminologii správy konfigurace.

Nedostatek jasného porozumění terminologii správy konfigurace, obvykle kvůli nedostatku formálního školení v oboru, často vede k koncepčnímu posunu a zmatku v základních principech CM.

Například základní konfigurační ovládací prvek „identifikace konfigurace“ je často chápán jako název nebo číslování dokumentu nebo produktu, které by mělo odpovídat konceptu „identifikace dokumentu“ nebo „identifikace produktu“. Zatímco pojem „konfigurace“ neodkazuje na dokument nebo produkt. Tento pojem označuje obsah dokumentů, označuje obsah technické dokumentace popisující výrobek. Mimochodem, pravidla pro pojmenování a číslování dokumentů a produktů se vztahují k dalšímu prvku systému řízení - „kontrola konfigurace“ a nazývají se „dohoda o pojmenování a číslování“.

Základy správy konfigurace

Od formálního založení disciplíny konfiguračního managementu, které lze zhruba počítat od zavedení standardu IEEE-STD-610, je uvažováno z různých úhlů pohledu a v různých aplikacích. S používáním postupů správy konfigurace v různých projektech bylo nashromážděno mnoho zkušeností, které byly shrnuty z pohledu různých standardů a modelů softwarového inženýrství.

Proces správy konfigurace se skládá z následujících vzájemně souvisejících činností:

• identifikace konfigurace artefaktů (pracovních materiálů) použitých nebo vytvořených během projektu;
• kontrola konfigurace, včetně informací o dopadu změn na organizační a řídící strukturu, aktuální priority úkolů, zdroje a stav projektu;
• zohlednění stavu konfigurace na základě stavu artefaktů použitých při vývoji, při vydávání hotových verzí softwaru nebo jejich údržbě;
• revize a audit konfigurace, při kterém se posuzuje stav a připravenost produktu;
• postupy pro řízení uvolňování produktů, dodávky a monitorování stavu projektu;
• kontrola verzí projektových pracovních materiálů, zajištění opakovatelnosti montáže produktu na základě jeho základních verzí.

Mezi hlavní prvky procesu správy konfigurace patří (viz obrázek 1.) následující čtyři prvky:

1. Identifikace konfigurace.
2. Kontrola konfigurace.
3. Účtování stavu konfigurace.
4. Revize a audit konfigurace.

Obrázek 1. Základní prvky procesu správy konfigurace

Pojďme se blíže podívat na složení každého z těchto prvků.

Identifikace konfigurace je založena na následujících komponentách:

• pravidla identifikace a číslování - co se identifikuje a jak;
• identifikace požadavků na produkt - jak jsou identifikovány požadavky na software;
• identifikace změn v datech - jak jsou změny v datech identifikovány;
• základní verze - vytvořené pro opravu stabilních stavů systému a používají se jako kandidáti na vydání softwaru;
• specifikace a schémata - dokumenty popisující specifikaci konfigurace softwaru a schémata používaná pro stejné účely;
• identifikace dat podle vydání - metody, které umožňují jednoznačně porovnávat konfigurační prvky softwaru a jejich verze s konkrétní verzí softwaru.

Řízení konfigurace zahrnuje:

• kritéria pro schválení změny - definovat formální kritéria, na základě kterých se rozhoduje o schválení nebo zamítnutí navrhované změny;
• specifikace, modely, dokumentace atd. - všechny tyto konfigurační prvky podléhají změnám a spadají pod kontrolu konfigurace;
• postupy kontroly konfigurace – schválené postupy, které musí účastníci projektu dodržovat;
• organizace řízení změn - organizační složka procesu, která určuje odpovědnost účastníků projektu při provádění postupů kontroly konfigurace.

Zohlednění stavu konfigurace zahrnuje:

• udržování historie změn konfigurace produktu – určuje, kdo a kdy provedl jaké změny;
• udržování historie stavů schválených změn - ukazuje, jak se změnily stavy schválených změn od okamžiku schválení do okamžiku jejich dokončení;
• udržování historie ověřování konfigurace - ukládá data o všech provedených ověřeních a jejich výsledcích;
• účtování autorizace změn - uvádí, kdo je odpovědný za provedené změny.

Revize a audit konfigurace zahrnuje:

• formální kvalifikační audity - zjišťují shodu konfiguračních prvků s formálními požadavky na ně kladenými, např. soulad s konkrétní šablonou dokumentu;
• audit funkční konfigurace - zjišťuje shodu softwarové konfigurace s funkčními požadavky na produkt;
• audit fyzické konfigurace - zjišťuje přítomnost či nepřítomnost jednotlivých prvků v konfiguraci.

Správa konfigurací ve standardech

Dosud jsme mluvili o správě konfigurace v širokém smyslu jako o disciplíně. To bylo přípustné, pokud nebyly brány v úvahu normy. Od této chvíle, pokud není výslovně uvedeno něco jiného, ​​budeme uvažovat o procesu správy konfigurace. Níže pojednáváme o standardech, které definují proces správy konfigurace, a také o samotném procesu standardizace z pohledu aplikace CM procedur.

Typy norem

Pro definování základních principů procesu správy konfigurace se zdá rozumné použít existující standardy popisující proces CM. V tomto případě je nutné určit standard, který bude nejlépe vyhovovat potřebám konkrétního podniku.

Všechny normy lze rozdělit do typů v závislosti na šíři jejich působnosti:

1. Mezinárodní normy platné bez omezení ve všech zemích;
2. Státní nebo oborové normy platné pro skupinu podniků nebo organizací sjednocených určitými společnými charakteristikami;
3. Interní standardy podniku, které jsou platné pro konkrétní podnik a zohledňují specifika tohoto podniku.

Některé běžně používané mezinárodní normy jsou uvedeny níže (viz tabulka 1). V tabulce „SCM“ označuje možnost použití standardu pro systémy správy (správa konfigurace softwaru) a „HCM“ - pro zařízení (správa konfigurace hardwaru). Zmíněná tabulka zdůrazňuje tři nejvýznamnější oblasti použití norem:

• akviziční proces, během kterého se zjišťuje stupeň kompatibility nakupovaného produktu se systémy a zařízeními, které se v organizaci již používají;
• proces dodávky/vývoje produktu, pro který je zvláště důležitá koordinace jednání dodavatele/vývojáře a zákazníka produktu při určování identifikace konfigurace, revizí a auditech konfigurace a odsouhlasení změn provedených na produktu;
• data - tento rozsah standardů je zcela specifický a týká se především stanovení dohodnutých formátů a pravidel pro jejich změnu při výměně dat mezi různými odděleními nebo organizacemi.

Tabulka 1. Mezinárodní standardy popisující proces QM

Příkladem průmyslového standardu je MIL-STD-2549, „Configuration Management Data Interface“, který podrobně popisuje požadavky na výměnu dat mezi vládními systémy pro správu konfigurace.

Mezinárodní a oborové standardy neumožňují přímou aplikaci jimi popisovaného procesu na podnikové úrovni, protože samotný popis CM procesu není uveden dostatečně podrobně pro přímé použití.

Obvyklou praxí při používání takových norem je přizpůsobit je potřebám konkrétního podniku. Při úpravě normy se určuje, do jaké míry bude v podniku používán - zcela; kromě určitých situací; jednotlivá ustanovení normy. Dále jsou ustanovení normy upřesněna a doplněna s ohledem na specifika konkrétního podniku.

Chcete-li podrobně popsat proces QM při jeho přizpůsobování, můžete použít metodiky vyvinuté různými mezinárodními organizacemi a společnostmi (například Rational Unified Process). Takové metodiky obvykle obsahují podrobnější popis procesu a často obsahují návod na použití automatizačních nástrojů, což značně zjednodušuje přizpůsobení metodiky. Existují však situace, kdy jsou specifika podniku natolik odlišná od obecných pravidel navrhovaných metodikou, že je snazší si proces řízení podrobně popsat sami, aniž byste byli vázáni na jakoukoli metodiku.

Výsledkem takové adaptace je obvykle interní podnikový standard pro proces konfiguračního managementu. Lze tedy vysledovat následující řetězec:

• Mezinárodní standard - definující obecná ustanovení procesu QM;
• Metodika, která odpovídá vybraným obecným ustanovením - podrobně popisuje proces řízení na základě principů a pravidel prověřených zkušenostmi mnoha společností;
• Podnikový standard - objasnění procesu a jeho přizpůsobení potřebám konkrétního podniku.

Podnikový standard vyžaduje seriózní prostudování jeho ustanovení a práce na jeho zavedení obvykle trvá několik let. Dokud nebude zaveden podnikový standard, mohou mít projekty v platnosti samostatné regulační a organizační dokumenty.

Řízení změn jako nedílná součást procesu řízení

Než přejdeme k podrobné diskusi o popisu procesu CM v jednom ze standardů, je nutné poskytnout určité objasnění týkající se moderního chápání procesu CM a změn, které nastaly od počátečního pochopení disciplíny konfigurace. řízení.

Zpočátku správa konfigurace zahrnovala správu požadavků, správu změn a správu verzí. To je zaznamenáno ve všech hlavních normách vztahujících se k trestnímu zákoníku. Z hlediska standardů softwarového inženýrství tento přístup platí dodnes.

Z teoretického hlediska dává dokonalý smysl držet všechny tři vzájemně související procesy – správu požadavků, správu změn a správu verzí – pod jedním procesem správy konfigurace. V praxi je to ale momentálně jinak.

Těžko říci, zda hlavní příčinou byly skutečné potřeby uživatelů nebo marketingové strategie výrobců nástrojů, ale v současné době je řízení požadavků považováno v naprosté většině projektů za samostatný proces a řízení změn je v polovině projektů považován za samostatný proces a ve druhé polovině - jako součást procesu správy konfigurace. A pouze správa verzí je vždy považována za součást správy konfigurace.

Dále budeme management požadavků považovat za samostatný proces, který není součástí procesu konfiguračního managementu, i když s ním úzce souvisí (ačkoli to odporuje řadě standardů, které nerozlišují management požadavků jako samostatný proces).

Oddělení správy konfigurací a správy změn do samostatných procesů nebo zvažování jediného procesu správy konfigurace z technologického hlediska je malý rozdíl. Problematika separace je posuzována především z pohledu organizační struktury podporující realizaci jednoho procesu nebo dvou vzájemně provázaných procesů a z pohledu využití nástrojů pro automatizaci procesu řízení konfigurace a řízení změn. Autorům se v obou případech podařilo projekty realizovat stejně úspěšně.

Dále, pokud není výslovně uvedeno jinak, bude řízení změn vždy považováno za součást procesu řízení konfigurace v souladu se standardy používanými k definování procesu CM.

Jedna z těchto norem, GOST R ISO/IEC 12207, je popsána níže.

Proces řízení v normě GOST R ISO/IEC 12207

Proč jsme při výběru normy, která definuje proces správy konfigurace, pro podrobné zvážení zvolili GOST R ISO/IEC 12207 „Informační technologie. Procesy životního cyklu softwaru? Existuje pro to několik důležitých důvodů:

1. Norma GOST R ISO/IEC 12207 je ruská norma oficiálně uvedená v platnost na území Ruské federace.
2. Předmětný standard byl vytvořen na základě jednoho z nejpopulárnějších mezinárodních standardů v oblasti informačních technologií - ISO/IEC 12207:1995 (ISO/IEC12207) Standard pro informační technologie - Software Lifecycle Processes.
3. Populární metodologie vývoje softwaru (jako je Rational Unified Process) jsou založeny na normě ISO/IEC 12207:1995 (ISO/IEC12207) Standard pro informační technologie – Procesy životního cyklu softwaru.

Než přejdeme přímo k procesu správy konfigurace definovanému v tomto standardu, krátce zvážíme standard jako celek.

Ruská norma GOST R ISO/IEC 12207 zohledňuje procesy životního cyklu (LC) softwaru a rozděluje je do tří skupin:

1. Základní.
2. Pomocný.
3. Organizační.

Norma GOST R ISO/IEC 12207 stanoví obecnou strukturu procesů životního cyklu softwaru (LC), definuje procesy, práci a úkoly prováděné během životního cyklu softwaru.

Proces správy konfigurace je definován jako podpůrný proces (viz obrázek 2).

Obrázek 2. Procesy životního cyklu rozvodny podle GOST R ISO/IEC 12207.

V souladu s uvažovanou normou se tento proces skládá z následujících prací:

1. příprava procesu;
2. definice konfigurace;
3. kontrola konfigurace;
4. účtování stavů konfigurace;
5. posouzení konfigurace;
6. správa vydání a dodání.

Níže jsou uvedeny stručné popisy všech prací v procesu.

Příprava procesu

Musí být vytvořen plán řízení konfigurace. Plán by měl definovat: činnosti řízení konfigurace; postupy a harmonogram provádění těchto prací; organizace (organizace) odpovědné za provádění těchto prací; spojení této organizace (organizací) s jinými organizacemi, například pro vývoj a údržbu softwaru. Plán musí být zdokumentován a proveden (plán může být součástí plánu řízení konfigurace systému).

Definice konfigurace

Musí být definováno schéma označení pro softwarové objekty a jejich verze (objekty konfigurace softwaru), které jsou řízeny během realizace projektu. Pro každý softwarový objekt a jeho verze musí být definováno: dokumentace, která zaznamenává stav jeho konfigurace; referenční verze a další prvky označení.

Kontrola konfigurace

Analýza a hodnocení změn; přijetí nebo nepřijetí žádosti; implementace, ověření a uvolnění upraveného softwarového objektu. Pro každou změnu musí být provedeny audity, které prověří každou změnu, její důvod a její oprávnění. Všechny ovladatelné softwarové objekty, které jsou spojeny s kritickými bezpečnostními nebo zabezpečovacími funkcemi, musí být kontrolovány a auditovány.

Účtování stavů konfigurace

Měly by být připraveny manažerské záznamy a stavové zprávy, které odrážejí stav a historii změn řízených softwarových objektů, včetně stavu jejich konfigurace. Zprávy o stavu by měly obsahovat počet změn daného projektu, nejnovější verze softwarových položek, označení vydaných verzí, počet vydání a srovnání softwarových položek napříč vydáními.

Vyhodnocení konfigurace

Musí být stanoveno a zajištěno: funkční úplnost softwarových objektů z hlediska realizace požadavků na ně stanovených; fyzická úplnost softwarových objektů z hlediska implementace všech změn provedených v projektu a programech.

Správa a doručení vydání

Vydání a dodávka softwarových produktů spolu s přidruženou dokumentací musí být formálně kontrolována. Původní programy a dokumentace musí být doprovázeny po celou dobu životního cyklu. Programy a dokumentace související s kritickými bezpečnostními nebo zabezpečovacími funkcemi musí být zpracovány, uloženy, zabaleny a dodány v souladu se stanovenými postupy.

Správa konfigurace z pohledu Capability Maturity Model

CMM (Capability Maturity Model) je vyspělý model procesů tvorby softwaru nebo evoluční model pro rozvoj schopnosti společnosti vyvíjet vysoce kvalitní software.

CMM byl původně navržen a vyvinut jako technika, která má pomoci velkým americkým vládním organizacím vybrat nejlepší dodavatele softwaru. K tomu bylo plánováno vytvoření komplexního popisu způsobů hodnocení procesů vývoje softwaru a metod pro jejich další zlepšování. Díky tomu se autorům podařilo dosáhnout takové úrovně detailů, že se standard ukázal jako vhodný pro běžné vývojářské společnosti, které se snaží kvalitativně zlepšit stávající vývojové procesy a dovést je k určitým standardům.

Klíčovým pojmem standardu je vyspělost organizace. Za nezralou je považována organizace, ve které proces vývoje softwaru závisí pouze na konkrétních výkonných lidech a manažerech a řešení jsou často jednoduše improvizovaná „za běhu“ – čemuž se v moderním jazyce říká kreativní přístup nebo umění. V tomto případě existuje vysoká pravděpodobnost překročení rozpočtu nebo překročení termínů dodání projektu, takže manažeři a vývojáři jsou nuceni řešit pouze naléhavé problémy, čímž se stávají rukojmími vlastního softwarového produktu. Bohužel většina firem je v této fázi vývoje (podle gradace CMM je tato úroveň označena číslem 1).

Naproti tomu vyspělá organizace má jasně definované postupy pro tvorbu softwarových produktů a zavedené mechanismy projektového řízení. Všechny postupy a mechanismy jsou v pilotních projektech podle potřeby objasňovány a zdokonalovány. Odhady času a nákladů na dokončení práce jsou založeny na nashromážděných zkušenostech a jsou poměrně přesné. A konečně, společnost má standardy pro procesy vývoje, testování a implementace, stejně jako pravidla pro návrh konečného programového kódu, komponent, rozhraní atd. To vše tvoří infrastrukturu a firemní kulturu, která podporuje proces vývoje softwaru. Technologie vydání se bude projekt od projektu měnit jen nepatrně na základě absolutně stabilních a osvědčených přístupů.

CMM definuje pět úrovní organizační vyspělosti. V důsledku certifikace je firmě přidělena určitá úroveň, kterou lze následně zvyšovat nebo snižovat. Je třeba poznamenat, že každá další úroveň zahrnuje všechny klíčové vlastnosti předchozích.

(1) Vstupní úroveň ( počáteční úroveň) je hlavním standardem. Do této úrovně patří zpravidla jakákoliv společnost, které se podařilo obdržet zakázku, vyvinout a dodat zákazníkovi softwarový produkt. Podniky první úrovně nemají stabilní vývoj. Úspěch jednoho projektu zpravidla nezaručuje úspěch dalšího. Společnosti na této úrovni se vyznačují nerovnoměrným vývojovým procesem – přítomností uspěchaných pracovních míst. Do této kategorie patří jakákoliv společnost, která nějakým způsobem plní své závazky.

(2) Opakovatelná úroveň ( opakovatelná úroveň). Tato úroveň odpovídá podnikům, které mají určité technologie projektového řízení. Plánování a řízení ve většině případů vychází z dosavadních zkušeností. Společnost na této úrovni již zpravidla vypracovala interní normy a zorganizovala speciální skupiny kontroly kvality.

(3) Určitá úroveň ( definovaná úroveň). Úroveň je charakterizována přítomností formálního přístupu k řízení (to znamená, že jsou popsány všechny typické akce nutné pro opakované opakování: role účastníků, formáty dokumentů, prováděné akce atd.). Pro vytvoření a udržení takového standardu v aktuálním stavu již organizace připravila speciální skupinu. Společnost neustále provádí speciální školení ke zvýšení odborné úrovně svých zaměstnanců. Počínaje touto úrovní přestává organizace záviset na osobních kvalitách konkrétních vývojářů a nemá tendenci sklouznout na nižší úrovně. Abstrakce od vývojářů je způsobena promyšleným mechanismem pro nastavování úkolů a sledování provádění.

(4) Řízená úroveň ( řízená úroveň). Úroveň, na které jsou stanoveny kvantitativní ukazatele kvality.

(5) Úroveň optimalizace ( optimalizační úroveň) se vyznačuje tím, že zlepšovací opatření jsou navrhována nejen pro stávající procesy, ale také pro hodnocení efektivity zavádění nových technologií. Hlavním úkolem celé organizace na této úrovni je neustálé zlepšování stávajících procesů, které je ideálně navrženo tak, aby pomáhalo předcházet případným chybám či závadám. K opětovnému použití komponent z projektu do projektu se používá mechanismus, například šablony zpráv, formáty požadavků.

Z gradace úrovní je zřejmé, že technologické požadavky jsou zachovány pouze do 3. úrovně, dále navazují především požadavky na administrativní řízení. To znamená, že úrovně 4 a 5 jsou většinou manažerské a pro jejich dosažení je důležité nejen vydat softwarový produkt, ale také analyzovat postup projektu a také plánovat budoucí projekt na základě aktuálních šablon. Použití těchto přístupů by mělo zajistit systematické a hladké zlepšování používaných procesů.

Přestože lidé v Rusku znají zkratku SMM, většina organizací netuší, jak dosáhnout kvalitativního skoku. A nejde jen o to, že směr tohoto skoku je neznámý, ale že pro každou jednotlivou společnost je poměrně obtížné vybudovat své procesy tak, aby splňovaly požadavky CMM samostatně, bez externího zásahu. Proč znovu vynalézat kolo? Není jednodušší vzít hotový soubor řešení (například metodiku, IBM Rational Unified Process nebo podobně), implementovat je (zde to již můžete udělat sami) a obdržet hotovou sadu řešení pro kvalitní konstrukci procesu Configuration Management a teprve poté pozvat specialisty a získat certifikaci na určitou úroveň? V Rusku již existují příklady společností, které byly certifikovány na vyšší úroveň SMM právě díky implementaci řešení založených na IBM Rational Unified Process. Můžete je najít hledáním na internetu.

Na Západě jsou technologie IBM Rational již dnes široce používány k optimalizaci procesu vydávání softwaru. Důvodů je několik: za prvé, IBM Rational Software je prakticky jediná společnost, která jasně popsala celý produkční cyklus vydávání softwaru (IBM Rational Unified Process), identifikovala všechny možné typy dokumentů doprovázejících projekt a přesně popsala role. (vstupní/výstupní dokumenty, šablony dokumentů atd.) pro každého účastníka projektu. Za druhé, společnost vytvořila speciální software pro kvalitní provedení každé etapy samostatně i celého projektu jako celku. Důležité také je, že IBM Rational prostřednictvím RUP navrhuje přejít od programování jako umění k programování jako vědě, kde je vše jasné a transparentní díky vědeckému přístupu k vývoji. Podle některých odhadů západních analytiků se poměr návratnosti kapitálu před a po implementaci procesů pohybuje od 5:1 do 8:1.

Požadavky na proces řízení v SMM

Správa konfigurace se podílí na včasné identifikaci konfigurace vydaného softwaru (tedy na výběru softwarového produktu a jeho popisu). SCM (Source Configuration Management) poskytuje systematické řízení změn konfigurace, zachování jejich integrity a relevance v průběhu celého životního cyklu projektu. Výsledky vývoje, které jsou doručeny klientovi, jsou řízeny konfiguračním systémem. Také kontroluje všechny dokumenty a výsledky kompilace (dokumenty s požadavky, sestavy, zdrojová data v libovolném programovacím jazyce).

Základní knihovny musí být nainstalovány a obsahovat pracovní verze vydání. Základní verze dále označují sadu verzí zdrojových souborů, které tvoří konkrétní verzi zkompilovaného vydání. Změny v základních řadách softwarových produktů vybudovaných nad základní knihovnou musí být spravovány prostřednictvím řízení změn a auditování konfigurace funkcí v SCM, které plně podporuje Rational ClearCase (řízení verzí).

Všechna data z klíčových oblastí procesů ( Oblast klíčových procesů) pokrývají možné způsoby provádění funkce správy konfigurace. V SMM jsou všechny požadavky na kvalitu prezentovány přesně jako KPA. Každá z těchto metod jasně popisuje konkrétní oblast s formalizovanými požadavky a RUP je schopen tuto oblast uvést do souladu se zadaným požadavkem.

Mechanismy, které identifikují konkrétní konfigurační jednotky, jsou obsaženy v KPA a popisují vývoj a údržbu každé konfigurační jednotky (zdrojové texty, obrázky, dokumentace atd.).

Níže jsou uvedeny požadavky CMM na proces správy konfigurace s bezplatnými komentáři autora. Toto jsou požadavky úrovně 2 a 3. Chtěl bych poznamenat, že implementace správcovské společnosti v souladu s RUP automaticky dává úroveň 3 CMM

Cíle procesu QM:

1. Správa konfigurace probíhá plánovaně

Mnoho společností se při pokusu o instalaci jakéhokoli procesu (bez ohledu na to, co, ale v tomto případě - Správa konfigurace) jsou omezeny pouze na instalaci softwaru s minimálními náklady na další práci. Tímto způsobem byl zničen nejeden projekt. Za prvé, vždy musí být systematická práce. A za druhé, nejprve je proces implementován a poté jsou instalovány automatizační nástroje (určitě ne naopak). Pokud tedy existuje proces, musí existovat dokument, který jej popisuje. Takovým dokumentem pro správcovskou společnost je „Konfigurační plán řízení“, který stanoví koncepci procesu a implementaci automatizačních nástrojů. Popisuje také všechny role a především činnosti v závislosti na fázi životního cyklu vývoje softwaru.

2. Všechny změny probíhají kontrolovaným způsobem

Téměř důsledek z prvního bodu. V projektu nejsou a nemohou být nekontrolované změny.

Povinnosti plnění

1. Projekt se řídí zdokumentovanou organizační politikou

1.1. Za realizaci projektu jsou zodpovědní lidé

Nestačí mít na starosti lidi. Musí být formálně schváleny. Musí existovat dokument (například příkaz), ve kterém jsou jmenováni osoby odpovědné za realizaci.

1.2. CM je implementován během celého životního cyklu vývoje

Nestačí používat CM pouze ve fázi vývoje. CM je implementován v průběhu celého životního cyklu: od obchodního modelování a nastavení požadavků až po zprovoznění a údržbu (pokud je vyvíjený software podporován, pak CM končí až ukončením podpory).

1.3. CM se zavádí pro finální produkty, meziprodukty, experimentální a perspektivní

Často se stává, že vývojářům jsou povoleny přechodné verze, budoucí rozvržení atd. rozvíjet lokálně. Logika managementu je jasná – nechte ho pracovat – přijde čas, vše, co udělal, bude zahrnuto do projektu. Není to správné. Normálně zavedený proces znamená, že všechny změny se provádějí v nástroji pro automatizaci procesů řízení, protože zde je uložena historie změn a komentáře k nim. Pokud totiž vývojář odejde, pak se v případě takové organizace projekt posune dál. A pokud byl vývoj proveden lokálně, můžete ztratit segmenty kódu, což znamená, že ztratíte spoustu času na obnovu.

1.4. Všechny projekty mají své vlastní úložiště

(Pozn.: Zde jsou uvedeny pouze základní požadavky na proces. V normě CMM je jich podstatně více. Vynechání jsou označena „*“. Podrobnější informace o normě lze získat na webu SEI-CMM)

4. Manažerská práce musí být zajištěna zdroji

Velmi často dochází k implementaci procesů podle scénáře: „Vitek nebo Vašek udělají všechno“. Nakonec se nic neudělalo. Proces musí být zajištěn. Musí být jmenovány odpovědné osoby a musí jim být přiděleny další odpovědnosti. Pokud se tak nestane, projekt se velmi brzy rozpadne.

4.1. Jmenování manažera správcovské společnosti

Klíčová role. Tato osoba zná proces vývoje. Rozumí cílům a záměrům správcovské společnosti. Všechny své znalosti stanoví v plánu řízení. Řídí proces řízení sám. Velmi často se snaží buď se bez takové role úplně obejít, nebo ji „tlačit“ na vývojáře. To je přirozeně špatně, protože vývojář nevidí celý obraz procesu vývoje, nemusí rozumět strukturálním interakcím mezi odděleními... atd. Ve výčtu nedorozumění lze pokračovat dále. Nejprve, v raných fázích vývoje, roli manažera přebírá člověk, který má představu o procesu vývoje. Takový člověk se v týmu vždycky najde.

4.2. Jmenování správce správcovské společnosti

Aby vše fungovalo a bylo zkontrolováno, je potřeba člověk, který proces podporuje. Pokud je za jeho logickou harmonii, konzistenci a potřebnou detailnost odpovědný procesní manažer (to vše se promítá do plánu), pak musí administrátor tento koncept implementovat do akce (převést do skriptů, nastavení). Koneckonců, plán je nejvyšší úroveň a jeho realizace je spodní. Správce je tedy odpovědný za implementaci a údržbu procesu. Bez toho se také neobejdete.

4.3. Práce je zajištěna nářadím a vybavením

5. Účastníci CM musí být proškoleni v cílech, postupech a metodách výkonu práce CM

6. Členové týmu pro vývoj softwaru by měli být vyškoleni ve svých úkolech

Problém problémů - nainstalovali nástroj, ale neřekli mi, co mám dělat. Všichni účastníci musí projít školením, aby pochopili, co se od nich vyžaduje z hlediska znalosti nástroje a co musí v projektu udělat. Samozřejmě se obejdete bez tréninku, ale riziko, že věc poděláte, je velmi vysoké, protože nikoho nenapadne posadit za volant auta člověka, který neumí řídit, ale jen slyšel, jak to je hotovo. Zdá se, že ve vývoji softwaru není nic stejné. Přírodní zákony jsou ale všude stejné – nejprve trénink – pak praxe (toto je obecný komentář k bodům 5 a 6).

Operace

1. Pro každý projekt je vypracován plán řízení

Na trestním zákoníku je dobré, že jeho sepsání JEDNOU trvá dlouho. Dále je pro každý projekt napsán nový plán na základě stávajícího, protože metody a metody v novém projektu se mohou lišit, plán také popisuje všechny vlastnosti tohoto projektu. Ale plán se musí vztahovat k tomuto projektu, i když je projekt veden úplně stejným způsobem jako všechny ostatní.

1.1. Plán je vypracován v raných fázích celkového plánování projektu.

Plán musí být připraven v nejranějších fázích, ještě předtím, než vývojáři zapnou počítače.

1.2. Plán je přezkoumán a přezkoumán všemi účastníky procesu

Plán je živý dokument. Plán píší skuteční lidé, kteří mohou dělat chyby. Plán není tajný dokument - měl by být uchováván na viditelném místě, měl by si ho přečíst každý, protože plán popisuje proces vývoje, měli by ho číst PŘEDEVŠÍM nově příchozí vývojáři, testeři a manažeři. Aby byl plán živým plodem lásky, a ne sušeným listem v herbáři, je třeba jej číst a korigovat – zbavit se jazykozpytu a nesprávných formulací. Chyba, jako je nepochopení procesu, vede k prostojům a častým úpravám produktu.

1.3. Plán musí být přístupný a měnitelný

3. Je nainstalován systém knihovny pro správu, který slouží jako úložiště projektu

Vše ve třetím odstavci se netýká ani tak procesu, jako nástroje automatizace. Samozřejmě můžete nastavit proces bez automatizačních nástrojů, ale to bude velmi špatné. Na trhu je spousta nástrojů, které, pokud jsou správně nakonfigurovány, mohou tento proces podporovat. Požadavky na ně jsou uvedeny níže.

3.1. Víceúrovňová podpora pro řízení správy

3.2. Ukládání a načítání položek konfigurace

3.3. Sdílení prvků mezi vývojovými týmy

3.4. Pomoc při aplikaci výrobních standardů CM

3.5. Ukládání a načítání archivovaných verzí

3.6. Zajištění správného vytvoření produktů

3.7. Uchovávání a aktualizace záznamů dle trestního zákoníku

3.8. Podpora hlášení

3.9. Struktura knihovny a podpora obsahu

4. Identifikace přechodných softwarových produktů umístěných v systému řízení

4.1. Výběr prvků na základě zdokumentovaných kritérií

4.2. Položkám úložiště jsou přiřazeny jedinečné identifikátory

4.3. Jsou určeny charakteristiky každého konfiguračního bloku

4.4. Jsou stanoveny základní linie

4.5. Pro každý blok je definována vývojová fáze, do které je umístěn v systému řízení

4.6. Osoba zodpovědná za každý prvek je určena

6. Změny základních verzí (baseline) probíhají kontrolovaným způsobem, v souladu s dokumentovaným postupem

6.1. Provádění validací a regresních testů

6.2. Přidávání pouze schválených konfiguračních bloků do knihovny základních verzí

6.3. Přidávání a odebírání konfiguračních bloků nenarušuje integritu projektu

7. Vytváření produktů na základě knihoven základních verzí a řízení jejich vydávání v souladu s dokumentovaným postupem

7.1. Komise kontroluje tvorbu produktů na základě knihovny základních verzí

7.2. Všechny prvky jsou vytvořeny pouze z konfiguračních bloků obsažených v knihovně základní verze

8. Zaznamenejte stav položek konfigurace v souladu s dokumentovaným postupem

8.1. Evidence úkonů podle trestního zákoníku je prováděna dostatečně podrobně, aby byl zajištěn stav všech prvků

8.2. Být schopen obnovit předchozí verze souborů

8.3. Udržování historie změn

Měření a analýza

1. Provádění měření a využívání jejich výsledků ke zjištění stavu prací na systému managementu

Všechno, co nás v životě potká, se dá změřit. Proces QM není výjimkou – lze jej také měřit. Navíc je to potřeba měřit. Při aktivní práci se totiž v úložišti (úložišti) hromadí obrovské množství statistických informací. Vytváření reportů a analytických částí je nedílnou součástí jak procesu vývoje obecně, tak manažerské společnosti zvláště. Ostatně jen na základě analýzy nasbíraných statistik lze rozhodnout o dalším postupu. SMM specifikuje pouze nejdůležitější sekce a sestavy.

1.1. Přehledy o počtu požadavků za jednotku času

1.2.Zprávy o provádění etap prací dle správcovské společnosti v porovnání s plánem

1.3. Zprávy o objemu provedených prací dle správcovské společnosti

1.4. Zprávy o zdrojích

Místo závěru

Rád bych připomněl, že zde jsou uvedeny pouze nejzákladnější klíče SMM. Zbytek viz standard.

Než však tento článek zavřete, zapište si procesní požadavky předložené SMM a porovnejte je s tím, jak to chodí ve vaší společnosti. Budeme rádi, pokud bude odpovídat alespoň 50 % vašich požadavků!

Pokud tomu tak není, musíte se vážně zamyslet nad zlepšením procesu řízení kvality.

Vytvoření základní konfigurace projektu

Příklad postupu pro vytvoření infrastruktury projektu

K vytvoření infrastruktury, kterou potřebujete:

· zajistit přísun věcných prostředků - potřebné prostředky je nutné objednat nebo vyžádat;

· organizovat instalaci zařízení - zajistit dodávku, instalaci a testování zařízení;

· zajistit údržbu zařízení - vypracovat plán údržby;

· otestovat pracovní prostředí z hlediska jeho kompatibility s požadavky na funkčnost, kompatibilita a dostupnost.

Základní linka nebo fixní konfigurační slice - soubor konfiguračních prvků formálně definovaných a pevných Podlečas během života cyklus JE. V určitých případech základnířádek lze změnit pouze prostřednictvím formálního postupu kontroly změn. Pevný řez v kombinaci se všemi schválenými změnami představuje aktuální schválenou konfiguraci.

Jsou předávány různé konfigurační položky správa konfigurace v různých okamžicích a jsou zahrnuty do základní linie v určitých okamžicích života cyklus. Spouštěcí událostí je dokončení určitých forem formálního schválení úkolu, jako je formální hodnocení. Příklady položek konfigurace zahrnují nakonfigurované moduly IC, uživatelské příručky, testovací plány, Databáze testy a tak dále.

Pro organizaci realizace výše uvedených úkolů ve fázi plánování životního cyklu IS je vypracován plán řízení konfigurace, který stanoví koncepci a definuje prostředky pro automatizaci procesu a také popisuje všechny role a činnosti v závislosti na fázi života cyklus JE.

Plán řízení konfigurace (CM) je vyvíjen v rané fázi plánování a je součástí plán řízení projektu. Struktura plánu řízení závisí na faktorech, jako je typ projektu a jeho trvání, úroveň formalizace procesů, velikost týmu atd. To znamená, že struktura plánu se může výrazně lišit v závislosti na projektu. Dokončeno analýza faktory ovlivňující strukturu plánu.

Přítomnost několika kanceláří tedy komplikuje plán, doplňuje jej o pravidla pro interakci mezi kancelářemi a ovlivňuje celkovou architekturu projektu. Nárůst počtu krajů ovlivňuje úroveň formalismu plánu.

Relativní velikost projekt ovlivňuje množství předpisů a jejich rozpracování a podrobnost. Podrobněji jsou popsány fáze, interakce mezi skupinami a průchod požadavků na změnu. Čím větší je projekt, tím formálnější by měl být plán.

Počet konfiguračních prvků ovlivňuje pouze hlubší propracování identifikace prvků. V některých případech je užitečné definovat všechny typy konfiguračních položek v plánu na základě šablon.

Počet komponent a subsystémů ovlivňuje výběr prvků z úložiště (způsob výběru a přístupu) a hloubku prezentace sekce popisující strukturu katalogu projektů Plán managementu obvykle popisuje všechny fáze života cyklus JE. Někdy je při práci se subdodavateli nutné jasněji identifikovat fázi, ve které je subdodavatel zapojen.

Průběh projektu a plánu významně ovlivňují faktory jako např vývojové nástroje, vývojová platforma (je možný vývoj na několika platformách a pro několik platforem současně). Velký význam mají typ a počet implementačních nástrojů (MC automatizace) a patří jednomu nebo více dodavatelům. Projekt může například používat nástroj pro správu verzí od jednoho dodavatele, ale nástroj pro řízení změn od jiného dodavatele. Typ integrace mezi nástroji, architektura integrace by měly být podrobně řešeny v plánu řízení.

Úroveň formalizace závisí na mnoha faktorech. Při výběru úrovně formálnosti a hloubky prezentace se musíte řídit základními úkoly a cíli. Faktory, jako je složitost projektu, regionální rozptyl, typ projektu a přítomnost subdodavatelů, by měly automaticky podnítit sepsání vysoce formalizovaného plánu řízení. Střední a nízké úrovně mohou být použity v relativně krátkodobých projektech, projektech, které zahrnují malý počet vývojářů. S růstem týmu a rozdělením rolí by měl být plán řízení revidován a úroveň formalizace zvýšena. Tabulka 42 uvádí příklad struktury plánu správcovské společnosti.

V závislosti na velikosti projektu mohou být některé položky plánu přeskočeny.

Během plánovací fáze správy konfigurace je také nutné určit jakou software A Hardware zajistit dosažení cílů projektu, vypracovat plány Podle kontrola a tvorba projektových dokumentů a definování projektových strategií, standardů a postupů k zajištění správa konfigurace dokumentovat, jak budou položky konfigurace identifikovány, organizovány a řízeny.

8.4. Organizace dokumentace stavu položek konfigurace

Příklad postupu ukládání dokumentů.

Veškerá projektová dokumentace je uložena v knihovně projektů. Knihovna je organizována tak, aby zajistila dostupnost dokumentů projektovému týmu; evidence a uchovávání kopií upravených dokumentů; skladování referenčních materiálů včetně dokumentace o normách; podpora administrativních informací o projektu; ukládání aktuálních (pracovních) informací.

Příklad postupu přípravy dokumentu

Všechny projektové dokumenty musí mít titulní stránku, historii revizí, seznam recenzentů a distribuční tabulku.

Titulní strana musí obsahovat předmět dokumentu, autora, datum vytvoření, datum poslední úpravy dokumentu, identifikátor, pomocí kterého lze na dokument odkazovat, číslo verze dokumentu, kdo schvaluje dokument.

Historie změn obsahuje datum změny a autora provedené změny.

Příklad postupu hlášení aktivity

Postup podávání zpráv o činnosti má zavést a udržovat proces podávání zpráv o realizaci projektu. Časové osy projektů jsou řízeny sledováním výsledků provedené práce, které jsou hlášeny jako součást poskytovaných zpráv.

Projektovou dokumentaci budou připravovat projektové týmy po celou dobu projektu, v souladu s plánem práce projektu.

Veškeré projektové podklady budou předloženy zákazníkovi ke schválení a schválení. Otevřené otázky k dokumentu jsou zaznamenány v poslední části každého dokumentu „Otevřené otázky pro tento dokument“ s možnostmi řešení problému. Otevřené problémy, které nelze vyřešit na úrovni projektových týmů a projektového manažera, jsou duplikovány v protokolu problému a otevřeného problému v souladu s postupem řízení problému a otevřeného problému.

Schválené projektové podklady budou tvořit základ pro následné projektové práce.

K dokončení dokumentů bude použit následující software:

· Microsoft Word 2010 - pro přípravu textové části projektových dokumentů;

· Microsoft Project 2010 - pro přípravu projektových záměrů;

· Visio 2010 - pro grafický popis podnikových procesů.

Veškerá projektová dokumentace bude uložena v elektronické podobě v knihovně projektů.

Tabulka 7.3. Struktura plánu správy konfigurace (převzato z)