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 question

The company

How we work

Quality of code is fundamental

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

ANEGIS works to a simple principle: good design is the key to success. Accordingly, we base our methodology on the ‘reverse-effort approach’, a model we have adopted working on projects from 50 to 27,000 users.

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.

III

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

VII

Faza 7 - Start Produkcyjny

Realizacja planu Startu Produkcyjnego - część II.
Przygotowanie i przeprowadzenie Migracji Produkcyjnej - część II.
Wsparcie po Starcie Produkcyjnym.

Organizacja prac zespołów projektowych klienta i ANEGIS w całym Projekcie jest według metodyki Agile.

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.

III

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

ANEGIS uses Visual Studio Application Lifecycle Management↗ (ALM) to manage the product lifecycle, so reducing risks and increasing efficiencies.

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

Whether the software project is large or small, ANEGIS uses version control as early as possible in the lifecycle of a project. For small projects, it is used to improve personal productivity and resolve difficult problems. When working with a team or on complex projects, ANEGIS uses a shared, version-controlled file system to improve collaboration and transparency.

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

With Team Foundation Build, ANEGIS creates and manages build processes that automatically compile and test applications.

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

The central item of each implementation project in TFS is an artefact called ‘Team Project’. It contains a well-organised hierarchical structure of all dependent work items, describing all the information required to run the project.

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

ANEGIS uses Microsoft Test Manager, which is included in the Application Lifecycle Management tool, to help define and manage test plans. These test plans are stored on a Team Foundation Server and are closely integrated with its build.

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.