Uvedení do komerčního provozu informačních systémů GOST. Aplikace státních norem při návrhu informačních systémů

Klíčovým dokumentem definujícím interakci stran při implementaci softwarových řešení je technická specifikace, která obsahuje soubor požadavků na funkčnost softwarového řešení a ověřovacích a akceptačních kritérií. Hlavní otázka, na kterou by měla technická specifikace odpovědět, je: co by měl budoucí systém dělat? Proces přípravy technických specifikací se skládá z vývoje, realizace, koordinace a schválení dokumentu. Zpravidla představuje společnou práci specialistů zákaznické organizace a provádějící organizace. Na této práci se podílejí produktoví IT konzultanti.

Referenční podmínky vydává organizace zákazníka provádějící organizaci ( systémový integrátor) práce na implementaci softwarových řešení, její náplní jsou již dříve vypracované požadavky na IS.

Metodickou podporou pro přípravu technických specifikací je GOST 34.602-89 "Informační technologie. Soubor norem pro automatizované systémy. Automatizované systémy. Technické specifikace pro tvorbu automatizovaného systému“, který definuje seznam požadavků na obsah dokumentu a testování.

V souladu s uvedenou normou obsahuje technická specifikace následující oddíly, které lze rozdělit do pododdílů:

1. obecná informace;
2. účel a cíle tvorby (vývoje) systému;
3. charakteristiky objektů automatizace;
4. Požadavky na systém;
5. skladba a obsah práce na vytvoření systému;
6. postup kontroly a akceptace systému;
7. požadavky na skladbu a obsah prací na přípravě objektu automatizace pro uvedení systému do provozu;
8. požadavky na dokumentaci;
9. vývojové zdroje.

6.7.5. Organizace řízení procesu implementace na základě vytváření společných pracovních skupin

Jako každý projekt i implementační projekt potřebuje svou organizační strukturu, která by měla odrážet rozsah a složitost implementačních úkolů. Taková struktura by měla spojovat odborné znalosti pracovníků funkčních útvarů organizace, znalosti projektového řízení a implementační metodiky softwarový produkt.

Při vytváření organizační struktury pro implementační projekt jsou vypracovány kvalifikační požadavky na účastníky, posouzeny mzdové náklady pro jednotlivé etapy implementace a stanoven potřebný počet účastníků, specifikovány role a oblasti odpovědnosti každého člena týmu, personální zajištění vybrané a vyškolené implementační metodiky a použité nástroje.

Příkladem organizační struktury projektu implementace ERP systému ve velkém průmyslovém podniku může být následující organizační struktura:

• koordinační výbor, který zahrnuje vedení podniku a vrcholové manažery, včetně hlavního projektového manažera, a také vedoucího konzultanta jmenovaného generálním ředitelem;
• projektový manažer a realizační projektový tým, který zahrnuje technický tým, zástupce klíčových uživatelů, konzultanty a zástupce vrcholového managementu.

Organizační struktura projektu může zahrnovat různé spolupracující pracovní skupiny, kterým jsou v rámci projektu přiděleny konkrétní úkoly. To zahrnuje jmenování různých členů pracovních skupin, přiřazení vedoucích týmů a vytvoření struktury zpráv pro podávání zpráv o výkonu každé pracovní skupiny, která je pak konsolidována do celkové zprávy o výkonnosti projektu.

Metodiky implementace přední vývojáři software zajistit určité organizační struktury implementačních projektů a jasné rozdělení rolí s odpovídajícími požadavky na jejich dovednosti a znalosti, zakotvené v dokumentaci. Příkladem je dokumentace pro implementační metodiky AcceleratedSAP, který podrobně definuje role všech účastníků v organizační struktuře projektu vč. a aplikační poradce.

Nutno podotknout, že organizační struktura implementačního projektu nutně zahrnuje produktové IT konzultanty. Organizační struktura projektu SAP tedy zahrnuje vedoucí modulů, kteří jsou odpovědní za každý ze základních modulů plánovaných k implementaci.

Produktoví IT konzultanti se v rámci hlavní organizační struktury podílejí na tvorbě implementační strategie a dále plní určité úkoly v jednotlivých fázích implementace v rámci společných pracovních skupin a plní tyto hlavní odpovědnosti:

• školení členů pracovní skupiny implementační metodiky, použitý v tomto projektu;
• školení uživatelů pro práci se softwarovým produktem;
• Příprava vzdělávacích materiálů;
• odpovědnost za dodržování termínů implementace konkrétních modulů softwarového produktu;
• vypracování potřebné dokumentace;
• pomoc v procesu přizpůsobení softwarového produktu formulovaným požadavkům;
• vývoj a řízení metodiky testování pracovní skupina během testování;
• sledování výsledků implementace a provádění nezbytných úprav;
• diskuse uživatelských komentářů a identifikovaných úzkých míst projektu;
• uživatelské konzultace.

6.7.6. Práce při stanovení hranic projektu a plánu realizace

Základem pro přípravu projektové charty je standard ANSI PMI PMBOK® 3-rd Edition (2004) - hlavní standard, který popisuje všechny procesy projektového řízení.

Charta projektu je prvním oficiálním dokumentem projektu, který formálně potvrzuje existenci projektu. Tento dokument dává projektovému manažerovi právo používat zdroje organizace v projektových operacích.

Charta může obsahovat:

• obecný popis projektu (vedoucí, zahájení projektu, dokončení projektu, stručný popis);
• účel nebo zdůvodnění projektu, cíle projektu;
• hranice projektu (hlavní vykonávaná práce);
• výsledky projektu, systém opatření (způsoby hodnocení výsledků), skladba a struktura zpráv o projektech;
• organizační struktura projektu;
• popis funkcí rolí účastníků projektu;
• popis interakčních postupů;
• plán milníky(hlavní data);
• popis postupů pro řízení změn, problémů a rizik;
• rozpočet projektu.

V procesu přípravy Charty projektu a základního plánu je hlavními úkoly produktového IT konzultanta stanovení rozsahu implementačního projektu, výběr implementační strategie a strategie nasazení (stanovení plánu nasazení systému z pilotního místě ke zbytku, vymezenému rozsahem prováděcího projektu), plánování projektové aktivity.

Pro stanovení rozsahu projektu je nutné identifikovat ty typy činností a oddělení, kterých se automatizace dotkne.

Vymezení hranic projektu se provádí ve fázi předběžného průzkumu organizace. Během předběžného průzkumu se shromažďují všechny makro informace o organizaci: informace o organizaci funkční struktura, oblasti činnosti, vykonávané práce a služby, rozsah organizace. Hranice projektu jsou konkrétní seznam prací nebo obchodních procesů, které jsou ovlivněny automatizací. Hranice projektu jsou základem pro určení načasování projektu a jeho nákladů a plánování projekční práce.

Na základě informací získaných na základě předběžného průzkumu produktový IT konzultant vygeneruje zprávu upravující hranice projektu. Vytyčené hranice projektu jsou výchozí informací pro vypracování charty projektu.

Implementační strategie definuje přístup k implementaci softwarového produktu v organizaci. Přední softwaroví vývojáři používají různé implementační strategie. Například při implementaci ERP systémů se obvykle používají strategie „Big Bang“, „Step by Step“ a pilotní implementace.

Princip „Big Bang“ spočívá v současné implementaci všech funkčních modulů softwarového produktu a výměně starých systémů.

Při přístupu „Krok za krokem“ je implementace funkčních modulů rozložena v čase, kdy po ukončení jedné implementace začíná další.

Během pilotní implementace je v určitém oddělení podniku implementován prototyp budoucího systému, který je v případě úspěchu distribuován do dalších oddělení s ohledem na nasbírané zkušenosti. V tomto případě může být samotný prototyp implementován podle principu „Big Bang“ nebo „Step by Step“. Po dokončení pilotní projekt Prototyp systému je přenesen do zbývajících oblastí v souladu se strategií nasazení. Vzhledem ke specifikům stránek se zpravidla provádějí minimální změny.

Výběr vhodných implementačních a implementačních strategií je rozhodující pro úspěch implementačního projektu.

Na základě přijatých strategií, s přihlédnutím ke stanoveným cílům projektu, přiděleným zdrojům a financím, a základní plán realizační projekt.

Základní linie projektu (náklady, harmonogram) – úředně schválený dokument, podle kterého se měří výkon projektu a který se používá k řízení a sledování realizace projektu. Tento plán obsahuje plán rozvoje zdrojů a plán rozpočtu, rozvrh kalendáře, který určuje načasování různých projektových milníků. Takový plán není statický, je vylepšován, jak projekt postupuje a prochází různými fázemi. Základní plán projektu obvykle zahrnuje:

• seznam etap, dílčích etap, úkolů a jejich vztahů;
• termíny plnění etap, dílčích etap, úkolů včetně všech typů činností, které jsou zahrnuty v harmonogramu realizace;
• termíny pro poskytování výsledků;
• pracovní náročnost etap;
• plánované zdroje po etapách.

6.7.7. Vývoj dokumentu "Návrh systému".

Dokument „Návrh systému“ odpovídá na zásadní otázku implementačního projektu: jak systém postavíme, aby splňoval požadavky na něj kladené. Během jeho vývoje se provádí finální detaily a dokumentace všech požadavků organizace týkajících se určitých obchodních procesů a je stanoveno nezbytné přizpůsobení softwarového produktu specifikacím uživatelského rozhraní.

Při vývoji dokumentu System Design provádějí konzultanti IT produktů další sběr informací, aby potvrdili a vyjasnili požadavky; demonstrovat uživatelům standardní funkčnost softwarového produktu na základě testovacích dat, která je doprovázena vyplněním dotazníků s názory uživatelů; identifikovat mezery mezi standardní funkčností softwarového produktu a požadavky; vypracovat vhodná doporučení a opatření k jejich odstranění.

Na základě analýzy pokrytí požadavků standardní funkčností softwarového produktu; analýza souladu formulářů dokladů a výkazů podniku s formuláři dokladů a výkazů standardně generovanými v softwarový produkt, produktový konzultant IT sestavuje seznam nezbytných úprav softwarového produktu, aby jej přizpůsobil charakteristikám organizace, koordinuje základní rozhodnutí, dokumentuje rozvržení zpráv a primárních formulářů a vyvíjí předpisy pro uchovávání regulačních a referenčních informací.

Vzhledem k tomu, že v době realizace projektu může organizace používat i jiný software, jsou při provádění zadaných prací vyřešeny i otázky exportu a importu informací a organizace přenosu dat ze starých systémů do nového.

Výsledkem provedených prací je dokument „Návrh systému“ a technické specifikace pro provedení nezbytných úprav. V souladu s technickými specifikacemi organizace provádějící práce finalizuje funkčnost systému.

6.7.8. Správa procesu nastavení softwarového produktu

Konfigurace softwarového produktu v souladu s formulovanými funkčními požadavky a s přihlédnutím k charakteristikám podnikových procesů je dlouhý a pracný proces, protože při provádění této práce je implementována logika každého z podnikových procesů a je vytvořeno uživatelské rozhraní. vytvořené.

Tyto práce jsou prováděny na základě vypracovaného dokumentu „Návrh systému“ a odpovídajících technických specifikací. Produktový konzultant IT se podílí na řízení procesu přizpůsobení softwarového produktu stanoveným požadavkům.

V obecný případ v této fázi jsou obchodní procesy softwarového produktu nakonfigurovány v souladu s obchodním modelem organizace; jsou vytvořeny potřebné šablony pro zprávy a primární dokumenty; prostředky se vyvíjejí export-import dat S softwarová řešení již v podniku působí; adresáře a klasifikátory jsou nakonfigurovány; Další aplikační moduly se vyvíjejí.

Během procesu řízení přizpůsobení produktový IT konzultant sestaví plán a scénáře pro testování modifikace softwarového produktu. Testování vám umožňuje ujistit se, že nakonfigurovaný softwarový produkt funguje bez něj softwarové chyby a splňuje dohodnuté doménové a organizační požadavky. Pokud jsou zjištěny chyby, provádějí se práce na jejich odstranění.

Kromě toho během procesu nastavování softwarového produktu produktový konzultant používá testovací data, aby uživatelům ukázal, jak jsou v softwarovém produktu prováděny nakonfigurované obchodní procesy; koordinuje komentáře a změny. Paralelně s demonstrací layoutu softwarového produktu vede školení pro koncové uživatele, podílí se také na dokumentaci konfigurace a přípravě dokumentace pro koncové uživatele.

6.7.9. Práce na řízení procesu tvorby pilotní verze informačního systému

Praktické zkušenosti ukazují, že práce na vytvoření informačního systému na základě vybraného softwarového produktu se zejména u velkých projektů doporučuje začít již od pilotní projekt. Pilotní projekt implementace zahrnuje implementaci softwarového produktu v samostatné oblasti v rámci vybraných prioritních funkcí. Získané zkušenosti pak přenáší do dalších funkcí a divizí.

Pilotní projekt je prototypem informačního systému, který implementuje omezená funkčnost, nebo pokrývá užší rozsah implementace, případně ukládá a zpracovává část dat. Jeho úkolem je identifikovat efekt zavedení daného softwarového produktu za účelem přijetí konečné rozhodnutí o proveditelnosti realizace v plném rozsahu a vytvoření základu pro plánování prací na prováděcím projektu.

Produktový IT konzultant se zabývá otázkami plánování pilotní projekt. Podílí se na práci na ověření připravenosti pilotních zařízení (vybraných oblastí) k implementaci, vyhodnocuje potřebné zdroje a sestavuje plán převodu dat ze starých systémů do nový systém a plán pro provádění akceptačních testů, provádí školení uživatelů.

V rámci prováděných prací produktový IT konzultant koordinuje a schvaluje případné změny, podle kterých se finalizuje softwarový produkt a dokumentace.

Po dokončení práce se produktový IT konzultant podílí na přípravě zprávy obsahující výsledky pilotní projekt.

6.7.10. Školení pracovníků organizace v metodice implementace a používání vybraného IT řešení

Proces školení personálu organizace je podporován školicí strategií, technologií a školicími nástroji.

Strategie školení je vypracována s ohledem na fáze a rozsah implementace softwarového produktu. Produktový IT konzultant stanoví obecný přístup ke školení, naplánuje hlavní etapy a činnosti pro školení a certifikaci získaných znalostí personálu, sestaví harmonogram školení, provede předběžný výpočet počtu studentů a popíše potřebné zdroje pro trénink.

Vzdělávací technologie obsahuje seznam školení, pro které odpovídá výukové programy a je podporována školicími nástroji.

Skladba tréninkového nástroje je obvykle následující: dokumentace k popisu funkčnost softwarový produkt; učební pomůcky; praktické úkoly k učení a učební materiály; výukovou kopii softwarového produktu naplněnou testovacími daty pro předvedení a školení; další automatizované školicí nástroje, např. testovací systémy, elektronické vzdělávací materiály.

Dokumentace strategie a technologie výcviku se provádí formou zpracování speciální zprávy, včetně popisu přístupů k výcviku, výcvikových kurzů a výcvikových programů, používaných výcvikových nástrojů, zdrojů potřebných pro výcvik, osnovy a výcvikového řádu.

Produktový IT konzultant se podílí jak na vývoji školicích nástrojů, tak na přípravě zprávy dokumentující školicí strategii a technologie.

Mezi funkční povinnosti produktového IT konzultanta patří školení projektového týmu implementační metodiky a školení uživatelů. V souladu s vypracovaným plánem tréninkového kalendáře vede předepsané tréninky. Je třeba poznamenat, že školení personálu zahrnuje nejen vedení školení, ale také certifikaci schopnosti personálu zajistit fungování softwarového produktu a vykonávat práce nezbytné pro implementaci.

6.7.11. Organizace zkušebního provozu informačního systému a vývoj zkušebních metod

Informační systém založený na zvoleném softwarovém produktu musí prokázat svoji výkonnost.

Testování informačního systému je proces kontroly plnění stanovených funkcí systému, zjišťování a ověřování souladu kvantitativních a kvalitativních charakteristik systému s požadavky technických specifikací, identifikace a odstranění nedostatků v akcích systému, ve vypracované dokumentaci.

V souladu s GOST 34.603-92 "Informační technologie. Typy testování automatizovaných systémů" pro informační systémy Jsou stanoveny tyto typy zkoušek: předběžná, zkušební provoz, přejímka.

Předběžné testy provedené poté, co vývojář odladil a otestoval dodaný software a technické prostředky systémy a předání jim příslušných dokladů o jejich připravenosti ke zkouškám, jakož i po seznámení personálu s provozní dokumentací.

