Standardi avtomatiziranih sistemov in informacijske tehnologije. Sprejemni testi ACS. Kaj so standardi dokumentacije

Danes bomo govorili o domačih standardih za projektno dokumentacijo. Kako ti standardi delujejo v praksi, zakaj so slabi in kaj dobri. Pri izdelavi dokumentacije za javne in resne zasebne naročnike običajno nimamo izbire – skladnost s standardi je zapisana v zahtevah za dokumentiranje tehničnih specifikacij. V praksi sem naletel na različne primere nerazumevanja strukture standardov, kaj mora biti v dokumentih in zakaj so ti dokumenti potrebni. Posledično včasih takšni dragulji izidejo izpod peresa tehničnih piscev, analitikov in strokovnjakov, 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 zapolnimo to nadležno vrzel.

Kakšni so standardi dokumentacije?

V zadevni seriji 34 obstajajo samo 3 glavni standardi dokumentiranja:

Najbolj priljubljen in priljubljen standard za razvoj tehničnih specifikacij. Edino, na kar ne smete pozabiti, je, da je tesno povezan z drugimi standardi v seriji, in če ste prejeli tehnično specifikacijo, izdelano po tem standardu, je zelo zaželeno, da se držite drugih standardov, tudi če jih ni. neposredne zahteve za to. Vsaj v smislu skupna ideologija(o tem spodaj)

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

Pravzaprav je ta standard velika označena tabela. Za lažjo uporabo ga je mogoče vnesti v Excel.

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

Postavlja se veliko vprašanj in interpretacij njegovih določil k standardu RD 50-34.698-90, ki jih zaradi svoje nejasnosti naročnik in izvajalec ali celo člani projektne ekipe pogosto različno razumejo. A žal nimamo nič bolj konkretnega.

Zdaj pa razmislimo o prednostih in slabostih standardov, začenši tradicionalno z minusi.

Slabosti standardov

Glavna pomanjkljivost je očitna vsem - standardi so stari. Vsebujejo zastarel koncept arhitekture avtomatiziranega sistema. Na primer:

• dvotirne aplikacije, sestavljene iz odjemalskega programa in strežnika DBMS (brez treh ali več "tier" aplikacij, brez Weblogic ali JBoss)
• struktura tabel baze podatkov, ki je opisana, bo dala predstavo o logičnem podatkovnem modelu (dejstvo, da je med aplikacijo in bazo podatkov morda nekaj mirovanja, potem se je zdelo slab presežek)
• uporabniški vmesnik je enookenski (ali je lahko drugačen? In kaj je "brskalnik"?)
• V sistemu ni veliko poročil, vsa so papirnata in so natisnjena na matričnem tiskalniku
• Razvit program je usmerjen v 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 usmerjeno programiranje je takrat delalo šele 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 standard vsebuje artefakte, kot so naslednji:

5.8. Risba obrazca dokumenta (video okvir)
Dokument mora vsebovati sliko obrazca dokumenta ali video okvirja v skladu z zahtevami državni standardi enotni dokumentacijski sistem R 50-77 in potrebna pojasnila.

Pomen dokumenta je, da so v sovjetskih podjetjih uporabljali tako imenovana "tiskarska območja", kjer so bili hitri matrični tiskalniki, za katere so gonilnike pogosto napisali inženirji sami. Zato so morali voditi register vseh dokumentov, ki jih je bilo treba natisniti, da bi zagotovili, da bodo dokumenti ob tiskanju videti tako, kot bi morali.

"Video okvir" je tudi dokument, ki je bil prikazan na besedilnem zaslonu. Zasloni niso vedno podpirali zahtevanih znakov in zahtevanega števila znakov vodoravno in navpično (in sploh niso podpirali grafike). Zato je bilo tudi tukaj potrebno dodatno uskladiti obrazce vseh zaslonskih dokumentov.

Zdaj nam besede "machine-gram", "video frame", "ADCP" ne povedo 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 zagotovi celoten sklop dokumentacije v skladu z GOST 34.201-89. Še več, podobne formulacije v TK tavajo od enega ministrstva do drugega in so že postale nekakšna neizrečena šablona, ​​v katero je zagnan vsebinski del.

Torej dokument z neumnim imenom "Risa obrazca dokumenta (videookvir)" v projektu mora in ne sme biti prazen.

Kaj je dobro v standardu

Vsak standard je dober s tem, da omogoča naročniku in izvajalcu, da govorita isti jezik in daje jamstvo, da vsaj glede oblike naročnik ne bo imel nobenih zahtevkov "v obliki" do posredovanih rezultatov.

In standardi GOST 34 so tudi dobri, ker so bili sestavljeni pametni ljudje, delujejo že leta in imajo jasen cilj – čim bolj popolno na papirju opisati kompleksno abstraktno entiteto, ki jo predstavlja katerikoli ACS.

Ko morate kompetentno postaviti nalogo zahodnim izvajalcem, ki še nikoli niso slišali za naše GOST, se lahko zanesete tudi na te standarde ali bolje rečeno na njihovo vsebino, semantično komponento. Ker je spet jamstvo za popolnost informacij veliko vredno. Ne glede na to, kako se razvajamo z visoko stopnjo svoje strokovnosti, lahko pozabimo vključiti osnovne stvari v svoje zahteve, medtem ko isti GOST 34.602-89 "spominja" vse. Če ne razumete, kako naj bi izgledal rezultat dela zahodnih izvajalcev, si oglejte zahteve za dokumentacijo, za priporočene razdelke. Zagotavljam vam, da je bolje, da si tega ne izmislite! Najverjetneje obstajajo zahodni analogi naših standardov, v katerih je vse lahko polnejše, modernejše in boljše. Žal jih ne poznam, saj še ni bilo niti enega primera, da naši GOST ne bi zadostovali.

Lahko se smejite, da ustvarjalci standardov niso vedeli ničesar o javi ali .NET-u, o HD monitorjih in internetu, vendar vam ne bi svetoval, da podcenjujete obseg njihovega dela in njegovo vrednost za našo strokovno skupnost.

Kako brati in razumeti standarde dokumentacije serije GOST 34

