Tz katrai sistēmai. Informācijas sistēmas izveides darba uzdevums

Tehniskais uzdevums radīt informācijas sistēma

Pamatojoties uz GOST 34.602-89
tehnisko specifikāciju rakstīšanai automatizētas sistēmas vadība datēta ar 01.01.1990.

1. VISPĀRĪGI NOTEIKUMI

1.1. TK ir galvenais dokuments, kas nosaka informācijas sistēmas (turpmāk tekstā IS) izveides (izstrādes vai modernizācijas - turpmāk - izveide) prasības un kārtību, saskaņā ar kuru tiek veikta IS izstrāde un pieņemšana. pēc nodošanas ekspluatācijā.

1.2. TK ir izstrādāta sistēmai kopumā, paredzēta darbam neatkarīgi vai kā citas sistēmas sastāvdaļa.

1.3. Prasības attiecībā uz IP šajā standartā noteiktajā apjomā var iekļaut jaunizveidota informatizācijas objekta projektēšanas uzdevumā. Šajā gadījumā TK nav izstrādāta.

1.4. TOR ietvertajām prasībām jāatbilst pašreizējam attīstības līmenim informācijas tehnoloģijas un nepakļauties līdzīgām prasībām labākajiem mūsdienu vietējiem un ārvalstu kolēģiem. TOR noteiktajām prasībām nevajadzētu ierobežot sistēmas izstrādātāju efektīvāko tehnisko, priekšizpētes un citu risinājumu meklēšanā un ieviešanā.

1.5. TOR ietver tikai tās prasības, kas papildina prasības šāda veida sistēmām un ir noteiktas pēc konkrētā objekta, kuram sistēma tiek veidota, specifika.

1.6. Izmaiņas TOR tiek formalizētas ar pielikumu vai protokolu, ko parakstījis klients un izstrādātājs. Papildinājums vai norādītais protokols ir IP neatņemama TOR sastāvdaļa. TK titullapā jābūt ierakstam “Derīgs no ...”.

2. SASTĀVS UN SATURS

2.1. TOR satur šādas sadaļas, kuras var iedalīt apakšsadaļās:

    Galvenā informācija;

    sistēmas izveides (attīstīšanas) mērķis un mērķi;

    objektu īpašības;

    Sistēmas prasības;

    sistēmas kontroles un pieņemšanas kārtība;

    prasības darba sastāvam un saturam, lai sagatavotu izstrādes objektu sistēmas nodošanai ekspluatācijā;

    dokumentācijas prasības;

    attīstības avoti.
    Pieteikumus var iekļaut darba uzdevumā.

2.2. Atkarībā no projekta veida, mērķa, specifikas un sistēmas darbības apstākļiem ir atļauts noformēt TPR sadaļas pieteikumu veidā, ieviest papildu, izslēgt vai apvienot TPR apakšsadaļas.

Sistēmas daļu TOR neietver sadaļas, kas dublē visu TOR sadaļu saturu.

2.3. Nodaļā " Galvenā informācija” norāda:

    pilns sistēmas nosaukums un tās nosaukums simbols;

    tēmas šifrs vai līguma šifrs (numurs);

    sistēmas izstrādātāja un pasūtītāja (lietotāja) uzņēmumu nosaukumus un to rekvizītus;

    dokumentu saraksts, uz kuru pamata sistēma tiek veidota, kas un kad šos dokumentus apstiprinājis;

    plānotos datumus sistēmas izveides darbu uzsākšanai un pabeigšanai;

    informāciju par darbu finansēšanas avotiem un kārtību;

    kārtība, kādā tiek formalizēti un iesniegti klientam darba rezultāti pie sistēmas (tās daļu) izveides, atsevišķu līdzekļu (aparatūras, programmatūras, informācijas) un programmatūras un aparatūras (programmatūras un metodisko) kompleksu izgatavošanas un regulēšanas. sistēma.

2.4. Sadaļa “Sistēmas izveides (attīstīšanas) mērķis un uzdevumi” sastāv no apakšsadaļām:

    sistēmas mērķis;

    sistēmas mērķis.

2.4.1. Apakšsadaļā “Sistēmas mērķis” norāda sistēmas darbības veidu (pārvaldība, projektēšana u.c.) un informatizācijas objektu (objektu) sarakstu, kuros to paredzēts izmantot.

2.4.2. Apakšsadaļā “Sistēmas izveides mērķi” norādīti informatizācijas objekta tehnisko, tehnoloģisko, ražošanas-ekonomisko vai citu rādītāju nosaukumi un nepieciešamās vērtības, kas jāsasniedz IS izveides rezultātā, un norāda sistēmas izveides mērķu sasniegšanas vērtēšanas kritērijus.

2.5. Sadaļā “Informatizācijas objekta raksturojums” tie sniedz:

    īsa informācija par informatizācijas objektu vai saites uz dokumentiem, kas satur šādu informāciju;

    informācija par automatizācijas objekta darbības apstākļiem.

2.6. Sadaļa Sistēmas prasības sastāv no šādām apakšsadaļām:

    prasības sistēmai kopumā;

    prasības sistēmas veicamajām funkcijām (uzdevumiem);

    prasības drošības veidiem.

Šajā IS TOR sadaļā ietverto sistēmas prasību sastāvs tiek noteikts atkarībā no veida, mērķa, īpašām iezīmēm un darbības apstākļiem. specifiska sistēma.

2.6.1. Apakšsadaļā “Prasības sistēmai kopumā” norādiet:

    prasības sistēmas struktūrai un darbībai;

    prasības sistēmas personāla skaitam un kvalifikācijai un tās darba režīmam;

    galamērķa rādītāji;

    uzticamības prasības;

    drošības prasības;

    ergonomikas un tehniskās estētikas prasības;

    prasības sistēmas komponentu darbībai, apkopei, remontam un uzglabāšanai;

    prasības informācijas aizsardzībai pret nesankcionētu piekļuvi;

    prasības informācijas drošībai negadījumu gadījumā;

    prasības aizsardzībai no ārējās ietekmes ietekmes;

    prasības attiecībā uz patenta tīrību;

    standartizācijas un unifikācijas prasības;

    Papildu prasības.

2.6.1.1. Sistēmas struktūras un darbības prasības ietver:

    apakšsistēmu saraksts, to mērķis un galvenie raksturlielumi, prasības hierarhijas līmeņu skaitam un sistēmas centralizācijas pakāpei;

    prasības saziņas metodēm un līdzekļiem informācijas apmaiņai starp sistēmas komponentiem;

    prasības veidojamās sistēmas starpsavienojumu raksturlielumiem ar blakus sistēmām, prasības tās savietojamībai, tai skaitā instrukcijas, kā apmainīties ar informāciju (automātiski, nosūtot dokumentus, pa telefonu u.c.);

    prasības sistēmas darbības režīmiem;

    sistēmas diagnostikas prasības;

    sistēmas attīstības, modernizācijas perspektīvas.

2.6.1.2. Prasībās par IS personāla skaitu un kvalifikāciju ir norādīts:

    prasības IS personāla (lietotāju) skaitam;

    prasības personāla kvalifikācijai, apmācības un zināšanu un prasmju kontroles kārtība;

    nepieciešamo IS personāla darba režīmu.

2.6.1.3. Prasībās IS mērķa indikatoriem ir norādītas to parametru vērtības, kas raksturo sistēmas atbilstības pakāpi tās mērķim.

2.6.1.4. Uzticamības prasības ietver:

    uzticamības rādītāju sastāvs un kvantitatīvās vērtības sistēmai kopumā vai tās apakšsistēmām;

    to ārkārtas situāciju saraksts, kurām būtu jāreglamentē uzticamības prasības, un atbilstošo rādītāju vērtības;

    uzticamības prasības tehniskajiem līdzekļiem un programmatūra;

    prasības ticamības rādītāju novērtēšanas un uzraudzības metodēm dažādos sistēmas izveides posmos saskaņā ar spēkā esošajiem normatīvajiem un tehniskajiem dokumentiem.

2.6.1.5. Drošības prasības ietver prasības drošības nodrošināšanai sistēmas piegādes, nodošanas ekspluatācijā, ekspluatācijas un apkopes laikā.

2.6.1.6. Ergonomikas un tehniskās estētikas prasībās ir iekļauti IS rādītāji, kas norāda nepieciešamo cilvēka un mašīnas mijiedarbības kvalitāti un personāla darba apstākļu komfortu.

2.6.1.7. Prasības informācijas aizsardzībai pret nesankcionētu piekļuvi ietver nozares un klienta informācijas vides noteiktās prasības.

2.6.1.8. Informācijas drošības prasībās ir ietverts notikumu saraksts: avārijas, tehnisko līdzekļu atteices (t.sk. jaudas zudums) u.c., kurās jānodrošina informācijas drošība sistēmā.

2.6.1.9. Patenta tīrības prasības norāda valstu sarakstu, attiecībā uz kurām jānodrošina sistēmas un tās daļu patentētā tīrība.

2.6.1.10. Papildu prasības ietver īpašas prasības pēc sistēmas izstrādātāja vai klienta ieskatiem.

2.6.2. Apakšsadaļā “Prasības funkcijām (uzdevumiem)”, ko veic sistēma, ir norādīts:

    katrai apakšsistēmai automatizējamo funkciju, uzdevumu vai to kompleksu (arī to, kas nodrošina sistēmas daļu mijiedarbību) saraksts;

    veidojot sistēmu divās vai vairākās rindās - funkcionālo apakšsistēmu, atsevišķu funkciju vai uzdevumu saraksts, kas tiek ieviesti 1. un turpmākajās rindās;

    katras funkcijas, uzdevuma (vai uzdevumu kopas) īstenošanas laika grafiks;

    prasības katras funkcijas (uzdevuma vai uzdevumu kopas) izpildes kvalitātei, izvadinformācijas pasniegšanas formai, nepieciešamās precizitātes un izpildes laika raksturlielumiem, prasības funkciju grupas izpildes vienlaicīgumam, uzticamībai. no rezultātiem;

    saraksts un atteices kritēriji katrai funkcijai, kurai noteiktas uzticamības prasības.

2.6.3. Apakšsadaļā “Prasības atbalsta veidiem” atkarībā no sistēmas veida ir dotas prasības matemātiskajam, informatīvajam, lingvistiskajam, programmatūras, tehniskajam, metroloģiskajam, organizatoriskajam, metodiskajam un cita veida sistēmas atbalstam.

