Podejście klasyczne.

Analiza

Rozdział ten opisuje fazę analizy według CDM. Sednem tej fazy jest sformułowanie szczegółowych wymagań dla aplikacji systemowych. W czasie fazy analizy zespół projektowy bada, rozpatruje obszar biznesowy, który został wcześniej zdefiniowany w fazie definicji. Grupa analityków powinna pamiętać o osiągnięciu i udokumentowaniu całkowitego zrozumienia obszaru biznesowego poprzez dokładne ustawienia modeli. Modele te muszą zawierać opisy co dany obszar biznesowy wykonuje i informację który jest używany.

Diagram 5-1 Kontekstowy CDM fazy analizy.

Przegląd

Sekcja ta daje nam ogólny widok fazy analizy.

Cele.

Cele fazy analizy są następujące:

• wytwarzanie wiernych i kompletnych modeli procesów, funkcji i danych obszaru biznesowego

• zdefiniowanie szczegółów funkcjonalnych, informacyjnych i operacyjnych wymagań dla proponowanej aplikacji systemowej

• zdefiniowanie architektury technicznej warstwy sprzętowej i programowej której implementację zaproponuje system aplikacyjny

• propozycja tranzycji strategii dla przenoszenia z aktualnego systemu(ów) do nowego systemu aplikacyjnego

Krytyczne czynniki powodzenia.

Krytyczne czynniki powodzenia fazy analizy są następujące:

• wymagana komisja użytkowników

• zaległe zagadnienia i pytania powinny być stanowcze w pożądany sposób

• QA standardy znajdujące się w tym miejscu gwarantują dokładną kontrolę kompletności i zgodności

• grupa projektowa definiuje klucz wyjściowy dla tranzycji do fazy projektowej

• dobre zamiany miejsc procedur kontrolujących silnie skupiających się na utrzymaniu zdefiniowanej funkcjonalnej dziedziny projektu

• znakomicie zdefiniowana bieżąca architektura techniczna lub strategiczne systemy informacyjne

Schemat metody

Diagram ten ilustruje warunki wstępne, procesy, i produkty dostarczone do fazy analizy.

Diagram 5-2 Widok ogólny fazy analizy.

Warunki początkowe.

Warunki początkowe fazy analizy są następujące. Powinieneś używać tych warunków jeśli ich istnienie zapewnia rozpoczęcie fazy. W przeciwnym razie będziesz musiał je stworzyć w czasie fazy analizy.

Warunki początkowe	Źródło
Model procesów biznesowych	Definicja wymagań biznesowych
Model funkcji biznesowych	Definicja wymagań biznesowych(wysoko-poziomowa)
Model danych biznesowych	Definicja wymagań biznesowych (inicjująca)
Definicja struktury organizacyjnej	Istniejący system kontroli
Istniejący system interfejsów	Istniejący system kontroli
Wymagania interfejsu systemowego	Architektura techniczna
Architektura techniczna (inicjująca)	Architektura techniczna
Plan objętościowy (inicjujący)	Architektura techniczna
Istniejąca architektura techniczna	Istniejący system kontroli
Wymagania konwersji danych	Konwersja danych

Tabela 5-1 Warunki początkowe fazy analizy.

Procesy

Procesy użyte w tej fazie są następujące:

Procesy	Opis
Definicja wymagań biznesowych	Kompletny model analizy szczegółowej. Przekształcenie modelów wymagań biznesowych w modele wymagań systemowych poprzez dodanie szczegółów architektury systemowej.
Istniejący system kontroli	Szczegółowy dokument istniejących funkcji i procesów
Architektura techniczna	Specyfikacje sprzętowe, programowe i rozkładu architektury bazujące na informacji objętościowej
Konwersja danych	Określenie strategii planu pracy nad konwersją wszystkich niezbędnych danych
Dokumentacja	Określenie wymagań i standardów użytkowników oraz dokumentacji, włączając dokumentacje, bieżącą
Testowanie	Opracowanie ogólnej strategii testowania
Trening	Opracowanie wymagań treningowych projektu
Tranzycja	Definiowanie strategii inicjującej dla odcinania

