GOST 19.402-78

Skupina T55

MEZISTÁTNÍ STANDARD

jeden systém dokumentaci programu

POPIS PROGRAMU

Jednotný systém pro dokumentaci programu. Popis programu.

MKS 35,080

Datum zavedení 1980-01-01

Výnosem Státního výboru pro normy SSSR ze dne 18. prosince 1978 N 3350 bylo datum implementace stanoveno na 01.01.80

VYDÁNÍ (leden 2010) s dodatkem č. 1, schváleným v září 1981 (IUS 11-81).

1. Tato norma stanoví složení a požadavky na obsah programového dokumentu „Popis programu“, definovaného GOST 19.101-77.

Norma plně vyhovuje ST SEV 2092-80*.
________________
* Přístup k mezinárodním a zahraničním dokumentům uvedeným zde lze získat kliknutím na odkaz na webovou stránku http://shop.cntd.ru. - Poznámka výrobce databáze.

(Změněné vydání, dodatek č. 1).

2. Struktura a provedení dokumentu jsou stanoveny v souladu s GOST 19.105-78.

Vypracování informační části (anotace a obsah) je povinné.

3. Popis programu musí obsahovat následující části:

obecná informace;

funkční účel;

popis logické struktury;

použitý technické prostředky;

vstupní data;

výstup.

V závislosti na vlastnostech programu je možné zavádět další sekce nebo jednotlivé sekce kombinovat.

4. V sekci " Obecná informace“ musí být uvedeno:

označení a název programu;

software nezbytný pro provoz programu;

programovací jazyky, ve kterých je program napsán.

5. Sekce „Functional Purpose“ musí uvádět třídy problémů, které se řeší, a (nebo) účel programu a informace o funkčních omezeních použití.

6. V části „Popis logické struktury“ by mělo být uvedeno:

programový algoritmus;

použité metody;

struktura programu s popisem funkcí komponenty a spojení mezi nimi;

propojení programu s jinými programy.

Popis logické struktury programu se provádí s přihlédnutím k textu programu ve zdrojovém jazyce.

3-6. (Změněné vydání, dodatek č. 1).

7. V části „Použité technické prostředky“ musí být uvedeny typy elektronických počítačů a zařízení, které se používají při spouštění programu.

způsob volání programu z odpovídajícího paměťového média;

vstupní body do programu.

Je povoleno uvádět adresy pro stahování, informace o použití paměť s náhodným přístupem, hlasitost programu.

9. V části "Vstupní údaje" musí být uvedeno:

charakter, organizace a předběžná příprava vstupní data;

formát, popis a způsob kódování vstupních dat.

10. V části „Výstupní data“ musí být uvedeno:

povaha a organizace výstupních dat;

formát, popis a způsob kódování výstupních dat.

11. Obsah oddílů je dovoleno ilustrovat vysvětlujícími příklady, tabulkami, schématy, grafy.

12. Příloha k popisu programu může obsahovat různé materiály, které není vhodné zahrnout do částí popisu.

7-12. (Vloženo dodatečně, změna č. 1).



Text elektronického dokumentu
připravené společností Kodeks JSC a ověřené proti:
oficiální publikace
Jednotný systém programové dokumentace:
Sbírka národní normy. -
M.: Standartinform, 2010

V.E. Karpov

Tento dokument obsahuje Stručný popis Standardy ESPD, jejichž znalost je nezbytná pro studenty k dokončení kurzů a projektů souvisejících s tvorbou softwarových systémů. Navíc to může být užitečné z hlediska zlepšení kvality softwarové dokumentace obecně.

TECHNICKÉ SPECIFIKACE (GOST 19.201-78)

1. Obecná ustanovení

FÁZE VÝVOJE (GOST 19.102–77)

POPIS PROGRAMU (GOST 19,402-78)

TEXT PROGRAMU (GOST 19 401-78)

PROGRAM A METODIKA TESTU (GOST 19.301-79)

POŽADAVKY NA TIŠTĚNÉ SOFTWAROVÉ DOKUMENTY (GOST 19.106-78)

Standardizace v oblasti softwarové dokumentace

Jak se posunout vpřed

Příprava dokumentace pro software(PS) v souladu se stávajícími GOST

2. Obecná charakteristika stavu

2.3. Státní normy Ruské federace (GOST R)

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

Snad nejnepříjemnější a nejobtížnější fází programátorské práce je tvorba programové dokumentace. Bohužel se to většinou buď vůbec neučí, nebo v lepším případě nevěnují náležitou pozornost kvalitě obdržených dokumentů. Zvládnutí tohoto umění je však často jedním z nejdůležitějších faktorů určujících kvalitu programátora.

Za prvé, schopnost vytvářet programovou dokumentaci určuje profesionální úroveň programátora. Zákazník se nebude ponořit do složitostí a funkcí ani toho nejúžasnějšího programu. Zákazník si nejprve přečte dokumentaci. Velkou roli v tom hraje i psychologický faktor. Zejména bývalá sovětská škola programování byla (a nyní je) ceněna po celém světě. Moderní domácí programátoři přestali být citováni. Třída není stejná. V dnešní době se programy již nepíší, ale kompilují (a to jsou „dva velké rozdíly“). Balíček softwarové dokumentace (dále jen PD) vytvořený v „klasickém“ stylu tedy udělá na vašeho zákazníka či zaměstnavatele ten nejpříznivější dojem. Navíc, pokud se autor PD vyhýbá frázím jako „klikni na posuvník...“, „šroub“ atp. Bohužel takové žargonové tlachání v sobě většinou skrývá buď myšlenkový nedostatek, nebo naprostou prázdnotu (na autora nesmazatelně zapůsobila historka jednoho jeho známého o jistém „hráči“, který buď s někým „kecal“, nebo se věnoval „moderování“ “Nebo tak nějak.). Jazyk PD je druh byrokratického, velmi konzervativního jazyka. Má své zvláštní kouzlo. Souhlasíte s tím, že pojmy pevný disk, plochý disk, ruční manipulátor jako „myš“ (nebo „houska“, jak bylo napsáno v jednom ze starých balíčků PD) zní úplně jinak než odpovídající „šroub“, „ flop“ a jednoduše „myš“. Mimochodem, věci už dospěly k tomu, že se prý objevila i zvláštní specialita - technický spisovatel, tzn. člověk, který ví, jak vytvářet softwarovou dokumentaci.

