2. diel - Metodiky RAD a DSDM

V minulej lekcii, Úvod do metodológie vývoja softvéru , sme si uviedli bežné problémy pri vývoji softvéru a ich možné riešenie. Teraz už tiež vieme, aký je rozdiel medzi tradičné a agilné metodikou.

R APID A pplication D evelopment (skrátene RAD) je metodika vývoja softvéru, ktorá vznikla na prelome 80. a 90. rokov spoločnosti IBM. Jedná sa o formu agilné metodiky, pri ktorej prebieha menej plánovanie, ale viac vývoja.

Metodika RAD

Vývoj softvéru pomocou metodiky RAD prebieha pomocou prototypovania. Ako prvý nastáva analýza požiadaviek a rýchly vývoj prototypu (niekedy dokonca aj viac prototypov zároveň). Prototypy sa vytvárajú už od ranej verzie softvéru a užívatelia sa tak stretávajú s podobou cieľového riešenia už čoskoro pri vývoji. Vďaka spätnej väzby od týchto užívateľov sa dokážu rýchlo zachytiť problémy z ich strany a dokáže sa na ne rýchlo reagovať. Pokiaľ je už zákazník s výsledkom spokojný, nastáva testovanie a oprava dokončeného produktu. Po všetkých týchto krokoch je softvér pripravený na implementáciu:

Diagram procesu vývoja softvéru pomocou metodiky RAD.

Musíme sa pripraviť na to, že užívateľ nebude spokojný na 100%. Môže nastať situácia, kedy si zákazník stanoví budget, do ktorého sa s jeho požiadavkami jednoducho nebude možné vliezť. Je dôležité vedieť nájsť kompromis.

Príklad

Pre lepšie pochopenie tejto metodiky si uvedieme príklad.

Majme zákazníka, ktorý po nás chce vytvoriť aplikáciu pre jeho internetový obchod. Zákazník ako už zvyčajne poriadne nevie, čo vlastne chce, a tak nám naložia poriadnu dávku požiadaviek, ktoré sa zmestia do jeho stanoveného rozpočtu. Kto by taky nechcel čo najviac muziky za málo peňazí, že? Keď za našim zákazníkom po chvíli prídeme s prototypom, uvedomí si, že o niektorú z predtým chcených funkcionalít nestojí a že sú pre jeho aplikácii zbytočné. Naopak nám povie, že by sa chcel dať iným smerom a my sme tak vďaka prototypu zabránili zbytočnej práci na niečom, o čo zákazník vlastne ani nemal poriadne záujem. Vďaka tejto metodiky sa môžeme sústrediť viac na to, čo zákazník naozaj chce.

Spôsob vývoja pomocou metodiky RAD je značnou výhodou oproti veľmi zastaranému "utopickému" vodopádovému vývoji, v ktorom by sa pri zistení nedostatkov muselo ísť znovu na začiatok a začínať skoro znova:

Zastaraný vodopádový model, ktorý sa dnes už nepoužíva.

Využitia

RAD sa využíva predovšetkým na typ softvéru, ktorý rýchly vývoj umožňuje. To znamená, že máme nejakú platformu, na ktorú pomocou RAD prístupu napojujeme ďalšie časti a tým sa pôvodný softvér stáva rozsiahlejšie. Takáto RAD platforma rieši veľmi efektívne jednotné užívateľské rozhranie a vnútorné fungovanie naprieč celou platformou (zdieľanie dát, kompatibilita a podobne). Môžete si to predstaviť ako sadu herných kartičiek, ku ktorým si dokupujete rôzne expanzie.

Výhody

Jednou z výhod RAD prístupu je najmä vyššia kvalita vďaka používaniu prototypov. Dôraz je pri vývoji kladený hlavne na užívateľa a jeho potreby. Celková funkcionalita tak bude zodpovedať hlavne požiadavkám užívateľa a ten vďaka toho bude spokojnejší. Ďalšou výhodou je bezpochyby včasná identifikácia a eliminácia rizík a tým aj veľké ušetrenie času. Vďaka týmto výhodám rastie pravdepodobnosť, že sa projekt dokončí načas a vojdeme sa do daného rozpočtu.

Nevýhody

Aby to celé neznelo moc rozprávkovo dobre, tak iu RAD metodiky nájdeme nevýhody.

