Návrh nariadenia vlády Ruskej federácie „O vytvorení, vývoji a uvedení do prevádzky, prevádzke automatizovaného informačného systému pre projektovú činnosť“ Cloudové riešenie pre automatizáciu projektovej činnosti orgánov štátnej moci„a zmeny a doplnenia niektorých zákonov vlády Ruskej federácie“ (vypracovalo Ministerstvo telekomunikácií a masových komunikácií Ruska 15. februára 2018)

Projektová dokumentácia

Vysvetľujúca poznámka

Za účelom implementácie Nariadení o organizácii projektových činností vo vláde Ruskej federácie, schválených nariadením vlády Ruskej federácie z 15. októbra 2016. N1050, Vláda Ruskej federácie rozhodla:

1. Schváľte priložené:

Predpisy o automatizovanom informačnom systéme projektovej činnosti „Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci“;

Akčný plán ("cestovná mapa") na vytvorenie, vývoj a uvedenie do prevádzky, prevádzku automatizovaného informačného systému pre projektové činnosti "Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci" na roky 2018-2020 (ďalej len Akčný plán) ;

Zmeny, ktoré sa vykonávajú v niektorých aktoch vlády Ruskej federácie.

2. Určite:

Ministerstvo telekomunikácií a masových komunikácií Ruskej federácie - štátny zákazník a prevádzkovateľ automatizovaného informačného systému pre projektové činnosti "Cloudové riešenie pre automatizáciu projektových činností orgánov verejnej moci" (ďalej v tomto poradí - AISPD);

Federálny projektový úrad je oprávneným orgánom na údržbu AISPD.

3. Federálny projektový úrad, federálne výkonné orgány na zabezpečenie:

a) implementácia akčného plánu;

b) prepojenie informačných systémov federálnych výkonných orgánov v rámci projektových aktivít s AISPD a elektronická interakcia týchto informačných systémov s AISPD;

c) využitie AISPD v projektových aktivitách.

4. Odporúčať výkonným orgánom zakladajúcich subjektov Ruskej federácie a orgánom miestna vláda zabezpečiť využívanie AISPD alebo integráciu vlastných informačných systémov s AISPD v rámci aktivít projektu.

5. Ministerstvo telekomunikácií a masových komunikácií Ruskej federácie štvrťročne do 15. dňa mesiaca nasledujúceho po štvrťroku podávania správ predkladá vláde Ruskej federácie správu o implementácii akčného plánu.

6. Ustanoviť, že opatrenia ustanovené týmto uznesením vykonávajú federálne výkonné orgány v rámci ustanovených právomocí a v rámci rozpočtových prostriedkov stanovených federálny zákon o spolkovom rozpočte na príslušný rozpočtový rok a plánovacie obdobie, o vedení a riadení v oblasti zriadených funkcií.

7. Zabezpečiť pridelenie v roku 2018 rozpočtových prostriedkov z rezervný fond Vláda Ruskej federácie na financovanie aktivít na vytvorenie AISPD.

8. Zabezpečiť vyčlenenie alokácií federálneho rozpočtu od roku 2019 na realizáciu opatrení na rozvoj a prevádzku AISPD.

Schválené
Vládne nariadenie
Ruská federácia

pozícia
o automatizovanom informačnom systéme projektovej činnosti „Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci“

1. Automatizovaný informačný systém projektovej činnosti „Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci“ (ďalej len AISPD) zabezpečuje riešenie nasledovných úloh:

a) informačnú podporu projektovej činnosti vo vláde Ruskej federácie, vrátane federálnej projektovej kancelárie, federálnych výkonných orgánov, výkonných orgánov jednotlivých subjektov Ruskej federácie, miestnych samospráv, ako aj iných organizácií (ďalej len štát orgány a organizácie) podieľajúce sa na projektových aktivitách;

b) informačná podpora stálych a dočasných riadiacich orgánov projektovej činnosti štátnych orgánov a organizácií zaoberajúcich sa iniciovaním a realizáciou projektov (programov);

c) informačná interakcia poskytovateľov informácií a používateľov informácií obsiahnutých v AISPD;

d) operatívne a objektívne monitorovanie implementácie projektov (programov);

e) interakcia s občanmi pri realizácii projektov (programov) a projektových iniciatív;

f) udržiavanie elektronické formuláre podávanie správ;

g) informačná podpora motivačného systému pre účastníkov projektových aktivít vrátane účtovania ukazovateľov výkonnosti.

2. Plnenie úloh uvedených v odseku 1 týchto pravidiel sa vykonáva prostredníctvom nasledujúcich funkcií AISPD:

a) podpora prijímania manažérskych rozhodnutí na základe rýchleho a objektívneho monitorovania implementácie projektov (programov);

b) riadenie projektov (programov), portfólia projektov (programov) v orgánoch na rôznych úrovniach podľa jednotnej metodiky, vrátane:

účtovníctvo a údržba (údržba) návrhov projektov;

iniciovanie projektov (programov), klasifikácia a tvorba portfólia projektov (programov);

príprava projektu (programu);

implementácia projektu (programu) a riadenie zmeny projektu (programu);

dokončenie projektu (programu);

monitorovanie implementácie projektov (programov);

analýzy, hodnotenie a iné kontrolné opatrenia na implementáciu projektov (programov);

c) získavanie informácií o realizácii projektov (programov) z rôznych externých zdrojov;

d) používanie elektronického podávania správ o projektových aktivitách;

e) vytváranie štatisticky spoľahlivých informácií o stave realizácie projektov (programov);

f) účtovanie a kalkulácia osobných a projektových ukazovateľov výkonnosti, motivácia stálych a dočasných riadiacich orgánov a účastníkov projektových aktivít;

g) informačná interakcia orgánov verejnej moci a organizácií a nimi používaných informačných systémov v procese projektového riadenia a získavania informácií pre objektívne sledovanie realizácie projektov (programov);

h) interakcia a práca s dokumentmi stálych a dočasných riadiacich orgánov projektových činností v rámci jedného informačný priestor;

i) interakcia s občanmi, organizáciami a inými zainteresovanými osobami a o realizácii projektov (programov) a projektových iniciatív;

j) vytvorenie jednotného zdroja spoľahlivých informácií o projektových aktivitách v orgánoch na rôznych úrovniach, dostupnosť informácií o projektoch (programoch) pre orgány verejnej moci a organizácie.

3. Účastníkmi informačnej interakcie sú:

a) prevádzkovateľ AISPD;

b) poskytovatelia informácií v AISPD;

c) používatelia informácií obsiahnutých v AISPD.

4. Poskytovatelia informácií v AISPD sú:

a) verejné orgány a organizácie vykonávajúce projektové činnosti;

b) orgány verejnej moci a organizácie, ktoré zbierajú, spracúvajú a analyzujú informácie potrebné na objektívne sledovanie realizácie projektov (programov).

5. Používateľmi informácií spracovávaných v AISPD sú federálna projektová kancelária, stále a dočasné orgány riadenia projektovej činnosti štátnych orgánov a organizácií zaoberajúcich sa projektovou činnosťou.

6. Oprávnený orgán na údržbu AISPD vykonáva tieto funkcie:

a) koordinuje tvorbu a rozvoj automatizovaného informačného systému pre projektové činnosti;

b) monitoruje implementáciu a prevádzku AISPD;

c) schvaľuje po dohode s prevádzkovateľom AISPD požiadavky na softvér AISPD;

d) určuje po dohode s prevádzkovateľom AISPD pokyny pre rozvoj AISPD;

e) poskytuje metodickú podporu pre fungovanie a rozvoj AISPD.

7. Prevádzkovateľ AISPD poskytuje:

a) fungovanie AISPD vrátane prevádzkyschopnosti softvéru a hardvéru AISPD;

b) vytvorenie, vývoj a uvedenie do prevádzky, prevádzka AISPD, a to aj z hľadiska podpory a rozvoja technických a softvér AISPD pre rôzne typy projektov po dohode s Oprávneným orgánom na udržiavanie AISPD;

c) príjem, uchovávanie, poskytovanie údajov AISPD;

d) integrita a dostupnosť údajov AISPD pre účastníkov interakcie informácií;

e) ochrana informácií a údajov vytvorených a spracovaných v rámci fungovania AISPD;

f) diferenciácia prístupových práv účastníkov informačnej interakcie;

g) pripojenie a (alebo) poskytovanie prístupu k AISPD;

h) povinné vyúčtovanie a evidencia všetkých akcií a identifikácia všetkých účastníkov;

i) technologická a iná interakcia AISPD s externými informačnými systémami;

j) metodická podpora technického využitia a obsahu AISPD;

k) nahrávanie a aktualizácia klasifikátorov, referenčných kníh a iných referenčných informácií používaných v AISPD do Federálneho štátneho informačného systému „Jednotný systém referenčných informácií“.

8. Poskytovatelia informácií v AISPD poskytujú:

a) poskytovanie informácií AISPD predpísaným spôsobom;

b) relevantnosť a spoľahlivosť informácií poskytnutých v AISPD;

c) výkon vlastného softvéru a hardvéru používaného pri práci s AISPD;

d) poskytovanie návrhov na vypracovanie AISPD poverenému orgánu na vedenie AISPD.

9. Poskytovanie prístupu k AISPD sa vykonáva vo vzťahu k zodpovedným vykonávateľom stálych a dočasných orgánov projektového manažmentu, ktorí prešli procesom identifikácie a autentifikácie prostredníctvom federálneho informačného systému „Jednotný identifikačný a autentizačný systém“ v infraštruktúre, ktorá poskytuje informácie a technologickej interakcie informačných systémov slúžiacich na zabezpečenie stavu a komunálne služby v elektronickej podobe.

10. Softvér a hardvér AISPD musia spĺňať nasledujúce požiadavky:

a) sa nachádzajú na území Ruskej federácie;

b) zabezpečiť umiestňovanie informácií v štátnom jazyku Ruskej federácie;

c) mať platné osvedčenia vydané od Federálna služba bezpečnosť Ruskej federácie a (alebo) Federálnej služby pre technickú a exportnú kontrolu vo vzťahu k ich nástrojom informačnej bezpečnosti, vrátane softvéru a hardvéru, antivírusových a kryptografických nástrojov na ochranu informácií a nástrojov na ochranu informácií pred neoprávneným prístupom, zničením, modifikáciou a blokovanie prístupu k nim, ako aj z iných nezákonných konaní v súvislosti s týmito informáciami;

d) zabezpečiť automatizovanú údržbu elektronických záznamov transakcií uskutočnených v AISPD s fixáciou umiestnenia, zmeny a vymazania informácií, presného času takýchto transakcií, obsahu zmien a informácií o účastníkoch AISPD, ktorí tieto úkony vykonali;

e) zabezpečiť prístup zodpovedným vykonávateľom stálych a dočasných orgánov projektového manažmentu k AISPD, nepretržitú údržbu databáz a ochranu informácií obsiahnutých v AISPD pred neoprávneným prístupom;

f) poskytovať možnosť informačnej interakcie AISPD s inými informačnými systémami, a to aj prostredníctvom využívania prvkov infraštruktúry, ktoré poskytujú informačnú a technologickú interakciu informačných systémov používaných na poskytovanie služieb štátu a obcí v elektronickej forme;

g) zabezpečiť identifikáciu a autentifikáciu zodpovedných vykonávateľov stálych a dočasných orgánov projektového riadenia v AISPD pomocou jednotný systém identifikácia a autentifikácia;

h) poskytovať možnosť získavania informácií z AISPD vo forme súborov a elektronických správ;

i) zabezpečiť bezpečnosť všetkých verzií vytvorených dokumentov a históriu zmien.

11. AISPD zabezpečuje jednotnosť použitých referenčných informácií.

12. Informačná interakcia AISPD s federálnymi štátnymi informačnými systémami, informačnými systémami štátnych orgánov sa uskutočňuje pomocou jednotného systému medzirezortnej elektronickej interakcie, s ostatnými organizáciami využíva zabezpečenú sieť prenosu dát, ktorej organizáciu zabezpečuje prevádzkovateľ AISPD.

13. Technické normy a požiadavky na technologickú kompatibilitu AISPD s externými informačnými systémami, požiadavky na štandardy a protokoly na výmenu dokumentov AISPD s externými informačnými systémami stanovuje prevádzkovateľ AISPD v súlade s požiadavkami legislatívy Ruskej federácie v oblasti informačné technológie.

14. Stanovenie a objasnenie zloženia informácií, formátov na ich poskytovanie, dodávateľov a spotrebiteľov informácií generovaných v AISPD, vykonáva federálna projektová kancelária s prihliadnutím na rozhodnutia pracovnej skupiny pod prezídiom Rady pod prezidenta Ruskej federácie za strategický rozvoj a prioritných projektov (ďalej len Rada) a môže ich posudzovať prezídium Rady na návrh federálnej projektovej kancelárie.

15. Informácie obsiahnuté v AISPD podliehajú ochrane v súlade s právnymi predpismi Ruskej federácie o informáciách, informačných technológiách a ochrane informácií, právnymi predpismi Ruskej federácie o osobných údajoch.

16. Ochrana informácií obsiahnutých v AISPD je zabezpečená aplikáciou organizačných a technických opatrení na ochranu informácií, ako aj monitorovaním prevádzky AISPD.

17. Spôsobom a v prípadoch ustanovených právnym poriadkom Ruskej federácie sa poskytovanie informácií o projektoch (programoch) v elektronickej forme pomocou AISPD uskutočňuje pomocou vylepšeného kvalifikovaného elektronického podpisu.

18. Za úplnosť a správnosť informácií o projektoch (programoch), informáciách o stave realizácie projektov (programov), ako aj za dodržiavanie ust. postup a termíny ich predloženia AISPD.

Schválené
Vládne nariadenie
Ruská federácia
zo dňa "__" _______ 2018 N _______

Plán
činnosti ("cestovnej mapy") na vytvorenie, vývoj a uvedenie do prevádzky, prevádzku automatizovaného informačného systému pre projektovú činnosť "Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci" na roky 2018-2020

I. Všeobecné ustanovenia

1. Implementácia akčného plánu ("cestovnej mapy") na tvorbu, vývoj a uvedenie do prevádzky, prevádzkovanie automatizovaného informačného systému projektovej činnosti "Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci" na roky 2018-2020 (ďalej len ako „cestovná mapa“) je zameraná na zlepšenie účinnosti a efektívnosti projektového riadenia vo vláde Ruskej federácie, federálne orgány výkonné orgány, výkonné orgány zakladajúcich subjektov Ruskej federácie, miestne samosprávy, ako aj iné organizácie, a to aj prostredníctvom zavedenia automatizovaný systém riadiť projekty (programy) podľa jednotnej metodiky, vytvárať jednotný informačný priestor pre interakciu stálych a dočasných orgánov projektového riadenia, prechod na elektronická správa dokumentov v projektových aktivitách.

Štandardizácia prístupov k riadeniu projektov, využitie cloudového riešenia na automatizáciu projektových činností orgánov verejnej moci zníži administratívnu záťaž orgánov verejnej moci a zároveň zvýši úroveň efektívnosti riadenia projektov.

V tejto súvislosti je potrebné zaviesť moderné informačné technológie v zmysle automatizácie projektovej činnosti orgánov verejnej moci.

2. Účelom „cestovnej mapy“ je optimalizovať pracovné, materiálne a finančné zdroje využívané pri plánovaní, realizácii a monitorovaní projektov (programov).

II. Všeobecné charakteristiky a hlavné výsledky

Posilňovač účinnosti kontrolovaná vládou je prechod na projektové riadenie pomocou jednotnej metodiky a automatizácie procesov projektového riadenia.

Výsledky implementácie „cestovnej mapy“ sú:

vytvorenie, vývoj, uvedenie do prevádzky a prevádzka automatizovaného informačného systému pre projektovú činnosť „Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci“;

prijatie príslušných regulačných právnych aktov s cieľom zaviesť automatizáciu projektového riadenia vo verejných orgánoch a organizáciách.

Na základe výsledkov realizácie cestovnej mapy sa plánuje zabezpečiť na zákl spoločné normy a metodických prístupov nevyhnutnú úroveň informačnej interakcie medzi orgánmi verejnej moci a organizáciami nimi využívaných informačných systémov v procese projektového riadenia, automatizovať konštantné a monotónne procesy, zvyšovať validitu prijatých rozhodnutí, automatizovať zber a analýzu súhrnných informácií o výsledky realizácie projektov (programov), prejsť na elektronické vykazovanie projektov (programov), ako aj zvýšiť dostupnosť týchto informácií pre orgány verejnej moci.

III. Akčný plán

Schválené
Vládne nariadenie
Ruská federácia
zo dňa "__" _______ 2018 N _______

zmeny,
ktoré sú súčasťou niektorých zákonov vlády Ruskej federácie

1. Pododsek "a" odseku 2 nariadenia o infraštruktúre, ktorá zabezpečuje informačnú a technologickú interakciu informačných systémov používaných na poskytovanie štátnych a komunálnych služieb a vykonávanie štátnych a obecných funkcií v elektronickej forme, schváleného nariadením vlády Ruskej federácie. federácie dňa 8. júna 2011 N 451 "O infraštruktúre poskytujúcej informačnú a technologickú interakciu informačných systémov používaných na poskytovanie štátnych a komunálnych služieb a vykonávanie štátnych a obecných funkcií v elektronickej forme" (Sobraniye Zakonodatelstva Rossiyskoy Federatsii, 2011, č. 24, čl. 3503, č. 44, článok 6274, č. 49, článok 7284, 2012, č. 39, článok 5269, č. 53, článok 7938, 2013, č. 27, článok 3612, č. č. 45, článok 5827; č. 52, článok 7218; 2014, N 30, položka 4318; N 48, položka 6876; N 50, položka 7113; 2016, N 34, položka 5247; 2017, N 5981, položka N 44, položka 6523) pridať tento odsek:

"automatizovaný informačný systém pre projektovú činnosť "Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci."

2. V bode "b" odseku 4 Predpisov o štátnom automatizovanom informačnom systéme "Manažment", schválenom nariadením vlády Ruskej federácie z 25. decembra 2009 N 1088 "O štátnom automatizovanom informačnom systéme" Riadenie " (Zbierané právne predpisy Ruskej federácie, 2010, N 1, položka 101; 2011, N 38, položka 5380; 2013, N 1, položka 65; N 48, položka 6259; 2015, N 2, položka 459, 4060; N 1 1524, N 49, bod 6972) sa vypúšťajú slová "a realizácii prioritných národných projektov".

3. V stanovisku k hlavnému podujatiu 4.2, Príloha č. 4 k štátnemu programu Ruskej federácie „Informačná spoločnosť (2011 - 2020)“, schválenom uznesením vlády Ruskej federácie z 15. apríla 2014 N 313 "O schválení štátneho programu Ruskej federácie" Informačná spoločnosť (2011 - 2020) "Zbierané právne predpisy Ruskej federácie, 2014, N 18, čl. 2159; 2015, N 9, čl. 1341; N 26, čl. 3896; 2016, N 44, čl. 6139; 2017, N 9, položka 1366; N 11, položka 1573; N 15, položka 2214; N 34, položka 5289; N 45, položka 6661, položka N 707; 2018, N 4, položka 623), v stĺpci „Hlavné smery implementácie“:

a) po odseku 32 "vývoj federálneho štátneho informačného systému" Federálne situačné stredisko e-government";" pridať nasledujúci odsek:

"tvorba a vývoj automatizovaného informačného systému pre projektovú činnosť "Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci";"

b) po odseku tridsiatom štvrtom „prevádzkovanie federálneho štátneho informačného systému „Federálne situačné centrum pre elektronickú vládu“;“ pridať nasledujúci odsek:

„uvedenie do prevádzky a prevádzka automatizovaného informačného systému pre projektovú činnosť „Cloudové riešenie pre automatizáciu projektovej činnosti orgánov verejnej moci“;“.

Prehľad dokumentov

Návrh Vyhlášok o činnosti projektu AIS "Cloudové riešenie pre automatizáciu projektovej činnosti štátnych orgánov."

Úlohy - informačná podpora stálych a dočasných riadiacich orgánov projektovej činnosti orgánov a organizácií, ktoré iniciujú a realizujú projekty (programy); informačná podpora projektových aktivít; informačná interakcia poskytovateľov a používateľov informácií obsiahnutých v AIS; operatívne a objektívne sledovanie realizácie projektov (programov); interakcia s občanmi pri realizácii projektov (programov) a projektových iniciatív; údržba elektronických oznamovacích formulárov; informačná podpora motivačného systému pre účastníkov projektu.