Za druhé, dobře navržený (přesněji vytvořený) balíček PD vás ušetří mnoha problémů. Zejména se můžete zbavit nepříjemných otázek a nepodložených nároků jednoduchým odkazem uživatele na dokumentaci. Týká se to především nejdůležitějšího dokumentu – zadávacího řízení. O tom si povíme níže, ale nyní vám můžeme připomenout mnohamilionovou žalobu proti IBM. Tuto žalobu podalo jedno velké vydavatelství, nespokojené s kvalitou VT a softwaru. IBM spor vyhrála. A vyhrála jen proto, že předložila Zadání podepsané oběma stranami. Stalo se to už dávno, v 70. letech, ale to nic nemění na podstatě věci.

Ještě jedna věc. Je důležité vytvořit první balíček PD. To bude stačit k tomu, abyste na jeho základě postavili všechny následující a použili je jako model nebo šablonu. Ale to musí být provedeno velmi efektivně. Neuspěchaný. Velmi důkladné.

Nejprve se musíte vyzbrojit normami GOST. GOST definuje vše. Zejména zahrnuje Unified System of Program Documentation (USPD), který nás zajímá. Snad nejtěžší je získat samotný GOST. GOST by měl být pouze v tištěné originální podobě. Prodávají se (alespoň tomu tak bylo dříve) ve speciálních obchodech. Pro získání norem v oblasti dokumentace se můžete obrátit zejména na následující organizace:

• IPK "Publishing Standards", Územní oddělení distribuce NTD (obchod "Standards"), 17961, Moskva, st. Donskaya, 8, tel. 236-50-34, 237-00-02, fax/tel. 236-34-48 (ohledně GOST a GOST R).
• VNIIKI Gosstandart Ruska (čítárna), 103001, Moskva, Granatny per. č. 4, tel. 290-50-94 (týkající se mezinárodních, zahraničních norem a další vědecké a technické dokumentace).

A žádné citace nebo sekundární zdroje. GOST je zákon. A ještě k tomu žádný internet (představte si, že soud vynese rozsudek pomocí výtisku trestního zákoníku staženého z nějakého webu). Nevěřte nikomu jinému než originálu. Poté se však bude muset autor uchýlit k citaci ESPD, čímž se zříká veškeré odpovědnosti.

Začněme obecnými ustanoveními o Jednotném systému programové dokumentace (která jsou také definována v odpovídající normě GOST 19.001-77).

Jednotný systém programové dokumentace je souborem státních norem, které stanovují vzájemně provázaná pravidla pro tvorbu, provádění a oběh programů a programové dokumentace.

definují normy ESPD obecná ustanovení a základní normy, pravidla pro provádění vývojové dokumentace, pravidla pro provádění výrobní dokumentace, pravidla pro provádění dokumentace údržby, pravidla pro provádění provozní dokumentace, pravidla pro nakládání s programovou dokumentací a další normy. ESPD zahrnuje:

• základní a organizační a metodické standardy;
• standardy definující formy a obsah programových dokumentů používaných při zpracování dat;
• standardy, které zajišťují automatizaci tvorby programových dokumentů.

Obecně je seznam dokumentů ESPD velmi rozsáhlý. Zahrnuje zejména následující GOST:

• GOST 19.001-77 ESPD. Obecná ustanovení.
• GOST 19.101-77 ESPD. Typy programů a programové dokumenty (znovu vydáno v listopadu 1987 s úpravami).
• GOST 19.102-77 ESPD. Vývojové fáze.
• GOST 19.103-77 ESPD. Označení programů a programových dokumentů.
• GOST 19.104-78 ESPD. Základní nápisy.
• GOST 19.105-78 ESPD. Obecné požadavky na programové dokumenty.
• GOST 19.106-78 ESPD. Požadavky na tištěné programové dokumenty.
• GOST 19.201-78 ESPD. Technický úkol. Požadavky na obsah a design.
• GOST 19.202-78 ESPD. Specifikace. Požadavky na obsah a design.
• GOST 19.301-79 ESPD. Testovací program a metodika.
• GOST 19.401-78 ESPD. Text programu. Požadavky na obsah a design.
• GOST 19.402-78 ESPD. Popis programu.
• GOST 19.404-79 ESPD. Vysvětlivka. Požadavky na obsah a design.
• GOST 19.501-78 ESPD. Formulář. Požadavky na obsah a design.
• GOST 19.502-78 ESPD. Popis aplikace. Požadavky na obsah a design.
• GOST 19.503-79 ESPD. Příručka systémového programátora. Požadavky na obsah a design.
• GOST 19.504-79 ESPD. Příručka programátora.
• GOST 19.505-79 ESPD. Návod k obsluze.
• GOST 19.506-79 ESPD. Popis jazyka.
• GOST 19.508-79 ESPD. Průvodce údržba. Požadavky na obsah a design.
• GOST 19.604-78 ESPD. Pravidla pro provádění změn v programových dokumentech prováděných v tisku.
• GOST 19.701-90 ESPD. Schémata algoritmů, programů, dat a systémů. Konvence a pravidla provádění.
• GOST 19.781-90. Software pro systémy zpracování informací.

Jak vidíte, hlavní část komplexu ESPD vznikla v 70. a 80. letech. Některé z těchto norem jsou zastaralé a nejsou bez některých nedostatků. Za prvé, některé neodrážejí moderní tendence návrh programů a programová dokumentace, za druhé, tyto standardy obsahují mnohonásobnou duplikaci fragmentů programové dokumentace. Nicméně z nedostatku něčeho lepšího se na ně musíme zaměřit.

Normy ESPD tedy zjednodušují proces dokumentace softwarových systémů. Zaprvé, složení programových dokumentů stanovené standardy ESPD není vůbec tak „rigidní“, jak by se mohlo zdát: standardy umožňují zahrnout dokumentaci o softwarový systém(PS) další typy a za druhé, na základě požadavků zákazníka jsou přípustné některé změny ve struktuře i obsahu zavedených typů PD. Kromě toho lze poznamenat, že normy ESPD (a to platí pro všechny ostatní normy v oblasti PS - GOST 34, Mezinárodní standard ISO/IEC atd.) mají poradní charakter. Faktem je, že v souladu se zákonem Ruské federace „o standardizaci“ se tyto normy stávají povinnými na smluvním základě - tzn. při odkazu na ně ve smlouvě o vývoji (dodávce) softwaru.

