Cztery nogi i blat, czyli co to jest cykl projektowy

Tym artykułem rozpoczynamy cykl publikacji poświęconych metodyce projektowania systemów komputerowych. W kolejnych odcinkach postaramy się odpowiedzieć na pytanie, czym jest strukturalna metodyka analizy i projektowania systemów informatycznych, dlaczego powstała oraz jakie korzyści może dać jej stosowanie. Powiemy też parę słów o stosowanych w niej technikach oraz wspomagających je narzędziach.

Tym artykułem rozpoczynamy cykl publikacji poświęconych metodyce projektowania systemów komputerowych. W kolejnych odcinkach postaramy się odpowiedzieć na pytanie, czym jest strukturalna metodyka analizy i projektowania systemów informatycznych, dlaczego powstała oraz jakie korzyści może dać jej stosowanie. Powiemy też parę słów o stosowanych w niej technikach oraz wspomagających je narzędziach.

Zastanówmy się najpierw nad problemami towarzyszącymi dziś projektom informatycznym. Po pierwsze zaplanowany budżet i harmonogram większości projektów nie ma wiele wspólnego z ich rzeczywistymi kosztami i ramami czasowymi. Po drugie systemy nie odpowiadają często istotnym potrzebom użytkowników. Po trzecie systemy informatyczne są zawodne. Po czwarte, są często bardzo trudne do utrzymania i mało elastyczne. Można więc z pewną przekorą powiedzieć o informatykach (do których zalicza się też autor niniejszych słów), że nie potrafią planować swoich przedsięwzięć, dogadać się ze swoimi klientami - wreszcie - że nie potrafią programować (przynajmniej w dużej skali).

Powyższe stwierdzenie jest ţ świadomie ţ nieco prowokacyjne. Kłopoty z opracowywaniem systemów informatycznych pozostają jednak faktem. Fakt ten niekoniecznie oznacza brak kompetencji inżynierów oprogramowania. Informatyka jest dyscypliną stosunkowo młodą. Kilkadziesiąt lat rozwoju inżynierii oprogramowania wobec np. tradycji inżynierii lądowej to niewiele. Mosty, budynki, tunele buduje ludzkość od tysiącleci, a mimo to budowa tunelu pod kanałem La Manche dwukrotnie przekroczyła zaplanowany budżet, zaś opóźnienie w pracach wynosi dziś trzy lata. Czy więc np. opóźnienie we wprowadzaniu systemu komputerowego do rozliczania podatków

nie jest w tym kontekście wytłumaczalne?

Na szczęście informatycy nie zadowalają się tego typu argumentami. Szukają sposobów na poprawienie jakości swojej pracy.

Czy informatyka to zarządzanie?

Na pytanie "czym jest inżynieria oprogramowania" można dać wiele odpowiedzi. Najczęściej spotkalibyśmy się zapewne z poglądem, że inżynieria programowania, to po prostu sztuka pisania programów. Zapewne w pewnym stopniu tak jest. Nam chodzi tu jednak o bardzo skomplikowane programy, od których niezawodności często zależy funkcjonowanie ważnych instytucji, bezpieczeństwo, a nawet życie ludzi, a które są tworzone przez wieloosobowe zespoły. Okazuje się, że tego rodzaju przedsięwzięcia stwarzają w pierwszym rzędzie problemy organizacyjne: Jak umożliwić efektywną komunikację w zespole projektowym? W jaki sposób kontrolować poszczególne etapy projektu? Jakimi mechanizmami zapewnić wysoką jakość powstającego produktu programistycznego? A przede wszystkim ţ jak zagwarantować zgodność funkcji realizowanych przez system z oczekiwaniami użytkownika?

Informatyka nie znalazła do dziś "jedynie słusznej" odpowiedzi na postawione tutaj pytania. Metodyka

strukturalna, która wydaje się być najlepszym ze znanych dziś sposobów opanowania żywiołu dużego projektu informatycznego, jest szeroko stosowana w przemyśle informatycznym u takich krajów, jak: W. Brytania (SSADM to

standard rządowy), USA, Niemcy i Francja. Zaczyna się pojawiać również i u nas.

Nasz klient ţ nasz wyrzut sumienia, czyli problemy cyklu projektowego

Zastanówmy się, jak najprościej opisać istotę projektu informatycznego. Wydaje się, że można przyjąć następujący

model:

Projekt informatyczny ma na celu zaspokojenie istotnych potrzeb użytkownika za pomocą systemu informatycznego.

Celowo eksponujemy tu potrzeby użytkownika jako podstawowy cel działania informatyków. Częstym ich grzechem jest brak świadomości o swojej usługowej roli. "Ujarzmianie" komputerów ma dziś wiele z działalności pionierskiej

twórczej. Zapewne z tego powodu informatycy lubią myśleć o sobie jak o swego rodzaju artystach. Jedna ze słynnych książek, dotyczących metod programowania nazywa się nawet "Sztuka programowania". Nie zmienia to faktu, że dziś informatyk powinien być przede wszystkim dobrym rzemieślnikiem. Rzemieślnik zaś żyje dzięki użyteczności swoich produktów. Ma on - z punktu widzenia użytkownika - sens o tyle, o ile wprowadza elementy poprawiające funkcjonowanie jego organizacji.

W przypadku stolarza i stołu sprawa jest w miarę prosta. Stół jaki jest (a raczej jaki może być) każdy widzi.

Użytkownik stosunkowo prosto może się dogadać ze stolarzem co do swoich wymagań, rysując szkice, ustalając wymiary czy oglądając katalogi standardowych modeli. Również stolarz dysponuje typowymi materiałami, łącznikami, lakierami, innymi słowy - ustaloną technologią produkcji. Odbiór wykonanego zamówienia sprowadza się do oględzin, sprawdzenia solidności połączeń i podpisania rachunku. Można zakładać, że w procesie produkcji nie odstąpiono istotnie od początkowych założeń.

Z wielu powodów w wypadku tworzenia systemów informatycznych sprawa nie jest tak banalna. Gdyby kontynuować nasze porównanie, należy założyć, że początkowo klient tylko z grubsza wie o co mu chodzi. Chciałby mieć coś dużego, płaskiego, na czterech nogach. Pierwsza trudność polega na tym, że wykonawca musi zgadnąć iż chodzi o stół, a nie o rozwalcowanego słonia. Jeśli przypadkiem uda mu to się, kolejne przeszkody powstaną w procesie produkcyjnym. Cztery nogi wykonywane przez różne zespoły specjalistów nie pasują do siebie wielkością ani rodzajem materiałów. W trakcie opracowywania schematu stołu użytkownik ciągle dodaje różne schowki, półki, szufladki, w rezultacie do stołu zostają na chybcika dorobione dwie etażerki i szafa (ale bez drzwi). Gdy stół jest już gotowy okazuje się, że jest to tylko prototyp, w którym blat wykonano w ostatniej chwili z dykty. Na szczęście obito ją złotą blachą, dzięki czemu blat jest wodoodporny (podnosi to jednak znacznie cenę stołu). Klient urzeczony złotym połyskiem i mnóstwem szuflad w szafce bez drzwi, akceptuje całość. Niestety, stół nie mieści się w żadnym z pokojów w jego domu. W końcu służy jako altana w ogrodzie sąsiadów.

Na szczęście klient jako człowiek nieustannie podróżujący po świecie i spędzający czas w samolotach oraz hotelach

doskonale radził sobie dalej bez stołu, który w gruncie rzeczy nigdy nie był mu potrzebny.

Powyższy przykład, jakkolwiek całkowicie zmyślony i nieprawdopodobny, ilustruje dobrze problemy, z jakimi

codziennie borykają się ludzie tworzący duże systemy informatyczne. Większość projektów informatycznych zamiast

spełniać nasz wzorcowy model, przetwarza nieprecyzyjne i częściowo nieprawdziwe informacje, pochodzące od

użytkownika, w chaotycznym, bardzo skomplikowanym i podlegającym nieustannym zmianom procesie produkcyjnym.

Efekt tego procesu zwykle nie na wiele się przydaje użytkownikowi.

Cykl projektowy

Podstawowy problem, który możemy rozwiązać stosując metodykę strukturalną, związany jest z cyklem projektowym. Dziś jego cechą jest zwykle brak logicznego uporządkowania prac projektowych, uniemożliwiającym efektywne zarządzanie projektami. Drugi problem polega na braku mechanizmów zapewniających spójność informacji, używanej na etapie implementacji z informacją w formie zapisu wymagań użytkownika.

Współczesna metodyka strukturalna pozwala określić formy typowego projektu. Wyznacza ją struktura zadań, określająca co, jak i kiedy należy wykonać ţ podobnie jak przepisy z książki kucharskiej. W większości metodyk struktura taka ma trzy lub cztery poziomy szczegółowości: od podstawowych, ogólnie określonych faz cyklu projektowego do zadań najniższego poziomu określających produkty, które powinno się wytworzyć oraz wymagania dotyczące osób je realizujących. Tak opracowana struktura zadań ułatwia efektywne zarządzanie, planowanie i kontrolowanie przebiegu projektu. Poza tym kolejne zadania wykonywane są za pomocą technik zaprojektowanych z myślą o kontroli spójności informacji projektowej na wszystkich etapach opisu systemu. Dobra metodyka, wsparta odpowiednimi narzędziami, pozwala udokumentować każde wymaganie użytkownika fragmentem kodu i strukturą danych, które w działającym systemie zapewniają realizację tego wymagania.

Typowe fazy występujące w cyklu projektowym to strategia, analiza, projektowanie, implementacja, wdrożenie i

utrzymanie.

Wymienione fazy w naturalny sposób następują jedna po drugiej. Realizacja cyklu, w którym rozpoczęcie kolejnej

fazy jest możliwe po całkowitym zrealizowaniu fazy poprzedniej nazywana jest podejściem "wodospadowym"

