Z Na státnice zvesela!

Metodiky vývoje se snaží usnadnit proces vývoje software. Poskytují ověřené rámcové návody jak k vývoji přistupovat. Jsou to takové šablony vedení projektu. Jejich použitím lze minimalizovat pravděpodobnost selhání projektu a naopak zvýšit produktivitu, kvalitu a spravovatelnost celého procesu. Metodologie je opakovatelný proces umožňující zvýšení produktivity a kvality projektu.

Metodiky obsahují postupy jak spravovat jednotlivé fáze životního cyklu projektu, specificky jak:

• komunikovat se zákazníkem a sbírat požadavky
• navrhovat systém
• implementovat systém
• testovat systém
• vydávat systém
• dokumentovat systém
• nasazovat
• spravovat (maintenance)
• vytvářet týmy atd.

Metodiky se liší především:

• rozsahem
  • některé metodiky specifikují jen určité části procesu vývoje SW.
• úrovní formalismu
  • některé metodiky jsou definovány jen rámcově (např. agilní metodiky)
• vhodností nasazení pro danou doménovou oblast
  • např. jinou metodiku použijeme pro vývoj webových aplikací a jinou pro vývoj krabicového software, případně při vývoji open-source SW

Ve většině případů nasazování nějaké metodiky dochází k přizpůsobení metodiky konkrétním potřebám.

Při výběru metodiky je vhodné správně vyvážit úroveň formalismu a kreativní činnost vývojářů, aby nedošlo k situaci, že vývojáři budou jen cvičené opice.

Samotné metodiky jsou předmětem vývoje, neustále se objevují nové a "lepší". Jednotlivými metodikami se zabývá další státnicová otázka. Přikladem je vodopád, spirála, XP,...

Obsah [skrýt] 1 Strukturální/sekvenční metodiky 1.1 SSADM 1.1.1 Modely systému 1.1.2 Etapy 1.1.2.1 Analýza 1.1.2.2 Návrh: 2 Iterativní metodiky 2.1 Rational Unified Process 2.2 Microsoft Solution Framework 3 Agilní (čiperné) metodiky 3.1 Extrémní programování 3.2 Scrum

[editovat] Strukturální/sekvenční metodiky

[editovat] SSADM

• SSADM (Structured System Analysis and Design Method) se stala v průběhu 80. let v Británii standardem pro analýzu a návrh systémů
• Jde o variaci modelu Vodopád
• Ucelená metodologie srovnatelná co do rozsahu a výběru nástrojů např. s metodologií Yourdon/DeMarco
• Metoda je striktně formulována a vede návrháře při jeho práci pomocí jednoznačně definovaných kroků a dílčích cílů
• Systematicky se prověřují dosažené cíle a provádí se jejich korekce
• Vychází z datového modelu; základní datový model se snaží zformulovat už v počátečních etapách
• Odděluje logický a fyzický návrh systému
• Již v průběhu analýzy by měli být podchyceny nestandardní situace a chybové stavy systému

[editovat] Modely systému

• Modely entit (Logical Data Structures – LDS)
  • Tvoří datový model, který ukazuje informaci uchovávanou v systému a vzájemné vztahy mezi jednotlivými datovými komponentami
  • Oproti klasickému ERD se liší především volbou a grafickým znázorněním entit
  • Obsahuje 3 druhy komponent
    • Entity – něco, co je z hlediska sytému podstatné, reprezentuje logicky seskupené údaje, které se týkají jednoho subjektu
    • Datové položky – nejmenší diskrétní komponenta informace, která má význam z hlediska modelovaného systému
    • Relace – vztah mezi dvěma entitami, který má význam pro systém
  • Skládá se ze dvou částí
    • Grafická část – pomocí ERD popisuje entity a vztahy mezi nimi
    • Popisná část – určuje z jakých datových položek se entity skládají a jaké jsou jejich vlastnosti
• Diagramy datových toků (Data Flow Diagrams - DFD)
  • Tvoří funkční model, ukazují informační cesty a transformaci informace
• Životní cyklus entit (Entity Life History - ELH)
  • Ukazuje, jak entita vznikne, mění se a zaniká z pohledu modelovaného systému
  • Grafický model znázorňující život jedné entity od jejího vzniku až po zrušení pomocí stromového grafu
  • V kořeni stromu se nachází příslušná entita; uzly grafu na nižších úrovních představují jednotlivé podněty, které působí na entitu během jejího života