Standard deli vse dokumente po dveh oseh - časovno in predmetno področje. Če pogledate tabelo 2 v GOST 34.201-89, je ta razdelitev jasno vidna (stolpca "Faza ustvarjanja" in "Del projekta"

Faze ustvarjanja avtomatiziranega nadzornega sistema

Faze ustvarjanja so opredeljene v GOST 34.601-90. Trije od njih so pomembni za dokumentacijo:

• Osnutek načrta (EDS)
• Tehnična zasnova (TP)
• Izdelava delovne dokumentacije (RD)

Idejni projekt sledi fazi projektnega zadatka in služi za razvoj idejnih projektnih rešitev.

Tehnični projekt opisuje prihodnji sistem z vseh zornih kotov. Dokumenti faze TP naj po branju pustijo za seboj popolno jasnost predlaganih pristopov, metod, arhitekturnih in tehničnih rešitev. V naslednji fazi bo za opis in utemeljitev pristopov prepozno tehnične rešitve tako da je faza P ključna uspešna dostava deluje, saj bi se morala vsa raznolikost zahtev TK odražati v dokumentih faze P. Na stopnji P sistem morda sploh ne obstaja.

Delovna dokumentacija je zasnovan za uspešno uvajanje, zagon in nadaljnje delovanje novega sistema. To so dokumenti, ki vsebujejo zelo specifične informacije, ki opisujejo fizično obstoječe entitete, v nasprotju s fazo P, ki opisuje prihodnji sijaj.

Deli (oddelki) projektne dokumentacije za izdelavo avtomatiziranega nadzornega sistema

Predmetno področje je razdeljeno na "Določila". Sprva se zdi, da je takšna delitev odveč in nepotrebna. Toda ko začnete s tem orodjem delati v praksi, postopoma doseže ideologija, ki je v njej vgrajena.

Avtomatizirani sistem v mislih prevajalcev GOST je kombinacija strojne, programske in komunikacijskih kanalov, ki obdeluje informacije, ki prihajajo iz različnih virov v skladu z določenimi algoritmi in daje rezultate obdelave v obliki dokumentov, podatkovnih struktur ali nadzornih dejanj. Primitivni model najpreprostejšega avtomata.

Da bi v celoti opisali ta "avtomat", so bili narejeni naslednji rezi (kot na risbi):

Programska oprema (MO), ki odgovarja na vprašanja: kakšna je logika za »črno skrinjico«? Zakaj so bili izbrani ti algoritmi, točno takšne formule in ravno takšni koeficienti?

Programska oprema ne ve ničesar o procesorjih ali bazah podatkov. To je ločeno abstraktno območje, bivališče "sferičnih konj v vakuumu". Toda programska oprema je lahko zelo tesno povezana s predmetnim področjem, aka Resnično življenje... Na primer, krmilni algoritmi za krmilne sisteme cestnega prometa se je potrebno dogovoriti s prometno policijo, preden jih dogovori stranka. In potem razumete, zakaj so izpostavljeni v ločeni knjigi. Ker v prometni policiji nikogar ne zanima, na katerem operacijskem sistemu bo deloval aplikacijski strežnik, je pa zelo zanimivo, kakšen znak in omejitev hitrosti se bosta pojavila na semaforju v dežju ali snegu. Za svoje so odgovorni in ničesar drugega ne bodo podpisali. Po drugi strani pa ob podpisu ne bo nobenih vprašanj o tehnični plati vprašanja – zakaj so izbrali prav te, ne pa druge table ali semaforje. Modrost "prednikov" se natančno kaže v takšnih praktičnih primerih.

Informacijska podpora (IO)... Še en del sistema. Tokrat je črna skrinjica našega sistema pregledna in gledamo informacije, ki krožijo v njej. Predstavljajte si model človeškega krvnega obtoka, ko so vsi drugi organi nevidni. To je nekaj podobnega in obstaja informacijska podpora. Opisuje sestavo in poti prehoda informacij znotraj in zunaj, logično organizacijo informacij v sistemu, opis referenčnih knjig in kodirnih sistemov (kdor je izdelal programe za produkcijo, ve, kako pomembni so). Glavni opisni del sodi na stopnjo TP, vendar se nekateri "rudimenti" pretakajo v stopnjo RD, kot je dokument "Katalog baz podatkov". Jasno je, da je prej vseboval točno to, kar piše v naslovu. Toda danes poskusite oblikovati tak dokument za zapleten kompleksen sistem, ko se kot del sistema zelo pogosto uporabljajo kupljeni podsistemi s svojimi skrivnostnimi shrambami informacij. Sploh ne govorim o tem, da ta dokument zdaj ni posebej potreben.

Ali pa tukaj je "Izjava o medijih z informacijami o stroju". Jasno je, da je nekoč vseboval število magnetnih bobnov ali kolutov filma. In kaj zdaj prinesti tja?

Skratka, v fazi RD so dokumenti informacijske podpore precej poguben rudiment, saj bi formalno morali biti, vendar jih ni nič posebnega zapolniti.

Programska oprema (programska oprema)... Vsem najljubši del projektne dokumentacije. Da, če le zato, ker je to samo en dokument! In potem vsi razumejo, kaj je treba tam zabeležiti. Ampak vseeno bom ponovil.

V tem dokumentu moramo povedati, s katero programsko opremo se izvajajo algoritmi, opisani v IO, ki obdelujejo informacije, opisane v IO. To pomeni, da tukaj ni treba podvajati informacij iz drugih razdelkov. Poda arhitekturo 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, shrambe, orodja za varnostno kopiranje, rešitve za razpoložljivost, vse vrste aplikacijskih področij itd.). Standard ima natančen opis vsebino tega dokumenta, ki jo razume vsak strokovnjak.

Tehnična podpora (TO)... Nič manj priljubljen pri vseh, del projektne dokumentacije. Svetlo sliko zatemni le obilica dokumentov, ki jih je treba razviti. Skupno je v skladu s standardom potrebno razviti 22 dokumentov, od tega 9 v fazi TP.

Dejstvo je, da standard predvideva opis vse tehnične podpore, vključno z računalniško strojno opremo in omrežji, inženirskimi sistemi in celo konstrukcijskim delom (če je potrebno). In to gospodarstvo ureja ogromno standardov in predpisov, usklajeno je v različnih organizacijah in zato je bolj priročno vse razdeliti na dele in uskladiti (urediti) po delih. Hkrati standard omogoča združevanje nekaterih dokumentov med seboj, kar je smiselno, če se za celoten kup dogovori ena oseba.

Ne pozabite tudi, da nabor standardov kakovosti vključuje obračunavanje in hrambo tehnične dokumentacije, naše "knjige" pri stranki pa so lahko razpršene v različnih arhivih, odvisno od predmeta opisa. To je še en argument v prid razdrobljenosti dokumentacije.

Organizacijska podpora (OO)... Ko sem zatrel željo, normalno za tehniko, da čim prej preskoči ta odsek, nasprotno, ga bom podrobneje obravnaval. Kolegi, saj so se v zadnjih letih začrtali slabi trendi pri projektih, ki zahtevajo pojasnitev v tem posebnem razdelku.

Na stopnji TP razdelek vsebuje samo en dokument " Opis organizacijske strukture«, v katerem moramo stranki povedati, na kaj naj se pripravi v smislu spremembe organizacijske strukture. Nenadoma morate organizirati nov oddelek za upravljanje vašega sistema, uvesti nova delovna mesta itd.

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

Navodila... Komentarji so po mojem mnenju odveč.

Metodologija (tehnologija) računalniško podprtega oblikovanja... V ta dokument lahko po potrebi vnesete opis postopka gradnje programske opreme, nadzora različic, testiranja itd. Toda to je, če želi stranka v TK osebno sestaviti programsko opremo. Če tega ne zahteva (in tega ne plača), potem vsa vaša notranja kuhinja ni njegova stvar in tega dokumenta ni treba narediti.

Tehnološka navodila... Zaradi mode formaliziranja poslovnih procesov zvit kupec včasih poskuša v ta dokument strniti operativne postopke. Torej, to nikakor ni potrebno.

Opis poslovnih procesov, vloga in opisi delovnih mest, predpisi o delu - vse to je ORD, torej organizacijska in administrativna dokumentacija. Kar je produkt svetovalnega projekta, ki ga, kolikor razumem, ni kupil pri vas. In od vas so kupili tehnični projekt in tudi tehnično dokumentacijo zanj.

Tehnološko navodilo je vmesni sloj med ORD in uporabniškim priročnikom. RP podrobno opisuje kako morate izvesti določena dejanja v sistemu. Tehnološko navodilo pravi katera vrsta dejanja morajo biti izvedena 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 definiranih vlog ali želi, da vloge in zahteve za delovna mesta določite sami, v dokument vključite najosnovnejše vloge, na primer: operater, višji operater, skrbnik. Komentarjem stranke na temo, "vendar nam ni všeč" ali "vendar nam ni všeč", naj bo priložen seznam vlog in opis službene obveznosti... Ker poslovni procesi mi ne daj... Mi smo ti poslovni procesi avtomatizirati.

O opisanem raku bom pisal ločeno, s pisanimi primeri, saj se v različnih sektorjih »narodnega gospodarstva« ne ponavlja prvič.

Opis tehnološkega procesa obdelave podatkov (vključno z daljinsko obdelavo)... Škodljiv ostanek jamske dobe, ko so bili posebej določeni »računalniški operaterji«, ki so napajali stroj z luknjanimi karticami in pakirali izpis rezultata v ovojnico. To navodilo je zanje. Kaj napisati vanj v XXI stoletju - ne morem vam zagotovo povedati. Odvijte se. Najbolje je, da pozabite na ta dokument.

Sistemske rešitve (ALI)... Standard predvideva 17 dokumentov oddelka OP. Prvič, to so skoraj vsi dokumenti iz faze idejnega projekta. 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 pomožno osebje - vodje, ocene stroškov, strokovnjake za nabavo, ekonomiste itd.

In tretjič, OR vključuje mega-dokument, imenovan "Pojasnilo k tehničnemu projektu", ki je po zamisli nekakšen povzetek, v resnici pa številni oblikovalci vanj porinejo vso uporabno vsebino faze TP. . Tako radikalen pristop je včasih upravičen in celo obojestransko koristen tako za naročnika kot za izvajalca, a v določenih primerih.

Različice uporabe GOST 34