Zkušební provoz se provádí za účelem zjištění skutečných hodnot kvantitativních a kvalitativních charakteristik informačního systému a připravenosti personálu pracovat v podmínkách jeho fungování, zjištění skutečné účinnosti informačního systému a přizpůsobení ( v případě potřeby) dokumentaci.

Při organizování zkušební provoz informačního systému, úkolem produktového IT konzultanta je vypracovat dokument „Program a metody testování“.

Dokument "Program a metodika testování" obsahuje:

• podmínky a postup fungování částí informačního systému a informačního systému jako celku;
• doba trvání zkušební provoz, postačující k ověření správné funkce informačního systému při výkonu každé funkce systému a připravenosti personálu k práci v provozních podmínkách informačního systému Dílo je ukončeno vydáním osvědčení o absolvování; zkušební provoz a připuštění k přijímacím zkouškám.

  6.7.12. Řízení zavádění informačního systému do komerčního provozu a tvorba jeho předpisů

  Úkolem řízení zavádění informačního systému do komerčního provozu je příprava a schválení podrobného plánu přechodu na nový systém a plánu jeho další podpory, provádění přejímací zkoušky informační systém. Této práce se účastní produktový IT konzultant.

  Jak již bylo zmíněno, akceptačnímu testování informačního systému by měl předcházet jeho zkušební provoz. Na základě výsledků zkušební provoz Získané zkušenosti jsou šířeny do všech oblastí v rámci projektu v souladu s přijatou strategií nasazení informačního systému.

  Přejímací zkoušky informačního systému jsou prováděny za účelem zjištění jeho souladu s technickými specifikacemi a hodnocení kvality zkušební provoz a vyřešení otázky možnosti přijetí informačního systému do komerčního provozu.

  V souladu s GOST 34.603-92 "Informační technologie. Typy testování automatizovaných systémů" dokument "Program přejímací zkoušky"obsahuje:

  • seznam objektů přidělených v systému pro testování a seznam požadavků, které musí objekty splňovat (s odkazem na články technických specifikací);
  • akceptační kritéria pro systém a jeho části;
  • podmínky a načasování testování;
  • testovací zařízení;
  • jména osob odpovědných za testování;
  • zkušební metody a zpracování jejich výsledků;
  • seznam dokončené dokumentace.

  Přijímací testy zahrnují kontrolu:

  • úplnost a kvalita implementace funkcí při standardních, mezních, kritických hodnotách parametrů objektu automatizace a v dalších podmínkách fungování informačního systému uvedených v technických specifikacích;
  • splnění každého požadavku týkajícího se rozhraní systému;
  • zaměstnanci pracují v interaktivním režimu;
  • prostředky a metody pro obnovu funkčnosti informačního systému po poruchách;
  • úplnost a kvalita provozní dokumentace.

  6.7.13. Organizace sledování výsledků implementace informačního systému a provádění nezbytných úprav

  Produktový IT konzultant ve stanoveném časovém rámci provádí práce na organizaci sledování provozu informačního systému a provádění nezbytných úprav. Tyto práce jsou zaměřeny na zlepšení účinnosti a výkonnosti informačního systému. Obvykle zahrnují následující činnosti:

  • dodatečné školení uživatelů;
  • konzultace s uživateli;
  • sledování výkonu informačního systému;
  • analýza získaných výsledků monitoringu a vypracování doporučení pro provedení nezbytných změn
  • řízení procesu provádění změn a modernizace informačního systému;
  • vývoj další dokumentace, provádění změn stávající dokumentace.

Výnosem Státního výboru pro normy SSSR ze dne 14. května 1980 č. 2101 bylo stanoveno datum zavedení

od 01.01.1981

Tato norma platí pro technickou dokumentaci pro automatizované řídicí systémy (ACS) všech typů, vyvinutou pro všechny úrovně řízení (kromě národních), a stanoví požadavky na obsah dokumentů zpracovaných ve fázi „Uvádění do provozu“ v souladu s požadavky GOST 24.101-80

1. OBECNÁ USTANOVENÍ

1.1. Dokumenty vytvořené ve fázi „Uvedení do provozu“ jsou klasifikovány jako přejímací dokumentace pro automatizovaný řídicí systém.

1.2. Při zpracování podkladů pro části automatizovaného řídicího systému je obsah dokumentů omezen na rámec odpovídající části automatizovaného řídicího systému.

1.3. V závislosti na účelu a specifických vlastnostech vytvořených automatizovaných řídicích systémů je dovoleno zahrnout do dokumentů další informace, jejichž obsahové požadavky nejsou touto normou stanoveny.

2. POŽADAVKY NA PŘEJÍMACÍ DOKLADY

2.1. Osvědčení o dokončení práce

2.1.1. Dokument je určen k zaznamenání skutečnosti dokončení samostatné práce při vytváření automatizovaného řídicího systému.

2.1.2. Dokument se nevztahuje na stavební, instalační a uvádění do provozu.

2.1.3. Dokument musí obsahovat:

• název dokončených prací;
• seznam zástupců developerské organizace a zákaznické organizace, kteří zákon vypracovali;
• datum dokončení práce;
• název dokumentu (dokumentů), na jehož základě byla práce provedena;
• hlavní výsledky dokončené práce;
• závěr o výsledcích dokončené práce.

2.2. Osvědčení o převzetí do zkušebního provozu

2.2.1. Dokument je určen k evidenci ukončení zprovoznění automatizovaného řídicího systému jako celku nebo jeho částí do zkušebního provozu.

2.2.2. Dokument musí obsahovat:

• název automatizovaného řídicího systému (nebo jeho části) přijatého do zkušebního provozu a odpovídajícího řídicího objektu;
• složení přijímací komise a podklady pro její práci (název, číslo a datum schválení dokumentu, na jehož základě komise vznikla);
• skladba funkcí automatizovaného řídicího systému (nebo jeho části) přijatého do zkušebního provozu;
• seznam součástí technické, softwarové, informační a organizační podpory vyzkoušených ve zkušebním provozu;
• hlavní výsledky převzetí do zkušebního provozu;
• rozhodnutí komise o převzetí automatizovaného řídicího systému do zkušebního provozu.

2.3. Osvědčení o převzetí do průmyslového provozu

2.3.1. Dokument je určen k zaznamenání skutečnosti uvedení automatizovaného řídicího systému (nebo jeho části) do komerčního provozu.

2.3.2. Dokument musí obsahovat:

• název řídicího objektu a automatizovaného řídicího systému (nebo jeho části) přijatého ke komerčnímu provozu;
• informace o stavu přijímací komise (státní, meziresortní, resortní), jejím složení a podkladech pro její práci;
• dobu práce komise;
• název vývojářské organizace, spoluprovádějící organizace a zákaznické organizace;
• název dokumentu, na jehož základě byl automatizovaný řídicí systém vyvinut;
• složení funkcí automatizovaného řídicího systému (nebo jeho části) přijatého pro komerční provoz;
• seznam součástí technické, softwarové, informační a organizační podpory přijatých ke komerčnímu provozu;
• seznam dokumentů předložených komisi;
• závěr o výsledcích zkušebního provozu automatizovaného řídicího systému;
• posouzení souladu přijatého automatizovaného řídicího systému s technickými specifikacemi pro jeho vytvoření;
• stručná charakteristika a hlavní výsledky práce provedené na vytvoření automatizovaného řídicího systému;
• posouzení vědecké a technické úrovně automatizovaného řídicího systému (na základě konstrukčních dat) * ;
• posouzení ekonomické efektivity z implementace automatizovaných řídicích systémů (na základě konstrukčních dat) * ;
• rozhodnutí komise;
• doporučení komise pro další rozvoj systému *.

2.3.3. K „Osvědčení o převzetí do průmyslového provozu“ je přiložen program a protokoly o zkouškách, zápisy z jednání komise, potvrzení o převzetí do průmyslového provozu dříve přijatých částí automatizovaného řídicího systému a seznam technických prostředků, které komise použila při přijímání automatizovaného řídicího systému. Podle uvážení komise je povoleno zahrnout do žádosti další dokumenty.

2.4. Pracovní rozvrh

2.4.1. Dokument stanoví seznam prací, termíny a vykonávající práce související s vytvořením díla.

2.4.2. Dokument pro každé dílo zahrnuté v seznamu musí obsahovat:

• název práce;
• datum zahájení a ukončení práce;
• název jednotky podílející se na práci;
• příjmení a funkce odpovědného exekutora;
• vzorec pro prezentaci výsledků práce.

2.5. Zakázka

2.5.1. V závislosti na fázi práce na vytvoření automatizovaného řídicího systému byly stanoveny následující typy dokumentů:

• nařízení o připravenosti řídícího zařízení pro stavební a instalační práce;
• příkaz k připravenosti kontrolního zařízení k provádění seřizovacích prací;
• příkaz k zahájení zkušebního provozu automatizovaného řídicího systému (jeho částí);
• za účelem uvedení automatizovaného řídicího systému (jeho částí) do komerčního provozu.

2.5.2. Dokument „Příkaz o připravenosti řídicího zařízení pro stavební a instalační práce“ musí obsahovat:

• zpráva o připravenosti řídícího objektu provést stavební a instalační práce;
• určení zóny výstavby a instalace;
• postup pro přijetí do práce;
• seznam zástupců zákaznické organizace odpovědných za práci a bezpečnost instalovaného zařízení;
• seznam odpovědných zástupců stavebních a montážních organizací provádějících práce.

2.5.3. Dokument „Příkaz o připravenosti kontrolního objektu k provedení seřizovacích prací“ musí obsahovat:

• zpráva o připravenosti řídicího objektu provést seřizovací práce;
• seznam technického vybavení automatizovaného řídicího systému k úpravě;
• pokyny k postupu provádění seřizovacích prací;
• postup pro přijetí k zadávacím pracím;
• seznam zástupců zákaznické organizace odpovědných za uvedení do provozu;
• seznam odpovědných zástupců organizací provádějících uvádění do provozu;
• pokyny k postupu při odstraňování chyb při instalaci a osob odpovědných za provádění těchto prací.

2.5.4. Dokument „Příkaz k zahájení zkušebního provozu automatizovaného řídicího systému (jeho částí)“ musí obsahovat:

• název automatizovaného řídicího systému jako celku nebo jeho částí ve zkušebním provozu;
• načasování zkušebního provozu;
• seznam úředníků zákaznické organizace a developerské organizace odpovědných za provedení zkušebního provozu;
• seznam oddělení zákaznické organizace účastnících se zkušebního provozu.

2.5.5. Dokument „Příkaz k uvedení automatizovaného řídicího systému (jeho částí) do komerčního provozu“ musí obsahovat:

• složení funkcí automatizovaného řídicího systému nebo jeho částí, hardware a software přijaté pro komerční provoz;
• seznam úředníků a seznam divizí zákaznické organizace odpovědných za provoz automatizovaného kontrolního systému;
• postup a načasování zavádění nových forem dokumentů (v případě potřeby);
• postup a načasování převedení prvozaměstnanců do práce v provozních podmínkách automatizovaného řídicího systému.

2.6. Usnesení o složení přijímací komise

Dokument musí obsahovat:

• název převzatého automatizovaného řídicího systému jako celku nebo jeho částí;
• informace o složení komise;
• základ pro organizaci komise;
• název zákaznické organizace;
• název vývojářské organizace, spoluprovádějící organizace;
• účel a cíle komise;
• datum zahájení a ukončení práce komise;
• pokyny na formuláři pro dokončení práce komise.

2.7. Pracovní program

2.7.1. V závislosti na obsahu práce jsou stanoveny následující typy dokumentů:

• testovací program;
• pilotní operační program;
• pracovní program přejímací komise.

2.7.2. Dokument „Program zkoušek“ má stanovit postup a rozsah předběžných zkoušek při převodu do zkušebního provozu a přejímacích zkoušek při převodu automatizovaných řídicích systémů do komerčního provozu.

Dokument musí obsahovat:

• složení funkcí automatizovaného řídicího systému jako celku nebo jeho částí, které mají být testovány, s odkazem na odstavce „Zadání“ pro vytvoření automatického řídicího systému;
• seznam součástí technické, softwarové, informační a organizační podpory, které podléhají testování;
• postup testování jednotlivých komponent automatizovaného řídicího systému a jednotlivých funkcí automatizovaného řídicího systému;
• podmínky a načasování testování;
• postup registrace testů a zjištěných nedostatků;
• postup při odstraňování nedostatků a provádění nezbytných změn technické dokumentace;
• pokyny k formě prezentace výsledků testu.

2.7.2. Dokument „Program zkušebního provozu“ má stanovit postup a rozsah zkušebního provozu.

Dokument musí obsahovat:

• složení funkcí automatizovaného řídicího systému a jeho částí podléhajících zkušebnímu provozu s odkazem na doložky technických specifikací pro vytvoření automatického řídicího systému;
• seznam součástí technické, softwarové, informační a organizační podpory, které jsou předmětem zkušebního provozu;
• postup pro personální úkony při zkušebním provozu prvků automatizovaného řídicího systému a jednotlivých funkčních subsystémů;
• podmínky a načasování zkušebního provozu;
• postup evidence výsledků zkušebního provozu a zjištěných nedostatků;
• postup při odstraňování zjištěných nedostatků a provádění změn technické dokumentace;
• pokyny na formuláři pro předkládání výsledků zkušebního provozu.

2.7.2. Dokument „Pracovní program přejímací komise“ má stanovit postup pro přijetí automatizovaného řídicího systému do komerčního provozu. Složení a obsah dokumentu jsou stanoveny podle regulačních a technických dokumentů schválených v daném odvětví.

2.8. Protokol o zkoušce

2.8.1. Dokument je určen k zaznamenání výsledků předběžných zkoušek při převodu automatizovaného řídicího systému jako celku nebo jeho částí do zkušebního nebo průmyslového provozu.

2.8.2. Dokument musí obsahovat:

• název testovacího objektu;
• seznam úředníků, kteří test provedli;
• účel testování;
• informace o délce trvání zkoušek;
• seznam položek technických specifikací pro vytvoření automatizovaného řídicího systému, pro jejichž dodržování byly provedeny zkoušky;
• seznam položek „Programu testování“, pro které byly testy provedeny;
• informace o výsledcích pozorování správného fungování automatizovaného řídicího systému;
• informace o poruchách, poruchách a nouzových situacích, které vznikly během testování;
• informace o úpravách parametrů zkoušeného objektu a technické dokumentaci.

2.9. Protokol dohody

2.9.1. Dokument je určen ke koordinaci odchylek od dříve přijatých a schválených konstrukčních rozhodnutí, kdy během zkušebního provozu automatizovaného řídicího systému jako celku nebo jeho částí byla odhalena potřeba jejich úpravy.

2.9.2. Dokument musí obsahovat:

• seznam uvažovaných odchylek s uvedením dokumentu, jehož odchylky od požadavků podléhají schválení;
• seznam úředníků, kteří protokol sestavili;
• zdůvodnění přijatých odchylek od rozhodnutí o návrhu;
• seznam sjednaných odchylek a lhůt pro provedení nezbytných změn technické dokumentace.

Znovu vydat. května 1986

Uvedení informačního systému do provozu se skládá z následujících fází:

• 1) uvádění technického zařízení do zkušebního provozu;
• 2) zprovoznění softwaru do zkušebního provozu;
• 3) školení a certifikace personálu;
• 4) provádění zkušebního provozu všech komponent a systému jako celku;
• 5) uvedení do provozu a podepsání potvrzení o převzetí díla.

Informační systém, který jsme vyvinuli, má následující minimální požadavky na technické vlastnosti hardwaru a softwaru:

• - jednojádrový procesor s frekvencí 2 GHz;
• -DDR RAM - 512 MB;
• -grafická karta - bude stačit jakákoli moderní;
• -1 GB místa na pevném disku;
• -monitor, klávesnice, myš;
• - instalovaný operační sál systém Windows 98/XP/Vista/Seven.

Od OJSC "Kirovenergosbyt" tento moment Existují podobné databáze (naše databáze je syntézou 2 existujících databází), dále speciální školení personálu při implementaci nová základna nejsou vyžadována žádná data.

Po vložení do podnikové databáze je zcela připraven k použití.

Provoz informačního systému

V této práci byl učiněn pokus maximálně zjednodušit práci uživatelů pomocí informačního systému „Účetnictví pro práci s klienty“ OJSC „Kirovenergosbyt“. Protože je aplikace plná tabulek, bylo nutné vyvinout pohodlný systém pro navigaci, vyhledávání, přidávání a mazání záznamů a generování reportů.

