Darba uzdevumi automatizācijai. Kas ir tehniskais uzdevums? Noteikumi vienota automatizēto sistēmu standartu kopuma izveidei

129 kb.09.12.2011 03:33

1.dok

^ Ievada datumsno 01.01.1990

Šis standarts attiecas uz automatizētām sistēmām (AS), lai automatizētu dažāda veida darbības (vadību, projektēšanu, pētniecību utt.), tostarp to kombinācijas, un nosaka dokumenta "Uzdevumu izveide attīstības vai modernizācijas) sistēmas” (turpmāk – AES TK).

Ieteicamā procedūra kodolspēkstaciju tehnisko specifikāciju izstrādei, apstiprināšanai un apstiprināšanai ir dota 1. pielikumā.
^

1. VISPĀRĪGI NOTEIKUMI

1.1. Atomelektrostaciju uzdevumi ir galvenais dokuments, kas nosaka izveides (attīstīšanas vai modernizācijas – turpmāk – izveide) prasības un kārtību. automatizēta sistēma, saskaņā ar kuru tiek veikta ĀS 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.

Turklāt TOR var izstrādāt AES daļām:

• 
  par 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 sistēmām atbilstoši ESKD un SRPP standartiem;
• 
  programmatūrai atbilstoši ESPD standartiem;
• 
  informācijas produktiem saskaņā ar GOST 19.201 un NTD, kas darbojas ĀS 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 sistēmas darbības apstākļiem, 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. Nodaļā " Galvenā informācija» norādīt:

• 
  1) sistēmas pilns nosaukums un tās nosaukums 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 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 metodiskās) izgatavošanas un pielāgošanas. 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 ir 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 AES veida, mērķa, īpašām iezīmēm un ekspluatācijas apstākļiem. specifiska sistēma. 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.

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, tajā 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ības attiecībā uz AES personāla skaitu un kvalifikāciju ietver:

• 
  prasības AES personāla (lietotāju) skaitam;
• 
  prasības personāla kvalifikācijai, apmācības un zināšanu un prasmju kontroles kārtība;
• 
  nepieciešamais AES personāla darba 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:

• 
  sistēmas pielāgojamības pakāpi procesu un vadības metožu izmaiņām, novirzēm vadības objekta parametros;
• 
  pieļaujamās sistēmas modernizācijas un attīstības robežas;
• 
  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:

• 
  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) uzticamības prasības tehniskajiem līdzekļiem un programmatūra;
• 
  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 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:

• 
  1) 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 veidi un biežums vai darbības pieļaujamība bez apkopes ;
• 
  2) sākotnējās prasības attiecībā uz pieļaujamajām platībām sistēmas personāla un TS izvietošanai, elektroapgādes tīklu parametriem utt.;
• 
  3) prasības apkopes personāla skaitam, kvalifikācijai un viņu darba veidiem;
• 
  4) prasības rezerves produktu un ierīču komplekta sastāvam, izvietojumam un uzglabāšanas nosacījumiem;
• 
  5) prasības apkopes grafikam.

2.6.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 dots notikumu uzskaitījums: 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:

• 
  1) prasības AES objektu radioelektroniskajai aizsardzībai;
• 
  2) prasības noturībai, stabilitātei un stiprībai 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:

• 
  1) 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;
• 
  2) prasības servisa iekārtām, stendiem sistēmas elementu pārbaudei;
• 
  3) sistēmas prasības, kas saistītas ar īpaši nosacījumi darbība;
• 
  4) īpašas prasības pēc sistēmas izstrādātāja vai pasūtītāja ieskatiem.

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

 1) 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;

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

 3) prasības katras funkcijas (uzdevuma vai uzdevumu kopas) izpildes kvalitātei, izvadinformācijas pasniegšanas formai, nepieciešamās precizitātes un izpildes laika raksturojumiem, prasības funkciju grupas vienlaicīgai izpildei. , rezultātu ticamība;

 4) 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.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. 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 vissavienības un reģistrēto republikas, nozaru klasifikatoru, vienoto dokumentu un attiecīgajā uzņēmumā darbojošos klasifikatoru izmantošanu;
• 
  5) par datu bāzu pārvaldības sistēmu izmantošanu;
• 
  6) uz datu vākšanas, apstrādes, pārsūtīšanas sistēmā un datu prezentēšanas procesa struktūru;
• 
  7) aizsargāt datus no iznīcināšanas avāriju un sistēmas elektroenerģijas padeves pārtraukumu gadījumā;
• 
  8) datu kontrole, uzglabāšana, atjaunināšana un atjaunošana;
• 
  9) kārtību, kādā piešķir juridisku spēku dokumentiem, kas izgatavoti ar ĀS tehniskajiem līdzekļiem (saskaņā ar GOST 6.10.4 ).

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, priekšmeta aprakstīšanas līdzekļi (automatizācijas objekts), sistēmas organizēšanas metodes. dialogs.

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 neatkarībai no izmantotās CVT un darbības vides;
• 
  2) programmatūras kvalitātei, kā arī tās nodrošināšanas un kontroles metodēm;
