Delovna dokumentacija GOST 34. Kaj je dobro v standardu. Vrste in imena dokumentov

Standardi IT so daleč napredovali zadnja leta, in da bi pokazal, kako se sodobni procesno usmerjeni standardi bistveno razlikujejo od tradicionalnih, bom začel z verjetno najbolj znanim standardom pri nas, GOST 34, ki še vedno uteleša koncept IT standarda na splošno za mnoge managerje (in IT). specialisti). Poskušal bom, ne da bi se preveč poglobil v podrobnosti, analizirati prakso njegove uporabe, pa tudi možnosti za njegovo uporabo kot vir referenčnih procesov upravljanja IT.

Štiriintrideseti GOST v žargonu IT strokovnjakov je niz med seboj povezanih standardov, ki imajo številko, ki se začne s 34: GOST 34.602-89, 34.003-90, 34.603-92, 34.201-89, 34.601-90, 34.698-90, 34.320-96, 34.321-96, kot tudi smernice RD 50-34.698-90 in dva samostojna standarda, povezana z visoko specializirano temo kriptografske zaščite - GOST 34.10 -01 in GOST 34.11-94.

Vsi ti standardi so se pojavili v poznih 80-ih - zgodnjih 90-ih (leto izdaje je označeno s številko za vezajem), ki je nadomestilo ali dopolnilo prejšnje standarde 19. in 24. serije.

Da bi razumeli in ocenili logiko, ki jo vsebuje družina GOST 34, podrobneje analiziramo vsebino njenih sestavnih standardov. GOST 34.320-96 "Koncepti in terminologija za konceptualni diagram in informacijsko bazo", GOST 34.321-96, namenjen IT strokovnjakom. "Referenčni model za upravljanje podatkov", GOST 34.10 -01 "Kriptografski varovanje informacij. Postopki za ustvarjanje in preverjanje elektronskih digitalni podpis" in GOST 34.11-94 "Kriptografski varovanje informacij. Ne bom upošteval funkcije zgoščevanja, ker niso namenjeni menedžerjem, ampak tehničnim strokovnjakom. Za nas so zanimivi naslednji standardi:

• GOST 34.201-89. "Vrste, popolnost in poimenovanje dokumentov pri ustvarjanju avtomatiziranih sistemov";
• GOST 34.003-90 "Izrazi in definicije";
• GOST 34.602-89 " Referenčna naloga ustvarjati avtomatiziran sistem";
• GOST 34.603-92 "Vrste testiranja avtomatiziranih sistemov";
• GOST 34.601-90 "Avtomatizirani sistemi. Faze ustvarjanja";
• Vodilni dokument RD 50-34.698-90 "Avtomatizirani sistemi. Zahteve za vsebino dokumentov."

GOST 34.003-90, poleg tega, da vsebuje številne napake, je popolnoma zastarel in je izgubil svoj pomen, zato o tem ne bom govoril. Tako so naslednji štirje dokumenti obravnavani.

Standard GOST 34.201-89

Resno zastarel, a delno uporaben standard (GOST 34, 1989a). Ugotavlja skladnost dokumentov s fazami ustvarjanja AS 1 AS je avtomatiziran sistem, to je informacijski sistem, razvit ali implementiran v določenem podjetju., opisan v GOST 24.601 (kasneje nadomeščen z GOST 34.601). Na podlagi sestave dokumentov in faz projekta je mogoče slediti izvoru standarda iz gradbene prakse. Očitno je projektna narava gradnje in aktivnosti za vzpostavitev informacijskega sistema vodila avtorje standarda do ideje o razširitvi osnovnih oblik organizacije. gradbeni projekti za projekte izdelave informacijskih sistemov. Delno se je to izkazalo za priročno - dokumenti, omenjeni v standardu, kot so " Referenčna naloga", "Skica načrta", " Tehnični projekt", "Navodila" (za uporabnika), "Program in metode testiranja" so se trdno uveljavili v praksi ustvarjanja sistemov. Po drugi strani pa "Seznam računalniških pomnilniških medijev", "Imenik baze podatkov" ali "Seznam izvirnih imetniki" zdaj verjetno ne bodo več smiselni. Standard vključuje tudi elemente pisarniške prakse v obliki pravil kodiranja dokumentov.

Skratka, z “kreativnim” pristopom lahko še kako služi, predvsem v tistih organizacijah, kjer projektne aktivnosti urejajo podobni projektno usmerjeni standardi, sestava projektne dokumentacije pa je blizu tistemu, kar ponuja GOST 34.201-89.

Standard GOST 34.601-90

Eden najbolj razširjenih standardov doslej (GOST 34, 1990), ki določa stopnje in faze ustvarjanja avtomatiziranega sistema. Spodnja tabela je osrednja za standard.

Tabela 2.1.

Faze in stopnje ustvarjanja avtomatiziranega sistema po GOST 34.601-90	Faze
Faze	1. Oblikovanje zahtev za govorce
	1.1. Pregled objekta in utemeljitev potrebe po izgradnji jedrske elektrarne
	1.2. Oblikovanje uporabniških zahtev za zvočnike
1.3. Izdelava poročila o opravljenem delu in vloge za razvoj AS (taktične in tehnične specifikacije)	2. Razvoj koncepta AC
	2.1. Preučevanje predmeta
	2.2. Izvajanje potrebnega raziskovalnega dela
	2.3. Razvoj variant koncepta zvočnikov, ki ustreza zahtevam uporabnikov
2.4. Sestava poročila o opravljenem delu	3.1 Razvoj in odobritev tehničnih specifikacij za izgradnjo jedrske elektrarne
4. Osnutek zasnove	4.1. Razvoj predhodnih oblikovalske rešitve po sistemu in njegovih delih
	4.2. Razvoj dokumentacije za zvočniški sistem in njegove dele