Navzdory tomu, že aplikace nevyžaduje výkonné technická charakteristika z počítače, na kterém bude používána, by aplikace neměla obsahovat přemíru vedlejších prvků.

Po spuštění programu „Zákaznické účetnictví“ se zobrazí formulář, který vás vyzve, abyste začali pracovat s daty Kirovenergosbyt OJSC.

Pokud potřebujete informace o dlužnících společnosti Kirovergosbyt OJSC, klikněte na „Dlužníci“. Otevře nový formulář„Dlužníci“, pomocí kterých můžete najít, přidat, změnit nebo odstranit požadovaný parametr.

Když kliknete na tlačítko „Změnit“, po prvním kliknutí na požadovaný řádek v tabulce a změně jeho údajů se změny v údajích zadaného řádku zaznamenají do tabulky. Pokud chcete do tabulky přidat nová data, zadejte nová data do určených polí. Poté klikněte na tlačítko „Přidat“ a v databázi se objeví nové informace. V poli „Hledat“ můžete najít potřebné informace podle jednoho nebo více parametrů zadáním údajů a kliknutím na tlačítko „Hledat“. Také zvýrazněním řádku v tabulce a kliknutím na tlačítko „Smazat“ bude požadovaný řádek a všechna data o něm odstraněna z vašeho seznamu. Pokud se chcete vrátit k původnímu formuláři, klikněte na „Exit“.

Hlavní formulář dále obsahuje tlačítka, která umožňují přístup k údajům o dodavatelích („Dodavatelé“), o smlouvách („Smlouvy“), o zaměstnancích („Zaměstnanci“), o spotřebitelích („Spotřebitelé“). Všechny otevřené formuláře obsahují také tlačítka „Přidat“, „Změnit“, „Vymazat“, „Hledat“, „Nahlásit“, „Ukončit“.

Pokud chcete program ukončit, musíte v hlavním formuláři kliknout na tlačítko „Ukončit“.

Program zavádí omezení pro změnu rozhraní, uživatelský přístup k tlačítkům „Přidat“, „Změnit“, „Odstranit“, kontrolu, zda zadaná data odpovídají parametrům tabulek, a kontrolu nejúplnějšího zadávání dat.

Perspektivy rozvoje informačního systému

Námi vytvořený informační systém je v této fázi schopen zohlednit práci s klienty OJSC Kirovenegosbyt, s jejími dodavateli a zařadit dlužníky společnosti do samostatné kategorie, což zjednodušuje práci s jejich vyhledáváním. Při tvorbě tohoto informačního systému byl učiněn pokus o spojení 2 aktuálně existujících databází s přihlédnutím k zvlášť dlužníkům a všem spotřebitelům Společnosti.

V budoucnu k němu mohou být přidány nové možnosti pro vytváření oznámení a varování pro dlužníky, účtování služeb poskytovaných v souladu se smlouvou, účetní prvky, schopnost integrovat data do 1C: Enterprise atd.

3) popis akcí operátora při práci s programy (pravidla pro spouštění programů, pracovní příkaz, akce v případných nestandardních situacích atd.).

Popis testovacího případu obsahuje popis:

1) funkce a parametry softwaru testovaného testovacím případem;

2) složení technických prostředků nezbytných k testování softwaru v tomto příkladu;

3) vstupní informace;

4) výsledky spouštění programů na základě dat testovacích případů;

5) akce operátora při kontrole programu na testovacím příkladu;

6) výsledky testů (kontrolní standard) programů pomocí testovacího příkladu.

Postup pro přenos softwarové dokumentace

Všechny programy a návody, odzkoušené vývojářem na testovacím příkladu, jsou zákazníkovi předány pod certifikátem potvrzujícím jejich převzetí do zkušebního provozu.

Doručeno zákazníkovi software, instrukce a popisy algoritmů musí splňovat požadavky na skladbu a obsah pracovního návrhu informačního systému. Pořady nahrané na magnetických médiích jsou předány zákazníkovi. Zákazník poskytuje vývojáři magnetická média a počítačový čas nutný pro uvedení programů do zkušebního provozu a jejich případné rozmnožování.

Přijetí sady úloh (subsystémů) do zkušebního provozu zahrnuje vyřešení testovacího případu speciálně vyškoleným personálem zákazníka za přítomnosti zástupců vývojářů s následnou analýzou výsledků. Po vzájemné dohodě může být testovací případ proveden vývojářem za přítomnosti zákazníka.

Na základě výsledků akceptace je podepsán certifikát o akceptaci softwaru pro zkušební provoz. Objevil

Vývojářské chyby v programech a technické dokumentaci jsou eliminovány během procesu uvádění do provozu.

Organizační a administrativní dokumentace

Pro hlavní práce prováděné ve fázi „Detailní návrh“ je vypracována následující organizační a administrativní dokumentace:

1) nařídit provedení prací v etapě v souladu s harmonogramem organizační a technická opatření;

2) harmonogram společných prací mezi zhotovitelem a objednatelem;

3) akt ověření na zkušebních příkladech a převzetí pracovních programů do zkušebního provozu;

4) akt připravenosti regulační a referenční dokumentace;

5) úkon provedení organizačních a technických opatření k přípravě podniku na implementaci informačního systému.

5.5. Uvedení informačního systému do provozu

Uvedení informačního systému a jeho jednotlivých prvků do provozu je procesem postupného přechodu od stávajících metod řízení k metodám automatizovaného řízení.

Uvedení informačního systému do provozu organizuje a provádí zákazník za účasti vývojářů a spoluprovádějících organizací. Interakce mezi zákaznickými organizacemi, vývojáři a spoluprovozovateli probíhá na základě smluvních podmínek a harmonogramu uvedení informačního systému do komerčního provozu.

Uvedení do provozu probíhá po etapách, počínaje fází zpracování technického projektu, kdy je připravena pracovní dokumentace a zprovozněny technické prostředky zajišťující realizaci front nebo objektů informačního systému schopných samostatného fungování.

Informační systém byste měli začít zprovozňovat, pokud máte:

1) vypracované dokumenty o realizaci akčního plánu pro přípravu zařízení;

2) pracovní dokumentace pro implementaci vyhrazené fronty nebo informačního systému jako celku;

3) vyškolený personál zajišťující přípravu na uvedení do provozu

provoz a provoz vyhrazené fronty informačního systému;

4) technické prostředky informačního systému přijaté do provozu, zajišťující fungování realizovaných souborů úkolů.

Organizace práce

Implementováno:

1) zkušební provoz jednotlivých úkolů a jejich komplexů;

2) přijímání komplexů úkolů pro komerční provoz;

3) provádění přejímacích zkoušek;

4) přijetí systému do komerčního provozu.

Složení a pořadí prací jsou určeny dohodnutými harmonogramy uvádění do provozu, které udávají složení a načasování následujících prací:

1) pro výstavbu, instalaci, uvedení do provozu a testování objektů informačního systému od okamžiku obdržení pracovní dokumentace až do uvedení objektů do komerčního provozu;

2) pro provádění zkušebního provozu a akceptační testování sad úkolů;

3) zajistit přechod od stávajících metod řízení

Na metody, které poskytuje návrh informačního systému.

Ve fázi „Uvádění informačního systému do provozu“

zákazník je povinen:

1) ukončit exekuci organizační a technická opatření k přípravě podniku na implementaci informačního systému a jejich formalizaci akty;

2) zajistit, aby pracovníci podniku dodržovali pracovní a technologické pokyny;

3) uvést do provozu technické prostředky potřebné k realizaci technologický postup zpracování dat;

4) vydat objednávku s harmonogramem provedení zkušebního provozu informačního systému a analyzovat spolu s developerem výsledky zkušebního provozu;

5) dokončit zkušební provoz komplexů úloh zařazených do informačního systému a jejich převzetí do komerčního provozu;

6) provádět změny organizační struktury podniku v souladu s projektem informačního systému;

7) vypracovat návrh nařízení o složení přijímací komise;

8) vyvinout a koordinovat s vývojářem návrh programu přejímací zkoušky;

9) organizovat práci přejímací komise, poskytovat jí požadovanou dokumentaci a testovat informační systém;

10) prověřit efektivitu implementovaných řešení v podmínkách průmyslového provozu a na základě výsledků analýzy fungování systému vypracovat doporučení pro jeho další rozvoj.

