Mylné představy o vývoji informačních systémů

Mylných představ ohledně vývoje informačního systému existuje poměrně dost. Pro ilustraci uvádím několik takových představ z praxe i s komentářem:

1) "Analýzu nepotřebujeme, víme co chceme, dodáme naprosto jasné zadání."
Příklad naprosto jasného zadání: "Systém pro podporu procesu XYZ." Zadavatelé vědí, co daný proces řeší a jak. Možná  mají proces nějakým způsobem popsaný a mají obecnou představu, co by měl podporovat budoucí informační systém. Pro vývoj informačného systému je ovšem potřeba přesná specifikace. Většinou stačí několik konkrétních otázek a analytik zjistí, že naprosto jasné zadání není jasné ani zadavatelům.
                                                                   
2) "Na analytické schůzky nemáme čas, potřebujeme to dodat co nejdřív."
I na tento přístup lze narazit. Zadavatelé si nemají čas "jen tak povídat" o tom co by měla aplikace dělat. Je třeba začít co nejdřív programovat, aby se vše včas stihlo. Důležité je, zda je hlavním problémem vytížení zadavatelů požadavků jinou prací, nebo je problém ve velmi krátkém termínu dodání. V případě, že zadavetelé nemají čas, je třeba, aby si zadavatelská firma jasně určila priority - tedy zda je důležitější nový systém nebo něco jiného. V případě velmi krátkého termínu dodání je třeba rychle určit, co je kritická funkcionalita, kterou je potřeba do určeného termínu zanalyzovat a nasadit.

3) "Zpracování požadavků trvá zbytečně moc dlouho, vždyť je to úplně jednoduché.
Zadavatelé požadavku obvykle neznají všechny důsledky požadované změny. Například z pohledu uživatelského rozhraní může změna vypadat velmi jednoduše. Tato změna ale může mít dopady do dalších částí systému, může vyžadovat obsáhlé testování, migraci dat, integraci s ostatními systémy. Požadovanou změnu také obvykle není možné nasadit kdykoliv, obvykle se změny nenasazují po jedné, ale ve větších celcích. Proto může zdánlivě jednoduchá změna trvat dlouho.
                                         
4) "Požadavek je třeba nasadit co nejdřív a když to nebude fungovat, tak se to pak nějak upraví."
Ano, takto to může fungovat. Otázka je jaké chyby v tomto případě mohou nastat, jaké mohou být jejich důsledky a co budeme dělat, pokud nastanou. Pokud jde například systém pro řízení jaderné elektrárny, tento přístup bych nepoužil.        

5) "Musíte nám zaručit, že to bude na 100% bez chyb."
Zaručit, že v software není na 100% žádná chyba nelze. Ano, testováním lze pravděpodobnost chyby snížit. Čím déle testování probíhá, tím méně chyb testeři objeví - náklady na objevenou chybu tedy časem stoupají, pravděpodobnost neodhalené chyby klesá. Obvykle je rozumné testování v určité fázi ukončit, protože náklady by při pokračujícím testování byly příliš vysoké a doba do dodání systému příliš dlouhá.

6) "Nevíme co přesně budeme potřebovat, proto chceme, aby byl systém plně parametrizovatelný."
Často si zadavatelé nejsou jisti zadáním. Ví co potřebují nyní, neví co budou potřebovat v budoucnu. Raději tedy udělejme vše parametrizovatelné, ať to jde jednoduše změnit. Není to špatný nápad, jediný problém je cena a čas. Pokud bude vše parametrizovatelné, bude systém universálněji použitelný, ale bude výrazně dražší a jeho vývoj bude trvat déle.  

7) 14 dní před nasazením "Potřeboval bych ještě jednu drobnou úpravu ..."
Zadavatel často nechápe, že 14 dní před nasazením je (obvykle) skoro vše hotovo. Probíhá  testování, opravují se poslední chyby. Drobná úprava z hlediska zadavatele požadavků může mít rozsáhlé dopady do vyvíjeného systému.