Informācijas sistēmas nodošana ekspluatācijā. Ievads rūpnieciskajā darbībā GOST informācijas sistēmu

Apstiprināt

Valsts regulas departamenta direktora vietnieks ekonomikā

Krievijas Federācijas Ekonomikas attīstības ministrija
______________ V.N. Rudenko
« 09 » _ novembris__ 2011

Likums par pasūtīšanu izmēģinājuma operācijā

Automatizēta projektu vadības informācijas sistēma, kas izstrādāta ietvaros Valsts līguma datēts 2011. gada 7. novembris Nr. GK-158-OF / D01.
Saskaņā ar Klienta kopīgo lēmumu (Krievijas Ekonomikas attīstības ministrija) un Līgumslēdzējs (LLC "OTR 2000"), lai ieviestu izmēģinājuma darbību.

Komisija sastāvā:

Komisijas priekšsēdētājs:

Valsts regulas departamenta direktora vietnieks ekonomikā V.N. Rudenko,

Komisijas locekļi:

Rīkojies galvenā Elektroniskās sabiedrības attīstības departaments Ekonomikā S.V. Pushakovā, \\ t

Metodoloģiskā atbalsta departamenta padomnieks valsts regulējuma departamenta starpdienestu mijiedarbības organizēšanai ekonomikā A.V. Matveenko,

Vadošais konsultants Attīstības departamenta par Elektroniskās sabiedrības departamenta Valsts regulas ekonomikā N.N. Kirsanova

LLC virziena vadītājs "OTP 2000" A.I. Kuleshova,

Projektu vadītājs LLC "OTR 2000" O.V. Apdrošināšana

Vadošā analīze LLC "OTR 2000" Yu.M. Gudkova,

"Reālā sektora" vadības pētnieks, kas nosaukts pēc E.T. Gaidar E.R. Battarkshina.
kopš "_" 08 _" novembris 2011 ar "_ 09 _" novembris 2011. gadā veica lietišķās programmatūras sākotnējos testus automatizētajai informācijas sistēmai "Projektu vadības portāls" (AIS PPU), kas izveidots Krievijas Ekonomiskās attīstības ministrijā.


  1. Sākotnējie testi tiek atzīti veiksmīgi pabeigti.

    1. Galvenie attīstības posmi tiek veikti saskaņā ar atskaites noteikumiem.

    2. Attīstīts dokumentācija atbilst prasībām Programmatūras darbība.

    3. Programmatūra, kas sagatavota izmēģinājuma darbībai.

  1. Izmēģinājuma operācijā iekļauto funkciju saraksts (sadaļa "Prasības attiecībā uz funkcijām, ko sistēma veic" no tehniskā uzdevuma):

    1. Saglabājot projektu sarakstu.

    2. Darbs ar dizaina vienībām.

    3. Darbs ar rādītājiem, lai novērtētu darba statusu projektā.

    4. Analītiskais modulis.

    5. Dokumentu bibliotēka.

  1. Sarakstu ar dokumentiem, kas nepieciešami pieredzējušai operācijas veikšanai:

    1. "AIS" projektu vadības portāla "apraksts" (sistēmas pase);

    2. "Administratora instrukcija AIS PPU";

    3. "Lietotāja instrukcijas AIS PPU";

    4. "AIS PPU testēšanas programma un metodes";

    5. "Testa uzdevumi AIS PPU";

    6. "Lomu spēles norādījums, kurā aprakstīta procedūra, lai strādātu ar AIS PPU kā projektu vadības rīks" starpdepartal mijiedarbība ".

  2. Komisijas lēmums: pieņemiet izmēģinājuma darbības plānošanu no 2011. gada 9. novembra.

Pieteikumi:


  1. Protokols par sākotnējo testu Nr.1

  2. Protokols par sākotnējo testu Nr 2
Komisijas locekļi:

V.N. Rudenko

S.V. Pushcakov

A.v. Maldināt

N.n. Kirsanova

A.i. Kulīnists

O.V. Apdrošināšana

Yu.m. Gudkovs

E.R. Bartarshin

Pieņemšanas akts izmēģinājuma darbībā Veidlapas, pamatojoties uz provizorisko testu rezultātiem un ietver: secinājumus, kas veikti saskaņā ar visaptverošo testu rezultātiem; Uzdevumi izmēģinājuma darbībai.

Komisijas laika periods

Šī akta akta sadaļa tiek dota pieņemšanas komisijas darba sākuma un beigas par iepriekšēju testu veikšanu.

Testa sākums - 2010. gada 1. novembris.
Testa beigas - 2010. gada 31. decembris.
Kopējais testēšanas ilgums - 44 darba dienas.

Organizācijas-klientu, organizācijas izpildītāja un organizācijas ierīču nosaukums

Testēšanas dalībnieku organizāciju nosaukums un tie, kas apkopojuši informācijas sistēmas pieņemšanas aktu izmēģinājuma darbībā.

Klienta organizācija - OJSC klients.
Organizācijas izpildītājs - CJSC "Līgumslēdzējs".
Organizācijas-co-vārsts - LLC "Solvdilizer" (ja tāds ir).

AIS funkciju sastāvs, kas pieņemts izmēģinājuma darbībā

Tiek uzskaitīta izmēģinājuma operācijā pieņemto AIS funkciju sastāvs. Funkcijas var nosūtīt gan sistēmas, gan apakšsistēmas. Funkcijas tiek veiktas no sadaļas "Prasības funkcijas, ko sistēma veic" Tehniskais uzdevums izveidot informācijas sistēmu.

Tehnisko, programmatūras, informācijas un organizatorisko noteikumu komponentu saraksts, kas pārbauda izmēģinājuma procesā

Šajā pieņemšanas likuma sadaļā ir sniegts izmēģinājuma darbības laikā veikto testu saraksts. Testu saraksts tiek ņemts no sadaļas "Testa apjoma" testa programma.