Uvedený je Akčný plán ("cestovná mapa") na vytvorenie, rozvoj a uvedenie do prevádzky, prevádzku AIS na roky 2018-2020.

Nbsp; Modely životného cyklu AIS

Model životného cyklu AIS- je štruktúra, ktorá popisuje procesy, činnosti a úlohy, ktoré sa vykonávajú počas vývoja, prevádzky a údržby počas celého životného cyklu systému.

Výber modelu životného cyklu závisí od špecifík, rozsahu, zložitosti projektu a súboru podmienok, v ktorých AIS vzniká a funguje.

Model životného cyklu AIS zahŕňa:

Výsledky práce v každej fáze;

Kľúčové udalosti alebo body dokončenia a rozhodovania.

V súlade so známymi modelmi životného cyklu softvéru sa určujú modely životného cyklu AIS - kaskáda, iterácia, špirála.

I. Kaskádový model opisuje klasický prístup k vývoju systémov v ľubovoľných tematických oblastiach; bol široko používaný v 70-tych a 80-tych rokoch.

Kaskádový model zabezpečuje sekvenčnú organizáciu práce a hlavnou črtou modelu je rozdelenie všetkých prác na etapy. Prechod z predchádzajúcej fázy do ďalšej nastáva až po úplnom dokončení všetkých prác predchádzajúcej.

Prideliť päť etapy trvalo udržateľného rozvoja, prakticky nezávislé od predmetnej oblasti (obr. 1.1).

Na najprv Vo fáze sa študuje problémová oblasť, formulujú sa požiadavky zákazníka. Výsledkom tejto fázy je zadanie (vývojová úloha), dohodnuté so všetkými zainteresovanými stranami.

Počas druhý etape, podľa požiadaviek zadávacích podmienok sa vyvíjajú určité konštrukčné riešenia. Výsledkom je súprava projektovej dokumentácie.

Tretia etapa - realizácia projektu; v podstate vývoj softvéru (kódovanie) v súlade s rozhodnutiami o dizajne predchádzajúcej etapy. Spôsoby implementácie nemajú zásadný význam. Výsledkom etapy je hotový softvérový produkt.

Na štvrtý Vo fáze sa kontroluje, či prijatý softvér spĺňa požiadavky uvedené v zadávacích podmienkach. Skúšobná prevádzka umožňuje odhaliť rôzne druhy skrytých nedostatkov, ktoré sa prejavujú v reálnych podmienkach prevádzky AIS.

Poslednou fázou je dodanie hotového projektu a tu ide hlavne o to presvedčiť zákazníka, že všetky jeho požiadavky sú plne splnené.

Obr. 1.1 Kaskádový model AIS LC

Etapy práce v rámci vodopádového modelu sú často označované ako časti projektového cyklu AIS, keďže etapy pozostávajú z mnohých opakovaných postupov na dolaďovanie systémových požiadaviek a možností návrhu. Životný cyklus AIS je oveľa komplikovanejší a dlhší: môže zahŕňať ľubovoľný počet cyklov zdokonaľovania, zmien a doplnkov k už prijatým a realizovaným návrhovým rozhodnutiam. V týchto cykloch prebieha vývoj AIS a modernizácia jeho jednotlivých komponentov.

Výhody modelu vodopádu:

1) v každej fáze sa vytvorí kompletný súbor projektovej dokumentácie, ktorá spĺňa kritériá úplnosti a konzistentnosti. V záverečných fázach sa vytvára užívateľská dokumentácia pokrývajúca všetky typy podpory AIS poskytovanej štandardmi (organizačná, informačná, softvérová, technická atď.);

2) postupné vykonávanie etáp práce vám umožňuje naplánovať načasovanie dokončenia a zodpovedajúce náklady.

Kaskádový model bol pôvodne vyvinutý na riešenie rôznych druhov inžinierskych problémov a dodnes nestratil svoj význam pre aplikovanú oblasť. Vodopádový prístup je navyše ideálny pre vývoj AIS, keďže už na samom začiatku vývoja je možné celkom presne formulovať všetky požiadavky, aby vývojári mali voľnosť pri technickej implementácii. Medzi takéto AIS patria najmä komplexné zúčtovacie systémy a systémy v reálnom čase.

Nevýhody vodopádového modelu:

Výrazné oneskorenie pri dosahovaní výsledkov;

Chyby a nedostatky v ktorejkoľvek z fáz sa spravidla objavujú v nasledujúcich fázach práce, čo vedie k potrebe návratu;

Zložitosť paralelnej práce na projekte;

Nadmerné informačné preťaženie každej z fáz;

zložitosť projektového manažmentu;

Vysoká miera rizika a nespoľahlivosti investícií.

Oneskorenie dosiahnutia výsledkov Prejavuje sa to v tom, že pri dôslednom prístupe k rozvoju sú výsledky so zainteresovanými stranami dohodnuté až po ukončení ďalšej etapy prác. V dôsledku toho sa môže ukázať, že vyvinutý AIS nespĺňa požiadavky a takéto nezrovnalosti sa môžu vyskytnúť v ktorejkoľvek fáze vývoja; okrem toho môžu analytici aj programátori neúmyselne zaviesť chyby, pretože sa od nich nevyžaduje, aby sa dobre orientovali v oblastiach, pre ktoré sa AIS vyvíja.

Vráťte sa do predchádzajúcich fáz. Táto nevýhoda je prejavom predchádzajúcej: postupná postupná práca na projekte môže viesť k tomu, že chyby urobené v skorších štádiách sa zistia až v nasledujúcich fázach. V dôsledku toho sa projekt vráti do predchádzajúcej fázy, spracuje sa a až potom sa prenesie do ďalšej práce. To môže spôsobiť narušenie harmonogramu a skomplikovať vzťahy medzi vývojovými tímami vykonávajúcimi jednotlivé etapy.

Najhoršou možnosťou je, keď sa nedostatky predchádzajúcej fázy zistia nie v ďalšej fáze, ale neskôr. Napríklad v štádiu skúšobnej prevádzky sa môžu objaviť chyby v popise predmetnej oblasti. To znamená, že časť projektu sa musí vrátiť do počiatočnej fázy prác.

Zložitosť paralelnej práce súvisí s potrebou zosúladiť jednotlivé časti projektu Čím pevnejší je vzťah jednotlivých častí projektu, tým častejšie a starostlivejšie sa musí vykonávať synchronizácia, tým viac sú na sebe vývojové tímy závislé. V dôsledku toho sa jednoducho stratia výhody paralelnej práce; nedostatok paralelizmu negatívne ovplyvňuje organizáciu práce celého tímu.

Problém prebytok informácií vyplýva zo silnej závislosti medzi rôznymi skupinami vývojárov. Faktom je, že pri vykonávaní zmien v jednej z častí projektu je potrebné upozorniť tých vývojárov, ktorí ju použili (mohli použiť) vo svojej práci. Pri veľkom počte vzájomne prepojených subsystémov sa synchronizácia internej dokumentácie stáva samostatnou hlavnou úlohou: vývojári sa musia neustále oboznamovať so zmenami a vyhodnocovať, ako tieto zmeny ovplyvnia dosiahnuté výsledky.

Zložitosť projektového manažmentu najmä kvôli prísnej postupnosti vývojových etáp a prítomnosti zložitých vzťahov medzi rôznymi časťami projektu. Regulovaná postupnosť prác vedie k tomu, že niektoré vývojové skupiny musia čakať na výsledky práce iných tímov, preto je potrebný administratívny zásah na dohodnutie načasovania a zloženia prenášanej dokumentácie.

V prípade zistenia chýb v práci je potrebný návrat k predchádzajúcim etapám; súčasná práca tých, ktorí urobili chybu, je prerušená. Dôsledkom toho je zvyčajne oneskorenie v realizácii opravených aj nových projektov.

Zjednodušiť interakciu medzi vývojármi a znížiť informačnú preťaženosť dokumentácie je možné znížením počtu väzieb medzi jednotlivými časťami projektu, nie každý AIS je však možné rozdeliť na voľne viazané podsystémy.

Vysoká miera rizika.Čím je projekt zložitejší, tým dlhšie trvá každá etapa vývoja a tým zložitejší je vzťah medzi jednotlivými časťami projektu, ktorých počet sa tiež zvyšuje. Navyše, výsledky vývoja je možné reálne vidieť a vyhodnotiť až vo fáze testovania, teda po dokončení analýzy, návrhu a vývoja – fázy, ktorej realizácia si vyžaduje nemalý čas a peniaze.

Oneskorené hodnotenie spôsobuje vážne problémy pri identifikácii chýb analýzy a návrhu – je potrebný návrat k predchádzajúcim fázam a opakovanie procesu vývoja. Návrat k predchádzajúcim etapám však môže byť spojený nielen s chybami, ale aj so zmenami, ktoré nastali v predmetnej oblasti alebo v požiadavkách zákazníkov počas vývoja. Zároveň nikto nezaručuje, že sa predmetná oblasť do prípravy ďalšej verzie projektu opäť nezmení. V skutočnosti to znamená, že existuje možnosť „cyklu“ procesu vývoja: náklady na projekt budú neustále rásť a termíny dodania hotového produktu sa budú neustále oneskorovať.

II. Iteračný model pozostáva zo série krátkych cyklov (krokov) plánovania, implementácie, štúdie, akcie.

Tvorba komplexného AIS zahŕňa koordináciu konštrukčných riešení získaných pri realizácii jednotlivých úloh. Konštrukčný prístup „zdola nahor“ si vyžaduje také iterácie návratnosti, keď sa dizajnové riešenia jednotlivých úloh spájajú do spoločných systémových riešení. V tomto prípade je potrebné revidovať predtým vytvorené požiadavky.

Výhoda iteračného modelu je, že medzistupňové úpravy poskytujú menšiu pracovnú náročnosť vývoja v porovnaní s kaskádovým modelom.

nevýhody iteračný model:

· životnosť každej etapy sa predlžuje na celé obdobie práce;

· v dôsledku veľkého počtu opakovaní dochádza k nezrovnalostiam pri implementácii návrhových rozhodnutí a dokumentácie;

zložitosti architektúry

· Ťažkosti pri používaní projektovej dokumentácie v etapách implementácie a prevádzky si vyžadujú prepracovanie celého systému.

III. špirálový model, na rozdiel od kaskády, ale podobne ako tá predchádzajúca, zahŕňa iteračný proces vývoja AIS. Zároveň sa zvyšuje dôležitosť počiatočných fáz, akými sú analýza a návrh, ktoré kontrolujú a zdôvodňujú realizovateľnosť. technické riešenia vytváraním prototypov.

Každá iterácia je úplným vývojovým cyklom vedúcim k vydaniu internej alebo externej verzie produktu (alebo podmnožiny konečného produktu), ktorá sa od iterácie po iteráciu vylepšuje, aby sa stala kompletným systémom (obrázok 1.2).

Ryža. 1.2. Špirálový model životného cyklu AIS

Každé otočenie špirály teda zodpovedá vytvoreniu fragmentu alebo verzie softvérového produktu, špecifikuje ciele a charakteristiky projektu, určuje jeho kvalitu a plánuje prácu na ďalšom otočení špirály. Každá iterácia slúži na prehĺbenie a dôsledné upresnenie detailov projektu, v dôsledku čoho sa vyberie rozumná možnosť pre konečnú realizáciu.

Použitie špirálového modelu vám umožňuje prejsť do ďalšej fázy projektu bez čakania na dokončenie aktuálnej - nedokončenú prácu je možné vykonať v ďalšej iterácii. hlavnou úlohou každá iterácia - čo najskôr vytvoriť funkčný produkt na demonštráciu používateľom. Proces zavádzania objasnení a dodatkov k projektu je teda značne zjednodušený.

Špirálový prístup k vývoju softvéru prekonáva väčšinu nedostatkov vodopádového modelu, navyše poskytuje množstvo ďalších funkcií, vďaka ktorým je proces vývoja flexibilnejší.

Výhody iteratívny prístup:

Iteračný vývoj výrazne zjednodušuje zavádzanie zmien do projektu pri zmene požiadaviek zákazníka;

Pri použití špirálového modelu sa jednotlivé prvky AIS postupne integrujú do jedného celku. Keďže integrácia začína s menším počtom prvkov, pri jej implementácii je oveľa menej problémov;

Zníženie úrovne rizík (dôsledok predchádzajúcej výhody, keďže riziká sa zisťujú počas integrácie). Miera rizík je na začiatku vývoja projektu maximálna, s postupom vývoja klesá;

