Inżynieria
oprogramowania
Inspekcje kodu jako skuteczna
metoda weryfikacji oprogramowania
Mariusz Chrapko
artykule The Best Infl uence on Softwa- wykrytymi/zgłoszonymi przez klienta błędami a ich
re Engineering, IEEE, January/February naprawą/likwidacją. Wszystko to nieuchronnie pro-
W2000; Steve McConnell przedstawia listę wadziło do sytuacji w której, jeżeli fi rma chciała do-
11 najważniejszych osiągnięć inżynierii oprogramowa- starczyć nową funkcjonalność, musiała zatrudniać
nia, mających  jego zdaniem  decydujących wpływ nowych programistów, gdyż pozostała większość
na rozwój tej dziedziny. Wśród czynników takich jak: koncentrowała się na pracy związanej z redukcją
programowanie obiektowe, inkrementalne tworzenie backlog u. W konsekwencji, ogromna większość pro-
oprogramowania, Capability Maturity Model for Softwa- jektów informatycznych była po prostu z
le zarządza-
re (SW-CMM), stosowanie metryk  wymienia również na, wykazując dużą tendencję do zakończenia się
inspekcje kodu. Jest to praktyka, mająca na celu wykry- fi askiem. A jeśli nawet projekty kończyły się sukce-
cie jak największej ilości błędów, a także ich naprawę sem, to tylko dzięki ciężkiej i  wręcz heroicznej pra-
jeszcze w trakcie fazy kodowania. Polega to na przeglą- cy programistów, którzy doprowadzali je do końca.
dzie kodu przez niewielkie grupy programistów (zwykle Fagan, wcielając się w rolę menedżera zarzą-
4  5 osób) zanim kod ten zostanie objęty kontrolą wer- dzającego dużym zespołem programistów, był głę-
sji i poddany testom. Warto zauważyć, iż inspekcje mo- boko świadomy rzeczywistości, w której się znalazł.
gą być stosowane przy generowaniu wszelkich artefak- Jednocześnie zastanawiał się nad wypracowaniem
tów projektowych, takich jak wymagania, design, test jakiegoś wspólnego podejścia, która pozwoliłoby to
plany czy przypadki testowe. zmienić  tak narodził się pomysł praktyk, zwanych
Praktykę inspekcji po raz pierwszy zastosował póz
niej inspekcjami. Początkowo jego współpracow-
w obecnej formie Michael Fagan, ówczesny pracow- nicy  o czym dzisiaj rzadko się mówi  bardzo scep-
nik fi rmy IBM, menedżer projektu informatycznego, tycznie podchodzili do przyjętego przez niego podej-
zajmującego się developmentem software u. ścia, czasami wręcz utrudniali mu pracę. Jak póz
niej
W artykule Review and Inspections, SD&m Con- wspomina Fagan, krytyka ta była dla niego szczegól-
ference 2001, Software Pioneers; Fagan zebrał i opi- nie cenna  czego oczywiście nie byli wtedy świado-
sał swoje doświadczenia związane z zarządzaniem mi jego przeciwnicy  i w wielu momentach w spo-
projektami informatycznymi, a co się z tym wiąże  sób znaczący pomogła usprawnić stosowane przez
próbą budowania software u o najwyższej jakości, niego podejście.
dostarczanego na czas, bez okrojonej funkcjonalno- Proces inspekcji, w formie w jakiej praktykowany
ści. Kwestia, której  jako menedżer zespołów pro- jest dzisiaj, dojrzewał przez okres aż 3,5 roku. Pro-
jektowych  poświęcił najwięcej uwagi to ogromne jekt wdrożenia tej metodologii był rozwijany na wie-
koszty rework u, a więc pracy developerów, związa- lu produktach i release ach. Zaangażowanych w nie-
nej z naprawą błędów software u, w tym szczególnie go było setki osób, często o bardzo zróżnicowanym
 błędów, pojawiających się po ostatecznym odda- stopniu sympatii dla zaimplementowanego podej-
niu produktu do klienta (release). Jak stwierdził, na- ścia. Wreszcie  po wielu cyklach stosowania pro-
prawa właśnie tych błędów powodowała największe cesu inspekcji przy generowaniu artefaktów pro-
zakłócenia w pracy developerskiej w kolejnych rele- jektowych, kiedy proces stał się w miarę stabilny,
ase ach. Rework bardzo często powodował opóz
nie- a co za tym idzie powtarzalny  IBM poprosił Fagan a
nia w dostawie produktu w zaplanowanym czasie, o wdrożenie stosowanych przez niego praktyk także
a także rezygnację z dostarczenia pewnej klasy funk- w innych dywizjach fi rmy. Jak się okazało, projekt zwią-
cjonalności, na których implementację nie było już po zany z zaimplementowaniem tej metodologii w IBM-ie
prostu czasu. Dodatkowo developerów prześlado- zakończył się w pełni sukcesem. Odnotowano wzrost
wał wciąż backlog defektów  a więc różnica między zadowolenia klientów z jakości dostarczanych produk-
tów, co było związane ze znaczącym zmniejszeniem
się ilości błędów przez nich raportowanych,
Autor pracuje w Motorola Polska Electronics na stano-
To wszystko zaowocowało artykułem Design and
wisku inżyniera jakości. Zawodowo interesuje się pro-
code inspections to reduce errors in program deve-
blematyką jakości w inżynierii oprogramowania, ze
lopment, IBM Systems J., Vol. 15, No. 3, 1976, w któ-
szczególnym uwzględnieniem doskonalenia procesu je-
rym Fagan po raz pierwszy opisał rozwijane przez
go wytwarzania w oparciu o Model CMM(I). Prywatnie
niego podejście. Artykuł ten, i kilka innych, jest do
lubi jazz i filozofi ę (głównie współczesną). W wolnych
chwilach fotografuje. pobrania na stronie internetowej Michael Fagan As-
Kontakt z autorem: [e-mail]
sociates (http://www.mfagan.com/)  firmy, którą Fa-
gan założył tuż po tym, jak odszedł z IBM a.
18
www.sdjournal.org Software Developer s Journal 03/2007
Inspekcje kodu
Produkt
roboczy
1. Planowanie
- autor gromadzi materiały
- moderator weryfikuje spełnienie kryteriów wejściowych
- wybór 3-6 osób i podział ról
Standardy,
- zaplanowanie spotkana i dystrybucja materiałów
specyfikacje
Rola Opis
2. Overview (opcjonalnie)
- wprowadzenie uczestników w zagadnienia związane z inspektowanym materiałem
Organizuje, prowadzi i weryfikuje
- spotkanie prowadzi moderator
Moderator inspekcję, przygotowuje raport
- autor prezentuje produkt roboczy
z jej przebiegu.
Zapisuje znalezione podczas inspekcji
Recorder defekty, może jednocześnie pełnić
3. Przygotowanie
rolę moderatora.
- indywidualne zapoznanie się z pakietem inspekcyjnym
Twórca produktu roboczego,
Autor z założenia nie powinien pełnić innej
roli.
4. Examination/Inspekcja
Inni Inspektorzy szukają błędów.
- zebranie czasu przygotowania się poszczególnych uczestników spotkania
- reader prezentuje (parafrazuje) produkt roboczy
- celem spotkania jest wykrywanie błędów, nie dyskusja nad możliwymi rozwiązaniami
- nie komentujemy pracy autora
Raport
- zapisanie oraz klasyfikacja wykrytych defektów (minor, major)
- maksymalnie 2 godziny
- określenie czy re-inspekcja jest konieczna
Lista defektów:
- lokalizajca
- klasyfikacja
5. Rework
- opis
- autor poprawia wykryte błędy
6. Follow-up
- moderator weryfikuje wprowadzone poprawki
Rysunek 1. Proces Inspekcji (IEEE STD 1028-1988)
Proces inspekcji Role
Szczegółowy opis procesu inspekcji oprogramowania został Proces inspekcji wymaga zdefi niowania odpowiednich ról dla
przedstawiony w IEEE Standard for Software Reviews and Audits poszczególnych uczestników spotkania. Są to:
(IEEE STD 1028-1988). W dużym stopniu pozostaje on zbieżny
z podejściem zaproponowanym przez Michaela Fagan a. " Moderator  odpowiada za zorganizowanie, prowadzenie i we-
Inspekcje, o czym była już mowa, polegają na szczegóło- ryfikację inspekcji. Jest także odpowiedzialny za przygotowa-
wym przeglądzie artefaktów projektowych przez grupę współ- nie krótkiego raportu z jej przebiegu, zawierającego m.in.:
pracowników, mających decydujący wpływ na ich powstanie. " listę wszystkich uczestników spotkania,
Grupa inspektorów nie może być zbyt duża, praktyka pokazu- " czas trwania inspekcji, wielkość inspektowanego materiału
je, iż najbardziej wydajne inspekcje są prowadzone przez pię- (np. liczba linii kodu),
cioosobowe zespoły. Artefakty projektowe to małe, ale komplet- " czas przygotowania się poszczególnych inspektorów i sza-
ne elementy naszego fi nalnego produktu, który zamierzamy do- cowany czas rework u znalezionych błędów,
starczyć naszemu klientowi. Są to np. wymagania, fragmenty ko- " czas jego zakończenia.
du, czy plany naszych testów. Małe, w przypadku kodu oznacza " Reader  rezentuje inspektowany materiał, czytając go
200-250 NCSL (non-comment source lines), w przypadku wyma- głośno, linijka po linijce  parafrazując.
gań, czy design u, mówimy o 10-20 stron przy 34 liniach tekstu " Recorder  zapisuje wszystkie błędy wykryte podczas in-
na stronę. Jeżeli design przygotowany jest w formie UML-owej, spekcji.
wówczas można przyjąć podobny przelicznik jak dla dokumen- " Autor  twórca inspektowanego materiału. Do jego obo-
tów nie-UML-owych. Samo spotkanie, podczas którego odby- wiązków należy również ewentualny rework.
wa się inspekcja, zazwyczaj poprzedzone jest indywidualnym
przygotowaniem się inspektorów, które trwa od 1-4 godzin, i jest Standardowy proces inspekcji wymaga zdefiniowania jedynie
szczególnie istotne, gdyż tak naprawdę od niego zależy czy da- ról Moderatora, Reader a, Recorder a oraz Autora. Każda do-
na inspekcja powinna się faktycznie odbyć, czy też nie. Jest rze- datkowa osoba, zaproszona na inspekcję pełni rolę Inspekto-
czą oczywistą, iż bez solidnego przygotowania się inspektorów, ra. Słowem, skupia się na skutecznym wyszukiwaniu błędów
inspekcja po prostu nie ma sensu. Oczywiście czas przygotowa- w prezentowanym produkcie roboczym. Robi więc to, co na-
nia zależy w dużej mierze od stopnia znajomości produktu robo- leży do podstawowych obowiązków wszystkich uczestników
czego, który jest przedmiotem inspekcji. spotkania.
Software Developer s Journal 03/2007 www.sdjournal.org
19
Re-inspekcja
Inżynieria
oprogramowania
Fazy
W procesie inspekcji można wyróżnić 6 faz:
Design
" Planning  w momencie, gdy developer zakończy prace
(Zarys)
12%
związane z tworzeniem danego fragmentu produktu robo-
czego, wówczas ustalany jest skład zespołu inspektorów
wraz z Moderatorem spotkania. Jego rola jest tutaj szcze-
gólnie ważna, gdyż tak naprawdę od niej zależy, jaki kształt
Design
będzie miało spotkanie  to Moderator bowiem wybiera jego
(Szczegóły)
16%
uczestników; decyduje, czy zostały spełnione wszystkie kry-
REWORK
44%
teria wejściowe, umożliwiające przeprowadzenie inspekcji 
takim kryterium może być np. bezbłędna kompilacja inspek-
towanego kodu; wreszcie to on zajmuje się organizacją sa-
Kodowanie &
Testy jednostkowe
mego spotkania, tzn. informuje wszystkich o dokładnym ter-
12%
minie planowanej inspekcji, rezerwuje salę jeśli zajdzie taka
potrzeba, a także dba o to, aby wszyscy otrzymali ten sam
Testy
integracyjne &
pakiet inspekcyjny (np. fragment kodu).
Wyma-
Systemowe
gania
" Overview  jeśli poziom wiedzy poszczególnych uczest-
10%
6%
ników spotkania jest niewystarczający, Standard IEEE
zaleca zorganizowanie krótkiego spotkania (overview),
mającego na celu wprowadzenie poszczególnych in-
Rysunek 3. Ukryte koszty REWORK'u
spektorów do zagadnień związanych z materiałem, bę-
dącym przedmiotem inspekcji. Organizacją takiego spo- 1988 sugeruje 1,5 godziny  jako średni czas przygoto-
tkania zazwyczaj zajmuje się Moderator, Autor natomiast wania.
dokonuje krótkiej prezentacji pakietu inspekcyjnego. Fa- " Examination/Inspekcja  jest to już moment, w którym
za ta ma charakter jedynie opcjonalny. Niekiedy wystar- przeprowadzana jest sama inspekcja. Zanim jednak spo-
czy przeprowadzić jedno overview dla kilku inspekcji, tkanie się rozpocznie, do obowiązków Moderatora należy
w zależności od stopnia złożoności produktu robocze- sprawdzenie stopnia przygotowania poszczególnych je-
go. Warto również podkreślić, iż w spotkaniu tym mogą go uczestników. W sytuacji, gdy Moderator uzna, iż jest
wziąć udział inni członkowie zespołu projektowego, dla on niewystarczający, powinien odwołać inspekcję, gdyż
którego prezentowana wiedza może okazać się szcze- może być ona wówczas mało wydajna. Kiedy już jednak
gólnie cenna z punktu widzenia wykonywania przyszłych do niej dojdzie, osoba, której została przypisana rola Re-
prac projektowych. ader a rozpoczyna parafrazowanie inspektowanego ma-
" Preparation  jest to faza, w której wszyscy inspektorzy teriału, linijka po linijce. W tym czasie pozostali członko-
przygotowują się do inspekcji, szczegółowo analizując wie koncentrują całą swoją uwagę na wyszukiwaniu błę-
produkt roboczy, będący jej przedmiotem. Czas przygo- dów w prezentowanym produkcie roboczym. I tutaj bardzo
towania zależy oczywiście od stopnia znajomości pakie- ważna uwaga  podczas inspekcji nie oceniamy w żad-
tu inspekcyjnego. Niemniej jednak Standard IEEE 1028- nym wypadku pracy Autora, nie zastanawiamy się też dla-
czego dany błąd wystąpił, ani w jaki sposób go naprawić.
Podstawowym celem inspekcji jest wyszukiwanie błędów!
Jeżeli inspektorzy nie będą tego świadomi, spotkanie mo-
Wymagania
że okazać się: po pierwsze niezręczne dla samego Auto-
7%
ra, który będzie snuł obawy związane z oceną jego pra-
cy, po drugie bezowocne. Wszystkie znalezione błędy po-
winny zostać odpowiednio sklasyfikowane (minor, major)
Design (Zarys)
Testy integracyjne &
16%
oraz zapisane, wraz z podaniem lokalizacji  na przykład
Systemowe
numeru linii kodu, w którym wystąpiły. Jeśli chodzi o czas
29%
trwania spotkania, Standard IEEE zaleca, aby nie było ono
dłuższe niż 2 godziny. Po tym czasie uczestnicy są już za-
zwyczaj zmęczeni, a co za tym idzie mało wydajni. Na ko-
niec spotkania Moderator powinien zdecydować, czy wy-
magana jest re-inspekcja. Jeżeli nie, spotkanie należy
Design
uznać za zamknięte.
(Szczegóły)
24%
" Rework  etap, który występuje bezpośrednio po inspekcji.
Kodowanie &
Testy jednostkowe Autor poprawia wszystkie znalezione błędy.
29%
" Follow-up  moderator weryfi kuje poprawki wprowadzone
przez Autora. Jeśli uzna, że wszystko zostało przeprowa-
dzone w sposób zgodny z  regułami sztuki wówczas in-
spekcję należy uznać za formalnie zamkniętą, a produkt
Rysunek 2. Koszty dewelopmentu software'u roboczy umieścić pod kontrolą wersji.
20
www.sdjournal.org Software Developer s Journal 03/2007
Inspekcje kodu
" Produkt roboczy  przedmiotem inspekcji niekoniecznie
50%
musi być fragment napisanego przez developera kodu.
REWORK 44%
PRODUKCJA 56% W pakiecie inspekcyjnym mogą znalez
ć się wymagania,
40%
design, przypadki testowe, user guide i wiele innej doku-
mentacji związanej z tworzonym przez nas software m.
30%
Standard IEEE nie precyzuje limitów dla poszczególnych
produktów roboczych, natomiast zazwyczaj w przypadku
44%
20% 8%
19% kodu jest to 200-250 linii, w przypadku dokumentacji 10-20
12%
4% stron w ciągu jednego spotkania.
10%
" Output  efektem każdej inspekcji powinno być: 1) lista błę-
1%
16%
12% 12%
10%
dów, wymagających poprawy oraz 2) raport inspekcyjny, któ-
6%
0%
rego celem jest określenie co było inspektowane (kod, wy-
Wyma- Design Design Kodowa- Testy Re-work
magania, design, etc.), zidentyfikowanie poszczególnych
gania (Zarys) (Sczegóły) nie & Testy inttegra-
jednost- cyjne &
uczestników spotkania oraz ich ról, przedstawienie liczby błę-
kowe Syste-
dów wraz z ich odpowiednią klasyfikacją (minor, major).
mowe
Rysunek 4. REWORK rozbity na poszczególne fazy
Inspekcje a testowanie
dewelopmentu
Zarówno inspekcje, jak i testowanie mają na celu ewaluację
Reguły i dbanie o poprawę jakości tworzonego oprogramowania, zanim
Dodatkowo istnieje kilka reguł, o których, organizując inspek- znajdzie się ono w rękach klienta. Tak więc ich wspólnym i pod-
cję, należy pamiętać: stawowym celem jest podejmowanie wszelkich aktywności zwią-
zanych z wykrywaniem i naprawą błędów, a także potencjalnych
" Cele  podstawowym celem inspekcji jest detekcja błę- problemów, które mogą zaistnieć. Jedyna, istotna różnica, za-
dów. Podejmowanie jakichkolwiek dyskusji w trakcie spo- chodząca między inspekcjami a testowaniem polega na tym, iż
tkania na temat różnych możliwości naprawienia znale- inspekcje mogą być zastosowane dużo wcześniej niż wygene-
zionej usterki, bądz
próba udowadniania, iż daną funkcję rujemy test, który umożliwi nam przeprowadzanie testów. Celem
możnaby napisać lepiej  jest naprawdę zbyteczne. A już bowiem praktyk inspekcyjnych są poniekąd elementy statyczne
na pewno!  należy unikać wszelkiej ewaluacji pracy Au- działań developerskich  dokumentacja, kod. Testy natomiast
tora. Jest to niezwykle destruktywne nie tylko dla samego skupiają się już na działającym produkcie.
spotkania, ale, co gorsze, nawet dla całego procesu wdro- Nie jest więc tak, iż inspekcje mają stać się substytutem te-
żenia inspekcji w firmie. stowania oprogramowania  nawet nie mogą. O ile bowiem pra-
" Zespół  według IEEE STD 1028-1988 powinien liczyć od ce developerskie mogą obejść się bez inspekcji, z czym de fac-
3 do 6 inspektorów. W praktyce wygląda to różnie. Należy to w naszej codziennej rzeczywistości developerskiej mamy do
zachować zasady zdrowego rozsądku. Na pewno podczas czynienia, o tyle nie można sobie wyobrazić sytuacji bez fazy te-
inspekcji kodu liczba ta nie powinna wynosić więcej niż stów. I tutaj  odsłania się właściwe przeznaczenie praktyk in-
6-7 osób. Trochę inaczej wygląda to w przypadku inspekcji spekcyjnych względem procesu testowania  komplementar-
dokumentacji. Kiedy inspektujemy na przykład wymagania ność. Błędy bądz
potencjalne zagrożenia, wykryte w trakcie in-
czy design  wówczas zaproszenie większej liczby inspek- spekcji nie pojawią się w trakcie testów, skutkiem czego zmini-
torów jest całkowicie uzasadnione. malizujemy wysiłek (effort), który prawdopodobnie pojawiłby się
Dodatkowo musimy pamiętać o tym, iż  ze względu na więk-
Defekty/KLOC
sza wydajność inspekcji  nie jest pożądane zapraszanie na
nią menedżera. Praktyka pokazuje, że inspektorzy mają wów-
czas tendencję, skądinąd uzasadnioną, do pewnej  powierz-
20
chowności w wyszukiwaniu błędów  wszystko po to, żeby
Wymagania
 chronić Autora. Jest to oczywiście sprzeczne z ideą inspek-
