Inżynieria oprogramowania, wykład 7, slajd 1

Wprowadzenie do zarządzania projektem

dr inż. Grzegorz
Bliźniuk

Inżynieria oprogramowania

wykład 7

Inżynieria oprogramowania, wykład 7, slajd 2

Plan wykładu

1. Zadania kierownictwa przedsięwzięcia

2. Czynniki psychologiczne w inżynierii oprogramowania

3. Kilka metodyk prowadzenia projektów (Prince2, PMI, RUP)

4. Podsumowanie

Inżynieria oprogramowania, wykład 7, slajd 3

Niezbędnym warunkiem sukcesu, czyli wykonania systemu informatycznego
zaakceptowanego przez użytkownika jest właściwe zarządzanie
przedsięwzięciem informatycznym.

Podstawowe zadania kierownictwa przedsięwzięcia informatycznego:

1. Opracowanie propozycji dotyczących sposobu prowadzenia przedsięwzięcia

2. Kosztorysowanie przedsięwzięcia

3. Planowanie i harmonogramowanie przedsięwzięcia

4. Monitorowanie i kontrolowanie realizacji przedsięwzięcia

5. Dobór i ocena personelu

6. Opracowanie i prezentowanie sprawozdań dla kierownictwa wyższego szczebla

Zadania kierownictwa przedsięwzięcia

Inżynieria oprogramowania, wykład 7, slajd 4

Czynniki te wynikają z faktu, że oprogramowanie jest
używane i tworzone przez ludzi.

Użytkowanie - implikuje zasady tworzenia interfejsu
użytkownika i dokumentacji użytkowej,

Tworzenie - zagadnienia psychologiczne odgrywające rolę w
tworzeniu oprogramowania.

Elementy ludzkiej inteligencji:
1. Umiejętność całościowego (syntetycznego) spojrzenia na

problem.

2. Posługiwanie się wiedzą płynącą z doświadczenia, a więc

stosowania nieścisłych zasad wnioskowania na bazie
wcześniejszych doświadczeń.

Czynniki psychologiczne w inżynierii

oprogramowania

Inżynieria oprogramowania, wykład 7, slajd 5

Istnieją ogromne różnice w predyspozycjach osób dotyczące ich
efektywności w produkcji oprogramowania.

Testy osobowości:
metody określenia, czy dana osoba posiada cechy przydatne na
danym stanowisku.

Stosowanie testów osobowości wiąże się z następującymi

trudnościami:

1. Osobowość ludzka ma charakter dynamiczny (zmienia się).

Wieloletnia praktyka zawodowa nie pozostaje bez wpływu na
osobowość.

2. Różne zadania mogą wymagać różnych cech osobowości. Inne

powinien posiadać analityk (kontakt z klientem), inne zaś
programista lub osoba testująca oprogramowanie. Ponadto,
metody inżynierii oprogramowania ulegają zmianie, co pociąga
za sobą inny stosunek pożądanych cech osobowości do
aktualnych zadań.

3. Osoby poddane testom będą starały się raczej odgadnąć

pożądaną przez testujących odpowiedź niż odpowiadać zgodnie
ze stanem faktycznym. Test nie będzie więc odzwierciedlał cech
osobowości osoby, lecz raczej to, jak ta osoba wyobraża sobie
cele i kryteria testowania oraz cechy pożądane przez
pracodawcę.

Osobowość twórców oprogramowania

Inżynieria oprogramowania, wykład 7, slajd 6

Umiejętność pracy w stresie. W pracy często zdarzają się
okresy wymagające szybkiego wykonania złożonych zadań. Dla
większości osób niewielki stres działa mobilizująco. Po
przekroczeniu jednak pewnego progu następuje spadek
możliwości danej osoby. Próg ten jest różny dla różnych osób.

Zdolności adaptacyjne. Informatyka jest jedną z najszybciej
zmieniających się dziedzin. Ocenia się, że 7-9 miesięcy przynosi
w informatyce zmiany, które w innych dziedzinach zajmują 5-7
lat. Oznacza to konieczność stałego kształcenia dla wszystkich
inżynierów oprogramowania - stałe poznawanie nowych
narzędzi, sprzętu, oprogramowania, technologii, metod,
sposobów pracy. Niestety, nie wszyscy to tempo wytrzymują.

Uśpienie, zajmowanie się jednym problemem w jednym
środowisku przez lata jest w informatyce bardzo groźne!

Cechy dobrego inżyniera

oprogramowania

Inżynieria oprogramowania, wykład 7, slajd 7