Ve fázi „Uvádění informačního systému do provozu“

je developer povinen:

1) upravit technickou dokumentaci na základě výsledků zkušebního provozu informačního systému;

2) podílet se na vývoji návrhu programu akceptačního testování informačního systému;

3) metodicky usměrňovat a podílet se na uvádění úkolů (souborů úkolů) do komerčního provozu;

4) podílet se na práci komise pro převzetí informačního systému do komerčního provozu.

Postup při provádění zkušebního provozu

Začátek zkušebního provozu úkolů (souborů úkolů), podmínky provozu a složení komise pro přijetí konkrétního úkolu nebo subsystému jsou stanoveny objednávkou vystavenou objednatelem a odsouhlasenou s developerem. Přílohou objednávky je odsouhlasená dohoda

zpracovatel má program zkušebního provozu, který definuje podmínky testování souborů úloh, postup kontroly technických prostředků při řešení souborů problémů (subsystémů) a postup odstraňování nedostatků zjištěných při zkušebním provozu.

Dodatečné požadavky zákazníka, které vzniknou během zkušebního provozu a nejsou uvedeny v technických specifikacích a technickém návrhu, nezakládají důvod k negativnímu posouzení výsledků zkušebního provozu a mohou být splněny dodatečnou dohodou v dohodnutém termínu.

Pokud jsou výsledky zkušebního provozu úloh (subsystémů) pozitivní, je sepsán dvoustranný akt o jejich převzetí do komerčního provozu.

Po převzetí informačního systému do komerčního provozu nese odpovědnost za jeho fungování v rámci přijatých souborů úkolů a nástrojů zákazník.

Prvotní a reportovací dokumenty pro testování softwaru informačního systému

Společné testy provádí zákaznická komise, která zahrnuje manažera vývoje a několik předních vývojářů. Testovací komise se řídí následujícími dokumenty:

1) technické specifikace pro tvorbu informačního systému schválené zákazníkem a dohodnuté s vývojářem;

2) aktuální stav a průmyslové standardy pro návrh a testování softwaru a technickou dokumentaci;

3) zkušební program pro všechny technické požadavky

4) zkušební metody pro každý oddíl požadavků technických specifikací.

Testovací program, způsoby jejich provádění a vyhodnocování

Výsledky jsou vyvíjeny společně zákazníkem a vývojářem a musí být odsouhlaseny a schváleny. Obsahují objasnění požadavků technických specifikací pro tento systém a musí je garantovat správná kontrola. Systémová dokumentace by měla

plně vyhovovat testovaným programům, zajistit, aby byl systém srozumitelný personálu údržby, a také poskytnout možnost vyvíjet a modernizovat programy pro prodloužení doby jejich životního cyklu.

Testovací program je plán na provedení série experimentů. Je vyvíjen z pozice minimalizace množství testování při zajištění spolehlivosti získaných výsledků specifikovaných a odsouhlasených se zákazníkem. K tomu je určeno pořadí a rozsah každého testování během testovacího procesu, aby se ověřila shoda s požadavky technických specifikací, když minimální náklady. Zvláště obtížné může být vybrat soubor stresových provozních situací systému, za kterých by mělo být testování prováděno. Testovací program by měl obsahovat tyto jasně definované části:

1) testovací objekt, jeho účel a seznam hlavních dokumentů, které určovaly jeho vývoj;

2) účel zkoušek s uvedením hlavních požadavků technických specifikací, které mají být ověřeny, a omezení zkoušek;

3) vlastně testovací program, obsahující kontrolu úplnosti vyvinutého systému v souladu s technickými specifikacemi a plán zkoušek pro kontrolu fungování programů pro všechny části technických specifikací a další požadavky formalizované samostatnými řešeními;

4) zkušební metody, jednoznačně definující všechny pojmy testovaných charakteristik, podmínky testování, nástroje používané pro testování, metody zpracování a vyhodnocování výsledků testů pro každý úsek testovacího programu.

Velký objem heterogenních dat získaných během testování

software a rozmanitost možné způsoby jejich zpracování, interpretace a vyhodnocení vede k tomu, že nejdůležitějšími faktory pro zpracování výsledků testů se stávají metody zpracování a vyhodnocování výsledků. V souladu se zkušebními metodami musí automatizační zařízení zajistit úplnost kontrol vlastností pro každý úsek metod a vývoje

kontrolní protokoly pro položky zkušebního programu. Složitost softwaru a úzký vztah mezi jeho různými charakteristikami vede k potřebě pečlivé formulace všech testovacích podmínek a hodnot parametrů, při kterých musí být test proveden.

Výsledky testů se zaznamenávají do protokolů , které obvykle obsahují následující sekce:

1) účel zkoušení a část požadavků technických specifikací, podle kterých se zkouška provádí;

2) uvedení metod, podle kterých byly zkoušky provedeny, zpracování a vyhodnocení výsledků;

3) zkušební podmínky a vlastnosti výchozího

4) zobecněné výsledky zkoušek s jejich posouzením shody s požadavky technických specifikací a dalších řídících dokumentů;

5) závěry o výsledcích testů a míře shody vytvořeného softwaru s určitou částí požadavků technických specifikací.

Protokoly pro celý program jsou shrnuty do aktu, jehož výsledkem je

je učiněn závěr o shodě systému s požadavky zákazníka a zda je práce dokončena s kladným nebo záporným výsledkem. Pokud jsou plně splněny všechny požadavky technické specifikace, je zákazník povinen systém převzít a dílo se považuje za dokončené.

Jak však již bylo uvedeno, u složitých softwarových balíků je obtížné předvídat a správně formulovat všechny požadavky technických specifikací v počátečních fázích návrhu. Proto se při ladění a testování často ukáže, že některé požadavky technických specifikací nejsou splněny a někdy i zásadně nemohou být splněny ani při sebesvědomitějším přístupu k tomu ze strany vývojáře. V tomto případě je nutné při vyplňování testů a vypracování závěru spolupracovat mezi zákazníkem a vývojářem na nalezení kompromisního řešení. Některé nedostatky programového komplexu během testovacího procesu jsou pouze evidovány a evidovány v rámci eliminace připomínek komise,

kdo testy prováděl. Tento plán je přílohou zprávy o výsledcích testu a umožňuje oddělit následná vylepšení od přímých testů.

Postup pro provádění přejímacích zkoušek

Za organizaci a provedení převzetí do komerčního provozu odpovídá zákazník. Převzetí informačního systému do komerčního provozu se provádí po dokončení akceptace všech souborů úkolů (subsystémů) pro komerční provoz zákazníkem.

Úkoly, soubory úkolů (subsystémy) a technické prostředky informačního systému, které nejsou uvedeny v technických specifikacích, ale realizují je zákazník samostatně, lze do komplexu dodávaného informačního systému zařadit pouze po dohodě s zpracovatelem. a po provedení příslušných změn technických specifikací pro vytvoření informačního systému.

Na žádost zákazníka nebo vývojáře mohou být do přejímky informačního systému zapojeni zástupci subdodavatelů.

Zákazník předloží informační systém přejímací komisi. Do přijímacího procesu mohou být kromě členů komise zapojeni odborníci na některé otázky tvorby informačních systémů s právem poradního hlasu. Zákazník je povinen zajistit pro provizi běžné pracovní podmínky v souladu s přijatým akceptačním programem informačního systému. Pro promptní řešení organizační záležitosti vzniklé při přejímce informačního systému, je na příkaz vedoucího vývojářské organizace přidělen odpovědný zástupce vývojářské organizace.

Zákazník společně s vývojářem připraví návrh programu pro testování a akceptaci informačního systému a předloží jej akceptační komisi k posouzení a schválení. Program uvádí: název předkládaného informačního systému, směrnicové dokumenty, na jejichž základě byl systém vyvíjen (pokud existují), složení přejímací komise a číslo zakázky na její jmenování, účel, předměty, objem, umístění a

sled zkoušek, metody zkoušení a vyhodnocování výsledků.

Zákazník připraví společně s developerem a předá provizi k dočasnému použití následující dokumenty:

1) objednávky, pokyny, plány, smlouvy zajišťující vytvoření informačního systému;

2) technické a ekonomické odůvodnění, zadání, technické provedení, podrobný návrh informačního systému;

3) úkony posouzení a schválení technického návrhu;

