1. diel - Úvod do metodológie vývoja softvéru

Ak sa už nejaký ten rok pohybujeme v IT, programujeme, vytvárame UX dizajn alebo inú činnosť spätú s vývojom softvéru, celkom určite sme sa stretli s projektom, s ktorým bol vážny problém. Či už išlo o vlastný projekt malých rozmerov alebo trebárs aj nejaký väčší. Typickými problémy s ktorými ste sa mohli stretnúť sú:

• projekt sa nestihne dorobiť včas
• projekt je drahšie, než ste čakali
• projekt sa vôbec nedokončí a tzv. stroskotá

Problémy mnohokrát vznikajú z toho dôvodu, že zákazník takmer nikdy nemá rozmyslené čo presne chce (aspoň nie zo začiatku). Má iba predstavu.

Motivácia

Predstavme si problém projektu na úplne triviálnym príklade.

Zákazník po nás bude chcieť e-shop s možnosťou platby iba v hotovosti. Pri nasadení e-shopu si náš zákazník uvedomí, že by chcel ľahko párovať platby pomocou externého účtovného softvéru. Keďže sme nepočítali s tým, že platba bude musieť ešte komunikovať s externými systémami, vývoj sa nám výrazne skomplikoval a predĺžil. Keby sme túto požiadavku dostali hneď na začiatku, nemuseli by sme prerábať časť projektu.

V praxi sú samozrejme také problémy výrazne komplikovanejšia, tento príklad bol iba ukážkový.

Taký projekt je často znázornený kresleným príbehom stavanie hojdačky:

Metodológie vs Metodika

Z takých problému, ktorý sme si uviedli vyššie, vznikla disciplína zaoberajúca sa metódami / problémy vývoja rozsiahlych softvérových systémov. Tejto disciplíne sa hovorí metodológie.

Vo vývoji softvéru predstavuje metodika sadu odporúčaných praktík a postupov pokrývajúce celý životný cyklus tvorby softvéru (od návrhu až k prevádzke).

Metodika a metodológia je v angličtine "methodology", obaja pojmy majú však iný význam. Z tohto dôvodu sa v slovenčine mnohokrát tieto pojmy zamieňajú.

Code and fix

Pre lepšie pochopenie si ukážeme príklad najzákladnejšie metodiky. Jedna z najzákladnejších metodík, ktorú používame pri programovaní malé aplikácie, je Code and fix. Metodika má 3 základné body:

• implementácia
• oprava chýb
• Rozšírenie (ďalší implementácia)

Asi je jasné, že má táto metodika nejaké nevýhody. Na väčších projektoch totiž zlyháva. U takejto metodiky je mnohokrát výsledok projektu nejasný. Metodika typu "Code and fix" by nám teda v praxi nevystačili. Ako sme si už povedali, klient veľakrát ani nevie čo chce a tieto informácie musia často získať projektový manažér od klienta.

Firmy zvyčajne investujú do IT len okolo 6% ich obratu.

Štatistiky

Musíme si uvedomiť, že softvérový vývoj je trochu "mladá" disciplína na rozdiel od elektrotechniky, ktoré sa ľudstvo venuje takmer od počiatku existencie. Softvérovému vývoji sa venujeme iba od roku 1960 (a to informačné systémy neboli úplne tak komplexné ako dnes).

Z tohto dôvodu je iba 60% úspešne dokončených projektov. Úspešne dokončeným projektom rozumieme, že nepresiahol vopred dohodnutý rozpočet a termín dokončenia (tzv. Deadline).

Pri tzv. Tradičných metodík je úspešnosť len 40%. Tradičné metodika je popísaná ďalej v článku.

Pretože majú zákazníci často nerealistické očakávania, priemerne projekt presiahne rozpočet o 45%, čas o 7% a doručí len 44% pridanej hodnoty. Tieto problémy sú spôsobené najčastejšie takto:

1. takmer polovica vývojárov plne nechápu / nevidí pridanú hodnotu v softvéri
2. väčšina projekt manažérov neverí v úspech projektu
3. príliš veľký projekt (projekty s rozpočtom okolo $ 10 mil. majú iba 10% úspešnosť).

Riešenie rizík pri vývoji softvéru

Aby sa projekt stal úspešným, mali by sme:

• Pochopiť problém, ktorý zákazník rieši. Zákazník presne ani nevie, čo chce. Programátor zase nechápe / nerozumie to čo presne potrebuje. Veľakrát sa stáva, že zákazník zvolí nevhodné riešenie, pretože tomu poriadne nerozumie. Je na nás, aby sme sa okrem programovania podieľali aj na zapájanie softvéru do business problematiky a pochopili tak tzv. use case softvéru.
• Popísať problém "raz" vetou.
• Jasne si definovať pridanú hodnotu softvéru.
• Aktívne sa venovať vývojovým metodikám, aby sme mohli zvoliť tú najlepšiu metodiku pre náš projekt.

Projektový trojimperatív (trojuholník)

Kvalita projektu záleží na rozsahu (scope), rozpočtu (price) a termíne dodania (delivery).

Vráťme sa k príkladu s e-shopom, ktorý sme si uviedli na začiatku. Zmena požiadaviek zákazníka viedol k zmene rozsahu (klient požadoval vlastnosť, s ktorou sme nepočítali). Aby sme zachovali kvalitu nových vlastností, ktoré nám ešte ostávajú naimplementovať, musíme zvýšiť rozpočet a oddialiť termín dodania.

Uveďme si ešte jeden príklad. Typicky platí, že projekt s menším rozpočtom, má dlhšiu dobu implementácie. Je to logické, menšie rozpočet mnohokrát znamená menšie tím ľudí, čo môžu na projekte aktívne pracovať. Samozrejme môžeme do istej miery skrátiť dobu dodania, ale s väčším rozpočtom (väčším tímom). Od určitého počtu členov tímu sa produktivita však začne zase znižovať. Zamestnanci si totiž začnú prekážať a môžu spôsobiť skôr viac problémov ako úžitku).

Keď teda zmeníme jeden parameter (napr. Rozsah), minimálne jeden ďalší parameter je ovplyvnený. To nám znázorňuje model projektový trojimperatív:

Už je teda asi jasné, že projektový trojuholník má fixné a variabilné zložky. Fixná zložka je tá, ktorá sa po celý čas projektu nemení. Variabilné sa mení v priebehu životného cyklu vývoja softvéru. Typicky tieto kombinácie fixných a variabilných zložiek rozdeľujeme na dva typy metodík:

• tradičné metodika
• agilné metodika

Tradičné metodika

V tradičných metodikách platí, že je fixná rozsah. Analýza sa urobí typicky hneď zo začiatku a keď s ňou klient súhlasí, "podpíše ju krvou". Projekty používajúce túto metodiku trpí nižšou kvalitou. Jeden z dôvodov nižšej kvality je fakt, že vývoj väčšieho softvéru trvá minimálne 6 mesiacov a za tú dobu sa toho môže všeličo zmeniť. Napríklad si klient u konkurencie všimne, že ich POS (Point of sale) obsahujú aj samoobslužné kasy, ale my klientovi iba vyvíjame POS, ktoré sú určené iba pre zamestnancov (predavačky).

POS je anglická skratka, ktorá v preklade znamená pokladničné miesto

Tento príklad zase berte s nadhľadom

Túto metodiku môžeme vyjadriť týmto schémou:

Agilné metodika

U agilných metodík je fixná rozpočet a termín dodania. Rozsah je variabilný. Oproti tradičných metodík majú projekty typicky vyššiu kvalitu, pretože sa projekt adaptuje vonkajším faktorom. Konkurencia pridá samoobslužný POS a nám nerobí problém sa prispôsobiť a vytvoriť je taky (rozsah projektu je variabilný).

Táto metodika možno znázorniť zase týmto schémou:

Agilné metodika, rovnako ako tradičné, má taky rad svojich nevýhod. Agilné metodiky majú tendenciu byť viac chaotické, kvôli meniacemu sa rozsahu. Ďalej majú tieto metodiky tendenciu viac zapájať klienta. Nie vždy má však klient čas riešiť analýzy.

Záver

Je veľa faktorov ovplyvňujúce výber správnej metodiky. Je dôležité pochopiť, že sa jedná iba o súhrn odporúčaní. Mnoho firiem si rôzne metodiky upravujú podľa seba, aby lepšie vyhovela ich prípadom použitia.

V nasledujúcich lekciách si ukážeme najznámejšie a nepoužívanější metodiky.

V nasledujúcom kvíze, Kvíz - Úvod, metodiky RAD a DSDM, si vyskúšame nadobudnuté skúsenosti z predchádzajúcich lekcií.