Metodyki
Metodyka, według której prowadzimy projekty, to kombinacja metodyk Waterfall, Agile i elementów Fast Track opracowanej przez Microsoft.
Pytania?Jak działamy?
Rekomendujemy pełne przygotowanie przed przystąpieniem do fazy programowania. Dokonywanie zmian w trakcie realizacji projektu może być korzystne, jednak często wydłuża proces i może doprowadzić do problemów z ukończeniem projektu. Przed zmianami w programowaniu należy wrócić do fazy projektowania.
Podejście odwrotnego wysiłku
Korelacja między wysiłkiem i kosztem staje się ważna po dalszej fazie rozwoju. Doświadczenie pokazało, że większa ilość czasu i wysiłku poświęconego na przygotowanie projektu zmniejsza całkowity koszt rozwoju i pozwala systemowi działać prawidłowo.
Proces projektowania
Faza 1 - Przygotowanie Projektu
- Organizacja Projektu oraz Narzędzi Projektowych, w tym opracowanie dokumentu Plan Projektu.
- Instalacja środowisk i standardowego systemu.
- Przekazanie do klienta arkuszy Migracji Wstępnej.
Faza 2 - Analiza
- Przygotowanie i przeprowadzenie Migracji Wstępnej do standardowego systemu.
- Szkolenia z interfejsu nowego systemu w celu zapoznania klienta ze środowiskiem.
- Analiza i opracowanie Dokumentu Analizy (DAR), który ramowo (przy podejściu Agile) lub szczegółowo (przy podejściu Waterfall) opisuje wymagania oraz przyjętą implementację w systemie.
- Opracowanie Scenariusza Prezentacji Systemu, który będzie podstawą do przedstawienia klientowi postępu prac w systemie podczas Fazy Implementacji.
Faza 3 - Prototypowanie Projektu
- Weryfikacja zakresu Projektu, w tym zakresu implementacji systemu na Start Produkcyjny oraz na etap rozwoju systemu (po zakończeniu Projektu).
- Uzgodnienie Backlogu prac projektowych oraz opracowanie Harmonogramu Dostaw.
Faza 4 - Implementacja Systemu
- Instalacja i konfiguracja Prototypu Systemu.
- Rozbudowa Prototypu Systemu o uzgodnione modyfikacje (w tym interfejsy).
- Przygotowanie i przeprowadzanie Migracji Testowej.
- Szkolenie zespołu klienta i administratorów klienta - część I.
- Prezentacje postępu prac według Scenariusza Prezentacji.
- Testy jednostkowe procesów oraz modyfikacji.
- Weryfikacja zakresu Projektu, w tym zakresu implementacji systemu na Start Produkcyjny oraz na etap rozwoju systemu (po zakończeniu Projektu).
Faza 5 - Testy Akceptacyjne
- Testy akceptacyjne prototypu systemu.
- Opracowanie dokumentu Planu Startu Produkcyjnego.
- Weryfikacja zakresu Projektu, w tym zakresu implementacji systemu na Start Produkcyjny oraz na etap rozwoju systemu (po zakończeniu Projektu).
Faza 6 - Przygotowanie do Startu Produkcyjnego
- Okres stabilizacji prototypu systemu (usuwanie wyłącznie błędów w prototypie systemu, który będzie referencyjny dla systemu produkcyjnego).
- Instalacja i konfiguracja systemu produkcyjnego.
- Szkolenia użytkowników końcowych i administratorów - część II.
- Realizacja planu Startu Produkcyjnego - część I.
- Przygotowanie i przeprowadzenie Migracji Produktowej - część I.
- Weryfikacja zakresu Projektu, w tym zakresu implementacji systemu na Start Produkcyjny oraz na etap rozwoju systemu (po zakończeniu Projektu).
Faza 7 - Start Produkcyjny
- Realizacja planu Startu Produkcyjnego - część II.
- Przygotowanie i przeprowadzenie Migracji Produkcyjnej - część II.
- Wsparcie po Starcie Produkcyjnym.
Kluczowe role w projekcie realizacyjnym:
Business Architect
Osoba merytoryczna po stronie klienta odpowiedzialna za zgodność przygotowywanego systemu z wymaganiami biznesowymi klienta określonymi w umowie.
Solution Architect
Osoba po stronie ANEGIS odpowiedzialna za odpowiednią implementację wymagań w systemie (w tym architekturę merytoryczną systemu) oraz maksymalne wykorzystanie standardowej funkcjonalności systemu.
Technical Architect
Osoba po stronie ANEGIS odpowiedzialna za prawidłową techniczną implementację wymagań w systemie, w tym architekturę techniczną systemu oraz jakość techniczną dostarczanych zmian w systemie.
Proces rozwoju programowania
Określenie wymagań
Zdefiniowanie wymagań przez klienta. Ocena merytoryczna wymagań przez Business Architekta, w tym ustalenie jej zasadności biznesowej. Ocena umowy, budżetów i harmonogramowanie przez Project Managera klienta możliwości ich realizacji, a następnie skierowanie ich do analizy ANEGIS.
Analiza wymagań
Solution Architect sprawdza, czy wymagania zawierają wszystkie informacje szczegółowe pozwalające na analizę wymagań oraz sprawdza wykonalność wymagań w przyjętej architekturze merytorycznej systemu. Technical Architect dokonuje podobnych czynności, ale z perspektywy architektury technicznej. Następnie Project Manager kieruje wymagania do analizy i opracowania dokumentu FDD przez Konsultanta. Przygotowany dokument FDD z propozycją implementacji jest oceniany zarówno przez Solution, jaki i Technical Architekta, a następnie przedstawiany do akceptacji klienta. Po pozytywnej ocenie klienta wymagania są kierowane do realizacji.
Implementacja wymagań
W ramach implementacji dokonywane są zmiany w konfiguracji systemu i/lub kodzie źródłowym, które są testowane przez programistę, konsultanta i klienta według scenariusza testowego wskazanego w dokumencie FDD. W przypadku pozytywnych testów Technical Architect dokonuje przeglądu kodu pod względem jakości oraz zgodności z najlepszymi praktykami (a w uzasadnionych przypadkach - wpływu zmian na wydajność systemu). W przypadku pozytywnej oceny wymagania są przenoszone do systemu produkcyjnego.
ALM/TFS
Visual Studio Team Foundation Server (TFS) pozwala nam na zastosowanie sprawdzonych praktyk w zakresie zarządzania cyklem życia produktu: zarządzanie kodem źródłowym w zespołach, programowanie, kompilowanie i testowanie aplikacji, planowanie projektów, śledzenie pracy i raportowania postępu prac. TFS zapewnia kontrolę wersji, system kompilacji, CMMI, Scrum, narzędzia planowania agile i metryki do zarządzania projektami rozwoju oprogramowania. ANEGIS jest jedną z niewielu firm wdrażających Microsoft Dynamics AX, które stosują TFS i posiadają funkcjonujące skrypty kompilacji.
Zarządzanie kodem
Team Foundation Version Control (TFVC) jest scentralizowanym systemem kontroli wersji. Zazwyczaj członkowie zespołu mają tylko jedną wersję każdego pliku na swoim urządzeniu. Dane historyczne są przechowywane tylko na serwerze. Ponadto oddziały oparte są na ścieżkach i tworzone na serwerze. ANEGIS działa w środowisku rozproszonym - oznacza to, że każdy programista posiada osobistą maszynę wirtualną z zainstalowanym środowiskiem Microsoft Dynamics AX 2012 Server. Maszyny wirtualne są zarządzane przez Hyper-V Manager.
Liczba maszyn wirtualnych na komputerze każdego programisty jest połączona z liczbą obsługiwanych klientów, ale nie powinna przekraczać trzech lub czterech w danym momencie. ANEGIS używa jednego z dwóch modeli dostarczanych przez TFVC: check-out/check-in w serwerowych obszarach roboczych. Przed wprowadzeniem zmian członkowie zespołu publicznie wykonują pobranie (check-out) plików. Większość operacji wymaga od programistów podłączenia do serwera.
Zarządzanie kompilacjami
Oprócz pliku modelowego Microsoft Dynamics AX proces ten umożliwia tworzenie pliku dziennika zawierającego zarówno opis całego procesu kompilacji, jak i wynik testu. ANEGIS używa systemu kompilacji do wspierania strategii ciągłej integracji i do zapewnienia jeszcze bardziej rygorystycznej kontroli jakości w celu uniknięcia sytuacji, w której złej jakości kod "psuje kompilację".
Zarządzanie pracą
Elementy takie jak funkcje, żądania zmian i błędy zapewniają określoną część pracy do wdrożeń w systemie.Po zakończeniu procesu weryfikacji wymagania są wykonywane i przypisywane do ostatecznych zadań. Przypadki testowe obejmują manualne testowanie każdego wymagania.
Zarządzanie testami
Podczas procesu testowania istnieje możliwość tworzenia i przechowywania elementów roboczych błędów przeznaczonych do dalszej analizy. Gdy udowodniony zostanie błąd, tworzony jest nowy wymóg i określane jest odpowiadające mu zadanie programistyczne. Zarządzanie testami obejmuje następujące kroki: planowanie, tworzenie, uruchamianie, śledzenie wyników i reagowanie.
