Štandardy pre automatizované systémy a informačné technológie. Akceptačné testy ACS. Čo sú štandardy dokumentácie

Dnes si povieme niečo o domácich normách pre projektovú dokumentáciu. Ako tieto normy fungujú v praxi, prečo sú zlé a čo sú dobré. Pri vypracovaní dokumentácie pre verejných a vážnych súkromných zákazníkov väčšinou nemáme na výber - súlad s normami je zapísaný v požiadavkách na dokumentáciu technických špecifikácií. V praxi som sa stretol s rôznymi príkladmi nepochopenia štruktúry noriem, čo by v dokumentoch malo byť a prečo sú tieto dokumenty potrebné. Výsledkom je, že niekedy z pera technických spisovateľov, analytikov a špecialistov vychádzajú také skvosty, že nie je jasné, v akom stave vedomia boli napísané. Ale v skutočnosti je všetko celkom jednoduché. Hľadanie na Habr nevrátilo odkazy na viac-menej úplný materiál na túto tému, preto navrhujem vyplniť túto nepríjemnú medzeru.

Čo sú štandardy dokumentácie?

V predmetnej sérii 34 existujú iba 3 hlavné dokumentačné normy:

Najobľúbenejší a najobľúbenejší štandard pre vývoj technických špecifikácií. Jediné, na čo by ste nemali zabúdať, je, že je úzko prepojený s ostatnými normami v rade a ak ste dostali technickú špecifikáciu vyrobenú podľa tejto normy, je veľmi žiaduce dodržiavať ďalšie normy, aj keď neexistujú žiadne priame požiadavky na to. Aspoň čo sa týka spoločná ideológia(o čom nižšie)

Toto je základný dokument, ktorý poskytuje úplný zoznam dokumentácia GOST 34, odporúčania pre kódovanie dokumentov, do akých fáz projektu dokumenty patria (etapy sú opísané v GOST 34.601-90) a tiež ako ich možno navzájom kombinovať.

V skutočnosti je tento štandard veľkou anotovanou tabuľkou. Pre jednoduché použitie ho možno vložiť do Excelu.

Objemný štandard popisujúci obsah projektových dokumentov s rôznym stupňom podrobnosti. Ako index sa používa vyššie uvedený GOST 34.201-89.

Existuje mnoho otázok a výkladov jej ustanovení k norme RD 50-34.698-90, ktoré sú pre svoju nejednoznačnosť často rozdielne chápané zo strany objednávateľa a zhotoviteľa, prípadne aj členov projektového tímu. Ale, žiaľ, nemáme nič konkrétnejšie.

Uvažujme teraz o výhodách a nevýhodách noriem, počnúc tradične mínusmi.

Nevýhody noriem

Hlavná nevýhoda je zrejmá každému - normy sú staré. Obsahujú zastaraný pohľad na architektúru automatizovaného systému. Napríklad:

• dvojvrstvové aplikácie pozostávajúce z klientskeho programu a servera DBMS (žiadne tri alebo viac „vrstvových“ aplikácií, žiadne Weblogic alebo JBoss)
• opísaná štruktúra databázových tabuliek poskytne predstavu o logickom dátovom modeli (skutočnosť, že medzi aplikáciou a databázou môže byť nejaký režim dlhodobého spánku, potom sa to zdalo ako zlý prebytok)
• používateľské rozhranie je jednooknové (môže byť iné? A čo je to „prehliadač“?)
• V systéme nie je veľa výkazov, všetky sú papierové a sú tlačené na ihličkovej tlačiarni
• Vyvinutý program je zameraný na riešenie „problému spracovania informácií“, ktorý má jasný vstup a výstup a je vysoko špecializovaný. Spracovanie informácií je založené na „algoritme“. Niekedy existuje niekoľko „algoritmov“. (Objektovo orientované programovanie vtedy robilo len prvé kroky a vážne sa o ňom neuvažovalo.)
• správca databázy rozumie, aké informácie sú v tabuľkách a aktívne sa podieľa na úprave systémových adresárov (naozaj existuje jeden DBMS server pre 50 rôznych aplikácií?)

V súlade s tým štandard obsahuje artefakty, ako sú tieto:

5.8. Výkres formulára dokumentu (rámček videa)
Dokument musí obsahovať obrázok formulára dokumentu alebo videozáznam v súlade s požiadavkami štátne normy jednotný dokumentačný systém R 50-77 a potrebné vysvetlivky.

Zmyslom dokumentu je, že takzvané „oblasti tlače“ sa používali v sovietskych podnikoch, kde boli vysokorýchlostné ihličkové tlačiarne, ktorých ovládače často písali samotní inžinieri. Preto museli viesť register všetkých dokumentov, ktoré bolo potrebné vytlačiť, aby sa zabezpečilo, že po vytlačení budú dokumenty vyzerať tak, ako majú.

„Rámec videa“ je tiež dokument, ktorý bol zobrazený na textovom displeji. Displeje nie vždy podporovali požadované znaky a požadovaný počet znakov horizontálne a vertikálne (a už vôbec nie grafiku). Preto aj tu bolo potrebné dodatočne zladiť formy všetkých obrazovkových dokumentov.

Teraz nám slová „stroj-gram“, „video rám“, „ADCP“ nič nehovoria. Tiež som ich nenašiel v použití, hoci som v 90. rokoch vyštudoval špecializovaný ústav. Vtedy sa objavil Windows 3.1, VGA displeje, trojpalcové diskety a prvé domáce internetové stránky. Tieto slová sú však v norme a zákazník niekedy svojvoľne požaduje, aby mu poskytol úplný súbor dokumentácie v súlade s GOST 34.201-89. Navyše podobné formulácie v TK blúdia z jedného ministerstva na druhé a už sa stali akousi nevypovedanou šablónou, do ktorej je vháňaná podstatná časť.

Čiže dokument s hlúpym názvom „Výkres podoby dokumentu (videorámček)“ v projekte by mal a nemal byť prázdny.

Čo je dobré v štandarde

Akákoľvek norma je dobrá na to, že umožňuje objednávateľovi a zhotoviteľovi hovoriť rovnakým jazykom a dáva záruku, že aspoň po formálnej stránke nebude mať objednávateľ „formálne“ nároky na prenášané výsledky.

A normy GOST 34 sú tiež dobré, pretože boli zostavené chytrí ľudia, fungujú už roky a majú jasný cieľ – čo najúplnejšie popísať na papieri komplexnú abstraktnú entitu, ktorú reprezentuje ktorýkoľvek ACS.

Keď potrebujete kompetentne zadať úlohu pre západných dodávateľov, ktorí nikdy nepočuli o našich GOST, môžete sa spoľahnúť aj na tieto normy, alebo skôr na ich obsahovú, sémantickú zložku. Pretože opäť platí, že záruka úplnosti informácií stojí za veľa. Bez ohľadu na to, ako sa oddávame vysokej úrovni našej profesionality, môžeme zabudnúť zahrnúť základné veci do našich požiadaviek, zatiaľ čo ten istý GOST 34.602-89 si všetko „pamätá“. Ak nerozumiete, ako by mal vyzerať výsledok práce západných dodávateľov, pozrite si požiadavky na dokumentáciu, na odporúčané časti. Uisťujem vás, že je lepšie na to neprichádzať! S najväčšou pravdepodobnosťou existujú západné analógy našich štandardov, v ktorých môže byť všetko plnšie, modernejšie a lepšie. Bohužiaľ sa v nich nevyznám, keďže sa zatiaľ nevyskytol jediný prípad, že by naše GOST nestačili.

Môžete sa pousmiať nad tým, že tvorcovia noriem nevedeli nič o jave či .NETe, o HD monitoroch a internete, ale neradil by som vám podceňovať rozsah ich práce a jej hodnotu pre našu odbornú verejnosť.

Ako čítať a porozumieť normám dokumentácie série GOST 34