Tabela 5-2 Procesy fazy analizy.

Produkty wyjściowe

Podstawowe produkty wyjściowe tej fazy:

Produkt	Opis
Model danych biznesowych	Szczegółowe zdefiniowanie informacji która jest użyta, przez biznes-klienta, z dostarczeniem reprezentacji struktury tej informacji

Produkt	Opis
Szczegółowy model funkcji biznesowych	Szczegółowy opis funkcji, które zawieraj ą procesy biznesowe, z przedstawieniem graficznym klasyfikacji hierarchicznej tych funkcji.
Model procesów systemu	Graficzna reprezentacja procesów biznesowych, która pokazuje jak funkcje systemowe są powiązane z funkcjami ręcznymi, aby zareagować na zdarzenia kierujące tym przedsiębiorstwem.
Model funkcji systemu	Szczegółowa specyfikacja funkcji dostarczanych przez system.
Model danych systemu	Szczegółowy model związków encji, opisujący logiczną strukturę informacji przechowywaną i przetwarzaną w systemie.
Podstawowa definicja sprzętu i oprogramowania	Techniczna architektura sprzętu i oprogramowania wymagana dla działania nowego systemu.
Strategia konwersji danych, Wymagania szkoleń, Wstępna strategia wdrażania	Opis jak informacja jest przekazywana z istniejącego do nowego systemu, jak personel powinien być przeszkolony, aby korzystać z nowego systemu i jak nowy system jest wdrażany.

Tabela 5-3. Kluczowe elementy fazy analizy.

Przybliżenie

Ten rozdział opisuje podejście do fazy analizy.

Zadania i ich wyniki

Poniższa tabela zawiera przedsięwzięcia wykonywane i efekty powstające podczas fazy analizy. Procesy są wyróżnione ciemniejszą czcionką, a użyte identyfikatory są powszechne w całości materiałów dotyczących CDM.

ID	Przedsięwzięcie	Efekt
Definicja wymagań przedsiębiorstwa
RD.050	Zbieranie szczegółowych informacji o przedsiębiorstwie	Szczegółowy opis przedsiębiorstwa
RD.060	Konstrukcja modelu danych przedsiębiorstwa	Model danych przedsiębiorstwa
RD.070	Konstrukcja szczegółowego modelu funkcji przedsiębiorstwa	Szczegółowy model funkcji przedsiębiorstwa
RD.080	Konstrukcja modelu danych systemu	Model danych systemu
RD.090	Konstrukcja modelu funkcji systemu	Model funkcji systemu
RD.100	Tworzenie modelu procesów systemu	Model procesów systemu
Badanie systemu istniejącego
ES.080	Wytwarzanie skorygowanej istniejącej architektury technicznej	Skorygowana istniejąca architektura techniczna
ES.090	Wytwarzanie opisu funkcji istniejącego systemu	Istniejący opis funkcji systemu
ES. 100	Wytwarzanie szczegółowego modelu danych istniejącego systemu	Istniejący szczegółowy model systemu danych
ES.110	Wytwarzanie opisu istniejących procedur	Opis istniejących procedur
Architektura techniczna
TA.050	Definiowanie szczegółowych wymagań systemu	Szczegółowe wymagania systemu
TA.060	Rozwój podstawowej definicji sprzętu i oprogramowania	Podstawowa definicja sprzętu i oprogramowania
TA.070	Rozwój architektury podziału	Architektura podziału
TA.080	Rozwój strategii odzyskiwania i cofania	Strategia odzyskiwania i cofania
TA.090	Rozwój strategii bezpieczeństwa i kontroli	Strategia bezpieczeństwa i kontroli
TA. 100	Rozwój definicji stylu interfejsu użytkownika	Definicja stylu interfejsu użytkownika
TA. 110	Rozwój ulepszania planu pojemnościowego	Ulepszony plan pojemnościowy
Konwersja danych
CY.020	Definiowanie strategii konwersji danych		Strategia konwersji danych
CY.030	Definiowanie planu pracy przy konwersji danych		Plan pracy przy konwersji danych
Dokumentacja
DO.020	Specyfikacja wymagań dokumentacji		Wymagania dokumentacji
DO.030	Określenie standardów dokumentacji		Standardy dokumentacji
Testowanie
TE.010	Rozwój strategii testowania		Strategia testowania
Szkolenie
TR.010	Specyfikacja wymagań szkolenia		Wymagania szkolenia
TR.020	Definiowanie planu szkolenia		Plan szkolenia
Wdrażanie
TS.010	Definiowanie wstępnej strategii		Wstępna strategia wdrażania

