Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Piotr Skwarski, Maciej Prusko MSF. Zagadnienia: Przyczyny niepowodzeń projektów informatycznych Jakie problemy może rozwiązać MSF Omówienie MSF v.3 Jak.

Podobne prezentacje


Prezentacja na temat: "Piotr Skwarski, Maciej Prusko MSF. Zagadnienia: Przyczyny niepowodzeń projektów informatycznych Jakie problemy może rozwiązać MSF Omówienie MSF v.3 Jak."— Zapis prezentacji:

1 Piotr Skwarski, Maciej Prusko MSF

2 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

3 Czym jest Framework? Framework jest zestawem dobrych praktyk Framework a metodologia Łatwość wdrożenia Restrykcyjność Framework + metodologia (np. RUP)

4 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ą

5 Cykl życia projektu IT Microsoft Operations Framework Microsoft Solutions Framework Operate Deploy Build Plan

6 Odsetek porażek w projektach IT %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 SukcesProblemyPorażka

7 Czy MSF się sprawdza? Tak, jeśli wybierzesz odpowiednią dla twojego projektu cześć MSF Duże projekty prowadzone zgodnie z MSF Visual Studio, Windows 2003, Windows XP

8 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)

9 Komponenty MSF Risk Management Discipline Process Model Team Model Project Management Discipline Readiness Management Discipline Models Disciplines

10 Komponenty MSF

11 Model procesów w MSF Zatwierdzenie planów projektu Wypuszczenie wersji beta Gotowość do wdrożenia Zakończenie wdrażania Zatwierdzenie dokumentu wymagań MSF

12 Faza wstępna Utworzenie zespołu projektowego Analiza dziedziny problemowej Wstępne oszacowanie ryzyka

13 Planowanie Wybór technologii i środowiska Dokumenty: Specyfikacja funkcjonalna Główny plan projektu Terminarz projektu

14 Koszty zmian w planie projektu Koszt względny Faza projektu Faza strategiczna Planowanie ImplementacjaTestowanieWdrażanie

15 Implementacja Kod aplikacji Dokumentacja Proces wdrażania Procedury operacyjne Podręcznik użytkownika Materiały marketingowe Aktualizacja głównego planu

16 Daily Build Budowanie kodu (kompilowalnego) w cyklu dobowym. Zalety: Wskaźnik, że zespół programistyczny funkcjonuje Uwidocznienie postępu prac Lepsza motywacja zespołu

17 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

18 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.

19 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.)

20 Testowanie Release Readiness Approved Scope Complete Project Plans Approved

21 Faza stabilizacji Wypuszczenie pilota Kod źródłowy Instrukcja instalacji Dokumentacja Raporty o błędach Aktualizacja dokumentacji projektu

22 Wdrażanie Instrukcje wdrażania Repozytorium wszystkich wersji dokumentów, kodów źródłowych, konfiguracji Raport zamknięcia projektu

23 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

24 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.

25 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

26 Łączenie ról

27 Product Management Identyfikacja i zrozumienie klienta Analiza wymagań Release Management Testing Development User Experience Program Management Product Management

28 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

29 Development Zbudowanie rozwiązania zgodnego z oczekiwaniami klienta i specyfikacją Release Management Testing Development User Experience Program Management Product Management

30 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

31 Release Management Planowanie wdrożenia Release Management Testing Development User Experience Program Management Product Management

32 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

33 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: Microsoft Operations Framework:

34 Zarządzanie ryzykiem to: Ciągłe identyfikowanie ryzyka w projekcie Ustalanie priorytetów Implementowanie strategii w cyklu oprogramowania

35 Charakterystyka zarządzania ryzykiem Obszerna – dotyczy Ludzi, Procesów i Elementów Technologicznych Stosowana podczas całego cyklu budowy oprogramowania Łatwe do przystosowania

36 Identyfikacja ryzyka Identyfikacja ryzyka dla rozwijania świadomości zespołu Plan and Schedule Analyze and Prioritize Identify Track and Report Learn Control

37 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

38 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

39 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

40 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

41 Nauka Zebranie doświadczenia i nadanie jej formy ponownego użycia Plan and Schedule Analyze and Prioritize Identify Track and Report Learn Control

42 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

43 Dodatkowe informacje Kurs Microsoftu: MSF Essentials MOC #1846 Książka: Dynamics of Software Development by Jim McCarthy, Microsoft Press


Pobierz ppt "Piotr Skwarski, Maciej Prusko MSF. Zagadnienia: Przyczyny niepowodzeń projektów informatycznych Jakie problemy może rozwiązać MSF Omówienie MSF v.3 Jak."

Podobne prezentacje


Reklamy Google