Wiedza składniowa. Polega na mechanicznym zapamiętaniu
pewnych faktów, bez ich istotnego przetworzenia. Jest słabo
zintegrowana z wcześniej zdobytą wiedzą.
Np. do takiej wiedzy zaliczamy reguły składniowe danego języka
programowania.

Wiedza semantyczna (znaczeniowa). Fakty są zapamiętane nie w
postaci ich formy, lecz w postaci znaczenia. Np. znajomość zasady
instrukcji while, znajomość koncepcji pojęcia klasy i dziedziczenia,
itd. Nowa wiedza jest zintegrowana z wcześniej zdobytą wiedzą.

Istnienie tych dwóch rodzajów wiedzy może mieć wpływ na
politykę kadrową. Np. pracownik rozumiejący zasady
obiektowości (wiedza semantyczna) może lepiej sobie poradzić niż
pracownik dobrze znający składnię i reguły użycia poszczególnych
konstrukcji C++ (wiedza składniowa).

Firmy przywiązują zbyt wielką wagę do wiedzy składniowej,
np. znajomości konkretnych języków i systemów. W istocie, ta
wiedza może być stosunkowo szybko nabyta (kilka tygodni
przeciętnie na opanowanie nowego języka). Natomiast wiedza
semantyczne może być przedmiotem lat studiów i doświadczeń.

Rodzaje wiedzy

Inżynieria oprogramowania, wykład 7, slajd 8

Czynniki psychologiczne mają zasadniczy wpływ na efektywność
pracy zespołu. Wyróżnia się następujące typy psychologiczne:

1. Zorientowani na zadania (task-oriented). Osoby
samowystarczalne, zdolne, zamknięte, agresywne, lubiące
współzawodnictwo, niezależne.

2. Zorientowani na siebie (self-oriented). Osoby niezgodne,
dogmatyczne, agresywne, zamknięte, lubiące współzawodnictwo,
zazdrosne.

3. Zorientowani na interakcję (interaction-oriented). Osoby
nieagresywne, o niewielkiej potrzebie autonomii i
indywidualnych osiągnięć, pomocne, przyjazne.

Osoby typu 1 są efektywne, o ile pracują w pojedynkę. Zespół
złożony z takich osób może być jednak nieefektywny. Lepsze
wyniki dają zespoły złożone z typów 3. Typ 1 i 2 może być także
efektywny w zespole, o ile jest odpowiednio motywowany przez
kierownictwo. Typy 3 są konieczne w fazie wstępnej wymagającej
intensywnej interakcji z klientem.

Nastawienie osób do pracy w zespole

Inżynieria oprogramowania, wykład 7, slajd 9

Terminem tym określa się silny, osobisty związek pomiędzy
poszczególnymi członkami zespołu, grupą i wynikami pracy
grupy. Niekorzystne efekty:

Trudność zmiany lidera. Silnie związana grupa nie akceptuje
nowego lidera narzuconego z zewnątrz. Często jednak formalny
lider źle kieruje pracą.

Myślenie grupowe (groupthink). Brak krytycyzmu w stosunku
do efektów pracy grupy, nie rozważanie jakichkolwiek pomysłów
i rozwiązań nie pochodzących z wnętrza grupy, wzajemne
podtrzymywanie się w poglądach, często niesłusznych lub
tendencyjnych. Rezultatem jest znaczny spadek jakości wyników
pracy.

Walka z myśleniem grupowym:

Sesje krytyki, podczas których dozwolona jest jedynie krytyka
przyjętych rozwiązań, natomiast zabroniona jest jakakolwiek
obrona osiągnięć grupy.

Włączanie do zespołu krytycznych osobowości - osób o
szczególnych zdolnościach do wyszukiwania błędów i
kwestionowania przyjętych rozwiązań (tzw. “czepialskich”).
Osoby te są zwykle nie lubiane.

Lojalność grupowa

Inżynieria oprogramowania, wykład 7, slajd 10

1. Zamiast dużej hali, lepsze wyniki daje umieszczenie dwóch-

trzech stanowisk pracy w wielu mniejszych
pomieszczeniach.

2. Personalizacja stanowiska pracy.

3. Pokój zebrań dla organizowania formalnych spotkań

pracowników.

4. Miejsce dla spotkań nieformalnych (np. omówienie spraw

przy kawie).

5. Poczucie pracy na nowoczesnym sprzęcie. Wydajność i chęć

ludzi do pracy gwałtownie spada, jeżeli odczuwają oni, że
pracują na przestarzałym sprzęcie - nawet wtedy, gdy
wymiana sprzętu jest merytorycznie nieuzasadniona.

6. Komfort psychiczny, właściwa atmosfera w pracy, eliminacja

napięć i zadrażnień,

7. nie dopuszczanie do rozmycia odpowiedzialności,