Norma rozdeľuje všetky dokumenty podľa dvoch osí – časovej a vecnej. Ak sa pozriete na tabuľku 2 v GOST 34.201-89, potom je toto rozdelenie jasne viditeľné (stĺpce "Fáza tvorby" a "Časť projektu"

Etapy vytvárania automatizovaného riadiaceho systému

Etapy tvorby sú definované v GOST 34.601-90. Tri z nich sú relevantné pre dokumentáciu:

• Návrh návrhu (EDS)
• Technický dizajn (TP)
• Vypracovanie pracovnej dokumentácie (RD)

Predbežný návrh sleduje štádium zadávacích podmienok a slúži na vypracovanie predbežných konštrukčných riešení.

Technický projekt opisuje budúci systém zo všetkých uhlov pohľadu. Dokumenty etapy TP by mali po prečítaní zanechať úplnú prehľadnosť v navrhovaných prístupoch, metódach, architektonických a technických riešeniach. V ďalšej fáze už bude neskoro popisovať prístupy a zdôvodňovať technické riešenia takže fáza P je kľúčom k úspešné doručenie funguje, pretože všetka rôznorodosť požiadaviek na TK by sa mala odraziť v dokumentoch fázy P. Vo fáze P systém nemusí vôbec existovať.

Pracovná dokumentácia je určený pre úspešné nasadenie, uvedenie do prevádzky a ďalšiu prevádzku nového systému. Ide o dokumenty obsahujúce veľmi špecifické informácie popisujúce fyzicky existujúce entity, na rozdiel od fázy P, ktorá popisuje budúcu nádheru.

Časti (sekcie) projektovej dokumentácie na vytvorenie automatizovaného riadiaceho systému

Predmetová oblasť je rozdelená na „Ustanovenia“. Spočiatku sa zdá, že takéto rozdelenie je nadbytočné a zbytočné. Ale keď začnete pracovať s touto súpravou nástrojov v praxi, ideológia v nej vložená postupne dosiahne.

Automatizovaný systém v mysli kompilátorov GOST je kombináciou hardvéru, softvéru a komunikačných kanálov, ktoré spracovávajú informácie pochádzajúce z rôznych zdrojov v súlade s určitými algoritmami a poskytujú výsledky spracovania vo forme dokumentov, dátových štruktúr alebo kontrolných akcií. Primitívny model najjednoduchšieho automatu.

Aby bol tento „automat“ úplne opísaný, boli urobené nasledujúce rezy (ako na výkrese):

softvér (MO), ktorý odpovedá na otázky: aká je logika za „čiernou skrinkou“? Prečo boli zvolené tieto algoritmy, presne také vzorce a presne také koeficienty?

Softvér nevie nič o procesoroch alebo databázach. Toto je samostatná abstraktná oblasť, sídlo „guľových koní vo vzduchoprázdne“. Softvér však môže veľmi úzko súvisieť s predmetnou oblasťou, aka Skutočný život... Napríklad riadiace algoritmy pre riadiace systémy cestnej premávke pred ich odsúhlasením objednávateľom je potrebné dohodnúť sa s dopravnou políciou. A potom pochopíte, prečo sú uvedené v samostatnej knihe. Pretože v dopravnej polícii nikoho nezaujíma, na akom operačnom systéme bude aplikačný server bežať, ale to, aká značka a rýchlostný limit sa objaví na výsledkovej tabuli v daždi alebo snehu, je veľmi zaujímavé. Sú zodpovední za svoju časť a nič iné sa nechystajú podpísať. Na druhej strane, keď podpísali, nebudú otázky k technickej stránke otázky - prečo zvolili práve tie, a nie iné tabule či semafory. V takýchto praktických prípadoch sa presne prejavuje múdrosť „predkov“.

Informačná podpora (IO)... Ďalší kúsok systému. Tentoraz je čierna skrinka nášho systému priehľadná a my sa pozeráme na informácie, ktoré v nej kolujú. Predstavte si model ľudského obehového systému, keď sú všetky ostatné orgány neviditeľné. Toto je niečo podobné a existuje informačná podpora. Popisuje zloženie a cesty prechodu informácií dovnútra a von, logickú organizáciu informácií v systéme, popis referenčných kníh a kódovacích systémov (kto robil programy na výrobu, vie, aké sú dôležité). Hlavná popisná časť spadá do štádia TP, ale niektoré „základy“ prechádzajú do štádia RD, ako napríklad dokument „Katalóg databáz“. Je jasné, že predtým obsahoval presne to, čo je napísané v názve. Skúste však dnes vytvoriť takýto dokument pre zložitý komplexný systém, keď sa ako súčasť systému často používajú kupované podsystémy s ich tajomnými informačnými skladmi. O tom, že tento dokument teraz nie je zvlášť potrebný, ani nehovorím.

Alebo tu je "Vyhlásenie o strojových informačných médiách". Je jasné, že kedysi obsahovala počty magnetických bubnov alebo kotúčov filmu. A teraz čo tam priniesť?

Stručne povedané, vo fáze RD sú dokumenty informačnej podpory dosť zhubným základom, pretože formálne by mali byť, ale nie je potrebné ich naplniť.

softvér (softvér)... Všetkých obľúbená časť projektovej dokumentácie. Áno, už len preto, že toto je len jeden dokument! A potom každý pochopí, čo tam treba zaznamenať. Ale aj tak sa budem opakovať.

V tomto dokumente musíme povedať, akým softvérom sa vykonávajú algoritmy opísané v IO, ktoré spracúvajú informácie opísané v IO. To znamená, že tu nie je potrebné duplikovať informácie z iných sekcií. Uvádza architektúru systému, zdôvodnenie zvolených softvérových technológií, ich popis (všetky druhy systémových vecí: programovacie jazyky, frameworky, operačné systémy atď.). V tomto dokumente tiež popisujeme, ako sú usporiadané nástroje na spracovanie informácií (fronty správ, úložiská, nástroje na zálohovanie, riešenia dostupnosti, všetky druhy aplikačných oblastí atď.). Norma má Detailný popis obsah tohto dokumentu, ktorému rozumie každý odborník.

Technická podpora (TO)... Všetkými nemenej milovaná súčasť projektovej dokumentácie. Svetlý obraz stmavne iba množstvo dokumentov, ktoré je potrebné vypracovať. Celkovo je podľa normy potrebné vypracovať 22 dokumentov, z toho 9 v štádiu TP.

Faktom je, že norma poskytuje popis všetkej technickej podpory vrátane počítačového hardvéru a sietí, inžinierskych systémov a dokonca aj stavebnej časti (ak je to potrebné). A táto ekonomika je regulovaná obrovským množstvom noriem a predpisov, je koordinovaná v rôznych organizáciách a preto je pohodlnejšie všetko rozdeliť na časti a skoordinovať (upraviť) po častiach. Norma zároveň umožňuje niektoré dokumenty navzájom kombinovať, čo má zmysel robiť, ak celú haldu odsúhlasí jedna osoba.

Nezabudnite tiež, že súbor štandardov kvality zahŕňa účtovanie a uchovávanie technických dokumentov a naše „knihy“ u zákazníka môžu byť rozptýlené v rôznych archívoch v závislosti od predmetu popisu. Toto je ďalší argument v prospech fragmentácie dokumentácie.

Organizačná podpora (OO)... Po potlačení túžby, normálnej pre technikov, túto časť čo najskôr preskočiť, naopak, zvážim to podrobnejšie. Odkedy, kolegovia, v posledných rokoch boli načrtnuté zlé trendy na projektoch, ktoré si vyžadujú objasnenie práve v tejto časti.

V štádiu TP sekcia obsahuje iba jeden dokument “ Popis organizačnej štruktúry“, V ktorej musíme zákazníkovi povedať, na čo sa má pripraviť z hľadiska zmeny organizačnej štruktúry. Zrazu potrebujete zorganizovať nové oddelenie na prevádzku vášho systému, zaviesť nové pozície atď.

Vo fáze RD sa objavujú ďalšie, zaujímavejšie dokumenty, ktoré by som rád zvážil samostatne.

Užívateľská príručka... Komentáre sú podľa mňa zbytočné.

Metodika (technológia) počítačom podporovaného projektovania... V tomto dokumente môžete v prípade potreby vložiť popis procesu vytvárania softvéru, kontroly verzií, testovania atď. Ale to je vtedy, ak si zákazník v TK želá softvér osobne zostaviť. Ak to nevyžaduje (a neplatí za to), potom celá vaša vnútorná kuchyňa nie je jeho vecou a tento dokument nie je potrebné vybavovať.

Technologický návod... Kvôli móde formalizácie obchodných procesov sa niekedy prefíkaný zákazník snaží vtesnať prevádzkové postupy do tohto dokumentu. Takže to v žiadnom prípade nie je potrebné.

Popis obchodných procesov, roly a popisy práce, pracovný poriadok - to všetko je ORD, teda organizačná a administratívna dokumentácia. Čo je produktom poradenského projektu, ktorý, pokiaľ som dobre pochopil, u vás nekúpil. A kúpili od vás technický projekt a k nemu aj technickú dokumentáciu.

Technologický pokyn je vrstva medzi OSD a užívateľským manuálom. RP podrobne popisuje ako musíte vykonať určité akcie v systéme. Technologický pokyn hovorí aký druhčinnosti sa musia vykonať v určitých prípadoch súvisiacich s prevádzkou systému. Zhruba povedané, technologická inštrukcia je krátky prehľad RP pre konkrétnu pozíciu alebo rolu. Ak zákazník nemá zadefinované roly, alebo chce, aby ste si roly a pracovné požiadavky definovali sami, zahrňte do dokumentu najzákladnejšie roly, napríklad: operátor, senior operátor, administrátor. Komentáre zákazníka k téme „ale nepáči sa nám to“ alebo „ale nepáči sa nám to“ by mali byť doplnené zoznamom rolí a popisom pracovné povinnosti... Pretože obchodné procesy my nedávajte... My sme tieto obchodné procesy automatizovať.

O popísanom hrable napíšem samostatne s pestrými príkladmi, keďže to nie je prvýkrát, čo sa v rôznych odvetviach „národného hospodárstva“ opakujú.

Popis technologického procesu spracovania dát (vrátane teleprocessingu)... Poľutovaniahodná pozostatka jaskynného veku, keď tam boli špeciálne určení "počítači" kŕmili stroj diernymi štítkami a výtlačok výsledku balili do obálky. Tento návod je pre nich. Čo do nej napísať v XXI storočí - to vám neviem s istotou povedať. Odskrutkujte sa. Najlepšie je na tento dokument zabudnúť.

Systémové riešenia (OR)... Norma zabezpečuje 17 dokumentov sekcie OP. Po prvé, toto sú takmer všetky dokumenty z fázy predbežného návrhu návrhu. Po druhé, sú to všetky druhy odhadov, výpočtov a Stručný opis automatizované funkcie. Teda informácie pre ľudí nie z hlavnej IT výroby, ale pre pomocný personál – manažérov, odhady nákladov, špecialistov na obstarávanie, ekonómov atď.

A do tretice, súčasťou OR je megadokument s názvom „Vysvetlivka k technickému projektu“, ktorý je podľa myšlienky akýmsi Executive Summary, no v skutočnosti doň mnohí dizajnéri pchajú všetok užitočný obsah etapy TP. . Takýto radikálny prístup je niekedy opodstatnený a dokonca obojstranne výhodný pre objednávateľa aj zhotoviteľa, no v určitých prípadoch.

Varianty použitia GOST 34

1. Úplné a presné dodržiavanie normy... Prirodzene, nikto dobrovoľne nenapíše taký oblak dokumentov. Preto sa len na naliehavú požiadavku objednávateľa pripravuje kompletný súbor podkladov, ktorý si zabezpečil v TK a dohodou zhora rozdrvil. V tomto prípade musíte všetko doslovne pochopiť a dať zákazníkovi fyzické „knihy“, na ktorých sa objavia názvy dokumentov z tabuľky 2 GOST 34.201-89, s výnimkou úplne nepotrebných, ktorých zoznam musíte určite písomne ​​prediskutovať a opraviť. Obsah dokumentov musí tiež bez akejkoľvek predstavivosti zodpovedať PD 50-34.698-90, až po názvy sekcií. Aby zákazníkovi vybuchol mozog, niekedy sa veľký systém rozdelí na podsystémy a na každý podsystém sa vydá samostatná projektová dokumentácia. Vyzerá desivo a nepodlieha bežnej kontrole pomocou pozemskej mysle. Najmä z hľadiska integrácie subsystémov. To výrazne zjednodušuje prijatie. Hlavné je, aby ste sa vy sami nezmýlili a aby váš systém stále fungoval tak, ako má.
2. Jednoducho milujeme GOST... Vážne veľké spoločnosti normy lásky. Pretože pomáhajú ľuďom lepšie si porozumieť. Ak si váš zákazník všimne, že miluje poriadok a štandardizáciu, snažte sa pri tvorbe dokumentov dodržiavať štandardnú ideológiu GOST, aj keď to technická špecifikácia nevyžaduje. Budete lepšie pochopený a schválený koordinujúcimi špecialistami a vy sami nezabudnete zahrnúť do dokumentácie dôležitá informácia, lepšie uvidíte cieľovú štruktúru dokumentov, presnejšie si naplánujete prácu na ich písaní a ušetríte sebe aj svojim kolegom kopu nervov a peňazí.
3. Nestaráme sa o dokumentáciu, pokiaľ všetko funguje.... Miznúci druh nezodpovedného zákazníka. Podobný pohľad na dokumentáciu ešte stále nájdeme medzi malými a chudobnými zákazníkmi, ako aj v autoritárskych „idiotokraciách“, ktoré zostali po perestrojke, kde je šéf obklopený vernými priateľmi – režisérmi a všetky problémy sa riešia v osobných rozhovoroch. V takýchto podmienkach môžete zabudnúť na dokumentáciu vo všeobecnosti, ale je lepšie nezraziť zrak a aspoň schematicky naplniť dokumentáciu obsahom. Ak nie tomuto zákazníkovi, tak previesť (predať) ďalšiemu.

Záver

Tento článok sa týkal našich noriem GOST pre dokumentáciu ACS. GOST sú staré, ale ako sa ukázalo, stále sú v domácnosti veľmi užitočné. Štruktúra dokumentácie má odhliadnuc od niektorých samozrejmých základov vlastnosti úplnosti a konzistentnosti a dodržanie štandardu odstraňuje mnohé projektové riziká, ktorých existenciu na prvý pohľad ani netušíme.

Dúfam, že prezentovaný materiál bol pre vás užitočný alebo aspoň zaujímavý. Napriek vonkajšej nude je dokumentácia dôležitá a zodpovedná práca, kde je presnosť rovnako dôležitá ako písanie dobrého kódu. Napíšte dobré dokumenty, kolegovia! A idem budúci týždeň Idem na dve služobné cesty za sebou, takže vydanie nových materiálov nemôžem zaručiť (predajňu nemám, píšem z hlavy).

M. Ostrogorskij, 2008

Aby bolo možné úspešne aplikovať GOST 34, je potrebné pochopiť, ako je z hľadiska tohto súboru noriem usporiadaný automatizovaný systém. Inak v hosťoch okrem dlhého zoznamu dokumentov s tajomnými menami nič neuvidíme a požiadavky na ich obsah nás opäť presvedčia, že v mnohých múdrostiach je veľa smútku. Preto pred diskusiou o samotných dokumentoch musíme pochopiť, čo tvorí predmet dokumentácie.

Automatizovaný systém, jeho funkcie a úlohy

Definícia automatizovaného systému

GOST 34.003-90 obsahuje nasledujúcu definíciu automatizovaného systému: systém pozostávajúci z personálu a súboru prostriedkov na automatizáciu ich činností, ktorý implementuje informačné technológie na vykonávanie zavedených funkcií. Čo znamená táto definícia v praxi? Pochopíte to len tak, že si prečítate ostatné definície tohto štandardu a porovnáte ich medzi sebou. Čo budeme teraz robiť.

Ciele činnosti

Automatizovaný systém môže existovať len tam, kde sú pracovníci zapojení do konkrétnej činnosti. Spravidla hovoríme o činnostiach, ktorých výsledky sú niekomu užitočné, bez ohľadu na použité nástroje. Napríklad žiadam v pokladni o lístok a padlo by mi dobre, keby mi ho pokladníčka vypísala perom na hlavičkovom papieri, aby ma s ním pustili do sály. Pokladník sa vo všeobecnosti tiež nestará o to, ako urobiť lístok. Akákoľvek metóda by jej vyhovovala, pokiaľ by nebola príliš prácna a poskytovala by jej možnosť predať mi lístok. Inými slovami, máme s ňou spoločný cieľ. V GOST 34.003-90 sa tento termín používa na jeho označenie účel činnosti... Vždy, keď od okna odíde iný divák s lístkom v ruke a divadlo o niečo zbohatne, je tento cieľ aktivity splnený.

Funkcie automatizovaného systému

Cieľov činnosti môže byť (a spravidla existuje) niekoľko. Za jeho cieľ možno považovať akýkoľvek výsledok, ktorý je užitočný mimo samotnej aktivity. Ak teda pokladník nielen predáva lístok, ale aj na konci pracovného dňa vypracuje správu o predaji pre šéfov, vypracovanie dennej správy možno považovať za ďalší cieľ činnosti.

Ak pokladníčke položíme na stôl počítač a tlačiareň a vedúci pokladníka jej vydá príkaz, aby v textovom editore napísala lístky a zostavy a vytlačila ich na tlačiarni, dostaneme automatizovaný systém. Podľa moderných predstáv je veľmi primitívny, formálne bude vyhovovať gostskej definícii. Upozorňujeme, že ciele aktivity sa v dôsledku implementácie automatizovaného systému nezmenili, zmenil sa len spôsob ich dosiahnutia. To, čo sa kedysi robilo „len tak“, sa dnes robí v rámci automatizovaného systému. Súbor činností automatizovaného systému zameraných na dosiahnutie konkrétneho cieľa sa podľa GOST 34.003-90 nazýva funkciu... Poznámka: Čokoľvek si o tom myslíte, personál je považovaný za súčasť systému.

Funkcia automatizovaného systému je základným pojmom v GOST 34. Automatizovaný systém sa v prvom rade považuje za súhrn jeho funkcií a až potom za súbor "softvéru" a "hardvéru". Najdôležitejšie je, že to, čo systém robí a z čoho pozostáva, je druhoradé.

Vyššie uvedené by mohlo viesť čitateľa k záveru, že každému cieľu činnosti v automatizovanom systéme zodpovedá iba jedna funkcia. Je ľahké si takýto systém predstaviť, no prax je pestrejšia. Na jednej strane nie sú činnosti vždy plne automatizované. Aj po zavedení automatizovaného systému sa niektoré ciele musia dosahovať manuálne. Na druhej strane, keďže možno dosiahnuť rovnaký výsledok za rôznych podmienok rôzne cesty, viaceré funkcie môžu smerovať k jednému cieľu činnosti v automatizovanom systéme, napríklad predaj lístka v pokladni a predaj lístka na internete. Okrem toho každý automatizovaný systém vyžaduje určitú údržbu, preto je potrebné zaviesť koncept pomocnej funkcie. Typickým príkladom je zálohovanie dát.

Úlohy automatizovaného systému

Vo všeobecnom prípade pri vykonávaní funkcie časť práce vykonáva personál a časť práce vykonáva zariadenie, napríklad lístok sa automaticky vytlačí a pokladníci ho vydajú manuálne. Postupnosť automatických (sic) akcií vedúcich k výsledku daného typu sa nazýva GOST 34.003-90 úloha.

Tu definícia problému nie je citovaná celkom presne, ale zatiaľ nám to bude stačiť a to v konečnom dôsledku nie je hanba, aby si niekto normu prečítal sám. Je dôležité, aby úloha bola najjasnejšie formalizovanou súčasťou automatizovanej činnosti. Možno si predstaviť funkciu vykonávanú úplne automaticky, ako je napríklad spomínaná záloha. V tomto prípade je funkcia zredukovaná na jednu úlohu.

Rovnakú úlohu možno vyriešiť vykonaním rôznych funkcií. Napríklad, ak má automatizovaný systém niekoľko funkcií na predaj lístka, potom vykonanie každej z nich môže v určitom bode vyžadovať vytlačenie lístka.

Zloženie automatizovaného systému

Subsystémy

Ak je automatizovaný systém dostatočne zložitý, delí sa na subsystémy... Čo to znamená, dosť ťažké, dosť ťažké povedať. Teória systémov popisuje rôzne úrovne a kritériá zložitosti. V praxi je potreba oddelenia viacerých subsystémov v automatizovanom systéme často spôsobená organizačnými a finančnými dôvodmi, napríklad subsystémy sa vyvíjajú a uvádzajú do prevádzky postupne.

Hoci v GOST 34 sa pojem subsystém používa mnohokrát, zdá sa, že neexistuje žiadna formálna definícia tohto pojmu. Zo skúseností vyplýva, že podsystém je súčasťou automatizovaného systému, ktorý zároveň spĺňa definíciu automatizovaného systému, má najmä plnohodnotné funkcie.

Ak sa vrátime k príkladu predaja lístkov, môžeme sa rozhodnúť, že automatizovaný systém pozostáva z dvoch podsystémov: podsystému predaja lístkov a podsystému na generovanie denných zostáv. Len pre lepšiu názornosť sa dohodnime, že pokladník zadáva lístky v textovom editore a hlási v tabuľkových procesoroch.

Komponenty

Pridelenie cieľov činnosti, funkcií automatizovaného systému a v prípade potreby jeho podsystémov je do značnej miery subjektívne a závisí od uhla pohľadu subjektu, ktorý sa tak rozhodol. Ak je nejaký výsledok dôležitý v kontexte riešeného problému, môžeme ho považovať za cieľ a inak ho ignorovať. Automatizovaný systém tiež rozdelíme na podsystémy, ako nám to bude vyhovovať, pokiaľ naše rozhodnutia nebudú v rozpore s obsahom tohto konceptu.

Komponenty sú časti, z ktorých budujeme automatizovaný systém v objektívnej realite. Systém sa fyzicky skladá zo svojich komponentov, preto je rozdelenie automatizovaného systému na komponenty najobjektívnejšie.

Každý komponent (ak ide o zariadenie), inštalujeme (ak ide o program) a servisujeme oddelene od ostatných komponentov nakupujeme, montujeme a pripájame. Kúpili sme a položili počítač na stôl - to je komponent. Vyvinuli sme špeciálny textový editor pre sadu tiketov - ďalší komponent. Stiahnuté bezplatné tabuľky z internetu - opäť komponent. A dokonca aj samotná pokladníčka je istým spôsobom súčasťou automatizovaného systému.

Komponentné zloženie automatizovaného systému je veľmi dôležité z hľadiska jeho dokumentácie, keďže s technickou dokumentáciou pre systém ako taký a s komponentmi sa zaobchádza rozdielne. Vo všeobecnosti by sa mala rozvíjať Iný ľudia a je navrhnutý podľa rôznych noriem v závislosti od typu komponentu.

Druhy kolaterálu

Jedným z najťažších konceptov pre začínajúceho používateľa GOST 34 je typ zabezpečenia... Čo je to za bezpečnosť? Môžete to vidieť alebo sa ho dotknúť? Predať alebo kúpiť?

Každý typ podpory kombinuje komponenty alebo technické riešenia špecifického charakteru. GOST 34 spomína veľa odlišné typy ustanovenia, nebudeme tu dôsledne popisovať každý z nich, ale vymenujeme len tie najpozoruhodnejšie:

• informačná podpora - všetky údaje a metadáta, s ktorými systém pracuje;
• softvér - všetky programy, ktoré sú súčasťou systému;
• technická podpora - všetky technické prostriedky (inými slovami vybavenie, prístroje), ktoré sú súčasťou systému.

Ešte raz opakujeme, nie sú to všetky typy kolaterálu. Nemôžeme ani s istotou povedať, že sú najdôležitejšie. Napríklad pre automatizované systémy riadenia procesov (APCS) veľkú hodnotu má metrologickú podporu. Mnohé automatizované systémy vyžadujú komplexnú matematickú a jazykovú podporu. Je však ťažké predstaviť si automatizovaný systém, ktorý by bol úplne zbavený jedného z troch typov podpory uvedených vyššie (cvičenie: vyskúšajte).

Úvod

V modernom svete sa každý deň objavujú desiatky a stovky rôznych programov, aplikácií, informačných systémov. Môžu byť určené pre verejný alebo komerčný sektor, ako aj pre bežných používateľov. 90% všetkých používateľov dokumentáciu nečíta, považuje ju za nudnú, nudnú a nezaujímavú a používateľskú príručku otvára až vtedy, keď niečo nefunguje alebo je absolútne nemožné na to prísť bez návodu. Teraz je všeobecne akceptované zostaviť používateľské rozhranie tak, aby bolo intuitívne a používateľ mohol prísť na systém bez toho, aby musel čítať dlhé návody. Pri práci s veľkými zákazníkmi je však takmer vždy potrebné predložiť určitý balík dokumentov - príručky, pokyny, konštrukčné riešenia vypracované v súlade s GOST.
Keď prvýkrát narazíte na písanie dokumentácie v súlade s GOST, prídete do strnulosti a úplného šoku, pretože tieto GOST sú „morské“ a ako a čo o nich písať sa stáva nejasným.
Tento článok pojednáva o GOST na písanie dokumentácie a ich hlavných bodoch.

Čo sú GOST?

Najprv musíte zistiť, čo sú GOST. Každý vie, že GOST je niečo, čo bolo vyvinuté v rámci Únie a je ich jednoducho nekonečné množstvo. Ponáhľam sa vás uistiť, že pre IT sektor neexistuje toľko noriem GOST a všetky z nich, napriek dobe ich vzniku, nestratili svoj význam.
Po prvé, štandardy pre písanie dokumentácie sú rozdelené do dvoch typov:

1. Medzinárodné normy (ISO, IEEE Std);
2. Ruské alebo sovietske GOST.

Medzinárodné normy
Medzinárodné normy sa používajú na vypracovanie dokumentácie na medzinárodnej úrovni. Spravidla nie sú zadarmo, pretože ich nevyvíjajú vládne organizácie, ale na rozdiel od našich boli vyvinuté pomerne nedávno. Téma medzinárodné normy veľmi široká, preto sa jej budeme venovať v inom článku. Okamžite sa dotkne niekoľkých noriem, ktoré úzko súvisia s písaním dokumentácie.
Zoznam hlavných medzinárodných štandardov pre písanie dokumentácie:

1. IEEE Std 1063-2001 "IEEE Standard for Software User Documentation" - štandard pre písanie užívateľskej príručky;
2. IEEE Std 1016-1998 "IEEE Odporúčaná prax pre popisy návrhov softvéru" - štandard pre písanie technického popisu programu;
3. ISO / IEC FDIS 18019: 2004, "Pokyny pre návrh a prípravu užívateľskej dokumentácie pre aplikačný softvér" je ďalším štandardom pre písanie užívateľských manuálov. Tento dokument má veľký počet príklady. To znamená, že to vyzerá skôr ako príručka na písanie používateľskej príručky. Začiatočníci budú obzvlášť užitoční;
4. ISO / IEC 26514: 2008, Požiadavky na dizajnérov a vývojárov užívateľskej dokumentácie, je ďalšou normou pre dizajnérov a vývojárov užívateľskej dokumentácie.

V skutočnosti existuje veľa medzinárodných noriem a v každej krajine sú iné, keďže rovnaký štandard nemusí byť vždy vhodný pre európske aj ázijské spoločnosti.

Ruské štandardy
Ruské normy sa vyvíjajú na štátnej úrovni. Všetky sú úplne zadarmo a všetky sa dajú ľahko nájsť na internete. Na písanie dokumentácie k programu sa používajú dve série GOST 19 a 34. O nich sa bude ďalej diskutovať.

Aký je rozdiel medzi GOST série 19 a 34?

Prvá otázka, ktorá vzniká, je, ako sa tieto GOST 19 a 34 vo všeobecnosti navzájom líšia.
V GOST 19.781-90 „Jednotný systém programovej dokumentácie. Softvér systémov na spracovanie informácií. Termíny a definície „definície sú uvedené:

1. Program - dáta určené na riadenie špecifických komponentov systému spracovania informácií za účelom implementácie špecifického algoritmu.
2. Softvér - súbor programov systému spracovania informácií a programových dokumentov potrebných na prevádzku týchto programov.

V GOST 34.003-90 „Informačné technológie. Súbor noriem pre automatizované systémy. Automatizované systémy. Termíny a definície „definícia je uvedená:

1. Automatizovaný systém (AS) je systém pozostávajúci z personálu a súboru prostriedkov na automatizáciu ich činností, ktorý implementuje informačné technológie na vykonávanie stanovených funkcií.
   V závislosti od druhu činnosti sa napríklad rozlišujú tieto typy automatizovaných systémov: automatizované riadiace systémy (ACS), počítačové systémy projektovania (CAD), automatizované systémy vedecký výskum(ASNI) a ďalšie.

Podľa typu riadeného objektu (procesu) sa ACS delí napr. na: ACS podľa technologických procesov (ACS), ACS podľa podnikov (ACS) atď.
GOST 34 tiež delí na typy podpory JE:

1. Organizačné;
2. Metodický;
3. technické;
4. matematické;
5. Softvér;
6. Informačné;
7. lingvistické;
8. právne;
9. Ergonomický.

Výsledkom je, že Automatizovaný systém nie je program, ale súbor typov podpory vrátane softvéru. AS spravidla nesie organizačné riešenie pre konkrétneho užívateľa a zákazníka a Program môže byť vytvorený a replikovaný pre veľký počet užívateľov bez toho, aby bol viazaný na akýkoľvek podnik.
Ak teda vyvíjate dokumentáciu k programu, ktorý ste vytvorili pre konkrétnu spoločnosť, potom váš GOST 34. Ak píšete dokumenty pre hromadný program, potom váš GOST 19.

GOST 34

Séria GOST 34 (normy pre informačné technológie GOST 34.xxx) pozostáva z:

1. GOST 34.201-89 Typy, úplnosť a označenia dokumentov pri vytváraní automatizovaných systémov - táto norma stanovuje typy, názov, úplnosť a čísla dokumentov. Je to jeden z hlavných dokumentov série GOST 34. V skutočnosti ide o základný dokument, takže začiatočníci by sa s ním mali najskôr zoznámiť.
2. GOST 34.320-96 Pojmy a terminológia pre koncepčný diagram a informačnú základňu- táto norma stanovuje základné pojmy a termíny pojmových schém a informačných báz, ktoré zahŕňajú vývoj, popis a aplikáciu pojmových schém a informačných báz, manipuláciu s informáciami, ako aj popis a implementáciu informačného procesu. Norma definuje úlohu pojmovej schémy. Ustanovenia v ňom uvedené majú poradný charakter a možno ich použiť na hodnotenie systémov správy databáz (DBMS). Tento dokument nepopisuje špecifické metódy na používanie nástrojov na podporu koncepčných schém. Jazyky koncepčných schém opísané v norme by sa nemali považovať za štandardné.
3. GOST 34.321-96 Informačné technológie. Databázový štandardný systém. Referenčný model riadenia – Tento dokument stanovuje referenčný model riadenia údajov.
   Referenčný model definuje všeobecnú terminológiu a pojmy súvisiace s údajmi informačných systémov. Takéto pojmy sa používajú na definovanie služieb poskytovaných systémami správy databáz alebo systémami údajových slovníkov.
   Referenčný model nezohľadňuje protokoly na správu údajov.
   Rozsah referenčného modelu zahŕňa procesy, ktoré sa týkajú správy perzistentných údajov a ich interakcie s procesmi, ktoré sa líšia od požiadaviek konkrétneho informačný systém ako aj všeobecné služby správy údajov na definovanie, ukladanie, vyhľadávanie, aktualizáciu, zadávanie, kopírovanie, obnovu a prenos údajov.
4. GOST 34.601-90 Automatizované systémy. Etapy vzniku - norma stanovuje etapy a etapy vzniku AU.
5. GOST 34.602-89 Referenčné podmienky pre vytvorenie automatizovaného systému (Namiesto GOST 24.201-85) - stanovuje zloženie, obsah, pravidlá pre vypracovanie dokumentu „Zadávacie podmienky pre vytvorenie (vývoj alebo modernizáciu) systému ."
   Tento dokument je jedným z najčastejšie používaných dokumentov série GOST 34. Pri vývoji TK podľa tohto GOST je potrebné pamätať na iné normy, aj keď tento dokument neobsahuje odkazy na tieto normy.
6. GOST 34.603-92 Informačné technológie. Typy skúšok automatizovaných systémov - norma stanovuje typy skúšok AÚ (autonómne, integrované, akceptačné skúšky a skúšobná prevádzka) a všeobecné požiadavky na ich vykonávanie.
7. RD 50-34.698-90 Automatizované systémy. Požiadavky na obsah dokumentov sú jedným z najdôležitejších dokumentov 34 GOST, pretože v ňom je opísaný obsah takmer všetkých dokumentov, ako aj popis každého odseku dokumentu.
8. GOST R ISO / IEC 8824-3-2002 Informačné technológie. Abstraktný zápis syntaxe Verzia jedna – Táto medzinárodná norma je súčasťou abstraktného zápisu syntaxe 1 (ASN.1) a poskytuje zápis na špecifikovanie užívateľom definovaných obmedzení a obmedzení tabuliek.
9. GOST R ISO / IEC 10746-3-2001 Správa údajov a otvorené distribuované spracovanie.
   V tomto štandarde:
   • určuje sa, ako sú špecifikované systémy otvoreného distribuovaného spracovania (ODP) pomocou konceptov zavedených v GOST R ISO / IEC 10746-2;
   • identifikujú sa charakteristiky, podľa ktorých sú systémy klasifikované ako systémy ODP.

   Norma vytvára rámec pre koordináciu vývoja noriem pre systémy ODP.

10. GOST R ISO / IEC 15271-02 Procesy životného cyklu softvéru - tento GOST je podľa môjho názoru potrebný viac pre analytikov pri projektovaní a modelovaní jadrových elektrární.
    Tento dokument je z môjho pohľadu užitočný na čisto vzdelávacie účely.
11. GOST R ISO / IEC 15910-2002 Proces vytvárania užívateľskej dokumentácie pre softvérový nástroj - definuje minimálny požadovaný proces vytvárania užívateľskej dokumentácie všetkého druhu pre softvérový nástroj, ktorý má užívateľské rozhranie. Tieto zobrazenia pokrývajú tlačenú dokumentáciu (napríklad používateľské príručky a rýchle referenčné karty), interaktívnu (prevádzkovú) dokumentáciu, text pomocníka ("pomoc") a systémy interaktívnej dokumentácie.

Takže na základe všetkého napísaného vyššie je zrejmé, že hlavné dokumenty v 34 GOST 3: GOST 34.201-89, RD 50-34.698-90 a GOST 34.602-89.
Pri vývoji balíka dokumentácie musíte najskôr otvoriť GOST 34.201-89 a vybrať fázu tvorby Návrh návrhu, Technický návrh a Pracovná dokumentácia. Ďalej by ste mali vybrať dokumenty na vývoj, ktoré zodpovedajú štádiu vytvorenia.

Zoznam dokumentov 34 GOST

Etapa tvorba	Názov dokumentu	Kód	Časť projekt	Prinad posteľ do projektu ale odhadnúť noah dok policajt cie	Prinad posteľ do vykorisťovanie stanica noah hore kuménu staníc	Ďalšie pokyny
EP	Schematický návrhový list	EP *	ALEBO	—	—	—
	Vysvetľujúca poznámka K návrhu dizajnu	P1	ALEBO	—	—	—
EP, TP	Organizačná schéma	CO	ALEBO	—	—	Do dokladu je povolené zahrnúť P3 alebo PV
	Štrukturálna schéma komplexu technické prostriedky	C1 *	POTOM	X	—
	Schéma funkčnej štruktúry	C2 *	ALEBO	—	—	Pri vývoji dokumentov CO, C1, C2, C3 v štádiu ES je povolené zahrnúť ich do dokumentu P1
	špecializované (nové) technické prostriedky	O 9	POTOM	X	—	Pri vývoji v štádiu TP povolené zahrnúť do dokumentu P2
	Schéma automatizácie	C3 *	POTOM	X	—	—
	Referenčné podmienky pre vývoj špecializované (nové) technické prostriedky	—	POTOM	—	—	Projekt nezahŕňa
TP	Vývojové úlohy sanitárne a ďalšie sekcie súvisiaci s projektom s vytvorením systému	—	POTOM	X	—	Projekt nezahŕňa
	Technický projektový list	TP *	ALEBO	—	—	—
	Zoznam zakúpených produktov	viceprezident *	ALEBO	—	—	—
	Zoznam vstupných signálov a údaje	V 1	A O	—	—	—
	Zoznam výstupných signálov (Dokumenty)	V 2	A O	—	—	—
	Zoznam vývojových úloh stavebníctvo, elektro, sanitárne a ďalšie sekcie súvisiaci s projektom s vytvorením systému	O 3	POTOM	X	—	Je povolené zahrnúť do dokumentu P2
	Vysvetľujúca poznámka k technickému projektu	P2	ALEBO	—	—	Zahŕňa akčný plán pripraviť objekt na uvedenie do prevádzky systémy v prevádzke
	Popis automat funkcie	P3	ALEBO	—	—	—
	Popis nastavenia úlohy (súbor úloh)	P4	ALEBO	—	—	Je povolené zahrnúť na dokumenty P2 alebo P3
	Popis informácií systémová podpora	P5	A O	—	—	—
	Popis organizácie informačnú základňu	P6	A O	—	—	—
TP	Opis klasifikačných systémov a kódovanie	P7	A O	—	—	—
	Popis poľa informácie	P8	A O	—	—	—
	Popis komplexu technické prostriedky	P9	POTOM	—	—	Pre úlohu je povolené zahrnúť do dokumentu 46 podľa GOST 19.101
	Popis softvéru zaistenie	PA	ON	—	—	—
	Popis algoritmu (postup návrhu)	PB	MO	—	—	Je povolené zahrnúť do dokumentov P2, P3 alebo P4
	Popis organizácie štruktúry	PV	OO	—	—	—
	Plán rozloženia	C8	POTOM	X	—	Je povolené zahrnúť do dokumentu P9
	Zoznam vybavenia a materiálov	—	POTOM	X	—	—
	Výpočet miestneho odhadu	B2	ALEBO	X	—	—
TP, RD	Hodnotenie projektu spoľahlivosť systému	B1	ALEBO	—	—	—
	Výkres formulára dokumentu (snímka videa)	C9	A O	—	X	V štádiu TP je to povolené zahrnúť do dokumentov P4 alebo P5
RD	Zoznam držiteľov originály	DP *	ALEBO	—	—	—
	Vyhlásenie o prevádzke Dokumenty	ED *	ALEBO	—	X	—
	Špecifikácia hardvéru	AT 4	POTOM	X	—	—
	Vyhlásenie o požiadavke v materiáloch	O 5	POTOM	X	—	—
	Zoznam médií stroja informácie	VM *	A O	—	X	—
	Pole vstupných údajov	O 6	A O	—	X	—
RD	Databázový adresár	O 7	A O	—	X	—
	Zloženie výstupu (správy)	O 8	A O	—	X	—
	Miestne odhady	B3	ALEBO	X	—	—
	Metóda (technológia) automatizované projektovanie	I1	OO	—	X	—
	Technologický návod	A 2	OO	—	X	—
	Užívateľská príručka	I3	OO	—	X	—
	Návod na tvarovanie a údržba databázy (množina údajov)	I4	A O	—	X	—
	Návod na obsluhu KTS	IE	POTOM	—	X	—
	Schéma externého zapojenia	C4 *	POTOM	X	—	Je povolené vystupovať v vo forme tabuliek
	Schéma zapojenia vonkajšie vedenie	C5 *	POTOM	X	—	Tiež
	Tabuľka pripojenia a pripojenia	C6	POTOM	X	—	—
	Schéma delenia systému (štrukturálne)	E1 *	POTOM	—	—	—
	Výkres celkového usporiadania	IN*	POTOM	X	—	—
	Inštalačný výkres technického zariadenia	CA	POTOM	X	—	—
	Schematický diagram	So	POTOM	X	—	—
	Štrukturálna schéma komplexu technické prostriedky	C1 *	POTOM	X	—	—
	Rozmiestnenie zariadení a elektroinštalácie	C7	POTOM	X	—	—
	Popis technológie proces spracovania údaje (vrátane teleprocessing)	PG	OO	—	X	—
	Všeobecný popis systému	PD	ALEBO	—	X	—
	Testovací program a metodika (komponenty, automatizačné systémy, subsystémy, systémy)	POPOLUDNIE *	ALEBO	—	—	—
	Formulár	FD *	ALEBO	—	X	—
	Pas	PS *	ALEBO	—	X	—
* Dokumenty, ktorých kód je stanovený v súlade s požiadavkami noriem ESKD

Poznámka k tabuľke:

1. Tabuľka používa nasledujúce označenia:
   • EP - predbežný návrh;
   • TP - technické prevedenie;
   • RD - pracovná dokumentácia;
   • OR - celosystémové riešenia;
   • OO - rozhodnutia o organizačnom zabezpečení;
   • TO - riešenia pre technickú podporu;
   • IO - riešenia pre informačnú podporu;
   • Softvér - softvérové ​​riešenia;
   • MO - softvérové ​​riešenia.
2. Znak X - označuje príslušnosť k projektovým odhadom alebo prevádzkovej dokumentácii.
3. Nomenklatúra dokumentov jedného mena sa stanovuje v závislosti od rozhodnutí o dizajne prijatých pri vytváraní systému.

Keď je určený zoznam dokumentov, potom v RD 50-34.698-90 by ste mali nájsť vybrané dokumenty a rozvinúť ich presne podľa uvedených bodov. Všetky body obsahu, ktoré sú uvedené, musia byť v dokumente.
Ak sa vyvíja referenčný rámec, musíte okamžite otvoriť GOST 34.602-89 a vypracovať technickú špecifikáciu presne podľa odsekov.

GOST 19

Séria GOST 19 (GOST 19.xxx The Unified Programming Documentation System (ESPD)) pozostáva z:

1. 1. GOST 19.001-77 Všeobecné ustanovenia - príliš všeobecný dokument, nie je praktický. Preto ho môžete preskočiť.
   2. GOST 19781-90 Termíny a definície - dobrý zoznam definície v oblasti softvéru pre systémy spracovania informácií. Okrem definícií neobsahuje nič iné.
   3. GOST 19.101-77 Typy programov a programových dokumentov - jeden z hlavných dokumentov 19 GOST. Práve s ním by ste mali začať pracovať s 19 GOST, pretože obsahuje úplný zoznam a označenia dokumentov GOST.

Zoznam dokumentov 19 GOST

Kód	Typ dokumentu	Vývojové štádiá
		Skica projektu	Technická projektu	Pracovný návrh
				komponent	komplexný
—	Špecifikácia	—	—
05	Zoznam pôvodných držiteľov	—	—	—
12	Text programu	—	—
13	Popis programu	—	—
20	Výkaz prevádzkových dokladov	—	—
30	Formulár	—	—
31	Popis aplikácie	—	—
32	Príručka systémového programátora	—	—
33	Príručka programátora	—	—
34	Návod na obsluhu	—	—
35	Popis jazyka	—	—
46	Technická príručka údržbu	—	—
51	Testovací program a metodika	—	—
81	Vysvetľujúca poznámka			—	—
90-99	Ostatné dokumenty

Legenda:
- doklad je povinný;
- dokument je povinný pre komponenty, ktoré majú nezávislú aplikáciu;
- potreba vypracovať dokument je určená v štádiu vývoja a schvaľovania zadávacích podmienok;
- dokument nie je vyhotovený.

1. GOST 19.102-77 Vývojové štádiá – obsahuje popis vývojových štádií. Užitočné na vzdelávacie účely. Podľa môjho názoru to nemá osobitný praktický prínos.
2. GOST 19.103-77 Označenia programov a programových dokumentov - obsahuje popis priradenia čísla (kódu) dokumentu. Aj po prečítaní tohto GOST zostáva veľa otázok o tom, ako priradiť toto číslo dokumentu.
3. GOST 19.104-78 Základné nápisy - stanovuje formy, veľkosti, umiestnenie a postup vyplnenia základných nápisov schvaľovacieho hárku a titulnej strany v programových dokumentoch stanovených normami ESPD, bez ohľadu na spôsoby ich implementácie. Keďže dokumenty 19 GOST sú zostavené v rámoch, tento dokument je veľmi dôležitý.
4. GOST 19.105-78 Všeobecné požiadavky na programové dokumenty - stanovuje všeobecné požiadavky na dizajn programových dokumentov. Požiadavky sú príliš všeobecné. Spravidla sa tento GOST takmer nikdy nepoužíva na vývoj dokumentu, pretože pre dokument existuje dostatok špeciálnych GOST, ale pre všeobecné znalosti v tomto GOST je stále lepšie pozrieť sa raz.
5. GOST 19.106-78 Požiadavky na tlačené softvérové ​​dokumenty - obsahuje požiadavky na dizajn všetkých dokumentov GOST 19.
6. GOST 19.201-78 Zadávacie podmienky, požiadavky na obsah a dizajn – stanovuje postup konštrukcie a vyhotovenia technických špecifikácií pre vývoj programu alebo softvérového produktu.

   Klauzuly TK 34 GOST a 19 GOST sa líšia.

7. GOST 19.601-78 Všeobecné pravidlá pre duplikáciu, účtovníctvo a skladovanie - všeobecné pravidlá rozmnožovanie, obeh, účtovanie a uchovávanie programových dokumentov. V GOST je v niekoľkých odsekoch popísané, ako zabezpečiť, aby sa dokumenty nestratili.
8. GOST 19.602-78 Pravidlá pre duplikáciu, účtovanie a ukladanie programových dokumentov, dokončená tlač. Svojím spôsobom - dodatok k GOST 19.601-78.
9. GOST 19.603-78 Všeobecné pravidlá pre vykonávanie zmien - stanovuje všeobecné pravidlá pre vykonávanie zmien v programových dokumentoch. V podstate popisuje dlhý byrokratický algoritmus na vykonávanie zmien v dokumentoch.
10. GOST 19.604-78 Pravidlá pre vykonávanie zmien v programových dokumentoch vyhotovených tlačeným spôsobom - popisuje postup práce a vyplnenia Registračného listu zmien zo zoznamu.

Zoznam špecializovaných GOST, to znamená, že každá z nich popisuje obsah a požiadavky na konkrétny dokument:

1. Špecifikácia GOST 19.202-78. Požiadavky na obsah a dizajn;
2. GOST 19.301-79 Program a skúšobný postup. Požiadavky na obsah a dizajn;
3. GOST 19.401-78 Text programu. Požiadavky na obsah a dizajn;
4. GOST 19.402-78 Popis programu;
5. GOST 19.403-79 Zoznam pôvodných držiteľov;
6. GOST 19.404-79 Vysvetlivka. Požiadavky na obsah a dizajn;
7. Formulár GOST 19.501-78. Požiadavky na obsah a dizajn;
8. GOST 19.502-78 Popis aplikácie. Požiadavky na obsah a dizajn;
9. GOST 19.503-79 Príručka systémového programátora. Požiadavky na obsah a dizajn;
10. GOST 19.504-79 Príručka programátora. Požiadavky na obsah a dizajn;
11. GOST 19.505-79 Návod na obsluhu. Požiadavky na obsah a dizajn;
12. GOST 19.506-79 Popis jazyka. Požiadavky na obsah a dizajn;
13. GOST 19.507-79 Výpis prevádzkových dokumentov;
14. GOST 19.508-79 Návod na údržbu. Požiadavky na obsah a dizajn.

Postup pri práci s 19 GOST:

1. V GOST 19.101-77 vyberte dokument a jeho kód podľa štádia vývoja.
2. Podľa GOST 19.103-77 priraďte dokumentu číslo.
3. Potom v súlade s GOST 19.104-78 a 19.106-78 vypracujte dokument.
4. Zo špecializovaného zoznamu GOST by ste si mali vybrať ten, ktorý zodpovedá vyvíjanému dokumentu.

Záver

GOST nie je strašidelný a jednoduchý! Hlavná vec je pochopiť, čo je potrebné napísať a čo sa na to používa GOST. Naše hlavné GOST 19 a 34 na písanie dokumentácie sú veľmi staré, ale dodnes sú relevantné. Písanie dokumentácie v súlade s normou odstraňuje mnohé otázky medzi zhotoviteľom a objednávateľom. Preto šetrí čas a peniaze.

Dátum zavedenia 01.01.92

Táto norma platí pre automatizované systémy (AS) používané v odlišné typyčinnosti (výskum, dizajn, manažment atď.), vrátane ich kombinácií, vytvorené v organizáciách, združeniach a podnikoch (ďalej len organizácie).

Norma stanovuje štádiá a štádiá vytvárania rečníka. Príloha 1 obsahuje obsah práce v každej etape.

1. Všeobecné ustanovenia

2. Etapy a etapy tvorby rečníka

Dodatok 1 (odkaz)

Dodatok 2 (odkaz)

1. VŠEOBECNÉ USTANOVENIA

1.1. je súbor časovo usporiadaných, vzájomne prepojených, zjednotených v etapách a etapách prác, ktorých realizácia je potrebná a postačujúca na vytvorenie AU, ktorá spĺňa stanovené požiadavky.

1.2. Etapy a etapy tvorby AU sa rozlišujú ako súčasť procesu tvorby z dôvodov racionálneho plánovania a organizácie práce, končiacej daným výsledkom.

1.3. Práce na vývoji AÚ sa vykonávajú podľa etáp a etáp použitých na vytvorenie AÚ.

1.4. Zloženie a pravidlá pre vykonávanie prác v etapách a etapách ustanovených touto normou sú určené v príslušnej dokumentácii organizácií podieľajúcich sa na vytváraní konkrétnych typov jadrových elektrární.

Zoznam organizácií podieľajúcich sa na vytvorení AÚ je uvedený v prílohe 2.

2. ETAPA A ETAPA VZNIKU AU

2.1. Fázy a fázy vytvárania AU vo všeobecnom prípade sú uvedené v tabuľke.

Etapy	Etapy práce
1. Tvorba požiadaviek na AÚ	1.1. Prieskum lokality a zdôvodnenie potreby vytvorenia jadrovej elektrárne
	1.2. Formovanie požiadaviek používateľov na reproduktor
	1.3. Registrácia správy o vykonanej práci a žiadosť o vypracovanie AU (taktické a technické zadanie)
2. Vývoj koncepcie AÚ	2.1. Štúdia objektu
	2.2. Vykonávanie potrebných výskumných prác
	2.3. Vývoj variant koncepcie reproduktora a výber verzie koncepcie reproduktora, ktorá uspokojí požiadavky užívateľa
	2.4. Evidencia správy o vykonanej práci
3. Referenčné podmienky	3.1. Vypracovanie a schválenie technických špecifikácií pre vytvorenie AÚ
4. Návrh projektu	4.1. Vývoj predbežných konštrukčných riešení systému a jeho častí
	4.2. Vypracovanie dokumentácie pre JE a jej časti
5. Technické prevedenie	5.1. Vývoj konštrukčných riešení systému a jeho častí
	5.2. Vypracovanie dokumentácie pre JE a jej časti
	5.3. Vypracovanie a vyhotovenie dokumentácie pre dodávku produktov pre dostavbu jadrových elektrární a (alebo) technické požiadavky (technické špecifikácie) na ich vývoj
	5.4. Vypracovanie návrhových zadaní v priľahlých častiach projektu objektu automatizácie
6. Pracovná dokumentácia	6.1. Vypracovanie pracovnej dokumentácie pre systém a jeho časti
	6.2. Vývoj alebo prispôsobenie programov
7. Uvedenie do činnosti	7.1. Príprava objektu automatizácie na uvedenie JE do prevádzky
	7.2. Školenie personálu
	7.3. Doplnenie reproduktorovej sústavy o dodané produkty (softvér a hardvér, softvérové ​​a hardvérové ​​komplexy, informačné produkty)
	7.4. Stavebné a inštalačné práce
	7.5. Kolaudačné práce
	7.6. Predbežné testy
	7.7. Skúšobná prevádzka
	7.8. Akceptačné testy
8. Sprevádzanie AÚ	8.1. Vykonávanie prác v súlade so záručnými povinnosťami
	8.2. Pozáručný servis

2.2. Etapy a etapy vykonávané organizáciami - účastníkmi prác na vytvorení AÚ, sú stanovené v zmluvách a zadávacích podmienkach na základe tohto štandardu.

Je dovolené vylúčiť etapu „Návrh návrhu“ a samostatné etapy prác vo všetkých etapách, spojiť etapy „Technický návrh“ a „Pracovná dokumentácia“ v jednej etape „Technický návrh“. V závislosti od špecifík vytváraných jadrových systémov a podmienok ich vzniku je možné vykonávať jednotlivé etapy prác pred ukončením predchádzajúcich etáp, súbežne s časovým vykonávaním etáp prác, zaraďovaním nových etáp prác. .

PRÍLOHA 1 Odkaz

1. V etape 1.1 „Prieskum zariadenia a zdôvodnenie potreby výstavby jadrovej elektrárne“ vo všeobecnosti vykonajte:

• zhromažďovanie údajov o objekte automatizácie a vykonávaných činnostiach;
• hodnotenie kvality objektu a vykonávaných činností, identifikácia problémov, ktorých riešenie je možné pomocou automatizácie;
• posúdenie (technické, ekonomické, sociálne atď.) uskutočniteľnosti vytvorenia AÚ.

2. Vo fáze 1.2 „tvorba požiadaviek používateľov na AÚ“ vykonajte:

• príprava počiatočných podkladov pre tvorbu požiadaviek na jadrovú elektráreň (charakteristika objektu automatizácie, popis požiadaviek na systém, obmedzenie prípustných nákladov na vývoj, uvedenie do prevádzky a prevádzku, očakávaný efekt od systému, podmienky pre vytvorenie a prevádzka systému);
• formulácia a realizácia užívateľských požiadaviek na AÚ.

3. V etape 1.3 „Vypracovanie správy o vykonanej práci a žiadosti o vypracovanie AÚ (takticko-technické zadanie)“ sa vypracuje správa o vykonanej práci v tejto etape a žiadosť o vypracovanie AÚ. s podobným obsahom sa vypracuje AÚ (takticko-technické zadanie) alebo iný dokument, ktorý ho nahrádza.

4. V etapách 2.1 „Štúdium objektu“ a 2.2 „Vykonanie potrebných výskumných prác“ vykonáva developerská organizácia podrobnú štúdiu objektu automatizácie a potrebné výskumné práce (R&D) súvisiace s hľadaním spôsobov a posúdením možnosti implementáciu požiadaviek používateľov, vypracúvanie a schvaľovanie správ o výskume.

5. V etape 2.3 „Vývoj možností pre koncepciu AU a výber verzie koncepcie AU, ktorá spĺňa požiadavky užívateľa“, vo všeobecnom prípade vývoj tzv. alternatívne možnosti koncepcia vytváranej AÚ a plány ich realizácie; ohodnotenie potrebné zdroje na ich implementáciu a udržanie fungovania; posúdenie výhod a nevýhod každej možnosti; porovnanie užívateľských požiadaviek a vlastností navrhovaného systému a výber najlepšia možnosť; určenie postupu posudzovania kvality a podmienok prevzatia systému; hodnotenie účinkov získaných zo systému.

6. V etape 2.4 „Správa o vykonanej práci“ pripraviť a vypracovať správu obsahujúcu popis vykonanej práce v etape, popis a zdôvodnenie navrhovanej verzie koncepcie systému.

7. V etape 3.1 „Vypracovanie a schvaľovanie zadávacích podmienok na vytvorenie JE“ vypracovanie, vyhotovenie, koordinácia a schválenie zadania JE a v prípade potreby zadania pre časť JE. sa realizujú JE.

8. V etape 4.1 „Vývoj predbežných konštrukčných riešení pre systém a jeho časti“ určiť: funkcie AÚ; funkcie subsystémov, ich ciele a účinky; zloženie komplexov úloh a jednotlivých úloh; koncepcia informačnej základne, jej rozšírená štruktúra; funkcie systému správy databáz; zloženie výpočtového systému; funkcie a parametre hlavného softvéru.

9. V etape 5.1 „Vývoj konštrukčných riešení systému a jeho častí“ zabezpečiť vývoj všeobecných riešení pre systém a jeho časti, funkčnú a algoritmickú štruktúru systému, pre funkcie personálu a Organizačná štruktúraštruktúrou technických prostriedkov, algoritmami na riešenie problémov a používanými jazykmi, organizáciou a údržbou informačnej základne, systémom klasifikácie a kódovania informácií, softvérom.

10. Vo fázach 4.2 a 5.2 " Vypracovanie dokumentácie na JE a jej častiach „vykonať vypracovanie, vyhotovenie, koordináciu a schválenie dokumentácie v rozsahu potrebnom na popísanie kompletného súboru prijatých projektových riešení a postačujúceho pre ďalšie práce na tvorbe JE. Typy dokumentov - podľa GOST 34.201.

11. V etape 5.3 „Vypracovanie a vyhotovenie dokumentácie na dodávku produktov dostavby JE a (alebo) technických požiadaviek (technických špecifikácií) na ich vypracovanie“ pripraviť a vykonať dokumentáciu na dodávku produktov na dostavbu JE; stanovenie technických požiadaviek a príprava technických špecifikácií pre vývoj produktov, ktoré nie sú sériovo vyrábané.

12. V etape 5.4 „Vypracovanie projektových zadaní v susedných častiach projektu automatizácie“ vykonať vypracovanie, vyhotovenie, koordináciu a schválenie projektových zadaní v priľahlých častiach objektu automatizácie pre stavebné, elektrické, sanitárne a iné prípravné práce súvisiace s vytvorenie AC.

13. V etape 6.1 „Vypracovanie pracovnej dokumentácie pre systém a jeho časti“ je vypracovaná pracovná dokumentácia obsahujúca všetky potrebné a dostatočné informácie na zabezpečenie výkonu prác na spúšťaní JE a jej prevádzke, ako aj na udržiavanie úroveň prevádzkových charakteristík (kvality) systému v súlade s prijatými projektovými rozhodnutiami, jeho evidencia, koordinácia a schvaľovanie. Typy dokumentov - podľa GOST 34.201.

14. V štádiu 6.2 „Vývoj alebo prispôsobenie programov“ sa vyvíjajú programy a softvér systému, výber, prispôsobenie a (alebo) viazanie zakúpeného softvéru, vývoj softvérovej dokumentácie v súlade s GOST 19.101.

15. V etape 7.1 „Príprava objektu automatizácie na spúšťanie JE“ sa vykonávajú práce na organizačnej príprave objektu automatizácie na spúšťanie JE, zahŕňajúce: realizáciu projektových riešení organizačnej štruktúry JE; poskytovanie inštruktážnych a metodických materiálov pododdielov objektu riadenia; zavedenie klasifikátorov informácií.

16. V etape 7.2 „Výcvik personálu“ sa školí personál a testuje sa jeho schopnosť zabezpečiť prevádzku JE.

17. V etape „Kompletizácia AÚ dodanými výrobkami“ zabezpečiť príjem komponentov sériovej a kusovej výroby, materiálov a montážnych výrobkov. Vykonávajú vstupnú kontrolu kvality.

18. V etape 7.4 „Stavebné a inštalačné práce“ sa vykonáva: vykonávanie prác na výstavbe špecializovaných objektov (areálov) na umiestnenie technického vybavenia a personálu JE; výstavba káblových kanálov; vykonávanie prác na inštalácii technických prostriedkov a komunikačných vedení; testovanie inštalovaných technických zariadení; dodávka technických prostriedkov na uvedenie do prevádzky.

19. V etape 7.5 „Uvedenie do prevádzky“ vykonať autonómne nastavenie hardvéru a softvéru, načítanie informácií do databázy a kontrolu systému z hľadiska jeho údržby; komplexné nastavenie všetkých systémových prostriedkov.

20. V štádiu 7.6 „Predbežné testy“ vykonajte:

• skúšanie prevádzkyschopnosti jadrovej elektrárne a jej plnenia v súlade s programom a metódou predbežných skúšok;
• odstraňovanie porúch a zmeny dokumentácie pre JE vrátane prevádzkovej v súlade so správou o skúške;
• registrácia osvedčenia o kolaudácii jadrovej elektrárne do skúšobnej prevádzky.

21. V etape 7.7 „Skúšobná prevádzka“ sa vykonáva skúšobná prevádzka JE; analýza výsledkov experimentálnej prevádzky JE; revízia (ak je to potrebné) softvéru AC; dodatočná úprava (v prípade potreby) hardvéru JE; registrácia osvedčenia o vykonaní skúšobnej prevádzky.

22. V štádiu 7.8 „Akceptačné testy“ vykonajte:

• testy zhody so zadávacími podmienkami v súlade s programom a metódami akceptačných testov;
• analýza výsledkov skúšok AU a odstránenie nedostatkov zistených počas skúšok;
• evidencia osvedčenia o prevzatí jadrovej elektrárne do trvalej prevádzky.

23. V etape 8.1 „Vykonávanie prác v súlade so záručnými povinnosťami“ sa vykonávajú práce na odstránení nedostatkov zistených pri prevádzke JE v ustanovených záručných lehotách, na vykonanie potrebných zmien dokumentácie pre JE.

24. V etape 8.2 „Pozáručný servis“ sa vykonávajú práce na:

• analýza fungovania systému;
• identifikácia odchýlok skutočných prevádzkových charakteristík JE od projektových hodnôt;
• stanovenie dôvodov týchto odchýlok;
• odstránenie zistených nedostatkov a zabezpečenie stability prevádzkových charakteristík JE;
• vykonanie potrebných zmien v dokumentácii pre AÚ.

DODATOK 2. Odkaz

ZOZNAM ORGANIZÁCIÍ ZÚČASTNENÝCH NA PRÁCI NA VYTVORENÍ AÚ

1. Organizácia-odberateľ (užívateľ), pre ktorú bude JE vytvorená a ktorá zabezpečuje financovanie, preberanie prác a prevádzku JE, ako aj vykonávanie jednotlivých prác na vytvorení JE.

2. Organizácia-vývojár, ktorý vykonáva práce na vytvorení AU, poskytuje zákazníkovi súbor vedeckých a technických služieb pre rôznych štádiách a fázach tvorby, ako aj vývoja a dodávky rôzneho softvéru a hardvéru AU.

3. Dodávateľská organizácia, ktorá vyrába a dodáva softvér a hardvér na žiadosť vývojára alebo zákazníka.

4. Organizačno-generálny dizajnér objektu automatizácie.

5. Dizajnérske organizácie rôzne časti projekt automatizačného objektu pre stavebné, elektrické, sanitárne a iné prípravné práce súvisiace s vytvorením jadrovej elektrárne.

6. Organizácie pre výstavbu, montáž, uvedenie do prevádzky a iné.

Poznámky:

1. V závislosti od podmienok vytvorenia AU sú možné rôzne kombinácie funkcií zákazníka, vývojára, dodávateľa a iných organizácií podieľajúcich sa na tvorbe AU.

2. Etapy a etapy ich práce na vytvorení AÚ sú určené na základe tohto štandardu.

INFORMAČNÉ ÚDAJE

1. VYVINUTÝ A ZAVEDENÝ Štátnym výborom ZSSR pre riadenie kvality výrobkov a normy

VÝVOJÁRI

Yu.Kh. Vermišev, Dr. vedy; Ya.G. Vilenchik; IN AND. Voropajev, Dr. vedy; L.M. Seidenberg, Cand. tech. vedy; Yu.B. Irz, Cand. tech. vedy; V.D. Kosťukov, Cand. tech. vedy; M.A. Labutín, kond. tech. vedy; N.P. Leskovskaja; JE. Mityaev; V.F. Popov (vedúci témy); S.V. Garshina; A.I. Hluchý veriaci; JUH. Žukov, Cand. Tech. vedy; Z.P. Zadubovskaya; V.G. Ivanov; Yu.I. Karavanov, Cand.Tech. vedy; A.A. Skartácie; V.Yu Korolev; IN AND. Machnáč, Cand. tech. vedy; S. B. Michalev, Dr. vedy; V.N. Petrikevič; V.A. Rachmanov, Cand. ekonomika. vedy; A.A. Ratkovič; R.S. Sedegov, Dr. vedy; N.V. Stepanchikova; PANI. Surovets; A.V. Fleents; L.O. Chvilevskij, Cand. tech. vedy; VC. Chistov, Cand. ekonomika. vedy

2. SCHVÁLENÉ A UVEDENÉ DO ČINNOSTI vyhláškou Štátneho výboru ZSSR pre riadenie a normy kvality výrobkov zo dňa 29.12.1990 č.3469