Než se začneme zabývat pravidly pro sestavování softwarové dokumentace, je nutné učinit následující poznámku. Ke každému dokumentu je vhodné uvést úvod. Úvod mluví obecně. O důležitosti, nutnosti atd. Cílem umělce je zde ukázat význam a nutnost této práce. Začátek je obvykle standardní: „V současnosti existující četné systémy... ... otevírají skutečné vyhlídky v...“, atd. Obvykle se sem vkládají citace z projevů různých osobností (toto čistě psychologický aspekt): "...jak bylo řečeno na minulém plénu, kongresu, konferenci atd.). Můžete začít tím, že "...Dnes, v době radikálních socioekonomických transformací...atd." Obecně platí, že hlavní věc Nepřehánějte to zde.

A dál. Při popisu svého produktu si vývojář často plete pojmy komponentní a komplexní. Tento - odlišné typy programy. Komponenta je definována jako „program považovaný za jeden celek, vykonávající úplnou funkci a používaný samostatně nebo jako součást komplexu“ a komplex je „program sestávající ze dvou nebo více komponent a (nebo) komplexů, které provádějí vzájemně související funkce. funkce a používá se samostatně nebo jako součást jiného komplexu."

Podle GOST tato norma (znovu vydaná v listopadu 1987) stanoví postup pro konstrukci a přípravu technických specifikací pro vývoj programu nebo softwarového produktu pro počítače, komplexy a systémy bez ohledu na jejich účel a rozsah.

Při jeho vytváření musíte být extrémně opatrní a opatrní, protože... O úspěchu celé práce často rozhoduje dovedně (a kompetentně) vypracovaná technická specifikace. Právě technické specifikace jsou dohodnuty se zákazníkem, který se obvykle snaží zavést co nejvíce protichůdných a nafouknutých požadavků. Úkolem Exekutora je naopak usnadnit mu život. Ale poté, co byly podpisy umístěny na obou stranách, je příliš pozdě něco přehrát.

Zadávací podmínky jsou vypracovány na listech formátu A4 a/nebo A3 zpravidla bez vyplňování polí listu. Čísla listů (stránek) jsou umístěna v horní části listu nad textem.

Pro provedení změn a doplnění technického zázemí v následných fázích vývoje programu nebo softwarového produktu je k němu uvolněn dodatek. Koordinace a schvalování dodatku k Technické specifikace provedeny ve stejném pořadí, jaké je stanoveno pro technické specifikace.

Zadávací podmínky musí obsahovat následující oddíly:

• název a rozsah aplikace;
• základ pro rozvoj;
• účel vývoje;
• technické požadavky na program nebo softwarový produkt;
• etapy a etapy vývoje;
• kontrolní a přejímací řízení;
• aplikací.

V závislosti na vlastnostech programu nebo softwarového produktu je možné upřesnit obsah sekcí, zavést nové sekce nebo jednotlivé kombinovat.

V kapitole Název a rozsah uvést jméno, stručný popis rozsah použití programu nebo softwarového produktu a předmět, ve kterém je program nebo softwarový produkt používán.

V kapitole Základ pro rozvoj musí být uvedeno:

• dokument (dokumenty), na jehož základě je vývoj prováděn;
• organizaci, která tento dokument schválila, a datum jeho schválení;
• jméno a (nebo) symbol rozvojová témata.

Ve vztahu ke specifikům vzdělávacího procesu může být podkladem zadání pro návrh kurzu, objednávka ústavu ze dne __.__. pro N ___., smlouva __.__. pro N ___. , a tak dále.

V kapitole Účel rozvoje Musí být uveden funkční a provozní účel programu nebo softwarového produktu. Zde se můžete omezit na jednu nebo dvě fráze. Hlavní věc je jasně definovat, k čemu tento program je.

Například: Program je jádrem automatizované pracovní stanice (AWS) pro vývojáře kontinuálních lineárních automatických řídicích systémů (ACS), umožňující uživateli řešit problémy analýzy jednoduchých modelů.

Kapitola Technické požadavky na program nebo softwarový produkt by měl obsahovat následující podsekce:

• požadavky na funkční charakteristiky;
• požadavky na spolehlivost;
• podmínky použití;
• požadavky na skladbu a parametry technických prostředků;
• požadavky na informace a kompatibilitu softwaru;
• požadavky na označování a balení;
• požadavky na přepravu a skladování;
• speciální požadavky.

Jinými slovy, zde začínají specifika. Popisuje, co by měl program dělat a jak by měl vypadat.

Požadavky na funkční vlastnosti. Zde by měly být uvedeny požadavky na skladbu vykonávaných funkcí, organizaci vstupních a výstupních dat, časové charakteristiky atd.

Například: Program by měl umožnit ... vypočítat ... postavit ... vytvořit ...

Počáteční údaje: textový soubor s daným...

Výstupní data: grafické a textové informace - výsledky systémové analýzy...; textové soubory - zprávy o ... diagnostika stavu systému a zprávy o všech vzniklých chybách.

Požadavky na spolehlivost. Musí být specifikovány požadavky na zajištění spolehlivého provozu (zajištění stabilního provozu, sledování vstupních a výstupních informací, doba zotavení po poruše atd.).

Tady je těžké něco „uhodnout“. Nejlepším případem je, že váš program pracuje pouze s absolutně správnými daty. Zákazník s tím obvykle nesouhlasí, ale můžete to zkusit.

Například: Program musí pracovat s danou rozšířenou maticí incidentů studovaného grafu v souladu s provozním algoritmem, generovat chybová hlášení, když jsou počáteční data nesprávně specifikována, a podporovat interaktivní režim v rámci možností poskytovaných uživateli.

Podmínky použití. Musí být uvedeny provozní podmínky (okolní teplota, relativní vlhkost apod. u vybraných typů paměťových médií), za kterých musí být zajištěny uvedené vlastnosti, dále druh obsluhy, požadovaný počet a kvalifikace personálu.

S tímto bodem obvykle nejsou žádné potíže. Bohužel klauzule o profesionalitě uživatele ze strany zákazníka je nutně implikována. To je samozřejmě další důvod, proč najít chybu ve svém programu. Zde se však můžeme omezit na fráze jako „Provozní podmínky programu se shodují s provozními podmínkami IBM PC a kompatibilních PC“, „Program by měl být navržen pro neprofesionálního uživatele.“ a tak dále.

Požadavky na složení a parametry technických prostředků. Uveďte požadované složení technických prostředků s uvedením jejich technických vlastností.

