Aplikację widzę doskonałą

Pomysłów na to, jak sztukę tworzenia oprogramowania przekształcić w powtarzalny proces przemysłowy, jest wiele. Na drodze do realizacji tego ideału stoją oczywiście ludzie oraz... ich skłonność do innowacji.

Pomysłów na to, jak sztukę tworzenia oprogramowania przekształcić w powtarzalny proces przemysłowy, jest wiele. Na drodze do realizacji tego ideału stoją oczywiście ludzie oraz... ich skłonność do innowacji.

Tworzenie aplikacji teoretycznie powinno przypominać inne procesy inżynierskie. Najpierw powstaje projekt, potem jest realizowany i oddawany do użytku. Patrząc na statystyki, trudno oprzeć się wrażeniu, że rzetelny projekt i wykonana na jego podstawie aplikacja to sytuacja niezwykle rzadka. Sytuacja idealna i praktyka to w tym przypadku naprawdę dwa różne światy - zwykle po prostu warunki akceptacji projektu zmieniają się wraz z upływem czasu. Mimo to ostateczny efekt niekoniecznie zachwyca zleceniodawcę.

Obecny etap wiedzy o prowadzeniu projektów IT można porównać trochę z początkami ery przemysłowej, kiedy to próbowano przejść od wytwarzania rzemieślniczego do produkcji masowej i eksperymentowano z "taśmą" produkcyjną. To porównanie jest jednak nie całkiem doskonałe - o ile bowiem w przemyśle produkuje się prawie identyczne elementy, o tyle w przypadku IT za każdym razem powstaje produkt unikatowy. Mimo to można wyróżnić pewne elementy wspólne wszystkich projektów, co daje nadzieję, że z czasem proces tworzenia oprogramowania będzie bardziej dojrzały.

Informatyka to nie mosty

O ile udaje się budować domy, mosty - to z systemami IT nie jest już tak różowo. Warto tu przytoczyć definicję ISO 9001 określającą, czym jest jakość oprogramowania - mianowicie wg ISO jakość to "spełnienie wymagań" klienta. Jednak co robić, gdy te wymagania są nieznane i dopiero w procesie produkcji firma "odkrywa", czego oczekuje od systemu IT, albo wręcz zmieniają się w związku z nowymi warunkami biznesowymi?

Czytając angielskie materiały marketingowe, często napotyka się stwierdzenia, że nasze oprogramowanie jest "reliable" - czyli niezawodne i "robust" - czyli solidne. Niezawodne - to znaczy, że działa tak jak założono. Solidne - że prawidłowo zachowuje się w sytuacjach nieoczekiwanych. No ale co oznaczają te "sytuacje nieoczekiwane"? Część elementów może zostać obsłużona przez API warstwy usługowej (transakcyjność, pewny transport itp.). Ale tak naprawdę - mówiąc o systemie, że jest "solidny", można powiedzieć - solidny na tyle, na ile testerzy przewidzieli owe sytuacje nieoczekiwane.

Aplikacja może być zaprojektowana i realizowana na wiele różnych sposobów. Niby wiadomo, że będzie faza projektu, realizacji i testowania, ale fazy te mogą się przenikać między sobą, testy może wykonywać zleceniodawca, a projekt może być rozbity na etapy i robiony de facto w trakcie realizacji. To, czy projekt zakończy się sukcesem, zależy od wielu czynników: warunków biznesowych, precyzji definicji, jakości projektu, wykorzystanej metodologii.

Szablon od księcia, czyli Prince II

Prince II to chyba najbardziej uporządkowana metoda prowadzenia projektu. Pierwsza wersja Prince powstała w 1989 r. w Central Computer and Telecommunications Agency (CCTA), potem Office of Government Commerce w Anglii jako standard prowadzenia projektów IT dla rządu brytyjskiego. Prince II powstało w wyniku prac OGC i ponad 150 publicznych i prywatnych organizacji, które określiły wspólnie dodatkowe modyfikacje tej metodologii. Nie jest to metodologia ściśle związana z IT - odmiany Prince są stosowane w wielu projektach w różnych dziedzinach. Prince II definiuje ciąg procesów, które mają być wykonane w celu zarządzania projektem. Wiadomo, co każdy taki proces musi "przyjąć" na wejściu i co powstanie w wyniku danej operacji. W ten sposób projekt rozbity jest na łatwiejsze do zarządzania etapy dostosowane do konkretnych rozmiarów i wymagań danego projektu.

Tak naprawdę Prince II to pewnego rodzaju "szablon", na który nakłada się konkretny projekt. Szablon definiuje sposoby planowania czy analizy postępów. Aby wykorzystać Prince II, konieczne jest opracowanie scenariusza biznesowego, który ma realizować dany projekt. Podczas kolejnych etapów ten scenariusz biznesowy wyznacza ewentualne modyfikacje procesu. Prince II określa mechanizmy pozwalające dokładnie kontrolować przebieg procesu, m.in. definiowanie punktów krytycznych, tj. takich, w których trzeba podjąć ważne decyzje, analizowanie odchyleń projektu od założonego scenariusza biznesowego i harmonogramu czy przekazywanie sponsorom czytelnych informacji o postępie prac.

Twórczy bałagan, czyli eXtreme Programming

Na drugim biegunie (w pewnym sensie) znajduje się jeden z bardziej kontrowersyjnych sposobów tworzenia aplikacji - eXtreme Programming (XP). To stosunkowo młoda metodologia (liczy 8 lat). Jest o tyle ciekawa, że powstała na potrzeby tworzenia oprogramowania. Pozostałe metody mają swoje korzenie w bardziej "tradycyjnych" przedsięwzięciach biznesowych albo też ich mutacje są stosowane w innych gałęziach przemysłu. Twórcą XP jest Kent Beck, który w marcu 1996 r. rozpoczął nowy projekt w DaimlerChrysler, posługując się owym "odmiennym" sposobem tworzenia aplikacji.

Złośliwi mogą mówić, że XP to usankcjonowany bałagan. Trochę w tym racji - ta metodologia powstała po to, by można było prowadzić projekty w sytuacji, gdy klient tak naprawdę nie ma do końca sprecyzowanych oczekiwań i chce uczestniczyć w procesie tworzenia na bieżąco, dodając własne wymagania. Projekt w XP to nie jest element określający długofalową "strategię" prac, a raczej szybko opracowane "przypadki użycia" i prototypy określające wstępne życzenia klienta. Warto podkreślić, że w XP członkami zespołu są zarówno menedżer, programiści, jak i klient - wszyscy razem pracują, by powstał produkt "doskonały". XP zakłada bardzo intensywną komunikację wszystkich członków zespołu, tak by wszyscy na bieżąco znali stan projektu.

Jednym z fundamentów XP jest tzw. wspólna własność kodu. W przypadku innych metod moduły mają swojego "właściciela", który opiekuje się daną funkcjonalnością w projekcie. W XP każdy może dodać dowolną linię kodu, zmienić coś czy poprawić błąd. By to było możliwe, zespół musi mieć opracowane wspólne standardy kodowania. Oczywiście, zwłaszcza w większych projektach, trudno wymagać, by każdy programista był w stanie "zrozumieć" pełny projekt. Stąd właśnie duży nacisk na testy jednostkowe określające warunki, jakie musi spełniać kod. Dzięki temu, że w "pełnym" XP testy powstają przed napisaniem kodu od razu wiadomo, czy to co powstało lub zostało zmodyfikowane odpowiada wymaganiom projektu.


TOP 200