Vstupy:

– konceptuální model

– datový

– popisuje entity, atributy, vztahy a integritní omezení

– vztahy mezi nimi

– model tříd popisuje i operace, často se však k modelu připojí až v návrhu

– funkční model

– popisuje služby, které systém poskytuje pro záznam, údržbu a využití dat

– use cases, DFD

– dynamický model

– popisuje možné stavy dat a jejich změny

– diagram aktivit, stavy systému, události a reakce na ně

Kroky návrhu:

– návrh architektury systému

– návrh uživatelského vzhledu

– způsob ovládání (formuláře, řádkové příkazy, …)

– volba ovládacích prvků

– volba základních prvků ovládání

– návrh komponent

– návrh komunikace mezi komponentami

– návrh způsobu integrace komponent a testování celku

– návrh reprezentace dat

– pro každou datovou paměť (úložiště) se musí navrhnout způsob reprezentace

– převod konceptuálního modelu do relačního

Základní technologická rozhodnutí ve fázi návrhu:

– architektura systému

– datové zdroje, přístupové mechanizmy k nim

– distribuce programových modulů, komunikační mechanizmy

– typy a formy výstupů

– uživatelské rozhraní

– vývojové prostředí

Výstupní dokumenty návrhu

– architektura systému (HW, SW)

– popis implementace dat (logický datový model)

– logický např. relační model, SQL-99 …, včetně integritních omezení

– ovládání souborů

– popis komponent (modulů)

– projektová dokumentace návrhu

16. Jaké metodiky řízení vývoje informačních systémů znáte?

Metodika vývoje SW je tvořena obecně uznávanými postupy a návody, které popisují činnosti při analýze, návrhu, vývoji, nasazování software stejně jako činnosti spojené s řízením projektu. Cílem metodiky je formalizovat postupy, definovat zodpovědnosti a pravidla komunikace. Metodiky vývoje, údržby a provozu IS/ICT definují principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačních systémů, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení.

V oblasti řízení a podpory softwarových projektů je k dispozici velké množství metodik. U nás i ve světě jsou nejpoužívanější dvě metodiky, které se staly uznávaným standardem. První z nich je „Object-Oriented Software Process Pattern" od Scotta Amblera a druhou je „Rational Unified Process" (RUP) firmy Rational. Ve světě i u nás je známější RUP, pro který jsou již dokonce dostupné i podpůrné softwarové nástroje. Ve srovnání s amblerovou metodikou je RUP podrobnější a složitější, ale amblerův přístup má čtyři významné přednosti:

1. … je jednodušší a je důsledně procesně orientovaný ve srovnání s RUPem

2. … zabývá se i fází údržby a provozu již vyrobeného systému

3. … lépe podporuje tvorbu v čistých objektových jazycích a databázích

4. … lze využít i pro jiné metody analýzy a návrhu, než z dílny UML.

Rigorózní metodiky

Rigorózní metodika je pejorativní označení přístupu založeného na sekvenčním modelu od autorů agilních metodik. Někteří autoři ale pod rigorózní metodiky zahrnují jakoukoliv metodiku, ve které se objevují různé fáze během vývoje systému a ve které se pracuje s formální dokumentací (diagramy, tabulky, seznamy, …), i když je tato metodika iterativní nebo evoluční.

Rigorózní metodiky jsou údajně příliš složité, málo účinné, vyžadují množství dokumentace a tím vším komplikují a oddalují výslednou implementaci. Rigorózní metodiky jsou také údajně neúčinné v podmínkách rychle se měnících požadavků a vyvíjejících se technologií.

 Pro mnohé současné projekty nevyhovují.

Vycházejí z odlišných předpokladů:

• požadavky je možné specifikovat předem,

• změnám se snažíme zabránit,

jsou náročné

• velké množství meziproduktů

• ztrácí se cíl vývoje: vytvořit fungující SW odpovídající potřebám uživatelů

Rigorózní metodiky jsou postaveny na nedůvěře.

Spolupráce zákazníků a vývojářů:

• standardizují lidi v organizaci

• snaží se vykázat lidi do role zaměnitelné součástky

• čím větší projekty se realizují, tím více specialistů je třeba zapojit

Vycházejí z přesvědčení, že procesy při budování IS/ICT lze popsat, plánovat, řídit a měřit.

Snaží se podrobně a přesně definovat procesy, činnosti a vytvářené produkty, a proto bývají často velmi objemné.

Rigorózní metodiky jsou zpravidla založeny na sériovém (vodopádovém) vývoji. Existují ale také rigorózní metodiky založené na iterativním a inkrementálním vývoji. Příkladem těchto metodik jsou OPEN, Rational Unified Process (RUP), Enterprise Unified Process (EUP).

Vycházejí z předpokladů:

požadavky je možné specifikovat předem,

změnám se snažíme zabránit,

Jsou náročné:

velké množství meziproduktů

ztrácí se cíl vývoje – vytvořit fungující SW odpovídající potřebám uživatelů.

Příčina vzniku agilních metodik je samotnými autory popisována jako selhání rigorózních metodik. Příčinu jejich selhání vysvětlují v nepotřebné dokumentaci, zbytečném kreslení diagramů a vůbec v provádění aktivit, které oddalují „opravdové“ programování. Jako lék nabízejí tyto zdržující aktivity nedělat vůbec a soustředit se jen na vlastní tvorbu softwaru.

S tímto tvrzením však nelze souhlasit. Pokud se podíváme na jiné oblasti inženýrských aktivit (stavebnictví, strojírenství, …), tak uvidíme, že se všude plánuje, analyzuje, dokumentuje, prototypuje, testuje atd. Proč by tedy měla být oblast tvorby softwaru výjimečná?

Základní myšlenka potřebnosti „rigorózních“ metodik nemůže být špatná. I v softwarovém inženýrství je potřeba projekty plánovat, řídit, analyzovat zadání atp. Na druhou stranu je pravda, že v mnoha případech „rigorózní“ přístup nevede k lepšímu, rychlejšímu a levnějšímu výsledku, než při nasazení AP.

Agilní metodiky

Agilní metodiky jsou samotnými autory označovány jako metodiky, které umožňují vytvořit řešení velmi rychle a optimálně a toto řešení dovolují pružně přizpůsobovat. Jedná se o několik metodik, z nich nejpopulárnější je takzvané extrémní programování (XP). Agilní přístup (AP) byl s velkým nadšením přijat v komunitě programátorů pracujících s OOP. Představitelé těchto přístupů z celého světa v roce 2001 vydali společný dokument „Agile Manifesto“ a vytvořili alianci pro „agilní vývoj softwaru“. [AP 2001, Beck 2003, Beck 2002]

 Tento manifest deklaruje následující priority (citace z [AP 2001]):

Odhalili jsme lepší způsob vývoje softwaru, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Dáváme přednost:

1. individualitám a komunikaci před procesy a nástroji,

2. provozuschopnému softwaru před obsažnou dokumentací,

3. spolupráci se zákazníkem před sjednáváním kontraktu a

4. reakci na změnu před plněním plánu.

Přestože doposud uvedená informace o agilním přístupu vypadá krajně podezřele, tak agilní přístup má v praxi dobré výsledky, což můžeme potvrdit i my¹. Autoři agilních metodik jsou většinou pro věc nadšení, ale také velmi vzdělaní lidé.

 Agilní přístup má velké přednosti v malých týmech, které mohou pravidelně komunikovat se zákazníkem/zadavatelem. Nezbytnou nutností pro úspěch je ale mít zajištěné:

1. technickou podporu týmu (vývojové prostředí, které umožňuje práci s komponentami, inkrementální kompilaci, refaktoring, evidence a sdílení kódu, metriky a v neposlední řadě testování) a

2. koordinovaný a průběžný kontakt se zadavatelem/zákazníkem.

Agilní přístupy nelze použít u velmi velkých projektů, kde se naráží nejvíce na nedostatek průběžného kontaktu se zadavateli a na potřebu projekt plánovat.

Lehké metodiky, nepopisují procesy, ale principy, málo dokumentace, dávají přednost osobní komunikaci

• zaměřeny na ty činnosti, které vytvářejí hodnotu, eliminují činnosti, které hodnotu nepřinášejí

• inovace a kreativita se rozvíjejí v chaosu, proto málo procesů, spíše praktiky

Agilní metodiky jsou formovány na důvěře a respektu. (vůdcovství a spolupráce).

Spolupráce zákazníků a vývojářů: využívají individualit a silných stránek lidí, požadují integraci znalostí, stálá interakce a kooperace, sdílení znalostí v týmu, týmové řešení problému.

Agilní metodiky se navzájem liší, ale jsou postaveny na společných principech:

• iterativní vývoj s velmi krátkými iteracemi, zaměření na fungující SW, který má hodnotu pro zákazníka, lidé jsou prvořadým faktorem, důraz na spolupráci a komunikaci, tolerantní ke změnám, automatizované testování.

 

Agilní metodiky:

• Adaptive Software Development (ASD), (dynamický cyklus .Speculate.Collaborate.Learn.)

• Dynamic Systems Development Method (DSDM), ( dynamic, systems, development, method)

• Feature-Driven Development (FDD), vývoj podle užitných vlastností