5. Tehnični projekt	5.1. Razvoj projektnih rešitev za sistem in njegove dele
	5.2. Razvoj dokumentacije za zvočniški sistem in njegove dele
	5.3. Razvoj in izvedba dokumentacije za dobavo izdelkov za dokončanje zvočnikov in (ali) tehnične zahteve(tehnične specifikacije) za njihov razvoj
	5.4. Izdelava projektnih nalog v sosednjih delih projekta avtomatizacije
6. Delovna dokumentacija	6.1. Razvoj delovna dokumentacija na sistem in njegove dele
	6.2. Razvoj ali prilagoditev programov
7. Zagon	7.1. Priprava objekta avtomatizacije za začetek obratovanja NEK
	7.2. Usposabljanje osebja
	7.3. Komplet zvočnikov z dobavljenimi izdelki (programska in strojna oprema, programski in strojni sistemi, informacijski izdelki)
	7.4. Gradbena in inštalacijska dela
	7.5. Zagonsko delo
	7.6. Izvajanje predhodni testi
	7.7. Izvajanje poskusno obratovanje
	7.8. Izvajanje sprejemni testi
8. AC podpora	8.1. Izvajanje del v skladu z garancijskimi obveznostmi
	8.2. Pogarancijski servis

Skoraj vse naštete stopnje se še vedno srečujejo v praksi ustvarjanja informacijskih sistemov za podjetja in organizacije. Seveda lahko standardu očitamo njegovo nefleksibilnost glede zaporedja in poimenovanj stopenj in stopenj, vendar ostaja dejstvo, da je pokazal izjemno vitalnost in razumevanje razloga za to je veliko pomembnejše od kritiziranja razvoja skoraj pred 20 leti. Zdi se mi, da standard dokazuje, da se zelo ujema s svojimi cilji. Prvič, ne zahteva IT znanja in je zato razumljiv navadnim menedžerjem. Drugič, je kompakten in preprost v strukturi, kar omogoča osebi, ki je ne pozna, hitro pridobi hitrost. Tretjič, je samozadosten - v njem praktično ni sklicevanj na sorodne dokumente (z izjemo GOST 34.201). In končno, praktičen je - takoj je jasno, kako ga uporabljati in kako nadzorovati njegovo uporabo.

Poleg zgornje tabele GOST 34.601-90 vsebuje referenčni dodatek 1 s postopno razčlenitvijo dela, vključno z navedbo dokumentov, ki izhajajo iz tega dela, kot tudi dodatek 2 - »Seznam organizacij, ki sodelujejo pri gradnji jedrskih elektrarn." To predlaga način za prilagoditev standarda posebnim pogojem: dovolj je, da predelate aplikacije in dobili boste povsem razumen korporativni standard za ustvarjanje IP. In spet je to delo v moči navadnega menedžerja.

Standard GOST 34.602-89

Zahteva po »pripravi Referenčna naloga v skladu z GOST 34.602-89", je verjetno znano vsem, ki so vsaj enkrat sodelovali pri razvoju IP po meri ali njegovem sprejemanju, in vsem, ki so tako ali drugače povezani z informacijski sistemi. Nekateri razvijalci še vedno mislijo v dobri formi zapomnite si na pamet sestavo tehničnih specifikacij (TOR) v skladu z GOST 34.602-89 (GOST 34, 1989b).

1. Splošne informacije.
2. Namen in cilji nastanka (razvoja) sistema.
3. Značilnosti objektov avtomatizacije.
4. Sistemske zahteve.
5. Sestava in vsebina dela za ustvarjanje sistema.
6. Postopek kontrole in prevzema sistema.
7. Zahteve za sestavo in vsebino dela za pripravo objekta avtomatizacije za zagon sistema.
8. Zahteve glede dokumentacije.
9. Viri razvoja.

Poskusimo razumeti razloge za stalno priljubljenost tega standarda, ki je že presegel 20 let. Pravzaprav je celoten standard prepis naštetih devetih točk. Njegova velikost je le 11 strani, vendar obseg informacij koristne informacije presenetljivo velika. Če zavržemo očitne arhaizme, kot so skladi nekoč obstoječih algoritmov in programov, se izkaže, da je skoraj vse, o čemer govorimo, še vedno v celoti uporabno. Tukaj je primer enega od razdelkov.

"2.6.2. V pododdelku "Zahteve za funkcije (naloge)", ki jih izvaja sistem, je podano naslednje:

1. za vsak podsistem seznam funkcij, nalog ali njihovih kompleksov (vključno s tistimi, ki zagotavljajo interakcijo delov sistema), ki jih je treba avtomatizirati;

   pri ustvarjanju sistema v dveh ali več čakalnih vrstah - seznam funkcionalnih podsistemov, posameznih funkcij ali nalog, ki se izvajajo v 1. in naslednjih čakalnih vrstah;

2. časovni predpisi za izvajanje posamezne funkcije, naloge (ali sklopa nalog);
3. zahteve po kakovosti izvajanja posamezne funkcije (naloge ali sklopa nalog), po obliki predstavitve izhodne informacije, značilnosti zahtevane natančnosti in časa izvajanja, zahteve za sočasno izvajanje skupine funkcij, zanesljivost rezultatov;
4. seznam in kriteriji napak za vsako funkcijo, za katero so določene zahteve glede zanesljivosti."

Zgornji odlomek prikazuje hierarhično naravo standarda: sistem je sestavljen iz podsistemov, sklopov nalog, posameznih nalog in funkcij. Čim natančneje in podrobneje so zahteve oblikovane, tem bolj predvidljiv bo rezultat. Posebej so oblikovane zahteve za funkcije interakcije podsistemov (zdaj bi rekli »integracijske metode«), funkcije so vezane na urnik implementacije sistema (ki s tem postane tudi hierarhičen). Zahteve glede kakovosti so posebej navedene. Predstavitveni obrazec izhodne informacije, tj. posebej je treba omeniti tudi sklop poročil. Z eno besedo, predstavljeni odlomek kaže, da razvoj tehničnih specifikacij v skladu z GOST 34.602-89 ni enostavno in zelo delovno intenzivno delo, ki nalaga resne obveznosti ne le razvijalcu, ampak tudi naročniku sistema.

