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 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ę