• Zadání pro vývoj informačního systému „Účtování obchodních operací. Zadání pro tvorbu automatizovaného informačního systému

    GOST 34.602-89 Informační technologie. Soubor standardů pro automatizované systémy. Technický úkol pro vytvoření automatizovaného systému (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 hardwarové komponenty a softwarové a hardwarové systémy v souladu s normami 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) typy, složení, rozsah a zkušební metody systému a jeho základní části(typy zkoušek v souladu s aktuálními normami platnými 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. Titulní strana dodatky k TOR pro JE se zpracovávají stejným způsobem jako titulní strana technického zadání. 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) jeden systém normy pro automatizované systémy řízení (24. systém), který se vztahuje na automatizované systémy řízení, automatizované systémy řízení, 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) referenční podmínky jsou hlavním dokumentem, podle kterého se provádí vytvoření AU a její přijetí zákazníkem;
    • 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ílnou součástí práce 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 designových výrobků 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 zprovozňuje informační systém „Účtování obchodních operací“

    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ě, správce 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 programové vybavení a skladbu, strukturu a způsob 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:

    - přidávání, změna, mazání referenčních informací IS;

    - 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.

    Home > Podmínky

    MINISTERSTVO KULTURY RUSKÉ FEDERACE

    Petrohrad Státní univerzita kultury a umění

    Ústav informatiky a informační technologie

    PROJEKT INFORMAČNÍHO SYSTÉMU

    TECHNICKÝ ÚKOL

    pro rozvoj

    vzdělávací informační systém

    < Celý název systému a jeho symbol >

    na 4 listech

    vydáno __.__.200_

    Petrohrad

      Obecná informace

        Důvody rozvoje

    V rámci studia a rozvoje předmětu "Návrh a využití informačních systémů" je vyvíjen vzdělávací informační systém.
        Plánované termíny zahájení a ukončení prací, jakož i postup zpracování a předkládání výsledků prací Zákazníkovi jsou stanoveny v odst. 4 a 5 těchto ZDP.

      Účel a cíle tvorby vzdělávacího informačního systému

        Účel
    Vzdělávací informační systém je určen:
      prokázat míru asimilace obsahu předmětu "Návrh a využití informačních systémů" studentem pro použití jako layout v další práce ah vytvořit nebo zlepšit skutečný informační systém.
        Cíle tvorby vzdělávacího projektu informačního systému
    Vzdělávací informační systém je vytvořen pro:
      dosažení porozumění základním pojmům procesu návrhu systému, zvládnutí vazeb mezi základními pojmy a metodami návrhu, schopnost vypracovat projekt systému a jeho dokumentaci, jakož i vytvořit skutečný IS, demonstrovat výsledky práce a míra asimilace obsahu výcvikový kurz, čímž se vytvoří základ pro další práci na zlepšování projektu a jeho praktické realizaci.

      Požadavky na reportovací materiály vzdělávacího informačního systému

        Požadavky na materiály obecně
          Složení zpravodajských materiálů. Reportingové materiály by se měly skládat ze dvou hlavních částí: projektové dokumentace a layoutu informačního systému (kompletní databáze spolu s požadavky, formuláři, reporty, přístupovými stránkami) realizovaným pomocí ACCESS DBMS (nebo jiného systému). Dispozice musí být realizována v souladu s projektem. Návrhové materiály by měly popisovat uspořádání a jeho možnosti.
        Obsah projektové dokumentace
    Projektová dokumentace by měla obsahovat následující části.
          Titulní strana s názvem projektovaného IC, označení vývojáře a zákazníka. Sekce "Studie proveditelnosti", obsahující stručný popis předmětné oblasti:
      obecné charakteristiky obor a stav prací na automatizaci informační aktivity v této oblasti; analýza schopností a vlastností stávajících podobných systémů; organizační struktura organizace, pro kterou je projektovaný IS vytvářen; jaký je účel organizace (systému) využívajícího projektovaný IS, jeho funkce (organizační, „materiální“, informační); hlavní technicko-ekonomické ukazatele činnosti organizace; informační procesy, spojení mezi nimi; složení použitých dokumentů a jejich účel.
          Stručné podmínky. TOR by měl odrážet:
      účel a účel tvorby IS; požadavky na systém jako celek; hlavní automatizované funkce a úlohy, časové charakteristiky řešení problémů a požadavky na prezentaci informací v systému;
      kritéria účinnosti vyvíjeného systému (faktory určující užitečnost vyvíjeného systému, kritéria jejich hodnocení); seznam etap a etap prací a načasování jejich realizace, načasování zpracování projektové dokumentace.
          Sekce "Technické provedení", obsahující následující podkapitoly:
      funkční model systému (prezentovat kontextový diagram, diagram první úrovně a jeden nebo dva diagramy druhé úrovně; popsat složení hlavních funkcí, jejich vztahy: vstup, výstup, řídicí toky); model toku dat (prezentovat kontextový diagram, diagram první úrovně a jeden nebo dva diagramy druhé úrovně; popsat složení pohonů, hlavní funkce, jejich informační odkazy: vstupní a výstupní proudy; pro každé zařízení pro ukládání dat charakterizujte objem, frekvenci a intenzitu aktualizace); popis informační podpory: formy vstupních a výstupních dokumentů, charakteristika jejich objemu, frekvence, intenzita aktualizace, analýza jejich struktury (podrobnosti, popisované entity), použité klasifikátory, metody kódování, požadavky na zajištění spolehlivosti dat.
          Seznam použitých zdrojů (literatura). Sekce "Pracovní návrh", obsahující následující podkapitoly:
      koncepční schéma softwaru a fyzické schéma systémové databáze (vyvinuté pomocí systému Power Designer); popis konkrétního vývoje pro realizaci projektu IP:
        popis databázového schématu v ACCESS (nebo v jiném DBMS), popis úloh, které implementují funkce formulované v Technickém návrhu (včetně dotazů, formulářů, sestav, přístupových stránek používaných v těchto úlohách). Je nutné mít dialogové formuláře a návod k jejich použití. Pokud projekt nemá složité formuláře, sestavy, je skóre sníženo o 1 bod.
          Závěr: Shrnutí výsledků práce. Uveďte, která z ustanovení Technického návrhu byla ve druhé části implementována a která nebyla implementována a proč.
        Uspořádání informačního systému

    Uspořádání informačního systému musí být realizováno v souladu s projektem. Mělo by se jednat o kompletní databázi s dotazy, formuláři, sestavami, které realizují úkoly popsané v projektu.

        Požadavky na dokumentaci
    Při vytváření dokumentů zvažte následující požadavky:
      skladba oddílů a pododdílů reportovacího dokumentu musí odpovídat tomu, co je uvedeno v odstavci „Obsah projektové dokumentace“, schémata funkčního modelu, modely datových toků, koncepční a fyzický model jsou zpracovány ve formě obrázky a jsou zahrnuty v hlavním textu; dále v hlavním textu jsou jako přílohy uvedeny texty žádostí, výkresy prezentace formulářů, sestavy, přístupové stránky, vzorové dokumenty, tabulky popisující modely, tabulky popisující vlastnosti databázových polí.

      Seznam fází prací a termínů jejich realizace

    Práce probíhají dle harmonogramu uvedeného na další strana(tabulka 4.1).

      Postup při kontrole a přijímání hlášení

        Materiály pro hlášení se předkládají ve dvou termínech:
      V podzimním semestru se odevzdává zpráva, která odpovídá prvním pěti bodům rozvrhu. V jarním semestru jsou odevzdány konečné výsledky práce: zpráva (včetně přepracovaných výsledků předchozího semestru), dále databáze - model vyvíjeného IS.
        Hodnocení práce v podzimním semestru probíhá formou testu. V jarním semestru se všechny ročníkové práce odevzdávají jako semestrální práce. Zkoušku mohou konat pouze studenti, kteří obhájili semestrální práci. Penalty.
    Výsledky návrhu musí být předloženy v termínu uvedeném v harmonogramu. Porušení lhůt je penalizováno, pokud zpracovatel (student) neodevzdá první zprávu v termínu uvedeném v harmonogramu, není mu umožněno absolvovat. Při pozdním odevzdání protokolu rozhoduje o připuštění ke zkoušce objednatel (učitel) do týdne Pokud zpracovatel (student) odevzdá závěrečné podklady k vykazování později než v termínu uvedeném v rozvrhu, známka za práce na kurzu se snižuje o 1 bod. Ochrana seminární práce může proběhnout nejdříve týden po odevzdání podkladů. O připuštění ke zkoušce rozhoduje vyučující na základě výsledků obhajoby seminární práce. Přání vývojáře získat stipendium není základem pro zrušení sankcí.

    Harmonogram prací na vývoji reportovacích materiálů

    Tabulka 4.1.

    Pseudonym

    Uzávěrka

    Prezentované materiály

    PODZIMNÍ SEMESTRÁLNÍ PRÁCE
    1 Výběr oborové oblasti a organizace, pro kterou má být informační systém navržen Týden po první přednášce IP jméno
    2 "Průzkum" oboru (v literatuře a jako výsledek komunikace s odborníky) Týden po třetí přednášce
    3 Vývoj funkčního modelu Týden po čtvrté přednášce Funkční schémata v ručně psané formě
    4 Vývoj modelu toku dat Týden po páté přednášce Ručně psané diagramy toku dat
    5 Vývoj popisů vstupních a výstupních dokumentů Konec 25. listopadu Struktura rekvizit dokumentu, funkčních závislostí podrobnosti
    6 Vypracování projektové dokumentace v souladu s body 3.2.1 - 3.2.5 Probíhá. praktický třídy.
    7 Dodání projektové dokumentace 20. prosince Dokumentace ve formě zprávy
    JARNÍ SEMESTRÁLNÍ PRÁCE
    8 Vývoj schématu kontextové domény Týden po druhé přednášce Kontextový diagram softwaru v ručně psané podobě
    9 Vytvoření databázového schématu v jazyce zvoleného DBMS Na konci druhého praktického třídy
    10 Implementace systému (vyplňování databázových tabulek, vytváření dotazů, formulářů, reportů, přístupových stránek) Do konce pátého praktické sezení Kompletní databáze s požadavky, formuláři atd.; předložen učiteli
    11 Registrace výsledků (projekt a databáze) Týden po bodu 9 Cvičení: dokumentace ve formě zprávy a v kartotéce; databáze
    12 Obhajoba ročníkové práce Ne dříve než týden po předchozím termínu
  • Životní cyklus (LC) informačního systému. Základní procesy životního cyklu. Pomocné procesy. organizační procesy. Technologie návrhu informačních systémů.
  • Zadávací podmínky pro návrh informačního systému. Hlavní části zadání. Normy popisující zadání. Analýza a vývoj požadavků.
  • Metody autentizace uživatelů informačních systémů.
  • Feistelova síť: princip činnosti a použití v algoritmech blokové šifry
  • Analýza hlavních technologií pro vývoj elektronických technických dokumentů
  • Typické struktury elektronických technických dokumentů
  • Technologie pro návrh a implementaci multimediálního produktu.
  • 26. Klasifikace počítačových grafických systémů. Kódování vektorové a rastrové grafické informace. Rastrové grafiky jsou obrazové objekty. Vektorová grafika jsou obrazové objekty.
  • 27. Barevné modely rgb, cmYk, hsv (hsb), hsl, lab. Reprezentace barev, kódování, přiřazení.
  • 28. Strukturovaná kabeláž: topologie, subsystémy, kategorie pasivních zařízení.
  • 29. Postup návrhu systému strukturované kabeláže.
  • 30. Globální internet. síťových protokolů. osový model. Systém doménových jmen, překlad doménového jména na ip adresu. Směrování paketů na internetu.
  • 31. Logické programování v Prologu. Reprezentace znalostí o předmětu ve formě faktů a pravidel znalostní báze Prolog. Organizace opakování.
  • 1.1. Metoda vrácení po selhání.
  • 33. Jádro operačního systému. Klasifikace jader operačních systémů. Výhody a nevýhody různých architektur jader operačních systémů.
  • 34. Souborový systém jako součást operačního systému: definice, hlavní funkce a možnosti. Příklady implementace souborových systémů.
  • 35. Informace a entropie. Měření množství informací. Informační vlastnosti. Hartleyho a Shannonova vzorce.
  • 37. Kódy, které detekují a opravují chyby přenosu. Budování systematického kódu. Hammingův kód.
  • 38. Pojem proměnné v programovacích jazycích. operátor přiřazení. Organizace vstupu a výstupu dat v aplikaci. Organizace větvení a smyček v programovacích jazycích.
  • 39. Pole jako způsob organizace dat. Implementace polí v různých programovacích jazycích. Jednorozměrná a vícerozměrná pole. Typické algoritmy pro zpracování polí.
  • 40. Podprogramy (metody) v programovacích jazycích. Formální a skutečné parametry. Globální a lokální proměnné. Rekurzivní provádění podprogramu.

    1. Zadávací podmínky pro návrh informačního systému. Hlavní části zadání. Normy popisující zadání. Analýza a vývoj požadavků.

    Technický úkol- technický dokument (specifikace) specifikující soubor požadavků na systém a schválený jak zákazníkem/uživatelem, tak dodavatelem/výrobcem systému. Tato specifikace může také obsahovat Požadavky na systém a požadavky na testování.

    Smluvní podmínky obsahují následující oddíly:

      Obecná informace. Tato část obsahuje: celý název vývoje, celé jméno a údaje o objednateli a zhotoviteli, seznam dokumentů, které jsou podkladem pro vývoj, možné termíny zahájení a ukončení prací, postup zpracování a prezentace výsledků práce na vytvoření systému nebo jeho částí zákazníkovi.

      Základy a účel rozvoje.Účelem rozvoje se rozumí typ automatizovaných procesů činnosti.

      Požadavky na systém. Obsahuje podsekce s požadavky na systém jako celek a funkcemi, které systém vykonává.

      Skladba a obsah práce na tvorbě systému. Seznam prací a jejich obsah, které mají být provedeny v rámci tohoto projektu

      Pořadí kontroly a akceptace systému. Obsahuje odhadovaná data pro prozatímní kontrolu a odhadované datum dodání zákazníkovi.

      Požadavky na skladbu a obsah prací na přípravu vývojového objektu pro uvedení systému do provozu. Jsou popsány přípravné práce pro uvedení systému do provozu.

      Požadavky na dokumentaci. Obsahuje seznam a složení systémové dokumentace.

      Vývojové zdroje. Obsahuje seznam dokumentace, literatury, která bude použita při vývoji systému.

    Existují tři normy, které popisují podmínky návrhu IC: GOST 34.602-89, GOST 19.201-78, GOST 19.102-77.

    Vývoj požadavků může být tvořen na základě průzkumů, dotazníků atd. Kromě toho lze požadavky formulovat na základě brainstormingu, pozorování výrobních činností, analýzy regulační dokumentace, analýzy již vytvořeného IS, analýzy používaných verzí IS.

    Při vývoji požadavků často vyvstávají problémy s nejednoznačností, neúplností a nejednotností jednotlivých požadavků. Odstranění těchto problémů ve fázi vývoje požadavků stojí o několik řádů méně než řešení stejných problémů v pozdějších fázích vývoje.

      Uživatelské rozhraní informačních systémů. Obecné zásady konstrukce. styly uživatelského rozhraní. Kritéria výkonu uživatelského rozhraní. Pokyny pro vytváření uživatelského rozhraní. Pravidla designu.

    Uživatelské rozhraní- jedná se o softwarovou část informačního systému zodpovědnou za správu zařízení, se kterými uživatel komunikuje s programem.

    Plánování a návrh uživatelského rozhraní by mělo být založeno na následujících modelech:

    - mentální model- některá očekávání člověka založená na smyslu pro realitu a na jeho znalostech a zkušenostech s počítačem.

    - Vlastní model- Pozorováním toho, jak uživatelé pracují s novým rozhraním pro sebe a analýzou jejich zpětné vazby na práci, můžete získat obecnou představu o budoucím rozhraní. Je důležité, aby byl uživatel co nejdříve zapojen do práce na IS.

    - Programátorský model- se rodí v hlavě programátora, na základě jeho profesních aktivit.

    styly uživatelského rozhraní. Existují čtyři hlavní styly uživatelského rozhraní:

    - Grafické uživatelské prostředí (Grafický uživatel Rozhraní, GUI) - Toto rozhraní je založeno na čtyřech základních prvcích: okna, ukazatel (myš), nabídky a ikony. Používají se i další prvky: tlačítka, přepínače, vstupní pole atd. Charakteristickým rysem tohoto rozhraní jsou pokročilé možnosti designu obrazovky a ovládání pomocí ukazatele myši.

    - web-rozhraní (web uživatel Rozhraní, WUI) - Rozhraní připomíná rozhraní GUI, ale původně bylo chudší než ono. V něm se konkrétně používal režim jednoho okna a chyběla možnost „drag and drop“ objektů. S rozvojem JavaScriptu a Ajaxu se stává spíše rozhraním GUI.

    - RozhraníHUI (člověk uživatel Rozhraní) je uživatelské rozhraní pro kapesní zařízení. Obvykle mají tato zařízení velmi malou obrazovku. Obsahuje některé prvky GUI, jako jsou položky nabídky a ikony.

    - Objektový styl rozhraní. Možnosti objektového programování umožňují přenést povahu objektu do uživatelského rozhraní. Objektový přístup je charakterizován funkcemi jako drag and drop, kontextová nabídka, popisky atd.

    Zvažte sadu kritérií kvality uživatelského rozhraní:

    - Porozumění uživatelům - jak se potřeby uživatelů promítají do rozhraní programu.

    - Efektivita procesu návrhu– určuje, zda je produkt pečlivě promyšlen a navržen.

    - Potřeba projektu- zda má produkt ekonomický a společenský význam.

    - Vhodnost pro studium a použití– jak obtížné je produkt naučit a používat.

    - Korespondence Je design produktu vhodný pro řešení problémů.

    - estetické cítění– jak esteticky příjemné je použití produktu.

    - Proměnlivost– jak moc se může design měnit podle požadavků uživatele.

    - ovladatelnost- do jaké míry je implementována funkce správy produktu: správa instalace, školení, údržba.

    Obecné principy tvorby grafického rozhraní:

    Použití jediného uživatelského prostředí v podobě tzv. desktopu;

    Použití grafických oken k zobrazení dat;

    Použití vstupu bez klávesnice (pomocí myši).

    Pravidla návrhu uživatelského rozhraní:

    - Uživatelské ovládání - vývojáři by měli uživateli poskytnout nejúplnější kontrolu nad IP (pokud to zabezpečení umožňuje). Zvažte několik konkrétních implementací tohoto principu:

    1) snížení zátěže paměti – paměť uživatele není tak velká a není tak rychlá.

    2) kompatibilita rozhraní – schopnost uživatelů přenášet své zkušenosti a znalosti do práce s novým softwarem.

      Modelování informačních systémů. Potřeba modelovacích jazyků. JazykUML. Principy objektově orientovaného navrhování. Přehled jazykových diagramůUML. Diagramy případů užití a diagramy tříd.

    Modelování- jedná se o nahrazení studovaného objektu (originálu) jeho podmíněným obrazem nebo jiným objektem (modelem) a studium vlastností originálu zkoumáním vlastností modelu.

    Účinnosti simulace lze dosáhnout, jsou-li splněny dvě podmínky: model poskytuje správné zobrazení vlastností originálu; model odstraňuje problémy spojené s měřením skutečného objektu.

    Modelovací jazyk - je to zápis, většinou grafický, který se používá k popisu projektů. Notový zápis je kolekce grafických objektů použitých v modelu. Notace je syntaxí modelovacího jazyka. Na jedné straně by měl modelovací jazyk učinit rozhodnutí návrháře srozumitelným pro uživatele, na druhé straně poskytnout návrhářům prostředky pro co nejformalizovanější reprezentaci informačního systému. Grafický obrázek je často nejsrozumitelnější formou prezentace informací.

    UML (sjednocený Modelování Jazyk- Unifikovaný Modelovací Jazyk) je grafický popisný jazyk pro objektové modelování v oblasti vývoje softwaru.UML používá grafickou notaci k reprezentaci abstraktního modelu systému, nazývaného UML model. Tento jazyk byl vyvinut pro modelování IS UML není programovací jazyk, ale kód je generován na základě modelu UML.

    Objektově orientovaný model je soubor diagramů popisujících pomocí jazyka UML různé aspekty struktury a chování IS.

    DiagramUML- Jedná se o grafické znázornění množiny prvků, nejčastěji zobrazované jako graf s vrcholy (entitami) a hranami (relacemi).

    Přečtěte si více: