258 Metodyki zarządzania projektami informatycznymi

Tabela 9.1. Mapa procesów zarządzania projektem, (źródło: [AGUIOO])

Grupy procesów Obszary wiedzy	Inicja­cja	Planowanie	Wykonanie	Kontrola	Zakończe­nie
Zarządzanie integracją projektu		Rozwój planu projektu	Projekt planu wykonawstwa	Integracja kontroli zmian
Zarządzanie zakresem	Inicjacja	Planowanie zakresu Definicja zakresu		Weryfikacja zakresu Kontrola zmian za­kresu
Zarządzanie czasem		Definiowanie działań Kolejność działań Szacowanie czasu wykonania działań Harmonogramo-wanie		Kontrola harmono­gramu
Zarządzanie kosztem		Planowanie zasobów Szacowanie kosztów Budżetowanie		Kontrola kosztów
Zarządzanie jakością		Planowanie jakości	Zapewnienie jakości	Kontrola jakości
Zarządzanie zasobami ludzkimi		Planowanie organizacji Pozyskanie pracowników	Rozwój ze­społu
Zarządzanie komunikacją		Planowanie komunikacji	Dystrybucja informacji	Wykony­wanie raportów	Administro­wanie zam­knięciem
Zarządzanie ryzykiem		Planowanie za­rządzania ryzy­kiem Identyfikacja ryzy­ka Analiza ryzyka Ocena ryzyka Planowanie dzia­łań zapobiegaw­czych		Monitoro­wanie ryzy­ka
Zarządzanie dostawami		Planowanie do­staw Planowanie pozy­skiwania dostaw­ców	Pozyskiwanie dostawców Kryteria wybo­ru dostawcy Administrowa­nie kontraktem		Zamknięcie kontraktu

Metodyka punktów węzłowych ^ 259

W opisie znajdziemy specyfikacje dokumentów i produktów, które są Konieczne dla rozpoczęcia prac. Opisane są poszczególne aktywności po­dejmowane w ramach danego procesu oraz wyspecyfikowane produkty wyjścia powstałe w wyniku realizacji opisywanego procesu. W opisach pro­cesów wskazywane są sugerowane metody i techniki realizacji działań.

Wyspecyfikowane 39 procesów zostało ponadto pogrupowane w po­staci mapy w obszary wiedzy oraz przyporządkowane do opisanych grup procesów. Mapę tę przedstawia tabela 9.1.

Zawarte w pracach PMI wskazówki mają charakter ogólny i trudno jest nazwać to jednorodną metodyką postępowania w przypadku tworzenia projektu informatycznego. Przedstawione zasady są wypadkową wielu do­świadczeń z różnych obszarów aktywności i adaptacja ich na potrzeby konkretnego projektu jest zadaniem kierownika projektu. Bardziej zbliżone do praktyki realizacji projektów informatycznych są metodyki proponowane przez dostawców systemów informatycznych. Metodyki te najczęściej uwzględniają zasady ogólne opisane w przewodniku PMI, adaptując je do warunków projektów informatycznych.

9.2. Założenia metodyki punktów węzłowych

Metodyką tworzenia systemu informatycznego nazywamy zdyscyplino­wane, wykorzystujące określony cykl życia systemu oraz najczęściej wspomagane narzędziami komputerowymi, podejście do procesu realizacji projektu informatycznego. Metodyki powstają w wyniku uogólnionych do­świadczeń zebranych przy realizacji wielu projektów informatycznych. Kon­kretna metodyka wykorzystuje te doświadczenia i ustanawia procedury, które dają większą szansę uzyskania sukcesu projektu. Oprzyrządowanie stanowi, sprawdzone w innych projektach, procedury postępowania, zasa­dy organizacji zespołu i prac projektowych, dokumenty i normy wypraco­wane we wcześniejszych projektach. Korzystanie z doświadczeń wcze­śniejszych projektów pozwala na unikanie błędów oraz powielanie dobrych wzorców postępowania i praktyk działania. Doświadczenia każdego pro­jektu wzbogacają bazę danych wiedzy o realizacji projektów, w określonych unikalnych dla danej organizacji warunkach. Metodyki wypracowane w określonej organizacji mogą być adoptowane do innych organizacji i
warunków