Potencial standarda je izjemno velik in ni presenetljivo, da njegova priljubljenost že toliko let ostaja konstantno visoka.

• Sčasoma so se pokazale slabosti standarda: standard je osredotočen na povsem prilagojen razvoj sistema »iz nič« in ni namenjen implementacijiže pripravljena rešitev
• z uporabo standardne metodologije ali kombinacije razvoja in implementacij po meri; standard ponuja enega in edinega model življenjski cikel
• sistem, imenovan kaskada, ko je vse delo za ustvarjanje sistema linearno urejeno in je ta vrstni red vnaprej določen;

standard je preveč formalen. V praksi to vodi do pojava tehničnih specifikacij, ki v obliki izpolnjujejo zahteve GOST 34.602-89, vendar v bistvu nimajo vsebine. Treba je poudariti, da tako kot GOST 34.601-90 tudi GOST 34.602-89 ne zahteva posebnega usposabljanja na tem področju. informacijske tehnologije , torej lahko navaden vodja, katerega naloga vključuje na primer interakcijo s podizvajalci, spremlja skladnost s Tehničnimi specifikacijami. To poenostavi izvedbo in praktična uporaba

standard Referenčna naloga, ki ustreza zahtevam standarda. Pravzaprav je pojav GOST 34.602-89 spodbudil nastanek novih strokovnjakov - poslovnih analitikov in svetovalcev na področju informacijske tehnologije, katerih glavno delo je bil razvoj in usklajevanje tehničnih specifikacij s strankami avtomatiziranih sistemov.

GOST 34.201-89. Vrste, popolnost in poimenovanje dokumentov pri ustvarjanju avtomatiziranih sistemov.

1. Vrste in imena dokumentov

1.1. Sestava vrst dokumentov, razvitih na stopnji "Raziskave in utemeljitev za ustvarjanje AS", je določena v skladu z razdelkom. 3 GOST 24.601, ki temelji na zahtevanih rezultatih te stopnje.
1.2. Na stopnji "Referenčni pogoji" se razvije tehnična specifikacija (TOR) za ustvarjanje avtomatiziranega sistema v skladu z zahtevami GOST 34.602. Dovoljeno je razvijati zasebne tehnične specifikacije za ločeni sistemi: podsistemi - na primer avtomatiziran krmilni podsistem za robotsko linijo, s pomočjo katerega se proizvaja medicinsko pohištvo, medicinski vozički in oprema; kompleks proizvodnih nalog, npr. lokalni sistem nadzor kotla; sistemi programske in strojne opreme; komponente strojne in programske opreme itd.
1.3. Vrste dokumentov, razvite po stopnjah »Skica«, »Tehnična zasnova«, »Delovna dokumentacija« so navedeni spodaj:
1). Izjava - šifra dokumenta B. Navedba v sistematični obliki predmetov, stvari ipd.
2). Shema - šifra dokumenta C. Grafična podoba oblike dokumentov, delov, sistemskih elementov in povezav med njimi v obrazcu simboli.
3). Navodila - šifra dokumenta I. Izjava o sestavi ukrepov in pravilih za njihovo izvajanje s strani osebja.
4). Utemeljitev - šifra dokumenta B. Navedba podatkov, ki potrjujejo ustreznost sprejetih odločitev.
5). Opis - šifra dokumenta P. Razlaga namena sistema, njegovih delov, principov njihovega delovanja in pogojev uporabe.
6). Projektni dokument - po GOST 2.102.
7). Programski dokument je v skladu z GOST 19.101.

1.3.1. Ime posebnih dokumentov, ki se razvijajo pri načrtovanju sistema kot celote ali njegovega dela, so navedeni spodaj:
Izjava o idejnem projektu - šifra dokumenta EP*.
Pojasnilo za idejni projekt - šifra dokumenta P1.
Shema organizacijska struktura- šifra dokumenta CO.

Diagram funkcionalne strukture - šifra dokumenta C2*.
Seznam nalog za razvoj specializiranih (novo) tehnična sredstva- šifra dokumenta B9.
Shema avtomatizacije - šifra dokumenta C3*.
Tehnične specifikacije za razvoj specializiranih (novih) tehničnih sredstev niso vključene v projekt.
Naloge za razvoj gradbenih, električnih, sanitarnih in drugih delov projekta, povezanih z ustvarjanjem sistema, niso vključene v projekt.
Izjava o tehnični izvedbi - šifra dokumenta TP*.
Seznam nabavljenih artiklov - šifra dokumenta VP*.
Seznam vhodnih signalov in podatkov - oznaka dokumenta B1.
Seznam izhodnih signalov (dokumentov) - šifra dokumenta B2.
Seznam nalog za razvoj gradbenih, električnih, sanitarnih in drugih delov projekta, povezanih z ustvarjanjem sistema - šifra dokumenta B3.
Pojasnilo k tehnični projekt- šifra dokumenta P2.
Opis avtomatiziranih funkcij - šifra dokumenta P3.
Opis izjave o nalogah (sklop nalog) - šifra dokumenta P4.
Opis informacijske podpore sistema - šifra dokumenta P5.
Opis organizacije informacijske baze - šifra dokumenta P6.
Opis klasifikacijskih in šifrirnih sistemov - oznaka dokumenta P7.
Opis informacijskega polja - šifra dokumenta P8.
Opis kompleta tehničnih sredstev - oznaka dokumenta P9.
Opis programske opreme - šifra dokumenta PA.
Opis algoritma (postopka načrtovanja) - oznaka dokumenta PB.
Opis organizacijske strukture - šifra dokumenta PV.
Tlorisni načrt - šifra dokumenta C8.
Seznam opreme in materialov - ki pripadajo projektni in predračunski dokumentaciji.
Lokalni predračun - šifra dokumenta B2.
Projektna ocena zanesljivosti sistema - šifra dokumenta B1.
Risba obrazca dokumenta (video okvir) - šifra dokumenta C9.
Seznam imetnikov izvirnikov - šifra dokumenta DP*.
Seznam operativnih dokumentov - šifra dokumenta ED*.
Specifikacija opreme - šifra dokumenta B4.
Izjava o materialnih zahtevah – šifra dokumenta B5.
Seznam računalniških pomnilniških medijev - šifra dokumenta VM*.
Niz vhodnih podatkov - šifra dokumenta B6.
Katalog baze podatkov - oznaka dokumenta B7.
Sestava izhodnih podatkov (sporočil) - šifra dokumenta B8.
Lokalni predračun - šifra dokumenta B3.
Metodologija (tehnologija) računalniško podprtega načrtovanja - šifra dokumenta I1.
Tehnološka navodila - šifra dokumenta I2.
Navodila za uporabo - šifra dokumenta I3.
Navodilo za izdelavo in vzdrževanje baze (podatkovnega niza) - šifra dokumenta I4.
Navodila za uporabo KTS - oznaka dokumenta IE.
Shema povezav za zunanje ožičenje - koda dokumenta C4*.
Shema zunanje napeljave - šifra dokumenta C5*.
Tabela priključkov in povezav - šifra dokumenta C6*.
Diagram razdelitve sistema (strukturni) - šifra dokumenta E1*.
risanje splošni pogled- šifra dokumenta VO*.
Načrt vgradnje tehnične opreme - oznaka dokumenta CA.
Osnovni diagram - Šifra dokumenta SB.
Strukturni diagram kompleksa tehničnih sredstev - šifra dokumenta C1*.
Načrt razporeditve opreme in ožičenja - šifra dokumenta C7.
Opis tehnološki proces obdelava podatkov (vključno z daljinsko obdelavo) - šifra dokumenta PG.
Splošni opis sistema - Šifra dokumenta PD.
Program in metodologija testiranja (komponente, kompleksi opreme za avtomatizacijo, podsistemi, sistemi) - šifra dokumenta PM*.
Obrazec - šifra dokumenta FO*.
Potni list - šifra dokumenta PS*.

