GOST 19.701-90
(ISO 5807-85)

Grupa T55

MEĐUDRŽAVNI STANDARD

jedan sustav programska dokumentacija

DIJAGRAMI ALGORITAMA, PROGRAMA, PODATAKA I SUSTAVA

Konvencionalne oznake i pravila izvođenja

Jedinstveni sustav programske dokumentacije. Dijagrami toka podataka, programa i sustava, mrežni grafikoni programa i grafikoni sistemskih resursa. Dokumentacijski simboli i konvencije za dijagram toka

MKS 35.080*
OKSTU 5004

____________________
* U indeksu "Nacionalni standardi" 2012
ISS 01.080.50 i 35.080. - Napomena proizvođača baze podataka.

Datum uvođenja 1992-01-01

INFORMACIJSKI PODACI

1. RAZVIO I UVEO Državni komitet SSSR-a za računalno inženjerstvo i informatiku

PROGRAMI

A.A. Mkrtumyan (voditelj razvoja); A.L. Shchers, Dr. tehn. znanosti; A.N. Sirotkin, dr. sc. ist. znanosti; L.D.Raikov, dr. sc. tehn. znanosti; A.V.Lobova; međuodjelski Radna skupina o razvoju ESPD standarda

2. ODOBRENO I STUPILO NA SNAGU Rezolucijom Državnog odbora SSSR-a za upravljanje kvalitetom proizvoda i standarde od 26. prosinca 1990. N 3294

3. Ova je norma razvijena izravnom primjenom međunarodne norme ISO 5807-85 * "Obrada informacija. Simboli i konvencije za podatkovne blok dijagrame, programe i sustave, softverske mrežne dijagrame i resursi sustava"
________________
* Pristup međunarodnim i stranim dokumentima koji se spominju u tekstu možete dobiti kontaktiranjem korisničke podrške. - Napomena proizvođača baze podataka.

4. UMJESTO GOST 19.002-80, GOST 19.003-80

5. REPUBLIKACIJA. siječnja 2010


Ova se norma primjenjuje na konvencije (simbole) u dijagramima algoritama, programa, podataka i sustava i utvrđuje pravila za izvođenje dijagrama koji se koriste za prikaz različitih vrsta problema obrade podataka i sredstava za njihovo rješavanje.

Norma se ne odnosi na oblik unosa i simbola postavljenih unutar ili uz simbole koji služe za pojašnjavanje funkcija koje obavljaju.

Zahtjevi standarda su obvezni.

1. OPĆE ODREDBE

1. OPĆI ZAHTJEVI

1.1. Dijagrami algoritama, programa, podataka i sustava (u daljnjem tekstu: dijagrami) sastoje se od simbola sa zadanim značenjem, kratkog teksta objašnjenja i spojnih linija.

1.2. Sheme se mogu koristiti na različitim razinama detalja, pri čemu broj razina ovisi o veličini i složenosti problema obrade podataka. Razina detalja treba biti takva da se različiti dijelovi i odnosi između njih razumiju kao cjelina.

1.3. Ova norma definira simbole za uporabu u dokumentaciji obrade podataka i daje smjernice o konvencijama za uporabu u:

1) sheme podataka;

2) programski dijagrami;

3) sheme rada sustava;

4) sheme programske interakcije;

5) dijagrami resursa sustava.

1.4. Norma koristi sljedeće pojmove:

1) osnovni simbol - simbol koji se koristi u slučajevima kada je točan tip (tip) procesa ili medija za pohranu nepoznat ili nema potrebe za opisom stvarnog medija za pohranu;

2) specifični simbol - simbol koji se koristi u slučajevima kada je poznata točna vrsta (vrsta) procesa ili medija za pohranu ili kada je potrebno opisati stvarni medij za pohranu;

3) dijagram - grafički prikaz definicije, analize ili metode za rješavanje problema koji koristi simbole za predstavljanje operacija, podataka, toka, opreme itd.

2. OPIS KRUGA

2.1. Shema podataka

2.1.1. Podatkovne sheme predstavljaju put podataka u rješavanju problema i definiraju korake obrade kao i različite medije za pohranu koji se koriste.

2.1.2. Shema podataka sastoji se od:

1) podatkovni simboli (podatkovni simboli također mogu označavati vrstu medija za pohranu);

2) simboli procesa koji se trebaju izvršiti nad podacima (simboli procesa mogu označavati i funkcije koje obavlja računalo);

3) linijski simboli koji označavaju protok podataka između procesa i (ili) medija za pohranu;

2.1.3. Simboli podataka prethode i slijede simbole procesa. Shema podataka počinje i završava podatkovnim simbolima (osim posebni znakovi navedeno u klauzuli 3.4).

2.2. Pregled programa

2.2.1. Programski dijagrami prikazuju redoslijed operacija u programu.

2.2.2. Programsku shemu čine:

1) procesne simbole koji označavaju stvarne operacije obrade podataka (uključujući simbole koji definiraju put koji treba slijediti, uzimajući u obzir logičke uvjete);

2) linearni simboli koji označavaju tok upravljanja;

3) posebni simboli koji se koriste za lakše pisanje i čitanje dijagrama.

2.3. Dijagram rada sustava

2.3.1. Dijagrami rada sustava prikazuju upravljanje radom i protokom podataka u sustavu.

2.3.2. Shema rada sustava sastoji se od:

1) podatkovni simboli koji označavaju prisutnost podataka (podatkovni simboli mogu označavati i vrstu nositelja podataka);

2) procesne simbole, koji označavaju operacije koje bi se trebale izvršiti na podacima, a također definiraju logički put koji treba slijediti;

3) linearni simboli koji označavaju tijek podataka između procesa i (ili) medija za pohranu, kao i kontrolni tok između procesa;

4) posebni simboli koji se koriste za lakše pisanje i čitanje dijagrama toka.

2.4. Shema programske interakcije

2.4.1. Dijagrami interakcije programa prikazuju put aktivacije programa i interakcije s odgovarajućim podacima. Svaki program u dijagramu interakcije programa prikazuje se samo jednom (u dijagramu rada sustava program se može prikazati u više od jednog tijeka upravljanja).

2.4.2. Shema interakcije programa sastoji se od:

1) simboli podataka koji označavaju prisutnost podataka;

2) simbole procesa koji označavaju operacije koje treba izvršiti nad podacima;

3) linearni simboli koji prikazuju tijek između procesa i podataka, kao i početak procesa;

4) posebni simboli koji se koriste za lakše pisanje i čitanje dijagrama.

2.5. Dijagram resursa sustava

2.5.1. Dijagrami resursa sustava prikazuju konfiguraciju podataka i procesorskih jedinica koje su potrebne za rješavanje zadatka ili skupa zadataka.

2.5.2. Dijagram resursa sustava sastoji se od:

1) podatkovni simboli koji prikazuju ulazne, izlazne i pohranjujuće uređaje računala;

2) procesni simboli koji prikazuju procesore ( središnje procesne jedinice, kanali itd.);

3) linearni simboli koji prikazuju prijenos podataka između ulazno/izlaznih uređaja i procesora, kao i prijenos upravljanja između procesora;

4) posebni simboli koji se koriste za lakše pisanje i čitanje dijagrama.

Primjeri izvedbe sklopa dati su u dodatku.

3. OPIS SIMBOLA

3.1. Podatkovni simboli

3.1.1. Simboli osnovnih podataka

3.1.1.1. Podaci

Simbol prikazuje podatke, medij za pohranu nije definiran.

3.1.1.2. Memorirani podaci

Simbol prikazuje pohranjene podatke u obliku pogodnom za obradu, medij za pohranu nije definiran.

3.1.2. Specifični podatkovni znakovi

3.1.2.1. RAM memorija

Simbol prikazuje podatke pohranjene u uređaju za radnu memoriju.

3.1.2.2. Memorija sa serijskim pristupom

Simbol predstavlja podatke pohranjene u uređaju za pohranu sa serijskim pristupom (magnetska vrpca, kazeta s magnetskom vrpcom, kazeta s vrpcom).

3.1.2.3. Uređaj za pohranu s izravnim pristupom

Simbol predstavlja podatke pohranjene u uređaju za pohranu s izravnim pristupom ( magnetski disk, magnetski bubanj, savitljivi magnetski disk).

3.1.2.4. Dokument

Simbol prikazuje podatke prikazane na mediju u čitljivom obliku (strojna shema, dokument za optičko ili magnetsko očitavanje, mikrofilm, rola vrpce sa sumarnim podacima, obrasci za unos podataka).

3.1.2.5. Ručni unos

Simbol prikazuje podatke unesene ručno tijekom obrade s bilo koje vrste uređaja (tipkovnica, prekidači, gumbi, svjetleća olovka, barkod trake).

3.1.2.6. Karta

Simbol prikazuje podatke predstavljene na mediju sličnom kartici (bušene kartice, magnetske kartice, kartice s čitljivim oznakama, kartice s naljepnicom za otkidanje, kartice s oznakama koje se mogu skenirati).

3.1.2.7. Papirna traka

Simbol prikazuje podatke prikazane na mediju u obliku papirne trake.

3.1.2.8. Prikaz

Simbol prikazuje podatke prikazane u obliku čitljivom za čovjeka na mediju u obliku uređaja za prikaz (zaslon za vizualno promatranje, indikatori unosa informacija).

3.2. Simboli procesa

3.2.1. Simboli osnovnih procesa

3.2.1.1. Postupak

Simbol predstavlja funkciju obrade podataka bilo koje vrste (izvođenje određene operacije ili skupine operacija koje rezultiraju promjenom vrijednosti, oblika ili smještaja informacija ili određivanjem koji od nekoliko smjerova toka treba slijediti).

3.2.2. Obradite specifične simbole

3.2.2.1. Predefinirani proces

Simbol prikazuje unaprijed definirani proces koji se sastoji od jedne ili više operacija ili programskih koraka koji su definirani negdje drugdje (u potprogramu, modulu).

3.2.2.2. Ručna operacija

Simbol predstavlja bilo koji proces koji obavlja neka osoba.

3.2.2.3. Priprema

Simbol predstavlja modifikaciju instrukcije ili skupine instrukcija kako bi se utjecalo na neku naknadnu funkciju (postavljanje sklopke, modificiranje indeksnog registra ili inicijalizacija programa).

3.2.2.4. Riješenje

Simbol predstavlja funkciju odluke ili tipa prekidača koja ima jedan ulaz i niz alternativnih izlaza, od kojih se jedan i samo jedan može aktivirati nakon procjene uvjeta definiranih unutar simbola. Odgovarajući rezultati izračuna mogu se napisati uz linije koje predstavljaju te staze.

3.2.2.5. Paralelne aktivnosti

Simbol predstavlja sinkronizaciju dviju ili više paralelnih operacija.

Primjer

Bilješka. Procesi C, D i E ne mogu započeti dok proces A ne završi; slično, proces F mora čekati da procesi B, C i D završe, ali proces C može započeti i/ili završiti prije nego proces D započne i/ili završi.

