Dokumentumok kijelölése a GOST szerint 19. A program tervezése a GOST szerint (hogyan kell). Számítógépes ismeretek gyakorlata

V.E. Karpov

Ez a dokumentum az ESPD szabványok rövid leírását tartalmazza, amelyek ismerete szükséges a hallgatóknak a szoftverrendszerek létrehozásával kapcsolatos kurzusok és projektek teljesítéséhez. Ezenkívül hasznos lehet a programdokumentáció általános minőségének javítása szempontjából.

SZABÁLYOZÁSI FELTÉTELEK (GOST 19.201-78)

1. Általános rendelkezések

FEJLESZTÉSI SZAKASZOK (GOST 19.102-77)

A PROGRAM LEÍRÁSA (GOST 19.402-78)

PROGRAMSZÖVEG (GOST 19.401-78)

PROGRAM ÉS VIZSGÁLATI MÓDSZEREK (GOST 19.301-79)

NYOMTATÁSI MÓDSZEREL KÉSZÜLT PROGRAMDOKUMENTUMOKRA VONATKOZÓ KÖVETELMÉNYEK (GOST 19.106-78)

Szabványosítás a szoftverdokumentáció területén

Hogyan haladjunk előre

A szoftvereszközök (PS) dokumentációjának elkészítése a meglévő GOST-oknak megfelelően

2. Az állam általános jellemzői

2.3. Az Orosz Föderáció állami szabványai (GOST R)

2.4. ISO/IEC 12207 nemzetközi szabvány: 1995-08-01

A programozási munka talán legkellemetlenebb és legnehezebb szakasza a programdokumentáció elkészítése. Sajnos általában ezt vagy egyáltalán nem tanítják, vagy jó esetben nem fordítanak kellő figyelmet a beérkezett dokumentumok minőségére. Ennek a művészetnek az elsajátítása azonban gyakran az egyik legfontosabb tényező a programozó minőségének meghatározásában.

