Archives

Komunitnú zodpovednosť berieme naozaj vážne. Aktivity, pri ktorých sa venujeme študentom a učiteľom u nás prebiehajú celoročne. Aj preto sme si počas letných prázdnin dopriali aktívny oddych spolu s pedagógmi z SPŠT v Bardejove.

Keď sa nám pani zástupkyňa Mgr. Dana Janečková ohlásila, že ich škola má záujem s nami nadviazať spoluprácu, netušili sme, ako rýchlo sa to rozvinie. A naozaj, odtiaľ to bol už len krôčik od zostavenia oblastí potrebných pre náš projekt – implementáciu softvérového produktu pre ich štvrtákov študijného odboru Informačné a sieťové technológie, realizovaného projektovým riadením, vrátane agilných techník.

Pedagógovia na tejto škole majú výborné technologické znalosti, preto sme semináre zacielili na manažment produktu, špecifikáciu a sledovanie zmien, ako aj nástroje, ktoré toto všetko umožňujú. Ako prvú vec sme dohodli produkt. Prioritou bolo vymyslieť tému pútavú pre študentov. Voľba padla na zbieranie informácií o kvalite ovzdušia v triedach a ich zobrazovaní pri vstupe do školskej budovy. Vo vstupnej hale školy sa nachádza televízor, ktorý je využívaný ako monitor. K nemu je pripojený raspberry pi počítač. Práve ten bude slúžiť ako server pre celé riešenie.
Údaje budú zobrazované na web stránke práve na tomto spomínanom výstupnom zariadení. Takto poskytneme aktuálne informácie komukoľvek, kto bude vchádzať do budovy, či len prechádzať okolo.

Obr. 1. Ilustračný obrázok zo školenia pre učiteľov v priestoroch GlobalLogic Slovakia z Pre-COVID-19

Návrh web stránky, teda jej obsah a jeho rozloženie na obrazovke sme spoločne navrhli a implementovali počas prvých seminárov. Už počas prvých rozhovorov sa ukázala dôležitosť UX/UI na začiatku celého procesu.

Znalosti so spracúvaním údajov cez RESt API pomohli vytvoriť základný blok riešenia – architektúru. Pre serverovú časť sme spoločne zvolili jazyka Python a aplikačnú knižnicu (framework) Flask. MariaDB sme využili pre databázu – miesto pre kumulované údaje zo senzorov. Znalosti linuxu umožnili riešenie nasadiť na RPi. Stojí za zmienku, že všetok zdrojový kód si implementovali na vlastný gitlab server. S týmto sa museli popasovať asi najviac, keďže im skúsenosť s týmto nástrojom chýbala.

Celá implementácia bola v agilnom duchu, použili sme metódu scrum. Od seminára k semináru sme pridávali ďalšiu a ďalšiu funkcionalitu. Takto sme krok po kroku dopracovali celé riešenie. Cieľom však ostáva odovzdať toto všetko študentom. Tí na to budú mať čas do svojich maturít.

Hoci by si pedagógovia zaslúžili oddych, celé 2 mesiace sme mali utorkové rána spestrené touto aktivitou. To všetko sa konalo s cieľom pripraviť sa na tohtoročných maturantov a posunúť hĺbku ich znalostí ešte ďalej. Semináre zastrešil Ing. Tibor Radačovský.

Iniciatíva má samozrejme hlbší rozmer. Pedagógovia sú si vedomí, že technologicky sú na tom dobre. Avšak prax pre vytvorenie projektového plánu na softvérový produkt je oblasť, kde uvítali pomoc. Rovnako tak existujú mnohé nástroje, ktoré pri tejto práci vedia veľmi pomôcť, no doteraz o nich nepočuli a nemali teda skúsenosť s ich aplikáciou. Po týchto seminároch tak už budú vedieť, ktorým smerom posunúť študentov.

V GlobalLogic Slovakia si uvedomuje, že nestačí len očakávať, že študenti budú vedieť to, či ono. Vzdelávanie pedagógov je aktivita, ktorú veľmi aktívne podporujeme nie len priamo vo firme ale aj v rámci Košice IT Valley.

Veľké uznanie patrí pedagógom zo SPŠT Bardejov, konkrétne Mgr. Dana Janečková,
Mgr. Jakub Grohoľ a technickej podpore Peter Oláh.

Veľmi sa tešíme na ďalšiu spoluprácu.

Trendy v automobilovom priemysle, ako autonómne riadenie vozidla, konektivita V2X, OTA (Over The Air) aktualizácie, prediktívna údržba a mnoho ďalších inovatívnych funkcií, sú založené na softvérových funkciách vo vozidle. Aby všetky tieto funkcie fungovali bez problémov a v reálnom čase, musí každá jednotka vo vozidle (ECU – Electronic Control Unit) pracovať efektívne. Moderné vozidlá môžu mať viac než 100 ECU, ktoré navzájom komunikujú prostredníctvom zbernice CAN, LIN alebo ethernetovej siete.

Predtým neexistovala žiadna jednotná softvérová architektúra, ktorú by používali automobilový výrobcovia (OEM – Original Equipment Manufacturer) na návrh softvéru pre ECU. Takže vždy, keď chcel OEM prejsť na nového dodávateľa komponentov, bol tento prechod veľmi ťažký. Nový dodávateľ čelil obrovským výzvam pri pochopení existujúcej softvérovej architektúry, hardvérových platforiem a noriem používaných pri vývoji softvéru pre ECU. Preto bolo takmer nemožné, aby nový dodávateľ pokračoval v rozbehnutom projekte napríklad od polovice jeho výrobného cyklu.