• 
  3) 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:

• 
  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 mijiedarbības kārtībai starp AES personālu un automatizācijas objekta personālu;

 3) 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. veicot 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.

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

• 
  1) dokumentu saraksts, saskaņā ar GOST 34.201-89 uzrāda attiecīgo darba posmu un posmu beigās;
• 
  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 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 uz darbu pieņemšanu 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ību;
• 
  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 sniegt sarakstu ar galvenajām darbībām un to veicējiem, kas jāveic, sagatavojot automatizācijas objektu nodošanai. AU sāk darboties.

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 prasībām, par kurām vienojas sistēmas izstrādātājs un pasūtītājs GOST 34.201-89 un klienta nozares NTD;
  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, ārvalstu 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:

• 
  1) sistēmas paredzamās efektivitātes aprēķins;
• 
  2) sistēmas zinātniski 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 tas ir saskaņots 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.

ĀS TK titullapas forma ir dota 2.pielikumā.ĀS TK pēdējās lapas forma ir dota 3.pielikumā.

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 ĀS TOR papildinājuma lapā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 vārdi “aizstāt”, “papildināt”, “dzēst”, “. stāvoklis jaunā izdevumā” jāizmanto.

1. PIELIKUMS
Ieteicams
^

AES TOR IZSTRĀDES, LĪGUMA UN APSTIPRINĀŠANAS KĀRTĪBA

1. AES 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ā AES TPR 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 AES TPR galīgo variantu ar topošā AES attīstītāja līdzdalība.

2. Nepieciešamību saskaņot AES RT projektu 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 vai tās kārta ir nodota 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 - AES tehnisko specifikāciju izstrādātājs APSTIPRINĀT Vadītājs (amats, uzņēmuma nosaukums - AES klients) datums APSTIPRINĀT Vadītājs (amats, uzņēmuma nosaukums - izstrādātājs "AS") Personīgais paraksts Paraksta atšifrējums Maiņstrāvas tipa nosaukums ________________________________________________________ Automatizācijas objekta nosaukums ________________________________________________________ Saīsinātais nosaukums 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

MADE

PIEKRĪTU

4. PIELIKUMS
Atsauce
^

NOTEIKUMI AUTOMATIZĒTO SISTĒMU VIENOTA STANDARTU KOMPLEKSA IZVEIDOŠANAI

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, metodiskā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) vienota automatizēto vadības sistēmu standartu sistēma (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 saimnieciskā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 nav saskaņotas savā starpā. pastāv atšķirības darba sastāvā un saturā, atšķiras dokumentu apzīmējums, sastāvs, saturs un noformējums 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. Vienam standartu un vadlīniju kopumam ir 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) tehniskais uzdevums ir galvenais dokuments, saskaņā ar kuru AS tiek izveidots un pasūtītājs akceptēts;
• 
  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 sastāvdaļas, kā arī PMK un PTK ir jāražo un jāpiegādā kā izstrādājumi rūpnieciskiem 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ā tehniskās, programmatūras vai informatīvās programmatūras 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.
^

2. 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 daļa no darba pie vispārinātās problēmas. Informāciju tehnoloģijas».

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 esošie standartu komplekti ESKD, SRPP, ESPD, SGIP, USD, tehniskās un ekonomiskās informācijas klasifikatori un kodifikatori, standartu kopas tipa "OTT", "Testēšanas metodes", "TU", kā arī kā klienta 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, kā arī programmatūras un metodiskie kompleksi tiek uzskatīti par sarežģītiem produktiem, kuriem mašīnbūvē nav analogu. Ņemot vērā PTK un PMK kā rūpnieciskiem nolūkiem paredzētu produktu statusu, to izstrādes noteikumiem un kārtībai jābūt līdzīgiem prasībām, kas noteiktas produktu izstrādes un ražošanas sistēmas (SRPP) standartos.

Rūpīgi apdomājot, nolēmu, ka atkal nedarbosies visu plānotās otrās daļas materiālu satilpināt vienā rakstā, citādi būs topi un teorētiski, kas jau rakstīts daudzās mācību grāmatās. Bet galu galā es uzstādīju uzdevumu tā, lai to varētu pielietot praksē, tāpēc nākotnē vairs nedomāšu par to, cik daudz jautājumu būs nepieciešams, lai pabeigtu tēmu. To ietekmēs arī lasītāju atsauksmes, tāpēc rakstiet, nekautrējieties!

Izmantojot iespēju, vēlos uzdot jautājumu: cik interesanti būtu organizēt praktisko apmācību semināru Sanktpēterburgā par darba uzdevuma izstrādi? Mēs satiktos un apmainītos pieredzē. Ja šāda interese nebūs izolēta, apsolu organizēt.

