Recenze softwaru - Software review

Vývoj softwaru
Hlavní činnosti
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Praxe
Nástroje
Standardy a subjekty znalostí
Glosáře
Obrysy

A kontrola softwaru je „Proces nebo schůzka, během níž je softwarový produkt zkoumán pracovníky projektu, manažery, uživateli, zákazníky, zástupci uživatelů nebo jinými zúčastněnými stranami k vyjádření nebo schválení“.[1]

V této souvislosti pojem „softwarový produkt“ znamená „jakýkoli technický dokument nebo částečný dokument vytvořený jako výstup činnosti v oblasti vývoje softwaru“ a může zahrnovat dokumenty, jako jsou smlouvy, plány a rozpočty projektů, dokumenty s požadavky, specifikace, návrhy, zdrojový kód, uživatelská dokumentace, dokumentace podpory a údržby, plány zkoušek, specifikace zkoušek, normy a jakýkoli jiný typ speciálního pracovního produktu.

Odrůdy kontroly softwaru

Recenze softwaru lze rozdělit do tří kategorií:

  • Peer recenze softwaru jsou prováděny autorem pracovního produktu nebo jedním nebo více kolegy autora, aby vyhodnotili technický obsah a / nebo kvalitu díla.[2]
  • Recenze správy softwaru jsou prováděny zástupci vedení s cílem vyhodnotit stav odvedené práce a rozhodovat o navazujících činnostech.
  • Kontroly softwarového auditu jsou prováděny externími pracovníky softwarového projektu k vyhodnocení dodržování se specifikacemi, normami, smluvními dohodami nebo jinými kritérii.

Různé typy vzájemných hodnocení

  • Kontrola kódu je systematické zkoumání (často jako peer review ) zdrojového kódu počítače.
  • Párové programování je typ kontroly kódu, kdy dvě osoby vyvíjejí kód společně na stejné pracovní stanici.
  • Inspekce je velmi formální typ vzájemného hodnocení, kdy recenzenti sledují přesně definovaný proces hledání vad.
  • Návod je forma vzájemného hodnocení, kde autor vede členy vývojového týmu a další zúčastněné strany procházejí softwarovým produktem a účastníci kladou otázky a komentují závady.
  • Technická kontrola je forma vzájemného hodnocení, ve kterém tým kvalifikovaných pracovníků zkoumá vhodnost softwarového produktu pro jeho zamýšlené použití a identifikuje nesrovnalosti ve specifikacích a normách.

Formální versus neformální recenze

„Formálnost“ označuje míru, do jaké se činnost řídí dohodnutými (písemnými) pravidly. Procesy kontroly softwaru existují napříč spektrem formalit, s relativně nestrukturovanými činnostmi, jako je „kontrola kamaráda“ na jednom konci spektra, a formálnějšími přístupy, jako jsou návody, technické kontroly a kontroly softwaru, na straně druhé. IEEE Std. 1028-1997 definuje formální struktury, role a procesy pro každou z posledních tří („formální vzájemná hodnocení“) společně s softwarové audity.[1] IEEE 1028-1997 byl následován IEEE 1028-2008.[3]

Výzkumné studie mají tendenci podporovat závěr, že formální kontroly výrazně převyšují neformální kontroly v nákladové efektivnosti. Neformální kontroly mohou být často zbytečně nákladné (kvůli plýtvání časem kvůli nedostatečnému zaměření) a často poskytují pocit jistoty, který je poměrně neopodstatněný relativně malým počtem nalezených a opravených skutečných závad.

Obecný proces IEEE 1028 pro formální kontroly

