27.10.2016 09:57:23

Acest articol discută etapa de proiectare tehnică legată de una dintre etapele ciclului de viață al sistemului securitatea informatiei(NIB) - etapa de „proiectare”, care, în conformitate cu standard intern GOST 34.601-90 urmează imediat dezvoltarea Termenilor de referință pentru un sistem de securitate a informațiilor.

1. Elaborarea documentației tehnice a proiectului pentru BNI

Ciclul de viață al unui sistem de securitate a informațiilor (în continuare - SIS) constă în general din următoarele etape:

• analiza cerințelor pentru ISS;
• proiecta;
• implementare;
• implementare;
• exploatare.

Acest articol discută stadiul proiectului tehnic legat de etapa „proiectare” și, în conformitate cu standardul intern GOST 34.601-90, urmează imediat dezvoltarea Termenilor de referință pentru sistemul de securitate a informațiilor.

1.1. De ce să dezvoltați documentația pentru NIB?

Răspunsul la această întrebare ar trebui luat în considerare în două planuri: în planul proprietarului resurselor informaționale (pentru protecția cărora este creat ISS) și în planul dezvoltatorului direct al ISS.

Pentru proprietarul resurselor informaționale, este important să obțină rezultatul sub forma unui sistem de securitate a informațiilor funcțional, care să reducă riscurile de a compromite informații cu acces restricționat în organizație. Proiectul tehnic în acest caz servește la dezvoltarea bazelor fundamentale ale viitorului sistem, și anume, include o descriere a modului în care va fi construit și funcționa ISS, ce măsuri și mijloace vor asigura protecția informațiilor, care sunt posibilitățile de dezvoltare si imbunatatirea sistemului. La finalizarea dezvoltării unui proiect tehnic pentru un sistem de securitate a informațiilor, Clientul primește un set cuprinzător de documentație pentru NIS, care descrie toate nuanțele tehnice ale viitorului sistem.

Pentru executantul direct din etapa proiectului tehnic, este necesar să se stabilească cea mai adecvată arhitectură a NIS, precum și să se realizeze alegerea potrivita măsuri şi mijloace de protecţie a informaţiilor din organizaţie. De asemenea, este important să se asigure că caracteristicile și proprietățile sistemului respectă termenii de referință sau să se justifice, cu participarea și acordul Clientului, ajustarea cerințelor specificate în TOR pentru a crește eficiența sistemul care se creează.

Astfel, ca urmare a elaborării documentației tehnice a proiectului, Clientul va avea răspunsuri la următoarele întrebări:

• care este arhitectura generală a BNI;
• ce măsuri și mijloace vor fi utilizate pentru implementarea cerințelor de protecție a informațiilor;
• cum va funcționa NIS;
• ce schimbări în organizație, necesare creșterii nivelului de securitate a informațiilor, vor urma ca urmare a introducerii ISS;
• dacă cerințele Clientului (cerințe de business) și cerințele actelor juridice de reglementare în domeniul securității informațiilor vor fi luate în considerare la elaborarea și implementarea ISS și, dacă da, cum.

Antreprenorul aflat în curs de elaborare a documentației tehnice a proiectului va primi următoarele rezultate:

• baza pentru trecerea la etapele următoare de construire a INS, și anume etapele de documentare de lucru și implementare;
• înțelegerea arhitecturii, tehnologiilor și instrumentelor utilizate, ordinea de construire a sistemului;
• modul în care sunt implementate cerințele Clientului (cerințe de afaceri) și documentele de reglementare în domeniul securității informațiilor pentru sistem.

1.2. Prezentare generală a abordărilor pentru dezvoltarea documentației tehnice a proiectului

Elaborarea unui proiect tehnic pentru un sistem de securitate a informațiilor se realizează cel mai adesea pe baza standardelor relevante și a documentelor de orientare. Si pentru institutii publice utilizarea lor este obligatorie, iar in scopuri comerciale este recomandata. La practică organizatii comerciale De asemenea, utilizați standardele de stat atunci când elaborați documentația tehnică a proiectului din următoarele motive:

• abordare dovedită în mod repetat a creării de sisteme informaționale;
• structura și conținutul atent al documentelor;
• un set de documente suficient pentru dezvoltarea și descrierea aproape a oricărui sistem.

Pentru elaborarea documentației pentru etapa proiectului tehnic (TP) pe BNI se folosesc standarde de stat și documente de orientare din seria 34:

• GOST 34.201-89 „Tipurile, completitudinea și desemnarea documentelor atunci când se creează sisteme automate”. Acest standard specifică:
  • tipuri și denumiri de documente ale etapei TP;
  • caracterul complet al documentației;
  • denumiri acceptate ale documentelor;
  • reguli pentru desemnarea NIB-urilor și a părților acestora.
• GOST 34.003-90 „Termeni și definiții”;
• GOST 34.601-90 „Sisteme automatizate. Etapele creației. Standardul specifică:
  • lista etapelor de lucru efectuate la etapa TP;
  • descriere detaliata lucrari efectuate in etapa TP;
  • lista organizațiilor care participă la crearea INS;
• RD 50-34.698-90 „Sisteme automatizate. Cerințe pentru conținutul documentelor. Acest document de orientare specifică cerințele pentru conținutul documentelor de etapă AT.

Este important de înțeles că, conform standardelor din seria 34, un proiect tehnic este o etapă în crearea unui sistem, și nu doar un set de documente. Această etapă în practică este adesea combinată cu etapa de proiectare preliminară, care servește la elaborarea mai multor soluții preliminare și la fundamentarea celei mai potrivite. O astfel de combinație este permisă de standard, dar trebuie avut în vedere că aceasta nu anulează necesitatea atingerii obiectivelor etapei preliminare de proiectare.

Cel mai adesea, etapa de proiectare a proiectului este dezvoltată atunci când cerințele specificațiilor tehnice pentru sistem pot fi implementate în mai multe moduri fundamental diferite și, de asemenea, dacă nu există metode preferate fără ambiguitate printre aceste metode.

Cu toate acestea, trebuie remarcat faptul că standardele de mai sus sunt prea generale și implementează în principal o funcție de proiectare și structurală generală. Pentru a dezvolta partea de fond a documentelor etapei de proiectare tehnică, proiectanții folosesc informații din următoarele surse:

Documente de reglementare actuale (NLA) care reglementează cerințele de protecție a uneia sau aceleia informații cu acces limitat. Aceste RLA prezintă cerințele pentru măsurile de protecție a informațiilor în sistemele informaționale, descriu nuanțele implementării acestor măsuri și măsuri suplimentare de consolidare. Dintre NPA-urile actuale se pot distinge următoarele:

• Ordinul FSTEC al Rusiei din 18 februarie 2013 nr. 21 „Cu privire la aprobarea compoziției și conținutului măsurilor organizatorice și tehnice pentru a asigura securitatea datelor cu caracter personal în timpul prelucrării acestora în sistemele de informații cu date cu caracter personal”;
• Ordinul FSTEC al Rusiei din 11 februarie 2013 nr. 17 „Cu privire la aprobarea cerințelor de protecție a informațiilor care nu sunt secrete de stat conținute în sistemele informaționale de stat”
• Ordinul FSTEC al Rusiei din 14 martie 2014 nr. 31 „Cu privire la aprobarea cerințelor pentru asigurarea protecției informațiilor în sistemele automate de control pentru producție și procese tehnologice la instalațiile de importanță critică, instalațiile potențial periculoase, precum și instalațiile care prezintă un pericol crescut pentru viața și sănătatea umană și pentru mediul natural;
• document metodologic „Măsuri de protecție a informațiilor în sistemele informaționale de stat”, aprobat de FSTEC din Rusia la 11 februarie 2014

Cerințele pentru protecția informațiilor de acces restricționat și listele de măsuri de protecție variază pentru IS de diferite niveluri/clase de securitate. Dacă informațiile din organizație nu aparțin celor protejați în conformitate cu legi federale RF (de exemplu, un secret oficial), atunci proprietarul acestor informații poate folosi abordările propuse în aceste acte juridice pentru a construi un ISS corporativ.

rusă și standarde străine, descriind diferite abordări ale modalităților de implementare a etapelor ciclului de viață al construirii unui SSI, inclusiv etapele unui proiect tehnic:

• o serie de standarde de stat GOST R ISO/IEC 2700X, identice cu standardele internaționale ISO/IEC 2700X. Aceste standarde descriu abordarea procesului PDCA (Plan, Do, Check, Act) pentru implementarea ciclului de viață al sistemului de management al securității informațiilor, care este o parte integrantă a ISS;
• NIST SP 800-64 este un standard al Institutului Național de Standarde și Tehnologie din SUA care descrie ciclu de viață dezvoltarea sistemelor informatice;
• NIST SP 800-37 este un standard al Institutului Național de Standarde și Tehnologie din SUA, care oferă îndrumări privind integrarea managementului riscului în ciclul de viață al dezvoltării sistemelor informaționale.

