Wybrane elementy zarządzania projektem informatycznym

Transkrypt

1 Marian KOPCZEWSKI 1), Ewa CZAPIK-KOWALEWSKA, Joanna KRAWCZYK 2) 1) Wyższa Szkoła Bezpieczeństwa, 2) Instytut Polityki Społecznej i Stosunków Międzynarodowych, Politechnika Koszalińska 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 takich kryteriów oceny jak czas, koszt i jakość projektu. 1. Wstęp Definicję procesu zarządzania projektem informatycznym, która w prosty i trafny sposób opisuje to zagadnienie, przedstawił Wiliam Duncan. Pisze on, że zarządzanie projektem 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 odpowiedniego 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 zmiany. 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 informatycznego, ale na użytkowaniu produktu w celu polepszenia efektów podstawowej działalności firmy [25]. 107

2 Rys. 1. Projekt a zmiana W definicji projektu podkreślony został czasowy charakter i unikalność prac realizowanych 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 wprowadzenie 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ć procesem. 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 modyfikację 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 zaangaż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. Wydaje się to dość naturalne z uwagi na przedstawioną charakterystykę projektu. Na początku należy, bowiem wykonać wiele prac przygotowawczych i stworzyć fundamenty dla pracy zespołów wykonawczych, natomiast na zakończenie wykonywane są prace sumujące i umożliwiające zamknięcie projektu. 108

3 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 definiujących projekt, przy zachowanych dwóch pozostałych, wpływa na korzyści przewidywane 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 109

4 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. Sytuacja 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 projektu). Rezultatem jest wydłużenie czasu osiągania korzyści, co oznacza, że zwrot z inwestycji 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 stosowane 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 generowanymi w trakcie realizacji i zgłaszanymi przez przyszłego użytkownika. Kolejnym istotnym 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- 110

5 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 przypadku 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 dziedziny 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 aktywnym 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 zintegrować 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. 111

6 Rysunek 7 przedstawia schemat organizacyjny zespołu realizującego projekt informatyczny. 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 istotnymi dla realizacji projektu. Do sponsora więc, jako do ostatniej instancji, może zwracać 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 wykonawcy, ale aktywnego obserwatora postępu prac. Wiedza fachowa sponsora jest wzbogacona 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. 112

7 Wskazywaliśmy już na istotną rolę problemów jakości. Z uwagi na zapewnienie wymaganych parametrów jakościowych realizowanego produktu wskazane jest powołanie specjalnego zespołu. Zadaniem zespołu jest wspomaganie kierownika projektu i komitetu 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 skontrolować działania kierownika projektu, natomiast kierownik projektu otrzymuje informacje 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 czasowy. 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 uwarunkowanie 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ównocześ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 opracowanych 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 informatycznych modele odzwierciedlają różne aspekty funkcjonowania systemu: przetwarzanie 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ę 113

8 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 Szyjewskiego [25]: model przyrostowy, model kaskadowy, model ewolucyjny, model spiralny, metodykę HIPO, realizację kierowaną dokumentami, prototypowanie 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ć. 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. 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ń punktów węzłowych. Analiza sieci powiązań pozwala odpowiednio zorganizować proces realizacji również mniej doświadczonym wykonawcom. Określenie listy poprzedników i nastę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 dopasowanych 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 Digital zaowocowały opracowaniem metodyki DPM (Digital Program Methodology). Zilustrowano 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 wielowątkowe i wielopoziomowe, przez co tworzą skomplikowaną strukturę działań rozpi- 114

9 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: definicja 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 oprogramowania 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 ostateczny kształt i jakość projektu. Układ kaskadowy nie oznacza sekwencyjnego sposobu realizacji prac. Wymogi dokumentowania i formalnego odbioru prac pozwalają na weryfikacje 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 poziomu oraz wydzielenie prac związanych z zarządzaniem projektem. Jasne określenie kryterium 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 stosowanych przy realizacji projektów, jest kaskadowy model wykonywania prac. Podział na 115

10 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 rozwiązania według określonej strategii, zgodnej ze strategią działania organizacji. Wczesne wdrożenie niektórych elementów projektu umożliwia wcześniejsze uzyskanie korzyści z wprowadzanej zmiany oraz ma istotny wpływ edukacyjny na użytkowników. Pozwala również łatwiej akceptować sukcesywnie wprowadzane zmiany oraz elastycznie modyfikować elementy projektu znajdujące się jeszcze w toku realizacji. 116

