Technická úloha
vypracovať informačný systém
1. Všeobecne
4. Systémové požiadavky
6. Postup kontroly a prijatia systému
1. Všeobecne
V súlade so Zmluvou č. MP23 medzi "LLC TechnonPlus" (v budúcnosti, vývojárom) a Optotorgovka LLC (ďalej len zákazník), vývojár navrhuje databázu, vyvíja a uvedenie informačného systému "Účtovníctvo obchodných operácií"
Deň začiatku dizajnu BDB je deň ďalej po podpísaní tejto technickej úlohy
Ak zákazník zmení požiadavky opísané v tomto dokumente v tomto dokumente, potom sú vykonané samostatným dokumentom a predstavujú zmenu alebo doplnenie zmluvy medzi zákazníkom a vývojárom databázy z hľadiska úplnenia zmluvy
Zákazník zaplatí prácu DB Developer v súlade s zmluvou N XXX
2. Menovanie a ciele vytvorenia (rozvoja) systému
IC "Účtovanie obchodných operácií" je určené na skladovanie, spracovanie a analýzu informácií týkajúcich sa hlavnej činnosti zákazníka.
Účel vytvorenia IP "Účtovníctvo obchodných operácií" je:
Ukladanie informácií o obchodných operáciách;
Odrazu obchodných operácií v účtovníctve;
Analýza finančných výsledkov obchodných operácií;
Analýza obchodných činností v kontexte nomenklatúry a protistrany.
3. Charakteristika automatizačných objektov
3.1. Hlavnou činnosťou zákazníka je predaj nábytku a súvisiacich tovarov na nepeňažných platbách.
3.2. Zákazník nie je platiteľom DPH
3.3. Počas dňa zákazník nevykonáva viac ako 100 obchodných operácií na nákup a predaj tovaru.
3.4. Celkový objem sortimentu nepresahuje 3000 jednotiek
3.5. Celkový počet zmluvných strán - dodávateľov najviac 100 jednotiek.
3.6. Počet zmluvných strán - kupujúcich - nie je obmedzený. V čase, keď bolo podpísanie dohody n xxx 300 jednotiek.
3.7. Kontrola tovaru zo skladu zákazníka vykonáva podľa metódy vážených priemerných nákladov.
3.9. Ako výdavky sa používajú iba účty triedy 9.
3.10. Financi Výsledky Torgіveloji Diyalostiosti pіdpriєmovi (opercii opolištiki)) Navštívte základňu na základe Riznitski Rahunkiv 702 TA 902.
3.11. Obchodné operácie sú zapísané v primárnych dokumentoch. Farská faktúra, spotrebný faktúra, bankový výpis.
PRIBUTKOVA OVAKA (PN) Vіdoguguyu "Skutočnosť prežije na tovar do skladu P_dpromnia, že úvod je:
- číslo;
- dátum;
– Іm'ya protistrana (firmy - asistent);
– na namanuvanny na výrobok;
- kilkіst;
– tsіna odinitsky na výrobok;
- Sumu.
Vidatkova oblasť (VN) Vidigovanie Skutočnosť Vidvanthavnaya Vo produkte predajnej ceny Pіdpromnia, som nakupovať úvodom, som podobný informaxiu v PN (Lishe podpredsedom firmy-dámska komunita Kompletná Firma-Parašská).
Riadok Bankіvskoї Vipizki піддоторджу фак Fakt Non-Arrivaly / Vibutety Koshtіv із Ryrojunkovoy Rahunku (P / R) P_DPRIєMI do MISTAK Taka IFORFORY:
- dátum;
– miestne / súkromné \u200b\u200bKoshtіv;
– ІM je protistrana (koho opіyshley / kto bol prepracovaný mačkami).
3.12. Primárny dokument kože є Підстовую за зісненненняя spev elektroinštalácie, yakі zіysnutnut zmіni spevácky účtovníctvo Rhoduskiv. Operácie Torgіvetnaya pіdpriєmi villicyut sai elektroinštalácie (tabuľka 3.1)
Tabuľka 3.1 - Zapojenie používané v účtovníctve v podniku zákazníka
Prevádzka | Dokument | Debetné faktúry | Úverový účet | Množstvo |
Vysielanie | Nákupná faktúra | množstvo dokumentu |
||
Preprava tovaru | Faktúra | množstvo dokumentu |
||
tovar dodaný tovar |
||||
Prijatie peňazí na zúčtovací účet | Výpis z banky (farnosť) | množstvo dokumentu |
||
Prenos peňazí z bežného účtu | Výpis z banky (spotrebný) | množstvo dokumentu |
||
Stanovenie finančných výsledkov | vo výške uzatvorenia 902 účtov |
|||
vo výške uzatvárania 702 účtov |
dE 281 - Komentáre na skladu;
311 - Roshukunki Rahunov Vіtchiznyanіy Valti;
361 - Roshwasters z nákupných obchodov;
631 - Roshwinks s vіtchiznyani Apeople;
702 - Príjem VID Realіzatskі Ukrajina;
902 - Civicarti Realinzovy Telepary (Vitya).
3.13. V Yakosti účtovníctve Kittnities Vicerist, Saldov Vіdomіst syntetická oblasť Visigayda Yak v tabuľkách 3.2.
Dlaždice 3.2 - Revolučná Saldova Vіdomіst syntetická oblasť
Číslo pozície | Balancecale | Otáčanie | Saldo Kіntsev |
|||
Naraz |
4. Systémové požiadavky
IC "Účtovanie obchodných operácií" musí spĺňať tieto požiadavky:
4.1. Databáza pre IP "Účtovné operácie" by mali poskytovať ukladanie, zobrazenie a editáciu referenčných a prevádzkových informácií.
Referenčné informácie:
o Popis produktu:
Číslo nomenklatúry (tovar);
Meno Produktu;
Popis;
o Zmluvy - Dodávatelia;
Číslo protistrany;
Názov protistrany;
Adresa protistrany;
Kontaktov;
o protistrany - kupujúci;
Číslo protistrany;
Názov protistrany;
Adresa protistrany;
Kontaktov;
o Účel Účet, na ktorom je účtovanie, aby zodpovedalo na obchodné operácie a analyzovanie finančných výsledkov;
o Zoznam základných elektroinštalácie na zobrazenie obchodných operácií v účtovníctve spôsobené primárnymi dokumentmi, ktoré majú nasledujúci formulár ako v tabuľke3.1;
Operatívne informácie:
o Primárne dokumenty: Farská faktúra, spotrebná faktúra, výpis z bankoviek (popis dokumentu je uvedený v 3.11)
o Účtovné zapojenie spôsobené primárnymi dokumentmi (pohľad na zapojenie je uvedené v tabuľke 3.2)
o Informácie o tovare na sklade: \\ t
Číslo položky;
Sumy;
Sumy;
Priemerná cena.
4.2. IP "Účtovanie obchodných operácií" by vám malo umožniť automatizovať tieto akcie:
4.2.1 odrážajú skutočnosti získavania (získania) a prepravy tovaru na sklade, a to, prepočítavajú množstvo tovaru na sklade a jeho priemerné náklady.
4.2.2 Tvorba podľa primárnych dokumentov Účtovné zapojenie v automatickom režime.
4.2.3 Vyhľadávanie nasledujúcich informácií:
Primárne dokumenty určeného typu na určité obdobie;
Zapojenie pre špecifikovaný typ dokumentov na určitý dátum;
Informácie o protistrane
Informácie o produkte
4.2.4 Analyzovať obchodné aktivity počas stanoveného obdobia v nasledujúcich kusoch: \\ t
Finančné výsledky obchodných činností;
Výsledky výpočtov pre každú protistranu;
Zvyšky tovaru v sklade pre každé meno;
Náklady na transakcie pre každú protistranu;
Náklady a množstvo predaja pre každý typ tovaru
4.2.5 Vytvoriť správy na určené obdobie:
Zariadenie, na ktorom je IP nainštalovaná, musí byť vybavená neprerušiteľným napájaním. Pri poruchách napájania by sa malo vyskytnúť automatické ukončenie IP operácií bez straty údajov.
OP by mala zabezpečiť záložné mechanizmy, IP by mala byť vybavená vhodným zariadením a softvérom:
Kvantitatívne hodnoty indikátorov spoľahlivosti:
- Čas automatického ukončenia práce by nemal byť dlhší ako 1 minútu;
- Čas obnovy po zlyhaní nesmie byť dlhší ako 30 minút;
- index zlyhanie IP by mala byť 11/7, t.j. neprerušovaná práca ICS 11 hodín denne 7 dní v týždni.
Údržba IP by sa mala vykonať bez prerušenia.
4.5 Požiadavky na metódy hodnotenia a kontrolu indikátorov spoľahlivosti vo fáze skúšobnej prevádzky
Na kontrolu ukazovateľov spoľahlivosti v etapách skúsenej prevádzky OP musí servisný personál viesť lodný denník, ktorý musí obsahovať tieto informačné označenia:
Dátum výskytu chýb;
Celkovú prevádzku predmetu od začiatku jeho prevádzky až do rozpoznania chýb;
Externé príznaky a povaha vzhľadu chyby;
Typ práce, pod ktorou bola chyba zistená.
4.6 Požiadavky na výkonnosť IP
Systém musí zachovať schopnosť spracovať až 1000 dokumentov za deň
Systém musí mať nasledujúcu produktivitu:
80% operácií musí mať čas odozvy (čas prevádzky) menej ako 1C;
15% operácií - od 5PS. až 10 sekúnd;
5% operácií - viac ako 10 sekúnd, ale nie viac ako 30 minút.
4.7 Požiadavky na zväzky (škálovateľnosť)
Systém musí uchovávať prístup k údajom po dobu 10 rokov.
Odhadované zvýšenie objemu databázy v jednom dni prevádzky 20 MB.
4.8 Požiadavky na číslo, funkcie a kvalifikácie personálu IP a jeho pracovného režimu
Práca s IP vykoná nasledovné zákaznícke personál:
Správca:
Množstvo: 1;
Kvalifikácia: Administrátor siete, administrátor databázy;
Funkcie: Systém riadenia bezpečnosti, zálohovanie dát na začiatku každého pracovného dňa, archivovanie údajov raz ročne;
Spôsob prevádzky: 1 hodina za deň, 5 dní v týždni
Prevádzkovateľ (používateľ), ktorý opravuje skutočnosť obchodnej prevádzky a analyzovanie výsledkov obchodných činností:
Množstvo: 2;
Kvalifikácia: účtovník, užívateľ PC;
Funkcie: Zadajte primárne dokumenty, udržiavať aktuálny stav informácií o akciách, vytvorenie účtovného zapojenia, analýzy výsledkov obchodných aktivít, záložných údajov na začiatku pracovného dňa padajúceho v sobotu a nedeľu.
Spôsob prevádzky: Zmenený, aby sa zabezpečila prevádzka systému 11 hodín denne 7 dní v týždni;
Prístup k práci: 8. hodinový kurz;
Pred obsluhovaním musia personál prejsť 8-hodinovým vzdelávacím kurzom. Po dokončení kurzu sa vykoná testovanie v procese, podľa ktorého sa odhaduje správnosť a rýchlosť riešenia praktických problémov, ako aj znalosti oficiálnych a technických pokynov.
Systém by mal poskytnúť prístup k jeho funkciám len pre registrovaných IP používateľov na určenie hesla.
4.10 Požiadavky na softvér a zloženie, štruktúra a metódy organizácie BD
Systémové údaje by mali byť uložené v relačnom DBMS MS SQL Server 2000.
- T-SQL (dialekt jazyka SQL);
S #.
Softvér sa skladá zo softvéru širokého systému zakúpeného od fondov zákazníka (zakúpený softvér) a špeciálny softvér vyvinutý ako súčasť práce na vytváraní IP.
Ako softvér široký systém musí byť použitý nasledujúci softvér:
Operačný systém;
Systém databázy databázy SQL Server 2000;
Softvér pre zálohovanie;
4.11 Hardvérové \u200b\u200bpožiadavky
BD Server, 2 pracovné stanice.
Šírka pásma siete - 100Mbps v sek.
4.12 Požiadavky na rozvojové vyhliadky, modernizácia
Možnosť modernizácie a rozvoja IP bez toho, aby sa vývojár vytvoril pre vývojárov síl správ IP na úrovni:
- dodatky, zmeny, odstrániť referenčné informácie IP;
- pripojenie / odstránenie nových používateľov IP;
- zmeny hesla;
- import / export dát z / na externé zdroje údajov.
Mali by sa poskytnúť možnosť modernizácie a rozvoja IP s obmedzenou účasťou developera (telefonické konzultácie) na úrovni modernizácie starých a vytváraní nových správ. Možnosť a podmienky informačnej konzultácie Developer o modernizácii OP sú dohodnuté samostatne podpisom novej zmluvy.
5. Zloženie a údržba práce na vytváraní systému
Práca na dizajne IP "Účtovanie obchodných operácií" sa vykonáva v troch etapách.
Prvá etapa zahŕňa:
Kontrola možnosti získania všetkých informácií požadovaných zákazníkom na základe zdrojových údajov;
Návrh BD IP;
Vyplnenie databázy vyvinutá databázou;
Vývoj dizajnu používateľského rozhrania;
Vývoj technickej špecifikácie s nízkou úrovňou pre rozvoj IP "Účtovníctvo obchodných operácií"
Koncová fáza je potvrdená podpísaním interného zákona o vykonanej práci a vyhlásenie o nízkej úrovni technickej špecifikácie pre vývoj IP.
Druhou etapou je vývoj testovacej verzie IP "účtovníctva pre obchodné operácie". Koniec tejto fázy je vstup skúšobnej verzie do skúšobnej prevádzky.
Treťou etapou je skúsená prevádzka IC "účtovníctva pre obchodné operácie", ktorý zahŕňa odstránenie zistených chýb, nedostatkov a nezrovnalostí s touto technickou úlohou. Koniec druhej etapy je zavedenie IP do priemyselnej prevádzky.
Koniec každej druhej a tretej fáze potvrdzujú zmluvné strany podpísaním aktu o prijatí.
Trvanie prvého stupňa je 10 dní. Začiatok prvého stupňa je deň, nasledujúci deň podpísania zákazníkom a vývojárom databázy tejto technickej úlohy.
Trvanie druhej etapy je 20 dní. Začiatok druhej etapy sa považuje za deň po dni schválenia technickej špecifikácie na nízkej úrovni pre rozvoj OP.
Trvanie tretej etapy je 20 dní. Začiatok tretej etapy je deň, keď deň budúci po dni podpisu zákazníkom a vývojárom prijatia databázy testovacej verzie testovacej verzie IP do skúšobnej prevádzky.
Súbor údajov pre testovanie IP poskytuje zákazníkom.
Na konci druhej fázy práce, vývojár databázy nastaví test na testovací server zákazníka a poskytuje zákazníkovi predchádzajúci príručku užívateľa, ktorý obsahuje postupy potrebné na prácu s IP "Účtovníctvo obchodných operácií". Popisy sú uvedené v elektronickej forme.
Na konci tretej fázy práce, developer databázy poskytuje zákazníkovi na server inštalačného programu na server, aj pokyny na používateľov, programátor a pokyny na inštaláciu IP s opismi postupov potrebných na prácu s IC "Účtovníctvo pre obchodné operácie ".
6. Postup monitorovania a prijímania systému
Na konci prvej etapy je podpísaný interný zákon o vykonanej práci a technická špecifikácia na nízkej úrovni je schválená technická špecifikácia pre rozvoj IP.
Na konci druhého a tretieho štádia konštrukčných fáz sa vývojár zakladá OP od objednávateľa, demonštruje prácu OP v súlade s požiadavkami uvedenými v tomto technických špecifikáciách a podpisuje akt prijatia a prenosu.
7. Požiadavky na zloženie a údržbu práce na príprave automatizačného zariadenia na vstup do systému
V deň začatia skúsenej prevádzky je zákazník povinný poskytnúť vývojár potrebný prístup k serveru, na ktorom bude nasadená skúšobná verzia "účtovníctva obchodných operácií".
Absencia servera na inštaláciu databázy OS "Účtovníctvo obchodných operácií" nemôže byť základom pre odmietnutie podpísať akt prijatia prijatia správy IP "účtovníctva pre obchodné operácie" do experimentálnej alebo priemyselnej prevádzky.
Na konci druhej etapy developer vykonáva 8-hodinový tréningový kurz so zamestnancami zákazníka pre službu IP. Na konci tohto kurzu je zákazníkom testovaný.
8. Požiadavky na dokumentáciu
Na konci tretej fázy, vývojový vývojár "účtovanie obchodu" prenesie nasledujúcu dokumentáciu zákazníkovi:
1. Pokyny pre programátora.
Pokyny programátora opisujú postupy potrebné na prácu s IP "Účtovníctvo obchodných operácií". Opis postupov zahŕňa:
Názov postupu;
Opis vykonaného postupu;
Popis vstupných parametrov, s indikáciou typu parametra, formátu jeho nahrávania a predvolených hodnôt, ak áno, je definovaný pre parameter;
Popis výstupných parametrov a (alebo) vrátených záznamových súborov označujúcich ich typy a formáty
Príklad volania postupu a vráti hodnoty. Ak môže mať postup niekoľko možností volania, potom príklady pre každú možnosť.
2. Pokyny na inštaláciu IC "Účtovníctvo pre obchodné operácie".
3. Používateľská príručka "Účtovníctvo pre obchodné operácie".
Ostatná dokumentácia nie je poskytnutá zákazníkovi. Pokyny sú poskytované v tlačenej aj elektronickej forme. Pokyny v tlači sú uvedené v jednom prípade.
GOST 34.602-89 Informačné technológie. Komplex noriem na automatizovaných systémoch.Technická úloha vytvoriť automatizovaný systém (namiesto GOST 24.201-85)
Dátum zavedenia od 01/01 / 1990G.
Tento štandard sa vzťahuje na automatizované systémy (AC) na automatizáciu rôznych typov činností (riadenie, dizajn, výskum, atď.), Vrátane ich kombinácií a stanovuje zloženie, obsah, pravidlá pre návrh dokumentu "Technická úloha pre vytvorenie (vývoj alebo modernizácia) systémy "(ďalej len TK na AC).
1. Všeobecné ustanovenia
1.1. TK na AC je hlavným dokumentom, ktorý definuje požiadavky a postup vytvárania (rozvoj alebo modernizácia, je ďalej vytvoriť automatizovaný systém, podľa ktorého sa pri nadobudnutí jeho účinnosti vyvíja AC a jeho prijatie.
1.2. TK na AÚ je vyvinutý na systéme ako celku, určený na prácu nezávisle alebo ako súčasť iného systému.
Okrem toho môže byť TK vyvinutý na časti reproduktorov:
- na subsystémoch AÚ, komplexy úloh AC atď. v súlade s požiadavkami tohto štandardu;
- o komponentoch technickej podpory a softvéru a technických komplexov v súlade s normami ECC a SRPP;
- v súlade s normami ECPD;
- informačné produkty v súlade s GOST 19.201 a NTD pôsobiacim na Katedre zákazníka AU.
Poznámka. V TK na ACS pre skupinu vzájomne prepojených predmetov by sa mali zahrnúť iba požiadavky na skupinu predmetov. Špecifické požiadavky jednotlivého kontrolného objektu by sa mali prejaviť v TK na ACS tohto objektu.
1.3. Požiadavky na AC vo výške stanovenej v tomto štandarde môžu byť zahrnuté do úlohy na navrhovanie novovytvoreného objektu automatizácie. V tomto prípade sa TK na rečníkoch nevyvíja.
1.4. Požiadavky obsiahnuté v TK na AÚ by mali zodpovedať modernej úrovni rozvoja vedy a techniky a nie na výnos podobných požiadaviek pre najlepšie moderné domáce a zahraničné analógy. Požiadavky uvedené v TK na AÚ by nemali obmedziť vývojára systému pri hľadaní a implementácii najúčinnejšej technickej, uskutočniteľnosti a iných riešení.
1.5. TK na AÚ je vyvinutý na základe zdrojových údajov vrátane tých, ktoré sú obsiahnuté v konečnej dokumentácii štádia "štúdie a odôvodnenie vytvárania AC", založená GOST 24.601.
1.6. TK na AU obsahuje iba tie požiadavky, ktoré dopĺňajú požiadavky na systémy tohto druhu (ACS, CAD, ANSI, atď.) Obsiahnuté v súčasnom NTD a sú určené špecifikámi konkrétneho objektu, pre ktorý je systém vytvorený .
1.7. Zmeny v TK na AÚ sú vydané dodatkom alebo podpísaným zákazníkom a vývojárskym protokolom. Dodatok alebo špecifikovaný protokol je neoddeliteľnou súčasťou TK na AU. Na titulnej strane by TK na AU by mal byť vstupom "Skončuje ...".
2. Zloženie a obsah
2.1. TK na AC obsahuje nasledujúce časti, ktoré možno rozdeliť na podsekcie:
- 1) Všeobecné informácie;
- 2) vymenovanie a účel vytvorenia (rozvoja) systému;
- 3) Charakteristiky automatizačných predmetov;
- 4) Systémové požiadavky;
- 5) Zloženie a obsah práce na vytváraní systému;
- 6) Postup monitorovania a prijímania systému;
- 7) Požiadavky na zloženie a udržiavanie práce na prípravu automatizačného zariadenia na vstup do systému;
- 8) Požiadavky na dokumentáciu;
- 9) Zdroje rozvoja.
V TK na AU môžu byť zahrnuté aplikácie.
2.2. V závislosti od typu, cieľa, špecifických vlastností objektu automatizácie a podmienok prevádzky systému, je povolené vydať časti TK vo forme žiadostí, zaviesť dodatočné, eliminovať alebo zjednotiť pododdiely TK.
TK na strane systému nezahŕňa časti, ktoré duplikujú obsah sekcií TK na AU ako celok.
2.3. Časť "Všeobecná" označuje:
- 1) Úplný názov systému a jej podmienené označenie;
- 2) šifrovanie témy alebo šifru (číslo) zmluvy;
- 3) názov podnikov (združenia) vývojára a zákazníka (používateľa) systému a ich podrobnosti;
- 4) Zoznam dokumentov, na základe ktorých je systém vytvorený, kým a ak sú tieto dokumenty schválené;
- 5) Plánovaný čas začiatku a ukončenia práce na vytváraní systému;
- 6) Informácie o zdrojoch a postupu na financovanie práce;
- 7) Postup registrácie a prezentácie výsledkov práce na vytváraní systému (jeho častí), na výrobu a uvedenie do prevádzky jednotlivých fondov (technické, softvér, informácie) a softvérové \u200b\u200ba technické (softvérové \u200b\u200bmetodické) systémy systém.
2.4. Časť "Menovanie a ciele vytvárania (rozvoja) systému" pozostáva zo podsekcií:
- 1) Účel systému;
- 2) Ciele tvorby systému.
2.4.1. Pododdiel "Účel systému" označuje typ automatizovanej aktivity (riadenie, dizajn, atď.) A zoznam automatizačných objektov (objektov), \u200b\u200bna ktorých sa predpokladá, že sa použije.
Pre ACS, navyše uveďte zoznam automatizovaných orgánov (položiek) manažmentu a spravovaných objektov.
2.4.2. V časti "Systém tvoriaci cieľ" pododdiel a požadované hodnoty technických, technologických, výrobných a ekonomických alebo iných ukazovateľov objektu automatizácie, ktoré by sa mali dosiahnuť v dôsledku vytvorenia AC a uviesť kritériá pre Posúdenie dosiahnutia cieľov vytvárania systému.
2.5. V časti "Charakteristika objektu automatizácie":
- 1) Stručné informácie o objekte automatizácie alebo odkazov na dokumenty obsahujúce takéto informácie;
- 2) Informácie o prevádzkových podmienkach automatizácie a environmentálnych charakteristík.
PoznámkaV prípade CAPR, okrem toho sú uvedené hlavné parametre a charakteristiky dizajnových predmetov.
2.6. Sekcia "Systémové požiadavky" pozostáva z nasledujúcich pododdielov:
- 1) Požiadavky na systém ako celok;
- 2) Požiadavky na funkcie (úlohy) vykonávané systémom;
- 3) Požiadavky na typy kolaterálu.
Zloženie požiadaviek na systém zahrnuté v tejto časti TK na AU sa stanoví v závislosti od druhov, cieľa, špecifických funkcií a podmienok pre fungovanie konkrétneho systému. V každej pododdiele odkazy na existujúce NTD, ktoré určujú požiadavky na systémy zodpovedajúcich druhov.
2.6.1. V pododdiele "Požiadavky na systém ako celok" Uveďte: \\ t
- požiadavky na štruktúru a prevádzku systému;
- požiadavky na počet a kvalifikáciu systémového personálu a jeho pracovného režimu;
- ukazovatele cieľa;
- požiadavky na spoľahlivosť;
- bezpečnostné požiadavky;
- požiadavky na ergonómiu a technickú estetiku;
- požiadavky na prepravovateľnosť pre mobilné reproduktory;
- požiadavky na prevádzku, údržbu, opravu a skladovanie systémových komponentov;
- požiadavky na ochranu informácií od neoprávneného prístupu;
- požiadavky na bezpečnosť informácií počas nehôd;
- požiadavky na ochranu pred vplyvom vonkajších vplyvov;
- požiadavky na čistotu patentov;
- požiadavky na štandardizáciu a zjednotenie;
- Ďalšie požiadavky.
2.6.1.1. V požiadavkách na štruktúru a prevádzku systému, olovo:
- 1) Zoznam subsystémov, ich účel a hlavné charakteristiky, požiadavky na počet úrovní hierarchie a stupeň centralizácie systému;
- 2) Požiadavky na metódy a prostriedky komunikácie pre výmenu informácií medzi komponentmi systému;
- 3) Požiadavky na charakteristiky vzťahov systému vytvorených so susednými systémami, požiadavky na jeho kompatibilitu, vrátane pokynov na metódach zdieľania informácií (automaticky, odosielanie dokumentov telefonicky atď.);
- 4) Požiadavky na režimy prevádzky systému;
- 5) požiadavky na diagnostiku systému;
- 6) Vývojové vyhliadky, aktualizácie systému.
2.6.1.2. V požiadavkách na číslo a kvalifikáciu personálu na AU, olovo:
- požiadavky na počet pracovníkov (používateľov) rečníkov;
- požiadavky na personálne kvalifikácie, postup jeho prípravy a kontroly vedomostí a zručností;
- požadovaný spôsob prevádzky pracovníkov AC.
2.6.1.3. V požiadavkách na indikátory zadania, ACS vedú hodnoty parametrov charakterizujúcich stupeň zhody jeho zamýšľaného systému.
Pre ACS označuje:
- stupeň prispôsobivosti systému zmenám v metódach procesov a riadenia na odchýlky parametrov riadiaceho objektu;
- prípustné limity modernizácie a rozvoja systému;
- pravdepodobnostné časové charakteristiky, za ktorých sa cieľový systém uloží.
2.6.1.4. V požiadavkách na spoľahlivosť zahŕňajú:
- 1) zloženie a kvantitatívne hodnoty indikátorov spoľahlivosti pre systém ako celok alebo jeho subsystémy;
- 2) zoznam núdzových situácií, v ktorých musia byť regulované požiadavky na spoľahlivosť a hodnoty zodpovedajúcich ukazovateľov;
- 3) Požiadavky na spoľahlivosť technických prostriedkov a softvéru;
- 4) Požiadavky na metódy hodnotenia a kontrolu indikátorov spoľahlivosti v rôznych štádiách vytvárania systému v súlade s aktuálnymi regulačnými dokumentmi.
2.6.1.5. Bezpečnostné požiadavky zahŕňajú bezpečnostné požiadavky na inštaláciu, uvedenie do prevádzky, prevádzky, údržby a opravy technických prostriedkov systému (ochrana pred elektrickým prúdom, elektromagnetickými poliami, akustickým hlukom atď.), Podľa prípustných úrovní osvetlenia, vibrácií a hluku zaťaženia.
2.6.1.6. Požiadavky na ergonómiu a technickú estetiku zahŕňajú ukazovatele AÚ, pýtajú sa potrebnú kvalitu interakcie ľudí so strojom a komfortom pracovných podmienok.
2.6.1.7. Pre mobilných reproduktorov zahŕňajú požiadavky na dopravu konštruktívne požiadavky, ktoré zabezpečujú prepravovateľnosť systému systému, ako aj požiadavky na vozidlá.
2.6.1.8. Požiadavky na prevádzku, údržbu, opravu a skladovanie zahŕňajú:
- 1) Podmienky a predpisy (nariadenie) operácie, ktoré by mali zabezpečiť používanie technických prostriedkov (TC) systémy so špecifikovanými technickými ukazovateľmi, vrátane typov a frekvencie údržby systému systému alebo prípustnosť práce bez výživného;
- 2) predbežné požiadavky na prípustné oblasti, aby sa prispôsobili personálu a TC systému, na parametre siete napájania atď.;
- 3) požiadavky na množstvo, kvalifikácia servisného personálu a spôsoby jeho práce;
- 4) Požiadavky na podmienky zloženia, umiestnenia a skladovania súborov náhradných výrobkov a spotrebičov;
- 5) Požiadavky na služby.
2.6.1.9. V požiadavkách na ochranu informácií pred neoprávneným prístupom požiadavky stanovené v NTD pôsobení v priemysle zákazníka (kancelária).
2.6.1.10. V požiadavkách na bezpečnosť informácií existuje zoznam udalostí: nehody, zamietnutia technických prostriedkov (vrátane straty energie) atď., V ktorých by sa mala zachovať bezpečnosť informácií.
2.6.1.11. V požiadavkách na ochranu proti vonkajším vplyvom:
- 1) Požiadavky na rádiovú elektronickú ochranu AC;
- 2) Požiadavky na vytrvalosť, stabilitu a silu vonkajších vplyvov (aplikačné prostredie).
2.6.1.12. Požiadavky na čistotu patentu označujú zoznam krajín, v súvislosti s ktorými by sa mala zabezpečiť patentová čistota systému a jej časti.
2.6.1.13. V požiadavkách na normalizáciu a zjednotenie zahŕňajú: ukazovatele, ktorými sa ustanovujú požadovaný stupeň používania štandardných, jednotných metód vykonávacích funkcií (úlohy) systému, ktorý poskytuje softvér, typické matematické metódy a modely, typické riešenia dizajnu, jednotné formy zavedených dokumentov Podľa GOST 6.10.1, Union-Unifiers of Technické a ekonomické informácie a klasifikátory iných kategórií v súlade s rozsahom ich uplatňovania požiadavky na používanie typických automatizovaných pracovísk, komponentov a komplexov.
2.6.1.14. Ďalšie požiadavky zahŕňajú:
- 1) požiadavky na vybavenie systému pre vzdelávacie zariadenia pre vzdelávanie zamestnancov (simulátory, iné zariadenia podobného účelu) a dokumentáciu na nich;
- 2) Požiadavky na servisné zariadenia, znamená kontrolu prvkov systému;
- 3) Systémové požiadavky spojené so špeciálnymi prevádzkovými podmienkami;
- 4) Osobitné požiadavky podľa uváženia systému developer alebo zákazníka.
2.6.2. V pododdiele "Požiadavka na funkcie (úlohy)" vykonáva systém, olovo:
pri vytváraní systému v dvoch alebo viacerých frontoch - zoznam funkčných subsystémov, jednotlivých funkcií alebo úloh, vstúpil do konania v 1. a nasledujúcich frontoch;
2.6.3. V pododdiele "Požiadavky na typy kolaterálu" v závislosti od typu systému si vyžaduje požiadavky na matematické, informačné, jazykové, softvérové, technické, metrologické, organizačné, metodické a iné typy systémovej podpory.
2.6.3.1. Pre matematickú podporu systému, požiadavky na zloženie, rozsah pôsobnosti (obmedzenia) a metódy, použitie v systéme matematických metód a modelov, typických algoritmov a algoritmov, ktoré sa majú vyvinúť.
2.6.3.2. Pre systém podpory informácií sa vyžadujú požiadavky: \\ t
- 1) na zloženie, štruktúru a metódy organizovania údajov v systéme;
- 2) na informačnú výmenu medzi komponentmi systému;
- 3) na kompatibilitu informácií s priľahlými systémami;
- 4) o využívaní verejných a registrovaných republikánskych, sektorových klasifikátorov, jednotných dokumentov a klasifikátorov pôsobiacich v tomto podniku;
- 5) O používaní systémov správy databáz;
- 6) na štruktúru procesu zhromažďovania, spracovania, prenosu údajov v zastúpení systému a údajov;
- 7) chrániť údaje pred zničením počas nehodov a porúch v zdrojovom napájaní systému;
- 8) kontrolovať, skladovanie, aktualizáciu a zhodnocovanie údajov;
- 9) K postupu pri výbere právnej sily na dokumenty vypracované technickými prostriedkami AC (v súlade s GOST 6.10.4).
2.6.3.3. Pre jazykový systém systém poskytuje požiadavky na použitie v systéme programovacích jazykov na vysokej úrovni, jazykoch používateľa a technických systémov, ako aj požiadaviek na kódovanie údajov a dekódovanie dát, na vstupné jazyky údajov, manipulačné dátové jazyky, nástroje opisujúca oblasť (objekt automatizácie) na metódy organizácie dialógu.
2.6.3.4. Pre softvérový softvér, zoznam zakúpeného softvéru, ako aj požiadavky:
- 1) na nezávislosť softvéru z použitých SVT a prevádzkového prostredia;
- 2) K kvalite softvéru, ako aj metódam zabezpečenia a kontroly;
- 3) Podľa potreby prispôsobiť novo vyvinutý softvér s algoritmom a programovým fondom.
2.6.3.5. Na technickú podporu systému sa vyžadujú požiadavky: \\ t
- 1) na typy technických prostriedkov, vrátane typov komplexov technických zariadení, softvérových a technických komplexov a iných komponentov, ktoré sú povolené používať v systéme;
- 2) na funkčné, konštruktívne a prevádzkové charakteristiky technickej podpory systému.
2.6.3.6. Požiadavky na oltrologickú podporu: \\ t
- 1) predbežný zoznam meracích kanálov;
- 2) požiadavky na presnosť merania parametrov a (alebo) metrologické charakteristiky meracích kanálov;
- 3) Požiadavky na metrologickú zlučiteľnosť systémových technických prostriedkov;
- 4) zoznam kontrolných a výpočtových kanálov systému, pre ktorý je potrebné vyhodnotiť charakteristiky presnosti;
- 5) Požiadavky na metrologickú podporu technického a softvéru, ktoré sú súčasťou meracích kanálov systému, fondov, vstavanej kontroly, metrologickej vhodnosti meracích kanálov a meracích prístrojov používaných v uvedení do prevádzky a testovanie systému;
- 6) Typ metrologickej certifikácie (štátnej alebo rezort), ktorý poukazuje na postup jeho vykonávania a organizácií vykonávaných certifikáciou.
2.6.3.7. Pre organizačnú podporu vedie k požiadavkám:
2.6.3.8. Pre metodickú podporu vedie CAD k zloženiu systému regulačnej a technickej dokumentácie systému (zoznam noriem, ktoré sa používajú vo svojej prevádzke, normách, metódach atď.).
2.7. "Zloženie a udržiavanie práce na vytváraní (rozvoja) systému" by mala obsahovať zoznam etáp a etáp práce na vytvorení systému v súlade s GOST 24.601, načasovaním ich implementácie, zoznam organizácií - Pracovníci, odkazy na dokumenty, ktoré potvrdzujú súhlas týchto organizácií, aby sa zúčastnili na vytváraní systému, alebo záznam definujúci zodpovedný (zákazník alebo developer) na vykonávanie týchto prác.
Táto časť tiež vedie:
- 1) Zoznam dokumentov podľa GOST 34.201-89 prezentovaný na konci príslušných etapov a štádií práce;
- 2) Forma a postup vykonávania preskúmania technickej dokumentácie (štádium, štádium, rozsah overiteľnej dokumentácie, odbornej organizácie);
- 3) pracovný program zameraný na zabezpečenie požadovanej úrovne spoľahlivosti systému, ktorý sa vyvíja (v prípade potreby);
- 4) Zoznam práce na metrologickej podpore vo všetkých fázach vytvorenia systému označujúceho ich načasovanie a výkonné organizácie (v prípade potreby).
2.8. V časti "Problém riadiaceho a prijatia systému" označuje:
- 1) druhy, zloženie, objem a spôsoby testovania systému a jeho komponentov (typy skúšok v súlade so súčasnými normami, ktoré sa rozprestierajú na vyvinuté systém);
- 2) Všeobecné požiadavky na prijatie práce na etapách (zoznam zúčastnených podnikov a organizácií, miesta a termínov), postup koordinácie a schvaľovania dokumentácie o prijatí;
- H) štatút prijatia komisie (štátna, medzisústredina, rezort).
2.9. V sekcii "Požiadavky na zloženie a údržbu prác na prípravu automatizačného zariadenia na vstup do systému je potrebné pri príprave automatizačného zariadenia vykonávať zoznam základných činností a ich výkonných umelcov, ktoré by sa mali vykonávať pri príprave automatizácie skutočná aktivácia.
Medzi základné aktivity patrí:
- 1) prináša informácie prichádzajúce do systému (v súlade s požiadavkami na informácie a jazykovej podpory) do formulára vhodného na spracovanie pomocou počítačov;
- 2) Zmeny, ktoré musia byť implementované v objekte automatizácie;
- 3) Vytvorenie podmienok pre prevádzku objektu automatizácie, podľa ktorého je splnenie vytvoreného systému zaručené požiadavkám obsiahnutým v TK;
- 4) vytvorenie jednotiek a služieb potrebných na fungovanie;
- 5) Podmienky a postupy náboru štátov a odbornej prípravy zamestnancov.
Napríklad pre ACS vedie:
- zmeny aplikovaných metód riadenia;
- vytvorenie podmienok pre prevádzku komponentov ACS, podľa ktorého je zaručená súlad systému s požiadavkami obsiahnutými v TK.
2.10. V časti "Požiadavky na dokumentáciu" vedie:
- 1) Systém odsúhlasený vývojárom a zákazníkom systému na vypracovanie súprav a druhov dokumentov zodpovedajúcich požiadavkám GOST 34.201-89 a NTD sektorov zákazníka;
Zoznam dokumentov vyrobených na strojových médiách;
Požiadavky na dokumentáciu mikrofilmovania; - 2) Požiadavky na dokumentovanie prvkov komponentov prebiehateľného použitia v súlade s požiadavkami ECCD a ECPD;
- 3) V prípade neexistencie štátnych noriem, ktoré určujú požiadavky na dokumentovanie prvkov systému, ďalej zahŕňajú požiadavky na zloženie a obsah takýchto dokumentov.
2.11. Časť "Zdroje rozvoja" by mali zahŕňať dokumenty a informačné materiály (štúdia uskutočniteľnosti, správy o ukončených výskumných práci, informačné materiály pre domáce, cudzie a analógy systémy atď.), Na základe ktorých bol TK vyvinutý a ktorý by sa mali používať pri vytváraní systému.
2.12. TK na AU v prítomnosti schválených techník zahŕňa aplikácie obsahujúce:
- 1) výpočet očakávanej účinnosti systému;
- 2) Hodnotenie vedeckej a technickej úrovne systému.
Aplikácie zahŕňajú TK na AÚ po dohode medzi vývojárom a zákazníkom systému.
3. Pravidlá registrácie
3.1. Odseky a pododdiely TK na AÚ by mali byť umiestnené spôsobom predpísaným v časti. 2 tohto štandardu.
3.2. TK na AU sa vydáva v súlade s požiadavkami GOST 2.105.95 na listoch listov A4 podľa GOST 2.301 bez rámca, hlavného nápisu a ďalšieho grafu.
Čísla listov (stránok) sú vyplnené z prvého hárku podľa titulnej stránky, v hornej časti listu (nad textom, v strede) po označení TK Code na AU.
3.3. Hodnoty ukazovateľov, noriem a požiadaviek označujú spravidla s obmedzenými odchýlkami alebo maximálnymi a minimálnymi hodnotami. Ak tieto ukazovatele, normy, požiadavky sú jednoznačne upravené NTD, TK na AÚ by mal poskytnúť odkaz na tieto dokumenty alebo ich oddiely, ako aj dodatočné požiadavky, ktoré zohľadňujú charakteristiky vytvoreného systému. Ak sa počas rozvoja TK na AÚ môžu stanoviť špecifické hodnoty ukazovateľov, noriem a požiadaviek, malo by sa zaznamenať postup na vytvorenie a koordináciu týchto ukazovateľov, noriem a požiadaviek: \\ t
"Konečná požiadavka (hodnota) je špecifikovaná v procese ... a koordinuje protokol s ... v štádiu ...".
Zároveň sa text TK na AC zmení neprispieva.
3.4. Na titulnej strane sa umiestnia podpisy zákazníka, vývojár a zodpovedajúce organizácie, ktoré upevňujú tesnenie pečiatky. V prípade potreby sa titulná stránka vypracuje na viacerých stránkach. Podpisy vývojárov TK na AÚ a úradníkov zapojených do koordinácie a zváženia projektu TK na AÚ sú uvedené na posledný list.
Forma titulnej list TK na AU je uvedený v dodatku 2. Forma posledného listu TK na AÚ je uvedený v dodatku 3.
3.5. Ak je to potrebné, na titulnej strane, TK na AU je povolené umiestniť kódy inštalované v priemysle, napríklad: sup tajomstvo, pracovný kód, registračné číslo TK atď.
3.6. Titulná strana doplnku k TK na AÚ je vypracovaná analogicky k titulu technickej úlohy. Namiesto názvu "Technická úloha", "doplnok č. ... TK na AC ...".
3.7. Na nasledujúcich listoch doplnku k TK je základňa umiestnená na AÚ na zmenu, obsah zmien a odkazov na dokumenty, podľa ktorých sa tieto zmeny vykonávajú.
3.8. Ak opisujete text doplnku k TK, je potrebné uviesť čísla príslušných položiek, pododsekov, tabuľky hlavného TK na AC atď. A aplikovať slová: "nahradiť", "pridať", "Vylúčiť", "State v novom vydaní". \\ T
Postup rozvoja, koordinácie a schválenia TK na AC
1. Projekt TK na AC vyvíja organizáciu pre rozvojovú rozvojovú organizáciu s účasťou zákazníka na základe technických požiadaviek (aplikácií, taktických a technických úloh atď.).
S konkurenčnou organizáciou práce, varianty projektu TK na AC posudzujú zákazník, ktorý je buď uprednostňovanou možnosťou, alebo na základe porovnateľnej analýzy pripravuje sa s účasťou budúceho developera konečnej verzie AC tk na AC.
2. Potreba harmonizovať projekt TK na AÚ so štátnymi dozornými orgánmi a inými zainteresovanými organizáciami určujú spoločne zákazníka systému a vývojára projektu TK na AÚ, \\ t
Práca na koordinácii projektu TK na AC je spoločne implementovaná vývojárom TK na AC a zákaznícky systém, každý v organizáciách svojej služby (oddelenie).
3. Schválenie projektu TK na AÚ v každej organizácii by nemal presiahnuť 15 dní odo dňa jej prijatia. Odporúča sa poslať schvaľovaniu inštancií projektu TK na AÚ (kópiách) súčasne vo všetkých organizáciách (divíziách).
4. Pripomienky k projektu TK na AÚ by sa mali predložiť technickým odôvodnením. Rozhodnutia o pripomienkach by mali byť prijatý vývojárom projektu TK na AÚ a zákazníka systému pred schválením TK na AÚ.
5. Ak sa nezhody medzi vývojárom a zákazníkom (alebo inými zainteresovanými organizáciami) vznikli pri schvaľovaní projektu TK na rečníkov (alebo iných zainteresovaných organizáciách), potom je vypracovaný nesúhlasný protokol (ľubovoľná forma) a osobitné rozhodnutie je predpísaným spôsobom.
6. Koordinácia projektu TK na AÚ je povolená vykonať samostatný dokument (list). V tomto prípade pod vaulture "koordinovaný" vykonajte odkaz na tento dokument.
7. Vyhlásenie TK na AÚ vykonávajú vodcovia podnikov (organizácie) developerského a zákazníckeho systému.
8. TK na AÚ (dodatok k TK) Pred prevodom na jeho schválenie by mali kontrolovať Normočlánkovou službou organizácie - vývojár TK av prípade potreby vystavený metrologickému vyšetreniu.
9. Kópie schválené spoločnosťou TK na AÚ na 10-dňový termín po schválení zasiela vývojár TK na účastníkoch AC na vytváranie systému.
10. Koordinácia a schvaľovanie dodatkov k TK na AÚ sa vykonáva spôsobom, ktorý predpísaný pre TK na AÚ.
11. Zmeny TK na AÚ nie sú povolené uplatniť po predložení systému alebo jeho frontu o akceptačných testoch.
12. Registrácia, účtovníctvo a skladovanie TK na AÚ a dodatky k nej sa vykonávajú v súlade s požiadavkami GOST 2.501.
Forma titulu list TK na AU
________________________________________________________
|
názov Schváliť Hlava Osobný podpis Vytlačiť dátum Schváliť Hlava Osobný podpis Vytlačiť dátum
názov AC.
názov objektu
skrátený Technická úloha Na ____ listoch Konať Dohodnutý Hlava Osobný podpis Vytlačiť dátum |
Forma posledného listu TK na AU
(TK kód)Dohodnuté
Dodatok 4.
Referencia
Predpisy o vytvorení jednotného súboru štandardov automatizovaných systémov
1. Orientálne pozadie pozadia stvorenia
1.1. Tvorba a implementácia automatizovaných systémov rôznych tried a vymenovaní sa vykonáva v mnohých priemyselných odvetviach v regulačnej a technickej dokumentácii, ktorá stanovuje rôzne organizačné a metodické a technické normy, pravidlá a predpisy, ktoré bránia integrácii systémov a ich účinné spoločné fungovanie .
1.2. V období prijatia štátnou normou ZSSR sa rozhodnutia o zlepšovaní medzisektorových súborov noriem prevádzkovali tieto komplexy a systémy noriem, ktoré stanovujú požiadavky na rôzne typy rečníkov:
- 1) Jednotný systém štandardov automatizovaných riadiacich systémov (24. systém) množiteľnosti na ACS, ACS, TP ACS a iných organizačných a ekonomických systémoch;
- 2) Súbor noriem (systém 23501); pre automatizované dizajnové systémy;
- 3) Štvrtá skupina 14. systému štandardov siahajúcich sa na automatizované technologické systémy.
1.3. Prax uplatňovania noriem pre ACS, CAD, ACS TP, ASTPP ukázala, že používajú rovnaké koncepčné prístroje, existuje mnoho spoločných normalizačných objektov, ale požiadavky noriem nie sú dohodnuté medzi sebou, existujú rozdiely v zložení a Údržba prác, rozdiely v označení, zložení, obsahu a dizajne dokumentov atď.
1.4. Na pozadí nedostatku jednej technickej politiky v oblasti vytvárania rôznych štandardov neexistovali žiadna široká kompatibilita AC s ich interakciou, neumožňoval systému replikovať rozvoj sľubných oblastí používania výpočtových zariadení .
1.5. V súčasnosti sa uskutočňuje prechod na vytvorenie komplexných rečníkov (v zahraničí systému CAD - sám), vrátane ACS ACS prostredníctvom technologických procesov a výroby, CAD Constructor, CAD Technológov, ASNI atď. Využívanie konfliktných pravidiel pri vytváraní takýchto systémov vedie k zníženiu kvality, zvýšenie nákladov na prácu, sprísnenie databázy AC na akciu.
1.6. Zjednotený súbor noriem a usmernení by sa mal uplatňovať na automatizované systémy na rôzne účely: AsNI, CAD, OASU, ASUP, ASUTP, ASUSKSKO, OPATRENIE, ASTPP, vrátane ich integrácie.
1.7. Pri vývoji medziodvetvových dokumentov by sa mali zohľadniť tieto vlastnosti rečníkov ako objekty štandardizácie: \\ t
- 1) Technická úloha je hlavným dokumentom, v súlade s ktorým je vytvorenie AC a prijatie zo strany zákazníka;
- 2) AKO spravidla vytvorte projekt s kompletným súborom výrobkov sériovej a jednotkovej výroby a výstavby, inštalácie, uvedenia do prevádzky a počiatočnej práce potrebnej na aktiváciu AC;
- 3) Vo všeobecnom prípade AC (AC subsystém) sa skladá zo softvéru a technických (PTC), metodických komplexov (PMK) a komponentov technickej, softvérovej a informačnej podpory.
Komponenty týchto druhov kolaterálu, ako aj PMK a PTK, by sa mali vyrábať a dodávané ako výroba a technické výrobky.
Komponenty môžu byť zahrnuté do AC ako nezávislé časti alebo môžu byť kombinované do komplexov; - 4) Vytvorenie ACS v organizáciách (podnikoch) si vyžaduje osobitné školenie používateľov a servisných pracovníkov;
- 5) Fungovanie reproduktorov a komplexov je zabezpečené súborom organizačných a metodických dokumentov, ktoré sa posudzuje v procese vytvárania zložiek právnych, metodických, jazykových, matematických, organizačných a iných druhov kolaterálu. Samostatné riešenia získané v procese vývoja týchto kolaterálov možno realizovať vo forme zložiek technickej, softvérovej alebo informačnej podpory;
- 6) Spoločné fungovanie a interakciu rôznych systémov a komplexov sa vykonáva na základe počítačových sietí.
Špecifikácie a dohody prijaté pre miestne počítačové siete sú potrebné na zabezpečenie kompatibility systémov, komplexov a komponentov.
2. Vzťah ex AC s inými systémami a súbormi noriem
2.1. Štandardizácia v oblasti AC je neoddeliteľnou súčasťou práce na zovšeobecných "informačných technológiách".
2.2. Zjednotený súbor štandardov riadiacich dokumentov o automatizovaných systémoch spolu s inými systémami a komponentmi noriem by mali tvoriť kompletnú regulačnú a technickú podporu pre vytvorenie a prevádzku AC.
2.3. ACS by mali pokrývať automatizovaný systém pre smer štandardizácie a distribuovať tradičné pokyny normalizácie na softvérových a technických, softvérových metodických komplexoch a automatizovaných systémoch ako celku.
2.4. Pokyny a ciele normalizácie s normatívnou a technickou podporou procesov tvorby a prevádzky AÚ sú zoskupené takto: \\ t
- 1) Vytvorenie technických požiadaviek na výrobky;
- 2) Regulácia skúšobných metód a certifikačných pravidiel a certifikácia výrobkov;
- 3) regulácia pravidiel a postupov rozvoja;
- 4) zriadenie pravidiel dokumentácie;
- 5) Kompatibilita;
- 6) Regulácia organizačných a metodických otázok systému fungovania systému.
Pokyny 1-4 sú tradičné vo vývoji, výrobe a dodávke výrobkov. Smery 5, 6 sú špecifické a prietok z funkcií, ktoré sú obsiahnuté v AU.
2.5. Bezpečnosť AU ako celku a ich zložky regulačnej a technickej dokumentácie v rámci prijatých oblastí a úloh normalizácie je odlišná.
Súčasti technických, softvérových a informačných podpory, ako výroba a technické výrobky, sú považované za dizajn, softvérové \u200b\u200ba informačné produkty. Tieto výrobky podliehajú existujúcim normám ECCD, SRPP, ECPD, SPI, DRD, klasifikátory a kodifikátory funkcií, komplexov štandardov "OTT", "testovacie metódy", "TU", ako aj OTD zákazníka.
2.5.1. Celý životný cyklus projektových výrobkov je plne vybavený regulačnou a technickou dokumentáciou pôsobiacou v strojárstve a výrobe prístroja.
2.5.2. Softvérové \u200b\u200bprodukty sú poskytované NTD, ktoré je zahrnuté v ECAP a OTD zákazníka. Distribučná oblasť týchto NTD by sa však mala rozšíriť tak, aby odrážala otázky súvisiace s vývojom, tvorbou, distribúciou a prevádzkou softvérových produktov.
2.5.3. Informačné produkty v súčasnosti neposkytujú NTD, hoci jednotlivé otázky boli vypracované v rámci USP, klasifikátorov a technických a ekonomických informačných kodifikátorov.
2.6. Softvér a softvér a metodické komplexy sú považované za komplexné produkty, ktoré nemajú žiadne analógy v strojárstve. Vzhľadom na stav PTK a PMK ako výrobu a technické výrobky by mali byť pravidlá a postupy pre ich rozvoj podobné požiadavkám stanoveným normami rozvoja a výrobného systému (SRPP).
Prednáška 15. Vývoj technických špecifikácií na vytvorenie informačného systému
Technická úloha na vytvorenie IP.
2. Zloženie a obsah TK
Výpis z GOST 34.602-89 Technická úloha na vytvorenie informačného systému je odporúčaný, ktorý určuje zloženie a obsah TK. V priebehu realizácie Kirgizska rozumný Zmeňte zloženie a obsah TK.
TK na OP je hlavným dokumentom definujúcim požiadavky a postup na vytváranie (rozvoj alebo modernizáciu - ďalšie vytvorenie) automatizovaného systému, v súlade, s ktorým sa pri vstupe do činnosti vykonáva rozvoj IP a jeho prijatie.
Požiadavky zahrnuté do TK na IC by mali zodpovedať modernej úrovni rozvoja vedy a techniky a nie vzdať podobných požiadaviek na najlepšie moderné domáce a zahraničné analógy
V závislosti od typu, cieľa, špecifických vlastností objektu automatizácie a podmienok prevádzky systému, je povolené vydať časti TK vo forme žiadostí, zaviesť dodatočné, eliminovať alebo zjednotiť pododdiely TK.
Zloženie a obsah TK
1. V sekcii "Všeobecné informácie" Uveďte: Úplný názov systému a jeho podmienené označenie; názov podnikov (asociácie) developer a zákazníka (používateľa) systému a ich detaily; plánovaný čas začiatku a ukončenia práce na vytváraní systému .
2. Sekcia "Účel a účel vytvárania (vývoja) systému"pozostáva zo podsekcií:
"Systémový účel" označujú typ automatizovanej aktivity (riadenie, dizajn, atď.) A zoznam automatizačných objektov, na ktorých sa predpokladá, že sa použije.
"Systém vytváranie cieľov" vedie názvy a požadované hodnoty technických, technologických, výrobných a ekonomických a iných ukazovateľov objektu automatizácie, ktoré sa musia dosiahnuť v dôsledku vytvorenia OP, uveďte kritériá na posúdenie dosiahnutia vytvárania objektu systému.
V kapitole "Charakteristiky objektu automatizácie" Tlač na objekty automatizácie alebo odkazy na dokumenty obsahujúce takéto informácie a informácie o prevádzkových podmienkach automatizácie objektov a environmentálnych charakteristík.
3. sekcia "Požiadavky na systém" Pozostáva z nasledujúcich pododdielov: požiadavky na systém ako celok; Požiadavky na funkcie (úlohy) vykonávané systémom; Požiadavky doplnkov.
Zloženie požiadaviek na systém zahrnuté v tejto časti TK na IP je nastavený v závislosti od druhov, cieľa, špecifických funkcií a podmienok pre fungovanie konkrétneho systému.
V podsekcii "Systémové požiadavky ako celok" označujú: \\ t
požiadavky na štruktúru a prevádzku systému;
požiadavky na počet a kvalifikáciu systémového personálu a jeho pracovného režimu;
ukazovatele cieľa;
požiadavky na spoľahlivosť;
bezpečnostné požiadavky;
požiadavky na ergonómiu a technickú estetiku;
požiadavky na prepravovateľnosť pre mobil je;
požiadavky na prevádzku, údržbu, opravu a skladovanie systémových komponentov;
požiadavky na ochranu informácií od neoprávneného prístupu;
požiadavky na bezpečnosť informácií počas nehôd;
požiadavky na ochranu pred vplyvom vonkajších vplyvov;
požiadavky na štandardizáciu a zjednotenie;
Ďalšie požiadavky.
V požiadavkách na štruktúru a prevádzku systému, olovo:
1) Zoznam subsystémov, ich účel a hlavné charakteristiky, požiadavky na počet úrovní hierarchie a stupeň centralizácie systému;
2) Požiadavky na metódy a prostriedky komunikácie pre výmenu informácií medzi komponentmi systému;
3) Požiadavky na charakteristiky vzťahov systému vytvorených so susednými systémami, požiadavky na jeho kompatibilitu, vrátane pokynov na metódach zdieľania informácií (automaticky, odosielanie dokumentov telefonicky atď.);
4) Požiadavky na režimy prevádzky systému;
5) požiadavky na diagnostiku systému;
6) Vývojové vyhliadky, aktualizácie systému.
V požiadavkách na číslo a kvalifikácie personálu, IP vedie:
požiadavky na počet zamestnancov (používateľov) OP;
požiadavky na kvalifikáciu zamestnancov, postup pre jeho prípravu I kontrolovať vedomosti a zručnosti;
požadovaný spôsob prevádzky personálu IP.
V požiadavkách na účely postúpenia IPS Hodnoty parametrov charakterizujúcich stupeň zhody systému jeho účelu (stupeň prispôsobivosti systému zmenám v procesoch, metódy riadenia, na odchýlky parametrov kontrolného objektu; prípustné limity modernizácie a rozvoja systému; pravdepodobnostné charakteristiky, pod ktorými sa cieľový systém uloží).
V požiadavkách na spoľahlivosť zahŕňajú:
1) zloženie a kvantitatívne hodnoty indikátorov spoľahlivosti pre systém ako celok alebo jeho subsystémy;
2) zoznam núdzových situácií, v ktorých musia byť regulované požiadavky na spoľahlivosť a hodnoty zodpovedajúcich ukazovateľov;
3) Požiadavky na spoľahlivosť technických prostriedkov a softvéru;
4) Požiadavky na metódy hodnotenia a kontrolu indikátorov spoľahlivosti v rôznych štádiách vytvárania systému v súlade s aktuálnymi regulačnými dokumentmi.
Bezpečnostné požiadavky zahŕňajú Požiadavky na bezpečnosť pri inštalácii, uvedenie do prevádzky, prevádzky, údržby a opravy technických prostriedkov systému (ochrana pred elektrickým prúdom, elektromagnetickými poliami, akustickým hlukom atď.), Podľa prípustných úrovní osvetlenia, vibrácií a hluku zaťaženia.
V požiadavkách na ergonómiu a technickú estetiku Zahŕňa IP indikátory, ktoré špecifikujú potrebnú kvalitu interakcie ľudí so strojom a komfortom pracovných podmienok.
Pre mobilné IPS v požiadavkách na dopravu zahŕňajú Konštrukčné požiadavky, ktoré zabezpečujú prepravovateľnosť technických prostriedkov systému, ako aj požiadavky na vozidlá.
V požiadavkách na prevádzku, údržbu, opravy a skladovanie zahŕňajú:
1) Podmienky a predpisy (nariadenie) operácie, ktoré by mali zabezpečiť používanie technických prostriedkov (TC) systémy so špecifikovanými technickými ukazovateľmi, vrátane typov a frekvencie údržby systému systému alebo prípustnosť práce bez výživného;
2) predbežné požiadavky na prípustné oblasti, aby sa prispôsobili personálu a TC systému, na parametre siete napájania atď.;
3) požiadavky na množstvo, kvalifikácia servisného personálu a spôsoby jeho práce;
4) Požiadavky na podmienky zloženia, umiestnenia a skladovania súborov náhradných výrobkov a spotrebičov;
5) Požiadavky na služby.
V požiadavkách na ochranu informácií od neoprávneného prístupu Zahŕňa požiadavky stanovené v NTD pôsobení v priemysle zákazníka (kancelária).
V požiadavkách na bezpečnosť informácií Zoznam udalostí: nehody, zamietnutia technických prostriedkov (vrátane straty energie), pod ktorým by sa mala zabezpečiť bezpečnosť informácií v systéme.
V požiadavkách na ochranu proti vonkajším vplyvom:
1) Požiadavky na rádiovú elektronickú ochranu IP fondov;
2) Požiadavky na vytrvalosť, stabilitu a silu vonkajších vplyvov (aplikačné prostredie).
V patentových požiadavkách Uveďte zoznam krajín, v súvislosti s ktorými by sa mala poskytnúť patentová čistota systému a jej časti.
V požiadavkách na normalizáciu a zjednotenie zahŕňajú: Ukazovatele, ktorými sa ustanovujú požadovaný stupeň používania štandardných, jednotných metód vykonávacích funkcií (úlohy) systémov dodávaných softvérom, typickými matematickými metódami a modelmi, typickými dizajnovými riešeniami, jednotnými formami riadiacich dokumentov zriadených GOST 6.10.1, All-Union Klasifikátory pre technické a ekonomické informácie a klasifikátory iných kategórií v súlade s rozsahom ich uplatňovania požiadavky na používanie typických a automatizovaných pracovísk, komponentov a komplexov.
Ďalšie požiadavky zahŕňajú:
1) požiadavky na vybavenie systému pre vzdelávacie zariadenia pre vzdelávanie zamestnancov (simulátory, iné zariadenia podobného účelu) a dokumentáciu na nich;
2) Požiadavky na servisné zariadenia, znamená kontrolu prvkov systému;
3) Systémové požiadavky spojené so špeciálnymi prevádzkovými podmienkami;
4) Osobitné požiadavky podľa uváženia systému developer alebo zákazníka.
V pododdiele "Požiadavka na funkcie (úlohy)" vykonáva systém, olovo:
1) Pre každý subsystém, zoznam funkcií, úloh alebo ich komplexov (vrátane zabezpečenia interakcie častí systému), ktoré majú byť automatizované;
2) Dočasné nariadenia o vykonávaní každej funkcie, úloh (alebo komplexu úloh);
3) Požiadavky na kvalitu implementácie každej funkcie (úloha alebo problém úloh), forme zastúpenia výstupných informácií, charakteristík potrebnej presnosti a času vykonávania, požiadavky súčasného vykonávania skupiny funkcií, spoľahlivosť výsledkov výsledkov;
4) Zoznam a kritériá pre zlyhania pre každú funkciu, ktorá stanovuje požiadavky na spoľahlivosť.
V pododdiele "Požiadavky na typy podpory" v závislosti od typu systému sa vyžadujú požiadavky: \\ t
Pre matematickú podporu Systémy poskytujú požiadavky na zloženie, rozsah pôsobnosti (obmedzenia) a metódy, použitie v systéme matematických metód a modelov, typických algoritmov a algoritmov, ktoré sa majú vyvinúť.
Pre informačnú podporu: Systémy vedú požiadavky:
1) na zloženie, štruktúru a metódy organizovania údajov v systéme;
2) na informačnú výmenu medzi komponentmi systému;
3) na kompatibilitu informácií s priľahlými systémami;
4) o využívaní verejných a registrovaných republikánskych, sektorových klasifikátorov, jednotných dokumentov a klasifikátorov pôsobiacich v tomto podniku;
5) O používaní systémov správy databáz;
6) na štruktúru procesu zhromažďovania, spracovania, prenosu údajov v zastúpení systému a údajov;
7) chrániť údaje pred zničením počas nehodov a porúch v zdrojovom napájaní systému;
8) kontrolovať, skladovanie, aktualizáciu a zhodnocovanie údajov;
Pre jazykovú podporu Systémy poskytujú požiadavky na použitie v systéme programovacích jazykov na vysokej úrovni, jazykoch interakcie a technických zdrojov, ako aj požiadavky na kódovanie údajov a dekódovanie dát, jazykoch dát, jazykoch manipulácie s údajmi, nástroje na opis oblasti predmetu (Automation objekt), metódy organizovania dialógu.
Pre softvér Systémy vedú zoznam zakúpeného softvéru, ako aj požiadavky: na nezávislosť softvéru z použitého SVT a OS; kvality PS, ako aj spôsobov, ako zabezpečiť a kontrolovať; Potreba koordinovať novo vyvinutý PS s algoritmmi a programovým základom.
Pre technickú podporu Systémy vedú požiadavky:
1) na typy technických prostriedkov, vrátane typov komplexov technických zariadení, softvérových a technických komplexov a iných komponentov, ktoré sú povolené používať v systéme;
2) na funkčné, konštruktívne a prevádzkové charakteristiky technickej podpory systému.
V požiadavkách na metrologickú podporu viesť (Pre ekonómovi to nie je potrebné):
1) predbežný zoznam meracích kanálov;
2) požiadavky na presnosť merania parametrov a (alebo) metrologické charakteristiky meracích kanálov;
3) Požiadavky na metrologickú zlučiteľnosť systémových technických prostriedkov;
4) zoznam kontrolných a výpočtových kanálov systému, pre ktorý je potrebné vyhodnotiť charakteristiky presnosti;
Pre organizačnú podporu Uveďte požiadavky:
1) na štruktúru a funkcie jednotiek zapojených do fungovania systému alebo zabezpečenie prevádzky;
2) k organizácii fungovania systému a postup interakcie IP personálu a personálu objektu automatizácie;
3) Chrániť pred chybnými činnosťami systémového personálu.
Pre metodickú podporu Poskytujú požiadavky na zloženie regulačnej a technickej dokumentácie systému (zoznam noriem používaných vo svojej prevádzke, normách, technikách atď.).
Originalita OP, as, ako výroba a technické výrobky, vyjadrené vo svojej zložitosti, pri absencii noriem pre väčšinu typov postupov a diel, robí proces ich plánovania a navrhovania je veľmi zložitý a ťažký. V interakcii podniku s vývojárom akéhokoľvek účelu sú potrebné dva hlavné dokumenty na začatie pracovnej práce: zmluvu a technická úloha (TK). Kompilácia TK je samostatnou úlohou. Technická úloha, v skutočnosti, je dokument, ktorý odráža všetky želania zákazníka, malo by sa čo najpodrobnejšie vypracovať a špecifikovať všetky podrobnosti a víziu výsledku. Len na jeho základe bude určený skutočnosťou, že vývojári musia byť podnesení, preto by sa technická úloha mala vykonať podrobnejšie.
Pri navrhovaní akýchkoľvek informačných systémov sa vyžaduje ich podrobný opis. Na tieto účely môžete použiť rôzne metódy a metódy, ale najúčinnejším riešením je rozvíjať technickú úlohu (TK), ktorá opisuje ciele, úlohy, rozhranie a iné požiadavky na vyvinutý objekt.
Technická úloha je dokument, ktorý určuje ciele, požiadavky a hlavné zdroje potrebné na rozvoj OP. TK na OP je hlavným dokumentom definujúcim požiadavky a postup na vytváranie, rozvoj alebo modernizáciu OP, v súlade s ktorým sa vykonáva jeho vývoj, uvedenie do prevádzky a prijímania.
Úspech pri implementácii IP je správnosť úlohy so zákazníkom. Ak sú splnené všetky potrebné podmienky na písanie dobrých TK, výsledkom z očakávaných sa zmení na spustiteľné.
zákaznícke sily;
sily umelcov, ale v tomto prípade jeho povinnosti zadá návrh a vykonávanie testovania;
súťažní umelci, ktorých povinnosti zahŕňajú len písanie TK;
sily interpretov tretích strán.
Pre tých TK, ktoré sú napísané Dodávateľom, existuje niekoľko regulačných dokumentácií:
GOST 21.408-93 "Pravidlá vykonávania pracovnej dokumentácie automatizácie technologických procesov";
GOST 34.201-89 "Typy, úplnosť a označenie dokumentov pri vytváraní automatizovaných systémov";
GOST 24.703-85 "Modelové dizajnové riešenia v ACS. Základné ustanovenia ";
GOST 34.003-90 "Automatizované systémy. Pojmy a definície";
GOST 34.601-90 "Automatizované systémy. Štádiá na tvorbu ";
GOST 34.602-90 "Technická úloha na vytvorenie automatizovaného systému";
GOST 19.201- 78 Zjednotený systém dokumentácie systému;
GOST 2.114-95 Jednotný systém dizajnovej dokumentácie.
TK na OP je zoznam hlavných operačných, technologických, technických, organizačných, programových, informačných a logických a jazykových, ekonomických a iných požiadaviek, ktoré by mali uspokojiť OP vo všetkých fázach existencie.
TK je textový dokument, zostavený v ľubovoľnom formulári. Požadované výkresy, schémy a veľké objemy tabuľky sa odporúča navrhnúť vo forme aplikácií. V závislosti od typu, cieľa a špecifických vlastností objektu automatizácie a podmienok prevádzky systému sa umožní vydať časti TK vo forme žiadostí, zadajte dodatočné, odstrániť alebo kombinovať svoje pododdiely.
Neexistujú žiadne osobitné odporúčania pre to, čo by malo obsahovať TK NO, potom by sa mali vypracovať časti a pododdiely a umiestnené spôsobom predpísaným dodávateľom. Existujú len spoločné charakteristiky sekcií a podsekcií. Vývojár môže nezávisle zmeniť, pridať a upraviť svoje meno a množstvo.
Počet listov (stránok) sú plnené z prvého listu podľa titulnej stránky, v hornej časti listu (nad textom, v strede) po skúšobnom kóde pre IP.
Na titulnej stránke sú umiestnené podpisy zákazníka, vývojár a zodpovedajúce spoločnosti, ktoré upevňujú pečať. V prípade potreby sa titulná stránka vypracuje na viacerých stránkach. Podpisy vývojárov TK a úradníkov zapojených do koordinácie a zváženia projektu TK na OP sú uvedené na posledný list.
Titulná strana dodatku k TK je navrhnutá ako titulná list technickej úlohy. Namiesto názvu "Technická úloha", "doplnok č. ... TK na AC ..."
Na nasledujúcich plechoch dodatkov k TK, základňa je umiestnená na zmenu, obsah zmeny a odkazy na dokumenty, v súlade s ktorými sa tieto zmeny vykonávajú.
Pri prezentácii textu pridávania TK, by mali byť špecifikované čísla zodpovedajúcich položiek, pododsekov, tabuľky hlavného TK atď., Aplikovať slová: "nahradiť", "pridať", "vylúčiť", " Uveďte v novom vydaní ".
V počiatočnom štádiu rozvoja TK, dodávateľ vytvára príklad obsahu.
Všeobecné informácie;
Cieľové ciele a objektové tvorby;
Charakteristiky objektu automatizácie;
Požiadavky na systém;
Prevádzkové podmienky;
Požiadavky na dokumentáciu softvéru;
Technické a ekonomické ukazovatele;
Etapy a fázy vývoja;
Postup kontroly a prijatia.
Tieto časti možno rozdeliť na pododdiely. TK môže tiež zahŕňať aplikácie, ktoré sú opísané zavedenými normami. Performer môže pridať do odstránenia potrebných sekcií, všetky tieto faktory by mali byť špecifikované so zákazníkom. Nasledovanie plánovaného plánu, výkonný umelec môže vyvinúť TK kvalitatívne av krátkom čase.
V prípade potreby dodávateľ vytvorí zoznam prijatých škrtov a glosár.
Technické zadanie k rozvoju zdravotníckeho inštitúcie je uverejnené v dodatku B.