3.2.2.6. Granica petlje

Dvodijelni simbol predstavlja početak i kraj ciklusa. Oba dijela simbola imaju isti identifikator. Uvjeti za inicijalizaciju, inkrement, prekid, itd. postavljaju se unutar simbola na početku ili kraju, ovisno o mjestu operacije koja provjerava stanje.

Primjer 

3.3. Simboli linija

3.3.1. Simbol osnovne linije

3.3.1.1. Crta

Simbol predstavlja tijek podataka ili kontrolu.

Po potrebi ili radi poboljšanja čitljivosti mogu se dodati strelice za smjer.

3.3.2. Specifični linijski simboli

3.3.2.1. Prijenos kontrole

Simbol predstavlja izravan prijenos kontrole s jednog procesa na drugi, ponekad uz mogućnost izravnog povratka na inicirajući proces nakon što je inicirani proces završio svoje funkcije. Vrsta prijenosa kontrole mora biti imenovana unutar simbola (npr. zahtjev, poziv, događaj).

3.3.2.2. Veza

Simbol prikazuje prijenos podataka preko komunikacijskog kanala.

3.3.2.3. Točkasta linija

Prikazuje se simbol alternativni priključak između dva ili više znakova. Osim toga, simbol se koristi za ocrtavanje označenog područja.

Primjer 1

Kada se jedan od niza alternativnih izlaza koristi kao ulaz u proces ili kada se izlaz koristi kao ulaz u alternativne procese, ovi simboli su povezani točkastim linijama.

Primjer 2

Izlaz koji se koristi kao ulaz u sljedeći proces može se povezati s tim ulazom pomoću točkaste linije.

3.4. Posebni simboli

3.4.1. Priključak

Simbol predstavlja izlaz u dio strujnog kruga i ulaz iz drugog dijela tog strujnog kruga i koristi se za prekid linije i nastavak na drugom mjestu. Odgovarajući simboli konektora moraju sadržavati istu jedinstvenu oznaku.

3.4.2. Terminator

Simbol prikazuje izlaz u vanjsko okruženje i ulaz iz vanjskog okruženja (početak ili kraj dijagrama programa, vanjska uporaba i izvor ili odredište podataka).

3.4.3. Komentar

Simbol se koristi za dodavanje opisnih komentara ili objašnjenja u svrhu objašnjenja ili napomena. Isprekidane linije u simbolu komentara povezane su s odgovarajućim simbolom ili mogu ocrtavati grupu simbola. Tekst komentara ili bilješki treba postaviti blizu graničnog oblika.

Primjer

3.4.4. Proći

Simbol (tri točke) koristi se u dijagramima za označavanje izostavljanja simbola ili skupine simbola u kojima nije navedena niti vrsta niti broj simbola. Simbol se koristi samo unutar ili između linijskih simbola. Koristi se uglavnom u dijagramima koji prikazuju opća rješenja s nepoznatim brojem ponavljanja.

Primjer

4. PRAVILA ZA PRIMJENU SIMBOLA I IZVOĐENJE DIJAGRAMA

4.1. Pravila za korištenje simbola

4.1.1. Simbol je namijenjen za grafičku identifikaciju funkcije koju predstavlja, bez obzira na tekst unutar tog simbola.

4.1.2. Simboli u dijagramu trebaju biti ravnomjerno raspoređeni. Treba održavati razumnu duljinu veza i minimalni broj veza. dugi redovi.

4.1.3. Većina simbola dizajnirana je tako da omogućuje uključivanje teksta unutar simbola. Obrasci simbola navedeni u ovoj normi služe kao vodič za simbole koji se stvarno koriste. Kutovi i drugi parametri koji utječu na odgovarajući oblik simbola ne smiju se mijenjati. Simboli trebaju biti, ako je moguće, iste veličine.

Likovi se mogu crtati u bilo kojoj orijentaciji, ali horizontalna orijentacija je poželjna kad god je to moguće. Zrcaljenje oblika znaka označava istu funkciju, ali nije poželjno.

4.1.4. Minimalna količina teksta potrebna za razumijevanje funkcije danog simbola treba biti smještena unutar danog simbola. Tekst za čitanje treba pisati s lijeva na desno i odozgo prema dolje, bez obzira na smjer toka.

Primjer

Ako količina teksta unutar simbola premašuje njegove dimenzije, treba koristiti simbol komentara.

Ako bi uporaba simbola komentara mogla zbuniti ili poremetiti tijek dijagrama, tekst treba staviti na poseban list i treba navesti unakrsnu referencu na simbol.

4.1.5. Sheme mogu koristiti identifikator simbola. Ovo je identifikator povezan s danim simbolom, koji identificira simbol za referentnu upotrebu u drugim elementima dokumentacije (na primjer, popis programa). ID simbola trebao bi se nalaziti lijevo iznad simbola.

Primjer

4.1.6. Dijagrami mogu koristiti opise simbola—bilo koje druge informacije, na primjer da pokažu posebnu upotrebu simbola s unakrsnom referencom ili da poboljšaju razumijevanje funkcije kao dijela dijagrama. Opis simbola treba se nalaziti desno iznad simbola.

Primjer

4.1.7. U dijagramima sustava simboli koji predstavljaju medije za pohranu često predstavljaju metode ulaza/izlaza. Da bi se koristio kao referenca na dokumentaciju, tekst na dijagramu za simbole koji predstavljaju metode izlaza treba biti postavljen desno iznad simbola, a tekst za simbole koji predstavljaju metode unosa trebao bi biti postavljen desno ispod simbola.

Primjer

4.1.8. Dijagrami mogu koristiti detaljan prikaz, koji je označen trakastim simbolom za proces ili podatke. Simbol trake označava da su detaljnije informacije dostupne drugdje u istom skupu dokumentacije.

Simbol s prugom je svaki simbol koji unutar sebe na vrhu ima povučenu vodoravnu crtu. Između ovog retka i gornjeg retka simbola nalazi se identifikator koji pokazuje detaljan prikaz tog simbola.

Završni znak mora se koristiti kao prvi i zadnji znak opširnog prikaza. Prvi znak završetka mora sadržavati referencu, koja je također prisutna u znaku trake.

	Simbol s prugom	Detaljan prikaz

4.2. Pravila za izradu veza

4.2.1. Tokovi podataka ili tokovi upravljanja u dijagramima prikazani su kao linije. Smjer protoka s lijeva na desno i odozgo prema dolje smatra se standardnim.

U slučajevima kada je potrebno donijeti veću jasnoću dijagramu (na primjer, prilikom spajanja), strelice se koriste na linijama. Ako je protok u smjeru različitom od standardnog, strelice bi trebale pokazivati ​​taj smjer.

4.2.2. Na dijagramima treba izbjegavati linije koje se sijeku. Crte koje se sijeku nemaju međusobnu logičnu vezu, stoga promjene smjera u točkama sjecišta nisu dopuštene.

Primjer

4.2.3. Dvije ili više dolaznih linija mogu se kombinirati u jednu odlaznu liniju. Ako se dva ili više redaka spajaju u jedan, mjesto spajanja mora se pomaknuti.

Primjer

4.2.4. Crte u dijagramima trebale bi prilaziti simbolu slijeva ili odozgo, a polaziti s desne ili odozdo. Linije trebaju biti usmjerene prema središtu simbola.

4.2.5. Ako je potrebno, linije u dijagramima trebaju biti prekinute kako bi se izbjegla nepotrebna križanja ili predugi redovi, kao i ako se dijagram sastoji od više stranica. Spojnica na početku loma naziva se vanjska veznica, a veznica na kraju loma unutarnja veznica.

	Vanjski priključak	Unutarnji konektor

4.3. Posebne konvencije

4.3.1. Više izlaza

4.3.1.1. Treba prikazati višestruke izlaze iz simbola:

1) nekoliko redaka od ovog simbola do drugih simbola;

2) jedna linija iz zadanog simbola, koja se zatim grana u odgovarajući broj linija.

Primjeri

4.3.1.2. Svaki izlaz simbola mora biti popraćen odgovarajućim vrijednostima uvjeta kako bi se prikazao logički put koji predstavlja, tako da su ti uvjeti i odgovarajuće reference identificirani.

Primjeri

4.3.2. Pogled koji se ponavlja

4.3.2.1. Umjesto jednog simbola s pridruženim tekstom, može se koristiti više simbola koji se preklapaju, od kojih svaki sadrži opisni tekst (upotrebom ili generiranjem više medija za pohranu ili datoteka, stvaranjem više kopija ispisanih izvješća ili formata bušenih kartica).

4.3.2.2. Kada više znakova predstavlja uređen skup, redoslijed mora biti od naprijed (prvi) prema nazad (zadnji).

4.3.2.3. Crte mogu ulaziti ili polaziti iz bilo koje točke preklapajućih simbola, međutim, moraju se poštivati ​​zahtjevi paragrafa 4.2.4. Prioritet ili redoslijed višestrukih simbola ne mijenja se točkom u kojoj linija ulazi ili izlazi.

Primjer

5. PRIMJENA SIMBOLA

	Ime simbola	Shema podataka	Pregled programa	Dijagram rada sustava	Shema programske interakcije	Dijagram resursa sustava
Podatkovni simboli
Osnovni, temeljni
	Memorirani podaci
Specifično
	RAM memorija
	Memorija sekvencijalnog pristupa
	Uređaj za pohranu s izravnim pristupom
	Dokument
	Ručni unos
	Papirna traka
Simboli procesa
Osnovni, temeljni
Specifično
	Predefinirani proces
	Ručna operacija

Kako dokumentu dodijeliti "GOST kod".

Mihail Ostrogorski, 2010

Zašto su nam potrebni simboli dokumenata?

Ponekad nas pitaju kako dokumentu ispravno dodijeliti šifru, šifru, broj itd. Recimo odmah da to nije velika znanost. Ali, prvo, to nije šifra ili šifra, već oznaka, u svakom slučaju, ako se namjeravamo pridržavati ESPD (GOST 19) ili KSAS (GOST 34). Drugo, prvo shvatimo koje je značenje notacija dokumenta.

U vrijeme pisanja i papira oznake dokumenata služile su za održavanje arhive. Zamislite veliku organizaciju koja interno naručuje ili razvija mnogo programa ili automatiziranih sustava. Ona također skuplja puno tehničke dokumentacije. Za navigaciju, između ostalog, morate svakom dokumentu dati jedinstveni identifikator. Kao takve, domaće norme predlažu korištenje oznake oblikovane prema određenim redovitim pravilima. O njima ćemo govoriti.

Oznake dokumenata ne trebaju tužitelj, ne Rostekhregulirovanie, ne programer ili programer sustava, već, prije svega, kupac. Ako vaš klijent pod svaku cijenu zahtijeva da dokumenti koji su za njega izrađeni budu opskrbljeni "GOST kodom", možete odgovoriti pitanjem održava li arhivu tehnička dokumentacija. Nažalost, u većini slučajeva odgovor je ne. Ako kupac ima takvu arhivu, najvjerojatnije će biti elektronička, a ne papirnata. U elektroničkim arhivama dokumentima se obično automatski dodjeljuju jedinstveni identifikatori.