Iteračný vývoj poskytuje väčšiu flexibilitu v riadení projektu tým, že umožňuje taktické zmeny, ktoré sa majú robiť vo vývoji produktu. Je teda možné skrátiť čas vývoja znížením funkčnosti systému alebo použiť produkty tretích strán namiesto vlastného vývoja ako komponenty (relevantné v trhovej ekonomike, keď je potrebné brániť sa presadzovaniu konkurencie ' Produkty);

Iteračný prístup uľahčuje opätovné použitie komponentov, pretože je oveľa jednoduchšie identifikovať (identifikovať) spoločné časti projektu, keď sú už čiastočne vyvinuté, než sa ich snažiť izolovať na samom začiatku projektu. Analýza návrhu po niekoľkých počiatočných iteráciách odhaľuje bežné opakovane použiteľné komponenty, ktoré budú vylepšené v nasledujúcich iteráciách;

Špirálový model vám umožňuje získať spoľahlivejší a stabilnejší systém. Je to preto, že ako sa systém vyvíja, pri každej iterácii sa nachádzajú a opravujú chyby a slabé stránky. Zároveň sa upravujú kritické výkonové parametre, ktoré sú v prípade vodopádového modelu dostupné len pred implementáciou systému;

Iteratívny prístup umožňuje zlepšovanie procesov
vývoj - ako výsledok analýzy na konci každej iterácie sa vykoná hodnotenie zmien v organizácii vývoja; pri ďalšej iterácii sa to zlepšuje.

Hlavný problém špirálového cyklu- obtiažnosť určenia okamihu prechodu do ďalšej fázy. Na jeho vyriešenie je potrebné zaviesť časové limity pre každú z etáp životného cyklu. V opačnom prípade sa vývojový proces môže zmeniť na nekonečné zlepšovanie toho, čo už bolo urobené.

Zapojenie používateľov do procesu navrhovania a kopírovania aplikácie vám umožňuje prijímať pripomienky a doplnky k požiadavkám priamo v procese navrhovania aplikácie, čím sa skracuje čas vývoja. Zástupcovia zákazníka dostávajú možnosť kontrolovať proces tvorby systému a ovplyvňovať jeho funkčný obsah. Výsledkom je uvedenie systému do prevádzky, ktorý zohľadňuje väčšinu potrieb zákazníkov.

Sú dodávané moderné metodiky a technológie návrhu AIS, ktoré ich implementujú v elektronickom formáte spolu s CASE-tools a zahŕňajú knižnice procesov, šablón, metód, modelov a iných komponentov určených na budovanie softvéru tej triedy systémov, na ktoré je metodika orientovaná. Elektronické metodiky a technológie tvoria jadro súboru harmonizovaných vývojových nástrojov AIS. Vlastnosti moderných metodických riešení pre návrh AIS nemožno implementovať bez určitých konštrukčných technológií, ktoré zodpovedajú rozsahu a špecifikám projektu.

Technológia dizajnu AIS- ide o súbor metód a nástrojov na navrhovanie AIS, ako aj metód a nástrojov na organizovanie dizajnu (riadenie procesu tvorby a modernizácie projektu AIS).

Podľa návrhu TP je AIS súbor sériovo-paralelných, spojených a podriadených reťazcov akcií, z ktorých každý môže mať svoj vlastný predmet. Úkony, ktoré sa vykonávajú pri návrhu AIS, možno definovať ako nedeliteľné technologické operácie alebo ako čiastkové procesy. technologické operácie. Všetky akcie môžu byť dizajn, ktoré tvarujú alebo upravujú výsledky návrhu a hodnotenie, ktoré sa vyvíjajú podľa stanovených kritérií na hodnotenie výsledkov projektovania.

Technológia návrhu je teda daná regulovaným sledom technologických operácií vykonávaných v procese tvorby projektu na základe konkrétnej metódy.

Predmetom zvolenej technológie návrhu by mala byť reflexia vzájomne súvisiacich procesov návrhu vo všetkých fázach životného cyklu AIS.

Hlavné požiadavky na zvolenú konštrukčnú technológiu sú nasledovné:

Projekt vytvorený pomocou tejto technológie musí spĺňať požiadavky zákazníka;

Technológia by mala maximálne odrážať všetky fázy životného cyklu projektu;

Technológia by mala poskytovať minimálne náklady na prácu a náklady na dizajn a údržbu projektu;

technológie by mali prispieť k rastu produktivity práce dizajnérov;

Technológia musí zabezpečiť spoľahlivosť návrhu a prevádzky projektu;

Technológia by mala uľahčiť jednoduchú údržbu projektovej dokumentácie.

Technológia návrhu AIS implementuje určitú metodológiu návrhu. Metodológia dizajnu zase predpokladá existenciu určitého konceptu, princípov dizajnu a je implementovaná súborom metód a nástrojov.

Metódy návrhu AIS možno klasifikovať podľa miery využitia automatizačných nástrojov, projektov štandardných riešení a adaptability na očakávané zmeny.

Podľa stupňa automatizácie existujú:

manuálny dizajn, v ktorom sa návrh komponentov AIS vykonáva bez použitia špeciálnych softvérových nástrojov; programovanie sa vykonáva v algoritmických jazykoch;

počítačový dizajn, v ktorom sa generovanie alebo konfigurácia (nastavenie) konštrukčných riešení uskutočňuje pomocou špeciálnych softvérových nástrojov.

Podľa stupňa použitia štandardných konštrukčných riešení existujú:

originál (jednotlivec) dizajn, keď sa dizajnové riešenia vyvíjajú od začiatku v súlade s požiadavkami na AIS;

štandardné prevedenie, ktorý predpokladá konfiguráciu AIS z hotových štandardných konštrukčných riešení (softvérových modulov).

originálny dizajn AIS predpokladá maximálne zohľadnenie vlastností automatizovaného objektu.

Typický dizajn sa realizuje na základe hotových riešení a je zovšeobecnením skúseností získaných skôr pri tvorbe súvisiacich projektov.

Podľa miery prispôsobivosti konštrukčných riešení Rozlišujú sa tieto metódy:

rekonštrukcia- prispôsobenie konštrukčných riešení sa vykonáva spracovaním príslušných komponentov (preprogramovanie softvérových modulov);

parametrizácia- konštrukčné riešenia sú upravené v súlade s určenými a meniteľnými parametrami;

reštrukturalizácia modelu- mení sa doménový model, čo vedie k automatickému pretváraniu dizajnových riešení.

Kombinácia rôznych znakov klasifikácie metód návrhu určuje charakter použitej technológie návrhu AIS. Existujú dve hlavné triedy technológie dizajnu: kanonický a priemyselný. Technológia priemyselného dizajnu je rozdelená do dvoch podtried: automatizované(pomocou technológií CASE) a typický(parametricky orientovaný alebo modelovo orientovaný) dizajn.

Tabuľka 1.1.Charakteristika tried technológie dizajnu

Kanonický dizajn AIS zameraný na využitie najmä kaskádového modelu životného cyklu AIS.

V závislosti od zložitosti objektu automatizácie a súboru úloh, ktoré je potrebné vyriešiť pri vytváraní konkrétneho AIS, môžu mať etapy a etapy práce rôznu zložitosť. Je povolené kombinovať po sebe nasledujúce fázy a niektoré z nich vylúčiť v ktorejkoľvek fáze projektu. Je tiež povolené začať prácu ďalšej etapy pred ukončením predchádzajúcej.

Etapy a etapy tvorby AIS, vykonávané zúčastnenými organizáciami, sú predpísané v zmluvách a zadávacích podmienkach na výkon prác.

1. fáza Formovanie požiadaviek na AIS:

prieskum objektu a zdôvodnenie potreby vytvorenia AIS;

Tvorba užívateľských požiadaviek na AIS;

vypracovanie správy o vykonanej práci a takticko-technického zadania pre voj.

2. fáza Vývoj koncepcie AIS:

štúdium predmetu automatizácie;

Vykonávanie potrebných výskumných prác;

· vývoj variant koncepcie AIS, ktoré spĺňajú požiadavky užívateľov;

vypracovanie správy a schválenie koncepcie.

3. fáza Technická úloha:

Vypracovanie a schválenie zadávacích podmienok pre tvorbu AIS.

4. fáza Predbežný návrh:

vývoj predbežných konštrukčných riešení pre systém a jeho časti;

rozvoj skicovej dokumentácie o AIS a jeho častiach.

5. fáza Technický projekt:

vývoj dizajnových riešení pre systém a jeho časti;

vypracovanie dokumentácie pre AIS a jeho časti;

vývoj a realizácia dokumentácie pre dodávku komponentov;

· vypracovanie úloh pre projektovanie v priľahlých častiach projektu.

6. fáza Pracovná dokumentácia:

· vypracovanie pracovnej dokumentácie pre AIS a jeho časti;

vývoj a prispôsobenie programov.

7. fáza Uvedenie do prevádzky:

príprava objektu automatizácie; školenie zamestnancov;

· kompletný súbor AIS s dodávanými produktmi (softvér a hardvér, softvérové ​​a hardvérové ​​komplexy, informačné produkty);

stavebné a inštalačné práce; uvedenie do prevádzky;

Vykonávanie predbežných testov;

vykonávanie skúšobnej prevádzky;

Vykonávanie akceptačných testov.

8. fáza Sprievodný AIS:

vykonávanie prác v súlade so záručnými povinnosťami;

pozáručný servis.

Prieskum je štúdium a analýza organizačnej štruktúry podniku, jeho činnosti a existujúci systém spracovávanie informácií.

Materiály získané ako výsledok prieskumu sa používajú na:

Zdôvodnenie vývoja a postupnej implementácie systémov;

Príprava referenčných podmienok pre vývoj systémov;

Vývoj technických a pracovných projektov systémov.

V štádiu prieskumu je vhodné rozlíšiť dve zložky: definíciu implementačnej stratégie AIS a podrobnú analýzu aktivít organizácie.

Hlavnou úlohou prvej etapy prieskumu je posúdiť skutočný rozsah projektu, jeho ciele a zámery na základe zistených funkcií a informačných prvkov vysokoúrovňového automatizovaného objektu. Tieto úlohy môže realizovať buď zákazník AIS samostatne, alebo so zapojením poradenských organizácií. Fáza zahŕňa úzku interakciu s hlavnými potenciálnymi používateľmi systému a obchodnými expertmi. Hlavnou úlohou interakcie je úplné a jednoznačné pochopenie požiadaviek zákazníka. Potrebné informácie možno spravidla získať na základe rozhovorov, rozhovorov alebo seminárov s vedením, odborníkmi a používateľmi.

Na konci fázy prieskumu je možné určiť pravdepodobné technické prístupy k vytvoreniu systému a odhadnúť náklady na jeho implementáciu (na hardvér, na zakúpený softvér a na vývoj nového softvéru).

Výsledkom fázy definovania stratégie je dokument (štúdia uskutočniteľnosti - štúdia uskutočniteľnosti - projekt), v ktorom je jasne uvedené, čo zákazník dostane, ak bude súhlasiť s financovaním projektu, kedy dostane hotový produkt (harmonogram prác) a koľko bude to stáť (pri veľkých projektoch - ide o harmonogram financovania v rôznych fázach práce). V dokumente je žiaduce premietnuť nielen náklady, ale aj prínosy projektu, napríklad dobu návratnosti projektu, očakávaný ekonomický efekt (ak sa dá odhadnúť).

Obmedzenia, riziká, kritické faktory, ktoré môžu ovplyvniť úspech projektu;

Súbor podmienok, za ktorých má budúci systém fungovať – architektúra systému, hardvérové ​​a softvérové ​​prostriedky, prevádzkové podmienky, obslužný personál a používateľov systému;

Termíny ukončenia jednotlivých etáp, forma prevzatia/dodania diela, prilákané zdroje, opatrenia na ochranu informácií;

Popis funkcií vykonávaných systémom;

Príležitosti pre rozvoj a modernizáciu systému;

Rozhrania a rozdelenie funkcií medzi osobou a systémom;

požiadavky na softvér a systémy riadenia databáz (DBMS).

V štádiu podrobného rozboru činnosti organizácie sa skúmajú činnosti zabezpečujúce výkon riadiacich funkcií, organizačná štruktúra, personálne obsadenie a náplň práce na riadení podniku, ako aj charakter podriadenosti vyšším riadiacim orgánom. Tu je potrebné načrtnúť inštruktážno-metodické a direktívne materiály, na základe ktorých sa určuje skladba podsystémov a zoznam úloh, ako aj možnosti aplikácie nových metód riešenia problémov.

Analytici zhromažďujú a zaznamenávajú informácie v dvoch vzájomne súvisiacich formách:

Funkcie – informácie o udalostiach a procesoch, ktoré sa vyskytujú v automatizovanej organizácii;

Entity – informácie o triedach objektov, ktoré sú dôležité pre organizáciu a o ktorých sa zhromažďujú údaje.

Pri štúdiu každej funkčnej úlohy riadenia sa určujú:

názov úlohy; podmienky a frekvenciu jeho rozhodovania;

Stupeň formalizovateľnosti úlohy;

Zdroje informácií potrebné na vyriešenie problému;

Ukazovatele a ich kvantitatívne charakteristiky;

Postup opravy informácií;

Prevádzkové algoritmy na výpočet ukazovateľov a možné metódy kontroly;

Prevádzkové prostriedky na zber, prenos a spracovanie informácií;

Prevádzkové komunikačné prostriedky;

Akceptovaná presnosť riešenia problému;

Zložitosť riešenia problému;

Súčasné formy prezentácie prvotných údajov a výsledkov ich spracovania vo forme dokumentov;

Spotrebitelia výsledných informácií o úlohe.

Jednou z časovo najnáročnejších, aj keď dobre formalizovaných úloh tejto fázy, je popis pracovného toku organizácie. Pri skúmaní toku dokumentov sa zostaví schéma trasy pohybu dokumentov, ktorá by mala odrážať:

Počet dokumentov;

Miesto tvorby indikátorov dokumentov;

Vzťah dokumentov pri ich tvorbe;

Trasa a trvanie pohybu dokumentu;

Miesto použitia a uloženia tohto dokumentu;

Interná a externá informačná komunikácia;

Objem dokumentu v znakoch.

Na základe výsledkov prieskumu je zostavený zoznam úloh I manažmentu, ktoré sa majú automatizovať, a postupnosť ich vývoja.

Počas fázy prieskumu by sa plánované funkcie systému mali klasifikovať podľa dôležitosti. Jedným z možných formátov na vyjadrenie takejto klasifikácie je MuSCoW. Táto skratka znamená: Must have - nevyhnutné funkcie; Mal by mať - žiaduce funkcie; Mohol mať - I možné funkcie; Nebude mať - chýbajúce funkcie.

Funkcie prvej kategórie sú rozhodujúce pre I úspešná práca systémy príležitostí. Implementácia funkcií druhej a tretej kategórie je limitovaná časovým a finančným rámcom: vyvíja sa potrebný, ako aj maximálny možný počet funkcií druhej a tretej kategórie v poradí podľa priority. Posledná kategória funkcií je obzvlášť dôležitá, pretože musíte mať jasno v hraniciach Projektu I a súbore funkcií, ktoré budú v systéme chýbať.

Modely činností organizácie sú vytvorené v dvoch typoch 1 :

Model „tak ako je“ odráža obchodné procesy existujúce v organizácii op-I;

Model „byť“ odráža potrebné zmeny v podnikových procesoch s prihliadnutím na zavedenie AIS. j

Už vo fáze analýzy je potrebné zapojiť testovacie skupiny do práce na vyriešenie nasledujúcich úloh:

Získanie porovnávacích charakteristík hardvérových platforiem, operačných systémov, DBMS atď. určených na 1 použitie;

Vypracovanie plánu práce na zabezpečenie spoľahlivosti AIS a jeho testovania.

Zapojenie testerov v počiatočných fázach vývoja je vhodné pre akýkoľvek projekt. Čím neskôr sa zistia chyby v rozhodnutiach o dizajne, tým drahšia je ich oprava; najhoršou možnosťou je ich odhalenie v štádiu implementácie. Čím skôr teda testovacie tímy začnú zisťovať chyby v AIS, tým nižšie sú náklady na prácu na systéme. Čas na testovanie systému a opravu zistených chýb by mal byť poskytnutý nielen vo fáze vývoja, ale aj vo fáze návrhu.

Špeciálne systémy na sledovanie chýb sú navrhnuté tak, aby uľahčili a zvýšili efektivitu testovania. Ich používanie vám umožňuje mať jediné úložisko chýb, sledovať ich opätovné objavenie, kontrolovať rýchlosť a efektivitu odstraňovania chýb, vidieť najnestabilnejšie komponenty systému a tiež udržiavať komunikáciu medzi vývojovým tímom a testovacím tímom.

Výsledky prieskumu predstavujú objektívny základ pre tvorbu zadávacích podmienok AIS.

Technická úloha je dokument, ktorý definuje ciele, požiadavky a základné vstupné údaje potrebné pre vývoj automatizovaného riadiaceho systému.

Pri vývoji zadávacích podmienok (TOR) je potrebné vyriešiť nasledujúce úlohy:

· Inštalácia spoločný cieľ vytvorenie AIS;

Stanovte všeobecné požiadavky na navrhovaný systém;

· vypracovať a zdôvodniť požiadavky na informačnú, matematickú, softvérovú, technickú a technologickú podporu;

určiť zloženie subsystémov a funkčné úlohy;

vypracovať a zdôvodniť požiadavky na subsystémy;

určiť fázy vytvárania systému a načasovanie ich implementácie;

vykonať predbežnú kalkuláciu nákladov na vytvorenie systému a určiť úroveň ekonomická efektívnosť implementácia;

určiť zloženie účinkujúcich.

Typické požiadavky na zloženie a obsah zadávacích podmienok sú uvedené v tabuľke. 1.6.

Tabuľka 1.6. Zloženie a obsah zadávacích podmienok (GOST 34.602-89)

Exkluzívny projekt zabezpečuje vývoj predbežných konštrukčných riešení systému a jeho častí. Realizácia predbežného návrhu nie je striktne povinnou etapou. Ak sú hlavné konštrukčné rozhodnutia definované skôr alebo sú dostatočne zrejmé pre konkrétny AIS a objekt automatizácie, potom možno túto fázu vylúčiť z celkovej postupnosti práce.

funkcie AIS;

Funkcie subsystémov, ich ciele a očakávaný efekt implementácie;

Zloženie komplexov úloh a jednotlivých úloh;

koncepcia informačnú základňu a jeho rozšírená štruktúra;

Funkcie systému správy databázy;

Zloženie počítačového systému a iných technických prostriedkov;

Funkcie a parametre hlavných softvérových nástrojov.

Na základe výsledkov vykonanej práce sa vypracuje, odsúhlasí a schvaľuje dokumentácia v množstve potrebnom na opísanie celého súboru prijatých návrhových rozhodnutí a postačujúce pre ďalšiu prácu na vytvorení systému.

V súlade s GOST 19.102-77 fáza predbežného návrhu obsahuje dve etapy: vývoj predbežného návrhu; schválenie návrhu dizajnu.

Prvá fáza vývoja pozostáva z:

Predbežný vývoj štruktúry vstupných a výstupných údajov;

Spresnenie metód riešenia problému;

Vývoj všeobecný popis Algoritmus riešenia problémov;

vypracovanie štúdie uskutočniteľnosti;

Vypracovanie vysvetľujúcej poznámky.

Zároveň je dovolené niektoré diela kombinovať a vylučovať.

Nižšie je uvedený súbor dokumentov, ktoré by mali a môžu byť pripravené na konci návrhu návrhu.

Požadované dokumenty:

1) revidované referenčné podmienky pre dizajn a vývoj
prevádzka AIS;

2) špecifikácia kvalifikačné požiadavky na AIS;

3) súbor špecifikácií požiadaviek na funkčné softvérové ​​komponenty a popisy údajov;

4) špecifikácia požiadaviek na vnútorné rozhrania komponentov a rozhrania s vonkajším prostredím;

5) popis systému správy databázy, štruktúry a distribúcie programových a informačných objektov v databáze;

6) návrh smerníc pre informačnú bezpečnosť a zabezpečenie spoľahlivosti fungovania AIS;

7) návrh príručky správcu AIS;

8) návrh verzie užívateľskej príručky AIS;

9) aktualizovaný plán implementácie projektu;

10) aktualizovaný plán riadenia zabezpečenia kvality AIS;

11) vysvetlivka k predbežnému návrhu AIS;

12) bližšie špecifikovaná zmluva (dohoda) so zákazníkom
nový dizajn AIS.

Dokumenty vyhotovené po dohode so zákazníkom:

1) predbežný popis fungovania AIS;

2) schéma dátových tokov medzi funkčnými komponentmi AIS;

3) prepracovaná schéma architektúry AIS, interakcia softvérových a informačných komponentov, organizácia výpočtového procesu a distribúcia zdrojov;

4) popis ukazovateľov kvality komponentov a požiadaviek na ne podľa štádií vývoja AIS;

5) správa o technických a ekonomických ukazovateľoch, harmonograme realizácie projektu, prideľovaní zdrojov a rozpočtu;

6) tabuľka rozdelenia odborníkov podľa komponentov a fáz práce;

7) certifikáty vývojárov za právo používať technológie a automatizačné nástroje na vývoj AIS;

8) popis požiadaviek na zloženie a formy výsledných dokumentov podľa etáp práce;

9) plán na ladenie softvérových komponentov, ktorý mu poskytne metódy a prostriedky automatizácie testovania;

10) predbežný návod na podrobný návrh
vaniya, programovanie a ladenie komponentov AIS;

11) predbežný plán predaja a implementácie;

12) popis predbežnej štruktúry databázy.

Technický projekt systémy sú technická dokumentácia obsahujúca celosystémové konštrukčné riešenia, algoritmy riešenia problémov, ako aj hodnotenie ekonomickej efektívnosti AIS. V tejto fáze sa vykonáva súbor výskumných a experimentálnych prác na výber hlavných konštrukčných riešení a výpočet ekonomická efektívnosť systému. Zloženie a obsah technického projektu sú uvedené v tabuľke. 1.7

Tabuľka 1.7. Obsah technického projektu

Vo fáze „Pracovná dokumentácia“ sa realizuje tvorba softvérového produktu a vypracovanie všetkej sprievodnej dokumentácie. Dokumentácia musí obsahovať všetky potrebné a dostatočné informácie na zabezpečenie realizácie prác na uvádzaní AIS do prevádzky a jeho prevádzky, ako aj na zachovanie úrovne prevádzkových charakteristík (kvality) systému. Vypracovaná dokumentácia musí byť riadne vykonaná, odsúhlasená a schválená.

Vo fáze „Uvedenie do prevádzky“ sú pre AIS stanovené tieto hlavné typy skúšok: predbežné skúšky, skúšobná prevádzka a akceptačné skúšky. V prípade potreby sú povolené dodatočné skúšky systému a jeho častí.

V závislosti od vzťahu medzi komponentmi AIS a objektom automatizácie môžu byť testy autonómne a komplexné. Autonómne testy zahŕňajú systémové komponenty. Vykonávajú sa ako časti systému pripravené na uvedenie do skúšobnej prevádzky. Komplexné testy sa vykonávajú pre skupiny vzájomne prepojených komponentov (subsystémov) alebo pre systém ako celok.

Na plánovanie všetkých typov testov sa pripravuje dokument „Program a metódy testovania“. Vyhotoviteľ dokumentu je stanovený v zmluve alebo CK. Ako príloha môžu byť v dokumente zahrnuté testy alebo testovacie prípady.

Ladenie je časovo najnáročnejší proces návrhu. Skryté chyby sa niekedy objavia po mnohých rokoch prevádzky systému. Chybám sa nedá úplne vyhnúť, kvôli astronomickému množstvu možností systému. V dohľadnej dobe je takmer nemožné všetky skontrolovať, či správne fungujú.

Náklady na identifikáciu a opravu chýb v neskorších fázach návrhu rastú zhruba exponenciálne (obrázok 1.10).

Výskumníci počítajú 169 typov chýb, zhrnutých do 19 veľkých tried:

1) logické;

2) chyby pri manipulácii s údajmi;

3) vstupno-výstupné chyby;

4) chyby vo výpočtoch;

Ryža. 1.10. Relatívne náklady na nájdenie a opravu jednej chyby

5) chyby v používateľských rozhraniach;

6) chyby v operačnom systéme a pomocných programoch;

7) chyby rozloženia;

8) chyby v medziprogramových rozhraniach;

9) chyby v rozhraniach "Program - systémový softvér";

10) chyby pri manipulácii s externými zariadeniami;

11) chyby v párovaní s databázou (DB);

12) chyby inicializácie databázy;

13) chyby zmien na žiadosť zvonku;

14) chyby súvisiace s globálnymi premennými;

15) opakované chyby;

16) chyby v dokumentácii;

17) porušenie technické požiadavky;

18) neidentifikované chyby;

19) chyby operátora.

Nie všetky chyby pochádzajú od vývojára. Podľa rôznych výskumníkov je 6 až 19 % chýb generovaných chybami v dokumentácii.

Pomer vývoja a testovania v rôznych fázach návrhu AIS je znázornený na obr. 1.11.

Táto reťaz je len podmienečne „natiahnutá“ do línie. Vo vnútri sú vždy cykly návratu. Na identifikáciu chýb vývojári vytvárajú špeciálne testy a vykonávajú fázu ladenia. Ak sa nenájdu žiadne chyby, neznamená to, že neexistujú - možno sa test ukázal ako príliš slabý.

Ryža. 1.11. Pomer vývoja a testovania podľa štádií návrhu AIS

Technika ladenia zohľadňuje príznaky možných chýb:

Nesprávne spracovanie (nesprávna odpoveď, výsledok) - až 30%;

Nesprávny prenos kontroly - 16 %;

Nekompatibilita programov s použitými údajmi - 15%;

Nekompatibilita programov na prenesených dátach - až 9%.

Pri vývoji úloh ladenia sa riešia tieto úlohy:

Kompilácia testov;

Výber bodov, zón a kontrolných trás;

Stanovenie zoznamu kontrolovaných hodnôt a postupu na stanovenie ich hodnôt;

Nastavenie poradia testovania;

Posúdenie spoľahlivosti a zložitosti ladenia.

Ladiaci program musí prejsť každou vetvou algoritmu aspoň raz a zároveň priradiť premenným sériu hodnôt, zachytávajúcich hranice rozsahu, niekoľko hodnôt v ňom, nulové hodnoty a špeciálne body (ak existujú). Pre špecializované systémy vyviňte špeciálne ladiace jazyky. Môžu obsahovať relatívne malý počet príkazov (20-30) s dodatočnými nastaveniami na riešenie nasledujúcich úloh:

riadenie výstupov;

Modelovanie procesu vykonávania ladeného programu;

Vydanie stavu pamäťových komponentov v procese vykonávania programov;

Kontrola podmienok na dosiahnutie určitých stavov v procese vykonávania programu;

Stanovenie skúšobných hodnôt počiatočných údajov;

Implementácia podmienených prechodov v testovaní v závislosti od výsledkov vykonávania iných makier alebo rôznych testov;

Vykonávanie kancelárskych operácií na prípravu programu na testovanie.

Proces ladenia nemožno pripísať plne formalizovanému, preto existujú empirické odporúčania na jeho implementáciu, ktoré sú uvedené nižšie.

1. Prijmite sémantický, vopred premyslený prístup k ladeniu, naplánujte si proces ladenia a starostlivo navrhnite svoje testovacie súbory údajov z najjednoduchších možností, čím sa eliminujú najpravdepodobnejšie zdroje chýb.

2. Ak chcete zefektívniť proces testovania, zbierajte a analyzujte informácie:

O vlastnostiach a štatistikách chýb;

O špecifikách počiatočných údajov a postupnosti meniacich sa premenných v programe a ich vzájomnom ovplyvňovaní;

O štruktúre algoritmu a vlastnostiach jeho softvérovej implementácie.

3. Nájdite vždy len jednu chybu.

Využite nástroje na zaznamenávanie a zobrazovanie informácií o chybách, vrátane špeciálneho ladiaceho kódu v programe na tlač vzorových hodnôt premenných, hlásení o ukončení jednotlivých sekcií programu, trasovaní, logických podmienkach atď.

