Prawie 40 lat temu - podczas NATO Software Engineering Conference - pojawił się termin inżynieria oprogramowania. Gdzie inżynieria oprogramowania znajduje się dzisiaj?

Od paradygmatu GOTO, przez metody strukturalne, po nieudane próby języków czwartej generacji przemysł IT wszedł w erę metod i języków obiektowych. Od tworzenia każdej aplikacji niemal od zera, poprzez biblioteki funkcji dotarliśmy do hierarchii klas, do bibliotek łączonych dynamicznie i wielojęzykowej platformy CORBA. Od topornego interfejsu wierszowego przeszliśmy do znacznie wygodniejszych interfejsów graficznych; zaczęto też coraz systematyczniej uprawiać inżynierię interakcji. Mniej radykalne przemiany zachodziły na wyższych poziomach procesu: projektowania architektury, inżynierii wymagań oraz testowania.

Dziś w porównaniu z sytuacją sprzed 40 lat mamy do dyspozycji o wiele więcej znacznie potężniejszych sposobów pracy. W tyle za rosnącą skutecznością i sprawnością metod technicznych pozostawała i pozostaje nauka o zarządzaniu przedsięwzięciami. Nasza wiedza o tym jak optymalnie organizować projekty IT, jak dobierać oraz wiązać ze sobą metody i narzędzia, uwzględniając rodzaj produktu, wymagania niezawodności oraz czynniki ludzkie, wciąż pozostaje w powijakach. Pojawiło się i zyskało krótkotrwałą sławę wiele nowości: TQM, clean-room software engineering, techniki przyrostowe, daily build, modelowanie obiektowe, RUP - nazwy można mnożyć.

Narastająca złożoność i ociężałość modeli procesów wytwarzania oprogramowania spowodowała kontrakcję. Od ok. 15 lat coraz większą popularnością cieszą się metodyki lekkie i zwinne (agile). Procesy - zarówno ciężkie, jak i zwinne - nie są jednak dane raz na zawsze, powinny się zmieniać. Jak mierzyć i oceniać, a w miarę potrzeby zmieniać, udoskonalać i usprawniać nasze procesy? Powstało wiele metametodyk, które można podzielić na dwa wielkie stronnictwa: metametody ciężkie i lekkie.

Metametody ciężkie

Ciężkich, rozbudowanych metod mierzenia i udoskonalania procesów jest wiele. Pozwalam sobie w odniesieniu do nich używać złośliwego określenia "rezerwat leśnych dziadków" ze względu na ich skłonność do odrywania nadbudowy od bazy. Samemu będąc niewątpliwym leśnym dziadkiem, mam jak widać skłonność do używania terminologii z minionych epok, nie tylko w IT. Ciężkie metody postulują budowę i utrzymywanie ogromnego aparatu nadzorującego, przez co wymagają znacznych zasobów i nakładów, a ich stosowanie w praktyce powoduje duże spowolnienie procesu i niechęć jego uczestników. Stąd syndrom rezerwatu: ambitne, rozbudowane metodyki żyją życiem niezależnym od realiów projektów. Przykłady takich metod/modeli to rodziny: ISO 9000, Six Sigma, CMMI, COBIT, ITIL, TickIT, ISO/IEC 12207, Bootstrap, SPICE, ISO/IEC 15504 i metodyki udoskonalania procesu testowego: TMM, MMAST, TAP, TCMM, TIM, TOM, TSM, TPI. To imponująca i groźna lista skrótowców, ze szczegółami oraz praktyką można się zapoznać m.in. na spotkaniach sieci SPIN.

Metametody lekkie:

Metody lekkie można podsumować, narażając się na zarzut niejakiej przesady, jako minimalizowanie działań, oprócz czysto konstrukcyjnych. Czyli w pewnym stopniu następuje odwrócenie sytuacji - zamiast rezerwatu leśnych dziadków mamy rezerwat młodych wilków, którzy z błogosławieństwem proroków biurokracji metodom ciężkim przeciwstawiają zorientowane na skuteczność konkretnego projektu podejście na skróty. Przykłady takich metod to eXtreme Programming, metodyki agile, metody ewolucyjne (iteracyjne), prototypowanie, daily build, Rapid Application Development. W dziedzinie testowania specyficzną formą lekkiej metodyki są testy eksploracyjne.

Niedostatki rezerwatów

Słabości metod i modeli ciężkich są oczywiste: w wielu wypadkach ich złożoność i koszty postępowania wg ich wskazań po prostu przewyższają korzyści, tak jak koszt instalacji linii robotów przemysłowych w małomiasteczkowym warsztacie. Nawet jednak jeśli potencjalnie inwestycja w ciężką metodykę ma szansę się zwrócić, to jej nieelastyczność, ignorowanie mechanizmów psychologicznych i społecznych, zawiłość i oddalenie od konkretów stanowią poważną przeszkodę w ich zastosowaniu.

Z drugiej strony, metody lekkie są na dobrą sprawę rezygnacją walkowerem z korzyści gromadzenia i stosowania dobrych praktyk, z międzyprojektowego transferu wiedzy i umiejętności, systematyzacji i dyscypliny, które nie zawsze są tylko obciążeniem. Wyraźnie potrzebna jest trzecia droga - między biurokracją a chaosem.

ASDP - nareszcie!

Zapoznając się z metodyką opisaną przez Adama Kolawę i Dorotę Huizinga w mającej się ukazać we wrześniu br. książce "Automated Defect Prevention: Best Practices in Software Management", co chwila miałem chęć zawołać "nareszcie!". Nareszcie pewne oczywiste prawdy, które aż dziw, że nie zostały wyartykułowane wcześniej, doczekały się opisania! Nareszcie mamy model procesu IT, opisujący projektową rzeczywistość w miejsce hermetycznego, pełnego pobożnych, acz nierealnych życzeń świata modeli ciężkich. Nareszcie otrzymujemy metodykę, która w spójną całość łączy trzy zwykle obce sobie dotąd światy: skuteczne projektowanie oraz implementację kodu, pomiary, ocenę oraz udoskonalanie procesów i procedur, psychologię uczestników przedsięwzięcia informatycznego.

Aż się prosi, aby metodzie ASDP nadać jakąś bardziej porywającą nazwę, skoro przychodzi jej konkurować ze swoistym fundamentalizmem tradycyjnych metod. Czy istnieje korelacja między jakością projektu a jakością produktu oraz czy jest to zależność przyczynowa? Wydaje się, że tej kluczowej kwestii powinno być poświęcona większość prac dotyczących procesów oraz ich udoskonalania, ale tak nie jest. Dominuje cyzelowanie metod oraz szczegółowe opisywanie przypisywanych im cudów, bez prób choćby odpowiedzi na pytanie, na ile rzetelnie owe cuda zostały zarejestrowane i na ile tej metodzie właśnie można przypisać ich zaistnienie.