18

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 03/2007

Inspekcje kodu jako skuteczna
metoda weryfi kacji oprogramowania

W

artykule The Best Infl uence on Softwa-
re Engineering, IEEE, January/February
2000; Steve McConnell przedstawia listę

11 najważniejszych osiągnięć inżynierii oprogramowa-
nia, mających – jego zdaniem – decydujących wpływ
na rozwój tej dziedziny. Wśród czynników takich jak:
programowanie obiektowe, inkrementalne tworzenie
oprogramowania, Capability Maturity Model for Softwa-
re (SW-CMM), stosowanie metryk – wymienia również
inspekcje kodu. Jest to praktyka, mająca na celu wykry-
cie jak największej ilości błędów, a także ich naprawę
jeszcze w trakcie fazy kodowania. Polega to na przeglą-
dzie kodu przez niewielkie grupy programistów (zwykle
4 – 5 osób) zanim kod ten zostanie objęty kontrolą wer-
sji i poddany testom. Warto zauważyć, iż inspekcje mo-
gą być stosowane przy generowaniu wszelkich artefak-
tów projektowych, takich jak wymagania, design, test
plany czy przypadki testowe.

Praktykę inspekcji po raz pierwszy zastosował

w obecnej formie Michael Fagan, ówczesny pracow-
nik fi rmy IBM, menedżer projektu informatycznego,
zajmującego się developmentem software’u.

W artykule Review and Inspections, SD&m Con-

ference 2001, Software Pioneers; Fagan zebrał i opi-
sał swoje doświadczenia związane z zarządzaniem
projektami informatycznymi, a co się z tym wiąże –
próbą budowania software’u o najwyższej jakości,
dostarczanego na czas, bez okrojonej funkcjonalno-
ści. Kwestia, której – jako menedżer zespołów pro-
jektowych – poświęcił najwięcej uwagi to ogromne
koszty rework’u, a więc pracy developerów, związa-
nej z naprawą błędów software’u, w tym szczególnie
– błędów, pojawiających się po ostatecznym odda-
niu produktu do klienta (release). Jak stwierdził, na-
prawa właśnie tych błędów powodowała największe
zakłócenia w pracy developerskiej w kolejnych rele-
ase’ach. Rework bardzo często powodował opóźnie-
nia w dostawie produktu w zaplanowanym czasie,
a także rezygnację z dostarczenia pewnej klasy funk-
cjonalności, na których implementację nie było już po
prostu czasu. Dodatkowo developerów prześlado-
wał wciąż backlog defektów – a więc różnica między

wykrytymi/zgłoszonymi przez klienta błędami a ich
naprawą/likwidacją. Wszystko to nieuchronnie pro-
wadziło do sytuacji w której, jeżeli fi rma chciała do-
starczyć nową funkcjonalność, musiała zatrudniać
nowych programistów, gdyż pozostała większość
koncentrowała się na pracy związanej z redukcją
backlog’u. W konsekwencji, ogromna większość pro-
jektów informatycznych była po prostu źle zarządza-
na, wykazując dużą tendencję do zakończenia się
fi askiem. A jeśli nawet projekty kończyły się sukce-
sem, to tylko dzięki ciężkiej i – wręcz heroicznej pra-
cy programistów, którzy doprowadzali je do końca.

Fagan, wcielając się w rolę menedżera zarzą-

dzającego dużym zespołem programistów, był głę-
boko świadomy rzeczywistości, w której się znalazł.
Jednocześnie zastanawiał się nad wypracowaniem
jakiegoś wspólnego podejścia, która pozwoliłoby to
zmienić – tak narodził się pomysł praktyk, zwanych
później inspekcjami. Początkowo jego współpracow-
nicy – o czym dzisiaj rzadko się mówi – bardzo scep-
tycznie podchodzili do przyjętego przez niego podej-
ścia, czasami wręcz utrudniali mu pracę. Jak później
wspomina Fagan, krytyka ta była dla niego szczegól-
nie cenna – czego oczywiście nie byli wtedy świado-
mi jego przeciwnicy – i w wielu momentach w spo-
sób znaczący pomogła usprawnić stosowane przez
niego podejście.

Proces inspekcji, w formie w jakiej praktykowany

