Standarde pentru sisteme automate și tehnologii informaționale. Teste de acceptare a sistemelor automate de control. Ce sunt standardele de documentare?

Astăzi vom vorbi despre standardele interne pentru documentația de proiectare. Cum funcționează aceste standarde în practică, de ce sunt rele și de ce sunt bune. Atunci când dezvoltăm documentație pentru guvern și clienți privați serioși, de obicei nu avem de ales - conformitatea cu standardele este inclusă în cerințele pentru documentarea specificațiilor tehnice. În practică, am întâlnit diverse exemple de neînțelegere a structurii standardelor, ce ar trebui să fie în documente și de ce sunt necesare aceste documente. Drept urmare, pixurile scriitorilor tehnici, analiștilor și specialiștilor produc uneori astfel de pietre prețioase încât nu este clar în ce stare de conștiință au fost scrise. Dar, de fapt, totul este destul de simplu. O căutare pe Habr nu a returnat niciun link către material mai mult sau mai puțin complet pe această temă, așa că îmi propun să umplem acest gol enervant.

Ce sunt standardele de documentare?

În seria 34 în cauză, există doar 3 standarde principale de documentare:

Cel mai iubit și popular standard pentru dezvoltarea specificațiilor tehnice. Singurul lucru pe care nu trebuie să-l uitați este că este strâns legat de alte standarde ale seriei și, dacă ați primit specificații tehnice realizate conform acestui standard, este foarte recomandabil să respectați alte standarde, chiar dacă nu există cerințe directe. pentru aceasta. Cel puțin în ceea ce privește ideologie generală(mai multe despre care mai jos)

Acesta este documentul de bază care oferă lista plina Documentația GOST 34, recomandări pentru codificarea documentelor, la ce etape ale proiectului aparțin documentele (etapele sunt descrise în GOST 34.601-90) și, de asemenea, cum pot fi combinate între ele.

De fapt, acest standard este un tabel mare cu comentarii. Poate fi pus în Excel pentru ușurință în utilizare.

Un standard voluminos care descrie conținutul documentelor de proiect cu diferite grade de detaliu. GOST 34.201-89 menționat mai sus este folosit ca index.

Există multe întrebări și interpretări ale prevederilor acestuia cu privire la standardul RD 50-34.698-90, care, datorită vagului lor, sunt adesea înțelese diferit de către client și antreprenor, sau chiar membrii echipei de proiect. Dar, din păcate, nu avem nimic mai concret.

Să luăm acum în considerare avantajele și dezavantajele standardelor, începând în mod tradițional cu dezavantajele.

Dezavantajele standardelor

Principalul dezavantaj este evident pentru toată lumea - standardele sunt vechi. Ele conțin o idee învechită a arhitecturii unui sistem automatizat. De exemplu:

• aplicații pe două niveluri, constând dintr-un program client și un server DBMS (fără trei sau mai multe aplicații „nivel”, fără Weblogic sau JBoss)
• structura tabelelor bazei de date, fiind descrisă, va da o idee despre modelul logic de date (faptul că ar putea exista un fel de Hibernare între aplicație și baza de date părea un exces rău atunci)
• interfața cu utilizatorul este cu o singură fereastră (mai există ceva? Ce este un „browser”?)
• Există puține rapoarte în sistem; toate sunt pe hârtie și tipărite pe o imprimantă cu matrice de puncte.
• Programul în curs de dezvoltare este axat pe rezolvarea „problemei de procesare a informațiilor”, care are o intrare și o ieșire clare și este foarte specializată. Procesarea informațiilor se bazează pe un „algoritm”. Uneori există mai mulți „algoritmi”. (Programarea orientată pe obiecte făcea atunci doar primii pași și nu a fost luată în considerare în mod serios).
• administratorul bazei de date înțelege ce informații sunt în tabele și participă activ la editarea directoarelor sistemului (există într-adevăr un server DBMS pentru 50 de aplicații diferite?)

În consecință, standardul are artefacte precum următoarele:

5.8. Desenul formularului de document (cadru video)
Documentul trebuie să conțină o imagine a formei documentului sau a cadrului video în conformitate cu cerințele standardele de stat sistem de documentare unificat R 50-77 si explicatii necesare.

Ideea documentului este că întreprinderile sovietice foloseau așa-numitele „zone de imprimare”, unde existau imprimante matrice de mare viteză, driverele pentru care erau adesea scrise de către inginerii înșiși. Prin urmare, au trebuit să mențină un registru cu toate documentele care trebuiau tipărite pentru a se asigura că documentele arată așa cum ar trebui la imprimare.

„Cadru video” este, de asemenea, un document care a fost afișat pe un afișaj text. Ecranele nu au acceptat întotdeauna caracterele necesare și numărul necesar de caractere orizontale și linii verticale (și nu au suportat deloc grafice). Prin urmare, și aici a fost necesară coordonarea suplimentară a formularelor tuturor documentelor de ecran.

Acum cuvintele „machineogramă”, „cadru video”, „ADC” nu ne mai spun nimic. Nici eu nu le-am găsit în uz, deși am absolvit un institut de specialitate în anii 90. Acesta a fost momentul apariției Windows 3.1, a ecranelor VGA, a dischetelor de trei inci și a primelor site-uri de internet interne. Dar aceste cuvinte sunt în standard, iar clientul solicită uneori capricios să îi oferim un set complet de documentație în conformitate cu GOST 34.201-89. Mai mult, astfel de formulări din ToR migrează de la un minister la altul și au devenit deja un fel de șablon nerostit în care este introdus conținutul.

Deci, documentul cu numele stupid „Desenul formularului de document (cadru video)” din proiect ar trebui și nu trebuie să fie gol.

Ce este bun în standard

Orice standard este bun prin faptul că permite clientului și contractantului să vorbească aceeași limbă și oferă o garanție că, cel puțin, clientul nu va avea nicio reclamație „în formă” la rezultatele transmise.

Și standardele GOST 34 sunt, de asemenea, bune pentru că au fost compilate oameni destepti, au fost testate de ani de zile și au un scop clar – să descrie cât mai complet pe hârtie entitatea abstractă complexă pe care o reprezintă orice sistem de control automatizat.

Când trebuie să stabiliți cu competență o sarcină pentru contractorii occidentali care nu au auzit niciodată de standardele noastre GOST, vă puteți baza și pe aceste standarde, sau mai degrabă pe conținutul și componenta semantică a acestora. Pentru că, repet, garanția completității informațiilor valorează mult. Oricât de mult ne-am consola nivel inalt profesionalismul nostru, este posibil să uităm să includem lucruri elementare în cerințele noastre, în timp ce același GOST 34.602-89 „îți amintește” totul. Dacă nu vă este clar cum ar trebui să arate rezultatul muncii antreprenorilor occidentali, uitați-vă la cerințele de documentare și la secțiunile recomandate. Te asigur, e mai bine să nu te gândești la asta! Cel mai probabil, există analogi occidentali ai standardelor noastre, în care totul poate fi mai complet, mai modern și mai bun. Din păcate, nu sunt familiarizat cu ele, deoarece nu a existat încă un singur caz în care standardele noastre GOST nu au fost suficiente.

Puteți râde de faptul că creatorii de standarde nu știau nimic despre java sau .NET, despre monitoare HD și Internet, dar nu aș sfătui să subestimați amploarea muncii pe care le-au făcut și valoarea acesteia pentru comunitatea noastră profesională.

Cum să citiți și să înțelegeți standardele de documentare conform GOST seria 34