260 Metodyki zarządzania projektami informatycznymi

wytwarzania, z racji podobieństwa problemów wynikających w pro­cesie realizacji systemu informatycznego, ale zebrane własne doświadcze­nia dają największą gwarancję poprawności realizacji projektu.

Metodyki powstają w wyniku kumulacji doświadczeń z wielu zrealizo­wanych projektów. Zarówno pozytywne jak i negatywne doświadczenia, analizowane przez wykonawców stanowią podstawę do decyzji przy pra­cach nad kolejnym projektem informatycznym. Opracowane procedury i miary pozwalają na lepsze szacowanie parametrów nowego projektu i podejmowanie lepszych decyzji w nowej sytuacji. Metodyka jest uzupeł­niana o nowe doświadczenia i żyje wraz z rozwojem firmy zbierającej do­świadczenia. Opracowanie pierwszej wersji metodyki wymaga dużego na­kładu pracy oraz posiadania wielu różnorodnych doświadczeń, które zo­stały nie tylko zebrane, ale również krytycznie przeanalizowane i opraco­wane. Potem należy metodykę ciągle pielęgnować, dodając nowe do­świadczenia, weryfikując wcześniejsze i modyfikować w miarę zmian w technologii informatycznej. Opracowanie i utrzymanie metodyki jest przedsięwzięciem kosztownym i trudnym merytorycznie.

Większość metodyk realizacji systemów informatycznych została opra­cowana przez duże firmy zajmujące się wytwarzaniem systemów informa­tycznych. Tylko one miały wystarczająco duży zasób doświadczeń oraz zespoły, które potrafiły utrzymywać metodykę w stanie nadążającym za zmianami technologii informatycznej. W Polsce prace takie były podejmo­wane, ale żadne z nich nie zakończyły się sukcesem, który pozwoliłby na wypracowanie metodyki o większej popularności. Koncentrowano się, w dużej mierze, na wypracowaniu jednorodnych standardów dokumenta­cyjnych oraz normalizacji cyklu życia systemu informatycznego. Były to uogólnione doświadczenia z realizacji systemów konkretnej branży, często wykorzystującej jednorodny sprzęt i oprogramowanie systemowe. Ambitne próby ujednolicenia podejmowały jednostki centralne funkcjonujące w in­formatyce lat ubiegłych, jak Zjednoczenie Informatyki, czy funkcjonujący w nim Ośrodek Badawczo-Rozwojowy informatyki. Opracowywano, publi­kowano i rozpowszechniano jednorodne standardy dokumentacyjne wytwa­rzanych systemów informatycznych. Prace te miały bardzo istotne znacze­nie na tym etapie rozwoju informatyki w kraju. Próby standaryzacji były dyskutowane i podejmowane przez środowiska naukowe, mające związki z praktykami realizacji systemów informatycznych. Przykładem takiej metodyki

jest metodyka punktów węzłowych powstała w szczecińskim środowi­sku informatyków skupionych wokół ośrodka ZETO oraz uczelni szczeciń­skich. W pracach tych byli zaangażowani informatycy z innych regionów przez udział w licznych konferencjach i seminariach organizowanych w kolejnych latach.

Konkretne metodyki różnią się specyfiką realizowanych projektów. Specyfika ta to wielkość projektów, założenia specjalne, typ projektu (wy­twarzanie, adaptacja, wdrożenie), czy też specjalne uwarunkowania reali­zacji. Metodyki najczęściej wykorzystują jeden z opisanych wcześniej cykli życia systemu i do danego cyklu życia dostosowane są procesy i procedury postępowania zespołu realizatorów. Różnice między metodykami polegają też na stopniu wspomagania i konkretnych narzędziach wspomagających daną metodykę. Chociaż funkcjonuje wiele narzędzi uniwersalnych, które są wykorzystywane w wielu metodykach, konkretne metodyki mają własne oprzyrządowanie narzędziowe. Przykładem uniwersalnych narzędzi wspo­magających harmonogramowanie są liczne produkty wspomagające two­rzenie i śledzenie prac projektowych. Metodyki mogą być różnie klasyfiko­wane i grupowane, ale powinny spełniać następujące wymagania:

• obejmować cały cykl życia systemu - od zdefiniowania problemu do pielęgnacji eksploatowanego systemu z jednoczesnym mechanizmem płynnego przejścia przez poszczególne fazy realizacji,

• proces tworzenia systemu powinien być wspomagany metodami, tech­nikami i narzędziami komputerowymi,

• powinien być łatwy mechanizm komunikowania się członków zespołu wykonawczego w procesie realizacji systemu,

• powinny być stosowane standardy, zapewniające łatwość uczenia się i stosowania w różnych środowiskach sprzętowo-programowych.

Przykładem metodyki wykorzystującej model kaskadowy może być metodyka punktów węzłowych, która przyjmując wszystkie cechy kaskado­wego postępowania proponuje uporządkowaną listę działań koniecznych

przy realizacji typowego systemu informatycznego przetwarzania danych [SZYJ94]. Lista działań powiązanych zależnościami przyczynowo-skutkowymi może stanowić przewodnik dydaktyczny dla mniej doświad­czonych twórców systemów informatycznych w pełnym cyklu realizacji systemu informatycznego.

Metodyka punktów węzłowych koncentruje się na zakresie wykonywa­nych prac, czyli określone są działania odpowiadające na pytanie „co?", należy wykonać. Metodyka nie daje odpowiedzi na pytanie „jak?" należy dane prace wykonać. Sposób realizacji pozostaje indywidualną decyzją kierownika projektu, który wybiera najlepsze, w konkretnym przypadku, narzędzia realizacji prac. Takie podejście uniezależnia metodykę od roz­woju technologii wytwarzania, która dostarcza coraz to nowsze, wydajniej­sze narzędzia realizacji zadań określonych na liście prac. W konkretnym przypadku modyfikacji może ulec zaproponowana w metodyce lista zadań, ale łatwiej jest modyfikować istniejącą listę niż konstruować ją samemu od początku. Przedstawiona w metodyce lista działań jest powiązana zależno­ściami przyczynowo-skutkowymi, określając zalecany porządek realizacji. Sieć czynności do realizacji dodatkowo jest pogrupowana w kilka pozio­mów ogólności, co pozwala na wybór odpowiedniego poziomu szczegóło­wości, w zależności od szczebla zarządzania projektem. Głębokość de­kompozycji poszczególnych zadań zależy od konkretnego projektu, należy jedynie przestrzegać ogólnych zasad dekompozycji opisanych wcześniej. Nadmiarowość listy zadań nie zwalnia z obowiązku dogłębnej analizy kon­kretnego projektu i należy traktować ją jako pomocny wzorzec, który trzeba dostosować do konkretnych warunków realizowanego projektu.

9.3. Lista zadań do realizacji

Przedstawiony model określa kaskadę działań typową dla większości systemów informatycznych przetwarzania danych. W przypadku konkret­nego projektu informatycznego należy wybrać odpowiedni podzbiór czyn­ności koniecznych do realizacji w tym konkretnym przypadku. Może istnieć potrzeba poszerzenia listy na pewnych poziomach dekompozycji lub elimi­nacji wymienionych na liście prac. Konkretne decyzje, co do ostatecznego kształtu listy zadań podejmowane są w zespole wykonawczym. Metodyka określa związki między wymienionymi czynnościami, dodatkowo czynności te są uszczegółowione na kilku poziomach. Konkretny układ czynności mo­że być dowolnie rozszerzony lub ograniczony do niezbędnego zestawu działań. Konkretne prace wykonywane w ciągu działań pogrupowane zo­stały w punkty węzłowe czyli takie zespoły czynności, które kończą się konkretnym produktem, odpowiednio dokumentowanym.

Walor praktyczny metodyki punktów węzłowych, stanowi sieć powiązań punktów węzłowych. Analiza sieci powiązań pozwala na odpowiednią, dla konkretnej sytuacji, organizację procesu realizacji również dla mniej do­świadczonych wykonawców. Określenie dla każdego punktu węzłowego listy poprzedników i następników pozwala na sprawną organizacje prac w związku z otwierającym się frontem prac, jak również ułatwia działania kontrolne w poszczególnych etapach realizacji. Analizując sieć zależności można jednoznacznie określić jakie działania powinny być zakończone przed rozpoczęciem prac nad każdym z wymienionych punktów węzło­wych. Wiedza o zalecanej kolejności realizacji pozwala na prawidłową, z punktu widzenia technologii wytwarzania, organizację prac i optymalne wykorzystanie zasobów. Zaznaczone związki mają charakter technologicz­ny i wynikają z zależności produktowej. Produkty poprzednika stanowią podstawę prac następnika proponowanej sieci zależności.

Rysunek 9.8 przedstawia pełną listę zadań na pierwszym poziomie de­kompozycji. Każde z wymienionych zadań jest dalej dekomponowane na zadania składowe. Fragment takiej próby dekompozycji do drugiego poziomu przedstawiony jest na rysunku 9.9. Występujące na drugim poziomie zadania mogą być dalej dekomponowane na prace bardziej szczegółowe.

Rysunki wykasowałyśmy bo nie było się ich jak odczytać

Listy zadań składające się na propozycje zawarte w metodyce punktów węzłowych prezentowane są w postaci zapisanej w MS Project. Podane czasy realizacji są przykładowe i dla konkretnego projektu estymacja czasu wykonania każdego z zadań musi być określona przez zespół realizatorów. Na rysunku zaznaczone zostały związki przyczynowo-skutkowe między zadaniami.

Rysunek wykasowany 9.9 ze względu na brak czynności

Pełna lista zadań wyspecyfikowana w metodyce punktów węzłowych, z podziałem na dwa poziomy szczegółowości jest następująca:

010 Zgłoszenie potrzeby

020 Analiza problemu

021 Badanie możliwości i sposobu rozwiązania problemu

022 Analiza wariantów rozwiązań I ofert

023 Ocena opłacalności

• możliwości realizacji

030 Zdefiniowanie zadania projektowego

• Uwarunkowania

• Główne funkcje systemu

• Powiązania z innymi systemami

• 
  Zakres prac projektowych

• Umowa

040 Opis stanu istniejącego

• Charakterystyka stanu organizacji

• Charakterystyka danych

• Strumienie informacyjne

• Opis algorytmów

050 Analiza stanu istniejącego

• Analiza stanu organizacji

• Analiza danych

• Analiza strumieni informacyjnych 060 Koncepcja systemu informatycznego

• Zakres systemu - struktura funkcjonalna

• Struktura informacyjna

• Struktura techniczna

• Struktura przestrzenna

• Obraz funkcjonowania systemu

• Założenia organizacyjne systemu

• Założenia ekonomiczne systemu 070 Normatywy

• Normatywy komunikowania się z innymi systemami

• Zasady budowy nazw w systemie

• Normatywy wydawnictw i wprowadzania danych

• Normatywy dokumentowania

• Normatywy technologii przetwarzania

• Normatywy programowania

• Protokoły transmisji

• Normatywy identyfikacji zbiorów danych 080 Projekt struktury informacyjnej

• Projekt wyjść

• Projekt systemu kodów

• Projekt wejść

• Struktura logiczna danych

• Projekt zbiorów podstawowych 090 Projekt technologii przetwarzania

091 Wybór technologii

• Podział systemu na jednostki technologiczne

• Projekt schematu przetwarzania

• Projekt zbiorów roboczych

• Projekt struktury przestrzennej

• Projekt struktury technicznej 100 Synteza projektu

• Synteza struktur systemu

• Organizacja funkcjonowania systemu oraz koszty jego eksploatacji

• Projekt zmian w organizacji obiektu i wymagania wdrożeniowe

• Harmonogram i preliminarz prac programowo-wdrożeniowych

• Koszty i efekty

110 Projekt oprogramowania

• Założenia ogólne oprogramowania systemu

• Założenia do programów

• Specyfikacja algorytmów

• Zdefiniowanie struktury danych

• Projekt modułów oprogramowania