1. Popolno in natančno upoštevanje standarda... Seveda nihče ne bo prostovoljno napisal takšnega oblaka dokumentov. Zato se celoten komplet dokumentov pripravlja le na vztrajno željo stranke, ki jo je zavaroval v TK in jo z dogovorom zdrobil od zgoraj. V tem primeru morate vse razumeti dobesedno in stranki dati fizične "knjige", na katerih se bodo pojavila imena dokumentov iz tabele 2 GOST 34.201-89, z izjemo popolnoma nepotrebnih, katerih seznam morate zagotovo razpravljati in pisno popraviti. Vsebina dokumentov mora tudi brez domišljije ustrezati RD 50-34.698-90, vse do naslovov razdelkov. Da bi kupčevi možgani eksplodirali, včasih velik sistem razdelimo na podsisteme, za vsak podsistem pa se izda ločena projektna dokumentacija. Izgleda zastrašujoče in ni predmet normalnega nadzora s pomočjo zemeljskega uma. Predvsem v smislu integracije podsistema. To močno poenostavi sprejem. Glavna stvar je, da se sami ne zmedete in da vaš sistem še vedno deluje, kot bi moral.
2. Obožujemo GOST... Resno velika podjetja ljubezenski standardi. Ker pomagajo ljudem bolje razumeti drug drugega. Če je vaša stranka opažena v ljubezni do reda in standardizacije, se pri razvoju dokumentov poskušajte držati standardne ideologije GOST, tudi če tega ne zahteva tehnična specifikacija. Koordinacijski strokovnjaki vas bodo bolje razumeli in odobrili, sami pa ne boste pozabili vključiti v dokumentacijo pomembna informacija, 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. Dokumentacija nas ne zanima, dokler vse deluje.... Izginjajoča vrsta neodgovorne stranke. Podoben pogled na dokumentacijo še vedno najdemo med malimi in revnimi strankami, pa tudi v avtoritarnih "idiotokracijah", ki so ostale iz perestrojke, kjer je šef obkrožen z zvestimi prijatelji - direktorji, vsa vprašanja pa rešujejo v osebnih pogovorih. V takih razmerah lahko pozabite na dokumentacijo na splošno, vendar je vseeno bolje, da ne podrete pogleda in dokumentacijo vsaj shematično napolnite z vsebino. Če ne tej stranki, potem prenesite (prodaj) na naslednjo.

Zaključek

Ta članek je bil o naših standardih GOST za dokumentiranje ACS. GOST-ji so stari, a kot se je izkazalo, so še vedno zelo uporabni v gospodinjstvu. Poleg nekaterih očitnih začetkov ima struktura dokumentacije lastnosti popolnosti in doslednosti, spoštovanje standarda pa odpravlja številna projektna tveganja, o katerih obstoja sprva morda ne ugibamo.

Upam, da vam je bilo predstavljeno gradivo koristno ali vsaj zanimivo. Kljub zunanjemu dolgčasu je dokumentiranje pomembno in odgovorno delo, kjer je natančnost prav tako pomembna kot pisanje dobre kode. piši dobri dokumenti, kolegi! In sem na naslednji teden Grem na dve službeni poti zapored, tako da ne morem jamčiti za objavo novih materialov (trgovine nimam, pišem iz glave).

M. Ostrogorskega, 2008

Za uspešno uporabo GOST 34 je treba razumeti, kako je z vidika tega niza standardov urejen avtomatiziran sistem. Sicer v gostih ne bomo videli ničesar razen dolgega seznama dokumentov s skrivnostnimi imeni, zahteve po njihovi vsebini pa nas bodo znova prepričale, da je v marsikateri modrosti veliko žalosti. Zato moramo pred razpravo o samih dokumentih razumeti, kaj je predmet dokumentacije.

Avtomatiziran sistem, njegove funkcije in naloge

Opredelitev avtomatiziranega sistema

GOST 34.003-90 vsebuje naslednjo definicijo avtomatiziranega sistema: sistem, sestavljen iz osebja in niza sredstev za avtomatizacijo njihovih dejavnosti, ki izvaja informacijsko tehnologijo za opravljanje uveljavljenih funkcij. Kaj ta definicija pomeni v praksi? To lahko razumete le tako, da preberete druge definicije tega standarda in jih primerjate med seboj. Kaj bomo zdaj počeli.

Cilji dejavnosti

Avtomatiziran sistem lahko obstaja le tam, kjer je osebje, ki se ukvarja z določeno dejavnostjo. Praviloma govorimo o dejavnostih, katerih rezultati so nekomu koristni, ne glede na uporabljena orodja. Na blagajno se na primer prijavim za vstopnico in prav bi mi bilo, če bi mi jo blagajničarka izpisala s pisalom na pisemski glavi, da bi me z njo spustili v dvorano. Blagajni na splošno tudi ni mar, kako narediti vstopnico. Vsaka metoda bi ji ustrezala, če le ne bi bila preveč naporna in bi ji dala možnost, da mi proda vstopnico. Z drugimi besedami, z njo imamo skupen cilj. V GOST 34.003-90 se izraz uporablja za njegovo označevanje namen dejavnosti... Kadar koli drug gledalec z vstopnico v roki odide od okna in gledališče postane malo bogatejše, je ta cilj dejavnosti dosežen.

Avtomatizirane sistemske funkcije

Ciljev dejavnosti je lahko (in praviloma obstaja) več. Vsak rezultat, ki je uporaben zunaj dejavnosti same, se lahko šteje za njen cilj. Torej, če blagajnik ne samo proda vstopnico, ampak ob koncu delovnega dne sestavi prodajno poročilo za šefe, se lahko sestava dnevnega poročila šteje za še en cilj dejavnosti.

Če blagajničarki postavimo na mizo računalnik in tiskalnik, vodja blagajne pa ji izda ukaz, naj v urejevalnik besedil vtipka liste in poročila ter jih natisne na tiskalnik, potem dobimo avtomatiziran sistem. Po sodobnih zamislih je zelo primitiven, formalno bo ustrezal definiciji gosta. Upoštevajte, da se cilji aktivnosti zaradi uvedbe avtomatiziranega sistema niso spremenili, spremenil se je le način njihovega doseganja. Kar se je nekoč delalo »kar tako«, se zdaj dela v okviru avtomatiziranega sistema. Nabor dejanj avtomatiziranega sistema, namenjenega doseganju določenega cilja, se po GOST 34.003-90 imenuje funkcijo... Opomba: karkoli si mislite o tem, osebje velja za del sistema.

Funkcija avtomatiziranega sistema je temeljni koncept v GOST 34. Avtomatizirani sistem se najprej obravnava kot vsota njegovih funkcij in šele nato kot kup "programske in strojne opreme". Najpomembneje je, kaj sistem počne in iz česa je sestavljen, je sekundarno.

Navedeno bi bralca lahko pripeljalo do zaključka, da vsakemu cilju dejavnosti v avtomatiziranem sistemu ustreza ena in samo ena funkcija. Tak sistem si je enostavno predstavljati, vendar je praksa bolj pestra. Po eni strani dejavnosti niso vedno popolnoma avtomatizirane. Tudi po uvedbi avtomatiziranega sistema je treba nekatere cilje doseči ročno. Po drugi strani pa zato, ker je pod različnimi pogoji mogoče doseči enak rezultat različne poti, lahko več funkcij usmerimo v en cilj dejavnosti v avtomatiziranem sistemu, na primer prodaja vstopnice na blagajni in prodaja vstopnice na internetu. Poleg tega vsak avtomatiziran sistem zahteva določeno vzdrževanje, zato je treba uvesti koncept pomožne funkcije. Tipičen primer je varnostno kopiranje podatkov.

Naloge avtomatiziranega sistema

V splošnem primeru pri opravljanju funkcije del dela opravi osebje, del dela pa oprema, na primer vstopnica se samodejno natisne, blagajničarji pa jo izdajo kupcu ročno. Zaporedje samodejnih (sic) dejanj, ki vodijo do rezultata določene vrste, se imenuje v GOST 34.003-90 nalogo.

Tukaj definicija problema ni povsem natančno navedena, a za zdaj nam bo dovolj in to na koncu ni sramotno, da bi kdo sam prebral standard. Pomembno je, da je naloga najbolj jasno formaliziran del avtomatizirane dejavnosti. Lahko si predstavljamo funkcijo, ki se izvaja popolnoma samodejno, kot je že omenjeno varnostno kopiranje. V tem primeru se funkcija zmanjša na eno nalogo.

Enako nalogo je mogoče rešiti z izvajanjem različnih funkcij. Na primer, če ima avtomatiziran sistem več funkcij za prodajo vozovnice, potem lahko za izvedbo vsake od njih v nekem trenutku zahteva izpis vstopnice.

Sestava avtomatiziranega sistema

Podsistemi

Če je avtomatiziran sistem dovolj zapleten, ga razdelimo na podsistemi... Kaj to pomeni, dovolj težko, dovolj težko reči. Teorija sistemov opisuje različne ravni in kriterije kompleksnosti. V praksi je potreba po ločevanju več podsistemov v avtomatiziranem sistemu pogosto posledica organizacijskih in finančnih razlogov, na primer, podsistemi se razvijajo in začnejo delovati zaporedno.

Čeprav se v GOST 34 izraz podsistem uporablja večkrat, se zdi, da ta koncept ni uradne opredelitve. Izkušnje narekujejo, da je podsistem del avtomatiziranega sistema, ki prav tako ustreza definiciji avtomatiziranega sistema, zlasti ima polnopravne funkcije.