Tabela 5-4 Efekty i zadania fazy analizy

Ta strona jest celowo pusta

Zależności między zadaniami

Ten diagram pokazuje zależności między zadaniami w fazie analizy.

Diagram 5-3 : Zależności między zadaniami fazy analizy

Diagram 5-3 : Zależności między zadaniami fazy analizy (cd.)

Designer/2000 Wspomaganie analizy

Rysunek 5-4 Designer/2000 Wspomaganie fazy analizy

Zarządzanie ryzykiem

Najbardziej prawdopodobne obszary ryzyka w fazie analizy są następujące

• Faza analizy zaczyna się bez akceptacji przez firmę efektów fazy definicji, czy też planu osiągnięcia akceptacji.

• Zespół projektowy nie uczestniczy w szkoleniach dotyczących metod i narzędzi.

• Wymagania zmian i szkoleń dla szeroko rozwiniętej firmy nie są adekwatnie dobrane.

• Sponsor projektu nie uczestniczy aktywnie w spotkaniach nad projektem i dlatego nie jest na bieżąco z przebiegiem prac oraz ich dalszym planem działania, wysiłkami ludzi i kosztami. Im więcej ludzi pracuje nad wytworzeniem systemu, tym większe jest zapotrzebowanie na sponsorów.

• Cele projektu tracą na szczegółach i kierownik projektu nie przestrzega ściśle wymagań.

Powyższe niebezpieczeństwa powinno łagodzić się. następująco:

• Utrzymywać przegląd efektów fazy definicji z zamiarem uzyskania akceptacji. (Ten przegląd powinien być podzielony na kolejne kompletne fazy). Otrzymane efekty należy posegregować na kategorie: „akceptacja bez wyników”, „akceptacja z wynikami w formie notatki”, „akceptacja z udokumentowanymi wynikami”.

• Przeprowadzać odpowiednie szkolenie członków zespołu i nauczać narzędzi. Szkolenia dotyczące metod powinny być przeprowadzane zarówno na początku, jak i podczas kończenia fazy.

• Przeglądać proces sprawozdawczości. Upewnić się, że odpowiada on i uwidacznia sponsorowi postęp prac nad projektem w taki sposób, który zachęci go do dalszego w nim udziału.

• Jeżeli postanowienia końcowe są trudne do wykonania lub kontrolowania to należy przedstawić analizę kosztów/korzyści lub wartości projektu. To pomoże ujrzeć perspektywę znaczenia procesu i jego funkcje. Ta trudność to zwykle znak „rozłączności” między wartością procesu lub funkcji a kosztem rozwoju, szkoleń i utrzymania.

Porady techniczne

Ten rozdział omawia podstawowe techniki, które mogą okazać się pomocne w przeprowadzeniu fazy analizy. Zawiera też porady i komentarz do każdego procesu.

Zarządzanie projektem

Każdy efekt fazy definicji musi przejść kilka różnych kontroli. Podczas fazy analizy zmiana nadzoru jest szczególnie ważna w zarządzaniu przejściami od modeli biznesu do modeli systemu. Należy zakończyć definiowanie strategii dotyczącej konwersji danych, architektury technicznej, dokumentacji, szkoleń i zmian podczas tej fazy.

