Zápis v programe. Schémy algoritmov a programov Symboly, grafické symboly

GOST 19.701-90
(ISO 5807-85)

Skupina T55

MEDZIŠTÁTNY ŠTANDARD

jeden systém programová dokumentácia

DIAGRAMY ALGORITMOV, PROGRAMOV, ÚDAJOV A SYSTÉMOV

Konvenčné označenia a pravidlá vykonávania

Jednotný systém pre dokumentáciu programu. Dátové, programové a systémové vývojové diagramy, programové sieťové diagramy a diagramy systémových zdrojov. Dokumentačné symboly a konvencie pre vývojové diagramy

MKS 35,080*
OKSTU 5004

____________________
* V indexe "Národné štandardy" 2012
ISS 01.080.50 a 35.080. - Poznámka výrobcu databázy.

Dátum zavedenia 1992-01-01

INFORMAČNÉ ÚDAJE

1. VYVINUTÝ A ZAVEDENÝ Štátnym výborom ZSSR pre počítačové inžinierstvo a informatiku

VÝVOJÁRI

A.A. Mkrtumyan (manažér vývoja); A.L. Shchers, Dr. tech. vedy; A. N. Sirotkin, Ph.D. ist. vedy; L.D.Raikov, PhD. tech. vedy; A. V. Lobová; medzirezortný Pracovná skupina o vývoji noriem ESPD

2. SCHVÁLENÉ A NADOBUDNUTÉ ÚČINNOSTI uznesením Štátneho výboru ZSSR pre riadenie kvality výrobkov a normy zo dňa 26. decembra 1990 N 3294

3. Táto norma bola vyvinutá priamou aplikáciou medzinárodnej normy ISO 5807-85 * „Spracovanie informácií. Symboly a konvencie pre dátové blokové diagramy, programy a systémy, softvérové ​​sieťové diagramy a systémové prostriedky"
________________
* Prístup k medzinárodným a zahraničným dokumentom uvedeným v texte môžete získať kontaktovaním zákazníckej podpory. - Poznámka výrobcu databázy.

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

5. REPUBLIKÁCIA. januára 2010


Táto norma sa vzťahuje na konvencie (symboly) v diagramoch algoritmov, programov, údajov a systémov a stanovuje pravidlá na vykonávanie diagramov používaných na zobrazenie rôznych typov problémov spracovania údajov a prostriedky na ich riešenie.

Norma sa nevzťahuje na formu záznamov a symbolov umiestnených v rámci symbolov alebo vedľa nich, ktoré slúžia na objasnenie funkcií, ktoré vykonávajú.

Požiadavky normy sú povinné.

1. VŠEOBECNÉ USTANOVENIA

1. VŠEOBECNÉ POŽIADAVKY

1.1. Diagramy algoritmov, programov, údajov a systémov (ďalej len diagramy) pozostávajú zo symbolov s daným významom, krátkeho vysvetľujúceho textu a spojovacích čiar.

1.2. Schémy možno použiť na rôznych úrovniach detailov, pričom počet úrovní závisí od veľkosti a zložitosti problému spracovania údajov. Úroveň podrobnosti by mala byť taká, aby sa rôzne časti a vzťahy medzi nimi chápali ako celok.

1.3. Táto norma definuje symboly na použitie v dokumentácii spracovania údajov a poskytuje návod na konvencie na použitie v:

1) dátové schémy;

2) programové diagramy;

3) schémy fungovania systému;

4) schémy interakcie programu;

5) diagramy systémových prostriedkov.

1.4. Norma používa nasledujúce pojmy:

1) základný symbol - symbol používaný v prípadoch, keď nie je známy presný typ (typ) procesného alebo pamäťového média alebo nie je potrebné popisovať skutočné pamäťové médium;

2) špecifický symbol - symbol používaný v prípadoch, keď je známy presný typ (druh) procesu alebo pamäťového média alebo keď je potrebné opísať skutočné pamäťové médium;

3) diagram - grafické znázornenie definície, analýzy alebo metódy na riešenie problému, ktorá používa symboly na znázornenie operácií, údajov, toku, vybavenia atď.

2. POPIS OBVODU

2.1. Schéma údajov

2.1.1. Dátové schémy predstavujú cestu dát pri riešení problémov a definujú kroky spracovania, ako aj rôzne používané pamäťové médiá.

2.1.2. Dátová schéma pozostáva z:

1) dátové symboly (údajové symboly môžu označovať aj typ pamäťového média);

2) symboly procesu, ktorý by sa mal vykonať na údajoch (symboly procesov môžu tiež označovať funkcie vykonávané počítačom);

3) čiarové symboly označujúce dátové toky medzi procesmi a (alebo) pamäťovými médiami;

2.1.3. Dátové symboly predchádzajú a nasledujú symboly procesu. Dátová schéma začína a končí dátovými symbolmi (okrem špeciálne znakyšpecifikované v odseku 3.4).

2.2. Náčrt programu

2.2.1. Programové diagramy zobrazujú postupnosť operácií v programe.

2.2.2. Programová schéma pozostáva z:

1) symboly procesu označujúce skutočné operácie spracovania údajov (vrátane symbolov definujúcich cestu, po ktorej by sa malo postupovať, berúc do úvahy logické podmienky);

2) lineárne symboly označujúce riadiaci tok;

3) špeciálne symboly používané na uľahčenie písania a čítania diagramu.

2.3. Schéma fungovania systému

2.3.1. Prevádzkové diagramy systému zobrazujú riadenie operácií a tok dát v systéme.

2.3.2. Prevádzková schéma systému pozostáva z:

1) dátové symboly označujúce prítomnosť dát (údajové symboly môžu označovať aj typ pamäťového média);

2) symboly procesov označujúce operácie, ktoré by sa mali vykonať s údajmi, a tiež definujúce logickú cestu, ktorá by sa mala dodržiavať;

3) lineárne symboly označujúce dátové toky medzi procesmi a (alebo) pamäťovými médiami, ako aj riadiaci tok medzi procesmi;

4) špeciálne symboly používané na uľahčenie zapisovania a čítania vývojového diagramu.

2.4. Schéma interakcie programu

2.4.1. Diagramy interakcie programu zobrazujú cestu aktivácií programu a interakcií s príslušnými údajmi. Každý program v diagrame interakcie programu je zobrazený iba raz (v diagrame prevádzky systému môže byť program zobrazený vo viacerých riadiacich tokoch).

2.4.2. Schéma interakcie programu pozostáva z:

1) dátové symboly označujúce prítomnosť dát;

2) symboly procesov označujúce operácie, ktoré by sa mali vykonať s údajmi;

3) lineárne symboly zobrazujúce tok medzi procesmi a údajmi, ako aj spustenie procesov;

4) špeciálne symboly používané na uľahčenie písania a čítania diagramu.

2.5. Schéma systémových prostriedkov

2.5.1. Diagramy systémových prostriedkov zobrazujú konfiguráciu údajov a jednotiek spracovania, ktoré sú potrebné na vyriešenie úlohy alebo súboru úloh.

2.5.2. Schéma systémových prostriedkov pozostáva z:

1) dátové symboly zobrazujúce vstupné, výstupné a pamäťové zariadenia počítača;

2) symboly procesov zobrazujúce procesory ( centrálne procesorové jednotky, kanály atď.);

3) lineárne symboly zobrazujúce prenos údajov medzi vstupnými/výstupnými zariadeniami a procesormi, ako aj prenos riadenia medzi procesormi;

4) špeciálne symboly používané na uľahčenie písania a čítania diagramu.

Príklady implementácie obvodu sú uvedené v prílohe.

3. POPIS SYMBOLOV

3.1. Dátové symboly

3.1.1. Základné dátové symboly

3.1.1.1. Údaje

Symbol zobrazuje údaje, pamäťové médium nie je definované.

3.1.1.2. Zapamätané údaje

Symbol zobrazuje uložené údaje vo forme vhodnej na spracovanie, pamäťové médium nie je definované.

3.1.2. Špecifické dátové znaky

3.1.2.1. Náhodný vstup do pamäťe

Symbol zobrazuje údaje uložené v pamäťovom zariadení s náhodným prístupom.

3.1.2.2. Pamäť so sériovým prístupom

Symbol predstavuje údaje uložené v pamäťovom zariadení so sériovým prístupom (magnetická páska, kazeta s magnetickou páskou, kazeta s páskou).

3.1.2.3. Úložné zariadenie s priamym prístupom

Symbol predstavuje údaje uložené v úložnom zariadení s priamym prístupom ( magnetický disk magnetický bubon, flexibilný magnetický disk).

3.1.2.4. Dokument

Symbol zobrazuje údaje prezentované na médiu v čitateľnej forme (schéma stroja, dokument na optické alebo magnetické čítanie, mikrofilm, rolka pásky so súhrnnými údajmi, formuláre na zadávanie údajov).

3.1.2.5. Manuálny vstup

Symbol zobrazuje údaje zadané ručne počas spracovania z akéhokoľvek typu zariadenia (klávesnica, spínače, tlačidlá, svetelné pero, pásiky čiarových kódov).

3.1.2.6. Mapa

Symbol zobrazuje údaje prezentované na kartovom médiu (dierne štítky, magnetické karty, karty s čitateľnými štítkami, karty s odtrhávacím štítkom, karty so snímateľnými štítkami).

3.1.2.7. Papierová páska

Symbol zobrazuje údaje prezentované na médiu vo forme papierovej pásky.

3.1.2.8. Displej

Symbol zobrazuje údaje prezentované vo forme čitateľnej pre človeka na médiu vo forme zobrazovacieho zariadenia (obrazovka vizuálneho pozorovania, indikátory vstupu informácií).

3.2. Procesné symboly

3.2.1. Základné procesné symboly

3.2.1.1. Proces

Symbol predstavuje funkciu spracovania údajov akéhokoľvek druhu (vykonávanie špecifickej operácie alebo skupiny operácií, ktorých výsledkom je zmena hodnoty, formy alebo umiestnenia informácií alebo určenie, ktorý z niekoľkých smerov toku sa má sledovať).

3.2.2. Spracujte špecifické symboly

3.2.2.1. Preddefinovaný proces

Symbol zobrazuje preddefinovaný proces pozostávajúci z jednej alebo viacerých operácií alebo krokov programu, ktoré sú definované inde (v podprograme, module).

3.2.2.2. Manuálna operácia

Symbol predstavuje akýkoľvek proces vykonávaný osobou.

3.2.2.3. Príprava

Symbol predstavuje úpravu inštrukcie alebo skupiny inštrukcií na ovplyvnenie niektorej následnej funkcie (nastavenie prepínača, úprava registra indexu alebo inicializácia programu).

3.2.2.4. Riešenie

Symbol predstavuje rozhodovaciu alebo prepínaciu funkciu, ktorá má jeden vstup a niekoľko alternatívnych výstupov, z ktorých jeden a len jeden je možné aktivovať po vyhodnotení podmienok definovaných v rámci symbolu. Zodpovedajúce výsledky výpočtu možno zapísať vedľa čiar reprezentujúcich tieto cesty.

3.2.2.5. Paralelné aktivity

Symbol predstavuje synchronizáciu dvoch alebo viacerých paralelných operácií.

Príklad

Poznámka. Procesy C, D a E sa nemôžu spustiť, kým sa nedokončí proces A; podobne proces F musí čakať na dokončenie procesov B, C a D, ale proces C sa môže spustiť a/alebo dokončiť skôr, ako sa začne a/alebo dokončí proces D.