Pieredzētās operācijas procesā pārbaudes ir pakļautas tabulai.

Komisijas iesniegto dokumentu saraksts

Šī akta akta sadaļa sniedz sarakstu ar dokumentiem, ko Komisija sniedz dokumentiem, kas vajadzīgi, lai veiktu pieredzējušu operāciju.

Norādījumi datu bāzes veidošanai un uzturēšanai (datu kopa), 1. versija 09/12/2010.
- Lietotāja rokasgrāmata, versija 1 datēta 09/14/2010.
- ...

Pieņemtā AIS tehniskā virsnieka atbilstības novērtējums

Tehniskā uzdevuma AIS atbilstības novērtējums tiek sniegts.

Saskaņā ar provizorisko testu rezultātiem sistēma atbilst dokumentā iesniegtajām prasībām: ". Versija 1.0.

Galvenie izmēģinājuma darbības rezultāti

Šajā akceptēšanas aktu sadaļā ir uzskaitīti galvenie rezultāti, kas iegūti, izmantojot informācijas sistēmas eksperimentālās darbības rezultātus.

Saskaņā ar eksperimentālās darbības rezultātiem būtu jāiegūst šādi galvenie rezultāti:
- sistēma darbojas;
- sistēmas apakšsistēmas - mijiedarbojas;
- Sistēma atbilst dokumenta "Tehniskais uzdevums, lai izveidotu automatizētu sistēmu". Versija 1.0.;
- Visi raksturlielumi ir pakļauti novērtējumam, ir pieņemami ierobežojumi.

Komisijas lēmums par AIS pieņemšanu izmēģinājuma darbībā

Komisijas lēmums par iespēju vai neiespējamību pieņemt informācijas sistēmu izmēģinājuma operācijā.

Kovtun m.v. 2010. gada oktobris.

Krievijas Federācijas valdības dekrēts 2015. gada 6. jūlija N 676
"Par valsts informācijas sistēmu darbības izveidi, izstrādi, ekspluatāciju, darbību un noslēgšanu no valsts informācijas sistēmu darbības un turpmākās uzglabāšanas, kas ietverta to informācijas datubāzēs"

Saskaņā ar Federālā likuma "Par informāciju, informācijas tehnoloģiju un informācijas aizsardzību" 6. daļu, Krievijas Federācijas valdība nolemj:

1. Apstiprināt papildu prasības attiecībā uz valsts informācijas sistēmu darbības, izstrādes, ekspluatācijas, darbības un noslēgšanas procedūru un turpmāku glabāšanu, kas iekļautas to informācijas datu bāzēs.

2. noteikt, ka šīs rezolūcijas prasības, kas paredzētas šīs rezolūcijas prasības, veic federālās izpildinstitūcijas budžeta piešķīrumos, ko paredz Federālais likums par federālo budžetu attiecīgajam fiskālajam gadam un rokasgrāmatas un pārvaldības plānošanas periodam izveidoto funkciju jomā.

3. Iesakām citām valsts aģentūrām, papildus federālajām izpildinstitūcijām un izpildinstitūcijām Satversmes struktūrām Krievijas Federācijas, kā arī valsts ekstrabudgetāro līdzekļu, pašvaldību vadāmās savā darbībā ar prasībām, kas apstiprinātas ar to Rezolūcija.

Prasībām
uz procedūru, izstrādājot, izstrādājot, nodot ekspluatācijā, ekspluatācijā un produkciju no valsts informācijas sistēmu darbības un turpmāku glabāšanu, kas iekļautas to informācijas datubāzēs
(Ierīce. Krievijas Federācijas valdības dekrēts 2015. gada 6. jūlijs N 676)

Ar izmaiņām un papildinājumiem:

I. Vispārīgi noteikumi

1. Šis dokuments nosaka prasības attiecībā uz pasākumu īstenošanas kārtību, lai izveidotu, attīstītu, ekspluatāciju, darbību un noslēgtu valsts informācijas sistēmu (turpmāk - sistēma), un turpmāku informāciju, kas ietverta to datubāzēs veikto informāciju federālās izpildinstitūcijas un izpildinstitūcijas iestādēm par Satikņu struktūrām Krievijas Federācijas (turpmāk tekstā izpildu iestādes), lai uzlabotu efektivitāti Iestādes izpildu iestāžu, kā rezultātā informācijas un Komunikācijas tehnoloģijas vai izpildvaras iestādes, kas darbojas kā valsts partneri un privātie partneri saskaņā ar publiskā un privātā sektora partnerības nolīgumiem (turpmāk - privāts partneris), lai īstenotu šos nolīgumus.

1.1. Īstenojot izpildvaras iestādes vai nu privātiem partneriem pasākumiem, lai izveidotu, izstrādātu, ekspluatāciju, darbību un noslēgtu sistēmas darbību un turpmāku uzglabāšanu, kas ietverta to datubāzēs, būtu jāveic:

a) prasības attiecībā uz informācijas aizsardzību, kas ietvertas Izpildes iestādes federālās iestādes noteiktajās sistēmās drošības un federālās izpildvaras iestāde, kas atļauta tehniskās izpētes un informācijas apkarošanas jomā, to pilnvarās;

b) prasības organizācijai un pasākumiem, lai aizsargātu sistēmā ietverto informāciju;

Mainiet informāciju:

1.1. Punktu papildina "b" apakšpunkts no 2019. gada 27. aprīļa - Rezolūcija

c) Prasības personas datu aizsardzībai, kas paredzēti Federālā likuma "Par personas datiem" 19. panta 3. daļā (personas datu sistēmas gadījumā).

Mainiet informāciju:

Krievijas Federācijas valdības dekrēts 2017. gada 11. maija N 555 prasībām papildina 1.2. Punkts

