Zadání pro tvorbu automatizovaného informačního systému. Standardy a šablony pro TK pro vývoj softwaru

GOST 34.602-89 Informační technologie. Soubor standardů pro automatizované systémy.Zadání pro tvorbu automatizovaný systém(Místo GOST 24.201-85)

Datum zavedení od 01.01.1990.

Tato norma se vztahuje na automatizované systémy (AS) pro automatizaci různých druhů činností (řízení, projektování, výzkum atd.), včetně jejich kombinací, a stanovuje skladbu, obsah, pravidla pro vydávání dokumentu „Podmínky pro tvorbu ( vývojové nebo modernizační) systémy“ (dále jen TK pro JE).

1. OBECNÁ USTANOVENÍ

1.1. ToR pro JE je hlavním dokumentem, který definuje požadavky a postup pro vytvoření (vývoj nebo modernizace - další tvorba) automatizovaného systému, v souladu s nímž se uskutečňuje vývoj JE a její převzetí při uvedení do provozu.

1.2. Specifikace pro jaderné elektrárny jsou vypracovány pro systém jako celek, navržený tak, aby pracoval samostatně nebo jako součást jiného systému.

Navíc lze TOR vyvinout pro části JE:

o subsystémech JE, komplexech úkolů JE atd. v souladu s požadavky této normy;
pro příslušenství technická podpora a softwarové a hardwarové komplexy v souladu se standardy ESKD a SRPP;
pro software v souladu se standardy ESPD;
pro informační produkty v souladu s GOST 19.201 a NTD, který je platný v oddělení zákazníka JE.

Poznámka. V TOR pro automatizovaný řídicí systém pro skupinu vzájemně souvisejících objektů by měly být zahrnuty pouze požadavky společné pro skupinu objektů. Specifické požadavky na samostatný řídicí objekt by se měly odrazit v TOR pro ACS tohoto objektu.

1.3. Požadavky na AU v rozsahu stanoveném touto normou lze zahrnout do zadání pro návrh nově vytvořeného automatizačního objektu. V tomto případě nejsou vypracovány technické specifikace pro jaderné elektrárny.

1.4. Požadavky zahrnuté v TOR pro JE musí odpovídat současné úrovni rozvoje vědy a techniky a nesmí být nižší než podobné požadavky na nejlepší moderní domácí a zahraniční analogy. Požadavky specifikované v TOR pro JE by neměly omezovat vývojáře systému při hledání a implementaci nejúčinnějších technických, proveditelných a jiných řešení.

1.5. Specifikace pro JE jsou vypracovány na základě výchozích údajů, včetně těch obsažených v závěrečné dokumentaci etapy „Výzkum a zdůvodnění vzniku JE“, stanovené GOST 24.601.

1.6. TOR pro jaderné elektrárny zahrnuje pouze ty požadavky, které doplňují požadavky na systémy tohoto typu (ACS, CAD, ASNI atd.) obsažené v aktuální NTD a jsou určeny specifiky konkrétního objektu, pro který je systém určen. se vytváří.

1.7. Změny TOR na JE jsou formalizovány dodatkem nebo protokolem podepsaným zákazníkem a developerem. Dodatek nebo stanovený protokol je nedílnou součástí Za podmínky JE. Na titulní straně TK na AC by měl být záznam „Platnost od ...“.

2. SLOŽENÍ A OBSAH

2.1. ToR pro JE obsahuje následující sekce, které lze rozdělit do podsekcí:

1) obecné informace;
2) účel a cíle tvorby (vývoje) systému;
3) charakteristiky objektů automatizace;
4) systémové požadavky;
5) složení a obsah práce na vytvoření systému;
6) postup pro kontrolu a akceptaci systému;
7) požadavky na skladbu a obsah prací na přípravu objektu automatizace pro uvedení systému do provozu;
8) požadavky na dokumentaci;
9) vývojové zdroje.

Přihlášky mohou být zahrnuty do TOR pro AU.

2.2. V závislosti na typu, účelu, specifických vlastnostech objektu automatizace a provozních podmínkách systému je povoleno sestavit části TOR ve formě aplikací, zavést další, vyloučit nebo kombinovat podsekce TOR.

TOR pro části systému nezahrnuje části, které duplikují obsah sekcí TOR pro JE jako celek.

2.3. V kapitole" Obecná informace» uvést:

1) úplný název systému a jeho symbol;
2) šifra tématu nebo šifra (číslo) smlouvy;
3) název podniků (sdružení) vývojáře a zákazníka (uživatele) systému a jejich podrobnosti;
4) seznam dokumentů, na jejichž základě je systém vytvořen, kým a kdy byly tyto dokumenty schváleny;
5) plánované termíny zahájení a ukončení prací na vytvoření systému;
6) informace o zdrojích a postupu financování díla;
7) postup formalizace a prezentace výsledků práce na vytvoření systému (jeho částí), na výrobě a úpravě jednotlivých prostředků (hardware, software, informace) a softwaru a hardwaru (softwarové a metodické) zákazníkovi. komplexy systému.

2.4. Sekce "Účel a cíle tvorby (vývoje) systému" se skládá z podsekcí:

1) účel systému;
2) účel vytvoření systému.

2.4.1. V podsekci "Účel systému" uveďte typ automatizované činnosti (řízení, návrh atd.) a seznam automatizačních objektů (objektů), na kterých má být použita.

U automatizovaných řídicích systémů je navíc uveden seznam automatizovaných řídicích orgánů (bodů) a řízených objektů.

2.4.2. V podsekci "Cíle vytvoření systému" uveďte názvy a požadované hodnoty technických, technologických, výrobně-ekonomických nebo jiných ukazatelů objektu automatizace, kterých musí být dosaženo vytvořením AU, a uveďte kritéria pro hodnocení dosažení cílů tvorby systému.

2.5. V části "Charakteristiky objektu automatizace" uveďte:

1) stručné informace o objektu automatizace nebo odkazy na dokumenty obsahující takové informace;
2) informace o provozních podmínkách objektu automatizace a vlastnostech prostředí.

Poznámka: Pro CAD tato sekce navíc poskytuje hlavní parametry a charakteristiky konstrukčních objektů.

2.6. Část Systémové požadavky se skládá z následujících podsekcí:

1) požadavky na systém jako celek;
2) požadavky na funkce (úkoly) prováděné systémem;
3) požadavky na typy zajištění.

Složení požadavků na systém zahrnutý v této části zadání pro JE je stanoveno v závislosti na typu, účelu, specifických vlastnostech a provozních podmínkách konkrétního systému. Každá podsekce obsahuje odkazy na aktuální NTD, které definují požadavky na systémy odpovídajícího typu.

2.6.1. V podsekci „Požadavky na systém jako celek“ uveďte:

požadavky na strukturu a fungování systému;
požadavky na počet a kvalifikaci personálu systému a způsob jeho práce;
ukazatele destinace;
požadavky na spolehlivost;
bezpečnostní požadavky;
požadavky na ergonomii a technickou estetiku;
požadavky na přepravitelnost pro mobilní AS;
požadavky na provoz, údržbu, opravy a skladování součástí systému;
požadavky na ochranu informací před neoprávněným přístupem;
požadavky na bezpečnost informací v případě nehod;
požadavky na ochranu před vlivem vnějších vlivů;
požadavky na čistotu patentu;
požadavky na standardizaci a unifikaci;
Další požadavky.

2.6.1.1. Požadavky na strukturu a fungování systému zahrnují:

1) seznam subsystémů, jejich účel a hlavní charakteristiky, požadavky na počet úrovní hierarchie a stupeň centralizace systému;
2) požadavky na způsoby a prostředky komunikace pro výměnu informací mezi složkami systému;
3) požadavky na charakteristiku propojení vytvářeného systému s navazujícími systémy, požadavky na jeho kompatibilitu, včetně návodu na výměnu informací (automaticky, zasíláním dokumentů, telefonicky apod.);
4) požadavky na provozní režimy systému;
5) požadavky na diagnostiku systému;
6) perspektivy rozvoje, modernizace systému.

2.6.1.2. Požadavky na počet a kvalifikaci personálu v JE zahrnují:

požadavky na počet pracovníků (uživatelů) JE;
požadavky na kvalifikaci personálu, postup při jeho školení a kontrolu znalostí a dovedností;
požadovaný způsob práce personálu JE.

