Jak napsat správnou analýzu webové aplikace rubrika: Návrh
1
Roman Gronych
Zdravím,
nejsem si jist, jak sem moje otázka patří, přesto to zkusím. Věřím, že jste se s tímto potýkali všichni, tedy: jak správně napsat technickou analýzu na webovou aplikaci. Každý jsme si tím prošli a každý píšeme analýzy svým způsobem. Jde mi o ideální metodologii, o TOP100 pravidel, která je záhodno dodržovat, aby byly splněny nejzákladnější podmínky, které tedy já cítím:
- aby zákazník věděl, co si od nás kupuje za dílo
- aby programátor věděl, jak to má pod tím představit a jak to udělat (nebo je třeba dle Vaší zkušenosti nezáhodno tyto 2 cíle kombinovat a pro zákazníka i programátora máte oddělené dokumenty?)
Existuje nějaká obecná metodologie psaní analýzy webových aplikací?
Několik mých nastřelených pohledů, kterými se obvykle zabývám
- použitá terminologie
- cíle projektu
- popsat z pohledu frontendu
- popsat z pohledu backendu
- procesy a USERCASES
- funkční požadavky
- záměrně neřešené oblasti
- ostatní požadavky zákazníka
- použitá technologie / HW
- systémové požadavky
- bezpečnost
- grafika
- import dat
- vazby na externí systémy
Díky za jakékoliv připomínky,
Roman
6
Filda
Nic jako správná analýza neexistuje. I ta nejlepší je zastaralá ve chvíli kdy analytik zmáčkne ctrl-s. Už jenom proto, že vetšina detailů vyplave na povrch až při implementaci a je potřeba některé věci měnit/doladit. Jenže nikomu se už nechce podepsanou a schválenou analýzu (většinou značně rozsáhlou) znovu číst a kontrolovat, takže se to řeší formou dodatků. Tím pak dochází k problémům s konzistencí, protichůdným požadavkům a nejasnostem. Protože "dokonalá" analýza by musela být stejně rozsáhlá jako kód programu sám. Největším problémem je totiž udržet konzistenci mezi analýzou a kódem.
V praxi se mi nejvíc osvědčil iterativní vývoj za pomoci user stories (US), což je jedna z mála dobrých věcí ve scrumu. Tyhle US jsou totiž čitelné jak pro zákazníka tak pro programátora a ideální je mít je ve spustitelném tvaru například jako BDD testy.
Není nic lepšího než mít seznam požadavků ve tvaru:
- libovolný návštěvník má možnost se registrovat
- uživatel má možnost přidat "článek"
-
funkce "hledání" odpoví nejdéle za 500ms
atd.
Z výsledků běhu lze poznat co už je hotovo a co ne, co je rozbité, na čem se ještě nezačalo pracovat a tak dále.
Nový požadavek se znovu zapíše jako takový test a velmi brzo se při implementaci pozná jestli je konzistetní se zbytkem systému, jestli nekoliduje s jiným požadavkem nebo například jestli už nebyl implementován jen tak mimochodem. Není totiž výjimkou, že systém dovede něco co nebylo plánováno.
Chápu, že zákazník chce vždy dopředu znát cenu, ale my neděláme rohlíky nebo židle, takhle vývoj software nefunguje.
Při iterativním vývoji můžeme zákazníkovi sdělit cenu za např. den práce celého týmu a pak třeba ve dnech estimovat US. To pomáhá při vytváření tlaku na správnou prioritu/pořadí US. Často se totiž stává, že se nejdřív implementují zelená tlačítka a řazení gridu než to aby to tlačítko správně fungovalo.
Ve výsledku bývá takový způsob vývoje levnější, protože se implementuje pouze ta funkcionalita, která je skutečně nezbytná k tomu aby aplikace měla přínos.
Pro zobrazení všech 10 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře