107

Marian KOPCZEWSKI1), Ewa CZAPIK-KOWALEWSKA, Joanna KRAWCZYK2)

1)Wyższa Szkoła Bezpieczeństwa, 2) Instytut Polityki Społecznej i Stosunków Międzynarodowych, Politechnika Koszalińska

E-mail:marian.kopczewski@tu.koszalin.pl

Wybrane elementy zarządzania projektem informatycznym

Streszczenie: Artykuł prezentuje porównanie wybranych metodyk zarzą-dzania projektami informatycznymi. Przedstawiono również podstawowe pojęcia związane z prowadzeniem przedsięwzięcia z uwzględnieniem ta-kich kryteriów oceny jak czas, koszt i jakość projektu.

1. Wstęp Definicję procesu zarządzania projektem informatycznym, która w prosty i trafny spo-sób opisuje to zagadnienie, przedstawił Wiliam Duncan. Pisze on, że zarządzanie pro-jektem polega na zastosowaniu wiedzy, umiejętności, narzędzi i technik w działaniach projektowych w celu osiągnięcia korzyści, jakich współuczestnicy spodziewają się w związku z realizacją projektu. Osiągnięcie oczekiwanych korzyści wymaga odpo-wiedniego współdziałania w następujących aspektach:

• zakres, czas, koszt i jakość, • różne oczekiwania i uwarunkowania współuczestników projektu, • zidentyfikowane i niezidentyfikowane wymagania użytkownika [4].

2. Cykl życia projektu i cele przez niego wyznaczone Cele projektu określa się na samym początku procesu. Prawidłowa realizacja tej fazy warunkuje podejmowane decyzje i w sposób istotny wpływa na sukces całego projektu. Rezultatem każdego zdefiniowanego projektu jest wprowadzenie przewidywanej zmia-ny. Ilustruje to rysunek 1.

Według Szyjewskiego celem projektu jest szybkie wprowadzenie zmiany w ściśle okre-ślonym terminie i w założonym zakresie. Służy to osiągnięciu nowej jakości, która wyraża się najczęściej zyskami i korzyściami wynikającymi z wprowadzonych zmian. Natomiast cele nie polegają na udanym jednorazowym uruchomieniu systemu informa-tycznego, ale na użytkowaniu produktu w celu polepszenia efektów podstawowej dzia-łalności firmy [25].

108

Rys. 1. Projekt a zmiana

W definicji projektu podkreślony został czasowy charakter i unikalność prac realizo-wanych w ramach prac projektowych. Określone terminy rozpoczęcia i zakończenia prac projektowych wyznaczają ramy czasowe realizacji projektu. Ta cecha pozwala w sposób jednoznaczny odróżnić działania nowatorskie, mające na celu wprowadze-nie zmiany, od użytkowania, czyli eksploatacji wdrożonej zmiany.

Z unikalnością projektu wiąże się niepewność dotycząca poprawności działań i ich rezultatów. W celu minimalizowania niepewności organizacje realizujące projekt dzielą każdy projekt na fazy, co pozwala lepiej zarządzać procesem wykonawczym i lepiej dopasować nowy produkt do potrzeb organizacji. Całość tych działań, czyli wszystkie fazy składające się na projekt, określa się jako cykl życia projektu.

Istnieją różne sposoby podziału projektu na fazy. Istotne jest, aby podział pozwalał lepiej zrozumieć proces tworzenia nowego produktu i efektywnie zarządzać proce-sem. Ważnym warunkiem podziału jest wymóg, aby każda faza projektu kończyła się wytworzeniem konkretnego produktu. Kolejne fazy pozwalają również na modyfika-cję celów projektu oraz stwierdzenie prawidłowości podejmowanych działań. Termin rozpoczęcia projektu wyznacza data rozpoczęcia cyklu życia, a termin zakończenia jest datą zakończenia cyklu życia projektu. Intensywność prac projektowych i zaan-gażowanie środków jest różne w różnych fazach cyklu życia projektu.

Rysunek 2 ilustruje niską intensywność prac projektowych w początkowej i końcowej fazie cyklu życia oraz dużą intensywność prac w środkowych fazach realizacji. Wyda-je się to dość naturalne z uwagi na przedstawioną charakterystykę projektu. Na po-czątku należy, bowiem wykonać wiele prac przygotowawczych i stworzyć fundamen-ty dla pracy zespołów wykonawczych, natomiast na zakończenie wykonywane są prace sumujące i umożliwiające zamknięcie projektu.

109

Rys. 2. Cykl życia projektu

