Uvedení do provozu informačního systému. Vstup do průmyslového provozu informačních systémů GOST

Schválit

Zástupce ředitele Ústavu státního nařízení v ekonomice

Ministerstvo hospodářského rozvoje Ruské federace
______________ v.n. Rudenko.
« 09 » _ listopad__ 2011.

Akt Uvedení do provozu

Automatizovaný projektový informační systém projektu vyvinutý v rámci státní smlouvy ze dne 7. listopadu 2011 č. GK-158-OF / D01.
V souladu se společným rozhodnutím zákazníka (Ministerstvo hospodářského rozvoje Ruska) a dodavatele (LLC "OTR 2000") na zavedení do zkušebního provozu.

Komise složená:

Předseda Komise:

Zástupce ředitele ministerstva státní regulace v ekonomice v.n. Rudenko,

Členové Komise:

Hlavní vedoucí oddělení rozvoje elektronické společnosti Katedra státní regulace v ekonomice S.V. Pushakov,

Poradce Katedry metodické podpory pro organizaci meziresortního interakce Ústavu státního nařízení v ekonomice A.v. Matveenko,

Přední konzultant pro rozvojové oddělení odboru elektronické společnosti Státní regulace v ekonomice N.N. Kirsanova

Vedoucí směru LLC "OTP 2000" A.I. Kuleshova,

Vedoucí projektů LLC "OTR 2000" O.v. Pojištění

Přední analýza LLC "OTR 2000" Yu.m. Gudkova,

Výzkumný pracovník směr "Reálný sektor" IEE pojmenovaný po E.T. Gaidar E.R. Battarshina.
od té doby "_ 08 _" listopad 2011 "_ 09 _" listopad 2011 provedly předběžné zkoušky aplikovaného softwaru pro automatizovaný informační systém "Portál projektového řízení" (AIS PPU) zřízený v Ministerstvu hospodářského rozvoje Ruska.

Předběžné testy jsou rozpoznány úspěšně dokončeny.

Hlavní fáze vývoje jsou prováděny v souladu s podmínkami.
Rozvinutý dokumentace splňuje požadavky Provoz softwaru.
Software připravený pro zkušební provoz.

Seznam funkcí přijatých do zkušebního provozu (oddíl "Požadavky na funkce prováděné systémem" technického úkolu):
1. Udržování seznamu projektů.
2. Práce s designovými subjekty.
3. Práce s ukazateli pro posouzení stavu práce na projektu.
4. Analytický modul.
5. Knihovna dokumentů.

Seznam dokumentů poskytnutých dokumenty nezbytnými pro vedení zkušený provoz: \\ t
1. "Popis portálu AIS" Projektový management "" (systémový pas);
2. "Instrukce administrátora AIS ppu";
3. "Uživatelské pokyny AIS PPU";
4. "Program a metody testování AIS PPU";
5. "Zkušební úkoly pro AIS PPU";
6. "Pokyny pro přehrávání rolí popisující postup pro práci s AIS PPU jako nástroj pro správu projektů" Interdepartmental interakce ".
Rozhodnutí Komise: Přijmout programování zkušebního provozu od 9. listopadu 2011.

Aplikace:

Protokol předběžného testu č. 1
Protokol předběžného testu č. 2

Členové Komise:

V.n. Rudenko.

S.v. Pushchakov.

A.v. Matveenko

N.n. Kirsanova

A.I. Kuleshov.

O.v. Pojištění

Mňam. Gudkov.

E.R. Bartarshshin.

Aktu o přijetí ve zkušební operaci Formuláře založené na výsledcích předběžných zkoušek a zahrnuje: závěry provedené podle výsledků komplexních testů; Úkoly pro zkušební provoz.

Časové období Komise

Tato sekce akčního úkonu je dána zahájení start a konce práce přijatelné komise k provádění předběžných zkoušek.

Začátek zkoušky - 1. listopadu 2010.
Konec testu - 31. prosince 2010.
Celková doba testování - 44 pracovních dnů.

Jméno organizace-zákazníka, organizace-performer a organizace-Spolu-Appliance

Název organizací účastníků testování a těch, kteří sestavili akt přijetí informačního systému ve zkušební operaci.

Organizace zákazníka - OJSC zákazníka.
Organizace-performer - CJSC "Dodavatel".
Organizace-ko-ventil - LLC "Solddilizer" (pokud existuje).

Složení funkcí AIS, přijaté ve zkušební operaci

Složení funkcí AIS přijatého ve zkušebním provozu je uvedena. Funkce mohou být přenášeny jak systémem a subsystémy. Funkce jsou převzaty z sekce "Požadavky na funkce prováděné systémem" Technický úkol pro vytvoření informačního systému.

