1. AIM
Metodologia wdrożenia
Oracle Applications

2. AIM
Metoda 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ń
2

3. AIM nie jest to:
• Gotowa recepta na prowadzenie projektu
• Gwarancja realizacji w terminie i w zakresie
określonym kontraktem
3

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

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 Aplikacje Oracle
najbardziej skomplikowane
Aplikacja 2
Aplikacja 3
5

6. Zalety korzystania z AIM
Dla organizacji klienta: Dla zespołu projektowego:
 Projekty dostarczane zgodnie z  Dobrze zdefiniowany plan
harmonogramem i budżetem projektu
 Zmniejszenie ryzyka /  Wyższa jakość wyników
zwiększenie zaufania
 Skrócona krzywa uczenia
 Lepsza komunikacja
6

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
7

8. Podstawowe składniki AIM
Zależność między
Produkt Zadanie zadaniami
RD.030 RD.020 RD.030
Utwórz model Utwórz Utwórz
przysz³ych model model
istniej¹cych przysz³ych
procesów
procesów procesów
Podejście
Proces do Narzędzie
projekt
8

9. Zadanie
JAN FEB MAR APR MAY JUN
RD.010
• Podstawowe realizowane RD.020
zadanie RD.030
RD.040
BR.020
BR.020
• Jego wynikiem jest jeden Formularz
produkt Mapowanie mapowania
wymagań wymagań
9

10. Produkt
• Wiele typów i formatów:
– Plan
– Dokument opisowe
– Kod programu
MODEL PROCESÓW
– Wyniki testów BIEŻĄCYCH
• Kryterium jakości - cel, PKO BP SA
zakres informacyjny
Autor: Jak Kowalski
• Akceptacja przez Klienta Data Utowrzenia:
Ostatnia Aktualizacja:
13.06.2001
13.06.2001
Numer Kontrolny: 00001
Wersja: 1
AIM
10

11. Zależności pomiędzy zadaniami
• Relacje pomiędzy zadaniami
• Sekwencje zadań
• Powiązania przez wspólne produkty
BR.020 BR.020 BR.100 BR.100
Mapowanie Formularz Definicja Dokument
wymagań Mapowania Parametryzacji
Parametryzcji
biznesowych Wymagań Systemu
Systemu
BR.090 BR.090
Certyfikat
Potwierdzenie
Akceptacji
rozwiazania
11

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
12

13. Fazy
• Chronologiczne
grupowanie zadań
• Umożliwia
– lepszą organizację zadań
– planowanie
podstawowych
produktów
– optymalną realizację
projektów w czasie
Czas
13

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
14

15. AIM: fazy i procesy
a a
jn ani
Zarządzanie projektem acy iąz
p er zw a cja
a a O t ro a ście loat
icj liz jek ow ej p
Procesy fin na ro d rz ks
De A P Bu P E
Definicja Analiza Projekt Budowa Przejście Eksploatacja
Operac. Rozw.
– Definiowanie wymagań
– Mapowanie wymagań
– Architektura Techniczna
– Projektowanie i Budowa
– Konwersja Danych
– Dokumentacja
– Testowanie systemu
– Testowanie wydajnościowe
– Szkolenia
– Przejście do eksploatacji
15

16. Pakiet AIM 3.0 Advantage zawiera: fazy i
procesy
Szablony elektroniczne Podręczniki
 Szablony planu  Method Handbook
projektu  Process & Task Reference
 Szablony Produktów 
Deliverable Reference
 Podręczniki on-line 
Standards & Guidelines
16

17. Procesy w projekcie AIM
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.
AP
Architektura Biznesowa
RD
Definicja Wymagań
BR
Mapowanie Wymagań Funkcjonalnych
TA
Architektura Aplikacji i Techniczna
Projektowanie i Budowa Modu³ów MD
Konwersja Danych CV
Dokumentacja DO
Funkcjonalne Testy Systemu TE
Testy Wydajnościowe PT
Szkolenia TR
Migracja PM
17

18. Proces Definiowania Wymagań Biznesowych
K atalog wym agań
K atalog
b izne s owych
wym aganych
rap ortów
P roce s y P roce s y
Wnios ki z b ie żące p rzys z łe
eks ploatacji
s ys temów
informatycznych
S ce nariu s ze
wym agań
b izne s owych
18

19. Proces Odwzorowywania Wymagań
Funkcjonalnych
D oku m e nty
S ce nariu s ze wym agań
p aram e tryzacji
b izne s owych oraz
s ys te m u
p roce s y p rzys z łe
O d wzorowanie
wym agań
b izne s owych
Parametryzacja
aplikacji
K once p cj arch ite ktu ry
a
s ys te m u
Mod e l d os tęp u
d o inform acj /
i
d e finicj au toryzacj
e i
19