Standardul împarte toate documentele pe două axe - timp și domeniu. Dacă vă uitați la Tabelul 2 din GOST 34.201-89, puteți vedea clar această diviziune (coloanele „Etapa de creare” și „Parte din proiect”

Etapele creării unui sistem de control automatizat

Etapele creației sunt definite în GOST 34.601-90. Trei dintre ele sunt relevante pentru documentare:

• Proiect de proiect (ED)
• Proiectare tehnică (TP)
• Elaborarea documentației de lucru (DD)

Proiectare preliminară urmează după etapa Specificațiilor tehnice și servește la dezvoltarea soluțiilor preliminare de proiectare.

Proiect tehnic descrie viitorul sistem din toate unghiurile. Documentele aflate în etapa de TP ar trebui, după citire, să lase în urmă o claritate deplină în abordările, metodele, soluțiile arhitecturale și tehnice propuse. La următoarea fază va fi prea târziu pentru a descrie abordările și a justifica solutii tehnice, deci faza P este cheia pentru finalizarea cu succes lucrări, întrucât toată varietatea cerințelor tehnice trebuie să se reflecte în documentele fazei P. La faza P este posibil ca sistemul să nu existe deloc.

Documentatie de lucru conceput pentru implementare cu succes, punere în funcțiune și funcționare continuă sistem nou. Acestea sunt documente care conțin informații foarte specifice care descriu entități existente fizic, spre deosebire de faza P, care descrie splendoarea viitoare.

Părți (secțiuni) ale documentației de proiect pentru crearea unui sistem de control automatizat

Tematica este împărțită în „Dispoziții”. La început se pare că o astfel de împărțire este redundantă și inutilă. Dar când începeți să lucrați cu acest set de instrumente în practică, ideologia încorporată în el devine treptat clară.

Un sistem automatizat, așa cum este definit de compilatorii GOST, este o combinație de hardware, software și canale de comunicare care prelucrează informații provenind din diferite surse în conformitate cu anumiți algoritmi și produce rezultate de prelucrare sub formă de documente, structuri de date sau acțiuni de control. Un model primitiv al celei mai simple mitraliere.

Pentru a descrie pe deplin această „mașină”, sunt realizate următoarele secțiuni (ca în desen):

Software (MS), răspunzând la întrebările: ce logică este conectată în interiorul „cutiei negre”? De ce au fost aleși acești algoritmi, formulele și coeficienții?

Software-ul matematic nu știe nimic despre procesoare sau baze de date. Aceasta este o zonă abstractă separată, locuința „cailor sferici în vid”. Dar software-ul matematic poate fi foarte strâns legat de domeniul subiectului, adică Viata reala. De exemplu, algoritmi de control pentru sistemele de control trafic trebuie să fie aprobate de poliția rutieră înainte de a fi aprobate de client. Și atunci înțelegeți de ce sunt incluse într-o carte separată. Pentru că nimeni din poliția rutieră nu este interesat de ce sistem de operare va rula serverul de aplicații, dar ce semn și limita de viteză vor apărea pe tablă în ploaie sau zăpadă este foarte interesant. Ei sunt responsabili pentru partea lor și nu vor semna nimic altceva. Pe de altă parte, atunci când au semnat, nu vor fi întrebări despre latura tehnică a problemei - de ce au ales acele panouri sau semafoare și nu altele. Înțelepciunea „strămoșilor” se manifestă tocmai în astfel de cazuri practice.

Suport informațional (IS). O altă porțiune din sistem. De data aceasta, cutia neagră a sistemului nostru este transparentă și ne uităm la informațiile care circulă în ea. Imaginați-vă un model sistem circulator a unei persoane când toate celelalte organe sunt invizibile. Ceva de genul acesta este Suportul de informații. Descrie compoziția și rutele fluxului de informații în interior și în exterior, organizarea logică a informațiilor în sistem, o descriere a cărților de referință și a sistemelor de codificare (cei care au realizat programe pentru producție știu cât de importante sunt acestea). Partea descriptivă principală se încadrează în etapa TP, dar unele „rudimente” curg în etapa RD, cum ar fi documentul „Catalog baze de date”. Este clar că anterior conținea exact ceea ce este scris în titlu. Dar astăzi, încercați să creați un astfel de document pentru un sistem complex complex, când de foarte multe ori sistemul utilizează subsisteme achiziționate cu propriile lor depozite de informații misterioase. Nici măcar nu spun că acest document nu este deosebit de necesar acum.

Sau aici este „Declarația despre mediile de stocare a computerului”. Este clar că anterior conținea un număr de tobe magnetice sau bobine de film. Acum ce ar trebui să pun acolo?

Pe scurt, în faza RD, documentele Suport Informațional reprezintă un rudiment destul de nociv, întrucât formal ar trebui să existe, dar nu este nimic special cu care să le umplem.

Software. Partea preferată a tuturor din documentația proiectului. Da, fie doar pentru că este doar un document! Și apoi, toată lumea înțelege ce trebuie scris acolo. Dar o voi repeta oricum.

În acest document, trebuie să vă spunem cu ajutorul cărui software sunt executați algoritmii descriși în ML, procesând informațiile descrise în IR. Adică, nu este nevoie să duplicați informațiile din alte secțiuni aici. Aici este prezentată arhitectura sistemului, rațiunea tehnologiilor software selectate, descrierea acestora (tot felul de lucruri de sistem: limbaje de programare, cadre, sisteme de operare etc.). De asemenea, în acest document descriem modul în care sunt organizate instrumentele de procesare a informațiilor (cozi de mesaje, stocare, instrumente de backup, soluții de disponibilitate, tot felul de pool-uri de aplicații etc.). Standardul are descriere detaliata conținutul acestui document, pe care orice specialist îl va înțelege.

Suport tehnic (TO). O parte nu mai puțin iubită a documentației proiectului. Tabloul roz nu este decât întunecat de abundența documentelor care trebuie dezvoltate. În total, standardul necesită elaborarea a 22 de documente, dintre care 9 sunt în stadiul de TC.

Faptul este că standardul oferă o descriere a întregului suport tehnic, inclusiv hardware și rețele de computer, sisteme de inginerie și chiar partea de construcție (dacă este necesar). Și această economie este reglementată de un număr mare de standarde și reglementări, coordonate în diferite organizații și, prin urmare, este mai convenabil să împărțiți totul în părți și să coordonați (editați) în părți. În același timp, standardul vă permite să combinați unele documente între ele, ceea ce are sens dacă întregul grup este aprobat de o singură persoană.

De asemenea, nu uitați că un set de standarde de calitate presupune înregistrarea și stocarea documentelor tehnice, iar „cărțile” noastre de la client pot fi distribuite în diferite arhive, în funcție de subiectul descrierii. Acesta este un alt argument în favoarea fragmentării documentației.

Suport organizațional (OO). După ce am suprimat dorința, normală pentru un techie, de a trece peste această secțiune cât mai repede posibil, dimpotrivă, o voi lua în considerare mai detaliat. Din moment ce, colegi, în În ultima vreme Există unele tendințe proaste în proiecte care necesită clarificări în această secțiune.

La etapa TP, secțiunea conține un singur document „ Descrierea structurii organizatorice„, în care trebuie să spunem clientului pentru ce ar trebui să se pregătească în ceea ce privește schimbarea structurii organizatorice. Dintr-o dată trebuie să organizați un nou departament pentru a vă opera sistemul, să introduceți noi poziții etc.

La etapa RD apar și alte documente, mai interesante, pe care aș vrea să le iau în considerare separat.

Manualul utilizatorului. Comentariile sunt inutile, cred.

Metodologia (tehnologia) proiectării asistate de calculator. Dacă este necesar, puteți include în acest document o descriere a procesului de construire a software-ului, control al versiunilor, testare etc. Dar asta dacă clientul din specificația tehnică dorește să asambleze personal software-ul. Dacă nu cere acest lucru (și nu plătește pentru asta), atunci întreaga bucătărie internă nu este treaba lui și acest document nu trebuie făcut.

Instructiuni tehnologice. Datorită modului de formalizare a proceselor de afaceri, un client viclean încearcă uneori să introducă reglementări de operare în acest document. Deci, sub nicio formă nu trebuie să faci asta.

Descrierea proceselor de afaceri, rol și descrierea postului, regulament de muncă - toate acestea sunt ORD, adică documentație organizatorică și administrativă. Care este produsul unui proiect de consultanță, care, din câte am înțeles, nu a fost achiziționat de la dumneavoastră. Și ți-au cumpărat un proiect tehnic și, de asemenea, documentația tehnică pentru el.

Instrucțiunea tehnologică este un strat între instrucțiunile de utilizare și manualul de utilizare. RP descrie în detaliu Cum trebuie să faceți anumite acțiuni în sistem. Instrucțiunea tehnologică spune că care acțiunile trebuie efectuate în anumite cazuri legate de funcționarea sistemului. În linii mari, o instrucțiune tehnologică este un scurt rezumat al RP pentru o anumită poziție sau rol. Dacă clientul nu are roluri formate sau dorește să vă creați singur roluri și cerințe de post, includeți în document cele mai elementare roluri, de exemplu: operator, operator senior, administrator. Comentariile clientului cu privire la subiectul „dar nu e așa la noi” sau „nu ne place” ar trebui să fie însoțite de o listă de roluri și de o descriere responsabilitatile locului de munca. Pentru că procesele de afaceri noi nu o punem. Suntem aceste procese de afaceri automatiza.

Voi scrie separat despre greblele descrise, cu exemple colorate, deoarece nu este prima dată când acest lucru se repetă în diferite sectoare ale „economiei naționale”.

Descrierea procesului tehnologic de prelucrare a datelor (inclusiv teleprocesare). O relicvă jalnică a epocii peșterilor, când existau „operatori de computer” special desemnați, care introduceau carduri perforate la mașină și împachetau o imprimare a rezultatului într-un plic. Această instrucțiune este pentru ei. Nu vă pot spune exact ce să scrieți în el în secolul 21. Ieși singur. Cel mai bun lucru este să uiți de acest document.

Soluții la nivel de sistem (WSO). Standardul prevede 17 documente în secțiunea OP. În primul rând, acestea sunt aproape toate documentele fazei preliminare de proiectare schematică. În al doilea rând, acestea sunt tot felul de estimări, calcule și descriere scurta funcții automatizate. Adică informații pentru oameni nu din producția IT principală, ci pentru personalul suport - manageri, estimatori, specialiști în achiziții, economiști etc.

Și în al treilea rând, PO include un mega-document numit „Notă explicativă a proiectului tehnic”, care se dorește a fi un fel de rezumat executiv, dar, de fapt, mulți designeri introduc în el tot conținutul util al etapei TP. O astfel de abordare radicală poate fi justificată și chiar reciproc avantajoasă atât pentru client, cât și pentru antreprenor, dar în anumite cazuri.

Opțiuni pentru utilizarea GOST 34

1. Respectarea deplină și exactă la standard. Desigur, nimeni nu va scrie în mod voluntar un astfel de nor de documente. Prin urmare, un set complet de documente este pregătit doar la cererea urgentă a clientului, pe care acesta le-a asigurat în specificațiile tehnice și, de asemenea, a fixat cu un acord deasupra. În acest caz, trebuie să luați totul la propriu și să oferiți clientului „cărți” fizice, pe care vor fi numele documentelor din Tabelul 2 din GOST 34.201-89, cu excepția celor complet inutile, a căror listă trebuie să discute și să se asigure în scris. Conținutul documentelor trebuie, de asemenea, să respecte, fără nicio imaginație, RD 50-34.698-90, până la denumirile secțiilor. Pentru a face creierul clientului să explodeze, uneori un sistem mare este împărțit în subsisteme și se eliberează documentație de proiectare separată pentru fiecare subsistem. Arată terifiant și nu este supus controlului normal cu ajutorul minții pământești. În special în ceea ce privește integrarea subsistemelor. Ceea ce simplifică foarte mult acceptarea. Principalul lucru este că tu însuți nu te confuzi și că sistemul tău încă funcționează așa cum ar trebui.
2. Ne plac standardele GOST. În serios marile companii standarde de dragoste. Pentru că îi ajută pe oameni să se înțeleagă mai bine. Dacă clientul dvs. este remarcat pentru dragostea lui pentru ordine și standardizare, încercați să respectați ideologia standard GOST atunci când dezvoltați documente, chiar dacă acest lucru nu este cerut de specificațiile tehnice. Specialiștii avizori te vor înțelege mai bine și te vor aproba, iar tu însuți nu vei uita să-i incluzi în documentație Informații importante, veți vedea mai bine structura țintă a documentelor, veți planifica mai precis munca de scriere a acestora și vă veți economisi pe dumneavoastră și pe colegii tăi o mulțime de nervi și bani.
3. Nu ne pasă de documentare, atâta timp cât totul funcționează. Aspectul dispărut al clientului iresponsabil. O viziune similară asupra documentației poate fi găsită încă în rândul clienților mici și săraci, precum și în „idiotocrațiile” autoritare rămase din timpul perestroikei, unde șeful este înconjurat. prieteni adevărați- directori, iar toate problemele sunt rezolvate în conversații personale. În astfel de condiții, sunteți liber să neglijați documentația cu totul, dar este mai bine, până la urmă, să nu doborâți vederea și să completați cel puțin schematic documentația cu conținut. Dacă nu acestui client, atunci transmiteți-l (vindeți-l) următorului.

Concluzie

Acest articol a fost despre standardele noastre GOST pentru documentarea sistemelor de control automatizate. GOST-urile sunt vechi, dar, după cum se dovedește, sunt încă foarte utile în gospodărie. În afară de unele rudimente evidente, structura documentației are proprietăți de completitudine și consistență, iar aderarea la standard elimină multe riscuri ale proiectului, de a căror existență este posibil să nu fim conștienți la început.

Sper că materialul prezentat v-a fost de folos, sau măcar interesant. În ciuda oboselii aparente, documentarea este o muncă importantă și responsabilă, în care acuratețea este la fel de importantă ca și scrierea unui cod bun. Scrie documente bune, Colegi! Și sunt pe săptămâna viitoare Plec în două călătorii de afaceri la rând, așa că nu pot garanta publicarea de materiale noi (nu am un ascunt, scriu din cap).

M. Ostrogorsky, 2008

Pentru a aplica cu succes GOST 34, este necesar să înțelegem cum, din punctul de vedere al acestui set de standarde, este structurat sistemul automatizat. În caz contrar, nu vom vedea nimic în invitat decât o listă lungă de documente cu nume misterioase, iar cerințele pentru conținutul lor ne vor convinge încă o dată că în multe înțelepciuni există multă tristețe. Prin urmare, înainte de a discuta documentele în sine, trebuie să înțelegem care este subiectul documentării.

Sistem automatizat, funcțiile și sarcinile acestuia

Definiția unui sistem automatizat

GOST 34.003-90 conține următoarea definiție a unui sistem automatizat: un sistem format din personal și un set de instrumente de automatizare pentru activitățile lor, implementând tehnologia informației pentru a îndeplini funcțiile stabilite. Ce înseamnă de fapt această definiție? Puteți înțelege acest lucru doar citind alte definiții ale acestui standard și comparându-le între ele. Ce vei face acum?

Obiectivele activității

Un sistem automatizat poate exista doar acolo unde există personal angajat într-o anumită activitate. De obicei, vorbim despre activități ale căror rezultate sunt utile cuiva, indiferent de instrumentele folosite. De exemplu, merg la casa de bilete a teatrului pentru un bilet și sunt destul de fericit dacă casieria îmi scrie cu stiloul pe un formular, atâta timp cât mă lasă să intru în teatru folosindu-l. Casierului, în general, nici nu îi pasă cum exact este făcut biletul. O să fie bine cu orice metodă, atâta timp cât nu necesită multă muncă și îi oferă posibilitatea de a-mi vinde un bilet. Cu alte cuvinte, ea și cu mine avem un scop comun. GOST 34.003-90 folosește termenul pentru a-l desemna scopul activității. De fiecare dată când un alt spectator părăsește fereastra cu un bilet în mână, iar teatrul devine puțin mai bogat, acest scop al activității este atins.

Funcțiile sistemului automatizat

Pot exista (și, de regulă, există) mai multe obiective pentru o activitate. Orice rezultat util în afara activității în sine poate fi considerat scopul său. Așadar, dacă casiera nu numai că vinde bilete, ci întocmește și un raport de vânzări pentru superiorii ei la sfârșitul zilei de lucru, întocmirea unui raport zilnic poate fi considerată un alt scop de activitate.

Dacă punem un computer și o imprimantă pe biroul casieriei, iar șeful casieriei îi dă ordin să introducă bilete și rapoarte într-un procesor de text și să le imprime pe imprimantă, atunci vom obține un sistem automat. Potrivit ideilor moderne, este foarte primitiv; formal va satisface definiția Gost. Vă rugăm să rețineți că obiectivele activității nu s-au schimbat ca urmare a implementării sistemului automatizat, s-a schimbat doar modalitatea de realizare a acestora. Ceea ce se făcea anterior „așa” se face acum în cadrul unui sistem automatizat. Setul de acțiuni ale unui sistem automatizat care vizează atingerea unui obiectiv specific, conform GOST 34.003-90, se numește funcţie. Notă: indiferent de modul în care îl priviți, personalul este considerat parte a sistemului.

Funcția unui sistem automatizat este un concept fundamental în GOST 34. Un sistem automatizat este considerat, în primul rând, ca suma funcțiilor sale și abia apoi ca o grămadă de „software” și „hardware”. Cel mai important lucru este ceea ce face sistemul și în ce constă este secundar.

Cele de mai sus ar putea conduce cititorul la concluzia că fiecărui scop de activitate într-un sistem automatizat îi corespunde una și o singură funcție. Un astfel de sistem este ușor de imaginat, dar practica este mai variată. Pe de o parte, activitățile nu sunt întotdeauna complet automatizate. Chiar și după implementarea unui sistem automatizat, unele obiective trebuie atinse manual. Pe de altă parte, deoarece același rezultat poate fi obținut în condiții diferite căi diferite, mai multe funcții pot viza un singur scop de activitate într-un sistem automatizat, de exemplu, vânzarea unui bilet la casa de bilete și vânzarea unui bilet prin Internet. În plus, orice sistem automatizat necesită o anumită întreținere, așa că trebuie să introducem conceptul de funcție auxiliară. Un exemplu tipic este crearea unei copii de rezervă a datelor.

Sarcinile sistemului automatizat

În cazul general, la îndeplinirea unei funcții, o parte din muncă este efectuată de personal, iar o parte de tehnologie; să zicem, un bilet este tipărit automat și dat cumpărătorului manual de către casier. O secvență de acțiuni automate (sic) care conduc la un rezultat de un anumit tip este numită în GOST 34.003-90 sarcină.

Aici definiția problemei nu este citată în întregime, dar deocamdată acest lucru va fi suficient pentru noi; la urma urmei, nu este o rușine pentru nimeni să citească singur standardul. Este important ca o sarcină să fie partea cea mai clar oficializată a unei activități automatizate. Vă puteți imagina o funcție care este efectuată complet automat, cum ar fi backup-ul menționat mai sus. În acest caz, funcția este redusă la o singură sarcină.

Aceeași sarcină poate fi rezolvată prin îndeplinirea unor funcții diferite. De exemplu, dacă un sistem automatizat are mai multe funcții pentru vânzarea unui bilet, atunci executarea fiecăreia dintre ele poate necesita la un moment dat tipărirea biletului.

Compoziția sistemului automatizat

Subsisteme

Dacă sistemul automatizat este destul de complex, acesta este împărțit în subsisteme. Ce înseamnă, destul de complex, destul de greu de spus. Teoria sistemelor descrie diferite niveluri și criterii de complexitate. În practică, nevoia de a aloca mai multe subsisteme într-un sistem automat este adesea cauzată de motive organizaționale și financiare, de exemplu, subsistemele sunt dezvoltate și puse în funcțiune secvenţial.

Deși în GOST 34 termenul subsistem este folosit de multe ori, nu pare să existe o definiție formală a acestui concept acolo. Experiența sugerează că un subsistem este o parte a unui sistem automatizat care satisface și definiția unui sistem automatizat, în special, are funcții cu drepturi depline.

Revenind la exemplul de ticketing, putem decide că sistemul automatizat este format din două subsisteme: un subsistem de ticketing și un subsistem de raportare zilnică. Să fim de acord, pentru mai multă claritate, că casierul scrie biletele într-un editor de text și rapoartele în foi de calcul.

Componente

Identificarea scopurilor de activitate, funcțiile unui sistem automatizat și, dacă este necesar, a subsistemelor acestuia este în mare măsură subiectivă și depinde de punctul de vedere al subiectului care a decis să facă acest lucru. Dacă un rezultat este important în contextul problemei care se rezolvă, îl putem considera un scop, altfel îl ignorăm. De asemenea, vom sparge sistemul automatizat în subsisteme într-un mod care ne este convenabil, atâta timp cât deciziile noastre nu contrazic conținutul acestui concept.

Componentele sunt părțile din care noi realitatea obiectivă Construim un sistem automatizat. Sistemul constă fizic din componentele sale, astfel că împărțirea unui sistem automatizat în componente este cea mai obiectivă.

Cumpărăm fiecare componentă, o instalăm și conectăm (dacă este echipament), o instalăm (dacă este un program) și o întreținem separat de celelalte componente. Am cumpărat și am așezat un computer pe masă - este o componentă. Am dezvoltat un editor de text special pentru tastarea biletelor - o altă componentă. Foi de calcul gratuite descărcate de pe Internet - din nou o componentă. Și chiar și casiera însăși, într-un fel, este, de asemenea, o componentă a sistemului automatizat.

Compoziția componentelor unui sistem automatizat este foarte importantă din punct de vedere al documentației sale, deoarece documentația tehnică pentru sistem ca atare și pentru componente este tratată diferit. În general, ar trebui dezvoltat oameni diferiti, și este proiectat după diferite standarde în funcție de tipul de componentă.

Tipuri de garanții

Unul dintre cele mai dificile concepte pentru un utilizator începător al GOST 34 este tip de securitate. Ce fel de securitate este aceasta? Îl poți vedea sau atinge? Vinde sau cumpara?

Fiecare tip de software combină componente sau soluții tehnice de o anumită natură. GOST 34 menționează multe tipuri diferite software, nu le vom descrie pe fiecare dintre ele secvenţial aici, ci le vom enumera doar pe cele mai vizibile:

• suport informațional - toate datele și metadatele cu care funcționează sistemul;
• software - toate programele care fac parte din sistem;
• suport tehnic - toate mijloacele tehnice (cu alte cuvinte, echipamente, echipamente) care fac parte din sistem.

Să repetăm ​​încă o dată, acestea nu sunt toate tipurile de securitate. Nici măcar nu putem spune cu certitudine că sunt cele mai importante. De exemplu, pentru sisteme automatizate controlul procesului (APCS) de mare valoare are suport metrologic. Multe sisteme automate necesită un suport matematic și lingvistic complex. Dar este greu de imaginat un sistem automatizat care să fie complet lipsit de unul dintre cele trei tipuri de suport enumerate mai sus (exercițiu: încercați).

Introducere

ÎN lumea modernăÎn fiecare zi apar zeci și sute de programe, aplicații și sisteme de informații diferite. Ele pot fi dezvoltate pentru sectorul guvernamental sau comercial, precum și pentru utilizatorii obișnuiți. 90% dintre toți utilizatorii nu citesc documentația, o consideră plictisitoare, plictisitoare și neinteresantă și deschid manualul de utilizare numai atunci când ceva nu funcționează sau este complet imposibil să-l înțelegi fără instrucțiuni. Acum este o practică obișnuită să proiectați interfața cu utilizatorul în așa fel încât să fie intuitivă, iar utilizatorul să poată înțelege sistemul fără a fi nevoie să citească manuale lungi. Cu toate acestea, atunci când lucrați cu clienți mari, este aproape întotdeauna necesar să trimiteți un anumit pachet de documente - manuale, instrucțiuni, soluții de proiectare, elaborate în conformitate cu GOST.
Când întâlniți prima scriere a documentației în conformitate cu GOST, sunteți uluit și complet șocat, deoarece există „mare” de aceste GOST și cum și ce să scrieți în conformitate cu ele devine neclar.
Acest articol discută standardele GOST pentru scrierea documentației și punctele lor principale.

Care sunt standardele GOST?

În primul rând, trebuie să înțelegeți ce sunt standardele GOST. Toată lumea știe doar că GOST este ceva care a fost dezvoltat în cadrul Uniunii și că există pur și simplu un număr nesfârșit. Mă grăbesc să vă asigur că nu există multe GOST-uri pentru sectorul IT și toate acestea, în ciuda timpului lor de creare, nu și-au pierdut relevanța.
În primul rând, standardele pentru scrierea documentației sunt împărțite în două tipuri:

1. Standarde internaționale (ISO, IEEE Std);
2. GOST rusești sau sovietice.

Standarde internaționale
Standardele internaționale sunt utilizate pentru a dezvolta documentație la nivel internațional. De regulă, ele nu sunt gratuite, deoarece nu sunt dezvoltate organizatii guvernamentale, dar, spre deosebire de ale noastre, au fost dezvoltate destul de recent. Subiect standarde internaționale foarte larg, așa că va fi discutat într-un alt articol. Mai multe standarde care sunt strâns legate de redactarea documentației sunt, de asemenea, atinse.
Lista principalelor standarde internaționale pentru scrierea documentației:

1. IEEE Std 1063-2001 „IEEE Standard for Software User Documentation” - standard pentru scrierea manualelor de utilizare;
2. IEEE Std 1016-1998 „IEEE Recommended Practice for Software Design Descriptions” - un standard pentru scrierea unei descrieri tehnice a unui program;
3. ISO/IEC FDIS 18019:2004 „Linii directoare pentru proiectarea și pregătirea documentației de utilizare pentru software-ul aplicației” este un alt standard pentru scrierea manualelor de utilizare. Acest document conţine un numar mare de exemple. Ca să spunem așa, acesta este mai degrabă un ghid pentru scrierea unui manual de utilizare. Va fi util în special pentru specialiștii începători;
4. ISO/IEC 26514:2008 „Cerințe pentru proiectanții și dezvoltatorii de documentație pentru utilizator” este un alt standard pentru proiectanții și dezvoltatorii de documentație pentru utilizator.

De fapt, există o mulțime de standarde internaționale și fiecare țară are propriile sale, deoarece același standard poate să nu se potrivească întotdeauna atât companiilor europene, cât și asiatice.

standardele rusești
Standardele rusești sunt dezvoltate la nivel de stat. Toate sunt absolut gratuite și fiecare dintre ele este ușor de găsit pe Internet. Pentru a scrie documentația pentru program, sunt utilizate două serii de GOST-uri 19 și 34. Acestea vor fi discutate în continuare.

Care este diferența dintre seria GOST 19 și 34?

Prima întrebare care apare este cum, în general, aceste GOST-uri 19 și 34 diferă unele de altele.
În GOST 19.781-90 " un singur sistem documentația software. Software pentru sisteme de procesare a informațiilor. Termeni și definiții” sunt indicate definițiile:

1. Program - date destinate controlului unor componente specifice ale unui sistem de procesare a informațiilor în vederea implementării unui anumit algoritm.
2. Software-ul este un set de programe ale sistemului de procesare a informațiilor și documente de program necesare pentru funcționarea acestor programe.

În GOST 34.003-90 „Tehnologia informației. Set de standarde pentru sisteme automate. Sisteme automatizate. Termeni și definiții” se indică definiția:

1. Sistem automatizat (AS) - un sistem format din personal și un set de instrumente de automatizare pentru activitățile acestora, implementând tehnologia informației pentru a îndeplini funcțiile stabilite.
   În funcție de tipul de activitate, de exemplu, se disting următoarele tipuri de AS: sisteme automate de control (ACS), sisteme de proiectare asistată de calculator (CAD), sisteme automatizate cercetare științifică(ASNI) și alții.

În funcție de tipul de obiect (proces) controlat, sistemele de control automatizate se împart, de exemplu, în: sisteme de control automatizate pentru procese tehnologice (ACS), sisteme de control automatizate pentru întreprinderi (ACS) etc.
GOST 34 face, de asemenea, o împărțire în tipuri de suport AS:

1. organizatoric;
2. Metodic;
3. Tehnic;
4. Matematic;
5. Software;
6. informativ;
7. Lingvistic;
8. Legal;
9. Ergonomic.

Ca urmare, un sistem automatizat nu este un program, ci un complex de tipuri de software, inclusiv software. AS, de regulă, oferă o soluție organizațională pentru un anumit utilizator și client, iar Programul poate fi creat și replicat pentru un număr mare de utilizatori fără a fi legat de nicio întreprindere.
Prin urmare, dacă dezvoltați documentație pentru un program pe care l-ați creat pentru o anumită întreprindere, atunci GOST este 34. Dacă scrieți documente pentru un program de masă, atunci GOST este 19.

GOST 34

Seria GOST 34 (GOST 34.xxx Standarde de tehnologie a informației) constă din:

1. GOST 34.201-89 Tipurile, caracterul complet și denumirea documentelor la crearea sistemelor automate - acest standard stabilește tipurile, numele, caracterul complet și numărul documentelor. Este unul dintre documentele principale ale seriei GOST 34. De fapt, acesta este un document de bază, așa că începătorii trebuie să se familiarizeze mai întâi cu el.
2. GOST 34.320-96 Concepte și terminologie pentru diagrama conceptuală și baza de informatii- prezentul standard stabilește conceptele și termenii de bază ai schemelor conceptuale și a bazelor de informații, acoperind dezvoltarea, descrierea și aplicarea schemelor conceptuale și a bazelor de informații, manipularea informațiilor, precum și descrierea și implementarea procesului informațional. Standardul definește rolul diagramei conceptuale. Prevederile cuprinse în acesta sunt de natură consultativă și pot fi utilizate pentru evaluarea sistemelor de management al bazelor de date (DBMS). Acest document nu descrie metode specifice de utilizare a instrumentelor de suport pentru diagrame conceptuale. Limbile de schemă conceptuală descrise în standard nu ar trebui să fie considerate limbi standard.
3. GOST 34.321-96 Tehnologii informaționale. Sistem de standarde de baze de date. Model de referință de guvernare - Acest document stabilește un model de referință de guvernanță a datelor.
   Modelul de referință definește terminologia și conceptele comune legate de datele sistemelor informaționale. Astfel de concepte sunt folosite pentru a defini serviciile furnizate de sistemele de management al bazelor de date sau sistemele de dicționar de date.
   Modelul de referință nu ia în considerare protocoalele pentru gestionarea datelor.
   Sfera de aplicare a modelului de referință include procese care se ocupă cu gestionarea datelor persistente și interacțiunea acestora cu procese care diferă de cerințele unui anumit Sistem informatic, precum și servicii generale de gestionare a datelor pentru definirea, stocarea, preluarea, actualizarea, capturarea, copierea, restaurarea și transmiterea datelor.
4. GOST 34.601-90 Sisteme automate. Etapele creării - standardul stabilește etapele și etapele creării unui AS.
5. GOST 34.602-89 Specificații tehnice pentru crearea unui sistem automat (În locul GOST 24.201-85) - stabilește compoziția, conținutul, regulile de întocmire a documentului „Termeni de referință pentru crearea (dezvoltarea sau modernizarea) sistemului. ”
   Acest document este unul dintre documentele utilizate frecvent din seria GOST 34. Când dezvoltați specificațiile tehnice pentru acest GOST, ar trebui să vă amintiți despre alte standarde, chiar dacă acest document nu conține referințe la aceste standarde.
6. GOST 34.603-92 Tehnologia informației. Tipuri de teste ale sistemelor automate - standardul stabilește tipuri de teste ale AS (autonome, complexe, teste de acceptare și funcționare de probă) și cerințe generale pentru implementarea acestora.
7. RD 50-34.698-90 Sisteme automatizate. Cerințele pentru conținutul documentelor sunt unul dintre cele mai importante documente ale GOST 34, deoarece descrie conținutul aproape tuturor documentelor, precum și o descriere a fiecărui paragraf al documentului.
8. GOST R ISO/IEC 8824-3-2002 Tehnologia informației. Notație de sintaxă abstractă Versiunea unu - Acest standard face parte din Notația de sintaxă abstractă Versiunea 1 (ASN.1) și stabilește o notație pentru specificarea constrângerilor definite de utilizator și a constrângerilor de tabel.
9. GOST R ISO/IEC 10746-3-2001 Managementul datelor și procesarea distribuită deschisă.
   În acest standard:
   • se determină modul în care sunt specificate sistemele de procesare distribuită deschisă (ODP) folosind conceptele introduse în GOST R ISO/IEC 10746-2;
   • Au fost identificate caracteristicile conform cărora sistemele aparțin sistemelor OPO.

   Standardul stabilește un cadru pentru coordonarea dezvoltării standardelor pentru sistemele ODP.

10. GOST R ISO/IEC 15271-02 Procesele ciclului de viață al software-ului - acest GOST este necesar mai mult, în opinia mea, pentru analiști atunci când proiectează și modelează AS.
    Acest document este util, din punctul meu de vedere, în scop pur educativ.
11. GOST R ISO/IEC 15910-2002 Proces pentru crearea documentației utilizator pentru un instrument software - definește procesul minim necesar pentru crearea documentației utilizator de toate tipurile pentru un instrument software care are o interfață cu utilizatorul. Aceste tipuri includ documentație tipărită (de exemplu, ghiduri de utilizare și carduri de referință rapidă), documentație online, text de ajutor și sisteme de documentare online.

Deci, pe baza a tot ceea ce este scris mai sus, este clar că principalele documente din GOST 34 sunt 3: GOST 34.201-89, RD 50-34.698-90 și GOST 34.602-89.
Când dezvoltați un pachet de documentație, mai întâi, trebuie să deschideți GOST 34.201-89 și să selectați etapa de creare: proiectare, proiectare tehnică și documentație de lucru. În continuare, ar trebui să selectați documente pentru dezvoltare care corespund etapei de creare.

Lista documentelor 34 GOST

Etapă creare	Titlul documentului	Cod	Parte proiect	Prinad pat la proiect dar-estimare Noah Doku poliţist țiuni	Prinad pat la exploatare tare noah sus kumen tații	Instructiuni aditionale
EP	Fișă de proiect preliminar	EP*	SAU	—	—	—
	Notă explicativă La proiectul preliminar	P1	SAU	—	—	—
EP, TP	Organigrama	CO	SAU	—	—	Este permisă includerea P3 sau PV în document
	Schema structurală a complexului mijloace tehnice	C1*	ACEA	X	—
	Diagrama structurii funcționale	C2*	SAU	—	—	La elaborarea documentelor CO, C1, C2, C3 în stadiul ES, este permisă includerea lor în documentul P1
	specializat (nou) mijloace tehnice	LA 9	ACEA	X	—	Când se dezvoltă în stadiul tehnic permis să includă la documentul P2
	Schema de automatizare	C3*	ACEA	X	—	—
	Specificații tehnice pentru dezvoltare specializat (nou) mijloace tehnice	—	ACEA	—	—	Proiectul nu include
TP	Sarcini de dezvoltare sanitare şi alte secțiuni legate de proiect cu crearea unui sistem	—	ACEA	X	—	Proiectul nu include
	Fișă de proiect tehnic	TP*	SAU	—	—	—
	Lista articolelor achiziționate	VP*	SAU	—	—	—
	Lista semnalelor de intrare și date	ÎN 1	ȘI DESPRE	—	—	—
	Lista semnalelor de ieșire (documente)	LA 2	ȘI DESPRE	—	—	—
	Lista sarcinilor de dezvoltare constructii, electrice, sanitare şi alte secțiuni legate de proiect cu crearea unui sistem	LA 3	ACEA	X	—	Este permisă includerea P2 în document
	Notă explicativă la proiectul tehnic	P2	SAU	—	—	Include planul evenimentului la pregătirea unui obiect pentru intrare sisteme în funcţiune
	Descrierea automată funcții	P3	SAU	—	—	—
	Descrierea setarii sarcinii (set de sarcini)	P4	SAU	—	—	Permis să includă la documentele P2 sau P3
	Descrierea informațiilor asigurarea sistemului	P5	ȘI DESPRE	—	—	—
	Descrierea organizației baza de informatii	P6	ȘI DESPRE	—	—	—
TP	Descrierea sistemelor de clasificare și codificare	P7	ȘI DESPRE	—	—	—
	Descrierea matricei informație	P8	ȘI DESPRE	—	—	—
	Descrierea complexului mijloace tehnice	P9	ACEA	—	—	Pentru sarcină este permisă includerea în documentul 46 conform GOST 19.101
	Descrierea software-ului dispoziţie	PA	DE	—	—	—
	Descrierea algoritmului (procedura de proiect)	PB	MO	—	—	Este permisă includerea P2, P3 sau P4 în documente
	Descrierea organizațională structurilor	PV	OO	—	—	—
	Planul de amenajare	C8	ACEA	X	—	Este permisă includerea P9 în document
	Lista de echipamente si materiale	—	ACEA	X	—	—
	Calcul de deviz local	B2	SAU	X	—	—
TP, RD	Evaluarea proiectului fiabilitatea sistemului	B1	SAU	—	—	—
	Desenul formularului de document (cadru video)	C9	ȘI DESPRE	—	X	La stadiul TP este permis include în documente P4 sau P5
RD	Lista titularilor originale	DP*	SAU	—	—	—
	Fișa de operare documente	ED*	SAU	—	X	—
	Specificații hardware	LA 4	ACEA	X	—	—
	Lista cerințelor în materiale	LA 5	ACEA	X	—	—
	Inventarul media de mașini informație	VM*	ȘI DESPRE	—	X	—
	Matrice de intrare	LA 6	ȘI DESPRE	—	X	—
RD	Directorul bazei de date	LA 7	ȘI DESPRE	—	X	—
	Compoziția datelor de ieșire (mesaje)	LA 8	ȘI DESPRE	—	X	—
	Estimări locale	B3	SAU	X	—	—
	Metodologie (tehnologie) automatizate proiecta	I1	OO	—	X	—
	Instructiuni tehnologice	ȘI 2	OO	—	X	—
	Manualul utilizatorului	I3	OO	—	X	—
	Instructiuni de formare si întreținerea bazei de date (set de date)	I4	ȘI DESPRE	—	X	—
	Instrucțiuni de utilizare KTS	IE	ACEA	—	X	—
	Schema cablajului extern	C4*	ACEA	X	—	Permis să fie efectuat în sub formă de tabele
	Schema de conectare postări externe	C5*	ACEA	X	—	La fel
	Tabel de conexiuni și conexiuni	C6	ACEA	X	—	—
	Diagrama de diviziune a sistemului (structural)	E1*	ACEA	—	—	—
	Desen general	ÎN*	ACEA	X	—	—
	Desen montaj echipament tehnic	SA	ACEA	X	—	—
	Diagramă schematică	SB	ACEA	X	—	—
	Schema structurală a complexului mijloace tehnice	C1*	ACEA	X	—	—
	Planul de amenajare a echipamentelor și cablajului	C7	ACEA	X	—	—
	Descrierea tehnologică proces de prelucrare date (inclusiv teleprocesare)	PG	OO	—	X	—
	Descrierea generală a sistemului	PD	SAU	—	X	—
	Programul și metodologia de testare (componente, sisteme de automatizare, subsisteme, sisteme)	P.M*	SAU	—	—	—
	Formă	FO*	SAU	—	X	—
	Pașaport	PS*	SAU	—	X	—
*Documente al căror cod este stabilit în conformitate cu cerințele standardelor ESKD

Notă la tabel:

1. În tabel sunt utilizate următoarele notații:
   • EP - proiect preliminar;
   • TP - proiect tehnic;
   • RD - documentație de lucru;
   • SAU - soluții la nivel de sistem;
   • OO - decizii privind suportul organizatoric;
   • TO - soluții pentru suport tehnic;
   • IO - soluții pentru suport informațional;
   • Software - soluții software;
   • MO - soluții software.
2. Semnul X indică faptul că aparține devizelor de proiectare sau documentației operaționale.
3. Nomenclatorul documentelor cu același nume se stabilește în funcție de deciziile de proiectare luate în timpul creării sistemului.

Când lista de documente a fost stabilită, atunci în RD 50-34.698-90 ar trebui să găsiți documentele selectate și să le dezvoltați strict conform punctelor specificate. Toate punctele de conținut care sunt indicate trebuie să fie în document.
Dacă specificațiile tehnice sunt în curs de dezvoltare, atunci trebuie să deschideți imediat GOST 34.602-89 și să dezvoltați specificațiile tehnice strict în conformitate cu punctele.

GOST 19

Seria de GOST-uri 19 (GOST 19.xxx Unified System of Program Documentation (USPD)) constă din:

1. 1. GOST 19.001-77 Dispoziții generale - un document prea general, nu are nicio utilitate practică. Prin urmare, puteți sări peste el.
   2. GOST 19781-90 Termeni și definiții - lista buna definiţii în domeniul software-ului pentru sistemele de prelucrare a informaţiei. Nu conține nimic mai mult decât definiții.
   3. GOST 19.101-77 Tipuri de programe și documente de program - unul dintre principalele documente ale 19 GOST. Aici ar trebui să începeți să lucrați cu GOST 19, deoarece conține o listă completă și denumiri ale documentelor GOST.

Lista documentelor 19 GOST

Cod	Tipul documentului	Etape de dezvoltare
		Sketchy proiect	Tehnic proiect	Proiect de lucru
				componentă	complex
—	Specificație	—	—
05	Lista deținătorilor originali	—	—	—
12	Textul programului	—	—
13	Descrierea programului	—	—
20	Lista documentelor operaționale	—	—
30	Formă	—	—
31	Descrierea aplicației	—	—
32	Ghidul programatorului de sistem	—	—
33	Ghidul programatorului	—	—
34	Manual de utilizare	—	—
35	Descrierea limbii	—	—
46	Manual tehnic serviciu	—	—
51	Programul de testare și metodologia	—	—
81	Notă explicativă			—	—
90-99	Alte documente

Legendă:
— documentul este obligatoriu;
— documentul este obligatoriu pentru componentele care au utilizare independentă;
— necesitatea întocmirii unui document este determinată în stadiul de elaborare și aprobare a specificațiilor tehnice;
- - documentul nu este întocmit.

1. GOST 19.102-77 Etape de dezvoltare - conține o descriere a etapelor de dezvoltare. Util în scopuri educaționale. După părerea mea, nu are prea multe beneficii practice.
2. GOST 19.103-77 Denumiri de programe și documente de program - conține o descriere a atribuirii unui număr (cod) unui document. Chiar și după citirea acestui GOST, rămân o mulțime de întrebări despre cum să atribuiți același număr unui document.
3. GOST 19.104-78 Inscripții principale - stabilește formele, dimensiunile, locația și procedura de completare a inscripțiilor principale ale fișei de aprobare și Pagina titluîn documentele programului prevăzute de standardele DEPD, indiferent de metodele de implementare a acestora. Deoarece documentele 19 GOST sunt întocmite în cadre, acest document este foarte important.
4. GOST 19.105-78 Cerințe generale pentru documentele programului - stabilește cerințe generale pentru pregătirea documentelor programului. Cerințele sunt prea generale. De regulă, acest GOST aproape că nu este folosit pentru a dezvolta un document, deoarece un GOST special pentru un document este suficient, dar pentru cunoștințe generale este mai bine să cercetați acest GOST o dată.
5. GOST 19.106-78 Cerințe pentru documentele programului executate în formă tipărită - conține cerințe pentru executarea tuturor documentelor 19 GOST.
6. GOST 19.201-78 Specificații tehnice, cerințe pentru conținut și proiectare - stabilește procedura de construire și pregătire a specificațiilor tehnice pentru dezvoltarea unui program sau a unui produs software.

   Clauzele specificațiilor tehnice ale 34 GOST și 19 GOST sunt diferite.

7. GOST 19.601-78 Reguli generale pentru duplicare, contabilitate și stocare - reguli generale duplicarea, circulația, contabilizarea și stocarea documentelor programului. GOST descrie în mai multe puncte cum să vă asigurați că documentele nu sunt pierdute.
8. GOST 19.602-78 Reguli pentru duplicarea, contabilizarea și stocarea documentelor de program, execuții de tipărire. Metodă - adăugare la GOST 19.601-78.
9. GOST 19.603-78 Reguli generale pentru efectuarea modificărilor - stabilește reguli generale pentru efectuarea modificărilor documentelor programului. În esență, descrie un algoritm birocratic lung pentru efectuarea modificărilor documentelor.
10. GOST 19.604-78 Reguli pentru efectuarea modificărilor documentelor de program făcute în format tipărit - descrie procedura de lucru și completare a fișei de înregistrare a modificărilor.

O listă de GOST-uri specializate, adică fiecare dintre ele descrie conținutul și cerințele pentru un anumit document:

1. Specificație GOST 19.202-78. Cerințe pentru conținut și design;
2. GOST 19.301-79 Programul de testare și metodologia. Cerințe pentru conținut și design;
3. GOST 19.401-78 Textul programului. Cerințe pentru conținut și design;
4. GOST 19.402-78 Descrierea programului;
5. GOST 19.403-79 Lista deținătorilor originali;
6. GOST 19.404-79 Notă explicativă. Cerințe pentru conținut și design;
7. GOST 19.501-78 Form. Cerințe pentru conținut și design;
8. GOST 19.502-78 Descrierea aplicației. Cerințe pentru conținut și design;
9. GOST 19.503-79 Ghidul programatorului de sistem. Cerințe pentru conținut și design;
10. GOST 19.504-79 Ghidul programatorului. Cerințe pentru conținut și design;
11. GOST 19.505-79 Manual de utilizare. Cerințe pentru conținut și design;
12. GOST 19.506-79 Descrierea limbii. Cerințe pentru conținut și design;
13. GOST 19.507-79 Declarația documentelor operaționale;
14. GOST 19.508-79 Ghid pentru întreținere. Cerințe pentru conținut și design.

Procedura de lucru cu 19 GOST:

1. În GOST 19.101-77, selectați un document și codul acestuia în funcție de stadiul de dezvoltare.
2. Conform GOST 19.103-77, atribuiți un număr documentului.
3. Apoi, conform GOST-urilor 19.104-78 și 19.106-78, întocmește un document.
4. Din lista specializată de GOST-uri, ar trebui să-l selectați pe cel care corespunde documentului în curs de dezvoltare.

Concluzie

GOST nu este înfricoșător și ușor! Principalul lucru este să înțelegeți ce trebuie scris și ce GOST este folosit pentru aceasta. Principalele noastre GOST 19 și 34 pentru scrierea documentației sunt foarte vechi, dar încă relevante până în prezent. Redactarea documentației conform standardului elimină multe probleme dintre antreprenor și client. În consecință, economisește timp și bani.

Data introducerii 01/01/92

Acest standard se aplică sistemelor automate (AS) utilizate în tipuri variate activități (cercetare, proiectare, management etc.), inclusiv combinațiile acestora, create în organizații, asociații și întreprinderi (denumite în continuare organizații).

Standardul stabilește etapele și etapele creării unui AS. Anexa 1 prezintă conținutul lucrării în fiecare etapă.

1. Dispoziții generale

2. Etapele și etapele creării unui AS

Anexa 1 (pentru referință)

Anexa 2 (referință)

1. DISPOZIȚII GENERALE

1.1. este un ansamblu de lucrări ordonate în timp, interconectate, combinate în etape și faze, a căror implementare este necesară și suficientă pentru a crea un sistem automatizat care să îndeplinească cerințele specificate.

1.2. Etapele și fazele creării unui AS se disting ca părți ale procesului de creare din motive de planificare rațională și organizare a muncii care se încheie cu un rezultat dat.

1.3. Lucrările privind dezvoltarea AS se desfășoară în funcție de etapele și etapele utilizate pentru crearea AS.

1.4. Compoziția și regulile de realizare a lucrărilor la etapele și etapele stabilite de prezentul standard sunt determinate în documentația relevantă a organizațiilor implicate în crearea unor tipuri specifice de centrale nucleare.

Lista organizațiilor implicate în crearea centralelor nucleare este prezentată în Anexa 2.

2. ETAPE ŞI ETAPE DE CREARE A AS

2.1. Etapele și etapele creării unui AS sunt prezentate în general în tabel.

Etape	Etapele muncii
1. Formarea cerințelor pentru vorbitori	1.1. Inspecția instalației și justificarea necesității creării unei centrale nucleare
	1.2. Formarea cerințelor utilizatorilor pentru difuzoare
	1.3. Întocmirea unui raport asupra lucrărilor efectuate și a unei cereri pentru dezvoltarea unui AS (specificații tactice și tehnice)
2. Dezvoltarea conceptului AC	2.1. Studierea obiectului
	2.2. Efectuarea lucrărilor de cercetare necesare
	2.3. Dezvoltarea opțiunilor de concept AC și selectarea unei opțiuni de concept AC care satisface cerințele utilizatorului
	2.4. Întocmirea unui proces-verbal asupra lucrărilor efectuate
3. Termeni de referință	3.1. Elaborarea și aprobarea specificațiilor tehnice pentru realizarea centralelor nucleare
4. Proiect de proiect	4.1. Dezvoltarea de soluții preliminare de proiectare pentru sistem și părțile sale
	4.2. Dezvoltarea documentației pentru sistemul de difuzoare și părțile sale
5. Proiectare tehnică	5.1. Dezvoltarea de soluții de proiectare pentru sistem și piesele sale
	5.2. Dezvoltarea documentației pentru sistemul de difuzoare și părțile sale
	5.3. Elaborarea și executarea documentației pentru furnizarea produselor pentru completarea CNE și (sau) cerințe tehnice (specificații tehnice) pentru dezvoltarea acestora
	5.4. Dezvoltarea sarcinilor de proiectare în părțile adiacente ale proiectului unității de automatizare
6. Documentație de lucru	6.1. Elaborarea documentației de lucru pentru sistem și părțile sale
	6.2. Dezvoltarea sau adaptarea programelor
7. Intrare și acțiune	7.1. Pregatirea obiectului de automatizare pentru punerea in functiune a CNE
	7.2. Instruirea personalului
	7.3. Set complet de difuzoare cu produsele furnizate (software și hardware, sisteme software și hardware, produse informatice)
	7.4. Lucrari de constructii si montaj
	7.5. Lucrări de punere în funcțiune
	7.6. Efectuarea de teste preliminare
	7.7. Efectuarea operațiunii de probă
	7.8. Efectuarea testelor de acceptare
8. Suport AC	8.1. Efectuarea lucrărilor în conformitate cu obligațiile de garanție
	8.2. Service post-garanție

2.2. Etapele și reperele realizate de organizațiile care participă la crearea centralelor nucleare sunt stabilite în contracte și specificații tehnice bazate pe acest standard.

Este posibil să excludeți etapa „Proiectare schiță” și etapele individuale de lucru în toate etapele, pentru a combina etapele „Proiectare tehnică” și „Documentație de lucru” într-o etapă de „Proiectare tehnică detaliată”. În funcție de specificul AS care se creează și de condițiile pentru crearea acestora, este permisă efectuarea unor etape individuale de lucru înainte de finalizarea etapelor anterioare, execuția paralelă a etapelor de lucru sau includerea unor noi etape de lucru.

ANEXA 1. Pentru referință

1. La etapa 1.1 „Inspecția instalației și justificarea necesității creării unei CNE”, în cazul general, se efectuează următoarele:

• colectarea datelor despre obiectul automatizării și tipurile de activități desfășurate;
• evaluarea calității de funcționare a unității și a tipurilor de activități desfășurate, identificarea problemelor care pot fi rezolvate cu ajutorul instrumentelor de automatizare;
• evaluarea (tehnică, economică, socială etc.) a fezabilității creării unei centrale nucleare.

2. La etapa 1.2 „formarea cerințelor utilizatorilor pentru difuzoare” se efectuează următoarele:

• pregătirea datelor inițiale pentru formarea cerințelor pentru sistemul automatizat (caracteristicile obiectului de automatizare, descrierea cerințelor pentru sistem, limitări ale costurilor acceptabile pentru dezvoltare, punere în funcțiune și exploatare, efectul așteptat de la sistem, condițiile de creare și funcționarea sistemului);
• formularea și executarea cerințelor utilizatorilor pentru difuzoare.

3. La etapa 1.3 „Completarea unui raport cu privire la lucrările efectuate și a unei cereri pentru dezvoltarea unui AS (specificații tactice și tehnice)”, un raport cu privire la lucrările efectuate în această etapă și o cerere pentru dezvoltarea unui AS (tactica și specificațiile tehnice) sau un alt document care îl înlocuiește sunt completate cu conținut similar.

4. La etapele 2.1 „Studiul obiectului” și 2.2 „Efectuarea lucrărilor de cercetare necesare”, organizația de dezvoltare realizează un studiu detaliat al obiectului de automatizare și lucrările de cercetare necesare (C&D) legate de găsirea modalităților și evaluarea posibilității de implementarea cerințelor utilizatorilor, întocmește și aprobă rapoarte de cercetare.

5. La etapa 2.3 „Elaborarea opțiunilor pentru conceptul AS și selectarea unei opțiuni pentru conceptul AS care să îndeplinească cerințele utilizatorului”, în cazul general, dezvoltarea opțiuni alternative conceptele AS în curs de creare și planuri pentru implementarea acestora; evaluare resursele necesare pentru implementarea și funcționarea acestora; evaluarea avantajelor și dezavantajelor fiecărei opțiuni; compararea cerințelor utilizatorilor și a caracteristicilor sistemului propus și selecție varianta optima; stabilirea procedurii de evaluare a calitatii si conditiilor de acceptare a sistemului; evaluarea efectelor obţinute din sistem.

6. La etapa 2.4 „Întocmește un raport asupra lucrărilor efectuate”, întocmește și întocmește un raport care să conțină o descriere a lucrărilor efectuate la etapa, o descriere și o justificare a versiunii propuse a conceptului de sistem.

7. La etapa 3.1 „Elaborarea și aprobarea specificațiilor tehnice pentru realizarea unei centrale nucleare”, elaborarea, execuția, coordonarea și aprobarea specificațiilor tehnice pentru centrala nucleară și, dacă este cazul, specificațiile tehnice pentru părți ale centralei nucleare. centrale electrice sunt executate.

8. La etapa 4.1 „Elaborarea soluțiilor preliminare de proiectare pentru sistem și părțile sale” se determină: funcțiile AS; funcțiile subsistemelor, scopurile și efectele acestora; alcătuirea complexelor de sarcini și a sarcinilor individuale; concepte ale bazei de informații, structura sa extinsă; funcții ale sistemului de management al bazelor de date; alcătuirea sistemului informatic; funcțiile și parametrii software-ului de bază.

9. La etapa 5.1 „Elaborarea soluțiilor de proiectare pentru sistem și părțile sale”, acestea asigură dezvoltarea de soluții generale pentru sistem și părțile sale, structura funcțional-algoritmică a sistemului, funcțiile personalului și structura organizationala, asupra structurii mijloacelor tehnice, asupra algoritmilor de rezolvare a problemelor și a limbajelor utilizate, asupra organizării și întreținerii bazei informaționale, asupra sistemului de clasificare și codificare a informațiilor, pe software.

10. La etapele 4.2 și 5.2 " Dezvoltarea documentației privind CNE și părțile sale” efectuează elaborarea, execuția, coordonarea și aprobarea documentației în măsura în care este necesar pentru a descrie setul complet de decizii de proiectare luate și suficient pentru implementarea în continuare a lucrărilor de creare a CNE. Tipuri de documente - conform GOST 34.201.

11. La etapa 5.3 „Elaborarea și executarea documentației pentru furnizarea produselor pentru completarea CNE și (sau) cerințe tehnice (specificații tehnice) pentru dezvoltarea acestora”, se realizează pregătirea și execuția documentației pentru furnizarea produselor pentru completarea CNE. ; determinarea cerințelor tehnice și întocmirea specificațiilor tehnice pentru dezvoltarea produselor care nu sunt produse în serie.

12. La etapa 5.4 „Elaborarea sarcinilor de proiectare în părțile adiacente ale proiectului de automatizare”, ei elaborează, formalizează, coordonează și aprobă sarcini de proiectare în părțile adiacente ale proiectului obiect de automatizare pentru efectuarea lucrărilor de construcții, electrice, sanitare și a altor lucrări pregătitoare aferente la creația AC.

13. La etapa 6.1 „Elaborarea documentației de lucru pentru sistem și părțile acestuia”, se elaborează documentația de lucru care conține toate informațiile necesare și suficiente pentru a asigura implementarea lucrărilor de punere în funcțiune și funcționare a CNE, precum și pentru menținerea acestuia. nivelul caracteristicilor operaționale (calității) sistemului în conformitate cu deciziile de proiectare adoptate, execuția, coordonarea și aprobarea acestuia. Tipuri de documente - conform GOST 34.201.

14. La etapa 6.2 „Dezvoltarea sau adaptarea programelor”, sunt dezvoltate programe și software de sistem, selectarea, adaptarea și (sau) conectarea software-ului achiziționat și dezvoltarea documentației programului în conformitate cu GOST 19.101.

15. La etapa 7.1 „Pregătirea obiectului de automatizare pentru punerea în funcțiune a instalației”, se lucrează la pregătirea organizatorică a obiectului de automatizare pentru punerea în funcțiune a instalației, inclusiv: implementarea soluțiilor de proiectare pentru structura organizatorică a instalației. plantă; furnizarea departamentelor unității de management cu materiale didactice și metodologice; implementarea clasificatoarelor de informații.

16. La etapa 7.2 „Instruirea personalului”, personalul este instruit și se verifică capacitatea acestuia de a asigura funcționarea instalației.

17. La etapa „Completarea difuzoarelor cu produse furnizate” asigură primirea componentelor de producție în serie și individuale, materialelor și produselor de instalare. Se efectuează controlul de calitate la intrare.

18. La etapa 7.4 „Lucrări de construcție și instalare” se efectuează: lucrări de construcție a clădirilor (incintelor) specializate pentru găzduirea echipamentelor tehnice și a personalului CNE; construirea de canale de cablu; efectuarea de lucrări la instalarea echipamentelor tehnice și a liniilor de comunicație; testarea echipamentelor tehnice instalate; livrarea echipamentelor tehnice pentru punerea în funcțiune.

19. La etapa 7.5 „Dare în funcțiune”, efectuează reglarea autonomă a hardware-ului și software-ului, încărcarea informațiilor în baza de date și verificarea sistemului de întreținere a acesteia; configurarea completă a tuturor instrumentelor de sistem.

20. La etapa 7.6 „Efectuarea testelor preliminare” se efectuează următoarele:

• testarea difuzoarelor pentru funcționarea și conformitatea cu specificațiile tehnice în conformitate cu programul și metodologia încercărilor preliminare;
• depanarea și efectuarea de modificări la documentația CNE, inclusiv documentația operațională în conformitate cu raportul de testare;
• executarea unui certificat de acceptare a CNE pentru exploatare de probă.

21. La etapa 7.7 „Efectuarea operațiunii de probă” se efectuează exploatarea de probă a CNE; analiza rezultatelor exploatării de probă a CNE; modificarea (dacă este necesar) a software-ului AS; ajustarea suplimentară (dacă este necesar) a echipamentelor tehnice CNE; executarea unui certificat de finalizare a operațiunii de probă.

22. La etapa 7.8 „Efectuarea testelor de acceptare” se efectuează următoarele:

• testarea conformității cu specificațiile tehnice în conformitate cu programul și metodologia de testare de acceptare;
• analiza rezultatelor testelor AS și eliminarea deficiențelor identificate în timpul testării;
• executarea unui act de acceptare a CNE în exploatare permanentă.

23. La etapa 8.1 „Efectuarea lucrărilor în conformitate cu obligațiile de garanție” se efectuează lucrări pentru eliminarea deficiențelor identificate în timpul funcționării CNE în perioadele de garanție stabilite, precum și pentru efectuarea modificărilor necesare în documentația pentru CNE.

24. La etapa 8.2 „Service post-garanție” se lucrează la:

• analiza funcționării sistemului;
• identificarea abaterilor caracteristicilor efective de exploatare ale CNE de la valorile de proiectare;
• stabilirea cauzelor acestor abateri;
• eliminarea deficiențelor identificate și asigurarea stabilității caracteristicilor operaționale a CNE;
• efectuarea modificărilor necesare în documentația pentru vorbitori.

ANEXA 2. Referință

LISTA ORGANIZAȚILOR PARTICIPANTE LA CREAREA AU

1. Organizația client (utilizator) pentru care va fi creat CNE și care asigură finanțarea, acceptarea lucrărilor și funcționarea CNE, precum și realizarea lucrărilor individuale de realizare a CNE.

2. Organizația de dezvoltare, care desfășoară lucrări la crearea CNE, oferind clientului un set de servicii științifice și tehnice pt. diferite etapeși etapele de creare, precum și dezvoltarea și furnizarea diverselor instrumente software și hardware pentru AS.

3. O organizație furnizor care produce și furnizează software și hardware la comanda dezvoltatorului sau clientului.

4. Organizație-proiectant general al instalației de automatizare.

5. Organizații de proiectare diverse părți proiectarea unei instalații de automatizare pentru construcții, lucrări electrice, sanitare și alte lucrări pregătitoare legate de crearea de centrale nucleare.

6. Construcție, instalare, punere în funcțiune și alte organizații.

Note:

1. În funcție de condițiile de creare a CNE, sunt posibile diferite combinații de funcții ale clientului, dezvoltatorului, furnizorului și altor organizații implicate în crearea CNE.

2. Etapele și fazele lucrării pe care le efectuează pentru crearea AS sunt determinate pe baza acestui standard.

DATE INFORMAȚII

1. DEZVOLTAT ȘI INTRODUS de Comitetul de Stat al URSS pentru managementul calității produselor și standarde

DEZVOLTATORII

Yu.H. Vermishev, doctor în inginerie. științe; Da.G. Vilenchik; IN SI. Voropaev, doctor în inginerie. științe; L.M. Seidenberg, Ph.D. tehnologie. științe; Yu.B. Irz, Ph.D. tehnologie. științe; V.D. Kostyukov, Ph.D. tehnologie. științe; M.A. Labutin, cond. tehnologie. științe; N.P. Leskovskaia; ESTE. Mitiaev; V.F. Popov (conducător de subiect); S.V. Garshina; A.I. Surditate; SUD. Jukov, Ph.D. științe; Z.P. Zadubovskaya; V.G. Ivanov; Yu.I. Karavanov, Ph.D. științe; A.A. Klochkov; V.Yu. Korolev; IN SI. Makhnach, Ph.D. tehnologie. științe; S.B. Mihailev, doctor în inginerie. științe; V.N. Petrikevici; V.A. Rakhmanov, Ph.D. econ. științe; A.A. Ratkovici; R.S. Sedegov, doctor în economie. științe; N.V. Stepanchikova; DOMNIȘOARĂ. Surovets; A.V. Flegentov; L.O. Khvilevsky, Ph.D. tehnologie. științe; VC. Chistov, Ph.D. econ. stiinte

2. APROBAT ȘI INTRAT ÎN VIGOARE prin Rezoluția Comitetului de Stat al URSS pentru Managementul Calității Produselor și Standarde din 29 decembrie 1990 Nr. 3469