Projekt Content Management System „Profilowanie”

Projekt Content Management System „Profilowanie”

P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Zarządzanie Projektem Informatycznym
Projekt
Content Management System
„Profilowanie”
Opracował zespół w składzie:
Michał Misiak
Wojciech Turak
Michał Kościesza
2005 © ZPI
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Wstęp
W dzisiejszych czasach business wykorzystuje różne sposoby walki o klienta, walki z
konkurencją angażując to tego procesu najlepszych specjalistów różnych dziedzin oraz
wykorzystując najnowsze zdobycze technologiczne i naukowe. W hipermarketach pracują
grupy psychologów zajmujących się odpowiednim przygotowaniem półek z towarami w taki
sposób, aby zmusić klienta do zakupu rzeczy, których w rzeczywistości nie zamierzał kupić.
Wszechobecna reklama jest coraz doskonalsza. Pomimo naszej świadomości o tym, że
może na nas wypływać, nie jesteśmy w stanie obronić się przed nią. W rzeczywistości i tak
jej ulegamy. Kolejnym krokiem w pozyskiwaniu informacji o człowieku, jest wejście w jego
sferę prywatności. W celu lepszego organizowania kampanii reklamowych, projektowaniu
businessu liczy się wiedza o rzeczywistych i aktualnych pragnieniach człowieka, o stanie
fizycznym, psychicznym, statusie społecznym, warunkach finansowych, itd.. Istotna i
pożądana jest informacja precyzyjna, opisująca nie grupę, ale jednostkę. Można by się
rozwodzić nad etyką takiej działalności, natomiast faktem jest, iż coraz częściej profile
naszych osób stają przedmiotem handlu. Wartość rynkowa profilu zależy od jego
wiarygodności i precyzji opisu konkretnej osoby.
Tworzenie profilu jest zadaniem nie łatwym. Polega ono na przechytrzeniu osoby, o
której będzie zbierana informacja. Należy to robić bardzo subtelnie. Liczy się pomysłowość.
Nikt przecież nie chce, być w żaden sposób śledzony – profilowany.
W realizowanym projekcie skupimy się na tworzeniu profili na bazie zachowań osób
przebywających w wirtualnym świecie – Internecie.
Cel projektu
Budowa systemu zarządzania treścią służącego do kreowania profili jego
użytkowników.
Specyfikacja wymagań
Wymagania co do systemu i profili
 W ramach systemu zostaną zbudowane 3 portale:
o Sklep internetowy,
o Portal prasowy,
o Portal ogólno informacyjny z rozwarstwieniem na lokalność danych (dla
miast),
 Użytkownik nie może odczuć, że jego działalność jest w jakikolwiek sposób śledzona
i analizowana,
 System powinien efektywnie zbierać informację o użytkownikach z portali, które
obsługuje,
 Profil musi zostać przygotowany w uporządkowanej wersji elektronicznej z
możliwością pobierania i aktualizowania go przy pomocy Web Services,
 Profil powinien zawierać następującą informację:
Informacja
Kto?
Gdzie?
Czym się interesuje?
2005 © ZPI
Pola profilu
Imię Nazwisko, Nick sieciowy
Status społeczny, płeć, stan cywilny, wykształcenie, zarobki
Wiek
Stan zdrowia
Miasto, Wielkość miasta, Kod pocztowy, adres IP
Informacja podana w postaci słów kluczowych
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”

Profil
powinien
być
bardzo
precyzyjny.
prawdopodobieństwo jego wiarygodności
Powinno
zostać
określone
Wymagania co do budowy portali
 Portale powinny zapewniać różnego rodzaju zabawki, gadżety, które będą stanowiły
element za pomocą, którego system będzie gromadził informacje o użytkowniku,
 Funkcjonalność portalu powinna uwzględniać charakterystykę użytkownika zadaną w
rozdziale „Charakterystyka statystycznego użytkownika portalu”
 Portal powinien umożliwiać łatwa nawigację,
 Portal powinien wspierać użytkownika zgodnie z jego przeznaczeniem (np. sklep
internetowy - )
 Portal powinien być w łatwy sposób zarządzany, tak żeby osoby redagujące
wszelaką zawartość nie wchodzili w zagadnienia programowania pisania stron itp..
Informacja pojawiająca się na portalu powinna być archiwizowana
Specyfikacja projektowa
Architektura systemu
Koncepcję architektury Content Managment System wykorzystanego
sporządzania profili użytkowników przedstawiono na rysunku poniżej:
do
Architektura systemu CMS profilowanie
Profil
Psychologiczny
Profil
Profil
WEB Services
Wnioskowanie
Użytkownicy
Portal 1
Laptop
Słowa
kluczowe
User
Elementy
portali
Portal 2
Laptop
Portal3
User
2005 © ZPI
Przykładowy scenariusz:
Pan Jan Kowalski mieszkający w mieście o liczącym powyżej 300 tyś. mieszkańców,
będący w wieku ok. 41 lat, mający problemy ze zdrowiem (najprawdopodobniej krążenie)
zarejestrował się na portalu prasowym gazety „Co w trawie piszczy”, gdzie założył sobie
2005 © ZPI
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
również konto poczty elektronicznej. W formularzu rejestracyjnym określił, że chce dostawać
informacje dotyczącą najnowszych osiągnięć medycyny w zakresie kardiologii oraz IT.
Pewnego razu przeczytał reklamę na portalu gazety o możliwości dokonywania zakupów w
sieci oferowanej przez sklep internetowy „Manhattan”. Ze względu na pogarszający się stan
zdrowia uznał, że ułatwi mu to życie ponieważ nie będzie musiał wychodzić z domu, gdyż w
sklep internetowy oferuje nawet artykuły codziennego użytku, które zostają dostarczone już
po 3 h przez firmę kurierską.
Zgodnie z wybranymi preferencjami ujętymi w formularzu rejestracyjnym system
serwuje panu Janowi maile z reklamami sprzętu IT oraz najnowszych leków. Pan Jan od
czasu do czasu przegląda w portalu gazety treści związane z wydarzeniami lokalnymi, czyta
artykuły o dokonaniach prof. Religi. Któregoś razu natknął się na reklamę firmy
ubezpieczeniowej „…”, która to oferowała pakiet reasekuracyjny w bardzo korzystnej cenie
(Uwaga! Reklama ta pojawia się jedynie u osób, w profilu, których stwierdzono, że mają
powyżej 41 lat i poważne problemy ze zdrowiem). Pan Jan podpisał umowę z firmą
ubezpieczeniową, której transakcja ta z pewnego powodu bardzo się opłacała …
Elementy architektury systemu:
W skład architektury systemu wchodzą następujące elementy:
 Użytkownicy,
 Portale, na których znajdują się konta użytkowników,
 Centralny system „Profil” zbierających informację z baz poszczególnych portali.
Informacja ta jest porządkowana i obrabiana oraz gromadzona w następujących
bazach danych opisujących:
o Elementy portali,
o Przestrzeń słów kluczowych, na bazie których opisane są elementy portali,
o Zbiór użytkowników w powiązaniu z informacją o zainteresowaniach
ustalanych na bazie słów kluczowych,
 Serwer Web Services,
 System wnioskowania profilu psychologicznego na podstawie udostępnionych profili
w postaci (słowa kluczowe, intensywność, prawdopodobieństwo).
Z wymienionych powyżej elementów systemu poza obszarem naszego projektu znajduje się
Serwer Web Services oraz Wnioskowanie profili psychologicznych.
Centralny system „Profil”
System „Profil” jest elementem centralnym systemu CMS. Realizuje zbieranie i
obróbkę danych z poszczególnych portali. Na bazie tej tworzy profil użytkowników. Ważnym
zadaniem jest uogólnianie i próba łączenia uzyskanych danych oraz wnioskowanie o
zachowaniach.
System jest aplikacją stand-alone napisaną w języku Java operująca na
wymienionych wcześniej 3 bazach danych. Realizuje komunikację sieciową z silnikami
portali oraz udostępnia interfejs do Web Services.
Portale
Jednym z elementów systemu są portale, które oferują użytkownikowi określoną
funkcjonalność jest to m. in.:
 sklep internetowy,
 portal prasowy,
 portal ogólnoinformacyjny – z informacjami dotyczącymi poszczególnych miast
