A New Approach to Traceability Can Solve Software Product Validation Issues
A New Approach to Traceability Can Solve Software Product Validation Issues
In Agile software development there are constant changes to multiple parts of a product at the same time. How can you keep track of them all?
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
Much like the practice of enterprise software delivery itself, traceability is complex and fast becoming one of the biggest technical headaches for organizations worldwide.
It’s easy to see why. Think of all those concurrent product lines. All those evolving features. All that mutable product information that specialist teams create and depend on during different stages of the process. Think of how the essence of Agile means requirements constantly evolve from backlog to deployed.
Think of all the planning, articulating, building, testing and deploying. The ongoing customer feedback. The second iteration, the third, fourth, fifth and so on. Think of all that honing, continuous collaborative development. Few things are static in software delivery. Being able to capture every activity matters.
This type of work asks some key questions about product validation: How do you trace multiple elements pertaining to one product when all these elements are constantly being edited by different stakeholders via different systems? How do you obtain that essential “one source of truth” so that everyone has an omniscient view of the value stream and can see every task, activity and comment a stakeholder has made in relation to a product’s development?
A spreadsheet or even a requirements traceability matrix (RTM) simply won’t cut it—they lack the deep sophistication required to document and link all these moving parts. As a result, the industry is crying out for a better, more practical way to manage and trace this immense body of iterative work as new features come to life.
What Do We Mean by Traceability?
Traceability can mean different things in different industries, but ultimately it’s about product validation. In general, traceability is a crucial element that underpins three critical business management processes:
- Quality Management: enabling organizations to hit quality targets/meet customer expectations
- Change Management: tracking changes to product during development (before, during and post)
- Risk Management: tracking and verifying vulnerabilities to product integrity
Whether it’s an automobile, medicine, an airplane part or a software application, organizations need to be able to trace the entire lifecycle of all elements in their product iterations, including all associated changes. It’s the only way to validate what actually got deployed after all the dust settles.
The Limitations of Requirements Traceability
Traditionally, when people talk about traceability in enterprise software delivery, they’re referring to "requirements traceability"—the ability to trace the lifecycle of a requirement and its related design elements (tests, commits, builds, etc.) as it moves downstream towards deployment.
Organizations typically track these requirements in a requirements management tool via an RTM, which documents information relating to a requirement from initiation to completion. In modern software delivery, however, a requirement’s journey is now too complicated and nuanced for such an approach. It’s too narrow and static to capture the sheer volume and velocity of work—especially when you consider the spiraling network of specialists, tools and artifacts involved in creating a single iteration.
The key thing to remember is that there isn’t just one version of a requirement. Multiple tools store their own fragment of each requirement iteration that a specific practitioner will work on. Yet there’s no practical way to check, cross-reference and verify this work. No consistency or cohesion.
Sure, simple traceability can be managed in a spreadsheet. But when a product has lots of requirements and hierarchical relationships, dependencies and other linked artifacts (such as test cases) that travel through multiple systems, traceability becomes limited. You end up losing control of the product validation process.
A requirement management tool can only display information it has inherit access to. This means that a product owner or business analyst has a restricted view of the requirement’s journey, not it’s full lifecycle across the value stream. For example, if a requirement isn’t linked from a requirements management tool to a test tool, it’s challenging to know if you have completed test coverage.
For organizations in heavily regulated industries such as finance, healthcare, insurance and federal government, this is a deal-breaker. And even for companies outside those sectors, there is serious danger that they risk deploying a wrong or malfunctioning product that undermines a quality delivery.
To combat this, we need to consider an approach to traceability that gives the business assurance that product validation is being fully covered.
Bringing the Fragments Together for a True Reflection of Product’s Lifecycle
When approaching traceability, organizations must enable collaboration, transparency and linkage across teams and multiple tools. Sounds simple, but to obtain end-to-end traceability, you need data integration that allows all teams to collaborate on artifacts from within their respective tools. All teams need to be singing to the same traceability hymn sheet.
The tools that practitioners use in the "plan and design" stage, however, do not naturally integrate with tools further downstream in the "build and deploy" stage. To address this, both functional areas need to be sharing the same information automatically. By connecting all tools across the value stream, organizations can then visually trace the full lifecycle in an automated fashion. A good way to begin a lifecycle traceability initiative is to start by building traceability either upstream or downstream.
Downstream Requirements Traceability
Downstream requirements traceability typically traces requirements to their related design elements downstream, e.g. sub-level implementation elements, test cases and then back to the source requirement. The key for downstream requirements traceability is cross-tool integration that enables a source requirement to exist across tools as a single source of collaboration, along with complete visualization of downstream relationship bindings.
Upstream Requirements Traceability
Upstream traceability traces development and implementation artifacts (and events) back to one or more of the original requirements as part of the configuration management process. There are lots of tools in the software build, deploy and automation spaces that generate events you’d want to have traced into the design and implementation work that happens further upstream.
Fortunately, continuous integration, continuous deployment (CI/CD) and release automation via DevOps tools provide pretty good extensibility via webhooks that can be leveraged for traceability. Here are some examples of how organizations are approaching upstream traceability:
Code Commit to Requirement Traceability
When a developer commits code in a version control system, the story in a developer’s Agile planning tool is automatically updated with a link to the version control’s changeset, as well as take the latter’s commit message, adding it to the issue in the Agile planning tool for code to requirement traceability.
Code Deployment to Change Request Traceability
When a release automation tool deploys code to a production environment, a new change request is created in an ITSM tool for an automated flow.
Test Automation to Defect Traceability
When a test fails in an automated test tool, a defect can be created in an Agile planning tool for a traceable verification and validation process.
Code Scan to Defect Traceability
When a code scan fails in a static code analysis tool, a defect is created in a project management tool for a traceable defect reporting and resolution process.
Performance Monitoring to Defect Traceability
When a performance analysis tool detects that your system’s slowing down, a defect is created in an Agile ALM tool for issue resolution traceability.
Ultimately, traceability first requires the ability to link all artifacts (i.e. collaborative product-critical information). Downstream traceability links requirements to all the related work downstream, while upstream traceability gives way to the configuration management process where specific lines of code, commits, builds, issues, deployments, etc. are linked to the original requirements.
By integrating all tools with traceability built in upstream and downstream, organizations can trace a product’s iterations in both directions, and ensure all work is tied back to the customer’s initial request and inevitable changing needs. They now have a method that can help them optimize the holy trinity of management processes – quality, change and risk – to be sure they are accounting for what changed, what got delivered and what issues were addressed to satisfy both internal and external standards.
Opinions expressed by DZone contributors are their own.