Dla projektów informatycznych najbardziej reprezentatywny jest model zaproponowany przez Morrisa [17]. Autor ten wyróżnił następujące fazy:

1. studium wykonalności projektu (feasibility study), 2. planowanie i projektowanie (planning and desigri), 3. wykonanie (production), 4. wdrożenie (turnover and startup).

Element niepewności, którego nie jesteśmy w stanie wyeliminować, stanowi zagrożenie niedotrzymania jednego z parametrów charakteryzujących projekt – zakresu, terminów lub budżetu. Przekroczenie jednego z parametrów ma wpływ na pozostałe, które są możliwe do zmodyfikowania w procesie realizacji. Nie pozostaje to jednak bez wpływu na wynik końcowy, czyli na cel projektu. Najczęściej celem projektu jest osiągnięcie zysków. Kolejne rysunki przedstawiają, jak przekroczenie każdego z parametrów defi-niujących projekt, przy zachowanych dwóch pozostałych, wpływa na korzyści przewi-dywane w związku z wdrożeniem projektu.

Rys. 3. Czas a zyski

Rysunek 3 ilustruje sytuację, w której zostaje przekroczony czas realizacji projektu. W sposób oczywisty następuje wydłużenie czasu osiągnięcia korzyści. W przypadku projektów gdzie termin realizacji jest życiowo ważnym parametrem, konsekwencje mogą być znacznie większe. Niedokończenie inwestycji na czas może spowodować, że

110

konkurencja uzyska przewagę na rynku, co ma duże znaczenie w warunkach gospodarki rynkowej i w staraniach o zdobycie nowych rynków.

Rys. 4. Zakres a zyski

Rysunek 4 przedstawia efekty wynikające z ograniczenia zakresu prac projektowych. Sytu-acja taka przyczynia się do zmniejszenia korzyści związanych z wdrożeniem projektu.

Rys. 5. Koszty a zyski

Rysunek 5 przedstawia sytuację, w której przekroczone zostały koszty (budżet projek-tu). Rezultatem jest wydłużenie czasu osiągania korzyści, co oznacza, że zwrot z inwe-stycji informatycznej zostanie uzyskany później [25].

3. Organizacja i zarządzanie projektem Zdefiniowane cele działań projektowych wyznaczają zakres prac projektowych. Zakres projektu pozwala określić pozostałe dwa kluczowe parametry projektu. Metody stoso-wane w celu zdefiniowania zakresu projektu mogą decydować o końcowym sukcesie. Zarządzanie zakresem nie jest jednorazowym aktem, ale powinno trwać przez cały okres realizacji projektu. W szczególności dotyczy to zarządzania zmianami generowa-nymi w trakcie realizacji i zgłaszanymi przez przyszłego użytkownika. Kolejnym istot-nym parametrem definiującym projekt jest czas realizacji. Wyliczanie czasu realizacji projektu, harmonogramowanie prac, śledzenie postępu prac i reagowanie na odchylenia to główne problemy związane z zarządzaniem czasem. Trzecim parametrem są koszty realizacji. Zarządzanie finansami projektu wymaga, aby kierownik projektu nie tylko miał podstawową wiedzę ekonomiczną, ale również współdziałał z innymi służbami organizacji, dla której realizowany jest projekt. Inwestycje informatyczne są stosunko-

111

wo drogie i problem zarządzania kosztami jest ważnym czynnikiem realizacji projektu. W niektórych definicjach projektu wyróżniany jest czwarty parametr – jakość produktu. Niezależnie od sposobu rozumienia parametrów projektu, problemy jakości w przypad-ku systemów informatycznych mają szczególną wagę i powinny podlegać umiejętnemu zarządzaniu.

Realizacja projektu, czyli wykonanie kolejnych działań, wymaga odpowiedniego anga-żowania zasobów. Podstawowym zasobem są ludzie, a sposób organizowania ich pracy oraz metody motywowania do pełnej wydajności to kolejne problemy zarządzania. Oprócz ludzi angażowane są różne narzędzia i sprzęt. Umiejętne zarządzanie zasobami stanowi warunek zgodności z podstawowymi parametrami projektu.

Niezależnie od poprawności wykonania wszystkich działań, zawsze pozostaje pewien margines ryzyka niepowodzenia. Identyfikacja obszarów ryzyka, oszacowanie wpływu zagrożenia na proces realizacji i podejmowanie działań zaradczych to problemy z dzie-dziny zarządzania ryzykiem [25].