Defekty wykryte
40
cji, niemniej jednak, musimy pamiętać o tym, iż inspekcję two-
w "polu" (KLOC)
Design
rzą ludzie, i  pewnych zachowań nie jesteśmy w stanie unik-
nąć. Natomiast najlepszym sposobem na sprawdzenie przez
100
menedżera, czy inspekcje są przeprowadzane w sposób pra- Kodowanie
widłowy jest przede wszystkim odpowiednie przeszkolenie lu-
50
Testy
dzi w zakresie tego podejścia, monitoring raportów generowa-
jednostkowe
nych przez Moderatora oraz śledzenie, czy wykryte błędy zo-
20
stały we właściwym czasie naprawione. Testy
integracyjne
" Role  musimy pamiętać o tym, że podczas inspekcji Au-
10
Testy
tor nie może pełnić dwóch ról jednocześnie, w szczegól-
systemowe
ności nie może być Moderatorem czy Reader em, czego
nie ma w przypadku Moderatora, który może dodatkowo
pełnić rolę Recorder a. Rysunek 5. Standardowy rozkład defektów per faza
Software Developer s Journal 03/2007 www.sdjournal.org
21
Inżynieria
oprogramowania
cesu deweloperskiego z perspektywy kosztów, z jakimi poszcze-
gólne fazy się wiążą. Tego typu podział został przedstawiony
Defekty/KLOC
przez Barry ego Boehma w artykule Improving Software Produc-
tivity, Computer Vol. 20, No. 9, Sept. 1987. Należy zauważyć, iż
5(20)
blisko 40% kosztów prac developerskich związanych jest z testo-
Wymagania
waniem oprogramowania (testy jednostkowe, integracyjne i sys-
Defekty wykryte
10(40) temowe). Co ciekawe  jak pokazują badania  aktywności zwią-
w "polu" (KLOC)
Design
zane z testowaniem oprogramowanie w dużej mierze zdomino-
wane są przez naprawę defektów. W efekcie okazuje się, iż bli-
15(100)
sko 44% aktywności developerskich w fazie testów  zużywa-
Kodowanie
nych jest na naprawę błędów znalezionych przez testerów (Ry-
7(50)
Testy
sunek 3). Rysunek 4 (y
ródło: Boehm B., Improving Software Pro-
jednostkowe
ductivity, 1987) obrazuje rozkład pracy związanej z naprawą de-
fektów w poszczególnych fazach developmentu. Widzimy, że za-
3(20)
Testy
integracyjne leżność zachodząca między rework iem a poszczególnymi fa-
zami jest wprost proporcjonalna. W fazie testów integracyjnych
1(10)
Testy i systemowych jego wartość, w porównaniu z kosztami przygo-
systemowe
towania środowiska testowego oraz egzekucji testów, zwiększa
się niemalże dwukrotnie. W tym wypadku zastosowanie inspek-
cji, może okazać się szczególnie pomocne.
Rysunek 6. Rozkład defektów per faza po zastosowaniu
Rysunek 5 (y
ródło: Wheeler D.A., Brykczynski B., Meeson
inspekcji
R.N.Jr, Software Inspection, IEEE, 1996) obrazuje standardo-
gdybyśmy błędy te znalez
li, wykonując testy. Oczywiście można wy cykl tworzenia oprogramowania  kaskadowy. Obok każ-
powiedzieć, iż koszty się wcale nie zmniejszą, gdyż przecież od- dej fazy umieszczona została liczba defektów, które nie zostały
będą się inspekcje  niemniej jednak, nie służą one tylko do wy- wykryte w poprzednich fazach, skutkiem czego przeszły do ko-
krywania i eliminowania błędów w kodzie, również do śledzenia lejnych. I tak  w przypadku testów jednostkowych mamy licz-
problemów, które tylko potencjalnie mogą wystąpić. Poza tym in- bę 50 defektów na 1000 linii kodu (kilo lines of code, w skrócie
spekcje, można także stosować w przypadku dokumentacji te- KLOC ). Natomiast z fazy testów systemowych  wymknęło się
stowej  tworzenia test planów, projektowania przypadków te- aż 10 defektów/KLOC i zostały wykryte w tzw.  polu  a więc
stowych. Już sama praca nad dokumentacją testową, pozwala w miejscu swojego przeznaczenia  po stronie klienta. Grubość
nam zaoszczędzić sporo błędów, które na skutek z
le zaprojekto- linii strzałek pokazuje koszt naprawy znalezionych usterek. Wi-
wanego przypadku testowego może sprawić, iż tester długie go- dzimy, że im póz
niej dany błąd zostanie wykryty, tym większy
dziny spędzi najpierw na szukaniu usterki, a póz
niej jej naprawie- jest koszt jego naprawy. Załóżmy, że funkcjonalność, którą za-
niu. Co więcej, AT & T Bell Labs na łamach  At&T Technical Jo- implementowaliśmy nie działa tak jak powinna, tzn. tak, jak pier-
urnal , inspekcję określa jako formę testowania oprogramowania wotnie uzgodniliśmy to z naszym klientem  niezrozumieliśmy
 lecz testowania  bezkomputerowego . Oczywiście wiąże się to po prostu wymagań. Oprócz ogromnych kosztów związanych