jest dzisiaj, dojrzewał przez okres aż 3,5 roku. Pro-
jekt wdrożenia tej metodologii był rozwijany na wie-
lu produktach i release’ach. Zaangażowanych w nie-
go było setki osób, często o bardzo zróżnicowanym
stopniu sympatii dla zaimplementowanego podej-
ścia. Wreszcie – po wielu cyklach stosowania pro-
cesu inspekcji przy generowaniu artefaktów pro-
jektowych, kiedy proces stał się w miarę stabilny,
a co za tym idzie powtarzalny – IBM poprosił Fagan’a
o wdrożenie stosowanych przez niego praktyk także
w innych dywizjach fi rmy. Jak się okazało, projekt zwią-
zany z zaimplementowaniem tej metodologii w IBM-ie
zakończył się w pełni sukcesem. Odnotowano wzrost
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,

To wszystko zaowocowało artykułem Design and

code inspections to reduce errors in program deve-
lopment, IBM Systems J., Vol. 15, No. 3, 1976, w któ-
rym Fagan po raz pierwszy opisał rozwijane przez
niego podejście. Artykuł ten, i kilka innych, jest do
pobrania na stronie internetowej Michael Fagan As-
sociates (http://www.mfagan.com/) – fi rmy, którą Fa-
gan założył tuż po tym, jak odszedł z IBM’a.

Mariusz Chrapko

Autor pracuje w Motorola Polska Electronics na stano-
wisku inżyniera jakości. Zawodowo interesuje się pro-
blematyką jakości w inżynierii oprogramowania, ze
szczególnym uwzględnieniem doskonalenia procesu je-
go wytwarzania w oparciu o Model CMM(I). Prywatnie
lubi jazz i fi lozofi ę (głównie współczesną). W wolnych
chwilach fotografuje.
Kontakt z autorem: [e-mail]

Inspekcje kodu

19

www.sdjournal.org

Software Developer’s Journal 03/2007

Proces inspekcji

Szczegółowy opis procesu inspekcji oprogramowania został
przedstawiony w IEEE Standard for Software Reviews and Audits
(IEEE STD 1028-1988). W dużym stopniu pozostaje on zbieżny
z podejściem zaproponowanym przez Michaela Fagan’a.

Inspekcje, o czym była już mowa, polegają na szczegóło-

wym przeglądzie artefaktów projektowych przez grupę współ-
pracowników, mających decydujący wpływ na ich powstanie.
Grupa inspektorów nie może być zbyt duża, praktyka pokazu-
je, iż najbardziej wydajne inspekcje są prowadzone przez pię-
cioosobowe zespoły. Artefakty projektowe to małe, ale komplet-
ne elementy naszego fi nalnego produktu, który zamierzamy do-
starczyć naszemu klientowi. Są to np. wymagania, fragmenty ko-
du, czy plany naszych testów. Małe, w przypadku kodu oznacza
200-250 NCSL (non-comment source lines), w przypadku wyma-
gań, czy design’u, mówimy o 10-20 stron przy 34 liniach tekstu
na stronę. Jeżeli design przygotowany jest w formie UML-owej,
wówczas można przyjąć podobny przelicznik jak dla dokumen-
tów nie-UML-owych. Samo spotkanie, podczas którego odby-
wa się inspekcja, zazwyczaj poprzedzone jest indywidualnym
przygotowaniem się inspektorów, które trwa od 1-4 godzin, i jest
szczególnie istotne, gdyż tak naprawdę od niego zależy czy da-
na inspekcja powinna się faktycznie odbyć, czy też nie. Jest rze-
czą oczywistą, iż bez solidnego przygotowania się inspektorów,
inspekcja po prostu nie ma sensu. Oczywiście czas przygotowa-
nia zależy w dużej mierze od stopnia znajomości produktu robo-
czego, który jest przedmiotem inspekcji.

Role

Proces inspekcji wymaga zdefi niowania odpowiednich ról dla
poszczególnych uczestników spotkania. Są to:

• Moderator – odpowiada za zorganizowanie, prowadzenie i we-

ryfi kację inspekcji. Jest także odpowiedzialny za przygotowa-
nie krótkiego raportu z jej przebiegu, zawierającego m.in.:

•

listę wszystkich uczestników spotkania,

•

czas trwania inspekcji, wielkość inspektowanego materiału
(np. liczba linii kodu),

•

czas przygotowania się poszczególnych inspektorów i sza-
cowany czas rework’u znalezionych błędów,

• czas

jego

zakończenia.

• Reader – rezentuje inspektowany materiał, czytając go

głośno, linijka po linijce – parafrazując.

• Recorder – zapisuje wszystkie błędy wykryte podczas in-

spekcji.

• Autor – twórca inspektowanego materiału. Do jego obo-

wiązków należy również ewentualny rework.

Standardowy proces inspekcji wymaga zdefi niowania jedynie
ról Moderatora, Reader’a, Recorder’a oraz Autora. Każda do-
datkowa osoba, zaproszona na inspekcję pełni rolę Inspekto-
ra. Słowem, skupia się na skutecznym wyszukiwaniu błędów
w prezentowanym produkcie roboczym. Robi więc to, co na-
leży do podstawowych obowiązków wszystkich uczestników
spotkania.

Rysunek 1.

Proces Inspekcji (IEEE STD 1028-1988)

2. Overview (opcjonalnie)
- wprowadzenie uczestników w zagadnienia związane z inspektowanym materiałem
- spotkanie prowadzi moderator
- autor prezentuje produkt roboczy

3. Przygotowanie
- indywidualne zapoznanie się z pakietem inspekcyjnym

5. Rework
- autor poprawia wykryte błędy

6. Follow-up
- moderator weryfikuje wprowadzone poprawki

Rola

Moderator

Recorder

Autor

Inni

Opis

Organizuje, prowadzi i weryfikuje
inspekcję, przygotowuje raport
z jej przebiegu.

Zapisuje znalezione podczas inspekcji
defekty, może jednocześnie pełnić
rolę moderatora.

Twórca produktu roboczego,
z założenia nie powinien pełnić innej
roli.

Inspektorzy szukają błędów.

Produkt
roboczy

Standardy,

specyfikacje

Lista defektów:
- lokalizajca
- klasyfikacja
- opis

Raport

1. Planowanie
- autor gromadzi materiały
- moderator weryfikuje spełnienie kryteriów wejściowych
- wybór 3-6 osób i podział ról
- zaplanowanie spotkana i dystrybucja materiałów

4. Examination/Inspekcja
- 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
- zapisanie oraz klasyfikacja wykrytych defektów (minor, major)
- maksymalnie 2 godziny
- określenie czy re-inspekcja jest konieczna

Re-inspekcja

20

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 03/2007

Fazy

W procesie inspekcji można wyróżnić 6 faz:

• Planning – w momencie, gdy developer zakończy prace

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
będzie miało spotkanie – to Moderator bowiem wybiera jego
uczestników; decyduje, czy zostały spełnione wszystkie kry-
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-
mego spotkania, tzn. informuje wszystkich o dokładnym ter-
minie planowanej inspekcji, rezerwuje salę jeśli zajdzie taka
potrzeba, a także dba o to, aby wszyscy otrzymali ten sam
pakiet inspekcyjny (np. fragment kodu).

• Overview – jeśli poziom wiedzy poszczególnych uczest-

ników spotkania jest niewystarczający, Standard IEEE
zaleca zorganizowanie krótkiego spotkania (overview),
mającego na celu wprowadzenie poszczególnych in-
spektorów do zagadnień związanych z materiałem, bę-
dącym przedmiotem inspekcji. Organizacją takiego spo-
tkania zazwyczaj zajmuje się Moderator, Autor natomiast
dokonuje krótkiej prezentacji pakietu inspekcyjnego. Fa-
za ta ma charakter jedynie opcjonalny. Niekiedy wystar-
czy przeprowadzić jedno overview dla kilku inspekcji,
w zależności od stopnia złożoności produktu robocze-
go. Warto również podkreślić, iż w spotkaniu tym mogą
wziąć udział inni członkowie zespołu projektowego, dla
którego prezentowana wiedza może okazać się szcze-
gólnie cenna z punktu widzenia wykonywania przyszłych
prac projektowych.

• Preparation – jest to faza, w której wszyscy inspektorzy

przygotowują się do inspekcji, szczegółowo analizując
produkt roboczy, będący jej przedmiotem. Czas przygo-
towania zależy oczywiście od stopnia znajomości pakie-
tu inspekcyjnego. Niemniej jednak Standard IEEE 1028-

1988 sugeruje 1,5 godziny – jako średni czas przygoto-
wania.

• Examination/Inspekcja – jest to już moment, w którym

przeprowadzana jest sama inspekcja. Zanim jednak spo-
tkanie się rozpocznie, do obowiązków Moderatora należy
sprawdzenie stopnia przygotowania poszczególnych je-
go uczestników. W sytuacji, gdy Moderator uzna, iż jest
on niewystarczający, powinien odwołać inspekcję, gdyż
może być ona wówczas mało wydajna. Kiedy już jednak
do niej dojdzie, osoba, której została przypisana rola Re-
ader’a rozpoczyna parafrazowanie inspektowanego ma-
teriału, linijka po linijce. W tym czasie pozostali członko-
wie koncentrują całą swoją uwagę na wyszukiwaniu błę-
dów w prezentowanym produkcie roboczym. I tutaj bardzo
ważna uwaga – podczas inspekcji nie oceniamy w żad-
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-
że okazać się: po pierwsze niezręczne dla samego Auto-
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 sklasyfi kowane (minor, major)
oraz zapisane, wraz z podaniem lokalizacji – na przykład
numeru linii kodu, w którym wystąpiły. Jeśli chodzi o czas
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
uznać za zamknięte.

• Rework – etap, który występuje bezpośrednio po inspekcji.

Autor poprawia wszystkie znalezione błędy.

• 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
roboczy umieścić pod kontrolą wersji.

Rysunek 2.

Koszty dewelopmentu software'u

Wymagania

7%

Design (Zarys)

16%

Design

(Szczegóły)

24%

Testy integracyjne &

Systemowe

29%

Kodowanie &

Testy jednostkowe

29%

Rysunek 3.

Ukryte koszty REWORK'u

Wyma-

gania

6%

Design
(Zarys)

12%

Design

(Szczegóły)

16%

REWORK

44%

Testy

integracyjne &

Systemowe

10%

Kodowanie &

Testy jednostkowe

12%

Inspekcje kodu

21

www.sdjournal.org

Software Developer’s Journal 03/2007

Reguły

Dodatkowo istnieje kilka reguł, o których, organizując inspek-
cję, należy pamiętać:

• Cele – podstawowym celem inspekcji jest detekcja błę-

dów. Podejmowanie jakichkolwiek dyskusji w trakcie spo-
tkania na temat różnych możliwości naprawienia znale-
zionej usterki, bądź próba udowadniania, iż daną funkcję
możnaby napisać lepiej – jest naprawdę zbyteczne. A już
na pewno! – należy unikać wszelkiej ewaluacji pracy Au-
tora. Jest to niezwykle destruktywne nie tylko dla samego
spotkania, ale, co gorsze, nawet dla całego procesu wdro-
żenia inspekcji w fi rmie.

• Zespół – według IEEE STD 1028-1988 powinien liczyć od

3 do 6 inspektorów. W praktyce wygląda to różnie. Należy
zachować zasady zdrowego rozsądku. Na pewno podczas
inspekcji kodu liczba ta nie powinna wynosić więcej niż
6-7 osób. Trochę inaczej wygląda to w przypadku inspekcji
dokumentacji. Kiedy inspektujemy na przykład wymagania
czy design – wówczas zaproszenie większej liczby inspek-
torów jest całkowicie uzasadnione.

Dodatkowo musimy pamiętać o tym, iż – ze względu na więk-
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-
chowności” w wyszukiwaniu błędów – wszystko po to, żeby
„chronić” Autora. Jest to oczywiście sprzeczne z ideą inspek-
cji, niemniej jednak, musimy pamiętać o tym, iż inspekcję two-
rzą ludzie, i – pewnych zachowań nie jesteśmy w stanie unik-
nąć. Natomiast najlepszym sposobem na sprawdzenie przez
menedżera, czy inspekcje są przeprowadzane w sposób pra-
widłowy jest przede wszystkim odpowiednie przeszkolenie lu-
dzi w zakresie tego podejścia, monitoring raportów generowa-
nych przez Moderatora oraz śledzenie, czy wykryte błędy zo-
stały we właściwym czasie naprawione.

• Role – musimy pamiętać o tym, że podczas inspekcji Au-

tor nie może pełnić dwóch ról jednocześnie, w szczegól-
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.

• Produkt roboczy – przedmiotem inspekcji niekoniecznie

musi być fragment napisanego przez developera kodu.
W pakiecie inspekcyjnym mogą znaleźć się wymagania,
design, przypadki testowe, user guide i wiele innej doku-
mentacji związanej z tworzonym przez nas software’m.
Standard IEEE nie precyzuje limitów dla poszczególnych
produktów roboczych, natomiast zazwyczaj w przypadku
kodu jest to 200-250 linii, w przypadku dokumentacji 10-20
stron w ciągu jednego spotkania.

• Output – efektem każdej inspekcji powinno być: 1) lista błę-

