Sistem unificat de documentare a programului. Cerințe generale pentru documentele programului. Sistem unificat de documentare a programului Cerințe generale pentru documentele programului

GOST 19.105-78

Grupa T55

STANDARD INTERSTATAL

Sistem unificat documentația programului

CERINȚE GENERALE PENTRU DOCUMENTELE SOFTWARE

Sistem unificat pentru documentarea programului. Cerințe generale pentru documentele programului

MKS 35.080

Data introducerii 1980-01-01

Rezoluţie Comitetul de Stat URSS conform standardelor din 18 decembrie 1978 N 3350, data introducerii este stabilită la 01/01/80

EDIȚIE (ianuarie 2010) cu Amendamentul nr. 1, aprobat în septembrie 1981 (IUS 11-81).


Acest standard stabilește cerințe generale pentru pregătirea documentelor de program pentru calculatoare, complexe și sisteme, indiferent de scopul și domeniul de aplicare al acestora și prevăzute de standardele Sistemului Unificat de Documentare a Programelor (USPD) pentru orice metodă de executare a documentelor pe diverse purtători de date.

Standardul respectă ST SEV 2088-80* în ceea ce privește cerințele generale pentru proiectarea părții de informații (vezi anexa).
________________
* Accesul la documentele internaționale și străine menționate în text poate fi obținut contactând Asistența Clienți. - Nota producătorului bazei de date.

(Ediție schimbată, amendamentul nr. 1).

1. CERINȚE GENERALE

1. CERINȚE GENERALE

1.1. Documentul de politică poate fi prezentat la adresa diverse tipuri purtători de date.

1.2. Documentul programului constă din următoarele părți convenționale:

titlu;

informativ;

de bază;

înregistrarea modificărilor.

1.3. Regulile de executare a unui document și a părților acestuia pe fiecare suport de date sunt stabilite de standardele DEPD pentru regulile de executare a documentelor pe suporturile de date aferente.

2. TITLUL PARTEA

2.1. Partea de titlu constă dintr-o fișă de aprobare și pagina de titlu.

Reguli pentru întocmirea foii de aprobare și a paginii de titlu - conform GOST 19.104-78.

3. INFORMAȚII PARTEA

3.1. Partea de informare ar trebui să conțină un rezumat și conținut.

3.2. Necesitatea includerii părții informaționale în diferitele tipuri de documente de program este stabilită de standardele relevante ale DEUE pentru aceste documente.

3.3. Adnotarea oferă informații despre scopul documentului și un scurt rezumat al părții sale principale.

3.4. Conținutul include o listă de înregistrări despre elemente structurale partea principală a documentului, fiecare dintre ele include:

desemnarea unui element structural (număr de secțiune, subsecțiune etc.);

denumirea elementului structural;

adresa elementului structural de pe suportul de stocare (de exemplu, numărul paginii, numărul fișierului etc.).

Regulile de desemnare a elementelor structurale ale părții principale a documentului și adresarea acestora sunt stabilite de standardele DEPD pentru regulile de întocmire a documentelor pe suporturile de date aferente.

4. PARTEA PRINCIPALA

4.1. Compoziția și structura părții principale a documentului de program sunt stabilite de standardele DEPD pentru documentele relevante.

5. SCHIMBAREA ÎNREGISTRAREA PARTEA

5.1. Fiecare modificare a documentului programului este înregistrată în această parte în conformitate cu cerințele GOST 19.603-78.

ANEXĂ (referință). INFORMAȚII DATE PRIVIND CONFORMITATEA CU GOST 19.105-78 ST SEV 2088-80

APLICARE
Informaţii

Secțiunea 3 din GOST 19.105-78 corespunde secțiunii 4 (clauzele 4.2, 4.3) ST SEV 2088-80.

(Introdus suplimentar, amendamentul nr. 1).



Textul documentului electronic
pregătit de Kodeks JSC și verificat cu:
publicație oficială
Sistem unificat de documentare a programului:
Culegere de standarde naționale. -
M.: Standartinform, 2010

Sistemul unificat de documentare a programelor este un set de standarde de stat care stabilesc reguli interconectate pentru dezvoltarea, executarea și circulația programelor și a documentației programelor.

Compoziția ESP

GOST 19.004 ESPD. Termeni și definiții.

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

GOST 19.102 ESPD. Etape de dezvoltare.

GOST 19.103 ESPD. Denumirile programelor și documentelor programelor.

GOST 19.104 ESPD. Inscripții de bază.

GOST 19.105 ESPD. Cerințe generale La documentele programului.

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

GOST 19.201 ESPD. Termeni de referință. Cerințe pentru conținut și design.

GOST 19.202 ESPD. Caietul de sarcini. Cerințe pentru conținut și design.

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

GOST 19.402 ESPD. Descrierea programului.

GOST 19.501 ESPD. Formă. Cerințe pentru conținut și design.

GOST 19.502 ESPD. Descriere generală. Cerințe pentru conținut și design.

GOST 19.503 ESPD. Ghidul programatorului de sistem. Cerințe pentru conținut și design.

GOST 19.504 ESPD. Ghidul programatorului. Cerințe pentru conținut și design.

GOST 19.505 ESPD. Manual de utilizare. Cerințe pentru conținut și design.

GOST 19.506 ESPD. Descrierea limbii. Cerințe pentru conținut și design.

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

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

GOST 19.603 ESPD. Reguli generale efectuarea de modificări.

GOST 19.604 ESPD. Reguli pentru efectuarea modificărilor documentelor de program tipărite.

GOST 19.001 ESPD. Dispoziții generale.

Sistemul Unificat de Documentare a Programelor (USPD) este un set de standarde de stat care stabilesc reguli interconectate pentru dezvoltarea, execuția și circulația programelor și a documentației programelor.

Standardele ESPD stabilesc cerințe de reglementare

dezvoltare,

acompaniament,

fabricaţie şi

operarea programelor.

Regulile și reglementările stabilite în standardele ESPD se aplică documentației software pentru calculatoare, complexe și sisteme, indiferent de scopul și domeniul de aplicare al acestora.

DEUE include următoarele grupuri de standarde:

0 – Dispoziții generale.

1 – Standarde fundamentale.

2 – Reguli de executare a documentației de dezvoltare.

3 – Reguli de executare a documentației de execuție.

4 – Reguli de implementare a documentației suport.

5 – Reguli de executare documentatie operationala.

6 – Reguli de circulație a documentației software.

7 – Grup de rezervă.

8 – Grup de rezervă.

9 – Alte standarde.

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

Standardul stabilește tipurile de programe și documente de programe pentru calculatoare, complexe și sisteme, indiferent de scopul și scopul acestora.

