Traceability Matrix

	In industry, it's one of most simple, elegant and effective ways
of carrying out what is called 'configuration management'. OK, just a few
words about that too...

Configuration Management : 
There are various artifacts produced in a
software project. Mostly documents : project plan, req. specs., HLD, LLD,
code,
Unit Test Cases (UTC), Integration Test Cases (ITC), Regression Test cases
(RTC), and System Test Cases (STC), Maintenance Manual, User Manual, among
hordes of others. Many of these are among deliverables to the clients.

	JUST IMAGINE WHAT A LINE OF CODE CHANGED MAY MEAN TO ALL THE OTHER
ARTIFACTS!!!

	If things are honestly done, one small change in one of these
artifacts may make all the rest of them obsolete. And in industry you
aren't allowed to work with obsolete documents! A project is
well-configured if it has a complete, crisp account of location, version
and status of all the artifacts which are listed as products of the
project in the 'Project Plan'.

	Configuration Management appears as one of the KPAs in the level 2
of Capability Maturity Model (CMM). Hence any organisation aiming at CMM
Level 2 onwards (there are 5 levels) must be good at configuration
management (CM).

Traceability Matrix (TM):

	So here's where traceability matrix comes to our help. It makes
the job of CM a manageable job even though it seems impossible at the
first glance.

	The traceability matrix is structured in the following way :

Rows are comprised of items. Columns are comprised of Deliverables. Now
each deliverable (including the code) is developed as per the items of the
traceability matrix. Here's a simplified, incomplete example :

**************************************************************************
		SRS		HLD		LLD		Code	
	
O2 Meas.	Sec. 2.1	Sec. 3.2	Sec 3.3.2	fnO2Meas()
								file :
								Measure
								dir:
								Instru

	...	...	...	...	...	...	...	...	
	...	...	...	...	...	...	...	...	
	...	...	...	...	...	...	...	...	
	
*************************************************************************

	Now suppose at some advanced stage of development, there is a
change request, all you have to do is to find out the suitable item, and
investigate the 'Change Impact' on the corresponding items (i.e. items
in the same row of the TM) in the other deliverables. Simple!

	Well...not so simple! Things are cumbersome in the beginning, and
there's always a bit of overhead involved in keeping the TM updated.

	HOWEVER, IT PAYS OFF TO MAINTAIN A TRACEABILITY MATRIX AT ANY
SCALE. EVEN FOR TERM PROJECTS.

	Do try out a somewhat simplified version of the above concept
while you are doing the term project of SA. It'll make the life simpler
during the high pressure end sem days. And it will also be instructive!