dów, wymagających poprawy oraz 2) raport inspekcyjny, któ-
rego celem jest określenie co było inspektowane (kod, wy-
magania, design, etc.), zidentyfi kowanie poszczególnych
uczestników spotkania oraz ich ról, przedstawienie liczby błę-
dów wraz z ich odpowiednią klasyfi kacją (minor, major).

Inspekcje a testowanie

Zarówno inspekcje, jak i testowanie mają na celu ewaluację
i dbanie o poprawę jakości tworzonego oprogramowania, zanim
znajdzie się ono w rękach klienta. Tak więc ich wspólnym i pod-
stawowym celem jest podejmowanie wszelkich aktywności zwią-
zanych z wykrywaniem i naprawą błędów, a także potencjalnych
problemów, które mogą zaistnieć. Jedyna, istotna różnica, za-
chodząca między inspekcjami a testowaniem polega na tym, iż
inspekcje mogą być zastosowane dużo wcześniej niż wygene-
rujemy test, który umożliwi nam przeprowadzanie testów. Celem
bowiem praktyk inspekcyjnych są poniekąd elementy statyczne
działań developerskich – dokumentacja, kod. Testy natomiast
skupiają się już na działającym produkcie.

Nie jest więc tak, iż inspekcje mają stać się substytutem te-

stowania oprogramowania – nawet nie mogą. O ile bowiem pra-
ce developerskie mogą obejść się bez inspekcji, z czym de fac-
to w naszej codziennej rzeczywistości developerskiej mamy do
czynienia, o tyle nie można sobie wyobrazić sytuacji bez fazy te-
stów. I tutaj – odsłania się właściwe przeznaczenie praktyk in-
spekcyjnych względem procesu testowania – komplementar-
ność. Błędy bądź potencjalne zagrożenia, wykryte w trakcie in-
spekcji nie pojawią się w trakcie testów, skutkiem czego zmini-
malizujemy wysiłek (effort), który prawdopodobnie pojawiłby się

Rysunek 4.

REWORK rozbity na poszczególne fazy

dewelopmentu

0%

10%

20%

30%

40%

50%

1%

6%

4%

12%

8%

16%

12%

12%

19%

10%

44%

Wyma-

gania

Design
(Zarys)

Design

(Sczegóły)

Kodowa-

nie & Testy

jednost-

kowe

Testy

inttegra-

cyjne &

Syste-

mowe

Re-work

REWORK 44%

PRODUKCJA 56%

Rysunek 5.

Standardowy rozkład defektów per faza

Wymagania

Defekty/KLOC

Design

Kodowanie

Testy