2.6.1.3. V požadavcích na ukazatele účelu AS jsou uvedeny hodnoty parametrů charakterizující míru shody systému s jeho účelem.

Pro ACS uveďte:

míra adaptability systému na změny procesů a metod řízení, na odchylky v parametrech řídicího objektu;
přípustné limity modernizace a rozvoje systému;
pravděpodobnostně-časové charakteristiky, pod kterými je zachován zamýšlený účel systému.

2.6.1.4. Mezi požadavky na spolehlivost patří:

1) složení a kvantitativní hodnoty ukazatelů spolehlivosti pro systém jako celek nebo jeho subsystémy;
2) seznam nouzových situací, pro které by měly být požadavky na spolehlivost regulovány, a hodnoty odpovídajících ukazatelů;
3) požadavky na spolehlivost technické prostředky a software;
4) požadavky na metody hodnocení a sledování ukazatelů spolehlivosti pro různé fáze vytvoření systému v souladu s aktuálními regulačními a technickými dokumenty.

2.6.1.5. Bezpečnostní požadavky zahrnují požadavky na zajištění bezpečnosti při instalaci, uvádění do provozu, provozu, údržbě a opravách technických prostředků systému (ochrana proti elektrický proud, elektromagnetická pole, akustický hluk atd.), přípustnými úrovněmi osvětlení, vibrací a hlukového zatížení.

2.6.1.6. Mezi požadavky na ergonomii a technickou estetiku patří indikátory AS, které specifikují požadovanou kvalitu interakce člověk-stroj a komfort pracovních podmínek personálu.

2.6.1.7. U mobilních jaderných elektráren požadavky na přepravitelnost zahrnují konstrukční požadavky, které zajišťují přepravitelnost technických prostředků systému, a také požadavky na vozidla.

2.6.1.8. Požadavky na provoz, údržbu, opravy a skladování zahrnují:

1) podmínky a předpisy (režim) provozu, které by měly zajistit používání technických prostředků (TS) soustavy se stanovenými technickými ukazateli, včetně druhů a četnosti údržby TS soustavy nebo přípustnosti provozu bez údržby ;
2) předběžné požadavky na přípustné plochy pro umístění personálu a TS soustavy, na parametry napájecích sítí atd.;
3) požadavky na počet, kvalifikaci personálu údržby a způsoby jeho práce;
4) požadavky na složení, umístění a podmínky skladování sady náhradních výrobků a zařízení;
5) požadavky na plán údržby.

2.6.1.9. Požadavky na ochranu informací před neoprávněným přístupem zahrnují požadavky stanovené v NTD působící v odvětví (oddělení) zákazníka.

2.6.1.10. V požadavcích na bezpečnost informací je uveden výčet událostí: havárie, poruchy technických prostředků (včetně výpadku napájení) apod., při kterých musí být zajištěna bezpečnost informací v systému.

2.6.1.11. V požadavcích na prostředky ochrany před vnějšími vlivy jsou uvedeny:

1) požadavky na radioelektronickou ochranu zařízení JE;
2) požadavky na odolnost, stabilitu a pevnost vůči vnějším vlivům (prostředí užívání).

2.6.1.12. Požadavky na patentovou čistotu udávají seznam zemí, u kterých musí být patentová čistota systému a jeho částí zajištěna.

2.6.1.13. Mezi požadavky na standardizaci a unifikaci patří: indikátory, které stanovují požadovanou míru využití standardu, jednotné metody realizace funkcí (úkolů) dodávaného systému softwarové nástroje, typické matematické metody a modely, standardní konstrukční řešení, jednotné formy řídících dokumentů stanovené GOST 6.10.1, celounijní klasifikátory technických a ekonomických informací a klasifikátory jiných kategorií v souladu s jejich rozsahem, požadavky na používání typických automatizovaných pracovních stanic, komponent a komplexy.

2.6.1.14. Mezi další požadavky patří:

1) požadavky na vybavení systému zařízeními pro školení personálu (simulátory, jiná zařízení podobného účelu) a dokumentací k nim;
2) požadavky na servisní vybavení, stojany na kontrolu prvků systému;
3) systémové požadavky spojené se zvláštními provozními podmínkami;
4) speciální požadavky dle uvážení vývojáře nebo zákazníka systému.

2.6.2. V podsekci "Požadavky na funkce (úkoly)" prováděné systémem je uvedeno:

1) pro každý subsystém seznam funkcí, úkolů nebo jejich komplexů (včetně těch, které zajišťují interakci částí systému), které mají být automatizovány;

při vytváření systému ve dvou a více frontách - seznam funkčních subsystémů, jednotlivých funkcí nebo úkolů realizovaných v 1. a dalších frontách;

2) časový harmonogram realizace každé funkce, úkolu (nebo souboru úkolů);

3) požadavky na kvalitu provedení každé funkce (úkolu nebo souboru úkolů), na formu prezentace výstupní informace, charakteristiku požadované přesnosti a doby provedení, požadavky na simultánnost provádění skupiny funkce, spolehlivost výsledků;

4) seznam a kritéria selhání pro každou funkci, pro kterou jsou specifikovány požadavky na spolehlivost.

2.6.3. V podkapitole „Požadavky na druhy podpory“ jsou v závislosti na typu systému uvedeny požadavky na matematické, informační, jazykové, softwarové, technické, metrologické, organizační, metodické a další typy podpory systému.

2.6.3.1. Pro matematickou podporu systému jsou uvedeny požadavky na složení, rozsah (omezení) a metody, použití matematických metod a modelů v systému, typické algoritmy a algoritmy, které mají být vyvíjeny.

2.6.3.2. Pro informační podporu systému jsou dány následující požadavky:

1) ke složení, struktuře a metodám organizace dat v systému;
2) k výměně informací mezi komponentami systému;
3) na kompatibilitu informací se sousedními systémy;
4) o používání celounijních a registrovaných republikových, oborových klasifikátorů, jednotných dokumentů a klasifikátorů působících v daném podniku;
5) o používání systémů správy databází;
6) ke struktuře procesu shromažďování, zpracování, přenosu dat v systému a prezentace dat;
7) chránit data před zničením v případě nehod a výpadků napájení systému;
8) kontrola, ukládání, aktualizace a obnova dat;
9) k postupu při poskytování právní účinek dokumenty vyrobené technickými prostředky AU (v souladu s GOST 6.10.4).

2.6.3.3. Pro jazykovou podporu systému jsou uvedeny požadavky na použití programovacích jazyků v systému. vysoká úroveň, jazyky interakce mezi uživateli a technickými prostředky systému, jakož i požadavky na kódování a dekódování dat, jazyky pro vstup/výstup dat, jazyky pro manipulaci s daty, popisné nástroje předmětová oblast(předmět automatizace), ke způsobům organizace dialogu.

2.6.3.4. U systémového softwaru je uveden seznam zakoupeného softwaru a požadavky:

1) k nezávislosti softwaru na použitém CVT a provozním prostředí;
2) na kvalitu softwaru, jakož i na způsoby jeho poskytování a kontroly;
3) pokud je nutné sladit nově vyvinutý software s fondem algoritmů a programů.

2.6.3.5. Pro technickou podporu systému jsou dány následující požadavky:

1) na druhy technických prostředků, včetně typů komplexů technických prostředků, softwarových a hardwarových komplexů a dalších komponent, které jsou přijatelné pro použití v systému;
2) na funkční, konstrukční a provozní vlastnosti technické podpory systému.

2.6.3.6. Požadavky na metrologickou podporu zahrnují:

1) předběžný seznam měřicích kanálů;
2) požadavky na přesnost měření parametrů a (nebo) na metrologické charakteristiky měřicích kanálů;
3) požadavky na metrologickou kompatibilitu technických prostředků systému;
4) seznam řídicích a výpočetních kanálů systému, u kterých je nutné vyhodnotit charakteristiky přesnosti;
5) požadavky na metrologickou podporu hardwaru a softwaru, které jsou součástí měřicích kanálů systému, nástrojů, vestavěného řízení, metrologické vhodnosti měřicích kanálů a měřicích přístrojů používaných při seřizování a testování systému;
6) typ metrologické certifikace (státní nebo resortní) s uvedením postupu jejího provádění a organizací provádějících certifikaci.