sprawiedliwa ocena wyników pracy poszczególnych
członków zespołu, równomierny rozkład zadań.

Ergonomia pracy

Inżynieria oprogramowania, wykład 7, slajd 11



CCTA Prince2



Project Management Institute



elementy Chestra v. 2.0 z Siemens
Business Services



zarządzanie konfiguracją z Rational
Unified Process

Metodyki zarządzania

Inżynieria oprogramowania, wykład 7, slajd 12



Metodyka Prince2 została opracowana w 1996 r. przez brytyjską

organizację CCTA (Central Computer and Telecommunication Agency).

Początki jej koncepcji są jednak dużo starsze (lata 80-te). W dużym

stopniu Prince2 jest związana z popularną w Polsce metodyką LBMS

(firma LBMS była twórcą poprzedniej wersji Prince), jak też z metodyką

Unii Europejskiej o nazwie MAXIME.



Obecnie Prince2 jest obowiązkową metodyką wszystkich organizacji

rządowych w Wielkiej Brytanii. Jest również stosowana w innych krajach

europejskich.



Według autorów Prince2 metoda ta jest pionierem procesowego

podejścia do zarządzania projektem, a także norm jakościowych z serii

ISO 9000.



Konkurencyjna do Prince2 amerykańska metodyka zarządzania

projektami opracowana przez Project Management Instytute (PMI)

została opublikowana również w 1996r.



Pomimo tego, że autorzy Prince2 mocno próbują odróżniać się od PMI,

to tak faktycznie nie widać tutaj istotnych różnić w idei zarządzania.

Trochę odmienna jest jedynie enumeracja obszarów zarządzania

projektem, co nie zmienia faktu, że Prince2 i PMI są do siebie bardzo

podobne.

Prince2, pochodzenie

Inżynieria oprogramowania, wykład 7, slajd 13



W Prince2 skoncentrowano się na określeniu zasad
organizacji i zarządzania projektem, co ma w
przekonaniu jej autorów gwarantować prawidłowe
jego rozpoczęcie i doprowadzenie do pomyślnego
zakończenia oraz wypracowanie oczekiwanych
produktów, przy jednoczesnym dotrzymaniu
planowanego czasu, budżetu i jakości projektu.



Dzięki oddzieleniu grupy zarządczej,
odpowiedzialnej za organizację i kierowanie, od
technicznej wytwarzającej produkt, może ona
znaleźć zastosowanie w wielu dziedzinach

Prince2, główne założenia

Inżynieria oprogramowania, wykład 7, slajd 14

Projekt

, to sposób prowadzenia

przedsięwzięć gospodarczych
zmierzający do wytworzenia produktu
uzasadnionego biznesowo, w ramach
określonego czasu, budżetu, z
odpowiednią strukturą organizacyjną ,
rolami i zakresami odpowiedzialności.

Prince2, definicja projektu

Inżynieria oprogramowania, wykład 7, slajd 15

Prince2 – wymiary zarządzania projektem

Produkt

Harmonogram

Koszt

Jakość

Poszczególne wymiary zarządzania projektem mają
na siebie istotny wpływ. Powinny być one
analizowane przez kierownika projektu łącznie

(również ocena ryzyka)

Prince2, wymiary zarządzania

Inżynieria oprogramowania, wykład 7, slajd 16



Przez produkty projektu rozumie się wszystkie jego
elementy, które mogą powstać w wyniku jego
realizacji.



Może to być gotowe oprogramowanie,
zainstalowane systemy, dokumentacja
oprogramowania, różnego rodzaju procedury,
wykształcone kadry ludzkie itp.



Opracowanie planów działań w wymiarze produktów
odbywa się na podstawie definicji zakresu projektu.

Prince2, wymiar produktu

Prince2 – wymiary

Produkt

Harmo-
nogram

Koszt

Jakość

Inżynieria oprogramowania, wykład 7, slajd 17



Na podstawie precyzyjnie zdefiniowanego

zakresu projektu można zdefiniować drugi

wymiar projektu, czyli czas, który jest najczęściej

zapisywany w postaci harmonogramu.



Często spotykaną formą prezentacji

harmonogramu są na przykład tabele lub arkusze

kalkulacyjne, jak również wykresy Gantta, które

przedstawiają poszczególne czynności projektowe

w sieci uwzględniającej wzajemne ich zależności,

następstwa i zasoby niezbędne do ich wykonania

w odpowiednio zdefiniowanej skali czasu.

Prince2, wymiar czasu

Prince2 – wymiary

Produkt

Harmo-
nogram

Koszt

Jakość

Inżynieria oprogramowania, wykład 7, slajd 18