jednostkowe

Testy

integracyjne

Testy

systemowe

20

40

100

50

20

10

Defekty wykryte

w "polu" (KLOC)

22

Inżynieria

oprogramowania

www.sdjournal.org

Software Developer’s Journal 03/2007

gdybyśmy błędy te znaleźli, wykonując testy. Oczywiście można
powiedzieć, iż koszty się wcale nie zmniejszą, gdyż przecież od-
będą się inspekcje – niemniej jednak, nie służą one tylko do wy-
krywania i eliminowania błędów w kodzie, również do śledzenia
problemów, które tylko potencjalnie mogą wystąpić. Poza tym in-
spekcje, można także stosować w przypadku dokumentacji te-
stowej – tworzenia test planów, projektowania przypadków te-
stowych. Już sama praca nad dokumentacją testową, pozwala
nam zaoszczędzić sporo błędów, które na skutek źle zaprojekto-
wanego przypadku testowego może sprawić, iż tester długie go-
dziny spędzi najpierw na szukaniu usterki, a później jej naprawie-
niu. Co więcej, AT & T Bell Labs na łamach „ At&T Technical Jo-
urnal”, inspekcję określa jako formę testowania oprogramowania
– lecz testowania „bezkomputerowego”. Oczywiście wiąże się to
z większymi kosztami, aniżeli w przypadku używania różnego ro-
dzaju narzędzi, które zrobią to szybciej, a co za tym idzie taniej,
niemniej jednak nieoceniony jest ów „czynnik ludzki” współpra-
ca w rozwiązywaniu problemów, zdolność formułowania sądów
wartościujących, wnikliwej dyskusji nad problemem – tego wciąż
nie potrafi maszyna.

