Fraczkowski - Zarządzanie projektem informatycznym

Kazimierz Frczkowski

Zarzdzanie projektem informatycznymProjekty w rodowisku wirtualnym Czynniki sukcesu i niepowodze projektw

Oficyna Wydawnicza Politechniki Wrocawskiej Wrocaw 2003

Wydzia Informatyki i Zarzdzania Wydziaowy Zakad Informatyki

OpiniodawcaZdzisaw SZYJEWSKI

Opracowanie redakcyjne i korektaAlina KACZAK

Projekt okadkiJustyna 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 treciOd Autora ............................................................................................................................................ Wprowadzenie ................................................................................................................................... 1. Geneza zarzdzania projektami ..................................................................................................... 1.1. Przegld historyczny wybranych zagadnie zarzdzania .................................................... 1.2. Podstawowe pojcia i definicje stosowane w zarzdzaniu projektami ................................. 1.3. Czynniki charakterystyczne projektu ................................................................................... 1.4. Proces ................................................................................................................................... 2. Planowanie projektu informatycznego .......................................................................................... 2.1. Cele planowania projektu ..................................................................................................... 2.2. Definiowanie celw projektu ............................................................................................... 2.3. Zasoby projektu ................................................................................................................... 2.4. Definiowanie ogranicze w projekcie .................................................................................. 2.5. Strategia realizacji projektu ................................................................................................. 2.6. Ocena ryzyka ....................................................................................................................... 2.7. Struktura projektu dekompozycja projektu na zadania WBS ......................................... 2.8. Szacowania w projekcie ....................................................................................................... 2.9. Metoda punktw funkcyjnych ............................................................................................. 2.10. Harmonogram ...................................................................................................................... 2.11. Sieciowe diagramy zalenoci ............................................................................................. 2.12. Inicjowanie projektu ............................................................................................................ 3. ledzenie i zarzdzanie zmianami projektu ................................................................................... 3.1. ledzenie projektu monitorowanie .................................................................................... 3.2. Zarzdzanie jakoci w projekcie ........................................................................................ 3.3. rda i rodzaje zmian ......................................................................................................... 3.4. Proces zarzdzania zmianami .............................................................................................. 3.5. ledzenie i nadzorowanie czasu oraz kosztw projektu ....................................................... 3.6. Nadzorowanie projektu metod wartoci uzyskanej (Earned Value) ................................... 3.7. Podsumowanie ..................................................................................................................... 4. Modele pracy i komunikacji .......................................................................................................... 4.1. Telepraca .............................................................................................................................. 4.2. Modele organizacji pracy zespow projektowych .............................................................. 4.3. Elektroniczny czonek zespou zesp .............................................................................. 4.4. Wirtualna sie partnerw przedsiwzicia ........................................................................... 4.5. Zespoy Projektowe ............................................................................................................. 4.6. Praca grupowa ...................................................................................................................... 5. Zarzdzanie ryzykiem ................................................................................................................... 5.1. Czynniki majce wpyw na ryzyko ...................................................................................... 5 6 8 8 11 13 14 17 18 19 20 21 24 25 26 31 34 45 48 50 52 52 53 59 60 65 66 74 77 78 80 85 89 91 92 94 99

4

Spis treci 102 104 105 113 118 118 121 125 125 128 130 131 132 133 136 136 136 139 141 141 144 145 150 153 155 161

5.2. Identyfikacja ryzyka metody analizy ryzyka kwestionariusze, listy kontrolne .............. 5.3. Akcje naprawcze .................................................................................................................. 5.4. Metoda punktowa szacowania ryzyka ................................................................................. 5.5. Metoda PERT szacowania ryzyka ....................................................................................... 6. Projekty wdroeniowe outsourcing ............................................................................................ 6.1. Rodzaje projektw informatycznych oraz organizacja pracy i zespow ............................ 6.2. Wdroenie przez outsourcing .............................................................................................. 7. Czynniki sukcesw i niepowodze projektw .............................................................................. 7.1. Niektre badania statystyczne niepowodze projektu ......................................................... 7.2. Wpyw wielkoci projektu na jego sukces ........................................................................... 8. Rola i zadania kierownika projektu ............................................................................................... 8.1. Usytuowanie kierownika projektu a jego skuteczno ......................................................... 8.2. Dobr czonkw zespou ...................................................................................................... 8.3. Rekrutacja czonkw zespou ............................................................................................... 8.4. Budowa kompetencji w projekcie ........................................................................................ 8.5. Konflikt ................................................................................................................................ 8.6. Motywowanie ...................................................................................................................... 8.7. Delegowanie uprawnie ....................................................................................................... 9. Dodatek ......................................................................................................................................... 9.1. Metoda zarzdzania projektami PRINCE-2 ......................................................................... 9.2. Oprogramowanie wspomagajce zarzdzanie zmianami ..................................................... 9.3. Najpopularniejsze narzdzia open source ............................................................................ 9.4. Oprogramowanie komercyjne do zarzdzania zmianami ..................................................... 9.5. Narzdzie open source do zarzdzania projektami .............................................................. Sownik poj i terminw .................................................................................................................... Literatura .............................................................................................................................................

Od autoraNiniejsza ksika stanowi prb opracowania zagadnie zwizanych z zarzdzaniem przedsiwziciami informatycznymi. Obejmuje wybrane wspczesne pogldy na tematy, ktre s kluczowe w obszarze planowania, zarzdzania zmianami, organizacji zespow projektowych, szacowania kosztw, monitorowania ryzyka i decyduj o sukcesie lub niepowodzeniu projektu. Celem opracowania jest rwnie prba podzielenia si z czytelnikami wasnym dowiadczeniem zawodowym, nabytym podczas prac nad projektami informatycznymi, uczestniczenia w szkoleniach z tej tematyki oraz prowadzenia wykadw i seminariw na Wydziale Informatyki i Zarzdzania Politechniki Wrocawskiej, dla studentw kierunku Inynieria Oprogramowania w latach 1998 2003. Prace nad ksik zainicjowao dostarczenie mi notatek w postaci elektronicznej z cyklu moich wykadw przez studenta pana Piotra Hojnara. Dzikuj rwnie innym studentom, ktrzy przygotowujc i prezentujc w trakcie seminariw niektre zagadnienia z tej dziedziny, narzekali na brak polskiej literatury z tego przedmiotu, przez co stymulowali prac nad ksik. Studenci, ktrzy uczestniczyli w dojrzaych dyskusjach na seminariach i przygotowali interesujce wystpienia, stali si poniekd wspautorami niniejszego opracowania. Ksika jest przeznaczona dla studentw informatyki i zarzdzania oraz kierownikw projektw. Zawarto opracowania to prba osignicia kompromisu midzy rozlegym zakresem tematycznym tego zagadnienia a programem studiw, ktry opracowalimy wsplnie z pani dr in. Iwon Dubielewicz, ktrej dzikuj za cenne propozycje dotyczce omawianych zagadnie i sposobu ich przedstawienia. Zachty i osobistego wsparcia w pracy udzieli mi prof. Zbigniew Huzar, ktremu dedykuj t prac. Bd wdziczny wszystkim, ktrzy zechc przesa uwagi i sugestie dotyczce podrcznika. Adres: e-mail: [email protected] Kazimierz Frczkowski