Tā kā lasītāji ir ne tikai programmatūras izstrādātāji, bet arī biznesa analītiķi un vadītāji dažādi līmeņi Centīšos rakstīt tā, lai visiem būtu interesanti.

Šajā daļā mēs runāsim par to, kā organizēt darba posmu pie prasību apkopošanas, no kā tam vajadzētu sastāvēt un kādus rīkus var izmantot. Atkārtoju, ka šie darbi posmos ir ļoti līdzīgi uzņēmumu aptaujai, lai aprakstītu biznesa procesus.

Kā parasti dzīvē:

Kā tas darbojas lielākajā daļā projektu
Soļi	Kā tas notiek
	Skaidrs, ka priekam ir pamats, īpaši, ja projekts ir liels, tur nav nekā slikta! Galvenais pārāk ilgi nepriecāties, kavējot reālo darbu sākšanu, turpmāk laikam ritēs savādāk.
	Parasti šis process aprobežojas ar vairākām tikšanās reizēm ar vadību, pēc tam ar nodaļu vadītājiem. Nofiksējot dažus Klienta “mudinājumus”, tie tiek fiksēti vispārīgu formulējumu veidā. Dažkārt tai tiek pievienota pieejamā dokumentācija (kāds reiz mēģinājis veikt ekspertīzi, dokumenti atbilstoši esošajiem normatīvajiem aktiem, izmantotās atskaišu formas) Pārsteidzoši, ka pēc tam lielākā daļa automatizācijas sistēmu ieviesēju priecīgi iesaucas: “jā, mūsu sistēmā ir tas viss! Nu, nedaudz pielabot un viss izdosies. Uz jautājumu, vai ar galalietotājiem ir nepieciešams pārrunāt, kā lietām būtu jāstrādā (vai kā konkrēts process tiek veikts), atbilde parasti ir nē. Tiek izteikts viedoklis, ka vadītājs saviem padotajiem visu zina. Bet velti... Aiz tā slēpjas daudz slazdu un šķēršļu, un darbu piegāde var pārvērsties par maratonu pa šķēršļu joslu. Kā zināms, ir pieņemts skriet maratonu pa līdzenu ceļu, un skriet ar šķēršļiem iespējams tikai nelielās distancēs (var arī neskriet).
Darba rezultātu dokumentēšana	Pēc tam sākas rezultātu dokumentēšana atkarībā no darba mērķiem: Ja jums ir jāizstrādā darba uzdevumi , konsultants sāk bāzt saņemto informāciju pēc sagatavotā dokumenta veidnes, lai tā izskatās skaisti un tiek fiksētas galvenās prasības (tās, kas izskan no vadības, pretējā gadījumā tās var neapstiprināt). Saprotot, ka praksē šāds Nolikums netiek īpaši izmantots un viss ir jānoskaidro "kā iet", viņš izvirza nolikuma galveno mērķi. minimālais laiks saskaņošanai un apstiprināšanai. Un, ja iespējams, informācija par aptuvenu nākotnes darbu izmaksu aprēķinu (starp citu, tas ir arī svarīgi). Ja vēlaties aprakstīt biznesa procesus. Savādi, bet bieži vien visas iepriekšējās darbības izskatās tāpat kā darba uzdevuma izstrādes gadījumā. Vienīgā atšķirība ir dokumentācijā. Šeit ir iespējamas iespējas: konsultanti apraksta procesu ar patvaļīgiem vārdiem vai izmanto jebkādus biznesa procesu aprakstīšanas noteikumus (apzīmējumus). Pirmajā gadījumā šāds dokuments izrādās pārsteidzoši līdzīgs Darba uzdevumam. Gadās pat tā, ka, nomainot titullapu, jūs neredzēsiet nekādu atšķirību. formāla apraksta noteikumu ievērošana.Diemžēl abi varianti nav tie visvairāk labākā prakse, jo ir vairāk formalitāte un nedod lielu labumu.

Kāpēc pastāv šāda iepriekš aprakstītā prakse? Atzīšos, ka nezinu. Neviens nejautā, neviens nezina. Tajā pašā laikā situācija nemainās ļoti strauji, lai gan par šo tēmu nemitīgi tiek runāts, notiek pieredzes apmaiņa, rakstītas grāmatas... Man šķiet, ka viens no iemesliem ir attiecīgās izglītības zemā kvalitāte. To var ietekmēt arī tas, ka daudzi speciālisti vispār nāk no citiem uzņēmumiem un visu saprot praksē, t.i. viņu pieredzi veido vide, kurā viņi atrodas. Arī augstskolu attieksme un nevēlēšanās būt tuvāk realitātei ir vispārzināms fakts, taču dažkārt viņu nostāja mani pārsteidz. Piemēram, man bija gadījums, kad maģistrants, talantīgs speciālists gribēja uzrakstīt diplomdarbu uz platformas 1C (laba nozares attīstība), bet katedrā viņai teica, ka neatkarīgi no tēmas tas nebūs iespējams. rēķināties ar atzīmi “teicami”, jo 1C nav nopietna sistēma. Šeit runa nav par šāda viedokļa nopietnību un objektivitāti, bet gan par to, ka primitīvs uzdevums klasiskajā programmēšanas valodā uzreiz tika uzskatīts par “izcila” vērtējuma cienīgu.

