Saturday, June 30, 2007


Anyone who's taken a software engineering class from me, undergrad or grad, knows I like traceability:

Requirements traceability... provides critical support for software engineers as they develop and maintain software systems. Traceability helps determine that researchers have refined requirements into lower-level design components, built them into the executable system, and tested them effectively. It further helps analysts understand the implications of a proposed change and ensures that no extraneous code exists...

Furthermore, organizations building safety-critical systems are often legally required to demonstrate that all parts of the code trace back to valid requirements. Laws such as the US Sarbanes-Oxley Act of 2002 require organizations to implement change-management processes with explicit traceability coverage for any parts of a software product that potentially impact the balance sheet.

The above is from a paper in the June 2007 IEEE Computer magazine, "Best practices for automated traceability" by authors from DePaul University, Siemens Corporate Research, and iRise. The paper gets heavily into probability after the first couple of pages, so I wouldn't make undergrads read it, but skimming the paper gives an idea of what folks are doing to find and maintain those threads of traceability I'm so fond of.

Here are the links:
  • directly to article in the IEEE online library (unless you have a subscription, you'll only get the abstract and reference information)
  • a direct link to the article for Fresno State students, staff, and faculty.
  • a direct link to the June 2007 issue for University of Hawaii students, staff, and faculty (you'll have to scroll down to the article).