The Nested Cyclic Convergence Software Development Process

In my professional life I have been involved in a range of software development processes: from “just do it” in small projects, i.e. no process at all, over agile & iterative development processes in projects of various sizes, to more formal processes, e.g. for safety critical systems following EUROCAE ED 109A. The outcomes varies accordingly as the following diagram tries to show.

Torn between two extremes: just do it no process to prescriptive processes, one likely to end up with something akin to Howl’s Moving Castle, the other one achieving something like the Concorde.

In the middle of the two extremes lies somewhere Agile Software Development which I do quite enjoy, in particular the iterative aspect. With its epics, stories, issues, and all of that it all feels natural. At times, however, one gets the impression that agile development is used as an excuse or exemption from thinking things through in advance and as a wild card to just rush in. It should not be that way as there is a cost in refactoring later what could have been avoided with a little bit of foresight. While this is still acceptable for pure software projects, it would not be possible in anything that involves hardware, or civil engineering, e.g. the Millau Viaduct; there, things have to be done right first time round. It is all a matter of good measure.

In my experience, agile processes do not consider the need for consistent life cycle documents such as requirement specification, design description and other traceability artefacts, e.g. needed for a safety case. On the upper end in the scale of process complexity, the execution of a V-model Development Process in a chronological interpretation as a Waterfall Model showed me that this approach does not reflect what really happens; it becomes even more questionable if the tools used in and for various stages of the process are very different and do not allow or enforce the generation of consistent artefacts.

Given the positive and negative aspects experienced in each process, I tried to define a different process as a synthesis, the combination of both an iterative process and the V-model at various levels: the nested and cyclic execution of a V-model, or the Nested Cyclic Convergence Development Process. It is an evolutionary process, starts at an embryonic stage with seed artefacts, continuously runs cycles in nested loops, and finally converges to a stable piece of work. At the inception of a new project the scaffolding for all artefacts is created as a template. As the project evolves, a consistent cross section of artefacts can be produced at any time. It is a relational interpretation of the V-cycle and aspires to reflect more how processes, even formal processes, are run in reality.

To Start with, the Usual Suspects

The software development process (SDP) as described here covers the requirements analysis, architectural and detailed design process, construction process, the integration process and verification process. There are guides to be found on the Internet how to run each of those, so I won’t go into their details, nor into the standards to be used at all stages. Figure 1 describes the various stages of the software creation process, its inputs and outputs as well as the relationships with sibling processes.

Figure 1: Complete V-model (or rather U model) from external input to verified output.

The global input into the process is the System-Subsystem Specification (SSS) which is usually an input to a System Development Process. Since the software development process needs to address system aspects of the software to be developed, it will generate software portions of the System Subsystem Design Description (SSDD). The output of the overall process is a collection of verified and integrated Computer Software Configuration Items (CSCIs), along artefacts such as the Subsystem Requirement Specification (SRS), Subsystem Design Description (SDD) and Computer Software Unit (CSU). COTS stands for Commercial Off the Shelf component.
Note that Interface Specifications, Test Descriptions and Reports etc are not shown in Figure 1 to keep the diagram relatively simple.

Observations in development

For some products a single run through the sequential process described above as a Waterfall Process may be appropriate and feasible. For most products, however, the development process is quite engaging and the product development cycle has, realistically, to be carried out in iterations for the following reasons:

1. Exploration allowance: nothing can be designed ex-nihilo. In order to carry out a requirements capture and analysis, there has to be a notion of a product concept or proposition, and in order to produce some preliminary design, there has to be some knowledge about the feasibility of the implementation, e.g. external libraries or available technologies.
2. Design and implementation feedback: while in a top-down design many details may well be anticipated, when a design is eventually implemented, or an implementation is exposed to real data, weaknesses at a higher level may be exposed which necessitates to re-run parts of the process (the devil is in the detail).
3. Accommodate change during process: there is a commercial need to rapidly accommodate new or changed requirements to support contractual needs, product enhancement and market advantage (embrace change rather than fight change).

The relationship between all boxes in Figure 1 has to be seen as a logical one; it establishes a logical dependency between the various stages, but it does not necessarily command a chronological execution, even though it is interpreted as such quite often. Alternatively, the processes shown in Figure 1 can be executed in a more cyclic, iterative manner that can best be expressed in a state diagrams, while maintaining the logical relationship between its constituents at all times. In the following the nested cyclic approach will be explained in its two main stages, an initial exploration cycle and the continuous improvement cycles at various levels.

Initial Exploration Cycle

This initial, exploratory cycle is sometimes referred to as Iteration Zero in literature of Agile & Iterative Development and is shown in Figure 2.

Figure 2: Initial cycle: iteration zero as exploratory cycle.

Based on an understanding of the problem at hand and an initial concept a requirements analysis stage creates an initial draft of the SSS (red dot as starting point in Figure 2). This forms the input into an initial design stage that makes major design choices such as dividing up the system into Hardware Configuration Items (HWCIs), CSCIs, hardware and software COTS components as well as their interfaces at a conceptual stage. At this stage top level requirements are tentatively apportioned to the chosen CIs and COTS components.

