Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

MSF Piotr Skwarski, Maciej Prusko.

Podobne prezentacje


Prezentacja na temat: "MSF Piotr Skwarski, Maciej Prusko."— Zapis prezentacji:

1 MSF Piotr Skwarski, Maciej Prusko

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 Solutions Framework Plan Operate
Build Deploy Microsoft Operations Framework

6 Odsetek porażek w projektach IT
Porażka Problemy Sukces 23% 49% 28% 2000 28% 46% 26% 1998 40% 33% 27% 1995 31% 53% 16% 1994 źródło:The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000

7 Czy MSF się sprawdza? Tak, jeśli wybierzesz odpowiednią dla twojego projektu cześć MSF Duże projekty prowadzone zgodnie z MSF ,www.marriott.com , 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 Models Disciplines Team Model Process Model
Risk Management Discipline Process Model Team Model Project Management Discipline Readiness Management Discipline Models Disciplines

10 Komponenty MSF

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

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
100 80 60 40 20 Koszt względny Faza strategiczna Planowanie Implementacja Testowanie Wdrażanie Faza projektu

15 Implementacja Kod aplikacji Dokumentacja Materiały marketingowe
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 Implementacja Daily Builds Testowanie

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 Project Plans Approved
Scope Complete Project Plans Approved

21 Faza stabilizacji Wypuszczenie „pilota” Raporty o błędach
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 Zespoły są małe – sprzyja komunikacji, więż i zaufanie Role w zespole – wyrażny podział odpowiedzialności. Chociaż zespołowy model składa się z sześć roli, zespół nie potrzebuje minimum sześciu ludzie. To też nie wymaga jednej osoby na roli. Punkt kluczowy jest ten, który sześć celów ma aby zostać reprezentowany na każdym zespole. Typowo, mienie co najmniej jednej osoby na roli pomaga do zapewnij, że ktoś opiekuje się zainteresowaniami każdej roli, ale nie wszystkie projekty mają korzyść napełniania każdej roli w tej modzie. Często, członkowie zespołu muszą podzielić się role. Na mniejszych zespołach, role muszą zostać podzielona przez członkostwo zespołu. Dwie zasady kierują system wielodostępowy roli. Pierwszy jest, że członkowie zespołu rozwoju nigdy nie podzielają się roli. Producenci są projektowi budowniczy i oni nie powinni zostać oderwany od ich zadania głównego. Aby dać dodatkowe role do zespołu rozwoju tylko robi to, które prawdopodobniejsze, że plany chcą pośliźnij się z powodu tych innych odpowiedzialności. Drugi przewodnia zasada ma spróbować nie łączyć role, które mają wrodzone konflikty zainteresowania. Na przykład , zarządzanie produktu i zarządzanie programami mają kolidujące zainteresowania i nie powinien zostać łączony. Zarządzanie produktu chce zaspokajać klient, podczas gdy zarządzanie programami chce dostarczyć punktualnie i na budżecie. Jeśli te role zostały łączone i klient mieli poprosić zmianę, ryzyko jest to którykolwiek zmiana nie dostanie rozważaniu tego zasługuje utrzymać klienta satysfakcja albo, że to będzie przyjęte bez rozumienia uderzenia do projektu. Mienie różni zespołowi członkowie reprezentują te role pomaga zapewnić że każdy perspektywa otrzymuje równą wagę. To jest też prawdziwe, jeśli próbując łączyć testowanie i rozwój. Zespół rówieśników – każda rola jest ważna. To umożliwia nieograniczony komunikacja między rolami, wzrosty zespołową odpowiedzialnością i wzmacnia pojęcie, że każdy z sześć jakościowych celów są jednakowo ważni i muszą zostać osiągnięty.

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. Członkowie zespołu muszą poczuć że podejnowane przez nich decyzje mają wpływ na projekt. Upoważnianie członków zespołu do wywiązywania się z przydzielnonych zobowiązań Muszą czuć że są aktywnymi niezbędnymi elementami w osiągnięciu celu. Być przygotowanym na uzależnie od innych. Chodzi o nastawienie i gotowość do zmian. Bycia gotowym do pomocy innym członkom zespołu. Jasno określać swoje zaangażowanie. Jeżeli dokładnie wiadomo kto się czym zajmuje to nie ma z tego powodu nieporozumień. To też wpływa na zaufanie w zespole. Informowanie o zagrożeniach. Informowanie wcześniej o problemach. Np że zadanie zajęło więcej niż zakładaliśmy lub że po prostu potrzebujemy pomocy może za wczasu pomóc podjąć pewnie kroki by ominąć zagrożenie. Skoro więcej niż jedna osoba jest zaangażowana działalność zespołu to sukces zespołu będzie sumą wysiłków wszystkich uczestników zespołu. Przez to że nie ma kierownika zespołu to nie ma też kontroli i czasu na kontrolę. Dlatego z czasem sam zespół wypracowuje w sobie zaufanie wobec poszczególnych człoków.

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ń
Development Program Management Testing Product Management Release Management Cluster Role Management produktu Kluczowy cel grona roli zarządzania produktu jest zaspokajany klientami. Projekty musi zaspokajać potrzebę klientów w porządku, by być pomyślny. Jednakże, po pierwsze klient musi wyraźnie zostać zidentyfikowany i jest zrozumiany! W jakichś przypadkach klient proszący rozwiązanie albo zaszedł cech może być różny od sponsora, który płaci albo popierając wysiłek. W ten sposób muszą być jasne rozróżnienie i analiza wymagań dla czynniki sukcesu dla oba przyjęć. Tylko wtedy mogą odpowiedzialności ustawienia i spotykając oczekiwania być wyznaczony do odpowiednich obszarów funkcji. To jest możliwe do spotkaj budżet i cele czasu ale nadal bądź nieudany, jeśli klient i potrzeby biznesu nie zostać spotkany. Model zespołu MSF rozdziela funkcjonalne obszary dla każdego grona roli w porządku do więcej wąsko zdefiniuj komplet odpowiedzialności, że kiedy wzięty razem często utworzyć wspólnego komplet umiejętności. Aby osiągnąć cel zadowolonych klientów, grono roli zarządzania produktu nakazuje że kilka funkcjonalnych obszarów: planowanie produktu, opłacalność, obrona i marketing. Model Team MSF v Funkcjonalni Areas Marketing Marketing Drive i wiadomości public relations, które mają uderzenie na celu klient. Wysoce zostać odróżniony więc rozwiązanie wystaje z konkurencji . Place rozwiązanie do dystrybucji, żeby klient celu mógł łatwo nabyć to. Dostarcz poparcia, żeby klienci mieli pozytywne doświadczenie kupujące i używające rozwiązanie. Opłacalność Define i utrzymaj biznesowe usprawiedliwienie dla projektu. Define i zmierz realizację opłacalności i metrykę. Klient Advocate Drive podzielony projekt i wizję rozwiązania. Manage oczekiwania klienta i komunikacje. Planning produktu Gather, analizuj i wyznacz priorytety klienta i wymagania biznesu. Perform badanie rynku, popyt rynku, konkurencyjną inteligencję / analizę. Determine metryka biznesu i criteria sukcesu. Identify wielo - - plan wypuszczenia wersji. Marketing jest procesem albo techniką promowania, sprzedawania i rozprowadzania produktu, rozwiązanie, albo usługa. Są kilka faset marketingu: Marketing szalupy, podtrzymany marketing i public relations. W ciągu cyklu życia rozwiązania, skupienia z marketing przesunie się. Znanie miejsca twojego rozwiązania w cyklu życia będzie krytyczny do wykonywania odpowiedniego poziomu działalności. W opłacalność funkcjonalnym obszarze, zarządzanie produktu dostarcza klientów, Makers Decision biznesu (BDMs), z jak zwięzły przewidujacy miara jako oni nakaż dla finansowego i sprawnego powrotu do biznesu od inwestowania w TEN 22 Model Team MSF v. 3.1 Aby skutkuje w dostarczaniu przydatnego rozwiązania, zarządzanie produktu musi zyskać wiedza o klientach biznesowych, czynnikach sukcesu i kluczowych miarach osiągalności. Proces chwytania tej wiedzy może zostać zdefiniowany jako oszacowanie opłacalności albo identyfikując krytyczne czynniki sukcesu. Wyraźnie, znając co zrobi klienta pomyślny pomaga w decydowaniu i proponowaniu odpowiednich rozwiązań. Z powiększaniem regularność, TA inwestowania zostają poddany intensywnemu badaniu i wielu IT - strona kontaktom wymagaj finansowej recenzji przed kończeniem na projektach. Przez wykonywanie costbenefit celu analiza, prawdopodobieństwo zaspokajania klienta jest powiększona. Obliczenie finansowych skutków uzupełnia rozwój biznesowego przypadku dla TEGO inwestowanie. Ten funkcjonalny obszar zawiera odpowiedzialności dla wysokiego szczebli komunikacji i zarządzanie oczekiwań klienta. Wysokiego szczeble komunikacje zawierają publiczny relacje, odprawy do starszego zarządzania / klientów, wprowadzając na rynek do użytkowników, demonstracje i szalupy produktu. Zarządzanie oczekiwań jest kluczową rolą produktu zarządzanie raz wizja jest ustawiona. To jest rozważone, by być najważniejszą rolą, ponieważ to może określ różnicę między sukcesem i niepowodzeniem. Znaczenie skutecznie zarządzania oczekiwań może zostać zilustrowane z przykładem włączając spodziewaną dostawę dziesięć cech produktu od zespołu do klienta przez pewna data. Jeśli zespół dostarcza tylko dwie cechy kiedy klient oczekuje dostawa wszystko dziesięciu, projekt będzie uważany niepowodzenie zarówno przez klienta i przez zespół. Jeśli, jednakże, zarządzanie produktu utrzymuje stałą łączność dupleksową z klient podczas długometrażowego rozwoju i okresu produkcji, zmiany mogą zostać zrobiona co do klienta oczekiwania, które mogą zapewnić sukces. Zarządzanie produktu może włącz klienta do procesu decydowania tradeoff i informuj ich z zmieniając ryzyka i inne wyzwania. W przeciwieństwie do poprzedni scenariusz, klient może oszacuj sytuację i zgódź się z zespołem ta dostawa wszystkich dziesięć cech w wyszczególniona rama czasu jest nierealistyczna i ta dostawa tylko dwóch jest zadowalająca. W tym scenariusz, dostawa dwóch cech teraz zestawia oczekiwania klienta i oba przyjęcia będą uważały, że projekt za jest sukces. Planowanie produktu identyfikuje wymagania i cecha ustawiła(s) dla wielokrotnych wersji rozwiązanie. Cel produktu planowanie ma zrobić to łatwe dla kierownika programu albo producent, by zrozumieć wymaganie rozwiązania bynajmniej ilość czasu możliwego. To powoduje pierwszego, rozumiejąc aktualne wymagania rozwiązania zupełnie — coś co potrzeby biznesu są, jak klienci użyją tego, jaki wyjścia poparcia będzie i jakie alternatywy są dostępne. Drugi, cechy, które dodałyby wartość do klienci, którzy używają rozwiązania są przeegzaminowani, takie jak zdolność, by umożliwić wejście do nowe biznesowe segmenty, integracja z innymi systemami, większą produktywnością, ulepszając od innych rozwiązań, zmniejszając koszty poparcia i tak dalej. Bazował na tej wiedzy, planista produktu może polecić określone cechy, które mogą zostać wyznaczona do każdego rozwiązania wypuszczenie i wyznacz priorytety długometrażowego listę. W rdzeniu produktu planowanie jest badaniem i analizą. Czy rozumiejąc klient i potrzeby biznesu albo rozumiejąc konkurencyjny krajobraz, to przychodzi do odpowiedniej uwagi do badania i analizy. To zapobiegnie niepotrzebne cechy od bycia zbudowany do rozwiązania. Model Team MSF v User Experience

28 Program Management Ustalenie budżetu Harmonogram projektu
Projektowanie całkowitego rozwiązania Zapewnienie jakości Zapewnie usług administracyjnych Development Program Management Testing Product Management Release Management Cluster Role zarządzania programami Skupienie roli zarządzania programami ma spotkać cel dostarczania rozwiązania w przymusach projektu. To może zostać oglądnięte jako zapewnianie, że projektowy sponsor jest zaspokajał z rezultatem projektu. Aby spotkać ten cel, zarządzanie programami posiada i jazdy plan, długometrażowy komplet i budżet dla projektu. Program zarządzanie zapewnia, że właściwe rozwiązanie jest dostarczone w odpowiednim czasie i że oczekiwania sponsora projektu są zrozumiane i są zarządzone przez projekt. Opisy wybranych funkcjonalnych obszarów są pokazane poniżej. Management projektu Track i zarządź budżet. Manage mistrz projekt plan. Proces zarządzania ryzyka Drive. Facilitate komunikację i negocjacje w zespole. Postęp Track i zarządzając stan projektu zgłaszający. Manage alokację zasobów Architecture rozwiązania Drive projektowanie rozwiązania kombinezonu. Manage wyszczególnienie funkcjonalne. Manage zakres rozwiązania i krytyczne decyzje ustępstwa. Assurance procesu Zapewnienie jakości procesu Drive. Define i poleć poprawy. Administracyjni Services Wprowadź w życie projektowe procesy zarządzania i poprzyj zespół zaprowadza w używaniu ich. Dostarcz zasięgu administracyjnych usług, by poprzeć skuteczne zespołowe działanie. 24 Model Team MSF v. 3.1 Jako właściciel planu, zarządzanie projektu zbiera wszystkie zespołowe plany, uprawomocnia ich i łączy ich do mistrza plan, który jest wyśledzony i jest doniesiony do zespołu i projektowy sponsor. Jako właściciel budżetu, zarządzanie projektu ułatwia tworzenie projektu budżet przez wymagania zasobu zebrania od wszystkiego role na zespole. Projekt zarządzanie musi zrozumieć i zgodzić się z wszystkimi decyzjami zasobu { sprzęt komputerowy, oprogramowanie, i ludzie) i musi wyśledzić faktyczny wydatek przeciw planowi. Zespół i sponsor projektu otrzymują sprawozdania stanu. W dodatku , zarządzanie projektu koordynuje zasoby, ułatwia komunikację zespołu, i pomaga jeździe krytycznym decyzjom. Dla więcej informacji na projektowe zarządzanie funkcjonalnym obszarze i podejściu MSF do projektowych odpowiedzialności zarządzania, zobacz: Architektura rozwiązania jest funkcjonalnym obszarem grona roli zarządzania programami odpowiedzialny za schemat logiczny rozwiązania i wyszczególnienia funkcjonalnego. Architektura rozwiązania skupia dalej zapewnianie, że rozwiązanie może zostać użyte przez wyszczególnionych użytkowników aby osiągnąć wyszczególnione cele z skutecznością, wydajnością i satysfakcją. Odpowiedzialności architekta rozwiązania zawierają: Driving całkowite projektowanie rozwiązania. Managing wyszczególnienie funkcjonalne. Managing zakres rozwiązania i krytyczne decyzje ustępstwa. Posiadając schemat logiczny, architektura rozwiązania dostarcza ważnego łącza między strona biznesu rozwiązania { jako reprezentował przez zarządzanie produktu w pojęciowym projektowanie) i strona technologii rozwiązania { jako reprezentował przez rozwój w fizyczne projektowanie). Czyny architektury rozwiązania jako dozorca funkcjonalnego specyfikacja. To kieruje zespół, by osiągnąć zgodę o zawartości i projektowaniu z rozwiązanie między żądaniami ich innych roli i usprawiedliwia zgodzony - dalej podejście do projektowych przyjmujących stawki. To jest też odpowiedzialne za zapewnianie traceability z cechy z powrotem do wymagań (i ostatecznie do pokolenia opłacalności), tak że wszystkie cechy mogą zostać widziana, by poprzeć stwierdzone wymagania i więc, że zespół może oszacuj uderzenie jakichś długometrażowych zmian na wartości rozwiązania. Model Team MSF v Działalności architektury rozwiązania zawierają: Create pojęcie rozwiązania i zszereguj to z architekturą przedsięwzięcia klienta; zapisz strategię wypuszczenia versioned; plany recenzji dla wymagań chwytają. Capture wymagania od architektonicznego / grupy standardów i dotycząc współdziałanie; skieruj proces schematu logicznego; dostarcz kalki mapy traceability cechy z powrotem do wymagań i korzyści; utwórz wyszczególnienie funkcjonalne; zdefiniuj aktualizacje tymczasowe . Manage zmiany do wyszczególnienia funkcjonalnego; utrzymaj mapę traceability; rozjaśnij się specyfikacja do innych zespołowych roli i do zewnętrznych przyjmujących stawki; połącz się z innym zespoły projektu na wyjściach współdziałania. Participate w procesie odpadków wysianych; zarządź oczekiwania przyjmujących stawki projektu co do zawartość rozwiązania. Dostarcz aktualizacji do zespołu architektury przedsięwzięcia; uaktualnij wymagania dla przyszłości wypuszczenia versioned. Lekarze architektury rozwiązania powinni być technicznie zabrzmieć, z obszerną podstawą z wiedza i doświadczenie i zdolność odnosić techniczne wyjścia do leżenia u podstaw potrzeby biznesu. Kiedy architekt rozwiązania może polegać na zespole rozwoju dla wiedzy specjalistycznej na określonych technologiach użytych w rozwiązaniu, oni muszą być w stanie się aby chwycić implikacje tych technicznych szczegółów bardzo szybko i rozumieją ich schowaj do grobu - relacje i ich uderzenie na środowisku, do którego rozwiązanie będzie rozmieścił. Architekt rozwiązania musi też być w stanie się, by dyskutować te uderzenia z architekci klienta, tak jak zdecydować się szybko jakieś konflikty między proponował rozwiązanie i architektura przedsięwzięcia. Zapewnienie procesu funkcjonalny obszar zarządzania programami zapewnia że projekt zespół zaadoptuje procesy to skupienie na spotykaniu całkowite projektowe jakościowe cele, z nacisk na eliminowaniu źródeł wady. Zapewnienie procesu jest odpowiedzialne za dwa główne obszary: Defining kluczowe projektowe procesy, by zostać użyty przez zespół i dostarczając rady i kierownictwo do zespołu na ich wprowadzaniu Undertaking recenzje, by uprawomocnić odniesienie i skuteczność procesów, polecając poprawy i monitorując zgodę. Zapewnienie procesu skupia się na poszły za działalnościami: Define protokoły projektu i procesy w linii z projektowym projektowaniem. Dostarczają rada i kierownictwo na efektywnym wprowadzaniu projektowych procesów; uprawomocnij zgodę z procesami; zobowiązują się recenzje kamienia milowego; poleć poprawy procesu. Korzyści zapewnienia procesu od stopnia niepodległości od projektowego zespołu więc że to może wziąć zewnętrzną perspektywę. Dla tego powodu, to często jest zarządzone od na zewnątrz zespół projektu, nawet, jeśli projektowa wielkość nie robi, że to jest pełnoetatowa rola. 26 Model Team MSF v. 3.1 To jest funkcjonalny obszar grona roli zarządzania programami, które jest odpowiedzialne dla wprowadzania projektowych procesów zarządzania i dla administracyjnego poparcia projektowego zespołu. Projektowa administracja funkcjonalny obszar zapewnia, że projektowe zespołowe narzędzia procesy, które spotykają projektową specyfikację projektową zdefiniowały przez zarządzanie projektu. To jest odpowiedzialny za zapewnianie, że projektowy zespół może działać skutecznie z minimum biurokracji. Odpowiedzialności administracji projektu zawierają: Wprowadzanie w życie projektowe procesy zarządzania i popieranie zespołu zaprowadza w używając ich. To zawiera konsolidowanie zespołowego wejścia, by utrzymać plan główny i plan i bycie obecnym zaprowadza w toku zgłaszający. Dostarczając zasięgu administracyjnych usług, by poprzeć skuteczne zespołowe działanie, takie jako planowanie spotkań, ogólnych nabywania i zarządzania kontraktu. Administracja projektu skupia się dalej: Supporting procesy zapoczątkowania projektu, takie jak skuteczna rekrutacja zespołu członkowie od trzecia strony; zarządź kontraktowe przygotowanie; zorganizuj zespół udogodnienia (przestrzeń, telefony, dostęp bezpieczeństwa i tak dalej). Establishing się stałą strukturę planowania; pomóż zespołowi zaprowadza w planowaniu i planując; skonsoliduj wejście zespołu, by utworzyć plan główny i zaplanować; załóż finansowy i postęp donoszący procesy. Assisting zespół zaprowadza w toku zgłaszający; utwórz całkowity postęp i finansowy sprawozdania. Ensuring zamknięcie wszystkich administracyjnych systemów na zakończeniu projektu. Performing ogólne administracyjne działalności poparcia takie jak planowanie spotkań, wprowadzając w życie ryzyko i procesy zarządzania wyjścia; utrzymując mistrz ryzyko listę, lista działania i tak dalej; wygenerowując finansowy i komunikaty bieżące; potrafiący zespół miejsce, by poprawić morale. Projektowa rola administracji wymaga połączenia silnego administracyjny zdolność i uwaga, by podać szczegóły z wydaj dźwięk doświadczenie w planowaniu projektu i planując techniki, jak również dobre zrozumienie polityk i wytycznych operacyjny w organizacji dostawcy. Na większym projekcie to dostarcza doskonałego okazja, by pracować obok kierunku projektu i zbuduj doświadczenie potrzebowane bezpośrednie przyszłe projekty. Model Team MSF v User Experience

29 Development Zbudowanie rozwiązania zgodnego z oczekiwaniami klienta i specyfikacją Development Program Management Testing Product Management Release Management Cluster Role rozwoju "urośnij do specyfikacji ” cel jest skupieniem dla grona roli rozwoju podczas projekt MSF. Aby odnosić sukces w spotykaniu jego jakościowy cel, rola rozwoju ma urosnąć rozwiązanie, które spotyka oczekiwania klienta i specyfikacje jako wyraził w wyszczególnienie funkcjonalne . Grono roli rozwoju przylega do rozwiązania architektura i projektowania, które, razem z specyfikacją funkcji, tworzą całkowitego specyfikacje rozwiązania. W dodatku do bycia budowniczych rozwiązania, rozwój służy zespołowi jako doradca technologii. Jako doradca technologii, rozwój dostarcza wejścia do projektowanie i decyzje selekcji technologii, jak również budując funkcjonalne prototypy aby uprawomocnić decydowanie i złagodzić ryzyka rozwoju. Jako budowniczy, rozwój dostarcza niskiego poziomu rozwiązania i projektowania cechy, ocenia wysiłek wymagał dostarczyć na tym projektowaniu i wtedy zbudował rozwiązanie. Rozwój ocenia jego własny wysiłek i plan, ponieważ to pracuje codziennie z wszystkim rozwojowym czynniki wariantu. MSF odnosi się do tego pojęcia jako wnioskowanie uprzedzające oceniające i to jest podstawowa część filozofii MSF. Jego cel ma osiągnąć wyższą jakość z plan i powiększyć odpowiedzialność tych dostarczań ocen i ich występ pracy. Technologia Consulting Functional Area Serve zespół jako doradca technologii. Evaluate i uprawomocnij technologie. Participate aktywnie w tworzeniu i przejrzyj wyszczególnienie funkcjonalne. Contribute do definiowania standardów rozwoju dla organizacji. Architektura wprowadzania i projektowanie funkcjonalny obszar Map Architecture Enterprise (EA) do architektury wprowadzania rozwiązania przez dostarczanie rozwiązania określonego szczegółu dla aplikacji, danych i widoków technologii z architektura. Own i wprowadź w życie logiczne i fizyczne projektowania rozwiązania. Programowanie aplikacji Functional Area Cechy Code, by spotkać specyfikacje projektowe. Recenzje kodu Conduct podczas rozwoju, by podzielić się wiedzę i doświadczenie. Carry testowanie blokowe jako zdefiniowany w próbnym planie z poparciem próbnej roli. 28 Model Team MSF v. 3.1 Development infrastruktury Functional Area Develop cechy, które spotykają specyfikacje projektowe. Develop scenariusze dla zautomatyzowanego rozwinięcia. Develop dokumentację rozwinięcia. Technologia radząca funkcjonalny obszar serwuje jako techniczny zasób przez cykl życia projektu. Jako doradca technologii, rozwój musi dostarczyć wejścia do wysokiego szczeble projektowania, oceń i uprawomocnij technologie i prowadź badanie by złagodzić ryzyka rozwoju wcześnie w procesie rozwoju. Podczas wyobrażonej sobie fazy, ten funkcjonalny obszar skupia się na analizowaniu wymagania użytkownika / klienta od perspektywy realizatora. Funkcjonalny obszar przyczynia się do definicji wizja / zakres dokumentu przez ocenianie techniczne implikacje projektu dla wykonalności wprowadzania w początkowym parametry projektu. To dostarcza kierownictwa na argumentach za i przeciw możliwego podejścia wprowadzania i uprawomocnia początkowe wybory technologii. W tym procesie funkcjonalny obszar może prowadzić badanie, naradzają się z odpowiednikami w organizacji albo gdzie indziej i trzymaj dyskusje z dostarczycielami technologii. Dla dodatkowej walidacji, funkcjonalny obszar może rozwinąć ograniczona funkcjonalność prototyp, by serwować jako dowód z pojęcie. To jest szczególnie związane dla projektów, które wymagają użycia nowego technologie albo w obszarach, gdzie projektowy zespół brakuje. Architecture wprowadzania i Design Functional Area Architektura wprowadzania i projektowanie funkcjonalny obszar opisuje komplet z odpowiedzialności wiążące się z definicją architektury wprowadzania dla rozwiązanie i rozwój projektowań rozwiązania podczas projektu MSF. Od punktu widzenia projektowania, zarządzanie programami jest odpowiedzialne za całkowitego architektura rozwiązania i jego pozycjonowania w architekturze przedsięwzięcia. Rozwój jest odpowiedzialny za rozplanowywanie architektury przedsięwzięcia do rozwiązanie architektura wprowadzania przez dostarczanie rozwiązania określonego szczegółu dla aplikacji, dane i widoki technologii rozwiązania. MSF proponuje trzy ułożony warstwami proces projektowania: Projektowanie pojęciowe , schemat logiczny i fizyczne projektowanie. Zarządzanie programami i co zarządzania produktu - posiądź pojęciowy projektowanie. Projektowanie pojęciowe zawiera scenariusze użytkownika, wysokiego szczebel analizę użyteczności, pojęciowe dane modelujące i początkowe opcje technologii. Rozwój posiada logicznego i fizyczni jęz aspekt czasownika projektowania rozwiązania. Logiczne i fizyczne projektowania nakazują wiedza związanej technologii i uderzenia wyborów technologii na projektowaniu rozwiązania. Model Team MSF v Programowanie aplikacji funkcjonalny obszar opisuje komplet odpowiedzialności wiążących do rozwoju aplikacji oprogramowania podczas projektu MSF. Rozwój najważniejsza odpowiedzialność roli w tym funkcjonalnym obszarze ma zbudować cechy pożądane rozwiązanie do specyfikacji i projektowań, testowania blokowego zachowania, jakości adresu wyjścia zidentyfikowały w procesie testowania i przeprowadziły integrację rozwiązania komponenty dawać plony końcowy do dostarczenia. Rola rozwoju przyczynia się do definicji standardów i przylega do tych podczas rozwoju rozwiązania. Recenzje kodu są prowadzone przez rozwój by oszacować poziom jakości cech aplikacji w poziomie części. Recenzje pozwalają członków zespołu aby podzielić się wiedzę rozwoju i doświadczenie, popierając cel MSF z "gotowość, by nauczyć się ” dla zespołów projektu. Rola rozwoju jest wymagana by prowadzić i skutki dokumentu zadowalającego części - poziomu przetestowującego cech wprowadziły w życie. The prace roli próby aktywnie z rolą rozwoju, by zaplanować dla i prowadź oszacowanie jakości cechy rozwiązania niezależnie i jako część kompletne rozwiązanie. Rozwój infrastruktury funkcjonalny obszar opisuje komplet odpowiedzialności wiążąc się z rozwojem systemów i infrastruktury oprogramowania dla rozwiązania podczas projektu MSF. Infrastruktura systemów zawiera infrastrukturę sieci dla środowisko przetwarzania rozproszonego, klienta i systemy serwera i jakieś popierając komponenty. Infrastruktura oprogramowania zawiera systemy obsługiwania dla klienci i serwery, jak również produkty oprogramowania, którzy dostarczają wymaganej platformy usługi oprogramowania, na przykład, katalog, posyłając wiadomość, baza danych, aplikacja przedsięwzięcia integracja, zarządzanie systemem, zarządzanie sieci i tak dalej. Podczas rozwoju infrastruktury, roli rozwoju "rozwija się ” infrastruktura wyszczególnił w projektowaniu. To zawiera konfigurowanie technologii założenia infrastruktura dla rozwiązania, na przykład łącząc w sieć poparcie i klienta i serwer systemy jako zdefiniował przez projektowanie. Jęz aspekt czasownika infrastruktury mogą zostać wpłynięty przez wymagania aplikacji, by zostać poparty i vice versa. Na przykład , missioncritical dobrze wykonane rozwiązanie może potrzebować zaakomodować grupowanie i loadbalancing wewnętrznych serwerów. Obsługując systemy i produkty platformy dla potrzeba rozwiązania, by być właściwie "rozwinięty.” Różne produkty platformy oprogramowania musi zostać zainstalowany, jest skonfigurowany i jest zoptymalizowany, by spotkać potrzeby rozwiązania. Po odpowiednim testowanie i stabilizując, rozwiązanie infrastruktury jest rozmieszczone na obszernej skali pod oskarżenie roli zarządzania wypuszczenia, która rola zarządziła nabywanie wymagania infrastruktury rozwiązania. 30 Model Team MSF v. 3.1 User Experience