4) dvoustranné úkony objednatele a developera o dodání úkolů, souborů úkolů (subsystémů), zařízení a jejich komplexů do komerčního provozu v souladu se schválenými technickými specifikacemi.

Přijímací komise zajišťuje:

1) kontrola dokumentace a fungování informačního systému;

2) organizování pracovních skupin a rozdělení odpovědnosti mezi členy komise za kontrolu jednotlivých subsystémů;

3) kontrola výpočtu ekonomické efektivnosti vytvořeného informačního systému;

4) pořádání workshopů a příprava certifikátů o přijetí informačního systému.

Kontrola provozních podmínek a provozních režimů technických

nástrojů informačního systému se provádí současně s kontrolou fungování komplexů úloh (subsystémů). Připravenost pracovníků odpovědných za provoz informačního systému je stanovena v souladu s programem školení a náplní práce obsaženými v pracovním projektu. Výsledky kontroly jsou projednávány na pracovních poradách a dokumentovány v zápisech.

Poslední fází práce komise je vypracování aktu, který uvádí:

1) složení komise, funkce a pracoviště členů komise;

2) termín (datum) přijetí systému;

3) složení výkonných umělců (organizací, podniků), kteří se podíleli na tvorbě informačního systému;

4) důvody pro přijetí (objednávky, pokyny a

5) seznam prezentované dokumentace informačního systému

A posouzení jeho souladu s proudem regulační a technické dokumenty;

6) soulad skutečně dokončených a realizovaných prací s technickými specifikacemi;

7) připravenost všech druhů podpory a strukturální dělení zákazníkem k implementaci a provozu informačního systému;

8) informace o efektivitě informačního systému (porovnání stávajících nebo očekávaných skutečných údajů o objemu a zdrojích získaných úspor s vypočítanými údaji);

9) závěry komise o možnosti přijetí informačního systému;

Potvrzení o převzetí v pěti vyhotoveních podepisuje předseda a všichni členové komise. Dnem uvedení informačního systému do provozu je datum podpisu zákona komisí.

6. Tým vývoje informačních systémů

Vzhledem k tomu, že tvorba moderního informačního systému je složitý proces, který vyžaduje společné úsilí velkého počtu různých specialistů, je v moderních podmínkách velmi důležité sestavení týmu podílejícího se na návrhu, vývoji a implementaci informačního systému.

Organizaci týmu a rozdělení práce mezi specialisty lze provádět podle několika zásad:

1) na základě rozdělení systémové analýzy (algoritmizace) a vývoje programu mezi různé týmy;

Nařízení vlády Ruské federace ze dne 6. července 2015 N 676
„O požadavcích na postup při vytváření, rozvoji, uvádění do provozu, provozu a vyřazování z provozu státních informačních systémů a dalším uchovávání informací obsažených v jejich databázích“

V souladu s částí 6 článku 14 spolkového zákona "o informacích, informačních technologiích a ochraně informací" vláda Ruská Federace rozhoduje:

1. Schvalovat přiložené požadavky na postup při vytváření, rozvoji, uvádění do provozu, provozu a vyřazování státních informačních systémů z provozu a dalším uchovávání informací obsažených v jejich databázích.

2. Stanovit, že činnosti stanovené požadavky schválenými tímto usnesením provádějí federální výkonné orgány v rámci rozpočtových přídělů stanovených federálním zákonem o federálním rozpočtu na odpovídající finanční rok a plánovací období pro vedení a řízení v pole zavedených funkcí.

3. Doporučit, aby se ostatní vládní orgány, kromě federálních výkonných orgánů a výkonných orgánů ustavujících subjektů Ruské federace, i řídící orgány státních mimorozpočtových fondů, samosprávy, řídily ve své činnosti schválenými požadavky tímto usnesením.

Požadavky
k postupu při vytváření, vývoji, uvádění do provozu, provozu a vyřazování z provozu státních informačních systémů a dalším uchovávání informací obsažených v jejich databázích
(schváleno nařízením vlády Ruské federace ze dne 6. července 2015 N 676)

Se změnami a doplňky od:

I. Obecná ustanovení

1. Tento dokument vymezuje požadavky na postup při provádění opatření k vytvoření, rozvoji, zprovoznění, provozu a vyřazení státních informačních systémů (dále jen systém) a dalšího uchovávání informací obsažených v jejich databázích, prováděných federální výkonné orgány a výkonné orgány orgány ustavujících subjektů Ruské federace (dále jen výkonné orgány) za účelem zvýšení efektivity výkonu pravomocí výkonných orgánů v důsledku využívání informačních a komunikačních technologií, nebo výkonné orgány jednající jako veřejní partneři a soukromí partneři v souladu se smlouvami o partnerství veřejného a soukromého sektoru (dále jen soukromý partner) za účelem realizace těchto dohod.

1.1. Když výkonné orgány nebo soukromí partneři zavedou opatření pro vytvoření, vývoj, uvedení do provozu, provoz a vyřazení systémů z provozu a další ukládání informací obsažených v jejich databázích, je třeba provést následující:

a) požadavky na ochranu informací obsažených v systémech zřízených federálním výkonným orgánem v oblasti bezpečnosti a federálním výkonným orgánem pověřeným v oblasti boje proti technickému zpravodajství a technické ochrany informací v mezích jejich pravomocí;

b) požadavky na organizaci a opatření na ochranu informací obsažených v systému;

Informace o změnách:

Bod 1.1 byl ze dne 27. dubna 2019 doplněn o podbod „c“ - Usnesení

c) požadavky na ochranu osobních údajů stanovené v části 3 článku 19 spolkového zákona „o osobních údajích“ (pokud jsou v systému osobní údaje).

Informace o změnách:

Nařízením vlády Ruské federace ze dne 11. května 2017 N 555 byly požadavky doplněny o bod 1.2.

1.2. Pro splnění požadavků na ochranu informací stanovených v odst. 1.1 tohoto dokumentu (dále jen požadavky na ochranu informací) určují výkonné orgány požadavky na ochranu informací obsažených v systému výkonné moci. orgán, pro který vykonávají:

a) určení informací, které mají být chráněny před neoprávněným přístupem, zničením, úpravou, blokováním, kopírováním, poskytováním, šířením, jakož i jiným protiprávním jednáním v souvislosti s těmito informacemi;

b) rozbor předpisů, metodických dokumentů a národních norem, které musí systém splňovat;

c) klasifikace systému v souladu s požadavky na bezpečnost informací;

d) identifikace hrozeb informační bezpečnosti, jejichž realizace může vést k narušení informační bezpečnosti v systému, a na jejich základě vypracování modelu ohrožení informační bezpečnosti;

e) stanovení požadavků na informační systém (subsystém) pro ochranu informací obsažených v systému.

II. Požadavky na postup při vytváření systému

2. Základem pro vytvoření systému je:

a) povinnost výkonného orgánu vytvořit systém stanovený regulačními právními akty;

b) rozhodnutí výkonného orgánu o vytvoření systému k zajištění realizace jemu svěřených pravomocí;

Informace o změnách:

Ustanovení 2 bylo doplněno písmenem „c“ ze dne 27. dubna 2019 – nařízení vlády Ruska ze dne 11. dubna 2019 N 420

c) rozhodnutí vlády Ruské federace o realizaci projektu partnerství veřejného a soukromého sektoru;

Informace o změnách:

Ustanovení 2 bylo doplněno odstavcem „d“ ze dne 27. dubna 2019 – nařízení vlády Ruska ze dne 11. dubna 2019 N 420

d) rozhodnutí nejvyššího výkonného orgánu státní moci ustavujícího subjektu Ruské federace, je-li veřejným partnerem ustavujícím subjektem Ruské federace nebo je plánováno uspořádání společné soutěže za účasti ustavujícího subjektu Ruské federace. Ruská federace (s výjimkou případů pořádání společné soutěže za účasti Ruské federace).

3. Vytvoření systému se provádí v souladu se zadáním, s přihlédnutím k modelu ohrožení bezpečnosti informací stanovenému v pododstavci "d" odstavce 1.2 tohoto dokumentu, jakož i k úrovním zabezpečení osobních údajů při jejich zpracování v informačních systémech osobních údajů v závislosti na ohrožení bezpečnosti těchto údajů a požadavcích tohoto dokumentu.

