Životní cykly.  Životní cyklus produktu (IS / IT služby)  Životní cyklus projektu  Životní cyklus řízení projektu  Vývoje produktu  Implementace.

Prezentace na téma: "Životní cykly.  Životní cyklus produktu (IS / IT služby)  Životní cyklus projektu  Životní cyklus řízení projektu  Vývoje produktu  Implementace."— Transkript prezentace:

1 Životní cykly

2  Životní cyklus produktu (IS / IT služby)  Životní cyklus projektu  Životní cyklus řízení projektu  Vývoje produktu  Implementace produktu

3 1. Identifikace problému – potřeba nového systému/služby obyčejně zadává business 2. Vývoj/pořízení systému/služby  Vývoj systémů je proces tvorby (návrhu, vytváření a udržování) systému, který pomáhá organizaci dosáhnout jejích strategických cílů tím, že podporuje klíčové business procesy  Vývoj systémů/služeb je oblast lidské činnosti, která má svoji vlastní metodologie, terminologii, školy, historii a budoucnost. 3. Předání systému do produktivního provozu 4. Provozování a údržba systému 5. Stárnutí systému 6. Ukončení provozu systému

4  Často se zaměňuje  Životní cyklus projektu - je společný pro všechny projekty  Zahájení projektu  Organizování a příprava projektu  Realizace projektu  Ukončení projektu  Životní cyklus řízení projektu - je specifický pro každý projekt, je ovlivněn cíli projektu, je přizpůsoben specifickým vlastnostem projektu:  Příklad: Stavba domu  Příklad: Vývoj systému na míru  Příklad: Implementace standardního aplikačního softwaru  Pozn. Životní cyklus řízení projektu je specifický jen do určité míry– možné společné znaky pro určité společné typy projektů

5 PotřebaVývoj/pořízení systému/služby Produktivní provoz Ukončení provozu ZahájeníPlánování Organizování RealizaceUkončení Životní cyklus produktu/služby Životní cyklus projektu Životní cyklus řízení projektu ProblémSpecifikaceNávrhImplemen- tace TestováníProvoz a údržba

6

7 Projekt s jednou fází Př.: big bang implementace Projekt se třemi sekvenčními fázemi Př.Fázová implementace modulů Projekt s překrývajícími se fázemi Př. Reengineering procesů a implementace