Polski.
2005 © ZPI
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Portale zostaną zbudowane przy wykorzystaniu elementu architektury J2EE tj.
technologii JSP i Servlet oraz języków skryptowych JavaScript na bazie silnika systemu CMS
„MAMBO”.
Silnik CMS jest projektem Open Source. Oferuje podstawową funkcjonalność do zarządzania
treścią, która znajduje się na stronach portali.
Profile
Można wyróżnić dwie kategorie profili ze względu na sposób gromadzenia informacji
oraz jej wiarygodności: profil jawny i profil niejawny.
Profil niejawny jest profilem, który organizuje zbierane informacje w sposób zbiorczy
– bardzo statystyczny. W szczególności użytkownik nie założył sobie konta i jego działalność
na portalu nie może być przypisana do konkretnej osoby. Pomiędzy kolejnymi interakcjami
użytkownika z portalem nie zawsze jesteśmy pewni, że jest to ta sama osoba.
Profil jawny – użytkownik założył konto na portalu. Posiadamy jego Nick – nazwę.
Po zalogowaniu do systemu otwierana jest dla niego sesja. Uzyskuje dostęp do zasobów
dostępnych jedynie członkom portalu. Możemy bardzo dokładanie określi jego działalność.
Przeważnie jesteśmy w posiadaniu (nie zawsze prawdziwych!) informacji zebranych o nim w
formularzu rejestracyjnym, a w szczególności adresu e-mail istniejącego przeważnie na
serwerze pocztowym obsługiwanych przez naszą firmę.
W naszym rozwiązaniu będziemy zajmować się budową profili jawnych.

Profil zostanie opisany w języku XML zgodnie ze zdefiniowanym formatem danych:
XML Schema;
 Profil będzie udostępniany przy pomocy Web Services opisany w języku WSDL,
przesyłany przy pomocy protokołu SOAP,
 Każdy element profilu będzie miał reprezentację probabilistyczną – zostanie
zdefiniowany jako trójka liczb:
Profil (słowa kluczowe, intensywność, prawdopodobieństwo)
Charakterystyka statystycznego użytkownika portalu
Na podstawie badań psychologicznych przeprowadzonych na zróżnicowanej grupie
użytkowników portali internetowych wyciągnęliśmy następujące wnioski:



użytkownik szuka dobrej wyszukiwarki: szybkiej i trafnej.
użytkownik nie lubi się wysilać. Wszelkie informacje skierowane do niego muszą być
jasne i łatwe do zrozumienia.
ZASADA TRZECH KROKÓW. Jeśli czegoś nie da się zrobić w trzech krokach to nie
należy robić tego wcale.
2005 © ZPI
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”












użytkownik nie lubi czytać – należy konstruować krótkie teksty
użytkownik nie lubi, gdy jest przenoszony bez jego zgody w inne miejsce
użytkownik nie lubi zmieniać strony. Jeśli czegoś nie może zrobić na tej stronie, to
tego nie zrobi.
użytkownik działa według zasady: "nic mnie to nie kosztuje, to mogę to zrobić"
użytkownik toleruję rozsądną ilość reklam. Właściwie określa zainteresowania
reklamami, bo: "jeśli już musi być jakiś spam, to niech chociaż będzie ciekawy", ale
traktuje reklamy jako zło konieczne i nie chce mieć z nimi nic wspólnego, najlepiej,
gdyby ich nie było widać
użytkownik chce, by strona pojawiała się szybko. Jeżeli może, to zmniejszy ilość
informacji do minimum - tylko to co go interesuje.
użytkownik lubi kalendarium, tzn. informacje o czymś, co go interesuje, na co może
się wybrać, zobaczyć. Nie co było, i ma być trafne i nie nachalne.
użytkownik jest leniwy i nie chce mu się przeglądać sterty gazet, ogłoszeń, plakatów i
zaproszeń. Woli mieć to podane na tacy.
użytkownik może zechcieć "sezonować" swój profil, np. czas sesji, czas wakacji, czas
świąt.
zmiana powinna być intuicyjna.
prosta grafika, komiksowa, zrozumiała na pierwszy rzut oka, a w dodatku
humorystyczna jest mile widziana.
ankiety, pytania itp. najlepiej bez przycisku wyślij, bo komu chce się jeszcze go
naciskać?
2005 © ZPI
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Struktura zarządzania i kontroli projektem
Zewnętrzna
Firma Audytowa
Sponsor
(Rada nadzorcza)
Raport dla
Sponsora
Komitet
Sterujący
Raport dla
Komitetu ster.
Kierownik
Projektu
Raport do kierownika
projektu
Pełnomocnik
ds.. jakości
Główny
Projektant
Kierownik
zespołu
Kierownik
zespołu
Kierownik
zespołu
Kierownik
zespołu
Zespół
wykonawców
Zespół
wykonawców
Zespół
wykonawców
Zespół
wykonawców
aplikacja
centralna
sklep
internetowy
portal
prasowy
portal
ogólnoinformacyjny
Sponsor
Sponsorem projektu jest właściciel dużej firmy medialnej. Firma ta jest spółką akcyjną
więc ciałem reprezentującym jest rada nadzorcza.
Kompetencje:





2005 © ZPI
Decyduje o możliwości zwiększenie budżetu.
Podejmuje ostateczną decyzję o zaprzestaniu realizacji projektu.
Decyduje o składzie reprezentantów firmy w komitecie sterującym.
Odbiera raporty o stanie realizacji projektu od komitetu sterującego.
Sponsor może powołać zewnętrzną firmę zajmującą się audytem, aby
skontrolować pracę nad projektem.
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Komitet Sterujący
Skład:

Dyrektor działu IT klienta (przewodniczący komitetu sterującego)
Jest przedstawicielem sponsora. Pełni wysokie stanowisko, więc ma
możliwość podejmowania decyzji. Jest osobą która posiada wiedzę
techniczną, która pozwoli na lepszą rozeznanie się w potencjalnych
problemach wynikających przy realizacji projektu. Zarządzanie systemem
CMS będzie w przyszłości w zakresie obowiązków działu IT gazety, więc jest
on osobą bardzo dobrze nadająca się na to stanowisko.

Z-ca redaktora naczelnego gazety (która jest własnością klienta – firmy
działającej w branży medialnej)
Jest przedstawicielem użytkowników. System CMS ma umożliwić redaktorom
gazety łatwe umieszczanie artykułów (treści). Za-ca redaktora naczelnego jest
doświadczonym dziennikarzem i zna „kuchnie zawodu‟, pozwoli mu to na
trafną identyfikacje elementów które mogą utrudnić pracę w redakcji.

Z-ca dyrektora firmy informatycznej realizującej projekt
Jest przedstawicielem wykonawców projektu. Pełni wysokie stanowisko, więc
może podejmować, kluczowe dla interesu firmy, decyzje. Np. decyzje
związane z finansowaniem projektu lub z ewentualnym przerwaniu realizacji
projektu.

Kierownik projektu
Jest przedstawicielem wykonawców projektu. Jest osobą najlepiej
zorientowana w bieżącym stanie realizacji projektu. Pełni operacyjną kontrolę
nad projektem, więc zajmuje się wdrażaniem postanowień Komitetu
sterującego. Jest osobą najlepiej rozumiejącą możliwości realizacyjne zespołu
wykonawczego i dlatego jego zdanie może być przeciwwagą w ewentualnych
postulatach dotyczących różnych ulepszeń wychodzących od strony klienta.

Główny projektant
Jest przedstawicielem wykonawców projektu. Jest specjalistą do spraw
technicznych i dlatego jego głos jest bardzo ważny. Może określić czy
ewentualne propozycje zmian są technicznie do zrealizowania.
Kompetencje:

Głównym zadaniem komitetu sterującego jest zatwierdzanie kolejnych etapów
projektu.
Po zakończeniu etapu realizacji projektu, kierownik projektu przedstawia
rezultaty pracy. Odbywa się dyskusja nad wynikiem prac. Skład komitetu jest
tak dobrany aby każdy członek mógł ocenić projekt z innej perspektywy (np.
od strony technicznej, od strony użytkownika itd.). Etap projektu jest
zatwierdzany w wyniku konsensusu.
2005 © ZPI
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”

Podejmowanie kluczowych decyzji (szczególnie w sytuacjach wyjątkowych).
Decyzje które wymagają kompetencji, które nie są w gestii kierownika
projektu, wymagają decyzji komitetu sterującego. Jeśli do realizacji projektu
będą potrzebne dodatkowe fundusze (np. na zakup sprzęty lub wynajęcie
dodatkowego specjalisty) to decyzję taką może podjąć tylko komitet sterujący.
W sytuacjach kryzysowych, komitet może rozważyć możliwość przerwania
realizacji projektu.

Zatwierdzanie planów na następne etapy.
Plany projektu systemu CMS są przygotowywane przed realizacją projektu,
ale w wyniku implementacji mogą wyniknąć pewne trudności, które mogą być
rozwiązane tylko przez zmiany w istniejących planach, co za tym idzie jest
potrzeba dostosowywania planów do aktualnego stanu realizacji i aktualnych
potrzeb klienta. Zatwierdzaniem tych planów zajmuje się komitet.

Tworzenie raportów dla rady nadzorczej wydawcy gazety.
Rada nadzorcza jest informowana o stanie postępów w realizacji projektu.
Raport zawiera informacje o wykorzystaniu budżetu i planach na przyszłość,
szczególnie szacowanie kosztów. Raporty dla sponsora są bardzo ważne
ponieważ tylko on może podjąć decyzję o ewentualnym powiększeniu
budżetu. Raporty są tworzone po zakończeniu etapu projektu.
Kierownik Projektu
1 osoba pełniąca rolę „kierownik projektu‟.
Główny Projektant
1 osoba pełniąca rolę „główny projektant‟.
Pełnomocnik ds. jakości
1 osoba pełniąca rolę „pełnomocnik ds. jakości‟.
Kierownik Zespołu
1 osoba pełniąca role „kierownik‟ i „analityk‟.
Zespól wykonawców

Zespól „Aplikacja centralna‟
4 osoby pełniące role „programista JAVA‟
2 osoby pełniące rolę „tester‟

Zespół „Sklep Internetowy‟
2 osoby pełniące role „programista JAVA‟
2 osoby pełniące role „programista Webowy‟
2 osoby pełniące rolę „tester‟
2005 © ZPI
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”

Zespół „Portal Prasowy‟
4 osoby pełniące role „programista Webowy‟
2 osoby pełniące rolę „tester‟

Zespół „Portal ogólno-informacyjny‟
4 osoby pełniące role „programista Webowy‟
2 osoby pełniące rolę „tester‟
2005 © ZPI
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Role
nazwa
wymagane kwalifikacje
zadania
uprawnienia
Ma prawo do zmian
kadrowych w składzie
zespołów. Ma głos
decydujący w zakresie
wszystkich kwestii
logistycznoadministracyjnych. W
przypadku różnego
zdania z Głównym
projektantem do niego
należy decyzja.
Decyduje o wszystkich
kwestiach technicznych.
Jego przełożonym jest
kierownik projektu, lecz
w przypadku sporu,
może odwołać się do
decyzji komitetu
sterującego.
kierownik
projektu
umiejętność zarządzania
(menadżer), dobry organizator,
autorytet wśród pracowników,
ogólna wiedza techniczna,
dyspozycyjność, elokwencja i
miła aparycja
Organizuje przydział i zarządzanie
zasobami. Ustala harmonogram
spotkań z kierownikami zespołów.
Nadzoruje operacyjnie projekt, tj.
przyjmuje sprawozdania od
kierowników, Operacyjnie zarządza
budżetem. Sporządza raporty dla
Komitetu sterującego. Dba o
porządek, ew. rozwiązuje konflikty
pomiędzy zespołami.
główny
projektant
specjalistyczna wiedza
techniczna z zakresu budowy
rozproszonych systemów
sieciowych, specjalistyczna
wiedza z zakresu profilowania w
Internecie, ogólna wiedza z
zakresu programowania i handlu
elektronicznego, duże
doświadczenie (na jego wiedzy
opierał będzie się cały zespół)
specjalistyczna wiedza
dotycząca zapewnienia jakości,
silna osobowość (często będzie
musiał walczyć o swoje racje, bo
tak naprawdę „jakość‟ jest
pojęciem nieznanym dla
programistów)
Przygotowuje techniczne plany
projektu. Opracowuje jak
zrealizować określoną w
specyfikacji funkcjonalność.
Dokonuje zmian w planach jeśli
sytuacja tego wymaga.
pełnomocnik
ds. jakości
2005 © ZPI
Stała kontrola jakości tworzonego
oprogramowania. Dba aby była
tworzona dokumentacja.
Ma obowiązek
sygnalizowania
wszystkich uchybień w
jakości przy realizacji
projektu.
Jego przełożonym jest
kierownik projektu, lecz
w przypadku sporu,
może odwołać się do
zakres
odpowiedzialności
Odpowiada z wszystkie
problemy powstające w
zespołach
projektowych np.
opróżnienia czasowe w
realizacji modułów.
Odpowiada za
wszystkie błędy
związane z fazą
projektowania systemu.
Odpowiada za jakość
oprogramowania i braki
w dokumentacji.
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
decyzji komitetu
sterującego.
Ma decydujący głos w
przypadku sporów
wewnątrz zespołu. Nie
może podejmować
decyzji kadrowych, ale
może wystąpić o takie do
kierownika projektu.
Podejmuje decyzje
związane ze sposobem
implementacji
oprogramowania
tworzonego w ramach
zespołu.
Wykonuje polecenia
kierownika zespołu.
kierownik
autorytet wśród pracowników
(wszyscy go słuchają), dobry
organizator
Planuje harmonogram pracy
wewnątrz zespołu. Organizuje
codzienne zebrania. Rozwiązuje
problemy w przypadku konfliktów
wewnątrz zespołu. Sporządza
raporty dla kierownika projektu.
projektant
specjalistyczna wiedza z
zakresu inżynierii
oprogramowania,
doświadczenie w budowie
systemów.
Przeprowadza analizę zadań
przydzielonym zespołowi.
programista
Webowy
Sprawdzony programista HTML,
CSS, PHP
programuje
programista
JAVA
sprawdzony programista języka
JAVA
programuje
Wykonuje polecenia
kierownika zespołu.
tester
Ktoś kto będzie dużo pracował
za małe pieniądze, wykonując
monotonne zadania o niewielkim
stopniu skomplikowania, czyli
najlepiej student informatyki.
Testuje powstające
oprogramowanie.
Wykonuje polecenia
kierownika zespołu.
2005 © ZPI
Odpowiada za stan
pracy w zespole.
Odpowiada przed
kierownikiem zespołu
za tworzone
oprogramowanie.
Odpowiada przed
kierownikiem zespołu
za powierzone mu
zadanie
Odpowiada przed
kierownikiem zespołu
za powierzone mu
zadanie
Odpowiada przed
kierownikiem zespołu
za powierzone mu
zadanie.
Standardy dokumentacji

Dokumentacja techniczna
Biblioteka projektu
o Repozytorium dotychczas powstałej dokumentacji,
o Repozytorium pojawiających się problemów i ich rozwiązań
Wprowadzania danych do biblioteki będą mogli wykonywać członkowie projektu z
uwzględnieniem swoich kompetencji.
Dostęp do biblioteki po autoryzacji.
Modyfikacja danych będzie możliwa jedynie za zgodą Kierownika Zespołu.

Dokumentacja sprawozdawcza
Notatki ze zebrania w grupach zespołowych
Opis tematu spotkania, zaznaczanie problemów i propozycje ich rozwiązań
Forma:
Notatka z zebrania zespołu
Data: 11 gru 2005
Temat spotkania:
Poruszane problemy
Zaproponowane rozwiązania:
Podpis Kierownika Zespołu
Lista Obecności
Raporty Kierowników zespołów
Informacje o stanie realizacji zleconego zadania i ewentualnych problemach.
Raporty Kierownika Projektu do Komitetu Sterującego
Informacje o stanie projektu:
 Szacowanie stanu projektu
 Informowanie o potencjalnych problemach
Raporty Komitetu Sterującego do Sponsora
 Informacja o zrealizowanych celach projektu
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”


Stan wykorzystania budżetu i plan wykorzystania
Harmonogram z zaznaczeniem kluczowych terminów
Szacowanie pracochłonności i kosztów.
Szacowanie pracochłonności.
Proces szacowania pracochłonności i kosztów (a zwłaszcza kosztów) projektu z
punktu widzenia klienta – podmiotu, dla którego wykonywane jest zlecenie jest
bardzo istotny. Może zaważyć na powodzeniu całego projektu, wygraniu przetargu
czy w końcu uniknięciu kar za niezrealizowanie zadania w terminie.
Trzeba pamiętać także o przyszłym serwisowaniu, czy naprawianiu błędów w
działającym systemie co jest operacja bardzo kosztowną.
Mając na uwadze te czynniki w realizowanym projekcie główną uwagę trzeba więc
będzie zwrócić na wykorzystanie technologii sprawdzonych i generujących jak
najmniejszą ilość błędów (których i tak nie da się uniknąć) np. stosowanie w każdym
możliwym przypadku wzorców projektowych.
Z drugiej strony dokładne oszacowanie pracochłonności projektu, a co za tym idzie w
pewnym sensie kosztów jest zadaniem złożonym i wymaga dużego doświadczenia
głównego projektanta. Wiąże się to z trudnościami jakie mogą wystąpić w tego typu
szacowaniach, a mianowicie:
 nieliniowy wzrost złożoności oprogramowania przy zwiększaniu zakresu projektu
 zmienność technologii – praktycznie każdy nowy projekt w innej technologii
 niematerialny charakter oprogramowania trudny z natury do oszacowania
 brak doświadczenia zespołów projektowych – zwykle młodzi ludzie
 brak dojrzałych metryk oprogramowania dobrze skorelowanych z procesem tworzenia
oprogramowania
Kluczowymi z punktu widzenia spółki jest oszacowanie: harmonogramu tzn. czasu
trwania zadań i całego projektu i zasobów ludzkich (jak duży zespół). Mając te dane
łatwo już wyznaczyć koszt całego projektu, gdyż ceny sprzętu w porównaniu do cen
licencji za oprogramowanie i tworzenia nowego oprogramowania są relatywnie tanie.
W przypadku tego projektu jedynym faktem ułatwiającym szacowanie jest w miarę
dobra znajomość specyfikacji i zarysu fazy projektowej.
Ważnymi elementami, które trzeba wziąć pod uwagę podczas projektowania są
(oprócz tych wymienionych wcześniej) są:
 czas nieproduktywny (praca w innych projektach, administrowanie, wakacje,
choroby, szkolenia)
 czynności i czas związany z zarządzaniem (spotkania, przygotowywanie raportów,
sprawozdań itp.)
 czas niezbędny dla komunikacji w zespole
Ważne jest aby szacowanie odbyło się według rożnych standardów, dzięki temu
uzyska się większą wiarygodność i możliwość skorygowania błędnych założeń.
2005 © PHE TEAM
14
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Dekomponując projekt na trzy części: portal, sklepi system centralny zmniejszy to
wpływu błędów oszacowania poszczególnych elementów na sumaryczny szacunek
całości.
Metoda COCOMO
Jako pierwszą w szacowaniu czasochłonności projektu zastosujemy metodę:
COCOMO. Na podstawie prowadzonych wcześniej podobnych projektów można
przyjąć ze współczynnik KDSI wyniesie około 20. Przyjmując że projekt jest typowy
(ponieważ używana jest typowa technologia: J2EE (stosowana obecnie bardzo
często) + relacyjna baza danych, ale nie jest to projekt mały !!!) współczynniki we
wzorze na pracochłonność (E), ilość miesięcy (T) i osób pracujących przy
projekcie(S):
E = a  (KDSI)b  d
T = 2,5 Ec
S = E/T
Przyjmują następujące wartości:
a=3, b=1.12, c=0.35 i KDSI=20.
Po podstawieniu otrzymano następujące wartości:
E=85.9, T=11.8 i S=7.2
Metoda Top-Down
Korzystając z metody Top-Down można założyć następujący typowy podział
czasochłonności między kolejne etapy budowy systemu:
Cały projekt
100%
Projektowanie
40%
Oprogramowanie
20%
Testowanie i
wdrożenie
40%
oraz podziału czasochłonności miedzy wyodrębnione podsystemy:
2005 © PHE TEAM
15
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Cały projekt
100%
Portal
informacyjny
20%
System centralny
50%
Sklep
internetowy
30%
Podsumowanie
Tabele poniżej przedstawiają podział szacowanej pracochłonności między
poszczególne zadania i etapy projektu.
Pracochłonność
Ilość miesięcy
(w osobomiesiącach)
Projektowanie (40%)
34.36
4.72
Oprogramowanie (20%)
17.18
2.36
Testowanie i wdrożenie
(40%)
34.36
4.72
Pracochłonność
Ilość miesięcy
(w osobomiesiącach)
Portal informacyjny (20%)
17.18
2.36
System centralny (50%)
42.95
5.9
Sklep internetowy (30%)
25.77
3.54
Analiza kosztów
o
Na koszt projektu składają się następujące rzeczy: koszty wynagrodzeń
o
koszty sprzętu i oprogramowania
o
koszty materiałów
o
koszty usług obcych (podwykonawców)
o
koszty szkoleń, wyjazdów itp.
Oszacowanie pracochłonności ma ważna rolę w szacowaniu kosztów projektu. Koszty
poniesione na zaprojektowanie i napisanie kodu projektu są wyższe i trudniejsze do
przewidzenia, niż wydatki poniesione na sprzęt.
Procedury komunikacji w projekcie
Komunikacja z klientem
2005 © PHE TEAM
16
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Zostaje powołane stanowisko pełnomocnika ds. kontaktów. Osoba pełniąca to stanowisko
jest pracownikiem klienta, która ma uprawnienia i środki do udzielania odpowiedzi w
kwestiach związanych z projektem.

Cała komunikacja pomiędzy firmą realizującą projekt a klientem będzie się odbywać
za pośrednictwem tej osoby. Każdy kierownik zespołu projektowego ma prawo
skierować formalne pytanie do pełnomocnika. Procedurę ilustruje diagram:
Formalne pytanie
(tryb normalny)
Kierownik zespołu
projektowego
Pełnomocnik ds..
Kontaktów
24 godziny
na reakcje
Formalna odpowiedź
(tryb normalny)
Skarga na brak
odpowiedzi od strony
pełnomocnika ds.. jakości
Decyzja
Kierownik
projektu


1. prośba o wyjaśnienie sprawy od
strony pełnomocnika
2. podniesienie problemu na forum
Komitetu Sterującego
Jeśli pełnomocnik nie udzieli odpowiedzi w czasie 24 godzin lub nie sprecyzuje w
jakim czasie jest możliwe udzielenie odpowiedzi, to kierownik zespołu projektowego
ma obowiązek poinformować kierownika projektu o problemie.
Kierownik Projektu podejmuje decyzje o dalszym rozwiązaniu problemu. Jeśli sprawa
jest bardzo istotna dla dalszych prac to podnosi ta kwestie na forum Komitetu
sterującego.
Komunikacja wewnątrz zespołu projektowego

Zostaje ustalony grafik zebrań:
rodzaj
zebrania
komitet
Sterujący
skład
tematy
dokumentacja
częstotliwość
członkowie
komitetu
sterującego
raport dla
sponsora
raz w
miesiącu, albo
w sytuacji
kryzysowej
zebranie
kierowników
kierownik
projektu,
kierownicy
zespołów
zatwierdzanie kolejnych
etapów projektu,
podejmowanie
kluczowych decyzji,
zatwierdzanie planów na
następne etapy
Analiza postępów prac,
rozwiązywanie problemów
operacyjnych, planowanie
dalszych działań.
Kierownik
sporządza
raport dla
komitetu
2 razy w
tygodniu tj w
poniedziałek i
w piątek
2005 © PHE TEAM
17
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
projektowych,
główny
projektant
wszyscy
członkowie
zespołu
projektowego
zebranie
zespołu
sterującego
Planowanie zadań na
dany dzień, sprawozdania
członków z wykonanej
pracy, rozwiązywanie
problemów wewnątrz
zespołowych.
lista obecności,
raport dla
kierownika
projektu.
Co dziennie o
9.00

Na potrzeby projektu zostaje uruchomiony portal intranetowy, w którym będę
umieszczane wszystkie informacje dotyczące projektu tj. terminy spotkań, stan
postępów prac czy informacje o problemach poszczególnych członków. Każdy
członek będzie posiadał własny blog w którym będzie mógł informować innych o
swojej pracy (ma to duże znaczenie integracyjne)

Zostaje uruchomione repozytorium dokumentacji projektowej. Członkowie zespołu
posiadający odpowiednie uprawnienia, będą mogli zapoznawać się z zawsze
aktualną dokumentacją.
Procedury zapewnienia i kontroli jakości
Zostaje zaproponowany następujący system zapewniania jakości
Definicja parametrów jakości





System powinien działać prawidłowo przy obciążeniu do 1000 odwołań/minute.
Awaria któregokolwiek z elementów (portali, sklepu, czy punktu centralnego) nie
powinna być wyczuwalna przez użytkowników innych elementów. Przez awarie
będzie rozumieć się brak jakiegokolwiek działania lub działanie niezgodne ze
specyfikacją tj. np. komunikacja za pomocą nie prawidłowego protokołu.
Interfejs użytkownika systemu profilowania, powinien być intuicyjny i zrozumiały dla
użytkownika bez wiedzy technicznej.
Stosowane protokoły komunikacyjne i architektura Web Services muszą być zgodne
z działającymi innymi systemami aby zapewnić możliwość ewentualnego łączenia
systemów.
Każdy element systemu powinien mieć pełną dokumentacje.
Nadzorowanie i Kontrola jakości
Implementacja
Definicja
jakości
testy
Produkt pośredni
+ dokumentacja
Programiści
weryfikacja
Pełnomocnik
ds.. jakości
Tester
Produkt do
poprawy
2005 © PHE TEAM
Produkt pośredni
+ dokumentacja
Produkt do
poprawy
18
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”



Każdy powstający produkt pośredni będzie testowany już na poziomie zespołu
projektowego. W skład każdego zespołu wchodzą 2 osoby przewidziane do tej
czynności. W przypadku nie pomyślnych testów produkt jest poprawiany.
Każdy ukończony moduł jest poddawany kontroli pełnomocnika ds. jakości, który
kontroluje poprawność dokumentacji i zgodność z parametrami jakościowymi
produktu.
Podczas zakończenia etapu pełnomocnik ds. jakości przedstawia raport dotyczący
powstałego produktu.
Procedury kontroli postępów i wykorzystania budżetu

Grafik spotkań i raportowania (omówione wcześniej) umożliwia kierownikom
zespołów, kierownikowi projektu i komitetowi sterującemu sprawowanie kontroli nad
pracami. System raportowania przedstawia się tak:
członkowie
zespołów
sprawozdania
codzienne z pracy
w formie ustnej
na zebraniach
Kierownik
zespołu
Sprawozdania
pisemne ze spotkań
w zespołach,
Zebrania
kierowników
Kierownik
projektu
Tygodniowe
raporty o
stanie prac
Rada
nadzorcza


Raport na
zakończenie
etapu
Komitet
sterujący
Kierownik projektu jest zobowiązany do przeprowadzania analiz wykorzystania
budżetu i postępu prac. Wykorzystuje on metodę Earned Value. Na podstawie
parametrów oblicza wskaźniki SV i CV i przedstawia je w raportach. W przypadku
odchyleni jego zadaniem jest podjąć odpowiednie działania.
Komitet Sterujący może wynająć zewnętrzną firmę audytową do skontrolowania
pracy nad projektem.
Procedury kontroli zmian

Kierownik Projektu otrzymuje propozycję zmiany w formie formalnej (na piśmie) w
zraz z uzasadnieniem. Taki wniosek jest ściśle określony i powinien zawierać: datę
złożenia, opis słowny propozycji zmiany.
2005 © PHE TEAM
19
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Wniosek o wprowadzenie zmiany
Opis zmiany:
Uzasadnienie:
____________
Data podpis



Kierownik Projektu przeprowadza analizę uwzględniającą czy wprowadzana zmiana
może wpłynąć na terminy realizacjo projektu, budżet itp.
Kierownik podejmuje decyzję w ciągu 7 dni od wpłynięcia wniosku o zmianę:
o zgodzie na wprowadzenie zmiany
o przekazaniu sprawy decyzji Komitetowi Sterującemu. Komitet podejmuje
ostateczną decyzję ew. negocjuje terminy i budżet z klientem.
o odłożeniu decyzji na późniejszy termin.
Kierownik projektu przekazuje rezultat decyzji i wyniki analizy komitetu sterującemu.
Procedury rozwiązywania problemów






każdy członek zespołu jest zobowiązany do informowania swojego przełożonego o
możliwych lub zaistniałych problemach. Zgodnie z tą zasadą członek zespołu
informuje swojego kierownika zespołu, kierownik zespołu informuje kierownika
projektu, kierownik projektu przedstawia raporty komitetowi sterującemu.
Jeśli problemy mogą być rozwiązane na poziomie zespołów to są rozwiązywane, ale
informacja o zaistniałych okolicznościach powinna trafić do kierownika projektu.
Decyzje związane z rozwiązaniem problemów i sytuacji spornych należą zawsze do
przełożonego zgodnie z określona hierarchią.
Każdy pracownik ma prawo odwołać się od decyzji przełożonego, formułując wniosek
do kierownika projektu.
Spory pomiędzy Kierownikiem Projektu, pełnomocnikiem ds. Jakości i głównym
projektantem rozstrzyga Komitet sterujący.
Kierownik projektu dysponuje pełnymi kompetencjami i środkami do rozwiązywania
sporów. Może zastosować którąkolwiek z metod, jeśli uzna że jest ona najlepsza dla
dobra projektu.
o Negocjacje i próba doprowadzenia do kompromisu.
o Zmiana w organizacji projektu, tak aby uniknąć dalszych konfliktów
o Zastosowanie kar (np. obniżenie premi)
o Wykluczenie pracownika z zespołu.
2005 © PHE TEAM
20
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Analiza i kontrola ryzyka
Występowanie ryzyk w trakcie projektu jest nieuniknione i tylko odpowiednie zarządzanie
ryzykiem zapewnia osiągnięcie celów projektu. Proces zarządzania ryzykiem jest cyklem
zapoczątkowanym na etapie planowania projektu i kontynuowanym w momencie
występowania nierozpoznanych na etapie planowania nowych czynników ryzyka. Przyczyną
występowania nowych elementów ryzyka jest m.in.:





pominięcia lub nieprzewidywalność ryzyka na etapie planowania,
wprowadzenie i zatwierdzenie zmian do projektu, których koszt, harmonogram lub
zakres mogą wpłynąć na ścieżkę krytyczną,
powstanie ryzyka na poziomie zespołu projektowego,
bieżące zdarzenia na projekcie,
zajście i konsekwencje zdarzeń związanych z odrębnymi czynnikami ryzyka.
Opis metodyki
Struktura zarządzania ryzykiem użyta w projekcie została oparta na dwufazowym modelu
składającym się z fazy zarządzania ryzykiem oraz fazy kontroli ryzyka:
Faza analizy ryzyka składa się z następujących elementów:

Identyfikacja ryzyka:
o
Risk Estimate of Situation
o
Kategoryzacja ryzyka

Estymacja ryzyka

Ewaluacja ryzyka
Faza kontroli ryzyka składa się z następujących elementów:

Planowanie ryzyka (Risk Management Plan)

Sterowanie ryzykiem

Monitorowanie ryzyka
Analiza ryzyka
Identyfikacja ryzyka
a) Risk Estimate od Situation

Cele

o wysoka niezawodność i szybkość działania systemu
o zakończenie projektu w terminie,
o nie przekroczenie budżetu,
o dostarczenie systemu spełniającego przedstawione wymagania,
o uzyskanie akceptacji przez sponsora,
o zadowolenie użytkowników,
o łatwość w utrzymaniu i skalowalność systemu.
Strategie
2005 © PHE TEAM
21
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”


o
metodyki zdobywania wymagań,
o
procedury zgłaszania zmian i zarządzania wersjami oprogramowania,
o
procedury kontroli postępów prac,
o
procedury komunikacji wewnętrznej i zewnętrznej.
Taktyki
o
wydobywanie wymagań od zleceniodawcy i użytkowników (wywiady, poznawanie
środowiska docelowego i obecnie eksploatowanych systemów),
o
kontrola postępu prac - kamienie milowe “milestones” na koniec każdego etapu,
o
kontrola kosztów (płace dla pracowników, ekspertów),
o
zarządzanie kolejnymi wersjami (serwer CVS),
o
zbieranie opinii od przyszłych użytkowników i wczesne testowanie wydajności,
funkcjonalności i interfejsów.
Środki
o
terminy zakończenia etapów,
o
budżet projektu,
o
godziny pracy zespołów projektowych i dostępność pracowników,
b) Kategoryzacja ryzyka
Zastosowanie kategoryzacji według głównych czynników ryzyka:



Czasu i harmonogramu
o
zbyt ambitne oszacowanie czasów wykonania zadania,
o
zbyt mało czasu na zebrania między etapami i podejmowanie kluczowych decyzji,
o
zbyt ambitny harmonogram,
o
opóźnienia i trudności w kontaktach z użytkownikami.
Kosztów
o
zbyt optymistyczny budżet,
o
błędne oszacowanie kosztów związanych z zakupem odpowiedniej ilości sprzętu i
oprogramowania,
o
wprowadzanie zmian w wymaganiach mających wpływ na przyjętą architekturę
systemu i tym samym koszt całego rozwiązania.
Organizacji i złożoności projektu
o
zbyt sztywny plan projektu i procedury związane z prowadzeniem projektu,
o
wysokie wymagania klienta (zgodność z wieloma różnorodnymi systemami i
protokołami),
o
zbyt duże wymagania na niezawodność.
Estymacja ryzyka
W celu estymacji ryzyka został zastosowany tzw. Wskaźnik Ryzyka (WR). Określa on udział
stwierdzonych zagrożeń w realizacji całego projektu oraz poszczególnych grupach
czynników i jest wielkością z przedziału (0;1).
2005 © PHE TEAM
22
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Kształtowanie się wskaźników cząstkowych ryzyka WR
 wielkość projektu:
o pracochłonność:
> 10000 roboczogodzin;
o czas realizacji:
w przedziale 6-12 miesięcy;
 zastosowana technologia:
o relacyjny motor bazy danych (Oracle)
o J2EE

WRw=0.70
WR = 0.40
WR = 0.30
WRt=0.45
WR= 0.1
WR= 0.35
zaangażowanie użytkownika:
WRu=0.30
o postawa użytkownika: częściowe zaangażowanie i współpraca WR= 0.20
o udział użytkownika w zespole realizacyjnym i testowym:
użytkownicy kluczowi
WR= 0.10
Globalny wskaźnik ryzyka dla całego projektu:
WRg
WRw + WRt + WRu
= ------------------------------------------------ = 0.48
3
Wartości wskaźnika ryzyka cząstkowego WR dla tego projektu oznaczają, że charakteryzuje
się dużym ryzykiem globalnym (WRg = 0.48) z uwagi na:
 bardzo duże ryzyko ze względu na wielkość przedsięwzięcia informatycznego (WRw=
0.70)
 wysokie ryzyko związane z technologiami informatycznymi (WRt =0.45)
 średnie ryzyko ze względu na zaangażowanie użytkownika w przebieg prac
realizacyjnych nad systemem (WRu= 0.3)
Ewaluacja ryzyka
W celu ewaluacji ryzyka zastosowano tzw. miękkie podejście i wybrano najbardziej
prawdopodobne czynniki ryzyka mające jednocześnie znaczny wpływ na dalsze losy
projektu:
Czynnik ryzyka
Konsekwencje
Zbyt ambitne oszacowanie
czasów wykonania zadania
Konieczność ponownego szacowania i układania
harmonogramu, niedostarczenie systemu na czas
Zbyt optymistyczny budżet
(błędne oszacowanie kosztów
związanych z zakupem
odpowiedniej ilości sprzętu
i oprogramowania)
Przekroczenie budżetu, dodatkowe koszty
Zbyt duże wymagania na
niezawodność
Ponowne projektowanie architektury systemu
(serwerów, modelu danych)
Nowy sprzęt i oprogramowanie
trudne w konfiguracji (serwery
bazodanowe i aplikacyjne)
Zwiększenie kosztów (związanych z dodatkowymi
pracownikami) i wydłużenie czasu projektu
2005 © PHE TEAM
23
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Kontrola ryzyka
Planowanie ryzyka
Risk Managment Plan (Plan Zarządzania Ryzykiem)
1
Zbyt optymistyczne
oszacowanie czasów
wykonania
poszczególnych
zadań i przesunięcia
terminów ukończenia
etapów
Krytyczna
Prawdopodobieństwo
Małe
2
Zbyt mało czasu na
zebrania między
etapami i
podejmowanie
kluczowych decyzji
Wysoka
Średnie
Czynnik ważny z punktu widzenia
strategicznego,
od
strony
prowadzenia projektu, może zaważyć
na
uzyskaniu
wymaganej
funkcjonalności,
niezawodności
systemu;
3
Niedostępność i
awarie środowiska
tworzenia projektu
(komputerów,
serwerów
bazodanowych,
aplikacyjnych, sieci
komputerowej)
Średnia /
Wysoka
Małe
Może mieć różny wpływ na cel
związany z zakończeniem projektu w
terminie (w zależności od czasu
trwania awarii, może to jednorazowe
zawieszenia serwerów wymagające
restartu, jak również dłuższe awarie
wymagające wymiany sprzętu na
nowy
i
ponownego
harmonogramowania
prac),
prawdopodobieństwo
wystąpienia
awarii środowiska jest małe ze
względu na wykorzystanie sprzętu
czołowych dostawców (Sun, BEA,
Oracle) o stabilnej pozycji na rynku i z
dużym wsparciem technicznym;
4
Utrata
fragmentów Wysoka
kodu,
fragmentów
specyfikacji projektu
(awarie
serwerów
CVS);
Małe
Istotny wpływ na koszt i zakończenie
projektu w terminie, ponieważ może
być
potrzeba
ponownego
projektowania
i
implementacji
fragmentu
systemu,
jednak
prawdopodobieństwo
jego
wystąpienia jest znikome ze względu
na wykonywanie kopii zapasowych;
5
Zbyt sztywny plan Wysoka
projektu i procedury
związane
z
Małe
Może mieć znaczny wpływ na termin
ukończenia
projektu,
jednak
prawdopodobieństwo zajścia jest
Nr
Czynnik ryzyka
2005 © PHE TEAM
Ważność
Wpływ na projekt
Wpływ na kluczowy cel – ukończenie
projektu w terminie, jak również niesie
ze sobą dodatkowe koszty związane z
wynagrodzeniem
za
dodatkowe
godziny pracy, może mieć znaczny
wpływ na końcową jakość systemu.
Prawdopodobieństwo zajścia tego
czynnika jest małe, ponieważ projekt
wykonywany
będzie
w
znanej
technologii i oszacowanie każdego
przedsięwzięcia nie jest rzeczą łatwą i
pewną;
24
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Nr
Czynnik ryzyka
Ważność
Prawdopodobieństwo
małe, ponieważ zespoły projektowe i
kadra kierownicza mają za sobą nie
jeden duży projekt informatyczny;
prowadzeniem
projektu
6
Wpływ na projekt
Niedyspozycyjność
Średnia
pracownika
(-ów)
(choroba,
nieszczęśliwe
przypadki);
Średnie
Wpływ na opóźnienia w projekcie
proporcjonalny do długości trwania
absencji oraz zadań powierzonych
danemu pracownikowi i waha się w
przedziale od niskiego do krytycznego
w zależności;
Dla przewidywanego okresu realizacji
projektu
(do
12
miesięcy)
prawdopodobieństwo jest średnie;
7
Niedyspozycyjność
Niska
członka
(-ów)
komitetu sterującego;
Małe
Brak istotnego wpływu na opóźnienia
projektu, chyba, że niedyspozycyjność
dotyczy kierownika projektu (problemy
z podjęciem strategicznych decyzji);
8
Braki
w Niska
pomocniczych
zasobach
(dostępność sal do
spotkań
zespołu
projektowego,
artykułów biurowych)
Problemy
z Wysoka
komunikacją
wewnętrzną;
Małe
Nieistotny wpływ na cele projektu,
istotne znaczenie dla zadowolenia i
komfortu pracy pracowników;
Małe
Istotny wpływ na wszystkie cele
projektu, ale prawdopodobieństwo
zajścia jest małe, ponieważ zespoły
są małe i składają się z osób
współpracujących
ze
sobą
od
dłuższego czasu;
10
Konflikty
interpersonalne;
Wysoka
Małe
Istotny wpływ na wszystkie cele
projektu, ale prawdopodobieństwo
zajścia jest małe, ponieważ w trakcie
współpracy w przeszłości nie miały
miejsca tego typu konflikty;
11
Opóźnianie
trudności
kontaktach
użytkownikami
lub Wysoka
w
z
Małe
Wpływ zarówno na ukończenie
projektu w terminie, jak również na
zadowolenie
klienta,
może
powodować nieścisłości w specyfikacji
wymagań;
12
Sprzęt
i Wysoka
oprogramowanie
trudne w konfiguracji
i utrzymaniu (serwery
bazodanowe
i
aplikacyjne, itp.)
Średnie
Wywiera istotny wpływ na zadowolenie
klienta, może on wystąpić w końcowej
fazie, podczas integracji, instalacji i
konfiguracji systemu i powodować
przesunięcie oddania systemu do
użytku, prawdopodobieństwo jego
zajścia mimo dużego wsparcia
technicznego ze strony dostawców
jest średnie, ze względu na
wykorzystanie nowych, niezbadanych
9
2005 © PHE TEAM
25
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Nr
Czynnik ryzyka
Ważność
Prawdopodobieństwo
Wpływ na projekt
i niewykorzystywanych dotąd w
Polsce na tak szeroką skalę nowych
technologii
Strategia zapobiegania i minimalizacji czynników ryzyka
Poniżej, dla każdego z wymienionych w poprzednim punkcie czynników ryzyka zostały
przedstawione proponowane działania zmierzające do zredukowania szans wystąpienia oraz
minimalizacji skutków wystąpienia czynników ryzyka, zawierające dla każdego z czynników
ryzyka plan implementacji:
a) Dla czynników ryzyka związanych z przekroczeniem czasu wykonania projektu lub
brakiem czasu na spotkania w zespołach projektowych proponowanym podejściem
jest redukcja ryzyka poprzez takie ułożenie harmonogramu działań, aby bezpiecznie
planować terminy z odpowiednim wyprzedzeniem (np. kilkudniowym w stosunku do
całego etapu);
b) Ryzyko awarii środowiska można rozpatrywać w kontekście kilku aspektów; przed
awarią serwera bazodanowego i aplikacyjnego zabezpieczanie polega na
redundancji (kilka równorzędnych serwerów działających równocześnie), awarię stacji
roboczych może być zminimalizowana poprzez wykorzystanie maszyn dobrej jakości
od renomowanych dostawców oferujących wsparcie techniczne (Sun, Hewlett
Packard);
c) Przed ryzykiem utraty danych zabezpieczamy się poprzez wykonywanie
systematycznie kopii zapasowych. Każdy pracownik ma oprogramowanie MS Visual
Source Safe i własne konto na serwerze służącym do kontroli wersji, poza tym
utrzymuje na swojej stacji roboczej kopię wykonanej pracy;
d) Czynnik ryzyka związany ze zbyt optymistycznym oszacowaniem kosztów zakupu
wymaganego sprzętu i oprogramowania jest minimalizowany poprzez utrzymywanie
odpowiednio wysokiej marży zysku i możliwości pokrycia nieoczekiwanych wydatków;
e) W celu zredukowania ryzyka niedyspozycyjności pracowników zespołu projektowego
– podobnie jak w punkcie pierwszym - każdy etap planowany będzie z kilkudniowym
wyprzedzeniem, który ma kompensować krótkie nieobecności pracownika. Przy
dłuższej niedyspozycyjności pracownika (nieszczęśliwy przypadek, dłuższa choroba)
przewiduje się zatrudnienie nowego pracownika; dlatego każdy zobowiązany jest na
bieżąco dokumentować swoją pracę po to, aby jego obowiązki mogły być w każdej
chwili przekazane innemu pracownikowi;
f) Prawdopodobieństwo wystąpienia czynnika ryzyka związanego z niedoborem w
pomocniczych zasobach (typu art. biurowe) przeniesione zostało na klienta,
natomiast problem z dostępnością sal zostanie zminimalizowany poprzez
przygotowanie na początku projektu grafiku spotkań oraz procedury rezerwacji sal;
g) Ryzyko związane z trudnościami w konfiguracji i utrzymaniu systemu w trakcie
trwania projektu, przenosimy na dostawców sprzętu i oprogramowania, którzy
dysponują szerokim wsparciem technicznym. Po zakończeniu projektu w odniesieniu
do konfiguracji i utrzymania systemu produkcyjnego ryzyko to zostanie przeniesione
bezpośrednio na klienta.
Zasoby służące zapobiegania ryzyku
2005 © PHE TEAM
26
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Podstawowym zasobem przypisywanym w planie zapobiegania ryzyka jest czas (marginesy czasowe w planowaniu terminów); koszt zależny jest od kilku czynników,
przede wszystkim od ilości czasu, liczby i stawek pracowników, których musimy
opłacić.
Innym zasobem są redundantne serwery bazodanowe i aplikacyjne, jak również czas
i środki finansowe związane z procedurą wykonywania kopii zapasowych i replikacji
danych. Zasobami, które są niezbędne w celu redukcji awarii środowiska pracy jest
wykorzystywanie sprzętu wysokiej jakości (stacje robocze HP, UPS-y). Łączny koszt
wymienionych zasobów sprzętowych można dosyć łatwo oszacować znając ceny
dostępnych produktów i rozwiązań.
Zasoby służące zapobiegania ryzyku
Dla czynników ryzyka zebranych w trzy grupy sformułowano następujące kryteria
sukcesu zapobiegania czynników ryzyka:
a) Dla czynników związanych z przekroczeniem terminów, ponownym
harmonogramowaniem zadań jest nie przekroczenie założonych marginesów
czasowych dla zadań i etapów o więcej niż 4 - 6 dni.
b) Dla czynników ryzyka związanych z awarią środowiska będzie to niezakłócona
praca zespołu z przyczyn technicznych (czas awarii 2 godziny).
c) Dla czynnika ryzyka utraty fragmentów kodu lub danych będzie możliwość
odtworzenia danego fragmentu kodu w przeciągu nie dłużej niż 2 godzin oraz
odtworzenia danych sprzed stanu przynajmniej 2 godzin.
Regresja ryzyka
Analiza ryzyka będzie powtórzona w punktach końcowych każdego etapu w ramach
jego podsumowania. Analiza dotychczasowego przebiegu pracy pozwoli zauważyć
nowe czynniki ryzyka, które nie zostały uwzględnione we wstępnej analizie ryzyka.
Projekt będzie składał się z etapów:
Planowania i analizy,
Projektowania,
Budowania,
Testów,
Wdrożenia.
Narzędziem, które będzie wykorzystywane do analizy ryzyka, będzie omówiony
wcześniej wskaźnik ryzyka WR. Na jego podstawie można dla realizowanego
projektu uwzględnić ogólny wpływ ryzyka realizacji projektu na jego budżet i
harmonogram przez dodanie do wyliczonych wielkości marginesu bezpieczeństwa:
Wskaźnik ryzyka
Mały
Średni
Duży
Bardzo duży
Margines bezpieczeństwa
15%
20%
25%
40%
Poniżej znajduje się Plan Ryzyka wyrażony wartością w skali 0 (najniższy poziom
ryzyka) do 5 (najwyższy poziom ryzyka).
2005 © PHE TEAM
27
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Nr
etapu
Zarzą Prac
Wydajnoś Organizacj
Metod
dzani own
ć
a
yka
e
icy
Plan
Budżet
1
4
4
2
3
3
1
2
2
3
4
2
1
2
2
2
3
2
3
2
1
1
2
2
4
2
2
3
1
1
3
1
5
1
2
3
1
1
3
1
Suma współczynników w tabeli = 73;
Maksymalny wynik = liczba kolumn * liczba wierszy * max. współczynnik = 175
Ryzyko projektu = Suma / Maksymalny wynik = 41%
Dla przedstawionego planu ryzyka obliczony łączny współczynnik ryzyka wynosi
41%. Oznacza to, że przedsięwzięcie to cechuje się średnim poziomem ryzyka. Dla
takiego poziomu ryzyka planowane czasy zadań, etapów i koszt projektu powinny
zostać pomnożone przez 3,14.
Zalecane wartości współczynników są obliczane na podstawie
współczynnika ryzyka na projektu i kształtują się następująco:





łącznego
70 % - projekt powinien zostać zarzucony;
50-70% - jak ktoś lubi ryzykować, to może się za niego wziąć;
40-50% - mnożymy czas/koszt przez 3,14;
20-40% - mnożymy czas/koszt przez 2-3;
<20% - mnożymy czas/koszt przez 1.5;
Harmonogram i budżet
Prace nad projektem zostały podzielony na 3 etapy, których cele przedstawiają się
następująco:

(ETAP I) Tworzenie wymagań, specyfikowanie oraz projekt architektury systemu
CMS;

(ETAP II) Implementacja zaproponowanych rozwiązań – podział na moduły
wykonywane przez poszczególne zespoły;

(ETAP III) Testowanie, uruchomienie systemu, integracja ze środowiskiem,
ulepszenia, podsumowanie projektu.
Czas trwania etapów oraz przewidywany budżet:
ETAP
Termin rozpoczęcia /
Przewidywany budżet
zakończenia
I
1 luty 2005 /
2005 © PHE TEAM
Rozbudowa stacji roboczych: 10000
28
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
1 kwiecień 2005
Zakup serwera do testów: 8000
Dodatkowy sprzęt i materiały: 6000
Zakup środowisk programistycznych: 10000
1 kwiecień 2005 /
II
1 lipiec 2005
III
1 lipiec 2005 /
Nadgodziny 16 osób * 1/5 etatu (600zł)
1 sierpień 2005
Koszty związane z wynajęciem firmy audytorskiej: 10000
Komunikacja: 16 osób * 30 zł * 6 m-cy
Pensje: 16 osób * 3000 zł * 2 m-ce
Przestrzeń i obsługa infrastruktury projektu: 3000 zł * 6 m-cy
Data rozpoczęcia projektu: 1 luty 2005
Data zakończenia projektu: 1 sierpień 2005
Planowany budżet : suma wyszczególnionych elementów.
Kalkulacja budżetu z podziałem na kategorie zasobów:


Ludzkie
o
Kierownik projektu;
o
Główny projektant;
o
Pełnomocnik ds. jakości;
o
4 zespoły po 4 osoby w tym 4 kierowników zespołów.
Sprzętowe
o
16 komputerów osobistych – infrastruktura istnieje. Pewne aktualizacje
poszczególnych zestawów komputerowych;
o
1 serwer obsługujący wersje testowe projektu. Serwer aplikacyjny i serwer
bazodanowy;
o
1 serwer projektowy – istnieje – wykorzystywany do obsługi infrastruktury
projektu;
o

Materiały eksploatacyjne, drobne urządzenia.
Programowe
o
2005 © PHE TEAM
Środowisko programistyczne dla języka Java na 4 stacje robocze;
29
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
Środowisko programistyczne dla tworzenia elementów architektury J2EE na 4
o
komputery;


o
Środowisko programistyczne dla języka PHP i Java Script na 8 komputerów;
o
Licencja na MS Project Manager.
Inne
o
Komunikacja w projekcie – telefony, wyjazdy na konsultacje;
o
Przestrzeń i obsługa infrastruktury projektowej;
o
Koszty swobodne dodatkowe niezaplanowane.
Dotyczące kontroli
Zewnętrzna firma audytorska.
o
Harmonogram kontraktowy
Jest
to
rozbudowany
harmonogram
negocjacyjny.
Rozszerzony
opis
etapu
I
z
uwzględnieniem szczegółowych potrzeb i preferencji klienta.
Harmonogram szczegółowy – na poziomie etapu: ETAP I.
Termin
Nazwa Zadań
1 luty – 14 Rozbudowa
luty
Budżet
sprzętu
Zgłoszenie
do
Logistyka
infrastruktury
projektowej
20 luty – 1 Określenie
marca
zakup
odpowiednich zasobów.
10 luty – 28 Przygotowanie
luty
i
Zasoby
wymagań,
dla
Kierownik,
zadeklarowanych celi strategicznych
Główny
klienta
Klient,
analitycy
projektant,
MS
Project
Manager
1 marca – Definicja specyfikacji projektowej
Analitycy,
10 marca
projektant
10 marca – Opis
20 marca
rozwiązania
–
projekt
realizowane
przez
projektant,
zespoły
architektury systemu
10 marca – Podział zadań projektowych – moduły
25 marca
Główny
Główny
poszczególne
Główny
Projektant,
Kierownik Projektu
zespoły
2005 © PHE TEAM
30
P r o j e k t C o n t e n t M a n a g m e n t S ys t e m „ P r o f i l o w a n i e ”
30 marca
Podsumowanie
etapu,
określenie
problemów.
2005 © PHE TEAM
31