2.6.3.7. Pro organizační podporu jsou dány následující požadavky:

1) ke struktuře a funkcím jednotek zapojených do provozu systému nebo zajištění provozu;

2) k organizaci fungování systému a postupu interakce mezi personálem JE a personálem objektu automatizace;

3) k ochraně před chybným jednáním personálu systému.

2.6.3.8. Pro metodickou podporu CAD, požadavky na složení předpisu technická dokumentace systému (seznam norem, předpisů, metod atd. používaných při jeho provozu).

2.7. Sekce „Složení a obsah práce na vytvoření (vývoji) systému“ by měla obsahovat seznam fází a fází prací na vytvoření systému v souladu s GOST 24.601, načasování jejich implementace, seznam organizací provádění díla, odkazy na dokumenty potvrzující souhlas těchto organizací s účastí na vytváření systému, případně záznam identifikující osobu odpovědnou (zákazníka nebo vývojáře) za provedení těchto prací.

Tato sekce také poskytuje:

1) seznam dokumentů v souladu s GOST 34.201-89 předložených na konci příslušných etap a etap práce;
2) druh a postup provádění kontroly technické dokumentace (etapa, fáze, rozsah kontrolované dokumentace, organizace-odborník);
3) pracovní program zaměřený na zajištění požadované úrovně spolehlivosti vyvíjeného systému (je-li to nutné);
4) seznam prací na metrologické podpoře ve všech fázích tvorby systému s uvedením jejich termínů a provádějících organizací (v případě potřeby).

2.8. V části „Postup monitorování a akceptace systému“ uveďte:

1) druhy, složení, rozsah a metody zkoušení systému a jeho součástí (druhy zkoušek podle aktuálních norem platných pro vyvíjený systém);
2) obecné požadavky na přejímku díla po etapách (seznam zúčastněných podniků a organizací, místo a načasování), postup schvalování a schvalování přejímací dokumentace;
H) stav přejímací komise (státní, meziresortní, resortní).

2.9. V části „Požadavky na skladbu a obsah prací na přípravu objektu automatizace pro uvedení systému do provozu“ je nutné uvést výčet hlavních činností a jejich vykonavatelů, které by měly být provedeny při přípravě objektu automatizace pro uvedení systému do provozu. AU do provozu.

Seznam hlavních činností zahrnuje:

1) uvedení informace vstupující do systému (v souladu s požadavky na informační a jazykovou podporu) do podoby vhodné pro zpracování pomocí počítače;
2) změny, které je třeba provést v objektu automatizace;
3) vytvoření podmínek pro fungování objektu automatizace, za kterých je zaručena shoda vytvořeného systému s požadavky obsaženými v TOR;
4) vytvoření pododdělení a služeb nezbytných pro fungování systému;
5) podmínky a postup pro personální obsazení a školení personálu.

Například pro ACS dávají:

změny v používaných metodách řízení;
vytvoření podmínek pro provoz komponent ACS, za kterých je zaručena shoda systému s požadavky obsaženými v TOR.

2.10. V části „Požadavky na dokumentaci“ je uvedeno následující:

1) seznam sad a typů dokumentů, které mají být vyvinuty a které splňují požadavky GOST 34.201-89 a NTD odvětví zákazníka, dohodnuté vývojářem a zákazníkem systému;
seznam dokumentů vydaných na strojových médiích;
požadavky na dokumentaci mikrofilmování;
2) požadavky na dokumentaci komponentních prvků meziodvětvové aplikace v souladu s požadavky ESKD a ESPD;
3) při absenci státních norem, které definují požadavky na dokumentaci prvků systému, obsahují navíc požadavky na skladbu a obsah takových dokumentů.

2.11. Sekce Vývojové zdroje by měla obsahovat dokumenty a informační materiály(studie proveditelnosti, zprávy o ukončených výzkumných pracích, informační materiály o domácích, zahraničních analogových systémech atd.), na jejichž základě byl TOR vypracován a které by měly být použity při tvorbě systému.

2.12. Složení TOR na JE, za přítomnosti schválených metod, zahrnuje aplikace obsahující:

1) výpočet očekávané účinnosti systému;
2) posouzení vědecké a technické úrovně systému.

Aplikace jsou zahrnuty v TOR pro JE podle dohody mezi vývojářem a zákazníkem systému.

3. NÁVRHOVÁ PRAVIDLA

3.1. Úseky a podsekce TOR na JE musí být umístěny způsobem předepsaným v odst. 1 písm. 2 této normy.

3.2. TK pro AU je vypracován v souladu s požadavky GOST 2.105.95 na listech formátu A4 v souladu s GOST 2.301 bez rámu, hlavního nápisu a dalších sloupců.

Čísla listů (stránek) se zapisují, počínaje prvním listem po titulní straně, v horní části listu (nad textem, uprostřed) po označení kódu TK na AC.

3.3. Hodnoty ukazatelů, norem a požadavků jsou zpravidla uváděny s maximálními odchylkami nebo maximálními a minimálními hodnotami. Pokud jsou tyto ukazatele, normy, požadavky jednoznačně regulovány NTD, měl by TOR pro JE poskytovat odkaz na tyto dokumenty nebo jejich části, jakož i další požadavky, které zohledňují vlastnosti vytvářeného systému. Pokud konkrétní hodnoty indikátorů, norem a požadavků nelze stanovit v procesu tvorby TOR pro JE, měl by zaznamenat postup pro stanovení a odsouhlasení těchto indikátorů, norem a požadavků:

„Konečný požadavek (hodnota) je specifikován v procesu ... a odsouhlasen protokolem s ... ve fázi ...“.

Současně nejsou prováděny žádné změny textu TOR pro JE.

3.4. Na titulní straně jsou umístěny podpisy objednatele, developera a koordinující organizace, které jsou zapečetěny razítkem. V případě potřeby je titulní strana vypracována na více stránek. Podpisy zpracovatelů zadání pro JE a úředníků podílejících se na schvalování a kontrole návrhu zadání pro JE jsou umístěny na poslední straně.

Podoba titulní strany TK pro AU je uvedena v příloze 2. Podoba posledního listu TK pro AU je uvedena v příloze 3.

3.5. V případě potřeby je na titulní straně CK na AU povoleno umístit kódy zavedené v oboru, např.: bezpečnostní razítko, pracovní kód, evidenční číslo CK apod.

3.6. Stejným způsobem je vypracována i titulní strana Dodatku TOR pro JE titulní strana technický úkol. Místo názvu „Terms of Reference“ píší „Dodatek č. ... k TOR pro AC ...“.

3.7. Na následujících listech Dodatku k TOR na AU je umístěn podklad pro změnu, obsah změny a odkazy na dokumenty, podle kterých jsou tyto změny provedeny.

3.8. Při uvádění textu dodatku k TV by měla být uvedena čísla příslušných odstavců, pododstavců, tabulek hlavního TVD na AU atd. a slova „nahradit“, „dodat“, „smazat“, „ uvést v novém vydání“.

POSTUP PRO VYPRACOVÁNÍ, DOHODU A SCHVÁLENÍ TOR PRO JE

1. Návrh TOR pro JE vypracovává vývojář systému za účasti zákazníka na základě technických požadavků (aplikace, specifikace výkonu atd.).

V konkurenční organizaci práce varianty návrhu TOR pro JE zvažuje zákazník, který buď zvolí preferovanou variantu, nebo na základě srovnávací analýzy připraví finální verzi TOR pro JE s účast budoucího developera JE.

2. Potřebu schválení návrhu zadání pro JE s orgány státního dozoru a dalšími zainteresovanými organizacemi stanoví společně objednatel systému a zpracovatel návrhu zadání na JE,

Práce na schvalování návrhu TOR pro AC provádí společně zpracovatel TOR pro JE a objednatel systému, každý v organizacích svého ministerstva (odboru).

3. Lhůta pro schválení návrhu TOR pro JE v každé organizaci by neměla přesáhnout 15 dnů od data jeho obdržení. Doporučuje se zaslat kopie návrhu ToR pro jaderné elektrárny (kopie) současně všem organizacím (divizím) ke schválení.

4. Připomínky k návrhu TOR pro JE musí být předloženy s technickým zdůvodněním. O připomínkách musí rozhodnout zpracovatel návrhu zadání pro JE a zákazník systému před schválením zadání pro JE.