Zarządzanie projektem wymaga odpowiedniej organizacji prac projektowych. Projekty są opracowywane w celu zwiększenia efektywności prowadzonej działalności. Systemy informatyczne najczęściej mają za zadanie wspomagać zarządzanie firmą. Opracowanie systemu informatycznego, a następnie wdrażanie go do eksploatacji odbywa się w ak-tywnym otoczeniu gospodarczym, co stanowi istotną trudność realizacyjną. Zjawisko to ilustruje rysunek 6.

Rys. 6. Miejsce projektu w otoczeniu

Opracowywany produkt końcowy, będący wynikiem działań projektowych, na etapie realizacyjnym jest chroniony przed negatywnym wpływem otoczenia przez system zarzą-dzania projektem. Po zakończeniu prac projektowych wykonany produkt powinien zinte-grować się z otoczeniem bez zakłócania jego działania i przynosić korzyści zdefiniowane na etapie ustanawiania projektu. System zarządzania projektem stanowi warstwę ochronną podczas realizacji, ale zmusza do takiego przygotowania produktu końcowego, aby mógł on bez problemów włączyć się w przyszłe środowisko funkcjonowania.

112

Rysunek 7 przedstawia schemat organizacyjny zespołu realizującego projekt informa-tyczny. Na schemacie tym występują nazwy funkcji sprawowanych przez określone osoby, których działalność jest kluczowa dla realizacji prac projektowych. Osoby te to: sponsor projektu, kierownik projektu, kierownicy podprojektów, osoby zewnętrzne, komitet sterujący, biuro projektu, zespół zapewnienia jakości.

Rys. 7. Schemat organizacyjny projektu

W zależności od wielkości realizowanego projektu określenia funkcji można rozumieć jako role. Role te można obsadzić jedną osobą lub zespołem w zależności od ilości zadań, ale również można wyobrazić sobie sytuacje, w których jedna osoba odgrywa więcej niż jedną rolę.

Schemat organizacyjny wskazuje na kluczową rolę kierownika projektu, na tej funkcji, bowiem koncentruje się większość powiązań [25].

Innym interesującym blokiem na schemacie jest „komitet sterujący” zawierający kilka ról. Kluczową osobą w komitecie sterującym jest sponsor. Sponsorem najczęściej jest osoba, która wygenerowała projekt i jest szczególnie zainteresowana osiągnięciem celów projektu. Osoba ta jest dysponentem środków pozwalających na realizację prac projektowych, rozporządza więc finansami, ale również często innymi zasobami istot-nymi dla realizacji projektu. Do sponsora więc, jako do ostatniej instancji, może zwra-cać się kierownik projektu w sytuacjach, gdy jego kompetencje nie wystarczają, aby rozwiązać problemy powstałe w trakcie realizacji projektu. Z racji swej pozycji sponsor jest aktywnym uczestnikiem procesu realizacji. Najczęściej nie pełni funkcji wykonaw-cy, ale aktywnego obserwatora postępu prac. Wiedza fachowa sponsora jest wzbogaco-na wiedzą ekspertów powoływanych w różnych fazach realizacji projektu. Sponsor kieruje się również opinią przyszłego użytkownika wykonywanego produktu czy też opiniami innych kluczowych osób na temat wdrożenia innowacji będącej przedmiotem prac projektowych. Ten zespół osób stanowi komitet sterujący i jest najwyższą władzą dla projektu. Członkowie tego zespołu podejmują kluczowe decyzje związane z kształ-tem projektu i jego kluczowymi parametrami, rozwiązują problemy istotne dla całego przedsięwzięcia oraz wydają wiążące rozporządzenia.

113

Wskazywaliśmy już na istotną rolę problemów jakości. Z uwagi na zapewnienie wyma-ganych parametrów jakościowych realizowanego produktu wskazane jest powołanie specjalnego zespołu. Zadaniem zespołu jest wspomaganie kierownika projektu i komite-tu sterującego w sprawach związanych z zagwarantowaniem odpowiednich parametrów jakości. Podwójna podległość zespołu decyduje o jego ograniczonej niezależności, co powinno wpływać na jakość pracy.

Sponsor zleca wykonanie ekspertyz z postępu prac z punktu widzenia jakości, aby skon-trolować działania kierownika projektu, natomiast kierownik projektu otrzymuje infor-macje o pracy kierowników podprojektów w sytuacjach, gdy istnieje podejrzenie, że prace w podprojektach nie spełniają norm jakościowych.