11 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 liczby schematycznie takich samych bloków. Według wcześniej przyjętej strategii dziadzi ł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 ania wdrożeniowe [25]. Rys. 11. Model ewolucyjny tworzenia systemu informatycznego 117

12 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 zastosowania w przemyśle lotniczym. Przy krokowym dochodzeniu do rozwiązania docelowego można oceniać efekty prac projektowych w sposób etapowy oraz wprowadzać ewentualne modyfikacje zgodnie ze zmianami celów biznesowych działania organizacji. W pierwszej fazie planuje się działania realizacyjne, czyli wyznacza się zakres wprowadzanej zmiany oraz zakres pierwszego etapu realizacji. Następnie ocenia się ryzyko podejmowanego przedsięwzięcia i na podstawie tej oceny modyfikuje się plan. Zmodyfikowany plan poddawany jest realizacji. Najczęściej faza konstrukcji jest realizowana zgodnie z modelem kaskadowym. Zakończenie etapu realizacji stanowi konkretny produkt, 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 powstaje produkt rynkowy, który ma określony numer wersji. Kolejny cykl owocuje nastę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 118

13 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 przedstawicielami 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 programów, przeprowadzanie testów wewnętrznych oraz opracowanie niezbędnej dokumentacji. 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ę żadnych nowych elementów. Wynikiem takiego cyklu jest rynkowa wersja oprogramowania, przekazywana do użytkowania Prototypowanie Ideą modelu prototypowania jest dążenie do uniknięcia błędów wynikających z nieprawidłowego określenia wymagań w początkowym etapie definicji zakresu projektu. W wyniku błędnego zdefiniowania wymagań projektowych i ich realizacji według modelu kaskadowego 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 aktualnych 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śleniem 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. 119

14 Stosowanie metodyki RAD pozwala na wytwarzanie dużych i skomplikowanych systemó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 najnowszymi 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 prowizoryczne, pozwalające bezboleśnie wprowadzić użytkownika w nowoczesną technologię informatyczną. Zachowanie dotychczasowego dorobku, przyzwyczajeń, metod pracy czy wreszcie danych na nośnikach komputerowych to warunki często formułowane w przypadku nowo powstających systemów informatycznych. Mimo prowizorycznego 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 zmuszające zespół realizatorów do stałego doskonalenia warsztatu, stosowanych metod, narzędzi i sposobu organizacji pracy. Szybkie dostarczanie użytkownikowi rozwiązania informatycznego mającego odpowiadać na jego zmieniające się oczekiwania zakłada ewolucyjne dokonywanie zmian w technologii pracy, ale zmusza też do stałego kontaktu z użytkownikiem i natychmiastowego reagowania uwagi i sugestie. Taki sposób realizacji znacznie zmniejsza rozminięcia się z wymaganiami i oczekiwaniami użytkownika. 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 wprowadzenie 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 Cegieła R., Zalewski A., Racjonalne zarządzanie przedsięwzięciami informatycznymi i systemami komputerowymi, Poznań Digital Program Metodology Life Cycle Volume. Digital Eqiupment Corporation, Raport no A-MN-ELCP ,

15 4. Duncan Wiliam R., A Guide to the Project Management Body Of Knowledge. PMI Standards Committee, PA USA Gierszewska G., Romanowska M., Analiza strategiczna przedsiębiorstwa, Warszawa Griffin R.W., Podstawy zarządzania organizacjami, Warszawa 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 Maksimczuk P., PC kurier. Ujarzmić projekty. Nr 9/2003, Warszawa Meredith J.R., Mantel S.J., Project Management a Managerial Apptoache. John Wiley&Sons.Inc, New York Morris P., Peter W.G., Managing Project Interfaces; Key Point for Project Success In Cleand and King. Prentice Hall, Englewood Cliffs, New York Pells L.D., Projekt Management Plans: An Approach to Comprehensive Planning for Complex Project. The AMA handbook of Project Management, AMACOM, New York Prentis E.L., Master Project Planning Scope Time and Cost. Project Management Journal, Rakos J.I., Software Project Management. Prentice Hall, Englewood Cliffs, New York Sacha K., Projektowanie oprogramowania systemów wbudowanych, Warszawa Szybkie wytwarzanie aplikacji (Rapid Application Development). Organizacja, metody, narzędzia, Świnoujście 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 Szyjewski Z., Zarządzanie projektami informatycznymi. Metodyka tworzenia systemów informatycznych, Warszawa Vademecum teleinformatyka. Zbiór wydań specjalnych miesięcznika Net World. IDG Poland S.A., Warszawa Use H., A Framework of Software Measurement. Walter de Gruyter, Berlin