1
Inżynieria oprogramowania
Tworzenie i śledzenie
harmonogramów
1
Inżynieria oprogramowania
Tworzenie i śledzenie
harmonogramów
2/32
Harmonogramowanie –
podstawowe informacje
cel → pomaga w terminowej realizacji
przedsięwzięcia
wykonanie → podział przedsięwzięcia na mniejsze
zadania, ustalenie czasu i kolejności ich
wykonania
praktyczna realizacja → możliwe wspomaganie
komputerowe, np. MsProject, Primavera
Contractor, Project Manager, Planista
3/32
Czynności wykonywane podczas
tworzenia harmonogramu
podział prac procesu wytwórczego na mniejsze zadania
określenie efektów realizacji poszczególnych zadań
ułożenie zadań w określonym porządku przewidzianym do
realizacji, zgodnie z przyjętym modelem procesu
wytwórczego i z uwzględnieniem zależności między
zadaniami
określenie pracochłonności zadań i przydzielenie na tej
podstawie czasu na realizację (data rozpoczęcia i
zakończenia)
przydzielenie do poszczególnych zadań zasobów (osoba
odpowiedzialna, pracownicy, środowisko programistyczne,
komponenty i inne)
4/32
Przyczyny opóźnień w
realizacji przedsięwzięcia
wymuszony i nierealny termin wykonania ustalony przez osobę spoza
zespołu programistów
zmiany wymagań klienta, nie uwzględnione na etapie planowania w
harmonogramie
niedoszacowanie pracochłonności przedsięwzięcia lub poszczególnych
zadań
niedoszacowanie niezbędnych zasobów (za mało sprzętu, za mały
zespół)
zagrożenia nie uwzględnione na etapie planowania
czynniki losowe powodujące nieprzewidziane trudności techniczne
nieprzewidziane kłopoty z pracownikami
nieporozumienia, słaba współpraca w zespole
niedostateczny nadzór i monitorowanie procesu wytwórczego, brak
reakcji na opóźnienia
5/32
Zależność między czasem realizacji
przedsięwzięcia a jego pracochłonnością*
zależność ma charakter nieliniowy
E = L
3
/ (P
3
∙t
4
)
E - pracochłonność w osobomiesiącach
L – liczba wierszy kodu
t - czas trwania przedsięwzięcia w miesiącach/latach
P – współczynnik wydajności, np. P=10000 dla syst. operacyjnych,
P=28000 dla aplikacji informacyjnych, zależny od m.in. dojrzałości
procesu wytw., metod zarządzania, umiejętności pracowników,
poziomu języków programowania, stos. metod inż.. oprogr.,
złożoności aplikacji, środowiska programistycznego
wniosek: można uzyskać korzyści realizując
przedsięwzięcie w dłuższym okresie ale mniejszym
zespołem
* L. Putnam, W. Myers: „Measures for Excellence”,Yourdon Press, 1992
6/32
Podział czasu realizacji
przedsięwzięcia
podział czasu pracy jest zwykle indywidualnie
dostosowywany do charakterystyki przedsięwzięcia
reguła 40-20-40 (obecnie niezalecana): analizowanie i
projektowanie oraz testowanie – po 40%, kodowanie
20%
obecnie szacuje się następująco średni nakład pracy:
planowanie: 2-3%
analizowanie wymagań: 10-25%
projektowanie: 20-25%
kodowanie: 15-20%
testowanie, usuwanie błędów: 30-40%
7/32
Typy przedsięwzięć
informatycznych
nowy projekt wg wymagań klienta
projekt koncepcyjny – nowy pomysł na produkt,
inne zastosowanie, nowa technologia
modyfikacja istniejącego produktu
(funkcjonalności, interfejs, efektywność działania)
pielęgnacja produktu
reinżynieria – częściowa lub całkowita
przebudowa odziedziczonego produktu
8/32
Stopnie rygoru pracy
swobodny → podstawowe czynności wytwórcze zgodne z
zasadami inżynierii oprogramowania, ograniczone jednak do
minimum (ograniczenia: dokumentacja, czynności
przekrojowe)
strukturalny → prace wg uniwersalnego schematu proc.
wytw., stosowane procedury zapewnienia jakości,
prowadzona dokumentacja oraz pomiary (proc. wytw. i
produktu)
ścisły → pełny schemat proc. wytw. dla zapewnienia
jakości, wykonywane czynności przekrojowe
szybkiego reagowania → stos. w nagłych wypadkach,
wykonywane tylko zadania niezbędne dla utrzymania
jakości, inne zadania (np. dokumentacja) wykonywane są
później (po oddaniu produktu użytkownikowi)
9/32
Kryteria adaptacji
analizowane w celu wyznaczenia zalecanego rygoru pracy
kryteria dla przedsięwzięcia programistycznego*
wielkość przedsięwzięcia
liczba potencjalnych użytkowników
skala skutków potencjalnej awarii (krytyczność)
trwałość produktu
stabilność wymagań
łatwość komunikacji między twórcą a klientem
stopień dojrzałości stosowanej technologii
ograniczenia dotyczące efektywności produktu
różnice między systemami wbudowanymi i innymi
pracownicy
czynniki związane ze stosowaniem reinżynierii
każdemu kryterium przypisywana jest waga (1-5), gdzie 1-
wykonywane nie wszystkie czynności wytwórcze, małe wymagania
dotyczące metod pracy i dokumentacji, 5-wykonywane wszystkie
zadania wytwórcze, duże wymagania dot. metod pracy i dokumentacji
* R.S. Pressman: „Adaptable Process Model”,R. S. pressman & Associates 1999
10/32
Obliczanie wskaźnika doboru
zadań (1)
1
0
0
0
0
1,2
czynniki reinżynierii
1
1
1
1
0
1,1
współdziałanie z innymi syst.
1
1
1
1
1
1,0
pracownicy
1
0
1
1
1
1,2
systemy wbudowane/inne
1
0
1
1
0
0,8
ograniczenia efektywności
1
0
0
1
1
0,9
dojrzałość technologii
1
1
1
1
1
0,9
łatwość komunikacji
1
1
1
1
0
1,2
stabilność wymagań
0
0
1
1
0
0,9
trwałość
1
1
1
1
0
1,1
krytyczność
1
1
1
1
0
1,1
liczba użytkowników
1
1
1
1
0
1,2
wielkość przedsięwzięcia
reinży-
nieria
pielę-
gnacja
rozsze-
rzenie
nowy
koncep-
cja
iloczyn
mnożnik punktowy
waga
wartość
kryterium
11/32
Obliczanie wskaźnika doboru
zadań (2)
analiza kryteriów adaptacji i przypisanie im wartości z zakresu 1-5
analiza wag przypisanych kryteriom (0.8-1.2) i ewentualna ich zmiana
w danych warunkach realizacji przedsięwzięcia
dla każdego kryterium obliczenie iloczynu:
wartość∙waga∙mnożnik_punktowy
obliczenie wartości średniej iloczynów
wyznaczenie stopnia rygoru wg poniższej tabeli (wspomagane
doświadczeniem i analizą konkretnego przypadku - przedziały
częściowo pokrywają się):
ścisły
> 2.4
strukturalny
1.0 – 3.0
swobodny
< 1.2
stopień rygoru
wskaźnik doboru zadań
12/32
Sieć zadań
przedstawia graficznie zależności między zadaniami i
podzadaniami
zadania muszą być wykonywane w określonej
kolejności, wykonanie niektórych zadań warunkuje
wykonanie następnych
zadania mogą być wykonywane równocześnie, gdy są
niezależne od siebie a nad przedsięwzięciem pracuje
większa liczba osób
należy zidentyfikować zadania leżące na tzw. ścieżce
krytycznej procesu wytwórczego
sieć zadań może stanowić dane wejściowe do
automatycznych narzędzi generujących harmonogram
13/32
Techniki planowania i
harmonogramowania
WBS (Work Break-Down Structure)
sieciowe (PERT, CPM)
wykresy (diagramy) Gantta
14/32
Planowanie metodą WBS
przedstawia działania w sposób hierarchiczny (projekt,
podprojekt, grupa zadań, zadanie)
po określeniu najważniejszych grup zadań, dzieli się je na
bardziej szczegółowe, aż do założonego poziomu
szczegółowości
każde zadanie powinno być związane z konkretnym
rezultatem (produktem), powinno mieć przypisane zasoby
ludzkie, musi istnieć możliwość określenia czy zadanie
zostało zrealizowane
15/32
Planowanie metodą WBS -
schemat
zadanie główne
zadanie 2
zadanie 3
zadanie 1
zadanie 1.1
zadanie 1.2
zadanie 2.1
zadanie2.2
zadanie 2.3
zadanie 3.1
zadanie 3.2
zadanie 3.2.1
zadanie 3.2.2
zadanie 2.2.1
zadanie 2.2.2
16/32
Metody sieciowe
oparte są na teorii grafów
zbiór działań można przedstawić w postaci grafu
skierowanego zadań i zależności
każde zadanie ma zdefiniowany czas realizacji, moment
rozpoczęcia i zakończenia, przydzielone zasoby,
zdefiniowany poprzednik i następnik
zdarzenia (działania pozorne)→ nie zużywają czasu ani
zasobów
17/32
Podstawowe metody sieciowe
CPM (Critical Path Method) → stosowana w projektach
o zdeterminowanych czasach realizacji zadań
składowych
PERT (Programm Evaluation and Receive Technique)
→ stosowana w projektach o stochastycznych czasach
realizacji zadań składowych (nie można dokładnie
określić czasu realizacji zadania, wykorzystywane są
metody rachunku prawdopodobieństwa: wartość
oczekiwana, wariancja)
18/32
Metody sieciowe –
reprezentacja zadania
NWP
NPP
NWK
NPK
4.2
testowanie
5 d
czas realizacji
nazwa zadania
numer zadania
19/32
Czasy rozpoczęcia/zakończenia
zadania
NWP → najwcześniejszy czas rozpoczęcia
zadania
NPP → najpóźniejszy czas rozpoczęcia
zadania
NWK → najwcześniejszy czas zakończenia
zadania
NPK → najpóźniejszy czas zakończenia
zadania
20/32
Relacje między zadaniami
ZR (FS) → zadanie następne może się
rozpocząć najwcześniej po zakończeniu
zadania poprzedniego
ZZ (FF) → zadanie następne może się
zakończyć się najwcześniej po
zakończeniu zadania poprzedniego
RR (SS) → zadanie następne może się
rozpocząć najwcześniej po rozpoczęciu
zadania poprzedniego
RZ (SF) → zadanie następne może
zakończyć się najwcześniej po
rozpoczęciu zadania poprzedniego
A
B
A
B
A
B
A
B
21/32
Ścieżka krytyczna
jeżeli zadanie ma NWP=NPP oraz NWK=NPK, to jest
zadaniem krytycznym
ciąg zadań krytycznych tworzy ścieżkę krytyczną
ścieżka krytyczna określa maksymalny czas wykonania
projektu
każde opóźnienie wykonania zadania krytycznego
powoduje opóźnienie realizacji całego projektu
przyśpieszenie wykonania zadania krytycznego może
spowodować przyśpieszenie realizacji całego projektu
22/32
Ścieżka krytyczna - przykład
zadanie
wykonane
zadanie
wykonane
częściowo
23/32
Zalety i wady metod sieciowych
zalety:
pokazują logiczne zależności między
poszczególnymi zadaniami
pozwalają na określanie ścieżek krytycznych i ryzyka
wady:
nienajlepsza czytelność
trudności podczas nanoszenia poprawek
24/32
Wykres (diagram) Gantta
graficzne przedstawienie kolejności działań,
zależności między nimi, terminów rozpoczęcia i
zakończenia poszczególnych zadań, czasu ich
wykonania, wykorzystywanych zasobów
jest jedną z najpopularniejszych metod
harmonogramowania
umożliwia tworzenie różnego typu raportów,
wyznaczenie ścieżki krytycznej i wyświetlenie
projektu w widoku sieciowym
25/32
Procedura tworzenia wykresu
Gantta
określenie celu projektu
podział projektu na zadania
określenie kolejności wykonywania zadań
określenie czasów trwania zadań oraz terminów
rozpoczęcia/zakończenia
określenie zależności między zadaniami
przydzielenie zasobów dla poszczególnych
zadań
26/32
Wykres Gantta - przykład
27/32
Wykres Gantta – tryb śledzenia
28/32
Śledzenie harmonogramu-
możliwości
spotkania informacyjne zespołu, opisywanie postępów
prac i ewentualnych problemów
analiza wyników przeglądów technicznych
(wyszukiwanie błędów, sprawdzenie zgodności z
wymaganiami i inne działania mające na celu
zapewnienie jakości oprogramowania)
porównywanie planowanego i rzeczywistego czasu
rozpoczęcia/zakończenia poszczególnych zadań
ilościowa analiza postępu prac wytwórczych w oparciu
o pewne wskaźniki
pomaga w zarządzaniu zasobami i skutecznej reakcji
na zagrożenia, pomaga w zarządzaniu pracownikami
29/32
Analiza wartości uzyskanej
analiza wartości uzyskanej → earned value analysis (EVA)
pomaga w obiektywnej (ilościowej) ocenie postępu prac w
procesie wytwórczym i ewentualny wdrożeniu działań
naprawczych celem dotrzymania czasu realizacji
przedsięwzięcia
obliczenie wartości uzyskanej:
dla każdego zadania w harmonogramie ustala się pracochłonność
w osobomiesiącach lub osobodniach – BCWS
i
w analizowanym momencie wykonywania przedsięwzięcia oblicza
się planowaną pracochłonność zaplanowanych zadań BCWS (dla
zadań które wg harmonogramu powinny się już zakończyć)
obliczenie całkowitej planowanej pracochłonności (dla wszystkich
zadań): BAC=Σ(BCWS
k
)
obliczenie planowanej pracochłonności wykonanych zadań BCWP
30/32
Wskaźniki realizacji
przedsięwzięcia
I - na podstawie BCWS, BCWP, BAC:
wskaźnik wykonania harmonogramu SPI=BCWP/BCWS
wskaźnik ten opisuje tzw. efektywność wykorzystania zaplanowanego
czasu pracy, wartość bliska 1 oznacza postęp prac zgodny z
harmonogramem
odchylenie (bezwzględne) od harmonogramu SV=BCWP-BCWS
zaplanowany postęp prac = BCWS/BAC, pokazuje jaka część prac
powinna być już zrealizowana
rzeczywisty postęp prac = BCWP/BAC, pokazuje jaką część prac
faktycznie zrealizowano
II - na podstawie rzeczywistej pracochłonności wykonanych zadań ACWP
wskaźnik wykonania budżetu CPI=BCWP/ACWP (bliskie 1 oznacza
koszty pracy nieprzekraczające zaplanowanego budżetu)
odchylenie od budżetu CV=BCWP-ACWP (miara oszczędności)
31/32
Plan przedsięwzięcia
zakres przedsięwzięcia
dostępne zasoby
potencjalne zagrożenia przedsięwzięcia,
metody zapobiegania i reakcji gdy wystąpią
kosztorys przedsięwzięcia
harmonogram
podejście do procesu wytwórczego
metody zapewnienia jakości i zarządzania
zmianami
32
Dziękuję za uwagę
źródło: „Praktyczne podejście do inżynierii oprogramowania”, R.S. Pressman