(waterfall approach). Jest ono najwygodniejsze ze względu na planowanie i szacowanie kosztów ma jednak także swoje wady. O ile strategia i analiza zakładają zwykle znaczny udział użytkownika w tworzonym systemie, to na etapach bliższych implementacji nie ma on już wpływu na kształt systemu. Nowy system zrealizuje tylko te wymagania, które wykryli i opisali analitycy. Pozostaje tylko się modlić i/lub trzymać kciuki, aby wdrożenie nie przyniosło zbyt wielu rozczarowań.

Często lepiej jest powtórzyć cały cykl projektowy kilkakrotnie, wykorzystując za każdym razem doświadczenia z

poprzedniej iteracji. Taki sposób realizacji jest zwykle bardziej ryzykowny finansowo dla użytkownika i trudniej go zaplanować, daje jednak system znacznie lepiej dostosowany do potrzeb zamawiającego. Tym co odróżnia projekt iteracyjny od chaotycznego, jest przede wszystkim kontrolowanie marginesu ryzyka. Obszary projektu i koncepcje, mające potencjalnie największy element ryzyka, realizowane są możliwie wcześnie, aby minimalizować straty przy ewentualnym odstąpieniu od projektu.

Charakterystyka faz projektu:

Strategia

W fazie strategii w pierwszym rzędzie należy określić kto jest faktycznym użytkownikiem systemu. Jeśli system ma

realizować cele strategiczne organizacji (np. poprawa efektywności firmy poprzez wspieranie śledzenia konkurencji

podniesienie rentowności określonych zakresów działania organizacji itp.), to użytkownikiem jest przede wszystkim

kierownictwo. Do realizacji takich celów konieczne jest czasem poświęcenie wygody osób pracujących na co dzień z

systemem. (Nie należy tu jednak przesadzać. Rozjuszony użytkownik zdolny jest nieraz do desperackich działań. W

jednym z dużych kanadyjskich dzienników użytkownicy, przerażeni wdrożeniem nowego systemu komputerowego, dokonali sabotażu przecinając kabel światłowodowy stanowiący magistralę komunikacyjną systemu).

Jeśli jednak system ma wspierać przede wszystkim codzienną działalność końcowych użytkowników (np. poczta

elektroniczna), to ich wymagania będą decydujące przy opracowywaniu tego systemu.

Na tym etapie ważna jest więc przede wszystkim selekcja automatyzowanych obszarów działalności i wyartykułowanie realnych powodów, dla których podejmuje się tak kosztowne i ryzykowne przedsięwzięcie, jak stworzenie systemu komputerowego. Może się to okazać zadaniem trudnym, gdy ukrywanym powodem angażowania informatyków są na przykład względy prestiżowe ţ "no bo wszyscy się dziś komputeryzują".

Analiza

Celem analizy jest stworzenie dokumentacji zgodnej z wymaganiami użytkownika.

Dokumentacja taka powstaje we współpracy ze stroną zamawiającą, której przedstawiciele są pełnoprawnymi

członkami zespołu analityków. Dokumentacja musi być zatwierdzona i podpisana przez odpowiedzialnego

reprezentanta strony zamawiającej system. Stanowi ona podstawę do weryfikacji systemu i bazę do negocjacji w

wypadku zmiany wymagań lub problemów w realizacji projektu.

W metodyce strukturalnej istotnym elementem fazy analizy jest rozpracowanie działania bieżącego systemu. Na początku bada się aktualne rozwiązania, potem próbuje się stwierdzić, jakie logiczne funkcje spełniają. Ten logiczny opis jest tak modyfikowany aby likwidował aktualne problemy i realizował nowe postulaty użytkownika.

Na tym etapie powstaje często dokumentacja użytkowa systemu, plan testów akceptacyjnych i plan szkoleń użytkowników!

Projekt

Po uzgodnieniu logicznego kształtu systemu, przystępują do pracy projektanci, których zadaniem jest przejście od bardzo uogólnionego opisu z fazy analizy, do opisu technicznego, stanowiącego specyfikację dla generatora aplikacji.

Szczególną uwagę zwraca się na zachowanie spójności tworzonych produktów z fazą analizy i dokumentacją wymagań użytkownika. Powstaje plan testów modułów i testów integracyjnych.

Wdrożenie

Z etapem wdrożenia łączą się takie elementy, jak szkolenia, kompleksowe testowanie aplikacji i wdrożenie nowych procedur pracy komputeryzowanej organizacji. Testy akceptacyjne przeprowadzane zgodnie z kryteriami określonymi w etapach strategii i analizy pozwalają stwierdzić czy system jako całość spełnia oczekiwania zamawiającego.

W następnych odcinkach "Metodyki strukturalnej dla każdego" powiemy parę słów na temat technik i produktów faz analizy oraz projektowania. Omówimy też techniki związane z architekturą Klient/Serwer i projektowaniem graficznych systemów interakcyjnych.


TOP 200