• Extreme Programming (XP): plánovací hra, malé verze, metafora, jednoduchý návrh, testování refaktorizace, párové programování, společné vlastnictví kódu, nepřetržitá integrace, 40hodinový týden, zákazník na pracovišti, standardy pro psaní zdroj kódu

Lean Development, cílem je vytváření softwaru tolerantního ke změnám s třetinovou lidskou prací, s třetinovým časem, s třetinou investic do nástrojů a metod, s třetinovou námahou přizpůsobit se novému tr.nímu prostředí.

SCRUM (projektová metodika; zaměřená především na řízení projektu; Chápe procesy při vývoji software jako empirické procesy, které není možné předvídat, ale je nutné je monitorovat.; K tomu poskytuje praktiky jako denní porady, monitorování Sprintu (30 denní iterace) pomocí Backlog graph a další.

Framework pro řízení projektu

• vývoj SW není definovaný proces, který je možné přesně popsat opakovat, a ale empirický proces

• empirický proces vyžaduje odlišný styl řízení – vyžaduje konstantní monitorování a adaptaci

• implementace empirického procesu má 3 pilíře:

1 viditelnost do procesu

2 inspekce

3 adaptace

Role Scrum

Product Owner - spravuje seznam požadavků (Product Backlog) tak, aby maximalizoval hodnotu projektu; reprezentuje všechny zainteresované

Team - kros-funkční skupina lidí, kteří se sami řídí tak, aby v každém sprintu dodali fungující SW

ScrumMaster - zodpovídá za Scrum proces, jeho správnou implementaci a maximalizaci užitku

Sprint

Všechna práce se dělá uvnitř sprintu. Sprint je 30 denní iterace.

Na začátku sprintu se koná Sprint Planning Meeting:

• trvá max. 8 hodin,

• cíl - definovat Sprint Backlog

• první 4 hodiny - Product Owner prezentuje požadavky nejvyšší priority v Product Backlogu, tým se dotazuje na obsah, účel, význam požadavků požadavků, nakonec vybere požadavky nejvyšší priority do Sprint Backlogu

• druhé 4 hodiny – tým plánuje Sprint – jde o plán předběžný, který se neustále sprintu v průběhu upravuje

• každý den se koná Scrum Meeting – 15 min.

na konci sprintu se koná Sprint review meeting:

• trvá 4 hodiny

• tým prezentuje, co bylo vyvinuto

• Sprint retrospective meeting zlepšení procesu a praktik

Principy Scrum

- Komunikace

- sdílení informací umožňuje viditelnost, lepší rozhodování a pochopení cílů

- denní informování o (daily meeting) pokroku meeting).

- je třeba vědět, jak na tom tým je a podle toho dělat rozhodnutí (sprint backlog).

- pracujte společně ( Stay in sync.) p j p y y )

- Pravomoc týmu

- není nic mocnějšího než tým, který je omezován jen tím, jak kreativní je a jak tvrdě bude pracovat

- Učit se a zlepšovat

- zkusit, prohlédnout výsledky, zlepšitsprint

- krátké sprinty

- předvedení výsledků na konci sprintu (sprint review)

- zlepšení po každé iteraci (sprint retrospective).

- Dodat hodnotu včas

- priority požadavků (product backlog, Product Owner), dohoda o produktech, jejich

dodání – to buduje důvěru mezi spolupracovníky, dalšími týmy a zákazníky

- plánujte sprint (sprint planning meeting).

SCRUM meetings

- umožňují monitorovat stav projektu,

- konají se vždy ve stejný čas na stejném místě

- trvají méně než 30 minut (cílem je 15 minut)

- vede je Scrum master j

- účastní se jich všichni členové týmu (vývojáři, uživatelé ,

testeři,..)

- navštěvují je manažeři, aby věděli o stavu, ale aktivně se

neúčastní

- slouží ke zjištění problémů, ale ne k jejich řešení

- každý účastník musí zodpovědět 3 otázky:

- co udělal od poslední scrum porady

- co bude dělat do příští scrum porady

- jaké překážky mu stojí v cestě

Crystal metodiky, - rodina metodik, které jsou určeny pro různé typy projektů

Agile Modeling - lehká metodika pro efektivní modelování postavená na prověřených modelovacích technikách

V průběhu devadesátých let získaly značnou popularitu programové systémy na podporu vývoje informačního systému - systémy CASE.

  

	Rigorózní metodiky	Agilní metodiky
předpoklady	SW procesy lze popsat	SW procesy nelze popsat
	požadavky je možné definovat předem	předem jen hrubé požadavky
obsah	přesně definované procesy, činnosti, artefakty	jen generativní pravidla, praktiky a principy
použití	standardní projekty, velké projekty	výzkumné projekty time-to-market menší týmy