WprowadzenieNiekiedy, na pewnym etapie kariery zawodowej, nieoczekiwanie stajemy przed szans zostania kierownikiem projektu (ang. Project Manager PM). Rzadko z wyprzedzeniem planujemy ubieganie si o funkcj kierownika projektu PM. Najczciej nie jestemy do tego teoretycznie przygotowani, przez co zarzdzanie projektem nabiera charakteru twrczej intuicyjnej improwizacji. Kady kolejny kierownik projektu dy do jego realizacji, musi samodzielnie, od podstaw, wykreowa wszelkie rozwizania, improwizowa, weryfikowa swoje dziaania metod prb i bdw. Tymczasem sztuka zarzdzania projektami, ktra znacznie rozwina si w cigu ostatnich pitnastu lat, stanowi dzi cis, profesjonaln dyscyplin. Skada si na ni wiedza teoretyczna, konkretny zestaw umiejtnoci i kompetencji, a take proces certyfikacji przeprowadzany przez np. Project Management Institute (PMI) z siedzib w Waszyngtonie orodek badawczy zgbiajcy arkana tej dziedziny. Profesjonalizm w zarzdzaniu projektami ma nie tylko pozytywne odzwierciedlenie w stylu dziaania organizacji, ale take wpywa na podniesienie motywacji i satysfakcji z pracy osb odpowiedzialnych za projekty. Warto pamita, e wiedza w tej dziedzinie rozwija si bardzo dynamicznie i tylko stae podnoszenie kompetencji oparte na dowiadczeniu przodujcych w zarzdzaniu projektami instytutw naukowych i stowarzysze branowych gwarantuje przewag konkurencyjn ich adeptom. Wiedza na temat zarzdzania projektami nie powinna by zarezerwowana jedynie dla najwyszego kierownictwa, odpowiedzialnego za caoksztat organizacji. Tej grupie jest ona bezsprzecznie potrzebna do realizacji celw strategicznych, podejmowania trudnych decyzji i alokowania zasobw w sposb sprzyjajcy realizacji projektw. Jednak bez odpowiedniego przygotowania zespow projektowych nie ma gwarancji, e zadania przydzielane im w poszczeglnych etapach projektw zostan prawidowo zrealizowane. Wszyscy czonkowie organizacji potrzebuj wiedzy i umiejtnoci w zakresie zarzdzania projektami jedni bardziej pogbionej i rozbudowanej, inni mniej szczegowej. Mimo e ci z nas, ktrzy cho raz zarzdzali projektem lubi nazywa siebie Project Managerami, coraz czciej licz si formalne, powiadczone certyfikatem uprawnienia do tego tytuu. Dyplomy wydawane przez MT&DC, przy wsppracy z Educational Services Institute International (ESI), potwierdzaj uzyskanie przez uczestnika kursu gruntownego wyksztacenia i nabycia kompetencji

Wprowadzenie

