Automatizavimo sąlygos. Kas yra techninė užduotis? Vieningo automatizuotų sistemų standartų rinkinio sukūrimo nuostatos

129 kb.09.12.2011 03:33

1.doc

^ Pristatymo datanuo 1990-01-01

Šis standartas taikomas automatizuotoms sistemoms (AS), skirtoms įvairių rūšių veiklai (valdymui, projektavimui, tyrimams ir kt.) automatizuoti, įskaitant jų derinius, ir nustato dokumento „Kūrimo sąlygos“ sudėtį, turinį, išdavimo taisykles. plėtros ar modernizavimo) sistemos“ (toliau – AE TK).

Rekomenduojama branduolinių elektrinių techninių specifikacijų rengimo, tvirtinimo ir tvirtinimo tvarka pateikta 1 priede.
^

1. BENDROSIOS NUOSTATOS

1.1. Atominių elektrinių TSR yra pagrindinis dokumentas, apibrėžiantis kūrimo (plėtros ar modernizavimo – toliau – kūrimas) reikalavimus ir tvarką. automatizuota sistema, pagal kurią vykdoma AS plėtra ir jos priėmimas paleidžiant eksploatuoti.

1.2. Atominių elektrinių specifikacijos yra sukurtos visai sistemai, skirtos veikti savarankiškai arba kaip kitos sistemos dalis.

Be to, TOR gali būti sukurtas šioms AE dalims:

• 
  apie AE posistemius, AE užduočių kompleksus ir kt. pagal šio standarto reikalavimus;
• 
  techninės įrangos komponentams ir programinei įrangai bei techninės įrangos sistemoms pagal ESKD ir SRPP standartus;
• 
  programinei įrangai pagal ESPD standartus;
• 
  informaciniams produktams pagal GOST 19.201 ir NTD, veikiantys AS kliento skyriuje.

Pastaba.Į automatinės valdymo sistemos TOR, skirtą tarpusavyje susijusių objektų grupei, turėtų būti įtraukti tik reikalavimai, bendri objektų grupei. Specialūs reikalavimai atskiram valdymo objektui turėtų atsispindėti šio objekto ACS TOR.

1.3. Reikalavimai AU šio standarto nustatytoje apimtyje gali būti įtraukti į naujai kuriamo automatikos objekto projektavimo užduotį. Šiuo atveju atominių elektrinių techninės specifikacijos nėra parengtos.

1.4. Reikalavimai, įtraukti į TOR AE, turi atitikti dabartinį mokslo ir technologijų išsivystymo lygį ir nenusileisti panašiems reikalavimams geriausiems šiuolaikiniams šalies ir užsienio analogams. TOR nurodyti reikalavimai AE neturėtų riboti sistemos kūrėjo ieškant ir įgyvendinant efektyviausių techninių, galimybių ir kitų sprendimų.

1.5. AE specifikacijos rengiamos remiantis pradiniais duomenimis, įskaitant tuos, kurie yra GOST 24.601 nustatyto etapo „AE kūrimo tyrimai ir pagrindimas“ galutiniuose dokumentuose.

1.6. Atominių elektrinių TOR apima tik tuos reikalavimus, kurie papildo šio tipo sistemoms (ACS, CAD, ASNI ir kt.) esančius reikalavimus, esančius galiojančiame NTD, ir yra nulemti konkretaus objekto, kuriam sistema skirta, specifikos. kuriama.

1.7. TOR pakeitimai AE įforminami priedu arba protokolu, kurį pasirašo užsakovas ir kūrėjas. Priedas arba nurodytas protokolas yra neatskiriama AE ToR dalis. TK ant AC tituliniame puslapyje turėtų būti įrašas „Galioja nuo ...“.
^

2. SUDĖTIS IR TURINYS

2.1. AE techninę reglamentą sudaro šie skyriai, kuriuos galima suskirstyti į poskyrius:

• 
  1) bendroji informacija;
• 
  2) sistemos kūrimo (plėtojimo) tikslas ir tikslai;
• 
  3) automatikos objektų charakteristikos;
• 
  4) sistemos reikalavimai;
• 
  5) sistemos kūrimo darbo sudėtis ir turinys;
• 
  6) sistemos kontrolės ir priėmimo tvarka;
• 
  7) darbų, skirtų paruošti automatikos objektą sistemai pradėti eksploatuoti, sudėties ir turinio reikalavimai;
• 
  8) reikalavimai dokumentacijai;
• 
  9) plėtros šaltiniai.

Programos gali būti įtrauktos į AS skirtą TOR.

2.2. Atsižvelgiant į automatizavimo objekto tipą, paskirtį, specifines ypatybes ir sistemos veikimo sąlygas, leidžiama paraiškų pavidalu sudaryti TOR skyrius, įvesti papildomus, neįtraukti ar sujungti TOR poskyrius.

Sistemos dalių TOR neapima skilčių, kurios dubliuoja visos AE TOR skyrių turinį.

2.3. Skyriuje " Bendra informacija» nurodyti:

• 
  1) visas sistemos pavadinimas ir jos pavadinimas simbolis;
• 
  2) temos šifras arba sutarties šifras (numeris);
• 
  3) sistemos kūrėjo ir užsakovo (naudotojo) įmonių (asociacijų) pavadinimas ir jų rekvizitai;
• 
  4) dokumentų, kurių pagrindu kuriama sistema, sąrašas, kas ir kada šie dokumentai buvo patvirtinti;
• 
  5) planuojamos sistemos kūrimo darbų pradžios ir pabaigos datos;
• 
  6) informacija apie darbų finansavimo šaltinius ir tvarką;
• 
  7) sistemos (jos dalių) kūrimo, atskirų priemonių (techninės, programinės įrangos, informacijos) ir programinės bei techninės (programinės ir metodinės) gamybos ir derinimo darbų rezultatų įforminimo ir pateikimo užsakovui tvarka. sistemos kompleksai.

2.4. Skyrius „Sistemos sukūrimo (plėtojimo) tikslas ir uždaviniai“ susideda iš poskyrių:

• 
  1) sistemos paskirtis;
• 
  2) sistemos sukūrimo tikslas.

2.4.1. Poskyryje „Sistemos paskirtis“ nurodykite automatizuotos veiklos rūšį (valdymas, projektavimas ir kt.) ir automatizavimo objektų (objektų), kuriuose ji turėtų būti naudojama, sąrašą.

Automatizuotoms valdymo sistemoms papildomai nurodomas automatizuotų valdymo organų (taškų) ir valdomų objektų sąrašas.

2.4.2. Poskyryje „Sistemos kūrimo tikslai“ pateikite automatikos objekto techninių, technologinių, gamybinių, ekonominių ar kitų rodiklių, kuriuos reikia pasiekti sukūrus AS, pavadinimus ir reikalingas reikšmes bei nurodykite sistemos kūrimo tikslų pasiekimo vertinimo kriterijai.

2.5. Skyriuje „Automatizavimo objekto charakteristikos“ nurodykite:

• 
  1) trumpą informaciją apie automatikos objektą arba nuorodas į dokumentus, kuriuose yra tokia informacija;
• 
  2) informacija apie automatikos objekto eksploatavimo sąlygas ir aplinkos charakteristikas.

Pastaba: CAD atveju skyriuje papildomai pateikiami pagrindiniai projektavimo objektų parametrai ir charakteristikos.

2.6. Skyrius „Reikalavimai sistemai“ susideda iš šių poskyrių:

• 
  1) reikalavimai visai sistemai;
• 
  2) reikalavimai sistemos atliekamoms funkcijoms (užduotims);
• 
  3) reikalavimai užstato rūšims.

Sistemos reikalavimų, įtrauktų į šį AE ToR skirsnį, sudėtis nustatoma atsižvelgiant į tipą, paskirtį, specifines savybes ir eksploatavimo sąlygas. specifinė sistema. Kiekviename poskyryje pateikiamos nuorodos į dabartinį NTD, kurios apibrėžia reikalavimus atitinkamo tipo sistemoms.

2.6.1. Poskyryje „Reikalavimai visai sistemai“ nurodykite:

• 
  reikalavimai sistemos struktūrai ir veikimui;
• 
  reikalavimai sistemos darbuotojų skaičiui ir kvalifikacijai bei darbo režimui;
• 
  paskirties rodikliai;
• 
  patikimumo reikalavimai;
• 
  saugos reikalavimai;
• 
  ergonomikos ir techninės estetikos reikalavimai;
• 
  gabenamumo reikalavimai mobiliajai AS;
• 
  sistemos komponentų eksploatavimo, priežiūros, remonto ir saugojimo reikalavimai;
• 
  informacijos apsaugos nuo neteisėtos prieigos reikalavimai;
• 
  informacijos saugos reikalavimai avarijų atveju;