S cieľom zefektívniť koordináciu medzi OEM výrobcami a ich dodávateľmi, zlepšiť kvalitu softvéru ECU a skrátiť čas a náklady na vývoj sa v roku 2003 spojili dodávatelia automobilového priemyslu, výrobcovia polovodičov, dodávatelia softvéru a nástrojov a vytvorili konzorcium s názvom AUTOSAR. Zakladajúcimi členmi boli BMW, Bosch, Continental, Daimler AG, Siemens VDO, a Volkswagen. Neskôr sa pridali Ford Motor Company, PSA Peugeot Citroen a Toyota Motor Corporation.

 

Čo je AUTOSAR?

AUTOSAR je otvorená a štandardizovaná softvérová architektúra pre automobilový priemysel, ktorá poskytuje štandardy pre vývoj softvérových aplikácií, zjednocuje rozhrania medzi aplikačným softvérom a základnými funkciami vozidiel a pomáha vytvárať spoločnú softvérovú architektúru ECU pre všetkých členov AUTOSAR konzorcia. Je to stále rastúci a vyvíjajúci sa štandard, ktorý definuje vrstvovú softvérovú architektúru. Najznámejší dodávatelia AUTOSAR riešení a vývojových nástrojov sú Vector, Elektrobit a ETAS.

AUTOSAR v konečnom dôsledku prináša výhody pri manažovaní  čoraz zložitejších elektrických/elektronických (E/E – Electric/Electronic) prostredí vo vozidle, ako je napríklad jednoduchá integrácia, zmena funkcií v rámci komplexnej sieti ECU a riadenie celého životného cyklu výrobku.

 

Architektúra AUTOSAR

Nižšie vysvetlená architektúra je tzv. klasická AUTOSAR verzia, ktorá podporuje vykonávanie funkcií v reálnom čase pričom berie do úvahy bezpečnostné obmedzenia. Klasický AUTOSAR je rozdelený do týchto 3 hlavných vrstiev (v poradí zhora nadol):

  • Aplikačná vrstva
  • AUTOSAR runtime prostredie (RTE)
  • Základný softvér (BSW)

Obr. 1.  AUTOSAR architektúra
Zdroj: https://circuitdigest.com/article/understanding-autosar-and-its-architecture

 

Aplikačná vrstva

Aplikačná vrstva je najvyššou vrstvou softvérovej architektúry AUTOSAR a podporuje implementáciu užívateľských funkcií a aplikácií na realizáciu konkrétnej funkcionality vozidla. Táto vrstva pozostáva z tzv. softvérových komponentov, ktoré vykonávajú špecifické úlohy podľa požiadaviek užívateľa a komunikujú medzi sebou a s BSW vrstvou pomocou RTE, čo znamená, že sú nezávislé od hardvéru, komunikačných zberníc a ostatných softvérových komponentov. 

Komunikácia medzi softvérovými komponentami je sprostredkovaná prostredníctvom portov virtuálnej funkčnej zbernice (VFB). Tieto porty tiež uľahčujú komunikáciu medzi softvérovými komponentami a základným softvérom AUTOSAR (BSW).

AUTOSAR Runtime Prostredie (RTE)

AUTOSAR Runtime prostredie je vrstva AUTOSARu, ktorá uskutočňuje komunikáciu medzi softvérovými komponentami v aplikačnej vrstve a BSW. Taktiež samotné softvérové komponenty komunikujú medzi sebou výlučne pomocou RTE, takže sú úplne nezávisle od ECU a ostatných softvérových komponent.

Základný softvér (BSW)

AUTOSAR základný softvér (BSW) vytvára abstrakciu medzi hardvérom a aplikačnou vrstvou. Skladá sa z desiatok softvérových modulov štruktúrovaných v rôznych vrstvách a tie sú rovnaké pre všetky AUTOSAR ECU. To znamená, že dodávateľ, ktorý navrhol konfiguráciu BSW, ju môže zdieľať s inými dodávateľmi, ktorí pracujú na inej ECU napríklad motora, posilňovača riadenia, alebo prevodovky.

BSW sa dá rozdeliť do troch rôznych vrstiev:

  • Servisná vrstva: Servisná vrstva je najvyššou vrstvou BSW a poskytuje základné služby (nezávislé na hardvéry) pre aplikačnú vrstvu. Komponenty v aplikačnej vrstve môžu pristupovať k týmto službám cez štandardizované AUTOSAR rozhrania. Servisná vrstva je zodpovedná za služby ako komunikačné služby, pamäťové služby, systémové služby na riadenie stavu ECU, diagnostické služby, operačný systém (OS) a ďalšie.
  • Abstraktná vrstva ECU: Hlavnou úlohou abstraktnej vrstvy ECU je spájať vrstvu MCAL a servisnú vrstvu. Vytvára abstrakciu pre prístup ku všetkým perifériám a externým zariadeniam ECU ako komunikácia, pamäť, I/O, tak aby API bolo nezávislé od hardvéru ECU (porty, registre, interné a externé zariadenia atď.).
  • Abstraktná vrstva mikrokontroléra (MCAL): MCAL je najnižšia vrstva BSW a priamo pristupuje k registrom a perifériám mikrokontroléra. MCAL je preto veľmi závislí od typu mikrokontroléra a obyčajne sa dodáva priamo jeho výrobcom. MCAL ponúka ovládače, ako komunikačné ovládače (CAN, LIN, ethernet), ovládače I/O, ovládače pamäte, ovládače systému a ďalšie.

