SRL „Documentația tehnică. Aplicarea standardelor de stat în proiectarea sistemelor informatice

Introducere

În acest standard, termenii sunt aranjați într-o ordine sistematică care reflectă sistemul de concepte din domeniul schimbului electronic de informații. Termenii sunt grupați în subsecțiuni care combină mai mulți termeni legați tematic.

Există un termen standardizat pentru fiecare concept.

Termenii standardizați sunt cu caractere aldine, formele lor scurte reprezentate de abreviere sunt în font deschis, iar sinonimele sunt în caractere italice între paranteze.

O parte dintr-un termen verbos care poate fi omis în forma sa scurtă este afișată în paranteze cu font deschis.

Între paranteze drepte după definiție se află desemnarea standardului în conformitate cu care este dată definiția termenului introdus.

În unele cazuri, după termen sunt date (în paranteze drepte) clarificările necesare asupra termenului definit.

În corpul acestui standard, termenii împrumutați de la alte standarde sunt încadrați într-o casetă. Între paranteze drepte sunt referiri la aceste standarde indicând numărul de serie din bibliografie.

Următorii termeni sunt utilizați în anexele la acest standard:

Forța juridică a documentului, regulile de documentare, fluxul documentelor (GOST R 51141-98);

Relaţie sisteme deschise, model de referință de bază, nivel, nivel de prezentare, nivel de aplicație (GOST R ISO/IEC 7498-1-99);

Octet, cifră, date digitale, literă, semn, număr, informații (ISO/IEC 2382-1-93).

6.4 Tipul ElD

NOTĂ Următoarele definiții de protocol sunt echivalente în contextul acestui standard. Al doilea dintre ele este tradițional, dar prea detaliat în acest context.

document: Informații și mass-media conexe.

document: Un bloc de informații desemnat în mod unic pentru uz uman, cum ar fi un raport, o specificație, un manual sau o carte.

document: Informații structurate, destinate direct sau indirect consumului uman, care pot fi transmise, stocate, preluate și prelucrate prin aplicații instituționale.

Notă - Această definiție este folosită și în GOST R ISO/IEC 10166, GOST R ISO/IEC 10740.

document(element de documentare): informație țintită destinată unui anumit public, plasată pe un anumit mediu (de exemplu, o carte, un disc, un card de referință rapidă) într-un format specificat.

document: Un corp structurat de informații, destinat să fie perceput vizual, care poate fi schimbat ca o unitate între utilizatori și/sau sisteme.

document: O colecție de informații care este procesată ca întreg. Documentele sunt clasificate în funcție de tipurile de documente specifice.

NOTĂ În acest standard, acest termen înseamnă aproape întotdeauna (fără pierderi de precizie) un document SGML.

document electronic: Un document pe un suport care poate fi citit de mașină, care necesită tehnologie informatică pentru utilizare.

document electronic(DE): obiect informațional format din două părți:

Detalii care conțin atribute de identificare (nume, ora și locul creării, informații despre autor etc.) și o semnătură digitală electronică;

Dacă este necesar, DE poate adopta diverse forme de afișare vizuală: pe un ecran sau pe hârtie.

A.2 Model conceptual adoptat în ISO 2382-, ISO 14662, ISO/IEC 10746-1

Existența exemplelor de mai sus (dar nu exhaustive) de definiții inconsecvente ale aceluiași concept se datorează, în primul rând, faptului că fiecare dintre definițiile de mai sus se limitează la domeniul de aplicare al unui anumit standard și se concentrează pe rezolvarea o problemă particulară a fluxului de documente. Terminologia acestui standard este în concordanță cu abordările adoptate în standardele de bază pentru terminologia în domeniul IT (standarde din seria ISO 2382), schimb electronic prelucrarea datelor (ISO 14662) și a informațiilor în sisteme distribuite(Standarde din seria ISO/IEC 10746).

Adoptat în aceste standarde abordare modernă la specificația IT se bazează pe separarea a două aspecte diferite ale fenomenelor: social (în acest caz, scop, informație, document etc.) și tehnologic (în acest caz, media, format, date etc.). Standardele stabilesc reguli pentru a asigura armonizarea problemelor legate de aspectele sociale managementul documentelor electronice(informații comerciale, contracte, acorduri și reguli adoptate între organizații, inclusiv probleme de confidențialitate, fiabilitate etc.) și problemele IT în sine ( funcţionalitate, interfețe de serviciu, protocoale etc.).

Conceptele introduse în acest standard reflectă natura socială a conceptului de „document” și fac posibilă conectarea documentului cu implementarea acestuia prin metode IT bazate pe standardele din seria ISO 14662 și ISO/IEC 10746.

Anexa B

Un document poate exista sub forma unui obiect sau proces material care acționează ca intermediar al interacțiunii informaționale.

Împărțirea documentelor în analogic, discret și electronic este determinată de tehnologiile utilizate. Diferența dintre ele este o diferență în mediul existenței și, prin urmare, în forma existenței și reprezentării lor. Mai mult, același document, indiferent de forma sa, reflectă același lucru relatii socialeși îndeplinește aceleași funcții sociale.

Notă - În unele cazuri, cerințele pentru un document limitează posibilele forme de existență a documentului. De exemplu, o bancnotă poate exista doar sub formă de hârtie (un document analog) și într-un singur exemplar.

Un document analogic este un obiect al unui mediu analogic. De exemplu, un document text tradițional pe hârtie este clasificat ca un document analog. Conceptul de A&D include toate formele tradiționale de prezentare a documentelor pe suport analogic: hârtie, fotografie și film etc. Forma analogică de reprezentare poate fi convertită în formă discretă folosind digitizarea (termenul).

Conceptul de „document electronic” se referă la prelucrarea datelor folosind IT. Trăsătură caracteristică IT este transformarea datelor prelucrate dintr-o formă de reprezentare (implementare, termen) în alta și, eventual, existența simultană a mai multor reprezentări echivalente ale acelorași date. Principala metodă de prelucrare a datelor în IT este prelucrare digitală. Un document electronic în formă digitală este un document discret.

Datorită legilor mediului electronic, datele electronice pot exista în acest mediu doar ca un set de implementări echivalente, fiecare dintre ele putând fi transformată în alta pe baza unor reguli formale și toate afișează aceleași informații. Identificarea ElD, i.e. set de implementări echivalente, este posibil pe baza oricărui subset, inclusiv a unei implementări.

Orice lucru cu un document electronic este o transformare a unei implementări în alta, iar mai multe implementări pot exista simultan. De exemplu, la redarea unui câmp stocat într-un fișier de pe disc pe un ecran de monitor, există cel puțin două implementări simultan: fișierul de pe disc și imaginea de pe ecran. În plus, în funcție de arhitectura hardware și software, pot exista: un fișier în memorie cu acces aleator computer, fișier în memoria unui dispozitiv video, fișier în memoria unei unități de disc, fluxuri de date în canale care se conectează diferite dispozitive, etc. Toate aceste implementări sunt echivalente, deoarece reprezintă același document. Proprietățile acestor implementări, relațiile cu mediul de existență și regulile de transformare a acestora unele în altele sunt determinate de legile mediului electronic.

Așa cum în sectorul eficienței documentelor există cerințe pentru document, la fel și în sectorul eficienței datelor electronice există cerințe pentru implementarea datelor electronice în medii electronice și digitale. Specificul cerințelor pentru (implementarea) documentului electronic în raport cu cerințele generale pentru document în sectorul său de eficacitate este determinat de legile mediului de existență a acestuia.

Acestea din urmă, în special, stabilesc că, în mediul electronic, datele electronice pot exista doar sub forma multor implementări interconectate. Interconectarea implementărilor înseamnă că o implementare poate fi obținută dintr-o alta ca rezultat al unei transformări definite formal. Fiecare dintre aceste implementări poate exista doar într-o parte a mediului electronic. Legile acestui mediu stabilesc restricții cu privire la alegerea sectorului admisibil al eficacității implementării, care este un subsector al eficacității eD.

Dintre implementări, se evidențiază un subset de reproduceri datorită semnificației lor speciale pentru o persoană - posibilitatea percepției lor directe. În exemplul de mai sus, doar implementarea ElD pe ecranul monitorului este disponibilă pentru percepție directă și este reprezentativă pentru întregul set de implementări ale acestui ElD, inclusiv. fișier pe discul computerului dvs.

Sectorul de eficacitate EL este o uniune de sectoare a eficacității implementărilor sale, în fiecare dintre acestea fiind stabilite reguli uniforme (în cadrul sectorului) de prelucrare și conversie a datelor.

Sectorul de eficiență EL este împărțit în subsectoare „vertical” și „orizontal”. Diviziunea verticală este determinată de nivelurile modelului VOS (GOST R ISO/IEC 7498-1), care corespund, în special, la diferite grade de detaliere în descrierea mediului electronic. Diviziunea orizontală este determinată de prezență zone diferite procesarea datelor. Zonele de prelucrare a datelor sunt dispozitive individuale pentru procesarea, stocarea și transmiterea datelor. Realizările există în celule separate rezultate din această diviziune. Transformarea unei implementări în alta, situată într-o celulă adiacentă, se realizează pe baza unor reguli formale (algoritmi) și este reversibilă.

Notă - Mai multe dispozitive pot fi considerate ca un întreg, astfel cum sunt combinate într-o zonă de procesare, a cărei structură internă nu este semnificativă pentru această considerație. În special, orice sistem de prelucrare a datelor este o astfel de zonă constând din mai multe dispozitive; la acel nivel de considerare la care detaliile structurii interne a sistemului nu prezintă interes, sistemul este considerat ca un întreg unic.

Într-un mediu social, un document trebuie să aibă proprietățile de mai sus care sunt necesare pentru ca documentul să-l execute. rol social. Prezența acestor proprietăți într-un document se formulează sub formă de cerințe ale mediului social, iar îndeplinirea acestor cerințe trebuie asigurată prin mijloace tehnice. Cerințele pentru implementarea unui document sunt derivate din legile mediului tehnologic și cerințele sociale pentru document.