• 
  apsaugos nuo išorinių poveikių reikalavimai;
• 
  patento grynumo reikalavimai;
• 
  standartizavimo ir unifikavimo reikalavimai;
• 
  Papildomi reikalavimai.

2.6.1.1. Sistemos struktūrai ir veikimui keliami reikalavimai:

• 
  1) posistemių sąrašas, jų paskirtis ir pagrindinės charakteristikos, reikalavimai hierarchijos lygių skaičiui ir sistemos centralizavimo laipsniui;
• 
  2) ryšio tarp sistemos komponentų informacijos mainų metodų ir priemonių reikalavimai;
• 
  3) kuriamos sistemos jungčių su susijusiomis sistemomis charakteristikų reikalavimai, reikalavimai jos suderinamumui, įskaitant nurodymus, kaip keistis informacija (automatiškai, siunčiant dokumentus, telefonu ir pan.);
• 
  4) reikalavimus sistemos darbo režimams;
• 
  5) sistemos diagnozavimo reikalavimai;
• 
  6) sistemos plėtros, modernizavimo perspektyvos.

2.6.1.2. AE personalo skaičiui ir kvalifikacijai keliami reikalavimai:

• 
  AE darbuotojų (naudotojų) skaičiaus reikalavimai;
• 
  personalo kvalifikacijos reikalavimai, jų mokymo ir žinių bei įgūdžių kontrolės tvarka;
• 
  reikalingą AE personalo darbo režimą.

2.6.1.3. AS paskirties rodiklių reikalavimuose pateikiamos parametrų reikšmės, apibūdinančios sistemos atitikties jos paskirčiai laipsnį.

ACS nurodykite:

• 
  sistemos prisitaikymo prie procesų ir valdymo metodų pokyčių, prie valdymo objekto parametrų nukrypimų laipsnį;
• 
  leistinos sistemos modernizavimo ir plėtros ribos;
• 
  tikimybinės-laikinės charakteristikos, pagal kurias išsaugoma numatyta sistemos paskirtis.

2.6.1.4. Patikimumo reikalavimai apima:

• 
  1) visos sistemos ar jos posistemių patikimumo rodiklių sudėtis ir kiekybinės vertės;
• 
  2) avarinių situacijų, kurioms turėtų būti reglamentuojami patikimumo reikalavimai, sąrašas ir atitinkamų rodiklių reikšmės;
• 
  3) patikimumo reikalavimai techninėmis priemonėmis ir programinė įranga;
• 
  4) patikimumo rodiklių vertinimo ir stebėjimo metodų reikalavimai įvairiuose sistemos kūrimo etapuose pagal galiojančius norminius ir techninius dokumentus.

2.6.1.5. Saugos reikalavimai apima saugos užtikrinimo reikalavimus montuojant, paleidžiant, eksploatuojant, prižiūrint ir remontuojant sistemos technines priemones (apsaugą nuo elektros srovė, elektromagnetiniai laukai, akustinis triukšmas ir kt.), pagal leistinus apšvietimo, vibracijos ir triukšmo apkrovų lygius.

2.6.1.6. Ergonomikos ir techninės estetikos reikalavimai apima AS rodiklius, nurodančius reikiamą žmogaus ir mašinos sąveikos kokybę bei personalo darbo sąlygų komfortą.

2.6.1.7. Mobiliosioms AE keliamumo reikalavimai apima projektinius reikalavimus, užtikrinančius sistemos techninių priemonių transportavimą, taip pat reikalavimus transporto priemonių.

2.6.1.8. Eksploatavimo, priežiūros, remonto ir saugojimo reikalavimai apima:

• 
  1) eksploatavimo sąlygos ir taisyklės (režimas), kurios turėtų užtikrinti, kad būtų naudojamos sistemos techninės priemonės (TS) su nurodytais techniniais rodikliais, įskaitant sistemos TP tipus ir dažnumą arba leistinumą veikti be priežiūros. ;
• 
  2) preliminarūs reikalavimai dėl leistinų plotų personalo ir sistemos TS, elektros tiekimo tinklų parametrams ir kt.;
• 
  3) techninės priežiūros personalo skaičiaus, kvalifikacijos ir jų darbo režimų reikalavimai;
• 
  4) atsarginių gaminių ir prietaisų rinkinio sudėties, išdėstymo ir laikymo sąlygų reikalavimai;
• 
  5) techninės priežiūros grafiko reikalavimai.

2.6.9. Reikalavimai informacijos apsaugai nuo neteisėtos prieigos apima NTD nustatytus reikalavimus, veikiančius kliento pramonėje (departamente).

2.6.1.10. Informacijos saugos reikalavimai apima įvykių sąrašą: avarijas, techninių priemonių gedimus (įskaitant elektros energijos tiekimo praradimą) ir pan., kurių metu turi būti užtikrintas informacijos saugumas sistemoje.

2.6.1.11. Apsaugos nuo išorinių poveikių priemonių reikalavimuose pateikiama:

• 
  1) AE objektų radioelektroninės apsaugos reikalavimai;
• 
  2) atsparumo, stabilumo ir stiprumo išoriniam poveikiui reikalavimai (naudojimo aplinka).

2.6.1.12. Patento grynumo reikalavimuose nurodomas sąrašas šalių, kurių atžvilgiu turi būti užtikrintas sistemos ir jos dalių patentinis grynumas.

2.6.1.13. Standartizavimo ir unifikavimo reikalavimai apima: rodiklius, nustatančius reikiamą standarto panaudojimo laipsnį, unifikuotus sistemos funkcijų (užduočių) įgyvendinimo metodus, tiekiamą programinę įrangą, tipinius matematinius metodus ir modelius, standartinius projektinius sprendimus, unifikuotas valdymo dokumentų formas. nustatyti GOST 6.10.1, visos Sąjungos techninės ir ekonominės informacijos klasifikatoriai ir kitų kategorijų klasifikatoriai pagal jų apimtį, tipinių automatizuotų darbo vietų, komponentų ir kompleksų naudojimo reikalavimus.

2.6.1.14. Papildomi reikalavimai apima:

• 
  1) reikalavimai dėl sistemos aprūpinimo personalo mokymo įrenginiais (treniruokliais, kitais panašios paskirties įrenginiais) ir jų dokumentacija;
• 
  2) reikalavimai serviso įrangai, stendams tikrinti sistemos elementus;
• 
  3) sistemos reikalavimai, susiję su specialios sąlygos operacija;
• 
  4) specialius reikalavimus sistemos kūrėjo ar užsakovo nuožiūra.

2.6.2. Poskyryje „Reikalavimai sistemos atliekamoms funkcijoms (užduotims)“ pateikiama:

 1) kiekvienam posistemiui – automatizuotinų funkcijų, užduočių ar jų kompleksų (įskaitant ir užtikrinančius sistemos dalių sąveiką) sąrašas;

kuriant sistemą dviejose ar daugiau eilių – funkcinių posistemių, atskirų funkcijų ar užduočių, įgyvendinamų 1-oje ir vėlesnėse eilėse, sąrašas;

 2) kiekvienos funkcijos, užduoties (ar užduočių rinkinio) įgyvendinimo grafikas;

 3) reikalavimai kiekvienos funkcijos (užduoties ar užduočių rinkinio) įgyvendinimo kokybei, išvesties informacijos pateikimo formai, reikalaujamo tikslumo ir vykdymo laiko charakteristikoms, funkcijų grupės vienu metu vykdymo reikalavimai. , rezultatų patikimumas;

 4) sąrašas ir gedimo kriterijai kiekvienai funkcijai, kuriai nustatyti patikimumo reikalavimai.

2.6.3. Poskyryje „Reikalavimai paramos rūšims“, priklausomai nuo sistemos tipo, pateikiami reikalavimai matematinei, informacinei, kalbinei, programinei, techninei, metrologinei, organizacinei, metodinei ir kitų tipų sistemos pagalbai.

2.6.3.1. Sistemos matematiniam palaikymui pateikiami reikalavimai sudėčiai, apimčiai (ribojimams) ir metodams, matematinių metodų ir modelių naudojimui sistemoje, tipiniams kuriamiems algoritmams ir algoritmams.

2.6.3.2. Informaciniam sistemos palaikymui pateikiami šie reikalavimai:

• 
  1) į duomenų sudėtį, struktūrą ir organizavimo metodus sistemoje;
• 
  2) keistis informacija tarp sistemos komponentų;
• 
  3) į informacijos suderinamumą su gretimomis sistemomis;
• 
  4) dėl toje įmonėje veikiančių sąjunginių ir registruotų respublikinių, ūkio šakų klasifikatorių, unifikuotų dokumentų ir klasifikatorių naudojimo;
• 
  5) dėl duomenų bazių valdymo sistemų naudojimo;