2.6.3.2. Sistēmas informatīvajam atbalstam tiek izvirzītas šādas prasības:

    uz datu sastāvu, struktūru un kārtošanas veidiem sistēmā;

    informācijas apmaiņai starp sistēmas komponentiem;

    informācijas savietojamībai ar blakus sistēmām;

    par datu bāzu pārvaldības sistēmu izmantošanu;

    uz datu vākšanas, apstrādes, pārsūtīšanas sistēmā un datu prezentēšanas procesa struktūru;

    datu aizsardzībai;

    kontrolēt, uzglabāt, atjaunināt un atjaunot datus;

2.6.3.3. Sistēmas lingvistiskajam atbalstam ir dotas prasības programmēšanas valodu lietošanai sistēmā. augsts līmenis, mijiedarbības valodas starp lietotājiem un sistēmas tehniskajiem līdzekļiem, kā arī prasības datu kodēšanai un dekodēšanai, datu ievades-izvades valodas, datu apstrādes valodas, tēmas aprakstīšanas līdzekļi un dialoga organizēšanas metodes.

2.6.3.4. Sistēmas programmatūrai ir norādīts iegādātās programmatūras saraksts, kā arī prasības:

    programmatūras atkarībai no darbības vides;

    programmatūras kvalitātei, kā arī tās nodrošināšanas un kontroles metodēm;

2.6.3.5. Sistēmas tehniskajam atbalstam tiek izvirzītas šādas prasības:

    uz tehnisko līdzekļu veidiem, tai skaitā tehnisko līdzekļu kompleksu veidiem, programmatūras un aparatūras kompleksiem un citām sastāvdaļām, kas ir pieņemamas lietošanai sistēmā;

    sistēmas tehniskā nodrošinājuma līdzekļu funkcionālajām, konstruktīvajām un darbības īpašībām.

2.6.3.6. Metroloģiskā atbalsta prasības ietver:

    provizoriskais mērīšanas kanālu saraksts;

    prasības parametru mērījumu precizitātei un (vai) mērīšanas kanālu metroloģiskajiem raksturlielumiem;

    sistēmas tehnisko līdzekļu metroloģiskās savietojamības prasības;

    sistēmas vadības un skaitļošanas kanālu sarakstu, kuriem nepieciešams novērtēt precizitātes raksturlielumus;

    sistēmas mērīšanas kanālu sastāvā esošās aparatūras un programmatūras metroloģiskā nodrošinājuma prasības, instrumenti, iebūvēta vadība, mērīšanas kanālu un sistēmas nodošanā ekspluatācijā un testēšanā izmantoto mērinstrumentu metroloģiskā piemērotība;

    metroloģiskās sertifikācijas veids (valsts vai departaments) ar norādi par tās īstenošanas kārtību un organizācijām, kas veic sertifikāciju.

2.6.3.7. Organizatoriskajam atbalstam tiek izvirzītas šādas prasības:

    sistēmas funkcionēšanā iesaistīto vai darbības nodrošināšanā iesaistīto vienību struktūrai un funkcijām;

    sistēmas darbības organizācijai un IS personāla un informatizācijas objekta personāla mijiedarbības kārtībai;

    aizsardzībai pret sistēmas personāla kļūdainu rīcību.

2.7. Sadaļā “Sistēmas izveides (izstrādes) darba sastāvs un saturs” jāiekļauj sistēmas izveides posmu un darba posmu saraksts, to ieviešanas laiks, darbu veicošo organizāciju saraksts, saites uz dokumentiem, kas apliecina šo organizāciju piekrišanu piedalīties sistēmas izveidē, vai ierakstu, kurā noteikta atbildīgā persona (pasūtītājs vai izstrādātājs) par šo darbu veikšanu.

AT šajā sadaļā citē arī:

    attiecīgo darba posmu un posmu beigās uzrādāmo dokumentu saraksts;

    tehniskās dokumentācijas pārbaudes veids un kārtība (pārbaudāmās dokumentācijas posms, posms, apjoms, organizācija-eksperts);

    darba programma, kuras mērķis ir nodrošināt izstrādājamās sistēmas nepieciešamo uzticamības līmeni (ja nepieciešams);

    metroloģiskā atbalsta darbu saraksts visos sistēmas izveides posmos, norādot to termiņus un izpildorganizācijas (ja nepieciešams).

2.8. Sadaļā “Sistēmas uzraudzības un pieņemšanas kārtība” norāda:

    sistēmas un tās sastāvdaļu veidi, sastāvs, apjoms un pārbaudes metodes;

    Vispārīgās prasības uz darbu pieņemšanu pa posmiem, pieņemšanas dokumentācijas saskaņošanas un apstiprināšanas kārtību;

2.9. Sadaļā “Prasības darbu sastāvam un saturam, lai sagatavotu automatizācijas objektu sistēmas nodošanai ekspluatācijā” nepieciešams nodrošināt galveno darbību un to veicēju sarakstu, kas jāveic, sagatavojot projektu IR ekspluatācijā.

Galveno darbību saraksts ietver:

    informācijas ienešana sistēmā (atbilstoši informācijas un lingvistiskā atbalsta prasībām);

    tādu apstākļu radīšana projekta funkcionēšanai, pie kuriem tiek garantēta izveidotās sistēmas atbilstība TPR ietvertajām prasībām;

    sistēmas funkcionēšanai nepieciešamo apakšnodaļu un dienestu izveide;

    personāla komplektēšanas un personāla apmācības noteikumi un kārtība.

2.10. Sadaļā "Dokumentācijas prasības" ir norādīts:

    izstrādājamo dokumentu komplektu un veidu sarakstu, vienojoties sistēmas izstrādātājam un Pasūtītājam;
    uz mašīnu datu nesējiem izsniegto dokumentu saraksts;

    ja nav valsts standartu, kas nosaka prasības sistēmas elementu dokumentēšanai, tie papildus ietver prasības šādu dokumentu sastāvam un saturam.

2.11. Sadaļā “Izstrādes avoti” jāuzskaita dokumenti un informatīvie materiāli, uz kuru pamata tika izstrādāts TO un kuri jāizmanto sistēmas veidošanā.

3. KONSTRUKCIJAS NOTEIKUMI

3.1. TOR sadaļas un apakšsadaļas jāievieto secībā, kas noteikta 2. punktā. 2 no šī standarta.

3.2. Lapu (lapu) numurus noliek, sākot no pirmās lapas aiz titullapas, lapas augšējā daļā (virs teksta, vidū) pēc TK koda apzīmējuma uz IC.

3.3. Titullapā ir ievietoti pasūtītāja, izstrādātāja un koordinējošo uzņēmumu paraksti, kas ir aizzīmogoti. Ja nepieciešams, titullapu noformē uz vairākām lapām. Pēdējā lapā ievietoti TK izstrādātāju un TK par IP projekta apstiprināšanā un izskatīšanā iesaistīto amatpersonu paraksti.

TOR titullapas forma dota 2.pielikumā TOR pēdējās lapas forma dota 3.pielikumā.

3.4. TOR papildinājuma titullapa tiek noformēta tāpat kā darba uzdevuma titullapa. Nosaukuma “Uzdevumu noteikumi” vietā tiek rakstīts “Maiņstrāvas TOR... papildinājums Nr. ...”.

3.5. Nākamajās TOR papildinājuma lapās tiek ievietots izmaiņu iemesls, izmaiņu saturs un saites uz dokumentiem, saskaņā ar kuriem šīs izmaiņas tiek veiktas.

3.8. Iesniedzot TPR papildinājuma tekstu, jānorāda galveno TP attiecīgo punktu, apakšpunktu, tabulu uc numuri un vārdi "aizstāt", "papildināt", "dzēst", "norādīt jauns izdevums”.

TK FOR IP IZSTRĀDES, LĪGŠANAS UN APSTIPRINĀŠANAS KĀRTĪBA

    TOR projektu izstrādā sistēmas izstrādātājs, piedaloties pasūtītājam, pamatojoties uz tehniskajām prasībām(pieteikumi, taktiskās un tehniskās specifikācijas utt.).
    Konkursa darba organizēšanā TOR projekta variantus izskata pasūtītājs, kurš vai nu izvēlas sev vēlamo variantu, vai arī, pamatojoties uz salīdzinošo analīzi, sagatavo AC galīgo variantu, piedaloties topošais IS izstrādātājs.

    Nepieciešamību TOR projekta saskaņošanai ar valsts uzraudzības iestādēm un citām ieinteresētajām organizācijām kopīgi nosaka sistēmas pasūtītājs un IP projekta TOR projekta izstrādātājs,
    Darbu pie TK projekta apstiprināšanas IK kopīgi veic TOR izstrādātājs un sistēmas pasūtītājs, katrs savas ministrijas (departamenta) organizācijās.

    TOR projekta apstiprināšanas termiņš katrā organizācijā nedrīkst pārsniegt 15 dienas no tā saņemšanas dienas. ToR projekta kopijas (kopijas) ieteicams nosūtīt apstiprināšanai vienlaikus visām organizācijām (nodaļām).

    Komentāri par TOR projektu iesniedzami ar tehnisku pamatojumu. Lēmumi par komentāriem ir jāpieņem ToR projekta izstrādātājam un sistēmas pasūtītājam, pirms tiek apstiprināts IS uzdevums.

    Ja, vienojoties par TK projektu, starp izstrādātāju un pasūtītāju (vai citām ieinteresētajām organizācijām) radušās domstarpības, tad tiek sastādīts domstarpību protokols (patvaļīga forma) un noteiktajā kārtībā pieņemts konkrēts lēmums.

    TOR projekta apstiprinājumu atļauts noformēt kā atsevišķu dokumentu (vēstule). Šajā gadījumā zem virsraksta "Saskaņots" izveidojiet saiti uz šo dokumentu.

    TOR apstiprināšanu veic sistēmas izstrādātāja un pasūtītāja uzņēmumu vadītāji.

    Apstiprinātās rokasgrāmatas kopijas 10 dienu laikā pēc apstiprināšanas Nolikuma izstrādātājs nosūta sistēmas izveides dalībniekiem.

    Norādījumu papildinājumu saskaņošana un apstiprināšana tiek veikta IP noteiktajā kārtībā.

    Izmaiņas TOR nav atļauts apstiprināt pēc sistēmas vai tās rindas iesniegšanas akcepttestiem.