20. Proces Projektowania i Budowy Modułów
D oku m e ntacja
Środ owis ko
p aram e tryzacji
d o d e ve lop m e ntu
P roce s y P rzys z łe ap likacji
Opracowanie
projektów
Kodowanie
funkcjonalnych
Opracowanie kas tomizacji
lis ty kas tomizacji
Katalog
wym aganych
rap ortów
Wykonanie tes tów
jednos tkowych
Arch ite ktu ra
inte rfe j ów
s
Ins talacja
kas tomizacji
Środ owis ko
p rod u kcyj
ne
20

21. Proces Konwersji Danych
D oku m e ntacja
p aram e tryzacji
P roce s y P rzys z łe ap likacji
Opracowanie
programów do Przygotowanie
konwers ji danych ś rodowis ka
Opracowanie tes towego
S trategii Konwers ji
C e le , Zakre s i
S p os ób R e alizacji
Przygotowanie
tes towego B .O.
Wykonanie konwers ji
danych do nowego Środ owis ko
s ys temu p rod u kcyjne
Dos tarczenie Wykonanie tes tów
rzeczywis tego konwers ji danych
B .O.
21

22. Proces Testowania Systemu
D oku m e ntacja
p aram e tryzacji
S ce nariu s ze ap likacji
Wym agań Opracowanie
Bizne s owych s cenarius zy Przygotowanie
Opracowanie tes towania ś rodowis ka
S trategii Tes towania tes towego
S ys temu
C e le , Zakre s i
S p os ób R e alizacji
Przygotowanie
danych tes towych
K as tom izacj
e
Wykonanie tes tów
akc eptacyjnych
Modyfikacje Wykonanie tes tów
potes towe ws tępnych
s ys temu
22

23. Proces Szkoleniowy
D oku m e ntacja
p aram e tryzacji
ap likacji
Opracowanie Przeprowadzenie Przygotowanie
S trategii S zkoleń s zkoleń Zes po ł u ś rodowis ka
C e le , Zakre s i Projektowego s zkoleniowego
S p os ób R e alizacji
D oku m e ntacj
a
s zkole niowa
Przeprowadzenie
s zkoleń użytkowników
koń cowych
23

24. Proces Migracji
D oku m e ntacja D oku m e ntacj
a
C e le , Zakre s i p aram e tryzacji s tanowis kowa
S p os ób R e alizacji ap likacji
Opracowanie Opracowanie Przygotowanie
S trategii Migracji S zczegó ł owego ś rodowis ka
Planu Migracji produkcyjnego
S trate gia
K onwe rs j D anych
i
Koordynacja i
Arch ite ktu ra
kontrola realizacji zadań
Ap likacj i
w pozos tał ych
proces ach
24

25. Przykładowy Plan Projektu
2000 200
ID Task Name Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan
1 Przedsięwzięcie A - zastąpienie systemu
kadrowo-płacowego systemem zgodnym z rokiem 2000
9 Przedsięwzięcie B - wdrożenie SGW
10 Analiza SGW
14 Akceptacja wyników analizy SGW
18 Projekt Rozwiązania
19 Akceptacja Projektu
22 Budowa Rozwiązania
32 Audyt zewnętrzny gotowego systemu
33 Akceptacja systemu gospodarki własnej
34 SGW zaakceptowany 10-17
35 Migracja do nowego systemu (dla pilota)
39 Akceptacja gotowości do rozpoczęcia eksploatacji
40 Eksploatacja próbna
41 Rollout całego systemu
25

26. Podstawowe zadania wdrożeniowe
Faza Definicji
Definicja Analiza Projekt Budowa Przejście Produkcja
Operacyjna Rozwiązania
Model
Funkcyjny
Proces Proces
Bie¿¹cy Przysz³y

27. Modelowanie Procesów
Uwagi 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

28. Modelowanie Procesów
Standardy modelowania
Zdarzenie (wyzwalające) Krok procesu
D024: Przyjęcie Zamówienia
E001 OR.010
Karta
Urzędnik Wprowadź
Zamówienie Kredyt. ? Możliwość poprawy
wprowadzaj¹cy
OR.020 1
Sprawdź
Autoryzacjê
Baza danych
OR.030
Potwierdzona? Zaksięguj
Krok Zamówienie
OE
Baza Danych
ręczny
Planista OR.040 OR.050
Wyślij
Wci¹gnij
Potwierdzenie
Zamówienie
Zamówienia
na listę
Obszar E020
Decyzja
odpowiedzialności
Zdarzenie (wynikowe)

