Exemplu de descriere a programului GOST 19.402 78. Curs de tineri luptători: Cu privire la pregătirea documentației programului (documentație). Sistem unificat de documentare a programului

G O S U D A R S T V E N N Y S T A N D A R T S O Y W A S S R

Sistem unificat de documentare a programului	GOST 19.402-78* (ST SEV 2092-80)

DESCRIEREA PROGRAMULUI

Sistem unit pentru documentarea programului. Descrierea programului

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

din 01.01. 1980

1. Acest standard stabilește compoziția și cerințele pentru conținutul documentului de program „Descrierea programului”, definit de GOST 19.101-77.

Standardul respectă pe deplin ST SEV 2092-80.

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

Întocmirea părții de informare (adnotări și conținut) este obligatorie.

3. Descrierea programului trebuie să conțină următoarele secțiuni:

Informații generale;
scop funcțional;
descrierea structurii logice;
date de intrare;
date de ieșire.

În funcție de caracteristicile programului, este posibil să introduceți secțiuni suplimentare sau să combinați secțiuni individuale.

4. În secțiunea „Informații generale” trebuie indicate următoarele:

denumirea și denumirea programului;
software-ul necesar pentru funcționarea programului;
limbaje de programare în care este scris programul.

5. Secțiunea „Scopul funcțional” trebuie să indice clasele de probleme care se rezolvă și (sau) scopul programului și informații despre restricțiile funcționale de utilizare.

6. În secțiunea „Descrierea structurii logice” ar trebui să fie indicate următoarele:

algoritmul programului;
metodele utilizate;
structura programului cu o descriere a funcțiilor componentelor sale și a conexiunilor dintre acestea;
conectarea programului cu alte programe.

Descrierea structurii logice a programului se realizează ținând cont de textul programului în limba sursă.

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

7. Secțiunea „Unelte tehnice utilizate” trebuie să indice tipurile de computere și dispozitive electronice care sunt utilizate la rularea programului.

metoda de apelare a programului de pe mediul de stocare corespunzător;
puncte de intrare în program.

Puteți specifica adrese de descărcare, informații despre utilizarea RAM și dimensiunea programului.

9. În secțiunea „Date de intrare” trebuie să fie indicate următoarele:

natura, organizarea și pregătirea prealabilă a datelor de intrare;
format, descriere și metoda de codificare a datelor de intrare.

10. În secțiunea „Date de ieșire” trebuie să fie indicate următoarele:

natura și organizarea datelor de ieșire;
format, descriere și metoda de codificare a datelor de ieșire.

11. Este permisă ilustrarea conținutului secțiunilor cu exemple explicative, tabele, diagrame, grafice.

12. Anexa la descrierea programului poate include diverse materiale care nu pot fi incluse în secțiuni ale descrierii.

7-12.(Introdus suplimentar, amendamentul nr. 1).

* Reeditare (noiembrie 1987) cu modificarea nr. 1, aprobată în septembrie 1981 (IUS 11-81)

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

din 01/01/1980

1. Acest standard stabilește compoziția și cerințele pentru conținutul documentului de program „Descrierea programului”, definit de GOST 19.101-77.

Standardul respectă pe deplin ST SEV 2092-80.

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

Întocmirea părții de informare (adnotări și conținut) este obligatorie.

3. Descrierea programului trebuie să conțină următoarele secțiuni:

Informații generale;

scop funcțional;

descrierea structurii logice;

date de intrare;

date de ieșire.

În funcție de caracteristicile programului, este posibil să introduceți secțiuni suplimentare sau să combinați secțiuni individuale.

4. În secțiunea „Informații generale” trebuie să fie indicate următoarele:

denumirea și denumirea programului;

software-ul necesar pentru funcționarea programului;

limbaje de programare în care este scris programul.

5. Secțiunea „Scopul funcțional” trebuie să indice clasele de probleme rezolvate și (sau) scopul programului și informații despre restricțiile funcționale ale aplicației.

6. În secțiunea „Descrierea structurii logice” ar trebui să fie indicate următoarele:

algoritmul programului;

metodele utilizate;

structura programului prin descrierea funcțiilor părților sale componente și a conexiunilor dintre acestea;

conectarea programului cu alte programe.

Descrierea structurii logice a programului se realizează ținând cont de textul programului în limba sursă.

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

7. Secțiunea „Unelte tehnice utilizate” trebuie să indice tipurile de dispozitive electronice de calculator care sunt utilizate la rularea programului.

metoda de apelare a programului de pe mediul de stocare corespunzător;

puncte de intrare în program.

Puteți specifica adrese de descărcare, informații despre utilizarea RAM și dimensiunea programului.

9. În secțiunea „Date de intrare” trebuie să fie indicate următoarele:

natura, organizarea și pregătirea prealabilă a datelor de intrare;

format, descriere și metoda de codificare a datelor de intrare.

10. În secțiunea „Date de ieșire” trebuie să fie indicate următoarele:

natura și organizarea datelor de ieșire;

format, descriere și metoda de codificare a datelor de ieșire.

11. Este permisă ilustrarea conținutului secțiunilor cu exemple explicative, tabele, diagrame, grafice.

12. În anexa la descrierea programului este permisă includerea diferitelor materiale care nu sunt adecvate pentru a fi incluse în secțiunile descrierii.

7-12. (Introdus suplimentar, amendamentul nr. 1).

V.E. Karpov

Acest document conține o scurtă descriere a standardelor ESPD, a căror cunoaștere este necesară pentru ca studenții să finalizeze cursurile și proiectele legate de crearea de sisteme software. În plus, poate fi util din punctul de vedere al îmbunătățirii calității documentației software în general.

SPECIFICAȚII TEHNICE (GOST 19.201-78)

1. Dispoziții generale

ETAPE DE DEZVOLTARE (GOST 19.102-77)

DESCRIEREA PROGRAMULUI (GOST 19.402-78)

TEXTUL PROGRAMULUI (GOST 19.401-78)

PROGRAM ȘI METODOLOGIA DE TESTARE (GOST 19.301-79)

CERINȚE PENTRU DOCUMENTELE SOFTWARE TIPARATE (GOST 19.106-78)

Standardizare în domeniul documentației software

Cum să mergi înainte

Pregătirea documentației pentru software (PS) în conformitate cu GOST-urile existente

2. Caracteristicile generale ale stării

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

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

Poate cea mai neplăcută și dificilă etapă a activității de programare este crearea documentației programului. Din păcate, de obicei acest lucru fie nu este predat deloc, fie, în cel mai bun caz, nu acordă atenția cuvenită calității documentelor primite. Cu toate acestea, stăpânirea acestei arte este adesea unul dintre cei mai importanți factori care determină calitatea unui programator.

În primul rând, capacitatea de a crea documentația programului determină nivelul profesional al programatorului. Clientul nu se va adânci în complexitățile și caracteristicile celui mai minunat program. Clientul va citi mai întâi documentația. Factorul psihologic joacă, de asemenea, un rol important în acest sens. În special, fosta școală sovietică de programare a fost (și este acum) apreciată în întreaga lume. Programatorii autohtoni moderni au încetat să fie citați. Clasa nu este aceeași. În zilele noastre programele nu mai sunt scrise, ci compilate (și acestea sunt „două mari diferențe”). Deci, un pachet de documentație software (denumit în continuare PD) creat în stil „clasic” va crea cea mai favorabilă impresie asupra clientului sau angajatorului dumneavoastră. Mai mult, dacă autorul PD evită expresii precum „click pe scrollbar...”, „șurub”, etc. Din păcate, o astfel de vorbărie argotică ascunde de obicei fie o lipsă de gânduri, fie un gol complet (autorul a fost impresionat de neșters de povestea unuia dintre cunoscuții săi despre un anume „jucător” care fie „conversa” cu cineva, fie era angajat în „moderare” sau asa ceva.). Limbajul PD este un fel de limbaj birocratic, foarte conservator. Are propriul farmec aparte. Sunteți de acord că termenii unitate de disc, unitate de disc plat, manipulator portabil, cum ar fi „mouse” (sau „coclă”, așa cum era scris în unul dintre vechile pachete PD) sună complet diferit de „șurubul” corespunzător, „ flop” și pur și simplu „mouse”. Apropo, lucrurile au ajuns deja în punctul în care, spun ei, a apărut chiar și o specialitate specială - scriitor tehnic, adică. o persoană care știe să creeze documentație software.

În al doilea rând, un pachet PD bine conceput (mai precis, creat) vă va scuti de multe necazuri. În special, puteți scăpa de întrebările enervante și de afirmațiile nefondate prin simpla trimitere a utilizatorului la documentație. Acesta se referă, în primul rând, la cel mai important document - Termenii de referință. Vom vorbi despre asta mai jos, dar acum vă putem aminti de procesul de mai multe milioane de dolari împotriva IBM. Acest proces a fost intentat de o editură mare, nemulțumită de calitatea VT și a software-ului. IBM a câștigat cazul. Și a câștigat doar pentru că a prezentat Termenii de Referință semnat de ambele părți. Acest lucru s-a întâmplat cu mult timp în urmă, în anii 70, dar asta nu schimbă esența problemei.

Și încă un lucru. Este important să creați primul pachet PD. Acest lucru va fi suficient pentru a construi toate cele ulterioare pe baza sa, folosindu-l ca model sau șablon. Dar acest lucru trebuie făcut foarte eficient. Nu vă grăbiţi. Foarte temeinic.

Mai întâi trebuie să vă înarmați cu standardele GOST. GOST definește totul. În special, include Sistemul Unificat de Documentare a Programelor (USPD) care ne interesează. Poate cel mai dificil lucru este să obțineți GOST-ul în sine. GOST ar trebui să fie numai în formă originală tipărită. Se vând (cel puțin așa era înainte) în magazine speciale. În special, pentru a obține standarde în domeniul documentației, puteți contacta următoarele organizații:

IPK „Standarde de publicare”, Departamentul teritorial de distribuție al NTD (magazinul „Standarde”), 17961, Moscova, st. Donskaya, 8, tel. 236-50-34, 237-00-02, fax/tel. 236-34-48 (privind GOST și GOST R).
VNIIKI Gosstandart al Rusiei (sala de lectură), 103001, Moscova, Granatny per. nr. 4, tel. 290-50-94 (privind standarde internaționale, străine și alte documentații științifice și tehnice).

Și fără citate sau surse secundare. GOST este legea. Și cu atât mai mult, fără internet (imaginați-vă că o instanță pronunță o sentință folosind o imprimare a Codului penal descărcată de pe un site web). Nu ai încredere în nimeni altul decât originalul. Totuși, autorul va trebui apoi să recurgă la citarea DUAE, abdicând astfel orice responsabilitate.

Să începem cu prevederile generale despre Sistemul Unificat de Documentare a Programului (care sunt, de asemenea, definite în standardul corespunzător GOST 19.001-77).

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.

Standardele ESPD definesc prevederi generale și standarde fundamentale, reguli de execuție a documentației de dezvoltare, reguli de execuție a documentației de fabricație, reguli de execuție a documentației suport, reguli de execuție a documentației operaționale, reguli de circulație a documentației programului și alte standarde . ESPD include:

standarde fundamentale și organizatorice și metodologice;
standarde care definesc formele și conținutul documentelor de program utilizate în prelucrarea datelor;
standarde care asigură automatizarea elaborării documentelor programului.

În general, lista documentelor DEPD este foarte extinsă. În special, include următoarele GOST-uri:

GOST 19.001-77 ESPD. Prevederi generale.
GOST 19.101-77 ESPD. Tipuri de programe și documente de program (reeditate în noiembrie 1987 cu modificări).
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. Programul de testare și metodologia.
GOST 19.401-78 ESPD. Textul programului. Cerințe pentru conținut și design.
GOST 19.402-78 ESPD. Descrierea programului.
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.
GOST 19.505-79 ESPD. Manual de utilizare.
GOST 19.506-79 ESPD. Descrierea limbii.
GOST 19.508-79 ESPD. Manual de întreținere. Cerințe pentru conținut și design.
GOST 19.604-78 ESPD. Reguli pentru efectuarea de modificări la documentele programului executate în tipărire.
GOST 19.701-90 ESPD. Scheme de algoritmi, programe, date și sisteme. Convenții și reguli de executare.
GOST 19.781-90. Software pentru sisteme de procesare a informațiilor.

După cum puteți vedea, partea principală a complexului ESPD a fost dezvoltată în anii 70 și 80. Unele dintre aceste standarde sunt depășite și nu sunt lipsite de unele dezavantaje. În primul rând, ele nu reflectă unele tendințe moderne în proiectarea programelor și a documentației programului și, în al doilea rând, aceste standarde conțin duplicarea multiplă a fragmentelor de documentație a programului. Cu toate acestea, în lipsa de ceva mai bun, trebuie să ne concentrăm asupra lor.

Deci, standardele ESPD simplifică procesul de documentare a sistemelor software. Cu toate acestea, în primul rând, compoziția documentelor software prevăzută de standardele ESPD nu este deloc atât de „rigidă” pe cât ar părea: standardele permit includerea unor tipuri suplimentare în setul de documentație pentru un sistem software (PS) și , în al doilea rând, pe baza cerințelor clienților, sunt acceptabile unele modificări atât în structura, cât și în conținutul tipurilor de PD stabilite. Mai mult, se poate observa că standardele ESPD (și acest lucru se aplică tuturor celorlalte standarde din domeniul PS - GOST 34, standardul internațional ISO/IEC etc.) sunt de natură consultativă. Faptul este că, în conformitate cu Legea Federației Ruse „Cu privire la standardizare”, aceste standarde devin obligatorii pe bază contractuală - adică. când se face referire la acestea în contractul de dezvoltare (furnizare) a software-ului.

Înainte de a începe să luăm în considerare regulile de compilare a documentației software, este necesar să facem următoarea remarcă. Este recomandabil să prefațați fiecare document cu o introducere. Introducerea vorbește în general. Despre relevanță, necesitate etc. Scopul interpretului aici este să arate semnificația și necesitatea efectuării acestei lucrări. Începutul este de obicei standard: „Nenumăratele sisteme existente în prezent... ... deschid perspective reale în...”, etc. Aici se introduc de obicei citate din discursurile diferitelor figuri (acesta este un aspect pur psihologic): „... așa cum s-a spus la ultimul plen, congres, conferință etc. Puteți începe cu faptul că „..). Astăzi, în era transformărilor socio-economice indigene... etc.” În general, principalul lucru aici este să nu exagerăm.

Și încă un lucru. Când își descrie produsul, dezvoltatorul confundă adesea conceptele de componentă și complex. Acestea sunt diferite tipuri de programe. O componentă este definită ca „un program considerat ca un întreg unic care îndeplinește o funcție completă și este utilizat independent sau ca parte a unui complex”, iar un complex este „un program format din două sau mai multe componente și (sau) complexe care efectuează funcții interconectate și este utilizat independent sau ca parte a unui alt complex.”

Conform GOST, acest standard (reeditat în noiembrie 1987) 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 scopul acestora.

Trebuie să fii extrem de atent și atent când îl creezi, pentru că... Adesea, o specificație tehnică elaborată cu pricepere (și competent) determină succesul întregii lucrări. Specificațiile tehnice sunt convenite cu Clientul, care de obicei se străduiește să introducă cât mai multe cerințe contradictorii și umflate. Sarcina Executorului este, dimpotrivă, să-i ușureze viața. Dar după ce semnăturile au fost plasate pe ambele părți, este prea târziu pentru a reda ceva.

Caietul de sarcini se întocmește pe foi de format A4 și/sau A3, de regulă, fără a se completa câmpurile foii. Numerele foii (paginii) sunt plasate în partea de sus a foii, deasupra textului.

Pentru a face modificări și completări la fundalul tehnic în etapele ulterioare de dezvoltare a unui program sau a unui produs software, se eliberează o completare la acesta. Coordonarea și aprobarea completărilor la specificațiile tehnice se realizează în același mod ca cel stabilit pentru specificațiile tehnice.

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

denumirea și domeniul de aplicare;
baza de dezvoltare;
scopul dezvoltării;
cerințe tehnice pentru un program sau un produs software;
stadii și stadii de dezvoltare;
procedura de control si acceptare;
aplicatii.

Î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.

In sectiunea Numele și domeniul de aplicare indicați numele, o scurtă descriere a domeniului de aplicare a programului sau produsului software și obiectul în care este utilizat programul sau produsul software.

In sectiunea Baza dezvoltării trebuie indicat:

document(e) pe baza căruia se realizează dezvoltarea;
organizația care a aprobat acest document și data aprobării acestuia;
numele și (sau) simbolul temei de dezvoltare.

În raport cu specificul procesului de învățământ, la baza poate fi o misiune pentru proiectarea cursului, o comandă de la institut din data de __.__. pentru N ___., contract __.__. pentru N ___. , etc.

In sectiunea Scopul dezvoltării Trebuie indicat scopul funcțional și operațional al programului sau produsului software. Vă puteți limita aici la una sau două fraze. Principalul lucru este să definiți clar pentru ce este acest program.

De exemplu: Programul este nucleul unei stații de lucru automatizate (AWS) pentru dezvoltatorul de sisteme de control automat linear continuu (ACS), permițând utilizatorului să rezolve problemele de analiză a modelelor simple.

Capitol Cerințe tehnice pentru un program sau un produs software ar trebui să conțină următoarele subsecțiuni:

cerințe pentru caracteristicile funcționale;
cerințe de fiabilitate;
termeni de utilizare;
cerințe pentru compoziția și parametrii mijloacelor tehnice;
cerințe pentru informații și compatibilitate software;
cerințe de etichetare și ambalare;
cerințe pentru transport și depozitare;
cerințe speciale.

Cu alte cuvinte, de aici încep specificul. Descrie ce ar trebui să facă programul și cum ar trebui să arate.

Cerințe pentru caracteristicile funcționale. Aici trebuie indicate cerințele pentru compoziția funcțiilor îndeplinite, organizarea datelor de intrare și de ieșire, caracteristicile de sincronizare etc.

De exemplu: programul ar trebui să permită ... să calculeze ... să construiască ... să creeze ...

Date de intrare: fișier text cu date...

Date de ieșire: informații grafice și text - rezultatele analizei sistemului...; fișiere text - rapoarte despre ... diagnostice ale stării sistemului și mesaje despre toate erorile care au apărut.

Cerințe de fiabilitate. Trebuie specificate cerințele pentru asigurarea funcționării fiabile (asigurarea funcționării stabile, monitorizarea informațiilor de intrare și ieșire, timpul de recuperare după o defecțiune etc.).