• 
  6) į duomenų rinkimo, apdorojimo, perdavimo sistemoje ir duomenų pateikimo proceso struktūrą;
• 
  7) apsaugoti duomenis nuo sunaikinimo avarijų ir sistemos elektros energijos tiekimo sutrikimų atveju;
• 
  8) duomenų kontrolė, saugojimas, atnaujinimas ir atkūrimas;
• 
  9) teisinės galios suteikimo dokumentams, parengtiems AS techninėmis priemonėmis, tvarka (pagal 2010 m GOST 6.10.4 ).

2.6.3.3. Sistemos kalbiniam palaikymui pateikiami programavimo kalbų naudojimo sistemoje reikalavimai. aukštas lygis, vartotojų sąveikos kalbos ir sistemos techninės priemonės, taip pat duomenų kodavimo ir dekodavimo reikalavimai, duomenų įvesties-išvesties kalbos, duomenų apdorojimo kalbos, dalykinės srities (automatizavimo objekto) apibūdinimo priemonės, sistemos organizavimo būdai. dialogą.

2.6.3.4. Sistemos programinei įrangai pateikiamas įsigytos programinės įrangos sąrašas ir reikalavimai:

• 
  1) programinės įrangos nepriklausomumui nuo naudojamos CVT ir veiklos aplinkos;
• 
  2) į programinės įrangos kokybę, jos teikimo ir kontrolės būdus;
• 
  3) jei reikia suderinti naujai kuriamą programinę įrangą su algoritmų ir programų fondu.

2.6.3.5. Techniniam sistemos palaikymui pateikiami šie reikalavimai:

• 
  1) į techninių priemonių tipus, įskaitant techninių priemonių kompleksų tipus, programinės ir techninės įrangos kompleksus ir kitus komponentus, kurie yra priimtini naudoti sistemoje;
• 
  2) į sistemos techninės priežiūros funkcines, konstrukcines ir eksploatacines charakteristikas.

2.6.3.6. Metrologinės pagalbos reikalavimai yra šie:

• 
  1) preliminarus matavimo kanalų sąrašas;
• 
  2) parametrų matavimų tikslumo ir (ar) matavimo kanalų metrologinių charakteristikų reikalavimai;
• 
  3) sistemos techninių priemonių metrologinio suderinamumo reikalavimus;
• 
  4) sistemos valdymo ir skaičiavimo kanalų, kurių tikslumo charakteristikas būtina įvertinti, sąrašas;
• 
  5) techninės ir programinės įrangos, kurios yra sistemos matavimo kanalų dalis, metrologinio palaikymo, įrankių, įmontuoto valdymo, matavimo kanalų ir matavimo priemonių, naudojamų reguliuojant ir tikrinant sistemą, metrologinio tinkamumo reikalavimus;
• 
  6) metrologinio sertifikavimo tipas (valstybinis ar žinybinis), nurodant jo vykdymo tvarką ir sertifikavimą vykdančias organizacijas.

2.6.3.7. Organizacinei pagalbai keliami šie reikalavimai:

 1) į sistemos eksploatavimo ar veiklą vykdančių padalinių struktūrą ir funkcijas;

 2) į sistemos veikimo organizavimą ir sąveikos tarp AE personalo ir automatikos objekto personalo tvarką;

 3) apsauga nuo klaidingų sistemos personalo veiksmų.

2.6.3.8. CAD metodiniam palaikymui pateikiami sistemos norminės ir techninės dokumentacijos sudėties reikalavimai (jos eksploatacijos metu naudojamų standartų, normų, metodų ir kt. sąrašas).

2.7. Skyriuje „Sistemos kūrimo (kūrimo) darbo sudėtis ir turinys“ turėtų būti pateiktas sistemos kūrimo etapų ir etapų sąrašas pagal GOST 24.601, jų įgyvendinimo laikas, organizacijų sąrašas. atliekančius darbus, nuorodas į dokumentus, patvirtinančius šių organizacijų sutikimą dalyvauti kuriant sistemą, arba įrašą, identifikuojantį atsakingą asmenį (užsakovą ar kūrėją) už šių darbų atlikimą.

AT šį skyrių taip pat cituoti:

• 
  1) dokumentų sąrašas, pagal GOST 34.201-89 pateikiami atitinkamų darbo etapų ir etapų pabaigoje;
• 
  2) techninės dokumentacijos tyrimo rūšis ir atlikimo tvarka (etapas, etapas, tikrinamos dokumentacijos apimtis, organizacija-ekspertas);
• 
  3) darbo programa, kuria siekiama užtikrinti reikiamą kuriamos sistemos patikimumo lygį (jei reikia);
• 
  4) metrologinės paramos visuose sistemos kūrimo etapuose darbų sąrašas, nurodant jų atlikimo terminus ir vykdančias organizacijas (jei reikia).

2.8. Skiltyje „Sistemos stebėjimo ir priėmimo tvarka“ nurodykite:

• 
  1) sistemos ir jos komponentų tipai, sudėtis, apimtys ir testavimo metodai (testų tipai pagal galiojančius kuriamai sistemai taikomus standartus);
• 
  2) Bendrieji reikalavimaiį darbų priėmimą etapais (dalyvaujančių įmonių ir organizacijų sąrašas, vieta ir laikas), priėmimo dokumentų derinimo ir tvirtinimo tvarka;
• 
  H) priėmimo komisijos statusas (valstybinis, tarpžinybinis, žinybinis).

2.9. Skyriuje „Reikalavimai automatikos objekto paruošimo sistemai pradėti eksploatuoti darbų sudėčiai ir turiniui“ būtina pateikti pagrindinių veiklų ir jų vykdytojų, kuriuos reikėtų atlikti ruošiant automatikos objektą pradėti eksploatuoti, sąrašą. AS pradės veikti.

Pagrindinių veiklų sąrašas apima:

• 
  1) į sistemą patenkančios informacijos pateikimas (pagal informacijos ir kalbinės pagalbos reikalavimus) į formą, tinkamą apdoroti kompiuteriu;
• 
  2) pakeitimai, kuriuos reikia atlikti automatikos objekte;
• 
  3) automatizavimo objekto funkcionavimo sąlygų, kurioms esant garantuojama sukurtos sistemos atitiktis TOR nustatytiems reikalavimams, sudarymas;
• 
  4) sistemos funkcionavimui reikalingų padalinių ir tarnybų kūrimas;
• 
  5) personalo komplektavimo ir personalo mokymo terminai ir tvarka.

Pavyzdžiui, ACS jie pateikia:

• 
  taikomų valdymo metodų pokyčiai;
• 
  ACS komponentų veikimo sąlygų sudarymas, kurioms esant garantuojama sistemos atitiktis TOR numatytiems reikalavimams.

2.10. Skiltyje „Reikalavimai dokumentacijai“ pateikiama:

• 
  1) rengiamų dokumentų rinkinių ir tipų sąrašas, atitinkantis sistemos kūrėjo ir užsakovo sutartus reikalavimus. GOST 34.201-89 ir kliento pramonės NTD;
  mašininėse laikmenose išduotų dokumentų sąrašas;
  reikalavimai mikrofilmavimo dokumentacijai;
• 
  2) įvairių pramonės šakų taikymo komponentų elementų dokumentavimo reikalavimai pagal ESKD ir ESPD reikalavimus;
• 
  3) nesant valstybinių standartų, apibrėžiančių sistemos elementų dokumentavimo reikalavimus, juose papildomai pateikiami tokių dokumentų sudėties ir turinio reikalavimai.

2.11. Skyriuje „Plėtros šaltiniai“ turėtų būti išvardyti dokumentai ir informacinė medžiaga (galimybių studija, atliktų tiriamųjų darbų ataskaitos, informacinė medžiaga apie šalies, užsienio analogines sistemas ir kt.), kurių pagrindu buvo sukurta TK ir kuri turėtų būti naudojami kuriant sistemą.

2.12. AE TOR sudėtis, esant patvirtintiems metodams, apima programas, kuriose yra:

• 
  1) numatomo sistemos efektyvumo apskaičiavimas;
• 
  2) sistemos mokslinio ir techninio lygio įvertinimas.

Programos įtraukiamos į AE skirtą TOR, kaip susitaria kūrėjas ir sistemos užsakovas.
^

3. PROJEKTAVIMO TAISYKLĖS

3.1. TOR skyriai ir poskyriai AE turi būti išdėstyti taip, kaip nurodyta 2010 m. 2 šio standarto.

3.2. TK AU sudaromas pagal GOST 2.105 reikalavimus A4 formato lapuose pagal GOST 2.301 be rėmo, pagrindinio užrašo ir papildomų stulpelių prie jo.

