Traceability and Auditability: Satisfying your Customers

[article]
Summary:
When we deliver software products, we need to be able to tell our customers what they're getting. Not only product documentation, but specifically, every time we deliver a new release we need to relay what problems were fixed and what new features were added. If the software is subject to periodic audits, we need to tell them even more, especially the abiltiy to trace a requirement or change request to what was changed.

When we deliver software products, we need to be able to tell our customers what they're getting.  Not just product documentation, but specifically, every time we deliver a new release, what problems were fixed, and also what the new features are. If the software is subject to periodic audits, we need to tell them even more, especially the ability to trace a requirement or change request to what was changed. 

We do that very well.  We point to the build that the customer currently has and to the build that we're planning on shipping to the customer.  We then ask for a list of problems fixed, a list of the new features, and any documentation available for the new features.  In a few seconds we have our answer in a simple release notes document ready for the technical writer to spruce up.

This is good and useful.  For many shops this might be a leap forward, but in the context of an ALM solution, it doesn't go far enough.

If my world is limited to taking a list of problems and features and fixing/implementing them and delivering builds with those implementations, the above release notes are helpful.  However if, instead, my world deals with taking a requirements specification, which is changing over time, and then ensuring that a conforming product can be demonstrated to the customer, my world is a bit bigger.  If those requirements also include a budget and delivery schedule, it's all the bigger.  Then if I happen to have one of those management structures that want to know the status of development, including, whether or not we'll meet our requirements within budget and on time, it's bigger still.  If I have to track what customers have which problems and feature requests outstanding with each delivery, it's even bigger.

Many customers ask for much more than release notes. They want to know about their outstanding requests.  They want to know about the quality level of the software we're shipping them.  They want to know about the risks involved.  They want to review the product specs before development is complete so that they may have additional input on the functionality.  They want to know if our delivery schedule will be on time.  We need a virtual maze of data to track the information involved in the ALM process (see diagram) and to support the audit process.

jfaug07-1jpg

Pages

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01