• Projekt technologii produkcji oprogramowania

120 Oprogramowanie wykonanie

• Wykonanie modułów wspólnych

• Wykonanie opisu struktur danych

• Wykonanie programów

• Testowanie pojedynczych modułów i programów

• Testowanie całego systemu oprogramowania

• Skompletowanie dokumentacji programów

130 Organizacyjne przygotowanie obiektu

• Pozyskanie zasobów

• Pracochłonność i koszty wdrożenia

• Pracochłonność i koszty eksploatacji

• Przygotowanie kadr

• Baza normatywna systemu - opracowanie

• Podstawy prawne wdrożenia i eksploatacji

140 Eksperyment na danych modelowych

• Opracowanie eksperymentu

• Wykonanie eksperymentu

• Analiza wyników eksperymentu

• Wnioski wypływające z eksperymentu 150 Instalacja systemu

• Zawarcie umowy o eksploatację

• Biblioteki programów

• Zbiory kartotekowe

• Inicjacja taśm, dysków, kartotek

• Implementacja technologii w konkretnym ośrodku

160 Wdrożenie pilotowe

• Wybór metody wdrażania

• Opracowanie kryterium oceny

• Eksploatacja pilotowa systemu

• Ocena wyników eksploatacji pilotowej

• Rozpowszechnienie systemu 170 Projekt eksploatacyjny

• Aktualna dokumentacja systemu

• Instrukcje wypełniania i obiegu dokumentów

• Instrukcje tworzenia maszynowych nośników

• Instrukcja kompletacji i kontroli danych wejściowych

• Instrukcja operowania systemem

• Instrukcja kompletacji i kontroli danych wyjściowych 177 Instrukcje instalacyjne

180 Eksploatacja i rozwój

Zaproponowana lista punktów węzłowych może być dalej dekompono-wana, na kolejnych poziomach, bez obawy zaburzenia struktury całości. Zgodnie z wcześniej określonymi zasadami dekompozycji wskazane jest, aby nie przekraczać czwartego poziomu. Ułożenie zadań w proponowanej liście zakłada kaskadowy sposób realizacji zadań, stąd pierwszym punktem węzłowym jest zgłoszenie potrzeby wprowadzenia zmiany, a ostatnim eks­ploatacja i rozwój systemu informatycznego.

Zgłoszenie potrzeby oznacza inicjację procesu projektowego. Nieza­leżnie od motywacji przyświecającej zgłoszeniu zmiany, sam ten fakt staje się początkiem działań zmierzających do wytworzenia systemu informa­tycznego.

Zgłoszona potrzeba wprowadzenia określonej zmiany wymaga prze­prowadzenia badań i analiz, których celem jest określenie możliwości i uwarunkowań realizacji. Prace wykonywane na tym etapie mają za zada­nie dostarczenie danych do zdefiniowania zadania projektowego. Analizo­wane są różne sposoby wprowadzenia sugerowanej zmiany oraz opłacal­ność ekonomiczna przedsięwzięcia. Zawartość informacyjna dokumentacji wykonanej na tym etapie powinna odzwierciedlać kierunki prowadzonych analiz oraz materiały źródłowe i wyciągnięte wnioski.

Zdefiniowanie zadania projektowego jest wynikiem prac analitycznych i określa wstępny zakres systemu i koniecznych do wykonania prac pro­jektowych. Opisane są uwarunkowania wykonania projektu; będą to czyn­niki organizacyjne, sprzętowe, finansowe, kadrowe, prawne oraz spodzie­wany wpływ otoczenia biznesowego. Definiujemy główne funkcje systemu, co wyznacza zakres zmiany oraz powiązania z innymi systemami.

Opis stanu istniejącego sprowadza się do opisu aktualnego stanu or­ganizacji i tych elementów, które są istotne z punktu widzenia rozpoczyna­nego projektu. W szczególności opisujemy wykorzystywane dane i stru­mienie informacyjne oraz algorytmy ich przetwarzania. Opisy te mają sta­nowić podstawę prac projektowych. Lokalizowane są miejsca ujęcia da­nych, postać graficzna dokumentów, określana jest liczebność i format da­nych wykorzystywanych w dotychczasowym systemie.