Šis standarts attiecas uz automatizētām sistēmām (AS), kas paredzētas dažāda veida darbību (vadības, projektēšanas, izpētes utt.) automatizēšanai, ieskaitot to kombinācijas, un nosaka dokumenta "Uzdevumu izveides noteikumi" sastāvu, saturu, izdošanas noteikumus attīstības vai modernizācijas) sistēmas” (turpmāk – AES TK).
Ieteicamā procedūra atomelektrostaciju tehnisko specifikāciju izstrādei, apstiprināšanai un apstiprināšanai ir dota 1. pielikums.

1. Vispārīgie noteikumi.

1.1. AES TO ir galvenais dokuments, kas nosaka prasības un kārtību automatizētas sistēmas izveidei (izstrādei vai modernizācijai - tālākai izveidei), saskaņā ar kuru tiek veikta AES izstrāde un pieņemšana, nododot ekspluatācijā.
1.2. Atomelektrostaciju specifikācijas ir izstrādātas sistēmai kopumā, paredzētas darbam neatkarīgi vai kā citas sistēmas sastāvdaļa.
Papildus var izstrādāt tehniskās specifikācijas AES daļām: AES apakšsistēmām, AES uzdevumu kompleksiem u.c., atbilstoši šī standarta prasībām; aparatūras komponentiem un programmatūras un aparatūras kompleksiem atbilstoši ESKD un SRPP standartiem; programmatūrai atbilstoši ESPD standartiem; informācijas produktiem saskaņā ar GOST 19.201 un NTD, kas ir spēkā AES klienta nodaļā.
Piezīme. TOR, kas paredzēts automatizētai vadības sistēmai savstarpēji saistītu objektu grupai, jāiekļauj tikai prasības, kas ir kopīgas objektu grupai. Atsevišķa vadības objekta īpašās prasības ir jāatspoguļo šī objekta ACS TOR.
1.3. Prasības AU šī standarta noteiktajā apjomā var iekļaut jaunizveidota automatizācijas objekta projektēšanas uzdevumā. Šajā gadījumā atomelektrostaciju tehniskās specifikācijas netiek izstrādātas.
1.4. TOR ietvertajām prasībām AES ir jāatbilst pašreizējam zinātnes un tehnoloģiju attīstības līmenim un nedrīkst būt zemākas par līdzīgām prasībām labākajiem mūsdienu vietējiem un ārvalstu analogiem.
TOR noteiktajām prasībām AES nevajadzētu ierobežot sistēmas izstrādātāju efektīvāko tehnisko, priekšizpētes un citu risinājumu meklējumos un ieviešanā.
1.5. AES specifikācijas tiek izstrādātas, pamatojoties uz sākotnējiem datiem, tostarp tiem, kas ietverti posma "AES izveides izpēte un pamatojums" gala dokumentācijā, kas noteikta GOST 24.601.
1.6. Atomelektrostaciju TOR ietver tikai tās prasības, kas papildina pašreizējā NTD ietvertās prasības šāda veida sistēmām (ACS, CAD, ASNI u.c.), un tās nosaka konkrētā objekta specifika, kurai sistēma ir paredzēta. tiek radīts.
1.7. Izmaiņas TOR AES tiek formalizētas ar papildinājumu vai protokolu, ko paraksta pasūtītājs un izstrādātājs. Papildinājums vai norādītais protokols ir AES darba noteikumu neatņemama sastāvdaļa. TK titullapā par AC jābūt ierakstam "Derīgs no ...".

2. Sastāvs un saturs.

2.1. AES TO ir šādas sadaļas, kuras var iedalīt apakšsadaļās:
1) vispārīga informācija;
2) sistēmas izveides (attīstīšanas) mērķis un mērķi;
3) automatizācijas objektu raksturojums;
4) sistēmas prasības;
5) sistēmas izveides darba sastāvs un saturs;
6) sistēmas kontroles un pieņemšanas kārtība;
7) prasības darba sastāvam un saturam, lai sagatavotu automatizācijas objektu sistēmas nodošanai ekspluatācijā;
8) prasības dokumentācijai;
9) attīstības avoti.
Pieteikumus var iekļaut ĀS TOR.
2.2. Atkarībā no automatizācijas objekta veida, mērķa, specifiskām iezīmēm un apstākļiem (sistēmas funkcionēšanas) ir atļauts noformēt TOR sadaļas pieteikumu veidā, ieviest papildu, izslēgt vai apvienot TOR apakšsadaļas.
Sistēmas daļu TOR neietver sadaļas, kas dublē AES TOR sadaļu saturu kopumā.
2.3. Sadaļā "Vispārīga informācija" norādiet:
1) sistēmas pilns nosaukums un tās simbols;
2) tēmas šifrs vai līguma šifrs (numurs);
3) sistēmas izstrādātāja un pasūtītāja (lietotāja) uzņēmumu (asociāciju) nosaukums un rekvizīti;
4) dokumentu saraksts, uz kuru pamata sistēma tiek veidota, kas un kad šos dokumentus apstiprinājis;
5) plānotos datumus sistēmas izveides darbu uzsākšanai un pabeigšanai;
6) informāciju par darbu finansēšanas avotiem un kārtību;
7) kārtība, kādā noformējami un pasūtītājam tiek iesniegti sistēmas (tās daļu) izveides, atsevišķu līdzekļu (aparatūras, programmatūras, informācijas) un programmatūras un aparatūras (programmatūras un metodiskās) izgatavošanas un pielāgošanas darba rezultāti; sistēmas kompleksi.
2.4. Sadaļa "Sistēmas izveides (attīstīšanas) mērķis un uzdevumi" sastāv no apakšsadaļām:
1) sistēmas mērķis;
2) sistēmas izveides mērķis.
2.4.1. Apakšsadaļā "Sistēmas mērķis" norādiet automatizētās darbības veidu (pārvaldība, projektēšana u.c.) un automatizācijas objektu (objektu) sarakstu, kuros to paredzēts izmantot.
Automatizētajām vadības sistēmām papildus tiek norādīts arī automatizēto vadības institūciju (punktu) un pārvaldīto objektu saraksts.
2.4.2. Apakšsadaļā "Sistēmas izveides mērķi" norādiet automatizācijas objekta tehnisko, tehnoloģisko, ražošanas, ekonomisko vai citu rādītāju nosaukumus un nepieciešamās vērtības, kas jāsasniedz AU izveides rezultātā, un norāda sistēmas izveides mērķu sasniegšanas vērtēšanas kritēriji.
2.5. Sadaļā "Automatizācijas objekta raksturojums" norādiet:
1) īsa informācija par automatizācijas objektu vai saites uz dokumentiem, kas satur šādu informāciju;
2) informāciju par automatizācijas objekta darbības apstākļiem un vides īpašībām.
Piezīme: CAD sadaļā papildus sniegti galvenie dizaina objektu parametri un raksturlielumi.
2.6. Sadaļa Sistēmas prasības sastāv no šādām apakšsadaļām:
1) prasības sistēmai kopumā;
2) prasības sistēmas veicamajām funkcijām (uzdevumiem);
3) prasības nodrošinājuma veidiem.
Sistēmas prasību sastāvs, kas ietverts šajā AES uzdevuma sadaļā, tiek noteikts atkarībā no konkrētas sistēmas veida, mērķa, specifiskām iezīmēm un darbības apstākļiem. Katrā apakšnodaļā ir norādītas saites uz pašreizējo NTD, kas nosaka prasības atbilstošā tipa sistēmām.
2.6.1. Apakšsadaļā "Prasības sistēmai kopumā" norādiet:

  • prasības sistēmas struktūrai un darbībai;
  • prasības sistēmas personāla skaitam un kvalifikācijai un tās darba režīmam;
  • galamērķa rādītāji;
  • uzticamības prasības;
  • drošības prasības;
  • ergonomikas un tehniskās estētikas prasības;
  • pārvietojamības prasības mobilajai AS;
  • prasības sistēmas komponentu darbībai, apkopei, remontam un uzglabāšanai;
  • prasības informācijas aizsardzībai pret nesankcionētu piekļuvi;
  • prasības informācijas drošībai negadījumu gadījumā;
  • prasības aizsardzībai no ārējās ietekmes ietekmes;
  • prasības attiecībā uz patenta tīrību;
  • standartizācijas un unifikācijas prasības;
  • Papildu prasības.