Mēģināsim piešķirt iepriekš apspriestajam procesam sistemātiskāku pieeju. Kā tad viņš varētu izskatīties?

Kā redzat, process beidzas ar jautājumu, jo pie tā darbs ne tuvu nav beidzies, un tad sāksies grūtākais un praktiskākais - tieši tas, kas noteiks iegūtā rezultāta pielietojamību. īsta dzīve. Tieši tas noteiks iepriekšējā darba likteni: vai nu tas nonāks skapī (plauktā vai kur citur), vai arī būs vērtīgs informācijas avots. Un vēl labāk, ja tas kļūst par paraugu turpmākajiem projektiem.

Gribu uzsvērt, ka līdz pēdējam solim diagrammā (kur ir jautājums) vispārējais informācijas vākšanas princips par uzņēmuma darbību izskatās vienāds, neatkarīgi no tā, ko plānots darīt nākotnē, aprakstīt biznesa procesus vai ieviest automatizēta sistēma. Jā, pati darbību secība ir tāda pati, taču dažos no tiem izmantotie rīki var atšķirties. Mēs noteikti apsvērsim šo brīdi, kad pētīsim atsevišķu posmu metodes un rīkus. Mēs to detalizēti darīsim atsevišķos rakstos, bet tagad mēs apsvērsim tikai vissvarīgāko. Turpmākie soļi atšķirsies un tos noteiks tas, kas ir nepieciešams no projekta: aprakstiet biznesa procesus vai ieviesiet grāmatvedības sistēmu.

Apskatīsim, kā jūs varat pārkārtot pieeju informācijas vākšanai par uzņēmuma darbību.