* Dokumenti, katerih koda je določena v skladu z zahtevami standardov ESKD.

V GOST so sprejete naslednje oznake:
EP - idejni projekt;
TP - tehnična zasnova;
RD - delovna dokumentacija;
ALI - sistemske rešitve;
OO - odločitve o organizacijski podpori;
TO - rešitve za tehnično podporo;
IO - rešitve za informacijsko podporo;
Programske rešitve programsko opremo;
MO - programske rešitve.
Znak X označuje, da spada v projektantsko ali obratovalno dokumentacijo.

Nomenklatura istoimenskih dokumentov je vzpostavljena glede na oblikovalske odločitve, sprejete med ustvarjanjem sistema.

1.3.2. Vrste dokumentov za programsko opremo, ki se uporablja za ustvarjanje AS (njenih delov) - po GOST 19.101.
1.3.3. Vrste dokumentov za tehnična sredstva, ki se uporabljajo pri ustvarjanju jedrske elektrarne (njenih delov) - po GOST 2.102 in po GOST 2.601 v smislu operativnih dokumentov.
1.3.4. Glede na uporabljene metode načrtovanja in posebnosti zvočnikov, ki se ustvarjajo, je dovoljeno naslednje:
1). pripravi skupinske in temeljne dokumente v skladu z oddelkom. 1, 3, 4, 6 GOST 2.113;
2). dokumente izdajati ločeno neodvisni deli, ki ustreza razdelkom glavnega dokumenta;
3). razširiti obseg dokumentov, ki jih določa ta standard.

1.4. Na stopnjah " Izdelava neserijskih komponent KSA« in »Zagon» pripravi naslednje organizacijske in upravne dokumente:
1). potrdilo o opravljenem delu;
2). potrdilo o sprejemu v poskusno obratovanje;
3). potrdilo o sprejemu za industrijsko delovanje;
4). urnik dela;
5). ukaz o sestavi komisije za sprejem;
6). delovni nalog;
7). program dela;
8). poročilo o preskusu;
9). sporazumni protokol.

2. Popolnost dokumentacije

2.1. Seznam imen dokumentov, ki se razvijajo, in njihova popolnost za sistem in njegove dele je treba določiti v tehničnih specifikacijah za ustvarjanje avtomatiziranega sistema (podsistema).

Opomba - popolnost projektne in ocenjevalne dokumentacije je določena v skladu s pravili nameščen s strani sistema projektna dokumentacija za gradnjo (SPDS).

2.2. Za vsak sklop je treba sestaviti seznam dokumentov.
2.3. Popolnost dokumentacije, ki zagotavlja razvoj, proizvodnjo, sprejem in namestitev tehnične opreme, je v skladu z GOST 2.102. Popolnost operativne dokumentacije za ta sredstva je v skladu z GOST 2.601.
2.4. Popolnost dokumentacije za računalniško programsko opremo je v skladu z GOST 19.101.
2.5. pri samostojni razvoj deli sistema so dokumenti zanj izpolnjeni v skladu z zahtevami tega standarda.

3. Oznake dokumentov

3.1. Vsakemu razvitemu dokumentu je treba dodeliti neodvisno oznako. Dokument, sestavljen na različnih nosilcih podatkov, mora imeti enako oznako. Oznaki dokumentov, izdelanih na računalniškem mediju, je dodana črka "M".
Izposojeni dokumenti ohranijo predhodno dodeljene oznake.
3.2. Ta pravila ne veljajo za dokumente, katerih pravila za označevanje urejajo državni standardi drugih dokumentacijskih sistemov.
3.3. Oznaka dokumenta ima določeno odobreno strukturo.
3.3.1. Pravila za označevanje sistema (dela sistema) so podana v Dodatku 2.
3.3.2. Koda dokumenta je sestavljena iz dveh alfanumeričnih znakov. Šifra dokumentov, ki jih določa ta standard, se vnese v skladu s stolpcem 3 tabele. 2. Šifra dodatnih dokumentov se oblikuje na naslednji način: prvi znak je črka, ki označuje vrsto dokumenta v skladu s tabelo. 1 je drugi znak številka ali črka, ki označuje zaporedno številko dokumenta te vrste. Šifra dokumenta je od prejšnje oznake ločena s piko.
3.3.3. Serijske številke dokumentov z enim imenom (2 znaka) se dodelijo od drugega in so ločene od prejšnje oznake s piko.
3.3.4. Številka revizije dokumenta se dodeli od druge v naraščajočem vrstnem redu od 2 do 9 in je od prejšnje vrednosti ločena s piko. Številka naslednje izdaje se dodeli v primerih, ko se prejšnja izdaja ohrani (ne prekliče).
3.3.5. Številka dela dokumenta je od prejšnje oznake ločena z vezajem. Če je dokument sestavljen iz enega dela, se vezaj ne vstavi in ​​številka dela dokumenta ni dodeljena.
3.3.6. Po potrebi se vpiše atribut dokumenta, ki se izvaja na računalniškem mediju. Črka "M" je od prejšnje oznake ločena s piko.