Tady jde hlavně o to, na jednu stranu na nic nezapomenout a vše zajistit (jinak tam vklouznou nějaké IBM PC/XT s monochromatickým displejem a bez myši), na druhou stranu přehánět to se zvýšenými požadavky, jinak si Zákazník najde flexibilnějšího Dodavatele.

Například: Musíte mít IBM PC - kompatibilní PC s grafický adaptér EGA (VGA). Nutné místo na disku- alespoň 600 KB, množství volné paměti RAM - alespoň 400 KB. Je žádoucí mít ovladač EMS a manipulátor typu myši.

Požadavky na informace a kompatibilitu softwaru. Funkce jsou stejné jako v předchozím odstavci. Zde by měly být specifikovány požadavky na informační struktury na vstupu a výstupu a metody řešení, zdrojové kódy, programovací jazyky. V případě potřeby musí být zajištěna ochrana informací a programů.

Například: Program musí pracovat autonomně pod OS MS DOS verze ne nižší než 3.3. Základním programovacím jazykem je Turbo Pascal 6.0.

Požadavky na označování a balení a požadavky na přepravu a skladování jsou docela exotické. V obecný případ zde uveďte požadavky na označování softwarového produktu, možnosti balení a metody. A požadavky na přepravu a skladování musí u softwarového produktu uvádět přepravní podmínky, místa skladování, podmínky skladování, podmínky skladování, doby skladování v různých podmínkách.

Zvláštní požadavky jsou velmi důležitá věc. Je lepší se jim pokud možno vyhnout. A hned to deklaruj.

Například: Neexistují žádné zvláštní požadavky na časové charakteristiky programu. Na kapacitní charakteristiky programu nejsou kladeny žádné zvláštní požadavky.

Technické a ekonomické ukazatele. Tento nejobtížnější bod pro programátora tam není vždy. Je potřeba především tehdy, když je vaším cílem ospravedlnit obrovskou efektivitu a důležitost vykonávané práce. Tato položka obvykle funguje pro zákazníka velmi dobře. To je přinejmenším nejlepší ospravedlnění pro načasování a peněžní částky rozvoje.

V této části by měla být uvedena: odhadovaná ekonomická efektivita, odhadovaná roční potřeba (například: předpokládaný počet hovorů do areálu jako celku za rok - 365 pracovních sezení), ekonomické výhody vývoje ve srovnání s nejlepšími domácími a zahraničními vzorky popř. analogy.

Kromě toho je vhodné poskytnout definici jak odhadovaných nákladů na vývoj programu, tak definici složitosti programování.

Etapy a fáze vývoje(o tom bude podrobněji pojednáno níže) stanovit potřebné etapy vývoje, etapy a obsah prací (seznam programových dokumentů, které musí být vypracovány, odsouhlaseny a schváleny), jakož i zpravidla termíny vývoje a určit účinkující.

Standardní kroky jsou popsány zde. Hlavní věc je správně určit načasování. Pokud je to možné, snažte se rovnoměrně rozdělit fáze mezi termíny (a částky). Pamatujte, že ne všechny projekty se dostanou do závěrečné fáze. A pro každou fázi by měly být zprávy. Pamatujte také, že nejvíce času zabere pracovní projekt. Pokud dokumentaci nedokončíte včas, má Zákazník plné právo dílo vůbec nepřevzít se všemi z toho vyplývajícími důsledky.

Hlavními a nepostradatelnými etapami a fázemi jsou samotné zadání, předběžný návrh, technické a pracovní návrhy.

• Předběžný návrh. V této fázi jsou podrobně rozpracovány struktury vstupních a výstupních dat a stanovena forma jejich prezentace. Ve vývoji obecný popis algoritmus, samotný algoritmus, struktura programu. Připravuje se akční plán rozvoje a realizace programu.
• Technický projekt. Obsahuje vyvinutý algoritmus pro řešení problému a také metody pro sledování počátečních informací. Zde jsou vyvíjeny nástroje pro zpracování chyb a vydávání diagnostických zpráv, jsou určeny formuláře pro prezentaci výchozích dat a konfigurace technického vybavení.
• Pracovní návrh. V této fázi se provádí programování a ladění programu, vývoj programových dokumentů, programů a testovacích metod. Příklady testování a ladění se připravují. Dokumentace a grafický materiál jsou dokončeny. Obvykle se uvádí, že během vývoje programu by měla být připravena následující dokumentace:

• text programu;
• popis programu;
• testovací program a metodika;
• popis aplikace;
• uživatelská příručka.

Toto jsou standardní požadavky. Pokud zákazník souhlasí s tím, že nemůže být předložen celý tento seznam, znamená to, že jeho záměry ohledně vás a vašeho produktu nejsou vážné.

Nemusí tam být žádný grafický materiál. Zvlášť když se nechystáte hlásit výsledky své práce. Ale pro seriózní projekty je tato položka vyžadována.

Například: Během vývoje programu by měl být připraven následující grafický materiál:

• technické a ekonomické ukazatele;
• struktura programu;
• formát pro prezentaci vstupních dat programu;
• obecný diagram algoritmu (2 listy);
• základní výpočetní algoritmy;
• ukázka toho, jak program funguje.

V kapitole Kontrolní a akceptační řízení musí být specifikovány typy zkoušek a Obecné požadavky za přijetí práce. Je-li to možné, pak v tomto odstavci uveďte, že „kontrola a akceptace vývoje se provádí pomocí zařízení poskytnutého zákazníkem“, jinak můžete být požádáni, abyste si zařízení přinesli s sebou.

Například: Kontrola a akceptace vývoje jsou prováděny na základě testovacích testů a příkladů ladění. Tím se kontroluje provádění všech funkcí programu.

V Aplikace V případě potřeby technické specifikace poskytne:

• seznam výzkumných a jiných prací odůvodňujících vývoj;
• diagramy algoritmů, tabulky, popisy, zdůvodnění, výpočty a další dokumenty, které lze použít při vývoji;

• další vývojové zdroje.

Tato norma stanoví fáze vývoje programů, programové dokumentace, jakož i fáze a obsah práce:

Vývojové fáze	Fáze práce
Technický úkol	Odůvodnění potřeby rozvíjet program	Formulace problému. Sbírka podkladů. Výběr a zdůvodnění kritérií účinnosti a kvality vyvíjeného programu. Odůvodnění potřeby výzkumné práce.
	Výzkumná práce	Stanovení struktury vstupních a výstupních dat. Předběžný výběr metod řešení problémů. Zdůvodnění proveditelnosti použití dříve vyvinutých programů. Stanovení požadavků na technické prostředky. Zdůvodnění zásadní možnosti řešení problému.
	Vývoj a schvalování technických specifikací	Stanovení požadavků programu. Vypracování studie proveditelnosti pro rozvoj programu. Stanovení etap, etap a načasování vývoje programu a dokumentace k němu. Výběr programovacích jazyků. Stanovení potřeby výzkumných prací v následujících fázích. Koordinace a schvalování technických specifikací.
Předběžný návrh	Vypracování předběžného návrhu	Předběžný vývoj struktury vstupních a výstupních dat. Objasnění metod řešení problému. Vývoj obecného popisu algoritmu pro řešení problému. Vypracování studie proveditelnosti.
	Schválení předběžného návrhu	Koordinace a schválení předběžného projektu
Technický projekt	Technický vývoj projektu	Objasnění struktury vstupních a výstupních dat. Vývoj algoritmu pro řešení problému. Stanovení formy prezentace vstupních a výstupních dat. Definice sémantiky a syntaxe jazyka. Vývoj programové struktury. Konečné určení hardwarové konfigurace.
	Schválení technického provedení	Vypracování akčního plánu pro rozvoj a realizaci programů. Vypracování vysvětlivky. Koordinace a schvalování technického návrhu.
Pracovní návrh	Vývoj programu	Programování a ladění
	Vývoj softwarové dokumentace	Vývoj programových dokumentů v souladu s požadavky GOST 19.101-77.
	Testování programu	Vývoj, koordinace a schvalování zkušebního programu a metodiky. Provádění předběžných státních, meziresortních, přejímacích a jiných typů zkoušek. Oprava programu a programové dokumentace na základě výsledků testů.
Implementace	Příprava a přenos programu	Příprava a přenos programů a softwarové dokumentace pro údržbu a (nebo) výrobu. Registrace a schválení aktu předání programu pro údržbu a (nebo) výrobu. Převod programu do fondu algoritmů a programů.

Poznámky:

1. Je povoleno vyloučit druhou fázi vývoje a v technicky odůvodněných případech druhou a třetí fázi. Potřeba těchto stupňů je uvedena v technických specifikacích.
2. Je povoleno kombinovat, vylučovat etapy prací a (nebo) jejich obsah, jakož i zavádět další etapy prací podle dohody se zákazníkem.

Tato norma je zaměřena na dokumentaci výsledného vývojového produktu.

Přísně vzato jde o dva různé dokumenty, které však mají mnoho společného. Toto je OBECNÝ POPIS (GOST 19.502-78) a POPIS PROGRAMU (GOST 19.402-78). Vzhledem k tomu, že je ale velmi obtížné skutečně kvalitně vytvořit oba dva, aniž bychom se uchýlili k téměř úplné duplikaci a trhání kusů, stačilo by implementovat jeden, obecnější, „hybridní“ dokument. Říkejme tomu „Popis programu“.

Ve skutečnosti může být „Popis programu“ v jeho obsahu doplněn o oddíly a odstavce převzaté z norem pro další popisné dokumenty a příručky: GOST 19.404-79 ESPD. Vysvětlivka, GOST 19.503-79 ESPD. Příručka systémového programátora, GOST 19.504-79 ESPD. Příručka programátora, GOST 19.505-79 ESPD. Návod k obsluze atd. Zejména z vysvětlující poznámky si můžete vzít schéma algoritmu, obecný popis algoritmu a (nebo) fungování programu, jakož i odůvodnění přijatých technických a technicko-ekonomických rozhodnutí.

Popis programu musí obsahovat informační část - anotaci a obsah.

Hlavní část dokumentu by se měla skládat z úvodní části a následujících částí:

• funkční účel;
• popis logiky.
• podmínky použití;
• složení a funkce.

V závislosti na specifikách programu mohou být zavedeny další sekce.

V Úvodní část Dokument poskytuje obecné informace o programu - celý název, označení, jeho možné aplikace atd.

Například: Program "Automat pracoviště ACS developer“ je určen pro... implementován na.... Program podporuje...

V kapitole Účel uveďte účel programu a uveďte obecný popis fungování programu, jeho hlavní charakteristiky, informace o omezeních uložených na rozsah programu a také uveďte typy elektronických počítačů a zařízení, které se používají během provozu.

Například: Program je určen k řešení problémů... Program představuje jádro automatizované pracovní stanice...

Uživatel má možnost..., implementovat..., spustit..., analyzovat..., získat výsledky analýzy a zpracování..., postavit..., atd.

V kapitole" Popis logiky"uveďte:

• popis struktury programu a jeho hlavních částí

(například: Program obsahuje následující:

• uživatelské rozhraní,
• modul pro určování cest v grafu,
• modul výpočtu přenosové funkce,
• modul pro konstrukci amplitudových a fázových frekvenčních charakteristik,
• modul pro konstrukci reakce na polynomiální vliv,
• textový editor) .

• popis funkcí komponent a spojení mezi nimi;

Například: Program se skládá ze šesti modulů: modul rozhraní; definiční modul...; výpočetní modul...; modul...atd..

Modul rozhraní je postaven na dvou typech dialogů: dialogu otázka-odpověď a dialogu typu menu. Modul rozhraní ovládá...

Definiční modul... Je to...

Výpočtový modul...atd.

• informace o programovacím jazyce;

Například: Program je napsán v jazyce ... pomocí kompilátoru ...

• popis vstupních a výstupních dat pro každou z komponent;

Například: INPUT DATA. Vstupními daty pro program je textový soubor popisující rozšířenou matici výskytu grafu studovaného systému.

VÝSTUP. Výstup je:

• grafické a textové informace zobrazené na obrazovce (výsledky systémové analýzy);
• soubory v jednom z grafických formátů- kopie obrazu konstruovaných charakteristik (AFC, PFC atd.);
• textové soubory - zprávy o provedeném výzkumu;
• diagnostiku stavu systému a zprávy o všech chybách, které se vyskytnou.

• popis logiky součástí (v případě potřeby by měl být napsán popis schémat programu).

Při popisu programové logiky je nutný odkaz na text programu.

V kapitole Složení a funkce uveďte popis složení a funkce programů a metod používaných k řešení problémů.

