Our methodology

Albert Einstein was reported to have been asked what he would do if he only had one hour to save the world. He answered: “I would spend fifty-five minutes defining the problem and only five minutes executing the solution.” ANEGIS’s methodology is based on the same theory – strategy is key.

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.

How we work

Reverse-effort approach

ANEGIS Consulting 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.

Reverse-effort approach

Design cycle

Requirements

  • Performed by: ANEGIS and/or customer onsite resources
  • Input: customer's ideas, requirements, GAP
  • Output: functional requirements document

Functional design

  • Performed by: ANEGIS
  • Input: functional requirements document
  • Output: functional design document

1/2

Technical design

  • Performed by: ANEGIS
  • Input: functional design document
  • Output: technical design document

Prototype

  • Performed by: ANEGIS
  • Input: technical design document
  • Output: prototype accepted by customer

2/2

Development process

Design handover meeting

An ANEGIS functional consultant hands over the design to the technical architecture team.

1/8

Design assessment

The technical architect checks whether the design contains all the details required, including any necessary information to start development, while reviewing the design for errors and technical procedures.

2/8

Design optimisation

This is probably the most critical phase of any ERP development strategy. The customer can often be saved huge amounts of money by proposing an alternative, technically easier solution while still delivering the essential, required functionality. It is often overlooked that basic optimisations may vary little in comparison to using standard UI patterns or reusing standard applications. However, these issues should be analysed carefully before proceeding.

3/8

Creating technical specification

The key to creating a technical specification is making sure that the technical architect and developers are on the same page. It is business-critical to demonstrate a clear design while making sure that the developer is properly briefed. A well-thought-out technical design significantly reduces the chances of costly changes during the development phase.

4/8

Technical meeting to approve technical design

The solution architects read both functional and technical specifications. It is important to ask questions and verify with both the consultant and the developer to gauge whether they understand each other. This step avoids misunderstandings and prevents situations whereby the developer creates something different to what has been created by the functional consultants.

5/8

Creating the prototype

Prototyping gives the user the ability to see what the consultants are designing before the project enters its core development phase. It is an opportunity to make final changes. Prototyping reduces the scope of the changes because here we are changing the design, not the code.

6/8

Development

The development team writes the code according to the specification created.

7/8

Quality assurance

The technical architects review the code.  ANEGIS Consulting’s code meets the very highest standard and we use Microsoft Lifecycle Services Customisation Analysis to help us achieve this standard at all times.

8/8

ALM/TFS

ANEGIS Consulting 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.

1/4

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

Build environment
2/4

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.

Work Management
3/4

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.

Test management
4/4