inżynieria oprogramowani3 TSLMEXSXGYHSNJAKOLSQLSHUNCAEADI7VGZEO7I


Inżynieria oprogramowania - 4 Slide 1

Zarządzanie przedsięwzięciami

Organizowanie, planowanie i

tworzenie harmonogramu

projektów oprogramowania

Inżynieria oprogramowania - 4 Slide 2

Cele

. Wprowadzenie do zarządzania przedsięwzięciem

programistycznym i opis jego wyróżniających się

właściwości

. Omówienie planowania przedsięwzięcia i procesów

planowania

. Pokazanie używanej przez menadżerów projektów

graficznej reprezentacji harmonogramów

przedsięwzięcia

. Omówienie notacji zagrożeń i procesu zarządzania

zagrożeniami

Inżynieria oprogramowania - 4 Slide 3

Zawartość

. Czynności zarządzania

. Planowania przedsięwzięcia

. Tworzenie harmonogramu przedsięwzięcia

. Zarządzanie ryzykiem

Inżynieria oprogramowania - 4 Slide 4

. Obejmuje działania mające na celu zapewnienie,

że oprogramowania zostanie dostarczone na czas

i zgodnie z wymaganiami odbiorcy

oprogramowania

. Zarządzanie projektem jest potrzebne ponieważ

tworzenie oprogramowania podlega

ograniczeniom budżetowym i czasowym

ustalonym przez firmę budującą oprogramowanie

Zarządzanie przedsięwzięciem

programistycznym

Inżynieria oprogramowania - 4 Slide 5

. Produkt jest nieuchwytny

. Produkt jest wyjątkowo elastyczny

. Inżynieria oprogramowania nie jest

rozpoznawana jako dyscyplina inżynierii o takim

samym statusie jak np. inżynieria maszyn

. Proces tworzenia oprogramowania nie jest

standaryzowany

. Wiele przedsięwzięć programistycznych to

projekty jednorazowe

Cechy szczególne zarządzania

programowaniem

Inżynieria oprogramowania - 4 Slide 6

. Opracowywanie oferty

. Planowanie i tworzenie harmonogramu projektu

. Szacowanie kosztów przedsięwzięcia

. Monitorowanie i ocenianie przedsięwzięcia

. Wybór i ocena personelu

. Opracowywanie raportów i prezentacji

Czynności zarządzania

Inżynieria oprogramowania - 4 Slide 7

. Działania, które nie są specyficzne wyłącznie dla

zarządzania procesem wytwarzania

oprogramowania

. Wiele technik inżynierii zarządzania

przedsięwzięciem w równej mierze daje się

zastosować do zarządzanie przedsięwzięciem

programistycznym

. Problemy napotykane w trakcie procesu

tworzenia oprogramowania są podobne do tych z

jakimi borykają się inżynierowie przy budowie

innych systemów

Wspólne elementy procesów

zarządzania

Inżynieria oprogramowania - 4 Slide 8

Obsada przedsięwzięcia

. Może być niemożliwe desygnowanie najlepszych

ludzi do pracy nad przedsięwzięciem

. Budżet przedsięwzięcia nie pozwala na zatrudnienie dobrze

opłacanego personelu

. Personel o odpowiednim doświadczeniu nie jest dostępny

. Firma oczekuje zwiększenia umiejętności pracowników podczas

realizacji przedsięwzięcia

. Menedżerowie muszą pracować zgodnie z tymi

ograniczeniami szczególnie gdy istnieje ogólny brak

wykwalifikowanej kadry IT

Inżynieria oprogramowania - 4 Slide 9

Planowanie przedsięwzięcia

. Prawdopodobnie najbardziej czasochłonne

działanie zarządzania przedsięwzięciem

. Ciągłe działanie od koncepcji wstępnej aż po

dostarczenie systemu. Plany muszą być

regularnie korygowane gdy pojawiają się nowe

informacje

. żne typy planów mogą być tworzone w celu