5. Pozorne si preštudujte prijaté výstupné údaje a porovnajte ich s očakávanými, vopred vypočítanými výsledkami.

6. Venujte pozornosť údajom, starostlivo analyzujte fungovanie programu pri použití hraničných hodnôt a pri nesprávnom zadaní; ovládať typy údajov, rozsahy, veľkosti polí a presnosť.

7. Použite analýzu toku údajov a riadenia na overenie a definovanie domén údajov pre rôzne cesty vykonávania programu.

8. Súčasne používajte rôzne nástroje na ladenie bez toho, aby ste sa zastavili pri jednej možnosti. Zahrňte automatizované nástroje a súčasne manuálne ladenie a testovanie, kontrolu textu programu z hľadiska fungovania, berúc do úvahy najpravdepodobnejšie chyby.

9. Zdokumentujte všetky nájdené a opravené chyby, ich rozdiely, umiestnenie a typ. Tieto informácie budú užitočné pri predchádzaní budúcim chybám.

10. Zmerajte zložitosť programov. Programy s vysokou zložitosťou majú väčšiu pravdepodobnosť chýb v špecifikácii a návrhu, zatiaľ čo programy s nízkou zložitosťou sú náchylnejšie na chyby v kódovaní a administratívne chyby.

11. Pre zvýšenie skúseností a precvičenie ladenia umelo umiestňujte chyby do programov. Po určitej dobe ladenia by mal programátor upozorniť na zostávajúce a nezistené chyby. Takéto „nasadzovanie“ sa široko používa na odhadovanie počtu nezistených chýb (ak sú umelé aj skutočné chyby jednotne zistené a opravené, potom podľa percenta zistených zavedených a skutočných chýb možno predpokladať, koľko z nich zostáva).

Vykonajú sa predbežné testy na zistenie prevádzkyschopnosti systému a rozhodnutie, či je možné ho prijať do skúšobnej prevádzky. Predbežné testy by mali byť vykonané po tom, čo vývojár odladí a otestuje dodaný softvér a hardvér systému a predloží príslušné dokumenty o ich pripravenosti na testovanie, ako aj po oboznámení personálu AIS s prevádzkovou dokumentáciou.

Skúšobná prevádzka systému sa vykonáva s cieľom zistiť skutočné hodnoty kvantitatívnych a kvalitatívnych charakteristík systému a pripravenosti personálu pracovať v podmienkach jeho prevádzky, ako aj určiť skutočnú účinnosť a prispôsobiť v prípade potreby dokumentáciu.

Preberacie skúšky sa vykonávajú s cieľom zistiť, či systém vyhovuje zadávacím podmienkam, posúdiť kvalitu skúšobnej prevádzky a rozhodnúť, či je možné systém prijať do trvalej prevádzky.

Etapy vývoja CASE-systémov

Za posledné desaťročie sa sformoval nový smer v navrhovaní informačných systémov – počítačom podporovaný dizajn pomocou nástrojov CASE. Termín CASE (Computer Aided System/Software Engineering) pôvodne označoval len automatizáciu vývoja softvéru; teraz pokrýva vývoj komplexného AIS vo všeobecnosti.

Spočiatku boli CASE technológie vyvinuté s cieľom prekonať nedostatky metodológie štrukturálneho návrhu (zložitosť pochopenia, vysoká pracovná náročnosť a náklady na používanie, ťažkosti pri vykonávaní zmien konštrukčných špecifikácií atď.) prostredníctvom automatizácie a integrácie podporných nástrojov.

CASE-technológie neexistujú samé o sebe, nie sú nezávislé. Automatizujú a optimalizujú používanie príslušnej metodiky a umožňujú zvýšiť efektivitu jej aplikácie.

Inými slovami, CASE technológie je súbor metodík pre analýzu, návrh, vývoj a údržbu komplexných softvérových systémov, podporovaný súborom vzájomne prepojených automatizačných nástrojov, ktoré umožňujú vizuálne modelovať predmetnú oblasť, analyzovať tento model vo všetkých fázach vývoja a údržby AIS a vyvíjať aplikácie v súlade s informačnými potrebami používateľov.

Moderné nástroje CASE pokrývajú širokú škálu podpory pre množstvo návrhových technológií AIS – od jednoduchých nástrojov na analýzu a dokumentáciu až po komplexné automatizačné nástroje pokrývajúce celý životný cyklus AIS. Najväčšia potreba využívania CASE-systémov sa prejavuje v počiatočných fázach vývoja - vo fázach analýzy a špecifikácie požiadaviek na AIS. Chyby, ktoré sa tu dopustili, sú takmer fatálne, ich cena ďaleko prevyšuje náklady na chyby v neskorších fázach vývoja.

Hlavným cieľom nástrojov CASE je oddeliť počiatočné fázy (analýza a návrh) od následných a nezaťažovať vývojárov detailmi vývojového prostredia a prevádzky systému.

Väčšina moderných systémov CASE využíva metodológie štrukturálne a/alebo objektovo orientovaná analýza a dizajn, založené na použití vizuálnych diagramov, grafov, tabuliek a diagramov.

Pri správnom používaní CASE nástrojov sa dosahuje výrazné zvýšenie produktivity práce, ktorá (podľa odhadov zahraničných firiem využívajúcich CASE technológie) je od 100 do 600% v závislosti od objemu, náročnosti práce a skúseností s CASE. Zároveň sa menia všetky fázy životného cyklu AIS, no najväčšie zmeny sa týkajú fáz analýzy a návrhu (tabuľky 2.5, 2.6) .

Tabuľka 2.5. Odhady nákladov práce podľa fáz životného cyklu AIS

Tabuľka 2.6. Porovnanie použitia CASE a tradičného rozvoj

Použitie CASE-tools nielen automatizuje štrukturálnu metodiku a umožňuje využívať moderné metódy systémového a softvérového inžinierstva, ale poskytuje aj ďalšie výhody (obr. 2.22), najmä:

1. zlepšuje kvalitu vyvíjaného softvéru prostredníctvom automatického generovania a riadenia;

2. umožňuje skrátiť čas vytvorenia prototypu AIS, čo umožňuje posúdiť kvalitu a efektívnosť projektu v počiatočnom štádiu;

3. urýchľuje proces navrhovania a vývoja;

4. umožňuje opätovné použitie vyvinutých komponentov;

5. podporuje sledovanie AIS;

6. oslobodzuje od rutinnej práce s dokumentovaním projektu, keďže využíva vstavaný dokumentátor;

7. Uľahčuje tímovú prácu na projekte.

Ryža. 2.22. Výhody vývoja AIS pomocou CASE-technológií: a- koeficient zníženia nákladov projektu; b - faktor zníženia času vývoja

Väčšina nástrojov CASE je založená na štyroch hlavných konceptoch: metodológia, metóda, zápis, nástroj [ 11,15, 16].

Metodológia definuje usmernenia pre hodnotenie a výber riešení pri návrhu a vývoji AIS, etapy prác, ich postupnosť, pravidlá pre rozdelenie a zadanie metód.

metódy - postupy na generovanie komponentov a ich popisy.

Notácie určené na opis celková štruktúra systémy, dátové prvky, kroky spracovania, môžu zahŕňať grafy, diagramy, tabuľky, vývojové diagramy, formálne a prirodzené jazyky.

Vybavenie- nástroje na podporu a zlepšenie metód; podporuje prácu používateľov pri vytváraní a úprave projektu v interaktívnom režime, pomáha organizovať projekt vo forme hierarchie úrovní abstrakcie, kontroluje zhodu komponentov.

Klasifikácia nástrojov CASE

Doteraz neexistuje stabilná klasifikácia nástrojov CASE, boli definované iba prístupy ku klasifikácii v závislosti od rôznych klasifikačných znakov. Nižšie sú uvedené niektoré z nich.

Orientácia na technologické etapy a procesy životného cyklu AIS:

1. prostriedky analýzy a návrhu. Používa sa na vytvorenie špecifikácií a návrhu systému. Podporujú známe metodológie dizajnu;

2. nástroje na návrh databázy. Zabezpečiť modelovanie logických údajov, generovanie databázových štruktúr;

3. nástroje riadenia požiadaviek;

4. nástroje na správu konfigurácie softvéru. Podpora programovania, testovania, automatického generovania softvéru zo špecifikácií;

5. dokumentačné prostriedky;

6. testovacie nástroje;

7. nástroje projektového manažmentu. Podpora plánovania, kontroly, interakcie;

8. nástroje reverzného inžinierstva určené na prenos existujúceho systému do nového prostredia.

Podporované metodológie návrhu[ 11, 12, 15, 16]:

1. funkčne orientovaný (štrukturálne orientovaný);

2. objektovo orientovaný;

3. komplexne orientované (súbor návrhových metodík).

Podporované grafické zápisy do grafov:

1. s pevným zápisom;

2. so samostatnými zápismi;

3. s najbežnejšími zápismi.

Stupeň integrácie:

1. pomocné programy (Nástroje), samostatne riešiace autonómnu úlohu;

2. vývojové balíky (Toolkit), ktoré sú súborom nástrojov, ktoré poskytujú pomoc pri jednej z tried softvérových úloh;

3. sady integrovaných nástrojov prepojených spoločnou databázou návrhov – úložisko, automatizujúce celú alebo časť práce rôznych etáp vytvárania AIS (Workbench).

Spoločný rozvoj projektu:

1. bez podpory kolektívneho rozvoja;

2. zameraná na vývoj projektu v reálnom čase;

3. zameraný na spôsob kombinovania podprojektov.

Typy nástrojov CASE:

1. analytické nástroje (veľké písmená); medzi odborníkmi sa nazývajú prostriedky počítačového plánovania. Pomocou týchto nástrojov CASE je zostavený model, ktorý odráža všetky existujúce špecifiká. Je zameraná na pochopenie všeobecných a partikulárnych mechanizmov fungovania, dostupných príležitostí, zdrojov, cieľov projektu v súlade s účelom podniku. Tieto nástroje vám umožňujú analyzovať rôzne scenáre a zhromažďovať informácie na prijímanie optimálnych rozhodnutí;

2. nástroje analýzy a návrhu (stredný prípad); sa považujú za podporu analýzy požiadaviek a fáz návrhu špecifikácií a štruktúry AIS. Hlavným výsledkom použitia stredného nástroja CASE je výrazné zjednodušenie návrhu systému, keďže sa z návrhu stáva iteratívny proces práce s požiadavkami AIS. Stredné CASE nástroje navyše poskytujú rýchlu dokumentáciu požiadaviek;

3. nástroje na vývoj softvéru (nižšie); podpora systémov vývoja softvéru AIS. Obsahujú systémové slovníky a grafické nástroje, ktoré eliminujú potrebu vývoja fyzických špecifikácií – existujú systémové špecifikácie, ktoré sú priamo preložené do programových kódov vyvíjaného systému (až 80 % kódov je generovaných automaticky). Hlavnými výhodami nižších CASE-nástrojov je výrazné skrátenie času vývoja, uľahčenie úprav, podpora schopnosti pracovať s prototypmi.

CASE nástroje tiež klasifikujú podľa typu a architektúry počítačová veda, ako aj typu operačný systém .

V súčasnosti trh softvérové ​​produkty Predstavuje ho široká škála softvéru, vrátane nástrojov CASE takmer ktorejkoľvek z uvedených tried.

Charakteristika nástrojov CASE

strieborný beh. Nástroj Silverrun CASE americkej spoločnosti Computer Systems Advisers, Inc. (CSA) sa používa na analýzu a návrh business class AIS a je zameraný skôr na špirálový model životného cyklu. Je použiteľný na podporu akejkoľvek metodológie založenej na oddelenej konštrukcii funkčných a informačných modelov (diagramy toku údajov a diagramy vzťahov medzi subjektmi).

Naladenie na konkrétnu metodiku je zabezpečené výberom požadovaného grafického zápisu modelov a súboru pravidiel pre kontrolu špecifikácií návrhu. Systém má pripravené nastavenia pre najbežnejšie metodiky: DATARUN (hlavná metodika podporovaná Silverrunom), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Informačné inžinierstvo. Ku každému konceptu predstavenému v projekte je možné pridať vlastné deskriptory. Architektúra Silverrun vám umožňuje rozširovať vývojové prostredie podľa potreby.

Silverrun má modulárna štruktúra a pozostáva zo štyroch modulov, z ktorých každý je samostatným produktom a je možné ho zakúpiť a použiť samostatne.

1. Modul na vytváranie modelov podnikových procesov vo forme diagramov toku dát vám Business Process Modeler (BPM) umožňuje modelovať fungovanie automatizovanej organizácie alebo vytváraného AIS. Schopnosť pracovať s modelmi veľkej zložitosti poskytujú funkcie automatického prečíslovania, práca so stromom procesov (vrátane vizuálneho drag and drop vetiev), oddeľovanie a pripájanie častí modelu pre kolektívny vývoj. Grafy je možné kresliť v niekoľkých preddefinovaných notáciách, vrátane Yourdon/DeMarco a Gane/Sarson. Je tiež možné vytvoriť si vlastné notácie, napríklad pridať používateľom definované polia k počtu deskriptorov zobrazených v diagrame.

2. Modul koncepčného modelovania údajov Entity-Relationship eXpert (ERX) umožňuje konštrukciu dátových modelov entitných vzťahov, ktoré nie sú špecifické pre implementáciu. Vstavaný expertný systém vám umožňuje vytvoriť správny normalizovaný dátový model zodpovedaním zmysluplných otázok o vzťahu dát. Je zabezpečená automatická konštrukcia dátového modelu z popisov dátových štruktúr. Analýza funkčných závislostí atribútov umožňuje kontrolovať súlad modelu s požiadavkami tretej normálnej formy a zabezpečiť ich implementáciu. Overený model sa odovzdá modulu Relational Data Modeler.

3. Modul relačného modelovania Relational Data Modeler (RDM) vám umožňuje vytvárať podrobné modely vzťahov medzi entitami a entitami navrhnuté na implementáciu v relačnej databáze. Tento modul dokumentuje všetky štruktúry súvisiace s budovaním databázy: indexy, spúšťače, uložené procedúry atď. Flexibilný zápis a rozšíriteľnosť úložiska vám umožňuje pracovať s akoukoľvek metodikou. Schopnosť vytvárať podschémy je konzistentná s prístupom ANSI SPARC k reprezentácii databázovej schémy. V jazyku podobvodov sú modelované uzly distribuovaného spracovania aj používateľské pohľady. Tento modul poskytuje návrh a kompletnú dokumentáciu relačných databáz.

4. Správca úložiska pracovnej skupiny Workgroup Repository Manager (WRM) sa používa ako dátový slovník na ukladanie informácií spoločných pre všetky modely a tiež poskytuje integráciu modulov Silverrun do jedného dizajnového prostredia.

Výhodou nástroja Silverrun CASE je jeho vysoká flexibilita a rôznorodosť obrázkových nástrojov na stavbu modelov a nevýhodou chýbajúca prísna vzájomná kontrola medzi komponentmi rôznych modelov (napríklad možnosť automatického šírenia zmien medzi DFD rôznych modelov). úrovne rozkladu). Treba však poznamenať, že tento nedostatok môže byť významný len v prípade použitia kaskádového modelu životného cyklu.

Nástroje zahrnuté v Silverrun:

1. automatické generovanie databázových schém pre najbežnejšie DBMS: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase;

2. prenos dát do nástrojov na vývoj aplikácií: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.

Je teda možné úplne definovať databázový stroj pomocou všetkých funkcií konkrétneho DBMS: spúšťače, uložené procedúry, obmedzenia referenčnej integrity. Pri vytváraní aplikácie sa údaje migrované z úložiska Silverrun použijú buď na automatické generovanie objektov rozhrania, alebo na ich rýchle manuálne vytvorenie.

Na výmenu údajov s inými nástrojmi na automatizáciu návrhu, vytváranie špecializovaných postupov na analýzu a overovanie špecifikácií návrhu a zostavovanie špecializovaných správ v súlade s rôznymi štandardmi poskytuje Silverrun tri spôsoby, ako poskytnúť informácie o návrhu do externých súborov.

1. Systém podávania správ. Výstupom zostáv sú textové súbory.

2. Systém export/import. Nastavuje sa nielen obsah exportného súboru, ale aj oddeľovače záznamov, polia v záznamoch, značky začiatku a konca textových polí. Takéto exportné súbory je možné vygenerovať a nahrať do úložiska. To umožňuje vymieňať si údaje s rôznymi systémami: inými nástrojmi CASE, DBMS, textové editory a tabuľky.

3. Uloženie úložiska do externých súborov s prístupom pomocou ovládačov ODBC. Pre prístup k dátam úložiska z najbežnejších DBMS je možné ukladať všetky informácie o projekte priamo vo formáte týchto DBMS.

Silverrun podporuje dva spôsoby skupinovej práce:

1) v štandardnej jednoužívateľskej verzii je mechanizmus na riadené oddeľovanie a spájanie modelov. Model je možné rozdeliť na časti a rozdeliť medzi viacerých vývojárov. Po podrobnom preštudovaní sú diely opäť zostavené do jedného modelu;

2) sieťová verzia Silverrunu umožňuje paralelnú skupinovú prácu s modelmi uloženými v sieťovom úložisku založenom na Oracle, Sybase alebo Informix DBMS. Zároveň môže s rovnakým modelom pracovať viacero vývojárov, keďže k blokovaniu objektov dochádza na úrovni jednotlivých prvkov modelu.

JAM. JYACC's Application Manager (JAM) je produkt JYACC. Hlavná prednosť je súlad s metodikou RAD, pretože JAM vám umožňuje rýchlo implementovať cyklus vývoja aplikácie, ktorý spočíva vo vygenerovaní ďalšej verzie prototypu aplikácie s prihliadnutím na požiadavky identifikované v predchádzajúcom kroku a jej predložení používateľovi.

JAM má modulárnu štruktúru a pozostáva z nasledujúcich komponentov:

1. jadro systému;

2. JAM/DBi - špecializované moduly rozhrania DBMS (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC atď.);

3. JAM/RW - modul generátora správ;

4. JAM/CASEi - špecializované moduly rozhrania pre nástroje CASE (JAM/CASE-TeamWork, JAM/CASE-Innovator atď.);

5. JAM/TPi - špecializované moduly rozhrania pre manažérov transakcií (napríklad JAM/TPi-Server TUXEDO atď.);

6. Jterm - špecializovaný emulátor X-terminálu.

Jadrom systému je hotový produkt a možno ho nezávisle použiť na vývoj aplikácií. Všetky ostatné moduly sú voliteľné a nemožno ich používať samostatne.

Jadro systému zahŕňa tieto hlavné komponenty:

1. editor obrazovky. Editor obrazovky obsahuje vývojové prostredie obrazovky, úložisko vizuálnych objektov, vlastný JAM DBMS - JDB, manažér transakcií, debugger, editor štýlov;

2. editor menu;

3. súbor pomocných nástrojov;

4. prostriedky na výrobu priemyselnej verzie aplikácie.

Pri používaní JAM je vývoj externého rozhrania aplikácie vizuálny dizajn a spočíva v vytváraní obrazovkových formulárov umiestnením štruktúr rozhrania na ne a definovaním vstupných / výstupných polí informácií na obrazovke. Dizajn rozhrania v JAM sa vykonáva pomocou editor obrazovky. Aplikácie vyvinuté v JAM majú rozhranie s viacerými oknami. Vývoj obrazovky spočíva v umiestnení prvkov rozhrania na ňu, ich zoskupení, nastavení hodnôt ich vlastností.

Editor menu umožňuje vyvíjať a ladiť systémy menu. Implementovaná schopnosť vytvárať obrázkové menu. Priradenie položiek ponuky k objektom aplikácie sa vykonáva v editore obrazovky.

Jadro JAM má v sebe zabudovaný relačný DBMS pre jedného používateľa JDB. Hlavným účelom JDB je prototypovanie aplikácií v prípadoch, keď je práca so štandardným DBMS nemožná alebo nepraktická. JDB implementuje nevyhnutné minimum relačných DBMS schopností, ktoré nezahŕňajú indexy, uložené procedúry, spúšťače a pohľady. Pomocou JDB môžete vytvoriť databázu, ktorá je identická s cieľovou databázou (až do funkcií, ktoré v JDB chýbajú) a vyvinúť významnú časť aplikácie.

Debugger vám umožňuje vykonávať komplexné ladenie vyvinutej aplikácie. Všetky udalosti, ktoré sa vyskytnú počas vykonávania aplikácie, sú sledované.

Verejné služby JAM zahŕňa tri skupiny:

1) Prevodníky súborov obrazovky JAM na text. JAM ukladá obrazovky ako binárne súbory vlastného formátu;

2) konfigurácia I/O zariadení. JAM a aplikácie s ním vytvorené nefungujú priamo s I/O zariadeniami. Namiesto toho JAM pristupuje k logickým I/O zariadeniam (klávesnica, terminál, správa);

3) údržba knižníc obrazoviek.

Jedným z voliteľných modulov JAM je generátor správ. Rozloženie správy sa vykonáva v editore obrazovky JAM. Popis správy sa vykonáva pomocou špeciálneho jazyka. Generátor zostáv vám umožňuje definovať údaje, ktoré sa majú vypísať do zostavy, zoskupenie výstupných informácií, formátovanie výstupu atď.

Z aplikácií vyvinutých pomocou JAM je možné vytvoriť spustiteľné moduly. Na to musia mať vývojári kompilátor C a linker.

JAM obsahuje vstavaný programovací jazyk JPL (JAM Procedural Language), pomocou ktorého je možné v prípade potreby napísať moduly implementujúce konkrétne akcie. Tento jazyk sa vykladá. Je možné vymieňať si informácie medzi vizuálne vytvoreným aplikačným prostredím a takýmito modulmi. Okrem toho JAM implementuje možnosť pripojenia externých modulov napísaných v jazykoch, ktoré sú kompatibilné vo volaniach funkcií s jazykom C.

Džem je udalosťami riadený systém pozostávajúce zo súboru udalostí - otváranie a zatváranie okien, stlačenie klávesu na klávesnici, spustenie systémového časovača, prijatie a odovzdanie kontroly nad každým prvkom obrazovky. Vývojár implementuje aplikačnú logiku definovaním obsluhy pre každú udalosť.

obsluhy udalostí JAM môže mať vstavané funkcie JAM aj funkcie napísané vývojárom v C alebo JPL. Sada vstavaných funkcií obsahuje viac ako 200 funkcií na rôzne účely; sú dostupné pre volania z funkcií napísaných v JPL aj C.

Priemyselná verzia aplikácie, vyvinutý s JAM, pozostáva z nasledujúcich komponentov:

1. spustiteľný modul interpreta aplikácií;

2. obrazovky, ktoré tvoria aplikáciu (dodávané ako samostatné súbory, ako súčasť knižníc obrazoviek alebo zabudované do tela tlmočníka);

3. externé moduly JPL (dodávané ako textové súbory alebo predkompilované; predkompilované

4. externé moduly JPL - ako samostatné súbory a ako súčasť knižníc obrazoviek);

5. konfiguračné súbory aplikácie - konfiguračné súbory klávesnice a terminálu, súbor systémových správ, všeobecný konfiguračný súbor.

Priama interakcia s DBMS je realizovaná modulmi JAM/DBi (Database interface). Spôsoby implementácie interakcie v JAM sú rozdelené do dvoch tried: manuálne a automatické.

o manuálnym spôsobom vývojár nezávisle píše dotazy SQL, v ktorých zdrojmi a cieľmi na prijímanie výsledkov vykonania dotazu môžu byť prvky rozhrania vizuálne navrhnutej externej úrovne a vnútorné premenné neviditeľné pre koncového používateľa.

Automatický režim implementovaný manažérom transakcií JAM. Je to realizovateľné pre typické bežné typy databázových operácií, takzvané QBE (Query By Example - dotazy podľa modelu), berúc do úvahy pomerne zložité vzťahy medzi databázovými tabuľkami a automatické ovládanie atribúty I/O polí na obrazovke v závislosti od typu transakcie (čítanie, zápis atď.), na ktorej sa vygenerovaná požiadavka zúčastňuje.

JAM vám umožňuje vytvárať aplikácie na prácu s viac ako 20 DBMS: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, DBMS kompatibilné s ODBC atď.

Charakteristickým rysom JAM je vysoká úroveň prenositeľnosti aplikácií medzi rôznymi platformami (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS atď.); možno požiadavka „prekresliť“ statické textové polia na obrazovkách ruským textom pri prenose medzi prostrediami DOS-Windows-UNIX. Prenosnosť navyše uľahčuje skutočnosť, že v JAM sa aplikácie vyvíjajú skôr pre virtuálne I/O zariadenia ako pre fyzické. Pri prenose aplikácie z platformy na platformu je teda spravidla potrebné iba určiť súlad medzi fyzickými I/O zariadeniami a ich logickými reprezentáciami pre aplikáciu.

Použitie SQL ako prostriedku na prepojenie s DBMS tiež pomáha zabezpečiť prenosnosť medzi DBMS. V prípade prenosu štruktúry databázy nemusia aplikácie vyžadovať žiadne úpravy, okrem inicializácie relácie. Je to možné, ak aplikácia nepoužívala rozšírenia SQL špecifické pre DBMS.

So zvyšujúcou sa záťažou systému a zložitosťou riešených úloh (distribúcia a heterogenita použitých zdrojov, počet súčasne pripojených používateľov, zložitosť aplikačnej logiky), trojvrstvový model architektúry"klient - server" pomocou transakčných manažérov. Komponenty JAM/TPi-Client a JAM/TPi-Server uľahčujú prechod na trojvrstvový model. Zároveň hrá kľúčovú úlohu modul JAM/TPi-Server, keďže hlavný problém implementácie trojvrstvového modelu spočíva v implementácii aplikačnej logiky v službách manažéra transakcií.

Rozhranie JAM/CASE umožňuje výmenu informácií medzi úložiskom objektov JAM a úložiskom nástrojov CASE. Výmena je podobná tomu, ako sa štruktúra databázy importuje do úložiska JAM priamo z databázy. Rozdiel je v tom, že výmena medzi úložiskami je obojsmerná.

Okrem modulov JAM / CASEi existuje aj modul JAM / CASEi Developer "s Kit. Pomocou tohto modulu môžete nezávisle vyvinúť rozhranie (t. j. špecializovaný modul JAM / CASEi) pre konkrétny nástroj CASE, ak existuje je hotový modul JAM / CASEi pre to neexistuje.

Existuje rozhranie, ktoré implementuje interakciu medzi nástrojom Silverrun CASE a JAM. Prenáša schému databázy a formuláre obrazovky aplikácie medzi nástrojom Silverrun-RDM CASE a JAM verzie 7.0; má dva režimy prevádzky:

1) priamy režim (Silverrun-RDM->JAM) je určený na vytváranie objektov CASE slovníka a prvkov úložiska JAM založených na reprezentácii schémy v Silverrun-RDM. Na základe reprezentácie dátových modelov rozhrania v Silverrun-RDM sa generujú obrazovky a prvky JAM úložiska. Most konvertuje tabuľky relačných schém RDM a vzťahy na sekvenciu objektov JAM vhodných typov. Technika vytvárania dátových modelov rozhrania v Silverrun-RDM zahŕňa použitie mechanizmu podschémy na prototypovanie obrazoviek aplikácií. Na základe popisu každého z podokruhov RDM most generuje obrazovku JAM;

2) reverzný režim (JAM->Silverrun-RDM) je určený na prenos modifikácií objektov CASE-dictionary do relačného modelu Silverrun-RDM.

Režim reengineeringu umožňuje preniesť úpravy všetkých vlastností obrazoviek JAM predtým importovaných z RDM do schémy Silvcrrun. Na kontrolu integrity databázy nie sú povolené zmeny schémy vo forme pridávania alebo odstraňovania tabuliek a polí tabuľky.

Jadro JAM má vstavané rozhranie pre nástroje na správu konfigurácie (PVCS na platforme Windows a SCCS na platforme UNIX). Knižnice obrazoviek a/alebo úložiská sa prenášajú pod kontrolu týchto systémov. Ak takéto systémy neexistujú, JAM nezávisle implementuje niektoré funkcie na podporu rozvoja tímu.

Na platforme MS-Windows má JAM vstavané rozhranie pre PVCS a akcie načítania/vrátenia sa vykonávajú priamo z prostredia JAM.

Vantage Team Builder (Westmount I-CASE). Vantage Team Builder je integrovaný softvérový produkt orientovaný na implementáciu s plnou podporou modelu životného cyklu vodopádu.

Vantage Team Builder poskytuje nasledujúce funkcie:

1. navrhovanie diagramov toku údajov, diagramov vzťahov medzi entitami, dátových štruktúr, blokové schémy programy a sekvencie obrazovkových formulárov;

2. návrh schém architektúry systému - SAD (návrh zloženia a prepojenia výpočtových zariadení, distribúcia systémových úloh medzi výpočtovými zariadeniami, modelovanie vzťahov klient-server, analýza využitia transakčných manažérov a funkcií fungovania systému v reálnom čase);

3. generovanie programového kódu v jazyku cieľovej DBMS s úplným softvérovým prostredím a generovanie SQL kódu pre tvorbu databázových tabuliek, indexov, integritných obmedzení a uložených procedúr;

4. programovanie v C s vloženým SQL;

5. riadenie verzií a projektovej konfigurácie;

6. viacužívateľský prístup do projektového úložiska;

7. generovanie projektovej dokumentácie pre štandardné a jednotlivé šablóny;

8. export a import dát projektu vo formáte CDIF (CASE Data Interchange Format).

Vantage Team Builder sa dodáva v rôznych konfiguráciách v závislosti od použitého systému správy databáz (ORACLE, Informix, Sybase alebo Ingres) alebo nástrojov na vývoj aplikácií (Uniface). Konfigurácia Vantage Team Builder pre Uniface sa líši od ostatných tým, že sa čiastočne zameriava na špirálový model životného cyklu vďaka schopnostiam rýchleho prototypovania. Na popis projektu AIS sa používa veľký súbor diagramov.

Pri konštrukcii všetkých typov diagramov je zabezpečená kontrola zhody modelov so syntaxou použitých metód, ako aj kontrola zhody prvkov rovnakého mena a ich typov pre rôzne typy diagramov.

Pri konštrukcii diagramov dátových tokov DFD je zabezpečená kontrola zhody diagramov rôznych úrovní rozkladu. DFD najvyššej úrovne sa overuje pomocou matice zoznamu udalostí ELM. Na riadenie rozkladu kompozitných dátových tokov sa používa niekoľko možností ich popisu: vo formulári diagramy štruktúry údajov DSD alebo in zápisy BNF (forma Backus - Naur).

Na zostavenie SAD sa používa rozšírená notácia DFD, ktorá umožňuje zaviesť koncepty procesorov, úloh a periférnych zariadení, čo poskytuje prehľadnosť návrhových rozhodnutí.

Pri budovaní dátového modelu vo forme ERD sa normalizuje a zavádza sa definícia fyzických názvov dátových prvkov a tabuliek, ktoré sa použijú v procese generovania fyzickej dátovej schémy konkrétneho DBMS. Poskytuje možnosť určiť alternatívne kľúče entít a polí, ktoré tvoria dodatočné vstupné body do tabuľky (polia indexov), a mohutnosť vzťahov medzi entitami.

Prítomnosť univerzálneho systému generovania kódu založeného na špecifikovaných prostriedkoch prístupu k úložisku projektu umožňuje vývojárom udržiavať vysokú úroveň vykonávania disciplíny projektu: prísny postup pri generovaní modelov; pevná štruktúra a obsah dokumentácie; automatické generovanie zdrojových kódov programu atď.; to všetko zabezpečuje zvýšenie kvality a spoľahlivosti vyvíjaného IS.

Na prípravu projektovej dokumentácie možno využiť publikačné systémy ako FrameMaker, Interleaf alebo Word Perfect. Štruktúra a skladba projektovej dokumentácie sú konfigurované v súlade s určenými normami. Úprava sa vykonáva bez zmeny návrhových rozhodnutí.

Pri vývoji veľkých AIS celý systém ako celok zodpovedá jednému projektu ako kategória Vantage Team Builder. Projekt je možné rozložiť na množstvo systémov, z ktorých každý zodpovedá nejakému relatívne autonómnemu subsystému AIS a je vyvíjaný nezávisle od ostatných. V budúcnosti je možné integrovať projektové systémy.

Proces návrhu AIS pomocou Vantage Team Builder je implementovaný v štyroch po sebe nasledujúcich fázach (fázach) - analýza, architektúra, dizajn a implementácia, zároveň sa dokončené výsledky každej etapy úplne alebo čiastočne prenesú (importujú) do ďalšej fázy. Všetky diagramy, okrem ERD, sú prevedené na iný typ alebo menia svoj vzhľad v súlade s vlastnosťami aktuálnej fázy. DFD sa teda konvertujú vo fáze architektúry na SAD, DSD na DTD. Po dokončení importu sa preruší logické spojenie s predchádzajúcou fázou, t.j. v diagramoch je možné vykonať všetky potrebné zmeny.

Konfigurácia Vantage Team Builder pre Uniface poskytuje zdieľanie dvoch systémov v rámci jedného technologického návrhového prostredia, pričom databázové schémy (modely SQL) sa prenášajú do úložiska Uniface a naopak, aplikačné modely generované nástrojmi Uniface je možné prenášať do Úložisko Vantage Team Builder . Prípadné nezrovnalosti medzi úložiskami oboch systémov sú odstránené pomocou špeciálnej utility. Vývoj obrazovkových formulárov v prostredí Uniface sa vykonáva na základe FSD diagramov sekvencií formulárov po importovaní SQL modelu. Vývojová technológia AIS založená na tejto konfigurácii je znázornená na obr. 2.23.

Štruktúra úložiska uloženého v cieľovom DBMS a rozhrania Vantage Team Builder sú otvorené, čo v princípe umožňuje integráciu s akýmikoľvek inými nástrojmi.

Uniface. Produkt Compuware je vývojové prostredie pre rozsiahle aplikácie v architektúre „klient-server“ a má nasledujúcu architektúru komponentov:

1. Repozitár aplikačných objektov (úložisko aplikačných objektov) obsahuje metadáta automaticky používané všetkými ostatnými komponentmi počas životného cyklu AIS (modely aplikácií, popisy údajov, obchodné pravidlá, formuláre obrazovky, globálne objekty a šablóny). Úložisko môže byť uložené v ktorejkoľvek z databáz podporovaných Uniface;

Ryža. 2.23. Interakcia medzi Vantage Team Builder a Uniface

2. Application Model Manager podporuje aplikačné modely (E-R modely), z ktorých každý je podmnožinou celkovej databázovej schémy z pohľadu tejto aplikácie a zahŕňa zodpovedajúce grafický editor;

3. Nástroj na tvorbu rýchlych aplikácií rýchla tvorba obrazovkové formuláre a zostavy založené na objektoch aplikačného modelu. Zahŕňa grafický editor formulárov, nástroje na vytváranie prototypov, ladenie, testovanie a dokumentáciu. Implementované rozhranie s rôznymi typmi ovládania okien Open Widget Interface pre existujúce grafické rozhrania - MS Windows (vrátane VBX), Motif, OS/2. Universal Presentation Interface umožňuje používať rovnakú verziu aplikácie v prostredí rôznych grafických rozhraní bez zmeny programového kódu;

4. Služby pre vývojárov (služby pre vývojárov) sa používajú na podporu veľkých projektov a implementáciu kontroly verzií (Uniface Version Control System), prístupových práv (vymedzenie právomocí), globálnych úprav atď. To poskytuje vývojárom prostriedky paralelného návrhu, vstupu výstupná kontrola, vyhľadávanie, prezeranie, údržba a vydávanie správ o údajoch systému na správu verzií;

5. Deployment Manager (správa distribúcie aplikácií) - nástroje, ktoré umožňujú pripraviť vytvorenú aplikáciu na distribúciu, nainštalovať ju a udržiavať (platforma používateľa sa môže líšiť od platformy vývojára). Zahŕňajú sieťové a DBMS ovládače, aplikačný server (polyserver), distribúciu aplikácií a nástroje na správu databáz. Uniface podporuje rozhranie s takmer všetkými známymi hardvérovými a softvérovými platformami, DBMS, CASE nástrojmi, sieťovými protokolmi a manažérmi transakcií;

6. Personal Series (osobné nástroje) sa používajú na vytváranie zložitých dopytov a zostáv v grafickej forme (Personal Query a Personal Access - PQ / PA), ako aj na prenos údajov do systémov ako WinWord a Excel;

7. Distributed Computing Manager - integračný nástroj s manažérmi transakcií Tuxedo, Encina, CICS, OSF DCE.

Verzia Uniface 7 plne podporuje distribuovaný výpočtový model a trojvrstvovú architektúru klient-server (s možnosťou zmeniť schému dekompozície aplikácie za behu). Aplikácie vytvorené pomocou Uniface 7 je možné spúšťať v heterogénnych operačných prostrediach s použitím rôznych sieťových protokolov súčasne na niekoľkých heterogénnych platformách (vrátane internetu).

Komponenty Uniface 7 zahŕňajú:

1. Uniface Application Server - aplikačný server pre distribuované systémy;

2. WebEnabler - serverový softvér na prevádzku aplikácií na internete a intranete;

3. Name Server - serverový softvér, ktorý zabezpečuje využívanie distribuovaných aplikačných zdrojov;

4. PolyServer – prostriedok na prístup k dátam a integráciu rôznych systémov.

Podporované DBMS zahŕňajú DB2, VSAM a IMS; PolyServer tiež poskytuje interoperabilitu s OS MVS.

Dizajnér/2000 + Vývojár/2000. ORACLE Designer/2000 2.0 je integrovaný CASE nástroj, ktorý v spojení s vývojovými nástrojmi Developer/2000 poskytuje plnú podporu životného cyklu softvéru pre systémy využívajúce ORACLE DBMS.

Designer/2000 je rodina metodík a ich podporných softvérových produktov. Základná metodika Designer/2000 (CASE*Method) je metodika návrhu konštrukčného systému, ktorá plne pokrýva všetky fázy životného cyklu AIS. Vo fáze plánovania sa stanovia ciele tvorby systému, priority a obmedzenia, vypracuje sa architektúra systému a plán rozvoja AIS. V procese analýzy sa vytvárajú: model informačných potrieb (diagram entita-vzťah), diagram funkčnej hierarchie (založený na funkčnom rozklade AIS), krížová referenčná matica a diagram toku údajov.

Vo fáze návrhu sa vypracuje detailná architektúra AIS, navrhne sa schéma relačnej databázy a programové moduly, vytvoria sa krížové referencie medzi komponentmi AIS na analýzu ich vzájomného vplyvu a kontroly zmien.

Vo fáze implementácie sa vytvorí databáza, vybudujú sa aplikačné systémy, tie sa testujú, kontroluje sa kvalita a zhoda s požiadavkami používateľov. Vytvorená systémová dokumentácia, školiace materiály a užívateľské príručky. V etapách prevádzky a údržby sa analyzuje výkonnosť a integrita systému, vykonáva sa podpora a v prípade potreby úprava AIS.

Designer/2000 poskytuje grafické rozhranie pre vývoj rôznych doménových modelov (diagramov). V procese vytvárania modelov sa informácie o nich vkladajú do úložiska. Designer/2000 obsahuje nasledujúce komponenty.

Odoslanie dobrej práce do databázy znalostí je jednoduché. Použite nižšie uvedený formulár

Študenti, postgraduálni študenti, mladí vedci, ktorí pri štúdiu a práci využívajú vedomostnú základňu, vám budú veľmi vďační.

Uverejnené dňa http://www.allbest.ru/

Ministerstvo školstva a vedy Ruskej federácie

federálny štátny rozpočet vzdelávacia inštitúcia vyššie odborné vzdelanie

Saint Petersburg Štátna univerzita technológie a dizajnu

Práca na kurze

Podľa disciplíny: "Architektúra informačných systémov"

Na tému: "Návrh automatizovaných informačných systémov"

ÚVOD

V súčasnosti sa výpočtová technika čoraz viac rozširuje tak vo výrobe, ako aj v pracovných tokoch podnikov a zoznam úloh, ktoré zahŕňa, sa stále rozširuje. Objem a komplexnosť spracovávaných informácií neustále narastá a vyžadujú si nové typy ich prezentácie.

Tu sú len niektoré z výhod, ktoré používanie výpočtovej techniky poskytuje v práci organizácie:

* Možnosť operatívnej kontroly spoľahlivosti informácií;

