GENERALIDADES

phase of formalisation and abstraction, i.e. after the initial artefacts success- fully passed the informal verification step. First, the component signatures are defined by abstracting from the component port and types given by the initial design. The signatures are crucial, as they define the alphabet for the specification of all system properties. Using the component signatures, the desired system behaviour can be translated into a set of global contracts, and the component behaviours into component contracts. Similarly, the informa- tion given by the initial configuration diagram and the reconfiguration rule descriptions are condensed to create the assembly specification. With these artefacts created, the formal verification step can be started to establish a formal proof of correctness.

In the final step, the implementation (shown in the lower third part of Figure 5.2), the code for the REFLECT framework is created: from the com- ponent ports and types of the initial design, the code for the static structure (i.e. the components with their portS) of the adaptive system can be created. Similarly, the component implementation is derived from the initial compo- nent behaviour and the formal component contracts. The initial system configuration is created from information available in the initial component configuration diagram and the assembly specification, and the reconfigura- tion actions are created from the textual description of the reconfiguration rules and from the assembly specification.

5.2

Combining formal verification and Scrum

A software development methodology for the development of physiological computing should be agile, as the development of physiological computing systems is often an undertaking that involves a significant amount of research work. We propose using Scrum [107] since it is a software development methodology that is well suited for the development of new products and software (cf. Section 2.5.6). Scrum has its roots in the empirical process model, and as a consequence, uses frequent inspection and adaptive feedback as its main means of control (compare with Section 2.5.4). Scrum is a generic software development methodology that can be used to create software, but also for research and development activities that do not primarily focus on software; hence, it is most suitable for the creation of physiological computing applications.

Model initial design Informal design verification Formal design verification Implement components Implement reconfiguration rules

Sprint Planning Meeting Design verification Sprint

Abstraction and formalization

Other tasks

Figure 5.3: Delaying combination of reconfiguration verification and Scrum

However, the formal verification and implementation work needs to be carefully embedded in Scrum without diminishing its adaptive nature. When integrating the verification process described in Section 5.1 in Scrum, the question arises how the five steps defined for formal verification can be nat- urally embedded. Overall, there are two forces that guide the integration of the verification process into the agile methodology of Scrum:

• Early verification. The formal verification of a system structure and its reconfiguration rules is a step that needs to be performed early; the failure of a verification proof often entails changes in the structure of a system that require modifications of implementation code if that implementation code was already created.

• Staying agile. Scrum suggests to include early design discussion in the sprint planning meeting, but not to perform any detailed design activ- ities in that meeting. Introducing design verification steps between the sprint planning and sprint execution causes a delay of implementation work that commemorates the waterfall approach. Such an approach should be avoided, as it would stall the whole development team, and reduce the adaptation capabilities of the development teams.

5.2 Combining formal verification and Scrum 169

Model initial design

Informal design verification

Formal design verification Abstraction and

formalization Implement components

Implement reconfiguration rules

Sprint Planning Meeting Sprint

Other tasks

Figure 5.4: Agile combination of reconfiguration verification and Scrum

Figure 5.3 shows how the process would be organised if we followed solely the force of early verification. The modelling, verification, and implementa- tion activities would be integrated in Scrum by introducing another phase before the start of a sprint. During the sprint planning meeting, the design would be elaborated and informally verified, while the the formal verification would be moved to an own phase of the project. Once the formal proof of correctness is achieved, the sprint starts, and the component and reconfigu- ration design is implemented along with other sprint backlog items that need completion.

In order to prevent progress delay, it is necessary to find a compromise between early verification and agility. Figure 5.4 shows a different approach to the integration of reconfiguration verification in Scrum. Here, the design verification activities are added as regular, additional sprint backlog items to the sprint itself. This implies that the reconfiguration rules and component behaviour implementation may start before a formal proof of correctness have been established. However, parallel implementation and verification allows to feed back insights gained from the implementation into the specification, and by this to rule out problematic designs that would have been hard to detect otherwise. Additionally, performing the formal validation of the design within the sprint allows the team to tackle product backlog items that do not

affect the design or component behaviour to be verified. This may include bug fixes and development in other parts of the system, experiments with new technologies, code cleanup and refactorings.

In the described approach, the early verification force seems to be bla- tantly violated, but it is not; it is only subordinated to the force of staying agile. Of course, the team should tackle the issue of component and recon- figuration design verification early on; partial implementation of an invalid design may lead to time-consuming changes and revisions that impede the progress of the sprint. At the same time, the team is empowered to make the correct trade-off between the forces of agility and early verification based on the current project context, and other existing forces.

In total, the second embedding shown in Figure 5.4 provides a more nat- ural and realistic embedding of the formal verification of component and re- configuration design into a system development effort. Rather than imposing a strict ordering on how to proceed, the development team is empowered to decide how to intertwine the formal verification process with other activities in the sprint for maximum benefit.