Harmonogramowanie projektu tworzenia systemu informatycznego

Tworzenie systemu informatycznego obarczone jest dużą niepewnością. Jest to dzia-łalność twórcza, inwencyjna prowadzona w konsultacji z klientem, którego wymagania są często trudne do przewidzenia i zrealizowania. Występuje niepewność przy wyko-nywaniu poszczególnych zadań, jak i przy szacowaniu czasu trwania projektu. Uzasad-nione jest stosowanie predyktywno-reaktywnego harmonogramowania projektu z ogra-niczoną dostępnością zasobów, w którym chronione są terminy realizacji poszczegól-nych etapów projektu. Poniżej przedstawione są wybrane aspekty związane z

zastoso-waniem i przydatnością modelu RCPSP z kamieniami milowymi dla problemu harmo-nogramowania projektu informatycznego.

Szeregowanie zadań projektu tworzenia systemu informatycznego można sprowadzić do problemu reaktywno-predyktywnego harmonogramowania projektów z ograniczoną dostępnością odnawialnych zasobów RCPSP.

Zasoby, które są wykorzystywane w tworzeniu systemu informatycznego są odna-wialne – po zakończeniu zadania są dostępne do realizacji następnych czynności. Do tych zasobów można zaliczyć:

 zasoby ludzkie – programiści, projektanci (analitycy), testerzy (problem wielozaso-bowy), w mniejszych firmach, przy mniejszych projektach możliwość połączenia tych wszystkich funkcji (problem jednozasobowy),

 zasoby sprzętowe (ang. hardware) z oprogramowaniem (ang. software) – komputery z zainstalowanym środowiskiem programistycznym, z bibliotekami i narzędziami stosowanymi w tworzeniu systemu informatycznego

Każdy pracownik pracuje najczęściej przy jednym stanowisku komputerowym – może być rozważany łącznie jako całość: pracownik z komputerem i oprogramowaniem.

Podczas planowania projektu najczęściej zakłada się, że dany projekt realizuje grupa projektowa o zbliżonej wiedzy i doświadczeniu: pracownicy nie są istotnie zróżnicowa-ni pod względem umiejętności i pracowitości, w związku z tym planowany czas realiza-cji poszczególnych zadań przez każdego z pracowników jest podobny. Czynność reali-zowana przez więcej niż jeden zasób, mimo czasowej niedostępności jednego z zaso-bów, może być kontynuowana (ang. preempt-resume), ale jest wydłużona. Istnieje moż-liwość transferu zasobu (pracownika) do wykonywania tej czynności, ale wiąże się to z dodatkowym czasem potrzebnym do zapoznania się ze specyfiką zadania.

Liczba zasobów jest ograniczona tzn. podczas wykonania projektu w firmie progra-mistycznej występują ograniczenie zasobowe takie jak:

 liczba pracowników, liczba członków grupy projektowej realizującej dany projekt,  liczba stanowisk komputerowych wyposażonych w odpowiednie oprogramowanie

(np. ograniczenia związane z liczbą licencji na dane oprogramowanie, ograniczenie związane z dostępną przestrzenią użytkową w budynku firmy).

Najczęściej projekt informatyczny jest wykonywany przez przydzieloną do niego grupę złożoną z określonej liczby programistów, analityków i testerów.

Między zadaniami występują ograniczenia kolejnościowe. Zadania powiązane są re-lacjami typu koniec-początek np.:

 tworzenie nowej funkcjonalności jest rozwinięciem już istniejącej i może być rozpo-częte po zakończeniu jej wykonania np. moduł ewidencji danych można implemen-tować dla opracowanej już struktury bazy danych,

 implementacja zadania przez programistów możliwa jest po sporządzeniu jego spe-cyfikacji przez analityków,

 testowanie zadania przez testerów możliwe jest po jego implementacji przez progra-mistów itd.

