Vyvíjíme převážně na platformách Java, JEE a v jazycích C/C++.
Zaujala Vás naše nabídka? Chcete se dozvědět více? Napište nám na
algomica@algomica.cz
NEŽ ZAČNEME SPOLEČNĚ VYVÍJET SOFTWARE
Než se spustí vlastní vývoj softwaru, je třeba mít alespoň hrubou představu, co výsledný software má dělat a jaké požadavky má splňovat. Zde demonstrujeme náš typický postup při úvodním sběru požadavků a specifikaci softwaru. Tento postup uplatňujeme hlavně pro zákazníky, kteří nemají dostatečné technické zázemí, aby tyto úvodní kroky mohli zvládnout sami.
Sběr požadavků
Během úvodních diskusí se zákazníkem se snažíme zjistit jeho potřeby a očekávání vzhledem k softwaru. V této fázi se také snažíme zorientovat v doméně a terminologii zákazníka – učíme se mluvit jeho jazykem.
Výsledkem naší společné snahy je soubor jednoduchých požadavků na funkci softwaru – Funkční požadavky. Umožňují nám jako výrobci softwaru základní orientaci v potřebách zákazníka a představují jakýsi most mezi prostředím a terminologií zákazníka a prostředím vývoje software.
Pokud má zákazník jasnější představu o způsobech použití budoucího software, popíšeme tzv. případy užití (neboli Use cases). Jedná se o scénáře popisující kroky při určitém způsobu použití softwaru. Pomáhají nám ujasnit si, jakým způsobem chce zákazník software používat a co by měl splňovat, aby byl pro zákazníka užitečný.
Funkční specifikace
Po úspěšném sběru požadavků na software a jejich analýze, můžeme přikročit k sepsání funkční specifikace. Je to detailní popis, jak má software fungovat, ovšem bez vazby na konkrétní technologii či detailní architekturu systému. Při sepisování funkční specifikace je třeba vzít v úvahu následující oblasti:
1) Datový model – formální popis dat a informací v systému a vztahy mezi nimi. Při popisu dat se snažíme používat zákazníkovi srozumitelnou formu.
2) Popis funkčností – zjednodušeně se jedná o popis toho, co má software s daty uvedenými v bodu 1) provádět a jak se mají data v závislosti na prováděných akcích měnit.
3) Interakce s dalšími systémy – i ty nejjdednoduší samostatné aplikace umožňují importy a exporty dat. Složitější informační systémy je pak třeba integrovat s dalšímy existujícími systémy. Je proto třeba popsat interakci a výměnu dat s dalšími systémy a softwary, protože pokud je taková interakce vyžadována tak její implementace obvykle tvoří značnou část úsilí vynaloženého na vývoj softwaru.
4) Role a oprávnění – funkčnost, kterou software nabízí uživateli může záviset na tom, kdo je aktuálně k systému přihlášen. Je třeba definovat, co kdo může a za jakých podmínek v systému vykonávat – tedy uživatelské role a uživatelská práva.
5) Uživatelské grafické rozhraní – popis, jak by mělo vypadat uživatelské rozhraní tak, aby umožnilo uživateli všechny akce popsané v bodu 2). Může obsahovat i grafické návrhy včetně rozvrženi jednotlivých prvků. Toto je oblast kde obvykle mají i netechničtí zákazníci poměrně jasnou představu jak by měl systém fungovat.
6) Funkčnost uživatelského rozhraní – co všechno by mělo umět uživatelské rozhraní, aby uživateli umožnilo efektivní a pokud možno příjemnou práci se softwarem. Jedná se především o různé druhy filtrování, třídění, vyhledávání, scrolování či stránkování většího množství položek, drag and drop. Pokud jsou požadavky na bohatou funkčnost uživatelského rozhraní znamená to zvýšené náklady na vývoj, proto je třeba dobře zkokumentovat zákazníkovu představu o úrovni konmfortu grafického rozhraní předem.
7) Lokalizace aplikace – velmi často se naši zákazníci pohybují v mezinárodním prostředí. V takovém případě je třeba počítat s tím, že budeme vyvíjet vícejazyčný software. Pokud se software vyvíjí od počátku jako vícejazyčný znamená to pouze minimální náklady navíc. Oproti tomu přidat další jazykovou mutaci do softwaru u něhož se s takovou možností předem nepočítalo může být dost nákladné.
8) Tisk – u většiny softwaru platí, že uživateli umožňují nějaký tiskový výstup. U toho je třeba učit formát, obsah a grafickou formu, podobně jako u uživatelského rozhraní.
9) Reporty – poměrně častým požadavkem bývá nějakým způsobem zjistit, co se za určité časové období v systému odehrálo, jak jsou ti či oni uživatelé aktivní. Typicky to znamená generovat přehledové dokumenty, často v závisloti na oprávněních uživatele. Občas jsou pravidla pro generování reportů hodně složitá a ve spojení s rozsahem dat potom vznikají problémy s rychlostí a výkonem aplikace.
10) Uzávěrky – především u aplikací zaměřených na finance je třeba zvážit požadavky na různé denní, měsíční uzávěrky. Takové uzávěrky typicky probíhají noci, kdy uživatelé se systémem nepracují. Během specifikace je třeba všechny takové pravidelné a automatické úlohy identifikovat a popsat.
11) Výkon aplikace – u vyvíjené aplikace je třeba zvážit nejen prostou funkcionalitu, ale také potřebnou rychlost aplikace při zátěži. Někdy se stává, že aplikace funguje dobře pro určitý počet uživatelů, ale při větší zátěži se zpomalí natolik, že se stává obtížně použitelnou. Pokud máte zvláštní nároky na počet uživatelů či objemy zpracovávaných dat v uzávěrkách a při generování reportů je třeba tyto požadavky také uvést ve specifikaci.
Na základě funkční specifikace jsme schopni připravit kvalifikovaný odhad náročnosti softwaru. Funkční specifikace slouží jako základ smluvního vztahu při vývoji softwaru. Alternativně může být součástí tohoto vztahu i technická specifikace (viz další krok).
Technická specifikace
Následuje sepsání technické specifikace, což je popis konkrétního technického řešení funkční specifikace. Technická specifikace obsahuje návrh architektury systému a jeho jednotlivých částí, volbu konkrétních technologií. Technická specifikace již obsahuje naše know-how a specifická technická řešení. Technická specifikace obsahuje řadu odborných termínů a nemusí tak být srozumitelná pro laiky.
Zatímco u funkční specifikace obvykle umožňujeme aby ji případně zákazník po zaplacení použil pro vývoj u jiné firmy, technická specifikace je důvěrným dokumentem mezi námi a naším zákazníkem.
Po uzavření smluvního vztahu o vývoji softwaru (jehož podstanou část tvoří obě výše uvedené specifikace) následuje vlastní vývoj softwaru.