Posted on by Cyber-physical Systemsin
By Robert V. Binder Senior Engineer Software Solutions Division
As Soon as Possible
In the first post in this series, I introduced the concept of the Minimum Viable Capability (MVC). While the intent of the Minimum Viable Product (MVP) strategy is to focus on rapidly developing and validating only essential product features, MVC adapts this strategy to systems that are too large, too complex, or too critical for MVP.
MVC is a scalable approach to validating a system of capabilities, each at the earliest possible time. Capability scope is limited (minimum) so that it may be produced as soon as possible. For MVP, as soon as possible is often a just a few weeks. But what does as soon as possible mean for an MVC? This post explores how technical dependencies and testability determine that, and what this implies for a system roadmap. Let's start with the pattern of MVC activities to produce a major release.
The MVC Release Pattern
Cyber-physical systems can comprise hundreds or thousands of distinct capabilities. Typically a capability is achieved by integrating software items (SI), hardware items (HI), and other capabilities. Each capability depends on the presence of these components or at least a proxy sufficient for testing. Eventually, MVCs will become full capabilities (FCs). Taking all this into consideration, laying out a feasible and effective CPS roadmap is an enduring puzzle. The following steps sketch how the MVC strategy can solve this puzzle. MVC relies on Agile practices, so the overall plan is fluid, but sprint backlogs are not. The following order is typical, but should be adapted as needed:
MVC, Architecture, and Testability
Point releases of MVCs may not be acceptable for full production use or field trials, in contrast to MVPs that are released as soon as possible to get rapid feedback. Realistic, automated, and sufficient testing of MVCs and system point releases is essential to provide rapid feedback.
Sufficient testing requires testable MVCs. While capabilities are typically defined with quantitative and behavioral requirements, they must also be controllable and observable, i.e., testable. Control and observation are typically achieved by a separate testing system. The effectiveness of the testing system is limited to the testability of the system under test. To be controllable, capabilities must be independently invokable, have working interfaces that support automated testing, and allow configuration to evaluate their full behavioral range. To be observable, a capability's behavior and/or output level must be practically and reliably recordable for evaluation.
As a result, testability is a driver for architecture and MVC definition. System architecture cannot therefore simply be an inventory of hardware items, software items, and their physical interfaces. It must define which of these elements is needed to support a capability and which capabilities depend on others. Sequence diagrams are one simple representation that can often provide this.
Why This Works
MVC addresses critical questions for cyber-physical systems with a large installed base or where customer acceptance is only one of many required measures of effectiveness. To see why that is, let's consider the full spectrum of release frequency and scope. The figure below shows how risk and efficiency change as a function of release frequency and scope. More red equals more risk or waste, yellow possibly acceptable risks, and green indicates a feasible trade of scope and frequency.
This notional chart illustrates the MVC concept and does not represent any particular system. It is worth repeating that scope is the net change, not the absolute size of a system.
The infeasible region (northwest corner) represents combinations of large scope and high frequency that are substantially more risky. The wasteful region (southeast corner) represents combinations of smaller scope and low frequency resulting in slack time between releases that probably could be put to better use, perhaps by increasing frequency.
In contrast, MVP focuses on high frequency cycles for small scope products or feature set increments, indicated with the blue oval.
Scope versus Frequency: Long-term Planning Versus Rapid Delivery
For most large systems, a release roadmap does not focus on a single scope or release frequency. Their roadmaps often include multiple releases of different scope, each consisting of carefully selected capability sets matched to a feasible frequency. Microsoft Windows is one example of this. The Windows operating system is a truly a huge system, but is released on several frequencies and scopes.
The Windows case is an extreme example since it is a very large and complex collection of software products. As noted above, a major release cadence of 12- to-18 months is preferable and feasible for many applications. Note that the pre-release development effort of a capability, even at the southwest corner of the chart, can be considerably longer than the span between releases.
Wrapping Up and Looking Ahead
The third and final post in this series, How to deliver a Minimum Viable Capability Roadmap, will argue that the MVC strategy relies on a well-formed and testable architecture with early validation, just as for MVP. As result, a capability-driven architecture model can guide a just-enough implementation and support realistic evaluation of point and major releases.
View my keynote, Testability: Factors and Strategy, which was presented at the 2010 Google Test Automation Conference.
Read the article Impact of Budget and Schedule Pressure on Software Development Cycle Time and Effort by Ning Nan and Donald E. Harter, which was published in the Sept.-Oct. 2009 IEEE Transactions on Software Engineering.
Read the article Wavefront: a goal-driven requirements process model by Mary Frances Theofanosa and Shari Lawrence Pfleeger, which was published in Information and Software Technology Volume 38, Issue 8, 1996.