Relacje między zadaniami przy produkcji systemu informatycznego występują głównie wtedy, gdy nowa funkcjonalność jest rozwinięciem już istniejącej. W związku z tym uzasadnione jest podejście stosowane w pracy przy alokacji zasobów do zadań projek-towych, w którym te same zasoby przydzielane są do pracy nad zadaniami między,

któ-rymi istnieją zależności kolejnościowe. Na przykład programiści, którzy pracowali nad istniejącym modułem, znają jego specyfikę i szybciej wykonają zadanie, które jest roz-budową tego modułu. Z podobnych przyczyn wskazane jest także alokowanie jak naj-mniejszej liczby wspólnych zasobów do realizacji poszczególnych etapów projektu. Dodatkowo ułatwia to rozliczanie pracowników z realizacji etapów projektu.

Przydatność modelu RCPSP dla problemu harmonogramowania projektu informa-tycznego potwierdzają analizy przeprowadzone w badaniach [7][75]. W produkcji sys-temów informatycznych szczególnie przydatny jest rozpatrywany w rozprawie problem

RCPSP z kamieniami milowymi. Jako kamienie milowe należy tutaj potraktować

kolej-ne wersje systemu informatyczkolej-nego przeznaczokolej-ne do odbioru przez klienta (zlecenio-dawcę). Zleceniodawcy systemu informatycznego często ustalają terminy zobowiązują-ce firmę do wysłania programu zawierajązobowiązują-cego określone funkcjonalności. Jeśli wystę-pują opóźnienia w przygotowywaniu kolejnych wersji oprogramowania, firma progra-mistyczna może być zobligowana do opłacenia kar umownych, a przy dużym poślizgu czasowym zleceniodawca ma możliwość wycofania się z projektu. Z kolei za termino-we wykonanie danej termino-wersji systemu informatycznego, zleceniodawca jest zobowiązany do przesłania transz płatności za ten etap projektu. Wykonawca projektu, w celu mak-symalizacji zysku z przedsięwzięcia, w harmonogramie prac musi uwzględniać umow-ne etapy projektu.

W etapie negocjacji z klientem użyteczne jest znalezienie wstępnego harmonogramu realizacji projektu. Wiedza z tego harmonogramu może być wykorzystana do renego-cjowania terminów realizacji poszczególnych etapów systemu informatycznego (kolej-nych wersji systemu) a także do wyceny przedsięwzięcia (podstawą wyceny jest także liczba osobogodzin potrzebnych do realizacji projektu). Powinien być zagwarantowany odpowiedni poziom zabezpieczenia (uwzględniający ryzyko danego projektu IT) dla terminowej realizacji wszystkich etapów projektu. Ten harmonogram wstępny można znaleźć przy użyciu proponowanych przez autora rozwiązań. Kompleksowe predyk-tywno-reaktywne podejście pozwala także prowadzić analizy zabezpieczenia umow-nych terminów w zależności od zmienności parametrów produkcyjumow-nych.

Dla projektu systemu informatycznego można wyodrębnić przykładowo następujące kamienie milowe:

I etap (faza negocjacji z klientem) – termin zatwierdzenia wszystkich funkcjonalności

systemu – przygotowanie koncepcji całego systemu, struktury bazy danych, opracowa-nie interfejsów komunikacyjnych systemu (do negocjacji z klientem).

II etap – termin wysyłki pierwszej wersji systemu np. z modułem ewidencji danych. III etap – termin wysyłki drugiej wersji systemu np. z modułem zarządzania systemem,

z obsługą interfejsów komunikacyjnych.

IV etap – termin wysyłki trzeciej wersji systemu, np. z modułem raportowania danych,

modułem analizy i wizualizacji danych, modułem aktualizacji wersji.

V etap – termin realizacji całego przedsięwzięcia – testowanie całego systemu,

popra-wa błędów, poprapopra-wa wydajności, przygotopopra-wanie programu instalacyjnego (konfigurują-cego system).

Moduły składają się z zadań wyodrębnionych w wyniku analizy wymagań funkcjo-nalnych i systemowych. Każde z zadań ma określoną liczbę zasobów różnego typu (analityków, programistów, testerów) niezbędną do realizacji tej czynności, ustaloną

w fazie planowania np. na podstawie analiz możliwości podziału tego zadania na części, które powinny być wykonywane równolegle. Każde z zadań jest gotowe do implemen-tacji po sporządzeniu specyfikacji przez analityków systemu. Testowanie jest wykony-wane dla funkcjonalności (całych modułów) lub dla pojedynczych czynności.

Podczas wykonania projektu IT zadaniom przypisuje się priorytety. Priorytety zadań przydzielanych do wykonania (zadanie krytyczne, ważne, o średnim priorytecie, o ni-skim priorytecie) wynikają z aktualnej rezerwy czasowej dla etapu projektu związanego z danym zadaniem (z aktualnego zużycia bufora czasowego kamienia milowego). Jest to możliwe do zrealizowania w proponowanych rozwiązaniach.

Umowne etapy tworzenia systemu informatycznego są uwzględniane podczas pre-dyktywno-reaktywnego szeregowania. Harmonogram predyktywny maksymalizuje po-ziom zabezpieczenia poszczególnych kamieni milowych.

Podczas harmonogramowania odpornego w tej rozprawie przyjęte jest założenie, że zadania najdłuższe i najbardziej zasobochłonne są najbardziej narażone na zakłócenia i dlatego są w pierwszej kolejności zabezpieczane. Założenie to jest uzasadnione przy planowaniu projektów IT: najtrudniejszymi do oszacowania i najbardziej ryzykownymi są z reguły zadania trwające najdłużej i realizowane przez największą liczbę osób. Pod-czas wykonania takich dużych zadań występuje także większe prawdopodobieństwo wystąpienia czasowej niedostępności, któregoś z zasobów. W związku z dużą niepew-nością, przy szacowaniu czasów trwania krytycznych i skomplikowanych fragmentów oprogramowania, w praktyce stosuje się tzw. wczesne wykonanie prototypów (ang.

rapid prototyping).

Predyktywno-reaktywne podejście jest przeznaczone dla planowania przedsięwzięć obarczonych niepewnością związaną z czasami trwania zadań. Jako źródła niepewności podczas tworzenia systemu informatycznego można wymienić:

 związane z czynnikiem ludzkim: systemy informatyczne są tworzone przez zasoby ludzkie (analitycy, projektanci, programiści, testerzy), które charakteryzują się dużą zmiennością czasów wykonania zadań, czas realizacji każdego zadania przez po-szczególnych pracowników może być różny – uzależniony od doświadczenia, wie-dzy, talentu, pracowitości,

 związane z klientem (zleceniodawcą): każdy klient jest inny, ma inne wymagania, w związku z tym projekty zawsze się różnią od już zrealizowanych, poza tym często występują problemy komunikacyjne między klientem a wykonawcą (niezrozumienie rzeczywistych wymagań klienta co do kształtu systemu),

 związane z dostępnością zasobów: sprzętowych (awaryjność), ludzkich (choroby, nieplanowane urlopy itp.),

 trudności implementacyjne: związane ze stosowanym środowiskiem programistycz-nym, z błędami w nim występującymi i ewentualnymi ograniczeniami (niemożność wykonania zadania bez uzupełnienia bibliotek danego środowiska),

 problemy z oszacowaniem czasów trwania zadań.

Oszacowanie czasów trwania zadań jest trudne, ponieważ tworzenie oprogramowania jest działalnością twórczą i każdy projekt informatyczny ma cechy nowatorskie. Ozna-cza to, że doświadczenie zdobyte podOzna-czas realizacji poprzednich systemów informa-tycznych może być wykorzystane w następnych przedsięwzięciach jedynie jako odnie-sienie do przeprowadzenia oszacowania. Występuje podobieństwo implementowanych

modułów, koncepcji, a niepewność występuje przede wszystkim na poziomie rozwiązań szczegółowych.

