How to Incorporate Guidance into Process Execution Using ALM

How to Incorporate Guidance into Process Execution Using ALM

In a previous article we discussed the concept of treating process guidance (work instructions, industry standards, internal procedures, etc.) as requirements that teams can directly link their project artifacts within their application lifecycle management (ALM) solution. By doing so, teams unlock powerful benefits that will help them more efficiently deliver software and systems and demonstrate their compliance with process guidance through end-to-end traceability links from guidance to project execution and deliverables.

Previous Article: How to Capture your Processes and Regulatory Requirements in ALM

This can be implemented in a number of different ALM solutions, but to give a more specific example we will highlight how teams may approach doing this using IBM® Engineering Lifecycle Management® (ELM), an ecosystem of applications that offers extensive configuration management and link traceability features that are key to managing process guidance while allowing different projects to independently adopt different revisions of that guidance.

There's a lot to unpack in that last statement. Standards, best practices, work instructions, and other forms of process guidance are in a constant state of evolution. Some are updated every few years, others yearly, quarterly, or more often. Even if some standards are relatively static, corporate guidance on those standards can change over time. To look at it from a different perspective, these are project dependencies that are developed, published, and revised on a schedule that is largely independent from other projects in the organization. It is important that teams aren't simply aware, for example, that they need to comply with ISO 26262. They need to know if they are following the 2011 or the 2018 revision. And in cases where teams are managing multiple long-running projects, they may at times be following different revisions of a standard simultaneously.

This is where configuration management becomes incredibly important: there must be a way for teams to document which guidance and which revision they are utilizing in each project they are working on. Configuration management is the glue that allows teams to say, "This is what we will build (req spec), and this is how we should do it (guidance)". Project execution and test management complete the picture by providing planning, issue/defect tracking, and verification.

Coming back to IBM Engineering Lifecycle Management, the following applications provide the bulk of the solution that can achieve this:

¹ Formerly Rational Team Concert
² Formerly Rational Quality Manager

Configuration Management Terms

Before diving into the applications, we need to explain some of the terms used when discussing configuration management in the context of IBM Enterprise Lifecycle Management. In many ways these terms are derived from software development practices.

DOORS Next Generation

DOORS Next Generation stores individual requirements but also can group requirements together in collections or modules, the latter enabling requirements to be presented in document-like form. Each requirement can be linked to issues, tasks, models, test cases, or other requirements to enable traceability. Using configuration management capabilities built into DOORS, teams can separate requirements into components, for example, to separate product requirements into different systems and subsystems. Each component has one or more streams with each representing an ongoing development process. These streams could be set up the following way:

• One master stream representing the most up to date requirements for a system
• One or more variant streams, likely spun off from the master stream, tracking requirements for a specific product release

Each stream may be baselined to capture the state of all requirements contained in the stream. These can be treated as releases or release candidates that product development and testing are based off of.

These are powerful features that can be leveraged to support variant development and increase reuse of common requirements across different systems.

Let's say a team is managing the requirements around an active lane centering system. This system may have high-level requirements that apply to the system as a whole as well as a decomposition of requirements specific to dependent subsystems, such as sensors, actuators, and a control module. There are other external systems the lane centering system interfaces with, such as braking and steering. In an organization working on a number of product releases, there are likely multiple variants of each of these systems and subsystems under development. Organizing these into their own components and developing each variant within its own stream allows teams to ensure that changes to one system variant does not affect another.

This is powerful functionality but adds some complexity. If there are three variants of a lane centering system under development, each dependent on ten different subsystems, each with their own variants, it can quickly become difficult for teams to ensure they are working against the right set of requirements. Maintaining dependencies between the system and its subsystem also requires knowledge of which variants are in scope.

These issues are quite similar to those described around process guidance and, fortunately, there is a common solution for them.

Global Configuration

The Global Configuration component of the Jazz ecosystem attempts to solve this web of variants by allowing teams to define all the systems, subsystems, and specific variants that make up a project. It also provides a "configuration context" that allows each team member to select what they are working on (the context) and get a view of requirements, models, and tests that apply only to that context.

Looking at the lane centering system example again, a team may define a single global configuration component representing that system. Just as in DOORS and Test Management, global components have streams. Within each stream the team can then pull in each DOORS, EWM and ETM component – along with its applicable stream or baseline – that makes up the system. Once this is in place, team members can select the stream as their configuration context and navigate around all the ELM tools, only seeing content specific to that stream.

This is a view of a global configuration showing the structure of a vehicle project containing all the different components in ELM related to that project. Standards guidance for ISO 26262:2011 is in its own component as well, so users accessing this project will only see guidance specific to that standard and revision.

The top of the screen shows the user is working on (automated lane control system) ALCS requirements (component) for the Vehicle SUV XY – 2022 project (global configuration context).

Process guidance can be added to the mix in the same way: teams can add in the different component streams or baselines representing different industry standards, internal guidance, and other content that is applicable to the development of the system.

Global Configuration also enables linking artifacts across different components, for example, to link a test case and its results to its related requirements, tasks, and other items.

Tracing Requirements and Work Products Back to Process Guidance

Just as requirements can be linked to test cases and defects, they can also be linked to standards they are derived from. The lane centering system's main DOORS component for a 2022 model release may include an item definition document that fulfills that specific ISO 26262 work product. The lane centering team knows they produced the document and where it's located in DOORS, but other teams, such as functional safety competency team, would not have this information.

This is where we can make full use of DOORS and Global Configuration. The team maintaining internal process guidance for an industry standard can define a set of requirements describing the work products that may need to be produced as a part of developing a new system or a new version of a system. Teams developing systems that fall under that standard can then link their work products to those requirements. By doing this, a number of benefits become available:

• Development teams can demonstrate their compliance with the standard within the tool itself. They can also check for gaps between the standards and their own work more easily.
• Compliance teams can run reports against ELM and create dashboards tracking standards adherence across projects. With this increased visibility numerous emails and status meetings can be eliminated.

And in cases where teams need to follow different standards per project, Global Configuration allows them to pick specific standards, even different revisions, so that each project's context contains only those standards and revisions that apply.

Development teams can go one step further by developing their own internal project procedures and linking them back to standards and higher-level corporate guidance. If there is a specific set of tasks that must be executed for each project a team works on, they can document that as a template with links to any requirements satisfied by those tasks. They can later take this template and turn it into a project plan in EWM. This enables even more powerful traceability reporting, such as a real-time cross-team status report on standard work products that need to be completed by the next project milestone.

The ALCS team has defined a set of functional safety activities in their project that produce specific ISO 26262 work products.

When the procedure is created in EWM, visual traceability is possible between the ISO 26262 work products and the EWM work items implementing them. Color coding and other visual indicators can be added to show the status of the deliverables and the teams responsible.

Conclusion

This solution example highlights some powerful benefits by incorporating guidance into project execution using ELM. The investment required to put this in place depends heavily on how mature teams are in documenting their processes and how well they can demonstrate that those processes adhere to applicable corporate procedures and industry standards. Conversely, the cost of missing, incomplete, or outdated documentation may be far greater if products are released with more defects or organizations are unable to demonstrate compliance to standards or regulations.

Even where documentation exists and is well maintained, there can always be a gap between what is documented, what teams are aware of, and what ultimately happens during project execution. Placing this documentation within the same system managing requirements and project plans increases its visibility and enables productivity improvements through real-time project reporting that can eliminate numerous emails and status meetings.

If you are a manager or chief engineer: Do you know if your teams are following a standard, and how can you prove it in an audit? If you are an engineer: Are you sure you need to create that item definition, and do you have the right work instructions to do so? Can your organization answer these questions in minutes without sending emails or calling a meeting? This solution offers that possibility.

Interested in learning more about ALM for your organization? Contact our team today! 

Further reading and references

• How to Capture your Processes and Regulatory Requirements in ALM
• SME Interview ALM Tools for ISO26262 Compliance