3.2.2.6. Hranica slučky

Dvojdielny symbol predstavuje začiatok a koniec cyklu. Obe časti symbolu majú rovnaký identifikátor. Podmienky pre inicializáciu, inkrementáciu, ukončenie atď. sú umiestnené vo vnútri symbolu na začiatku alebo na konci, v závislosti od miesta operácie, ktorá kontroluje stav.

Príklad 

3.3. Symboly čiar

3.3.1. Symbol základnej čiary

3.3.1.1. Linka

Symbol predstavuje tok údajov alebo kontroly.

Smerové šípky môžu byť pridané podľa potreby alebo na zlepšenie čitateľnosti.

3.3.2. Špecifické symboly riadkov

3.3.2.1. Prevod kontroly

Symbol predstavuje priamy prenos riadenia z jedného procesu na druhý, niekedy s možnosťou priameho návratu do iniciačného procesu po tom, čo iniciovaný proces splní svoje funkcie. Typ prenosu kontroly musí byť pomenovaný v rámci symbolu (napr. požiadavka, volanie, udalosť).

3.3.2.2. Link

Symbol zobrazuje prenos dát cez komunikačný kanál.

3.3.2.3. Bodkovaná čiara

Zobrazí sa symbol alternatívne pripojenie medzi dvoma alebo viacerými znakmi. Okrem toho sa tento symbol používa na označenie oblasti s poznámkami.


Príklad 1

Keď sa jeden z množstva alternatívnych výstupov používa ako vstup pre proces, alebo keď sa výstup používa ako vstup pre alternatívne procesy, tieto symboly sú spojené bodkovanými čiarami.

Príklad 2

Výstup používaný ako vstup pre ďalší proces môže byť pripojený k tomuto vstupu pomocou bodkovanej čiary.

3.4. Špeciálne symboly

3.4.1. Konektor

Symbol predstavuje výjazd do časti okruhu a vstup z inej časti tohto okruhu a používa sa na prerušenie čiary a pokračovanie v nej na inom mieste. Zodpovedajúce symboly konektorov musia obsahovať rovnaké jedinečné označenie.

3.4.2. Terminátor

Symbol zobrazuje výstup do externého prostredia a vstup z externého prostredia (začiatok alebo koniec programového diagramu, vonkajšie použitie a zdroj alebo cieľ údajov).

3.4.3. Komentár

Symbol sa používa na pridanie popisných komentárov alebo vysvetľujúcich poznámok za účelom vysvetlenia alebo poznámok. Bodkované čiary v symbole komentára sú spojené so zodpovedajúcim symbolom alebo môžu načrtnúť skupinu symbolov. Text komentárov alebo poznámok by mal byť umiestnený v blízkosti ohraničujúceho tvaru.


Príklad

3.4.4. Pass

Symbol (tri bodky) sa používa v diagramoch na označenie vynechania symbolu alebo skupiny symbolov, v ktorých nie je špecifikovaný typ ani počet symbolov. Symbol sa používa iba v rámci alebo medzi riadkovými symbolmi. Používa sa najmä v diagramoch zobrazujúcich všeobecné riešenia s neznámym počtom opakovaní.

Príklad

4. PRAVIDLÁ POUŽÍVANIA SYMBOLOV A VYKONÁVANIA DIAGRAMOV

4.1. Pravidlá používania symbolov

4.1.1. Symbol je určený na grafické označenie funkcie, ktorú predstavuje, bez ohľadu na text v tomto symbole.

4.1.2. Symboly v diagrame by mali byť rozmiestnené rovnomerne. Mala by byť zachovaná primeraná dĺžka spojov a minimálny počet spojov. dlhé rady.

4.1.3. Väčšina symbolov je navrhnutá tak, aby umožňovala vloženie textu do symbolu. Formy symbolov špecifikované v tejto norme majú slúžiť ako návod pre skutočne používané symboly. Uhly a iné parametre, ktoré ovplyvňujú vhodný tvar symbolov, by sa nemali meniť. Symboly by mali mať podľa možnosti rovnakú veľkosť.

Znaky je možné kresliť v ľubovoľnej orientácii, ale vždy, keď je to možné, uprednostňujeme horizontálnu orientáciu. Zrkadlenie tvaru znaku označuje rovnakú funkciu, ale nie je preferované.

4.1.4. V rámci daného symbolu by malo byť umiestnené minimálne množstvo textu potrebné na pochopenie funkcie daného symbolu. Čítaný text by sa mal písať zľava doprava a zhora nadol bez ohľadu na smer toku.

Príklad

Ak množstvo textu umiestneného vo vnútri symbolu presahuje jeho rozmery, mal by sa použiť symbol komentára.

Ak by použitie symbolov komentárov mohlo zmiasť alebo narušiť plynulosť diagramu, text by sa mal umiestniť na samostatný list a mal by sa uviesť krížový odkaz na symbol.

4.1.5. Schémy môžu používať identifikátor symbolu. Toto je identifikátor spojený s daným symbolom, ktorý identifikuje symbol na referenčné použitie v iných prvkoch dokumentácie (napríklad výpis programu). ID symbolu by malo byť umiestnené vľavo nad symbolom.

Príklad

4.1.6. Diagramy môžu používať popisy symbolov – akékoľvek iné informácie, napríklad na znázornenie špeciálneho použitia symbolu s krížovým odkazom alebo na zlepšenie pochopenia funkcie ako súčasti diagramu. Popis symbolu by mal byť umiestnený vpravo nad symbolom.

Príklad

4.1.7. V systémových diagramoch symboly predstavujúce pamäťové médium často predstavujú vstupno/výstupné metódy. Aby bolo možné použiť ako odkaz na dokumentáciu, text na diagrame pre symboly reprezentujúce výstupné metódy by mal byť umiestnený vpravo nad symbolom a text pre symboly reprezentujúce vstupné metódy by mal byť umiestnený vpravo pod symbolom.

Príklad

4.1.8. Diagramy môžu používať podrobné znázornenie, ktoré je označené čiarovým symbolom pre proces alebo údaje. Symbol pruhu označuje, že podrobnejšie informácie sú dostupné inde v tej istej sade dokumentácie.

Prúžkový symbol je akýkoľvek symbol, ktorý má v hornej časti nakreslenú vodorovnú čiaru. Medzi týmto riadkom a horným riadkom symbolu je identifikátor označujúci podrobné znázornenie tohto symbolu.

Znak terminátora sa musí použiť ako prvý a posledný znak vo verbálnej reprezentácii. Prvý znak ukončenia musí obsahovať odkaz, ktorý je prítomný aj v znaku pruhu.

Symbol s pruhom

Detailný pohľad

4.2. Pravidlá pre vytváranie spojení

4.2.1. Dátové toky alebo riadiace toky v diagramoch sú znázornené ako čiary. Smer prúdenia zľava doprava a zhora nadol sa považuje za štandardný.

V prípadoch, keď je potrebná väčšia prehľadnosť v diagrame (napríklad pri vytváraní spojení), sa na čiarach používajú šípky. Ak je tok v inom než štandardnom smere, šípky by mali tento smer ukazovať.

4.2.2. V diagramoch by ste sa mali vyhnúť pretínajúcim sa čiaram. Križujúce sa čiary nemajú medzi sebou žiadnu logickú súvislosť, preto nie sú povolené zmeny smeru v križovatkách.

Príklad

4.2.3. Dve alebo viac prichádzajúcich liniek je možné spojiť do jednej výstupnej linky. Ak sa dva alebo viac riadkov zlúči do jedného riadku, miesto zlúčenia sa musí posunúť.

Príklad

4.2.4. Čiary v diagramoch by sa mali približovať k symbolu buď zľava, alebo zhora, a vychádzať buď sprava alebo zdola. Čiary by mali smerovať do stredu symbolu.

4.2.5. V prípade potreby by mali byť čiary v diagramoch prerušené, aby sa predišlo zbytočným križovatkám alebo príliš dlhým čiaram, a tiež ak diagram pozostáva z niekoľkých strán. Konektor na začiatku prerušenia sa nazýva vonkajší konektor a konektor na konci prerušenia sa nazýva vnútorný konektor.

Externý konektor

Vnútorný konektor

4.3. Špeciálne konvencie

4.3.1. Viaceré východy

4.3.1.1. Mali by sa zobraziť viaceré výstupy zo symbolu:

1) niekoľko riadkov od tohto symbolu k iným symbolom;

2) jeden riadok z daného symbolu, ktorý sa potom rozvetvuje na zodpovedajúci počet riadkov.

Príklady

4.3.1.2. Každý výstup symbolu musí byť sprevádzaný zodpovedajúcimi hodnotami podmienok, aby sa zobrazila logická cesta, ktorú predstavuje, aby boli tieto podmienky a zodpovedajúce odkazy identifikované.

Príklady

4.3.2. Opakujúce sa zobrazenie

4.3.2.1. Namiesto jedného symbolu s pridruženým textom možno použiť viacero prekrývajúcich sa symbolov, z ktorých každý obsahuje popisný text (použitie alebo generovanie viacerých pamäťových médií alebo súborov, vytváranie viacerých kópií tlačených správ alebo formátov diernych štítkov).

4.3.2.2. Ak viacero znakov predstavuje objednanú množinu, zoradenie musí byť spredu (prvý) dozadu (posledný).

4.3.2.3. Čiary môžu vstupovať alebo vychádzať z ktoréhokoľvek bodu prekrývajúcich sa symbolov, musia sa však dodržať požiadavky bodu 4.2.4. Priorita alebo sekvenčné poradie viacerých symbolov sa nemení podľa bodu, v ktorom riadok vstupuje alebo odchádza.

Príklad

5. APLIKÁCIA SYMBOLOV

Názov symbolu

Schéma údajov

Náčrt programu

Schéma fungovania systému

Schéma interakcie programu

Schéma systémových prostriedkov

Dátové symboly

Základné

Zapamätané údaje

Špecifické

Náhodný vstup do pamäťe

Sekvenčná prístupová pamäť

Úložné zariadenie s priamym prístupom

Dokument

Manuálny vstup

Papierová páska

Procesné symboly

Základné

Špecifické

Preddefinovaný proces

Manuálna operácia

Ako priradiť „kód GOST“ dokumentu

Michail Ostrogorskij, 2010

Prečo potrebujeme symboly dokumentov?

Občas dostávame otázku, ako správne priradiť k dokumentu kód, kód, číslo atď.. Povedzme si hneď, že to nie je žiadna veľká veda. Po prvé to však nie je kód alebo šifra, ale označenie, v každom prípade, ak máme v úmysle dodržiavať ESPD (GOST 19) alebo KSAS (GOST 34). Po druhé, poďme najprv pochopiť, aký význam majú zápisy dokumentov.

V dobe písanej strojom a papiera slúžili označenia dokumentov na udržiavanie archívu. Predstavte si veľkú organizáciu, ktorá si interne objednáva alebo vyvíja množstvo programov alebo automatizovaných systémov. Zhromažďuje tiež množstvo technickej dokumentácie. Aby ste sa v ňom mohli pohybovať, okrem iného musíte každému dokumentu poskytnúť jedinečný identifikátor. Domáce normy ako také navrhujú používať označenie vytvorené podľa určitých pravidelných pravidiel. Budeme o nich hovoriť.