26.1.1. Sistēmas struktūras un darbības prasības ietver:
a) apakšsistēmu saraksts, to mērķis un galvenie raksturlielumi, prasības hierarhijas līmeņu skaitam un sistēmas centralizācijas pakāpei;
b) prasības saziņas metodēm un līdzekļiem informācijas apmaiņai starp sistēmas komponentiem;
c) prasības veidojamās sistēmas ar blakus sistēmām starpsavienojumu raksturlielumiem, prasības to savietojamībai, tai skaitā norādījumi, kā apmainīties ar informāciju (automātiski, nosūtot dokumentus, pa telefonu u.c.);
d) prasības sistēmas darbības režīmiem;
e) prasības sistēmas diagnosticēšanai;
f) sistēmas attīstības, modernizācijas perspektīvas.
2.6.1.2. Jā, prasībās par personāla skaitu un kvalifikāciju AU norāda:
a) prasības AES personāla (lietotāju) skaitam;
b) prasības personāla kvalifikācijai, apmācības kārtībai un zināšanu un prasmju kontrolei;
c) nepieciešamais AES personāla darbības režīms.
2.6.1.3. Prasībās AS mērķa indikatoriem ir norādītas to parametru vērtības, kas raksturo sistēmas atbilstības pakāpi tās mērķim.
ACS norādiet:
a) sistēmas pielāgošanās pakāpi procesu izmaiņām, kontroles metožu skaitu, novirzēm vadības objekta parametros;
b) pieļaujamās robežas sistēmas modernizācijai un attīstībai;
c) varbūtības un laika raksturlielumi, saskaņā ar kuriem tiek saglabāts sistēmas paredzētais mērķis.
2.6.1.4. Uzticamības prasības ietver:
a) uzticamības rādītāju sastāvs un kvantitatīvās vērtības visai sistēmai vai tās apakšsistēmām;
b) to ārkārtas situāciju saraksts, kurām būtu jāreglamentē uzticamības prasības, un atbilstošo rādītāju vērtības;
c) prasības aparatūras un programmatūras uzticamībai;
d) prasības ticamības rādītāju novērtēšanas un uzraudzības metodēm dažādos sistēmas izveides posmos saskaņā ar spēkā esošajiem normatīvajiem un tehniskajiem dokumentiem.
2.6.1.5. Drošības prasības ietver prasības drošības nodrošināšanai sistēmas tehnisko līdzekļu uzstādīšanas, nodošanas ekspluatācijā, ekspluatācijas, apkopes un remonta laikā (aizsardzība pret elektriskā strāva, elektromagnētiskie lauki, akustiskais troksnis utt.), pēc pieļaujamajiem apgaismojuma, vibrācijas un trokšņa slodzes līmeņiem.
2.6.1.6. Ergonomikas un tehniskās estētikas prasībās ir iekļauti AS indikatori, kas norāda nepieciešamo cilvēka un mašīnas mijiedarbības kvalitāti un personāla darba apstākļu komfortu.
2.6.1.7. Mobilajām AES transportējamības prasības ietver konstrukcijas prasības, kas nodrošina sistēmas tehnisko līdzekļu transportējamību, kā arī prasības transportlīdzekļiem.
2.6.1.8. Darbības, apkopes, remonta un uzglabāšanas prasības ietver:
a) darbības nosacījumi un noteikumi (režīms), kam jānodrošina sistēmas tehnisko līdzekļu (TS) izmantošana ar noteiktiem tehniskajiem rādītājiem, tostarp sistēmas TS apkopes veidiem un biežumu vai darbības pieļaujamību bez apkopes ;
b) sākotnējās prasības attiecībā uz pieļaujamajām platībām personāla un sistēmas TS izvietošanai, elektroapgādes tīklu parametriem utt.;
c) prasības apkalpojošā personāla skaitam, kvalifikācijai un viņu darba veidiem;
d) prasības rezerves produktu un ierīču komplekta sastāvam, izvietojumam un uzglabāšanas nosacījumiem;
e) prasības apkopes grafikam.
2.6.1.9. Prasības informācijas aizsardzībai pret nesankcionētu piekļuvi ietver prasības, kas noteiktas NTD, kas darbojas klienta nozarē (nodaļā).
2.6.1.10. Informācijas drošības prasībās ir ietverts notikumu saraksts: avārijas, tehnisko līdzekļu atteices (t.sk. jaudas zudums) u.c., kurās jānodrošina informācijas drošība sistēmā.
2.6.1.11. Prasībās aizsardzības līdzekļiem pret ārējām ietekmēm ir norādīts:
a) prasības AES objektu radioelektroniskajai aizsardzībai;
b) prasības attiecībā uz izturību, stabilitāti un izturību pret ārējām ietekmēm (lietošanas vide).
2.6.1.12. Patenta tīrības prasības norāda valstu sarakstu, attiecībā uz kurām jānodrošina sistēmas un tās daļu patentētā tīrība.
2.6.1.13. Standartizācijas un unifikācijas prasības ietver: rādītājus, kas nosaka nepieciešamo standarta izmantošanas pakāpi, vienotas metodes sistēmas funkciju (uzdevumu) īstenošanai, piegādāto programmatūru, tipiskās matemātiskās metodes un modeļus, standarta dizaina risinājumus, vienotas pārvaldības dokumentu formas. kas noteikti ar GOST 6.10.1, Vissavienības tehniskās un ekonomiskās informācijas klasifikatori un citu kategoriju klasifikatori atbilstoši to darbības jomai, tipisku automatizētu darbstaciju, komponentu un kompleksu izmantošanas prasībām.
2.6.1.14. Papildu prasības ietver:
a) prasības sistēmas aprīkošanai ar personāla apmācības ierīcēm (simulatoriem, citām līdzīga mērķa ierīcēm) un to dokumentāciju;
b) prasības servisa aprīkojumam, stendiem sistēmas elementu pārbaudei;
c) sistēmas prasības, kas saistītas ar īpaši nosacījumi darbība;
d) īpašas prasības pēc sistēmas izstrādātāja vai klienta ieskatiem.
2.6.2. Apakšsadaļā "Prasības sistēmas veiktajām funkcijām (uzdevumiem)" ir norādīts:
a) katrai apakšsistēmai automatizējamo funkciju, uzdevumu vai to kompleksu (tostarp to, kas nodrošina sistēmas daļu mijiedarbību) saraksts;
veidojot sistēmu divās vai vairākās rindās - funkcionālo apakšsistēmu, atsevišķu funkciju vai uzdevumu saraksts, kas tiek ieviesti 1. un turpmākajās rindās;
b) katras funkcijas, uzdevuma (vai uzdevumu kopas) īstenošanas laika grafiks;
c) prasības katras funkcijas (uzdevuma vai uzdevumu kopas) izpildes kvalitātei, izvadinformācijas pasniegšanas formai, nepieciešamās precizitātes un izpildes laika raksturlielumiem, prasības grupas izpildes vienlaicīgumam. funkcijas, rezultātu ticamība;
d) saraksts un atteices kritēriji katrai funkcijai, kurai ir noteiktas uzticamības prasības.
2.6.3. Apakšsadaļā “Prasības nodrošinājuma veidiem” atkarībā no sistēmas veida ir norādītas prasības:
1) matemātiskā,
2) informatīvs,
3) lingvistiskā,
4) programmatūra,
5) tehniskā,
6) metroloģiskais,
7) organizatoriskā,
8) metodiskais un cita veida sistēmas atbalsts.
2.6.3.1. Sistēmas matemātiskajam nodrošinājumam tiek dotas prasības sastāvam, apjomam (ierobežojumiem) un metodēm, matemātisko metožu un modeļu izmantošanai sistēmā, tipiskiem algoritmiem un izstrādājamiem algoritmiem.
2.6.3.2. Informācijas atbalstam: sistēmas nosaka prasības:
a) datu sastāvs, struktūra un metodes, kā organizēt datus sistēmā;
b) informācijas apmaiņa starp sistēmas komponentiem;
c) informācijas savietojamība ar saistītām sistēmām;
d) par vissavienības un reģistrēto republikas, nozaru klasifikatoru, vienoto dokumentu un klasifikatoru izmantošanu, kas darbojas konkrētajā uzņēmumā;
e) par datu bāzu pārvaldības sistēmu izmantošanu;
f) uz datu vākšanas, apstrādes, pārsūtīšanas sistēmā un datu prezentēšanas procesa struktūru;
g) aizsargāt datus no iznīcināšanas avāriju un sistēmas barošanas traucējumu gadījumā;
h) kontrolēt, uzglabāt, atjaunināt un atjaunot datus;
i) kārtību, kādā piešķir juridisku spēku dokumentiem, kas sagatavoti ar AES tehniskajiem līdzekļiem (saskaņā ar GOST 6.10.4).
2.6.3.3. Sistēmas lingvistiskajam atbalstam ir izvirzītas prasības augsta līmeņa programmēšanas valodu lietošanai sistēmā, lietotāja mijiedarbības valodām un sistēmas tehniskajiem līdzekļiem, kā arī prasības datu kodēšanai un dekodēšanai, datu ievadei. / izvades valodas, datu manipulācijas valodas, priekšmeta jomas aprakstīšanas līdzekļi (automatizācijas objekts), dialoga organizēšanas veidiem.
2.6.3.4. Sistēmas programmatūrai ir norādīts iegādātās programmatūras saraksts, kā arī prasības:
a) programmatūras neatkarība no izmantotās PBT un darbības vides;
b) uz programmatūras kvalitāti, kā arī uz tās nodrošināšanas un kontroles metodēm;
c) ja nepieciešams saskaņot jaunizveidoto programmatūru ar algoritmu un programmu fondu.
2.6.3.5. Sistēmas tehniskajam atbalstam tiek izvirzītas šādas prasības:
a) uz tehnisko līdzekļu veidiem, tostarp tehnisko līdzekļu kompleksu veidiem, programmatūras un aparatūras kompleksiem un citiem komponentiem, kas ir pieņemami lietošanai sistēmā;
b) sistēmas tehniskā atbalsta funkcionālajiem, dizaina un darbības parametriem.
2.6.3.6. Metroloģiskā atbalsta prasības ietver:
a) provizorisks mērīšanas kanālu saraksts;
b) prasības parametru mērījumu precizitātei un (vai) mērīšanas kanālu metroloģiskajiem raksturlielumiem;
c) sistēmas tehnisko līdzekļu metroloģiskās savietojamības prasības;
d) to sistēmas vadības un skaitļošanas kanālu saraksts, kuriem nepieciešams novērtēt precizitātes raksturlielumus;
e) prasības aparatūras un programmatūras metroloģiskajam atbalstam, kas ir daļa no sistēmas mērīšanas kanāliem, iebūvētajiem vadības instrumentiem, mērīšanas kanālu un sistēmas regulēšanā un testēšanā izmantoto mērinstrumentu metroloģiskā piemērotība;
f) metroloģiskās sertifikācijas veids (valsts vai departaments), norādot tās īstenošanas kārtību un organizācijas, kas veic sertifikāciju.
2.6.3.7. Organizatoriskajam atbalstam tiek izvirzītas šādas prasības:
a) to struktūrvienību struktūrai un funkcijām, kas iesaistītas sistēmas darbībā vai nodrošina darbību;
b) sistēmas darbības organizācijai un mijiedarbības kārtībai starp AES personālu un automatizācijas objekta personālu;
c) aizsardzība pret sistēmas personāla kļūdainu rīcību.
2.6.3.8. CAD metodiskajam nodrošinājumam tiek izvirzītas prasības sistēmas normatīvās un tehniskās dokumentācijas sastāvam (tās darbības laikā izmantoto standartu, normu, metožu u.c. saraksts).
2.7. Sadaļā "Sistēmas izveides (izstrādes) darba sastāvs un saturs" jāiekļauj sistēmas izveides posmu un posmu saraksts saskaņā ar GOST 24.601, to ieviešanas laiks, organizāciju saraksts. kas veic darbu, saites uz dokumentiem, kas apliecina šo organizāciju piekrišanu piedalīties sistēmas veidošanā, vai ierakstu, kas identificē atbildīgo personu (pasūtītāju vai izstrādātāju) par šo darbu veikšanu.
Šajā sadaļā ir sniegta arī:
1) dokumentu saraksts saskaņā ar GOST 34.201, kas uzrādīts attiecīgo darba posmu un posmu beigās;
2) tehniskās dokumentācijas pārbaudes veidu un kārtību (pārbaudāmās dokumentācijas stadija, stadija, apjoms, organizācija-eksperts);
3) darba programma, kuras mērķis ir nodrošināt izstrādājamās sistēmas nepieciešamo uzticamības līmeni (ja nepieciešams);
4) metroloģiskā atbalsta darbu saraksts visos sistēmas izveides posmos, norādot to izpildes termiņus un izpildorganizācijas (ja nepieciešams).
2.8. Sadaļā "Sistēmas uzraudzības un pieņemšanas kārtība" norāda:
1) sistēmas un tās sastāvdaļu testēšanas veidi, sastāvs, apjoms un metodes (pārbaužu veidi saskaņā ar pašreizējiem standartiem, kas piemērojami izstrādājamai sistēmai);
2) vispārīgās prasības darbu pieņemšanai pa posmiem (iesaistīto uzņēmumu un organizāciju saraksts, vieta un laiks), pieņemšanas dokumentācijas saskaņošanas un apstiprināšanas kārtība;
H) pieņemšanas komisijas statuss (valsts, starpresoru, departamentu).
2.9. Sadaļā "Prasības automatizācijas objekta sagatavošanas darbu sastāvam un saturam sistēmas nodošanai ekspluatācijā" nepieciešams nodrošināt galveno darbību un to veicēju sarakstu, kas jāveic, sagatavojot automatizācijas objektu nodošanai. ĀS darbību.
Galveno darbību saraksts ietver:
1) sistēmā ienākošās informācijas nogādāšana (atbilstoši informācijas un lingvistiskā atbalsta prasībām) formā, kas piemērota apstrādei, izmantojot datoru;
2) izmaiņas, kas jāveic automatizācijas objektā;
3) tādu apstākļu radīšana automatizācijas objekta funkcionēšanai, pie kuriem tiek garantēta izveidotās sistēmas atbilstība TOR ietvertajām prasībām;
4) sistēmas funkcionēšanai nepieciešamo apakšnodaļu un dienestu izveide;
5) personāla komplektēšanas un personāla apmācības termiņi un kārtība.
Piemēram, ACS tie sniedz:
  • izmaiņas pielietotajās vadības metodēs;
  • tādu apstākļu radīšana ACS komponentu darbībai, pie kuriem tiek garantēta sistēmas atbilstība TOR ietvertajām prasībām.

2.10. Sadaļā "Dokumentācijas prasības" ir norādīts:
1) izstrādājamo dokumentu komplektu un veidu saraksts, kas atbilst GOST 34.201 un klienta nozares NTD prasībām, saskaņots ar sistēmas izstrādātāju un pasūtītāju; uz mašīnu datu nesējiem izsniegto dokumentu saraksts; prasības mikrofilmēšanas dokumentācijai;
2) prasības starpnozaru lietojuma komponentu elementu dokumentēšanai atbilstoši ESKD un ESPD prasībām;
3) ja nav valsts standartu, kas nosaka prasības sistēmas elementu dokumentēšanai, tie papildus ietver prasības šādu dokumentu sastāvam un saturam.
2.11. Sadaļā "Izstrādes avoti" jāuzskaita dokumenti un informatīvie materiāli (priekšizpēte, atskaites par paveikto pētniecisko darbu, informatīvie materiāli par pašmāju, ārzemju analogajām sistēmām u.c.), uz kuru pamata tika izstrādāta TK un kuri būtu jāveido. izmanto sistēmas izveidošanai.
2.12. AES TOR sastāvs, ja ir apstiprinātas metodes, ietver lietojumus, kas satur:
a) sistēmas paredzamās efektivitātes aprēķins;
b) sistēmas zinātniskā un tehniskā līmeņa novērtējums.
Lietojumprogrammas tiek iekļautas AES TOR pēc vienošanās starp izstrādātāju un sistēmas klientu.

3. KONSTRUKCIJAS NOTEIKUMI

3.1. TOR sadaļas un apakšsadaļas AES ir jāizvieto 2.punktā noteiktajā kārtībā. 2 no šī standarta.
3.2. TK AU ir sastādīts saskaņā ar GOST 2.105 prasībām uz A4 formāta loksnēm saskaņā ar GOST 2.301 bez rāmja, galvenā uzraksta un papildu kolonnām tam.
Lapu (lapu) numurus noliek, sākot no pirmās lapas aiz titullapas, lapas augšpusē (virs teksta, vidū) pēc TK koda norādīšanas uz maiņstrāvas.
3.3. Rādītāju, normu un prasību vērtības parasti tiek norādītas ar maksimālajām novirzēm vai maksimālajām un minimālajām vērtībām. Ja šos rādītājus, normas, prasības viennozīmīgi reglamentē NTD, AES TOR būtu jānodrošina saite uz šiem dokumentiem vai to sadaļām, kā arī papildu prasības, kas ņem vērā veidojamās sistēmas īpatnības. Ja AES TOR izstrādes procesā nevar noteikt konkrētas rādītāju, normu un prasību vērtības, tai jāreģistrē šo rādītāju, normu un prasību noteikšanas un saskaņošanas kārtība:
"Galīgā prasība (vērtība) tiek noteikta procesā ... .. un saskaņota ar protokolu ar ... ... stadijā ... ...". Tajā pašā laikā AES TOR tekstā izmaiņas netiek veiktas.
3.4. Titullapā ievietoti pasūtītāja, izstrādātāja un koordinējošo organizāciju paraksti, kas apzīmogoti ar zīmogu. Ja nepieciešams, titullapu noformē uz vairākām lapām. Pēdējā lappusē ievietoti AES RT izstrādātāju un AES RT projekta apstiprināšanā un izskatīšanā iesaistīto amatpersonu paraksti.
TK titullapas forma par ĀS norādīta 2. pielikums. AES tehnisko specifikāciju pēdējās lapas forma ir dota 3. pielikums.
3.5. Ja nepieciešams, TK titullapā uz ĀS ir atļauts ievietot nozarē noteiktos kodus, piemēram: drošības zīmogs, darba kods, TK reģistrācijas numurs u.c.
3.6. AES darba noteikumu pielikuma titullapa noformēta tāpat kā darba uzdevuma titullapa. Nosaukuma "Noteikumi" vietā viņi raksta "AC TOR ... papildinājums Nr. ...".
3.7. Nākamajās pielikuma lapās TOR par ĀS ir ievietots izmaiņu pamatojums, izmaiņu saturs un saites uz dokumentiem, saskaņā ar kuriem šīs izmaiņas tiek veiktas.
3.8. Iesniedzot TOR papildinājuma tekstu, jānorāda attiecīgo punktu, apakšpunktu, galveno TPR tabulu par ĀS u.c. numuri un jālieto vārdi: “aizstāt”, “papildināt”, “ dzēst”, “norādīt jaunā izdevumā”.

1. pielikums

1. AES TOR projektu izstrādā sistēmas izstrādātājs, piedaloties pasūtītājam, pamatojoties uz tehniskajām prasībām (pielietojums; taktiskais un tehniskais uzdevums utt.).
Konkursa darba organizēšanā AES TPR projekta variantus izskata pasūtītājs, kurš vai nu izvēlas sev vēlamo variantu, vai, pamatojoties uz salīdzinošo analīzi, ar līdzdalību sagatavo AES TPR galīgo variantu. topošā AES attīstītāja.
2. Nepieciešamību AES RT projekta saskaņošanai ar valsts uzraudzības iestādēm un citām ieinteresētajām organizācijām kopīgi nosaka sistēmas pasūtītājs un AES RT projekta izstrādātājs.
Darbu pie AC TOR projekta apstiprināšanas kopīgi veic AES TOR izstrādātājs un sistēmas pasūtītājs, katrs savas ministrijas (resora) organizācijās.
3. Termiņš AES projekta apstiprināšanai katrā organizācijā nedrīkst pārsniegt 15 dienas no tā saņemšanas dienas. Atomelektrostaciju darba uzdevuma projekta kopijas (kopijas) ieteicams nosūtīt saskaņošanai vienlaikus visām organizācijām (nodaļām).
4. Komentāri par AES TOR projektu jāiesniedz ar tehnisko pamatojumu. Lēmumi par komentāriem ir jāpieņem AES uzdevuma projekta izstrādātājam un sistēmas pasūtītājam pirms AES uzdevuma apstiprināšanas.
5. Ja, vienojoties par TOR projektu AES, radušās domstarpības starp attīstītāju un pasūtītāju (vai citām ieinteresētajām organizācijām), tad tiek sastādīts domstarpību protokols (patvaļīga forma) un pieņemts konkrēts lēmums noteiktajā kārtībā.
6. TOR projekta apstiprināšanu AES atļauts noformēt kā atsevišķu dokumentu (vēstule). Šajā gadījumā zem virsraksta "Saskaņots" izveidojiet saiti uz šo dokumentu.
7. Atomelektrostaciju tehnisko specifikāciju apstiprināšanu veic sistēmas izstrādātāja un pasūtītāja uzņēmumu (organizāciju) vadītāji.
8. Specifikācija AES (specifikācijas papildinājums) pirms iesniegšanas saskaņošanai ir jāpārbauda specifikācijas izstrādātājas organizācijas normatīvās kontroles dienestā un, ja nepieciešams, jāpakļauj metroloģiskajai ekspertīzei.
9. AES apstiprināto noteikumu kopijas 10 dienu laikā pēc apstiprināšanas AES nolikuma izstrādātājs nosūta sistēmas izveides dalībniekiem.
10. AES uzdevuma papildinājumu saskaņošana un apstiprināšana tiek veikta AES uzdevumā noteiktajā kārtībā.
11. Izmaiņas TOR AES nav atļauts apstiprināt pēc tam, kad sistēma ir nodota kārtai pieņemšanas testiem.
12. Tehnisko specifikāciju un tās papildinājumu reģistrācija, uzskaite un glabāšana AES tiek veikta saskaņā ar GOST 2.501 prasībām.


organizācijas nosaukums - atomelektrostaciju tehnisko specifikāciju izstrādātājs

________________________________________________________
maiņstrāvas tipa nosaukums
________________________________________________________
automatizācijas objekta nosaukums
________________________________________________________
saīsinājums AS

