Jak napsat správnou analýzu webové aplikace rubrika: Návrh

1 Roman Gronych
položil/-a 12.7. 15:34

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:

  1. aby zákazník věděl, co si od nás kupuje za dílo
  2. 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

odkaz
8 Filda
odpověděl/-a 17.7. 13:23

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.

Komentáře

  • arron : To je totiž děsně good point, my neděláme sériovou výrobu, kde má každý kus svojí standardní cenu a dobu dodání...když to přirovnám k autům, tak nevyrábíme standardní škodovku jednu za druhou, ale vymýšlíme úplně nový model. Jasné, víme, že bude mít čtyři kola, motor, volant a tak a že ty kola budou kulatý, ale to je tak všechno. Těžko se na něco takovýho bude dělat fix price, že jo. Stejně tak, když uděláme nějaké dveře a klientovi se nebudou líbit, tak se prostě musí zahodit a musí udělat nové. To ale není jednoduchá úprava a klient jí prostě musí zaplatit. Nebo motor...člověk bude měsíc (to je fuk jak dlouho, že jo) vyvíjet benzínový čtyřválec, ale klient sis pak vzpomene, že chce dieslový šestiválec. Dovedete si představit, že by u toho motoru klient řekl, že to nezaplatí?? Těžko...ale u SW to dělají normálně. Zlatou medaili tomu, kdo tohle těm klientům bude umět vysvětlit tak, aby to fakt pochopili!! 17.7. 14:09
  • Tomáš Tintěra : @aaron Je to o tom nakolik děláme vývoj a nakolik N tou variaci jakéhosi řešení. Třeba rodinné domy jsou také každý originál a přesto jde předem stavbu nacenit poměrně podrobně. Horší už je to s projektem. Tam je obvyklá fix-price na určitý typ stavby. Protože tam už položky těžko specifikovat. V SW by tomu mohl odpovídat e-shop na míru (víme co děláme, n-tá iterace) a analýza (fix price). 17.7. 18:10

Pro zobrazení všech 10 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.