Tipuri de programe:

Program original. Un program conceput pentru a stoca și reproduce duplicate din acesta.

Program duplicat. Un program care este o copie a programului original și este destinat stocării și realizării de copii.

O copie a programului. Un program conceput pentru utilizare directă.

Tipuri de documente de program(eșantionare pentru condițiile de proiectare a programelor pentru computere):

Specificatii tehnice. Scopul și domeniul de aplicare al programului, tehnic, tehno-economic și cerințe speciale cerințe pentru program, etapele necesare și termenii de dezvoltare, tipuri de teste.

Caietul de sarcini. Componența programului și documentația acestuia.

Lista deținătorilor originali. Lista companiilor care stochează programe originale și documentația originală a programului.

Textul programului. Înregistrarea programului cu comentariile necesare.

Descrierea programului. Informații despre structura logică și funcționarea programului.

Notă explicativă. Justificarea solutiilor tehnice adoptate, descriere algoritm general functionarea programului.

Procedura și metodologia de testare. Cerințe care trebuie verificate la testarea programului, precum și procedura și metodele de control al acestora.

Manual de utilizare (de utilizare). Informații pentru asigurarea procedurii de comunicare cu sistemul informatic în timpul execuției programului.

GOST 19.102 ESPD. Etape de dezvoltare.

GOST 19.201 ESPD. Specificatii tehnice. Cerințe pentru conținut și design.

Standardul stabilește procedura de construire și pregătire a specificațiilor tehnice pentru dezvoltarea unui program sau produs software pentru calculatoare, complexe și sisteme, indiferent de scopul și domeniul de aplicare al acestora.

Termenii de referință trebuie să conțină următoarele secțiuni:

Denumirea și domeniul de aplicare.

Secțiunea indică numele, o scurtă descriere a domeniului de aplicare, programul sau produsul software și obiectul în care este utilizat programul sau produsul software.

Baza dezvoltării.

Secțiunea ar trebui să indice documentul pe baza căruia se realizează dezvoltarea.

Scopul dezvoltării.

Secțiunea trebuie să indice scopul funcțional și operațional al programului sau produsului software.

Cerințe tehnice pentru un program sau un produs software.

Secțiunea ar trebui să conțină următoarele subsecțiuni:

Cerințe pentru caracteristicile funcționale.

Termeni de utilizare.

Cerințe pentru compoziția și parametrii mijloacelor tehnice.

Cerințe pentru informații și compatibilitate software.

Subsecțiunea „Cerințe pentru caracteristicile funcționale” ar trebui să indice cerințele pentru compoziția funcțiilor îndeplinite, organizarea datelor de intrare și de ieșire, caracteristicile de sincronizare etc.

În subsecțiunea „Cerințe privind compoziția și parametrii mijloacelor tehnice”, este indicată compoziția necesară a mijloacelor tehnice, indicând caracteristicile tehnice ale acestora.

Subsecțiunea „Cerințe privind compatibilitatea informațiilor și software-ului” ar trebui să indice cerințele pentru structurile de informații la intrare și ieșire și metodele de soluție, codurile sursă și limbaje de programare.

Indicatori tehnico-economici.

Secțiunea indică eficiența economică estimată, cererea anuală estimată, avantajele economice ale dezvoltării în comparație cu cele mai bune mostre și analogi.

Etape și stadii de dezvoltare.

Procedura de control si acceptare.

Secțiunea ar trebui să indice tipurile de teste și cerințele generale pentru acceptarea lucrărilor.

GOST 19.402 ESPD. Descrierea programului.

Documentul constă dintr-o parte de informare (adnotări și conținut) și o parte principală (scop funcțional, descrierea logicii).

Secțiunea „Scopul funcțional” indică scopul programului și oferă o descriere generală a funcționării programului și informații despre restricțiile de utilizare.

În secțiunea „Descrierea logicii” indicați:

Descrierea structurii programului și a componentelor sale.

Descrierea funcțiilor componentelor și a conexiunilor dintre acestea.

Informații despre limbajul de programare.

Descrierea datelor de intrare și de ieșire pentru fiecare dintre componente.

Descrierea logicii componentelor (dacă este necesar, sunt compilate descrieri ale diagramelor de program).

Când descrieți logica programului, este necesară o legătură către textul programului.

GOST 19.505 ESPD. Manual de utilizare. Cerințe pentru conținut și design.

Documentul trebuie să conțină următoarele secțiuni:

Scopul programului.

Conditii de utilizare.

Porniți programul.

Comenzile operatorului.

Mesaje către operator.

Secțiunea „Porniți un program” ar trebui să indice pașii care trebuie efectuati pentru a vă asigura că programul se încarcă și rulează.

Secțiunea „Comenzile operatorului” ar trebui să conțină o descriere a funcțiilor și posibilelor opțiuni de comandă cu care operatorul încarcă și controlează execuția programului, precum și procedura operatorului pentru finalizarea programului.

Secțiunea „Mesaje către operator” ar trebui să conțină textele mesajelor emise în timpul execuției programului, o descriere a conținutului acestora și acțiunile operatorului corespunzătoare (acțiunile operatorului în caz de eșec, posibilitatea repornirii programului).

În raportul meu mă bazez pe:

• articol „Standardizarea în domeniul software” de V.V Vasyutkovich - șef de departament și S.S. Samotokhin - cercetător principal. Institutul de Cercetare a Standardelor din întreaga Rusie a Standardului de Stat al Federației Ruse;
• articolul „Corelarea și utilizarea standardelor pentru organizarea ciclurilor de viață ale sistemelor” de E.Z.
• textele GOST și alte standarde.

1. Probleme de bază în dezvoltarea de software

Când un programator-dezvoltator primește o sarcină de programare într-o formă sau alta, el, managerul de proiect și întreaga echipă de proiect se confruntă cu următoarele întrebări:

• ce ar trebui făcut în afară de programul propriu-zis?
• ce și cum ar trebui documentat?
• ce să transmit utilizatorilor și ce? serviciu de escortă?
• cum să gestionezi întreg acest proces?
• Ce ar trebui inclus în sarcina de programare în sine?

Pe lângă problemele menționate, mai sunt și altele.

Au răspuns odată standardele de stat pentru documentația software la acestea și la o mulțime de alte întrebări? set de standarde din a 19-a serie de GOST ESPD. Dar chiar și atunci, programatorii au avut o mulțime de plângeri cu privire la aceste standarde. Ceva trebuia să fie duplicat în documentație de multe ori (după cum părea - în mod nejustificat), și nu s-au prevăzut multe, cum ar fi, de exemplu, reflectarea specificului documentării programelor care lucrează cu o bază de date integrată.