Budżet projektu stanowi zestawienie kosztów
realizacji projektu.



Koszt ten powinien być podzielony na
poszczególne jego kategorie.



Mogą to być

– koszty osobowe,
– koszty sprzętu,
– administracji projektu,
– delegacji,
– szkoleń itp.

Prince2, wymiar budżetu

Prince2 – wymiary

Produkt

Harmo-
nogram

Koszt

Jakość

Inżynieria oprogramowania, wykład 7, slajd 19



Wymiar jakości dotyczy

– oceny zarówno poszczególnych produktów

projektowych:

» dokumentacji,
» oprogramowania,
» platformy techniczno-systemowej itp.

– jak i oceny organizacji procesu projektowego:

» planu wzajemnych oddziaływań procesów projektowych,
» zasobów ludzkich zaangażowanych w projekt,
» zarządzania poszczególnymi wymiarami projektu itp.

Prince2, wymiar jakości

Prince2 – wymiary

Produkt

Harmono
gram

Koszt

Jakość

Inżynieria oprogramowania, wykład 7, slajd 20

Elementy nadrzędne względem
biura projektu: Sponsor, Rada,
Zarząd
Elementy merytorycznie
powiązane z
biurem projektu: Szef jakości,
Komitet
Kontroli Zmian, Komitet
Akceptacyjny

Pozostałe elementy są
składowymi biura projektu

Prince2, struktura projektu

Zarząd biznesu

użytkownika

Sponsor projektu

Rada Projektu

Zarząd projektu

Szef
projektu
u
użytkownik
a

Szef
projektu
u dostawcy

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akceptacyj

ny

analogicznie

Sekretariat

biura

projektu

Administracja

biura

projektu

Menedżer

Konfiguracji

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjny 1

Zespół

realizacyjny 2

Zespół

realizacyjny N

Zespół

realizacyjny 3

Inżynieria oprogramowania, wykład 7, slajd 21



Najczęściej jest to członek zarządu klienta
lub jego bezpośredni przedstawiciel.



Jest on odpowiedzialny za finansowanie
całego przedsięwzięcia i reprezentuje
informatyzowany biznes.



Zna on dokładnie wartość biznesową
projektu i musi posiadać uprawnienia do
podejmowania decyzji w zakresie zmian
dotyczących projektu.

Prince2, Sponsor Projektu

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 22



Sponsor w początkowej fazie projektu:

– formułuje

misję

przedsięwzięcia

informatycznego i uzasadnia ją biznesowo

– wyznacza budżet projektu
– ustala główne oczekiwane produkty projektu
– mianuje Przewodniczącego Rady Projektu,

zatwierdza pozostałych członków Rady



W pozostałych fazach projektu:

– zatwierdza odbiór produktów projektu,
– na

poziomie

taktycznym

decyduje

w

kluczowych momentach projektu, (wstrzymuje

projekt , przydziela dodatkowe finanse itp.),

– jest mediatorem w ważnych konfliktach,

niemożliwych do rozstrzygnięcia na niższych

szczeblach struktury projektu.

Prince2, Sponsor Projektu

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 23



Sponsor jest odpowiedzialny za utworzenie Dokumentu

Inicjacji Projektu (PID), w którym określa się:

– określa się cel i zakres realizacji projektu,
– czas realizacji projektu,
– budżet realizacji projektu,
– plan prowadzenia projektu,
– plan zapewnienia jakości,
– kryteria akceptacji produktów projektu
– oczekiwane korzyści biznesowe
– pierwszą ocenę zagrożeń w projekcie
– plan zarządzania problemami



Dokument inicjacji jest poprzedzany:

– Uzasadnieniem biznesowym projektu
– Oceną zagrożeń projektu
– Studium wykonalności projektu

Prince2, Sponsor Projektu

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 24



Rada Projektu (Komitet Sterujący) zawiera w swoim ciele
reprezentację wszystkich uczestników projektu, takich
jak: Sponsor, użytkownicy, dostawcy. Składa się on z:

–

Przewodniczącego Rady, mianowanego przez Sponsora

–

pozostałych

członków

Rady

zaproponowanych

przez

Przewodniczącego Rady



obraduje w kluczowych momentach projektu, takich jak:
początek i koniec projektu oraz tzw. punktach
krytycznych (ang. milestones) poszczególnych faz
projektu



spotyka się również doraźnie w przypadku występowania
zagrożeń dla prawidłowej realizacji projektu

Prince2, Rada Projektu

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 25



główne zadania Rady Projektu:

– mianowanie Szefów Projektu,
– okresowa i etapowa ocena stanu projektu i

zatwierdzanie planów dalszych prac,

– rozstrzyganie

sporów