Model ohrožení informační bezpečnosti a (nebo) podmínky pro vytvoření systému jsou dohodnuty s federálním výkonným orgánem v oblasti bezpečnosti a federálním výkonným orgánem oprávněným v oblasti boje proti technickému zpravodajství a technické ochraně informací, v mezích svých pravomocí ve vztahu k implementaci stanovených požadavků na ochranu informací.

Zadávací podmínky pro vytvoření systému musí obsahovat požadavky na ochranu informací obsažených v systému, vytvořené v souladu s pododstavci „a“ a „c“ odstavce 1.1 tohoto dokumentu.

4. Zadání pro vytvoření systému a model ohrožení informační bezpečnosti schvaluje úředník výkonného orgánu, kterému jsou svěřeny příslušné pravomoci.

5. Postup pro vytvoření systému zahrnuje následující postupně implementované fáze:

a) vypracování dokumentace systému a jeho částí;

b) vypracování pracovní dokumentace pro systém a jeho části;

c) vývoj nebo adaptace softwaru;

d) uvedení do provozu;

e) provádění předběžných testů systému;

f) provádění zkušebního provozu systému;

g) provádění přejímacích zkoušek systému.

6. Etapa zpracování dokumentace systému a jeho částí zahrnuje vypracování, koordinaci a schvalování dokumentace v rozsahu nezbytném pro popis celého souboru konstrukčních řešení (včetně informační bezpečnosti) a dostatečném pro další práce na vytváření systému.

7. Stupeň zpracování pracovní dokumentace systému a jeho částí zahrnuje vypracování, koordinaci a schvalování dokumentace obsahující informace potřebné k provedení prací na uvedení systému do provozu a jeho provozu a postup provozování systému obsahující informace nezbytné k provedení prací pro udržení úrovně provozních charakteristik (kvality) systému (včetně informační bezpečnosti) stanovených v konstrukčních řešeních specifikovaných v odstavci 6 tohoto dokumentu, včetně:

a) seznam úkonů zaměstnanců při plnění úkolů k obsluze systému, včetně seznamu, druhů, objemů a četnosti prací pro zajištění fungování systému;

b) sledování výkonu systému a komponent, které zajišťují ochranu informací;

c) seznam poruch, které mohou nastat během provozu systému, a doporučení ohledně akcí, když k nim dojde;

d) seznam provozních režimů systému a jejich charakteristik, jakož i postup a pravidla pro převod systému z jednoho provozního režimu do druhého s uvedením času, který je k tomu zapotřebí.

8. Stupeň vývoje nebo adaptace softwaru zahrnuje vývoj systémového softwaru, výběr a přizpůsobení nakupovaného softwaru, jakož i ve stanovených případech a postupech certifikaci vyvíjeného systémového softwaru a nástrojů informační bezpečnosti podle požadavků na bezpečnost informací.

9. Etapa zprovoznění zahrnuje autonomní úpravu hardwaru a softwaru částí systému, načtení informací do jeho databáze, komplexní úpravu hardwaru a softwaru systému včetně nástrojů informační bezpečnosti.

10. Fáze předběžného testování zahrnuje:

a) vypracování programu a metodiky předběžných zkoušek, podle kterých je systém kontrolován z hlediska provozuschopnosti a souladu s technickými specifikacemi pro jeho vytvoření;

b) kontrola provozuschopnosti systému a dodržování technických specifikací pro jeho vytvoření;

c) odstraňování závad zjištěných při těchto zkouškách a provádění změn v dokumentaci a pracovní dokumentace na systému;

d) vyhotovení zkušebního protokolu a potvrzení o převzetí systému do zkušebního provozu.

11. Fáze zkušebního provozu zahrnuje:

a) vypracování programu a metodiky zkušebního provozu;

b) zkušební provoz systému v souladu s programem a metodikou zkušebního provozu;

c) zpřesnění programového vybavení systému a dodatečná úprava technických prostředků v případě zjištění nedostatků zjištěných při zkušebním provozu systému;

d) vyhotovení potvrzení o absolvování zkušebního provozu včetně výčtu nedostatků, které je nutné před zahájením provozu systému odstranit.

12. Fáze akceptačního testování zahrnuje:

a) testování systému na shodu s technickými specifikacemi pro jeho vytvoření v souladu s programem a metodikou akceptačních zkoušek;

b) rozbor výsledků odstraňování nedostatků uvedených v potvrzení o ukončení zkušebního provozu;

c) vypracování aktu o převzetí systému do provozu.

III. Požadavky na postup při uvádění systému do provozu

13. Podkladem pro uvedení systému do provozu je právní akt výkonného orgánu o uvedení systému do provozu, který stanoví seznam opatření k zajištění uvedení systému do provozu a stanoví termín zahájení provozu.

14. Právní akt výkonného orgánu o uvedení systému do provozu obsahuje:

a) opatření pro vypracování a schvalování organizačních a administrativních dokumentů, které definují opatření k ochraně informací při provozu systému, jejichž vývoj je zajištěn regulačními právními akty a metodickými dokumenty federálního výkonného orgánu v oblasti bezpečnosti a federální výkonný orgán oprávněný v oblasti boje proti technickému zpravodajství a technické informační bezpečnosti, jakož i národních standardů v oblasti informační bezpečnosti;

b) opatření k certifikaci systému podle požadavků na ochranu informací, v jejichž důsledku je v případech stanovených právními předpisy Ruské federace soulad ochrany informací obsažených v systému s požadavky stanovenými právními předpisy Ruské federace. potvrzuje se Ruská federace o informacích, informačních technologiích a ochraně informací;

c) opatření k přípravě výkonného orgánu i soukromého partnera v případě uzavření smlouvy o partnerství veřejného a soukromého sektoru na provoz systému;

d) opatření k přípravě úředníků výkonného orgánu i zaměstnanců soukromého partnera v případě uzavření smlouvy o partnerství veřejného a soukromého sektoru na provoz systému, včetně osob odpovědných za zajištění bezpečnosti informací.

15. Uvedení systému do provozu není povoleno v následujících případech:

a) nedodržení požadavků na ochranu informací stanovených právními předpisy Ruské federace, včetně chybějícího platného osvědčení o splnění požadavků na bezpečnost informací;

b) nepřítomnost v evidenci územního umístění objektů kontroly, stanovené Pravidly pro sledování umístění technických prostředků informačních systémů používaných státními orgány, samosprávami, státními a obecními podniky, státními a obecními institucemi, na území Ruské federace, schválené usnesením vlády Ruské federace ze dne 6. července 2015 N 675 „O postupu při kontrole dodržování požadavků stanovených v části 2.1 článku 13 a části 6 článku 14 spol. Zákon „o informacích, informačních technologiích a ochraně informací“, informace o umístění technických prostředků informačního systému na území Ruské federace;

c) nedodržení požadavků tohoto paragrafu zjištěné při provádění kontroly podle Pravidel pro sledování dodržování požadavků na postup při vytváření, rozvoji, uvádění do provozu, provozu a vyřazování státních informačních systémů z provozu a dále uchovávání informací obsažených v jejich databázích, schválené nařízení vlády Ruské federace ze dne 6. července 2015 N 675 „O postupu při kontrole dodržování požadavků stanovených v části 2.1 článku 13 a části 6 článku 14 zákona č. federálního zákona „O informacích, informačních technologiích a ochraně informací“ tohoto právního aktu a) příprava právních aktů souvisejících s vyřazením systému z provozu;

b) práce na vyřazení systému z provozu, včetně prací na odinstalaci systémového softwaru, výkonu práv k systémovému softwaru, demontáži a vyřazení hardwaru systému, zajištění uložení a dalšího použití informační zdroje systémy;

Informace o změnách:

Nařízením vlády Ruské federace ze dne 11. května 2017 N 555 byl odstavec 23 doplněn o písmeno „c“

c) zajištění ochrany informací v souladu s dokumentací k systému a organizačními a administrativními dokumenty o ochraně informací, včetně archivace informací obsažených v systému, zničení (vymazání) dat a zbytkových informací z paměťových médií počítačů a (nebo) zničení počítačových paměťových médií .

24. Pokud regulační právní akty Ruské federace nestanoví jinak, jsou doby uchovávání informací obsažených v databázích systému stanoveny výkonným orgánem a nemohou být kratší než doby uchovávání informací, které jsou stanoveny pro uchovávání papírových dokumentů obsahujících takové informace.

25. Lhůta pro vyřazení soustavy z provozu nemůže být dřívější než datum ukončení poslední akce stanovené právním aktem o vyřazování soustavy.