Piotr Skwarski, Maciej
Prusko

MSF

Zagadnienia:



Przyczyny niepowodzeń projektów
informatycznych



Jakie problemy może rozwiązać MSF



Omówienie MSF v.3



Jak wdrożyć MSF



MSF a MOF

Czym jest Framework?



Framework jest zestawem „dobrych
praktyk”



Framework a metodologia



Łatwość wdrożenia



Restrykcyjność



Framework + metodologia (np. RUP)

MSF



Microsoft Solutions Framework



Utworzony w 1991, ostatnie duże

zmiany w 1998 i 2003 (v3)



Związek z MOF, Microsoft Operational

Framework



Koncentruje się na zarządzaniu

infrastrukturą informatyczną

Cykl życia projektu IT

Microsoft Operations
Framework

Microsoft Solutions

Framework

Opera

te

D

ep

lo

y

Build

Pl

a

n

Odsetek porażek w projektach
IT

2000

1998

1995

1994

28%

23%

49%

26%

28%

46%

27%

40%

33%

16%

31%

53%

źródło:The Standish Group International, Extreme Chaos, The Standish Group
International, Inc., 2000

Sukces

Problemy

Porażka

Czy MSF się sprawdza?



Tak, jeśli wybierzesz odpowiednią dla
twojego projektu cześć MSF



Duże projekty prowadzone zgodnie z
MSF



www.nasdaq.com

,

www.marriott.com

,

www.ciber.co.uk



Visual Studio, Windows 2003, Windows XP

Dla kogo jest MSF?



Głównie wdrażany przy dużych
projektach



Co to jest duży projekt?



3-12 miesięcy (najczęściej 4-6) i
zespół programistyczny przynajmniej
3 osobowy (najczęściej 7-11 osób)

Komponenty MSF

Risk

Management

Discipline

Process

Model

Team

Model

Project

Management

Discipline

Readiness

Management

Discipline

Models

Disciplines

Komponent
y MSF

Model procesów w MSF

Zatwierdzenie
planów
projektu

Wypuszczenie

wersji beta

Gotowość do

wdrożenia

Zakończeni

e

wdrażania

Zatwierdzeni
e
dokumentu
wymagań

MS
F

Faza wstępna



Utworzenie zespołu
projektowego



Analiza dziedziny
problemowej



Wstępne oszacowanie
ryzyka

Planowanie



Wybór technologii
i środowiska



Dokumenty:



Specyfikacja
funkcjonalna



Główny plan projektu



Terminarz projektu

Koszty zmian w planie
projektu

K

o

sz

t

w

zg

lę

d

n

y

Faza projektu

100

80

60

40

20

Faza strategiczna

Faza strategiczna

Planowanie

Planowanie

Implementacja

Implementacja

Testowanie

Testowanie

Wdrażanie

Wdrażanie

Implementacja



Kod aplikacji



Dokumentacja



Proces wdrażania



Procedury operacyjne



Podręcznik użytkownika



Materiały marketingowe



Aktualizacja głównego planu

Daily Build

Budowanie kodu

(kompilowalnego) w cyklu

dobowym.

Zalety:



Wskaźnik, że zespół

programistyczny funkcjonuje



Uwidocznienie postępu prac



Lepsza motywacja zespołu

Wersje wewnętrzne (Internal

Releases)



„Daily builds” kończą się
wypuszczeniem działającej wersji
alpha

Wersja

wewnetrzna

n

Wersja

wewnętrzna

n + 1

Testowanie

Implementacja

Daily Builds

Czy wypuszczanie
kompilowalnej wersji
oprogramowania każdego dnia
jest możliwe?



W typowym 4 – 6 miesięcznym
projekcie nie będzie to możliwe
przez pierwsze 3 do 5 dni.



Potem jest to możliwe.

Porady odnośnie Daily Build



Używaj systemu zarządzania wersjami



Każdy pracownik pracuje lokalnie
(kopie oprogramowania są na każdym
komputerze)



Dzienny kod jest grupowany,
kompilowany i każdego ranka
publikowany



Zautomatyzuj co się da (batch files
itp.)

Testowanie

Release Readiness

Approved

Scope

Complete

Project Plans
Approved

Faza stabilizacji



Wypuszczenie
„pilota”



Kod źródłowy



Instrukcja instalacji



Dokumentacja



Raporty o błędach



Aktualizacja dokumentacji projektu

Wdrażanie



Instrukcje wdrażania



Repozytorium
wszystkich wersji
dokumentów,
kodów źródłowych,
konfiguracji



Raport zamknięcia projektu