Označenie dokumentov nepotrebuje prokurátor, nie Rostekhregulirovanie, nie vývojár programu alebo systému, ale predovšetkým zákazník. Ak váš zákazník za každú cenu požaduje, aby pre neho vytvorené dokumenty boli vybavené „kódom GOST“, môžete mu odpovedať otázkou, či vedie archív technická dokumentácia. Bohužiaľ, vo väčšine prípadov je odpoveď nie. Ak má zákazník takýto archív, tak s najväčšou pravdepodobnosťou bude skôr elektronický ako papierový. Jednoznačné identifikátory sa v elektronických archívoch zvyčajne prideľujú dokumentom automaticky.

Priraďovanie oficiálnych označení dokumentom je dnes do značnej miery nezmyselné a predstavuje „magický rituál“. Čo ak zákazník stále trvá na jeho realizácii? Samozrejme, urobte to.

Označenia dokumentov na automatizovaných systémoch

Štruktúra označenia systémového dokumentu v súlade s GOST 34.201-89 je uvedená nižšie. Vysvetlenie častí označenia je uvedené v tabuľke.

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

Časť označenia Význam
A kód organizácie vývojárov systému. GOST 34.201-89 hovorí: „Kód vývojárskej organizácie sa prideľuje v súlade s celoúniovým klasifikátorom podnikov, inštitúcií a organizácií (OKPO) alebo podľa pravidiel stanovených normatívnou a technickou dokumentáciou v odvetví.“ Zo známych dôvodov dnes nemáme celoúnijný klasifikátor, ale existuje celoruský klasifikátor podnikov a organizácií (OKPO). Kód OKPO je súčasťou oficiálnych údajov organizácie a vaše účtovné oddelenie by ho malo poznať. Ak sa vám naozaj nechce volať do účtovného oddelenia, skúste si svoju firmu vyhľadať v online adresári, no majte na pamäti, že nápis na dverách kancelárie sa nemusí vždy zhodovať s názvom právnickej osoby. Okrem toho podľa GOST 2.201-80 musí byť vývojovej organizácii pridelený štvorpísmenový kód na generovanie označení pre konštrukčné dokumenty. Centralizované prideľovanie kódov vykonávajú oprávnené organizácie, napríklad FSUE Standardinform a OJSC Standardelectro. Toto je skutočná prax, niektoré spoločnosti dokonca zverejňujú na svojich webových stránkach dôkazy o pridelení kódu
B kód klasifikačnej charakteristiky typu systému alebo jeho časti. Podľa GOST 34.201-89 by sa tento kód mal vybrať z klasifikátora produktov All-Union, ktorý bol teraz nahradený klasifikátorom produktov All-Russian Product Classifier (OKP). Na internete bola publikovaná mnohokrát, môžete ju ľahko nájsť pomocou tu uvedeného odkazu alebo pomocou vyhľadávača. Tento triedič obsahuje všetky možné produkty od kráčajúcich rýpadiel až po kolíky. Časť klasifikátora venovaná automatizované systémy, začína riadkom 425000 Softvérové ​​a hardvérové ​​systémy pre automatizované systémy. Možno má klasifikátor iné reťazce, ktoré sú pre vás vhodnejšie na základe špecifík systému. Skúste ich nájsť pomocou obvyklej funkcie vyhľadávania v texte stránky. Ako alternatívu k OKP norma navrhuje použiť celozväzový klasifikátor subsystémov a komplexov úloh ACS (OKPKZ). Pokiaľ vieme, bol zrušený, ale nebol nahradený ničím iným, takže tento odkaz je zapísaný do histórie
CCC registračné číslo automatizovaného systému alebo jeho časti. Predpokladá sa, že vývojár zorganizoval evidenciu vyrobených automatizovaných systémov a pridelil im registračné čísla. Ak to vaša spoločnosť neakceptuje, nemôžete plne vyhovieť požiadavkám CCAS. Začnite nový život, veďte si denník uvoľnených systémov. Číslovanie systémov sa vykonáva pre každý typ (t. j. kód klasifikačnej charakteristiky, pozri vyššie) systémov samostatne. Norma nehovorí, čo robiť pre organizáciu, ktorej sa podarilo vydať 1000 automatizovaných systémov rovnakého typu.
DD kód dokumentu (presnejšie typ dokumentu) podľa GOST 34.201-89. Napríklad kód používateľskej príručky je I3(a-tri), a programový kód a testovacie metódy sú POPOLUDNIE.
E.E. číslo dokladu jedného mena. Povedzme, že vo svojej dokumentácii máte tri procesné inštrukcie pre tri rôzne funkčné roly. V tomto prípade budú mať čísla 01, 02 A 03 . Pravidlá pre prideľovanie týchto čísel (podľa dátumu vydania dokumentu, podľa mena v abecednom poradí alebo iným spôsobom) nie sú určené. Hlavná vec je, že čísla idú postupne od jedného. Ak súbor obsahuje iba jeden dokument určitého typu, napríklad jednu vysvetlivku k technickému projektu, číslo sa nepridelí a príslušná pozícia v označení sa preskočí.
F číslo revízie dokumentu. Hovoríme o tých vydaniach, ktoré oficiálne prevediete na zákazníka a on ich oficiálne prijme a schvaľuje. Ak vám zákazník počas procesu kontroly a schvaľovania dokumentu opakovane posielal pripomienky a vy ste odpovedali opraveným súborom, nehovoríme o nových vydaniach dokumentu, ide o pracovné materiály a nič viac. Nové vydanie sa uskutoční, ak to zákazník schváli nová možnosť dokument pri zachovaní predchádzajúceho a v zásade možno v niektorých situáciách použiť oba. V opačnom prípade môže byť zastaraná možnosť zrušená a navždy zabudnutá. Vydaniam sú priradené čísla, počnúc druhým. V prvom vydaní je zodpovedajúca pozícia v označení vynechaná
G číslo časti dokumentu. Dokument možno fyzicky rozdeliť na niekoľko častí. Zvyčajne sa to robí, aby sa dokument ľahšie čítal alebo zviazal. Ak dokument nie je rozdelený na časti, číslo sa nepridelí a príslušná pozícia v označení sa preskočí
M v roku 1989 elektronické dokumenty boli stále novým a nezvyčajným fenoménom. Typickým dokumentom bol list alebo stoh listov papiera so schvaľovacími a schvaľovacími podpismi. Samostatnú úvahu si vyžadovala aj skutočnosť, že disketa alebo magnetická páska s napísaným textom môže byť aj dokumentom. Preto bol list pridaný k označeniu takýchto dokumentov M. Napodiv, táto prax nie je neopodstatnená ani teraz, keďže u nás sa v toku oficiálnych dokumentov objavujú papierové dokumenty s originálnymi podpismi kompetentných osôb a „mokrými“ pečaťami organizácií. Preto napríklad technologický pokyn, za nedodržanie ktorého môže byť zamestnanec oficiálne potrestaný, musí byť realizovaný presne v takejto podobe. Ale ak od nás zákazník požaduje napríklad text programu (dokument, ktorý zabezpečuje ESPD), stále mu vieme poskytnúť nie kamión výpisov, ale CD. Označenie takéhoto dokumentu musí končiť písm M, ktorý je oddelený od predchádzajúcej časti bodkou (nie spojovníkom!)

Ako príklad priradíme označenie technologického návodu pre užívateľa tejto stránky. Stránku budeme považovať za automatizovaný systém, ktorý sme si sami vyvinuli a toto bola naša prvá skúsenosť s vývojom systémov tohto typu. Používateľa budeme považovať za zamestnanca spoločnosti Philosoft, ktorý na stránke publikuje články. Súhlasme aj s tým, že osoba zodpovedná za zverejnenie nie je jedinou funkčnou úlohou. Máme aj zodpovednú osobu za umiestňovanie reklamných pútačov, pre ktorú sú spísané vlastné technologické pokyny. Platí prvé vydanie technologického návodu, dokument nie je rozdelený na časti, existuje vo forme papierového originálu s podpismi a pečaťami. Berúc do úvahy vyššie uvedené okolnosti, označenie je nasledovné:

63755082,425750,001.I2.01, Kde

63755082 - kód spoločnosti Philosoft LLC podľa OKPO.

425750 - riadkový kód Softvérové ​​a hardvérové ​​systémy pre automatizáciu spracovania informácií v obchode, logistike podľa OKP. Autor článku si prezrel OKP, zamyslel sa a rozhodol túto charakteristiku vyhovuje našej stránke lepšie ako všetky ostatné, ktoré tam ponúkajú. Možno sa mýli.

001 je registračné číslo automatizovaného systému tohto typu v našej internej evidencii (predpokladajme, že ho vedieme).

I2 - kód technologických pokynov podľa GOST 34.201-89.

01 - počet technologických pokynov v súbore technickej dokumentácie pre stavenisko. Pripomeňme, že pre manažéra je tu ešte jeden reklamné bannery, jej číslo je 02.

Označenie technických špecifikácií pre automatizovaný systém

V ustanovení 3.2 GOST 34.602-89 je fráza, ktorá uvádza určitý kód TK: „Čísla hárkov (strán) sa umiestňujú počnúc prvým hárkom, po titulnej strane, v hornej časti hárku (nad textom, v strede) po uvedení kódu TK na AC.“ GOST 34.201-89 zároveň poskytuje kódy pre dokumenty vyvinuté vo fázach počnúc predbežným návrhom, ale neexistuje žiadny kód pre technické špecifikácie, čo je trochu mätúce.

Pri generovaní kódu technickej špecifikácie pre reproduktory môžete vziať do úvahy bod 3.5. GOST 34.602-89, ktorý hovorí: "Ak je to nevyhnutné, titulná strana Na JE je povolené umiestňovať kódy zavedené v priemysle, napr.: bezpečnostná klasifikácia, pracovný kód, evidenčné číslo TK a pod.“ a prideľovať kód svojvoľne s odvolaním sa na skutočnosť, že je to obvyklé v odvetví alebo stanovené vedeckou a technickou dokumentáciou konkrétneho podniku. Okrem toho si môžete pamätať, že podľa GOST 24.101-80 mala technická špecifikácia kód 2A a priraďte dokumentu označenie podľa vyššie opísanej schémy. Ale vo všeobecnosti to všetko už pripomína scholastický výpočet počtu diablov na hrote ihly.

Symboly programových dokumentov

Štruktúra označenia programového dokumentu v súlade s GOST 19.103-77 je uvedená nižšie. Vysvetlenie častí označenia je uvedené v tabuľke. Číslo revízie, číslo dokumentu a číslo časti dokumentu sú tvorené rovnakým spôsobom ako pri systémových dokumentoch (z historického hľadiska je to naopak, ale prosíme čitateľa, aby nám tento anachronizmus odpustil).

A.B.CCCCC-DD EE FF-G

Časť označenia Význam
A kód krajiny. V súčasnosti je rozumné špecifikovať dvojpísmenový kód podľa normy ISO 3166-1: RU pre Rusko, KZ pre Kazachstan atď.
B kód organizácie vývojára. Analogicky so systémovými dokumentmi môžete zadať kód OKPO
CCCCC registračné číslo programu. Podľa GOST 19.103-77 by mala byť pridelená "v súlade s All-Union Classification of Programs, schváleným Gosstandartom predpísaným spôsobom." Tejto požiadavke dnes nevieme vyhovieť. Venujte pozornosť roku schválenia normy: 1977. Odvtedy sa v našich životoch veľa zmenilo
DD číslo revízie dokumentu
E.E. kód typu dokumentu v súlade s GOST 19.101-77
FF číslo dokladu tohto typu
G číslo časti dokumentu