Komplexný ovládač zariadenia (CDD)

Komplexný ovládač zariadenia (CDD) sa používa na implementáciu funkcionality mimo BSW, napríklad pre komplexné vyhodnocovanie senzorov, alebo ovládanie aktuátorov, ale najmä pre hardvér, ktorý nie je priamo podporovaný systémom AUTOSAR.

 

Adaptívny AUTOSAR

Od roku 2003 sa klasický AUTOSAR stal bežnou platformou a veľmi dobre sa mu darilo zrealizovať vozidlá s 60-80 ECU. Avšak, s postupom automobilových trendov založených na IoT, ako napríklad konektivita V2X a autonómna jazda, prudko stúpol počet funkcií vo vozidle a v dôsledku toho sa na trhu vytvoril obrovský dopyt po zariadeniach podporujúcich tieto funkcie. Zistilo sa, že existujúci klasický AUTOSAR nie je vhodný na podporu týchto nových trendov a vyžaduje sa nová architektúra s výkonnejšou a flexibilnejšou architektúrou E/E. Preto pre podporu týchto funkcií bola v Marci 2017 navrhnutá nová architektúra s názvom adaptívny AUTOSAR. 

Adaptívny AUTOSAR je škálovateľný a má dynamickú architektúru. Je vyvíjaný pomocou objektovo orientovaného programovacieho jazyka C++ na rozdiel od klasického AUTOSARu, ktorý je založený na programovacom jazyku C. Prichádza s centrálnym aplikačným serverom, ktorý pomáha s náročnými výpočtovými úlohami a taktiež plne podporuje ethernet, ktorý pomáha vykonávať funkcie v reálnom čase. Taktiež umožňuje nasadiť vo vozidle špičkové technológie ako je infotainment, V2X, prediktívna údržba, funkcie ADAS s kamerou, radarové a LIDAR senzory, aktualizácie máp a kedykoľvek ich bezdrôtovo aktualizovať.

 

Slovo na záver

AUTOSAR je navrhnutý tak, aby našiel využitie v rôznych oblastiach automobilového priemyslu. Ponúka množstvo výhod ako napríklad možnosť znovu použiť už existujúci softvér pre ďalšie ECU, a zároveň tento softvér môže byť opäť kedykoľvek nahradený iným. Ďalšou výhodou je, že poskytuje štandardizované rozhrania, čím zabezpečuje štandardizovaný spôsob vývoja softvéru vo vozidlách. AUTOSAR taktiež obsahuje OS so základnými funkciami, ktorý uľahčuje vývoj softvéru. Užívateľské funkcie sú realizované pomocou softvérových komponentov, ktoré sú nezávisle na hardvéri. Nový adaptívny AUTOSAR je pripravený na podporu nových technologií náročných na výpočtový výkon, takže všetko nasvedčuje tomu, že táto technológia má veľkú perspektívu aj do budúcnosti.

 

Referencie

  1. https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
  2. Oliver Scheid, AUTOSAR COMPENDIUM PART 1 – Application & RTE, Edition 1.0.2 based on AR4.0.3, 2015
  3. https://www.bosch-mobility-solutions.com/en/mobility-topics/ee-architecture/
  4. https://en.wikipedia.org/wiki/AUTOSAR
  5. https://circuitdigest.com/article/understanding-autosar-and-its-architecture

Cukrovka je veľmi trpkou súčasťou života diabetika. Jej neliečenie môže mať veľmi ťažké dôsledky na život pacienta. V súčasnosti väčšina pacientov s cukrovkou používa domáci glukomer, ktorý zmeria hladinu cukru v krvi z maličkej kvapôčky krvi. Spoločnosti pôsobiace na trhu diabetických pomôcok hľadajú a ponúkajú rôzne metódy, ako uľahčiť život pacientom. Prečítajte si článok, v ktorom sa dozviete ako sme nášmu zákazníkovi pomáhali vyvíjať softvér, ktorý zhromažďuje a organizuje informácie z glukomerov a inzulínových púmp a prevádza dáta do personalizovaných správ.

PREČíTAŤ ČLÁNOK

Aké sú najčastejšie aktivity a výstupy v Discovery fáze?

Discovery fáza popisuje, ako sa z nápadu stane jeho najlepšia možná verzia tak, aby sa na konci naše očakávania zhodovali s výsledným produktom. Ak chceme dosiahnuť čo najlepšie výsledky, mala by byť nevyhnutnou súčasťou vývoja projektu. Ktoré aktivity nám pomôžu k úspešnej realizácii Discovery fázy?

Tak ako sú etapy Discovery fázy konfigurovateľné podľa potrieb každého projektu, rovnaké je to aj s jednotlivými aktivitami a výstupmi, tzv. Deliverables. Medzi najčastejšie používané patria:

 

1. Definícia a rozhovory so zainteresovanými stranami. Zoznam obsahuje vlastníka produktu, členov tímu klienta (napr. marketing), investorov, koncových používateľov a každého, kto sa podieľa na vytváraní alebo používaní konečného produktu. Klient má však vždy konečné slovo.

2. Identifikácia obchodných cieľov. Stanovíme si hlavný cieľ nášho riešenia a identifikujeme problémy, ktoré je potrebné vyriešiť. Najrýchlejším spôsobom je usporiadanie workshopu s kľúčovými účastníkmi projektu. Hlavným účelom workshopu by malo byť: popísať súčasný stav, definovať požadovaný budúci stav a zosúladiť všetky zainteresované strany s víziou projektu.

3. Definovanie toho, ako merať úspech. Tím musí vedieť, aké má projekt stanovené ciele, aby sme mohli povedať, či bol úspešný. Sú dané jasné parametre, na základe ktorých rozhodujeme o čiastkových úspechoch. 

4. Kontrola dokumentácie a existujúceho prieskumu. Je potrebné preskúmanie marketingových artefaktov, ako napríklad aktuálnej marketingovej stratégie a metód, krátkodobých a dlhodobých merateľných cieľov, stratégie budovania značky a podobne. Ak už výsledky prieskumu existujú, a sú dostatočne validné, nie je potrebné robiť nový.

5. Kontrola existujúceho riešenia (ak existuje). V tomto kroku vykonáme technologický audit existujúceho riešenia (posúdime architektúru, použité technológie, výkon, stabilitu, identifikujeme vylepšenia, …), získame spätnú väzbu od klienta, analyzujeme funkcionalitu.

6. Identifikácia cieľovej skupiny a cieľov používateľov. Musíme pochopiť, kto sú koncoví používatelia. Musíme overiť, čo chcú a potrebujú. Čo radi robia? Koľko majú rokov? Sú technicky zdatní? Aké sú ich kľúčové problémy? Existuje mnoho rôznych metód, od rozhovorov so zákazníkmi, heuristiky a podobne. V tomto momente sa tvoria persóny.

7. Prieskum konkurencie. Pomáha nám nájsť silné a slabé stránky existujúcich riešení. Zahŕňa online aj offline riešenia, primárnu a aj sekundárnu konkurenciu.

8. Prieskum trhu. Zahŕňa online a offline výskum, publikácie špecifické pre dané odvetvie, predpokladané trendy a podobne.

9. Mapovanie cesty zákazníka. Keď už vieme, kto sú naši používatelia, musíme sa zamerať na úlohy, otázky a problémy, ktoré môžu mať. Jedným z najlepších spôsobov, ako to dosiahnuť, je práve tzv. Customer journey mapping. Ukazuje skúsenosti zákazníkov s používaním produktu, či už sú pozitívne alebo negatívne. Je to vizuálny prehľad fáz interakcie používateľa s produktom (čo robia, ako rozmýšľajú, ako sa cítia) a identifikácia príležitostí zodpovedajúcich obchodným cieľom (vízii).

10. Vytvorenie informačnej architektúry. Vytvára obraz o tom, ako všetky menšie časti systému do seba zapadajú a navzájom súvisia v rámci celého systému. Napriek zavádzajúcemu názvu je to úloha pre dizajnérov. 

11. Vytvorenie user flows. Označujú sled obrazoviek, ktoré sa zobrazujú používateľovi v rámci jedného vybraného scenáru.

12. Vytvorenie wireframes. Je to návrh aplikácie, ktorý zobrazuje prechody medzi obrazovkami a základnú logiku produktu. Znázorňuje tiež cestu používateľa (kam kliká počas používania). Ukazuje nám, ako bude riešenie fungovať.

13. Definovanie vizuálneho štýlu. Navrhneme vizuálnu stránku riešenia tak, aby bolo atraktívne a pútavé. Zvyčajne zahŕňa 2 až 3 možné varianty. Ukazuje nám, ako bude riešenie vyzerať.

14. Vytvorenie interaktívnych prototypov. Tieto realisticky demonštrujú všetky potrebné interakcie medzi systémom a používateľmi. Sú to vlastne simulácie alebo vzorky produktu, ktoré používame na získanie spätnej väzby. Môže ísť napr. o prelinkované (interaktívne) wireframes, alebo vizuálne navrhnuté obrazovky.

15. Napísanie špecifikácie riešenia. Agregované informácie transformujeme do zoznamu biznisových a technických požiadaviek. Ten zahŕňa aj funkcionálne a nefunkcionálne atribúty.

16. Napísanie technickej dokumentácie. Veľmi dôležitou súčasťou je dokument, ktorý podrobne popisuje všetky technologické a netechnologické požiadavky projektu, z ktorých bude vývojový tím neskôr vychádzať. Zahŕňa architektonický návrh a ďalšie technické špecifikácie. 

17. Odhadnutie rozpočtu a časovej osi. Všetky získané informácie dajú tímu dostatok vedomostí, na základe ktorých budú môcť odhadnúť čas a náklady potrebné na implementáciu.

18. Vytvorenie plánu. Výsledným dokumentom je projektový plán. Ten okrem iného obsahuje míľniky, plánované výstupy, termíny dodania čiastkových výsledkov, ako aj samotného finálneho produktu.

 

Pri vyššie spomenutých aktivitách je veľa artefaktov, ktoré vo výsledku tvoria jasný plán “čo, prečo, ako, ako dlho a za koľko” ideme vyvinúť. Najdôležitejšie z nich sú nasledovné výstupy z Discovery fázy:

  1. Špecifikácie (popis požiadaviek a technické špecifikácie, najmä architektúra)
  2. Dizajnový koncept (zahŕňajúci wireframes, dizajnový jazyk a prototypy)
  3. Prioritizovaný a odhadnutý list požiadaviek (tzv. backlog)
  4. Projektový plán

 

Slovo na záver

Stavba domu si vyžaduje pevné základy. Základom úspešnej realizácie projektu je práve Discovery fáza. Pomáha objasniť víziu projektu a minimalizovať riziká. Poskytuje tímu dostatočné informácie, aby realizoval projekt tak, ako to bolo zamýšľané. 

V  našich blogoch sme sa sústredili na opis procesu Discovery fázy, jej dôležitosť pri vývoji produktu a uviedli zoznam aktivít, ktoré vám pomôžu k jej úspešnej realizácii. 

Existuje veľa praktických cvičení a aktivít, ktoré prispejú k zvládnutiu Discovery fázy na jednotku. Ich popísanie by však zabralo zopár prednášok. 

Snažte sa presadiť, aby sa odteraz žiadny projekt nezačínal bez tejto fázy. Čas a peniaze tvoria zlomok jeho následnej realizácie. Zákazník bude spokojnejší, tím bude dosahovať výsledky rýchlejšie a kvalitnejšie a napokon, výsledný produkt bude stáť za to. 

 

Kto je súčasťou tímu pre Discovery fázu a ako dlho by mala ideálne trvať?

V Discovery fáze sa snažíme pochopiť víziu projektu, zhromaždiť čo najviac informácií, definovať požiadavky, priradiť priority, odhadnúť rozpočet a identifikovať možné riziká. Pre túto fázu je potrebný tím expertov, ktorí sa budú vzájomne dopĺňať.

Mnoho ľudí si predstavuje tím pre Discovery fázu zložený výlučne z dizajnérov. Či už sa jedná o špecialistu na prieskum trhu, vizuálneho dizajnéra, alebo dizajnéra zameraného na používateľské testovanie a podobne. Tento tím by mal však obsahovať nasledujúce roly:

  • Product Owner (Vlastník produktu). Osoba, zvyčajne zákazník, ktorá je “vlastníkom” vízie. Je hlavným spojivom medzi klientským tímom a tímom dodávateľa. Je jedinou a centrálnou osobou, ktorá komunikuje finálne rozhodnutia dodávateľskému tímu.
  • Projektový manažér. Je zodpovedný za celkové plánovanie a organizáciu Discovery fázy, zaznamenávanie všetkých podrobností diskutovaných počas stretnutí a zabezpečenie produktívnej spolupráce medzi klientom a vývojovým tímom.
  • Business Analyst (Analytik). Je spoluzodpovedný s dizajnérmi za prieskum a analýzu trhu, definovanie potrieb používateľov, ako aj za analýzu trhového potenciálu a ziskovosti produktu. Navyše definuje funkcionálne a nefunkcionálne parametre, a zlaďuje ich s obchodnými cieľmi a technickými možnosťami spolu s developermi.
  • Solution Architect (Architekt). Je zodpovedný za analýzu technologického riešenia, čo zahŕňa definíciu prostredia a výkonu, škálovateľnosti a údržby. Architekti tiež skúmajú riešenia a platformy tretích strán a odporúčajú ich použitie či nepoužitie v projekte.
  • Tech-Leads (Technologickí doménoví špecialisti). Komunikujú so zákazníkom, spolu s architektom definujú technické požiadavky na produkt, vytvárajú plán vývoja, určujú postupnosť krokov vývoja, stanovujú odhady, identifikujú riziká a poskytujú alternatívne technické riešenia.
  • UX/UI Designers (Dizajnéri). Zrejme najdôležitejší komponent tímu tvoria práve dizajnéri. Mohli by sme mať dokonalý produkt, ktorý je technologickou špičkou, avšak to nezaručuje, že bude mať aj trhový úspech. Dizajnéri sú zodpovední za vytváranie čo najlepšej používateľskej skúsenosti v súlade s cieľmi projektu. Produkt definujú tak, aby bol vizuálne atraktívny, ľahký na používanie a čo najlepšie vystihoval pôvodný zámer zákazníka. Niekedy sa tiež stane, že sa vízia produktu musí po ich zisteniach prehodnotiť, aby sa dosiahol čo najväčší úspech.

 

Znamená použitie Discovery fázy návrat k Waterfallu? Aká dlhá je táto fáza?

IT projekty majú svoj životný cyklus, ktorý zvyčajne delíme do piatich fáz: zahájenie (initiation), plánovanie (planning), realizácia (execution), kontrola (control) a ukončenie (closure). Discovery fázu teda môžeme chápať ako preklenutie priepasti medzi fázami zahájenia a plánovania projektu.