MSF – model zespołu

Cechy:



Zespoły są małe



Współzależne i współpracujące role



Każdy członek ma jasne cele i zadania



Współdzielone zarządzanie projektem



„Zespół rówieśników” – nieograniczona
komunikacja

Integracja i motywacja
zespołu

Członek zespołu musi :



Być świadomy wpływu podejmowanych przez
siebie decyzji



Być przygotowany na uzależnienia od innych



Jasno określać swoje zaangażowanie



Informować o zagrożeniach

Zespół z czasem wypracowuje zaufanie pomiędzy
członkami zespołu.

Wspólny cel – różne wizje



Każdy członek zespołu ma własną
wizję realizacji celu



Jedna narzucona wizja może być
przyczyną współzawodnictwa w
zespole

Łączenie ról

Product Management



Identyfikacja
i zrozumienie
klienta



Analiza
wymagań

Release

Management

Testing

Development

User

Experience

Program

Management

Product

Management

Program Management



Ustalenie budżetu



Harmonogram projektu



Projektowanie

całkowitego

rozwiązania



Zapewnienie

jakości



Zapewnie usług

administracyjnych

Release

Management

Testing

Development

User

Experience

Program

Management

Product

Management

Development



Zbudowanie
rozwiązania
zgodnego
z
oczekiwaniami
klienta
i specyfikacją

Release

Management

Testing

Development

User

Experience

Program

Management

Product

Management

Testing



Zidentyfikowanie
wad i poprawienie
błędów



Testowanie
planu i podejścia



Poprawienie
jakości



Rozwój
specyfikacji testu

Release

Management

Testing

Development

User

Experience

Program

Management

Product

Management

Release Management



Planowanie
wdrożenia

Release

Management

Testing

Development

User

Experience

Program

Management

Product

Management

User Experience



Poprawa jakości



Rozwój
dokumentacji
dla systemów
wykonawczych



Interfejs
użytkownika

Release

Management

Testing

Development

User

Experience

Program

Management

Product

Management

Podsumowanie



Model zespołu nie jest gwarancją sukcesu
projektu



Struktura jest podstawą dla efektywniejszej i
pomyślnej pracy



Więcej info na:



Microsoft Solutions Framework:

http://www.microsoft.com/msf



Microsoft Operations Framework:

http://

www.microsoft.com/mof

Zarządzanie ryzykiem to:



Ciągłe identyfikowanie ryzyka w
projekcie



Ustalanie priorytetów



Implementowanie strategii w cyklu
oprogramowania

Charakterystyka zarządzania
ryzykiem



Obszerna – dotyczy Ludzi, Procesów i
Elementów Technologicznych



Stosowana podczas całego cyklu
budowy oprogramowania



Łatwe do przystosowania

Identyfikacja ryzyka



Identyfikacja ryzyka
dla rozwijania
świadomości
zespołu

Plan and

Schedule

Analyze and

Prioritize

Identify

Track

and Report

Learn

Control

Analiza i priorytezacja



Przekształcenie
danych dot. ryzyka
do formy
która umożliwi
zespołowi
określenia
priorytetów
i przydzielenie
zasobów

Plan and

Schedule

Analyze and

Prioritize

Identify

Track

and Report

Learn

Control

Planowanie



Formułowanie
strategii, planów,
działań



Zatwierdzanie
planów



Harmonogram
ryzyka
łączy się
z harmonogramem
projektu

Plan and

Schedule

Analyze and

Prioritize

Identify

Track

and Report

Learn

Control

Raportowanie



Monitorowanie stanu
i postępu



Zbieranie danych
do ewentualnych
zmian
w planach

Plan and

Schedule

Analyze and

Prioritize

Identify

Track

and Report

Learn

Control

Kontrola



Nanoszenie zmian
do projektu jeżeli
zmiany planu
zarządzania
ryzykiem są
znaczące

Plan and

Schedule

Analyze and

Prioritize

Identify

Track

and Report

Learn

Control

Nauka



Zebranie doświadczenia
i nadanie jej
formy
ponownego
użycia

Plan and

Schedule

Analyze and

Prioritize

Identify

Track

and Report

Learn

Control

Podsumowanie



Projekty kończą się niepowodzeniem
z powodów nietechnologicznych



Framework taki jak MSF zwiększa
szanse powodzenia projektu



Nie musisz używać całego MSF

Dodatkowe informacje



www.microsoft.com/msf



Kurs Microsoftu: “MSF Essentials” MOC
#1846



Książka:



“Dynamics of Software Development” by Jim
McCarthy, Microsoft Press