GOST o vrstah dokumentov programske opreme. Priprava dokumentacije za program po GOST. Kratek algoritem načrtovanja programa

Datum uvedbe od 01.01.80

Ta standard določa vrste programov in programskih dokumentov za računalnike, komplekse in sisteme, ne glede na njihov namen in obseg.

Standard je popolnoma v skladu s ST SEV 1626-79.

1. VRSTE PROGRAMOV

1.1. Program (v skladu z GOST 19781-90) je mogoče identificirati in uporabljati samostojno in (ali) kot del drugih programov.

1.2. Programi so razdeljeni na vrste, prikazane v tabeli. 1

Tabela 1

1.3. Za program razvito dokumentacijo je mogoče uporabiti za implementacijo in prenos programa na pomnilniški medij ter za izdelavo programskega izdelka.

1.2,1.3.

2. VRSTE PROGRAMSKIH DOKUMENTOV

2.1. Dokumenti programske opreme vključujejo dokumente, ki vsebujejo informacije, potrebne za razvoj, proizvodnjo, vzdrževanje in delovanje programov.

2.2. Vrste programskih dokumentov in njihove vsebine so podane v tabeli. 2.

tabela 2

Vrsta programskega dokumenta	Vsebina političnega dokumenta
Specifikacija	Sestava programa in njegova dokumentacija
	Seznam podjetij, ki hranijo originalne programske dokumente
Besedilo programa	Snemanje programa s potrebnimi komentarji
Opis programa	Informacije o logični zgradbi in delovanju programa
	Zahteve, ki jih je treba preveriti pri testiranju programa, ter postopek in metode njihovega nadzora
Tehnična naloga	Namen in obseg programa, tehnične, izvedljive in posebne zahteve za program, potrebne stopnje in roki razvoja, vrste testov.
Pojasnilo	Diagram algoritma, splošen opis algoritma in (ali) delovanja programa ter utemeljitev sprejetih tehničnih in tehnično-ekonomskih odločitev.
Operativni dokumenti	Informacije za zagotavljanje delovanja in delovanja programa

(Spremenjena izdaja, sprememba št. 1).

2.3. Vrste operativnih dokumentov in njihova vsebina so podane v tabeli 3.

Tabela 3

Vrsta operativnega dokumenta	Vsebina operativnega dokumenta
	Seznam operativnih dokumentov za program
Oblika	Glavne značilnosti programa, popolnost in podatki o delovanju programa
Opis aplikacije	Informacije o namenu programa, obsegu uporabe, uporabljenih metodah, razredu problemov, ki jih je treba rešiti, omejitvah za uporabo, minimalni konfiguraciji strojne opreme.
	Informacije za preverjanje, zagotavljanje delovanja in prilagajanje programa za pogoje določene aplikacije
Programerski vodnik	Informacije za uporabo programa
Navodila za uporabo	Informacije za zagotavljanje postopka komunikacije med operaterjem in računalniškim sistemom med izvajanjem programa
Opis jezika	Opis sintakse in semantike jezika
	Informacije za uporabo testnih in diagnostičnih programov pri servisiranju tehnične opreme

(Spremenjena izdaja, sprememba št. 1).

2.4. Programski dokumenti so glede na način izvajanja in naravo uporabe razdeljeni na izvirnike, dvojnike in kopije (GOST 2.102-68), namenjene razvoju, vzdrževanju in delovanju programa.

2.5. Vrste programskih dokumentov, razvitih v različnih fazah, in njihove kode so podane v tabeli s kliki. 4.

Tabela 4

Koda vrste dokumenta	Vrsta dokumenta	Razvojne faze
		Idejni projekt	Tehnični projekt	Delovni osnutek
		Idejni projekt	Tehnični projekt	komponento	kompleksen
-	Specifikacija	-	-
05	Seznam originalnih imetnikov	-	-	-
12	Besedilo programa	-	-
13	Opis programa	-	-
20	Seznam operativnih dokumentov	-	-
30	Oblika	-	-
31	Opis aplikacije	-	-
32	Priročnik za sistemskega programerja	-	-
33	Programerski vodnik	-	-
34	Navodila za uporabo	-	-
35	Opis jezika	-	-
46	Priročnik za vzdrževanje	-	-
51	Testni program in metodologija	-	-
81	Pojasnilo			-	-
90-99	Drugi dokumenti

Legenda:
- dokument je obvezen;
- dokument je obvezen za komponente, ki imajo samostojno uporabo;
- potreba po pripravi dokumenta je določena v fazi razvoja in odobritve tehničnih specifikacij;
- - listina ni sestavljena.

2.2-2.5. (Spremenjena izdaja, sprememba št. 1).

2.6. Dovoljeno je združevanje nekaterih vrst operativnih dokumentov (razen seznama operativnih dokumentov in obrazca). Potreba po združitvi teh dokumentov je navedena v tehničnih specifikacijah. Spojenemu dokumentu se dodeli ime in oznaka enega od spojenih dokumentov.

Spojeni dokumenti morajo določati informacije, ki morajo biti vključene v vsak dokument, ki se združuje.

2.7. V fazi razvoja in odobritve tehničnih specifikacij se ugotovi potreba po pripravi tehničnih specifikacij, ki vsebujejo zahteve za izdelavo, nadzor in sprejem programa.

Tehnične specifikacije so razvite v fazi "Detajlni projekt".

2.8. Potreba po pripravi tehničnih specifikacij za komponente, ki niso namenjene samostojni uporabi, in komplekse, ki so vključeni v druge komplekse, se določi po dogovoru s stranko.

(Dodatno uvedena sprememba št. 1).

Ponovna izdaja (november 1987) s spremembo št. 1, odobrena junija 1981 (IUS 9-81)

Ko programer dobi nalogo za razvoj programa, se on, vodja projekta in celotna projektna ekipa soočijo z naslednjimi vprašanji:

kaj je treba storiti poleg programa?
kakšno dokumentacijo je treba napisati?
kaj sporočiti uporabnikom in kaj? spremstvo storitev?
kako upravljati razvojni proces?
Kaj mora vsebovati projektna naloga?

Poleg omenjenih vprašanj obstaja še veliko drugih.

Na vsa ta vprašanja so nekoč odgovorili državni standardi za programsko dokumentacijo - niz standardov 19. serije GOST ESPD. Toda že takrat so imeli programerji veliko pritožb glede teh standardov. Nekatere stvari je bilo treba večkrat neupravičeno podvajati v dokumentaciji, marsikaj pa ni bilo predvideno, na primer specifika dokumentiranja programov, ki delajo z bazo podatkov.

Do danes je vprašanje obstoja sistema standardov, ki urejajo dokumentacijo razvitih programov, še vedno pomembno.

2. Splošne značilnosti stanja

Osnova domačega regulativnega okvira na področju programske dokumentacije je niz standardov Enotnega sistema programske dokumentacije (USPD). Glavni in večji del tega kompleksa je bil razvit v 70. in 80. letih. Trenutno ta kompleks predstavlja sistem meddržavnih standardov držav CIS, ki delujejo na ozemlju Ruske federacije na podlagi meddržavnega sporazuma o standardizaciji.

Standardi ESPD zajemajo tisti del dokumentacije, ki nastane v procesu razvoja programa in je povezan z dokumentiranjem funkcionalnih značilnosti. Ne pozabite, da so standardi ESPD (GOST 19) svetovalne narave. Vendar to velja tudi za druge standarde na področju razvoja programske opreme, kot so: GOST 34, mednarodni standard ISO/IEC itd. V skladu z zakonom Ruske federacije "o standardizaciji" ti standardi postanejo obvezni le na pogodbene podlage – torej ob sklicevanju nanje v pogodbi o razvoju programa.

Če govorimo o stanju ESPD kot celote, lahko rečemo, da je večina standardov moralno zastarela.

K glavnim pomanjkljivostim ESPD lahko pripišemo:

usmerjenost k enotnemu, »kaskadnemu« modelu življenjskega cikla programa;
pomanjkanje jasnih priporočil za dokumentiranje značilnosti kakovosti;
pomanjkanje povezav z drugimi obstoječimi domačimi sistemi standardov, na primer ESKD;
slabo izražen pristop k dokumentiranju programa kot komercialnega izdelka;
pomanjkanje priporočil za interno dokumentacijo, kot so zaslonski meniji, pomoč pri delu s programom itd.;
pomanjkanje priporočil o sestavi, vsebini in izvedbi dokumentov za program, skladnih z mednarodnimi in regionalnimi standardi.

Iz tega sledi, da potrebuje ESPD popolno revizijo na podlagi standarda ISO/IEC 12207-95 (ta standard bo podrobneje obravnavan v nadaljevanju).

Omeniti velja, da poleg ESPD v uradnem regulativnem okviru Ruske federacije na področju dokumentiranja programov in sorodnih področij obstajajo številni obetavni standardi, na primer:

mednarodni standard ISO/IEC 12207: 1995-08-01 organizirati življenjski cikel programskih izdelkov.

Kompleksni standardi GOST 34 za ustvarjanje in razvoj avtomatiziranih sistemov.

2.1. Kratek opis razpoložljivih standardov ESPD

Kljub pomanjkljivostim je veliko standardov ESPD mogoče koristno uporabiti za dokumentiranje programov, ker:

Standardi ESPD uvajajo značilen red v proces dokumentiranja programov;
Sestavo programskih dokumentov, ki jo predvidevajo standardi ESPD, je mogoče spreminjati z dodajanjem dodatnih vrst dokumentov v nabor dokumentacije.
Standardi ESPD omogočajo spreminjanje strukture in vsebine glede na specifične zahteve kupca in uporabnika.

Hkrati naročnik in vodja projekta izbereta ustrezen podmnožico standardov in dokumentacije za projekt, jih dopolnita s potrebnimi razdelki (izključi nepotrebne) in povežeta izdelavo teh dokumentov s shemo, uporabljeno v projektu.

Standardi ESPD so razdeljeni v skupine, prikazane v tabeli:

Oznaka standarda ESPD temelji na klasifikacijskih merilih:

Oznaka standarda ESPD mora vsebovati:

številka 19 (dodeljena razredu standardov ESPD);
ena številka (za piko), ki označuje oznako klasifikacijske skupine standardov, navedenih v tabeli;
dvomestno število (za pomišljajem), ki označuje leto registracije standarda.

Seznam dokumentov ESPD:

GOST 19.001-77 ESPD. Splošne določbe.
GOST 19.101-77 ESPD. Vrste programov in programski dokumenti.
GOST 19.102-77 ESPD. Razvojne faze.
GOST 19.103-77 ESPD. Označevanje programov in programskih dokumentov.
GOST 19.104-78 ESPD. Osnovni napisi.
GOST 19.105-78 ESPD. Splošne zahteve za programske dokumente.
GOST 19.106-78 ESPD. Zahteve za tiskane programske dokumente.
GOST 19.201-78 ESPD. Tehnična naloga. Zahteve glede vsebine in oblikovanja.
GOST 19.202-78 ESPD. Specifikacija. Zahteve glede vsebine in oblikovanja.
GOST 19.301-79 ESPD. Testni postopek in metodologija.
GOST 19.401-78 ESPD. Besedilo programa. Zahteve glede vsebine in oblikovanja.
GOST 19.402-78 ESPD. Opis programa.
GOST 19.404-79 ESPD. Pojasnilo. Zahteve glede vsebine in oblikovanja.
GOST 19.501-78 ESPD. Oblika. Zahteve glede vsebine in oblikovanja.
GOST 19.502-78 ESPD. Opis aplikacije. Zahteve glede vsebine in oblikovanja.
GOST 19.503-79 ESPD. Priročnik za sistemskega programerja. Zahteve glede vsebine in oblikovanja.
GOST 19.504-79 ESPD. Programerski vodnik.
GOST 19.505-79 ESPD. Navodila za uporabo.
GOST 19.506-79 ESPD. Opis jezika.
GOST 19.508-79 ESPD. Priročnik za vzdrževanje. Zahteve glede vsebine in oblikovanja.
GOST 19.604-78 ESPD. Pravila za spreminjanje programskih dokumentov, ki se izvajajo v tisku.
GOST 19.701-90 ESPD. Sheme algoritmov, programov, podatkov in sistemov. Dogovori in pravila izvajanja.
GOST 19.781-90. Programska oprema za sisteme za obdelavo informacij.

Izrazi in definicije

Od vseh standardov ESPD se bomo osredotočili na tiste, ki se lahko pogosteje uporabljajo v praksi razvoja programov.

Prvi standard, ki ga je mogoče uporabiti pri izdelavi tehničnih specifikacij za programiranje, je GOST (ST SEV) 19.201-78 (1626-79). ESPD.
(Tehnične specifikacije. Vsebinske in oblikovne zahteve.).

Projektna naloga za razvoj programa vsebuje nabor zahtev za program in se lahko uporablja kot nabor meril, potrebnih za preverjanje in sprejem izdelanega programa. Zato je dokaj popolna tehnična specifikacija eden od začetnih dokumentov projekta.

