1

Zarządzanie Projektem

Teleinformatycznym

dr inż. Konrad Jackowski

e-mail:

[e-mail]

C3 111

Podstawowe pojęcia

Projekt – działalność, w której zasoby ludzkie,
materialne i finansowe są organizowane w sposób
odpowiadający zakresowi pracy zadanemu w danej
specyfikacji, z uwzględnieniem ograniczeń
czasowych i kosztowych, tak aby uzyskać produkt lub
zmianę określoną przez cele jakościowe i ilościowe

Wprowadzenie

• Powody prowadzenia projektów

– Zmiana to nie jest coś, co się zdarza. To sposób

na życie, To proces, w wartość, To nie jest coś
to, co robisz, to cię zewsząd otacza

• Projekty to sposoby wprowadzania zmian w sposób

bezkonfliktowy, szybki i niezakłucający sposobu
funkcjonowania firmy

– Stworzenie, wdrożenie lub wypromowanie

nowego produktu

– Dostosowanie firmy do nowych warunków,

standardów

Specyfika projektów IT

• Liczba uruchamianych projektów IT z roku na rok

rośnie

• Liczba projektów IT zakończonych sukcesem z roku

na rok maleje

• Wciąż brak jest rzetelnych metod wymiarowania

projektów informatycznych

• Złożoność projektów IT jest bardzo duża

• Wymagania odnośnie produktu końcowego zmienia

się w trakcie realizacji projektu

• Istnieją bardzo duże kłopoty z rzetelnym

planowaniem końcowego budżetu projektu

Specyfika projektów IT

•

47% - nigdy nie używanych

•

29% - opłaconych ale nie ukończonych

•

19% - zaniechanych lub całkowicie zmienionych

•

3% - wykorzystywanych po poprawkach

•

2% - używanych bez zmian

•

??? Jakie czynniki mogą determinować sukces lub porażkę ???

*

- K. Frączkowski, Managing IT projects, Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław 2003.

Statystyczny obraz porażek

•

Dane o projektach informatycznych

pochodzą z analizy 6 700 projektów

informatycznych.

Jones C., Patterns of Software Systems Failure and Success,

International Thomson Computer Press 1996.

•

Wykorzystywana w opisie wielkość -

punkt funkcyjny to uznawana przez

Międzynarodową Organizacje

Normalizacyjną ISO miara złożoności

oprogramowania. Opiera się ona na

szacowaniu funkcjonalności poprzez

pomiar:

–

liczby wejść do i wyjść z

systemu,

–

liczby interakcji z

użytkownikiem,

–

liczby plików wewnętrznych,

–

liczby interfejsów zewnętrznych.

2

Statystyczny obraz porażek – socjologia projektu

To czynniki związane
doświadczeniem i kwalifikacjami,
czyli strukturą doświadczeń
zespołu związaną z obszarem
działalności podlegającym
informatyzacji:

– kadry kierującej

przedsięwzięciem,

– członków zespołu

projektowego,

– klienta.

socjologia projektu

14%

62%

16%

8%

0%

10%

45%

45%

0%

10%

20%

30%

40%

50%

60%

70%

przed czasem

na czas

opóźnione

zaniechane

dobra

zła

Statystyczny obraz porażek – czynniki
techniczne

Czynniki techniczne to:

–

dobór narzędzi i technologii

budowy systemu informatycznego,

–

nadzór nad wymaganiami i

zakresem przedsięwzięć,

–

możliwość ponownego

wykorzystania komponentów.

czynniki techniczne

14%

57%

20%

9%

0%

10%

75%

15%

0%

10%

20%

30%

40%

50%

60%

70%

80%

przed czasem

na czas

opóźnione

zaniechane

dobra

zła

Statystyczny obraz porażek – zarządzanie
projektem

Czynniki związane z zarządzaniem
projektem to:

– szacowanie pracochłonności,

– planowanie,

– sformalizowany sposób

śledzenia projektu,

– wysokość nakładów na

kontrolę jakości.

zarządzanie projektem

15%

61%

16%

8%

0%

15%

45%

40%

0%

10%

20%

30%

40%

50%

60%

70%

przed czasem

na czas

opóźnione

zaniechane

dobra

zła

Przyczyny porażek

Socjologia projektu

• Histeryczny optymizm - brak doświadczenia kadry zarządzającej.

• Naiwny optymizm - braku doświadczenia kadry technicznej.

• Rozgrywki wewnątrz firmy.

• Brak wewnętrznych standardów prowadzenia projektu.

Otoczenie projektu

• Wzrost konkurencyjności powodujący pojęcie się „misji niemożliwych”.

• Wprowadzenie nieoczekiwanych regulacji.

• Kryzysy związane z kondycją odbiorcy, firmy macierzystej oraz firm

kooperujących.

Przyczyny porażek

Czynniki techniczne –wymagania użytkownika

•

Tylko 50% początkowo zebranych wymagań nie zmienia się.

•

Wzrost wymagań - ok.2% miesięcznie.

•

Ok. 20% początkowych wymagań staje się zbędne do czasu ukończenia pierwszej

wersji systemu.

•

Najwięcej błędów pojawia się na etapie analizy.

Czynniki techniczne - testowanie

•

Większość metod testowania nie wykrywa więcej niż 30% błędów i sprawdza mniej niż

50% kodu.

•

W przeciętnym projekcie występuje ok. 5 błędów na każdy FP.

•

Przed oddaniem oprogramowania do użytkowania tylko ok.85% błędów jest

wykrywanych.

•

Usunięcie pozostałych jest najbardziej kosztowne.

•

Ok.5% modułów systemu zawiera 50% wszystkich błędów.

•

Ok. 7% poprawek wprowadza nowe błędy.

Przyczyny porażek

Zarządzanie projektem – szacowanie kosztów

•

Wiarygodność oszacowań staje się kluczem do pomyślnej realizacji projektu i wymaga

systematycznego doskonalenia.

•

Konkretyzacja myślenia o projekcie wymaga liczbowego wyrażania takich cech

(parametrów) projektu jak koszt działań, czas ich realizacji, pracochłonność

wykonania, liczba pracowników, potrzebne zasoby itp.

Trudności:

–

zróżnicowanie i złożoność projektów,

–

zmienność wymagań, środowiska, technologii,

–

niematerialny charakter programu,

–

niedojrzałość inżynierii oprogramowania,

–

małe doświadczenie zespołów,

–

brak dojrzałych metryk oprogramowania.

3

Zarządzanie projektami – zastosowanie wiedzy, umiejętności, narzędzi i
technik, do kolejnych działań projektowych, mających na celu realizację
zadań stojących przed zespołem projektowym.

– Identyfikację i jasne sprecyzowanie celów i jego zakresu wynikających z

wymagań stawianych przez zleceniodawcę lub potencjalnego odbiorcę

– Rozpoznanie i zarządzanie wymaganiami, obawami i oczekiwaniami

stawianymi przez wszystkich interesariuszy (stakeholders) projektu

– Efektywne balansowanie pomiędzy różnymi konkurencyjnymi czynnikami

wpływającymi na projekt

Procesy zarządzania projektem

Fazy zarz

ą

dzania

projektem nie s

ą

fazami projektu!!!

Procesy zarządzania projektem

Procesy zarządzania projektem
Po co ten skomplikowany diagram?

DILBERT® is a registered trademark of Scott Adams, Inc.

Plan kursu - wykład

•

Problematyka zarządzania projektami

•

Metodyka tworzenia systemów informatycznych

•

Zarządzanie zakresem projektu

•

Wymiarowanie projektów informatycznych

•

Dokumentowanie wymagań systemu – Volere

•

Zarządzanie czasem

•

Zarządzanie zasobami

•

Zarządzanie komunikacją

•

Zarządzanie ryzykiem

•

Zarządzanie zmianami

•

Planowanie jakości

•

Kierownik projektu

Plan kursu - projekt

• Projekt 2

– Zgłoszenie grup projektowych i tematów projektów

• Projekt 4

– Zakres projektu – cele, ograniczenia, WBS

– Wymiarowanie projektu – zasoby, koszty

• Projekt 6

– Specyfikacja wymagań użytkownika

– Harmonogram realizacji projektu

– Zasoby

• Projekt 7

– Budżet

– Analiza ryzyka

4

Zasady zaliczenia projektu zespołowego

•

W ramach zajęć projektowych studenci dzielą się na grupy dwu- lub trzyosobowe

•

Każda grupa wybiera do realizacji temat projektu teleinformatycznego. Projekty mogą dotyczyć np.:

–

Wdrożenia Zintegrowanego Systemu Informatycznego klasy ERP w przedsiębiorstwie

–

Projekt i implementację systemu informatycznego realizowanego na zamówienie klienta

•

W projekcie mogą pojawić się również elementy związane z modernizacją infrastruktury sprzętowej: sieci,

bazy serwerów itp.

•

Efektem końcowym pracy powinna być kompletna dokumentacja projektowa obejmująca:

–

Kartę projektu opisującą: opis środowiska wdrożenia, cele, zakres itd.

–

Specyfikację wymagań systemu (zalecana forma zgodna z szablonem VOLERE)

–

Plan realizacji projektu obejmujące harmonogram, zasoby itd.

–

Identyfikację ryzyka wraz z propozycjami minimalizacji ich wystąpienia oraz procedurami awaryjnymi

–

Wymiarowanie parametrów projektu (koszty, zasoby itp.) opracowana z wykorzystaniem metod opartych

o harmonogram lub metod algorytmicznych

–

Szczegółowy budżet projektu (koszty sumaryczne + zapotrzebowanie w czasie)

•

Zachęcam do wykorzystania w pracach narzędzia Microsoft Project Professional (do pobrania z MSDN)

Zasady zaliczenia przedmiotu

Ocena projektu = ocena dokumentacji

Ocena wykładu= ½ oceny projektu +

½ oceny testu zaliczeniowego

• Test zaliczeniowy odbędzie się na

ostatnim wykładzie

Literatura

Literatura podstawowa
• A Guide to the Project Management Body of Knowledge, 4th Edition, PMI,

2009.

• Robertson S., Robertson J., Mastering Requirements Process, 2nd Ed.,

Addison-Wesley 2006.

• Alexander I., Beus-Dukic L., Discovering Requirements, John Wiley, 2009
Materiały uzupełniające
• Bainey K.R., Integrated IT Project Management, Artech House, Boston, 2003.
• Jones C., Estimating Software Costs, McGraw Hill, New York 2007.
• Jones C., Software Project Management Practices: Failure Versus Success,

CrossTalk – the Journal of Defense Software Engineering, Oct 2004, pp.5-9.

• Jones C., Patterns of Software Systems Failure and Success, International

Thomson Computer Press 1996.

• Jones C., Positive and Negative Innovations in Software Engineering, IT

Metrics and Productivity Journal, April 2007.

• http://www.volere.co.uk/