Stoga je davanje službenih oznaka dokumentima danas uglavnom besmisleno i predstavlja “magični ritual”. Što ako kupac i dalje inzistira na njegovoj provedbi? Naravno, učini to.

Oznake dokumenata na automatiziranim sustavima

Struktura oznake dokumenta sustava u skladu s GOST 34.201-89 prikazana je u nastavku. Objašnjenje dijelova oznake dano je u tablici.

A.B.CCC.DD.EE.F-G.M

Dio oznake	Značenje
A	kod organizacije koja razvija sustav. GOST 34.201-89 kaže: "Šifra organizacije razvojnog programera dodjeljuje se u skladu sa All-Union Klasifikatorom poduzeća, institucija i organizacija (OKPO) ili u skladu s pravilima utvrđenim industrijskom normativnom i tehničkom dokumentacijom." Iz dobro poznatih razloga, danas nemamo svesavezni klasifikator, ali postoji Sveruski klasifikator poduzeća i organizacija (OKPO). Kod OKPO dio je službenih podataka organizacije i vaš bi ga računovodstveni odjel trebao znati. Ako baš ne želite zvati računovodstvo, pokušajte svoju tvrtku potražiti u internetskom imeniku, ali imajte na umu da oznaka na vratima ureda ne mora uvijek odgovarati nazivu pravne osobe. Osim toga, prema GOST 2.201-80, razvojnoj organizaciji mora se dodijeliti kod od četiri slova za generiranje oznaka za projektne dokumente. Centralizirano dodjeljivanje kodova provode ovlaštene organizacije, na primjer, FSUE Standardinform i OJSC Standardelectro. To je stvarna praksa; neke tvrtke čak na svojim web stranicama objavljuju dokaze o dodjeli koda
B	šifra klasifikacijskog obilježja vrste sustava ili njegovog dijela. Prema GOST 34.201-89, ovaj kod treba odabrati iz All-Union Product Classifier-a, koji je sada zamijenjen All-Russian Product Classifier-om (OKP). Puno je puta objavljivan na Internetu, lako ga možete pronaći pomoću ovdje navedene poveznice ili pomoću tražilice. Ovaj klasifikator sadrži sve moguće proizvode od hodajućih bagera do igala. Odjeljak klasifikatora posvećen automatizirani sustavi, počinje linijom 425000 Softverski i hardverski sustavi za automatizirane sustave. Možda klasifikator ima druge nizove koji su vam prikladniji na temelju specifičnosti sustava. Pokušajte ih pronaći koristeći uobičajenu funkciju pretraživanja u tekstu stranice. Kao alternativa OKP-u, standard predlaže korištenje All-Union Klasifikatora podsustava i kompleksa ACS zadataka (OKPKZ). Koliko znamo, ona je otkazana, ali nije zamijenjena ničim drugim, tako da je ova poveznica poslana u povijest
CCC	registarski broj automatiziranog sustava ili njegovog dijela. Pretpostavlja se da je programer organizirao evidenciju proizvedenih automatiziranih sustava i dodijelio im registracijske brojeve. Ako to nije prihvaćeno u vašoj tvrtki, tada ne možete u potpunosti ispuniti zahtjeve CCAS-a. Započnite novi život, vodite dnevnik izdanih sustava. Numeriranje sustava provodi se za svaki tip (tj. šifru klasifikacijske karakteristike, vidi gore) sustava zasebno. Standard ne kaže što učiniti za organizaciju koja je uspjela izdati 1000 automatiziranih sustava iste vrste.
dd	šifra dokumenta (točnije, vrsta dokumenta) prema GOST 34.201-89. Na primjer, šifra korisničkog priručnika je I3(i-tri), a programski kod i metode ispitivanja su PM.
E.E.	dokument broj jednog imena. Recimo da imate tri procesne upute u svom skupu dokumentacije za tri različite funkcionalne uloge. U ovom slučaju oni će imati brojeve 01, 02 I 03 . Pravila za dodjelu ovih brojeva (po datumu objave dokumenta, po imenu po abecednom redu ili na bilo koji drugi način) nisu navedena. Glavna stvar je da brojevi idu uzastopno od jednog. Ako skup sadrži samo jedan dokument određene vrste, na primjer, jedno objašnjenje tehničkog projekta, broj se ne dodjeljuje, a odgovarajuće mjesto u oznaci se preskače.
F	broj revizije dokumenta. Riječ je o onim izdanjima koja službeno prenosite na kupca, a on ih službeno prihvaća i odobrava. Ako vam je tijekom procesa pregleda i odobravanja dokumenta korisnik više puta poslao komentare, a vi ste odgovorili ispravljenom datotekom, ne govorimo o novim izdanjima dokumenta, to su radni materijali i ništa više. Novo izdanje dolazi ako kupac to odobri nova opcija dokumenta, uz očuvanje prethodnog, au načelu se u nekim situacijama mogu koristiti oba. U suprotnom, zastarjela opcija može se otkazati i zauvijek zaboraviti. Brojevi se dodjeljuju izdanjima, počevši od drugog. U prvom izdanju izostavljeno je odgovarajuće mjesto u oznaci
G	broj dijela dokumenta. Dokument se može fizički podijeliti u nekoliko dijelova. To se obično radi kako bi se dokument lakše čitao ili uvezivao. Ako dokument nije podijeljen na dijelove, broj se ne dodjeljuje, a odgovarajuće mjesto u oznaci se preskače
M	1989. godine elektronički dokumenti bili još uvijek nova i neobična pojava. Tipičan dokument bio je list ili hrpa listova papira s odobrenjem i potpisima odobrenja. Činjenica da disketa ili magnetska vrpca s tekstom napisanim na njoj također može biti dokument koji zahtijeva posebno razmatranje. Stoga je slovo dodano oznaci takvih dokumenata M. Začudo, ova praksa ni sada nije bez temelja, budući da se kod nas u službenom dokumentarnom prometu pojavljuju papirnati dokumenti s originalnim potpisima nadležnih osoba i “mokri” pečati organizacija. Stoga se, primjerice, tehnološka uputa, za čije se nepoštivanje službeno može kazniti zaposlenik, mora provoditi upravo u ovakvom obliku. Ali ako kupac od nas traži, na primjer, tekst programa (dokument predviđen ESPD-om), još uvijek mu možemo dati ne kamion listinga, već CD. Oznaka takvog dokumenta mora završavati slovom M, koji je od prethodnog dijela odvojen točkom (ne crticom!)

Kao primjer, dodijelit ćemo oznaku tehnoloških uputa za korisnika ove stranice. Stranicu ćemo promatrati kao automatizirani sustav koji smo razvili za sebe, a ovo je bilo naše prvo iskustvo u razvoju sustava ovakvog tipa. Korisnika ćemo smatrati zaposlenikom Philosofta koji objavljuje članke na stranici. Složimo se i da osoba odgovorna za objavu nije jedina funkcionalna uloga. Imamo i odgovornu osobu za postavljanje reklamnih bannera za koju su napisane vlastite tehnološke upute. Prvo izdanje tehnološke upute je važeće, dokument nije podijeljen na dijelove, postoji u obliku papirnatog izvornika s potpisima i pečatima. Uzimajući u obzir gore navedene okolnosti, oznaka je sljedeća:

63755082.425750.001.I2.01, Gdje

63755082 - šifra Philosoft LLC prema OKPO.

425750 - red šifra Programski i hardverski sustavi za automatizaciju obrade informacija u trgovini, logistici sukladno OKP. Autor članka je pregledao OKP, razmislio i odlučio ovu karakteristiku odgovara našoj stranici bolje od svih ostalih koje se tamo nude. Možda se vara.

001 je registarski broj automatiziranog sustava ove vrste u našoj internoj evidenciji (pretpostavimo da ga vodimo).

I2 - šifra tehnoloških uputa prema GOST 34.201-89.

01 - broj tehnoloških uputa u kompletu tehničke dokumentacije za gradilište. Podsjetimo, postoji još jedan za voditelja reklamni banneri, njen broj je 02.

Određivanje tehničkih specifikacija za automatizirani sustav

U klauzuli 3.2 GOST 34.602-89 postoji izraz koji spominje određeni TK kod: “Brojevi lista (stranica) stavljaju se počevši od prvog lista, nakon naslovne stranice, na vrhu lista (iznad teksta, u sredini) nakon označavanja TK šifre na AC.” Istodobno, GOST 34.201-89 daje kodove za dokumente razvijene u fazama počevši od idejnog projekta, ali ne postoji kod za tehničke specifikacije, što je pomalo zbunjujuće.

Prilikom generiranja koda tehničke specifikacije za zvučnike, možete uzeti u obzir klauzulu 3.5. GOST 34.602-89, koji kaže: "Ako je potrebno, Naslovnica Na NEK je dopušteno postaviti šifre utvrđene u industriji, npr.: sigurnosna klasifikacija, radna šifra, matični broj TK i sl.” i dodijeliti šifru proizvoljno, pozivajući se na činjenicu da je to uobičajeno u industriji ili određeno znanstvenom i tehničkom dokumentacijom određenog poduzeća. Osim toga, možete zapamtiti da je prema GOST 24.101-80 tehnička specifikacija imala kod 2A i dodijelite dokumentu oznaku prema gore opisanoj shemi. Ali općenito, sve ovo već sliči na školsko računanje broja vragova na vrhu igle.

Simboli programskih dokumenata

Struktura označavanja programskog dokumenta u skladu s GOST 19.103-77 prikazana je u nastavku. Objašnjenje dijelova oznake dano je u tablici. Broj revizije, broj dokumenta i broj dijela dokumenta formiraju se na isti način kao i kod dokumenata sustava (iz povijesne perspektive je obrnuto, ali molimo čitatelja da nam oprosti ovaj anakronizam).

A.B.CCCCC-DD EE FF-G

Dio oznake	Značenje
A	kod zemlje. Danas je razumno navesti dvoslovni kod prema standardu ISO 3166-1: RU za Rusiju, KZ za Kazahstan itd.
B	šifra organizacije programera. Po analogiji s dokumentima sustava, možete navesti OKPO kod
CCCCC	registracijski broj programa. Prema GOST 19.103-77, treba ga dodijeliti „u skladu sa Svesaveznom klasifikacijom programa koju je odobrio Gosstandart na propisani način.” Danas ne znamo kako ispuniti taj zahtjev. Obratite pozornost na godinu kada je standard odobren: 1977. Od tada se mnogo toga promijenilo u našim životima
dd	broj revizije dokumenta
E.E.	šifra vrste dokumenta u skladu s GOST 19.101-77
FF	broj dokumenta ove vrste
G	broj dijela dokumenta

Početni dio oznake, A.B.CCCC-DD, služi kao oznaka za sam program i istovremeno za glavni dokument povezan s njim, specifikaciju.