Discovery fázu je možné integrovať do rôznych metodík riadenia projektov, či už ide o Waterfall alebo Agile. Niektoré organizácie fungujúce na princípoch Agile tvrdia, že používanie Discovery fázy je návrat ku koreňom princípov Waterfall. Všetko sa najprv precízne naplánuje, napíše sa kompletná dokumentácia a vývoj sa začne až potom. Toto však nie je úlohou Discovery fázy. Ako bolo spomenuté vyššie, v tejto fáze ide o to, aby sa pochopila vízia projektu, jeho ciele a rozsah. V mnohom ide o hrubý náčrt, keďže dôležitejšie je víziu pretransformovať do takého zoznamu požiadaviek, ktorý splní stanovené ciele. Mnohé tímy dokonca majú svoje “malé” Discovery fázy ako začiatočnú etapu každého cyklu, ktorý sa končí uvedením novej verzie na trh.

V projektoch riadených metodikou Waterfall môže Discovery fáza zvyčajne trvať 4-12 týždňov, v závislosti od veľkosti projektu. Pri použití agilných metodológií, napr. Scrum alebo Kanban, priemerné časové odhady sú: pre malý projekt 1-5 dní, pre stredne veľký projekt 1-3 týždne a pre veľký projekt 3-6 týždňov, alebo viac.

 

Etapy Discovery fázy

Každý projekt je jedinečný, preto nasledujúce etapy Discovery fázy berte skôr len ako inšpiráciu:

  1.  Porozumenie
    • Vytvorí sa rovnaké chápanie. Zameriava sa na identifikáciu potrieb používateľov a ich zosúladenie s potrebami projektu. Klienti majú svoje vlastné ciele, ktoré chcú dosiahnuť – tie sa nie vždy sa zhodujú s cieľmi používateľov. Aby sme zaistili, že nami navrhované riešenie pokryje ciele oboch skupín, musíme skúmať obchodné aj používateľské ciele projektu.
    • Skúmame potreby používateľov. Mali by sme vykonať rozsiahly výskum, študovať riešenia konkurencie a najmä identifikovať skupiny typov našich používateľov (tzv. personas). Mali by sme byť schopní odpovedať na 3 otázky: Pre akých používateľov navrhujeme nás produkt? Aká je vízia môjho klienta? Aké sú kľúčové úlohy, ktoré chcú používatelia a klienti vyriešiť?
  2. Ideácia
    • Navrhovanie rôznych riešení. Vďaka znalostiam získaným v predchádzajúcej etape dokážeme navrhovať možné riešenia, definovať požiadavky, softvérovú architektúru, začať pracovať na náčrtoch funkcionality (tzv. wireframes), a určite aj nadviazať kontakt s potenciálnymi používateľmi, aby sme dostávali pravidelnú spätnú väzbu. V tomto okamihu nehovoríme o dobrých alebo zlých riešeniach, jednoducho experimentujeme a snažíme sa prísť s čo najlepším konceptom. Je to etapa skúšania – pokus a omyl. V tejto etape začneme hlasovať a vyberať najlepšie riešenia, najdôležitejšie funkcie.
    • Vytváranie prototypov a ich testovanie. Tým, že testovacej vzorke používateľov dáme peknú prezentáciu alebo vytlačené nákresy, nedokážeme pochopiť ich reakciu. Preto musíte nájsť pragmatický spôsob, ako premeniť svoje nápady na niečo “trochu skutočné”, čo nazývame prototypy. Prototypovanie je jednoduchým spôsobom, ako potvrdiť alebo vyvrátiť hypotézy (testovaním prototypov) sledovaním spätnej väzby používateľov.
  3. Rozhodovanie
    • Validácia nápadov. Po starom by to bolo: “To znie ako skvelý nápad, páči sa mi to! Poďme do toho!” Zmenené uvažovanie by malo byť: “Dokáž mi, že je to také skvelé, ako to opisuješ.” Validácia je o zvýšení dôvery v naše nápady. Pomôže nám rozhodnúť sa, či ich budeme realizovať alebo sa nimi nebudeme zaoberať. Dobrou metódou je tzv. Impact Mapping.
    • Finalizácia návrhu. Discovery fáza nie je lineárna, nejde od jedného kroku k druhému. Často sa stane, že musíme urobiť krok späť a vrátiť sa k predchádzajúcej etape a opraviť jej výstupy. Keď už máme všetky potrebné údaje, zoznam požiadaviek, informácie o výskume a podobne, sme pripravení urobiť potrebné rozhodnutie, ktoré nebude založené na pocitoch, ale dátach. V tomto okamihu sa tiež rozhodujeme, či investovať do pokračovania projektu, alebo je potrebné prehodnotiť celý projekt.

Na týchto etapách sa svojou prácou podieľa celý tím a spoločne sa snaží dospieť k čo najlepšiemu finálnemu návrhu. To, aké benefity prináša úspešne absolvovanie týchto etáp discovery fázy, si môžete prečítať v našom prechádzajúcom blogu. Ak vás zaujíma, aké aktivity a výstupy sú súčasťou Discovery fázy, tak si nenechajte ujsť ďalšie pokračovanie článku.

Aké výhody získame, ak je Discovery fáza súčasťou projektu?

V predchádzajúcom blogu sme načrtli, čo je Discovery fáza a ako to môže dopadnúť, ak ju v procese vývoja projektu vynecháme. Povedzme si teraz, prečo ju môžeme nazvať nielen prvou, ale zároveň aj najdôležitejšou fázou vývoja. Aké benefity nám prináša?