występujących

na

szczeblu Szefów Projektu

– zatwierdzanie Wniosków o Zmianę w zakresie

funkcjonalnym i niefunkcjonalnym projektu

– zatwierdzanie akceptacji kolejnych produktów

projektu

Prince2, Rada Projektu

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 26



Szef (Kierownik) Projektu jest personalnie

odpowiedzialny za sukces lub porażkę projektu



Szef Projektu decyduje na szczeblu operacyjnym



Szefowie projektów ze strony wytwórcy i ze

strony dostawcy tworzą Zarząd Projektu



Zarząd Projektu decyduje na szczeblu taktyczno-

operacyjnym



pozostałe szczeble decyzyjne:

– decyzje taktyczne – Rada Projektu

– decyzje strategiczne – Sponsor Projektu

Prince2, Szef Projektu

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 27



Szef Projektu u wytwórcy odpowiada za:

– organizowanie (planowanie) projektu i prac oraz

korygowanie planów,

– ustalenie założeń, wymagań użytkownika oraz

kryteriów akceptacji produktów projektowych,

– kontrolę postępów i ich raportowanie (produkt,

czas, budżet),

– mianowanie Szefów Zespołów i Sekretariatu

Projektu,

– dostarczenie produktów do testów i akceptacji,
– zapewnienie zasobów ze strony dostawcy,
– zorganizowanie prac Komitetu Sterującego,
– kontakty z poddostawcami

Prince2, Szef Projektu

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 28



Szef Projektu u użytkownika odpowiada za:

– współorganizację prac projektowych,
– zapewnienie zasobów dla projektu ze strony

klienta,



Obaj Szefowie projektu:

– prowadzą i gromadzą dokumentację projektu,
– zapewniają

warunki

pracy

zespołów

realizacyjnych,

– realizują zatwierdzone zmiany,
– w zależności od potrzeb zajmują eskalacją

odpowiednich problemów

Prince2, Szef Projektu

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 29



Szef Jakości jest współpracuje z Szefami

Projektu



uczestniczy we wszystkich pracach zespołów

realizacyjnych (bardzo dyskusyjne)



w zakresie jakości podlegają mu

– plany i dokumentacja projektu
– produkty i ich testy
– praca zespołów realizacyjnych
– kontakty z poddostawcami
– gospodarka finansowa projektu
– zarządzanie ryzykiem projektu

Prince2, Szef Jakości

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 30



Komitet Kontroli Zmian składa się z

przedstawicieli zarówno dostawcy jak i klienta.

Jego skład wyznacza Rada Projektu



Spotkania Komitetu odbywają się doraźnie, w

przypadku konieczności rozpatrzenia Wniosków

o zmianę w projekcie, składanych przez

Szefów Projektów oraz w czasie przeglądów

zatwierdzania etapów zarządczych.



W przypadku niemożności podjęcia decyzji o

dokonaniu zmian przedkłada on sprawę do

rozstrzygnięcia Radzie Projektu.

Prince2, Komitet Kontroli Zmian

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 31



Komitet Akceptacyjny składa się przeważnie z

przedstawicieli obu stron, często jednak spotyka

się w nim wyłącznie przedstawicieli klienta.



Podlega mu zespół testów akceptacyjnych.



Podstawowym

zadaniem

Komitetu

Akceptacyjnego jest wypracowanie decyzji

odnośnie przyjęcia lub odrzucenia produktów, na

podstawie wyników testów i opinii specjalistów,

a następnie przedstawieniu jej Radzie Projektu,

która podejmuje decyzję o akceptacji bądź braku

akceptacji produktów projektu

Prince2, Komitet Akceptacyjny

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 32



Wykonuje zadania w zakresie:

– prowadzenia biblioteki projektu, planów, raportów,

Wniosków o Zmianę itp.

– zarządzania korespondencją, dokumentacją spotkań
– zbierania i konsolidacji raportów z zespołów

technicznych,

– przygotowania materiałów do raportów Szefa Projektu
– spraw osobowych (urlopy, rozliczenia finansowe,

sprawy pracownicze itp.)

– rozliczeń finansowych z dostawcami zewnętrznymi
– rozliczeń finansowych z klientem



w większych projektach powołuje się:

– Menedżera Konfiguracji (ang. Configuration Manager)
– Bibliotekarza Projektu (ang. Librarian)
– Planistę (ang. Planner)

Prince2,

sekretariat/administracja biura projektu

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 33



Zespoły realizacyjne są wykonawcami produktów i

dlatego od ich prawidłowego składu i organizacji zależy

powodzenie realizacji projektu.



często łączy się w nich fachowców tych samych

specjalnościach.