Należy zwrócić uwagę, że przedstawiona struktura organizacyjna ma charakter czaso-wy. Struktura ta powstaje w momencie ustanowienia projektu i jest rozwiązywana w momencie zakończenia prac projektowych. Do zespołu projektowego przydzielani są pracownicy wykonujący na co dzień inne zajęcia. Stanowi to dodatkowe, istotne uwa-runkowanie organizacyjne, ponieważ większość członków zespołu projektowego uczestniczy równocześnie w rutynowych, normalnych pracach. Podporządkowanie większości członków zespołu dwóm różnym kierownikom, zlecającym inne zadania, wpływa na wydajność zespołu projektowego i jego zaangażowanie w pracę.

O strukturze organizacji decyduje kierownik projektu i on kieruje bieżącą pracą zespołu. Czynnik czasowego działania zespołu jest dodatkowym elementem, który może obniżać motywację do wydajnej pracy. Nierównomierność obciążenia pracą członków zespołu w kolejnych fazach realizacji projektu zmusza do angażowania pracowników równo-cześnie w kilku równolegle realizowanych projektach. Równoczesna praca w kilku projektach może być efektywna tylko pod warunkiem bardzo dobrej organizacji wcze-śniej właściwie zaplanowanych prac i konsekwentnej dyscypliny w realizacji opraco-wanych planów. Są to podstawowe cele zarządzania projektami [25].

4. Modele tworzenia systemów informatycznych projektów Z pojęciem modelu związane są następujące kwestie:

• przedmiot, którego odzwierciedleniem jest dany model – przedmiotem może być np. urządzenie bądź jego część, zjawisko, problem; w przypadku systemów infor-matycznych modele odzwierciedlają różne aspekty funkcjonowania systemu: prze-twarzanie danych, przepływ danych, związki między danymi, budowę systemu etc.;

• język lub notacja, w której zapisano model; mówiąc inaczej: postać modelu; • właściwości modelu, takie jak:

- stopień, - dokładność, - czytelność i zrozumiałość.

Zwróćmy uwagę, że sposób zapisania modelu (język lub notacja) wpływa na jego wła-ściwości. Ideałem byłby model, który byłby jednocześnie w pełni formalny, dokładny, czytelny i zrozumiały. Zwykle jednak poprawa jednej własności pogarsza pewną liczbę

114

innych – na przykład: większy stopień sformalizowania zapisu powoduje zwykle zmniejszenie czytelności i zrozumiałości modelu.

Za obowiązującą w tej analizie przyjmijmy klasyfikację przedstawiona przez Szyjew-skiego [25]:

• model przyrostowy, • model kaskadowy, • model ewolucyjny, • model spiralny, • metodykę HIPO, • realizację kierowaną dokumentami, • prototypowanie.

4.1. Model kaskadowy Przykładem modelu kaskadowego może być metodyka punktów węzłowych, która ma wszystkie cechy kaskadowego postępowania i pozwala stworzyć uporządkowaną listę działań koniecznych przy realizacji typowego systemu informatycznego przetwarzania danych [24]. Metodyka punktów węzłowych koncentruje się na zakresie wykonywanych prac, czyli określone są działania odpowiadające na pytanie, co należy zrealizować. Meto-dyka nie daje odpowiedzi na pytanie, jak należy dane prace wykonać. Sposób realizacji pozostaje indywidualną decyzją kierownika projektu, który wybiera najlepsze w konkret-nym przypadku narzędzia realizacji. Opisująca metodykę lista działań jest powiązana zależnościami przyczynowo-skutkowymi i określa zalecany porządek realizacji. Sieć czynności do realizacji jest też pogrupowana w kilka poziomów ogólności, co pozwala wybrać poziom szczegółowości odpowiedni dla danego szczebla zarządzania projektem. Konkretne prace wykonywane w ciągu działań pogrupowane zostały w punkty węzłowe, czyli takie zespoły czynności, które kończą konkretnym, odpowiednio dokumentowanym produktem. Wartość praktyczną tej metodyki stanowi proponowana sieć powiązań punk-tów węzłowych. Analiza sieci powiązań pozwala odpowiednio zorganizować proces reali-zacji również mniej doświadczonym wykonawcom. Określenie listy poprzedników i na-stępników dla każdego punktu węzłowego pozwala zorganizować prace w związku z otwierającym się frontem prac oraz ułatwia przeprowadzenie działań kontrolnych dopa-sowanych do etapu realizacji. Dzięki analizie sieci 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łowych. Wiedza o zalecanej kolejności realizacji pozwala prawidłowo zorganizować prace i optymalnie wykorzystać zasoby [25].