Wykonany opis poddawany jest krytycznej analizie z punktu widzenia zmiany wprowadzanej projektem. Formaty danych, ich miejsca ujęcia i strumienie zbieranych danych są oceniane z punktu widzenia nowych sposobów ich zbierania i przetwarzania. Najczęściej jest to związane z inną postacią graficzną, nowymi możliwościami sprzętowymi i zmodyfikowanymi strumieniami przepływu danych. Analiza powinna mieć charakter globalny i należy uwzględniać nie tylko nowe możliwości wynikające z technologii, ale również z nowych rozwiązań biznesowych. W wyniku analizy może po­wstać zupełnie nowy model zbierania i przetwarzania danych oraz inna ich zawartość merytoryczna. Podstawą analizy są nowe procesy wprowadzane projektowanym systemem informatycznym.

Analiza opisu stanu obecnego jest podstawą do koncepcji nowego systemu. Koncepcja jest udokumentowanym opisem proponowanej zmiany z uwzględnieniem sugerowanych rozwiązań biznesowych i technicznych.

W szczególności opisana jest funkcjonalność nowego systemu. Opisane są wszystkie funkcje, jakie będą realizowane przez powstający system. Funk­cje te mają zaspokajać potrzeby użytkownika i w całości pokrywać nowe rozwiązanie biznesowe. Na potrzeby proponowanej funkcjonalności defi­niowana jest struktura informacyjna systemu, zarówno w sensie zawartości merytorycznej, jak i rozwiązań technicznych. Opis rozwiązania techniczne­go dotyczy nie tylko zbierania i dystrybucji danych, ale również przetwarza­nia, archiwizowania i integracji danych. Najczęściej związane to jest z roz­proszeniem terytorialnym, co zmusza nas do dokładnego opisu struktury przestrzennej w sensie geograficznym i merytorycznym. W koncepcji po­winny być nie tylko zdefiniowane i opisane ujęcia danych, ale również pro­ponowane rozwiązania technologii przetwarzania danych.

Opis koncepcji systemu informatycznego zamyka ten etap prac i roz­poczyna etap wykonawczy, gdzie większość działań to czynności rutynowe. W trakcie tych prac korzysta się z unifikacji i standaryzacji pewnych rozwią­zań. Jakie standardy i w jakim zakresie będą stosowane w procesie wytwa­rzania, należy zdecydować i udokumentować przed przystąpieniem do wy­konania. Normatywy wykorzystywane w procesie realizacji mogą dotyczyć wielu obszarów aktywności, od metodyki zarządzania projektem do szcze­gółowych rozwiązań programistycznych. Często przyjęcie jednego standar­du wymusza stosowanie innych lub zarządzenia wewnętrzne zmuszają do stosowania pewnych zunifikowanych rozwiązań. W dokumentacji systemu powinna znaleźć się informacja o tym jakie standardy mają zastosowanie w realizowanych projekcie oraz jakie są przesłanki takiej decyzji.

Kolejne punkty węzłowe to techniczna realizacja koncepcji i wykonanie zapisanych tam rozwiązań. W szczególności uszczegóławiana jest struktu­ra informacyjna projektu. Szczegółowy projekt techniczny opisuje wszystkie zastosowane rozwiązania technologii zbierania, przetwarzania i przecho­wywania danych wraz z ich dokładnym opisem, szatą graficzną i innymi wymogami koniecznymi do realizacji programowej.

W innym punkcie opisujemy szczegóły technologii obliczeń i przetwa­rzania w systemie informatycznym. Częstotliwość pozyskiwania danych, ich sposób ujmowania i przetwarzania, okresy archiwizacji, procesy integracji i inne działania manipulacji na danych wraz z algorytmami, stanowią tę część dokumentacji i realizowanych prac. Wykorzystywany sprzęt komputerowy oraz oprogramowanie operacyjne stosowane w systemie, powinny być zaimplementowane do potrzeb wytwarzanego systemu.