Este dificil să „ghicim” ceva aici. Cel mai bun scenariu este că programul dumneavoastră funcționează numai cu date absolut corecte. De obicei, Clientul nu este de acord cu acest lucru, dar puteți încerca.

De exemplu: Programul trebuie să funcționeze cu o anumită matrice extinsă de incidente ale graficului studiat în conformitate cu algoritmul de operare, să genereze mesaje de eroare atunci când datele inițiale sunt specificate incorect și să suporte un mod interactiv în cadrul capabilităților oferite utilizatorului.

Termeni de utilizare. Trebuie indicate conditiile de functionare (temperatura mediului ambiant, umiditate relativa etc. pentru tipurile de medii de stocare selectate) in care trebuie asigurate caracteristicile specificate, precum si tipul de serviciu, numarul necesar si calificarea personalului.

De obicei, nu există dificultăți cu acest punct. Din pacate, clauza despre profesionalismul utilizatorului de catre Client este neaparat implicata. Acesta, desigur, este un alt motiv pentru a găsi defecte în programul dvs. Cu toate acestea, aici ne putem limita la expresii precum „Condițiile de operare ale programului coincid cu condițiile de funcționare ale PC-ului IBM și ale PC-urilor compatibile cu acestea”, „Programul ar trebui să fie proiectat pentru un utilizator neprofesionist”. etc.

Cerințe pentru compoziția și parametrii mijloacelor tehnice. Indicați compoziția necesară a mijloacelor tehnice cu indicarea caracteristicilor tehnice ale acestora.

Principalul lucru aici este să nu uiți nimic și să asigurăm totul, pe de o parte (altfel se vor strecura într-un fel de IBM PC/XT cu afișaj monocrom și fără mouse), și pe de altă parte, să nu exagerați cu cerințe crescute, altfel Clientul va găsi un Antreprenor mai flexibil.

De exemplu: Trebuie să aveți un PC IBM - PC compatibil cu un adaptor grafic EGA (VGA). Spațiul necesar pe disc este de cel puțin 600 KB, cantitatea de RAM liberă este de cel puțin 400 KB. Este de dorit să aveți un driver EMS și un manipulator de tip mouse.

Cerințe pentru informații și compatibilitate software. Caracteristicile sunt aceleași ca în paragraful anterior. Aici trebuie specificate cerințele pentru structurile de informații la intrare și ieșire și metodele de soluție, codurile sursă și limbaje de programare. Acolo unde este necesar, trebuie asigurată protecția informațiilor și a programelor.

De exemplu: Programul trebuie să funcționeze autonom sub versiunea MS DOS OS nu mai mică de 3.3. Limbajul de programare de bază este Turbo Pascal 6.0.

Cerințele de etichetare și ambalare și cerințele de transport și depozitare sunt destul de exotice. În general, cerințele pentru etichetarea unui produs software, opțiunile de ambalare și metodele sunt indicate aici. Iar cerințele de transport și depozitare trebuie să indice pentru produsul software condiții de transport, locații de depozitare, condiții de depozitare, condiții de depozitare, perioade de depozitare în diferite condiții.

Cerințele speciale sunt un lucru foarte important. Este mai bine să le evitați dacă este posibil. Și declară-o imediat.

De exemplu: Nu există cerințe speciale pentru caracteristicile de sincronizare ale programului. Nu există cerințe speciale pentru caracteristicile capacitive ale programului.

Indicatori tehnico-economici. Acest punct cel mai dificil pentru un programator nu este întotdeauna acolo. Este necesar în primul rând atunci când scopul tău este de a justifica eficacitatea și importanța enormă a muncii efectuate. Acest articol funcționează de obicei foarte bine pentru Client. Cel puțin, aceasta este cea mai bună justificare pentru momentul și sumele monetare ale dezvoltării.

Această secțiune ar trebui să indice: eficiența economică estimată, necesarul anual estimat (de exemplu: numărul așteptat de apeluri către complex în ansamblu - 365 de sesiuni de lucru), avantajele economice ale dezvoltării în comparație cu cele mai bune eșantioane interne și străine sau analogi.

În plus, este recomandabil să se ofere o definiție atât a costului estimat al dezvoltării programului, cât și o definiție a complexității programării.

Etape și stadii de dezvoltare(acesta va fi discutat mai detaliat mai jos) stabiliți etapele necesare de dezvoltare, etapele și conținutul lucrărilor (o listă de documente de program care trebuie elaborate, convenite și aprobate), precum și, de regulă, termenele de dezvoltare și determina executantii.

Pașii standard sunt descriși aici. Principalul lucru este să determinați corect momentul. Dacă este posibil, încercați să distribuiți în mod egal etapele pe termene limită (și sume). Amintiți-vă că nu toate proiectele ajung la etapa finală. Și ar trebui să existe rapoarte pentru fiecare etapă. Amintiți-vă, de asemenea, că proiectul de lucru va dura cel mai mult timp. Dacă nu reușiți să completați documentația la timp, Clientul are tot dreptul să nu accepte deloc lucrarea cu toate consecințele care decurg.

Etapele și fazele principale și indispensabile sunt termenii de referință în sine, proiectul preliminar, proiectele tehnice și de lucru.

Proiect de proiect. În această etapă, structurile datelor de intrare și de ieșire sunt dezvoltate în detaliu și se determină forma de prezentare a acestora. O descriere generală a algoritmului, algoritmul în sine și structura programului sunt în curs de dezvoltare. Se elaborează un plan de acțiune pentru dezvoltarea și implementarea programului.
Proiect tehnic. Conține un algoritm dezvoltat pentru rezolvarea problemei, precum și metode de monitorizare a informațiilor inițiale. Aici sunt dezvoltate instrumente pentru prelucrarea erorilor și emiterea mesajelor de diagnosticare, se determină formulare de prezentare a datelor inițiale și configurarea mijloacelor tehnice.
Proiect de lucru. În această etapă, se efectuează programarea și depanarea programului, dezvoltarea documentelor programului, a programelor și a metodelor de testare. Se pregătesc exemple de testare și depanare. Documentația și materialul grafic sunt finalizate. De obicei, se precizează că în timpul dezvoltării programului trebuie pregătită următoarea documentație:

textul programului;
descrierea programului;
programul de testare și metodologia;
descrierea aplicației;
manual de utilizare.