Model projektu według metodyki firmy Digital. Doświadczenia praktyczne firmy Digi-tal zaowocowały opracowaniem metodyki DPM (Digital Program Methodology). Zilu-strowano wielowątkowość działań: od problemów finansowych, przez odpowiednie zarządzanie pracami projektowymi, po formalizacje przyjmowania zrealizowanych prac i uruchamianie kolejnych faz projektu. Każdy z przedstawionych tematów cząstkowych jest rozwijany kaskadowo w całym cyklu życia projektu. Rozwinięcia te są często wie-lowątkowe i wielopoziomowe, przez co tworzą skomplikowaną strukturę działań rozpi-

115

sanych na pojedyncze role. Rysunek 8 przedstawia główne elementy metodyki i ich wzajemne relacje [3].

Rys. 8. Cykl życia systemu według metodyki firmy Digital

Cykl życia projektu według tej metodyki jest podzielony na sześć faz realizacji: defini-cja problemu, analiza problemu, projekt, implementacja, instalacja, eksploatacja.

W modelu tym zwraca uwagę zebranie działań projektowych i implementacyjnych w samodzielne, odrębne fazy – przez to fazy te stają się najbardziej pracochłonne. Do-świadczenia praktyczne wskazują, że dzielenie tych faz na mniejsze etapy jest często wymogiem formalnym, a nie merytorycznym. Podział złożonego systemu oprogramowa-nia jest niezwykle trudny z uwagi na wielorakie powiązania i wzajemne oddziaływanie. Wydzielenie etapów kontrolnych wynika jednak z potrzeb kontroli fazy programowej, która jest najbardziej kosztowna, czasochłonna i w decydujący sposób wpływa na osta-teczny kształt i jakość projektu. Układ kaskadowy nie oznacza sekwencyjnego sposobu realizacji prac. Wymogi dokumentowania i formalnego odbioru prac pozwalają na weryfi-kacje postępu prac z punktu widzenia głównych parametrów projektu. Daje to możliwość wprowadzenia uzasadnionych modyfikacji parametrów projektu w czasie jego realizacji.

Zwraca uwagę wyodrębnienie zarządzania finansami projektu jako oddzielnego pozio-mu oraz wydzielenie prac związanych z zarządzaniem projektem. Jasne określenie kry-terium odbioru oznacza, że problematyka ta jest istotna w procesie realizacji już na wstępnym etapie prac projektowych.

Model firmy IBM. Firma IBM, na podstawie wieloletnich doświadczeń wypracowała własną metodykę tworzenia systemów informatycznych. Podstawą metodyki MITP (Manaaj the Implementation of the Total Project), podobnie jak innych metod stosowa-nych przy realizacji projektów, jest kaskadowy model wykonywania prac. Podział na

116

fazy jest nieco inny niż w omówionej wcześniej metodyce, wynika bowiem z praktyki

realizacji projektów w firmie IBM. Model ten zilustrowano na rysunku 9.

Wydzielenie tylko czterech faz realizacji projektu wynika z doświadczeń firmy IBM.

Inną nowością, w porównaniu z innymi metodykami, jest umiejscowienie decyzji

o możliwości zaniechania projektu tylko między fazą pierwszą a drugą. Decyzja „tak”

oznacza konieczność realizacji projektu aż do ukończenia [14].

Rys. 9. Model metodyki IBM

4.2. Model przyrostowy

Model przyrostowy jest stosowany w przypadku projektów obejmujących duży obszar

działalności organizacji. Realizacja projektu w całości mogłaby stanowić zbyt dużą

inwestycję, nie tylko z powodu kosztów, ale także z uwagi na zbyt dużą skalę zmian

wprowadzonych dzięki projektowi. W takich sytuacjach określa się strategię etapowego

dochodzenia do ostatecznej postaci i przyrostowo realizuje się kolejne etapy projektu.

Model przyrostowy przedstawia rysunek 10 [25].

Zastosowanie modelu przyrostowego pozwala sukcesywnie wdrażać nowoczesne roz-

wiązania według określonej strategii, zgodnej ze strategią działania organizacji. Wcze-

sne wdrożenie niektórych elementów projektu umożliwia wcześniejsze uzyskanie ko-

rzyści z wprowadzanej zmiany oraz ma istotny wpływ edukacyjny na użytkowników.

Pozwala również łatwiej akceptować sukcesywnie wprowadzane zmiany oraz elastycz-

nie modyfikować elementy projektu znajdujące się jeszcze w toku realizacji.

Rys. 10. Model przyrostowy tworzenia systemu informatycznego

Przy zastosowaniu zasoby finansowe oraz zespoły ludzkie uczestniczące w pracach projektowych [23].

