Bloggo back to the blog
Traceability within an Application Lifecycle Management (ALM) solution.-->
When organizations fail to deliver quality software on time and on budget, it is typically not because any individual is dysfunctional, but because the entire team or organization is misaligned. End-to-end visibility enables organizations to proactively steer projects to success based on real-time information.
End-to-end lifecycle traceability is a prerequisite for meaningful insight into project status, issues and risks. For example, the question, “Are we ready to release?” requires knowledge that can only be gathered by correlating requirements, code, build, and test information-data that potentially resides in four different repositories. The ideal environment will allow teams to easily link related assets and maintain those linkages as assets evolve.
Traceability is the ability to gain an end-to-end view across your project lifecycle. When your software is delivered to the customer, you should be able to identify all the activities associated with the software. You should be able to state with confidence that the software includes this specific requirement, included in this software build, validated by this test case and with this test result. Anything less and you really don’t know what you are delivering and whether what you are delivering will meet your quality requirements.
Traceability isn’t simply one of those “nice to have” capabilities in the software development lifecycle. Traceability helps you understand what everyone else on the team is doing. For example, while the requirements analyst knows very well what requirements she has written, she still needs to know whether a given requirement will be addressed during a specific development iteration and, if so, which one. Or she wants to know if the implementation of that requirement has been tested and
with what result.
An ALM solution that allows for lifecycle artefact traceability helps teams to answer the hard questions about requirements and risk management. By linking related artefacts, teams are better equipped to answer questions such as “which requirements are affected by defects?” and “which work items are ready for test?”
It is important to understand how requirements, test and development are linked by projects and tasks.
DON’T do traceability for traceability sake.
Identify a few meaningful questions or set one goal and institute a “just enough” approach for
linking related artefacts. For example, link requirements and test cases, link test cases and development work items. Try one and get good at it before doing more.
DON’T rely on reports that go stale after you’ve created them.
Practice continuous traceability: Leverage a system that shows the traceability links directly on the
plan, or that uses queries that identify gaps, such as “Plan items without requirements” and “Plan
items without test cases”, and “Defects blocking test.”
DON’T ignore, hide from or hope to pass regulatory audits
Invest in an ALM solution that makes traceability easy to do, maintain and report against.
DON’T work in disconnected project repositories, or cobble together a disparate set of tools.
Seek products built with open interfaces. Seek vendors who understand and support the ALM integration challenges. Invest in tools with a longer-term integration roadmap in mind.
DON’T enter links manually after the fact, it’s easy to forget, hard to enforce.
Integrated tools make it easy to establish as the project executes.
DON’T build your own integration based on proprietary API’s.
Choose a solution with open services (OSLC) for linking data across the lifecycle.
DON’T choose a one-size-fits-no-one solution.
Invest in a loosely coupled, integrated ALM solution that is built to scale and supports open and flexible integrations. A single ALM repository will not scale to fit your needs over time. Times change, new products emerge; your ALM solution needs to be flexible enough to move with the times.
After all, do you really want to face that data migration challenge?