Szefów Zespołów powinni być oni doświadczonymi

fachowcami z danej dziedziny przedmiotowej projektu,

posiadających zdolności kierowania ludźmi.



Szefowie Zespołów powinni pomagać Szefowi Projektu w

zakresie definiowania produktów, planowania, oceny

Wniosków o Zmianę, przygotowywania raportów z

realizacji prac, czy wreszcie realizacji zadań.



Najczęściej pełnią one również rolę zespołów testów (lub

powoływany jest oddzielny zespół testów)

Prince2, Zespoły Realizacyjne

Zarząd biznesu

użytkownika

Sponsor

projektu

Rada

Projektu

Zarząd

projektu

Szef projektu

(odpowiedni)

Szef

Jakości

Komitet

Kontroli

Zmian

Komitet

Akcepta

-cyjny

Sekretariat

Administrac

ja

Menedżer

Konfiguracj

i

Biblioteka /

Archiwum

Projektu

Planista

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Zespół

realizacyjn

y 1

Inżynieria oprogramowania, wykład 7, slajd 34

PMI – wymiary zarządzania projektem

Zakres

Harmonogram

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Zasoby ludzkie

Zaopatrywanie / zlecenia / sprzedaż

Metodyka PMI, wymiary zarządzania

Inżynieria oprogramowania, wykład 7, slajd 35



Zarządzanie zakresem projektu obejmuje procesy

wymagane dla uzyskania pewności, że projekt

uwzględnia

wszystkie

konieczne

czynności

niezbędne dla pomyślnego zakończenia projektu i

uzyskania oczekiwanego zakresu produktu.



Procesy te w głównej mierze są skoncentrowane

na permanentnym ustalaniu, co powinno mieścić

się w zakresie projektu, czy w zakresie produktu



Główne procesy:

– inicjowanie faz projektu
– planowanie zakresu
– definiowanie zakresu
– weryfikacja zakresu
– kontrola zmian zakresu

PMI, wymiar zakresu

PMI – wymiary

Zakres

Czas

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Ludzie

Zaopatrywanie/zlecenia/...

Inżynieria oprogramowania, wykład 7, slajd 36



Zarządzanie

kosztem

projektu

obejmuje

procesy wymagane do zapewnienia, że projekt
zostanie

ukończony

w

ramach

zaakceptowanego budżetu.



Główne procesy:

– planowanie zasobów
– estymowanie kosztu
– przypisywanie kosztów (budżetowanie)
– kontrola kosztu
– zarządzanie zmianami budżetu

PMI, wymiar kosztu

PMI – wymiary

Zakres

Czas

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Ludzie

Zaopatrywanie/zlecenia/...

Inżynieria oprogramowania, wykład 7, slajd 37



Zarządzanie

harmonogramem

projektu

obejmuje procesy wymagane do zapewnienia
przestrzegania

przez

zespół

projektowy

ustalonych

granic

czasowych

dla

poszczególnych czynności w projekcie.



Główne procesy:

– definiowanie czynności
– sekwencjonowanie czynności
– estymowanie czasu
– opracowanie harmonogramu
– kontrola wykonania harmonogramu
– zarządzanie zmianami harmonogramu

PMI, wymiar czasu

PMI – wymiary

Zakres

Czas

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Ludzie

Zaopatrywanie/zlecenia/...

Inżynieria oprogramowania, wykład 7, slajd 38



Zarządzanie

jakością

projektu

obejmuje

procesy

wymagane

do

zapewnienia

zaspokojenia przez rezultaty projektu tych
potrzeb, dla których został on powołany.



Zalicza się tu wszystkie czynności z zakresu
funkcji

zarządzania,

których

wykonanie

decyduje o celach i polityce jakości w projekcie.



Główne procesy:

– planowanie jakości,
– zapewnienie jakości
– kontrola jakości

PMI, wymiar jakości

PMI – wymiary

Zakres

Czas

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Ludzie

Zaopatrywanie/zlecenia/...

Inżynieria oprogramowania, wykład 7, slajd 39



Zarządzanie komunikacją obejmuje procesy służące

zapewnieniu terminowego i właściwego tworzenia,

gromadzenia, rozpowszechniania, przechowywania i

usuwania informacji niezbędnej do efektywnego

zarządzania projektem.



Analizuje się tutaj wszystkie istotne połączenia między

ludźmi,

ideami

oraz

wszelkimi

informacjami

potrzebnymi dla osiągnięcia sukcesu przedsięwzięcia

informatycznego.



Każdy zatrudniony w projekcie musi być przygotowany

do wysyłania i odbierania komunikatów w języku

projektu i musi rozumieć w jaki sposób komunikacja, w

