Zarzadzanie Projektem

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 ............................................................................................................................................ 5
Wprowadzenie ................................................................................................................................... 6
1. Geneza zarzdzania projektami ..................................................................................................... 8
1.1. Przegld historyczny wybranych zagadnie zarzdzania .................................................... 8
1.2. Podstawowe pojcia i definicje stosowane w zarzdzaniu projektami ................................. 11
1.3. Czynniki charakterystyczne projektu ................................................................................... 13
1.4. Proces ................................................................................................................................... 14
2. Planowanie projektu informatycznego .......................................................................................... 17
2.1. Cele planowania projektu ..................................................................................................... 18
2.2. Definiowanie celw projektu ............................................................................................... 19
2.3. Zasoby projektu ................................................................................................................... 20
2.4. Definiowanie ogranicze w projekcie .................................................................................. 21
2.5. Strategia realizacji projektu ................................................................................................. 24
2.6. Ocena ryzyka ....................................................................................................................... 25
2.7. Struktura projektu dekompozycja projektu na zadania WBS ......................................... 26
2.8. Szacowania w projekcie ....................................................................................................... 31
2.9. Metoda punktw funkcyjnych ............................................................................................. 34
2.10. Harmonogram ...................................................................................................................... 45
2.11. Sieciowe diagramy zalenoci ............................................................................................. 48
2.12. Inicjowanie projektu ............................................................................................................ 50
3. ledzenie i zarzdzanie zmianami projektu ................................................................................... 52
3.1. ledzenie projektu monitorowanie .................................................................................... 52
3.2. Zarzdzanie jakoci w projekcie ........................................................................................ 53
3.3. rda i rodzaje zmian ......................................................................................................... 59
3.4. Proces zarzdzania zmianami .............................................................................................. 60
3.5. ledzenie i nadzorowanie czasu oraz kosztw projektu ....................................................... 65
3.6. Nadzorowanie projektu metod wartoci uzyskanej (Earned Value) ................................... 66
3.7. Podsumowanie ..................................................................................................................... 74
4. Modele pracy i komunikacji .......................................................................................................... 77
4.1. Telepraca .............................................................................................................................. 78
4.2. Modele organizacji pracy zespow projektowych .............................................................. 80
4.3. Elektroniczny czonek zespou zesp .............................................................................. 85
4.4. Wirtualna sie partnerw przedsiwzicia ........................................................................... 89
4.5. Zespoy Projektowe ............................................................................................................. 91
4.6. Praca grupowa ...................................................................................................................... 92
5. Zarzdzanie ryzykiem ................................................................................................................... 94
5.1. Czynniki majce wpyw na ryzyko ...................................................................................... 99
4 Spis treci
5.2. Identyfikacja ryzyka metody analizy ryzyka kwestionariusze, listy kontrolne .............. 102
5.3. Akcje naprawcze .................................................................................................................. 104
5.4. Metoda punktowa szacowania ryzyka ................................................................................. 105
5.5. Metoda PERT szacowania ryzyka ....................................................................................... 113
6. Projekty wdroeniowe outsourcing ............................................................................................ 118
6.1. Rodzaje projektw informatycznych oraz organizacja pracy i zespow ............................ 118
6.2. Wdroenie przez outsourcing .............................................................................................. 121
7. Czynniki sukcesw i niepowodze projektw .............................................................................. 125
7.1. Niektre badania statystyczne niepowodze projektu ......................................................... 125
7.2. Wpyw wielkoci projektu na jego sukces ........................................................................... 128
8. Rola i zadania kierownika projektu ............................................................................................... 130
8.1. Usytuowanie kierownika projektu a jego skuteczno ......................................................... 131
8.2. Dobr czonkw zespou ...................................................................................................... 132
8.3. Rekrutacja czonkw zespou ............................................................................................... 133
8.4. Budowa kompetencji w projekcie ........................................................................................ 136
8.5. Konflikt ................................................................................................................................ 136
8.6. Motywowanie ...................................................................................................................... 136
8.7. Delegowanie uprawnie ....................................................................................................... 139
9. Dodatek ......................................................................................................................................... 141
9.1. Metoda zarzdzania projektami PRINCE-2 ......................................................................... 141
9.2. Oprogramowanie wspomagajce zarzdzanie zmianami ..................................................... 144
9.3. Najpopularniejsze narzdzia open source ............................................................................ 145
9.4. Oprogramowanie komercyjne do zarzdzania zmianami ..................................................... 150
9.5. Narzdzie open source do zarzdzania projektami .............................................................. 153
Sownik poj i terminw .................................................................................................................... 155
Literatura ............................................................................................................................................. 161
Od autora
Niniejsza ksika stanowi prb opracowania zagadnie zwizanych z zarzdza-

niem przedsiwziciami informatycznymi. Obejmuje wybrane wspczesne pogldy
na tematy, ktre s kluczowe w obszarze planowania, zarzdzania zmianami, organi-
zacji zespow projektowych, szacowania kosztw, monitorowania ryzyka i decyduj
o sukcesie lub niepowodzeniu projektu. Celem opracowania jest rwnie prba po-
dzielenia 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 Politech-
niki 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 zagad-
nienia z tej dziedziny, narzekali na brak polskiej literatury z tego przedmiotu, przez co
stymulowali prac nad ksik. Studenci, ktrzy uczestniczyli w dojrzaych dysku-
sjach na seminariach i przygotowali interesujce wystpienia, stali si poniekd
wspautorami niniejszego opracowania.
Ksika jest przeznaczona dla studentw informatyki i zarzdzania oraz kierowni-
kw projektw. Zawarto opracowania to prba osignicia kompromisu midzy
rozlegym zakresem tematycznym tego zagadnienia a programem studiw, ktry opra-
cowalimy wsplnie z pani dr in. Iwon Dubielewicz, ktrej dzikuj za cenne pro-
pozycje 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 wy-
przedzeniem planujemy ubieganie si o funkcj kierownika projektu PM. Najcz-
ciej 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 cer-
tyfikacji 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 dziedzi-
nie rozwija si bardzo dynamicznie i tylko stae podnoszenie kompetencji oparte na
dowiadczeniu przodujcych w zarzdzaniu projektami instytutw naukowych i sto-
warzysze branowych gwarantuje przewag konkurencyjn ich adeptom.
Wiedza na temat zarzdzania projektami nie powinna by zarezerwowana jedynie
dla najwyszego kierownictwa, odpowiedzialnego za caoksztat organizacji. Tej gru-
pie jest ona bezsprzecznie potrzebna do realizacji celw strategicznych, podejmowa-
nia 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 uzy-
skanie przez uczestnika kursu gruntownego wyksztacenia i nabycia kompetencji
Wprowadzenie 7
w tym zakresie. Otrzymanie certyfikatu ESI czy si z fundamentalnym poznaniem

niezbdnej tematyki zwizanej z zarzdzaniem projektem i otwiera drog do uzyska-
nia dyplomu Project Management Professional (PMP). Nie bez znaczenia i nie przy-
padkiem przedmiot ten znalaz si w programie studiw na kierunku informatyka.
Mam skromn nadziej, e praca ta pomoe w pewnym stopniu Czytelnikowi w szer-
szym spojrzeniu na realizacj przedsiwzi informatycznych, uwzgldniajc w za-
rzdzaniu 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 efektyw-
nymi metodami zarzdzania. W Egipcie nie powstayby piramidy, gdyby przy ich
budowie nie zastosowano takich elementw zarzdzania, jak planowanie, organizo-
wanie i kontrolowanie zaplanowanych prac. Aleksander Wielki, zwany Macedo-
skim (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 przywdz-
twa w 900 roku n.e. Ksztatowanie si dokona w dziedzinie zarzdzania przedsta-
wiono 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 do-
strzeg 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
1. Geneza zarzdzania projektami 9
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 kon-
cepcjami by zachwycony car Mikoaj I, od ktrego otrzyma propozycj osiedle-
nia si w Rosji wraz z 2 mln angielskich robotnikw. Mimo e nie znalaz nala-
dowcw 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 pro-
dukcji. Babbage wiza wielkie nadzieje z podziaem pracy i by ordownikiem
zastosowania matematyki do takich problemw, jak efektywne wykorzystanie ma-
szyn, 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 uzy-
skiwa wysz jako produkowanych wyrobw.
Prekursorzy zarzdzania
Wspczenie zarzdzanie kojarzy nam si przede wszystkim z duymi przedsi-

biorstwami, korporacjami, organizacjami, ktre s kierowane przez zarzdy, preze-
sw, rady nadzorcze. Zanim do tego doszlimy, na przestrzeni wielu stuleci yy naro-
dy i ich wybitni przedstawiciele, ktrzy stworzyli podwaliny naszej cywilizacji.
Sumerowie znani s z metod zarzdzania opartych na spisanych przepi-
sach,
Egipcjanie stworzyli reguy i praktyki w budowie piramid,
Babiloczycy zaczli stosowa szeroki zestaw aktw prawnych i rodkw poli-
tycznych 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 rzdo-
wych oraz w dziedzinie sztuki,
Wenecjanie zastosowali projektowanie organizacji i planowanie do osigni-
10 Zarzdzanie projektem informatycznym
cia celu, jakim byo panowanie na morzu.
Grecy
Babiloczycy Wenecjanie
Egipcjanie Rzymianie
Sumerowie 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 wy-
wary 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 przy-
wdztwa w zarzdzaniu,
Robert Owen 17711858 zmieni sposb traktowania i nada due
znaczenie warunkom ludzkiej pracy,
Charles Babage 17521871 koncentrowa si na efektywnoci produk-
cji,
Frank Gilberth 18681924 projektant wydajnych stanowisk pracy,
Lilian Gilbert 18791972 prace nad optymalizacj np. optymalizacja
sposobu ukadania cegy, psychologia prze-
mysu, 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.
1.2. Podstawowe pojcia i definicje

stosowane w zarzdzaniu projektami
Zarzdzanie
Definicji zarzdzania jest wiele, tak jak ksiek na ten temat. Wikszo z nich d-
y do zwizego i precyzyjnego zdefiniowania istoty zagadnienia, jednak to czym jest
zarzdzanie zaley od szczebla, obszaru i organizacji, gdzie nastpuje proces zarz-
dzania. 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 kompeten-
cji i czynnoci nalecy do kierownika projektu, wwczas zarzdzanie moemy zdefi-
niowa jako og dziaa zmierzajcych do efektywnego wykorzystania zespow ludz-
kich, 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 reali-
zowanym wczeniej. Dotyczy nowej sytuacji, wymaga nierutynowego podejcia. Nie
moemy polega na historycznych sposobach postpowania z danym problemem. Pro-
jekt jest to przedsiwzicie, na ktre skada si zesp czynnoci, ktre s charaktery-
styczne przez to, e maj dat rozpoczcia, specyficzne cele i limity, ustalone odpowie-
dzialnoci (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 decy-
duj 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, parame-
trw uytkowych, zgodnoci ze standardami, trwaoci, niezawodnoci, atwoci napra-
wy i dajcego si odrni od innych projektw stylu. Projekt ma wizje, najczciej
zawiera rysunki, schematy, obliczenia, opisy, kosztorysy itp. dotyczce wykonania da-
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 udo-
stpniacie 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 za-
kres, takie jak:
Projekt od dou do gry (ang. Buttom-up design) proces projektowania sys-

temu 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 sys-
temu 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 iny-
nierii oprogramowania moe by czci wikszego projektu. Projekt inynierii opro-
gramowania 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 projek-
tu, wyszczeglnione w uzgodnieniach projektowych. W niektrych przypadkach pro-
jekt 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 zaspo-
kojenia terminw i warunkw realizacji projektu. Projekt inynierii systemu jest
czynnoci charakteryzujc si dat startu, specyficznymi celami i limitami, ustano-
wionymi obowizkami, budetem i planem oraz dat ukoczenia. Zuywa zasoby i ma
na celu wytworzenie produktu lub zestawu produktw, ktre zaspokajaj wymagania
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 architek-
tury 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 ar-
chitektury, jej skadnikw, moduw funkcjonalnych, interfejsu, danych, sprz-
tu/oprogramowania dla systemu w celu zaspokojenia wyszczeglnionego wymagania
systemu. 2. Wynik przebiegu procesw projektowania systemu. Bliskoznaczny pro-
jektowi architektury. Patrz te projekt oprogramowania.
Projekt wstpny (ang. Preliminary desing) 1. Proces analizowania alternatyw

projektu oraz definiowania architektury sprztu/systemu oprogramowania. W inynie-
rii oprogramowania wstpny projekt zwykle zawiera definicj oraz struktur kompute-
rowych skadnikw programw i danych, definicje interfejsw oraz przygotowanie
rozmieszczenia w czasie i oszacowania kosztw. 2. Wynik przebiegu procesw pro-
jektowania wstpnego. Niekiedy rozumiany jako opis projektu wstpnego.
Projektowanie-do-kosztu (ang. Desing-to-cost) podejcie w zarzdzania projek-

tem, polegajce na utrzymania projektu w granicach kosztu przewidzianego w harmo-
nogramie. To znaczy, e przebieg projektowania jest oceniany (oszacowywany) po-
przez 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 kosz-
tw (zwykle 1520%), szukajc praktycznego kompromisu midzy operacyjnymi
moliwociami wykonawczymi, zakresem i harmonogramem.
Projektowanie szczegowe (ang. Detalied design) 1. W inynierii oprogramowa-

nia 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 projektowa-
nia. Niekiedy bliskoznaczny z opisem specyfikacji projektu szczegowego.
1.3. Czynniki charakterystyczne projektu
Jak ju wczeniej wspomniano, projekt informatyczny charakteryzuje si innowa-

cyjnoci, 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 pra-
cy (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 pro-
jekt kontekstu organizacyjnego firm zaangaowanych w jego realizacj i niezrozumie-
nie 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 zwiza-
nych 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 zdefi-
niowa 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 kt-
rych mona osign zaoony cel,
uoenie dokadnego planu dziaania, zmierzajcego do osignicia celu przy za-
stosowaniu najlepszych w obecnych warunkach rodkw,
wykonanie skrupulatnie zaoonego planu,
skontrolowanie osignitych wynikw i porwnanie z zamierzonym celem wy-
cignicie wnioskw na przyszo (do nastpnego planu projektu).
Mona zatem wnioskowa, e wymienione elementy racjonalnego dziaania byy
podstaw wspczesnego pojmowania realizacji projektw.
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 eko-
nomiczny 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]. Pro-
jektem jest na przykad zbudowanie nowego poczenia kolejowego midzy miejsco-
woci 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 realizo-
wane 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 szcze-
gln jest realizacja procesw lub projektw. Prowadzenie dziaalnoci procesowej
powinno by zdefiniowane i zweryfikowane w wielu konkretnych typowych realiza-
cjach. Zespoy wykonawcw dysponuj opisanym cigiem dziaa stanowicym ele-
menty 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 wymu-
szajcym ich modyfikacje. Obserwujemy zamiany w technologii, powstaj nowe
urzdzenia, materiay, rodzaje energii, dowiadczenia i obserwacje z realizacji stoso-
wanych procesw itp., co najczciej skutkuje potrzeb ich wprowadzenia do funkcjo-
nujcych procesw podyktowan wzgldami ekonomicznymi sprostaniu konkuren-
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 czstko-
wych. W przypadku systemu informatycznego, w ktrym wystpuje proces genero-
wania 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 samocho-
dw, 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 nietypo-
wa sytuacja, np. klient zagubi dokumenty, a chce podj gotwk; kto chce zreali-
zowa 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 realiza-
cj 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 opra-
cowanie i wprowadzenie nowej usugi bankowej, np. e-konto, podpis elektroniczny.
W dziaalnoci firm, ktrych podstawow dziaalno stanowi projekty mog wyst-
powa procesy, np. w ksigowoci czy obsudze patnoci. W dziaalnoci firm infor-
matycznych, zwaszcza duych, cz dziaalnoci, np. produkcja komputerw, podze-
spow 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 sys-
temu SAP). Firma informatyczna, ktra sprzedaje tylko komputery czy akcesoria nie-
wiele si rni od firmy, ktra sprzedaje sprzt AGD, ale firma, ktra przyjmuje zle-
cenia 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.
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 informa-
tycznego, ktrego zadaniem jest osignicie celu projektu z uwzgldnianiem ogranicze
projektu.
Trudno ustali list priorytetw uniwersaln dla wszystkich projektw, ktra uza-
sadniaaby 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?
3. Jak duo czasu powici na planowanie?

4. Skd czerpa dane?
Mwi si, e planowanie zabiera co najmniej 10% czasu, ale czasem dochodzi na-
wet 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 realiza-
cji chcemy si podj w ramach kontraktw zewntrznych, np. przetargw publicz-
nych, 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 specy-
fikacji wymaga systemu przedstawionej przez klienta.
Gdy mamy do czynienia z projektami wewntrznymi najczciej zanim powsta-
nie specyfikacja, wwczas od zespou wykonawczego zarzd firmy oczekuje oszacowa-
nia projektu na podstawie zdefiniowanego problemu lub pomysu na wytworzenie pro-
duktu, 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 kadorazo-
wym przegldzie harmonogramu i budetu, jeli nastpuj rozbienoci z planem wcze-
niejszym, 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 za-
daniem jest osignicie celu projektu z uwzgldnieniem ogranicze projektu, takich
jak:
2. Planowanie projektu informatycznego 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 rodza-
je 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 za-
sobw 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, wymagaj-
cym 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 porwny-
walnych efektw, ktre powinien wnosi projekt. Bardzo czsto jako cel projektu wska-
zuje si np. budow systemu informatycznego, wdroenie oprogramowania czy budow
sieci komputerowej i instalacj oprogramowania. Wiadomo, e s to jedynie rodki tech-
niczne 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 hamo-
wania rozwoju lub braku konkurencyjnoci. Celem takich projektw moe by uspraw-
nienie procesw zarzdczych, ktrych wymiernym efektem moe by zmniejszenie za-
pasw, kosztw transportu, jednostkowych kosztw obsugi klienta itp.
2.3. Zasoby projektu
W rozdziale tym przyjto nomenklatur i sposb zarzdzania zasobami zaimple-

mentowanymi 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 zarzdza-
niu 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 pli-
kami 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 zaso-
bw. Nastpnie meneder grupy funkcjonalnej moe zbilansowa ich obcienie prac
i zastpi lub ponownie przydzieli zasoby, aby zachowa zgodno z harmonogra-
mem. Jeeli nie ma znaczenia, ktry zasb wykonuje dane zadanie, pula zasobw
moe by zarzdzana poza zakresem projektu, w celu zapewnienia optymalnej efek-
tywnoci harmonogramu pracy zasobw. Jeeli natomiast naley zachowa kontrol
nad tym, kto wykonuje jakie zadania, mona skonfigurowa proces zmian przydzia-
w zasobw, ktry umoliwi zatwierdzanie przydziaw zasobw przed dokonaniem
zmian przydziaw w pliku projektu.
3. Przewidywanie obcienia prac w wielu projektach. Wykorzystanie puli za-
sobw moe by bardzo wydajne w przewidywaniu obcienia prac osb, ktrych za-
dania 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 zada-
nia. 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 ka-
dego z opisw prac stanowi informacj, jak wiele okrelonych zasobw potrzeba do
wykonania pracy nad projektami zgodnie z biecymi harmonogramami projektw. Na
przykad nadmierna alokacja na poziomie 300% dla Architekta I oznacza, e do wyko-

nania pracy potrzeba trzech modszych architektw. Nastpnie, po ucileniu listy zaso-
bw 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. Jee-
li 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 zaso-
bw z puli zasobw, jest nazywany plikiem wspuytkujcym. Jako puli zasobw
mona uywa dowolnego, istniejcego pliku projektu, ale zaleca si utworzenie no-
wego pliku projektu tylko na informacje o zasobach, by jak najbardziej uatwi zarz-
dzanie informacjami o zasobach i przydziaami zada midzy plikami wspuytkuj-
cymi 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 osta-
teczny 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 (harmo-
nogram) moe zwikszy liczb pracownikw potrzebnych do realizacji planu (zaso-
by) oraz zmniejszy liczb waciwoci cechujcych produkt (zakres). Meneder pro-
jektu 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
si do niej odnie. Waciwym dla wykonawcw jest take uzgodnienie sposobu ich
reakcji na niespodziewane ograniczenia, ktre mog ujawni si w czasie trwania pro-
jektu. Na przykad, jeeli koszty pracy oka si wysze od przewidywanych, to wy-
konawcy 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 dyspo-
nujemy,
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 stosun-
kowo 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 da-
nych zasobach ma szanse wykonania (zakoczenia si sukcesem).
Inicjowanie projektu (IP) zbir czynnoci, ktre naley podj przed formal-
nym 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
Przegld opisu projektu
WYKONALNO-
WYKONALNOCI
CI PROJEKTU
PROJEKTU Opis projektu
Wybr strategii prowadzenia

projektu
Strategia
Identyfikacja
kategorii ryzyka
Ocena ryzyka
Identyfikacja
i dobr zada
Zadania
Oszacowanie zada
Oszacowanie
INICJOWANIE zada
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 (fi-
zyczne),
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,
preliminarz kosztw,
okrelenie struktury uczestnikw projektu (klienta, zespou projektowego, in-
nych),
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]. Dla-
tego 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 kluczo-
w spraw jest pamitanie o zdefiniowanych i uzgodnionych celach projektu oraz pro-
wadzenie okresowej weryfikacji ich zrozumienia przez poszczeglnych wykonawcw.
2.5. Strategia realizacji projektu
Wybr strategii rozwoju projektu jest poprzedzony analiz wielkoci projektu, ho-
ryzontu czasowego jego realizacji, poziomem dopuszczalnego ryzyka i innymi czyn-
nikami. Wyrnia si kilka strategii, ktre maj swoje nazwy:
fazowa, monolityczna sekwencja kolejno wykonywanych faz, dobra dla pro-
jektw o niskim poziomie ryzyka,
wydania, wersje wytwarzane s fragmenty (podsystemy, komponenty), inkre-
mentalne podsystemy mog powstawa w sekwencji lub rwnolegle, ich od-
dzielne wytwarzanie zmniejsza ryzyko ich uruchomienia
szybkiej cieki, prototypowania wytwarzany jest prototyp, nastpnie wyko-
nywana jest jego ocena, po ktrej wytwarzany jest system, zalecana przy wyso-
kim ryzyku,
mieszana fragmenty (podprojekty) powstaj wedug rnych strategii, szcze-
glnie przydatna dla duych projektw obarczonych duym ryzykiem
Tabela 2.1. Wybr strategii realizacji projektu