Projektna naloga za razvoj programa mora vsebovati naslednje razdelke:

uvod;
razlogi za razvoj;
namen razvoja;
zahteve za program ali programski izdelek;
zahteve za dokumentacijo programske opreme;
tehnični in ekonomski kazalci;
faze in stopnje razvoja;
postopek kontrole in prevzema;
različne aplikacije (po potrebi).

Glede na značilnosti programa je možno razjasniti vsebino razdelkov, uvesti nove razdelke ali združiti obstoječe.

Drugi standard je GOST (ST SEV) 19.101-77 (1626-79). ESPD.
Vrste programov in programski dokumenti).
Ta standard določa vrste programov in programskih dokumentov za računalnike, komplekse in sisteme, ne glede na njihov namen in obseg.

Vrste programov:

Vrste programskih dokumentov:

Vrsta programskega dokumenta	Vsebina političnega dokumenta
Specifikacija	Sestava programa in njegova dokumentacija
	Seznam podjetij, ki hranijo originalne programske dokumente
Besedilo programa	Snemanje programa s potrebnimi komentarji
Opis programa	Informacije o logični zgradbi in delovanju programa
	Zahteve, ki jih je treba preveriti pri testiranju programa, ter postopek in metode njihovega nadzora
Tehnična naloga	Namen in obseg programa, tehnične, izvedljive in posebne zahteve za program, potrebne stopnje in roki razvoja, vrste testov.
Pojasnilo	Diagram algoritma, splošen opis algoritma in (ali) delovanja programa ter utemeljitev sprejetih tehničnih in tehnično-ekonomskih odločitev.
Operativni dokumenti	Informacije za zagotavljanje delovanja in delovanja programa

Vrste operativnih dokumentov:

Vrsta operativnega dokumenta	Vsebina operativnega dokumenta
	Seznam operativnih dokumentov za program
Oblika	Glavne značilnosti programa, popolnost in podatki o delovanju programa
Opis aplikacije	Informacije o namenu programa, obsegu uporabe, uporabljenih metodah, razredu problemov, ki jih je treba rešiti, omejitvah za uporabo, minimalni konfiguraciji strojne opreme.
	Informacije za preverjanje, zagotavljanje delovanja in prilagajanje programa za pogoje določene aplikacije
Programerski vodnik	Informacije za uporabo programa
Navodila za uporabo	Informacije za zagotavljanje postopka komunikacije med operaterjem in računalniškim sistemom med izvajanjem programa
Opis jezika	Opis sintakse in semantike jezika
	Informacije za uporabo testnih in diagnostičnih programov pri servisiranju tehnične opreme

Programski dokumenti so glede na način izvajanja in naravo uporabe razdeljeni na izvirnike, dvojnike in kopije (GOST 2.102-68), namenjene razvoju, vzdrževanju in delovanju programa.

Vrste programskih dokumentov, razvitih na različnih stopnjah, in njihove kode:

Koda vrste dokumenta	Vrsta dokumenta	Razvojne faze
		Idejni projekt	Tehnični projekt	Delovni osnutek
		Idejni projekt	Tehnični projekt	komponento	kompleksen
-	Specifikacija	-	-	!	+
05	Seznam originalnih imetnikov	-	-	-	?
12	Besedilo programa	-	-	+	?
13	Opis programa	-	-	?	?
20	Seznam operativnih dokumentov	-	-	?	?
30	Oblika	-	-	?	?
31	Opis aplikacije	-	-	?	?
32	Priročnik za sistemskega programerja	-	-	?	?
33	Programerski vodnik	-	-	?	?
34	Navodila za uporabo	-	-	?	?
35	Opis jezika	-	-	?	?
46	Priročnik za vzdrževanje	-	-	?	?
51	Testni program in metodologija	-	-	?	?
81	Pojasnilo	?	?	-	-
90-99	Drugi dokumenti	?	?	?	?

Dovoljeno je združevanje nekaterih vrst dokumentov (razen seznama operativnih dokumentov in obrazca), medtem ko je potreba po združevanju teh dokumentov navedena v tehničnih specifikacijah. Spojenemu dokumentu se dodeli ime in oznaka enega od spojenih dokumentov. Združeni dokumenti morajo navajati informacije, ki jih mora vsebovati vsak združeni dokument.

…………………………………………………………

GOST 19.102-77. ESPD. Razvojne faze.

Določa stopnje razvoja programov in programske dokumentacije za računalnike, komplekse in sisteme, ne glede na njihov namen in obseg uporabe.

Faze razvoja programa, faze in vsebina dela

Razvojne faze	Faze dela	Vsebina dela
Tehnična naloga	Utemeljitev potrebe po razvoju programa	Oblikovanje problema. Zbirka izvornih materialov. Izbira in utemeljitev meril za učinkovitost in kakovost razvitega programa. Utemeljitev potrebe po raziskovalnem delu.
	Raziskovalno delo	Določanje strukture vhodnih in izhodnih podatkov. Predhodna izbira metod reševanja problema. Utemeljitev izvedljivosti uporabe predhodno razvitih programov. Določitev zahtev za tehnična sredstva. Utemeljitev temeljne možnosti rešitve problema.
	Razvoj in odobritev tehničnih specifikacij	Določitev programskih zahtev. Izdelava študije izvedljivosti za razvoj programa. Določitev stopenj, stopenj in časovnega okvira razvoja programa in dokumentacije zanj. Izbira programskih jezikov. Ugotavljanje potrebe po raziskovalnem delu v naslednjih fazah. Usklajevanje in potrditev tehničnih specifikacij.
Idejni projekt	Izdelava idejnega projekta	Predhodni razvoj strukture vhodnih in izhodnih podatkov. Pojasnitev metod za rešitev problema. Razvoj splošnega opisa algoritma za reševanje problema. Izdelava študije izvedljivosti.
Idejni projekt	Potrditev idejnega projekta	Razvoj pojasnjevalne opombe. Usklajevanje in potrditev idejnega projekta
Tehnični projekt	Razvoj tehničnega projekta	Razjasnitev strukture vhodnih in izhodnih podatkov. Razvoj algoritma za rešitev problema. Določanje oblike prikaza vhodnih in izhodnih podatkov. Opredelitev semantike in sintakse jezika. Razvoj programske strukture. Končna določitev konfiguracije strojne opreme.
Tehnični projekt	Soglasje tehnične zasnove	Izdelava akcijskega načrta za razvoj in izvajanje programov. Razvoj pojasnjevalne opombe. Usklajevanje in potrditev tehničnega projekta.
Delovni osnutek	Razvoj programa	Programiranje in odpravljanje napak
	Razvoj programske dokumentacije	Razvoj programskih dokumentov v skladu z zahtevami GOST 19.101-77.
	Testiranje programa	Razvoj, usklajevanje in potrditev testnega programa in metodologije. Izvajanje predhodnih državnih, medoddelčnih, sprejemnih in drugih vrst testov. Popravek programa in programske dokumentacije na podlagi rezultatov testiranja.
Izvedba	Priprava in prenos programa	Priprava in prenos programov in programske dokumentacije za vzdrževanje in (ali) proizvodnjo. Registracija in odobritev akta o prenosu programa za vzdrževanje in (ali) proizvodnjo. Prenos programa v sklad algoritmov in programov.

Opombe:

Dovoljeno je izključiti drugo stopnjo razvoja, v tehnično utemeljenih primerih pa drugo in tretjo stopnjo. Potreba po teh stopnjah je navedena v tehničnih specifikacijah.
Dovoljeno je kombinirati, izločiti faze dela in (ali) njihovo vsebino ter uvesti druge faze dela po dogovoru s stranko.

GOST 19.103-77 ESPD. Označevanje programov in programskih dokumentov

Šifra države razvijalca in šifra organizacije razvijalca se dodelita na predpisan način.

Registrska številka je dodeljena v naraščajočem vrstnem redu, od 00001 do 99999, za vsako razvojno organizacijo.
Številka objave programa ali številka revizije. številka dokumenta te vrste, številka dela dokumenta se dodeli v naraščajočem vrstnem redu od 01 do 99. (Če je dokument sestavljen iz enega dela, se vezaj in zaporedna številka dela ne navedeta).
Številka revizije specifikacije in seznama operativnih dokumentov za program se mora ujemati s številko objave istega programa.

GOST 19.105-78 ESPD. Splošne zahteve za programske dokumente

Ta standard določa splošne zahteve za izvajanje programskih dokumentov za računalnike, komplekse in sisteme, ne glede na njihov namen in obseg uporabe ter jih določajo standardi Enotnega sistema programske dokumentacije (USPD) za kateri koli način izvajanja dokumentov na različnih nosilci podatkov.

Programski dokument je lahko predstavljen na različnih vrstah pomnilniških medijev in je sestavljen iz naslednjih običajnih delov:
naslov;
informativni;
osnovni.

Pravila za izvedbo dokumenta in njegovih delov na posameznem nosilcu podatkov določajo ESPD standardi za pravila za izvajanje dokumentov na pripadajočih nosilcih podatkov.

GOST 19.106-78 ESPD. Zahteve za tiskane programske dokumente

Programske dokumente pripravljajo:

na listih formata A4 (GOST 2.301-68) pri pripravi dokumenta s tipkanjem ali rokopisom;
Možnost tiskanja na liste velikosti A3;
pri strojnem načinu izdelave dokumentov so dovoljena odstopanja v velikosti listov, ki ustrezajo formatoma A4 in A3, ki jih določajo zmogljivosti uporabljenih tehničnih sredstev; na listih formatov A4 in A3, ki jih predvidevajo izhodne lastnosti naprav za izpisovanje podatkov, pri strojni izdelavi dokumenta;
na listih tipografskih formatov pri izdelavi dokumenta s tipografsko metodo.

Gradiva programskega dokumenta so urejena v naslednjem zaporedju:

Naslovni del:

odobritveni list (ni vključen v skupno število listov dokumenta);
naslovna stran (prva stran dokumenta);

informativni del:

opomba;
kazalo;

glavni del:

besedilo dokumenta (s slikami, tabelami itd.)
seznam pojmov in njihovih definicij;
seznam okrajšav;
aplikacije;
predmetno kazalo;
seznam referenčnih dokumentov;

del beleženja sprememb:

sprememba vpisnega lista.

Po potrebi je naveden seznam pojmov in njihovih definicij, seznam okrajšav, priloge, predmetno kazalo, seznam referenčnih dokumentov.

Naslednji standard je osredotočen na dokumentiranje nastalega razvojnega izdelka:

GOST 19.402-78 ESPD. Opis programa

Sestavo dokumenta "Opis programa" po svoji vsebini lahko dopolnite z razdelki in odstavki, vzetimi iz standardov za druge opisne dokumente in priročnike: GOST 19.404-79 ESPD. Pojasnilo, GOST 19.502-78 ESPD. Opis uporabe, GOST 19.503-79 ESPD. Vodnik sistemskega programerja, GOST 19.504-79 ESPD. Navodila za programerje, GOST 19.505-79 ESPD. Navodila za uporabo.

Obstaja tudi skupina standardov, ki opredeljujejo zahteve za zapis celotnega nabora programov in PD, ki so sestavljeni za prenos programske opreme. Ustvarjajo jedrnate računovodske listine in so lahko koristne za racionalizacijo celotnega upravljanja programov in PD (navsezadnje je pogosto treba le vzpostaviti osnovni red!). Obstajajo tudi standardi, ki določajo pravila za hrambo dokumentov v "gospodinjstvu" PS.

Poudariti moramo tudi

GOST 19.301-79 ESPD. Testni program in metodologija, ki se (v prilagojeni obliki) lahko uporabljata za izdelavo planskih dokumentov in izvajanje testnih del za oceno pripravljenosti in kakovosti RTP.

Za konec še zadnji standard glede na leto sprejetja.

GOST 19.701-90 ESPD. Sheme algoritmov, programov, podatkov in sistemov. Konvencionalne grafične oznake in pravila izvedbe.

Določa pravila za izvedbo diagramov, ki se uporabljajo za predstavitev različnih vrst problemov obdelave podatkov, in sredstva za njihovo reševanje in je popolnoma skladen s standardom ISO 5807:1985.

Poleg ESPD na meddržavni ravni veljata še dva standarda, ki sta povezana tudi z dokumentiranjem PS in sprejeta ne tako dolgo nazaj kot večina GOST ESPD.

GOST 19781-90 Programska oprema za sisteme za obdelavo informacij. Izrazi in definicije. Razvit za zamenjavo GOST 19.781-83 in GOST 19.004-80 ter določa izraze in definicije na področju programske opreme (programske opreme) sistemov za obdelavo podatkov (SOD), ki se uporablja v vseh vrstah dokumentacije in literature, ki je vključena v obseg standardizacijskega dela ali z uporabo rezultate tega dela.

