Životní cykly
Životní cyklus produktu (IS / IT služby) Životní cyklus projektu Životní cyklus řízení projektu Vývoje produktu Implementace produktu
1.
2.
3.
4. 5. 6.
Identifikace problému – potřeba nového systému/služby obyčejně zadává business 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. Předání systému do produktivního provozu Provozování a údržba systému Stárnutí systému Ukončení provozu systému
Č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ů
Životní cyklus produktu/služby Potřeba
Životní cyklus projektu
Životní cyklus řízení projektu
Vývoj/pořízení systému/služby
Zahájení
Problém
Produktivní provoz
Plánování Realizace Organizování
Specifikace
Návrh
Ukončení provozu
Ukončení
Implemen- Testování tace
Provoz a údržba
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
Druhy životního cyklu řízení 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
Kategorie projektů
?
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
Klasické Vodopádový model
Prototypové Spirálový model RUP
Agilní Extreme programming SCRUM
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
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é
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
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
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. B. C. D.
Určení cílů, alternativ, omezení (Determine objectives, alternatives, constraints) Vyhodnocení alternativ, identifikace a řešení rizik (Evaluate alternatives, identify, resolve risks) Vývoj a verifikace další úrovně produktu (Develop, verify next-level product) Plánování následujících fází (Plan next phases)
D
B D
D
C D D
D D D
A D
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
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)
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%)
Procesy mající vliv na vývoj SW
Fáze RUP S iteracemi:
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
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í
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
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í.
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
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í
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
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
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
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.
SCRUM
SPRINT
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
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)
Prvky agilních metodik Silná účast Zákazníka Iterace Rizika
1. 2. 3. 4. 5. 6.
Definování potřeb řízení Definování modelu řízení Definování datové/informační základny Modelování a optimalizace podnikových procesů Výběr modelu poskytování služby Výběr produktu, poskytovatele a uzavření smlouvy
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
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í
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ží.
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
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
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, ..)
Státní organizace Zákon 137 Sb., o veřejných zakázkách Nabídkové a poptávkové řízení Smlouva (obchodní podmínky)
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
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