TEHNISKAIS UZDEVUMS
Uz ____ loksnēm

Derīgs no
PIEKRĪTU
vadītājs (amats, koordinējošās organizācijas nosaukums)
Personīgais paraksts __________ Paraksta atšifrējums _______________
Ronis
datums

____________________________________
(TK kods)

MADE

PIEKRĪTU

Pieteikums(Informatīvi) Noteikumi vienota automatizēto sistēmu standartu kopuma izveidei.

1. Sākotnējie priekšnoteikumi kompleksa izveidei
1.1. Dažādu klašu un mērķu automatizētu sistēmu izveide un ieviešana tiek veikta daudzās nozarēs saskaņā ar normatīvo un tehnisko dokumentāciju, kas nosaka dažādas organizatoriskās, metodoloģiskās un tehniskās normas, noteikumus un noteikumus, kas kavē sistēmu integrāciju un to efektīvu kopīgu darbību. .
1.2. Laikā, kad PSRS Gosstandarts pieņēma lēmumu uzlabot starpnozaru standartu kompleksus, bija spēkā šādi standartu kompleksi un sistēmas, kas noteica prasības dažāda veida atomelektrostacijām:
1) viena sistēma automatizēto vadības sistēmu standarti (24. sistēma), kas attiecas uz automatizētajām vadības sistēmām, automatizētajām vadības sistēmām, automatizētajām procesu vadības sistēmām un citām organizatoriskām un ekonomiskām sistēmām;
2) standartu kopums (sistēma 23501); paplašināt līdz datorizētām projektēšanas sistēmām;
3) 14. standartu sistēmas ceturtā grupa, kas aptver ražošanas tehnoloģiskās sagatavošanas automatizētās sistēmas.
1.3. Standartu piemērošanas prakse automatizētajām vadības sistēmām, CAD, automatizētajām procesu vadības sistēmām, ASTPP ir parādījusi, ka tajās tiek izmantots viens un tas pats konceptuālais aparāts, ir daudz kopīgu standartizācijas objektu, tomēr standartu prasības savā starpā nav saskaņotas, ir atšķirības darba sastāvā un saturā, atšķirības dokumentu apzīmējumā, sastāvā, saturā un formātā u.c.
1.4. Uz singla trūkuma fona tehniskā politika AS izveides jomā standartu daudzveidība nenodrošināja plašu AS savietojamību to mijiedarbības laikā, neļāva sistēmas replicēt un kavēja perspektīvu datortehnoloģiju izmantošanas jomu attīstību.
1.5. Šobrīd notiek pāreja uz sarežģītu AS (ārvalstu CAD sistēmu - CAM) izveidi, kas ietver tehnoloģisko procesu un nozaru automatizētās vadības sistēmas, CAD - projektētājs, CAD - tehnologs, ASNI un citas sistēmas. Pretrunīgu noteikumu izmantošana, veidojot šādas sistēmas, izraisa kvalitātes pazemināšanos, darbu izmaksu pieaugumu un aizkavējas AES nodošana ekspluatācijā.
1.6. Vienots komplekss standartiem un vadlīnijām jāattiecas uz automatizētām sistēmām dažādiem mērķiem: ASNI, CAD, OASU, APCS, APCS, APCS, ASK, ASTPP, ieskaitot to integrāciju.
1.7. Izstrādājot starpnozaru dokumentus, jāņem vērā šādas ĀS kā standartizācijas objektu iezīmes:
1) darba uzdevums ir galvenais dokuments, saskaņā ar kuru tiek veikta AU izveide un tā pieņemšana no klienta puses;
2) AES parasti tiek veidotas projektējot ar pilnu sērijveida un vienreizējās ražošanas produktu komplektu un veicot būvniecības, uzstādīšanas, nodošanas ekspluatācijā un nodošanas darbus, kas nepieciešami AES nodošanai ekspluatācijā;
3) vispārīgā gadījumā AS (AS apakšsistēma) sastāv no programmatūras un aparatūras (STC), programmatūras un metodiskajiem kompleksiem (PMC) un tehniskā, programmatūras un informācijas atbalsta komponentiem.
Šo atbalsta veidu, kā arī PMK un PTK sastāvdaļas ir jāražo un jāpiegādā kā izstrādājumi rūpnieciskiem un tehniskiem nolūkiem. Sastāvdaļas var iekļaut AS kā neatkarīgas daļas vai apvienot kompleksos;
4) AS izveidei organizācijās (uzņēmumos) nepieciešama īpaša sistēmas lietotāju un apkalpojošā personāla apmācība;
5) AS un kompleksu darbību nodrošina organizatorisko un metodisko dokumentu kopums, kas tapšanas procesā tiek uzskatīts par juridiskā, metodiskā, lingvistiskā, matemātiskā, organizatoriskā un cita veida atbalsta sastāvdaļām. Šo programmatūru izstrādes procesā iegūtie atsevišķi risinājumi var tikt realizēti kā aparatūras, programmatūras vai informatīvā atbalsta sastāvdaļas;
6) pamatojoties uz tiek veikta dažādu sistēmu un kompleksu kopīga darbība un mijiedarbība vietējie tīkli DATORS.
Specifikācijas un līgumi, kas pieņemti lokālajiem datortīkliem, ir obligāti, lai nodrošinātu sistēmu, kompleksu un komponentu savietojamību.
CEN AU savstarpējā saistība ar citām sistēmām un standartu kopām.
2.1. Standartizācija AS jomā ir neatņemama sastāvdaļa darbā pie vispārinātās problēmas "Informācijas tehnoloģija".
2.2. Vienam standartu kopumam, kas reglamentē automatizēto sistēmu dokumentus, kopā ar citām sistēmām un standartu kopām ir jāveido pilnīgs normatīvais un tehniskais atbalsts AS izveides un darbības procesiem.
2.3. EKS AS jāaptver standartizācijas jomas, kas raksturīgas automatizētajām sistēmām, un tradicionālās standartizācijas jomas jāpaplašina līdz programmatūrai un aparatūrai, programmatūras un metodiskajiem kompleksiem un automatizētajām sistēmām kopumā.
2.4. Standartizācijas virzieni un uzdevumi AS izveides un darbības procesu normatīvajā un tehniskajā nodrošināšanā tiek grupēti šādi:
1) produktu tehnisko prasību noteikšana;
2) testēšanas metožu regulējums un produktu atestācijas un sertificēšanas noteikumi;
3) izstrādes noteikumu un kārtības regulējums;
4) dokumentācijas noteikumu izveide;
5) saderības nodrošināšana;
6) sistēmu funkcionēšanas organizatorisko un metodisko jautājumu regulēšana.
1.-4. virzieni ir tradicionāli produktu izstrādē, ražošanā un piegādē. 5., 6. norādījumi ir specifiski un izriet no AS raksturīgajām iezīmēm.
2.5. Atomelektrostaciju kopumā un to komponentu nodrošinājums ar normatīvo un tehnisko dokumentāciju pieņemto standartizācijas jomu un uzdevumu ietvaros ir atšķirīgs.
Tehniskā, programmatūras un informācijas atbalsta komponenti kā izstrādājumi rūpnieciskiem nolūkiem tiek uzskatīti attiecīgi par dizaina, programmatūras un informācijas produktiem. Uz šiem produktiem attiecas pašreizējie ESKD standartu komplekti. SRPP, ESPD, SGIP, USD, tehniskās un ekonomiskās informācijas klasifikatori un kodifikatori, standartu kompleksi tipa "OTT", "Pārbaudes metodes", "TU", kā arī pasūtītāja OTT.
2.5.1. Viss dizaina produktu dzīves cikls ir pilnībā nodrošināts ar normatīvo un tehnisko dokumentāciju, kas ir spēkā mašīnbūvē un instrumentu ražošanā.
2.5.2. Programmatūras produkti tiek nodrošināti ar NTD, kas ir iekļauts klienta ESPD un OTT. Tomēr šo NTD darbības joma ir jāpaplašina, lai atspoguļotu problēmas, kas saistītas ar programmatūras produktu izstrādi, izveidi, izplatīšanu un darbību.
2.5.3. Informācijas produkti šobrīd netiek nodrošināti ar NTD, lai gan DDD ietvaros ir izstrādāti atsevišķi jautājumi, tehniskās un ekonomiskās informācijas klasifikatori un kodifikatori.
2.6. Programmatūra un aparatūra un programmatūras un metodiskie kompleksi tiek uzskatīti par sarežģītiem produktiem, kuriem mašīnbūvē nav analogu. Ņemot vērā PTK un PMK statusu. kā rūpnieciskiem nolūkiem paredzētiem produktiem, to izstrādes noteikumiem un procedūrai jābūt līdzīgai prasībām, kas noteiktas produktu izstrādes un ieviešanas ražošanā (SRPP) sistēmas standartos.


informācijas tehnoloģijas. Standartu komplekts automatizētām sistēmām. Tehniskie virzieni automatizēto sistēmu izstrādei

Pamatojoties uz GOST 34.602-89 tehnisko specifikāciju rakstīšanai automatizētām vadības sistēmām no 01/01/1990

1. VISPĀRĪGI NOTEIKUMI

1.1. TK ir galvenais dokuments, kas nosaka informācijas sistēmas (turpmāk tekstā IS) izveides (izstrādes vai modernizācijas - turpmāk - izveide) prasības un kārtību, saskaņā ar kuru tiek veikta IS izstrāde un pieņemšana. pēc nodošanas ekspluatācijā.

1.2. TK ir izstrādāta sistēmai kopumā, paredzēta darbam neatkarīgi vai kā citas sistēmas sastāvdaļa.

1.3. Prasības attiecībā uz IP šajā standartā noteiktajā apjomā var iekļaut jaunizveidota informatizācijas objekta projektēšanas uzdevumā. Šajā gadījumā TK nav izstrādāta.

1.4. TOR ietvertajām prasībām jāatbilst pašreizējam informācijas tehnoloģiju attīstības līmenim un nedrīkst būt zemākas par līdzīgām prasībām labākajiem mūsdienu vietējiem un ārvalstu analogiem. TOR noteiktajām prasībām nevajadzētu ierobežot sistēmas izstrādātāju efektīvāko tehnisko, priekšizpētes un citu risinājumu meklēšanā un ieviešanā.

1.5. TOR ietver tikai tās prasības, kas papildina prasības šāda veida sistēmām un ir noteiktas pēc konkrētā objekta, kuram sistēma tiek veidota, specifika.

