7. listopadu 2012

Jak snížit chybovost na projektu?

V dnešním článku se chci zamyslet nad tím, jak co nejlépe (= s minimem nákladů mít maximální užitek) snižovat chybovost během vývoje aplikace. Chyby dělá každý a kdo říká, že ne, tak nemluví pravdu.

Produkce chyb na softwarovém projektu je funkcí práce a velikosti projektu, takže je možné tuto produkci odhadnout. Jonesova data (Capers Jones) říkají, že typický projekt produkuje celkově asi 5 chyb (myšleno v celém vývojovém cyklu) na funkční celek, což znamená asi 50 chyb na 1000 řádků kódu. Čím větší projekt je, tím se výrazně zvyšuje i hustota chyb. (vybráno z knížky Odhadování softwarových projektů, Steve McConnell)
Existuje množství způsobů resp. postupů, jak ve všech fázích vývoje hledat a odstraňovat chyby. Následuje seznam těchto možností, který je seřazený sestupně podle efektivity, kterou definuji takto: nejefektivnější způsob detekce chyb je takový, který mi dokáže nalézt co nejvíce chyb s nejmenšími náklady - rychlým, jednoduchým způsobem, co nejdříve během vývoje.
  1. UML modelování - nejsem velkým zastáncem velkého modelování, ale na druhou stranu si nedovedu představit, že bych začal hned programovat aniž bych si cokoliv namodeloval. UML je standard, který usnadňuje komunikace uvnitř týmu i směrem k zákazníkovi. Obecně jakákoliv vizualizace usnadňuje komunikaci a vzájemné porozumění. Když modeluji, tak mi to umožňuje se na aplikaci dívat z různých pohledů a nutí mě to přemýšlet a tím eliminovat věci, na které zapomenu.
  2. prototypování - myslím zejména prototypování uživatelského rozhraní pomocí vhodných nástrojů, ale může být i třeba prototypování na úrovni serveru, modulu apod. ve smyslu proof-of-concept.
  3. revize návrhu - před samotným vývojem provést formální/neformální revizi návrhu celého řešení a výběru technologií
  4. jednotkové testování - nezbytná součást vývoje aplikace. Je nutné vhodně definovat úroveň testování, tak aby to bylo opravdu efektivní - vývoj produktu vs. vývoj jednorázové aplikace. V prvním případě bych se snažil o 70-80% pokrytí, u druhého případu by mi nevadily ani poloviční hodnoty.
  5. inspekce kódu během vývoje samotného vývoje - zde nepočítám jen týmové inspekce, ale často není od věci si projít a zkontrolovat svůj kód sám.
  6. integrační testování - "ověřování, že nově přidané funkcionality spolu nekolidují a pracují stejně jako během feature testů i po zaintegrování z jednotlivých vývojových větví do hlavního projektu" (viz wiki)
  7.  klasické lidské testování
Seznam možností není určitě úplný, uvedl jsem jen ty, které jsem někdy již použil nebo chci použít. Zajímalo by mě, jaký způsob preferujete vy?

3 komentáře:

Jan Novotný řekl(a)...

Já bych s uvedeným seznamem souhlasil - přesně podle něj se řídíme i my. Vidím jen trochu odklon od toho UML - mám zkušenost, že pokud na straně zákazníka není technik, nesetkávají se diagramy s žádným porozuměním. Pak děláme jen diagramy, které pomáhají nám = deployment diagram, component diagram, ERD. UC diagram je často jen popis bulletek ve wordu .

Guido řekl(a)...

Co mi tam chybí, je kontinuální integrace, jež defakto slučuje body 4 a 5 a dává jim novou kvalitu.

Upozornil bych na rozdíl prototyp a proof of concept (PoC). Byť se tyto termíny běžně zaměňují, je mezi nimi podstatný rozdíl - PoC nemusí skončit úspěchem (tj. nepodařilo se daný koncept prokázat). PoC tedy neslouží (primárně) k detekci chyb, ale k ověření, že "to vůbec půjde udělat".

Může se stát, že se pak PoC překlopí do prototypu a na něm už se budou odlaďovat chyby.

Petr Jůza řekl(a)...

S kontinuální integrací souhlasím, nějak mi to při tom přemýšlení nenapadlo.

S tím prototypováním jsem to nenapsal úplně nejlépe. Chtěl jsem říci, že řadu stěžejních technologických rozhodnutí je vhodné udělat co nejdříve než někdy během samotného vývoje zjistit, že je problém, a že něco nejde.