w zalenoci od rozmiaru projektu i oceny ryzyka
Rozmiar projektu Ocena ryzyka Strategia

< 3 mies. niskie fazowa
rednie wydania
wysokie prototypowanie
3-6 mies. niskie fazowa lub wydania
rednie wydania
wysokie wydania lub prototypowanie
> 6 mies. niskie wydania
rednie wydania
wysokie mieszana lub prototypowanie
Kada strategia realizacji projektu powinna uwzgldnia pryncypia w zakresie za-

rzdzania, takie jak:
zarzdzanie wymaganiami zapewnienie jednoznacznego, obiektywnego okre-
lania cech tworzonego rozwizania oraz zapewnienie weryfikacji zgodnoci
docelowego produktu z wymaganiami,
kontrol przebiegu projektu moliwo biecego ledzenia faktycznego post-
pu prac i wczesne wykrywanie zagroe dla harmonogramu, budetu i jakoci
tworzonego systemu,
kontrol kosztw utrzymania moliwo realistycznego przewidywania kosz-
tw 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 pro-
jektu. 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,
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 Break-

down Structure) do poziomu zadania (ang. task), ktre definiuj czynnoci, jakie na-
ley zrealizowa w celu wyprodukowania okrelonego produktu, usugi, dokumentacji
itp. w zalenoci od tego do czego ma suy realizacja zdefiniowanego zadania. Za-
danie moe si dzieli na czynnoci. Przyjmuje si, e zadanie powinno by przypisa-
ne 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 reprezentu-
je prac nad wytworzeniem indywidualnych komponentw i prac nad integracj
komponentw w projekt. Gwnym celem struktury WBS jest przejrzysta i ade-

kwatna do rodzaju projektu organizacja powiza i wspdziaania wytwarzanych
produktw zmierzajcych do osignicia celu projektu. Umoliwia graficzne wy-
obraenie 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 zada-
nia, 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 oprogramo-
wania, np. faza analizy (ang. Analysis phase) jest to jedna z dodatkowych faz mode-
lu 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 struktu-
r drzewa. Na poziomie zerowym jest umieszczona nazwa projektu. Jednake nie
oznacza to, e projekt jest czci WBS. Stanowi on raczej opis, jakiego projektu do-
tyczy 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 pozio-
mie WBS, zaraz po nazwie projektu. Zadania znajduj si na niszym poziomie, poni-
ej faz. Zadania mog by dekomponowane na aktywnoci lub na inne zadania. Ska-
dowe 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 pro-
duktw). Aktywnoci znajduj si na najniszym poziomie WBS. Reprezentuj one
produkty, ktre s przydzielane konkretnym osobom. Osoby te wykonuj prac po-
trzebn do stworzenia produktu. Tak wic aktywno jest kombinacj produktu i pro-
cesu. Tworzc struktur WBS, naley zwrci uwag na numerowanie kolejnych
komponentw WBS. Kady element WBS jest unikatowy. Na poziomie zerowym

znajduje si jeden komponent nazwa projektu o numerze 1.0, na poziomie pierw-
szym znajduj si elementy numerowane od 1.1 do 1n, gdzie n jest liczb faz, na po-
ziomie 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 kom-
ponentw 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 wy-
szczeglnione w umowie, dokumentacji, specyfikacji projektu. Ich nazwy powinny
by par rzeczownikw lub rzeczownika z przymiotnikiem, np. Specyfikacja, Spe-
cyfikacja 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 wyko-
nania zadania zwizanego z danym produktem. Podzia produktu na wyszym pozio-
mie na produkty na niszym poziomie musi mie sens. Kady z produktw na ni-
szym poziomie powinien odrnia si od pozostaych oraz by odrbn czci
produktu wyszego poziomu.
3. Kontynuacja dekompozycji powinna trwa do momentu osignicia odpowied-
niego poziomu szczegowoci.
Zadania na najniszym poziomie aktywnoci powinny spenia nastpujce wa-
runki:
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 przydzie-
li odpowiednie osoby.
Zadania te powinny by nazwane w formie bezokolicznika: np. Tworzenie specy-
fikacji projektu.
4. W WBS powinny by opisane najwaniejsze czynnoci prowadzce do powsta-
nia 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 wyma-
gane do jego utworzenia.
5. W miar rozwoju WBS moe mie kilka aktywnoci na poziomie drugim, trze-
cim 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 ka-
dy 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 sprawdza-
my 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 konkret-
nym wykonawc. Tworzona jest organizacja, ktra zajmuje si realizacj projektu.
3. Dla danej organizacji wykonujcej projekt jest tworzona struktura podziau pra-
cy 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 kon-
traktowej struktury podziau pracy do zdefiniowania raportw, jakie bdzie przedsta-
wia klientowi po zakoczeniu realizacji prac wyspecyfikowanych w kontrakcie.
CWBS zawiera wicej szczegw zwizanych z zarzdzaniem prac nad projektem,

po zakoczeniu ktrej nastpuj zobowizania stron projektu. Struktura ta jest pomoc-
na 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 poj-
cie struktury WBS jest niepoprawne w powizaniu ze struktur zasobw (RBS) [2].
POZIOM 1
PROJEKT
POZIOM 2
Studium Moliwoci Inicjacja Specyfikacja Projektowanie Eksploatacja

realizacji/badanie systemu
definiowanie celu Przygotowanie

planu i budetu
bad. potrzeb uytkownika Analiza wymaga POZIOM 3
Org. zespou
przegld rozwiza realizacyjnego
alternatywnych
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 po-
wsta 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.
Tabela 2.2. WBS: Standardowe fazy cyklu ycia projektu (wedug Coopers & Lybrand)
Faza Czynnoci Produkt kocowy
Studium Zdefiniuj problem. Zbadaj Sprawozdanie studialne
moliwoci wymagania uytkownika.
realizacji/badanie Oce rozwizania alternatyw-
ne. Zale kierunek dziaania.
Inicjacja Przygotuj plan i budet. Przy- Projekt planu technicznego. Projekt planu zaso-
gotuj opis dziaalnoci firmy. bw. Projekt uzasadnienia przedsiwzicia.
Szczegowy plan dla nastpnej fazy. Aprobata
dalszych dziaa.
Specyfikowanie Analizuj szczegowo wyma- Specyfikacja wymaga uytkownika. Kryteria
gania uytkownika. Okrel akceptacji. Strategia instalacji i przejcia. Stra-
kryteria akceptacji. Wymyl tegia szkolenia. Szczegowy plan dla nastpnej
strategi implementacji. Opra- fazy. Akceptacja dalszych dziaa.
cuj plany.
Projektowanie Stwrz projekt systemu. Projekt systemu. Strategia budowy systemu.
Wymyl strategi. Opracuj Strategia testowania. Szczegowy plan dla
plan. nastpnej fazy. Akceptacja dalszych dziaa.
Realizacja Projektuj, pisz i testuj pro- Moduy. Programy. Procedury. Dokumentacja
gramy. Skompletuj dokumen- systemu. Materiay do szkole. Szczegowy
tacj. Przeprowad testy plan dla nastpnej fazy. Akceptacja dalszych
systemu. Opracuj plany. dziaa.
Instalowanie Opracuj zasady konwersji. System zatwierdzony przez uytkownika.
Przeprowad testy akceptuj- Szczegowy plan dla nastpnej fazy. Akcepta-
ce. Opracuj plany. cja dalszych dziaa.
Eksploatacja Przegld po implementacyjny. System nadajcy si do eksploatacji i utrzyma-
nia. 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 oczywi-
sta i uwaga badaczy skoncentrowana jest wok jednostki miary i metody powtarzal-
noci pomiaru.
Tabela 2.3. Fazy cyklu ycia projektu obiektowego dostosowane na potrzeby projektu grupowego
Faza Czynnoci Produkty