• Uvedené modely jsou tvořeny při analýze systému (etapy 1-3, viz dále) a dále zpřesňovány v etapách logického návrhu (4-5)
• Uvedená trojice se používá ve všech etapách společně, modely jsou vzájemně propojeny a jsou kontrolovány na logickou úplnost a bezespornost

[editovat] Etapy

• Pokrývají pouze analýzu a návrh IS
• Jednotlivé kroky mají přesně definované vstupy a výstupy

[editovat] Analýza

• Analýza stávajícího systému
  • Analyzuje se stávající systém, který má být sice nahrazen, přesto existující informace a podstatné funkce budou pravděpodobně zachovány
  • Pomáhá při stanovování rozsahu
  • Zvyšuje důvěru u uživatelů – zdokumentováním stávajícího stavu prokáží analytici uživatelům, že rozumí problematice
  • Vyšetřují se – operace a data stávajícího systému, jeho problémy, hranice systému, cenové úvahy, objemové a výkonové údaje
  • Používají se různé techniky – interview, studium dokumentace stávajícího systému, dotazníky, pozorování činnosti a další
  • Zjištěné poznatky promítnuty do 3 dokumentů – funkční model systému (sada DFD až do 3. úrovně), datový model systému (LDS), výchozí seznam požadavků/problémů
• Specifikace požadavků
  • Vzdálení se od implementace stávajícího systému a sestavení nezkreslené specifikace nových a aktualizovaných požadavků
  • Popis systému – modely vytvořené v 1. etapě překresleny tak, aby vyjadřoval, co systém dělá bez toho, jak je toho dosaženo
• Výběr technických možností
  • Pokud je vyžadováno nové technické vybavení (HW), jsou připravena podle etapy 2. alternativní technická řešení
  • Každá alternativa je oceněna a je určen možný přínos vztažený k nákladům
  • Pro výběr slouží kvalifikovaně odhadnuté údaje

[editovat] Návrh:

• Návrh logických dat
  • Navrhován logický datový model (data), který bude obsahovat všechny požadované údaje
  • Model je relační; na základě nalezených vztahů jsou údaje seskupovány, jsou identifikovány datové entity a vzájemné vztahy
  • Model se porovnává proti logickým procesům; především musí data použitá v procesním modelu být obsažena v datovém modelu
• Návrh logických procesů
  • Specifikace požadavků 2. etapy je rozvedena do podrobného popisu, ve kterém konstruktér nalezne potřebné informace pro návrh systému
• Fyzický návrh
  • Úplný logický návrh (datový a procesní) je převeden na návrh, který respektuje konečné technické řešení
  • Před vlastní implementací je prvotní fyzický návrh nejprve doladěn (na papíře) a je zjištěno, zda vyhovuje požadavkům na výkonnost systému
  • V této fázi je vytvořena většina technické dokumentace

[editovat] Iterativní metodiky

[editovat] Rational Unified Process

RUP je rozsáhlá, propracovaná objektově orientovaná iterativní metodologie vývoje softwaru. RUP náleží do skupiny. tzv. přístupů řízených případy použití (use-case-driven approach), což znamená, že jako základní element je chápán případ použití definovaný jako posloupnost akcí prováděných systémem či uvnitř systému, která poskytuje určitou hodnotu uživateli systému (v nejobecnějším smyslu).

RUP zavádí čtyři základní fáze vývoje, přičemž každá z nich je organizována do několika iterací. Před započetím nové iterace musí být splněna definovaná kritéria předchozí iterace. Ve fázi zahájení (inception) musí vývojáři definovat účel a rozsah projektu a jeho obchodní kontext; ve fázi projektování (elaboration) je úkolem vývojářů analyzovat potřeby projektu a zákazníka a definovat základy architektury. Třetí fáze, realizace (construction), je zaměřena na vývoj designu aplikace a tvorbu zdrojových kódů, zatímco v poslední fázi, ve fázi předání (transition), dochází k předání projektu – buď zákazníkovi nebo do dalšího vývojového cyklu.

