Zarz 261 Dzanie Projektem Informatycznym

Kazimierz Frczkowski
Zarzdzanie
projektem informatycznym
Projekty w rodowisku wirtualnym
Czynniki sukcesu i niepowodze projektw
Oficyna Wydawnicza Politechniki Wrocawskiej

Wrocaw 2003
Wydzia Informatyki i Zarzdzania

Wydziaowy Zakad Informatyki
Opiniodawca
Zdzisaw SZYJEWSKI
Opracowanie redakcyjne i korekta

Alina KACZAK
Projekt okadki
Justyna GODLEWSKA
Copyright by Oficyna Wydawnicza Politechniki Wrocawskiej, Wrocaw 2003
OFICYNA WYDAWNICZA POLITECHNIKI WROCAWSKIEJ

Wybrzee Wyspiaskiego 27, 50-370 Wrocaw
ISBN 83-7085-731-0
Drukarnia Oficyny Wydawniczej Politechniki Wrocawskiej. Zam. nr 633/2003.
Spis treci
Od Autora ............................................................................................................................................
Wprowadzenie ...................................................................................................................................
1. Geneza zarzdzania projektami .....................................................................................................
1.1. Przegld historyczny wybranych zagadnie zarzdzania ....................................................
1.2. Podstawowe pojcia i definicje stosowane w zarzdzaniu projektami .................................
1.3. Czynniki charakterystyczne projektu ...................................................................................
1.4. Proces ...................................................................................................................................
2. Planowanie projektu informatycznego ..........................................................................................
2.1. Cele planowania projektu .....................................................................................................
2.2. Definiowanie celw projektu ...............................................................................................
2.3. Zasoby projektu ...................................................................................................................
2.4. Definiowanie ogranicze w projekcie ..................................................................................
2.5. Strategia realizacji projektu .................................................................................................
2.6. Ocena ryzyka .......................................................................................................................
2.7. Struktura projektu dekompozycja projektu na zadania WBS .........................................
2.8. Szacowania w projekcie .......................................................................................................
2.9. Metoda punktw funkcyjnych .............................................................................................
2.10. Harmonogram ......................................................................................................................
2.11. Sieciowe diagramy zalenoci .............................................................................................
2.12. Inicjowanie projektu ............................................................................................................
3. ledzenie i zarzdzanie zmianami projektu ...................................................................................
3.1. ledzenie projektu monitorowanie ....................................................................................
3.2. Zarzdzanie jakoci w projekcie ........................................................................................
3.3. rda i rodzaje zmian .........................................................................................................
3.4. Proces zarzdzania zmianami ..............................................................................................
3.5. ledzenie i nadzorowanie czasu oraz kosztw projektu .......................................................
3.6. Nadzorowanie projektu metod wartoci uzyskanej (Earned Value) ...................................
3.7. Podsumowanie .....................................................................................................................
4. Modele pracy i komunikacji ..........................................................................................................
4.1. Telepraca ..............................................................................................................................
4.2. Modele organizacji pracy zespow projektowych ..............................................................
4.3. Elektroniczny czonek zespou zesp ..............................................................................
4.4. Wirtualna sie partnerw przedsiwzicia ...........................................................................
4.5. Zespoy Projektowe .............................................................................................................
4.6. Praca grupowa ......................................................................................................................
5. Zarzdzanie ryzykiem ...................................................................................................................
5.1. Czynniki majce wpyw na ryzyko ......................................................................................
5
6
8
8
11
13
14
17
18
19
20
21
24
25
26
31
34
45
48
50
52
52
53
59
60
65
66
74
77
78
80
85
89
91
92
94
99
Spis treci
5.2. Identyfikacja ryzyka metody analizy ryzyka kwestionariusze, listy kontrolne ..............
5.3. Akcje naprawcze ..................................................................................................................
5.4. Metoda punktowa szacowania ryzyka .................................................................................
5.5. Metoda PERT szacowania ryzyka .......................................................................................
6. Projekty wdroeniowe outsourcing ............................................................................................
6.1. Rodzaje projektw informatycznych oraz organizacja pracy i zespow ............................
6.2. Wdroenie przez outsourcing ..............................................................................................
7. Czynniki sukcesw i niepowodze projektw ..............................................................................
7.1. Niektre badania statystyczne niepowodze projektu .........................................................
7.2. Wpyw wielkoci projektu na jego sukces ...........................................................................
8. Rola i zadania kierownika projektu ...............................................................................................
8.1. Usytuowanie kierownika projektu a jego skuteczno .........................................................
8.2. Dobr czonkw zespou ......................................................................................................
8.3. Rekrutacja czonkw zespou ...............................................................................................
8.4. Budowa kompetencji w projekcie ........................................................................................
8.5. Konflikt ................................................................................................................................
8.6. Motywowanie ......................................................................................................................
8.7. Delegowanie uprawnie .......................................................................................................
9. Dodatek .........................................................................................................................................
9.1. Metoda zarzdzania projektami PRINCE-2 .........................................................................
9.2. Oprogramowanie wspomagajce zarzdzanie zmianami .....................................................
9.3. Najpopularniejsze narzdzia open source ............................................................................
9.4. Oprogramowanie komercyjne do zarzdzania zmianami .....................................................
9.5. Narzdzie open source do zarzdzania projektami ..............................................................
Sownik poj i terminw ....................................................................................................................
Literatura .............................................................................................................................................
102
104
105
113
118
118
121
125
125
128
130
131
132
133
136
136
136
139
141
141
144
145
150
153
155
161
Od autora
Niniejsza ksika stanowi prb opracowania zagadnie zwizanych z zarzdzaniem przedsiwziciami informatycznymi. Obejmuje wybrane wspczesne pogldy
na tematy, ktre s kluczowe w obszarze planowania, zarzdzania zmianami, organizacji zespow projektowych, szacowania kosztw, monitorowania ryzyka i decyduj
o sukcesie lub niepowodzeniu projektu. Celem opracowania jest rwnie prba podzielenia si z czytelnikami wasnym dowiadczeniem zawodowym, nabytym podczas
prac nad projektami informatycznymi, uczestniczenia w szkoleniach z tej tematyki oraz
prowadzenia wykadw i seminariw na Wydziale Informatyki i Zarzdzania Politechniki Wrocawskiej, dla studentw kierunku Inynieria Oprogramowania w latach 1998
2003. Prace nad ksik zainicjowao dostarczenie mi notatek w postaci elektronicznej z
cyklu moich wykadw przez studenta pana Piotra Hojnara. Dzikuj rwnie innym
studentom, ktrzy przygotowujc i prezentujc w trakcie seminariw niektre zagadnienia z tej dziedziny, narzekali na brak polskiej literatury z tego przedmiotu, przez co
stymulowali prac nad ksik. Studenci, ktrzy uczestniczyli w dojrzaych dyskusjach na seminariach i przygotowali interesujce wystpienia, stali si poniekd
wspautorami niniejszego opracowania.
Ksika jest przeznaczona dla studentw informatyki i zarzdzania oraz kierownikw projektw. Zawarto opracowania to prba osignicia kompromisu midzy
rozlegym zakresem tematycznym tego zagadnienia a programem studiw, ktry opracowalimy wsplnie z pani dr in. Iwon Dubielewicz, ktrej dzikuj za cenne propozycje dotyczce omawianych zagadnie i sposobu ich przedstawienia. Zachty
i osobistego wsparcia w pracy udzieli mi prof. Zbigniew Huzar, ktremu dedykuj
t prac.
Bd wdziczny wszystkim, ktrzy zechc przesa uwagi i sugestie dotyczce
podrcznika.
Adres: e-mail: kazimierzfraczkowski@pwr.wroc.pl
Kazimierz Frczkowski
Wprowadzenie
Niekiedy, na pewnym etapie kariery zawodowej, nieoczekiwanie stajemy przed
szans zostania kierownikiem projektu (ang. Project Manager PM). Rzadko z wyprzedzeniem planujemy ubieganie si o funkcj kierownika projektu PM. Najczciej nie jestemy do tego teoretycznie przygotowani, przez co zarzdzanie projektem
nabiera charakteru twrczej intuicyjnej improwizacji. Kady kolejny kierownik
projektu dy do jego realizacji, musi samodzielnie, od podstaw, wykreowa wszelkie
rozwizania, improwizowa, weryfikowa swoje dziaania metod prb i bdw.
Tymczasem sztuka zarzdzania projektami, ktra znacznie rozwina si w cigu
ostatnich pitnastu lat, stanowi dzi cis, profesjonaln dyscyplin. Skada si na ni
wiedza teoretyczna, konkretny zestaw umiejtnoci i kompetencji, a take proces certyfikacji przeprowadzany przez np. Project Management Institute (PMI) z siedzib w
Waszyngtonie orodek badawczy zgbiajcy arkana tej dziedziny. Profesjonalizm w
zarzdzaniu projektami ma nie tylko pozytywne odzwierciedlenie w stylu dziaania
organizacji, ale take wpywa na podniesienie motywacji i satysfakcji
z pracy osb odpowiedzialnych za projekty. Warto pamita, e wiedza w tej dziedzinie rozwija si bardzo dynamicznie i tylko stae podnoszenie kompetencji oparte na
dowiadczeniu przodujcych w zarzdzaniu projektami instytutw naukowych i stowarzysze branowych gwarantuje przewag konkurencyjn ich adeptom.
Wiedza na temat zarzdzania projektami nie powinna by zarezerwowana jedynie
dla najwyszego kierownictwa, odpowiedzialnego za caoksztat organizacji. Tej grupie jest ona bezsprzecznie potrzebna do realizacji celw strategicznych, podejmowania trudnych decyzji i alokowania zasobw w sposb sprzyjajcy realizacji projektw.
Jednak bez odpowiedniego przygotowania zespow projektowych nie ma gwarancji,
e zadania przydzielane im w poszczeglnych etapach projektw zostan prawidowo
zrealizowane. Wszyscy czonkowie organizacji potrzebuj wiedzy i umiejtnoci
w zakresie zarzdzania projektami jedni bardziej pogbionej i rozbudowanej, inni
mniej szczegowej. Mimo e ci z nas, ktrzy cho raz zarzdzali projektem lubi
nazywa siebie Project Managerami, coraz czciej licz si formalne, powiadczone
certyfikatem uprawnienia do tego tytuu. Dyplomy wydawane przez MT&DC, przy
wsppracy z Educational Services Institute International (ESI), potwierdzaj uzyskanie przez uczestnika kursu gruntownego wyksztacenia i nabycia kompetencji
Wprowadzenie
w tym zakresie. Otrzymanie certyfikatu ESI czy si z fundamentalnym poznaniem

niezbdnej tematyki zwizanej z zarzdzaniem projektem i otwiera drog do uzyskania dyplomu Project Management Professional (PMP). Nie bez znaczenia i nie przypadkiem przedmiot ten znalaz si w programie studiw na kierunku informatyka.
Mam skromn nadziej, e praca ta pomoe w pewnym stopniu Czytelnikowi w szerszym spojrzeniu na realizacj przedsiwzi informatycznych, uwzgldniajc w zarzdzaniu projektami omawiane zagadnienia.
1. Geneza zarzdzania projektami

1.1. Przegld historyczny
wybranych zagadnie zarzdzania
Potrzeba zarzdzania jest pochodn zoonoci przedsiwzi, ktrych realizacja
rozciga si w czasie, angauje zasoby i ma okrelony cel. Mona postawi tez, e
zarzdzanie moe obejmowa dziaania pojedynczego czowieka do duych zoonych
przedsibiorstw, korporacji, organizmw pastwowych i midzynarodowych. Z tymi
ostatnimi mamy do czynienia dopiero od setek lat, ale zarzdzanie uprawiano ju od
tysicleci.
Powstajce w staroytnoci cywilizacje swj rozwj i osignicia zawdziczaj
jednostkom, ktre posugiway si adekwatnymi do istniejcego otoczenia efektywnymi metodami zarzdzania. W Egipcie nie powstayby piramidy, gdyby przy ich
budowie nie zastosowano takich elementw zarzdzania, jak planowanie, organizowanie i kontrolowanie zaplanowanych prac. Aleksander Wielki, zwany Macedoskim (356323 p.n.e.), krl Macedonii i wychowanek Arystotelesa, posugiwa si
sztabow organizacj w koordynacji dziaa w toku swoich kampanii wojennych, co
zapewnio mu w historii miano znakomitego stratega i taktyka oraz administratora.
Cesarstwo rzymskie rozwino dobrze wyksztacon struktur organizacyjn, ktrej
podstaw by system komunikacji (wszystkie drogi prowadz do Rzymu)
i kontroli. Na temat praktyk i koncepcji zarzdzania wypowiada si Sokrates w 400
roku p.n.e.; Platon w 350 roku p.n.e. opisa specjalizacj pracy; Farabi, Alfarabi,
waciwie Muhammad ibn Takhan abu Nasr al.-Farabi, poda kilka cech przywdztwa w 900 roku n.e. Ksztatowanie si dokona w dziedzinie zarzdzania przedstawiono na rysunku 1.1.
Wspczeni prekursorzy zarzdzania rozwinli sw dziaalno dopiero
w XIX wieku. Robert Owen (17711858), angielski ekonomista, filozof, polityk,
przemysowiec i reformator, by jednym z pierwszych menederw, ktry dostrzeg znaczenie zasobw ludzkich organizacji. Do jego czasw na robotnikw
fabrycznych patrzono w sposb bardzo podobny jak na maszyny czy sprzt. Owen,
ktry sam by wacicielem fabryk, by przekonany, e robotnicy maj prawo do
poszanowania i godnoci, dlatego w kierowanej przez siebie przdzalni w New

Lamark wdroy unikatowy wwczas program socjalny (budowa mieszka dla
robotnikw, podwyka pac, skrcenie czasu pracy). Wychodzi z zaoenia, e
wiksza troska o robotnika zaowocuje zwikszon wydajnoci pracy. Jego koncepcjami by zachwycony car Mikoaj I, od ktrego otrzyma propozycj osiedlenia si w Rosji wraz z 2 mln angielskich robotnikw. Mimo e nie znalaz naladowcw wrd sobie wspczesnych, jego idee zostay pniej rozwinite
w behawioralnym podejciu do zarzdzania.
Charles Babbage (17921871), angielski matematyk, pionier informatyki, profesor
uniwersytetu Cambridge (18281839), koncentrowa uwag na efektywnoci produkcji. Babbage wiza wielkie nadzieje z podziaem pracy i by ordownikiem
zastosowania matematyki do takich problemw, jak efektywne wykorzystanie maszyn, pomieszcze i materiaw. W tym sensie jego praca wyprzedzia zarwno
klasyczne, jak i ilociowe spojrzenie na zarzdzanie. Babbage dostrzega jednak
rwnie czowieka. Rozumia korzyci pynce z wspdziaania pracodawcy i
robotnikw, i rozumia korzyci pynce ze wspudziau w zyskach tych ostatnich.
Wspczeni prekursorzy naukowego zarzdzania to midzy innymi Federic W.
Taylor (18651915), Frank Gilbreth (18681924), Henry Gantt (186119190 czy
Harrington Emerson (18531931). Pionierem w dziedzinie wydajnoci pracy by
niewtpliwie Taylor, ktry wprowadzi liczne innowacje w sposobie projektowania
stanowiska pracy, szkolenia pracownikw, ktrzy mieli prac wykonywa i uzyskiwa wysz jako produkowanych wyrobw.
Prekursorzy zarzdzania
Wspczenie zarzdzanie kojarzy nam si przede wszystkim z duymi przedsibiorstwami, korporacjami, organizacjami, ktre s kierowane przez zarzdy, prezesw, rady nadzorcze. Zanim do tego doszlimy, na przestrzeni wielu stuleci yy narody i ich wybitni przedstawiciele, ktrzy stworzyli podwaliny naszej cywilizacji.
Sumerowie
znani s z metod zarzdzania opartych na spisanych przepisach,
Egipcjanie
stworzyli reguy i praktyki w budowie piramid,
Babiloczycy zaczli stosowa szeroki zestaw aktw prawnych i rodkw politycznych w zarzdzaniu,
Grecy
specjalizowali si w rnych systemach zarzdzania miastami
i pastwami,
Rzymianie
uywali struktury organizacyjnej w celu komunikacji i kontroli,
Chiczycy
wprowadzili rozleg struktur organizacyjn dla agencji rzdowych oraz w dziedzinie sztuki,
Wenecjanie
zastosowali projektowanie organizacji i planowanie do osigni-
Zarzdzanie projektem informatycznym
10
cia celu, jakim byo panowanie na morzu.

Grecy
Babiloczycy
Egipcjanie
Sumerowie
Wenecjanie
Rzymianie
Chinczycy
3000 p.n.e 2500 p.n.e 2000 p.n.e 1500 p.n.e 1000 p.n.e 500 p.n.e
500 n.e
1000 p.n.e 1500 n.e
2000 n.e
Rys. 1.1. Prekursorzy zarzdzania i przeomowe ich dokonania,

wedug Griffina Ricky [22]
Chciabym poda tylko skromny wybr spord znamienitych postaci, ktre wywary olbrzymi wpyw na postp w zarzdzaniu. Ze wzgldu na charakter tej ksiki
przytaczam tylko bardzo skrcon ich charakterystyk:
Sokrates
400 p.n.e. autor koncepcji i praktyki zarzdzania,
Platon
350 p.n.e. podkrela rol specjalizacji w pracy,
Alfarbi
900 p.n.e. wyrnia znaczenie posiadania cechy przywdztwa w zarzdzaniu,
Robert Owen
17711858 zmieni sposb traktowania i nada due
znaczenie warunkom ludzkiej pracy,
Charles Babage
17521871 koncentrowa si na efektywnoci produkcji,
Frank Gilberth
18681924 projektant wydajnych stanowisk pracy,
Lilian Gilbert
18791972 prace nad optymalizacj np. optymalizacja
sposobu ukadania cegy, psychologia przemysu, z dwunastk taniej (bya matk
12 dzieci),
Henry Gantt
18611912 autor powszechnie stosowanego wykresu
Gantta,
Harrington Emerson 18531931 doradca organizacyjny rzdu USA,
Henry Ford
18631947 wynalazca tamy produkcyjnej,
Eliyahu Goldratt
acuch krytyczny, tak silna organizacja, jak
silne jej najsabsze ogniwo,
Frederick W. Taylor 18611919 pionier w dziedzinie wydajnoci pracy.
11
1.2. Podstawowe pojcia i definicje

stosowane w zarzdzaniu projektami
Zarzdzanie
Definicji zarzdzania jest wiele, tak jak ksiek na ten temat. Wikszo z nich dy do zwizego i precyzyjnego zdefiniowania istoty zagadnienia, jednak to czym jest
zarzdzanie zaley od szczebla, obszaru i organizacji, gdzie nastpuje proces zarzdzania. Jedna z definicji mwi, e zarzdzanie to dokadne poznanie tego, czego si
oczekuje od ludzi, a nastpnie dopilnowanie, aby wykonali to w najlepszy i najtaszy
sposb [F.W. Taylor. Shop Manager, Harper & Row, New York 1903, s. 21].
Gdy przedmiotem zarzdzania bd projekty informatyczne oraz zakres kompetencji i czynnoci nalecy do kierownika projektu, wwczas zarzdzanie moemy zdefiniowa jako og dziaa zmierzajcych do efektywnego wykorzystania zespow ludzkich, rodkw materialnych i czasu w celu osignicia wczeniej sformuowanego celu
projektu informatycznego w okrelonej technologii zakresie i jakoci.
W procesie zarzdzania mona wyrni pi podstawowych funkcji: planowanie,
organizowanie, przekazywanie polece, koordynacj i kontrolowanie.
W ramach kadej z tych funkcji zarzdzajcy moe wykorzystywa okrelone
rodki organizacyjne, motywacyjne i techniczne, suce do ich realizacji. Zarzdzanie
to take nauka o metodach, zasadach i instrumentach dotyczcych realizacji podanych
zaoe.
Projekt
Projekt (ang. Project) jest nowym przedsiwziciem, nie majcym wzorca, nie realizowanym wczeniej. Dotyczy nowej sytuacji, wymaga nierutynowego podejcia. Nie
moemy polega na historycznych sposobach postpowania z danym problemem. Projekt jest to przedsiwzicie, na ktre skada si zesp czynnoci, ktre s charakterystyczne przez to, e maj dat rozpoczcia, specyficzne cele i limity, ustalone odpowiedzialnoci (obowizki) realizatorw, budet, rozkad czynnoci oraz dat ich ukoczenia
(gdy celem projektu jest rozwinicie systemu oprogramowania, wtedy jest to projekt
rozwoju oprogramowania lub projekt inynierii oprogramowania). Podane cechy decyduj o tym, e jest to nowe przedsiwzicie nie majce wzorca, nie bdce rutynowymi
dziaaniami, nie realizowane wczeniej. Projekt, projektowanie twrcza dziaalno
zwizana
z powstawaniem produktu, powodujca jego zrnicowanie wynikajce z cech, parametrw uytkowych, zgodnoci ze standardami, trwaoci, niezawodnoci, atwoci naprawy i dajcego si odrni od innych projektw stylu. Projekt ma wizje, najczciej
zawiera rysunki, schematy, obliczenia, opisy, kosztorysy itp. dotyczce wykonania da-
12
nego urzdzenia, przedmiotu, systemu informatycznego lub obiektu budowlanego.

Przykad
Projekt systemu Rejestr Zakadw Opieki Zdrowotnej (RZOZ), ktrego celem jest
wsparcie mechanizmw planowania i zaspokajania potrzeb na wiadczenia zdrowotne
przez ewidencj i biec aktualizacj informacji rejestrowych o wszystkich zakadach
medycznych w Polsce, z udziaem wojewdzkich organw rejestrowych oraz udostpniacie tych informacji przez serwis informacyjny www.rejestrzoz.gov.pl
Projekty mog dotycz rnych przedsiwzi informatycznych, dlatego zostay
opracowane rne techniki realizacji projektw, w tym uwzgldniajce obszar i zakres, takie jak:
Projekt od dou do gry (ang. Buttom-up design) proces projektowania systemu przez identyfikacj skadowych niszego poziomu, projektowanie struktury
w celu zintegrowania skadowych niszego poziomu w coraz wiksze podsystemy, a
projekt bdzie ukoczony.
Projekt od gry do dou (ang. Top down design) proces projektowania systemu poprzez identyfikacj jego wikszych skadnikw, rozoenie ich na skadniki
niszego poziomu oraz rozdzielanie dopki podany poziom szczegowoci nie
zostanie osignity, jest to dziaanie przeciwne do projektu od dou do gry.
Projekt inynierii oprogramowania (ang. Software engineering project) zestaw
wszystkich czynnoci, funkcji i zada zarwno technicznych, jak i menederskich,
wymaganych do zaspokojenia terminw i warunkw realizacji projektu. Projekt inynierii oprogramowania moe by czci wikszego projektu. Projekt inynierii oprogramowania jest czynnoci charakteryzujc si dat startu, specyficznymi celami i
limitami, ustanowionymi obowizkami, budetem i planem oraz dat ukoczenia.
Projekt inynierii oprogramowania zuywa zasoby, ktre speniaj wymagania projektu, wyszczeglnione w uzgodnieniach projektowych. W niektrych przypadkach projekt moe obejmowa tylko porcj produktu oprogramowania, moe trwa wiele lat i
skada si z licznych podprojektw.
Projekt inynierii systemu (ang. System engineering project) zestaw wszystkich
czynnoci, funkcji zarwno technicznych, jak i zarzdczych, wymaganych do zaspokojenia terminw i warunkw realizacji projektu. Projekt inynierii systemu jest
czynnoci charakteryzujc si dat startu, specyficznymi celami i limitami, ustanowionymi obowizkami, budetem i planem oraz dat ukoczenia. Zuywa zasoby i ma
na celu wytworzenie produktu lub zestawu produktw, ktre zaspokajaj wymagania
13
projektu wyszczeglnione w specyfikacji projektu. W niektrych przypadkach moe

obejmowa tylko porcj produktu oprogramowania, trwa wiele lat i skada si
z licznych podprojektw.
Projekt oprogramowania (ang. Software desing) proces definiowania architektury oprogramowania skadnikw, moduw, interfejsw, podejcia testowego oraz
danych dla systemu oprogramowania.
Projekt rozwoju oprogramowania (ang. Software development process) patrz
projekt inynierii oprogramowania.
Projekt systemu (ang. System design) 1. Proces (patrz p. 1.4) definiowania architektury, jej skadnikw, moduw funkcjonalnych, interfejsu, danych, sprztu/oprogramowania dla systemu w celu zaspokojenia wyszczeglnionego wymagania
systemu. 2. Wynik przebiegu procesw projektowania systemu. Bliskoznaczny projektowi architektury. Patrz te projekt oprogramowania.
Projekt wstpny (ang. Preliminary desing) 1. Proces analizowania alternatyw
projektu oraz definiowania architektury sprztu/systemu oprogramowania. W inynierii oprogramowania wstpny projekt zwykle zawiera definicj oraz struktur komputerowych skadnikw programw i danych, definicje interfejsw oraz przygotowanie
rozmieszczenia w czasie i oszacowania kosztw. 2. Wynik przebiegu procesw projektowania wstpnego. Niekiedy rozumiany jako opis projektu wstpnego.
Projektowanie-do-kosztu (ang. Desing-to-cost) podejcie w zarzdzania projektem, polegajce na utrzymania projektu w granicach kosztu przewidzianego w harmonogramie. To znaczy, e przebieg projektowania jest oceniany (oszacowywany) poprzez monitorowanie jednostkowych wymaga w kolejnoci zalenej od wanoci
oraz ustanowienie rygorystycznych celw kosztowych do projektowania i wykonania
kadego zadania. Aby to osign, rezerwuje si zapas na przypadki odstpstwa kosztw (zwykle 1520%), szukajc praktycznego kompromisu midzy operacyjnymi
moliwociami wykonawczymi, zakresem i harmonogramem.
Projektowanie szczegowe (ang. Detalied design) 1. W inynierii oprogramowania proces weryfikacji polegajcy na usuwaniu bdw, rozszerzaniu projektu wstpnego
oprogramowania w celu zawarcia bardziej szczegowych opisw logiki przetwarzania,
struktur danych oraz definicji danych do tego stopnia, gdzie projekt jest wystarczajco
szczegowy, aby mg zosta wdroony. 2.Wynik szczegowego procesu projektowania. Niekiedy bliskoznaczny z opisem specyfikacji projektu szczegowego.
14
1.3. Czynniki charakterystyczne projektu

Jak ju wczeniej wspomniano, projekt informatyczny charakteryzuje si innowacyjnoci, zakresem, ryzykiem, zapotrzebowaniem na zasoby ludzkie i materialne oraz
niezbdnym czasem na realizacj. Wykonawca projektu-realizator (firma, zesp),
przystpujc do jego wykonania, najczciej zmienia swj dotychczasowy model pracy (cho dobry do realizacji codziennych zada), ze wzgldu na cel projektu [14, 24,
46, 50]. Jednym z gwnych bdw jest niedocenienie zoonoci i wpywu na projekt kontekstu organizacyjnego firm zaangaowanych w jego realizacj i niezrozumienie celu. Gwne czynniki, ktre charakteryzuj projekt:
dziaania nastawione na dokonanie zmian,
ocena moliwych zyskw i strat,
zakres,
strategia,
ewolucja modelu prac w wyniku dowiadczenia,
wykorzystanie bazy wiedzy do tworzenia nowych jakoci,
cel (biznesowy, organizacyjny, jakociowy, inny), misja (przesanie),
oryginalno,
dziaanie niepowtarzalne,
dotyczy elementw rozwoju, ma cechy ewolucji,
dziaanie nastawione na nowatorsk obsug procesw biznesowych zwizanych z produktem dla okrelonego podmiotu, dla ktrego jest realizowany
projekt,
metoda racjonalnego dziaania jako czynnik sprawczy inicjacji projektw,
inne czynniki w zalenoci od charakteru projektu.
S to wspczesne wyznaczniki zwizane z projektem, ale czy jest to uniwersalna
recepta na generowanie projektw? W XIX wielu C. Bernard, francuski patolog zdefiniowa czynniki, ktre sprzyjaj powstawaniu rzeczy nowych projektw. Wedug
autora nale do nich:
wyrane ustalenie celu dziaania,
ustalenie szczegowo wszystkich kierunkw dziaa i rodkw, za pomoc ktrych mona osign zaoony cel,
uoenie dokadnego planu dziaania, zmierzajcego do osignicia celu przy zastosowaniu najlepszych w obecnych warunkach rodkw,
wykonanie skrupulatnie zaoonego planu,
skontrolowanie osignitych wynikw i porwnanie z zamierzonym celem wycignicie wnioskw na przyszo (do nastpnego planu projektu).
Mona zatem wnioskowa, e wymienione elementy racjonalnego dziaania byy
podstaw wspczesnego pojmowania realizacji projektw.
15
1.4. Proces
Proces jest to cile zdefiniowany cig dziaa nastawionych na ustabilizowanie
i optymalizacj stanowicych podstaw technologii wytwarzania wielu identycznych
lub podobnych produktw o okrelonych parametrach uytkowych lub wiadczonych
usugach. Przez technologi naley rozumie przetwarzanie w sposb celowy i ekonomiczny z zastosowaniem nowej techniki [31, 48].
Projekt a proces czynniki rnicujce
Waciwoci projektw jest ukierunkowanie na zmiany [7, 21]. Wprowadzenie
nowoci, zmiana stanu obecnego jest podstawow cech kadego projektu [39]. Projektem jest na przykad zbudowanie nowego poczenia kolejowego midzy miejscowoci A i B, wprowadzenie nowej usugi dostarczania poczty (listy, paczki) lub
zmiana organizacji pracy (cz pracownikw dostaje komputery do domu i przez
Internet przekazuje rezultaty pracy). Projekty s najczciej realizacj wytworw
ludzkiej wyobrani, ktra praktycznie adaptuje zdobycze nauki i przez przemylane
dziaanie tworzy now jako. Powtarzalne wykonywanie czynnoci, ktre s realizowane wedug okrelonej technologii, a ich rezultatem jest jasno zdefiniowany produkt,
to typowe dziaania procesowe, jak np. produkcja kolejnego z serii motocykla, roweru,
krzesa, pyty CD; wykonanie usugi, np. zdjcie RTG, sprzeda TV przez kasjera,
przelew bankowy i tym podobne czynnoci, ktre maja charakter powtarzalny i s
realizowane wedug opracowanych zasad (na podstawie wczeniej zrealizowanych
projektw). Sytuacje rutynowe, powtarzajce si z du czstotliwoci (do czasu
wprowadzenia zmiany przez projekt) w jednostce czasu oraz przez dowolnie dugi
okres, to procesy [20, 48].
Na rynku mamy do czynienia z podmiotami gospodarczymi, ktrych cech szczegln jest realizacja procesw lub projektw. Prowadzenie dziaalnoci procesowej
powinno by zdefiniowane i zweryfikowane w wielu konkretnych typowych realizacjach. Zespoy wykonawcw dysponuj opisanym cigiem dziaa stanowicym elementy w realizacji caego procesu. Zidentyfikowane s rwnie problemy zarzdzania
zespoem realizujcym proces i algorytmy wspdziaania, komunikacji, kompetencji
oraz funkcji z podziaem zakresu prac czonkw zespou. Projekt kreuje specyficzne,
niepowtarzalne podejcie, adekwatne do osignicia celu projektu, przez opracowanie
procedur zarzdzania i realizacji, ktre tworz proces realizacji.
Czas, zarwno opracowywania procesw, jak i projektw, jest czynnikiem wymuszajcym ich modyfikacje. Obserwujemy zamiany w technologii, powstaj nowe
urzdzenia, materiay, rodzaje energii, dowiadczenia i obserwacje z realizacji stosowanych procesw itp., co najczciej skutkuje potrzeb ich wprowadzenia do funkcjonujcych procesw podyktowan wzgldami ekonomicznymi sprostaniu konkuren-
16
cji. Zmiany w procesach najczciej s wprowadzane sukcesywnie w dugim okresie,

mog np. dotyczy wymiany narzdzia lub urzdzenia na tamie produkcyjnej, ktre
stanowio wskie gardo procesu lub zmiany kolejnoci czynnoci operacji czstkowych. W przypadku systemu informatycznego, w ktrym wystpuje proces generowania cyklicznych raportw z bazy danych zastosowanie szybszego procesora lub
pamici masowej o krtszym czasie dostpu, co moe spowodowa skrcenie czasu
niezbdnego na dostarczenie uytkownikowi wymaganego raportu. W projektach
zmiany maj szczeglny wymiar i skal, najczciej s gbokie, gruntowne, niekiedy
rewolucyjne. Skala projektw, ich charakter powoduje, e ich wprowadzenie
jest zwizane z poruszaniem si w obszarze czynnikw niepewnych oraz s zagroone
rn skal ryzyka.
Rola, wymagania, niezbdne predyspozycje i kwalifikacje kierownika s inne
w przypadku realizacji procesw, a inne w przypadku prowadzenia projektw [17,
18, 45]. Kierownictwo firmy, w ktrej s realizowane procesy, np. fabryka samochodw, sprztu AGD, banku, ingeruje w procesy, gdy np. obnia si jako produkcji, tj.
zwiksza si koszt reklamacji, a w przypadku banku przy kasie pojawia si nietypowa sytuacja, np. klient zagubi dokumenty, a chce podj gotwk; kto chce zrealizowa faszywy czek itp. W projekcie prawie wszystkie dziaania s nietypowe
i nigdy nie wiadomo, kiedy bdzie potrzeba konsultacji czy bezporednich dziaa
kierownictwa firmy, wic zaoy naley, e udzia kierownictwa jest wskazany przez
cay okres prowadzenia projektu.
W gospodarce wystpuj takie podmioty, ktre s nastawione na sprawn realizacj procesw, s to mae i due firmy wytwarzajce dobra uytku codziennego w skali
masowej (artykuy tzw. przemysowe oraz do zaspokojenia codziennych potrzeb, np.
spoywcze, higieniczne itp.), biura administracji publicznej, banki, sektor rozrywki
itp. Istniej take firmy realizujce jednostkowe przedsiwzicia w duszym czasie,
np. biura projektw (mostw, drg, okrtw itp.), jednostki odpowiedzialne za opracowanie i wprowadzenie nowej usugi bankowej, np. e-konto, podpis elektroniczny.
W dziaalnoci firm, ktrych podstawow dziaalno stanowi projekty mog wystpowa procesy, np. w ksigowoci czy obsudze patnoci. W dziaalnoci firm informatycznych, zwaszcza duych, cz dziaalnoci, np. produkcja komputerw, podzespow itp., to dziaalno procesowa, ale faza opracowania nowego produktu, np.
nowego procesora, innego rodzaju nonika informacji, to dziaanie projektowe. Na
naszym rynku informatycznym s firmy informatyczne, ktre specjalizuj si we
wdroeniach systemw (niekoniecznie wasnej produkcji) i tu wystpuj dziaania
zarwno projektowe, jak i procesowe (np. zdefiniowana technologia wdroenia systemu SAP). Firma informatyczna, ktra sprzedaje tylko komputery czy akcesoria niewiele si rni od firmy, ktra sprzedaje sprzt AGD, ale firma, ktra przyjmuje zlecenia wygrywa przetargi na opracowanie i dostarczenie systemu do obsugi
telekomunikacji, np. billingu, czy rozliczenia wszystkich podmiotw gospodarczych
z obowizku podatkowego z urzdem skarbowym, to na pewno firma realizujca pro-
jekty.
17
2. Planowanie projektu informatycznego

Jeli nie potrafisz czego zaplanowa,
to na jakiej podstawie sdzisz, e potrafisz to zrobi.
KF
Planowanie rozumiane jest najczciej jako zesp dziaa pomocnych w wytyczaniu
celw organizacji i okrelaniu sposobu ich najlepszej realizacji. W procesie planowania
wystpuj takie elementy, jak podejmowanie decyzji, wybr kierunkw dziaa oraz
sprawno zarzdzania. Planowanie jest rwnie immanentn czci projektu informatycznego, ktrego zadaniem jest osignicie celu projektu z uwzgldnianiem ogranicze
projektu.
Trudno ustali list priorytetw uniwersaln dla wszystkich projektw, ktra uzasadniaaby czy wskazywaaby na cele i zadania zwizane z szacowaniem planowania
projektu [2, 11, 42, 43]. Do najwaniejszych nale:
okrelenie zaoe projektowych (cel, zakres, ograniczenia),
oszacowanie kosztw przedsiwzicia i jego uytecznoci,
pomoc w identyfikacji obszarw ryzyka,
utworzenie harmonogramu, ktrego cechy to:
moliwo koordynacji i integracji prac tworzcych przedsiwzicie,
podstawowe narzdzie do kontroli realizacji projektu,
wspieranie motywacji zespow przez okrelenie celw,
miara postpu prac,
tworzenie wiedzy dla przyszych projektw.
Nie tylko nieudane projekty s rdem postpu.
KF
Planowanie jest procesem realizowanym w caym cyklu ycia projektu
Pytania, jakie najczciej pojawiaj si przed rozpoczciem planowania to:
1. Jak daleko planowa?
2. Jak szczegowo (gboko) planowa?
18
3. Jak duo czasu powici na planowanie?

4. Skd czerpa dane?
Mwi si, e planowanie zabiera co najmniej 10% czasu, ale czasem dochodzi nawet do 90%.
2.1. Cele planowania projektu

Planowanie projektu w znacznej mierze jest to szacowanie czasu, nakadw pracy i
innych zasobw niezbdnych do realizacji projektu. Rne elementy planu mog by
podane w zalenoci od tego kto jest odbiorc planu. W projektach, ktrych realizacji chcemy si podj w ramach kontraktw zewntrznych, np. przetargw publicznych, istotn spraw jest oszacowanie kosztw oraz czasu niezbdnego na realizacj w
postaci raportu (biznes planu) dla zarzdu firmy, ktry ma podj decyzje w sprawie
zdobycia kontraktu. W takim przypadku planowanie odbywa si na podstawie specyfikacji wymaga systemu przedstawionej przez klienta.
Gdy mamy do czynienia z projektami wewntrznymi najczciej zanim powstanie specyfikacja, wwczas od zespou wykonawczego zarzd firmy oczekuje oszacowania projektu na podstawie zdefiniowanego problemu lub pomysu na wytworzenie produktu, ktry bdzie mia warto rynkow. W takich projektach wiedza na ich temat
ewoluuje w miar rozwoju prac koncepcyjnych i pozyskiwania wiedzy z otoczenia, co
umoliwia w kolejnych fazach projektu uszczegowienie szacowania. Zaleceniem
w takich projektach jest iteracyjne szacowanie ponownie po opracowaniu specyfikacji
oraz po zakoczeniu projektowania i wytworzeniu prototypu systemu. Po kadorazowym przegldzie harmonogramu i budetu, jeli nastpuj rozbienoci z planem wczeniejszym, to o tym fakcie kierownik projektu powinien powiadomi sponsora projektu.
Sponsorem projektu w przypadku projektw zewntrznych jest podmiot zamawiajcy
projekt, w projektach wewntrznych natomiast zarzd firmy lub uprawomocniona
osoba funkcyjna.
Planujemy rwnie po to, aby byo wiadomo
co musimy lub moemy zmienia.
KF
Na og planowanie rozumiane jest jako wytyczenie celw organizacji i okrelenie
sposobu ich najlepszej realizacji. W procesie planowania wystpuj takie elementy,
jak podejmowanie decyzji, wybr kierunkw dziaa oraz sprawno zarzdzania.
Planowanie jest rwnie immanentn czci projektu informatycznego, ktrego zadaniem jest osignicie celu projektu z uwzgldnieniem ogranicze projektu, takich
jak:
19
koszt, czyli rodki finansowe, ktre moemy wykorzysta do realizacji projektu

budet projektu,
czas, w jakim naley wykona projekt harmonogram projektu,
zakres, czyli jak posta finaln ma przedstawia zrealizowany projekt w sensie
funkcjonalnoci, uytych technologii, jakoci, obszaru zastosowania itp. przekada si
bezporednio na prac, jak trzeba wykona, aby osign oczekiwany cel projektu.
W wielu rozwaaniach zwizanych z planowaniem projektw wyrnia si czsto
czwarty parametr, ktrym jest jako [8, 12, 15, 28, 37, 40]. Korekta jednego z tych
elementw wpywa na pozostae dwa. Mimo e wszystkie trzy s wane, zwykle jeden
z wymienionych elementw bdzie mia najwikszy wpyw na projekt.
Zwizek midzy tymi elementami jest rny w rnych projektach i okrela rodzaje problemw, jakie moemy napotka oraz rozwizania, jakie mona zastosowa.
Wiedzc o ograniczeniach lub dopuszczalnej elastycznoci, mona atwiej planowa
projekt i nim zarzdza. Naley rwnie podkreli, e duy wpyw na planowanie
projektu informatycznego ma tzw. pula zasobw projektw (patrz, co to jest pula zasobw p. 2.3).
Plan jest najczciej projekcj wyobrani przyszego kierownika projektu co do
sposobu osignicia celu.
2.2. Definiowanie celw projektu

Opis celw projektu jest bardzo wanym i niekiedy trudnym zadaniem, wymagajcym rozwaenia wielu czynnikw, ktre w sposb mierzalny przedstawiaj produkt
(produkty), przez ktre osigamy cele:
biznesowe,
jakociowe,
technologiczne,
konkurencyjne,
inne cele.
Najczciej mao si powica czasu na wyspecyfikowanie mierzalnych i porwnywalnych efektw, ktre powinien wnosi projekt. Bardzo czsto jako cel projektu wskazuje si np. budow systemu informatycznego, wdroenie oprogramowania czy budow
sieci komputerowej i instalacj oprogramowania. Wiadomo, e s to jedynie rodki techniczne narzdzia, ktra mog by elementem by moe podstawowym w realizacji
projektu, ale celem zasadniczym projektu jest uzyskanie nowej jakoci w organizacji,
ktra jest beneficjentem projektu, wyeliminowanie procesw, ktre s przyczyn hamowania rozwoju lub braku konkurencyjnoci. Celem takich projektw moe by usprawnienie procesw zarzdczych, ktrych wymiernym efektem moe by zmniejszenie zapasw, kosztw transportu, jednostkowych kosztw obsugi klienta itp.
20
2.3. Zasoby projektu

W rozdziale tym przyjto nomenklatur i sposb zarzdzania zasobami zaimplementowanymi w programie MS Projekt 2000.
We wspczesnych firmach informatycznych jest rzadkoci przydzielenie osoby
do jednego projektu od jego rozpoczcia a do zakoczenia, bez nakadania na ni
dodatkowych, wykraczajcych poza jeden projekt, zobowiza. Wspuytkowanie
zasobw midzy projektami pozwala na wiksz elastyczno i kontrol w zarzdzaniu zasobami. Wspuytkowanie zasobw naley rozway, jeeli speniony jest
ktry z podanych warunkw:
1. Nakadanie si projektw. Moe si zdarzy, e konieczne bdzie rozpoczcie
nowego projektu przed zakoczeniem projektu wykonywanego aktualnie. W razie
potrzeby dzielenia czasu midzy projektami, wspuytkowanie zasobw midzy plikami tych projektw moe pomc w zapobieeniu nadmiernej alokacji zasobw.
Chcc przenie dane zasobw, takie jak stawki kosztw, z dotychczasowego projektu
do nowego projektu, mona utworzy pul zasobw, aby zawrze w niej zasoby oraz
informacje o nich dla obu plikw. Utworzenie puli zasobw i nastpujce po nim
przeniesienie informacji o zasobach uatwi przenoszenie danych ze starego do nowego
pliku projektu.
2. Organizowanie zasobw w obszary funkcjonalne. Jeeli trzeba przydzieli
zasoby, ktre pracuj nad wieloma projektami w ramach procesu zarzdzania, na
przykad rewidentw i ksigowych, uzasadnione jest utworzenie dla nich puli zasobw. Nastpnie meneder grupy funkcjonalnej moe zbilansowa ich obcienie prac
i zastpi lub ponownie przydzieli zasoby, aby zachowa zgodno z harmonogramem. Jeeli nie ma znaczenia, ktry zasb wykonuje dane zadanie, pula zasobw
moe by zarzdzana poza zakresem projektu, w celu zapewnienia optymalnej efektywnoci harmonogramu pracy zasobw. Jeeli natomiast naley zachowa kontrol
nad tym, kto wykonuje jakie zadania, mona skonfigurowa proces zmian przydziaw zasobw, ktry umoliwi zatwierdzanie przydziaw zasobw przed dokonaniem
zmian przydziaw w pliku projektu.
3. Przewidywanie obcienia prac w wielu projektach. Wykorzystanie puli zasobw moe by bardzo wydajne w przewidywaniu obcienia prac osb, ktrych zadania maj podobne opisy. Mona przydzieli zasoby o nazwach oglnych, jak choby
Architekt I i Architekt II odpowiednio dla modszych i starszych czonkw personelu,
lub oznaczy rne poziomy dowiadczenia zawodowego niezbdne w realizacji zadania. Po przypisaniu zadaniom w kadym zbliajcym si projekcie odpowiednich opisw
prac, mona wspuytkowa zasoby za pomoc nowej puli zasobw i mona zobaczy
cakowit prac, przydzielon do kadego opisu prac. Warto nadmiernej alokacji kadego z opisw prac stanowi informacj, jak wiele okrelonych zasobw potrzeba do
wykonania pracy nad projektami zgodnie z biecymi harmonogramami projektw. Na
21
przykad nadmierna alokacja na poziomie 300% dla Architekta I oznacza, e do wykonania pracy potrzeba trzech modszych architektw. Nastpnie, po ucileniu listy zasobw projektu, mona wprowadzi konkretne nazwy do kadego opisu prac i ponownie
przydzieli prac rzeczywistym osobom, ktr j wykonaj.
Co to jest pula zasobw
Pula zasobw umoliwia wspuytkowanie zasobw przez wiele projektw.
Uywanie puli zasobw umoliwia sporzdzanie harmonogramw dla zasobw pracy
we wszystkich projektach, identyfikacj konfliktw midzy przydziaami w rnych
projektach i monitorowanie, wykorzystywania czasu zasobu w wielu projektach. Jeeli informacje o ludziach lub sprzcie pracujcym nad zadaniami znajduj si
w wielu plikach projektw, mona uy puli zasobw do centralizacji informacji
o zasobach, takich jak nazwa zasobu, uywany kalendarz, jednostki zasobu i tabele
stawek kosztw, co uatwi zarzdzanie projektem. Kady projekt, ktry uywa zasobw z puli zasobw, jest nazywany plikiem wspuytkujcym. Jako puli zasobw
mona uywa dowolnego, istniejcego pliku projektu, ale zaleca si utworzenie nowego pliku projektu tylko na informacje o zasobach, by jak najbardziej uatwi zarzdzanie informacjami o zasobach i przydziaami zada midzy plikami wspuytkujcymi a pul zasobw.
2.4. Definiowanie ogranicze w projekcie

Ograniczeniami w projekcie s czynniki, ktre maj podstawowy wpyw na opcje
dziaa kierownika projektu. Typowe trzy gwne ograniczenia to:
Harmonogram ograniczenia, takie jak staa data zakoczenia lub termin ostateczny w przypadku gwnych punktw kontrolnych.
Zasoby (materia, wyposaenie, sprzt i ludzie oraz skojarzone z nimi koszty)
ograniczenie, takie jak uprzednio zdefiniowany budet.
Zakres ograniczenie, takie jak zakadana funkcjonalno, technologia, produkty
itp.
Zmiana jednego z wymienionych ogranicze zwykle wpywa na dwa pozostae,
a take na jako projektu. Na przykad zmniejszenie czasu trwania projektu (harmonogram) moe zwikszy liczb pracownikw potrzebnych do realizacji planu (zasoby) oraz zmniejszy liczb waciwoci cechujcych produkt (zakres). Meneder projektu musi okreli, czy mona zaakceptowa tak degradacj. Taki zwizek jest
nazywany potrjnym ograniczeniem zarzdzania projektem lub trjktem ogranicze
projektu. Podczas procesu planowania naley sporzdzi list ogranicze projektu,
aby upewni si, e wszyscy wykonawcy projektu zostali o niej powiadomieni i mog
22
si do niej odnie. Waciwym dla wykonawcw jest take uzgodnienie sposobu ich
reakcji na niespodziewane ograniczenia, ktre mog ujawni si w czasie trwania projektu. Na przykad, jeeli koszty pracy oka si wysze od przewidywanych, to wykonawcy mog zada zmniejszenia zakresu projektu.
Gwne czynniki, ktre rwnie naley uwzgldni w planowaniu projektu:
pienidze/budet, jakim dysponujemy,
czas, w ktrym projekt naley zrealizowa,
ludzie/nakad pracy, jaki wymaga realizacja projektu,
miejsce, w ktrym projekt bdzie realizowany.
wyposaenie/warunki pracy oraz rodki techniczne i narzdzia, ktrymi dysponujemy,
komunikacja/lokalizacja zespou, poczta, telefon, videokonferencje itp.,
logistyka,
wyksztacenie czonkw zespou,
kompetencje posiadane,
wiedza (praktyczna i teoretyczna),
zdolnoci,
umiejtnoci,
outsourcing niektrych prac, zada, zasobw.
Poniewa przy realizacji projektw informatycznych cz czynnikw jest stosunkowo atwo mierzalna i porwnywalna, jak pienidze, czas, wyposaenie stanowiska
pracy czy warunki pracy, tzw. standardy, wic o sukcesie projektu mog zdecydowa
pozostae czynniki, ktre wymagaj wikszego dowiadczenia i uwagi.
Etapy i czynnoci przygotowawcze zwizane z planowaniem projektu:
Studium wykonalnoci projektu (SWP) stwierdza, czy dany projekt przy danych zasobach ma szanse wykonania (zakoczenia si sukcesem).
Inicjowanie projektu (IP) zbir czynnoci, ktre naley podj przed formalnym uruchomieniem cyklu prac nad projektem:
opis rozwizania technicznego,
opis (wstpny plan) projektu (ang. Business Case),
ustanowienie projektu.
Dziaania w obrbie inicjacji projektu zale od punktu jego startu [11, 22, 26, 29].
Rozpoczynajc prace nad SWP, zmierzamy do IP, ale zanim to ewentualnie nastpi,
naley wykona prace przez wyspecjalizowane zespoy, ktre przedkadaj dokumenty
wymagane w danej firmie. Przykadowy schemat postpowania podano na rys. 2.2.
Opis projektu
Opis projektu moe by wykonywany wedug rnych, wczeniej przygotowanych
formularzy, wzorcw. Ich posta jest zalena od dowiadczenia i obowizujcych

STUDIUM
STUDIUM
WYKONALNO-
23
Przegld opisu projektu
WYKONALNOCI
CI PROJEKTU
PROJEKTU
Opis projektu
Wybr strategii prowadzenia

projektu
Strategia
Identyfikacja
kategorii ryzyka
Ocena ryzyka
Identyfikacja
i dobr zada
Zadania
Oszacowanie zada
Oszacowanie
zada
INICJOWANIE
INICJOWANIE
PROJEKTU
PROJEKTU
Harmonogramowanie
Rys. 2.2. Etapy i czynnoci przygotowawcze zwizane z planowaniem projektu
norm, zarzdze czy ustale zwizanych z realizacj projektu przez dany podmiot.
Przytoczono najczciej spotykan specyfikacj zawartoci opisu projektu:
opis celw projektu,
okrelenie zakresu, oglna charakterystyka, jego otoczenie i umiejscowienie (fizyczne),
okrelenie granic projektu i punktw kontrolnych, ogranicze i zaoe,
zalenoci od innych projektw i powizania z nimi,
okrelenie strategii budowy (wydania, wersje, podprojekty patrz dalej),
oszacowanie ryzyka projektu,
podzia prac i oszacowanie nakadw (w cyklu budowy i dziaania),
wstpny harmonogramu projektu,
24
preliminarz kosztw,
okrelenie struktury uczestnikw projektu (klienta, zespou projektowego, innych),
okrelenie wymaganych metryk jakoci produktu,
rozwizania prawne,
ustanowienie i rozpoczcie projektu,
mierniki sukcesu projektu.
Analiza opisu projektu
Jedna z gwnych przyczyn poraek projektw to niewaciwa identyfikacja
i brak zgodnoci celw midzy wykonawc a klientem (patrz rozdz. 9) [52, 56]. Dlatego analiza opisu projektu powinna dotyczy obydwu stron przedsiwzicia
i uwzgldnia potrzeb uzyskania odpowiedzi na pytania:
Czy cele projektu jasno odzwierciedlaj potrzeby klienta?
Czy projekt ma zdefiniowane produkty kocowe?
Czy s sprecyzowane mierniki sukcesu?
Czy cele projektu s perspektywiczne i osigalne?
Czy cele nie s wzajemnie sprzeczne (czy moliwy jest kompromis)?
Czy cele wyznaczaj w przyblieniu przedzia czasu dla ich osignicia ?
Czy cele s zgodne z oczekiwaniami klienta i czy gwne kierownictwo klienta
jest zaangaowane w dziaania dla ich osignicia?
Czy cele zostay uzgodnione ze sponsorem projektu?
Szczeglnie istotne jest uwiadomienie zespoowi realizujcemu projekt, e kluczow spraw jest pamitanie o zdefiniowanych i uzgodnionych celach projektu oraz prowadzenie okresowej weryfikacji ich zrozumienia przez poszczeglnych wykonawcw.
2.5. Strategia realizacji projektu

Wybr strategii rozwoju projektu jest poprzedzony analiz wielkoci projektu, horyzontu czasowego jego realizacji, poziomem dopuszczalnego ryzyka i innymi czynnikami. Wyrnia si kilka strategii, ktre maj swoje nazwy:
fazowa, monolityczna sekwencja kolejno wykonywanych faz, dobra dla projektw o niskim poziomie ryzyka,
wydania, wersje wytwarzane s fragmenty (podsystemy, komponenty), inkrementalne podsystemy mog powstawa w sekwencji lub rwnolegle, ich oddzielne wytwarzanie zmniejsza ryzyko ich uruchomienia
szybkiej cieki, prototypowania wytwarzany jest prototyp, nastpnie wyko-
25
nywana jest jego ocena, po ktrej wytwarzany jest system, zalecana przy wysokim ryzyku,
mieszana fragmenty (podprojekty) powstaj wedug rnych strategii, szczeglnie przydatna dla duych projektw obarczonych duym ryzykiem
Tabela 2.1. Wybr strategii realizacji projektu
w zalenoci od rozmiaru projektu i oceny ryzyka
Rozmiar projektu
< 3 mies.
3-6 mies.
> 6 mies.
Ocena ryzyka
niskie
rednie
wysokie
niskie
rednie
wysokie
niskie
rednie
wysokie
Strategia
fazowa
wydania
prototypowanie
fazowa lub wydania
wydania
wydania lub prototypowanie
wydania
wydania
mieszana lub prototypowanie
Kada strategia realizacji projektu powinna uwzgldnia pryncypia w zakresie zarzdzania, takie jak:
zarzdzanie wymaganiami zapewnienie jednoznacznego, obiektywnego okrelania cech tworzonego rozwizania oraz zapewnienie weryfikacji zgodnoci
docelowego produktu z wymaganiami,
kontrol przebiegu projektu moliwo biecego ledzenia faktycznego postpu prac i wczesne wykrywanie zagroe dla harmonogramu, budetu i jakoci
tworzonego systemu,
kontrol kosztw utrzymania moliwo realistycznego przewidywania kosztw przyszych modyfikacji wdroonego systemu.
2.6. Ocena ryzyka

Najczciej zagroenia (ryzyko projektu) ocenia si w dwch gwnych obszarach
dotyczcych uzasadnienie biznesowego projektu, tj. ryzyko biznesowe i ryzyko projektu. Czynniki, jakie naley bra pod uwag w cenie mona pogrupowa te, ktre
dotycz:
1. Zoonoci systemu lub produktu:
funkcje i algorytmy,
zoono sterowania, wyjtkw i/lub operacji matematycznych,
procedury wspdziaania z uytkownikiem,
26
znaczcy wpyw na prac ludzi,

wymagania jakociowe i efektywnociowe,
dua ilo danych, dania krtkiego czasu odpowiedzi,
wymagania technologii,
istotne zastosowanie specyficznego sprztu/oprogramowania.
2. Klienta i rodowiska docelowego:
liczba wzw i uytkownikw,
poziom wiedzy uytkownikw i ich udzia w projekcie,
priorytetowo systemu i jego znaczenie dla zamawiajcego,
konieczno wprowadzenia zmian w biurach, oddziaach, procedurach.
3. rodowiska budowy systemu.
4. Harmonogramw, ich niezmiennoci bd elastycznoci.
5. Poziomu wiedzy i dowiadczenia zespou projektowego, stabilnoci.
6. Oszacowania ram czasowych.
7. Korzystania z zewntrznych dostawcw i podwykonawcw.
8. Fizycznego i technologicznego rodowiska realizacji projektu.
W przypadku oceny ryzyka jako wysokiego:
9. Wskazania do obnienia zoonoci projektu.
10. Udokumentowania obszarw wysokiego ryzyka.
11. Formalnego memorandum.
Patrz take: [22, 28, 31, 32, 33].
2.7. Struktura projektu dekompozycja projektu

na zadania WBS
W kadym projekcie PM dekomponuje cay projekt na WBS (ang. Work Breakdown Structure) do poziomu zadania (ang. task), ktre definiuj czynnoci, jakie naley zrealizowa w celu wyprodukowania okrelonego produktu, usugi, dokumentacji
itp. w zalenoci od tego do czego ma suy realizacja zdefiniowanego zadania. Zadanie moe si dzieli na czynnoci. Przyjmuje si, e zadanie powinno by przypisane w realizacji dla pojedynczej osoby i czas jego trwania od 1 do kilku dni, ponadto na
by mierzalny i da si skontrolowa co do wykonania oraz jakoci.
Definicja struktury WBS
Gwnym zadaniem kierownika projektu jest waciwe okrelenie elementw
skadowych prac, ktre naley zrealizowa w projekcie. Struktura WBS reprezentuje prac nad wytworzeniem indywidualnych komponentw i prac nad integracj
27
komponentw w projekt. Gwnym celem struktury WBS jest przejrzysta i adekwatna do rodzaju projektu organizacja powiza i wspdziaania wytwarzanych
produktw zmierzajcych do osignicia celu projektu. Umoliwia graficzne wyobraenie i sprawdzenie czy dany projekt ma szanse realizacji. Wszystko to, co
znajduje si w projekcie musi si znajdowa w strukturze WBS. Jeli czego nie ma
uwzgldnionego w WBS, to oznacza, e nie ma tego w projekcie. WBS moe by
struktur hierarchiczn drzewa. Poczwszy od korzenia do lici, wzrasta stopie
szczegowoci opisu WBS. Komponentami WBS mog by zarwno produkty, jak
i usugi [3, 26, 32]. Plan projektu powinien by dokadny, zawiera wszystkie zadania, czynnoci niezbdne do osignicia zamierzonych celw projektu. Struktura
WBS powinna to umoliwia.
WBS i jego rodzaje
WBS produktowy stanowi perspektyw produktw. Fazy WBS produktowego to
najbardziej oglne komponenty, ktre musz by zrealizowane w projekcie.
WBS fazowy opiera si na modelu fazowym cyklu ycia oprogramowania tzw.
faz, ktre skadaj si z kilku dziaa, a te z kolei z aktywnoci. Faza (ang. Phase)
faza rozwoju w produkcie lub czynnoci, jedna z faz modelu cyklu ycia oprogramowania, np. faza analizy (ang. Analysis phase) jest to jedna z dodatkowych faz modelu kaskadowego cyklu ycia oprogramowania, w ktrej budowany jest logiczny model
systemu. Celem fazy analizy jest udzielenie odpowiedzi na pytanie: jak system ma
dziaa? Dziaaniem w tej fazie i jest udzielenie odpowiedzi na pytanie: jak system ma
dziaa?, to nastpuje przez aktywno, wynikiem ktrej jest logiczny model systemu,
opisujcy sposb realizacji przez system postawionych wymaga, lecz abstrahujcy
od szczegw implementacyjnych. WBS jest struktur podziau pracy, jak naley
wykona, aby osign zamierzone cele projektu. WBS stanowi hierarchiczn struktur drzewa. Na poziomie zerowym jest umieszczona nazwa projektu. Jednake nie
oznacza to, e projekt jest czci WBS. Stanowi on raczej opis, jakiego projektu dotyczy dany WBS. Idea tworzenie WBS: og pracy dzielimy na fazy, nastpnie fazy
dzielimy na zadania, a te na aktywnoci. WBS: Faza zadanie aktywno [3].
Fazy tworz najbardziej oglny podzia pracy. Znajduj si one na pierwszym poziomie WBS, zaraz po nazwie projektu. Zadania znajduj si na niszym poziomie, poniej faz. Zadania mog by dekomponowane na aktywnoci lub na inne zadania. Skadowe danego zadania znajduj si na niszym poziomie. Tak wic zadania mog
znajdowa si na poziomie drugim, trzecim itd. Wane jest, e na ostatnim poziomie
dekompozycji danego zadania musz znajdowa si aktywnoci (dostarczajce produktw). Aktywnoci znajduj si na najniszym poziomie WBS. Reprezentuj one
produkty, ktre s przydzielane konkretnym osobom. Osoby te wykonuj prac potrzebn do stworzenia produktu. Tak wic aktywno jest kombinacj produktu i procesu. Tworzc struktur WBS, naley zwrci uwag na numerowanie kolejnych
28
komponentw WBS. Kady element WBS jest unikatowy. Na poziomie zerowym

znajduje si jeden komponent nazwa projektu o numerze 1.0, na poziomie pierwszym znajduj si elementy numerowane od 1.1 do 1n, gdzie n jest liczb faz, na poziomie drugim znajduj si skadowe poszczeglnych faz, np. 1.1.1 do 1.1x, gdzie x
liczba komponentw skadowych pierwszej fazy, 1.2.1 do 1.2y, gdzie y liczba komponentw drugiej fazy.
WBS strukturalny tworzymy w celu przedstawienia organizacji zaangaowanej w
realizacj projektu. Naley uwzgldni takie elementy wspdziaania, ktre wynikaj
z umowy na tworzenie produktw oraz relacji z wykonawcami, ktra ma zabezpieczy
wykonanie projektu.
Etapy tworzenia WBS produktowego
1. Pierwszy poziom tworzymy z produktw, co do ktrych jestemy zobowizani
w umowie z klientem. Fazy w WBS produktowym s produktami. Produkty te s wyszczeglnione w umowie, dokumentacji, specyfikacji projektu. Ich nazwy powinny
by par rzeczownikw lub rzeczownika z przymiotnikiem, np. Specyfikacja, Specyfikacja projektu.
2. Dla kadego produktu na najwyszym poziomie naley dokona dekompozycji
do czci skadowych. Kada cz skadowa staje si komponentem czci WBS.
WBS powinien by tak tworzony, aby osoba postronna moga zrozumie cele wykonania zadania zwizanego z danym produktem. Podzia produktu na wyszym poziomie na produkty na niszym poziomie musi mie sens. Kady z produktw na niszym poziomie powinien odrnia si od pozostaych oraz by odrbn czci
produktu wyszego poziomu.
3. Kontynuacja dekompozycji powinna trwa do momentu osignicia odpowiedniego poziomu szczegowoci.
Zadania na najniszym poziomie aktywnoci powinny spenia nastpujce warunki:
powinny by moliwe do wykonania od jednego do dziesiciu dni,
czas ich wykonania nie krtszy od sporzdzenia raportu,
dla kadego zadania aktywnoci mona oszacowa koszty i czas oraz przydzieli odpowiednie osoby.
Zadania te powinny by nazwane w formie bezokolicznika: np. Tworzenie specyfikacji projektu.
4. W WBS powinny by opisane najwaniejsze czynnoci prowadzce do powstania produktu. W tworzeniu np. oprogramowania gwnymi etapami tworzenia jest
system, podsystem i funkcja. Naley tutaj uwzgldni wyniki testw, kompilacj kodu
i wymagan dokumentacj.
Kady wymagany produkt naley zdekomponowa do czynnoci, ktre s wymagane do jego utworzenia.
29
5. W miar rozwoju WBS moe mie kilka aktywnoci na poziomie drugim, trzecim itd. Jednake naley szczeglnie zwrci uwag, aby liczba aktywnoci zwizana
z danym produktem zadaniem nie bya ani za dua, ani za maa. Zaleca si, aby kady produkt zadanie skadao si z 7 +/ 2 aktywnoci. Jeeli jest ich od trzech do
piciu, to naley si zastanowi czy nie mona ich doczy do innego produktu
zadania. Jeeli jest ich wicej ni dziesi naley sprbowa podzieli dany produkt
zadanie (zwizane z tymi aktywnociami) na mniejsze produkty. Jednake s to tylko
zalecenia, jeli do konkretnego WBS trudno jest zastosowa powysze wskazwki,
naley je zaniecha. Struktura WBS powinna by logiczna, tzn. produkty skadowe
znajdujce si w WBS powinny tworzy produkt na wyszym poziomie oraz powinny
by znaczco rne, nie pokrywa si.
6. Sprawdzenie poprawnoci WBS rozpoczyna si od przechodzenia z najniszego
poziomu do najwyszego, inaczej od dou do gry od lici do korzenia. Przechodzc
z niszego poziomu do wyszego, naley sumowa produkty (aktywnoci lub zadania)
i sprawdza czy tworz one produkt na wyszym poziomie. W ten sposb sprawdzamy czy WBS jest kompletny, czy czego w nim nie brakuje. Jeeli okae si, e s
jakie luki w danym WBS, to naley go uzupeni.
7. Ostatni etap to sprawdzenie zgodnoci powstaego WBS z celami projektu,
czy przez utworzone produkty mona zrealizowa cele projektu [8].
Etapy tworzenia WBS fazowego:
1. Na poziomie pierwszym znajduj si fazy cyklu oprogramowania.
2. Nastpnie naley zidentyfikowa produkty, co do ktrych jestemy zobowizani
w umowie z klientem. Produkty te umiejscawiamy pod odpowiedni faz.
3. Dane produkty dekomponujemy podobnie jak w WBS produktowym.
Etapy tworzenia WBS strukturalnego:
1. Na pierwszym poziomie znajduje si firma klienta oraz firmy, ktre deklaruj
si do wykonania projektu.
2. Drugi poziom odzwierciedla zawarcie umowy. Poczenie firmy klienta z konkretnym wykonawc. Tworzona jest organizacja, ktra zajmuje si realizacj projektu.
3. Dla danej organizacji wykonujcej projekt jest tworzona struktura podziau pracy wedug WBS produktowego lub WBS fazowego.
Inne struktury podziau pracy
Struktura podziau pracy kontraktowa (Contractual WBS CWBS)
Jest tworzona w celu przedstawienia klientowi. Wykonawca projektu uywa kontraktowej struktury podziau pracy do zdefiniowania raportw, jakie bdzie przedstawia klientowi po zakoczeniu realizacji prac wyspecyfikowanych w kontrakcie.
30
CWBS zawiera wicej szczegw zwizanych z zarzdzaniem prac nad projektem,

po zakoczeniu ktrej nastpuj zobowizania stron projektu. Struktura ta jest pomocna w egzekwowaniu terminw patnoci przez klienta za projekt.
Struktura podziau pracy organizacyjna (Organizational Breakdown Structure OBS)
Przedstawia struktur organizacji realizujcej projekt. Pokazuje, ktre elementy
pracy s przydzielone, do ktrych jednostek organizacji. Taka struktura jest stosowana
w przypadku rozproszonych zespow lub ma specyficzn wiedz dziedzinow.
Zasoby (Resource Breakdown Structure RBS)
Odmiana organizacyjnej struktury podziau pracy. Jest uywana, kiedy zadania s
przydzielone konkretnym osobom.
Koszty (Bill of Materials)
Prezentuje hierarchiczn struktur zada, podzada, komponentw potrzebnych do
wyprodukowania produktu.
Projektowa struktura (Project Breakdown Structure PBS)
Projektowa struktura podziau pracy jest wykorzystywana w aplikacjach, gdzie pojcie struktury WBS jest niepoprawne w powizaniu ze struktur zasobw (RBS) [2].
POZIOM 1
Studium Moliwoci
realizacji/badanie
PROJEKT
Inicjacja
definiowanie celu
Projektowanie
Eksploatacja
Przygotowanie
planu i budetu
bad. potrzeb uytkownika

przegld rozwiza
alternatywnych
Specyfikacja
systemu
POZIOM 2
Analiza wymaga
Org. zespou
realizacyjnego
POZIOM 3
Rys. 2.3. Przykad WBS fazowego, prace poziomu 3 mona dzieli na dziaania (czynnoci)
(ang. activities)
Aby praktycznie zilustrowa etapy, jak rwnie sposb tworzenia diagramw

WBS, moemy korzysta z opisu faz wedug Coopers & Lybrand (tabela 2.2), gdzie
jest kolumna z typowymi fazami projektu, kolumna opisujca zesp czynnoci, ktre
realizujemy w ramach fazy oraz kolumna produktw kocowych, ktre powinny powsta na zakoczenie danej fazy. Tak rozpisany projekt umoliwia atwe tworzenie
zarwno WBS produktowego, jak rwnie fazowego (rys. 2.3).
Dla penego udokumentowania wszystkich produktw moemy zdefiniowa
POZIOM 4, na ktrym wyspecyfikujemy wytworzone w projekcie np. dokumentacje,
oprogramowanie, instrukcje, zainstalowany sprzt, uruchomione oprogramowanie itd.
31
Tabela 2.2. WBS: Standardowe fazy cyklu ycia projektu (wedug Coopers & Lybrand)
Faza
Studium
moliwoci
realizacji/badanie
Inicjacja
Specyfikowanie
Projektowanie
Realizacja
Instalowanie
Eksploatacja
Czynnoci
Zdefiniuj problem. Zbadaj
wymagania uytkownika.
Oce rozwizania alternatywne. Zale kierunek dziaania.
Przygotuj plan i budet. Przygotuj opis dziaalnoci firmy.
Produkt kocowy
Sprawozdanie studialne
Projekt planu technicznego. Projekt planu zasobw. Projekt uzasadnienia przedsiwzicia.

Szczegowy plan dla nastpnej fazy. Aprobata
dalszych dziaa.
Analizuj szczegowo wyma- Specyfikacja wymaga uytkownika. Kryteria
gania uytkownika. Okrel
akceptacji. Strategia instalacji i przejcia. Strakryteria akceptacji. Wymyl
tegia szkolenia. Szczegowy plan dla nastpnej
strategi implementacji. Opra- fazy. Akceptacja dalszych dziaa.
cuj plany.
Stwrz projekt systemu.
Projekt systemu. Strategia budowy systemu.
Wymyl strategi. Opracuj
Strategia testowania. Szczegowy plan dla
plan.
nastpnej fazy. Akceptacja dalszych dziaa.
Projektuj, pisz i testuj proModuy. Programy. Procedury. Dokumentacja
gramy. Skompletuj dokumen- systemu. Materiay do szkole. Szczegowy
tacj. Przeprowad testy
plan dla nastpnej fazy. Akceptacja dalszych
systemu. Opracuj plany.
dziaa.
Opracuj zasady konwersji.
System zatwierdzony przez uytkownika.
Przeprowad testy akceptuj- Szczegowy plan dla nastpnej fazy. Akceptace. Opracuj plany.
cja dalszych dziaa.
Przegld po implementacyjny. System nadajcy si do eksploatacji i utrzymania. Raport kocowy.
2.8. Szacowania w projekcie

Policz to co mona policzy, zmierz to co mona zmierzy,
a to co niemierzalne uczy mierzalnym.
Galileo Galilei
Wymiarowanie systemw informatycznych, w tym szacowanie poszczeglnych
elementw projektu, takich jak czas realizacji, pracochonno, koszty, wydajno,
zuycie materiaw i inne, s przedsiwziciem zoonym. Szczeglnym przedmiotem
szacowania jest ta cze projektu informatycznego, ktra dotyczy oprogramowania.
W przypadku takich nauk, jak fizyka, elektronika, ekonomia sprawa jest do oczywista i uwaga badaczy skoncentrowana jest wok jednostki miary i metody powtarzalnoci pomiaru.
32
Tabela 2.3. Fazy cyklu ycia projektu obiektowego dostosowane na potrzeby projektu grupowego
Faza
Planowanie
wstpne
(zaoenia)
Studium
wykonalnoci
Planowanie
projektu (ang.
Preliminary
project plan)
Specyfikacja
wymaga systemowych
Specyfikacja
wymaga na
oprogramowanie
(modelowanie)
Czynnoci
Poznanie celw, odpowiedzialnoci
i harmonogramu. Analiza problemu.
Okrelenie osb penicych rol klientw
Identyfikacja podstawowych wymaga.
Analiza wykonalnoci. Przygotowanie
raportu wykonalnoci.
Organizacja grupy, przypisanie rl.
Okrelenie planu dziaa, oczekiwanych
produktw, zasobw, przydziau prac. Okrelenie ryzyka, okrelenie strategii. Przyjcie
planu kontroli jakoci. Opracowanie harmonogramu. Przygotowanie wymaganych raportw.
Identyfikacja wymaga w oparciu o analiz
dokumentw, wywiady, pytania, etc. Specyfikacja wymaga. Weryfikacja i akceptacja.
Dziaania zmierzajce do zapewnienia
jakoci. Przygotowanie wymaganych
raportw.
Analiza wymaga. Modelowanie i specyfikacja. Ucilenie sownika danych. Weryfikacja
i akceptacja. Dziaania zmierzajce do zapewnienia jakoci. Ucilenie zaoe projektowych i implementacyjnych. Przygotowanie
wymaganych raportw i dokumentacji.
Projektowanie
systemu
Modelowanie i specyfikacja. Ucilenie sownika danych. Dziaania zmierzajce do zapewnienia jakoci. Ucilenie zaoe projektowych
i implementacyjnych. Przygotowanie wymaganych raportw i dokumentacji.
Projektowanie Projektowanie klas. Ucilenie sownika
klas
danych. Dziaania zmierzajce do zapewnienia jakoci. Ucilenie zaoe implementacyjnych. Przygotowanie wymaganych raportw.
Implementacja, Implementacja obiektw. Testowanie. Uzupenienie sownika danych. Dziaania zmieintegracja
rzajce do zapewnienia jakoci. Przygotowai testowanie
nie wymaganych raportw i dokumentacji.
Finalizacja
Dyskusja testw akceptacyjnych.

Dokumentowanie. Raport.
Produkty
Powizanie grupy z tematem projektu
Raport wykonalnoci
Raporty spotka
Plan projektu. Zaoenia strategii minimalizacji ryzyka. Plan nadzoru jakoci.
Szczegowy plan fazy nastpnej.
Raport przebiegu prac (w tym spotka)
Dokument specyfikacji wymaga uytkowych. Plan (projekt) testw akceptacyjnych. Sownik danych (wstpny).
Raport zmian. Raport przebiegu prac
(w tym take spotka
i dziaa projakociowych)
Modele systemu:
Model klas
Model funkcjonalny
Model dynamiczny
Sownik danych
Projekt testowania funkcjonalnego.
Podrcznik uytkownika (szkic). Szczegowy plan fazy nastpnej. Raport
zmian. Raport przebiegu prac
Dokumentacja projektu systemu. Sownik danych. Projekt testowania integracyjnego. Szczegowy plan fazy nastpnej. Raport zmian. Raport przebiegu
prac
Dokumentacja projektu klas. Sownik
danych. Projekt testowania obiektw.
Raport zmian. Raport przebiegu prac
Oprogramowanie projektu. Sownik
danych. Raport testowania obiektowego, integracyjnego, funkcjonalnego.
Dokumentacja (szkic). Szczegowy
plan fazy nastpnej. Raport zmian.
Raport przebiegu prac
Raport testowania akceptacyjnego.
Dokumentacja (szkic). Raport finalny
33
W przypadku informatyki problem dotyczy zoonoci oprogramowania, czyli

na og relacji, jakie wystpuj midzy dwoma, trzema programami, ktry jest bardziej zoony, trudniejszy w pielgnacji, implementacji algorytmw, testowaniu,
wdroeniu itd.
Szacowanie zada zwizanych z implementacj oprogramowania jest zagadnieniem trudnym, wymagajcym wspdziaania kierownika projektu z zespoami przewidzianymi do realizacji projektu, dostpu do informacji na temat podobnych przedsiwzi lub jego fragmentw, aby mona si posuy np. technik analogii zamiast
regu palca i sufitu. Podstaw prac nad szacowaniem zada jest opracowanie
w miar dokadnej struktury projektu, ktr naley dekomponowa do zada, ktre
realizuj pojedynczy wykonawcy lub specjalizowane zespoy w stosunkowo krtkim
czasie, np. kilku dni. Wprowadza si tu takie pojcia, jak:
nakad pracy (ang. effort) (MM man-months, PM preson-months),
czas trwania (ang. duration) (Mo months),
obcienie ludzi (ang. manpower loading) liczba wymaganych pracownikw
przydzielonych do projektu w funkcji czasu.
Dla oszacowania kosztu caego projektu, pojedynczej fazy, aktywnoci, s potrzebne kosztowe informacje [47, 51, 52]:
przed startem projektu (dla analizy koszty/zysk, negocjacji kontraktu),
podczas realizacji projektu (w celu zarzdzania projektem, planowania, monitorowania i kontroli),
musz by aktualizowane w trakcie prowadzenia projektu.
Metody szacowania zada
Przez szacowanie zada naley rozumie rne obszary mierzenia zada, ktre naley wykona, aby wytworzy oprogramowanie, midzy innymi:
prognozowana pracochonno,
koszty,
niezawodno,
zoono,
zoono implementacji algorytmw,
jako,
przenaszalno.
Nie ma uniwersalnej metody, ktra by w zadowalajcy sposb okrelaa wszystkie
obszary oprogramowania, i to niezalenie od jego charakteru, wielkoci itd.
Metoda punktw funkcyjnych (PF) jest stosowana przede wszystkim do szacowania pracochonnoci i jakoci oprogramowania.
Modele parametryczne, np. COCOMO [Boehm B. W., Software Engineering
Economics, Prentice Hall, 1981,Putnam L. H., A General Empirical Solution to
34
the Macro Software Sizing and Estimating Problem, IEEE Transaction of Software Enginering, SE-4, July 1978] znane jako najlepsze do szacowania kosztw [4].
Miary niezawodnoci oprogramowania opieraj si na okreleniu rednich czasw bezawaryjnej pracy oprogramowania, s to gwnie modele niezawodnociowe.
Naley wspomnie o mikrotechnice szacowania zada, faz, Wide-Band Delphi,
szacowania cakowitego wysiku przedsibiorstwa oraz przez eksperta lub oprogramowanie. Z innymi technikami szacowania projektw mona si zapozna w
pracy Z. Szyjewskiego [47]. W dalszej czci pracy szczegowo omwiono metod PF.
2.9. Metoda punktw funkcyjnych

W pnych latach siedemdziesitych IBM potrzebowa wynale metod oceny
kosztw rozwoju aplikacji niezalen od jzyka, w ktrym dana aplikacja ma by stworzona. Zleci realizacj takiego projektu jednemu ze swoich pracownikw Allanowi Albrechtowi, ktry w 1979 roku zaprezentowa wyniki swoich prac jako metod punktw
funkcyjnych podczas konferencji w Monerey w Kalifornii [Albrecht A.J., Measuring
Applications Development Productivity, Procedings of IBM applications Devision Join
SHARE/GUIID Symposium, Monterey, CA, 1979], [1, 26]. W pocztkowym okresie
pojawio si sporo zarzutw wobec tej metody, ze wzgldu na bardzo ograniczon liczb
parametrw wejciowych, ktre wykorzystywano, ale bya rozwijana i w 1984 opublikowano wersj, ktra uwzgldniaa 14 wspczynnikw majcych wpyw na projekt. Ta
wersja metody zacza zdobywa coraz wiksz liczb zwolennikw.
Punkty funkcyjne (PF) s rozumiane jako miara wielkoci aplikacji komputerowych i projektu, ktre naley stworzy. Jest to miara stworzona gwnie na uytek
szacowania wielkoci i kosztw projektu, ktre np. negocjujemy we wstpnej fazie
projektu z klientem. Podstaw mierzenia jest planowanie funkcjonalnoci (inaczej
specyfikowanie potrzeb uytkownika co do funkcjonalnoci, interfejsu, wielkoci
i iloci zbiorw danych itd.). Jest ona niezalena od jzyka programowania, metodologii rozwoju, technologii lub zdolnoci grup projektowych uytych do wytworzenia
aplikacji. Fakt i Albrecht po raz pierwszy uy jej do szacowania pracochonnoci
(wysiku) jest prost konsekwencj tego, e wielko projektu jest podstawowym
czynnikiem wpywajcym na pracochonno projektu.
Metoda PF nie jest doskonaym miernikiem pracochonnoci stworzenia aplikacji
lub wyceny jej wartoci biznesowej, aczkolwiek wielko projektu podana w punktach
funkcyjnych jest wanym czynnikiem w mierzeniu kadej z tych dwu wartoci. Ilustruje to prosta analogia w handlu nieruchomociami. Koszt wybudowania budynku A
o powierzchni 100 m2 jest zwykle mniejszy od kosztu wybudowania budynku B o
35
powierzchni 400 m2. Jednake wiele atrybutw, takich jak marmurowe azienki, armatura i podogi moe wpyn na to, i mniejszy dom moe by bardziej kosztowny.
Inne czynniki, takie jak lokalizacja i liczba sypialni moe take uczyni mniejszy dom
bardziej wartociowym miejscem zamieszkania. Tym samym koszt wybudowania 1
m2 w budynku A i B mog znacznie si rni oraz ich warto rynkowa niekoniecznie musi odzwierciedla poniesione nakady finansowe.
Mona nadmieni dlaczego punkty funkcyjne nie mierz wartoci projektu oraz
wskaza powody, ktre decyduj, e warto uywa punktw funkcyjnych:
1. Miara produktywnoci wiele wykonawcw projektw doszo do wniosku, e
pomimo prowadzenia szerszej dziaalnoci informatycznej znaczn cz angaowanych zasobw bazowych lokuj w produkcj oprogramowania. Policzenie kilku wariantw rozwizania tematu za pomoc punktw funkcyjnych daje im moliwo ocenienia jak dobrze sobie radz w tej dziedzinie.
2. Wspomaganie szacowania rozwoju od pocztku punkty funkcyjne uywane byy
jako technika do szacowania. Szacowanie wielkoci projektu jest oczywicie potrzebne
do szacowania kosztw aplikacji, co daje nam pojcie o sposobie jej wytwarzania. Nawet dla strategicznych projektw, ktre nie potrzebuj adnej ilociowej oceny, waciwe szacowanie jest potrzebne w celu waciwego przydziau pracownikw.
3. Monitorowanie umw zewntrznych (ang. Outsourcing) firmy zlecajce komu na zewntrz znaczce czci swoich zada oczekuj, e dostawca dostarczy produkt wedug specyfikacji, na odpowiednim poziomie jakoci, oczekuj zatem zwizku
z kosztami, ktre maj ponie firmy zewntrzne. Uycie metody PF w celu zademonstrowania zgodnoci swych szacunkw, adekwatn do skali produkcji oprogramowania, jest podstaw negocjowania ceny usugi.
4. Pomoc w decyzjach biznesowych firmy musz analizowa kady pakiet aplikacji w projekcie. Wielko w punktach funkcyjnych jest atrybutem, ktry musi by
ledzony dla iloci aplikacji w projekcie. Wraz z innymi danymi pozwoli na decyzje
dotyczce ponownego wykorzystania, wycofania lub zmodyfikowania aplikacji.
5. Normalizacja innych miar aby pokaza waciwy sens niektrych danych, naley
je porwna z punktami funkcyjnymi. Na przykad: informacje, e aplikacja o rozmiarze
100 punktw funkcyjnych, posiadajca 100 defektw, jest niezbyt dobr wiadomoci.
Ta sama ilo dostarczanych defektw dla aplikacji o rozmiarze 10 000 punktw funkcyjnych jest ju znacznie lepszym wskanikiem jakoci oprogramowania.
Podstawowe pojcia i wzory stosowane w metodzie PF
Granice systemu (ang. System Boundaries) jawnie okrelone granice systemu
poddawanego mierzeniu. Naley wyodrbni granic pomidzy projektem lub aplikacj z punktu widzenia uytkownika.
ILF (ang. Internal Logical File) wewntrzny plik logiczny grupa danych i rekordw powizanych ze sob i utrzymywanych wewntrz granic sytemu podtrzymywana przez zewntrzne wejcie EI (External Omput).
36
EIF (ang. External Interface File) zewntrzny plik interfejsowy grupa danych
i rekordw powizanych ze sob i utrzymywana na zewntrz granic sytemu, ktra jest
uywana tylko jako referencje wewntrz systemu.
RET (ang. Record Element Type) rekord, zbir powizanych ze sob logicznie
danych identyfikowalny przez uytkownika znajdujcy si wewntrz ILF lub EIF.
FTR (ang. File Type Referenced) plik, do ktrego odwouj si transakcje. Musi
by to ILF lub EIF.
DET (ang. Data Element Type) pojedyncza dana identyfikowalna z punktu
widzenia uytkownika. Niepowtarzalne pole DET jest informacj, ktra jest zmienn, a nie sta. Zmienne pole jest odczytywane z pliku lub stworzone za pomoc
DET-w zawartych w FTR. Dodatkowo DET moe wywoywa transakcje lub moe
by dodatkow informacj dotyczc danej transakcji. Jeli DET ma wiele wystpie (jest rekursywny), to tylko jego pierwsze wystpienie powinno by brane pod
uwag. IFPUG (International Function Point Group) [26] podaje szczegowe sposoby rozpoznawania i liczenia DET dla systemw z GUI oraz systemw czasu rzeczywistego.
EO (ang. External Output) zewntrzne wyjcie proces, w czasie ktrego
przetworzona grupa danych przekracza granice systemu z wewntrz na zewntrz
systemu. Dodatkowo moe uaktualnia ILF. Dane tworz raporty lub pliki wyjciowe wysyane do innych aplikacji. S one tworzone na podstawie jednego lub wicej
ILF oraz EIF.
EI (ang. External Inputs) zewntrzne wejcie proces, w czasie ktrego dane
przekraczaj granice systemu z zewntrz do wewntrz. Mog one pochodzi
z ekranu (klawiatury), przez ktre wprowadzamy dane lub inne aplikacje Dane te
mog suy do uaktualnienia jednego lub wicej ILF. Dane te mog by danymi
kontrolnymi lub operacyjnymi. Jeli s to dane kontrolne, to nie musz uaktualnia
ILF.
EQ (ang. External Inquiries) informacje zewntrzne proces, w ktrym dane
wychodz poza granice systemu. Nie moe zawiera przetworzonych lub obliczonych
danych wewntrz moduu. To ilo danych, ktre otrzymujemy w wyniku zewntrznych zapyta do systemu.
Wyrniamy 3 podstawowe typy liczenia :
Dla projektu (ang. development),
Dla aplikacji (ang. application),
Dla aplikacji modyfikowanej (ang. enhancement).
Trzeci z wymienionych typw nie rni si zbytnio od drugiego typu. W procesie
liczenia dla aplikacji modyfikowanej badamy wpyw dokonanych zmian (zliczamy
usunite zmodyfikowane i dodane funkcjonalnoci), korzystajc z bazowej liczby
punktw obliczonej dla aplikacji przed zmianami.
VAF (ang. Value Adjustment Factor) czynnik modyfikujcy warto punktw
funkcyjnych. Ma on za zadanie modyfikacj liczby punktw otrzymanych z bazowego
37
liczenia przez uwzgldnienie wiadomoci o realizowanym projekcie. Uzyskuje si go

przez odpowiedzenie na 14 pyta zwizanych z projektem. Odpowiedzi jest ustalenie
wanoci podanego wspczynnika dla naszego systemu (w skali 05). Kocow warto otrzymujemy za pomoc wzoru :
14
VAF = 0,65 + Ci 100

i =1
gdzie: Ci 14 wspczynnikw majcych wpyw na projekt.

Przedstawiono kroki, ktre naley wykona w celu kalkulacji projektu wedug metody PF, zgodne z podrcznikiem opublikowanymi przez IFPUG [26]:
1. Zaplanuj liczenie. Ten krok obejmuje wybr rodzaju liczenia oraz zdefiniowanie granic liczenia. Obejmuje take bardzo wany krok zwizany z identyfikacj
i przydzieleniem eksperta systemowego.
2. Wytumacz proces liczenia. Jeli korzystamy z pomocy eksperta systemowego,
bdziemy potrzebowali wytumaczy mu, co zamierzamy robi, po co liczymy, co
zamierzamy zrobi z uzyskanymi informacjami i inne podobne sprawy. Nie bdziemy
przecie co chwil przerywa liczenia, po to by tumaczy, e uycie punktw funkcyjnych jest konieczne.
3. Policz VAF. IFPUG poleca zrobi to na kocu, lecz w czasie liczenia eksperci czsto narzekaj, e poszczeglne procesy s zbyt sabo ocenione. Mona
powiedzie, e VAF wemie to pniej pod uwag i poprawi ich ocen. Podzielenie si wiadomoci o zoonoci systemu utrzymuje osoby zwizane z liczeniem
w ciekawoci.
4. Policz typy danych funkcyjnych. Krok ten obejmuje identyfikacj ILF oraz
EIF. Zadajc pytania ekspertowi o gwne kategorie danych oraz studiujc model
danych, uzyskamy podstaw do ustalenia grup danych powizanych logicznie, co
nastpnie uatwi liczenie zoonoci transakcji.
5. Zidentyfikuj transakcje. Obejmuje to identyfikacj EI, EO, EQ. Jest to zwykle
najdusza cz. Identyfikacja transakcji oraz ocenianie ich zoonoci na podstawie
liczby danych, z ktrych korzysta.
6. Wykonaj obliczenia. Obejmuje zsumowanie punktw oraz przemnoenie
otrzymanego wyniku przez VAF
7. Weryfikacja wynikw. Po zakoczeniu procesu liczenia powinno si wyniki
przekaza ekspertowi w celu weryfikacji tego, czy jaka funkcjonalno zawarta
w systemie nie zostaa pominita.
8. Pokazanie wynikw. Jednym z podstawowych powodw niepowodze przygotowywanych metryk projektw jest to, i klient musi zbyt dugo czeka na wyniki
oblicze. W dzie lub dwa po zakoczeniu liczenia wyniki powinny by przedstawione pracownikom biorcym udzia w projekcie oraz sponsorom.
38
Co zrobi z wyznaczonymi punktami funkcyjnymi?
Cel liczenia powinien by ju ustalony przed liczeniem, gdy liczenie dla samego
liczenia nie ma sensu. Oto kilka zastosowa punktw funkcyjnych:
mierzenie podanej produktywnoci zatrudnionych ludzi, poszukanie outsourcera, a nawet oszacowanie niezbdnego zaangaowania czasowego kierownika
projektu, nastpnie ledzenie zmian w czasie,
przewidywanie kosztw i budowanie harmonogramu projektu,
porwnywanie produktywnoci z innymi firmami,
do oceny czy aplikacja nadaje si do ponownego uytku, powinna zosta odrzucona lub przerobiona.
Przykad
Oszacowanie kosztw projektu Systemu do ewidencjonowania polis ubezpieczeniowych w ubezpieczeniach komunikacyjnych dla PZU S.A. POLISA metod
punktw funkcyjnych.
Celem projektu jest ewidencjonowanie polis i obliczanie wysokoci skadek ubezpieczeniowych w ubezpieczeniach komunikacyjnych (OC, NW, AC, Assistance i Zielona
Karta) oraz likwidacji szkd komunikacyjnych.
Funkcjonalno systemu POLISA zostaa skrtowo przedstawiona na rysunku 2.4.
system do obsugi
ubezpiecze komunikacyjnych
w PZU S.A.
sporzdzenie
SW
analiza
projektowanie
Likwidacja szkd
Sporzdzanie protokou zgoszenia szkody

Sporzdzeni protokou szkody
Decyzja o wypacie
Implementacja
wpaty skadek /
wypaty odszkodowa
Wyszukiwanie polisy
Przyjmowanie wpat na polis
Wypata odszkodowa
testowanie
Wyliczenie skadki ubezpieczenia

i wystawienie polisy
Wyst. polisy OC
Wyst. polisy AC
Wyst. polisy NW
Wyst. polisy ZK
Wyst. polisy Assistance
Wysz. wniosku o zaw ubezp.
wdraanie
konserwacja
sporzdzanie wniosku
o zawarcie ubezpieczenia
Wprow. danych klienta

Wprow. danych pojazdu
Wprow. danych koniecznych przy OC
Wprow. danych koniecznych przy AC
Wprow. danych koniecznych przy Assistance
Wprow. danych koniecznych przy NW
Wprow. danych koniecznych przy ZK
Sporzdzanie listy klientw
Sporzdzenie listy pojazdw
Rys. 2.4. WBS dla projektu POLISA (uszczegowiono tylko faz implementacji)
Szacowanie wielkoci projektu POLISA metod punktw funkcyjnych dzielimy na

nastpujce etapy:
39
1. Etap wstpny:
wybieramy typ liczenia liczymy w fazie projektu (ang. Development),
ekspert systemowy projektant.
2. Obliczenie VAF dla projektu.
W tabeli 2.4 przedstawiono 14 czynnikw, ktre szacuje projektant w skali od
1 do 5 jako wspczynniki majce istotne znaczenie dla zoonoci, wielkoci i problemw napotykanych przy budowie oprogramowania.
Tabela 2.4. Cechy aplikacji
Nazwa cechy
Wymiana danych
Charakterystyka cechy aplikacji

Warto Ci
Aplikacja jest oparta na lokalnym przetwarzaniu plikw ale moliwe
2
jest zdalne wprowadzanie danych i wykorzystuje zdaln drukark.
Przetwarzanie
Aplikacja przygotowuje dane dla kocowego uytkownika procesu
1
danych
w innym komponencie systemu, takim jak arkusz kalkulacyjny lub
rozproszonych
system zarzdzania baz danych.
Wymagana
Czas odpowiedzi i wymagania dotyczce przepustowoci s wyma3
wydajno
ganiem kluczowym przez cay czas pracy systemu. Wymagania
systemu
wydajnociowe dotyczce wsppracy mierzonego systemu z innymi
systemami s ograniczone.
Wymagania sprz- W systemie naley uwzgldni bezpieczestwo i zagadnienia doty2
towe systemu
czce czasu.
Czstotliwo
Wymagania ustanowione przez uytkownika dotyczce przetwarza4
transakcji
nia transakcji w aplikacji s na tyle due, e uwzgldniane s ju
w etapie analizy zada.
Wprowadzanie
Wicej ni 30% transakcji polega na interaktywnym wprowadzaniu
5
danych w czasie
danych.
dziaania systemu
Efektywno
Aplikacja uwzgldnia nastpujce czynniki:
4
uatwienia w nawigacji (klawisze funkcyjne, dynamicznie

dla uytkownika
generowane menu, przechodzenie pomidzy elementami interfejsu za pomoc tabulatora),
menu,
pomoc online i dokumentacja,
automatyczne przesuwanie kursora,
przewijanie okna (w poziomie i w pionie),
zdalne drukowanie,
predefiniowane klawisze funkcyjne,
transakcje online.
Modyfikacja
plikw logicznych
w czasie dziaania
systemu
Zoono
przetwarzania
Ponowne wyko-
Moliwa jest aktualizacja wikszoci wewntrznych plikw

logicznych.
Aplikacja nie zawiera zaawansowanych funkcji matematycznych

i logicznych.
Nie ma kodu nadajcego si do ponownego uycia.
0
0
40
rzystanie pakietw
z kodu programu
atwo
instalacji
atwo
administracji
Wielokrotna
lokalizacja
atwo
dostosowania
Nie wyspecyfikowano specjalnych wymaga uytkownika oraz nie

1
wymagany jest program uatwiajcy instalacj.
Nie wyspecyfikowano specjalnych wymaga oprcz standardowych
0
procedur archiwizacji.
Uwzgldniono w projekcie potrzeb instalacji aplikacji w wicej ni
2
jednej lokalizacji. Aplikacja jest zaprojektowana tak, by moga
pracowa w kadej z tych lokalizacji przy zaoeniu podobnej konfiguracji sprztowej i/lub programowej (np. pod kontrol tego samego systemu operacyjnego).
Dane kontrolne dotyczce regu rzdzcych aplikacj s utrzymy2
wane w tabelach. Zmiany mog by wprowadzane online przez
uytkownika, ale skutki s widoczne natychmiast
Suma Ci = 29
14
Ci
100 = 29 / 100 = 0,29
i =1
VAF = 0,65 + 0,29 = 0,94

Identyfikacja wewntrznych plikw logicznych i zewntrznych plikw interfejsowych
W projekcie wyodrbniono nastpujce pliki ILF i EIF:

Wewntrzne pliki logiczne (ILF): Klient, Pojazd, Ubezpieczenie OC, Ubezpieczenie AC, Ubezpieczenie NW, Ubezpieczenie Assistance, Ubezpieczenie Zielona
Karta, Szkoda, Cz.
Zewntrzne pliki interfejsowe (EIF): Wycena
Aby obliczy liczb punktw funkcyjnych dla zewntrznych plikw interfejsowych (EIF) i wewntrznych plikw logicznych (ILF), trzeba zna:
liczb rekordw tworzcych plik (RET),
liczb danych (DET) rozrnialnych dla przyszego uytkownika tworzcych
plik.
Odpowiadajc im zoono (liczba punkw funkcyjnych) odczytujemy z tabeli
2.5 i 2.6.
Tabela 2.5. Liczba punktw funkcyjnych dla ILF
Liczba RET
1 RET
2 do 5 RET
6 lub wicej RET
Liczba DET
119
Niska (7)
Niska (7)
rednia (10)
2050
Niska (7)
rednia (10)
Wysoka (15)
51 lub wicej
rednia (10)
Wysoka (15)
Wysoka (15)
41
Tabela 2.6. Liczba punktw funkcyjnych dla EIF

Liczba RET
Liczba DET
119
Niska (5)
Niska (5)
rednia (7)
1 RET
2 do 5 RET
6 lub wicej RET
2050
Niska (5)
rednia (7)
Wysoka (10)
51 lub wicej
rednia (7)
Wysoka (10)
Wysoka (10)
Przykadowy wewntrzny plik logiczny ILF: Klient

liczba RET: 3 (dane osobowe, adres, inne dane),
liczba DET: 23 (PESEL, imi, nazwisko, ulica itd.),
zoono: rednia(10).
Plik interfejsowy wycena
liczba RET: 1 (wycena),
liczba DET: 2 (warto, marka),
zoono: niska (5).
Cakowita liczba punktw funkcyjnych dla danych zapisanych w plikach ILF
i EIF:
Tabela 2.7
Wewntrzny
plik logiczny ILF
Klient
24
rednia(10)
Punkty funkcyjne
(UFP)
10
Pojazd
21
rednia(10)
10
Ubezpieczenie NW
Maa(7)
Ubezpieczenia AC
55
Wysoka(15)
15
Ubezpieczenie OC
12
Maa(7)
Zielona Karta
DT
RET
Zoono
15
Maa(7)
Szkoda
ponad 100
15
Wysoka(15)
15
Czci
Maa(7)
Wycena
Maa (5)
Suma punktw funkcyjnych dla plikw wynosi 83
Przystpujemy do identyfikacja transakcji. Aby obliczy FP dla zewntrznych

wej (EI), trzeba zna:
liczb plikw zwizanych z transakcj (FTR),
liczb danych rozrnialnych dla przyszego uytkownika wykorzystywanych
przez transakcj (DET).
Odpowiadajc im zoono wyznaczon w PF odczytujemy z tabeli 2.8.
42
Tabela 2.8
Liczba plikw zwizanych (FTR)
Mniej ni 2
2
Wicej ni 2
Liczba DET
14
Niska (3)
Niska (3)
rednia (4)
515
Niska (3)
rednia (4)
Wysoka (6)
wicej ni 15
rednia (4)
Wysoka (6)
Wysoka (6)
Aby obliczy PF dla zewntrznych wyj (EO), trzeba zna:

liczb danych rozrnialnych dla przyszego uytkownika (DET) wykorzystywanych przez transakcj.
Odpowiadajc im zoono w PF odczytujemy z tabeli 2.9.
Tabela 2.9
9
Mniej ni 2
2 lub 3
Wicej ni 3
Liczba DET
15
Niska (4)
Niska (4)
rednia (5)
619
Niska (4)
rednia (5)
Wysoka (7)
Wicej ni 19
rednia (5)
Wysoka (7)
Wysoka (7)
Aby obliczy PF dla zewntrznych zapyta (EQ), trzeba zna:

liczb danych rozrnialnych dla przyszego uytkownika (DET) wykorzystywanych przez transakcj.
Odpowiadajc im zoono w PF odczytujemy z tabeli 2.10.
Tabela 2.10
Mniej ni 2
2 lub 3
Wicej ni 3
Liczba DET
15
Niska (3)
Niska (3)
rednia (4)
619
Niska (3)
rednia (4)
Wysoka (6)
Wicej ni 19
rednia (4)
Wysoka (6)
Wysoka (6)
Przykadowy modu sporzdzanie wniosku o zawarcie ubezpieczenia tabela

2.11.
43
Tabela 2.11
Modu
Sporzdzanie wniosku o zawarcie ubezpieczenia

FTR DET Zoono
UFP
Typ
Wejcia EI
Wprowadzenie danych klienta
1
23
rednia
4
Danych
Wprowadzenie danych pojazdu
2
22
Wysoka
6
Wprowadzenie danych koniecznych
3
14
Wysoka
6
przy OC
3
48
Wysoka
6
przy AC
3
4
rednia
4
przy Assistance
3
4
rednia
4
przy NW
3
4
rednia
4
przy ZK
Zapytania EQ Sporzdzanie listy klientw
1
5
Niska
3
Sporzdzanie listy pojazdw
1
2
Niska
3
Zbir danych
Klient, Pojazd, Ubezpieczenie NW, Ubezpieczenia AC, Ubezpieczenie OC,
Zielona Karta
Obliczenie sumy nieskorelowanych punktw funkcyjnych (UPF). Sumujemy wartoci UPF dla wszystkich transakcji i zbiorw danych (tabela 2.12).
Tabela 2.12
Rodzaj komponentu
Zoono komponentw
rednia
Wejcie EI
4 x 4 = 16
Wyjcie EO
0x5=0
Zapytania EQ
1x4=4
Wewntrzne pliki logiczne ILF
2 x 10 = 20
Zewnetrzne pliki interfejsw
0x7=0
EIF
Cakowita liczba nieskorygowanych punktw funkcyjnych
Niska
1x 3 = 3
0x4=0
3x3=9
4 x 7 = 28
1x5=5
Wyznaczenie PF
Na podstawie: UPF
obliczonej liczby = 193,
wartoci VAF = 0,94.
otrzymujemy:
FP = UPF VAF,
PF = 193 0,94 = 181.
Wysoka
6 x 6 = 36
6 x 7 = 42
0x6=0
2 x 15 = 30
0 x 10 = 0
Razem
55
42
13
78
5
193
44
Szacowanie zoonoci implementacji projektu POLISA

Szacowanie linii kodu w zalenoci od stosowanego jzyka programowania [1, 26]:
Liczba linii kodu odpowiadajca 1 PF:
Dla jzyka ADA 95
: 49,
Dla jzyka C++
: 53,
Dla jzyka Visual C++ : 34.
Szacowanie liczby linii kodu dla omawianego projektu POLISA:
Dla jzyka ADA 95
: 49 181 = 8869,
Dla jzyka C++
: 53 181 = 9593,
Dla jzyka Visual C++ : 34 181 = 6154.
Szacowanie czasu potrzebnego do wytworzenia aplikacji w osobomiesicach:
VC++ ma poziom jzyka 9,5.

Dla jzyka o takim poziomie jedna osoba jest w stanie przez miesic oprogramowa od 16 do 23 punktw funkcyjnych.
Minimalny czas potrzeby do implementacji projektu
181/23 = 7,9 miesica
Maksymalny czas potrzeby do implementacji projektu
181/16 = 11,3 miesica
Implementacja projekt POLISA bdzie realizowany przez jedn osob przez 811
miesicy.
140
Osobomiesice
Osobomiesice
120
100
80
60
40
20
0
50
100
150
200
250
300
350
400
450
500
550
600
650
700
750
800
PF
LLiczba
czba PF
Rys. 2.5. Wykres zalenoci nakadu pracy od liczby PF
850
900
950
1000
1050
45
Podane szacowanie nie uwzgldnia innych czynnoci technologicznych zwizanych z wytwarzaniem oprogramowania, jak studium wymaga, projektowanie, analizy, testowania wdroenia itd.
Z wykresu przedstawionego na rys. 2.5 wida, e wraz ze wzrostem wielkoci projektu liczonego liczb PF, wykonanie kolejnego przyrostu w projekcie (modyfikacje, rozszerzenie funkcjonalnoci) o np. 100 PF bdzie wymagao coraz wikszej pracochonnoci,
czyli zmiany w duych projektach mog by wielokrotnie kosztowniejsze od zmian w
maym projekcie, cho sam produkt liczony w PF jest podobny.
2.10. Harmonogram
Harmonogram to okrelony w czasie porzdek realizacji zada w projekcie.
Gwnymi skadowymi harmonogramu s zadania, zalenoci midzy nimi, czas
trwania oraz alokacja zasobw do poszczeglnych zada.
Jednym z trzech podstawowych parametrw, ktry definiuje i jednoczenie ogranicza projekt jest czas, ktremu w planowaniu projektu i jego monitorowaniu powica si szczegln uwag. Najczciej mamy do czynienia z sytuacj dysponowania
okrelonymi (najczciej ograniczonymi) zasobami ludzkimi lub mamy narzucony
czas na wykonanie projektu. Charakter projektu i technologia jego realizacji wpywa
na zwizki oraz kolejno realizacji zada.
Proces tworzenia harmonogramu
Harmonogram jest to okrelony w czasie porzdek realizacji zada w projekcie.

Gwnymi skadowymi harmonogramu s zadania, zalenoci midzy nimi, czas
trwania oraz alokacja zasobw do poszczeglnych zada. Czas trwania realizacji zadania obliczamy wedug nastpujcego wzoru:
czas trwania zadania = wymagana praca/nakad pracy zasobu
gdzie:
czas trwania zadania jest rzeczywist wielkoci czasu, ktry jest planowany na
wykonanie zadania (np. 5 dni),
wymagana praca jest wielkoci mierzon w jednostkach czasochonnoci niezbdnej do wykonania zadania (np. 4 osobogodziny),
nakad pracy zasobu jest wielkoci wyraon w jednostkach pracochonnoci
z uwzgldnieniem tylko tego czasu, w ktrym zasb pracuje na rzecz danego zadania jest alokowany.
Przykad
Trzej programici pracuj nad zadaniem przez dwa dni przy nakadzie pracy
46
8 godzin dziennie, praca kadego zasobu wynosi 16 godzin: (2 dni 8 godzin).

Cakowity nakad pracy zasobw wynosi 24 godziny dziennie: (3 programistw
8 godzin).
Cakowita praca w zadaniu wynosi 48 godzin: (2 dni 8 godzin 3 programistw).
Czas trwania zadania wynosi 2 dni: 48 godzin / (3 programistw 8 godzin).
Zrozumienie powyszego wzoru jest wane do oszacowania, w jaki sposb zmiany
dokonywane w zadaniach wpywaj na harmonogram projektu.
Prace nad harmonogramem zwizane s z wykonaniem nastpujcych krokw:
tworzenie hierarchicznej struktury zada WBS,
specyfikacja zada na podstawie WBS,
szeregowanie zada,
tworzenie powiza i zalenoci midzy zadaniami,
okrelenie wymaganych zasobw,
szacowanie pracochonnoci,
okrelenie czasu trwania zadania,
stworzenie wstpnego harmonogramu projektu,
stworzenie harmonogramu projektu,
weryfikacja i korekta harmonogramu.
Patrz: [2, 3, 5, 10, 16, 51].
Pojcia i technika tworzenia harmonogramu
Stosuje si najczciej dwa podejcia co do przyjmowanego czasu trwania zadania:

zalene od posiadanych zasobw (ang. resource-driven scheduling),
o ustalonym czasie minimalnym, w ktrym zadanie moe by wykonane.
Wspomniana technologia realizacji i charakter projektu bezporednio wpywa na
zalenoci midzy zadaniami, ktre wyspecyfikowano, aby zrealizowa projekt.
Opis powiza midzy zadaniami
Graficzne rozmieszczenie zada na osi czasu oraz ich wzajemne powizania przedstawia s na og w sposb, jak na rys. 2.6.
Koniec Start (ang. Finish-to-Start FS)
zadanie B nie moe rozpocz si
przed ukoczeniem zadania A,
Start Start (ang. Start-to-Start SS)
zadanie B nie moe rozpocz si
przed rozpoczciem zadania A,
Koniec Koniec (ang. Finish-to-Finish FF) zadanie B nie moe zakoczy si
dopki nie zakoczy si zadanie A,
Start Koniec (ang. Start-to-Finish SF)
zadanie B nie moe zakoczy si
dopki nie rozpocznie si zadanie A.
47
A
SS:
FS:
B
FF:
SF:
Rys. 2.6. Typy powiza midzy zadaniami w projekcie
Standardowo przyjmuje si, e zadania rozpoczynaj si, gdy tylko jest to moliwe.
Zadania, ktrych liczba w projekcie zwykle jest znaczna i tworz harmonogram,
maj takie atrybuty, jak:
sekwencja,
powizanie,
nakadanie si,
ograniczenia (czasowe), data startu i zakoczenia.
Z1
Z2
Z3
Z4
Rys. 2.7. Przykad zada Z1, Z2, Z3, Z4, z ktrych skada si projekt
Zadania Z2 i Z3 s realizowane sekwencyjnie po wykonaniu zadania Z1, a zadanie

Z3 po zrealizowaniu zadania Z2 i Z4. Z takiego graficznego przedstawienia zada jak
na rys. 2.7 nic nie moemy wnioskowa o ograniczeniach czasowych ani o oczekiwanych zasobach przewidzianych do ich realizacji.
48
2.11. Sieciowe diagramy zalenoci

Diagram PERT (ang. Program Evaluation and Review Technique PERT)
W programie MS Project 2000 moemy przedstawi zadania i ich relacje (poprzednik, nastpnik oraz ktre zadania wykonuj si rwnolegle) (rys. 2.8).
3
Z1
Z2
Z3
Z4
Z5
Z6
Z7
Z5
Z4
Z1
Z3
Z2
Z6
Z7
Rys. 2.8. Graficzne przedstawienie zada oraz ich dekompozycja w sie powiza oraz czas realizacji
Rys. 2.9. Widok zada oraz ich powizania z wyrnionymi kamieniami milowymi sieci PERT
za pomoc MS Projekt 2000
Rys. 2.10. Fragment projektu z opisami atrybutw sieci PERT za pomoc MS Projekt 2000
Rys. 2.11. Przedstawienie zada oraz przypisanie zasobw do zada na schemacie Gantta
49
50
Aby zobaczy nazwy zada, daty ich rozpoczcia i zakoczenia, czas trwania oraz
jakimi zasobami planujemy wykona zadania, moemy to zobrazowa za pomoc
diagramu PERT oraz wykresu Gantta (rys. 2.10 i 2.11).
Przypisanie zasobw do zada polega na oszacowaniu:
Jakie zasoby s potrzebne do realizacji zadania?
Ile jednostek danego zasobu naley przydzieli do zadania?
W jakim czasie od rozpoczcia zadania zasb bdzie potrzebny i do kiedy?
Zasoby = ludzie
Odmiana diagramu, w ktrym kade zadanie jest opisane przez punkt startu
i punkt ukoczenia, jest poczona lini. Innymi liniami zaznaczono zalenoci midzy zadaniami.
cieka krytyczna (ang. Critical Path Metod CPM) bazuje na PERT i czsto nazywane jest PERT/CPM. CPM obejmuje cig zada w projekcie, od ktrych zaley zakoczenie projektu w terminie. Zadania te wymagaj szczeglnej uwagi PM, na og
czstszego monitorowania, niekiedy specjalnego raportowania przez zesp, ktry realizuje dane zadanie krytyczne. Dla tych zada w zarzdzaniu ryzykiem powinno uwzgldnia
si tzw. akcje zapobiegawcze w przypadku zagroenia terminu realizacji .
2.12. Inicjowanie projektu

Uruchomienie projektu najczciej nastpuje w sposb formalny i wedug przytoczonej listy czynnoci, ktre towarzysz temu zdarzeniu. Jednak biorc pod uwag, e
nie tylko projekt jest niepowtarzalny, ale rwnie okolicznoci i warunki jego uruchomienia, to bywaj sytuacje, e prace nad projektem i jego poszczeglnymi fazami
wyprzedzaj oficjalne uruchomienie projektu. Dotyczy to szczeglnie sytuacji, kiedy
firma uczestniczy w przetargu publicznym i chce zaoferowa realizacj projektu. Aby
mc wyceni warto projektu trzeba oszacowa potrzebne zasoby, czas, koszty stae,
koszty zmienne itp. Naley podj wtedy takie dziaania, ktre w przypadku wygranej
wyprzedzayby niektre dziaania, aby nie podejmowa ich powtrnie ju w trakcie
prac nad projektem. Oczywicie inna jest ich skala i dokadno. Innym podejciem
jest szacowanie projektu dla wygranej i tu decyduj gwnie czynniki strategii firmy
i jej polityki [23, 24]. Dobr praktyk jest zatem:
uzyskanie formalnej aprobaty sponsora,
przydzielenie budetu z podziaem na poszczeglne fundusze,
zdefiniowanie struktury projektu (kierownik projektu, odpowiedzialny zwierzchnik, komitet kierujcy, reprezentacja uytkownika, struktura zespou, zaoenia,
odpowiedzialno osb i zespow),
51
ustanowienie struktury (wyznaczenie kierownika i kluczowych czonkw zespou, zasad raportowania, monitorowania i powiza, zasad zarzdzania, komunikacji),
opublikowanie celw i planu,
opracowanie planw dla wczesnych etapw projektu,
zapewnienie zasobw, ustanowienie administracji projektu,
zebranie i odprawa zespou przewidzianego do realizacji projektu.
Efektywna organizacja
Podobne projekty mog by rnie realizowane w zalenoci od otoczenia zewntrznego oraz modelu organizacji firmy wykonujcej projekt (patrz rozdz. 4 oraz
[11, 17, 20, 24, 28, 59]). Istnieje jednak przekonanie, e efektywna organizacja prac
nad projektem powinna charakteryzowa si nastpujcymi kryteriami:
pojedynczy kierownik (odpowiedzialny, rozliczalny, z autorytetem, dowiadczony i uzdolniony),
rodki zarzdzania dla wsparcia kierownika projektu (moliwo skutecznego
oddziaywania na jako i terminowo prac przez moliwo nagradzania i karania,
a take z wystpowaniem z wnioskami do waciwych osb funkcyjnych patrz rozdzia 4.4 oraz [17, 18],
jasno okrelone cele i odpowiednie cieki raportowania,
prosta struktura zespou,
krtkie cieki komunikowania,
samowystarczalne zespoy,
zrwnowaone poczenie umiejtnoci i dowiadczenia,
dedykowane zasoby,
jasno zdefiniowane zadania i zakres odpowiedzialnoci,
odpowiedni czas dla komunikowania si i rozwoju zespou, szkolenia, podnoszenie motywacji i kompetencji (patrz rozdz. 8.4),
kontrolowanie delegowania uprawnie (patrz rozdz. 8.7),
zasada najzdolniejszy wykonuje najtrudniejsze zadania,
jedna osoba wykonuje jedno zadanie na raz,
zdefiniowanie zada i zakresu odpowiedzialnoci dla zarzdzajcych jakoci [8,
37].
3. ledzenie oraz zarzdzanie zmianami projektu

ledzenie projektu to nie ledzenie ludzi,
lecz zada i produktw, ktre powstaj w czasie projektu.
KF
3.1. ledzenie projektu monitorowanie

Sprawdzenie, czy projekt znajduje si pod kontrol, czy te wymkn si spod kontroli oraz czy w zwizku z tym trzeba zmieni plan, specyfikacj produktw, opis
i inne wymagania uytkownika to czynnoci permanentne w trakcie trwania projektu. Oglny model obiegu informacji zwizanej ze ledzeniem (kontrol) projektu
przedstawiony jest na rys 3.1. Na wyjciu kontrolujemy wyspecyfikowane parametry
projektu, sprzenie zwrotne jest kanaem zgaszania odstp od zaoonych parametrw realizacji projektu oraz postulowanych zmian w projekcie.
Sprzenie zwrotne
Wejcie
PROJEKT
Wyjcie
Rys. 3.1. Model obiegu informacji zwizanej ze ledzeniem (kontrol) projektu
Cel raportowania projektu

Zapewnienie bezpiecznego realizowania projektu przy fluktuacji w zespoach projektowych.
Gwne aspekty ledzenia projektu:
czas,
jako,
53
funkcjonalno,
koszty.
Etapy ledzenia projektu:
1. Wstpne rozpoznanie:
Porwnanie stanu z opisem projektu (ang. Feasibility Study Report, Business Case) w celu sprawdzenia, czy nastpiy (lub te gro) jakie istotne zmiany.
2. Drugie rozpoznanie:
Analiza stanu zaawansowanych zada, porwnanie liczby zada wykonanych
w stosunku do planowanych do zakoczenia w danym czasie.
3. Trzecie rozpoznanie:
Zebranie danych potrzebnych do finansowania projektu i tworzenia historii projektu. Dane takie pochodz od codziennych sprawozda prowadzonych przez czonkw
zespou. Sprawozdanie powinno zawiera czas spdzony danego dnia na rzecz projektu oraz zakres wykonanych czynnoci (nakad pracy).
Projekt powinien by ledzony okresowo: raz na tydzie lub raz na dwa tygodnie.
Dla projektw o duym stopniu ryzyka ledzenie naley wykonywa czciej.
Jeli wida, e dane zadanie moe nie by wykonane na czas, naley wczeniej
powiadomi o tym kierownika projektu.
Szczeglnie jest to istotne dla zada znajdujcych si na ciece krytycznej. Dla
innych zada jest to istotne wtedy, gdy moe zosta przekroczony dopuszczalny
czas trwania zadania.
ledzenie projektu dotyczy projektu, a nie ludzi! Moe by cakiem uzasadnione,
i jednego dnia jaka osoba nie zrobia nic na rzecz projektu.
Priorytety ledzenia projektu:
zadania cieki krytycznej,
zadania nie majce moliwoci manewru czasowego,
zadania o niewielkiej moliwoci manewru czasowego,
zadania o wysokim ryzyku,
zadania wykorzystujce krytyczne zasoby (ludzi, sprzt).
3.2. Zarzdzanie jakoci w projekcie

Jest wiele definicji jakoci oprogramowania: zgodno z wymaganiami, przydatno uytkowa. Normy ISO 9000 przyjy nastpujc definicj:
Jako og cech i waciwoci wyrobu lub usug decydujcych o zdolnoci wyrobu lub usugi do zaspokojenia stwierdzonych lub przewidywanych potrzeb.
Definicja jakoci decyduje o caoci procesu tworzenia systemu. Podstawowym
zadaniem kierownika projektu i innych osb odpowiedzialnych za projekt jest uzyskanie porozumienia co do wsplnej wizji jakoci. Bardzo powszechne jest mylenie
54
jakoci z funkcjonalnoci produktu. Lider procesu wdroeniowego musi troszczy si

nie tylko o to, by oprogramowanie miao wszystkie funkcje, ktrych si oczekuje, ale
gwnie o to, aby te funkcje, ktre bd dostpne, byy niezawodne, efektywne, bezpieczne itd.
Doskonalenie jakoci produktu czsto ogranicza si tylko do polepszania technik
i narzdzi testowania. To tradycyjne podejcie, bazujce na testowaniu jakoci zamiast
jej wytwarzaniu i jest przyczyn niepowodze wielu projektw.
Kryteria jakoci
Charakterystyka jakoci to zesp cech opisujcych jako produktu lub na podstawie ktrych jego jako jest oceniana.
Jednym z zestaww minimalnego zestawu kryteriw jakoci opisujcych oprogramowanie jest model McCalla przedstawiony w tabeli 3.1.
Tabela 3.1
Wygodny
Bezpieczestwo
Wydajno
Poprawno
Niezawodno
Pielgnowalno
Elastyczno
Testowalno
Przenono
Uniwersalno
Otwarto
Dziaanie programu
Odnosi si do efektywnoci uytkowania programu i wygodnego interfejsu
Odnosi si do bezpieczestwa uytkowania programu pod ktem kontroli uprawnie do korzystania z niego oraz odpornoci na skutki nieprawidowej obsugi
Odnosi si do oceny wydajnoci systemu i sposobw zarzdzania zasobami
Odnosi si do stopnia realizacji wymaga, kompletnoci i logicznoci wdroenia,
zgodnoci dziaania programu ze specyfikacj
Odnosi si do stopnia odpornoci programu na bdy, jego poprawnoci formalnej
oraz sposobw reakcji na bdne sytuacje
Przystosowanie do modyfikacji
Ocenia stopie przystosowania programu do dziaa zmierzajcych do jego poprawiania, modyfikacji, rozszerzania, adaptowania itp., wedug nowych wymaga
lub raportw o bdach
Ocenia moliwoci rozbudowania programu o nowe funkcje oraz uniwersalno
wdroonych rozwiza
Ocenia przystosowanie oprogramowania do procesu testowania, tzn. jego struktur, dokumentacj, specyfikacj moduw itp., a take przewidziane mechanizmy
wspomagajce ten proces
Mobilno oprogramowania
Ocenia oprogramowanie pod ktem zdolnoci do atwego uruchomienia na innych
maszynach lub systemach programowania ni rodowisko projektowe
Odnosi si do moliwoci wykorzystania istniejcego oprogramowania lub jego
fragmentw do konstrukcji innych programw lub systemw komputerowych
Ocenia stopie przystosowania programu do wsppracy lub wymiany informacji
z innymi systemami komputerowymi
55
Zapewnienie jakoci. Wedug definicji ISO 9000 zapewnienie jakoci s to

wszystkie zaplanowane i systematyczne dziaania, ktre s niezbdne do uzyskania
i utrzymania odpowiedniego stopnia wiarygodnoci, e wyrb speni ustalone wymagania jakociowe.
Planowanie jakoci jest to zaplanowanie dziaa zmierzajcych do zapewnienia
jakoci. W planie powinny by wzite pod uwag nastpujce kategorie dziaa:
przegldy kontraktw,
sterowanie analiz wymaga, projektowaniem, wdroeniem,
zaopatrzenie i kontrola kooperantw,
kontrola i badanie oprogramowania w toku produkcji,
obsuga produktw projektowych niespeniajcych wymaga,
instalacje, wdroenia,
serwis,
szkolenie personelu
wsparcie organizacyjne projektu,
audyty wewntrzne i przegldy systemu jakoci inicjowane przez kierownictwo
projektu,
inne dziaania.
Plan jakoci powinien zawiera:
opis sposobu realizacji polityki jakoci firmy,
opis systemu zapewnienia jakoci jego struktury, podziau, odpowiedzialnoci,
procedur i potrzebnych zasobw,
zestaw przyjtych kryteriw jakoci i metryk, sucych do ich monitorowania
i oceny,
przyjte standardy i normy,
plan dziaa weryfikacyjnych i walidacyjnych w trakcie projektu,
plan audytw,
ustalenie kryteriw jakociowych dla wszystkich produktw,
plan i procedur obsugi sytuacji wyjtkowych,
opis warunkw wsppracy z klientem, kooperantami, gwarantujc wysok jako.
Nadzorowanie jakoci. Pozytywne, czy negatywne wyniki kontroli jakoci s
rdem decyzji projektowych, ktre zmierzaj do:
dokumentowania dziaa,
podjcia dziaa korekcyjnych,
ledzenia ich realizacji,
weryfikacji ich skutecznoci.
Doskonalenie jakoci. Do podstawowych narzdzi doskonalenia jakoci nale:
inynieria wymaga,
metoda projektowania,
weryfikacja i walidacja,
56
przegldy techniczne oprogramowania,

testowanie oprogramowania,
dowodzenie poprawnoci,
symulacje i prototypowanie,
ledzenie wymaga,
inne narzdzia.
Do metod sformalizowanych naley rwnie tzw. formalny przegld techniczny
(ang. Formal Technical Raport FTR): metoda ustrukturalizowanego dziaania, podczas ktrego osoba lub grupa osb poprawia jako oryginalnego produktu pewnej
pracy, jak rwnie jako samej metody [16, 19].
FTR zapewnia:
autorowi dane o usterkach,
partnerom i konstruktorom informacje o produkcie,
testujcym informacje o prawdopodobnych bdach,
kierownictwu informacj o stanie produktu,
grupie nadzorowania jakoci informacj o stanie procesu.
Aby uczyni punkt rozwaa o zarzdzaniu jakoci mniej abstrakcyjnym i nie
usysze komentarza po przeczytaniu Kto by to wszystko mia robi, maa uwaga dotyczca tego kiedy i czy wymienione procedury wprowadza. Trudno o jednoznaczn
odpowiedz. Jedno jest chyba pewne, nie warto i chyba si to nie uda, aby wszystko
wprowadza przy nowym projekcie, jeli dotychczas zesporganizacja ich nie stosowaa. Formalne procesy s dobrym wynalazkiem, jeli si je stosuje ze zrozumieniem, jeli je stosowano wczeniej oraz najlepiej, jeli jest ich aprobata. Ale projekt
jest prb zrobienia czego, czego jeszcze nigdy nie zrobiono, zatem sposb jego realizacji te moe by nowy, kiedy mona i trzeba zacz wprowadza procedury
zarzdzania jakoci.
Nadzorowanie funkcjonalnoci dotyczy realizacji celw, jakie przyjto dla
projektu i byy przedmiotem specyfikacji funkcji, ktre maj by realizowane
przez system informatyczny w zakresie interfejsu, wydajnoci, dostpu itd. W wyniku nadzorowania projektu moemy dostrzec uchybienia, ktrych rdo ma pochodzenie:
wewntrzne zmiany wywodzce si z fazy planowania projektu, wynikajce
z niezrozumienia zaoe, ze zmian w oszacowaniu nakadu pracy, zmian w skadzie zespou, z przyczyn technicznych i inne zmiany, ktrych nie mona byo
przewidzie wczeniej;
zewntrzne pochodzce od klienta lub kierownictwa, wynikajce z nowych
idei, przeocze, wymaga innych projektw i inne zmiany, ktre nie s zwizane z pocztkow specyfikacj projektu.
Nadzorowanie kosztw. ledzenie i nadzorowanie czasu oraz kosztw projektu
57
przedstawiono w rozdziale 3.4.

Kontrolowanie zmian
1. danie zmiany: musi by dokonane na pimie. Adresowane do kierownika projektu. Musi zawiera: nazwisko czonka zespou dajcego zmiany, dat, opis problemu, opis proponowanej zmiany i jej uzasadnienie.
2. Ocena postulowanej zmiany:
Czy zmiana jest rzeczywicie uzasadniona? Jeli tak, to czy musi by wykonana
teraz, czy mona j odoy na pniej?
Czy w istotny sposb zmienia opis projektu?
Na jakie zadania (zakoczone lub w toku) wpywa ta zmiana?
Jaki jest nakad pracy potrzeby na jej zrealizowanie, koszty i korzyci?
Czy w konsekwencji jej wprowadzenia naley ustali nowy harmonogram projektu?
Czy wymaga ona nowych zasobw nie przewidzianych w planie projektu?
Czy zmiana zwiksza w istotny sposb zoono i ryzyko projektu?
Czym ryzykujemy, jeli zrealizujemy zmian (lub: jeli nie)?
Jakie s priorytety przypisane do zmiany?
Jakie s skutki zmiany na innych procesach ?
Jakie bd skutki technicznej stabilnoci produktu?
3. Decyzja:
Jeli kierownik projektu nie ma wtpliwoci co do koniecznoci wprowadzenia
zmiany i jeli zmiana:
moe by dokonana w danym momencie realizacji projektu,
nie wymaga dodatkowych rodkw,
nie zmienia ryzyka i zoonoci projektu,
nie zmienia opisu projektu,
nie przedua realizacji projektu.
Kierownik projektu akceptuje zmian. W przeciwnym razie naley odwoa si do
kierownictwa organizacji, komitetu sterujcego lub innej struktury kompetentnej do
podejmowania decyzji. Decyzja powinna by na pimie zakomunikowana zgaszajcemu zmian i traktowana jako ostateczna [3, 7, 16, 36].
Sprawozdawczo raportowanie
Szablony i zasady oraz obieg dokumentw sprawozdawczych jest zadaniem PM
i to naley ustali na samym pocztku realizacji projektu, poniewa:
sprawozdawczo to wicej ni wielkie raporty na temat maych sukcesw,
problemy naley sygnalizowa wczenie,
zgoszenie problemu musi pociga za sob odpowiedni reakcj,
sygnalizowanie problemw jest elementem kultury technologicznej zespo-
58
u/organizacji.
Tabela 3.2. Klasy i metody przegldw
Metoda
Walkthroughs
Typowe cele
Minimalny nakad
wiczenie dla konstruktora
Szybki obieg
Przegldy techniczne
(ang. technicreviews)
Identyfikacja wymaga
Wychwycenie niespjnoci
wiczenie
Efektywne wykrycie i usunicie
wszystkich defektw
Inspekcje
(ang. inspections)
Typowe cechy
Brak przygotowa
Nieformalne
Nie ma pomiarw
Nie jest FTR!
Proces sformalizowany
Prezentacje autorskie
Szeroki zakres dyskusji
Proces sformalizowany
Listy kontrole
Pomiary
Faza weryfikacji
Raportowanie
Sposb raportowania postpu projektu zaley od organizacji. Zakres informacji
zawartych w raporcie dla kierownictwa organizacji obejmuje:
stan projektu: planowo czy nie?
jeli nie, jakie s przyczyny zmian?
jakie dodatkowe akcje podj zesp w celu przezwycienia problemw?
czy s jakie alternatywy w dalszej realizacji projektu?
jak moe pomc kierownictwo organizacji?
Raport powinien zawiera take wymagan dokumentacj projektu, uwzgldniajc aspekty finansowe (fundusze ju wydatkowe a fundusze planowane, wystawione
faktury dla klientw itd.).
Akcje naprawcze dziaania, ktre zapobiegaj negatywnym nastpstwom niektrych przeocze lub bdw popenionych we wczeniejszych fazach projektu.
Nale do nich:
Detekcja potrzeby akcji naprawczej.
Wybr waciwej akcji naprawczej.
Wczesne podjcia akcji naprawczej.
Nadzorowanie pracy i pisanie raportw na temat jej postpw to za mao! Meneder projektu musi wnosi now warto przez wczesne identyfikowanie problemu
i podejmowanie akcji naprawczych.
59
3.3. rda i rodzaje zmian

Errare humanum est.
Seneka
Zarzdzanie zmianami, nazywane rwnie zarzdzaniem konfiguracj projektu, obejmuje zasady i techniki zmierzajce do identyfikacji, ledzenia, oceny, sterowania i autoryzacji
zmian we wszelkiej informacji projektowej, ktra ma by udostpniona rnym osobom
(zespoom), zwizanym z projektem. Gwnym celem zarzdzania konfiguracj jest kontrolowane wprowadzenie do projektu zmian dotyczcych dokumentacji, kodu programu
i innych produktw faz projektowych. Sposb ich dokonania nie moe mie negatywnego
wpywu na zakadane parametry projektu oraz integralno i jako wytwarzanego systemu
informatycznego. Pojcie zarzdzanie konfiguracj jest tumaczeniem angielskiego terminu
Configuration Management. W odniesieniu do systemw informatycznych sowo konfiguracja rozumiemy jako zmienny w czasie zestaw wszelkich produktw projektu i innych
informacji, ktre s istotne do sprawnej jego realizacji.
W przypadku zarzdzania konfiguracj koncentrujemy si na tych aspektach systemu
informatycznego, ktre bezporednio lub porednio dotycz gromadzenia informacji,
przechowywania, aktualizowania i dostarczania odbiorcom informacji w taki sposb, aby
zachowa integralno informacji, jej dostpno, poprawno, wiarygodno i aktualno.
Elementy konfiguracji. Nale do nich przede wszystkim:
Dokumentacja produktw wszystkie informacje ujte w formie dokumentacji,
ktre s podstaw do projektowania.
Dokumentacja projektowa dokumenty konstytuujce projekt i opisujce jego
histori oraz stan biecy.
Standardy, procedury, instrukcje wszelkie ujte w formie normatywnej opisy
sposobw realizacji procesw projektowych.
Kod programu.
Zwykle zaleca si stworzenie zespou ds. zarzdzania konfiguracj projektu, ktry
najczciej jest rozproszony po caym projekcie.
Na kadym poziomie znajduje si osoba, ktra ma prawo zatwierdza zmiany
w projekcie, stosownie do swoich kompetencji i zakresu prac, za ktre odpowiada.
Osoba ta ma obowizek dopilnowania, aby wszelkie zmiany byy odpowiednio raportowane i archiwizowane, a te, ktre zostay przyjte do realizacji, take monitorowane,
a do momentu ich wprowadzenia.
Zgoszenia niezgodnoci:
Bdy w wymaganiach, wynikajce ze zego rozpoznania wymaga.
60
Bdy w projekcie.
Naruszenie standardw.
Zgoszenie zmian. S obsugiwane podobnie jak niezgodnoci, lecz ich powstanie
ma inn natur. Mona je podzieli na trzy kategorie:
Wymagania nie realizowalne np. z przyczyn zbyt maych zasobw bd bdw
w implementacji innych wymaga.
Rozszerzenia zwykle dotycz nowych wymaga, powstajcych jako wynik
przemyle i analizy twrcw i odbiorcw przyszego systemu.
Usprawnienia. Kade zgoszenie powinno by zapisane, a jego status odpowiednio ledzony.
Przed podjciem decyzji o wprowadzeniu zmian do projektu naley przeanalizowa:
rozmiar i zakres zmian,
zoono,
ograniczenia czasowe,
wpyw na biecy stan projektu,
zasoby wymagane do realizacji,
koszt,
ryzyko niepowodzenia,
polityk firmy, produktu, projektu,
wymagania udziaowcw,
alternatywne sposoby wprowadzenia zmian.
Jednym z postulatw dobrego zarzdzania konfiguracj jest zasada aktualnoci
danych projektowych. Oznacza ona, e w danej chwili mona otrzyma peny obraz zmian w projekcie, dotrze do rda ich powstania i przeledzi losy ich realizacji.
3.4. Proces zarzdzania zmianami

Zarzdzanie zmianami (konfiguracj) to zasady i techniki zmierzajce do identyfikacji, ledzenia, oceny, sterowania i autoryzacji wprowadzonych do projektu zmian
we wszelkiej informacji projektowej, ktra ma by udostpniona rnym osobom,
zwizanym z realizacj projektu. Wprowadzenie zarzdzania zmianami ma na celu
zachowanie spjnoci i integralnoci projektu oraz zabezpieczenie osignicia zakadanej jakoci [32, 44, 45].
Zadania zwizane z zarzdzaniem zmianami w wikszych projektach powierza si
najczciej zespoowi ds. zarzdzania zmianami, ktry moe by rozproszony po caym projekcie.
Zmiana propozycja modyfikacji czego, co zostao ju wczeniej uzgodnione
61
moe dotyczy zarwno projektu, jak i sposobu jego zarzdzania.

Zarzdzanie zmianami proces, ktry umoliwia wprowadzenie wymaganych
i uzgodnionych zmian przy minimalnym wpywie na projekt.
Zmiany w projekcie:
zmiany modyfikuj ustalony (bazowy) plan projektu,
zmiany mog (lub nie) modyfikowa uzgodnione elementy projektu,
zmiany rde,
zespou realizujcego projekt,
uytkownikw.
Zmiany nie mog by ignorowane! Zmiany musz by formalnie zarzdzane!
Ignorowanie a bezkrytycyzm
Ignorowanie (odmowa wprowadzenia) jakichkolwiek zmian spowoduje, e projekt
nie bdzie spenia rzeczywistych potrzeb. Bezkrytyczna akceptacja wszystkich zmian
grozi wymkniciem si projektu spod kontroli.
Dlaczego zarzdzanie zmianami?
Poniewa w kadym projekcie w trakcie jego realizacji wystpuj zmiany:
Potrzeba oceny zmiany: konieczna czy nie?
Zesp projektowy musi pracowa wedug takich samych zaoe, co do zakresu
i produktw projektu
Zarzdzanie zmianami cele:
racjonalizacja procesu modyfikacji projektu,
kwalifikacja zmian: konieczne, warunkowe itd.,
wprowadzenie zmian do projektu w sposb jak najbardziej agodny, bezwstrzsowy,
definiowanie i dokumentowanie zmian (zakresu, czasu, kosztu, ryzyka...),
uzasadnienie koniecznoci wprowadzenia zmiany.
Brak zarzdzania zmianami
Po zastosowaniu zmian w projekcie bez zarzdzania powoduje:
polizgi czasowe, bdce wynikiem dodatkowej pracy,
opnione punkty wzowe i terminy realizacji prac,
62
oddalanie si od zaoonych celw, a nawet bankructwo projektu.

Zarzdzanie zmianami struktura procesu
Identyfikacja koniecznoci zmian: dokumentacja dania zmiany (opis, uzasadnienie, istotno, wypyw).
Analiza: ocena wpywu zmiany na poszczeglne podprojekty.
Ocena wpywu na projekt (cay).
Decyzja o wprowadzeniu (tak, nie, na pniej).
Wprowadzenie, komunikacja, rozpowszechnienie.
Tabela 3.3
Decyzja/zmiana
Odrzucenie
Akceptacja
Odoenie
W zakresie projektu
Poza zakresem projektu
Rozpowszechnienie decyzji wraz z uzasadnieniem
doczenie do planu
przygotowanie propozycji
zmiana harmonogramu
wstrzymanie realizacji do momentu uzyskania formalnej kontaktowej zgody
przydzia rodkw
rozpowszechnianie i realizacja
przeprowadzenie dokadniejszej analizy
zgrupowanie zmiany z innymi o podobnym charakterze
rda zmian:
a) wewntrzne:
architektura systemu,
plan realizacji,
konfiguracja (nie powoduje zmian zakresu projektu);
b) zewntrzne:
funkcjonalno,
otoczenia,
misji,
prawne (zwykle powoduj zmian zakresu projektu).
Grupowanie zmian ma na celu polepszenie efektywnoci procesu wdraania
zmian i moe by uzyskane przez ich analiz:
wedug podobiestwa przyczyn,
wedug podobiestwa dziaa,
w celu minimalizacji zakresu powtarzania prac,
w celu minimalizowania zakresu testowania.
czenie zmian tak, aby ich wprowadzenie stawao si przedmiotem projektw
z wyznaczonymi celami oraz mierzalnymi efektami ich wprowadzenia.
63
Przykadowy formularz zgoszenia zmiany, ktr autor stosowa w fazie nadzoru

autorskiego do zarzdzania zmianami projektu.
Przykad: Formularz zgoszenia zmian w projekcie
FORMULARZ ZGOSZENIE ZMIANY
Tytu Projektu
Serwis Internetowy Rejestru Zakadw Pracy Chronionej
Skrt:
SI RPC
Numer zmiany: 39/2003

Akceptacja oczekiwana w : *1 tydzie
/ 2 tygodnie
/ 1 miesic
/ 3 miesice
Cz I : Propozycja zmiany (wypenia wnioskujcy)

APLIKACJA Centralna Zmiana kodw teryt
Propozycja zmiany:
1. Dokonanie zmian kodw terytorialnych w bazie centralnej zgodnie z zacznikiem
2. Wprowadzenie takich zmian w aplikacji centralnej , ktre pozwol na automatyczn zmian starego kodu na nowy niezalenie, czy operator w aplikacji lokalnej wprowadzi zmian starego
kodu na nowy czy te nie.
Uzasadnienie zmiany:
W dniu 1.01.2003 wesza w ycie zmiana rozporzdzenia Rady Ministrw w sprawie kodw terytorialnych. Ograniczenie si do zmian w aplikacji jedynie do zmian sownikowych spowoduje, ze w
raportach odnoszcych si do poszczeglnych powiatw nie bdzie prawidowych danych. Przykadowo w nowo utworzonym powiecie Powiat m.st. Warszawa raporty wyka 0 (zero) zakadw pracy chronionej.
Zgaszajcy zmian:
A. Kowalski
Data: 20.02.2003
Cz II Decyzja
(wypenia akceptujcy)
Akceptacja*
Akceptacja warunkowa*
Odrzucenie zmiany*
Podpis decydujcego: Kazimierz Frczkowski

X
Data: 23.02.2003
64
Komentarz :
Akceptacja czciowa
* zaznacz waciwe pole X
Cz III. Podsumowanie dziaa

(wypenia Kierownik Projektu)
Koszty:
3 godz. pracy
Harmonogram: w terminie dogodnym dla Zamawiajcego z powiadomieniem wybranych organw
rejestrowych
Zasoby: J. Nowak, A. Zawilak
Efekt w projekcie
Ad1.
1. W CBD
zmieni sownik teryt (mog to wykona: A. Kowalski J. Nowak, A. Kabel)
wystawi nowy sownik TERYT do pobrania (data w SL) dla dolnolskiego, mazowieckiego, MZ
i podkarpackiego
2. W aplikacji lokalnej nie dokonujemy zmian.
Ad 2. Zmiana 39/2003 p.2 proponuje si odrzuci, nie mona rcznie manipulowa danymi, ktre
autoryzuj lokalne punkty rejestrowe z uyciem podpisu elektronicznego. Zmodyfikowanie BD aplikacji centralnej przez Wykonawc spowoduje, e powinnimy te zmodyfikowa bazy lokalne. Jest to
rozwizanie tymczasowe na ktre nie mona si zgodzi. Podmienia kody moe rwnie aplikacja
lokalna ale na takie rozwizanie te nie moemy zgodzi si.
Co zrobimy jeli przyjd kolejne zmiany w kodach teryt?
WNIOSEK
Punkt 2 zmiany 39 odrzucamy.
Ryzyko:
Gdy FIRMA S.A. bdzie modyfikowaa rcznie dane w CBD, bdzie przejmowaa odpowiedzialno
za ich jako.
Zmiana :
*TAK
/NIE
65
Komentarz:
Aplikacje lokalne w ramach aktualnej funkcjonalnoci mog poprzez zoenie wniosku o aktualizacje
dokona stosownych zmian kodu.
Dziaania w zakresie zmian oszacowane przez.....W. Warkomla......................................

Data: ......22.02.2003..................................
* zaznacz X waciwe pole
Zacznik do formularza zgoszenia zmian
L.p.
Przed zmian w bazie centralnej

Kod
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
0263
0263011
1805102
1406102
1431191
1413
1431011
1431021
1431031
1431041
1431058
1431058
1431078
1431088
1431098
1431108
1431118
1431121
1431131
1431141
1431151
1431161
1431171
1431181
1431201
nazwa
Powiat M. Wabrzych
M. Wabrzych
Szerzyny
Tarczyn
Sulejwek
Powiat warszawski
Warszawa-Bemowo
Warszawa - Biaoka
Warszawa - Bielany
Warszawa - Centrum
Warszawa Mokotw
Warszawa - Ochota
Warszawa Praga Poudnie
Warszawa Praga Pnoc
Warszawa rdmiecie
Warszawa Wola
Warszawa oliborz
Warszawa Rembertw
Warszawa Targwek
Warszawa Ursus
Warszawa Ursynw
Warszawa Wawer
Warszawa Wilanw
Warszawa Wochy
Wesoa
Po zmianie w bazie centralnej

Kod
0221
0221091
1216162
1418063
1412151
1465
1465028
1465038
1465048
1465
1465058
1465068
1465078
1465088
1465098
1465188
1465198
1465098
1465118
1465128
1465138
1465148
1465168
1465178
1465158
nazwa
Powiat Wabrzyski
Wabrzych
Szerzyny
Tarczyn
Sulejwek
Powiat m.st.Warszawa
Bemowo
Biaoka
Bielany
Powiat m.st.Warszawa
Mokotw
Ochota
Praga Poudnie
Praga Pnoc
rdmiecie
Wola
oliborz
Rembertw
Targwek
Ursus
Usynw
Wawer
Wilanw
Wochy
Wesoa
Dla wikszoci projektw nie ma czego takiego jak maa zmiana!

KF
3.5. ledzenie i nadzorowanie czasu

oraz kosztw projektu
66
Konieczno kontroli realizacji projektu zauwaono ju dawno (patrz rozdz. 1.3

C. Bernard), wskazujc na potrzeb skontrolowania osignitych wynikw i porwnanie z zamierzonym celem wycignicie wnioskw na przyszo (do nastpnego planu projektu).
67
Potrzebna jest ona zarwno osobom odpowiedzialnym za realizacj projektu, jak

i zleceniodawcom. Cho obydwie wspomniane grupy na realizacj projektu patrz
z rnych perspektyw, to jednak mona wycign pewn cz wspln lub prbowa
opisa stan projektu obiektywnymi wspczynnikami. Opisywane metody opieraj si
wanie na takich wspczynnikach dajcych peny i stosunkowo obiektywny obraz.
rdem powstania najpopularniejszej metody s Stany Zjednoczone, a wic jak
mona si spodziewa podstaw oblicze s pienidze. Budet przedsiwzicia szacowany jest metod bottom-up, tzn. budet przydzielany jest kademu maemu zadaniu realizowanemu w ramach projektu. Cakowity budet jest wic sum budetw
wszystkich zada. Harmonogram przedstawia zatem rozkad w czasie planowanych
wydatkw na realizacj zada, czyli krzyw budetu w funkcji czasu.
Wydatki
Budet
Czas
Rys. 3.2. Przebieg wydatkw na realizacje projektu w czasie
Przykadow krzyw budetu przedstawia wykres na rysunku 3.2. Informuje nas ona
o planowanych wydatkach rozoonych w czasie. Aby zweryfikowa wydajno osigan przy realizacji projektu, naley porwna osigane wyniki z tym co zostao zaplanowane.
3.6. Nadzorowanie projektu metod wartoci uzyskanej

(Earned Value)
Amerykascy producenci kierowani potrzeb pomiaru wydajnoci pracy zastosowali metod, ktra staa si pocztkiem Earned Value, czyli obliczania tzw. wartoci
uzyskanej. Prawdziwy pocztek i rozkwit metody to lata 1960. Departament Obrony
Narodowej Stanw Zjednoczonych w 1967 roku przyj t metod jako standard stosowany do pomiaru wydajnoci projektw prowadzonych na ich zlecenie. Metoda
Earnet Value lub wartoci uzyskanej polega na kontroli realizacji projektu przez porwnywanie zrealizowanego do danej chwili zakresu prac i terminw ich realizacji
oraz rzeczywicie poniesionych kosztw z przyjtymi w planie bazowym harmono-
68
gramem i budetem projektu. Metoda ta naley do kategorii metod zarzdzania przez

pomiar wydajnoci (ang. performance based management).
Czas
Rys. 3.3. Tradycyjne podejcie do kontroli kosztw
Czas
Rys. 3.4. Przedstawienie na wykresie dodatkowej krzywej wartoci uzyskanej
W tradycyjnej metodzie kontroli realizacji projektu w punkcie kontrolnym (stan na

dzisiaj) porwnywano, jakie byy faktycznie poniesione wydatki zwizane z realizacj projektu (od jego pocztku kumulowane) w stosunku do zaplanowanych kosztw
na realizacj (od jego pocztku kumulowane). W takim podejciu nie wyceniano
wartoci prac, ktre zostay wykonane do chwili kontroli. To czy poniesione nakady
spowodoway wytworzenie okrelonej wartoci, jak warto uzyskano nie byo
przedmiotem kontroli. W ten sposb mona byo mylnie interpretowa rnic midzy
69
kumulowanymi kosztami planowanymi i kumulowanymi kosztami rzeczywistymi jako

oszczdnociami (rys. 3.3).
Kontrola obejmuje rwnie wycen wartoci prac (produktw, usug itd. od pocztku realizacji projektu) zrealizowanych do chwili kontroli (stan na dzi) przez obliczenia tzw. kumulowanej wartoci uzyskanej, wwczas mamy moliwo porwnania
w pienidzach trzech parametrw, tj. kosztw planowanych (KP), kosztw rzeczywistych (KR), wartoci uzyskanej (WU) (rys. 3.4) i okrelenia wskanikw odchyle
zawizanych z realizacj projektu takich, jak planowany czas (harmonogram) i budet
(koszt projektu).
Odchylenia
Odchylenie kosztw (ang. cost variance) jest pierwszym parametrem metody Earned Value:
OdK = WU KR
gdzie:
OdK odchylenie kosztw,
WU warto uzyskana,
KR koszty rzeczywiste.
Odchylenie od harmonogramu (ang. schedule variance) jest rnic w danej chwili
midzy planowanym kosztem a wartoci uzyskan:
OdH = WU KP
gdzie:
OdH odchylenie od harmonogramu,
WU warto uzyskana,
KP koszt planowany.
Jak wida z definicji danych odchyle, tj. OdK i OdH mog one mie wartoci dodatnie lub ujemne. Wartoci dodatnie wystpuj wtedy, kiedy WU jest wiksza zarwno od KR, jak i KP, jest to sytuacja korzystna, bo inwestujc w projekt np. 1 z
wypracowujemy WU wiksz od 1 z. Rwnie nasz harmonogram nie ma opnienia
do chwili kontroli, poniewa uzyskalimy wiksz warto (wicej zrobilimy) ni
byo zaplanowane. Oczywicie w przypadku ujemnych wartoci podanych parametrw naley wysun wniosek, e projekt realizujemy za drogo oraz mamy opnienie
w harmonogramie.
Wskaniki
Wskanik kosztw (ang. cost performance index) daje nam odpowied na pytanie
70
ile uzyskujemy za kad wydan jednostk waluty finansowania projektu, np. zotwk. Jeli np. uzyskujemy warto prac tylko 90 groszy przy wydaniu jednego zotego,
to znaczy, e mamy ma wydajno prac w projekcie:
WK = WU/KR,
gdzie:
WK wskanik kosztw,
WU warto uzyskana,
KR koszt rzeczywisty.
Wskanik harmonogramu (ang. schedule performance index) jest porwnaniem tego co zostao zrobione do tego co miao by zrobione. Jeli wskanik ten wynosi np.
1,05, to znaczy e projekt realizowany si szybciej ni byo planowane. Jeli jednak
WH jest mniejszy od jednego, to znaczy, e si spniamy:
WH = WU/KP
gdzie:
WH wskanik harmonogramu,
WU warto uzyskana,
KP koszt planowany.
Rys. 3.5. Przedstawienie graficzne WK i WH w metodzie Earned Value
Analiza i wnioski z danych wskanikw nie zawsze s takie jednoznaczne i jasne,

poniewa mog dotyczy nie tylko koniecznoci zwikszenia wydajnoci pracy zespou, ale moe si okaza, e warto prac w projekcie zostaa zaniona (przydzielenie
wartoci uzyskanej) lub planowane koszty oszacowano nieprawidowo.
Gdy mamy moliwo okresowego badania tendencji przez estymacj zwikszenia
kosztw projektu czy moliwych opnie, wwczas PM mona wczeniej podj
akcje naprawcze lub wystpi z inicjatyw negocjacji terminu zakoczenia projektu
oraz jego kosztw (np. aneks do umowy ) (rys. 3.5).
Z przeprowadzonych bada nad 700 projektami ledzonymi metod Earned Value
71
Koszty
wynika, e ju po okoo 15% realizacji wida pewn stabilizacj trendw. Odwrcenie

trendw (tych negatywnych) jest jednym z najtrudniejszych wyzwa Project Managera [5, 53, 59].
Rys. 3.6. Przedstawienie ostatecznych kosztw projektu i rzeczywistego

(szacowanego) terminu zakoczenia
Przydzielanie wartoci uzyskanej

Metoda 0/100
Dogodnym momentem kontroli prac projektowych metod Earned Value s takie fazy harmonogramu projektu, w ktrych zakoczono prac nad produktami
(komponentami projektu) po osigniciu kamieni milowych. Ale niejednokrotnie
osignicie takiej sytuacji byoby zwizane ze zbyt dugim czasem oczekiwania. W
przypadku wspbienego realizowania wielu zada ich dynamika przydzielania
wartoci uzyskanej musi nastpowa w wyznaczonym czasie kontroli projektu,
pierwsza kontrola ju po ok. 15% wykorzystania zaplanowanego czasu na realizacj projektu. Jak ju zaznaczono najkorzystniejsza sytuacja jest wtedy, kiedy wykonano zadanie w 100%. Przydzielanie wartoci uzyskanej nastpuje
w wysokoci 100% planowanych kosztw. Jest to dobre rozwizanie dla krtko-
72
trwaych zada.
Metoda 50/50
Metoda 50/50 jest rwnie prosta. Przy rozpoczciu zadania uzyskuje 50% swojego zaplanowanego budetu, na zakoczenie pozostae 50%. Gdy operujemy wiksz liczb zada, statystyczny rozkad ich rozpocz i zakocze powoduje, e po
pierwszym skoku, gdy rozpoczynamy kilka zada, krzywa uzyskanych wartoci
do dobrze odpowiada rzeczywistoci. Metoda jest dobra, gdy zadania maj zblione
dugoci realizacji.
Metoda 0-30-70-90-100
W metodzie tej przyporzdkowujemy kolejno 0% wykorzystanego zaplanowanego
budetu na rozpoczcie a do 15% zaawansowania prac nad zadaniem, 30% gdy oceniamy realizacj midzy 15% a 50%, 70% gdy ocena realizacji mieci si midzy 50% a
80%; 90% gdy zrealizowane jest midzy 80% a 95%; 100% za od 95% realizacji do
koca zadania. Metoda 0-30-70-90-100 jest oparta na ocenie eksperta. Wkada on niejako
swoj ocen wartoci uzyskanej do jednej z kilku powyszych przegrdek.
Metoda subiektywnej oceny
Podstaw metody jest ocena postpu prac nad projektem przez eksperta. Metoda ta
ma wad, zwykle oceny eksperta s zbyt optymistyczne. Zwaszcza gdy ekspert ocenia sam siebie. Najczciej ekspert ulega deklarowanym przez wykonawcw sugestiom, e prace wykonano w 90%, a pniej przez dugi czas s kopoty ze zrobieniem
pozostaych 10% zadania. Szczeglnie atwo o taki bd w pracach integracyjnych
i testowych, gdzie podwyszenie lub zapewnienie wymaganej jakoci moe istotnie
przeduy czas zakoczenia tych ostatnich 10% nawet do 50% i wicej.
Metoda oparta na dowiadczeniach z poprzednich inwestycji projektowych
W metodzie tej porwnujemy aktualny projekt z wczeniej wykonanymi projektami. Analizujemy podobne produkty, ktre byy ju wykonywane oraz pytamy byych
wykonawcw o pracochonno i zoono prac oraz obcienie zespou, jakie byo
potrzebne, aby produkt wykona.
Estymacja ostatecznych kosztw i terminu zakoczenia
Wybranie jednej z wymienionych metod moe uatwi monitorowanie stanu projektu. Dziki wskanikowi kosztw (WK) moemy obliczy, jaki bdzie ostateczny
koszt projektu.
Nazywane jest to estymacj ostatecznych kosztw EOK (ang. estimate et comple-
73
tion). Uproszczony wzr na obliczenie tej estymacji wyglda nastpujco:

EOK = (pierwotny budet projektu)/WK.
Podobnie, korzystajc ze wskanika harmonogramu, moemy estymowa termin
zakoczenia projektu. Estymowany okres realizacji EOR mona obliczy z uproszczonego wzoru:
EOR = (pierwotny planowany czas realizacji)/WH.
Estymacja opnienia to EOR pomniejszony o pierwotny planowany czas realizacji.
Szacowanie upywu czasu w projekcie
Ze wzgldu na rny stopie wykorzystania czasu pracy, obiektywne przyczyny
zewntrzne angaowania zasobw przydzielonych do projektu, najczciej nie ma
bezporedniego przeoenia midzy wysikiem a upywajcym czasem w harmonogramie projektu.
Wysiek Upyw czasu
W planach oglnych naley uwzgldnia szkolenia, wakacje, zwolnienia itp.,
przyjmujc okoo 200 dni roboczych w roku.
Realnie przecitny pracownik wykorzystuje na prac 25 godzin w tygodniu.
Dla osb odpowiedzialnych za kierowanie ludmi naley uwzgldnia dodatkowo 1520% na bezporednio podlegych pracownikw.
Oszacowania powinny by dokumentowane w sposb czytelny zawsze wystpuje konieczno korygowania planw.
Pierwsze przydzielone zadania nie powinny by due i zoone.
Naley minimalizowa wspzalenoci dla skracania cieki krytycznej.
Wane jest przydzielanie czasu na przegldy, aby jako bya uwzgldniona
w planach projektw.
Ludzie i miesice nie mog by traktowani wymiennie (10 ludzi 1 mies.
1 cz. 10 mies.).
Czas na przeczenie midzy zadaniami.
O okoo 10% powinno by zwikszone szacowania w celu uwzgldnienia dziaa
zwizanych z zapewnieniem jakoci.
74
start zadania
PT
1
koniec zadania
SOB
NIED
PON
4
przerwa w pracy
Rys. 3.7. Zaleno midzy harmonogramem a terminami wedug kalendarza
Naley zwrci szczegln uwag na kalendarz, dni wolne, wita, urlopy i dostpno zasobw w odniesieniu do kalendarza, jak rwnie szacowan nieprzerwan
prac wymagan do zrealizowania zadania. Na rysunku 3.7 przedstawiono zaleno
midzy harmonogramem a terminem wedug kalendarza:
wysiek
= praca
= 4 dni kodowania
zasoby
= 2 programistw
czas trwania = # nieprzerwany czas wymaganej pracy
= 2 dni
kalendarz
= # cigy czas kalendarzowy wymagany do pracy = 4 dni
Zasoby zuywane na ponoszone koszty rzeczywiste projektu
W wikszoci przypadkw przydzielone do realizacji projektu zasoby bywaj wspdzielone np. z innymi projektami lub wykorzystywane s rwnie np. do wspomagania
dziaalnoci operacyjnej firmy, dotyczy to pomieszcze, wyposaenia, jak rwnie czasu
pracy. Oglnie zalene jest to od przyjtej w firmie metody ewidencji i rozliczenia kosztw i obciania nimi orodkw ich powstawania. Wyrni mona nastpujce rodzaje
zasobw:
ludzkie,
rodki materialne (trwae, nietrwae),
zasoby sprztu komputerowego: pami zewntrzna, moc obliczeniowa,
specyficzny sprzt biurowy,
zasoby programowe, narzdzia, usugi zewntrzne,
infrastruktura,
rodki niematerialne (wiedza, dowiadczenie itd.),
finansowe,
czas,
inne.
W ostatnim okresie, e wzgldu na narastajc konkurencj i postpy technologii
informatycznych, ktre wymuszaj skracanie cyklu realizacyjnego projektu oraz ich
kosztu, metoda Earned Value staje si niewystarczajca i wspomagana jest now metod zarzdzanie zasobami projektu ludzkimi, materialnymi, sprztowymi, czaso-
75
wymi, tzw. (ang. Activity Based Costing) ABC.

Activity Based Costing jest now koncepcj rachunku kosztw, jest to tzw. rachunek
kosztw dziaa. Zgodnie z t koncepcj koszty stanowi jedynie pewien miernik zuycia
zasobw w trakcie realizacji procesw i dziaa prowadzcych do powstania produktu.
Kluczowe znaczenie dla zarzdzania kosztami ma zrozumienie, e wysokie koszty
s jedynie skutkiem, a nie przyczyn niskiej efektywnoci ekonomicznej przedsibiorstwa.
Krzysztof Pniewski [41]
3.7. Podsumowanie
Nie ma tzw. maych zmian w projekcie.
KF
Skoro nie mona unikn zmian, wic jak je traktowa? Mona je ignorowa,
mona te bezkrytycznie akceptowa. Ignorowanie zmian, jeli pojawi si konieczno ich wprowadzenia, nie jest dobrym rozwizaniem. Zmiana jest pewn akcj korekcyjn wobec naszego projektu i jeli j zignorujemy, to moemy doprowadzi do
tego, e nasz projekt nie bdzie czciowo bd nawet cakowicie spenia wymaga
klienta. W takim razie akceptujmy wszystkie zmiany, jakie si tylko pojawi! Niestety
nie byoby to wcale lepsze rozwizanie. W tym przypadku nagminne i niekontrolowane wprowadzanie zmian do projektu mogoby spowodowa wymknicie si projektu
spod kontroli i minicie si z jego celem. Dodawanie kadej nowoci, np. najnowszej
animacji w Flashu, kontrolek, ktre stay si hitem na rynku, tylko po to, e s one
nowociami nie jest na miejscu. Nasz system ma przede wszystkim funkcjonowa,
natomiast tworzenie tzw. wodotryskw nieraz byo powodem problemw.
Innym aspektem, ktry tutaj si pojawia jest nastpujce stwierdzenie: Do projektu
zawsze mona wprowadzi pniej zmiany, wic nie musimy teraz a tak bardzo si
przykada. Pniej wszystko si poukada. Teraz to znaczy we wczesnych fazach
projektu. O jake zgubne jest ono dla tych, ktrzy mu zawierz. Prawda jest taka, e
kady projekt w kocu uda si zakoczy, nawet, jeli nawet realizowany jest niestarannie.
76
B
A
E
C
Rys. 3.8. Sekwencja powstawania komponentw projektu

oraz ich powizanie funkcjonalne i czasowe w kontekcie postulowanych zmian
Uda si, jeli dysponujemy nieograniczonymi zasobami i nieograniczonym czasem. W rzeczywistych projektach jednak mamy ograniczony czas, ograniczony budet, ograniczone zasoby. Z tego wniosek, e im staranniej przykadamy si do realizacji, zwaszcza we wczesnych fazach projektu, tym lepiej jest szansa, e
w projekcie nie bdzie radykalnych zmian. Jeszcze jeden przykad na to, e zwaszcza wczesne fazy s istotne dla projektu (rys. 3.8). Zamy, e podany schemat
mwi nam o zalenociach midzy kolejnymi komponentami i pokazuje czas ich
powstawania. Jeli na pocztku realizacji projektu trzeba bdzie wprowadzi jakie
zmiany do komponentu A, to kolejno powstajce komponenty B, C, D, E i F bd
ju budowane wedug zmienionego elementu A. Jeli natomiast wykonamy wszystkie wymienione komponenty i okae si, e naley dokona zmian w elemencie A,
to pocignie to za sob zmiany w pozostaych, czyli dodatkowe zuycie czasu, pienidzy, rodkw. Jak wida naley si stara zaradza problemom, jeszcze zanim si
pojawi. Jeli jednak zmiany trzeba wprowadzi, naley rozway czy mona je
odoy, czy te naley je wprowadzi natychmiast, aby unikn przedstawionej
sytuacji.
Naley zatem przyj, e niezalenie od woonego wysiku oraz stopnia kompetencji zespou, ktry przygotowywa zaoenia do projektu, tworzy plan zmiany s
nieuchronnym zjawiskiem zwizanym z istot projektu.
Mona by powiedzie, e stae w projekcie jest to, e nic nie jest stae.
Zadanie 3.1
7 wrzenia 2003 w dniu kontroli projektu, kierownik programistw poinformowa
kierownika projektu, e zadanie nr 4 Implementacja elementw interfejsu przeduy
si. Jest to dzie, w ktrym zadanie to powinno by zrealizowane w okoo 50%. Po
oszacowaniu dotychczas zrealizowanych prac kierownik programistw stwierdzi, e
prace s zrealizowane jedynie w okoo 25%, co przekaza menederowi projektu
w postaci raportu. Informacja ta po wprowadzeniu do programu Microsoft Projekt
77
pokazaa, e projekt jest opniony i skonia kierownika projektu do przeprowadzenia

analizy metod Earned Value.
Zadania
1
2
3
4
Rys. 3.9. Rnice midzy harmonogramem planowanym a obecnym.

Zad. 1. Implementacja, zad. 2. Konsultacje i doradztwo,
zad. 3. Nadzr zada, zad.4. Implementacja elementw interfejsu
Podane wykresy przedstawiaj rnice midzy harmonogramem wczeniej zaplanowanym (szary), a pokazujcym obecn sytuacj (zacieniony). Zadanie zaplanowane
byo na okoo 2500 h. Poniewa w poowie jego realizacji kierownik programistw
oceni, e zadanie jest zrealizowane w okoo 25% a ich obecny czas realizacji wynosi okoo 5000 h. Pozostae zadania 1, 2 trwaj odpowiednio 140 dni, zad. 3 3 dni.
Przyjmujemy koszt godziny pracy 40 z dla zada 1 i 3 oraz 60 z dla zada 2 i 4.
Obliczy odstpstwa od planu na podstawie:
1. Wskanika harmonogramu WH.
2. Odchylenia harmonogramu OdH.
3. Wskanika kosztw WK.
4. Odchylenia od kosztw OdK.
4. Modele pracy i komunikacji telepraca

Sytuacje, w ktrych zwykle przychodzi dziaa PM odbiega znacznie od ideau, ktry pozwalaby waciwie zaplanowa przedsiwzicie informatyczne. Do rzadkoci nale takie projekty, w ktrych na pocztku PM moe zdefiniowa jego struktur (WBS),
do zada i uzgodnionego harmonogramu moe przydzieli we waciwej fazie okrelone
zasoby ludzkie, sprztowe oraz ma przydzielony budet. To tylko gwne elementy,
ktre na samym pocztku mog zdecydowa czy projekt bdzie waciwie zarzdzany.
Najczciej mamy do czynienia z sytuacj, e realizujemy projekt w pewnym okresie,
np. 11,5 rocznym, a w tym czasie zmienia si np. organizacja firmy oraz jej strategia.
Do przeszoci nale czasy, kiedy zmiany struktury organizacyjne w firmie byy bardzo
powolne i nieznaczne. Przykadem mog by struktury organizacyjne przedsibiorstwa
w Europie z lat 20. i koca lat 80., aby stwierdzi niewielkie rnice nawet w nazewnictwie komrek organizacyjnych [11, 22, 33, 35, 38].
Dopiero w ostatnich kilkunastu latach nastpio szalestwo zwizane ze zmian
formy zarzdzania, organizacji pracy, tzw. reengineering. W latach 19791995 w Ameryce zlikwidowano blisko 43 miliony miejsc pracy. W Niemczech na pocztku 1996 roku
liczba bezrobotnych osigna najwikszy poziom od czasw drugiej wojny wiatowej
4 miliony. W Wielkiej Brytanii, zgodnie z danymi Ministerstwa Pracy z grudnia 1994, od
1990 roku 6,6 miliona mczyzn, czyli 44% caej populacji siy roboczej byo bezrobotnymi
w rnych okresach, w tym czasie ten sam los spotka ok. 3,9 miliona kobiet, czyli ponad
30% wszystkich pracujcych kobiet [11]. Kolejn fal zwolnie obserwuje si w ostatnich
miesicach 2001 r. w USA, w Polsce poziom bezrobocia w maju 2001 r. osign prawie
16% Polakw tj. ok. 3 miliony, powodem zwolnie nie musi by skrajnie za sytuacja
firmy, ale walka konkurencyjna, poszukiwania sposobw obniania kosztw dziaalnoci
firm oraz dostpne inne moliwoci zatrudniania ludzi wirtualnie. Jaki zatem jest faktyczny poziom bezrobocia? Czy waciwie je mierzymy w sytuacji, kiedy szacuje si, e
obecnie w Europie jest ponad 9 milionw telepracownikw, rok wczeniej z tej formy
zatrudnienia korzystao 4,6 miliona osb, a w 1997 r. tylko 2 miliony, tak wynika z raportu Nowe metody pracy, przygotowanego przez Komisj Europejsk [11]. Mamy zatem do
czynienia z wirtualnymi firmami, w ktrej pracuj wirtualni pracownicy, i praca nadzorowana jest przez sprawnie dziaajce sieci telekomunikacyjno-informatyczne, bez siedzi-
78
by, a czsto rwnie osobowoci prawnej. Mog j tworzy ludzie znajdujcy si w rnych zaktkach wiata, lecz pracujcy wsplnie nad jednym przedsiwziciem i indywidualnie wiadczcy okrelon prac zgodnie z umiejtnociami i potrzebami zleceniodawcy.
Praktyczne wskazwki i informacje w zakresie technik oraz narzdzi wspomagajcych prac zespow zlokalizowanych geograficznie w rnych miejscach s od
pewnego czasu coraz czciej poszukiwane. W tej tematyce wyrniono ju odrbne
zagadnienia socjologiczne czy implikacje globalnej ekonomiki wirtualnych biur. Nie
rzadko podnoszone si problemy kulturowe, ktrych nie mona pomija jako aspektu
zwikszenia produktywnoci, efektywnoci, elastycznoci czy kolokacji zespou. Mwimy o wirtualnej organizacji, zespole i gdy zapytamy o definicje, czy cechach tych
poj, moemy usysze do zrnicowane pogldy, ktre koncentruj si wok
nastpujcych zagadnie:
geograficznej separacji czonkw zespou,
cigy system pracy,
struktura przejciowa lub macierzowa,
zespoy multikorporacyjne.
Obserwuje si dynamiczny rozwj outsourcingu, w warunkach coraz wikszej konkurencji na rynku, coraz mniej firm sta jest na stworzenie i utrzymanie zespou projektowego. Zrnicowanie projektw uniemoliwia wrcz stworzenie dostatecznie elastycznej
grupy, mogcej podj si coraz trudniejszych zlece. Dynamika rozwoju informatyki
skania pracownikw do specjalizacji w wskiej dziedzinie, w ktrej mog ubiega si
o miano eksperta. Trudnym zadaniem jest stworzenie zespou, zawierajcego wszystkie
ogniwa konieczne do podjcia kadego wyzwania. Dostp do ekspertw staje si coraz
bardziej znaczcy. Niejednokrotnie moliwe jest to tylko w sposb zdalny. Dziki nowoczesnym technikom porozumiewania si, ludzko stoi u progu pokonania barier komunikacyjnych bez wzgldu na odlego, a to daje moliwoci tworzenia zespow cile
wyspecjalizowanych w dziedzinie problemw, z ktrymi konwencjonalne zespoy nie
mog wygra.
Poniewa dostp do tego rynku pracy dotyczy jednak niewielu, wic s jego zwolennicy i przeciwnicy, tak jak dla idei globalizacji, ktra bdzie sprzyjaa takim tendencj.
Jest to zrozumiae w sytuacji patrzenia na wiat w zmniejszonych proporcjach dziki rozwojowi komunikacji i telekomunikacji. Dla kogo takie trendy s szans, a dla kogo zagroeniem w sytuacji, kiedy uwzgldnimy, e wiat to wioska zamieszkaa przez 100 osb,
w ktrej: 12 osb to Europejczycy, 60 Azjaci, 14 Afrykanie, 1 Australijczyk, 13
Amerykanie. Ponadto: 6 osb ma prawie 3/5 dochodw caej wioski i jest 1 komputer.
4.1. Wirtualne zarzdzanie zasobami - elektroniczny PM
79
Zrnicowanie stref czasowych umoliwia niemal cig prac 24 godziny na dob, gdzie poszczeglne zadania przejmowane s przez grupy ludzi z rnych czci
globu [18]. Zwiksza to elastyczno, wydajno i dyspozycyjno do wiadczenia
pracy. Niesie rwnie ze sob nowe zagroenia. Rnice wystpuj w sposobie pracy,
mentalnoci pracownikw, s te rnice kulturowe. Wymaga to bardzo skrupulatnego przestrzegania zasad komunikacji, definiowania wsplnych poj i celw. Jednakowe zrozumienie i interpretacja wspdzielonych danych jest wanym aspektem tworzenia i dziaania zespow wirtualnych.
Przed projektem menedera (PM) stoj cakowicie nowe wyzwania. Wi si one
z budow zespou, z pokonaniem barier kulturowych, ocen kosztw i zoonoci
komunikacji, z okreleniem jednolitych standardw obowizujcych cay zesp.
Tabela 4.1. Telepracownicy w Unii Europejskiej (w latach 20002010)
Na stae zatrudnieni w domu

Pracownicy pracujcy w wielu miejscach
Niezatrudnieni na stae, wiadczcy usugi
Pracujcy w domu, nie wiadczcy usug
Suma
2000
2010
810 000
3 700 000
1 450 000
3 080 000
9 040 000
3 170 000
14 332 000
3 040 000
6 580 000
27 122 000
rdo: Emergence analysis, 2001 [5].
W istocie elektroniczny PM to rzeczywisty czowiek specjalista w dziedzinie zarzdzania przedsiwziciami projektowymi, ktry poza dowiadczeniem i wiedz niezbdn
w kierowaniu i zarzdzaniu ludmi jest wyposaony w odpowiednie rodki techniczne
oraz narzdzia programowe, ktrymi posuguje si sprawnie, aby zaplanowa i monitorowa cay cykl ycia przedsiwzicia. Dodatkowym zadaniem PM dziaajcego w rodowisku wirtualnym jest zorganizowanie komunikacji z zespoem poprzez efektywne
wykorzystanie rodkw technicznych zapewniajcych dostp do wiedzy, czciowych
wynikw prac wspdziaajcych zespow oraz zarzdzania zmianami.
4.2. Elektroniczny partner, czonek zespou

Elektroniczny czonek zespou lub zesp to istniejcy rzeczywicie specjalici, ktrzy pracuj niejednokrotnie we wasnych mieszkaniach i najczciej w takich strefach
ekonomicznych, gdzie jest dua poda specjalistw, a ich oczekiwania finansowe za
wiadczon prac s znacznie nisze ni w centrali firmy. Dzi niejednokrotnie bardzo
zoone prace mog realizowa wirtualne zespoy na wasnym sprzcie komputerowym
(najczciej) lub udostpnionym, majc zapewniony dostp do Internetu. Dynamiczny
rozwj sieci telekomunikacyjnej oraz telefonia komrkowa praktyczne umoliwia prac
80
prawie w kadych warunkach. Nowoczesne miejsce pracy zapewniajce peny komfort

obejmuje: telefon, komputer osobisty poczony z sieci, laptop, fax, cze internetowe i
cze wideo. Taka praca jest pochodn innych znanych modeli organizacyjnych zespow w zarzdzaniu projektami, poniewa celem ich jest:
przedstawienie modeli organizacji zespow projektowych w zrnicowanych
organizacyjnie firmach,
analiza zada pod ktem dopasowania zastosowania adekwatnej metody organizacji zespou a typem projektu,
jak wykorzysta zrnicowan wiedz poszczeglnych czonkw zespou do realizacji wsplnego celu.
Zesp grupa, jest wtedy, gdy ma wsplne cele i zdaje sobie z tego spraw, e
do ich osignicia potrzebne s wysiki kadego z jej czonkw. Zesp jest wwczas,
kiedy grupa ludzi sama uwaa si za zesp, gdy zmierza w zespoowym kierunku i
gdy ma wasne zespoowe sposoby dziaania, swoisty sposb zachowania.
Symptomy tworzenia, powstawania zespou
Aby mona byo nazwa grup ludzi zespoem, musz oni mie wsplny cel,
wspzalene zadania, wspln odpowiedzialno i wzajemne zaufanie.
Proces tworzenia wirtualnego zespou projektowego naley do projektu menedera
(PM). Jego zadaniem nie jest jedynie stworzenie wasnej wizji wsppracy. Budowanie zespou pociga za sob rwnie:
Okrelenie wsplnej wizji dla zespou.
Zbudowanie infrastruktury dotyczcej technologii, nadzoru, uatwienia komunikacji.
Utworzenie wspdzielonego repozytorium wiedzy.
Zbudowanie dobrych relacji pomidzy czonkami zespou.
Selekcj i ocen czonkw zespou.
Stworzenie atmosfery satysfakcjonujcej prac w zespole.
W MSI (ang. Management Strategies, Inc.) opracowano dwa wsppracujce ze
sob modele efektywnego tworzenia zespow rozproszonych.
Model dopasowania wspomaga projekt menedera w selekcji i ocenie kandydatw.
Model dojrzewania pomaga oceni istniejc struktur zespou rozproszonego,
by umoliwi jego rozwj do postaci umoliwiajcej uzyskanie wikszej wydajnoci.
Aby zastosowa z powodzeniem podane modele, naley dokadnie zdefiniowa
gwne aspekty wsppracy midzy czonkami zespou wirtualnego. Odnosz si one
do okrelenia standardw dostpnoci i potwierdzania otrzymania informacji, utworzenia wsplnego kontekstu wszystkich przesyanych informacji. Komunikacja synchroniczna, zapewniajca umieszczenie wszystkich stron komunikacji w tej samej
czasoprzestrzeni umoliwia szybkie zbudowanie korzystnych relacji midzy czon-
81
kami zespou. Wprowadzenie priorytetw w rozsyaniu informacji, aby zapobiec efektowi przeadowania.
W zespoach rozproszonych due znaczenie ma repozytorium wiedzy, jest to najczciej dziedzinowa baza danych, ktra zawiera wszystkie biece i historyczne informacje
dotyczce projektu. Coraz rzadziej zdarza si, aby w zespoach projektowych osoby
uczestniczce w realizacji projektu byy tam od samego pocztku. Cenna wiedza gromadzona przez osoby zaangaowane na rnych etapach, nie moe zosta bezpowrotnie
utracona. Stworzenie centralnej bazy wiedzy umoliwia korzystanie z repozytoriw, dokumentw, formularzy, opracowa czy kodw rdowych tworzonych przez zesp.
Umoliwia szacowanie rozmiaru kolejnych projektw, ich czasochonnoci i zoonoci
przez podobiestwo do informacji zgromadzonych w repozytorium.
Uycie modelu dopasowania koryguje procedur doboru osb angaowanych w realizacj projektu. W przypadku klasycznym Project Manager, kieruje si przede wszystkim
umiejtnociami technicznymi kandydata, zakada si, e zatrudniona osoba wdroy si
w narzucony styl i narzdzia pracy. To podejcie nie ma zastosowania w przypadku osb
zatrudnianych zdalnie.
Rdzeniem modelu dopasowania jest uzmysowienie sobie, e zatrudnienie osoby
z zewntrz organizacji zatrudniajcej pociga za sob rozbienoci w stylu komunikacji i pracy midzy pracodawc a pracownikiem. Konieczne staje si dopasowanie
dwch czci ukadanki, dajcej w efekcie owocn wspprac. Jej elementami s:
cele, procesy, narzdzia i kwalifikacje (rys. 4.1.)
Rys. 4.1. Model dopasowania
Pierwsz czci s cele. W procesie ich definiowania nie wystarczy rozpatrzenie

podstawowych elementw. W zespoach rozproszonych o rnych uwarunkowaniach
82
kulturowych, w duym rozproszeniu geograficznym konieczne jest dogbne zdefiniowanie uywanych poj. Okrelenia jako czy na czas mog mie zbyt rozbiene znaczenia. Wsplne definicje uywanych poj s konieczne przy definiowaniu
wsplnych celw.
Wsplne procesy maj wpyw na dopasowanie telepracownika do zespou. W przypadku stosowania rygorystycznych procesw wytwarzania oprogramowania wane jest
zatrudnienie pracownika znajcego i rozumiejcego obowizujce procedury postpowania.
Posugiwanie si wsplnymi narzdziami i rodowiskami pracy jest bardzo wanym
aspektem pracy w grupach rozproszonych. Komunikacja elektroniczna niejednokrotnie
stanowi jedyny pomost cznoci midzy czonkami zespou. Korzystanie z jednolitych
rozwiza technologicznych pozwala na zachowanie spjnoci przesyanych informacji.
Opnienia spowodowane trudnociami w komunikacji mog stanowi nawet do 25%
czasu realizacji projektu.
Ostatnim elementem ukadanki s umiejtnoci. Oprcz cile zwizanych z technologi licz si rwnie umiejtnoci zwizane z komunikacj oraz sam organizacj
pracy. Dopasowanie tych elementw jest konieczne do stworzenia prnie dziaajcego wirtualnego zespou projektowego.
Model dojrzewania opiera si na czterech poziomach struktur zespou wirtualnego.
Na kadym z tych poziomw pojawiaj si kluczowe problemy, charakterystyczne dla
kadego z nich. Model dojrzewania jest w stanie okreli czas, jaki zajmie organizacji
przejcie z aktualnego poziomu do kolejnego. Miar wydajnoci zespou jest jego
zdolno do realizacji projektw w narzuconym czasie i budecie. Przejcie do kolejnych poziomw zwiksza wydajno przez optymalizacj poszczeglnych aspektw
dziaania zespou.
Zesp niezalenie od fizycznego usytuowania, sposobu komunikacji oraz realizowanego zadania na pewnym etapie dziaania nabywa cech pozytywnych oraz negatywnych, do ktrych nale midzy innymi:
swoista ideologia,
normy wspdziaania i bycia egzekwowane s w sposb naturalny nie ma regulaminu,
mylenie grupowe,
brak krytycznego spojrzenia na efekt pracy grupy,
nie rozwaanie jakichkolwiek rozwiza przyjtych poza grup,
nastpuje spadek jakoci pracy,
manifestowanie jednolitoci i lojalnoci.
Niektre ze zjawisk maj przyczyn w istotnych rnicach wynikajcych z porwnania pracy midzy zespoem tradycyjnym a wirtualnym, takich jak:
w zespole tradycyjnym:
dyskusje prowadzone bezporednio, wida reakcje i temperament rozmwcy,
czsto praca samodzielna,
83
zasoby w bliskim otoczeniu,

praca sekwencyjna,
informacja przechowywana lokalnie;
w zespole wirtualnym:
sesje dyskusyjne wirtualne (czat, gadu-gadu, e-mail),
dokumenty elektroniczne,
informacja w globalnym oglnodostpnym lub selektywnym repozytorium,
praca wykonywana wsplnie,
dostp do zasobw poprzez poczenia.
Tabela 4.2. Rnice midzy tradycyjnym i wirtualnym zespoem projektowym
Tradycyjny zesp
Czonek z tej samej organizacji
Czonek wyuczony, czsto polecony, ustalajcy
standardy
Maa ufno
Procesy pracy sztywne i zdefiniowane, czsto
nieuyteczne
Struktura zespou hierarchiczna
Stabilne rodowisko pracy
Wane pozycja i wadza
Wirtualny zesp
Czonek z organizacji, firmy przynalenej biznesowo, konkurent
Czonek dobrany z powodu wykazanych przez
niego kompetencji
danie duej ufnoci
Procesy pracy elastyczne dopasowane do zespou,
dostosowane do projektu
Redukcja hierarchii, wicej zalenoci sieciowych
Cige zmiany rodowiska pracy
Wana wiedza i zdolnoci
Grupowe produkty zespow wirtualnych generuj rozwj oraz wymogi w kierunku sprawniejszej i multimedialnej komunikacji, sprzeda produktw grupowych
w 1997 r. w USA zwikszya si w stosunku rocznym prawie o 100% [23], ale jednoczenie w cigu ok. 30 dni instalowanych jest prawie 1 milion korporacyjnych
skrzynek e-mailowych.
Przykad:
Przy realizacji projektu PM, realizowanego w okresie od kwietnia 2001 r. do grudnia 2002, w listopadzie 2001 r. do projektu byo zaangaowanych 7 osb. W tym czasie harmonogram obejmowa 5 wydzielonych zada midzy innymi: modelowanie
danych, modelowanie procesw, opracowanie logiki stanw. W cigu miesica zesp
(3 osoby we Wrocawiu, 2 w odzi, 1 w Katowicach, 1 w Gdyni) wymieni pomidzy
sob ponad 1000 e-mali, czyli przecitnie kady z czonkw zespou otrzyma lub
wysa cznie rednio ponad 140 e-maili. Niezalenie od poczty by dostp do wsplnych zasobw repozytorium w Lotusie i grupowa praca nad produktami. W repozytorium gromadzono np. wsplne ustalenia, wzory dokumentw, korekty dokumentw,
uwagi, polecenia, monitorowanie zmian, opiniowanie itd. Etapy koczyy si spotka-
84
niem zespou w trakcie videokonferencji [18, 30].
4.3. Podzia i modele organizacyjne zespow

Organizacja jest wskanikiem stopnia dojrzaoci organizacji oraz jej podejcia do
tego zagadnienia. Wyrnia si nastpujce modele organizacyjne pracy zespow:
sieciowy,
gwiadzisty,
izomorficzny,
specjalizacyjny,
nieegoistyczny,
macierzowy
zadaniowy,
funkcjonalny.
Zesp sieciowy (demokratyczny) charakteryzuje si dosy rwnym udziaem
wszystkich czonkw w podejmowaniu decyzji (rola lidera moe w zasadzie by przechodnia). Uczestnicy komunikuj si kady z kadym (rys. 4.2). Z tego wzgldu liczba
czonkw
w takim zespole nie powinna przekracza 812. Zalet tej struktury jest atwa moliwo
rekonstrukcji zespou w razie odejcia lidera, gdy wszyscy czonkowie maj duy wgld
w postp prac projektowych. Lider ma za zadanie wycznie koordynacj prac, reprezentowanie zespou i penienie funkcji administracyjnych. W zespole takim nie mog si
pojawia czonkowie nowi, niedowiadczeni, gdy nie nadaliby za tempem pracy pozostaych. Model taki dobrze sprawdza si we wczesnych fazach prac nad projektem (burza
mzgw), gdy wymagane jest powstawanie twrczych koncepcji. Moe si wraz z
upywem czasu okaza, e zesp o strukturze demokratycznej przerodzi si w zesp o
bardziej scentralizowanej strukturze (np. zesp o strukturze gwiadzistej).
Rys. 4.2. Struktura sieciowa wspdziaania czonkw zespou
85
W strukturze sieciowej wystpuj takie cechy, jak:

istnieje komunikacja midzy poszczeglnymi osobami,
nie ma podziau ze wzgldu na odlego subow lub organizacyjn,
grupy kilkuosobowe (zalecane maksymalnie 8 osb),
grupa pocztkujca,
szybko wypracowuje standardy dokumentowania pracy itp.
Zesp o organizacji gwiadzistej charakteryzuje si siln, centraln pozycj lidera,
ktry poredniczy w wymianie wszystkich informacji midzy czonkami zespou (rys.
4.3). Lider jest jedyn osob znajc cao prac projektu i jego odejcie jest duym
zagroeniem dla projektu. Lider przydziela prac poszczeglnym czonkom zespou
i nadzoruje wykonanie przez nich zada. Nie ma tu miejsca na dyskusje i demokratyczne
ustalenia. Za to zesp moe by liczniejszy (do pewnych rozsdnych granic wyznaczanych przez moliwoci komunikacyjne lidera), jak rwnie mog w nim znale
miejsce osoby o rnym poziomie zaawansowania (zwaszcza pocztkujce, ktrym
lider moe powici nieco czasu na udzielanie rad). Model ten sprawdza si w dalszych
fazach cyklu produkcji oprogramowania, dziki scentralizowanej wadzy. Angielska
nazwa tej struktury wzia si od sposobu organizowania zespow programistycznych
stosowanego w latach siedemdziesitych przez IBM. Zesp taki skada si z 34 staych czonkw: gwnego programisty (chief programmer), programisty zapasowego
(backup programmer), oraz bibliotekarza (librarian). Do nich w razie potrzeby przydzielano pozostaych niezbdnych pracownikw.
Rys. 4.3. Struktura gwiadzista wspdziaania czonkw zespou
W strukturze gwiadzistej mona wyspecyfikowa takie cechy dziaania, jak:

wszystko skupia si wok jednej osoby szefa,
szef wsppracuje cile, ale osobno z kad osob z grupy,
wymiana informacji midzy czonkami zespou jest za pomoc kierownika,
kierownik przydziela zadania i ocenia efekty pracy,
zespoy z niedowiadczonymi ludmi (kierownik prowadzi za rk pomaga),
86
liczno wiksza ni przy sieciowej zalena od moliwoci kierownika.

Problemem zasadniczym staje si zmiana kierownika, jak rwnie jego czasowa
nieobecno, np. choroba, urlop.
Struktura izomorficzna najczciej charakteryzuje si takimi cechami, jak:
odwzorowuje struktura projektu,
oddaje struktur projektu w struktur zespou,
opracowanie dokumentw projektu zgodnie z kompetencjami zespou.
Rys. 4.4. Struktura specjalistyczna zespou
Rys. 4.5. Struktura nieegoistyczna zespou
Struktura specjalistyczna (rys. 4.4) jest dostosowana do moliwoci i kwalifikacji zespou, jak:
zadania dla osb wedug ich specjalizacji,
odpowiedzialny za cao projektu najbardziej dowiadczony czonek zespou.
Podstaw pracy zespou o strukturze nieegoistycznej s zadania i ich znaczenie
(rys. 4.5). Praca czonkw zespou podporzdkowana jest ich realizacji i zespoy maj
wsplny cel (w rnym czasie lub stopniu) w wykonaniu zadania. Wykonane zadanie
87
z sukcesem lub jego niepowodzenie to zasuga caego zespou. Informacja dotyczca

wkadu w cao projektu i poszczeglnych zada nie jest przedmiotem personalnego identyfikowania si z produktem kocowym czy zadaniem.
4.4. Projekty w firmie o strukturze macierzowej

Rzeczywista firma i jej zdolno do realizacji projektu przez wirtualne tworzenie
sieci partnerw jest niejednokrotnie podstaw jej sukcesw. Modele organizacyjne,
ich cechy i specyfika omwiona jest w pracach [7, 11, 28, 38]. Najczciej obserwuj
si ewolucje firm o strukturze macierzowej (rys 4.6), ktre dopasowuj swoj organizacj pod sprawn obsug procesw, przez ni przebiegajcych. Nowe zadania, nietypowe projekty w takiej strukturze wymuszaj tworzenie sieci partnerw. W strukturze macierzowej mamy do czynienia:
z podwjn podlego pracownikw,
konfliktami wobec podwjnego podporzdkowania przy prbach elastycznego
dziaania na styku rnych komrek i w przypadku przecienia zadaniami,
podwjny system kontroli i oceny wynikw pracy, niejednokrotnie trudnoci
rwnowaenia obowizkw formalnych i wkadem pracy, co ma bezporedni wpyw
na nagradzanie pracownikw.
Rys. 4.6. Podwjny acuch podporzdkowania w realizacji projektw

w firmie o strukturze macierzowej zadaniowej
88
Moemy wyrni dwa rodzaje osb kierujcych (zarzdzajcych): kierownika

projektu (ang. software project manager) i kierownika zespou funkcyjnego (ang.
supervisor). W zalenoci od ich wpyww i siy struktury macierzowe mona podzieli na sabe, silne i zbalansowane. Dla struktury macierzowej sabej rola kierownika
projektu jest ograniczona bardziej do roli koordynatora i przyspieszacza ni zarzdzajcego. Przy strukturze silnej macierzowej kierownik projektu ma znaczny autorytet (prawo podejmowania decyzji) i uprawnienia administracji zaog. Zazwyczaj kierownik
projektu
odpowiada
za
sprawy
zwizane
z
zarzdzaniem,
harmonogramowaniem i planowaniem, natomiast kierownik funkcjonalny jest odpowiedzialny za techniczn stron projektu, zajmuje si szkoleniami i karier pracownikw.
Rys. 4.7. Podwjny acuch podporzdkowania w realizacji projektw

w firmie o strukturze macierzowej funkcjonalnej
Zaogi s grupowane z uwzgldnieniem specjalnoci, funkcji oprogramowania lub

podobnych, takich jak: zesp inynierw systemowych, zesp testerw, zesp pomocy technicznej (ang. software support), zespoy zastosowa inynierii oprogramowania, zesp analitykw branowych, hurtowni danych itp.
Zasig projektu ograniczony jest do zespou funkcyjnego, tzn. komunikacja poszczeglnych zespow odbywa si przez przeoonych, tj. kierownikw zespow
dziedzinowych. Zarwno pytania, jak i produkty kocowe przekazywane s od jednego zespou do drugiego przez przeoonych.
Taka organizacja w dalszym cigu w wielu firmach zdaje egzamin, ale duy postp
w zakresie stosowania nowoczesnych systemw informatycznych gwnie w samych
firmach informatycznych oraz zmiana kultury kierowania przez partnerstwo ludzi myl-
89
cych, majcych du swobod dziaania nie tyko czekajcych na polecenia i ich wykonanie, zmienia model zarzdzania. Sieci korporacyjne, intranet, e-mail, poczenia ISDN
na potrzeby wideokonferencji, telefon stacjonarny i komrkowy spowodoway, e moemy mwi o rodzcym si zjawisku samokreowania warsztatu i miejsca pracy. Mj pracodawca to ja sam z moimi umiejtnociami wiadczenia pracy i przesyania jej wynikw
w postaci elektronicznej. Idziemy w kierunku kontraktowania zadaniowego i czasowego
swej pracy, a nie zatrudnienia na etat.
Za pomoc rodkw i narzdzi informatycznych wykonawcy zada oraz centrala firmy, na kade danie i w kadej chwili ma zapewniony dostp do rezultatw pracy, moe
jednym e-mailem powiadomi wszystkich lub wybran grup pracownikw o swoich
decyzjach lub zadaniach.
Udostpni wiedz i prowadzi edukacj przez organizacj dziedzinowych repozytoriw, np. z wykorzystaniem Lotus Notes lub WebDB, Visual Source Safe (VSS).
Istnieje rodzina programw wspomagajca zarzdzania konfiguracj typu RCS, Case
Ware, Aide-De-Comp, DSEE, Rational, NSE, ktre pozwalaj na atwe kontrolowanie
procesu zmian w projekcie i zarzdzania wersjami (dodatkowe informacje w rozdz. 9).
Tym samym szczeble porednie staj si zbdne, struktura znacznie si spaszcza, ale
powstaje inny problem potrzeby wykreowania specjalistw, ktrzy zweryfikuj tworzone rozwizania i wykorzystaj je w firmie. Budowane narzdzia i technika komunikacyjna sprzyja budowie systemu scentralizowanego z moliwociami zdecentralizowanych i samodzielnych decyzji w maych zespoach zadaniowych.
4.5. Wirtualna siec partnerw przedsiwzicia

Cho sowo wirtualny znaczy nierzeczywisty, nieprawdopodobny, ale moliwy bez
cech fizycznych, jest bytem realnie mogcym dziaa. W tym nowym otoczeniu dotychczasowe metody zarzdzania s niewystarczajce. Adekwatnie do potrzeb wirtualna sie
zespow potrzebuje wirtualnego zarzdzania. To pojcie jeszcze nie jest upowszechnione, czy si z metodami kreowania zespow wirtualnych, pobudzania indywidualnej
przedsibiorczoci, przekazywanie efektw pracy na odlego, czyli telepraca, efektywne
kierowanie specjalistami, zapewnienie cigego uczenia si w przedsibiorstwie i przeksztacenie go w uczc si organizacj, ktra umie zarzdza wiedz.
Kto za co odpowiada i czym dysponuje
Jeli gwnymi elementami stanowicymi o sukcesie wirtualnego zarzdzania jest
elastyczno oraz kreatywna integracja, to dotychczasowe systemy planowania, sterowania kontroli nie speniaj ju swojej roli. Pewne elementy kontroli, jak np. czas
pracy, dyscyplina formalna, harmonogram w pewnym zakresie jest poza kontrol i nie
90
speniaj swojej roli. Pracownicy przejmuj w znacznej czci funkcje menederw

mylenie w zakresie co i jak zrobi, nie otrzymuj systematyczne polece, ktre skrupulatnie maj wypenia. Pracownika nie obserwuje kierownik i nie widzi jego zmczenia czy patrzenia w sufit. Menederowie steruj zespoem wirtualnym przez
wsplne zdefiniowanie celw i wystpuj w roli konsultantw i trenerw. Kierownictwo firmy dysponuje odpowiedni infrastruktur i zatrudnia menaderw zajmujcych
si zarzdzaniem strategicznym. Za dziaalno operacyjn w wikszoci przypadkw
odpowiadaj rozproszone zespou czy pojedynczy ich czonkowie, co znacznie zwiksza wymagania wobec wszystkich i jest elementem mobilizujcym. Kady kto bierze
udzia w takim projekcie ma wiadomo swojej wanoci, e jest specjalist, a wic
pracownikiem dysponujcym du wiedz, jest dobrze wyksztacony, pomysowy,
odznacza si umiejtnoci dziaania w zespole i dobrze znosi prac bez ywych kontaktw (atmosfery biurowej) i jest odporny na stres zwizany z brakiem kontaktw
interpersonalnych.
Gdy mamy zesp i organizacj
Gdy mamy infrastruktur, rodki techniczne oraz organizacj rozproszon jak niemal sie www, wwczas jako firma majca zdefiniowany cel moemy realizowa
zoone projekty, ale moemy rwnie oferowa na bazie utworzonej organizacji
zesp telepracownikw, oferowa nowy rodzaj usug np.:
ICC (Internet Comunication Center), usuga hostingu serwerw, w ktrej usugodawca udostpnia serwer we wasnej serwerowni i odpowiada za stan oraz aktualizacj plikw.
ASP (Aplication Service Provider), usuga udostpniania aplikacji dla klientw
za miesiczn opat.
Serwisowanie oprogramowania przez Internet.
E-commerce, inne.
Tabela 4.3. Zalety i wady struktur macierzowych
Struktura zespou
Zalety
Funkcjonalna
1. Szybki start- organizacja ju istnieje

atwe zarzdzanie pracownikami
ustalone s narzdzia, techniki, standardy itp.
Projektowa
1. Centralna odpowiedzialno za projekt

2. Centralna kontrola interfejsw komunikacyjnych
3. Szybko podejmowania decyzji
4. Wysoka motywacja zaogi
Wady
1. Brak centralnej odpowiedzialnoci za
projekt
2. Problemy z interfejsami komunikacyjnymi
3. Trudna kontrola i monitorowanie
1. Konieczno tworzenia nowego zespou
dla kadego projektu
2. Trudniejsze zarzdzanie pracownikami
3. Brak ustalonych narzdzi, metod standardw, itp. na starcie projektu

Macierzowa
1. Wady powyszych projektw zagodzone

2. Bardziej elastyczne zarzdzanie ludmi
91
1. Dwch przeoonych
2. Trudnoci w monitorowaniu i przepywie dokumentw, wikszy nakad
czynnoci koordynujcych
3. Moliwy konflikt przywdcw
Wprowadzenie systemw elektronicznej komunikacji wewntrznej i internetowych

baz danych, dostpnych z kadego miejsca na wiecie, praktycznie wyeliminowao
problemy dostpu do danych zwizanych z lokalizacj miejsca pracy. Dzi, pracujc
nad konkretnym projektem, firma moe zwerbowa zesp najlepszych specjalistw z
danej dziedziny, nie przejmujc si miejscem ich zamieszkania. Komunikacja przez
Internet uatwia te organizacj czasu pracy. Intenetowa wsppraca nie budzi jednak
entuzjazmu u wszystkich. Pewne kraje, jak USA, Wielka Brytania, maj wiksze dowiadczenia w pracy wirtualnej, w krajach tych lansowano tez, e przyszo to praca
w domu. Ale nie wszyscy pracownicy akceptuj taki model pracy, nie wszyscy czuj
si w nowej sytuacji lepiej. Nadal przyjedamy do firmy, aby zaspokoi nasze potrzeby spoeczne: spotkania si z kolegami, rozmowy, miechu. Psycholodzy ostrzegaj, e jeli pracujemy w domu, moemy mie trudnoci z okreleniem, gdzie koczy
si ycie zawodowe, a zaczyna prywatne. Przy bardziej stresujcych zadaniach i napitych terminach moe to doprowadzi do tego, e o firmie bdziemy myle od porannej toalety a po wieczorn. Przypomina o niej bdzie wczony komputer i sterta
dokumentw na biurku i w sypialni. Rozwizaniem moe by wydzielenie odrbnego
pokoju do pracy i elazne przestrzeganie godzin jej zakoczenia. Ryzyko realizacji
duych projektw w takiej organizacji moe by minimalizowane przez waciwe
proporcje midzy pracownikami pracujcymi tradycyjnie i wirtualnie. Gwn barier
w upowszechnianiu wirtualnej pracy nie s ograniczenia technologiczne, ale mentalno, zarwno pracownikw, jak i ich przeoonych.
4.6. Zespoy projektowe praca grupowa

Rozwj informatyki skania pracownikw do specjalizacji w wskiej dziedzinie,
w ktrej mog ubiega si o miano eksperta. Trudnym zadaniem jest stworzenie
zespou, zawierajcego wszystkie ogniwa konieczne do podjcia kadego wyzwania. Zasb wiedzy, umiejtnoci, jakie naley przyswoi w okrelonym czasie, jak
rwnie j aktualizowa, powoduje, e specjalizacja i podzia kompetencji jest dominujcy w organizacji, ktra wytwarza produkty informatyczne. Dostp do ekspertw staje si coraz bardziej znaczcy i niejednokrotnie decyduje o powodzeniu przedsiwzicia. Nie zawsze jest to moliwe w danej firmie, czsto naley szuka na zewntrz
lub niektre prace outsoursowa. Zachodzi potrzeba budowy zespow cile wyspecjalizowanych w dziedzinie problemw, z ktrymi konwencjonalne zespoy nie mog
92
wygra. Czasy kiedy informatyk zna budow komputera oraz 2 podstawowe jzyki
programowania, np. asembler oraz Coboll i wystarczay mu do zajmowania waciwej
pozycji w kadym projekcie nale do przeszoci. Ogromna liczba wykonywanych
zada w projekcie wymaga wsppracy kilku, a niekiedy kilkudziesiciu osb, czyli
wyspecjalizowanych zespow oraz pracy grupowej (ang. collaboration).
Rodzaje zespow projektowych
Typowymi zespoami, ktre powouje si na czas realizacji projektu lub na stae s
utrzymywane w firmie to:
zesp wytwarzania aplikacji
zaleno od technologii,
znajomo narzdzi i technik wytwarzania oprogramowania,
role:
klient/zamawiajcy, kierownik, kierownik techniczny, analityk, projektant,
implementator, testujcy, dokumentujcy, administrator
zesp identyfikacji i analizy potrzeb/wymaga
znajomo dziedziny znajomo metod informatycznych,
role:
analityk, dokonujcy interview, protokoujcy
zesp serwisu
sprztu informatycznego i infrastruktury,
oprogramowania systemowego,
oprogramowania uytkowego
zesp utrzymania
funkcje: obsuga, usuwanie usterek, rozwj, dostosowanie do nowych
potrzeb, doradztwo,
role:
uytkownik, operator, inynier systemw, administrator bazy danych, programista, konfiguracji
zesp wdroeniowy
znajomo strategii wdroenia,
zesp wytwarzajcy + przyszli uytkownicy.
Jeli przyjmiemy przykad przemysowej organizacji procesu spiralnego rozwoju
oprogramowania z rozwojem przyrostowym i iteracyjnym, to naley utworzy:
zesp zapewniajcy jako,
zesp organizacji wielokrotnego wykorzystania oprogramowania (ang. reuse),
zesp midzy-projektowy,
wzorcownia standaryzacja GUI, komunikacja z baz danych,
zesp konsultacyjny.
93
Praca grupowa
Termin ten okrela wspprac wielu, rozproszonych geograficznie, albo siedzcych w jednym pomieszczeniu osb, ktre korzystaj z udogodnie oferowanych
przez wspomagane technologi rodowisko pracy. Wspomaganie to polega na dostpnoci mechanizmw przesyania i wspdzielenia dokumentw, mechanizmw planowania i rozdzielania zada, kontroli postpw w realizacji tych zada, ledzenia terminowoci i kosztw prowadzonych prac. Przykadem jest pisanie raportu. Oprcz
gwnego autora, wpyw na tre dokumentu ma np. recenzent, konsultant, korekta
oraz szef zespou. Podobnie jest przy tworzeniu koncepcji, projektowaniu oraz pisaniu
oprogramowania, gdy odpowiednie rezultaty pracy wprowadzane s przez czonkw
poszczeglnych wydziaw. Takich sytuacji, w ktrych potrzebna jest wsppraca
kilku osb, mona wymieni jeszcze co najmniej kilka. Okazuje si, e zadania, jakie
wykonuj pracownicy w przedsibiorstwach, to czsto zoona praca grupowa.
Osignicia technologiczne ostatnich lat w zakresie Internetu oraz intranetu, a take w zakresie rozbudowywania moliwoci programw biurowych (pakietu biurowego Office 2000, Word, Excel, Power Point, Outlook) doprowadziy do tego, e dzisiaj
przy odrobinie dobrych chci praktycznie w kadym biurze moliwe jest zastosowanie
zasad pracy grupowej wykonywanej w sposb elektroniczny.
Z bada przeprowadzonych wrd uytkownikw Lotus Notes przez firm Andersen
Konsulting najczciej uywan czci oprogramowania pracy grupowej jest poczta
elektroniczna. Rzadziej uywane s grupy dyskusyjne, bazy informacyjne, a najmniej
obieg dokumentw (ang. workflow). W dalszym cigu obserwuje si niech do uywania
bardziej zaawansowanych technik poprawy efektywnoci pracy w zespole.
Narzdzia stosowane do pracy grupowej umoliwiaj wcielenie w ycie idei pracy
zdalnej telepraca, centralnego zarzdzania i kontroli prac grup projektowych, regularnego zabezpieczania ich wynikw, usystematyzowanego rejestrowania i korzystania z wiedzy czonkw zespou. Praca grupowa wymusza na czonkach zespou inicjatyw,
obowizkowo i efektywne gospodarowanie czasem i zasobami i stanowi moe element strategii zarzdzania wiedz i budowy kompetencji.
5. Zarzdzanie ryzykiem
W yciu pewne jest tylko to, e umrzemy i e musimy paci podatki.
B. Franklin
Gdyby wszystko wok byo pewne, niepotrzebne byoby zarzdzanie.
KF
Intuicyjnie ryzyko oznacza moliwo obnienia poziomu sukcesu przedsiwzicia
(do kompletnego braku sukcesu wcznie). Tak wic, na podstawie pojcia ryzyka,
naley odwoywa si do skali wartoci okrelajcej sukces przedsiwzicia (a waciwie brak sukcesu) oraz do okrelonej (niechcianej) sytuacji z tym zwizanej. Dla
poszczeglnych udziaowcw projektu informatycznego ta niechciana sytuacja moe
by rnie zdefiniowana. W przedsiwziciach projektowych wystpuj rwnie zjawiskami, ktre maj lub mog mie wpyw na powodzenie lub negatywne skutki, ale
oprcz uwiadomienia sobie potencjalnych zagroe nie moemy mie na niego
wpyw nie mona nim aktywnie zarzdza te czynniki lub zjawiska to niepewno.
Przytoczymy zatem dwie definicje, jakimi bdziemy si stale posugiwa w dalszej
analizie zagadnienia:
Ryzyko to moliwo, szansa wystpienia niebezpieczestwa, sytuacja niedeterministyczna, w ktrej s okrelone prawdopodobiestwa wystpienia przypadkw,
zarwno pozytywnych, jak i negatywnych. Ryzyko jest zjawiskiem permanentnym.
Niepewno niemono uzyskania informacji, charakteryzuje si brakiem
wpywu na zmian sytuacji niepewno nie podlega ocenie za pomoc prawdopodobiestwa i minimalizacji.
Przykadem ryzyka moe by np. przekroczenie budetu projektu czy nie wykonania projektu w terminie. Niepewno to np. pogoda czy zjawiska globalne, ktre mog
mie wpyw na nasz projekt termin dostawy sprztu komputerowego, a wymienionymi zjawiskami nie moemy zarzdza poniewa nie mamy na nie wpywu.
Na to jak wane jest odpowiednie wstpne oszacowanie ryzyka zwizanego
z projektem mog wskazywa statystyki dotyczce realizowanych projektw informatycznych [44, 50]:
95
47% projektw nie jest nigdy uywana (niezgodna z wymaganiami klienta),

29% jest zapacona, ale nigdy nie wytworzona,
19 % jest zarzucona lub cakowicie przerobiona na nowo,
3% uyte po zmianach,
2% uyte bez zmian.
Statystyki wyranie pokazuj jak niewielki jest odsetek dobrze zrealizowanych
projektw informatycznych oraz jak wiele projektw nie udao si zrealizowa wcale.
Niepowodzenia w realizacji projektu przekadaj si zazwyczaj na ogromne straty
finansowe bd to po stronie zamawiajcego, bd wytwrcy. Straty te rocznie szacowane s w miliardach dolarw (w samym tylko USA). Musimy zatem zada sobie
pytanie, czy w ogle opaca si podejmowanie realizacji projektw obarczonych ryzykiem. Jak ju wspomnielimy wczeniej, kady projekt obarczony jest ryzykiem
i niestety tego faktu nie mona unikn. Gdybymy zatem unikali ryzyka, wwczas
adne projekty nie mogy by by zrealizowane. Jak wida nie tdy droga, gdy dochodzimy do pewnego paradoksu. Oczywicie naley podejmowa si realizacji projektw, gdy s one chociaby motorem postpu tworzymy rzecz now, ale naley stara si w momencie planowania projektu (tworzenia harmonogramu) moliwie
najlepiej oszacowa ryzyko zwizane z projektem oraz zaplanowa akcje zapobiegawcze pozwoli to na sprawn realizacj projektu zgodnie ze stworzonym planem.
Jak wiemy, z ryzykiem moemy mie do czynienia dopiero w momencie, kiedy
wystpuj elementy niemonoci dokadnego szacowania pewnych wartoci zwizanych z otoczeniem projektu oraz jego udziaowcami i tak np. moe to by:
Dla klienta
przekroczenie budetu lub czasu realizacji.
Dla wykonawcy
odmowa klienta uznania systemu za zakoczony.
Dla uytkownika za funkcjonalno, trudny interfejs, nieefektywno
czasowa, wysoka zawodno.
Dla instalatora
niska jako oprogramowania, trudno w dopasowaniu do
rodowiska docelowego, skomplikowana parametryzacja.
O praktyce zarzdzania, zorientowanej na zarzdzanie ryzykiem, wicej mona
znale w pracach [28, 39, 45, 52].
Najwikszym ryzykiem dla projektu jest to, e z opnieniem lub w sytuacji,
kiedy ju wystpuj niekorzystne sytuacje dla projektu, takie jak: przekraczamy
terminy, ponosimy wiksze koszty od zakadanych czy np. uytkownik naszego
systemu nie przyj etapu zrealizowanych dla niego prac przystpujemy do usuwanie zagroe. Obrazowo przedstawia to rysunek 5.1 Toba Gilba. To, e takie
sytuacje mog wystpi prawie w kadym projekcie jest oczywiste, ale przyjcie
tego jako realne, e moe to nastpi w naszym projekcie i e naley wczeniej zastanowi si co bdziemy robili, aby do tego nie doszo lub jakie dziaania przedsiwzi wczeniej, nie jest powszechnie akceptowalnym dziaaniem. Wynika to
z faktu, e prace profilaktyczne zajmuj czas, angauj zasoby i kosztuj, czyli
najczciej podraaj realizacj projektu w sytuacji, gdy wierzymy, e nastpi wy-
96
cznie korzystne przypadki ryzyka. Czsto wymagane jest scharakteryzowanie

elementu ryzyka za pomoc pojedynczej wartoci liczbowej, co pozwala na ich bezporednie porwnywanie i uszeregowanie. Ryzyko jest funkcj, ktrego atrybuty
moemy zdefiniowa przez: zdarzenia, prawdopodobiestwo ich wystpienia oraz
konsekwencje skutki, ktre mog nastpi w wyniku wystpienia zdarzenia (korzystnego lub niekorzystnego).
Jeeli TY nie zaatakujesz ryzyka...
..... ryzyko zaatakuje Ciebie!!! Tob Gilb
Rys. 5.1. Rnica w podejciu do ryzyka w zalenoci od fazy realizacji projektu
97
Definicja podstawowa ryzyka:

Ryzyko = P(z) S(z)
gdzie:
z element ryzyka,
P(z) prawdopodobiestwo wystpienia z,
S(z) miara skutku wystpienia z, wyraana zazwyczaj szacunkowym kosztem lub
wartoci z przyjtej skali.
Celem zarzdzania ryzykiem jest utrzymanie odpowiedniego stopnia gwarancji odnonie do sukcesu przedsiwzicia. Poziom tego ryzyka, ktry w projekcie jest dopuszczalny, zaleny jest od wielu czynnikw zarwno zewntrznych, jak i wewntrznych. S
projekty, w ktrych rne jego elementy mog by krytyczne i poziom ryzyka musi by
ograniczony do wartoci bliskiej zeru. Takim przykadem moe by realizacja np. projektu do obsugi wyborw lub referendum z wykorzystaniem podpisu elektronicznego na
dzie 06.06.2004. Opnienie, wyduenie czasu realizacji projektu np. z 285 dni do
286, kiedy to moe znaczy oddanie w peni sprawnego systemu informatycznego na
dzie 07.06.2004 (opnienie tylko o 1 dzie) jest katastrof dla tego projektu.
Jak wspomniano ryzyko mona redukowa (minimalizowa) do poziomu oczekiwanego (akceptowalnego), a w niektrych przypadkach okrelone obszary ryzyka
eliminowa.
Metoda obliczania wpywu redukcji ryzyka RRL (ang. Risk Reduction Leverage):
RRL =
RVb RVa
RRC
gdzie:
RVb faktyczna warto ryzyka,
RVa oczekiwana warto ryzyka po akcji redukcji ryzyka,
RRC koszt redukcji ryzyka.
Metoda ta ma bardzo istotne znaczenie, poniewa w sposb ilociowy wymierny
szacuje koszty zwizane z redukcj (obnieniem) poziomu ryzyka.
Kady projekt ma swoj specyfik, a z tym zwizane ograniczenia i trudnoci oceny oraz zwymiarowania ryzyka. W projektach informatycznych mamy do czynienia
z du dynamik zmian technologii, brakiem danych o podobnych przedsiwziciach,
nieporwnywalnymi kwalifikacjami oraz kompetencjami zespou. Do gwnych elementw specyfiki projektw informatycznych nale:
Specyfika oprogramowania
zdominowanie przez proces projektowania,
trudnoci w wizualizacji,
98
oprogramowanie nie zuywa si fizycznie tylko moralnie,

dua zoono,
dowolno struktury (twrczo projektanta, programisty),
zaleno elementw,
brak naturalnych ogranicze,
atwo zmian.
Na czym polega specyfika projektw informatycznych?
wymiar projektu (czas, budet i funkcjonalno),
interdyscyplinarno,
brak wczeniejszych dowiadcze,
zmienno (Phanta rei),
rola i znaczenie defektw (tylko ten si nie myli, kto nic nie robi),
ustalenie celw i zakresu systemu,
intensywno komunikacji.
Nakad pracy zwizany z rozmiarem projektu nie jest liniowy (patrz rys. 2.5), ponadto wiele prac, ktre realizuje zesp projektu informatycznego przez duszy czas
jest niewidoczny. Dopiero pokazanie uytkownikowi projektu w fazie interfejsu (komunikacji z systemem) powoduje weryfikacj lub zmian zaoe.
Dlaczego nie potrafimy tworzy systemw informatycznych?
...gdybymy budowali domy tak, jak tworzymy systemy informatyczne,
to nie potrafilibymy wybudowa domu wyszego ni 50 piter,
za ponad poowa wieowcw o wysokoci ponad 20 piter
waliaby si zaraz po wybudowaniu.
Capers Jones Applied Software Measurement
Dlaczego projekty si nie udaj, co gwnie o tym decyduje?
Rozmiar projektu przekraczajcy umiejtnoci zarzdzania.
Strategia nieadekwatna do rodzaju projektu.
Niewystarczajce wsparcie projektu przez sponsora i kierownictwo firmy wykonawczej.
Wsppraca z klientem niewystarczajca.
Analiza systemowa powierzchowna.
Sztywna infrastruktura pracy.
Jako ograniczano z uwagi na czas i koszty.
99
Planowanie i nadzorowanie projektu.

Niekonsekwentne zarzdzanie zmianami.
Zarzdzanie ludmi oraz komunikacja.
Zarzdzanie ryzykiem najczciej bez wczeniejszej analizy i specyfikacji zada
zapobiegawczych.
Rys. 5.2. Czy wystarczy tylko wskazywa na ryzyko
Jak wida na rysunku 5.2 zarzdzanie ryzykiem nie moe sprowadza si wycznie to
uwiadamiania, eby by ostronym w dziaaniach. Sam fakt uwiadamiania sobie ryzyka, tego co moe nas spotka, moe by niewystarczajcy. Istotne s dziaania planowe
zwizane ryzykiem, zakomunikowanie ich wyszemu kierownictwu, wspdzielenie odpowiedzialnoci za sukces projektu ze sponsorem, delegowanie uprawnie i inne.
5.1. Czynniki majce wpyw na ryzyko

Harmonogramy prac s zwykle bardzo napite, budet szczegowo rozpisany,
a wykorzystanie zasobw wysoce zoptymalizowane. Kiedy ryzyko staje si problemem, trzeba nagle znale rodki do jego rozwizania. Odbija si to na terminowoci
oraz koszcie projektu. Gdyby przeprowadzono wstpn analiz ryzyka, wwczas moe udaoby si oszacowa jego skutki i zastosowa najprostsz strategie jego eliminacji lub ograniczenia przez dodanie do kosztorysu i harmonogramu marginesu bezpieczestwa na obsug pojawiajcych si problemw. Oto jakie cechy projektu mog
zadecydowa o jego sukcesie lub klsce.
100
Wsplna wizja produktu (systemu)

Powodzenie projektu powinno by wspln trosk wszystkich udziaowcw projektu.
Praca zespoowa
Bardzo wanym aspektem pracy zespoowej jest zaangaowanie przyszego uytkownika systemu. Nikt tak jak on nie zna przyszego rodowiska pracy systemu.
Mylenie przyszociowe
Zarzdzanie ryzykiem koncentruje si na wczesnym wykryciu moliwego ryzyka i dziaaniach prewencyjnych, nie za na usuwaniu skutkw powstaych problemw.
Komunikacja
Wymiana informacji midzy wszystkimi poziomami powinna by swobodna. Dotyczy to zarwno informacji o rozpoznanym ryzyku, jak i przyjtej strategii jego minimalizacji. Kady musi by odpowiedzialny za informowanie o wszystkim, co moe
zakci realizacj projektu. Rol kierownika projektu jest stworzenie struktury komunikacyjnej.
Zintegrowane zarzdzanie
Zarzdzanie ryzykiem jest czci zarzdzania projektem, dlatego musi by traktowane integralnie z innymi dziaaniami wspierajcymi. Znalezienie wszelkich moliwych rde ryzyka i skuteczna minimalizacja jego skutkw powinna stanowi jeden
z podcelw projektu.
Cigo procesw
Na kadym etapie projektu ryzyko musi by na nowo rozpoznane i oszacowane.
Dobr praktyk jest wpisanie do harmonogramu projektu czstego przegldu ryzyka
projektu.
Stopie ryzyka zwizany z wdraaniem systemw informatycznych
Okrela si go najczciej wedug osignitych rezultatw realizacyjnych:
przerwanie realizacji dziaa lub fiasko podjtego przedsiwzicia,
uzyskanie rezultatw, ktre nie speniaj wymaga funkcjonalnych czy jakociowych systemu (np. przeduenie czasu realizacji, zwikszenie kosztw, zawodno funkcjonowania, pominicie problemw bezpieczestwa itp.),
ujawnienie istotnych wad w trakcie eksploatacja systemu.
Kategorie ryzyka
1. Ryzyko organizacyjne, ktre wynika z :
niejednoznacznie okrelonych celw i wizji jednostki,
niewaciwych relacji w zakresie uprawnie i odpowiedzialnoci,
101
niezdolnoci do wprowadzeni zmian organizacyjnych,

braku waciwych procedur organizacyjnych,
niesprawnoci mechanizmw kontrolnych,
nieumiejtnoci pracy zespoowej,
braku okrelenia celu informatyzacji,
niedostatecznej znajomoci moliwoci i ogranicze informatycznego wspomagania zarzdzania w przedsibiorstwie oraz brak zaangaowania jego kierownictwa,
nieadekwatno stosowanej technologii informatycznej do rzeczywistych potrzeb
i moliwoci przedsibiorstwa,
brak zdolnoci przedsibiorstwa do zmiany lub niech do jej wprowadzenia
i zamiar wykorzystania technologii informatycznej jako jej substytutu,
niezdolno do przyswajania nowej technologii informatycznej w zakresie przetwarzania danych,
brak dostatecznej motywacji przyszych uytkownikw rozwizania informatycznego,
ograniczone zasoby realizacyjne przedsiwzicia,
niedostateczna umiejtnoci i dowiadczenie realizatorw systemu,
niesprawna organizacja zespou projektowo-wdroeniowego,
wykorzystanie odpowiednich metod, technik i narzdzi informatycznych,
pojawienie si nowych, nieprzewidzianych czynnikw w otoczeniu.
2. Ryzyko psychospoeczne okrelane przez:
niech do wprowadzania zmian organizacyjnych,
nieumiejtno celowego zastosowania technologii informatycznej,
niska kultura informatyczna.
3. Ryzyko techniczno-technologiczne okrelane przez:
niski poziom w zakresie infrastruktury informatycznej,
wykorzystywanie niewaciwej technologii informatycznej.
Praktyka ignorowania zagroe z pierwszej kategorii powoduje, e w krajowych wdroeniach zintegrowanych systemw informatycznych nastpuje wzrost
kosztw o 200300% oraz wyduenie terminw realizacji projektw o 100200%.
Waciwa ocena ryzyka sprowadza si do jego identyfikacji, a nastpnie opisu,
samo uwiadomienie sobie ryzyka nie wystarcza. Analiza musi dotyczy opisanych
zagroe list kontrolnych oraz prognozowanego rozmiaru, skutkw jakie dane
zagroenie bdzie miao dla projektu oraz w jakiej jego fazie, jak rwnie jakimi
symptomami ryzyko bdzie si przejawia. Wane jest te skupienie si na istotnych zagroeniach, aby analiza bya pomocna w uruchamianiu dziaa zapobiegawczych.
102
5.2. Identyfikacja ryzyka metody analizy ryzyka

kwestionariusze, listy kontrolne
Identyfikacja ryzyka moe odbywa si wedug okrelonych metod, ktre s preferowane w danej organizacji, ktra realizuje projekt. Najczciej wybrane metody analizy s adaptowane do potrzeb i specyfiki projektu, mona je podzieli oglnie na:
analiz subiektywn,
analiz wspomagan listami kontrolnymi i kwestionariuszami,
analiz wstpujc,
analiz zstpujc.
Kwestionariusz identyfikacji ryzyka projektu
Obszar kontaktw z klientem/uytkownikiem
Umowy
Jak jest skonstruowana umowa?
Jaka jest wymagana dokumentacja?
Jak okrelono standardy wykonania?
Czy dokonano przegldw umowy?
Wymagania
Czy uytkownik uczestniczy w ustalaniu wymaga?
Obszar rodowiska organizacyjnego projektu
System projektowania
Czy dostpna jest wystarczajca liczba stanowisk pracy?
Czy system pozwala na realizacj wszystkich krokw cyklu ycia
projektu?
Czy organizacja projektu jest efektywna?
Obszar zarzdzania projektami
Zarzdzanie
Czy projekt jest realizowany zgodnie z planem?
Czy oszacowania s wiarygodne?
Jakie jest dowiadczenie kierownika projektu?
Obszar inynierii oprogramowania
Wymagania
Czy wymagania zmieniaj si?
Jaki ma to wpyw na jako, funkcjonalno, projekt ...?
Czy s wymagania, ktrych nie ma w specyfikacji?
Projekt
Czy s specyficzne, trudne algorytmy do wdroenia?
Czy projekt opiera si na racjonalnych zaoeniach?
Czy zdefiniowano wszystkie interfejsy wewntrzne i zewntrzne?
Testowanie:
Czy jest wystarczajco duo czasu do przeprowadzania wszystkich testw?
Czy przygotowano plany testowania?
Jakie jest dowiadczenie zespou testujcego?
103
Obszar dziaa testujcych

Kontrola jakoci:
Czy zdefiniowano atrybuty jakoci produktu?
Czy istnieje system kontroli jakoci?
Czy prowadzone s zapisy jakociowe?
Szkolenia:
Czy pracownicy maj odpowiednie kwalifikacje?
Czy pracownicy przeszli odpowiednie szkolenia?
W tabeli 5.1 wyspecyfikowano czynniki rnicujce analiz ryzyka metod wstpujc i zstpujc.
Tabela 5.1. Porwnani analizy ryzyka zstpujcej i wstpujcej
Analiza
zstpujca
Analiza
wstpujca
Przegldanie list kontrolnych, zawierajcych spis potencjalnych zagroe

i odnoszenie tych zagroe do obecnej sytuacji
Analiza sytuacji biecej pozwala ograniczy liczb rozpatrywanych zagroe
Wykorzystanie list kontrolnych w celu utrzymania waciwego zakresu analiz
Ocena sytuacji obecnej i wskazanie moliwych negatywnych skutkw w przyszoci
Moliwo wystpienia przeocze oraz wykroczenia poza przewidziany zakres analiz
Czynniki wane podczas tworzenia list kontrolnych

Listy kontrolne s do powszechnie stosowan metod identyfikacji ryzyka. Wiele
firm ma wasne listy czynnikw ryzyka (np. firmy konsultingowe, wytwarzajce oprogramowanie, wdroeniowe), kwestionariusz z 194 pytaniami proponuje firma Software
Engineering Institute, ale s rwnie listy publikowane w literaturze jak np. 60 czynnikw
ryzyka Capersa Jonesa, Complete List of Schedule Risks Stevea McConnella [37]. Listy
kontrolne uzupenione specjalnymi szablonami, s stosowane w trakcie wsplnych sesji
identyfikacji ryzyka przez burz mzgw. Podstaw tworzenia list kontrolnych identyfikacji ryzyka w zakresie procesu wytwrczego oprogramowania s: aktywno, rola, jak
peni w projekcie wykonawcy oraz tworzone produkty (artefakty). Po uwzgldnieniu
jednak aktywnoci procesu wytwrczego zwizanego z oprogramowaniem, list naley
rozszerzy poprzez specyfikacj w nastpujcych obszarach:
czynnikw charakterystycznych dla efektywnoci aplikacji,
czynnikw ludzkich,
metod projektowych,
czynnikw programowych/sprztowych,
czynnikw zmiany,
czynnikw dostawy,
czynnikw rodowiskowych,
zabezpieczenia finansowego,
odpowiedzialnoci i stabilnej postawy partnera.
104
Stworzenie penej listy kontrolnej stanu pocztkowego projektu oraz opracowanie

formularzy raportowania parametrw stanowicych zidentyfikowane obszary ryzyka
to rutynowe elementy zarzdzania ryzykiem.
Inne czynniki wane podczas tworzenia list kontrolnych
W tej grupie zagadnie naley uwzgldni warunki i rodowisko oraz charakterystyk projektu:
otoczenie socjologiczno-ekonomiczne,
otoczenie technologiczne,
organizacja realizacji projektu,
lista twrcw SI,
projekt.
Strategie postpowania z ryzykiem
Podstawowe dziaania, jakie moemy zastosowa w przypadku, gdy zidentyfikowalimy ryzyko tworzylimy listy:
obnienia ryzyka,
uniknicia ryzyka,
transfer ryzyka,
zaakceptowania ryzyka.
Wyjanienia wymaga tzw. transfer ryzyka, chodzi o to, aby w projekcie ustanowi
waciwe relacje i wspodpowiedzialno sponsora za terminowe dostarczenie, np. zaoe, analiz itd., aby zamawiajcy opracowanie systemu informatycznego wyznaczy osob (zesp), ktra bdzie akceptowaa produkty czciowe powstajce w trakcie projektu.
5.3. Akcje naprawcze

Akcje
bezwarunkowe
Akcje
awaryjne
Jeli ryzyko moe by obnione przez natychmiastowe dziaania

podejmowane w stosunku do wpywajcych na nie czynnikw
Jeli poziom ryzyka wymaga ledzenia i jeeli zaistnieje taka
potrzeba podjcia odpowiednich dziaa naprawczych
Przygotowanie planu awaryjnego obejmuje:

okrelenie istoty potencjalnego problemu,
rozwaenie alternatywnych sposobw rozwizania problemu,
okrelenie ogranicze, w ramach ktrych problem bdzie rozwizywany,
analiza alternatywnych rozwiza,
wybr jednej z alternatyw.
105
Plan postpowania awaryjnego zawiera:

identyfikacj zagroe, ktrych dotyczy,
metod ledzenia ryzyka zwizanego z tymi zagroeniami,
przypisanie odpowiedzialnoci za ledzenie ryzyka i realizacj planu do czonkw zespou,
warunki uruchomienia planu,
przydzia zasobw do wykonania planu,
ograniczenia zwizane z opracowaniem planu.
Najwikszym nieporozumieniem w zarzdzaniu ryzykiem jest podejcie, ktre polega jedynie na dziaaniach zmierzajcych do uniknicia ryzyka !
5.4. Metoda punktowa szacowania ryzyka

Policz to co mona policzy, zmierz to co mona zmierzy,
a to co niemierzalne uczy mierzalnym.
Galileo Galilei
Wychodzc naprzeciw tezie, e analiza ryzyka musi by mierzalna, wymagane jest
scharakteryzowanie elementu ryzyka za pomoc pojedynczej wartoci liczbowej, co
umoliwia ich bezporednie porwnywanie i uszeregowanie.
Ryzyko dla wikszoci projektw mona wydzieli ze wzgldu na charakter zada,
ktre realizowane s w projekcie na kategorie. Najbardziej typowe kategorie ryzyka,
ich wagi oraz wartoci ryzyka przedstawiono w tabelach 5.2 i 5.3.
Tabela 5.2. Kategorie ryzyka
Kategoria
techniczna
organizacyjna
finansowa
zewntrzna
Waga
3
4
5
4
.
Tabela 5.3. Wartoci ryzyka
Warto
1
2
3
4
5
Znaczenie
pomijalne
niskie
rednie
wysokie
katastrofalne
106
Szacowanie ryzyka metod punktow polega na identyfikacji zada zagroonych

ryzykiem niepowodzenia realizacji oraz przydzielenie im ilociowej miary poziomu
ryzyka wedug przyjtej skali. Zadania projektu zakwalifikowane jako ryzykowne s
grupowane do okrelonej kategorii, np. organizacyjne. Za pomoc poniszych zalenoci s definiowane poszczeglne wskaniki ryzyka.
W tabeli 5.2 przydzielono subiektywnie dla poszczeglnych kategorii ryzyka wartoci wag. Waga ma stanowi ogln ocen wanoci gwnego zagroenie ocenianego nie z poziomu poszczeglnych zada, lecz caego projektu. Wagi wprowadzamy
w celu moliwoci przeszacowania wartoci ryzyk w poszczeglnych kategoriach
oraz caego projektu. To przeszacowanie nazywane jest normalizacj. Do obliczenia
wartoci ryzyk dla poszczeglnych kategorii przed i po podjciu akcji zapobiegawczych oraz wartoci ryzyka cakowitego posugujemy si wzorami:
ryzyko nieznormalizowane kategorii
Rx =
ryzyko znormalizowane kategorii
Rzn _ x =
Rx wx
,
wsr
ryzyko nieznormalizowane cakowite
Rcalk =
ryzyko znormalizowane cakowite
zn _ x
Rzn_calk =
gdzie:
n
Rv
k
wx
liczba zada nalecych do danej kategorii,

warto ryzyka dla zadania nalecego do danej kategorii,
liczba kategorii,
waga ryzyka kategorii,
wx
x
wsr rednia warto wagi wyliczana ze wzoru wsr =
.
k
Zadaniem normalizacji jest wyrwnanie skrajnych i subiektywnych oce zagroe
ze strony bezporednich wykonawcw, kierownikw zespow czy niekiedy samego
107
kierownika projektu. Powysze wskaniki liczymy przed konfliktem po wprowadzeniu akcji zapobiegawczych, aby oceni czy ograniczylimy ryzyko projektu do poziomu akceptowalnego przez sponsora projektu (komitet sterujcy).
Jeli zadania wyspecyfikowane dla okrelonego projektu maj okrelony czas trwania, przypisane zasoby do ich realizacji, to kolejnym etapem jest identyfikacja tych zada, ktrych wykonanie zagroone jest ryzykiem, nastpnie oceni, do jakiej kategorii
ryzyka to zadanie naley. Przeanalizowanie ryzyko pod ktem objaww, ktrym bdzie
si charakteryzowao dane ryzyko, tj. symptomy, jakie mog przepowiada, e zagroenie wystpio lub zaczyna faktycznie uaktywnia si w projekcie. Opis ryzyka jest zwizany z tym, czego chcemy unikn lub ograniczy w projekcie. Jeli zadania np. wprowadzone s w MS Projekt, to moemy kolumn z kolejnym nr zadania oraz nazw
zadania przenie do arkusza Excell, jak w przykadzie tabeli 5.4. W tabeli 5.4 pozostawiamy tylko zadania, ktre obarczone s ryzykiem z zachowaniem numerw zada ID
zgodnych z projektem gwnym, np. pierwszym zadaniem zwizanym z ryzykiem jest
zadanie 80 analiza, to zadanie naley do kategorii T technicznej i ma warto ryzyka
4 rednie. Kolejnymi zadaniami bdcymi przedmiotem ryzyka to zadania 81, 83, 84,
86 a do zadania 155 szkolenie uytkownikw. W tabeli 5.5 wprowadzamy akcje
zapobiegawcze minimalizujce (ograniczajcych) ryzyko zada. W tej tabeli szacujemy
koszty wprowadzonych akcji zapobiegawczych, nastpnie skutki na zadanie, jak rwnie
stopie ograniczenia wartoci ryzyka oraz prawdopodobiestwo wystpienia.
Przykad
Szacowanie ryzyka metod punktow projektu WIGGOR
Tabela 5.4. Zidentyfikowane rodzaje oraz wartoci ryzyka dla wybranych zada
ID
Nazwa zadania
80 Analiza
Kat.
T
81 Modelowanie
83 Analiza
84 Modelowanie
86 Analiza
Wart.
Objawy
Opis ryzyka
4
Brak informacji lub
Niedokadnie lub nieprawiinformacje niekompletne dowo przeprowadzona
analiza
4
Czonkowie stowarzy- Model nie odzwierciedla
szenia zgaszaj braki rzeczywistoci lub jest
w procedurach
niekompletny
4
Brak informacji lub
analiza
4
Czonkowie stowarzy- Model nie odzwierciedla
szenia zgaszaj braki rzeczywistoci lub jest
w procedurach
niekompletny
4
Brak informacji lub
analiza
108
87 Modelowanie
Czonkowie stowarzyszenia zgaszaj braki

w procedurach
Brak dokumentu
z opracowaniem procedur w terminie
Brak ankiet w terminie
88 Integracja opracowanych
procedur
92 Przeprowadzenie ankiet
wrd studentw
94 Wywiady z czonkami
stowarzyszenia
97 Projekt graficzny
98 Projekt funkcjonalny
99 Projekt bazy danych
102 Wywiady z czonkami

stowarzyszenia
104 Projekt graficzny
105 Projekt funkcjonalny
106 Projekt bazy danych
Programici skar si,

e nie maj wszystkich
informacji
Programici czsto
prosz o wprowadzanie
zmian w schemacie
bazy danych
110 Budowa sieci
Brak sprztu
111 Instalacja serwera
Brak serwera
112 Instalacja stacji roboczych

w sieci
117 Modu Dokumenty
Brak stacji roboczych
Brak moduu na czas
118 Modu Aktualnoci
Brak moduu na czas
Brak wynikw rozmw

w terminie
Brak projektu w terminie
Programici skar si,

e nie maj wszystkich
informacji
Programici czsto
prosz o wprowadzanie
zmian w schemacie
bazy danych
Brak wynikw rozmw
w terminie
Brak projektu w terminie
Model nie odzwierciedla

rzeczywistoci lub jest
niekompletny
Procedury nie s spjne
Maa frekwencja, trudno

z zebraniem odpowiedniej
prby
Nie mona dotrze do odpowiednich osb
Grafik przydzielony do
innych prac zleconych przez
stowarzyszenie
Projekcie nie specyfikuje
wszystkich zgoszonych
wymaga
W projekcie bazy danych nie
s odzwierciedlone wszystkie zwizki wystpujce
w rzeczywistoci lub brakuje
pewnych pl w tabelach
Nie mona dotrze do odpowiednich osb
Grafik przydzielony do
innych prac zleconych przez
stowarzyszenie
Projekcie nie specyfikuje
wszystkich zgoszonych
wymaga
W projekcie bazy danych nie
s odzwierciedlone wszystkie zwizki wystpujce
w rzeczywistoci lub brakuje
pewnych pl w tabelach
Sponsorzy nie dostarczaj
sprztu lub s opnienia
w przelewach pienidzy
Sponsorzy si wycofali lub
sprzt nie dotrze na czas
Sponsorzy si wycofali lub
sprzt nie dotrze na czas
Problem z doczaniem
i pozycjonowaniem zdj
w obrbie dokumentw
Nie gotowy modu dokumentw
121 Modu Subskrypcja
125 Modu Rekrutacja
129 Wprowadzanie danych
133 Szkolenie z CMS
142 Modu I-Mail
144 Modu Tablica ogosze
149 Wprowadzenie danych
154 Szkolenie administratorw
155 Szkolenie uytkownikw
109
Brak moduu na czas
Brak dostpu do serwera

SMTP
Brak moduu na czas
SMTP
System nie gotowy do Brak wszystkich materiatestw akceptacyjnych w, ktre maj by zamieszczone na stronie
Opnienia w szkoleniu Trudnoci z zebraniem ludzi
na czas szkolenia
Brak moduu na czas
SMTP
Brak moduu na czas
SMTP
System nie gotowy do Brak wszystkich materiatestw akceptacyjnych w, ktre maj by zamieszczone na stronie.
na czas szkolenia
na czas szkolenia
Tabela 5.5. Wprowadzanie akcji zapobiegawczych minimalizujcych (ograniczajcych) ryzyko zada

ID
80
83
86
81
84
87
88
Akcja zapobiegawcza
Szkolenie wewntrzne nt. metodologii prowadzenia analizy
procesw
Szkolenie wewntrzne nt. metodologii modelowania procesw
2 spotkania w trakcie procesu
modelowania
92 Przeprowadzenie akcji ankietowej podczas rekrutacji oraz

Targowiska
94 Przeprowadzenie ankiet lub
burzy mzgw podczas spotkania oglnego oraz wyjazdu
integracyjnego
97 zamwienie projektu na zewntrz stowarzyszenia
98 weryfikacja projektu przez innego czonka zespou w trakcie
jego tworzenia
(wewntrzny audyt)
Koszt
1500
Kat.
T
Wart.
2
1500
500
Prawd.
Skutki
0,7
dokadniejsze wykonanie
fazy modelowania, mniej
bdw w opracowaniach
0,7
dokadniejsze wykonanie
fazy modelowania, mniej
bdw w opracowaniach
0,25
wykrycie i wyeliminowanie niespjnoci w trakcie
modelowania
0,7
Uatwienie organizacyjne
dotarcia do studentw,
wiksza frekwencja
0,7
Wykonanie wywiadw na
czas, bo bdzie dostp do
wikszoci czonkw stowarzyszenia
0,7
projekt graficzny na czas
0,25
wyeliminowanie wikszoci niedopatrze
110

jego tworzenia
(wewntrzny audyt)
102 Przeprowadzenie ankiet lub
burzy mzgw podczas spotkania oglnego oraz wyjazdu
integracyjnego
104 zamwienie projektu na zewntrz stowarzyszenia
jego tworzenia
jego tworzenia
110 Spotkania z dodatkowymi sponsorami (rezerwowe rdo)
117 Dodatkowe testy technologii
118 przed przystpieniem do prac
implementacyjnych
121 Ustalenie dodatkowego serwera
testowego w innym miejscu (np.
na uczelni)
na uczelni)
129 Opracowanie czci materiaw
na wyjedzie strategicznym
133 2 dniowy wyjazd szkoleniowo
154 rekreacyjny do Srebrnej Gry
155
na uczelni)
na uczelni)
149 Opracowanie czci danych
(materiaw) na wyjedzie strategicznym
SUMA
0,25
0,7
500
0,4
Wykonanie wywiadw na
czas, bo bdzie dostp do
wikszoci czonkw stowarzyszenia
projekt graficzny na czas
0,25
0,25
100
0,7
100
0,7
100
0,7
0,25
0,4
Wiksza pewno otrzymania sprztu w terminie

Zapoznanie si z moliwociami i atwiejsza implementacja moduw
Moduy i testy na czas
0,4
0,25
Materiay na czas
1000
0,25
szkolenie przeprowadzone
w terminie
3
2
3
3
0,4
0,4
0,25
5300
Materiay na czas
111
Zaproponowane akcje zapobiegawcze zmniejszaj ryzyko nieznormalizowane z 3,39

do 2,38, a znormalizowane z 3,36 do 2,36. Jest to zmiana o ponad jeden rzd (z ponad
redniego ryzyka do ryzyka maego). Koszt dodatkowy, jaki bdzie trzeba ponie
z uruchomieniem zada zwizanych z akcjami zapobiegawczymi, to 5300 z. Naley
zauway, e wikszo akcji zapobiegawczych jest zwizana z inn organizacj pracy
lub wykorzystaniem innych dziaa organizacji mogcych uatwi wykonanie projektu.
Te akcje nie pochaniaj dodatkowych rodkw finansowych a jedynie sposb wykorzystania dostpnych zasobw oraz poszerzenie jakoci i czstotliwoci kontroli.
Tabela 5.6. Zbiorcze zestawienie ryzyka w poszczeglnych kategoriach
nieznormalizowane i znormalizowane przed i po akcji zapobiegawczej
Kategoria
ryzyka
Waga
Techniczne
Organizacyjne
Finansowe
Zewntrzne
Cakowite
3
4
5
4
4
Nieznormalizowane
przed akcj
3,13
3,86
4,00
2,57
3,39
po akcji
2,17
2,20
2,57
2,57
2,38
Znormalizowane
przed akcj
2,02
3,86
5,00
2,57
3,36
po akcji
1,27
2,48
3,75
1,93
2,36
Zestawienie podstawowych wskanikw zmierzonego ryzyka przedstawia tabela

5.7, w ktrej przedstawione s cakowite wartoci ryzyka oraz przewidywane skutki
procesu zarzdzania ryzykiem projektu WIGGOR.
Tabela 5.7. Szacunek ryzyka projektu WIGGOR
Lp.
1
2
3
4
5
Informatyzacja WIGGOR
Ryzyko projektu
Ryzyko znormalizowane
Koszt akcji zapobiegawczych
Ryzyko projektu po akcjach zapobiegawczych
Ryzyko znormalizowane po akcjach zapobiegawczych
Warto (z)
3,39
3,36
5 300
2,38
2,36
Ostateczn decyzj dotyczc wprowadzenia akcji zapobiegawczych zmniejszajcych (ograniczajcych ) ryzyko podejmuje PM, a w przypadku gdy projekt ma ograniczony budet i poziom ryzyka projektu jest akceptowalny, dla sponsora mog nie by
wprowadzane niektre dziaania. W powyszym przykadzie 5300 z stanowi zwikszenie budetu projektu o ok. 2% (cakowity budet projektu wynosi 220 000 z). Jeliby
koszty wprowadzenia akcji zapobiegawczej, ograniczajcych ryzyko stanowiy 10% lub
wicej budetu projektu, to sprawa staje si bardziej zoona i wymaga niejednokrotnie
dodatkowych negocjacji ze sponsorem oraz komitetem sterujcym projektu.
112
Zadanie 5.1
7 wrzenia 2003 w dniu kontroli projektu, kierownik programistw poinformowa
kierownika projektu, e zadanie nr 4 Implementacja elementw interfejsu przeduy
si. Jest to dzie, w ktrym zadanie to powinno by zrealizowane w okoo 50%. Po
oszacowaniu dotychczas zrealizowanych prac kierownik programistw stwierdzi, e
prace s zrealizowane jedynie w okoo 25%, co przekaza menederowi projektu
w postaci raportu. Informacja ta po wprowadzeniu do programu Microsoft Projekt
pokazaa, e projekt jest opniony i skonia kierownika projektu do przeprowadzenia
analizy metod Earned Value.
Wykresy (rys. 3.9) przedstawiaj rnice midzy harmonogramem wczeniej zaplanowanym (szary) a pokazujcym obecn sytuacj (czerwony). Zadanie zaplanowane byo na okoo 2500 h. Poniewa w poowie jego realizacji kierownik programistw oceni, e zadanie jest zrealizowane w okoo 25%, a ich obecny czas
realizacji wynosi bdzie okoo 5000 h. Pozostae zadania 1, 2 trwaj odpowiednio
140 dni, zadanie 3 3 dni.
Zadania
1
2
3
4
Rys. 3.9. Rnice midzy harmonogramem planowanym a obecnym

Zad. 1. Implementacja, Zad. 2. Konsultacje i doradztwo, Zad. 3. Nadzr zada,
Zad. 4. Implementacja elementw interfejsu
Oblicz ryzyko dla zada projektu, rozpisujc zadania gwne 14 do zada czstkowych, np. kade zadanie podziel na 2 podzadania. Zaplanuj akcje zapobiegawcze
i oblicz ryzyko (cakowite bez normalizacji i znormalizowane) metod punktow dla
tego projektu, zakadajc, e zadania 1 i 4 s kategorii ryzyka wewntrznego, a zadania 2 i 4 nale do kategorii ryzyka zewntrznego. Waga dla ryzyka wewntrznego
rwna si 4, a dla zewntrznego 1.
Oblicz ryzyko:
1. Dla poszczeglnych kategorii.
2. Cakowite podanych zada.
3. Ryzyko znormalizowane wymienionych zada.
113
5.5. Metoda PERT szacowania ryzyka

Technika PERT (ang. Program Evaluation and Review Techinque) zostaa stworzona
w celu oszacowania przyblionych czasw trwania realizacji aktywnoci/zada oraz wyznaczenia prawdopodobiestwa zakoczenia tych aktywnoci/zada w danym czasie.
Przez aktywno naley rozumie wydzielon czynno realizowanych najczciej
przez pojedynczego czonka zespou projektowego. Przyjmuje si, e dekompozycja
projektu na aktywnoci zmierza do realizacji zada, ktrych realizacja zamykaa si
w przedziale kilku dni. Dusze aktywnoci mog zamiennie przechodzi w zadania.
Metoda PERT zostaa stworzona na potrzeby kosztownych projektw, ktrych stopie
ryzyka by wysoki. Jest bardzo prosta w stosowaniu, a jednoczenie bardzo efektywna
[10, 44, 48]. Gwny trzon algorytmu szacowania stanowi trzy nastpujce kroki.
Algorytm szacowania czasu realizacji projektu
Oszacowanie czasu realizacji pojedynczej aktywnoci ta okrela si wzorem:
ta =
a + 4m + b
6
gdzie:
m najbardziej prawdopodobny czas wykonania aktywnoci,
a optymistyczny, czyli najkrtszy spodziewany czas wykonania aktywnoci,
b pesymistyczny, czyli najduszy spodziewany czas wykonania aktywnoci.
Obliczony w ten sposb czas ta poszczeglnych aktywnoci wykorzystuje si do
obliczania czasu trwania projektu i wyznaczania jego cieki krytycznej.
Obliczenie odchylenia standardowego aktywnoci s jest miar stopnia niepewnoci oszacowania czasu tz trwania aktywnoci i dane jest wzorem:
s=
ba
.
6
Moe by stosowane jako miara porwnawcza stopnia niepewnoci lub ryzyka

kadej aktywnoci.
Wyznaczenie prawdopodobiestwa osignicia celw zakoczenia (waciwie
niezakoczenia) danego zadania w ustalonym czasie T, naley:
a) Obliczy czas trwania zadania. Jeeli na dane zadanie skada si kilka aktywnoci, ktre wykonywane s jednoczenie, za czas realizacji zadania przyjmuje si czas
najduszej aktywnoci (patrz przykad).
b) Obliczy standardowe odchylenia zadania. Jeeli na dane zadanie skada si kilka aktywnoci, ktre s wykonywane jednoczenie, standardowe odchylenie obliczane
jest na podstawie najduszej aktywnoci (tej, ktra posuya do obliczenia czasu w
114
punkcie a). Jeeli t aktywno poprzedza inne zadanie, standardowe odchylenie zadania kocowego obliczane jest z wzoru:
s = szad_poprz + sakt .
2
c) Wyznaczy dla zadania warto wspczynnika z ze wzoru:
z=
T t
s
gdzie:
T dana data docelowa zakoczenia zadania,
t czas oszacowany w punkcie a).
Prawdopodobiestwo niedotrzymania terminu [%]
d) Odwzorowa warto z na prawdopodobiestwo, korzystajc z odpowiednich

krzywych zamieszczonych w np. tablicach matematycznych. Krzywa taka moe by
przedstawiona na rysunku 5.3.
100
90
80
70
60
50
40
30
20
10
0
3,25
2,75
2,25
1,75
1,25
0,75
0,25
-0,25
-0,75
-1,25
-1,75
-2,25
-2,75
-3,25
warto z
Rys. 5.3. Odwzorowanie prawdopodobiestwa niedotrzymania terminu w zalenoci od wartoci z
Zalety metody PERT

1. Ustanawiajc daty docelowe zada na ciece krytycznej, zwraca si szczegln
uwag na te zadania, ktre wprowadz do projektu pewne opnienia.
2. Obliczenie standardowego odchylenia zadania i porwnanie go ze stopniem ryzyka kadego zadania pozwoli na wyonienie tych zada, ktre wymagaj szczeglnej opieki.
115
Przykad
Projekt SEZAM skada si z omiu aktywnoci. Oznaczmy je literami AH. Zamy, e eksperci na podstawie swojego dowiadczenia i analizy projektu wyznaczyli czas realizacji poszczeglnych aktywnoci w nastpujcy sposb (patrz tabela
5.8).
Tabela 5.8. Czas trwania poszczeglnych aktywnoci
Czas trwania aktywnoci [tygodnie]
Aktywno
A
B
C
D
E
F
G
H
Optymistyczny
(a)
5
3
2
3,5
1
8
2
2
Najbardziej prawdopodobny
(m)
6
4
3
4
3
10
3
2
Pesymistyczny
(b)
8
5
3
5
4
15
4
2,5
W przypadku okrelenia czasu pesymistycznego bierze si pod uwag wszelkie

niepomylne zdarzenia, ktre mog wystpi w czasie realizacji projektu. Kalkulacje
tego czasu moe uwzgldnia konieczno uruchomienia akcji zapobiegawczej. Jeli
chodzi o czas optymistyczny, to zakada si, e czynniki wpywajce negatywnie na
wykonanie zadania nie wystpi lub nie spowoduj powaniejszych zmian w projekcie, a przede wszystkim obcienia czasowego.
Dla kadej aktywnoci obliczamy oczekiwany czas trwania t oraz odchylenie standardowe s przedstawione w tabeli 5.9. Po obliczeniu widzimy, e oczekiwany czas
aktywnoci A wynosi 6,17 tygodni, a odchylenie standardowe 0,5, aktywno B
odpowiednio 4,00 i 0,33 itd.
Tabela 5.9. Oczekiwany czas trwania oraz odchylenia standardowe poszczeglnych aktywnoci
Aktywno
Oczekiwany czas trwania [tygodnie]
Standardowe odchylenie (s)
A
B
C
D
E
F
G
H
6,17
4,00
2,83
4,08
2,83
10,5
3,00
2,08
0,50
0,33
0,17
0,25
0,50
1,17
0,33
0,08
116
Nasz projekt, zgodnie z grafem zamieszczonym poniej, skada si z 6 zada. Dodatkowo wiemy, e zadanie 4 musi zakoczy si po 10 tygodniach, gdy pracownicy
zaangaowani w realizacj aktywnoci C (poprzedzajcej zadanie) odchodz po tym
czasie do innego projektu. Zadanie 5 take musi zakoczy si po 10 tygodniach, gdy
po tym czasie zobowizalimy si pokaza klientowi prototyp systemu. Zakoczenie
projektu zadanie 6 planowane jest na 15 tydzie.
Zauwamy, e czas trwania aktywnoci F (t = 10,5) jest duy ni suma czasu aktywnoci B i E (t = 4,00 + 2,83 = 6,83), dlatego czas realizacji zadania 5 wynosi
t = 10,5.
Przewidywany czas realizacji zadania 6 to t = 10,5 + 3,00 = 13,5, a standardowe
odchylenie s wynosi:
s = 1,17 2 + 0,332 = 1,22

Przedstawiony graf sieci PERT ukazuje powizanie midzy aktywnociami oraz
zawiera obliczone poszczeglne wartoci. Graf skada si z wzw, ktre opisuj
cztery parametry zadania (czas realizacji zadania, na ktre skadaj si aktywno,
odchylenie standardowe, numer zadania oraz wymagany termin zakoczenia zadania)
oraz ukw, ktrymi s aktywnoci opisane trzema parametrami (nazwa aktywnoci,
oczekiwany czas trwania oraz odchylenie standardowe).
Rys. 5.4. Graf sieci PERT z uwzgldnieniem czasu i obliczonym standardowym odchyleniem
Ostatnim krokiem, zgodnie z algorytmem prezentowanym w punkcie 6.3.1 jest obliczenie wartoci z i odwzorowanie jej na prawdopodobiestwo niedotrzymania terminw poszczeglnych zada. Obliczenia zebralimy w tabeli 6.10, ktra umoliwia na
117
podstawie odczytania z wykresu (rys. 5.3) wartoci prawdopodobiestwa niedotrzymania terminw realizacji poszczeglnych zada w zalenoci od wartoci wspczynnika z.
Tabela 5.10. Wyznaczenie prawdopodobiestwa niedotrzymania terminw realizacji
poszczeglnych zada
Zadanie
Docelowa data
ukoczenia [tygodnie]
Warto z
Prawdopodobiestwo
poraki [%]
1
2
3
4
5
6
10
10
15
1,887
0,427
1,231
4
68
11
Wida, e zadanie 5 ma najwiksze prawdopodobiestwo przekroczenia czasu realizacji i wynosi ono a 68%. Jest to zgodne z naszymi oczekiwaniami, gdy oszacowany czas realizacji (t = 10,5 tygodnia) by wikszy od ustalonego z klientem (T = 10
tygodni data pokazania prototypu sytemu).
6. Projekty wdroeniowe outsourcing

Wdroenie w ramach projektu informatycznego mona zdefiniowa jako: przedsiwzicie majce na celu stworzenie unikatowej usugi lub produktu, wykorzystujce
rozwizania informatyczne, oparte na technologii komputerowej oraz wprowadzce
korzyci biznesowe, popraw funkcjonalnoci lub osignicia nowej jakoci w obszarze jego zastosowania. Przez rozwizania informatyczne rozumiemy metody komputerowego wspomagania przebiegu rnorodnych procesw zarzdczych, ekonomicznych, informacyjnych w firmie, a pod pojciem technologii komputerowej rozumie si
wszystkie aspekty techniczne takich rozwiza (np. sprzt, oprogramowanie).
6.1. Rodzaje projektw informatycznych

oraz organizacja pracy i zespow
Podzia projektw informatycznych ze wzgldu na to, jaki obszar informatyki
obejmuje projekt i czy projekt realizuje zupenie nowe rozwizania, czy te wprowadza nowe elementy do ju istniejcych rozwiza, jest nastpujcy:
nowe podejmowane przedsiwzicie ma zupenie nowy charakter dla organizacji, tj. nie funkcjonuj w niej systemy informatyczne,
uzupeniajce realizowane przedsiwzicie wnosi nowe elementy do ju istniejcych rozwiza (np. rozbudowa sieci komputerowej),
programowe projekt dotyczy wdroenia nowego typu oprogramowania przy istniejcych rozwizaniach sprztowych (np. budowa bazy danych klientw),
sprztowe w wyniku projektu nastpuje modyfikacja stosowanych rozwiza
sprztowych (np. wymiana stacji roboczych na nowsze),
kompleksowe czce w sobie projekty sprztowe i programowe (np. projekt
komputeryzacji firmy od podstaw).
Takie przyporzdkowanie umoliwia zorientowanie si, jak bardzo skomplikowany moe by projekt oraz jak przyj strategi jego realizacji. Zasadniczo najbardziej
skomplikowane bd projekty nowe i kompleksowe, gdy dotyczy bd czego, co
do tej pory nie byo realizowane. Prostsze natomiast bd projekty uzupeniajce,
sprztowe i programowe, gdy zawsze bd opieray si na ju istniejcych rozwiza-
119
niach. Rozpoznanie typu projektu moe by istotne z tego wzgldu, e z niektrymi

rodzajami projektw firma chcca je zrealizowa, moe sobie nie poradzi i wskazane
wtedy bdzie posuenie si fachow pomoc firm zewntrznych.
Szczegln waciwo maj tzw. projekty wdroeniowe, gdzie o sukcesie takiego projektu w bardzo duym stopniu decyduj czynniki i kwalifikacje socjotechniczne
kierownika projektu.
Aby wdroenie zakoczyo si sukcesem, naley:
pozyska zaangaowanie kierownika firmy, w ktrej wdraamy system (wspdzielenie si odpowiedzialnoci),
zapewni niezbdne zasoby ludzkie firmy,
przyj zasady stopniowego rozwoju,
zapewni elastyczno w doborze parametrw projektu,
uwzgldni aspekty socjotechniczne zwizane z mentalnoci i nawykami uytkownikw,
zaplanowa (wybra) lidera procesu wdroeniowego.
S to najwaniejsze czynniki, o ktrych naley pamita, ale nie jedyne, poniewa
jako oraz niezawodno produktu, jak rwnie przygotowanie organizacyjne uytkownika do procesu restrukturyzacji, w ktrym system informatyczny wspomaga
okrelone procesy, stanowi o zintegrowaniu procesu wdroeniowego.
Zmiany organizacyjne w jednostce s czasami konieczne, aby nastpio wdroenie
poniewa:
systemy zarzdzania wewntrz organizacji nie s przystosowane do realizacji
projektw,
powodzenie projektu zaley w takim samym stopniu od firmy, w ktrej projekt
ma by wdroony, jak i od innych organizacji realizujcych projekt,
lider wdroenia potrzebuje pomocy ze strony kierownictwa dziaw firmyklienta.
Struktura zespou wdroeniowego powinna bazowa na:
komitecie sterujcym
odpowiedzialnym za strategiczne zarzdzanie caym
przedsiwziciem,
komitecie wykonawczym odpowiedzialnym za taktyczne zarzdzanie caym
przedsiwziciem.
Komitet sterujcy najczciej stanowi:
sponsor przedsiwzicia,
gwny kierownik przedsiwzicia ze strony producenta systemu,
lider wdroenia ze strony informatyzowanego przedsibiorstwa,
konsultanci zewntrzni.
Zadania komitetu sterujcego obejmuj realizacj takich prac, jak:
okrelenie celw i zdefiniowanie pojcia wdroenie systemu,
przeprowadzenie analizy przedsibiorstwa oraz okrelenie budetu wdroenia,
120
wybr dostawcy oprogramowania oraz firmy doradczej,

zapewnienie aktywnego udziau naczelnego kierownictwa w pracy zespou
wdroeniowego,
przygotowanie harmonogramu wdroenia,
powoanie komitetu wykonawczego,
weryfikacja wykonywanych dziaa,
przekazanie systemu do eksploatacji.
Komitet wykonawczy to zesp operacyjny projektu, w skad ktrego wchodz:
gwny kierownik przedsiwzicia ze strony dostawcy systemu,
lider wdroenia ze strony klienta,
kierownicy dziedzinowi,
uytkownicy kluczowi.
Do zada komitetu wykonawczego nale:
podzia prac i odpowiedzialnoci w zespole,
biece zarzdzanie realizacj prac wdroeniowych,
prowadzenie dokumentacji wdroeniowej,
nadzorowanie prowadzonych prac, monitorowanie ich wydajnoci, sporzdzanie
okresowych raportw,
inicjowanie dziaa korygujcych w przypadku wystpienia zagroe realizacyjnych,
powoywanie oraz biece koordynowanie pracy zespow wdroeniowych.
Czynnoci etapu wdroenia obejmuj midzy innymi:
zakup sprztu,
instalacj bd rozwj sieci komputerowej,
zainicjowanie bazy danych,
wprowadzenie do niej danych,
opracowanie i testowanie programw,
zakup pakietw oprogramowania,
przygotowanie dokumentacji systemu,
przeszkolenie jego uytkownikw.
Prace programistyczne mona przyspieszy przez:
wykorzystanie zasad prototypowania systemu,
wykorzystanie jzykw czwartej generacji,
generatory kodu,
zakupienie i wdroenie zintegrowanego pakietu oprogramowania.
Kategorie testw oprogramowania:
indywidualne, dotyczce sprowadzenia poprawnoci poszczeglnych moduw
121
oprogramowania,
zintegrowane, zwane testami akceptacyjnymi, zwizane z kontrol i korekt caoci oprogramowania systemu, bdce podstaw harmonijnego wspdziaania
wszystkich jego moduw.
Jako wedug ISO 9000 og cech i waciwoci wyrobu lub usugi, decydujcych o zdolnoci wyrobu lub usugi do zaspokojenia stwierdzonych lub przewidywanych potrzeb.
Kryteria jakoci model McCalla
Dziaanie programu przyjazno, wydajno, poprawno, niezawodno.
Przystosowanie do modyfikacji pielgnowalno, elastyczno, testowalno.
Mobilno oprogramowania przejrzysto, uniwersalno, otwarto.
Strategie wdraania systemu
krokowe (ang. step-by-step),
wdraanie wszystkich moduw jednoczenie (ang. big-bang),
wdraanie gwnych moduw jednoczenie (ang. middle-size big bang).
Wdroenie istniejcego systemu
wymiana interfejsw na przyjazne,
wymiana platformy sprztowej,
wymiana oprogramowania uytkowego,
wprowadzenie architektury rozproszonej,
restrukturyzacja.
Wymiana oprogramowania aplikacji
konwersja bezporednia natychmiastowe zastpienie systemu,
konwersja rwnolega nowy i stary funkcjonuj jednoczenie, a nowy bdzie
w peni niezawodny i stabilny,
konwersja pilotowa tylko cze uytkownikw wykorzystuje nowy system,
konwersja fazowa etapowe wprowadzenie nowego systemu poprzez sukcesywne instalowanie poszczeglnych moduw zastpujcych dotychczas uytkowane.
6.2. Wdroenie przez outsourcing

Outsourcing to sprzeda kupno niematerialnych usug informatycznych; sposb
wiadczenia usug dotyczcych zarzdzania, eksploatacji i utrzymania czci albo
caoci systemu informatycznego, polegajcy na powierzeniu tych czynnoci specjalistycznej firmie usugowej na cile okrelony czas [17, 18, 19].
Alternatyw dla tradycyjnych metod wdraania systemw, ktra zdobywa sobie
ostatnio coraz wiksz popularno jest outsourcing. Firma wdraajca system na
122
zasadzie outsourcingu zarzdza nim na poziomie administracji sprztowej i aplikacyjnej oraz nadzoruje prac sieci rozlegej. Firma odpowiedzialna jest rwnie za infrastruktur oraz komunikacj zewntrzn. Serwery s najczciej przenoszone do centrum obliczeniowego firmy wdraajcej, co uwalnia komputeryzowan firm od troski
o bezpieczestwo systemu informatycznego. Informatyzowany klient nie musi take
zatrudnia dodatkowych pracownikw, ktrzy byliby odpowiedzialni za administrowanie systemem. W firmie zainstalowane s tylko komputery uytkownikw kocowych, przetwarzanie danych odbywa si w centrum obliczeniowym firmy outsourcingowej, zdalne jest take administrowanie caym systemem. Szkoleniom poddawani s
tylko uytkownicy kocowi.
Podsumowujc jest to wzgldnie szybki i bezpieczny sposb wdroenia zintegrowanego systemu informatycznego.
Porwnanie tradycyjnego podejcia do zakupu i wdroenia systemu informatycznego i outsourcingu zawarto w tabeli 6.1.
Tabela 6.1. Porwnanie tradycyjnej metody zakupu oprogramowania z outsourcingiem
Metoda tradycyjna
Outsourcing
Sie komputerowa
Tak
Czciowa
Sprzt komputerowy
Zakup
Wdroenie
Tak
Dzierawa; opaty zalene

od klasy sprztu
Tak
Opata za cza TP SA
Brak
Wymagana
Oprogramowanie aplikacyjne
Zakup
Oprogramowanie narzdziowe
Zakup
Instalacja i konfiguracja
oprogramowanie
Koszt utrzymania personelu
informatycznego
Wymagane
Dzierawa; opaty zalene od rodzaju

oprogramowania i efektywnego czasu
jego wykorzystywania (biling)
Opaty wliczone w opaty za
oprogramowanie
Opaty wliczone w opaty za
oprogramowanie i sprzt
Nie
Wymagane
Podzia outsourcingu
Outsourcing jest pojciem do rozlegym, dotyczcym rnych dziedzin dziaalnoci gospodarczej i biznesowej. W informatyce rozwin si i dotyczy nie tylko systemw informatycznych i ma rne odmiany. Klasyfikacja tego zagadnienia pozwala
unikn nieporozumie oraz uatwia zdefiniowanie potrzeb i moliwoci klienta.
Podzia wedug stawianego celu
taktyczny podyktowany jest biecymi potrzebami firmy koncentruje si zwykle na jednym aspekcie dziaalnoci (np. termin realizacji), przewanie ograni-
123
czony do czci systemu (np. zarzdzanie sieci LAN, WAN), wiadczony przez
stosunkowo krtki okres; moe wynika z biecych kopotw przedsibiorstwa
(np. brak moliwoci zatrudnienia wykwalifikowanych pracownikw),
strategiczny element strategii biznesowej przedsibiorstwa pomylany jest jako
peny transfer usug, zarzdzania i odpowiedzialnoci, ma dugotrway charakter,
cechuje si partnerskimi relacjami midzy firmami; wynika z przemylanej strategii
przedsibiorstwa (koncentrowanie si na podstawowej dziaalnoci firmy ang. core business).
Podzia wedug zakresu dziaania
totalny polega na przekazaniu jakiej caej dziedziny dziaalnoci biznesowej
w rce firmy usugowej (np. przekazanie systemw informatycznych do centrum
przetwarzania danych),
selektywny przekazuje si fragment dziaalnoci w obrbie danej dziedziny
(np. zarzdzanie sieci rozleg).
Podzia wedug rodzaju (dot. systemw informatycznych)
outsourcing przetwarzania danych udostpnianie mocy obliczeniowej zewntrznej bez wzgldu na rodzaj aplikacji,
outsourcing systemw informatycznych udostpnianie okrelonego systemu
informatycznego wraz zapewnieniem jego informatycznej obsugi,
outsourcing procesw biznesowych przekazanie dziaalnoci caego dziau do
firmy usugowej (np. naliczanie pac, rozlicze z kas chorych).
Integrator wdroenia
Podstawowym zadaniem integratora wdroenia jest zagwarantowanie powodzenia
w realizacji wdroenia systemu przez:
prawidowe planowanie i harmonogramowanie prac,
sprawne koordynowanie dziaa wszystkich uczestnikw przedsiwzicia,
rygorystyczne przestrzeganie terminw i budetu przy spenianiu wymogw jakociowych.
Firma taka bierze odpowiedzialno za kocowy rezultat prac projektowo-wdroeniowych, jakim jest efektywne funkcjonowanie systemu informatycznego.
Przykad modelu integracji
Faza 1 analiza przedsibiorstwa, okrelenie celw strategicznych przedsiwzicia, wymagania, kryteria wyboru Zintegrowanego Systemu Informatycznego (ZSI):
udokumentowanie istniejcych procedur dziaania,
opracowanie opisw procesw, przygotowanie koniecznej restrukturyzacji przedsibiorstwa,
124
ocena skali przedsiwzicia, ryzyka, kosztw i terminw.

Faza 2 opracowanie koncepcji informatyzacji przedsiwzicia:
selekcja i wybr gotowego systemu informacji,
konfigurowanie oprogramowania aplikacyjnego wedug modelu prototypowania,
modelowanie konfiguracji oprogramowania.
Faza 3 realizacja systemu obejmujca:
przeprowadzenie koniecznej restrukturyzacji przedsibiorstwa,
organizacj dostaw sprztu i oprogramowania,
instalacj i uruchomienie oprogramowania,
dziaalno szkoleniowo-edukacyjn,
szkolenia uytkownikw,
wdroenie i testowanie.
Faza 4 konserwacja i biecy rozwj systemu:
umowy na dugoterminow wspprac w ramach nadzoru autorskiego
(wykonawczego),
konieczne modyfikacje systemu, wynikajce ze zmian obowizujcych
przepisw,
rozbudowa oprogramowania i sprztu, wynikajca z rosncych wymaga uytkownika,
stay rozwj i dostosowywanie.
Formy szkole
Kade wdroenie systemu informatycznego musi zawiera efektywn form szkolenia uytkownikw systemu. S rne metody i formy szkolenia np.:
szkolenia prowadzone w zorganizowanych orodkach szkoleniowych wyposaonych w komputery poczone sieci,
szkolenia prowadzone na miejscu u klienta z wykorzystaniem miejscowego
sprztu i oprogramowania,
szkolenia przez sie (Internet).
inne.
Nawet najlepiej zbudowany i sprawdzony system informatyczny moe przynie
z saw wykonawcy, jeli w niewaciwy sposb przygotuj odbiorc systemu do
jego uytkowania. W tej klasie projektw szczegln uwag naley zwrci na zarzdzanie ryzykiem gwnie do zada w kategoriach zewntrznych i organizacyjnych.
7. Czynniki sukcesw i niepowodze projektw

Omawiane wczeniej gwne czynniki, ktre s przyczyn niepowodze projektw
informatycznych, wskazano midzy innymi na takie jego parametry, jak rozmiar
wielko, ktra powoduje, e przekracza on umiejtnoci niezbdne do jego zarzdzania. Wybr lub brak wyboru adekwatnej strategii realizacji, niewystarczajce wsparcie
projektu przez sponsora i kierownictwo firmy wykonawczej, niewystarczajca wsppraca z klientem, zbyt oglna analiza systemowa. Niewaciwy harmonogram i alokacja zasobw, powodujca konieczno wykonania prac kosztem ich
jakoci, utrata kontroli nad zarzdzaniem zmianami i inne. W tym rozdziale przedstawione zostan wyniki bada The Standisg Group, dotyczce najczstszych przyczyn
niepowodze projektw.
7.1. Niektre badania statystyczne niepowodze projektu

O tym jak wane jest planowanie w osigniciu sukcesu caego projektu mwi dokument Chaos stworzony w 1995 roku przez Standish Group [53], cho od 1995 r.
upyno kilka lat, to aktualno tych danych co do specyfikacji niektrych zalenoci w dalszym cigu jest pouczajca. Dostp do najnowszych danych jest patny
i zainteresowanych odsyam do zacytowanej strony WWW tej organizacji. Badania
przeprowadzone przez The Standish Group w Stanach Zjednoczonych byy przeprowadzone w firmach IT. Wyniki bada opieraj si na wywiadach z ludmi uczestniczcymi w tworzeniu projektw.
W badaniach byy brane pod uwag mae, rednie oraz due przedsibiorstwa
(dziaajce w Bostonie i San Francisco), poczwszy od duych przemysowych organizacji, np. bankowo, bezpieczestwo, sprzeda detaliczna, do lokalnych, federalnych organizacji. W sumie przebadano 365 firm, wzito pod uwag 8380 aplikacji.
Dla uzyskania poprawnych, rzetelnych wynikw Standish Group przeprowadzio wiele wywiadw, zadao wiele pyta.
Wedug bada wynika, e tylko 16,2% projektw koczy si sukcesem, podczas
gdy 52,7% koczy si niepenym sukcesem, a 31,1% zostaje anulowane. Projekty
126
zakoczone penym sukcesem to takie, ktre s kompletne, nie przekroczyy czasu ani
budetu. Projekty zakoczone niepenym sukcesem s kompletne, ale zosta przekroczony czas i budet, oraz kilka funkcji i zaoe pierwotnych zostao zmienionych
w trakcie realizacji projektu. Projekty anulowane nie zostay ukoczone.
Wyniki bada byy pesymistyczne niezalenie od wielkoci firmy. Tylko 9% projektw w wielkich przedsibiorstwach zakoczyo si sukcesem, w rednich 16,2%,
w maych 28%. Wikszo z projektw wielkich firm zakoczya si sukcesem niepenym, natomiast rednich i maych przedsibiorstw odpowiednio: 46,7% i 50,4%.
Projekty, ktre zostay anulowane stanowi 37,1% projektw w rednich firmach,
29,5% w wielkich, a 21,6% w maych.
Gwnymi przyczynami niepowodzenia projektu jest przekroczenie budetu i czasu
realizacji projektu. Najczciej jest to zwizane z nieprawidowym planowaniem projektu.
rednie przekroczenie budetu dla wszystkich przedsibiorstw wynosi 189% szacowanego budetu; dla wielkich przedsibiorstw: 178%, dla rednich 182% i 214% dla
maych.
Tabela 7.1
Przekroczenie budetu
(w procentach)
Poniej 20%
2150%
51100%
101200%
201400%
Ponad 400%
Liczba projektw
(w procentach)
15,5%
31,5%
29,6%
10,2%
8,8%
4,4%
rednie przekroczenie czasu stanowi 222% szacowanego czasu realizacji projektu.

Dla wielkich przedsibiorstw wynosi 230%, rednich 202% i maych 239% (tabela 7.2).
Tabela 7.2
Przekroczenie czasu
(w procentach)
Poniej 20%
2150%
51100%
101200%
201400%
Ponad 400%
Liczba projektw
(w procentach)
13,9%
18,3%
20,0%
35,5%
11,2%
1,1%
O penym sukcesie projektu decyduje niewtpliwie zgodno produktu kocowego

z zaoeniami, powstaymi przed realizacj projektu. Dla duych przedsibiorstw tylko
127
42% produktu kocowego zgadzaa si z zaoeniami, dla rednich przedsibiorstw

sytuacja przedstawia si troch lepiej 65%, a dla maych 74% (tabela 7.3).
Tabela 7.3
Zgodno produktu kocowego
z zaoeniami (w procentach)
Mniej ni 25%
2549%
5074%
7599%
100%
Liczba projektw
(w procentach)
4,6%
27,2%
21,8%
39,1%
7,3%
Z bada przeprowadzonych w 365 firmach na 3682 projektach wynika, e tylko

431, czyli 12% z tych projektw zostao zakoczonych na czas i nie przekroczyo
budetu. Celem Standish Group byo znalezienie przyczyny niepowodzenia projektw. W tym celu zapytaa ankietowanych, jakie wedug nich czynniki wpywaj na
sukces projektu. Na czwartym miejscu znalazo si prawidowe planowanie. Oznacza
to, e projektanci docenili rol planowania (tabela 7.4).
Tabela 7.4
Lp.
Czynniki sukcesu projektu
1
2
3
4
5
6
7
8
9
10
11
Zaangaowanie klienta
Wsparcie kierownictwa
Jasne okrelenie wymaga
Waciwe planowanie
Realistyczne oczekiwania
Mniejsze odstpy midzy punktami kontrolnymi
Kompetencje pracownikw
Odpowiedzialno
Jasno sprecyzowane cele
Ciko pracujcy pracownicy
Inne
Liczba projektw
(w procentach)
15,9%
13,9%
13,0%
9,6%
8,2%
7,7%
7,2%
5,3%
2,9%
2,4%
13,9%
Dla lepszego zrozumienia niepowodze projektw Standish Group szczegowo

przeanalizowao cztery synne projekty: dwa z nich zakoczyy si penym sukcesem
(Hyatt Hotels, Banco Itamarati), a dwa pozostae poniosy klsk (California DMV,
American Airlines). Rozpatrujc powysze przykady pod wzgldem czynnikw sukcesu projektu wynika, e waciwe planowanie odgrywa decydujc rol w sukcesie
projektu. Projekty, ktre odniosy sukces charakteryzoway si skrupulatnym planem,
natomiast w projektach, ktre zakoczyy si klsk proces planowania zosta zaniedbany.
Projekty zakoczone penym sukcesem: Hyatt Hotels, Banco Itamarati.
128
Projekty zakoczone klsk: California DMV, American Airlines.

Tabela 7.5
Lp.
Czynniki sukcesu projektu
1
2
3
4
5
6
Zaangaowanie klienta
Wsparcie kierownictwa
Jasne okrelenie wymaga
Waciwe planowanie
Realistyczne oczekiwania
Mniejsze odstpy midzy
punktami kontrolnymi
Kompetencje pracownikw
Odpowiedzialno
Jasno sprecyzowane cele
Ciko pracujcy pracownicy
Inne
7
8
9
10
11
California
DMV
nie
nie
nie
nie
tak
nie
American
Airlines
nie
tak
nie
nie
tak
nie
Hyatt
Hotels
tak
tak
tak
tak
tak
tak
Banco
Itamarati
tak
tak
nie
tak
tak
tak
nie
nie
nie
nie
nie
nie
nie
nie
nie
tak
tak
tak
tak
tak
tak
tak
tak
tak
tak
tak
Z przeprowadzonych bada przez Standish Group w roku 2003 wynika, e zwiksza si liczba projektw zakoczonych sukcesem z 16% w 1994 r. do 34% obecnie.
Innym pozytywnym zjawiskiem jest zmniejszanie si kosztw przekroczenia budetu
projektu z ok.180% w poowie lat 90. do ok. 43% obecnie. Najwikszy postp w zakresie prowadzenia projektw co do ich wskanika projektw zakoczonych sukcesem oraz kosztw wytwarzania odnotowano w duych firmach. W maych firmach
natomiast zauwaono do znaczcy (50%) wzrost kosztw przy niewielkiej poprawie
wskanika projektw zakoczonych sukcesem.
Standish Group stwierdza, e istniej trzy gwne przyczyny poprawy procentowego projektw ukoczonych sukcesem i do nich nale:
1. Obserwowany trend dekomponowania projektw na mniejsze aplikacje.
2. Oglny wzrost umiejtnoci i kompetencji kierownikw projektw oraz postp
nauki w dziedzinie zarzdzania projektami.
3. Upowszechnianie standardw i narzdzi wspomagajcych zarzdzania projektami.
W kolejnym rozdziale rozwinito niektre aspekty dotyczcy wielkoci projektu
i wpywu tego parametru na sukces projektu.
7.2. Wpyw wielkoci projektu na jego sukces

W jakim stopniu planowanie projektu wpywa na sukces projektu niewtpliwie zaley od wielko projektu. Wiadomo, e jeeli mamy do czynienia z duymi projek-
129
tami, dokadne, skrupulatne, szczegowe planowanie decyduje o sukcesie projektu.

Nie jest moliwe przy takich rozmiarach projektu zaniedba proces planowania. Przy
maych projektach natomiast jest wiksza szansa na powodzenie, nawet przy niezbyt
dokadnym i poprawnym planowaniu. Nasuwa si pytanie jak rozrni mae
i due projekty. Czy jest jakie kryterium oceny wielkoci projektu?
W 1979 roku na zlecenie IBM Allan Albrecht zaprezentowa metod punktw
funkcyjnych. Punkty funkcyjne s miar wielkoci aplikacji komputerowych i projektu, ktry je stworzy. Wielko ta jest mierzona ze wzgldu na funkcjonalno
z punktu widzenia uytkownika.
Wedug standardu ISO/IEC/JTC1/SC7 14143
Rozmiar funkcjonalny to rozmiar oprogramowania otrzymany przez obliczenie
funkcjonalnych wymaga uytkownika. Z pojciem punktu funkcyjnego zwizany jest
czynnik modyfikujcy warto punktw funkcyjnych VAF (ang. Value Adjustment
Factor). Uzyskuje si go przez odpowiedzenie na 14 pyta zwizanych z projektem.
Odpowiedzi jest ustalenie wanoci podanego czynnika dla naszego systemu (skala
od 0 do 5). Kocow warto oblicza si ze wzoru:
VAF = 0,65 + [(Ci)/100],
gdzie 0 < i < = 14
Wedug IFPUG redniej wielkoci projekt ma 899 punktw funkcyjnych.

ISBSG (ang. International Software Benchmarking Standards Group) w dokumencie Release 6 w kwietniu 2000 roku podaje przykadowe obliczanie kosztu redniego projektu (889 punktw funkcyjnych) pisanego w jzyku C++. rednia cena za
punkt funkcyjny wynosi $1,234. Praca przypadajca na jeden punkt funkcyjny trwa 14
godzin. Liczenie kosztu od strony klienta: $90 za godzin pracy [50, 55].
Poniewa zauwaono, e projekty mniejsze czciej kocz si sukcesem, wic zachodzi pytanie, co to jest may projekt. Wielko projektu jest spraw wzgldn,
zwizan z wielkoci firmy i jej poziomem kompetencji, stosowanymi standardami
oraz dowiadczeniem. Te zagadnienia i ich ocena jest procesem dynamicznym, poniewa wynika z tego, e krtsze ramy czasowe wytwarzania komponentw zwikszaj wspczynnik sukcesu, dziki iteracyjnemu procesowi projektowania, prototypowania, testowania i przekazywania maych elementw. Wiksze systemy powstaj
z maych komponentw i kady z nich ma posiada precyzyjnie okrelony zestaw celw i realistycznych oczekiwa klienta.
8. Rola i zadania kierownika projektu

Jak ju zaznaczono we wprowadzeniu tej ksiki wiedza na temat zarzdzania projektami nie powinna by zarezerwowana jedynie dla najwyszego kierownictwa, odpowiedzialnego za caoksztat organizacji oraz realizacj projektw. To samo dotyczy
PM, jest ona bezsprzecznie potrzebna do realizacji celw projektu, podejmowania
trudnych decyzji i alokowania zasobw w sposb sprzyjajcy realizacji projektw.
Jednak bez odpowiedniego przygotowania zespow projektowych nie ma gwarancji,
e zadania przydzielane w poszczeglnych etapach projektw zostan prawidowo
zrealizowane. Wszyscy czonkowie organizacji potrzebuj wiedzy i umiejtnoci
w zakresie zarzdzania projektami jedni bardziej pogbionej i rozbudowanej, inni
mniej szczegowej. Mimo e coraz czciej moemy spotka sytuacje, w ktrej kto
lub kogo nazywamy Project Managerami, coraz czciej licz si formalne, powiadczone certyfikatem uprawnienia do tego tytuu. Dyplomy wydawane przez
MT&DC przy wsppracy z Educational Services Institute International (ESI) potwierdzaj uzyskanie przez uczestnika kursu, gruntownego wyksztacenia i nabycia
kompetencji w tym zakresie. Otrzymanie certyfikatu ESI czy si z fundamentalnym poznaniem niezbdnej tematyki zwizanej z zarzdzaniem projektem i otwiera
drog do uzyskania dyplomu Project Management Professional (PMP).
Proces realizacji projektu jest niejednokrotnie dugotrway i skomplikowany, podczas
realizacji projektu PM dowiadcza zagadnie nie tylko dotyczcych projektu, ale rwnie
zmian organizacji firmy, ktra realizuje projekt (zmiany zarzdu, reorganizacja, zwolnienia itd.) W projektach informatycznych, szczeglnie duych, kiedy mamy do czynienia
z wieloma zespoami zadaniowymi (np. zesp analitykw, zesp wytwarzania aplikacji
produkcyjny, zesp komunikacji i przekazu elektronicznego dokumentw, baz danych,
integracji, bezpieczestwa itp.), mamy do czynienia z nowymi technologiami, nowatorskimi rozwizaniami oraz ze specjalizacj prac w zespoach. Dynamika zmian w zakresie
rozwoju narzdzi wspomagajcych prace projektowe i produkcyjne oprogramowania
stworzya sytuacj, e ju od kilku lat jeden czowiek nie jest w stanie by specjalist ze
wszystkich dziaach informatyki, zatem wspczesny PM to przede wszystkim:
Biznesmen do jego zada naley:
wsppraca z klientami,
adaptowanie zmian, wymaga i relacji wewntrz firmy,
131
szacowanie kosztw zwizanych z alternatywnymi wyborami.

Technolog odpowiedzialny za trafy wybr:
zasobw,
produktywno i efektywno dziaa ,
innowacje techniczne,
adaptowanie metod dziaania.
Zarzdzajcy
ludmi,
zasobami,
zmianami,
komunikacj,
powizaniem organizacyjnym z kooperantami,
prac grupow,
rozwizujcy konflikty,
twrca i lider zespou.
PM to architekt projektu integrujcy zagadnienia ekonomiczne i techniczne, niekoniecznie superspecjalista w dziedzinie informatyki.
8.1. Usytuowanie kierownika projektu

a jego skuteczno
Miejsce i rola kierownika projektu zaley midzy innymi od wielkoci firmy i czym
dla niej jest projekt. Moe to by jedyny projekt dla firmy, caa firma pracuje na jego
rzecz, a szef firmy kieruje jednoczenie projektem. Jednak istnieje inna moliwo: wiele
projektw realizowanych jest rwnoczenie w firmie, a szef firmy jest informowany lub
interesuje si tylko wybranymi projektami. W poszczeglnych branach czy zastosowaniach bezporedni nadzr sprawuj czonkowie zarzdu firmy. To czy firma realizujca
projekt liczy 510 osb czy 2000 zasadniczo wpywa na usytuowanie PM. Typowe grupy i osoby, z jakimi ma do czynienia kierownik projektu:
kierownicy innych zazbiajcych si projektw,
zarzd firmy i jego przedstawiciele,
szefowie dziaw firmy, w ktrej pracuje,
czonkowie zespou projektowego,
inni pracownicy firmy, ktrzy nie bior udzia w pracach nad projektem,
zleceniodawcy zewntrzni,
dostawcy sprztu i oprogramowania podwykonawcy,
kontrolerzy,
radcy prawni,
132
personel techniczny zapewniajcy prac rodowiska systemu oraz serwis,

administracja firmy (dzia finansowy, marketingu).
8.2. Dobr czonkw zespou

Najwiksze szanse na pomylne zrealizowanie projektu (zadania) maj zespoy,
ktre maja w swym skadzie pracownikw, ktrym mona przypisa 8 poniszych rl
(wg Belblina na podstawie dowiadcze):
chairman, koordynator,
nadajcy ksztat aplikacji,
ogrodnik zaszczepiajcy idee,
kontroler monitorujcy prace i nadzorujcy czy nie ma odstpstwa od zaoonego kierunku planu prac,
brygadzista, rozkadajcy prac,
osoba nastawiona na analiz zewntrzn zasobw, zmian w rodowisku, nowe
rozwizania techniczne, programowe itp.,
wykonawca, czonek zespou,
czuwajcy nad terminowym i waciwym zakoczeniem.
Dobranie pracownikw, o powyszych naturalnych predyspozycjach, sprzyja atmosferze pracy, a kady pracownik wykonuje tak prac, z ktrej jest zadowolony
i najefektywniejszy. Zadaniem kierownika projektu jest nie tylko uwiadomienie sobie
kogo potrzebuj, zdefiniowanie zada, zakresu prac, ale rwnie waciwe poznanie
predyspozycji czonkw zespou i podzia zada.
Przy specyfikacji zada i ich rozdziale naley zwrci szczegln uwag na:
jakie s podstawowe obowizki, czy istnieje specjalna odpowiedzialno za
sprzt, bezpieczestwo innych,
gwne trudnoci i uciliwoci,
z jakimi osobami bdzie mie kontakt osoba wykonujca zadanie,
zakadany stopie nadzoru, swobody w podejmowaniu decyzji,
czy istniej inne niedogodnoci tej pracy.
W specyfikacji zadania mog pomc:
dowiadczenia pracy nad analogicznymi projektami,
fachowcy, zatrudnieni w firmie.
8.3. Rekrutacja czonkw zespou

Coraz czciej rekrutacja do danej firmy projektu odbywa za porednictwem wyspecjalizowanych firm lub komrki organizacyjnej, ktre zajmuj si rwnie zarz-
133
dzaniem wiedz i modelowaniem cieek rozwoju pracownikw. Na og gwnym

czynnikiem, ktry wpywa na sposb i metod rekrutacji:
specyfikacja zadania jest podstaw dla charakterystyki poszukiwanego pracownika,
pod uwag naley bra budowanie zespou i wpyw jednostki na zesp, na
wspln prac,
podstawowe elementy charakterystyczne poszukiwanego pracownika:
oczekiwane zdolnoci i moliwoci kandydata,
cechy jako wsppracownika,
osobowo.
Metody rekrutacji z firmy:
spord kolegw,
od zleceniodawcy,
dawni pracownicy,
osoby, ktre wczeniej ubiegay si o prac,
inni, ktrzy przyprowadz kolejne osoby,
ogoszenia (koszt),
agencje porednictwa pracy,
czasem: rzdowa rekrutacja, przez centra zawodowe lub uczelnie czy kursy,
Internet (formularze elektroniczne zgoszenia zarwno wolnego miejsca pracyposzukiwanie pracownika, jak rwnie zgoszenie swojego chci zatrudnienia).
Metody wyboru:
tworzenie krtkiej listy,
na podstawie interview,
selekcja zespoowa,
test wyboru.
8.4. Budowa kompetencji w projekcie

Prowadzenie projektw informatycznych w nowoczesnych firmach zwizanych
z rynkiem IT opiera si na zespoach ludzi o zrnicowanych kwalifikacjach. Spektrum
problemw, z jakimi zesp czsto musi si zmierzy, wymaga, by kompetencje pracownikw nawzajem si uzupeniay. Powodzenie realizacji projektu, midzy innymi,
wynika z poziomu kompetencji caego zespou. Struktura przydziau odpowiedzialnoci
i zakresu obowizkw poszczeglnych pracownikw powinna by moliwie optymalna.
Jasna cieka rozwoju technologicznego bd aplikacyjno-wdroeniowa ma udzia
w motywowaniu czonkw zespou do systematycznego podnoszenia wasnych
kwalifikacji, co przekada si na budow kompetencji caej firmy.
Wiedza (praktyczna i teoretyczna) wiedza mwi o tym, e dana osoba miaa
ju do czynienia z wybranym zagadnieniem, moga o tym zagadnieniu czyta lub ob-
134
serwowa tok realizacji zada z nim zwizanych, jednak nie miaa okazji zdoby praktyki w jego realizacji. Jeli osoba posiada tylko wiedz z danego zagadnienia, kierownik nie decyduje si raczej przydziela penego zadania do wykonania przez t osob,
poniewa z wiedzy zgodnie z niniejsz definicj nie wynika jeszcze zdolno realizacji. W niektrych przypadkach znajomo dotyczy zagadnie, ktre s opisywane w
literaturze lub wykadane na uczelniach, lecz nie ma zbyt silnego uzasadnienia, aby
takie dziaania powtarza, poniewa s one ju gdzie indziej praktykowane
i uznane jako wzorcowe. Przykadem moe by budowa kompilatorw, w czym specjalizuj si due koncerny, a zatem rzadko powtarzane s takie prace, wic rwnie
nie istnieje zbyt wiele sposobnoci w realizacji zada z tym zwizanych.
Zdolnoci to cechy osoby, ktra jest w stanie wykona zadanie, ktrego rezultatem jest okrelona kategoria produktu (np.: raport z zakoczonej sukcesem instalacji
oprogramowania) bd (poprawny) stan konfiguracji systemu (np.: zainstalowany
system klasy...). Zdolno do wykonania okrelonej kategorii zadania oznacza, e
dana osoba moe zosta przydzielona do wykonania tego zadania, a jej praca nad zadaniem zakoczy si sukcesem (naley zatem ze zdolnoci szczeglnie silnie kojarzy pojcie samodzielnoci w dziaaniu).
kompetencje biznesowe
kompetencje spoeczne
KOMPETENCJE
UMIEJTNOCI
WIEDZA
kompetencje profesjonalne
kompetencje integracyjne
kompetencje branowe
Rys. 8.1. Schemat oglny klasyfikacji kompetencji
135
Umiejtno mwi o tym, e dana osoba jest w stanie wykona czynno praktyczn w sposb automatyczny (bez szczeglnych przemyle, np.: moe opiera si na
naladownictwie lub cechach wrodzonych) lub ze wsparciem. Umiejtno w szczeglnoci dotyczy niezbyt zoonych podzada czstkowych, ktrych wykonanie nie wymaga silnego zaangaowania w koordynacj zasobw i zarzdzanie. Umiejtno przejawia
si take moliwoci wykonania dziaa pod kierunkiem osoby bardziej dowiadczonej,
gdzie nie istnieje dla wykonujcego konieczno szczegowego planowania (nie jest
wymagany duy stopie samodzielnoci).
Kompetencje zdolnoci praktycznego wykorzystania umiejtnoci i wiedzy
w peni wystarczajce do samodzielnego wykonywania okrelonego zadania w projekcie.
Przedstawiony na rysunku 8.1 graficznie podzia i przenikanie si granic midzy
wiedz, umiejtnociami a kompetencjami, szczeglne istotne dla PM staj si kompetencje profesjonalne w obszarze produktw branowych oraz integracyjnych.
W przedsiwziciach integracyjnych nie bez znaczenia s postawy prezentowane partnerw, osobowo PM oraz szersza wiedza wykraczajca poza wiedz dotyczc produktu z uwagi na konieczno prowadzenia wielu rozmw i uzgodnie nie tylko biznesowych, ale w kontekcie otoczenia projektu. Uwarunkowania oraz umiejtnoci
spoecznej komunikacji i wspdzielenia zainteresowa partnerw przedsiwzicia jest
kluczem zawizania relacji, zaufania jak rwnie wspdziaania.
Kompetencje w projektach mog by dzielone na 3 klasy:
Profesjonalne.
Biznesowe.
Spoeczne.
1. Wykaz kompetencji podanych dla realizacji danego projektu powinien znajdowa si w opisie zasobw projektu.
2. Kompetencje podlegaj cigej ocenie oraz s wyjciem do podejmowanych
przez pracownika i w stosunku do pracownika dziaa i decyzji.
3. Dziaania i decyzje mog by powizane z pracami w projektach u klienta lub
pracami wewntrznymi (w szczeglnoci projektami wewntrznymi).
4. Wykorzystanie kompetencji w powyszych dziaaniach przekada si na stopie
realizacji celw przydzielonego stanowiska w projekcie.
5. Stopie realizacji celw stanowiska przekada si na stopie realizacji celw zespou.
6. Stopie realizacji celw zespou przekada si na stopie realizacji celw projekt.
W planowaniu naley uwzgldni kady z powyszych zasobw i zdefiniowa
ograniczenia, jakie wnosz do projektu. Niektre zasoby s czasami rozmyte lub trudno definiowalne (biznesowe, spoeczne, techniczne, rodowiskowe, etyczne, polityczne), ale w niektrych projektach mog mie podstawowe znaczenie w doprowadzeniu
projektu do sukcesu [5, 13, 30, 42, 59].
136
8.5. Konflikt
W ostatnich kilkunastu latach ulegy zmianie zapatrywania na konflikt, czyli problem nieporozumie oraz brak zgodnoci co do sposobu podejcia do realizacji projektu czy metody realizacji. Konflikt to sztuka przekonywania do swoich racji na tle
zaburze komunikacji w zespole. Obecnie uwaa si, e konflikty, ktre powstaj w
zespoach pracujcych nad projektami s naturalne i naley je wykorzystywa w celu
osignicia lepszych efektw pracy.
Tabela 8.1
Tradycyjnie
Zbdny i szkodliwy
Mona unikn
Powodem jest bd kierownictwa
lub osoby konfliktowej
Wspczenie
Nieunikniony
Naley nim kierowa
Za struktura zarzdzania, sposb
postrzegania czonkw przez kierownictwo
Przyczyny konfliktw:
konieczno dokonania wyboru,
zaspokojenie postulatw oczekiwa kosztem innych,
penienie funkcji w zespole i na zewntrz.
Kompromis jest nietrway i nie rozwizuje problemu (zgniy kompromis), najczciej
agodzi sytuacje konfliktowa na okres przejciowy, strony konfliktu czuj si niezadowolone i oczekuj na nastpn sytuacj, kiedy i ich racje zwyci. Kady element zbiorowoci ludzkiej dy do zaspokojenia swoich celw, co jest przyczyn konfliktw, ale
prowadzi do zmian w tych zbiorowociach [11, 22, 56].
Typy konfliktw:
wewntrzno-osobnicze,
midzyludzkie,
wewntrz grupowe,
midzygrupowe.
Zmiany s gwn przyczyn powstawania konfliktw, poniewa obejmuj zagadnienia, ktre dotycz ambicji oraz emocjonalnego zaangaowania najbardziej kreatywnych i o wyranej osobowoci czonkw zespou.
8.6. Motywowanie
Wedug Griffina [22] Motywowanie, to zestaw si, ktre powoduj, e ludzie zachowuj si w okrelony sposb. Zasadniczym celem stosowania technik motywacyj-
137
nych jest zwikszenie efektywnoci i wydajnoci pracy jako e pracownik, ktry

posiada odpowiedni motywacj do wykonywania swojej pracy wykonuje j lepiej
i szybciej.
Jak wykazay badania, najskuteczniejszym czynnikiem motywacyjnym nie jest wcale
wysokie uposaenia pracownikw, jak tradycyjnie przyjmowano za prac Fredericka W.
Taylora. Wprawdzie motywuj one do zwikszania swojej wydajnoci i podwyszania
kompetencji, ale nie stanowi czynnika budujcego lojalno wobec firmy pracownik
motywowany gwnie poprzez pac nie ma oporw przed odejciem do konkurencyjnej
firmy, jeeli ta zaproponuje mu odpowiednio wysok pensj. W ten sposb, przez odpyw kapitau intelektualnego, mona utraci znaczc cz potencjau firmy, co wywrze negatywny wpyw na jej warto rynkow. Na przestrzeni ostatnich lat powstao
wiele podej i teorii motywowania, jak: motywowanie od strony treci oraz hierarchii
potrzeb, np. przynalenoci, szacunku, teoria ERG. Hierarchia potrzeb wedug Maslowa
sugeruje, e ludzie musz zaspokoi pi kolejnych potrzeb fizjologicznych, bezpieczestwa, przynalenoci, szacunku i samorealizacji.
Najskuteczniejszym motywatorem jest, jak wykazay badania, sama praca, o ile
jest ona zgodna z kompetencjami i zainteresowaniami pracownika, pozwala mu ona na
samodoskonalenie si i rozwj zawodowy i intelektualny. Dodatkowo, jest to silny
element budujcy lojalno pracownika wobec firmy i dodatkowy argument przeciwko odejciu z niej w razie prby przejcia pracownika przez konkurencyjn firm.
Wybrane czynniki motywujce, co do ktrych istnieje konsensus to:
rozdzia pracy (interesujca, odpowiedzialna) wspomniana wyej praca zgodna
z kompetencjami,
czenie celw indywidualnych integracja celw indywidualnych z celami projektu (w ramach moliwoci),
perspektywiczno i rozwojowo.
Wybranymi czynnikami demotywujcymi s:
niski poziom pac,
rodowisko pracy,
styl pracy zespou, klimat (lider),
le dobrana praca,
niewaciwy poziom nadzoru lub jego brak,
le ustawione granice odpowiedzialnoci.
Jako potwierdzenie powyszych stwierdze moe posuy cytat z artykuu Joanny
Chylewskiej [13]:
Najbardziej efektywnymi sposobami motywowania pracownikw jest zapewnienie
im moliwoci zdobywania osigni w zakresach, ktre s spjne z ich najgbiej
zakorzenionymi zainteresowaniami i pasjami
Mechanizmami czcymi motywowanie z zarzdzaniem kompetencjami moe by na
przykad kompetencyjny system wynagrodze, uzaleniajcy wysoko uposaenia pracownika, od zakresu jego kompetencji. Naley jednake zaznaczy, e rzadko mona
138
spotka rozwizania, w ktrych kompetencje stanowi jedyne kryterium wyznaczania

wysokoci pensji. Trudnoci z ocen kompetencji i wycen ich wartoci, a take bariery
psychologiczne, powoduj, e stosowane s systemy hybrydowe, w ktrych ocena kompetencji stanowi tylko jeden z czynnikw wpywajcy na wysoko zarobkw pracownika, bdc po czci rwnowaone przez wycen wartoci wytwarzanych przez pracownika
(tj. przez ocen wartoci efektw jego pracy). Niemniej jednak system kompetencyjny
potrafi skutecznie zachci pracownika do samodoskonalenia si i rozwoju.
Innym mechanizmem motywujcym, dbanie o wasne kompetencje jest system ocen
okresowych w ktrym to systemie co pewien czas urzdza si badanie kompetencji
pracownikw, co stanowi pniej podstaw do oceny efektywnoci i jakoci pracy danej
osoby. wiadomo silnej konkurencji na rynku pracy i istotnoci wynikw bada okresowych stanowi rwnie bardzo silny czynnik motywujcy pracownikw do rozwoju.
Warto wreszcie przytoczy bardzo celne stwierdzenie Ulricha:
Kapita intelektualny = Kompetencje Motywacje, D.Ulrich, 1998
Stwierdzenie to jest wyraeniem bardzo prostej prawdy: na warto pracownika
jako kapitau intelektualnego skadaj si w rwnym stopniu jego kompetencje, jak
i motywacja. Pracownik kompetentny, ale o sabej motywacji nie jest w stanie osign maksimum swojej potencjalnej wydajnoci i jakoci pracy, podobnie w przypadku pracownika dobrze zmotywowanego, ale nie posiadajcego odpowiedniego zakresu
kompetencji. Dopiero pracownik kompetentny i dobrze zmotywowany stanowi naprawd wartociowy nabytek dla firmy i jest zdolny do osigania znakomitych wynikw zarwno pod wzgldem wydajnociowym, jak i jakociowym.
Ludzie d do spenienia swoich celw. W innym przypadku pojawiaj si ze
odczucia, majce swoje konsekwencje w zachowaniu.
Typowe cele pracy, ktre stymuluj rozwj kompetencji:
wsplne cele zawodowe zmierzajce do:
sukcesu,
finansowej satysfakcji,
rozwoju, nauki;
indywidualne:
towarzystwo, atmosfera w pracy,
bezpieczestwo,
odskocznia, zainteresowania.
Zadaniem prowadzcego projekt jest odpowiednie motywowanie i integracja celw zawodowych z celami indywidualnymi czonkw zespou.
Czynniki motywujce
Coraz czciej, a wynika to z licznych ankiet, jak rwnie preferowanych przez pracownikw cieek rozwoju, e gwnymi czynnikami motywujcymi do pracy s:
waciwy rozdzia pracy dla kadego interesujcej i odpowiedzialnej,
139
czenie celw zespoowych z indywidualnymi,

perspektywiczno i rozwojowo wykonywanej pracy,
moliwo awansu.
Czynniki demotywujce
niski poziom pac,
rodowisko pracy,
styl pracy zespou, klimat (lider),
le dobrana praca: za atwa, za trudna, nuca, nie odpowiadajca zainteresowaniom, nie satysfakcjonujca,
niewaciwy poziom nadzoru lub pomocy, brak zainteresowania przeoonych,
le ustawione granice odpowiedzialnoci.
8.7. Delegowanie uprawnie

Bardzo istotnym czynnikiem motywowania pracownika jest umiejtne przekazanie
i przejcie przez czonkw zespou niektrych kompetencji (midzy innymi dotyczcych planowania, kontroli) od kierownika projektu. Otrzymane uprawnienia powinny
by powizane nie tylko z moliwoci podejmowania decyzji, ale te z ponoszeniem
konsekwencji. Jest to forma zwikszenia efektywnoci i zaangaowania pracy nad
projektem czonkw zespou.
Czynniki przeciwne delegowaniu uprawnie
Delegowanie uprawnie nie jest powszechnie akceptowanym dziaaniem i moliwoci jego zastosowania moe ogranicza:
niech kierownictwa do pozbywania si czci uprawnie,
niech personelu do podejmowania odpowiedzialnoci.
Szczeglnie w organizacjach, gdzie autorytet czy pozycja zalena jest od tzw.
funkcji (kierownika, dyrektora itd.) zachodzi obawa, e przekazanie czci swoich
uprawnie moe stworzy konkurencj lub osabi moliwoci oddziaywania na
podwadnych. Personel przyjmujcy uprawnienia musi mie gwarancj, e podejmujc si wykonywania niektrych zada, ktre przynalene s wyszemu personelowi,
dziaajc w sytuacji braku dowiadczenia, moe popeni bdy. I jeli te bdy nie
bd wynikay z zaniechania lub niedbalstwa, to przyjmujcy uprawnienia nie poniesie odpowiedzialnoci.
Pracownicy ich podane postawy:
nie powinni mwi, e nie potrafi si czego zrobi,
nie powinni bagatelizowa trudnoci zadania,
domaga si prawa do popeniania bdw.
Skuteczno zespou wedug Mc Gregora
Mc Gregor sformuowa podstawowe czynniki, ktre powinny wystpowa w zespo-
140
le, aby dziaa skutecznie, s nimi:

pozbawiona oficjalnoci, rozluniona atmosfera,
duo i wszyscy dyskutuj o przedmiocie projekt,
cele i zadania s dobrze rozumiane i akceptowane,
czonkowie zespou uwanie suchaj opisu kolegw,
dopuszcza si niejednomylno, nieporozumie nie dusi si w zarodku, przyczyny s gboko rozwaane,
wikszo decyzji na zasadach konsensusu, rzadko oficjalne gosowania, wikszo gosw nie jest wystarczajc przesank do podjcia okrelonych krokw,
opinie krytyczne pojawiaj si czsto, ale nie s personalizowane, odnosz si do
zada oraz dziaa zespou,
gdy podejmuje si czynnoci, funkcje s jasno okrelone i akceptowane,
przywdca grupy nie dominuje nad szeregowymi pracownikami.
Aby zesp natomiast opanowa wymienion metod, skad czonkw tego zespou
powinien posiada okrelone predyspozycje i cechy osobowe, ktre zostay sformuowane przez Belblina (patrz rozdz. 8.2. Dobr czonkw zespou).
9. Dodatek
Ten rozdzia ma wskaza na przykadowe fakty w postaci wypracowanych i przyjtych przez niektre organizacje metod zarzdzania projektami oraz narzdzia, ktre
powstay, aby je wspomaga.
9.1. Metoda zarzdzania projektami PRINCE-2

Metoda PRINCE 2 powstaa w 1989/96 dziki CCTA (Central Computer and Telecomunications Agency)/SPOCE. Zostaa ona oparta na wczeniejszej metodzie, znanej pod nazw PROMPT. W 1999 firma CRM S.A. adaptuje metod PRINCE 2SPOCE-CRM do warunkw polskich [6]. PRINCE 2 jest standardem brytyjskiej administracji publicznej i biznesu do zarzdzania projektami, jest te powszechnie przyjta jako standard zarzdzania projektami wszystkich rodzajw w sektorze publicznym
i prywatnym.
1. Projekt jest skoczonym zbiorem aktywnoci, majcym swj pocztek i koniec.
2. Projekt musi by zarzdzany, aby skoczy si sukcesem.
3. Aby uzyska waciwe zaangaowanie stron, wszyscy musz mie pen jasno
co do celu, sposobw realizacji, odpowiedzialnoci stron;
Korzyci z zastosowania pakietu PRINCE 2-SPOCE-CRM.
Dziki elastycznoci tej metody jest stosowana zarwno do wielkich, wysokobudetowych projektw, jak i do maych przedsiwzi wewntrz organizacji. Metoda ta
moe by z powodzeniem uyta do zarzdzania wielkimi projektami inicjowanymi
przez due organizacje i agencje rzdowe (np. PRINCE 2 jest standardowo uywana
przez brytyjskie instytucje rzdowe), do zarzdzania rnej skali projektami uywane
przez brytyjskie agencje rzdowe).
Podstawowe waciwoci tej metody:
skupienie na ocenach wedug kryteriw biznesowych,
procesowe podejcie do sterowania zarzdzaniem, zespoem i jakoci,
zdefiniowana struktura organizacyjna zespou zarzdzajcego projektem,
142
planowanie dziaa zorientowane na produkty,

dekomponowanie projektu na atwo zarzdzane etapy,
zarzdzanie ryzykiem podczas caego cyklu realizacji projektu,
ustalone procedury postpowania,
dokadny i efektywny system dokumentowania,
kontrolowanie i zorganizowanie rozpoczcia, rozwinicia i zakoczenia projektu,
ledzenie postpw w stosunku do planw i zaoe,
automatyczna kontrola wszelkich odchyle od planu oraz elastyczno punktw
decyzyjnych,
zaangaowanie zarzdu i akcjonariuszy we waciwym czasie i stopniu w projekt.
Dla kierownik projektu moliwoci pakietu
opracowanie wstpnych zaoe przed rozpoczciem projektu oraz delegowanie
uprawnie, dzielenie projektu, raportowanie.
Rys. 9.1. Platforma startowa pakietu PRINCE 2-SPOCE CRM
9. Dodatek
143
Z rysunku 9.1 wida, e metoda PRINCE 2 porzdkuje czynnoci ich kolejno

oraz produkty, ktre maj powsta w trakcie prowadzenia projektu. W metodzie tej
wyrnia si PROCESY, do ktrych naley:
1. Przygotowanie zaoe projektu.
2. Konstruowanie projektu.
3. Strategiczne decyzje projektu.
4. Inne procesy.
Procesy te s wspomagane TECHNIKAMI, ktre udostpniaj narzdzia programowe lub przygotowane formularze, ktrych wypeniane jest elementem metody prowadzenia projektu. Zaczone ekrany (rys. 9.2) wskazuj na wykorzystywanie PERT
w analizie czasowej realizacji projektu, w ktrej szacuje si najwczeniejszy czas rozpoczcia zadania, najpniejszy czas rozpoczcia zadania, czas jego trwania, opnienie itd.
Rys. 9.2. Wyznaczanie cieki krytycznej i szacowanie zada w projekcie

za pomoc PERT w metodzie PRINCE 2
Przestrzeganie wszystkich zalece, ktre s zawarte w tzw. ELEMENTY, to midzy innymi struktura organizacyjna projektu zarzdzana zgodnie z metod PRINCE 2
(rys. 9.3).
144
Rys. 9.3. Opis struktury organizacyjnej projektu w metodzie PRINCE 2
9.2. Oprogramowanie wspomagajce

zarzdzanie zmianami
Jedn z decyzji, ktr naley podj we wczesnej fazie projektu, jest okrelenie
sposobu ledzenia zachodzcych w nim zmian. Powodzenie najmniejszych nawet
przedsiwzi informatycznych w istotny sposb zaley od tego, jakimi i czy odpowiednimi narzdziami bd dysponowali jego uczestnicy. Oprogramowanie przeznaczone do kontroli wersji powinno zapewnia analiz historii zmian i moliwo uzyskania kopii dowolnej wersji archiwizowanych artefaktw, umoliwia wprowadzanie
do projektu modyfikacji widocznych take dla innych jego uczestnikw i zapobiega,
lub chocia informowa, o powstaych w wyniku tych operacji konfliktach.
W najprostszym przypadku moliwe jest oczywicie wykorzystanie rcznie tworzonych i odpowiednio nazywanych kopii projektu. Podejcie to jest jednak bardzo
nieefektywne, podatne na bdy, utrudnia przegldanie zmian i jest praktycznie niemoliwe do zastosowania w zespoach wikszych ni jednoosobowe. Na szczcie
9. Dodatek
145
istnieje caa gama dedykowanego do tego celu oprogramowania, poczwszy od prostych narzdzi, przeznaczonych dla pojedynczych deweloperw, na zoonych systemach skierowanych do zespow liczcych setki uczestnikw. Przegld ten ma na celu
przedstawienie gwnych cech oprogramowania oraz wskazanie najbardziej znaczcych narzdzi wspomagajcych zarzdzanie zmianami.
Najczciej jest to oprogramowanie darmowe, lecz niekoniecznie z penym wsparciem ze strony producenta. Jest duo narzdzi dostpnych bez opat niektre z nich
s dostarczane z wikszoci systemw Unix, niektrych trzeba poszuka w Internecie. W niektrych przypadkach wymagaj samodzielnej kompilacji. Do wikszoci
darmowych narzdzi dostarczana jest wystarczajca dokumentacja. Poniewa wiele
z tych narzdzi jest dostarczana waciwie bez adnego wsparcia, nie zaleca si uywania ich w pewnych projektach. Dla kompletnoci zostay one ujte tutaj pomimo
potencjalnych wad.
9.3. Najpopularniejsze narzdzia Open Source

CSSC Compatibly Stupid Source Control (http://cssc.sourceforge.net/)
Dokonana przez Free Software Foundation reimplementacja najstarszego (i przed
pojawieniem si RCS jedynego) unixowego narzdzia kontroli wersji SCCS (Source
Code Control System). Jego zalet jest pena standaryzacja okrelona norm X/Open,
powodujca, e dostpne jest we wszystkich markowych wersjach systemw z rodziny
Unix. Oferuje funkcjonalno praktycznie identyczn z dostpn za pomoc RCS.
Obecnie nie jest ju praktycznie uywane.
RCS Revision Control System (http://www.gnu.org/software/rcs/rcs.html)
Jest to jedno z najstarszych (powstao w latach 80.) narzdzi. Program kontroluje
modyfikacje pliku rdowego i utrzymuje plik z list zmian, zawierajc informacje
potrzebne, by odtworzy dowoln poprzedni jego wersj. Pozwala w atwy sposb
zapisywa, odzyskiwa i odczytywa dane oraz czy wersje. Jest obsugiwany przez
wszystkie popularne w rodowisku Unix narzdzia programistyczne (w tym make).
Pracuje na poziomie pojedynczych plikw i nie oferuje mechanizmw uatwiajcych
prac grupow.
CVS Concurrent Versions System (http://www.cvshome.org/)
Jest to obecnie najpopularniejsze narzdzie z rodziny Open Source. Powstao
w 1986 r., by usprawni i rozszerzy moliwoci RCS, na ktrym si opiera. Jest syste-
146
mem w peni sieciowym, bazujcym na centralnym repozytorium. Umoliwia jednoczesn prac wielu programistw i oferuje mechanizmy automatycznego uzgadniania
wprowadzonych przez nich zmian. Znacznie lepiej ni RCS zarzdza zbiorami danych.
Podstawow jednostk informacji jest w nim pojedynczy plik, lecz przez uycie mechanizmu znacznikw pozwala rwnie odnosi si do caoci projektu. Umoliwia tworzenie odgazie. Zawiera mechanizm automatycznie rozwijanych sw kluczowych (np.
$Author$ jest rozwijany do systemowej nazwy autora pliku). Oferuje oczywicie take
dostp do penej historii wyda, informacji o autorach wprowadzonych zmian, nadanych
im komentarzach itp. Jest dostpny we wszystkich znaczcych systemach operacyjnych
i obsugiwany przez wszystkie popularne rodowiska programistyczne.
Subversion (http://subversion.tigris.org/)
Program pomylany jako nastpca CVS. Wychodzi z podobnych zaoe i oferuje
podobne funkcje, lecz stara si unika gwnych wad CVS. Operacje przydziau
znacznikw i tworzenia nowych odgazie s w nim znacznie szybsze. Dysponuje
lepszym wsparciem dla plikw binarnych. Oferuje wersjonowanie katalogw i metadanych repozytorium. Znacznie lepiej wspiera zmian nazw plikw i zapewnia atomizacj zmian repozytorium. Dane nie s przechowywane w formacie RCS, lecz
umieszczone w specjalnej bazie danych (aktualnie Berkeley DB). Mechanizmy sieciowe oferuje, wykorzystujc serwer Apache. Jest dostpny dla wszystkich wanych
systemw operacyjnych. Projekt nie doczeka si jeszcze bazy uytkownikw, choby
porwnywalnej z CVS, lecz prawdopodobnie w przyszoci bdzie stanowi dla niego
godn konkurencj.
Arch (http://arch.fifthvision.net/)
Arch jest obiecujcym, cho znajdujcym si jeszcze we wczesnej fazie rozwoju,
narzdziem, oferujcym cakowicie zdecentralizowane podejcie do zarzdzania kodem. W przeciwiestwie do programw kontynuujcych filozofi CVS, umoliwia kademu z deweloperw dysponowanie wasn kopi centralnego repozytorium i oferuje
narzdzia, umoliwiajce atw integracj repozytoriw. Znacznie lepsze ni w CVS
jest w nim wsparcie dla zmian nazw katalogw i plikw (do kadego z nich przydzielany jest niezaleny od jego nazwy znacznik). Zapewnia atomowo operacji, zaawansowane operacje na gaziach projektu i automatyczne generowanie plikw zmian
(ang. Changelog). Operacje wykonywane s w nim nie dla indywidualnych plikw
(jak w CVS), lecz na poziomie caego drzewa projektu. Mechanizmy sieciowe oparte
s o standardowe serwery, dostpne w systemach z rodziny Unix (ssh, ftp, http), co
uatwia konfiguracj i zmniejsza wymagania sprztowe. Obecnie istniej dwie gwne
wersje Arch utrzymywana przez oryginalnego autora, Toma Lorda
9. Dodatek
147
(http://arch.fifthvision.net/bin/view/Arch/WebHome) oraz, zmodyfikowana przez

Waltera Landry, ArX (http://arch.fifthvision.net/bin/view/Arx/WebHome). Pierwsza z nich wydaje si stabilniejsza, lecz z powodu korzystania ze skryptu sh, znacznie
wolniejsza, druga, napisana w C++, jest szybsza i oferuje kilka dodatkowych udogodnie.
Stellation (http://www.eclipse.org/stellation/)
Narzdzie oparte na wsppracy z zewntrzn baz danych. Umoliwia uycie
praktycznie dowolnej relacyjnej bazy oferujcej jzyk SQL. Zmiany zapisywane s
na poziomie caego projektu. Oferuje pen histori zmian w projekcie, wersjonowanie i zmiany nazw wszystkich artefaktw i w peni atomowe operacje. Umoliwia
wprowadzenie modyfikacji na poziomie linii kodu, a nie, jak zazwyczaj, caych
plikw.
Emacs rozszerzenia
Sam w sobie Emacs nie jest narzdziem do zarzdzania zmianami, jednake Emacs
19 zawiera tryb okrelony jako VC, zwiksza wpyw available from RCS, SCCS, or
CVS, oraz zmniejsza kopoty wynikajce z uywania tych narzdzi. VC automatycznie, ktra wersja systemu jest aktualnie wykorzystywana, dokonujc autokonfiguracji
do uywania systemu kontroli. (Systemy mona czy.) Ukryte w ten sposb zostaj
szczegy rejestracji, dostpu I blokowania plikw, ukrywajc je za jednym prostym
poleceniem wykonaj kolejny, logiczny krok. VC zawiera rwnie funkcje do przegldania rnic w wersjach zmian w historii, tworzenia i otrzymywania kolejnych
wersji. Wsparty zosta tryb Dired, ktry pozwala na wsadowe operacje kontroli wersji
na grupach plikw.
Dodatkowe informacje mona uzyska, wywoujc Emacs 19 i piszc `M-x info
RETURN m emacs RETURN m vc RETURN'. 3
Aegis
Aegis jest programem do nadzorowania zmian, opartym na licencji GNU. Jest to
raczej narzdzie developera, a nie menedera. Nie dostarcza mechanizmw ledzenia
postpu czy te rozmieszczenie pracy.
Podczas gdy CVS (opisywany poniej) dostarcza mechanizmy obsugi repozytorium, Aegis dostarcza mechanizmy obsugi repozytorium, linii bazowej oraz obowizkowych przegldw i testw. Aegis mona tak skonfigurowa, aby uywa niemale
dowolnego narzdzia do historii (jak np RCS) i niemal dowolnego narzdzia do kontrolowania zalenoci (np. make).
148
Najnowsze informacje i wersja Aegis s dostpne pod adresem:

http://www.canb.auug.org.au/~millerp/
BCS
BCS = Baseline Configuration System. Jest to system pracujcy wycznie w systemie UNIX.
CVS
CVS (Concurrent Versions System), ktry wymaga RCS (powyej wersji 1.10),
rozszerza RCS do kontroli konkurencyjnego edytowania rde przez kilku pracownikw.
Autor programu podaje nastpujc analogi: RCS jakby jzykiem asemblera,
podczas gdy CVS jest podobny do Pascala. Zaczynajc od wersji 1.8, CVS odnotowuje modyfikacj kadej linii pliku, z numerem korekty, nazw uytkownika dokonujcego modyfikacji i dat jej przeprowadzenia.
CVS mona cign z
ftp://ftp.cvshome.org/pub/.
http://www.loria.fr/~molli/cvs-index.html
http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/
Wersje pod Windows (WinCVS) powinny by dostpne pod
http://www.wincvs.org/
ICE
Wedug autorw ICE (Incremental Configuration Engine) jest narzdziem, ktre
dostarcza logiczne wsparcie dla wszystkich dziedzin zarzdzania konfiguracj, wczajc w to zintegrowane i zunifikowane zarzdzanie zmianami i korektami, repozytoria plikw binarnych, wnioskowanie o spjnoci konfiguracji.
Niestety uytkownicy zgaszaj do liczne problemy zwizane z zawieszaniem si
GUI i z funkcjonowaniem linii polece.
ICE nie jest ju wspierane, ale jest wci dostpne :
www.cs.tu-bs.de/softech/ice/
ODE
http://www.accurev.com/ode/index.html
Project Revision Control System (PRCS)
ftp://XCF.Berkeley.EDU/pub/prcs
9. Dodatek
149
http://www.xcf.berkeley.edu/~jmacd/prcs.html
PRCS jest oparte na licencji GNU.
RCS
RCS (Revision Control System), oparte na licencji GNU, utrzymuje ostatni lini
bazow i przyrosty poprzednich, co nieco przypiesza prac.
ftp://prep.ai.mit.edu/pub/gnu/rcs/
http://www.winsite.com/
http://www.fsf.org/order/windows.html
SCCS
SCCS (Source Code Control System) jest rozpowszechniane z wikszoci dystrybucji systemu Unix.
ShapeTools
Program pod Unixa.
ftp://gatekeeper.dec.com/pub/plan/shape/
http://swt.cs.tu-berlin.de/~shape/index.html
Ant
Program oparty na Javie
http://jakarta.apache.org/ant/
Bake
http://bake.werken.com/
Bras
http://wsd.iitb.fhg.de/~kir/brashome/
BuildRef
http://www.sander.cupertino.ca.us/source.html
Cons
http://www.dsmit.com/cons/
http://www.baldmt.com/cons-faq/
150
9.4. Oprogramowanie komercyjne

do zarzdzania zmianami
Wraz ze wzrostem kosztw wytwarzania oprogramowania coraz wicej firm oferuje autonomiczne narzdzia zarzdzania konfiguracj. Poniej wymieniono programy
najczciej wymienianie przez uytkownikw
+1CM
+1CM dostarczany przez +1 Software Engineering jest jednym z 14 produktw
wspierajcych +1Environment. Umoliwia prac wielu uzytkownikom nad projektem poprzez sie. +1CM wspiera wszystkie podstawowe problemy zarzdzania
konfiguracj, linie bazowe. Zawiera rwnie predefiniowane raporty. Jzyki
wspierane : C, C++, FORTRAN, Pascal, Ada i inne.
http://www.plus-one.com
2AllChange
AllChange jest narzdziem do zarzdzania konfiguracj i kontroli zmian dystrybuowanym przez Intasoft. Jego cechy to:
tworzenie wersji, ich ledzenie, odtwarzanie zmian,
definiowane przez uytkownika cykle ycia z automatycznym wyzwalaniem
akcji i procedur,
ledzenie da zmian,
workspaces, shared pools,
obsuga linii bazowej, wyda, ...
udogodnienia w raportowaniu/zapytaniach,
generowanie metryk i graficznych raportw,
cakowita konfigurowalno (jzyk skryptowy),
GUI Motif/Windows lub linia polece,
dostpne pod Unix, Windows 3.x, NT i 95,
wsparcie modelu client/server.
Uytkownicy uwaaj ten program jako elastyczne narzdzie zarzdzania konfiguracj, z dobrym wsparciem ze strony producenta.
http://www.intasoft.net
ChangeMan
http://www.serena.com Pakiet umoliwiajcy kontrolowanie konfiguracji sprztu,
platform bazodanowych oraz rodowiska developerskiego.
9. Dodatek
CM Synergy
http://www.telelogic.com/
CMF
http://www.cmvision.com/
Code Co-op
http://www.relisoft.com/co_op/
CMS and MMS
http://www.openvms.compaq.com/commercial/decset/decset_index.html
PVCS
http://www.qef.com
Quma Version Control System (QVCS)
ftp.clark.net in /pub/jimv/qvcs1625.zip
/pub/jimv/qvcs3225.zip
http://www.qumasoft.com/
RAZOR
http://www.razor.visible.com
Software Configuration Library Manager (SCLM)
http://www.ibm.com/software/ad/ispf/
Software Manager
http://www.verticalsky.com/solutions/
151
152
Source Code Manager

http://www.unipress.com/free_evals/
eridani.unipress.com/pub/free_evals
StarTeam
http://www.starbase.com
TeamConnection
http://www.software.ibm.com/ad/teamcon/
TeamSite
http://www.interwoven.com/
TRUEchange
http://www.truesoft.com/
VisualEnabler
http://www.softlabna.com/
Visual SourceSafe
SourceSafe dostarcza mechanizmy kontroli konfiguracji dla rzeczywistych projektw. W 1995 r. SourceSafe zosta przejty przez Microsoft i ponownie nazwany. Wedug dziau sprzeday, Microsoft narzdzia konwersji z takich programw, jak Delta i
PVCS. Wersja 4.0 wspiera dugie nazwy plikw i cieki UNC, a tab dialog for setting
options, jest w 5 jzykach, zgodny z designem Windows 95. VSS jest cile zintegrowany z Visual Basic, Visual C, Visual Test oraz z Fortran PowerStation. Posiada bardzo miy model do ustawiania wielu wersji projektu. Kluczowe polecenia dotycz
wspdziele, rozgazie, scalania, czenia i komend cieki. Zamiast uywa licznych rozgazie, tak jak wersja 2.3.6.1 SCCS, logiczne wydania lub nazwy uytkownika mog by uyte do osignicia tej samej konstrukcji. SourceSafe take pracuje na
wielu platformach systemowych, moe by uyte w pojekcie opartym na modelu
klient/serwer, gdzie kodowanie odbywa si w Visual Basicu pod Winnows na komputerze PC Windows PC using Visual Basic i na stacji Unixowej, gdzie si uywa C.
Microsoft System Journal (maj, 1993 r.) nazwany SourceSafe jest najlepszym narzdziem zarzdzania konfiguracj dla systemu Windows. Jedn komend w SourceSafe
9. Dodatek
153
mona zrobi zdjcie caego projektu, przypisujc jednoczenie nazw wersji. Ta

operacja jest bardzo szybka, nawet jeli project zawiera 2000 programw. SourceSafe
jest zintegrowany z VisualStudio, ktre automatycznie uzyskuje dostp do kodu podczas pracy programistw.
Mwi si, e uytkownik moe mie jednoczenie dostp do kilku projektw
w VSS, ale bezpieczestwo w SourceSafe dobrze dopracowane; posiada tylko 4 bezpieczestwa: read-only, checkout, add i destroy. To moe by niewystarczajce dla
niektrych projektw. Zostao zgoszonych wiele przypadkw uszkodze repozytoriw danych, zwaszcza duych.
http://msdn.microsoft.com/ssafe/
MainSoft Visual SourceSafe for UNIX
http://www.opengate.co.uk/opengate/
Metrowerks Visual SourceSafe for Macintosh
Metrowerks wytwarza wersje Visual SourceSafe na Macintosha. Oprogramowanie to jest w peni kompatybilne z Microsoft Visual Source Safe. Dodatkowe
informacje :
http://www.metrowerks.com.
Voodoo
ftp.swe.uni-linz.ac.at/pub/voodoo
http://www.unisoft.co.at/products/voodooserver.html
9.5. Narzdzia open source

do zarzdzania projektami
Narzdzia open source do zarzdzania projektami
Funkcjonalno dostpnych obecnie produktw open source pozostaje daleko
w tyle za produktami komercyjnymi. Darmowe programy OpenSched, PyGantt
i QtGantt (patrz ramka Zajrzyj) znajduj si w wersjach bardzo wstpnych i s nieudokumentowane. Dwa pierwsze to narzdzia generujce raporty, uruchamiane
z odpowiednimi parametrami z wiersza polece. QtGantt jest narzdziem wyposaonym w interfejs graficzny. Wszystkie programy s przeznaczone dla platformy
Linux, przy czym PyGantt moe by te uruchamiany na innych systemach z zainstalowan obsug jzyka Python.
154
OpenSched 0.1.0 ma najwiksze moliwoci, jako jedyny uwzgldnia zarzdzanie zasobami ludzkimi. Tworzy spory zbir raportw zawierajcy: list zada, powizania
zasobw ludzkich z zadaniami, zalenoci
pomidzy zadaniami, list dni wolnych (poza
weekendami), tygodniowe i miesiczne spisy
zada, wykres Gantta. Zestawienia tekstowe s bardzo eleganckie, wykres Gantta
do saby. Dane wejciowe program pobiera z pliku tekstowego o do dobrze
przemylanej strukturze. Na wyjciu jest dokument LaTeX-a, ktry nastpnie moe
by przekonwertowany do formatu PostScript lub PDF. Skrtowy opis formatu danych wejciowych znajduje si w przykadowych plikach wejciowych.
PyGantt 0.6.0 jest narzdziem do generowania wykresw Gantta, napisanym jako
skrypt w Pythonie. Przystosowano go
wprawdzie do systemu Linux, jednak po
niewielkiej zmianie moe by rwnie uruchamiany pod Windows oczywicie po zainstalowaniu obsugi jzyka Python. Dane
wejciowe zapisane s w formacie XML.
Struktura pliku nie jest w ogle udokumentowana; aby j opanowa, naley przeanalizowa doczony przykad. Skrypt generuje na wyjciu niedopracowany dokument HTML zawierajcy wykres Gantta. Na
koniec niespodzianka: PyGantt podczas tworzenia wykresu nie uwzgldnia w ogle
dni wolnych(!), dlatego przydatno narzdzia jest na razie adna.
QtGantt 0.0.7. jako jedyne z wymienionych
tu narzdzi oferuje graficzny interfejs wykorzystujcy bibliotek Qt. Program zawiera cztery widoki, z ktrych na razie tylko dwa zostay
zaimplementowane: ogldanie wykresu Gantta
i podgld wydruku wykresu. Wykres prezentuje list zada z punktami kontrolnymi, informuje
o stopniu zaawansowania poszczeglnych zada i porwnuje je z lini bazow. Funkcjonalno programu ogranicza si jednak do
otwierania
plikw,
prezentacji
ich
na
ekranie
i wydruku. Dane wejciowe zawarte s w pliku tekstowym o strukturze bardzo prostej,
ale nie do koca przemylanej edycja zada jest uciliwa. Opis struktury danych
wejciowych znajduje si w plikach przykadowych.
9. Dodatek
Opis wg PCkurier 2/2002 [52].
155
Literatura
[1] Abran A., Robillard P. N., Identification of the structural weaknesses of Function Point metrics,
3rd Annual Oregon Workshop on Software Metrics, Portland, Oregon, March 1991.
[2] Anthony R., Planning and Control System: A Framework for Analysis, Harvard Business Review, 1965.
[3] Badiru A.B., Project Management in Manufacturing and High Technology Operations, Willey,
New York, 1988.
[4] Boehm W.B. and all, Software cost estimation with COCOMO II, Prentice-Hall, July 2000.
[5] Bates P., Huws U., Modeling eWork in Europe Estimates Models and forecasts from the EMERGENCE
project, http://www.employment-studies.co.uk/summary/summary.php?id=388.
[6] Bradley K., Podstawy metody Prince 2, Wydane przez: Centrum Rozwiza Menederskich S.A.,
00-272 Warszawa, Rynek Starego Miasta 21/21A/9.
[7] Burton C., Michael N., Zarzdzanie projektem: Jak to si robi w Twojej Organizacji, Astrum 1999.
[8] Byzia T., Szybkie diagnozowanie procesw jako przykad metodyki podnoszenia jakoci zarzdzania projektem informatycznym, II Konferencja Project Management perspektywy i dowiadczenia, Stowarzyszenie Project Management Polska (SPMP), Gdask, 2000.
[9] Cegiea R., Zalewski., Racjonalne zarzdzanie przedsiwziciami informatycznymi i systemami
komputerowymi, Nakom, Pozna 2000.
[10] Charfield C.S., Jonson T.D., Microsoft Project 2000, RM 2000.
[11] Chrocicki Z., Zarzdzanie projektem zespoami zadaniowymi, Wyd. C.H. Beck, Warszawa 2001.
[12] Cleland D.I., Kimball R.K., The Strategic Context of Projects, Project Management Journal, August 1987.
[13] Chylewska J., Jak walczy o najlepszych w firmie, jak zatrzyma kluczowych pracownikw, Materiay firmy. Hewitt Associates:
http://was.hewitt.com/hewitt/worldwide/europe/poland/articles/publikacje/jak_zatrzyac_kluczowych.pdf.
[14] De Marco Toom., The Deadline, Dorest Hors Publishing, 1997.
[15] Den J. W. Junior, Junior, Evans J.R., Total Quality Management, Organization and Strategy, St.
Paul MN, West, 1994.
[16] Duncan W., A guide to the project management body of knowledge, PMI Standards Committee, PA
19082 USA.
[17] Frczkowski K., Lapkiewicz J., Zarzdzanie wirtualne zasobami projektu informatycznego realizowanego w firmie o strukturze macierzowej, Materiay VII Konferencji i Warsztatw uytkownikw ORACLE. Ploug 2001, Zakopane Kocielisko 2327.10.2001.
[18] Frczkowski K., Mechliski T., Telepraca i zarzdzanie wirtualne w projektach informatycznych,
Materiay VIII Konferencji i Warsztatw uytkownikw ORACLE. Ploug 2001, Zakopane Kocielisko 2226.10.2002. http://www.ploug.org.pl/konf_02/materialy/spis.htm.
[19] Frczkowski K., Woniak M., Wdroenie systemu informatycznego w szpitalu aspekty organizacyjne, psychologiczne oraz formalne, Oficyna Wydawnicza Politechniki Wrocawskiej, Wrocaw
2000.
[20] Goldratt E.M., acuch krytyczny, Wyd. Werbel 2000.
162
[21] Grudzewski W.M., Hejduk I., Sposoby i techniki zarzdzania projektem innowacyjnym, II Konferencja Project Management perspektywy i dowiadczenia, Stowarzyszenie Project Management
Polska (SPMP), Gdask, 2000.
[22] Griffin R.W., Podstawy zarzdzania organizacjami, Wyd. PWN 1996.
[23] Grski J., Inynieria Oprogramowania w Projekcie Informatycznym, Wyd. Mikom, Warszawa
2000.
[24] Haywood M., Managing Virtual Teams: Practical Techniques fir Hight Technology Projekt
Managers, Artech House, Bostom London, 1998.
[25] Hubbard D.G., Work Structuring, in P.C. Dismore ed., The AMA Handbook of Project Management, AMACOM, New York, 1993.
[26] IFPUG, International Function Point Users Group, Function Point Counting Practices Manual,
Release 3.0, IFPUG, Werterrille, Ohio, 1990.
[27] Jaszkiewicz A., Inynieria Oprogramowania, Wyd. Helion, Gliwice 1997.
[28] Jonem C., Assessment and Control of Software Risks, Yourdon Press, New Jersey, 1994.
[29] Kamerlas H., A Look at Major Planning Methods: Deployment, Implementation, Strengths and
Limitations, Long Rage Planning, August 1978.
[30] Kumierowski S., Przeciwdziaanie zagroeniom w projektach uruchamiania instytucji typu call
center, II Konferencja Project Management perspektywy i dowiadczenia, Stowarzyszenie Project Management Polska (SPMP), Gdask, 2000.
[31] Lapkiewicz J., Frczkowski K., High-Availability Infrastructure Architecture, Web Hosting Transition. Materiay VII Konferencji i Warsztatw uytkownikw ORACLE. Ploug 2001. Zakopane
Kocielisko 2327.108.2001.
[32] Liberatore M.J., A Decision Support System Linking Research And Development Project Selection
with Business Strategy, Project Management Journal, November 1988.
[33] Love S.F., Achieving Problem-Free Project Management, Wiley, New York, 1989.
[34] Managelli R.J., Klein Mark N.M., Reengineering, Wyd. PWN 1998.
[35] Mayer M., The virtual Edge, Published by: Project Management Institute Headquarters, 1998.
[36] Meredith J.R., Mantel S.J. Jr., Project Management, A Managerial Approach, third edition, John
Willey & Sons, Inc., New York, 1995.
[37] McConnell S., Rapid Development, Microsoft Press, 1996.
[38] Micklelhwait J., Woddridge A., Szamani zarzdzania, Wyd. WNT, 2000.
[39] Murawa Projekt: Project Management: Rola i usytuowanie w przedsiwziciu projektowym
w Polsce i Szwecji, II Konferencja Project Management perspektywy i dowiadczenia, Stowarzyszenie Project Management Polska (SPMP), Gdask, 2000.
[40] OConnel F., How to run successful projects II-the silver bulle, Wyd. T.J. International Ltd.
[41] Pniewski K., Koszty dziaa pod kontrol, PC Kurier nr 22/2000.
[42] Sajkowicz A., Zasoby ludzkie w firmie, Poltex, Warszawa, 2000.
[43] Stokolski B., Perspektywy zarzdzania projektami wobec nowych wyzwa IT, II Konferencja Project Management perspektywy i dowiadczenia, Stowarzyszenie Project Management Polska
(SPMP), Gdask, 2000.
[44] Sownik Jzyka Polskiego, PWN, Warszawa, 1981.
[45] Szych J., Typowe zagroenia w projektach informatycznych w administracji pastwowej, II Konferencja Project Management perspektywy i dowiadczenia, Stowarzyszenie Project Management
[46] Szyjewski Z., Analiza strategiczna w tworzeniu systemw informatycznych, [w:] Studia Informatica
nr 9, Zeszyty naukowe projects II the silver bulle. Wyd. T.J. International Ltd.
[47] Szyjewski Z., Zarzdzanie Projektem Informatycznym, Agencja Wydawnicza Placet, Warszawa, 2001.
[48] Tarnowski B.T., Project Management elastyczno czy kaftan bezpieczestwa?, II Konferencja
Project Management perspektywy i dowiadczenia, Stowarzyszenie Project Management Polska
Literatura
163
(SPMP), Gdask, 2000.

[49] Thayer R.H., Software Engineering Project Management, Published by the IEEE Computer Society
Press, 1987.
[50] Tyrowicz A., Od klski do sukcesw rozwj zarzdzania realizacj projektw informatycznych
w administracji celnej, II Konferencja Project Management perspektywy i dowiadczenia, Stowarzyszenie Project Management Polska (SPMP), Gdask, 2000.
[51] Webster J.L., Reif W.E., Bracker J.S., The Managers Guide To Strategic Planning Tools and
Techniques, Planning Review, Nov/Dec 1989.
[52] Wojtan G., Przyszo Project Management w Polsce z perspektywy midzynarodowej, II Konferencja Project Management perspektywy i dowiadczenia, Stowarzyszenie Project Management
[53] www.standishgroup.com.
[54] www.isbsg.org.au.
[55] www.pckurier.pl/archiwum/art0.asp?ID=5284&haslo=projekt%20informatyczny.
[56] www.pmi.org.
[57] www.spmp.org.pl.
[58] www.sunset.usc.edu/research/COCOMOII/index.html.
[59] Yourdon E., Marsz ku klsce, WNT, 2000.
[60] Zieliski B., Microsoft Project 98, Mikom 2000.

Zarz 261 Dzanie Projektem Informatycznym

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zarz 261 Dzanie Projektem Informatycznym

Uploaded by

Copyright:

Available Formats

Kazimierz Frczkowski

Oficyna Wydawnicza Politechniki Wrocawskiej

Wydzia Informatyki i Zarzdzania

Opracowanie redakcyjne i korekta

Copyright by Oficyna Wydawnicza Politechniki Wrocawskiej, Wrocaw 2003

OFICYNA WYDAWNICZA POLITECHNIKI WROCAWSKIEJ

Drukarnia Oficyny Wydawniczej Politechniki Wrocawskiej. Zam. nr 633/2003.

w tym zakresie. Otrzymanie certyfikatu ESI czy si z fundamentalnym poznaniem

1. Geneza zarzdzania projektami

1. Geneza zarzdzania projektami

poszanowania i godnoci, dlatego w kierowanej przez siebie przdzalni w New

Zarzdzanie projektem informatycznym

cia celu, jakim byo panowanie na morzu.

1000 p.n.e 1500 n.e

Rys. 1.1. Prekursorzy zarzdzania i przeomowe ich dokonania,

1. Geneza zarzdzania projektami

1.2. Podstawowe pojcia i definicje

Zarzdzanie projektem informatycznym

nego urzdzenia, przedmiotu, systemu informatycznego lub obiektu budowlanego.

1. Geneza zarzdzania projektami

projektu wyszczeglnione w specyfikacji projektu. W niektrych przypadkach moe

Zarzdzanie projektem informatycznym

1.3. Czynniki charakterystyczne projektu

1. Geneza zarzdzania projektami

Zarzdzanie projektem informatycznym

cji. Zmiany w procesach najczciej s wprowadzane sukcesywnie w dugim okresie,

1. Geneza zarzdzania projektami

2. Planowanie projektu informatycznego

Zarzdzanie projektem informatycznym

3. Jak duo czasu powici na planowanie?

2.1. Cele planowania projektu

2. Planowanie projektu informatycznego

koszt, czyli rodki finansowe, ktre moemy wykorzysta do realizacji projektu

2.2. Definiowanie celw projektu

Zarzdzanie projektem informatycznym

2.3. Zasoby projektu

2. Planowanie projektu informatycznego

2.4. Definiowanie ogranicze w projekcie

Zarzdzanie projektem informatycznym

2. Planowanie projektu informatycznego

Przegld opisu projektu

Wybr strategii prowadzenia

Rys. 2.2. Etapy i czynnoci przygotowawcze zwizane z planowaniem projektu

Zarzdzanie projektem informatycznym

2.5. Strategia realizacji projektu

2. Planowanie projektu informatycznego

2.6. Ocena ryzyka

Zarzdzanie projektem informatycznym

znaczcy wpyw na prac ludzi,

2.7. Struktura projektu dekompozycja projektu

2. Planowanie projektu informatycznego

Zarzdzanie projektem informatycznym

komponentw WBS. Kady element WBS jest unikatowy. Na poziomie zerowym

2. Planowanie projektu informatycznego

Zarzdzanie projektem informatycznym

CWBS zawiera wicej szczegw zwizanych z zarzdzaniem prac nad projektem,

bad. potrzeb uytkownika

Aby praktycznie zilustrowa etapy, jak rwnie sposb tworzenia diagramw

2. Planowanie projektu informatycznego

Projekt planu technicznego. Projekt planu zasobw. Projekt uzasadnienia przedsiwzicia.

2.8. Szacowania w projekcie

Zarzdzanie projektem informatycznym

Dyskusja testw akceptacyjnych.

2. Planowanie projektu informatycznego