Discovery je fázou intenzívneho výskumu na začiatku každého projektu s cieľom definovať jeho rozsah. Existuje však aj iný uhol pohľadu. Je to spôsob, ako odstrániť alebo minimalizovať neistotu. Bez Discovery fázy by jej eliminácia znamenala to, že by sme museli formulovať množstvo predpokladov. Počas vývoja je ich však veľmi nákladné opraviť a hľadať lepšie riešenia. Čiže sa buď zmierime s horším produktom, alebo navýšime náš rozpočet. Inak povedané, je dôležité nemať neistotu pred začatím fázy vývoja.

Pozrime sa na výhody Discovery fázy:

  • Prináša lepšie riešenia. Keď tím pochopí pozadie projektu, môže navrhnúť alternatívne riešenia, ktoré sú často lepšie alebo lacnejšie ako tie, ktoré navrhuje klient. Zároveň sa možným zapojením kreativity dosiahne vyššia motivácia tímu pracovať na projekte.
  • Znižuje riziká a zvyšuje návratnosť investícií. Lepšie pochopenie a definovanie rozsahu a cieľov projektu pomôže tímu presnejšie odhadovať potrebný čas a prostriedky. Nielen to, odhaľuje aj potenciálne riziká, ktoré by mohli projekt neskôr ohroziť. Vypracuje sa plán pre mitigáciu týchto rizík, čo zabráni nákladným a nepredvídaným zmenám na projekte počas jeho vývoja.
  • Identifikuje elementy úspešného produktu. Je nevyhnutné nielen načrtnúť ciele projektu, ale aj definovať, koľko z nich bude postačovať na dosiahnutie úspešného výsledku. Možno sa ukáže, že stačia len dve tretiny z vytýčených cieľov na pokrytie počiatočných požiadaviek. Tým sa optimalizujú a znížia náklady na projekt.
  • Zaistí rovnaké pochopenie aspektov projektu. Vízii projektu musí každý rozumieť tak, aby sa dosiahol želaný výsledok. Na druhej strane aj klient by mal jasne chápať, čo všetko je potrebné na jeho realizáciu. Mal by poznať dopady zmien, ktoré by alternatívne riešenia mohli priniesť. Otvorenou diskusiou sa odstránia nedorozumenia. Rozhodovanie sa deje na základe údajov a nie predpokladov. Takouto transparentnosťou sa zabezpečí dôvera medzi zákazníkom a tímom.
  • Prináša vytvorenie plánu. Ak máme definovanú víziu a súbor požiadaviek, dokážeme vytvoriť plán, ktorý sa dodrží ľahšie s menším počtom nečakaných zmien. Technická špecifikácia a dizajnové prototypy zabezpečia potvrdenie uskutočniteľnosti projektu. Získame časovú os projektu s predbežnými cieľmi, výsledkami a termínmi priebežných dodávok.
  • Zapája najlepších odborníkov. Keďže ide o fázu, ktorá je krátka, môžeme zapojiť interných špecialistov, aby sa maximalizovala pravdepodobnosť nájdenia najlepšieho riešenia. Niektorí z nich budú tvoriť kostru budúceho projektu.

Výhody Discovery fázy sú preukázateľné na reálnych projektoch. Mnohé tímy, ktoré ju nezahrnú do svojho vývoja, predĺžia svoj projekt oproti plánu viacnásobne, keďže zanedbali potrebnú technickú analýzu.

Niektoré z nich projekt ani nedokončia, buď im dojdú peniaze, alebo zvolili také riešenie, ktoré je nerealizovateľné. Kým len 7% projektov je dodaných neskoro, až 45% prekročí odhadovaný rozpočet. 17% projektov dokonca spôsobí krach spoločnosti. 9 z 10 startupov zlyhá, pretože ich riešenie nie je vhodné pre trh. A to neberieme do úvahy tvrdú konkurenciu, kde sa toto riešenie musí presadiť. Príklady projektov, ktorých súčasťou bola Discovery fáza, nám ukazujú, že končia omnoho úspešnejšie ako tie bez nej. Úspešnosť Discovery fázy ovplyvňuje vo veľkej miere aj tím a ľudí, ktorí sú jeho súčasťou. Chcete vedieť, kto tento tím tvorí? Prečítajte si ďalšiu časť blogu.

Poznáte ten pocit, to zvláštne nadšenie, keď vám na stole pristane nový projekt. V hlave máte kopec nápadov, už si predstavujete, s ktorými kolegami budete spolupracovať, rozmýšľate, ako zlepšíte projektové procesy… Jednoducho sa neviete dočkať, kedy sa to celé konečne začne. Ste si istí, že tentoraz to bude konečne dobré, máte už predsa množstvo skúseností. Chcete sa do práce pustiť okamžite.

Existuje mnoho dôvodov, prečo sa vrhneme priamo na projekt a vynecháme dôležitú fázu výskumu pred jeho začiatkom. Sme nadšení a veríme, že vieme dosť a máme všetko potrebné na to, aby sme začali. Ak sa aj niečo pokazí, povzbudzujeme sa, že sa veci “nejako” dajú samy do poriadku alebo máme pocit, že úvodný výskum je príliš veľký a zbytočný luxus, ktorý si nemôžeme dovoliť. Čo teda robiť, ak chceme byť úspešní? Čoraz častejšie počúvame o tajomnej prísade, nazývanej Discovery fáza. Preklenuje priepasť medzi nápadom a jeho následnou realizáciou.

