In the first part of this article, we saw how continuous engineering extends the idea of continuous delivery to the analysis and design phases of software development. We discussed why concepts like global traceability, configuration management, and interoperability are essential ingredients in a continuous engineering recipe. In this part, we conclude our discussion by introducing the other, more complex constituents in the mix.
Product Line Engineering
One way to create multiple product streams is to clone artifacts from another stream and then modify them. Called the 'clone and own' approach, this method has been in use for a while; sometimes on the hush-hush. It is not suited to continuous engineering environments simply because the frequency of change and the number of product streams makes it unmanageable. Given that most changes to a global configuration are incremental and do not touch most of the artifacts, why should one replicate the entire set of artifacts to accommodate changes in a handful? This 'wisdom' led to the emergence of the concept of 'product line engineering' (PLE).
PLE emerged from the automobile industry, whose age-old product line concept has helped inspire innovation in many realms of life. Automakers with multiple variants of a car try to be cost-effective by re-using as much of one core assembly line as possible. The approach is not just cost-effective but also usually great for quality. Once the equipment or assets on the core assembly line are tested, they don’t need to be re-tested for every car variant that is produced. Only the additional equipment needed for the new variant needs be tested. Not only is the quality control effort reduced, but the output tends to be more standardized.
Extrapolating the concept to software, PLE recommends that software engineers create a core set of reusable assets (like a core assembly line). These assets may be requirements, use cases, help documents, code, test cases, and anything else that is unlikely to change and can be re-used. As you would imagine, identifying a set of core assets is not easy and requires a certain degree of experience. Nevertheless, if done well, PLE can reduce the complexity of managing continuous engineering, especially when there are a number of products and devices—as with IoT.
Analysis of Engineering Information
The number and diversity of IoT products throws up another demand from software engineering—data analysis. Each software artifact contains engineering data, such as: prerequisites, dependencies, links, models, and so on, analysis of which provides valuable insights. For instance, if a pollution standard changes, impacting a running system, you would need to identify the devices and software products that are affected by the changed standard. You could do so by analyzing 'engineering information.' That’s why sophisticated analytical tools and queries are integral to continuous engineering of IoT systems, where the number and complexity of device types make manual analysis impractical.
Model-Based Systems Engineering
One of the primary purposes of this engineering data is to inform sophisticated modeling tools. Modeling tools are popular in IoT systems because they help test devices which, unlike software, cannot always be tested in 'production-like environments' simply because such 'production environments' may be non-replicable real-life situations (like motor accidents).
Since real-life situations change continuously and unpredictably, an IoT system must be flexible. Flexibility comes at a cost and, as just mentioned, may not always be practically verifiable. 'Model-based engineering' is an alternative to designing systems and testing under actual conditions. Although not a perfect solution, modeling does help detect defects early and relatively painlessly. Sophisticated modeling tools 'abstract' and simulate complex IoT devices and real-life conditions on computer screens. Imagine there's a small change made in a car safety device; Would you rather go through the entire cycle of manufacturing the device with the changed component and get it tested on a real circuit by a real human being, or would you prefer feeding the parameters into a computer program that models the device and simulates a crash?
Clearly, modeling tools that simulate hardware and software are going to be central to system design and testing in the IoT era. Every continuous engineering solution must incorporate them.
Most of what we have discussed so far amounts to this: 'Verify and validate your work as early as you can.' For instance, if you have a 'concrete' but 'loosely expressed' new customer need, then you would want to convert it into a formally stated 'customer requirement.' If you were following 'continuous verification' principles you would validate that formal requirement with the customer as early as possible, preferably before converting it into a use case or design model. No point waiting till you have developed the requirement into a new product feature, only to find that your customer was expecting something else.
If you are familiar with 'continuous testing' then don’t worry... continuous testing is part of continuous verification, though conventionally the word 'testing' has been used for checking pieces of code, whereas verification also deals with 'testing' requirements and designs even before the first line of code has been written—wherever possible. Modeling tools that abstract hardware devices and software play a big role in continuous verification in the IoT era by ensuring that much of the validation is done before too much money or effort has been spent.
Implementing OSLC, global configuration, global traceability, product line engineering, and the sophisticated analytical and modeling tools of continuous engineering is not trivial. It requires a willingness to embrace change early, expertise that goes beyond continuous delivery, and sophisticated tools (like IBM’s Internet of Things Continuous Engineering Solution).
The office file tracking system that I alluded to in the beginning of this post could have been developed fairly efficiently using continuous delivery practices. Yet, in the dynamic environment that we live, the principles of continuous engineering that we just discussed would reduce the pain and cost of change. As the Internet of Things puts sophisticated technological solutions within our reach, a mature continuous engineering capability is what firms manufacturing these solutions need to stay competitive. Time to progress from continuous delivery to continuous engineering.