Software Development Based on V-Model
Processes based on the V-Model are very often required by larger corporate companies who need strictly predictable and trackable plans split into clearly defined pieces of work.
Processes based on the V-Model:
Definition of Requirements
Our team of embedded software engineers collects the customer's requirements, reviews them, and clarifies any potential specification gaps.
System Design
In the system design, we develop ideas and consider how the functionality will be distributed to hardware and software resources. Consequently, we pre-define interfaces and data relations.
Architecture Design
In this phase, we analyze and evaluate different approaches at a high level that lead to the easiest and fastest development and lowest cost. We split the system design into individual modules depending on their functionality differentiation.
Module Design
A module or unit design is a detailed internal design definition at a low level focussing on inter-module compatibility.
Coding
We follow either the best-practice guidelines or customer standard guidelines, depending on the agreement with the customer. Code reviews and code optimization are an unavoidable part of this stage as well.
Unit Testing
Module or unit test scripts are implemented and performed during this process. They detect the maximum of the errors at an early stage.
Integration Testing
Integration testing checks the coexistence and mutual communication of the modules.
System Testing
System testing checks the functionality of the entire system the communication between the system and external systems. Hardware and software compatibility is checked in this stage as well.
Acceptance Testing
The whole software product is tested against the business requirements in the pre-final user environment. Both the user experience and system performance are finally tested here.
Software Development Based on Agile
Agile software development is an evolution-based approach that splits into many vertical integration campaigns. It supports continual improvement executed by self-organizing team(s) collaborating tightly with the customer’s team or end users.
We widely use one of the two software development frameworks:
- Scrum – a framework based on the short sprints (each done in typically two weeks) or
- Kanban – a framework with continuous workflow. As the first step, the backlog is filled by the epics/stories/issues/tasks, and all the items are estimated.
Typical Scrum events in our team are:
Sprint
A time window of typically two weeks during that the developer team finishes usable or releasable product (or its distinguishable part).
Sprint Plan
An activity done by the whole team that carries out a doable portion of work for the sprint.
Daily Scrum
A daily stand-up meeting to give the team an opportunity for mutual discussion on what the status is, if someone is stuck in something, and what problems the team have found.
Sprint Review
A meeting at the end of the sprint where the team members share their recent experience with the project, review the work that was not finished, and talk to the stakeholder.
Sprint Retrospective
An opportunity for team self-improvement.
