Przegląd oprogramowania

Przegląd oprogramowania to „proces lub spotkanie, podczas którego oprogramowanie jest badane przez personel projektu, kierowników, użytkowników, klientów, przedstawicieli użytkowników lub inne zainteresowane strony w celu uzyskania komentarza lub zatwierdzenia”.

W tym kontekście termin „oprogramowanie” oznacza „dowolny dokument techniczny lub dokument częściowy, wytworzony jako produkt końcowy działalności związanej z tworzeniem oprogramowania” i może obejmować dokumenty, takie jak umowy, plany i budżety projektów, dokumenty dotyczące wymagań, specyfikacje, projekty, kod źródłowy, dokumentację użytkownika, dokumentację wsparcia i konserwacji, plany testów, specyfikacje testów, standardy i wszelkie inne specjalistyczne produkty pracy.

Odmiany przeglądu oprogramowania

Recenzje oprogramowania można podzielić na trzy kategorie:

Recenzje oprogramowania są przeprowadzane przez jednego lub więcej współpracowników autora w celu oceny zawartości technicznej i/lub jakości pracy.
Przeglądy zarządzania oprogramowaniem są przeprowadzane przez przedstawicieli kierownictwa w celu oceny stanu wykonanej pracy i podjęcia decyzji dotyczących dalszych działań.
Przeglądy audytu oprogramowania są przeprowadzane przez personel spoza projektu oprogramowania w celu oceny zgodności ze specyfikacjami, standardami, umowami lub innymi kryteriami.

Różne rodzaje recenzowania

Przegląd kodu to systematyczne badanie (często jako przegląd wzajemny ) kodu źródłowego komputera.
Programowanie w parach to rodzaj przeglądu kodu, w którym dwie osoby wspólnie opracowują kod na tej samej stacji roboczej.
Inspekcja jest bardzo formalnym rodzajem wzajemnej oceny, w ramach której recenzenci postępują zgodnie z dobrze zdefiniowanym procesem w celu znalezienia defektów.
Przewodnik jest formą wzajemnej recenzji, w której autor prowadzi członków zespołu programistów i inne zainteresowane strony przeglądają oprogramowanie, a uczestnicy zadają pytania i zgłaszają uwagi na temat defektów.
Przegląd techniczny jest formą wzajemnej oceny, w której zespół wykwalifikowanego personelu bada przydatność oprogramowania do zamierzonego zastosowania i identyfikuje rozbieżności ze specyfikacjami i standardami.

Przeglądy formalne i nieformalne

„Formalność” określa stopień, w jakim czynność podlega uzgodnionym (pisemnym) regułom. Procesy przeglądu oprogramowania obejmują całe spektrum formalności, ze stosunkowo nieustrukturyzowanymi czynnościami, takimi jak „sprawdzanie przez znajomych” na jednym końcu spektrum, i bardziej formalnymi podejściami, takimi jak instruktaże, przeglądy techniczne i inspekcje oprogramowania, na drugim. standard IEEE 1028-1997 definiuje formalne struktury, role i procesy dla każdego z trzech ostatnich („formalne przeglądy wzajemne”), wraz z audytami oprogramowania . IEEE 1028-1997 został zastąpiony przez IEEE 1028-2008.

Badania naukowe ^{[ kto? ]} wydają się potwierdzać wniosek, że przeglądy formalne znacznie przewyższają przeglądy nieformalne pod względem opłacalności. Nieformalne przeglądy mogą często być niepotrzebnie kosztowne (ze względu na stratę czasu przez brak skupienia) i często dają poczucie bezpieczeństwa, które jest zupełnie nieuzasadnione relatywnie niewielką liczbą rzeczywistych wykrytych i naprawionych usterek.

Ogólny proces IEEE 1028 dla przeglądów formalnych

IEEE 1028 definiuje wspólny zestaw działań dla „formalnych” przeglądów (z pewnymi zmianami, zwłaszcza w przypadku audytu oprogramowania). Niniejsza norma stosuje rozróżnienie między przeglądem zarządzania , przeglądem technicznym , inspekcją , przeglądem , audytem itp.

Zaplanowana sekwencja standardowych działań jest w dużej mierze oparta na procesie kontroli oprogramowania opracowanym pierwotnie w IBM przez Michaela Fagana . Różne rodzaje przeglądów mogą stosować tę strukturę z różnym stopniem rygoru, ale wszystkie czynności są obowiązkowe dla inspekcji:

0. [Ocena wejścia]: Lider przeglądu stosuje standardową listę kontrolną kryteriów wejścia, aby upewnić się, że istnieją optymalne warunki dla pomyślnego przeglądu.
1. Przygotowanie kierownictwa: Odpowiedzialne kierownictwo zapewnia, że przegląd zostanie odpowiednio wyposażony w personel, czas, materiały i narzędzia oraz że zostanie przeprowadzony zgodnie z zasadami, standardami lub innymi odpowiednimi kryteriami.
2. Planowanie przeglądu: Lider przeglądu identyfikuje lub potwierdza cele przeglądu, organizuje zespół recenzentów i zapewnia wyposażenie zespołu we wszystkie niezbędne zasoby do przeprowadzenia przeglądu.
3. Omówienie procedur recenzji: Lider recenzji lub inna wykwalifikowana osoba upewnia się (w razie potrzeby na spotkaniu), że wszyscy recenzenci rozumieją cele recenzji, procedury recenzji, dostępne im materiały i procedury przeprowadzania recenzji.
4. [Indywidualne] Przygotowanie: Recenzenci indywidualnie przygotowują się do grupowej oceny recenzowanej pracy, dokładnie badając ją pod kątem „anomalii” (potencjalnych wad), których charakter będzie różny w zależności od rodzaju recenzji i jej celów.
5. [Grupowa] Egzamin: Recenzenci spotykają się w zaplanowanym czasie, aby zebrać wyniki swoich działań przygotowawczych i dojść do konsensusu co do statusu recenzowanego dokumentu (lub czynności).
6. Przeróbka/kontynuacja: Autor produktu pracy (lub inna wyznaczona osoba) podejmuje wszelkie działania niezbędne do naprawy usterek lub spełnienia w inny sposób wymagań uzgodnionych na spotkaniu egzaminacyjnym. Lider przeglądu sprawdza, czy wszystkie działania zostały zakończone.
7. [Ewaluacja końcowa]: Lider przeglądu weryfikuje, czy wszystkie działania niezbędne do pomyślnego przeprowadzenia przeglądu zostały wykonane i czy wszystkie produkty właściwe dla rodzaju przeglądu zostały sfinalizowane.

Wartość opinii

Najbardziej oczywistą wartością przeglądów oprogramowania (zwłaszcza przeglądów formalnych) jest to, że mogą one identyfikować problemy wcześniej i taniej niż byłyby one identyfikowane za pomocą testów lub użytkowania w terenie („proces wykrywania defektów”) [ ^{potrzebne źródło ]} . Koszt znalezienia i naprawienia usterki w wyniku dobrze przeprowadzonego przeglądu może być o jeden lub dwa rzędy wielkości niższy niż w przypadku wykrycia tej samej usterki podczas wykonywania testów lub w terenie. ^{[ potrzebne źródło ]}

Drugą, ale ostatecznie ważniejszą wartością recenzji oprogramowania jest to, że można ich używać do szkolenia autorów technicznych w zakresie opracowywania dokumentów o wyjątkowo niskiej liczbie błędów, a także do identyfikowania i usuwania niedoskonałości procesów, które sprzyjają defektom („proces zapobiegania defektom” ).

Dotyczy to w szczególności ocen wzajemnych , jeśli są one przeprowadzane wcześnie i często na próbkach pracy, zamiast czekać, aż praca zostanie zakończona. Wczesne i częste przeglądy małych próbek pracy mogą zidentyfikować systematyczne błędy w procesach pracy autora, które można poprawić przed wykonaniem dalszych wadliwych prac. Ta poprawa umiejętności autora może radykalnie skrócić czas potrzebny do opracowania wysokiej jakości dokumentu technicznego i radykalnie zmniejszyć poziom błędów podczas korzystania z dokumentu w dalszych procesach.

Zgodnie z ogólną zasadą, im wcześniej dokument techniczny zostanie wyprodukowany, tym większy będzie wpływ jego wad na wszelkie dalsze działania i ich produkty pracy. W związku z tym największą wartość przyniosą wczesne przeglądy dokumentów, takich jak plany marketingowe, kontrakty, plany i harmonogramy projektów oraz specyfikacje wymagań. Badacze i praktycy wykazali skuteczność procesu przeglądania w wyszukiwaniu błędów i problemów z bezpieczeństwem.

Zobacz też

Jakość oprogramowania
Lista filozofii tworzenia oprogramowania