* Zníženie počtu možných chýb pri generovaní odvodených údajov;

* Možnosť rýchleho prístupu k akýmkoľvek údajom;

* Schopnosť rýchlo vytvárať správy;

ѕ Úspora mzdových nákladov a času stráveného spracovaním informácií.

Všetky tieto výhody v súčasnosti oceňujú mnohé organizácie, preto dnes prebieha proces rýchleho rozvoja automatizovaných informačných systémov a ich zavádzania do práce rôznych inštitúcií. V tomto smere je téma, ktorú som si zvolil, v súčasnosti veľmi aktuálna.

Hlavnou črtou odvetvia automatizačných systémov rôznych podnikov a inštitúcií, ktoré sa vyznačujú širokou škálou vstupných údajov s rôznymi cestami spracovania týchto údajov, je koncentrácia zložitosti v počiatočných fázach analýzy požiadaviek a návrhu systémových špecifikácií s relatívne nízka zložitosť a náročnosť následných etáp. V skutočnosti tu dochádza k pochopeniu toho, čo bude budúci systém robiť a ako bude fungovať, aby splnil požiadavky, ktoré sú mu predložené. Totiž nejasnosť a nekompletnosť systémových požiadaviek, nevyriešené problémy a chyby vzniknuté v etapách analýzy a návrhu spôsobujú v nasledujúcich etapách ťažké, často neriešiteľné problémy a v konečnom dôsledku vedú k zlyhaniu celého diela. Jednoduchá replikácia aj veľmi dobrého podnikového manažérskeho systému nikdy plne neuspokojí zákazníka, keďže nedokáže zohľadniť jeho špecifiká. Navyše v tomto prípade vzniká problém vybrať si presne ten systém, ktorý je pre konkrétny podnik najvhodnejší. A tento problém je ďalej komplikovaný skutočnosťou, že kľúčové slová charakterizujúce rôzne informačné systémy sú prakticky rovnaké:

ѕ Jednotné informačné prostredie podniku;

* Režim v reálnom čase;

ѕ Nezávislosť od legislatívy;

ѕ Integrácia s inými aplikáciami (vrátane systémov, ktoré už v podniku bežia);

* Postupná implementácia atď.

V skutočnosti sa problém integrovanej automatizácie stal relevantným pre každý podnik. A aby ste sa mohli zapojiť do komplexnej automatizácie, potrebujete štruktúrované znalosti v tejto oblasti.

Cieľ práce: Oboznámiť sa s konceptom automatizovaných informačných systémov, zvážiť proces návrhu.

Na dosiahnutie cieľa je potrebné vyriešiť nasledujúce úlohy:

§ formulovať definície základných pojmov a pojmov;

§ Zvážte ciele a zámery dizajnu;

§ Oboznámte sa s hlavnými fázami projektovania;

§ identifikovať fázy vývoja automatizovaných informačných systémov;

§ Zvážte zloženie a štruktúru zadávacích podmienok a technického projektu.

1. VYMEDZENIE POJMOV AUTOMATIZOVANÝ INFORMAČNÝ SYSTÉM (AIS), INFORMAČNÝ SYSTÉM (IS), PROJEKT A NÁVRH

Pri štruktúrovaní procesov v oblasti ľudskej činnosti sa využívajú rôzne metódy izolácie komponentov (subprocesov) a získavajú sa rôzne výsledky ako výskum a vývoj, analýza a syntéza atď.

Je celkom prijateľné považovať dizajn za zovšeobecňujúci koncept pre mnohé intelektuálne úlohy, ktoré sa riešia v procese myslenia a rozlišujú sa rôznymi spôsobmi.

Koreň slova dizajn zdôrazňuje spojenie medzi procesom s týmto názvom a hlavnými výsledkami tohto procesu, ktorými sú:

a) projekcia - to, čo sa získa analýzou zložitých javov s cieľom získať zjednodušené zobrazenia a

b) dizajn – čo sa získa syntetizovaním zložitých zobrazení zo súboru jednoduchších obrázkov.

Uvedené dva dôvody odôvodnili súčasný výber slova dizajn ako výraz označujúci podstatu hlavnej činnosti, ktorá sa v informatike vykonáva.

Pri navrhovaní informačných systémov sú objektmi dizajnu informačné systémy, čo je pre informatiku celkom prirodzené (keďže IS sú považované za jej hlavné objekty).

Ako viete, informačné systémy sú schopné odrážať najrozmanitejšie javy vesmíru, a preto sa všetky javy tiež ukážu ako potenciálne objekty dizajnu.

Informačné systémy sa v mnohých prípadoch ukazujú ako predmety dizajnu, t.j. tí umelci, ktorí vykonávajú samotný proces navrhovania. Štúdiom procesu navrhovania sa tak vo veľkej miere zaoberáme štúdiom informačných systémov.

Systémom sa rozumie akýkoľvek objekt, ktorý sa súčasne považuje za jeden celok aj za súbor heterogénnych prvkov spojených v záujme dosiahnutia stanovených cieľov. Systémy sa od seba výrazne líšia tak zložením, ako aj hlavnými cieľmi.

V informatike je pojem systém rozšírený a má mnoho sémantických významov. Najčastejšie sa používa vo vzťahu k súboru hardvéru a softvéru. Doplnenie pojmu informačný systém o slovo informačný systém odráža účel jeho vzniku a fungovania. Informačné systémy zabezpečujú zber, uchovávanie, spracovanie, vyhľadávanie a vydávanie informácií potrebných v procese rozhodovania o úlohách z akejkoľvek oblasti. Pomáhajú analyzovať problémy a vytvárať nové produkty.

Informačný systém (IS) - vzájomne prepojený súbor nástrojov, metód a personálu slúžiaci na uchovávanie, spracovanie a vydávanie informácií za účelom dosiahnutia cieľa.

Moderné informačné technológie poskytujú široké možnosti implementácie IS, ktorých výber vychádza z požiadaviek predpokladaných používateľov, ktoré sa spravidla v procese vývoja menia.

Pridanie pojmu „automatizovaný“ k pojmu „systém“ odráža spôsoby, akými sa takýto systém vytvára a prevádzkuje.

Automatizovaný systém (podľa GOST) je systém pozostávajúci zo vzájomne prepojeného súboru organizačných jednotiek a súboru automatizačných nástrojov, ktorý implementuje automatizované funkcie pre určité typyčinnosti.

Automatizovaný informačný systém (AIS) je komplex softvérových, technických, informačných, jazykových, organizačných a technologických nástrojov a pracovníkov určených na riešenie problémov referenčných a informačných služieb a (alebo) informačnú podporu používateľov.

Automatizovaný informačný systém je súbor informácií, ekonomických a matematických metód a modelov, technických, softvérových, technologických nástrojov a špecialistov určených na spracovanie informácií a prijímanie manažérskych rozhodnutí.

Hlavným účelom automatizovaných informačných systémov nie je len zhromažďovať a uchovávať elektronické informačné zdroje, ale aj poskytovať používateľom k nim prístup. Jednou z najdôležitejších vlastností AIS je organizácia vyhľadávania dát v ich informačných poliach (databázach).

Pod projektom AIS budeme rozumieť projektovú a technologickú dokumentáciu, ktorá poskytuje popis konštrukčných riešení pre tvorbu a prevádzku IS v konkrétnom softvérovom a hardvérovom prostredí.

Je možné rozlíšiť tieto hlavné charakteristické črty projektu ako objektu riadenia:

Obmedzenie konečného cieľa;

obmedzené trvanie;

obmedzený rozpočet;

potrebné obmedzené zdroje;

novinka pre podnik, pre ktorý sa projekt realizuje;

zložitosť;

právnu a organizačnú podporu.

Pri zvažovaní plánovania a riadenia projektu je potrebné si jasne uvedomiť, že hovoríme o riadení určitého dynamického objektu. Preto musí byť systém riadenia projektov dostatočne flexibilný, aby umožňoval úpravy bez globálnych zmien pracovný program. Výkon práce je zabezpečený dostupnosťou potrebných zdrojov: materiálov; vybavenie; ľudské zdroje. Z hľadiska teórie systémov riadenia musí byť projekt ako objekt riadenia pozorovateľný a zvládnuteľný, to znamená, že sa rozlišujú niektoré charakteristiky, pomocou ktorých je možné neustále sledovať priebeh projektu. Okrem toho sú potrebné mechanizmy na včasné ovplyvnenie postupu projektu.

Dizajn AIS sa chápe ako proces premeny vstupných informácií o objekte, metódach a skúsenostiach s navrhovaním objektov podobného účelu v súlade s GOST do projektu IS.

Z tohto hľadiska sa návrh AIS redukuje na dôslednú formalizáciu návrhových rozhodnutí v rôznych fázach životného cyklu AIS: plánovanie a analýza požiadaviek, technický a detailný návrh, implementácia a prevádzka AIS.

Rozsah vyvíjaných systémov určuje zloženie a počet účastníkov procesu navrhovania. Pri veľkom objeme a napätých termínoch realizácie projekčných prác sa na vývoji systému môže podieľať viacero projekčných tímov (vývojových organizácií). V tomto prípade je vyčlenená materská organizácia, ktorá koordinuje činnosť všetkých spoluvykonávajúcich organizácií.

Technológia návrhu AIS je súbor metodológie a nástrojov na návrh AIS, ako aj metód a prostriedkov jej organizácie (riadenie procesu tvorby a modernizácie projektu AIS).

Technológia návrhu je založená na technologickom procese, ktorý určuje akcie, ich postupnosť, požadované zloženie účinkujúcich, nástroje a zdroje.

Technologický proces navrhovania AIS ako celku je rozdelený na súbor sériovo-paralelných, prepojených a podriadených reťazcov akcií, z ktorých každý môže mať svoj vlastný predmet. Technológia návrhu je teda daná regulovaným sledom technologických operácií vykonávaných na základe konkrétnej metódy, v dôsledku čoho je jasné nielen to, čo je potrebné urobiť pre vytvorenie projektu, ale aj ako, kým a v aká postupnosť.

Predmetom akejkoľvek zvolenej technológie návrhu by mala byť reflexia vzájomne súvisiacich procesov návrhu vo všetkých fázach životného cyklu AIS. Medzi hlavné požiadavky na zvolenú konštrukčnú technológiu patria:

Vytvorený projekt musí spĺňať požiadavky zákazníka;

maximálna reflexia všetkých fáz životného cyklu projektu;

zabezpečenie minimálnych nákladov na prácu a náklady na dizajn a údržbu projektu;

technológia by mala byť základom komunikácie medzi návrhom a údržbou projektu;

· rast produktivity práce projektanta;

Spoľahlivosť návrhu a prevádzky projektu;

Jednoduchá údržba projektovej dokumentácie.

Základom technológie dizajnu AIS je metodológia, ktorá definuje podstatu, hlavné charakteristické technologické znaky.

Metodológia dizajnu predpokladá existenciu určitého konceptu, princípov dizajnu, realizovaných súborom metód, ktoré však musia byť podporované nejakými prostriedkami.

Projekčná organizácia zahŕňa definovanie metód interakcie dizajnérov medzi sebou a so zákazníkom v procese tvorby projektu AIS, čo môže byť podporené aj súborom špecifických nástrojov.

informačný systém počítačom podporovaný dizajn

2. ÚČEL A CIELE DIZAJNU

Návrh informačných systémov vždy začína definovaním účelu projektu. Účelom návrhu je výber technickej a formačnej informačnej, matematickej, softvérovej a organizačnej a právnej podpory.

Výber technickej podpory by mal byť taký, aby sa zabezpečil včasný zber, registrácia, prenos, uchovávanie, vypĺňanie a spracovanie informácií.

Informačná podpora by mala zabezpečiť vytvorenie a prevádzku jednotného informačného fondu systému, reprezentovaného rôznymi informačnými poľami, súborom údajov alebo databázou.

Tvorba matematického softvéru pre systémy zahŕňa súbor metód a algoritmov na riešenie funkčných problémov. Pri tvorbe systémového softvéru sa osobitná pozornosť venuje vytvoreniu súboru programov a užívateľských pokynov a výberu efektívnych softvérových produktov.

Hlavnou úlohou každého úspešný projekt je zabezpečiť, aby v čase spustenia systému a počas celej doby jeho prevádzky bolo možné zabezpečiť:

požadovaná funkčnosť systému a stupeň prispôsobenia meniacim sa podmienkam jeho prevádzky;

požadovaná priepustnosť systému;

požadovaný čas odozvy systému na požiadavku;

· bezproblémová prevádzka systému v požadovanom režime, inými slovami - pripravenosť a dostupnosť systému na spracovanie požiadaviek užívateľov;

jednoduchosť prevádzky a podpora systému;

potrebné zabezpečenie.

Výkon je hlavným faktorom, ktorý určuje efektívnosť systému. Dobrý dizajn je základom vysoko výkonného systému.

Návrh automatizovaných informačných systémov pokrýva tri hlavné oblasti:

navrhovanie dátových objektov, ktoré budú implementované v databáze;

navrhovanie programov, obrazovkových formulárov, zostáv, ktoré zabezpečia vykonávanie dátových dotazov;

· zohľadnenie konkrétneho prostredia alebo technológie, a to: topológie siete, konfigurácie hardvéru, použitej architektúry (súborový server alebo klient-server), paralelného spracovania, distribuovaného spracovania údajov atď.

Dizajn je v reálnych podmienkach hľadaním cesty, ktorá uspokojí požiadavky funkčnosti systému pomocou dostupných technológií s prihliadnutím na dané obmedzenia.

Každý projekt podlieha množstvu absolútnych požiadaviek, napríklad maximálny čas vývoja projektu hotovostné investície do projektu a pod. Jednou z ťažkostí dizajnu je, že nie je tak štruktúrovaný ako analýza požiadaviek projektu alebo implementácia konkrétneho konštrukčného riešenia.

3. ETAPA NÁVRHU

Proces tvorby AIS je rozdelený do niekoľkých etáp (etáp), ohraničených určitým časovým rámcom a končiacich vydaním konkrétneho produktu.

Každý projekt, bez ohľadu na zložitosť a množstvo práce potrebnej na jeho realizáciu, prechádza určitými fázami svojho vývoja. Zo stavu, keď „zatiaľ neexistuje projekt“ do stavu, keď „projekt už neexistuje“. Súbor etáp vývoja od vzniku nápadu až po dokončenie projektu sa zvyčajne delí na fázy.

Účelom počiatočných fáz vytvárania AIS, vykonávaných vo fáze analýzy činností organizácie, je vytvorenie požiadaviek na AIS, ktoré správne a presne odrážajú ciele a zámery zákazníckej organizácie. Pre špecifikáciu procesu tvorby AIS, ktorý zodpovedá potrebám organizácie, je potrebné zistiť a jasne formulovať, o aké potreby ide. K tomu je potrebné určiť požiadavky zákazníkov na AIS a zobraziť ich v jazyku modelov v požiadavkách na vypracovanie projektu AIS tak, aby bol zabezpečený súlad s cieľmi a zámermi organizácie.

Možno rozlíšiť tieto fázy vývoja automatizovaných informačných systémov:

3.1 Formovanie koncepcie. Koncepčná fáza

Toto zahŕňa:

Formovanie myšlienky;

Vytvorenie kľúčového projektového tímu;

štúdium motivácií a požiadaviek zákazníka a ostatných účastníkov;

zber počiatočných údajov a analýza existujúceho stavu;

stanovenie základných požiadaviek a obmedzení, požadovaných materiálnych, finančných a pracovných zdrojov;

Porovnávacie hodnotenie alternatív;

predkladanie návrhov, ich preskúmanie a schválenie.

Úloha formovania požiadaviek na AIS je jednou z najzodpovednejších, ťažko formalizovateľných a najdrahších a ťažko opraviteľných v prípade chyby. Moderné nástroje a softvérové ​​produkty umožňujú rýchlo vytvárať AIS podľa hotových požiadaviek. Tieto systémy však často neuspokojujú zákazníkov, vyžadujú početné vylepšenia, čo vedie k prudkému nárastu skutočných nákladov na AIS. Hlavným dôvodom tejto situácie je nesprávna, nepresná alebo neúplná definícia požiadaviek AIS v štádiu analýzy.

3.2 Príprava technického návrhu

§ vypracovanie hlavného obsahu základnej štruktúry projektu;

§ vypracovanie a schválenie zadávacích podmienok;

§ plánovanie, dekompozícia základného konštrukčného modelu projektu;

§ vypracovanie odhadov a rozpočtu projektu;

§ rozvoj kalendárne plány a rozšírené pracovné plány;

§ podpísanie zmluvy so zákazníkom;

§ uvedenie do prevádzky komunikačných prostriedkov účastníkov projektu a prostriedkov monitorovania postupu prác.

3.3 Dizajn

Vo fáze návrhu sa určujú podsystémy, ich vzťahy, vyberajú sa najefektívnejšie spôsoby navrhovania a využívania zdrojov. Charakteristické práce tejto fázy:

§ realizácia základných projektových prác;

§ vývoj súkromných technických špecifikácií;

§ realizácia koncepčného návrhu;

§ príprava technických špecifikácií a pokynov;

§ prezentácia vývoja dizajnu, preskúmanie a schválenie.

Vo fáze návrhu sa najskôr vytvoria dátové modely. Projektanti dostanú výsledky analýzy ako počiatočnú informáciu. Vytváranie logických a fyzických dátových modelov je hlavnou súčasťou návrhu databázy. Informačný model získaný počas analýzy sa najskôr prevedie na logický a potom na fyzický dátový model.

3.4 Vývoj

Vo fáze vývoja sa vykonáva koordinácia a prevádzková kontrola prác na projekte, vyrábajú sa, kombinujú a testujú subsystémy.

Po úspešnom absolvovaní autonómneho testu je modul zaradený do vyvíjanej časti systému a skupina vygenerovaných modulov prejde linkovými testami, ktoré by mali sledovať ich vzájomné ovplyvňovanie.

Ďalej sa skupina modulov testuje na spoľahlivosť, to znamená, že prejdú po prvé testami simulácie porúch systému a po druhé testami času medzi poruchami. Prvá skupina testov ukazuje, ako dobre sa systém zotavuje po zlyhaniach softvéru, hardvéru. Druhá skupina testov určuje stupeň stability systému počas bežnej prevádzky a umožňuje vyhodnotiť dobu prevádzky systému. Sada testov stability by mala zahŕňať testy, ktoré simulujú špičkové zaťaženie systému.

Potom celá sada modulov prejde systémovým testom - testom internej akceptácie produktu, ktorý ukazuje úroveň jeho kvality. To zahŕňa testy funkčnosti a testy spoľahlivosti systému.

Posledným testom automatizovaného informačného systému je akceptačné testovanie. Takýto test zahŕňa ukážku informačného systému zákazníkovi a mal by obsahovať skupinu testov, ktoré simulujú reálne obchodné procesy.

3.5 Uvedenie systému do prevádzky

Vo fáze uvádzania systému do prevádzky prebiehajú testy, skúšobná prevádzka systému v reálnych podmienkach, prebiehajú rokovania o výsledkoch projektu a prípadných nových zákazkách.

Hlavné typy práce:

§ komplexné testy;

§ školenie pre obsluhu vytvorený systém;

§ príprava pracovnej dokumentácie, dodávka systému zákazníkovi a jeho uvedenie do prevádzky;

§ podpora, podpora, servisná údržba;

§ Vyhodnotenie výsledkov projektu a príprava záverečných dokumentov.

4. ZLOŽENIE A ŠTRUKTÚRA ZADÁVACÍCH PODMIENOK A TECHNICKÉHO PROJEKTU

1. Všeobecné ustanovenia

1.1. Zadanie (TOR) je hlavný dokument, ktorý definuje požiadavky a postup tvorby (vývoja alebo modernizácie - ďalšej tvorby) informačného systému, v súlade s ktorým sa realizuje vývoj IS a jeho akceptácia pri uvedení do prevádzky.

1.2. TK je vyvinutý pre systém ako celok, navrhnutý tak, aby fungoval samostatne alebo ako súčasť iného systému.

1.3. Požiadavky na IP v rozsahu ustanovenom touto normou je možné zahrnúť do zadania pre návrh novovzniknutého objektu informatizácie. V tomto prípade TK nie je vyvinutá.

1.4. Požiadavky zahrnuté v TOR musia zodpovedať súčasnej úrovni rozvoja informačných technológií a nesmú byť nižšie ako podobné požiadavky na najlepšie moderné domáce a zahraničné analógy. Požiadavky uvedené v TOR by nemali obmedzovať vývojára systému pri hľadaní a implementácii najefektívnejších technických, realizovateľných a iných riešení.

1.5. TOR obsahuje len tie požiadavky, ktoré dopĺňajú požiadavky na systémy tohto typu a sú určené špecifikami konkrétneho objektu, pre ktorý sa systém vytvára.

1.6. Zmeny TOR sú formalizované dodatkom alebo protokolom podpísaným zákazníkom a vývojárom. Dodatok alebo špecifikovaný protokol je neoddeliteľnou súčasťou TOR na IP. Na titulnej strane TK by mal byť záznam „Platnosť od ...“.

2. Zloženie a obsah

2.1. TOR obsahuje nasledujúce časti, ktoré možno rozdeliť na podsekcie:

1) všeobecné informácie;

2) účel a ciele vytvorenia (vývoja) systému;

3) charakteristiky predmetov;

4) systémové požiadavky;

5) zloženie a obsah práce na vytvorení systému;

6) postup kontroly a akceptácie systému;

7) požiadavky na skladbu a obsah prác prípravy vývojového objektu na uvedenie systému do prevádzky;

8) požiadavky na dokumentáciu;

9) rozvojové zdroje.

Žiadosti môžu byť zahrnuté v ZP.

2.2. V závislosti od typu, účelu, špecifických vlastností projektu a prevádzkových podmienok systému je možné vypracovať časti TOR vo forme aplikácií, zaviesť ďalšie, vylúčiť alebo kombinovať podsekcie TOR.

TOR pre časti systému nezahŕňa časti, ktoré duplikujú obsah častí TOR ako celku.

2.3. V časti „Všeobecné informácie“ uveďte:

1) úplný názov systému a jeho symbol;

2) šifra témy alebo šifra (číslo) zmluvy;

3) názov spoločností 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 kedy boli tieto dokumenty schválené;

5) plánované termíny začatia a ukončenia prác na vytvorení systému;

6) informácie o zdrojoch a postupe financovania diela;

7) postup pri formalizácii a prezentovaní výsledkov práce na vytvorení systému (jeho častí), na výrobe a úprave jednotlivých prostriedkov (hardvér, softvér, informácie) a softvéru a hardvéru (softvér a metodický) zákazníkovi. komplexy systému.

2.4. Časť „Účel a ciele tvorby (vývoja) systému“ pozostáva z podkapitol:

1) účel systému;

2) účel vytvorenia systému.

2.4.1. V podsekcii „Účel systému“ uveďte druh činnosti systému (riadenie, projektovanie a pod.) a zoznam objektov informatizácie (objektov), ​​na ktorých má byť využívaný.

2.4.2. V podsekcii „Ciele vytvorenia systému“ sú uvedené názvy a požadované hodnoty technických, technologických, výrobno-ekonomických alebo iných ukazovateľov objektu informatizácie, ktoré je potrebné dosiahnuť vytvorením IS. a uveďte kritériá hodnotenia dosiahnutia cieľov vytvorenia systému.

2.5. V časti „Charakteristika objektu informatizácie“ uvádzajú:

1) stručné informácie o predmete informatizácie alebo odkazy na dokumenty obsahujúce takéto informácie;

2) informácie o prevádzkových podmienkach objektu automatizácie.

2.6. Časť Systémové požiadavky pozostáva z nasledujúcich podsekcií:

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 systémových požiadaviek uvedených v tejto časti TOR pre IS je stanovené v závislosti od typu, účelu, špecifických vlastností a prevádzkových podmienok konkrétneho systému.

2.6.1. V podsekcii „Požiadavky na systém ako celok“ uveďte:

požiadavky na štruktúru a fungovanie systému;

požiadavky na počet a kvalifikáciu personálu systému a spôsob jeho práce;

ukazovatele destinácie;

požiadavky na spoľahlivosť;

bezpečnostné požiadavky;

požiadavky na ergonómiu a technickú estetiku;

požiadavky na prevádzku, údržbu, opravy a skladovanie komponentov systému;

požiadavky na ochranu informácií pred neoprávneným prístupom;

požiadavky na bezpečnosť informácií v prípade nehôd;

požiadavky na ochranu pred vplyvom vonkajších vplyvov;

požiadavky na čistotu patentov;

požiadavky na štandardizáciu a unifikáciu;

Ďalšie požiadavky.

2.6.1.1. Požiadavky na štruktúru a fungovanie systému zahŕňajú:

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 na výmenu informácií medzi komponentmi systému;

3) požiadavky na vlastnosti prepojení vytváraného systému so súvisiacimi systémami, požiadavky na jeho kompatibilitu vrátane pokynov na výmenu informácií (automaticky, zasielaním dokumentov, telefonicky atď.);

4) požiadavky na prevádzkové režimy systému;

5) požiadavky na diagnostiku systému;

6) perspektívy rozvoja, modernizácie systému.

2.6.1.2. V požiadavkách na počet a kvalifikáciu personálu na IS sú uvedené:

§ požiadavky na počet pracovníkov (používateľov) IS;

§ požiadavky na kvalifikáciu personálu, postup pri jeho výcviku a kontrolu vedomostí a zručností;

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

2.6.1.3. V požiadavkách na ukazovatele účelu IS sú uvedené hodnoty parametrov charakterizujúcich mieru zhody systému s jeho účelom.

2.6.1.4. Požiadavky na spoľahlivosť zahŕňajú:

1) zloženie a kvantitatívne hodnoty ukazovateľov spoľahlivosti pre systém ako celok alebo jeho subsystémy;

2) zoznam núdzových situácií, pre ktoré by sa mali regulovať požiadavky na spoľahlivosť, a hodnoty zodpovedajúcich ukazovateľov;

3) požiadavky na spoľahlivosť hardvéru a softvéru;

4) požiadavky na metódy hodnotenia a monitorovania ukazovateľov spoľahlivosti v rôznych fázach vytvárania systému v súlade s platnými regulačnými a technickými dokumentmi.

2.6.1.5. Bezpečnostné požiadavky zahŕňajú požiadavky na zaistenie bezpečnosti pri dodávke, uvádzaní do prevádzky, prevádzke a údržbe systému.

2.6.1.6. Medzi požiadavky na ergonómiu a technickú estetiku patria indikátory IS, ktoré špecifikujú požadovanú kvalitu interakcie človek-stroj a komfort pracovných podmienok personálu.

2.6.1.7. Požiadavky na ochranu informácií pred neoprávneným prístupom zahŕňajú požiadavky stanovené odvetvím a informačným prostredím zákazníka.

2.6.1.8. V požiadavkách na bezpečnosť informácií je uvedený zoznam udalostí: havárie, poruchy technických prostriedkov (vrátane výpadku napájania) a pod., pri ktorých musí byť zabezpečená bezpečnosť informácií v systéme.

2.6.1.9. Požiadavky na patentovú čistotu uvádzajú zoznam krajín, voči ktorým musí byť patentová čistota systému a jeho častí zabezpečená.

2.6.1.10. Ďalšie požiadavky zahŕňajú špeciálne požiadavky podľa uváženia vývojára systému alebo zákazníka.

2.6.2. V podsekcii „Požiadavky na funkcie (úlohy)“ vykonávané systémom je uvedené:

§ pre každý subsystém zoznam funkcií, úloh alebo ich komplexov (vrátane tých, ktoré zabezpečujú interakciu častí systému), ktoré sa majú automatizovať;

§ pri vytváraní systému v dvoch alebo viacerých radoch - zoznam funkčných podsystémov, jednotlivých funkcií alebo úloh realizovaných v 1. a ďalších radoch;

§ časový harmonogram implementácie každej funkcie, úlohy (alebo súboru úloh);

§ požiadavky na kvalitu vykonávania každej funkcie (úlohy alebo súboru úloh), na formu prezentácie výstupných informácií, charakteristiku požadovanej presnosti a času vykonávania, požiadavky na simultánnosť vykonávania skupiny funkcie, spoľahlivosť výsledkov;

§ zoznam a kritériá zlyhania pre každú funkciu, pre ktorú sú špecifikované požiadavky na spoľahlivosť.

2.6.3. V podkapitole „Požiadavky na druhy podpory“ sú v závislosti od typu systému uvedené požiadavky na matematické, informačné, jazykové, softvérové, technické, metrologické, organizačné, metodické a iné druhy systémovej podpory.

2.6.3.2. Pre informačnú podporu systému sú stanovené nasledujúce požiadavky:

1) na zloženie, štruktúru a metódy organizovania údajov v systéme;

2) k výmene informácií medzi komponentmi systému;

3) na informačnú kompatibilitu so susednými systémami;

4) o používaní systémov správy databáz;

5) na štruktúru procesu zhromažďovania, spracovania, prenosu údajov v systéme a prezentácie údajov;

6) k ochrane údajov;

7) kontrola, uchovávanie, aktualizácia a obnova údajov;

2.6.3.3. Pre lingvistickú podporu systému sú uvedené požiadavky na používanie vysokoúrovňových programovacích jazykov v systéme, jazykov interakcie s používateľmi a technických prostriedkov systému, ako aj požiadavky na kódovanie a dekódovanie údajov, zadávanie údajov -výstupné jazyky, jazyky na manipuláciu s údajmi, prostriedky na opis predmetnej oblasti a metódy organizácie dialógu.

2.6.3.4. Pre systémový softvér je uvedený zoznam zakúpeného softvéru, ako aj požiadavky:

1) na závislosť softvéru od operačného prostredia;

2) na kvalitu softvéru, ako aj na spôsoby jeho poskytovania a kontroly;

2.6.3.5. Pre technickú podporu systému sú stanovené nasledujúce požiadavky:

1) na druhy technických prostriedkov vrátane typov komplexov technických prostriedkov, softvérových a hardvérových komplexov a iných komponentov, ktoré sú prijateľné na použitie v systéme;

2) na funkčné, konštrukčné a prevádzkové charakteristiky technickej podpory systému.

2.6.3.6. Požiadavky na metrologickú podporu zahŕňajú:

1) predbežný zoznam meracích kanálov;

2) požiadavky na presnosť meraní parametrov a (alebo) na metrologické charakteristiky meracích kanálov;

3) požiadavky na metrologickú kompatibilitu technických prostriedkov systému;

4) zoznam riadiacich a výpočtových kanálov systému, pre ktoré je potrebné vyhodnotiť charakteristiky presnosti;

5) požiadavky na metrologickú podporu hardvéru a softvéru, ktoré sú súčasťou meracích kanálov systému, nástrojov, vstavaného riadenia, metrologickej vhodnosti meracích kanálov a meracích prístrojov používaných pri nastavovaní a testovaní systému;

6) typ metrologickej certifikácie (štátna alebo rezortná) s uvedením postupu jej vykonávania a organizácií vykonávajúcich certifikáciu.

2.6.3.7. Pre organizačnú podporu sú stanovené tieto požiadavky:

1) na štruktúru a funkcie jednotiek zapojených do prevádzky systému alebo zabezpečenia prevádzky;

2) na organizáciu fungovania systému a postup interakcie medzi personálom IS a personálom objektu informatizácie;

3) na ochranu pred chybným konaním personálu systému.

2.7. Sekcia „Zloženie a obsah prác na tvorbe (vývoji) systému“ by mala obsahovať zoznam etáp a etáp prác na tvorbe systému, načasovanie ich implementácie, zoznam organizácií – vykonávateľov prác, zoznam etáp a etáp prác na tvorbe systému, časový harmonogram ich implementácie, zoznam organizácií – vykonávateľov prác. odkazy na dokumenty potvrdzujúce súhlas týchto organizácií podieľať sa na tvorbe systému, prípadne záznam identifikujúci osobu zodpovednú (zákazníka alebo vývojára) za vykonávanie týchto prác.

Táto sekcia tiež poskytuje:

1) zoznam dokumentov, ktoré sa majú predložiť na konci príslušných etáp a etáp práce;

2) druh a postup vykonávania kontroly technickej dokumentácie (etapa, štádium, rozsah kontrolovanej dokumentácie, organizácia-odborník);

3) pracovný program zameraný na zabezpečenie požadovanej úrovne spoľahlivosti vyvíjaného systému (ak je to potrebné);

4) zoznam prác na metrologickej podpore vo všetkých fázach vytvárania systému s uvedením ich termínov a vykonávajúcich organizácií (ak je to potrebné).

2.8. V časti „Postup monitorovania a akceptácie systému“ uveďte:

1) typy, zloženie, rozsah a skúšobné metódy systému a jeho komponentov;

2) všeobecné požiadavky na preberanie diela po etapách, postup odsúhlasovania a schvaľovania preberacej dokumentácie;

2.9. V časti „Požiadavky na rozsah a obsah prác prípravy objektu automatizácie na uvedenie systému do prevádzky“ je potrebné uviesť zoznam hlavných činností a ich vykonávateľov, ktoré je potrebné vykonať pri príprave projektu uvedenia systému do prevádzky. IS do prevádzky.

Zoznam hlavných činností zahŕňa:

1) uvedenie informácií vstupujúcich do systému (v súlade s požiadavkami na informačnú a jazykovú podporu);

2) vytvorenie podmienok pre fungovanie projektu, za ktorých je zaručený súlad vytvoreného systému s požiadavkami obsiahnutými v TOR;

3) vytvorenie pododdielov a služieb potrebných pre fungovanie systému;

4) podmienky a postup pre personálne obsadenie a školenie personálu.

2.10. V časti „Požiadavky na dokumentáciu“ je uvedené:

1) zoznam súborov a typov dokumentov, ktoré sa majú vypracovať, odsúhlasený vývojárom a zákazníkom systému;

2) zoznam dokumentov vydaných na strojových médiách;

3) pri absencii štátnych noriem, ktoré definujú požiadavky na dokumentáciu prvkov systému, obsahujú navyše požiadavky na zloženie a obsah takýchto dokumentov.

2.11. V časti „Zdroje vývoja“ by mali byť uvedené dokumenty a informačné materiály, na základe ktorých boli vypracované Zadania a ktoré by sa mali použiť pri tvorbe systému.

3. Pravidlá registrácie.

3.1. Sekcie a pododdiely TOR by mali byť umiestnené v poradí uvedenom v ods. 2 tejto normy.

3.2. Čísla hárkov (strany) sa uvádzajú počnúc prvým hárkom po titulnej strane v hornej časti hárku (nad textom, v strede) za označením kódu TK na IC.

3.3. Na titulnej strane sú umiestnené podpisy objednávateľa, developera a koordinačnej spoločnosti, ktoré sú zapečatené. V prípade potreby je titulná strana zostavená na viacerých stranách. Podpisy vývojárov TK a úradníkov, ktoré sa podieľajú na koordinácii a posudzovaní návrhu TOR na IP, sú umiestnené na poslednom hárku.

Podoba titulnej strany TOR je uvedená v prílohe 2. Formulár posledného listu TOR je uvedený v prílohe 3.

3.4. Titulná strana Dodatku k TOR je vyhotovená rovnakým spôsobom ako titulná strana zadávacích podmienok. Namiesto názvu „Terms of Reference“ píšu „Dodatok č. ... k TOR pre AC ...“.

3.5. Na ďalších listoch dodatku k TOR je uvedený dôvod zmeny, obsah zmeny a odkazy na dokumenty, v súlade s ktorými sa tieto zmeny vykonávajú.

3.6. Pri uvádzaní textu dodatku k ZA treba uviesť čísla príslušných odsekov, pododsekov, tabuliek hlavného VZ a pod. a slová „nahradiť“, „doplniť“, „vypustiť“, „uviesť v by sa malo použiť nové vydanie“.

Postup pri vypracovaní, schvaľovaní a schvaľovaní TK pre IP.

1. Návrh TOR vypracuje organizácia-vývojár systému za účasti zákazníka na základe technických požiadaviek (aplikácia, takticko-technické zadanie a pod.).

V konkurenčnej organizácii práce možnosti návrhu TOR zvažuje objednávateľ, ktorý si buď vyberie preferovanú možnosť, alebo na základe porovnávacej analýzy pripraví finálnu verziu TOR pre AC za účasti CK. budúci vývojár IS.

2. Potrebu schválenia návrhu ZP s orgánmi štátneho dozoru a inými zainteresovanými organizáciami určuje spoločne objednávateľ systému a spracovateľ návrhu ZP pre IP,

Práce na schválení návrhu TOR na IC vykonávajú spoločne vývojár TOR a objednávateľ systému, každý v organizáciách vlastného ministerstva (odboru).

3. Lehota na schválenie návrhu TOR v každej organizácii by nemala presiahnuť 15 dní od dátumu jeho prijatia. Odporúča sa zaslať kópie návrhu ZP (kópie) na schválenie súčasne všetkým organizáciám (divíziám).

4. Pripomienky k návrhu TOR by mali byť predložené s technickým odôvodnením. O pripomienkach musí rozhodnúť spracovateľ návrhu ZP a objednávateľ systému pred schválením ZP pre IS.

5. Ak pri odsúhlasení návrhu TOR vzniknú nezhody medzi developerom a objednávateľom (prípadne inými zainteresovanými organizáciami), potom je spísaný protokol o nezhodách (ľubovoľná forma) a predpísaným spôsobom je prijaté konkrétne rozhodnutie.

6. Schválenie návrhu TOR je možné vypracovať ako samostatný dokument (list). V tomto prípade pod nadpisom „Súhlasím“ vytvorte odkaz na tento dokument.

7. Schvaľovanie TOR vykonávajú vedúci spoločností vývojára a objednávateľa systému.

8. Kópie schválených ZP do 10 dní po schválení zasiela vývojár ZP účastníkom tvorby systému.

9. Koordinácia a schvaľovanie dodatkov k ZA sa vykonáva spôsobom stanoveným pre ZA v IP.

10. Zmeny TOR nie je možné schváliť po predložení systému alebo jeho frontu na akceptačné testy.

Základom pre vypracovanie technického návrhu systému sú zadávacie podmienky schválené zákazníkom.

Technickým návrhom systému je predpísaným spôsobom schválená technická dokumentácia obsahujúca celosystémové konštrukčné riešenia, algoritmus riešenia problémov, ako aj posúdenie ekonomickej efektívnosti automatizovaného riadiaceho systému a zoznam opatrení na vypracovanie objekt na realizáciu.

Technický projekt sa pripravuje s cieľom určiť hlavné konštrukčné rozhodnutia pre vytvorenie systému. V tejto fáze sa vykonáva komplex výskumných a experimentálnych prác na výber najlepších riešení, experimentálne overenie hlavných návrhových rozhodnutí a výpočet ekonomickej efektívnosti systému.

Vlastne technický projekt obsahuje komplex ekonomicko-matematických a algoritmických modelov.

Kompletná sada technického návrhu systému obsahuje 10 dokumentov:

1. Vysvetlivka.

2. Funkčná a organizačná štruktúra systému.

3. Stanovenie problémov a algoritmus riešenia.

4. Organizácia informačnej základne.

5. Album formulárov dokumentov.

6. Softvérový systém.

7. Princíp budovania komplexu technických prostriedkov.

8. Výpočet ekonomickej efektívnosti systému.

9. Opatrenia na prípravu zariadenia na implementáciu systému.

10. Zoznam dokumentov.

Z vyššie uvedeného zoznamu sa dokument 3 „Algoritmus nastavenia a riešenia problému“ vykonáva pre každú jednotlivú úlohu zahrnutú v EIS, ostatné dokumenty sú spoločné pre celý systém. Okrem toho môžu byť dokumenty 1, 2, 5, 8 a 9 vypracované pre jednotlivé podsystémy.

Všetky tieto dokumenty môžu byť zoskupené a prezentované vo forme štyroch hlavných častí technického projektu: ekonomická a organizačná, informačná, matematická, technická.

Ekonomická a organizačná časť technického projektu obsahuje vysvetľujúca poznámka s odôvodnením vývoja systému, zoznam vývojárskych organizácií, stručný popis objektu s uvedením hlavných technických a ekonomických ukazovateľov jeho fungovania a vzťahov s inými objektmi, stručné informácie o hlavných návrhových rozhodnutiach pre funkčné a podporné časti systému.

V časti technického projektu, venovanej organizačnej a funkčnej štruktúre systému, je uvedené: zdôvodnenie pridelených subsystémov, ich zoznam a účel; zoznam úloh, ktoré sa majú riešiť v každom subsystéme, so stručným popisom ich obsahu; schéma informačných väzieb medzi subsystémami a medzi úlohami v rámci každého subsystému.

