In Connected Systems, the Software Development Lifecycle Lasts a Lifetime

Until recently, the software development lifecycle generally ended at product release. Connectivity, however, has extended that development lifecycle to the lifetime of the product or as long as it’s in the field. Unlike isolated systems, the software requirements for products such as connected cars can change at any time, whenever changes occur in the product’s connected environment or a new security vulnerability is discovered.
Each newly discovered vulnerability implies a changed or new requirement that requires an immediate response. Revised code must then undergo static analysis and all impacted unit and integration tests need to be re-run (regression tested).
The system itself may not have been touched by development engineers for a long time, so being able to isolate and automatically test only the functions impacted becomes much more significant.
This adds new importance to automated requirements traceability tools and techniques. By linking requirements, code, static and dynamic analysis results and unit- and system-level tests, the entire software development cycle becomes traceable. That makes it easy for developers to identify problems and implement solutions faster and more cost effectively—even after product release.
Figure 1 - Software-development V-model with cross-references to ISO 26262 and standard development tools

Process Objectives and Phases Using V-Model and Industry Standards

Using our connected car example, Figure 1 illustrates a V-model with cross-references to the automotive ISO 26262 standard and tools likely to be deployed at each phase in the development of complex automotive software.
(Other process models such as agile and waterfall can be equally well supported and the same principles apply to other safety-critical industries and standards). Moving through the V-model, we’ll examine each phase in terms of its impact on traceability.
System Design: This phase sees the technical safety requirements refined and allocated to hardware and software. The selection of appropriate tools helps in the maintenance of bi-directional traceability between phases of development.
Specification of Software Safety Requirements:
This phase provides the interface between the product-wide system design standard and software-specific requirements, and details the process of evolution of lower-level, software-related requirements.
Figure 2 - Graphical representation of control and data flow as depicted in the LDRA tool suite

Software Architectural Design: Static analysis tools help verify the design by means of control and data flow analysis of the code derived from it, providing graphical representations of the relationship between code components for comparison with the intended design (see Figure 2).
Loading... Loading...
×