Definicja wymagań biznesu

Faza analizy dostarcza przedsiębiorstwu okazję do odejścia od codziennych operacji i umożliwia szersze spojrzenie na swą działalność. Ponieważ ludzie badają i opisuj ą pracę, którą wykonuj ą są często świadomi sposobów, dzięki którym można j ą ulepszyć.

Kierownik zespołu analizy powinien określić stopień odróżnienia między modelami biznesu a systemu podczas tej fazy. Trzy modele systemu zawierają architekturę systemu - są oparte na modelach biznesu i dokumentuj ą przejścia od funkcji do modułów. Ważne jest, aby kontrolować to przejście, jako że zespół analizy przekształca wszystkie trzy modele w tym samym czasie. Powinno się wprowadzić standard dla obszaru automatyzacji decyzji, które są podejmowane podczas przejścia od modeli biznesu do modeli systemu.

Poza wyjściem z uzgodnionego zakresu projektu, obszar automatyzacji decyzji, jeśli nie jest zarządzany, może znacznie zwiększyć poziom wysiłków nad projektem.

Ważne jest, żeby zespół projektowy zrozumiał różnicę między modelowaniem wymagań biznesu a modelowaniem wymagań systemu oraz wpływem architektury client/server na modelowanie wymagań systemu.

Badanie istniejącego systemu

Ten proces należy zakończyć w tej fazie. Zespół powinien udostępnić efekty tego procesu dla wglądu przez zespoły definicji wymagań biznesu, konwersji danych i architektury technicznej. Nastąpić powinien końcowy przegląd, aby zatwierdzić, że uwzględnione zostały wszystkie istniejące funkcje w systemie, lub że nie są one już wymagane.

Architektura techniczna

Definicja stylu interfejsu użytkownika powinna być utworzona jako prototyp i udokumentowana przy wsparciu przyszłych użytkowników. Najlepszy wzór interfejsu balansuje między „wyglądem i czuciem” a możliwościami narzędzia, które ma służyć do implementacji systemu. Dobrze jest bazować na przyjętych standardach, co do częściej wykonywanych funkcji. Dobrze jest nadać priorytet funkcjom według częstości ich używania. Używać go potem należy podczas dokonywania zmian w architekturze technicznej, które mogą okazać się wymagane dla utrzymania funkcji. Konieczne jest upewnienie się, że role, na które powołuje się zespół strategii bezpieczeństwa i kontroli są tymi samymi, które podtrzymuje proces szkolenia.

Konwersja danych

Należy przejrzeć strategię konwersji danych i wyrazić zgodę na konwersję tylko tych danych, które maj ą pewną wartość wejściową dla biznesu. Pola danych w byłych systemach często zmieniaj ą znaczenie w późniejszym czasie (bez znacznika wskazującego zmiany). To sprawia trudności przy automatycznej konwersji danych bez interwencji z zewnątrz, czy też „oczyszczaniu danych”. Trudno jest oszacować zakres koniecznego „oczyszczania danych”, kiedy to faza definicji jest już zakończona.

Sugestia: Wersja „tylko z zapytaniami” istniejącego systemu może złagodzić potrzebę konwersji wszystkich danych.

Dokumentacja

Proces dokumentowania wyników odpowiada potrzebom użytkowników oraz personelowi obsługującemu. Z każdego obszaru wyznaczone zostają środki doradcze, które stają się częścią zarządu planowania. Szczegółowy plan dokumentacji musi identyfikować źródła informacji wymagane przez zespół dokumentujący tak dobrze jak role i zakresy odpowiedzialności dla przeglądania efektów.

Szkolenie

Trzeba się upewnić, że plan szkolenia zawiera wszystkie typy szkolenia, na przykład, szkolenie komputerowe, szkolenie instruktorów, samokształcenie, a także, że identyfikuje wszystkie role, które powinny być zawarte, na przykład, przedstawicieli serwisu klienta, kierowników, kontrolerów płatności rachunków.

