AIM Metodologia wdrożenia
Oracle Applications
2
AIMMetoda Wdrażania Aplikacji Oracle
• Sposób wdrażania pakietów oprogramowania standardowego
• Zestaw powiązanych zadań - zorientowanych na efektywne wdrożenie aplikacji
• Narzędzia do planowania, wykonywania i kontrolowania prac projektowych
• Doświadczenie wielu wdrożeń
3
AIM nie jest to:
• Gotowa recepta na prowadzenie projektu
• Gwarancja realizacji w terminie i w zakresie określonym kontraktem
4
Czym jest AIM ?
Zestaw instrukcji określających: CO – lista zadań do wykonania i produktów KTO – lista ról i odpowiedzialności DLACZEGO – cel poszczególnych zadań KIEDY – współzależności między zadaniami JAK – instrukcje, techniki, szablony
Narzędzia programowe do generowania szablonów dokumentów
Szablony
Dokumentacja opisująca metodologię
5
Elastyczność Zastosowania AIM w projekcie• Dopasowanie do
potrzeb projektu Jest dopasowywana do konkretnych
potrzeb wynikających z wielkości i charakteru wdrożenia
• Podprojekty Została stworzona z myślą o
skalowalności
• Wdrożenia innych aplikacji
Ma zastosowanie od najmniejszych i najprostszych wdrożeń po największe i najbardziej skomplikowane
Aplikacja 3
Aplikacja 2
Aplikacje Oracle
6
Zalety korzystania z AIM
Dla zespołu projektowego:
Dobrze zdefiniowany plan projektu
Wyższa jakość wyników
Skrócona krzywa uczenia
Dla organizacji klienta:
Projekty dostarczane zgodnie z harmonogramem i budżetem
Zmniejszenie ryzyka / zwiększenie zaufania
Lepsza komunikacja
7
Metodologia AIM – podsumowanie
• Sposób wdrażania pakietów oprogramowania standardowego Oracle Application
• Elastyczna, skalowalna, zoptymalizowana do projektów średnich i dużych
• Zorientowana na procesy projektowe
• Możliwa do wykorzystania na wiele sposobów
• Zawiera narzędzia do planowania, wykonywania i nadzorowania prac projektowych
8
Zależność między zadaniami
Podstawowe składniki AIM
Produkt
Proces
RD.030Utwórz model przysz³ych procesów
RD.030Utwórz model przysz³ych procesów
RD.030Utwórz model przysz³ych procesów
RD.030Utwórz model przysz³ych procesów
RD.020 Utwórz model istniej¹cych procesów
RD.020 Utwórz model istniej¹cych procesów
Narzędzie
Zadanie
Podejście do projekt
9
Zadanie
• Podstawowe realizowane zadanie
• Jego wynikiem jest jeden produkt
RD.010
RD.020
RD.030
RD.040
RD.010
RD.020
RD.030
RD.040
JAN FEB MAR APR MAY JUN
BR.020
Mapowaniewymagań
BR.020
Formularzmapowaniawymagań
10
AIM
Produkt
• Wiele typów i formatów:
– Plan
– Dokument opisowe
– Kod programu
– Wyniki testów
• Kryterium jakości - cel, zakres informacyjny
• Akceptacja przez Klienta
MODEL PROCESÓWBIEŻĄCYCH
PKO BP SA
Autor: Jak KowalskiData Utowrzenia: 13.06.2001Ostatnia Aktualizacja: 13.06.2001Numer Kontrolny: 00001Wersja: 1
11
Zależności pomiędzy zadaniami
• Relacje pomiędzy zadaniami
• Sekwencje zadań
• Powiązania przez wspólne produkty
BR.020
FormularzMapowaniaWymagań
BR.020
Mapowaniewymagań
biznesowych
BR.100
DefinicjaParametryzcji
Systemu
BR.090
Potwierdzenierozwiazania
BR.100
DokumentParametryzacji
Systemu
BR.090
CertyfikatAkceptacji
12
Procesy
• Blisko powiązana grupa zadań, w wyniku których zrealizowany jest pewien ogólny cel
• Wynikiem procesu jest jeden lub więcej produktów o zasadniczym znaczeniu dla projektu
13
Fazy
• Chronologiczne grupowanie zadań
• Umożliwia
– lepszą organizację zadań
– planowanie podstawowych produktów
– optymalną realizację projektów w czasie
CzasCzas
14
AIM - szczególny zbiór podstawowych elementów
• Sześć Faz• 10 Procesów
(bez PJM)• 130 Zadań /
Produktów• Zoptymalizowane
powiązania zadań i procesów
15
AIM: fazy i procesy
Definicja AnalizaOperac.
ProjektRozw.
Budowa EksploatacjaPrzejście
Analiza O
peracyjna
Analiza O
peracyjna
Projekt r
ozwiąza
nia
Projekt r
ozwiąza
nia
Definicja
Definicja
Eksploatacja
Eksploatacja
Budowa
Budowa
Przejście
Przejście
– Definiowanie wymagańDefiniowanie wymagań– Mapowanie wymagańMapowanie wymagań– Architektura TechnicznaArchitektura Techniczna– Projektowanie i BudowaProjektowanie i Budowa– Konwersja DanychKonwersja Danych– DokumentacjaDokumentacja– Testowanie systemuTestowanie systemu– Testowanie wydajnościoweTestowanie wydajnościowe– SzkoleniaSzkolenia– Przejście do eksploatacjiPrzejście do eksploatacji
ProcesyProcesy
Zarządzanie projektemZarządzanie projektem
16
Pakiet AIM 3.0 Advantage zawiera: fazy i procesy
Szablony elektroniczne Podręczniki
Szablony planu projektu
Szablony ProduktówPodręczniki on-line
Method HandbookProcess & Task ReferenceDeliverable ReferenceStandards & Guidelines
17
Proces może być opisany jako zbiór powiązanych celów, wymagań co do zasobów, danych wejściowych i produktów końcowych.
Procesy w projekcie AIM
Architektura BiznesowaDefinicja Wymagań
Mapowanie Wymagań FunkcjonalnychArchitektura Aplikacji i TechnicznaProjektowanie i Budowa Modu³ów
Konwersja DanychDokumentacja
Funkcjonalne Testy SystemuTesty Wydajnościowe
SzkoleniaMigracja
BR
TA
MD
CV
DO
TE
PT
TR
PM
RD
AP
18
Proces Definiowania Wymagań Biznesowych
Katalog wymagańbiznesowych
Wnioski z eksploatacjisystemów
informatycznych
Procesy przyszłe
Scenariuszewymagań
biznesowych
Katalog wymaganych
raportów
Procesybieżące
19
Proces Odwzorowywania Wymagań Funkcjonalnych
Scenariusze wymagańbiznesowych orazprocesy przyszłe
Koncepcja architekturysystemu
Odwzorowaniewymagań
biznesowych
Dokumentyparametryzacji
systemu
Model dostępu do informacji /
definicje autoryzacji
Parametryzacjaaplikacji
20
Proces Projektowania i Budowy Modułów
Katalogwymaganych
raportów
Środowiskoprodukcyjne
Opracowanieprojektów
funkcjonalnychKodowanie kastomizacji
Wykonanie testówjednostkowych
Procesy Przyszłe
Dokumentacjaparametryzacji
aplikacji
Instalacjakastomizacji
Środowiskodo developmentu
Architekturainterfejsów
Opracowanielisty kastomizacji
21
Proces Konwersji Danych
Cele, Zakres iSposób Realizacji
Środowiskoprodukcyjne
Opracowanieprogramów do
konwersji danychPrzygotowanie
środowiskatestowego
Przygotowanietestowego B.O.
Procesy Przyszłe
OpracowanieStrategii Konwersji
Dokumentacjaparametryzacji
aplikacji
Wykonanie testówkonwersji danych
Dostarczenie rzeczywistego
B.O.
Wykonanie konwersjidanych do nowego
systemu
22
Proces Testowania Systemu
Cele, Zakres iSposób Realizacji
ScenariuszeWymagań
Biznesowych
Dokumentacjaparametryzacji
aplikacji
Kastomizacje
OpracowanieStrategii Testowania
Systemu
Opracowaniescenariuszytestowania
Przygotowanieśrodowiskatestowego
Przygotowaniedanych testowych
Wykonanie testówwstępnych
Modyfikacjepotestowesystemu
Wykonanie testówakceptacyjnych
23
Proces Szkoleniowy
Cele, Zakres iSposób Realizacji
OpracowanieStrategii Szkoleń
Przeprowadzenieszkoleń ZespołuProjektowego
Przygotowanieśrodowiska
szkoleniowego
Przeprowadzenieszkoleń użytkowników
końcowych
Dokumentacjaparametryzacji
aplikacji
Dokumentacjaszkoleniowa
24
Proces Migracji
Cele, Zakres iSposób Realizacji
StrategiaKonwersji Danych
ArchitekturaAplikacji
Koordynacja ikontrola realizacji zadań
w pozostałychprocesach
Opracowanie Strategii Migracji
Dokumentacjaparametryzacji
aplikacji
Dokumentacjastanowiskowa
Opracowanie Szczegółowego Planu Migracji
Przygotowanieśrodowiska
produkcyjnego
Definicja Analiza Operacyjna
Projekt Rozwiązania
Budowa Przejście Produkcja
Podstawowe zadania wdrożenioweFaza Definicji
ProcesBie¿¹cy
ProcesPrzysz³y
Model Funkcyjny
Modelowanie ProcesówUwagi praktyczne
• Diagramy należy tworzyć z myślą o ekranach/raportach aplikacji
• Zbyt wiele elementów decyzyjnych może wskazywać potrzebę przeprojektowania
• Należy definiować początek i koniec procesu
• Należy sprawdzać czy zdarzenia się nie pokrywają
• Należy łączyć wynik jednego procesu z początkiem następnego
Modelowanie ProcesówStandardy modelowania
D024: Przyjęcie Zamówienia
Urzędnik wprowadzaj¹cy
Planista
E001 OR.010
Wprowadź Zamówienie
OR.020
SprawdźAutoryzacjê
KartaKredyt. ?
Potwierdzona?
OR.030
ZaksięgujZamówienie
OR.040
Wci¹gnijZamówienie
na listę
OR.050
WyślijPotwierdzenieZamówienia
1
OEBaza Danych
E020
Zdarzenie (wyzwalające) Krok procesu
Krok ręczny
Obszar odpowiedzialności
Decyzja
Możliwość poprawy
Zdarzenie (wynikowe)
Baza danych
Modele procesówProcesy bieżące i przyszłe
• Ulepszenia procesów
• Nowa technologia
D024: Order Receipt
Entry Clerk
Scheduler
E001
OR.010
Enter Order
OR.020
Get Authorization
CreditCard?
Approved?
OR.030
Book Order
OR.040
Schedule Order
OR.050
Send OrderConfirmation
1
OEDatabase
E020
D024: Order Receipt
Entry Clerk
E001
OR.010
Enter Order
OR.020
Check Credit
Approved?
OR.030
Book Order
OR.040
Schedule Order
OR.050
Send OrderConfirmation
E020
• Które procesy są realizowane w ramach standardowej aplikacji?
Model Procesów PrzyszłychUwagi praktyczne
• Należy powiązać ulepszenia z celami i zadaniami zawartymi w dokumencie ‘Zakres, Cele i Sposób Realizacji’
• AIM zawiera 3 rodzaje modeli procesów
– Procesy Biznesowe
– Modele Wspomagane Przez Aplikację
– Przepływy Testujące Integrację
31
Definicja Analiza Operacyjna
Projekt Rozwiązania
Budowa Przejście Produkcja
ProcesBie¿¹cy
ProcesPrzysz³y
Model Funkcyjny
BRS
BRMForm
DokumentRozwi¹zañ
Ok
Podstawowe zadania wdrożenioweFaza Analizy Operacyjnej
Odwzorowanie Procesów Uwagi praktyczne
• Tworzenie odwzorowań wymaga znajomości funkcjonalności Aplikacji Oracle
• Odwzorowania wykonujemy na poziomie elementarnych funkcji biznesowych
• Odwzorowywane są zarówno dane jak i procesy
• Odwzorowywane muszą być też dane z poprzedniego systemu
Odwzorowanie ProcesówModel Przyszłych Procesów
D024: Przyjęcie Zamówienia
UrzędnikWprowa-dzający
E001
\Nav Orders Enter
OR.010
WprowadźZamówienie
\Nav Orders CycleAction
OR.020
Sprawdź Kredyt
Potwierdzony?
\Nav Orders Enter
OR.030
ZaksięgujZamówienie
\Nav Orders View
OR.040
WciągnijZamówieniena listę
OR.050
WyślijPotwierdzenieZamówieniaE020
Wymaganedostosowanie aby
automatycznie wysłaćpotwierdzeniezamówienia
Odwzorowanie Procesów Przykładowe produkty
Szczegółowe szablony:
• RD.020 - Modele Procesów Obecnych
• RD.030 - Modele Procesów Przyszłych
• RD.070 - Scenariusze Wymagań Biznesowych
• BR.020 - Mapowanie Wymagań Biznesowych
Szacowanie nakładów pracy na dostosowania
• MD.020 - Definicja i Szacowanie Dostosowań
• Elementy dostosowań:
– Nowe i modyfikowane formatki, raporty, programy
– wyzwalacze bazy danych
– skrypty SQL*Loader
– Alerty
– nowe tablice
• Przypisuje się stopień złożoności
– Bardzo Proste
– Proste
– Średnie
– Skomplikowane
39
Definicja Analiza Operacyjna
Projekt Rozwiązania
Budowa Przejście Produkcja
ProcesBie¿¹cy
ProcesPrzysz³y
Model Funkcyjny
BRS
SetupAplikacji
SkryptyTestu
Systemu
BRMForm
DokumentRozwi¹zañ
OkProjekt
Specyficz.
SkryptyTestu
Specyficz.
Podstawowe zadania wdrożenioweFaza Projektu Rozwiązania
Definiowanie Parametrów Aplikacji
• Parametry są głównym produktem procesu Odwzorowania Wymagań Funkcjonalnych
• Szablony AIM - BR.110
Opracowanie Planu Testów
• Przekształcenie Scenariuszy Odwzorowań w plany testów
• Planowanie testów w fazie Projektu Rozwiązania, ich wykonanie w fazie Budowy
ELEMENT SYSTEMUINTEGRACJA
SYSTEMPOŁĄCZENIE
Tworzenie Planów Testów Dla Scenariuszy Odwzorowań
Wszystkie potrzebne i powstające informacje są częścią dokumentu Scenariuszy
– Zaczynamy od Odwzorowanego modelu przyszłych procesów
– Śledzimy wszystkie ścieżki modelu
– Każda ścieżka daje Scenariusz
– Dla każdego scenariusza należy
• określić profil danych
• opracować plan testów
43
Definicja Analiza Operacyjna
Projekt Rozwiązania
Budowa Przejście Produkcja
ProcesBie¿¹cy
ProcesPrzysz³y
Model Funkcyjny
BRS
SetupAplikacji
SkryptyTestu
Systemu
WykonanieTestu
Systemu
BRMForm
DokumentRozwi¹zañ
OkProjekt
Specyficz.
SkryptyTestu
Specyficz.
TworzenieModu³ówSpecyficz.
TestowanieModu³ów
Specyficzn.
Podstawowe zadania wdrożenioweFaza Budowy
45
Definicja Analiza Operacyjna
Projekt Rozwiązania
Budowa Przejście Produkcja
ProcesBie¿¹cy
ProcesPrzysz³y
Model Funkcyjny
BRS
SetupAplikacji
SkryptyTestu
Systemu
WykonanieTestu
Systemu
BRMForm
DokumentRozwi¹zañ
OkProjekt
Specyficz.
SkryptyTestu
Specyficz.
TworzenieModu³ówSpecyficz.
TestowanieModu³ów
Specyficzn.
Eksploatacja
Podstawowe zadania wdrożenioweFaza Przejścia
46
Przejście do eksploatacji
Przygotowanie środowiska produkcyjnego
Ustanowienie wsparcia w trakcie eksploatacji
Przejście do eksploatacji
Dopasowanie i strojenie systemu tak, aby odzwierciedlał zmiany organizacji
Określenie dalszych kierunków rozwoju
48
Zarządzanie projektem a AIM
Planowanie projektu
Kontrola faz Zamknięcie projektu
• Planowanie Fazy• Kontrola Fazy• Zamkniêcie fazy
1 2 3 4 5 6
Fazy
49
Czynniki decydujące o sukcesie projektu ...
1. Zaangażowanie klienta
2. Wsparcie Zarządu firmy
3. Szczegółowo zdefiniowana specyfikacja wymagań
4. Efektywne planowanie/ zarządzanie projektem
5. Realistyczne oczekiwania
Standish Group, 1994
50
Zarządzanie Projektami
CZAS
KOSZT JAKOŚĆ
51
Współczesne Zarządzanie Projektami
CZAS
KOSZT JAKOŚĆ
52
Dokumenty zarządzania projektem
CR.010 Cele Zakres i Sposób Realizacji cele osiągnięte poprzez wdrożenie systemu, zakres funkcjonalny
wdrożenia, sposób realizacji projektu
CR.030 Procedury Projektowe procedury projektowe określające sposoby postępowania w zakresie
zarządzania i kontroli wdrożenia oraz organizację zespołu projektowego
CR.035 Plan Projektu harmonogram realizacji projektu
53
Zarządzanie Projektem
Kontrola Projektu
Realizacja Planu Projektu
Kontrola i śledzenie zadań
Kontrola i śledzenie finansów
Zarządzanie zasobami ludzkimi
Zarządzanie komunikacją
Zarządzanie Jakością
Zarządzanie Ryzykiem
Zarządzanie Zmianami
Zarządzanie Konfiguracją
Zarządzanie kontraktem i zakupami
54
HISTORIA Z ŻYCIA
Było ważne zadanie do zrobienia i każdy został poproszony o jego wykonanie.Każdy przypuszczał, że ktoś je wykona.Ktokolwiek mógł to zrobić, ale nie zrobił tego nikt.Ktoś się z tego powodu zdenerwował, ponieważ to była praca każdego.Każdy myślał, że ktokolwiek może to zrobić, wszyscy nie zdali sobie sprawy , że nikt tego nie zrobi.Skończyło się na tym, że każdy winił kogoś, podczas gdy nikt nie mógł winić kogokolwiek.
Można było winić WSZYSTKICH.
KAŻDY KTOKOLWIEK KTOŚ NIKT
55
Plan zasobów i organizacja projektuDokument Plan Zasobów i Organizacja Projektu zawiera:
• opis ról pełnionych przez członków Zespołu Projektowego,
• zakresy odpowiedzialności i obowiązków członków Zespołu Projektowego,
• strukturę organizacyjną Zespołu Projektowego,
• procedurę zarządzania zasobami.
Dokument ten nie zawiera nazwisk członków Zespołu Projektowego ani
liczebności poszczególnych ról w Zespole.
Struktura projektu i role projektowe
Adm inistratorprojektu
(bibliotekarz)
Kom itet Sterujący
Przedstaw icieleZleceniodaw cy
Przedstaw icieleW ykonaw cy
KontrolaJakości
Sponsorprojektu
Adm instratorsystem u
ZespółW drożeniow y Zespół
program istów
KoordynatorProjektuze strony
Zlecenodaw cy
Kierow nik ProjektuCL
Użytkow nicykluczow i
57
Plan zasobów i organizacja projektu Komitet Sterujący Projektu
Zadaniem Komitetu jest: · zatwierdzanie planów projektu; · nadzorowanie przebiegu prac i koordynacja czynności stron projektu;· podejmowanie decyzji w kwestiach dotyczących projektu eskalowanych
do poziomu KSP; · autoryzowanie znaczących zmian w projekcie;· przydział zasobów ze strony Nabywcy (ludzie, sprzęt, budżet);
Komitet Sterujący Projektu reprezentuje, na poziomie kadry
zarządzającej, interesy biznesowe Klienta, zabezpiecza wymagania przyszłego
użytkownika systemu oraz uwzględnia punkt widzenia i kompetencje dostawcy rozwiązania.
58
Plan zasobów i organizacja projektu Role w Komitecie Sterującym
Sponsor
reprezentuje interesy Nabywcy w kwestiach kluczowych dla przebiegu projektu. Jest to osoba uprawniona do podejmowania decyzji finansowych i osobowych. Odpowiada za powodzenie projektu. Pełni funkcję Przewodniczącego KSP.
Przedstawiciele Użytkownika
odpowiedzialni są za prawidłowe zdefiniowanie wymagań i monitorowanie, że dostarczone rozwiązanie spełnia te wymagania, oraz za uzasadnienie biznesowe. Rola ta reprezentuje interesy wszystkich użytkowników systemu.
Przedstawiciele Wykonawcy
są odpowiedzialni za jakość produktów dostarczanych przez Wykonawców, a także za to, że proponowany projekt rozwiązania i jego implementacji jest realistyczny. Mają autoryzację do podejmowania decyzji dotyczących przydzielania zasobów ze strony Wykonawców do realizacji Projektu.
59
Plan zasobów i organizacja projektu Zarząd Projektu
Zarząd Projektu jest odpowiedzialny za
• bieżące sterowanie pracami projektowymi,
• rozwiązywanie problemów eskalowanych przez zespoły projektowe
• zarządzanie ryzykiem projektowym,
• efektywny postęp prac zgodnie z ustalonymi harmonogramami oraz wykorzystanie przydzielonych zasobów.
• bieżącą kontrolę przebiegu prac oraz ich zgodność z przyjętymi celam projektu.
60
Procedura Kontroli Zmian
Procedura określa zasady stosowane w przypadku konieczności wprowadzenia zmian i/ lub poprawek w ustalonej specyfikacji lub zakresie projektu.
Zmiana w projekcie może wynikać ze zmiany:• zakresu projektu (ustalonego obszaru prac) • specyfikacji rozwiązania (specyfikacji uzgodnionych produktów, sposobu ich
realizacji w tym również czasu ich realizacji). Każda ze stron Umowy może zaproponować zmiany lub poprawki do realizowanego
projektu.
61
Procedura Kontroli Zmian
Procedura Kontroli Zmian wykorzystuje dwa formularze:
1. Formularz Zgłoszenia Zmiany
2. Rejestr Zmian
62
Procedura Zarządzania Konfiguracją
Zarządzanie Konfiguracją określa techniki i procedury wykonywania następujących czynności:
- określenie produktów, które wymagają zarządzania,
- określenie osób odpowiedzialnych za poszczególne produkty,
- rejestracja, monitorowanie i raportowania stanu, w jakim znajdują się poszczególne produkty w trakcie realizacji przedsięwzięcia,
- kontrolowanie wersji produktów,
- przechowywanie dokumentacji opracowanej w czasie realizacji przedsięwzięcia dla poszczególnych produktów,
- zarządzanie zmianami dotyczącymi poszczególnych produktów
63
Procedury Komunikacji
Procedury Komunikacji określają następujące aspekty zarządzania projektem :
• raportowanie zaawansowania projektu,• spotkania projektowe,• zarządzanie korespondencją i dokumentacją projektową,• standardy środków komunikacji,• procedury rozwiązywania problemów projektowych,
• procedury eskalacji problemów.
64
Procedury Komunikacji
• Formularz Tygodniowy Raport Postępu Prac
• Formularz Raportu na Komitet Sterujący
65
Procedury Komunikacji
• Formularz Agenda Spotkania
• Formularz Notatka ze Spotkania
66
Procedury Komunikacji
• Formularz Zgłoszenie Problemu
• Formularz Rejestru Problemów
67
Procedury Komunikacji
• Harmonogramy projektów – MS Project 98
• Formularz Plan Działań
• Formularz Zlecenia Zadania
Bibliotekarz
• Sporządzanie notatek ze spotkań
• Zarządzanie bazami projektowymi (dodawanie do bazy nowo powstałych dokumentów)
• Opieka nad wersjami istniejących dokumentów
• Zarządzanie dokumentacją pisemną
• Sporządzanie odpowiednich dokumentów opisanych w procedurach projektowych (np. zarządzanie zmianą, rozwiązywanie problemów).
Struktura biblioteki
--> Nazwa Projektu-----> AIM (Metodologia, szablony, dokumentacja itp..)-----> Dokumenty wewnętrzne (np. od Klienta)-----> Notatki ze spotkań
----> moduł A----> moduł B----> Zarządcze----> Spotkania (zawiadomienia o spotkaniach)
----> Pisma----> Wchodzące----> Wychodzące
----> Plany projektu (Harmonogramy)----> Prezentacje (na spotkania u Klienta, w tym
prezentacje wyników prac)----> Produkty
----> Faza 1----> Faza 2 itd.
----> Protokoły----> Umowy, aneksy
Archiwizowanie dokumentów
• Katalog roboczy i archiwalny
• Pilnowanie wersji i przeglądów
• Zawsze aktualne archiwum
Rejestry
XXX-PRL-001 Rejestr Problemów
XXX-PRT-001 Zgłoszenie problemu
XXX-CRL-001 Rejestr żądań zmian
XXX-CRF-001 Żądanie zmiany
Harmonogram
• Podstawa do wyznaczania zadań konsultantom.
• Odzwierciedlenie postępu wykonywanych prac.
• Narzędzie do „wczesnego ostrzegania”
• Podstawa do sporządzania raportów tygodniowych i miesięcznych
73
Podstawowe zadania - faza definicji
RD.030 Procesy Przyszłe opis przyszłych (docelowych) procesów biznesowych, obejmuje
również zasady tworzenia planu kont
CV.010 Strategia Konwersji Danych zakres konwersji danych, sposoby konwersji, metody wyboru
sposobu konwersji, sposoby weryfikacji poprawności danych po konwersji, podział odpowiedzialności pomiędzy klienta a wykonawcę
74
Podstawowe zadania- faza analiza operacyjna
BR.010 Dokumentacja Instalacji Aplikacji raport z parametrów instalacji aplikacji oraz bazy danych (w tym
rozmieszczenie na dyskach), specyfikacja dostarczonego sprzętu dla obu serwerów
BR.020 Odwzorowanie Wymagań opis jak niestandardowe wymagania funkcjonalne będą realizowane
za pomocą funkcji systemu, specyfikacja niezbędnych modyfikacji funkcjonalności aplikacji
BR.070 Wymagania w Zakresie Raportowania katalog raportów wymaganych przez klienta wraz z metodą realizacji
75
Podstawowe zadania- faza analiza operacyjna
TA.060 Strategia Zapewnienia Dostępności Systemu opis w jaki sposób będą realizowane wymagania techniczne systemu
TA.100 Architektura Interfejsów opis interfejsów z innymi systemami informatycznymi, opis
sposobów wymiany danych
TA.130 Architektura Funkcjonalna Systemu opis architektury funkcjonalnej systemu zawierającej specyfikację
powiązań z systemami zewnętrznymi
76
Podstawowe zadania- faza analiza operacyjna
MD.020 Opis rozszerzeń systemu lista zatwierdzonych modyfikacji ze sposobem realizacji, terminem i
nakładem pracy
PM.010 Strategia migracji do nowego systemu opis strategii migracji: wymagane działania, plan realizacji,
wymagane zasoby, plan awaryjny na wypadek niepowodzenia
77
Podstawowe zadania- faza projekt rozwiązania
BR.110 Parametryzacja Systemu parametry setup’ów dla poszczególnych modułów systemu
TA.160 Dokumentacja Techniczna dokumentacja techniczna (po wykonawcza) opisująca konfigurację
systemu operacyjnego, sieci, stacji roboczych, opracowana przez członków zespołu technicznego
TA.190 Administracja Systemem opis procedur administracyjnych serwera bazy danych i aplikacji,
opracowany przez członków zespołu technicznego
78
Podstawowe zadania- faza projekt rozwiązania
MD.060 Projekt Funkcjonalny Rozszerzeń opis funkcjonalny modyfikacji; na podstawie listy rozszerzeń
funkcjonalnych uzgodnionych w dokumencie MD.020 Opis rozszerzeń systemu; zawiera projekt funkcjonalny interfejsów
TE.020 Scenariusze Testowania opis scenariuszy testowych, profili danych, kryteria akceptacji, na
podstawie dostarczonych przez ComputerLand standardowych scenariuszy
PM.030 Szczegółowy Plan Migracji plan migracji do nowego systemu.
79
Podstawowe zadania- faza budowy
DO.070 Dokumentacja Stanowiskowa instrukcje stanowiskowe, na podstawie dostarczonych przez ComputerLand
standardowych instrukcji
MD.110 Programy rozszerzeń kod źródłowy modyfikacji oprogramowania
TE.140 Wyniki Testów Akceptacyjnych protokoły z wykonanych testów akceptacyjnych, zawierające stwierdzenia o
spełnieniu lub nie kryteriów testu
CR.080 Certyfikat Akceptacji stwierdzenie, że system spełnia wymagania klienta
80
Podstawowe zadania- faza przejścia
CV.140 Raport z Przeniesienia Danych raport z przeniesienia danych stwierdzający ich poprawność w
nowym systemie
CR.080 Raport ze Szkoleń Użytkowników Końcowych protokoły z przeprowadzenia szkoleń dla użytkowników końcowych
CR.080 Protokół gotowości przekazania do eksploatacji protokół stwierdzający poprawność konfiguracji środowiska systemu,
poprawność wyników testów akceptacyjnych, przeszkolenie użytkowników końcowych, poprawność przeniesionych danych
81
Podstawowe zadania- faza eksploatacji
CR.080 Protokół zakończenia wdrożenia systemu protokół stwierdzający zakończenie wdrożenia systemu wizualizacja sekwencji zadań przypisanie wykonawcy do każdego zadania zaznaczone kamienie milowe odpowiednio częste punkty kontrolne
AIM a wymagania ISO
• ISO dotyczy całego zespołu projektowego.
• Konieczność przestrzegania procedur i metodologii projektowej
• Konieczność dbałego dokumentowania tworzonych kastomizacji i raportów