z większymi kosztami, aniżeli w przypadku używania różnego ro- z naprawą tego błędu, spóz
nieniu ulegnie także dostarczenie
dzaju narzędzi, które zrobią to szybciej, a co za tym idzie taniej, naszego produktu. Jak pokazuje Rysunek 6 (y
ródło: Wheeler
niemniej jednak nieoceniony jest ów  czynnik ludzki współpra- D.A., Brykczynski B., Meeson R.N.Jr, Software Inspection, IEEE,
ca w rozwiązywaniu problemów, zdolność formułowania sądów 1996)  inspekcje są w stanie drastycznie zmienić tę sytuację.
wartościujących, wnikliwej dyskusji nad problemem  tego wciąż Ich celem jest eliminacja wszystkich defektów w ramach danej
nie potrafi maszyna. fazy. Oczywiście jest to tylko pewnego rodzaju stan pożądany/
Mówiąc jednak o narzędziach, warto zatrzymać się nad jed- idealny, i jego osiągnięcie w praktyce jest niezwykle rzadkie; nie-
ną kwestią  narzędzia do analizy statycznej kodu. Są to narzę- mniej jednak nawet taka eliminacja defektów  jaką widzimy na
dzia programowe, które sprawdzają napisany kod w kontekście Rysunek 6  z perspektywy developerskiej jest niezwykle ko-
wystąpienia potencjalnych błędów czy anomalii. Mogą spraw- rzystna. W nawiasach umieszczona została liczba błędów bez
dzić, czy instrukcje są poprawnie zbudowane, wnioskować przeprowadzenia inspekcji. Eliminacja defektów z fazy testów
o przepływie sterowania w programie, a także bardzo często jednostkowych z 50 do 7 per KLOC wygląda niezwykle obiecują-
wyznaczyć zbiór możliwych wartości danych programu. Narzę- co. Podobnie w przypadku błędów wykrytych w  polu , które jak
dzi do statycznej analizy kodu jest całe mnóstwo, wśród bardziej wiemy najwięcej kosztują.
znanych wymienię Coverity, Klocwork czy Purify. Zaleca się uży-
wanie tych narzędzia przed każdą inspekcją. Po to żeby nie robić Podsumowanie
czegoś co może za nas zrobić maszyna. Inspekcje kodu są powszechnie znanym i cenionym narzę-
dziem developerskim, mającym na celu poprawę jakości two-
Czy to się opłaca? rzonego oprogramowania. Na ich temat powstało mnóstwo pu-
Raportów na temat korzyści płynących ze stosowania procesu blikacji naukowych oraz opracowań. Proces inspekcji kodu po-
inspekcji w praktykach developerskich jest bardzo dużo. Moż- zostaje jednak wciąż mało znany w polskich firmach informa-
na tutaj wspomnieć o takich fi rmach jak: IBM, American Telepho- tycznych. Paradoksalnie częściej mówi się o nim w salach pol-
ne & Telegraph, Bull HN Information Systems, American Express skich uczelni technicznych, aniżeli w pokojach menedżerów pro-
czy Hewlett-Packard. Rysunek 2 obrazuje typową strukturę pro- jektów informatycznych. Z kolei, jeżeli już jakaś wiedza na ten te-
22
www.sdjournal.org Software Developer s Journal 03/2007
Inspekcje kodu
mat się pojawi, to jest ona ciągle mało doceniana i przyswajana. zażyczył sobie nagle klient), bo ciągły rework, brak wiary
Najczęściej jesteśmy wówczas świadkami powstawania kolejne- w ostateczną redukcję backlogu do zera angażuje cały ze-
go  zbioru mitów związanych z dużymi kosztami wdrożenia tego spół. A poza tym gonią nas terminy, i produkt trzeba oddać
przedsięwzięcia. A tak naprawdę  bardzo często, mówiąc o wy- na czas  choć w on time delivery dawno już przestaliśmy
sokich kosztach zaimplementowania inspekcji na gruncie danej wierzyć& Czy tak musi być? Artykuł stanowi zwięzłą próbą
fi rmy, nie są w ogóle brane pod uwagę na przykład koszty na- przedstawienia jednej z bardziej skutecznych praktyk inżynie-
prawy błędów, które  jeśli zostały wykryte w fazie testów (oby!) rii oprogramowania, mającej na celu znaczący wpływ na po-
 da się jeszcze jakoś naprawić przed ostatecznym release m do prawę jakości tworzonego oprogramowania. Omawia kolejne