30 Testing Zidentyfikowanie wad i poprawienie błędów
Testowanie planu i podejścia Poprawienie jakości Rozwój specyfikacji testu Development Program Management Testing Product Management Release Management Cel próbnego grona roli ma pochwalać dla wypuszczenia tylko po wszystkiej jakości produktu wyjścia są zindentyfikowane i są zwrócony do. Wszystko oprogramowanie jest dostarczone z wadami. Kluczowy cel jest aby zapewnić, że te wady są zindentyfikowane i są zwrócony do przed wypuszczaniem produktu. Zwracanie się do może włączyć wszystko od naprawiania wady w omawianiu do udokumentowywania praca - dookoła rozwiązań. Dostarczając znaną wadę, która została zwrócony do wzdłuż z praca - dookoła rozwiązania jest bardziej pożądany do dostarczania produktu zawierającego niezidentyfikowanego wady, które mogą zaskoczyć zespół i klienta później. Aby być pomyślny, próbne zespołowe grono roli musi skupić się na pewnych kluczowych odpowiedzialnościach. Te odpowiedzialności są grupowane w trzech kluczowych funkcjonalnych obszarach. Planning próby Develop testowanie podejście i plan. Participate w ustawianiu jakościowego baru. Develop specyfikację próby. Engineering próby Develop i utrzymuje automatyzowane precedensy, narzędzia i scenariusze. Conduct przetestowuje, by dokładnie określić stan rozwoju produktu. Manage procesy budowania. Próba Reporting Dostarcz, że zespół dane wiązał się z produktem jakość. Track wszystkie pluskwy i komunikuje wyjścia, by zapewnić ich zdecydowanie przed produktem wypuszczenie. Model Team MSF v Próba planująca funkcjonalny obszar jest częścią próbnego grona roli, które skupia się dalej jak zespół zapewni, że wszystkie wyjścia jakości produktu są zindentyfikowane i są zwrócony do. Próbna rola rozwija przetestowywanie podejść i planów i przez robienie tak szkicuje strategia, która zespół użyje, by przetestować rozwiązanie. Te plany zawierają określone typy z przetestowuje, określone obszary, by zostać przetestowany, criteria sukcesu próby i informacja na zasobach (zarówno sprzęt komputerowy i ludzie) wymagały przetestować. Ważna część próby planującej funkcjonalny obszar jest udziałem w zachodzeniu bar jakości przez dostarczanie wejścia do projektowego zespołu na jakość miarach kontroli i criteria dla sukcesu rozwiązania. Końcowa działalność w próbie planującej funkcjonalny obszar ma rozwinąć próbę specyfikacja. To jest szczegółowy opis narzędzi i kodu koniecznego, by spotkać się potrzeby zdefiniowały w próbnym planie. Próbna inżynieria funkcjonalny obszar, jako część próbnego grona roli, skupia się na niesieniu z działalnościami zdefiniowanymi w próbie planowania wymaganego zapewnić, że wszystka jakość produktu wyjścia są zindentyfikowane i są zwrócony do. Między odpowiedzialnościami zdefiniowanymi w tym obszarze cła specyficzne mają rozwinąć się i utrzymać precedensy; rozwój narzędzi, scenariuszy i dokumentacja, by wykonać funkcje testowania; zarządzanie codziennego rośnie, by zapewnić to procedury pomiarowe mogą zostać wykonana i są doniesione na pojedynczej ramie odniesienia; i prowadzenie przetestowuje, by dokładnie określić stan rozwoju produktu — biegnąc przez precedensy, narzędzia i scenariusze utożsamić wyjścia z aktualnym urosnąć Pozostawiając ślady i Reporting Śledzienie i donosząc funkcjonalny obszar, jako część próbnego grona roli, skupia się dalej artykułowanie wyraźnie projektowemu zespołowi czego jest aktualnie niewłaściwe z rozwiązaniem i co było aktualnie dobrze, żeby stan rozwoju dokładnie został przedstawiony. Śledzienie wyjścia jest wykonany, by zapewnić, że wszystkie zidentyfikowane wyjścia zostały postanowione przed wypuszczenie produktu. Stan wyjścia dokumentu, zawierając zadanie, pierwszeństwo, zdecydowanie i praca - arounds jest uzupełniony na częstej podstawie, by dostarczyć, że zespół dane wiązał się do aktualny stan jakości produktu i podana szczegóły analiza trendu. 32 Model Team MSF v. 3.1 User Experience

