Powrót inżynierii oprogramowania
-
- Bogdan Bereza,
- 08.05.2014
Kolejne modne pojęcia-kanibale to architektura IT oraz architektura korporacyjna. Architektura IT oznacza strukturę, anatomię systemu informatycznego: jego podział na podsystemy, na komponenty, na klasy, zaś architektura korporacyjna albo organizacji (modniej: Enterprise Architecture) to po prostu jej schemat. Ale te pojęcia dawno wyszły za swoje początkowe ramy, zawłaszczając po drodze znaczne połacie inżynierii wymagań, ale także zarządzania zmianami, zarządzania informacją i jej przepływem, analizy biznesowej. To rozmycie znaczenia pojęcia architektury widać w tytułach referatów: „Architektura bezpieczeństwa”, „Enterprise Architecture jako kluczowy paradygmat w zarządzaniu megazmianami”.
Nie mówię, że takie ogromnie poszerzone znaczenie słowa „architektura” jest błędne – użytkownicy pojęć sami definiują ich zakres. Szkodą jest to, że w tej sytuacji wszyscy mówią swoje – obok siebie.
O tym samym mówi się raz pod nagłówkiem zarządzania projektami, raz jako o architekturze, kiedy indziej jako o wymaganiach, potem o modelowaniu biznesowym, wreszcie o ładzie korporacyjnym. Wkrada się chaos, zdublowana wielokrotnie terminologia.
Szczególnym obszarem zmasowanych nieporozumień jest świat paradygmatu agile. Patrząc z punktu widzenia agile, w tym świecie nie ma miejsca na zarządzanie projektami ani na inżynierię wymagań, ani na odniesienia do architektury korporacyjnej. Z drugiej strony, podejście agile wydaje się wielu zwolennikom tradycyjnej metodyki nie do pogodzenia z potrzebą planowania, przewidywania, kontroli i nadzorowania zakresu projektów oraz stopnia ich realizacji.
To nieporozumienia. Nie ma żadnych sprzeczności nie do pogodzenia między podejściem agile a wymogami metod nieiteracyjnych, sekwencyjnych. Znaczna część nieporozumień wynika stąd, że zarówno podejścia agile, jak i nie będące agile mają skłonność do zamykania się we własnym świecie, własnej interpretacji terminologii i zapominają, że są różnymi formami realizacji tej samej dziedziny – inżynierii oprogramowania.
Przyszłość to komunikacja
Przykłady można mnożyć. Można sięgać po kolejne nazwy: programowanie ekstremalne, różne podejścia zwane BDD/FDD/DDD/TDD… niejeden wybiera tylko jedną perspektywę, w której tkwi, ignorując pozostałe.
Wspólnym mianownikiem jest inżynieria oprogramowania, której różnymi szkołami są podawane w tym artykule podejścia, metodyki, paradygmaty. Częstsze niż obecnie odwoływanie się do niej, zamiast mnożenia niespójnych terminologicznie systemów, jest dobrą drogą do tego, o co wszystkim chodzi: o najlepsze metody tworzenia oprogramowania tak, aby realizowało jak najlepiej nasze biznesowe potrzeby.
Lata 1945–1955 to epoka pierwsza, starożytność, to lata genialnych rzemieślników, braku procedur, tworzenia oprogramowania od podstaw.
Lata 1955–1968 można nazwać renesansem: malały trudności techniczne, wzrastały koordynacyjno-logistyczne i pojawiła się potrzeba określenia praktyk i zasad nowej dziedziny, nazwanej inżynierią oprogramowania.
Lata 1968–1990 to epoka tayloryzmu w IT: powstawały wielkie i zawiłe standardy ISO oraz IEEE, powszechnie wierzono w zbawczą moc reguł i regulacji, w korzyści sformalizowanych procesów, w model sekwencyjny i w dobrodziejstwa obszernej dokumentacji. Narodziło się pojęcie dojrzałości procesów, ucieleśnione w CMM i w SPICE.
Lata 1990–2005 to okres wielkich rewolucji. W tym czasie powstały i rozpowszechniły się podejścia testowania kontekstowego, XP, agile, lean. Był to powrót do hakerskich korzeni IT, do rzemieślniczego etosu epoki starożytności, ale w zupełnie innej sytuacji technologicznej i w zmienionej społecznej roli IT.
Czasy współczesne, od roku 2005, można umownie nazwać epoką postagile. Podejścia sekwencyjne oraz iteracyjne współistnieją ze sobą, uczymy się cenić zalety każdego z nich. Tworzone są nowe normy, nowe architektury, a stare dziedziny inżynierii oprogramowania, np. inżynieria wymagań, ponownie wracają do łask.
