Ako prebieha vývoj softvéru na mieru od zadania po nasadenie
Vývoj softvéru na mieru nie je len programovanie. Je to séria rozhodnutí od analýzy potrieb cez návrh a testovanie až po nasadenie a ďalší rozvoj systému.
Zhrnutie
Vývoj softvéru na mieru zvyčajne prebieha v siedmich krokoch: pochopenie procesov, spresnenie požiadaviek, návrh riešenia, samotný vývoj, testovanie, nasadenie a priebežné zlepšovanie. Najväčší rozdiel medzi úspešným a drahým projektom nebýva v technológii, ale v tom, ako presne sa na začiatku pomenuje problém, nastaví priorita funkcií a priebežne sa vyhodnocuje reálne používanie. Dobre vedený proces preto spája biznis, používateľov aj vývojový tím do jedného rytmu rozhodovania.
Čo znamená vývoj softvéru na mieru v praxi?
V praxi ide o návrh a tvorbu systému okolo konkrétnych procesov firmy, nie o prispôsobovanie firmy hotovému nástroju. Softvér na mieru vzniká cez analýzu, dokumentáciu, programovanie, testovanie a dlhodobú údržbu, pričom testovanie a spätná väzba nemajú prísť až na konci, ale počas celého cyklu, ako to odporúča aj prehľad životného cyklu vývoja softvéru od Atlassianu.
Ak firma rieši obchod, servis, schvaľovanie, reporting alebo interné workflow spôsobom, ktorý sa do bežného „krabicového“ systému nezmestí bez veľkých kompromisov, práve tu dáva zmysel vývoj na mieru alebo nadväzujúci CRM systém na mieru.
Typicky nejde o jeden veľký jednorazový projekt, ale o riadený proces:
- najprv sa spresní obchodný cieľ,
- potom sa rozdelia požiadavky na priority,
- následne sa pripraví návrh architektúry a používateľských tokov,
- vývoj prebieha v menších celkoch,
- po nasadení sa sleduje používanie a ďalšie úpravy.
Ako vyzerá prvá fáza analýzy a zberu požiadaviek?
Prvá fáza má odpovedať na jednoduchú otázku: aký problém má softvér vyriešiť a podľa čoho spoznáte, že ho vyriešil. Bez tejto fázy sa projekt rýchlo mení na zoznam nápadov bez priorít, čo zvyšuje riziko meškania, zbytočných funkcií a rozpočtových zmien.
V tejto časti sa zvyčajne mapuje:
- kto bude systém používať,
- aké kroky dnes ľudia robia ručne,
- kde vznikajú chyby, duplicity alebo zdržania,
- aké dáta treba zbierať a prepájať,
- čo musí byť hotové v prvej verzii a čo môže počkať.
Dobrý výsledok analýzy nie je 50-stranový dokument pre dokument samotný, ale jasný rámec rozhodnutí. Pomáha backlog, používateľské scenáre, definícia priorít a pomenovanie závislostí medzi časťami systému. Práve kvalitné zadanie a nástroje pre plánovanie patria podľa výskumu McKinsey o Developer Velocity medzi faktory, ktoré súvisia s lepším biznis výkonom digitálnych tímov.
Ak firma už vie, že potrebuje prepojiť obchod, zákaznícke dáta a automatizované úlohy, býva užitočné od začiatku premýšľať aj nad tým, či výsledkom nebude okrem aplikácie aj širšia vrstva AI riešení alebo automatizačných riešení.
Ako sa z požiadaviek stane návrh riešenia?
Keď sú priority zrozumiteľné, prichádza preklad z biznis jazyka do technického návrhu. V tejto fáze sa určuje, ako bude systém fungovať zvnútra, ako budú vyzerať obrazovky, aké integrácie bude potrebovať a ktoré časti sa oplatí vyvíjať ako prvé.
Návrh zvyčajne zahŕňa:
- používateľské toky a wireframy,
- dátový model a pravidlá práce s dátami,
- architektúru aplikácie,
- integrácie na externé systémy,
- plán vydaní alebo MVP verzie.
Pri modernom vývoji sa už v návrhu oplatí riešiť aj bezpečnosť a ochranu údajov. NIST SSDF upozorňuje, že bezpečnostné praktiky treba integrovať do ľubovoľného SDLC modelu, nie dopĺňať až po vývoji. A ak systém pracuje s osobnými údajmi, GDPR v článku 25 vyžaduje prístup „data protection by design and by default“, teda ochranu súkromia už v návrhu riešenia.
V praxi to znamená napríklad rozhodnúť ešte pred programovaním, ktoré dáta sú skutočne potrebné, kto ich bude vidieť, ako dlho sa budú uchovávať a aké oprávnenia budú mať rôzne roly v systéme.
Ako prebieha samotný vývoj softvéru na mieru?
Samotný vývoj prebieha najlepšie v menších iteráciách, nie ako dlhé obdobie bez priebežných výstupov. Tím berie schválené priority z backlogu, implementuje ich, priebežne kontroluje kvalitu kódu a ukazuje funkčné časti systému, aby sa rozhodnutia dali korigovať skôr, než sa chyba predraží.
Počas vývoja sa bežne rieši:
- backend logika a databáza,
- používateľské rozhranie,
- napojenie na API a externé služby,
- prístupové práva a roly,
- logovanie, monitoring a technické základy prevádzky.
Dobrá prax dnes znamená, že vývoj nie je oddelený od kvality, bezpečnosti a nasadenia. Podľa odporúčaní NIST SSDF má bezpečný vývoj znižovať počet zraniteľností už počas tvorby softvéru. A OWASP ASVS poskytuje vývojovým tímom konkrétny rámec požiadaviek a verifikácie bezpečnostných kontrol webových aplikácií.
Pre firmu je dôležité, aby počas vývoja nehodnotila progres len podľa počtu odpracovaných hodín. Oveľa užitočnejšie je sledovať, či pribúdajú použiteľné funkcie, či sa skracuje ručná práca, či sú dáta spoľahlivejšie a či sa systém približuje k dohodnutému cieľu. Ak projekt zahŕňa aj verejnú prezentáciu firmy, vývoj sa často prepája s webovými stránkami, mobilnými aplikáciami alebo e-commerce vrstvou cez vývoj e-shopov.
Prečo nestačí testovať až pred spustením?
Testovanie na konci nestačí, pretože vtedy už bývajú chyby drahšie, zložitejšie a organizačne bolestivejšie na opravu. Rozumnejší prístup je testovať priebežne: od validácie zadania cez kontrolu funkčnosti až po bezpečnostné overenie a používateľské scenáre pred ostrým nasadením.
V praxi sa kombinuje viac vrstiev testovania:
- kontrola splnenia požiadaviek,
- funkčné a integračné testy,
- regresné testy po zmenách,
- používateľské akceptačné testovanie,
- bezpečnostné overenie kritických častí.
Atlassian pri svojom popise SDLC uvádza, že testovanie má byť súčasťou celého životného cyklu, nie izolovanou poslednou fázou. A OWASP ASVS je praktický základ na overovanie technických bezpečnostných kontrol, napríklad pri autentifikácii, práci so session, validácii vstupov alebo ochrane dát.
Ak sa počas testovania ukáže, že niektorý tok je pre používateľov zbytočne komplikovaný, je to stále dobrá správa. Oprava pred produkciou stojí násobne menej ako zmena procesu po zaškolení tímu a po prenesení reálnych dát.
Čo sa deje pri nasadení a po spustení systému?
Nasadenie nie je cieľová čiara, ale prechod do ďalšej fázy, v ktorej sa ukáže, ako softvér funguje v skutočnej prevádzke. Po spustení sa sleduje stabilita, správanie používateľov, kvalita dát, výkon systému a to, či nová aplikácia naozaj šetrí čas alebo odstraňuje chyby.
Po produkčnom štarte sa zvyčajne rieši:
- migrácia alebo import dát,
- školenie používateľov,
- monitoring výkonu a chýb,
- zber spätnej väzby,
- plán ďalších iterácií.
Práve táto fáza často rozhodne, či sa z projektu stane reálny pracovný nástroj alebo len „hotový systém“, ktorý tím obchádza bokom. Zmysel má sledovať konkrétne ukazovatele: čas spracovania úlohy, počet manuálnych krokov, chybovosť, rýchlosť reakcie obchodného tímu alebo kvalitu reportingu. Výskum McKinsey o Developer Velocity spája kvalitné nástroje, procesy a produktové riadenie s lepšou inováciou aj vyššou spokojnosťou používateľov v organizácii.
Ak firma potrebuje po spustení aj ďalšie školenie ľudí, môže byť súčasťou úspešného rollout-u aj interný tréning, dokumentácia alebo nadväzujúce školenia.
Ako dlho trvá vývoj softvéru na mieru a čo ho najviac ovplyvňuje?
Trvanie projektu neurčuje len počet obrazoviek alebo funkcií. Viac ho ovplyvňuje kvalita zadania, zložitosť integrácií, miera zmien počas vývoja, bezpečnostné požiadavky, dostupnosť ľudí na strane klienta a to, či sa ide cez jedno veľké zadanie alebo cez postupné iterácie.
Na čas aj rozpočet majú najväčší vplyv najmä tieto faktory:
- nejasné alebo meniace sa priority,
- komplikované napojenia na existujúce systémy,
- zlá kvalita vstupných dát,
- chýbajúce rozhodovanie na strane zadávateľa,
- podcenené testovanie a adopcia používateľmi.
Preto sa pri vývoji na mieru oplatí začať menším, ale dobre navrhnutým rozsahom. Prvá verzia nemusí obsahovať všetko; má priniesť funkčný základ, na ktorom sa dá bezpečne stavať. Takýto prístup býva stabilnejší než snaha naraz naprogramovať celý budúci svet firmy bez spätnej väzby z reálnej prevádzky.
Podľa čoho spoznáte, že je proces vývoja nastavený dobre?
Dobre nastavený proces spoznáte podľa toho, že aj netechnický človek vie odpovedať na tri otázky: čo sa teraz robí, prečo je to priorita a ako sa bude hodnotiť výsledok. Ak na ne nikto nevie odpovedať, problém zvyčajne nie je v programátoroch, ale v riadení projektu.
Zdravý proces má spravidla tieto znaky:
- jasne pomenovaný obchodný cieľ,
- priebežné ukážky funkčných častí systému,
- rozhodovanie podľa priorít, nie podľa hlasitosti požiadaviek,
- viditeľnú väzbu medzi požiadavkou, implementáciou a testom,
- plán ďalšieho rozvoja aj po nasadení.
Ak sa teda pýtate, ako prebieha vývoj softvéru na mieru, stručná odpoveď je táto: začína pochopením procesov, pokračuje premenou potrieb na návrh a iteratívny vývoj, a končí až vtedy, keď sa systém osvedčí v každodennej prevádzke. Pre firmy, ktoré chcú softvér stavať okolo vlastných workflow a nie naopak, je práve toto rozdiel medzi obyčajným dodaním aplikácie a reálnym zlepšením fungovania firmy. Ďalší kontext k prístupu na mieru prináša aj interný článok o rozdiele medzi custom a boxed softvérom.
