Etapy standardního provedení ais. Návrh automatizovaného skladového účetního systému pomocí nástroje Rational Rose CASE. Metody provádění projektových prací
Etapy vývoje systémů CASE
Během poslední dekády se objevil nový směr v navrhování informačních systémů – počítačově podporované navrhování pomocí nástrojů CASE. Termín CASE (Computer Aided System/Software Engineering) původně označoval pouze automatizaci vývoje softwaru; nyní pokrývá celý proces vývoje komplexního AIS.
Zpočátku byly technologie CASE vyvíjeny s cílem překonat nedostatky metodiky navrhování konstrukcí (obtížné porozumění, vysoká pracnost a náklady na použití, potíže při provádění změn konstrukčních specifikací atd.) prostřednictvím automatizace a integrace podpůrných nástrojů.
Technologie CASE neexistují samy o sobě a nejsou nezávislé. Automatizují a optimalizují použití příslušné metodiky a umožňují zvýšit efektivitu její aplikace.
Jinými slovy, CASE technologie představují soubor metodik pro analýzu, návrh, vývoj a údržbu komplexních softwarových systémů, podporovaný sadou vzájemně propojených automatizačních nástrojů, které umožňují vizuálně modelovat předmětnou oblast, analyzovat tento model ve všech fázích vývoje a údržby AIS a vyvíjet aplikace v souladu s informačními potřebami uživatelů.
Moderní nástroje CASE pokrývají širokou škálu podpory pro řadu návrhových technologií AIS – od jednoduchých analytických a dokumentačních nástrojů až po plnohodnotné automatizační nástroje pokrývající celý životní cyklus AIS. Největší potřeba využití CASE systémů je pociťována v počátečních fázích vývoje - ve fázích analýzy a specifikace požadavků na AIS. Chyby, které se zde dopustily, jsou téměř fatální, jejich cena je výrazně vyšší než cena chyb v pozdějších fázích vývoje.
Hlavním cílem nástrojů CASE je oddělit počáteční fáze (analýzu a návrh) od těch následných a nezatěžovat vývojáře detaily vývojového prostředí a provozu systému.
Většina moderních systémů CASE používá metodiky strukturální a/nebo objektově orientovaná analýza A design, založené na použití vizuálních tabulek, grafů, tabulek a diagramů.
Správným využitím nástrojů CASE je dosahováno výrazného zvýšení produktivity práce, dosahující (dle odhadů zahraničních firem, které využívají technologie CASE) od 100 do 600 %, v závislosti na objemu, náročnosti práce a zkušenostech s CASE. Zároveň se mění všechny fáze životního cyklu AIS, ale největší změny se týkají fáze analýzy a návrhu (tab. 2.5, 2.6).
Tabulka 2.5. Odhady mzdových nákladů podle fází životního cyklu AIS
Tabulka 2.6. Srovnání použití CASE a tradičního rozvoj
Použití nástrojů CASE nejen automatizuje strukturální metodiku a umožňuje využívat moderní metody systémového a softwarového inženýrství, ale přináší i další výhody (obr. 2.22), zejména:
1. zlepšuje kvalitu vyvíjeného softwaru prostřednictvím automatického generování a řízení;
2. umožňuje zkrátit čas na vytvoření prototypu AIS, což umožňuje posoudit kvalitu a efektivitu projektu v raných fázích;
3. urychluje proces návrhu a vývoje;
4. umožňuje znovu použít vyvinuté komponenty;
5. podporuje podporu AIS;
6. vás osvobodí od rutinní práce na dokumentaci projektu, protože používá vestavěný dokumentátor;
7. usnadňuje týmovou práci na projektu.
Rýže. 2.22. Výhody vývoje AIS pomocí CASE technologií: A- koeficient snížení nákladů projektu; b - faktor snížení doby vývoje
Většina nástrojů CASE je založena na čtyřech hlavních konceptech: metodologie, metoda, zápis, nástroj [ 11,15, 16].
Metodologie definuje směrnice pro hodnocení a výběr řešení při návrhu a vývoji AIS, etapy prací, jejich posloupnost, pravidla pro rozdělení a účel metod.
Metody - postupy pro generování komponent a jejich popisy.
Notace jsou určeny k popisu obecné struktury systému, datových prvků, fází zpracování, mohou zahrnovat grafy, diagramy, tabulky, vývojové diagramy, formální a přirozené jazyky.
Vybavení- nástroje na podporu a posílení metod; podporuje práci uživatelů při vytváření a úpravách projektu v interaktivním režimu, pomáhá organizovat projekt ve formě hierarchie úrovní abstrakce a kontroluje shodu komponent.
Klasifikace CASE nástrojů
Dosud neexistuje stabilní klasifikace nástrojů CASE; byly definovány pouze přístupy ke klasifikaci v závislosti na různých klasifikačních kritériích. Níže jsou uvedeny některé z nich.
Zaměření na technologické etapy a procesy životního cyklu AIS:
1. nástroje pro analýzu a návrh. Používá se k vytvoření systémových specifikací a návrhu. Podporují známé metodologie návrhu;
2. nástroje pro návrh databází. Poskytovat logické modelování dat, generování databázových struktur;
3. nástroje pro řízení požadavků;
4. nástroje pro správu konfigurace softwaru. Podpora programování, testování, automatické generování softwaru ze specifikací;
5. dokumentační nástroje;
6. testovací nástroje;
7. Nástroje projektového řízení. Podpora plánování, kontroly, interakce;
8. nástroje reverzního inženýrství určené k převodu stávajícího systému do nového prostředí.
Podporované metodologie návrhu[ 11, 12, 15, 16]:
1. funkčně (strukturně orientovaný);
2. objektově orientovaný;
3. komplexně orientované (soubor návrhových metodik).
Podporované grafické zápisy do grafů:
1. s pevným zápisem;
2. se samostatnými zápisy;
3. s nejběžnějšími zápisy.
Stupeň integrace:
1. pomocné programy (Nástroje), které samostatně řeší autonomní problém;
2. vývojové balíčky (Toolkit), což je sada nástrojů, které poskytují pomoc pro jednu z tříd softwarových úloh;
3. sady integrovaných nástrojů propojených společnou návrhovou databází - úložiště, automatizující celou nebo část práce v různých fázích tvorby AIS (Workbench).
Vývoj kolektivního projektu:
1. bez podpory kolektivního rozvoje;
2. zaměřené na vývoj projektu v reálném čase;
3. zaměřené na způsob spojování dílčích projektů.
Typy nástrojů CASE:
1. analytické nástroje (velká písmena); mezi specialisty se jim říká počítačové plánovací nástroje. Pomocí těchto nástrojů CASE je sestaven model, který odráží všechna existující specifika. Je zaměřena na pochopení obecných a specifických mechanismů fungování, dostupných schopností, zdrojů a cílů projektu v souladu s účelem společnosti. Tyto nástroje vám umožňují analyzovat různé scénáře a shromažďovat informace pro přijímání optimálních rozhodnutí;
2. nástroje pro analýzu a návrh (střední případ); jsou považovány za nástroje pro podporu analýzy požadavků a fází návrhu specifikací a struktury AIS. Hlavním výsledkem použití průměrného CASE nástroje je výrazné zjednodušení návrhu systému, protože návrh se mění v iterativní proces práce s požadavky na AIS. Navíc průměrné CASE nástroje poskytují rychlou dokumentaci požadavků;
3. nástroje pro vývoj softwaru (nižší); podpora systémů vývoje softwaru AIS. Obsahují systémové slovníky a grafické nástroje, které eliminují nutnost vyvíjet fyzické specifikace – existují systémové specifikace, které jsou přímo převedeny do programových kódů vyvíjeného systému (až 80 % kódů je generováno automaticky). Hlavními výhodami nižších CASE nástrojů je výrazné zkrácení doby vývoje, snadnější úpravy a podpora práce s prototypy.
Nástroje CASE jsou také klasifikovány podle typu a architektury výpočetní techniky, a podle typu operačního systému.
V současné době je softwarový trh zastoupen širokou škálou softwaru, včetně nástrojů CASE téměř kterékoli z uvedených tříd.
Charakteristika nástrojů CASE
Silverrun. CASE nástroj Silverrun od americké společnosti Computer Systems Advisers, Inc. (CSA) se používá pro analýzu a návrh business class AIS a je zaměřen spíše na spirálový model životního cyklu. Je použitelný pro podporu jakékoli metodiky založené na samostatné konstrukci funkčních a informačních modelů (diagramy datových toků a diagramy vztahů mezi entitami).
Přizpůsobení pro konkrétní metodiku je zajištěno výběrem požadovaného grafického zápisu modelů a sady pravidel pro kontrolu specifikací návrhu. Systém má připravená nastavení pro nejběžnější metodiky: DATARUN (hlavní metodika podporovaná Silverrunem), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Informační inženýrství. Pro každý koncept představený v projektu je možné přidat vlastní deskriptory. Architektura Silverrun vám umožňuje rozšiřovat vývojové prostředí podle potřeby.
Silverrun má modulární struktura a skládá se ze čtyř modulů, z nichž každý je samostatným produktem a lze jej zakoupit a používat samostatně.
1. Modul pro vytváření modelů podnikových procesů ve formě diagramů datových toků vám Business Process Modeler (BPM) umožňuje modelovat fungování automatizované organizace nebo vytvořeného automatizovaného informačního systému. Schopnost pracovat s vysoce komplexními modely poskytují funkce automatického přečíslování, práce s procesním stromem (včetně vizuálního přetahování větví), oddělování a připojování částí modelu pro kolektivní vývoj. Diagramy lze zobrazit v několika předdefinovaných notacích, včetně Yourdon/DeMarco a Gane/Sarson. Je také možné vytvářet vlastní zápisy, například přidat uživatelsky definovaná pole k počtu deskriptorů zobrazených v diagramu.
2. Modul koncepčního modelování dat Entity-Relationship eXpert (ERX) umožňuje konstrukci datových modelů entitních vztahů, které nejsou vázány na konkrétní implementaci. Vestavěný expertní systém umožňuje vytvořit správný normalizovaný datový model zodpovězením smysluplných otázek o vztahu dat. Je zajištěna automatická konstrukce datového modelu z popisů datových struktur. Analýza funkčních závislostí atributů umožňuje zkontrolovat shodu modelu s požadavky třetí normální formy a zajistit jejich splnění. Ověřený model je předán modulu Relational Data Modeler.
3. Modul relačního modelování Relational Data Modeler (RDM) umožňuje vytvářet podrobné modely vztahů mezi entitami pro implementaci v relační databázi. Tento modul dokumentuje všechny konstrukce spojené s budováním databáze: indexy, spouštěče, uložené procedury atd. Flexibilní, měnitelný zápis a rozšiřitelnost úložiště vám umožní pracovat s jakoukoli metodikou. Schopnost vytvářet podschéma odpovídá přístupu ANSI SPARC k reprezentaci databázového schématu. Jak uzly distribuovaného zpracování, tak uživatelské pohledy jsou modelovány v jazyce dílčích obvodů. Tento modul poskytuje návrh a kompletní dokumentaci relačních databází.
4. Správce úložiště pracovních skupin Workgroup Repository Manager (WRM) se používá jako datový slovník k ukládání informací společných všem modelům a také poskytuje integraci modulů Silverrun do jediného návrhového prostředí.
Výhodou nástroje Silverrun CASE je vysoká flexibilita a rozmanitost vizuálních prostředků pro konstrukci modelů a nevýhodou absence přísné vzájemné kontroly mezi komponentami různých modelů (například možnost automatického šíření změn mezi DFD různých modelů). úrovně rozkladu). Je však třeba poznamenat, že tato nevýhoda může být významná pouze v případě, že je použit model životního cyklu vodopádu.
Silverrun obsahuje:
1. automatické generování databázových schémat pro nejběžnější DBMS: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase;
2. přenos dat do nástrojů pro vývoj aplikací: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.
Je tedy možné kompletně definovat jádro databáze pomocí všech funkcí konkrétního DBMS: spouštěče, uložené procedury, omezení referenční integrity. Při vytváření aplikace se data migrovaná z úložiště Silverrun použijí buď k automatickému generování objektů rozhraní, nebo k jejich rychlému ručnímu vytvoření.
Pro výměnu dat s jinými nástroji pro automatizaci návrhu, vytváření specializovaných postupů pro analýzu a kontrolu specifikací návrhu a sestavování specializovaných zpráv v souladu s různými standardy poskytuje systém Silverrun tři způsoby výstupu návrhových informací do externích souborů.
1. Systém hlášení. Výstupem sestavy jsou textové soubory.
2. Systém exportu/importu. Je určen nejen obsah exportovaného souboru, ale také oddělovače záznamů, oddělovače polí v záznamech a značky začátku a konce textových polí. Takové exportní soubory lze vygenerovat a nahrát do úložiště. To umožňuje výměnu dat s různými systémy: jinými CASE nástroji, DBMS, textovými editory a tabulkovými procesory.
3. Uložení úložiště do externích souborů s přístupem pomocí ovladačů ODBC. Pro přístup k datům úložiště z nejběžnějších DBMS je možné ukládat veškeré informace o projektu přímo ve formátu těchto DBMS.
Silverrun podporuje dvě metody skupinové práce:
1) ve standardní jednouživatelské verzi je mechanismus pro řízené dělení a spojování modelů. Model lze rozdělit na části a distribuovat mezi několik vývojářů. Po detailním vývoji jsou díly znovu sestaveny do jediného modelu;
2) síťová verze Silverrunu umožňuje paralelní skupinovou práci s modely uloženými v síťovém úložišti založeném na Oracle, Sybase nebo Informix DBMS. Současně se stejným modelem může pracovat několik vývojářů, protože k zamykání objektů dochází na úrovni jednotlivých prvků modelu.
DŽEM. Nástroj pro vývoj aplikací JYACC's Application Manager (JAM) je produktem společnosti JYACC Hlavním rysem je soulad s metodikou RAD, protože JAM umožňuje rychle implementovat cyklus vývoje aplikace, který se skládá z generování další verze prototypu aplikace. s přihlédnutím k požadavkům uvedeným v předchozím kroku a předložit jej uživateli.
JAM má modulární strukturu a skládá se z následujících komponent:
1. systémová jádra;
2. JAM/DBi - specializované moduly rozhraní k DBMS (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC atd.);
3. JAM/RW - modul generátoru zpráv;
4. JAM/CASEi - specializované moduly rozhraní k nástrojům CASE (JAM/CASE-TeamWork, JAM/CASE-Innovator atd.);
5. JAM/TPi - specializované moduly rozhraní pro správce transakcí (například JAM/TPi-Server TUXEDO atd.);
6. Jterm - specializovaný emulátor X-terminálu.
Jádro systému je kompletní produkt a lze jej nezávisle použít pro vývoj aplikací. Všechny ostatní moduly jsou doplňkové a nelze je používat samostatně.
Jádro systému zahrnuje následující hlavní komponenty:
1. editor obrazovky. Editor obrazovky obsahuje vývojové prostředí obrazovky, úložiště vizuálních objektů, vlastní JAM DBMS - JDB, správce transakcí, debugger, editor stylů;
2. editor menu;
3. soubor pomocných nástrojů;
4. způsob výroby průmyslové verze aplikace.
Při použití JAM je vývoj externího rozhraní aplikace vizuálním návrhem a spočívá v vytváření obrazovkových formulářů umístěním struktur rozhraní na ně a definováním polí obrazovky pro vstup/výstup informací. Návrh rozhraní v JAM se provádí pomocí editor obrazovky. Aplikace vyvinuté v JAM mají rozhraní s více okny. Vývoj obrazovky zahrnuje umístění prvků rozhraní na ni, jejich seskupení a nastavení hodnot jejich vlastností.
Editor menu umožňuje vyvíjet a ladit systémy nabídek. Byla implementována schopnost vytvářet piktografická menu. Přiřazování položek nabídky k objektům aplikace se provádí v editoru obrazovky.
Jednouživatelský relační DBMS JDB je zabudován do jádra JAM. Hlavním účelem JDB je prototypování aplikací v případech, kdy je práce se standardním DBMS nemožná nebo nepraktická. JDB implementuje nezbytné minimální schopnosti relačních DBMS, které nezahrnují indexy, uložené procedury, spouštěče a pohledy. Pomocí JDB můžete vytvořit databázi identickou s cílovou databází (s výjimkou funkcí, které v JDB chybí) a vyvinout významnou část aplikace.
Debugger umožňuje komplexní ladění vyvíjené aplikace. Všechny události, ke kterým dojde během spouštění aplikace, jsou sledovány.
Utility JAMy zahrnují tři skupiny:
1) převodníky souborů obrazovky JAM na text. JAM ukládá obrazovky jako nativní binární soubory;
2) konfigurace vstupních/výstupních zařízení. JAM a aplikace s ním vytvořené nepracují přímo s I/O zařízeními. Místo toho JAM přistupuje k logickým I/O zařízením (klávesnice, terminál, sestava);
3) údržba knihoven obrazovek.
Jedním z přídavných modulů JAM je generátor zpráv. Rozvržení sestavy se provádí v editoru obrazovky JAM. Činnost sestavy je popsána pomocí speciálního jazyka. Generátor sestav umožňuje definovat data zobrazená v sestavě, seskupení výstupních informací, formátování výstupu atd.
Aplikace vyvinuté pomocí JAM lze vytvářet jako spustitelné moduly. K tomu musí mít vývojáři kompilátor C a linker.
JAM obsahuje vestavěný programovací jazyk JPL (JAM Procedural Language), pomocí kterého lze v případě potřeby napsat moduly implementující konkrétní akce. Tento jazyk je interpretován. Je možné vyměňovat informace mezi vizuálně vytvořeným aplikačním prostředím a takovými moduly. JAM navíc poskytuje možnost připojit externí moduly napsané v jazycích kompatibilních s jazykem C, pokud jde o volání funkcí.
JAM je systém orientovaný na události, skládající se ze sady událostí - otevírání a zavírání oken, stisknutí klávesy na klávesnici, spuštění systémového časovače, příjem a předání ovládání každého prvku obrazovky. Vývojář implementuje aplikační logiku definováním obsluhy pro každou událost.
Obslužné programy událostí JAM může obsahovat jak vestavěné funkce JAM, tak funkce napsané vývojářem v C nebo JPL. Sada vestavěných funkcí obsahuje více než 200 funkcí pro různé účely; jsou k dispozici pro volání funkcí napsaných v JPL i C.
Průmyslová verze aplikace, vyvinutý pomocí JAM, se skládá z následujících komponent:
1. spustitelný modul aplikačního interpretru;
2. obrazovky, které tvoří aplikaci (dodávané jako samostatné soubory, jako součást knihoven obrazovek nebo zabudované do těla interpretu);
3. externí moduly JPL (dodávané jako textové soubory nebo v předkompilované podobě; předkompilované
4. externí moduly JPL - ve formě samostatných souborů a jako součást knihoven obrazovek);
5. konfigurační soubory aplikace - konfigurační soubory klávesnice a terminálu, soubor systémových zpráv, obecný konfigurační soubor.
Přímou interakci s DBMS realizují moduly JAM/DBi (Database interface). Metody pro implementaci interakce v JAM jsou rozděleny do dvou tříd: manuální a automatické.
Na ručním způsobem Vývojář nezávisle zapisuje dotazy v SQL, ve kterých mohou být zdroji a cíli pro příjem výsledků dotazů jak prvky rozhraní vizuálně navržené externí úrovně, tak interní proměnné, které jsou pro koncového uživatele neviditelné.
Automatický režim implementovaný správcem transakcí JAM. Je to proveditelné pro typické běžné typy databázových operací, tzv. QBE (Query By Example - dotazy založené na vzorku), při zohlednění poměrně složitých vztahů mezi databázovými tabulkami a automatické kontrole atributů vstupně-výstupních polí obrazovky v závislosti na na typu transakce (čtení, zápis atd.), které se vygenerovaný požadavek účastní.
JAM vám umožňuje vytvářet aplikace pro práci s více než 20 DBMS: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, DBMS kompatibilní s ODBC atd.
Charakteristickým rysem JAM je vysoká úroveň přenositelnosti aplikací mezi různými platformami (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS atd.); může být nutné „překreslit“ statická textová pole na obrazovkách ruským textem při přenosu mezi prostředími DOS-Windows-UNIX. Přenositelnost je navíc usnadněna skutečností, že v JAM jsou aplikace vyvíjeny spíše pro virtuální I/O zařízení než pro fyzická. Při migraci aplikace z platformy na platformu tedy obvykle potřebujete pouze mapovat fyzická I/O zařízení na jejich logické reprezentace pro aplikaci.
Použití SQL jako prostředku interakce s DBMS také pomáhá zajistit přenositelnost mezi DBMS. Pokud je struktura databáze přenesena, aplikace nemusí vyžadovat žádné úpravy, s výjimkou inicializace pracovní relace. To je možné, pokud aplikace nepoužívala rozšíření SQL specifická pro DBMS.
Když se zvyšuje zatížení systému a využívá se složitost řešených úloh (distribuce a heterogenita použitých zdrojů, počet současně připojených uživatelů, složitost aplikační logiky). třívrstvý model architektury"klient - server" pomocí transakčních manažerů. Komponenty JAM/TPi-Client a JAM/TPi-Server usnadňují přechod na třívrstvý model. V tomto případě hraje klíčovou roli modul JAM/TPi-Server, protože hlavní problém implementace třívrstvého modelu spočívá v implementaci aplikační logiky ve službách transakčního manažera.
Rozhraní JAM/CASE umožňuje výměnu informací mezi úložištěm objektů JAM a úložištěm nástrojů CASE. Výměna je podobná tomu, jak se databázová struktura importuje do úložiště JAM přímo z databáze. Rozdíl je v tom, že výměna mezi repozitáři je obousměrná.
Kromě modulů JAM/CASEi existuje také modul JAM/CASEi Developer's Kit Pomocí tohoto modulu můžete samostatně vyvinout rozhraní (tedy specializovaný modul JAM/CASEi) pro konkrétní nástroj CASE, pokud existuje. hotový modul JAM/CASEi pro něj neexistuje.
Existuje rozhraní, které implementuje interakci mezi nástrojem Silverrun CASE a JAM. Přenáší schéma databáze a formuláře obrazovky aplikace mezi nástrojem Silverrun-RDM CASE a JAM verze 7.0; má dva provozní režimy:
1) přímý režim (Silverrun-RDM->JAM) je určen pro vytváření objektů CASE slovníku a prvků úložiště JAM na základě reprezentace schémat v Silverrun-RDM. Na základě reprezentace datových modelů rozhraní v Silverrun-RDM jsou generovány obrazovky a prvky úložiště JAM. Most převádí tabulky relačních schémat RDM a vztahy do sekvence objektů JAM příslušných typů. Metodika pro vytváření datových modelů rozhraní v Silverrun-RDM zahrnuje použití subobvodového mechanismu pro prototypování obrazovek aplikací. Na základě popisu každého z dílčích obvodů RDM můstek vygeneruje formulář obrazovky JAM;
2) reverzní režim (JAM->Silverrun-RDM) je určen pro přenos modifikací objektů CASE slovníku do relačního modelu Silverrun-RDM.
Režim reengineering umožňuje převedení úprav všech vlastností obrazovky JAM dříve importovaných z RDM do schématu Silvcrrun. Pro kontrolu integrity databáze nejsou povoleny změny schématu ve formě přidávání nebo odstraňování tabulek a polí tabulek.
Jádro JAM má vestavěné rozhraní pro nástroje pro správu konfigurace (PVCS na platformě Windows a SCCS na platformě UNIX). Knihovny obrazovek a/nebo úložiště jsou převedeny pod kontrolu těchto systémů. Pokud takové systémy neexistují, JAM nezávisle implementuje některé funkce na podporu rozvoje skupiny.
Na platformě MS-Windows má JAM vestavěné rozhraní k PVCS a akce načítání/odhlášení se provádějí přímo z prostředí JAM.
Vantage Team Builder (Westmount I-CASE). Vantage Team Builder je integrovaný softwarový produkt navržený pro implementaci a plnou podporu vodopádového modelu životního cyklu.
Vantage Team Builder poskytuje následující funkce:
1. navrhování diagramů toku dat, diagramů vztahů mezi entitami, datových struktur, programových blokových diagramů a sekvencí obrazovkových formulářů;
2. návrh schémat architektury systému - SAD (návrh skladby a komunikace výpočetních nástrojů, rozdělování systémových úloh mezi výpočetní nástroje, modelování vztahů klient-server, analýza využití transakčních manažerů a vlastností fungování systémů v reálném čase);
3. generování programového kódu v jazyce cílového DBMS s plnou podporou softwarového prostředí a generování SQL kódu pro tvorbu databázových tabulek, indexů, integritních omezení a uložených procedur;
4. programování v jazyce C s vestavěným SQL;
5. správa verzí a konfigurace projektu;
6. víceuživatelský přístup k úložišti projektu;
7. generování projektové dokumentace pomocí standardních a individuálních šablon;
8. export a import dat projektu ve formátu CDIF (CASE Data Interchange Format).
Vantage Team Builder se dodává v různých konfiguracích v závislosti na použitém DBMS (ORACLE, Informix, Sybase nebo Ingres) nebo nástrojích pro vývoj aplikací (Uniface). Konfigurace Vantage Team Builder pro Uniface se od ostatních liší v částečném zaměření na spirálový model životního cyklu díky svým schopnostem rychlého prototypování. K popisu projektu AIS se používá velká sada diagramů.
Při konstrukci všech typů diagramů je zajištěna kontrola souladu modelů se syntaxí použitých metod a také kontrola korespondence stejnojmenných prvků a jejich typů pro různé typy diagramů.
Při konstrukci diagramů toku dat DFD je sledována shoda diagramů na různých úrovních rozkladu. Správnost nejvyšší úrovně DFD je monitorována pomocí matice seznamu událostí ELM. Pro řízení rozkladu složených datových toků se používá několik možností jejich popisu: ve formuláři diagramy struktury dat DSD popř zápisy BNF (Backus - Naur forma).
K sestavení SAD se používá rozšířená notace DFD, která umožňuje zavést pojmy procesory, úlohy a periferní zařízení, což zajišťuje přehlednost konstrukčních řešení.
Při sestavování datového modelu ve formě ERD dochází k jeho normalizaci a je zavedena definice fyzických názvů datových prvků a tabulek, které budou použity v procesu generování fyzického datového schématu konkrétní DBMS. Je možné určit alternativní klíče entit a polí, které tvoří další vstupní body do tabulky (indexová pole), a sílu vztahů mezi entitami.
Přítomnost univerzálního systému generování kódu založeného na specifikovaných prostředcích přístupu k úložišti projektu umožňuje vývojářům udržovat vysokou úroveň provedení disciplíny designu: přísné pořadí generování modelu; pevná struktura a obsah dokumentace; automatické generování zdrojových kódů programu atd.; to vše zajišťuje zvýšení kvality a spolehlivosti vyvinutých integrovaných obvodů.
Pro přípravu projektové dokumentace lze využít publikační systémy FrameMaker, Interleaf nebo Word Perfect. Struktura a skladba projektové dokumentace je konfigurována v souladu se stanovenými normami. Přizpůsobení se provádí bez změny konstrukčních řešení.
Při vývoji velkých AIS celý systém jako celek odpovídá jednomu projektu jako kategorie Vantage Team Builder. Projekt lze rozložit na řadu systémů, z nichž každý odpovídá nějakému relativně autonomnímu subsystému AIS a je vyvíjen nezávisle na ostatních. V budoucnu mohou být projektové systémy integrovány.
Proces návrhu AIS pomocí Vantage Team Builder je implementován ve formě čtyř po sobě jdoucích fází (fází) - analýza, architektura, design A implementace, v tomto případě jsou dokončené výsledky každé fáze plně nebo částečně přeneseny (importovány) do další fáze. Všechny diagramy, kromě ERD, jsou převedeny na jiný typ nebo mění svůj vzhled v souladu s charakteristikami aktuální fáze. DFD se tedy ve fázi architektury převádějí na SAD, DSD na DTD. Jakmile je import dokončen, logické spojení s předchozí fází je přerušeno, tj. lze provést všechny potřebné změny ve schématech.
Konfigurace Vantage Team Builder pro Uniface zajišťuje sdílení dvou systémů v rámci jednoho technologického návrhového prostředí, zatímco databázová schémata (SQL modely) se přenášejí do úložiště Uniface a naopak, aplikační modely generované nástroji Uniface lze přenášet do Vantage. Úložiště Team Builderu. Případné nesrovnalosti mezi úložišti obou systémů jsou eliminovány pomocí speciální utility. Vývoj obrazovkových formulářů v prostředí Uniface probíhá na základě FSD sekvenčních diagramů formulářů po importu SQL modelu. Technologie pro vývoj AIS na základě této konfigurace je znázorněna na Obr. 2.23.
Struktura úložiště uloženého v cílovém DBMS a rozhraní Vantage Team Builder jsou otevřené, což v principu umožňuje integraci s libovolnými dalšími nástroji.
Uniface. Produkt Compuware je vývojové prostředí pro rozsáhlé aplikace v architektuře klient-server a má následující architekturu komponent:
1. Application Objects Repository (repository aplikačních objektů) obsahuje metadata, která jsou automaticky používána všemi ostatními komponentami v průběhu životního cyklu AIS (aplikační modely, popisy dat, obchodní pravidla, obrazovkové formuláře, globální objekty a šablony). Úložiště může být uloženo v kterékoli z databází podporovaných Uniface;
Rýže. 2.23. Interakce mezi Vantage Team Builder a Uniface
2. Application Model Manager podporuje aplikační modely (E-R modely), z nichž každý představuje podmnožinu obecného databázového schématu z pohledu dané aplikace a obsahuje odpovídající grafický editor;
3. Rapid Application Builder – nástroj pro rychlé vytváření obrazovkových formulářů a sestav založených na objektech aplikačního modelu. Zahrnuje grafický editor formulářů, prototypování, ladění, testování a dokumentační nástroje. Pro stávající grafická rozhraní - MS Windows (včetně VBX), Motif, OS/2 bylo implementováno rozhraní s různými typy ovládání oken Open Widget Interface. Univerzální prezentační rozhraní umožňuje používat stejnou verzi aplikace v různých grafických rozhraních beze změny programového kódu;
4. Vývojářské služby slouží k podpoře velkých projektů a implementaci správy verzí (Uniface Version Control System), přístupových práv (oddělení pravomocí), globálních úprav atd. To poskytuje vývojářům nástroje pro paralelní návrh, kontrolu vstupu a výstupu, vyhledávání, prohlížení, údržba a vydávání zpráv o datech systému správy verzí;
5. Deployment Manager (správa distribuce aplikací) - nástroje, které umožňují připravit vytvořenou aplikaci k distribuci, nainstalovat a udržovat ji (v tomto případě se platforma uživatele může lišit od platformy vývojáře). Zahrnují síťové ovladače a ovladače DBMS, aplikační server (polyserver), distribuci aplikací a nástroje pro správu databází. Uniface podporuje rozhraní s téměř všemi známými hardwarovými a softwarovými platformami, DBMS, CASE nástroji, síťovými protokoly a transakčními manažery;
6. Personal Series (osobní nástroje) slouží k vytváření složitých dotazů a sestav v grafické podobě (Personal Query a Personal Access - PQ/PA), jakož i k přenosu dat do systémů jako WinWord a Excel;
7. Distributed Computing Manager - integrační nástroj s transakčními manažery Tuxedo, Encina, CICS, OSF DCE.
Verze Uniface 7 plně podporuje distribuovaný výpočetní model a třívrstvou architekturu klient-server (s možností měnit schéma dekompozice aplikací za běhu). Aplikace vytvořené pomocí Uniface 7 lze spouštět v heterogenních operačních prostředích pomocí různých síťových protokolů současně na několika heterogenních platformách (včetně internetu).
Mezi komponenty Uniface 7 patří:
1. Uniface Application Server - aplikační server pro distribuované systémy;
2. WebEnabler - serverový software pro provoz aplikací na internetu a intranetu;
3. Name Server - serverový software, který zajišťuje využití distribuovaných aplikačních zdrojů;
4. PolyServer - nástroj pro přístup k datům a integraci různých systémů.
Seznam podporovaných DBMS zahrnuje DB2, VSAM a IMS; PolyServer také poskytuje interakci s OS MVS.
Designer/2000 + Developer/2000. Designer/2000 2.0 od společnosti ORACLE je integrovaný CASE nástroj, který spolu s nástroji pro vývoj aplikací Developer/2000 poskytuje podporu pro kompletní životní cyklus softwaru pro systémy využívající ORACLE DBMS.
Designer/2000 je rodina metodologií a softwarových produktů, které je podporují. Základní metodika Designer/2000 (CASE*Method) je strukturální metodika pro návrh systému, která plně pokrývá všechny fáze životního cyklu AIS. Ve fázi plánování jsou stanoveny cíle tvorby systému, priority a omezení, je vypracována architektura systému a plán rozvoje AIS. Během procesu analýzy se sestaví: model informačních potřeb (diagram vztahů entit), diagram funkční hierarchie (založený na funkčním rozkladu AIS), matice křížových odkazů a diagram toku dat.
Ve fázi návrhu je vyvinuta podrobná architektura AIS, je navrženo schéma relační databáze a softwarové moduly a jsou vytvořeny křížové odkazy mezi komponenty AIS pro analýzu jejich vzájemného vlivu a řízení změn.
Ve fázi implementace je vytvořena databáze, vybudovány aplikační systémy, jsou testovány, kontrolována kvalita a soulad s požadavky uživatelů. Je vytvořena systémová dokumentace, školicí materiály a uživatelské příručky. Ve fázi provozu a údržby je analyzována výkonnost a integrita systému, je prováděna podpora a v případě potřeby úprava AIS.
Designer/2000 poskytuje grafické rozhraní pro vývoj různých modelů (diagramů) dané oblasti. Během procesu vytváření modelů se informace o nich zadávají do úložiště. Designer/2000 obsahuje následující komponenty.
Design AIS
Detailní vývoj návrh systému, obsahující kompletní soubor jeho organizační, projektové, technologické a provozní dokumentace. V souladu s GOST 34.601-90. Návrh automatizovaných systémů zahrnuje realizaci řady fází, mezi něž patří: tvorba požadavků na AS, vývoj koncepce AS, vývoj technických specifikací, předběžný návrh, technický návrh a vypracování pracovní dokumentace. Fáze tvorby AS kromě návrhu také zahrnují: uvedení do provozu a údržbu AS. Každá etapa je rozdělena na etapy. Přílohy této normy také definují:
· Seznam typů organizací podílejících se na práci.
V závislosti na povaze projektovaného objektu a jeho konkrétních podmínkách umožňuje GOST 34.601-90 vyloučení jednotlivých etap a také jejich kombinaci. S přihlédnutím k dlouhodobé praxi v Rusku při vytváření automatizovaných informačních systémů (" AIS”) se obvykle provádějí následující fáze návrhu: předprojektový průzkum, koncepční návrh, předběžný návrh, technický návrh a podrobný návrh. Další státní normy upravující různé aspekty designu reproduktorů:
· GOST 34.602-89 Soubor norem pro automatizované systémy. Zadání pro vytvoření automatizovaného systému. Vloženo 01.01.90.
· Standardní 34.603-92 Informační technologie. Typy AC testů.
· Standardy 34. (971, 972,973, 974, 981) - 91 Informační technologie. Propojení otevřených systémů.
· Standardní 34,91. Informační technologie. Místní sítě atd.
Předprojektový průzkum- Shromažďování a zpracování informací o organizaci a vlastnostech fungování objektu automatizace, včetně údajů o jeho interakci s vnějším prostředím a jinými objekty, jakož i o implementaci systémové analýzy, vypracování studie proveditelnosti proveditelnosti automatizace a vypracování obecných požadavků na vývoj automatizovaného systému. Obsah práce při předprojektové kontrole automatizačního zařízení odpovídá etapě „Formování požadavků na automatizovaný systém“ GOST 34.601-90, etapám: „Inspekce objektu a zdůvodnění potřeby vytvoření automatizovaného systému “, “Formování uživatelských požadavků na automatizovaný systém”, “Vytvoření zprávy o provedené práci a aplikace pro vývoj AC - taktických a technických specifikací.”
Koncepční design- Odpovídá fázím návrhu v souladu s GOST 34.601-90 - „Zpracování koncepce JE“ (etapy: „Vývoj variant koncepce JE a výběr varianty koncepce JE, která uspokojí uživatele“, „Zpracování zprávy o provedené práce“) a „Vypracování technických specifikací“. Druhy konečných dokumentů práce v této fázi jsou předběžný projekt(používají se také názvy - “ Koncepční design ”, “Pilotní projekt") nebo Program vytvoření systému, který obsahuje:
· Stručný popis výchozího stavu objektu automatizace a prostředí, ve kterém pracuje;
· Označení hlavních cílů a seznam úloh automatizace;
· Popis rozšířené organizační a funkční struktury vybrané možnosti (nebo možností) pro konstrukci vytvářeného systému;
· Studie proveditelnosti;
· Integrovaný popis a základní požadavky na informační a jazykové podpůrné nástroje;
· Všeobecné požadavky na software a hardware;
· Výčet a rozšířené charakteristiky fází tvorby systému, načasování jejich implementace, složení účinkujících a očekávané výsledky jejich implementace;
· Počáteční posouzení ukazatelů nákladů na dílo;
· Technické specifikace systému jako celku a/nebo jeho hlavních komponent (subsystémy, softwarové a hardwarové systémy a nástroje, jednotlivé úkoly atd.), schválené Zákazníkem.
Schematický návrh- Vývoj předběžných konstrukčních řešení systému a jeho částí. Konečným dokumentem pro provedení práce v této fázi návrhu je předběžný návrh, která obsahuje zásadní návrh a obvodová řešení vývojového objektu a dále údaje definující jeho účel a základní parametry (při návrhu software systému, předběžný návrh musí obsahovat kompletní Specifikace se vyvíjí programy).
Technické provedení - Fáze práce na návrhu reproduktorového systému, která zahrnuje:
· Vývoj konstrukčních řešení systému a jeho částí;
· zpracování dokumentace pro JE a její části;
· Vypracování a zpracování dokumentace pro dodávku produktů pro dostavbu JE a/nebo technické požadavky (technické specifikace) pro jejich vypracování;
· Vývoj konstrukčních úloh v přilehlých částech projektu automatizačního zařízení.
Konečným dokumentem této fáze návrhu je technický projekt, obsahující kromě uvedených materiálů, schémat zapojení a projektové dokumentace vývojového objektu a jeho součástí i seznam vybraných hotových nástrojů software a hardware(včetně počítačů, operační systém, aplikační programy atd.), a také algoritmyřešení problémů pro vývoj nových softwarových nástrojů atd.
Detailní provedení- Poslední stadium design, která kromě vypracování pracovní dokumentace systému a jeho částí požadovaných GOST 34.601-90 obecně zajišťuje objasnění a upřesnění výsledků předchozích etap, vytvoření a testování prototypu a/nebo pilotního průmyslového modelu automatizačního objektu, vývoj a testování softwarových produktů, technologické a provozní dokumentace. Výsledky jsou uvedeny v pracovník nebo projekt technické práce. V moderní designové praxi automatizované informační systémy(Například, ABIS, ASNTI, ACS atd.) je to počáteční fáze jejich implementace v práci firmy, organizace nebo služby, která je objednatelem projektu, případně mateřskou v řadě dalších automatizovaných firem, organizací, služeb atp.
Vývojový (designový) cyklus) software - Sada vývojových fází software začínající od systémové analýzy a vývoj počátečních požadavků před jeho implementací.
Principy návrhu AIS- Soubor pravidel nebo požadavků stanovených mnohaletými různorodými zkušenostmi s tvorbou a provozem AIS. Nejběžnější jsou:
· Identita- vývoj nového, vylepšení stávajícího nebo implementace externě získaného AIS jsou vědeckotechnické problémy obsahově podobné, liší se od sebe pouze obsahem řady etap a časových parametrů ;
· Vyrobitelnost: automatizovaná technologie znamená vývoj nové technologie nebo modernizaci stávající v podmínkách AIS a neumožňuje jednoduché použití vyvinutého software a hardware v podmínkách starých tradičních technologií;
· Kontinuita, fázování a kontinuita vývoje a vývoje: AIS jsou systémy, které se na jejich základě neustále vyvíjejí; každá inovace slouží jako rozvoj základních systémových principů a již dosažené kvality;
· Přizpůsobivost: Komponenty AIS musí mít vlastnosti, které zajistí rychlé přizpůsobení těchto komponent změnám vnějšího prostředí a novým prostředkům;
· Modulární princip konstrukce softwaru a hardwaru: předpokládá, že složení těchto nástrojů sestává z bloků („modulů“), které poskytují možnost jejich nahrazení nebo změny za účelem zlepšení fungování AIS nebo jeho přizpůsobení novým podmínkám;
· Technologický (včetně - sítě) integrace: předpokládá jednotu pro celý systém technologie tvorby, aktualizace, ukládání a využívání informačních zdrojů a zejména jednorázové zpracování dokumentů a dat, jakož i jejich mnohostranné a víceúčelové využití;
· Kompletní normalizace procesů a jejich sledování: víceúčelové využití informací AIS vyžaduje zajištění vysoké spolehlivosti dat v systému. K tomu je v různých fázích zpracování a zadávání informačních dokumentů nutné využívat různé formy informační kontroly, na kterou lze požadavky tvořit ze skladby řešených úloh a zpracovávaných dat. neustálé sledování je rovněž nezbytné pro získání kvalitativních a kvantitativních charakteristik fungování AIS na základě vestavěných a speciálně vyvinutých nástrojů inteligentní statistiky;
· Nařízení: AIS jsou zaměřeny na fungování v průmyslovém režimu, zajišťující hromadné zpracování informačních dokumentů; Toto zpracování je regulováno standardy, směrovými a provozními technologiemi, standardy pro ukazatele zdrojů a času a rozvinutou dispečerskou službou.
· Ekonomická výhodnost: tvorba AIS by měla zahrnovat výběr takových konstrukčních řešení (včetně softwarových, technických a organizačně-technologických), která při splnění stanovených cílů a záměrů zajistí minimalizaci nákladů na finanční, materiálové a pracovní zdroje.
· Typizace konstrukčních řešení: rozvoj a rozvoj AIS a jejich sítí je prováděn se zaměřením na meziknihovní spolupráci a kooperaci, jakož i v souladu s pravidly a protokoly mezinárodní výměny informací;
· Maximální využití hotových řešení: pro snížení nákladů a času na vývoj a implementaci AIS, jakož i pro snížení konstrukčních chyb jak systému jako celku, tak jeho jednotlivých komponent, se doporučuje v maximální možné míře využívat hotová řešení a nástroje. V tomto plánu je při vytváření nového systému značné množství práce spojeno s rozborem alternativních možností možných řešení, výběrem toho nejvhodnějšího pro objekt automatizace a jeho přizpůsobením novým podmínkám aplikace;
· Firemní duch: při návrhu automatizovaného systému, který je součástí systému vyšší úrovně (město, odbor, republika apod.), je třeba zajistit jeho hardwarovou, softwarovou, jazykovou a informační kompatibilitu s ostatními účastníky systému a/nebo sítě AIS. Požadavky korporativismu mohou být v rozporu s požadavky nebo rozhodnutími diktovanými jinými principy, například kontinuitou rozhodnutí o designu;
· Orientace na první osoby objektu automatizace: úspěšná realizace prací na vytvoření automatizovaného informačního systému, jeho rozvoj a provoz je možný pouze za předpokladu, že jsou bezvýhradně podporovány první osobou objektu automatizace (například ředitel knihovny nebo informační agentury) a přímá odpovědnost za jejich prováděním je příkazem organizace pověřen vedoucí pracovník na úrovni minimálně zástupce ředitele
REGULAČNÍ A METODICKÁ PODPORA VYTVOŘENÍ AIS.
Základní koncepty návrhu AIS
Obecně AIS zahrnuje: uživatele (spotřebitele), informační zdroje, nosiče informací, prostředky pro sběr, ukládání, zpracování informací a prostředky pro přenos informací.
Návrh AIS je založen na dvou vzájemně souvisejících komponentách:
Design Standards;
Metodika návrhu.
Základní pojmy, přístupy a definice návrhu AIS jsou regulovány třemi typy projektové a softwarové dokumentace:
- jednotný systém projektové dokumentace (ESKD);
- jednotný systém programové dokumentace (USPD);
- soubor pokynů pro AIS.
Složení projektové dokumentace je soubor norem a směrnic vycházejících z AIS GOST 24.104-85, GOST 34.003-90, GOST 34.201-90, který zahrnuje směrnice pro informační technologie a automatizované systémy, jakož i požadavky na obsah dokumentů.
Cílem návrhu je identifikovat relativně jednoduchou vnitřní strukturu, nazývanou architektura systému.
AIS je vyvíjen jako projekt. Mnoho rysů projektového řízení a fáze vývoje projektu (fáze životního cyklu) je společných, nezávislých nejen na předmětu, ale také na povaze projektu. Pojem projekt je komplexní pojem a je těžké pro něj najít jednoznačnou formulaci.
Projekt– jedná se o časově omezenou, účelovou změnu na samostatný systém s původně jasně stanovenými cíli, jejichž dosažení podmiňuje dokončení projektu, dále se stanovenými požadavky na načasování, výsledky, riziko, rámec pro vynakládání finančních prostředků a zdrojů a pro organizační strukturu.
Pro ekonomické systémů, projektem EIS rozumíme projektovou a inženýrskou dokumentaci, která poskytuje popis konstrukčních řešení pro tvorbu a provoz EIS v konkrétním softwarovém a hardwarovém prostředí.
Pod designem EIS rozumí procesu převodu vstupních informací o designovém objektu, metodám navrhování a zkušenostem s navrhováním objektů podobného účelu v souladu s GOST do projektu EIS. Z tohoto pohledu návrh EIS spočívá v důsledné formalizaci návrhových řešení v různých fázích životního cyklu EIS: plánování a analýza požadavků, technický a detailní návrh, implementace a provoz EIS.
Designové objekty EIS jsou jednotlivé prvky nebo jejich komplexy funkčních a nosných částí. Funkčními prvky jsou tedy v souladu s tradičním rozkladem úkoly, soubory úkolů a řídící funkce. V rámci nosné části EIS jsou návrhovými objekty prvky a jejich komplexy informační, softwarové a hardwarové podpory systému.
Jako předmět Návrh EIS zahrnuje týmy specialistů, kteří provádějí projekční činnost, obvykle v rámci specializované (projekční) organizace, a zákaznickou organizaci, pro kterou je nutné EIS vyvinout. Rozsah vyvíjených systémů určuje složení a počet účastníků procesu návrhu. Při velkém objemu a krátkých termínech dokončení projekční práce se na vývoji systému může podílet několik konstrukčních týmů (vývojových organizací). V tomto případě je identifikována mateřská organizace, která koordinuje aktivity všech spoluvykonávajících organizací.
Forma účasti spoluřešitelů na vývoji systémového projektu může být různá. Nejběžnější formou je, že každý spolurealizátor provádí projekční práce od začátku do konce pro nějakou část vyvíjeného systému. Obvykle se jedná o funkční subsystém nebo propojenou sadu úloh správy. Méně obvyklá je forma účasti spoluvykonavatelů, kdy jednotliví spoluvykonavatelé vykonávají práci v určitých fázích procesu návrhu. Je možná varianta, ve které jsou funkce zákazníka a vývojáře kombinovány, to znamená, že EIS je navržen in-house.
Provádění návrhu EIS zahrnuje použití konstruktérů určité konstrukční technologie odpovídající rozsahu a vlastnostem vyvíjeného projektu.
Technologie návrhu EIS- jedná se o soubor metodologie a nástrojů pro návrh EIS, stejně jako metod a prostředků pro organizaci návrhu (řízení procesu tvorby a modernizace projektu EIS)
Metodika (koncept + metoda)
Organizace nástrojů
designový design
Technologie návrhu je založena na technologickém procesu, který určuje akce, jejich posloupnost, složení účinkujících, prostředky a zdroje potřebné k provedení těchto akcí.
Technologický proces návrhu EIS jako celku je tedy rozdělen do souboru sekvenčně-paralelních, propojených a podřízených řetězců akcí, z nichž každý může mít svůj vlastní předmět. Akce, které jsou prováděny při návrhu EIS, lze definovat jako nedělitelné technologické operace nebo jako podprocesy technologických operací. Všechny akce mohou být samotné návrhové akce, které tvoří nebo modifikují výsledky návrhu, a hodnotící akce, které jsou vyvíjeny podle stanovených kritérií pro posuzování výsledků návrhu.
Technologie návrhu je tedy specifikována regulovaným sledem technologických operací prováděných v procesu vytváření projektu na základě konkrétní metody, v důsledku čehož by bylo jasné nejen to, co je třeba udělat pro vytvoření projektu, ale také JAK, KOMU a V JAKÉM POŘADÍ to musí být provedeno.
Předmětem jakékoli zvolené návrhové technologie by měla být reflexe vzájemně souvisejících návrhových procesů ve všech fázích životního cyklu EIS.
Mezi hlavní požadavky na vybranou konstrukční technologii patří:
Projekt vytvořený pomocí této technologie musí splňovat požadavky zákazníka;
Zvolená technologie by měla co nejvíce odrážet všechny fáze životního cyklu projektu;
Zvolená technologie musí zajistit minimální mzdové a nákladové náklady na návrh a podporu projektu;
Technologie by měla být základem spojení mezi návrhem a údržbou projektu;
Technologie by měla pomoci zvýšit produktivitu návrhářů;
Technologie musí zajistit spolehlivost návrhu a provozu projektu;
Technologie by měla usnadnit snadnou údržbu projektové dokumentace.
Základem technologie návrhu EIS je metodika, která určuje podstatu, hlavní výrazné technologické rysy.
Metodika návrhu předpokládá přítomnost určitého konceptu, konstrukčních principů, realizovaných souborem konstrukčních metod, které zase musí být podporovány určitými konstrukčními nástroji.
Organizace návrhu zahrnuje stanovení metod interakce mezi projektanty mezi sebou a se zákazníkem v procesu vytváření projektu EIS, který může být také podpořen sadou specifických nástrojů.
Metody návrhu EIS lze klasifikovat podle míry využití automatizačních nástrojů, standardních konstrukčních řešení a přizpůsobivosti očekávaným změnám.
Ano, podle stupně automatizace Metody návrhu se dělí na metody:
ruční design, ve kterém se návrh komponent EIS provádí bez použití speciálních softwarových nástrojů a programování se provádí v algoritmických jazycích;
počítačový design, která generuje nebo konfiguruje (nastavuje) návrhová řešení založená na použití speciálních softwarových nástrojů.
Na základě míry použití standardních konstrukčních řešení se rozlišují následující konstrukční metody:
originální (individuální) design, kdy jsou konstrukční řešení vyvíjena „od začátku“ v souladu s požadavky na EIS;
Standardní návrh, který zahrnuje konfiguraci EIS z hotových standardních návrhových řešení (softwarových modulů).
Originální (individuální) návrh EIS se vyznačuje tím, že všechny typy projekční práce jsou zaměřeny na vytvoření individuálních projektů pro každý objekt, které v maximální míře odrážejí všechny jeho vlastnosti.
Standardní návrh je prováděn na základě zkušeností získaných při vývoji jednotlivých projektů. Typické projekty jako zobecnění zkušeností pro určité skupiny organizačních a ekonomických systémů nebo druhy prací v každém konkrétním případě jsou spojeny s mnoha specifickými rysy a liší se mírou pokrytí řídících funkcí, prováděných prací a vypracovávané projektové dokumentace.
Podle stupně adaptability konstrukčních řešení se konstrukční metody dělí na metody:
Rekonstrukce, kdy se provádí přizpůsobení konstrukčních řešení zpracováním příslušných komponent (přeprogramování softwarových modulů);
Parametrizace, kdy se návrhová řešení upravují (regenerují) v souladu se změněnými parametry;
Restrukturalizace modelu, kdy se mění model problémové oblasti, na základě čehož se automaticky regenerují konstrukční řešení.
Kombinace různých charakteristik klasifikace metod návrhu určuje povahu použité technologie návrhu EIS, mezi nimiž vynikají dvě hlavní:
třída: kanonické a průmyslové technologie (tabulka 2.1). Technologie průmyslového designu se zase dělí na dvě podtřídy: automatizovaný (s využitím CASE technologií) a standardní (parametrově orientovaný nebo modelově orientovaný) design. Použití technologií průmyslového designu v některých případech nevylučuje použití kanonické technologie.
Tabulka 2.1 Charakteristika tříd technologie návrhu
Specifické typy návrhových technologií se vyznačují použitím určitých vývojových nástrojů EIS, které podporují realizaci jak jednotlivých projekčních prací, etap, tak jejich kombinací. Vývojáři EIS proto zpravidla stojí před úkolem vybrat návrhové nástroje, které z hlediska svých vlastností nejlépe splňují požadavky konkrétního podniku.
Nástroje pro návrh by měly být:
Ve své třídě, invariantní k objektu designu;
Pokrýt souhrnně všechny fáze životního cyklu EIS;
Technicky, software a informace kompatibilní;
Snadno se učí a používá;
Ekonomicky proveditelné.
Návrhové nástroje EIS lze rozdělit do dvou tříd: bez použití počítače a s využitím počítače.
Návrhové nástroje bez použití počítače se používají ve všech fázích a fázích návrhu EIS. Zpravidla se jedná o prostředky organizační a metodické podpory projekční činnosti a především různé normy upravující proces návrhu systému. Patří sem také jednotný systém klasifikace a kódování informací, jednotný dokumentační systém, modely pro popis a analýzu informačních toků atd.
Návrhové nástroje s využitím počítače lze použít jak v jednotlivých, tak ve všech fázích a fázích procesu návrhu EIS a v souladu s tím podporují vývoj prvků návrhu systému, částí návrhu systému a návrhu systému jako celku. Celá sada návrhových nástrojů využívajících počítače je rozdělena do čtyř podtříd.
První podtřída zahrnuje operační nástroje, které podporují návrh operací zpracování informací. Tato podtřída nástrojů zahrnuje algoritmické jazyky, knihovny standardních podprogramů a tříd objektů, makrogenerátory, generátory programů pro typické operace zpracování dat atd., stejně jako nástroje pro rozšíření funkcí operačních systémů (utilit). Tato třída obsahuje i takové jednoduché návrhářské nástroje, jako jsou nástroje pro testování a ladění programů, podporující proces projektové dokumentace atd. Zvláštností nejnovějších programů je, že s jejich pomocí se zvyšuje produktivita designérů, ale není vyvinuto kompletní konstrukční řešení.
Nástroje této podtřídy tedy podporují jednotlivé operace návrhu EIS a lze je používat nezávisle na sobě.
Druhá podtřída zahrnuje nástroje, které podporují návrh jednotlivých komponent projektu EIS. Tato podtřída zahrnuje nástroje pro obecné systémové účely:
Systémy pro správu databází (DBMS);
Metodicky orientované balíčky aplikačních programů (řešení problémů diskrétního programování, matematické statistiky atd.)
Stolní procesory;
Statistická PPP;
Skořápky expertních systémů;
Grafický editor;
Textové editory;
Integrovaný software (interaktivní prostředí s vestavěnými dialogovými možnostmi, které umožňuje integrovat výše uvedené softwarové nástroje).
Uvedené konstrukční nástroje se vyznačují využitím pro vývoj technologických subsystémů EIS: vkládání informací, organizace ukládání a přístupu k datům, výpočty, analýza a zobrazování dat, rozhodování.
Třetí podtřída zahrnuje prostředky, které podporují návrh sekcí projektu EIS. Tato podtřída zahrnuje nástroje funkčního návrhu.
Funkční nástroje jsou zaměřeny na vývoj automatizovaných systémů, které implementují funkce, sady úloh a řídicí úlohy. Různorodost oborů dává vzniknout různým nástrojům této podtřídy, zaměřeným na typ organizačního systému (průmyslové, neprůmyslové sféry), úroveň řízení (například podnik, dílna, oddělení, pracoviště, pracoviště), management funkce (plánování, účetnictví atd.) .
Funkční nástroje pro navrhování systémů zpracování informací zahrnují standardní návrhová řešení, funkční balíčky aplikačních programů a standardní projekty.
Čtvrtá podtřída návrhových nástrojů EIS zahrnuje nástroje, které podporují vývoj projektu ve fázích a fázích procesu návrhu. Tato třída zahrnuje podtřídu nástrojů pro automatizaci návrhu EIS (CASE tools).
Moderní nástroje CASE jsou zase klasifikovány hlavně podle dvou kritérií:
1) podle fází zahrnutých v procesu vývoje EIS;
2) podle stupně integrace: samostatné lokální nástroje (nástroje), sada neintegrovaných nástrojů pokrývajících většinu fází vývoje EIS (toolkit) a plně integrované nástroje propojené společnou návrhovou databází – repozitářem (workbench).
Návrh AIS je kreativní proces. Každý projekt prochází ve svém vývoji určitými stavy: od stavu, kdy „projekt ještě neexistuje“, do stavu, kdy „projekt již neexistuje“. Soubor fází vývoje od vzniku nápadu až po úplné dokončení projektu se obvykle dělí na fáze (fáze, etapy). Existují určité rozdíly v určení počtu etap (fází) a jejich obsahu, ale přesto je podstata obsahu životního cyklu vývoje AIS v různých přístupech stejná.
Podle návrhučlověk by měl rozumět procesu vytváření prototypu předpokládaného nebo možného objektu.
Moderní technologie pro tvorbu AIS je souborem účinných nástrojů a návrhových metod, které umožňují zjednodušit tento proces, snížit náklady, zkrátit kalendářní čas pro návrh systému a zlepšit kvalitu vývoje prostřednictvím širokého výběru osvědčených pokročilých konstrukčních řešení.
K hlavnímu designové nástroje lze přičíst:
Standardní návrhová řešení (TDS) a aplikační softwarové balíčky (APP). TPR - soubor algoritmických a softwarových prvků, které zajišťují realizaci úkolů na počítači pomocí vhodných technických prostředků;
Systémy CAD (Computer-Aided Design), které zahrnují použití počítačů ve všech fázích tvorby AIS.
Obecné požadavky na konstrukční nástroje:
Úplné pokrytí celého procesu vytváření AIS;
Kompatibilita, tzn. důslednost jak v procesu tvorby systému, tak v procesu jeho fungování;
Všestrannost, tzn. schopnost používat stejné nástroje pro různé předměty;
Přístupnost k učení a jednoduchost (jednoduchost) implementace;
Schopnost organizovat proces návrhu v režimu interaktivní interakce mezi vývojářem systému, návrhářem a počítačem;
Adaptabilita a hospodárnost.
Mezi metody návrhu zvýraznit:
Originální design;
Standardní provedení a jeho typy: elementární, subsystémové, modulární, skupinové;
Automatizovaný design.
Původní metoda designu je tradiční a zaměřená na jeden konkrétní podnik. Charakteristickým rysem této metody je vývoj originálních metod zkoumání objektu a vytvoření potřebné dokumentace formou individuálního projektu. Výhodou této metody je zohlednění specifických vlastností objektu automatizace v projektu AIS. Mezi nevýhody patří relativně vysoká pracnost a dlouhá doba vývoje, nízká funkční spolehlivost a adaptabilita na měnící se podmínky. Projekty vytvořené původní metodou lze modernizovat, ale tato metoda se v čisté podobě používá jen zřídka. Dnes se při jeho realizaci používají různé konstrukční nástroje a pouze určité části projektu vyžadují originální konstrukční řešení. Tím se poněkud vyhladí jeho nedostatky. Tato metoda však zůstává relevantní při automatizaci složitých, mimořádných objektů.
V moderních podmínkách se AIS zpravidla nevytváří od nuly. V současné době v ekonomice fungují systémy automatizovaného zpracování informací téměř na všech úrovních řízení a na všech ekonomických zařízeních. Zvýšená potřeba včasných, kvalitních a operativních informací vyžaduje vytvoření automatizovaného informačního systému na nové technické a technologické bázi.
Hledání racionálních cest návrhu se provádí v následujících směrech:
1. vývoj standardních návrhových řešení implementovaných v aplikačních softwarových balíčcích (APP) pro řešení ekonomických problémů s následnou vazbou PPP na konkrétní podmínky implementace a provozu;
2. vývoj automatizovaných konstrukčních systémů.
Prvním způsobem je možnost využití standardních konstrukčních řešení obsažených v aplikačních softwarových balíčcích.
Standardní provedení- průmyslová metoda tvorby AIS pomocí TPR a PPP. Tato metoda se vyznačuje přítomností osvědčených, standardních organizačních, ekonomických, technických, informačních, matematických a softwarových nástrojů automatizace řízení. Použití této metody umožňuje snížit pracnost, snížit náklady, zkrátit dobu návrhu a zlepšit kvalitu návrhu. Standardní proces návrhu spočívá ve výběru a propojení podpůrných subsystémů v souladu s požadavky konkrétního AIS. Typickou součástí AIS je komplex informací, softwaru a hardwaru. Standardního charakteru informační podpory je dosaženo přísným dodržováním jednoty struktury informační báze, složení polí a forem vstupních a výstupních dokumentů. Standardní povahy softwaru je dosaženo použitím softwaru a standardní povahy hardwaru je dosaženo použitím počítačů stejného nebo společného typu.
1. Obměnou standardní metody návrhu je metoda elementární design, jehož základem je TPR. Při vývoji projektu se používá spíše hotové řešení s drobnými úpravami než vyvíjené nové.
2. Při použití modulární metoda TPR vznikají na modulární bázi, kdy je každé konstrukční řešení rozděleno na samostatné komponenty – moduly, které implementují určitou část TPR. To umožňuje vytvořit projekt pro nový automatizovaný systém kombinací jednotlivých standardních modulů.
3. Při použití metoda návrhu subsystému Pro každý subsystém jsou vytvořena projektová řešení a aplikační softwarové balíčky – celosystémové a funkční. Přidělování subsystémů závisí na předmětu ekonomického a výrobního procesu. Pro každý ze subsystémů je vyvinuto jeho vlastní řešení automatizovaného návrhu a PPP, které může být celosystémové nebo funkční. Mezi celosystémové patří PPP pro správu dat, PPP pro standardní postupy zpracování dat, metody matematické statistiky a diskrétního programování atd. Funkční PPP zahrnují balíčky zaměřené na průmyslové podniky s diskrétním nebo kontinuálním charakterem výroby, neprůmyslovou sféru, a řízení průmyslu.
Důležitým požadavkem na PPP je kompatibilita, protože Při návrhu AIS je vhodné použít několik balíčků najednou. Navrhování systémů pomocí PPP ve skutečnosti spočívá v propojení balíčků vybraných podle určitých parametrů se specifickými podmínkami objektu automatizace. Pozitivní vlastnosti tohoto přístupu k projektování lze nazvat: méně pracný proces, zkrácení doby návrhu oproti původnímu návrhu, implementace pokročilých metod zpracování dat, zjednodušení projektové dokumentace (jelikož se používá balíková dokumentace), a zvýšenou spolehlivost navrženého AIS.
4. Navíc zvýrazňují metoda skupinového návrhu. Jeho podstata spočívá v předběžném výběru skupiny objektů s podobnými vlastnostmi. Mezi nimi je vybrán základní objekt, pro který je projekt vyvíjen, a lze použít různé metody a metody návrhu. Hlavní je zajistit vysokou přizpůsobivost projektu. Hlavní oblastí použití této metody jsou neprůmyslová zařízení (například sklady).
Následující typy činností se nejlépe hodí k automatizaci:
1. účetnictví včetně manažerského a finančního. Největší počet PPP byl vytvořen pro účetní účely. Mezi ně patří „1C: Účetnictví“, „Turbo-účetní“, „Info-účetní“, „Parus“, „ABACUS“, „Bambi+“ atd.;
2. referenční a informační služby pro ekonomické činnosti. Zastoupená těmito PPP: „GARANT“ (daně, účetnictví, audit, podnikání, bankovnictví, měnová regulace, celní kontrola); „CONSULTANT+“ (daně, účetnictví, audit, podnikání, bankovnictví, měnová regulace, celní kontrola).
3. ekonomické a finanční činnosti. Zastoupená těmito PPP:
a) „Ekonomická analýza a prognóza činnosti firmy, organizace“ (firma „INEK“), implementující funkce: ekonomická analýza aktivit firmy, podniku; sestavování obchodních plánů; studie proveditelnosti splácení úvěru; analýza a výběr možností činnosti; prognóza rozvahy, peněžních toků a hotových výrobků.
b) Víceuživatelský síťový komplex plné automatizace společnosti Galaktika Corporation (JSC New Atlant), který zahrnuje plánování, provozní řízení, účetnictví a kontrolu, analýzu, navíc umožňuje v rámci DSS poskytovat řešení pro podnikání plánování problémů pomocí PPP Project-Expert.
4. organizace práce vedoucího;
5. automatizace toku dokumentů;
6. školení.
Podniky a firmy v poslední době dávají přednost nákupu hotových balíčků a technologií a v případě potřeby k nim přidávají vlastní software, protože vývoj vlastního AIS je spojen s vysokými náklady a riziky. Zpravidla je vyvíjen a nabízen základní systém, který se přizpůsobuje dle přání jednotlivých klientů. Zároveň jsou uživatelům poskytovány konzultace, které pomáhají minimalizovat dobu implementace systémů a technologií, co nejefektivněji je využívat a zvyšovat kvalifikaci personálu.
Automatizované konstrukční systémy - druhý, rychle se rozvíjející způsob vedení projekční práce.
Mezi automatizovanými metodami návrhu zaujímají metody návrhu modelu zvláštní místo. Vytvoření a použití CAD zajišťuje dosti vysokou úroveň funkční spolehlivosti, komplexní pokrytí všech technologických procesů, snížení pracnosti konstrukčních prací s maximálním zohledněním zájmů objektu automatizace. Tato metoda je však poměrně drahá a vyžaduje vysoce kvalifikované vývojáře. Klíčovým požadavkem na CAD je schopnost vybudovat a udržovat v návrhovém systému v adekvátním stavu nějaký globální ekonomický informační model objektu automatizace. Model je zobrazením informačních komponent objektu automatizace a vztahů mezi nimi, které jsou explicitně specifikovány. Hlavním cílem stavby modelu je vytvoření projektu AIS odpovídající tomuto modelu, který zohledňuje a aktivně využívá všechny charakteristiky objektu. Takový model musí obsahovat formalizovaný popis množin informačních komponent a vztahů mezi nimi, včetně informačních spojení a algoritmické interakce. Metodou modelového návrhu je použit systematický přístup, který stanoví použití počítačů nejen ve všech fázích tvorby systému, ale také v procesu analýzy výsledků jeho průmyslového provozu. Vývoj a aplikace CAD předurčily přechod k tvorbě individuálních projektů, ovšem na mnohem vyšší úrovni oproti původní metodě návrhu.
V oblasti automatizace návrhu IS a IT se v posledním desetiletí objevil nový směr - Technologie automatizovaného vývoje softwaru CASE(CASE - Computer-Aided Software/System Engineering). Rostoucí složitost informačních systémů a zvyšující se požadavky na ně vedly k potřebě industrializace technologií pro jejich tvorbu.
Technologie CASE je soubor metod pro analýzu, návrh, vývoj a údržbu IS, podporovaný sadou vzájemně propojených automatizačních nástrojů. CASE je sada nástrojů pro systémové analytiky, vývojáře a programátory, která umožňuje automatizovat proces navrhování a vývoje IS. Systémy CASE se používají jako výkonný nástroj pro řešení výzkumných a konstrukčních problémů, jako je strukturální analýza předmětné oblasti, realizace projektů pomocí programovacích jazyků nejnovější generace, vydání projektové dokumentace, testování realizace projektu, plánování a kontrola vývoje, modelování podnikových aplikací za účelem řešení provozních problémů a strategického plánování a řízení zdrojů atd.
Hlavním cílem CASE je maximalizace automatizace vývoje a provozu systémů.
Při použití technologií CASE se mění technologie pro provádění práce ve všech fázích životního cyklu automatizovaných systémů. V systémech CASE je návrh založen na přehledných vizuálních vývojových metodách, přičemž k popisu modelu navrženého IS se používají grafy, diagramy, tabulky, diagramy a textové vysvětlivky k nim. Tyto metodiky poskytují přesný a vizuální popis navrženého systému, který začíná jeho obecným přehledem a poté se stává podrobným, přičemž získává hierarchickou strukturu s rostoucím počtem úrovní.
Automatizace programování je založena na automatickém generování programových kódů, které obsahují popisy dat, základní logiku jejich zpracování, databázová schémata, soubory popisu rozhraní atd. Kódy jsou následně zpřesňovány a finalizovány, v některých případech však automatizace dosahuje 90% . Technologie CASE navíc generuje potřebnou projektovou dokumentaci, připravenou k použití.
Při použití technologie CASE je poskytována podpora pro jednu projektovou základnu, tzn. veškeré informace o vyvíjeném AIS jsou automaticky umístěny do jediné projektové databáze. To zachovává konzistenci, konzistenci, úplnost a minimální redundanci návrhových dat.
Technologie CASE zajišťuje týmovou spolupráci vývojových týmů, protože různé skupiny specialistů mají k dispozici odpovídající nástroje a také schopnost koordinovat a správně provádět změny projektu různými specialisty v reálném čase.
Technologie CASE se úspěšně používají k budování téměř všech typů AIS. CASE se také používá k vytváření systémových modelů, které pomáhají komerčním strukturám řešit problémy strategického plánování, finančního řízení, určování firemních politik, školení personálu atd.
CASE má tyto hlavní výhody:
Zvyšovat kvalitu vytvářených informačních systémů (IT) prostřednictvím prostředků automatického řízení (především projektového řízení);
Umožňují vytvořit prototyp budoucího IS (IT) v krátkém čase, což umožňuje rychle posoudit očekávaný výsledek v raných fázích;
Urychlit proces návrhu a vývoje systému;
Osvobozují vývojáře od rutinní práce a umožňují mu plně se soustředit na kreativní část návrhu;
Podporovat rozvoj a údržbu již fungujících informačních systémů.
K dnešnímu dni se zformoval silný CASE průmysl, který sdružoval stovky firem a společností různého zaměření. Mezi ně patří:
Společnosti, které vyvíjejí analytické a návrhové nástroje pro IS a IT
Firmy, které vyvíjejí speciální nástroje se zaměřením na úzké tematické okruhy nebo na jednotlivé fáze životního cyklu IS;
Školicí společnosti, které organizují semináře a školení pro specialisty;
Poradenské firmy poskytující praktickou pomoc při využívání CASE balíčků pro vývoj konkrétních IS;
Firmy specializující se na výrobu periodických časopisů a bulletinů o technologiích CASE.
Vláda Belgorodské oblasti Automatizovaný informační systém „Řízení projektů“ AIS „Řízení projektů“ Regulační rámec Řešení bylo vytvořeno v souladu se standardy zavedenými v Ruské federaci, zakotvenými v: 1. GOST R 54869—2011 „Řízení projektů. Požadavky na projektové řízení." 2. GOST R 54870—2011 „Řízení projektů. Požadavky na správu projektového portfolia." 3. GOST R 54871—2011 „Řízení projektů. Požadavky na správu programu." Při vytváření a nastavení systému byla zohledněna ustanovení vlády regionu Belgorod ze dne 31. května 2010 N 202-pp „O schválení nařízení o řízení projektů ve výkonných orgánech a vládních orgánech regionu Belgorod“. . 2 AIS „Project Management“ Technologie vývoje Internet Síť Lokální síť Řešení bylo vyvinuto na bázi platformy Motiware Melody One. Díky webovému rozhraní systému mají všichni účastníci projektu přístup k potřebným datům kdykoli a odkudkoli na světě. Pro přístup do systému potřebujete pouze připojení k internetu a nainstalovaný prohlížeč. Serverová část 3 AIS „Projektový management“ Cíle Cíle pro vytvoření a implementaci systému: . Zvýšit efektivitu realizace projektů na území ustavující entity Ruské federace poskytováním aktuálních, úplných a spolehlivých informací projektovým týmům. . Zlepšit interakci mezi orgány státní správy a samosprávy s občany a podniky při iniciaci a realizaci projektů. . Poskytněte všem účastníkům projektu pohodlné nástroje a nástroje pro řízení projektů. . Zjednodušte monitorování postupu projektu snížením času stráveného přípravou a analýzou dat výkazů. 4 AIS „Project Management“ Funkce systému Systém umožňuje organizovat celý cyklus projektu a/nebo portfolia procesu řízení projektů. Projekt v systému prochází postupně několika fázemi – od registrace iniciativní žádosti až po přesun hotového projektu do archivu. . Zvažování iniciativních žádostí. Zahájení. Plánování. Implementace a kontrola. Dokončení 5 AIS "Projektové řízení" Práce s iniciativními aplikacemi AIS "Projektové řízení" Projekty Iniciativní aplikace Portál interakce s občany a podniky Archiv (zamítnuté žádosti) 6 AIS "Projektové řízení" Fáze zahájení projektu 2. Zahájení projektu. Automatické přidělení jedinečného registračního čísla projektu. . Vytvoření projektové karty na základě údajů uvedených v žádosti iniciativy. 7 AIS „Řízení projektu“ Fáze zahájení projektu 3. Vytvoření pasportu projektu. Možnost postupné úpravy karty (polí) pasu projektu. . Účtování rozpočtu projektu podle zdrojů financování. . Sestavení projektového týmu s uvedením rolí účastníků. . Zadávání a editace charakteristik projektu. . Vygenerování podle zavedeného formuláře a nahrání ze systému pasportu projektu ve formátu *.docx. 8 AIS „Projektové řízení“ Fáze plánování projektu 4. Vytvoření plánu řízení projektu. Prezentace plánu řízení projektu pomocí Ganttova diagramu. . Plánování prací na projektu s uvedením data zahájení a ukončení, odpovědných realizátorů a požadavků na výsledky práce. . Vytvoření hierarchického seznamu prací pro projekt. . Vygenerování podle zavedeného formuláře a stažení ze systému plánu řízení projektu ve formátu *.docx. 9 AIS „Projektové řízení“ Etapa implementace a kontroly 5. Organizace procesu provádění změn pasportu a plánu řízení projektu. Vytváření a úpravy nových verzí pasportu a/nebo plánu řízení projektu. . Vytvoření podle zavedeného vzoru a nahrání seznamu změn ze systému ve formátu *.docx. . Koordinace seznamu změn s monitorovací a kontrolní skupinou. 10 AIS „Projektové řízení“ Etapa implementace a kontroly 6. Vyúčtování realizace prací na projektu. Možnost pro umělce připojit soubory zpráv o dokončení práce. . Účtování skutečných termínů dokončení prací a odchylek od plánovaných termínů. . Sledování nadcházejících a zpožděných milníků. 11 AIS „Projektový management“ Dokončovací fáze 7. Tvorba závěrečné zprávy. Výpočet hodnocení úspěšnosti projektu. . Formace dle zavedené šablony a nahrání závěrečné zprávy ze systému ve formátu *.docx. 12 AIS „Projektový management“ Archiv projektů 8. Vedení archivu projektů. Vytvoření jednotného datového skladu o všech projektech, které byly kdy zahájeny na území zakládajícího subjektu Ruské federace. . Přístup ke kompletním informacím o dokončených a archivovaných projektech. . Ochrana proti změnám dokončených projektů. 13 AIS „Projektový management“ Reporty a analýzy Jedním z cílů systému je poskytovat účastníkům projektových aktivit reportovací informace o projektech pohodlnou a vizuální formou. AIS umožňuje automaticky generovat projektovou dokumentaci: . Projektový pas. . Plán řízení projektu. . Konečná zpráva. 14 AIS „Projektové řízení“ Informace o implementaci Více než AIS „Projektové řízení“ bylo úspěšně využíváno k realizaci projektových aktivit úřady regionu Belgorod. 4 200 projektů 5 000 uživatelů AIS „Projektový management“ 60 000 prací (kontrolní akce) 19 městských částí 3 městské části 15 Vláda regionu Belgorod Děkujeme za pozornost! 16