Testy wydajności

Kolejnym obszarem dostarczającym wiele do myślenia jest organizacja scenariusza testów wydajności. Przypadek świadomej decyzji zaniechania takich testów może wynikać tylko z faktu istnienia dobrze udokumentowanej referencyjnej instalacji o zweryfikowanych parametrach lub faktu przeprowadzenia stosownych benchmarków w renomowanym centrum zajmującym się ich organizacją. Każda zmiana założonych parametrów instalacji powinna wpłynąć na powtórzenie takich testów. Jest to jednak proces kosztowny i czasochłonny, więc ten czynnik również powinien być brany pod uwagę.

Wróćmy do początku lat 90. XX w., gdzie jedna z polskich instytucji finansowych przeprowadziła test mający przesądzić o trafności wyboru systemu centralnego, polegający na wykonaniu operacji zamknięcia dnia w skali 100 tys. rachunków, gdy było już wiadomo, że na systemie centralnym docelowo będzie przetwarzanych ich kilkakrotnie więcej. Po latach okazało się, że wolumen ten był większy ponad 10 razy! Problem polegał na tym, że na istniejącej wówczas platformie takiego eksperymentu nie dałoby się wykonać. Fakt ten z całą ostrością ujawnił się w trakcie realizowanego wdrożenia, zmuszając do zwolnienia tempa projektu. Na szczęście prognozy Gartner Group, dotyczące wyprodukowania kolejnego, wydajniejszego modelu tej platformy, okazały się trafne, co - w połączeniu z ręcznym tuningiem aplikacji - umożliwiło zakończenie tego projektu po sześciu latach.

Innym przypadkiem - prowadzonym zresztą w ramach tej samej ewaluacji potencjalnych systemów - był przypadek firmy, która w ogóle nie potrafiła uruchomić aplikacji na deklarowanej platformie, o przeprowadzeniu testu wydajnościowego już nie mówiąc. Nie minęło wiele czasu, a podobny przypadek - tym razem oprogramowania zachodniego - miałem możliwość obserwować ponownie. Znowu w wykonaniu tej samej firmy. Obecnie już ona nie istnieje, została przejęta przez inną, co można by uznać za znak sprawiedliwości dziejowej.

Sztuka, nie nauka

Omawiane przypadki wskazują dobitnie, że z zadziwiającą konsekwencją - w różnych instytucjach - są powtarzane te same, elementarne przecież błędy, o których uczy się na wszystkich kursach z prowadzenia projektów.

Nasuwa się tu pytanie o przyczyny tego stanu. Jest ich kilka.

Inżynieria oprogramowania jest ciągle bardziej sztuką niż nauką. Dysponuje wprawdzie wieloma modelami i zasadami postępowania, jednak nadal nie ma uniwersalnych metod dowodzenia poprawności oprogramowania. Nie istnieje też model teoretyczny pozwalający bezspornie obliczyć wydajność projektowanego systemu. W tym sensie informatyka ciągle bliższa jest fizyce doświadczalnej niż teoretycznej. Jednym z ciekawszych tego przykładów jest - do dziś nie rozstrzygnięty teoretycznie problem, na niskim poziomie sprzętowym - która architektura jest efektywniejsza: RISC czy CISC? Co dopiero mówić o rozstrzyganiu efektywności złożonych programów korzystających w dodatku z funkcji realizowanych przez niższe warstwy oprogramowania, np. bazy danych.

W odróżnieniu od świata informatyki świat inżynierski w zakresie np. konstrukcji mechanicznych czy budowlanych wygląda zupełnie inaczej. Postępując zgodnie z zasadami wynikającymi z elementarnych i udowodnionych praw mechaniki, ma się praktycznie pewność, że konstrukcja została zaprojektowana poprawnie i będzie działać zgodnie z założeniami. Można więc powiedzieć, że świat informatyki tworzy pewną rzeczywistość, której weryfikacja nie jest jednoznaczna. Tworzy to zachętę dla wielu osób - nie mających wystarczającej i potwierdzonej akademickim dyplomem wiedzy - do wyrażania autorytatywnych sądów i sterowania procesem przez niektórych decydentów, często nieświadomych rzeczywistego zagrożenia, jakie kreują dla instytucji swoimi decyzjami.