Lapų (puslapių) numeriai užrašomi, pradedant nuo pirmojo lapo, einančio po titulinio lapo, lapo viršuje (virš teksto, viduryje), nurodant TK kodą AC.

3.3. Rodiklių, normų ir reikalavimų reikšmės paprastai nurodomos su didžiausiais nuokrypiais arba didžiausiomis ir mažiausiomis vertėmis. Jeigu šiuos rodiklius, normas, reikalavimus vienareikšmiškai reglamentuoja NTD, AE skirtoje TOR turėtų pateikti nuorodą į šiuos dokumentus ar jų skyrius bei papildomus reikalavimus, kuriuose atsižvelgiama į kuriamos sistemos ypatybes. Jei kuriant AE TOR negalima nustatyti konkrečių rodiklių, normų ir reikalavimų verčių, ji turėtų užregistruoti šių rodiklių, normų ir reikalavimų nustatymo ir susitarimo tvarką:

„Galutinis reikalavimas (vertė) nurodomas procese ...

Ir tai suderinta su protokolu su ... etape ...“.

Tuo pačiu metu AE TOR tekstas nekeičiamas.

3.4. Tituliniame lape dedami užsakovo, kūrėjo ir koordinuojančių organizacijų parašai, kurie užantspauduojami antspaudu. Jei reikia, titulinis lapas sudaromas keliuose puslapiuose. Paskutiniame puslapyje yra parašai AE techninių sąlygų rengėjų ir pareigūnų, dalyvaujančių tvirtinant ir peržiūrint AE TĮ projektą.

AS TK titulinio lapo forma pateikta 2 priede. Paskutinio AS skirto TK lapo forma pateikta 3 priede.

3.5. Jei reikia, TK ant AU tituliniame puslapyje leidžiama dėti pramonėje nustatytus kodus, pavyzdžiui: saugos antspaudas, darbo kodas, TK registracijos numeris ir kt.

3.6. AE techninių sąlygų priedo titulinis puslapis surašomas taip pat, kaip ir techninės užduoties titulinis lapas. Vietoj pavadinimo „Teisinės sąlygos“ jie rašo „AC TOR priedas Nr. ...“.

3.7. Vėlesniuose AS priedo TOR priedo lapuose pateikiamas pakeitimo pagrindas, pakeitimo turinys ir nuorodos į dokumentus, pagal kuriuos šie pakeitimai daromi.

3.8. Pateikiant TĮ priedo tekstą, reikia nurodyti atitinkamų pastraipų, pastraipų, pagrindinių TU apie AS lentelių ir kt. numerius ir vartoti žodžius: „pakeisti“, „papildyti“, „ ištrinti“, „pateikti naujame leidime“.

1 PRIEDAS
Rekomenduojamas
^

AE TOR KŪRIMO, SUTARTIES IR PATVIRTINIMO TVARKA

1. AE TOR projektą parengia sistemos kūrėjas, dalyvaujant užsakovui, remdamasis Techniniai reikalavimai(programos, taktinės ir techninės specifikacijos ir kt.).

Konkursinio darbo organizavimo metu AE TP projekto variantus apsvarsto užsakovas, kuris arba pasirenka pageidaujamą variantą, arba lyginamosios analizės pagrindu parengia galutinę AE TNT versiją su. būsimos AE vystytojo dalyvavimas.

2. AE techninės specifikacijos projekto patvirtinimo su valstybinės priežiūros institucijomis ir kitomis suinteresuotomis organizacijomis poreikį kartu nustato sistemos užsakovas ir AE techninės specifikacijos projekto rengėjas, t.

AE TNT projekto tvirtinimo darbus kartu atlieka AE TNT kūrėjas ir sistemos užsakovas, kiekvienas savo ministerijos (departamento) organizacijose.

3. Kiekvienos organizacijos AE TOR projekto patvirtinimo terminas neturėtų viršyti 15 dienų nuo jo gavimo dienos. Atominių elektrinių TSR projekto kopijas (kopijas) rekomenduojama siųsti tvirtinti visoms organizacijoms (skyriams) vienu metu.

4. Pastabos dėl AE TOR projekto turi būti pateiktos su techniniu pagrindimu. Sprendimus dėl pastabų turi priimti AE techninio užsakymo projekto rengėjas ir sistemos užsakovas iki AE TSR patvirtinimo.

5. Jeigu AE susitariant dėl ​​TOR projekto kilo nesutarimų tarp vystytojo ir užsakovo (ar kitų suinteresuotų organizacijų), tada surašomas nesutarimų protokolas (savavališka forma) ir nustatyta tvarka priimamas konkretus sprendimas.

6. AE TOR projekto patvirtinimą leidžiama surašyti kaip atskirą dokumentą (raštą). Tokiu atveju antraštėje „Sutarta“ pateikite nuorodą į šį dokumentą.

7. Atominių elektrinių techninių specifikacijų tvirtinimą atlieka sistemos kūrėjo ir užsakovo įmonių (organizacijų) vadovai.

8. AE specifikacija (specifikacijos papildymas) prieš pateikiant ją tvirtinti turi būti patikrinta specifikaciją parengusios organizacijos standartinės kontrolės tarnybos ir prireikus atlikti metrologinę ekspertizę.

9. Patvirtintų AE techninių sąlygų kopijas per 10 dienų nuo patvirtinimo AE techninių sąlygų rengėjas išsiunčia sistemos kūrimo dalyviams.

10. AE techninių sąlygų papildymų derinimas ir tvirtinimas vykdomas AE TSR nustatyta tvarka.

11. Neleidžiama patvirtinti TOR pakeitimų AE po to, kai sistema ar jos eilė pateikiama priėmimo bandymams.

12. Techninių specifikacijų ir jos papildymų registravimas, apskaita ir saugojimas AE vykdomas pagal GOST 2.501 reikalavimus.

______________________________________________________ Organizacijos pavadinimas – AE techninių specifikacijų rengėjas PATVIRTINTI Vadovas (pareigos, įmonės pavadinimas - AE klientas) data PATVIRTINTI Vadovas (pareigos, įmonės pavadinimas – kūrėjas „AS“) Asmeninis parašas Parašo stenograma Kintamosios srovės tipo pavadinimas ________________________________________________________ Automatikos objekto pavadinimas ________________________________________________________ Sutrumpintas pavadinimas AS ^ TECHNINĖ UŽDUOTIS Ant ____ lapų Galioja nuo SUTINKA Vadovas (pareigos, koordinuojančios organizacijos pavadinimas) Asmeninis parašas Parašo stenograma

PAGAMINTAS

SUTINKA

4 PRIEDAS
Nuoroda
^

VIENINGO AUTOMATIZUOTOMŲ SISTEMŲ STANDARTŲ KOMPLEKSO KŪRIMO NUOSTATOS

1. Pradinės prielaidos kompleksui sukurti

1.1. Įvairių klasių ir paskirties automatizuotų sistemų kūrimas ir diegimas daugelyje pramonės šakų vykdomas pagal norminę ir techninę dokumentaciją, kuri nustato įvairias organizacines, metodines ir technines normas, taisykles ir reglamentus, trukdančius integruoti sistemas ir efektyviai bendrai funkcionuoti. .

1.2. Tuo laikotarpiu, kai SSRS Gosstandartas priėmė sprendimą tobulinti tarpsektorinius standartų kompleksus, galiojo šie standartų kompleksai ir sistemos, nustatančios reikalavimus įvairių tipų atominėms elektrinėms:

• 
  1) vieninga automatizuotų valdymo sistemų standartų sistema (24-oji sistema), kuri taikoma automatizuotoms valdymo sistemoms, automatizuotoms valdymo sistemoms, automatizuotoms procesų valdymo sistemoms ir kitoms organizacinėms bei ekonominėms sistemoms;
• 
  2) standartų rinkinys (sistema 23501); išplėsti iki kompiuterinių projektavimo sistemų;
• 
  3) 14-osios standartų sistemos ketvirtoji grupė, apimanti automatizuotas gamybos technologinio paruošimo sistemas.

1.3. Standartų taikymo automatizuotoms valdymo sistemoms, CAD, automatizuotoms procesų valdymo sistemoms, ASTPP praktika parodė, kad jose naudojamas tas pats koncepcinis aparatas, yra daug bendrų standartizacijos objektų, tačiau standartų reikalavimai tarpusavyje nėra derinami, t. skiriasi darbų sudėtis ir turinys, skiriasi dokumentų paskirtis, sudėtis, turinys ir formatavimas ir kt.

1.4. Singlo nebuvimo fone techninę politiką AS kūrimo srityje standartų įvairovė neužtikrino plataus AS suderinamumo jų sąveikos metu, neleido sistemoms replikuotis, trukdė plėtoti perspektyvias kompiuterinių technologijų panaudojimo sritis.

