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

V predchádzajúcej lekcii, Testovacie nástroje , sme si ukázali čo je to konfiguračný manažment a manažment defektov. Vysvetlili, ako rôzne typy testovacích nástrojov podporujú testovanie a ukázali sme si výhody a riziká automatizácie testov.

V lekcii úvod do vývoja softvéru 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 tiež na projektový trojimperatív. Budeme tiež vedieť, aký je rozdiel medzi tradičnou a agilnou metodikou.

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

Pokiaľ sa už nejaký ten rok pohybujeme v IT, programujeme, vytvárame UX design 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 napríklad aj nejaký väčší. Typickými problémami s ktorými ste sa mohli stretnúť je že:

• projekt sa nestihne dorobiť včas,
• projekt je drahšie, 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 zo zač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 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šie, tento príklad bol iba ukážkový.

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

Metodológia vs Metodika

Z takýchto problémov, ktorý sme si uviedli vyššie, 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.

Vo vývoji softvéru predstavuje metodika 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 a metodológia je v angličtine „methodológmi“, oba 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šej metodiky. Jedna z najzákladnejších metodík, ktorú používame pri programovaní malej aplikácie, je Code and fix. Metodika má 3 základné body:

• Implementácia
• Oprava chýb
• Rozšírenie (ďalšia implementácia)

Asi je jasné, že táto metodika má 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čila. Ako sme si už povedali, klient často ani nevie čo chce a tieto informácie musí často získať projektový manažér od klienta.

Firmy obvykle 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, ktorej sa ľudstvo venuje takmer od počiatku existencie. Softvérovému vývoju 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čnej metodike je úspešnosť iba 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 týmto:

1. takmer polovica vývojárov plne nechápe/nevidí pridanú hodnotu v softvéri
2. väčšina projekt manažérov neveria 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 tomu č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ájaní 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 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 požiadaviek zákazníka 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í, č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ú dobu projektu nemení. Variabilný sa mení v priebehu SDLC. 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 trpia 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 Point of sale – POS 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.

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 vonkajším faktorom. Konkurencia pridá samoobslužný POS a nám nerobí problém sa prispôsobiť a vytvoriť ich tiež (rozsah projektu je variabilný).

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

Agilná metodika, rovnako ako tradičná, má tiež množstvo 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 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 ich 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.