The SeeFar application consists of various heterogeneous modules, such as smart glasses, various sensors, processing units, smartphone applications etc. So, the integration of all these modules was a challenge during the project.
For all possible integration strategies (“big bang”, “with the Stream”, incremental, Aggregates, Subsets, Threads or “Functional Chains”, top-down, bottom-up, sandwich or hybrid, Criterion Driven or “Critical Modules”, Continuous) for the SeeFar having considered the various advantages and disadvantages of the Integration Strategies the particularities/specificities and main features of the See Far solution’s comprising ‘aggregates’ and overall architecture, it has been decided that the most appropriate Integration Strategy for the See Far solution was the Aggregates’ Integration (also referred to as “Subsets”, “Threads” or “Functional Chains” Integration).
In this approach, the implemented elements/components are assembled into “aggregates”/“subsets” (or per execution “thread”), and then the aggregates/subsets are in turn assembled together. Is also referred to as “Functional Chains Integration”. Characteristic aspects are:
- Can result in significant time savings, due to the parallelisation of subsets/aggregates integration efforts, while ‘partial’ deliveries are also possible. Typically involves less means and fewer test cases than “Incremental Integration”.
- Associated subsets/aggregates are defined during the design phase.
- Is most applicable to architectures that comprise sub-systems.
The predominant reasons why the Aggregates’ Integration approach was selected for the See Far solution are summarised in the following points:
- The See Far Solution, according to its established Architecture comprises of only a few in number and quite clearly separated ‘aggregates’/sub-systems, with mostly expose some easily distinguishable real-world/physical ‘interfaces’ between them.
- Each See Far ‘aggregate’/sub-system only communicates with 1 or 2 other such, hence ‘interface’ testing will be minimal and can be performed ‘informally’ from a very early stage, thus minimising/eliminating potential integration ‘obstacles’ at later and more ‘critical’
- Will allow greater flexibility and possible parallelisation in integration efforts, should this be necessary at later stages in the development, due to delays in associated ‘partial’ deliveries or because of other ‘uncertainties’/risks that may materialise (e.g. the case of the COVID- 19 pandemic).
- Given the fact that See Far is the outcome of a research project and the focus at least in the first step is mainly the scientific and technical ‘proof-of-concept’ of some innovative functionalities and in a second plan a ‘commercial’ readiness, integration testing should be limited and targeted in the first phase in the scientific and technical issues.
Also, due to the fact that See Far consortium is distributed in many European countries, in order to achieve a reliable collaboration between them during the development and especially integration phase, it has been used as a test tool and integration issues tracking system, a test portal using the open-source TestLink framework (http://testlink.org/)