Je táto fáza naozaj odpoveďou na všetky problémy, ktoré môžu nastať vo vývoji projektu? Určite nie. Stále je potrebné mať dobrý nápad, skúsený tím na jeho realizáciu a musí “do seba zapadnúť” kopec iných vecí. Avšak príklady projektov, ktorých súčasťou bola Discovery fáza, nám ukazujú, že končia omnoho úspešnejšie ako tie bez nej. Prečo teda neponúknuť klientovi krátku fázu, ktorá neohrozí jeho rozpočet, a naopak, prinesie kopec benefitov? Prečo radšej nenájdeme odpovede na zásadné otázky predtým, než začneme investovať nielen čas ale aj peniaze do projektu? Ani do stavby domu sa nepustíme bez jasného plánu, alebo aspoň plánu s hrubými črtami a potrebnými povoleniami.

 

Čo je to Discovery fáza a čo sa môže stať, ak ju vynecháme?

Už samotný názov “Discovery fáza”, resp. “fáza objavovania” vyvoláva dojem, že sa môže ísť o zbytočný luxus. Možno by príhodnejším názvom bola “Prípravná fáza”. Akokoľvek sa rozhodneme túto fázu nazývať, je prvou a najdôležitejšou vo vývoji projektu. Počas nej sa snažíme pochopiť víziu projektu, zhromaždiť čo najviac informácií, definovať požiadavky, priradiť priority, odhadnúť rozpočet a identifikovať možné riziká. Inými slovami, vytvárame cestovnú mapu (tzv. roadmap), ktorá popisuje, ako sa z nápadu stane jeho najlepšia možná verzia tak, aby sa na konci naše očakávania zhodovali s realitou. Zároveň určíme najideálnejšie kroky, ako zámer docieliť.

Práve počas discovery fázy sa snažíme identifikovať to, čo nás odlíši od konkurencie. V podstate sa snažíme odpovedať na:

  • Súčasný stav: Čo už existuje na trhu? Čo už máme my? Aké rôzne verzie sú už dostupné?
  • Identifikovaná príležitosť: Čo ešte neponúkame? Čo chýba používateľom? Aký je problém, na ktorý by sme mali nájsť riešenie? Akú pridanú hodnotu to prinesie? Sústreďujeme sa na správnu oblasť? Čo je naša vízia
  • Plánovaný požadovaný budúci stav: Aký nový produkt prinášame? Aké vylepšenie chceme dosiahnuť? Ako vieme, že sme to dosiahli? Čo ďalej, aké budú naše ďalšie kroky?

Inými slovami, identifikujeme obchodné príležitosti, ktoré sú odpoveďou na túžby a potreby koncových používateľov. Tým, že pochopíme ich požiadavky, vieme zostaviť plán ako ich naplniť.

Ak by sme sa rozhodli začať projekt bez tejto fázy, môžeme očakávať nasledovné:

  • Výsledný produkt nebude odpovedať našim pôvodným očakávaniam. Chýbajúca, nedostatočná, alebo nesprávna komunikácia vedie k rôznemu pochopeniu, či dokonca nepochopeniu vízie. Výsledkom je niečo, čo je iba priemerné, z čoho sme sklamaní, čo zapadne medzi ostatné produkty.
  • Rastúce náklady. Bez jasných cieľov, s neustále sa meniacou stratégiou a novými požiadavkami vzniká potreba predlžovania projektu, prerábanie už dokončených vecí, výmenu frustrovaných členov tímu. Peniaze sa minú skôr, než tím vyvinie aspoň použiteľný, spolovice hotový produkt.
  • Zmeškané termíny. Klienti sa často snažia radšej navýšiť rozpočet, len aby sa dodržali termíny. Na konkurenčnom trhu sa zmeškané termíny totiž rovnajú obrovským obchodným stratám. Inou možnosťou je “zmenšiť víziu”, čiže vyvinúť minimalistickú verziu pôvodného produktu.

V týchto riadkoch sme si načrtli, prečo by mala byť Discovery fáza súčasťou každého projektu. Vieme už, prečo ju považujeme za nesmierne dôležitú a kľúčovú pre projekt. Zároveň sme zhodnotili, aké dôsledky má vynechanie tejto fázy. Môže to mať vplyv nielen na výsledný produkt, ale aj na prácu ľudí, ktorí sú súčasťou projektu a v neposlednom rade aj na financie. Ak vás zaujíma, aké ďalšie benefity nám prináša discovery fáza, prečítajte si druhú časť nášho blogu.

V automobilovom priemysle prebieha už dnes technologická revolúcia. Budúcnosť bude patriť čoraz viac autonómnym autám, ktoré budú postupne vyžadovať menej a menej aktívnej pozornosti vodičov. Už v súčasnosti ponúkajú autá množstvo funkcií, ktoré pomáhajú ľahšie a bezpečnejšie šoférovať.

Prečítajte si zaujímavý článok, v ktorom sa dozviete, akým smerom napreduje vývoj v automobilovom priemysle a na čom pracujú naše tímy.

PREČíTAŤ ČLÁNOK