31 Release Management Planowanie wdrożenia Development Program Management
Testing Product Management Release Management Cluster Role Management wypuszczenia Cel grona roli zarządzania wypuszczenia jest gładkim rozwinięciem i dalej poszły operacje. Zarządzanie wypuszczenia jest rolą tę bezpośrednio włącza operacje na MSF zespół. To zawiera iść za funkcjonalnymi obszarami odpowiedzialności: Acts jako najważniejszy poprzyj między rozwojem projektu i grupami operacji. Manages selekcję narzędzia dla działalności wypuszczenia i kieruje optymalizowanie automatyzacji. Sets sprawnego criteria dla wypuszczenia do produkcji. Participates w projektowaniu, skupiając na zolność kierowania, bycie do zniesienia i deployability. Drives szkolenie dla operacji. Drives i komplety w górę poparcie dla rozwinięcie pilota(s). Plans i zarządza rozwinięcie rozwiązania do produkcji. Ensures, że miary stabilizacji spotykają criteria akceptacji. Infrastruktura Planowanie infrastruktury Enterprise. Coordinate fizyczne użycie środowiska i planowanie przez geografie { centra obliczeniowe, laboratoria, biura pola). Dostarcz zespołowi polityki i procedury dla stałej infrastruktury zarządzanie i standardy. Dostarcz usługi infrastruktury do zespołu MSF { serwery budynku, standardowe obrazy, instalując oprogramowanie). Manage sprzęt komputerowy / oprogramowanie nabywanie dla zespołu. Build próbę i wystawiając środowiska te dokładnie odzwierciedlić środowiska produkcji. Poparcie Dostarcz współpracę warunku zasadniczego i dział obsługi klienta do TEGO użytkownicy. Support biznes przez zarządzanie SLA z klientem i zapewnianie zaangażowania są spotkane. Dostarczają wydarzenie i zdecydowanie problemu; szybka dopowiedzieć na użytkownika prośby i zalogował się wydarzenia. Give reakcję rozwojowi i zaprojektuj zespół. Develop poprawną pracę po przejęciu zadań i procedury poprawy. Model Team MSF v Operacje Account i kontrole konfiguracji systemu; zarządź konta użytkownika i pozwolenia. Messaging, baza danych, operacje telecom; operacje sieci. Administracja systemu, przetwarzanie wsadowe. Zarządzanie Firewall; administracja bezpieczeństwa. Usługi Application. Usługi integracji Host. Operacje usługi Directory. Handlowy Management Release Kody rejestracji Product; proces weryfikacji rejestracji. Licensing zarządzanie. Packaging. Manage kanał dystrybucji. Print i elektroniczne opublikowanie. Infrastruktura funkcjonalny obszar opisuje komplet odpowiedzialności wiążących do infrastruktura operacji, która musi zostać zaspokajana podczas projektu MSF. To jest część grono roli zarządzania wypuszczenia MSF. Dla projektów używających MOF, te korespondują do odpowiedzialności grona roli infrastruktury MOF. Ten funkcjonalny obszar skupia dalej zapewnianie, że rozwiązanie urosło i rozmieściło jest do zniesienia. Dla projektów używających MOF, te odpowiadają odpowiedzialnościom grono roli poparcia MOF. Ten funkcjonalny obszar opisuje komplet odpowiedzialności operacji, które muszą zostać zaspokajana podczas projektu MSF. Ten funkcjonalny obszar skupia dalej zapewnianie, że rozwiązanie urosło i rozmieścił jest wykonalny i kompatybilny z innymi usługami w operacji. Dla projektów używając MOF, te odpowiadają odpowiedzialnościom grona roli poparcia MOF. 38 Model Team MSF v. 3.1 Ten funkcjonalny obszar opisuje komplet odpowiedzialności wiążących się z wypuszczaniem handlowy produkty oprogramowania. Handlowe zarządzanie wypuszczenia skupia się na dostawaniu produktu do kanał. Ważąc Team Model W jego książka Rapid Development, byłym producencie oprogramowania Microsoft Steve McConnell stany: "Duże projekty domagają się organizacyjnych praktyk, które formalizują i nadają opływowy kształt komunikacja. … All drogi, by nadać opływowy kształt komunikację polegają na tworzeniu jakiegoś rodzaj hierarchii, która jest, tworząc małe grupy, które funkcja jako zespoły i wtedy wyznaczając reprezentantów od tych grup oddziałać na siebie z siebie i z zarządzanie.” Obrońcy modelu zespołu MSF rozbijający duże zespoły { ci więksi niż dziesięciu ludzie) do małego, zespołów cechy multidisciplinary. Te mała praca zespołowa równolegle, z częstymi okazjami, by zsynchronizować ich wysiłki. W dodatku , zespoły funkcji mogą zostać użyty, gdzie zasoby wielokrotności są wymagane, by spotkać się potrzeby szczególnej roli i jest grupowany odpowiednio w tej roli. Teams cechy Każde grono roli w zespołowym modelu obejmuje jednego albo więcej zasoby zorganizowały w struktura hierarchiczna (chociaż tak płaski jak możliwy). Na przykład , testery zgłaszają się do próby kierownik albo prowadzenie. Są pokryte na tej strukturze zespoły cechy. Te jest mniejsza łódź podwodna - łączy się to organizować jeden albo więcej członków od każdej roli do organizacji macierzy. Te zespoły są wtedy wyznaczony szczególny długometrażowy komplet i były odpowiedzialny za wszystkich jęz aspekt czasownika tego, zawierając jego projektowanie i plan. Na przykład , długometrażowy zespół mógłby zostać poświęcony do projektowania i rozwój drukowania usług. Steve McConnell pisze Rapid Development: "Zespoły cechy mają korzyści upoważniania, odpowiedzialności i zachowują równowagę. Zespół może sensownie zostać upoważniony, ponieważ to zawiera reprezentantów … od każdy z zainteresowanych przyjęć. Zespół rozważy wszystkie konieczne punkty widzenia w jego decyzje i w ten sposób chce rzadko kiedy być podstawą, ponieważ przekraczając to decyzje. "Dla tego samego powodu, zespół staje się odpowiedzialny. Oni mają dostęp do wszystkiego ludzie, którzy oni potrzebują, by osiągnęli sukcesy decyzje. Jeśli oni nie osiągają sukcesów decyzji, ich nie miej nikogo, by winić ale się. Zespół jest zachowany równowagę. Nie chciałbyś rozwój, marketing, albo zapewnienie jakości sam, by mieć ostateczny mówić ponad specyfikacja produktu, ale możesz dostać wyważone decyzje od grupy to zawiera reprezentantów od każdego z tych kategorii.” Model Team MSF v Zgadza się 2 – Teams Feature Zauważ: Ten graficzny przykład nie reprezentuje wymagań dla organizacji z zespoły cechy. Na przykład , nie wszystkie długometrażowe zespoły wymagają roli Experience User; zespoły powinny zostać zorganizowany jak jest wymagane, by spotkać cel ich skupienia rozwiązania. Teams funkcji Zespoły funkcji są zespołami, które istnieją w roli. Oni są skutkiem zespołu albo padają będąc tak duży, że to wymaga ludzi w roli, by zostać grupowane do zespołów opartych na ich funkcjonalności. Na przykład , to jest wspólne w Microsoft dla produktu zespół rozwoju, by mieć planistę produktu i rynkowiec produktu. Oba prac jest jęz aspekt czasownika zarządzania produktu: Skupia się na dostawaniu cechom klienta naprawdę chce i inne skupienia na komunikowaniu korzyści produktu do potencjalnego użytkownicy. To może też być prawdziwe dla rozwoju, gdzie producenci mogą zostać grupowany przez usługę warstwa, nad którą oni pracują: użytkownik, biznes, albo dane. To jest też wspólne dla producentów by być grupowany na podstawie, czy oni są budowniczymi rozwiązania albo budowniczymi komponentu. Budowniczy komponentu są zwykle niskiego poziomami producentami C, którzy tworzą nadający się do wielokrotnego użycia komponenty, które mogą być leveraged przez przedsięwzięcie. Budowniczy rozwiązania budują przedsięwzięcie aplikacje około "klejąc ” te komponenty razem. Budowniczy rozwiązania zwykle pracują z wyższymi równymi językami jak Microsoft ® Visual Basic ®. Często zespoły funkcji zawierają cechy wewnętrzne struktury hierarchicznej do tej grupy. Na przykład wielu kierowników programu zgłasza się w górę przez kierowników programu prowadzenia, z zaprowadza zgłaszając do grupowego kierownika programu. Struktura w tym sposobić może też zdarzyć się dla funkcjonalne obszary raczej niż w poziomie grona roli. Ważna rzecz zatrzymać w domu umysł jest, że hierarchia nie przeszkadza zespołowego modelu w poziomie projektu. Cele role pozostają tym samym także w ich całkowitej odpowiedzialności do projektowego zespołu. 40 Model Team MSF v. 3.1 Uczestniczący Roles Chociaż zespołowy model składa się z sześć roli, zespół nie potrzebuje minimum sześciu ludzie. To też nie wymaga jednej osoby na roli. Punkt kluczowy jest ten, który sześć celów ma aby zostać reprezentowany na każdym zespole. Typowo, mienie co najmniej jednej osoby na roli pomaga do zapewnij, że ktoś opiekuje się zainteresowaniami każdej roli, ale nie wszystkie projekty mają korzyść napełniania każdej roli w tej modzie. Często, członkowie zespołu muszą podzielić się role. Na mniejszych zespołach, role muszą zostać podzielona przez członkostwo zespołu. Dwie zasady kierują system wielodostępowy roli. Pierwszy jest, że członkowie zespołu rozwoju nigdy nie podzielają się roli. Producenci są projektowi budowniczy i oni nie powinni zostać oderwany od ich zadania głównego. Aby dać dodatkowe role do zespołu rozwoju tylko robi to, które prawdopodobniejsze, że plany chcą pośliźnij się z powodu tych innych odpowiedzialności. Drugi przewodnia zasada ma spróbować nie łączyć role, które mają wrodzone konflikty zainteresowania. Na przykład , zarządzanie produktu i zarządzanie programami mają kolidujące zainteresowania i nie powinien zostać łączony. Zarządzanie produktu chce zaspokajać klient, podczas gdy zarządzanie programami chce dostarczyć punktualnie i na budżecie. Jeśli te role zostały łączone i klient mieli poprosić zmianę, ryzyko jest to którykolwiek zmiana nie dostanie rozważaniu tego zasługuje utrzymać klienta satysfakcja albo, że to będzie przyjęte bez rozumienia uderzenia do projektu. Mienie różni zespołowi członkowie reprezentują te role pomaga zapewnić że każdy perspektywa otrzymuje równą wagę. To jest też prawdziwe, jeśli próbując łączyć testowanie i rozwój. Poszły za stołem ilustruje ryzykowny { jako wskazany około "Nie Recommended ” albo "Nieprawdopodobny ” symbole) i współdziałający (jako wskazywał około "Possible ” symbole) połączenia roli, ale jako z jakimś łączącym ćwiczeniem, pomyślny system wielodostępowy roli obniża się do faktyczni sami członkowie i jakie doświadczenie i umiejętności, które oni przynoszą z nimi. Model Team MSF v User Experience

32 User Experience Poprawa jakości
Rozwój dokumentacji dla systemów wykonawczych Interfejs użytkownika Development Program Management Testing Product Management Release Management Cluster Role Experience użytkownika Cel grona roli doświadczenia użytkownika jest poprawiony skutecznością użytkownika. Użytkownik doświadczenie jest objęte sześć funkcjonalnych obszarów: Dostępność, umiędzynarodowienie, techniczne komunikacje, trening, użyteczność i graficzne projektowanie. Doświadczenie użytkownika grono roli ma kilka odpowiedzialności w każdym funkcjonalnym obszarze, który musi być potrafił dla rozwiązania być pomyślny. Nastąpić jest wydrukiem funkcjonalnych obszarów i związane odpowiedzialności. Dostępność Pojęcia dostępności jazdy i wymagania do projektowania. Umiędzynarodowienie Ulepsz jakość i użyteczność rozwiązania w rynkach międzynarodowych. Techniczni Communications Design i rozwija dokumentację dla systemy wykonawcze { instrukcje Helpdesk, KB artykuły i więcej). Help Document / pomoc. Trening Rozwija się i wykonuje uczenie strategii (urośnij / kupować / dostarczać). Użyteczność Gather, analizuj i wyznacz priorytety wymagania użytkownika. Dostarcz reakcji i wejścia do projektowania rozwiązania. Develop scenariusze użycia i przypadki użycia. Act jako użytkownik popierają do projektowego zespołu. Graficzny Design Drives projektowanie interfejsu użytkownika. Model Team MSF v Dostępność funkcjonalny obszar skupia dalej zapewnianie, że rozwiązania są dostępne do te z kalectwami przez kierowanie pojęć dostępności i wymagań do projektowanie. Dostępność jest ważna dla wiele powodów. W pierwszym rzędzie, dostępność jest ważna ponieważ produkty i rozwiązania potrzebują być dostępny i użyteczny przez wszystkich ludzi nie zważając ich zdolności. Produkt albo rozwiązanie, które nie wyjaśnia dostępność będzie odczuj brak pełnej adopcji. Dodatkowo, zgoda dostępności często będzie wymagana aby spotkać regulacje rządu. Pojęcia dostępności i wymagania muszą zostać reprezentowane przez rozwiązanie cykl rozwoju i powinien zawrzeć: Włączenie sekcji dostępności w każdej długometrażowej specyfikacji. Integrating informację dostępności do sekcji pomóc rozwiązania. Ensuring, że ta dokumentacja dostępności jest kompletna. Ensuring, że ta dokumentacja dostępności jest była obecnym w dostępnych formatach. Odpowiedzialność w umiędzynarodowieniu funkcjonalny obszar ma poprawić się jakość i użyteczność rozwiązania w rynkach międzynarodowych. Umiędzynarodowienie funkcjonalny obszar jest złożony z zarówno globalizacji i lokalizacji procesów. Globalizacja Globalizacja jest procesem definiowania i rozwijania rozwiązania, które bierze do rachunek potrzeba, by zlokalizować rozwiązanie i jego zawartość bez modyfikacji albo niepotrzebny workarounds przez lokalizatory. Inaczej mówiąc , wypuszczone rozwiązanie które jest globalized właściwie jest gotowy, by zlokalizować z minimum trudności. Lokalizacja Lokalizacja rozwiązania włącza modyfikacje do interfejsu użytkownika rozwiązania, plików pomocy, drukowana i na żywo dokumentacja, wprowadzając na rynek materiały i strony sieci. Czasami, te materiały mogą wymagać zmian w graficznych elementach dla szczególnego języka wersja, albo nawet zadowolone modyfikacje. 34 Model Team MSF v. 3.1 Techniczna łączność funkcjonalny obszar skupia się na rozwoju rozwiązania systemy wykonawcze dokumentu. Główna odpowiedzialność technicznej łączności funkcjonalny obszar jest tworzeniem z komponenty narzędzi takie jak narzędziu pomóc. Narzędzie pomóc upoważnia użytkownika przez dostarczanie odpowiedzi do podstawowych pytań, opisów kluczowego słowa, wytłumaczeń błędu i często spytały pytania. Narzędzia takie jak zarówno użytkownikowi i organizacji przynieść korzyści pomóc. Użytkownicy korzyść, ponieważ oni dostają dopowiedzieć na wyjścia i pytaniom na czasie i efektywnego sposób. Korzyści organizacji przez redukcję w kosztach poparcia. Dodatkowa odpowiedzialność technicznej łączności funkcjonalny obszar jest będąc projektantem i rozwijając dokumentację dla rozwiązania. To może zawrzeć rozwój instalacji, ulepszenia, operacji i przewodników usuwania błędów. Szkolenie funkcjonalnego obszaru skupia się na poprawianiu występu użytkownika przez dostarczanie wiedza umiejętności potrzebowała skutecznie użyć rozwiązania. Ten transfer wiedzy umiejętności jest osiągnął przez wprowadzanie w życie strategię nauki. Rozwój strategii nauki jest odpowiedzialność grona roli zespołu doświadczenia użytkownika. Rozwój strategii nauki może mieć miejsce w organizacji, albo tej może być outsourced do organizacji, która specjalizuje się w treningu i rozwoju. Nie bacząc, na kogo właciwie rozwija się strategia nauki, podejście będzie najczęstszy złóż się: Przeanalizować użytkownika i celów i celów organizacji. Setting pożądany komplet poziomu umiejętności. Developing i wprowadzając w życie plan treningu. Upon wprowadzanie, mierząc plan treningu dla skuteczności i modyfikując plan treningu jako odpowiedni, ubezpieczyć sukces. Strategia nauki może obejmować jednego albo więcej poszłych za dostawą mechanizmów: Instruktor zaprowadzony trening, technologia dostarczyła szkolić się, badanie się albo użycie pomocy pracy. Wiele organizacji wybiera zmieszane zbliżyć się, do który przystosowuje się do osób posiadać ucząc styl. Model Team MSF v Użyteczność funkcjonalny obszar skupia dalej zapewnianie, że rozwiązanie może zostać użyte około wyszczególnili użytkownicy, by osiągnąć wyszczególnione cele z wysokimi poziomami skuteczności, wydajności, i satysfakcja. Główna odpowiedzialność zdefiniowała w użyteczności funkcjonalny obszar jest badania użyteczności, który zawiera zbieranie, analizowanie i wyznaczanie priorytetów wymagań użytkownika. Przez inwestowanie czas, by zrozumieć użytkownika wcześnie dalej i przez wysiłek rozwoju rozwiązania, projekt będzie miał wysokie prawdopodobieństwo skutecznie zaspokajania potrzeby użytkowników. Inna główna odpowiedzialność jako zdefiniował w użyteczności funkcjonalny obszar jest rozwijając scenariusze użycia i przypadki użycia. Kluczowy pomysł tutaj ma cofnąć się i spojrzeć w jak całe rozwiązanie prawdopodobnie będzie użyte. Ten wysiłek pomaga zespołowi rozwoju zrozumiej jak użytkownik zbliża się do rozwiązania od pojęciowego i literowego punktu widzenia i często zaprowadzą, by zaprojektować poprawy kończące się powiększoną wydajnością. Ostatnia główna odpowiedzialność jako zdefiniował w użyteczności funkcjonalny obszar dostarcza reakcja i wejście do rozwiązania. Przez branie czasu, by dostarczyć reakcję użytkownika do producenci przez cykl rozwoju, rozwiązanie skorzysta przez osiąganie wyższe tempo satysfakcji użytkownika. Graficzne projektowanie funkcjonalny obszar skupia dalej zapewnianie, że graficzne elementy w rozwiązanie jest zaprojektowany właściwie. Główna odpowiedzialność graficznego projektowania funkcjonalny obszar kieruje projektowanie interfejsu użytkownika. To włącza bycie projektantem przedmioty, że użytkownik będzie oddziaływał na siebie z (i działania odniosły się do tych przedmiotów), jak również główne ekrany w interfejsie. User Experience

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: Streszczenie Model zespołu MSF nie jest gwarancją dla sukcesu projektu. Więcej czynników niż tylko zespół struktura określają sukces albo niepowodzenie projektu, ale struktura zespołu jest ważna. W Rapid Development, Steve McConnell ilustruje ten punkt przez mówienie: "Nawet kiedy masz wykwalifikowany, umotywowany, pracowici ludzie, niewłaściwy zespół struktura może sprzedać taniej ich wysiłki zamiast katapultowania ich do sukces. Biedny zespół struktura może powiększyć się czas opracowania, zmniejszają jakość, morale szkody, wzrost obrót i ostatecznie ołowiany, by rzucać odwołanie.” Model zespołu MSF jest znaczony, by zwrócić się do tylko ten punkt. Właściwa zespołowa struktura jest podstawowy do sukcesu i wprowadzając w życie ten model i używając jego leżeć u podstaw zasady pomogą zrobić, że zespoły są efektywniejsze i dlatego pomyślny. Dla więcej informacji, zobacz: 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 Analyze and Prioritize
Identyfikacja ryzyka Identyfikacja ryzyka dla rozwijania świadomości zespołu Identify Analyze and Prioritize Learn Identification ryzyka pozwalał osoby do ryzyk powierzchni, żeby zespół stał się świadomy z potencjalny problem. Jako wejście do procesu zarządzania ryzyka, identyfikacji ryzyka powinien zostać przedsięwzięty jak najwcześniej i powtórzony często przez projekt cykl życia . Plan and Schedule Control Track and Report

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 Identify Analyze and Prioritize Learn Plan and Schedule Control Track and Report

38 Analyze and Prioritize
Planowanie Formułowanie strategii, planów, działań Zatwierdzanie planów Harmonogram ryzyka łączy się z harmonogramem projektu Identify Analyze and Prioritize Learn Plan and Schedule Control Track and Report

39 Analyze and Prioritize
Raportowanie Monitorowanie stanu i postępu Zbieranie danych do ewentualnych zmian w planach Identify Analyze and Prioritize Learn Plan and Schedule Control Track and Report

40 Analyze and Prioritize
Kontrola Nanoszenie zmian do projektu jeżeli zmiany planu zarządzania ryzykiem są znaczące Identify Analyze and Prioritize Learn Plan and Schedule Control Track and Report

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

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 www.microsoft.com/msf
Kurs Microsoftu: “MSF Essentials” MOC #1846 Książka: “Dynamics of Software Development” by Jim McCarthy, Microsoft Press


Pobierz ppt "MSF Piotr Skwarski, Maciej Prusko."

Podobne prezentacje


Reklamy Google