Počiatočná časť označenia, A.B.CCCC-DD, slúži ako označenie pre samotný program a zároveň pre hlavný dokument s ním spojený, špecifikáciu.

Označenia dizajnových dokumentov

Akýkoľvek program alebo automatizovaný systém môže byť považovaný za produkt a dokumentovaný na všeobecnom základe, riadený ESKD (GOST 2). Rovnaký súbor noriem by sa mal používať pri dokumentácii technických prostriedkov, ako sú servery, pracovné stanice, všetky druhy špecializovaných zariadení atď. Pravidlá pre prideľovanie označení projektovým dokumentom stanovuje GOST 2.201-80. Tu sa zdržíme prerozprávania tohto dokumentu, ale nepochybujeme, že teraz ho čitateľ ľahko nájde a zvládne.

Označenia schvaľovacieho listu

Ak je dokument vybavený schvaľovacím hárkom, tento musí mať svoje vlastné označenie. Vytvára sa podľa základného pravidla: k označeniu dokumentu by sa mal pridať kód LU, oddelené pomlčkou, napr. 63755082.425750.001.I2.01-LU.

O užitočnosti notácie s opatrným optimizmom

Pozorný čitateľ si všimol, že ak by všetky organizácie starostlivo dodržiavali takéto pravidlá, označenia dokumentov by boli v rámci krajiny jedinečné. Potom by bolo možné povedzme zriadiť národný katalóg technickej dokumentácie, prostredníctvom ktorého by si každý inžinier mohol vyžiadať dokument, ktorý potrebuje. To by zrejme uľahčilo integráciu automatizovaných systémov rôznych oddelení, no dnes práve pre ich izolovanosť zažívame množstvo všelijakých byrokratických nepríjemností. Napríklad dôchodcovia sú nútení zobrať si potvrdenie z matriky, že ešte žijú a osobne ho doručiť do Sociálnej poisťovne, až potom dostanú najrôznejšie príspevky a dávky. Vynára sa otázka: prečo by automatizované systémy matriky a sociálneho zabezpečenia nemohli pracovať s jedným súborom údajov? Na druhej strane, skúsený čitateľ si všimne, že tieto argumenty hrešia utopizmom, a bude mať pravdu.

Je možné, že označenia dokumentov môžu byť aj dnes užitočné pri vývoji a schvaľovaní veľkých súborov technickej dokumentácie. V korešpondencii medzi sebou av rôznych pracovných materiáloch musia účastníci projektu často uvádzať odkazy na dokumenty, uvádzať ich alebo ich uvádzať v rôznych kontextoch. Keď sa počet dokumentov v projekte zvýši, stáva sa nepohodlným odkazovať na ne menom. V priebehu projektu môžu byť mená upravované, navyše si ich ľudia často naspamäť označujú, skracujú a robia chyby, čo prirodzene vedie k zmätku. Zákazník napríklad nahlási chybu v jednom dokumente, no vývojár jej nerozumie a robí zbytočné opravy v inom s podobným názvom. Dúfame, že používanie notácií pomôže zbaviť sa takýchto problémov.

P R Í V A R S T V E N Y S T A N D A R T S O Y W A S S R

Jednotný systém programovej dokumentácie

GOST 19.003-80

Na oplátku

GOST 19428-74

ALGORITMICKÉ DIAGRAMY A PROGRAMOVACIE OZNAČENIE PODMIENKOVÁ GRAFIKA

Jednotný systém pre dokumentáciu programu.

Symboly grafického vývojového diagramu.

Výnosom Štátneho výboru pre normy ZSSR z 24. apríla 1980 č. 1867 bol stanovený dátum zavedenia

od 01.07.1981

Táto norma sa vzťahuje na podmienené grafické symboly(symboly) v diagramoch algoritmov a programov, zobrazujúcich základné operácie procesu spracovania dát a programovania pre softvérové ​​systémy počítačov, komplexy a systémy bez ohľadu na ich účel a rozsah.

Norma sa nevzťahuje na položky a symboly umiestnené v rámci symbolu alebo vedľa neho, ktoré slúžia na objasnenie funkcií, ktoré vykonáva.

Norma stanovuje zoznam, názov, tvar, veľkosť symbolov a funkcie zobrazené pomocou symbolov.

Norma je v súlade s ISO 1028-73, pokiaľ ide o označenie symbolov

1. ZOZNAM, NÁZOV, OZNAČENIE SYMBOLOV A ICH ZOBRAZOVANÝCH FUNKCIÍ

1.1. Zoznam, názov, označenie a veľkosť povinných symbolov a funkcií, ktoré zobrazujú v algoritme a programe na spracovanie údajov, musia zodpovedať tým, ktoré sú uvedené v tabuľke. 1.

Stôl 1.

názov

Označenie a rozmery v mm

Funkcia
1. Proces

Vykonávanie operácií alebo skupiny operácií, ktoré menia hodnotu, formu prezentácie alebo umiestnenie údajov
2. Riešenie

Výber smeru vykonávania algoritmu alebo programu v závislosti od niektorých premenných podmienok
3. Modifikácia

Vykonávanie operácií, ktoré menia príkazy alebo skupiny príkazov, ktoré menia program
4. Preddefinovaný proces Použitie predtým vytvorených a samostatne popísaných algoritmov alebo programov
5. Manuálna prevádzka

Autonómny proces vykonávaný ručne alebo pomocou neautomatizovaných prostriedkov
6. Pomocná prevádzka Autonómny proces vykonávaný zariadením, ktoré nie je priamo riadené procesorom
7. Zlúčenie Spojenie dvoch alebo viacerých sád do jednej sady
8. Výber

Odstránenie jednej alebo viacerých sád z jednej sady
9. Zoskupovanie

Kombinovanie dvoch alebo viacerých sád pri výbere niekoľkých ďalších sád
10. Triedenie

Objednávanie súpravy podľa daných vlastností
11. Manuálne zadávanie

Manuálne zadávanie údajov pomocou neautonómnych zariadení s klávesnicou, sadou prepínačov a tlačidiel
12. I/O

Prevod dát do formy vhodnej na spracovanie (vstup) alebo zobrazenie výsledkov spracovania (výstup)
13. Neautonómna pamäť

Vstup/výstup dát pri použití pamäťového zariadenia riadeného priamo procesorom
14. Offline pamäť Vstup/výstup dát pri použití úložného zariadenia, ktoré nie je priamo riadené procesorom
15. Dokument

Vstup-výstup dát, ktorých nosičom je papier
16. Dierny štítok

Vstup-výstup dát, ktorých nosičom je dierny štítok
17. Balíček diernych štítkov

Zobrazenie sady diernych štítkov
18. Súbor

Reprezentácia údajov organizovaná na základe spoločných charakteristík, ktoré súhrnne charakterizujú určitý objekt spracovania údajov. Symbol sa používa v kombinácii so symbolmi špecifických pamäťových médií, ktoré vykonávajú I/O funkcie
19. Dierna páska

Vstup-výstup dát, ktorých nosičom je dierna páska
20. Magnetická páska Vstup-výstup dát, ktorých nosičom je magnetická páska
21. Magnetický bubon

Vstup-výstup dát, ktorých nosičom je magnetický bubon
22. Magnetický disk

Vstup-výstup dát, ktorých nosičom je magnetický disk
23. RAM

Vstup-výstup dát, ktorých nosičom je magnetické jadro
24. Displej Vstup/výstup údajov, ak zariadenie priamo pripojené k procesu reprodukuje údaje a umožňuje operátorovi počítača vykonávať zmeny počas ich spracovania
25. Komunikačný kanál

Prenos dát cez komunikačné kanály
26. Prietoková čiara

Určenie postupnosti medzi znakmi
27. Paralelné akcie

Spustenie alebo ukončenie dvoch alebo viacerých súčasných operácií
28. Konektor

Označenie spojenia medzi prerušovanými prietokovými čiarami, spojovacie symboly
29. Štart – stop

Spustenie, ukončenie, prerušenie spracovania údajov alebo vykonávania programu
30. Komentujte

Vzťah medzi schematickým prvkom a vysvetlením

1.2. Zoznam, názov, označenie a veľkosť odporúčaných symbolov a funkcií, ktoré zobrazujú v algoritme a programe na spracovanie údajov, musia zodpovedať tým, ktoré sú uvedené v tabuľke. 2.

tabuľka 2

názov

Označenie a rozmery v mm

Funkcia
1. Konektor medzistránok Označenie spojenia medzi odpojenými časťami diagramov algoritmov a programami umiestnenými na rôznych hárkoch
2. Magnetická karta

Vstup-výstup dát, ktorých nosičom je magnetická karta
3. Príručný dokument

Vytvorenie dokumentu ako výsledok manuálnych operácií
4. Archív

Uloženie sady organizovaných úložných médií na opätovné použitie
5. Offline spracovanie Transformácia zdrojových údajov ako výsledok offline operácií
6. Dekódovanie

Čítanie z pamäťového média, opätovné kódovanie a tlač na rovnaké alebo iné pamäťové médium v ​​dôsledku offline operácie
7. Kódovanie

Aplikácia zakódovaných informácií na médium ako výsledok autonómnej operácie
8. Kopírovať

V.E. Karpov

Tento dokument obsahuje Stručný opisŠtandardy ESPD, ktorých znalosť je potrebná pre študentov na absolvovanie ročníkových prác a projektov súvisiacich s tvorbou softvérových systémov. Okrem toho môže byť užitočný aj z hľadiska zvyšovania kvality softvérovej dokumentácie vo všeobecnosti.

TECHNICKÉ ŠPECIFIKÁCIE (GOST 19.201-78)

1. Všeobecné ustanovenia

ETAPY VÝVOJA (GOST 19.102 – 77)

POPIS PROGRAMU (GOST 19,402-78)

TEXT PROGRAMU (GOST 19 401-78)

PROGRAM A METODIKA TESTOV (GOST 19,301-79)

POŽIADAVKY NA TLAČENÉ SOFTVÉROVÉ DOKUMENTY (GOST 19 106 – 78)

Štandardizácia v oblasti softvérovej dokumentácie

Ako sa pohnúť vpred

Príprava dokumentácie pre softvér(PS) v súlade s existujúcimi GOST

2. Všeobecná charakteristika stavu

2.3. Štátne normy Ruskej federácie (GOST R)

2.4. Medzinárodná norma ISO/IEC 12207: 1995-08-01

Azda najnepríjemnejšou a najťažšou etapou programátorskej práce je tvorba programovej dokumentácie. Bohužiaľ, zvyčajne sa to buď vôbec neučí, alebo v najlepšom prípade nevenujú náležitú pozornosť kvalite prijatých dokumentov. Ovládanie tohto umenia je však často jedným z najdôležitejších faktorov určujúcich kvalitu programátora.