În prezent rămâne problemă de actualitate despre prezența unui sistem de reglementare a documentației software-ului (PS).

2. Caracteristicile generale ale stării

Baza cadrului de reglementare intern în domeniul documentației software este un set de standarde ale Sistemului unificat de documentare a programelor (USPD). Partea principală și cea mai mare a complexului ESPD a fost dezvoltată în anii 70 și 80. Acum, acest complex este un sistem de standarde interstatale ale țărilor CSI (GOST), care operează pe teritoriu Federația Rusă bazat pe un acord interstatal privind standardizarea.

Standardele ESPD acoperă în principal acea parte a documentației care este creată în procesul de dezvoltare a software-ului și sunt asociate, în cea mai mare parte, cu documentarea caracteristicilor funcționale ale software-ului. Trebuie remarcat faptul că standardele ESPD (GOST 19) sunt de natură consultativă. Cu toate acestea, acest lucru se aplică și tuturor celorlalte standarde din domeniul PS (GOST 34, Standardul internațional ISO/IEC etc.). Cert este că, în conformitate cu Legea Federației Ruse „Cu privire la standardizare”, aceste standarde devin obligatorii pe bază contractuală - adică atunci când sunt menționate în contractul de dezvoltare (furnizare) a software-ului.

Vorbind despre starea DEUE în ansamblu, se poate afirma că majoritatea standardelor DEPD sunt depășite din punct de vedere moral.

Printre principalele dezavantaje ESPD pot fi atribuite:

• orientare către un singur model „în cascadă”. ciclu de viață(LC) PS;
• lipsa unor recomandări clare pentru documentarea caracteristicilor de calitate ale software-ului;
• lipsa unei legături sistemice cu alte sisteme de standarde interne existente pentru ciclul de viață și documentația produsului în general, de exemplu, ESKD;
• abordare neclară a documentării PS ca produs comercializabil;
• lipsa recomandărilor pentru auto-documentarea software-ului, de exemplu, sub formă de meniuri pe ecran și mijloace de asistență operațională pentru utilizator („ajutor”);
• lipsa recomandărilor privind compoziția, conținutul și proiectarea documentelor prospective privind PS, în concordanță cu recomandările standardelor internaționale și regionale.

Deci, ESPD are nevoie de o revizuire completă bazată pe standardul ISO/IEC 12207-95 pentru procesele ciclului de viață al software-ului (acest standard va fi discutat mai detaliat mai târziu).

Trebuie spus că, alături de complexul ESPD, oficialul cadrul de reglementare Federația Rusă în domeniul documentării software-ului și domeniilor conexe include o serie de standarde promițătoare (nivel intern, interstatal și internațional).

Standard internațional ISO/IEC 12207: 1995-08-01 pentru a organiza ciclul de viață al produselor software(software) - un standard aparent foarte vag, dar destul de nou și oarecum „la modă”.

Standarde complexe GOST 34 pentru crearea si dezvoltarea sisteme automatizate(AS) - generalizat, dar perceput ca foarte rigid în structura ciclului de viață și documentatia proiectului. Dar aceste standarde sunt considerate de mulți ca fiind birocratice până la nocive și conservatoare până la punctul de a fi depășite. În ce măsură acest lucru este adevărat și în ce măsură GOST 34 rămâne util, este util de înțeles.

În articolul său, E.Z Zinder se oprește în detaliu asupra metodologiei Oracle CDM(Custom Development Method) pentru dezvoltarea aplicației sisteme informatice la comandă - material specific, detaliat la nivelul spateurilor documentelor de proiectare, conceput pentru utilizare directă în proiecte NPP bazate pe instrumentele Oracle.

2.1. Scurtă introducere în standardele ESPD

Cu toate acestea, înainte de a revizui întregul complex, multe standarde ESPD pot fi utilizate util în practica documentării software-ului. Această poziție se bazează pe următoarele:

• Standardele ESPD introduc un element de ordonare în procesul de documentare a software-ului;
• Compoziția documentelor programului prevăzută de standardele ESPD nu este deloc atât de „rigidă” pe cât ar putea crede unii: standardele permit adăugarea unor tipuri suplimentare la setul de documentație pentru software
• Standardele ESPD permit, de asemenea, modificări flexibile în structură și conținut specii stabilite PD bazat pe cerințele clienților și utilizatorilor.

În același timp, stilul de aplicare a standardelor poate corespunde stilului general modern de adaptare a standardelor la specificul proiectului: clientul și managerul de proiect selectează un subset de standarde și PD care este adecvat pentru proiect, completează PD selectat cu secțiunile necesare și excluderea celor inutile, legați crearea acestor documente de schema ciclului de viață care este utilizată în proiect.

Standardele ESPD (precum și alte GOST) sunt împărțite în grupuri prezentate în tabel:

Desemnarea standardului ESPD se bazează pe criteriile de clasificare:

Desemnarea standardului DEPD trebuie să conțină:

• numărul 19 (atribuit clasei standardelor DEPD);
• o cifră (după punct) indicând codul grupului de clasificare a standardelor specificat în tabel;
• un număr din două cifre (după liniuță) care indică anul înregistrării standardului.

Lista documentelor DEPD

1. GOST 19.001-77 ESPD. Dispoziții generale.
2. GOST 19.101-77 ESPD. Tipuri de programe și documente de program.
3. GOST 19.102-77 ESPD. Etape de dezvoltare.
4. GOST 19.103-77 ESPD. Desemnarea programelor și documentelor programelor.
5. GOST 19.104-78 ESPD. Inscripții de bază.
6. GOST 19.105-78 ESPD. Cerințe generale pentru documentele programului.
7. GOST 19.106-78 ESPD. Cerințe pentru documentele de program tipărite.
8. GOST 19.201-78 ESPD. Specificatii tehnice. Cerințe pentru conținut și design.
9. GOST 19.202-78 ESPD. Caietul de sarcini. Cerințe pentru conținut și design.
10. GOST 19.301-79 ESPD. Procedura și metodologia de testare.
11. GOST 19.401-78 ESPD. Textul programului. Cerințe pentru conținut și design.
12. GOST 19.402-78 ESPD. Descrierea programului.
13. GOST 19.404-79 ESPD. Notă explicativă. Cerințe pentru conținut și design.
14. GOST 19.501-78 ESPD. Formă. Cerințe pentru conținut și design.
15. GOST 19.502-78 ESPD. Descrierea aplicației. Cerințe pentru conținut și design.
16. GOST 19.503-79 ESPD. Ghidul programatorului de sistem. Cerințe pentru conținut și design.
17. GOST 19.504-79 ESPD. Ghidul programatorului.
18. GOST 19.505-79 ESPD. Manual de utilizare.
19. GOST 19.506-79 ESPD. Descrierea limbii.
20. GOST 19.508-79 ESPD. Ghid pentru întreţinere. Cerințe pentru conținut și design.
21. GOST 19.604-78 ESPD. Reguli pentru efectuarea de modificări la documentele programului executate în tipărire.
22. GOST 19.701-90 ESPD. Scheme de algoritmi, programe, date și sisteme. Convenții și reguli de executare.
23. GOST 19.781-90. Software pentru sistemele de procesare a informațiilor.