Oznake projektne dokumentacije

Svaki program ili automatizirani sustav može se smatrati proizvodom i dokumentirati na općoj osnovi, vođen ESKD-om (GOST 2). Isti niz standarda treba koristiti pri dokumentiranju tehničkih sredstava, kao što su poslužitelji, radne stanice, sve vrste specijaliziranih uređaja itd. Pravila za dodjelu oznaka projektnim dokumentima utvrđena su GOST 2.201-80. Ovdje ćemo se suzdržati od prepričavanja ovog dokumenta, ali ne sumnjamo da će ga sada čitatelj lako pronaći i savladati.

Oznake lista odobrenja

Ako je dokument opremljen listom odobrenja, potonji mora imati vlastitu oznaku. Formira se prema elementarnom pravilu: oznaci dokumenta treba dodati šifru LU, odvojene crticom, na primjer: 63755082.425750.001.I2.01-LU.

O korisnosti notacije s opreznim optimizmom

Pažljivi čitatelj primijetio je da kada bi se sve organizacije pažljivo pridržavale takvih pravila, oznake dokumenata bile bi jedinstvene unutar zemlje. Onda bi bilo moguće, recimo, uspostaviti nacionalni katalog tehničke dokumentacije, preko kojeg bi svaki inženjer mogao zatražiti dokument koji mu treba. To bi vjerojatno olakšalo integraciju automatiziranih sustava različitih odjela, ali danas doživljavamo puno svakakvih birokratskih neugodnosti upravo zbog njihove izoliranosti. Recimo, umirovljenici su prisiljeni uzeti potvrdu iz matičnog ureda da su još živi i osobno je dostaviti socijalnom osiguranju, tek onda im se daju kojekakvi dodaci i beneficije. Postavlja se pitanje: zašto automatizirani sustavi matičnog ureda i socijalnog osiguranja ne bi radili s jednim nizom podataka? S druge strane, iskusni čitatelj primijetit će da ovi argumenti griješe utopizmom i bit će u pravu.

Moguće je da oznake dokumenata i danas mogu biti korisne u razvoju i odobravanju velikih skupova tehničke dokumentacije. U međusobnoj korespondenciji iu raznim radnim materijalima sudionici projekta često se moraju pozivati ​​na dokumente, navoditi ih ili spominjati u različitim kontekstima. Kada se broj dokumenata u projektu poveća, postaje nezgodno pozivati ​​se na njih imenom. Tijekom projekta imena se mogu mijenjati; osim toga, ljudi ih često navode napamet, skraćuju ih i čine pogreške, što naravno dovodi do zabune. Na primjer, kupac prijavi pogrešku u jednom dokumentu, ali programer to ne razumije i radi nepotrebne ispravke u drugom sa sličnim nazivom. Nadamo se da će korištenje notacija pomoći riješiti se takvih problema.

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

Jedinstveni sustav programske dokumentacije	GOST 19.003-80 Za uzvrat GOST 19428-74
DIJAGRAMI ALGORITAMA I PROGRAMSKA NOTACIJA UVJETNA GRAFIKA
Jedinstveni sustav programske dokumentacije. Simboli grafičkog dijagrama toka.

Dekretom Državnog odbora za standarde SSSR-a od 24. travnja 1980. br. 1867 utvrđen je datum uvođenja

od 01.07.1981

Ovaj se standard odnosi na uvjetne grafički simboli(simboli) u dijagramima algoritama i programa, koji prikazuju osnovne operacije procesa obrade podataka i programiranja za programske sustave računala, kompleksa i sustava, bez obzira na njihovu namjenu i opseg.

Norma se ne odnosi na unose i simbole postavljene unutar ili uz simbol koji služe za pojašnjavanje funkcija koje on obavlja.

Norma utvrđuje popis, naziv, oblik, veličinu simbola i funkcije prikazane simbolima.

Norma je u skladu s ISO 1028-73 u pogledu oznaka simbola

1. POPIS, NAZIV, OZNAKA SIMBOLA I FUNKCIJA KOJE SE NJIMA PRIKAZUJU

1.1. Popis, naziv, oznaka i veličina obveznih simbola i funkcija koje oni prikazuju u algoritmu i programu za obradu podataka moraju odgovarati onima navedenima u tablici. 1.

Stol 1.

Ime	Oznaka i mjere u mm	Funkcija
1. Proces		Izvođenje operacija ili skupine operacija koje mijenjaju vrijednost, oblik prikaza ili mjesto podataka
2. Rješenje		Odabir smjera izvođenja algoritma ili programa ovisno o nekim varijabilnim uvjetima
3. Izmjena		Izvođenje operacija koje mijenjaju naredbe ili grupe naredbi koje mijenjaju program
4. Predefinirani proces		Korištenje prethodno izrađenih i posebno opisanih algoritama ili programa
5. Ručni rad		Autonomni proces koji se izvodi ručno ili korištenjem neautomatiziranih sredstava
6. Pomoćna operacija		Autonomni proces koji izvodi uređaj kojim izravno ne upravlja procesor
7. Spajanje		Spajanje dva ili više skupova u jedan skup
8. Odabir		Uklanjanje jednog ili više skupova iz jednog skupa
9. Grupiranje		Kombiniranje dva ili više skupova uz odabir nekoliko drugih skupova
10. Razvrstavanje		Naručivanje kompleta prema zadanim karakteristikama
11. Ručni unos		Ručni unos podataka pomoću neautonomnih uređaja s tipkovnicom, sklopom prekidača i tipkama
12. I/O		Pretvaranje podataka u oblik pogodan za obradu (ulaz) ili prikaz rezultata obrade (izlaz)
13. Neautonomno pamćenje		Ulaz/izlaz podataka kada se koristi uređaj za pohranu kojim izravno upravlja procesor
14. Izvanmrežna memorija		Unos/izlaz podataka kada se koristi uređaj za pohranu koji izravno ne kontrolira procesor
15. Dokument		Ulaz-izlaz podataka čiji je nositelj papir
16. Bušena kartica		Ulaz-izlaz podataka čiji je nositelj bušena kartica
17. Špil bušenih karata		Prikaz kompleta bušenih kartica
18. Turpija		Prikaz podataka organiziran na temelju zajedničkih karakteristika koje zajedno karakteriziraju određeni objekt obrade podataka. Simbol se koristi u kombinaciji sa simbolima specifičnih medija za pohranu koji obavljaju I/O funkcije
19. Bušena traka		Ulaz-izlaz podataka čiji je nositelj bušena traka
20. Magnetska traka		Ulaz-izlaz podataka čiji je nositelj magnetska vrpca
21. Magnetski bubanj		Ulaz-izlaz podataka, čiji je nositelj magnetski bubanj
22. Magnetski disk		Ulaz-izlaz podataka čiji je nositelj magnetski disk
23. RAM memorija		Ulaz-izlaz podataka čiji je nositelj magnetska jezgra
24. Prikaz		Unos/izlaz podataka, ako uređaj izravno povezan s procesom reproducira podatke i omogućuje operateru računala da vrši promjene tijekom njihove obrade
25. Komunikacijski kanal		Prijenos podataka putem komunikacijskih kanala
26. Protočna linija		Određivanje slijeda između znakova
27. Paralelne akcije		Započinjanje ili završetak dvije ili više istovremenih operacija
28. Konektor		Označavanje veze između prekinutih vodova toka, povezujući simboli
29. Start - stop		Početak, kraj, prekid obrade podataka ili izvođenja programa
30. Komentirajte		Odnos između elementa sheme i objašnjenja

1.2. Popis, naziv, oznaka i veličina preporučenih simbola i funkcija koje oni prikazuju u algoritmu i programu za obradu podataka moraju odgovarati onima navedenima u tablici. 2.

tablica 2

Ime	Oznaka i mjere u mm	Funkcija
1. Interpage konektor		Označavanje veze između nepovezanih dijelova dijagrama algoritama i programa koji se nalaze na različitim listovima
2. Magnetska kartica		Ulaz-izlaz podataka čiji je nositelj magnetska kartica
3. Ručni dokument		Formiranje dokumenta kao rezultat ručnih operacija
4. Arhiva		Pohranjivanje skupa organiziranih medija za pohranu za ponovnu upotrebu
5. Izvanmrežna obrada		Transformacija izvornih podataka kao rezultat izvanmrežnih operacija
6. Dekodiranje		Čitanje s medija za pohranu, ponovno kodiranje i ispis na isti ili drugi medij za pohranu kao rezultat izvanmrežne operacije
7. Kodiranje		Primjena kodiranih informacija na medij kao rezultat autonomne operacije
8. Kopiraj

V.E. Karpov

Ovaj dokument sadrži Kratki opis ESPD standardi čije je poznavanje neophodno studentima za izradu kolegija i projekata vezanih uz izradu programskih sustava. Osim toga, može biti koristan sa stajališta poboljšanja kvalitete softverske dokumentacije općenito.

TEHNIČKE SPECIFIKACIJE (GOST 19.201-78)

1. Opće odredbe

FAZE RAZVOJA (GOST 19.102-77)

OPIS PROGRAMA (GOST 19.402-78)

TEKST PROGRAMA (GOST 19.401-78)

PROGRAM I METODOLOGIJA ISPITIVANJA (GOST 19.301-79)

ZAHTJEVI ZA ISPISANE SOFTVERSKE DOKUMENTE (GOST 19.106-78)

Standardizacija u području programske dokumentacije

Kako krenuti naprijed

Izrada dokumentacije za softver(PS) u skladu s postojećim GOST-ovima

2. Opće karakteristike stanja

2.3. Državni standardi Ruske Federacije (GOST R)

2.4. Međunarodna norma ISO/IEC 12207: 1995-08-01

Možda najneugodnija i najteža faza programerskog rada je izrada programske dokumentacije. Nažalost, obično se to uopće ne podučava ili, u najboljem slučaju, ne obraćaju dužnu pozornost na kvalitetu primljenih dokumenata. Međutim, vladanje ovom vještinom često je jedan od najvažnijih čimbenika koji određuju kvalitetu programera.

Prvo, sposobnost izrade programske dokumentacije određuje profesionalnu razinu programera. Kupac neće ulaziti u sitnice i značajke čak ni najljepšeg programa. Kupac će prvo pročitati dokumentaciju. Veliku ulogu u tome igra i psihološki faktor. Osobito je bivša sovjetska škola programiranja bila (i sada) cijenjena u cijelom svijetu. Moderni domaći programeri prestali su se citirati. Klasa nije ista. Danas se programi više ne pišu, već sastavljaju (a to su “dvije velike razlike”). Dakle, paket programske dokumentacije (u daljnjem tekstu PD) kreiran u “klasičnom” stilu ostavit će najpovoljniji dojam na vašeg kupca ili poslodavca. Štoviše, ako autor PD-a izbjegava izraze poput “klikni na traku za pomicanje...”, “šraf” itd. Nažalost, takvo žargonsko brbljanje obično krije ili manjak misli ili potpunu prazninu (na autora se neizbrisivo dojmila priča jednog njegovog poznanika o izvjesnom “gameru” koji je ili “čavrljao” s nekim ili se bavio “moderiranjem”). ” Ili tako nešto.). Jezik PD-a je vrsta birokratskog, vrlo konzervativnog jezika. Ima svoj poseban šarm. Složite se da pojmovi tvrdi disk, ravni disk, ručni manipulator poput “miš” (ili “kifla”, kako je pisalo u jednom od starih PD paketa) zvuče potpuno drugačije od odgovarajućeg “šrafa”, “ flop” i jednostavno “miš”. Inače, već je došlo do toga da se, kažu, pojavila čak i posebna specijalnost - tehnički pisac, tj. osoba koja zna izraditi programsku dokumentaciju.