Wdrażanie

Planowany typ rozwoju będzie miał wpływ na szkic programów konwersji danych. Zwiększanie zakresu wymaga, aby dane były konwertowane etapami - to inny problem niż konwersja danych na raz. Jeśli strategia konwersji nie jest stała lepiej jest kontynuować podejście zwiększania zmian albo przez jednostkę biznesową, albo przez położenie geograficzne. To podejście ciągle otwiera wiele możliwości.

Estymacja

Poniższa tabela przedstawia typowe procentowe wysiłki wkładane przy wykonywaniu każdego z zadań. Czas nie estymowany oznaczony jest gwiazdką (*).

		Udział	Analityk	Audytorium	Kierownik biznesu	Planujący	Projektant BD	Inżynier sieci	Persone1 obsługi	Kierownik Projektu	Sponsor Projektu	Architekt systemu	Persone1 Pomocy	Expert techniczny	Kierownik zespołu	Pisarz techniczny
ID	Zadanie	%	1	2	3	4	5	6	7	8	9	10	11	12	13	14
Definicja wymagań		46
RD.050	Zbieranie szczegółowych informacji o przedsiębiorstwie	12,9	80								*				20
RD.060	Konstrukcja modelu danych przedsiębiorstwa	6,5	85								*				15
RD.070	Konstrukcja szczegółowego modelu funkcji przedsiębiorstwa	16	85								*				15
RD.080	Konstrukcja modelu danych systemu	1,8	70									20			10
RD.090	Konstrukcja modelu funkcji systemu	5,8	70									20			10
RD.100	Tworzenie modelu procesów systemu	3,1	70								*	20			10
Analiza istniejącego systemu		13
ES.080	Wytwarzanie skorygowanej istniejącej architektury technicznej	0,2								10		90	*
ES.090	Wytwarzanie opisu funkcji istniejącego systemu	6,3	90										*		10
ES.100	Wytwarzanie szczegółowego modelu danych istniejącego systemu	6,5	95										*		5
ES.110	Wytwarzanie opisu istniejących procedur	0,5								*		95			5
Architektura techniczna		13
TA.050	Definiowanie szczegółowych wymagań systemu	3,9							*	15	*	85	*
TA.060	Rozwój podstawowej definicji sprzętu i oprogramowania	0,7	10					20	*			70	*
TA.070	Rozwój architektury podziału	1,4					10					80	*		10
TA.080	Rozwój strategii odzyskiwania i cofania	0,8	15						*			85	*
TA.090	Rozwój strategii bezpieczeństwa i kontroli	0,8	20	*								80	*
TA.100	Rozwój definicji stylu interfejsu użytkownika	1,4	15										*	85
TA.110	Rozwój ulepszania planu pojemnościowego	3,5	10			90
Konwersja danych		10
CY.020	Definiowanie strategii konwersji danych	8,5	100										*
CY.030	Definiowanie planu pracy przy konwersji danych	1,1	80							20			*
Dokumentacja		1
DO.020	Specyfikacja wymagań dokumentacji	0,6			*					5						95
DO.030	Określenie standardów dokumentacji	0,5			*											100
Szkolenie		2
TR.010	Specyfikacja wymagań szkolenia	1,0	95										*		5
TR.020	Definiowanie planu szkolenia	1,1	95										*		5
Wdrożenie		1
TS.020	Definicja wstępnej strategii wdrażania	0,9	95		*								*		5
Zarządzanie projektem		14
PM.000	Faza Zarządzania	14,2								100

Tabela 6-5 Estymacja Faz Projektowania

Planowanie zadań.

Typowy wykres Gantta dla wykonywania fazy Analizy jest przedstawiony poniżej. Ciemne paski wskazują zadania należące do ścieżki krytycznej.

Rysunek 5-5. Planowanie fazy Analizy (skala w tygodniach).