29. Modele procesów
Procesy bieżące i przyszłe
• Ulepszenia procesów • Które procesy są
realizowane w ramach
• Nowa technologia standardowej aplikacji?
D024: Order Receipt D024: Order Receipt
OR.010
OR.010 OR.020
E001 Credit
Enter Order E001
Card? Enter Order Check Credit
Entry Clerk
Entry Clerk
OR.020 1
Get Authorization
OR.030
OR.030
Approved? Book Order OE
Database Approved? Book Order
Scheduler OR.040 OR.050
OR.040 OR.050
Send Order
Schedule Order
Confirmation Send Order
Schedule Order
E020 Confirmation
E020

30. Model Procesów Przyszłych
Uwagi 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. Podstawowe zadania wdrożeniowe
Faza Analizy Operacyjnej
Definicja Analiza Projekt Budowa Przejście Produkcja
Operacyjna Rozwiązania
Model
Funkcyjny
BRS
Proces Proces
Bie¿¹cy Przysz³y
BRM Dokument Ok
Form Rozwi¹zañ
31

32. Fazy Definiowania i Analizy w planie projektu
2000
ID Task Name Sep Oct Nov Dec Jan Feb Mar Apr
1 Przedsięwzięcie A - zastąpienie systemu
kadrowo-płacowego systemem zgodnym z rokiem 2000
9 Przedsięwzięcie B - wdrożenie SGW
10 Analiza SGW
Faza Definicji
11 Opracowanie modelu bieżących procesów biznesowych
12 Zatwierdzenie modelu obecnego
13 Opracowanie propozycji rozwiązania docelowego
14 Akceptacja wyników analizy SGW
Faza Definicji i
15 Audyt zewnętrzny propozycji rozwiązania
Analizy Operacyjnej
16 Akceptacja wyników etapu
17 Podpisanie protokołu przystąpienia do dalszych prac 02-02
projektowych
18 Projekt Rozwiązania
19 Akceptacja Projektu
22 Budowa Rozwiązania
23 Kodowanie kastomizacji modułów systemu
32

33. Odwzorowanie Procesów
Scenariusze Odwzorowań
Jeden scenariusz
odpowiada jednej BRS 1
Scenariusz
możliwości realizacji Odwzorowania
1A
procesu
Model Procesu
Scenariusz
Odwzorowania
2A
BRS 2
Scenariusz
Odwzorowania
2B

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

35. Odwzorowanie Procesów
Model Przyszłych Procesów
D024: Przyjęcie Zamówienia
OR.010 OR.020
E001
Wprowadź Sprawdź Kredyt
Zamówienie
Urzędnik Nav Orders Cycle
Nav Orders Enter
Wprowa- Action
dzający
OR.030
Potwierdzony? Zaksięguj
Zamówienie
Nav Orders Enter
Wymagane
dostosowanie aby
automatycznie wysłać
potwierdzenie
zamówienia
OR.040 OR.050
Wyślij
Wciągnij
Potwierdzenie
Zamówienie
E020 Zamówienia
na listę
Nav Orders View

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

37. Typy rozbieżności
Funkcjonalne
• Reguły biznesowe
• Funkcje biznesowe
• Systemy
Informacyjne
• Pola
• Tablice
• Relacje

38. 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. Podstawowe zadania wdrożeniowe
Faza Projektu Rozwiązania
Definicja Analiza Projekt Budowa Przejście Produkcja
Operacyjna Rozwiązania
Model
Funkcyjny
Setup
Aplikacji
BRS
Skrypty
Proces Proces Testu
Bie¿¹cy Przysz³y Systemu
Skrypty
BRM Dokument Projekt Testu
Ok
Form Rozwi¹zañ Specyficz. Specyficz.
39

40. Definiowanie Parametrów Aplikacji
• Parametry są głównym produktem procesu Odwzorowania
Wymagań Funkcjonalnych
• Szablony AIM - BR.110

41. 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
INTEGRACJA
ELEMENT POŁĄCZENIE SYSTEM SYSTEMU

42. 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. Podstawowe zadania wdrożeniowe
Faza Budowy
Definicja Analiza Projekt Budowa Przejście Produkcja
Operacyjna Rozwiązania
Model
Funkcyjny
Setup
Aplikacji Wykonanie
BRS
Testu
Skrypty Systemu
Proces Proces Testu
Bie¿¹cy Przysz³y Systemu
Skrypty Tworzenie Testowanie
BRM Dokument Projekt Testu Modu³ów Modu³ów
Ok
Form Rozwi¹zañ Specyficz. Specyficz. Specyficz. Specyficzn.
43

44. Kolejne fazy w planie projektu
ID Task Name Apr May Jun Jul Aug Sep Oct Nov
22 Budowa Rozwiązania
23 Kodowanie kastomizacji modułów systemu
24 Kodowanie interfejsów
25 Kodowanie programów konwersji
26 Opracowanie testów wstępnych i akceptacyjnych
27 Kodowanie programów testów wydajnościowych
28 Testy wstępne
29 Zatwierdzenie uwag po testowych
30 Realizacja uwag po testowych
31 Testy akceptacyjne
32 Audyt zewnętrzny gotowego systemu
33 Akceptacja systemu gospodarki własnej
34 SGW zaakceptowany
35 Migracja do nowego systemu (dla pilota)
44