4.3. Model ewolucyjnyModel ewolucyjny, który jest przedstawiony na rysunku 11, jest zbudowany z dowolnej liczby schematycznie takich samych bloków. Według wcześniej przyjętej strategii dziłań wdrażane są kolejno systemy informatyczne. W takim przypadku ważne jest, aby mieć końcową wizję informatyzacji organizacji i konsekwentnie realizować podzielone na kroki działania wdrożeniowe [25].

Rys. 11. Model ewolucyjny tworzenia systemu informatycznego

117

Rys. 10. Model przyrostowy tworzenia systemu informatycznego

Przy zastosowaniu metody przyrostowej można lepiej, bardziej sukcesywnie wykorzystać zasoby finansowe oraz zespoły ludzkie uczestniczące w pracach projektowych [23].

Model ewolucyjny Model ewolucyjny, który jest przedstawiony na rysunku 11, jest zbudowany z dowolnej

schematycznie takich samych bloków. Według wcześniej przyjętej strategii dziłań wdrażane są kolejno systemy informatyczne. W takim przypadku ważne jest, aby mieć końcową wizję informatyzacji organizacji i konsekwentnie realizować podzielone

ania wdrożeniowe [25].

Rys. 11. Model ewolucyjny tworzenia systemu informatycznego

metody przyrostowej można lepiej, bardziej sukcesywnie wykorzystać zasoby finansowe oraz zespoły ludzkie uczestniczące w pracach projektowych [23].

Model ewolucyjny, który jest przedstawiony na rysunku 11, jest zbudowany z dowolnej schematycznie takich samych bloków. Według wcześniej przyjętej strategii dzia-

łań wdrażane są kolejno systemy informatyczne. W takim przypadku ważne jest, aby mieć końcową wizję informatyzacji organizacji i konsekwentnie realizować podzielone

118

4.4. Model spiralny Podobnie jak w modelu ewolucyjnym, model spiralny zakłada cykliczne powtarzanie pewnej sekwencji działań. Idea krokowego dochodzenia do rozwiązania docelowego jest realizowana poprzez cykliczne wykonywanie tych samych faz projektu. Najczęściej dotyczy to dużych i złożonych przedsięwzięć, dlatego też model ten ma liczne zastoso-wania w przemyśle lotniczym. Przy krokowym dochodzeniu do rozwiązania docelowe-go można oceniać efekty prac projektowych w sposób etapowy oraz wprowadzać ewen-tualne modyfikacje zgodnie ze zmianami celów biznesowych działania organizacji.

W pierwszej fazie planuje się działania realizacyjne, czyli wyznacza się zakres wpro-wadzanej zmiany oraz zakres pierwszego etapu realizacji. Następnie ocenia się ryzyko podejmowanego przedsięwzięcia i na podstawie tej oceny modyfikuje się plan. Zmody-fikowany plan poddawany jest realizacji. Najczęściej faza konstrukcji jest realizowana zgodnie z modelem kaskadowym. Zakończenie etapu realizacji stanowi konkretny pro-dukt, który może być poddany ocenie według kryterium użyteczności praktycznej. Etap testowania daje materiał do modyfikacji i określenia zakresu następnego przybliżenia w krokowej realizacji celów projektu. Ponownie realizowana jest faza planowania i spiralnie dochodzimy do wyznaczonych celów projektu.

Taki model wytwarzania oprogramowania stosuje firma Microsoft w procesie tworzenia systemów operacyjnych Windows i innego oprogramowania. Rysunek 12 przedstawia model takiego podejścia w jednym cyklu wytwarzania. W wyniku realizacji cyklu po-wstaje produkt rynkowy, który ma określony numer wersji. Kolejny cykl owocuje na-stępną wersją, która ma nowe funkcje oraz usunięte usterki wersji poprzedniej. Mimo dużej uciążliwości dla użytkownika tak wytwarzanego oprogramowania, metoda ta odnosi duży sukces rynkowy, o czym świadczy pozycja firmy Microsoft [25].

Rys. 12. Model spiralny firmy Microsoft

119

W pierwszej fazie należy stworzyć wizję wytwarzanego produktu. Wizja ta powstaje w wyniku uzgodnień pomiędzy zespołem wykonawczym a reprezentantem klienta, który określa przede wszystkim cele biznesowe i wymagania projektu. Wynikiem tej fazy jest wizja projektu uzgodniona i zaakceptowana przez wszystkich uczestników procesu. Ważnym elementem tego podejścia jest dbałość o to, aby wszyscy uczestnicy projektu traktowali wypracowaną wizję jako własną. W przypadku cyklu półrocznego faza ta trwa zwykle 2 do 3 tygodni.

