14. diel - Úvod do vývoja softvéru Nové

V predchádzajúcom kvíze, Kvíz - Prístupy k testovaniu, manažment testovania a rizík, sme si overili nadobudnuté skúsenosti z predchádzajúcich lekcií.

V dnešnom tutoriále si uvedieme bežné problémy pri vývoji softvéru a ich možné riešenie. Pozrieme sa na metodiku code and fix, riešenie rizík pri vývoji softvéru a taktiež na projektový trojimperatív. Tiež sa dozvieme, aký je rozdiel medzi tradičnou a agilnou metodikou.

Táto lekcia je súčasťou kurzu Metodiky vývoja softvéru.

Ak sa už nejaký ten rok pohybujete v IT, programujete, vytvárate UX design alebo inú činnosť spätú s vývojom softvéru, určite ste sa už stretli s projektom, s ktorým bol vážny problém. Či už išlo o vlastný projekt malých rozmerov, alebo napríklad aj nejaký väčší. Typickými problémami, s ktorými ste sa mohli stretnúť, sú tieto situácie:

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

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

Motivácia

Predstavme si problém projektu na úplne triviálnom 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 s tým, že platba bude musieť ešte komunikovať s externými systémami, nepočítali, 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šie, tento príklad bol iba ukážkový.

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

Metodológie vs. metodika

Z podobných problémov vznikla disciplína zaoberajúca sa metódami/problémami vývoja rozsiahlych softvérových systémov. Tejto disciplíne sa hovorí metodológia.

Metodika vo vývoji softvéru naproti tomu predstavuje sadu odporúčaných praktík a postupov pokrývajúcich celý softvér development life cycle (od návrhu až po prevádzku).

Metodika aj metodológia sa anglicky povedia „methodológmi“, kvôli čomu sa tieto pojmy v slovenčine často chybne zamieňajú. Každý z pojmov má však iný význam.

Code and fix

Pre lepšie pochopenie si ukážeme jednu z najzákladnejších metodík, ktoré používame pri programovaní malej aplikácie. Jedná sa o code and fix. Metodika má tri základné body:

• implementáciu,
• opravu chýb,
• rozšírenie (ďalšiu implementáciu).

Asi je zrejmé, že táto metodika má určité nevýhody. Na väčších projektoch zlyháva, pretože je u nej výsledok projektu často nejasný. Metodika typu code and fix by nám teda v praxi nevystačila. Ako sme si už povedali, klient často ani nevie, čo chce, a tieto informácie od neho musí často získať projektový manažér.

Firmy obvykle investujú do IT len okolo 6% svojho obratu.

Štatistiky

Musíme si uvedomiť, že softvérový vývoj je na rozdiel od elektrotechniky, ktorej sa ľudstvo venuje zhruba posledných 300 rokov, trochu „mladá“ disciplína. Softvérovým vývojom sa zaoberáme iba od roku 1960 (a to informačné systémy neboli tak komplexné ako dnes).

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

Pri tzv. tradičnej metodike je úspešnosť iba 40%. Tradičná metodika je popísaná ďalej v článku.

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

1. Takmer polovica vývojárov plne nechápe/nevidí pridanú hodnotu v softvéri.
2. Väčšina projektových manažérov neveria v úspech projektu.
3. Ide o príliš veľký projekt (projekty s rozpočtom okolo 10 mil. dolárov 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, čo zákazník presne potrebuje. Veľakrát sa stáva, že zákazník zvolí nevhodné riešenie, pretože problematike poriadne nerozumie. Je na nás, aby sme sa okrem programovania podieľali aj na zapájaní softvéru do business problematiky a pochopili sme 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 pre náš projekt.

Projektový trojimperatív (trojuholník)

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

Vráťme sa k príkladu s e-shopom, ktorý sme si uviedli na začiatku. Zmena zákazníkových požiadaviek viedla k zmene rozsahu (klient požadoval vlastnosť, s ktorou sme nepočítali). Aby sme zachovali kvalitu nových vlastností, ktoré nám ešte zostá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ší rozpočet často znamená menší tím ľudí, ktorí môžu na projekte aktívne pracovať. Samozrejme môžeme do istej miery skrátiť dobu dodania, ale len za cenu väčšieho rozpočtu (väčšieho tímu). Od určitého počtu členov tímu sa však produktivita začne opäť 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 tým ovplyvníme. 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ú dobu projektu nemení. Variabilný sa mení v priebehu SDLC. Tieto kombinácie fixných a variabilných zložiek typicky rozdeľujeme na dva typy metodík:

• tradičná metodika,
• agilná metodika.

Tradičná metodika

V tradičných metodikách platí, že fixný je 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 trpia nižšou kvalitou. Jedným z dôvodov 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 jej point of sale (POS), teda v preklade pokladničné miesto, obsahuje aj samoobslužné kasy, ale my klientovi vyvíjame POS, ktoré je určené iba pre zamestnancov (predavačky).

Túto metodiku môžeme vyjadriť touto schémou:

Agilná metodika

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

Táto metodika sa dá znázorniť zase touto schémou:

Agilná metodika má, rovnako ako tradičné, aj množstvo svojich nevýhod. Agilné metodiky majú tendenciu byť kvôli meniacemu sa rozsahu chaotickejšie. Ďalej tiež viac zapájajú klienta. Klient však nemá vždy čas riešiť analýzy.

Záver

Je mnoho faktorov ovplyvňujúci výber správnej metodiky. Je dôležité pochopiť, že ide iba o súhrn odporúčaní. Mnoho firiem si rôzne metodiky upravuje podľa seba, aby lepšie vyhoveli vlastným prípadom použitia.

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.