Kā tas var notikt ar kompetentāku darba organizāciju
Soļi	Kā tas notiek
Lēmums pieņemts, projekts būs!	Te nekas nemainās attiecībā uz pirmo variantu, emocijas neviens nav atcēlis
Mēs tikāmies ar vadītājiem, apkopojām informāciju par viņu redzējumu par rezultātu.	Šis solis arī paliek, un tam ir liela nozīme. Taču pirmās tikšanās (vai vairākas tikšanās) ar vadītājiem un īpašniekiem galvenais mērķis ir iepazīšanās. Iepazīšanās pirmām kārtām ar cilvēkiem un uzņēmumu. Šādās kopsapulcēs formulētie mērķi un vēlmes var būt ļoti dažādi, arī fantastiski. Tie visi, protams, tiks uzklausīti, bet ne tas, ka tie tiks īstenoti. Ar dziļāku iedziļināšanos uzņēmuma biznesā parādīsies citi mērķi, kā arī tiks noraidīti iepriekšējie. Ar to es domāju, ka no priekšsapulcēm nav iespējams noformulēt skaidrus mērķus, tas viss būs rūpīgi jāizpēta, šādās sanāksmēs ir nepieciešams ieskicēt visus īpašnieku un augstāko amatpersonu vēstījumus, lai vēlāk varētu atgriezties pie tiem. un apspriest, kad ir savākts pietiekami daudz informācijas. Pat šķietami vienkārša prasība var izrādīties nerealizējama vai ļoti darbietilpīga.
Darba grupas veidošana no Pasūtītāja un Izpildītāja, lomu sadale	Ir jāizlemj, kurš strādās pie projekta gan no Pasūtītāja, gan Izpildītāja puses. Neskatoties uz šī posma šķietamo vienkāršību, tam ir ļoti svarīga loma. Ja nepārprotami nenorādīsit, kurš par ko ir atbildīgs, jūs riskējat radīt neskaidrības darba izpildes laikā. Ja no savas puses vienmēr varat norādīt lomas savā komandā, tad Klientam ar to var rasties problēmas. Kam jāpievērš uzmanība: Pasūtītāja darba grupā obligāti jābūt tiem cilvēkiem, kuri nākotnē vismaz kaut kādā veidā ietekmēs rezultāta pieņemšanu. Ja pieņemam situāciju, ka, nododot darbu, pievienosies Pasūtītāja darbinieki, kuri nav piedalījušies mērķu veidošanas un prasību noteikšanas darbā, tad problēmas ir garantētas. Iespējama pat tik absurda situācija, ka viss, izrādās, nav izdarīts tā, kā prasīts.Savā praksē ar šādu situāciju esmu saskāries ne reizi vien.Tāpēc sevi var pasargāt, ja atrunā un dokumentē, ka neviens, izņemot Pasūtītāja darba grupu, nevar piedalīties darbu pieņemšanā un nodošanā. Un pats labākais, to noteikt līguma nosacījumos (līgumā vai projekta hartā). Atceros, bija tāds gadījums: vienā lielā projektā dibinātājs nolēma pievienoties procesam (nezinu kāpēc, kļuva garlaicīgi skatīties) un apmeklēja vienu no darba sanāksmēm, kur tika izskatīts jautājums par rēķinu ģenerēšanu klientiem. apspriests. Viņš bija pārsteigts, uzzinot, ka pārdošanas vadītājs izsniedz klientam rēķinu. Viņaprāt, grāmatvedim ir jāizraksta rēķins, un nekas cits. Bet patiesībā grāmatvedei vispār nebija ne jausmas, kas ir uz spēles, un vadītājs nevarēja iedomāties, kā tā var strādāt, ja par katru kontu skrien pie grāmatveža. Rezultātā mēs zaudējām daudz laika, taču nekas nemainījās, rēķinu joprojām izrakstīja pārvaldnieks. Un dibinātājs palika pie sava viedokļa, bet procesā vairs neiejaucās. Šajā posmā ir vēlams attīstīties Projekta harta, kurā nosaka dalībnieku lomas, saziņas kārtību, atskaites noteikumus un sastāvu, kā arī visu pārējo, kas būtu jāparedz hartā. Projekta hartas izstrāde atkal ir atsevišķs jautājums.
Apmācīt projekta komandu darba metodēs un instrumentos, vienojoties par darba noteikumiem, dokumentācijas veidiem un sastāvu	Pirmkārt, projekta komandai ir jāizskaidro viss, kas rakstīts hartā, kā tas tiks pielietots praksē. Otrkārt, Pasūtītāja projekta komanda ir jāapmāca par darba metodēm, kuras jūs gatavojaties izmantot visos turpmākajos posmos. Ir lietderīgi apspriest dokumentu formātus, kas tiks izmantoti, apsvērt paraugus. Ja tiks piemēroti kādi modeļu vai biznesa procesu aprakstīšanas noteikumi, tad arī šie noteikumi ir jāapspriež, lai tie būtu saprotami.
Anketa	Aptaujas posms ļauj salīdzinoši ātri iegūt diezgan ticamu informācijas šķēli par uzņēmumu. Šādas informācijas kvalitāti noteiks trīs faktori: Pirmkārt, kā jūs apmācījāt klienta projekta komandu. Viņiem skaidri jāsaprot, kā notiek aptaujas process, un jāspēj nodot informāciju visiem dalībniekiem. Pati anketas forma. Anketām jābūt saprotamām. Vēlams, lai būtu anketu aizpildīšanas instrukcija. Vēl labāk, ja ir pildījuma piemērs. Dalībnieku saraksts. Ir nepieciešams izvēlēties pareizo dalībnieku sastāvu. Ja aprobežosimies tikai ar vadītājiem, nebūs iespējams savākt ticamu informāciju. Iesaku anketā iekļaut visus, kas būs gala rezultātu lietotāji. Piemēram, ja mēs runājam par automatizētas sistēmas ieviešanu, tad ir vērts iekļaut visus, kas būs lietotāji. Ir reizes, kad no 10 viena amata darbiniekiem ir tāds, kurš veic kādu īpašu funkciju, par kuru neviens no atlikušajiem 9 nezina (piemēram, sagatavo speciālu atskaiti vadībai). Ja mēs runājam par tālāku pienākumu pārdali vai amatu aprakstu izstrādi, jums vajadzētu rīkoties tāpat. Es vēršu jūsu uzmanību uz to, ka iztaujāšanas metode turpmākai automatizētas sistēmas ieviešanai vai biznesa procesu aprakstam pareizajā gadījumā ir atšķirīga. Protams, anketu struktūra var būt vienāda, taču tas nav labākais risinājums. Kad mēs aprakstam biznesa procesus, anketām parasti ir vispārīgāks raksturs, jo nav precīzi zināms, ar ko nāksies saskarties. Ja mēs runājam par konkrētas automatizētas sistēmas ieviešanu, tad labāk ir izveidot anketas, kurās ņemtas vērā šīs sistēmas īpašības. Izmantojot šo pieeju, jūs varat nekavējoties noteikt visas sistēmas vājās vietas, kas nav piemērotas šim uzņēmumam. Parasti gatavu sistēmu ieviešanas metodes nodrošina šādu anketu pieejamību. Šādas anketas var izstrādāt vai nu atsevišķām grāmatvedības jomām (piemēram, pasūtījumu uzskaite, pārdošana, cenu noteikšana), vai arī konkrētiem amatiem (piemēram, finanšu direktors). Jautājumu sastāvs ir aptuveni vienāds.
Aptaujas	Aptauja ir mutiska intervija ar speciālistiem, lai noskaidrotu atsevišķu procesu īpatnības. Aptauja ir jāorganizē tā, lai tā neizskatītos tikai pēc "tikšanās-sarunas", bet gan organizētāka. Lai to izdarītu, ir nepieciešams sagatavot tā saukto aptaujas plānu. Tajā varat iekļaut tās anketas daļas, kas jums rada jautājumus, ir pretrunā ar citu anketu informāciju vai arī informācija ir sniegta virspusēji. Vēlams pievienot jautājumus un tikai no personīgās pieredzes.Atbildēm jābūt ieskicētām bez kļūmēm. Ideāli, ja vienojaties par audio ierakstu. Tajā pašā posmā ir jāuzrauga par darbplūsmu sniegtās informācijas pilnīgums (gan primāro dokumentu formas, gan dažādi ziņojumi)
Galveno biznesa procesu vai automatizācijas jomu identificēšana	Pēc anketas un aptaujas var pamatoti uzskatīt, ka ir pietiekami daudz informācijas, lai izdarītu secinājumus par galveno biznesa procesu sadalījumu. Faktiski jau tagad ir iespējams izcelt ne tikai galvenos biznesa procesus, bet gandrīz visu (ja dalībnieku sastāvs tika izvēlēts pareizi). Jautājums par biznesa procesu identificēšanu ir pilnīgi atsevišķs un nebūt ne vienkāršs temats. Mācīšanās šeit ir sarežģīta, un to galvenokārt veido pieredze. No atlasītajiem biznesa procesiem ir jāsastāda saraksts (klasifikators). Pēc tam varēs izlemt, kuras no tām izpētīt dziļāk, kuras nē, kā arī noteikt prioritātes.
Sistēmas galveno prasību formulēšana, mērķi, projekta panākumu kritēriji, procesi detalizētai izpētei	Līdz šim posmam jāsavāc visa primārā informācija par uzņēmuma darbību, jāsastāda biznesa procesu saraksts. Tagad ir pienācis laiks atgriezties pie mērķiem, precizēt tos, ja nepieciešams, pārrunāt ar uzņēmuma pirmajām personām. Formulējot mērķus, jāņem vērā konkrēti rādītāji, kurus sasniedzot, projektu uzskatīsim par veiksmīgu. Ja mēs runājam par automatizētas sistēmas ieviešanu, tad atsevišķā sarakstā var izcelt galveno lietotāju prasības sistēmai. Es to daru atsevišķas tabulas veidā, kur visas prasības ir sagrupētas pa apakšsistēmām, katrai prasībai ir norādīts prasības autors, formulējums un prioritāte. Šo informāciju var izmantot sistēmas izvēršanas plāna sastādīšanai (atsevišķu apakšsistēmu ieviešanas secība), kā arī priekšlikumiem sistēmas tālākai attīstībai (ja pašreizējā projektā nav paredzēts ieviest atsevišķas apakšsistēmas). Ja nepieciešams aprakstīt biznesa procesus, tiek pieņemti lēmumi par tiem procesiem, kuri ir jāizpēta sīkāk.