GOST 28388-89 Sistemi za obdelavo informacij. Dokumenti na magnetnem nosilcu podatkov. Vrstni red izvedbe in ravnanja. Ne velja le za programsko opremo, temveč tudi za načrtovanje, tehnološko in drugo projektno dokumentacijo, izdelano na magnetnem mediju.

2.2. Standardi kompleksa GOST 34

GOST 34 je bil zasnovan v poznih 80-ih kot obsežen sklop medsebojno povezanih medsektorskih dokumentov. Motivi in posledični rezultati so opisani spodaj v "Lastnostih" GOST 34. Predmeti standardizacije so zvočniki različnih (katerih koli!) Tipov in vseh vrst njihovih komponent, ne le programske opreme in podatkovnih baz.

Kompleks je zasnovan za interakcijo med stranko in razvijalcem. Podobno kot pri ISO12207 je predvideno, da lahko stranka sama razvije zvočnike (če za to ustvari specializirano enoto). Vendar pa besedilo GOST 34 ni osredotočeno na tako jasen in v določenem smislu simetričen odraz dejanj obeh strani kot ISO12207. Ker GOST 34 posveča pozornost predvsem vsebini projektnih dokumentov, se porazdelitev dejanj med strankami običajno izvaja na podlagi te vsebine.

Od vseh obstoječih in neizvedenih skupin dokumentov se bomo opirali le na skupino 0 »Splošne določbe« in skupino 6 »Ustvarjanje, delovanje in razvoj AS«. Najbolj priljubljeni standardi se lahko štejejo za GOST 34.601-90 (Faze ustvarjanja AS), GOST 34.602-89 (TK za ustvarjanje AS) in smernice RD 50-34.698-90 (Zahteve za vsebino dokumentov). Standardi predvidevajo faze in faze dela za ustvarjanje AS, vendar ne določajo izrecno procesov od konca do konca.

Za splošni primer razvoja AS so stopnje in faze GOST 34 podane v tabeli:

1. FT – Oblikovanje zahtev za AS.	1.1. Pregled objekta in utemeljitev potrebe po izgradnji jedrske elektrarne; 1.2. Oblikovanje uporabniških zahtev za zvočnike; 1.3. Priprava poročila o opravljenem delu in vloge za razvoj AS (taktične in tehnične specifikacije);
2. RK – Razvoj koncepta AS.	2.1. Študija predmeta; 2.2. Izvajanje potrebnega raziskovalnega dela; 2.3. Razvoj možnosti za koncept zvočnikov, ki ustreza zahtevam uporabnikov 2.4. Sestava poročila o opravljenem delu
3. TK – Tehnična izdelava NEK.	3.1. Razvoj in odobritev tehničnih specifikacij za nalogo.
4. EP - Osnutek zasnove.	4.1. Razvoj idejnih projektnih rešitev za sistem in njegove dele; 4.2. Razvoj dokumentacije za AU in njegove dele.
5. TP – Tehnična zasnova.	5.1. Razvoj oblikovalskih rešitev za sistem in njegove dele; 5.2. Izdelava dokumentacije za NEK in njene dele; 5.3. Razvoj in izvedba dokumentacije za dobavo proizvodov za dokončanje NEK in/ali tehničnih zahtev (tehničnih specifikacij) za njihov razvoj; 5.4. Izdelava projektnih nalog v sosednjih delih projekta avtomatizacije.
6. RD – Delovna dokumentacija.	6.1. Razvoj delovne dokumentacije za sistem in njegove dele; 6.2. Razvoj ali prilagoditev programov.
7. VD – Začetek obratovanja.	7.1. Priprava avtomatiziranega objekta za zagon naprave; 7.2. Usposabljanje osebja; 7.3. Komplet zvočnikov z dobavljenimi izdelki (programska in strojna oprema, programski in strojni sistemi, informacijski izdelki); 7.4. Gradbena in inštalacijska dela; 7.5. Zagonska dela; 7.6. Izvajanje predhodnih testov; 7.7. Izvajanje poskusnega obratovanja; 7.8. Izvajanje sprejemnih testov.
8. Sp – AC podpora.	8.1. Izvajanje del v skladu z garancijskimi obveznostmi; 8.2. Pogarancijski servis.

Opisana je vsebina dokumentov, razvitih na vsaki stopnji. To določa potencial za identifikacijo na vsebinski ravni dela od konca do konca, ki se izvaja vzporedno ali zaporedno (to je v bistvu procesov) in njihovih sestavnih nalog. To tehniko je mogoče uporabiti pri izdelavi profila standardov življenjskega cikla projekta, vključno z dogovorjenimi podnabori standardov GOST 34 in ISO12207.

Glavni motiv: rešiti problem "babilonskega stolpa".

V 80. letih je prišlo do situacije, v kateri so različne industrije in področja dejavnosti uporabljale slabo usklajeno ali neusklajeno NTD - "normativno in tehnično dokumentacijo". To je oteževalo integracijo sistemov in zagotavljanje njihovega učinkovitega skupnega delovanja. Obstajali so različni kompleksi in sistemi standardov, ki so določali zahteve za različne vrste AS.

Praksa uporabe standardov je pokazala, da v bistvu (vendar ne v skladu s strogimi definicijami) uporabljajo enoten sistem konceptov, obstaja veliko skupnih predmetov standardizacije, vendar zahteve standardov niso skladne med seboj, obstajajo razlike v sestava in vsebina dela, razlike v poimenovanju, sestavi, vsebini in izvedbi dokumentov ipd.

Seveda je to stanje deloma odražalo naravno raznolikost pogojev za razvoj AS, ciljev razvijalcev ter uporabljenih pristopov in tehnik.

Pod temi pogoji je bilo mogoče analizirati takšno raznolikost in nato nadaljevati na primer na enega od dveh v veliki meri nasprotnih načinov:

Razviti en posplošen konceptualni in terminološki sistem, splošno razvojno shemo, skupen sklop dokumentov z njihovo vsebino in jih opredeliti kot obvezne za vse AS;
Določite tudi en splošen konceptualni in terminološki sistem, posplošen nabor sistemskih zahtev, nabor kriterijev kakovosti, vendar zagotovite največjo svobodo pri izbiri razvojne sheme, sestave dokumentov in drugih vidikov, naložite le minimalne obvezne zahteve, ki bi omogočile :
- določite raven kakovosti rezultata;
- izbrati tiste specifične metode (s svojimi modeli življenjskega cikla, naborom dokumentov itd.), ki so najbolj primerne za razvojne pogoje in ustrezajo uporabljenim informacijskim tehnologijam;
- tako delujejo z minimalnimi omejitvami glede učinkovitih dejanj oblikovalca zvočnikov.

Razvijalci nabora standardov 34 so izbrali metodo, ki je blizu prvemu od zgoraj navedenih, to je, da so ubrali pot bližje shemam posebnih metod kot standardom, kot je ISO12207. Vendar pa standardi zaradi splošne konceptualne podlage ostajajo uporabni v zelo širokem razponu primerov.

Stopnja prilagodljivosti je formalno določena z zmogljivostmi:

izpustite fazo predhodnega projektiranja in združite fazi "tehnična zasnova" in "podrobna dokumentacija";
izpustite korake, združite in izpustite večino dokumentov in njihovih razdelkov;
vnesite dodatne dokumente, razdelke dokumentov in dela;
dinamično ustvarjanje t.i. ChTZ - zasebne tehnične specifikacije - je precej prilagodljiv za oblikovanje življenjskega cikla jedrske elektrarne; Praviloma se ta tehnika uporablja na ravni velikih enot (podsistemov, kompleksov), zaradi katerih se zdi upravičeno ustvariti CTZ, vendar ni pomembnih razlogov za močno omejitev tega načina upravljanja življenjskega cikla.

Faze in mejniki, ki jih izvajajo organizacije, ki sodelujejo pri gradnji jedrskih elektrarn, so določeni v pogodbah in tehničnih specifikacijah, kar je blizu pristopu ISO.

Vsekakor je koristna uvedba enotne, dokaj kakovostno opredeljene terminologije, prisotnost dokaj razumne klasifikacije del, dokumentov, vrst podpor itd. GOST 34 prispeva k popolnejšemu in kakovostnejšemu povezovanju resnično različnih sistemov, kar je še posebej pomembno v razmerah, ko se razvijajo vse bolj zapleteni integrirani sistemi, na primer CAD-CAM, ki vključujejo sistem za vodenje procesov, nadzorni sistem, CAD oblikovalec, CAD tehnolog, ASNI in drugi sistemi.

Opredeljenih je več pomembnih določb, ki odražajo značilnosti AS kot predmeta standardizacije, na primer: »na splošno AS sestavljajo programsko-strojni (PTK), programsko-metodološki (PMK) kompleksi in posamezne komponente organizacijskih, tehnična, programska in informacijska podpora.«

Ločitev konceptov PTC in AS je zasnovala načelo, po katerem AS ni »IS z bazo podatkov«, temveč:

"organizacijski in tehnični sistem, ki zagotavlja razvoj rešitev, ki temeljijo na avtomatizaciji informacijskih procesov na različnih področjih dejavnosti (upravljanje, projektiranje, proizvodnja itd.) Ali njihovih kombinacij" (v skladu z RD 50-680-88), ki je še posebej aktualna v poslovnih vidikih -reinženiring;
"Sistem, ki ga sestavljajo osebje in nabor orodij za avtomatizacijo za njihove dejavnosti, ki uporabljajo informacijsko tehnologijo za izvajanje uveljavljenih funkcij" (v skladu z GOST 34.003-90).

Te definicije kažejo, da je AS predvsem osebje, ki sprejema odločitve in izvaja druge upravljavske ukrepe, podprto z organizacijskimi in tehničnimi sredstvi.

Stopnja obveznosti:

Prejšnje polne obvezne zahteve ni; materiali GOST34 so v bistvu postali metodološka podpora, pogosteje za stranke, ki imajo v standardu niz zahtev glede vsebine tehničnih specifikacij in testiranja AS. Hkrati se lahko uporabnost GOST34 večkrat poveča, če se uporabljajo bolj prožno pri oblikovanju profila življenjskega cikla AS.

Ključni dokument za sodelovanje med stranema je tehnična specifikacija za izgradnjo jedrske elektrarne. Tehnična specifikacija je glavni izvorni dokument za izdelavo AS in njegovo sprejetje, tehnična specifikacija določa najpomembnejše točke interakcije med naročnikom in razvijalcem. V tem primeru tehnične specifikacije razvije organizacija razvijalca (v skladu z GOST 34.602-89), vendar stranka uradno izda tehnične specifikacije razvijalcu (v skladu z RD 50-680-88).

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

Ruska federacija ima številne standarde za dokumentiranje programske opreme, razvite na podlagi neposredne uporabe mednarodnih standardov ISO. to? najnovejše standarde v času sprejetja. Nekatera so neposredno naslovljena na vodje projektov ali direktorje informacijskih služb. Hkrati pa so neprimerno malo znani med strokovnjaki. Tukaj je njihov nastop.

GOST R ISO/IEC 9294-93 Informacijska tehnologija. Priročnik za upravljanje dokumentacije programske opreme. Standard je v celoti skladen z mednarodnim standardom ISO/IEC TO 9294:1990 in vzpostavlja priporočila za učinkovito upravljanje programske dokumentacije za vodje, odgovorne za njeno ustvarjanje. Namen standarda je pomagati pri definiranju strategije za dokumentiranje programske opreme; izbira standardov dokumentacije; izbira dokumentacijskih postopkov; določitev potrebnih sredstev; izdelava dokumentacijskih načrtov.

GOST R ISO/IEC 9126-93 Informacijska tehnologija. Ocenjevanje programskih izdelkov. Značilnosti kakovosti in smernice za njihovo uporabo. Standard je v celoti skladen z mednarodnim standardom ISO/IEC 9126:1991. V svojem kontekstu je značilnost kakovosti razumljena kot "niz lastnosti (atributov) programskega izdelka, s katerimi se opisuje in ocenjuje njegova kakovost." Standard opredeljuje šest celovitih karakteristik, ki z minimalnim podvajanjem opisujejo kakovost programske opreme (programske opreme, programskih izdelkov): funkcionalnost; zanesljivost; praktičnost; učinkovitost; spremstvo; mobilnost. Te značilnosti tvorijo osnovo za nadaljnja pojasnila in opis kakovosti programske opreme.

GOST R ISO 9127-94 Sistemi za obdelavo informacij. Uporabniška dokumentacija in informacije o embalaži za potrošniške programske pakete. Standard je v celoti skladen z mednarodnim standardom ISO 9127:1989. Za namene tega standarda je potrošniški programski paket (CSP) opredeljen kot »programski izdelki, zasnovani in trženi za izvajanje posebnih funkcij; program in z njim povezana dokumentacija, pakirana za prodajo kot ena enota.« Uporabniška dokumentacija se nanaša na dokumentacijo, ki končnemu uporabniku nudi informacije o namestitvi in delovanju programske opreme. Informacije na embalaži se nanašajo na informacije, ki so prikazane na zunanji embalaži PP. Njegov namen je potencialnim kupcem zagotoviti osnovne informacije o programski opremi.

