Trusted Product Lines Argument Framework

Chapter 1 summarised the five main challenges/strategies that we identified as being fundamental to the successful application of Trusted Product Lines. As part of the research evaluation, we now describe how these challenges have been addressed by our approach. Figure 90 maps the high-integrity re-use issues raised by the FAA and Leveson and Weiss (as identified and enumerated in Chapter 2) onto the Trusted Product Lines framework to indicate where these need to be been addressed and/or discharged. It should be noted that we have shown via the data analysis in this chapter that the assumption “Assume Minimum of 3 Products” stated in Figure 90 is valid in the context of our Trusted Product Lines approach.

167 Trusted Product Lines – PhD Thesis S G Hutchesson

6.5.1.1 PL Scoping is Possible

We described this challenge as being able to clearly identify a product line scope; i.e. be able to define robustly when a specific product is a member of the product line (and equally when a product is not a member). In addition, it must be possible to identify common parts of the product line (those aspects that are present in all members) and the variable parts (aspects included/excluded by selection).

We noted in Chapter 1 (1.3.1) that this was primarily an engineering challenge, not requiring significant research investment. Much of the scoping activity is problem-domain related, and thus not addressed explicitly by the work described in this thesis. However, we have provided explicit support to address the solution-domain issues, via our decision contract approach:

 We clearly identify those components that contain variability, via the existence of a decision contract.

 We clearly map those decisions onto the variable parts of the component with navigable associations in the UML model.

 We provide clear traceability back to the High Level Requirements for both common and variable parts of the components.

 We provide automatically, via transformation, the applicable subset of the traceability for the instantiated component.

In this way, the solution-domain issues raised by Leveson and Weiss (LW3) and the FAA in AC-148 (AC-R8) are addressed by our approach.

6.5.1.2 PL Synthesis is Effective

We described this as a demonstration of our ability to apply product line synthesis techniques to the creation of product instances from artefacts developed for the product line. The Trusted Product Line development and synthesis approach has to take into account the characteristics of typical high-integrity development projects. The product line development approach chosen must be capable of providing credible approval evidence for the instantiated product. This is a key message of Trusted Product Lines, and we have successfully demonstrated this in our approach – specifically by the following:

 We base our approach on a proven, certifiable software engineering process based on UML, SPARK and model-to-text code generators that have been demonstrated in use on current systems.

 We have defined a reference architecture that can host components containing variability but also instantiate products whose architecture as deployed reflects current, certified products.

 We include the SPARK information flow annotations in the component design, including explicit support for their variability and instantiation into the product source code.

168 Trusted Product Lines – PhD Thesis S G Hutchesson

 We have defined a decision contract approach that makes explicit the allowable variability in the component, with navigable links to all the points of variation in the component to aid review and analysis.

 Traceability links for both common and variable parts of the component are supported, allowing the variation to be justified and reviewed.

 Documentation can be produced for the product line component, allowing review and analysis pre-instantiation, and for the product-instance component, providing the DO-178B/ED-12B Low Level Requirements artefacts to support certification.

 Negative variability ensures that the review and analysis of the product line artefacts sees the full scope of the variation, and understands how particular decision options (and combinations) would affect the instantiated product.

 We have defined a deployment process that captures how products are built – i.e. from product line components allocated to processors, and with specific options selected to resolve the component variability.

 We have produced transformations that create the Low Level Requirements and Source Code artefacts for specific products from an architectural model that contains deployed components and resolved decisions.

 We have demonstrated in practice that this process is deployable on industrial- sized projects with large development teams who, in many cases, were unfamiliar with product line techniques prior to the deployment of this process.

Our approach has specifically addressed the associated PL synthesis issues raised by Leveson and Weiss (LW2 – via the reference architecture and decision contract) and the FAA in AC-148 (AC-D4, AC- I1, AC-I2, AC-R3, AC-R7).

We remove the need to consider the following, as we are developing as a product line and not as a reusable software component: AC-D3, AC-U4, AC-R4 and AC-R6.

6.5.1.3 Verification Evidence Applies

This challenge relates primarily to reducing product verification costs via the product line approach, whilst retaining the ability to demonstrate the applicability of the verification evidence to the product instance being certified. We have not addressed verification by test explicitly in this research, however our approach “does no harm”, in that the process produces artefacts that would enable a traditional verification approach to be followed on the instantiated product. Theoretically, we should be increasing the maturity of products instantiated using our approach (reducing the cost of what the company terms “scrap and rework”) as we enable review of product line assets prior to instantiation. However, as we have seen in section 6.5, it may be difficult to demonstrate the applicability of this verification to instantiated product. We address this in Chapter 7.

169 Trusted Product Lines – PhD Thesis S G Hutchesson

6.5.1.4 CM is Effective

The effectiveness of the Configuration Management and Change Control processes to manage the product assets and associated process evidence is key to the successful application of a Trusted Product Line Approach. As we noted in Chapter 1, this is primarily an engineering challenge rather than one that required novel research, and therefore we have not addressed this further. Furthermore, there is nothing introduced in our approach that should provide additional CM challenges over and above those existent already with the configuration of complex models.

6.5.1.5 Plans, Processes and Procedures are Standardised

The consistent management of the engineering process across a product line development is a significant challenge, as discussed in Chapter 1 (Section 1.3.5). However, it was not specifically the subject of the research described in this thesis and therefore will not be considered further.

6.5.1.6 Remaining High-Integrity Reuse Issues

The following issues raised by the FAA in AC20-148 and Leveson and Weiss are not addressed by the strategies and goals in the trusted product lines approach: LW4, AC-D5, AC-U2, AC-U3, AC-U4. This is because in general these issues need to be addressed at the

system level rather than the software level.