1.6. Izmaiņas TOR tiek formalizētas ar pielikumu vai protokolu, ko parakstījis klients un izstrādātājs. Papildinājums vai norādītais protokols ir IP neatņemama TOR sastāvdaļa. TK titullapā jābūt ierakstam "Derīgs no ...".

2. SASTĀVS UN SATURS

2.1. TOR satur šādas sadaļas, kuras var iedalīt apakšsadaļās:

  • 1) vispārīga informācija;

  • 2) sistēmas izveides (attīstīšanas) mērķis un mērķi;

  • 3) objektu raksturojums;

  • 4) sistēmas prasības;

  • 5) sistēmas izveides darba sastāvs un saturs;

  • 6) sistēmas kontroles un pieņemšanas kārtība;

  • 7) prasības darba sastāvam un saturam, lai sagatavotu izstrādes objektu sistēmas nodošanai ekspluatācijā;

  • 8) prasības dokumentācijai;

  • 9) attīstības avoti.
Pieteikumus var iekļaut darba uzdevumā.

2.2. Atkarībā no projekta veida, mērķa, specifikas un sistēmas darbības apstākļiem ir atļauts noformēt TPR sadaļas pieteikumu veidā, ieviest papildu, izslēgt vai apvienot TPR apakšsadaļas.

Sistēmas daļu TOR neietver sadaļas, kas dublē visu TOR sadaļu saturu.

2.3. Sadaļā "Vispārīga informācija" norādiet:


  • 1) sistēmas pilns nosaukums un tās simbols;

  • 2) tēmas šifrs vai līguma šifrs (numurs);

  • 3) sistēmas izstrādātāja un pasūtītāja (lietotāja) uzņēmumu nosaukumus un to rekvizītus;

  • 4) dokumentu saraksts, uz kuru pamata sistēma tiek veidota, kas un kad šos dokumentus apstiprinājis;

  • 5) plānotos datumus sistēmas izveides darbu uzsākšanai un pabeigšanai;

  • 6) informāciju par darbu finansēšanas avotiem un kārtību;

  • 7) kārtība, kādā noformējami un pasūtītājam tiek iesniegti sistēmas (tās daļu) izveides, atsevišķu līdzekļu (aparatūras, programmatūras, informācijas) un programmatūras un aparatūras (programmatūras un metodiskās) izgatavošanas un pielāgošanas darba rezultāti; sistēmas kompleksi.
2.4. Sadaļa "Sistēmas izveides (attīstīšanas) mērķis un uzdevumi" sastāv no apakšsadaļām:

  • 1) sistēmas mērķis;

  • 2) sistēmas izveides mērķis.
2.4.1. Apakšsadaļā "Sistēmas mērķis" norāda sistēmas darbības veidu (pārvaldība, projektēšana u.c.) un informatizācijas objektu (objektu) sarakstu, kuros to paredzēts izmantot.

2.4.2. Apakšsadaļā “Sistēmas izveides mērķi” ir norādīti informatizācijas objekta tehnisko, tehnoloģisko, ražošanas-ekonomisko vai citu rādītāju nosaukumi un nepieciešamās vērtības, kas jāsasniedz IS izveides rezultātā. , un norāda sistēmas izveides mērķu sasniegšanas vērtēšanas kritērijus.

2.5. Sadaļā "Informatizācijas objekta raksturojums" tie sniedz:


  • 1) īsa informācija par informatizācijas objektu vai saites uz dokumentiem, kas satur šādu informāciju;

  • 2) informācija par automatizācijas objekta darbības apstākļiem.
2.6. Sadaļa Sistēmas prasības sastāv no šādām apakšsadaļām:

  • 1) prasības sistēmai kopumā;

  • 2) prasības sistēmas veicamajām funkcijām (uzdevumiem);

  • 3) prasības nodrošinājuma veidiem.
Šajā IS TOR sadaļā ietverto sistēmas prasību sastāvs tiek noteikts atkarībā no konkrētas sistēmas veida, mērķa, īpašajām iezīmēm un darbības apstākļiem.

2.6.1. Apakšsadaļā "Prasības sistēmai kopumā" norādiet:


  • prasības sistēmas struktūrai un darbībai;

  • prasības sistēmas personāla skaitam un kvalifikācijai un tās darba režīmam;

  • galamērķa rādītāji;

  • uzticamības prasības;

  • drošības prasības;

  • ergonomikas un tehniskās estētikas prasības;

  • prasības sistēmas komponentu darbībai, apkopei, remontam un uzglabāšanai;

  • prasības informācijas aizsardzībai pret nesankcionētu piekļuvi;

  • prasības informācijas drošībai negadījumu gadījumā;

  • prasības aizsardzībai no ārējās ietekmes ietekmes;

  • prasības attiecībā uz patenta tīrību;

  • standartizācijas un unifikācijas prasības;

  • Papildu prasības.
2.6.1.1. Sistēmas struktūras un darbības prasības ietver:

  • 1) apakšsistēmu saraksts, to mērķis un galvenie raksturlielumi, prasības hierarhijas līmeņu skaitam un sistēmas centralizācijas pakāpei;

  • 2) prasības saziņas metodēm un līdzekļiem informācijas apmaiņai starp sistēmas komponentiem;

  • 3) prasības veidojamās sistēmas starpsavienojumu ar radniecīgām sistēmām raksturlielumiem, prasības tās savietojamībai, tai skaitā norādījumi, kā apmainīties ar informāciju (automātiski, nosūtot dokumentus, pa telefonu u.c.);

  • 4) prasības sistēmas darbības režīmiem;

  • 5) prasības sistēmas diagnostikai;

  • 6) sistēmas attīstības, modernizācijas perspektīvas.
2.6.1.2. Prasībās par IS personāla skaitu un kvalifikāciju ir norādīts:

  • prasības IS personāla (lietotāju) skaitam;

  • prasības personāla kvalifikācijai, apmācības un zināšanu un prasmju kontroles kārtība;

  • nepieciešamo IS personāla darba režīmu.
2.6.1.3. Prasībās IS mērķa indikatoriem ir norādītas to parametru vērtības, kas raksturo sistēmas atbilstības pakāpi tās mērķim.

2.6.1.4. Uzticamības prasības ietver:


  • 1) uzticamības rādītāju sastāvs un kvantitatīvās vērtības visai sistēmai vai tās apakšsistēmām;

  • 2) avārijas situāciju saraksts, kurām būtu jāreglamentē uzticamības prasības, un atbilstošo rādītāju vērtības;

  • 3) prasības aparatūras un programmatūras uzticamībai;

  • 4) prasības ticamības rādītāju novērtēšanas un uzraudzības metodēm dažādos sistēmas izveides posmos saskaņā ar spēkā esošajiem normatīvajiem un tehniskajiem dokumentiem.
2.6.1.5. Drošības prasības ietver prasības drošības nodrošināšanai sistēmas piegādes, nodošanas ekspluatācijā, ekspluatācijas un apkopes laikā.

2.6.1.6. Ergonomikas un tehniskās estētikas prasībās ir iekļauti IS rādītāji, kas norāda nepieciešamo cilvēka un mašīnas mijiedarbības kvalitāti un personāla darba apstākļu komfortu.

2.6.1.7. Prasības informācijas aizsardzībai pret nesankcionētu piekļuvi ietver nozares un klienta informācijas vides noteiktās prasības.

2.6.1.8. Informācijas drošības prasībās ir ietverts notikumu saraksts: avārijas, tehnisko līdzekļu atteices (t.sk. jaudas zudums) u.c., kurās jānodrošina informācijas drošība sistēmā.

2.6.1.9. Patenta tīrības prasības norāda valstu sarakstu, attiecībā uz kurām jānodrošina sistēmas un tās daļu patentētā tīrība.

2.6.1.10. Papildu prasības ietver īpašas prasības pēc sistēmas izstrādātāja vai klienta ieskatiem.

2.6.2. Apakšsadaļā "Prasības sistēmas veiktajām funkcijām (uzdevumiem)" ir norādīts:


  • katrai apakšsistēmai automatizējamo funkciju, uzdevumu vai to kompleksu (arī to, kas nodrošina sistēmas daļu mijiedarbību) saraksts;

  • veidojot sistēmu divās vai vairākās rindās - funkcionālo apakšsistēmu, atsevišķu funkciju vai uzdevumu saraksts, kas tiek ieviesti 1. un turpmākajās rindās;

  • katras funkcijas, uzdevuma (vai uzdevumu kopas) īstenošanas laika grafiks;

  • prasības katras funkcijas (uzdevuma vai uzdevumu kopas) izpildes kvalitātei, izvadinformācijas pasniegšanas formai, nepieciešamās precizitātes un izpildes laika raksturlielumiem, prasības funkciju grupas izpildes vienlaicīgumam, uzticamībai. no rezultātiem;

  • saraksts un atteices kritēriji katrai funkcijai, kurai noteiktas uzticamības prasības.
2.6.3. Apakšsadaļā “Prasības atbalsta veidiem” atkarībā no sistēmas veida ir dotas prasības matemātiskā, informatīvā, lingvistiskā, programmatūras, tehniskā, metroloģiskā, organizatoriskā, metodiskā un cita veida sistēmas atbalstam.

2.6.3.2. Sistēmas informatīvajam atbalstam tiek izvirzītas šādas prasības:


  • 1) uz datu sastāvu, struktūru un kārtošanas metodēm sistēmā;

  • 2) informācijas apmaiņai starp sistēmas komponentiem;

  • 3) informācijas savietojamībai ar blakus esošajām sistēmām;

  • 4) par datu bāzu pārvaldības sistēmu izmantošanu;

  • 5) datu vākšanas, apstrādes, nodošanas sistēmā un datu prezentēšanas procesa struktūrai;

  • 6) datu aizsardzībai;

  • 7) datu kontrole, uzglabāšana, atjaunināšana un atjaunošana;
2.6.3.3. Sistēmas lingvistiskajam atbalstam tiek izvirzītas prasības augsta līmeņa programmēšanas valodu lietošanai sistēmā, lietotāja mijiedarbības valodām un sistēmas tehniskajiem līdzekļiem, kā arī prasības datu kodēšanai un dekodēšanai, datu ievadei. -izvades valodas, datu apstrādes valodas, priekšmeta jomas aprakstīšanas līdzekļi un metodes dialoga organizēšanai.