Celem drugiej fazy jest zaplanowanie działań wykonawczych. Zespół wraz z przedstawi-cielami klienta określa, co będzie wytwarzane, oraz sposób i czas wykonania. W fazie tej powstaje uzgodniony plan realizacji. Faza planowania powinna trwać około 1,5 miesiąca.

Faza wytwarzania, której celem jest wyprodukowanie oprogramowania, nie powinna trwać dłużej niż 2 miesiące. Na fazę tę składają się prace zespołu piszącego kod pro-gramów, przeprowadzanie testów wewnętrznych oraz opracowanie niezbędnej doku-mentacji. Na zakończenie tej fazy otrzymujemy kompletne oprogramowanie, które odpowiada zakresowi określonemu w pierwszej fazie.

Ostatnią fazą cyklu spiralnego jest stabilizacja wytworzonego wcześniej produktu. W tej fazie wykonuje się testowanie zewnętrzne programowania. Wykryte błędy ocenia się i usuwa lub rezygnuje się z pewnych funkcji oprogramowania w wersji przygotowanej do wydania. W tej fazie, która również trwa około 2 miesięcy, nie wprowadza się żad-nych nowych elementów. Wynikiem takiego cyklu jest rynkowa wersja oprogramowa-nia, przekazywana do użytkowania.

4.5. Prototypowanie Ideą modelu prototypowania jest dążenie do uniknięcia błędów wynikających z nieprawi-dłowego określenia wymagań w początkowym etapie definicji zakresu projektu. W wyniku błędnego zdefiniowania wymagań projektowych i ich realizacji według modelu kaskadowe-go często powstaje produkt wykonany zgodnie ze sztuką (główne parametry projektu – zakres, budżet i czas – są zrealizowane zgodnie z założeniami), ale nie spełniający aktual-nych oczekiwań klienta. Dotyczy to głównie nowatorskich rozwiązań, gdzie trudno jest w początkowej fazie analizy dokładnie określić wymagania definiowanego projektu.

Celem prototypowania jest minimalizowanie ryzyka związanego z błędnym określe-niem wymagań. Często model ten nazywany jest metodyką szybkiego wytwarzania aplikacji RAD (Rapid Application Development) [22].

Ukierunkowanie prac na zaspokojenie potrzeb użytkownika oraz dbałość o wysoką jakość produktu to zasadnicze cele metodyki RAD. Metodyka ta charakteryzuje się:

• gwarantowaną wysoką jakością rozwiązania, • ewolucyjnością procesu wytwarzania systemu, • stosowaniem inżynierskich technik wytwarzania w całym cyklu realizacji, • zlecaniem wytwarzania profesjonalnym zespołom, wydzielonym do określonych

zadań, • wykorzystaniem profesjonalnych metod zarządzania zespołem, • stosowaniem wydajnych narzędzi wspomagających wytwarzanie oprogramowania, • gwarantowaną produktywnością wytwarzanego oprogramowania.

120

Stosowanie metodyki RAD pozwala na wytwarzanie dużych i skomplikowanych syste-mów informatycznych dość szybko i zgodnie z wymaganiami użytkownika. Osiągnięcie założonych celów często jest związane z koniecznością integracji nowego produktu z wcześniej wytworzonymi i eksploatowanymi systemami informatycznymi. Integracja taka jest trudna z wielu istotnych powodów. Dotychczasowe rozwiązanie oparte na przestarzałych technologiach i stary sprzęt komputerowy powinny współdziałać z naj-nowszymi osiągnięciami informatyki [25].

Często produkty wytworzone przy wykorzystaniu metodyki RAD mają z założenia krótki termin użytkowania, czyli mają charakter przejściowy. Są to rozwiązania prowi-zoryczne, pozwalające „bezboleśnie” wprowadzić użytkownika w nowoczesną techno-logię informatyczną. Zachowanie dotychczasowego dorobku, przyzwyczajeń, metod pracy czy wreszcie danych na nośnikach komputerowych to warunki często formułowa-ne w przypadku nowo powstających systemów informatycznych. Mimo prowizorycz-nego charakteru wytwarzanego systemu nie można pozwolić na obniżenie parametrów jakościowych. Zorientowanie na wysoką jakość produktu to jedno z podstawowych założeń tej metodyki.