1.2. Lai izpildītu šīs dokumenta 1.1. Punktā paredzētās informācijas aizsardzības prasības (turpmāk tekstā - informācijas aizsardzības prasības), izpildvaras nosaka prasības izpildinstitūcijas sistēmā ietvertās informācijas aizsardzībai , par kuru viņi veic:

a) informācijas definīcija, kas jāaizsargā no nelikumīgas piekļuves, iznīcināšanas, modifikācijas, bloķēšanas, kopēšanas, nodrošināšanas, izplatīšanas, kā arī citām nelikumīgām darbībām šādai informācijai;

b) reglamentējošo tiesību aktu, metodisko dokumentu un valsts standartu analīze, kas jākonfigurē;

c) sistēmas klasifikācija saskaņā ar informācijas aizsardzības prasībām;

d) nosakot draudus informācijas drošībai, kuru īstenošana var novest pie informācijas drošības pārkāpuma sistēmā, kā arī attīstību, pamatojoties uz informācijas drošības draudiem;

e) Sistēmā iekļautās informācijas aizsardzības sistēmas (apakšsistēmas) prasību noteikšana.

II. Prasības sistēmas izveides procedūrai

2. Sistēmas izveidošanas pamats ir:

a) izpildvaras pienākums izveidot regulatīvos tiesību aktos paredzēto sistēmu;

b) izpildvaras lēmums par sistēmas izveidi, lai nodrošinātu Viņam piešķirto pilnvaru īstenošanu;

Mainiet informāciju:

2. punktu papildina apakšpunkts "in" no 2019. gada 27. aprīļa - Krievijas valdības 2009. gada 11. aprīļa N 420

c) lēmums par Krievijas Federācijas valdības par publiskā un privātā sektora partnerības projekta īstenošanu;

Mainiet informāciju:

2. punktu papildina "G" apakšpunkts no 2019. gada 27. aprīļa - Krievijas valdības rezolūcija 2019. gada 11. aprīļa N 420

d) Krievijas Federācijas komponenta Augstākās izpildinstitūcijas lēmums, ja valsts partneris ir Krievijas Federācijas priekšmets vai kopīga konkurence, piedaloties Krievijas Federācijas priekšmets (ar Izņemot kopīgu konkurenci ar Krievijas Federācijas līdzdalību).

3. Sistēmas izveide tiek veikta saskaņā ar tehnisko uzdevumu, ņemot vērā šī dokumenta 1.2. Punktā paredzētās drošības draudu modeli, kā arī personas drošības līmeni Dati, apstrādājot personas datu informācijas sistēmās atkarībā no draudiem šo datu un prasību drošībai, šis dokuments.

Informācijas drošības draudu modelis un (vai) tehniskais uzdevums sistēmas izveidei atbilst federālajai izpildvarai drošības jomā un federālajā izpildvaras iestādē, kas ir atļauta tehniskās izpētes un informācijas tehniskās aizsardzības apkarošanas jomā, ietvaros; to pilnvaras attiecībā uz noteikto informācijas aizsardzības prasību īstenošanu.

Tehniskais uzdevums, lai izveidotu sistēmu, jāiekļauj saskaņā ar šā dokumenta 1.1. Punkta "A" un "C". Prasības sistēmā ietvertās informācijas aizsardzībai.

4. Tehniskais uzdevums, lai izveidotu sistēmu, un informācijas draudu modelis informācijai apstiprina izpildvaras amatpersona, kurai uzticēta attiecīgajai iestādei.

5. Sistēmas izveides procedūra ietver šādus secīgus īstenotos pasākumus: \\ t

a) sistēmas un tās daļu dokumentācijas izstrāde;

b) darba dokumentācijas izstrāde sistēmai un tās daļām;

c) programmatūras izstrāde vai pielāgošana;

d) pasūtīt darbu;

e) veicot sistēmas provizoriskus testus;

e), veicot pieredzējušu darbību sistēmā;

g) pieņemšanas testu veikšana sistēmas.

6. Sistēmas dokumentācijas izstrādes posms un tās daļa ietver dokumentācijas izstrādi, koordināciju un apstiprināšanu tādā apmērā, kas nepieciešama, lai aprakstītu pilnīgu dizaina risinājumu kopumu (tostarp informācijas aizsardzību), un pietiekams, lai turpmāk izpildītu darbu par sistēmas izveidi.

7. sistēmas izstrādes sistēma sistēmai un tās daļai ietver dokumentācijas izstrādi, koordinēšanu un apstiprināšanu, kurā ir informācija, kas vajadzīga, lai veiktu darbu, lai veiktu sistēmas ekspluatācijā un tās darbību, kā arī procedūru, lai izmantotu Sistēma, kas satur informāciju, kas vajadzīga, lai saglabātu tehniskās apkopes ekspluatācijas īpašības sistēmas (ieskaitot informācijas aizsardzību), kas noteikts šā dokumenta 6. punktā noteiktajos projektēšanas lēmumos, tostarp: \\ t

a) darbinieku darbības saraksts, veicot sistēmas darbības uzdevumus, tostarp sarakstu, sugas, apjomus un darba biežumu, lai nodrošinātu sistēmas darbību;

b) sistēmas un sastāvdaļu, kas sniedz informācijas aizsardzību, kontrole;

c) to kļūdu saraksts, kas var rasties sistēmas darbības laikā un ieteikumus darbībām to rašanās laikā;

d) sistēmas darbības veidu saraksts un to īpašības, kā arī sistēmas tulkošanas procedūra un noteikumi no viena darba režīma uz citu, norādot nepieciešamo laiku.

8. Programmatūras izstrādes vai adaptācijas solis ietver sistēmas programmatūras izstrādi, iegādātā programmatūras izvēli un pielāgošanu, kā arī gadījumos un kā sertificēt izstrādāto programmatūras programmatūru un informācijas drošības instrumentus informācijas drošības prasībām.