Drugo, dobro osmišljen (točnije, kreiran) PD paket spasit će vas od mnogih nevolja. Konkretno, možete se riješiti dosadnih pitanja i neutemeljenih tvrdnji jednostavnim upućivanjem korisnika na dokumentaciju. Riječ je, prije svega, o najvažnijem dokumentu - Projektnom zadatku. O tome ćemo u nastavku, no sada vas možemo podsjetiti na višemilijunsku tužbu protiv IBM-a. Tužbu je pokrenula jedna velika izdavačka kuća, nezadovoljna kvalitetom VT-a i softvera. IBM je dobio slučaj. A pobijedila je samo zato što je predočila projektni zadatak potpisan s obje strane. To se dogodilo davno, još 70-ih godina, ali to ne mijenja bit stvari.

Još jedna stvar. Važno je izraditi prvi PD paket. To će biti dovoljno za izgradnju svih sljedećih na njegovoj osnovi, koristeći ga kao model ili predložak. Ali to se mora učiniti vrlo učinkovito. Ležerno. Vrlo temeljito.

Prvo se morate naoružati GOST-ovima. GOST definira sve. Konkretno, uključuje Jedinstveni sustav programske dokumentacije (USPD) koji nas zanima. Možda je najteže dobiti sam GOST. GOST treba biti samo u tiskanom izvornom obliku. Prodaju se (bar je prije bilo tako) u posebnim trgovinama. Konkretno, za stjecanje standarda u području dokumentacije možete kontaktirati sljedeće organizacije:

• IPK "Standardi izdavanja", Teritorijalni odjel distribucije NTD (trgovina "Standardi"), 17961, Moskva, ul. Donskaja, 8, tel. 236-50-34, 237-00-02, faks/tel. 236-34-48 (u vezi GOST i GOST R).
• VNIIKI Gosstandart Rusije (čitaonica), 103001, Moskva, Granatny per. broj 4, tel. 290-50-94 (u vezi s međunarodnim, stranim normama i drugom znanstveno-tehničkom dokumentacijom).

I bez citata ili sekundarnih izvora. GOST je zakon. I još više, nema interneta (zamislite sud koji izriče kaznu koristeći ispis Kaznenog zakona skinut s neke web stranice). Ne vjeruj nikome osim originalu. Međutim, autor će tada morati pribjeći citiranju ESPD-a, čime se odriče svake odgovornosti.

Počnimo s općim odredbama o Jedinstvenom sustavu programske dokumentacije (koje su također definirane u odgovarajućem standardu GOST 19.001-77).

Jedinstveni sustav programske dokumentacije je skup državnih standarda koji uspostavljaju međusobno povezana pravila za razvoj, izvođenje i promet programa i programske dokumentacije.

ESPD standardi definiraju opće odredbe i temeljne norme, pravila za izradu razvojne dokumentacije, pravila za izradu proizvodne dokumentacije, pravila za izradu dokumentacije za održavanje, pravila za izradu operativne dokumentacije, pravila za rukovanje programskom dokumentacijom i druge norme. ESPD uključuje:

• temeljni i organizacijski i metodološki standardi;
• norme kojima se definiraju oblici i sadržaj programskih dokumenata koji se koriste u obradi podataka;
• standardi koji osiguravaju automatizaciju izrade programskih dokumenata.

Općenito, popis ESPD dokumenata je vrlo opsežan. Konkretno, uključuje sljedeće GOST-ove:

• GOST 19.001-77 ESPD. Opće odredbe.
• GOST 19.101-77 ESPD. Vrste programa i programski dokumenti (reizdano u studenom 1987. s izmjenama i dopunama).
• GOST 19.102-77 ESPD. Faze razvoja.
• GOST 19.103-77 ESPD. Određivanje programa i programskih dokumenata.
• GOST 19.104-78 ESPD. Osnovni natpisi.
• GOST 19.105-78 ESPD. Opći zahtjevi za programske dokumente.
• GOST 19.106-78 ESPD. Zahtjevi za tiskane programske dokumente.
• GOST 19.201-78 ESPD. Tehnički zadatak. Zahtjevi za sadržaj i dizajn.
• GOST 19.202-78 ESPD. Specifikacija. Zahtjevi za sadržaj i dizajn.
• GOST 19.301-79 ESPD. Program i metodologija ispitivanja.
• GOST 19.401-78 ESPD. Tekst programa. Zahtjevi za sadržaj i dizajn.
• GOST 19.402-78 ESPD. Opis programa.
• GOST 19.404-79 ESPD. Objašnjenje. Zahtjevi za sadržaj i dizajn.
• GOST 19.501-78 ESPD. Oblik. Zahtjevi za sadržaj i dizajn.
• GOST 19.502-78 ESPD. Opis primjene. Zahtjevi za sadržaj i dizajn.
• GOST 19.503-79 ESPD. Vodič za programera sustava. Zahtjevi za sadržaj i dizajn.
• GOST 19.504-79 ESPD. Programerski vodič.
• GOST 19.505-79 ESPD. Priručnik za rukovanje.
• GOST 19.506-79 ESPD. Opis jezika.
• GOST 19.508-79 ESPD. Vodič održavanje. Zahtjevi za sadržaj i dizajn.
• GOST 19.604-78 ESPD. Pravila za izmjene programskih dokumenata koji se izvode u tisku.
• GOST 19.701-90 ESPD. Sheme algoritama, programa, podataka i sustava. Konvencije i pravila izvršenja.
• GOST 19.781-90. Softver za sustave za obradu informacija.

Kao što vidite, glavni dio ESPD kompleksa razvijen je 70-ih i 80-ih godina. Neki od ovih standarda su zastarjeli i nisu bez nekih nedostataka. Prvo, oni ne odražavaju neke moderne tendencije dizajn programa i programske dokumentacije; drugo, ovi standardi sadrže višestruko umnožavanje fragmenata programske dokumentacije. Ipak, u nedostatku boljeg, moramo se fokusirati na njih.

Dakle, ESPD standardi pojednostavljuju proces dokumentiranja softverskih sustava. Međutim, prvo, sastav programskih dokumenata predviđen ESPD standardima uopće nije tako "krut" kao što se može činiti: standardi dopuštaju uključivanje dokumentacije o programski sustav(P.S) dodatne vrste, i, drugo, na temelju zahtjeva kupca, dopuštene su neke promjene u strukturi i sadržaju uspostavljenih vrsta PD-a. Štoviše, može se primijetiti da su ESPD standardi (a to se odnosi i na sve ostale standarde u području PS-a - GOST 34, ISO/IEC međunarodni standard itd.) savjetodavne prirode. Činjenica je da u skladu sa Zakonom Ruske Federacije "O normizaciji", ovi standardi postaju obvezni na ugovornoj osnovi - tj. kada se na njih poziva u ugovoru o razvoju (isporuci) softvera.

Prije nego počnemo razmatrati pravila za sastavljanje softverske dokumentacije, potrebno je napraviti sljedeću napomenu. Preporučljivo je svakom dokumentu dati neki uvod. Uvod govori općenito. O relevantnosti, nužnosti itd. Izvođačev cilj ovdje je pokazati značaj i nužnost bavljenja ovim poslom. Početak je obično standardan: "Brojni postojeći sustavi... ... otvaraju stvarne izglede u...", itd. Ovdje se obično ubacuju citati iz govora raznih ličnosti (ovo je čisto psihološki aspekt): "...kao što je rečeno na zadnjem plenumu, kongresu, konferenciji itd.). Možete početi s činjenicom da "...Danas, u eri radikalnih društveno-ekonomskih preobrazbi...itd. Općenito, glavna stvar Nemojte pretjerivati ​​ovdje.

I dalje. Kada opisuje svoj proizvod, programer često brka pojmove komponente i kompleksa. ovo - različiti tipovi programa. Komponenta se definira kao "program koji se smatra jedinstvenom cjelinom, obavlja potpunu funkciju i koristi se samostalno ili kao dio kompleksa", a kompleks je "program koji se sastoji od dvije ili više komponenti i (ili) kompleksa koji obavljaju međusobno povezane funkcionira, a koristi se samostalno ili u sklopu drugog kompleksa."

Prema GOST-u, ova norma (ponovno izdana u studenom 1987.) utvrđuje postupak za izradu i pripremu tehničkih specifikacija za razvoj programa ili softverskog proizvoda za računala, komplekse i sustave, bez obzira na njihovu svrhu i opseg.

Prilikom izrade morate biti izuzetno pažljivi i pažljivi, jer... Često vješto (i kompetentno) sastavljena tehnička specifikacija određuje uspjeh cjelokupnog posla. Tehničke specifikacije su ono što se dogovara s Naručiteljem, koji obično nastoji uvesti što više kontradiktornih i prenapuhanih zahtjeva. Zadatak Izvršitelja je, naprotiv, olakšati mu život. Ali nakon što su stavljeni potpisi s obje strane, prekasno je išta ponavljati.

Projektni zadatak izrađuje se na listovima formata A4 i/ili A3, u pravilu, bez popunjavanja polja lista. Brojevi listova (stranica) stavljaju se na vrhu lista iznad teksta.

Za izmjene i dopune tehničke pozadine u kasnijim fazama razvoja programa ili softverskog proizvoda, izdaje se dodatak. Usklađivanje i odobrenje dopune Tehničke specifikacije provodi istim redoslijedom koji je utvrđen za tehničke specifikacije.

Projektni zadatak mora sadržavati sljedeće odjeljke:

• naziv i opseg primjene;
• osnova za razvoj;
• svrha razvoja;
• tehnički zahtjevi za program ili softverski proizvod;
• faze i stupnjevi razvoja;
• postupak kontrole i prijema;
• aplikacije.

Ovisno o karakteristikama programa ili softverskog proizvoda, moguće je pojasniti sadržaj odjeljaka, uvesti nove dijelove ili kombinirati pojedine.

U poglavlju Naziv i opseg navesti ime, Kratak opis opseg primjene programa ili programskog proizvoda i objekt u kojem se program ili programski proizvod koristi.

U poglavlju Osnova za razvoj mora biti naznačeno:

• dokument(i) na temelju kojeg se provodi razvoj;
• organizacija koja je odobrila ovaj dokument i datum njegovog odobrenja;
• ime i (ili) simbol razvojne teme.

S obzirom na specifičnosti odgojno-obrazovnog procesa, temelj može biti projektni zadatak, narudžba zavoda od __.__. za N ___., ugovor __.__. za N ___. , i tako dalje.

U poglavlju Svrha razvoja Funkcionalna i operativna svrha programa ili softverskog proizvoda mora biti naznačena. Ovdje se možete ograničiti na jednu ili dvije fraze. Glavna stvar je jasno definirati za što je ovaj program.

Na primjer: Program je jezgra automatizirane radne stanice (AWS) za programere kontinuiranih linearnih sustava automatskog upravljanja (ACS), omogućujući korisniku rješavanje problema analize jednostavnih modela.

Poglavlje Tehnički zahtjevi za program ili softverski proizvod treba sadržavati sljedeće pododjeljke:

• zahtjevi za funkcionalne karakteristike;
• zahtjevi pouzdanosti;
• Uvjeti korištenja;
• zahtjevi za sastav i parametre tehnička sredstva;
• zahtjevi za informacijsku i softversku kompatibilnost;
• zahtjevi za označavanje i pakiranje;
• zahtjevi za prijevoz i skladištenje;
• posebni zahtjevi.

Drugim riječima, tu počinju specifičnosti. Opisuje što bi program trebao raditi i kako bi trebao izgledati.

Zahtjevi za funkcionalne karakteristike. Ovdje treba navesti zahtjeve za sastav funkcija koje se izvode, organizaciju ulaznih i izlaznih podataka, vremenske karakteristike itd.

Na primjer: Program bi trebao omogućiti ... izračunavanje ... izgradnju ... stvaranje ...

Početni podaci: tekstualna datoteka s datim...

Izlazni podaci: grafičke i tekstualne informacije - rezultati analize sustava...; tekstualne datoteke - izvješća o ... dijagnostici stanja sustava i porukama o svim greškama koje su se dogodile.

Zahtjevi pouzdanosti. Moraju se specificirati zahtjevi za osiguranje pouzdanog rada (osiguranje stabilnog rada, praćenje ulaznih i izlaznih informacija, vrijeme oporavka nakon kvara itd.).

Teško je tu nešto "pogoditi". Najbolji scenarij je da vaš program radi samo s apsolutno točnim podacima. Kupac se obično ne slaže s tim, ali možete pokušati.

Na primjer: Program mora raditi s danom proširenom matricom incidenata grafa koji se proučava u skladu s operativnim algoritmom, generirati poruke o pogrešci kada su početni podaci netočno specificirani i podržavati interaktivni način rada unutar mogućnosti koje se daju korisniku.

Uvjeti korištenja. Moraju biti navedeni uvjeti rada (temperatura okoline, relativna vlažnost itd. za odabrane vrste medija za pohranjivanje) pod kojima moraju biti osigurane navedene karakteristike, kao i vrsta usluge, potreban broj i kvalifikacije osoblja.

S ovom točkom obično nema poteškoća. Nažalost, klauzula o profesionalnosti korisnika od strane Kupca se nužno podrazumijeva. Ovo je, naravno, još jedan razlog da pronađete grešku u svom programu. Međutim, ovdje se možemo ograničiti na fraze poput "Uvjeti rada programa podudaraju se s uvjetima rada IBM PC-a i kompatibilnih računala", "Program bi trebao biti dizajniran za neprofesionalnog korisnika." i tako dalje.

Zahtjevi za sastav i parametre tehničkih sredstava. Navesti potreban sastav tehničkih sredstava s naznakom njihovih tehničkih karakteristika.

Ovdje je najvažnije ne zaboraviti ništa i osigurati sve, s jedne strane (inače će ubaciti nekakav IBM PC/XT s jednobojnim zaslonom i bez miša), a s druge strane, ne pretjerati s povećanim zahtjevima, inače će kupac pronaći fleksibilnijeg izvođača.

Na primjer: Morate imati IBM PC - kompatibilno računalo s grafički adapter EGA (VGA). Neophodno prostor na disku- najmanje 600 KB, slobodan prostor RAM memorija- najmanje 400 KB. Poželjno je imati EMS vozač i manipulator tipa miš.

Zahtjevi za informacijsku i softversku kompatibilnost. Značajke su iste kao u prethodnom paragrafu. Ovdje treba specificirati zahtjeve za informacijske strukture na ulazu i izlazu i metode rješenja, izvorni kodovi, programski jezici. Gdje je potrebno, mora se osigurati zaštita podataka i programa.

Na primjer: Program mora raditi autonomno pod MS DOS OS verzijom ne nižom od 3.3. Osnovni programski jezik je Turbo Pascal 6.0.

Zahtjevi za označavanje i pakiranje te zahtjevi za prijevoz i skladištenje prilično su egzotični. U opći slučaj ovdje navedite zahtjeve za označavanje softverskog proizvoda, mogućnosti i metode pakiranja. A zahtjevi za prijevoz i skladištenje moraju navesti uvjete prijevoza softverskog proizvoda, lokacije skladištenja, uvjete skladištenja, uvjete skladištenja, razdoblja skladištenja u različitim uvjetima.

Posebni zahtjevi su vrlo važna stvar. Bolje ih je izbjegavati ako je moguće. I to odmah proglasiti.

Na primjer: Ne postoje posebni zahtjevi za vremenske karakteristike programa. Ne postoje posebni zahtjevi za kapacitivne karakteristike programa.

Tehnički i ekonomski pokazatelji. Ova najteža točka za programera nije uvijek tu. Potreban je prije svega kada vam je cilj opravdati ogromnu učinkovitost i važnost posla koji se obavlja. Ova stavka obično vrlo dobro funkcionira za kupca. To je u najmanju ruku najbolje opravdanje za vremenski i novčani iznos razvoja.

U ovom odjeljku treba navesti: procijenjenu ekonomsku učinkovitost, procijenjenu godišnju potrebu (na primjer: očekivani broj poziva kompleksu u cjelini godišnje - 365 radnih sesija), ekonomske prednosti razvoja u usporedbi s najboljim domaćim i stranim uzorcima ili analozi.

Osim toga, preporučljivo je dati definiciju procijenjenog troška razvoja programa i definiciju složenosti programiranja.

Faze i stupnjevi razvoja(o tome će biti više riječi u nastavku) utvrditi potrebne faze razvoja, faze i sadržaj rada (popis programskih dokumenata koji se moraju izraditi, usuglasiti i odobriti), kao i, u pravilu, rokove izrade i odrediti izvođače.

Ovdje su opisani standardni koraci. Glavna stvar je ispravno odrediti vrijeme. Ako je moguće, pokušajte ravnomjerno rasporediti faze po rokovima (i iznosima). Ne zaboravite da svi projekti ne dođu do završne faze. I trebala bi postojati izvješća za svaku fazu. Upamtite također da će radni projekt oduzeti najviše vremena. Ukoliko dokumentaciju ne ispunite na vrijeme, Naručitelj ima puno pravo uopće ne prihvatiti posao sa svim posljedicama.

Glavne i neizostavne faze i faze su sam projektni zadatak, idejni projekt, tehnički i radni projekti.

• Idejni projekt. U ovoj se fazi detaljno razrađuju strukture ulaznih i izlaznih podataka te se određuje oblik njihova prikaza. U razvoju Opći opis algoritam, sam algoritam, struktura programa. U izradi je akcijski plan za razvoj i provedbu programa.
• Tehnički projekt. Sadrži razvijen algoritam za rješavanje problema kao i metode za praćenje početnih informacija. Ovdje se razvijaju alati za obradu pogrešaka i izdavanje dijagnostičkih poruka, utvrđuju se obrasci za prikaz početnih podataka i konfiguracija tehničke opreme.
• Radni nacrt. U ovoj fazi provodi se programiranje i otklanjanje pogrešaka programa, izrada programskih dokumenata, programa i testnih metoda. U pripremi su primjeri testiranja i otklanjanja pogrešaka. Dokumentacija i grafički materijal su finalizirani. Obično se navodi da tijekom razvoja programa treba pripremiti sljedeću dokumentaciju:

• tekst programa;
• opis programa;
• program i metodologija ispitivanja;
• opis primjene;
• korisnički vodič.

Ovo su standardni zahtjevi. Ako se Kupac slaže da se ne može prezentirati cijeli ovaj popis, to znači da njegove namjere prema Vama i Vašem proizvodu nisu ozbiljne.

Možda neće biti nikakvog grafičkog materijala. Pogotovo kada nećete izvještavati o rezultatima svog rada. Ali za ozbiljne projekte ova stavka je potrebna.

Na primjer: Tijekom izrade programa potrebno je pripremiti sljedeći grafički materijal:

• tehnički i ekonomski pokazatelji;
• struktura programa;
• format za prikaz ulaznih podataka programa;
• dijagram općeg algoritma (2 lista);
• osnovni računalni algoritmi;
• primjer kako program radi.

U poglavlju Postupak kontrole i prijema moraju se specificirati vrste ispitivanja i Opći zahtjevi za prihvaćanje posla. Ako je moguće, tada u ovom stavku naznačite da se "kontrola i prihvaćanje razvoja provodi pomoću opreme koju je kupac osigurao", u suprotnom ćete možda morati donijeti opremu sa sobom.

Na primjer: Kontrola i prihvaćanje razvoja provode se na temelju testa testiranja i primjera otklanjanja pogrešaka. Time se provjerava izvršenje svih funkcija programa.

U Prijave Ako je potrebno, tehničke specifikacije dostavljaju:

• popis istraživanja i drugih radova koji opravdavaju razvoj;
• dijagrame algoritama, tablice, opise, obrazloženja, izračune i druge dokumente koji se mogu koristiti tijekom razvoja;

• drugi izvori razvoja.

Ovim standardom utvrđuju se faze razvoja programa, programska dokumentacija, te faze i sadržaj rada:

Faze razvoja	Faze rada
Tehnički zadatak	Opravdanost potrebe izrade programa	Formulacija problema. Zbirka izvorne građe. Odabir i obrazloženje kriterija učinkovitosti i kvalitete izrađenog programa. Opravdanost potrebe istraživačkog rada.
	Istraživački rad	Određivanje strukture ulaznih i izlaznih podataka. Preliminarni odabir metoda rješavanja problema. Opravdanost izvedivosti korištenja prethodno razvijenih programa. Utvrđivanje zahtjeva za tehničkim sredstvima. Obrazloženje temeljne mogućnosti rješenja problema.
	Izrada i odobravanje tehničkih specifikacija	Utvrđivanje programskih zahtjeva. Izrada studije izvodljivosti za izradu programa. Određivanje faza, faza i vremena razvoja programa i dokumentacije za njega. Izbor programskih jezika. Utvrđivanje potrebe istraživačkog rada u kasnijim fazama. Usklađivanje i odobravanje tehničkih specifikacija.
