The importance of ALM for Aerospace and Defence (A&D)
Software development for the A&D industry differs from typical commercial software development in several key ways: the deliverables are often mission critical or safety critical systems, which require a level of rigour and quality that exceeds that of the average commercial software product; and the lifetime of the typical military system is usually far longer than that of the typical commercial software release. For example, the Honeywell H423 Inertial Navigation System was introduced in the early eighties and is still operational equipment on a number of military aircraft almost a quarter century later. Also, the A&D industry uses contract-based procurements far more heavily than commercial industry does. Contract-based procurements tend to explicitly define requirements for the systems being procured, rather than identifying a commercial product and accepting its attributes as is. These long lifetimes and the bespoke nature of most A&D systems naturally lead to procurements that explicitly follow a system life cycle model.
The software standards called out by A&D projects mandate strong configuration management and corrective action processes. The corrective action process is also known as change management; it complements configuration management by identifying the requests for change, prioritising them, approving (or rejecting), as well as monitoring and reporting on the status of the requests for change. The configuration management process then ensures that approved requests for change are implemented in a controlled and consistent manner.
A modern ALM system automates and streamlines these two core lifecycle processes, not only managing the source code developed for a software project, but all the artifacts within the development process along with the relationships and dependencies between those artifacts. Such an ALM system should explicitly handle complex configuration hierarchies, supporting proper versioning, branching and re-use at any level of the configuration – not just at the level of individual artifacts. A&D-related software development projects work with specifications that are configurations of individual requirements, design documents that are configurations of design elements and test plans that are configurations of test cases, as well as source code configurations. The contractual nature of A&D-related projects often results in subcontractors working on disparate components of the system, with the prime contractor taking on the job of integrating these pieces into a cohesive whole. To support such development strategies, the ALM system must support working at multiple levels of granularity, from individual files and tasks through to major subsystems and subprojects.
As part of the automatic enforcement of the change management process the ALM system ensures that all development activities follow the workflow defined by the change management process and that only approved changes are actually implemented. Just as a modern ALM system allows developers to manage configurations at the component or subsystem level, such a system allows change management at the task level by providing support for packages of logically related changes. Such change package support simplifies the management of work in progress and ensures that the full set of changes needed to implement a change request can be applied as a single update to the configuration being worked on. Change packages also provide a concise means of reporting the differences between two revisions of a configuration.
Project management support
A proper ALM system also provides strong support for project management. Given that all work activities are captured within the ALM repository, and the process engine enforces proper process and the linkage of activities to requirements and their work products, all the data about the current state of the development project is contained within the common ALM repository. The ALM system leverages this by providing strong reporting and dashboard capabilities that enable the real-time display of project status and the ability to drill down to appropriate details quickly and easily. Such an ALM system should also have analytic capabilities, so that key metrics are automatically computed and actual results can be compared against planning estimates. Such capabilities allow project managers to easily manage by exception, focusing their efforts on the tasks and subprojects that are behind schedule or over budget, or in danger of becoming so.
ALM systems are better at supporting real-time, closed loop project management than traditional project portfolio management (PPM) tools because the development activities and resulting artifacts are managed and captured by the same system, with project status automatically rolling up from the work records in the single common repository. With traditional PPM tools, the results of the development activities have to be entered into a separate PPM repository, either manually in the form of status reports and time entries, or via custom integrations with the other tools used to manage the development artifacts. Latency and accuracy of the data transfer are common problems with standalone PPM tools.
Modern ALM systems typically integrate with the project planning capabilities of PPM tools, since resource scheduling and forecasting are not aspects of managing established projects. A good ALM system should provide project managers with the ability to either manage projects using built-in reporting and dashboard presentation capabilities, or to update the PPM tool used to plan the project (for those managers who want to work only in the PPM tool).
Automated traceability
Traceability is a major activity in most A&D-related projects, unlike most commercial software development projects. The more rigorous verification and validation requirements mandated by the safety critical or mission critical nature of the software, combined with a tendency for formal gating reviews at key points in the project’s lifecycle, impose strict end-to-end traceability requirements on software developed for A&D systems. Traditionally, such traceability was a manual task, with teams of system engineers and software developers generating voluminous traceability matrices mapping from one set of artifacts (e.g. the requirements in the software requirements specification document) to another set of artifacts (e.g. the design models or the source code files). ALM systems can provide enormous labour savings by automating such traceability analysis and reporting.
With a proper ALM system, such linkages are automatically maintained within the single common repository, and it is a straightforward matter to generate reports identifying all requirements that do not map to corresponding development deliverables, or reports identifying source code that does not clearly derive from an approved requirement. A good ALM system should provide powerful but intuitive navigation and reporting capabilities so that reviewers can start at any point in the development lifecycle and trace back to the initial requirements or forward to the final deliverable. Since the relationships between all artifacts are automatically maintained in a common repository by the configuration management capability of the ALM system, such traceability reports are always current and reflect the actual state of development. With manually generated traceability matrices, there was always a strong risk that they were out of date or contained errors. Attempting to implement an ALM system with a set of loosely integrated point solutions does not provide the same level of automated traceability, since navigation across multiple repositories managed by different tools is not easily automated.
As stated earlier, verification and validation activities are typically more rigorous than with commercial software development projects. It is essential that such activities be tightly coupled with the other development activities, and there are a number of ways that a modern ALM system can streamline verification and validation efforts while improving the results. First, by implementing testing and other verification processes using the same process management engine that implements requirements management, configuration management and change management, inter-process constraints and dependencies can be explicitly defined and enforced. Secondly, with a common repository for all activities and artifacts that also tracks the linkages between such objects, test coverage analysis and impact analysis for proposed changes can be automated to a significant extent. Third, an ALM system can ensure that only controlled, approved configurations are handed off to QA for build and testing. Automated deployment and continual control of the configuration through the release management process ensure that what is built and tested corresponds to the approved configuration released from development. When defects are found in the process of testing a candidate configuration, the common process engine streamlines the process of generating defects and change requests to address those defects and ensuring the appropriate linkages to source code and requirements are established.
ALM can offer enormous benefits by automating the change control and configuration management of sets of requirements, and providing built-in linkages to the other development processes and their artifacts. This tightly coupled aspect is what distinguishes ALM systems from discrete point solutions such as version control tools and bug tracking tools. A good ALM system implements all development processes using a single, consistent workflow engine, and manages all development artifacts in a single logical repository, with linkages between artifacts automatically generated and updated as a result of the activities performed using the system. ALM systems automate the configuration management of all development artifacts, from requirements through design documents, test cases and source code, to the final deliverables, automatically ensuring end to end traceability.
A modern ALM system also takes into account the preferred way that various roles want to interact with the development artifacts. For example, most systems engineers or requirements analysts prefer to work with sets of requirements in a document-centric manner; their goal is to produce specification documents. Developers and unit testers, on the other hand, want to link their tasks up to individual requirements that their source code or test cases are intended to address. Traditional point solutions tend to support only one way of working with the artifacts, and are optimised for one role in the development organisation. The latest ALM tools, on the other hand, provide flexible views of the work process and artifacts – they can offer a document-centric view of sets of requirements to systems engineers, and provide developers or testers with relational views of individual requirements, or list views for reviewers.
The tightly-integrated nature of modern ALM systems also allows for holistic component re-use. Often in the past, re-use was limited to only a small subset of the development artifacts; perhaps just the build artifacts or source code. Without ensuring all the related artifacts and their appropriate context is also shared into the new project, serious errors can occur. One such example is the Ariane 501 satellite launch in 1996, which had to be destroyed just after take off due to an exception in its guidance software at a cost of approximately one billion dollars. The guidance software had been designed for a previous generation of launch vehicle, the Ariane 4, and the requirements and design of that component were never reviewed in the context of the Ariane 5’s intended flight dynamics or requirements. Ironically enough, the particular function that caused the failure was not even required for the Ariane 5 launch vehicle’s operation. By implementing proper ALM methodology, re-use of the guidance software component would have forced the inclusion of the requirements, design documents, test plans and test cases for that component as well. Such an approach would make such inconsistencies easier to find.
In conclusion, Application Lifecycle Management is a holistic approach to software development that emphasises the interrelated nature of the various phases of the software development lifecycle. ALM tools provide a common process engine and powerful configuration and change management capabilities that automate the management of all development artifacts and the relationships between them. ALM tools also provide comprehensive reporting and query capabilities to support project management, review and auditing requirements.