Če se vrnemo k primeru prodaje vstopnic, se lahko odločimo, da je avtomatizirani sistem sestavljen iz dveh podsistemov: podsistema prodaje vstopnic in podsistema za generiranje dnevnih poročil. Za večjo jasnost se strinjamo, da blagajnik vnese liste v urejevalnik besedil in poroča v preglednicah.

Komponente

Razporeditev ciljev dejavnosti, funkcij avtomatiziranega sistema in po potrebi njegovih podsistemov je v veliki meri subjektivna in je odvisna od stališča subjekta, ki se je za to odločil. Če je kakšen rezultat pomemben v kontekstu reševanja problema, ga lahko štejemo za cilj, sicer pa ga zanemarimo. Avtomatizirani sistem bomo tudi razbili na podsisteme, kot je za nas primerno, če naše odločitve ne bodo v nasprotju z vsebino tega koncepta.

Komponente so deli, iz katerih gradimo avtomatiziran sistem v objektivni realnosti. Sistem je fizično sestavljen iz svojih komponent, zato je delitev avtomatiziranega sistema na komponente najbolj objektivna.

Vsako komponento kupimo, montiramo in povežemo (če je oprema), namestimo (če gre za program) in servisiramo ločeno od ostalih komponent. Kupili smo in postavili računalnik na mizo - to je komponenta. Za nabor vstopnic smo razvili poseben urejevalnik besedil - drugo komponento. Prenesene brezplačne preglednice z interneta - spet komponenta. In tudi blagajna sama je na nek način tudi sestavni del avtomatiziranega sistema.

Komponentna sestava avtomatiziranega sistema je zelo pomembna z vidika njegove dokumentacije, saj se tehnična dokumentacija sistema kot takega in sestavnih delov obravnava različno. Na splošno ga je treba razviti različni ljudje, in je zasnovan v skladu z različnimi standardi, odvisno od vrste komponente.

Vrste zavarovanja

Eden najtežjih konceptov za začetnika GOST 34 je vrsta varnosti... Kakšna varnost je to? Ali ga lahko vidite ali se dotaknete? Prodati ali kupiti?

Vsaka vrsta podpore združuje komponente ali tehnične rešitve specifične narave. GOST 34 omenja veliko različni tipi določbe, tukaj ne bomo dosledno opisovali vsakega od njih, ampak bomo našteli le najbolj opazne:

• informacijska podpora - vsi podatki in metapodatki, s katerimi sistem deluje;
• programska oprema - vsi programi, ki so del sistema;
• tehnična podpora - vsa tehnična sredstva (z drugimi besedami, oprema, aparati), ki so del sistema.

Še enkrat ponavljamo, to niso vse vrste zavarovanj. Ne moremo niti z gotovostjo trditi, da so najpomembnejši. Na primer za avtomatizirane sisteme za nadzor procesov (APCS) dobra vrednost ima meroslovno podporo. Številni avtomatizirani sistemi zahtevajo kompleksno matematično in jezikovno podporo. Težko pa si je predstavljati avtomatiziran sistem, ki bi bil popolnoma brez ene od treh zgoraj naštetih vrst podpore (vaja: poskusi).

Uvod

V sodobnem svetu se vsak dan pojavlja na desetine in stotine različnih programov, aplikacij, informacijskih sistemov. Lahko so zasnovani tako za javni ali komercialni sektor kot tudi za splošne uporabnike. 90 % vseh uporabnikov ne bere dokumentacije, meni, da je dolgočasna, dolgočasna in nezanimiva, in odpre uporabniški priročnik le, ko kaj ne gre ali je popolnoma nemogoče razbrati brez navodil. Zdaj je splošno sprejeto, da se uporabniški vmesnik zgradi tako, da je intuitiven in da lahko uporabnik ugotovi sistem, ne da bi mu bilo treba brati dolge priročnike. Vendar pa je pri delu z velikimi strankami skoraj vedno treba predložiti določen paket dokumentov - priročnike, navodila, oblikovalske rešitve, izdelane v skladu z GOST.
Ko prvič naletite na pisanje dokumentacije v skladu z GOST, pridete do stuporja in popolnega šoka, saj so ti GOST "morji" in kako in kaj o njih pisati, postane nejasno.
Ta članek obravnava GOST za pisanje dokumentacije in njihove glavne točke.

Kaj so GOST?

Najprej morate ugotoviti, kaj so GOST. Vsi vedo, da je GOST nekaj, kar je bilo razvito v okviru Unije in jih je preprosto neskončno število. Pohitim, da vas pomirim, da za IT sektor ni toliko standardov GOST in vsi kljub času nastanka niso izgubili pomembnosti.
Najprej so standardi za pisanje dokumentacije razdeljeni na dve vrsti:

1. mednarodni standardi (ISO, IEEE Std);
2. Ruski ali sovjetski GOST.

mednarodni standardi
Za razvoj dokumentacije na mednarodni ravni se uporabljajo mednarodni standardi. Praviloma niso brezplačni, saj jih ne razvijajo vladne organizacije, za razliko od naših pa so jih razvili pred kratkim. Tema mednarodnih standardih zelo široka, zato bo obravnavana v drugem članku. Takoj se dotaknemo več standardov, ki so tesno povezani s pisanjem dokumentacije.
Seznam glavnih mednarodnih standardov za pisanje dokumentacije:

1. IEEE Std 1063-2001 "IEEE Standard for Software User Documentation" - standard za pisanje uporabniškega priročnika;
2. IEEE Std 1016-1998 "IEEE Recommended Practice for Software Design Descriptions" - standard za pisanje tehničnega opisa programa;
3. ISO / IEC FDIS 18019: 2004, "Smernice za načrtovanje in pripravo uporabniške dokumentacije za aplikacijsko programsko opremo" je še en standard za pisanje uporabniških priročnikov. Ta dokument ima veliko število primeri. Se pravi, da je videti bolj kot priročnik za pisanje uporabniškega priročnika. Začetniki bodo še posebej koristni;
4. ISO / IEC 26514: 2008, Zahteve za oblikovalce in razvijalce uporabniške dokumentacije, je še en standard za oblikovalce in razvijalce uporabniške dokumentacije.

Pravzaprav obstaja veliko mednarodnih standardov in so v vsaki državi različni, saj isti standard morda ni vedno primeren tako za evropska kot azijska podjetja.

ruski standardi
Ruski standardi so razviti na državni ravni. Vsi so popolnoma brezplačni in vse jih je enostavno najti na internetu. Za pisanje dokumentacije za program se uporabljata dve seriji GOST-ov 19 in 34. O njih bomo še razpravljali.

Kakšna je razlika med GOST-i serije 19 in 34?

Prvo vprašanje, ki se pojavi, je, kako se na splošno ta GOST 19 in 34 razlikujeta drug od drugega.
V GOST 19.781-90 "Enoten sistem programske dokumentacije. Programska oprema sistemov za obdelavo informacij. Izrazi in definicije "definicije so navedene:

1. Program - podatki, namenjeni nadzoru posebnih komponent sistema za obdelavo informacij z namenom izvajanja določenega algoritma.
2. Programska oprema - niz programov sistema za obdelavo informacij in programskih dokumentov, potrebnih za delovanje teh programov.

V GOST 34.003-90 "Informacijska tehnologija. Nabor standardov za avtomatizirane sisteme. Avtomatizirani sistemi. Izrazi in definicije "definicija je navedena:

1. Avtomatski sistem (AS) je sistem, sestavljen iz osebja in niza sredstev za avtomatizacijo njihovih dejavnosti, ki izvaja informacijsko tehnologijo za opravljanje uveljavljenih funkcij.
   Glede na vrsto dejavnosti se na primer razlikujejo naslednje vrste avtomatiziranih sistemov: avtomatizirani krmilni sistemi (ACS), sistemi za računalniško podprto načrtovanje (CAD), avtomatizirani sistemi znanstvena raziskava(ASNI) in drugi.

Glede na vrsto nadzorovanega objekta (procesa) se ACS deli na primer na: ACS po tehnoloških procesih (ACS), ACS po podjetjih (ACS) itd.
Tudi GOST 34 deli na vrste podpore za jedrske elektrarne:

1. organizacijski;
2. Metodična;
3. tehnična;
4. matematični;
5. Programska oprema;
6. informativni;
7. jezikoslovni;
8. pravni;
9. Ergonomsko

Posledično avtomatizirani sistem ni program, ampak niz vrst podpore, vključno s programsko opremo. AS praviloma nosi organizacijsko rešitev za določenega uporabnika in kupca, program pa je mogoče izdelati in replicirati za veliko število uporabnikov, ne da bi bil vezan na nobeno podjetje.
Če torej razvijate dokumentacijo za program, ki ste ga ustvarili za določeno podjetje, potem vaš GOST 34. Če pišete dokumente za množični program, potem vaš GOST 19.

