Działania w projekcie
Aby najbardziej efektywnie wykorzystać MSF dla ulepszanie procesów CMMI, należy zorganizować projekt do szeregu iteracji, zazwyczaj o długości między cztery a osiem tygodni.Pomaga to ograniczyć zagrożenie ryzyka projektu, które wynika z przechodzeniem do wymogów do kosztów realizacji.Iteracyjna struktura projektu jest ważnym wkładem w sprostaniu wymaganiom zarządzania ryzykiem CMMI.
Na początku projektu
Dzień rozpoczęcia projektu
Rozpoczęcie obejmuje zdefiniowanie wizji projektu, która stwierdza, co użytkownicy będą mogli zrobić, gdy projekt zwolni własny produkt.
Obejmuje to również tworzenie zespołu, infrastruktury i innych zasobów i określania procesu rozwoju.
Aby uzyskać więcej informacji, zobacz Incepcja projektu.
Wstępne planowanie projektu
Planowanie projektu obejmuje następujące działania:
Dostatecznie szczegółowe analizowanie wymagań umożliwiające utworzenie planu.Analiza ta może obejmować wykorzystanie modeli wymagania, storyboardy i inne narzędzia, które pomagają przewidzieć działający system.
Opracowanie ogólnego projektu lub architektury dla systemu.Jeżeli wiąże się to z pracą na platformie, która jest nowa dla członków zespołu, należy przeznaczyć trochę czasu na poeksperymentowanie z nią.Rozwoju będzie wolny w starszych iteracjach.
Osadzanie wymagań jako zestawu rosnących wymagań produktu, którego rozwój można w przybliżeniu oszacować.Różnica między wymaganiami ogólnymi i wymaganiami produktu jest ważne, i jest to znaczące działania.Aby uzyskać więcej informacji, zobacz Opracowywanie wymagań.
Dokonywanie początkowego przydziału wymagań produktu do iteracji.
Ustawienie daty wydania.
Modele planu i wymagań zostanie poprawiony i ulepszony w czasie trwania całego projektu.Częścią celu iteracyjnego projektowania jest umożliwienie ulepszeń w wymaganiach, które wynikają z wykazywania działania oprogramowanie na wczesnym etapie.
Wstępne planowanie projektu odbywa się w iteracji 0.
Aby uzyskać więcej informacji, zobacz Planowanie projektu (CMMI).
Poznawanie istniejącego produktu
Celem projektu może być aktualizacja produktu, który już istnieje.W tym przypadku, jeśli zespół nie jest zaznajomiony z produktem, badanie kodu jest działaniem dla Iteracji 0.Każde zadanie rozwoju w kolejnych iteracjach obejmie również zrozumienie kodu w określonej lokalizacji i śledzenie konsekwencji jego modyfikacji.
Aby uzyskać więcej informacji, zobacz Tworzenie wizualizacji kodu.
W trakcie realizacji projektu
Plan jest poprawiany i poddawany zmianom w czasie trwania całego projektu.
Kilka działań, które są związane z planu projektu jest wykonywane regularnie w całym projekcie, zwykle w kierunku końca iteracji.
Walidacja
Zademonstruj swoim klientom lub stronom zainteresowanym ze strony biznesu oprogramowanie, który zostało opracowane podczas iteracji.Jeżeli jest to wykonalne, zwolnij go do nich tak, żeby mogli eksperymentować z tym lub użyć tego do pewnego stopnia w kontekście praktycznym.
Po upływie wystarczające czasu, zorganizuj spotkanie w celu dokonania przeglądu opinii użytkowników.Opinie mają być użyty do wygenerowania żądania zmiany.
Aby uzyskać więcej informacji, zobacz Validation.
Zarządzanie ryzykiem
Przejrzyj prawdopodobieństwa i wpływ potencjalnych niepożądanych zdarzeń i podejmij kroki w celu zmniejszenia ryzyka.Aby uzyskać więcej informacji, zobacz Zarządzanie ryzykiem.
Zarządzanie zmianami
Możesz użyć żądania zmiany elementów roboczych, aby zarejestrować zmiany w wymaganiach określonych przez zainteresowane strony biznesowe.Wynikają one ze zmian w kontekście działalności, ale także z pokazów i prób wczesnej wersji produktu.Zmiany te powinny być przyjęte, ponieważ zwiększają przydatności produktu do jego celów biznesowych.Efekt ten jest częścią działania na rzecz rozwoju przyrostowych.
Niektóre zespoły projektów dopasowują elementy robocze wymagań produktu, gdy zmiany są wymagane, bez użycia elementu roboczego oddzielnie.Ale zaletą elementu roboczego żądania zmiany jest to, że w dalszej części projektu, można przejrzeć liczbę i charakter zmian, które zostały wprowadzone.Tych informacji można użyć do poprawy swojego procesu lub architektury w przyszłości.
Żądania zmiany powinny służyć jako dane wejściowe do przeglądu planu produktu.
Aby uzyskać więcej informacji, zobacz Zarządzanie zmianą.
Przegląd planu produktu
Zatrzymaj przegląd planu produktu przed planowaniem każdej iteracji.Plan projektu przypisuje wymagania produktu iteracji.
Plan zmieni się z dwóch głównych przyczyn:
Zmiany w wymaganiach.
Zmiany wartości szacunkowych, dokonane przez deweloperów.W miarę postępów projektu zespół opracowujący może uczynić bardziej wiarygodne szacunki prac, które będą potrzebne w celu wdrożenia przyszłych funkcji.W niektórych przypadkach niektóre funkcje mogły zostać odłożone z poprzedniej iteracji, która dodaje funkcję do planu.
Oba rodzaje zmiany staną się rzadsze w późniejszej iteracji.
Popraw modele wymagania, z których wywodzą się wymagania produktu.
Popraw przypisanie wymogów w odniesieniu do iteracji.Podobnie jak w początkowej fazie planowania, udziałowcy biznesowych ustalają priorytety, zespół opracowujący ustala szacunki, a spotkanie „żongluje” funkcjami między poszczególnymi iteracjami.
Aby uzyskać więcej informacji, zobacz Planowanie projektu (CMMI).
Przed głównym wydaniem produktu
Działania, które są zaangażowane we wdrażanie produktu zależą od jego typu i nie są tu omawiane.
Należy wziąć pod uwagę następujące punkty, w odniesieniu do nowszych iteracji rozwoju oprogramowania:
Wyklucza poważne zmiany w projekcie, aby uniknąć ryzyka nieprzewidzianych problemów.
Podnoszą poprzeczkę w dziedzinie zmiany i usterek na spotkaniach klasyfikacyjnych.Proponowane zmiany i poprawki błędów powinny zostać odrzucone, chyba że mają znaczący wpływ na użyteczność i przydatności do celów produktu.
Przeznacz zasoby na zwiększenie zakresu badań oraz przeprowadzanie testów ręcznych.