Dodatek 1. Razlaga izrazov, uporabljenih v tem standardu

Dokumentacija za avtomatiziran sistem je niz medsebojno povezanih dokumentov, ki v celoti opisujejo vse odločitve o ustvarjanju in delovanju sistema, pa tudi dokumente, ki potrjujejo skladnost sistema z zahtevami tehničnih specifikacij in njegovo pripravljenost za delovanje (delovanje).
Projektna in predračunska dokumentacija NEK je del dokumentacije NEK, izdelane za izvedbo gradnje in inštalacijska dela povezanih z nastankom AS.
Delovna dokumentacija za NEK je del dokumentacije za NEK, ki je potrebna za izdelavo, gradnjo, namestitev in zagon avtomatiziranega sistema kot celote, kot tudi programske in strojne opreme, programskih in metodoloških kompleksov ter komponent tehnične, programske in informacijska podpora vključena v sistem.

Danes bomo govorili o domačih standardih za projektna dokumentacija. Kako ti standardi delujejo v praksi, zakaj so slabi in zakaj dobri. Pri razvoju dokumentacije za državne in resne zasebne naročnike običajno nimamo izbire – skladnost s standardi je vključena v zahteve za dokumentiranje tehničnih specifikacij. V praksi sem se moral ukvarjati s različni primeri nerazumevanje strukture standardov, kaj bi moralo biti v dokumentih in zakaj so ti dokumenti potrebni. Posledica tega je, da peresa tehničnih piscev, analitikov in strokovnjakov včasih ustvarijo takšne dragulje, da ni jasno, v kakšnem stanju zavesti so bili napisani. Toda v resnici je vse precej preprosto. Iskanje na Habru ni vrnilo povezav do bolj ali manj popolnega gradiva na to temo, zato predlagam, da zapolnite to nadležno vrzel.

Kaj so dokumentacijski standardi?

V zadevnih 34 serijah obstajajo samo 3 glavni dokumentacijski standardi:

Najbolj priljubljen in priljubljen standard za razvoj tehničnih specifikacij. Edina stvar, ki je ne smete pozabiti, je, da je tesno povezan z drugimi standardi serije, in če ste prejeli tehnične specifikacije, izdelane v skladu s tem standardom, je zelo priporočljivo, da se držite drugih standardov, tudi če ni neposrednih zahtev za to. Vsaj glede splošne ideologije (o kateri spodaj)

To je osnovni dokument, ki zagotavlja celoten seznam Dokumentacija GOST 34, priporočila za kodiranje dokumentov, v katere faze projekta spadajo dokumenti (faze so opisane v GOST 34.601-90) in tudi, kako jih je mogoče kombinirati med seboj.

Pravzaprav je ta standard velika tabela s komentarji. Za lažjo uporabo ga lahko vstavite v Excel.

Obsežen standard, ki opisuje vsebino projektnih dokumentov z različnimi stopnjami podrobnosti. Kot indeks se uporablja zgoraj omenjeni GOST 34.201-89.

V zvezi s standardom RD 50-34.698-90 se pojavlja veliko vprašanj in interpretacij njegovih določil, ki jih zaradi svoje nedorečenosti pogosto različno razumejo naročnik in izvajalec ali celo člani projektne skupine. Ampak na žalost nimamo nič bolj konkretnega.

Zdaj pa razmislimo o prednostih in slabostih standardov, pri čemer običajno začnemo s slabostmi.

Slabosti standardov

Glavna pomanjkljivost je očitna vsem - standardi so stari. Vsebujejo zastarelo idejo o arhitekturi avtomatiziranega sistema. Na primer:

• dvonivojske aplikacije, sestavljene iz odjemalskega programa in strežnika DBMS (brez treh ali več "nivojskih" aplikacij, brez Weblogic ali JBoss)
• opisana struktura tabel baze podatkov bo dala predstavo o logičnem podatkovnem modelu (dejstvo, da bi med aplikacijo in bazo podatkov lahko obstajala nekakšna hibernacija, se je takrat zdelo kot hud presežek)
• uporabniški vmesnik je enookenski (je še kaj? Kaj je »brskalnik«?)
• V sistemu je malo poročil, vsa so papirnata in natisnjena na matričnem tiskalniku.
• Program, ki se razvija, je osredotočen na reševanje »problema obdelave informacij«, ki ima jasen vhod in izhod ter je visoko specializiran. Obdelava informacij temelji na "algoritmu". Včasih obstaja več "algoritmov". (Objektno orientirano programiranje je takrat šele delalo prve korake in ni bilo resno obravnavano).
• skrbnik baze podatkov razume, katere informacije so v tabelah in aktivno sodeluje pri urejanju sistemskih imenikov (ali res obstaja en strežnik DBMS za 50 različnih aplikacij?)

V skladu s tem ima standard artefakte, kot so naslednji:

5.8. Risba obrazca dokumenta (video okvir)
Dokument mora vsebovati sliko oblike dokumenta ali video okvira v skladu z zahtevami državnih standardov enotnega dokumentacijskega sistema R 50-77 in potrebna pojasnila.