Tātad mēs nonācām pie jautājuma "Kas tālāk?". Tālāk atsevišķi aplūkosim biznesa procesu aprakstīšanas un darba uzdevuma izstrādes uzdevumus. Nav nejaušība, ka es šos uzdevumus izskatu paralēli. Starp viņiem patiešām ir daudz kopīga, ko es vēlos demonstrēt. Pirmkārt, apsveriet darba secību, aprakstot biznesa procesus.

Soļi	Ko un kā darīt
Biznesa procesa izvēle	No vispārējā biznesa procesu saraksta, kas iegūts iepriekšējos posmos, mēs izceļam vienu (pēc prioritātes) detalizētai izpētei. Pēc tam mēs darām to pašu ar pārējo.
Detalizēta biznesa procesa izpēte	Izvēlēto biznesa procesu pakļaujam detalizētai izpētei: analizējam saņemtos primāros dokumentus, atskaites un programmas procesā izmantoto to struktūru, dažādus failus (piemēram, Excel), runājam ar gala izpildītājiem. Dažādu ideju apkopošana, kā procesu var uzlabot. Tas ir ļoti noderīgi, ja varat novērot procesu tieši tādos apstākļos, kādos tas tiek veikts (ne daudziem patīk, ka viņus skatās, bet ko darīt)
Uzņēmējdarbības procesa grafisks un/vai tekstuāls apraksts (primārais)	Sākam aprakstīt saņemto detalizēto informāciju Pirms procesa aprakstīšanas ir jāizlemj, vai tam būs nepieciešams grafisks apraksts. Ja process ir vienkāršs un skaidrs, tajā ir maz funkciju, un grafiskais attēlojums neuzlabo viņa izpratni vai uztveri, tad tam nav jātērē laiks. Šajā gadījumā pietiek to aprakstīt teksta veidā tabulas veidā. Ja process ir sarežģīts, ar dažādiem loģiskiem nosacījumiem, tad labāk ir dot tā grafisko diagrammu. Diagrammas vienmēr ir vieglāk saprotamas. Ja jūs nolemjat aprakstīt procesu grafiskā formā, tas nebūt nenozīmē, ka jums nav jāsniedz tā teksta apraksts. Tie. procesa tekstuālam aprakstam jebkurā gadījumā jābūt un tas jāveido saskaņā ar to pašu shēmu. To ir ērti izdarīt tabulas veidā, kurā norādīt: katra soļa veicējus, kādu informāciju viņi saņem ievadā, katra soļa aprakstu, kāda informācija tiek ģenerēta izejā. Tālāk mēs redzēsim piemēru, kā tas varētu izskatīties.
Saskaņošana ar izpildītājiem un biznesa procesa īpašnieku	Labākais veids, kā saprast, cik labi esat izvēlējies informācijas pasniegšanas stilu, ir procesa lietotājiem (izpildītājiem) parādīt rezultātu. Vissvarīgākais šādā demonstrācijā ir saprast, cik pareizi jūs sapratāt, kā process tiek veikts. Ja projekta komandas apmācība noritēja veiksmīgi, tad var sagaidīt diezgan adekvātas atsauksmes no izpildītājiem. Un, ja viņi sāks interesēties, tad viss sāks virzīties daudz ātrāk.Identificētie precizējumi un neatbilstības ir jāatspoguļo aprakstā (atjaunina), ja nepieciešams, atkārtojiet darbību.
Biznesa procesu indikatoru identificēšana	Kad jums ir laba izpratne par to, kā tiek izpildīts biznesa process, jums ir jādomā par rādītājiem, kas var izmērīt procesa kvalitāti vai ātrumu. Tas nav viegli, bet nepieciešams. Rādītājam jābūt izmērāmam, t.i. izteikta skaitliskā izteiksmē, un ir jābūt vienkāršam veidam, kā iegūt šo vērtību. Ja izmērīto rādītāju nevar identificēt, pastāv risks, ka biznesa process ir slikti identificēts. Turklāt nebūs iespējams saprast (jo to nevar izmērīt), vai izmaiņas procesā novedīs pie tā uzlabošanas vai nē.
Biznesa procesa noslēguma dokumentācija	Kad esam pārliecinājušies, ka saprotam, kā process tiek veikts (vai tam vajadzētu būt), varam to iekļaut dokumentācijā.
	Iespējami arī tālāki varianti: apskatāmie procesi tiks analizēti un optimizēti, izstrādāti darba apraksti, tiek pieņemti lēmumi par atsevišķu procesu automatizācijas nepieciešamību u.c. Tas var būt arī atsevišķs projekts: biznesa procesu apraksts.

