Testy

Przygotowaną aplikację przejmuje grupa testowa. Nazwa "kompleksowa kontrola jakości" wydaje się lepsza niż "testowanie". Zadaniem osób pracujących na stanowiskach testujących jest przede wszystkim próba "wykolejenia" aplikacji, lecz także testy bardziej kompleksowe: wydajności, ergonomii, bezpieczeństwa itd. Trudnym elementem są testy regresyjne. Jeżeli jakiś element został poprawiony, to należy zidentyfikować wszystkie ścieżki, w których dana funkcja może być wykorzystywana. Następnie trzeba od nowa przejść krok po kroku wszystkie scenariusze testowe, które uwzględniały sprawdzany element system, i upewnić się, że zmiana nie spowodowała problemów. Do realizacji tych żmudnych zadań informatycy ComArchu wykorzystują automatyczne narzędzia testujące. Lecz jeśli jest to niemożliwe lub niewydajne ze względu na zastosowaną technologię i specyfikę danego projektu, stosują tradycyjne techniki testowania wspierane przez dobrze opracowaną metodykę testowania - przede wszystkim scenariusze przygotowane już w fazie analizy systemowej.

Specjaliści z ComArchu uważają, że w pracy nie liczą się koderzy, lecz myślący programiści. "Często zdarza się, że uważny programista wyławia błędy lub niekonsekwencje popełnione w fazie analizy. Idzie wtedy do szefa analityków (lub analityka) i mówi: hej, to chyba zrobiliście źle albo może dałoby się lepiej, przemyślcie to jeszcze" - mówi Krzysztof Mendelowski. W ComArchu przyjęto założenie, aby nie podchodzić do procesu budowy oprogramowania w sposób tradycyjny, tj. kaskadowy, a raczej iteracyjny. Proces analizy systemowej przebiega w dwóch głównych fazach. W pierwszej fazie, analizy ogólnej, następuje identyfikacja głównych procesów biznesowych klienta i wszystkich funkcji, jakie system ma realizować. W drugiej, analizie szczegółowej, powstaje szczegółowy opis każdej funkcji systemu. Podział ten pozwala na prowadzenie prac analityczno-projektowych jednego obszaru systemu równolegle z pracami implementacyjnymi tego obszaru, gdzie faza analizy została zakończona.

Oddanie

Zespół udostępnia produkt kompletny, tj. wyposażony w dokumentację użytkową. Czasami są to bardzo opasłe księgi o różnym poziomie szczegółowości. Część dokumentacji jest przygotowywana przez samych informatyków (przede wszystkim dotyczy to szeroko rozumianej dokumentacji technicznej), ale większość piszą zawodowi twórcy dokumentacji. Ambicją informatyków z Com-Archu jest opracowanie wspólnych standardów i wytycznych dla dokumentacji użytkowej (zarówno merytorycznych, jak i formalnych). Trwa proces wdrażania tych standardów. Jest to jeden z punktów wdrożenia CMM w firmie. "Bardzo dbamy o to, żeby dokumentacja była aktualna i odzwierciedlała rzeczywisty stan systemu. Sami sobie oszczędzamy w ten sposób kłopotów" - dodaje Artur Ziajko, pełnomocnik zarządu ds. jakości w ComArch SA.

Utrzymanie

Znaczącą część pracy związanej z utrzymaniem funkcjonującego produktu wykonuje specjalny zespół serwisowy, do którego bezpośrednio są zgłaszane błędy. Każde zgłoszenie musi mieć formę pisemną. Do tego celu jest stosowany standardowy formularz, na którym klienci określają typ błędu, miejsce jego wystąpienia, pokrótce opisują kontekst pracy, podają wersję oprogramowania i wskazują, czy błąd jest krytyczny czy nie.

Jeżeli błąd jest poważny i zespół serwisowy nie może sobie z nim poradzić, wówczas poprawą zajmuje się zespół projektowy. "Wbudowaliśmy w nasze systemy bogate mechanizmy raportowania błędów. Dzięki temu w przypadku błędu krytycznego wiemy z dokładnością do linii kodu, gdzie wystąpiła awaria" - podkreśla z dumą Krzysztof Mendelowski. Bardzo ważną częścią tego procesu jest testowanie produktu po poprawkach - to czas wykonania tych testów w największej mierze decyduje o czasie poprawienia błędu. Testy opóźniają udostępnienie klientowi poprawionej aplikacji i w związku z tym nie zawsze są przez niego dobrze przyjmowane, ale jest to faza konieczna.

Dobre proporcje

Procesy organizacji projektu w Com-Archu cechują dobre proporcje między fazą analizy i projektowania, implementacji oraz testowania. Według szacunków firmy w przeciętnym projekcie ok. 30% czasu jest poświęcane na gruntowną analizę i wstępny projekt. Do 40% zajmuje implementacja (programowanie w tradycyjnym tego słowa znaczeniu, ale także budowa prototypu i wstępne testowanie przez programistów). Nie mniej niż 20%, ale nie więcej niż 30% czasu jest przeznaczane na testowanie na różnym poziomie. Szacunki te nie obejmują dokumentacji, która często jest tworzona przez innych, a czas jej przygotowania nie jest ściśle związany z projektem jako takim.