Termeni și definiții

Dintre toate standardele ESPD, ne vom concentra doar pe cele care pot fi folosite mai des în practică.

În primul rând, vom indica un standard care poate fi utilizat la crearea sarcinilor de programare.

GOST (ST SEV) 19.201-78 (1626-79). ESPD. Specificatii tehnice. Cerințe pentru conținut și design. (Reeditat în noiembrie 1987 cu revizuirea 1).

Specificația tehnică (TOR) conține un set de cerințe pentru software și poate fi folosită ca criteriu pentru verificarea și acceptarea programului dezvoltat. Prin urmare, destul de complet compilată (ținând cont de posibilitatea de a introduce secțiuni suplimentare) și acceptată de client și dezvoltator, specificația tehnică este unul dintre documentele fundamentale ale proiectului PS.

Termenii de referință trebuie să conțină următoarele secțiuni:

• introducere;
• motive de dezvoltare;
• scopul dezvoltării;
• cerințe pentru un program sau un produs software;
• cerințe pentru documentația software;
• indicatori tehnico-economici;
• etape și stadii de dezvoltare;
• procedura de control si acceptare;
• Aplicațiile pot fi incluse în specificațiile tehnice.

În funcție de caracteristicile programului sau produsului software, este posibil să clarificați conținutul secțiunilor, să introduceți noi secțiuni sau să le combinați pe cele individuale.

Următorul standard
GOST (ST SEV) 19.101-77 (1626-79). ESPD. Tipuri de programe și documente de program (Reeditate în noiembrie 1987 cu amendamentul 1).
Stabilește tipuri de programe și documente de programe pentru calculatoare, complexe și sisteme, indiferent de scopul și scopul acestora.

Tipuri de programe

Tipuri de documente de program

Tipuri de documente operaționale

În funcție de metoda de implementare și de natura aplicării, documentele programului sunt împărțite în original, duplicat și copie (GOST 2.102-68), destinate dezvoltării, întreținerii și funcționării programului.

Tipuri de documente de program dezvoltate în diferite etape și codurile acestora

Permis să se combine specii individuale documente operaționale (cu excepția listei documentelor operaționale și a formularului). Necesitatea combinarii acestor documente este indicata in specificatiile tehnice. Documentului fuzionat i se atribuie numele și denumirea unuia dintre documentele comasate. Documentele fuzionate trebuie să specifice informațiile care trebuie incluse în fiecare document care este fuzionat.

GOST 19.102-77. ESPD. Etape de dezvoltare.

Stabilește etapele de dezvoltare a programelor și a documentației programelor pentru calculatoare, complexe și sisteme, indiferent de scopul și domeniul de aplicare al acestora

Etapele dezvoltării, etapele și conținutul muncii

Note:

1. Este permisă excluderea celei de-a doua etape de dezvoltare, iar în cazuri justificate tehnic - a doua și a treia etapă. Necesitatea acestor etape este indicată în specificațiile tehnice.
2. Este permisă combinarea, excluderea etapelor de lucru și (sau) conținutului acestora, precum și introducerea altor etape de lucru, așa cum sa convenit cu clientul.

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

Codul țării dezvoltatorului și codul organizației dezvoltatorului sunt atribuite în modul prescris.

• Pentru fiecare organizație de dezvoltare i se atribuie un număr de înregistrare în ordine crescătoare, începând de la 00001 la 99999.
• Numărul publicării programului sau numărul revizuirii. numărul unui document de acest tip, numărul părții de document sunt atribuite în ordine crescătoare de la 01 la 99. (Dacă documentul este format dintr-o singură parte, atunci cratima și numărul de serie al părții nu sunt indicate).
• Numărul de revizuire al caietului de sarcini și lista documentelor operaționale pentru program trebuie să se potrivească cu numărul de publicație al aceluiași program.

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

Acest standard stabilește cerințe generale pentru executarea documentelor de program pentru calculatoare, complexe și sisteme, indiferent de scopul și domeniul de aplicare al acestora și prevăzute de standardele Sistemului Unificat de Documentare a Programelor (USPD) pentru orice metodă de executare a documentelor pe diverse purtători de date.

Documentul programului poate fi prezentat pe diferite tipuri de medii de stocare și constă din următoarele părți convenționale:
titlu;
informativ;
de bază.

Regulile de executare a unui document și a părților acestuia pe fiecare suport de date sunt stabilite de standardele DEPD pentru regulile de executare a documentelor pe suporturile de date aferente.

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

Documentele programului sunt intocmite de:

• pe foi de format A4 (GOST 2.301-68) la pregătirea unui document prin dactilografiere sau scris de mână;
• Poate fi imprimat pe coli de dimensiune A3;
• cu metoda automată de execuție a documentelor sunt permise abateri de dimensiunea foilor corespunzătoare formatelor A4 și A3, determinate de capacitățile mijloacelor tehnice utilizate; pe coli de formate A4 și A3, prevăzute de caracteristicile de ieșire ale dispozitivelor de ieșire a datelor, la realizarea unui document cu mașina;
• pe foi de formate tipografice la realizarea unui document folosind o metodă tipografică.

Materialele documentului programului sunt aranjate în următoarea secvență:

Partea de titlu:

• fișa de aprobare (nu este inclusă în numărul total de foi ale documentului);
• pagina de titlu (prima pagină a documentului);

• adnotare;
• Cuprins;

• textul documentului (cu imagini, tabele etc.)
• lista de termeni și definițiile acestora;
• lista de abrevieri;
• aplicații;
• indexul subiectelor;
• lista documentelor de referinta;

• schimba foaia de inregistrare.

Dacă este necesar, sunt furnizate o listă de termeni și definițiile acestora, o listă de abrevieri, anexe, un index de subiecte, o listă de documente de referință.

Următorul standard se concentrează pe documentarea produsului de dezvoltare rezultat:

GOST 19.402-78 ESPD. Descrierea programului

Compoziția documentului „Descrierea programului” în conținutul său poate fi completată cu secțiuni și paragrafe preluate din standardele pentru alte documente și manuale descriptive: GOST 19.404-79 ESPD. Notă explicativă, GOST 19.502-78 ESPD. Descrierea aplicației, GOST 19.503-79 ESPD. Ghidul programatorului de sistem, GOST 19.504-79 ESPD. Ghidul programatorului, GOST 19.505-79 ESPD. Manual de utilizare.