Pre každú úlohu zahrnutú v množine prioritných úloh sa vykoná jej vyhlásenie a algoritmus riešenia. Táto časť technického návrhu obsahuje:

§ organizačná a ekonomická podstata úlohy (názov, účel riešenia, súhrn, spôsob, frekvencia a čas riešenia problému, spôsoby zberu a prenosu údajov, prepojenie úlohy s inými úlohami, charakter použitia výsledky riešenia, v ktorom sa používajú);

§ ekonomický a matematický model problému (štrukturálna a rozšírená forma prezentácie);

§ vstupné prevádzkové informácie (charakteristika ukazovateľov, ich význam a rozsah zmien, formy prezentácie);

§ referenčné informácie (NSI) - obsah a formy prezentácie;

§ Informácie uložené pre spojenie s inými úlohami;

§ zhromaždené informácie pre následné riešenia tohto problému;

§ informácie o vykonaní zmien (zmenový systém a zoznam informácií podliehajúcich zmenám);

§ algoritmus riešenia úlohy (sekvencia výpočtových krokov, schéma, výpočtové vzorce);

§ testovací prípad (súbor formulárov vstupných dokumentov naplnených údajmi, podmienené dokumenty s nahromadenými a uloženými informáciami, formuláre výstupných dokumentov vyplnené na základe výsledkov riešenia ekonomického a technického problému a v súlade s vyvinutým algoritmom výpočtu).

Dokument „Výpočet ekonomickej efektívnosti systému“ obsahuje súhrnný odhad nákladov spojených s prevádzkou systémov, poskytuje kalkuláciu ročnej ekonomickej efektívnosti, ktorej zdrojom je optimalizácia produkčnej štruktúry ekonomiky (kombinácie), znižovanie nákladov na výrobu vďaka racionálnemu využívaniu výrobných zdrojov a znižovanie strát, zlepšovanie prijatých rozhodnutí manažmentu.

Dokument „Opatrenia na prípravu objektu na implementáciu systému“ obsahuje zoznam organizačných opatrení na zlepšenie existujúcej riadiacej štruktúry, zoznam prác na implementácii systému, ktoré je potrebné vykonať v štádiu podrobného návrhu s uvedením načasovanie a zodpovedné osoby.

Informačná časť technického projektu kombinuje dokumenty 4 a 5. Dokument „Organizácia informačnej základne“ odráža: zdroje informácií a spôsoby ich prenosu na riešenie prioritného súboru funkčných úloh; súbor indikátorov používaných v systéme; zloženie dokumentov, načasovanie a frekvencia ich prijímania; hlavné rozhodnutia o návrhu organizácie fondu NŠÚ; zloženie NŠÚ vrátane zoznamu podrobností, ich vymedzenie, význam, rozsah zmien a zoznam dokumentov NŠÚ; zoznam polí NSI, ich objem, poradie a frekvenciu opravy informácií; návrhy na zjednotenie dokumentácie, skúšobný prípad na vykonávanie zmien v NŠÚ; štruktúrna forma NSI s popisom vzťahu medzi prvkami; požiadavky na technológiu vytvárania a udržiavania fondu; spôsoby uchovávania, vyhľadávania, úpravy a kontroly, určovanie objemov a tokov informácií NŠÚ.

"Album formulárov dokumentov" obsahuje formuláre NSI.

Matematická časť technického projektu obsahuje zdôvodnenie štruktúry softvéru, zdôvodnenie výberu programovacieho systému vrátane zoznamu štandardných programov.

Technická časť technického projektu obsahuje: popis a zdôvodnenie schémy technického postupu spracovania údajov; zdôvodnenie požiadaviek na vývoj neštandardných zariadení; zdôvodnenie a voľba štruktúry komplexu technických prostriedkov a jeho funkčných skupín; súbor opatrení na zabezpečenie spoľahlivosti fungovania technických prostriedkov.

ZÁVER

Vývoj informačného systému sa spravidla vykonáva pre presne definovaný podnik. Vlastnosti predmetu činnosti podniku majú samozrejme vplyv na štruktúru informačného systému, ale zároveň sú štruktúry rôznych podnikov vo všeobecnosti navzájom podobné. Každá organizácia, bez ohľadu na typ svojej činnosti, pozostáva z niekoľkých divízií, ktoré priamo vykonávajú jeden alebo iný typ činnosti spoločnosti, a táto situácia platí takmer pre všetky organizácie, bez ohľadu na to, akým typom činnosti sa zaoberajú. v.

Zavádzanie moderných informačných technológií umožňuje skrátiť čas potrebný na prípravu konkrétnych marketingových a výrobných projektov, znížiť neproduktívne náklady pri ich realizácii, eliminovať možnosť vzniku chýb pri príprave účtovných, technologických a iných druhov dokumentácie, ktoré dáva obchodnej spoločnosti priamy ekonomický efekt.

Samozrejme, na odhalenie všetkých potenciálnych príležitostí, ktoré používanie počítačov so sebou nesie, je potrebné použiť sadu softvérových a hardvérových nástrojov, ktoré najlepšie zodpovedajú nastaveným úlohám. Preto je v súčasnosti veľká potreba obchodné spoločnosti v počítačových programoch, ktoré podporujú prácu manažmentu firmy, ako aj informácie o tom, ako optimálne využívať výpočtovú techniku ​​firmy.

Implementácia dizajnu AIS zahŕňa použitie dizajnérmi určitej konštrukčnej technológie, ktorá zodpovedá rozsahu a vlastnostiam vyvíjaného projektu.

ZOZNAM POUŽITEJ LITERATÚRY

1. Sprievodca štúdiom odboru "Automatizované informačné systémy" [Elektronický zdroj]. - Moskva, 2006. - Režim prístupu:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Hlava. z obrazovky.

2. Wikipedia, bezplatná encyklopédia [Elektronický zdroj] / Článok "Informačný systém" - Režim prístupu: http://ru.wikipedia.org/wiki/Information system.

3. Počítačová tlač: Online magazín. -- Elektrón. Dan. -- [B.m., 2001]. -- Režim prístupu: http://compress.ru/article.aspx?id=12282.

4. Vendrov A.M., “Projektovanie softvéru pre ekonomické informačné systémy” / A.M. Vendrov. - M.: "Financie a štatistika", 2000. - 364 s.

5. "Referenčné podmienky pre vytvorenie automatizovaného systému" / - M .: GOST 34.602-89, 1990.

6. Grekul V.I. "Návrh informačných systémov" / V.I. Grekul, G.N. Denishchenko, N.L. Korovkin. - M.: Internetová univerzita informačných technológií, 2008.

Hostené na Allbest.ru

Podobné dokumenty

Vývoj informačných systémov. Moderný trh finančný a ekonomický aplikačný softvér. Výhody a nevýhody zavádzania automatizovaných informačných systémov. Metódy navrhovania automatizovaných informačných systémov.

práca, pridané 22.11.2015


Typy poskytovania automatizovaných informačných systémov. Príprava zadávacích podmienok, vývoj informačného systému, príprava užívateľskej príručky k programu. Programovacie nástroje pre distribuované systémy spracovania informácií.

správa z praxe, pridaná 16.04.2017


Životný cyklus automatizovaných informačných systémov. Základy metodiky navrhovania automatizovaných systémov na báze CASE technológií. Fáza analýzy a plánovania, konštrukcie a implementácie automatizovaného systému. Kaskádový a špirálový model.

ročníková práca, pridaná 20.11.2010


Pojem informačný systém, typy informačných systémov. Analýza nástrojov pre vývoj automatizovaných informačných systémov. Požiadavky na program a softvérový produkt. Vývoj GUI formulárov a databáz.

práca, pridané 23.06.2015


Zásady organizácie systému pozostávajúceho z personálu a súboru prostriedkov na automatizáciu jeho činností. Navrhovanie podnikových automatizovaných informačných systémov. Štruktúra, vstupné a výstupné toky, obmedzenia automatizovaných systémov.

prezentácia, pridané 14.10.2013


Koncept informačného systému. Etapy vývoja informačných systémov. Procesy v informačnom systéme. Informačný systém na hľadanie trhových medzier, na znižovanie výrobných nákladov. Štruktúra informačného systému. Technická podpora.

abstrakt, pridaný 17.11.2011


Organizácia, architektúra a štruktúra informačného systému. Ukazovatele efektívnosti jeho práce. Ciele a ciele analýzy automatizovaných riadiacich systémov. Komponenty automatizovaných systémov. Opis predmetnej oblasti, vstupné a výstupné údaje. Vytvorenie diagramu precedensov.

semestrálna práca, pridaná 4.11.2014


Tvorba a organizácia automatizovaných informačných systémov (AIS). Hlavné komponenty a technologické procesy AIS. Etapy a etapy tvorby AIS z pozície vedenia organizácie. Vývoj komplexov konštrukčných riešení pre automatizovaný systém.

abstrakt, pridaný 18.10.2012


Hlavné faktory ovplyvňujúce históriu vývoja podnikových automatizovaných informačných systémov. Ich všeobecná charakteristika a klasifikácia. Zloženie a štruktúra integrovaného AIS. ERP systémy ako moderný vzhľad podnikový informačný systém.

prezentácia, pridané 14.10.2013


Analýza predmetu, etapy projektovania automatizovaných informačných systémov. Nástrojové systémy pre vývoj softvéru. Úloha CASE nástrojov pri návrhu informačného modelu. Logický model navrhovanej databázy.

Dizajn AIS

Detailný vývoj návrh systému obsahujúci kompletný súbor jeho organizačnej, projektovej, technologickej a prevádzkovej dokumentácie. V súlade s GOST 34.601-90. projektovanie automatizovaných systémov zahŕňa realizáciu niekoľkých etáp, vrátane: tvorby požiadaviek na JE, vypracovania koncepcie JE, vypracovania technických špecifikácií, predbežného návrhu, technické prevedenie a vypracovanie pracovnej dokumentácie. Etapy tvorby AÚ okrem projektovania zahŕňajú aj: uvedenie do prevádzky a údržbu AÚ. Každá etapa je rozdelená na etapy. Prílohy k tejto norme tiež definujú:

· Zoznam typov organizácií zapojených do práce.

V závislosti od charakteru projektovaného objektu a jeho špecifických podmienok umožňuje GOST 34.601-90 vylúčenie jednotlivých etáp, ako aj ich kombináciu. Berúc do úvahy dlhodobú prax, ktorá sa vyvinula v Rusku pri vytváraní automatizovaných informačných systémov (" AIS“), sa spravidla vykonávajú tieto etapy projektovania: predprojektový prieskum, ideový návrh, predbežný projekt, technický návrh a detailný projekt. Ďalšie štátne normy upravujúce rôzne aspekty projektovania JE:

· GOST 34.602-89 Súbor noriem pre automatizované systémy. Referenčné podmienky pre vytvorenie automatizovaného systému. Vložené.01.01.90.

Štandard 34.603-92 Informačné technológie. Typy AS testov.

· Štandardy 34. (971, 972.973, 974, 981) - 91 Informačné technológie. Vzťah otvorených systémov.

Štandardná 34,91. Informačné technológie. Lokálne siete atď.

Predprojektový prieskum- Zber a spracovanie informácií o organizácii a fungovaní objektu automatizácie, vrátane údajov o jeho interakcii s vonkajším prostredím a inými objektmi, ako aj o implementácii systémová analýza, vypracovanie štúdie uskutočniteľnosti automatizácie a vypracovanie všeobecných požiadaviek na vývoj automatizovaného systému. Obsah práce počas predprojektového prieskumu objektu automatizácie zodpovedá etape „Formovanie požiadaviek na AÚ“ GOST 34.601-90, etapy: „Kontrola objektu a zdôvodnenie potreby vytvorenia AÚ“, „ Tvorba užívateľských požiadaviek na AÚ“, „Vytvorenie správy o vykonanej práci a aplikácie pre vývoj AC - takticko-technické zadanie.

Koncepčný návrh- Zodpovedá fázam návrhu v súlade s GOST 34.601-90 - „Vývoj koncepcie AU“ (etapy: „Vývoj variantov koncepcie AU a výber možnosti koncepcie AU, ktorá uspokojí používateľa“, „Vypracovanie správy o vykonanej práci“) a „Vypracovanie zadávacích podmienok“. Typy konečných dokumentov práce v tejto fáze sú predbežný projekt(tiež používané mená - “ Koncepčný projekt ”, “Pilotný projekt") alebo Program vytvorenie systému, ktorý zahŕňa:

· Stručný popis počiatočný stav objektu automatizácie a prostredia, v ktorom funguje;

Označenie hlavných cieľov a zoznam úloh automatizácie;

· Popis rozšírenej organizačnej a funkčnej štruktúry vybranej možnosti (alebo možností) budovania vytváraného systému;

· Štúdie uskutočniteľnosti;

· Rozšírený popis a základné požiadavky na prostriedky informačnej a jazykovej podpory;

· Všeobecné požiadavky na softvér a hardvér;

· zoznam a rozšírený popis fáz vytvárania systému, načasovanie ich implementácie, zloženie účinkujúcich a očakávané výsledky ich implementácie;

· Vstupné hodnotenie nákladových ukazovateľov pracovného výkonu;

· Zadanie pre systém ako celok a/alebo jeho hlavné komponenty (subsystémy, softvérové ​​a hardvérové ​​systémy a nástroje, jednotlivé úlohy atď.), schválené zákazníkom.

Predbežný návrh- Vývoj predbežných konštrukčných riešení systému a jeho častí. Konečným dokumentom práce v tejto fáze návrhu je Predbežný návrh , ktorá obsahuje zásadné konštrukčné a obvodové riešenia vývojového objektu, ako aj údaje určujúce jeho účel a hlavné parametre (pri návrhu softvér systému, návrh návrhu musí obsahovať komplet špecifikácia vyvinuté programy).

Inžiniersky dizajn - Etapa projektovania JE, ktorá zahŕňa:

· Vývoj konštrukčných riešení systému a jeho častí;

· vypracovanie dokumentácie pre AÚ a jej časti;

· Vypracovanie a vyhotovenie dokumentácie pre dodávku produktov na obstaranie jadrových elektrární a/alebo technických požiadaviek (technických špecifikácií) na ich vývoj;

· Vypracovanie úloh pre projektovanie v priľahlých častiach projektu objektu automatizácie.

Posledným dokumentom tejto fázy návrhu je technický projekt obsahujúci okrem uvedených materiálov, schém elektrického zapojenia a projektovej dokumentácie vývojového objektu a jeho komponentov aj zoznam vybraného hotového náradia softvér a hardvér(vrátane počítačov, operačný systém, aplikačné programy atď.), ako aj algoritmy riešenie problémov pre vývoj nových softvérových nástrojov a pod.

Pracovný dizajn- Záverečná fáza dizajn, ktorý okrem vývoja pracovnej dokumentácie pre systém a jeho časti vyžadované GOST 34.601-90 vo všeobecnosti zabezpečuje objasnenie a spresnenie výsledkov predchádzajúcich etáp, vytvorenie a testovanie experimentálnej a/alebo pilotnej priemyselnej vzorky automatizačného objektu, vývoj a testovanie softvérových produktov, technologickej a prevádzkovej dokumentácie. Výsledky sú prezentované v pracovné alebo technický pracovný projekt. V modernej dizajnérskej praxi automatizované informačné systémy(Napríklad, ABIS, ASNTI, ACS a pod.) je to počiatočná fáza ich implementácie v práci firmy, organizácie alebo služby, ktorá je objednávateľom projektu, prípadne vedúcim v rade iných automatizovaných firiem, organizácií, služieb a pod.

Vývojový cyklus (dizajn) softvér - Súbor vývojových etáp softvér začať z systémová analýza a vývoj počiatočných požiadaviek pred jeho implementáciou.

Princípy návrhu AIS- Súbor pravidiel alebo požiadaviek stanovených dlhoročnými a všestrannými skúsenosťami s tvorbou a prevádzkou AIS. Najbežnejšie sú:

· identita- vývoj nového, zdokonaľovanie existujúceho alebo zavedenie externe získaného AIS sú vedecko-technické problémy obsahovo podobné, líšia sa od seba len obsahom viacerých etáp a časovými parametrami;

· Vyrobiteľnosť: automatizovaná technológia znamená vývoj Nová technológia alebo modernizácia existujúceho AIS a neumožňuje jednoduché použitie vyvinutého softvéru a hardvéru v starých tradičných technológiách;

· Kontinuita, fázovanie a postupnosť vývoja a vývoja: AIS - systémy neustále sa vyvíjajúce na ich základe; každá inovácia slúži ako rozvoj základných systémových princípov a už dosiahnutej kvality;

· prispôsobivosť: Komponenty AIS by mali mať vlastnosti, ktoré zabezpečia rýchle prispôsobenie týchto komponentov zmenám vonkajšie prostredie a nové prostriedky;

· Modulárny princíp budovania softvéru a hardvéru: predpokladá, že zloženie týchto nástrojov pozostáva z blokov („modulov“), ktoré poskytujú možnosť ich nahradenia alebo zmeny s cieľom zlepšiť fungovanie AIS alebo jeho prispôsobenie novým podmienkam;

· Technologické (vrátane - siete) integrácia: znamená jednotu pre celý systém technológie tvorby, aktualizácie, uchovávania a využívania informačných zdrojov a najmä jednorazové spracovanie dokumentov a údajov, ako aj ich viacúčelové a viacúčelové využitie;

· Úplná normalizácia procesov a ich monitorovanie: viacúčelové využitie informácií AIS si vyžaduje vysokú spoľahlivosť údajov v systéme. K tomu v rôznych fázach spracovania a vstupu informačné dokumenty je potrebné využívať rôzne formy informačnej kontroly, na ktoré sa môžu formovať požiadavky zo skladby riešených úloh a spracovávaných údajov. neustále monitorovanie je potrebné aj na získanie kvalitatívnych a kvantitatívnych charakteristík fungovania AIS na základe vstavaných a špeciálne vyvinutých nástrojov intelektuálnej štatistiky;

· nariadenia: AIS sú zamerané na fungovanie v priemyselnom režime, poskytujúce hromadné streamingové spracovanie informačných dokumentov; toto spracovanie je regulované normami, traťovými a prevádzkovými technológiami, normami pre zdrojové a časové ukazovatele a rozvinutou dispečerskou službou.

· Ekonomická výhodnosť: vytvorenie AIS by malo zabezpečiť výber takých konštrukčných riešení (vrátane softvérových, technických, organizačných a technologických), ktoré za predpokladu dosiahnutia cieľov a zámerov zabezpečia minimalizáciu nákladov na finančné, materiálne a pracovné zdroje.

· Typizácia konštrukčných riešení: rozvoj a rozvoj AIS a ich sietí sa uskutočňuje so zameraním na medziknižničnú spoluprácu a kooperáciu, ako aj v súlade s pravidlami a protokolmi medzinárodnej výmeny informácií;

· Maximálne využitie hotových riešení: na zníženie nákladov a času na vývoj a implementáciu AIS, ako aj na zníženie konštrukčných chýb ako systému ako celku, tak aj jeho jednotlivých komponentov, sa odporúča v maximálnej možnej miere využívať hotové riešenia a nástroje. V tomto pláne je pri vytváraní nového systému značné množstvo práce spojené s analýzou alternatívnych možností možných riešení, výberom toho najvhodnejšieho pre objekt automatizácie a jeho prispôsobením novým podmienkam používania;

· korporativizmus: pri navrhovaní automatizovaného systému, ktorý je súčasťou systému vyššej úrovne (mestá, rezorty, republiky atď.), by sa mala zabezpečiť jeho hardvérová, softvérová, jazyková a informačná kompatibilita s ostatnými účastníkmi systému a/alebo siete AIS. Firemné požiadavky môžu byť v rozpore s požiadavkami alebo rozhodnutiami diktovanými inými princípmi, napríklad kontinuitou dizajnových riešení;

· Orientácia na prvé osoby objektu automatizácie: úspešná realizácia prác na vytvorení AIS, ich rozvoj a prevádzka je možná len vtedy, ak sú bezvýhradne podporované prvou osobou objektu automatizácie (napríklad riaditeľ knižnice alebo informačného orgánu) a priama zodpovednosť za ich implementáciu je príkazom organizácie pridelený vedúcemu na úrovni najmenej zástupcu riaditeľa