Planowanie Poznanie celw, odpowiedzialnoci Powizanie grupy z tematem projektu
wstpne i harmonogramu. Analiza problemu.
(zaoenia) Okrelenie osb penicych rol klientw
Studium Identyfikacja podstawowych wymaga. Raport wykonalnoci
wykonalnoci Analiza wykonalnoci. Przygotowanie Raporty spotka
raportu wykonalnoci.
Planowanie Organizacja grupy, przypisanie rl. Plan projektu. Zaoenia strategii mini-
projektu (ang. Okrelenie planu dziaa, oczekiwanych malizacji ryzyka. Plan nadzoru jakoci.
Preliminary produktw, zasobw, przydziau prac. Okre- Szczegowy plan fazy nastpnej.
project plan) lenie ryzyka, okrelenie strategii. Przyjcie Raport przebiegu prac (w tym spotka)
planu kontroli jakoci. Opracowanie harmo-
nogramu. Przygotowanie wymaganych rapor-
tw.
Specyfikacja Identyfikacja wymaga w oparciu o analiz Dokument specyfikacji wymaga uyt-
wymaga sys- dokumentw, wywiady, pytania, etc. Specy- kowych. Plan (projekt) testw akcepta-
temowych fikacja wymaga. Weryfikacja i akceptacja. cyjnych. Sownik danych (wstpny).
Dziaania zmierzajce do zapewnienia Szczegowy plan fazy nastpnej.
jakoci. Przygotowanie wymaganych Raport zmian. Raport przebiegu prac
raportw. (w tym take spotka
i dziaa projakociowych)
Specyfikacja Analiza wymaga. Modelowanie i specyfika- Modele systemu:
wymaga na cja. Ucilenie sownika danych. Weryfikacja Model klas
oprogramowanie i akceptacja. Dziaania zmierzajce do za- Model funkcjonalny
(modelowanie) pewnienia jakoci. Ucilenie zaoe projek- Model dynamiczny
towych i implementacyjnych. Przygotowanie Sownik danych
wymaganych raportw i dokumentacji. Projekt testowania funkcjonalnego.
Podrcznik uytkownika (szkic). Szcze-
gowy plan fazy nastpnej. Raport
zmian. Raport przebiegu prac
Projektowanie Modelowanie i specyfikacja. Ucilenie sow- Dokumentacja projektu systemu. Sow-
systemu nika danych. Dziaania zmierzajce do zapew- nik danych. Projekt testowania integra-
nienia jakoci. Ucilenie zaoe projektowych cyjnego. Szczegowy plan fazy na-
i implementacyjnych. Przygotowanie wymaga- stpnej. Raport zmian. Raport przebiegu
nych raportw i dokumentacji. prac
Projektowanie Projektowanie klas. Ucilenie sownika Dokumentacja projektu klas. Sownik
klas danych. Dziaania zmierzajce do zapewnie- danych. Projekt testowania obiektw.
nia jakoci. Ucilenie zaoe implementa- Szczegowy plan fazy nastpnej.
cyjnych. Przygotowanie wymaganych rapor- Raport zmian. Raport przebiegu prac
tw.
Implementacja, Implementacja obiektw. Testowanie. Uzu- Oprogramowanie projektu. Sownik
integracja penienie sownika danych. Dziaania zmie- danych. Raport testowania obiektowe-
i testowanie rzajce do zapewnienia jakoci. Przygotowa- go, integracyjnego, funkcjonalnego.
nie wymaganych raportw i dokumentacji. Dokumentacja (szkic). Szczegowy
plan fazy nastpnej. Raport zmian.
Raport przebiegu prac
Finalizacja Dyskusja testw akceptacyjnych. Raport testowania akceptacyjnego.
Dokumentowanie. Raport. Dokumentacja (szkic). Raport finalny
W przypadku informatyki problem dotyczy zoonoci oprogramowania, czyli

na og relacji, jakie wystpuj midzy dwoma, trzema programami, ktry jest bar-
dziej zoony, trudniejszy w pielgnacji, implementacji algorytmw, testowaniu,
wdroeniu itd.
Szacowanie zada zwizanych z implementacj oprogramowania jest zagadnie-
niem trudnym, wymagajcym wspdziaania kierownika projektu z zespoami prze-
widzianymi do realizacji projektu, dostpu do informacji na temat podobnych przed-
siwzi 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 po-
trzebne kosztowe informacje [47, 51, 52]:
przed startem projektu (dla analizy koszty/zysk, negocjacji kontraktu),
podczas realizacji projektu (w celu zarzdzania projektem, planowania, monito-
rowania i kontroli),
musz by aktualizowane w trakcie prowadzenia projektu.
Metody szacowania zada
Przez szacowanie zada naley rozumie rne obszary mierzenia zada, ktre na-
ley 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 szaco-
wania 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
the Macro Software Sizing and Estimating Problem, IEEE Transaction of So-
ftware Enginering, SE-4, July 1978] znane jako najlepsze do szacowania kosz-
tw [4].
Miary niezawodnoci oprogramowania opieraj si na okreleniu rednich cza-
sw bezawaryjnej pracy oprogramowania, s to gwnie modele niezawodno-
ciowe.
Naley wspomnie o mikrotechnice szacowania zada, faz, Wide-Band Delphi,
szacowania cakowitego wysiku przedsibiorstwa oraz przez eksperta lub opro-
gramowanie. Z innymi technikami szacowania projektw mona si zapozna w
pracy Z. Szyjewskiego [47]. W dalszej czci pracy szczegowo omwiono meto-
d 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 stwo-
rzona. Zleci realizacj takiego projektu jednemu ze swoich pracownikw Allanowi Al-
brechtowi, 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 opubli-
kowano 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 komputero-
wych 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, metodo-
logii 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. Ilu-
struje to prosta analogia w handlu nieruchomociami. Koszt wybudowania budynku A
o powierzchni 100 m2 jest zwykle mniejszy od kosztu wybudowania budynku B o
powierzchni 400 m2. Jednake wiele atrybutw, takich jak marmurowe azienki, arma-
tura 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 niekoniecz-
nie 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 angaowa-
nych zasobw bazowych lokuj w produkcj oprogramowania. Policzenie kilku wa-
riantw rozwizania tematu za pomoc punktw funkcyjnych daje im moliwo oce-
nienia 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. Na-
wet dla strategicznych projektw, ktre nie potrzebuj adnej ilociowej oceny, waci-
we szacowanie jest potrzebne w celu waciwego przydziau pracownikw.
3. Monitorowanie umw zewntrznych (ang. Outsourcing) firmy zlecajce ko-
mu na zewntrz znaczce czci swoich zada oczekuj, e dostawca dostarczy pro-
dukt wedug specyfikacji, na odpowiednim poziomie jakoci, oczekuj zatem zwizku
z kosztami, ktre maj ponie firmy zewntrzne. Uycie metody PF w celu zademon-
strowania zgodnoci swych szacunkw, adekwatn do skali produkcji oprogramowa-
nia, jest podstaw negocjowania ceny usugi.
4. Pomoc w decyzjach biznesowych firmy musz analizowa kady pakiet apli-
kacji 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 funk-
cyjnych 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 aplika-
cj z punktu widzenia uytkownika.
ILF (ang. Internal Logical File) wewntrzny plik logiczny grupa danych i re-
kordw powizanych ze sob i utrzymywanych wewntrz granic sytemu podtrzymy-
wana przez zewntrzne wejcie EI (External Omput).
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 zmien-
n, 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 wyst-
pie (jest rekursywny), to tylko jego pierwsze wystpienie powinno by brane pod
uwag. IFPUG (International Function Point Group) [26] podaje szczegowe spo-
soby rozpoznawania i liczenia DET dla systemw z GUI oraz systemw czasu rze-
czywistego.
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 wyjcio-
we 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 zewntrz-
nych 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
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 war-
to 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 me-
tody PF, zgodne z podrcznikiem opublikowanymi przez IFPUG [26]:
1. Zaplanuj liczenie. Ten krok obejmuje wybr rodzaju liczenia oraz zdefiniowa-
nie 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 funk-
cyjnych jest konieczne.
3. Policz VAF. IFPUG poleca zrobi to na kocu, lecz w czasie liczenia eks-
perci czsto narzekaj, e poszczeglne procesy s zbyt sabo ocenione. Mona
powiedzie, e VAF wemie to pniej pod uwag i poprawi ich ocen. Podziele-
nie 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 przygo-
towywanych metryk projektw jest to, i klient musi zbyt dugo czeka na wyniki
oblicze. W dzie lub dwa po zakoczeniu liczenia wyniki powinny by przedstawio-
ne pracownikom biorcym udzia w projekcie oraz sponsorom.
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 outsource-
ra, 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 odrzu-
cona lub przerobiona.
Przykad
Oszacowanie kosztw projektu Systemu do ewidencjonowania polis ubezpie-
czeniowych w ubezpieczeniach komunikacyjnych dla PZU S.A. POLISA metod
punktw funkcyjnych.
Celem projektu jest ewidencjonowanie polis i obliczanie wysokoci skadek ubezpie-
czeniowych 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 analiza Implementacja testowanie wdraanie

SW projektowanie konserwacja
Likwidacja szkd wpaty skadek / Wyliczenie skadki ubezpieczenia sporzdzanie wniosku

wypaty odszkodowa i wystawienie polisy o zawarcie ubezpieczenia
Sporzdzanie protokou zgoszenia szkody Wyszukiwanie polisy Wyst. polisy OC Wprow. danych klienta
Sporzdzeni protokou szkody Przyjmowanie wpat na polis Wyst. polisy AC Wprow. danych pojazdu
Decyzja o wypacie Wypata odszkodowa Wyst. polisy NW Wprow. danych koniecznych przy OC
Wyst. polisy ZK Wprow. danych koniecznych przy AC
Wyst. polisy Assistance Wprow. danych koniecznych przy Assistance
Wysz. wniosku o zaw ubezp. 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:
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 pro-
blemw napotykanych przy budowie oprogramowania.
Tabela 2.4. Cechy aplikacji
Nazwa cechy Charakterystyka cechy aplikacji Warto Ci