GOST R ISO/IEC 8631-94 Informacijska tehnologija. Programski konstrukti in simboli za njihovo predstavitev. Opisuje predstavitev postopkovnih algoritmov.

2.4. Mednarodni standard ISO/IEC 12207: 1995-08-01

Prvo izdajo ISO12207 je leta 1995 pripravil skupni tehnični odbor ISO/IEC JTC1 “Informacijska tehnologija, pododbor SC7, programsko inženirstvo.”

Po definiciji je ISO12207 osnovni standard za procese življenjskega cikla programske opreme, osredotočen na različne (poljubne!) tipe programske opreme in tipe AS projektov, katerih del je programska oprema. Standard opredeljuje strategijo in splošni red pri ustvarjanju in delovanju programske opreme, zajema življenjski cikel programske opreme od konceptualizacije idej do zaključka življenjskega cikla.

Zelo pomembne OPOMBE K STANDARDU:

Procesi, uporabljeni v življenjskem ciklu programske opreme, morajo biti združljivi s procesi, uporabljenimi v življenjskem ciklu AS. (Zato je smotrnost skupne uporabe AS in programskih standardov jasna.)
Dodatek edinstvenih ali posebnih procesov, dejavnosti in nalog mora biti določen v pogodbi med strankama. Pogodbo razumemo v širokem smislu: od pravno formalizirane pogodbe do neformalnega dogovora lahko ena sama stranka opredeli dogovor kot nalogo, ki si jo zastavi sama.
Standard načeloma ne vsebuje posebnih načinov ukrepanja, še manj osnutkov rešitev ali dokumentacije. Opisuje arhitekturo procesov življenjskega cikla programske opreme, vendar ne določa podrobno, kako izvajati ali izvajati storitev in nalog, vključenih v procese, in ni namenjen predpisovanju imena, oblike ali natančne vsebine nastale dokumentacije. Tovrstne odločitve sprejema uporabnik standarda.

STANDARDNE DEFINICIJE:

Sistem je združenje enega ali več procesov, strojne opreme, programske opreme, opreme in ljudi, ki omogoča zadovoljevanje določenih potreb ali ciljev.
Model življenjskega cikla– strukturo, ki vsebuje procese, dejanja in naloge, ki se izvajajo med razvojem, delovanjem in vzdrževanjem programskega izdelka skozi celotno življenjsko dobo sistema, od določanja zahtev do konca njegove uporabe.
Številni procesi in opravila so zasnovani tako, da jih je mogoče prilagajati v skladu s programskimi projekti. Proces prilagajanja je proces izločanja procesov, aktivnosti in nalog, ki niso uporabni za določen projekt. Stopnja prilagodljivosti: največja
Kvalificirana zahteva– nabor kriterijev ali pogojev (zahtev za kvalifikacijo), ki morajo biti izpolnjeni, da se izdelek programske opreme kvalificira kot skladen (izpolnjuje pogoje) s svojimi specifikacijami in pripravljen za uporabo v ciljnem okolju.

Standard ne predpisuje posebnega modela življenjskega cikla ali metode razvoja programske opreme, ampak določa, da so uporabniki standarda odgovorni za izbiro modela življenjskega cikla za projekt programske opreme, za prilagajanje procesov in nalog standarda temu modelu. , za izbiro in uporabo metod razvoja programske opreme ter za izvajanje dejanj in nalog, primernih za projekt programske opreme.

Standard ISO12207 je enako osredotočen na organizacijo delovanja obeh strani: dobavitelja (razvijalca) in kupca (uporabnika); se lahko uporablja enako, če sta obe strani iz iste organizacije.

Vsak proces življenjskega cikla je razdeljen na nabor dejanj, vsako dejanje na nabor nalog. Zelo pomembna razlika med ISO: vsak proces, dejanje ali opravilo po potrebi sproži in izvede drug proces in ni vnaprej določenih zaporedij (seveda ob ohranjanju logike povezav glede na začetne informacije opravil itd. ).

Standard ISO12207 opisuje:

5 glavnih procesov življenjskega cikla programske opreme:
- Postopek pridobivanja. Določa dejanja nakupovalnega podjetja, ki kupi AS, programski izdelek ali programsko storitev.
- Postopek dostave. Določa dejanja dobavitelja, ki kupcu dobavlja sistem, programski izdelek ali programsko storitev.
- Razvojni proces. Določa dejanja razvojnega podjetja, ki razvija princip gradnje programskega izdelka in programskega izdelka.
- Proces delovanja. Določa dejanja operaterske družbe, ki zagotavlja vzdrževanje sistema (in ne samo programske opreme) med njegovim delovanjem v interesu uporabnikov. V nasprotju z dejanji, ki jih določi razvijalec v navodilih za uporabo (ta aktivnost razvijalca je predvidena v vseh treh obravnavanih standardih), so določena dejanja operaterja za posvetovanje z uporabniki, prejemanje povratnih informacij itd. sam načrtuje in prevzema ustrezne odgovornosti.
- Postopek vzdrževanja. Določa dejanja vzdrževalcev, ki zagotavljajo vzdrževanje programskega izdelka, to je upravljanje modifikacij programskega izdelka, podpora njegovemu trenutnemu stanju in funkcionalni ustreznosti, vključno z namestitvijo in odstranitvijo programskega izdelka v računalniškem sistemu.
8 pomožnih procesov, ki podpirajo implementacijo drugega procesa, ki je sestavni del celotnega življenjskega cikla programskega izdelka in zagotavlja ustrezno kakovost programskega projekta:
- rešitev problema;
- dokumentacija;
- upravljanje konfiguracije;
- zagotavljanje kakovosti, ki uporablja rezultate preostalih procesov skupine za zagotavljanje kakovosti, ki vključuje:
  - Postopek preverjanja;
  - Postopek certificiranja;
  - Participativni proces ocenjevanja;
  - Postopek revizije.
4 organizacijski procesi:
- Proces upravljanja;
- Postopek ustvarjanja infrastrukture;
- Postopek izboljšanja;
- Učni proces.

Spremlja jih poseben proces prilagajanja, ki opredeljuje glavne ukrepe, potrebne za prilagoditev standarda pogojem določenega projekta.

Pri tem proces izboljšave ne pomeni izboljšave AS ali programske opreme, ampak izboljšanje procesov pridobivanja, razvoja, zagotavljanja kakovosti itd., ki se dejansko izvajajo v organizaciji.

Zagotovljene niso stopnje, faze, stopnje, kar daje stopnjo prilagodljivosti, opisano spodaj.

»Dinamična« narava standarda je določena z načinom zaporedja procesov in opravil, v katerem en proces po potrebi pokliče drugega ali njegov del.

izvedba postopka pridobivanja v smislu analiziranja in beleženja zahtev za sistem ali programsko opremo lahko sproži izvajanje ustreznih nalog razvojnega procesa;
Dobavitelj mora v procesu dostave voditi podizvajalce v skladu s postopkom pridobivanja ter izvajati preverjanje in kvalifikacije glede na ustrezne procese;
Vzdrževanje lahko zahteva razvoj sistema in programske opreme, ki se izvaja v skladu z razvojnim procesom.

Ta narava omogoča implementacijo katerega koli modela življenjskega cikla.

Pri izvajanju analize programskih zahtev obstaja 11 razredov karakteristik kakovosti, ki se kasneje uporabljajo pri zagotavljanju kakovosti.

V tem primeru mora razvijalec določiti in dokumentirati kot zahteve za programsko opremo:

Funkcionalne in omogočilne specifikacije, vključno z izvajanjem, fizičnimi značilnostmi in pogoji operacijskega okolja, v katerih se mora programska postavka izvajati;
Zunanje povezave (vmesniki) s programsko enoto;
Zahteve glede kvalifikacij;
Specifikacije zanesljivosti, vključno s specifikacijami v zvezi z metodami delovanja in vzdrževanja, izpostavljenostjo okolja in verjetnostjo telesnih poškodb;
Varnostne specifikacije
Specifikacije človeških dejavnikov za inženirsko psihologijo (ergonomija), vključno s tistimi v zvezi z ročnim nadzorom, interakcijo med človekom in opremo, omejitvami osebja in področji, ki zahtevajo osredotočeno človeško pozornost in so občutljiva na človeške napake in učenje;
Določitev zahtev glede podatkov in baze podatkov;
Zahteve za namestitev in sprejem dobavljenega programskega izdelka na mestih delovanja in vzdrževanja (delovanja);
Uporabniška dokumentacija;
Uporabniško delo in zahteve glede uspešnosti;
Zahteve uporabniških storitev.

(Zanimivo in pomembno je, da se te in podobne značilnosti dobro ujemajo z značilnostmi NPP, ki jih GOST 34 predvideva za vrste sistemske podpore.)

Standard vsebuje zelo malo opisov, ki so namenjeni načrtovanju baze podatkov. To se lahko šteje za upravičeno, saj različni sistemi in različni paketi aplikacijske programske opreme ne morejo le uporabljati zelo specifičnih vrst baz podatkov, ampak tudi ne

Torej ima ISO12207 nabor procesov, dejavnosti in nalog, ki pokrivajo najširši možni spekter možnih situacij z največjo prilagodljivostjo.

Prikazuje primer, kako je treba zgraditi dobro organiziran standard, ki vsebuje najmanj omejitev (načelo "ni dva enaka projekta"). Hkrati je priporočljivo vključiti podrobne definicije procesov, oblik dokumentov itd. v različne funkcionalne standarde, oddelčne regulativne dokumente ali lastniške metode, ki se lahko ali ne smejo uporabiti v določenem projektu.

Iz tega razloga je koristno obravnavati ISO12207 kot osrednji standard, katerega določbe se vzamejo kot začetni "jedrni" nabor določb v procesu izdelave profila standardov življenjskega cikla za določen projekt. To »jedro« lahko definira programsko opremo in model življenjskega cikla AS, koncept zagotavljanja kakovosti in model vodenja projekta.

Praktiki uporabljajo drug način: sami prevajajo in uporabljajo v svojih projektih sodobne standarde za organizacijo življenjskega cikla programov in njihove dokumentacije. Toda ta pot ima vsaj to pomanjkljivost, da se bodo različni prevodi in prilagoditve standardov, ki jih naredijo različni razvijalci in kupci, razlikovali v številnih podrobnostih. Te razlike neizogibno zadevajo ne samo imena, temveč tudi njihove vsebinske opredelitve, ki so uvedene in uporabljene v standardih. Tako je na tej poti neizogibno nenehno nastajanje zmede, kar je neposredno v nasprotju s cilji ne le standardov, ampak tudi vseh pristojnih metodoloških dokumentov.

Trenutno je All-Russian Research Institute of Standards pripravil predloge za izboljšanje in razvoj nabora standardov za dokumentiranje programske opreme.

Na vrh

GOST 19.105-78* (Splošne zahteve za programske dokumente)

Iz tega GOST-a dobimosplošne zahteve za pripravo programskih dokumentov.Spodaj so najpomembnejši razdelki.

Ta standard določa splošne zahteve za izvajanje programskih dokumentov za računalnike, komplekse in sisteme, ne glede na njihov namen in obseg uporabe ter jih določajo standardi Enotnega sistema programske dokumentacije (USPD) za kateri koli način izvajanja dokumentov na različnih nosilci podatkov.
Programski dokument je sestavljen iz naslednjih konvencionalnih delov:

naslov;
informativni;
osnovni;
registracija sprememb.

Naslovnico sestavljata odobritveni list in naslovna stran. Pravila za sestavo homologacijskega lista in naslovne strani so določena v skladu z GOST 19.104-78.
Informacijski del mora biti sestavljen iz povzetka in vsebine.

Potrebo po vključitvi informacijskega dela v različne vrste programskih dokumentov določajo ustrezni standardi ESPD za te dokumente.
Anotacija vsebuje informacije o namenu dokumenta in kratek povzetek njegovega glavnega dela.
Vsebina vključuje seznam zapisov o strukturnih elementih glavnega dela dokumenta, od katerih vsak vključuje:

oznaka strukturnega elementa (številka odseka, pododdelka itd.);
ime strukturnega elementa;
naslov strukturnega elementa na pomnilniškem mediju (na primer številka strani, številka datoteke itd.).

Sestavo in strukturo glavnega dela programskega dokumenta določajo standardi ESPD za ustrezne dokumente.
Spremenite del za beleženje(mora biti prisoten v vsakem programskem dokumentu)

Vsaka sprememba programskega dokumenta se zabeleži v tem delu v skladu z zahtevami GOST 19.603-78.