Fixitatea unui document înseamnă că mesajul pe care îl transmite fixează un fapt, eveniment, relație, iar sensul acestui mesaj nu depinde de implementarea materială (în mod informal, sensul documentului este „fix”). Pentru AnD, fixitatea înseamnă, de exemplu, că conținutul (sensul) legii nu trebuie să depindă de execuția tipografică. Pentru ELD, fixitatea înseamnă, de exemplu, că conținutul (sensul) legii nu ar trebui să depindă de implementarea acesteia - sub forma unui fișier pe un disc, a unei imagini pe un monitor sau a unui flux de semnale într-o rețea.

Astfel, fixitatea documentului nu înseamnă fixitatea formularului de prezentare, ci trebuie asigurată de formularul(ele) de prezentare selectat(e) (secțiunile , - ) și procesele de prelucrare corespunzătoare (secțiunile , și ). În mediul electronic, cerința socială a fixității există sub forma unei cerințe formale de a păstra un anumit invariant în timpul lucrului cu un document (care depinde de tipul documentului și de tehnologia utilizată).

Accesibilitatea unui document implică faptul că acesta poate conține elemente (parametri) individuale ale căror valori pot fi măsurate. Pentru eD, disponibilitatea se bazează pe utilizare formate stabilite(secțiunile , - ), care definesc structura implementărilor specifice.

Valorile parametrilor incluși în cerințele de integritate pot fi specificate în documentele de reglementare sau pot fi obținute într-un mod dat din valorile unor parametri de prezentare a documentului la un moment anterior din timp. Pentru ELD, integritatea este asigurată în funcție de aplicație metode stabilite procesarea implementărilor, de ex. bazată pe tehnologie care conservă parametri specificati neschimbat (secțiuni și ).

Notă - Cerințele pentru parametrii de implementare a datelor electronice, respectarea cărora asigură disponibilitatea și integritatea documentului, depind de cerințele sociale pentru document. În cel mai simplu caz, poate fi suficient să obțineți o reproducere vizuală a documentului electronic (accesibilitate) și să verificați vizual dacă textul rezultat se potrivește cu un anumit eșantion (integritate). Cu cerințe sociale mai stricte pentru un document, este necesar să se asigure, de exemplu, disponibilitatea și accesibilitatea atributelor de securitate și conformitatea acestora cu cerințele tehnice stabilite.

Legitimitatea unui document înseamnă că atunci când lucrați cu acesta, numai operațiuni valide au fost utilizate într-o secvență acceptabilă. Legitimitatea ELD este asigurată prin metode de protecție.

Abilitatea de a demonstra un document este necesară, iar demonstrația reală este condiție suficientă pentru ca documentul să-l îndeplinească functie sociala. Locul, ora și alte condiții de desfășurare a demonstrației nu pot fi stabilite în prealabil, dar trebuie determinate în momentul demonstrației propriu-zise cu o acuratețe care să asigure posibilitatea demonstrației repetate în condiții similare. Parametrii (caracteristicile) care pot fi măsurați pentru o anumită implementare și metodele de măsurare a acestora trebuie stabilite în prealabil pentru acest tip de implementare.