Idejni projekt	Izrada idejnog projekta	Preliminarna izrada strukture ulaznih i izlaznih podataka. Pojašnjenje metoda za rješavanje problema. Izrada općeg opisa algoritma za rješavanje problema. Izrada studije izvodljivosti.
	Odobrenje idejnog projekta	Usklađivanje i suglasnost na idejni projekt
Tehnički projekt	Izrada tehničkog projekta	Pojašnjenje strukture ulaznih i izlaznih podataka. Razvoj algoritma za rješavanje problema. Određivanje oblika prikaza ulaznih i izlaznih podataka. Definicija semantike i sintakse jezika. Razvoj programske strukture. Konačno određivanje hardverske konfiguracije.
	Suglasnost na tehnički projekt	Izrada akcijskog plana za izradu i provedbu programa. Izrada bilješke s objašnjenjem. Usklađivanje i odobrenje tehničkog projekta.
Radni nacrt	Razvoj programa	Programiranje i otklanjanje pogrešaka
	Izrada programske dokumentacije	Razvoj programskih dokumenata u skladu sa zahtjevima GOST 19.101-77.
	Testiranje programa	Izrada, koordinacija i odobravanje programa i metodologije ispitivanja. Provođenje preliminarnih državnih, interresornih, prijemnih i drugih vrsta ispitivanja. Korekcija programa i programske dokumentacije na temelju rezultata ispitivanja.
Provedba	Priprema i prijenos programa	Priprema i prijenos programa i softverske dokumentacije za održavanje i (ili) proizvodnju. Registracija i odobrenje akta prijenosa programa za održavanje i (ili) proizvodnju. Prijenos programa u fond algoritama i programa.

Bilješke:

1. Dopušteno je isključiti drugi stupanj razvoja, au tehnički opravdanim slučajevima - drugi i treći stupanj. Potreba za ovim stupnjevima navedena je u tehničkim specifikacijama.
2. Dopušteno je kombinirati, isključivati ​​faze rada i (ili) njihov sadržaj, kao i uvoditi druge faze rada prema dogovoru s kupcem.

Ova je norma usmjerena na dokumentiranje rezultirajućeg razvojnog proizvoda.

Strogo govoreći, postoje dva različita dokumenta, koji, međutim, imaju mnogo toga zajedničkog. Ovo je OPĆI OPIS (GOST 19.502-78) i OPIS PROGRAMA (GOST 19.402-78). No, s obzirom na to da je jako teško kvalitetno izraditi oboje, bez pribjegavanja gotovo potpunom umnožavanju i kidanju dijelova, dovoljno bi bilo implementirati jedan, općenitiji, “hibridni” dokument. Nazovimo to "Opis programa".

Zapravo, "Opis programa" u svom sadržaju može se nadopuniti odjeljcima i paragrafima preuzetim iz standarda za druge opisne dokumente i priručnike: GOST 19.404-79 ESPD. Objašnjenje, GOST 19.503-79 ESPD. Vodič za programiranje sustava, GOST 19.504-79 ESPD. Programerski vodič, GOST 19.505-79 ESPD. Upute za rukovanje itd. Konkretno, iz Objašnjenja možete uzeti dijagram algoritma, opći opis algoritma i (ili) funkcioniranja programa, kao i obrazloženje usvojenih tehničkih i tehničko-ekonomskih odluka.

Opis programa mora sadržavati informativni dio - napomenu i sadržaj.

Glavni dio dokumenta trebao bi se sastojati od uvodnog dijela i sljedećih dijelova:

• funkcionalna svrha;
• opis logike.
• uvjeti korištenja;
• sastav i funkcije.

Ovisno o specifičnostima programa, mogu se uvesti dodatni dijelovi.

U Uvodni dio Dokument pruža opće informacije o programu - puni naziv, oznaku, njegove moguće primjene itd.

Na primjer: Program "Automatizirano radno mjesto ACS developer" je namijenjen za... implementiran na.... Program podržava...

U poglavlju Svrha navesti svrhu programa i dati opći opis funkcioniranja programa, njegove glavne karakteristike, informacije o ograničenjima nametnutim opsegu programa, a također navesti vrste elektroničkih računala i uređaja koji se koriste tijekom rada.

Na primjer: Program je dizajniran za rješavanje problema... Program predstavlja jezgru automatizirane radne stanice...

Korisnik ima mogućnost..., implementirati..., pokrenuti..., analizirati..., dobiti rezultate analize i obrade..., izgraditi... itd.

U poglavlju " Opis logike" označiti:

• opis strukture programa i njegovih glavnih dijelova

(na primjer: Program uključuje sljedeće:

• korisničko sučelje,
• modul za određivanje staza u grafu,
• modul za izračun prijenosne funkcije,
• modul za konstruiranje amplitudskih i fazno frekvencijskih karakteristika,
• modul za konstruiranje odgovora na polinomski utjecaj,
• uređivač teksta).

• opis funkcija komponenti i veza među njima;

Na primjer: Program se sastoji od šest modula: modul sučelja; definicijski modul...; modul za izračun...; modul...itd..

Modul sučelja izgrađen je na dvije vrste dijaloga: dijalog pitanje-odgovor i dijalog tipa izbornika. Modul sučelja upravlja...

Modul definicije... To je...

Modul za izračun... itd.

• informacije o programskom jeziku;

Na primjer: Program je napisan na jeziku ... korištenjem prevoditelja ...

• opis ulaznih i izlaznih podataka za svaku od komponenti;

Na primjer: ULAZNI PODACI. Ulazni podaci za program su tekstualna datoteka koja opisuje proširenu matricu incidencije grafa sustava koji se proučava.

IZLAZ. Izlaz je:

• grafičke i tekstualne informacije prikazane na ekranu (rezultati analize sustava);
• datoteke u jednoj od grafički formati- preslike slike izgrađenih karakteristika (AFC, PFC, itd.);
• tekstualne datoteke - izvješća o provedenim istraživanjima;
• dijagnostiku stanja sustava i poruke o svim greškama koje se pojave.

• opis logike sastavnih dijelova (po potrebi treba napisati opis dijagrama programa).

Pri opisu logike programa nužna je poveznica na tekst programa.

U poglavlju Sastav i funkcije navesti opis sastava i funkcije programa te metode korištene za rješavanje problema.

U poglavlju Uvjeti korištenja navedeni su uvjeti potrebni za provedbu programa (zahtjevi za tehničkim sredstvima potrebnim za ovaj program i druge programe, Opće karakteristike ulazne i izlazne informacije te zahtjevi i uvjeti organizacijske, tehničke i tehnološke prirode i sl.).

Na primjer: Program je pokrenut osobno računalo(PC) tipa IBM PC/AT. Za rad u interaktivnom načinu rada koriste se zaslon, tipkovnica i miš. Za podršku grafičkog načina rada potreban je EGA (VGA) adapter. Ulazni podaci pohranjuju se na diskete i/ili tvrde diskove. Program radi pod OS-om...

Dodatak opisu može sadržavati referentne materijale (ilustracije, tablice, grafikone, primjere itd.)

I ne zaboravite navesti naziv modula za učitavanje, kao i opis cijelog postupka

Pozivanje i dizanje sustava

Zahtjevi za dizajn programskog teksta prilično su jednostavni i prirodni za kompetentnog programera. Glavna stvar kojom se treba voditi prilikom izrade ovog dokumenta je da tekst programa treba biti čitljiv.

I dalje je obvezno sastavljanje informativnog dijela - napomena i sadržaja.

Glavninu dokumenta trebaju činiti tekstovi jednog ili više odjeljaka koji se nazivaju.

Tekst svake programske datoteke počinje "zaglavljem", koje označava:

• naziv programa,
• Autor,
• datum izrade programa,
• broj verzije,
• datum zadnje izmjene.

Komentari su obavezni, kao i strogo pridržavanje pravila uvlačenja. Zapamtite, čak i nemogućnost izrade softverske dokumentacije može biti opravdana. Ali ružan programski tekst – nikad. Pozivanje na činjenicu da je ovaj tekst razumljiv samom autoru ne uzima se za ozbiljno. Ne treba se sramiti dati programske tekstove drugima na čitanje.