V kapitole Podmínky použití jsou uvedeny podmínky nezbytné pro realizaci programu (požadavky na technické prostředky nezbytné pro tento program a další programy, Obecná charakteristika vstupní a výstupní informace, dále požadavky a podmínky organizačního, technického a technologického charakteru apod.).

Například: Program je spuštěn osobní počítač(PC) typu IBM PC/AT. Pro práci v interaktivním režimu se používá displej, klávesnice a myš. Pro podporu grafického režimu je vyžadován adaptér EGA (VGA). Vstupní data jsou uložena na disketách a/nebo pevných discích. Program běží pod OS...

Příloha k popisu může obsahovat referenční materiály (ilustrace, tabulky, grafy, příklady atd.)

A nezapomeňte uvést název načítacího modulu a také popis celého postupu

Volání a bootování systému

Požadavky na návrh programového textu jsou poměrně jednoduché a pro kompetentního programátora přirozené. Hlavní věcí, kterou je třeba se řídit při vytváření tohoto dokumentu, je, že text programu by měl být čitelný.

Stále je povinné sestavit informační část - anotace a obsah.

Hlavní část dokumentu by měla tvořit texty jedné nebo více sekcí, které jsou pojmenovány.

Text všech soubor programu začíná „hlavičkou“, která říká:

• název programu,
• autor,
• datum vytvoření programu,
• číslo verze,
• datum poslední úpravy.

Komentáře jsou povinné, stejně jako přísné dodržování pravidel pro odsazení. Pamatujte, že i neschopnost vytvořit softwarovou dokumentaci lze ospravedlnit. Ale ošklivý text programu - nikdy. Odkazy na to, že tento text je srozumitelný i samotnému autorovi, nebereme vážně. Neměla by být ostuda dávat texty programu ke čtení dalším lidem.

