Do you need any process?

Each of the implementing companies posses a process of software development. In Divante a big emphasis is put on the process, so it is as structured as possible, but the company is also oriented toward the customers reaching their objectives and their end users. We call our process User Centered Design. In the following files, regarding the course of analytical and design works and implementation of best practices, we describe how we work. We present our approach and general techniques used to ensure the highest quality.

What is our methodology?

The implementation is carried out as part of iterations/stages that are of a cascade nature.  The way of how the implementation occurs is well illustrated by the following infographic:

The implementation process includes the following stages:

  1. Specifying objectives, performing tests and determining the business strategy
  2. Pre-implementation analysis and gathering requirements
  3. Functional design (mockups and description of the system)
  4. Graphic Design
  5. Analysis and implementation of integration with external systems
  6. The implementation works (broken by stages)
  7. Tests
  8. Start-up of the system
  9. Maintenance and Hosting

One person is responsible for the whole project on behalf of Divante – a project manager who is also the contact person. Thanks to that we can limit the traffic chaos. The project manager takes care of the completion of the project on time and successfully (according to the specific indicators of success agreed with the customer).

Immediately after starting the work we develop a detailed timetable including calendar dates, determining the progress of the works and the deadlines when the customer is to be involved into the works (acceptances, transfer of materials). More information about how we organize our communication with the customer can be found in the accompanying descriptive material.

 Minimizing Risks

Implementation or transfer of the existing shop platform is usually not a simple and short process. During the works a lot of unforeseen events can happen. Therefore, it is important to reduce the design risk.

Divante takes the following steps to reduce the design risk:

  • Meeting precisely the requirements – we create models + collect screenshots of the existing systems (and possibly Webcasts), we test the current systems using the testing version and together with the customer we gather functional and non-functional Webcasts, check current systems for the testing and together with the client we collect functional and non-functional requirements .
  • Analysis of external systems (Integrations) and processes at their junction. Integrations are always risky because the unknown meets the unknown… The documentation and descriptions of the whole business processes on the point of contact of which the integration occurs, are the key factors. We try to accurately describe the protocols, data formats, and requests in order to avoid unnecessary tensions when conducting integration works.
  • Specific milestones / iterations – each stone means functionalities ready to use – closing, closing, closing. Milestones and iterations are planned at the very beginning of the project, with the appointed realistic deadlines. Project Manager and the implementation team who will perform the works are involved in planning milestones. This approach allows us to minimize the risk of underestimation or overestimation.
  • Monitoring progress in the Redmine system, with participation of the customer and focused on a constant exchange of information and use an on-line test version. The customer can always participate in the development and track the progress. All communications are registered in the ticket Redmine system so that they become a living system documentation and a reference point for all of the requirements changes.
  • Developing and testing automated data migration scripts – when creating the functions we first migrate the needed data thereto – in order to be sure that we do not forget anything. Migration is also a risky stage of the works, therefore, in order to avoid delays we check possibilities of migration at the beginning.
  • Creating documentation containing a description of all test scenarios of the business functioning of the platform (smoke tests). Only suitably large number of tests and amendments can result in a quality guarantee. We strive for complete transparency of the testing stage and its good documenting. In such a way that it can be a fully systematic and repeatable process.
  • Performing 2-3 stage functional tests, security tests, performance tests, emergency tests – after importing the data, before opening the system

Have a look on our cases, to see how it looks in practice:

The exact course of design works and analysis is described in separate, appended files.

In next entry – we’ll discuss next stages, documentation and tests