5. Pokud při odsouhlasení návrhu TOR na JE došlo k neshodám mezi developerem a objednatelem (případně jinými zainteresovanými organizacemi), je sepsán protokol o neshodách (libovolná forma) a je stanoveno konkrétní rozhodnutí předepsaným způsobem.

6. Schválení návrhu TOR na JE je možné vypracovat jako samostatný dokument (dopis). V tomto případě pod nadpisem „Souhlasím“ vytvořte odkaz na tento dokument.

7. Schvalování technických specifikací pro jaderné elektrárny provádějí vedoucí podniků (organizací) developera a zákazníka systému.

8. Specifikace pro JE (dodatek ke specifikaci) před předložením ke schválení musí být zkontrolována normativní kontrolní službou organizace, která specifikaci vypracovala, a v případě potřeby podrobena metrologickému přezkoušení.

9. Kopie schválených zadání pro JE do 10 dnů po schválení zasílá zpracovatel zadání pro JE účastníkům tvorby systému.

10. Koordinace a schvalování dodatků k ZP pro JE probíhá způsobem stanoveným pro ZP pro JE.

11. Změny TOR na JE nelze schvalovat poté, co je systém nebo jeho řada předložena k přejímacím testům.

12. Registrace, účtování a ukládání technických specifikací v JE a jejich doplňování se provádí v souladu s požadavky GOST 2.501.

FORMA TITULOVÉHO LISTU TK NA AC

________________________________________________________

název
organizace - zpracovatel technických specifikací pro jaderné elektrárny

SCHVALOVAT

Dozorce
(funkce, název podniku - zákazník JE)

Osobní podpis
Celé jméno

Těsnění

datum

SCHVALOVAT

Dozorce
(pozice, název podniku - vývojář” AS)

Osobní podpis
Celé jméno

Těsnění

datum

________________________________________________________

název typu AC

________________________________________________________

Název objektu
automatizace

________________________________________________________

zkrácený
AC jméno

TECHNICKÝ ÚKOL

Na ____ listech

Aktivní
S

SOUHLASENO

Dozorce
(pozice, název koordinující organizace)

Osobní podpis
Celé jméno

Těsnění

datum

FORMA POSLEDNÍHO LISTU TK NA AC

(TK kód)

HOTOVO SOUHLASENO

PŘÍLOHA 4
Odkaz

USTANOVENÍ PRO VYTVOŘENÍ JEDNOTNÉHO KOMPLEXU NORMY PRO AUTOMATIZOVANÉ SYSTÉMY

1. Prvotní předpoklady pro vznik areálu

1.1. Vytváření a implementace automatizovaných systémů různých tříd a účelů se provádí v mnoha průmyslových odvětvích podle regulační a technické dokumentace, která stanoví řadu organizačních, metodických a technických norem, pravidel a předpisů, které brání integraci systémů a jejich efektivnímu společnému fungování. .

1.2. V období, kdy se Gosstandart SSSR rozhodl zlepšit meziodvětvové komplexy norem, byly v platnosti následující komplexy a systémy norem stanovující požadavky na různé typy AC:

1) jednotný systém norem pro automatizované řídicí systémy (24. systém), který se vztahuje na automatizované řídicí systémy, automatizované řídicí systémy, automatizované systémy řízení procesů a další organizační a ekonomické systémy;
2) soubor norem (systém 23501); rozšíření na počítačem podporované konstrukční systémy;
3) čtvrtá skupina 14. soustavy norem, zahrnující automatizované systémy technologické přípravy výroby.

1.3. Praxe aplikace norem pro automatizované systémy řízení, CAD, systémy automatizovaného řízení procesů, ASTPP ukázala, že používají stejný pojmový aparát, existuje mnoho společných objektů standardizace, nicméně požadavky norem nejsou vzájemně koordinovány, existují rozdíly ve skladbě a obsahu práce, rozdíly v označení, skladbě, obsahu a formátování dokumentů atd.

1.4. Na pozadí absence jednotné technické politiky v oblasti tvorby AS neposkytovala různorodost standardů širokou kompatibilitu AS při jejich interakci, neumožňovala replikaci systémů a bránila rozvoji perspektivních oblastí pro využití výpočetní techniky.

1.5. V současné době probíhá přechod na tvorbu komplexních AS (zahraničních CAD systémů - CAM), které zahrnují automatizované řídicí systémy technologických postupů a průmysl, CAD - konstruktér, CAD - technolog, ASNI a další systémy. Použití protichůdných pravidel při vytváření takových systémů vede ke snížení kvality, zdražení práce a zpoždění uvedení JE do provozu.

1.6. Na automatizované systémy by se měl vztahovat jeden soubor norem a pokynů pro různé účely: ASNI, CAD, OASU, APCS, APCS, APCS, ASK, ASTPP včetně jejich integrace.

1.7. Při vývoji meziodvětvových dokumentů je třeba vzít v úvahu následující rysy AU jako objektů standardizace:

1) technický úkol je hlavním dokumentem, podle kterého se AS vytváří a přijímá zákazník;
2) JE jsou zpravidla projektovány s uceleným souborem výrobků sériové i kusové výroby a provádějícími stavební, instalační, spouštěcí a spouštěcí práce potřebné pro uvedení JE do provozu;
3) v obecném případě se AS (subsystém AS) skládá ze softwaru a hardwaru (STC), softwarových a metodických celků (PMC) a komponent technické, softwarové a informační podpory.
Komponenty těchto typů podpěr, stejně jako PMK a PTK, musí být vyráběny a dodávány jako výrobky pro průmyslové účely.
Komponenty mohou být zahrnuty do AS jako nezávislé části nebo mohou být kombinovány do komplexů;
4) vytvoření AS v organizacích (podnikech) vyžaduje speciální školení uživatelů a personálu údržby systému;
5) Fungování AS a komplexů je zajištěno souborem organizačních a metodických dokumentů považovaných v procesu tvorby za součásti právní, metodické, jazykové, matematické, organizační a další druhy podpory. Samostatná řešení získaná v procesu vývoje tohoto softwaru mohou být implementována jako součásti technického, softwarového nebo informačního softwaru;
6) společné fungování a interakce různé systémy a komplexy se provádí na zákl lokální sítě POČÍTAČ.

Specifikace a dohody přijaté pro místní počítačové sítě jsou povinné pro zajištění kompatibility systémů, komplexů a komponent.

2. Vzájemný vztah CEN AU s jinými systémy a soubory norem

2.1. Standardizace v oblasti AS je nedílná součást pracuje na zobecněném problému "Informační technologie".

2.2. Jednotný soubor norem upravujících dokumenty pro automatizované systémy by měl spolu s dalšími systémy a soubory norem tvořit kompletní regulační a technickou podporu pro procesy tvorby a fungování AS.

2.3. EKS AS by měl pokrývat oblasti standardizace specifické pro automatizované systémy a rozšířit tradiční oblasti standardizace na software a hardware, softwarové a metodické komplexy a automatizované systémy obecně.

2.4. Směry a úkoly standardizace v normativní a technické podpoře procesů tvorby a provozu AS jsou seskupeny následovně:

1) stanovení technických požadavků na výrobky;
2) regulace zkušebních metod a pravidel pro atestaci a certifikaci výrobků;
3) úprava pravidel a postupu pro rozvoj;
4) stanovení pravidel dokumentace;
5) zajištění kompatibility;
6) regulace organizačních a metodických otázek fungování systémů.

Směry 1-4 jsou tradiční ve vývoji, výrobě a dodávkách produktů. Směry 5, 6 jsou specifické a vyplývají z vlastností, které jsou vlastní AS.

2.5. Odlišné je zajištění jaderných elektráren jako celku a jejich součástí regulační a technickou dokumentací v rámci přijatých oblastí a úkolů normalizace.

Komponenty technické, softwarové a informační podpory se jako produkty pro průmyslové účely považují za designové, softwarové a informační produkty. Tyto výrobky podléhají stávajícím souborům norem ESKD, SRPP, ESPD, SGIP, USD, klasifikátorům a kodifikátorům technických a ekonomických informací, souborům norem typu „OTT“, „Testovací metody“, „TU“, jakož i jako OTT zákazníka.