7

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

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

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 koncepcjami by zachwycony car Mikoaj I, od ktrego otrzyma propozycj osiedlenia si w Rosji wraz z 2 mln angielskich robotnikw. Mimo e nie znalaz naladowcw wrd sobie wspczesnych, jego idee zostay pniej rozwinite w behawioralnym podejciu do zarzdzania. Charles Babbage (17921871), angielski matematyk, pionier informatyki, profesor uniwersytetu Cambridge (18281839), koncentrowa uwag na efektywnoci produkcji. Babbage wiza wielkie nadzieje z podziaem pracy i by ordownikiem zastosowania matematyki do takich problemw, jak efektywne wykorzystanie maszyn, pomieszcze i materiaw. W tym sensie jego praca wyprzedzia zarwno klasyczne, jak i ilociowe spojrzenie na zarzdzanie. Babbage dostrzega jednak rwnie czowieka. Rozumia korzyci pynce z wspdziaania pracodawcy i robotnikw, i rozumia korzyci pynce ze wspudziau w zyskach tych ostatnich. Wspczeni prekursorzy naukowego zarzdzania to midzy innymi Federic W. Taylor (18651915), Frank Gilbreth (18681924), Henry Gantt (186119190 czy Harrington Emerson (18531931). Pionierem w dziedzinie wydajnoci pracy by niewtpliwie Taylor, ktry wprowadzi liczne innowacje w sposobie projektowania stanowiska pracy, szkolenia pracownikw, ktrzy mieli prac wykonywa i uzyskiwa wysz jako produkowanych wyrobw.

Prekursorzy zarzdzaniaWspczenie zarzdzanie kojarzy nam si przede wszystkim z duymi przedsibiorstwami, korporacjami, organizacjami, ktre s kierowane przez zarzdy, prezesw, rady nadzorcze. Zanim do tego doszlimy, na przestrzeni wielu stuleci yy narody i ich wybitni przedstawiciele, ktrzy stworzyli podwaliny naszej cywilizacji. Sumerowie znani s z metod zarzdzania opartych na spisanych przepisach, Egipcjanie stworzyli reguy i praktyki w budowie piramid, Babiloczycy zaczli stosowa szeroki zestaw aktw prawnych i rodkw politycznych w zarzdzaniu, Grecy specjalizowali si w rnych systemach zarzdzania miastami i pastwami, Rzymianie uywali struktury organizacyjnej w celu komunikacji i kontroli, Chiczycy wprowadzili rozleg struktur organizacyjn dla agencji rzdowych oraz w dziedzinie sztuki, Wenecjanie zastosowali projektowanie organizacji i planowanie do osigni-

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


11

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

12


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


13

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

14


1.3. Czynniki charakterystyczne projektuJak ju wczeniej wspomniano, projekt informatyczny charakteryzuje si innowacyjnoci, zakresem, ryzykiem, zapotrzebowaniem na zasoby ludzkie i materialne oraz niezbdnym czasem na realizacj. Wykonawca projektu-realizator (firma, zesp), przystpujc do jego wykonania, najczciej zmienia swj dotychczasowy model pracy (cho dobry do realizacji codziennych zada), ze wzgldu na cel projektu [14, 24, 46, 50]. Jednym z gwnych bdw jest niedocenienie zoonoci i wpywu na projekt kontekstu organizacyjnego firm zaangaowanych w jego realizacj i niezrozumienie celu. Gwne czynniki, ktre charakteryzuj projekt: dziaania nastawione na dokonanie zmian, ocena moliwych zyskw i strat, zakres, strategia, ewolucja modelu prac w wyniku dowiadczenia, wykorzystanie bazy wiedzy do tworzenia nowych jakoci, cel (biznesowy, organizacyjny, jakociowy, inny), misja (przesanie), oryginalno, dziaanie niepowtarzalne, dotyczy elementw rozwoju, ma cechy ewolucji, dziaanie nastawione na nowatorsk obsug procesw biznesowych zwizanych z produktem dla okrelonego podmiotu, dla ktrego jest realizowany projekt, metoda racjonalnego dziaania jako czynnik sprawczy inicjacji projektw, inne czynniki w zalenoci od charakteru projektu. S to wspczesne wyznaczniki zwizane z projektem, ale czy jest to uniwersalna recepta na generowanie projektw? W XIX wielu C. Bernard, francuski patolog zdefiniowa czynniki, ktre sprzyjaj powstawaniu rzeczy nowych projektw. Wedug autora nale do nich: wyrane ustalenie celu dziaania, ustalenie szczegowo wszystkich kierunkw dziaa i rodkw, za pomoc ktrych mona osign zaoony cel, uoenie dokadnego planu dziaania, zmierzajcego do osignicia celu przy zastosowaniu najlepszych w obecnych warunkach rodkw, wykonanie skrupulatnie zaoonego planu, skontrolowanie osignitych wynikw i porwnanie z zamierzonym celem wycignicie wnioskw na przyszo (do nastpnego planu projektu). Mona zatem wnioskowa, e wymienione elementy racjonalnego dziaania byy podstaw wspczesnego pojmowania realizacji projektw.


15

1.4. ProcesProces jest to cile zdefiniowany cig dziaa nastawionych na ustabilizowanie i optymalizacj stanowicych podstaw technologii wytwarzania wielu identycznych lub podobnych produktw o okrelonych parametrach uytkowych lub wiadczonych usugach. Przez technologi naley rozumie przetwarzanie w sposb celowy i ekonomiczny z zastosowaniem nowej techniki [31, 48]. Projekt a proces czynniki rnicujce Waciwoci projektw jest ukierunkowanie na zmiany [7, 21]. Wprowadzenie nowoci, zmiana stanu obecnego jest podstawow cech kadego projektu [39]. Projektem jest na przykad zbudowanie nowego poczenia kolejowego midzy miejscowoci A i B, wprowadzenie nowej usugi dostarczania poczty (listy, paczki) lub zmiana organizacji pracy (cz pracownikw dostaje komputery do domu i przez Internet przekazuje rezultaty pracy). Projekty s najczciej realizacj wytworw ludzkiej wyobrani, ktra praktycznie adaptuje zdobycze nauki i przez przemylane dziaanie tworzy now jako. Powtarzalne wykonywanie czynnoci, ktre s realizowane wedug okrelonej technologii, a ich rezultatem jest jasno zdefiniowany produkt, to typowe dziaania procesowe, jak np. produkcja kolejnego z serii motocykla, roweru, krzesa, pyty CD; wykonanie usugi, np. zdjcie RTG, sprzeda TV przez kasjera, przelew bankowy i tym podobne czynnoci, ktre maja charakter powtarzalny i s realizowane wedug opracowanych zasad (na podstawie wczeniej zrealizowanych projektw). Sytuacje rutynowe, powtarzajce si z du czstotliwoci (do czasu wprowadzenia zmiany przez projekt) w jednostce czasu oraz przez dowolnie dugi okres, to procesy [20, 48]. Na rynku mamy do czynienia z podmiotami gospodarczymi, ktrych cech szczegln jest realizacja procesw lub projektw. Prowadzenie dziaalnoci procesowej powinno by zdefiniowane i zweryfikowane w wielu konkretnych typowych realizacjach. Zespoy wykonawcw dysponuj opisanym cigiem dziaa stanowicym elementy w realizacji caego procesu. Zidentyfikowane s rwnie problemy zarzdzania zespoem realizujcym proces i algorytmy wspdziaania, komunikacji, kompetencji oraz funkcji z podziaem zakresu prac czonkw zespou. Projekt kreuje specyficzne, niepowtarzalne podejcie, adekwatne do osignicia celu projektu, przez opracowanie procedur zarzdzania i realizacji, ktre tworz proces realizacji. Czas, zarwno opracowywania procesw, jak i projektw, jest czynnikiem wymuszajcym ich modyfikacje. Obserwujemy zamiany w technologii, powstaj nowe urzdzenia, materiay, rodzaje energii, dowiadczenia i obserwacje z realizacji stosowanych procesw itp., co najczciej skutkuje potrzeb ich wprowadzenia do funkcjonujcych procesw podyktowan wzgldami ekonomicznymi sprostaniu konkuren-

16


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


17

jekty.

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

18


3. Jak duo czasu powici na planowanie? 4. Skd czerpa dane? Mwi si, e planowanie zabiera co najmniej 10% czasu, ale czasem dochodzi nawet do 90%.

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

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 rodzaje problemw, jakie moemy napotka oraz rozwizania, jakie mona zastosowa. Wiedzc o ograniczeniach lub dopuszczalnej elastycznoci, mona atwiej planowa projekt i nim zarzdza. Naley rwnie podkreli, e duy wpyw na planowanie projektu informatycznego ma tzw. pula zasobw projektw (patrz, co to jest pula zasobw p. 2.3). Plan jest najczciej projekcj wyobrani przyszego kierownika projektu co do sposobu osignicia celu.

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

20


2.3. Zasoby projektuW rozdziale tym przyjto nomenklatur i sposb zarzdzania zasobami zaimplementowanymi w programie MS Projekt 2000. We wspczesnych firmach informatycznych jest rzadkoci przydzielenie osoby do jednego projektu od jego rozpoczcia a do zakoczenia, bez nakadania na ni dodatkowych, wykraczajcych poza jeden projekt, zobowiza. Wspuytkowanie zasobw midzy projektami pozwala na wiksz elastyczno i kontrol w zarzdzaniu zasobami. Wspuytkowanie zasobw naley rozway, jeeli speniony jest ktry z podanych warunkw: 1. Nakadanie si projektw. Moe si zdarzy, e konieczne bdzie rozpoczcie nowego projektu przed zakoczeniem projektu wykonywanego aktualnie. W razie potrzeby dzielenia czasu midzy projektami, wspuytkowanie zasobw midzy plikami tych projektw moe pomc w zapobieeniu nadmiernej alokacji zasobw. Chcc przenie dane zasobw, takie jak stawki kosztw, z dotychczasowego projektu do nowego projektu, mona utworzy pul zasobw, aby zawrze w niej zasoby oraz informacje o nich dla obu plikw. Utworzenie puli zasobw i nastpujce po nim przeniesienie informacji o zasobach uatwi przenoszenie danych ze starego do nowego pliku projektu. 2. Organizowanie zasobw w obszary funkcjonalne. Jeeli trzeba przydzieli zasoby, ktre pracuj nad wieloma projektami w ramach procesu zarzdzania, na przykad rewidentw i ksigowych, uzasadnione jest utworzenie dla nich puli zasobw. Nastpnie meneder grupy funkcjonalnej moe zbilansowa ich obcienie prac i zastpi lub ponownie przydzieli zasoby, aby zachowa zgodno z harmonogramem. Jeeli nie ma znaczenia, ktry zasb wykonuje dane zadanie, pula zasobw moe by zarzdzana poza zakresem projektu, w celu zapewnienia optymalnej efektywnoci harmonogramu pracy zasobw. Jeeli natomiast naley zachowa kontrol nad tym, kto wykonuje jakie zadania, mona skonfigurowa proces zmian przydziaw zasobw, ktry umoliwi zatwierdzanie przydziaw zasobw przed dokonaniem zmian przydziaw w pliku projektu. 3. Przewidywanie obcienia prac w wielu projektach. Wykorzystanie puli zasobw moe by bardzo wydajne w przewidywaniu obcienia prac osb, ktrych zadania maj podobne opisy. Mona przydzieli zasoby o nazwach oglnych, jak choby Architekt I i Architekt II odpowiednio dla modszych i starszych czonkw personelu, lub oznaczy rne poziomy dowiadczenia zawodowego niezbdne w realizacji zadania. Po przypisaniu zadaniom w kadym zbliajcym si projekcie odpowiednich opisw prac, mona wspuytkowa zasoby za pomoc nowej puli zasobw i mona zobaczy cakowit prac, przydzielon do kadego opisu prac. Warto nadmiernej alokacji kadego z opisw prac stanowi informacj, jak wiele okrelonych zasobw potrzeba do wykonania pracy nad projektami zgodnie z biecymi harmonogramami projektw. Na


21

przykad nadmierna alokacja na poziomie 300% dla Architekta I oznacza, e do wykonania pracy potrzeba trzech modszych architektw. Nastpnie, po ucileniu listy zasobw projektu, mona wprowadzi konkretne nazwy do kadego opisu prac i ponownie przydzieli prac rzeczywistym osobom, ktr j wykonaj. Co to jest pula zasobw Pula zasobw umoliwia wspuytkowanie zasobw przez wiele projektw. Uywanie puli zasobw umoliwia sporzdzanie harmonogramw dla zasobw pracy we wszystkich projektach, identyfikacj konfliktw midzy przydziaami w rnych projektach i monitorowanie, wykorzystywania czasu zasobu w wielu projektach. Jeeli informacje o ludziach lub sprzcie pracujcym nad zadaniami znajduj si w wielu plikach projektw, mona uy puli zasobw do centralizacji informacji o zasobach, takich jak nazwa zasobu, uywany kalendarz, jednostki zasobu i tabele stawek kosztw, co uatwi zarzdzanie projektem. Kady projekt, ktry uywa zasobw z puli zasobw, jest nazywany plikiem wspuytkujcym. Jako puli zasobw mona uywa dowolnego, istniejcego pliku projektu, ale zaleca si utworzenie nowego pliku projektu tylko na informacje o zasobach, by jak najbardziej uatwi zarzdzanie informacjami o zasobach i przydziaami zada midzy plikami wspuytkujcymi a pul zasobw.

2.4. Definiowanie ogranicze w projekcieOgraniczeniami w projekcie s czynniki, ktre maj podstawowy wpyw na opcje dziaa kierownika projektu. Typowe trzy gwne ograniczenia to: Harmonogram ograniczenia, takie jak staa data zakoczenia lub termin ostateczny w przypadku gwnych punktw kontrolnych. Zasoby (materia, wyposaenie, sprzt i ludzie oraz skojarzone z nimi koszty) ograniczenie, takie jak uprzednio zdefiniowany budet. Zakres ograniczenie, takie jak zakadana funkcjonalno, technologia, produkty itp. Zmiana jednego z wymienionych ogranicze zwykle wpywa na dwa pozostae, a take na jako projektu. Na przykad zmniejszenie czasu trwania projektu (harmonogram) moe zwikszy liczb pracownikw potrzebnych do realizacji planu (zasoby) oraz zmniejszy liczb waciwoci cechujcych produkt (zakres). Meneder projektu musi okreli, czy mona zaakceptowa tak degradacj. Taki zwizek jest nazywany potrjnym ograniczeniem zarzdzania projektem lub trjktem ogranicze projektu. Podczas procesu planowania naley sporzdzi list ogranicze projektu, aby upewni si, e wszyscy wykonawcy projektu zostali o niej powiadomieni i mog

22


si do niej odnie. Waciwym dla wykonawcw jest take uzgodnienie sposobu ich reakcji na niespodziewane ograniczenia, ktre mog ujawni si w czasie trwania projektu. Na przykad, jeeli koszty pracy oka si wysze od przewidywanych, to wykonawcy mog zada zmniejszenia zakresu projektu. Gwne czynniki, ktre rwnie naley uwzgldni w planowaniu projektu: pienidze/budet, jakim dysponujemy, czas, w ktrym projekt naley zrealizowa, ludzie/nakad pracy, jaki wymaga realizacja projektu, miejsce, w ktrym projekt bdzie realizowany. wyposaenie/warunki pracy oraz rodki techniczne i narzdzia, ktrymi dysponujemy, komunikacja/lokalizacja zespou, poczta, telefon, videokonferencje itp., logistyka, wyksztacenie czonkw zespou, kompetencje posiadane, wiedza (praktyczna i teoretyczna), zdolnoci, umiejtnoci, outsourcing niektrych prac, zada, zasobw. Poniewa przy realizacji projektw informatycznych cz czynnikw jest stosunkowo atwo mierzalna i porwnywalna, jak pienidze, czas, wyposaenie stanowiska pracy czy warunki pracy, tzw. standardy, wic o sukcesie projektu mog zdecydowa pozostae czynniki, ktre wymagaj wikszego dowiadczenia i uwagi. Etapy i czynnoci przygotowawcze zwizane z planowaniem projektu: Studium wykonalnoci projektu (SWP) stwierdza, czy dany projekt przy danych zasobach ma szanse wykonania (zakoczenia si sukcesem). Inicjowanie projektu (IP) zbir czynnoci, ktre naley podj przed formalnym uruchomieniem cyklu prac nad projektem: opis rozwizania technicznego, opis (wstpny plan) projektu (ang. Business Case), ustanowienie projektu. Dziaania w obrbie inicjacji projektu zale od punktu jego startu [11, 22, 26, 29]. Rozpoczynajc prace nad SWP, zmierzamy do IP, ale zanim to ewentualnie nastpi, naley wykona prace przez wyspecjalizowane zespoy, ktre przedkadaj dokumenty wymagane w danej firmie. Przykadowy schemat postpowania podano na rys. 2.2. Opis projektu Opis projektu moe by wykonywany wedug rnych, wczeniej przygotowanych formularzy, wzorcw. Ich posta jest zalena od dowiadczenia i obowizujcych

2. Planowanie projektu informatycznego STUDIUM STUDIUM WYKONALNOCI CI PROJEKTU PROJEKTUWYKONALNO-

23

Przegld opisu projektu Opis projektu

Wybr strategii prowadzenia projektu Strategia

Identyfikacja kategorii ryzyka Ocena ryzyka

Identyfikacja i dobr zadaZadania

Oszacowanie zada Oszacowanie zada Harmonogramowanie

INICJOWANIE INICJOWANIE PROJEKTU PROJEKTU

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

norm, zarzdze czy ustale zwizanych z realizacj projektu przez dany podmiot. Przytoczono najczciej spotykan specyfikacj zawartoci opisu projektu: opis celw projektu, okrelenie zakresu, oglna charakterystyka, jego otoczenie i umiejscowienie (fizyczne), okrelenie granic projektu i punktw kontrolnych, ogranicze i zaoe, zalenoci od innych projektw i powizania z nimi, okrelenie strategii budowy (wydania, wersje, podprojekty patrz dalej), oszacowanie ryzyka projektu, podzia prac i oszacowanie nakadw (w cyklu budowy i dziaania), wstpny harmonogramu projektu,

24


preliminarz kosztw, okrelenie struktury uczestnikw projektu (klienta, zespou projektowego, innych), okrelenie wymaganych metryk jakoci produktu, rozwizania prawne, ustanowienie i rozpoczcie projektu, mierniki sukcesu projektu. Analiza opisu projektu Jedna z gwnych przyczyn poraek projektw to niewaciwa identyfikacja i brak zgodnoci celw midzy wykonawc a klientem (patrz rozdz. 9) [52, 56]. Dlatego analiza opisu projektu powinna dotyczy obydwu stron przedsiwzicia i uwzgldnia potrzeb uzyskania odpowiedzi na pytania: Czy cele projektu jasno odzwierciedlaj potrzeby klienta? Czy projekt ma zdefiniowane produkty kocowe? Czy s sprecyzowane mierniki sukcesu? Czy cele projektu s perspektywiczne i osigalne? Czy cele nie s wzajemnie sprzeczne (czy moliwy jest kompromis)? Czy cele wyznaczaj w przyblieniu przedzia czasu dla ich osignicia ? Czy cele s zgodne z oczekiwaniami klienta i czy gwne kierownictwo klienta jest zaangaowane w dziaania dla ich osignicia? Czy cele zostay uzgodnione ze sponsorem projektu? Szczeglnie istotne jest uwiadomienie zespoowi realizujcemu projekt, e kluczow spraw jest pamitanie o zdefiniowanych i uzgodnionych celach projektu oraz prowadzenie okresowej weryfikacji ich zrozumienia przez poszczeglnych wykonawcw.

2.5. Strategia realizacji projektuWybr strategii rozwoju projektu jest poprzedzony analiz wielkoci projektu, horyzontu czasowego jego realizacji, poziomem dopuszczalnego ryzyka i innymi czynnikami. Wyrnia si kilka strategii, ktre maj swoje nazwy: fazowa, monolityczna sekwencja kolejno wykonywanych faz, dobra dla projektw o niskim poziomie ryzyka, wydania, wersje wytwarzane s fragmenty (podsystemy, komponenty), inkrementalne podsystemy mog powstawa w sekwencji lub rwnolegle, ich oddzielne wytwarzanie zmniejsza ryzyko ich uruchomienia szybkiej cieki, prototypowania wytwarzany jest prototyp, nastpnie wyko-


25

nywana jest jego ocena, po ktrej wytwarzany jest system, zalecana przy wysokim ryzyku, mieszana fragmenty (podprojekty) powstaj wedug rnych strategii, szczeglnie przydatna dla duych projektw obarczonych duym ryzykiemTabela 2.1. Wybr strategii realizacji projektu w zalenoci od rozmiaru projektu i oceny ryzyka Rozmiar projektu < 3 mies. Ocena ryzyka niskie rednie wysokie niskie rednie wysokie niskie rednie wysokie Strategia fazowa wydania prototypowanie fazowa lub wydania wydania wydania lub prototypowanie wydania wydania mieszana lub prototypowanie

3-6 mies.

> 6 mies.

Kada strategia realizacji projektu powinna uwzgldnia pryncypia w zakresie zarzdzania, takie jak: zarzdzanie wymaganiami zapewnienie jednoznacznego, obiektywnego okrelania cech tworzonego rozwizania oraz zapewnienie weryfikacji zgodnoci docelowego produktu z wymaganiami, kontrol przebiegu projektu moliwo biecego ledzenia faktycznego postpu prac i wczesne wykrywanie zagroe dla harmonogramu, budetu i jakoci tworzonego systemu, kontrol kosztw utrzymania moliwo realistycznego przewidywania kosztw przyszych modyfikacji wdroonego systemu.

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

26


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

2.7. Struktura projektu dekompozycja projektu na zadania WBSW kadym projekcie PM dekomponuje cay projekt na WBS (ang. Work Breakdown Structure) do poziomu zadania (ang. task), ktre definiuj czynnoci, jakie naley zrealizowa w celu wyprodukowania okrelonego produktu, usugi, dokumentacji itp. w zalenoci od tego do czego ma suy realizacja zdefiniowanego zadania. Zadanie moe si dzieli na czynnoci. Przyjmuje si, e zadanie powinno by przypisane w realizacji dla pojedynczej osoby i czas jego trwania od 1 do kilku dni, ponadto na by mierzalny i da si skontrolowa co do wykonania oraz jakoci. Definicja struktury WBS Gwnym zadaniem kierownika projektu jest waciwe okrelenie elementw skadowych prac, ktre naley zrealizowa w projekcie. Struktura WBS reprezentuje prac nad wytworzeniem indywidualnych komponentw i prac nad integracj


27

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

28


komponentw WBS. Kady element WBS jest unikatowy. Na poziomie zerowym znajduje si jeden komponent nazwa projektu o numerze 1.0, na poziomie pierwszym znajduj si elementy numerowane od 1.1 do 1n, gdzie n jest liczb faz, na poziomie drugim znajduj si skadowe poszczeglnych faz, np. 1.1.1 do 1.1x, gdzie x liczba komponentw skadowych pierwszej fazy, 1.2.1 do 1.2y, gdzie y liczba komponentw drugiej fazy. WBS strukturalny tworzymy w celu przedstawienia organizacji zaangaowanej w realizacj projektu. Naley uwzgldni takie elementy wspdziaania, ktre wynikaj z umowy na tworzenie produktw oraz relacji z wykonawcami, ktra ma zabezpieczy wykonanie projektu. Etapy tworzenia WBS produktowego 1. Pierwszy poziom tworzymy z produktw, co do ktrych jestemy zobowizani w umowie z klientem. Fazy w WBS produktowym s produktami. Produkty te s wyszczeglnione w umowie, dokumentacji, specyfikacji projektu. Ich nazwy powinny by par rzeczownikw lub rzeczownika z przymiotnikiem, np. Specyfikacja, Specyfikacja projektu. 2. Dla kadego produktu na najwyszym poziomie naley dokona dekompozycji do czci skadowych. Kada cz skadowa staje si komponentem czci WBS. WBS powinien by tak tworzony, aby osoba postronna moga zrozumie cele wykonania zadania zwizanego z danym produktem. Podzia produktu na wyszym poziomie na produkty na niszym poziomie musi mie sens. Kady z produktw na niszym poziomie powinien odrnia si od pozostaych oraz by odrbn czci produktu wyszego poziomu. 3. Kontynuacja dekompozycji powinna trwa do momentu osignicia odpowiedniego poziomu szczegowoci. Zadania na najniszym poziomie aktywnoci powinny spenia nastpujce warunki: powinny by moliwe do wykonania od jednego do dziesiciu dni, czas ich wykonania nie krtszy od sporzdzenia raportu, dla kadego zadania aktywnoci mona oszacowa koszty i czas oraz przydzieli odpowiednie osoby. Zadania te powinny by nazwane w formie bezokolicznika: np. Tworzenie specyfikacji projektu. 4. W WBS powinny by opisane najwaniejsze czynnoci prowadzce do powstania produktu. W tworzeniu np. oprogramowania gwnymi etapami tworzenia jest system, podsystem i funkcja. Naley tutaj uwzgldni wyniki testw, kompilacj kodu i wymagan dokumentacj. Kady wymagany produkt naley zdekomponowa do czynnoci, ktre s wymagane do jego utworzenia.


29

5. W miar rozwoju WBS moe mie kilka aktywnoci na poziomie drugim, trzecim itd. Jednake naley szczeglnie zwrci uwag, aby liczba aktywnoci zwizana z danym produktem zadaniem nie bya ani za dua, ani za maa. Zaleca si, aby kady produkt zadanie skadao si z 7 +/ 2 aktywnoci. Jeeli jest ich od trzech do piciu, to naley si zastanowi czy nie mona ich doczy do innego produktu zadania. Jeeli jest ich wicej ni dziesi naley sprbowa podzieli dany produkt zadanie (zwizane z tymi aktywnociami) na mniejsze produkty. Jednake s to tylko zalecenia, jeli do konkretnego WBS trudno jest zastosowa powysze wskazwki, naley je zaniecha. Struktura WBS powinna by logiczna, tzn. produkty skadowe znajdujce si w WBS powinny tworzy produkt na wyszym poziomie oraz powinny by znaczco rne, nie pokrywa si. 6. Sprawdzenie poprawnoci WBS rozpoczyna si od przechodzenia z najniszego poziomu do najwyszego, inaczej od dou do gry od lici do korzenia. Przechodzc z niszego poziomu do wyszego, naley sumowa produkty (aktywnoci lub zadania) i sprawdza czy tworz one produkt na wyszym poziomie. W ten sposb sprawdzamy czy WBS jest kompletny, czy czego w nim nie brakuje. Jeeli okae si, e s jakie luki w danym WBS, to naley go uzupeni. 7. Ostatni etap to sprawdzenie zgodnoci powstaego WBS z celami projektu, czy przez utworzone produkty mona zrealizowa cele projektu [8]. Etapy tworzenia WBS fazowego: 1. Na poziomie pierwszym znajduj si fazy cyklu oprogramowania. 2. Nastpnie naley zidentyfikowa produkty, co do ktrych jestemy zobowizani w umowie z klientem. Produkty te umiejscawiamy pod odpowiedni faz. 3. Dane produkty dekomponujemy podobnie jak w WBS produktowym. Etapy tworzenia WBS strukturalnego: 1. Na pierwszym poziomie znajduje si firma klienta oraz firmy, ktre deklaruj si do wykonania projektu. 2. Drugi poziom odzwierciedla zawarcie umowy. Poczenie firmy klienta z konkretnym wykonawc. Tworzona jest organizacja, ktra zajmuje si realizacj projektu. 3. Dla danej organizacji wykonujcej projekt jest tworzona struktura podziau pracy wedug WBS produktowego lub WBS fazowego. Inne struktury podziau pracy Struktura podziau pracy kontraktowa (Contractual WBS CWBS) Jest tworzona w celu przedstawienia klientowi. Wykonawca projektu uywa kontraktowej struktury podziau pracy do zdefiniowania raportw, jakie bdzie przedstawia klientowi po zakoczeniu realizacji prac wyspecyfikowanych w kontrakcie.

30


CWBS zawiera wicej szczegw zwizanych z zarzdzaniem prac nad projektem, po zakoczeniu ktrej nastpuj zobowizania stron projektu. Struktura ta jest pomocna w egzekwowaniu terminw patnoci przez klienta za projekt. Struktura podziau pracy organizacyjna (Organizational Breakdown Structure OBS) Przedstawia struktur organizacji realizujcej projekt. Pokazuje, ktre elementy pracy s przydzielone, do ktrych jednostek organizacji. Taka struktura jest stosowana w przypadku rozproszonych zespow lub ma specyficzn wiedz dziedzinow. Zasoby (Resource Breakdown Structure RBS) Odmiana organizacyjnej struktury podziau pracy. Jest uywana, kiedy zadania s przydzielone konkretnym osobom. Koszty (Bill of Materials) Prezentuje hierarchiczn struktur zada, podzada, komponentw potrzebnych do wyprodukowania produktu. Projektowa struktura (Project Breakdown Structure PBS) Projektowa struktura podziau pracy jest wykorzystywana w aplikacjach, gdzie pojcie struktury WBS jest niepoprawne w powizaniu ze struktur zasobw (RBS) [2].POZIOM 1PROJEKT

POZIOM 2

Studium Moliwoci realizacji/badanie

Inicjacja

Specyfikacja systemu

Projektowanie

Eksploatacja

definiowanie celu bad. potrzeb uytkownika przegld rozwiza alternatywnych

Przygotowanie planu i budetu Analiza wymaga Org. zespou realizacyjnego

POZIOM 3

Rys. 2.3. Przykad WBS fazowego, prace poziomu 3 mona dzieli na dziaania (czynnoci) (ang. activities)

Aby praktycznie zilustrowa etapy, jak rwnie sposb tworzenia diagramw WBS, moemy korzysta z opisu faz wedug Coopers & Lybrand (tabela 2.2), gdzie jest kolumna z typowymi fazami projektu, kolumna opisujca zesp czynnoci, ktre realizujemy w ramach fazy oraz kolumna produktw kocowych, ktre powinny powsta na zakoczenie danej fazy. Tak rozpisany projekt umoliwia atwe tworzenie zarwno WBS produktowego, jak rwnie fazowego (rys. 2.3). Dla penego udokumentowania wszystkich produktw moemy zdefiniowa POZIOM 4, na ktrym wyspecyfikujemy wytworzone w projekcie np. dokumentacje, oprogramowanie, instrukcje, zainstalowany sprzt, uruchomione oprogramowanie itd.

2. Planowanie projektu informatycznego Tabela 2.2. WBS: Standardowe fazy cyklu ycia projektu (wedug Coopers & Lybrand) Faza Studium moliwoci realizacji/badanie Inicjacja Czynnoci Zdefiniuj problem. Zbadaj wymagania uytkownika. Oce rozwizania alternatywne. Zale kierunek dziaania. Przygotuj plan i budet. Przygotuj opis dziaalnoci firmy. Produkt kocowy Sprawozdanie studialne

31

Specyfikowanie

Projektowanie

Realizacja

Instalowanie

Eksploatacja

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

2.8. Szacowania w projekciePolicz to co mona policzy, zmierz to co mona zmierzy, a to co niemierzalne uczy mierzalnym. Galileo Galilei Wymiarowanie systemw informatycznych, w tym szacowanie poszczeglnych elementw projektu, takich jak czas realizacji, pracochonno, koszty, wydajno, zuycie materiaw i inne, s przedsiwziciem zoonym. Szczeglnym przedmiotem szacowania jest ta cze projektu informatycznego, ktra dotyczy oprogramowania. W przypadku takich nauk, jak fizyka, elektronika, ekonomia sprawa jest do oczywista i uwaga badaczy skoncentrowana jest wok jednostki miary i metody powtarzalnoci pomiaru.

32

Zarzdzanie projektem informatycznym Tabela 2.3. Fazy cyklu ycia projektu obiektowego dostosowane na potrzeby projektu grupowego

Faza Planowanie wstpne (zaoenia) Studium wykonalnoci Planowanie projektu (ang. Preliminary project plan)

Specyfikacja wymaga systemowych

Czynnoci Poznanie celw, odpowiedzialnoci i harmonogramu. Analiza problemu. Okrelenie osb penicych rol klientw Identyfikacja podstawowych wymaga. Analiza wykonalnoci. Przygotowanie raportu wykonalnoci. Organizacja grupy, przypisanie rl. Okrelenie planu dziaa, oczekiwanych produktw, zasobw, przydziau prac. Okrelenie ryzyka, okrelenie strategii. Przyjcie planu kontroli jakoci. Opracowanie harmonogramu. Przygotowanie wymaganych raportw. Identyfikacja wymaga w oparciu o analiz dokumentw, wywiady, pytania, etc. Specyfikacja wymaga. Weryfikacja i akceptacja. Dziaania zmierzajce do zapewnienia jakoci. Przygotowanie wymaganych raportw. Analiza wymaga. Modelowanie i specyfikacja. Ucilenie sownika danych. Weryfikacja i akceptacja. Dziaania zmierzajce do zapewnienia jakoci. Ucilenie zaoe projektowych i implementacyjnych. Przygotowanie wymaganych raportw i dokumentacji.

Produkty Powizanie grupy z tematem projektu

Raport wykonalnoci Raporty spotka Plan projektu. Zaoenia strategii minimalizacji ryzyka. Plan nadzoru jakoci. Szczegowy plan fazy nastpnej. Raport przebiegu prac (w tym spotka)

Specyfikacja wymaga na oprogramowanie (modelowanie)

Projektowanie systemu

Modelowanie i specyfikacja. Ucilenie sownika danych. Dziaania zmierzajce do zapewnienia jakoci. Ucilenie zaoe projektowych i implementacyjnych. Przygotowanie wymaganych raportw i dokumentacji. Projektowanie Projektowanie klas. Ucilenie sownika klas danych. Dziaania zmierzajce do zapewnienia jakoci. Ucilenie zaoe implementacyjnych. Przygotowanie wymaganych raportw. Implementacja, Implementacja obiektw. Testowanie. Uzupenienie sownika danych. Dziaania zmieintegracja rzajce do zapewnienia jakoci. Przygotowai testowanie nie wymaganych raportw i dokumentacji.

Dokument specyfikacji wymaga uytkowych. Plan (projekt) testw akceptacyjnych. Sownik danych (wstpny). Szczegowy plan fazy nastpnej. Raport zmian. Raport przebiegu prac (w tym take spotka i dziaa projakociowych) Modele systemu: Model klas Model funkcjonalny Model dynamiczny Sownik danych Projekt testowania funkcjonalnego. Podrcznik uytkownika (szkic). Szczegowy plan fazy nastpnej. Raport zmian. Raport przebiegu prac Dokumentacja projektu systemu. Sownik danych. Projekt testowania integracyjnego. Szczegowy plan fazy nastpnej. Raport zmian. Raport przebiegu prac Dokumentacja projektu klas. Sownik danych. Projekt testowania obiektw. Szczegowy plan fazy nastpnej. Raport zmian. Raport przebiegu prac Oprogramowanie projektu. Sownik danych. Raport testowania obiektowego, integracyjnego, funkcjonalnego. Dokumentacja (szkic). Szczegowy plan fazy nastpnej. Raport zmian. Raport przebiegu prac Raport testowania akceptacyjnego. Dokumentacja (szkic). Raport finalny

Finalizacja

Dyskusja testw akceptacyjnych. Dokumentowanie. Raport.


33

W przypadku informatyki problem dotyczy zoonoci oprogramowania, czyli na og relacji, jakie wystpuj midzy dwoma, trzema programami, ktry jest bardziej zoony, trudniejszy w pielgnacji, implementacji algorytmw, testowaniu, wdroeniu itd. Szacowanie zada zwizanych z implementacj oprogramowania jest zagadnieniem trudnym, wymagajcym wspdziaania kierownika projektu z zespoami przewidzianymi do realizacji projektu, dostpu do informacji na temat podobnych przedsiwzi lub jego fragmentw, aby mona si posuy np. technik analogii zamiast regu palca i sufitu. Podstaw prac nad szacowaniem zada jest opracowanie w miar dokadnej struktury projektu, ktr naley dekomponowa do zada, ktre realizuj pojedynczy wykonawcy lub specjalizowane zespoy w stosunkowo krtkim czasie, np. kilku dni. Wprowadza si tu takie pojcia, jak: nakad pracy (ang. effort) (MM man-months, PM preson-months), czas trwania (ang. duration) (Mo months), obcienie ludzi (ang. manpower loading) liczba wymaganych pracownikw przydzielonych do projektu w funkcji czasu. Dla oszacowania kosztu caego projektu, pojedynczej fazy, aktywnoci, s potrzebne kosztowe informacje [47, 51, 52]: przed startem projektu (dla analizy koszty/zysk, negocjacji kontraktu), podczas realizacji projektu (w celu zarzdzania projektem, planowania, monitorowania i kontroli), musz by aktualizowane w trakcie prowadzenia projektu. Metody szacowania zada Przez szacowanie zada naley rozumie rne obszary mierzenia zada, ktre naley wykona, aby wytworzy oprogramowanie, midzy innymi: prognozowana pracochonno, koszty, niezawodno, zoono, zoono implementacji algorytmw, jako, przenaszalno. Nie ma uniwersalnej metody, ktra by w zadowalajcy sposb okrelaa wszystkie obszary oprogramowania, i to niezalenie od jego charakteru, wielkoci itd. Metoda punktw funkcyjnych (PF) jest stosowana przede wszystkim do szacowania pracochonnoci i jakoci oprogramowania. Modele parametryczne, np. COCOMO [Boehm B. W., Software Engineering Economics, Prentice Hall, 1981,Putnam L. H., A General Empirical Solution to

34


the Macro Software Sizing and Estimating Problem, IEEE Transaction of Software Enginering, SE-4, July 1978] znane jako najlepsze do szacowania kosztw [4]. Miary niezawodnoci oprogramowania opieraj si na okreleniu rednich czasw bezawaryjnej pracy oprogramowania, s to gwnie modele niezawodnociowe. Naley wspomnie o mikrotechnice szacowania zada, faz, Wide-Band Delphi, szacowania cakowitego wysiku przedsibiorstwa oraz przez eksperta lub oprogramowanie. Z innymi technikami szacowania projektw mona si zapozna w pracy Z. Szyjewskiego [47]. W dalszej czci pracy szczegowo omwiono metod PF.

2.9. Metoda punktw funkcyjnychW pnych latach siedemdziesitych IBM potrzebowa wynale metod oceny kosztw rozwoju aplikacji niezalen od jzyka, w ktrym dana aplikacja ma by stworzona. Zleci realizacj takiego projektu jednemu ze swoich pracownikw Allanowi Albrechtowi, ktry w 1979 roku zaprezentowa wyniki swoich prac jako metod punktw funkcyjnych podczas konferencji w Monerey w Kalifornii [Albrecht A.J., Measuring Applications Development Productivity, Procedings of IBM applications Devision Join SHARE/GUIID Symposium, Monterey, CA, 1979], [1, 26]. W pocztkowym okresie pojawio si sporo zarzutw wobec tej metody, ze wzgldu na bardzo ograniczon liczb parametrw wejciowych, ktre wykorzystywano, ale bya rozwijana i w 1984 opublikowano wersj, ktra uwzgldniaa 14 wspczynnikw majcych wpyw na projekt. Ta wersja metody zacza zdobywa coraz wiksz liczb zwolennikw. Punkty funkcyjne (PF) s rozumiane jako miara wielkoci aplikacji komputerowych i projektu, ktre naley stworzy. Jest to miara stworzona gwnie na uytek szacowania wielkoci i kosztw projektu, ktre np. negocjujemy we wstpnej fazie projektu z klientem. Podstaw mierzenia jest planowanie funkcjonalnoci (inaczej specyfikowanie potrzeb uytkownika co do funkcjonalnoci, interfejsu, wielkoci i iloci zbiorw danych itd.). Jest ona niezalena od jzyka programowania, metodologii rozwoju, technologii lub zdolnoci grup projektowych uytych do wytworzenia aplikacji. Fakt i Albrecht po raz pierwszy uy jej do szacowania pracochonnoci (wysiku) jest prost konsekwencj tego, e wielko projektu jest podstawowym czynnikiem wpywajcym na pracochonno projektu. Metoda PF nie jest doskonaym miernikiem pracochonnoci stworzenia aplikacji lub wyceny jej wartoci biznesowej, aczkolwiek wielko projektu podana w punktach funkcyjnych jest wanym czynnikiem w mierzeniu kadej z tych dwu wartoci. Ilustruje to prosta analogia w handlu nieruchomociami. Koszt wybudowania budynku A o powierzchni 100 m2 jest zwykle mniejszy od kosztu wybudowania budynku B o


35

powierzchni 400 m2. Jednake wiele atrybutw, takich jak marmurowe azienki, armatura i podogi moe wpyn na to, i mniejszy dom moe by bardziej kosztowny. Inne czynniki, takie jak lokalizacja i liczba sypialni moe take uczyni mniejszy dom bardziej wartociowym miejscem zamieszkania. Tym samym koszt wybudowania 1 m2 w budynku A i B mog znacznie si rni oraz ich warto rynkowa niekoniecznie musi odzwierciedla poniesione nakady finansowe. Mona nadmieni dlaczego punkty funkcyjne nie mierz wartoci projektu oraz wskaza powody, ktre decyduj, e warto uywa punktw funkcyjnych: 1. Miara produktywnoci wiele wykonawcw projektw doszo do wniosku, e pomimo prowadzenia szerszej dziaalnoci informatycznej znaczn cz angaowanych zasobw bazowych lokuj w produkcj oprogramowania. Policzenie kilku wariantw rozwizania tematu za pomoc punktw funkcyjnych daje im moliwo ocenienia jak dobrze sobie radz w tej dziedzinie. 2. Wspomaganie szacowania rozwoju od pocztku punkty funkcyjne uywane byy jako technika do szacowania. Szacowanie wielkoci projektu jest oczywicie potrzebne do szacowania kosztw aplikacji, co daje nam pojcie o sposobie jej wytwarzania. Nawet dla strategicznych projektw, ktre nie potrzebuj adnej ilociowej oceny, waciwe szacowanie jest potrzebne w celu waciwego przydziau pracownikw. 3. Monitorowanie umw zewntrznych (ang. Outsourcing) firmy zlecajce komu na zewntrz znaczce czci swoich zada oczekuj, e dostawca dostarczy produkt wedug specyfikacji, na odpowiednim poziomie jakoci, oczekuj zatem zwizku z kosztami, ktre maj ponie firmy zewntrzne. Uycie metody PF w celu zademonstrowania zgodnoci swych szacunkw, adekwatn do skali produkcji oprogramowania, jest podstaw negocjowania ceny usugi. 4. Pomoc w decyzjach biznesowych firmy musz analizowa kady pakiet aplikacji w projekcie. Wielko w punktach funkcyjnych jest atrybutem, ktry musi by ledzony dla iloci aplikacji w projekcie. Wraz z innymi danymi pozwoli na decyzje dotyczce ponownego wykorzystania, wycofania lub zmodyfikowania aplikacji. 5. Normalizacja innych miar aby pokaza waciwy sens niektrych danych, naley je porwna z punktami funkcyjnymi. Na przykad: informacje, e aplikacja o rozmiarze 100 punktw funkcyjnych, posiadajca 100 defektw, jest niezbyt dobr wiadomoci. Ta sama ilo dostarczanych defektw dla aplikacji o rozmiarze 10 000 punktw funkcyjnych jest ju znacznie lepszym wskanikiem jakoci oprogramowania. Podstawowe pojcia i wzory stosowane w metodzie PF Granice systemu (ang. System Boundaries) jawnie okrelone granice systemu poddawanego mierzeniu. Naley wyodrbni granic pomidzy projektem lub aplikacj z punktu widzenia uytkownika. ILF (ang. Internal Logical File) wewntrzny plik logiczny grupa danych i rekordw powizanych ze sob i utrzymywanych wewntrz granic sytemu podtrzymywana przez zewntrzne wejcie EI (External Omput).

36


EIF (ang. External Interface File) zewntrzny plik interfejsowy grupa danych i rekordw powizanych ze sob i utrzymywana na zewntrz granic sytemu, ktra jest uywana tylko jako referencje wewntrz systemu. RET (ang. Record Element Type) rekord, zbir powizanych ze sob logicznie danych identyfikowalny przez uytkownika znajdujcy si wewntrz ILF lub EIF. FTR (ang. File Type Referenced) plik, do ktrego odwouj si transakcje. Musi by to ILF lub EIF. DET (ang. Data Element Type) pojedyncza dana identyfikowalna z punktu widzenia uytkownika. Niepowtarzalne pole DET jest informacj, ktra jest zmienn, a nie sta. Zmienne pole jest odczytywane z pliku lub stworzone za pomoc DET-w zawartych w FTR. Dodatkowo DET moe wywoywa transakcje lub moe by dodatkow informacj dotyczc danej transakcji. Jeli DET ma wiele wystpie (jest rekursywny), to tylko jego pierwsze wystpienie powinno by brane pod uwag. IFPUG (International Function Point Group) [26] podaje szczegowe sposoby rozpoznawania i liczenia DET dla systemw z GUI oraz systemw czasu rzeczywistego. EO (ang. External Output) zewntrzne wyjcie proces, w czasie ktrego przetworzona grupa danych przekracza granice systemu z wewntrz na zewntrz systemu. Dodatkowo moe uaktualnia ILF. Dane tworz raporty lub pliki wyjciowe wysyane do innych aplikacji. S one tworzone na podstawie jednego lub wicej ILF oraz EIF. EI (ang. External Inputs) zewntrzne wejcie proces, w czasie ktrego dane przekraczaj granice systemu z zewntrz do wewntrz. Mog one pochodzi z ekranu (klawiatury), przez ktre wprowadzamy dane lub inne aplikacje Dane te mog suy do uaktualnienia jednego lub wicej ILF. Dane te mog by danymi kontrolnymi lub operacyjnymi. Jeli s to dane kontrolne, to nie musz uaktualnia ILF. EQ (ang. External Inquiries) informacje zewntrzne proces, w ktrym dane wychodz poza granice systemu. Nie moe zawiera przetworzonych lub obliczonych danych wewntrz moduu. To ilo danych, ktre otrzymujemy w wyniku zewntrznych zapyta do systemu. Wyrniamy 3 podstawowe typy liczenia : Dla projektu (ang. development), Dla aplikacji (ang. application), Dla aplikacji modyfikowanej (ang. enhancement). Trzeci z wymienionych typw nie rni si zbytnio od drugiego typu. W procesie liczenia dla aplikacji modyfikowanej badamy wpyw dokonanych zmian (zliczamy usunite zmodyfikowane i dodane funkcjonalnoci), korzystajc z bazowej liczby punktw obliczonej dla aplikacji przed zmianami. VAF (ang. Value Adjustment Factor) czynnik modyfikujcy warto punktw funkcyjnych. Ma on za zadanie modyfikacj liczby punktw otrzymanych z bazowego


37

liczenia przez uwzgldnienie wiadomoci o realizowanym projekcie. Uzyskuje si go przez odpowiedzenie na 14 pyta zwizanych z projektem. Odpowiedzi jest ustalenie wanoci podanego wspczynnika dla naszego systemu (w skali 05). Kocow warto otrzymujemy za pomoc wzoru :

14 VAF = 0,65 + Ci 100 i =1

gdzie: Ci 14 wspczynnikw majcych wpyw na projekt. Przedstawiono kroki, ktre naley wykona w celu kalkulacji projektu wedug metody PF, zgodne z podrcznikiem opublikowanymi przez IFPUG [26]: 1. Zaplanuj liczenie. Ten krok obejmuje wybr rodzaju liczenia oraz zdefiniowanie granic liczenia. Obejmuje take bardzo wany krok zwizany z identyfikacj i przydzieleniem eksperta systemowego. 2. Wytumacz proces liczenia. Jeli korzystamy z pomocy eksperta systemowego, bdziemy potrzebowali wytumaczy mu, co zamierzamy robi, po co liczymy, co zamierzamy zrobi z uzyskanymi informacjami i inne podobne sprawy. Nie bdziemy przecie co chwil przerywa liczenia, po to by tumaczy, e uycie punktw funkcyjnych jest konieczne. 3. Policz VAF. IFPUG poleca zrobi to na kocu, lecz w czasie liczenia eksperci czsto narzekaj, e poszczeglne procesy s zbyt sabo ocenione. Mona powiedzie, e VAF wemie to pniej pod uwag i poprawi ich ocen. Podzielenie si wiadomoci o zoonoci systemu utrzymuje osoby zwizane z liczeniem w ciekawoci. 4. Policz typy danych funkcyjnych. Krok ten obejmuje identyfikacj ILF oraz EIF. Zadajc pytania ekspertowi o gwne kategorie danych oraz studiujc model danych, uzyskamy podstaw do ustalenia grup danych powizanych logicznie, co nastpnie uatwi liczenie zoonoci transakcji. 5. Zidentyfikuj transakcje. Obejmuje to identyfikacj EI, EO, EQ. Jest to zwykle najdusza cz. Identyfikacja transakcji oraz ocenianie ich zoonoci na podstawie liczby danych, z ktrych korzysta. 6. Wykonaj obliczenia. Obejmuje zsumowanie punktw oraz przemnoenie otrzymanego wyniku przez VAF 7. Weryfikacja wynikw. Po zakoczeniu procesu liczenia powinno si wyniki przekaza ekspertowi w celu weryfikacji tego, czy jaka funkcjonalno zawarta w systemie nie zostaa pominita. 8. Pokazanie wynikw. Jednym z podstawowych powodw niepowodze przygotowywanych metryk projektw jest to, i klient musi zbyt dugo czeka na wyniki oblicze. W dzie lub dwa po zakoczeniu liczenia wyniki powinny by przedstawione pracownikom biorcym udzia w projekcie oraz sponsorom.

38


Co zrobi z wyznaczonymi punktami funkcyjnymi?

Cel liczenia powinien by ju ustalony przed liczeniem, gdy liczenie dla samego liczenia nie ma sensu. Oto kilka zastosowa punktw funkcyjnych: mierzenie podanej produktywnoci zatrudnionych ludzi, poszukanie outsourcera, a nawet oszacowanie niezbdnego zaangaowania czasowego kierownika projektu, nastpnie ledzenie zmian w czasie, przewidywanie kosztw i budowanie harmonogramu projektu, porwnywanie produktywnoci z innymi firmami, do oceny czy aplikacja nadaje si do ponownego uytku, powinna zosta odrzucona lub przerobiona.Przykad

Oszacowanie kosztw projektu Systemu do ewidencjonowania polis ubezpieczeniowych w ubezpieczeniach komunikacyjnych dla PZU S.A. POLISA metod punktw funkcyjnych. Celem projektu jest ewidencjonowanie polis i obliczanie wysokoci skadek ubezpieczeniowych w ubezpieczeniach komunikacyjnych (OC, NW, AC, Assistance i Zielona Karta) oraz likwidacji szkd komunikacyjnych. Funkcjonalno systemu POLISA zostaa skrtowo przedstawiona na rysunku 2.4.system do obsugi ubezpiecze komunikacyjnych w PZU S.A.

sporzdzenie SW

analiza projektowanie

Implementacja

testowanie

wdraanie konserwacja

Likwidacja szkd

wpaty skadek / wypaty odszkodowa

Wyliczenie skadki ubezpieczenia i wystawienie polisy

sporzdzanie wniosku o zawarcie ubezpieczenia

Sporzdzanie protokou zgoszenia szkody Sporzdzeni protokou szkody Decyzja o wypacie

Wyszukiwanie polisy Przyjmowanie wpat na polis Wypata odszkodowa

Wyst. polisy OC Wyst. polisy AC Wyst. polisy NW Wyst. polisy ZK Wyst. polisy Assistance Wysz. wniosku o zaw ubezp.

Wprow. danych klienta Wprow. danych pojazdu Wprow. danych koniecznych przy OC Wprow. danych koniecznych przy AC Wprow. danych koniecznych przy Assistance Wprow. danych koniecznych przy NW Wprow. danych koniecznych przy ZK Sporzdzanie listy klientw Sporzdzenie listy pojazdw

Rys. 2.4. WBS dla projektu POLISA (uszczegowiono tylko faz implementacji)

Szacowanie wielkoci projektu POLISA metod punktw funkcyjnych dzielimy na nastpujce etapy:


39

1. Etap wstpny: wybieramy typ liczenia liczymy w fazie projektu (ang. Development), ekspert systemowy projektant. 2. Obliczenie VAF dla projektu. W tabeli 2.4 przedstawiono 14 czynnikw, ktre szacuje projektant w skali od 1 do 5 jako wspczynniki majce istotne znaczenie dla zoonoci, wielkoci i problemw napotykanych przy budowie oprogramowania.Tabela 2.4. Cechy aplikacji Charakterystyka cechy aplikacji Warto Ci Aplikacja jest oparta na lokalnym przetwarzaniu plikw ale moliwe 2 jest zdalne wprowadzanie danych i wykorzystuje zdaln drukark. Przetwarzanie Aplikacja przygotowuje dane dla kocowego uytkownika procesu 1 danych w innym komponencie systemu, takim jak arkusz kalkulacyjny lub rozproszonych system zarzdzania baz danych. Wymagana Czas odpowiedzi i wymagania dotyczce przepustowoci s wyma3 wydajno ganiem kluczowym przez cay czas pracy systemu. Wymagania systemu wydajnociowe dotyczce wsppracy mierzonego systemu z innymi systemami s ograniczone. Wymagania sprz- W systemie naley uwzgldni bezpieczestwo i zagadnienia doty2 towe systemu czce czasu. Czstotliwo Wymagania ustanowione przez uytkownika dotyczce przetwarza4 transakcji nia transakcji w aplikacji s na tyle due, e uwzgldniane s ju w etapie analizy zada. Wprowadzanie Wicej ni 30% transakcji polega na interaktywnym wprowadzaniu 5 danych w czasie danych. dziaania systemu Efektywno Aplikacja uwzgldnia nastpujce czynniki: 4 uatwienia w nawigacji (klawisze funkcyjne, dynamicznie dla uytkownika generowane menu, przechodzenie pomidzy elementami interfejsu za pomoc tabulatora), menu, pomoc online i dokumentacja, automatyczne przesuwanie kursora, przewijanie okna (w poziomie i w pionie), zdalne drukowanie, predefiniowane klawisze funkcyjne, transakcje online. Modyfikacja plikw logicznych w czasie dziaania systemu Zoono przetwarzania Ponowne wykoMoliwa jest aktualizacja wikszoci wewntrznych plikw logicznych. 3 Nazwa cechy Wymiana danych

Aplikacja nie zawiera zaawansowanych funkcji matematycznych i logicznych. Nie ma kodu nadajcego si do ponownego uycia.

0 0

40 rzystanie pakietw z kodu programu atwo instalacji atwo administracji Wielokrotna lokalizacja


atwo dostosowania

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

Cii =1

14

100 = 29 / 100 = 0,29

VAF = 0,65 + 0,29 = 0,94Identyfikacja wewntrznych plikw logicznych i zewntrznych plikw interfejsowych

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

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

41

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

Suma punktw funkcyjnych dla plikw wynosi 83

Przystpujemy do identyfikacja transakcji. Aby obliczy FP dla zewntrznych wej (EI), trzeba zna: liczb plikw zwizanych z transakcj (FTR), liczb danych rozrnialnych dla przyszego uytkownika wykorzystywanych przez transakcj (DET). Odpowiadajc im zoono wyznaczon w PF odczytujemy z tabeli 2.8.

42

Zarzdzanie projektem informatycznym Tabela 2.8 Liczba plikw zwizanych (FTR) Mniej ni 2 2 Wicej ni 2 14 Niska (3) Niska (3) rednia (4) Liczba DET 515 Niska (3) rednia (4) Wysoka (6) wicej ni 15 rednia (4) Wysoka (6) Wysoka (6)

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

Aby obliczy PF dla zewntrznych zapyta (EQ), trzeba zna: liczb plikw zwizanych z transakcj (FTR),

Documents

Fraczkowski - Zarządzanie projektem informatycznym