GOST 34

Serija GOST 34 (GOST 34.xxx standardi informacijske tehnologije) je sestavljena iz:

1. GOST 34.201-89 Vrste, popolnost in oznake dokumentov pri ustvarjanju avtomatiziranih sistemov - ta standard določa vrste, ime, popolnost in število dokumentov. Je eden glavnih dokumentov v seriji GOST 34. Pravzaprav je to osnovni dokument, zato naj se začetniki najprej seznanijo z njim.
2. GOST 34.320-96 Koncepti in terminologija za konceptualni diagram in informacijsko bazo- ta standard določa osnovne pojme in pojme idejnih shem in informacijskih baz, ki zajemajo razvoj, opis in uporabo idejnih shem in informacijskih baz, manipulacijo z informacijami ter opis in izvajanje informacijskega procesa. Standard opredeljuje vlogo konceptualne sheme. Določbe, opisane v njem, so svetovalne narave in se lahko uporabljajo za oceno sistemov za upravljanje baz podatkov (DBMS). Ta dokument ne opisuje posebnih metod za uporabo podpornih orodij za konceptualno shemo. Jeziki konceptualnih shem, opisani v standardu, se ne smejo šteti za standardne.
3. GOST 34.321-96 Informacijska tehnologija. Sistem standardov baz podatkov. Referenčni model upravljanja – ta dokument vzpostavlja referenčni model za upravljanje podatkov.
   Referenčni model opredeljuje splošno terminologijo in koncepte, povezane s podatki informacijskih sistemov. Takšni koncepti se uporabljajo za opredelitev storitev, ki jih zagotavljajo sistemi za upravljanje baz podatkov ali sistemi podatkovnih slovarjev.
   Referenčni model ne upošteva protokolov za upravljanje podatkov.
   Obseg referenčnega modela vključuje procese, ki se nanašajo na upravljanje trajnih podatkov in njihovo interakcijo s procesi, ki se razlikujejo od zahtev določenega informacijski sistem kot tudi splošne storitve upravljanja podatkov za definiranje, shranjevanje, iskanje, posodabljanje, vnašanje, kopiranje, obnavljanje in prenos podatkov.
4. GOST 34.601-90 Avtomatski sistemi. Faze ustvarjanja – standard določa faze in faze ustvarjanja AU.
5. GOST 34.602-89 Pooblastila za ustvarjanje avtomatiziranega sistema (namesto GOST 24.201-85) - določa sestavo, vsebino, pravila za sestavo dokumenta "Referenčni pogoji za ustvarjanje (razvoj ali posodobitev) sistema ."
   Ta dokument je eden najpogosteje uporabljenih dokumentov serije GOST 34. Pri razvoju TK po tem GOST se je treba spomniti na druge standarde, tudi če ta dokument ne vsebuje sklicevanj na te standarde.
6. GOST 34.603-92 Informacijska tehnologija. Vrste testov avtomatiziranih sistemov - standard določa vrste testov AU (avtonomni, integrirani, prevzemni testi in poskusno delovanje) in splošne zahteve za njihovo izvajanje.
7. RD 50-34.698-90 Avtomatizirani sistemi. Zahteve po vsebini dokumentov je eden najpomembnejših dokumentov 34 GOST, saj je v njem opisana vsebina skoraj vseh dokumentov, pa tudi opis vsakega odstavka dokumenta.
8. GOST R ISO / IEC 8824-3-2002 Informacijska tehnologija. Zapis abstraktne sintakse, različica ena — ta mednarodni standard je del abstraktne sintaksne oznake 1 (ASN.1) in zagotavlja zapis za določanje uporabniško definiranih omejitev in omejitev tabele.
9. GOST R ISO / IEC 10746-3-2001 Upravljanje podatkov in odprta porazdeljena obdelava.
   V tem standardu:
   • določi se, kako so določeni sistemi odprte porazdeljene obdelave (ODP) z uporabo konceptov, uvedenih v GOST R ISO / IEC 10746-2;
   • opredeljene so značilnosti, po katerih so sistemi razvrščeni kot sistemi ODP.

   Standard vzpostavlja okvir za usklajevanje razvoja standardov za sisteme ODP.

10. GOST R ISO / IEC 15271-02 Procesi življenjskega cikla programske opreme - ta GOST je po mojem mnenju bolj potreben za analitike pri načrtovanju in modeliranju jedrskih elektrarn.
    Ta dokument je z mojega vidika uporaben izključno v izobraževalne namene.
11. GOST R ISO / IEC 15910-2002 Postopek za ustvarjanje uporabniške dokumentacije za programsko orodje - opredeljuje minimalno zahtevan postopek za izdelavo uporabniške dokumentacije vseh vrst za programsko orodje, ki ima uporabniški vmesnik. Ti pogledi zajemajo tiskano dokumentacijo (na primer uporabniške priročnike in hitre referenčne kartice), interaktivno (operativno) dokumentacijo, besedilo pomoči (»pomoč«) in interaktivne dokumentacijske sisteme.

Torej, na podlagi vsega napisanega zgoraj, je jasno, da so glavni dokumenti v 34 GOST 3: GOST 34.201-89, RD 50-34.698-90 in GOST 34.602-89.
Pri razvoju paketa dokumentacije morate najprej odpreti GOST 34.201-89 in izbrati stopnjo ustvarjanja Osnutek načrta, Tehnična zasnova in Delovna dokumentacija. Nato morate izbrati dokumente za razvoj, ki ustrezajo stopnji ustvarjanja.

Seznam dokumentov 34 GOST

Stopnja ustvarjanje	Naslov dokumenta	Koda	del projekt	Prinad postelja do projekt ampak oceni noah dok policaj cij	Prinad postelja do izkoriščanje tacija noah gor kumen tacije	Dodatna navodila
EP	Shematski načrt	EP *	ALI	—	—	—
	Pojasnilo Na osnutek načrta	P1	ALI	—	—	—
EP, TP	Organizacijska shema	CO	ALI	—	—	Dovoljeno je vključiti v dokument P3 ali PV
	Strukturna shema kompleksa tehnična sredstva	C1 *	POTEM	X	—
	Diagram funkcionalne strukture	C2 *	ALI	—	—	Pri razvoju dokumentov CO, C1, C2, C3 v fazi ES jih je dovoljeno vključiti v dokument P1
	specializirano (novo) tehnična sredstva	OB 9	POTEM	X	—	Pri razvoju v fazi TP dovoljeno vključiti na dokument P2
	Shema avtomatizacije	C3 *	POTEM	X	—	—
	Pooblastila za razvoj specializirano (novo) tehnična sredstva	—	POTEM	—	—	Projekt ne vključuje
TP	Razvojne naloge sanitarni in drugih oddelkov povezan s projektom z ustvarjanjem sistema	—	POTEM	X	—	Projekt ne vključuje
	Tehnični projektni list	TP *	ALI	—	—	—
	Seznam kupljenih izdelkov	VP *	ALI	—	—	—
	Seznam vhodnih signalov in podatke	V 1	IN O	—	—	—
	Seznam izhodnih signalov (dokumenti)	V 2	IN O	—	—	—
	Seznam razvojnih nalog gradbeni, električni, sanitarni in drugih oddelkov povezan s projektom z ustvarjanjem sistema	NA 3	POTEM	X	—	Dovoljeno je vključiti v dokument P2
	Pojasnilo na tehnični projekt	P2	ALI	—	—	Vključuje akcijski načrt pripraviti objekt za zagon sistemi v delovanju
	Opis avtomatiziranega funkcije	P3	ALI	—	—	—
	Opis nastavitve naloge (nabor nalog)	P4	ALI	—	—	Dovoljeno je vključiti na dokumente P2 ali P3
	Opis informacij sistemska podpora	P5	IN O	—	—	—
	Opis organizacije informacijsko bazo	P6	IN O	—	—	—
TP	Opis klasifikacijskih sistemov in kodiranje	P7	IN O	—	—	—
	Opis niza informacije	P8	IN O	—	—	—
	Opis kompleksa tehnična sredstva	P9	POTEM	—	—	Za nalogo je dovoljeno vključiti v dokument 46 po GOST 19.101
	Opis programske opreme zavarovanje	PA	VKLOPLJENO	—	—	—
	Opis algoritma (postopek oblikovanja)	PB	MO	—	—	Dovoljeno je vključiti v dokumente P2, P3 ali P4
	Opis organizacije strukture	PV	OO	—	—	—
	Načrt postavitve	C8	POTEM	X	—	Dovoljeno je vključiti v dokument P9
	Seznam opreme in materiali	—	POTEM	X	—	—
	Izračun lokalne ocene	B2	ALI	X	—	—