Tipul documentului este determinat de scopul său funcțional, care determină și cerințele tehnologice pentru implementarea materială a documentului. În special, conceptele „copie a unui document”, „copie certificată a unui document”, „duplicat a unui document” conform GOST R 51141 se referă la scopul funcțional al unui document în mediul social (prin conceptul „ forță juridică"), nu conțin indicații de implementare tehnică și ar trebui să fie considerate definiții ale tipurilor de documente. În cazul unui document analogic (de hârtie), crearea unui nou tip de document („copie”) coincide cu procedura tehnologică de copiere. În cazul datelor electronice, datorită specificului prelucrării datelor în mediul electronic, un document există sub forma unui set (termen) de implementări echivalente (termenul 5.3.1), și orice lucrare cu un document, incl. vizualizarea lui pe ecranul de afișare constă în crearea continuă a acestor implementări (), adică. în „copierea” unui document. În acest caz, operațiunea tehnologică de copiere nu conduce la crearea unui nou tip de document („copie”), ci doar la crearea unei noi implementări echivalente cu orice altă implementare a documentului electronic.

În mediul digital, informația este reprezentată ca un șir de biți - un set de zerouri și unu. Înțelegerea acestei informații (interpretarea ei) aparține sferei activității umane. În mediul digital (și electronic) în sine, nu există o „înțelegere” a informațiilor. În acest mediu, doar regulile formale pentru prelucrarea datelor pot fi specificate (de către oameni).

În caz contrar, datele pot fi definite ca implementarea datelor electronice în mediul digital. Datele constau dintr-o succesiune ordonată de blocuri - elemente. Pentru fiecare element trebuie specificat tipul acestuia, permițând interpretarea (înțelesul) datelor. Tipul unui element de date nu este o proprietate a datelor, ci este prescris de oameni în standarde, specificații și alte documente tehnice. Același element de date poate fi interpretat căi diferite, adică poate fi prescris mai multe tipuri diferite. De exemplu, o secvență de 16 biți poate fi interpretată ca cod binar, octal, zecimal, hexazecimal, caracter (litera) sau cod de instrucțiuni de mașină. Fiecare dintre aceste interpretări are propriul mod de a reproduce datele, propriul set de operații și valori permise. Tipul de date poate fi utilizat pentru a identifica hardware-ul, software-ul sau alte echipamente necesare pentru reproducerea sau operarea pe acele date.

O parte a interpretării datelor, reprezentată sub formă de reguli formale, poate fi introdusă într-un computer și, de asemenea, prezentată sub forma unui algoritm formalizat. Acest lucru nu înseamnă că computerul va „înțelege” informațiile. Va executa doar comenzile date.

Notă - Regulile de prelucrare a datelor (algoritmul) în sine sunt informații care în mediul digital pot fi reprezentate doar sub formă de date.

Reproducerea datelor sub forma unui șir de biți este incomod pentru percepția umană. Prin urmare, datele sunt de obicei reproduse într-o formă diferită, mai ușor de citit. Acest tip este determinat de tipul de date care este prescris pentru un anumit element de date: literă, număr, text, imagine, înregistrare audio etc.

Notă - Reproducerea este o metodă de interpretare a datelor. De obicei, această parte a interpretării este lăsată pe seama computerului.

Exemplu - Se poate preciza că un anumit element de date (sub formă de zerouri și unu) trebuie interpretat ca dată. Interpretarea acestui element de date de către un computer poate însemna că un program a fost introdus în computer pentru a transforma datele astfel încât să poată fi afișate pe un ecran într-o formă care poate fi înțeleasă de un om. În caz contrar, în computer poate fi introdus un program care verifică valoarea unui element de date și, în anumite condiții (egal cu o valoare specificată sau depășind valoarea stabilită) transferă controlul către alt program.

Tipul unui element de date compus este o succesiune ordonată a tipurilor subelementelor sale.

Textul este o reprezentare familiară a informațiilor într-un mediu analog pentru oameni. Interpretarea acestei reprezentări se bazează pe cunoştinţele cititorului: pentru a citi un text trebuie, cel puţin, să se cunoască limba în care este scris. Pentru a înțelege un text, trebuie să aveți cunoștințe în domeniul la care se referă.

Textul în înțelegerea umană obișnuită este de puțin folos pentru prelucrare automată programe de calculator. Pentru a program de calculator ar putea interpreta și procesa textul în consecință, acesta trebuie să conțină semne speciale, invizibile pentru om în timpul reproducerii „normale”, care sunt numite marcajele(termen).

Tipuri de date definite în standarde diferite(cifră, literă, semn, număr, imagine, date audio, date video, date audio-vizuale) sunt o prescripție pentru interpretarea aceleiași reprezentări de bază a datelor într-un mediu digital - șirul de biți. Formatul de date specifică metoda de interpretare a șirului de biți, specificând detalii precum dimensiunile câmpurilor individuale, metode de vizualizare (în cazul general, reproducere) a datelor etc.

Definiția unui atribut al unui obiect media electronic sau digital ar trebui să conțină, de regulă, numele atributului, formatul acestuia (sau, cel puțin, tipul acestuia).

Atributele serviciului nu sunt neapărat elemente de date ELD. De exemplu, atributele „nume fișier”, „data creării fișierului”, „dimensiune fișier” etc., care caracterizează o implementare specifică a documentului electronic, nu trebuie neapărat să fie prezente în datele documentului.

Diferența dintre atributele de referință și cele de serviciu este fundamentală: atributele de referință descriu un document ca obiect al mediului social, atributele de serviciu descriu implementarea unui document ca obiect sau proces material într-un mediu specific de existență. De exemplu, atributul „data creării documentului” se referă la un document, caracterizează momentul apariției documentului, indiferent de forma în care documentul a fost creat inițial și există în prezent și trebuie înțeles în acest sens, indiferent de implementarea tehnică. . Pe de altă parte, atributul „filename” este pur tehnic, interpretarea sa este dependentă de implementare (de exemplu, diferite sisteme de operare pot gestiona „filename” diferit) și, prin urmare, este un atribut de serviciu. În consecință, „numele fișierului”, ca orice alt atribut de serviciu, nu poate fi un atribut de document, dar „data creării documentului” poate fi.

GOST 34.601-90

Grupa P87

STANDARD INTERSTATAL

TEHNOLOGIA DE INFORMAȚIE

Set de standarde pentru sisteme automate

SISTEME AUTOMATICE

ETAPE DE CREAȚIE

Tehnologia de informație. Set de standarde pentru sisteme automate. Sisteme automatizate. Etape de dezvoltare

MKS 35.080
OKSTU 0034

Data introducerii 1992-01-01

DATE INFORMAȚII

1. DEZVOLTAT ȘI INTRODUS de Comitetul de Stat al URSS pentru managementul calității produselor și standarde

2. APROBAT ȘI INTRAT ÎN VIGOARE prin Rezoluția Comitetului de Stat al URSS pentru Managementul Calității Produselor și Standarde din 29 decembrie 1990 N 3469

3. ÎNLOC GOST 24.601-86, GOST 24.602-86

4. DOCUMENTE REGLEMENTARE ŞI TEHNICE DE REFERINŢĂ


	Număr articol, cerere
GOST 19.101-77	Anexa 1
GOST 34.201-89	Anexa 1

6*. REEDITARE. iulie 2009
________________
*Numerotarea corespunde cu originalul. - Nota producătorului bazei de date.

Acest standard se aplică sistemelor automate (AS) utilizate în tipuri variate activități (cercetare, proiectare, management etc.), inclusiv combinațiile acestora, create în organizații, asociații și întreprinderi (denumite în continuare organizații).

Standardul stabilește etapele și etapele creării unui AS.

Anexa 1 prezintă conținutul lucrării în fiecare etapă.

1. DISPOZIȚII GENERALE

1.1. Procesul de creare a unui AS este un set de lucrări ordonate în timp, interconectate, combinate în etape și faze, a căror implementare este necesară și suficientă pentru a crea un AS care să îndeplinească cerințele specificate.

1.2. Etapele și fazele creării unui AS se disting ca părți ale procesului de creare din motive de planificare rațională și organizare a muncii care se încheie cu un rezultat dat.

1.3. Lucrările privind dezvoltarea AS se desfășoară în funcție de etapele și etapele utilizate pentru crearea AS.

1.4. Compoziția și regulile de realizare a lucrărilor la etapele și etapele stabilite de prezentul standard sunt determinate în documentația relevantă a organizațiilor implicate în crearea unor tipuri specifice de centrale nucleare.

Lista organizațiilor implicate în crearea centralelor nucleare este prezentată în Anexa 2.

2. ETAPE ŞI ETAPE DE CREARE A AS

2.1. Etapele și etapele creării unui AS sunt prezentate în general în tabel.


	Etapele muncii
1. Formarea cerințelor pentru vorbitori	1.1. Inspecția instalației și justificarea necesității creării unei centrale nucleare
	1.2. Formarea cerințelor utilizatorilor pentru difuzoare
	1.3. Întocmirea unui raport asupra lucrărilor efectuate și a unei cereri pentru dezvoltarea unui AS (specificații tactice și tehnice)
2. Dezvoltarea conceptului AC	2.1. Studiind obiectul
	2.2. Efectuarea lucrărilor de cercetare necesare
	2.3. Dezvoltarea opțiunilor de concept AC și selectarea unei opțiuni de concept AC care satisface cerințele utilizatorului
	2.4. Întocmirea unui proces-verbal asupra lucrărilor efectuate
3. Termeni de referință	3.1. Elaborarea și aprobarea specificațiilor tehnice pentru realizarea centralelor nucleare
4. Proiect de proiect	4.1. Dezvoltarea de soluții preliminare de proiectare pentru sistem și părțile sale
	4.2. Dezvoltarea documentației pentru sistemul de difuzoare și părțile sale
5. Proiectare tehnică	5.1. Dezvoltarea de soluții de proiectare pentru sistem și piesele sale
	5.2. Dezvoltarea documentației pentru sistemul de difuzoare și părțile sale
	5.3. Elaborarea și executarea documentației pentru furnizarea produselor pentru completarea CNE și (sau) cerințe tehnice (specificații tehnice) pentru dezvoltarea acestora
	5.4. Dezvoltarea sarcinilor de proiectare în părțile adiacente ale proiectului unității de automatizare
6. Documentație de lucru	6.1. Elaborarea documentației de lucru pentru sistem și părțile sale
	6.2. Dezvoltarea sau adaptarea programelor
7. Punerea în funcţiune	7.1. Pregatirea obiectului de automatizare pentru punerea in functiune a CNE
	7.2. Instruirea personalului
	7.3. Set complet de difuzoare furnizate cu produse (software și hardware, complexe software și hardware, produse de informare)
	7.4. Lucrari de constructii si montaj
	7.5. Lucrări de punere în funcțiune
	7.6. Efectuarea de teste preliminare
	7.7. Efectuarea operațiunii de probă
	7.8. Efectuarea testelor de acceptare
8. Suport AC	8.1. Efectuarea lucrărilor în conformitate cu obligațiile de garanție
	8.2. Service post-garanție

2.2. Etapele și reperele realizate de organizațiile care participă la crearea centralelor nucleare sunt stabilite în contracte și specificații tehnice bazate pe acest standard.

Este permisă excluderea etapei „Proiectare schiță” și etapelor individuale de lucru în toate etapele, combinarea etapelor „Proiectare tehnică” și „Documentare de lucru” într-o singură etapă de „Proiectare tehnică detaliată”. În funcție de specificul AS care se creează și de condițiile pentru crearea acestora, este permisă efectuarea unor etape individuale de lucru înainte de finalizarea etapelor anterioare, execuția paralelă a etapelor de lucru sau includerea de noi etape de lucru.

ANEXA 1 (pentru referință). CONȚINUTUL LUCRĂRII

ANEXA 1
informație

1. La etapa 1.1 „Inspecția instalației și justificarea necesității creării unei CNE”, în cazul general, se efectuează următoarele:

- colectarea datelor despre obiectul automatizării și tipurile de activități desfășurate;

- evaluarea calitatii functionarii instalatiei si a tipurilor de activitati desfasurate, identificarea problemelor ce pot fi rezolvate prin automatizare;

- evaluarea (tehnică, economică, socială etc.) a fezabilității creării unei centrale nucleare.

2. La etapa 1.2 „Formarea cerințelor utilizatorilor pentru difuzoare” se efectuează următoarele:

- pregătirea datelor inițiale pentru formarea cerințelor pentru sistemul automatizat (caracteristicile obiectului de automatizare, descrierea cerințelor pentru sistem, limitări ale costurilor acceptabile pentru dezvoltare, punere în funcțiune și exploatare, efectul așteptat de la sistem, condițiile pentru crearea și funcționarea sistemului);

- formularea și executarea cerințelor utilizatorilor pentru difuzoare.

3. La etapa 1.3 „Completarea unui raport cu privire la lucrările efectuate și a unei cereri pentru dezvoltarea unui AS (specificații tactice și tehnice)”, un raport cu privire la lucrările efectuate în această etapă și o cerere pentru dezvoltarea unui AS (tactica și specificațiile tehnice) sau un alt document care îl înlocuiește sunt completate cu conținut similar.

4. La etapele 2.1 „Studiul obiectului” și 2.2 „Efectuarea lucrărilor de cercetare necesare”, organizația de dezvoltare realizează un studiu detaliat al obiectului de automatizare și lucrările de cercetare necesare (C&D) legate de găsirea modalităților și evaluarea posibilității de implementarea cerințelor utilizatorilor, întocmește și aprobă rapoarte de cercetare.

5. La etapa 2.3 „Elaborarea opțiunilor pentru conceptul AS și selectarea unei opțiuni pentru conceptul AS care să îndeplinească cerințele utilizatorului”, în cazul general, dezvoltarea opțiuni alternative conceptele AS în curs de creare și planuri pentru implementarea acestora; evaluare resursele necesare pentru implementarea și funcționarea acestora; evaluarea avantajelor și dezavantajelor fiecărei opțiuni; compararea cerințelor utilizatorilor și a caracteristicilor sistemului propus și selectarea opțiunii optime; stabilirea procedurii de evaluare a calitatii si conditiilor de acceptare a sistemului; evaluarea efectelor obţinute din sistem.

6. La etapa 2.4 „Întocmirea unui raport asupra lucrărilor efectuate”, întocmește și întocmește un raport care să cuprindă o descriere a lucrărilor efectuate la etapă, o descriere și o justificare a versiunii propuse a conceptului de sistem.

7. La etapa 3.1 „Elaborarea și aprobarea specificațiilor tehnice pentru realizarea unei centrale nucleare”, elaborarea, execuția, coordonarea și aprobarea specificațiilor tehnice pentru centrala nucleară și, dacă este cazul, specificațiile tehnice pentru părți ale centralei nucleare. centrale electrice sunt executate.

8. La etapa 4.1 „Elaborarea soluțiilor preliminare de proiectare pentru sistem și părțile sale” se determină: funcțiile AS; funcțiile subsistemelor, scopurile și efectele acestora; alcătuirea complexelor de sarcini și a sarcinilor individuale; concepte baza de informatii, structura sa mărită; funcții ale sistemului de management al bazelor de date; compus sistem de calcul; funcțiile și parametrii software-ului de bază.

9. La etapa 5.1 „Elaborarea soluțiilor de proiectare pentru sistem și părțile sale”, acestea asigură dezvoltarea de soluții generale pentru sistem și părțile sale, structura funcțional-algoritmică a sistemului, funcțiile personalului și structura organizatorică, structura mijloacelor tehnice, algoritmi de rezolvare a problemelor și limbajele utilizate, privind organizarea și menținerea unei baze de informații, a unui sistem de clasificare și codificare a informațiilor, pe software.

10. La etapele 4.2 și 5.2 „Elaborarea documentației pentru CNE și părțile sale”, elaborarea, execuția, coordonarea și aprobarea documentației se efectuează în măsura în care este necesar pentru a descrie setul complet de decizii de proiectare luate și suficient pentru continuarea implementarea lucrărilor de creare a CNE. Tipuri de documente - conform GOST 34.201.

11. La etapa 5.3 „Elaborarea și executarea documentației pentru furnizarea produselor pentru completarea CNE și (sau) cerințe tehnice (specificații tehnice) pentru dezvoltarea acestora” se realizează următoarele: pregătirea și execuția documentației pentru furnizarea produselor pt. finalizarea centralelor nucleare; determinarea cerințelor tehnice și întocmirea specificațiilor tehnice pentru dezvoltarea produselor care nu sunt produse în serie.

12. La etapa 5.4 „Elaborarea sarcinilor de proiectare în părțile adiacente ale proiectului instalației de automatizare” se realizează elaborarea, execuția, coordonarea și aprobarea sarcinilor de proiectare în părțile adiacente ale proiectului instalației de automatizare pentru realizarea construcțiilor, electrice, sanitare. și alte lucrări pregătitoare legate de crearea AS.

13. La etapa 6.1 „Elaborarea documentației de lucru pentru sistem și părțile sale”, se elaborează documentația de lucru care conține toate informațiile necesare și suficiente pentru a asigura implementarea lucrărilor de punere în funcțiune și funcționare a CNE, precum și pentru menținerea acestuia. nivelul caracteristicilor operaționale (calității) sistemului în conformitate cu deciziile de proiectare adoptate, execuția, coordonarea și aprobarea acestuia. Tipuri de documente - conform GOST 34.201.

14. La etapa 6.2 „Dezvoltarea sau adaptarea programelor”, dezvoltarea programelor și instrumentelor software ale sistemului, selectarea, adaptarea și (sau) conectarea instrumentelor software achiziționate, dezvoltarea documentația programuluiîn conformitate cu GOST 19.101.

15. La etapa 7.1 „Pregătirea obiectului de automatizare pentru punerea în funcțiune a instalației”, se lucrează la pregătirea organizatorică a obiectului de automatizare pentru punerea în funcțiune a instalației, inclusiv: implementarea soluțiilor de proiectare pentru structura organizatorică a instalației. plantă; furnizarea departamentelor unității de management cu materiale didactice și metodologice; implementarea clasificatoarelor de informații.

16. La etapa 7.2 „Instruirea personalului”, personalul este instruit și se verifică capacitatea acestuia de a asigura funcționarea instalației.

17. La etapa „Completarea difuzoarelor cu produse furnizate” asigură primirea componentelor de producție în serie și individuale, materialelor și produselor de instalare. Se efectuează controlul de calitate la intrare.

18. La etapa 7.4 „Lucrări de construcție și instalare” se efectuează: lucrări de construcție a clădirilor (incintelor) specializate pentru găzduirea echipamentelor tehnice și a personalului CNE; constructie canale prin cablu; efectuarea de lucrări la instalarea echipamentelor tehnice și a liniilor de comunicație; testarea echipamentelor tehnice instalate; livrarea echipamentelor tehnice pentru punerea în funcțiune.

19. La etapa 7.5 „Dare în funcțiune”, efectuează reglarea autonomă a hardware-ului și software-ului, încărcarea informațiilor în baza de date și verificarea sistemului de întreținere a acesteia; configurarea completă a tuturor instrumentelor de sistem.

20. La etapa 7.6 „Efectuarea testelor preliminare” se efectuează următoarele:

- teste ale AS de operabilitate si conformitate cu specificatiile tehnice in conformitate cu programul si metodologia de incercari preliminare;

- depanarea si efectuarea de modificari la documentatia CNE, inclusiv documentatia operationala in conformitate cu raportul de testare;

- intocmirea certificatului de acceptare a CNE pentru functionare de proba.

21. La etapa 7.7 „Efectuarea operațiunii de probă” se efectuează: funcționarea de probă a CNE; analiza rezultatelor exploatării de probă a CNE; modificarea (dacă este necesar) a software-ului AS; ajustarea suplimentară (dacă este necesar) a echipamentelor tehnice CNE; executarea unui certificat de finalizare a operațiunii de probă.

22. La etapa 7.8 „Efectuarea testelor de acceptare” se efectuează următoarele:

Teste de conformitate cu specificațiile tehnice în conformitate cu programul și metodologia de testare a recepției;

- analiza rezultatelor testelor CNE și eliminarea deficiențelor identificate în timpul testării;

- executarea unui act de acceptare a CNE pentru funcționare permanentă.

23. La etapa 8.1 „Efectuarea lucrărilor în conformitate cu obligațiile de garanție” se efectuează lucrări pentru eliminarea deficiențelor identificate în timpul funcționării CNE în perioadele de garanție stabilite, precum și pentru efectuarea modificărilor necesare în documentația pentru CNE.

24. La etapa 8.2 „Service post-garanție” se lucrează la:

- analiza functionarii sistemului;

- identificarea abaterilor caracteristicilor efective de exploatare ale CNE de la valorile de proiectare;

- stabilirea cauzelor acestor abateri;

- eliminarea deficiențelor identificate și asigurarea stabilității caracteristicilor operaționale a CNE;

- efectuarea modificărilor necesare în documentația pentru vorbitori.

ANEXA 2 (pentru referință). LISTA ORGANIZAȚILOR PARTICIPANTE LA CREAREA AU

ANEXA 2
informație

1. Organizația client (utilizator) pentru care se creează CNE și care asigură finanțarea, acceptarea lucrărilor și funcționarea CNE, precum și execuția lucrări individuale privind crearea AS;

2. O organizație de dezvoltare care desfășoară lucrări la crearea AS, oferind clientului un set de servicii științifice și tehnice în diferite etape și etape de creare, precum și dezvoltarea și furnizarea diverselor software și hardware pentru AS;

3. O organizație furnizor care produce și furnizează software și hardware la comanda dezvoltatorului sau clientului;

4. Organizație-proiectant general al instalației de automatizare;

5. Organizații-proiectați diferite părți ale proiectului instalației de automatizare pentru realizarea lucrărilor de construcție, electrice, sanitare și alte lucrări pregătitoare legate de crearea centralei nucleare;

6. Construcție, instalare, punere în funcțiune și alte organizații.

Note:

1. În funcție de condițiile de creare a CNE, sunt posibile diferite combinații de funcții ale clientului, dezvoltatorului, furnizorului și altor organizații implicate în crearea CNE.

2. Etapele și fazele lucrării pe care le efectuează pentru crearea AS sunt determinate pe baza acestui standard.

Textul documentului electronic
pregătit de Kodeks JSC și verificat cu:
publicație oficială
M.: Standartinform, 2009

standardele în IT au parcurs un drum lung în ultimii ani și pentru a arăta cât de mult standardele moderne orientate spre proces sunt fundamental diferite de cele tradiționale, voi începe cu probabil cel mai faimos standard din țara noastră, GOST 34, care încă mai reprezintă pentru mulți manageri. (și chiar specialiști IT) conceptul de standard IT în general. Voi încerca, fără a intra prea mult în detalii, să analizez practica aplicării sale, precum și perspectivele de utilizare ca sursă a proceselor de management IT de referință.

Cel de-al treizeci și patrulea GOST din jargonul specialiștilor IT este un set de standarde interconectate care au un număr care începe cu 34: GOST 34.602-89, 34.003-90, 34.603-92, 34.201-89, 34.601-90, 8-34. 34.320-96, 34.321-96, precum și documentul de orientare RD 50-34.698-90 și două standarde de sine stătătoare legate de tema de înaltă specialitate a protecției criptografice - GOST 34.10 -01 și GOST 34.11-94.

Toate aceste standarde au apărut la sfârșitul anilor 80 - începutul anilor 90 (anul emiterii este indicat prin numărul de după cratima), înlocuind sau completând standardele anterioare din seria a 19-a și a 24-a.

Pentru a înțelege și a evalua logica conținută în familia GOST 34, să analizăm mai detaliat conținutul standardelor sale constitutive. GOST 34.320-96 „Concepte și terminologie pentru o diagramă conceptuală și o bază de informații”, GOST 34.321-96, destinat specialiștilor IT. „Model de referință pentru gestionarea datelor”, GOST 34.10 -01 „Criptografic protejarea datelor. Procese de generare și verificare electronică semnatura digitala" și GOST 34.11-94 "Criptografic protejarea datelor. Nu voi lua în considerare funcția de hashing, deoarece acestea nu sunt destinate managerilor, ci specialiștilor tehnici. Următoarele standarde ne interesează:

GOST 34.201-89. „Tipurile, completitudinea și desemnarea documentelor la crearea sistemelor automate”;
GOST 34.003-90 „Termeni și definiții”;
GOST 34.602-89 „Specificații tehnice pentru creare sistem automatizat";
GOST 34.603-92 „Tipuri de testare a sistemelor automate”;
GOST 34.601-90 „Sisteme automatizate. Etapele creației”;
Document îndrumător RD 50-34.698-90 „Sisteme automatizate. Cerințe pentru conținutul documentelor”.

GOST 34.003-90, pe lângă faptul că conține numeroase erori, este complet depășit și și-a pierdut relevanța, așa că nu voi vorbi despre asta. Astfel, ceea ce urmează este considerat patru ultimul document.

Standard GOST 34.201-89

Standard învechit, dar parțial utilizabil (GOST 34, 1989a). Stabilește conformitatea documentelor cu etapele de creare a AS 1 AS este un sistem automatizat, adică un sistem informatic dezvoltat sau implementat la o anumită întreprindere., descris în GOST 24.601 (înlocuit ulterior cu GOST 34.601). Pe baza compoziției documentelor și a etapelor proiectului, se poate urmări originea standardului din practica de construcție. Evident, natura proiectului de construcție și activitățile de creare a unui sistem informațional i-au condus pe autorii standardului la ideea extinderii formelor de bază de organizare a proiectelor de construcție la proiecte de creare. sisteme de informare. Parțial, acest lucru s-a dovedit a fi convenabil - astfel de documente menționate în standard ca „ Sarcina tehnică", " Proiectare preliminară ", " Proiect tehnic„, „Instrucțiuni” (pentru utilizator), „Program și metode de testare” au devenit ferm stabilite în practica creării de sisteme. Pe de altă parte, „Lista mediilor de stocare a computerelor”, „Directorul bazei de date” sau „Lista cu originalul deținătorii” este puțin probabil să aibă sens acum. Standardul include și elemente ale practicii muncii de birou sub forma regulilor de codificare a documentelor.

Pe scurt, cu o abordare „creativă”, poate servi în continuare, mai ales în acele organizații în care activitati ale proiectului este reglementat de standarde similare orientate spre proiect, iar compoziția documentelor de proiectare este aproape de ceea ce oferă GOST 34.201-89.

Standard GOST 34.601-90

Unul dintre cele mai utilizate standarde până acum (GOST 34, 1990), care definește etapele și etapele creării unui sistem automat. Tabelul de mai jos este esențial pentru standard.

Tabelul 2.1. Etapele și etapele creării unui sistem automatizat conform GOST 34.601-90

Etape	Etape
1. Formarea cerințelor pentru vorbitori	1.1. Inspecția instalației și justificarea necesității creării unei centrale nucleare
	1.2. Formarea cerințelor utilizatorilor pentru difuzoare
	1.3. Întocmirea unui raport asupra lucrărilor efectuate și a unei cereri pentru dezvoltarea unui AS (specificații tactice și tehnice)
2. Dezvoltarea conceptului AC	2.1. Studiind obiectul
	2.2. Efectuarea lucrărilor de cercetare necesare
	2.3. Dezvoltarea de variante ale conceptului de difuzor care să răspundă cerințelor utilizatorilor
	2.4. Întocmirea unui proces-verbal asupra lucrărilor efectuate
3. Termeni de referință	3.1 Elaborarea și aprobarea specificațiilor tehnice pentru realizarea CNE
4. Proiect de proiect	4.1. Dezvoltarea de soluții preliminare de proiectare pentru sistem și părțile sale
4. Proiect de proiect	4.2. Dezvoltarea documentației pentru sistemul de difuzoare și părțile sale
5. Proiect tehnic	5.1. Dezvoltarea de soluții de proiectare pentru sistem și piesele sale
	5.2. Dezvoltarea documentației pentru sistemul de difuzoare și părțile sale
	5.3. Elaborarea și executarea documentației pentru furnizarea produselor pentru completarea CNE și (sau) cerințe tehnice (specificații tehnice) pentru dezvoltarea acestora
	5.4. Dezvoltarea sarcinilor de proiectare în părțile adiacente ale proiectului unității de automatizare
6. Documentatie de lucru	6.1. Dezvoltare documentatie de lucru asupra sistemului și a părților sale
6. Documentatie de lucru	6.2. Dezvoltarea sau adaptarea programelor
7. Punerea în funcţiune	7.1. Pregatirea obiectului de automatizare pentru punerea in functiune a CNE
	7.2. Instruirea personalului
	7.3. Set complet de difuzoare cu produsele furnizate (software și hardware, sisteme software și hardware, produse informatice)
	7.4. Lucrari de constructii si montaj
	7.5. Lucrări de punere în funcțiune
	7.6. Efectuarea teste preliminare
	7.7. Efectuarea operațiune de probă
	7.8. Efectuarea teste de acceptare
8. Suport AC	8.1. Efectuarea lucrărilor în conformitate cu obligațiile de garanție
8. Suport AC	8.2. Service post-garanție

Aproape toate etapele enumerate sunt încă întâlnite în practica creării de sisteme informatice pentru întreprinderi și organizații. Desigur, se poate critica standardul pentru inflexibilitatea sa în ceea ce privește succesiunea și denumirile etapelor și etapelor, dar rămâne faptul că acesta a demonstrat o vitalitate excepțională, iar înțelegerea motivului pentru aceasta este mult mai importantă decât a critica dezvoltarea aproape. acum 20 de ani. Mi se pare că standardul demonstrează că se potrivește îndeaproape cu obiectivele sale. În primul rând, nu necesită cunoștințe IT și, prin urmare, este de înțeles pentru managerii obișnuiți. În al doilea rând, are o structură compactă și simplă, ceea ce permite unei persoane care nu este familiarizată cu el să se transforme rapid la viteză. În al treilea rând, este autosuficient - practic nu există referințe la documente conexe în el (cu excepția GOST 34.201). Și, în sfârșit, este practic - este imediat clar cum să-l folosești și cum să-i controlezi utilizarea.

Pe lângă tabelul de mai sus, GOST 34.601-90 conține apendicele 1 de referință cu o defalcare pas cu pas a lucrării, inclusiv o indicație a documentelor rezultate ca urmare a acestei lucrări, precum și apendicele 2 - „Lista de organizații care participă la crearea centralelor nucleare.” Aceasta sugerează o modalitate de a adapta standardul la condiții specifice: este suficient să reluați aplicațiile și veți obține un standard corporativ complet rezonabil pentru crearea IP. Și din nou, această muncă este în puterea unui manager obișnuit.

Standard GOST 34.602-89

Cerința de a „pregăti Sarcina tehnicăîn conformitate cu GOST 34.602-89", este probabil familiar tuturor celor care au participat cel puțin o dată la dezvoltarea personalizată a unui IP sau acceptarea acestuia și, într-adevăr, tuturor celor care sunt într-un fel sau altul conectați cu sistemele informaționale. Unii dezvoltatori încă consideră că este o formă bună să ne amintim pe de rost compoziția specificațiilor tehnice (TOR) în conformitate cu GOST 34.602-89 (GOST 34, 1989b).

Informații generale.
Scopul și scopurile creării (dezvoltării) sistemului.
Caracteristicile obiectelor de automatizare.
Cerințe de sistem.
Compoziția și conținutul lucrării pentru crearea sistemului.
Procedura de control si acceptare a sistemului.
Cerințe pentru compoziția și conținutul lucrării pentru pregătirea obiectului de automatizare pentru punerea în funcțiune a sistemului.
Cerințe de documentare.
Surse de dezvoltare.

Să încercăm să înțelegem motivele popularității continue a acestui standard, care a depășit deja vârsta de 20 de ani. De fapt, întregul standard este o transcriere a celor nouă puncte enumerate. Dimensiunea sa este de doar 11 pagini, dar volumul de informații Informatii utile surprinzător de mare. Dacă aruncăm arhaisme evidente, cum ar fi fondurile de algoritmi și programe care au existat cândva, se dovedește că aproape totul despre despre care vorbim, este încă pe deplin aplicabilă. Iată un exemplu al uneia dintre secțiuni.

"2.6.2. În subsecțiunea "Cerințe pentru funcții (sarcini)" îndeplinite de sistem, se indică următoarele:

pentru fiecare subsistem, o listă de funcții, sarcini sau complexe ale acestora (inclusiv cele care asigură interacțiunea unor părți ale sistemului) care urmează să fie automatizate;
la crearea unui sistem în două sau mai multe cozi - listă subsisteme funcționale, funcții individuale sau sarcini puse în aplicare în prima etapă și etapele ulterioare;

regulamente de timp pentru implementarea fiecărei funcții, sarcini (sau set de sarcini);

cerințe pentru calitatea implementării fiecărei funcții (sarcină sau set de sarcini), pentru forma de prezentare informații de ieșire, caracteristici ale preciziei și timpului de execuție necesar, cerințe pentru executarea simultană a unui grup de funcții, fiabilitatea rezultatelor;

lista și criteriile de defecțiune pentru fiecare funcție pentru care sunt specificate cerințe de fiabilitate.”

Fragmentul de mai sus demonstrează natura ierarhică a standardului: sistemul constă din subsisteme, complexe de sarcini, sarcini individuale și funcții. Cu cât sunt formulate cerințele mai precise și detaliate, cu atât rezultatul va fi mai previzibil. Cerințele pentru funcțiile de interacțiune a subsistemelor sunt special formulate (acum am spune „metode de integrare”), funcțiile sunt legate de planul de implementare a sistemului (care devine astfel și ierarhic). Cerințele de calitate sunt menționate în mod specific. Formular de prezentare informații de ieșire, adică mențiune specială merită și setul de rapoarte. Într-un cuvânt, fragmentul prezentat arată că dezvoltarea specificațiilor tehnice în conformitate cu GOST 34.602-89 nu este o muncă ușoară și foarte intensivă în muncă, care impune obligații serioase nu numai dezvoltatorului, ci și clientului sistemului. Potențialul standardului este extrem de ridicat și nu este surprinzător faptul că popularitatea sa a rămas constant ridicată de atâția ani.

De-a lungul timpului, dezavantajele standardului au devenit vizibile:

standardul este axat pe dezvoltarea complet personalizată a unui sistem „de la zero” și nu este destinat implementării soluție gata făcută folosind o metodologie standard sau o combinație de dezvoltări și implementări personalizate;
standardul oferă unul și numai model ciclu de viață un sistem numit cascadă, când toată munca pentru crearea sistemului este ordonată liniar și această ordine este predeterminată;
standardul este prea formal. În practică, acest lucru duce la apariția specificațiilor tehnice, în formă care îndeplinesc cerințele GOST 34.602-89, dar lipsite în esență de conținut.

Merită subliniat faptul că, la fel ca GOST 34.601-90, GOST 34.602-89 nu necesită antrenament specialîn zonă tehnologia Informatiei, așadar, un manager obișnuit, a cărui sarcină include, de exemplu, interacțiunea cu subcontractanții, poate monitoriza conformitatea cu Specificațiile Tehnice. Acest lucru simplifică implementarea și uz practic standard

Un alt fenomen interesant pe care l-a demonstrat practica este că, după cum se dovedește, nu orice specialist IT este capabil să dezvolte Sarcina tehnică, îndeplinind cerințele standardului. De fapt, apariția GOST 34.602-89 a stimulat apariția de noi specialiști - analiști de afaceri și consultanți în domeniul tehnologiei informației, a căror activitate principală a fost dezvoltarea și coordonarea Specificațiilor tehnice cu clienții sistemelor automatizate.

Standarde pentru sistemele automate de control care nu sunt combinate în serie.

GOST 15971-90. Sisteme de prelucrare a informațiilor. Termeni și definiții.

GOST 19781-90. Software pentru sisteme de procesare a informațiilor. Termeni și definiții.

GOST 28806-90. Calitatea software-ului. Termeni și definiții. Introdus la 1 ianuarie 1992.

GOST 28195-89. Evaluarea calității software-ului. Dispoziții generale.

GOST 25868-91. Echipamente periferice pentru sistemele de procesare a informațiilor. Termeni și definiții. M. Editura Standarde. 1992, 34 p. Introdus la 1 ianuarie 1993.

GOST 28147-89. Sisteme de prelucrare a informațiilor. Protecție criptografică. Algoritmi de conversie criptografică.

GOST 28803-90 (ISO 6523-84). Schimb de date. Structura de identificare a organizației. Introdus din 01/01/93.

GOST R ISO/IEC 9125-93. Tehnologia de informație. Evaluarea produselor software. Caracteristici de calitate și linii directoare pentru utilizarea lor.

GOST R ISO/IEC TO 9294-93. Tehnologia de informație. Ghid de gestionare a documentației software.

GOST R ISO 9127-94. Sisteme de prelucrare a informațiilor. Documentația utilizatorului și informațiile de ambalare pentru pachetele software de consum.

RISO 9126-93. Sisteme de prelucrare a informațiilor. Documentația utilizatorului și informațiile de ambalare pentru pachetele software de consum.

GOST RISO/IEC 12207. Procesele ciclului de viață al software-ului. Introdus din 07/01/2000.

GOST R50739-95. Facilități computerizate. Protecție împotriva accesului neautorizat la informații. Cerințe tehnice generale.

GOST R51188-98. Protejarea datelor. Testarea software-ului pentru viruși informatici. Manual model.

GOST 28140-89. Sisteme de prelucrare a informațiilor. Limbajul de programare Pascal.

GOST R 51169-98. Informații despre calitatea serviciilor. Sistem de certificare a tehnologiei informației în domeniul calității informației serviciilor. Termeni și definiții.

GOST R 51168-98. Informații despre calitatea serviciilor. Legendă elemente ale proceselor tehnologice de prelucrare a datelor.

GOST R 51170-98. Informații despre calitatea serviciilor. Termeni și definiții.

GOST R 51171-98. Informații despre calitatea serviciilor. Reguli de depunere a tehnologiilor informaționale pentru certificare.

GOST seria 34. „Tehnologia informației (IT)”.

RD 50-680-88. Sisteme automatizate. Dispoziții de bază.

RD 50-682-89. Tehnologia de informație. Un set de standarde și linii directoare pentru sisteme automate. Dispoziții generale.

GOST 34.003-90. ACEASTA. Sisteme automatizate. Termeni și definiții.

GOST 34.201-89. ACEASTA. Set de standarde pentru sisteme automate. Tipuri, completitudine și desemnare a documentelor la crearea sistemelor automate.

GOST 34.601-90. ACEASTA. Set de standarde pentru sisteme automate. Sisteme automatizate. Etapele creației. (În loc de GOST 24.601-86, 24.602-86).

GOST 34.602-89. ACEASTA. Set de standarde pentru sisteme automate. Termeni de referință pentru crearea unui sistem automatizat.

GOST 34.603-89. ACEASTA. Tipuri de testare a sistemelor automate.

RD 50-34.698-90. ACEASTA. Sisteme automatizate. Cerințe pentru conținutul documentelor.

GOST 34.1501.1-92 (ISO/TR 10314-1-90). ACEASTA. Automatizare industriala. Productie primara. Partea 1. Model de referință de standardizare și metodologie pentru identificarea cerințelor de standardizare.

GOST seria 19. „Sistem unificat de documentare a programelor (USPD)”.

GOST 19.001-77. Sistem unificat de documentare a programului. Dispoziții generale.

GOST 19.701-90. (ISO 5807-85). ESPD. Scheme de algoritmi, programe, date și sisteme. Convenții și reguli de executare. (În loc de GOST 19.002-80, 19.003-80).

GOST 19.005-85. ESPD. P-scheme de algoritmi și programe. Denumiri grafice convenționale și reguli de execuție.

GOST 19.101-77. ESPD. Tipuri de programe și documente de program.

GOST 19.102-77. ESPD. Etape de dezvoltare.

GOST 19.103-77. ESPD. Denumirile programelor și documentelor programelor.

GOST 19.104-78. ESPD. Inscripții de bază.

GOST 19.105-78. ESPD. Cerințe generale pentru documentele programului.

GOST 19.106-78. ESPD. Cerințe pentru documentele de program tipărite.

GOST 19.201-78. ESPD. Sarcina tehnică. Cerințe pentru creare și proiectare.

GOST 19.202-78. ESPD. Specificație. Cerințe pentru conținut și design.

GOST 19.301-78 ESPD. Programul de testare și metodologia. Cerințe pentru conținut și design.

GOST 19.401-78. ESPD. Textul programului. Cerințe pentru conținut și design.

GOST 19.402-78. ESPD. Descrierea programului.

GOST 19.403-79. ESPD. Lista deținătorilor originali.

GOST 19.404-79. ESPD. Notă explicativă. Cerințe pentru conținut și design.

GOST 19.501-78. ESPD. Formă. Cerințe pentru descriere și proiectare.

GOST 19.502-78. ESPD. Descrierea aplicației. Cerințe pentru descriere și proiectare.

GOST 19.503-79. ESPD. Ghidul programatorului de sistem. Cerințe pentru descriere și proiectare.

GOST 19.504-79. ESPD. Ghidul programatorului. Cerințe pentru descriere și proiectare.

GOST 19.505-79. ESPD. Manual de utilizare. Cerințe pentru descriere și proiectare.

GOST 19.506-79. ESPD. Descrierea limbii. Cerințe pentru descriere și proiectare.

GOST 19.507-79. ESPD. Lista documentelor operaționale.

GOST 19.508-79. ESPD. Manual de întreținere. Cerințe pentru conținut și design.

GOST 19.601-78. ESPD. Reguli generale de duplicare, contabilitate și stocare.

GOST 19.602-78. ESPD. Reguli pentru duplicarea, contabilizarea și stocarea documentelor tipărite.

GOST 19.603-78. ESPD. Reguli generale pentru efectuarea modificărilor.

GOST 19.604-78. ESPD. Reguli pentru efectuarea modificărilor documentelor tipărite.

GOST seria 24. „Sistem unificat de standarde pentru sisteme de control automate (ESSASU)”.

GOST 24.104-85. ESSASU. Sisteme automate de control. Cerințe generale.

GOST 24.301-80. Sistem de documentație tehnică pentru sisteme automate de control. Cerințe generale pentru execuția documentelor text.

GOST 24.302-80. Sistem de documentație tehnică pentru sisteme automate de control. Cerințe generale pentru implementarea schemelor.

GOST 24.701-86. ESSASU. Fiabilitatea sistemelor automate de control. Dispoziții de bază.

GOST 24.702-85. Eficiența sistemelor automate de control. Dispoziții de bază.

GOST 24.703-85. Soluții tipice de proiectare în sistemele automate de control. Dispoziții de bază.

În loc de GOST 24.601-86 și 24.602-86, vezi GOST 34.601-90.

Standarde în domeniul securității informațiilor.

GOST R 50922-96. Protejarea datelor. Termeni și definiții de bază.

GOST R 50934-96. Protejarea datelor. Organizarea și conținutul muncii pentru a proteja informațiile despre echipamentele militare de informații tehnice. Dispoziții generale.

GOST R 50739-95. Facilități computerizate. Protecție împotriva accesului neautorizat la informații. Cerințe tehnice generale.

GOST R 51188-98. Protejarea datelor. Testarea software-ului pentru viruși informatici. Manual model.

GOST R 51275-99. Protejarea datelor. Obiect informativ. Factorii care influențează informația. Dispoziții generale.

GOST R 51241-98. Instrumente și sisteme de control acces. Clasificare. Cerințe tehnice generale. Metode de testare.

GOST R 51583-2000. Protejarea datelor. Procedura de creare a sistemelor automatizate într-un design sigur. Cerințe generale.

ISO/IEC 15408-99. Criterii de securitate a tehnologiei informației.

Clasificarea și codificarea informațiilor.

Materiale despre standardizare.

Reguli de standardizare. Prevederi de bază și procedură pentru efectuarea lucrărilor privind dezvoltarea, întreținerea și aplicarea clasificatoarelor întregi rusești. PR 50.1.024-2005. Agenția Federală pentru Reglementare Tehnică și Metrologie. Ordinul nr. 311-st din 14 decembrie 2005.

Astăzi vom vorbi despre standardele interne pentru documentația de proiectare. Cum funcționează aceste standarde în practică, de ce sunt rele și de ce sunt bune. Atunci când dezvoltăm documentație pentru guvern și clienți privați serioși, de obicei nu avem de ales - conformitatea cu standardele este inclusă în cerințele pentru documentarea specificațiilor tehnice. În practică, am întâlnit diverse exemple de neînțelegere a structurii standardelor, ce ar trebui să fie în documente și de ce sunt necesare aceste documente. Drept urmare, pixurile scriitorilor tehnici, analiștilor și specialiștilor produc uneori astfel de pietre prețioase încât nu este clar în ce stare de conștiință au fost scrise. Dar, de fapt, totul este destul de simplu. O căutare pe Habr nu a returnat niciun link către material mai mult sau mai puțin complet pe această temă, așa că îmi propun să umplem acest gol enervant.

Ce sunt standardele de documentare?

În seria 34 în cauză, există doar 3 standarde principale de documentare:

Cel mai iubit și popular standard pentru dezvoltarea specificațiilor tehnice. Singurul lucru pe care nu trebuie să-l uitați este că este strâns legat de alte standarde ale seriei și dacă ați primit o specificație tehnică realizată conform acest standard, este foarte recomandabil să respectați alte standarde, chiar dacă nu există cerințe directe pentru aceasta. Cel puțin în ceea ce privește ideologia generală (despre care mai jos)

Acesta este un document de bază care oferă o listă completă a documentației GOST 34, recomandări pentru codificarea documentelor, etapele de proiect cărora le aparțin documentele (etapele sunt descrise în GOST 34.601-90), precum și modul în care pot fi combinate între ele. .

De fapt, acest standard este masă mare cu comentarii. Poate fi pus în Excel pentru ușurință în utilizare.

Un standard voluminos care descrie conținutul documentelor de proiect cu diferite grade de detaliu. GOST 34.201-89 menționat mai sus este folosit ca index.

Există multe întrebări și interpretări ale prevederilor acestuia cu privire la standardul RD 50-34.698-90, care, datorită vagului lor, sunt adesea înțelese diferit de către client și antreprenor, sau chiar membrii echipei de proiect. Dar, din păcate, nu avem nimic mai concret.

Să luăm acum în considerare avantajele și dezavantajele standardelor, începând în mod tradițional cu dezavantajele.

Dezavantajele standardelor

Principalul dezavantaj este evident pentru toată lumea - standardele sunt vechi. Ele conțin o idee învechită a arhitecturii unui sistem automatizat. De exemplu:

aplicații pe două niveluri, constând dintr-un program client și un server DBMS (fără trei sau mai multe aplicații „nivel”, fără Weblogic sau JBoss)
structura tabelelor bazei de date, fiind descrisă, va da o idee despre modelul logic de date (faptul că ar putea exista un fel de Hibernare între aplicație și baza de date părea un exces rău atunci)
interfața cu utilizatorul este cu o singură fereastră (mai există ceva? Ce este un „browser”?)
Există puține rapoarte în sistem; toate sunt pe hârtie și tipărite pe o imprimantă cu matrice de puncte.
Programul în curs de dezvoltare este axat pe rezolvarea „problemei de procesare a informațiilor”, care are o intrare și o ieșire clare și este foarte specializată. Procesarea informațiilor se bazează pe un „algoritm”. Uneori există mai mulți „algoritmi”. (Programarea orientată pe obiecte făcea atunci doar primii pași și nu a fost luată în considerare în mod serios).
administratorul bazei de date înțelege ce informații sunt în tabele și participă activ la editarea directoarelor sistemului (există într-adevăr un server DBMS pentru 50 de aplicații diferite?)

În consecință, standardul are artefacte precum următoarele:

5.8. Desenul formularului de document (cadru video)
Documentul trebuie să conțină o imagine a formei documentului sau a cadrului video în conformitate cu cerințele standardelor de stat ale sistemului de documentare unificat R 50-77 și explicațiile necesare.

Ideea documentului este că întreprinderile sovietice foloseau așa-numitele „zone de imprimare”, unde existau imprimante matrice de mare viteză, driverele pentru care erau adesea scrise de către inginerii înșiși. Prin urmare, au trebuit să mențină un registru cu toate documentele care trebuiau tipărite pentru a se asigura că documentele arată așa cum ar trebui la imprimare.

„Cadru video” este, de asemenea, un document pe care a fost afișat afișarea textului. Ecranele nu au suportat întotdeauna caracterele necesare și cantitatea necesară caractere pe orizontală și linii pe verticală (iar graficele nu au fost acceptate deloc). Prin urmare, și aici a fost necesară coordonarea suplimentară a formularelor tuturor documentelor de ecran.

Acum cuvintele „machineogramă”, „cadru video”, „ADC” nu ne mai spun nimic. Nici eu nu le-am găsit în uz, deși am absolvit un institut de specialitate în anii 90. Era timpul apariția Windowsului 3.1, display-uri VGA, dischete de trei inchi și primele site-uri de internet interne. Dar aceste cuvinte sunt în standard, iar clientul solicită uneori capricios să îi oferim un set complet de documentație în conformitate cu GOST 34.201-89. Mai mult, astfel de formulări din ToR migrează de la un minister la altul și au devenit deja un fel de șablon nerostit în care este introdus conținutul.

Deci, documentul cu numele stupid „Desenul formularului de document (cadru video)” din proiect ar trebui și nu trebuie să fie gol.

Ce este bun în standard

Orice standard este bun prin faptul că permite clientului și contractantului să vorbească aceeași limbă și oferă o garanție că, cel puțin, clientul nu va avea nicio reclamație „în formă” la rezultatele transmise.

Și standardele GOST 34 sunt bune și pentru că au fost întocmite de oameni inteligenți, testate de-a lungul anilor și au un scop clar - să descrie pe hârtie cât mai complet esența complexă abstractă pe care o reprezintă orice sistem de control automatizat.

Când trebuie să stabiliți cu competență o sarcină pentru contractorii occidentali care nu au auzit niciodată de standardele noastre GOST, vă puteți baza și pe aceste standarde, sau mai degrabă pe conținutul și componenta semantică a acestora. Pentru că, repet, garanția completității informațiilor valorează mult. Oricât de mult ne-am consola nivel inalt profesionalismul nostru, este posibil să uităm să includem lucruri elementare în cerințele noastre, în timp ce același GOST 34.602-89 „îți amintește” totul. Dacă nu vă este clar cum ar trebui să arate rezultatul muncii antreprenorilor occidentali, uitați-vă la cerințele de documentare și la secțiunile recomandate. Te asigur, e mai bine să nu te gândești la asta! Cel mai probabil, există analogi occidentali ai standardelor noastre, în care totul poate fi mai complet, mai modern și mai bun. Din păcate, nu sunt familiarizat cu ele, deoarece nu a existat încă un singur caz în care standardele noastre GOST nu au fost suficiente.

Puteți râde de faptul că creatorii de standarde nu știau nimic despre java sau .NET, despre monitoare HD și Internet, dar nu aș sfătui să subestimați amploarea muncii pe care le-au făcut și valoarea acesteia pentru comunitatea noastră profesională.

Cum să citiți și să înțelegeți standardele de documentare conform GOST seria 34

Standardul împarte toate documentele pe două axe - timp și domeniu. Dacă vă uitați la Tabelul 2 din GOST 34.201-89, puteți vedea clar această diviziune (coloanele „Etapa de creare” și „Parte din proiect”

Etapele creării unui sistem de control automatizat

Etapele creației sunt definite în GOST 34.601-90. Trei dintre ele sunt relevante pentru documentare:

Proiect de proiect (ED)
Proiectare tehnică (TP)
Elaborarea documentației de lucru (DD)

Proiectare preliminară urmează după etapa Specificațiilor tehnice și servește la dezvoltarea soluțiilor preliminare de proiectare.

Proiect tehnic descrie viitorul sistem din toate unghiurile. Documentele aflate în etapa de TP ar trebui, după citire, să lase în urmă o claritate deplină în abordările, metodele, soluțiile arhitecturale și tehnice propuse. La următoarea fază va fi prea târziu pentru a descrie abordările și a justifica solutii tehnice, deci faza P este cheia livrării cu succes a lucrărilor, deoarece toată varietatea de cerințe ale specificațiilor tehnice trebuie să fie reflectată în documentele fazei P. În faza P, sistemul poate să nu existe deloc.

Documentatie de lucru conceput pentru implementare cu succes, punere în funcțiune și funcționare continuă sistem nou. Acestea sunt documente care conțin informații foarte specifice care descriu entități existente fizic, spre deosebire de faza P, care descrie splendoarea viitoare.

Părți (secțiuni) ale documentației de proiect pentru crearea unui sistem de control automatizat

Tematica este împărțită în „Dispoziții”. La început se pare că o astfel de împărțire este redundantă și inutilă. Dar când începeți să lucrați cu acest set de instrumente în practică, ideologia încorporată în el devine treptat clară.

Un sistem automatizat, așa cum este preconizat de compilatorii GOST, este o combinație de hardware, software și canale de comunicare care prelucrează informațiile provenite din surse diferite informații în conformitate cu anumiți algoritmi și produce rezultate de prelucrare sub formă de documente, structuri de date sau acțiuni de control. Un model primitiv al celei mai simple mitraliere.

Pentru a descrie pe deplin această „mașină”, sunt realizate următoarele secțiuni (ca în desen):

Software (MS), răspunzând la întrebările: ce logică este conectată în interiorul „cutiei negre”? De ce au fost aleși acești algoritmi, formulele și coeficienții?

Software-ul matematic nu știe nimic despre procesoare sau baze de date. Aceasta este o zonă abstractă separată, locuința „cailor sferici în vid”. Dar software-ul matematic poate fi foarte strâns legat de domeniul subiectului, aka Viata reala. De exemplu, algoritmii de control pentru sistemele de control al traficului trebuie aprobați de către Inspectoratul de Stat pentru Siguranța Circulației înainte de a fi aprobați de către client. Și atunci înțelegeți de ce sunt incluse într-o carte separată. Pentru că nimeni din poliția rutieră nu este interesat de ce sistem de operare va rula serverul de aplicații, dar ce semn și limita de viteză vor apărea pe tablă în ploaie sau zăpadă este foarte interesant. Ei sunt responsabili pentru partea lor și nu vor semna nimic altceva. Pe de altă parte, atunci când au semnat, nu vor fi întrebări despre latura tehnică a problemei - de ce au ales acele panouri sau semafoare și nu altele. Înțelepciunea „strămoșilor” se manifestă tocmai în astfel de cazuri practice.

Suport informațional (IS). O altă porțiune din sistem. De data aceasta, cutia neagră a sistemului nostru este transparentă și ne uităm la informațiile care circulă în ea. Imaginați-vă un model al sistemului circulator uman când toate celelalte organe sunt invizibile. Ceva de genul acesta este Suportul de informații. Descrie compoziția și rutele fluxului de informații în interior și în exterior, organizarea logică a informațiilor în sistem, o descriere a cărților de referință și a sistemelor de codificare (cei care au realizat programe pentru producție știu cât de importante sunt acestea). Partea descriptivă principală se încadrează în etapa TP, dar unele „rudimente” curg în etapa RD, cum ar fi documentul „Catalog baze de date”. Este clar că anterior conținea exact ceea ce este scris în titlu. Dar astăzi încearcă unul provocator sistem integrat pentru a crea un astfel de document atunci când foarte des sistemul folosește subsisteme achiziționate cu propriile depozite de informații misterioase. Nici măcar nu spun că acest document nu este deosebit de necesar acum.

Sau aici este „Declarația despre mediile de stocare a computerului”. Este clar că anterior conținea un număr de tobe magnetice sau bobine de film. Acum ce ar trebui să pun acolo?

Pe scurt, la faza RD documentele Suport informațional reprezintă un rudiment destul de dăunător, deoarece în mod formal ar trebui să existe, dar nu există nimic special cu care să le umpleți.

Software. Partea preferată a tuturor din documentația proiectului. Da, fie doar pentru că este doar un document! Și apoi, toată lumea înțelege ce trebuie scris acolo. Dar o voi repeta oricum.

În acest document, trebuie să vă spunem cu ajutorul cărui software sunt executați algoritmii descriși în ML, procesând informațiile descrise în IR. Adică, nu este nevoie să duplicați informațiile din alte secțiuni aici. Aici oferim arhitectura sistemului, rațiunea pentru selectat tehnologii software, descrierea lor (tot felul de lucruri de sistem: limbaje de programare, cadre, sisteme de operare etc.). De asemenea, în acest document descriem modul în care sunt organizate instrumentele de procesare a informațiilor (cozi de mesaje, facilități de stocare, Rezervă copie, soluții de accesibilitate, tot felul de pool-uri de aplicații etc.). Standardul conține o descriere detaliată a conținutului acestui document, pe care orice specialist o va înțelege.

Suport tehnic (TO). O parte nu mai puțin iubită a documentației proiectului. Tabloul roz nu este decât întunecat de abundența documentelor care trebuie dezvoltate. În total, standardul necesită elaborarea a 22 de documente, dintre care 9 sunt în stadiul de TC.

Faptul este că standardul oferă o descriere a tuturor suport tehnic, inclusiv hardware și rețele de computer, sisteme de inginerie și chiar partea de construcție (dacă este necesar). Și această economie este reglementată de un număr mare de standarde și reglementări, coordonate în diferite organizații și, prin urmare, este mai convenabil să împărțiți totul în părți și să coordonați (editați) în părți. În același timp, standardul vă permite să combinați unele documente între ele, ceea ce are sens dacă întregul grup este aprobat de o singură persoană.

De asemenea, nu uitați că un set de standarde de calitate presupune înregistrarea și stocarea documentelor tehnice, iar „cărțile” noastre de la client pot fi distribuite în diferite arhive, în funcție de subiectul descrierii. Acesta este un alt argument în favoarea fragmentării documentației.

Suport organizațional (OO). După ce am suprimat dorința, normală pentru un techie, de a trece peste această secțiune cât mai repede posibil, dimpotrivă, o voi lua în considerare mai detaliat. De vreme ce, colegilor, în ultima perioadă au existat unele tendințe proaste în proiecte care necesită clarificări în această secțiune.

La etapa TP, secțiunea conține un singur document „ Descrierea structurii organizatorice„, în care trebuie să spunem clientului pentru ce ar trebui să se pregătească în ceea ce privește schimbarea structurii organizatorice. Dintr-o dată trebuie să organizați un nou departament pentru a vă opera sistemul, să introduceți noi poziții etc.

La etapa RD apar și alte documente, mai interesante, pe care aș vrea să le iau în considerare separat.

Manualul utilizatorului. Comentariile sunt inutile, cred.

Metodologie (tehnologie) proiectare asistată de calculator . Dacă este necesar, puteți include în acest document o descriere a procesului de construire a software-ului, control al versiunilor, testare etc. Dar asta dacă clientul din specificația tehnică dorește să asambleze personal software-ul. Dacă nu cere acest lucru (și nu plătește pentru asta), atunci întreaga bucătărie internă nu este treaba lui și acest document nu trebuie făcut.

Instructiuni tehnologice. Datorită modului de formalizare a proceselor de afaceri, un client viclean încearcă uneori să introducă reglementări de operare în acest document. Deci, sub nicio formă nu trebuie să faci asta.

Descrierea proceselor de afaceri, rol și descrierea postului, regulament de muncă - toate acestea sunt ORD, adică documentație organizatorică și administrativă. Care este produsul unui proiect de consultanță, care, din câte am înțeles, nu a fost achiziționat de la dumneavoastră. Și ți-au cumpărat un proiect tehnic și, de asemenea, documentația tehnică pentru el.

Instrucțiunea tehnologică este un strat între instrucțiunile de utilizare și manualul de utilizare. RP descrie în detaliu Cum trebuie să faceți anumite acțiuni în sistem. Instrucțiunea tehnologică spune că care acțiunile trebuie efectuate în anumite cazuri legate de funcționarea sistemului. În linii mari, o instrucțiune tehnologică este un scurt rezumat al RP pentru o anumită poziție sau rol. Dacă clientul nu are roluri formate sau dorește să vă creați singur roluri și cerințe de post, includeți în document cele mai elementare roluri, de exemplu: operator, operator senior, administrator. Comentariile clientului cu privire la subiectul „dar nu e așa la noi” sau „nu ne place” ar trebui să fie însoțite de o listă de roluri și de o descriere a responsabilităților postului. Pentru că procesele de afaceri noi nu o punem. Suntem aceste procese de afaceri automatiza.

Voi scrie separat despre greblele descrise, cu exemple colorate, deoarece nu este prima dată când acest lucru se repetă în diferite sectoare ale „economiei naționale”.

Descrierea procesului tehnologic de prelucrare a datelor (inclusiv teleprocesare). O relicvă jalnică a epocii peșterilor, când existau „operatori de computer” special desemnați, care introduceau carduri perforate la mașină și împachetau o imprimare a rezultatului într-un plic. Această instrucțiune este pentru ei. Nu vă pot spune exact ce să scrieți în el în secolul 21. Ieși singur. Cel mai bun lucru este să uiți de acest document.

Soluții la nivel de sistem (WSO). Standardul prevede 17 documente în secțiunea OP. În primul rând, acestea sunt aproape toate documentele fazei preliminare de proiectare schematică. În al doilea rând, acestea sunt tot felul de estimări, calcule și descriere scurta funcții automatizate. Adică informații pentru oameni nu din producția IT principală, ci pentru personalul suport - manageri, estimatori, specialiști în achiziții, economiști etc.

Și în al treilea rând, OR include un mega-document numit „Notă explicativă pentru proiect tehnic„, care se dorește a fi un fel de Rezumat, dar, de fapt, mulți designeri pun tot conținutul util al etapei TP în el. O astfel de abordare radicală poate fi justificată și chiar reciproc avantajoasă atât pentru client, cât și pentru antreprenor, dar în anumite cazuri.

Opțiuni pentru utilizarea GOST 34

Respectarea deplină și exactă la standard. Desigur, nimeni nu va scrie în mod voluntar un astfel de nor de documente. Prin urmare, un set complet de documente este pregătit doar la cererea urgentă a clientului, pe care acesta le-a asigurat în specificațiile tehnice și, de asemenea, a fixat cu un acord deasupra. În acest caz, trebuie să luați totul la propriu și să oferiți clientului „cărți” fizice, pe care vor fi numele documentelor din Tabelul 2 din GOST 34.201-89, cu excepția celor complet inutile, a căror listă trebuie să discute și să se asigure în scris. Conținutul documentelor trebuie, de asemenea, să respecte, fără nicio imaginație, RD 50-34.698-90, până la denumirile secțiilor. Pentru ca creierul clientului să explodeze, uneori sistem mare sunt împărțite în subsisteme și se eliberează documentație de proiectare separată pentru fiecare subsistem. Arată terifiant și nu este supus controlului normal cu ajutorul minții pământești. În special în ceea ce privește integrarea subsistemelor. Ceea ce simplifică foarte mult acceptarea. Principalul lucru este că tu însuți nu te confuzi și că sistemul tău încă funcționează așa cum ar trebui.
Ne plac standardele GOST. Companiile mari serioase iubesc standardele. Pentru că îi ajută pe oameni să se înțeleagă mai bine. Dacă clientul dvs. este remarcat pentru dragostea lui pentru ordine și standardizare, încercați să respectați ideologia standard GOST atunci când dezvoltați documente, chiar dacă acest lucru nu este cerut de specificațiile tehnice. Specialistii avizari te vor intelege mai bine si te vor aproba, iar tu insuti nu vei uita sa ii incluzi in documentatie Informații importante, veți vedea mai bine structura țintă a documentelor, veți planifica mai precis munca de scriere a acestora și vă veți economisi pe dumneavoastră și pe colegii tăi o mulțime de nervi și bani.
Nu ne pasă de documentare, atâta timp cât totul funcționează. Aspectul dispărut al clientului iresponsabil. O viziune similară asupra documentației poate fi găsită încă în rândul clienților mici și săraci, precum și în „idiotocrațiile” autoritare rămase din timpul perestroikei, unde șeful este înconjurat de prieteni loiali - directori, iar toate problemele sunt rezolvate în conversații personale. . În astfel de condiții, sunteți liber să neglijați documentația cu totul, dar este mai bine, până la urmă, să nu doborâți vederea și să completați cel puțin schematic documentația cu conținut. Dacă nu acestui client, atunci transmiteți-l (vindeți-l) următorului.

Concluzie

Acest articol a fost despre standardele noastre GOST pentru documentarea sistemelor de control automatizate. GOST-urile sunt vechi, dar, după cum se dovedește, sunt încă foarte utile în gospodărie. În afară de unele rudimente evidente, structura documentației are proprietăți de completitudine și consistență, iar aderarea la standard elimină multe riscuri ale proiectului, de a căror existență este posibil să nu fim conștienți la început.

Sper că materialul prezentat v-a fost de folos, sau măcar interesant. În ciuda oboselii aparente, documentarea este o muncă importantă și responsabilă, acuratețea în care este la fel de importantă ca și atunci când scrieți. cod bun. Scrie documente bune, Colegi! Și săptămâna viitoare merg în două călătorii de afaceri la rând, așa că nu pot garanta publicarea de materiale noi (nu am un cache, scriu din cap).