Ispod je primjer tako dobro čitljivog programskog teksta (preuzeto s web stranice Nikolaja Gekhta, e-mail: [e-mail zaštićen], http://users.omskreg.ru/~geht)

/* Windows 98 izvori

Izvorni kod za 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) yte_swapfile (); do_nothing_loop (); totilla_screw_up_hpfs_file_system (); search_and_destroy_rest_of_os/2 (); onemogući _netscape (); onemogući_RealPlayer (); disable_Corel_Products(); hang_system(); ) write_something(bilo što); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(still_not_crashed) ( display_copyright_message(); do_nothing_loop(); basically_run_windows_3.1(); do_nothing_loop ( ); do_nothing_loop(); ) ) if(detect_cache()) disable_cache(); if(fast_cpu()) ( set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(action, jumpy); set_mouse(reaction, ponekad ) ; ) /* printf("Dobrodošli u Windows 3.11"); */ /* printf("Dobrodošli u Windows 95"); */ printf("Dobro došli u Windows 98"); if(system_ok()) crash(to_dos_prompt ) else system_memory = open("a:\swp0001.swp", O_CREATE); while(something) ( sleep(5); get_user_input(); spavanje(5); djelovati_na_unos_korisnika(); spavanje(5); ) create_general_protection_fault();

Ovaj dokument sadrži opis što i kako treba učiniti kako bi se uvjerio (i uvjerio kupca) da program radi ispravno. Zapravo, ovaj dokument je odlučujući za testove prihvaćanja. Dobro osmišljen ispitni program i metodologija ključ su za potpisivanje potvrde o prihvaćanju, tj. stvar za koju ste potrošili toliko truda i vremena.

Formalno, ovaj GOST se koristi za izradu planskih dokumenata i provođenje testnih radova za procjenu spremnosti i kvalitete softverskog sustava. Dokument sadrži opis predmeta i svrhe testiranja, zahtjeve za programsku i programsku dokumentaciju, sredstva i postupak testiranja, kao i opis primjera ispitivanja.

Komponente ovog dokumenta lakše su i jasnije opisane u obliku primjera.

Ispitni objekt

Primjer: Test objekt je program ..., namijenjen za ...

Svrha testiranja

Primjer: Provjera pouzdanosti programa.

Programski zahtjevi

Primjer: Rad programa ne smije dovesti do kvara (fatalnog poremećaja sustava). Organizacija dijaloga treba osigurati zaštitu od unosa netočnih podataka. Program bi trebao omogućiti dijagnostiku stanja sustava i poruke o greškama koje su se dogodile... itd.

Zahtjevi za softversku dokumentaciju

Primjer: Sadržaj softverske dokumentacije prezentirane tijekom testiranja:

• opis programa (GOST 19.402-78);
• program i metodologija ispitivanja (GOST 19.301-79);
• tekst programa (GOST 19.401-78).

Sredstva i postupak ispitivanja

Primjer: Program radi u skladu s radnim uvjetima operativnog sustava MS DOS (verzija ne niža od 3.0) na računalu kao što je IBM PC/AT, kao i na kompatibilnim. Za rad je također potreban EGA (VGA) adapter.

Postupak ispitivanja:

1. Program je pokrenut....
2. Odabran...
3. pritisnut...
4. Redom odabrano...

Test slučajevi

Primjer: Za testiranje su predloženi ... čiji su opisi sadržani u datotekama ... Sadržaj testnih datoteka i rezultati programa dani su u Dodatku 1.

I na kraju, osvrnimo se na posljednje ESPD standard koji se zove

Ova norma utvrđuje pravila za izvršavanje programskih dokumenata za računala, komplekse i sustave, bez obzira na njihovu namjenu i opseg primjene i predviđena ESPD standardima.

Opći zahtjevi. Potrebno je crnom tintom unijeti pojedine riječi, formule, simbole (ručno crtačkim fontom), slova latinične i grčke abecede, kao i crtati dijagrame i crteže u programske dokumente izrađene strojno, strojno i rukopisno. ili tinta.

Tipfeleri i grafičke netočnosti otkrivene tijekom postupka izvođenja mogu se ispraviti brisanjem loše izvedenog dijela teksta (crteža) i nanošenjem ispravljenog teksta (grafike) na isti list strojopisom ili crnom tintom, ovisno o načinu izvođenja. dokument.

Oštećenje listova dokumenta, mrlje i tragovi nepotpuno izbrisanog teksta (grafike) nisu dopušteni.

Programski dokumenti izrađuju se na listovima formata A4. Osim:

• Prihvatljivo je tiskati na A3 listove;
• kod strojnog načina izrade dokumenta dopuštena su odstupanja u veličini listova koja odgovaraju formatima A4 i A3, određena mogućnostima korištenih tehničkih sredstava; na listovima formata A4 i A3, predviđenim izlaznim karakteristikama uređaja za izlaz podataka, kod strojne izrade dokumenta;
• Kod izrade dokumenta tipografskom metodom moguće je koristiti listove tipografskih formata.

Materijali programskog dokumenta raspoređeni su sljedećim redoslijedom:

• naslovni dio:

• list odobrenja (ne ulazi u ukupan broj listova dokumenta);
• naslovna stranica (prva stranica dokumenta);

• informativni dio:

• anotacija;
• sadržaj;

• glavni dio:

• tekst dokumenta (sa slikama, tablicama i sl.);
• popis pojmova i njihovih definicija;
• popis kratica;
• aplikacije;
• predmetni indeks;
• popis referentnih dokumenata;

• dio zapisivanja promjena:

• promijeniti upisni list.

Konstrukcija dokumenta. Ako je potrebno, dopušteno je podijeliti dokument na dijelove. Podjela na dijelove provodi se na razini koja nije niža od odjeljka. Svaki dio popunjava se zasebno, a na kraju sadržaja prvog dijela treba navesti nazive preostalih dijelova.

U dokument je dopušteno uključiti dijelove programskog teksta, oblikovane u skladu s pravilima jezika na kojem je programski tekst napisan.

Sažetak je objavljen na zasebna stranica(stranice), s naslovom "SAŽETAK", numerirani i uključeni u sadržaj dokumenta.

Tekst svakog dokumenta, po potrebi, dijeli se na odlomke, a odlomci u podstavke, neovisno o tome je li dokument podijeljen na dijelove, odjeljke i pododjeljke ili ne.

Naslovi odjeljaka pišu se velikim slovima i postavljaju simetrično u odnosu na desni i lijevi rub teksta. Naslovi pododjeljaka pišu se iz odlomka mala slova(osim prvog kapitala). Rastavljanje riječi u naslovima nije dopušteno. Na kraju naslova nema točke. Preporuča se započeti svaki odjeljak na novom listu.

Odjeljke, pododjeljke, paragrafe i podstavke treba numerirati arapskim brojevima s točkom. Odjeljci moraju imati redni broj (1, 2 itd.)

Tekst dokumenta. Tekst dokumenta treba biti kratak, jasan, isključujući mogućnost pogrešnog tumačenja. Pojmovi i definicije moraju biti jedinstveni i u skladu s utvrđenim standardima, a u nedostatku - općeprihvaćeni u znanstvenoj i stručnoj literaturi, te biti navedeni u popisu pojmova.

Potrebna objašnjenja teksta dokumenta mogu se dati u fusnotama. Bilješka je označena brojem sa zagradom postavljenom na razini gornjeg ruba fonta.

Ako se bilješka odnosi na jednu riječ, znak fusnote stavlja se neposredno uz tu riječ, a ako se odnosi na rečenicu u cjelini, onda na kraju rečenice. Tekst fusnote stavlja se na kraj stranice i od glavnog teksta odvaja crtom duljine 3 cm na lijevoj strani stranice.

Ilustracije. Ilustracije se mogu nalaziti u tekstu dokumenta i (ili) u prilozima. Ilustracije, ako ih u pojedinom dokumentu ima više, numeriraju se arapskim brojevima kroz cijeli dokument.

U dodacima, ilustracije su numerirane unutar svakog dodatka redoslijedom utvrđenim za glavni tekst dokumenta. Upućivanja na ilustracije daju se prema vrsti: “Sl. 12” ili “(Sl. 12)”. Ilustracije mogu imati tematski naslov i tekst opisa koji objašnjava sadržaj ilustracije.

Formule. Formule u dokumentu, ako ih ima više, numeriraju se arapskim brojevima, uz broj se stavlja desna strana stranice, u zagradama na razini formule. Unutar cijelog dokumenta ili njegovih dijelova, ako je dokument podijeljen na dijelove, formule imaju kontinuirani broj.

Upućivanje u tekstu na redni broj formule navodi se u zagradama, na primjer: "u formuli (3)". Kod dijeljenja dokumenta na dijelove, broj dijela se stavlja ispred rednog broja formule i odvaja se od zadnje točke, na primjer: "u formuli (1.4)".

Značenje simbola uključenih u formulu mora biti navedeno neposredno ispod formule. Značenje svakog znaka ispisuje se u novom retku redoslijedom kojim su navedeni u formuli. Prvi redak prijepisa treba započeti riječju "gdje", bez dvotočke iza nje.

Linkovi. Upućivanja na standarde i druge dokumente dopuštena su u dokumentima o politici. Treba se pozvati na dokument u cjelini ili na njegove dijelove (uz naznaku i naziv dokumenta, broj i naziv odjeljka ili priloga).

Dopušteno je navesti samo oznaku dokumenta i (ili) odjeljaka bez navođenja njihovih naziva. Upućivanje na pojedine pododjeljke, paragrafe i ilustracije drugog dokumenta nije dopušteno. Dopuštene su poveznice unutar dokumenta na odlomke, ilustracije i pojedinačne pododjeljke.

Bilješke Bilješke uz tekst i tablice navode samo referentne podatke i podatke s objašnjenjima. Jedna bilješka nije numerirana. Iza riječi "Napomena" stavite točku. Nekoliko bilješki treba redom numerirati arapskim brojevima s točkom. Iza riječi "Napomena" staviti dvotačku. Tekst bilješki može se ispisati samo u jednom intervalu.

Kratice. Nisu dopuštene kratice riječi u tekstu i natpisi ispod ilustracija, osim:

• kratice utvrđene u GOST 2.316-68 i općenito prihvaćene na ruskom jeziku;
• kratice koje se koriste za označavanje programa, njihovih dijelova i načina rada, u jezicima za kontrolu zadataka, u alatima za konfiguraciju programa itd., označene slovima latinične abecede.

Prijave. Ilustrirani materijal, tablice ili popratni tekst mogu se prikazati u obliku priloga. Aplikacije su osmišljene kao nastavak ovog dokumenta na sljedećim stranicama ili izdati kao poseban dokument.

Svaka aplikacija mora započeti sa nova stranica s indikacijom na desnoj strani gornji kut riječi "Aplikacija" i imaju tematski naslov. Ako u dokumentu postoji više od jednog priloga, svi prilozi su numerirani arapskim brojevima (bez znaka br.), na primjer:

Dodatak 1, Dodatak 2 itd.

Prilikom izdavanja zahtjeva kao posebne isprave, na naslovnoj stranici ispod naziva isprave treba naznačiti riječ "Prilog", a ako je više prijava, treba navesti i njen redni broj.

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

Jedinstveni sustav programske dokumentacije	GOST 19.103-77
ODREĐIVANJE PROGRAMA I PROGRAMSKIH DOKUMENTA
Jedinstveni sustav programske dokumentacije. Indeksiranje programa i programskih dokumenata.

Datum uvođenja od 01.01.80

1. Ova norma utvrđuje strukturu označavanja programa i programskih dokumenata za računala, komplekse i sustave, bez obzira na njihovu namjenu i opseg.

2. Označavanje programa i dokumenata mora se sastojati od skupina znakova odvojenih točkama (nakon šifre zemlje i šifre organizacije razvojnog programera), razmaka (nakon revizijskog broja dokumenta i šifre vrste dokumenta) i crtica (nakon registracijskog broja i broj dokumenta ove vrste).

3. Uspostavlja se registracijski sustav za označavanje programa i programskih dokumenata.

Struktura programske oznake i njezin programski dokument – ​​specifikacije:

A.B.XXXXX-XX
Opći dio oznake / Kod države | | | |
programi i softver | Šifra organizacije programera | | |
dokumenti za to\ Matični broj | |
Broj izdanja (za program) |
Broj revizije (za dokument) |

4. Struktura oznake ostalih programskih dokumenata:

A.B.XXXXX-XX XX XX-x
Opći dio programa oznaka | | | | |
i programski dokumenti za to | | | | |
Broj revizije dokumenta | | | |
Šifra vrste dokumenta | | |
Broj dokumenta ove vrste | |
Broj dijela dokumenta |

5. Šifra države nositelja projekta i šifra organizacije (poduzeća) nositelja projekta dodjeljuju se na propisani način.

Registarski broj dodjeljuje se u skladu s All-Union klasifikatorom programa, koji je odobrio Gosstandart na propisani način.

Prije odobrenja All-Union Klasifikatora programa, dopušteno je dodijeliti registarski broj uzlaznim redoslijedom, počevši od 00001 do 99999, za svaku organizaciju (poduzeće) u razvoju.

Broj objave programa ili broj revizije dokumenta dodjeljuje se uzlaznim redoslijedom od 01 do 99.

6. Šifra vrste dokumenta dodjeljuje se u skladu sa zahtjevima GOST 19.101-77.

7. Broj dokumenta ove vrste dodjeljuje se uzlaznim redoslijedom od 01 do 99.

8. Broj dijela istog dokumenta dodjeljuje se uzlaznim redoslijedom od 1 do 9.

Bilješka. Ako se dokument sastoji od jednog dijela, tada se crtica i redni broj dijela ne označavaju.

9. Broj revizije specifikacije i popisa operativnih dokumenata za program mora odgovarati broju objave istog programa.

Ponovno izdavanje. studenog 1987