Programgranskning - Software review

Mjukvaruutveckling
Kärnverksamhet inom
mjukvaruteknik
Paradigmer och modeller
Metoder och ramar
Stödja discipliner
Övningar
Verktyg
Standarder och kunskapsorgan
Ordlistor
Konturer

En programvaruöversyn är "en process eller ett möte under vilket en mjukvaruprodukt granskas av projektpersonal, chefer, användare, kunder, användarrepresentanter eller andra intresserade parter för kommentarer eller godkännande".

I detta sammanhang betyder termen "mjukvaruprodukt" "alla tekniska dokument eller deldokument, framställda som leveranser av en programvaruutvecklingsaktivitet", och kan innehålla dokument som kontrakt, projektplaner och budgetar, kravdokument, specifikationer, konstruktioner, källkod, användardokumentation, support- och underhållsdokumentation, testplaner, testspecifikationer, standarder och andra typer av specialarbeten.

Varianter av programgranskning

Programvaruöversikter kan delas in i tre kategorier:

  • Programfackgranskningar utförs av en eller flera författarkollegor för att utvärdera det tekniska innehållet och/eller kvaliteten på arbetet.
  • Programhanteringsgranskningar utförs av ledningsrepresentanter för att utvärdera statusen för utfört arbete och för att fatta beslut om aktiviteter i senare led.
  • Programgranskningar görs av personal utanför programvaruprojektet för att utvärdera överensstämmelse med specifikationer, standarder, avtalsavtal eller andra kriterier.

Olika typer av peer reviews

  • Kodgranskning är systematisk undersökning (ofta som peer review ) av datorkällkod.
  • Parprogrammering är en typ av kodgranskning där två personer utvecklar kod tillsammans på samma arbetsstation.
  • Inspektion är en mycket formell typ av peer review där granskarna följer en väldefinierad process för att hitta defekter.
  • Walkthrough är en form av peer review där författaren leder medlemmar i utvecklingsteamet och andra intresserade går igenom en mjukvaruprodukt och deltagarna ställer frågor och kommenterar defekter.
  • Teknisk granskning är en form av peer review där ett team av kvalificerad personal undersöker programvarans produkts lämplighet för dess avsedda användning och identifierar avvikelser från specifikationer och standarder.

Formella kontra informella recensioner

"Formalitet" identifierar i vilken utsträckning en aktivitet styrs av överenskomna (skriftliga) regler. Programvaruprövningsprocesser finns över ett spektrum av formaliteter, med relativt ostrukturerade aktiviteter som "kompiskontroll" mot ena änden av spektrumet och mer formella tillvägagångssätt som genomgångar, tekniska granskningar och programvarukontroller, å andra sidan. IEEE Std. 1028-1997 definierar formella strukturer, roller och processer för var och en av de tre senaste ("formella peer reviews"), tillsammans med programvaruevisioner . IEEE 1028-1997 efterträddes av IEEE 1028-2008.

Forskningsstudier tenderar att stödja slutsatsen att formella granskningar överstiger informella granskningar i kostnadseffektivitet. Informella recensioner kan ofta vara onödigt dyra (på grund av tidsödande genom bristande fokus) och ger ofta en känsla av säkerhet som är ganska omotiverad av det relativt få antalet verkliga defekter som finns och repareras.

IEEE 1028 generisk process för formella granskningar