Acestea sunt cerințe standard. Dacă Clientul este de acord că nu toată această listă poate fi prezentată, atunci aceasta înseamnă că intențiile sale cu privire la dumneavoastră și produsul dumneavoastră nu sunt serioase.

Este posibil să nu existe niciun material grafic. Mai ales când nu vei raporta rezultatele muncii tale. Dar pentru proiecte serioase acest articol este necesar.

De exemplu: În timpul dezvoltării programului, trebuie pregătit următorul material grafic:

indicatori tehnico-economici;
structura programului;
format pentru prezentarea datelor de intrare în program;
diagrama algoritmului general (2 foi);
algoritmi de calcul de bază;
exemplu de funcționare a programului.

In sectiunea Procedura de control si acceptare trebuie indicate tipurile de încercări și cerințele generale de recepție a lucrărilor. Dacă este posibil, atunci în acest paragraf indicați că „controlul și acceptarea dezvoltării se realizează folosind echipamente furnizate de Client”, altfel vi se poate solicita să aduceți echipamentul cu dvs.

De exemplu: Controlul și acceptarea dezvoltării sunt efectuate pe baza testelor de testare și a exemplelor de depanare. Aceasta verifică execuția tuturor funcțiilor programului.

ÎN Aplicații Dacă este necesar, specificațiile tehnice sunt furnizate de:

o listă de cercetări și alte lucrări care justifică dezvoltarea;
diagrame de algoritm, tabele, descrieri, justificări, calcule și alte documente care pot fi utilizate în timpul dezvoltării;

alte surse de dezvoltare.

Acest standard stabilește etapele de dezvoltare a programelor, documentația programului, precum și etapele și conținutul muncii:

Etape de dezvoltare	Etapele muncii
Termeni de referință	Justificarea necesității dezvoltării programului	Enunțarea problemei. Colectarea materialelor sursă. Selectarea și justificarea criteriilor pentru eficacitatea și calitatea programului dezvoltat. Justificarea necesității lucrărilor de cercetare.
	Munca de cercetare	Determinarea structurii datelor de intrare și de ieșire. Selecția preliminară a metodelor de rezolvare a problemelor. Justificarea fezabilității utilizării programelor dezvoltate anterior. Determinarea cerinţelor pentru mijloace tehnice. Justificarea posibilității fundamentale de rezolvare a problemei.
	Elaborarea și aprobarea specificațiilor tehnice	Determinarea cerințelor programului. Elaborarea unui studiu de fezabilitate pentru dezvoltarea programului. Determinarea etapelor, etapelor și calendarului de desfășurare a programului și documentația pentru acesta. Alegerea limbajelor de programare. Determinarea necesității lucrărilor de cercetare în etapele ulterioare. Coordonarea si aprobarea specificatiilor tehnice.
Proiect de proiect	Elaborarea unui proiect preliminar	Dezvoltarea preliminară a structurii datelor de intrare și de ieșire. Clarificarea metodelor de rezolvare a problemei. Elaborarea unei descrieri generale a algoritmului de rezolvare a problemei. Elaborarea unui studiu de fezabilitate.
Proiect de proiect	Aprobarea proiectului preliminar	Coordonarea si aprobarea proiectului preliminar
Proiect tehnic	Dezvoltarea proiectului tehnic	Clarificarea structurii datelor de intrare și de ieșire. Dezvoltarea unui algoritm pentru rezolvarea problemei. Determinarea formei de prezentare a datelor de intrare și de ieșire. Definiția semanticii și sintaxei limbajului. Dezvoltarea structurii programului. Determinarea finală a configurației echipamentelor tehnice.
Proiect tehnic	Aprobarea proiectării tehnice	Elaborarea unui plan de acțiune pentru dezvoltarea și implementarea programelor. Elaborarea unei note explicative. Coordonarea si aprobarea proiectului tehnic.
Proiect de lucru	Dezvoltarea programului	Programare și depanare
	Dezvoltarea documentației software	Dezvoltarea documentelor programului în conformitate cu cerințele GOST 19.101-77.
	Testarea programului	Elaborarea, coordonarea și aprobarea programului și metodologiei de testare. Efectuarea de teste preliminare de stat, interdepartamentale, de acceptare și alte tipuri de teste. Corectarea programului și a documentației programului pe baza rezultatelor testelor.
Implementarea	Pregatirea si transmiterea programului	Pregătirea și transferul de programe și documentație software pentru întreținere și (sau) producție. Înregistrarea și aprobarea actului de transfer al programului pentru întreținere și (sau) producție. Transferul programului în fondul de algoritmi și programe.

Note:

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.
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.

Acest standard se concentrează pe documentarea produsului de dezvoltare rezultat.

Strict vorbind, există două documente diferite, care, totuși, au multe în comun. Aceasta este o DESCRIERE GENERALĂ (GOST 19.502-78) și o DESCRIERE A PROGRAMULUI (GOST 19.402-78). Cu toate acestea, din cauza faptului că este foarte dificil să le creați efectiv pe ambele cu o calitate înaltă, fără a recurge la duplicarea aproape completă și ruperea pieselor, ar fi suficient să implementați un document, mai general, „hibrid”. Să-i spunem „Descrierea programului”.

De fapt, „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.503-79 ESPD. Ghidul programatorului de sistem, GOST 19.504-79 ESPD. Ghidul programatorului, GOST 19.505-79 ESPD. Manual de utilizare etc. În special, din Nota explicativă puteți lua o diagramă a algoritmului, o descriere generală a algoritmului și (sau) funcționarea programului, precum și justificarea deciziilor tehnico-tehnico-economice adoptate.

Descrierea programului trebuie să includă o parte informativă - adnotare și conținut.

Partea principală a documentului ar trebui să conțină o parte introductivă și următoarele secțiuni:

scop funcțional;
descrierea logicii.
conditii de utilizare;
compoziție și funcții.

În funcție de specificul programului, pot fi introduse secțiuni suplimentare.

ÎN Parte introductivă Documentul oferă informații generale despre program - numele complet, denumirea, posibilele aplicații ale acestuia etc.

De exemplu: Programul „Stație de lucru automatizată pentru dezvoltator de arme autopropulsate” este destinat pentru... implementat pe.... Programul sprijină...

In sectiunea Scop indicați scopul programului și furnizați o descriere generală a funcționării programului, caracteristicile sale principale, informații despre restricțiile impuse domeniului de aplicare al programului și, de asemenea, indicați tipurile de computere și dispozitive electronice care sunt utilizate în timpul funcționării.

De exemplu: Programul este conceput pentru a rezolva probleme... Programul reprezintă nucleul unei stații de lucru automatizate...

Utilizatorul are posibilitatea de a..., implementa..., rula..., analiza..., obține rezultate de analiză și procesare..., construi... etc.

In sectiunea " Descrierea logicii" indica:

descrierea structurii programului și a părților sale principale

(de exemplu: programul include următoarele:

interfata utilizator,
modul pentru determinarea căilor într-un grafic,
modul de calcul al funcției de transfer,
modul pentru construirea caracteristicilor de amplitudine și frecvență de fază,
modul pentru construirea unui răspuns la o influență polinomială,
editor de text).

descrierea funcțiilor componentelor și a conexiunilor dintre acestea;

De exemplu: Programul este format din șase module: modul de interfață; modul de definire...; modul de calcul...; modul...etc..

Modulul de interfață este construit pe două tipuri de dialoguri: un dialog „întrebare-răspuns” și un dialog de tip „meniu”. Modulul de interfață controlează...

Modul de definire... Este...

Modul de calcul...etc.

informatii despre limbajul de programare;

De exemplu: Programul este scris în limbajul ... folosind un compilator ...

descrierea datelor de intrare și de ieșire pentru fiecare dintre componente;

De exemplu: INTRARE DATE. Datele de intrare pentru program sunt un fișier text care descrie matricea extinsă de incidență a graficului sistemului studiat.

IEȘIRE. Ieșirea este:

informații grafice și text afișate pe ecran (rezultatele analizei sistemului);
fișiere într-unul dintre formatele grafice - copii ale imaginii caracteristicilor construite (răspuns în frecvență, răspuns la fază etc.);
fișiere text - rapoarte privind cercetările efectuate;
diagnosticarea stării sistemului și mesajele despre toate erorile care apar.

descrierea logicii părților componente (dacă este necesar, trebuie scrisă o descriere a diagramelor programului).

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

In sectiunea Compoziție și funcții indicați o descriere a compoziției și funcției programelor și a metodelor utilizate pentru rezolvarea problemelor.

In sectiunea Conditii de utilizare sunt indicate condițiile necesare implementării programului (cerințe pentru mijloacele tehnice necesare acestui program și altor programe, caracteristicile generale ale informațiilor de intrare și ieșire, precum și cerințe și condiții de natură organizatorică, tehnică și tehnologică etc. ).

De exemplu: Programul este operat pe un computer personal (PC) de tip IBM PC/AT. Pentru a lucra în modul interactiv, se utilizează un ecran de afișare, tastatură și mouse. Pentru a accepta modul grafic, este necesar un adaptor EGA (VGA). Datele de intrare sunt stocate pe dischetă și/sau hard disk. Programul rulează sub sistemul de operare...

Anexa la descriere poate include materiale de referință (ilustrări, tabele, grafice, exemple etc.)

Și nu uitați să indicați numele modulului de încărcare, precum și o descriere a întregii proceduri

Apelarea și pornirea sistemului

Cerințele pentru proiectarea textului programului sunt destul de simple și naturale pentru un programator competent. Principalul lucru de care trebuie să vă ghidați atunci când creați acest document este ca textul programului să fie lizibil.

Este încă obligatorie să compilați partea de informații - adnotări și conținut.

Partea principală a documentului ar trebui să fie formată din textele uneia sau mai multor secțiuni, cărora li se dau nume.

Textul fiecărui fișier de program începe cu un „antet”, care indică:

numele programului,
autor,
data creării programului,
numărul versiunii,
data ultimei modificări.

Sunt necesare comentarii, precum și respectarea strictă a regulilor de indentare. Amintiți-vă, chiar și incapacitatea de a crea documentație software poate fi justificată. Dar textul de program urât - niciodată. Referințele la faptul că acest text este de înțeles pentru autor însuși nu sunt luate în serios. Nu ar trebui să fie rușine în a oferi texte de program altor persoane pentru a le citi.