Przy estymacji czasów należy również uwzględnić efekt Parkinsona i syndrom stu-denta, które występują przede wszystkim przy wykonaniu projektu przez zasoby ludzkie i w związku z tym wskazane jest stosowanie agresywnych estymat czasów realizacji zadań. Ustalenie zbyt dużego czasu trwania czynności może spowodować niższą wy-dajność pracy (pracownik mógłby to zrobić szybciej, ale nie widzi takiej potrzeby – efekt Parkinsona i syndrom studenta). Z kolei przyjęcie zbyt małego czasu wykonania zadania może spowodować niską jakość zrealizowanego zadania (liczne błędy progra-mistyczne w wyniku pośpiechu pracownika) lub/i zakłócić realizację harmonogramu przez opóźnienia czasowe rozpoczęcia innych czynności.

Poziom ryzyka wykonania danego projektu IT może być wynikiem analiz, które od-powiedzą na takie pytania jak:

 czy projekt jest oparty na znanym sprzęcie i środowisku? czy pracownicy posiadają doświadczenie (szkolenia) do pracy w tym środowisku programistycznym?

 czy system jest podobny do wcześniej już zrealizowanych? jeśli odpowiedź jest twierdząca to, jaki był poziom przewidywalności czasów trwania czynności w zreali-zowanym systemie informatycznym?

Proponowane w pracy rozwiązania pozwalają prowadzić analizy zabezpieczenia umow-nych terminów w zależności od zmienności parametrów produkcyjumow-nych i mogą uwzględniać przyjęty poziom ryzyka związany ze zmiennością czasów trwania zadań.

Kolejnym z czynników uzasadniających zastosowanie modelu predyktywno-reaktywnego szeregowania zadań są korzyści wynikające ze stabilnej realizacji zadań. Dokładne wykonanie harmonogramu predyktywnego dla projektu informatycznego przynosi korzyści finansowe i organizacyjne. W projektach IT realizowanych zgodnie z planem istnieje możliwość koordynacji zasobów między różnymi projektami.

Założenia dotyczące kosztów niestabilności związanych z zadaniami poczynione w rozprawie mają uzasadnienie dla planowania projektów IT. Koszt niestabilności (opóźnień) jest większy dla zadań realizowanych przez większą liczbę zasobów (jak w funkcji celu predyktywno-reaktywnego harmonogramowania określonej wzorem 19). Zachodzi bowiem zależność: im większa liczba bezczynnych zasobów, tym większa strata firmy (utracone korzyści wynikające z ich pracy). Dla poszczególnych zasobów planowe przerwy w pracy nad danym projektem (bufory czasowe) mogą być wypełnio-ne zadaniami z innych przedsięwzięć, dla nieplanowych przerw jest to utrudniowypełnio-ne.

W fazie harmonogramowania reaktywnego podczas tworzenia systemu informatycz-nego przydatne jest podejście, w którym czynności przerwane przez czasową niedo-stępność zasobów (chorobę pracownika, awarię sprzętu) mogą być kontynuowane, tylko ich realizacja się wydłuża. Awarie sprzętu lub oprogramowania nie powodują koniecz-ności rozpoczęcia wykonywanego zadania od początku, gdyż każdy fragment kodu po-siada kopie bezpieczeństwa. Kod przetrzymywany jest na komputerach pracowników oraz w tzw. centralnym repozytorium (często aktualizowanym i archiwizowanym).

Analiza wykonana w tym rozdziale wskazuje na przydatność proponowanych roz-wiązań przy tworzeniu systemu informatycznego. Pokazano, że w każdej fazie podej-ścia predyktywno-reaktywnego (w harmonogramowaniu nominalnym, w odpornej alo-kacji zasobów, w odpornej aloalo-kacji buforów i w harmonogramowaniu reaktywnym) przy konstrukcji modeli i algorytmów uwzględniona jest specyfika realizacji projektów

7.3.2 Harmonogramowanie projektu budowlanego,