klienta, a jeśli te defekty przeszły przez fazę testów niezauważo- fazy, które konstytuują proces inspekcji, definiuje role inspek-
ne i, ni stąd ni zowąd, pojawiły się w tzw.  polu , po stronie klienta torów, a także wskazuje na podstawowe zasady, które przy
 ile nas kosztuje ich naprawa? implementacji tego podejścia w firmie powinny towarzyszyć.
A patrząc z innej perspektywy, jeśli już znajdą się pienią- Dodatkowo pokazuje, iż inspekcje pełnią rolę komplementar-
dze na wdrożenie procesów usprawniających jakość tworzo- ną, żeby nie powiedzieć  służebną , względem procesu testo-
nego produktu (niekoniecznie inspekcji), to firmy zazwyczaj wania oprogramowania. Poprawnie użyte, potrafią drastycz-
nie mają czasu żeby się tym wszystkim zająć, bo niby kto nie, co pokazują dane empiryczne, zmniejszyć liczbę defek-
miałby to robić, a zatrudnić kogoś do pełnienia funkcji Quali- tów wykrywanych w kolejnych fazach życia software u; co
ty Engineer a to za duży wydatek i lepiej zatrudnić nowe oso- w rezultacie pociąga za sobą zmniejszenie wysiłku programi-
by do kodowania nowych funkcjonalności (które, jak na złość, stów związanego z ich naprawą.
R E K L A M A