TP, RD	Ocena projekta zanesljivost sistema	B1	ALI	—	—	—
	Risba obrazca dokumenta (video okvir)	C9	IN O	—	X	Na stopnji TP je dovoljeno vključiti v dokumente P4 ali P5
RD	Seznam imetnikov izvirniki	DP *	ALI	—	—	—
	Izjava o delovanju dokumenti	ED *	ALI	—	X	—
	Specifikacija strojne opreme	NA 4	POTEM	X	—	—
	Izjava o zahtevi v materialih	OB 5	POTEM	X	—	—
	Seznam strojnih medijev informacije	VM *	IN O	—	X	—
	Niz vhodnih podatkov	OB 6	IN O	—	X	—
RD	Imenik baze podatkov	OB 7	IN O	—	X	—
	Sestava izhoda (sporočila)	OB 8	IN O	—	X	—
	Lokalne ocene	B3	ALI	X	—	—
	Metoda (tehnologija) avtomatiziran oblikovanje	I1	OO	—	X	—
	Tehnološka navodila	IN 2	OO	—	X	—
	Navodila	I3	OO	—	X	—
	Navodila za oblikovanje in vzdrževanje baze podatkov (nabor podatkov)	I4	IN O	—	X	—
	Navodila za uporabo za KTS	IE	POTEM	—	X	—
	Zunanji priključni načrt	C4 *	POTEM	X	—	Dovoljeno je izvajati v v obliki tabel
	Diagram povezave zunanje ožičenje	C5 *	POTEM	X	—	Tudi
	Povezava in povezovalna miza	C6	POTEM	X	—	—
	Diagram delitve sistema (strukturno)	E1 *	POTEM	—	—	—
	Risba splošne ureditve	IN*	POTEM	X	—	—
	Montažna risba tehnične opreme	CA	POTEM	X	—	—
	Shematski diagram	sob	POTEM	X	—	—
	Strukturna shema kompleksa tehnična sredstva	C1 *	POTEM	X	—	—
	Postavitev opreme in ožičenja	C7	POTEM	X	—	—
	Opis tehnološkega proces obdelave podatki (vključno z daljinska obdelava)	PG	OO	—	X	—
	Splošni opis sistema	PD	ALI	—	X	—
	Testni program in metodologija (komponente, sistemi avtomatizacije, podsistemi, sistemi)	PM *	ALI	—	—	—
	Oblika	FD *	ALI	—	X	—
	Potni list	PS *	ALI	—	X	—
* Dokumenti, katerih koda je določena v skladu z zahtevami standardov ESKD

Opomba k tabeli:

1. Tabela uporablja 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;
   • Programska oprema - programske rešitve;
   • MO - programske rešitve.
2. Znak X - označuje pripadnost projektantskim predračunom ali obratovalni dokumentaciji.
3. Nomenklatura dokumentov enega imena je določena glede na oblikovalske odločitve, sprejete pri ustvarjanju sistema.

Ko je seznam dokumentov določen, morate v RD 50-34.698-90 poiskati izbrane dokumente in jih razviti strogo v skladu z navedenimi točkami. Vse točke vsebine, ki so navedene, morajo biti v dokumentu.
Če se razvija tehnični opis, morate takoj odpreti GOST 34.602-89 in razviti tehnično specifikacijo strogo v skladu z odstavki.

GOST 19

Serija GOST 19 (GOST 19.xxx Unified Programming Documentation System (ESPD)) je sestavljena iz:

1. 1. GOST 19.001-77 Splošne določbe - preveč splošen dokument, ni praktičen. Zato ga lahko preskočite.
   2. GOST 19781-90 Izrazi in definicije - dober seznam definicije na področju programske opreme za sisteme za obdelavo informacij. Razen kot definicije ne vsebuje ničesar drugega.
   3. GOST 19.101-77 Vrste programov in programskih dokumentov - eden glavnih dokumentov 19 GOST. Z njim bi morali začeti delati z 19 GOST, saj vsebuje popoln seznam in oznake dokumentov GOST.

Seznam dokumentov 19 GOST

Koda	Vrsta dokumenta	Faze razvoja
		Skica projekt	Tehnični projekt	Delovni osnutek
				komponento	zapleteno
—	Specifikacija	—	—
05	Seznam originalnih imetnikov	—	—	—
12	Besedilo programa	—	—
13	Opis programa	—	—
20	Izjava o operativnih dokumentih	—	—
30	Oblika	—	—
31	Opis aplikacije	—	—
32	Vodnik sistemskega programerja	—	—
33	Programerski vodnik	—	—
34	Uporabniški priročnik	—	—
35	Opis jezika	—	—
46	Tehnični priročnik vzdrževanje	—	—
51	Testni program in metodologija	—	—
81	Pojasnilo			—	—
90-99	Drugi dokumenti

Legenda:
- dokument je obvezen;
- dokument je obvezen za komponente, ki imajo samostojno uporabo;
- potreba po izdelavi dokumenta se določi v fazi razvoja in odobritve nalog;
- - dokument ni sestavljen.

1. GOST 19.102-77 Faze razvoja - vsebuje opis razvojnih stopenj. Uporabno v izobraževalne namene. Po mojem mnenju to nima posebne praktične koristi.
2. GOST 19.103-77 Oznake programov in programskih dokumentov - vsebuje opis dodelitve številke (kode) dokumentu. Tudi po branju tega GOST-a ostaja kup vprašanj o tem, kako dokumentu dodeliti prav to številko.
3. GOST 19.104-78 Osnovni napisi - določa oblike, velikosti, lokacijo in postopek za izpolnjevanje osnovnih napisov homologacijskega lista in naslovne strani v programskih dokumentih, ki jih predvidevajo standardi ESDM, ne glede na način njihove izvedbe. Ker so dokumenti 19 GOST sestavljeni v okvirih, je ta dokument zelo pomemben.
4. GOST 19.105-78 Splošne zahteve za programske dokumente - določa splošne zahteve za oblikovanje programskih dokumentov. Zahteve so preveč splošne. Praviloma se ta GOST skoraj nikoli ne uporablja za razvoj dokumenta, saj je za dokument dovolj posebnega GOST, vendar je za splošno znanje v tem GOST še vedno bolje pogledati enkrat.
5. GOST 19.106-78 Zahteve za tiskane dokumente programske opreme - vsebuje zahteve za oblikovanje vseh dokumentov GOST 19.
6. GOST 19.201-78 Opis nalog, zahteve za vsebino in načrtovanje - določa postopek za izdelavo in izvedbo tehničnih specifikacij za razvoj programa ali programskega izdelka.

   Klavzule TK 34 GOST in 19 GOST se razlikujejo.

7. GOST 19.601-78 Splošna pravila za podvajanje, računovodstvo in shranjevanje - splošna pravila podvajanje, kroženje, obračunavanje in shranjevanje programskih dokumentov. V GOST je v več odstavkih opisano, kako zagotoviti, da se dokumenti ne izgubijo.
8. GOST 19.602-78 Pravila za podvajanje, obračunavanje in shranjevanje programskih dokumentov, dokončano tiskanje. Na nek način - dodatek k GOST 19.601-78.
9. GOST 19.603-78 Splošna pravila za spremembe - določa splošna pravila za spreminjanje programskih dokumentov. V bistvu opisuje dolg birokratski algoritem za spreminjanje dokumentov.
10. GOST 19.604-78 Pravila za spreminjanje programskih dokumentov, narejenih na tiskani način - opisuje postopek dela in izpolnjevanja lista za registracijo sprememb s seznama.

Seznam specializiranih GOST-jev, to je, vsak od njih opisuje vsebino in zahteve za določen dokument:

1. GOST 19.202-78 Specifikacija. Zahteve glede vsebine in oblikovanja;
2. GOST 19.301-79 Program in preskusni postopek. Zahteve glede vsebine in oblikovanja;
3. GOST 19.401-78 Besedilo programa. Zahteve glede vsebine in oblikovanja;
4. GOST 19.402-78 Opis programa;
5. GOST 19.403-79 Seznam originalnih imetnikov;
6. GOST 19.404-79 Pojasnilo. Zahteve glede vsebine in oblikovanja;
7. Obrazec GOST 19.501-78. Zahteve glede vsebine in oblikovanja;
8. GOST 19.502-78 Opis uporabe. Zahteve glede vsebine in oblikovanja;
9. GOST 19.503-79 Navodila za sistemske programerje. Zahteve glede vsebine in oblikovanja;
10. GOST 19.504-79 Priročnik za programerje. Zahteve glede vsebine in oblikovanja;
11. GOST 19.505-79 Navodila za uporabo. Zahteve glede vsebine in oblikovanja;
12. GOST 19.506-79 Opis jezika. Zahteve glede vsebine in oblikovanja;
13. GOST 19.507-79 Izjava o operativnih dokumentih;
14. GOST 19.508-79 Priročnik za vzdrževanje. Zahteve glede vsebine in oblikovanja.