Na vrh
==================================
GOST 19.106-78* (Splošne zahteve za programske dokumente, izdelane v tiskani obliki
pot)
Iz tega GOST-a dobimo splošna pravila za način tiskanjaprogramske dokumente. Spodaj so najpomembnejši razdelki.

Ta standard določa pravila za izvajanje programskih dokumentov za računalnike, komplekse in sisteme, ne glede na njihov namen in obseg uporabe ter jih določajo standardi Enotnega sistema programske dokumentacije (USPD) za tiskani način izvedbe.
Standard ne velja za programski dokument »Programsko besedilo«.
Sestava in struktura programskega dokumenta sta določena v skladu z GOST 19.105-78.
Programski dokument se izvedena eni strani lista v dveh presledkih; dovoljeno v intervalih enega ali enega in pol.
Programske dokumente pripravljajo:

na listih formata A4 (GOST 2.301-68) - pri pripravi dokumenta s tipkanjem ali rokopisom (obrazec 1). Dovoljeno je risanje na A3 liste.

Gradiva programskega dokumenta so urejena v naslednjem zaporedju:

naslovni del:

odobritveni list (ni vključen v skupno število listov dokumenta);
naslovna stran (prva stran dokumenta);

informativni del:

opomba;
kazalo;

glavni del:

besedilo dokumenta (s slikami, tabelami itd.);
aplikacije;
seznam pojmov, seznam okrajšav, seznam slik, seznam tabel, predmetno kazalo, seznam referenčnih dokumentov;

del beleženja sprememb:

sprememba vpisnega lista.

Povzetek je umeščen na ločeno (oštevilčeno) stran z naslovom »POVZETEK« in ni oštevilčen kot razdelek.

Pripis navaja izdajo programa ter na kratko oriše namen in vsebino dokumenta. Če je dokument sestavljen iz več delov, je v opombi navedeno skupno število delov.

Vsebina dokumenta je na ločeni (oštevilčeni) strani (straneh) po opombi, opremljena z naslovom "VSEBINA", ki ni oštevilčena kot razdelek in je vključena v skupno število strani dokumenta.
Naslovi razdelkov so napisani z velikimi tiskanimi črkami in postavljeni simetrično glede na desno in levo obrobo besedila.
Naslovi pododdelkov se pišejo iz odstavka z malimi tiskanimi črkami (razen prve velike).
Deljenje besed v naslovih ni dovoljeno. Na koncu naslova ni pike.

Razdalja med naslovom in naslednjim besedilom ter med naslovi razdelkov in pododdelkov mora biti enaka:

pri izdelavi dokumenta s tipkanjem - dva intervala.

Za razdelke in pododdelke, katerih besedilo je napisano na isti strani z besedilom prejšnjega razdelka, mora biti razdalja med zadnjo vrstico besedila in naslednjim naslovom enaka:

pri izvajanju dokumenta s tipkano metodo - trije tipkani intervali.

Razdelki, pododdelki, odstavki in pododstavki morajo biti oštevilčeni z arabskimi številkami s piko.
Znotraj oddelka morajo biti vsi pododdelki, odstavki in pododstavki, vključeni v ta razdelek, neprekinjeno oštevilčeni.
Oštevilčenje pododdelkov vključuje številko oddelka in zaporedno številko pododdelka, vključenega v ta razdelek, ločeno s piko (2.1; 3.1 itd.).
Če so razdelki in pododdelki, se številki pododdelka za piko doda še zaporedna številka poglavja in pododdelka (3.1.1, 3.1.1.1 itd.).

Primer strukture besedila programskega dokumenta in oštevilčenja njegovih razdelkov, pododdelkov, odstavkov in pododstavkov.

Besedilo dokumenta mora biti kratko, jasno in izključuje možnost napačne interpretacije.
Izrazi in definicije morajo biti enotni in v skladu z uveljavljenimi standardi, če jih ni, pa splošno sprejeti v znanstveni in strokovni literaturi ter navedeni v seznamu izrazov.
Potrebna pojasnila k besedilu dokumenta so lahko navedena v opombah.

Opomba je označena s številko z oklepajem na ravni zgornje robne vrstice pisave, na primer: "tiskalna naprava 2) ..." ali "papir 5)".

Če se opomba nanaša na posamezno besedo, se znak za opombo postavi neposredno ob to besedo, če pa se nanaša na stavek kot celoto, pa na koncu stavka. Besedilo opombe je na koncu strani in ločeno od glavnega besedila s 3 cm dolgo črto na levi strani strani.

Ilustracije, če jih je v posameznem dokumentu več, so oštevilčene z arabskimi številkami po celotnem dokumentu.
Formule v dokumentu, če jih je več, so oštevilčene z arabskimi številkami, številka je postavljena na desni strani strani, v oklepaju na ravni formule.
Pomen simbolov in numeričnih koeficientov, vključenih v formulo, je treba navesti neposredno pod formulo. Pomen vsakega znaka je natisnjen v novi vrstici v vrstnem redu, v katerem je podan v formuli. Prva vrstica prepisa se mora začeti z besedo »kje«, brez dvopičja za njo.
V programskih dokumentih so dovoljena sklicevanja na standarde (razen standardov podjetij), tehnične specifikacije in druge dokumente (na primer dokumente državnih nadzornih organov, pravila in predpise Državnega odbora za gradnjo ZSSR). Pri sklicevanju na standarde in tehnične specifikacije je navedena njihova oznaka.
Sklicuje se na dokument kot celoto ali na njegove razdelke (z navedbo oznake in imena dokumenta, številke in imena razdelka ali priloge). Pri ponavljanju sklicevanj na razdelek ali aplikacijo je navedena samo številka.
Opombe k besedilu in tabelam navajajo le referenčne in pojasnjevalne podatke.

Ena opomba ni oštevilčena. Za besedo »Opomba« postavite piko.
Več opomb je treba oštevilčiti z arabskimi številkami s piko. Za besedo »Opomba« postavite dvopičje.

Okrajšave besed v besedilu in napisi pod ilustracijami niso dovoljeni.
Ilustrirano gradivo, tabele ali spremno besedilo so lahko predstavljeni v obliki prilog.
Vsaka prijava se mora začeti na novi strani z napisom »PRILOGA« v zgornjem desnem kotu in imeti tematski naslov, ki je izpisan simetrično na besedilo z velikimi tiskanimi črkami.(na koncu za izdelavo projekta potrebujemo samo registracijski list sprememb).
- Ta standard določa pravila za spreminjanje programskih dokumentov, ki jih določajo standardi enotnega sistema programske dokumentacije (USPD) in so natisnjeni.
Zaradi velike količine informacij v tem GOST-u in zaradi prihranka prostora na tej strani priporočam, da si ga ogledate sami GOST 19.604-78* . Primer pripravljenega dizajna"spremeni registrski list"Ogledate si ga lahko v katerem koli programskem dokumentu v razdelku PRENOS

Na vrh
==================================

Računalniški programi so sestavljeni v skladu z zahtevami Enotnega sistema programske dokumentacije (USPD). ESPD je niz GOST, ki določa pravila za oblikovanje, vsebino in strukturo programskih dokumentov.
To navodilo vsebuje izvlečke iz ESPD. Popolne informacije je mogoče dobiti neposredno iz GOST.

Kratek algoritem načrtovanja programa

Na kratko so prikazani algoritem načrtovanja programa in vrste programskih dokumentov. Postopek registracije je podrobneje opisan spodaj.

Priprava programskega dokumenta

Programski dokument - dokument, ki vsebuje informacije, potrebne za razvoj, izdelavo, vzdrževanje in delovanje programov.

Vsak posamezen programski dokument je sestavljen v skladu z (skupnimi vsem dokumentom ESPD) zahtevami GOST 19.101-77, GOST 19.103-77, GOST 19.104-78, GOST 19.105-78, GOST 19.106-78, GOST 19.604-78 ( podrobnejši opis teh GOST sledi spodaj) in GOST za določen programski dokument.

Splošne zahteve za programske dokumente. GOST 19.105 - 78

Zahteve za tiskane programske dokumente. GOST 19.106 - 78

GOST 19.106-78 določa pravila za izvedbo programskih dokumentov za tiskano metodo izvedbe.

Pomembno je omeniti, da ta GOST ne velja za programski dokument "Programsko besedilo".

Gradivo programskega dokumenta mora biti v naslednjem zaporedju:

Naslovni del:
- odobritveni list (ni vključen v skupno število listov dokumenta);
- naslovna stran (prva stran dokumenta);
Informacijski del:
- opomba;
- kazalo;
Glavni del:
- besedilo dokumenta (s slikami, tabelami itd.);
- aplikacije;
- seznam pojmov, seznam okrajšav, seznam slik, seznam tabel, predmetno kazalo, seznam referenčnih dokumentov;
- del beleženja sprememb:
- sprememba vpisnega lista.

Pripis navaja izdajo programa ter na kratko oriše namen in vsebino dokumenta. Če je dokument sestavljen iz več delov, je v opombi navedeno skupno število delov. Vsebina dokumenta je na ločeni (oštevilčeni) strani (straneh) po opombi, opremljena z naslovom "VSEBINA", ki ni oštevilčena kot razdelek in je vključena v skupno število strani dokumenta.

Oblikovanje besedila:

Programski dokument se izvaja na eni strani lista v dveh intervalih; dovoljeno v intervalih enega ali enega in pol.
Povzetek je umeščen na ločeno (oštevilčeno) stran z naslovom »POVZETEK« in ni oštevilčen kot razdelek.
Naslovi razdelkov so napisani z velikimi tiskanimi črkami in postavljeni simetrično glede na desno in levo obrobo besedila.
Naslovi pododdelkov se pišejo iz odstavka z malimi tiskanimi črkami (razen prve velike).
Deljenje besed v naslovih ni dovoljeno. Na koncu naslova ni pike.
Razdalja med naslovom in naslednjim besedilom ter med naslovi razdelkov in pododdelkov mora biti enaka:
- pri izdelavi dokumenta s tipkanjem - dva intervala.
Za razdelke in pododdelke, katerih besedilo je napisano na isti strani z besedilom prejšnjega razdelka, mora biti razdalja med zadnjo vrstico besedila in naslednjim naslovom enaka:
- pri izvajanju dokumenta s tipkano metodo - trije tipkani intervali.
Razdelki, pododdelki, odstavki in pododstavki morajo biti oštevilčeni z arabskimi številkami s piko.
Znotraj oddelka morajo biti vsi pododdelki, odstavki in pododstavki, vključeni v ta razdelek, neprekinjeno oštevilčeni.
Oštevilčenje pododdelkov vključuje številko oddelka in zaporedno številko pododdelka, vključenega v ta razdelek, ločeno s piko (2.1; 3.1 itd.).
Če so razdelki in pododdelki, se številki pododdelka za piko doda še zaporedna številka poglavja in pododdelka (3.1.1, 3.1.1.1 itd.).
Besedilo dokumenta mora biti kratko, jasno in izključuje možnost napačne interpretacije.
Izrazi in definicije morajo biti enotni in v skladu z uveljavljenimi standardi, če jih ni, pa splošno sprejeti v znanstveni in strokovni literaturi ter navedeni v seznamu izrazov.
Potrebna pojasnila k besedilu dokumenta so lahko navedena v opombah.
Opomba je označena s številko z oklepajem na ravni zgornjega roba pisave, na primer: »tiskalna naprava2)...« ali »papir5)«.
Če se opomba nanaša na posamezno besedo, se znak za opombo postavi neposredno ob to besedo, če pa se nanaša na stavek kot celoto, pa na koncu stavka. Besedilo opombe je na koncu strani in ločeno od glavnega besedila s 3 cm dolgo črto na levi strani strani.
Ilustracije, če jih je v posameznem dokumentu več, so oštevilčene z arabskimi številkami po celotnem dokumentu.
Formule v dokumentu, če jih je več, so oštevilčene z arabskimi številkami, številka je postavljena na desni strani strani, v oklepaju na ravni formule.
Pomen simbolov in numeričnih koeficientov, vključenih v formulo, je treba navesti neposredno pod formulo. Pomen vsakega znaka je natisnjen v novi vrstici v vrstnem redu, v katerem je podan v formuli. Prva vrstica prepisa se mora začeti z besedo »kje«, brez dvopičja za njo.
V programskih dokumentih so dovoljena sklicevanja na standarde (razen standardov podjetij), tehnične specifikacije in druge dokumente (na primer dokumente državnih nadzornih organov, pravila in predpise Državnega odbora za gradnjo ZSSR). Pri sklicevanju na standarde in tehnične specifikacije je navedena njihova oznaka.
Sklicuje se na dokument kot celoto ali na njegove razdelke (z navedbo oznake in imena dokumenta, številke in imena razdelka ali priloge). Pri ponavljanju sklicevanj na razdelek ali aplikacijo je navedena samo številka.
Opombe k besedilu in tabelam navajajo le referenčne in pojasnjevalne podatke.
Ena opomba ni oštevilčena. Za besedo »Opomba« postavite piko.
Več opomb je treba oštevilčiti z arabskimi številkami s piko. Za besedo »Opomba« postavite dvopičje.
Okrajšave besed v besedilu in napisi pod ilustracijami niso dovoljeni.
Ilustrirano gradivo, tabele ali spremno besedilo so lahko predstavljeni v obliki prilog.
Vsaka prijava se mora začeti na novi strani z napisom »PRILOGA« v zgornjem desnem kotu in imeti tematski naslov, ki je izpisan simetrično na besedilo z velikimi tiskanimi črkami.