Przystosowanie procesu wykonania do zmieniającej się aplikacji to wyzwanie zmusza-jące zespół realizatorów do stałego doskonalenia warsztatu, stosowanych metod, narzę-dzi i sposobu organizacji pracy. Szybkie dostarczanie użytkownikowi rozwiązania in-formatycznego mającego odpowiadać na jego zmieniające się oczekiwania zakłada ewolucyjne dokonywanie zmian w technologii pracy, ale zmusza też do stałego kontak-tu z użytkownikiem i natychmiastowego reagowania uwagi i sugestie. Taki sposób realizacji znacznie zmniejsza rozminięcia się z wymaganiami i oczekiwaniami użyt-kownika. Staje się on współautorem rozwiązania i identyfikuje się z nim, co istotnie upraszcza proces wdrożenia.

5. Podsumowanie Zarządzanie projektem informatycznym pomaga sformalizować prace projektowe – przez co stają się one bardziej czytelne dla wykonawców oraz pozwala przeprowadzić projekt według wcześniej zaplanowanych etapów, które zazwyczaj kończą się osiągnię-ciem punktu węzłowego (kamienia milowego projektu). Należy pamiętać również, że podstawowym celem ustanowienia projektu jest szybkie i bezkonfliktowe wprowadze-nie zmiany. Należy dążyć do osiągnięcia celów zmiany bez zakłócenia normalnego funkcjonowania organizacji.

Literatura 1. Bobkiewicz B., Komputer Świat – expert. Wejdź w sieć, Konfiguracja sieci LAN,

Dostęp do Internetu, Nr 3/2003. Warszawa 06.2003.

2. Cegieła R., Zalewski A., Racjonalne zarządzanie przedsięwzięciami informatycz-nymi i systemami komputerowymi, Poznań 2000.

3. Digital Program Metodology – Life Cycle Volume. Digital Eqiupment Corporation, Raport no A-MN-ELCP701-00-0, 1989.

121

4. Duncan Wiliam R., A Guide to the Project Management Body Of Knowledge. PMI Standards Committee, PA USA1982.

5. Gierszewska G., Romanowska M., Analiza strategiczna przedsiębiorstwa, Warsza-wa 1994.

6. Griffin R.W., Podstawy zarządzania organizacjami, Warszawa 1996. 7. http://sklep.komputronik.pl. 8. http://www.andersenbusinessconsulting.com.pl. 9. http://www.inwencja.com.pl/kacik2.html. 10. http://www.macrosoft.pl/oferta/wdrozenie/d_apm.html. 11. http://www.standishgroup.com. 12. http://www.telekomunikacja.pl/biznes/msp/internet/dsl/ 13. Hunt C., TCP/IP – administracja sieci, Warszawa 1996 r. Hunt C., 14. Łoopaciński T., Narzędzia do wspomagania zarządzania przedsięwzięciami firmy

IBM, Gdańsk 1999. 15. Maksimczuk P., PC kurier. Ujarzmić projekty. Nr 9/2003, Warszawa 16.05.2003. 16. Meredith J.R., Mantel S.J., Project Management a Managerial Apptoache. John

Wiley&Sons.Inc, New York 1995. 17. Morris P., Peter W.G., Managing Project Interfaces; Key Point for Project Success

In Cleand and King. Prentice – Hall, Englewood Cliffs, New York 1981. 18. Pells L.D., Projekt Management Plans: An Approach to Comprehensive Planning

for Complex Project. The AMA handbook of Project Management, AMACOM, New York 1993.

19. Prentis E.L., Master Project Planning Scope Time and Cost. Project Management Journal, 03.1989.

20. Rakos J.I., Software Project Management. Prentice Hall, Englewood Cliffs, New York 1990.

21. Sacha K., Projektowanie oprogramowania systemów wbudowanych, Warszawa 1996.

22. Szybkie wytwarzanie aplikacji (Rapid Application Development). Organizacja, metody, narzędzia, Świnoujście 1996.

23. Szyjewski Z., Analiza strategiczna w tworzeniu systemów informatycznych. W: „Studia informatica” nr 9, ZN Uniwersytetu Szczecińskiego nr 192, 1998 r.

24. Szyjewski Z., Komputerowe wspomaganie tworzenia systemów informatycznych. Szczecin 1994.

25. Szyjewski Z., Zarządzanie projektami informatycznymi. Metodyka tworzenia sys-temów informatycznych, Warszawa 2001.

26. Vademecum teleinformatyka. Zbiór wydań specjalnych miesięcznika „Net World”. IDG Poland S.A., Warszawa 2001.

27. Use H., A Framework of Software Measurement. Walter de Gruyter, Berlin 1998.