Wymiana danych 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 wyma- 3
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 doty- 2
towe systemu czce czasu.
Czstotliwo Wymagania ustanowione przez uytkownika dotyczce przetwarza- 4
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
dla uytkownika uatwienia w nawigacji (klawisze funkcyjne, dynamicznie
generowane menu, przechodzenie pomidzy elementami in-
terfejsu 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 Moliwa jest aktualizacja wikszoci wewntrznych plikw 3

plikw logicznych logicznych.
w czasie dziaania
systemu
Zoono Aplikacja nie zawiera zaawansowanych funkcji matematycznych 0
przetwarzania i logicznych.
Ponowne wyko- Nie ma kodu nadajcego si do ponownego uycia. 0
rzystanie pakietw
z kodu programu
atwo Nie wyspecyfikowano specjalnych wymaga uytkownika oraz nie 1
instalacji wymagany jest program uatwiajcy instalacj.
atwo Nie wyspecyfikowano specjalnych wymaga oprcz standardowych 0
administracji procedur archiwizacji.
Wielokrotna Uwzgldniono w projekcie potrzeb instalacji aplikacji w wicej ni 2
lokalizacja jednej lokalizacji. Aplikacja jest zaprojektowana tak, by moga
pracowa w kadej z tych lokalizacji przy zaoeniu podobnej kon-
figuracji sprztowej i/lub programowej (np. pod kontrol tego same-
go systemu operacyjnego).
atwo Dane kontrolne dotyczce regu rzdzcych aplikacj s utrzymy- 2
dostosowania wane w tabelach. Zmiany mog by wprowadzane online przez
uytkownika, ale skutki s widoczne natychmiast
Suma Ci = 29
14
Ci
i =1
100 = 29 / 100 = 0,29
VAF = 0,65 + 0,29 = 0,94
Identyfikacja wewntrznych plikw logicznych i zewntrznych plikw inter-

fejsowych
W projekcie wyodrbniono nastpujce pliki ILF i EIF:
Wewntrzne pliki logiczne (ILF): Klient, Pojazd, Ubezpieczenie OC, Ubezpie-
czenie AC, Ubezpieczenie NW, Ubezpieczenie Assistance, Ubezpieczenie Zielona
Karta, Szkoda, Cz.
Zewntrzne pliki interfejsowe (EIF): Wycena
Aby obliczy liczb punktw funkcyjnych dla zewntrznych plikw interfejso-
wych (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 Liczba DET

119 2050 51 lub wicej
1 RET Niska (7) Niska (7) rednia (10)
2 do 5 RET Niska (7) rednia (10) Wysoka (15)
6 lub wicej RET rednia (10) Wysoka (15) Wysoka (15)
Tabela 2.6. Liczba punktw funkcyjnych dla EIF
Liczba RET Liczba DET

119 2050 51 lub wicej
1 RET Niska (5) Niska (5) rednia (7)
2 do 5 RET Niska (5) rednia (7) Wysoka (10)
6 lub wicej RET 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 Punkty funkcyjne

DT RET Zoono
plik logiczny ILF (UFP)
Klient 24 3 rednia(10) 10
Pojazd 21 4 rednia(10) 10
Ubezpieczenie NW 5 1 Maa(7) 7
Ubezpieczenia AC 55 3 Wysoka(15) 15
Ubezpieczenie OC 12 1 Maa(7) 7
Zielona Karta 15 2 Maa(7) 7
Szkoda ponad 100 15 Wysoka(15) 15
Czci 4 1 Maa(7) 7
Wycena 2 1 Maa (5) 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.
Tabela 2.8
Liczba plikw zwizanych (FTR) Liczba DET

14 515 wicej ni 15
Mniej ni 2 Niska (3) Niska (3) rednia (4)
2 Niska (3) rednia (4) Wysoka (6)
Wicej ni 2 rednia (4) Wysoka (6) Wysoka (6)
Aby obliczy PF dla zewntrznych wyj (EO), trzeba zna:

liczb danych rozrnialnych dla przyszego uytkownika (DET) wykorzysty-
wanych przez transakcj.
Odpowiadajc im zoono w PF odczytujemy z tabeli 2.9.
Tabela 2.9

9 15 619 Wicej ni 19
2 lub 3 Niska (4) rednia (5) Wysoka (7)
Aby obliczy PF dla zewntrznych zapyta (EQ), trzeba zna:

liczb danych rozrnialnych dla przyszego uytkownika (DET) wykorzysty-
wanych przez transakcj.
Odpowiadajc im zoono w PF odczytujemy z tabeli 2.10.
Tabela 2.10

15 619 Wicej ni 19
2 lub 3 Niska (3) rednia (4) Wysoka (6)
Przykadowy modu sporzdzanie wniosku o zawarcie ubezpieczenia tabela

2.11.
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
Wprowadzenie danych koniecznych 3 48 Wysoka 6
przy AC
Wprowadzenie danych koniecznych 3 4 rednia 4
przy Assistance
przy NW
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 war-

toci UPF dla wszystkich transakcji i zbiorw danych (tabela 2.12).
Tabela 2.12
Rodzaj komponentu Zoono komponentw

Niska rednia Wysoka Razem
Wejcie EI 1x 3 = 3 4 x 4 = 16 6 x 6 = 36 55
Wyjcie EO 0x4=0 0x5=0 6 x 7 = 42 42
Zapytania EQ 3x3=9 1x4=4 0x6=0 13
Wewntrzne pliki logiczne ILF 4 x 7 = 28 2 x 10 = 20 2 x 15 = 30 78
Zewnetrzne pliki interfejsw 1x5=5 0x7=0 0 x 10 = 0 5
EIF
Cakowita liczba nieskorygowanych punktw funkcyjnych 193
Wyznaczenie PF
Na podstawie: UPF
obliczonej liczby = 193,
wartoci VAF = 0,94.
otrzymujemy:
FP = UPF VAF,
PF = 193 0,94 = 181.
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 oprogramo-
wa 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
120
Osobomiesice
100
Osobomiesice
80
60
40
20
0
50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 1000 1050
LLiczba
czba PFPF
Rys. 2.5. Wykres zalenoci nakadu pracy od liczby PF

Podane szacowanie nie uwzgldnia innych czynnoci technologicznych zwiza-

nych z wytwarzaniem oprogramowania, jak studium wymaga, projektowanie, anali-
zy, testowania wdroenia itd.
Z wykresu przedstawionego na rys. 2.5 wida, e wraz ze wzrostem wielkoci projek-
tu liczonego liczb PF, wykonanie kolejnego przyrostu w projekcie (modyfikacje, rozsze-
rzenie 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 ogra-
nicza projekt jest czas, ktremu w planowaniu projektu i jego monitorowaniu powi-
ca 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 za-
dania 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 nie-
zbdnej 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 za-
dania jest alokowany.
Przykad
Trzej programici pracuj nad zadaniem przez dwa dni przy nakadzie pracy
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 przed-
stawia 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.
A A
FS: SS:
B B
A A
FF: SF:
B B
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 oczekiwa-
nych zasobach przewidzianych do ich realizacji.
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 (po-
przednik, nastpnik oraz ktre zadania wykonuj si rwnolegle) (rys. 2.8).
3 4 4 3 3
Z1 Z2 Z3 Z4 Z5
3 2
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
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 mi-
dzy zadaniami.
cieka krytyczna (ang. Critical Path Metod CPM) bazuje na PERT i czsto na-
zywane jest PERT/CPM. CPM obejmuje cig zada w projekcie, od ktrych zaley za-
koczenie projektu w terminie. Zadania te wymagaj szczeglnej uwagi PM, na og
czstszego monitorowania, niekiedy specjalnego raportowania przez zesp, ktry realizu-
je 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 przyto-

czonej listy czynnoci, ktre towarzysz temu zdarzeniu. Jednak biorc pod uwag, e
nie tylko projekt jest niepowtarzalny, ale rwnie okolicznoci i warunki jego uru-
chomienia, 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 zwierzch-
nik, komitet kierujcy, reprezentacja uytkownika, struktura zespou, zaoenia,
odpowiedzialno osb i zespow),
ustanowienie struktury (wyznaczenie kierownika i kluczowych czonkw zespo-

u, zasad raportowania, monitorowania i powiza, zasad zarzdzania, komuni-
kacji),
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 ze-

wntrznego 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, dowiad-
czony 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 roz-
dzia 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, podnosze-
nie 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 kon-
troli oraz czy w zwizku z tym trzeba zmieni plan, specyfikacj produktw, opis
i inne wymagania uytkownika to czynnoci permanentne w trakcie trwania projek-
tu. 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 parame-
trw 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 pro-

jektowych.
Gwne aspekty ledzenia projektu:
czas,
jako,
3. ledzenie oraz zarzdzanie zmianami projektu 53
funkcjonalno,
koszty.
Etapy ledzenia projektu:
1. Wstpne rozpoznanie:
Porwnanie stanu z opisem projektu (ang. Feasibility Study Report, Business Ca-
se) 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 projek-
tu. Dane takie pochodz od codziennych sprawozda prowadzonych przez czonkw
zespou. Sprawozdanie powinno zawiera czas spdzony danego dnia na rzecz projek-
tu 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, przy-

datno uytkowa. Normy ISO 9000 przyjy nastpujc definicj:
Jako og cech i waciwoci wyrobu lub usug decydujcych o zdolnoci wy-
robu 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 uzy-
skanie porozumienia co do wsplnej wizji jakoci. Bardzo powszechne jest mylenie
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, bez-
pieczne 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 pod-

stawie ktrych jego jako jest oceniana.
Jednym z zestaww minimalnego zestawu kryteriw jakoci opisujcych oprogra-
mowanie jest model McCalla przedstawiony w tabeli 3.1.
Tabela 3.1
Dziaanie programu
Wygodny Odnosi si do efektywnoci uytkowania programu i wygodnego interfejsu
Bezpieczestwo Odnosi si do bezpieczestwa uytkowania programu pod ktem kontroli upraw-
nie do korzystania z niego oraz odpornoci na skutki nieprawidowej obsugi
Wydajno Odnosi si do oceny wydajnoci systemu i sposobw zarzdzania zasobami
Poprawno Odnosi si do stopnia realizacji wymaga, kompletnoci i logicznoci wdroenia,
zgodnoci dziaania programu ze specyfikacj
Niezawodno Odnosi si do stopnia odpornoci programu na bdy, jego poprawnoci formalnej
oraz sposobw reakcji na bdne sytuacje
Przystosowanie do modyfikacji
Pielgnowalno Ocenia stopie przystosowania programu do dziaa zmierzajcych do jego po-
prawiania, modyfikacji, rozszerzania, adaptowania itp., wedug nowych wymaga
lub raportw o bdach
Elastyczno Ocenia moliwoci rozbudowania programu o nowe funkcje oraz uniwersalno
wdroonych rozwiza
Testowalno Ocenia przystosowanie oprogramowania do procesu testowania, tzn. jego struktu-
r, dokumentacj, specyfikacj moduw itp., a take przewidziane mechanizmy
wspomagajce ten proces
Mobilno oprogramowania
Przenono Ocenia oprogramowanie pod ktem zdolnoci do atwego uruchomienia na innych
maszynach lub systemach programowania ni rodowisko projektowe
Uniwersalno Odnosi si do moliwoci wykorzystania istniejcego oprogramowania lub jego
fragmentw do konstrukcji innych programw lub systemw komputerowych
Otwarto Ocenia stopie przystosowania programu do wsppracy lub wymiany informacji
z innymi systemami komputerowymi
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 wymaga-
nia 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,
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, pod-
czas 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 doty-
czca 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 sto-
sowaa. Formalne procesy s dobrym wynalazkiem, jeli si je stosuje ze zrozumie-
niem, jeli je stosowano wczeniej oraz najlepiej, jeli jest ich aprobata. Ale projekt
jest prb zrobienia czego, czego jeszcze nigdy nie zrobiono, zatem sposb jego re-
alizacji 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 wy-
niku nadzorowania projektu moemy dostrzec uchybienia, ktrych rdo ma po-
chodzenie:
wewntrzne zmiany wywodzce si z fazy planowania projektu, wynikajce
z niezrozumienia zaoe, ze zmian w oszacowaniu nakadu pracy, zmian w ska-
dzie 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 zwiza-
ne z pocztkow specyfikacj projektu.
Nadzorowanie kosztw. ledzenie i nadzorowanie czasu oraz kosztw projektu

przedstawiono w rozdziale 3.4.
Kontrolowanie zmian
1. danie zmiany: musi by dokonane na pimie. Adresowane do kierownika pro-

jektu. Musi zawiera: nazwisko czonka zespou dajcego zmiany, dat, opis pro-
blemu, 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 zgaszaj-
cemu 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-
u/organizacji.
Tabela 3.2. Klasy i metody przegldw
Metoda Typowe cele Typowe cechy

Walkthroughs Minimalny nakad Brak przygotowa
wiczenie dla konstruktora Nieformalne
Szybki obieg Nie ma pomiarw
Nie jest FTR!
Przegldy techniczne Identyfikacja wymaga Proces sformalizowany
(ang. technicreviews) Wychwycenie niespjnoci Prezentacje autorskie
wiczenie Szeroki zakres dyskusji
Inspekcje Efektywne wykrycie i usunicie Proces sformalizowany
(ang. inspections) wszystkich defektw 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, uwzgldniaj-
c aspekty finansowe (fundusze ju wydatkowe a fundusze planowane, wystawione
faktury dla klientw itd.).
Akcje naprawcze dziaania, ktre zapobiegaj negatywnym nastpstwom nie-

ktrych 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! Mene-
der projektu musi wnosi now warto przez wczesne identyfikowanie problemu
i podejmowanie akcji naprawczych.
3.3. rda i rodzaje zmian
Errare humanum est.

Seneka
Zarzdzanie zmianami, nazywane rwnie zarzdzaniem konfiguracj projektu, obejmu-

je 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 kontro-
lowane 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 kon-
figuracja 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 aktual-
no.
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 rapor-
towane 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.
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 odpowied-
nio ledzony.
Przed podjciem decyzji o wprowadzeniu zmian do projektu naley przeanali-
zowa:
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 ob-
raz zmian w projekcie, dotrze do rda ich powstania i przeledzi losy ich reali-
zacji.
3.4. Proces zarzdzania zmianami
Zarzdzanie zmianami (konfiguracj) to zasady i techniki zmierzajce do identyfi-

kacji, 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 zaka-
danej jakoci [32, 44, 45].
Zadania zwizane z zarzdzaniem zmianami w wikszych projektach powierza si
najczciej zespoowi ds. zarzdzania zmianami, ktry moe by rozproszony po ca-
ym projekcie.
Zmiana propozycja modyfikacji czego, co zostao ju wczeniej uzgodnione
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, bezwstrz-
sowy,
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,
oddalanie si od zaoonych celw, a nawet bankructwo projektu.
Zarzdzanie zmianami struktura procesu
Identyfikacja koniecznoci zmian: dokumentacja dania zmiany (opis, uzasad-

nienie, 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 W zakresie projektu Poza zakresem projektu

Odrzucenie Rozpowszechnienie decyzji wraz z uzasadnieniem
Akceptacja doczenie do planu przygotowanie propozycji
zmiana harmonogramu wstrzymanie realizacji do momentu uzyska-
przydzia rodkw nia formalnej kontaktowej zgody
rozpowszechnianie i realizacja
Odoenie 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.
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 X / 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 stare-
go 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 teryto-
rialnych. Ograniczenie si do zmian w aplikacji jedynie do zmian sownikowych spowoduje, ze w
raportach odnoszcych si do poszczeglnych powiatw nie bdzie prawidowych danych. Przyka-
dowo w nowo utworzonym powiecie Powiat m.st. Warszawa raporty wyka 0 (zero) zakadw pra-
cy chronionej.
Zgaszajcy zmian:
A. Kowalski
Data: 20.02.2003
Cz II Decyzja
(wypenia akceptujcy)
Akceptacja* Podpis decydujcego: Kazimierz Frczkowski
Akceptacja warunkowa* X
Data: 23.02.2003
Odrzucenie zmiany*
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 aplika-
cji 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

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 Po zmianie w bazie centralnej

Kod nazwa Kod nazwa
1 0263 Powiat M. Wabrzych 0221 Powiat Wabrzyski
2 0263011 M. Wabrzych 0221091 Wabrzych
3 1805102 Szerzyny 1216162 Szerzyny
4 1406102 Tarczyn 1418063 Tarczyn
5 1431191 Sulejwek 1412151 Sulejwek
6 1413 Powiat warszawski 1465 Powiat m.st.Warszawa
7 1431011 Warszawa-Bemowo 1465028 Bemowo
8 1431021 Warszawa - Biaoka 1465038 Biaoka
9 1431031 Warszawa - Bielany 1465048 Bielany
10 1431041 Warszawa - Centrum 1465 Powiat m.st.Warszawa
11 1431058 Warszawa Mokotw 1465058 Mokotw
12 1431058 Warszawa - Ochota 1465068 Ochota
13 1431078 Warszawa Praga Poudnie 1465078 Praga Poudnie
14 1431088 Warszawa Praga Pnoc 1465088 Praga Pnoc
15 1431098 Warszawa rdmiecie 1465098 rdmiecie
16 1431108 Warszawa Wola 1465188 Wola
17 1431118 Warszawa oliborz 1465198 oliborz
18 1431121 Warszawa Rembertw 1465098 Rembertw
19 1431131 Warszawa Targwek 1465118 Targwek
20 1431141 Warszawa Ursus 1465128 Ursus
21 1431151 Warszawa Ursynw 1465138 Usynw
22 1431161 Warszawa Wawer 1465148 Wawer
23 1431171 Warszawa Wilanw 1465168 Wilanw
24 1431181 Warszawa Wochy 1465178 Wochy
25 1431201 Wesoa 1465158 Wesoa
Dla wikszoci projektw nie ma czego takiego jak maa zmiana!

KF
3.5. ledzenie i nadzorowanie czasu

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

C. Bernard), wskazujc na potrzeb skontrolowania osignitych wynikw i po-
rwnanie z zamierzonym celem wycignicie wnioskw na przyszo (do nastp-
nego planu projektu).
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 sza-
cowany jest metod bottom-up, tzn. budet przydzielany jest kademu maemu zada-
niu 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 osiga-
n przy realizacji projektu, naley porwna osigane wyniki z tym co zostao zaplano-
wane.
3.6. Nadzorowanie projektu metod wartoci uzyskanej

(Earned Value)
Amerykascy producenci kierowani potrzeb pomiaru wydajnoci pracy zastoso-

wali 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 sto-
sowany do pomiaru wydajnoci projektw prowadzonych na ich zlecenie. Metoda
Earnet Value lub wartoci uzyskanej polega na kontroli realizacji projektu przez po-
rwnywanie zrealizowanego do danej chwili zakresu prac i terminw ich realizacji
oraz rzeczywicie poniesionych kosztw z przyjtymi w planie bazowym harmono-
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 realiza-
cj 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
kumulowanymi kosztami planowanymi i kumulowanymi kosztami rzeczywistymi jako

oszczdnociami (rys. 3.3).
Kontrola obejmuje rwnie wycen wartoci prac (produktw, usug itd. od po-
cztku realizacji projektu) zrealizowanych do chwili kontroli (stan na dzi) przez obli-
czenia tzw. kumulowanej wartoci uzyskanej, wwczas mamy moliwo porwnania
w pienidzach trzech parametrw, tj. kosztw planowanych (KP), kosztw rzeczywi-
stych (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 Ear-
ned 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 do-
datnie lub ujemne. Wartoci dodatnie wystpuj wtedy, kiedy WU jest wiksza za-
rwno 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 parame-
trw 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
ile uzyskujemy za kad wydan jednostk waluty finansowania projektu, np. zotw-
k. 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 te-
go 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 zespo-
u, 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
wynika, e ju po okoo 15% realizacji wida pewn stabilizacj trendw. Odwrcenie

trendw (tych negatywnych) jest jednym z najtrudniejszych wyzwa Project Manage-
ra [5, 53, 59].
Koszty
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 ta-
kie 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 realiza-
cj projektu. Jak ju zaznaczono najkorzystniejsza sytuacja jest wtedy, kiedy wy-
konano zadanie w 100%. Przydzielanie wartoci uzyskanej nastpuje
w wysokoci 100% planowanych kosztw. Jest to dobre rozwizanie dla krtko-
trwaych zada.
Metoda 50/50
Metoda 50/50 jest rwnie prosta. Przy rozpoczciu zadania uzyskuje 50% swo-
jego zaplanowanego budetu, na zakoczenie pozostae 50%. Gdy operujemy wik-
sz 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 oce-
niamy 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 oce-
nia sam siebie. Najczciej ekspert ulega deklarowanym przez wykonawcw suge-
stiom, 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 projekta-
mi. 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 pro-

jektu. Dziki wskanikowi kosztw (WK) moemy obliczy, jaki bdzie ostateczny
koszt projektu.
Nazywane jest to estymacj ostatecznych kosztw EOK (ang. estimate et comple-
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 uprosz-
czonego 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 harmono-
gramie 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 dodatko-
wo 1520% na bezporednio podlegych pracownikw.
Oszacowania powinny by dokumentowane w sposb czytelny zawsze wyst-
puje 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.
start zadania koniec zadania

PT SOB NIED PON
1 2 3 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 do-
stpno 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 wsp-

dzielone 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 kosz-
tw 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 me-
tod zarzdzanie zasobami projektu ludzkimi, materialnymi, sprztowymi, czaso-
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 przedsibior-
stwa.
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 koniecz-
no ich wprowadzenia, nie jest dobrym rozwizaniem. Zmiana jest pewn akcj ko-
rekcyjn 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 niekontrolowa-
ne 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 niesta-
rannie.
A
E
C
D F
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 cza-

sem. W rzeczywistych projektach jednak mamy ograniczony czas, ograniczony bu-
det, ograniczone zasoby. Z tego wniosek, e im staranniej przykadamy si do re-
alizacji, zwaszcza we wczesnych fazach projektu, tym lepiej jest szansa, e
w projekcie nie bdzie radykalnych zmian. Jeszcze jeden przykad na to, e zwasz-
cza 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 wszyst-
kie wymienione komponenty i okae si, e naley dokona zmian w elemencie A,
to pocignie to za sob zmiany w pozostaych, czyli dodatkowe zuycie czasu, pie-
nidzy, 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 kompe-
tencji 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
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 zapla-

nowanym (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 wyno-
si 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, kt-

ry pozwalaby waciwie zaplanowa przedsiwzicie informatyczne. Do rzadkoci na-
le 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 nazewnic-
twie 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 Amery-
ce 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 bezrobot-
nymi
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 fak-
tyczny 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 rapor-
tu Nowe metody pracy, przygotowanego przez Komisj Europejsk [11]. Mamy zatem do
czynienia z wirtualnymi firmami, w ktrej pracuj wirtualni pracownicy, i praca nadzo-
rowana jest przez sprawnie dziaajce sieci telekomunikacyjno-informatyczne, bez siedzi-
by, a czsto rwnie osobowoci prawnej. Mog j tworzy ludzie znajdujcy si w r-

nych zaktkach wiata, lecz pracujcy wsplnie nad jednym przedsiwziciem i indywi-
dualnie wiadczcy okrelon prac zgodnie z umiejtnociami i potrzebami zlecenio-
dawcy.
Praktyczne wskazwki i informacje w zakresie technik oraz narzdzi wspomaga-
jcych 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. M-
wimy 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 konku-
rencji na rynku, coraz mniej firm sta jest na stworzenie i utrzymanie zespou projektowe-
go. 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 nowo-
czesnym technikom porozumiewania si, ludzko stoi u progu pokonania barier komu-
nikacyjnych 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 zwolen-
nicy i przeciwnicy, tak jak dla idei globalizacji, ktra bdzie sprzyjaa takim tendencj.
Jest to zrozumiae w sytuacji patrzenia na wiat w zmniejszonych proporcjach dziki roz-
wojowi komunikacji i telekomunikacji. Dla kogo takie trendy s szans, a dla kogo zagro-
eniem 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

4. Modele pracy i komunikacji telepraca 79
Zrnicowanie stref czasowych umoliwia niemal cig prac 24 godziny na do-

b, 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 skrupulatne-
go przestrzegania zasad komunikacji, definiowania wsplnych poj i celw. Jedna-
kowe zrozumienie i interpretacja wspdzielonych danych jest wanym aspektem two-
rzenia 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)
2000 2010
Na stae zatrudnieni w domu 810 000 3 170 000
Pracownicy pracujcy w wielu miejscach 3 700 000 14 332 000
Niezatrudnieni na stae, wiadczcy usugi 1 450 000 3 040 000
Pracujcy w domu, nie wiadczcy usug 3 080 000 6 580 000
Suma 9 040 000 27 122 000
rdo: Emergence analysis, 2001 [5].
W istocie elektroniczny PM to rzeczywisty czowiek specjalista w dziedzinie zarz-

dzania 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 monito-
rowa cay cykl ycia przedsiwzicia. Dodatkowym zadaniem PM dziaajcego w ro-
dowisku 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, kt-

rzy 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
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 zespo-
w w zarzdzaniu projektami, poniewa celem ich jest:
przedstawienie modeli organizacji zespow projektowych w zrnicowanych
organizacyjnie firmach,
analiza zada pod ktem dopasowania zastosowania adekwatnej metody orga-
nizacji zespou a typem projektu,
jak wykorzysta zrnicowan wiedz poszczeglnych czonkw zespou do re-
alizacji 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. Budowa-
nie 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 kandy-
datw.
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, utwo-
rzenia wsplnego kontekstu wszystkich przesyanych informacji. Komunikacja syn-
chroniczna, zapewniajca umieszczenie wszystkich stron komunikacji w tej samej
czasoprzestrzeni umoliwia szybkie zbudowanie korzystnych relacji midzy czon-
kami zespou. Wprowadzenie priorytetw w rozsyaniu informacji, aby zapobiec efek-

towi przeadowania.
W zespoach rozproszonych due znaczenie ma repozytorium wiedzy, jest to najcz-
ciej 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 groma-
dzona przez osoby zaangaowane na rnych etapach, nie moe zosta bezpowrotnie
utracona. Stworzenie centralnej bazy wiedzy umoliwia korzystanie z repozytoriw, do-
kumentw, 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 reali-
zacj 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 komunika-
cji 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
kulturowych, w duym rozproszeniu geograficznym konieczne jest dogbne zdefi-

niowanie uywanych poj. Okrelenia jako czy na czas mog mie zbyt roz-
biene znaczenia. Wsplne definicje uywanych poj s konieczne przy definiowaniu
wsplnych celw.
Wsplne procesy maj wpyw na dopasowanie telepracownika do zespou. W przy-
padku stosowania rygorystycznych procesw wytwarzania oprogramowania wane jest
zatrudnienie pracownika znajcego i rozumiejcego obowizujce procedury postpo-
wania.
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 tech-
nologi licz si rwnie umiejtnoci zwizane z komunikacj oraz sam organizacj
pracy. Dopasowanie tych elementw jest konieczne do stworzenia prnie dziaajce-
go 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 kolej-
nych poziomw zwiksza wydajno przez optymalizacj poszczeglnych aspektw
dziaania zespou.
Zesp niezalenie od fizycznego usytuowania, sposobu komunikacji oraz realizo-
wanego zadania na pewnym etapie dziaania nabywa cech pozytywnych oraz nega-
tywnych, do ktrych nale midzy innymi:
swoista ideologia,
normy wspdziaania i bycia egzekwowane s w sposb naturalny nie ma re-
gulaminu,
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 po-
rwnania pracy midzy zespoem tradycyjnym a wirtualnym, takich jak:
w zespole tradycyjnym:
dyskusje prowadzone bezporednio, wida reakcje i temperament rozmwcy,
czsto praca samodzielna,
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 Wirtualny zesp

Czonek z tej samej organizacji Czonek z organizacji, firmy przynalenej bizne-
sowo, konkurent
Czonek wyuczony, czsto polecony, ustalajcy Czonek dobrany z powodu wykazanych przez
standardy niego kompetencji
Maa ufno danie duej ufnoci
Procesy pracy sztywne i zdefiniowane, czsto Procesy pracy elastyczne dopasowane do zespou,
nieuyteczne dostosowane do projektu
Struktura zespou hierarchiczna Redukcja hierarchii, wicej zalenoci sieciowych
Stabilne rodowisko pracy Cige zmiany rodowiska pracy
Wane pozycja i wadza Wana wiedza i zdolnoci
Grupowe produkty zespow wirtualnych generuj rozwj oraz wymogi w kie-

runku sprawniejszej i multimedialnej komunikacji, sprzeda produktw grupowych
w 1997 r. w USA zwikszya si w stosunku rocznym prawie o 100% [23], ale jed-
noczenie 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 grud-
nia 2002, w listopadzie 2001 r. do projektu byo zaangaowanych 7 osb. W tym cza-
sie 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 wspl-
nych zasobw repozytorium w Lotusie i grupowa praca nad produktami. W repozy-
torium gromadzono np. wsplne ustalenia, wzory dokumentw, korekty dokumentw,
uwagi, polecenia, monitorowanie zmian, opiniowanie itd. Etapy koczyy si spotka-
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 prze-
chodnia). 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, reprezen-
towanie zespou i penienie funkcji administracyjnych. W zespole takim nie mog si
pojawia czonkowie nowi, niedowiadczeni, gdy nie nadaliby za tempem pracy pozo-
staych. 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

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 wyzna-
czanych 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 sta-
ych czonkw: gwnego programisty (chief programmer), programisty zapasowego
(backup programmer), oraz bibliotekarza (librarian). Do nich w razie potrzeby przydzie-
lano 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),
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 kwalifika-

cji 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
z sukcesem lub jego niepowodzenie to zasuga caego zespou. Informacja dotyczca

wkadu w cao projektu i poszczeglnych zada nie jest przedmiotem personalne-
go 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 organi-
zacj pod sprawn obsug procesw, przez ni przebiegajcych. Nowe zadania, nie-
typowe projekty w takiej strukturze wymuszaj tworzenie sieci partnerw. W struktu-
rze 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
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 podzie-
li na sabe, silne i zbalansowane. Dla struktury macierzowej sabej rola kierownika
projektu jest ograniczona bardziej do roli koordynatora i przyspieszacza ni zarz-
dzajcego. Przy strukturze silnej macierzowej kierownik projektu ma znaczny autory-
tet (prawo podejmowania decyzji) i uprawnienia administracji zaog. Zazwyczaj kie-
rownik projektu odpowiada za sprawy zwizane z zarzdzaniem,
harmonogramowaniem i planowaniem, natomiast kierownik funkcjonalny jest odpo-
wiedzialny za techniczn stron projektu, zajmuje si szkoleniami i karier pracowni-
kw.
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 po-
mocy technicznej (ang. software support), zespoy zastosowa inynierii oprogramo-
wania, zesp analitykw branowych, hurtowni danych itp.
Zasig projektu ograniczony jest do zespou funkcyjnego, tzn. komunikacja po-
szczeglnych zespow odbywa si przez przeoonych, tj. kierownikw zespow
dziedzinowych. Zarwno pytania, jak i produkty kocowe przekazywane s od jedne-
go 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-
cych, majcych du swobod dziaania nie tyko czekajcych na polecenia i ich wyko-
nanie, zmienia model zarzdzania. Sieci korporacyjne, intranet, e-mail, poczenia ISDN
na potrzeby wideokonferencji, telefon stacjonarny i komrkowy spowodoway, e moe-
my mwi o rodzcym si zjawisku samokreowania warsztatu i miejsca pracy. Mj pra-
codawca 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 fir-
my, 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 repozy-
toriw, 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 tworzo-
ne rozwizania i wykorzystaj je w firmie. Budowane narzdzia i technika komunika-
cyjna sprzyja budowie systemu scentralizowanego z moliwociami zdecentralizowa-
nych 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 dotych-
czasowe metody zarzdzania s niewystarczajce. Adekwatnie do potrzeb wirtualna sie
zespow potrzebuje wirtualnego zarzdzania. To pojcie jeszcze nie jest upowszechnio-
ne, 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 prze-
ksztacenie 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, ste-
rowania kontroli nie speniaj ju swojej roli. Pewne elementy kontroli, jak np. czas
pracy, dyscyplina formalna, harmonogram w pewnym zakresie jest poza kontrol i nie
speniaj swojej roli. Pracownicy przejmuj w znacznej czci funkcje menederw

mylenie w zakresie co i jak zrobi, nie otrzymuj systematyczne polece, ktre skru-
pulatnie maj wypenia. Pracownika nie obserwuje kierownik i nie widzi jego zm-
czenia czy patrzenia w sufit. Menederowie steruj zespoem wirtualnym przez
wsplne zdefiniowanie celw i wystpuj w roli konsultantw i trenerw. Kierownic-
two 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 zwik-
sza 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 kon-
taktw (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 nie-
mal 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 usu-
godawca udostpnia serwer we wasnej serwerowni i odpowiada za stan oraz aktuali-
zacj 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 Wady

Funkcjonalna 1. Szybki start- organizacja ju istnieje 1. Brak centralnej odpowiedzialnoci za
atwe zarzdzanie pracownikami projekt
ustalone s narzdzia, techniki, stan- 2. Problemy z interfejsami komunikacyj-
dardy itp. nymi
3. Trudna kontrola i monitorowanie
Projektowa 1. Centralna odpowiedzialno za projekt 1. Konieczno tworzenia nowego zespou
2. Centralna kontrola interfejsw komuni- dla kadego projektu
kacyjnych 2. Trudniejsze zarzdzanie pracownikami
3. Szybko podejmowania decyzji 3. Brak ustalonych narzdzi, metod stan-
4. Wysoka motywacja zaogi dardw, itp. na starcie projektu
Macierzowa 1. Wady powyszych projektw zago- 1. Dwch przeoonych

dzone 2. Trudnoci w monitorowaniu i przepy-
2. Bardziej elastyczne zarzdzanie ludmi wie 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 do-
wiadczenia 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 po-
trzeby spoeczne: spotkania si z kolegami, rozmowy, miechu. Psycholodzy ostrzega-
j, e jeli pracujemy w domu, moemy mie trudnoci z okreleniem, gdzie koczy
si ycie zawodowe, a zaczyna prywatne. Przy bardziej stresujcych zadaniach i na-
pitych terminach moe to doprowadzi do tego, e o firmie bdziemy myle od po-
rannej 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 mental-
no, 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 wyzwa-
nia. Zasb wiedzy, umiejtnoci, jakie naley przyswoi w okrelonym czasie, jak
rwnie j aktualizowa, powoduje, e specjalizacja i podzia kompetencji jest do-
minujcy w organizacji, ktra wytwarza produkty informatyczne. Dostp do eksper-
tw staje si coraz bardziej znaczcy i niejednokrotnie decyduje o powodzeniu przed-
siwzicia. Nie zawsze jest to moliwe w danej firmie, czsto naley szuka na zewntrz
lub niektre prace outsoursowa. Zachodzi potrzeba budowy zespow cile wyspecja-
lizowanych w dziedzinie problemw, z ktrymi konwencjonalne zespoy nie mog
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, pro-
gramista, 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.
Praca grupowa
Termin ten okrela wspprac wielu, rozproszonych geograficznie, albo siedz-

cych w jednym pomieszczeniu osb, ktre korzystaj z udogodnie oferowanych
przez wspomagane technologi rodowisko pracy. Wspomaganie to polega na dostp-
noci mechanizmw przesyania i wspdzielenia dokumentw, mechanizmw plano-
wania i rozdzielania zada, kontroli postpw w realizacji tych zada, ledzenia ter-
minowoci 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 tak-
e w zakresie rozbudowywania moliwoci programw biurowych (pakietu biurowe-
go 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, regularne-
go zabezpieczania ich wynikw, usystematyzowanego rejestrowania i korzystania z wie-
dzy czonkw zespou. Praca grupowa wymusza na czonkach zespou inicjatyw,
obowizkowo i efektywne gospodarowanie czasem i zasobami i stanowi moe ele-
ment 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 wa-
ciwie 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 zja-
wiskami, 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 niede-
terministyczna, 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 prawdopodo-
biestwa i minimalizacji.
Przykadem ryzyka moe by np. przekroczenie budetu projektu czy nie wykona-
nia projektu w terminie. Niepewno to np. pogoda czy zjawiska globalne, ktre mog
mie wpyw na nasz projekt termin dostawy sprztu komputerowego, a wymienio-
nymi 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 informa-
tycznych [44, 50]:
5. Zarzdzanie ryzykiem 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 szaco-
wane s w miliardach dolarw (w samym tylko USA). Musimy zatem zada sobie
pytanie, czy w ogle opaca si podejmowanie realizacji projektw obarczonych ryzy-
kiem. 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 docho-
dzimy do pewnego paradoksu. Oczywicie naley podejmowa si realizacji projek-
tw, gdy s one chociaby motorem postpu tworzymy rzecz now, ale naley sta-
ra si w momencie planowania projektu (tworzenia harmonogramu) moliwie
najlepiej oszacowa ryzyko zwizane z projektem oraz zaplanowa akcje zapobiegaw-
cze 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 zwiza-
nych 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 usu-
wanie 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 za-
stanowi si co bdziemy robili, aby do tego nie doszo lub jakie dziaania przed-
siwzi 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-
cznie korzystne przypadki ryzyka. Czsto wymagane jest scharakteryzowanie

elementu ryzyka za pomoc pojedynczej wartoci liczbowej, co pozwala na ich bez-
porednie 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 (ko-
rzystnego 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

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 od-
nonie do sukcesu przedsiwzicia. Poziom tego ryzyka, ktry w projekcie jest dopusz-
czalny, 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. pro-
jektu 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 oczeki-
wanego (akceptowalnego), a w niektrych przypadkach okrelone obszary ryzyka
eliminowa.
Metoda obliczania wpywu redukcji ryzyka RRL (ang. Risk Reduction Leverage):
RVb RVa
RRL =
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 oce-
ny 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 ele-
mentw specyfiki projektw informatycznych nale:
Specyfika oprogramowania
zdominowanie przez proces projektowania,

trudnoci w wizualizacji,
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), po-
nadto wiele prac, ktre realizuje zesp projektu informatycznego przez duszy czas
jest niewidoczny. Dopiero pokazanie uytkownikowi projektu w fazie interfejsu (ko-
munikacji 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 wyko-
nawczej.
Wsppraca z klientem niewystarczajca.
Analiza systemowa powierzchowna.
Sztywna infrastruktura pracy.
Jako ograniczano z uwagi na czas i koszty.
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 ry-
zyka, tego co moe nas spotka, moe by niewystarczajcy. Istotne s dziaania planowe
zwizane ryzykiem, zakomunikowanie ich wyszemu kierownictwu, wspdzielenie od-
powiedzialnoci 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 proble-
mem, trzeba nagle znale rodki do jego rozwizania. Odbija si to na terminowoci
oraz koszcie projektu. Gdyby przeprowadzono wstpn analiz ryzyka, wwczas mo-
e udaoby si oszacowa jego skutki i zastosowa najprostsz strategie jego elimina-
cji lub ograniczenia przez dodanie do kosztorysu i harmonogramu marginesu bezpie-
czestwa na obsug pojawiajcych si problemw. Oto jakie cechy projektu mog
zadecydowa o jego sukcesie lub klsce.
Wsplna wizja produktu (systemu)

Powodzenie projektu powinno by wspln trosk wszystkich udziaowcw pro-
jektu.
Praca zespoowa
Bardzo wanym aspektem pracy zespoowej jest zaangaowanie przyszego uyt-
kownika systemu. Nikt tak jak on nie zna przyszego rodowiska pracy systemu.
Mylenie przyszociowe
Zarzdzanie ryzykiem koncentruje si na wczesnym wykryciu moliwego ryzy-
ka i dziaaniach prewencyjnych, nie za na usuwaniu skutkw powstaych proble-
mw.
Komunikacja
Wymiana informacji midzy wszystkimi poziomami powinna by swobodna. Do-
tyczy to zarwno informacji o rozpoznanym ryzyku, jak i przyjtej strategii jego mi-
nimalizacji. Kady musi by odpowiedzialny za informowanie o wszystkim, co moe
zakci realizacj projektu. Rol kierownika projektu jest stworzenie struktury ko-
munikacyjnej.
Zintegrowane zarzdzanie
Zarzdzanie ryzykiem jest czci zarzdzania projektem, dlatego musi by trak-
towane integralnie z innymi dziaaniami wspierajcymi. Znalezienie wszelkich mo-
liwych 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 jako-
ciowych systemu (np. przeduenie czasu realizacji, zwikszenie kosztw, za-
wodno 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,
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 wspo-
magania zarzdzania w przedsibiorstwie oraz brak zaangaowania jego kierownic-
twa,
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 prze-
twarzania danych,
brak dostatecznej motywacji przyszych uytkownikw rozwizania informa-
tycznego,
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 krajo-
wych 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 istot-
nych zagroeniach, aby analiza bya pomocna w uruchamianiu dziaa zapobiegaw-
czych.
5.2. Identyfikacja ryzyka metody analizy ryzyka

kwestionariusze, listy kontrolne
Identyfikacja ryzyka moe odbywa si wedug okrelonych metod, ktre s prefe-
rowane w danej organizacji, ktra realizuje projekt. Najczciej wybrane metody ana-
lizy 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 wszyst-
kich testw?
Czy przygotowano plany testowania?
Jakie jest dowiadczenie zespou testujcego?
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 wst-

pujc i zstpujc.
Tabela 5.1. Porwnani analizy ryzyka zstpujcej i wstpujcej

Analiza Przegldanie list kontrolnych, zawierajcych spis potencjalnych zagroe
zstpujca i odnoszenie tych zagroe do obecnej sytuacji
Analiza sytuacji biecej pozwala ograniczy liczb rozpatrywanych zagroe
Wykorzystanie list kontrolnych w celu utrzymania waciwego zakresu analiz
Analiza Ocena sytuacji obecnej i wskazanie moliwych negatywnych skutkw w przyszoci
wstpujca 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 opro-
gramowanie, 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 identyfi-
kacji 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.
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 charaktery-

styk 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 zidentyfiko-

walimy 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. zao-
e, analiz itd., aby zamawiajcy opracowanie systemu informatycznego wyznaczy oso-
b (zesp), ktra bdzie akceptowaa produkty czciowe powstajce w trakcie projektu.
5.3. Akcje naprawcze

Akcje Jeli ryzyko moe by obnione przez natychmiastowe dziaania
bezwarunkowe podejmowane w stosunku do wpywajcych na nie czynnikw
Akcje Jeli poziom ryzyka wymaga ledzenia i jeeli zaistnieje taka
awaryjne 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.
Plan postpowania awaryjnego zawiera:

identyfikacj zagroe, ktrych dotyczy,
metod ledzenia ryzyka zwizanego z tymi zagroeniami,
przypisanie odpowiedzialnoci za ledzenie ryzyka i realizacj planu do czon-
kw zespou,
warunki uruchomienia planu,
przydzia zasobw do wykonania planu,
ograniczenia zwizane z opracowaniem planu.
Najwikszym nieporozumieniem w zarzdzaniu ryzykiem jest podejcie, ktre po-

lega 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 Waga
techniczna 3
organizacyjna 4
finansowa 5
zewntrzna 4
.
Tabela 5.3. Wartoci ryzyka
Warto Znaczenie
1 pomijalne
2 niskie
3 rednie
4 wysokie
5 katastrofalne
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 zale-
noci s definiowane poszczeglne wskaniki ryzyka.
W tabeli 5.2 przydzielono subiektywnie dla poszczeglnych kategorii ryzyka war-
toci wag. Waga ma stanowi ogln ocen wanoci gwnego zagroenie ocenia-
nego 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 zapobiegaw-
czych oraz wartoci ryzyka cakowitego posugujemy si wzorami:
ryzyko nieznormalizowane kategorii
R v
Rx = v
,
n
ryzyko znormalizowane kategorii
Rx wx
Rzn _ x = ,
wsr
ryzyko nieznormalizowane cakowite
R x
Rcalk = x
,
k
ryzyko znormalizowane cakowite
R zn _ x
Rzn_calk = x
k
gdzie:
n liczba zada nalecych do danej kategorii,
Rv warto ryzyka dla zadania nalecego do danej kategorii,
k liczba kategorii,
wx waga ryzyka kategorii,
wx
wsr rednia warto wagi wyliczana ze wzoru wsr = x
.
k
Zadaniem normalizacji jest wyrwnanie skrajnych i subiektywnych oce zagroe
ze strony bezporednich wykonawcw, kierownikw zespow czy niekiedy samego
kierownika projektu. Powysze wskaniki liczymy przed konfliktem po wprowadze-

niu akcji zapobiegawczych, aby oceni czy ograniczylimy ryzyko projektu do po-
ziomu akceptowalnego przez sponsora projektu (komitet sterujcy).
Jeli zadania wyspecyfikowane dla okrelonego projektu maj okrelony czas trwa-
nia, przypisane zasoby do ich realizacji, to kolejnym etapem jest identyfikacja tych za-
da, 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 zagroe-
nie wystpio lub zaczyna faktycznie uaktywnia si w projekcie. Opis ryzyka jest zwi-
zany z tym, czego chcemy unikn lub ograniczy w projekcie. Jeli zadania np. wpro-
wadzone 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 pozosta-
wiamy 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 Kat. Wart. Objawy Opis ryzyka

80 Analiza T 4 Brak informacji lub Niedokadnie lub nieprawi-
informacje niekompletne dowo przeprowadzona
analiza
81 Modelowanie T 4 Czonkowie stowarzy- Model nie odzwierciedla
szenia zgaszaj braki rzeczywistoci lub jest
w procedurach niekompletny
analiza
analiza

88 Integracja opracowanych T 3 Brak dokumentu Procedury nie s spjne
procedur z opracowaniem proce-
dur w terminie
92 Przeprowadzenie ankiet O 5 Brak ankiet w terminie Maa frekwencja, trudno
wrd studentw z zebraniem odpowiedniej
prby
94 Wywiady z czonkami O 5 Brak wynikw rozmw Nie mona dotrze do od-
stowarzyszenia w terminie powiednich osb
97 Projekt graficzny O 4 Brak projektu w terminie Grafik przydzielony do
innych prac zleconych przez
stowarzyszenie
98 Projekt funkcjonalny T 3 Programici skar si, Projekcie nie specyfikuje
e nie maj wszystkich wszystkich zgoszonych
informacji wymaga
99 Projekt bazy danych T 3 Programici czsto W projekcie bazy danych nie
prosz o wprowadzanie s odzwierciedlone wszyst-
zmian w schemacie kie zwizki wystpujce
bazy danych w rzeczywistoci lub brakuje
pewnych pl w tabelach
102 Wywiady z czonkami O 5 Brak wynikw rozmw Nie mona dotrze do od-
stowarzyszenia w terminie powiednich osb
104 Projekt graficzny O 4 Brak projektu w terminie Grafik przydzielony do
innych prac zleconych przez
stowarzyszenie
105 Projekt funkcjonalny T 3 Programici skar si, Projekcie nie specyfikuje
e nie maj wszystkich wszystkich zgoszonych
informacji wymaga
106 Projekt bazy danych T 3 Programici czsto W projekcie bazy danych nie
prosz o wprowadzanie s odzwierciedlone wszyst-
zmian w schemacie kie zwizki wystpujce
bazy danych w rzeczywistoci lub brakuje
pewnych pl w tabelach
110 Budowa sieci F 4 Brak sprztu Sponsorzy nie dostarczaj
sprztu lub s opnienia
w przelewach pienidzy
111 Instalacja serwera F 5 Brak serwera Sponsorzy si wycofali lub
sprzt nie dotrze na czas
112 Instalacja stacji roboczych F 5 Brak stacji roboczych Sponsorzy si wycofali lub
w sieci sprzt nie dotrze na czas
117 Modu Dokumenty T 4 Brak moduu na czas Problem z doczaniem
i pozycjonowaniem zdj
w obrbie dokumentw
118 Modu Aktualnoci T 4 Brak moduu na czas Nie gotowy modu doku-
mentw
121 Modu Subskrypcja T 4 Brak moduu na czas Brak dostpu do serwera

SMTP
125 Modu Rekrutacja T 4 Brak moduu na czas Brak dostpu do serwera
SMTP
129 Wprowadzanie danych Z 3 System nie gotowy do Brak wszystkich materia-
testw akceptacyjnych w, ktre maj by za-
mieszczone na stronie
133 Szkolenie z CMS O 4 Opnienia w szkoleniu Trudnoci z zebraniem ludzi
na czas szkolenia
142 Modu I-Mail T 4 Brak moduu na czas Brak dostpu do serwera
SMTP
144 Modu Tablica ogosze T 3 Brak moduu na czas Brak dostpu do serwera
SMTP
149 Wprowadzenie danych Z 3 System nie gotowy do Brak wszystkich materia-
testw akceptacyjnych w, ktre maj by za-
mieszczone na stronie.
154 Szkolenie administratorw O 4 Opnienia w szkoleniu Trudnoci z zebraniem ludzi
na czas szkolenia
155 Szkolenie uytkownikw O 5 Opnienia w szkoleniu Trudnoci z zebraniem ludzi
na czas szkolenia
Tabela 5.5. Wprowadzanie akcji zapobiegawczych minimalizujcych (ograniczajcych) ryzyko zada
ID Akcja zapobiegawcza Koszt Kat. Wart. Prawd. Skutki

80 Szkolenie wewntrzne nt. meto- 1500 T 2 0,7 dokadniejsze wykonanie
83 dologii prowadzenia analizy fazy modelowania, mniej
86 procesw bdw w opracowaniach
81 Szkolenie wewntrzne nt. meto- 1500 T 3 0,7 dokadniejsze wykonanie
84 dologii modelowania procesw fazy modelowania, mniej
87 bdw w opracowaniach
88 2 spotkania w trakcie procesu T 2 0,25 wykrycie i wyeliminowa-
modelowania nie niespjnoci w trakcie
modelowania
92 Przeprowadzenie akcji ankieto- Z 3 0,7 Uatwienie organizacyjne
wej podczas rekrutacji oraz dotarcia do studentw,
Targowiska wiksza frekwencja
94 Przeprowadzenie ankiet lub O 3 0,7 Wykonanie wywiadw na
burzy mzgw podczas spotka- czas, bo bdzie dostp do
nia oglnego oraz wyjazdu wikszoci czonkw sto-
integracyjnego warzyszenia
97 zamwienie projektu na ze- 500 T 3 0,7 projekt graficzny na czas
wntrz stowarzyszenia
98 weryfikacja projektu przez inne- T 3 0,25 wyeliminowanie wikszo-
go czonka zespou w trakcie ci niedopatrze
jego tworzenia
(wewntrzny audyt)

jego tworzenia
(wewntrzny audyt)
102 Przeprowadzenie ankiet lub O 3 0,7 Wykonanie wywiadw na
burzy mzgw podczas spotka- czas, bo bdzie dostp do
nia oglnego oraz wyjazdu wikszoci czonkw sto-
integracyjnego warzyszenia
104 zamwienie projektu na ze- 500 T 3 0,4 projekt graficzny na czas
wntrz stowarzyszenia
jego tworzenia
jego tworzenia
110 Spotkania z dodatkowymi spon- 100 F 2 0,7 Wiksza pewno otrzy-
sorami (rezerwowe rdo) mania sprztu w terminie
117 Dodatkowe testy technologii T 2 0,25 Zapoznanie si z moliwo-
118 przed przystpieniem do prac ciami i atwiejsza imple-
implementacyjnych mentacja moduw
121 Ustalenie dodatkowego serwera T 3 0,4 Moduy i testy na czas
testowego w innym miejscu (np.
na uczelni)
na uczelni)
129 Opracowanie czci materiaw O 2 0,25 Materiay na czas
na wyjedzie strategicznym
133 2 dniowy wyjazd szkoleniowo 1000 O 3 0,25 szkolenie przeprowadzone
154 rekreacyjny do Srebrnej Gry 2 w terminie
155 3
na uczelni)
na uczelni)
149 Opracowanie czci danych O 2 0,25 Materiay na czas
(materiaw) na wyjedzie stra-
tegicznym
SUMA 5300
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 wykorzy-
stania 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 Nieznormalizowane Znormalizowane

Waga
ryzyka przed akcj po akcji przed akcj po akcji
Techniczne 3 3,13 2,17 2,02 1,27
Organizacyjne 4 3,86 2,20 3,86 2,48
Finansowe 5 4,00 2,57 5,00 3,75
Zewntrzne 4 2,57 2,57 2,57 1,93
Cakowite 4 3,39 2,38 3,36 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. Informatyzacja WIGGOR Warto (z)

1 Ryzyko projektu 3,39
2 Ryzyko znormalizowane 3,36
3 Koszt akcji zapobiegawczych 5 300
4 Ryzyko projektu po akcjach zapobiegawczych 2,38
5 Ryzyko znormalizowane po akcjach zapobiegawczych 2,36
Ostateczn decyzj dotyczc wprowadzenia akcji zapobiegawczych zmniejszaj-

cych (ograniczajcych ) ryzyko podejmuje PM, a w przypadku gdy projekt ma ograni-
czony budet i poziom ryzyka projektu jest akceptowalny, dla sponsora mog nie by
wprowadzane niektre dziaania. W powyszym przykadzie 5300 z stanowi zwiksze-
nie 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.
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 za-
planowanym (szary) a pokazujcym obecn sytuacj (czerwony). Zadanie zaplano-
wane byo na okoo 2500 h. Poniewa w poowie jego realizacji kierownik progra-
mistw 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 czst-
kowych, 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 zada-
nia 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.
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 wy-
znaczenia 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:

a + 4m + b
ta =
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 niepew-
noci oszacowania czasu tz trwania aktywnoci i dane jest wzorem:
ba
s= .
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 aktywno-
ci, 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 kil-
ka aktywnoci, ktre s wykonywane jednoczenie, standardowe odchylenie obliczane
jest na podstawie najduszej aktywnoci (tej, ktra posuya do obliczenia czasu w
punkcie a). Jeeli t aktywno poprzedza inne zadanie, standardowe odchylenie za-
dania kocowego obliczane jest z wzoru:
s = szad_poprz + sakt .
2 2
c) Wyznaczy dla zadania warto wspczynnika z ze wzoru:

T t
z=
s
gdzie:
T dana data docelowa zakoczenia zadania,
t czas oszacowany w punkcie a).
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
Prawdopodobiestwo niedotrzymania terminu [%]
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 ry-
zyka kadego zadania pozwoli na wyonienie tych zada, ktre wymagaj szczegl-
nej opieki.
Przykad
Projekt SEZAM skada si z omiu aktywnoci. Oznaczmy je literami AH. Za-
my, e eksperci na podstawie swojego dowiadczenia i analizy projektu wyzna-
czyli czas realizacji poszczeglnych aktywnoci w nastpujcy sposb (patrz tabela
5.8).
Tabela 5.8. Czas trwania poszczeglnych aktywnoci
Czas trwania aktywnoci [tygodnie]

Aktywno Optymistyczny Najbardziej prawdopodobny Pesymistyczny
(a) (m) (b)
A 5 6 8
B 3 4 5
C 2 3 3
D 3,5 4 5
E 1 3 4
F 8 10 15
G 2 3 4
H 2 2 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 projek-
cie, a przede wszystkim obcienia czasowego.
Dla kadej aktywnoci obliczamy oczekiwany czas trwania t oraz odchylenie stan-
dardowe 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 6,17 0,50
B 4,00 0,33
C 2,83 0,17
D 4,08 0,25
E 2,83 0,50
F 10,5 1,17
G 3,00 0,33
H 2,08 0,08
Nasz projekt, zgodnie z grafem zamieszczonym poniej, skada si z 6 zada. Do-

datkowo 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 ak-
tywnoci 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 ob-

liczenie wartoci z i odwzorowanie jej na prawdopodobiestwo niedotrzymania termi-
nw poszczeglnych zada. Obliczenia zebralimy w tabeli 6.10, ktra umoliwia na
podstawie odczytania z wykresu (rys. 5.3) wartoci prawdopodobiestwa niedotrzy-

mania terminw realizacji poszczeglnych zada w zalenoci od wartoci wsp-
czynnika z.
Tabela 5.10. Wyznaczenie prawdopodobiestwa niedotrzymania terminw realizacji

poszczeglnych zada
Docelowa data Prawdopodobiestwo

Zadanie Warto z
ukoczenia [tygodnie] poraki [%]
1
2
3
4 10 1,887 4
5 10 0,427 68
6 15 1,231 11
Wida, e zadanie 5 ma najwiksze prawdopodobiestwo przekroczenia czasu re-

alizacji i wynosi ono a 68%. Jest to zgodne z naszymi oczekiwaniami, gdy oszaco-
wany 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: przed-

siwzicie 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 obsza-
rze jego zastosowania. Przez rozwizania informatyczne rozumiemy metody kompute-
rowego wspomagania przebiegu rnorodnych procesw zarzdczych, ekonomicz-
nych, 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 wpro-
wadza nowe elementy do ju istniejcych rozwiza, jest nastpujcy:
nowe podejmowane przedsiwzicie ma zupenie nowy charakter dla organiza-
cji, tj. nie funkcjonuj w niej systemy informatyczne,
uzupeniajce realizowane przedsiwzicie wnosi nowe elementy do ju istnie-
jcych rozwiza (np. rozbudowa sieci komputerowej),
programowe projekt dotyczy wdroenia nowego typu oprogramowania przy ist-
niejcych 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 skomplikowa-
ny 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-
6. Projekty wdroeniowe outsourcing 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 takie-
go 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 (wsp-
dzielenie 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 uyt-
kownikw,
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 uyt-
kownika 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,
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 realizacyj-
nych,
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
oprogramowania,
zintegrowane, zwane testami akceptacyjnymi, zwizane z kontrol i korekt ca-
oci oprogramowania systemu, bdce podstaw harmonijnego wspdziaania
wszystkich jego moduw.
Jako wedug ISO 9000 og cech i waciwoci wyrobu lub usugi, decyduj-
cych o zdolnoci wyrobu lub usugi do zaspokojenia stwierdzonych lub przewidywa-
nych 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 sukcesyw-
ne instalowanie poszczeglnych moduw zastpujcych dotychczas uytkowa-
ne.
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 specjali-
stycznej 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
zasadzie outsourcingu zarzdza nim na poziomie administracji sprztowej i aplikacyj-

nej oraz nadzoruje prac sieci rozlegej. Firma odpowiedzialna jest rwnie za infra-
struktur oraz komunikacj zewntrzn. Serwery s najczciej przenoszone do cen-
trum 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 administro-
wanie systemem. W firmie zainstalowane s tylko komputery uytkownikw koco-
wych, przetwarzanie danych odbywa si w centrum obliczeniowym firmy outsourcin-
gowej, zdalne jest take administrowanie caym systemem. Szkoleniom poddawani s
tylko uytkownicy kocowi.
Podsumowujc jest to wzgldnie szybki i bezpieczny sposb wdroenia zinte-
growanego systemu informatycznego.
Porwnanie tradycyjnego podejcia do zakupu i wdroenia systemu informatycz-
nego 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 Dzierawa; opaty zalene
od klasy sprztu
Wdroenie Tak Tak
Opata za cza TP SA Brak Wymagana
Oprogramowanie aplikacyjne Zakup Dzierawa; opaty zalene od rodzaju
oprogramowania i efektywnego czasu
jego wykorzystywania (biling)
Oprogramowanie narzdziowe Zakup Opaty wliczone w opaty za
oprogramowanie
Instalacja i konfiguracja Wymagane Opaty wliczone w opaty za
oprogramowanie oprogramowanie i sprzt
Koszt utrzymania personelu Wymagane Nie
informatycznego
Podzia outsourcingu
Outsourcing jest pojciem do rozlegym, dotyczcym rnych dziedzin dziaal-

noci gospodarczej i biznesowej. W informatyce rozwin si i dotyczy nie tylko sys-
temw 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 zwy-
kle na jednym aspekcie dziaalnoci (np. termin realizacji), przewanie ograni-
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. co-
re 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 ze-
wntrznej 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 ja-
kociowych.
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 przedsiwzi-

cia, wymagania, kryteria wyboru Zintegrowanego Systemu Informatycznego (ZSI):
udokumentowanie istniejcych procedur dziaania,
opracowanie opisw procesw, przygotowanie koniecznej restruktury-
zacji przedsibiorstwa,
ocena skali przedsiwzicia, ryzyka, kosztw i terminw.

Faza 2 opracowanie koncepcji informatyzacji przedsiwzicia:
selekcja i wybr gotowego systemu informacji,
konfigurowanie oprogramowania aplikacyjnego wedug modelu proto-
typowania,
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 wyma-
ga uytkownika,
stay rozwj i dostosowywanie.
Formy szkole
Kade wdroenie systemu informatycznego musi zawiera efektywn form szko-

lenia uytkownikw systemu. S rne metody i formy szkolenia np.:
szkolenia prowadzone w zorganizowanych orodkach szkoleniowych wyposa-
onych 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 zarz-
dzanie 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 zarzdza-
nia. Wybr lub brak wyboru adekwatnej strategii realizacji, niewystarczajce wsparcie
projektu przez sponsora i kierownictwo firmy wykonawczej, niewystar-
czajca wsppraca z klientem, zbyt oglna analiza systemowa. Niewaciwy harmo-
nogram i alokacja zasobw, powodujca konieczno wykonania prac kosztem ich
jakoci, utrata kontroli nad zarzdzaniem zmianami i inne. W tym rozdziale przedsta-
wione 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 do-
kument Chaos stworzony w 1995 roku przez Standish Group [53], cho od 1995 r.
upyno kilka lat, to aktualno tych danych co do specyfikacji niektrych zaleno-
ci 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 przepro-
wadzone w firmach IT. Wyniki bada opieraj si na wywiadach z ludmi uczestni-
czcymi w tworzeniu projektw.
W badaniach byy brane pod uwag mae, rednie oraz due przedsibiorstwa
(dziaajce w Bostonie i San Francisco), poczwszy od duych przemysowych orga-
nizacji, np. bankowo, bezpieczestwo, sprzeda detaliczna, do lokalnych, federal-
nych organizacji. W sumie przebadano 365 firm, wzito pod uwag 8380 aplikacji.
Dla uzyskania poprawnych, rzetelnych wynikw Standish Group przeprowadzio wie-
le 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
zakoczone penym sukcesem to takie, ktre s kompletne, nie przekroczyy czasu ani
budetu. Projekty zakoczone niepenym sukcesem s kompletne, ale zosta przekro-
czony 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% pro-
jektw w wielkich przedsibiorstwach zakoczyo si sukcesem, w rednich 16,2%,
w maych 28%. Wikszo z projektw wielkich firm zakoczya si sukcesem nie-
penym, 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% szaco-
wanego budetu; dla wielkich przedsibiorstw: 178%, dla rednich 182% i 214% dla
maych.
Tabela 7.1
Przekroczenie budetu Liczba projektw

(w procentach) (w procentach)
Poniej 20% 15,5%
2150% 31,5%
51100% 29,6%
101200% 10,2%
201400% 8,8%
Ponad 400% 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 Liczba projektw
(w procentach) (w procentach)
Poniej 20% 13,9%
2150% 18,3%
51100% 20,0%
101200% 35,5%
201400% 11,2%
Ponad 400% 1,1%
O penym sukcesie projektu decyduje niewtpliwie zgodno produktu kocowego

z zaoeniami, powstaymi przed realizacj projektu. Dla duych przedsibiorstw tylko
7. Czynniki sukcesw i niepowodze projektw 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 Liczba projektw

z zaoeniami (w procentach) (w procentach)
Mniej ni 25% 4,6%
2549% 27,2%
5074% 21,8%
7599% 39,1%
100% 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 projek-
tw. 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
Liczba projektw
Lp. Czynniki sukcesu projektu
(w procentach)
1 Zaangaowanie klienta 15,9%
2 Wsparcie kierownictwa 13,9%
3 Jasne okrelenie wymaga 13,0%
4 Waciwe planowanie 9,6%
5 Realistyczne oczekiwania 8,2%
6 Mniejsze odstpy midzy punktami kontrolnymi 7,7%
7 Kompetencje pracownikw 7,2%
8 Odpowiedzialno 5,3%
9 Jasno sprecyzowane cele 2,9%
10 Ciko pracujcy pracownicy 2,4%
11 Inne 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 suk-
cesu 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 zanie-
dbany.
Projekty zakoczone penym sukcesem: Hyatt Hotels, Banco Itamarati.
Projekty zakoczone klsk: California DMV, American Airlines.
Tabela 7.5
California American Hyatt Banco

Lp. Czynniki sukcesu projektu
DMV Airlines Hotels Itamarati
1 Zaangaowanie klienta nie nie tak tak
2 Wsparcie kierownictwa nie tak tak tak
3 Jasne okrelenie wymaga nie nie tak nie
4 Waciwe planowanie nie nie tak tak
5 Realistyczne oczekiwania tak tak tak tak
6 Mniejsze odstpy midzy nie nie tak tak
punktami kontrolnymi
7 Kompetencje pracownikw nie nie tak tak
8 Odpowiedzialno nie nie tak tak
9 Jasno sprecyzowane cele nie nie tak tak
10 Ciko pracujcy pracownicy nie nie tak tak
11 Inne nie tak tak tak
Z przeprowadzonych bada przez Standish Group w roku 2003 wynika, e zwik-

sza 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 za-
kresie prowadzenia projektw co do ich wskanika projektw zakoczonych sukce-
sem 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 procento-
wego 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 projek-
tami.
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 za-

ley od wielko projektu. Wiadomo, e jeeli mamy do czynienia z duymi projek-
7. Czynniki sukcesw i niepowodze projektw 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 projek-
tu, 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 doku-
mencie Release 6 w kwietniu 2000 roku podaje przykadowe obliczanie kosztu red-
niego 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 za-
chodzi 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, po-
niewa wynika z tego, e krtsze ramy czasowe wytwarzania komponentw zwiksza-
j wspczynnik sukcesu, dziki iteracyjnemu procesowi projektowania, prototypowa-
nia, testowania i przekazywania maych elementw. Wiksze systemy powstaj
z maych komponentw i kady z nich ma posiada precyzyjnie okrelony zestaw ce-
lw i realistycznych oczekiwa klienta.
8. Rola i zadania kierownika projektu
Jak ju zaznaczono we wprowadzeniu tej ksiki wiedza na temat zarzdzania pro-

jektami nie powinna by zarezerwowana jedynie dla najwyszego kierownictwa, od-
powiedzialnego 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, po-
wiadczone certyfikatem uprawnienia do tego tytuu. Dyplomy wydawane przez
MT&DC przy wsppracy z Educational Services Institute International (ESI) po-
twierdzaj uzyskanie przez uczestnika kursu, gruntownego wyksztacenia i nabycia
kompetencji w tym zakresie. Otrzymanie certyfikatu ESI czy si z fundamental-
nym 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, zwol-
nienia 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, nowator-
skimi 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,
8. Rola i zadania kierownika projektu 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, nie-
koniecznie 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 zastosowa-
niach bezporedni nadzr sprawuj czonkowie zarzdu firmy. To czy firma realizujca
projekt liczy 510 osb czy 2000 zasadniczo wpywa na usytuowanie PM. Typowe gru-
py 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,
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 zao-
onego 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 at-
mosferze 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 wy-

specjalizowanych firm lub komrki organizacyjnej, ktre zajmuj si rwnie zarz-
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 pracy-
poszukiwanie 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 pra-
cownikw 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-
serwowa tok realizacji zada z nim zwizanych, jednak nie miaa okazji zdoby prak-
tyki w jego realizacji. Jeli osoba posiada tylko wiedz z danego zagadnienia, kierow-
nik nie decyduje si raczej przydziela penego zadania do wykonania przez t osob,
poniewa z wiedzy zgodnie z niniejsz definicj nie wynika jeszcze zdolno realiza-
cji. 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 spe-
cjalizuj 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 rezulta-
tem 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 za-
daniem zakoczy si sukcesem (naley zatem ze zdolnoci szczeglnie silnie koja-
rzy pojcie samodzielnoci w dziaaniu).
kompetencje spoeczne kompetencje biznesowe
KOMPE-
TENCJE
UMIEJTNOCI
WIEDZA
kompetencje profesjonalne
kompetencje integracyjne kompetencje branowe
Rys. 8.1. Schemat oglny klasyfikacji kompetencji

Umiejtno mwi o tym, e dana osoba jest w stanie wykona czynno prak-
tyczn w sposb automatyczny (bez szczeglnych przemyle, np.: moe opiera si na
naladownictwie lub cechach wrodzonych) lub ze wsparciem. Umiejtno w szczegl-
noci dotyczy niezbyt zoonych podzada czstkowych, ktrych wykonanie nie wyma-
ga 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 pro-
jekcie.
Przedstawiony na rysunku 8.1 graficznie podzia i przenikanie si granic midzy
wiedz, umiejtnociami a kompetencjami, szczeglne istotne dla PM staj si kompe-
tencje profesjonalne w obszarze produktw branowych oraz integracyjnych.
W przedsiwziciach integracyjnych nie bez znaczenia s postawy prezentowane part-
nerw, osobowo PM oraz szersza wiedza wykraczajca poza wiedz dotyczc pro-
duktu z uwagi na konieczno prowadzenia wielu rozmw i uzgodnie nie tylko biz-
nesowych, 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 znaj-
dowa 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 ze-
spou.
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 trud-
no definiowalne (biznesowe, spoeczne, techniczne, rodowiskowe, etyczne, politycz-
ne), ale w niektrych projektach mog mie podstawowe znaczenie w doprowadzeniu
projektu do sukcesu [5, 13, 30, 42, 59].
8.5. Konflikt
W ostatnich kilkunastu latach ulegy zmianie zapatrywania na konflikt, czyli pro-

blem nieporozumie oraz brak zgodnoci co do sposobu podejcia do realizacji pro-
jektu 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 Wspczenie
Zbdny i szkodliwy Nieunikniony
Mona unikn Naley nim kierowa
Powodem jest bd kierownictwa Za struktura zarzdzania, sposb
lub osoby konfliktowej 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 niezado-
wolone i oczekuj na nastpn sytuacj, kiedy i ich racje zwyci. Kady element zbio-
rowoci 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 zagad-
nienia, ktre dotycz ambicji oraz emocjonalnego zaangaowania najbardziej kre-
atywnych i o wyranej osobowoci czonkw zespou.
8.6. Motywowanie
Wedug Griffina [22] Motywowanie, to zestaw si, ktre powoduj, e ludzie za-
chowuj si w okrelony sposb. Zasadniczym celem stosowania technik motywacyj-
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 od-
pyw kapitau intelektualnego, mona utraci znaczc cz potencjau firmy, co wy-
wrze 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, bezpie-
czestwa, 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 przeciw-
ko 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 pro-
jektu (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 pra-
cownika, od zakresu jego kompetencji. Naley jednake zaznaczy, e rzadko mona
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 kom-
petencji stanowi tylko jeden z czynnikw wpywajcy na wysoko zarobkw pracowni-
ka, bdc po czci rwnowaone przez wycen wartoci wytwarzanych przez pracowni-
ka
(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 okre-
sowych 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 osi-
gn maksimum swojej potencjalnej wydajnoci i jakoci pracy, podobnie w przypad-
ku pracownika dobrze zmotywowanego, ale nie posiadajcego odpowiedniego zakresu
kompetencji. Dopiero pracownik kompetentny i dobrze zmotywowany stanowi na-
prawd wartociowy nabytek dla firmy i jest zdolny do osigania znakomitych wyni-
kw 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 ce-
lw zawodowych z celami indywidualnymi czonkw zespou.
Czynniki motywujce
Coraz czciej, a wynika to z licznych ankiet, jak rwnie preferowanych przez pra-
cownikw cieek rozwoju, e gwnymi czynnikami motywujcymi do pracy s:
waciwy rozdzia pracy dla kadego interesujcej i odpowiedzialnej,
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 zainteresowa-
niom, 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 dotycz-
cych 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 moli-
woci 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 podejmu-
jc 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 ponie-
sie 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-
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, przy-
czyny s gboko rozwaane,
wikszo decyzji na zasadach konsensusu, rzadko oficjalne gosowania, wik-
szo 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 sformu-
owane przez Belblina (patrz rozdz. 8.2. Dobr czonkw zespou).
9. Dodatek
Ten rozdzia ma wskaza na przykadowe fakty w postaci wypracowanych i przy-

jtych 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 Te-
lecomunications Agency)/SPOCE. Zostaa ona oparta na wczeniejszej metodzie, zna-
nej pod nazw PROMPT. W 1999 firma CRM S.A. adaptuje metod PRINCE 2-
SPOCE-CRM do warunkw polskich [6]. PRINCE 2 jest standardem brytyjskiej ad-
ministracji publicznej i biznesu do zarzdzania projektami, jest te powszechnie przy-
jta jako standard zarzdzania projektami wszystkich rodzajw w sektorze publicznym
i prywatnym.
1. Projekt jest skoczonym zbiorem aktywnoci, majcym swj pocztek i ko-
niec.
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, wysokobu-
detowych 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,
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 pro-
jektu,
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 pro-
jekt.
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 progra-
mowe lub przygotowane formularze, ktrych wypeniane jest elementem metody pro-
wadzenia projektu. Zaczone ekrany (rys. 9.2) wskazuj na wykorzystywanie PERT
w analizie czasowej realizacji projektu, w ktrej szacuje si najwczeniejszy czas roz-
poczcia zadania, najpniejszy czas rozpoczcia zadania, czas jego trwania, opnie-
nie 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 mi-

dzy innymi struktura organizacyjna projektu zarzdzana zgodnie z metod PRINCE 2
(rys. 9.3).
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 odpo-
wiednimi narzdziami bd dysponowali jego uczestnicy. Oprogramowanie przezna-
czone do kontroli wersji powinno zapewnia analiz historii zmian i moliwo uzy-
skania 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 two-
rzonych i odpowiednio nazywanych kopii projektu. Podejcie to jest jednak bardzo
nieefektywne, podatne na bdy, utrudnia przegldanie zmian i jest praktycznie nie-
moliwe do zastosowania w zespoach wikszych ni jednoosobowe. Na szczcie
9. Dodatek 145
istnieje caa gama dedykowanego do tego celu oprogramowania, poczwszy od pro-

stych narzdzi, przeznaczonych dla pojedynczych deweloperw, na zoonych syste-
mach skierowanych do zespow liczcych setki uczestnikw. Przegld ten ma na celu
przedstawienie gwnych cech oprogramowania oraz wskazanie najbardziej znacz-
cych narzdzi wspomagajcych zarzdzanie zmianami.
Najczciej jest to oprogramowanie darmowe, lecz niekoniecznie z penym wspar-
ciem ze strony producenta. Jest duo narzdzi dostpnych bez opat niektre z nich
s dostarczane z wikszoci systemw Unix, niektrych trzeba poszuka w Interne-
cie. 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 uy-
wania 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-
mem w peni sieciowym, bazujcym na centralnym repozytorium. Umoliwia jednocze-

sn 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 mecha-
nizmu znacznikw pozwala rwnie odnosi si do caoci projektu. Umoliwia tworze-
nie 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 meta-
danych repozytorium. Znacznie lepiej wspiera zmian nazw plikw i zapewnia atomi-
zacj zmian repozytorium. Dane nie s przechowywane w formacie RCS, lecz
umieszczone w specjalnej bazie danych (aktualnie Berkeley DB). Mechanizmy sie-
ciowe 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 ko-
dem. W przeciwiestwie do programw kontynuujcych filozofi CVS, umoliwia ka-
demu 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 przydzie-
lany jest niezaleny od jego nazwy znacznik). Zapewnia atomowo operacji, zaawan-
sowane 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). Pierw-
sza z nich wydaje si stabilniejsza, lecz z powodu korzystania ze skryptu sh, znacznie
wolniejsza, druga, napisana w C++, jest szybsza i oferuje kilka dodatkowych udogod-
nie.
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, wersjono-
wanie 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 automatycz-
nie, 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 prze-
gldania 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 repozyto-
rium, Aegis dostarcza mechanizmy obsugi repozytorium, linii bazowej oraz obowiz-
kowych przegldw i testw. Aegis mona tak skonfigurowa, aby uywa niemale
dowolnego narzdzia do historii (jak np RCS) i niemal dowolnego narzdzia do kon-
trolowania zalenoci (np. make).
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 sys-

temie UNIX.
CVS
CVS (Concurrent Versions System), ktry wymaga RCS (powyej wersji 1.10),
rozszerza RCS do kontroli konkurencyjnego edytowania rde przez kilku pracowni-
kw.
Autor programu podaje nastpujc analogi: RCS jakby jzykiem asemblera,
podczas gdy CVS jest podobny do Pascala. Zaczynajc od wersji 1.8, CVS odnoto-
wuje modyfikacj kadej linii pliku, z numerem korekty, nazw uytkownika dokonu-
jcego 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, w-
czajc w to zintegrowane i zunifikowane zarzdzanie zmianami i korektami, repozyto-
ria 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 dystry-

bucji 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/
9.4. Oprogramowanie komercyjne

do zarzdzania zmianami
Wraz ze wzrostem kosztw wytwarzania oprogramowania coraz wicej firm oferu-

je 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 projek-
tem 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 dystrybu-

owanym 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 konfigu-
racj, 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 151
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/
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 projek-

tw. W 1995 r. SourceSafe zosta przejty przez Microsoft i ponownie nazwany. We-
dug 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 zintegro-
wany z Visual Basic, Visual C, Visual Test oraz z Fortran PowerStation. Posiada bar-
dzo miy model do ustawiania wielu wersji projektu. Kluczowe polecenia dotycz
wspdziele, rozgazie, scalania, czenia i komend cieki. Zamiast uywa licz-
nych rozgazie, tak jak wersja 2.3.6.1 SCCS, logiczne wydania lub nazwy uytkow-
nika 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 kompu-
terze PC Windows PC using Visual Basic i na stacji Unixowej, gdzie si uywa C.
Microsoft System Journal (maj, 1993 r.) nazwany SourceSafe jest najlepszym narz-
dziem 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 pod-
czas pracy programistw.
Mwi si, e uytkownik moe mie jednoczenie dostp do kilku projektw
w VSS, ale bezpieczestwo w SourceSafe dobrze dopracowane; posiada tylko 4 bez-
pieczestwa: read-only, checkout, add i destroy. To moe by niewystarczajce dla
niektrych projektw. Zostao zgoszonych wiele przypadkw uszkodze repozyto-
riw 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. Oprogramo-

wanie 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 nie-
udokumentowane. Dwa pierwsze to narzdzia generujce raporty, uruchamiane
z odpowiednimi parametrami z wiersza polece. QtGantt jest narzdziem wyposa-
onym w interfejs graficzny. Wszystkie programy s przeznaczone dla platformy
Linux, przy czym PyGantt moe by te uruchamiany na innych systemach z zain-
stalowan obsug jzyka Python.
OpenSched 0.1.0 ma najwiksze moliwo-

ci, jako jedyny uwzgldnia zarzdzanie za-
sobami ludzkimi. Tworzy spory zbir rapor-
tw 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 da-
nych wejciowych znajduje si w przykadowych plikach wejciowych.
PyGantt 0.6.0 jest narzdziem do gene-
rowania wykresw Gantta, napisanym jako
skrypt w Pythonie. Przystosowano go
wprawdzie do systemu Linux, jednak po
niewielkiej zmianie moe by rwnie uru-
chamiany pod Windows oczywicie po za-
instalowaniu obsugi jzyka Python. Dane
wejciowe zapisane s w formacie XML.
Struktura pliku nie jest w ogle udokumen-
towana; aby j opanowa, naley przeanalizowa doczony przykad. Skrypt gene-
ruje 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 wyko-
rzystujcy bibliotek Qt. Program zawiera czte-
ry widoki, z ktrych na razie tylko dwa zostay
zaimplementowane: ogldanie wykresu Gantta
i podgld wydruku wykresu. Wykres prezentu-
je list zada z punktami kontrolnymi, infor-
muje
o stopniu zaawansowania poszczeglnych za-
da 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 155
Opis wg PCkurier 2/2002 [52].

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 zarzdza-
nia projektem informatycznym, II Konferencja Project Management perspektywy i dowiadcze-
nia, 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, Au-
gust 1987.
[13] Chylewska J., Jak walczy o najlepszych w firmie, jak zatrzyma kluczowych pracownikw, Mate-
riay 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 reali-
zowanego w firmie o strukturze macierzowej, Materiay VII Konferencji i Warsztatw uytkowni-
kw 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 Kocie-
lisko 2226.10.2002. http://www.ploug.org.pl/konf_02/materialy/spis.htm.
[19] Frczkowski K., Woniak M., Wdroenie systemu informatycznego w szpitalu aspekty organiza-
cyjne, psychologiczne oraz formalne, Oficyna Wydawnicza Politechniki Wrocawskiej, Wrocaw
2000.
[20] Goldratt E.M., acuch krytyczny, Wyd. Werbel 2000.
[21] Grudzewski W.M., Hejduk I., Sposoby i techniki zarzdzania projektem innowacyjnym, II Konfe-
rencja 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 Manage-
ment, 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 Pro-
ject Management Polska (SPMP), Gdask, 2000.
[31] Lapkiewicz J., Frczkowski K., High-Availability Infrastructure Architecture, Web Hosting Transi-
tion. 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, Stowarzy-
szenie 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 Pro-
ject 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 Konfe-
[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, Stowa-
rzyszenie 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 Konfe-
[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.

Zarzadzanie Projektem

Uploaded by

Document Information

Original Title

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

Zarzadzanie Projektem

Uploaded by

Copyright:

Available Formats

Kazimierz Frczkowski

Oficyna Wydawnicza Politechniki Wrocawskiej

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.

Niniejsza ksika stanowi prb opracowania zagadnie zwizanych z zarzdza-

Niekiedy, na pewnym etapie kariery zawodowej, nieoczekiwanie stajemy przed

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

1.1. Przegld historyczny

Potrzeba zarzdzania jest pochodn zoonoci przedsiwzi, ktrych realizacja

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

Wspczenie zarzdzanie kojarzy nam si przede wszystkim z duymi przedsi-

cia celu, jakim byo panowanie na morzu.

Rys. 1.1. Prekursorzy zarzdzania i przeomowe ich dokonania,

1.2. Podstawowe pojcia i definicje

nego urzdzenia, przedmiotu, systemu informatycznego lub obiektu budowlanego.

Projekt od dou do gry (ang. Buttom-up design) proces projektowania sys-

Projekt inynierii oprogramowania (ang. Software engineering project) zestaw

Projekt inynierii systemu (ang. System engineering project) zestaw wszystkich

projektu wyszczeglnione w specyfikacji projektu. W niektrych przypadkach moe

Projekt rozwoju oprogramowania (ang. Software development process) patrz

Projekt wstpny (ang. Preliminary desing) 1. Proces analizowania alternatyw

Projektowanie-do-kosztu (ang. Desing-to-cost) podejcie w zarzdzania projek-

Projektowanie szczegowe (ang. Detalied design) 1. W inynierii oprogramowa-

1.3. Czynniki charakterystyczne projektu

Jak ju wczeniej wspomniano, projekt informatyczny charakteryzuje si innowa-

Projekt a proces czynniki rnicujce

Waciwoci projektw jest ukierunkowanie na zmiany [7, 21]. Wprowadzenie

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

Jeli nie potrafisz czego zaplanowa,

Nie tylko nieudane projekty s rdem postpu.

Planowanie jest procesem realizowanym w caym cyklu ycia projektu

Pytania, jakie najczciej pojawiaj si przed rozpoczciem planowania to:

3. Jak duo czasu powici na planowanie?

2.1. Cele planowania projektu

Planowanie projektu w znacznej mierze jest to szacowanie czasu, nakadw pracy i

Na og planowanie rozumiane jest jako wytyczenie celw organizacji i okrelenie

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

2.2. Definiowanie celw projektu

2.3. Zasoby projektu

W rozdziale tym przyjto nomenklatur i sposb zarzdzania zasobami zaimple-

przykad nadmierna alokacja na poziomie 300% dla Architekta I oznacza, e do wyko-

Co to jest pula zasobw

Pula zasobw umoliwia wspuytkowanie zasobw przez wiele projektw.

2.4. Definiowanie ogranicze w projekcie

Ograniczeniami w projekcie s czynniki, ktre maj podstawowy wpyw na opcje

Opis projektu moe by wykonywany wedug rnych, wczeniej przygotowanych

Wybr strategii prowadzenia

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

Analiza opisu projektu

Jedna z gwnych przyczyn poraek projektw to niewaciwa identyfikacja

2.5. Strategia realizacji projektu

Tabela 2.1. Wybr strategii realizacji projektu

Rozmiar projektu Ocena ryzyka Strategia

Kada strategia realizacji projektu powinna uwzgldnia pryncypia w zakresie za-

2.6. Ocena ryzyka

Najczciej zagroenia (ryzyko projektu) ocenia si w dwch gwnych obszarach

znaczcy wpyw na prac ludzi,

2.7. Struktura projektu dekompozycja projektu

W kadym projekcie PM dekomponuje cay projekt na WBS (ang. Work Break-

Definicja struktury WBS

Gwnym zadaniem kierownika projektu jest waciwe okrelenie elementw