Uvnitř každé fáze dále probíhají iterace; jejich počet závisí na konkrétních potřebách týmu a rozsahu projektu. V metodice Rational Unified Process jsou definovány čtyři základní pojmy, na nichž je celý RUP postaven a z nichž sestává celý vývoj podle této metodiky. Jedná se o pracovníky (workers -- ), činnosti (activities), pracovní procesy (workflows) a meziprodukty (artifacts). RUP pokrývá celý životní cyklus vývoje softwaru – a skoro vše, co RUP obsahuje, lze označit jedním z těchto základních pojmů. RUP dále definuje 6 obecných praktik, které mají při svém použití zajistit efektivnější vývoj, propracovanější řízení kvality a lepší výsledky:

• Iterativní vývoj softwaru: fundamentální problém tradičního, sekvenčního přístupu spočívá v tom, že před sebou tlačí (často dosud netušená) rizika, jejichž odstranění je postupně čím dále dražší. Naproti tomu v iterativním a inkrementálním přístupu, který vychází z Boehmova spirálového modelu, dochází k detekci rizik průběžně. Mezi další výhody iterativního vývoje patří snazší správa změn, lepší znovupoužitelnost, dokonalejší přiblížení k zákazníkovi, atd.

• Správa a řízení požadavků: požadavky jsou typicky dynamické a je nutné počítat s tím, že se v čase mění (syndrom IKIWISI – I Will Know It When I See It – „budu to vědět, až to uvidím“: s nadsázkou vyjádřená neschopnost zákazníka specifikovat dopředu všechny požadavky na vyvíjený produkt).

• Použití komponentové architektury: je-li vyvíjený systém otevřený k použití jiných komponent, může být vývoj efektivnější; znovupoužití hotové komponenty znamená podstatnou úsporu zdrojů. RUP poskytuje metodickou, systematickou cestu návrhu, vývoje a ověření správnosti architektury. Nabízí šablony, architektonické styly a pravidla designu.

• Vizuální modelování softwaru: model je zjednodušením reality; je vytvářen za účelem dokonalejšího porozumění systému; u rozsáhlejších projektů také proto, že není možné pochopit systém v celé jeho celistvosti. Použití standardního modelovacího jazyka (UML) znamená zjednodušení komunikace uvnitř týmu, zlepšení konzistence projektu, zvýšení pravděpodobnosti správného uchopení systému.

• Průběžné zajišťování a ověřování kvality: nalezení a odstranění problému je 100krát až 1000krát dražší po předání produktu než v úvodních fázích vývoje.

• Řízení změn: neřízené změny (ať již při vývoji nebo i po předání) vedou k chaosu

Představuje velmi obecnou metodiku, a proto sama v sobě obsahuje návody, jak ji modifikovat pro konkrétní použití. Ve velké firmě je proto možné vytvořit na základě RUP vlastní metodiku, která bude úzce vycházet z RUP, ale upřesní některé postupy tak, jak se ve firmě konkrétně provádějí

[editovat] Microsoft Solution Framework

• Poslední verze 4, z roku 2005
• Vytvořil Microsoft
• I když je primárně určena pro Windows a Microsoft Visual Studio, její postupy jsou obecně použitelné na jakékoliv platformě, ale není jisté, že budou tak účinné jako na Windows
• Metodika je určena především pro tvorbu databázových aplikacích, u kterých je vyžadována vysoká účinnost a které se vytvářejí v úzké součinnosti s budoucími uživateli
• Jako vhodnou pracovní skupinu doporučuje malý (nejlépe 5tičlenný) tým, jehož členové jsou zhruba vyrovnaní, pokud jde o schopnosti a zkušenosti
• Členové týmu si mezi sebou rozdělí dílčí role – manažer projektu, správce požadavků na aplikaci, technický lídr atd.
• Kromě povinností spojených s těmito funkcemi (viz minulý bod) se každý z nich podílí také na programování a testování
• Metodika klade velký důraz na iterační vývojový cyklus, ve kterém se aplikace vytváří v několika „vlnách“, aby měli budoucí uživatelé možnost co nejdříve se s ní seznámit a vyjádřit připomínky
• Metodika existuje ve variantě i pro agilní vývoj (MSF for Agile Software Development methodology)
• Vývoj by měl být organizován tak, aby každý den byla zkompilovaná nová verze
• Metodika zahrnuje také pravidla, jak navrhnout architekturu aplikace, aby na Microsoft platformě pracovala co nejefektivněji (např. doporučuje používat co nejčastěji uložené procedury a popisuje postupy jak dosáhnout co nejlepší škálovatelnosti)