Există, de asemenea, un grup de standarde care definesc cerințele pentru înregistrarea întregului set de programe și PD care sunt întocmite pentru transferul de software. Acestea generează documente contabile concise și pot fi utile pentru eficientizarea întregului management al programelor și PD (la urma urmei, de foarte multe ori trebuie doar să restabiliți ordinea de bază!). Există, de asemenea, standarde care definesc regulile de păstrare a documentelor în „gospodăria” PS.

De asemenea, trebuie să subliniem

GOST 19.301-79 ESPD. Program și metodologie de testare, care (în formă adaptată) pot fi utilizate pentru a dezvolta documente de planificare și pentru a efectua lucrări de testare pentru a evalua pregătirea și calitatea stației.

În sfârșit, cel mai recent standard în funcție de anul adoptării.

GOST 19.701-90 ESPD. Scheme de algoritmi, programe, date și sisteme. Denumiri grafice convenționale și reguli de execuție.

Stabilește reguli de implementare a diagramelor utilizate pentru a reprezenta diferite tipuri de probleme de prelucrare a datelor și mijloace de rezolvare a acestora și este pe deplin în conformitate cu standardul ISO 5807:1985.

Alături de ESPD, la nivel interstatal sunt în vigoare încă două standarde, legate de asemenea de documentarea PS și adoptate nu cu mult timp în urmă ca majoritatea ESPD GOST.

GOST 19781-90 Software pentru sisteme de procesare a informațiilor. Termeni și definiții. Dezvoltat pentru a înlocui GOST 19.781-83 și GOST 19.004-80 și stabilește termenii și definițiile conceptelor în domeniul software (software) al sistemelor de prelucrare a datelor (SOD), utilizate în toate tipurile de documentație și literatură incluse în sfera muncii de standardizare sau folosind rezultatele acestei lucrări .

GOST 28388-89 Sisteme de procesare a informațiilor. Documente pe medii de stocare magnetice. Ordinea de executare si manipulare. Se aplică nu numai software-ului, ci și documentelor de proiectare, tehnologice și de altă natură executate pe suport magnetic.

2.2. Standardele complexului GOST 34

GOST 34 a fost conceput la sfârșitul anilor 80 ca un set cuprinzător de documente intersectoriale interconectate. Motivele și rezultatele rezultate sunt descrise mai jos în „Caracteristicile” GOST 34. Obiectele standardizării sunt difuzoare de diferite (orice!) tipuri și toate tipurile de componente ale acestora, și nu doar software și baze de date.

Complexul este conceput pentru interacțiunea dintre client și dezvoltator. Similar cu ISO12207, se prevede ca clientul să poată dezvolta difuzoare pentru el însuși (dacă creează o divizie specializată pentru aceasta). Cu toate acestea, formularea GOST 34 nu este orientată către o reflectare atât de explicită și, într-un anumit sens, simetrică a acțiunilor ambelor părți precum ISO12207. Deoarece GOST 34 acordă în principal atenție conținutului documentelor de proiect, distribuirea acțiunilor între părți se face de obicei pe baza acestui conținut.

Dintre toate grupurile de documente existente și neimplementate, ne vom baza doar pe Grupa 0 „Dispoziții generale” și Grupa 6 „Crearea, funcționarea și dezvoltarea AS”. Cele mai populare standarde pot fi considerate GOST 34.601-90 (Etapele creării unui AS), GOST 34.602-89 (TK pentru crearea unui AS) și liniile directoare RD 50-34.698-90 (Cerințe pentru conținutul documentelor). Standardele prevăd etapele și etapele de lucru pentru a crea un AS, dar nu prevăd în mod explicit procese end-to-end.

Pentru cazul general al dezvoltării AS, etapele și etapele GOST 34 sunt prezentate în tabel:

Este descris conținutul documentelor elaborate în fiecare etapă. Aceasta determină potențialul de identificare la nivel de fond a lucrărilor de la capăt la capăt efectuate în paralel sau secvențial (adică, în esență, procese) și sarcinile lor constitutive. Această tehnică poate fi utilizată atunci când se construiește un profil al standardelor ciclului de viață al proiectului, inclusiv subseturile convenite ale standardelor GOST 34 și ISO12207.

Motivul principal: rezolvarea problemei „Turnului Babel”.

În anii 80, a apărut o situație în care diverse industrii și domenii de activitate au folosit NTD prost coordonat sau inconsecvent - „documentație normativă și tehnică”. Acest lucru a făcut dificilă integrarea sistemelor și asigurarea funcționării lor comune efective. Au existat diverse complexe și sisteme de standarde care stabileau cerințe pentru diverse tipuri AC.

Practica aplicării standardelor a arătat că ele în esență (dar nu conform definițiilor stricte) aplică un sistem unificat de concepte, există multe obiecte comune de standardizare, dar cerințele standardelor nu sunt în concordanță între ele, există diferențe în compoziția și conținutul lucrării, diferențele de desemnare, compoziție, conținut și execuție a documentelor etc.

Desigur, această situație a reflectat parțial diversitatea naturală a condițiilor de dezvoltare a SA, obiectivele dezvoltatorilor și abordările și tehnicile utilizate.

În aceste condiții, a fost posibil să se analizeze o astfel de diversitate și apoi să se procedeze, de exemplu, într-unul din cele două moduri în mare măsură opuse:

1. Dezvoltarea unui sistem conceptual și terminologic generalizat, schema generala dezvoltarea, un set general de documente cu conținutul lor și definirea acestora ca fiind obligatorii pentru toate AS;
2. Definiți și un sistem conceptual și terminologic general, un complex generalizat cerinţele de sistem, un set de criterii de calitate, dar oferă libertate maximă în alegerea schemei de dezvoltare, alcătuirea documentelor și alte aspecte, impunând doar un minim cerințe obligatorii, care ar permite:
   • determina nivelul de calitate al rezultatului;
   • selectați acele metode specifice (cu modelele lor de ciclu de viață, setul de documente etc.) care sunt cele mai potrivite condițiilor de dezvoltare și corespund Tehnologiilor Informaționale utilizate;
   • astfel lucrați cu restricții minime asupra acțiunilor eficiente ale designerului difuzorului.

Dezvoltatorii setului de standarde 34 au ales o metodă apropiată de prima dintre cele indicate mai sus, adică au luat o cale mai apropiată de schemele metodelor specifice decât de standarde precum ISO12207. Cu toate acestea, datorită generalității bazei conceptuale, standardele rămân aplicabile într-o gamă foarte largă de cazuri.