9. Pasūtījuma posms ietver autonomu tehnisko līdzekļu un sistēmas programmatūras daļu, lejupielādējot informāciju savā datu bāzē, visaptverošu tehnisko līdzekļu un sistēmas programmatūras mērķauditorijas atlasi, tostarp informācijas aizsardzības līdzekļus.

10. Iepriekšēja testa fāze ietver:

(A) izstrāde programmas un metodes provizorisku testu, saskaņā ar kuru sistēma ir pārbaudīta veiktspēju un atbilstību tehniskajam uzdevumam tās izveidei;

b) pārbaudīt sistēmas veiktspēju un atbilstību tehniskajam uzdevumam tās izveidei;

c) darbības traucējumu novēršana, veicot šādus testus un veicot izmaiņas dokumentācijā un darba dokumentācijā sistēmai;

d) Testa ziņojuma reģistrācija un sistēmas pieņemšanas akts izmēģinājuma darbībā.

11. Izmēģinājuma darbības posms ietver:

a) programmas izstrāde un izmēģinājuma darbības tehnika;

b) sistēmas izmēģinājuma darbību saskaņā ar izmēģinājuma darbības programmu un metodi;

c) sistēmas programmatūras pilnveidošana un tehnisko līdzekļu pielāgošana sistēmas darbības laikā konstatēto trūkumu atklāšanas gadījumā;

d) Reģistrācija Akta par pabeigšanu pieredzējušās operācijas, kas ietver sarakstu trūkumu, kas ir jānovērš pirms sistēmas darbības.

12. Pieņemšanas pārbaudes posms ietver:

a) testēšana sistēmu, lai atbilstu tehniskajam uzdevumam tās izveidei saskaņā ar programmu un pieņemšanas testu metodiku;

b) analīze par to, kā novērst trūkumus, kas norādīti likumā par izmēģinājuma darbības pabeigšanu;

c) reģistrācijas akta pieņemšanas sistēmas nodošanu ekspluatācijā.

III. Prasības ekspluatācijas sistēmai

13. Sistēmas nodošanas pamats ir ekspluatācijas sistēmas izpildvaras tiesību akts, kas nosaka pasākumu sarakstu, lai nodrošinātu ekspluatācijas sistēmu un izveidotu darbības sākšanu.

14. Izpildinstitūcijas nodošanas komisijas tiesību akts ietver: \\ t

a) notikumi par organizatorisko un administratīvo dokumentu izstrādi un apstiprināšanu, kas nosaka informāciju par informācijas aizsardzību sistēmas darbības laikā, kuru izstrāde ir paredzēta Federālās izpildvaras regulatīvajos tiesību aktos un metodoloģiskajos dokumentos drošības un federālās izpildvaras iestāde, kas atļauta tehniskās izlūkošanas novēršanas un informācijas aizsardzības jomā, kā arī valsts standartus informācijas aizsardzības jomā;

b) Sistēmas sertifikācijas pasākumi atbilstoši informācijas aizsardzības prasībām, kā rezultātā gadījumos, kas noteiktas tiesību aktos, lietās apstiprina sistēmas aizsardzības atbilstība sistēmā, prasības, kas noteiktas ar Krievijas Federācijas tiesību akti par informācijas, informācijas tehnoloģijām un informācijas aizsardzību;

c) pasākumi, lai sagatavotu izpildinstitūciju, kā arī privātu partneri, ja vienošanās par valsts un privātā sektora partnerību sistēmas darbībai;

d) Notikumi sagatavošanā amatpersonu izpildvaras, kā arī darbinieki privātā partnera, ja vienošanās par valsts un privātā sektora partnerību sistēmas, tostarp tiem, kas ir atbildīgi par informācijas aizsardzības nodrošināšanu.

15. Sistēmas ievadīšana nav atļauta šādos gadījumos:

a) neievērošana tiesību aizsardzības likumiem, kas izveidota ar Krievijas Federācijas tiesību aktiem, tostarp trūkst derīgu sertifikātu atbilstību informācijas drošības prasībām;

b) nav kontroles iekārtu teritoriālās izvietošanas reģistrā paredzētās teritoriālās izvietošanas noteikumos, lai īstenotu tehnisko līdzekļu informācijas sistēmu, ko izmanto valsts aģentūras, pašvaldības, valsts un pašvaldību vienības uzņēmumi, valsts un pašvaldību iestādes, \\ t Krievijas Federācijas teritorija, ko apstiprinājusi Krievijas Federācijas valdības dekrēts no 2015. gada 6. jūlija Nr 675 "par procedūru, lai uzraudzītu atbilstību prasībām, kas paredzētas 13. panta un Federālā 14. panta 6. daļā Likums "Par informācijas, informācijas tehnoloģiju un informācijas aizsardzību", informācija par informācijas sistēmas tehnisko līdzekļu izvietošanu teritorijā Krievijas Federācijā;

c) neievērojot šīs sadaļas prasības, kas konstatētas kontroles īstenošanas laikā saskaņā ar noteikumiem par valsts informācijas sistēmu izveides, attīstības, ekspluatācijas un noslēgšanas procedūras noteikumu uzraudzību, \\ t Turpmāka glabāšana, kas iekļauta to datu datubāzēs, apstiprināja Krievijas Federācijas valdības dekrētu, kas datēts ar 2015. gada 6. jūlija N 675 "par procedūru, lai uzraudzītu atbilstību 13. panta 2.1. Un no Federālā 14. panta 6.1. Likums "Par informāciju, informācijas tehnoloģijām un informācijas aizsardzību". Šajā dokumentā. Tiesiskais akts a) tiesību aktu sagatavošana, kas saistīta ar sistēmas produkciju no ekspluatācijas;