Po prvé, schopnosť vytvárať programovú dokumentáciu určuje profesionálnu úroveň programátora. Zákazník sa nebude ponoriť do zložitosti a funkcií ani toho najúžasnejšieho programu. Zákazník si najskôr prečíta dokumentáciu. Veľkú úlohu v tom zohráva aj psychologický faktor. Najmä bývalá sovietska škola programovania bola (a teraz je) cenená po celom svete. Moderní domáci programátori prestali byť citovaní. Trieda nie je rovnaká. V dnešnej dobe sa programy už nepíšu, ale kompilujú (a to sú „dva veľké rozdiely“). Balík softvérovej dokumentácie (ďalej len PD) vytvorený v „klasickom“ štýle tak urobí na vášho zákazníka alebo zamestnávateľa ten najpriaznivejší dojem. Navyše, ak sa autor PD vyhýba frázam ako „kliknite na posuvník...“, „skrutkujte“ atď. Žiaľ, takéto žargónové klábosenie zvyčajne skrýva buď nedostatok myšlienok, alebo úplnú prázdnotu (na autora nezmazateľne zapôsobil príbeh jedného z jeho známych o istom „hráčovi“, ktorý sa buď s niekým „kecal“, alebo sa venoval „moderovaniu“. “ Alebo niečo také.). Jazyk PD je akýmsi byrokratickým, veľmi konzervatívnym jazykom. Má to svoje zvláštne čaro. Súhlasíte s tým, že pojmy pevný disk, plochý disk, ručný manipulátor ako „myš“ (alebo „buchta“, ako bolo napísané v jednom zo starých PD balíkov) znejú úplne inak ako zodpovedajúci „skrutka“, „ flop“ a jednoducho „myš“. Mimochodom, veci už dospeli k tomu, že sa vraj objavila aj špeciálna špecialita - technický spisovateľ, t.j. človek, ktorý vie vytvárať softvérovú dokumentáciu.

Po druhé, dobre navrhnutý (presnejšie vytvorený) balík PD vás ušetrí od mnohých problémov. Predovšetkým sa môžete zbaviť nepríjemných otázok a nepodložených nárokov jednoduchým odkázaním používateľa na dokumentáciu. Týka sa to predovšetkým najdôležitejšieho dokumentu – zadávacích podmienok. Budeme o tom hovoriť nižšie, ale teraz vám môžeme pripomenúť niekoľkomiliónový súdny spor proti IBM. Túto žalobu podalo jedno veľké vydavateľstvo, nespokojné s kvalitou VT a softvéru. IBM spor vyhrala. A vyhrala len preto, že predložila Zadanie podpísané oboma stranami. Stalo sa to už dávno, ešte v 70. rokoch, ale to nič nemení na podstate veci.

Ešte jedna vec. Je dôležité vytvoriť prvý balík PD. To bude stačiť na zostavenie všetkých nasledujúcich na jeho základe a použije sa ako model alebo šablóna. Musí sa to však robiť veľmi efektívne. Vo voľnom čase. Veľmi dôkladné.

Najprv sa musíte vyzbrojiť GOST. GOST definuje všetko. Zahŕňa najmä Unified System of Program Documentation (USPD), ktorý nás zaujíma. Možno najťažšie je získať samotný GOST. GOST by mala byť iba v tlačenej originálnej forme. Predávajú sa (aspoň to tak bolo predtým) v špeciálnych obchodoch. Ak chcete získať štandardy v oblasti dokumentácie, môžete sa obrátiť najmä na tieto organizácie:

  • IPK "Publishing Standards", Územné oddelenie distribúcie NTD (obchod "Standards"), 17961, Moskva, ul. Donskaya, 8, tel. 236-50-34, 237-00-02, fax/tel. 236-34-48 (pokiaľ ide o GOST a GOST R).
  • VNIIKI Gosstandart Ruska (čitáreň), 103001, Moskva, Granatny per. č.4, tel. 290-50-94 (týkajúce sa medzinárodných, zahraničných noriem a inej vedeckej a technickej dokumentácie).

A žiadne citácie alebo sekundárne zdroje. GOST je zákon. A ešte k tomu žiadny internet (predstavte si, že súd vynesie rozsudok pomocou výtlačku Trestného zákona stiahnutého z nejakej webovej stránky). Neverte nikomu inému ako originálu. Autor sa však potom bude musieť uchýliť k citácii ESPD, čím sa zbaví všetkej zodpovednosti.

Začnime všeobecnými ustanoveniami o Jednotnom systéme programovej dokumentácie (ktoré sú tiež definované v zodpovedajúcej norme GOST 19.001-77).

Jednotný systém programovej dokumentácie je súborom štátnych noriem, ktoré stanovujú vzájomne prepojené pravidlá pre tvorbu, realizáciu a obeh programov a programovej dokumentácie.

Normy ESPD definujú všeobecné ustanovenia a základné normy, pravidlá pre vyhotovenie vývojovej dokumentácie, pravidlá pre vyhotovenie výrobnej dokumentácie, pravidlá pre vyhotovenie dokumentácie údržby, pravidlá pre vyhotovenie prevádzkovej dokumentácie, pravidlá pre nakladanie s programovou dokumentáciou a iné normy. ESPD zahŕňa:

  • základné a organizačné a metodické normy;
  • štandardy definujúce formy a obsah programových dokumentov používaných pri spracovaní údajov;
  • štandardy, ktoré zabezpečujú automatizáciu tvorby programových dokumentov.

Vo všeobecnosti je zoznam dokumentov ESPD veľmi rozsiahly. Zahŕňa najmä tieto GOST:

  • GOST 19.001-77 ESPD. Všeobecné ustanovenia.
  • GOST 19.101-77 ESPD. Druhy programov a programové dokumenty (november 1987 znovu vydaný s dodatkami).
  • GOST 19.102-77 ESPD. Vývojové štádiá.
  • GOST 19.103-77 ESPD. Označenie programov a programových dokumentov.
  • GOST 19.104-78 ESPD. Základné nápisy.
  • GOST 19.105-78 ESPD. Všeobecné požiadavky na programové dokumenty.
  • GOST 19.106-78 ESPD. Požiadavky na tlačené programové dokumenty.
  • GOST 19.201-78 ESPD. Technická úloha. Požiadavky na obsah a dizajn.
  • GOST 19.202-78 ESPD. Špecifikácia. Požiadavky na obsah a dizajn.
  • GOST 19.301-79 ESPD. Testovací program a metodika.
  • GOST 19.401-78 ESPD. Text programu. Požiadavky na obsah a dizajn.
  • GOST 19.402-78 ESPD. Popis programu.
  • GOST 19.404-79 ESPD. Vysvetľujúca poznámka. Požiadavky na obsah a dizajn.
  • GOST 19.501-78 ESPD. Formulár. Požiadavky na obsah a dizajn.
  • GOST 19.502-78 ESPD. Popis aplikácie. Požiadavky na obsah a dizajn.
  • GOST 19.503-79 ESPD. Príručka systémového programátora. Požiadavky na obsah a dizajn.
  • GOST 19.504-79 ESPD. Príručka programátora.
  • GOST 19.505-79 ESPD. Návod na obsluhu.
  • GOST 19.506-79 ESPD. Popis jazyka.
  • GOST 19.508-79 ESPD. Sprievodca údržbu. Požiadavky na obsah a dizajn.
  • GOST 19.604-78 ESPD. Pravidlá pre vykonávanie zmien v programových dokumentoch vykonávaných v tlači.
  • GOST 19.701-90 ESPD. Schémy algoritmov, programov, dát a systémov. Konvencie a pravidlá vykonávania.
  • GOST 19.781-90. Softvér pre systémy spracovania informácií.

Ako vidíte, hlavná časť komplexu ESPD bola vyvinutá v 70. a 80. rokoch. Niektoré z týchto noriem sú zastarané a nie sú bez niektorých nedostatkov. Po prvé, niektoré neodrážajú moderné tendencie návrh programov a programová dokumentácia, po druhé, tieto štandardy obsahujú viacnásobnú duplikáciu fragmentov programovej dokumentácie. Napriek tomu, pre nedostatok niečoho lepšieho, sa na ne musíme zamerať.

Normy ESPD teda zefektívňujú proces dokumentácie softvérových systémov. Po prvé, zloženie programových dokumentov, ktoré stanovujú normy ESPD, nie je vôbec také „rigidné“, ako by sa mohlo zdať: normy umožňujú zahrnúť dokumentáciu o softvérový systém(PS) dodatočné typy a po druhé, na základe požiadaviek zákazníka sú prípustné niektoré zmeny v štruktúre aj obsahu zavedených typov PD. Okrem toho je možné poznamenať, že normy ESPD (a to platí pre všetky ostatné normy v oblasti PS - GOST 34, medzinárodná norma ISO/IEC atď.) majú poradný charakter. Faktom je, že v súlade so zákonom Ruskej federácie „o štandardizácii“ sa tieto normy stávajú povinnými na zmluvnom základe – t.j. pri odvolaní sa na ne v zmluve o vývoji (dodávke) softvéru.

Predtým, ako začneme uvažovať o pravidlách zostavovania softvérovej dokumentácie, je potrebné urobiť nasledujúcu poznámku. Odporúča sa pred každým dokumentom uviesť úvod. Úvod hovorí všeobecne. O relevantnosti, nevyhnutnosti a pod. Cieľom interpreta je ukázať význam a nevyhnutnosť tejto práce. Začiatok je zvyčajne štandardný: „Množstvo súčasných systémov... ...otvára skutočné vyhliadky v...“, atď. Zvyčajne sa sem vkladajú citáty z prejavov rôznych osobností (toto je čisto psychologický aspekt): "...ako bolo povedané na minulom pléne, kongrese, konferencii atď.). Môžete začať tým, že "...Dnes, v ére radikálnych sociálno-ekonomických transformácií...atď." Všeobecne platí, že hlavná vec Nepreháňajte to tu.

A ďalej. Pri popise svojho produktu si vývojár často zamieňa pojmy komponent a komplex. toto - odlišné typy programy. Komponent je definovaný ako „program považovaný za jeden celok, ktorý vykonáva úplnú funkciu a používa sa nezávisle alebo ako súčasť komplexu“ a komplex je „program pozostávajúci z dvoch alebo viacerých komponentov a (alebo) komplexov, ktoré vykonávajú vzájomne súvisiace funkcie. funkcie a používa sa samostatne alebo ako súčasť iného komplexu."

Podľa GOST táto norma (znovu vydaná v novembri 1987) stanovuje postup konštrukcie a prípravy technických špecifikácií pre vývoj programu alebo softvérového produktu pre počítače, komplexy a systémy bez ohľadu na ich účel a rozsah.

Pri jej vytváraní musíte byť mimoriadne opatrní a opatrní, pretože... O úspechu celého diela často rozhoduje zručne (a kompetentne) vypracovaná technická špecifikácia. Práve technické špecifikácie sú dohodnuté so zákazníkom, ktorý sa zvyčajne snaží zaviesť čo najviac protichodných a nafúknutých požiadaviek. Úlohou Exekútora je, naopak, uľahčiť mu život. Ale potom, čo boli podpisy umiestnené na oboch stranách, je príliš neskoro na to, aby ste niečo prehrali.

Zadávacie podmienky sa vypracúvajú na hárkoch formátu A4 a/alebo A3 spravidla bez vypĺňania polí hárku. Čísla hárkov (strán) sú umiestnené v hornej časti hárku nad textom.

Na vykonanie zmien a doplnkov technického zázemia v ďalších fázach vývoja programu alebo softvérového produktu sa vydáva jeho dodatok. Koordinácia a schvaľovanie dodatku k Technické špecifikácie vykonávané v rovnakom poradí, ako je stanovené pre technické špecifikácie.

Zadávacie podmienky musia obsahovať tieto oddiely:

  • názov a rozsah aplikácie;
  • základ pre rozvoj;
  • účel rozvoja;
  • technické požiadavky na program alebo softvérový produkt;
  • etapy a etapy vývoja;
  • kontrolný a akceptačný postup;
  • aplikácie.

V závislosti od charakteristík programu alebo softvérového produktu je možné spresniť obsah sekcií, zaviesť nové sekcie, prípadne jednotlivé sekcie kombinovať.