Mai jos este un exemplu de text de program atât de ușor de citit (preluat de pe site-ul web al lui Nikolai Gekht, e-mail: [email protected], http://users.omskreg.ru/~geht)

/* Surse Windows 98

Cod sursă la Windows 98 */ #include „win31.h” #include „win95.h” #include „evenmore.h” #include „oldstuff.h” #include „billrulz.h” #include „monopoly.h” # define INSTALL = HARD char make_prog_look_big; void main() ( while(!CRASHED) ( display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) ( make_50_megabyte_swapfile(); do_nothing_loop(); totally_screw_up_up_HPFS();(); able_Netscape(); disable_RealPlayer(); disable_Corel_Products(); write_something(anything_loop) (); ; if(fast_cpu()) ( set_wait_states(loturi); set_mouse(viteza, foarte_lent); set_mouse(action, jumpy); set_mouse(reacție, uneori); ) /* printf("Bine ați venit la Windows 3.11"); * printf("Bun venit la Windows 95"); else system_memory = open("a:\swp0001.swp", O_CREATE while(something) ( sleep(5); get_user_input(); somn(5); act_on_user_input(); somn(5); ) create_general_protection_fault();

Acest document conține o descriere a ceea ce și cum trebuie făcut pentru a vă asigura (și a convinge Clientul) că programul funcționează corect. De fapt, acest document este decisiv pentru testele de acceptare. Un program de testare și o metodologie bine concepute sunt cheia semnării certificatului de acceptare, de exemplu. lucrul pentru care ai petrecut atât de mult timp și efort.

În mod oficial, acest GOST este utilizat pentru a dezvolta documente de planificare și pentru a efectua lucrări de testare pentru a evalua pregătirea și calitatea sistemului software. Documentul conține o descriere a obiectului și scopului testării, cerințele pentru documentația programului și software-ului, mijloacele și procedura de testare, precum și o descriere a exemplelor de testare.

Componentele acestui document sunt mai ușor și mai clar descrise sub formă de exemple.

Obiect de testare

Exemplu: Obiectul de testare este programul..., destinat pentru...

Scopul testării

Exemplu: Verificarea fiabilității programului.

Cerințele programului

Exemplu: Funcționarea programului nu trebuie să ducă la o defecțiune (întrerupere fatală a sistemului). Organizarea dialogului ar trebui să ofere protecție împotriva introducerii de date incorecte. Programul ar trebui să ofere diagnostice ale stării sistemului și mesaje despre orice erori care au apărut... etc.

Cerințe pentru documentația software

Exemplu: Conținutul documentației software prezentate în timpul testării:

descrierea programului (GOST 19.402-78);
programul de testare și metodologia (GOST 19.301-79);
textul programului (GOST 19.401-78).

Mijloacele și procedura de testare

Exemplu: Programul funcționează în conformitate cu condițiile de operare ale sistemului de operare MS DOS (versiunea nu mai mică de 3.0) pe un PC precum IBM PC/AT, precum și pe cele compatibile. Un adaptor EGA (VGA) este, de asemenea, necesar pentru funcționare.

Procedura de testare:

Programul este lansat...
Selectat...
Presat...
Selectat secvenţial...

Cazuri de testare

Exemplu: Pentru testare se propun ..., ale căror descrieri sunt cuprinse în fișiere... Conținutul fișierelor de testare și rezultatele programului sunt prezentate în Anexa 1.

Și, în sfârșit, să ne uităm la cel mai recent standard ESPD, care se numește

Acest standard stabilește reguli de execuție a documentelor program pentru calculatoare, complexe și sisteme, indiferent de scopul și domeniul de aplicare al acestora și prevăzute de standardele DEPD.

Cerințe generale. Este necesar să introduceți cuvinte individuale, formule, simboluri (de mână într-un font de desen), litere ale alfabetului latin și grecesc, precum și să desenați diagrame și desene în documentele programului realizate prin dactilografiere, mașină și scris de mână, cu cerneală neagră sau cerneală.

Greșelile de scriere și inexactitățile grafice descoperite în timpul procesului de execuție pot fi corectate prin ștergerea unei părți a textului (desen) prost executată și aplicarea textului corectat (grafice) pe aceeași foaie cu dactilograf sau cerneală neagră, în funcție de modalitatea de executare a textului. document.

Nu sunt permise deteriorarea foilor de document, petele și urmele de text (grafice) șterse incomplet.

Documentele programului sunt întocmite pe coli A4. Pe langa:

Este acceptabilă tipărirea pe coli 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;
Atunci când se produce un document folosind o metodă tipografică, este posibil să se utilizeze foi de formate tipografice.

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);

partea informativa:

adnotare;
Cuprins;

partea principala:

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

modificare partea de jurnal:

schimba foaia de inregistrare.

Construcția documentului. Dacă este necesar, este permisă împărțirea documentului în părți. Împărțirea în părți se realizează la un nivel nu mai mic decât secțiunea. Fiecare parte este completată separat, iar la sfârșitul conținutului primei părți trebuie enumerate numele părților rămase.

Este permisă includerea în document a unor părți din textul programului, formatate în conformitate cu regulile limbii în care este scris textul programului.

Rezumatul este plasat pe o pagină (pagini) separată, prevăzută cu titlul „RESUM”, numerotat și inclus în cuprinsul documentului.

Textul fiecărui document, dacă este necesar, este împărțit în paragrafe, iar paragrafele în subparagrafe, indiferent dacă documentul este împărțit în părți, secțiuni și subsecțiuni sau nu.

Titlurile secțiunilor sunt scrise cu majuscule și plasate simetric față de marginile din dreapta și din stânga textului. Titlurile subsecțiunilor sunt scrise din paragraf cu litere mici (cu excepția primei majuscule). Nu este permisă separarea cu silabe a cuvintelor din titluri. Nu există punct la sfârșitul titlului. Se recomandă să începeți fiecare secțiune pe o foaie nouă.

Secțiunile, subsecțiunile, paragrafele și subparagrafele trebuie numerotate cu cifre arabe cu un punct. Secțiunile trebuie să aibă un număr de serie (1, 2 etc.)

Textul documentului. Textul documentului trebuie să fie scurt, clar, excluzând posibilitatea unei interpretări greșite. Termenii și definițiile trebuie să fie uniformi și să respecte standardele stabilite, iar în absența acestora - general acceptate în literatura științifică și tehnică și să fie menționați în lista de termeni.

Explicațiile necesare pentru textul documentului pot fi furnizate în note de subsol. O notă de subsol este indicată de un număr cu o paranteză plasată la nivelul marginii superioare a fontului.

Dacă o notă de subsol se referă la un singur cuvânt, semnul notă de subsol este plasat direct lângă acest cuvânt, dar dacă se referă la o propoziție în ansamblu, atunci la sfârșitul propoziției. Textul notei de subsol este plasat la sfârșitul paginii și separat de textul principal printr-o linie lungă de 3 cm trasată în partea stângă a paginii.

Ilustrații. Ilustrațiile pot fi găsite în textul documentului și (sau) în anexe. Ilustrațiile, dacă există mai multe într-un document dat, sunt numerotate cu cifre arabe pe întregul document.

În anexe, ilustrațiile sunt numerotate în cadrul fiecărei anexe în ordinea stabilită pentru textul principal al documentului. Referințele la ilustrații sunt date după tip: „Fig. 12” sau „(Fig. 12)”. Ilustrațiile pot avea un titlu tematic și un text de lege care explică conținutul ilustrației.

Formule. Formulele dintr-un document, dacă există mai multe dintre ele, sunt numerotate cu cifre arabe, numărul este plasat în partea dreaptă a paginii, între paranteze la nivelul formulei. În cadrul întregului document sau părților sale, dacă documentul este împărțit în părți, formulele au numerotare continuă.

Referințele din text la numărul de serie al formulei sunt date între paranteze, de exemplu: „în formula (3)”. La împărțirea unui document în părți, numărul piesei este plasat înaintea numărului de serie al formulei și este separat de ultimul punct, de exemplu: „în formula (1.4)”.

Semnificația simbolurilor incluse în formulă trebuie dată direct sub formulă. Semnificația fiecărui caracter este tipărită pe o nouă linie în ordinea în care sunt date în formulă. Prima linie a transcripției ar trebui să înceapă cu cuvântul „unde”, fără două puncte după el.

Legături. Referințele la standarde și alte documente sunt permise în documentele de politică. Trebuie făcută referire la documentul în ansamblu sau la secțiunile acestuia (indicând denumirea și denumirea documentului, numărul și denumirea secțiunii sau anexei).