Gradul de adaptabilitate este determinat formal de capacitățile:

• se omite etapa de proiectare preliminară și se combină etapele „Proiectare tehnică” și „Documentație detaliată”;
• omiteți pași, combinați și omiteți majoritatea documentelor și secțiunile acestora;
• intra documente suplimentare, secțiuni de documente și lucrări;
• creând dinamic așa-numitul. ChTZ - specificații tehnice private - este destul de flexibil pentru a forma ciclul de viață al AS; De regulă, această tehnică este utilizată la nivelul unităților mari (subsisteme, complexe), pentru care se consideră justificată crearea unei CTZ, dar nu există motive semnificative pentru a limita sever această metodă de management al ciclului de viață.

Etapele și reperele realizate de organizațiile care participă la crearea centralelor nucleare sunt stabilite în contracte și specificații tehnice, ceea ce se apropie de abordarea ISO.

Introducerea unei terminologii unificate, destul de definită calitativ, prezența unei clasificări destul de rezonabile a lucrărilor, documentelor, tipurilor de suport etc. este cu siguranță utilă. GOST 34 contribuie la o îmbinare mai completă și de înaltă calitate a sistemelor cu adevărat diferite, ceea ce este deosebit de important în condițiile în care sunt dezvoltate sisteme integrate din ce în ce mai complexe, de exemplu, cum ar fi CAD-CAM, care includ un sistem de control al procesului, un sistem de control, un designer CAD, un tehnolog CAD, ASNI și alte sisteme.

Au fost definite mai multe prevederi importante care reflectă caracteristicile AS ca obiect de standardizare, de exemplu: „în general, AS este format din software și hardware (PTK), software și complexe metodologice (PMK) și componente individuale ale organizației, suport tehnic, software și informațional.”

Separarea conceptelor PTC și AS a consacrat principiul conform căruia AS nu este un „IS cu o bază de date”, ci:

• „un sistem organizatoric și tehnic care asigură dezvoltarea de soluții bazate pe automatizarea proceselor informaționale în diverse domenii activități (management, proiectare, producție etc.) sau combinațiile acestora” (conform RD 50-680-88), care este deosebit de relevant în aspectele de reinginiere a afacerilor;
• „un sistem format din personal și un set de instrumente de automatizare pentru activitățile lor, care implementează tehnologia informației pentru îndeplinirea funcțiilor stabilite” (conform GOST 34.003-90).

Aceste definiții indică faptul că SA este, în primul rând, personalul care ia decizii și realizează alte acțiuni de management, susținut de mijloace organizatorice și tehnice.

Gradul de obligație:

cerința anterioară obligatorie completă lipsește, materialele GOST34 au devenit în esență suport metodologic, mai des pentru clienții care au în standard un set de cerințe pentru conținutul specificațiilor tehnice și efectuarea testelor NPP. În același timp, utilitatea GOST34 poate crește de multe ori dacă sunt utilizate mai flexibil în formarea profilului ciclului de viață AS.

Documentul cheie pentru interacțiunea dintre părți îl reprezintă specificațiile tehnice pentru crearea CNE. Specificația tehnică este principalul document sursă pentru crearea AS și acceptarea acestuia determină cele mai importante puncte de interacțiune între client și dezvoltator; În acest caz, specificațiile tehnice sunt elaborate de organizația dezvoltatorului (conform GOST 34.602-89), dar clientul emite în mod oficial specificațiile tehnice dezvoltatorului (conform RD 50-680-88).

2.3. Standardele de stat ale Federației Ruse (GOST R)

Federația Rusă are o serie de standarde pentru documentarea software-ului, dezvoltate pe baza aplicării directe a standardelor internaționale ISO. Acest? cele mai recente standarde la momentul adoptării. Unele dintre ele se adresează direct managerilor de proiect sau directorilor de servicii de informare. În același timp, ele sunt nerezonabil de puțin cunoscute în rândul profesioniștilor. Iată prestația lor.

GOST R ISO/IEC 9294-93 Tehnologia de informație. Ghid de gestionare a documentației software. Standardul este pe deplin în concordanță cu standardul internațional ISO/IEC TO 9294:1990 și stabilește recomandări pentru management eficient software de documentare pentru managerii responsabili de crearea acestora. Scopul standardului este de a ajuta la definirea unei strategii de documentare a software-ului; alegerea standardelor de documentare; alegerea procedurilor de documentare; determinarea resurselor necesare; întocmirea planurilor de documentare.

GOST R ISO/IEC 9126-93 Tehnologia de informație. Evaluarea produselor software. Caracteristici de calitate și linii directoare pentru utilizarea lor. Standardul respectă pe deplin standardul internațional ISO/IEC 9126:1991. În contextul său, o caracteristică de calitate este înțeleasă ca „un set de proprietăți (atribute) unui produs software prin care calitatea acestuia este descrisă și evaluată”. Standardul definește șase caracteristici cuprinzătoare care, cu o dublare minimă, descriu calitatea software-ului (software, produse software): funcţionalitate; fiabilitate; caracter practic; eficienţă; acompaniament; mobilitate. Aceste caracteristici formează baza pentru clarificarea și descrierea ulterioară a calității software-ului.

GOST R ISO 9127-94 Sisteme de prelucrare a informațiilor. Documentația utilizatorului și informațiile de ambalare pentru pachetele software de consum. Standardul respectă pe deplin standardul internațional ISO 9127:1989. În sensul acestui standard, un pachet software de consum (CPP) este definit ca „un produs software conceput și vândut pentru a îndeplini o funcție specifică, programul și documentația asociată acestuia, ambalate pentru vânzare ca o singură unitate”. Documentația utilizatorului se referă la documentația care oferă utilizatorului final informații despre instalarea și funcționarea software-ului. Informațiile de pe ambalaj înseamnă informații reproduse pe ambalaj exterior PP. Scopul său este de a oferi potențialilor cumpărători informații primare despre software.

GOST R ISO/IEC 8631-94 Tehnologia de informație. Constructii software si simboluri pentru prezentarea lor. Descrie prezentarea algoritmilor procedurali.

2.4. Standardul internațional ISO/IEC 12207: 1995-08-01

Prima ediție a ISO12207 a fost pregătită în 1995 de către comitetul tehnic comun ISO/IEC JTC1 " Tehnologia de informație,Subcomitetul SC7, Inginerie software."

Prin definiție, ISO12207 este standardul de bază pentru procesele ciclului de viață al software-ului, axat pe diverse (orice!) tipuri de software și tipuri de proiecte AS, din care software-ul este inclus ca parte. Standardul defineşte strategia şi ordine generalăîn crearea și operarea software-ului, acesta acoperă ciclul de viață al software-ului de la conceptualizarea ideilor până la finalizarea ciclului de viață.