V kapitole Názov a rozsah uveďte meno, stručný popis rozsah použitia programu alebo softvérového produktu a predmet, v ktorom sa program alebo softvérový produkt používa.

V kapitole Základ pre rozvoj musí byť uvedené:

  • dokument(y), na základe ktorých sa vývoj vykonáva;
  • organizácia, ktorá schválila tento dokument, a dátum jeho schválenia;
  • meno a (alebo) symbol rozvojové témy.

Vo vzťahu k špecifikám vzdelávacieho procesu môže byť podkladom zadanie pre návrh kurzu, objednávka inštitútu zo dňa __.__. pre N ___., zmluva __.__. pre N ___. , a tak ďalej.

V kapitole Účel rozvoja Musí byť uvedený funkčný a prevádzkový účel programu alebo softvérového produktu. Tu sa môžete obmedziť na jednu alebo dve frázy. Hlavná vec je jasne definovať, na čo je tento program určený.

Napríklad: Program je jadrom automatizovanej pracovnej stanice (AWS) pre vývojárov kontinuálnych lineárnych automatických riadiacich systémov (ACS), ktoré umožňujú užívateľovi riešiť problémy analýzy jednoduchých modelov.

kapitola Technické požiadavky na program alebo softvérový produkt by mala obsahovať nasledujúce podsekcie:

  • požiadavky na funkčné charakteristiky;
  • požiadavky na spoľahlivosť;
  • podmienky používania;
  • požiadavky na zloženie a parametre technické prostriedky;
  • požiadavky na informácie a kompatibilitu softvéru;
  • požiadavky na označovanie a balenie;
  • požiadavky na prepravu a skladovanie;
  • špeciálne požiadavky.

Inými slovami, tu začínajú špecifiká. Popisuje, čo by mal program robiť a ako by mal vyzerať.

Požiadavky na funkčné vlastnosti. Tu by sa mali uviesť požiadavky na skladbu vykonávaných funkcií, organizáciu vstupných a výstupných údajov, charakteristiky časovania atď.

Napríklad: Program by mal umožniť ... vypočítať ... postaviť ... vytvoriť ...

Počiatočné údaje: textový súbor s daným...

Výstupné dáta: grafické a textové informácie - výsledky analýzy systému...; textové súbory - hlásenia o ... diagnostike stavu systému a hlásenia o všetkých chybách, ktoré sa vyskytli.

Požiadavky na spoľahlivosť. Musia byť špecifikované požiadavky na zabezpečenie spoľahlivej prevádzky (zabezpečenie stabilnej prevádzky, sledovanie vstupných a výstupných informácií, doba obnovy po poruche a pod.).

Tu je ťažké niečo „uhádnuť“. Najlepším prípadom je, že váš program pracuje iba s absolútne správnymi údajmi. Zákazník s tým zvyčajne nesúhlasí, ale môžete to skúsiť.

Napríklad: Program musí pracovať s danou rozšírenou maticou incidentov študovaného grafu v súlade s operačným algoritmom, generovať chybové hlásenia, keď sú počiatočné údaje nesprávne špecifikované, a podporovať interaktívny režim v rámci možností poskytnutých používateľovi.

Podmienky používania. Musia byť uvedené prevádzkové podmienky (teplota okolia, relatívna vlhkosť vzduchu a pod. pri vybraných typoch pamäťových médií), pri ktorých je potrebné zabezpečiť špecifikované vlastnosti, ako aj druh obsluhy, požadovaný počet a kvalifikácia personálu.

S týmto bodom zvyčajne nie sú žiadne ťažkosti. Žiaľ, klauzula o profesionalite užívateľa zo strany zákazníka je nevyhnutne implicitná. To je, samozrejme, ďalší dôvod, prečo nájsť chybu vo svojom programe. Tu sa však môžeme obmedziť na frázy ako „Prevádzkové podmienky programu sa zhodujú s prevádzkovými podmienkami IBM PC a kompatibilných PC“, „Program by mal byť navrhnutý pre neprofesionálneho používateľa.“ a tak ďalej.

Požiadavky na skladbu a parametre technických prostriedkov. Uveďte požadované zloženie technických prostriedkov s uvedením ich technických vlastností.

Tu ide hlavne o to, aby na jednu stranu nič nezabudli a všetko zabezpečili (inak tam vkĺzli nejaké IBM PC/XT s monochromatickým displejom a bez myši) a na druhej strane nezabudli. preháňať to so zvýšenými požiadavkami, inak si Objednávateľ nájde flexibilnejšieho Dodávateľa.

Napríklad: Musíte mať IBM PC - kompatibilný PC s grafický adaptér EGA (VGA). Nevyhnutné miesto na disku- aspoň 600 KB, voľné miesto Náhodný vstup do pamäťe- minimálne 400 kB. Je žiaduce mať ovládač EMS a manipulátor typu myši.

Požiadavky na informácie a kompatibilitu softvéru. Funkcie sú rovnaké ako v predchádzajúcom odseku. Tu by mali byť špecifikované požiadavky na informačné štruktúry na vstupe a výstupe a metódy riešenia, zdrojové kódy, programovacie jazyky. V prípade potreby sa musí zabezpečiť ochrana informácií a programov.

Napríklad: Program musí pracovať autonómne pod OS MS DOS verzie nie nižšej ako 3.3. Základným programovacím jazykom je Turbo Pascal 6.0.

Požiadavky na označovanie a balenie a požiadavky na prepravu a skladovanie sú dosť exotické. IN všeobecný prípad tu uveďte požiadavky na označovanie softvérového produktu, možnosti balenia a metódy. A požiadavky na prepravu a skladovanie musia pre softvérový produkt uvádzať prepravné podmienky, miesta skladovania, podmienky skladovania, skladovacie podmienky, doby skladovania v rôznych podmienkach.

Špeciálne požiadavky sú veľmi dôležitá vec. Ak je to možné, je lepšie sa im vyhnúť. A hneď to deklaruj.

Napríklad: Neexistujú žiadne špeciálne požiadavky na časové charakteristiky programu. Neexistujú žiadne špeciálne požiadavky na kapacitné charakteristiky programu.

Technické a ekonomické ukazovatele. Tento najťažší bod pre programátora nie je vždy prítomný. Je potrebný predovšetkým vtedy, keď je vaším cieľom ospravedlniť obrovskú efektivitu a dôležitosť vykonávanej práce. Táto položka zvyčajne funguje pre zákazníka veľmi dobre. Toto je prinajmenšom najlepšie zdôvodnenie načasovania a peňažných čiastok vývoja.

V tejto časti by mali byť uvedené: odhadovaná ekonomická efektívnosť, odhadovaná ročná potreba (napríklad: predpokladaný počet hovorov do komplexu ako celku za rok - 365 pracovných stretnutí), ekonomické výhody vývoja v porovnaní s najlepšími domácimi a zahraničnými vzorkami resp. analógy.

Okrem toho sa odporúča poskytnúť definíciu odhadovaných nákladov na vývoj programu a definíciu zložitosti programovania.

Etapy a etapy vývoja(o tom bude podrobnejšie popísané nižšie) stanoviť potrebné etapy vývoja, etapy a obsah prác (zoznam programových dokumentov, ktoré musia byť vypracované, odsúhlasené a schválené), ako aj spravidla termíny vývoja a určiť účinkujúcich.

Štandardné kroky sú popísané tu. Hlavná vec je správne určiť načasovanie. Ak je to možné, snažte sa rovnomerne rozdeliť fázy medzi termíny (a sumy). Pamätajte, že nie všetky projekty sa dostanú do záverečnej fázy. A pre každú fázu by mali byť správy. Pamätajte tiež, že pracovný projekt zaberie najviac času. Ak nedokončíte dokumentáciu včas, objednávateľ má plné právo dielo vôbec neprijať so všetkými z toho vyplývajúcimi dôsledkami.

Hlavnými a nevyhnutnými etapami a fázami sú samotné zadávacie podmienky, predbežný návrh, technické a pracovné návrhy.

  • Predbežný návrh. V tejto fáze sa podrobne rozpracúvajú štruktúry vstupných a výstupných údajov a určuje sa forma ich prezentácie. Vo vývoji všeobecný popis algoritmus, samotný algoritmus, štruktúra programu. Pripravuje sa akčný plán rozvoja a implementácie programu.
  • Technický projekt. Obsahuje vyvinutý algoritmus na riešenie problému, ako aj metódy sledovania počiatočných informácií. Tu sa vyvíjajú nástroje na spracovanie chýb a vydávanie diagnostických správ, určujú sa formuláre na prezentáciu prvotných údajov a konfigurácia technického vybavenia.
  • Pracovný návrh. V tejto fáze sa vykonáva programovanie a ladenie programu, vývoj programových dokumentov, programov a testovacích metód. Príklady testovania a ladenia sa pripravujú. Dokončuje sa dokumentácia a grafický materiál. Zvyčajne sa uvádza, že počas vývoja programu by sa mala pripraviť nasledujúca dokumentácia:
    • text programu;
    • popis programu;
    • testovací program a metodika;
    • popis aplikácie;
    • užívateľská príručka.

Toto sú štandardné požiadavky. Ak zákazník súhlasí s tým, že nie je možné predložiť celý tento zoznam, znamená to, že jeho zámery týkajúce sa vás a vášho produktu nie sú vážne.

Nemusí tam byť žiadny grafický materiál. Najmä vtedy, keď sa nechystáte podávať správy o výsledkoch svojej práce. Ale pre vážne projekty je táto položka potrebná.

Napríklad: Počas vývoja programu by mal byť pripravený nasledujúci grafický materiál:

    • technické a ekonomické ukazovatele;
    • štruktúra programu;
    • formát na prezentáciu vstupných údajov programu;
    • všeobecný diagram algoritmu (2 listy);
    • základné výpočtové algoritmy;
    • príklad fungovania programu.

V kapitole Postup kontroly a prijatia musia byť špecifikované druhy skúšok a Všeobecné požiadavky za prijatie prac. Ak je to možné, potom v tomto odseku uveďte, že „kontrola a akceptácia vývoja sa vykonáva pomocou vybavenia poskytnutého zákazníkom“, inak sa od vás môže vyžadovať, aby ste si toto vybavenie priniesli so sebou.

Napríklad: Kontrola a akceptácia vývoja sa vykonáva na základe testovacích testov a príkladov ladenia. Tým sa skontroluje vykonávanie všetkých funkcií programu.

IN Aplikácie V prípade potreby technické špecifikácie poskytne:

  • zoznam výskumných a iných prác odôvodňujúcich vývoj;
  • diagramy algoritmov, tabuľky, popisy, odôvodnenia, výpočty a iné dokumenty, ktoré možno použiť pri vývoji;
  • iné zdroje rozvoja.

Táto norma stanovuje fázy vývoja programov, programovú dokumentáciu, ako aj fázy a obsah práce:

Vývojové štádiá

Etapy práce

Technická úloha

Odôvodnenie potreby rozvoja programu

Formulácia problému.
Zbierka podkladov.
Výber a zdôvodnenie kritérií efektívnosti a kvality vypracovaného programu.
Zdôvodnenie potreby výskumnej práce.

Výskumná práca

Určenie štruktúry vstupných a výstupných údajov.
Predbežný výber metód riešenia problémov.
Zdôvodnenie uskutočniteľnosti použitia predtým vyvinutých programov.
Stanovenie požiadaviek na technické prostriedky.
Zdôvodnenie zásadnej možnosti riešenia problému.

Vývoj a schvaľovanie technických špecifikácií