1.5. Šiuo metu pereinama prie kompleksinių AS (užsienio CAD sistemų – CAM) kūrimo, kuri apima automatizuotas valdymo sistemas technologiniams procesams ir pramonės šakoms, CAD – projektuotoją, CAD – technologą, ASNI ir kitas sistemas. Kuriant tokias sistemas naudojant prieštaringas taisykles, pablogėja kokybė, pabrangsta darbai ir vėluojama pradėti eksploatuoti AE.

1.6. Įvairių tikslų automatizuotoms sistemoms: ASNI, CAD, OASU, APCS, APCS, APCS, ASK, ASTPP, įskaitant jų integravimą, turėtų būti taikomas vieningas standartų ir gairių rinkinys.

1.7. Kuriant tarpsektorinius dokumentus, reikėtų atsižvelgti į šias AS, kaip standartizacijos objektų, ypatybes:

• 
  1) techninė užduotis yra pagrindinis dokumentas, pagal kurį sukuriama ir užsakovas priima AS;
• 
  2) AE paprastai kuriamos projektuojant su pilnu serijinės ir vienetinės gamybos gaminių komplektu ir atliekant statybos, montavimo, paleidimo ir paleidimo darbus, būtinus AE pradėti eksploatuoti;
• 
  3) bendruoju atveju AS (AS posistemis) susideda iš programinės ir techninės įrangos (STC), programinių ir metodinių kompleksų (PMC) bei techninio, programinio ir informacinio palaikymo komponentų.
  Šių tipų atramų komponentai, taip pat PMK ir PTK, turi būti gaminami ir tiekiami kaip pramoniniai produktai.
  Komponentai gali būti įtraukti į AS kaip savarankiškos dalys arba gali būti sujungti į kompleksus;
• 
  4) AS kūrimui organizacijose (įmonėse) reikalingas specialus sistemos naudotojų ir priežiūros personalo mokymas;
• 
  5) AS ir kompleksų funkcionavimas užtikrinamas organizacinių ir metodinių dokumentų visuma, kuri kūrimo procese laikoma teisinės, metodinės, kalbinės, matematinės, organizacinės ir kitokios paramos komponentais. Atskiri sprendimai, gauti šios programinės įrangos kūrimo procese, gali būti įgyvendinami kaip techninės, programinės įrangos ar informacinio palaikymo komponentai;
• 
  6) remiantis vykdomas bendras įvairių sistemų ir kompleksų veikimas ir sąveika vietiniai tinklai KOMPIUTERIS.

Vietiniams kompiuterių tinklams taikomos specifikacijos ir sutartys yra privalomos, kad būtų užtikrintas sistemų, kompleksų ir komponentų suderinamumas.
^

2. CEN AS sąsajos su kitomis sistemomis ir standartų rinkiniais

2.1. Standartizavimas AS srityje yra neatsiejama darbo su apibendrinta problema dalis. Informacinės technologijos».

2.2. Vienas standartų rinkinys, reglamentuojantis automatizuotų sistemų dokumentus, kartu su kitomis sistemomis ir standartų rinkiniais turėtų sudaryti pilną reguliavimo ir techninę paramą AS kūrimo ir veikimo procesams.

2.3. EKS AS turėtų apimti automatizuotoms sistemoms būdingas standartizacijos sritis, o tradicines standartizacijos sritis išplėsti iki programinės ir techninės įrangos, programinės įrangos ir metodinių kompleksų bei automatizuotų sistemų apskritai.

2.4. AS kūrimo ir veikimo procesų normatyvinio ir techninio palaikymo standartizacijos kryptys ir uždaviniai yra sugrupuoti taip:

• 
  1) gaminių techninių reikalavimų nustatymas;
• 
  2) bandymo metodų reglamentavimas ir gaminių atestavimo bei sertifikavimo taisyklės;
• 
  3) rengimo taisyklių ir tvarkos reglamentavimas;
• 
  4) dokumentacijos taisyklių nustatymas;
• 
  5) suderinamumo užtikrinimas;
• 
  6) sistemų funkcionavimo organizacinių ir metodinių klausimų reglamentavimas.

1-4 kryptys yra tradicinės kuriant, gaminant ir tiekiant produktus. 5, 6 nurodymai yra specifiniai ir išplaukia iš AS būdingų savybių.

2.5. Atominių elektrinių kaip visumos ir jų komponentų aprūpinimas norminiais ir techniniais dokumentais pagal priimtas standartizacijos sritis ir užduotis skiriasi.

Techninės, programinės įrangos ir informacinio palaikymo komponentai, kaip pramonės reikmėms skirti produktai, atitinkamai laikomi dizaino, programinės įrangos ir informacijos produktais. Šiems gaminiams taikomi esami standartų rinkiniai ESKD, SRPP, ESPD, SGIP, USD, techninės ir ekonominės informacijos klasifikatoriai ir kodifikatoriai, „OTT“, „Bandymo metodai“, „TU“ tipo standartų rinkiniai. kaip kliento OTT.

2.5.1. Visas dizaino gaminių gyvavimo ciklas yra pilnai aprūpintas reglamentine ir technine dokumentacija, galiojančia mechanikos inžinerijoje ir prietaisų gamyboje.

2.5.2. Programinės įrangos produktai pateikiami su NTD, kuri yra įtraukta į kliento ESPD ir OTT. Tačiau šių NTD taikymo sritis turėtų būti išplėsta, kad atspindėtų problemas, susijusias su programinės įrangos produktų kūrimu, kūrimu, platinimu ir veikimu.

2.5.3. Informaciniai produktai šiuo metu nepateikiami su NTD, nors tam tikri klausimai buvo išnagrinėti pagal DDD, techninės ir ekonominės informacijos klasifikatorius ir kodifikatorius.

2.6. Kompleksiniais produktais, neturinčiais analogų mechanikos inžinerijoje, laikomi programinė ir techninė įranga bei programiniai ir metodiniai kompleksai. Atsižvelgiant į PTK ir PMK, kaip pramonės paskirties gaminių, statusą, jų kūrimo taisyklės ir tvarka turėtų būti panašios į gaminių kūrimo ir gamybos sistemos (SRPP) standartų nustatytus reikalavimus.

Gerai pagalvojęs nusprendžiau, kad visos planuojamos antrosios dalies medžiagos sutalpinti į vieną straipsnį vėl nepavyks, antraip tai teoriškai būtų topai, kas jau rašoma daugelyje vadovėlių. Bet juk užduotį iškėliau taip, kad tai būtų galima pritaikyti praktikoje, todėl ateičiai nebespėliosiu, kiek klausimų reikės užbaigti temą. Tam įtakos turės ir skaitytojų atsiliepimai, todėl rašykite, nesidrovėkite!

Naudodamasis proga, noriu užduoti klausimą: ar būtų įdomu surengti praktinio mokymo seminarą Sankt Peterburge apie techninės užduoties rengimą? Susitikdavome, keisdavomės patirtimi. Jei toks susidomėjimas nebus pavienis, žadu organizuoti.

Kadangi skaitytojai yra ne tik programinės įrangos kūrėjai, bet ir verslo analitikai bei vadovai skirtingi lygiai Stengsiuosi rašyti taip, kad visiems būtų įdomu.

Šioje dalyje kalbėsime apie tai, kaip organizuoti reikalavimų rinkimo darbo etapą, iš ko jis turėtų būti sudarytas ir kokias priemones galima naudoti. Kartoju, kad šie darbai etapais labai panašūs į įmonių apklausą, skirtą verslo procesams apibūdinti.

Kaip įprasta gyvenime:

Kaip tai veikia daugelyje projektų
Žingsniai	Kaip tai atsitinka
	Aišku, kad džiaugsmui yra pagrindo, ypač jei projektas didelis, tai nieko blogo! Svarbiausia per ilgai nesidžiaugti, atidėliojus faktinių darbų pradžią, nuo šiol laikas eis kitaip.
	Paprastai šis procesas apsiriboja keliais susitikimais su vadovybe, vėliau – su padalinių vadovais. Patikslinus kai kuriuos Kliento „raginimus“, jie fiksuojami bendrų formuluočių pavidalu. Kartais prie to pridedama turima dokumentacija (kažkada bandė atlikti ekspertizę, dokumentai pagal galiojančius reglamentus, naudojamos ataskaitų formos). Keista, bet po to dauguma automatizavimo sistemų diegėjų džiaugsmingai sušunka: „taip, mūsų sistema turi. Visa tai! Na, šiek tiek pakoreguoti ir viskas pavyks. Paklausus, ar būtina su galutiniais vartotojais aptarti, kaip viskas turėtų veikti (arba kaip atliekamas konkretus procesas), atsakymas dažniausiai yra neigiamas. Išsakoma nuomonė, kad vadovas viską žino už savo pavaldinius. Bet veltui... Už to slypi daugybė spąstų ir kliūčių, o darbų pristatymas gali virsti maratonu kliūčių ruože. Kaip žinia, įprasta maratoną bėgti lygiu keliu, o bėgti su kliūtimis galima tik trumpais atstumais (galima ir nebėgti).
