Masz poważne kłopoty przy projektowaniu zorientowanego obiektowo systemu informatycznego. Oto dziesięć rad, które pozwolą Ci przezwyciężyć wszystkie trudności.

Jesteś w trakcie realizacji projektu OOD (Object Oriented Development) i sprawy nie idą za dobrze? Może gonią cię terminy, klient ma nowe wymagania czy też nagle uległ zmianie profil rynku. Niezależnie od rodzaju trapiących cię kłopotów widać wyraźnie, że kontynuowanie przyjętej wcześniej strategii mija się z celem.

Przez pięć lat pracy w firmie Pages Software Inc. zajmowałem się tworzeniem aplikacji komercyjnych przy użyciu zorientowanego obiektowo oprogramowania. Mam więc spore doświadczenie w tej dziedzinie i znam wszystkie bolączki towarzyszące temu procesowi. Dlatego pozwalam sobie przedstawić Państwu dziesięciopunktowy program, który pomoże przezwyciężyć kłopoty i kontynuować z powodzeniem prace nad zagrożonym projektem.

1. Wstrzymaj prace nad projektem. Jedno z przysłów mówi, że po straceniu celu z pola widzenia dążymy do niego dalej ze zdwojoną energią. Efektem takiego dążenia do przodu jest to, że pogrążamy się tylko jeszcze bardziej. Wstrzymanie prac pozwoli nam być może dostrzec rzeczywisty cel naszych działań. Przejrzyj zatem wraz z grupą programistów cały projekt od nowa.

2. Odrzuć przyjęty wcześniej harmonogram prac nad poszczególnymi etapami projektu. Istnieje duże prawdopodobieństo, że jest on (harmonogram) nierealny, co nie pozwoli ci wykonywać tych prac zgodnie z przyjętymi terminami. Błędnie skonstruowany harmonogram prac nie spełni oczekiwań przełożonych i zniechęci programistów tworzących projekt.

3. Przejrzyj jeszcze raz całe oprogramowanie: sprawdź jego właściwości, kody i sposoby działania. Przyjrzyj się uważnie architekturze projektu, występującym w nim klasom obiektów i ich wzajemnym relacjom (hierarchia ważności). Zrób spis bieżących czy też potencjalnych problemów, jak również nie dokończonych zadań. Sprawdź dokładnie, które elementy projektu pracują poprawnie. Zrób sobie wykaz tych czynności, które trzeba wykonać, aby doprowadzić poszczególne elementy projektu do końca. Spisz wszystkie funkcje, które nie są jeszcze przez dany element projektu wykonywane. Oceń stopień zaawansowania prac związanych z wdrożeniem do pracy obiektów każdej z klas, jak i tych kodów (występujących w obiektach innych klas), które współpracują z obiektami tej klasy.

4. Oceń realność wykonania projektu. Na tym etapie dobrze jest mieć pełne rozeznanie co do tego, jak dalece są zaawansowane prace nad projektem i umieć oszacować chociaż z grubsza, ile jeszcze mamy pracy do wykonania (napisanie dodatkowego oprogramowania, wdrożenie go do pracy i testowanie) aby ukończyć projekt. Powinniśmy też zdawać sobie sprawę z tego, jakie są oczekiwania i wymagania menedżerów, którzy będą w przyszłości eksploatować dany system informatyczny. Doprowadzi to nas zapewne do jednej z wymienionych poniżej konkluzji:

A. Prace nad projektem idą zgodnie z planem lub nawet wyprzedzają go.

B. Prace nad projektem są nieco opóźnione, chociaż w granicach tolerancji.

C. Realizacja projektu napotyka poważne trudności i termin oddania go do użytku wydaje się być nierealny.

D. Cały projekt jest poważnie zagrożony. Występują znaczne opóźnienia, budżet jest przekroczony i projekt jest właściwie w rozsypce.

Jeśli mamy do czynienia z sytuacja opisaną w punkcie pierwszym, wznawiamy spokojnie prace nad projektem. Przypadek opisany w punkcie czwartym powinien skłonić nas do zarzucenia prac nad projektem, względnie do rozpoczęcia wszystkiego od początku. Jeśli jest to przypadek drugi lub trzeci, proszę postępować zgodnie z kolejnymi wskazówkami.

