Our methodology
Our methodology applies agile tools and Dynamics 365 Sure Step to manage product lifecycle, reduce risks, and improve efficiency in all D365 (AX) projects.
ask a questionHow we work
Be fully prepared before entering the development stage. Making changes during development can be beneficial, however, they often prolong the process and may cause the project plan to veer off-track. Go back to the design before changing development. A good project manager is essential to maintaining this consistency.
Reverse-effort approach
The correlation between effort and cost becomes important after the development phase. Experience has proven that more time and effort spent on preparation reduces the overall cost of development and allows for greater focus on making sure the system works as the user wants.
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) allows us to apply proven practices in ALM: managing source code across teams; developing, building and testing the application; planning projects; tracking work; and reporting work progress. TFS provides version control, a build system, CMMI, Scrum, agile planning tools and metrics for managing software development projects. ANEGIS is one of the only companies implementing Microsoft Dynamics 365 to use TFS and have working build scripts.
Code management
Team Foundation Version Control (TFVC) is a centralised version control system. Typically, team members have only one version of each file on their development machines. Historical data is maintained only on the server. In addition, branches are path-based and created on the server. ANEGIS works in a distributed environment, meaning that each developer has a personal virtual machine with a Microsoft Dynamics Server environment installed.
The virtual machines are managed by Hyper-V Manager. The number of virtual machines on each developer’s PC is connected to the number of serviced customers, but should not exceed three or four at any one time. ANEGIS uses one of the two models delivered by TFVC: check-out/check-in in server workspaces. Before making changes, team members publicly check-out the files. Most operations require the developers to be connected to the server.
Build management
In addition to the Microsoft Dynamics model file, this process enables the creation both of a log file containing the whole build process description and a test result. ANEGIS uses the build system to support a strategy of continuous integration and to put even more rigorous quality checks in place to prevent bad quality code from ‘breaking the build’.
Work management
Items like features, change requests and bugs provide a piece of work to be implemented in the system. After the verification process, requirements are produced and slotted into the final development tasks. Test cases cover the manual testing of each requirement.
Test management
During the testing process, bug work items may be created and stored for further analysis. When a bug is proven, a new requirement is created and a corresponding development task is specified. The steps of test management are as follows: plan, create, run, track results and react.