8 Druhy životního cyklu řízení projektů Kategorie projektů  SEQ Sequential (end to end)  WF Waterfall (overlapping phases, stair-step fashion)  PAR Parallel phases  CYC Cyclical model  SPIR Spiral model  INCR Incremental model  ITER Iterative model  ADAP Adaptive model  GATE Stage-Gate type model  CFIX Code and Fix model  Aerospace/Defense Projects  Business & Organization Change Projects  Communication Systems Projects  Event Projects (olympijské hry)  Facilities Projects (uzavření atomové elektrárny, demolice domu, likvidace chemického odpadu,..  Information Systems (Software) Projects  Media & Entertainment Projects (nový seriál)  Product and Service Development Projects  Research and Development Projects ?

9  Klasické  Vodopádový model  Prototypové  Spirálový model  RUP  Agilní  Extreme programming  SCRUM

10  Navazují na tvrdé systémové metodologie (známe cíl a můžeme nadefinovat kroky vedoucí ke splnění)  Sekvenčně řazené fáze bez iterací  Mezi jednotlivými fázemi je schvalovací proces, přes který musí všechny dokumenty projít, aby vývoj mohl pokročit do další fáze  Účast zadavatele jen na začátku a konci

11  Nejstarší model životního cyklu software  Winston W. Royce - článek „Managing the Development of Large Software System“, 1970  Cíl: lépe se vyrovnat s rostoucí složitostí produktů v leteckém průmyslu  Sekvenční přístup k jednotlivým fázím  Podmínkou vstupu do další fáze je kompletní ukončení předešlé

12

13  Výhody ???  Snadný a pochopitelný  Význam mají úvodní fáze projektu  Omezení chyb a oprav v pozdějších fázích projektu (drahé)  Validace a kompletace každé fáze  Nevýhody???  Není pružný na změny  Požadavky zadavatelů se vždy mění  Malá účast zadavatelů  Při vývoji SW se již téměř nevyužívá  Zákazník nese veškeré náklady

14  U velkého množství projektů se nedaří na počátku stanovit cíle – specifikace produktu  Potřeba pružnější reakce na požadavky zadavatele  Zapojení uživatele do vývoje  Prototyp:  nástroj pro představení vybraných částí připravovaného systému klientovi  zákazník si vytvoří představu, jak bude systém v klíčových částech vypadat a pracovat  existuje veliký prostor pro upřesnění projektu/aplikace ještě před vlastním programováním celé aplikace

15  Barry Boehm: článek A Spiral Model of Software Development and Enhancement, 1986  Vychází z vodopádového, ale doplňuje:  Iterace  Podrobnou analýzu rizik  ve své době přelom v chápání životního cyklu  „risk driven approach“:  postup do další fáze závisí na důsledně provedené analýze všech rizik a možných problémů  rizika lze v kontextu spirálového modelu chápat v nejobecnějším smyslu (mohou tak zahrnovat např. i vztah k legislativě či marketingu)  Hlavní etapy: A.Určení cílů, alternativ, omezení (Determine objectives, alternatives, constraints) B.Vyhodnocení alternativ, identifikace a řešení rizik (Evaluate alternatives, identify, resolve risks) C.Vývoj a verifikace další úrovně produktu (Develop, verify next-level product) D.Plánování následujících fází (Plan next phases)

16 DDDDDD DADDAD DBDDBD DCDDCD

17  Výhody:  Nezávislost na metodice  Pružnější – zlepšování prototypu  Lépe reaguje na pozdější požadavky  Větší účast zadavatele  Pravidelné testování – včasnější odhalení chyb  Nevýhody:  Opakované testování – různé sady testů  Vhodný pro vývoj produktů, které se budou opakovaně prodávat  Vývojář nese část nákladů  Není podrobné rozpracování náplně etap

18  Autor: společnost Rational Software Corporation (později IBM)  Rozsáhlá a detailně propracovaná metodika vývoje software  Objektově orientovaný iterativní přístup k životnímu cyklu software  Přístup řízený případy použití (use-case driven approach):  případ použití - posloupnost akcí prováděných systémem či uvnitř systému, která poskytuje určitou hodnotu uživateli systému  Pro modelování procesů se využívá prostředků jazyka UML (Unifed Modeling Language)

19  Vývoj probíhá v iterativních cyklech:  První cyklus se nazývá úvodní vývojový cyklus a jeho výsledkem je funkční softwarový produkt implementující nejpodstatnější část funkcionality  Vývoj pokračuje v různém množství rozvíjejících cyklů, počet závisí na rozsahu projektu  Každý cyklus se skládá ze 4 fází (v závorce typické rozdělení doby pro jednotlivé fáze úvodního vývojového cyklu):  1. Zahájení (10%)  2. Projektování (30%)  3. Realizace (50%)  4. Předání (10%)

20 Fáze RUP S iteracemi: Procesy mající vliv na vývoj SW

21  Výhody:  Univerzálnost, přizpůsobení různým projektům  Detailní propracovanost kroků  Objektový přístup  Nevýhody (vyplývají z výhod):  Vhodný pro větší týmy  Složitá navigace v metodice  Potřeba zkušenosti vedoucího  Komplexnost a univerzálnost – ne všechny kroky je potřeba realizovat

22  Rozvoj IT – všechny oblasti našeho života  Důraz na nízkou cenu a rychlost dodávky  Cílem fungující aplikace, která přinese zisk  Postupné vylepšování

23  Klasické:  Fixní funkcionalita – pevná specifikace na začátku, která se musí dodržet, jinak překročení času, zdrojů  Agilní:  Fixní čas a zdroje – funkcionalita proměnná /zákazník dostane včas a za stanovenou cenu produkt, který nemusí úplně plnit všechny jeho požadavky, ale je možné je snadno doplnit

24  Iterativní a inkrementální vývoj s krátkými iteracemi  Vývoj probíhá v krátkých fázích, takže celková funkcionalita je dodávána po částech  Zákazník tak má možnost průběžně sledovat vývoj, může se k němu vyjádřit a oponovat změny  Na konci má jistotu, že nedostane něco, co neočekával.  Komunikace mezi zákazníkem a vývojovým týmem  V ideálním případě je zákazník přímo součástí vývojového týmu, má možnost okamžitě vidět průběžné výsledky a reagovat na ně  Účastní se sestavování návrhu, spolurozhoduje o testech a poskytuje zpětnou vazbu pro vývojáře.  Průběžné automatizované testování  Díky krátkým iteracím se aplikace mění velice rychle, proto je nutné pro zajištění co nejvyšší kvality ověřovat její funkčnost průběžně.  Testy by měly být automatizované, předem sestavené a měly by být napsány ještě před samotnou implementací testované části  Při každé změně musí být aplikována kompletní sada testů, aby nebyla porušena integrace jednotlivých částí.

25  Kent Beck jako vedoucí projektu u Chryslera (aplikace výpočtu kompenzací ve mzdovém systému)  Časté výstupy „releases“ v krátkých cyklech vývoje  Programování ve dvojici (programming in pairs), lepší kontrola

26

27  Výhody:  Vyšší kvality výsledného SW produktu  Pružnější reakce na požadavky zadavatele (checkpoints)  Zlepšení produktivity programování  Nevýhoda:  Nestabilní požadavky (mnoho změn)  Slabá dokumentace kompromisů a konfliktů se zadavatelem  Absence celkové specifikace návrhu, koncepce řešení

28  Ken Schwaber a Mike Beedle, 2002  SCRUM =„mlýn“ týmová strategie jak dostat míč do hry  Není metodika, ale je o komunikaci a spolupráci v týmu  iterativní  flexibilní  rychlé dodávky částí aplikace nebo prototypů a následné sbírání zpětné vazby od zákazníka  rychlá reakce na měnící se požadavky a změny během vývoje

29  Sprint  první typ iterace:trvání asi jeden měsíc, počet se podle projektu různí (3 – 8)  Na začátku každého sprintu je plánovací schůzka, kde se třídí požadavky a vybírá se množina, která se bude implementovat  Na konci schůzka celého týmu, kde se probere, co všechno se na projektu za tento sprint událo, jaké požadavky se povedlo splnit, jaké ne, a na jaké nové požadavky k zapracování se během vývoje přišlo

30  Scrum  druhý typ iterace, který je o mnoho kratší, trvá jeden den  na začátku každého pracovního dne je uspořádána schůzka, tzv. Scrum Meeting  tým je dobře informován, v jakém stádiu jsou jednotlivé práce na projektu, ale také je schopen případné problémy operativně řešit, protože na ně přijde brzy

31  Backlog – dva druhy:  Product Backlog  obsahuje seznam veškeré funkcionality požadované od výsledné aplikace  vlastník produktu tento seznam uspořádá podle priorit a logických souvislostí  tým pak z něj vybere část, kterou přesune do Sprint Backlogů.  Sprint Backlog  Seznam funkcionality pro sprint  Evidence backlogů  pomocí tzv. uživatelských scénářů známých z Extrémního programování.  Často se používá seznam udržovaný jako tabulka v nějakém editoru podobnému Microsoft Excelu.

32

33

34 SCRUM SPRINT

35  Cílem není vytvořit nový produkt, ale customizovat hotový produkt do prostředí zákazníka  Důsledky:  Omezení iterací  Hlavní slovo Zákazník  Omezené datové analýzy, programování  Důraz na předprojektové fáze a kontraktační jednání  Z pohledu jednoho projektu (implementace) -kaskádový model  Z pohledu celého životního cyklu produktu - postupné zlepšování – prototypový model

36  Možné chápat jako program:  Předimplementační projekt  Nbídkové-poptávkové řízení (Výběr systému, dodavatele, modelu a uzavření smlouvy)  Implementační projekt  Projekt údržby (ne úplně jasný konec)

37  Prvky agilních metodik  Silná účast Zákazníka  Iterace  Rizika

38 1. Definování potřeb řízení 2. Definování modelu řízení 3. Definování datové/informační základny 4. Modelování a optimalizace podnikových procesů 5. Výběr modelu poskytování služby 6. Výběr produktu, poskytovatele a uzavření smlouvy

39  Rozhodnutí o míře centralizace a decentralizace rozhodovacích pravomocí.  Rozhodnutí o způsobu dekompozice společnosti pro potřeby optimalizace jejího řízení:  Funkční dekompozice  Procesní dekompozice  Rozhodnutí o způsobu zvýšení hospodárnosti společnosti: připadají v úvahu  zaměření na úspornost (snižování nákladů)  zaměření na výtěžnost (maximalizace objemu výkonů),  Rozhodnutí o časových intervalech řízení  Rozhodnutí o organizační struktuře

40  Všechny funkce SŘ se integrují v účetním zobrazení podnikatelského procesu (zajišťuje průkaznost, úplnost a správnost)  Účetní systém se ale nesmí chápat jako systém plnící požadavky externích zájmových entit (stakeholders)  Účetní systém – informační systém účelově orientovaný na předem rozpoznané a vymezené potřeby řízení

41  Varianty modelů účetních systémů  Nákladové účetnictví - zjištění skutečnosti a porovnání se žádoucím stavem  Výkonové – kalkulace výkonů (výrobků, služeb)  Odpovědnostní – systém plánů, rozpočtu a vnitropodnikových cen  ABC – Activity Based Costing – podklady pro řízení procesů  Manažerské účetnictví – zaměření na hodnotové informace faktorů ovlivňujících výši zisku, simulace, varianty vývoje  Controlling zahrnuje hodnotové i nepeněžní informace, zabývá se řízením nákladové, finanční (cash-flow) i naturální stránky procesů  Varianty kalkulací  Kalkulace plných nákladů – rozvrhování fixních i variabilních nákladů na výrobek  Kalkulace variabilních nákladů – hodnotové řízení – jednotce výkonu se přiřazují pouze variabilní náklady, fixní náklady se pro dané období pokrývají marží.

42  Jaké informační entity jsou k dispozici a jaké k dispozici nejsou a budou potřebné pro implementaci ERP systému (např. technologické popisy, kusovníky, popisy pracovních míst, průběžné časy výroby)  Kdo bude odpovědný za jejich údržbu (věcně i provozně, např. určení vlastníka souboru dodavatelé, určení správce databáze)  Jaké jsou požadavky přístupu k nim (kdo, jak rychle, jaké funkce může provádět)  Jaké jsou požadavky z hlediska jejich bezpečnosti (kriteria pro zálohování a obnovu dat)  Jak se tyto požadavky změní ve vazbě na životní cyklus dat

43  Souběžně s definováním datové základny  Formalizovaný popis s důrazem na  Rozlišení událostí a funkcí  Definování metrik (výkonnostních a cílových)  Trendy  BPMS, BSC – integrace s ERP systémy  Gartner – TVO - možnost hodnotit přidanou hodnotu ERP systémů ve vazbě na jednotlivé podnikatelské procesy

44  SaaS (on-demand) – koncový uživatel nevlastní licence a SW, platí univerzální poplatek za čerpání služby (méně časté, průměrná doba 4,3 roku)  Multi-instance: každý uživatel má svoji konfiguraci systému  Multi-tenant: více organizací užívá stejnou instalaci, specifika konfigurace se týkají pouze rolí v podniku a přístupových práv  Hosted: uživatel si koupí/pronajme licence na užívání SW od poskytovatele (Value Added Reseller), který provozuje systém v „hostovaném centru“. Uživatel platí poplatky za technickou údržbu a upgrady, má vlastní instalaci – průměrná doba 7,1 roku)  On-premise: tradiční prodej licencí vázaný na podmínky/omezení (počet uživatelů, budova, organizace,..)

45  Státní organizace Zákon 137 Sb., o veřejných zakázkách  Nabídkové a poptávkové řízení  Smlouva (obchodní podmínky)

46  Základní dokument projektu  Cíl, rozsah, časový harmonogram, etapy, milníky, složení týmů, pravidla spolupráce, reporting, rozpočet  Cílový koncept, specifikace řešení  Realizace, parametrizace, testování  Příprava produktivního provozu, přenos dat  Produktivní provoz a jeho optimalizace

47  Vysvětlete rozdíl mezi životním cyklem produktu, životním cyklem projektu a životním cyklem řízení projektu  Uveďte příklady životních cyklů řízení projektu pro vývoj SW produktů  Popište podrobněji životní cykly RUP a SCRUM  Popište životní cyklus řízení projektu pro implementaci standardního aplikačního SW