45. Podstawowe zadania wdrożeniowe
Faza Przejścia
Definicja Analiza Projekt Budowa Przejście Produkcja
Operacyjna Rozwiązania
Model
Funkcyjny
Setup
Aplikacji Wykonanie
BRS
Testu Eksploatacja
Skrypty Systemu
Proces Proces Testu
Bie¿¹cy Przysz³y Systemu
Skrypty Tworzenie Testowanie
BRM Dokument Projekt Testu Modu³ów Modu³ów
Ok
Form Rozwi¹zañ Specyficz. Specyficz. Specyficz. Specyficzn.
45

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
46

47. Migracja do nowego systemu
2001
ID Task Name Sep Oct Nov Dec Jan Feb Mar Apr
35 Migracja do nowego systemu (dla pilota)
36 Szkolenie użytkowników końcowych
37 Ostateczna parametryzacja systemu - instalacja w
jednostkach pilotowych
38 Konwersja danych
39 Akceptacja gotowości do rozpoczęcia eksploatacji
40 Eksploatacja próbna
41 Rollout całego systemu
42 Szkolenia użytkowników końcowych
43 Instalacja w pozostałych jednostkach
44 Konwersja danych dla pozostałych jednostek
45 Akceptacja gotowości do rozpoczęcia eksploatacji
47

48. Zarządzanie projektem a AIM
Planowani Kontrola faz Zamknięcie
e projektu projektu
Fazy
1 2 3 4 5 6
• Planowanie Fazy
• Kontrola Fazy
• Zamkniêcie fazy
48

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
49

50. Zarządzanie Projektami
CZAS
KOSZT JAKOŚĆ
50

51. Współczesne Zarządzanie Projektami
CZAS
KOSZT JAKOŚĆ
51

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
52

53. Zarządzanie Projektem
Kontrola Projektu
q
Realizacja Planu Projektu
q
Kontrola i śledzenie zadań
q
Kontrola i śledzenie finansów
q
Zarządzanie zasobami ludzkimi
q
Zarządzanie komunikacją
q
Zarządzanie Jakością
q
Zarządzanie Ryzykiem
q
Zarządzanie Zmianami
q
Zarządzanie Konfiguracją
q
Zarządzanie kontraktem i zakupami
53

54. HISTORIA Z ŻYCIA
KAŻDY KTOKOLWIEK KTOŚ NIKT
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.
54

55. Plan zasobów i organizacja projektu
Dokument 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.
55

56. Struktura projektu i role
projektowe K o m ite t S te r u ją c y
P r z e d s ta w ic ie le P r z e d s ta w ic ie le
Z le c e n io d a w c y W ykonaw cy
Sponsor
p r o je k tu
K o n tr o la
Jakości
K o o rd y n a to r
K ie r o w n ik P r o je k tu P r o je k tu
CL z e s tro n y
Z le c e n o d a w c y
A d m in is tr a to r
p r o je k tu A d m in s tr a to r
(b ib lio te k a r z ) s y s te m u
Zespół
W d r o ż e n io w y Zespół
U ż y tk o w n ic y p r o g r a m is tó w
k lu c z o w 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.
57

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

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

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

61. Procedura Kontroli Zmian
Procedura Kontroli Zmian wykorzystuje dwa formularze:
1. Formularz Zgłoszenia Zmiany
2. Rejestr Zmian
61

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
62

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

64. Procedury Komunikacji
• Formularz Tygodniowy Raport Postępu Prac
• Formularz Raportu na Komitet Sterujący
64

65. Procedury Komunikacji
• Formularz Agenda Spotkania
• Formularz Notatka ze Spotkania
65

66. Procedury Komunikacji
• Formularz Zgłoszenie Problemu
• Formularz Rejestru Problemów
66

67. Procedury Komunikacji
• Harmonogramy projektów – MS Project 98
• Formularz Plan Działań
• Formularz Zlecenia Zadania
67

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

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

70. Archiwizowanie dokumentów
• Katalog roboczy i archiwalny
• Pilnowanie wersji i przeglądów
• Zawsze aktualne archiwum

71. Rejestry
XXX-PRL-001 Rejestr Problemów
XXX-PRT-001 Zgłoszenie problemu
XXX-CRL-001 Rejestr żądań zmian
XXX-CRF-001 Żądanie zmiany

72. 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ę
73

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
74

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
75

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
76

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
77

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

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
79

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
80

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
81

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