2.5.1. Celý životní cyklus Design Products je plně vybaven regulační a technickou dokumentací platnou ve strojírenství a výrobě přístrojů.

2.5.2. Softwarové produkty jsou dodávány s NTD, které je součástí ESPD a OTT zákazníka. Rozsah těchto NTD by však měl být rozšířen tak, aby odrážel otázky související s vývojem, tvorbou, distribucí a provozem softwarových produktů.

2.5.3. Informační produkty nejsou v současné době poskytovány s NTD, i když v rámci DDD byly vypracovány určité problémy, klasifikátory a kodifikátory technických a ekonomických informací.

2.6. Software a hardware a softwarové a metodické komplexy jsou považovány za komplexní produkty, které nemají ve strojírenství obdoby. S přihlédnutím k postavení PTK a PMK jako výrobků pro průmyslové účely by pravidla a postup jejich vývoje měly být podobné požadavkům stanoveným normami systému pro vývoj a výrobu výrobků (SRPP).

TECHNICKÝ ÚKOL

na vývoj informačního systému

1. Obecné informace

4. Systémové požadavky

6. Postup pro kontrolu a přejímku systému

1. Obecné informace

Vývojář v souladu se smlouvou č. MP23 mezi TechnoPlus LLC (dále Vývojář) a OptoTrading LLC (dále Zákazník) navrhuje databázi, vyvíjí a uvádí do provozu informační systém „Účetnictví obchodní operace»

Dnem zahájení návrhu BDB je den následující po podpisu tohoto zadání

Pokud během procesu vývoje zákazník změní požadavky popsané v tomto dokumentu, jsou tyto vypracovány jako samostatný dokument a mají za následek změnu nebo doplnění smlouvy mezi zákazníkem a vývojářem databáze ve smyslu termínu implementace a platby. dohody

Zákazník hradí práci Developera DB v souladu se smlouvou N XXX

2. Účel a cíle tvorby (vývoje) systému

IS "Účtování obchodních operací" je určen k ukládání, zpracování a analýze informací souvisejících s hlavními činnostmi Zákazníka.

Účelem vytvoření IS "Účtování obchodních operací" je:

Ukládání informací o dokončených obchodních operacích;

Promítnutí obchodních operací do účetnictví;

Analýza finančních výsledků obchodních operací;

Analýza obchodní aktivity v kontextu nomenklatury a protistran.

3. Charakteristika objektů automatizace

3.1. Hlavní činností Zákazníka je prodej nábytku a souvisejících produktů bankovním převodem.

3.2. Zákazník není plátcem DPH

3.3. Zákazník během dne neprovede více než 100 obchodních operací pro nákup a prodej zboží.

3.4. Celkový sortiment zboží nepřesahuje 3000 kusů

3.5. Celkový počet dodavatelů - dodavatelů není větší než 100 jednotek.

3.6. Počet protistran – kupujících – není omezen. V době podpisu smlouvy N XXX bylo 300 jednotek.

3.7. Zákazník odepisuje zboží ze skladu metodou váženého průměru nákladů.

3.9. Jako nákladové účty se používají pouze účty třídy 9.

3.10. Finanční výsledky obchodní činnosti podniku (peněžní tok a peněžní tok z operací) se vypočítávají na základě maloobchodních výnosů 702 a 902.

3.11. Obchodní transakce jsou zaznamenány v primárních dokumentech Došlá faktura, Odchozí faktura, Bankovní výpis.

Příbutkov nákladní list (PN) zkontrolujte skutečnost, že je zboží dodáno do skladu pіdpriєmstva a zamlžte tyto informace:

- číslo;

- datum;

– jméno protistrany (firma - post-zaměstnanec);

– jméno výrobku;

- Množství;

– cіnu jediný produkt;

- součet.

Vidatkov nákladní list (VN) vіdobrazhuє skutečnost vіdvantazhennya zboží zі sklad pіdpriієmstva nákup a mіstit іnformacіyu, jdu na informace v PN (pouze zástupce společnosti-poštovní pracovník objednat společnost-nákup).

Řádek bankovního účtu potvrzující skutečnost, že je třeba / vibuttya koshtіv іz rozrahunkovy rahunka (r / r) přijmout a pomstít následující informace:

- datum;

– znamení příchodu / vitrati koshtiv;

– jméno protistrany (koho jste dostali / komu byly peníze vyplaceny).

3.12. Primární dokument kůže є pіdstavoy pro zdіysnennya pevnih příspěvky, yakі zdіysnyuyut zmіni snіh účetnictví rakhunkіv. Provozy živnostenského podniku vyžadují takové zaúčtování (tabulka 3.1)

Tabulka 3.1 - Účtování používané v účetnictví v podniku zákazníka

Úkon	Dokument	Debet z účtu	Úvěr na účet	Částka zaúčtování
Odesílání	Doklad o nákupu			částka dokladu
Odeslání zboží	Prodejní faktura			částka dokladu
				náklady na odeslané zboží
Příjem peněz na běžný účet	Bankovní výpis (účtenka)			částka dokladu
Převod peněz z běžného účtu	Bankovní výpis (výdaje)			částka dokladu
Definice finančních výsledků				na částku uzávěrky 902 účtů
				na částku uzávěrky 702 účtů

de 281 - zboží skladem;

311 - rozrahunkovy rahunok v měně země;

361 - rozrahunki s nákupy vіtchiznyanimi;

631 - rozrakhunki s votchiznyani post-zaměstnanci;

702 - příjmy z prodeje zboží;

902 - sbírka prodaného zboží (vitrati).

3.13. Z hlediska účetnictví vypadá zvіtnostі vykoristovuєtsya obrat-bilance syntetického vzhledu jako v tabulce 3.2.

Tabulka 3.2 - Bilanční hodnota obratu syntetického vzhledu

Číslo pozice	Cobova rovnováha	Vlkodlak	Kіntseve rovnováha







Spolu

4. Systémové požadavky

IS "Účtování obchodních operací" musí splňovat následující požadavky:

4.1. Databáze pro IS "Účtování obchodních operací" by měla zajišťovat ukládání, zobrazování a editaci referencí a provozní informace.

Referenční informace:

o popis zboží:

Nomenklaturní (produktové) číslo;

Jméno výrobku;

Popis;

o dodavatelé - dodavatelé;

číslo protistrany;

jméno protistrany;

adresa protistrany;

Kontakty;

o protistrany – kupující;

číslo protistrany;

jméno protistrany;

adresa protistrany;

Kontakty;

o účtová osnova, na které se účtuje za obchodní operace a analyzuje finanční výsledky;

o seznam základních účtování pro zobrazení obchodních operací v účetnictví, způsobených prvotními doklady, které mají podobu jako v tabulce 3.1;

Operativní informace:

o Primární doklady: Faktura, Odchozí faktura, Bankovní výpis (popis dokladů je uveden v 3.11)

o Účetní zápisy způsobené prvotními doklady (typ zápisů je uveden v tabulce 3.2)

o Informace o zboží skladem:

Číslo položky;

Množství;

Součet;

Průměrná cena.

4.2. IS "Účetnictví pro obchodní operace" by vám měl umožnit automatizovat následující akce:

4.2.1 Odrážet skutečnosti zaúčtování (příjem) a expedici zboží na sklad, konkrétně přepočítat množství zboží na skladě a jeho průměrné náklady.

4.2.2 Generování účetních zápisů podle prvotních dokladů v automatickém režimu.

4.2.3 Vyhledejte následující informace:

Primární dokumenty určeného typu za určité období;

Účtování pro zadaný typ dokladů ke konkrétnímu datu;

Informace o protistraně

Informace o produktu

4.2.4 Proveďte analýzu obchodní aktivity za uvedené období v následujících částech:

Finanční výsledky obchodních aktivit;

Výsledky vypořádání pro každou protistranu;

Zbytky zboží na skladě u každé položky;

náklady na transakce pro každou protistranu;

Náklady a množství prodeje pro každý druh zboží

4.2.5 Generování zpráv za zadané období:

Zařízení, na kterém je IC instalováno, musí být vybaveno nepřerušitelným zdrojem napájení. V případě výpadku napájení by se měl IC automaticky vypnout bez ztráty dat.

IS musí zajišťovat záložní mechanismy, IS musí být vybaven odpovídajícím hardwarem a softwarem:

Kvantitativní hodnoty ukazatelů spolehlivosti:

- doba automatického vypnutí by neměla být delší než 1 minuta;

- doba zotavení po selhání by neměla být delší než 30 minut;

- index odolnost proti chybám IS by měl být 11/7, tedy nepřetržitý provoz IS 11 hodin denně, 7 dní v týdnu.

Údržba IS by měla být prováděna bez přerušení jeho provozu.

4.5 Požadavky na metody hodnocení a sledování ukazatelů spolehlivosti ve fázi zkušebního provozu

Pro kontrolu ukazatelů spolehlivosti ve fázích zkušebního provozu IS musí personál údržby vést Záznam poruch, který musí obsahovat následující informační znaky:

Datum, kdy k chybě došlo;

Celková doba provozu objektu od začátku jeho provozu do zjištění chyby;

Vnější znaky a povaha chyby;

Typ práce, ve které byla chyba zjištěna.

4.6 Požadavky na výkon IC

Systém musí podporovat schopnost zpracovat až 1000 dokumentů denně

Systém musí mít následující výkon:

80 % operací by mělo mít dobu odezvy (dobu provozu) kratší než 1 sekundu;

15% operací - od 5sec. až 10 sekund;

5% operací - více než 10 sekund, ale ne více než 30 minut.

4.7 Požadavky na objem (škálovatelnost)

Systém musí podporovat přístup k datům po dobu 10 let.

Předpokládaný nárůst objemu databáze za jeden den provozu je 20Mb.

4.8 Požadavky na počet, funkce a kvalifikaci personálu IS a způsob jejich provozu

Práce s IS budou provádět následující pracovníci Zákazníka:

Správce:

Množství: 1;

Kvalifikace: správce sítě, administrátor databáze ;

Funkce: správa zabezpečení systému, záloha data na začátku každého pracovního dne, archivace dat 1x ročně;

Pracovní doba: 1 hodina denně, 5 dní v týdnu

Operátor (uživatel), který zafixuje skutečnost obchodní operace a analyzuje výsledky obchodních aktivit:

Množství: 2;

Kvalifikace: účetní, uživatel PC;

Funkce: zadávání primárních dokladů, udržování aktuálního stavu informací o skladu, tvorba účetních zápisů, analýza výsledků obchodní činnosti, zálohování dat na začátku pracovního dne, připadající na sobotu a neděli.

Provozní režim: ve směnách pro zajištění provozu systému 11 hodin denně, 7 dní v týdnu;

Přístup k práci: 8hodinový školicí kurz;

Pracovníci musí před uvedením IS do provozu absolvovat 8hodinové školení, aby získali pracovní povolení. Po absolvování kurzu se provádí test, při kterém se hodnotí správnost a rychlost řešení praktických problémů a také znalost pracovních a technických pokynů.

Systém by měl umožnit přístup ke svým funkcím pouze registrovaným uživatelům IS zadáním hesla.

4.10 Požadavky na software a složení, struktura a způsoby organizace IS DB

Data v systému musí být uložena v relační DBMS MS SQL Server 2000.

- T-SQL (dialekt jazyka SQL);

S # .

Software se skládá z obecného systémového softwaru zakoupeného na náklady Zákazníka (zakoupený software) a speciálního softwaru vyvinutého v rámci prací na tvorbě IS.

Jako celosystémový software musí být použit následující software:

Operační systém;

Systém správy databází MS SQL Server 2000;

Zálohovací software;

4.11 Hardwarové požadavky

Databázový server, 2 pracovní stanice.

Šířka pásma sítě - 100 Mbps.

4.12 Požadavky na perspektivu rozvoje, modernizace IS

Modernizovat a rozvíjet IS by mělo být možné bez zapojení Developera správcem IS na úrovni:

- doplnění, změny, odstranění informace o pozadí IP;

- připojení/vymazání nových uživatelů IP;

- změny hesla;

- import/export dat z/do externí zdroje data.

Upgradovat a vyvíjet IS by mělo být možné s omezenou účastí Vývojáře (telefonické konzultace) na úrovni upgradu starých reportů a vytváření nových reportů. Možnost a podmínky telefonického poradenství Developera o modernizaci IP jsou sjednány samostatně podpisem nové smlouvy.

5. Skladba a obsah práce na tvorbě systému

Práce na návrhu IS "Účtování obchodních operací" probíhají ve třech etapách.

První fáze zahrnuje:

Ověření možnosti získání všech Zákazníkem požadovaných informací na základě prvotních údajů;

Návrh IS DB;

Naplnění vytvořené databáze testovacím souborem dat;

Vývoj designu uživatelského rozhraní;

Vývoj nízkoúrovňové technické specifikace pro vývoj IS "Účtování obchodních operací"

Ukončení první etapy je potvrzeno podpisem interního zákona o provedených pracích a schválením nízkoúrovňové technické specifikace pro vývoj IS.

Druhou etapou je vývoj testovací verze IS „Účtování obchodních operací“. konec tuto fázi je uvedení testovací verze do zkušebního provozu.

Třetí etapou je pilotní provoz IS „Účtování obchodních operací“, jehož součástí je odstraňování zjištěných chyb, nedostatků a nesrovnalostí s tímto zadáním. Závěrem druhé etapy je zavedení IS do komerčního provozu.

Ukončení každé druhé a třetí etapy stvrzují smluvní strany podpisem Osvědčení o převodu a převzetí.

Doba trvání první etapy je 10 dní. Za začátek první etapy se považuje den následující po dni podpisu těchto Podmínek Zákazníkem a Developerem DB.

Doba trvání druhé etapy je 20 dní. Začátek druhé etapy je den následující po dni schválení nízkoúrovňové technické specifikace pro vývoj IS.

Délka třetí etapy je 20 dní. Za počátek třetí etapy se považuje den následující po dni podpisu Zákazníka a Developera DB Certifikátu o převzetí a předání testovací verze IS do zkušebního provozu.

Sadu dat pro testování IS poskytuje Zákazník.

Po dokončení druhé etapy prací Vývojář DB nainstaluje testovací IS na testovací server Zákazníka a předá Zákazníkovi předběžný uživatelský manuál obsahující popis postupů potřebných pro práci s IS Obchodní účetnictví. Popisy jsou uvedeny v v elektronické podobě.

Na konci třetí etapy práce vývojář DB poskytne Zákazníkovi program pro instalaci databáze na server, dále uživatelské a programátorské pokyny a pokyny pro instalaci IS s popisy postupů nutných pro práci s IS "Účtování obchodních operací".

6. Postup pro kontrolu a přejímku systému

Na konci první etapy je podepsán vnitřní zákon o provedené práci a nízkoúrovňový datový list pro rozvoj IS.

Po dokončení druhé a třetí etapy návrhu Developer nainstaluje IS u Zákazníka, předvede provoz IS v souladu s požadavky uvedenými v těchto Podmínkách a podepíše Certifikát o převodu a převzetí.

7. Požadavky na skladbu a obsah prací na přípravu objektu automatizace pro uvedení systému do provozu

Zákazník je povinen v den zahájení zkušebního provozu poskytnout Vývojáři nezbytný přístup k serveru, na kterém bude testovací verze IS účtování obchodních operací nasazena.

Absence serveru pro instalaci databáze IS "Účetnictví živností" nemůže být důvodem k odmítnutí podpisu Přejímacího listu IS "Účetnictví živnostenského provozu" ke zkušebnímu nebo komerčnímu provozu.

Na konci druhé etapy vývoje IS "Účtování obchodních operací" absolvuje Developer 8hodinové školení s pracovníky Zákazníka na obsluhu IS. Na konci tohoto kurzu je otestován personál zákazníka.

8. Požadavky na dokumentaci

Na konci třetí etapy předá Vývojář IS "Účtování obchodních operací" následující dokumentaci Zákazníkovi:

1. Pokyny programátora.

Manuál programátora popisuje postupy potřebné pro práci s IS "Účtování obchodních operací". Popis procedur zahrnuje:

název postupu;

Popis akcí prováděných postupem;

Pro parametr je definován popis vstupních parametrů s uvedením typu parametru, formátu jeho záznamu a případné výchozí hodnoty;

Popis výstupních parametrů a (nebo) vrácených sad záznamů s uvedením jejich typů a formátů