GOST vsebuje vzorčni list, ki označuje polja, mesta za oštevilčenje strani in kodo.

V svojem poročilu se zanašam na:

članek "Standardizacija na področju programske opreme" V. V. Vasjutkovič - vodja oddelka in S. S. Samotokhin - višji raziskovalec. Vseruski raziskovalni inštitut za standarde državnega standarda Ruske federacije;
članek »Korelacija in uporaba standardov za organizacijo življenjskih ciklov sistemov« avtorja E.Z.Zinderja;
besedila GOST in drugih standardov.

1. Osnovna vprašanja pri razvoju programske opreme

Ko programer-razvijalec prejme programsko nalogo v takšni ali drugačni obliki, se on, vodja projekta in celotna projektna ekipa soočijo z naslednjimi vprašanji:

kaj bi bilo treba storiti poleg dejanskega programa?
kaj in kako je treba dokumentirati?
kaj sporočiti uporabnikom in kaj? spremstvo storitev?
kako voditi ta celoten proces?
Kaj mora vsebovati sama programska naloga?

Poleg omenjenih vprašanj obstajajo še drugi.

Ali so državni standardi za programsko dokumentacijo nekoč odgovorili na ta in številna druga vprašanja? niz standardov 19. serije GOST ESPD. Toda že takrat so imeli programerji veliko pritožb glede teh standardov. V dokumentaciji je bilo treba nekaj večkrat podvojiti (kot se je zdelo - neupravičeno), veliko pa ni bilo predvideno, kot je na primer odražanje posebnosti dokumentiranja programov, ki delajo z integrirano bazo podatkov.

Trenutno ostaja aktualno vprašanje sistema, ki ureja dokumentacijo programske opreme.

2. Splošne značilnosti stanja

Osnova domačega regulativnega okvira na področju programske dokumentacije je niz standardov Enotnega sistema programske dokumentacije (USPD). Glavni in največji del kompleksa ESPD je bil razvit v 70. in 80. letih. Zdaj je ta kompleks sistem meddržavnih standardov držav CIS (GOST), ki deluje na ozemlju Ruske federacije na podlagi meddržavnega sporazuma o standardizaciji.

Standardi ESPD pokrivajo predvsem tisti del dokumentacije, ki nastane v procesu razvoja programske opreme in so povezani v veliki večini z dokumentiranjem funkcionalnih značilnosti programske opreme. Treba je opozoriti, da so standardi ESPD (GOST 19) svetovalne narave. Velja pa to tudi za vse druge standarde s področja PS (GOST 34, mednarodni standard ISO/IEC itd.). Dejstvo je, da v skladu z zakonom Ruske federacije "O standardizaciji" ti standardi postanejo obvezni na pogodbeni podlagi - to je, ko so navedeni v pogodbi za razvoj (dobavo) programske opreme.

Če govorimo o stanju ESPD kot celote, lahko rečemo, da je večina standardov ESPD moralno zastarela.

Med glavnimi pomanjkljivostmi ESPD lahko pripišemo:

usmerjenost k enotnemu, »kaskadnemu« modelu življenjskega cikla (LC) transformatorske postaje;
pomanjkanje jasnih priporočil za dokumentiranje kakovostnih značilnosti programske opreme;
pomanjkanje sistemske povezave z drugimi obstoječimi domačimi sistemi standardov za življenjski cikel in dokumentacijo izdelkov na splošno, na primer ESKD;
nejasen pristop k dokumentiranju PS kot tržnega izdelka;
pomanjkanje priporočil za samodokumentiranje programske opreme, na primer v obliki menijev na zaslonu in sredstev za operativno pomoč uporabniku (»pomoč«);
pomanjkanje priporočil o sestavi, vsebini in oblikovanju perspektivnih dokumentov na PS, skladnih s priporočili mednarodnih in regionalnih standardov.

Torej potrebuje ESPD popolno revizijo na podlagi standarda ISO/IEC 12207-95 za procese življenjskega cikla programske opreme (o tem standardu bomo podrobneje razpravljali kasneje).

Povedati je treba, da poleg kompleksa ESPD uradni regulativni okvir Ruske federacije na področju dokumentiranja PS in sorodnih področij vključuje številne obetavne standarde (domače, meddržavne in mednarodne ravni).

Mednarodni standard ISO/IEC 12207: 1995-08-01 za organizacijo življenjskega cikla programskih izdelkov - na videz zelo nejasen, a precej nov in nekoliko "moden" standard.

Kompleksni standardi GOST 34 za ustvarjanje in razvoj avtomatiziranih sistemov (AS) - posplošeno, vendar zaznano kot zelo strogo v strukturi življenjskega cikla in projektne dokumentacije. Toda mnogi menijo, da so ti standardi birokratski do te mere škodljivi in konzervativni do te mere, da so zastareli. V kolikšni meri je to res in v kolikšni meri GOST 34 ostaja uporaben, je koristno razumeti.

V svojem članku E.Z. Zinder podrobno obravnava metodologijo Oracle CDM(Custom Development Method) za razvoj po meri izdelanih aplikativnih informacijskih sistemov - specifično gradivo, razčlenjeno do nivoja praznih dokumentov oblikovanja, namenjeno neposredni uporabi v AS projektih, ki temeljijo na orodjih Oracle.

2.1. Kratek uvod v standarde ESPD

Vendar pa je pred revizijo celotnega kompleksa veliko standardov ESPD mogoče koristno uporabiti v praksi dokumentiranja programske opreme. To stališče temelji na naslednjem:

Standardi ESPD uvajajo element naročanja v proces dokumentiranja programske opreme;
Sestava programskih dokumentov, ki jo predvidevajo standardi ESPD, sploh ni tako »toga«, kot morda nekateri mislijo: standardi dovoljujejo dodajanje dodatnih vrst naboru dokumentacije za programsko opremo.
Standardi ESPD omogočajo tudi prilagodljivo spreminjanje strukture in vsebine uveljavljenih tipov PD glede na zahteve kupcev in uporabnikov.

Hkrati lahko slog uporabe standardov ustreza sodobnemu splošnemu slogu prilagajanja standardov posebnostim projekta: naročnik in vodja projekta izbereta podmnožico standardov in PD, ki je primerna za projekt, dopolnita izbrani PD s potrebnimi razdelki in izključite nepotrebne, povežite ustvarjanje teh dokumentov s shemo življenjskega cikla, ki se uporablja v projektu.

Standardi ESPD (tako kot drugi GOST) so razdeljeni v skupine, navedene v tabeli:

Oznaka standarda ESPD temelji na klasifikacijskih merilih:

Oznaka standarda ESPD mora vsebovati:

številka 19 (dodeljena razredu standardov ESPD);
ena številka (za piko), ki označuje oznako klasifikacijske skupine standardov, navedenih v tabeli;
dvomestno število (za pomišljajem), ki označuje leto registracije standarda.

Seznam dokumentov ESPD

GOST 19.001-77 ESPD. Splošne določbe.
GOST 19.101-77 ESPD. Vrste programov in programski dokumenti.
GOST 19.102-77 ESPD. Razvojne faze.
GOST 19.103-77 ESPD. Označevanje programov in programskih dokumentov.
GOST 19.104-78 ESPD. Osnovni napisi.
GOST 19.105-78 ESPD. Splošne zahteve za programske dokumente.
GOST 19.106-78 ESPD. Zahteve za tiskane programske dokumente.
GOST 19.201-78 ESPD. Tehnična naloga. Zahteve glede vsebine in oblikovanja.
GOST 19.202-78 ESPD. Specifikacija. Zahteve glede vsebine in oblikovanja.
GOST 19.301-79 ESPD. Testni postopek in metodologija.
GOST 19.401-78 ESPD. Besedilo programa. Zahteve glede vsebine in oblikovanja.
GOST 19.402-78 ESPD. Opis programa.
GOST 19.404-79 ESPD. Pojasnilo. Zahteve glede vsebine in oblikovanja.
GOST 19.501-78 ESPD. Oblika. Zahteve glede vsebine in oblikovanja.
GOST 19.502-78 ESPD. Opis aplikacije. Zahteve glede vsebine in oblikovanja.
GOST 19.503-79 ESPD. Priročnik za sistemskega programerja. Zahteve glede vsebine in oblikovanja.
GOST 19.504-79 ESPD. Programerski vodnik.
GOST 19.505-79 ESPD. Navodila za uporabo.
GOST 19.506-79 ESPD. Opis jezika.
GOST 19.508-79 ESPD. Priročnik za vzdrževanje. Zahteve glede vsebine in oblikovanja.
GOST 19.604-78 ESPD. Pravila za spreminjanje programskih dokumentov, ki se izvajajo v tisku.
GOST 19.701-90 ESPD. Sheme algoritmov, programov, podatkov in sistemov. Dogovori in pravila izvajanja.
GOST 19.781-90. Programska oprema za sisteme za obdelavo informacij.

Izrazi in definicije

Od vseh standardov ESPD se bomo osredotočili le na tiste, ki jih je v praksi mogoče pogosteje uporabljati.

Najprej bomo navedli standard, ki ga lahko uporabimo pri ustvarjanju programskih nalog.

GOST (ST SEV) 19.201-78 (1626-79). ESPD. Tehnična naloga. Zahteve glede vsebine in oblikovanja. (Ponovno izdano novembra 1987 z revizijo 1).

Tehnična specifikacija (TOR) vsebuje nabor zahtev za programsko opremo in se lahko uporablja kot merilo za preverjanje in sprejemanje razvitega programa. Zato je tehnična specifikacija, ki je v celoti sestavljena (ob upoštevanju možnosti uvedbe dodatnih razdelkov) in sprejeta s strani naročnika in razvijalca, eden temeljnih dokumentov projekta PS.

Projektna naloga mora vsebovati naslednje razdelke:

uvod;
razlogi za razvoj;
namen razvoja;
zahteve za program ali programski izdelek;
zahteve za dokumentacijo programske opreme;
tehnični in ekonomski kazalci;
faze in stopnje razvoja;
postopek kontrole in prevzema;
Aplikacije so lahko vključene v tehnične specifikacije.

Glede na značilnosti programa ali programskega izdelka je možno vsebino razdelkov pojasnjevati, uvajati nove razdelke ali posamezne sklope združevati.

Naslednji standard
GOST (ST SEV) 19.101-77 (1626-79). ESPD. Vrste programov in programski dokumenti (Ponovno izdano novembra 1987 s spremembo 1).
Določa vrste programov in programskih dokumentov za računalnike, komplekse in sisteme ne glede na njihov namen in obseg.

Vrste programov

Vrste programskih dokumentov

Vrsta programskega dokumenta
Specifikacija	Sestava programa in njegova dokumentacija
	Seznam podjetij, ki hranijo originalne programske dokumente
Besedilo programa	Snemanje programa s potrebnimi komentarji
Opis programa	Informacije o logični zgradbi in delovanju programa
	Zahteve, ki jih je treba preveriti pri testiranju programa, ter postopek in metode njihovega nadzora
Tehnična naloga	Namen in obseg programa, tehnične, izvedljive in posebne zahteve za program, potrebne stopnje in roki razvoja, vrste testov.
Pojasnilo	Diagram algoritma, splošen opis algoritma in (ali) delovanja programa ter utemeljitev sprejetih tehničnih in tehnično-ekonomskih odločitev.
Operativni dokumenti	Informacije za zagotavljanje delovanja in delovanja programa

Vrste operativnih dokumentov

Vrsta operativnega dokumenta
	Seznam operativnih dokumentov za program
Oblika	Glavne značilnosti programa, popolnost in podatki o delovanju programa
Opis aplikacije	Informacije o namenu programa, obsegu uporabe, uporabljenih metodah, razredu problemov, ki jih je treba rešiti, omejitvah za uporabo, minimalni konfiguraciji strojne opreme.
	Informacije za preverjanje, zagotavljanje delovanja in prilagajanje programa za pogoje določene aplikacije
Programerski vodnik	Informacije za uporabo programa
Navodila za uporabo	Informacije za zagotavljanje postopka komunikacije med operaterjem in računalniškim sistemom med izvajanjem programa
Opis jezika	Opis sintakse in semantike jezika
	Informacije za uporabo testnih in diagnostičnih programov pri servisiranju tehnične opreme