Bistvo dokumenta je, da so sovjetska podjetja uporabljala tako imenovana »tiskarska območja«, kjer so bili hitri matrični tiskalniki, gonilnike za katere so pogosto napisali inženirji sami. Zato so morali vzdrževati register vseh dokumentov, ki jih je bilo treba natisniti, da so dokumenti izgledali tako, kot bi morali biti natisnjeni.

"Video okvir" je tudi dokument, ki je bil prikazan na besedilnem zaslonu. Zasloni niso vedno podpirali zahtevanih znakov in zahtevana količina znaki vodoravno in črte navpično (in grafika sploh ni bila podprta). Zato je bilo tudi tukaj potrebno dodatno uskladiti oblike vseh zaslonskih dokumentov.

Zdaj nam besede "machineogram", "video frame", "ADC" ne povedo več ničesar. Prav tako jih nisem našel v uporabi, čeprav sem v 90. letih diplomiral na specializiranem inštitutu. To je bil čas pojava Windows 3.1, VGA zaslonov, tripalčnih disket in prvih domačih internetnih strani. Toda te besede so v standardu in stranka včasih muhasto zahteva, da mu zagotovimo popoln komplet dokumentacija v skladu z GOST 34.201-89. Še več, takšne formulacije v projektnem nalogu se selijo z enega ministrstva na drugo in so že postale nekakšna neizrečena šablona, ​​v katero se zabija vsebina.

Torej dokument z neumnim imenom "Risba obrazca dokumenta (video okvir)" v projektu bi moral in ne bi smel biti prazen.

Kaj je dobro v standardu

Vsak standard je dober v tem, da omogoča stranki in izvajalcu, da govorita isti jezik in zagotavlja, da vsaj stranka ne bo imela nobenih pritožb »v obliki« na posredovane rezultate.

In tudi standardi GOST 34 so dobri, ker so bili sestavljeni pametni ljudje, preizkušajo že leta in imajo jasen cilj – na papirju čim bolj popolno opisati zapleteno abstraktno entiteto, ki jo predstavlja vsak avtomatiziran nadzorni sistem.

Ko morate kompetentno postaviti nalogo za zahodne izvajalce, ki še nikoli niso slišali za naše GOST-e, se lahko zanesete tudi na te standarde, oziroma na njihovo vsebino in semantično komponento. Ker ponavljam, jamstvo za popolnost informacij je veliko vredno. Ne glede na to, koliko se tolažimo visoki ravni naše strokovnosti, lahko pozabimo vključiti osnovne stvari v naše zahteve, medtem ko si isti GOST 34.602-89 "zapomni" vse. Če vam ni jasno, kakšen naj bi bil rezultat dela zahodnih izvajalcev, si oglejte zahteve za dokumentacijo in priporočene razdelke. Zagotavljam vam, da je bolje, da ne razmišljate o tem! Najverjetneje obstajajo zahodni analogi naših standardov, v katerih je lahko vse popolnejše, sodobnejše in boljše. Na žalost jih ne poznam, saj še ni bilo niti enega primera, ko naši standardi GOST niso zadostovali.

Lahko se smejite dejstvu, da ustvarjalci standardov niso vedeli ničesar o Javi ali .NET, o HD monitorjih in internetu, vendar ne bi svetoval podcenjevanja obsega dela, ki so ga opravili, in njegove vrednosti za našo strokovno javnost.

Kako brati in razumeti dokumentacijske standarde po GOST seriji 34

