Techninė dokumentacija. Techninio projekto aiškinamasis raštas Techninės specifikacijos pavyzdžio aiškinamasis raštas

Pagrindinis Aiškinamojo rašto dokumento tikslas – pateikti bendrą informaciją apie sistemą ir jos kūrimo metu priimtų techninių sprendimų pagrindimą. Todėl aiškinamojo rašto rengimo pagrindas daugiausia bus techninės užduotys.

Aiškinamasis raštas yra vienas iš svarbiausių techninio projekto dokumentų. Techninis projektas rengiamas siekiant nustatyti galutinius techninius sprendimus, kurie suteikia pilną gaminio dizaino vaizdą.
Kuriant aiškinamojo rašto kūrimo programą, rekomenduojama naudoti GOST 19.404-79 „Aiškinamasis raštas. Reikalavimai turiniui ir dizainui“.

Norint sukurti techninio projekto aiškinamąjį raštą, aprašantį automatizuotą sistemą (AS), rekomenduojama naudoti standartą RD 50-34.698-90 „Automatizuotos sistemos. Reikalavimai dokumentų turiniui“.

Daugelis aukščiau pateiktų dokumentų skirsnių sutampa, todėl kaip pavyzdį nagrinėsime dokumentą Aiškinamoji pastaba, sukurta remiantis RD 50-34.698-90

1. Bendrosios nuostatos

1.1 Suprojektuoto garsiakalbio pavadinimas

Šiame aiškinamosios pastabos dokumento skyriuje pateikiamas visas ir trumpasis AS pavadinimas.

Pavyzdžiui: „Šiame dokumente kuriama sistema vadinama Įmonės informacijos portalu. Taip pat leidžiama naudoti sutrumpintą pavadinimą „KIP“ arba „Sistema“.

1.2 Dokumentai, kurių pagrindu sukurta sistema

Šiame aiškinamojo rašto dokumento skyriuje turi būti nurodytos nuorodos į automatizuotos sistemos kūrimo sutartį ir techninę užduotį.

1.3 Organizacijos, dalyvaujančios sistemos kūrime

Šioje aiškinamosios pastabos dokumento dalyje nurodyti klientų ir kūrėjų organizacijų pavadinimai.

1.4 AS plėtros tikslai

Šiame Aiškinamojo rašto dokumento skyriuje turėtų būti nurodyta techninė, ekonominė ir gamybinė nauda, ​​kurią klientas gaus įdiegęs sukurtą sistemą.

Pavyzdžiui: „Kuriamos sistemos tikslas yra:

• įmonės dokumentų srauto optimizavimas;
• įmonės verslo kultūros palaikymas;
• komunikacijos tarp įmonės darbuotojų optimizavimas. »

1.5 Sukurtos garsiakalbių sistemos paskirtis ir naudojimo sritis

Šioje aiškinamojo rašto dokumento dalyje turi būti aprašytas automatizuojamos veiklos tipas ir sąrašas procesų, kuriuos sistema ketina automatizuoti.

Pvz.: „KIP skirtas suteikti išsamią ir savalaikę informaciją bei efektyviai organizuoti darbuotojų darbą. Sistema turėtų užtikrinti bendro darbuotojų darbo organizavimą naudojant šias galimybes:

• Konferencijų problemoms aptarti kūrimas;
• Elektroninio pašto pranešimų siuntimas/gavimas;
• Bendradarbiavimo rengiant dokumentus užtikrinimas;
• Dokumentų derinimas;
• Tvarkyti gaunamų ir išsiunčiamų dokumentų įrašus.

1.6 Informacija apie projektuojant naudotus norminius ir techninius dokumentus

Šiame skyriuje turėtų būti nurodyti standartai, kurie buvo naudojami kuriant aiškinamosios pastabos dokumentą.

Pavyzdžiui: „Projektuojant buvo naudojami šie norminiai ir techniniai dokumentai:

• GOST 34.201-89 „Informacinės technologijos. Automatizuotų sistemų standartų rinkinys. Kuriant automatizuotas sistemas dokumentų tipai, išsamumas ir žymėjimai“;
• GOST 34.602-89 „Informacinės technologijos. Automatizuotų sistemų standartų rinkinys. Automatizuotos sistemos sukūrimo techninės specifikacijos“;
• GOST 34.003-90 „Informacinės technologijos. Automatizuotų sistemų standartų rinkinys. Automatizuotos sistemos. Terminai ir apibrėžimai“;
• GOST 34.601-90 „Informacinės technologijos. Automatizuotų sistemų standartų rinkinys. Automatizuotos sistemos. Kūrybos etapai“;
• RD 50-682-89 „Metodiniai nurodymai. Informacinės technologijos. Automatizuotų sistemų standartų ir gairių rinkinys. Bendrosios nuostatos";
• RD 50-680-88 „Metodiniai nurodymai. Automatizuotos sistemos. Pagrindinės nuostatos“;
• RD 50-34.698-90 „Metodiniai nurodymai. Informacinės technologijos. Automatizuotų sistemų standartų ir gairių rinkinys. Automatizuotos sistemos. Reikalavimai dokumentų turiniui“.

1.7. Sistemos kūrimo seka

Sistemoms, sukurtoms keliomis iteracijomis, aiškinamajame rašte turėtų būti nurodyta kiekvienos iteracijos darbo apimtis. Atskirai būtina pabrėžti šios iteracijos suplanuotus darbus.

Pavyzdžiui: „Įmonių informacijos portalo projekto įgyvendinimas planuojamas dviem etapais.

Pirmasis instrumentavimo etapas apima bendro įmonės darbuotojų darbo organizavimą dėl tokių galimybių kaip:

• Momentiniai pranešimai;
• Konferencijos organizavimas;
• El. laiškų siuntimas/gavimas;
• Dokumentų derinimas naudojant Sistemą.

2 Veiklos proceso aprašymas

Šioje aiškinamosios pastabos dokumento dalyje turėtų būti atspindėti procesai ir funkcijos, automatizuotos sistemos visame verslo procese.

Aiškinamajame rašte pateiktai medžiagai iliustruoti leidžiama naudoti UML, ARIS ar IDF0 žymėjimus, taip pat schematinius vaizdus, ​​sukurtus naudojant standartines programas (Visio).

Norint suprasti ryšį tarp automatizuotų ir neautomatizuotų funkcijų aiškinamosios pastabos dokumente, būtina aiškiai atskirti vartotojo veiksmus ir sistemos veiksmus.

Pavyzdžiui: „1. Vartotojas sukuria dokumentą

• Vartotojas inicijuoja dokumento pateikimo tvirtinti procesą
• Sistema pakeičia dokumento būseną į „patvirtinti“. »
• Pagrindiniai techniniai sprendimai

2.1. Sprendimai dėl sistemos ir posistemių struktūros.

Šiame dokumento skyriuje Aiškinamoji pastaba pateikiami sistemos ir jos posistemių funkcinės struktūros sprendimai.

2.2. Sistemos komponentų sąveikos priemonės ir metodai. Sujungimas su išorinėmis sistemomis

Šiame Aiškinamosios pastabos dokumento skyriuje būtina nurodyti sistemų, su kuriomis turi sąveikauti sukurtas produktas, sąrašą. Aiškinamajame rašte aprašant sistemos komponentų sąveiką, būtina nurodyti duomenų mainų formatą.

Pavyzdžiui: „Kaip prietaisų ir išorinių sistemų sąveikos dalis, naudojamos šios technologijos:
- „Įmonės apskaita“ - failų keitimas nustatytu XML / Excel formatu.

2.3. Sprendimai dėl darbo režimų

Šiame aiškinamojo dokumento skyriuje pateikiamas sistemos veikimo režimų sąrašas ir aprašymas. Paprastai išskiriami šie režimai: normalus režimas, bandomasis veikimo režimas, aptarnavimo režimas. Aiškinamajame rašte turi būti aprašytas ir pats režimas, ir jo įvedimo atvejai.

2.4. Sprendimai dėl AE personalo skaičiaus, kvalifikacijos ir funkcijų

Šis dokumento Aiškinamojo rašto skyrius reglamentuoja techninės priežiūros ir funkcinio personalo veiklą. Aiškinamajame rašte turi būti nurodyta darbuotojų kategorija, kuri priklauso tam tikram personalo tipui, ir aprašytos jų funkcijos sistemoje.

Pavyzdžiui: „Portalo administratorius yra atsakingas už:

• duomenų bazės ir programinės įrangos vientisumas;
• prevencinės priemonės duomenų saugumui užtikrinti;
• prieigos teisių paskirstymas ir vartotojų registravimas sistemoje. »

2.5. Techninėse specifikacijose nurodytų sistemos vartotojų savybių užtikrinimas

Šis Aiškinamojo rašto dokumento skyrius yra sukurtas remiantis techninėse specifikacijose nurodytais gaminio kokybės reikalavimais. Čia būtina aprašyti parametrą, pagal kurį nustatoma sistemos kokybė. Aiškinamajame rašte taip pat nurodomi sprendimai, kuriais ši charakteristika buvo pasiekta sistemoje.

Pavyzdžiui: „Instrumentų programinės įrangos modulių atsparumas gedimams ir veikimas užtikrinamas naudojant pramoninės programinės įrangos platformas IBM WebSphere Portal, Enterprise Oracle 10g“.

2.6. Sistemos įgyvendinamų funkcijų ir užduočių rinkinio sudėtis

Šiame aiškinamojo dokumento skyriuje pateikiamas užduočių, kurias sprendžia sistema, sąrašas. Aiškinamajame rašte funkcijos ir užduočių rinkinys gali būti pateikiami nenumeruoto sąrašo forma.

2.7. Sprendimai dėl techninės įrangos komplekto ir jo išdėstymo aikštelėje

Šiame Aiškinamojo rašto dokumento skyriuje pateikiami sprendimai dėl techninės sistemos architektūros ir reikalavimai techninių priemonių rinkiniui, būtinu jos tinkamam veikimui užtikrinti.

Reikalavimus techninių priemonių rinkiniui rekomenduojama pateikti aiškinamajame rašte lentelės pavidalu.
Pavyzdžiui: "

Įranga	Techninės specifikacijos
Duomenų bazės serveris
Versija su stovu	Ne daugiau kaip 4U
Procesoriaus architektūra	RISC (64 bitų)
CPU dažnis	ne mažiau kaip 1,5 GHz
CPU talpykla	Mažiausiai 1 MB
OS	Windows 2003 SP2
Galimas įdiegtų procesorių skaičius	Bent 4
Įdiegtų procesorių skaičius
Galima RAM talpa	32 GB su ECC
RAM talpa	Mažiausiai 8 GB
Sąsajų prieinamumas	10/100/1000 Base-T Ethernet sąsajos 2 vnt.; Ultra320 SCSI 2 vnt.; USB 4 vnt.; nuoseklioji sąsaja 1 vnt.; PCI 64 bitų išplėtimo lizdai 6 vnt.
Vaizdo plokštė:	Mažiausiai 8 MB.
Galimas įdiegtų standžiųjų diskų skaičius	Bent 4
Įdiegtų diskų skaičius
Skaitytojas
Maitinimas	Įvesties parametrai: 200-240 V, srovės dažnis: 50-60 Hz; maksimali įėjimo galia ne didesnė kaip 1600 W; mažiausiai 2 maitinimo šaltiniai, užtikrinantys atsparumą gedimams.

»

Apibūdinant techninių priemonių komplekso objektų išdėstymą aiškinamajame rašte, būtina vadovautis SNiP 11-2-80 reikalavimais „B“ kategorijos pastatams.

2.8. Apimtis, sudėtis, organizavimo būdai, informacijos apdorojimo seka

Informacijos palaikymas apima įrenginio ir papildomos įrangos informacijos palaikymą. Vidinę informacijos palaikymą teikia duomenų bazė (DB), įvesties ir išvesties dokumentai, gaunami iš išorinių sistemų.

Ne mašinos informacinę bazę sudaro popieriniuose dokumentuose esantys duomenys. Dažnai kuriant automatizuotas sistemas naudojama tik in-machine informacinė bazė, todėl pagrindinis akcentas aiškinamajame dokumente turėtų būti skiriamas šios dalies turiniui.

Aiškinamajame dokumente aprašant vidinę informacijos bazę, būtina nurodyti visų posistemių ir išorinių sistemų įvesties ir išvesties dokumentus bei pranešimus.

Pavyzdžiui: „Elektroninio dokumentų valdymo posistemio įvesties informacija yra:

• elektroninės gamybos darbo eigos dokumentų versijos;
• elektroninis skaitmeninis parašas;

Elektroninio dokumentų valdymo posistemio išvesties informacija yra:

• dokumento gyvavimo ciklo istorijos žurnalas;
• dokumentų tvirtinimo istorijos žurnalas;
• dokumento elektroninės versijos failas RTF formatu. »

2.9. Programinės įrangos produktų sudėtis, darbo kalbos, procedūrų ir operacijų algoritmai bei jų įgyvendinimo būdai

Šiame aiškinamojo dokumento skyriuje turi būti pateiktos sistemos kūrimo technologijos ir priemonės.

Pavyzdžiui:
«

• Duomenų bazės serveris: Oracle 10g
• Portalas: Websphere Portal Extend v6.0.
• Verslo modeliavimas: ARIS

»

3 Automatikos objekto paruošimo sistemos paleidimui priemonės

Šiame aiškinamojo dokumento skyriuje aprašomos šios veiklos rūšys:

• priemonės, kad informacija būtų tinkama kompiuteriniam apdorojimui;
• personalo mokymo ir kvalifikacijos tikrinimo veikla;
• priemonės reikalingiems padaliniams ir darbo vietoms sukurti;
• automatikos objekto keitimo priemonės;
• kita veikla, pagrįsta specifinėmis kuriamų sistemų savybėmis

27.10.2016 09:57:23

Šiame straipsnyje aptariamas techninio projekto etapas, susijęs su vienu iš informacijos apsaugos sistemos (ISS) gyvavimo ciklo etapų - „projektavimo“ etapu, kuris pagal vidaus standartą GOST 34.601-90 iš karto seka sukūrus informacijos apsaugos sistemos techninės užduotys.

1. NIB techninio projekto dokumentacijos rengimas

Informacijos saugumo sistemos (toliau – ISS) gyvavimo ciklas apskritai susideda iš šių etapų:

• informacijos saugumo sistemų reikalavimų analizė;
• dizainas;
• įgyvendinimas;
• įgyvendinimas;
• išnaudojimą.

Šiame straipsnyje aptariamas techninio projekto etapas, priklausantis „projektavimo“ etapui ir, remiantis vidaus standartu GOST 34.601-90, iš karto po informacijos saugos sistemos techninės užduoties rengimo.

1.1. Kam iš viso kurti NIB dokumentus?

Atsakymą į šį klausimą reikėtų nagrinėti dviem plotmėmis: informacinių išteklių savininko (kurių apsaugai sukurta informacijos apsaugos sistema) ir tiesioginio informacijos saugos sistemos kūrėjo plotmėje.

Informacinių išteklių savininkui svarbu gauti rezultatą kaip veikiančią informacijos saugumo sistemą, kuri sumažina riziką pakenkti ribotos prieigos informacijai organizacijoje. Techninis projektas šiuo atveju yra skirtas esminiams būsimos sistemos principams sukurti, būtent, jame aprašoma, kaip bus kuriama ir veiks TKS, kokiomis priemonėmis ir priemonėmis bus užtikrinta informacijos apsauga, kokios yra galimybės ją plėtoti ir tobulinti. sistema. Pabaigus informacinės apsaugos sistemos techninio projekto rengimą, Klientas gauna išsamų informacijos apsaugos sistemos dokumentacijos rinkinį, aprašantį visus būsimos sistemos techninius niuansus.

Tiesioginiam vykdytojui techninio projekto etape būtina nustatyti tinkamiausią ISS architektūrą, taip pat tinkamai pasirinkti priemones ir priemones informacijos apsaugai organizacijoje. Taip pat svarbu užtikrinti, kad sistemos charakteristikos ir savybės atitiktų technines specifikacijas, arba, Klientui dalyvaujant ir sutikus, pagrįsti techninėse specifikacijose nurodytų reikalavimų koregavimą, siekiant padidinti sistemos efektyvumą. kuriama sistema.

Taigi, rengiant techninę projekto dokumentaciją, Klientas turės atsakymus į šiuos klausimus:

• kokia yra bendra NIB architektūra;
• kokios priemonės ir priemonės bus naudojamos informacijos apsaugos reikalavimams įgyvendinti;
• kaip veiks NIB;
• kokie organizacijos pokyčiai, būtini informacijos saugumo lygiui didinti, įvyks įgyvendinus TKS;
• ar kuriant ir diegiant informacijos saugos sistemą bus atsižvelgta į Užsakovo reikalavimus (verslo reikalavimus) ir norminių teisės aktų reikalavimus informacijos saugumo srityje ir, jei taip, kaip.

Rengiant techninio projekto dokumentaciją, rangovas gaus šiuos rezultatus:

• pagrindas pereiti prie kitų ISS kūrimo etapų, ty darbo dokumentacijos ir įgyvendinimo etapų;
• architektūros, naudojamų technologijų ir priemonių supratimas, sistemos kūrimo tvarka;
• kaip sistemai įgyvendinti Kliento reikalavimai (verslo reikalavimai) ir norminiai dokumentai informacijos saugumo srityje.

1.2. Techninio projekto dokumentacijos rengimo metodų apžvalga

Informacijos saugos sistemos techninio projekto rengimas dažniausiai atliekamas remiantis atitinkamais standartais ir rekomendaciniais dokumentais. Be to, juos naudoti privaloma valstybinėms institucijoms, tačiau rekomenduojama komercinėms institucijoms. Praktiškai komercinės organizacijos taip pat naudoja valstybinius standartus rengdamos techninio projekto dokumentaciją dėl šių priežasčių:

• ne kartą išbandytas požiūris į informacinių sistemų kūrimą;
• apgalvota dokumentų struktūra ir turinys;
• dokumentų rinkinys, pakankamas beveik bet kuriai sistemai sukurti ir aprašyti.

Kuriant NIB techninio projekto (TP) etapo dokumentus, naudojami 34 serijos valstybiniai standartai ir rekomendaciniai dokumentai:

• GOST 34.201-89 „Dokumentų tipai, išsamumas ir žymėjimas kuriant automatizuotas sistemas“. Šis standartas nurodo:
  • TP stadijos dokumentų rūšys ir pavadinimai;
  • dokumentacijos išsamumas;
  • priimtus dokumentų pavadinimus;
  • NIB ir jų dalių skyrimo taisyklės.
• GOST 34.003-90 „Terminos ir apibrėžimai“;
• GOST 34.601-90 „Automatinės sistemos. Kūrybos etapai“. Standartas nurodo:
  • techniniame etape atliktų darbų etapų sąrašas;
  • išsamus techniniame etape atliktų darbų aprašymas;
  • organizacijų, dalyvaujančių kuriant TKS, sąrašas;
• RD 50-34.698-90 „Automatizuotos sistemos. Reikalavimai dokumentų turiniui“. Šiame rekomendaciniame dokumente nurodomi reikalavimai dokumentų turiniui TP etape.

Svarbu suprasti, kad pagal 34 standartų serijas techninis projektavimas yra sistemos kūrimo etapas, o ne tik dokumentų rinkinys. Praktikoje šis etapas dažnai derinamas su preliminariu projektavimo etapu, kurio metu parengiami keli preliminarūs sprendiniai ir pagrindžiamas tinkamiausias. Toks derinys leidžiamas pagal standartą, tačiau reikia atsižvelgti į tai, kad tai nepaneigia būtinybės pasiekti preliminaraus projektavimo etapo tikslus.

Dažniausiai preliminarus projektavimo etapas rengiamas tuo atveju, kai sistemos techninių specifikacijų reikalavimus galima įgyvendinti keliais iš esmės skirtingais būdais, taip pat kai tarp šių būdų nėra aiškiai pageidaujamų.

Tačiau verta paminėti, kad aukščiau pateikti standartai yra pernelyg bendri ir daugiausia įgyvendina projektavimo ir bendrąsias konstrukcines funkcijas. Kurdami esminę techninio projekto etapo dokumentų dalį, projektuotojai naudoja informaciją iš šių šaltinių:

Galiojantys norminiai dokumentai (RLA), reglamentuojantys tam tikros ribotos prieigos informacijos apsaugos reikalavimus. Šiuose nuostatuose pateikiami reikalavimai informacinių sistemų informacijos apsaugos priemonėms, aprašomi šių priemonių įgyvendinimo niuansai ir papildomos stiprinimo priemonės. Tarp galiojančių teisės aktų yra šie:

• 2013 m. vasario 18 d. Rusijos FSTEC įsakymas Nr. 21 „Dėl organizacinių ir techninių priemonių, užtikrinančių asmens duomenų saugumą juos tvarkant asmens duomenų informacinėse sistemose, sudėties ir turinio patvirtinimo“;
• 2013 m. vasario 11 d. Rusijos FSTEC įsakymas Nr. 17 „Dėl informacijos, kuri nesudaro valstybės paslapties, apsaugos valstybės informacinėse sistemose reikalavimų patvirtinimo“
• Rusijos FSTEC 2014 m. kovo 14 d. įsakymas Nr. 31 „Dėl informacijos saugumo užtikrinimo automatizuotose gamybos ir technologinių procesų valdymo sistemose reikalavimų kritiniuose objektuose, potencialiai pavojinguose objektuose, taip pat objektuose, kurie kelia padidintą pavojų žmonių gyvybei ir sveikatai bei gamtinei aplinkai;
• metodinis dokumentas „Informacijos apsaugos valstybės informacinėse sistemose priemonės“, patvirtintas Rusijos FSTEC 2014 m. vasario 11 d.

Ribotos prieigos informacijos apsaugos reikalavimai ir apsaugos priemonių sąrašai skiriasi skirtingų saugumo lygių/klasių informacinėms sistemoms. Jei informacija organizacijoje nėra apsaugota pagal Rusijos Federacijos federalinius įstatymus (pavyzdžiui, tarnybos paslaptys), tada šios informacijos savininkas gali naudoti šiuose norminiuose teisės aktuose siūlomus metodus įmonės informacijos saugos sistemai kurti. .

Rusijos ir užsienio standartai, apibūdinantys įvairius metodus, kaip įgyvendinti ISS statybos gyvavimo ciklo etapus, įskaitant techninio projektavimo etapą:

• valstybinių standartų serija GOST R ISO/IEC 2700X, identiška tarptautiniams standartams ISO/IEC 2700X. Šie standartai apibūdina PDCA (Plan, Do, Check, Act) procesų požiūrį į informacijos saugumo valdymo sistemos gyvavimo ciklo įgyvendinimą, kuri yra neatsiejama informacijos saugos sistemos dalis;
• NIST SP 800-64 yra JAV nacionalinio standartų ir technologijų instituto standartas, aprašantis informacinių sistemų kūrimo gyvavimo ciklą;
• NIST SP 800-37 yra JAV nacionalinio standartų ir technologijų instituto standartas, kuriame pateikiamos gairės, kaip integruoti rizikos valdymą į informacinių sistemų kūrimo gyvavimo ciklą.

Informacijos apsaugos įrangos ir pagalbinės įrangos gamintojo eksploatacinė dokumentacija. Šiuose dokumentuose pateikiama išsami techninė informacija apie informacijos saugos sistemų kūrimo įrankius, įskaitant tuos, kurie tiesiogiai susiję su informacijos saugumo priemonių įgyvendinimu, nesusijusių, pavyzdžiui, su serveriais, duomenų saugojimo sistemomis, virtualizacijos įrankiais ir kt. Bendras tokių dokumentų rinkinys skiriasi priklausomai nuo gamintojo ir, be kita ko, priklauso nuo konkretaus įrankio (techninės/programinės įrangos) įdiegimo. Žemiau pateikiamas standartinis informacijos saugos įrankių, naudojamų dokumentams rengti techninio projekto etape, operatyvinės dokumentacijos rinkinys:

• bendras aprašymas (duomenų lapas);
• administratoriaus vadovas (gali būti vietinio ir centralizuoto valdymo vadovas);
• naudotojo gidas;
• Greito diegimo ir diegimo vadovas (aparatinės įrangos informacijos apsaugos sistemoms);
• operatoriaus vadovas;
• Diegimo virtualioje infrastruktūroje gairės (programinės įrangos informacijos saugos sistemoms);

Bendra informacija apie turimas ISS architektūras, geriausia praktika kuriant ISS, informacijos saugumo sistemų saugumo ir integravimo gairės, informacija apie tam tikrų informacijos saugumo sistemų sąveikos problemas. Tokios informacijos pavyzdžiai gali būti šie dokumentai:

• informacijos saugumo sistemų architektūrų vadovai, pavyzdžiui: Defence-in-Depth, Cisco SAFE, Check Point SDP ir kt.;
• geriausios praktikos informacijos saugumo srityje, pavyzdžiui, šiose nuorodose (https://www.sans.org/reading-room/whitepapers/bestprac/, http://csrc.nist.gov/publications/nistpubs/ 800-14 /800-14.pdf). Šie dokumentai dažniausiai pateikiami anglų kalba, tačiau bet kuris Rusijos apsaugos priemonių gamintojas turi savo geriausią saugumo priemonių įgyvendinimo praktiką ir gali jas pateikti paprašęs;
• saugos gairės informacijos saugumui ir veiklos aplinkoms. Pavyzdys yra skyrius „Sauga“ oficialiame „Microsoft“ portale (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. NIB techninio projekto rengimas pagal GOST 34

Dokumentų kūrimą ISS techninio projekto etape dažniausiai atlieka šių paslaugų integratoriai ir jie daugiausia vykdomi pagal šį planą:

Kurtinų dokumentų sąrašo nustatymas – ši informacija nurodyta techninėse TKS specifikacijose. Tam tikrais atvejais dokumento rengėjas, susitaręs su Užsakovu, gali išplėsti arba sumažinti šį sąrašą, jeigu tokia galimybė yra numatyta techninėse specifikacijose;

TP etapo dokumentų šablonų kūrimas - struktūra naudojama pagal RD 50-34.698-90 ir GOST 2.106 (kai kuriems dokumentams), suformatuota pagal GOST 2.105-95;

Dokumentų esminės dalies rengimas. Reikalavimai sistemai nustatyti NIB techninėse specifikacijose. Pagal šiuos reikalavimus nustatomas apsaugos techninių ir organizacinių priemonių, reikalingų diegti sistemoje, sąrašas. Apsaugos priemonės gali būti nustatytos atitinkamuose reglamentuose (priklausomai nuo saugomos informacijos tipo), įmonės standartuose ir informacijos saugumo politikoje, taip pat remiantis esamomis saugumo grėsmėmis, nustatytomis kuriant organizacijos grėsmių modelį. IS kūrėjas, remdamasis apsaugos priemonių sąrašu, parenka tinkamus informacijos saugos įrankius ir sukuria informacijos saugos sistemos funkcinę struktūrą (posistemes, komponentus). Toliau techninio projekto dokumentuose aprašomas apsaugos priemonių, pagrįstų pasirinktomis apsaugos ar organizacinėmis priemonėmis, praktinis įgyvendinimas organizacijos infrastruktūroje.

Sukurtos dokumentacijos ir joje pateiktų sprendimų derinimas su sistemos užsakovu.

Rengiant techninio projekto dokumentaciją, dažniausiai nebūtina sudaryti viso GOST 34.201-89 nurodytų dokumentų sąrašo, nes šis standartas yra pasenęs, o kai kuriuose dokumentuose neatsižvelgiama į šiuolaikinių informacinių sistemų plėtros tendencijas ir technologijas. . Minimalus dokumentų rinkinys, reikalingas informacijos apsaugos sistemai apibūdinti, yra toks:

• techninio projekto pareiškimas;
• techninio projekto aiškinamasis raštas;
• funkcinės struktūros diagrama;
• techninių priemonių komplekso struktūrinė schema;
• organizacinės struktūros schema;
• įsigytų prekių sąrašas.

Kliento pageidavimu arba tuo atveju, kai ISS yra sudėtinga daugiakomponentė sistema, taip pat gali būti papildomai rengiami šie dokumentai:

• automatizavimo schema;
• automatizuotų funkcijų aprašymas;
• sistemos informacinio palaikymo aprašymas;
• techninių priemonių komplekso aprašymas;
• programinės įrangos aprašymas;
• organizacinės struktūros aprašymas.

Reikėtų pažymėti, kad GOST 34.201-89 leidžia išplėsti dokumentų asortimentą TP etape, tačiau praktiškai šių dokumentų yra daugiau nei pakankamai.

Techninio projekto lapas

Pavadinimas: TP.

Šis dokumentas skirtas aprašyti techninio projekto etape parengtų dokumentų sąrašą. Taip pat nurodomas kiekvieno parengto dokumento puslapių skaičius.

Techninio projekto aiškinamasis raštas

Pavadinimas: P2.

Šis dokumentas yra pagrindinis TP etapui ir apima TKS architektūros, techninių ir organizacinių priemonių, TKS funkcijų, programinės ir techninės įrangos sistemų ir kitų dalykų aprašymą. Pagal standartą jis susideda iš keturių pagrindinių skyrių:

• Bendrosios nuostatos;
• veiklos proceso aprašymas;
• pagrindiniai techniniai sprendimai;
• priemonės automatikos objektui paruošti sistemos paleidimui.

Funkcinės struktūros diagrama

Pavadinimas: C2.

Šiame dokumente aprašoma loginė ISS struktūra, būtent:

• loginės posistemės ir komponentai, įtraukti į ISS;
• posistemių ir komponentų pagalba įgyvendinamos funkcijos;
• informaciniai ryšiai tarp loginių SIS elementų ir pranešimų tipai apsikeitimo metu.

Techninių priemonių komplekso struktūrinė schema

Pavadinimas: C1.

Šiame dokumente aprašomi šie ISS elementai:

• techninės priemonės kaip loginių posistemių dalis ir informacijos apsaugos sistemų komponentai;
• ryšio kanalus ir mainus tarp techninių priemonių, nurodančių transportavimo protokolus.

Organizacinė diagrama

Pavadinimas: C0.

Šiame dokumente aprašoma organizacijos organizacinė struktūra ISS valdymo požiūriu, būtent:

• organizacijos, dalyvaujančios vykdant TKS, padaliniai ir atsakingi asmenys;
• atliekamos funkcijos ir ryšiai tarp skyrių ir atsakingų asmenų.

Pirktų prekių sąrašas

Pavadinimas: VP.

Šiame dokumente pateikiamas visos programinės ir techninės įrangos, taip pat licencijų, naudojamų kuriant informacijos apsaugos sistemą, sąrašas. Sukurta pagal GOST 2.106.

Pastaba.Čia taip pat verta paminėti, kad rekomendacinis dokumentas RD 50-34.698-90 leidžia pridėti bet kokį dokumentą TP etape (įtraukti skyrius ir informaciją, kuri skiriasi nuo siūlomos), sujungti skyrius, taip pat pašalinti. kai kurių atskirų skyrių. Sprendimus dėl to priima dokumentų rengėjas TP etape ir remiasi sukurto NIB ypatumais.

1.4. Dokumentacijos rengimo taisyklės

• struktūrinis atitikimas valstybiniams standartams;
• griežtas sistemos techninių specifikacijų reikalavimų laikymasis;
• dokumentų šablonų taikymas (vienodų stilių, žymėjimo, laukų ir kt. naudojimas);
• individualus požiūris ir tuo pat metu esamų pokyčių naudojimas pildant dokumentų skyrius.

Techninio projekto aiškinamasis raštas:

• dokumento kūrimas atliekamas Microsoft Word, baigus kurti, patogumo dėlei rekomenduojama konvertuoti dokumentą į PDF formatą;
• terminai ir santrumpos turi būti nuoseklūs visose dokumento dalyse;
• Rekomenduojama vengti akivaizdžių pasikartojimų ir nereikalingo dokumento ilgio didinimo;
• techniniai sprendimai turi būti aprašyti kuo išsamiau, nurodant:
  • architektūra ir naudojamos technologijos;
  • programinės ir techninės įrangos vietos organizacijos infrastruktūroje;
  • naudojamos informacijos saugos priemonės su jų charakteristikų aprašymu, įdiegtomis funkcijomis, informacija apie sertifikavimą;
  • pagrindiniai informacijos saugos priemonių nustatymai, susiję su apsaugos mechanizmais, adresais, maršrutais, sąveika su susijusiomis sistemomis ir įrankiais ir kt.;
  • valdikliai, prieigos prie jų būdai ir jų įrengimo vietos;
  • diagramos (struktūrinės, funkcinės, organizacinės):
    • kurti diagramas Microsoft Visio;
    • po kūrimo įterpkite diagramas į dokumentą naudodami dialogo langą „Įklijuoti specialųjį“ EMF formatu (Windows metafailas);
    • parengti atskiras sistemos, posistemių ir posistemių komponentų schemas;
    • padaryti diagramų dizainą vienodą, naudojant tuos pačius elementus, santrumpas, piktogramas, teksto stilius ir kt.

1.5. Ištekliai, padėsiantys kurti dokumentus

Internete yra didžiulis kiekis informacijos, kuri vienu ar kitu laipsniu gali padėti rengiant techninio projekto dokumentaciją. Pagrindiniai ištekliai pateikti toliau esančioje lentelėje.

Lentelė. SIS techninio projektavimo ištekliai

Ištekliaus tipas	Informacija	Išteklių pavyzdžiai
Federalinės vykdomosios valdžios institucijų interneto portalai	Norminiai dokumentai, metodinės rekomendacijos, registrai (įskaitant sertifikuotas informacijos saugos sistemas), duomenų bazės (įskaitant pažeidžiamumų ir grėsmių duomenų bazes)	fstec.ru clsz.fsb.ru minsvyaz.ru/ru/
Informacijos saugumo gamintojų, informacijos saugumo sprendimų platintojų internetiniai portalai	Informacijos saugumo sprendimų aprašymas, informacinės saugos operatyvinė dokumentacija, analitinė medžiaga ir straipsniai	securitycode.ru kaspersky.ru/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru
Specializuoti informacijos saugos ištekliai	Informacijos saugumo sprendimų palyginimas, apžvalginiai straipsniai apie informacijos saugos sprendimus, informacijos saugos sprendimų testai, išsami techninė informacija apie informacijos saugos technologijas	anti-malware.ru bis-expert.ru safe.cnews.ru securitylab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org

1.6. Techninio projekto etapo dokumentų pavyzdžiai

Norėdami suprasti dokumentacijos turiniui keliamus reikalavimus TP etape, žemiau pateikiami pagrindinių dokumentų (dokumentų skyrių) pildymo pavyzdžiai.

1.6.1. Techninio projekto aiškinamasis raštas

Aiškinamasis raštas yra gana didelės apimties dokumentas, todėl čia yra vieno iš SIS posistemių – saugumo analizės posistemio – skyriaus „Pagrindiniai techniniai sprendimai“ turinio pavyzdys.

ISS saugumo analizės posistemis

Posistemio struktūra ir sudėtis

Saugumo analizės posistemis (SAS) skirtas sistemingai stebėti personalo ir organizacijos serverių automatizuotų darbo vietų (AWS) saugos būseną. ESD pagrindas yra „Test“ programinės įrangos įrankis, kurį gamina Information Security LLC. SZI Test turi Rusijos federalinės techninės ir eksporto kontrolės tarnybos sertifikatą dėl atitikties techninėms informacijos saugumo specifikacijoms (TU) ir 4-am nedeklaruotų galimybių nebuvimo kontrolės lygiui.

ESD sudaro šie komponentai:

• Test Server valdymo serveris;
• Test Console valdymo pultas.

Posistemio komponentų aprašymas pateiktas toliau esančioje lentelėje.

Lentelė. ESD komponentai

Komponentas	apibūdinimas
Išbandyti serverio valdymo serverį	Teikia skenavimo užduočių valdymą, atlieka darbo vietos ir organizacijos serverių saugos būklės stebėjimo funkcijas. Nuskaitymo parametrus nustato informacijos saugos administratorius Test Server valdymo serveryje. Visa surinkta informacija apie nuskaitymo rezultatus saugoma „Test Server“ serverio saugykloje, pagrįsta „Microsoft SQL Server 2008“ duomenų bazių valdymo sistema.
Bandymo konsolė	Leidžia informacijos saugos administratoriui prisijungti prie testavimo serverio, peržiūrėti ir keisti jo konfigūraciją, kurti ir keisti nuskaitymo užduotis, peržiūrėti informaciją apie užduočių eigą ir jų vykdymo rezultatus. Valdymo konsolė įdiegta informacijos saugos administratoriaus darbo vietoje

Funkcijų suteikimas

ESD atlieka šias funkcijas:

• aktyvios organizacijos darbo vietų ir serverių apsaugos įgyvendinimas, stebint informacijos saugumo būklę;
• vidaus politikos ir tam tikrų saugumo standartų laikymosi stebėjimo procesų automatizavimas;
• audito ir saugumo kontrolės išlaidų mažinimas, būklės ataskaitų rengimas;
• išteklių inventorizavimo procesų automatizavimas, pažeidžiamumo valdymas, saugos politikos laikymosi stebėjimas ir pakeitimų kontrolė.

Sprendimas aparatinės ir programinės įrangos įrankių kompleksui

Naudotos ESD programinės ir techninės įrangos sąrašas pateiktas toliau esančioje lentelėje.

Lentelė. ESD programinė ir techninė įranga

ESD valdymo serveris

Techninės priemonės

Fizinis serveris, naudojamas kaip ESD valdymo serveris, turi atitikti jame įdiegtos programinės įrangos ir OS techninius reikalavimus, pateiktus žemiau esančioje lentelėje.

Lentelė. OS ir programinės įrangos reikalavimai ESD valdymo serveriui

Programinė įranga	Techniniai reikalavimai
	CPU	RAM, MB
Microsoft Windows Server 2008 R2	3000 MHz, 4 branduoliai	8192
Microsoft SQL Server 2008 R2
Testo serverio programinė įranga

Programinė įranga

Valdymo serverio OS

„Windows 2008 R2“ OS valdymo serveryje įdiegiama įprastu būdu iš įkrovos paskirstymo.

Valdymo serverio OS valdoma tiek lokaliai iš konsolės, tiek per KPP protokolą.

Valdymo serveris DBVS

„Microsoft SQL Server 2008 R2“ duomenų bazė įdiegiama naudojant vietinio administratoriaus teises, naudojant standartinį diegimo vedlį iš platinimo rinkinio, kurį pateikia produkto kūrėjas.

Testuoti serverio programinę įrangą

„Test Server“ programinė įranga įdiegiama valdymo serveryje naudojant standartinį diegimo vedlį.

Pradinė „Test Server“ programinės įrangos sąranka ir tolesnis valdymas įprastu režimu atliekamas naudojant „Test Console“ valdymo pultą, įdiegtą IS administratoriaus darbo vietoje.

IS administratoriaus darbo vieta

Techninės priemonės

Kaip platforma naudojama esama organizacijos skyriaus darbuotojo, atsakingo už informacijos saugumo užtikrinimą, darbo vieta, kurioje veikia Microsoft Windows šeimos operacinės sistemos.

Informacijos saugumo administratoriaus darbo vietos techninės priemonės turi turėti šias techninės įrangos konfigūracijos charakteristikas (bent jau rekomenduojama):

• CPU 2 GHz;
• RAM 4 GB;
• HDD 80GB.

Programinė įranga

Testavimo pulto programinė įranga

Informacijos saugos administratoriaus darbo stotis, kurioje įdiegta testavimo konsolės programinė įranga, turi veikti pagal vieną iš šių OS:

• Microsoft Windows 7, 32 ir 64 bitų;
• Microsoft Windows 8/8.1, 32 ir 64 bitų.

Be to, kad „Test Console“ valdymo pulto programinė įranga tinkamai veiktų, informacijos saugos administratoriaus darbo vietoje turi būti įdiegta „Microsoft .NET Framework“ 3.5 SP1 arba naujesnė versija, o naudojamos operacinės sistemos saugos parametrai turi leisti pasiekti „Test Server“.

„Test Console“ programinės įrangos diegimas ESD administratoriaus darbo vietoje atliekamas naudojant standartinį „Test Server“ programinės įrangos diegimo vedlį su pasirinkta parinktimi įdiegti „Test Console“ valdymo pultą ir kitus numatytuosius nustatymus.

Sąveika su gretimomis sistemomis

ESD atveju greta yra:

• ugniasienės posistemės įrankiai;
• Active Directory katalogų paslaugos;
• Organizacijos darbo vieta ir serveriai.

Norint užtikrinti tinklo sąveiką su gretimomis sistemomis ir tiesiogiai tarp pačių ESD komponentų, reikia organizuoti reikiamo tinklo srauto pralaidumą.

Kad būtų užtikrinta galimybė gauti Test Server skaitytuvo žinių bazės ir Test programinės įrangos modulių atnaujinimus, būtina suteikti prieigą prie „Information Security LLC“ įmonės žiniatinklio serverio update.com per prievadą 443/tcp.

Nuskaitant PenTest režimu, bandymo serverio skaitytuvo ir darbo vietos bei organizacijos serverių sąveika vykdoma per IP protokolą. Nuskaitant audito ir atitikties režimais, naudojami nuotolinio valdymo protokolai WMI, RPC ir kt. Norėdami nuskaityti pagrindinius kompiuterius įrenginiuose su ugniasienės funkcijomis, turite leisti prisijungti iš testavimo serverio prie nuskaitytų kompiuterių per IP. Atitinkamai, bandymo serveriui turi būti suteikta prieiga prie nuskaitytų pagrindinių kompiuterių tinklo prievadų naudojant atitinkamus nuotolinio valdymo protokolus.

Kadangi ESD, nuskaitydamas audito ir atitikties režimais, analizei naudoja nuotolinio valdymo protokolus, programinės įrangos nuskaitymo įrankiai turi būti autentifikuoti ir patvirtinti nuskaitytame mazge. ESD, norint nuskaityti mazgus audito ir atitikties režimais, kiekvieno tipo mazge (darbo stotyje, serveryje, taikomųjų programų sistemose, DBVS ir kt.) naudojamos paskyros su administravimo teisėmis.

Visi registruoti informacijos saugos įvykiai yra saugomi Microsoft SQL DBVS. Šie įvykiai gali būti siunčiami į informacijos saugumo įvykių stebėjimo posistemį naudojant specialias jungtis.

ESD veikimas ir priežiūra

Posistemio vartotojai

ESD įrankių valdymą ir priežiūrą atlieka organizacijos darbuotojai, turintys funkcinį „IS administratoriaus“ vaidmenį.

Informacijos saugos administratorius apibrėžiamas kaip specialistas, kurio užduotys apima:

• organizacijos mazgų nuskaitymo parametrų nustatymas;
• nuskaitymo užduočių nustatymas ir paleidimas;
• nuskaitymo rezultatų analizė dėl informacinių sistemų pažeidžiamumo, konfigūracijos klaidų ar techninių standartų neatitikimo;
• pažeidžiamumų pašalinimo kontrolė;
• standartų ir reikalavimų, taikomų organizacijos darbo vietų ir serverių saugumui užtikrinti, formavimas.

Sistemos veikimo režimai

Normalus darbo režimas

Įprastu režimu ESD veikia 24 valandas per parą, 7 dienas per savaitę.

Įprastomis sąlygomis informacijos saugos administratorius atlieka:

• suplanuotas ir neplanuotas mazgų nuskaitymas;
• ataskaitų generavimas;
• žinių bazių ir Testavimo programinės įrangos modulių atnaujinimas.

Avarinė operacija

Jei sutrinka saugos įrangos veikimas, sutrinka posistemio veikimas. ESD įrangos neeksploatavimas neturi įtakos organizacijos automatizuotų darbo vietų ir serverių veikimui.

1.6.2. Funkcinės struktūros diagrama

Funkcinės diagramos gali būti kuriamos visai informacijos apsaugos sistemai arba jos daliai, pavyzdžiui, posistemiui ar komponentui.

Bendros ISS funkcinės diagramos pavyzdys parodytas toliau pateiktame paveikslėlyje.

1.6.3. Techninių priemonių komplekso struktūrinė schema

Techninių priemonių komplekso blokinė schema gali būti sukurta tiek visai TKS, tiek jos dalims – posistemiams ir komponentams. Informacijos saugos sistemos dalių diagramų kūrimo galimybes lemia sistemos mastas ir reikalinga detalizacija.

Techninės informacijos ir apsaugos sistemų komplekso blokinės schemos pavyzdys pateiktas žemiau esančiame paveikslėlyje.

Rusijos Federacijos ekonominės plėtros ir prekybos ministerija

ATTVIRTAU

2007 m. spalio 29 d. valstybinė sutartis Nr. 000-05-07, sudaryta tarp Rusijos Federacijos ekonominės plėtros ir prekybos ministerijos ir UAB „PROGNOZ“, atlikti darbus tema „Automatinio modulio federaliniam socialiniam stebėjimui sukūrimas - Rusijos Federaciją sudarančių subjektų ekonominis vystymasis, sukuriant vieningą informacinę sistemą, skirtą pagrindinių Rusijos Federacijos socialinės ir ekonominės raidos rodiklių stebėjimui ir valdžios institucijų veiklos rezultatams juos pasiekti. Rengiant šį dokumentą buvo naudojamas standartizacijos vadovas GOST RD 50-34.698-90. 1. Bendrosios nuostatos... 5 1.1. Visas sistemos pavadinimas... 5 1.2. Dokumentai, kurių pagrindu vykdomas projektavimas.. 5 1.3. Etapai ir terminai.. 5 1.4. Tikslai ir tikslas.. 7 1.5. Projektinių sprendinių atitiktis saugos reikalavimams .. 8 1.6. Norminiai ir techniniai dokumentai... 9 2. Veiklos proceso aprašymas.. 10 2.1. Užduočių sąrašas... 10 2.2. Pagrindinės Modulio atliekamos funkcijos... 11 3. Pagrindiniai techniniai sprendimai.. 13 3.1. Modulio struktūra, posistemių sąrašas... 13 3.1.1. Centralizuoto duomenų saugyklos posistemis. 14 3.1.2. Sąsajos komponentas. 15 3.1.3. Adapterio programinės įrangos komponentai. 16 3.6.3. Pritaikomumo prie automatikos objekto parametrų nukrypimų laipsnis. 26 3.6.4. Priimtinos sistemos modernizavimo ir plėtros ribos.. 26 3.6.5. Patikimumo reikalavimai. 27 3.6.6. Saugumo reikalavimas. 27 3.6.7. Reikalavimai ergonomikai ir techninei estetikai. 28 Darbų sąrašas Laukiami darbo rezultatai Socialinės ir ekonominės informacijos centralizuotos duomenų saugyklos (CDW), naudojamos įgyvendinant Rusijos Federaciją sudarančių subjektų ir savivaldybių socialinio ir ekonominio išsivystymo rodiklių (PSED) federalinę stebėseną, sukūrimas. Centralizuotas duomenų saugojimo posistemis PSED duomenų schemų ir technologijos specifikacijų profilių, aprašančių sąveikos su sąsajos komponentu protokolus ir paskelbtų PSED duomenų formatus, kūrimas PSER duomenų schemos ir technologijos specifikacijų profiliai, aprašantys sąveikos su sąsajos komponentu protokolus ir paskelbtų PSER duomenų formatus; Duomenų schemų ir technologijų specifikacijų profilių specifikacijų projektų aptarimo ataskaita su įrašytomis diskusijos dalyvių pastabomis ir pasiūlymais. Kelių platformų programinės įrangos, skirtos sąsajos komponentui, kūrimas, testavimas bandomosiose diegimo vietose ir tobulinimas, atsižvelgiant į nustatytas pastabas. Sąsajos komponentai Privalomas adapterio komponentas Konkrečių adapterio komponentų, užtikrinančių automatinį informacijos apie EMS gavimą iš senų AIS duomenų šaltinių ir jos paskelbimo per sąsajos komponentą pagal jo specifikacijas, kūrimas. Konkrečiuose adapteriuose turi būti tikrinimo blokas ir jie turi patikrinti statistinės informacijos patikimumą Specialūs adapterio komponentai; Taisyklės dėl automatinio informacijos, naudojamos įgyvendinant federalinę stebėseną ir pateikiamos iš federalinių ministerijų ir departamentų, Rusijos Federaciją sudarančių subjektų, savivaldybių svetainių ir AIS, rinkimo pagal parengtas išvesties parametrų, skirtų informacijai teikti, specifikacijas. šių duomenų šaltinių Rusijos Federaciją sudarančių subjektų socialinės ir ekonominės raidos stebėjimo ir analizės rezultatų lentelių, grafinių, kartografinių, tekstinių pateikimo priemonių kūrimas. Stebėsenos duomenų ir Rusijos Federaciją sudarančių vienetų socialinės ir ekonominės raidos analizės rezultatų lentelių, grafinio, kartografinio, tekstinio pateikimo posistemis Modulio posistemio, skirto federaciją sudarančių vienetų ūkio sektorių raidos vertinimo kriterijams apskaičiuoti remiantis federalinės stebėsenos metu surinkta informacija, sukūrimas. Rusijos Federaciją sudarančių vienetų ekonomikos sektorių raidos vertinimo kriterijų apskaičiavimo posistemis (su galimybe identifikuoti regioninius klasterius), remiantis informacija, surinkta federalinės stebėsenos metu. Modulio posistemio, skirto federalinių subjektų integraliniams indeksams ir socialinio ir ekonominio išsivystymo vertinimams, remiantis federalinės stebėsenos metu surinkta informacija, kūrimas. Rusijos Federaciją sudarančių vienetų integralinių indeksų skaičiavimo ir socialinio ir ekonominio vystymosi vertinimų posistemė, pagrįsta informacija, surinkta federalinės stebėsenos metu. Modulio posistemio, skirto informacijai apie elektroninės energetikos sistemą skelbti pagal galiojančių teisės aktų reikalavimus ir parengto įgyvendinant projektą, sukūrimas, taip pat sąsajos komponento specifikacijos. Modulyje saugomos pirminės ir konvertuotos informacijos apie elektroninės energetikos sistemą viešai prieinamo publikavimo posistemis Administravimo posistemio kūrimas Administravimo posistemis Visas federalinio stebėjimo modulio projektinės dokumentacijos paketas pagal GOST 34 reikalavimus Priėmimo testų atlikimas, Modulio užbaigimas pagal Kliento pastabas

1. Bendrosios nuostatos;
2. veiklos aprašymas;
3. pagrindiniai techniniai sprendimai;
4. įvykiai

[iš RD 50-34.698-90 2.2.1 punkto]

Bendrosios nuostatos

Skiltyje „Bendrosios nuostatos“ jie pateikia:

1. dokumentų, kurių pagrindu vykdomas AE projektavimas, projektas ir pavadinimai, jų numeriai ir data;
2. sistemoje dalyvaujančių asmenų sąrašas, terminai;
3. tikslai, paskirtis ir AS;
4. patvirtinimas, kad projektiniai sprendiniai atitinka galiojančius standartus ir priešgaisrinę bei sprogimo saugą ir kt.;
5. informacija apie naudojamus projektuojant;
6. informacija apie geriausią praktiką, naudojamą kuriant projektą;
7. sistemos sukūrimo tvarka ir kiekvienos apimtis.

[iš RD 50-34.698-90 2.2.2 punkto]

Veiklos proceso aprašymas

Skyriuje „Veiklos proceso aprašymas“ jie atspindi procedūrų sudėtį (), atsižvelgiant į procesų ir veiklų tarpusavio ryšį ir suderinamumą, sudaro darbo organizavimą gamykloje [iš RD 50-34.698 2.2.3 p. -90]

Pagrindiniai techniniai sprendimai

Skyriuje „Pagrindiniai techniniai sprendimai“ jie pateikia:

1. sprendimai dėl sistemos struktūros, komunikacijos priemonių ir būdų keistis informacija tarp posistemių;
2. sprendimai dėl sistemos sujungimo su susijusiomis sistemomis ir jos palaikymo;
3. sistemos veikimo sprendimai;
4. sprendimai dėl skaičiaus, kvalifikacijos ir funkcijų, jos veikimo būdų, sąveikos tvarkos;
5. informacija apie ją apibrėžiančių sistemos (posistemių) nurodytų vartotojų savybių užtikrinimą;
6. sistemos (posistemės) įgyvendinamų užduočių kompleksų () sudėtis;
7. sprendimai dėl komplekso, jo išdėstymo;
8. sprendimai dėl informacijos sudėties, apimties, metodų, kompiuterių ir dokumentų tipų, sekos ir kitų komponentų;
9. sprendimus dėl veiklos sudėties, kalbų, procedūrų ir operacijų bei jų įgyvendinimo būdų.

Skyriuje pateikiamos kitų dokumentų, kurie gali būti įtraukti pagal GOST 34.201 [iš RD 50-34.698-90 2.2.4 punkto], iliustracijos.

Priemonės, skirtos automatikos objektui paruošti sistemos paleidimui

Skyriuje „Parengiamosios sistemos paleidimo priemonės“ pateikiama:

1. priemones, kad informacija būtų tinkama forma;
2. personalo mokymo ir kvalifikacijos tikrinimo veikla;
3. priemonės reikalingiems padaliniams ir darbo vietoms sukurti;
4. automatikos objekto keitimo priemonės;
5. kitos priemonės, pagrįstos specifinėmis kuriamų sistemų savybėmis.