Darbo rezultatų dokumentavimas	Po to prasideda rezultatų dokumentavimas, atsižvelgiant į darbo tikslus: Jei reikia parengti techninę užduotį , konsultantas pradeda stumdyti gautą informaciją pagal paruoštą dokumento šabloną, kad ji gražiai atrodytų ir būtų fiksuoti pagrindiniai reikalavimai (kurie išsakomi iš vadovybės, antraip gali būti nepatvirtinti). Suprasdamas, kad praktikoje tokios techninės užduotys nėra itin naudojamos ir viską reikia išsiaiškinti „pakeliui“, jis išsikelia pagrindinį techninės užduotys tikslą. minimalus derinimo ir tvirtinimo laikas. Ir, jei įmanoma, informacija, skirta apytiksliai įvertinti būsimų darbų kainą (beje, tai taip pat svarbu). Jei norite apibūdinti verslo procesus. Kaip bebūtų keista, bet dažnai visi ankstesni veiksmai atrodo taip pat, kaip ir rengiant techninę užduotį. Vienintelis skirtumas yra dokumentuose. Čia galimi variantai: konsultantai procesą apibūdina savavališkais žodžiais arba naudoja bet kokias verslo procesų apibūdinimo taisykles (žymėjimus). Pirmuoju atveju toks dokumentas pasirodo stebėtinai panašus į techninę užduotį. Pasitaiko net taip, kad pakeitus titulinį puslapį, jokio skirtumo nepamatysi. formalus aprašymo taisyklių laikymasis.Deja, abu variantai nėra patys geriausi geriausia praktika, nes yra daugiau formalumas ir neduoda daug naudos.

Kodėl yra tokia praktika, kaip aprašyta aukščiau? Prisipažįstu, kad nežinau. Niekas neklausia, niekas nežino. Tuo pačiu situacija nesikeičia labai greitai, nors šia tema nuolat diskutuojama, keičiamasi patirtimi, rašomos knygos... Man atrodo, kad viena iš priežasčių yra žema atitinkamo išsilavinimo kokybė. Tam įtakos gali turėti ir tai, kad daugelis specialistų iš viso ateina iš kitų verslų ir viską supranta praktiškai, t.y. jų patirtį formuoja aplinka, kurioje jie atsiduria. Universitetų požiūris ir nenorėjimas būti arčiau realybės – taip pat žinomas faktas, tačiau kartais jų pozicija mane nustebina. Pavyzdžiui, man buvo atvejis, kai magistrantas, talentingas specialistas, norėjo parašyti baigiamąjį darbą 1C platformoje (geras pramonės vystymasis), tačiau katedroje jai buvo pasakyta, kad, nepaisant temos, tai bus neįmanoma. pasikliauti „puikiu“ pažymiu, nes 1C nėra rimta sistema. Esmė čia yra ne tokios nuomonės rimtumas ir objektyvumas, o tai, kad primityvi užduotis klasikine programavimo kalba iškart buvo pripažinta verta „puikaus“ ​​įvertinimo.

Pabandykime aukščiau aptartam procesui suteikti sistemingesnį požiūrį. Kaip jis tada gali atrodyti?

Kaip matote, procesas baigiasi klausimu, nes šiuo klausimu darbas toli gražu nesibaigė, o tada prasidės pats sunkiausias ir praktiškiausias - būtent tai lems gauto rezultato pritaikymą Tikras gyvenimas. Būtent tai lems ankstesnio kūrinio likimą: arba jis nukeliaus į spintą (lentynoje ar kur nors kitur), arba bus vertingas informacijos šaltinis. Ir dar geriau, jei tai taps pavyzdžiu būsimiems projektams.

Noriu pabrėžti, kad iki paskutinio žingsnio diagramoje (kur klausimas) bendras informacijos apie įmonės veiklą rinkimo principas atrodo taip pat, nepriklausomai nuo to, ką planuojama daryti ateityje, aprašyti verslo procesus ar įgyvendinti automatizuota sistema. Taip, pati veiksmų seka yra ta pati, tačiau kai kuriems iš jų naudojami įrankiai gali skirtis. Šį momentą tikrai apsvarstysime, kai tyrinėsime atskirų etapų metodus ir priemones. Mes tai padarysime išsamiai atskiruose straipsniuose, bet dabar apsvarstysime tik svarbiausius. Tolesni veiksmai skirsis ir priklausys nuo to, ko reikia iš projekto: aprašyti verslo procesus arba įdiegti apskaitos sistemą.

Pažiūrėkime, kaip galite pertvarkyti požiūrį į informacijos apie įmonės veiklą rinkimą.