Tagad apsveriet, kādai pieejai tiek izvirzītas prasības informācijas sistēma ar to turpmāku atspoguļojumu darba uzdevumā

Soļi	Ko un kā darīt
Biznesa prasības/automatizācijas jomas izcelšana	Praksē tiek izmantota visa automatizācijas jomas izdalīšana kā prasības (piemēram, "Krājumi"), taču tas nav visvairāk efektīva metode prasību specifikācija. Automatizācijas joma ir prasību grupa, un labāk tās izskatīt atsevišķi. Piemēram, "Preču saņemšanas uzskaite noliktavā"
Detalizēts pētījums par uzņēmējdarbības prasībām	Ar detalizētu biznesa prasības izpēti saprot to, kā gala lietotājs to vēlas redzēt un izmantos (protams, saskaņā ar projekta mērķiem). Programmatūras izstrādes tehnoloģijās to bieži dēvē par "lietošanas gadījumu". Tādējādi detalizēta biznesa prasību izpēte tiek reducēta līdz lietošanas gadījumu izstrādei. Šādas iespējas piemērs ir sniegts raksta 2. pielikumā. Vienkāršākajos gadījumos vispār nav nepieciešams zīmēt lietošanas gadījumus grafisko diagrammu veidā, varat arī aprobežoties ar tekstuālu formulējumu. Piemēram, prasību "Ievadot preci, cena jāaprēķina kā pirkuma cena + 20%" nav jēgas zīmēt. Diagrammas veidā ir lietderīgi uzrādīt prasības, kas apvienotas līdz automatizācijas jomai, kā parādīts 2. papildinājuma piemērā.
Modelēšanas prasības informācijas sistēmā	Te tas ir! Kā jūs droši vien atceraties, es jau esmu pievērsis uzmanību šim vissvarīgākajam darba uzdevuma izstrādes metodoloģijas elementam. "Uzbūvē modeli - iegūsti rezultātu!" Kas būtu jāmodelē? Nepieciešams modelēt iepriekšējā posmā iegūtos lietošanas gadījumus. Kādam jābūt simulācijas rezultātam? Jums vajadzētu iegūt demonstrācijas programmu, kurā tiek ievadīti lietotāja dati un vēlams, lai tā būtu zināma viņa (lietotāja) dzirdei, ņemot vērā nozares specifiku, faktiskās problēmas. Un ne tikai ievadīts, bet jābūt skaidram, no kurienes šie dati ir iegūti, kā tie tika aprēķināti. Šajā brīdī lasītājam vajadzētu uzdot jautājumus: Bet ja ir plānots izstrādāt jaunu sistēmu un vienkārši nav ko modelēt? Ko darīt, ja demonstrācijai nav pietiekami daudz funkcionalitātes un sistēma ir jāuzlabo? Protams, jums ir jāsaskaras ar šādu situāciju, un tas ir normāli. Ko darīt? Ja sistēma ir pilnīgi jauna (kā saka “no nulles”), tad lielākoties būs jāmodelē uz papīra, šeit ļoti palīdzēs lietošanas gadījumu diagrammas. Daļēji ir jēga ieskicēt dažas ekrāna formas, kuras paredzēts izstrādāt (tieši tajā vidē, kurā tiks veikta izstrāde), jo. to zīmēšana kādā redaktorā prasīs ilgāku laiku, un šis darbs ir garlaicīgs. Ja tiek ieviesta jau gatava sistēma, kurai trūkst funkcionalitātes, tad nav ko uztraukties, dati tiek ievadīti ar roku, un lietotājam tiek pateikts, ka pēc nepieciešamajiem uzlabojumiem jārēķina tā un tā ( un viņš to redz). Šādam modelim ir vēlams pievienot tekstuālu aprakstu, pat ja tas ir īss, lai lietotājs varētu patstāvīgi mēģināt strādāt ar modeli savā brīvajā laikā. Tajā pašā aprakstā varat formulēt prasības uzlabojumiem.
Informācijas modeļa demonstrēšana darba grupai	Iegūto modeli rādām Pasūtītājam un pastāstām, kā visam jāstrādā.Labāk modeli demonstrēt pa apakšsistēmām, t.i. pēc prasību grupas. Ja izrādās, ka piedāvātā shēma klientam nederēs, jādomā par citiem lietošanas gadījumiem, jāveic izmaiņas modelī un jāparāda vēlreiz. Tikai tad, ja ir pārliecība, ka plānotais modelis “dzīvos” kopā ar konkrēto klientu, modeli var uzskatīt par veiksmīgu.
Testa izstrāde	Kāpēc ir nepieciešami testi? Būs jāpārbauda, ​​kā mēs spējām ieviest prasības. Attiecīgi ir vēlams veikt testus visām galvenajām jomām, sarežģītiem algoritmiem utt. Tostarp šos testus var izmantot darbu piegādes laikā. Nemaz nav nepieciešams veikt testus katrai sistēmas funkcijai, visur jābūt veselajam saprātam. Ja mēs runājam par gatavu sistēmu, tad testa veikšana “jauna elementa ievadīšanai klientu direktorijā” izskatīsies muļķīgi un laika un pūļu izšķiešana. Bet, ja šī ir pilnīgi jauna sistēma, tas ir pilnīgi iespējams. Kāpēc veikt testus, ja vēl nav sistēmas?Pirmkārt, izstrādātājam būs skaidrāk, ko viņi vēlas no viņa panākt. Otrkārt, atvieglojam dzīvi testētājam (galu galā kāds pārbaudīs izstrādes rezultātu). Kopumā testēšana ir atsevišķa disciplīna, kas nav ļoti vienkārša ar daudzām metodēm. Praksē, kā likums, joprojām tiek izmantotas vienkāršākās pārbaudes metodes.
Prasību dokumentācija darba uzdevuma veidā	Iepriekšējos posmos apkopotā informācija būs tieši tā, kas ir jāiekļauj dokumenta "Nolikums" bāzē prasību sadaļā, tāpēc atliek to visu pareizi sakārtot.
Turpmākās darbības (vai to trūkums), atkarībā no projekta mērķiem	Izstrādes process, partneru meklēšana projektam, konkursam utt., var aizņemt ilgāku laiku, viss atkarīgs no situācijas.

Jā, darba uzdevuma izstrāde ir laikietilpīgs process un tāpēc dārgs. Bet, ja tas tiek darīts pareizi, tas paglābj Klientu no nepiepildītām cerībām. Izpildītājam ir jādara tas, ko pieprasa Pasūtītājs, nevis jāatkārto viens un tas pats simts reizes. Un kopumā tas piešķir caurskatāmību visam projektam.

Pielikums 1. Aprakstīts biznesa process EPC notācijā.