W projektach inwestycyjnych bardzo ważnym dokumentem są założe­nia techniczno-ekonomiczne przedsięwzięcia. Wydaje się, że opracowanie podobnego dokumentu, stanowiącego syntezę wykonanych już prac, jest wskazane dla uzyskania wymaganej jakości systemu informatycznego. Dokument taki pozwoli zespołowi wykonawców jasno zdefiniować zakres prac do wykonania, natomiast przyszły użytkownik systemu będzie miał świadomość, jakie działania pozostają w jego kompetencji oraz jakie będą ponoszone koszty eksploatacji i efekty stosowania projektowanego rozwią­zania. W dokumencie tym można zawrzeć warunki odbioru prac oraz wszelkie ustalenia kończące projekt.

Po akceptacji syntezy projektu przez strony przedsięwzięcia, pozostaje realizacja zapisanych tam rozwiązań. Przystępujemy do prac wykonaw­czych nad oprogramowaniem, które są poprzedzone pracami planistycz­nymi samej realizacji programów składających się na system. Planujemy metodę wytwarzania oprogramowania, rozdzielamy prace i określamy za­sady wytwarzania, testowania i integracji. Kolejny punkt węzłowy to współ­bieżna realizacja poszczególnych programów składających się na system. Ta faza prac przysparza najwięcej problemów i jest szczególnie trudna z uwagi na złożoność i ujawnianie się niezgodności i usterek powstałych wcześniej. Ten etap prac bardzo często decyduje o ostatecznym sukcesie projektu informatycznego oraz o jego ostatecznej jakości.

Równocześnie można rozpocząć prace przygotowawcze w obiekcie, gdzie będzie wdrażany system informatyczny. W zależności od konkretne­go systemu zakres tych prac może być bardzo różny. Może zaistnieć, na przykład, potrzeba budowy ośrodka obliczeniowego, sieci komputerowej, instalacji sprzętu, dokonania adaptacji i zmian organizacyjnych na potrzeby wdrożenia i przyszłej eksploatacji systemu informatycznego. Należy doko­nać odpowiednich zmian organizacyjnych, szkoleń kadry obsługującej system informatyczny, opracować i wdrożyć przepisy prawne warunkujące eksploatację systemu. Przygotować organizacyjnie przyszły proces eksplo­atacji systemu ze wszystkimi szczegółami techniczno-organizacyjnymi, regulaminami, instrukcjami, zakresem odpowiedzialności.

Wykonanie oprogramowania i przygotowanie obiektu pozwala na prze­prowadzenie eksperymentu na danych modelowych. Na wcześniej przy­gotowanym zbiorze danych modelowych sprawdzana jest poprawność oprogramowania i procedur organizacyjnych. Jest to próba generalna przed wdrożeniem systemu do eksploatacji użytkowej. Integracja wykonywanych współbieżnie prac pozwala sprawdzić nie tylko poprawność wykonania tych prac, ale i współdziałanie zgodnie z założeniami projektu. W tym punkcie węzłowym usuwane są wszelkie usterki oraz przygotowywana jest eksplo­atacja systemu.

Instalacja systemu to wykonanie czynności początkowych polegających na instalacji oprogramowania systemowego i użytkowego. Instalacja zbio­rów z danymi na określonych nośnikach, instalacja sprzętu komputerowego i sieciowego oraz wdrożenie przygotowanych procedur organizacyjnych.

Wdrożenie systemu polega na ostatecznym przejściu z dotychczaso­wego sposobu prac na nowy wprowadzany zgodnie z założeniami projektu. Procesy wdrożeniowe, mają na celu dopasowanie szczegółów organizacyj­nych i technicznych eksploatacji nowego rozwiązania. W procesie tym sku­piają się wszystkie prace wykonywane w trakcie realizacji przedsięwzięcia i sprawdzane jest ich współdziałanie na potrzeby założonych celów.

Na etapie końcowych prac realizacyjnych przygotowywane są doku­menty i instrukcje konieczne dla sprawnej eksploatacji systemu informa­tycznego. Wykonane opracowania mają nie tylko gwarantować sprawną eksploatację, ale również niezbędne informacje techniczne konieczne w sytuacjach awaryjnych oraz na potrzeby modyfikacji i rozwoju systemu.