Seznam komponent technického, softwaru, informací a organizačních ustanovení ověřovatelných v procesu zkušební operace

Tato část akceptačního zákona je uveden seznam zkoušek prováděných během zkušební operace. Seznam testů je převzat z testovacího programu "Test Objem".

V procesu zkušený provoz se testy podléhají níže uvedené tabulce.

Seznam dokumentů předložených Komisí

Tato část akčního úkonu poskytuje seznam dokumentů poskytnutých Komisí, které jsou nezbytné pro provádění zkušené operace.

Pokyny pro vytvoření a údržbu databáze (DataSet), verze 1 datu 09/12/2010.
- Uživatelská příručka, verze 1 Datum 09/14/2010.
- ...

Posouzení souladu přijatého technického důstojníka AIS

Posouzení souladu AIS technického úkolu je uvedeno.

Podle výsledků předběžného testování systém splňuje požadavky předložené v dokumentu: ". Verze 1.0.

Hlavní výsledky přijetí ve zkušební operaci

Tato část akceptačních akcí uvádí hlavní výsledky získané výsledky experimentálního provozu informačního systému.

Podle výsledků experimentální operace by měly být získány následující hlavní výsledky: \\ t
- systém je funkční;
- Systémové subsystémy - interakce;
- Systém splňuje požadavky dokumentu "Technický úkol vytvořit automatizovaný systém". Verze 1.0.;
- Všechny vlastnosti podléhají posouzení, jsou v přijatelných limitech.

Rozhodnutí Komise o přijetí AIS ve zkušební operaci

Rozhodnutí Komise o možnosti nebo nemožnosti přijetí informačního systému do zkušební operace je uvedeno.

Kovtun M.V. Říjen 2010.

Vyhláška vlády Ruské federace 6. července 2015 N 676
"Na požadavcích na postup pro vytváření, rozvoj, uvedení do provozu, provozu a závěru z provozu státních informačních systémů a další skladování obsažené v jejich informačních databázích"

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

1. Schválit doprovodné požadavky na postup pro tvorbu, vývoj, uvedení do provozu, provozu a závěru z provozu státních informačních systémů a další skladování obsažené v jejich informačních databázích.

2. Zřídit, že činnosti stanovené požadavky schválenými tímto usnesením provádějí federální výkonné orgány v rámci přidělení rozpočtu stanovených federálním zákonem o federálním rozpočtu pro příslušný fiskální rok a plánovací období pro manuální a řízení v oblasti zavedených funkcí.

3. Doporučujeme další vládní agentury, kromě federálních výkonných orgánů a výkonných orgánů základních subjektů Ruské federace, jakož i vládní orgány státních extrabdgetových fondů, místní samosprávy, které mají být vedeny v jejich činnosti s požadavky schválenými tímto požadavky Řešení.

Požadavky
k postupu pro vytváření, vývoj, uvedení do provozu, provozu a výstupu z provozu státních informačních systémů a další skladování obsažené v jejich informačních databázích
(spotřebič. Vyhláška vlády Ruské federace ze dne 6. července 2015 N 676)

Se změnami a dodatky:

I. Obecná ustanovení

1. Tento dokument určuje požadavky na postup pro provádění činností k vytvoření, rozvoji, uvedení do provozu, provozu a závěru z provozu státních informačních systémů (dále jen "systém) a další skladování informací obsažených v jejich databázích Federálními výkonnými orgány a výkonnými orgány orgány základních subjektů Ruské federace (dále jen "výkonné orgány) s cílem zlepšit účinnost orgánu výkonných orgánů v důsledku používání informací a Komunikační technologie nebo výkonné orgány, které jednají jako veřejné partnery a soukromé partnery v souladu s dohodami o partnerství veřejného a soukromého sektoru (dále jen soukromý partner) s cílem realizovat tyto dohody.

1.1. Při provádění výkonných orgánů buď soukromými partnery opatření k vytvoření, rozvoji, uvedení do provozu, provozu a závěru z provozu systémů a další skladování informací obsažených v jejich databázích by měly být provedeny: \\ t

a) požadavky na ochranu informací obsažených v systémech stanovených spolkovým orgánem výkonného orgánu v oblasti bezpečnosti a federálního výkonného orgánu pověřeného v oblasti působení technického průzkumu a technické ochrany informací v rámci svých pravomocí;

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

Změnit informace:

Odstavec 1.1 je doplněn pododstavcem "B" od 27. dubna 2019 - rozlišení

c) Požadavky na ochranu osobních údajů stanovených z části 3 článku 19 federálního zákona "o osobních údajích" (v případě systému osobních údajů).

Změnit informace:

Vyhláška vlády Ruské federace 11. května 2017 N 555 Požadavky jsou doplněny odstavcem 1.2

1.2. Za účelem splnění požadavků na ochranu informací stanovených v odstavci 1.1 tohoto dokumentu (dále jen "požadavky na ochranu informací), výkonné orgány definují požadavky na ochranu informací obsažených v systému výkonného orgánu , pro které provádějí:

a) Definice informací, které mají být chráněny před nezákonným přístupem, zničením, modifikací, blokováním, kopírováním, poskytováním, distribucí, jakož i další protiprávní opatření pro tyto informace;

b) analýza regulačních právních aktů, metodických dokumentů a národních norem, které musí být nakonfigurovány;

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

d) stanovení ohrožení bezpečnosti informací, jejichž provádění může vést k porušení bezpečnosti informací v systému a rozvoj založený na bezpečnosti informací o bezpečnosti informací;

e) určení požadavků na informační systém (podsystém) ochrany informací obsažených v systému.

II. Požadavky na postup pro vytvoření systému

2. Základ pro vytváření systému je:

a) povinnost výkonného orgánu vytvořit systém stanovený právními předpisy;

b) rozhodnutí výkonného orgánu o vytvoření systému, aby bylo zajištěno provádění pravomocí, které mu byly přiděleny;

Změnit informace:

Odstavec 2 je doplněn pododstavcem "in" od 27. dubna 2019 - usnesení ruské vlády 11. dubna 2019 n 420

c) Rozhodnutí vlády Ruské federace o provádění projektu partnerství veřejného a soukromého sektoru;

Změnit informace:

Odstavec 2 je doplněn podle pododstavce "G" od 27. dubna 2019 - usnesení vlády Ruska z 11. dubna 2019 N 420

d) Rozhodnutí Nejvyššího výkonného orgánu státu Ústavní subjekty Ruské federace, pokud je veřejný partner předmětem Ruské federace nebo společné hospodářské soutěže, je plánována s účastí předmětu Ruské federace (s Výjimka případů společné hospodářské soutěže za účasti Ruské federace).

3. Vytvoření systému se provádí v souladu s technickým úkolem, s přihlédnutím k modelu bezpečnostních hrozeb informací stanovených podle subdodlace "G" odstavce 1.2 tohoto dokumentu, jakož i úrovně bezpečnosti osobních Data při zpracování v informačních systémech osobních údajů v závislosti na hrozbách bezpečnosti těchto údajů a požadavků, tento dokument.

Model informačních bezpečnostních hrozeb a (nebo) Technický úkol pro vytváření systému je v souladu s federální výkonnou autoritou v oblasti bezpečnosti a federálního výkonného orgánu pověřeného v oblasti působení technického průzkumu a technické ochrany informací uvnitř jejich pravomoci, pokud jde o provádění zavedených požadavků na ochranu informací.

Technický úkol vytvořit systém by měl zahrnovat vytvořené v souladu s pododstavci "A" a "C" odstavce 1.1 tohoto dokumentu. Požadavky na ochranu informací obsažených v systému.

4. Technický úkol pro vytvoření systému a model informačních hrozeb pro informace je schválen úředníkem výkonného orgánu, který je pověřen příslušným orgánem.

5. Postup pro vytváření systému obsahuje následující postupně implementované kroky:

a) Vývoj dokumentace pro systém a jeho části;

b) rozvoj pracovní dokumentace pro systém a její části;

c) vývoj nebo přizpůsobení softwaru;

d) práce do provozu;

e) provádění předběžných zkoušek systému;

e) provádění zkušený provoz systému;

g) provádění akceptačních testů systému.

6. Stage vývoje dokumentace pro systém a její část zahrnuje vývoj, koordinaci a schválení dokumentace ve výši nezbytné k popisu kompletní sadu návrhových řešení (včetně ochrany informací) a dostatečná k dalšímu plnění práce o vytvoření systému.

7. Systém rozvojové pracovní dokumentace pro systém a jeho část zahrnuje vývoj, koordinaci a schvalování dokumentace obsahující informace nezbytné pro provádění práce na uvedení do provozu systému provozu a jeho provozu a postup pro využívání Systém obsahující informace nezbytné pro zachování úrovně provozních charakteristik údržby systému (včetně ochrany informací) usazených v rozhodnutí o návrhu uvedené v odstavci 6 tohoto dokumentu, včetně: \\ t

a) seznam činností zaměstnanců při provádění úkolů provozu systému, včetně seznamu, druhů, svazků a četnosti práce při zajišťování fungování systému;

b) Kontrola výkonu systému a komponent poskytujících ochranu informací;

