W kryształowej kuli: inżynieria oprogramowania

© NewQuality
W kryształowej kuli: inżynieria oprogramowania
za 10 lat
Typowe błędy przewidywania
Próby przewidywania, jak będzie wyglądać niedaleka choćby przyszłość, zawsze
pociągały ludzi – i często kończyły się niepowodzeniem. Lektura literatury sciencefiction, nawet ambitnej, sprzed lat kilkudziesięciu, zwykle pobudza do śmiechu:
nawet u znakomitego i chwilami rzeczywiście proroczego Lema wielkie kalkulatory
zwykle migają licznymi światełkami, wypluwają z siebie mnóstwo dziurkowanej taśmy
i nerwowo potrząsają cyframi w okienkach.
Próby kształtowania rzeczywistości, od względnie niewinnych, jak państwowe
wsparcie dla przyszłościowych gałęzi przemysłu lub dziedzin nauki, po złowieszcze,
jak socjalizm i komunizm, regularnie kończą się spektakularnymi niepowodzeniami.
Jednocześnie wszelka ludzka działalność wymaga przewidywania przyszłego stanu
rzeczy. Każda decyzja inwestycyjna w przedsiębiorstwie, każde podjęcie lub
zaniechanie projektu opiera się de facto na przewidywanych skutkach takiego
działania. Toteż zabierając się do przewidywania, warto uzmysłowić sobie, jakie są
typowe błędy, które popełniamy, aby móc próbować ich unikać.
•
•
•
Pośpieszne wnioskowanie bez wstępnej analizy obecnej sytuacji; przykładem
jest np. pośpieszne wyciąganie wniosków o istnieniu zależności przyczynowej, gdy
mamy jedynie do czynienia z korelacją, lub o istnieniu korelacji, gdy mamy do
czynienia jedynie z przypadkowym współwystąpieniem pewnych zjawisk.
Nie umiemy przewidzieć skutków ubocznych – zwłaszcza odległych w czasie –
podjętych działań. Typowe przykłady to rozmaite próby inżynierii społecznej,
interwencji gospodarczych państwa oraz interwencji w systemy biologiczne: z
reguły zacne intencje działań przynoszą niezaplanowane skutki, bardzo odległe od
zamierzonych.
Błędne oszacowania prawdopodobieństwa przyszłych wydarzeń. Istnieje wiele
poznanych zależności, np. rozmaite zjawiska (wzorce, struktury w czasie i w
przestrzeni) regularne wydają się bardziej prawdopodobne niż nieregularne.
Szczególne znaczenie dla trafności przewidywania przyszłości ma zjawisko
poszukiwania logicznej historii: zdarzenia, łączące się w zgodny z doświadczeniem
życiowym łańcuch związków przyczynowo-skutkowych wydają się
prawdopodobniejsze od zdarzeń, gdzie takich związków nie dostrzegamy.
Strona 1 (4)
© NewQuality
•
Ekstrapolacja liniowa:
przewidywany
dalszy przebieg
zjawisko
faktyczny
dalszy przebieg
dotychczasowy
przebieg
czas
Ilustracja 1 Przykłady błędów ludzkiego przewidywania
Uzbrojeni w tego rodzaju ostrzeżenia (psychologia poznawcza ma na ten temat wiele
danych, z których tutaj skrótowo podanych zostało zaledwie kilka przykładów),
przystępujemy do próby opisu, co może się zmienić w ciągu najbliższych 10-ciu lat.
Szybko i intuicyjnie
O ile wiele dzisiejszych tendencji zdaje się prowadzić w kierunku bardziej
uporządkowanych i sformalizowanych metod projektowania systemów, o tyle
zjawiska opisane poniżej są wyrazem dążeń diametralnie przeciwnych: tworzenia
systemów w sposób spontaniczny, intuicyjny, pozbawiony gorsetu sztywnych
metodyk i – zdaniem zwolenników – dzięki temu pozwalający na pokonanie trzech
chronicznych bolączek inżynierii oprogramowania:
•
•
•
Niedostosowania języka specyfikacji systemu przez programistów do języka
użytkowników;
Trudności z uwzględnieniem i wdrożeniem późnych zmian wymagań i zakresu;
Marnotrawstwa pracy na tworzenie licznych artefaktów pośrednich:
dokumentacji, specyfikacji, modeli, raportów.
Można oczekiwać, że w przyszłości pojawi się metodyka (by nie powiedzieć: nauka),
pozwalająca precyzyjnie dopasować zastosowany proces wytwarzania do rodzaju
produktu, wymagań projektowych i jakościowych. Dziś wybór między zastosowaniem
procesu ciężkiego a procesu lekkiego dokonywany jest zwykle albo na podstawie
mętnych intuicji, albo firmowej tradycji i kultury. W przyszłości pojawią się, miejmy
nadzieję, metody (można je nazwać meta-procesami), pozwalające trafniej
dopasować poziom formalizacji procesu wytwarzania do wymagań.
Strona 2 (4)
© NewQuality
Programowanie intencjonalne
Jeden z najnowszych pomysłów to programowanie intencjonalne. Programista nie
pisałby kodu, tylko generator programów, produkujący kod na podstawie opisu
intencji (stąd nazwa) eksperta domenowego, wyrażonych mieszanką języka
naturalnego i różnych form wizualizacji (rysunki, wykresy, diagramy).
O ile faktyczna realizacja takiego pomysłu wymagałaby bez wątpienia zastosowania
najnowszych technologii i metodyk, o tyle sama koncepcja jest w zasadzie prostą
ekstrapolacją tego, co widzieliśmy w rozwoju inżynierii oprogramowania już
wielokrotnie:
•
•
•
Piętrowej architektury systemów realizowanej poprzez hierarchię maszyn
wirtualnych: nie pisze się dzisiaj aplikacji działających wprost na procesorze i
innych urządzeniach sprzętowych, lecz na wirtualnych platformach: sterownikach,
systemie operacyjnym, API, bibliotekach łączonych statycznie i dynamicznie,
wreszcie gotowych komponentach.
Języki 4-ej generacji: opis na wysokim poziomie abstrakcji przetwarzany
automatycznie na kod źródłowy programu.
Modelowanie: języki o składni uwzględniającej potrzeby domenowe służą do
modelowania (UML, XML, SDL), po czym rozmaite techniki – lub wręcz programy
tłumaczące – wspierają przełożenie modelu na kod nadający się do kompilacji i
wykonania.
Nie wydaje się, aby ten kierunek – choć na pewno ciekawy i mogący zaowocować
wieloma cząstkowymi rozwiązaniami – uporał się z kluczowymi problemami inżynierii
oprogramowania. Co najmniej 1/3 kłopotów w projektach informatycznych bierze się
nie z błędów implementacji, lecz z błędnych, niespójnych lub niekompletnych
wymagań, czemu żadne generatory kodu z intencji zapobiec nie potrafią.
Pomogłyby natomiast nowe, skuteczniejsze sposoby opisu i modelowania ludzkich
czynności oraz procesów – to temat do kolejnej książki.
Testowanie eksploracyjne
Jak proces projektowania i implementacji ma zwolenników metodyk intuicyjnych, tak
i testowanie próbuje uporać się z dylematem braku dokumentacji i specyfikacji
metodami zwanymi eksploracyjnymi. Testowanie eksploracyjne oznacza próbę
jednoczesnego badania funkcjonalności aplikacji, analizę wsteczną tego, jak powinna
działać i wreszcie testowania, czy działa poprawnie.
Sądzę, że wiele technik testowania eksploracyjnego ma przed sobą przyszłość.
Testowanie daje się zrealizować technikami formalnymi, algorytmicznymi, tylko w
pewnym zakresie – poza tym czynnikami sukcesu w testowaniu jest intuicja, twórczo
Strona 3 (4)
© NewQuality
spożytkowane doświadczenie, umiejętność myślenia. Natomiast cała ideologia
testowania eksploracyjnego: traktowanie planów i specyfikacji testów jako zbędnego
balastu nawet dla dobrze udokumentowanych systemów – pozostanie zapewne
jedną z wielu zabawnych, przemijających ciekawostek.
Spirale, iteracje, przyrost
Tradycyjne metody wytwarzania oprogramowania, dobrze zilustrowane modelem
kaskadowym i (pojedynczym) modelem „V”, nie radziły sobie z projektami zbyt
wielkimi, ani ze zmiennością wymagań, ani z koniecznością bardzo szybkich dostaw
choćby zrębów nowej funkcjonalności.
Stąd pojawiły się różne metodyki (spiralna, iteracyjna, przyrostowa – przy czy
określenia te nie są ani precyzyjne, ani rozłączne), pozwalające budować systemy i
aplikacje niejako po kawałku. Wprawdzie sprawiają one wiele kłopotów (komplikują
organizację projektów, narzucają konieczność rozbudowanych testów regresji, czyli
wielokrotnego ponownego testowania funkcji już przetestowanych), ale pozwalają
skuteczniej niż metodyki tradycyjne wykorzystać elastyczność materii
oprogramowania, która – pod warunkiem stworzenia odpowiednio giętkiej
architektury – pozwala majstrować przy fundamentach nawet wtedy, gdy na górze
położony jest już dach.
Metodyki przyrostowe pozostaną i rozpowszechni się ich zastosowanie. Zapewne
zaczną pojawiać się narzędzia, ułatwiające dobór odpowiedniej metodyki do założeń
projektowych, oraz narzędzia wspierające przekład wymagań (opisanych w formie
modelu) na architekturę tak, by architektura wspierała przyrostową organizację
projektu. Nie można wykluczyć, że pewne narzędzia umożliwią automatyczne
generowanie zarysu wstępnej organizacji projektu na podstawie wymagań
dotyczących produktu.
Strona 4 (4)