której bierze udział, wpływa całość projektu.



Główne procesy:

– planowanie komunikacji

– dystrybuowanie informacji

– sprawozdawczość

PMI, wymiar komunikacji

PMI – wymiary

Zakres

Czas

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Ludzie

Zaopatrywanie/zlecenia/...

Inżynieria oprogramowania, wykład 7, slajd 40



Zarządzanie integracją projektu obejmuje

procesy wymagane do zapewnienia poprawnej

koordynacji wszystkich elementów projektu.



Procesy te umożliwiają koordynację działań

mających na celu:

– zaspokojenie

wszystkich

zidentyfikowanych

potrzeb stron zainteresowanych projektem

– spełnienie

ich

oczekiwań

w

stopniu

zapewniającym pomyślność projektu



Główne procesy:

– wypracowanie planu projektu
– wykonywanie planu projektu
– ogólna kontrola zmian projektu

PMI, wymiar integracji

PMI – wymiary

Zakres

Czas

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Ludzie

Zaopatrywanie/zlecenia/...

Inżynieria oprogramowania, wykład 7, slajd 41



Zarządzanie

ryzykiem

obejmuje

procesy

identyfikacji, analizowania i reakcji na zaistnienie
czynników ryzyka w projekcie.



Jest to związane z podejmowaniem przez Szefa
Projektu decyzji w warunkach niepełnej i
niepewnej wiedzy o skutkach tej decyzji dla
projektu.



Główne procesy:

– identyfikacja ryzyka
– estymowanie ryzyka
– optymalizacja ryzyka
– monitorowanie ryzyka

PMI, wymiar ryzyka

PMI – wymiary

Zakres

Czas

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Ludzie

Zaopatrywanie/zlecenia/...

Inżynieria oprogramowania, wykład 7, slajd 42



Zarządzanie zasobami ludzkimi obejmuje procesy

ułatwiające efektywne wykorzystanie ludzi w

projekcie

(klientów,

sponsorów

i

innych

uczestników).



Procesy te uwzględniają między innymi:

– przywództwo, komunikację, negocjacje,
– delegowanie, motywowanie, mentoring,
– budowę zespołów, rozwiązywanie konfliktów,
– rekrutację, różne regulacje



Główne procesy:

– planowanie organizacji
– nabór personelu
– zarządzanie zespołami ludzkimi

PMI, wymiar ludzki

PMI – wymiary

Zakres

Czas

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Ludzie

Zaopatrywanie/zlecenia/...

Inżynieria oprogramowania, wykład 7, slajd 43



Zarządzanie zaopatrywaniem/zleceniami/sprzedażą

obejmuje zdobywanie dóbr

i usług spoza

organizacji wykonującej projekt.



Obszar ten jest badany z perspektywy kupującego

oraz relacji kupujący-dostawca. Relacja ta może

istnieć na wielu szczeblach jednego projektu.



Dla dostawcy kluczowym podmiotem jest odbiorca.



Główne procesy:

– planowanie zleceń

– planowanie ofert

– realizacja ofert

– selekcja dostawców

PMI, zaopatrywanie

PMI – wymiary

Zakres

Czas

Koszt

Jakość

Komunikacja

Ryzyko

Integracja

Ludzie

Zaopatrywanie/zlecenia/...

Inżynieria oprogramowania, wykład 7, slajd 44

źródło: Siemens Konzern

Kierownik Projektu

Techniczne zarządzanie

projektem

Komitet Sterujący

(Rada Projektu)

Menedżer

Budżetu

Menedżer

Konfiguracji

Menedżer Jakości

Architekt
Systemowy

Architekt

Biznesowy

Administracja

Projektu

Dokumen-
tacja
użytkowni
ka

Integracja

i Testy

ZR 1

ZR 2

ZR n



Silna pozycja Kierownika
Projektu (Szefa Projektu),



zakres projektu i zakres
produktu jest określany
przez Architekta
Systemowego i Architekta
Biznesowego,



Menedżer Jakości podlega
pod Szefa Projektu



Menedżer Konfiguracji
nie jest już składową
administracji projektu



wyróżniono obszary
dokumentacji i testów

Chestra SBS –

struktura biura projektu

Inżynieria oprogramowania, wykład 7, slajd 45



Proces zarządzania konfiguracją oprogramowania jest realizowany w
celu:

– identyfikacji i udokumentowania funkcjonalnych oraz niefunkcjonalnych

charakterystyk produktów projektowych,

– monitorowania wszelkich zmian tych charakterystyk,
– zapisywania i raportowania tych zmian oraz stopnia implementacji tych

zmian,

– weryfikacji poszczególnych produktów projektowych pod względem