Níže je uveden příklad takového dobře čitelného textu programu (převzato z webu Nikolaje Gekhta, e-mail: [e-mail chráněný], http://users.omskreg.ru/~geht)

/* Zdroje Windows 98

Zdrojový kód pro Windows 98 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" # define INSTALL = HARD char make_prog_look_big; VOID Main () (While (! CraShed) (Display_copyright_message (); Display_bill_rules_message (); do_nothing_loop (); if (první_instalace) yte_swapfile (); do_nothing_loop (); totilla_screw_file_up_systemofs); netscape (); zakázat_RealPlayer (); disable_Corel_Products(); hang_system(); ) write_something(cokoliv); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(stále_nehavaroval) (display_copyright_message(); do_nothing_loop(); (; basic_run_window_3.1 ); do_nothing_loop(); ) ) if(detect_cache()) disable_cache(); if(fast_cpu()) ( set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(action, jumpy); set_mouse(reaction, někdy ) ; ) /* printf("Vítejte ve Windows 3.11"); */ /* printf("Vítejte ve Windows 95"); */ printf("Vítejte ve 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ánek(5); act_on_user_input(); spánek(5); ) create_general_protection_fault();

Tento dokument obsahuje popis toho, co a jak je třeba udělat, abyste se ujistili (a přesvědčili zákazníka), že program funguje správně. Ve skutečnosti je tento dokument rozhodující pro přejímací zkoušky. Dobře navržený testovací program a metodika je klíčem k podpisu akceptačního certifikátu, tzn. věc, za kterou jsi vynaložil tolik úsilí a času.

Formálně se tento GOST používá k vývoji plánovacích dokumentů a provádění zkušebních prací k posouzení připravenosti a kvality softwarového systému. Dokument obsahuje popis předmětu a účelu testování, požadavky na programovou a softwarovou dokumentaci, prostředky a postup testování a také popis testovacích příkladů.

Komponenty tohoto dokumentu jsou snadněji a přehledněji popsány ve formě příkladů.

Testovací objekt

Příklad: Testovacím objektem je program ..., určený pro ...

Účel testování

Příklad: Kontrola spolehlivosti programu.

Požadavky na program

Příklad: Provoz programu by neměl vést k poruše (fatálnímu narušení systému). Organizace dialogu by měla zajistit ochranu před zadáním nesprávných údajů. Program by měl poskytovat diagnostiku stavu systému a zprávy o případných chybách, které se vyskytly...atd.

Požadavky na dokumentaci k softwaru

Příklad: Obsah softwarové dokumentace prezentované během testování:

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

Testovací prostředky a postup

Příklad: Program pracuje v souladu s provozními podmínkami operačního systému MS DOS (verze ne nižší než 3.0) na PC, jako je IBM PC/AT, i na kompatibilních. K provozu je také nutný adaptér EGA (VGA).

Postup testu:

1. Program je spuštěn….
2. Vybraný...
3. Lisováno...
4. Postupně vybrané...

Testovací případy

Příklad: Pro testování jsou navrženy ..., jejichž popisy jsou obsaženy v souborech ... Obsah testovacích souborů a výsledky programu jsou uvedeny v příloze 1.

A nakonec se podívejme na poslední standard ESPD který se nazývá

Tato norma stanoví pravidla pro provádění programových dokumentů pro počítače, komplexy a systémy, bez ohledu na jejich účel a rozsah použití a stanovená normami ESPD.

Obecné požadavky. Je nutné zadávat jednotlivá slova, vzorce, symboly (ručně kreslicím písmem), písmena latinské a řecké abecedy, jakož i kreslit schémata a kresby v programových dokumentech vytvořených strojopisem, strojem a rukopisem, černým inkoustem. nebo inkoust.

Překlepy a grafické nepřesnosti zjištěné během procesu provádění lze opravit vymazáním špatně provedené části textu (kresby) a aplikací opraveného textu (grafiky) na stejný list strojopisem nebo černým inkoustem, v závislosti na způsobu provedení. dokument.

Poškození listů dokumentů, skvrny a stopy po neúplně smazaném textu (grafice) nejsou povoleny.

Programové dokumenty jsou vypracovány na listech A4. Kromě:

• Je přijatelné tisknout na listy A3;
• při strojovém způsobu provedení dokumentu jsou přípustné odchylky ve velikosti listů odpovídající formátům A4 a A3, dané možnostmi použitých technických prostředků; na listech formátu A4 a A3, zajištěných výstupními charakteristikami zařízení pro výstup dat, při strojové výrobě dokumentu;
• Při výrobě dokumentu typografickou metodou je možné použít listy typografických formátů.

Materiály programového dokumentu jsou uspořádány v následujícím pořadí:

• titulní díl:

• schvalovací list (nezapočítává se do celkového počtu listů dokumentu);
• titulní strana (první strana dokumentu);

• informační část:

• anotace;
• obsah;

• hlavní část:

• text dokumentu (s obrázky, tabulkami atd.);
• seznam pojmů a jejich definice;
• seznam zkratek;
• aplikace;
• předmětový rejstřík;
• seznam referenčních dokumentů;

• změnit logovací část:

• změnit registrační list.

Konstrukce dokumentu. V případě potřeby je povoleno rozdělit dokument na části. Rozdělení na části se provádí na úrovni ne nižší než sekce. Každá část se vyplňuje samostatně a na konci obsahu první části by měly být uvedeny názvy zbývajících částí.

Do dokumentu je povoleno zahrnout části textu programu, formátované v souladu s pravidly jazyka, ve kterém je text programu napsán.

Abstrakt je zveřejněn na samostatná stránka(strany), opatřené záhlavím „ABSTRAKT“, očíslované a zahrnuté do obsahu dokumentu.

Text každého dokumentu je v případě potřeby rozdělen na odstavce a odstavce na pododstavce, bez ohledu na to, zda je dokument rozdělen na části, oddíly a pododdíly či nikoli.

Nadpisy oddílů jsou psány velkými písmeny a umístěny symetricky vzhledem k pravému a levému okraji textu. Nadpisy pododdílů se píší z odstavce malá písmena(kromě prvního hlavního města). Dělení slov v nadpisech není povoleno. Na konci názvu není žádná tečka. Doporučuje se začít každou sekci na novém listu.

Oddíly, pododdíly, odstavce a pododstavce by měly být číslovány arabskými číslicemi s tečkou. Sekce musí mít pořadové číslo (1, 2 atd.)

Text dokumentu. Text dokumentu by měl být krátký, jasný, vylučující možnost nesprávného výkladu. Termíny a definice musí být jednotné a v souladu se zavedenými normami a v případě jejich absence - obecně uznávané ve vědecké a technické literatuře a musí být uvedeny v seznamu termínů.

Potřebná vysvětlení k textu dokumentu lze uvést v poznámkách pod čarou. Poznámka pod čarou je označena číslem se závorkou umístěnou na úrovni horního okraje písma.

Odkazuje-li poznámka pod čarou na jediné slovo, je znak poznámky pod čarou umístěn přímo u tohoto slova, pokud však odkazuje na větu jako celek, pak na konec věty. Text poznámky pod čarou je umístěn na konci stránky a oddělen od hlavního textu 3 cm dlouhou čarou nakreslenou na levé straně stránky.

Ilustrace. Ilustrace mohou být umístěny v textu dokumentu a (nebo) v přílohách. Ilustrace, pokud je jich v daném dokumentu více, jsou v celém dokumentu číslovány arabskými číslicemi.

V přílohách jsou ilustrace v každé příloze číslovány v pořadí stanoveném pro hlavní text dokumentu. Odkazy na obrázky jsou uvedeny podle typu: „obr. 12“ nebo „(obr. 12)“. Ilustrace mohou mít tematický název a text popisku vysvětlující obsah ilustrace.

Vzorce. Vzorce v dokumentu, pokud jich je více, jsou číslovány arabskými číslicemi, číslo je umístěno s pravá strana stránky, v závorkách na úrovni vzorce. V rámci celého dokumentu nebo jeho částí, pokud je dokument rozdělen na části, mají vzorce průběžné číslování.

Odkazy v textu na pořadové číslo vzorce jsou uvedeny v závorkách, například: „ve vzorci (3)“. Při rozdělování dokumentu na části se číslo dílu umístí před pořadové číslo vzorce a oddělí se od poslední tečky, například: „ve vzorci (1.4)“.

Význam symbolů obsažených ve vzorci musí být uveden přímo pod vzorcem. Význam každého znaku se vytiskne na nový řádek v pořadí, v jakém jsou uvedeny ve vzorci. První řádek přepisu by měl začínat slovem „kde“ bez dvojtečky za ním.

Odkazy. V dokumentech zásad jsou povoleny odkazy na normy a další dokumenty. Měl by být uveden odkaz na dokument jako celek nebo na jeho části (s uvedením označení a názvu dokumentu, čísla a názvu oddílu nebo přílohy).

Je povoleno uvést pouze označení dokumentu a (nebo) oddílů bez uvedení jejich jmen. Odkazy na jednotlivé pododstavce, odstavce a ilustrace jiného dokumentu nejsou povoleny. V rámci dokumentu jsou povoleny odkazy na odstavce, ilustrace a jednotlivé podsekce.

Poznámky Poznámky k textu a tabulkám uvádějí pouze referenční a vysvětlující údaje. Jedna poznámka není očíslována. Za slovo "Poznámka" vložte tečku. Několik poznámek by mělo být očíslováno v pořadí pomocí arabských číslic s tečkou. Za slovo "Poznámka" vložte dvojtečku. Text poznámek lze tisknout pouze v jednom intervalu.

Zkratky. Zkratky slov v textu a nápisy pod obrázky nejsou povoleny, s výjimkou:

• zkratky stanovené v GOST 2.316-68 a obecně přijímané v ruském jazyce;
• zkratky používané k označení programů, jejich částí a provozních režimů, v jazycích pro řízení úloh, v nástrojích pro konfiguraci programu atd., označované písmeny latinské abecedy.

Aplikace. Ilustrovaný materiál, tabulky nebo podpůrný text mohou být uvedeny ve formě příloh. Aplikace jsou koncipovány jako pokračování tohoto dokumentu na dalších stránkách nebo vydán jako samostatný dokument.

Každá aplikace musí začínat nová stránka s označením vpravo horní roh slova „Aplikace“ a mají tematický název. Pokud je v dokumentu více než jedna příloha, jsou všechny přílohy očíslovány arabskými číslicemi (bez znaku č.), například:

Dodatek 1, Dodatek 2 atd.

Při uvolnění aplikace jako samostatného dokumentu, na titulní strana Pod názvem dokumentu by mělo být uvedeno slovo „Příloha“, a pokud existuje několik příloh, mělo by být uvedeno také jeho sériové číslo.

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

Jednotný systém programové dokumentace	GOST 19.402-78* (ST SEV 2092-80)
POPIS PROGRAMU
Sjednocený systém pro dokumentaci programu. Popis programu

Výnosem Státního výboru pro normy SSSR ze dne 18. prosince 1978 č. 3350 bylo stanoveno datum zavedení

od 01.01. 1980

1. Tato norma stanoví složení a požadavky na obsah programového dokumentu „Popis programu“, definovaného GOST 19.101-77.

Norma plně vyhovuje ST SEV 2092-80.

2. Struktura a formát dokumentu jsou stanoveny v souladu s GOST 19.105-78.

Vypracování informační části (anotace a obsah) je povinné.

3. Popis programu musí obsahovat následující části:

obecná informace;

funkční účel;

popis logické struktury;

použité technické prostředky;

vstupní data;

výstup.

V závislosti na vlastnostech programu je možné zavádět další sekce nebo jednotlivé sekce kombinovat.

4. V části „Všeobecné informace“ musí být uvedeno:

označení a název programu;

software nezbytný pro provoz programu;

programovací jazyky, ve kterých je program napsán.

5. Sekce „Functional Purpose“ musí uvádět třídy problémů, které se řeší, a (nebo) účel programu a informace o funkčních omezeních použití.

6. V části „Popis logické struktury“ by mělo být uvedeno:

programový algoritmus;

použité metody;

struktura programu s popisem funkcí jeho součástí a vazeb mezi nimi;

propojení programu s jinými programy.

Popis logické struktury programu se provádí s přihlédnutím k textu programu ve zdrojovém jazyce.

3-6.(Změněné vydání, dodatek č. 1).

7. V části „Použité technické nástroje“ musí být uvedeny typy elektronických počítačů a zařízení, které se používají při spouštění programu.

způsob volání programu z odpovídajícího paměťového média;

vstupní body do programu.

Můžete zadat adresy pro stahování, informace o využití paměti RAM a velikosti programu.

9. V části „Vstupní data“ musí být uvedeno:

charakter, organizace a předběžná příprava vstupních dat;

formát, popis a způsob kódování vstupních dat.

10. V části „Výstupní data“ musí být uvedeno:

povaha a organizace výstupních dat;

formát, popis a způsob kódování výstupních dat.

11. Obsah oddílů je dovoleno ilustrovat vysvětlujícími příklady, tabulkami, schématy, grafy.

12. Příloha k popisu programu může obsahovat různé materiály, které není vhodné zahrnout do částí popisu.

7-12.(Vloženo dodatečně, změna č. 1).

* Opětovné vydání (listopad 1987) se změnou č. 1, schváleno v září 1981 (IUS 11-81)

MEZISTÁTNÍ STANDARD

Norma plně vyhovuje ST SEV 2092-80.

2. Struktura a formát dokumentu jsou stanoveny v souladu s GOST 19.105-78.

Vypracování informační části (anotace a obsah) je povinné.

3. Popis programu musí obsahovat následující části:

vstupní data;

výstup.

V závislosti na vlastnostech programu je možné zavádět další sekce nebo jednotlivé sekce kombinovat.

4. V části „Všeobecné informace“ musí být uvedeno:

označení a název programu;

použité metody;

struktura programu s popisem funkcí jeho součástí a vazeb mezi nimi;

propojení programu s jinými programy.

Popis logické struktury programu se provádí s přihlédnutím k textu programu ve zdrojovém jazyce.

3-6.(Změněné vydání, dodatek č. 1).

7. V části „Použité technické prostředky“ musí být uvedeny typy elektronických počítačů a zařízení, které se používají při spouštění programu.

charakter, organizace a předběžná příprava vstupních dat;

formát, popis a způsob kódování vstupních dat.

10. V části „Výstupní data“ musí být uvedeno:

povaha a organizace výstupních dat;

formát, popis a způsob kódování výstupních dat.

11. Obsah oddílů je dovoleno ilustrovat vysvětlujícími příklady, tabulkami, schématy, grafy.

12. Příloha k popisu programu může obsahovat různé materiály, které není vhodné zahrnout do částí popisu.

7-12.(Vloženo dodatečně, změna č. 1).

Výnosem Státního výboru pro normy SSSR ze dne 18. prosince 1978 č. 3350 bylo stanoveno datum zavedení

od 01.01. 1980

1. Tato norma stanoví složení a požadavky na obsah programového dokumentu „Popis programu“, definovaného GOST 19.101-77.

Norma plně vyhovuje ST SEV 2092-80.

2. Struktura a provedení dokumentu jsou stanoveny v souladu s GOST 19.105-78.

Vypracování informační části (anotace a obsah) je povinné.

3. Popis programu musí obsahovat následující části:

• obecná informace;
• funkční účel;
• popis logické struktury;
• použité technické prostředky;
• vstupní data;
• výstup.

V závislosti na vlastnostech programu je možné zavádět další sekce nebo jednotlivé sekce kombinovat.

4. V části „Všeobecné informace“ musí být uvedeno:

• označení a název programu;
• software nezbytný pro provoz programu;
• programovací jazyky, ve kterých je program napsán.

5. Sekce „Functional Purpose“ musí uvádět třídy problémů, které se řeší, a (nebo) účel programu a informace o funkčních omezeních použití.

6. V části „Popis logické struktury“ by mělo být uvedeno:

• programový algoritmus;
• použité metody;
• struktura programu s popisem funkcí jeho součástí a vazeb mezi nimi;
• propojení programu s jinými programy.

Popis logické struktury programu se provádí s přihlédnutím k textu programu ve zdrojovém jazyce.

3-6.(Změněné vydání, dodatek č. 1).

7. V části „Použité technické nástroje“ musí být uvedeny typy elektronických počítačů a zařízení, které se používají při spouštění programu.

• způsob volání programu z odpovídajícího paměťového média;
• vstupní body do programu.

Můžete zadat adresy pro stahování, informace o využití paměti RAM a velikosti programu.

9. V části „Vstupní data“ musí být uvedeno:

• charakter, organizace a předběžná příprava vstupních dat;
• formát, popis a způsob kódování vstupních dat.

10. V části „Výstupní data“ musí být uvedeno:

• povaha a organizace výstupních dat;
• formát, popis a způsob kódování výstupních dat.

11. Obsah oddílů je dovoleno ilustrovat vysvětlujícími příklady, tabulkami, schématy, grafy.

12. Příloha k popisu programu může obsahovat různé materiály, které není vhodné zahrnout do částí popisu.

7-12.(Vloženo dodatečně, změna č. 1).

* Opětovné vydání (listopad 1987) se změnou č. 1, schváleno v září 1981 (IUS 11-81)