Stanovenie požiadaviek programu.
Vypracovanie štúdie uskutočniteľnosti pre vypracovanie programu.
Stanovenie etáp, etáp a načasovanie vývoja programu a dokumentácie k nemu.
Výber programovacích jazykov.
Stanovenie potreby výskumnej práce v nasledujúcich etapách.
Koordinácia a schvaľovanie technických špecifikácií.

Predbežný návrh

Vypracovanie predbežného návrhu

Predbežný vývoj štruktúry vstupných a výstupných údajov.
Objasnenie metód riešenia problému.
Vývoj všeobecného popisu algoritmu na riešenie problému.
Vypracovanie štúdie uskutočniteľnosti.

Schválenie predbežného projektu


Koordinácia a schvaľovanie predbežného projektu

Technický projekt

Technický vývoj projektu

Objasnenie štruktúry vstupných a výstupných údajov.
Vývoj algoritmu na riešenie problému.
Určenie formy prezentácie vstupných a výstupných údajov.
Definícia sémantiky a syntaxe jazyka.
Vývoj programovej štruktúry.
Konečné určenie hardvérovej konfigurácie.

Schválenie technického návrhu

Vypracovanie akčného plánu rozvoja a implementácie programov.
Vypracovanie vysvetľujúcej poznámky.
Koordinácia a schvaľovanie technického návrhu.

Pracovný návrh

Vývoj programu

Programovanie a ladenie

Vývoj softvérovej dokumentácie

Vývoj programových dokumentov v súlade s požiadavkami GOST 19.101-77.

Testovanie programu

Vývoj, koordinácia a schvaľovanie programu a metodiky testovania.
Vykonávanie predbežných štátnych, medzirezortných, akceptačných a iných typov skúšok.
Oprava programu a programovej dokumentácie na základe výsledkov testov.

Implementácia

Príprava a prenos programu

Príprava a prenos programov a softvérovej dokumentácie pre údržbu a (alebo) výrobu.
Registrácia a schválenie aktu prevodu programu na údržbu a (alebo) výrobu.
Presun programu do fondu algoritmov a programov.

Poznámky:

  1. Je povolené vylúčiť druhú fázu vývoja av technicky odôvodnených prípadoch druhú a tretiu fázu. Potreba týchto etáp je uvedená v technických špecifikáciách.
  2. Je dovolené kombinovať, vylučovať etapy prác a (alebo) ich obsah, ako aj zavádzať ďalšie etapy prác podľa dohody so zákazníkom.

Táto norma je zameraná na dokumentáciu výsledného vývojového produktu.

Prísne vzaté, ide o dva rôzne dokumenty, ktoré však majú veľa spoločného. Toto je VŠEOBECNÝ POPIS (GOST 19.502-78) a POPIS PROGRAMU (GOST 19.402-78). Avšak vzhľadom na to, že je veľmi ťažké skutočne kvalitne vytvoriť oboje, bez uchyľovania sa k takmer úplnej duplikácii a vytrhávaniu kúskov, stačilo by implementovať jeden, všeobecnejší, „hybridný“ dokument. Nazvime to „Popis programu“.

V skutočnosti môže byť „Popis programu“ v jeho obsahu doplnený oddielmi a odsekmi prevzatými z noriem pre iné popisné dokumenty a príručky: GOST 19.404-79 ESPD. Vysvetlivka, GOST 19.503-79 ESPD. Príručka systémového programátora, GOST 19.504-79 ESPD. Príručka programátora, GOST 19.505-79 ESPD. Návod na obsluhu atď. Najmä z vysvetliviek si môžete vziať schému algoritmu, všeobecný popis algoritmu a (alebo) fungovania programu, ako aj zdôvodnenie prijatých technických a technicko-ekonomických rozhodnutí.

Popis programu musí obsahovať informačnú časť – anotáciu a obsah.

Hlavná časť dokumentu by mala pozostávať z úvodnej časti a nasledujúcich častí:

  • funkčný účel;
  • popis logiky.
  • podmienky používania;
  • zloženie a funkcie.

V závislosti od špecifík programu môžu byť zavedené ďalšie sekcie.

IN Úvodná časť Dokument poskytuje všeobecné informácie o programe – celý názov, označenie, jeho možné aplikácie atď.

Napríklad: Program "Automat pracovisko ACS developer“ je určený pre... implementovaný na.... Program podporuje...

V kapitole Účel uveďte účel programu a uveďte všeobecný popis fungovania programu, jeho hlavné charakteristiky, informácie o obmedzeniach uložených na rozsah programu a tiež uveďte typy elektronických počítačov a zariadení, ktoré sa používajú počas prevádzky.

Napríklad: Program je určený na riešenie problémov... Program predstavuje jadro automatizovanej pracovnej stanice...

Používateľ má možnosť..., implementovať..., spustiť..., analyzovať..., získať výsledky analýzy a spracovania..., zostaviť..., atď.

V kapitole " Popis logiky"označiť:

  • popis programovej štruktúry a jeho hlavných častí

(napríklad: Program obsahuje nasledovné:

  • používateľské rozhranie,
  • modul na určovanie ciest v grafe,
  • modul výpočtu prenosovej funkcie,
  • modul na konštrukciu amplitúdových a fázových frekvenčných charakteristík,
  • modul na zostavenie odozvy na polynomický vplyv,
  • textový editor).
  • popis funkcií komponentov a spojení medzi nimi;

Napríklad: Program pozostáva zo šiestich modulov: modul rozhrania; definičný modul...; výpočtový modul...; modul atd...

Modul rozhrania je postavený na dvoch typoch dialógov: dialóg otázka-odpoveď a dialóg typu menu. Modul rozhrania ovláda...

Definičný modul... Je to...

Výpočtový modul...atď.

  • informácie o programovacom jazyku;

Napríklad: Program je napísaný v jazyku ... pomocou kompilátora ...

  • popis vstupných a výstupných údajov pre každý z komponentov;

Napríklad: INPUT DATA. Vstupnými údajmi pre program je textový súbor popisujúci rozšírenú maticu výskytu grafu skúmaného systému.

VÝKON. Výstupom je:

  • grafické a textové informácie zobrazené na obrazovke (výsledky analýzy systému);
  • súbory v jednom z grafických formátov- kópie obrazu zostrojených charakteristík (AFC, PFC atď.);
  • textové súbory - správy o vykonaných výskumoch;
  • diagnostiku stavu systému a správy o všetkých chybách, ktoré sa vyskytnú.
  • popis logiky komponentov (ak je to potrebné, treba napísať popis programových diagramov).

Pri popise logiky programu je potrebný odkaz na text programu.

V kapitole Zloženie a funkcie uveďte popis zloženia a funkcie programov a metód používaných na riešenie problémov.

V kapitole Podmienky používania sú uvedené podmienky potrebné na realizáciu programu (požiadavky na technické prostriedky potrebné pre tento program a iné programy, Všeobecné charakteristiky vstupné a výstupné informácie, ako aj požiadavky a podmienky organizačného, ​​technického a technologického charakteru a pod.).

Napríklad: Program je spustený osobný počítač(PC) typu IBM PC/AT. Na prácu v interaktívnom režime sa používa obrazovka, klávesnica a myš. Na podporu grafického režimu je potrebný adaptér EGA (VGA). Vstupné dáta sa ukladajú na diskety a/alebo pevné disky. Program beží pod OS...

Príloha k popisu môže obsahovať referenčné materiály (ilustrácie, tabuľky, grafy, príklady atď.)

A nezabudnite uviesť názov načítacieho modulu, ako aj popis celého postupu

Volanie a zavádzanie systému

Požiadavky na návrh programového textu sú celkom jednoduché a pre kompetentného programátora prirodzené. Hlavná vec, ktorou sa treba riadiť pri vytváraní tohto dokumentu, je, že text programu by mal byť čitateľný.

Naďalej je povinné zostaviť informačnú časť – anotácie a obsah.

Hlavná časť dokumentu by mala pozostávať z textov jednej alebo viacerých častí, ktoré sú pomenované.

Text každého programového súboru začína „hlavičkou“, ktorá označuje:

    • názov programu,
    • autor,
    • dátum vytvorenia programu,
    • číslo verzie,
    • dátum poslednej úpravy.

Sú potrebné komentáre, ako aj prísne dodržiavanie pravidiel odsadzovania. Pamätajte, že aj neschopnosť vytvoriť softvérovú dokumentáciu môže byť odôvodnená. Ale škaredý text programu - nikdy. Odkazy na to, že tento text je zrozumiteľný aj pre samotného autora, neberú vážne. Nemalo by byť hanbou dať programové texty na čítanie iným ľuďom.