Programski dokumenti so glede na način izvajanja in naravo uporabe razdeljeni na izvirnike, dvojnike in kopije (GOST 2.102-68), namenjene razvoju, vzdrževanju in delovanju programa.

Vrste programskih dokumentov, razvitih na različnih stopnjah, in njihove kode

Koda vrste dokumenta	Vrsta dokumenta	Razvojne faze
		Idejni projekt	Tehnični projekt	Delovni osnutek
		Idejni projekt	Tehnični projekt	komponento	kompleksen
-	Specifikacija	-	-	!	+
05	Seznam originalnih imetnikov	-	-	-	?
12	Besedilo programa	-	-	+	?
13	Opis programa	-	-	?	?
20	Seznam operativnih dokumentov	-	-	?	?
30	Oblika	-	-	?	?
31	Opis aplikacije	-	-	?	?
32	Priročnik za sistemskega programerja	-	-	?	?
33	Programerski vodnik	-	-	?	?
34	Navodila za uporabo	-	-	?	?
35	Opis jezika	-	-	?	?
46	Priročnik za vzdrževanje	-	-	?	?
51	Testni program in metodologija	-	-	?	?
81	Pojasnilo	?	?	-	-
90-99	Drugi dokumenti	?	?	?	?

Dovoljeno je združevanje nekaterih vrst operativnih dokumentov (razen seznama operativnih dokumentov in obrazca). Potreba po združitvi teh dokumentov je navedena v tehničnih specifikacijah. Spojenemu dokumentu se dodeli ime in oznaka enega od spojenih dokumentov. Spojeni dokumenti morajo določati informacije, ki morajo biti vključene v vsak dokument, ki se združuje.

GOST 19.102-77. ESPD. Razvojne faze.

Določa stopnje razvoja programov in programske dokumentacije za računalnike, komplekse in sisteme, ne glede na njihov namen in obseg uporabe.

Faze razvoja, faze in vsebina dela

Razvojne faze	Faze dela
Tehnična naloga	Utemeljitev potrebe po razvoju programa	Oblikovanje problema. Zbirka izvornih materialov. Izbira in utemeljitev meril za učinkovitost in kakovost razvitega programa. Utemeljitev potrebe po raziskovalnem delu.
	Raziskovalno delo	Določanje strukture vhodnih in izhodnih podatkov. Predhodna izbira metod reševanja problema. Utemeljitev izvedljivosti uporabe predhodno razvitih programov. Določitev zahtev za tehnična sredstva. Utemeljitev temeljne možnosti rešitve problema.
	Razvoj in odobritev tehničnih specifikacij	Določitev programskih zahtev. Izdelava študije izvedljivosti za razvoj programa. Določitev stopenj, stopenj in časovnega okvira razvoja programa in dokumentacije zanj. Izbira programskih jezikov. Ugotavljanje potrebe po raziskovalnem delu v naslednjih fazah. Usklajevanje in potrditev tehničnih specifikacij.
Idejni projekt	Izdelava idejnega projekta	Predhodni razvoj strukture vhodnih in izhodnih podatkov. Pojasnitev metod za rešitev problema. Razvoj splošnega opisa algoritma za reševanje problema. Izdelava študije izvedljivosti.
Idejni projekt	Potrditev idejnega projekta	Usklajevanje in potrditev idejnega projekta
Tehnični projekt	Razvoj tehničnega projekta	Razjasnitev strukture vhodnih in izhodnih podatkov. Razvoj algoritma za rešitev problema. Določanje oblike prikaza vhodnih in izhodnih podatkov. Opredelitev semantike in sintakse jezika. Razvoj programske strukture. Končna določitev konfiguracije strojne opreme.
Tehnični projekt	Soglasje tehnične zasnove	Izdelava akcijskega načrta za razvoj in izvajanje programov. Razvoj pojasnjevalne opombe. Usklajevanje in potrditev tehničnega projekta.
Delovni osnutek	Razvoj programa	Programiranje in odpravljanje napak
	Razvoj programske dokumentacije	Razvoj programskih dokumentov v skladu z zahtevami GOST 19.101-77.
	Testiranje programa	Razvoj, usklajevanje in potrditev testnega programa in metodologije. Izvajanje predhodnih državnih, medoddelčnih, sprejemnih in drugih vrst testov. Popravek programa in programske dokumentacije na podlagi rezultatov testiranja.
Izvedba	Priprava in prenos programa	Priprava in prenos programov in programske dokumentacije za vzdrževanje in (ali) proizvodnjo. Registracija in odobritev akta o prenosu programa za vzdrževanje in (ali) proizvodnjo. Prenos programa v sklad algoritmov in programov.

Opombe:

Dovoljeno je izključiti drugo stopnjo razvoja, v tehnično utemeljenih primerih pa drugo in tretjo stopnjo. Potreba po teh stopnjah je navedena v tehničnih specifikacijah.
Dovoljeno je kombinirati, izločiti faze dela in (ali) njihovo vsebino ter uvesti druge faze dela po dogovoru s stranko.

GOST 19.103-77 ESPD. Označevanje programov in programskih dokumentov

Šifra države razvijalca in šifra organizacije razvijalca se dodelita na predpisan način.

Registrska številka je dodeljena v naraščajočem vrstnem redu, od 00001 do 99999, za vsako razvojno organizacijo.
Številka objave programa ali številka revizije. številka dokumenta te vrste, številka dela dokumenta se dodeli v naraščajočem vrstnem redu od 01 do 99. (Če je dokument sestavljen iz enega dela, se vezaj in zaporedna številka dela ne navedeta).
Številka revizije specifikacije in seznama operativnih dokumentov za program se mora ujemati s številko objave istega programa.

GOST 19.105-78 ESPD. Splošne zahteve za programske dokumente

Programski dokument je lahko predstavljen na različnih vrstah pomnilniških medijev in je sestavljen iz naslednjih običajnih delov:
naslov;
informativni;
osnovni.

Pravila za izvedbo dokumenta in njegovih delov na posameznem nosilcu podatkov določajo ESPD standardi za pravila za izvajanje dokumentov na pripadajočih nosilcih podatkov.

GOST 19.106-78 ESPD. Zahteve za tiskane programske dokumente

Programske dokumente pripravljajo:

na listih formata A4 (GOST 2.301-68) pri pripravi dokumenta s tipkanjem ali rokopisom;
Možnost tiskanja na liste velikosti A3;
pri strojnem načinu izdelave dokumentov so dovoljena odstopanja v velikosti listov, ki ustrezajo formatoma A4 in A3, ki jih določajo zmogljivosti uporabljenih tehničnih sredstev; na listih formatov A4 in A3, ki jih predvidevajo izhodne lastnosti naprav za izpisovanje podatkov, pri strojni izdelavi dokumenta;
na listih tipografskih formatov pri izdelavi dokumenta s tipografsko metodo.

Gradiva programskega dokumenta so urejena v naslednjem zaporedju:

Naslovni del:

odobritveni list (ni vključen v skupno število listov dokumenta);
naslovna stran (prva stran dokumenta);

informativni del:

opomba;
kazalo;

glavni del:

besedilo dokumenta (s slikami, tabelami itd.)
seznam pojmov in njihovih definicij;
seznam okrajšav;
aplikacije;
predmetno kazalo;
seznam referenčnih dokumentov;

del beleženja sprememb:

sprememba vpisnega lista.

Po potrebi je naveden seznam pojmov in njihovih definicij, seznam okrajšav, priloge, predmetno kazalo, seznam referenčnih dokumentov.

Naslednji standard je osredotočen na dokumentiranje nastalega razvojnega izdelka:

GOST 19.402-78 ESPD. Opis programa

Sestavo dokumenta "Opis programa" po svoji vsebini je mogoče dopolniti z razdelki in odstavki, vzetimi iz standardov za druge opisne dokumente in priročnike: GOST 19.404-79 ESPD. Pojasnilo, GOST 19.502-78 ESPD. Opis uporabe, GOST 19.503-79 ESPD. Vodnik sistemskega programerja, GOST 19.504-79 ESPD. Navodila za programerje, GOST 19.505-79 ESPD. Navodila za uporabo.

Poudariti moramo tudi

GOST 19.301-79 ESPD. Testni program in metodologija, ki se (v prilagojeni obliki) lahko uporabljata za izdelavo planskih dokumentov in izvajanje testnih del za oceno pripravljenosti in kakovosti RTP.

Za konec še zadnji standard glede na leto sprejetja.

GOST 19.701-90 ESPD. Sheme algoritmov, programov, podatkov in sistemov. Konvencionalne grafične oznake in pravila izvedbe.

Poleg ESPD na meddržavni ravni veljata še dva standarda, ki sta povezana tudi z dokumentiranjem PS in sprejeta ne tako dolgo nazaj kot večina GOST ESPD.

2.2. Standardi kompleksa GOST 34

Za splošni primer razvoja AS so stopnje in faze GOST 34 podane v tabeli:

1. FT - Oblikovanje zahtev za govorce.	1.1. Pregled objekta in utemeljitev potrebe po izgradnji jedrske elektrarne; 1.2. Oblikovanje uporabniških zahtev za zvočnike; 1.3. Priprava poročila o opravljenem delu in vloge za razvoj AS (taktične in tehnične specifikacije);
2. RK - Razvoj koncepta AS.	2.1. Študija predmeta; 2.2. Izvajanje potrebnega raziskovalnega dela; 2.3. Razvoj možnosti za koncept zvočnikov, ki ustreza zahtevam uporabnikov 2.4. Sestava poročila o opravljenem delu
3. TK - Tehnična izdelava AS.	3.1. Razvoj in odobritev tehničnih specifikacij za nalogo.
4. EP - Osnutek zasnove.	4.1. Razvoj idejnih projektnih rešitev za sistem in njegove dele; 4.2. Razvoj dokumentacije za AU in njegove dele.
5. TP - Tehnična zasnova.	5.1. Razvoj oblikovalskih rešitev za sistem in njegove dele; 5.2. Izdelava dokumentacije za NEK in njene dele; 5.3. Razvoj in izvedba dokumentacije za dobavo proizvodov za dokončanje NEK in/ali tehničnih zahtev (tehničnih specifikacij) za njihov razvoj; 5.4. Izdelava projektnih nalog v sosednjih delih projekta avtomatizacije.
6. RD - Delovna dokumentacija.	6.1. Razvoj delovne dokumentacije za sistem in njegove dele; 6.2. Razvoj ali prilagoditev programov.
7. VD - Začetek obratovanja.	7.1. Priprava avtomatiziranega objekta za zagon naprave; 7.2. Usposabljanje osebja; 7.3. Komplet zvočnikov z dobavljenimi izdelki (programska in strojna oprema, programski in strojni sistemi, informacijski izdelki); 7.4. Gradbena in inštalacijska dela; 7.5. Zagonska dela; 7.6. Izvajanje predhodnih testov; 7.7. Izvajanje poskusnega obratovanja; 7.8. Izvajanje sprejemnih testov.
8. Sp - AC podpora.	8.1. Izvajanje del v skladu z garancijskimi obveznostmi; 8.2. Pogarancijski servis.

Opisana je vsebina dokumentov, razvitih na vsaki stopnji. To določa potencialne možnosti prepoznavanja na vsebinski ravni vzporedno ali zaporedno opravljenega dela od konca do konca (to je v bistvu procesov) in njihovih sestavnih nalog. To tehniko je mogoče uporabiti pri izdelavi profila standardov življenjskega cikla projekta, vključno z dogovorjenimi podnabori standardov GOST 34 in ISO12207.

Glavni motiv: rešiti problem "babilonskega stolpa".

V 80. letih je prišlo do situacije, v kateri so različne industrije in področja dejavnosti uporabljale slabo usklajeno ali nedosledno NTD - "normativno in tehnično dokumentacijo". To je oteževalo integracijo sistemov in zagotavljanje njihovega učinkovitega skupnega delovanja. Obstajali so različni kompleksi in sistemi standardov, ki so določali zahteve za različne vrste AS.

Seveda je to stanje deloma odražalo naravno raznolikost pogojev za razvoj AS, ciljev razvijalcev ter uporabljenih pristopov in tehnik.

Pod temi pogoji je bilo mogoče analizirati takšno raznolikost in nato nadaljevati na primer na enega od dveh v veliki meri nasprotnih načinov:

Razviti en posplošen konceptualni in terminološki sistem, splošno razvojno shemo, skupen sklop dokumentov z njihovo vsebino in jih opredeliti kot obvezne za vse AS;
Določite tudi en splošen konceptualni in terminološki sistem, posplošen nabor sistemskih zahtev, nabor kriterijev kakovosti, vendar zagotovite največjo svobodo pri izbiri razvojne sheme, sestave dokumentov in drugih vidikov, naložite le minimalne obvezne zahteve, ki bi omogočile :
- določite raven kakovosti rezultata;
- izbrati tiste specifične metode (s svojimi modeli življenjskega cikla, naborom dokumentov itd.), ki so najbolj primerne za razvojne pogoje in ustrezajo uporabljenim informacijskim tehnologijam;
- tako delujejo z minimalnimi omejitvami glede učinkovitih dejanj oblikovalca zvočnikov.