c) seznam chyb, které se mohou vyskytnout během provozu systému a doporučení pro akce v jejich výskytu;

d) Seznam provozních režimů systému a jejich vlastnosti, jakož i postup a pravidla pro překlad systému z jednoho pracovního režimu do druhého s uvedením požadovaného času.

8. Vývoj softwaru nebo adaptační krok zahrnuje vývoj systému System Software, volba a přizpůsobení zakoupeného softwaru, stejně jako v případech a způsobu potvrzení vyvinutého softwarového softwaru a nástroje pro bezpečnost informací pro požadavky na bezpečnost informací.

9. Stage Uvedení do provozu zahrnuje autonomní nastavení technických prostředků a softwarových částí systému, stahování informací do jeho databáze, komplexní cílení technických prostředků a systémového softwaru, včetně nástrojů pro ochranu informací.

10. Předběžná zkušební fáze zahrnuje:

a) rozvoj programu a metod předběžných zkoušek, v souladu s tím, že systém je kontrolován na výkon a dodržování technického úkolu pro jeho vytvoření;

b) Kontrola systému pro výkon a dodržování technického úkolu pro jeho vytvoření;

c) odstranění poruch identifikovaných při provádění těchto zkoušek a provádění změn dokumentace a pracovní dokumentace pro systém;

d) Registrace zkušební zprávy a akt přijetí systému ve zkušební operaci.

11. Stage zkušební operace zahrnuje:

a) rozvoj programu a techniky zkušební operace;

b) zkušební provoz systému v souladu s programem a technikou zkušební operace;

c) zdokonalení systémového softwaru a dodatečné úpravy technických prostředků v případě detekce nedostatků zjištěných během provozu provozu systému;

d) Registrace zákona o dokončení zkušený provoz, který zahrnuje seznam nedostatků, které je třeba odstranit před operací systému.

12. Stage akceptačního testu zahrnuje:

a) testování systému pro dodržování technického úkolu pro jeho vytvoření v souladu s programem a metodikou akceptačních testů;

b) analýza výsledků odstranění nedostatků uvedených v zákoně o dokončení pilotního provozu;

c) Registrace aktu o přijetí systému uvedení do systému.

III. Požadavky na uvedení do provozu

13. Základem pro uvedení do provozu Systém je právním aktem výkonného orgánu systému uvedení do provozu, který určuje seznam opatření k zajištění systému uvedení do provozu a stanovení zahájení provozu.

14. Právní akt výkonného orgánu o uvedení do provozu Komise zahrnuje: \\ t

a) události o vývoji a schvalování organizačních a správních dokladů, které definují informace o ochraně informací v průběhu fungování systému, jehož rozvoj je stanoven právními předpisy a metodickými dokumenty federální výkonné orgány v rámci Oblast bezpečnosti a federálního výkonného orgánu pověřeného v oblasti působení technické inteligence a technické ochrany informací, jakož i vnitrostátních norem v oblasti bezpečnosti informací;

b) opatření pro certifikaci systému podle požadavků na ochranu informací v důsledku toho v případech stanovených právními předpisy, případy potvrzují soulad ochrany informací obsažených v systému, požadavky stanovené Právní předpisy Ruské federace o informacích, informačních technologiích a ochraně informací;

c) opatření na přípravu výkonného orgánu, jakož i soukromého partnera v případě dohody o partnerství veřejného a soukromého sektoru pro provoz systému;

d) Události o přípravě úředníků výkonného orgánu, jakož i zaměstnanci soukromého partnera v případě dohody o partnerství veřejného a soukromého sektoru pro provoz systému, včetně těch, které jsou odpovědné za zajištění ochrany informací.

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

a) nedodržení právních předpisů o ochraně informací stanovených právními předpisy Ruské federace, včetně nedostatku platného potvrzení o dodržování požadavků bezpečnosti informací;

b) nepřítomnost v rejstříku územního umístění kontrolních zařízení stanovených pravidly pro provádění umístění technických prostředků informačních systémů používaných vládními agenturami, místními vládami, státními a obecními jednotkami, státními a obecními institucemi, v Území Ruské federace, schválené nařízením vlády Ruské federace od 6. července 2015 N 675 "o postupu pro monitorování dodržování požadavků stanovených částí 2.1 článku 13 a část 6 článku 14 federálního 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ů této části zjištěné při provádění kontrol v souladu s pravidly pro monitorování dodržování požadavků na postup pro tvorbu, rozvoj, uvedení do provozu, provozu a závěru z provozu státních informačních systémů a Další úložiště obsažené ve svých databázích dat schválila vyhláška vlády Ruské federace ze dne 6. července 2015 N 675 "o postupu pro monitorování dodržování požadavků stanovených z části 2.1 článku 13 a část 6 článku 14 federálního Zákon o informacích, informačních technologiích a ochraně informací ". Tohoto dokumentu. Právní zákon a) Příprava právních aktů souvisejících s výstupem systému z vykořisťování;

b) Práce na systému vyřazování z provozu, včetně práce na odinstalaci systémového softwaru, realizovat práva na systémový software, demontáž a odepsat systém systému, zajistit skladování a další využití systémových informačních zdrojů;

Změnit informace:

Vyhláška vlády Ruské federace 11. května 2017 N 555 Bod 23 je doplněna podle pododstavce "v"

c) zajištění bezpečnosti informací v souladu s dokumentací pro systém a organizační a správní dokumenty o ochraně informací, včetně archivace informací obsažených v systému, zničení (mazání) údajů a zbytkových informací ze strany nosičů strojů a ( nebo) zničení strojních médií.

24. Pokud regulační právní úkony Ruské federace nebyly stanoveny jinak, je doba skladování informací obsažených v systémových databázích stanovena výkonným orgánem a nemůže být nižší než doba skladování informací, které jsou stanoveny pro skladování Dokumenty v papíru obsahující tyto informace.

25. Využití systému z provozu nemůže být dříve než lhůta pro konec poslední události stanovené právním úkonem na výstupu systému z vykořisťování.

Postup pro zadávání EIS do provozu.

Typický automatizovaný design. Stage do provozu.

Přednáška 10.

Podle GOST 34.601-90 "AU. Stage pro vytváření "a GOST 34.603-92" Druhy testů AU "v rámci fáze uvedení do provozu se provádějí následující práce:

1) organizační školení automatizace do akce - implementace návrhových řešení pro organizační strukturu, zajišťující jednotky předmětu řízení instruktivních metodických materiálů, zavedení informačních klasifikátorů;

2) příprava personálu - školení personál a kontrola jeho schopnosti zajistit operaci IP;

3) vybavení dodávaných výrobků IP (v případě nezbytného takového dodávání popsaného v CST) - získání složek sériové a jednotkové produkce, materiálů a montážních produktů, provádění vstupních řízení jejich kvality;

4) stavební a montážní práce - provádění práce na výstavbě specializovaných prostor pro umístění technického vybavení a personálu IP, konstrukce kabelových kanálů, montáž technických prostředků a komunikačních linek, testování namontovaných technických prostředků, manipulaci s technickými prostředky pro uvedení do provozu;

5) práce do provozu - Offline uvedení do provozu technického a softwaru, stahování informací do databáze a kontrola jeho údržby, integrované uvedení do provozu všech prostředků systému;

6) předběžné testování - zkušební zkouška výkonu a dodržování technického zadání v souladu s programem a metodou předběžných zkoušek; Odstraňování problémů a provádění změn IP dokumentace, včetně provozu v souladu s testovacím protokolem; Registrace aktu o přijetí IP do zkušební operace;

7) experimentální vykořisťování - zkušený provoz IP; analýza jeho výsledků; Zdokonalení IP softwaru; Další uvedení do provozu IP technických prostředků; Registrace zákona o dokončení zkušený provoz.

8) provádění akceptačních testů - testy pro dodržování technických úkolů v souladu s programem a metodami přijatelných zkoušek; Analýza výsledků testů IP a eliminace nedostatků identifikovaných během testování; Registrace aktu o přijetí IP do trvalého provozu.

Uvedení do emisí je postupný přechod ze stávajícího řídicího systému automatizovaným. Zároveň se zvyšuje nejen míra využití technických nástrojů pro zpracování dat, ale také se mění i metody řízení.

V souladu s spirálovým modelem životního cyklu systému, od fáze technického designu, subsystém EIS, úkoly úkolů nebo jednotlivé složky schopné samoobslužné, jsou uvedeny do provozu ve fázích, protože pracovní dokumentace a technické prostředky jsou snadno.

Fáze uvedení do provozu zahrnuje zkušenou činnost úkolů a přijímá je do komerčního provozu po obdržení a zkušebním testování. V průmyslové operaci je celý systém přijat po dokončení přijetí všech komplexů úkolů.

Jedním z důležitých rysů systému uvedení do provozu je přítomnost určitého období, během něhož se provádí paralelní provoz stávajícího systému a nové EIS. V technických systémech je jeden přístroj nahrazen jinými nejčastěji včas. Někdy je nový stroj instalován na místě starého - v tomto případě, žádné nové vybavení nefunguje nějakou dobu nějakou dobu. Pokud přijde nový, přijde do pořádku než staré zastávky, pracují nezávisle na sobě. Při uvádění do provozu EIS organizačního typu je zásadně nemožné, situace, na které alespoň ani starý ani nový systém nefungoval krátce. Kromě toho, aby ověřil správnost všech položených rozhodnutí, je uvedení do provozu nového systému postupně prováděn během experimentálního provozu následujících kroků:

1. Zkontrolujte komplex subsystému nebo úkolu v plných skutečných údajích, ale ne v reálném čase potřebném k řízení.

2. Provoz nového systému je v plném rozsahu reálných dat a pro reálné podmínky v režimu řízení, když výsledky nejsou používány k řízení, ale jsou porovnány s výsledky získanými v předchozímu systému a jsou analyzovány.

3. Přechod na správu na základě výsledků nového systému při zachování v práci starého systému v případě možných poruch a nepředvídatelných situací.

4. Konečný přechod do nového systému.

Provoz systému v paralelním režimu je pro zaměstnance extrémně nepříznivé. Musí provádět dvojí práci s vysokým zatížením. Vývojáři systému by se měli snažit snížit dobu paralelní práce, což významně závisí na tom, jak úspěšně byl proveden vývoj a ladění systému. Je nepřijatelné vydržet alespoň část ladění a přizpůsobení systému po dobu zkušeného vykořisťování. Změny a během tohoto období jsou však nevyhnutelné, mělo by být usilovat o pouze tak, že nebylo možné před zahájením zkušenosti poskytovat.

Zkušený provoz překrývá proces testování. Systém je zpravidla uveden zcela, postupně. Z hlediska informací vyplněného systému je proto uvedení do provozu v nejméně tří fázích: \\ t

2) akumulace informací;

3) Konec na konstrukční kapacitu.

Zahájení poměrně úzkého kruhu chyb - převážně problematiky shody dat při načítání a vlastních chybách nakladače, to znamená, že to, co nebylo sledováno na testovacích datech. Pokud je ladění "živých" dat nemožné vyrábět, pak budete muset modelovat situaci a rychle. Vyžadují se zde velmi kvalifikované testery.

Během akumulace informací Zobrazí se největší počet chyb vytvořených vytvářením informačního systému. Jedná se o chyby spojené s přístupem pro více hráčů. Často v testovací fázi nejsou takové chyby věnovány náležitou pozornost. To je způsobeno, zřejmě se složitostí modelování, stejně jako s vysokými náklady na automatizaci testování informačního systému v podmínkách přístupu pro více hráčů. Některé chyby opravují, je to poměrně obtížné, protože jsou chyby návrhu. Žádný největší projekt z nich není pojištěný. To znamená, že jen v případě, že potřebujete rezervovat čas pro lokalizaci a korekci těchto chyb.

V období akumulace informací můžete čelit slavnému "pádu základny". V nejhorší situaci se ukázalo, že DBMS nevydrží tok informací. S dobrým - pouze konfigurační parametry jsou nesprávné. První případ je nebezpečný, protože je velmi obtížné ovlivnit výrobce DBMS a zákazník nemá rád odkazy na službu technické podpory DBMS. Řešení problému selhání DBM nebude muset výrobce, ale změnit režim, snížit tok žádostí, změnit požadavky; Obecně existuje mnoho možností. Pokud se čas obnova databáze hodí do plánovaného projektu.

Systémový výstup na konstrukční kapacitu, když Dobrá konkrétní okolnost je korekce řady malých chyb a příležitostně - vážné chyby.

GOST 24.208-80 Požadavky na obsah dokumentů "Uvedení do provozu"

Usnesení Státního výboru SSSR k normám 14. května 1980 č. 2101 Úvod

od 01.01 1981.

Tato norma se vztahuje na technickou dokumentaci pro automatizované řídicí systémy (ACS) všech typů vyvinutých pro všechny úrovně kontroly (s výjimkou národního) a stanoví požadavky na obsah dokumentů vyvinutých na stupni "uvedení do provozu" v souladu s požadavky GOST 24.101-80.

1. Obecná ustanovení

1.1. Dokumenty vyvinuté ve fázi uvedení do provozu jsou označovány jako akceptační dokumentaci pro ACS.

1.2. Při vypracování dokumentů do části ACS je obsah dokumentů omezen na rámec odpovídající části ACS.

1.3. V závislosti na účelu a specifických specifikách vytvořených ACS je dovoleno zahrnout další informace v dokumentech, jejichž požadavky na obsah, který není zřízen tímto standardem.

2. Požadavky na akceptační dokumentaci

2.1. Dokončení práce

2.1.1. Dokument je navržen tak, aby opravil skutečnost, že při vytváření ACS dokončí samostatnou práci.