wspomagania głównego planu przedsięwzięcia

programistycznego

Inżynieria oprogramowania - 4 Slide 10

Typy planów przedsięwzięcia

Plan Opis

Plan jakości

Plan zatwierdzania

Plan zarządzania

konfiguracjami

Plan pielęgnacji

Plan rozwoju

umiejętności

personelu

Obejmuje procedury zapewniania jakości i

standardy obowiązujące w przedsięwzięciu

Obejmuje podejście, zasoby i harmonogram

zatwierdzania systemu

Obejmuje procedury zarządzania konfiguracjami i

używane struktury

Przewiduje się w nim wymagania stawiane

pielęgnacji systemu, jej koszty i niezbędne nakłady

Opisuje się w nim jak będą rozwijane umiejętności i

doświadczenie personelu

Inżynieria oprogramowania - 4 Slide 11

Proces planowania przedsięwzięcia

Establish the project constraints

Make initial assessments of the project parameters

Define project milestones and deliverables

while project has not been completed or cancelled loop

Draw up project schedule

Initiate activities according to schedule

Wait ( for a while )

Review project progress

Revise estimates of project parameters

Update the project schedule

Re-negotiate project constraints and deliverables

if ( problems arise ) then

Initiate technical review and possible revision

end if

end loop

Ustal ograniczenia przedsięwzięcia

Wstępnie oszacuj parametry przedsięwzięcia

Skoryguj etapy i produkty

dopóki nie zrealizowano i nie anulowano przedsięwzięcia powtarzaj

Opracuj harmonogram przedsięwzięcia

Poczekaj (chwilę)

Zbadaj postępy przedsięwzięcia

Zrewiduj oszacowanie parametrów przedsięwzięcia

Zaktualizuj harmonogram przedsięwzięcia

Renegocjuj ograniczenia i produkty przedsięwzięcia

jeśli (pojawiły się kłopoty) to

Rozpocznij przegląd techniczny i dopuszczalne poprawki

koniec jeśli

koniec powtarzaj

Inżynieria oprogramowania - 4 Slide 12

Struktura planu przedsięwzięcia

. Wprowadzenie

. Organizacja przedsięwzięcia

. Analiza zagrożeń

. Wymagania stawiane zasobom sprzętowym i

programowym

. Podział pracy

. Harmonogram przedsięwzięcia

. Mechanizmy monitorowania i składania raportów

Inżynieria oprogramowania - 4 Slide 13

Organizacja działań

. Działania w przedsięwzięciu powinny być

zorganizowane tak by można było dokonać oceny

postępów na podstawie konkretnych efektów

. Kamienie milowe (milestones) są punktami

końcowymi czynności procesu tworzenia

oprogramowania

. Produkty (deliverables) to wyniki przedsięwzięć

dostarczane klientowi

. Proces kaskadowy (waterfall) tworzenia

oprogramowania pozwala na wyraźne zdefiniowanie

postępów w postaci kamieni milowych

Inżynieria oprogramowania - 4 Slide 14

Etapy w procesie określania wymagań

Raport

wykonalności

Wymagania

użytkownika

Raport

oceniający

Projekt

architektoniczny

Wymagania

systemowe

Studium

wykonalności

Analizowanie

wymagań

Tworzenie

prototypu

Studium

projektowe

Specyfikowanie

wymagań

Czynności

Etapy (milestones)

Inżynieria oprogramowania - 4 Slide 15

Tworzenie harmonogramu

przedsięwzięcia

. Dzielenie przedsięwzięcia na zadania, szacowanie

czasu i wymaganych zasobów potrzebnych do

ukończenia każdego zadania

. Organizowanie zadań równocześnie aby

zoptymalizować wykorzystanie siły roboczej

. Minimalizowanie zależności pomiędzy zadaniami

aby uniknąć opóźnienia w sytuacji kiedy jedno

zadanie oczekuje na zakończenie innego

. Zależy od intuicji i doświadczenia menedżerów

przedsięwzięcia

Inżynieria oprogramowania - 4 Slide 16

Proces tworzenia harmonogramu

przedsięwzięcia

Zidentyfikuj

czynności

Zidentyfikuj

zależności

między

czynnościami

Oszacuj

zasoby dla

czynności

Przydziel

zasoby do

czynności

Opracuj

wykresy

przedsięwzięcia

Wymagania

stawiane

oprogramowaniu

Wykresy czynności

i wykresy paskowe

Inżynieria oprogramowania - 4 Slide 17

Problemy przy tworzeniu

harmonogramu przedsięwzięcia

. Określenie trudności problemów i kosztów rozwiązania

jest trudne

. Produktywność nie jest proporcjonalna do liczby ludzi

pracujących nad zadaniem

. Zwiększania zasobów ludzkich w opóźnionych projektach

powoduje ich dalsze opóźnienie z powodów

zwiększonych nakładów czasu na komunikację

. Zawsze zdarzają się rzeczy nieoczekiwane. Bierz pod

uwagę taką możliwość podczas planowania

Inżynieria oprogramowania - 4 Slide 18

Wykresy paskowe i sieci działań

. Graficzne notacje używane do zilustrowania

harmonogramu przedsięwzięcia

. Pokazują rozdział przedsięwzięcia na zadania.

Zadania nie powinny być zbyt krótkie. Powinny

zajmować około tygodnia lub dwóch

. Sieci działań pokazują zależności między

zadaniami i wskazują ścieżką krytyczną

. Wykresy paskowe pokazują harmonogram

odniesiony do aktualnego kalendarza

Inżynieria oprogramowania - 4 Slide 19

Czas trwania zadań i ich zależności

Task Duration (days) Dependenci es

T1 8

T2 15

T3 15 T1 (M1)

T4 10

T5 10 T2, T4 (M2)

T6 5 T1, T2 (M3)

T7 20 T1 (M1)

T8 25 T4 (M5)

T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7)

T11 7 T9 (M6)

T12 10 T11 (M8)

Zadanie Czas trwania (dni) Zależy od

T1 (M1)

T2, T4 (M2)

T3, T6 (M4)

T1, T2 (M3)

T1 (M1)

T4 (M5)

T5 (M6)

T5, T7 (M7)

Inżynieria oprogramowania - 4 Slide 20

Sieć działań

start

T2

M3

T6

Finish

T10

M7 T5

T7

M2

T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days

25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3

T9

M6

T11

M8

T12

M4

Inżynieria oprogramowania - 4 Slide 21

Diagram paskowy czynności

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1

T2

M1

T7

T3

M5

T8

M3

M2

T6

T5

M4

T9

M7

T10

M6

T1 1

M8

T12

Start

Finish

Inżynieria oprogramowania - 4 Slide 22

Przydział personelu

4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

Inżynieria oprogramowania - 4 Slide 23

Zarządzanie ryzykiem

. Zarządzanie ryzykiem jest nastawione na identyfikacją

zagrożeń i opracowanie planów zmniejszenia skutków ich

urzeczywistnienia

. Ryzyko to prawdopodobieństwo wystąpienia pewnych

niesprzyjających okoliczności

. Ryzyko związane z przedsięwzięciem dotyczy harmonogramu

przedsięwzięcia i jego zasobów

. Ryzyko związane z produktem dotyczy jego jakości i

efektywności budowy

. Ryzyko związane z przedsiębiorstwem dotyczy problemów

przedsiębiorstwa dostarczającego lub zaopatrującego się w

oprogramowanie

Inżynieria oprogramowania - 4 Slide 24

Zagrożenia procesu

Zagrożenie Typ zagrożenia Opis

Rotacja personelu

Zmiana zarządzania

Niedostępność

sprzętu

Zmiana wymagań

Opóźnienia

specyfikacji

Niedoszacowanie

Mniejsza

efektywność CASE

Zmiana technologii

Konkurencja dla

produktu

Przedsięwzięcie

Przedsięwzięcie

Przedsięwzięcie

Przedsięwzięcie i

produkt

Przedsięwzięcie i

produkt

Przedsięwzięcie i

produkt

Produkt

Przedsiębiorstwo

Przedsiębiorstwo

Doświadczony personel opuści przedsięwzięcie przed jego

ukończeniem

Nastąpi zmiana w organizacji zarządzania i priorytetów

Podstawowy sprzęt dla przedsięwzięcia nie będzie

dostarczony na czas

Liczba zmian wymagań będzie większa niż przewidywano

Specyfikacja podstawowych interfejsów nie będzie

dostępna na czas

Zbyt nisko oszacowano rozmiar systemu

Narzędzia CASE użyte do wspomagania przedsięwzięcia

nie działają tak jak oczekiwano

Technologia w której buduje się system będzie zmieniona

na nową

Przed ukończeniem naszego produktu na rynku pojawił się

konkurencyjny produkt

Inżynieria oprogramowania - 4 Slide 25

Proces zarządzania ryzykiem

. Identyfikacja zagrożeń

. Identyfikowanie zagrożeń dla przedsięwzięcia, produktu i

przedsiębiorstwa

. Analiza ryzyka

. Ocena prawdopodobieństwa i konsekwencji tych zagrożeń

. Planowanie przeciwdziałania

. Opracowanie planów unikania ryzyka lub minimalizowania ich

skutków

. Monitorowanie ryzyka

. Monitorowanie ryzyka przez całe przedsięwzięcie

Inżynieria oprogramowania - 4 Slide 26

Proces zarządzania zagrożeniami

Identyfikacja

zagrożeń

Lista

potencjalnych

zagrożeń

Lista ryzyka z

przypisanymi

priorytetami

Ocena ryzyka Plany unikania

ryzyka i plany

awaryjne

Analiza

ryzyka

Planowanie

przeciwdziałania Monitorowanie

ryzyka

Inżynieria oprogramowania - 4 Slide 27

Identyfikacja zagrożeń

. Zagrożenia technologiczne

. Zagrożenia ze strony ludzi

. Zagrożenia organizacyjne

. Zagrożenia narzędziowe

. Zagrożenia związane z wymaganiami

. Zagrożenia związane z oszacowaniami

Inżynieria oprogramowania - 4 Slide 28

Zagrożenia i ich typy

Niedoszacowano czasu niezbędnego do tworzenia oprogramowania

Niedoszacowano częstości napraw usterek

Niedoszacowano rozmiaru oprogramowania

Szacowanie

Zaproponowano zmiany wymagań które prowadzą do poważnej korekty

projektu; klienci nie są w stanie zrozumieć wpływu zmian wymagań Wymagania

Kod generowany przez narzędzia CASE jest nieefektywny; nie da się

zintegrować narzędzi CASE Narzędzia

Firma jest reorganizowana tak, że inni członkowie zarządu są teraz

odpowiedzialni za przedsięwzięcie; problemy finansowe firmy powodują

redukcję budżetu przedsięwzięcia

Organizacyjne

Nie można zatrudnić personelu o odpowiednich umiejętnościach;

najważniejsi pracownicy są chorzy lub niedostępni w krytycznym okresie;

nie są możliwe niezbędne szkolenia dla personelu

Ludzie

Baza danych użyta w systemie może nie być w stanie przetwarzać tyle

transakcji na sekundę ile przewidywano; komponenty programowe których

należy użyć wielokrotnie moją defekty ograniczające ich funkcjonalność

Technologia

Możliwe zagrożenia Typ zagrożenia

Inżynieria oprogramowania - 4 Slide 29

Analiza ryzyka

. Ocena prawdopodobieństwa urzeczywistnienia

się i wagi każdego zagrożenia

. Prawdopodobieństwo może być bardzo niskie,

niskie, umiarkowane, wysokie i bardzo wysokie

. Skutki urzeczywistnienia się zagrożeń mogą być

katastrofalne, poważne, znośne lub mało

znaczące

Inżynieria oprogramowania - 4 Slide 30

Analiza ryzyka

Nieistotne Średnie Kod generowany przez narzędzia CASE jest nieefektywny

Znośne Duże Niedoszacowano rozmiaru oprogramowania

Znośne Średnie Niedoszacowano częstości napraw usterek

Znośne Średnie Nie są możliwe niezbędne szkolenia dla personelu

Znośne Średnie Klienci nie są w stanie zrozumieć wpływu zmian wymagań

Znośne Duże Nie da się zintegrować narzędzi CASE

Poważne Duże Niedoszacowano czasu niezbędnego do tworzenia oprogramowania

Poważne Średnie Baza danych użyta w systemie może nie być w stanie przetwarzać tyle

transakcji na sekundę ile przewidywano

Poważne Duże Firma jest reorganizowana tak, że inni członkowie zarządu są teraz

odpowiedzialni za przedsięwzięcie

Poważne Średnie Zaproponowano zmiany wymagań które prowadzą do poważnej korekty

projektu

Poważne Średnie Komponenty programowe których należy użyć wielokrotnie moją defekty

ograniczające ich funkcjonalność

Poważne Średnie Najważniejsi pracownicy są chorzy lub niedostępni w krytycznym okresie

Katastroficzn

e Duże Nie można zatrudnić personelu o odpowiednich umiejętnościach

Katastroficzn

e Małe Problemy finansowe firmy powodują redukcję budżetu przedsięwzięcia

Konsekwencje Prawdopod

obieństwo Zagrożenie

Inżynieria oprogramowania - 4 Slide 31

Planowanie przeciwdziałania

. Rozważanie każdego ryzyka i opracowanie

strategii jego kontroli

. Strategie unikania

. Prawdopodobieństwo wystąpienia zagrożenia jest redukowane

. Strategie minimalizacji

. Wpływ zagrożenia na przedsięwzięcie lub produkt jest

redukowany

. Plany awaryjne

. Jeśli zagrożenia urzeczywistni się plany awaryjne sobie z tym

radzą

Inżynieria oprogramowania - 4 Slide 32

Strategie zarządzania ryzykiem

Zbadaj możliwość zakupu gotowych komponentów; zbadaj możliwość użycia

generatora programów

Niedoszacowany

czas tworzenia

Zbadaj możliwości zakupu bardziej wydajnej bazy danych Efektywność

bazy danych

Przygotuj krótki dokument dla menadżerów wyższego poziomu pokazujący, w

jaki sposób to przedsięwzięcie istotnie przyczynia się do osiągnięcia celów

gospodarczych

Reorganizacja

firmy

Zapisuj informacje o śladzie, aby móc ocenić wpływ zmian wymagań; w projekcie

maksymalizuj ukrywanie informacji

Zmiana

wymagań

Zastąp potencjalnie wadliwe komponenty zakupionymi komponentami o

sprawdzonej niezawodności

Wadliwe

komponenty

Zreorganizuj zespół tak aby prace poszczególnych osób bardziej się na siebie

nakładały co pomoże pracownikom zrozumieć zajęcia innych

Choroby

personelu

Ostrzeż klienta o potencjalnych kłopotach i o możliwościach opóźnień; rozważ

zakup gotowych komponentów

Problemy z

rekrutacją

Przygotuj krótki dokument dla menadżerów wyższego poziomu pokazujący, w

jaki sposób to przedsięwzięcie istotnie przyczynia się do osiągnięcia celów

gospodarczych

Problemy

finansowe

przedsiębiorstwa

Strategia Zagrożenie

Inżynieria oprogramowania - 4 Slide 33

Monitorowanie ryzyka

. Zbadaj każde zidentyfikowane zagrożenie i zdecyduj

czy staje się one bardziej lub mniej prawdopodobne

. Określ czy konsekwencje zagrożeń uległy zmianie

