Šiandien kalbėsime apie vietinius projektų dokumentacijos standartus. Kaip šie standartai veikia praktiškai, kodėl jie blogi ir kas yra gerai. Kurdami dokumentaciją valstybiniams ir rimtiems privatiems klientams dažniausiai neturime pasirinkimo – standartų laikymasis yra įrašytas techninių specifikacijų dokumentavimo reikalavimuose. Praktikoje esu susidūręs su įvairiais pavyzdžiais, kai nesupratau standartų sandaros, kas turi būti dokumentuose ir kam šie dokumentai reikalingi. Todėl kartais iš techninių rašytojų, analitikų ir specialistų plunksnos išlenda tokie brangakmeniai, kad neaišku, kokioje sąmonės būsenoje jie buvo parašyti. Tačiau iš tikrųjų viskas yra gana paprasta. Paieškoje „Habr“ nebuvo rasta nuorodų į daugiau ar mažiau išsamią medžiagą šia tema, todėl siūlau užpildyti šią erzinančią spragą.
Kas yra dokumentacijos standartai?
Aptariamoje 34 serijoje yra tik 3 pagrindiniai dokumentavimo standartai:Mėgstamiausias ir populiariausias techninių specifikacijų kūrimo standartas. Vienintelis dalykas, kurio neturėtumėte pamiršti, yra tai, kad jis yra glaudžiai susijęs su kitais serijos standartais, o jei gavote techninę specifikaciją, pagamintą pagal šį standartą, labai pageidautina laikytis kitų standartų, net jei jų nėra. tiesioginiai reikalavimai tam. Bent jau kalbant apie bendra ideologija(apie kurį žemiau)
Tai yra pagrindinis dokumentas, kuriame numatyta pilnas sąrašas GOST 34 dokumentacija, rekomendacijos dėl dokumentų kodavimo, kokiems projekto etapams priklauso dokumentai (etapai aprašyti GOST 34.601-90), taip pat kaip juos galima derinti tarpusavyje.
Tiesą sakant, šis standartas yra didelė anotuota lentelė. Kad būtų lengviau naudoti, jį galima perkelti į „Excel“.
Didelis standartas, apibūdinantis projekto dokumentų turinį su įvairaus detalumo laipsniu. Pirmiau minėtas GOST 34.201-89 naudojamas kaip indeksas.
Kyla daug klausimų ir jo nuostatų interpretacijų RD 50-34.698-90 standartui, kurias dėl savo neaiškumo dažnai skirtingai supranta užsakovas ir rangovas ar net projekto komandos nariai. Bet, deja, nieko konkretesnio neturime.
Dabar panagrinėkime standartų privalumus ir trūkumus, tradiciškai pradėdami nuo minusų.
Standartų trūkumai
Pagrindinis trūkumas akivaizdus visiems – standartai seni. Juose yra pasenęs automatizuotos sistemos architektūros vaizdas. Pavyzdžiui:- dviejų pakopų programos, susidedančios iš kliento programos ir DBVS serverio (nėra trijų ar daugiau „pakopų“ programų, nėra „Weblogic“ ar „JBoss“)
- aprašoma duomenų bazės lentelių struktūra suteiks idėją apie loginį duomenų modelį (faktas, kad tarp programos ir duomenų bazės gali būti šiek tiek užmigdymo, tada atrodė, kad tai yra blogas perteklius)
- vartotojo sąsaja yra vieno lango (ar gali būti kitaip? O kas yra „naršyklė“?)
- Sistemoje nėra daug ataskaitų, jos visos yra popierinės ir spausdinamos taškiniu spausdintuvu
- Sukurta programa yra orientuota į „informacijos apdorojimo problemos“ sprendimą, kuri turi aiškų įvestį ir išvestį bei yra labai specializuota. Informacijos apdorojimas pagrįstas „algoritmu“. Kartais būna keli „algoritmai“. (Objektinis programavimas tada žengė tik pirmuosius žingsnius ir nebuvo rimtai svarstomas.)
- duomenų bazės administratorius supranta, kokia informacija yra lentelėse, ir aktyviai dalyvauja redaguojant sistemos katalogus (ar tikrai yra vienas DBVS serveris 50 skirtingų programų?)
5.8. Dokumento formos brėžinys (vaizdo įrašo kadras)
Dokumente turi būti pateiktas reikalavimus atitinkantis dokumento formos vaizdas arba vaizdo kadras valstybiniai standartai vieninga dokumentacijos sistema R 50-77 ir reikalingi paaiškinimai.
Dokumento prasmė ta, kad vadinamosios „Spausdinimo zonos“ buvo naudojamos sovietinėse įmonėse, kur buvo didelės spartos taškiniai spausdintuvai, kurių tvarkykles dažnai rašydavo patys inžinieriai. Todėl jie turėjo tvarkyti visų dokumentų, kuriuos reikėjo spausdinti, registrą, kad atspausdinti dokumentai atrodytų taip, kaip turėtų.
"Vaizdo kadras" taip pat yra dokumentas, kuris buvo rodomas teksto ekrane. Ekranai ne visada palaikė reikiamus simbolius ir reikiamą simbolių skaičių horizontaliai ir vertikaliai (ir visiškai nepalaikė grafikos). Todėl ir čia reikėjo papildomai derinti visų ekrano dokumentų formas.
Dabar žodžiai „mašina-grama“, „vaizdo kadras“, „ADCP“ mums nieko nesako. Taip pat neradau jų naudojamų, nors 90-aisiais baigiau specializuotą institutą. Tai buvo Windows 3.1, VGA ekranų, trijų colių diskelių ir pirmųjų vietinių interneto svetainių atsiradimo laikas. Tačiau šie žodžiai yra standarte, o klientas kartais kaprizingai reikalauja pateikti jam visą dokumentų rinkinį pagal GOST 34.201-89. Be to, panašios formuluotės TK klaidžioja iš vienos ministerijos į kitą ir jau tapo savotišku neišsakytu šablonu, į kurį įsmeigta esminė dalis.
Taigi dokumentas kvailu pavadinimu „Dokumento formos brėžinys (vaizdo įrašo kadras)“ projekte turi ir neturi būti tuščias.
Kas gero standarte
Bet koks standartas naudingas tuo, kad leidžia užsakovui ir rangovui kalbėti ta pačia kalba ir suteikia garantiją, kad bent jau formos atžvilgiu užsakovas neturės pretenzijų „forma“ perduodamiems rezultatams.
Ir GOST 34 standartai taip pat yra geri, nes jie buvo sudaryti protingi žmonės, veikia daugelį metų ir turi aiškų tikslą – kuo išsamiau popieriuje apibūdinti sudėtingą abstrakčią esybę, kurią reprezentuoja bet kuri ACS.
Kai jums reikia kompetentingai nustatyti užduotį Vakarų rangovams, kurie niekada negirdėjo apie mūsų GOST, taip pat galite pasikliauti šiais standartais arba, tiksliau, jų turiniu, semantiniu komponentu. Nes vėlgi, informacijos išsamumo garantija yra daug verta. Kad ir kaip lepintume save aukštu savo profesionalumo lygiu, galime pamiršti į savo reikalavimus įtraukti elementarių dalykų, o tas pats GOST 34.602-89 viską „atsimena“. Jei nesuprantate, kaip turėtų atrodyti Vakarų rangovų darbo rezultatas, pažiūrėkite į reikalavimus dokumentacijai, rekomenduojamoms sekcijoms. Užtikrinu jus, geriau to nesugalvoti! Greičiausiai yra vakarietiški mūsų standartų analogai, kuriuose viskas gali būti pilniau, moderniau ir geriau. Deja, nesu su jais susipažinęs, nes dar nebuvo nė vieno atvejo, kad mūsų GOST neužtektų.
Galima juoktis, kad standartų kūrėjai nieko nežinojo apie java ar .NET, apie HD monitorius ir internetą, tačiau nepatarčiau nuvertinti jų darbo masto ir vertės mūsų profesionalų bendruomenei.
Kaip perskaityti ir suprasti GOST 34 serijos dokumentacijos standartus
Standartas visus dokumentus skirsto pagal dvi ašis – laiko ir dalykinės srities. Jei pažvelgsite į GOST 34.201-89 2 lentelę, šis padalijimas yra aiškiai matomas (stulpeliai „Kūrimo etapas“ ir „Projekto dalis“)
Automatizuotos valdymo sistemos sukūrimo etapai
Kūrimo etapai apibrėžti GOST 34.601-90. Trys iš jų yra svarbūs dokumentams:- Projekto projektas (EDS)
- Techninis projektas (TP)
- Darbo dokumentacijos (RD) rengimas
Techninis projektas apibūdina būsimą sistemą iš visų pusių. TP etapo dokumentus perskaičius turėtų likti visiškas siūlomų požiūrių, metodų, architektūrinių ir techninių sprendimų aiškumas. Kitame etape bus per vėlu aprašyti metodus ir pagrįsti techniniai sprendimai todėl P fazė yra raktas į sėkmingas pristatymas veikia, nes visa TK reikalavimų įvairovė turėtų atsispindėti P fazės dokumentuose. P etape sistemos gali išvis nebūti.
Darbo dokumentacija skirta sėkmingam naujos sistemos diegimui, paleidimui ir tolesniam veikimui. Tai dokumentai, kuriuose yra labai konkrečios informacijos, apibūdinančios fiziškai egzistuojančius objektus, o ne P fazė, kuri apibūdina būsimą puošnumą.
Automatizuotos valdymo sistemos sukūrimo projektinės dokumentacijos dalys (skyriai).
Dalyko sritis suskirstyta į „Nustatymai“. Iš pradžių atrodo, kad toks skirstymas yra perteklinis ir nereikalingas. Bet kai pradedi dirbti su šiuo įrankių rinkiniu praktiškai, jame įtvirtinta ideologija pamažu pasiekia.Automatizuota sistema GOST kompiliatorių galvoje yra aparatinės, programinės įrangos ir ryšio kanalų derinys, apdorojantis iš skirtingų šaltinių gaunamą informaciją pagal tam tikrus algoritmus ir pateikiantis apdorojimo rezultatus dokumentų, duomenų struktūrų ar valdymo veiksmų pavidalu. Primityvus paprasčiausio automato modelis.
Siekiant visapusiškai apibūdinti šį „automatą“, buvo atlikti šie pjūviai (kaip brėžinyje):
Programinė įranga (MO), kuris atsako į klausimus: kokia logika slypi už „juodosios dėžės“? Kodėl buvo pasirinkti šie algoritmai, būtent tokios formulės ir būtent tokie koeficientai?
Programinė įranga nieko nežino apie procesorius ar duomenų bazes. Tai atskira abstrakti sritis, „sferinių arklių vakuume“ buveinė. Tačiau programinė įranga gali būti labai glaudžiai susijusi su dalykine sritimi, dar žinoma Tikras gyvenimas... Pavyzdžiui, valdymo sistemų valdymo algoritmai kelių eismas būtina susitarti su kelių policija, kol jie nesutinka užsakovui. Ir tada supranti, kodėl jie išskiriami atskiroje knygoje. Nes kelių policijoje niekam neįdomu, kokia OS veiks aplikacijų serveris, bet koks ženklas ir greičio apribojimas iššoks švieslentėje lyjant ar sningant – labai įdomu. Jie yra atsakingi už savo dalį ir daugiau nieko nesiruošia pasirašyti. Kita vertus, kai jie pasirašys, nekils klausimų techninei klausimo pusei – kodėl pasirinko būtent tuos, o ne kitas lentas ar šviesoforus. „Protėvių“ išmintis būtent tokiais praktiniais atvejais pasireiškia.
Informacijos palaikymas (IO)... Dar viena sistemos dalis. Šį kartą mūsų sistemos juodoji dėžė daroma skaidri ir žiūrime į joje cirkuliuojančią informaciją. Įsivaizduokite žmogaus kraujotakos sistemos modelį, kai visi kiti organai yra nematomi. Tai kažkas panašaus ir yra informacijos palaikymas. Jame aprašoma informacijos perdavimo viduje ir išorėje sudėtis ir maršrutai, loginis informacijos organizavimas sistemoje, žinynų ir kodavimo sistemų aprašymas (kas sukūrė programas gamybai, žino, kokios jos svarbios). Pagrindinė aprašomoji dalis tenka TP stadijai, tačiau kai kurie „rudimentai“ patenka į RD etapą, kaip dokumentas „Duomenų bazių katalogas“. Akivaizdu, kad anksčiau jame buvo būtent tai, kas parašyta pavadinime. Tačiau šiandien pabandykite suformuoti tokį dokumentą sudėtingai sudėtingai sistemai, kai labai dažnai perkamos posistemės su paslaptingomis informacijos saugyklomis naudojamos kaip sistemos dalis. Jau net nekalbu apie tai, kad šis dokumentas dabar ne itin reikalingas.
Arba čia yra „Mašinos informacijos laikmenos pareiškimas“. Akivaizdu, kad jame buvo įrašyti magnetinių būgnų arba plėvelės ritinių numeriai. O dabar ką ten atsinešti?
Trumpai tariant, RD fazėje Informacinės paramos dokumentai yra gana žalingas užuomazgas, nes formaliai jie turėtų būti, bet nėra kuo juos užpildyti.
Programinė įranga (programinė įranga)... Visų mėgstamiausia projekto dokumentacijos dalis. Taip, jei tik todėl, kad tai tik vienas dokumentas! Ir tada visi supranta, ką ten reikia įrašyti. Bet aš vis tiek kartosiu.
Šiame dokumente turime pasakyti, su kokia programine įranga yra vykdomi IO aprašyti algoritmai, kurie apdoroja IO aprašytą informaciją. Tai reiškia, kad čia nereikia dubliuoti informacijos iš kitų skyrių. Jame pateikiama sistemos architektūra, pagrindžiamos pasirinktos programinės įrangos technologijos, jų aprašymas (visi sistemos dalykai: programavimo kalbos, karkasai, operacinės sistemos ir pan.). Taip pat šiame dokumente aprašome, kaip organizuojami informacijos apdorojimo įrankiai (pranešimų eilės, saugyklos, atsarginės kopijos įrankiai, pasiekiamumo sprendimai, visų rūšių taikomųjų programų telkiniai ir kt.). Standartas turi Išsamus aprašymasšio dokumento turinį, kurį gali suprasti bet kuris ekspertas.
Techninė pagalba (TO)... Ne mažiau visų mylima, projekto dokumentacijos dalis. Ryškų vaizdą temdo tik dokumentų, kuriuos reikia plėtoti, gausa. Iš viso pagal standartą reikia parengti 22 dokumentus, iš kurių 9 yra TP stadijoje.
Faktas yra tas, kad standartas numato visos techninės pagalbos aprašymą, įskaitant kompiuterinę įrangą ir tinklus, inžinerines sistemas ir net konstrukcinę dalį (jei reikia). Ir ši ekonomika yra reguliuojama daugybės standartų ir reglamentų, ji yra derinama įvairiose organizacijose ir todėl patogiau viską skaidyti į dalis ir derinti (redaguoti) dalimis. Tuo pačiu metu standartas leidžia derinti kai kuriuos dokumentus tarpusavyje, o tai daryti prasminga, jei dėl visos krūvos susitaria vienas asmuo.
Taip pat nepamirškite, kad kokybės standartų rinkinys apima techninių dokumentų apskaitą ir saugojimą, o mūsų „knygos“ pas klientą gali būti išsklaidytos skirtinguose archyvuose, priklausomai nuo aprašymo temos. Tai dar vienas argumentas, palaikantis dokumentacijos fragmentiškumą.
Organizacinis palaikymas (OO)... Užgniaužęs norą, normalų technikui, kuo greičiau praleisti šią atkarpą, atvirkščiai, panagrinėsiu plačiau. Kadangi, kolegos, pastaraisiais metais buvo nubrėžtos blogos tendencijos projektuose, kuriuos reikia paaiškinti būtent šioje dalyje.
TP etape skyriuje yra tik vienas dokumentas “ Organizacinės struktūros aprašymas“, kuriame turime pasakyti klientui, kam jis turėtų pasiruošti, keisdamas organizacinę struktūrą. Staiga jums reikia organizuoti naują skyrių, kuris veiktų jūsų sistemai, įvestų naujas pareigas ir pan.
RD etape atsiranda kiti, įdomesni dokumentai, kuriuos norėčiau panagrinėti atskirai.
Naudotojo gidas... Komentarai, manau, nereikalingi.
Kompiuterinio projektavimo metodika (technologija).... Šiame dokumente, jei reikia, galite pateikti programinės įrangos kūrimo, versijų valdymo, testavimo ir kt. Bet taip yra, jei TK klientas nori asmeniškai surinkti programinę įrangą. Jei jis to nereikalauja (ir nemoka), tai visa jūsų vidinė virtuvė nėra jo reikalas, ir šio dokumento daryti nereikia.
Technologinis mokymas... Dėl verslo procesų formalizavimo mados gudrus klientas kartais siekia įsprausti veiklos procedūras į šį dokumentą. Taigi, tai jokiu būdu nėra būtina.
Verslo procesų aprašymas, vaidmuo ir pareigybių aprašymai, darbo reglamentas – visa tai yra ORD, tai yra organizacinė ir administracinė dokumentacija. Kuris yra konsultacinio projekto produktas, kuris, kiek suprantu, nepirko iš jūsų. Ir jie nupirko iš jūsų techninį projektą ir jo techninę dokumentaciją.
Technologinė instrukcija yra sluoksnis tarp OSD ir vartotojo vadovo. RP išsamiai aprašo kaip reikia atlikti tam tikrus veiksmus sistemoje. Technologinėje instrukcijoje rašoma kokios rūšies veiksmai turi būti atliekami tam tikrais su sistemos veikimu susijusiais atvejais. Grubiai tariant, technologinė instrukcija yra trumpas RP santrauka, skirta konkrečiai pozicijai ar vaidmeniui. Jei klientas neapibrėžė vaidmenų arba jis nori, kad vaidmenis ir darbo reikalavimus apibrėžtumėte patys, į dokumentą įtraukite pagrindinius vaidmenis, pavyzdžiui: operatorius, vyresnysis operatorius, administratorius. Prie kliento komentarų tema „bet mums nepatinka“ arba „bet mums nepatinka“ turi būti pateiktas vaidmenų sąrašas ir aprašymas. Darbo pareigos... Kadangi verslo procesus mes nedėk... Mes esame šie verslo procesai automatizuoti.
Apie aprašytą grėblį parašysiu atskirai, su spalvingais pavyzdžiais, nes tai jau ne pirmas kartas, kai jis kartojasi skirtinguose „nacionalinio ūkio“ sektoriuose.
Duomenų apdorojimo (įskaitant nuotolinį apdorojimą) technologinio proceso aprašymas... Apgailėtinas urvo amžiaus likutis, kai buvo specialiai paskirti „Kompiuterių operatoriai“, kurie mašiną pamaitindavo perforuotomis kortelėmis, o rezultato spaudinį supakavo į voką. Ši instrukcija skirta jiems. Ką jame rašyti XXI amžiuje - negaliu tiksliai pasakyti. Atsukite patys. Geriausias dalykas yra tiesiog pamiršti šį dokumentą.
Visą sistemą apimantys sprendimai (OR)... Standartas numato 17 OP skyriaus dokumentų. Pirma, tai beveik visi dokumentai iš preliminaraus projekto projekto etapo. Antra, tai yra visokie įvertinimai, skaičiavimai ir Trumpas aprašymas automatizuotos funkcijos. Tai yra, informacija žmonėms ne iš pagrindinės IT gamybos, o pagalbiniam personalui – vadovams, kaštų vertintojams, pirkimų specialistams, ekonomistams ir kt.
Ir trečia, OR apima megadokumentą, pavadintą „Techninio projekto aiškinamasis raštas“, kuris, pagal idėją, yra savotiška santrauka, tačiau iš tikrųjų daugelis dizainerių į jį įtraukia visą naudingą TP etapo turinį. . Toks radikalus požiūris kartais pasiteisina ir netgi naudingas abiems pusėms tiek užsakovui, tiek rangovui, tačiau tam tikrais atvejais.
GOST 34 naudojimo variantai
- Visiškas ir tikslus standarto laikymasis... Natūralu, kad tokio debesies dokumentų niekas savo noru nesurašys. Todėl tik primygtinai užsakovui pageidaujant rengiamas visas dokumentų komplektas, kurį jis užsitikrino TK ir susitarimu sutraiškė iš viršaus. Tokiu atveju turite viską suprasti pažodžiui ir duoti klientui fizines „knygas“, kuriose bus pateikti dokumentų pavadinimai iš GOST 34.201-89 2 lentelės, išskyrus visiškai nereikalingus, kurių sąrašą tikrai turite. aptarti ir pataisyti raštu. Dokumentų turinys taip pat turi be jokios įsivaizdavimo atitikti RD 50-34.698-90, iki pat skyrių pavadinimų. Kad užsakovo smegenys sprogtų, kartais didelė sistema suskirstoma į posistemius, kiekvienam posistemiui išduodama atskira projektinė dokumentacija. Tai atrodo bauginančiai ir nėra normaliai kontroliuojama žemiško proto pagalba. Ypač kalbant apie posistemių integravimą. Tai labai supaprastina priėmimą. Svarbiausia, kad jūs patys nesusipainiotumėte ir jūsų sistema vis tiek veiktų taip, kaip turėtų.
- Mes tiesiog mėgstame GOST... Rimtai didelių įmonių meilės standartai. Nes jie padeda žmonėms geriau suprasti vieni kitus. Jei pastebėsite, kad jūsų klientas mėgsta tvarką ir standartizaciją, kurdami dokumentus stenkitės laikytis standartinės GOST ideologijos, net jei to nereikalauja techninė specifikacija. Jus geriau supras ir patvirtins koordinuojantys specialistai, o patys nepamiršite įtraukti į dokumentaciją svarbi informacija, geriau matysite tikslinę dokumentų struktūrą, tiksliau suplanuosite jų rašymo darbus ir sutaupysite daug nervų bei pinigų sau ir kolegoms.
- Mums nerūpi dokumentacija, kol viskas veikia.... Išnyksta toks neatsakingas klientas. Panašų požiūrį į dokumentaciją vis dar galima rasti tarp mažų ir neturtingų klientų, taip pat autoritarinėse „idiotokratijose“, likusiose nuo perestroikos, kur viršininkas yra apsuptas ištikimų draugų – direktorių, o visi klausimai sprendžiami asmeniniuose pokalbiuose. Tokiomis sąlygomis galite laisvai pamiršti dokumentaciją apskritai, bet vis tiek geriau nenumušti reginio ir bent jau schematiškai užpildyti dokumentaciją turiniu. Jei ne šiam klientui, tai perkelkite (parduokite) kitam.
Išvada
Šis straipsnis buvo apie mūsų GOST standartus ACS dokumentavimui. GOST yra seni, tačiau, kaip paaiškėjo, jie vis dar labai praverčia buityje. Be kai kurių akivaizdžių užuomazgų, dokumentacijos struktūra pasižymi išbaigtumo ir nuoseklumo savybėmis, o standarto laikymasis pašalina daugybę projektų rizikų, kurių egzistavimo iš pradžių galime net nenutuokti.
Tikiuosi, kad pateikta medžiaga jums buvo naudinga ar bent įdomi. Nepaisant išorinio nuobodulio, dokumentavimas yra svarbus ir atsakingas darbas, kuriame tikslumas yra toks pat svarbus kaip ir gero kodo parašymas. Rašyti geri dokumentai, kolegos! Ir aš esu kitą savaitę Vykstu į dvi komandiruotes iš eilės, todėl naujos medžiagos publikavimo garantuoti negaliu (neturiu parduotuvės, rašau iš galvos).
M. Ostrogorskis, 2008
Norint sėkmingai taikyti GOST 34, būtina suprasti, kaip šio standartų rinkinio požiūriu yra sutvarkyta automatizuota sistema. Priešingu atveju svečiuose nieko nepamatysime, išskyrus ilgą dokumentų sąrašą paslaptingais pavadinimais, o reikalavimai jų turiniui dar kartą įtikins, kad daugelyje išminties yra daug liūdesio. Todėl prieš aptardami pačius dokumentus turime suprasti, kas yra dokumentacijos objektas.
Automatizuota sistema, jos funkcijos ir uždaviniai
Automatizuotos sistemos apibrėžimas
GOST 34.003-90 pateikiamas toks automatizuotos sistemos apibrėžimas: sistema, susidedanti iš personalo ir jų veiklos automatizavimo priemonių rinkinio, diegianti informacines technologijas nustatytoms funkcijoms atlikti. Ką šis apibrėžimas reiškia praktiškai? Tai galite suprasti tik perskaitę kitus šio standarto apibrėžimus ir palyginę juos tarpusavyje. Ką mes dabar darysime.
Veiklos tikslai
Automatizuota sistema gali egzistuoti tik ten, kur dirba tam tikra veikla užsiimantys darbuotojai. Paprastai kalbame apie veiklą, kurios rezultatai yra kažkam naudingi, nepriklausomai nuo naudojamų priemonių. Pavyzdžiui, kreipiuosi į kasą dėl bilieto ir man būtų gerai, jei kasininkė man išrašytų tušinuku ant firminio blanko, kad su juo į salę įleistų. Kasininkei iš esmės taip pat nerūpi, kaip padaryti bilietą. Jai tiktų bet koks metodas, jei jis nebūtų per daug varginantis ir suteiktų galimybę parduoti man bilietą. Kitaip tariant, mes su ja turime bendrą tikslą. GOST 34.003-90 terminas naudojamas jo žymėjimui veiklos tikslas... Kaskart, kai kitas žiūrovas su bilietu rankoje nueina pro langą ir teatras tampa šiek tiek turtingesnis, šis veiklos tikslas pasiekiamas.
Automatizuotos sistemos funkcijos
Gali būti (ir, kaip taisyklė, yra) keli veiklos tikslai. Bet koks rezultatas, naudingas už pačios veiklos ribų, gali būti laikomas jos tikslu. Taigi, jei kasininkė ne tik parduoda bilietą, bet ir darbo dienos pabaigoje surašo viršininkams pardavimo ataskaitą, dienos ataskaitos surašymas gali būti laikomas dar vienu veiklos tikslu.
Jeigu kasininkei ant stalo pastatysime kompiuterį ir spausdintuvą, o kasininkės vadovas išduoda jai įsakymą suvesti bilietus, ataskaitas teksto redaktoriumi ir atsispausdinti spausdintuvu, tai gauname automatizuotą sistemą. Pagal šiuolaikines idėjas jis labai primityvus, formaliai tenkins gosto apibrėžimą. Atkreipiame dėmesį, kad įdiegus automatizuotą sistemą veiklos tikslai nepasikeitė, pasikeitė tik būdas juos pasiekti. Tai, kas anksčiau buvo daroma „tiesiog taip“, dabar daroma automatizuotos sistemos rėmuose. Automatizuotos sistemos veiksmų rinkinys, kuriuo siekiama konkretaus tikslo, pagal GOST 34.003-90 vadinamas. funkcija... Pastaba: kad ir ką apie tai galvotumėte, darbuotojai yra laikomi sistemos dalimi.
Automatizuotos sistemos funkcija yra pagrindinė GOST 34 sąvoka. Automatizuota sistema visų pirma laikoma jos funkcijų visuma, o tik po to kaip „programinės įrangos“ ir „techninės įrangos“ krūva. Svarbiausia, kad tai, ką sistema daro ir iš ko ji susideda, yra antraeilis dalykas.
Tai, kas išdėstyta pirmiau, gali paskatinti skaitytoją padaryti išvadą, kad kiekvieną veiklos tikslą automatizuotoje sistemoje atitinka viena ir tik viena funkcija. Nesunku įsivaizduoti tokią sistemą, tačiau praktika įvairesnė. Viena vertus, veikla ne visada yra visiškai automatizuota. Net ir įdiegus automatizuotą sistemą kai kuriuos tikslus tenka pasiekti rankiniu būdu. Kita vertus, kadangi galima pasiekti tą patį rezultatą skirtingomis sąlygomis Skirtingi keliai, kelios funkcijos gali būti nukreiptos į vieną veiklos tikslą automatizuotoje sistemoje, pavyzdžiui, parduoti bilietą kasoje ir parduoti bilietą internete. Be to, bet kuri automatizuota sistema reikalauja tam tikros priežiūros, todėl būtina įvesti pagalbinės funkcijos sąvoką. Tipiškas pavyzdys yra atsarginių duomenų kopijavimas.
Automatizuotos sistemos užduotys
Bendruoju atveju, atliekant funkciją, dalį darbų atlieka personalas, o dalį – įranga, pavyzdžiui, bilietas automatiškai atspausdinamas, o pirkėjui kasininkės išduodama rankiniu būdu. Automatinių (sic) veiksmų seka, vedanti į tam tikro tipo rezultatą, vadinama GOST 34.003-90 užduotis.
Čia ne visai tiksliai cituojamas problemos apibrėžimas, bet kol kas mums jo užteks ir tai galų gale nėra gėda niekam pačiam skaityti standartą. Svarbu, kad užduotis būtų aiškiausiai formalizuota automatizuotos veiklos dalis. Galima įsivaizduoti visiškai automatiškai atliekamą funkciją, pavyzdžiui, minėtą atsarginę kopiją. Šiuo atveju funkcija sumažinama iki vienos užduoties.
Viena ir ta pati užduotis gali būti išspręsta atliekant skirtingas funkcijas. Pavyzdžiui, jei automatizuota sistema turi kelias bilieto pardavimo funkcijas, tai kiekvienai iš jų tam tikru momentu gali tekti atsispausdinti bilietą.
Automatizuotos sistemos sudėtis
Posistemės
Jei automatizuota sistema pakankamai sudėtinga, ji skirstoma į posistemių... Ką tai reiškia, pakankamai sunku, pakankamai sunku pasakyti. Sistemų teorija aprašo skirtingus sudėtingumo lygius ir kriterijus. Praktikoje poreikis atskirti keletą posistemių automatizuotoje sistemoje dažnai kyla dėl organizacinių ir finansinių priežasčių, pavyzdžiui, posistemės kuriamos ir pradedamos eksploatuoti nuosekliai.
Nors GOST 34 terminas posistemis vartojamas daug kartų, atrodo, kad nėra oficialaus šios sąvokos apibrėžimo. Patirtis rodo, kad posistemis yra automatizuotos sistemos dalis, kuri taip pat atitinka automatizuotos sistemos apibrėžimą, visų pirma turi pilnavertes funkcijas.
Grįžtant prie bilietų pardavimo pavyzdžio, galime nuspręsti, kad automatizuota sistema susideda iš dviejų posistemių: bilietų pardavimo posistemio ir dienos ataskaitų generavimo posistemio. Tik dėl didesnio aiškumo sutikime, kad kasininkė įveda bilietus teksto rengyklėje, o ataskaitas – į skaičiuokles.
Komponentai
Veiklos tikslų, automatizuotos sistemos ir prireikus jos posistemių funkcijų paskirstymas iš esmės yra subjektyvus ir priklausomas nuo subjekto, kuris nusprendė tai padaryti, požiūrio. Jei koks nors rezultatas yra svarbus sprendžiamos problemos kontekste, galime jį laikyti tikslu, o kitaip – ignoruoti. Taip pat automatizuotą sistemą išskaidysime į posistemes taip, kaip mums patogu, jei tik mūsų sprendimai neprieštaraus šios koncepcijos turiniui.
Komponentai yra dalys, iš kurių mes sukuriame automatizuotą sistemą objektyvioje realybėje. Sistema fiziškai susideda iš jos komponentų, todėl automatizuotos sistemos suskirstymas į komponentus yra objektyviausias.
Perkame, montuojame ir prijungiame kiekvieną komponentą (jeigu tai įranga), montuojame (jei tai programa) ir aptarnaujame atskirai nuo kitų komponentų. Nusipirkome ir padėjome ant stalo kompiuterį – tai komponentas. Mes sukūrėme specialų teksto rengyklę bilietų rinkiniui – dar vieną komponentą. Atsisiųstos nemokamos skaičiuoklės iš interneto – vėlgi komponentas. Ir net pati kasininkė tam tikra prasme taip pat yra automatizuotos sistemos komponentas.
Automatizuotos sistemos komponentų sudėtis yra labai svarbi jos dokumentacijos požiūriu, nes pačios sistemos ir komponentų techninė dokumentacija traktuojama skirtingai. Paprastai tariant, jis turėtų būti plėtojamas skirtingi žmonės, ir jis sukurtas pagal skirtingus standartus, priklausomai nuo komponento tipo.
Užstato rūšys
Viena iš sudėtingiausių sąvokų pradedančiajam GOST 34 vartotojui yra saugumo tipas... Kas tai per saugumas? Ar galite jį pamatyti ar paliesti? Parduoti ar pirkti?
Kiekviena paramos rūšis sujungia tam tikro pobūdžio komponentus arba techninius sprendimus. GOST 34 mini daug skirtingi tipai nuostatą, čia kiekvieno iš jų nuosekliai neaprašysime, o išvardinsime tik labiausiai pastebimus:
- informacinis palaikymas – visi duomenys ir metaduomenys, su kuriais sistema dirba;
- programinė įranga – visos programos, kurios yra sistemos dalis;
- techninė pagalba – visos techninės priemonės (kitaip tariant, įranga, aparatūra), kurios yra sistemos dalis.
Dar kartą kartojame, kad tai ne visos užstato rūšys. Net negalime tvirtai pasakyti, kad jie yra patys svarbiausi. Pavyzdžiui, automatizuotoms procesų valdymo sistemoms (APCS) Gera vertė turi metrologinę paramą. Daugeliui automatizuotų sistemų reikalingas sudėtingas matematinis ir kalbinis palaikymas. Tačiau sunku įsivaizduoti automatizuotą sistemą, kurioje visiškai nebūtų vieno iš trijų aukščiau išvardytų paramos tipų (pratimas: išbandykite).
Įvadas
Šiuolaikiniame pasaulyje kasdien atsiranda dešimtys ir šimtai įvairių programų, aplikacijų, informacinių sistemų. Jie gali būti skirti tiek viešajam, tiek komerciniam sektoriui, tiek paprastiems vartotojams. 90% visų vartotojų neskaito dokumentacijos, laiko ją nuobodžia, nuobodžia ir neįdomia, o vartotojo vadovą atidaro tik tada, kai kas nors nepavyksta arba visiškai neįmanoma to išsiaiškinti be instrukcijų. Dabar visuotinai priimta sukurti vartotojo sąsają taip, kad ji būtų intuityvi ir vartotojas galėtų suprasti sistemą neskaitydamas ilgų vadovų. Tačiau dirbant su stambiais klientais beveik visada reikia pateikti tam tikrą dokumentų paketą – vadovus, instrukcijas, projektinius sprendimus, parengtus pagal GOST.
Kai pirmą kartą susiduriate su dokumentų rašymu pagal GOST, patenkate į stuporą ir visišką šoką, nes šie GOST yra „jūra“ ir kaip ir ką apie juos rašyti tampa neaišku.
Šiame straipsnyje aptariami dokumentacijos rašymo GOST ir pagrindiniai jų punktai.
Kas yra GOST?
Pirmiausia turite išsiaiškinti, kas yra GOST. Visi tiesiog žino, kad GOST yra kažkas, kas buvo sukurta sąjungoje, ir jų yra be galo daug. Skubu jus nuraminti, kad IT sektoriuje nėra tiek daug GOST standartų, ir visi jie, nepaisant jų sukūrimo laiko, neprarado savo aktualumo.
Visų pirma, dokumentacijos rašymo standartai skirstomi į du tipus:
- Tarptautiniai standartai (ISO, IEEE Std);
- Rusijos ar sovietų GOST.
Tarptautiniai standartai
Tarptautiniai standartai naudojami kuriant tarptautinio lygio dokumentaciją. Paprastai jie nėra nemokami, nes jų nekuria vyriausybinės organizacijos, tačiau, skirtingai nei mūsų, jie buvo sukurti gana neseniai. tema tarptautinius standartus labai platus, todėl jis bus aptartas kitame straipsnyje. Iš karto paliečiami keli standartai, glaudžiai susiję su dokumentacijos rašymu.
Pagrindinių tarptautinių dokumentų rašymo standartų sąrašas:
- IEEE Std 1063-2001 „IEEE Standard for Software User Documentation“ – vartotojo vadovo rašymo standartas;
- IEEE Std 1016-1998 „IEEE Recommended Practice for Software Design Descriptions“ – programos techninio aprašymo rašymo standartas;
- ISO / IEC FDIS 18019: 2004 „Taikomosios programinės įrangos naudotojo dokumentacijos projektavimo ir rengimo gairės“ yra dar vienas naudotojo vadovų rašymo standartas. Šis dokumentas turi didelis skaičius pavyzdžių. Tai reiškia, kad tai labiau atrodo kaip vartotojo vadovo rašymo vadovas. Pradedantiesiems bus ypač naudinga;
- ISO / IEC 26514: 2008, Reikalavimai naudotojų dokumentacijos dizaineriams ir kūrėjams, yra dar vienas standartas, skirtas naudotojų dokumentacijos dizaineriams ir kūrėjams.
Tiesą sakant, tarptautinių standartų yra daug ir kiekvienoje šalyje jie yra skirtingi, nes tas pats standartas ne visada gali tikti tiek Europos, tiek Azijos įmonėms.
Rusijos standartai
Rusijos standartai yra sukurti valstybiniu lygiu. Jie visi yra visiškai nemokami ir juos visus lengva rasti internete. Programos dokumentacijai rašyti naudojamos dvi serijos GOST 19 ir 34. Būtent apie juos ir bus kalbama toliau.
Kuo skiriasi 19 ir 34 serijų GOST?
Pirmiausia kyla klausimas, kuo šie GOST 19 ir 34 skiriasi vienas nuo kito.
GOST 19.781-90 „Vieninga programos dokumentacijos sistema. Informacijos apdorojimo sistemų programinė įranga. Sąvokos ir apibrėžimai "nurodomos apibrėžtys:
- Programa – duomenys, skirti valdyti konkrečius informacijos apdorojimo sistemos komponentus, siekiant įgyvendinti konkretų algoritmą.
- Programinė įranga – informacijos apdorojimo sistemos programų ir programinių dokumentų rinkinys, reikalingas šioms programoms veikti.
GOST 34.003-90 „Informacinės technologijos. Automatizuotų sistemų standartų rinkinys. Automatizuotos sistemos. Sąvokos ir apibrėžimai "nurodomas apibrėžimas:
- Automatizuota sistema (AS) – tai sistema, susidedanti iš personalo ir jų veiklos automatizavimo priemonių, diegianti informacines technologijas nustatytoms funkcijoms atlikti.
Pavyzdžiui, atsižvelgiant į veiklos pobūdį, išskiriami šie automatizuotų sistemų tipai: automatizuotos valdymo sistemos (ACS), kompiuterinio projektavimo sistemos (CAD), automatizuotos sistemos. moksliniai tyrimai(ASNI) ir kt.
Priklausomai nuo valdomo objekto (proceso) tipo, ACS skirstomas, pavyzdžiui, į: ACS pagal technologinius procesus (ACS), ACS pagal įmones (ACS) ir kt.
Be to, GOST 34 skirstomas į AE paramos tipus:
- Organizacinis;
- Metodinis;
- Techninė;
- Matematinis;
- Programinė įranga;
- Informacinis;
- Lingvistinė;
- Teisinė;
- Ergonomiškas.
Dėl to automatizuota sistema yra ne programa, o palaikymo tipų rinkinys, įskaitant programinę įrangą. AS, kaip taisyklė, teikia konkrečiam vartotojui ir klientui skirtą organizacinį sprendimą, o Programa gali būti sukurta ir atkartota daugeliui vartotojų, nesusijusi su jokia įmone.
Todėl, jei kuriate dokumentaciją programai, kurią sukūrėte konkrečiai įmonei, tada jūsų GOST 34. Jei rašote dokumentus masinei programai, tada jūsų GOST 19.
GOST 34
GOST 34 seriją (GOST 34.xxx informacinių technologijų standartai) sudaro:
- GOST 34.201-89 Dokumentų tipai, išsamumas ir žymėjimai kuriant automatizuotas sistemas - šis standartas nustato dokumentų tipus, pavadinimus, išsamumą ir numerius. Tai vienas iš pagrindinių dokumentų serijoje GOST 34. Tiesą sakant, tai yra pagrindinis dokumentas, todėl pradedantiesiems pirmiausia reikėtų su juo susipažinti.
- GOST 34.320-96 Koncepcinės schemos sąvokos ir terminai informacinė bazė- šis standartas nustato pagrindines konceptualių schemų ir informacinių bazių sąvokas ir terminus, apimančius koncepcinių schemų ir informacinių bazių kūrimą, aprašymą ir taikymą, manipuliavimą informacija, taip pat informacijos proceso aprašymą ir įgyvendinimą. Standartas apibrėžia konceptualios schemos vaidmenį. Jame išdėstytos nuostatos yra patariamojo pobūdžio ir gali būti naudojamos vertinant duomenų bazių valdymo sistemas (DBVS). Šiame dokumente neaprašomi konkretūs konceptualios schemos palaikymo įrankių naudojimo metodai. Standarte aprašytos konceptualios schemos kalbos neturėtų būti laikomos standartinėmis.
- GOST 34.321-96 Informacinės technologijos. Duomenų bazių standartų sistema. Valdymo pamatinis modelis – šis dokumentas nustato duomenų valdymo pamatinį modelį.
Pamatinis modelis apibrėžia bendrąją terminiją ir sąvokas, susijusias su informacinių sistemų duomenimis. Tokios sąvokos naudojamos duomenų bazių valdymo sistemų ar duomenų žodynų sistemų teikiamoms paslaugoms apibrėžti.
Pamatiniame modelyje duomenų valdymo protokolai neatsižvelgiama.
Etaloninio modelio taikymo sritis apima procesus, susijusius su nuolatinių duomenų valdymu ir jų sąveika su procesais, kurie skiriasi nuo konkretaus informacinė sistema taip pat bendrosios duomenų valdymo paslaugos, skirtos duomenims apibrėžti, saugoti, ieškoti, atnaujinti, įvesti, kopijuoti, atkurti ir perduoti. - GOST 34.601-90 Automatizuotos sistemos. Kūrimo etapai – standartas nustato AS kūrimo etapus ir etapus.
- GOST 34.602-89 Automatizuotos sistemos kūrimo techninės sąlygos (vietoj GOST 24.201-85) - nustato dokumento „Sistemos kūrimo (plėtojimo ar modernizavimo) sąlygos, sudėtis, turinys, rengimo taisyklės. “.
Šis dokumentas yra vienas iš dažniausiai naudojamų GOST 34 serijos dokumentų Kuriant TK pagal šį GOST, reikia atsiminti apie kitus standartus, net jei šiame dokumente nėra nuorodų į šiuos standartus. - GOST 34.603-92 Informacinės technologijos. Automatizuotų sistemų testų tipai – standartas nustato AU testų tipus (autonominis, integruotas, priėmimo testai ir bandomasis veikimas) ir bendruosius jų atlikimo reikalavimus.
- RD 50-34.698-90 Automatizuotos sistemos. Reikalavimai dokumentų turiniui yra vienas iš svarbiausių 34 GOST dokumentų, nes jame aprašomas beveik visų dokumentų turinys, taip pat kiekvienos dokumento pastraipos aprašymas.
- GOST R ISO / IEC 8824-3-2002 Informacinės technologijos. Pirmoji abstrakčiojo sintaksės žymėjimo versija – šis tarptautinis standartas yra 1 abstrakčios sintaksės žymėjimo (ASN.1) dalis ir pateikia vartotojo apibrėžtų apribojimų ir lentelės apribojimų nurodymą.
- GOST R ISO / IEC 10746-3-2001 Duomenų valdymas ir atviras paskirstytas apdorojimas.
Šiame standarte:- nustatoma, kaip nurodomos atvirojo paskirstytojo apdorojimo (ODP) sistemos, naudojant GOST R ISO / IEC 10746-2 pateiktas sąvokas;
- nustatomos charakteristikos, pagal kurias sistemos priskiriamos ODP sistemoms.
Standartas nustato ODP sistemų standartų kūrimo koordinavimo sistemą.
- GOST R ISO / IEC 15271-02 Programinės įrangos gyvavimo ciklo procesai – šis GOST, mano nuomone, labiau reikalingas atominių elektrinių projektavimo ir modeliavimo analitikams.
Šis dokumentas, mano požiūriu, yra naudingas tik švietimo tikslais. - GOST R ISO / IEC 15910-2002 Programinės įrangos įrankio vartotojo dokumentacijos kūrimo procesas – apibrėžia minimalų reikalingą visų rūšių vartotojo dokumentacijos kūrimo procesą programinės įrangos įrankiui, turinčiam vartotojo sąsają. Šie rodiniai apima spausdintą dokumentaciją (pavyzdžiui, vartotojo vadovus ir greitų nuorodų korteles), interaktyvią (eksploatacinę) dokumentaciją, žinyno tekstą ("pagalba") ir interaktyvias dokumentų sistemas.
Taigi, remiantis viskuo, kas parašyta aukščiau, aišku, kad pagrindiniai dokumentai 34 GOST 3: GOST 34.201-89, RD 50-34.698-90 ir GOST 34.602-89.
Kurdami dokumentų paketą, pirmiausia turite atidaryti GOST 34.201-89 ir pasirinkti kūrimo etapą Projektavimo projektas, Techninis projektas ir Darbo dokumentacija. Toliau turėtumėte pasirinkti kūrimo etapą atitinkančius dokumentus.
Dokumentų sąrašas 34 GOST
| Scena kūryba |
Dokumento pavadinimas | Kodas | dalis projektas |
Prinad lova į projektą bet įvertink nojaus dokas policininkas cijos |
Prinad lova į išnaudojant tacija nojus aukštyn kumenas tacijos |
Papildomos instrukcijos |
| EP | Scheminis dizaino lapas | EP* | ARBA | — | — | — |
| Aiškinamasis raštas Prie projekto projekto |
P1 | ARBA | — | — | — | |
| EP, TP | Organizacinė diagrama | CO | ARBA | — | — | Į dokumentą leidžiama įtraukti P3 arba PV |
| Komplekso struktūrinė schema techninėmis priemonėmis |
C1* | TADA | NS | — | ||
| Funkcinės struktūros diagrama | C2* | ARBA | — | — | Rengiant dokumentus CO, C1, C2, C3 ES etape, leidžiama juos įtraukti į dokumentą P1 | |
specializuota (nauja) techninėmis priemonėmis |
9 val | TADA | NS | — | Vystantis TP stadijoje leidžiama įtraukti į dokumentą P2 |
|
| Automatikos schema | C3* | TADA | NS | — | — | |
| Plėtros techninės sąlygos specializuota (nauja) techninėmis priemonėmis |
— | TADA | — | — | Projektas neapima | |
| TP | Vystymo užduotys sanitariniai ir kiti skyriai susijęs su projektu su sistemos sukūrimu |
— | TADA | NS | — | Projektas neapima |
| Techninio projekto lapas | TP* | ARBA | — | — | — | |
| Pirktų prekių sąrašas | VP* | ARBA | — | — | — | |
| Įvesties signalų sąrašas ir duomenis |
1 | IR APIE | — | — | — | |
| Išvesties signalų sąrašas (dokumentai) |
2 | IR APIE | — | — | — | |
| Kūrimo užduočių sąrašas statybos, elektros, sanitariniai ir kiti skyriai susijęs su projektu su sistemos sukūrimu |
3 d | TADA | NS | — | Leidžiama įtraukti į P2 dokumentą | |
| Aiškinamasis raštas prie techninio projekto |
P2 | ARBA | — | — | Apima veiksmų planą parengti objektą paleisti veikiančios sistemos |
|
| Automatizavimo aprašymas funkcijas |
P3 | ARBA | — | — | — | |
| Užduoties nustatymo aprašymas (užduočių rinkinys) |
P4 | ARBA | — | — | Leidžiama įtraukti į dokumentus P2 arba P3 |
|
| Informacijos aprašymas sistemos palaikymas |
P5 | IR APIE | — | — | — | |
| Organizacijos aprašymas informacinė bazė |
P6 | IR APIE | — | — | — | |
| TP | Klasifikavimo sistemų aprašymas ir kodavimas |
P7 | IR APIE | — | — | — |
| Masyvo aprašymas informacija |
P8 | IR APIE | — | — | — | |
| Komplekso aprašymas techninėmis priemonėmis |
P9 | TADA | — | — | Užduočiai leidžiama įtraukti į 46 dokumentą pagal GOST 19.101 | |
| Programinės įrangos aprašymas užtikrinimas |
PA | ĮJUNGTA | — | — | — | |
| Algoritmo aprašymas (projektavimo procedūra) |
PB | MO | — | — | Leidžiama įtraukti į dokumentus P2, P3 arba P4 | |
| Organizacijos aprašymas struktūros |
PV | OO | — | — | — | |
| Išdėstymo planas | C8 | TADA | NS | — | Leidžiama įtraukti į P9 dokumentą | |
| Įrangos sąrašas ir medžiagas |
— | TADA | NS | — | — | |
| Vietinės sąmatos skaičiavimas | B2 | ARBA | NS | — | — | |
| TP, RD | Projekto vertinimas sistemos patikimumas |
B1 | ARBA | — | — | — |
| Dokumento formos brėžinys (vaizdo įrašo kadras) |
C9 | IR APIE | — | NS | TP stadijoje tai leidžiama įtraukti į dokumentus P4 arba P5 |
|
| RD | Turėtojų sąrašas originalai |
DP* | ARBA | — | — | — |
| Veiklos pareiškimas dokumentus |
ED* | ARBA | — | NS | — | |
| Techninės įrangos specifikacija | 4 val | TADA | NS | — | — | |
| Reikalavimo pareiškimas medžiagose |
5 val | TADA | NS | — | — | |
| Mašinos laikmenų sąrašas informacija |
VM* | IR APIE | — | NS | — | |
| Įvesties duomenų masyvas | 6 val | IR APIE | — | NS | — | |
| RD | Duomenų bazės katalogas | 7 val | IR APIE | — | NS | — |
| Išvesties sudėtis (žinutės) |
8 val | IR APIE | — | NS | — | |
| Vietiniai skaičiavimai | B3 | ARBA | NS | — | — | |
| Metodas (technologija) automatizuotas projektavimas |
I1 | OO | — | NS | — | |
| Technologinis mokymas | IR 2 | OO | — | NS | — | |
| Naudotojo gidas | I3 | OO | — | NS | — | |
| Formavimo instrukcijos ir duomenų bazės priežiūra (duomenų rinkinys) |
I4 | IR APIE | — | NS | — | |
| KTS naudojimo instrukcijos | T.Y | TADA | — | NS | — | |
| Išorinių laidų prijungimo schema | C4* | TADA | NS | — | Leidžiama koncertuoti lentelių pavidalu |
|
| Sujungimo schema išoriniai laidai |
C5* | TADA | NS | — | Taip pat | |
| Sujungimas ir pajungimo lentelė | C6 | TADA | NS | — | — | |
| Sistemos padalijimo schema (struktūrinis) |
E1* | TADA | — | — | — | |
| Bendras išdėstymo brėžinys | IN* | TADA | NS | — | — | |
| Techninės įrangos montavimo brėžinys | CA | TADA | NS | — | — | |
| Schema | Šešt | TADA | NS | — | — | |
| Komplekso struktūrinė schema techninėmis priemonėmis |
C1* | TADA | NS | — | — | |
| Įrangos ir laidų išdėstymas | C7 | TADA | NS | — | — | |
| Technologijų aprašymas apdorojimo procesas duomenis (įskaitant nuotolinis apdorojimas) |
PG | OO | — | NS | — | |
| Bendras sistemos aprašymas | PD | ARBA | — | NS | — | |
| Testavimo programa ir metodika (komponentai, automatizavimo sistemos, posistemės, sistemos) |
PM* | ARBA | — | — | — | |
| Forma | FD* | ARBA | — | NS | — | |
| Pasas | PS* | ARBA | — | NS | — | |
| * Dokumentai, kurių kodas nustatytas pagal ESKD standartų reikalavimus | ||||||
Pastaba prie lentelės:
- Lentelėje naudojami šie pavadinimai:
- EP - preliminarus projektas;
- TP - techninis projektas;
- RD – darbo dokumentacija;
- ARBA – visos sistemos sprendimai;
- OO - sprendimai dėl organizacijos paramos;
- TO – techninės pagalbos sprendimai;
- IO – informacinio palaikymo sprendimai;
- Programinė įranga – programiniai sprendimai;
- MO – programiniai sprendimai.
- X ženklas – žymi priklausymą projektinėms sąmatoms arba eksploatacinei dokumentacijai.
- Vieno pavadinimo dokumentų nomenklatūra nustatoma priklausomai nuo projektavimo sprendimų, priimtų kuriant sistemą.
Kai yra nustatytas dokumentų sąrašas, tada RD 50-34.698-90 turėtumėte rasti pasirinktus dokumentus ir juos parengti griežtai pagal nurodytus punktus. Visi nurodyti turinio taškai turi būti dokumente.
Jei kuriamos techninės užduotys, turite nedelsdami atidaryti GOST 34.602-89 ir parengti techninę specifikaciją griežtai pagal pastraipas.
GOST 19
GOST 19 seriją (GOST 19.xxx Vieningoji programavimo dokumentavimo sistema (ESPD)) sudaro:
- GOST 19.001-77 Bendrosios nuostatos - pernelyg bendras dokumentas, tai nepraktiška. Todėl galite tai praleisti.
- GOST 19781-90 Terminai ir apibrėžimai - geras sąrašas Apibrėžimai informacijos apdorojimo sistemų programinės įrangos srityje. Išskyrus apibrėžimus, jame nėra nieko kito.
- GOST 19.101-77 Programų tipai ir programos dokumentai - vienas iš pagrindinių 19 GOST dokumentų. Būtent su juo turėtumėte pradėti dirbti su 19 GOST, nes jame yra visas GOST dokumentų sąrašas ir pavadinimai.
Dokumentų sąrašas 19 GOST
| Kodas | Dokumento tipas | Vystymosi etapai | |||
| Eskizas projektą |
Techninė projektą |
Darbinis juodraštis | |||
| komponentas | kompleksas | ||||
| — | Specifikacija | — | — | ||
| 05 | Originalių laikiklių sąrašas | — | — | — | |
| 12 | Programos tekstas | — | — | ||
| 13 | Programos aprašymas | — | — | ||
| 20 | Veiklos dokumentų išrašas | — | — | ||
| 30 | Forma | — | — | ||
| 31 | Programos aprašymas | — | — | ||
| 32 | Sistemos programuotojo vadovas | — | — | ||
| 33 | Programuotojo vadovas | — | — | ||
| 34 | Naudotojo vadovas | — | — | ||
| 35 | Kalbos aprašymas | — | — | ||
| 46 | Techninis vadovas priežiūra |
— | — | ||
| 51 | Testo programa ir metodika | — | — | ||
| 81 | Aiškinamasis raštas | — | — | ||
| 90-99 | Kiti dokumentai | ||||
Legenda:
- dokumentas yra privalomas;
- dokumentas yra privalomas komponentams, kurie turi nepriklausomą taikymą;
- būtinybė rengti dokumentą nustatoma techninės užduoties rengimo ir tvirtinimo etape;
- - dokumentas nesurašytas.
- GOST 19.102-77 Kūrimo etapai - yra kūrimo etapų aprašymas. Naudinga edukaciniais tikslais. Mano nuomone, tai neduoda ypatingos praktinės naudos.
- GOST 19.103-77 Programų ir programos dokumentų pavadinimai - yra numerio (kodo) priskyrimo dokumentui aprašymas. Net ir perskaičius šį GOST, lieka krūva klausimų, kaip dokumentui priskirti būtent šį numerį.
- GOST 19.104-78 Pagrindiniai užrašai - nustato patvirtinimo lapo ir titulinio lapo pagrindinių įrašų formas, dydžius, vietą ir užpildymo tvarką programos dokumentuose, numatytuose ESDM standartuose, neatsižvelgiant į jų vykdymo būdą. Kadangi 19 GOST dokumentai yra surašyti rėmeliuose, šis dokumentas yra labai svarbus.
- GOST 19.105-78 Bendrieji programos dokumentų reikalavimai – nustato bendruosius programos dokumentų rengimo reikalavimus. Reikalavimai pernelyg bendri. Paprastai šis GOST beveik niekada nenaudojamas kuriant dokumentą, nes dokumentui yra pakankamai specialaus GOST, tačiau norint gauti bendrų žinių apie šį GOST, vis tiek geriau pažvelgti vieną kartą.
- GOST 19.106-78 Reikalavimai spausdintiems programinės įrangos dokumentams - yra visų GOST 19 dokumentų projektavimo reikalavimai.
- GOST 19.201-78 Techninė užduotis, reikalavimai turiniui ir dizainui - nustato programos ar programinės įrangos produkto kūrimo techninių specifikacijų konstravimo ir vykdymo tvarką.
GOST 34 TK ir GOST 19 punktai skiriasi.
- GOST 19.601-78 Bendrosios dauginimo, apskaitos ir saugojimo taisyklės - Bendrosios taisyklės programinių dokumentų dauginimas, apyvarta, apskaita ir saugojimas. GOST keliose pastraipose aprašyta, kaip įsitikinti, kad dokumentai nėra prarasti.
- GOST 19.602-78 Programinių dokumentų dauginimo, apskaitos ir saugojimo taisyklės, baigtas spausdinimas. Tam tikra prasme - GOST 19.601-78 papildymas.
- GOST 19.603-78 Bendrosios pakeitimų taisyklės - nustato bendrąsias programos dokumentų pakeitimų taisykles. Iš esmės jame aprašomas ilgas biurokratinis dokumentų pakeitimų algoritmas.
- GOST 19.604-78 Programos dokumentų, padarytų spausdintu būdu, pakeitimų taisyklės - aprašoma pakeitimų registracijos lapo iš sąrašo darbo ir pildymo tvarka.
Specializuotų GOST sąrašas, tai yra, kiekvienas iš jų apibūdina konkretaus dokumento turinį ir reikalavimus:
- GOST 19.202-78 Specifikacija. Reikalavimai turiniui ir dizainui;
- GOST 19.301-79 Programa ir bandymo procedūra. Reikalavimai turiniui ir dizainui;
- GOST 19.401-78 Programos tekstas. Reikalavimai turiniui ir dizainui;
- GOST 19.402-78 Programos aprašymas;
- GOST 19.403-79 Originalių laikiklių sąrašas;
- GOST 19.404-79 Aiškinamasis raštas. Reikalavimai turiniui ir dizainui;
- GOST 19.501-78 forma. Reikalavimai turiniui ir dizainui;
- GOST 19.502-78 Taikymo aprašymas. Reikalavimai turiniui ir dizainui;
- GOST 19.503-79 sistemos programuotojo vadovas. Reikalavimai turiniui ir dizainui;
- GOST 19.504-79 programuotojo vadovas. Reikalavimai turiniui ir dizainui;
- GOST 19.505-79 Naudotojo vadovas. Reikalavimai turiniui ir dizainui;
- GOST 19.506-79 Kalbos aprašymas. Reikalavimai turiniui ir dizainui;
- GOST 19.507-79 Eksploatacinių dokumentų išrašas;
- GOST 19.508-79 Priežiūros vadovas. Reikalavimai turiniui ir dizainui.
Darbo su 19 GOST procedūra:
- GOST 19.101-77 pasirinkite dokumentą ir jo kodą pagal kūrimo etapą.
- Pagal GOST 19.103-77, priskirkite dokumentui numerį.
- Tada pagal GOST 19.104-78 ir 19.106-78 surašykite dokumentą.
- Iš specializuoto GOST sąrašo turėtumėte pasirinkti tą, kuris atitinka kuriamą dokumentą.
Išvada
GOST nėra baisu ir lengva! Svarbiausia suprasti, ką reikia parašyti ir kas tam naudojamas GOST. Mūsų pagrindiniai GOST 19 ir 34, skirti dokumentacijai rašyti, yra labai seni, tačiau vis dar aktualūs iki šių dienų. Dokumentacijos rašymas pagal standartą pašalina daug klausimų tarp rangovo ir užsakovo. Todėl sutaupoma laiko ir pinigų.
Įvedimo data 92.01.01
Šis standartas taikomas automatizuotoms sistemoms (AS). skirtingi tipai organizacijose, asociacijose ir įmonėse (toliau – organizacijos) sukurtos veiklos (tyrimų, projektavimo, vadybos ir kt.), įskaitant jų derinius.
Standartas nustato garsiakalbio kūrimo etapus ir etapus. 1 priede pateikiamas kiekvieno etapo darbo turinys.
1. Bendrosios nuostatos
2. Pranešėjo kūrimo etapai ir etapai
1 priedas (nuoroda)
2 priedas (nuoroda)
1. BENDROSIOS NUOSTATOS
1.1. yra laike sutvarkytų, tarpusavyje susijusių, etapais ir darbo etapais vienijamų visuma, kurią įgyvendinti būtina ir pakanka, kad būtų sukurtas nurodytus reikalavimus atitinkantis AS.
1.2. AS kūrimo etapai ir etapai išskiriami kaip kūrimo proceso dalis racionalaus darbo planavimo ir organizavimo sumetimais, baigiant duotu rezultatu.
1.3. AS plėtros darbas atliekamas pagal AS kūrimo etapus ir etapus.
1.4. Šio standarto nustatytų etapų ir etapų darbų sudėtis ir atlikimo taisyklės nustatomos atitinkamuose organizacijų, dalyvaujančių kuriant konkrečių tipų atomines elektrines, dokumentuose.
Organizacijų, dalyvaujančių kuriant AS, sąrašas pateiktas 2 priede.
2. AU KŪRIMO ETAPAI IR ETAPAI
2.1. AU kūrimo etapai ir etapai bendruoju atveju pateikti lentelėje.
| Etapai | Darbo etapai |
|---|---|
| 1. Reikalavimų AS formavimas | 1.1. Vietos apžiūra ir atominės elektrinės kūrimo būtinumo pagrindimas |
| 1.2. Vartotojo reikalavimų garsiakalbiui formavimas | |
| 1.3. Ataskaitos apie atliktus darbus ir paraiškos AU rengimui registravimas (taktinė ir techninė užduotis) | |
| 2. AS koncepcijos kūrimas | 2.1. Objekto tyrimas |
| 2.2. Būtinų tiriamųjų darbų atlikimas | |
| 2.3. Garsiakalbio koncepcijos variantų kūrimas ir vartotojo poreikius tenkinančios kolonėlės koncepcijos versijos parinkimas | |
| 2.4. Atliktų darbų ataskaitos registravimas | |
| 3. Darbo sąlygos | 3.1. AS kūrimo techninių specifikacijų rengimas ir tvirtinimas |
| 4. Projekto projektas | 4.1. Sistemos ir jos dalių preliminaraus projektavimo sprendinių kūrimas |
| 4.2. AE ir jos dalių dokumentacijos rengimas | |
| 5. Techninis projektas | 5.1. Sistemos ir jos dalių projektinių sprendimų kūrimas |
| 5.2. AE ir jos dalių dokumentacijos rengimas | |
| 5.3. Gaminių tiekimo atominėms elektrinėms užbaigimui ir (ar) techninių reikalavimų (techninių specifikacijų) jų kūrimo dokumentacijos rengimas ir vykdymas. | |
| 5.4. Projektavimo užduočių rengimas susijusiose automatikos objekto projekto dalyse | |
| 6. Darbo dokumentacija | 6.1. Sistemos ir jos dalių darbinės dokumentacijos rengimas |
| 6.2. Programų kūrimas ar pritaikymas | |
| 7. Įgyvendinimas | 7.1. Automatikos objekto parengimas AE paleidimui |
| 7.2. Personalo mokymas | |
| 7.3. Garsiakalbių sistemos komplektavimas su pateiktais produktais (programine ir technine įranga, programinės ir techninės įrangos kompleksais, informaciniais produktais) | |
| 7.4. Statybos ir montavimo darbai | |
| 7.5. Paleidimo darbai | |
| 7.6. Preliminarūs testai | |
| 7.7. Bandomoji operacija | |
| 7.8. Priėmimo testai | |
| 8. AS akompanimentas | 8.1. Darbų atlikimas pagal garantinius įsipareigojimus |
| 8.2. Pogarantinis aptarnavimas |
2.2. Etapai ir etapai, kuriuos atlieka organizacijos - AS kūrimo darbo dalyviai, nustatomi sutartyse ir įgaliojimuose, remiantis šiuo standartu.
Leidžiama išskirti etapą „Projektavimas“ ir atskirus darbo etapus visuose etapuose, sujungti etapus „Techninis projektas“ ir „Darbinė dokumentacija“ į vieną etapą „Techninis projektas“. Atsižvelgiant į kuriamų branduolinių sistemų specifiką ir jų kūrimo sąlygas, atskirus darbų etapus leidžiama atlikti iki ankstesnių etapų užbaigimo, lygiagrečiai laiku atliekant darbų etapus, įtraukiant naujus darbo etapus. .
1 PRIEDAS Nuoroda
1. 1.1 etape „Įrenginio apžiūra ir atominės elektrinės kūrimo būtinumo pagrindimas“ bendruoju atveju atlikti:
- duomenų apie automatikos objektą ir vykdomas veiklas rinkimas;
- objekto ir vykdomos veiklos kokybės įvertinimas, problemų, kurių sprendimas įmanomas automatizavimo priemonėmis, nustatymas;
- AS kūrimo galimybių įvertinimas (techninis, ekonominis, socialinis ir kt.).
2. 1.2 etape "Naudotojų reikalavimų AS formavimas" atlikite:
- pradinių duomenų rengimas reikalavimams atominei elektrinei formuoti (automatizacijos objekto charakteristikos, reikalavimų sistemai aprašymas, leistinų plėtros, paleidimo ir eksploatacijos sąnaudų ribojimas, sistemos laukiamas poveikis, sąlygos sistemos kūrimas ir veikimas);
- naudotojų reikalavimų AS formulavimas ir vykdymas.
3. 1.3 etapu „Atliktų darbų ataskaitos ir prašymo parengti AS (taktinė ir techninė užduotis) vykdymas“ surašomas šiame etape atliktų darbų aktas ir paraiška parengti surašomas panašaus turinio AU (taktinė ir techninė užduotis) arba kitas jį pakeičiantis dokumentas.
4. 2.1 etapuose „Objekto tyrimas“ ir 2.2 „Būtinų tyrimo darbų atlikimas“ kūrėjo organizacija atlieka išsamią automatizavimo objekto studiją ir reikalingus tyrimo darbus (MTEP), susijusius su būdų paieška ir galimybių įvertinimu. įgyvendinti vartotojų reikalavimus, rengti ir tvirtinti tyrimų ataskaitas.
5. 2.3 etape „AS koncepcijos variantų kūrimas ir vartotojo reikalavimus atitinkančios AS koncepcijos varianto parinkimas“, bendru atveju, 2010 m. alternatyvių variantų kuriamos AS koncepcija ir jų įgyvendinimo planai; įvertinimas būtinų išteklių už jų įgyvendinimą ir funkcionavimo palaikymą; kiekvienos galimybės privalumų ir trūkumų įvertinimas; vartotojų reikalavimų ir siūlomos sistemos charakteristikų palyginimas bei pasirinkimas geriausias variantas; sistemos kokybės vertinimo tvarkos ir priėmimo sąlygų nustatymas; sistemos gauto poveikio įvertinimas.
6. 2.4 etape „Atliktų darbų ataskaita“ parengti ir surašyti ataskaitą, kurioje aprašytas etape atliktas darbas, pasiūlytos sistemos koncepcijos varianto aprašymas ir pagrindimas.
7. 3.1 etape „AE kūrimo techninių užduočių rengimas ir tvirtinimas“ – AE techninės užduoties ir, jei reikia, dalies techninės užduoties rengimas, vykdymas, derinimas ir tvirtinimas. vykdomos AE.
8. 4.1 etape "Sistemos ir jos dalių preliminaraus projektavimo sprendinių rengimas" nustato: AS funkcijas; posistemių funkcijos, jų tikslai ir poveikis; užduočių kompleksų ir individualių užduočių sudėtis; informacinės bazės samprata, išplėsta jos struktūra; duomenų bazių valdymo sistemos funkcijos; skaičiavimo sistemos sudėtis; pagrindinės programinės įrangos funkcijos ir parametrai.
9. 5.1 etape „Sistemos ir jos dalių projektinių sprendinių kūrimas“ pateikti bendruosius sistemos ir jos dalių sprendinius, sistemos funkcinę ir algoritminę struktūrą, personalo ir jos dalių funkcijas. organizacinė struktūra, techninių priemonių struktūra, problemų sprendimo algoritmais ir vartojamomis kalbomis, informacinės bazės organizavimu ir priežiūra, informacijos klasifikavimo ir kodavimo sistema, programine įranga.
10. 4.2 ir 5.2 etapuose Dokumentacijos rengimas AE ir jos dalyse „atlieka dokumentacijos kūrimą, vykdymą, derinimą ir tvirtinimą tiek, kiek reikia visam priimtų projektinių sprendinių rinkiniui aprašyti ir kurio pakaktų tolesniam AE kūrimo darbui. Dokumentų rūšys – pagal GOST 34.201.
11. 5.3 etape "Produktų tiekimo AE užbaigimui ir (ar) techninių reikalavimų (techninių specifikacijų) jų rengimui rengimas ir įforminimas" rengia ir įformina gaminių tiekimo AE užbaigimui dokumentaciją; techninių reikalavimų nustatymas ir techninių specifikacijų rengimas gaminiams, kurie nėra gaminami masiškai, kūrimui.
12. 5.4 etape „Projektavimo užduočių rengimas gretimose automatikos projekto dalyse“ atlikti projektavimo užduočių rengimą, vykdymą, tvirtinimą ir tvirtinimą gretimose automatikos objekto dalyse statybos, elektros, sanitarinių ir kitų parengiamųjų darbų, susijusių su kūrimas AC.
13. 6.1 etape „Sistemos ir jos dalių darbinės dokumentacijos rengimas“ rengiama darbo dokumentacija, kurioje yra visa reikalinga ir pakankama informacija, užtikrinanti AE paleidimo ir eksploatavimo darbų atlikimą bei techninę priežiūrą. sistemos eksploatacinių charakteristikų (kokybės) lygis pagal priimtus projektinius sprendimus, jo registravimas, derinimas ir tvirtinimas. Dokumentų rūšys – pagal GOST 34.201.
14. 6.2 etape „Programų kūrimas ar pritaikymas“ kuriamos sistemos programos ir programinė įranga, įsigytos programinės įrangos parinkimas, pritaikymas ir (ar) įrišimas, programinės įrangos dokumentacijos kūrimas pagal GOST 19.101.
15. 7.1 etape „Automatizacijos objekto parengimas AE paleidimui“ yra vykdomi organizacinio automatikos objekto parengimo AE paleidimui darbai, įskaitant: AE organizacinės struktūros projektinių sprendinių įgyvendinimą; Valdymo objekto padalinių aprūpinimas mokomąja ir metodine medžiaga; informacijos klasifikatorių įvedimas.
16. 7.2 etape „Personalo mokymas“ apmokomi darbuotojai ir tikrinamas jų gebėjimas užtikrinti AE veiklą.
17. Etape „AU komplektavimas su tiekiama produkcija“ užtikrinti serijinės ir vienetinės gamybos komponentų, medžiagų ir surinkimo gaminių priėmimą. Jie atlieka gaunamos kokybės kontrolę.
18. 7.4 etape „Statybos ir montavimo darbai“ atliekami: specializuotų pastatų (patalpų), skirtų techninei įrangai ir AE personalui išdėstyti, statybos darbai; kabelinių kanalų tiesimas; techninių priemonių ir ryšių linijų įrengimo darbų vykdymas; sumontuotos techninės įrangos testavimas; techninių priemonių paleidimui pristatymas.
19. 7.5 etape „Paleidimas“ atlikti autonominį techninės ir programinės įrangos derinimą, įkelti informaciją į duomenų bazę ir tikrinti sistemos priežiūrą; kompleksinis visų sistemos priemonių reguliavimas.
20. 7.6 etape "Preliminarūs bandymai" atlikti:
- atominės elektrinės darbingumo ir techninės užduoties atitikties bandymai pagal išankstinių bandymų programą ir metodą;
- gedimų šalinimas ir AE dokumentacijos, įskaitant eksploatacinę, keitimas pagal bandymų ataskaitą;
- atominės elektrinės priėmimo bandomajam eksploatavimui pažymėjimo įregistravimas.
21. 7.7 etape „Bandomoji eksploatacija“ vykdomas bandomasis AE eksploatavimas; AE eksperimentinės veiklos rezultatų analizė; kintamosios srovės programinės įrangos peržiūra (jei reikia); papildomas (jei reikia) atominės elektrinės techninių priemonių koregavimas; bandomosios operacijos atlikimo pažymėjimo įregistravimas.
22. 7.8 etape „Priėmimo testai“ atlikti:
- techninės užduoties atitikties bandymai pagal priėmimo testų programą ir būdus;
- AU tyrimų rezultatų analizė ir bandymų metu nustatytų trūkumų pašalinimas;
- atominės elektrinės priėmimo nuolatiniam eksploatuoti pažymėjimo įregistravimas.
23. 8.1 etape „Darbų atlikimas pagal garantinius įsipareigojimus“ atliekami darbai, siekiant nustatytais garantiniais terminais pašalinti AE eksploatacijos metu nustatytus trūkumus, atlikti būtinus AE dokumentacijos pakeitimus.
24. 8.2 etape „Pogarantinis aptarnavimas“ atliekami darbai:
- sistemos veikimo analizė;
- faktinių AE eksploatacinių charakteristikų nukrypimų nuo projektinių verčių nustatymas;
- šių nukrypimų priežasčių nustatymas;
- nustatytų trūkumų pašalinimas ir AE eksploatacinių charakteristikų stabilumo užtikrinimas;
- atlikti būtinus AU dokumentų pakeitimus.
PRIEDAS 2. Nuoroda
ORGANIZACIJŲ, DALYVAUJANČIŲ AS KŪRIMO DARBE, SĄRAŠAS
1. Organizacija-užsakovas (naudotojas), kuriam bus kuriama AE ir kuri teikia finansavimą, darbų priėmimą ir AE eksploatavimą bei individualių darbų AE kūrimui atlikimą.
2. Organizacija-kūrėjas, vykdantis AS kūrimo darbus, teikiantis užsakovui mokslinių ir techninių paslaugų kompleksą skirtingi etapai ir kūrimo etapai, taip pat įvairios programinės ir techninės įrangos kūrimas ir tiekimas AU.
3. Tiekėjo organizacija, gaminanti ir tiekianti programinę ir techninę įrangą kūrėjo ar kliento prašymu.
4. Organizacija-generalinis automatikos objekto projektuotojas.
5. Projektavimo organizacijos skirtingos dalys statybos, elektros, sanitarinių ir kitų parengiamųjų darbų, susijusių su atominės elektrinės kūrimu, automatikos objekto projektas.
6. Statybos, surinkimo, paleidimo ir kitos organizacijos.
Pastabos:
1. Priklausomai nuo AS kūrimo sąlygų, galimi įvairūs užsakovo, kūrėjo, tiekėjo ir kitų su AS kūrimu susijusių organizacijų funkcijų deriniai.
2. Jų AS kūrimo etapai ir etapai nustatomi remiantis šiuo standartu.
INFORMACINIAI DUOMENYS
1. SUGRĘŽTA IR ĮVEŽA SSRS Valstybinis gaminių kokybės valdymo ir standartų komitetas
KŪRĖJAI
Yu.Kh. Vermiševas, dr. mokslai; Ya.G. Vilenčikas; Į IR. Voropajevas, dr. mokslai; L.M. Seidenbergas, Cand. tech. mokslai; Yu.B. Irz, Cand. tech. mokslai; V.D. Kostjukovas, Cand. tech. mokslai; M.A. Labutinas, vad. tech. mokslai; N.P. Leskovskaja; I.S. Mityajevas; V.F. Popovas (temos vadovas); S.V. Garšina; A.I. Kurtieji tikintys; PIETUS. Žukovas, Cand. Tech. mokslai; Z.P. Zadubovskaja; V.G. Ivanovas; Yu.I Karavanovas, Cand. Tech. mokslai; A.A. Susmulkinti; V.Yu. Korolevas; Į IR. Makhnachas, Cand. tech. mokslai; S. B. Michalevas, dr. mokslai; V.N. Petrikevičius; V.A. Rachmanovas, Cand. ekonominis. mokslai; A.A. Ratkovičius; R.S. Sedegovas, dr. mokslai; N.V. Stepančikova; M.S. Surovets; A.V. Fleents; L.O. Khvilevskis, Cand. tech. mokslai; VC. Chistovas, Cand. ekonominis. mokslai
2. PATVIRTINTA IR ĮVEŽTA TSRS Valstybinio gaminių kokybės valdymo ir standartų komiteto 1990 m. gruodžio 29 d. dekretu Nr. 3469