b) darbs ekspluatācijas pārtraukšanas sistēmā, tostarp darbu atinstalēšanas sistēmas programmatūrā, lai realizētu tiesības uz sistēmas programmatūru, demontēt un norakstīt sistēmas sistēmas, nodrošinot uzglabāšanu un turpmāku izmantošanu sistēmas informācijas resursu;

Mainiet informāciju:

Krievijas Federācijas valdības dekrēts 2017. gada 11. maijā N 555 23. punktu papildina apakšpunkts "In".

c) informācijas drošības nodrošināšana saskaņā ar dokumentāciju par sistēmu un organizatoriskiem un administratīviem dokumentiem par informācijas aizsardzību, tostarp sistēmas arhivēšanu, kas ietverta sistēmā, datu iznīcināšana (dzēšana) un atlikušo informāciju no mašīnbūvēm un ( vai) mašīnu mediju iznīcināšana.

24. Ja Krievijas Federācijas normatīvie akti nav noteikta citādi, tad sistēmas datu bāzēs ietvertās informācijas glabāšanas laiku nosaka izpildinstitūcija, un tā nevar būt mazāka par informācijas glabāšanai paredzēto informācijas glabāšanas laiku dokumentus papīra, kurā ir šāda informācija.

25. Sistēmas izmantošanu no darbības nevar būt agrāk kā pēdējā notikuma beigu termiņš, ko paredz juridiskais akts par sistēmas produkciju no ekspluatācijas.

Procedūra, lai ievadītu EIS ekspluatācijā.

Tipisks automatizēts dizains. Ekspluatācijā.

Lekcija 10.

Saskaņā ar GOST 34,601-90 "AU. Izveides posmi "un GOST 34.603-92" Testu veidu AU ", kas nodota ekspluatācijas posmā, tiek veikti šādi darbi:

1) automatizācijas mehānisma organizatoriskā apmācība darbībai - projektēšanas risinājumu īstenošana organizatoriskajai struktūrai, nodrošinot vienības objekta vadības instruktīvu metodisko materiālu, ieviešot informācijas klasifikatorus;

2) personāla sagatavošana - apmācīt personālu un pārbaudīt tās spēju nodrošināt IP darbību;

3) iP piegādāto produktu aprīkojums (attiecībā uz nepieciešamo piegādi, kas aprakstīta CST) - iegūšana sērijas un vienību ražošanas, materiālu un montāžas produktu, veicot ievades kontroli savu kvalitāti;

4) celtniecības un uzstādīšanas darbi - veikt darbu būvniecībā specializēto telpu būvniecībai tehnisko iekārtu un IP personāla izvietošanai, kabeļu kanālu būvniecība, tehnisko līdzekļu un sakaru līniju uzstādīšana, uzstādītu tehnisko līdzekļu pārbaude, tehnisko līdzekļu ekspluatācijas tehnisko līdzekļu pārbaude;

5) pasūtīšanas darbi - bezsaistes ekspluatācijā tehniskā un programmatūra, informācijas lejupielāde datu bāzē un pārbaudot tās uzturēšanu, integrētu ekspluatācijā visu sistēmu;

6) iepriekšēja pārbaude - testa tests veiktspēju un atbilstību tehniskajam uzdevumam saskaņā ar programmu un iepriekšēju testu metodi; Traucējummeklēšana un izmaiņas IP dokumentācijā, tostarp darbojoties saskaņā ar testa protokolu; IP pieņemšanas akta reģistrācija izmēģinājuma darbībā;

7) eksperimentālā ekspluatācija - pieredzējis IP darbība; tās rezultātu analīze; IP programmatūras pilnveidošana; IP tehnisko līdzekļu papildu nodošana ekspluatācijā; Reģistrācija aktus par pabeigšanu pieredzējušās operācijas.

8) pieņemšanas testu veikšana - testi atbilstoši tehniskajam uzdevumam saskaņā ar programmu un pieņemšanas testu metodēm; IP testa rezultātu analīze un testēšanas laikā konstatēto trūkumu novēršana; IP pieņemšanas akta reģistrācija pastāvīgā darbībā.

Emisijas nodošana ekspluatācijā ir pakāpeniska pāreja no esošās kontroles sistēmas, lai automatizētu. Tajā pašā laikā palielinās ne tikai datu apstrādes tehnisko instrumentu izmantošanas pakāpe, bet arī pašas pārvaldības metodes tiek attiecīgi mainītas.


Saskaņā ar sistēmas dzīves cikla spirālveida modeli no tehniskā dizaina posma EIS apakšsistēma, uzdevumu kompleksi vai individuālie komponenti, kas spēj pašfunkcionēt, tiek nodoti ekspluatācijā posmos, jo darba dokumentācija un tehniskie līdzekļi ir viegli.

Pasūtījuma posms ietver pieredzējušu uzdevumu darbību un saņemot tos komerciālā darbībā pēc saņemšanas un izmēģinājuma testēšanu. Rūpnieciskajā darbībā visa sistēma tiek pieņemta pēc visu kompleksu pieņemšanas pabeigšanas.

Viena no galvenajām ekspluatācijas sistēmas iezīmēm ir noteiktā laika posma, kurā tiek veikta esošās sistēmas un jaunās EIS paralēlā darbība. Tehniskās sistēmās viena ierīce tiek aizstāta ar citām visbiežāk laikā. Dažreiz jaunā mašīna ir uzstādīta uz vietas veco - šajā gadījumā, neviens jauns aprīkojums nedarbojas kādu laiku kādu laiku kādu laiku. Ja jaunais ierodas kārtībā nekā vecais pieturas, viņi strādā neatkarīgi viens no otra. Rezervējot Organizatoriskā tipa EIS, ir neiespējami, situācija, kad vismaz ne vecā vai jaunā sistēma nav strādājusi neilgi. Turklāt, lai pārbaudītu visu liktu lēmumu pareizību, jaunās sistēmas ekspluatācijā pakāpeniski tiek veikta šādu pasākumu eksperimentālā darbības laikā:

1. Pārbaudiet apakšsistēmu vai uzdevumu kompleksu pilnos reālos datus, bet ne reālajā laikā, kas nepieciešams, lai pārvaldītu.

2. Jaunās sistēmas darbība ir par pilnu reālo datu apjomu un reāliem noteikumiem kontroles režīmā, kad rezultāti netiek izmantoti, lai kontrolētu, bet tiek salīdzināti ar iepriekšējā sistēmā iegūtajiem rezultātiem un tiek analizēti.

3. Pāreja uz vadību, pamatojoties uz jaunu sistēmas rezultātiem, vienlaikus saglabājot vecās sistēmas darbā iespējamo neveiksmju un neparedzētu situāciju gadījumā.

4. Galīgā pāreja uz jauno sistēmu.

Sistēmas paralēlā režīmā darbībai ir ārkārtīgi nelabvēlīga darbiniekiem. Viņiem ir jāveic dubultā darbs ar lielu slodzi. Sistēmas izstrādātājiem jācenšas samazināt paralēlā darba laiku, kas būtiski ir atkarīgs no tā, cik veiksmīgi ir veikta sistēmas izstrāde un atkļūdošana. Ir nepieņemami izturēt vismaz daļu no atkļūdošanas un sistēmas pielāgošanu uz pieredzējušu ekspluatāciju. Izmaiņas un šajā periodā ir neizbēgamas, tomēr ir jācenšas tikai tādam, ka pirms pieredzes sākuma nebija iespējams sniegt neiespējamu.

Pieredzējis darbība pārklājas testēšanas procesu. Kā likums, sistēma tiek pasūtīta ne pilnībā, pakāpeniski. Tāpēc no informācijas aizpildīšanas viedokļa ekspluatācijā ir vismaz trīs posmos:

2) informācijas uzkrāšana;

3) Iziet uz dizaina jaudu.

Uzsāk diezgan šauru kļūdu loku - galvenokārt datu neatbilstības problēmas, ielādējot un jūsu pašu iekrāvēju kļūdas, tas ir, kas nav izsekots testa datiem. Ja "tiešraides" datu atkļūdošana nav iespējama, tad jums būs jāizstrādā situācija un ātri. Šeit ir nepieciešami ļoti kvalificēti testeri.

Laikā informācijas uzkrāšana Parādīsies lielākais kļūdu skaits, izveidojot informācijas sistēmu. Kā likums, šīs ir kļūdas, kas saistītas ar multiplayer piekļuvi. Bieži vien testa posmā šādas kļūdas nav pienācīgas uzmanības. Tas ir saistīts, acīmredzot, ar modelēšanas sarežģītību, kā arī ar augstām izmaksām, automatizējot informācijas sistēmas testēšanu multiplayer piekļuves apstākļos. Dažas kļūdas ir diezgan grūti, jo tās ir dizaina kļūdas. Nav lielākais projekts no tiem ir apdrošināts. Tas nozīmē, ka tikai gadījumā, ja jums ir nepieciešams rezervēt laiku lokalizācijai un šādu kļūdu labošanai.

Informācijas uzkrāšanas periodā jūs varat saskarties ar slaveno "krita bāzi". Sliktākajā situācijā izrādās, ka DBMS neiztur informācijas plūsmu. Ar labu - tikai konfigurācijas parametri ir nepareizi. Pirmais gadījums ir bīstams, jo ir diezgan grūti ietekmēt DBVS ražotāju, un klientam nepatīk saites uz DBVS tehniskā atbalsta dienestu. Neveiksmes problēmas risināšana DBMS nebūs jāizveido ražotājs, bet mainīt shēmu, samazināt pieprasījumu plūsmu, mainīt pašus pieprasījumus; Kopumā ir daudz iespēju. Nu, ja datu bāzes atgūšanas laiks iekļaujas plānotajā projekta laikā.

Sistēmas izeja uz projektēšanas jaudu, kad Labs konkrēts apstāklis \u200b\u200bir vairāku mazu kļūdu un reizēm - nopietnu kļūdu korekcija.

GOST 24.208-80 Prasības dokumentu saturam "nodošana ekspluatācijā"

PSRS Valsts komitejas rezolūcija par 14. maija standartiem Nr. 2101 Ievads

no 01.01 1981

Šis standarts attiecas uz visu veidu kontroles sistēmām (ACS), kas izstrādātas visiem kontroles līmeņiem (izņemot valsts), un nosaka prasības attiecībā uz dokumentu saturu, kas izstrādāti "ekspluatācijā" stadijā saskaņā ar prasībām GOST 24,101-80

1. Vispārīgi noteikumi

1.1. Pasūtīšanas posmā izstrādātie dokumenti tiek saukti par ACS pieņemšanas dokumentiem.

1.2. Izstrādājot dokumentus ACS daļai, dokumentu saturs attiecas tikai uz atbilstīgo ACS daļu.

1.3. Atkarībā no izstrādāto ACS mērķa un specifiku dokumentos ir atļauts iekļaut papildu informāciju, kuru prasības attiecībā uz saturu nav noteikta ar šo standartu.

2. Prasības pieņemšanas dokumentācijai

2.1. Darba pabeigšanas akts

2.1.1. Dokuments ir paredzēts, lai noteiktu faktu, kad izveidojat ACS, izveidojot ACS.

2.1.2. Dokuments neattiecas uz būvniecību un nodošanu ekspluatācijā un nodošanu ekspluatācijā.