RAD vyžaduje skoro neustále zapojenie "business", kedy vďaka novým verziám prototypov vznikajú aj neustále nové požiadavky, ktoré je nutné riešiť. Vďaka neustále novým prototypom môže dochádzať k nedostatkom v návrhu. Dochádza tak k neustálym drobným zmenám a podcenenie základný stavebný architektúry, ktorú by malo riešenie disponovať.

Metodika DSDM

Povedali sme si teda, ako metodika RAD funguje, kde sa využíva a aké sú výhody a nevýhody. Podľa čoho sa ale riadi? Nie je na škodu spomenúť metodiku D ynamic S ystems D evelopment M ethod (Skrátene DSDM). Táto metodika pôvodne vznikla ako riadiaca štruktúra pre metodiku RAD a sú si veľmi podobné. Z metodiky pre vývoj softvéru sa DSDM nakoniec vyvinulo v agilné metodiku pre riadenie projektov, ktoré sa môžu zaoberať skoro čímkoľvek.

Rovnako ako u metodiky RAD, prvé nastáva analýza (v tomto prípade Uskutočniteľnosť a Business štúdia). Potom prichádza na rad vytvorenie funkčného prototypu. Ďalej sa spracujú návrhy na vylepšenie, či zmeny a ako posledný krok je implementácia samotného projektu:

Diagram procesu riešenia projektu pre metodiku DSDM.

DSDM Aterno je nezávislý prístup, ktorý hovorí, že viac projektov stroskotá vďaka problémom s ľuďmi ako s technológiami. Aterno sa tak sústredí na pomoc ľuďom pracovať spoločne a efektívne na dosiahnutie cieľa. Je nezávislý na technológiách a technikách a vďaka tomu sa nemusí viazať na riešenie problémov len v určitej oblasti.

Aterno obsahuje 8 princípov, ktoré smerujú tím k tomu, aby projekt nezlyhal:

• Zameranie sa na biznis potreby.
• Doručenie včas.
• Spolupráca.
• Nikdy neohrozovať kvalitu.
• Budovanie postupne a zo silných základov.
• Rozvíjanie iteratívne.
• Nepretržitá a jasná komunikácia.
• Preukázanie kontroly.

Techniky pre riadenie projektu

Timeboxing je postup pre postupné dokončenie projektu za pomocou rozdelenia projektu na menšie časti - každá časť s pevným rozpočtom a časom dokončenie. Keďže je DSDM agilný prístup a my už vieme, že rozsah je v tomto prípade premenný, tak je už viac-menej jasné, že ak nášmu projektu dôjde čas alebo peniaze, musíme požiadavky s najnižšou prioritou z projektu vypustiť. To však neznamená, že nedodáme nedokončený produkt. Podľa Paretova princípu 80/20 vieme, že 80% projektu pochádza z 20% požiadaviek. Kým máme teda v projekte implementované týchto 20%, projekt spĺňa obchodné potreby:

Ilustračný ukážka Paretova pravidlá.

Čím menšia je hodnota u daného problému, tým menej krivka stúpa.

Moscow je zase technika pre prioritizáciu požiadaviek. Jedná sa o jednoduché MUSÍME (M ust) mať, MALI BY SME (S hould) mať, MOHLI BY SME (C Ould) mať a NEBUDEME (W on't) mať. Sú to úrovne priorít pre požiadavky na projekt. Môžeme ich využiť napríklad v už spomínanom Timeboxingu.

Prototypovania a Testovanie už poznáme z metodiky RAD. Jedná sa teda o vytváranie prototypov a ich testovanie užívateľmi. Vďaka tomu vieme, či sa vydávame správnym smerom a môžeme včas riešiť problémy.

Workshop je schôdzka všetkých zúčastnených strán projektu, aby spolu prediskutovali požiadavky, funkcie a vzájomne si tak lepšie porozumeli.

Modelovanie pomáha s vizualizáciou a zlepšuje porozumenie. Jedná sa o vytvorenie schematického znázornenie dôležitých častí projektu.

Záver

Nie je pravidlom, že sa metodika RAD musí riadiť zrovna pomocou DSDM. DSDM a rovnako tak RAD sú len súborom odporúčaní, ktoré pomáhajú s riadením projektu a ako už padlo v minulej lekcii, jedná sa naozaj skôr o odporúčanie, než o pevne dané pravidlá.

V ďalšej lekcii, Metodika SCRUM , sa pozrieme na vývojovú metodiku, ktorú používa až 40 percent spoločností. Táto metodika sa nazýva SCRUM.