Kaip tai gali atsitikti su kompetentingesniu darbo organizavimu
Žingsniai	Kaip tai atsitinka
Sprendimas priimtas, projektas bus!	Dėl pirmojo varianto čia niekas nesikeičia, emocijų niekas neatšaukė
Surengėme susitikimą su vadovais, surinkome šiek tiek informacijos apie jų viziją apie rezultatą.	Šis žingsnis taip pat išlieka, ir jis yra labai svarbus. Tačiau pagrindinis pirmojo susitikimo (ar kelių susitikimų) su vadovais ir savininkais tikslas – pažintis. Pažintis pirmiausia su žmonėmis ir kompanija. Tokiuose visuotiniuose susirinkimuose suformuluoti tikslai ir pageidavimai gali būti labai įvairūs, net ir fantastiški. Visi jie, žinoma, bus išgirsti, bet ne tai, kad jie bus įgyvendinti. Giliau pasinėrus į įmonės verslą, atsiras kiti tikslai, taip pat bus atmesti ankstesni. Noriu pasakyti, kad iš išankstinių susitikimų neįmanoma suformuluoti aiškių tikslų, visa tai reikės atidžiai išstudijuoti, tokiuose susitikimuose būtina išdėstyti visas savininkų ir aukščiausių pareigūnų žinutes, kad vėliau būtų galima prie jų sugrįžti ir padiskutuoti. kai surenkama pakankamai informacijos. Netgi iš pažiūros paprastas reikalavimas gali pasirodyti neįgyvendinamas arba labai sunkus.
Darbo grupės iš Užsakovo ir Rangovo formavimas, vaidmenų paskirstymas	Būtina nuspręsti, kas dirbs su projektu tiek iš Užsakovo, tiek iš Rangovo pusės. Nepaisant akivaizdaus šio etapo paprastumo, jis atlieka labai svarbų vaidmenį. Jei aiškiai nenustatysite, kas už ką atsakingas, rizikuojate susipainioti vykdydami darbą. Jei iš savo pusės visada galite nurodyti vaidmenis savo komandoje, Klientas gali turėti problemų dėl to. Į ką reikėtų atkreipti dėmesį: Užsakovo darbo grupėje būtinai turi būti tie žmonės, kurie ateityje bent kažkaip paveiks rezultato priėmimą. Jei darysime prielaidą, kad perdavus darbą prisijungs Užsakovo darbuotojai, kurie nedalyvavo tikslų nustatymo ir reikalavimų nustatymo darbuose, tada problemos garantuotos. Galima net tokia absurdiška situacija, kad viskas, pasirodo, daroma ne taip, kaip reikalaujama.Savo praktikoje ne kartą yra tekę susidurti su tokia situacija.Todėl galite apsisaugoti, jei išlygiate ir įforminate dokumentus, niekas, išskyrus Užsakovo darbo grupę, negali dalyvauti darbų priėmime ir pristatyme. Ir geriausia, kad tai būtų nurodyta sutarties sąlygose (sutartyje arba projekto chartijoje). Pamenu, buvo toks atvejis: viename dideliame projekte steigėjas nusprendė prisijungti prie proceso (nežinau kodėl, pasidarė nuobodu žiūrėti) ir dalyvavo viename iš darbinių susitikimų, kur buvo sprendžiamas sąskaitų faktūrų klientams generavimo klausimas. aptarė. Jis nustebo sužinojęs, kad pardavimų vadybininkas išrašo klientui sąskaitą. Jo nuomone, buhalteris turėtų išrašyti sąskaitą, ir nieko daugiau. Bet iš tikrųjų buhalterė visiškai neįsivaizdavo, kas gresia, o vadovas neįsivaizdavo, kaip taip dirbti, jei dėl kiekvienos sąskaitos bėgtų pas buhalterę. Dėl to praradome daug laiko, bet niekas nepasikeitė, sąskaitą vis tiek aprašė vadybininkas. Ir įkūrėjas liko prie savo nuomonės, bet daugiau į procesą nesikišo. Šiame etape patartina vystytis Projekto chartija, kuriame nustatomi dalyvių vaidmenys, bendravimo tvarka, ataskaitų teikimo taisyklės ir sudėtis, taip pat visa kita, kas turėtų būti nustatyta Chartijoje. Projekto chartijos rengimas vėlgi yra atskiras klausimas.
Apmokyti projekto komandą darbo metodais ir priemonėmis, susitarti dėl darbo taisyklių, dokumentacijos rūšių ir sudėties	Pirmiausia reikia paaiškinti projekto komandai viską, kas parašyta Chartijoje, kaip tai bus taikoma praktikoje. Antra, Kliento projekto komanda turi būti apmokyta darbo metodų, kuriuos ketinate naudoti visuose tolesniuose etapuose. Tikslinga aptarti dokumentų formatus, kurie bus naudojami, apsvarstyti pavyzdžius. Jei bus taikomos kokios nors modelių ar verslo procesų aprašymo taisyklės, šios taisyklės taip pat turi būti aptartos, kad jos būtų suprantamos.
Klausimynas	Apklausos etapas leidžia gana greitai gauti gana patikimą informacijos apie įmonę gabalą. Tokios informacijos kokybę lems trys veiksniai: Visų pirma, kaip apmokėte kliento projekto komandą. Jie turi aiškiai suprasti, kaip vyksta apklausos procesas, ir gebėti perduoti informaciją visiems dalyviams. Pati anketos forma. Anketos turi būti suprantamos. Pageidautina, kad būtų anketų pildymo instrukcija. Dar geriau, jei yra užpildymo pavyzdys. Dalyvių sąrašas. Būtina pasirinkti tinkamą dalyvių sudėtį. Jei apsiribosime tik vadovais, patikimos informacijos surinkti nepavyks. Rekomenduoju į anketą įtraukti visus, kurie naudosis galutiniais rezultatais. Pavyzdžiui, jei kalbame apie automatizuotos sistemos įdiegimą, verta įtraukti visus, kurie bus naudotojai. Pasitaiko atvejų, kai iš 10 vienos pareigybės darbuotojų yra vienas, kuris atlieka kokią nors specialią funkciją, apie kurią nebežino nė vienas iš likusių 9 žmonių (pavyzdžiui, rengia specialią ataskaitą vadovybei). Jei kalbame apie tolesnį pareigų perskirstymą ar pareigybių aprašymų kūrimą, tai ir jūs turėtumėte daryti. Atkreipiu jūsų dėmesį į tai, kad apklausos būdas vėlesniam automatizuotos sistemos diegimui ar verslo procesų aprašymui tinkamu atveju skiriasi. Žinoma, anketų struktūra gali būti tokia pati, tačiau tai nėra pats geriausias variantas. Kai aprašome verslo procesus, klausimynai dažniausiai būna bendresnio pobūdžio, nes nėra tiksliai žinoma, su kuo susidurs. Jei kalbame apie konkrečios automatizuotos sistemos įdiegimą, tuomet geriau turėti anketas, kuriose būtų atsižvelgta į šios sistemos ypatybes. Taikydami šį metodą galite iš karto nustatyti visas sistemos kliūtis, kurios netinka šiai įmonei. Paprastai paruoštų sistemų diegimo metodai numato tokių klausimynų prieinamumą. Tokie klausimynai gali būti rengiami arba atskiroms apskaitos sritims (pavyzdžiui, užsakymų apskaita, pardavimas, kainodara), arba konkrečioms pareigoms (pavyzdžiui, finansų direktorius). Klausimų sudėtis yra maždaug tokia pati.
Apklausos	Apklausa – tai žodinis pokalbis su specialistais, siekiant išsiaiškinti atskirų procesų ypatybes. Apklausą būtina organizuoti taip, kad ji neatrodytų tik kaip „susitikimas-pokalbis“, o labiau organizuotas. Tam reikia parengti vadinamąjį apklausos planą. Į jį galite įtraukti tas anketos dalis, kurios jums kelia klausimų, prieštarauja kitų anketų informacijai arba informacija pateikiama paviršutiniškai. Patartina pridėti klausimų ir tik iš asmeninės patirties.Atsakymai turi būti aiškiai išdėstyti. Idealu, jei sutinkate dėl garso įrašo. Tame pačiame etape būtina stebėti pateiktos informacijos apie darbo eigą išsamumą (tiek pirminių dokumentų formas, tiek įvairias ataskaitas).
Pagrindinių verslo procesų arba automatizavimo sričių nustatymas	Atlikus anketą ir apklausą galima pagrįstai manyti, kad informacijos pakanka, kad būtų galima padaryti išvadas apie pagrindinių verslo procesų paskirstymą. Tiesą sakant, jau galima išskirti ne tik pagrindinius verslo procesus, bet ir beveik viską (jei dalyvių sudėtis parinkta teisingai). Verslo procesų identifikavimo klausimas yra visiškai atskira ir ne paprasta tema. Mokymasis čia yra sunkus ir daugiausia vyksta patirties dėka. Sąrašas (klasifikatorius) turėtų būti sudarytas iš pasirinktų verslo procesų. Tada bus galima nuspręsti, kuriuos iš jų reikėtų nagrinėti nuodugniau, kurių ne, taip pat nustatyti prioritetus.
Pagrindinių sistemos reikalavimų, tikslų, projekto sėkmės kriterijų, procesų detaliam tyrimui formulavimas	Iki šio etapo turėtų būti surinkta visa pirminė informacija apie įmonės veiklą, sudarytas verslo procesų sąrašas. Dabar pats laikas grįžti prie tikslų, juos patikslinti, jei reikia, aptarti su pirmaisiais įmonės asmenimis. Formuojant tikslus reikia atsižvelgti į konkrečius rodiklius, kuriuos pasiekę projektą laikysime sėkmingu. Jei mes kalbame apie automatizuotos sistemos įdiegimą, atskirame sąraše galima pabrėžti pagrindinių vartotojų sistemos reikalavimus. Tai darau atskiros lentelės pavidalu, kur visi reikalavimai sugrupuoti pagal posistemes, prie kiekvieno reikalavimo nurodomas reikalavimo autorius, formuluotė ir prioritetas. Ši informacija gali būti naudojama rengiant sistemos diegimo planą (atskirų posistemių diegimo seką), taip pat teikiant pasiūlymus dėl tolimesnės sistemos plėtros (jei dabartiniame projekte nenumatyta diegti atskirų posistemių). Jei reikia aprašyti verslo procesus, priimami sprendimai dėl tų procesų, kuriuos reikia išstudijuoti plačiau.

Taigi mes priėjome prie klausimo "Kas toliau?". Toliau atskirai svarstysime verslo procesų aprašymo ir techninės užduoties rengimo užduotis. Neatsitiktinai šias užduotis svarstau lygiagrečiai. Tarp jų tikrai yra daug bendro, ką noriu pademonstruoti. Pirmiausia apsvarstykite darbų seką aprašydami verslo procesus.