Postopek za delo z 19 GOST:

1. V GOST 19.101-77 izberite dokument in njegovo kodo glede na razvojno stopnjo.
2. V skladu z GOST 19.103-77 dokumentu dodelite številko.
3. Nato v skladu z GOST 19.104-78 in 19.106-78 sestavite dokument.
4. S specializiranega seznama GOST-ov izberite tistega, ki ustreza dokumentu, ki se razvija.

Zaključek

GOST ni strašljiv in enostaven! Glavna stvar je razumeti, kaj je treba napisati in kaj se GOST uporablja za to. Naša glavna GOST 19 in 34 za pisanje dokumentacije sta zelo stara, vendar sta še vedno pomembna do danes. Pisanje dokumentacije v skladu s standardom odpravlja številna vprašanja med izvajalcem in naročnikom. Zato prihrani čas in denar.

Datum uvedbe 01.01.92

Ta standard velja za avtomatizirane sisteme (AS), ki se uporabljajo v različni tipi dejavnosti (raziskave, načrtovanje, upravljanje itd.), vključno z njihovimi kombinacijami, ustvarjenimi v organizacijah, združenjih in podjetjih (v nadaljnjem besedilu - organizacije).

Standard določa faze in faze ustvarjanja zvočnika. Priloga 1 vsebuje vsebino dela na vsaki stopnji.

1. Splošne določbe

2. Faze in faze ustvarjanja govorca

Dodatek 1 (referenca)

Dodatek 2 (referenca)

1. SPLOŠNE DOLOČBE

1.1. je niz časovno urejenih, medsebojno povezanih, združenih v etape in faze dela, katerih izvedba je potrebna in zadostna za ustvarjanje AU, ki izpolnjuje določene zahteve.

1.2. Kot del procesa ustvarjanja zaradi racionalnega načrtovanja in organizacije dela ločimo stopnje in faze ustvarjanja AU, ki se konča z danim rezultatom.

1.3. Delo pri razvoju AU poteka po fazah in fazah, ki se uporabljajo za ustvarjanje AU.

1.4. Sestava in pravila za opravljanje dela na stopnjah in fazah, določenih s tem standardom, so določena v ustrezni dokumentaciji organizacij, ki sodelujejo pri ustvarjanju posebnih vrst jedrskih elektrarn.

Seznam organizacij, ki sodelujejo pri oblikovanju AU, je podan v Dodatku 2.

2. FAZE IN STOPNJE USTVARJANJA AU

2.1. Faze in faze ustvarjanja AU v splošnem primeru so prikazane v tabeli.

Obdobja	Faze dela
1. Oblikovanje zahtev za AU	1.1. Pregled lokacije in utemeljitev potrebe po izgradnji jedrske elektrarne
	1.2. Oblikovanje uporabniških zahtev za zvočnika
	1.3. Registracija poročila o opravljenem delu in prijave za razvoj AU (taktično-tehnična naloga)
2. Razvoj koncepta AU	2.1. Študija predmeta
	2.2. Opravljanje potrebnega raziskovalnega dela
	2.3. Razvoj variant koncepta zvočnika in izbor različice koncepta zvočnika, ki ustreza zahtevam uporabnika
	2.4. Registracija poročila o opravljenem delu
3. Pooblastila	3.1. Razvoj in odobritev tehničnih specifikacij za oblikovanje AU
4. Osnutek projekta	4.1. Razvoj idejnih projektnih rešitev sistema in njegovih delov
	4.2. Izdelava dokumentacije za NEK in njene dele
5. Tehnična zasnova	5.1. Razvoj oblikovalskih rešitev za sistem in njegove dele
	5.2. Izdelava dokumentacije za NEK in njene dele
	5.3. Razvoj in izvedba dokumentacije za dobavo izdelkov za dokončanje jedrskih elektrarn in (ali) tehničnih zahtev (tehničnih specifikacij) za njihov razvoj
	5.4. Izdelava projektnih nalog v sorodnih delih projekta objekta avtomatizacije
6. Delovna dokumentacija	6.1. Izdelava delovne dokumentacije za sistem in njegove dele
	6.2. Razvoj ali prilagoditev programov
7. Začetek delovanja	7.1. Priprava objekta avtomatizacije za zagon NEK
	7.2. Usposabljanje osebja
	7.3. Dopolnitev zvočniškega sistema s priloženimi izdelki (programska in strojna oprema, programski in strojni kompleksi, informacijski izdelki)
	7.4. Gradbena in inštalacijska dela
	7.5. Zagonska dela
	7.6. Preliminarni testi
	7.7. Poskusno delovanje
	7.8. Sprejemni testi
8. Spremstvo AU	8.1. Opravljanje del v skladu z garancijskimi obveznostmi
	8.2. Pogarancijski servis

2.2. Faze in faze, ki jih izvajajo organizacije - udeleženke pri delu pri oblikovanju AU, so določene v pogodbah in nalogah, ki temeljijo na tem standardu.

Dovoljeno je izključiti fazo "Osnutek načrta" in ločene faze dela v vseh fazah, združiti stopnje "Tehnična zasnova" in "Delovna dokumentacija" v eni fazi "Tehnična zasnova". Glede na posebnosti ustvarjenih jedrskih sistemov in pogojev za njihovo ustvarjanje je dovoljeno izvesti posamezne faze dela pred zaključkom prejšnjih stopenj, vzporedno časovno izvajanje faz dela, vključitev novih stopenj dela. .

PRILOGA 1 Referenca

1. Na stopnji 1.1 "Pregled objekta in utemeljitev potrebe po izgradnji jedrske elektrarne" v splošnem primeru izvedite:

• zbiranje podatkov o objektu avtomatizacije in izvedenih dejavnostih;
• ocena kakovosti objekta in izvedenih dejavnosti, prepoznavanje problemov, katerih rešitev je možna z avtomatizacijo;
• ocena (tehnična, ekonomska, socialna itd.) izvedljivosti oblikovanja AU.

2. V fazi 1.2 "formiranje uporabniških zahtev za AU" izvedite:

• priprava začetnih podatkov za oblikovanje zahtev za jedrsko elektrarno (značilnosti objekta avtomatizacije, opis zahtev za sistem, omejitev dopustnih stroškov razvoja, zagona in obratovanja, pričakovani učinek od sistema, pogoji za ustvarjanje in delovanje sistema);
• oblikovanje in izvedba uporabniških zahtev za AU.

3. Na stopnji 1.3 "Izvedba poročila o opravljenem delu in vloge za razvoj AU (taktično-tehnična naloga)" se izdela poročilo o opravljenem delu v tej fazi in vloga za razvoj AU (taktično-tehnična naloga) ali drug dokument, ki jo nadomešča, je sestavljen s podobno vsebino.

4. Na stopnjah 2.1 "Študija predmeta" in 2.2 "Izvajanje potrebnega raziskovalnega dela" razvijalec izvede podrobno študijo predmeta avtomatizacije in potrebno raziskovalno delo (R&R), povezano z iskanjem načinov in oceno možnosti uresničevanje zahtev uporabnikov, izdelava in potrjevanje poročil o raziskavah.

5. Na stopnji 2.3 "Razvoj možnosti za koncept AU in izbira različice koncepta AU, ki ustreza zahtevam uporabnika", v splošnem primeru razvoj alternativne možnosti koncept oblikovanja AU in načrti za njihovo izvajanje; ocenjevanje potrebna sredstva za njihovo izvajanje in vzdrževanje delovanja; ocena prednosti in slabosti vsake možnosti; primerjava uporabniških zahtev in značilnosti predlaganega sistema ter izbor najboljša možnost; določitev postopka ocenjevanja kakovosti in pogojev prevzema sistema; oceno učinkov, prejetih od sistema.

6. V fazi 2.4 "Poročanje o opravljenem delu" pripravi in ​​sestavi poročilo, ki vsebuje opis opravljenega dela v fazi, opis in utemeljitev predlagane različice koncepta sistema.

7. Na stopnji 3.1 "Razvoj in odobritev projektnega pooblastila za ustanovitev NEK" se razvija, izvedba, usklajevanje in odobritev projektnega pooblastila za NPP in po potrebi naloge za del projekta. NPP se izvajajo.

8. V fazi 4.1 "Razvoj idejnih projektnih rešitev za sistem in njegove dele" se določijo: funkcije AU; funkcije podsistemov, njihovi cilji in učinki; sestava kompleksov nalog in posameznih nalog; koncept informacijske baze, njena razširjena struktura; Funkcije sistema za upravljanje baz podatkov; sestava računalniškega sistema; funkcije in parametre glavne programske opreme.