(zdroj: Potuzák, Kubovec - Okruhy otázek ke státní závěrečné zkoušce z předmětu - Návrh informačních systémů (NIS) 2005/2006)

[editovat] Agilní (čiperné) metodiky

[editovat] Extrémní programování

• agilní metodologie – důležité je přijmout změny v požadavcích návrhu, všude. Změnám se nelze vyhnout a je pravděpodobné že se budou měnit požadavky během vývoje, je tedy nutné upravit metodologii, tak aby změny nenarušily vývoj.

Proč extrémní? Protože používá osvědčené a známé postupy vývoje sw, dotahuje však jejich použití do extrémů.

• neustálá revize zdrojového textu programů (protože kontroly nezaujatým čtenářem jsou dobrá věc, budeme kontrolovat kód nepřetržitě) – párové programování
• protože testování je dobrá věc, všichni budou testovat neustále, dokonce i zákazník (testovací kód někdy přesahuje svým rozsahem vlastní výkonný kód) – test-first
• ověřování, zda návrh programu je správný (protože návrh je dobrá věc, uděláme z navrhování software každodenní chléb všech programátorů) – refaktoring
• program se udržuje na co nejměnší úrovni složitosti – vždy se programuje jen to, co je v danou chvíli nezbyté – jednoduchost
• protože krátké iterace jsou dobrá věc, budeme iterace mít opravdu krátké – dny, ne týdny, měsíce a roky – krátké iterace
• dokumentace minimální, jen pokud je opravdu potřebná
• kódování je nejdůležitější činností v XP, zde ovšem zahrnuje kreslení diagramů, a také vytváření designu, problémy se řeší pokusnými implementacemi a vybráním nejlepšího řešení.
• párové programování – jeden programátor kóduje tj. zabývá se detaily a druhý neustále kontroluje jeho kód a zaměřuje se na celkový obraz. Role se pravidelně střídají, páry se mění a díky tomu programátoři získávají dobrý pojem o systému jako celku.

• XP vyznává následující hodnoty
  • Komunikace – cílem je dát všem členům týmu celkový obraz o projektu, návrh je proto co nejjednodušší a používá běžných metafor. Programátoři komunikují se zákazníkem a spolu navzájem.
  • Jednoduchost – začít s co nejjednodušším řešením a funkcionalitu přidávat. Programuje se pro potřeby dneška a ne někdy v budoucnu. Díky jednoduchosti je design a kód srozumitelný většině členů týmu.
  • Odezva – odezva od systému (unit testing), zákazníka (akceptační testy), od týmu (jak dlouho bude nový požadavek zákazníka trvat implementovat)
  • Odvaha – odvaha zahodit špatný (zastaralý) kód (i když trvalo dlouho ho napsat), změnit strukturu (refaktoring)

• Plánovací hra – hlavní plánovací proces, odehrává se jednou za iteraci (typicky jednou za týden), má dvě části
  • plánování vydání – jaké funkce budou zahrnuty v jakých vydáních (release) projektu a kdy budou dodány. Zákazník dodá požadavky na funkcionalitu, tým požadavky přijme a vyhodnotí
  • plánování iterace – vývojáři rozdělí požadavky na úkoly – odhadne se jejich časová náročnost a přiřadí se konkrétním vývojářům

Hodí se pro menší projekty a malé týmy vyvíjející sw podle zadání, které je nejasné nebo se rychle mění.

[editovat] Scrum

Agilní, iterativní a inkrementální proces. Skládá se ze tří částí, které se opakují po přibližně 15-30 dnech:

1. Předehra (Pre-game, Pre-sprint)
   • plánování, seznam užitečných vlastností – features, úkoly, chyby, … (=backlog), definování cíle sprintu
2. Hra, vývoj (Game, Sprint).
   • přírůstková implementace, scrum meetings
3. Dohra (Post-game, Post-sprint)
   • dodávka

Každodenní schůzka (SCRUM meetings):

• ve stejný čas na stejném místě
• max 30min (cílem je 15 minut) vestoje
• vede SCRUM master (člen týmu, 50% úvazek na implementaci)
• účastníci všichni členové týmu (vývojáři, testeři, uživatelé, …)
• 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ý učastník odpovídá na otázky:
  • co jsi udělal od poslední scrum porady?
  • co budeš dělat do příští scrum porady?
  • jaké překážky Ti stojí v cestě?