Příklad volání procedury a její návratové hodnoty. Pokud procedura může mít více call opcí, pak příklady pro každou možnost.

2. Návod k instalaci IS "Účtování obchodních operací".

3. Pokyny pro uživatele IS „Účtování obchodních operací“.

Jiná dokumentace není Zákazníkovi poskytována. Pokyny jsou poskytovány v tištěné i elektronické podobě. Pokyny v tištěné podobě jsou poskytovány v jednom exempláři.

Přednáška 15 informační systém

Zadávací podmínky pro tvorbu IS.

2. Složení a obsah TK

Poradní je výpis z GOST 34.602-89 PODMÍNKY PRO VYTVOŘENÍ INFORMAČNÍHO SYSTÉMU, určující složení a obsah TK. Při realizaci RC je povoleno oprávněné změna složení a obsahu TK.

ToR pro IS je hlavním dokumentem, který definuje požadavky a postup pro vytvoření (vývoj nebo modernizace - další tvorba) automatizovaného systému, podle kterého je IS vyvíjen a přijímán při uvedení do provozu.

Požadavky zahrnuté v TOR pro IP musí odpovídat současné úrovni rozvoje vědy a techniky a nesmí být nižší než podobné požadavky na nejlepší moderní domácí a zahraniční analogy.

V závislosti na typu, účelu, specifických vlastnostech objektu automatizace a provozních podmínkách systému je povoleno sestavit části TOR ve formě aplikací, zavést další, vyloučit nebo kombinovat podsekce TOR.

SLOŽENÍ A OBSAH TK

1. Oddíl "Obecná informace" uveďte: úplný název systému a jeho symbol; název podniků (sdružení) vývojáře a zákazníka (uživatele) systému a jejich podrobnosti; plánované termíny zahájení a ukončení prací na tvorbě systému .

2. Oddíl "Účel a cíle tvorby (vývoje) systému" se skládá z podsekcí:

„Účel systému“ označuje typ automatizované činnosti (řízení, návrh atd.) a seznam automatizačních objektů, na kterých má být použit.

„Cíle vytvoření systému“ uvádějí názvy a požadované hodnoty technických, technologických, výrobních, ekonomických či jiných ukazatelů objektu automatizace, kterých je třeba v důsledku vytvoření IS dosáhnout, udávají kritéria pro hodnocení dosažení cíle vytvoření systému.

V kapitole "Charakteristiky objektu automatizace" poskytnout stručné informace o objektu automatizace nebo odkazy na dokumenty obsahující takové informace a informace o provozních podmínkách objektu automatizace a charakteristikách prostředí.

3. Oddíl "Požadavky na systém" sestává z následujících podsekcí: požadavky na systém jako celek; požadavky na funkce (úkoly) prováděné systémem; požadavky na typy zabezpečení.

Skladba systémových požadavků obsažených v této části TOR pro IS je stanovena v závislosti na typu, účelu, specifických vlastnostech a provozních podmínkách konkrétního systému.

V podsekci „Požadavky na systém jako celek“ uveďte:

požadavky na strukturu a fungování systému;

požadavky na počet a kvalifikaci personálu systému a způsob jeho práce;

ukazatele destinace;

požadavky na spolehlivost;

bezpečnostní požadavky;

požadavky na ergonomii a technickou estetiku;

požadavky na přepravitelnost mobilních integrovaných obvodů;

požadavky na provoz, údržbu, opravy a skladování součástí systému;

požadavky na ochranu informací před neoprávněným přístupem;

požadavky na bezpečnost informací v případě nehod;

požadavky na ochranu před vlivem vnějších vlivů;

požadavky na standardizaci a unifikaci;

Další požadavky.

Požadavky na strukturu a fungování systému zahrnují:

1) seznam subsystémů, jejich účel a hlavní charakteristiky, požadavky na počet úrovní hierarchie a stupeň centralizace systému;

2) požadavky na způsoby a prostředky komunikace pro výměnu informací mezi složkami systému;

3) požadavky na charakteristiku propojení vytvářeného systému s navazujícími systémy, požadavky na jeho kompatibilitu, včetně návodu na výměnu informací (automaticky, zasíláním dokumentů, telefonicky apod.);

4) požadavky na provozní režimy systému;

5) požadavky na diagnostiku systému;

6) perspektivy rozvoje, modernizace systému.

V požadavcích na počet a kvalifikaci personálu a vedení IS:

požadavky na počet pracovníků (uživatelů) IS;

požadavky na kvalifikaci personálu, postup při jeho školení a kontrolu znalostí a dovedností;

požadovaný režim práce personálu IS.

V požadavcích na ukazatele jmenování IP dávají hodnoty parametrů, které charakterizují míru shody systému s jeho účelem (míra adaptability systému na změny procesů, metody řízení, na odchylky v parametrech objektu řízení; přípustné limity pro modernizaci a rozvoj systém, pravděpodobnostní a časové charakteristiky, pod kterými je zachován zamýšlený účel systému).

Mezi požadavky na spolehlivost patří:

1) složení a kvantitativní hodnoty ukazatelů spolehlivosti pro systém jako celek nebo jeho subsystémy;

2) seznam nouzových situací, pro které by měly být požadavky na spolehlivost regulovány, a hodnoty odpovídajících ukazatelů;

3) požadavky na spolehlivost hardwaru a softwaru;

4) požadavky na metody hodnocení a sledování ukazatelů spolehlivosti v různých fázích vytváření systému v souladu s platnými regulačními a technickými dokumenty.

Bezpečnostní požadavky zahrnují požadavky na zajištění bezpečnosti při instalaci, seřizování, provozu, údržbě a opravách technických prostředků systému (ochrana před účinky elektrického proudu, elektromagnetického pole, akustického hluku atd.), podle přípustných úrovní osvětlení, vibrací a hluku zatížení.

Ergonomie a technická estetika zahrnují indikátory IS, které specifikují požadovanou kvalitu interakce člověk-stroj a komfort pracovních podmínek personálu.

U mobilních integrovaných obvodů zahrnují požadavky na přenositelnost konstrukční požadavky, které zajišťují přepravitelnost technických prostředků systému, jakož i požadavky na vozidla.

Požadavky na provoz, údržbu, opravy a skladování zahrnují:

1) podmínky a předpisy (režim) provozu, které by měly zajistit používání technických prostředků (TS) soustavy se stanovenými technickými ukazateli, včetně druhů a četnosti údržby TS soustavy nebo přípustnosti provozu bez údržby ;

2) předběžné požadavky na přípustné plochy pro umístění personálu a TS soustavy, na parametry napájecích sítí atd.;

3) požadavky na počet, kvalifikaci personálu údržby a způsoby jeho práce;

4) požadavky na složení, umístění a podmínky skladování sady náhradních výrobků a zařízení;

5) požadavky na plán údržby.

Požadavky na ochranu informací před neoprávněným přístupem zahrnují požadavky stanovené v NTD působící v odvětví (oddělení) zákazníka.

V požadavcích na bezpečnost informací uveďte seznam událostí: havárie, poruchy technických prostředků (včetně výpadku napájení) atd., při kterých musí být zajištěna bezpečnost informací v systému.

V požadavcích na prostředky ochrany před vnějšími vlivy jsou uvedeny:

1) požadavky na elektronickou ochranu majetku duševního vlastnictví;

2) požadavky na odolnost, stabilitu a pevnost vůči vnějším vlivům (prostředí užívání).

V požadavcích na udělení patentu uveďte seznam zemí, pro které musí být systém a jeho části bez patentu.

Mezi požadavky na standardizaci a unifikaci patří: indikátory, které stanovují požadovaný stupeň využití standardu, jednotné metody pro implementaci funkcí (úkolů) systému, dodávané softwarové nástroje, typické matematické metody a modely, typická konstrukční řešení, jednotné formy řídících dokumentů stanovené GOST 6.10.1 , celounijní klasifikátory technických a ekonomických informací a klasifikátory ostatních kategorií v souladu s jejich rozsahem, požadavky na použití typických automatizovaných pracovních stanic, komponent a komplexů.

Dodatečné požadavky zahrnout:

1) požadavky na vybavení systému zařízeními pro školení personálu (simulátory, jiná zařízení podobného účelu) a dokumentací k nim;

2) požadavky na servisní vybavení, stojany na kontrolu prvků systému;