2.1.2. Dokument se nevztahuje na stavebnictví a uvedení do provozu a uvedení do provozu.

2.1.3. Dokument musí obsahovat:

jméno dokončené práce (práce);
seznam zástupců organizace-developer a organizace-zákazníka, který zkompilovaný akt;
datum dokončení práce;
název dokumentu (dokumentů) na základě které práce byla provedena;
hlavní výsledky dokončené práce;
závěr o výsledcích dokončené práce.

2.2. Aktu o přijetí ve zkušební operaci

2.2.1. Dokument je navržen tak, aby opravil skutečnost vstupu ACS vstupu jako celku nebo jeho částí do zkušební operace.

2.2.2. Dokument musí obsahovat:

název ACS (nebo její části) přijaté ve zkušební operaci a odpovídajícím řídícím zařízením;
složení akceptační komise a základ pro její práci (jméno, číslo a datum schválení dokumentu, na jejichž základě byla vytvořena Komise);
složení funkcí ACS (nebo její části) přijaté do zkušební operace;
seznam komponent technického, softwaru, informací a organizačních ustanovení ověřitelných v procesu zkušený provoz;
hlavní výsledky přijetí ve zkušební operaci;
rozhodnutí Komise o přijetí ACS do zkušební operace.

2.3. Zákon přijetí v průmyslové operaci

2.3.1. Dokument je navržen tak, aby opravil skutečnost vložení ACS (nebo jeho části) do průmyslové operace.

2.3.2. Dokument musí obsahovat:

název předmětu kontroly a ACS (nebo jejích částí) přijatých do průmyslového provozu;
informace o stavu akceptační komise (stát, meziresortní, oddělení), jeho složení a důvody pro svou práci;
doba práce Komise;
název organizace-developer, organizace-Spolu-Appliance a zákaznické organizace;
název dokumentu na základě kterého byl vytvořen ACC;
složení funkcí ACS (nebo její části) přijaté do průmyslového provozu;
seznam součástí technického, softwaru, informací a organizačních podpor přijatých do průmyslové operace;
seznam dokumentů uložených Komisí;
závěr o výsledcích experimentálního provozu ACS;
posouzení souladu AKU k technickému úkolu pro jeho vytvoření;
krátké vlastnosti a hlavní výsledky práce prováděné na tvorbě ACS;
posouzení vědecké a technické úrovně ACS (podle údajů projektu) *;
posouzení ekonomické účinnosti z provádění ACS (podle údajů projektu) *;
rozhodnutí Komise;
doporučení Komise pro další rozvoj systému *.

* Nutně při přijímání ACS obecně.

2.3.3. "Akt přijetí průmyslové operace" činí program a protokoly testů, protokoly schůzek Komise, akty přijetí do průmyslového provozu ACS přijatých dříve, seznam technických prostředků, který použil Komisi pro přijetí ACS. Podle uvážení Komise je povoleno zahrnout další dokumenty v žádosti.

2.4. Plán-plán

2.4.1. Dokument stanoví seznam prací, načasování provádění a zahajovatele práce související s tvorbou práce.

2.4.2. Dokument pro každou práci v seznamu musí obsahovat:

jméno práce;
datum zahájení a ukončení;
jméno pracovního partnera;
příjmení a postavení odpovědného performera;
vzorec pro prezentaci výsledků práce.

2.5. Pořadí práce

2.5.1. V závislosti na fázi práce na tvorbě ACS jsou stanoveny následující odrůdy dokumentu: \\ t

oBJEDNÁVKA o připravenosti správního zařízení k provádění stavebních a montážních prací;
na připravenosti správního zařízení k provádění úpravy;
na začátku zkušení provozu ACS (jeho částí);
pořadí vstupu do průmyslového provozu ACS (jeho části).

2.5.2. Dokument "Objednávka na připravenosti zařízení pro provádění konstrukce a instalace" musí obsahovat:

zpráva o připravenosti správního zařízení pro provádění stavebních a montážních prací;
stanovení stavební zóny a instalace;
postup pro přijetí do práce;
seznam představitelů organizace zákazníka odpovědné za provádění prací a bezpečnosti připojených zařízení;
seznam odpovědných zástupců stavebních a instalačních organizací vyrábějících práce.

2.5.3. Dokument "Objednávka na připravenosti správního zařízení k provádění uvedení do provozu by měl obsahovat: \\ t

zpráva o připravenosti správního zařízení k provádění úpravy;
seznam technických prostředků, které mají být upraveny AC;
indikace postupu pro provádění zařízení;
postup pro přijetí do provozu;
seznam zástupců Organizace zákazníka odpovědné za řízení uvedení do provozu;
seznam odpovědných zástupců organizací provádějících uvedení do provozu;
pokyny k postupu pro eliminaci chyb instalace a osoby odpovědné za provádění těchto prací.