Nižšie je uvedený príklad takého dobre čitateľného textu programu (prevzatý z webovej stránky Nikolaja Gekhta, e-mail: [e-mail chránený], http://users.omskreg.ru/~geht)

/* Zdroje Windows 98

Zdrojový kód pre Windows 98 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" # definuj INSTALL = HARD char make_prog_look_big; VOID Main () (While (! CraShed) (Display_copyright_message (); Display_bill_rules_message (); do_nothing_loop (); if (prvá_inštalácia) yte_swapfile (); do_nothing_loop (); (); totilla_screw_screw_file_up_systemofs); netscape (); disable_RealPlayer (); disable_Corel_Products(); hang_system(); ) write_something(hocico); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(stále_nezlyhalo) (zobraziť_správu_copyrightu(); do_nothing_loop(); (;v podstate_run_windows do_3.1 ); do_nothing_loop(); ) ) if(detect_cache()) disable_cache(); if(fast_cpu()) ( set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(akcia, skákanie); set_mouse(reakcia, niekedy ) ; ) /* printf("Vitajte v systéme Windows 3.11"); */ /* printf("Vitajte v systéme Windows 95"); */ printf("Vitajte v systéme 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(); spánok(5); act_on_user_input(); spánok(5); ) create_general_protection_fault();

Tento dokument obsahuje popis toho, čo a ako je potrebné urobiť, aby ste sa uistili (a presvedčili zákazníka), že program funguje správne. V skutočnosti je tento dokument rozhodujúci pre akceptačné testy. Dobre navrhnutý testovací program a metodika je kľúčom k podpisu akceptačného certifikátu, t.j. vec, na ktorú ste vynaložili toľko úsilia a času.

Formálne sa tento GOST používa na vývoj plánovacích dokumentov a vykonávanie testovacích prác na posúdenie pripravenosti a kvality softvérového systému. Dokument obsahuje popis predmetu a účelu testovania, požiadavky na programovú a softvérovú dokumentáciu, prostriedky a postup testovania, ako aj popis testovacích príkladov.

Komponenty tohto dokumentu sú jednoduchšie a jasnejšie opísané vo forme príkladov.

Testovaný objekt

Príklad: Testovacím objektom je program ..., určený pre ...

Účel testovania

Príklad: Kontrola spoľahlivosti programu.

Požiadavky na program

Príklad: Prevádzka programu by nemala viesť k poruche (fatálnemu narušeniu systému). Organizácia dialógu by mala poskytnúť ochranu pred zadaním nesprávnych údajov. Program by mal poskytovať diagnostiku stavu systému a správy o akýchkoľvek chybách, ktoré sa vyskytli... atď.

Požiadavky na softvérovú dokumentáciu

Príklad: Obsah softvérovej dokumentácie prezentovanej počas testovania:

  • popis programu (GOST 19.402-78);
  • testovací program a metodika (GOST 19.301-79);
  • text programu (GOST 19.401-78).

Testovacie prostriedky a postup

Príklad: Program funguje v súlade s prevádzkovými podmienkami operačného systému MS DOS (verzia nie nižšia ako 3.0) na PC ako IBM PC/AT, ako aj na kompatibilných. Na prevádzku je potrebný aj EGA (VGA) adaptér.

Skúšobný postup:

    1. Program je spustený....
    2. Vybraný...
    3. Stlačené...
    4. Postupne vybrané...

Testovacie prípady

Príklad: Na testovanie sú navrhnuté ..., ktorých popisy sú obsiahnuté v súboroch ... Obsah testovacích súborov a výsledky programu sú uvedené v prílohe 1.

A nakoniec sa pozrime na ten posledný štandard ESPD ktorá sa volá

Táto norma stanovuje pravidlá pre vykonávanie programových dokumentov pre počítače, komplexy a systémy bez ohľadu na ich účel a rozsah použitia a stanovené normami ESPD.

Všeobecné požiadavky. Je potrebné zadávať jednotlivé slová, vzorce, symboly (ručne kresliacim písmom), písmená latinskej a gréckej abecedy, ako aj kresliť schémy a kresby v programových dokumentoch písaných strojom, strojom a rukou, čiernym atramentom. alebo atrament.

Preklepy a grafické nepresnosti zistené počas procesu vykonávania je možné opraviť vymazaním zle vykonanej časti textu (kresby) a aplikáciou opraveného textu (grafiky) na ten istý list strojopisom alebo čiernym atramentom, v závislosti od spôsobu vykonania dokument.

Poškodenie listov dokumentu, škvrny a stopy po neúplne vymazanom texte (grafike) nie sú povolené.

Programové dokumenty sú vyhotovené na listoch A4. Okrem toho:

  • Je prijateľné tlačiť na listy A3;
  • pri strojovom spôsobe vyhotovenia dokumentu sú prípustné odchýlky vo veľkosti listov zodpovedajúce formátom A4 a A3, určené možnosťami použitých technických prostriedkov; na listoch formátov A4 a A3, zabezpečených výstupnými charakteristikami zariadení na výstup dát, pri výrobe dokumentu strojom;
  • Pri výrobe dokumentu typografickou metódou je možné použiť listy typografických formátov.

Materiály programového dokumentu sú usporiadané v nasledujúcom poradí:

  • titulná časť:
    • schvaľovací list (nezahrnutý do celkového počtu listov dokumentu);
    • titulná strana (prvá strana dokumentu);
    • informačná časť:
    • anotácia;
    • obsah;
    • Hlavná časť:
    • text dokumentu (s obrázkami, tabuľkami atď.);
    • zoznam pojmov a ich definícií;
    • zoznam skratiek;
    • aplikácie;
    • index predmetu;
    • zoznam referenčných dokumentov;
  • zmeniť časť záznamu:
    • zmeniť registračný list.

Konštrukcia dokumentu. V prípade potreby je dovolené rozdeliť dokument na časti. Rozdelenie na časti sa vykonáva na úrovni nie nižšej ako sekcia. Každá časť je vyplnená samostatne a na konci obsahu prvej časti by mali byť uvedené názvy zvyšných častí.

Do dokumentu je povolené zahrnúť časti textu programu, naformátované v súlade s pravidlami jazyka, v ktorom je text programu napísaný.

Abstrakt je zverejnený na samostatná stránka(strany), opatrené nadpisom „ABSTRAKT“, očíslované a zahrnuté do obsahu dokumentu.

Text každého dokumentu je v prípade potreby rozdelený na odseky a odseky na pododstavce bez ohľadu na to, či je dokument rozdelený na časti, oddiely a pododdiely alebo nie.

Nadpisy sekcií sa píšu veľkými písmenami a sú umiestnené symetricky vzhľadom na pravý a ľavý okraj textu. Nadpisy pododdielov sa píšu z odseku malé písmená(okrem prvého hlavného mesta). Delenie slov v nadpisoch nie je povolené. Na konci nadpisu nie je bodka. Odporúča sa začať každú sekciu na novom hárku.

Oddiely, pododdiely, odseky a pododseky by mali byť očíslované arabskými číslicami s bodkou. Sekcie musia mať poradové číslo (1, 2 atď.)

Text dokumentu. Text dokumentu by mal byť krátky, jasný, s vylúčením možnosti nesprávneho výkladu. Termíny a definície musia byť jednotné a musia byť v súlade so stanovenými normami a ak neexistujú, musia byť všeobecne akceptované vo vedeckej a technickej literatúre a musia byť uvedené v zozname termínov.

Potrebné vysvetlenia k textu dokumentu je možné uviesť v poznámkach pod čiarou. Poznámka pod čiarou je označená číslom so zátvorkou umiestnenou na úrovni horného okraja písma.

Ak sa poznámka pod čiarou vzťahuje na jedno slovo, znak poznámky pod čiarou sa umiestni priamo vedľa tohto slova, ak sa však vzťahuje na vetu ako celok, potom na koniec vety. Text poznámky pod čiarou je umiestnený na konci strany a oddelený od hlavného textu 3 cm dlhou čiarou nakreslenou na ľavej strane strany.

Ilustrácie. Ilustrácie sa môžu nachádzať v texte dokumentu a (alebo) v prílohách. Ilustrácie, ak je ich v danom dokumente viac, sú v celom dokumente očíslované arabskými číslicami.

V prílohách sú ilustrácie očíslované v každej prílohe v poradí stanovenom pre hlavný text dokumentu. Odkazy na ilustrácie sú uvedené podľa typu: „Obr. 12“ alebo „(Obr. 12)“. Ilustrácie môžu mať tematický názov a text popisku vysvetľujúci obsah ilustrácie.

Vzorce. Vzorce v dokumente, ak je ich viac, sú očíslované arabskými číslicami, číslo sa umiestni s pravá strana strany v zátvorkách na úrovni vzorca. V rámci celého dokladu alebo jeho častí, ak je doklad rozdelený na časti, majú vzorce priebežné číslovanie.

Odkazy v texte na poradové číslo vzorca sú uvedené v zátvorkách, napríklad: „vo vzorci (3)“. Pri delení dokumentu na časti sa číslo časti umiestni pred poradové číslo vzorca a oddelí sa od poslednej bodky, napríklad: „vo vzorci (1.4)“.

Význam symbolov zahrnutých vo vzorci musí byť uvedený priamo pod vzorcom. Význam každého znaku sa vytlačí na nový riadok v poradí, v akom sú uvedené vo vzorci. Prvý riadok prepisu by mal začínať slovom „kde“ bez dvojbodky.

Odkazy. V politických dokumentoch sú povolené odkazy na normy a iné dokumenty. Je potrebné uviesť odkaz na dokument ako celok alebo na jeho časti (s uvedením označenia a názvu dokumentu, čísla a názvu sekcie alebo prílohy).

Je povolené uviesť iba označenie dokumentu a (alebo) oddielov bez uvedenia ich názvov. Odkazy na jednotlivé podsekcie, odseky a ilustrácie iného dokumentu nie sú povolené. V rámci dokumentu sú povolené odkazy na odseky, ilustrácie a jednotlivé podsekcie.

Poznámky Poznámky k textu a tabuľkám uvádzajú len referenčné a vysvetľujúce údaje. Jedna poznámka nie je očíslovaná. Za slovo „Poznámka“ vložte bodku. Niekoľko poznámok by sa malo očíslovať v poradí pomocou arabských číslic s bodkou. Za slovo „Poznámka“ vložte dvojbodku. Text poznámok možno vytlačiť iba v jednom intervale.

Skratky. Skratky slov v texte a nápisy pod obrázkami nie sú povolené, s výnimkou:

  • skratky zavedené v GOST 2.316-68 a všeobecne akceptované v ruskom jazyku;
  • skratky používané na označenie programov, ich častí a prevádzkových režimov, v jazykoch riadenia úloh, v nástrojoch na konfiguráciu programov atď., označované písmenami latinskej abecedy.

Aplikácie. Ilustrovaný materiál, tabuľky alebo sprievodný text môžu byť prezentované vo forme príloh. Aplikácie sú koncipované ako pokračovanie tohto dokumentu na nasledujúcich stranách alebo vydaný ako samostatný dokument.

Každá aplikácia musí začínať nová stránka s označením vpravo horný roh slová „Aplikácia“ a majú tematický názov. Ak je v dokumente viac ako jedna príloha, všetky prílohy sú očíslované arabskými číslicami (bez znaku č.), napríklad:

Dodatok 1, Dodatok 2 atď.

Pri vydávaní prihlášky ako samostatného dokumentu by sa malo na titulnej strane pod názvom dokumentu uviesť slovo „Príloha“ a ak ide o viacero žiadostí, uviesť aj jej poradové číslo.

P R Í V A R S T V E N Y S T A N D A R T S O Y W A S S R

Jednotný systém programovej dokumentácie

 GOST 19.103-77

OZNAČOVANIE PROGRAMOV A PROGRAMOVÝCH DOKUMENTOV

Jednotný systém pre dokumentáciu programu.
Indexovanie programov a programových dokumentov.

Dátum uvedenia od 01.01.80

1. Táto norma stanovuje štruktúru označovania programov a programových dokumentov pre počítače, komplexy a systémy bez ohľadu na ich účel a rozsah.

2. Označenie programov a dokumentov musí pozostávať zo skupín znakov oddelených bodkami (za kódom krajiny a kódom vývojárskej organizácie), medzerami (za číslom revízie dokumentu a kódom typu dokumentu) a pomlčkami (za registračným číslom a číslo dokladu tohto typu).

3. Je vytvorený registračný systém na označovanie programov a programových dokumentov.

Štruktúra programového označenia a jeho programového dokumentu - špecifikácie:

A.B.XXXXX-XX
Všeobecná časť označenia / Kód krajiny | | | |
programy a softvér | Kód organizácie vývojára | | |
dokumenty k tomu\ Registračné číslo | |
Číslo vydania (pre program) |
Číslo revízie (pre dokument) |

4. Štruktúra označenia ostatných programových dokumentov:

A.B.XXXXX-XX XX XX-X
Všeobecná časť programového označenia | | | | |
a programové dokumenty k tomu | | | | |
Číslo revízie dokumentu | | | |
Kód typu dokumentu | | |
Číslo dokladu tohto typu | |
Číslo časti dokumentu |

5. Kód krajiny – developera a kód organizácie (podniku) – developera sa prideľujú predpísaným spôsobom.

Registračné číslo je pridelené v súlade s All-Union klasifikátorom programov, schváleným Gosstandartom predpísaným spôsobom.

Pred schválením klasifikátora programov All-Union je povolené prideliť registračné číslo vo vzostupnom poradí, počnúc od 00001 do 99999, pre každú rozvíjajúcu sa organizáciu (podnik).

Číslo publikácie programu alebo číslo revízie dokumentu sa prideľuje vzostupne od 01 do 99.

6. Kód typu dokumentu je priradený v súlade s požiadavkami GOST 19.101-77.

7. Číslo dokladu tohto typu sa prideľuje vzostupne od 01 do 99.

8. Číslo dielu toho istého dokumentu sa prideľuje vzostupne od 1 do 9.

Poznámka. Ak dokument pozostáva z jednej časti, potom sa pomlčka a sériové číslo časti neuvádzajú.

9. Číslo revízie špecifikácie a zoznamu operačných dokumentov pre program sa musí zhodovať s číslom publikácie toho istého programu.

Opätovné vydanie. novembra 1987