Note: This is the essay from SPaMCAST 66 at http://www.spamcast.net – Comments are welcome!
Traceability is an important tool in software engineering and a core tenant of the CMMI. It is used as a tool for the management and control of requirements. Controlling and understanding the flow of requirements puts a project manager’s hand on the throttle of the project by allowing and controlling the flow of work through a project. However, it is both hard to accomplish and requires a focused application to derive value. When does the control generated represent the proper hand on the throttle or a lead foot on a break?
The implementation of traceability sets the stage for the struggle over processes mandated by management or the infamous “model”. Developers actively resist process when they perceive that the effort isn’t directly leading to functionality that can be delivered and therefore, not delivering value to their customers. In the end, traceability, like insurance, is best when the most obvious reasons (uncontrolled project changes and delivering functionality not related to requirements) for having to perform traceability are avoided.
Identifying both the projects and the audience that can benefit from traceability is paramount for implementing and sustaining the process. Questions that need to be asked and addressed include:
- Is the need for control for all types of projects the same?
- Is the value-to-effort ratio from tracing requirements the same for all projects?
- What should be evaluated when determining whether to scale the traceability process?
Scalability is a needed step to affect the maximum value from any methodology component, traceability included, regardless of whether the project is plan-driven or Agile. A process is needed to ensure that traceability occurs based on a balance between process, effort and complexity.
The concept of traceability acts a lightening rod for the perceived excesses of CMMI (and by extension all other model-based improvement methods). I will explore a possible approach for scaling traceability. My approach bridges the typical approach (leveraging matrices and requirement tools) with an approach that trades documentation for intimate user involvement. It uses a simple set of three criteria (complexity, user involvement and criticality) to determine where a project should focus its traceability effort on the continuum between documentation and involvement.
Traceability becomes a tool that can be leveraged to bridge the gaps caused by less than perfect involvement, a complex project and increased criticality. The model we will propose provides a means to apply traceability in a scaled manner so that it fits a projects need and is not perceived as a one size fits all approach.