3) systémové požadavky spojené se zvláštními provozními podmínkami;

4) speciální požadavky dle uvážení vývojáře nebo zákazníka systému.

V podsekci „Požadavky na funkce (úkoly)“, prováděné systémem, je uvedeno:

1) pro každý subsystém seznam funkcí, úkolů nebo jejich komplexů (včetně těch, které zajišťují interakci částí systému), které mají být automatizovány;

2) časový harmonogram realizace každé funkce, úkolu (nebo souboru úkolů);

4) seznam a kritéria selhání pro každou funkci, pro kterou jsou specifikovány požadavky na spolehlivost.

V podkapitole „Požadavky na typy zajištění“ jsou v závislosti na typu systému uvedeny následující požadavky:

Pro software systémy poskytují požadavky na složení, rozsah (omezení) a metody, použití matematických metod a modelů v systému, typické algoritmy a algoritmy, které mají být vyvíjeny.

Pro informační podporu: požadavky na vedení systému:

1) ke složení, struktuře a metodám organizace dat v systému;

2) k výměně informací mezi komponentami systému;

3) na kompatibilitu informací se sousedními systémy;

4) o používání celounijních a registrovaných republikových, oborových klasifikátorů, jednotných dokumentů a klasifikátorů působících v daném podniku;

5) o používání systémů správy databází;

6) ke struktuře procesu shromažďování, zpracování, přenosu dat v systému a prezentace dat;

7) chránit data před zničením v případě nehod a výpadků napájení systému;

8) kontrola, ukládání, aktualizace a obnova dat;

Pro jazykovou podporu systémy poskytují požadavky na použití vysokoúrovňových programovacích jazyků v systému, jazyků interakce s uživatelem a technických prostředků systému, dále požadavky na kódování a dekódování dat, jazyky pro vstup a výstup dat, jazyky pro manipulaci s daty, prostředky popisu předmětné oblasti (objekt automatizace), způsoby organizace dialogu.

Pro software systémy poskytují seznam zakoupeného softwaru a také požadavky: na nezávislost softwaru na používaném CVT a OS; na kvalitu PS, jakož i na způsoby jejího poskytování a kontroly; pokud je nutné koordinovat nově vyvinutý software s fondem algoritmů a programů.

Pro technickou podporu požadavky na vedení systému:

1) na druhy technických prostředků, včetně typů komplexů technických prostředků, softwarových a hardwarových komplexů a dalších komponent, které jsou přijatelné pro použití v systému;

2) na funkční, konstrukční a provozní vlastnosti technické podpory systému.

V požadavcích na metrologickou podporu Vést (volitelné pro ekonomy):

1) předběžný seznam měřicích kanálů;

2) požadavky na přesnost měření parametrů a (nebo) na metrologické charakteristiky měřicích kanálů;

3) požadavky na metrologickou kompatibilitu technických prostředků systému;

4) seznam řídicích a výpočetních kanálů systému, u kterých je nutné vyhodnotit charakteristiky přesnosti;

Za organizační podporu klást požadavky:

1) ke struktuře a funkcím jednotek zapojených do provozu systému nebo zajištění provozu;

2) k organizaci fungování systému a postupu interakce mezi personálem IS a personálem objektu automatizace;

3) k ochraně před chybným jednáním personálu systému.

Za metodickou podporu dát požadavky na skladbu regulační a technické dokumentace systému (seznam norem, předpisů, metod apod. používaných při jeho provozu).

Nedávno jsem byl osloven, abych poradil standardy pro psaní zadávacích podmínek (TOR) pro vývoj automatizovaných systémů (AS) a softwaru (SW). Takže si myslím, že teď půjdu na Yandex, najdu vhodný článek a pošlu ho. Ale to tam nebylo! Nenašel jsem jeden článek uvádějící standardy pro TK včetně šablon a ukázek hotových dokumentů. Budu si muset udělat vlastní článek...

A tak hlavní standardy, metodiky a kódy znalostí, kde je zmíněna specifikace TK nebo SRS (Software (nebo System) Requirements Specification):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK atd.

GOST 34

GOST 34.602-89 Referenční podmínky pro vytvoření automatizovaného systému reguluje strukturu TOR pro vytvoření SYSTÉMU, který zahrnuje software, hardware, lidi, kteří pracují se softwarem, a automatizované procesy.

Podle GOST 34 by referenční podmínky měly zahrnovat následující oddíly:

1. Obecné informace
2. Účel a cíle tvorby (vývoje) systému
3. Charakteristika objektů automatizace
4. Systémové požadavky
5. Skladba a obsah práce na tvorbě systému
6. Postup pro kontrolu a přejímku systému
7. Požadavky na skladbu a obsah prací na přípravu objektu automatizace pro uvedení systému do provozu
8. Požadavky na dokumentaci
9. Zdroje rozvoje

Při vývoji TOR pro vládní projekty Zákazníci obvykle požadují dodržování této konkrétní normy.

GOST 19

„GOST 19.xxx jeden systém Programová dokumentace (ESPD)“ je soubor státních norem, které stanovují vzájemně propojená pravidla pro vývoj, návrh a oběh programů (nebo softwaru) a programové dokumentace. Tito. Tato norma platí specificky pro vývoj softwaru.
Podle podmínek zadání GOST 19.201-78 by požadavky na obsah a design podmínek zadání měly zahrnovat následující oddíly:

1. Úvod;
2. Důvody rozvoje;
3. Účel rozvoje;
4. Požadavky na program nebo softwarový produkt;
5. Požadavky na dokumentaci softwaru;
6. Technické a ekonomické ukazatele;
7. Etapy a fáze vývoje;
8. Pořadí kontroly a přijetí;
9. Aplikace.

Přirozeně, GOST 34 (a 19) jsou již zastaralé a nerad je používám, ale se správnou interpretací norem můžete získat dobrou TK, viz Závěr.

IEEE STD 830-1998

Dost dobrá definice Standard 830-1998 - Doporučená praxe IEEE pro specifikace softwarových požadavků je uveden v jeho samotném popisu:

Popište obsah a kvalitativní charakteristiky k dispozici je dobře napsaná specifikace softwarových požadavků (SRS) a několik šablon SRS. Tento doporučený postup je určen ke stanovení požadavků na vyvíjený software, ale může být také použit jako pomoc při výběru proprietárních a komerčních softwarových produktů.

Podle standardu by zadání mělo obsahovat následující oddíly:

1. Úvod

1. Jmenování
2. Rozsah
3. Definice, akronymy a zkratky
4. Odkazy
5. Přehled

2. Obecný popis

1. Interakce produktu (s jinými produkty a komponenty)
2. Vlastnosti produktu (stručný popis)
3. Uživatelské vlastnosti
4. Omezení
5. Předpoklady a závislosti

3. Podrobné požadavky (mohou být organizovány různými způsoby, např. tak)

1. Požadavky na externí rozhraní
- 1. Uživatelská rozhraní
- 2. Hardwarová rozhraní
- 3. Softwarová rozhraní
- 4. Interakční rozhraní
2. Funkční požadavky
3. Požadavky na výkon
4. Návrhová omezení (a odkazy na normy)
5. Nefunkční požadavky (spolehlivost, dostupnost, bezpečnost atd.)
6. Další požadavky

4. Aplikace
5. Abecední rejstřík

Ve skutečnosti je pro začátečníka docela obtížné pochopit, co by mělo být obsaženo v těchto částech podle výše uvedené struktury (jako v případě GOST), takže si musíte přečíst samotnou normu, která. ovšem v angličtině. Jazyk.

No a pro ty, kteří to dočetli až do konce, je tu bonus: příklad TK, který jsem napsal před mnoha lety (teď už dávno nepracuji jako analytik a další úspěšnější příklady jsou zakázány které NDA zpřístupní veřejnosti).

Prezentace Yury Buluy Klasifikace požadavků na software a její reprezentace ve standardech a metodikách.
Analýza požadavků na automatizované informační systémy. Přednáška 11: Požadavky na dokumentaci.
Pravidla pro sestavování specifikace požadavků na software (číst s komentáři)
Příklady TOR a další dokumentace pro vývoj AS pro Ministerstvo hospodářského rozvoje
GOST-ovsky styl řízení. Gapertonův článek správná práce s TK podle GOST
Šablony dokumentů pro obchodní analytiky z