2.6.3.4. Sistēmas programmatūrai ir norādīts iegādātās programmatūras saraksts, kā arī prasības:


  • 1) programmatūras atkarībai no darbības vides;

  • 2) programmatūras kvalitātei, kā arī tās nodrošināšanas un kontroles metodēm;
2.6.3.5. Sistēmas tehniskajam atbalstam tiek izvirzītas šādas prasības:

  • 1) tehnisko līdzekļu veidiem, tai skaitā tehnisko līdzekļu kompleksu veidiem, programmatūras un aparatūras kompleksiem un citām sastāvdaļām, kas ir pieņemami lietošanai sistēmā;

  • 2) uz sistēmas tehniskā nodrošinājuma funkcionālajām, konstruktīvajām un darbības īpašībām.
2.6.3.6. Metroloģiskā atbalsta prasības ietver:

  • 1) provizorisks mērīšanas kanālu saraksts;

  • 2) prasības parametru mērījumu precizitātei un (vai) mērīšanas kanālu metroloģiskajiem raksturlielumiem;

  • 3) sistēmas tehnisko līdzekļu metroloģiskās savietojamības prasības;

  • 4) sistēmas vadības un skaitļošanas kanālu sarakstu, kuriem nepieciešams novērtēt precizitātes raksturlielumus;

  • 5) prasības aparatūras un programmatūras, kas ir daļa no sistēmas mērīšanas kanāliem, metroloģiskā atbalsta, instrumentu, iebūvētās vadības, mērīšanas kanālu un sistēmas regulēšanā un testēšanā izmantoto mērinstrumentu metroloģiskā piemērotība;

  • 6) metroloģiskās sertifikācijas veids (valsts vai departaments), norādot tās īstenošanas kārtību un sertifikāciju veicošās organizācijas.
2.6.3.7. Organizatoriskajam atbalstam tiek izvirzītas šādas prasības:

 1) sistēmas darbībā iesaistīto vai darbību nodrošinājošo struktūrvienību struktūrai un funkcijām;

 2) sistēmas darbības organizācijai un IS personāla un informatizācijas objekta personāla mijiedarbības kārtībai;

 3) aizsardzība pret sistēmas personāla kļūdainu rīcību.

2.7. Sadaļā "Sistēmas izveides (izstrādes) darba sastāvs un saturs" jāiekļauj sistēmas izveides posmu un darba posmu saraksts, to ieviešanas laiks, darbu veicošo organizāciju saraksts, saites uz dokumentiem, kas apliecina šo organizāciju piekrišanu piedalīties sistēmas izveidē, vai ierakstu, kurā noteikta atbildīgā persona (pasūtītājs vai izstrādātājs) par šo darbu veikšanu.

Šajā sadaļā ir sniegta arī:


  • 1) attiecīgo darba posmu un posmu beigās uzrādāmo dokumentu saraksts;

  • 2) tehniskās dokumentācijas pārbaudes veids un kārtība (pārbaudāmās dokumentācijas posms, posms, apjoms, organizācija-eksperts);

  • 3) darba programma, kuras mērķis ir nodrošināt izstrādājamās sistēmas nepieciešamo uzticamības līmeni (ja nepieciešams);

  • 4) metroloģiskā atbalsta darbu saraksts visos sistēmas izveides posmos, norādot to izpildes termiņus un izpildorganizācijas (ja nepieciešams).
2.8. Sadaļā "Sistēmas uzraudzības un pieņemšanas kārtība" norāda:

  • 1) sistēmas un tās sastāvdaļu veidi, sastāvs, apjoms un pārbaudes metodes;

  • 2) vispārīgās prasības darbu pieņemšanai pa posmiem, pieņemšanas dokumentācijas saskaņošanas un apstiprināšanas kārtība;
2.9. Sadaļā “Prasības automatizācijas objekta sagatavošanai sistēmas nodošanai ekspluatācijā paredzēto darbu apjomam un saturam” nepieciešams nodrošināt galveno darbību un to veicēju sarakstu, kas jāveic, sagatavojot projektu par nodošanu ekspluatācijā. IR ekspluatācijā.

Galveno darbību saraksts ietver:


  • 1) sistēmā ienākošās informācijas ienešana (saskaņā ar informācijas un lingvistiskā atbalsta prasībām);

  • 2) tādu apstākļu radīšana projekta funkcionēšanai, pie kuriem tiek garantēta izveidotās sistēmas atbilstība TPR ietvertajām prasībām;

  • 3) sistēmas funkcionēšanai nepieciešamo apakšnodaļu un dienestu izveide;

  • 4) personāla komplektēšanas un personāla apmācības termiņi un kārtība.
2.10. Sadaļā "Dokumentācijas prasības" ir norādīts:

  • 1) izstrādājamo dokumentu komplektu un veidu sarakstu, vienojoties ar sistēmas izstrādātāju un Pasūtītāju;
    uz mašīnu datu nesējiem izsniegto dokumentu saraksts;

  • 2) ja nav valsts standartu, kas nosaka prasības sistēmas elementu dokumentēšanai, tie papildus ietver prasības šādu dokumentu sastāvam un saturam.
2.11. Sadaļā "Izstrādes avoti" jāuzskaita dokumenti un informatīvie materiāli, uz kuru pamata tika izstrādāts TO un kuri jāizmanto, veidojot sistēmu.

3. KONSTRUKCIJAS NOTEIKUMI

3.1. TOR sadaļas un apakšsadaļas jāievieto secībā, kas noteikta 2. punktā. 2 no šī standarta.

3.2. Lapu (lapu) numurus noliek, sākot no pirmās lapas aiz titullapas, lapas augšējā daļā (virs teksta, vidū) pēc TK koda apzīmējuma uz IC.

3.3. Titullapā ir ievietoti pasūtītāja, izstrādātāja un koordinējošo uzņēmumu paraksti, kas ir aizzīmogoti. Ja nepieciešams, titullapu noformē uz vairākām lapām. Pēdējā lapā ievietoti TK izstrādātāju un TK par IP projekta apstiprināšanā un izskatīšanā iesaistīto amatpersonu paraksti.

TOR titullapas forma dota 2.pielikumā TOR pēdējās lapas forma dota 3.pielikumā.

3.4. TOR papildinājuma titullapa tiek noformēta tāpat kā darba uzdevuma titullapa. Nosaukuma "Noteikumi" vietā viņi raksta "AC TOR ... papildinājums Nr. ...".

3.5. Nākamajās TOR papildinājuma lapās tiek ievietots izmaiņu iemesls, izmaiņu saturs un saites uz dokumentiem, saskaņā ar kuriem šīs izmaiņas tiek veiktas.

3.8. Iesniedzot TOR papildinājuma tekstu, jānorāda galveno TP attiecīgo punktu, apakšpunktu, tabulu u.c. numuri un vārdi “aizstāt”, “papildināt”, “dzēst”, “norādīt jauns izdevums”.

TK FOR IP IZSTRĀDES, LĪGŠANAS UN APSTIPRINĀŠANAS KĀRTĪBA

1. TOR projektu izstrādā sistēmas organizācija-izstrādātājs, piedaloties pasūtītājam, pamatojoties uz tehniskajām prasībām (pielietojums, taktiskais un tehniskais uzdevums utt.).

Konkursa darba organizēšanā TOR projekta variantus izskata pasūtītājs, kurš vai nu izvēlas sev vēlamo variantu, vai arī, pamatojoties uz salīdzinošo analīzi, sagatavo AC galīgo variantu, piedaloties topošais IS izstrādātājs.

2. Nepieciešamību saskaņot RĪ projektu ar valsts uzraudzības iestādēm un citām ieinteresētajām organizācijām nosaka sistēmas pasūtītājs un IS projekta izstrādātājs kopīgi,

Darbu pie TK projekta apstiprināšanas IK kopīgi veic TOR izstrādātājs un sistēmas pasūtītājs, katrs savas ministrijas (departamenta) organizācijās.

3. TOR projekta apstiprināšanas termiņš katrā organizācijā nedrīkst pārsniegt 15 dienas no tā saņemšanas dienas. ToR projekta kopijas (kopijas) ieteicams nosūtīt apstiprināšanai vienlaikus visām organizācijām (nodaļām).

4. Komentāri par TOR projektu iesniedzami ar tehnisku pamatojumu. Lēmumi par komentāriem ir jāpieņem ToR projekta izstrādātājam un sistēmas pasūtītājam, pirms tiek apstiprināts IS uzdevums.

5. Ja, saskaņojot TOR projektu, radušās domstarpības starp izstrādātāju un pasūtītāju (vai citām ieinteresētajām organizācijām), tad tiek sastādīts domstarpību protokols (patvaļīga forma) un pieņemts konkrēts lēmums noteiktajā kārtībā.

6. TOR projekta apstiprinājumu atļauts noformēt kā atsevišķu dokumentu (vēstule). Šajā gadījumā zem virsraksta "Saskaņots" izveidojiet saiti uz šo dokumentu.

7. TOR apstiprināšanu veic sistēmas izstrādātāja un pasūtītāja uzņēmumu vadītāji.

8. Apstiprinātās rokasgrāmatas kopijas 10 dienu laikā pēc apstiprināšanas Nolikuma izstrādātājs nosūta sistēmas izveides dalībniekiem.

9. TPR papildinājumu saskaņošana un apstiprināšana notiek tādā veidā, kā tas noteikts TPR uz IP.

10. Izmaiņas TOR nav atļauts apstiprināt pēc sistēmas vai tās rindas iesniegšanas akcepttestiem.

NOSAUKUMLAPAS FORMA TK


______________________________________________________ .

organizācijas nosaukums - TK izstrādātājs IP


APSTIPRINĀT

Vadītājs (amats, uzņēmuma nosaukums - IP klients)

Ronis


datums
APSTIPRINĀT

Vadītājs (amats, uzņēmuma nosaukums - "IS" izstrādātājs)

Personīgais paraksts Paraksta atšifrējums

Ronis


datums

IP veida nosaukums

________________________________________________________

informatizācijas objekta nosaukums

________________________________________________________

IS saīsinātais nosaukums
TEHNISKAIS UZDEVUMS

Uz ____ loksnēm


Derīgs no

PIEKRĪTU


vadītājs (amats, koordinējošās organizācijas nosaukums)

Personīgais paraksts Paraksta atšifrējums