9. Na stopnji 5.1 "Razvoj projektantskih rešitev za sistem in njegove dele" zagotovi razvoj splošnih rešitev za sistem in njegove dele, funkcionalno in algoritemsko strukturo sistema, za funkcije osebja in organizacijska struktura, po strukturi tehničnih sredstev, po algoritmih za reševanje problemov in uporabljenih jezikih, po organizaciji in vzdrževanju informacijske baze, sistemu klasifikacije in kodiranja informacij, s programsko opremo.

10. Na stopnjah 4.2 in 5.2 " Razvoj dokumentacije v NEK in njenih delih »izvajajo razvoj, izvedbo, usklajevanje in potrditev dokumentacije v obsegu, ki je potreben za opis celotnega sklopa sprejetih projektnih rešitev in zadostuje za nadaljnja dela pri nastanku NEK. Vrste dokumentov - po GOST 34.201.

11. Na stopnji 5.3 "Razvoj in izvedba dokumentacije za dobavo izdelkov za dokončanje NEK in (ali) tehničnih zahtev (tehničnih specifikacij) za njihov razvoj" pripravi in ​​izvede dokumentacijo za dobavo izdelkov za dokončanje NEK; določitev tehničnih zahtev in priprava tehničnih specifikacij za razvoj izdelkov, ki niso serijsko proizvedeni.

12. Na stopnji 5.4 "Razvoj projektantskih nalog v sosednjih delih projekta avtomatizacije" izvaja razvoj, izvedbo, usklajevanje in odobritev projektnih nalog v sosednjih delih objekta avtomatizacije za gradbena, elektro, sanitarna in druga pripravljalna dela v zvezi z ustvarjanje AC.

13. Na stopnji 6.1 "Razvoj delovne dokumentacije za sistem in njegove dele" se razvije delovna dokumentacija, ki vsebuje vse potrebne in zadostne informacije za zagotavljanje izvajanja del pri zagonu NEK in njenega delovanja ter vzdrževanje raven obratovalnih značilnosti (kakovosti) sistema v skladu s sprejetimi projektnimi odločitvami, njegova registracija, usklajevanje in odobritev. Vrste dokumentov - po GOST 34.201.

14. Na stopnji 6.2 "Razvoj ali prilagoditev programov" se razvijejo programi in programska oprema sistema, izbira, prilagoditev in (ali) vezava kupljene programske opreme, razvoj programske dokumentacije v skladu z GOST 19.101.

15. Na stopnji 7.1 "Priprava objekta avtomatizacije za zagon NEK" se izvajajo dela na organizacijski pripravi objekta avtomatizacije za zagon NEK, vključno z: izvedbo projektnih rešitev za organizacijsko strukturo NEK; zagotavljanje pododdelkov objekta upravljanja z učnimi in metodološkimi materiali; uvedba klasifikatorjev informacij.

16. Na stopnji 7.2 "Usposabljanje osebja" se osebje usposablja in preverja njihova sposobnost zagotavljanja delovanja NEK.

17. V fazi »Dokončanje AU z dobavljenimi izdelki« zagotovite prejem serijskih in enotskih proizvodnih komponent, materialov in montažnih izdelkov. Izvajajo vhodno kontrolo kakovosti.

18. V fazi 7.4 "Gradbena in inštalacijska dela" se izvajajo: izvedba del na gradnji specializiranih zgradb (prostorov) za namestitev tehnične opreme in osebja NEK; gradnja kabelskih kanalov; izvedba del na inštalaciji tehničnih sredstev in komunikacijskih vodov; testiranje vgrajene tehnične opreme; dobava tehničnih sredstev za zagon.

19. Na stopnji 7.5 "Zagon" izvede avtonomno prilagajanje strojne in programske opreme, nalaganje informacij v bazo podatkov in preverjanje vzdrževanja sistema; kompleksno prilagajanje vseh sistemskih sredstev.

20. Na stopnji 7.6 "Predhodni preskusi" opravite:

• preizkušanje delovanja jedrske elektrarne in skladnost s projektnim zadatkom v skladu s programom in načinom predhodnih preizkusov;
• odpravljanje okvar in dopolnitev dokumentacije za NEK, vključno z obratovalno, v skladu s poročilom o preskusu;
• registracija potrdila o sprejemu jedrske elektrarne v poskusno obratovanje.

21. V fazi 7.7 "Poskusno obratovanje" se izvaja poskusno obratovanje NEK; analiza rezultatov poskusnega obratovanja NEK; revizija (če je potrebno) programske opreme AC; dodatna prilagoditev (če je potrebno) tehničnih sredstev jedrske elektrarne; registracija potrdila o zaključku poskusnega obratovanja.

22. Na stopnji 7.8 "Sprejemni preskusi" opravite:

• preizkusi skladnosti s projektnim zadatkom v skladu s programom in metodami prevzemnih preizkusov;
• analiza rezultatov AU testov in odprava ugotovljenih pomanjkljivosti med preizkusi;
• registracija potrdila o sprejemu jedrske elektrarne v trajno obratovanje.

23. V fazi 8.1 "Opravljanje del v skladu z garancijskimi obveznostmi" se izvajajo dela za odpravo pomanjkljivosti, ugotovljenih med obratovanjem NEK v ugotovljenih garancijskih rokih, za potrebne spremembe dokumentacije za NEK.

24. V fazi 8.2 "Pogarancijski servis" se izvajajo dela na:

• analiza delovanja sistema;
• ugotavljanje odstopanj dejanskih obratovalnih značilnosti NEK od projektnih vrednosti;
• ugotavljanje razlogov za ta odstopanja;
• odprava ugotovljenih pomanjkljivosti in zagotavljanje stabilnosti obratovalnih značilnosti NEK;
• opravi potrebne spremembe v dokumentaciji za AU.

PRILOGA 2. Referenca

SEZNAM ORGANIZACIJ, KI SODELUJEJO PRI DELU NA USTVARJANJU AU

1. Organizacija-naročnik (uporabnik), za katero bo NEK ustvarjena in ki zagotavlja financiranje, prevzem del in obratovanje NEK ter izvedbo posameznih del za nastanek NEK.

2. Organizacija-razvijalec, ki izvaja delo pri ustvarjanju AU, ki stranki zagotavlja nabor znanstvenih in tehničnih storitev za različne faze in fazah ustvarjanja ter razvoja in dobave različne programske in strojne opreme AU.

3. Organizacija dobaviteljev, ki proizvaja in dobavlja programsko in strojno opremo na zahtevo razvijalca ali stranke.

4. Organizacijsko-generalni projektant objekta avtomatizacije.

5. Oblikovalske organizacije različni deli projekt objekta avtomatizacije za gradbena, elektro, sanitarna in druga pripravljalna dela v zvezi z izgradnjo jedrske elektrarne.

6. Organizacije za gradnjo, montažo, zagon in drugo.

Opombe:

1. Glede na pogoje za ustvarjanje AU so možne različne kombinacije funkcij naročnika, razvijalca, dobavitelja in drugih organizacij, ki sodelujejo pri ustvarjanju AU.

2. Faze in faze njihovega dela pri oblikovanju AU so določene na podlagi tega standarda.

INFORMACIJSKI PODATKI

1. RAZVOJ IN UVODIL Državni odbor ZSSR za upravljanje kakovosti izdelkov in standarde

RAZVIJACI

Yu.Kh. Vermišev, dr. znanosti; Ya.G. Vilenchik; V IN. Voropajev, dr. znanosti; L.M. Seidenberg, dr. tech. znanosti; Yu.B. Irz, Kand. tech. znanosti; V.D. Kostjukov, dr. tech. znanosti; M.A. Labutin, kond. tech. znanosti; N.P. Leskovskaya; I.S. Mityaev; V.F. Popov (vodja teme); S.V. Garshina; A.I. Gluhi verujoči; JUG. Žukov, doc. znanosti; Z.P. Zadubovskaya; V.G. Ivanov; Yu.I. Karavanov, doc. znanosti; A.A. Drobci; V.Yu. Korolev; V IN. Makhnach, dr. tech. znanosti; S. B. Mihalev, dr. znanosti; V.N. Petrikevič; V.A. Rakhmanov, dr. ekonomičnost. znanosti; A.A. Ratkovich; R.S. Sedegov, dr. znanosti; N.V. Stepančikova; GOSPA. Surovets; A.V. Fleents; L.O. Khvilevsky, dr. tech. znanosti; VC. Čistov, dr. ekonomičnost. znanosti

2. ODOBREN IN UVODEN V DEJANJE z Odlokom Državnega odbora ZSSR za upravljanje kakovosti izdelkov in standardov z dne 29. decembra 1990 št. 3469