2.1.3. Dokumentā jābūt:

  • pabeigtā darba nosaukums (darbi);
  • organizācijas izstrādātāja pārstāvju saraksts un organizācijas-klients, kas ir apkopojusi aktus;
  • darba pabeigšanas datums;
  • dokumenta nosaukums (-i), pamatojoties uz kuru darbs tika veikts;
  • pabeigtā darba galvenie rezultāti;
  • secinājums par pabeigtā darba rezultātiem.

2.2. Pieņemšanas akts izmēģinājuma darbībā

2.2.1. Dokuments ir paredzēts, lai noteiktu ACS ieraksta kopšanas faktu izmēģinājuma darbībā.

2.2.2. Dokumentā jābūt:

  • aKS (vai tās daļas) nosaukums, kas pieņemts izmēģinājuma darbībā un attiecīgajā pārvaldības iestādē;
  • pieņemšanas komisijas sastāvs un tā darba pamats (nosaukums, numurs un dokumenta apstiprināšanas datums, pamatojoties uz kuru tika izveidota Komisija);
  • izmēģinājuma darbībā pieņemto ACS (vai tās daļas) funkciju sastāvs;
  • tehnisko, programmatūras, informācijas un organizatorisko noteikumu komponentu saraksts pieredzējušās operācijas procesā;
  • galvenie pieņemšanas rezultāti izmēģinājuma darbībā;
  • komisijas lēmums par ACS pieņemšanu izmēģinājuma darbībā.

2.3. Akts pieņemšana rūpnieciskajā darbībā

2.3.1. Dokumentā ir izstrādāts, lai noteiktu ACS (vai tās daļas) ievietošanu rūpnieciskajā darbībā.

2.3.2. Dokumentā jābūt:

  • kontroles objekta un ACS (vai tās daļu) nosaukums, kas pieņemts rūpnieciskajā darbībā;
  • informācija par statusu pieņemšanas komisijas (valsts, starpdepartal, departamenta), tās sastāvs un pamatojums tās darbam;
  • komisijas darba laiks;
  • organizācijas izstrādātāja, organizācijas un klientu organizāciju nosaukums;
  • dokumenta nosaukums, pamatojoties uz kuru tika izstrādāts ACC;
  • rūpnieciskajā darbībā pieņemto ACS (vai tās daļas) funkciju sastāvs;
  • rūpnieciskajā darbībā pieņemto tehnisko, programmatūras, informācijas un organizatorisko atbalsta komponentu saraksts;
  • komisijas noteikto dokumentu saraksts;
  • secinājums par ACS eksperimentālās darbības rezultātiem;
  • novērtējums par atbilstību ACU tehniskajam uzdevumam tās izveidei;
  • Īsas īpašības un galvenie rezultāti, kas veikti, izveidojot ACS;
  • novērtējot ACS zinātnisko un tehnisko līmeni (saskaņā ar projekta datiem) *;
  • ekonomiskās efektivitātes novērtējums no ACS īstenošanas (saskaņā ar projekta datiem) *;
  • komisijas lēmums;
  • komisijas ieteikumi sistēmas turpmākai attīstībai *.
* Obligāti tikai tad, ja pieņemot ACS kopumā.

2.3.3. "Rūpniecības ekspluatācijas akts" veic programmu un protokolus testus, Komisijas sanāksmju protokoli, aktu pieņemšanas rūpnieciskajā darbībā ACS agrāk pieņemto ACS, sarakstu ar tehnisko līdzekļu, kas izmantoja Komisiju par ACS pieņemšanu. Pēc Komisijas ieskatiem pieteikumā ir atļauts iekļaut papildu dokumentus.

2.4. Plāna grafiks

2.4.1. Dokumentā izveido darbu sarakstu, īstenošanas un darba izpildītāju laiku, kas saistīts ar darba izveidi.

2.4.2. Dokumentā par katru sarakstā iekļauto darbu jābūt:

  • darba nosaukums;
  • sākuma un beigu datums;
  • darba partnera nosaukums;
  • atbildīgās izpildītāja uzvārds un amats;
  • darba rezultātu formulu.

2.5. Darba kārtība

2.5.1. Atkarībā no darba stadijas par ACS izveidi, ir izveidotas šādas dokumenta šķirnes:

  • rīkojums par pārvaldības mehānisma gatavību būvniecības un uzstādīšanas darbu veikšanai;
  • rīkojums par pārvaldības mehānisma gatavību veikt korekciju;
  • rīkojums sākumā pieredzējušās darbības ACS (tās daļas);
  • rūpnieciskās ekspluatācijas rīkojums (tās daļas).

2.5.2. Dokumentu "pasūtījums par gatavību pārvaldības mehānismu, lai veiktu būvniecības un uzstādīšanas darbu" ir jāietver:

  • ziņu par vadības mehānisma gatavību būvniecības un uzstādīšanas darbu veikšanai;
  • būvniecības zonas un uzstādīšanas noteikšana;
  • procedūra uzņemšanai darbā;
  • klienta organizācijas pārstāvju saraksts, kas atbild par darbu veikšanu un uzstādīto iekārtu drošību;
  • atbildīgo būvniecības un uzstādīšanas organizāciju pārstāvju saraksts, kas ražo darbu.

2.5.3. Dokumentā "Rīkojums par vadības mehānisma gatavību nodot: \\ t

  • ziņu par vadības mehānisma gatavību veikt korekciju;
  • tehnisko līdzekļu saraksts ir jāpielāgo;
  • norāde par ierīces veikšanas kārtību;
  • procedūra uzņemšanai uzstādīšanas darbā;
  • klienta organizācijas pārstāvju saraksts, kas atbild par nodošanu ekspluatācijā;
  • atbildīgo organizāciju pārstāvju saraksts, kas veic ekspluatācijā;
  • norādījumi par uzstādīšanas kļūdu novēršanas kārtību un personām, kas atbildīgas par šo darbu veikšanu.