Rolę ścieżki krytycznej w czasie fazy Analizy projektu pełni analityk. Przydzielając większą liczbę analityków do tej fazy można zmniejszyć długość ścieżki krytycznej. Wykonywanie zadań należących do ścieżki krytycznej równolegle także pozwala skrócić jej czas. Poniższa tabela przedstawia niektóre sugerowane przekrywanie się zadań dla fazy Analizy.

ID	Nazwa zadania głównego	ID	Nazwa zadania powiązanego	Przekrycie
B.RD.EXEC	Definicja wymagań przedsiębiorstwa
B.RD.060	Skonstruowanie modelu danych przedsiębiorstwa	B.RD.050	Zebranie szczegółowych informacji o przedsiębiorstwie	50%
		B.ES.090	Wytworzenie opisu istniejących funkcji systemu	50%
B.RD.070	Skonstruowanie szczegółowego modelu funkcji przedsiębiorstwa	B.RD.050	Zebranie szczegółowych informacji o przedsiębiorstwie	50%
B.RD.080	Skonstruowanie modelu danych systemu	B.RD.070	Skonstruowanie szczegółowego modelu funkcji przedsiębiorstwa	50%
		B.RD.060	Skonstruowanie modelu danych przedsiębiorstwa	50%
B.RD.090	Skonstruowanie modelu funkcji systemu	B.RD.070	Skonstruowanie szczegółowego modelu funkcji przedsiębiorstwa	50%
		B.RD.060	Skonstruowanie modelu danych przedsiębiorstwa	50%
B.RD.100	Stworzenie modelu procesów systemu	B.RD.070	Skonstruowanie szczegółowego modelu funkcji przedsiębiorstwa	50%
		B.RD.060	Skonstruowanie modelu danych przedsiębiorstwa	50%
B.TA.EXEC	Architektura techniczna
B.TA.050	Zdefiniowanie szczegółowych wymagań operacyjnych systemu	B.RD.100	Stworzenie modelu procesów systemu	50%
		B.RD.090	Skonstruowanie modelu funkcji systemu	50%
		B.RD.080	Skonstruowanie modelu danych systemu	50%
B.TA.060	Definicja rozwinięcia założeń sprzętowych i programowych
B.TA.070	Rozwinięcie architekturę rozproszenia	B.TA.050	Zdefiniowanie szczegółowych wymagań operacyjnych systemu	50%
B.TA.080	Rozwinięcie strategii odzyskiwania i cofania	B.TA.050	Zdefiniowanie szczegółowych wymagań operacyjnych systemu	50%
B.TA.090	Rozwinięcie strategii ochrony i kontroli	B.TA.050	Zdefiniowanie szczegółowych wymagań operacyjnych systemu	50%
B.TA.100	Rozwinięcie definicji stylu interfejsu użytkownika	B.TA.050	Zdefiniowanie szczegółowych wymagań operacyjnych systemu	50%
B.TA110	Rozwinięcie zrewidowanego planu wydajności	B.TA.050	Zdefiniowanie szczegółowych wymagań operacyjnych systemu	50%
B.CV.EXEC	Konwersja danych
B.CY.020	Definiowanie strategii konwersji danych	B.TA.090	Rozwinięcie strategii ochrony i kontroli	50%
		B.TA.070	Rozwinięcie architekturę rozproszenia	50%
		B.TA.060	Definicja rozwinięcia założeń sprzętowych i programowych	50%
B.TR.EXEC	Szkolenie
B.TR.010	Zdefiniowanie wymagań szkoleniowych	B.TA.060	Definicja rozwinięcia założeń sprzętowych i programowych	50%
B.TS.EXEC	Okres przejściowy
B.TS.010	Zdefiniowanie wstępnej strategii wdrażania	B.TR.020	Zdefiniowanie planu szkolenia	50%
		B.TR.030	Zdefiniowanie planu pracy przy konwersji danych	50%

Tabela 5-6. Przesłanianie zadań w fazie Analizy.

---