Mówiąc jednak o narzędziach, warto zatrzymać się nad jed-

ną kwestią – narzędzia do analizy statycznej kodu. Są to narzę-
dzia programowe, które sprawdzają napisany kod w kontekście
wystąpienia potencjalnych błędów czy anomalii. Mogą spraw-
dzić, czy instrukcje są poprawnie zbudowane, wnioskować
o przepływie sterowania w programie, a także bardzo często
wyznaczyć zbiór możliwych wartości danych programu. Narzę-
dzi do statycznej analizy kodu jest całe mnóstwo, wśród bardziej
znanych wymienię Coverity, Klocwork czy Purify. Zaleca się uży-
wanie tych narzędzia przed każdą inspekcją. Po to żeby nie robić
czegoś co może za nas zrobić maszyna.

Czy to się opłaca?

Raportów na temat korzyści płynących ze stosowania procesu
inspekcji w praktykach developerskich jest bardzo dużo. Moż-
na tutaj wspomnieć o takich fi rmach jak: IBM, American Telepho-
ne & Telegraph, Bull HN Information Systems, American Express
czy Hewlett-Packard. Rysunek 2 obrazuje typową strukturę pro-

cesu deweloperskiego z perspektywy kosztów, z jakimi poszcze-
gólne fazy się wiążą. Tego typu podział został przedstawiony
przez Barry’ego Boehma w artykule Improving Software Produc-
tivity, Computer Vol. 20, No. 9, Sept. 1987. Należy zauważyć, iż
blisko 40% kosztów prac developerskich związanych jest z testo-
waniem oprogramowania (testy jednostkowe, integracyjne i sys-
temowe). Co ciekawe – jak pokazują badania – aktywności zwią-
zane z testowaniem oprogramowanie w dużej mierze zdomino-
wane są przez naprawę defektów. W efekcie okazuje się, iż bli-
sko 44% aktywności developerskich w fazie testów „zużywa-
nych” jest na naprawę błędów znalezionych przez testerów (Ry-
sunek 3). Rysunek 4 (Źródło: Boehm B., Improving Software Pro-
ductivity, 1987) obrazuje rozkład pracy związanej z naprawą de-
fektów w poszczególnych fazach developmentu. Widzimy, że za-
leżność zachodząca między rework’iem a poszczególnymi fa-
zami jest wprost proporcjonalna. W fazie testów integracyjnych
i systemowych jego wartość, w porównaniu z kosztami przygo-
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 5 (Źródło: Wheeler D.A., Brykczynski B., Meeson

R.N.Jr, Software Inspection, IEEE, 1996) obrazuje standardo-
wy cykl tworzenia oprogramowania – kaskadowy. Obok każ-
dej fazy umieszczona została liczba defektów, które nie zostały
wykryte w poprzednich fazach, skutkiem czego przeszły do ko-
lejnych. I tak – w przypadku testów jednostkowych mamy licz-
bę 50 defektów na 1000 linii kodu (kilo lines of code, w skrócie
KLOC ). Natomiast z fazy testów systemowych „wymknęło się”
aż 10 defektów/KLOC i zostały wykryte w tzw. „polu” – a więc
w miejscu swojego przeznaczenia – po stronie klienta. Grubość
linii strzałek pokazuje koszt naprawy znalezionych usterek. Wi-
dzimy, że im później dany błąd zostanie wykryty, tym większy
jest koszt jego naprawy. Załóżmy, że funkcjonalność, którą za-
implementowaliśmy nie działa tak jak powinna, tzn. tak, jak pier-
wotnie uzgodniliśmy to z naszym klientem – niezrozumieliśmy
po prostu wymagań. Oprócz ogromnych kosztów związanych
z naprawą tego błędu, spóźnieniu ulegnie także dostarczenie
naszego produktu. Jak pokazuje Rysunek 6 (Źródło: Wheeler
D.A., Brykczynski B., Meeson R.N.Jr, Software Inspection, IEEE,
1996) – inspekcje są w stanie drastycznie zmienić tę sytuację.
Ich celem jest eliminacja wszystkich defektów w ramach danej
fazy. Oczywiście jest to tylko pewnego rodzaju stan pożądany/
idealny, i jego osiągnięcie w praktyce jest niezwykle rzadkie; nie-
mniej jednak nawet taka eliminacja defektów – jaką widzimy na
Rysunek 6 – z perspektywy developerskiej jest niezwykle ko-
rzystna. W nawiasach umieszczona została liczba błędów bez
przeprowadzenia inspekcji. Eliminacja defektów z fazy testów
jednostkowych z 50 do 7 per KLOC wygląda niezwykle obiecują-
co. Podobnie w przypadku błędów wykrytych w „polu”, które jak
wiemy najwięcej kosztują.

