The Journey Through Traceability to Process Control

[article]

 

 

Summary:
Taking a team from an undisciplined product development strategy, through an organized process with visible tracks, to a mostly automated, self-improving process is a long journey. It requires a good understanding of change, an adequate SCM tool or tool suite, good people for sure, and a lot of common sense. The journey is well worth the effort, though. I've been down the road more than once. It leads you to the path where you can manage properly and let the configuration management be handled automatically.

Traceability
Traceability is a cornerstone of change management. It tells you why things have changed. It lets you identify the level of verification for particular changes. It links the Requirements and Requests of customers and product managers down through code, test cases and test run data.

Granularity
Here's an example of a fully traced system development.

  • Requirement R1: Build a CM system
  • Request Q1: Make it easier to use
  • Request Q2: It's not working, we need it to work
  • Activity A1: Implement R1
  • Activity A2: Implement Q1
  • Problem P1: It doesn't work spawned from Q2
  • Problem P2: Testing failed - see R1
  • Change C1: Implement A1 part 1
  • Change C2: Implement A1 part 2
  • Create Build B1 using C1 and C2
  • Change C3: Implement A2 and fix P1 and P2
  • Create Build B2 using B1 and C3
  • Testcase T1: Test the system to ensure it meets R1
  • Testrun TR1: System failed T1 testing run on B1 - Created P2
  • Testrun TR2: System passed T1 testing run on B2

It doesn't really matter which system you're developing, you can probably shoe-horn your system into this template. The problem is, although I have full traceability, the granularity of my traceability makes the data all but useless. Granularity will certainly dictate how useful the data is.

Although the above example gives little traceability information, it does cover a lot of bases. It identifies the fact that requirements (Rs) and requests (Qs) are needed for development to proceed. It shows that the Rs and Qs spawn design activities (As) and problem reports (Ps). It shows that Changes (Cs) address the As and Ps. It shows that builds (Bs) are created with certain Cs. It shows that test cases (Ts) address Rs. It shows that test runs (TRs) run Ts using Bs and spawn Ps where necessary.

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!