Standard deli vse dokumente po dveh oseh - časovni in predmetni. Če pogledate tabelo 2 v GOST 34.201-89, lahko jasno vidite to delitev (stolpca "Faza ustvarjanja" in "Del projekta"

Faze ustvarjanja avtomatiziranega nadzornega sistema

Faze ustvarjanja so opredeljene v GOST 34.601-90. Za dokumentacijo so pomembni trije:

• Osnutek načrta (ED)
• Tehnična zasnova (TP)
• Izdelava delovne dokumentacije (DD)

Osnutek zasnove sledi fazi Tehnične specifikacije in služi za razvoj idejnih projektantskih rešitev.

Tehnični projekt opisuje prihodnji sistem z vseh zornih kotov. Dokumenti v fazi TP morajo po branju pustiti za seboj popolno jasnost predlaganih pristopov, metod, arhitekturnih in tehničnih rešitev. V naslednji fazi bo za opis pristopov in utemeljitev prepozno tehnične rešitve, zato je faza P ključna za uspešno izvedbo dela, saj se mora vsa raznolikost zahtev tehničnih specifikacij odražati v dokumentih faze P. V fazi P sistem morda sploh ne obstaja.

Delovna dokumentacija zasnovan za uspešno namestitev, zagon in nadaljnje delovanje nov sistem. To so dokumenti, ki vsebujejo zelo specifične informacije, ki opisujejo fizično obstoječe entitete, v nasprotju s fazo P, ki opisuje bodoči sijaj.

Deli (oddelki) projektne dokumentacije za izdelavo avtomatiziranega nadzornega sistema

Predmetno področje je razdeljeno na »Določbe«. Sprva se zdi, da je takšna delitev odveč in nepotrebna. Toda ko začnete s tem kompletom orodij delati v praksi, postane ideologija, ki je v njem vgrajena, postopoma jasna.

Avtomatizirani sistem, kot so ga opredelili prevajalci GOST, je kombinacija strojne, programske in komunikacijskih kanalov, ki obdeluje informacije, ki prihajajo iz različnih virov v skladu z določenimi algoritmi, in proizvaja rezultate obdelave v obliki dokumentov, podatkovnih struktur ali nadzornih dejanj. Primitivni model najpreprostejše mitraljeze.

Da bi v celoti opisali ta "stroj", so narejeni naslednji deli (kot na risbi):

Programska oprema (MS), ki odgovarja na vprašanja: kakšna logika je vpeta v »črno skrinjico«? Zakaj so bili izbrani ti posebni algoritmi, te posebne formule in ti posebni koeficienti?

Matematična programska oprema ne ve ničesar o procesorjih ali bazah podatkov. To je ločeno abstraktno področje, bivališče "sferičnih konjev v vakuumu". Toda matematična programska oprema je lahko zelo tesno povezana s predmetnim področjem, oz Resnično življenje. Na primer, nadzorne algoritme za sisteme za nadzor prometa mora odobriti državni inšpektorat za varnost prometa, preden jih odobri stranka. In potem razumete, zakaj so vključeni v ločeno knjigo. Ker nikogar v prometni policiji ne zanima, na katerem OS bo deloval strežnik aplikacij, je pa zelo zanimivo, kakšen znak in omejitev hitrosti se bo pojavil na tabli v dežju ali snegu. Oni so odgovorni za svoj del in ne bodo podpisali ničesar drugega. Po drugi strani pa ob podpisu ne bo nobenih vprašanj o tehnični plati vprašanja - zakaj so izbrali te in ne druge table ali semaforje. Modrost "prednikov" se kaže prav v takih praktičnih primerih.

Informacijska podpora (IS). Še en del sistema. Tokrat je črna skrinjica našega sistema pregledna in opazujemo informacije, ki krožijo v njej. Predstavljajte si model človeškega krvožilnega sistema, ko so vsi drugi organi nevidni. Nekaj ​​takega je informacijska podpora. Opisuje sestavo in poti pretoka informacij znotraj in zunaj, logično organizacijo informacij v sistemu, opis referenčnih knjig in sistemov kodiranja (tisti, ki so delali programe za proizvodnjo, vedo, kako pomembni so). Glavni opisni del pade na stopnjo TP, nekateri "rudimenti" pa se pretakajo v stopnjo RD, kot je dokument "Katalog baze podatkov". Jasno je, da je prej vseboval točno to, kar piše v naslovu. Toda danes poskusite ustvariti tak dokument za zapleten kompleksen sistem, ko sistem zelo pogosto uporablja kupljene podsisteme z lastnimi skrivnostnimi shrambami informacij. Sploh ne trdim, da ta dokument zdaj ni posebej potreben.

Ali tukaj je "Izjava o pomnilniških medijih računalnika". Jasno je, da je prej vseboval številne magnetne bobne ali kolute filma. Kaj naj dam noter?

Skratka, v fazi RD so dokumenti informacijske podpore precej škodljiv rudiment, saj bi formalno morali obstajati, a jih ni s čim posebnim zapolniti.

Programska oprema. Vsem najljubši del projektne dokumentacije. Da, že zato, ker je samo en dokument! In potem vsi razumejo, kaj je tam treba zapisati. Ampak bom vseeno ponovil.

V tem dokumentu vam moramo povedati, s pomočjo katere programske opreme se izvajajo algoritmi, opisani v ML, ki obdelujejo informacije, opisane v IR. To pomeni, da tukaj ni treba podvajati informacij iz drugih razdelkov. Tu je podana arhitektura sistema, utemeljitev izbranih programskih tehnologij, njihov opis (vse vrste sistemskih stvari: programski jeziki, ogrodja, operacijski sistemi itd.). Tudi v tem dokumentu opisujemo, kako so organizirana orodja za obdelavo informacij (čakalne vrste sporočil, shranjevanje, orodja za varnostno kopiranje, rešitve razpoložljivosti, vse vrste aplikacijskih skupin itd.). Standard ima podroben opis vsebino tega dokumenta, ki jo bo razumel vsak strokovnjak.

Tehnična podpora (TO). Nič manj ljubljeni del projektne dokumentacije. Rožnato sliko zamegljuje le obilica dokumentov, ki jih je treba razviti. Standard zahteva skupno izdelavo 22 dokumentov, od tega 9 v fazi TC.

Dejstvo je, da standard zagotavlja opis vse tehnične podpore, vključno z računalniško strojno opremo in omrežji, inženirski sistemi in celo gradbeni del (če je potrebno). In to gospodarstvo ureja ogromno število standardov in predpisov, skladnih z različne organizacije in zato je bolj priročno vse razdeliti na dele in uskladiti (urediti) po delih. Hkrati pa standard omogoča kombiniranje nekaterih dokumentov med seboj, kar je smiselno, če ena oseba odobri celoten kup.

Ne pozabite tudi, da niz standardov kakovosti vključuje snemanje in shranjevanje tehnične dokumentacije, naše "knjige" od naročnika pa lahko razdelimo v različne arhive, odvisno od predmeta opisa. To je še en argument v prid razdrobljenosti dokumentacije.

Organizacijska podpora (OO). Ko sem zatrl željo, ki je običajna za tehničarja, da bi čim hitreje preskočil ta razdelek, nasprotno, ga bom podrobneje obravnaval. Ker, kolegi, v v zadnjem času Obstaja nekaj slabih trendov v projektih, ki zahtevajo pojasnilo v tem razdelku.

Na stopnji TP razdelek vsebuje samo en dokument " Opis organizacijske strukture«, v katerem moramo stranki povedati, na kaj naj se pripravi glede spremembe organizacijske strukture. Nenadoma se morate organizirati nov oddelek za upravljanje vašega sistema, uvajanje novih položajev itd.

Na stopnji RD se pojavijo drugi, bolj zanimivi dokumenti, ki bi jih rad obravnaval ločeno.

Uporabniški priročnik. Komentarji se mi zdijo nepotrebni.

Metodologija (tehnologija) računalniško podprtega načrtovanja. Po potrebi lahko v ta dokument vključite opis procesa izdelave programske opreme, nadzor različic, testiranje itd. Ampak to je, če stranka v tehnični specifikaciji želi osebno sestaviti programsko opremo. Če tega ne zahteva (in ne plača), potem je vse tvoje. notranja kuhinja To ni njegova stvar in tega dokumenta ni treba narediti.

Tehnološka navodila. Zaradi mode formalizacije poslovnih procesov včasih zvit kupec poskuša v ta dokument vtlačiti predpise o delovanju. Torej tega pod nobenim pogojem ne smete storiti.

Opis poslovnih procesov, vloga in opisi delovnih mest, delovni predpisi - vse to je ORD, to je organizacijska in upravna dokumentacija. Ki je produkt svetovalnega projekta, ki pa kolikor razumem ni bil kupljen od vas. In od vas so kupili tehnični projekt in tudi tehnično dokumentacijo zanj.

Tehnološka navodila so plast med navodili za uporabo in navodili za uporabo. RP podrobno opisuje kako v sistemu morate narediti določena dejanja. To pravi tehnološko navodilo ki dejanja je treba izvesti v določenih primerih, povezanih z delovanjem sistema. Grobo rečeno, tehnološko navodilo je kratek povzetek RP za določen položaj ali vlogo. Če stranka nima oblikovanih vlog ali želi, da vloge in delovne zahteve ustvarite sami, v dokument vključite najosnovnejše vloge, npr.: operater, višji operater, administrator. Komentarji strank na temo "a pri nas ni tako" ali "nam ni všeč" naj bodo opremljeni s seznamom vlog in opisom. delovne obveznosti. Ker poslovne procese mi ne damo. Mi smo ti poslovni procesi avtomatizirati.

O opisanih grabljah bom pisal posebej, s slikovitimi primeri, saj to ni prvič, da se to ponavlja v različnih panogah »narodnega gospodarstva«.

Opis tehnološkega procesa obdelave podatkov (vključno s teleprocesiranjem). Patetičen ostanek jamske dobe, ko so bili posebej imenovani »računalniški operaterji«, ki so v stroj podajali luknjane kartice in izpis rezultata zapakirali v ovojnico. To navodilo je za njih. Ne morem vam natančno povedati, kaj naj v 21. stoletju pišem vanj. Izstopite sami. Najbolje je, da kar pozabite na ta dokument.

Sistemske rešitve (WSO). Standard predvideva 17 dokumentov v razdelku OP. Prvič, to so skoraj vsi dokumenti predhodne faze shematskega načrta. Drugič, to so vse vrste ocen, izračunov in kratek opis avtomatizirane funkcije. Se pravi, informacije za ljudi, ki niso iz glavne IT proizvodnje, ampak za podporno osebje - menedžerje, cenilce, nabavnike, ekonomiste itd.

In tretjič, OP vključuje megadokument, imenovan »Pojasnilo za tehnični projekt«, ki naj bi bil nekakšen povzetek, v resnici pa mnogi projektanti vanj stlačijo vso uporabno vsebino faze TP. Tako radikalen pristop je lahko upravičen in celo obojestransko koristen tako za naročnika kot za izvajalca, vendar v določenih primerih.

Možnosti uporabe GOST 34

1. Popolno in natančno upoštevanje standarda. Takšnega oblaka dokumentov seveda nihče ne bo napisal prostovoljno. Zato se kompletna dokumentacija pripravi le na nujno zahtevo stranke, ki jo je zavaroval v tehničnih specifikacijah in tudi zatrdil z dogovorom na vrhu. V tem primeru morate vse jemati dobesedno in stranki dati fizične "knjige", na katerih bodo imena dokumentov iz tabele 2 GOST 34.201-89, z izjemo popolnoma nepotrebnih, katerih seznam boste mora pisno obravnavati in zagotoviti. Vsebina dokumentov mora tudi brez domišljije ustrezati RD 50-34.698-90, vse do imen razdelkov. Da bi kupcu včasih počili možgani velik sistem so razdeljeni na podsisteme, za vsak podsistem pa se izda posebna projektna dokumentacija. Videti je grozljivo in ni podvrženo običajnemu nadzoru s pomočjo zemeljskega uma. Predvsem glede integracije podsistemov. Kar zelo poenostavi sprejemanje. Glavna stvar je, da se sami ne zmedete in da vaš sistem še vedno deluje, kot mora.
2. Všeč so nam standardi GOST. Resna velika podjetja obožujejo standarde. Ker pomagajo ljudem bolje razumeti drug drugega. Če je vaša stranka znana po svoji ljubezni do reda in standardizacije, se pri pripravi dokumentov poskušajte držati standardne ideologije GOST, tudi če tega ne zahtevajo tehnične specifikacije. Odobritveni strokovnjaki vas bodo bolje razumeli in odobravali, sami pa jih ne boste pozabili vključiti v dokumentacijo pomembne informacije, boste bolje videli ciljno strukturo dokumentov, natančneje načrtovali delo pri njihovem pisanju ter sebi in svojim sodelavcem prihranili veliko živcev in denarja.
3. Ne zanima nas dokumentacija, če vse deluje. Izginjajoči videz neodgovornega kupca. Podoben pogled na dokumentacijo je še vedno pri malih in revnih kupcih, pa tudi v avtoritarnih »idiotokracijah«, ki so ostale iz časov perestrojke, kjer je šef obkrožen z zvestimi prijatelji – direktorji, vsa vprašanja pa se rešujejo v osebnih pogovorih. . V takšnih razmerah lahko dokumentacijo povsem zanemarite, vendar je kljub vsemu bolje, da pogleda ne podrete in dokumentacijo vsaj shematično zapolnite z vsebino. Če ne tej stranki, jo posredujte (prodajte) naslednji.

Zaključek

Ta članek je govoril o naših standardih GOST za dokumentiranje avtomatiziranih nadzornih sistemov. GOST-i so stari, a kot kaže, so še vedno zelo uporabni v gospodinjstvu. Poleg nekaterih očitnih zametkov ima struktura dokumentacije lastnosti popolnosti in konsistentnosti, spoštovanje standarda pa odpravi mnoga projektna tveganja, katerih obstoja se sprva sploh ne zavedamo.

Upam, da vam je bilo predstavljeno gradivo koristno ali vsaj zanimivo. Kljub navidezni dolgočasnosti je dokumentiranje pomembno in odgovorno delo, pri katerem je natančnost enako pomembna kot pisanje dobre kode. Pišite dobre dokumente, kolegi! In naslednji teden grem na dve zaporedni službeni poti, zato ne morem zagotoviti objave novih materialov (nimam predpomnilnika, pišem iz glave).