Podsumowanie

Inspekcje kodu są powszechnie znanym i cenionym narzę-
dziem developerskim, mającym na celu poprawę jakości two-
rzonego oprogramowania. Na ich temat powstało mnóstwo pu-
blikacji naukowych oraz opracowań. Proces inspekcji kodu po-
zostaje jednak wciąż mało znany w polskich fi rmach informa-
tycznych. Paradoksalnie częściej mówi się o nim w salach pol-
skich uczelni technicznych, aniżeli w pokojach menedżerów pro-
jektów informatycznych. Z kolei, jeżeli już jakaś wiedza na ten te-

Rysunek 6.

Rozkład defektów per faza po zastosowaniu

inspekcji

Wymagania

Defekty/KLOC

Design

Kodowanie

Testy

jednostkowe

Testy

integracyjne

Testy

systemowe

5(20)

10(40)

15(100)

7(50)

3(20)

1(10)

Defekty wykryte

w "polu" (KLOC)

Inspekcje kodu

mat się pojawi, to jest ona ciągle mało doceniana i przyswajana.
Najczęściej jesteśmy wówczas świadkami powstawania kolejne-
go „zbioru mitów” związanych z dużymi kosztami wdrożenia tego
przedsięwzięcia. A tak naprawdę – bardzo często, mówiąc o wy-
sokich kosztach zaimplementowania inspekcji na gruncie danej
fi rmy, nie są w ogóle brane pod uwagę na przykład koszty na-
prawy błędów, które – jeśli zostały wykryte w fazie testów (oby!)
– da się jeszcze jakoś naprawić przed ostatecznym release’m do
klienta, a jeśli te defekty przeszły przez fazę testów niezauważo-
ne i, ni stąd ni zowąd, pojawiły się w tzw. „polu”, po stronie klienta
– ile nas kosztuje ich naprawa?

A patrząc z innej perspektywy, jeśli już znajdą się pienią-

dze na wdrożenie procesów usprawniających jakość tworzo-
nego produktu (niekoniecznie inspekcji), to fi rmy zazwyczaj
nie mają czasu żeby się tym wszystkim zająć, bo niby kto
miałby to robić, a zatrudnić kogoś do pełnienia funkcji Quali-
ty Engineer’a to za duży wydatek i lepiej zatrudnić nowe oso-
by do kodowania nowych funkcjonalności (które, jak na złość,

zażyczył sobie nagle klient), bo ciągły rework, brak wiary
w ostateczną redukcję backlogu do zera angażuje cały ze-
spół. A poza tym gonią nas terminy, i produkt trzeba oddać
na czas – choć w on time delivery dawno już przestaliśmy
wierzyć… Czy tak musi być? Artykuł stanowi zwięzłą próbą
przedstawienia jednej z bardziej skutecznych praktyk inżynie-
rii oprogramowania, mającej na celu znaczący wpływ na po-
prawę jakości tworzonego oprogramowania. Omawia kolejne
fazy, które konstytuują proces inspekcji, defi niuje role inspek-
torów, a także wskazuje na podstawowe zasady, które przy
implementacji tego podejścia w fi rmie powinny towarzyszyć.
Dodatkowo pokazuje, iż inspekcje pełnią rolę komplementar-
ną, żeby nie powiedzieć „służebną”, względem procesu testo-
wania oprogramowania. Poprawnie użyte, potrafi ą drastycz-
nie, co pokazują dane empiryczne, zmniejszyć liczbę defek-
tów wykrywanych w kolejnych fazach życia software’u; co
w rezultacie pociąga za sobą zmniejszenie wysiłku programi-
stów związanego z ich naprawą.



R

E

K

L

A

M

A