Lekce 2 - Etapy projektu GIS 1. Uvod..................................................................................................................................................1 1.1 Cíle lekce...................................................................................................................................1 1.2 Projekt a metodika řízení projektu.............................................................................................1 1.3 Orgány řízení projektu a pracovní týmy.....................................................................................2 2. Fáze a procesy vývoje.......................................................................................................................7 2.1 Procesy vývoje...........................................................................................................................7 2.2 Tři úrovně vývoje (implementace) GIS.......................................................................................8 2.2.1 Konceptuálni úroveň (business layer)................................................................................8 2.2.2 Logická úroveň (logical layer)..........................................................................................12 2.2.3 Fyzická úroveň (physical layer).......................................................................................12 2.3 Přehled fází vývoje - klasický přístup.....................................................................................13 2.3.1 Definition (Definice)..........................................................................................................13 2.3.2 Analysis (Analýza)...........................................................................................................13 2.3.3 Design (Návrh řešení)......................................................................................................13 2.3.4 Build (Vytvoření aplikace)................................................................................................14 2.3.5 Transition (Přechod)........................................................................................................14 2.3.6 Production (Produkce).....................................................................................................14 2.4 Přehled fází vývoje - rychlý přístup........................................................................................14 2.5 Přehled fází vývoje - „lite" přístup...........................................................................................14 1. Úvod 1.1 Cíle lekce • Prezentovat přehled metodiky pro vývoj a implementaci GIS (na základě metodik Oracle CDM a Oracle AIM) • Vysvětlit fáze a procesy vývoje (implementace) GIS • Zdůraznit rozdíly při vývoji (implementaci) běžných IS a GIS 1.2 Projekt a metodika řízení projektu Projekt v našem smyslu je časově omezené úsilí, směřující k vytvoření unikátního produktu nebo služby. Při řízení projektu je vhodné nechat se vést zkušenostmi jiných (všechny chyby, které uděláte, už s velkou pravděpodobností někdo před vámi udělal) sepsaných do metodiky. Jednou z mnoha metodik pro řízení projektů v oblasti IT je Project Management Method (PJM) firmy Oracle. Project Management ■o_____*.„„^ Control and Reporting Processes ľ ° Work Management Resource Management Quality Management Configuration Management Planning "V~ V Completion :x Figure 1-2 Processes in PJM 1 1.3 Orgány řízení projektu a pracovní týmy Organizační struktura Řídící výbor Výkonný výbor Komise pro změny Tým podpory Tým akceptace Tým kvality Analytici a návrháři Programátoři Tým pro systémovou integraci Tým migrace Legenda: Tým Objednatele Smišený tým Tým Zhotovitele Řídící výbor Řídící výbor (RV) především zajišťuje: • vytváření podmínek pro úspěšnou realizaci projektu • kontrolu a sledování průběhu projektu • vyjadřování svého stanoviska k akceptaci výsledků jednotlivých etap projektu na základě výsledku akceptačního řízení • doporučování změn smlouvy, nových dílčích smluv a jejich změn k podpisu statutárními orgány smluvních stran • navržení uvedení informačního systému do provozu. ŘV je vrcholným rozhodovacím orgánem projektu. Obě strany se zavazují vybavit členy ŘV potřebnými kompetencemi rozhodovat v zásadních otázkách projektu a toto rozhodnutí prosadit v rámci příslušné strany. Řádná zasedání ŘVse konají pravidelně, zpravidla jednou měsíčně nebo čtvrtletně podle rozsahu a stavu projektu. Předseda ŘV (Gestor projektu Objednatele) má v případě potřeby nebo na žádost kteréhokoli člena ŘV možnost svolat i mimořádné zasedání ŘV. Podklady projednání ŘV předává předsedovi a všem členům výboru vedoucí projektu na straně Zhotovitele v písemné podobě nejpozději tři dny před zasedáním, pokud ŘV nerozhodne jinak na předcházejícím zasedání nebo pokud ŘV nenastaví jiný způsob předávání podkladů pro celou dobu trvání projektu. Další podklady pro jednání ŘV si může předseda ŘV vyžádat od Týmu kvality (TK), Týmu akceptace (TA) nebo Komise pro změny (KZ). ŘV přijímá rozhodnutí konsensem. Nejčastější problémy v práci ŘV: • formální účast řídících pracovníků Zhotovitele a zejména Objednatele • vyhýbání se řešení problémů • nedostatek času klíčových členů ŘV, ŘV se neschází, když je potřeba Komise pro změny Komise pro změny především zajišťuje: • posuzování požadovaných změn rozsahu projektu • posuzování změn v rámci rozsahu jednotlivých etap 2 • podávání doporučení RV k provedení navrhovaných změn Zasedání KZ se konají jen v případě potřeby - pokud jsou požadovány změny projektu. Nejčastější problémy v práci KZ: • formální nebo nekompetentní řešení požadavků na změny • nedosažení shody na realizaci změn a tím přílišné zatížení ŘV Výkonný výbor Výkonný výbor (VV) především zajišťuje: • koordinaci součinnosti smluvních stran navzájem a koordinaci s konzultanty • koordinaci činnosti týmů • podrobnou kontrolu průběhu projektu a operativní řešení problémů, které nevyžadují rozhodnutí ŘV • podrobnou specifikaci jednotlivých etap řešení projektu a navrhování z toho vyplývajících upřesnění ve formě dílčích smluv • organizační zajištění aktivit Uchazeče na místech plnění • koordinaci spolupráce s TK, TA a jednotlivými pracovními týmy • schválení detailního průběhu akceptačního řízení • rozhodování o vytvoření smíšených pracovních týmů Členy VVjsou vedoucí projektu na straně Zhotovitele (VPZ), vedoucí projektu na straně Objednatele (VPO) a s hlasem poradním i vedoucí všech týmů, které jsou v daném čase zřízeny. Rozhodnutí VVjsou realizována prostřednictvím VPZ nebo VPO v rozsahu jejich pravomocí. Řízení projektu mezi jednotlivými jednáními Řídícího výboru Řízením projektu mezi jednotlivými jednáními ŘVjsou pověřeni VPO a VPZ. Nejčastější problémy v práci VV: • VPZ nebo VPO jsou vedoucími typu „úředník" • VPZ nebo VPO jsou vedoucími typu „zanícený řešitel" • Trvalé neshody a konflikty VPZ a VPO • Zadržování informací směrem k ŘV Zápisy jednání orgánů projektu Zjednání orgánů řízení projektu budou pořízeny písemné zápisy zachycující projednané skutečnosti a podepsané VPO a VPZ. Pracovní týmy zřizované Objednatelem Zadavatel zřizuje tyto týmy: • tým akceptace • podle potřeb další pracovní týmy pro plnění úkolů jednotlivých etap projektu, tvořené výhradně zaměstnanci Objednatele 3 Vedoucí projektu Objednatele Vedoucí týmu akceptace Systémový Datový Administrátor Klíčový integrátor specialista systému uživatel Struktura týmu Objednatele Pracovní týmy zřizované Zhotovitelem V rámci jednotlivých etap řešení projektu k plnění svých závazků zřizuje Uchazeč další pracovní týmy, tvořené výhradně pracovníky Zhotovitele: • Programátoři • Teste ři Vedoucí projektu Zhotovitele Hlavní programátor Hlavní tester Programátor Programátor Programátor databáze aplikační vrstvy klienta Tester Struktura týmu Zhotovitele 4 Smíšené pracovní týmy Pro řešení projektu jsou definovány smíšené pracovní týmy, a to: Tým kvality Analytici a návrháři Tým pro systémovou integraci Tým podpory řešení Tým migrace podle potřeb další smíšené pracovní týmy pro plnění úkolů jednotlivých etap projektu (tým tým Infrastruktura apod.) 5 Vedoucí projektu Zhotovitele Hlavní systémový integrátor Systémový Systémový Hlavní Hlavní Specalista Analytik Datový Specialista Datový analytik analytik analytik programátor pro verejnou geodatabází architekt GIS specialista a integrátor a integrátor správu Vedoucí týmu migrace i ^^ i Auditor kvality Auditor kvality T "T" "T" "T" T H lavn í analytik T "T Vedoucí podpory 1 i Specalista Datový architekt Procesní analytik Analytik geodatabází Specialista GIS Hlavní uživatel Administrátor Datový svstému specialista Pracovník Hlavní Administrátor HelpDesk uživatel systému Vedoucí týmu Pracovník Zhotovitele Pracovník I Objednatele Struktura smíšených týmů Řízení týmů Smíšené pracovní týmy (s výjimkou týmu kvality) a týmy zřizované Zhotovitelem jsou řízeny VPZ. Tým kvality a týmy zřizované Objednatele jsou řízeny VPO. Tým akceptace Tým akceptace zajišťuje: • přípravu posouzení a převzetí výstupů jednotlivých etap a přípravu podkladů pro rozhodnutí o akceptaci těchto výsledků • přípravu a provedení akceptačních testů, včetně převzetí testovacího prostředí a schválení výběru testovacích prostředků • posouzení výsledků provozních a implementačních testů • spolupráci s řešiteli (pracovníky Zhotovitele) v oblasti akceptace Tým akceptace je tvořen výhradně pracovníky Objednatele. Tým je řízen vedoucím projektu Objednatele. Dále je tvořen systémovým integrátorem, klíčovými uživateli, datovým specialistou a administrátorem systému. 5 Tým kvality Tým kvality zajišťuje: • provádění auditu jakosti řešení projektu • hodnocení návrhu dílčích smluv z hlediska zajištění možnosti vyhodnocení kvality • hodnocení jednotlivých etap realizace projektu z hlediska dodržování stanoveného systému kvality • přípravu modelu a pravidel systému jakosti pro období provozu informačního systému Tým kvality je tvořen auditorem kvality Objednatele a auditorem kvality Zhotovitele. Tým kvality je řízen vedoucím tým kvality. Analytici a návrháři Analytický tým zajišťuje: • návrh technické a aplikační architektury systému • analýzu funkčních i nefunkčních požadavků Objednatele, návrh procesního modelu celého řešení • analýzu vstupních dat pro migraci do systému • návrh migrace a cílového uložení dat • sledování platné legislativy a návrh změn systému vyplývajících ze změn v legislativě Tým analytiků a návrhářů je řízen hlavním analytikem a je tvořen analytikem geodatabází, procesním analytikem, datovým architektem, specialistou pro analýzu legislativy, specialistou pro veřejnou správu, specialistou GIS a návrhářem technické a aplikační architektury. Tým je dále složen z pracovníků Objednatele - administrátorem původního systému, datovým specialistou a klíčovými uživateli systému. Tým pro systémovou integraci Tým pro systémovou integraci zajišťuje návrh a realizaci integrace GIS do SW prostředí Objednatele. Tým pro systémovou integraci je tvořen hlavním systémovým integrátorem, systémovým analytikem a architektem, hlavním analytikem systému, hlavním programátorem a specialistou pro veřejnou správu. Dále je tým doplněn systémovým analytikem a integrátorem Objednatele. Programátoři Tým programátorů zajišťuje realizaci vlastního řešení podle schválených návrhů Tým programátorů je řízen hlavním programátorem a je dále tvořen programátory klientských aplikací, programátory aplikačního serveru a programátory databáze. Teste ři Tým testerů zajišťuje • pilotní testování projektu (včetně vytvoření závěrečných zpráv projektu) • přípravu projektu pro akceptační testování Tým testerů je složen z hlavního testera a testerů systému. Tým migrace Tým migrace zajišťuje: • Migraci dat ze stávajících systémů Tým migrace je složen z analytika prostorových databází, datového architekta, datového specialisty a specialisty GIS. Tým je řízen vedoucím týmu migrace. Tým podpory řešení 6 Tým podpory řešení zajišťuje: • službu HelpDesk • odstraňování a identifikaci vad • zaškolení uživatelů • technickou a provozní dokumentaci řešení • instalaci a implementaci nových verzí systému Tým pro podporu řešení je tvořen především školitelem, pracovníkem HelpDesk, hlavním uživatelem Objednatele a administrátorem systému Objednatele. Podle aktuálních požadavků a potřeb může být tým rozšířen o členy ostatních týmů. Tým je veden vedoucím podpory řešení. 2. Fáze a procesy vývoje 2.1 Procesy vývoje • Business Requirements Definition - definice požadavků V tomto procesu jsou definovány business požadavky kladené na aplikaci. Je vytvořen procesní model, konceptuálni datový model a konceptuálni funkční model. Dále jsou popsány nefunkční požadavky (uživatelský interface, požadované odezvy systému, ...). V rámci tohoto procesu je vytvořen první návrh pilotního území a připravena kriteria pro akceptaci projektu. • Existing Systems Examination - analýza stávajících systémů Analýza stávajícího systému (stávajících systémů), pokud Objednatel chce novým systémem pokrýt funkcionalitu stávajícího systému (stávajících systémů). • Technical Architecture - definice technické infrastruktury Určení technické infrastruktury navrhovaného systému -technických a technologických prvků systému. Podrobnost a obsah návrhu se liší podle fáze projektu, ve které je technická architektura vytvářena. Technická architektura by měla vycházet ze širší informační strategie, kterou by Objednatel měl mít vytvořenu. • Database Design and Build - návrh a vytvoření databáze Proces vytvoření logického datového modelu, fyzického datového modelu a implementace databáze v DDL. • Module Design and Build - návrh a vytvoření modulů Z procesního modelu, konceptuálního datového modelu a konceptuálního funkčního modelu je vytvořen logický model modulů, které podporují navržené funkce. Dále probíhá implementace modulů ve zvoleném technologickém prostředí. • Data Conversion - migrace a konverze dat Migrace, konverze a testování migrovaných dat potřebných pro testování a provoz vyvíjeného systému. Migrace dat může být podporována automatickými prostředky nebo realizována manuálně. • Documentation - dokumentace Vytváření dokumentace ve všech fázích a všech výstupů systému. • Testing-testování Vytváření testovacích scénářů, testovacích návodů a skriptů. Testování modulů, testování business funkcí, integrační testování. • Training-školení Příprava školení a vlastní školení školitelů a uživatelů vyvíjeného systému. Školení administrace a podpory systému. • Transition - přechod Proces, který od začátku projektu připravuje přechod na nový systém. Připravuje se instalační plán, scénář přechodu na nový systém, plán implementace HW a SW prostředků pro testovacím a produktivní provoz. 7 • Post-System Support - poinstalační podpora, podpora produkce Monitorování a řešení provozních problémů pomocí help-desku, příprava upgrade aplikace s opravenými chybami. Vyhodnocování provozu systému, plánování přírůstků a dalšího rozvoje systému. 2.2 Tři úrovně vývoje (implementace) GIS 2.2.1 Konceptuálni úroveň (business layer) Business modely: • Kontextový procesní model - identifikace klíčových procesů, které hrají roli v businessu (ve WOI), identifikace primárních business jednotek, hlavních procesních toků. Identifikace hlavních rozhraní na okolí a okolní systémy. • Konceptuálni (business) procesní model - dokumentace business procesů a událostí. Model každého procesu se skládá z procesních kroků, procesních toků, rozhodovacích bodů, organizačních jednotek, z událostí, které spouštějí procesní kroky, ze vstupů a z výstupů. Procesní krok nejnižší úrovně je elementární (business) funkce. Business proces model dokumentuje, co se má udělat nezávisle na tom, jak se to má udělat. Klíčovým pro úspěšné vytvoření business procesního modelu je angažovanost uživatelů při vytváření modelu. • Konceptuálni (business) funkční model - vytvoření hierarchie business funkcí alespoň do úrovně elementárních funkcí. Doplnění neprocesních funkcí (podpůrné funkce, jednorázové funkce, ...). Popis požadované funkcionality (pseudokódem). • Konceptuálni (business) datový model - dokumentace požadavků na business data. Definice a popis entit a vztahů mezi nimi. Definice základních atributů entit a jejich popis. • Vztah dat a funkcí - mapování business funkcí na entity, případně entity a jejich atributy formou matice. Příklad: GIS správce kanalizační sítě Cílem je navrhnout systém, který zajistí požadavky uživatele - správce velké kanalizační sítě: převést stávající dokumentaci kanalizační sítě vedenou na papírových mapách a dalších papírových podkladech na počítačové vedení dokumentace provádět aktualizaci evidovaných dat (zdrojem změn jsou revize sítě s doměřením polohy prvků a dokumentace skutečného provedení stavby) poskytovat mapové podklady i další sestavy pro vyjadřování o kapacitě kanalizace v rámci stavebního řízení umožnit výstupy ze systému, které budou sloužit jako podklady pro výpočty kapacit kanalizační sítě v topologickém modelu síťového grafu, a umět převzít výsledky výpočtů připravovat provozní podklady pro revizi a údržbu kanalizační sítě ve formě map s vyznačenými prvky (kanalizační šachty a stoky), které mají být revidovány K dispozici je rozsáhlá dokumentace kanalizační sítě na mapových listech měřítka 1:500 a 1:1000, kterých je celkem asi 2000. V dokumentaci jsou zakresleny úseky stok, šachty, přípojky (resp. vložky, tj. připravené odbočky ve stokách, do kterých se mohou zaústit přípojky) a další objekty kanalizační sítě. Odhadované počty objektů: 200 000 šachet, 200 000 úseků stok, 6 000 000 vložek, 50 000 dalších objektů. Správa dat je centralizována, aktualizace dat by měla probíhat na jednom pracovišti v rámci LAN. Je požadován vzdálený pasivní přístup k datům (jak pro veřejnost za úplatu, tak pro organizační jednotky správce sítě, které jsou vzdáleny od pracoviště aktualizace dat). 8 Ukázka papírové dokumentace « lť» \no tó- mS: mm ?*?,«■ tS3,3g 232JL <3Q9 099 M^ Kontextový procesní model analysis Business Process Model ■ kolaudace stavby doměření povrchových znaků I -T- / požadavek n výpočet GIS správce kanalizační sítě ^ fr kíualizace dat o kanalizač / síti úložiště IS KS úložiště aplikace pro výpočty komunikace s externím ýpočtovým programem poskytnutí podkladů k vyjádření o síti X loskytnutí podkladů pro údržbu T l l požadavek na vyjádření ke kapacitě sítě požadavek na opravu nebo údržbu sítě 9 Konceptuálni funkční model - diagram funkční hierarchie act Diagram funkční hierarchie aktualizace dat zpracovaní podkladu ŕ - N zahájeni změnového ponzeni zmeň IS správce kanalizace připrav a podkladů k vyjádřeni o šiti příprava podkladu pro údržbu šitě definice šablony pro výběr provedeni exportu import dat do pracov niho prostředí provedeni změn v aktuálních datech 10 Konceptuálni datový model class Konceptulání datový model / zařízení kanalizační sítě zařízení kanalizační sítě:: úsek stoky zařízení kanalizační sítě:: vložka n.v. vtoku: int n.v. výtoku: int staničení: int typ obsazení: char poloha: geometrie bodu 0..11..* materiál: int profil: int akce údržby o..* o..* průřez: int datum zahájení: char datum ukončení: char pracovní četa: int H a 1 1..* 1 1..* 1 zařízení kanalizační sítě:: šachta zařízení kanalizační sítě:: stavební objekt na síti typ poklopu: int n.v. dna: int n.v. poklopu: int poloha: geometrie bodu typ objektu: int prvek podkladové mapy - typ prvku: int prvek podkladové mapy:: bodový prvek podkladu prvek podkladové mapy:: liniový prvek podkladu poloha: geometrie bodu průběh: geometrie linie prvek podkladové mapy::textový prvek podkladu text: char poloha textu: geometrie textu 11 2.2.2 Logická úroveň (logical layer) Systémové modely: • Systémový procesní model - specifikace způsobu, jakým budou procesy vykonávány. Specifikace typu procesu (interakce s uživatelem, dávkový proces, report, apod.) • Systémový funkční model - specifikace všech funkcí, které budou podporovány aplikačním systémem. Elementární business funkce jsou mapovány na entity a atributy. Funkce jsou detailně popsány pseudokódem. • Systémový datový model - specifikace všech dat, která budou podporována aplikačním systémem. Entity obsahují všechny atributy, jejich formát a popis. Jsou určeny odvozené a denormalizované atributy, interface a řídící entity. • Vztah entit s funkcí - mapování business funkcí na entity a jejich atributy formou matice. Specifikace způsobu užití atributů entit funkcemi (create, delete, update, select). Specifikace modulů: • Procesní model modulů - specifikace způsobu, jakým moduly podporují business procesy • Definice modulů - mapování elementárních business funkcí do primárních modulů, specifikace užití sloupců a tabulek moduly. Specifikace funkčnosti (logiky) modulů, rozvržení (layout) modulů, implementace standardů GUI. Logický datový model: • Definice databáze - návrh tabulek a sloupců, primárních a cizích klíčů, návrh sekvencí a indexů. Návrh validačních pravidel, návrh řešení super/sub typů entit a vytvoření odvozených a denormalizovaných sloupců. 2.2.3 Fyzická úroveň (physical layer) Aplikace: • Vytvoření nebo implementace nebo generování modulů - vytvoření (naprogramování) modulů, implementace hotových modulů, generování modulů z CASE. Fyzický datový model: • Vytvoření nebo generování databáze - vytvoření nebo generování (z CASE) DDL příkazů a jejich spuštění a vytvoření databáze. Verifikace: • Testování modulů - testování každého modulu podle scénářů vytvořených na základě požadavků na funkcionalitu elementárních business funkcí, požadavků na validaci, na ošetřování chyb, na standardy GUI, na layout modulu a na help. • Integrační testování modulů - testování vzájemného zapojení a integrace modulů v rámci funkční oblasti, která reaguje na jednu business událost. • Systémové testování - testování celého systému s důrazem na integraci všech procesů, žurnálování, bezpečnost, dokumentaci, stav manuálně pořízených a konvertovaných dat, zálohování a archivaci. • Integrační systémové testování - testování vazeb a integrace se sousedními aplikačními systémy • Akceptační testování - testování celého systému vzhledem k uživatelem stanoveným akceptačním kritériím. 12 2.3 Přehled fází vývoje - klasický přístup Classic Phases Business Requirements Definition Existing Systems Examination Technical Architecture Database Design and Build Module Design and Build Data Conversion Documentation Testing Training Transition Post-System Support Definition z^r Analysis TV hi EH 0- Design ^~ {> O Build ^VCIZľvC o- Transition Production V____A____A____A____A____A. Figure 1-3 The CDM Classic Approach Diagram 2.3.1 Definition (Definice) Vtéto fázi se plánuje celý implementační projekt. Definují se základní procesy a strategie, provede se sběr a analýza potenciálních změn produktu. Vytvoří se procesní Model nejvyšší úrovně. Definuje se strategie implementace. Definují se požadavky a strategie pro aplikační a technickou architekturu. Definují se požadavky a strategie pro konverzi dat a tvorbu dokumentace, navrhují se standardy a procedury pro dokumentaci systému, připravuje se glosář projektu. Definuje se strategie a požadavky pro funkční testování systému, strategie pro výkonnostní testy a navrhuje se strategie pro osvojení a vyškolení uživatelů. 2.3.2 Analysis (Analýza) Vtéto fázi jsou vytvořeny scénáře business požadavků na základě výstupů předchozí fáze. Je navrženo zavedení nových business operací do aplikační a technické architektury. Je navržena definice aplikační a technické architektury systému. Technická architektura na nejvyšší úrovni zahrnuje návrh platformy, software a komunikačních komponent nového systému. 2.3.3 Design (Návrh řešení) V této fázi se provádí dokumentace Business procedur, definuje se aplikační setup, bezpečnostní aplikační architektura, standardy designu a buildu. Vytváří se návrh aplikací - návrh funkcí, návrh databáze a technický návrh. Definují se standardy pro konverzi dat, připravuje se prostředí pro konverzi a mapují se data pro konverzi na datové struktury vyvíjené aplikace. Definují se manuální konverzní procedury a konverzní programy, připravuje se plán testů konverze. Vytvářejí se testovací skripty pro testování modulů, jejich komunikaci, pro systémové a integrační testy. Je vytvořen návrh výkonnostních testů. Provádí se analýza potřeb pro školení uživatelů a tvoří se plán uživatelských školení. 13 2.3.4 Build (Vytvoření aplikace) V této fázi se vytváří kód a testují se parametrizace a rozšíření systému, včetně aplikačních zlepšení, konverzí a interfaces. Vytvářejí se a provádějí funkční, výkonnostní a integrační testy systému, definuje se aplikační a databázová architektura, definuje se platforma řešení a síťové architektury. Po přípravě vývojového prostředí je možno zahájit práce na vytvoření databáze a vývoji aplikačních modulů. Pokračuje vývoj konverzních programů a provádí se testy konverzních nástrojů. V této fázi se vytváří dokumentace - Instalační příručky, Uživatelské příručky a Systémové příručky. Po přípravě testovacího prostředí se provádí testy modulů a systémové, instalační a integračních testy. Provádí se příprava klíčových uživatelů pro testování. Provádí se výkonnostních testy systému. Pro účely budoucího školení se vytvářejí školicích materiály a prostředí pro školení uživatelů. Je vytvořen návrh infrastruktury pro support produkční fáze a plánu přechodu a náhradních řešení. 2.3.5 Transition (Přechod) V této fázi na nový systém zahrnuje instalaci konverzních programů, konverzi a verifikaci dat, funkční testování, výkonnostní testy, zaškolení školitelů zákazníka, produkční migraci, přípravu produkčního prostředí, setup aplikací a jejich implementaci. Fáze končí zahájením produkce systému. 2.3.6 Production (Produkce) Tato fáze je poslední fází implementace a je současně začátkem supportu systému. Tato konečná fáze obsahuje činnosti zaměřené na měření výkonnosti a jemné ladění systému, provádí se masivní podpora uživatelů systému. Připravuje se návrh budoucích business a technických záměrů pro případný další rozvoj systému. 2.4 Přehled fází vývoje - rychlý přístup Sloučením a zjednodušením fází definice a analýzy, návrhu a vytvoření aplikace a přechodu a produkce je možné realizovat „rychlý přístup" při vývoji aplikace. Fast Track Phases Business Requirements Definition Existing Systems Examination Technical Architecture Module Design and Build Database Design and Build Data Conversion Documentation Testing Training Transition Post-System Support Requirements System Design am Transition Modeling ZJ--U Ľh-C Er-LZ ZJ- -LZ ZJ--0 D IZZH LH Generation -A_ Production 1-HZI r—D 1-HZI r-TZZI _A_ Figure 1-4 CDM Fast Track Approach 2.5 Přehled fází vývoje - „lite" přístup Ještě rychlejší - „lite" - přístup vznikne při řešení založeném na prototypování. Uživateli se předkládají prototypy řešení, nad nimi probíhá analýza požadavků a zpřesňování řešení do dalších prototypů. Výsledná aplikace je ve fázi přechodu a produkce implantována do produktivního provozu. 14 Lite ^ Phases r Prototype and Build ^\ Transition to ' Production ss Requirements Definition 1 Technical Architecture 1 n Database Design and Build 1 1 Module Design and Build 1 1 ^ Documentation ľ 1 Testing Training Transition 1 1 1 h h h -n \ i Post-System Support i i i j Figure 1-5 CDM Lite Approach Připomínky a dotazy k obsahu lekce posílej, prosím, na adresu: Rudolf Richter, richter@fi.muni.cz 15