IEEE Std 1028 definuje společnou sadu činností pro „formální“ kontroly (s některými variacemi, zejména pro softwarový audit). Sled činností je do značné míry založen na kontrola softwaru proces původně vyvinutý v IBM společností Michael Fagan.[4] Různé typy kontroly mohou tuto strukturu použít s různým stupněm přísnosti, ale všechny činnosti jsou pro kontrolu povinné:

  • 0. [Vstupní hodnocení]: Vedoucí kontroly používá standardní kontrolní seznam vstupních kritérií, aby zajistil optimální podmínky pro úspěšnou kontrolu.
  • 1. Příprava managementu: Odpovědné vedení zajistí, že kontrola bude mít odpovídající zdroje s personálem, časem, materiály a nástroji a bude prováděna v souladu se zásadami, normami nebo jinými příslušnými kritérii.
  • 2. Plánování kontroly: Vedoucí revize identifikuje nebo potvrdí cíle revize, zorganizuje tým recenzentů a zajistí, aby byl tým vybaven všemi nezbytnými prostředky pro provedení revize.
  • 3. Přehled kontrolních postupů: Vedoucí kontroly nebo jiná kvalifikovaná osoba zajišťuje (v případě potřeby na schůzce), aby všichni recenzenti rozuměli cílům kontroly, postupům kontroly, materiálům, které mají k dispozici, a postupům při provádění kontroly.
  • 4. [Individuální] Příprava: Recenzenti se individuálně připravují na skupinové zkoumání recenzované práce tím, že ji pečlivě zkoumají anomálie (potenciální vady), jejichž povaha se bude lišit podle typu kontroly a jejích cílů.
  • 5. [Skupinová] zkouška: Recenzenti se scházejí v plánovaném čase, aby shromáždili výsledky své přípravné činnosti a dospěli ke konsensu ohledně stavu dokumentu (nebo aktivity), který je přezkoumáván.
  • 6. Přepracování / následné kroky: Autor pracovního produktu (nebo jiná pověřená osoba) podniká jakékoli kroky nezbytné k opravě vad nebo k jinému splnění požadavků dohodnutých na zkušební schůzce. Vedoucí kontroly ověří, zda jsou všechny akční položky uzavřeny.
  • 7. [Hodnocení výstupu]: Vedoucí kontroly ověří, že byly dokončeny všechny činnosti nezbytné pro úspěšnou kontrolu a že byly dokončeny všechny výstupy vhodné pro daný typ kontroly.

Hodnota recenzí

Nejviditelnější hodnotou recenzí softwaru (zejména formálních) je, že mohou identifikovat problémy dříve a levněji, než by byly identifikovány testováním nebo použitím v terénu ( proces detekce vady)[Citace je zapotřebí ]. Náklady na nalezení a opravu defektu pomocí dobře provedené kontroly mohou být o jeden nebo dva řády nižší, než když je stejný defekt nalezen provedením testu nebo v terénu.[Citace je zapotřebí ]

Druhou, ale v konečném důsledku důležitější, hodnotou softwarových recenzí je, že je lze použít k proškolení technických autorů ve vývoji dokumentů s extrémně nízkými vadami, a také k identifikaci a odstranění nedostatků procesu, které podporují vady ( proces prevence závad).

To platí zejména pro vzájemné hodnocení pokud jsou prováděny brzy a často, na vzorcích práce, spíše než čekat na dokončení práce. Včasné a časté kontroly vzorků malé práce mohou identifikovat systematické chyby v pracovních postupech autora, které lze opravit před provedením dalších chybných prací. Toto zlepšení autorských dovedností může dramaticky zkrátit čas potřebný k vytvoření vysoce kvalitního technického dokumentu a dramaticky snížit chybovost při používání dokumentu v následných procesech.

Obecně platí, že čím dříve je technický dokument vytvořen, tím větší bude dopad jeho vad na jakékoli následné činnosti a jejich pracovní produkty. Největší hodnotu tedy získá časná kontrola dokumentů, jako jsou marketingové plány, smlouvy, plány a plány projektů a specifikace požadavků. Vědci a odborníci prokázali účinnost procesu kontroly při hledání chyb a bezpečnostních problémů.[5]

Viz také

Reference

  1. ^ A b IEEE Std. 1028-1997, „Standard IEEE pro softwarové recenze“, článek 3.5
  2. ^ Wiegers, Karl E. (2001). Peer Reviews in Software: A Practical Guide. Addison-Wesley. p. 14. ISBN  0201734850.
  3. ^ „Standard IEEE pro kontroly a audity softwaru“. IEEE Std 1028-2008: 1–53. 2008-08-15 [2008]. doi:10.1109 / IEEESTD.2008.4601584.
  4. ^ Fagan, Michael E: „Inspekce designu a kódu ke snížení chyb při vývoji programu“, IBM Systems Journal, Sv. 15, č. 3, 1976; "Kontrola softwarových návrhů a kódu", Datamace, Říjen 1977; "Pokroky v softwarových kontrolách", Transakce IEEE v softwarovém inženýrství, Sv. 12, č. 7, červenec 1986
  5. ^ Charles P. Pfleeger, Shari Lawrence Pfleeger. Zabezpečení ve výpočetní technice. Čtvrté vydání. ISBN  0-13-239077-9