NOTE foarte importante ALE STANDARDULUI:

1. Procesele utilizate în timpul ciclului de viață al software-ului trebuie să fie compatibile cu procesele utilizate în timpul ciclului de viață al AS. (Prin urmare, oportunitatea utilizării în comun a standardelor AS și software este clară.)
2. Adăugarea de procese, activități și sarcini unice sau specifice trebuie specificată în contractul dintre părți. Contractul este înțeles într-un sens larg: de la un contract formalizat legal la un acord informal, un acord poate fi definit de o singură parte ca o sarcină stabilită pentru sine.
3. Standardul nu conține în principiu metode specifice de acțiune, cu atât mai puțin soluții pregătite sau documentație. Descrie arhitectura proceselor ciclului de viață al software-ului, dar nu specifică în detaliu cum să implementeze sau să execute serviciile și sarcinile incluse în procese și nu are scopul de a prescrie numele, formatul sau conținutul exact al documentației rezultate. Deciziile de acest tip sunt luate de utilizatorul standardului.

DEFINIȚII STANDARD:

1. Un sistem este o combinație de unul sau mai multe procese, hardware, software, echipamente și oameni pentru a permite satisfacerea nevoilor sau obiectivelor specificate.
2. Modelul ciclului de viață- o structură care conține procese, acțiuni și sarcini care sunt efectuate în timpul dezvoltării, exploatării și întreținerii produs software pe toată durata de viață a sistemului, de la definirea cerințelor până la finalizarea utilizării acestuia.
   Multe procese și sarcini sunt proiectate astfel încât să poată fi adaptate în conformitate cu proiectele software. Procesul de adaptare este procesul de eliminare a proceselor, activităților și sarcinilor care nu sunt aplicabile unui anumit proiect. Gradul de adaptabilitate: maxim
3. Cerința de calificare- un set de criterii sau condiții ( cerințe de calificare) care trebuie să fie îndeplinite pentru a califica un produs software ca fiind conform (satisfăcând condițiile) specificațiilor sale și gata de utilizare în mediul țintă.

Standardul nu cere model specific Ciclul de viață sau metoda de dezvoltare a software-ului, dar precizează că părțile la utilizarea standardului sunt responsabile pentru selectarea unui model de ciclu de viață pentru un proiect software, pentru adaptarea proceselor și sarcinile standardului la acest model, pentru selectarea și aplicarea metodelor de dezvoltare software , pentru realizarea acțiunilor și sarcinilor adecvate pentru proiectul software.

Standardul ISO12207 este axat în egală măsură pe organizarea acțiunilor fiecăreia dintre cele două părți: furnizorul (dezvoltatorul) și cumpărătorul (utilizatorul); poate fi aplicat în mod egal atunci când ambele părți sunt din aceeași organizație.

Fiecare proces ciclului de viață este împărțit într-un set de acțiuni, fiecare acțiune într-un set de sarcini. O diferență foarte importantă între ISO: fiecare proces, acțiune sau sarcină este inițiată și executată de un alt proces după cum este necesar și nu există secvențe predeterminate (desigur, menținând în același timp logica conexiunilor conform informațiilor inițiale ale sarcinilor etc. ).

Standardul ISO12207 descrie:

1. 5 procese principale ale ciclului de viață al software-ului:
   • Procesul de achiziție. Determină acțiunile întreprinderii cumpărătoare care achiziționează AS, produs software sau serviciu software.
   • Procesul de livrare. Definește acțiunile companiei furnizor care furnizează cumpărătorului un sistem, produs software sau serviciu software.
   • Procesul de dezvoltare. Determină acțiunile întreprinderii de dezvoltare, care dezvoltă principiul construirii unui produs software și al produsului software.
   • Proces de funcționare. Definește acțiunile companiei operator, care asigură întreținerea sistemului (și nu doar software-ul) în timpul funcționării acestuia în interesul utilizatorilor. Spre deosebire de acțiunile care sunt determinate de dezvoltator în instrucțiunile de operare (această activitate de dezvoltator este prevăzută în toate cele trei standarde luate în considerare), acțiunile operatorului de a consulta utilizatorii, de a obține feedback etc., pe care le planifică el însuși și își asumă responsabilitățile corespunzătoare.
   • Proces de întreținere. Determină acțiunile personalului de asistență care asigură întreținerea produsului software, care este gestionarea modificărilor produsului software, suportul acestuia starea actualăși adecvarea funcțională, include instalarea și îndepărtarea unui produs software pe un sistem informatic.
2. 8 procese auxiliare care susțin implementarea unui alt proces, fiind parte integrantă a întregului ciclu de viață al unui produs software și asigură calitatea corespunzătoare a proiectului software:
   • rezolvarea problemelor;
   • documentare;
   • managementul configurației;
   • asigurarea calității, care utilizează rezultatele proceselor rămase ale grupului de asigurare a calității, care include:
     • Procesul de verificare;
     • Procesul de certificare;
     • Procesul de evaluare participativă;
     • Procesul de audit.
3. 4 procese organizatorice:
   • Procesul de management;
   • Procesul de creare a infrastructurii;
   • proces de îmbunătățire;
   • Procesul de învățare.

Acestea sunt însoțite de un Proces special de Adaptare, care definește principalele acțiuni necesare pentru adaptarea standardului la condițiile unui anumit proiect.

Procesul de îmbunătățire aici nu înseamnă îmbunătățirea AS sau a software-ului, ci îmbunătățirea proceselor de achiziție, dezvoltare, asigurare a calității etc., derulate efectiv în organizație.

Nu sunt prevăzute etape, faze, etape, ceea ce dă gradul de adaptabilitate descris mai jos.

Natura „dinamică” a standardului este determinată de modul în care procesele și sarcinile sunt secvențiate, în care un proces îl numește pe altul sau o parte din acesta atunci când este necesar.

• executarea Procesului de Achiziție în ceea ce privește cerințele de analiză și înregistrare pentru un sistem sau software poate declanșa executarea sarcinilor corespunzătoare Procesului de Dezvoltare;
• În Procesul de Livrare, furnizorul trebuie să gestioneze subcontractanții în conformitate cu Procesul de Achiziție și să efectueze verificarea și calificarea în raport cu procesele relevante;
• Întreținerea poate necesita dezvoltarea sistemului și a software-ului, care se realizează conform Procesului de Dezvoltare.

Această natură face posibilă implementarea oricărui model de ciclu de viață.

Atunci când se efectuează analiza cerințelor software, există 11 clase de caracteristici de calitate care sunt utilizate ulterior în asigurarea calității.