Žingsniai	Ką ir kaip daryti
Verslo proceso pasirinkimas	Iš bendro verslo procesų sąrašo, gauto ankstesniuose etapuose, išskiriame vieną (pagal prioritetą) išsamiam tyrimui. Tada mes darome tą patį su likusia dalimi.
Išsamus verslo proceso tyrimas	Pasirinktą verslo procesą atliekame detaliam tyrimui: analizuojame gautus pirminius dokumentus, ataskaitas ir programos procese naudojamą jų struktūrą, įvairius failus (pvz., Excel), kalbamės su galutiniais vykdytojais. Įvairių idėjų, kaip būtų galima patobulinti procesą, rinkimas. Labai naudinga, jei galite tiksliai stebėti procesą tokiomis sąlygomis, kokiomis jis atliekamas (nedaug kam patinka būti stebimi, bet ką daryti)
Verslo proceso grafinis ir (arba) tekstinis aprašymas (pagrindinis)	Pradedame aprašinėti gautą detalią informaciją Prieš aprašant procesą būtina apsispręsti, ar jam reikės grafinio aprašymo. Jei procesas paprastas ir aiškus, jame yra nedaug funkcijų ir grafinis vaizdas nepagerina jo supratimo ar suvokimo, tada nereikia tam gaišti laiko. Šiuo atveju pakanka jį apibūdinti tekstine forma lentelės pavidalu. Jei procesas yra sudėtingas, su skirtingomis loginėmis sąlygomis, tada geriau pateikti jo grafinę diagramą. Diagramas visada lengviau suprasti. Jei nuspręsite procesą apibūdinti grafine forma, tai visiškai nereiškia, kad jums nereikia pateikti jo tekstinio aprašymo. Tie. Tekstinis proceso aprašymas bet kuriuo atveju turėtų būti sudarytas pagal tą pačią schemą. Patogu tai padaryti lentelės pavidalu, kurioje nurodoma: kiekvieno žingsnio atlikėjai, kokią informaciją jie gauna įėjime, kiekvieno žingsnio aprašymą, kokia informacija generuojama išėjime. Žemiau pamatysime pavyzdį, kaip tai gali atrodyti.
Derinimas su atlikėjais ir verslo proceso savininku	Geriausias būdas suprasti, kaip gerai pasirinkote informacijos pateikimo stilių, yra proceso naudotojams (atliktojams) parodyti rezultatą.Svarbiausia tokioje demonstracijoje suprasti, kaip teisingai supratote, kaip procesas atliekamas. Jei projekto komandos mokymai buvo sėkmingi, galite tikėtis gana adekvačių atsiliepimų iš atlikėjų. Ir jei jie susidomės, tada viskas pradės judėti daug greičiau.Nustatyti patikslinimai ir neatitikimai turi būti atspindėti aprašyme (atnaujinami), jei reikia, pakartokite operaciją.
Verslo procesų rodiklių identifikavimas	Kai gerai suprasite, kaip vykdomas verslo procesas, turite pagalvoti apie metrikas, kurios gali išmatuoti proceso kokybę ar greitį. Tai nėra lengva, bet būtina. Rodiklis turi būti išmatuojamas, t.y. išreikšta skaitiniais terminais ir turėtų būti paprastas būdas gauti šią vertę. Jei išmatuoto rodiklio nustatyti nepavyksta, kyla rizika, kad verslo procesas buvo netinkamai identifikuotas. Be to, nebus galima suprasti (nes to negalima išmatuoti), ar proceso pakeitimai lems jo tobulėjimą, ar ne.
Galutinė verslo procesų dokumentacija	Kai tik įsitikinsime, kad suprantame, kaip procesas yra (arba turėtų būti) atliekamas, galime įtraukti jį į dokumentus.
	Galimi ir kiti variantai: nagrinėjami procesai bus analizuojami ir optimizuojami, plėtojami pareigybių aprašymai, priimami sprendimai dėl būtinybės automatizuoti atskirus procesus ir pan.Tai gali būti ir atskiras projektas: verslo procesų aprašymas.

Dabar apsvarstykite, koks požiūris į studijų reikalavimus informacinė sistema su tolesniu jų atspindžiu techninėje užduotyje

Žingsniai	Ką ir kaip daryti
Verslo poreikio / automatizavimo srities išryškinimas	Praktikoje naudojamas visos automatikos srities išskyrimas kaip reikalavimai (pavyzdžiui, „Akcijos“), tačiau tai nėra labiausiai efektyvus metodas reikalavimų patikslinimas. Automatikos sritis yra reikalavimų grupė, todėl geriau juos apsvarstyti atskirai. Pavyzdžiui, „Prekių gavimo į sandėlį apskaita“
Išsamus verslo poreikio tyrimas	Išsamus verslo reikalavimo tyrimas suprantamas kaip galutinis vartotojas nori jį matyti ir panaudos (žinoma, pagal projekto tikslus). Programinės įrangos kūrimo technologijose tai dažnai vadinama „naudojimo atveju“. Taigi detalus verslo poreikio tyrimas apsiriboja naudojimo atvejų kūrimu. Tokios galimybės pavyzdys pateiktas straipsnio 2 priede. Paprasčiausiais atvejais visai nebūtina piešti naudojimo atvejų grafinių diagramų pavidalu, taip pat galite apsiriboti tekstiniu formulavimu. Pavyzdžiui, reikalavimas „Įvedant prekę kaina turi būti skaičiuojama kaip pirkimo kaina + 20%“ nėra prasmės braižyti. Diagramos forma prasminga pateikti reikalavimus sujungti iki automatizavimo apimties, kaip parodyta 2 priedo pavyzdyje.
Modeliavimo reikalavimai informacinėje sistemoje	Štai jis! Kaip tikriausiai prisimenate, aš jau atkreipiau dėmesį į šį svarbiausią techninės užduoties rengimo metodikos elementą. „Sukurk modelį – gauk rezultatą! Kas turėtų būti modeliuojama? Būtina modeliuoti ankstesniame etape gautus naudojimo atvejus. Koks turėtų būti modeliavimo rezultatas? Turėtumėte gauti demonstracinę programą, kurioje įvedami vartotojo duomenys ir, pageidautina, žinomą jo (vartotojo) klausai, atsižvelgiant į pramonės specifiką, tikrosios problemos. Ir ne šiaip įvesti, o turėtų būti aišku, iš kur šie duomenys atkeliavo, kaip buvo paskaičiuoti. Šiuo metu skaitytojui turėtų kilti klausimų: Bet ką daryti, jei planuojama sukurti naują sistemą ir tiesiog nėra ką modeliuoti? Ką daryti, jei demonstracijai nepakanka funkcionalumo, o sistemą reikia tobulinti? Žinoma, jūs turite susidurti su tokia situacija, ir tai yra normalu. Ką daryti? Jei sistema yra visiškai nauja (kaip sakoma „nuo nulio“), tuomet dažniausiai teks modeliuoti popieriuje, čia jums labai padės naudojimo atvejų diagramos. Iš dalies prasminga nubrėžti kai kurias ekrano formas, kurios turėtų būti kuriamos (tiesiog toje aplinkoje, kurioje bus vykdoma plėtra), nes. piešti juos kokiame nors redaktoriuje užtruks ilgiau ir šis darbas yra nuobodus. Jeigu diegiama jau paruošta sistema, o jai trūksta funkcionalumo, tai nėra ko jaudintis, duomenys įvedami ranka, o vartotojui pasakoma, kad atlikus reikiamus patobulinimus reikia skaičiuoti ir taip (ir anaip). jis tai mato). Prie tokio modelio patartina pridėti tekstinį aprašymą, net jei jis trumpas, kad vartotojas galėtų savarankiškai pabandyti dirbti su modeliu laisvalaikiu. Tame pačiame aprašyme galite suformuluoti reikalavimus patobulinimams.
Informacinio modelio demonstravimas darbo grupei	Gautą modelį parodome Užsakovui ir pasakome kaip viskas turi veikti.Geriau modelį demonstruoti posistemiais, t.y. pagal reikalavimų grupę. Paaiškėjus, kad pasiūlyta schema klientui netiks, reikia pagalvoti apie kitus panaudojimo atvejus, atlikti modelio pakeitimus ir parodyti dar kartą. Tik tada, kai yra įsitikinimas, kad planuojamas modelis „gyvens“ su konkrečiu klientu, modelis gali būti laikomas sėkmingu.
Testo kūrimas	Kodėl reikalingi testai? Reikės patikrinti, kaip mums pavyko įgyvendinti reikalavimus. Atitinkamai, pageidautina atlikti visų pagrindinių sričių, sudėtingų algoritmų ir kt. Įskaitant šiuos testus galima naudoti darbų pristatymo metu. Nebūtina daryti kiekvienos sistemos funkcijos testų, visur turi būti sveikas protas. Jei mes kalbame apie paruoštą sistemą, tada bandymas „įvesti naują elementą į klientų katalogą“ atrodys kvailas ir laiko bei pastangų švaistymas. Bet jei tai visiškai nauja sistema, tai visiškai įmanoma. Kam daryti testus, jei dar nėra sistemos?Pirma, kūrėjui bus aiškiau, ką iš jo nori pasiekti. Antra, palengviname testuotojo gyvenimą (juk kūrimo rezultatą kas nors patikrins). Apskritai testavimas yra atskira disciplina, kuri nėra labai paprasta naudojant daugybę metodų. Praktikoje, kaip taisyklė, vis dar naudojami paprasčiausi tyrimo metodai.
Reikalavimų dokumentavimas techninės užduoties forma	Ankstesniuose etapuose surinkta informacija bus būtent tai, kas turėtų būti įtraukta į dokumento „Teisės užduotys“ pagrindą reikalavimų skyriuje, todėl belieka visa tai teisingai sutvarkyti.
Tolesni veiksmai (arba jų nebuvimas), priklausomai nuo projekto tikslų	Kūrimo procesas, partnerių paieška projektui, konkursas ir pan., gali užtrukti ilgiau, viskas priklauso nuo situacijos.

Taip, techninės užduoties rengimas yra daug laiko reikalaujantis procesas, todėl brangus. Bet jei tai daroma teisingai, tai išgelbėja Klientą nuo neišsipildžiusių lūkesčių. Rangovas turi daryti tai, ko reikalauja Užsakovas, o ne kartoti to paties šimtą kartų. Ir apskritai tai suteikia skaidrumo visam projektui.

Priedas 1. Verslo procesas aprašytas EPC žymėjimu.