spełniania wymagań ustalonych dla tych produktów



Zarządzanie konfiguracją jest związane z:

– zarządzaniem żądaniami zmian (ang. Change Request Management CRM),
– raportowaniem statusu konfiguracji,
– śledzeniem zmian
– zarządzaniem wersjami dokumentacji i oprogramowania
– zarządzaniem architekturą oprogramowania

RUP – wybrane aspekty zarządzania

konfiguracją

Inżynieria oprogramowania, wykład 7, slajd 46

Zarządzanie żądaniami zmian (ang. CRM)

Zarządzanie konfiguracją (ang. CM)

Raportowanie
statusu
konfiguracji

źródło: Rational Corp.: usytuowanie zarządzania konfiguracją według RUP

RUP – wybrane aspekty zarządzania

konfiguracją

Inżynieria oprogramowania, wykład 7, slajd 47



Przeglądy konfiguracji przeprowadza się w dwóch etapach:

– przeglądy konfiguracji fizycznej, dotyczące identyfikacji produktów

programowych podlegających wdrożeniu,

– przeglądy konfiguracji funkcjonalnej, mające na celu potwierdzenie

zgodności konfiguracji z wymaganiami funkcjonalnymi nałożonymi na
oprogramowanie.



Wnioski z przeglądów konfiguracji stanowią podstawę dla:

– ustalenia wersji konfiguracji fizycznej i funkcjonalnej oprogramowania,
– identyfikacji konfiguracji podstawowej oprogramowania,
– identyfikacji wszystkich brakujących elementów konfiguracji, np.:

» dokumentacji projektowej,
» produktów programowych,
» dokumentacji testów,
» dokumentacji wymagań itp.),

– identyfikacji tych elementów konfiguracji fizycznej, które przeszły testy

(bądź ich nie przeszły)

RUP – wybrane aspekty zarządzania

konfiguracją

Inżynieria oprogramowania, wykład 7, slajd 48

Plan kontroli

konfiguracji i

zmian

Utworzenie

środowiska

zarządzania

zmianami

Zmiany,

dostarczani

e

elementów

konfiguracj

i

Zarządzanie

wersjami

konfiguracji

Monitorowanie

i raportowanie

statusu

konfiguracji

Zarządzanie

zmianami

wymagań

źródło: Rational Corp.: . Przepływ prac w zarządzaniu
zmianami i
konfiguracją według RUP

RUP – wybrane aspekty zarządzania

konfiguracją

Inżynieria oprogramowania, wykład 7, slajd 49



W dużych i dojrzałych organizacjach prac wytwórczych SI

oprócz biura projektu u wytwórcy oprogramowania

powołuje się biuro projektu po stronie użytkownika.



Biuro u wytwórcy ma za zadanie doprowadzić do

skutecznego wytworzenia poszczególnych produktów

programowych zgodnie z wytycznymi, jakie są dostarczane

przez użytkownika.



Biuro projektu u użytkownika natomiast powinno:

– skutecznie zarządzać współpracą użytkownika z wytwórcą,
– wspomagać zmiany organizacji biznesu użytkownika na skutek

jego informatyzacji

– zapewnić profesjonalizm po stronie użytkownika w podejściu do

zadań poszczególnych osób związanych z tą informatyzacją

(znakomita większość użytkowników systemów informatycznych

nie zna się na informatyce jako takiej).

Podsumowanie

Inżynieria oprogramowania, wykład 7, slajd 50



Okazuje się, że w ogromnym gąszczu różnych wymiarów,
zasad i procedur zarządzania, jak również wobec ogromnego
rozmiaru literatury przedmiotu zdarza się, że traci się z pola
widzenia sens budowania organizacji projektowych.



Zaczyna się zużywać ogromną ilość zasobów po to, aby biuro
po prostu powstało i istniało.



Samo istnienie sfery zarządczej biura projektu na pewno
jednak nie spowoduje to automatycznej realizacji
podstawowych zadań uczestników projektu, tj.:

– użytkownika, czyli stwierdzenia CO należy wykonać,
– wytwórcy, czyli określenia JAK wykonać to, czego oczekuje

użytkownik (i skutecznej realizacji tych oczekiwań)

Podsumowanie

Inżynieria oprogramowania, wykład 7, slajd 51



Najbardziej istotnym elementem organizacji

projektowej po obu stronach przedsięwzięcia

informatycznego są Zespoły Realizacyjne



Bez kompetentnej pracy tych zespołów

Kierownik Projektu z całą pewnością

pozbawia siebie możliwości realizacji

swojego podstawowego zadania, jakim jest

doprowadzenie do sukcesu projektu.

4. Podsumowanie

dziękuję za uwagę