Este permisă indicarea doar a denumirii documentului și (sau) secțiunilor fără a indica numele acestora. Referințele la subsecțiuni, paragrafe și ilustrații individuale ale altui document nu sunt permise. Sunt permise link-uri din document către paragrafe, ilustrații și subsecțiuni individuale.

Note Notele la text și tabele indică doar date de referință și explicative. O nota nu este numerotata. După cuvântul „Notă” puneți un punct. Mai multe note trebuie numerotate în ordine, folosind cifre arabe cu punct. După cuvântul „Notă” puneți două puncte. Textul notelor poate fi tipărit doar la un interval.

Abrevieri. Abrevierile cuvintelor din text și inscripțiile de sub ilustrații nu sunt permise, cu excepția:

abrevieri stabilite în GOST 2.316-68 și general acceptate în limba rusă;
abrevieri folosite pentru a desemna programe, părțile lor și modurile de operare, în limbaje de control al sarcinilor, în instrumentele de configurare a programelor etc., notate cu litere ale alfabetului latin.

Aplicații. Materialul ilustrat, tabele sau textul suport pot fi prezentate sub formă de anexe. Anexele sunt întocmite ca o continuare a acestui document pe paginile ulterioare sau emise ca document separat.

Fiecare aplicație trebuie să înceapă pe o pagină nouă cu cuvântul „Aplicație” în colțul din dreapta sus și să aibă un titlu de subiect. Dacă într-un document există mai multe atașamente, toate atașamentele sunt numerotate cu cifre arabe (fără semnul nr), de exemplu:

Anexa 1, Anexa 2 etc.

La emiterea unei cereri ca document separat, cuvântul „Anexă” trebuie indicat pe pagina de titlu sub denumirea documentului, iar dacă există mai multe cereri, trebuie indicat și numărul de serie al acestuia.

Sistem unificat de documentare a programului

DESCRIEREA PROGRAMULUI

Sistem unificat pentru documentarea programului. Descrierea programului.

Prin Decretul Comitetului de Stat pentru Standarde al URSS din 18 decembrie 1978 nr. 3350, a fost stabilită data introducerii
din 01.01. 1980
1. Acest standard stabilește compoziția și cerințele pentru conținutul documentului de program „Descrierea programului”, definit de GOST 19.101-77.
Standardul respectă pe deplin ST SEV 2092-80.
2. Structura și formatul documentului sunt stabilite în conformitate cu GOST 19.105-78.
Întocmirea părții de informare (adnotări și conținut) este obligatorie.
3. Descrierea programului trebuie să conțină următoarele secțiuni:

Informații generale;
scop funcțional;
descrierea structurii logice;
mijloace tehnice utilizate;
date de intrare;
date de ieșire.

În funcție de caracteristicile programului, este posibil să introduceți secțiuni suplimentare sau să combinați secțiuni individuale.
4. În secțiunea „Informații generale” trebuie să fie indicate următoarele:
denumirea și denumirea programului;
software-ul necesar pentru funcționarea programului;
limbaje de programare în care este scris programul.
5. Secțiunea „Scopul funcțional” trebuie să indice clasele de probleme care se rezolvă și (sau) scopul programului și informații despre restricțiile funcționale de utilizare.
6. În secțiunea „Descrierea structurii logice” ar trebui să fie indicate următoarele:

algoritmul programului;
metodele utilizate;
structura programului cu o descriere a funcțiilor componentelor sale și a conexiunilor dintre acestea;
conectarea programului cu alte programe.

Descrierea structurii logice a programului se realizează ținând cont de textul programului în limba sursă.
3-6.(Ediția schimbată, Amendamentul nr. 1).
7. Secțiunea „Unelte tehnice utilizate” trebuie să indice tipurile de computere și dispozitive electronice care sunt utilizate la rularea programului.

metoda de apelare a programului de pe mediul de stocare corespunzător;
puncte de intrare în program.

Puteți specifica adrese de descărcare, informații despre utilizarea RAM și dimensiunea programului.
9. În secțiunea „Date de intrare” trebuie să fie indicate următoarele:

natura, organizarea și pregătirea prealabilă a datelor de intrare;
format, descriere și metoda de codificare a datelor de intrare.

10. În secțiunea „Date de ieșire” trebuie să fie indicate următoarele:

natura și organizarea datelor de ieșire;
format, descriere și metoda de codificare a datelor de ieșire.

11. Este permisă ilustrarea conținutului secțiunilor cu exemple explicative, tabele, diagrame, grafice.
12. Anexa la descrierea programului poate include diverse materiale care nu pot fi incluse în secțiuni ale descrierii.
7-12 (Introdus suplimentar, amendamentul nr. 1).

STANDARD INTERSTATAL

Standardul respectă pe deplin ST SEV 2092-80.

2. Structura și formatul documentului sunt stabilite în conformitate cu GOST 19.105-78.

Întocmirea părții de informare (adnotări și conținut) este obligatorie.

3. Descrierea programului trebuie să conțină următoarele secțiuni:

date de intrare;

date de ieșire.

În funcție de caracteristicile programului, este posibil să introduceți secțiuni suplimentare sau să combinați secțiuni individuale.

4. În secțiunea „Informații generale” trebuie indicate următoarele:

denumirea și denumirea programului;

metodele utilizate;

structura programului cu o descriere a funcțiilor componentelor sale și a conexiunilor dintre acestea;

conectarea programului cu alte programe.

Descrierea structurii logice a programului se realizează ținând cont de textul programului în limba sursă.

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

7. Secțiunea „Mijloace tehnice utilizate” trebuie să indice tipurile de calculatoare și dispozitive electronice care sunt utilizate la rularea programului.

natura, organizarea și pregătirea prealabilă a datelor de intrare;

format, descriere și metoda de codificare a datelor de intrare.

10. În secțiunea „Date de ieșire” trebuie să fie indicate următoarele:

natura și organizarea datelor de ieșire;

format, descriere și metoda de codificare a datelor de ieșire.

11. Este permisă ilustrarea conținutului secțiunilor cu exemple explicative, tabele, diagrame, grafice.

12. Anexa la descrierea programului poate include diverse materiale care nu pot fi incluse în secțiuni ale descrierii.

7-12.(Introdus suplimentar, amendamentul nr. 1).