Stopnja prilagodljivosti je formalno določena z zmogljivostmi:

izpustite fazo predhodnega projektiranja in združite fazi "tehnična zasnova" in "podrobna dokumentacija";
izpustite korake, združite in izpustite večino dokumentov in njihovih razdelkov;
vnesite dodatne dokumente, razdelke dokumentov in dela;
dinamično ustvarjanje t.i. ChTZ - zasebne tehnične specifikacije - je precej prilagodljivo za oblikovanje življenjskega cikla AS; Praviloma se ta tehnika uporablja na ravni velikih enot (podsistemov, kompleksov), zaradi katerih se zdi upravičeno ustvariti CTZ, vendar ni pomembnih razlogov za močno omejitev tega načina upravljanja življenjskega cikla.

Faze in mejniki, ki jih izvajajo organizacije, ki sodelujejo pri gradnji jedrskih elektrarn, so določeni v pogodbah in tehničnih specifikacijah, kar je blizu pristopu ISO.

Ločitev konceptov PTC in AS je zasnovala načelo, po katerem AS ni »IS z bazo podatkov«, temveč:

"organizacijski in tehnični sistem, ki zagotavlja razvoj rešitev, ki temeljijo na avtomatizaciji informacijskih procesov na različnih področjih dejavnosti (upravljanje, projektiranje, proizvodnja itd.) Ali njihovih kombinacij" (v skladu z RD 50-680-88), ki je še posebej aktualna v poslovnih vidikih -reinženiring;
"Sistem, ki ga sestavljajo osebje in nabor orodij za avtomatizacijo za njihove dejavnosti, ki uporabljajo informacijsko tehnologijo za izvajanje uveljavljenih funkcij" (v skladu z GOST 34.003-90).

Te definicije kažejo, da je AS predvsem osebje, ki sprejema odločitve in izvaja druge upravljavske ukrepe, podprto z organizacijskimi in tehničnimi sredstvi.

Stopnja obveznosti:

Ključni dokument za sodelovanje med stranema so tehnične specifikacije za izgradnjo jedrske elektrarne. Tehnična specifikacija je glavni izvorni dokument za izdelavo AS in njegovo sprejetje, tehnična specifikacija določa najpomembnejše točke interakcije med naročnikom in razvijalcem. V tem primeru tehnične specifikacije razvije organizacija razvijalca (v skladu z GOST 34.602-89), vendar stranka uradno izda tehnične specifikacije razvijalcu (v skladu z RD 50-680-88).

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

GOST R ISO 9127-94 Sistemi za obdelavo informacij. Uporabniška dokumentacija in informacije o embalaži za potrošniške programske pakete. Standard je v celoti skladen z mednarodnim standardom ISO 9127:1989. Za namene tega standarda je potrošniški programski paket (CPP) opredeljen kot "programski izdelek, zasnovan in prodan za opravljanje določene funkcije; program in njegova povezana dokumentacija, zapakirana za prodajo kot ena sama enota." Uporabniška dokumentacija se nanaša na dokumentacijo, ki končnemu uporabniku nudi informacije o namestitvi in delovanju programske opreme. Informacije na embalaži se nanašajo na informacije, ki so prikazane na zunanji embalaži PP. Njegov namen je potencialnim kupcem zagotoviti osnovne informacije o programski opremi.

GOST R ISO/IEC 8631-94 Informacijska tehnologija. Programski konstrukti in simboli za njihovo predstavitev. Opisuje predstavitev postopkovnih algoritmov.

2.4. Mednarodni standard ISO/IEC 12207: 1995-08-01

Prvo izdajo ISO12207 je leta 1995 pripravil skupni tehnični odbor ISO/IEC JTC1 "Informacijska tehnologija, pododbor SC7, programsko inženirstvo".

Po definiciji je ISO12207 osnovni standard za procese življenjskega cikla programske opreme, osredotočen na različne (poljubne!) vrste programske opreme in vrste AS projektov, katerih del je programska oprema. Standard opredeljuje strategijo in splošni red pri ustvarjanju in delovanju programske opreme, zajema življenjski cikel programske opreme od konceptualizacije idej do zaključka življenjskega cikla.

Zelo pomembne OPOMBE K STANDARDU:

Procesi, uporabljeni v življenjskem ciklu programske opreme, morajo biti združljivi s procesi, uporabljenimi v življenjskem ciklu AS. (Zato je smotrnost skupne uporabe AS in programskih standardov jasna.)
Dodatek edinstvenih ali posebnih procesov, dejavnosti in nalog mora biti določen v pogodbi med strankama. Pogodbo razumemo v širokem smislu: od pravno formalizirane pogodbe do neformalnega dogovora lahko ena sama stranka opredeli dogovor kot nalogo, ki si jo zastavi sama.
Standard načeloma ne vsebuje posebnih načinov ukrepanja, še manj pripravljenih rešitev ali dokumentacije. Opisuje arhitekturo procesov življenjskega cikla programske opreme, vendar ne določa podrobno, kako izvajati ali izvajati storitev in nalog, vključenih v procese, in ni namenjen predpisovanju imena, oblike ali natančne vsebine nastale dokumentacije. Tovrstne odločitve sprejema uporabnik standarda.

STANDARDNE DEFINICIJE:

Sistem je kombinacija enega ali več procesov, strojne opreme, programske opreme, opreme in ljudi, ki omogoča zadovoljevanje določenih potreb ali ciljev.
Model življenjskega cikla- strukturo, ki vsebuje procese, dejanja in naloge, ki se izvajajo med razvojem, delovanjem in vzdrževanjem programskega izdelka skozi celotno življenjsko dobo sistema, od določanja zahtev do konca njegove uporabe.
Številni procesi in opravila so zasnovani tako, da jih je mogoče prilagajati v skladu s programskimi projekti. Proces prilagajanja je proces izločanja procesov, aktivnosti in nalog, ki niso uporabni za določen projekt. Stopnja prilagodljivosti: največja
Kvalificirana zahteva- nabor meril ali pogojev (zahtev za kvalifikacijo), ki morajo biti izpolnjeni, da se programski izdelek kvalificira kot skladen (izpolnjuje pogoje) s svojimi specifikacijami in pripravljen za uporabo v ciljnem okolju.

Standard ISO12207 je enako osredotočen na organizacijo delovanja obeh strani: dobavitelja (razvijalca) in kupca (uporabnika); se lahko enako uporablja, če sta obe strani iz iste organizacije.

Standard ISO12207 opisuje:

5 glavnih procesov življenjskega cikla programske opreme:
- Postopek pridobivanja. Določa dejanja nakupovalnega podjetja, ki kupi AS, programski izdelek ali programsko storitev.
- Postopek dostave. Določa dejanja dobavitelja, ki kupcu dobavlja sistem, programski izdelek ali programsko storitev.
- Razvojni proces. Določa dejanja razvojnega podjetja, ki razvija princip gradnje programskega izdelka in programskega izdelka.
- Proces delovanja. Določa dejanja operaterske družbe, ki zagotavlja vzdrževanje sistema (in ne samo programske opreme) med njegovim delovanjem v interesu uporabnikov. V nasprotju z dejanji, ki jih določi razvijalec v navodilih za uporabo (ta aktivnost razvijalca je predvidena v vseh treh obravnavanih standardih), so določena dejanja operaterja za posvetovanje z uporabniki, prejemanje povratnih informacij itd. sam načrtuje in prevzema ustrezne odgovornosti.
- Postopek vzdrževanja. Določa dejanja vzdrževalcev, ki zagotavljajo vzdrževanje programskega izdelka, to je upravljanje modifikacij programskega izdelka, podpora njegovemu trenutnemu stanju in funkcionalni ustreznosti, vključno z namestitvijo in odstranitvijo programskega izdelka v računalniškem sistemu.
8 pomožnih procesov, ki podpirajo implementacijo drugega procesa, ki je sestavni del celotnega življenjskega cikla programskega izdelka in zagotavlja ustrezno kakovost programskega projekta:
- rešitev problema;
- dokumentacija;
- upravljanje konfiguracije;
- zagotavljanje kakovosti, ki uporablja rezultate preostalih procesov skupine za zagotavljanje kakovosti, ki vključuje:
  - Postopek preverjanja;
  - Postopek certificiranja;
  - Participativni proces ocenjevanja;
  - Postopek revizije.
4 organizacijski procesi:
- Proces upravljanja;
- Postopek ustvarjanja infrastrukture;
- Postopek izboljšanja;
- Učni proces.

Spremlja jih poseben proces prilagajanja, ki opredeljuje glavne ukrepe, potrebne za prilagoditev standarda pogojem določenega projekta.

Pri tem proces izboljšave ne pomeni izboljšave AS ali programske opreme, ampak izboljšanje procesov pridobivanja, razvoja, zagotavljanja kakovosti itd., ki se dejansko izvajajo v organizaciji.

Zagotovljene niso stopnje, faze, stopnje, kar daje stopnjo prilagodljivosti, opisano spodaj.

"Dinamična" narava standarda je določena z načinom zaporedja procesov in opravil, pri katerem en proces po potrebi pokliče drugega ali njegov del.

izvedba postopka pridobivanja v smislu analiziranja in beleženja zahtev za sistem ali programsko opremo lahko sproži izvajanje ustreznih nalog razvojnega procesa;
Dobavitelj mora v procesu dostave voditi podizvajalce v skladu s postopkom pridobivanja ter izvajati preverjanje in kvalifikacije glede na ustrezne procese;
Vzdrževanje lahko zahteva razvoj sistema in programske opreme, ki se izvaja v skladu z razvojnim procesom.

Ta narava omogoča implementacijo katerega koli modela življenjskega cikla.

Pri izvajanju analize programskih zahtev obstaja 11 razredov karakteristik kakovosti, ki se kasneje uporabljajo pri zagotavljanju kakovosti.

V tem primeru mora razvijalec določiti in dokumentirati kot zahteve za programsko opremo:

Funkcionalne in omogočilne specifikacije, vključno z izvajanjem, fizičnimi značilnostmi in pogoji operacijskega okolja, v katerih se mora programska postavka izvajati;
Zunanje povezave (vmesniki) s programsko enoto;
Zahteve glede kvalifikacij;
Specifikacije zanesljivosti, vključno s specifikacijami v zvezi z metodami delovanja in vzdrževanja, izpostavljenostjo okolja in verjetnostjo telesnih poškodb;
Varnostne specifikacije
Specifikacije človeških dejavnikov za inženirsko psihologijo (ergonomija), vključno s tistimi v zvezi z ročnim nadzorom, interakcijo med človekom in opremo, omejitvami osebja in področji, ki zahtevajo osredotočeno človeško pozornost in so občutljiva na človeške napake in učenje;
Določitev zahtev glede podatkov in baze podatkov;
Zahteve za namestitev in sprejem dobavljenega programskega izdelka na mestih delovanja in vzdrževanja (delovanja);
Uporabniška dokumentacija;
Uporabniško delo in zahteve glede uspešnosti;
Zahteve uporabniških storitev.

(Zanimivo in pomembno je, da se te in podobne značilnosti dobro ujemajo z značilnostmi NPP, ki jih GOST 34 predvideva za vrste sistemske podpore.)

Torej ima ISO12207 nabor procesov, dejavnosti in nalog, ki pokrivajo najširši možni spekter možnih situacij z največjo prilagodljivostjo.

Praktiki uporabljajo drug način: sami prevajajo in uporabljajo v svojih projektih sodobne standarde za organizacijo življenjskega cikla transformatorske postaje in njihove dokumentacije. Toda ta pot ima vsaj to pomanjkljivost, da se bodo različni prevodi in prilagoditve standardov, ki jih naredijo različni razvijalci in kupci, razlikovali v številnih podrobnostih. Te razlike neizogibno zadevajo ne samo imena, temveč tudi njihove vsebinske opredelitve, ki so uvedene in uporabljene v standardih. Tako je na tej poti neizogibno nenehno nastajanje zmede, kar je neposredno v nasprotju s cilji ne le standardov, ampak tudi vseh pristojnih metodoloških dokumentov.

Trenutno je All-Russian Research Institute of Standards pripravil predloge za izboljšanje in razvoj nabora standardov za dokumentiranje programske opreme.

referenčne informacije

Za nakup standardov dokumentacije priporočamo, da se obrnete na naslednje organizacije:

IPK "Standardi založništva", Teritorialni oddelek za distribucijo znanstvene in tehnične dokumentacije (trgovina "Standardi"), 17961, Moskva, ul. Donskaya, 8, tel. 236-50-34, 237-00-02, faks/tel. 236-34-48 (glede GOST in GOST R).