IEEE Std 1028 definierar en gemensam uppsättning aktiviteter för "formella" granskningar (med vissa variationer, särskilt för programvarurevision). Aktivitetssekvensen är till stor del baserad på den programvaruinspektionsprocess som ursprungligen utvecklades på IBM av Michael Fagan . Olika typer av granskningar kan tillämpa denna struktur med varierande noggrannhet, men all verksamhet är obligatorisk för inspektion:

  • 0. [Inmatningsutvärdering]: Granskningsledaren använder en standardchecklista med inträdeskriterier för att säkerställa att optimala förutsättningar finns för en lyckad granskning.
  • 1. Förberedelse av ledningen: Ansvarsfull ledning säkerställer att granskningen har tillräckliga resurser med personal, tid, material och verktyg och genomförs i enlighet med policyer, standarder eller andra relevanta kriterier.
  • 2. Planera granskningen: Granskningsledaren identifierar eller bekräftar granskningens mål, organiserar ett team av granskare och ser till att teamet är utrustat med alla nödvändiga resurser för att genomföra granskningen.
  • 3. Översikt över granskningsförfaranden: Granskningsledaren eller någon annan kvalificerad person säkerställer (vid ett möte om det behövs) att alla granskare förstår granskningsmålen, granskningsförfarandena, materialet som är tillgängligt för dem och förfarandena för att genomföra granskningen.
  • 4. [Individuell] Förberedelse: Granskarna förbereder sig individuellt för gruppundersökning av det arbete som granskas genom att noggrant undersöka det för "avvikelser" (potentiella defekter), vars karaktär kommer att variera med typen av granskning och dess mål.
  • 5. [Grupp] Undersökning: Granskarna träffas vid en planerad tidpunkt för att sammanställa resultaten av deras förberedelser och komma fram till enighet om statusen för det dokument (eller den aktivitet) som granskas.
  • 6. Omarbetning/uppföljning: Arbetsproduktens författare (eller annan tilldelad person) vidtar alla åtgärder som är nödvändiga för att reparera defekter eller på annat sätt uppfylla de krav som överenskommits vid provmötet. Granskningsledaren verifierar att alla åtgärder är stängda.
  • 7. [Utgångsvärdering]: Granskningsledaren verifierar att alla aktiviteter som är nödvändiga för framgångsrik granskning har genomförts och att alla resultat som är lämpliga för typen av granskning har slutförts.

Värdet av recensioner

Det mest uppenbara värdet av programgranskningar (särskilt formella granskningar) är att de kan identifiera problem tidigare och billigare än de skulle identifieras genom testning eller genom användning av fältet ("defektdetekteringsprocessen"). Kostnaden för att hitta och åtgärda ett fel genom en väl genomförd granskning kan vara en eller två storleksordningar mindre än när samma defekt upptäcks genom testkörning eller i fältet.

Ett andra, men ytterst viktigare, värde av programvaruöversyner är att de kan användas för att utbilda tekniska författare i utvecklingen av dokument med extremt låga defekter, och även för att identifiera och ta bort processbrister som uppmuntrar till defekter ("defektförebyggande process" ).

Detta är särskilt fallet för peer reviews om de utförs tidigt och ofta, på exempelprover, snarare än att vänta tills arbetet har slutförts. Tidiga och frekventa granskningar av små arbetsprover kan identifiera systematiska fel i författarens arbetsprocesser, som kan korrigeras innan ytterligare felaktigt arbete utförs. Denna förbättring av författarkunskaper kan dramatiskt minska den tid det tar att utveckla ett tekniskt dokument av hög kvalitet och dramatiskt minska felfrekvensen vid användning av dokumentet i nedströms processer.

Som en allmän princip, ju tidigare ett tekniskt dokument tas fram, desto större blir dess defekter på eventuell nedströms verksamhet och deras arbetsprodukter. Följaktligen kommer det största värdet att komma från tidiga granskningar av dokument som marknadsföringsplaner, kontrakt, projektplaner och scheman och kravspecifikationer. Forskare och praktiker har visat effektiviteten av att granska processen för att hitta buggar och säkerhetsproblem.

Se även

Referenser

År 2020 lanserades den första ärliga plattformen för granskning av programvara, https://Tekpon.com för att övertyga fler och fler plattformar om att generera riktiga recensioner från besökare, inte betalda. Om vi ​​accepterar falska recensioner köper vi produkter som vi inte vill ha