W projekcie powinien być opisany system zbierania informacji eksplo­atacyjnych. Każdy system informatyczny powinien być modyfikowany i rozwijany nie tylko z powodu szybkich zmian w technologii informatycznej, ale również na skutek nowych potrzeb biznesowych użytkownika. Modyfi­kacje mogą być wykonywane na bieżąco w trakcie procesu eksploatacji lub zbierane i wprowadzane jednorazowo jako samodzielny projekt modyfiku­jący wykonany wcześniej system.

Przedstawiona lista punktów węzłowych rozwinięta do drugiego pozio­mu, może stanowić wzorzec zakresu prac dla systemów informatycznych realizowanych w pełnym cyklu życia w przypadku systemów przetwarzania danych. Proponowana lista może być dowolnie uzupełniana i modyfikowa­na zależnie od potrzeb konkretnego systemu. Ponadto metodyka punktów węzłowych przedstawia sieć zależności przyczynowo-skutkowych między zadaniami występującymi na liście.

9.4. Sieć zależności przyczynowo-skutkowych

Kolejność realizacji poszczególnych prac w systemie informatycznym jest ustalana indywidualnie dla każdego systemu w zależności od konkret­nych warunków realizacji. Uwarunkowania realizacyjne i przyjęta taktyka wykonawcza decydują o tym, w jakiej kolejności wykonywane są prace. Taktyka realizacji musi jednak przestrzegać zależności technologicznych między poszczególnymi pracami. Dla realizacji konkretnych zadań potrzeb­ne są produkty innych prac i stąd powstaje konieczność wcześniejszego ich wykonania. Te związki technologiczne muszą być zachowane w procesie realizacji systemu informatycznego. Dla ułatwienia pracy zespołowi wyko­rzystującemu metodykę punktów węzłowych, wskazuje się związki techno­logiczne między zadaniami. Utworzona jest sieć działań, gdzie zadania powiązane są związkami przyczynowo-skutkowymi. Dla każdego zadania zostaje określony poprzednik i następnik wśród zadań z listy. W ten sposób powstaje sieć zależności określająca konieczną technologię realizacji prac zapisanych na liście.

Rysunek 9.10 przedstawia fragment zależności przyczynowo-skutkowych między zadaniami zapisanymi w postaci sieci w programie MS Project, czyli oprogramowaniu wspomagającym prace planistyczne i śledzenie realizacji projektu, wykorzystywanym dla proponowanej wzor­cowej hierarchicznej struktury prac. Na potrzeby konkretnego projektu wy­starczy uzupełnić podaną strukturę prac zgodnie z listą zadań konkretnego systemu informatycznego oraz wprowadzić szacowane czasy realizacji zadań i przydział zasobów, aby uzyskać gotowy materiał do śledzenia pro­jektu z wykorzystaniem oprogramowania MS. Project.

Rys 9.10 wykasowany z powodu braku czytności

Metodyka punktów węzłowych jest próbą strukturalizowania prac wy­konywanych w procesie realizacji typowego systemu przetwarzania da­nych. Zaznaczone związki przyczynowo-skutkowe oraz odpowiednio dekomponowana lista zadań stanowią przewodnik lub wzorzec przy realizacji konkretnego systemu informatycznego. Dobór metod i technik realizacji konkretnych zadań, wybór narzędzi wspomagających prace, rozwiązania szczegółowe pozostawia się realizatorom systemu.

Metodyka punktów węzłowych koncentruje się jedynie na realizacji systemu informatycznego, całkowicie pomijając problemy organizacji ze­społu projektowego, komunikacji, zarządzania ryzykiem w projekcie, zmia­nami, czy innymi zagadnieniami istotnymi z punktu widzenia zarządzania projektem [SZYJ01]. W związku z tym należy to podejście traktować jako próbę opracowania metodyki, a nie pełnowartościową metodykę realizacji systemu informatycznego, ale zarazem obrazuje to skalę problemów jakie stoją przed zespołami, które opracowują i utrzymują w stanie aktualnym inne metodyki realizacji systemów informatycznych.

---