The initial, conceptual design is captured in the initial draft of the SSDD (the Software aspects in the SSDD as far as this process is concerned). It may simply be a collection of functional block diagrams, use cases or sequence diagrams, perhaps only sketches on a napkin, scanned and put in source control at their appropriate place. Also at this stage choices are made on communication protocols that could be used. Quite importantly, COTS software will be identified at this stage for assessment and, if chosen, be subject to the COTS qualification process.

The construction cycle at the system level means that for every CSCI identified a sub-process is spawned with its own cycle: an initial requirements analysis, i.e. an intial CSCI SRS, an initial design as CSCI SDD dividing up functionality into CSUs and also identifying COTS software as appropriate (with an associated COTS qualification process). The software construction at this stage is mostly about exploring the feasibility and will use stubs that emulate functionality or even HWCI. Stub CSUs may be integrated into candidate CSCIs, loosely verified against the CSCI’s SRS, and then handed back to the system cycle.

Back at the system integration level, CSCIs (and potentially emulated HWCIs) will be integrated into a more or less functional system. The objective is to obtain an understanding whether the design would work in principle, e.g. software can be constructed and run with the performance and timing requirements, or third party libraries and COTS components behave as expected. Finally, an initial integration and verification framework will make sure that the CSUs and CSCI will be subject to regression testing and verification.

The result of the first cycle will be a deeper understanding of the possibilities in design and implementation which will inform the next cycle. It may result in revising top level requirements, because they may not be achievable. The first cycle may result in the knowledge that some software function needs to be implemented in hardware in order to meet performance requirements. Conversely, some function which was initially apportioned to hardware may equally be fulfilled by COTS software or a CSCI yielding higher flexibility.

It may all sound a bit onerous, in particular for developers who want to get their fingers into the code, because they feel: I know what I have to do, I have a rough idea how to do it and I will figure out the details as I go along; no need to waste time and money on design. That is the reason why I would advocate only a minimum of these formal activities at the start; this part may well be templated. Just enough is needed to create a minimum viable product, but with all the documents in an embryonic stage.

Continuous development

After the initial cycle, there will be a sequence of many more cycles, all controlled through the Configuration Management Process. Changes may arise from all stages of the development cycles, top-down as well as bottom up, such as minor code or major design enhancements cued by changes in requirements, re-factoring of code, bug fixes, etc. All do not necessarily trigger full cycles. These cycles operate in nested loops between all stages as shown in Figure 3.

Figure 3: Software development process with feedback loops

These feedback and feed-forward mechanisms are all to be captured in the Change Management as follows:

1. Design –Analysis: It may turn out that a certain requirement change necessitates a fundamental redesign of a CSU. Conversely, some design constraints will need to re-evaluate certain requirements, e.g. perhaps they are not feasible;
2. Design — Construction: It may turn out that a small design change entails a large re-factoring effort. Conversely, implementation details constrain the design leading to a redesign, e.g. data-processing has to be multi-process or multi-threaded;
3. Design –Verification: It may turn out that the design has to be reviewed in order to allow or facilitate verification;
4. Construction — Verification: the regression as part of the verification may flag issues in the implementation;
5. Analysis — Verification: It may turn out that some requirements are not easy to verify and have to be changed;
6. Construction — Analysis: It may turn out that implementation constraints may the achievement of some requirements impossible and the requirements have to reflect implementation constraints.

As the software matures the cycles will converge as shown in Figure 4. Note that usually the system cycle is likely to have less iteration, but every CSCI may have several iterations, all at their own pace.

Figure 4: Software Evolution and Iterative Convergence

All software development artefacts (SSDD, SRS, SDD, CSU, CSCI) will evolve together and remain consistent with each other at all times; a full set of software artefacts can be produced after every iteration at any level. As the product matures, the differences between the cycles will become smaller. Conversely, the convergence of the software state attractor is an indicator of software maturity. The output of every iteration is verified software with all process artefacts in place.

Requirement Specification of a Tool Set

Unfortunately, I still haven’t found a set of tools that allows for all that process in an easy way and can be used by all participants and stakeholders. At the moment I get by with all source and all process artefacts of every stage being kept in a single version controlled space; then some tooling is needed to tie specifications, documentation, source code, continuous integration and artefacts together. But it is not ideal, as not all stakeholder work with source control systems, and there is no programme management, either.

In order for this process to work, a set of tools needs to:

• allow to boot-strap and evolve all documents and process artefacts as well as all source code together with automatic version control on changes,
• allow stakeholders to capture requirements in a comfortable manner with tracking versions vertically through design, implementation and verification as well as chronologically, but also in a way that the information can be used in automatic tools in Continuous Integration to generate versioned requirements specifications and verification cross reference indices,
• allow software engineers to produce design documents in a comfortable manner, not repeating code but describing concepts and rationale, and nevertheless linked to source code which may be augmented with some but not all information, all in a way that the information can be used in automatic tools in Continuous Integration to generate versioned design descriptions and interface specifications,
• avoid redundancy of information and enforce consistency at all times by design; developers hate to provide the same information in various places as part of the perceived process tedium,
• allow project and programme management to capture the work flow from inception to completion of the whole or of features, a historical analysis of work done and a more statistical approach to prediction using expected duration and variances, or other measures of uncertainty or confidence.

There are pieces of the puzzle available, but I am still looking for a set of tools that is not too onerous and minimises tedium.