În acest caz, dezvoltatorul trebuie să stabilească și să documenteze ca cerințe software:

1. Specificații funcționale și de activare, inclusiv execuția, caracteristicile fizice și condițiile mediului de operare în care trebuie să fie executat elementul software;
2. Conexiuni externe (interfețe) cu unitatea software;
3. Cerințe de calificare;
4. Specificațiile de fiabilitate, inclusiv specificațiile legate de metodele de operare și întreținere, impact mediuși probabilitatea de vătămare a personalului;
5. Specificații de securitate
6. Specificațiile factorilor umani pentru psihologia ingineriei (ergonomie), inclusiv cele legate de controlul manual, interacțiunea om-echipament, constrângerile de personal și domeniile care necesită atenție umană concentrată, care sunt sensibile la eroarea umană și la învățare;
7. Definirea cerințelor de date și baze de date;
8. Cerințe de instalare și acceptare a produsului software furnizat la locurile de operare și întreținere (exploatare);
9. documentatie utilizator;
10. Munca utilizatorului și cerințele de performanță;
11. Cerințe de servicii pentru utilizatori.

(Este interesant și important ca aceste caracteristici și similare să corespundă bine cu caracteristicile NPP prevăzute în GOST 34 pentru tipurile de suport de sistem.)

Standardul conține foarte puține descrieri care vizează proiectarea bazelor de date. Acest lucru poate fi considerat justificat, deoarece sisteme diferite și pachete software de aplicații diferite nu pot utiliza numai tipuri foarte specifice de baze de date, dar nici nu pot utiliza

Deci, ISO12207 are un set de procese, activități și sarcini care acoperă cea mai largă gamă posibilă de situații posibile cu adaptabilitate maximă.

Acesta arată un exemplu despre cum ar trebui să fie construit un standard bine organizat, care să conțină un minim de restricții (principiul „nu există două proiecte la fel”). În același timp, este recomandabil să se includă definiții detaliate ale proceselor, formelor de documente etc. în diverse standarde funcționale, departamentale documente de reglementare sau tehnici de proprietate care pot fi sau nu utilizate într-un anumit proiect.

Din acest motiv, este util să se considere ISO12207 ca standard central, ale cărui prevederi sunt luate ca setul inițial de prevederi „de bază” în procesul de construire a unui profil al standardelor ciclului de viață pentru un anumit proiect. Acest „nucleu” poate defini un model de ciclu de viață software și AS, un concept de asigurare a calității și un model de management de proiect

Practicanții folosesc un alt mod: îl traduc ei înșiși și îl folosesc în proiectele lor standarde moderne pentru organizarea ciclului de viata al statiei si documentatia acestora. Dar această cale suferă cel puțin de dezavantajul că diferitele traduceri și adaptări ale standardelor realizate de diferiți dezvoltatori și clienți vor diferi în multe detalii. Aceste diferențe privesc inevitabil nu numai denumirile, ci și definițiile lor substanțiale introduse și utilizate în standarde. Astfel, pe această cale, apariția constantă a confuziei este inevitabilă, iar aceasta este direct opusă obiectivelor nu numai ale standardelor, ci și ale oricăror documente metodologice competente.

În prezent, Institutul de Cercetare a Standardelor All-Russian a pregătit propuneri pentru îmbunătățirea și dezvoltarea unui set de standarde pentru documentarea software-ului.

Informații de fundal

Pentru a achiziționa standarde de documentare, vă recomandăm să contactați următoarele organizații:

IPK „Standarde de publicare”, Departamentul teritorial de distribuție a documentației științifice și tehnice (magazinul „Standarde”), 17961, Moscova, st. Donskaya, 8, tel. 236-50-34, 237-00-02, fax/tel. 236-34-48 (privind GOST și GOST R).

Standardele ESPD (ca și alte GOST) sunt împărțite în grupuri,

Dispoziții generale;

Standarde fundamentale;

Reguli de executare a documentației;

Reguli de implementare a documentației operaționale;

Reguli de circulație a documentației software;

Grupuri de rezervă;

Alte standarde.

ESPD include următoarele GOST-uri:

GOST 19.001-77 ESPD. Dispoziții generale.

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. Desemnarea 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. Specificatii tehnice. Cerințe pentru conținut și design.

GOST 19.202-78 ESPD. Caietul de sarcini. Cerințe pentru conținut și design.

GOST 19.301-79 ESPD. Procedura și metodologia de testare.

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 conținut și design.

GOST 19.502-78 ESPD. Descrierea aplicației. Cerințe pentru conținut și design.

GOST 19.503-79 ESPD. Ghidul programatorului de sistem. Cerințe pentru conținut și design.

GOST 19.504-79 ESPD. Ghidul programatorului. Cerințe pentru conținut și design.

GOST 19.505-79 ESPD. Manual de utilizare. Cerințe pentru conținut și design.

GOST 19.506-79 ESPD. Descrierea limbii. Cerințe pentru conținut și design.

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 de program tipărite.

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

GOST 19.604-78 ESPD. Reguli pentru efectuarea de modificări la documentele programului executate în tipărire.

Prin Decretul Comitetului de Stat pentru Standarde al URSS din 18 decembrie 1978 nr. 3350, a fost stabilită data introducerii

din 01/01/1980

Acest standard stabilește cerințe generale pentru pregătirea documentelor de program pentru calculatoare, complexe și sisteme, indiferent de scopul și domeniul de aplicare al acestora și prevăzute de standardele Sistemului Unificat de Documentare a Programelor (USPD) pentru orice metodă de executare a documentelor pe diverse purtători de date.

Standardul respectă ST SEV 2088-80 în ceea ce privește cerințele generale pentru proiectarea părții de informații (a se vedea anexa de referință).

1. CERINȚE GENERALE

3. PARTEA INFORMAȚII

3.1 . Partea de informare ar trebui să conțină un rezumat și conținut.

3.2 Necesitatea includerii părții informaționale în diferitele tipuri de documente de program este stabilită de standardele relevante ale DEUE pentru aceste documente.

3.3 . Adnotarea oferă informații despre scopul documentului și un scurt rezumat al părții sale principale.

3.4 . Conținutul include o listă de înregistrări despre elementele structurale ale părții principale a documentului, fiecare dintre acestea incluzând:

desemnarea unui element structural (număr de secțiune, subsecțiune etc.);

denumirea elementului structural;

adresa elementului structural de pe suportul de stocare (de exemplu, numărul paginii, numărul fișierului etc.);

Regulile de desemnare a elementelor structurale ale părții principale a documentului și adresarea acestora sunt stabilite de standardele DEPD pentru regulile de execuție a documentelor pe suporturile de date adecvate.