Documentația operațională a producătorului pentru securitatea informațiilor și ajutoare. Aceste documente conțin informații tehnice cuprinzătoare despre instrumentele utilizate în construcția ISS, inclusiv cele care nu au legătură directă cu implementarea măsurilor IS, de exemplu, servere, sisteme de stocare a datelor, instrumente de virtualizare și altele. Setul general de astfel de documente pentru diferiți producători este diferit și depinde, printre altele, de execuția unui anumit instrument (hardware/software). Mai jos este un set standard de documentație operațională pentru instrumentele de securitate a informațiilor utilizate pentru elaborarea documentelor pentru etapa de proiect tehnic:

• descriere generală (fișă de date);
• ghidul administratorului (poate include ghid de management local și centralizat);
• manualul utilizatorului;
• ghid rapid de instalare și implementare (pentru GIS hardware);
• manual de utilizare;
• ghid de implementare a infrastructurii virtuale (pentru software GIS);

Informații generale despre arhitecturile NIS disponibile, cele mai bune practiciîn ceea ce privește construirea ISS, îndrumări privind securitatea și integrarea echipamentelor de securitate a informațiilor între ele, informații despre problemele în interacțiunea anumitor facilități de securitate a informațiilor. Exemple de astfel de informații pot include următoarele documente:

• ghiduri de arhitectură a sistemului de securitate a informațiilor, de exemplu: Defense-in-Depth, Cisco SAFE, Check Point SDP și altele;
• cele mai bune practici de securitate a informațiilor, cum ar fi cele disponibile la aceste link-uri (https://www.sans.org/reading-room/whitepapers/bestprac/ , http://csrc.nist.gov/publications/nistpubs/800-14/ 800-14.pdf). Aceste documente sunt cel mai adesea prezentate pe Limba engleză, cu toate acestea, orice producator rus SZI si la cerere pot fi furnizate;
• ghiduri de siguranță pentru IPS și medii de operare. Un exemplu este secțiunea „Securitate” de pe portalul oficial Microsoft (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. Dezvoltarea unui proiect tehnic pentru NIB în conformitate cu GOST 34

Elaborarea documentelor pentru etapa de proiect tehnic la INS este realizată cel mai adesea de integratori ai acestor servicii și este implementată în principal în conformitate cu următorul plan:

Stabilirea listei de documente care urmează să fie elaborate - această informație este indicată în termenii de referință pentru INS. În unele cazuri, elaboratorul documentelor, de comun acord cu Clientul, poate extinde sau reduce această listă, dacă posibilitatea acestui lucru este prevăzută în TOR;

Dezvoltarea șabloanelor de documente pentru etapa TP - structura este utilizată în conformitate cu RD 50-34.698-90 și GOST 2.106 (pentru unele documente), execuție în conformitate cu GOST 2.105-95;

Dezvoltarea părții de fond a documentelor. Cerințele pentru sistem sunt stabilite în termenii de referință pentru NIB. În conformitate cu aceste cerințe, se stabilește o listă a măsurilor tehnice și organizatorice de protecție necesare implementării în sistem. Măsurile de protecție pot fi definite în actele juridice de reglementare relevante (în funcție de tipul de informații care sunt protejate), standardele corporativeși politicile de securitate a informațiilor, precum și pe baza prezenței amenințărilor curente de securitate identificate în timpul dezvoltării modelului de amenințare al organizației. Pe baza listei de măsuri de protecție, dezvoltatorul ISS selectează instrumentele adecvate de protecție a informațiilor și dezvoltă structura funcțională a sistemului de securitate a informațiilor (subsisteme, componente). În continuare, în documentele tehnice de proiectare este descris implementare practică măsuri de protecție bazate pe GIS-ul selectat sau măsuri organizatorice în infrastructura organizației.

Coordonarea documentatiei elaborate si a solutiilor prezentate in aceasta cu Clientul sistemului.

La elaborarea documentației tehnice a proiectului, cel mai adesea nu este necesară elaborarea unei liste complete de documente specificate în GOST 34.201-89, deoarece acest standard este învechit și unele dintre documente nu iau în considerare tendințele de dezvoltare și tehnologiile sistemelor informaționale moderne. . Setul minim de documente necesare pentru a descrie un sistem de securitate a informațiilor este următorul:

• descrierea proiectului tehnic;
• nota explicativa la proiect tehnic;
• sistem structură funcțională;
• diagrama structurală a complexului mijloace tehnice;
• Organigrama;
• lista de articole achizitionate.

La cererea Clientului sau dacă NIS este un sistem complex multicomponent, pot fi elaborate suplimentar următoarele documente:

• schema de automatizare;
• descrierea funcțiilor automate;
• Descriere suport informativ sisteme;
• descrierea complexului de mijloace tehnice;
• Descriere software;
• descrierea structurii organizatorice.

Trebuie remarcat faptul că GOST 34.201-89 permite extinderea gamei de documente în etapa TP, cu toate acestea, în practică, aceste documente sunt mai mult decât suficiente.

Fișă de proiect tehnic

Denumire: TP.

Acest document are scopul de a descrie lista documentelor elaborate la etapa proiectului tehnic. De asemenea, este indicat numărul de pagini ale fiecărui document elaborat.

Notă explicativă la proiectul tehnic

Denumire: P2.

Acest document este principalul pentru etapa TP și include o descriere a arhitecturii ISS, măsuri tehnice și organizatorice, funcții ISS, complexe software și hardware și altele. Conform standardului, acesta constă din patru secțiuni principale:

• Dispoziții generale;
• descrierea procesului de activitate;
• principalele soluții tehnice;
• măsuri de pregătire a obiectului de automatizare pentru punerea în funcţiune a sistemului.

Diagrama structurii funcționale

Denumire: C2.

Acest document descrie structura logică a NIS, și anume:

• subsisteme și componente logice incluse în NIS;
• funcții implementate prin intermediul subsistemelor și componentelor;
• legături de informații între elementele logice ale NIS și tipurile de mesaje din schimb.

Diagrama structurală a unui complex de mijloace tehnice

Denumire: C1.

Acest document include o descriere a următoarelor elemente ale NIS:

• mijloace tehnice ca parte a subsistemelor și componentelor logice ale NIS;
• canale de comunicare şi schimb între mijloace tehnice cu indicarea protocoalelor de transport.

Schema de organizare

Denumire: C0.

Acest document descrie structura organizationala organizații în ceea ce privește managementul NIS și anume:

• subdiviziunile și persoanele responsabile ale organizației implicate în funcționarea ISS;
• funcțiile îndeplinite și comunicările între departamente și persoanele responsabile.

Lista produselor achizitionate

Denumire: VP.

Acest document include o listă a tuturor software-ului și hardware-ului, precum și a licențelor utilizate la crearea NIS. Dezvoltat în conformitate cu GOST 2.106.

Notă. De asemenea, este de remarcat aici că actul de guvernare RD 50-34.698-90 permite adăugarea oricărui document al etapei TP (includerea de secțiuni și informații altele decât cele propuse), comasarea secțiunilor, precum și excluderea unor secțiuni individuale. Deciziile în acest sens sunt luate de dezvoltatorul documentelor din etapa TP și se bazează pe caracteristicile NIS-ului creat.

1.4. Reguli de elaborare a documentației

• conformitatea structurală standardele de stat;
• respectarea strictă a cerințelor specificațiilor tehnice pentru sistem;
• aplicarea șabloanelor de documente (aplicarea de stiluri uniforme, marcare, câmpuri etc.);
• abordarea individuală și utilizarea simultană a dezvoltărilor existente la completarea secțiunilor de documente.

Notă explicativă la proiectul tehnic:

• dezvoltarea documentului se realizează în mediul Microsoft Word, după finalizarea dezvoltării se recomandă convertirea documentului în format PDF pentru comoditate;
• termenii și abrevierile ar trebui să fie aceleași în toate secțiunile documentului;
• se recomandă evitarea repetărilor explicite și a creșterii inutile a volumului documentului;
• soluțiile tehnice trebuie descrise cât mai detaliat posibil, indicând:
  • arhitectura si tehnologiile utilizate;
  • locațiile software și hardware în infrastructura organizației;
  • instrumente de securitate a informațiilor utilizate cu o descriere a caracteristicilor acestora, funcții implementate, informații de certificare;
  • setările de bază ale instrumentelor de securitate a informațiilor în ceea ce privește mecanismele de protecție, adresare, rutare, interacțiune cu sisteme și instrumente aferente și alte lucruri;
  • comenzile, metodele de acces la acestea și locațiile de instalare ale acestora;
  • scheme (structurale, funcționale, organizaționale):
    • dezvolta diagrame în mediul Microsoft Visio;
    • după dezvoltare, inserați diagrame într-un document utilizând dialogul Paste Special în format EMF (metafișier Windows);
    • dezvoltarea schemelor separate pentru sistem, subsisteme și componente ale subsistemelor;
    • faceți designul schemelor de același tip, folosind aceleași elemente, abrevieri, pictograme, stiluri de text și așa mai departe.

1.5. Resurse pentru a vă ajuta să dezvoltați documentația

Pe Internet este postată o cantitate imensă de informații care, într-o măsură sau alta, pot ajuta la elaborarea documentației tehnice a proiectului. Principalele resurse sunt prezentate în tabelul de mai jos.

Masa. Resurse pentru proiectare tehnică PENIŢĂ

1.6. Exemple de documente ale etapei proiectului tehnic

Pentru a înțelege cerințele pentru conținutul documentației etapei TP, mai jos sunt prezentate exemple de completare a documentelor principale (secțiuni de documente).

1.6.1. Notă explicativă la proiectul tehnic

Nota explicativă este un document destul de voluminos, prin urmare, iată un exemplu de conținut al secțiunii „Soluții tehnice de bază” în ceea ce privește unul dintre subsistemele ISS - subsistemul de analiză a securității.

Subsistemul de analiză de securitate NIS

Structura și componența subsistemului

Subsistemul de analiză a securității (SAS) este conceput pentru a monitoriza sistematic starea de securitate a stațiilor de lucru automate (AWP) ale personalului și serverelor organizației. Baza PAZ este instrumentul software „Test” produs de compania LLC „Securitate informațională”. IPS Test este certificat de FSTEC din Rusia pentru conformitatea cu specificațiile tehnice (TU) pentru securitatea informațiilor și pentru al 4-lea nivel de control al absenței capacităților nedeclarate.

Compoziția PAZ include următoarele componente:

• Server de administrare Test Server;
• consola de testare a consolei de management.

Descrierea componentelor subsistemului este prezentată în tabelul de mai jos.

Masa. Componentele PAZ

Furnizare de caracteristici

PAZ oferă următoarele funcții:

• implementarea protecției proactive a stațiilor de lucru și serverelor organizației prin monitorizarea stării de securitate a informațiilor;
• automatizarea proceselor de control al conformității politicieni interniși anumite standarde de siguranță;
• reducerea costurilor de audit și control de securitate, pregătirea rapoartelor de stare;
• automatizarea inventarului de resurse, managementul vulnerabilităților, conformitatea cu politicile de securitate și procesele de control al schimbărilor.

Soluție pentru un complex de instrumente hardware și software

Lista de software și hardware utilizate de ESD este prezentată în tabelul de mai jos.

Masa. Software și hardware PAZ

Server de control PAZ

Mijloace tehnice

Serverul fizic utilizat ca server de management SIS trebuie să îndeplinească cerințele tehnice pentru software-ul și OS instalat pe acesta, prezentate în tabelul de mai jos.

Masa. Cerințe pentru sistemul de operare și software-ul serverului de management PAZ

Software

Management Server OS

Sistemul de operare Windows 2008 R2 este instalat pe serverul de management în mod obișnuit dintr-o distribuție bootabilă.

Sistemul de operare al serverului de management este gestionat atât local din consolă, cât și prin protocolul RDP.

Server de management DBMS

Instalarea bazei de date Microsoft SQL Server 2008 R2 se realizează sub un cont cu drepturi de administrator local utilizând vrăjitorul de instalare standard din pachetul de distribuție furnizat de dezvoltatorul produsului.

Testare software server

Software-ul Test Server este instalat pe serverul de management folosind asistentul standard de instalare.

Configurarea inițială și gestionarea ulterioară a software-ului Test Server în modul normal se realizează utilizând consola de management Test Console instalată pe stația de lucru a administratorului IS.

Stație de lucru administrator IS

Mijloace tehnice

Ca platformă, este utilizată o stație de lucru existentă a unui angajat al unității organizaționale responsabilă cu asigurarea securității informațiilor, care rulează un OS din familia Microsoft Windows.

Mijloacele tehnice ale stației de lucru ale administratorului IS trebuie să aibă următoarele caracteristici ale configurației hardware (cel puțin recomandate):

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

Software

Software-ul consolei de testare

Stația de lucru a administratorului IS, pe care este instalat software-ul Test Console, trebuie să funcționeze sub unul dintre următoarele sisteme de operare:

• Microsoft Windows 7, 32 și 64 de biți;
• Microsoft Windows 8/8.1, 32 și 64 de biți.

În plus, pentru funcționarea corectă a software-ului consolei de management Test Console, stația de lucru a administratorului IS trebuie să aibă instalată Microsoft .NET Framework versiunea 3.5 SP1 sau o versiune ulterioară, iar setările de securitate ale SO utilizat trebuie să permită accesul la Test Server.

Software-ul Test Console este instalat pe stația de lucru a administratorului PAZ utilizând asistentul standard de instalare a software-ului Test Server, cu opțiunea de instalare a consolei de management Test Console selectată și alte setări implicite.

Interacțiunea cu sistemele conexe

Pentru PAZ, adiacente sunt:

• mijloacele subsistemului firewall;
• servicii de directoare Active Directory;
• Stația de lucru și serverele organizației.

Pentru a asigura interacțiunea rețelei cu sistemele adiacente și direct între componentele ESD în sine, trebuie organizat trecerea traficului de rețea necesar.

Pentru a oferi posibilitatea de a primi actualizări ale bazei de cunoștințe și modulelor software-ului Test pentru scanerul Test Server, este necesar să oferiți acces la serverul web update.com al Information Security LLC update.com pe portul 443/tcp.

La scanarea în modul PenTest, interacțiunea dintre scanerul Test Server și stația de lucru și serverele organizației se realizează prin protocolul IP. La scanarea în modul Audit și Conformitate, sunt utilizate protocoalele de control de la distanță WMI, RPC etc.. Pentru a scana gazde pe dispozitive cu funcții de firewall, trebuie să permiteți conexiuni de la Serverul de testare la gazdele scanate prin protocolul IP. În consecință, pentru serverul de testare, este necesar să se ofere acces la porturile de rețea ale nodurilor scanate folosind protocoalele adecvate de control de la distanță.

Deoarece PAZ, atunci când scanează în modurile Audit și Conformitate, utilizează protocoale de control de la distanță pentru analiză, instrumentele de scanare ale software-ului Test trebuie să fie autentificate și autorizate pe nodul scanat. În PAZ, pentru a scana noduri în modurile Audit și Conformitate în fiecare dintre tipurile de noduri (stație de lucru, server, sisteme de aplicații, DBMS etc.) Conturi cu privilegii administrative.

Toate evenimentele de securitate a informațiilor înregistrate sunt stocate în Microsoft SQL DBMS. Aceste evenimente pot fi trimise prin conectori speciali la subsistemul de monitorizare a evenimentelor IS.

Exploatarea și întreținerea PAZ

Utilizatorii subsistemului

Operarea și întreținerea instrumentelor PAZ este efectuată de angajați ai organizației cu rolul funcțional de „administrator IS”.

Un administrator IS este un specialist ale cărui sarcini includ:

• definirea parametrilor pentru scanarea nodurilor organizației;
• configurarea și lansarea sarcinilor de scanare;
• analiza rezultatelor scanării pentru vulnerabilități, erori de configurare sau neconformități în sistemele informaționale standardele tehnice;
• controlul eliminării vulnerabilităților;
• formarea standardelor și cerințelor care se aplică pentru asigurarea securității stațiilor de lucru și serverelor organizației.

Moduri de operare a sistemului

Modul obișnuit de funcționare

În funcționare normală, PAZ funcționează 24 de ore pe zi, 7 zile pe săptămână.

În funcționare normală, administratorul IS efectuează:

• scanarea programată și neprogramată a nodurilor;
• generarea de rapoarte;
• actualizarea bazelor de cunoștințe și modulelor software-ului Test.

Operare de urgență

În cazul unei defecțiuni a mijloacelor PAZ, funcționarea subsistemului este întreruptă. Încălcarea operabilității mijloacelor PAZ nu afectează funcționarea stației de lucru și a serverelor organizației.

1.6.2. Diagrama structurii funcționale

Diagramele funcționale pot fi dezvoltate pentru întregul NIS sau pentru o parte a acestuia, cum ar fi un subsistem sau o componentă.

Un exemplu de general diagrama functionala NIB este prezentat în figura de mai jos.

1.6.3. Diagrama structurală a unui complex de mijloace tehnice

O diagramă bloc a unui complex de mijloace tehnice poate fi dezvoltată atât pentru întregul NIS, cât și pentru părțile sale - subsisteme și componente. Actualitatea dezvoltării schemelor pentru părți ale NIS este determinată de amploarea sistemului și de detaliul necesar.

Exemplu diagramă bloc a complexului de mijloace tehnice ale NIS este prezentată în figura de mai jos.

De regulă, Nota explicativă este cel mai complex document software, provocând uneori multe controverse și discuții în jurul conținutului său. De ce se întâmplă asta?

Numirea unei note explicative

Am spus deja că în dezvoltarea de software aceasta este una dintre etapele importante. Ar trebui să conțină o descriere a sistemului dvs., ținând cont de tehnologiile selectate, conform cerințelor GOST 34. Și documentul Notă explicativă a proiectului tehnic sau, pe scurt, PZ, este unul dintre documentele principale. această etapă. Și, trebuie să spun, de cele mai multe ori Nota explicativă este cel mai complex document despre software, provocând uneori multe controverse și discuții în jurul conținutului acestuia.

Componența unei note explicative tipice

Nota explicativă a proiectului tehnic include secțiuni precum:

– Introducere. Această secțiune conține numele complet al sistemului și subiectul dezvoltării, precum și o listă de documente care au servit ca bază pentru lucrul la proiect.

– Scopul și domeniul de aplicare. Descrie scopurile și obiectivele care vor fi rezolvate cu ajutorul sistemului, precum și domeniul de aplicare al acestuia.

– Specificații. Această secțiune este de obicei împărțită în subsecțiuni, care descriu: stabilirea sarcinii de creare a unui program; aparate matematice folosite; algoritm de operare software; structura datelor de intrare și de ieșire; compoziția hardware și software. De asemenea, este necesar să se furnizeze calcule și rezultate ale analizelor pentru a justifica alegerea exactă a acelor decizii care sunt menționate în document.

– Tehnic așteptat indicatori economici . Secțiunea presupune o justificare economică a dezvoltării, ținând cont de indicatorii tehnici ai acesteia.

– Surse utilizate în dezvoltare. O secțiune este o listă de documente, articole și publicații care au fost menționate în text.

Standarde pentru nota explicativă

Compoziția secțiunilor este determinată de GOST 19.404, cu toate acestea, standardul permite combinarea acestor secțiuni, dacă este necesar, și, de asemenea, adăugarea altora noi. În cazul utilizării GOST seria 34, un document trebuie elaborat în conformitate cu RD 50-34.698. Cu toate acestea, documentul trebuie să rămână în cerințele standarde comune, cum ar fi, de exemplu, GOST 19.105.

Costul elaborării unei note explicative

Ce zici cu cel mai mic cost creați un document de program care este cel mai util pentru proiectul dvs., care:

- pe de o parte, prezintă clar și inteligibil toate informațiile necesare (și uneori plictisitoare), inclusiv detalii tehnice complexe;

GOST 19.404-79

Grupa T55

STANDARD INTERSTATAL

Sistem unificat de documentare a programului

NOTĂ EXPLICATIVĂ

Cerințe pentru conținut și design

Sistem unificat pentru documentarea programului. Notă explicativă. Cerințe privind conținutul și forma de prezentare

Data introducerii 1981-01-01

Decret Comitetul de Stat CCSR conform standardelor din 11 decembrie 1979 N 4753, data introducerii este stabilită la 01.01.81

REPUBLICARE. ianuarie 2010


Acest standard stabilește cerințele pentru conținutul și proiectarea documentului de program „Notă explicativă”, definită de GOST 19.101-77, care face parte din documente în etapele de elaborare a proiectului și a proiectelor tehnice ale programului.

1. DISPOZIȚII GENERALE

1. DISPOZIȚII GENERALE

1.1. Structura și designul documentului sunt stabilite în conformitate cu GOST 19.105-78.

Compilarea părții de informații (rezumat și conținut) este opțională.

1.2. Nota explicativă trebuie să conțină următoarele secțiuni:

introducere;

Scopul și domeniul de aplicare;

specificații;

indicatori tehnici și economici așteptați;

sursele utilizate în dezvoltare.

În funcție de caracteristicile documentului, se pot combina secțiuni individuale (subsecțiuni), precum și se pot introduce noi secțiuni (subsecțiuni).

2.1. În secțiunea „Introducere” indicați numele programului și (sau) simbol teme de dezvoltare, precum și documente pe baza cărora se realizează dezvoltarea, indicând organizarea și data aprobării.

2.2. În secțiunea „Scopul și domeniul de aplicare” indicați scopul programului, descriere scurta domeniul de aplicare al programului.

2.3. Secțiunea „Specificații” ar trebui să conțină următoarele subsecțiuni:

stabilirea unei sarcini pentru dezvoltarea unui program, o descriere a metodelor matematice aplicate și, dacă este necesar, o descriere a ipotezelor și restricțiilor asociate cu aparatul matematic ales;

descrierea algoritmului și (sau) funcționarea programului cu justificarea alegerii schemei algoritmului de rezolvare a problemei, posibile interacțiuni ale programului cu alte programe;

descrierea și justificarea alegerii metodei de organizare a datelor de intrare și de ieșire;

descrierea și justificarea alegerii compoziției hardware și software pe baza calculelor și (sau) analizelor, distribuția suporturilor de date utilizate de program.

2.4. În secțiunea „Indicatori tehnici și economici așteptați” se indică indicatorii tehnici și economici care justifică avantajul opțiunii alese a soluției tehnice, precum și, dacă este cazul, indicatorii operaționali preconizați.

2.5. În secțiunea „Surse utilizate în dezvoltare” indicați o listă de publicații științifice și tehnice, documente de reglementare și alte materiale științifice și tehnice la care se face referire în textul principal.

2.6. Anexa la document poate include tabele, justificări, metode, calcule și alte documente utilizate în elaborare.



Textul electronic al documentului
pregătit de CJSC „Kodeks” și verificat cu:
publicație oficială
Sistem unificat de documentare a programului:
sat. GOST-uri. -
M.: Standartinform, 2010

minister dezvoltare economicăși comerț Federația Rusă

din 01.01.74

Acest standard stabilește cerințe pentru implementarea unui proiect tehnic pentru produse în toate industriile.

1. DISPOZIȚII GENERALE

2. CERINȚE PENTRU IMPLEMENTAREA DOCUMENTELOR

APENDICE

LISTA LUCRĂRILOR REALIZATE ÎN PERIOADA DEZVOLTĂRII PROIECTULUI TEHNIC

În cazul general, la elaborarea unui proiect tehnic se efectuează următoarele lucrări: a) elaborarea de soluții de proiectare pentru produs și componentele sale principale; b) efectuarea calculelor necesare, inclusiv a celor de confirmare a indicatorilor tehnico-economici stabiliți de caietul de sarcini c) realizarea completarii schemelor de circuite necesare, schemelor de conectare etc.; d) elaborarea și justificarea soluțiilor tehnice care furnizează indicatori de fiabilitate stabiliți prin caietul de sarcini și etapele anterioare de dezvoltare (dacă aceste etape au fost elaborate); e) analiza proiectării produsului pentru fabricabilitate, luând în considerare feedback-ul producătorilor industriali în ceea ce privește asigurarea fabricabilității în condițiile acestei producții particulare, inclusiv utilizarea echipamentelor disponibile la întreprindere, precum și luarea în considerare în acest proiect cerintele documentatiei normative si tehnice in vigoare la intreprindere - producator; identificarea echipamentelor noi necesare producerii produselor (justificarea dezvoltarii sau achizitiei); dezvoltarea suportului metrologic (selectarea metodelor si mijloacelor de masurare); f) producerea și testarea machetelor materiale și (sau) elaborarea și analiza machetelor electronice”; g) evaluarea produsului în raport cu conformitatea acestuia cu cerințele economice, estetice tehnice; h) evaluarea posibilității de transport, depozitare și instalare a produsului la locul de utilizare; i) evaluarea datelor operaționale ale produsului (interschimbabilitatea, ușurința întreținerii, mentenabilitatea, rezistența la influențele mediului, capacitatea de a eliminarea rapidă a defecțiunilor, controlul calității produsului, disponibilitatea instrumentelor de control stare tehnica etc.); j) finalizarea aplicațiilor pentru dezvoltarea și fabricarea de noi produse (inclusiv instrumente de măsură) și materiale utilizate în produsul în curs de dezvoltare; k) luarea de măsuri pentru asigurarea nivelului de standardizare și unificare a produsului specificat în termenii de referință; l) verificarea purității și competitivității produsului, depunerea cererilor de invenție; m) identificarea gamei de produse achiziționate, coordonarea utilizării produselor achiziționate; o) coordonarea dimensiunilor de gabarit, de instalare și de legătură cu clientul sau consumatorul principal; o) evaluarea nivelului tehnic și a calității produsului; p) elaborarea desenelor de unități și piese de asamblare, dacă aceasta este cauzată de necesitatea de a accelera emiterea unei sarcini pentru dezvoltarea echipamentelor specializate pentru fabricarea acestora; c) verificarea conformității deciziilor luate cu cerințele de siguranță; și salubritate industrială, documentație de dezvoltare și de lucru, suplimentar și (sau) clarificarea lucrării prevăzute de caietul de sarcini, propunerea tehnică și proiectul de proiect, suplimentar, Rev. Nr. 4). t) pregătirea propunerilor de utilizare a software-ului și a suportului informațional pentru sistemele automatizate în elaborarea documentației de proiectare de lucru (introdus suplimentar, amendamentul nr. 5).