5. Jeszcze raz przeanalizuj harmonogram prac nad projektem. Zasiądź przy jednym stole razem z użytkownikami, przedstawicielami dyrekcji i innymi osobami związanymi z projektem oraz przedyskutuj temat od początku. Uświadom wszystkim, że projekt nie może być ukończony zgodnie z wcześniej ustalonym terminem, chyba że będzie poważnie okrojony o pewne elementy. Postępuj dalej zgodnie z poniższymi wskazówkami:

- Każdy z elementów projektu umieść w jednej z trzech grup. Grupa pierwsza: zawiera te elementy, które muszą się znaleźć na 100% w projekcie. Grupa druga: rozwiązania które mogą, ale nie muszą się znaleźć w projekcie. Sprawa jest do przedyskutowania z klientem. Grupa trzecia: znajdą się tu te elementy projektu, które można na razie spokojnie pominąć, a dodawać do aplikacji w późniejszym terminie. Elementy z grupy trzeciej odkładamy na bok i zajmujemy się elementami oprogramowania umieszczonymi w grupie drugiej.

- Dokładnie przeglądamy rozwiązania z grupy drugiej, rezygnując z niektórych elementów modyfikując jednocześnie pozostałe. Należy się przy tym upewnić, czy jest na to zgoda wszystkich stron.

- Renegocjujemy datę ukończenia prac nad projektem. Uzgodnij nowy, tym razem już absolutnie realny, termin.

6. Przejrzyj wszystkie pozostałe elementy projektu. Sprawdź stopień zaawansowania prac nad każdym z nich, zwracając szczególnie uwagę na usytuowanie każdego elementu w ogólnej architekturze projektu. Zrób sobie dokładny spis tych rzeczy, które należy koniecznie wykonać, aby dany element oprogramowania pracował poprawnie. Zrób też rozeznanie - czy usunięcie z projektu niektórych elementów oprogramowania nie zmusi nas do przeprojektowania pozostałych elementów.

7. Zrób listę wszystkich zadań, jednocześnie ustalając kolejność ich wykonania. Niektóre zadania są ze sobą ściśle powiązane i należy je wykonywać w odpowiedniej kolejności. Dlatego sprawdź dokładnie, jakie zadania trzeba wykonać najpierw, aby podjąć następne. Ustal harmonogram prac nad zadaniami, wyszczególniając czas potrzebny na projektowanie, wdrażanie i testowanie każdego z nich.

8. Ustal harmonogram prac związanych z uruchomieniem całego projektu, upewniając się czy dysponujesz odpowiednio licznym zespołem programistów i całym zapleczem informatycznym. Biorąc pod uwagę fakt, że projekt może być uruchamiany w kilku fazach, ustal harmonogram każdej z faz, biorąc pod uwagę kolejne cykle projektowania, to jest: pisanie oprogramowania, wdrażanie go do pracy, testowanie i poprawianie. Zarezerwuj sobie też czas na prowadzenie szkoleń (zapoznanie pracowników ze środowiskiem pracy OOD)

9. Przedstaw kierownictwu tak wypracowany harmonogram prac. W przypadku stwierdzenia, że nie jesteś jednak w stanie dotrzymać wszystkich terminów, wróć do punktu piątego i zarezerwuj sobie nieco więcej czasu lub zrezygnuj z niektórych elementów oprogramowania.

10. Przystąp ponownie do prac nad projektem, kontrolując cały czas ich postęp. Jeśli projekt jest uruchamiany w kilku fazach, po zakończeniu każdej fazy poddawaj go wnikliwej ocenie i powtarzaj taką procedurę za każdym razem.

Nie jest to oczywiście idealny sposób na wdrażanie w życie każdego projektu informatycznego. Jest to tylko pewien wzorzec postępowania czy też ogólne zasady, które każdy z zainteresowanych może we własnym zakresie udoskonalać i modyfikować. Każdy następny projekt informatyczny będzie wtedy dużo łatwiejszy w realizacji.

Bruce F. Webster jest dyrektorem technicznym w firmie Pages Software Inc. Specjalizuje się w zagadnieniu projektowania systemów informatycznych przy użyciu narzędzi zorientowanych obiektowo.