CM Crossroads sobre trazabilidad

La última actualización de noticias de CM Crossroads agrupa varios artículos sobre Trazabilidad publicados durante Agosto. Este concepto impacta en la calidad y confiabilidad con que se manejen los procesos de construcción de software. No está de más dedicarles un tiempo. Los artículos son:
Traceability and Auditability: Definiciones, especialmente sobre auditorías.
Traceability and Auditability: Satisfying your Customers: Más detallado sobre trazabilidad

One of the most common queries in our shop is: What went into a build? This may seem like an innocent question, or to some who know better, it may seem like a terribly complex question.

When we ask what went into a build, we ask the questions:

• What problems were fixed?
• What problems are outstanding?
• What features have been added?
• What requirements have been met?
• Which updates (i.e change packages) went into the build?
• Which files were changed?
• How have run-time data configuration files changed?

Why is this so common a query in our shop? Well first of all our ALM toolset makes it easy to do. But secondly, when something goes wrong, we want to isolate the cause as quickly as possibly. If a new delivery to a customer introduces a problem they didn't previously have, we ask: What changes went into this build as compared to the customer's previous release build? We then screen these based on the problem and more times than not isolate the cause quickly. Even more frequently, if the system integration team, or verification team, finds a problem with an internal build, we go through the same process and isolate the cause quickly. By having a sufficiently agile development environment that packages a couple of dozen or so updates into each successive build, we're able to pinpoint new problems and hopefully turn them around in a few minutes to a few hours. Finally, we need to produce release notes for our customers. This type of query is the raw data needed by the technical writer to produce release notes. It's also the raw data needed by our sales team to let prospects know what's in the new release, or what's coming down the pipe.

Traceability & Auditability: Do you really know what went into production?: La relación de la trazabilidad con la puesta en producción del software:

Change management has two main objectives. The first is to provide support for the processing of changes, typically initiated via the service desk. Such processing includes change identification, analysis, prioritizing, planning for their implementation, decisions for their rejection or postponement, and decisions for their integration in new product releases. The second objective is traceability (i.e., to make it possible to list all active and implemented changes). It should also be possible to track the modifications of different items due to a specific change. (e.g. Part of the ITIL Knowledge database.)

By extending the Service Desk into ALM, traceability will not only include configuration items (CIs) in production, but will also provide the capability to link to all application development artifacts to be able to perform end-to-end impact analysis, including the scope of the resolution of the problem under analysis.

Audit Trails, Traceability - Because Sometimes Things Go Wrong: La trazabilidad en el seguimiento de problemas

Any time we make a change to production, there is the risk that something will go wrong. Risk is a fact. The only way to eliminate risk is to never do anything. (But of course, that is not an option.) So we are left with actions we can take to mitigate those risks. Configuration Management (CM) is mainly about risk mitigation. Everything we do in CM is designed to reduce the likelihood that things will go wrong, or to reduce the adverse impact when they do go wrong. CM helps us to avoid many failures, and to recover quickly from those few that we can't avoid. But how do audit trails and traceability fit into this picture? Traceability doesn't prevent errors, and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools?
On the contrary, audit trails and traceability are two of our most important CM tools for learning how to mitigate risk.
Answering 6 Questions
Both auditing and traceability are mechanisms that are designed to answer the six questions: who, what, when, where, why, and how. For example:

• Who made the change? Who authorized it? Who knew about it?
• What exactly was changed? And what was not changed?
• When was the change made (especially relative to other activities)?
• Where was the change made (e.g. what platform, repository, location)?
• Why was the change made? What triggered the change or motivated the person?
• How was the change made? What precisely was done and not done? How was information about the change captured and communicated?
  

Y especialmente: The Trouble with Tracing: Traceability Dissected: Una buena descripción de su valor y aspectos negativos

Eight Reasons for Traceability

If traceability is so much work, and if the return-on-investment is so hard for so many to see, then why do we bother? Or rather, why should we bother? Other than obvious contractual obligation, legal liability, or the fact that various CM and software engineering tomes declare “thou shalt have traceability,” what real needs does it serve? What does it let me do that I couldn’t otherwise do very easily? Several reasons commonly given are:

1. Validate we built what the customer actually agreed to pay us to build, that we built the “right thing” and that we “did things right” when building it
2. Verify that we delivered every file and feature/fix that we said we would, and nothing that we said we wouldn’t
3. Identify and isolate a set of changes that were made, and be able to either back-out the change from an existing version, and/or reintroduce the change to other versions
4. Assess the impact upon the design, code, tests and other aspects of the system for a proposed change-request (this in turn helps us determine effort, risk, cost, and the other affected groups)
5. Maintain an audit trail about who did what, when, where, why and how - so we can prove what we should and shouldn’t be held accountable for when the customer, or management or some other formal authority demands to know, or claims that we didn’t something we shouldn’t have, or for invalid reasons
6. Capture everything necessary to identify exactly what was delivered and repeat the steps necessary to reproduce it again
7. Report status of our activities to the customer and to management for the features and fixes that we are currently working on, so they can evaluate the progress and risks in delivering the project
8. Retrace our steps regarding something we did poorly, or that we simply didn’t know to pay attention to before, so we can identify root causes and learn how to prevent and/or correct it in the future

Those are all some pretty good reasons. Does that really justify why some of us have to maintain a traceability matrix? Is that really the most effective way?

Even agile development is in favor of tracing tests to features, which is extremely straightforward when one is doing test-driven development (TDD). When it comes to tracing requirements through to design and code, images of manually maintained traceability matrices that are hopelessly effort-intensive and never quite up-to-date seem to spring to mind.