. Każde kluczowe zagrożenie powinno być

przedyskutowane na spotkaniach menedżerskich

Inżynieria oprogramowania - 4 Slide 34

Czynniki ryzyka

Niepowodzenie w spełnieniu uzgodnionego harmonogramu,

niepowodzenie w usuwaniu zgłoszonych usterek Szacowanie

Wiele żądań zmian wymagań, narzekania klientów Wymagania

Niechęć członków zespołu do używania narzędzi, narzekania na

narzędzia CASE, żądania silniejszych stacji roboczych Narzędzia

Plotki w firmie, brak działań menedżerów wyższego poziomu Organizacyjne

Niskie morale personelu, nieprzyjazne stosunki członków zespołu,

wolne miejsca pracy Ludzie

źne dostarczenie sprzętu lub pomocniczego oprogramowania, wiele

zgłoszonych problemów technologicznych Technologie

Potencjalne wskazówki Typ

zagrożenia

Inżynieria oprogramowania - 4 Slide 35

Główne tezy

. Dobre zarządzanie przedsięwzięciem programistycznym

jest niezbędne do osiągnięcia sukcesu przedsięwzięcia

. Nieuchwytna natura oprogramowania powoduje

problemy w zarządzaniu

. Zarządzający programowaniem odgrywają wiele ról lecz

najistotniejsze działania to planowanie przedsięwzięcia,

szacowanie i opracowywanie harmonogramu

. Planowanie i szacowanie są procesami iteracyjnymi które

kontynuowane są poprzez całe przedsięwzięcie

Inżynieria oprogramowania - 4 Slide 36

. Etap przedsięwzięcia przewidywalnym stanem gdzie

pewny formalny raport o postępach jest prezentowany

kierownictwu

. Zagrożenie może być zagrożeniem przedsięwzięcia,

zagrożeniem produktu i zagrożeniem przedsiębiorstwa

. Zarządzanie zagrożeniami zajmuje się identyfikacją

zagrożeń, które mogą wpływać na przedsięwzięcie i takim

planowaniem ażeby mieć pewność, że zagrożenie nie

przekształci się w główny problem realizacji

przedsięwzięcia

Główne tezy



Wyszukiwarka

Podobne podstrony:
Inzynieria oprogramowania w ujeciu obiektowym UML wzorce projektowe i Java iowuje
ZadanieNaZaliczenie, WAT, semestr IV, Inżynieria oprogramowania
Rafał Polak 12k2 lab8, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Spr
zagadnienia egzaminacyjne z przedmiotu inżynieria oprogramowania zIO
Inżynieria oprogramowania Diagramy ERD
2006 06 Wstęp do Scrum [Inzynieria Oprogramowania]
sciąga moja, Informatyka SGGW, Semestr 4, Inżynieria oprogramowania, Od starszego rocznika
Tworzenie oprogramowania, Semestr 5, Inżynieria oprogramowania
2007 05 Mechanizm koncepcji w języku C nowe oblicze szablonów [Inzynieria Oprogramowania]
Inżynieria oprogramowania syllabus IV niestac 07 08, Prywatne, WAT, SEMESTR IV, IO, io, Materiały od
Rafał Polak 12k2 lab9, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Spr
inżynieria oprogramowani5s 3D2LFW6JYNMO6D276CSZQV5ONUNVXOTKWFXHA3A
inżynieria oprogramowani1 2EM7Y2ON72DKTCAQF3UOSCLXHY5636FZE7C7PUQ
inżynieria oprogramowani5 G46UQE27RE6UDINZWBW2TXNEOUUYOYV2MMVZ2NI
2008 06 Java Microedition – metody integracji aplikacji [Inzynieria Oprogramowania]
Inżynieria oprogramowania II
Opracowanie na Inżynierie Oprogramowania
Przykład diagramu sekwencji, Inżynieria oprogramowania
Inżynieria oprogramowania, Studia, Informatyka, Informatyka, Informatyka

więcej podobnych podstron