2.5.4. Dokumentā "Rīkojums sākumā pieredzējušās darbības ACS (tās daļas)" jāietver:

  • aKS nosaukumu kopumā vai tās daļas, kas iet ar pieredzējušu darbību;
  • pieredzējušās operācijas termiņi;
  • klientu organizācijas ierēdņu saraksts un izstrādātāja organizācija, kas atbild par pieredzējušu operācijas veikšanu;
  • klientu organizāciju saraksts, kas iesaistītas pieredzējušā ekspluatācijā.

2.5.5. Dokumentu "uzņēmuma rīkojums ACS rūpnieciskajā darbībā (tās daļas)" jāietver:

  • aKS vai to daļu funkciju sastāvs, tehniskie un programmatūras rīki, kas uzņemti rūpnieciskajā darbībā;
  • ierēdņu saraksts un klienta organizācijas nodaļu saraksts, kas atbild par ACS darbu;
  • procedūru un termiņus ieviešot jaunus dokumentus (ja nepieciešams);
  • tulkošanas procedūra un termiņi, kas uzsākti ACS darbībā.

2.6. Pasūtījums par pieņemšanas komisijas sastāvu

Dokumentā jābūt:

  • saņemto ACS nosaukumu kopumā vai tās daļās;
  • informācija par Komisijas sastāvu;
  • komisijas organizācijas pamatojums;
  • klienta organizācijas nosaukums;
  • organizācijas attīstītāja nosaukums, co-vārstu organizēšana;
  • komisijas iecelšana un mērķi;
  • komisijas darba sākuma un pabeigšanas termiņi;
  • norādījumi par Komisijas pabeigšanas formu.

2.7. Darba programma

2.7.1. Atkarībā no darba uzturēšanas ir uzstādīti šādi dokumentu veidi:

  • testa programma;
  • pieredzējušās darbības programma;
  • pieņemšanas komisijas darba programma.

2.7.2. Dokumentā "Testa programma" ir paredzēta, lai noteiktu procedūru, lai veiktu iepriekšējus testus, nosūtot un pieņemot testēšanu, nododot rūpnieciskās darbības ACS.

Dokumentā jābūt:

  • aKS funkciju sastāvs kopumā vai tās daļas, uz kurām attiecas testi, atsaucoties uz tehniskā uzdevuma priekšmetiem par ACS izveidi;
  • tehnisko, programmatūras, informācijas un organizatorisko atbalsta sastāvdaļu saraksts, uz kuriem attiecas testi;
  • procedūra, lai pārbaudītu atsevišķas sastāvdaļas ACS un atsevišķu ACS funkcijas;
  • testēšanas noteikumi un laiks;
  • testu reģistrēšanas procedūra un konstatētie trūkumi;
  • trūkumu novēršanas procedūra un nepieciešamās izmaiņas tehniskajā dokumentācijā;
  • norādot testa rezultātu formu.

2.7.2. "Eksperimentālās darbības programma" ir paredzēta, lai noteiktu kārtību un izmēģinājuma darbības apjomu.

Dokumentā jābūt:

  • aKS un tā detaļu funkciju sastāvs, atsaucoties uz tehnisko uzdevumu, lai izveidotu ACS;
  • tehnisko, programmatūras, informācijas un organizatorisko noteikumu komponentu saraksts;
  • procedūra personāla darbībām eksperimentālā darbībā elementu ACS un individuālās funkcionālās apakšsistēmas;
  • izmēģinājuma darbības nosacījumi un termiņi;
  • procedūra, lai reģistrētu izmēģinājuma darbības rezultātus un konstatētos trūkumus;
  • noteikto trūkumu novēršanas procedūru un tehniskās dokumentācijas izmaiņas;
  • norāde par eksperimentālās darbības rezultātu pārstāvības formu.

2.7.2. Dokumenta "Pieņemšanas komisijas darbu programma" ir paredzēta, lai noteiktu ACS pieņemšanas kārtību rūpnieciskajā darbībā. Dokumenta sastāvu un saturu nosaka šajā nozarē apstiprinātie regulatīvie un tehniskie dokumenti.

2.8. Testa ziņojums

2.8.1. Dokuments ir paredzēts, lai noteiktu provizorisko testu rezultātus, nosūtot ACS kopumā vai tās daļās eksperimentālajā vai rūpnieciskajā darbībā.

2.8.2. Dokumentā jābūt:

  • testa objekta nosaukums;
  • to ierēdņu saraksts, kas veicis testu;
  • testa mērķis;
  • informācija par testa ilgumu;
  • tehniskā uzdevuma sarakstu ACS izveidei, lai atbilstu testiem;
  • to preču "testa programma" saraksts, uz kura tika veikti testi;
  • informāciju par novērojumu rezultātiem par pareizu darbību ACS;
  • informācija par neveiksmēm, defektiem un ārkārtas situācijām, kas notika testēšanas laikā;
  • informācija par korekcijām uz parametriem testa objekta un tehnisko dokumentāciju.

2.9. Protokola koordinācija

2.9.1. Dokumentā ir paredzēts, lai saskaņotu novirzes no iepriekš pieņemtajiem un apstiprinātiem dizaina lēmumiem, kad eksperimentālās darbības procesā ACS kopumā vai tās daļas atklāja vajadzību pēc to korekcijas.

2.9.2. Dokumentā jābūt:

  • sarakstu ar diskrētām novirzēm ar norādi par dokumentu, novirzes no prasībām, kas ir koordinācijas priekšmeti;
  • ierēdņu saraksts, kas apkopoja protokolu;
  • pieņemto novirzes no dizaina risinājumiem;
  • saskaņoto novirzju sarakstu un termiņus, lai veiktu vajadzīgās izmaiņas tehniskajā dokumentācijā.

Atkārtoti izdrukājiet. 1986. gada maijs

Līdzīgi izstrādājumi