Először is, a programdokumentáció készítésének képessége határozza meg a programozó szakmai szintjét. Az ügyfél még a legcsodálatosabb program finomságaiba és jellemzőibe sem fog belemenni. Az ügyfél először olvassa el a dokumentációt. Ebben a pszichológiai tényező is fontos szerepet játszik. Különösen az egykori szovjet programozási iskola volt nagyra értékelve (és jelenleg is nagyra értékelik) az egész világon. A modern hazai programozókat megszűnt idézni. Az osztály nem ugyanaz. Manapság már nem írnak programokat, hanem összeállítanak (és ez "két nagy különbség"). Tehát a "klasszikus" stílusban elkészített szoftver dokumentációs csomag (továbbiakban PD) a legkedvezőbb benyomást keltheti ügyfelében vagy munkáltatójában. Különösen, ha a PD szerzője kerüli az olyan kifejezéseket, mint "kattintson a görgetősávra ...", "csavar" stb. Sajnos az ilyen szlengcsevegés általában vagy a gondolatok szűkösségét vagy a teljes ürességet rejti (a szerzőt kitörölhetetlenül lenyűgözte egyik ismerősének története egy bizonyos "játékosról", aki vagy "csacsogott" valakivel ott, vagy "moderálással" foglalkozott. "vagy valami ilyesmi.). A PD nyelve egyfajta bürokratikus, nagyon konzervatív nyelv. Megvan a maga különleges varázsa. Fogadja el, hogy a merevlemez-meghajtó, hajlékonylemez-meghajtó, kézi manipulátor, például az "egér" (vagy a "kolobok", ahogyan az egyik régi PD-csomagban volt) kifejezések teljesen másként hangzanak, mint a megfelelő "csavar", "flop" és egyszerűen "egér". Amúgy már odáig jutottak a dolgok, hogy állítólag még egy különleges specialitás is megjelent - egy műszaki író, i.e. olyan személy, aki szoftverdokumentációt tud készíteni.

Másodszor, egy jól összeállított (pontosabban megalkotott) PD-csomag sok bajtól kímél meg. Különösen megszabadulhat a bosszantó kérdésektől és megalapozatlan állításoktól, ha egyszerűen a felhasználót a dokumentációhoz irányítja. Ez mindenekelőtt a legfontosabb dokumentumot – a feladatmeghatározást – érinti. Az alábbiakban erről lesz szó, most pedig felidézhetjük az IBM elleni több millió dolláros pert. Ezt a keresetet egy jelentős kiadó nyújtotta be, elégedetlen a BT és a szoftver minőségével. Az IBM nyerte az ügyet. És csak annak köszönhetően nyert, hogy bemutatta a mindkét fél által aláírt feladatmeghatározást. Nagyon régen volt, még a 70-es években, de ez nem változtat a dolog lényegén.

Még egy dolog. Fontos az első PD-csomag létrehozása. Ez elegendő lesz ahhoz, hogy az összes következőt ennek alapján építse fel, modellként vagy sablonként használva. De nagyon jól kell csinálni. Kényelmes. Nagyon alapos.

Először is fel kell vértezni magát a GOST-okkal. A GOST mindent meghatároz. Ez magában foglalja a minket érdeklő egységes programdokumentációs rendszert (ESPD) is. Talán a legnehezebb dolog magának a GOST-nak a beszerzése. A GOST csak nyomtatott eredeti formában legyen. Szaküzletekben árulják (legalábbis régen). A dokumentáció területén a szabványok megszerzéséhez különösen a következő szervezetekkel fordulhat:

IPK "Standards Publishing House", Tudományos és Műszaki Dokumentumok Terjesztésének Területi Osztálya ("Standards" bolt), 17961, Moszkva, st. Donskaya, 8. sz., tel. 236-50-34, 237-00-02, fax/tel. 236-34-48 (a GOST és a GOST R tekintetében).
VNIIKI of the State Standard of Russia (olvasóterem), 103001, Moszkva, Granatny per. 4, tel. 290-50-94 (nemzetközi, külföldi szabványok és egyéb tudományos és műszaki dokumentumok tekintetében).

És nincsenek idézetek és másodlagos források. A GOST a törvény. És még inkább, nincs internet (képzeljük el, hogy a bíróság ítéletet hoz a Büntető Törvénykönyv valamely oldalról letöltött kinyomtatása alapján). Ne bízz senkiben, csak az eredetiben. A szerzőnek azonban a továbbiakban az ESPD-re kell hivatkoznia, miközben mentesül minden felelősség alól.

Kezdjük az egységes programdokumentációs rendszer általános rendelkezéseivel (amelyeket a megfelelő GOST 19.001-77 szabvány is meghatároz).

A programdokumentáció egységes rendszere olyan állami szabványok összessége, amelyek összefüggő szabályokat állapítanak meg a programok és a programdokumentáció fejlesztésére, tervezésére és forgalmazására.

Az ESPD szabványok meghatározzák az általános rendelkezéseket és az alapszabványokat, a fejlesztési dokumentáció megvalósításának szabályait, a gyártási dokumentáció végrehajtásának szabályait, a karbantartási dokumentáció végrehajtásának szabályait, az üzemeltetési dokumentáció végrehajtásának szabályait, az üzemeltetési dokumentáció végrehajtásának szabályait programdokumentáció és egyéb szabványok kezelése. Az ESPD a következőket tartalmazza:

alapvető és szervezeti és módszertani szabványok;
szabványok, amelyek meghatározzák az adatfeldolgozás során használt programdokumentumok formáit és tartalmát;
szabványok, amelyek automatizálják a programdokumentumok fejlesztését.

Általában véve az ESPD dokumentumok listája nagyon kiterjedt. Különösen a következő GOST-okat tartalmazza:

GOST 19.001-77 ESPD. Általános rendelkezések.
GOST 19.101-77 ESPD. Műsortípusok és programdokumentumok (1987. novemberében, módosításokkal újra kiadva).
GOST 19.102-77 ESPD. Fejlesztési szakaszok.
GOST 19.103-77 ESPD. Programok és programdokumentumok kijelölése.
GOST 19.104-78 ESPD. Alapfeliratok.
GOST 19.105-78 ESPD. A programdokumentumokra vonatkozó általános követelmények.
GOST 19.106-78 ESPD. A nyomtatott formában készült programdokumentumokkal szemben támasztott követelmények.
GOST 19.201-78 ESPD. Műszaki feladat. A tartalommal és a dizájnnal szemben támasztott követelmények.
GOST 19.202-78 ESPD. Leírás. A tartalommal és a dizájnnal szemben támasztott követelmények.
GOST 19.301-79 ESPD. Program és vizsgálati eljárás.
GOST 19.401-78 ESPD. Program szövege. A tartalommal és a dizájnnal szemben támasztott követelmények.
GOST 19.402-78 ESPD. Program leírása.
GOST 19.404-79 ESPD. Magyarázó jegyzet. A tartalommal és a dizájnnal szemben támasztott követelmények.
GOST 19.501-78 ESPD. Forma. A tartalommal és a dizájnnal szemben támasztott követelmények.
GOST 19.502-78 ESPD. Az alkalmazás leírása. A tartalommal és a dizájnnal szemben támasztott követelmények.
GOST 19.503-79 ESPD. Rendszerprogramozói útmutató. A tartalommal és a dizájnnal szemben támasztott követelmények.
GOST 19.504-79 ESPD. Programozói útmutató.
GOST 19.505-79 ESPD. Kezelési kézikönyv.
GOST 19.506-79 ESPD. A nyelv leírása.
GOST 19.508-79 ESPD. Karbantartási leírás. A tartalommal és a dizájnnal szemben támasztott követelmények.
GOST 19.604-78 ESPD. A nyomtatott programdokumentumok módosításának szabályai.
GOST 19.701-90 ESPD. Algoritmusok, programok, adatok és rendszerek sémái. Konvenciók és végrehajtási szabályok.
GOST 19.781-90. Információfeldolgozó rendszerszoftverek biztosítása.

Mint látható, az ESPD komplexum fő részét a 70-es és 80-as években fejlesztették ki. Ezek a szabványok részben elavultak, ráadásul bizonyos hiányosságoktól sem mentesek. Egyrészt nem tükrözik a programok és a programdokumentáció tervezésének néhány modern trendjét, másrészt ezek a szabványok a programdokumentáció töredékeinek többszörös megkettőzését tartalmazzák. Jobb híján azonban rájuk kell koncentrálni.

Tehát az ESPD szabványok leegyszerűsítik a szoftverrendszerek dokumentálásának folyamatát. Egyrészt azonban az ESPD szabványok által előírt programdokumentumok összetétele egyáltalán nem olyan „merev”, mint amilyennek tűnhet: a szabványok lehetővé teszik további típusok felvételét a szoftverrendszer (PS) dokumentációs készletébe, másrészt a vevői igények alapján néhány változás mind szerkezetében, mind tartalmában a kialakult PD típusoknál. Ezenkívül meg kell jegyezni, hogy az ESPD szabványok (és ez vonatkozik a PS területén minden más szabványra is - GOST 34, az ISO / IEC nemzetközi szabvány stb.) tanácsadó jellegűek. Az a tény, hogy az Orosz Föderáció "szabványosítási törvényének" megfelelően ezek a szabványok szerződéses alapon kötelezővé válnak - pl. amikor a PS fejlesztési (szállítási) szerződésében hivatkozik rájuk.

Mielőtt rátérnénk a programdokumentáció összeállításának szabályaira, meg kell tenni a következő megjegyzést. Célszerű minden dokumentumot megelőzni némi bevezetéssel. A bevezetés általános. A relevanciáról, szükségességről stb. A Vállalkozó célja itt az, hogy bemutassa ennek a munkának a jelentőségét és szükségességét. Az eleje általában szabványos: "A számos jelenleg létező rendszer ... ... valódi kilátásokat nyit ..." stb. Ide szoktak beszúrni különféle alakok beszédeiből vett idézeteket (ez pusztán lélektani szempont): "... ahogy a legutóbbi plénumon, kongresszuson, konferencián stb. hangzott el. Kezdheti azzal is, hogy ". .. Ma, a bennszülött társadalmi-gazdasági átalakulások korszakában... stb. "Általában az a lényeg, hogy ne vigyük túlzásba.

És tovább. A termék leírása során a fejlesztő gyakran összekeveri az alkatrész és a komplex fogalmát. Ezek különböző típusú programok. A komponens definíciója szerint "egy egészként tekintett program, amely teljes funkciót lát el, és önállóan vagy egy komplexum részeként használják", a komplex pedig "két vagy több összetevőből és (vagy) komplexumból álló program, amely egymással összefüggő funkciókat lát el. , és önállóan vagy egy másik komplexen belül használható.

A GOST szerint ez a szabvány (újra kiadva 1987 novemberében) meghatározza a számítógépekhez, komplexekhez és rendszerekhez készült programok vagy szoftvertermékek fejlesztéséhez szükséges műszaki előírások megalkotásának és végrehajtásának eljárását, függetlenül azok céljától és hatókörétől.

Az elkészítésekor rendkívül óvatosnak és körültekintőnek kell lennünk, mert. gyakran ügyesen (és hozzáértően) megszerkesztett TOR meghatározza minden munka sikerét. A TOR-ban állapodnak meg az Ügyféllel, aki általában arra törekszik, hogy minél több egymásnak ellentmondó és túlzó követelményt fogalmazzon meg. A Végrehajtó feladata éppen ellenkezőleg, hogy megkönnyítse saját életét. De miután mindkét oldal aláírása megtörtént, már túl késő bármit is lejátszani.

A feladatmeghatározás általában A4-es és/vagy A3-as formátumú lapokon készül, a lap mezőinek kitöltése nélkül. A lapok (oldalak) száma a lap tetején, a szöveg felett található.

A technikai háttér módosításához és kiegészítéséhez a program vagy szoftvertermék fejlesztésének későbbi szakaszaiban egy kiegészítést adunk ki. A feladatmeghatározás kiegészítésének egyeztetése és jóváhagyása a feladatmeghatározásnál megállapítottakkal megegyező módon történik.

A feladatmeghatározásnak a következő szakaszokat kell tartalmaznia:

név és hatókör;
a fejlesztés alapja;
fejlesztés célja;
a program vagy szoftvertermék műszaki követelményei;
a fejlődés szakaszai és szakaszai;
ellenőrzési és átvételi eljárás;
alkalmazások.

A program vagy szoftver termék jellemzőitől függően megengedett a szakaszok tartalmának pontosítása, új szakaszok bevezetése vagy egyesítése.

fejezetben Név és hatókör feltünteti a program vagy szoftvertermék nevét, rövid leírását a hatóköréről és az objektumról, amelyben a programot vagy szoftverterméket használják.

fejezetben A fejlesztés alapja meg kell adni:

dokumentum (okiratok), amelyek alapján a fejlesztést végzik;
a dokumentumot jóváhagyó szervezet és a jóváhagyás dátuma;
a fejlesztési téma neve és (vagy) jelképe.

Az oktatási folyamat sajátosságaira tekintettel a kurzustervezési megbízás, az intézet __.__ keltezésű megrendelése szolgálhat alapul. N ___., szerződés __.__. N___ számára. stb.

fejezetben A fejlesztés célja fel kell tüntetni a program vagy szoftvertermék funkcionális és működési célját. Itt egy vagy két kifejezésre korlátozhatja magát. A lényeg az, hogy egyértelműen meghatározzuk, mire való ez a program.

Például: A program a folyamatos lineáris automatikus vezérlőrendszerek (ACS) fejlesztője automatizált munkaállomásának (AWS) magja, amely lehetővé teszi a felhasználó számára, hogy megoldja az egyszerű modellek elemzésével kapcsolatos problémákat.

Fejezet A program vagy szoftvertermék műszaki követelményei a következő alszakaszokat kell tartalmaznia:

teljesítménykövetelmények;
megbízhatósági követelmények;
használati feltételek;
a műszaki eszközök összetételére és paramétereire vonatkozó követelmények;
információk és szoftverek kompatibilitására vonatkozó követelmények;
a címkézésre és a csomagolásra vonatkozó követelmények;
a szállításra és tárolásra vonatkozó követelmények;
speciális követelmények.

Más szóval, itt kezdődnek a konkrétumok. Leírja, mit kell tennie a programnak és hogyan kell kinéznie.

teljesítménykövetelmények. Itt kell feltüntetni az ellátott funkciók összetételére, a bemeneti és kimeneti adatok szervezésére, az időbeli jellemzőkre stb. vonatkozó követelményeket.

Például: A programnak lehetővé kell tennie ... kiszámítását ... felépítését ... létrehozását ...

Kiinduló adat: egy szöveges fájl adott ...

Kimeneti adatok: grafikus és szöveges információk - a rendszer elemzésének eredményei...; szöveges fájlok - jelentések ... a rendszer állapotának diagnosztizálásáról és az esetleges hibák jelentéséről.

megbízhatósági követelmények. Meg kell határozni a megbízható működés biztosításának követelményeit (stabil működés biztosítása, bemeneti és kimeneti információk ellenőrzése, meghibásodás utáni helyreállítási idő stb.).

Nehéz itt valamit "kitalálni". A legjobb esetben egy olyan változat is áthaladhat, amelyben a program csak teljesen helyes adatokkal működik. Általában az Ügyfél ebbe nem egyezik bele, de megpróbálhatja.

Például: A programnak a vizsgált gráf adott kiterjesztett előfordulási mátrixával kell működnie a működési algoritmusnak megfelelően, hibaüzeneteket kell kiadnia, ha a kezdeti adatok hibásan vannak megadva, támogatnia kell az interaktív módot a felhasználónak biztosított lehetőségek keretein belül. .

Üzemeltetési feltételek. Meg kell adni azokat az üzemeltetési feltételeket (környezeti levegő hőmérséklete, relatív páratartalma stb. a kiválasztott adathordozó típusoknál), amelyek mellett biztosítani kell a megadott jellemzőket, valamint a szolgáltatás típusát, a szükséges létszámot és szakképzettséget.

Ezen a ponton általában nem merülnek fel nehézségek. Sajnos a felhasználó professzionalizmusára vonatkozó szempontot a Megrendelő szükségszerűen sugallja. Ez természetesen egy újabb ok arra, hogy hibát találjon a programjában. Itt azonban korlátozhatja magát az olyan kifejezésekre, mint "A program működési feltételei egybeesnek az IBM PC és a kompatibilis PC-k működési feltételeivel", "A programot nem professzionális felhasználók számára kell tervezni." stb.

A műszaki eszközök összetételére és paramétereire vonatkozó követelmények. Tüntesse fel a műszaki eszközök szükséges összetételét műszaki jellemzőik feltüntetésével.

Itt a lényeg az, hogy egyrészt ne felejts el semmit, és mindent előre láss (különben lecsúsznak néhány IBM PC / XT monokróm kijelzővel és egér nélkül), másrészt ne vigyük túlzásba a megnövelt követelményeknek, ellenkező esetben a Megrendelő alkalmazkodóbb Vállalkozót talál.

Például: IBM PC-kompatibilis számítógépre van szüksége EGA (VGA) grafikus adapterrel. A szükséges lemezterület legalább 600 Kb, a szabad RAM mennyisége legalább 400 Kb. Kívánatos egy EMS illesztőprogram és egy egér.

Információ- és szoftverkompatibilitási követelmények. A funkciók ugyanazok, mint az előző bekezdésben. Itt fel kell tüntetni a bemeneti és kimeneti információs struktúrákra, valamint a megoldási módszerekre, a forráskódokra, a programozási nyelvekre vonatkozó követelményeket. Ahol szükséges, az információkat és programokat védeni kell.

Például: A programnak önállóan kell működnie az MS DOS 3.3 vagy újabb verziója alatt. Az alap programozási nyelv a Turbo Pascal 6.0.

A címkézésre és csomagolásra, valamint a szállításra és tárolásra vonatkozó követelmények meglehetősen egzotikusak. Általános esetben a szoftvertermékek címkézésére vonatkozó követelmények, a csomagolás lehetőségei és módjai itt vannak feltüntetve. A szállítási és tárolási követelményekben pedig fel kell tüntetni a szoftvertermék szállítási feltételeit, tárolási helyeit, tárolási feltételeit, raktározási feltételeit, tárolási időtartamát különböző körülmények között.

A különleges követelmények nagyon felelősségteljes dolog. A legjobb, ha lehetőleg kerüljük őket. És azonnal jelentse be.

Például: Nincsenek speciális követelmények a program időbeli jellemzőire vonatkozóan. A program kapacitív jellemzőire nincsenek különleges követelmények.

Műszaki és gazdasági mutatók. Ez a programozó számára legnehezebb elem nem mindig létezik. Elsősorban akkor van rá szükség, ha célja az elvégzett munka óriási hatékonyságának és fontosságának igazolása. Ez az elem általában nagyon jól működik az Ügyfél számára. Legalábbis ez a legjobb indoklás a fejlesztés időzítését és költségeit illetően.

Ebben a rovatban fel kell tüntetni: a becsült gazdasági hatékonyságot, a becsült éves igényt (például: a komplexum egészét érintő hívások becsült száma évente 365 munkamenet), a fejlesztés gazdasági előnyeit a legjobb hazai és külföldi mintákhoz képest, ill. analógok.

Ezen túlmenően kívánatos meghatározni mind a programfejlesztés becsült költségét, mind a programozás összetettségét.

A fejlődés szakaszai és szakaszai(erről az alábbiakban bővebben) megállapítja a szükséges fejlesztési szakaszokat, szakaszokat és a munka tartalmát (a kidolgozandó, egyeztetendő és jóváhagyandó programdokumentumok listája), valamint főszabály szerint a fejlesztés ütemtervét, és meghatározza a végrehajtókat.

A szabványos lépéseket itt ismertetjük. A legfontosabb az időzítés helyes meghatározása. Ha lehetséges, próbálja meg egyenletesen elosztani a szakaszokat idő (és mennyiség) szerint. Ne feledje, hogy nem minden projekt jut el az utolsó szakaszig. És minden szakaszról jelentést kell készíteni. Ne feledje azt is, hogy a munkaprojekt a legtöbb időt veszi igénybe. Ha nincs ideje a dokumentációt határidőre elkészíteni, úgy a Megrendelőnek teljes joga van ahhoz, hogy a munkát az ebből eredő összes következménnyel együtt egyáltalán ne vegye át.

A fő és nélkülözhetetlen szakaszok és szakaszok maga a feladatmeghatározás, a vázlatterv, a műszaki és munkatervek.

Előzetes tervezés. Ebben a szakaszban részletesen kidolgozzák a bemeneti és kimeneti adatok struktúráit, meghatározzák bemutatásuk formáját. Az algoritmus általános leírása, maga az algoritmus és a program felépítése folyamatban van. A program kidolgozására és végrehajtására vonatkozó cselekvési terv kidolgozása folyamatban van.
Műszaki projekt. Tartalmazza a probléma megoldására kidolgozott algoritmust, valamint a kiindulási információk vezérlésére szolgáló módszereket. Hibakezelő eszközöket és diagnosztikai üzenetek kiadását is fejleszti, meghatározza a kiindulási adatok megjelenítési formáit és a technikai eszközök konfigurációját.
Működő projekt. Ebben a szakaszban a program programozása és hibakeresése, programdokumentumok, programok és tesztelési módszerek fejlesztése történik. Tesztelési és hibakeresési példák készülnek. A dokumentáció és a grafikai anyagok véglegesítése megtörtént. Általában előírják, hogy a program fejlesztése során a következő dokumentációt kell elkészíteni:

programszöveg;
programleírás;
program és vizsgálati módszertan;
az alkalmazás leírása;
kézikönyv.

Ezek szabványos követelmények. Ha a Vevő beleegyezik abba, hogy a lista nem mindegyike küldhető be, akkor ez azt jelenti, hogy szándékai Önnel és termékével kapcsolatban nem komolyak.

A grafika elérhető vagy nem. Főleg, ha nem fogsz beszámolni a munkád eredményéről. De komoly projektekhez ez az elem szükséges.

Például: A program fejlesztése során a következő grafikai anyagot kell elkészíteni:

műszaki és gazdasági mutatók;
programstruktúra;
formátum a program bemeneti adatainak megjelenítésére;
az algoritmus általános sémája (2 lap);
alapvető számítási algoritmusok;
példa a programra.

fejezetben Ellenőrzési és átvételi eljárás fel kell tüntetni a vizsgálatok típusait és a munka átvételének általános követelményeit. Lehetőség szerint ebben a bekezdésben jelezze, hogy "a fejlesztés ellenőrzése és átvétele a Megrendelő által biztosított berendezéseken történik", ellenkező esetben a berendezést magával kell hoznia.

Például: A fejlesztés ellenőrzése és elfogadása ellenőrzési és hibakeresési példák tesztjei alapján történik. Ez ellenőrzi az összes programfunkció végrehajtását.

NÁL NÉL Alkalmazások a feladatmeghatározáshoz, ha szükséges, vezesse:

a fejlesztést alátámasztó kutatási és egyéb munkák jegyzéke;
algoritmussémák, táblázatok, leírások, indoklások, számítások és egyéb, a fejlesztés során felhasználható dokumentumok;

egyéb fejlesztési források.

Ez a szabvány meghatározza a programok, a programdokumentáció fejlesztésének szakaszait, valamint a munka szakaszait és tartalmát:

Fejlesztési szakaszok	A munka szakaszai
Műszaki feladat	A program kidolgozásának szükségességének indoklása	A probléma megfogalmazása. Forrásanyagok gyűjtése. A kidolgozott program eredményességének és minőségének kritériumainak kiválasztása és indoklása. A kutatómunka szükségességének indoklása.
	Kutatómunka	A bemeneti és kimeneti adatok szerkezetének meghatározása. A problémamegoldó módszerek előzetes kiválasztása. A korábban fejlesztett programok felhasználásának célszerűségének indoklása. A műszaki eszközökre vonatkozó követelmények meghatározása. A problémamegoldás alapvető lehetőségének indoklása.
	Feladatkör kidolgozása és jóváhagyása	A program követelményeinek meghatározása. Megvalósíthatósági tanulmány készítése a program kidolgozásához. A program és az arra vonatkozó dokumentáció szakaszainak, szakaszainak és fejlesztési feltételeinek meghatározása. Programozási nyelvek kiválasztása. A kutatómunka szükségességének meghatározása a következő szakaszokban. A feladatmeghatározás egyeztetése és jóváhagyása.
Előzetes tervezés	Tervezettervezet kidolgozása	A bemeneti és kimeneti adatok szerkezetének előzetes kialakítása. Problémamegoldási módszerek finomítása. A probléma megoldására szolgáló algoritmus általános leírásának kidolgozása. Megvalósíthatósági tanulmány kidolgozása.
Előzetes tervezés	Koncepcióterv jóváhagyása	A tervtervezet egyeztetése és jóváhagyása
Műszaki projekt	Műszaki projekt kidolgozása	A bemeneti és kimeneti adatok szerkezetének finomítása. Algoritmus kidolgozása a probléma megoldására. A bemeneti és kimeneti adatok ábrázolási formájának meghatározása. A nyelv szemantikájának és szintaxisának meghatározása. A programstruktúra kialakítása. A hardverkonfiguráció végleges meghatározása.
Műszaki projekt	A műszaki projekt jóváhagyása	Cselekvési terv kidolgozása a programok kidolgozására és megvalósítására. Magyarázó jegyzet kidolgozása. A műszaki projekt egyeztetése, jóváhagyása.
munkatervezet	Programfejlesztés	Program programozása és hibakeresése
	Programdokumentáció kidolgozása	Programdokumentumok kidolgozása a GOST 19.101-77 követelményeinek megfelelően.
	Program próbák	A program és a vizsgálati módszerek kidolgozása, koordinálása és jóváhagyása. Előzetes állapot-, osztályközi, átvételi és egyéb vizsgálatok elvégzése. A program és a programdokumentáció javítása a teszteredmények alapján.
Végrehajtás	A program elkészítése, továbbítása	A program és a programdokumentáció elkészítése, átadása karbantartáshoz és (vagy) gyártáshoz. A program karbantartási és (vagy) gyártási célú átadásáról szóló törvény nyilvántartásba vétele és jóváhagyása. A program átvitele az algoritmusok és programok alapjába.

Megjegyzések:

A fejlesztés második szakasza, valamint műszakilag indokolt esetekben a második és harmadik szakasz kizárása megengedett. Ezen szakaszok szükségességét a feladatmeghatározás jelzi.
A munkaszakaszokat és (vagy) azok tartalmát kombinálni, kizárni, valamint a megrendelővel egyeztetett egyéb munkaszakaszokat bevezetni megengedett.

Ez a szabvány az eredményül kapott fejlesztési termék dokumentálására összpontosít.

Szigorúan véve két különböző dokumentum van, amelyekben azonban sok a közös. Ezek az ÁLTALÁNOS LEÍRÁS (GOST 19.502-78) és a PROGRAM LEÍRÁSA (GOST 19.402-78). Tekintettel azonban arra, hogy nagyon nehéz minőségileg létrehozni mind az egyiket, mind a másikat, anélkül, hogy a szinte teljes sokszorosításhoz, darabok kiszakításhoz folyamodnánk, elég lenne egy általánosabb, "hibrid" dokumentumot megvalósítani. Nevezzük "Programleírásnak".

Valójában a "Programleírás" tartalmában kiegészíthető az egyéb leíró dokumentumok és kézikönyvek szabványaiból vett szakaszokkal és bekezdésekkel: GOST 19.404-79 ESPD. Magyarázó megjegyzés, GOST 19.503-79 ESPD. Rendszerprogramozói kézikönyv, GOST 19.504-79 ESPD. Programozói kézikönyv, GOST 19.505-79 ESPD. Kezelési útmutató stb. A magyarázó megjegyzésből különösen kivehető az algoritmus sémája, az algoritmus és (vagy) a program működésének általános leírása, valamint az elfogadott műszaki és műszaki-gazdasági megoldások indoklása.

A program leírásának szükségszerűen tartalmaznia kell egy tájékoztató részt - megjegyzést és tartalmat.

A dokumentum fő részének egy bevezető részből és a következő részekből kell állnia:

funkcionális cél;
a logika leírása.
Felhasználási feltételek;
összetétele és funkciói.

A program jellemzőitől függően további szakaszok bevezetése megengedett.

NÁL NÉL Bevezető rész a dokumentum általános információkat ad a programról - teljes név, megnevezés, lehetséges alkalmazásai stb.

Például: Az "Az ACS fejlesztő automatizált munkahelye" program célja, hogy ... valósítsa meg .... A program támogatja...

fejezetben Célja meg kell jelölni a program célját és általános leírást adni a program működéséről, főbb jellemzőiről, tájékoztatást adni a program hatókörére vonatkozó korlátozásokról, valamint feltüntetni a munkában használt elektronikus számítógépek és eszközök típusait is. .

Például: A program célja, hogy megoldja a problémákat ... A program egy automatizált munkahely magja ...

A felhasználónak lehetősége van ..., megvalósítani ..., futtatni ..., elemezni ..., megszerezni az elemzés és feldolgozás eredményeit ..., felépíteni ... stb.

fejezetben " A logika leírása" jelezze:

a program felépítésének és főbb részeinek leírása

(például: A program a következőket tartalmazza:

felhasználói felület,
modul az útvonalak meghatározásához egy gráfban,
átviteli függvény számítási modul,
amplitúdó- és fázisfrekvencia-karakterisztikát készítő modul,
modul egy polinomiális műveletre adott válasz létrehozásához,
szöveg szerkesztő) .

az alkotórészek funkcióinak és a köztük lévő kapcsolatok leírása;

Például: A program hat modulból áll: interfész modul; definíciós modul ...; számítási modul ...; modul …stb.

Az interfész modul kétféle párbeszédablakra épül: egy „kérdés-válasz” párbeszédablakra és egy „menü” típusú párbeszédablakra. Az interfész modul kezeli...

Definíciós modul... Ez...

Számoló modul...stb.

információ a programozási nyelvről;

Például: A program a ... nyelven íródott a fordító segítségével ...

az egyes összetevők bemeneti és kimeneti adatainak leírása;

Például: INPUT DATA. A program bemeneti adata egy szöveges fájl, amely leírja a vizsgált rendszer grafikonjának kiterjesztett előfordulási mátrixát.

KIMENET. A kimenet a következő:

a képernyőn megjelenő grafikus és szöveges információk (rendszerelemzés eredményei);
fájlok az egyik grafikus formátumban - a megépített jellemzők képének másolatai (frekvencia-válasz, fázisválasz stb.);
szöveges fájlok - kutatási jelentések;
a rendszer állapotának diagnosztizálása és az esetleges hibák jelentése.

az alkotórészek logikájának leírása (szükség esetén a programsémák leírását kell elkészíteni).

A programlogika leírásánál szükséges a programszöveghez való hivatkozás.

fejezetben Összetétel és funkciók mutassa be a programok összetételének és funkcióinak leírását, a problémamegoldásban alkalmazott módszereket.

fejezetben Pályázati feltételek feltüntetik a program megvalósításához szükséges feltételeket (az e programhoz szükséges technikai eszközök követelményei, és egyéb programok, a bemeneti és kimeneti információk általános jellemzői, valamint a szervezeti, technikai és technológiai jellegű követelmények és feltételek stb. .).

Például: A program személyi számítógépen (PC) működik, például IBM PC/AT. Az interaktív módban való munkához a kijelzőt, a billentyűzetet és az egeret kell használni. A grafikus mód támogatásához EGA (VGA) adapter szükséges. A bemeneti adatok floppyon és/vagy merevlemezen tárolódnak. A program operációs rendszeren fut...

A referenciaanyagok (illusztrációk, táblázatok, grafikonok, példák stb.) a leírás mellékletében szerepelhetnek.

És ne felejtse el megadni a rendszerindító modul nevét, valamint a teljes eljárás leírását.

Hívás és indító rendszer

A program szövegének kialakítására vonatkozó követelmények meglehetősen egyszerűek és természetesek egy hozzáértő programozó számára. A dokumentum elkészítésekor a fő szempont az, hogy a program szövege olvasható legyen.

Továbbra is kötelező egy tájékoztató rész - annotációk és tartalom - elkészítése.

A dokumentum fő része egy vagy több szakasz szövegeiből álljon, amelyek címet kapnak.

Minden programfájl szövege "fejléccel" kezdődik, amely a következőket jelzi:

program neve,
szerző,
a program létrehozásának dátuma,
verziószám
utolsó módosítás dátuma.

Hozzászólás kötelező, valamint a behúzás szabályainak szigorú betartása. Ne feledje, még a programdokumentáció megírásának képtelensége is igazolható. És a program csúnya szövege – soha. Nem veszik komolyan az arra való hivatkozásokat, hogy ez a szöveg a szerző számára is világos. A műsorszövegeket nem kell szégyellnie, ha mások elolvassák.

Az alábbiakban egy példa látható egy ilyen jól olvasható programszövegre (Nikolaj Gecht webhelyéről, e-mail: [e-mail védett], http://users.omskreg.ru/~geht)

/* Windows források"98

A Windows 98 forráskódja */ #include "win31.h" #include "win95.h" #include "még több.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" # define INSTALL = HARD char make_prog_look_big; void main() ( while(!CRASHED) ( display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) ( make_50_megabyte_swapfile(); do_nothing_loop(); disable_RealPlayer(); disable_Corel_Products(); hang_system(); ) írjon_valamit(bármit); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(még mindig_nem_összeomlott) ( display_copyright_message();_do_nothing_nothing_1);(loos_nothing_nothing_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éha) ); ) /* printf("Üdvözöljük a Windows 3.11-ben"); */ /* printf("Üdvözli a Windows 95"); */ printf("Üdvözli a 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(); alvás(5); act_on_user_input(); alvás(5); ) create_general_protection_fault();

Ez a dokumentum leírást tartalmaz arról, hogy mit kell tenni, és hogyan lehet meggyőződni arról (és meggyőzni az Ügyfelet), hogy a program megfelelően működik. Valójában ez a dokumentum meghatározó az átvételi teszteknél. A jól megtervezett program és vizsgálati módszertan a kulcsa az átvételi igazolás aláírásának, i.e. amelyre annyi időt és erőfeszítést fordítottál.

Formálisan ezt a GOST-t a tervezési dokumentumok kidolgozására és a szoftverrendszer felkészültségének és minőségének felmérésére szolgáló tesztmunka elvégzésére használják. A dokumentum tartalmazza a tesztelés tárgyának és céljának leírását, a program és szoftver dokumentációval szemben támasztott követelményeket, a tesztelés eszközeit és eljárását, valamint a tesztesetek leírását.

Ennek a dokumentumnak az összetevői könnyebben és érthetőbben azonnal leírhatók példák formájában.

Tesztobjektum

Példa: A tesztobjektum egy olyan program, amely a ...

A tesztelés célja

Példa: A program megbízhatóságának ellenőrzése.

Programkövetelmények

Példa: A program működése nem vezethet hibához (a rendszer végzetes meghibásodásához). A párbeszéd megszervezésének védelmet kell nyújtania a hibás adatok bevitelével szemben. A programnak diagnosztikát kell adnia a rendszer állapotáról, és üzeneteket kell küldenie az esetleges hibákról stb.

A szoftverdokumentáció követelményei

Példa: A tesztelésre bemutatott programdokumentáció összetétele:

a program leírása (GOST 19.402-78);
vizsgálati program és módszertan (GOST 19.301-79);
programszöveg (GOST 19.401-78).

A vizsgálat eszközei és eljárása

Példa: A program az MS DOS (3.0 vagy újabb verzió) működési feltételeinek megfelelően működik olyan PC-n, mint az IBM PC/AT, valamint kompatibilis vele. A működéshez EGA (VGA) adapter is szükséges.

Vizsgálati eljárás:

A program elindul...
Kiválasztott…
Sajtolt...
Sorozatosan kiválasztott...

Teszt esetek

Példa: Tesztelésre ... kínálják fel, melyek leírását a fájlok tartalmazzák ... A tesztfájlok tartalmát és a program eredményeit az 1. számú melléklet tartalmazza.

És végül vegyük figyelembe a legújabb ESPD szabványt, amely az ún

Ez a szabvány megállapítja a számítógépekre, komplexekre és rendszerekre vonatkozó programdokumentumok megvalósításának szabályait, függetlenül azok céljától és hatályától, és amelyeket az ESPD szabványok írnak elő.

Általános követelmények. A géppel, géppel és kézírással készült programdokumentumokba egyedi szavakat, képleteket, szimbólumokat (kézzel rajzbetűvel), a latin és a görög ábécé betűit kell bevinni, valamint a diagramokat, rajzokat fekete tintával ill. tinta.

A végrehajtás során feltárt nyomtatási hibák, grafikai pontatlanságok a rosszul kivitelezett szövegrész törlésével (rajz) és a javított szöveg (grafika) ugyanazon a lapon történő felhordásával javíthatók, a dokumentum-végrehajtás módjától függően géppel vagy fekete tintával.

A dokumentumlapok sérülése, foltok és hiányosan törölt szövegek (grafikák) nyomai nem megengedettek.

A programdokumentumok A4-es lapokra készülnek. Kívül:

A3 formátumú lapokon történő tervezés elfogadható;
gépi dokumentum-végrehajtási módszerrel az A4-es és A3-as formátumnak megfelelő lapok méretében eltérések megengedettek, az alkalmazott technikai eszközök képességeitől függően; az adatkiadó eszközök kimeneti jellemzői által biztosított A4 és A3 formátumú lapokon, gépi dokumentumkészítéskor;
egy dokumentum tipográfiai készítésénél lehetőség van tipográfiai formátumú lapok használatára.

A programdokumentum anyagainak elhelyezése a következő sorrendben történik:

cím rész:

jóváhagyási lap (nem számít bele a teljes dokumentumlapok számába);
címlap (a dokumentum első oldala);

információs rész:

annotáció;
tartalomlap;

fő rész:

dokumentum szövege (ábrákkal, táblázatokkal stb.);
kifejezések listája és definícióik;
rövidítések listája;
alkalmazások;
tárgymutató;
referenciadokumentumok listája;

naplózási rész:

regisztrációs lap módosítása.

Dokumentum felépítése. Ha szükséges, megengedett a dokumentum részekre bontása. A részekre osztás a szakasznál nem alacsonyabb szinten történik. Minden részt külön-külön kell kitölteni, míg az első rész tartalmának végén a többi rész nevét kell feltüntetni.

A dokumentumban megengedett a program szövegének részei, amelyek a programszöveg írási nyelvének szabályai szerint készültek.

Az absztrakt külön lapon (oldalakon) kerül elhelyezésre, „ÖSSZEFOGLALÁS” címszóval, számozással és a dokumentum tartalmával együtt.

Az egyes dokumentumok szövegét szükség esetén bekezdésekre, a bekezdéseket albekezdésekre osztjuk, függetlenül attól, hogy a dokumentum részekre, szakaszokra és alszakaszokra van-e felosztva vagy sem.

A szakaszok fejléceit nagybetűkkel írjuk, és szimmetrikusan helyezzük el a szöveg jobb és bal széléhez képest. Az alcímeket a bekezdésből kisbetűvel írjuk (kivéve az első nagybetűt). A szavak elválasztása a címsorokban nem megengedett. Ne tegyen pontot a cím végére. Minden szakaszt ajánlatos új lapon kezdeni.

A szakaszokat, alszakaszokat, bekezdéseket és albekezdéseket arab számmal, ponttal kell számozni. A szakaszoknak sorszámmal kell rendelkezniük (1, 2 stb.)

Dokumentum szövege. A dokumentum szövegének rövidnek, világosnak kell lennie, kizárva a félreértelmezés lehetőségét. A fogalmaknak és definícióknak egységesnek kell lenniük, meg kell felelniük a megállapított szabványoknak, ezek hiányában a tudományos és műszaki irodalomban általánosan elfogadottnak, és szerepelniük kell a fogalomjegyzékben.

A dokumentum szövegéhez szükséges magyarázatokat lábjegyzetekkel lehet megtenni. A lábjegyzetet a betűtípus felső szélének szintjén elhelyezett zárójellel ellátott szám jelzi.

Ha a lábjegyzet egyetlen szóra vonatkozik, akkor a lábjegyzet jele közvetlenül e szó mellé kerül, ha viszont az egész mondatra, akkor a mondat végére. A lábjegyzet szövege az oldal végére kerül, és a lap bal szélére húzott 3 cm hosszú vonal választja el a főszövegtől.

Illusztrációk. Az illusztrációk a dokumentum szövegében és (vagy) az alkalmazásokban találhatók. Az illusztrációk, ha egynél több van ebben a dokumentumban, a teljes dokumentumon belül arab számokkal vannak számozva.

A mellékletekben az illusztrációk az egyes mellékleteken belül a dokumentum főszövegére meghatározott sorrendben vannak számozva. Az illusztrációkra való hivatkozások típusonként vannak megadva: "12. ábra" vagy "(12. ábra)". Az illusztrációkon tematikus cím és ábraszöveg szerepelhet, amely elmagyarázza az illusztráció tartalmát.

Képletek. A dokumentumban lévő képletek, ha több van, arab számmal vannak számozva, a szám az oldal jobb oldalán, zárójelben a képlet szintjén kerül elhelyezésre. A teljes bizonylaton vagy annak részein belül a bizonylat részekre bontása esetén a képletek folyamatos számozással rendelkeznek.

A szövegben a képlet sorszámára való hivatkozások zárójelben vannak megadva, például: "a (3) képletben". A dokumentum részekre bontásakor a cikkszám a képlet sorszáma elé kerül, és elválasztva az utolsó ponttól, például: "az (1.4) képletben".

A képletben szereplő szimbólumok jelentését közvetlenül a képlet alatt kell megadni. Minden karakter értéke egy új sorba kerül a képletben megadott sorrendben. Az első dekódoló sornak a „hol” szóval kell kezdődnie, kettőspont nélkül utána.

Linkek. Szabványokra és egyéb dokumentumokra való hivatkozás megengedett a szakpolitikai dokumentumokban. Hivatkozni kell a dokumentum egészére vagy részeire (a dokumentum megnevezésének és megnevezésének, a szakasz vagy melléklet számának és megnevezésének feltüntetésével).

Csak a dokumentum és (vagy) szakaszok megnevezését szabad feltüntetni nevük feltüntetése nélkül. Egyes alfejezetekre, bekezdésekre és más dokumentumok illusztrációira mutató hivatkozások nem megengedettek. A dokumentumon belül bekezdésekre, illusztrációkra és egyes alfejezetekre való hivatkozás megengedett.

Megjegyzések. A szöveghez és a táblázatokhoz fűzött megjegyzések csak hivatkozási és magyarázó adatokat tartalmaznak. Egy jegyzet nincs számozva. A "Megjegyzés" szó után tegyen egy pontot. Több hangjegyet egymás után kell számozni arab számokkal, ponttal. A „Megjegyzés” szót kettőspont követi. A jegyzetek szövege csak egy szóközzel nyomtatható.

Rövidítések. A szavak rövidítése a szövegben és az illusztrációk alatti feliratokban nem megengedett, kivéve:

a GOST 2.316-68-ban megállapított és oroszul általánosan elfogadott rövidítések;
latin ábécé betűivel jelölt rövidítések, amelyek a programok, részeik és működési módjaik megjelölésére szolgálnak, a feladatvezérlő nyelvekben, a programbeállító eszközökben stb.

Alkalmazások. Pályázat formájában illusztrált anyagok, táblázatok vagy segédszöveg is készíthető. A mellékletek e dokumentum folytatásaként a következő oldalakon vagy külön dokumentumként kerülnek kiadásra.

Minden pályázatnak új oldalon kell kezdődnie a „Pályázat” szóval a jobb felső sarokban, és tematikus címsorral kell rendelkeznie. Ha egynél több pályázat van a dokumentumban, akkor az összes kérelmet arab számokkal kell számozni (számjel nélkül), például:

1. függelék, 2. függelék stb.

A kérelem külön iratként történő kibocsátásakor a címlapon az irat neve alatt a „Pályázat” szót kell feltüntetni, több pályázat esetén pedig annak sorszámát is.

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

A programdokumentáció egységes rendszere	GOST 19.003-80 Helyette GOST 19428-74

ALGORITMUSOK ÉS PROGRAMOK SÉMA, FELTÉTELES GRAFIKA

Egységes rendszer a programdokumentációhoz. Grafikus folyamatábra szimbólumok.

A Szovjetunió Állami Szabványügyi Bizottságának 1980. április 24-i, 1867. sz. rendelete értelmében a bevezetés határideje

1981.07.01-től

Ez a szabvány a hagyományos grafikus szimbólumokra (szimbólumokra) vonatkozik az algoritmusok és programok sémáiban, amelyek megjelenítik a számítógépek, komplexek és rendszerek szoftverrendszerei adatfeldolgozási és programozási folyamatának fő műveleteit, függetlenül azok céljától és hatókörétől.

A szabvány nem vonatkozik a szimbólumon belül vagy mellette elhelyezett bejegyzésekre, megjelölésekre, amelyek az általa ellátott funkciók tisztázását szolgálják.

A szabvány létrehozza a szimbólumok listáját, nevét, formáját, méretét és a szimbólumokkal megjelenített funkciókat.

A szabvány a szimbólumok tekintetében megfelel az MS ISO 1028-73 szabványnak

1. AZ ÁLTAL MEGJELENÍTETT SZIMBÓLUMOK ÉS FUNKCIÓK LISTÁJA, MEGNEVEZÉSE, MEGJELÖLÉSE

1.1. Az algoritmusban és az adatfeldolgozó programban a kötelező szimbólumok listájának, megnevezésének, megnevezésének és méretének, valamint az általuk megjelenített funkcióknak meg kell egyeznie a táblázatban szereplőkkel. egy.

Asztal 1.

Név	Megnevezés és méretek mm-ben	Funkció
1. Folyamat		Olyan műveletek vagy műveletcsoportok végrehajtása, amelyek megváltoztatják az adatok értékét, megjelenítési formáját vagy helyét
2. Megoldás		Egy algoritmus vagy program végrehajtási irányának megválasztása bizonyos változó feltételek függvényében
3. Módosítás		Olyan műveletek végrehajtása, amelyek megváltoztatják a parancsokat vagy parancsok csoportját, amelyek megváltoztatják a programot
4. Előre meghatározott folyamat		Korábban létrehozott és külön leírt algoritmusok vagy programok használata
5. Kézi működtetés		Autonóm folyamat, manuálisan vagy nem automatikus módon
6. Segédművelet		A processzor által közvetlenül nem vezérelt eszköz által végrehajtott önálló folyamat
7. Egyesítés		Két vagy több készlet összevonása egyetlen készletbe
8. Jelölje ki		Egy vagy több készlet eltávolítása egyetlen készletből
9. Csoportosítás		Két vagy több készlet egyesítése több más készlet kiválasztásával
10. Rendezés		Készlet rendelése megadott szempontok szerint
11. Kézi bevitel		Kézi adatbevitel on-line eszközökkel billentyűzettel, kapcsolókészlettel, gombokkal
12. Bemenet-kimenet		Adatok feldolgozásra (bevitelre) vagy a feldolgozás eredményének megjelenítésére (output) alkalmas formába konvertálása
13. On-line memória		Bemeneti-kimeneti adatok a processzor által közvetlenül vezérelt tárolóeszköz használata esetén
14. Offline memória		Adatbevitel/kimenet olyan tárolóeszköz használata esetén, amelyet nem közvetlenül a processzor vezérel
15. Irat		Adatok bevitele-kimenete, amelyek hordozója a papír
16. Lyukkártya		Adatok bevitele-kimenete, melynek hordozója egy lyukkártya
17. Egy pakli lyukkártya		Egy sor lyukkártya megjelenítése
18. Fájl		Az adatkezelés valamely tárgyát összességében jellemző közös jellemzők alapján szervezett adatok ábrázolása. A szimbólum az I/O funkciókat ellátó, meghatározott adathordozók szimbólumaival együtt használatos.
19. Perforált szalag		Adatok bevitele-kimenete, melynek hordozója lyukszalag
20. Mágnesszalag		Adatok bevitele-kimenete, melynek hordozója egy mágnesszalag
21. Mágneses dob		Adatok input-output, melynek hordozója egy mágneses dob
22. Mágneses korong		Adatok be- és kimenete, amelyek hordozója egy mágneslemez
23. RAM		Adatok input-output, melynek hordozója egy mágneses mag
24. Kijelző		Adatbevitel-kimenet, ha a folyamathoz közvetlenül kapcsolódó eszköz reprodukálja az adatokat, és lehetővé teszi a számítógép kezelőjének, hogy azok feldolgozása során változtatásokat hajtson végre
25. Kommunikációs csatorna		Adatátvitel kommunikációs csatornákon
26. Áramlási vonal		A karakterek közötti sorrend megadása
27. Párhuzamos cselekvések		Két vagy több egyidejű művelet kezdete vagy vége
28. Csatlakozó		Megszakított áramlási vonalak közötti kapcsolat jelzése, összekötő szimbólumok
29. Start - stop		Az adatfeldolgozás vagy programvégrehajtás kezdete, vége, megszakítása
30. Kommentár		A sematikus elem és a magyarázat kapcsolata

1.2. Az algoritmusban és adatfeldolgozó programban az ajánlott szimbólumok és az általuk megjelenített funkciók listája, megnevezése, megnevezése, méretei meg kell, hogy feleljenek a táblázatban feltüntetetteknek. 2.

2. táblázat

Név	Megnevezés és méretek mm-ben	Funkció
1. Oldalon kívüli csatlakozó		A különböző lapokon elhelyezett algoritmusok és programok diagramjainak szétválasztott részei közötti kapcsolat jelzése
2. Mágneskártya		Adatok be- és kimenete, melynek hordozója egy mágneskártya
3. Kézi dokumentum		Dokumentum kialakítása kézi műveletek eredményeként
4. Archívum		Szervezett adathordozó-készlet tárolása újrafelhasználásra
5. Offline feldolgozás		Forrásadatok átalakítása offline műveletek eredményeként
6. Dekódolás		Adathordozóról történő olvasás, átkódolás és nyomtatás ugyanazon vagy másik adathordozón offline művelet eredményeként
7. Kódolás		Kódolt információ alkalmazása a médiában offline művelet eredményeként
8. Másolás

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

A programdokumentáció egységes rendszere	GOST 19.103-77

PROGRAMOK ÉS PROGRAMDOKUMENTUMOK KIJELÖLÉSE
Egységes rendszer a programdokumentációhoz. Programok és programdokumentumok indexelése.

Bevezetés dátuma 80.01.01-től

1. Ez a szabvány meghatározza a számítógépekhez, komplexekhez és rendszerekhez tartozó programok és szoftverdokumentumok kijelölésének szerkezetét, függetlenül azok céljától és hatókörétől.

2. A programok, dokumentumok megjelölése pontokkal elválasztott karaktercsoportokból (a fejlesztő szervezet országkódja és kódja után), szóközökből (a dokumentum revíziószáma és dokumentumtípus kódja után), kötőjelekből (a regisztrációs szám után, ill. ilyen típusú dokumentumszám).

3. A programok és programdokumentumok elnevezésére szolgáló regisztrációs rendszer kialakítása folyamatban van.

A programok kijelölésének szerkezete és programdokumentuma - specifikációk:

4. Egyéb szakpolitikai dokumentumok kijelölésének szerkezete:

5. Az országfejlesztő kódja és a szervezet (vállalkozás) fejlesztő kódja az előírt módon kerül kiosztásra.

A regisztrációs szám hozzárendelése az Állami Szabvány által a megállapított eljárásnak megfelelően jóváhagyott Össz-uniós Programosztályozója szerint történik.

Az Össz- uniós Programosztályozó jóváhagyása előtt minden szervezet (vállalkozás)-fejlesztő számára engedélyezett a regisztrációs szám hozzárendelése növekvő sorrendben, 00001-től 99999-ig.

A program kiadási száma vagy a dokumentum verziószáma 01-től 99-ig növekvő sorrendben van hozzárendelve.

6. Az irattípus kód hozzárendelése a követelményeknek megfelelően történik GOST 19.101-77.

7. Az ilyen típusú bizonylatszám 01-től 99-ig növekvő sorrendben van hozzárendelve.

8. Ugyanazon dokumentum cikkszáma 1-től 9-ig növekvő sorrendben van hozzárendelve.

Jegyzet. Ha a dokumentum egy részből áll, akkor az alkatrész kötőjelét és sorszámát nem tüntetik fel.

9. A program specifikációjának és működési dokumentumainak kiadási számának meg kell egyeznie ugyanazon program kiadási számával.

Újra kiadás. 1987. november

Fóka

Szintén érdekes:

A betűjel megváltoztatása szabványos Windows-eszközökkel A helyi meghajtó betűjelének megváltoztatása

Kódblokkok IDE – Beállítás és használat

A SolidWorks program célja

Javasoljuk elolvasni:

2022-05-13 03:45:28

Hogyan lehet bekapcsolni a bluetooth-ot egy laptopon

2022-05-13 03:45:28

Hogyan lehet mentőt hívni egy Beeline számról?

2022-05-13 03:45:28

Bootolható GRUB4DOS flash meghajtó létrehozása a grubinst segítségével

A témát folytatva:

ablakok

Programok avatarok létrehozásához

Natalya Komarova , 2009. 05. 28. (2018. 03. 25.) Amikor egy fórumot vagy blogot olvasol, a bejegyzések szerzőire becenévvel és ... a felhasználó képével, az úgynevezett avatárral... emlékszel.