2.5.4. Dokument "Objednávka na začátku zkušený provoz ACS (jeho částí) musí obsahovat:

jméno ACS obecně nebo jeho části procházející zkušeným provozem;
termíny pro zkušený provoz;
seznam úředníků zákaznické organizace a organizace developerských odpovědných za vedení zkušený provoz;
seznam zákaznických organizací zapojených do vedení zkušeného vykořisťování.

2.5.5. Dokument "Objednávka podniku v průmyslovém provozu ACS (jeho částí)" musí obsahovat: \\ t

složení funkcí ACS nebo jeho částí, technických a softwarových nástrojů odebraných do průmyslového provozu;
seznam úředníků a seznam divizí organizace zákazníka odpovědné za práci ACS;
postup a termíny pro zavedení nových forem dokumentů (v případě potřeby);
postup a termíny pro překlad iniciované pod fungováním ACS.

2.6. Na schématu akceptační komise

Dokument musí obsahovat:

jméno přijatého ACS obecně nebo jeho částí;
informace o složení Komise;
důvody pro organizaci Komise;
jméno organizace zákazníka;
název organizace-vývojáře, organizování ko-ventily;
jmenování a cíle Komise;
termíny pro začátek a dokončení práce Komise;
pokyny pro vyplnění Komise.

2.7. Program práce

2.7.1. V závislosti na údržbě práce jsou nainstalovány následující typy dokumentů:

testovací program;
program zkušené operace;
program práce Komise.

2.7.2. Dokument "Testovací program" je určen k určení postupu pro provádění předběžných zkoušek při přenosu a přijímání testování při přenosu do průmyslového provozu ACS.

Dokument musí obsahovat:

složení funkcí ACS obecně nebo jejích částí podléhajících zkouškám, s odkazem na předměty technického úkolu na vytvoření ACS;
seznam komponent technického, softwaru, informací a organizačních podpor, které jsou předmětem testů;
postup pro testování jednotlivých složek ACS a jednotlivých funkcí ACS;
termíny a načasování testování;
postup pro registraci testů a identifikovaných nedostatků;
postup pro odstranění nedostatků a provedení nezbytných změn technické dokumentace;
určování formuláře výsledků testů.

2.7.2. "Program experimentální operace" je určen k určení objednávky a objemu zkušební operace.

Dokument musí obsahovat:

složení funkcí ACS a jeho částí, které mají být spuštěny, s odkazem na předměty technického úkolu pro vytvoření ACS;
seznam součástí technického, softwaru, informací a organizačních předpisů, které mají být zaženy;
postup pro personální akce v experimentálním provozu prvků ACS a jednotlivých funkčních subsystémů;
podmínky a termíny pro zkušební provoz;
postup registrace výsledků zkušebního provozu a identifikovaných nevýhod;
postup pro odstranění identifikovaných nedostatků a změn technické dokumentace;
označení formy reprezentace výsledků experimentálního provozu.

2.7.2. Dokument "Program prací akceptační komise" je určen k určení postupu pro přijetí ACS do průmyslové operace. Složení a obsah dokumentu stanoví regulační a technické dokumenty schválené v tomto odvětví.

2.8. Protokol o zkoušce

2.8.1. Dokument je navržen tak, aby vyřešil výsledky předběžných testů při přenosu ACS obecně nebo jeho částí do experimentálního nebo průmyslového provozu.

2.8.2. Dokument musí obsahovat:

název testovacího objektu;
seznam úředníků, kteří test provedli;
Účel zkoušky;
informace o délce testu;
seznam položek technického zadání k vytvoření ACS, pro dodržování testů;
seznam položek "Testovací program", na kterých byly provedeny testy;
informace o výsledcích připomínek ke správnému provozu ACS;
informace o poruchách, poruchách a nouzových situacích, ke kterým došlo během testování;
informace o úpravách parametrů testovacího objektu a technické dokumentace.

2.9. Koordinace protokolu

2.9.1. Dokument je určen k harmonizaci odchylek od dříve přijatých a schválených rozhodnutí o návrhu, kdy v procesu experimentálního provozu ACS jako celku nebo její části odhalily potřebu jejich úpravy.

2.9.2. Dokument musí obsahovat:

seznam disked odchylek s uvedením dokumentu, odchylky od požadavků, jejichž jsou předměty koordinace;
seznam úředníků, kteří sestavili protokol;
odůvodnění přijatých odchylek od návrhových řešení;
seznam dohodnutých odchylek a termínů pro provedení nezbytných změn technické dokumentace.

Dotisk. Květen 1986.