Traceability

1
Traceability

• Why Do You Need It?

2
Traceability

• The software requirements, design, code, and test
  cases are traced to the source from which they
  were derived and to the products of the
  subsequent software engineering activities
• from SEI-93-TR-25,
• "Key Practices of the Capability Maturity Model,
  Version 1.1" SPE Sub AC10.2

3
Background Issues

• Rework is costly
• Maintenance projects are costly
• Changes to software projects can be costly

4
Background - rework

• The cost of rework on large scale projects has
  typically consumed 40 to 50 percent of the total
  software development budget.
• 
  B. Boehm, IEEE Tutorial on
  Software Risk Management, IEEE CS Press, Los
  Alamitos, Calif., 1989.

5
Background - Y2K Maintenance

• Y2K costs will cost approximately 600 billion
  according to Gartner Group of Stamford CT
• contract repair service costs appear to be rising
  at 20-50 per year as we approach 2000
• estimated cost of correcting and testing each
  line of code (LOC) is approximately .50 -1.1O,
  plus added costs for management and other
  expenses.
• Most sources agree that 50 or more of the cost
  will be borne in the testing stage after
  renovation.
• Dr. Edward J. Deak, Prepared Testimony - Field
  HearingThe Implications of the Year 2000
  Computer Problem
• February 17, 1998

6
Background - Fundamental Principles of Change

• The very act of creating software causes
  discovery that will impact the process itself in
  other words, change is practically inevitable
• Customers want to modify requirements
• Developers want to modify the technical approach
• Management wants to modify the project approach
• Changes in software engineering projects rarely
  happen in a vacuum there are impacts

7
Background - Change has Management Impacts

• Product Impact
• Direct
• Ripple effects
• Performance effects
• Plan Impact
• Size
• Effort
• Schedule
• Cost

8
Background - Change has technical impacts

• Implementing changes can be frustrating and
  costly when software developers are unsure which
  other requirements, design, code and test
  products may be affected

9
Traceability

• These issues are partly a result of missing or
  poor traceability
• The following slides address these issues from
  the point of view of missing traceability
  practices...

10
Consequences of No Traceability - 1

• Acceptance Testing Compromised
• It is difficult to demonstrate that the product
  is ready for a rapid and easy acceptance test
• Product goes into acceptance too early and
  remains in acceptance too long

11
Consequences of No Traceability - 2

• Project Management Compromised
• When re-planning, the project leader cannot be
  sure which requirements have already been
  partially or completely developed and which can
  still be removed without extra work
• Descoping of the project can generate more work
  through the removal of previous work

12
Consequences of No Traceability - 3

• Product Compromised
• Development is not performed in order of
  criticality (either importance to the customer or
  technical complexity)
• Nice-to-have features are developed and
  implemented more fully than key features
• Software developers may spend a large amount of
  time creating a wonderful system that does not
  correspond to any requirements
• Cost overrun
• Schedule slippage

13
Consequences of No Traceability - 4

• Maintenance Difficult
• tracing tests, code, and design to originating
  requirements laborious
• impact of changes on related work products and
  requirements difficult
• testing overly complex

14
What Traceability Is
15
Requirements Traceability

• Method for tracing each requirement from its
  point of origin, through each development phase
  and work product, to the delivered product
• Can indicate through identifiers where the
  requirement is originated, specified, created,
  tested, and delivered
• Will indicate for each work product the
  requirement(s) this work product satisfies
• Facilitates communications, helping customer
  relationship management and commitment negotiation

16
Purpose

• Demonstrate to the customer that the requested
  contents have been developed
• Ensure that all requirements are correct and
  included in the test plan and the test cases
• Ensure that developers are not creating features
  that no one has requested

17
Traceability

• Traceability techniques can
• reduce rework by helping ensure all work is
  against current requirements, and that
  requirements are complete
• simplify maintenance by mapping changes to other,
  potentially impacted parts of a system
• facilitate impact analysis on changes to a
  project already in progress

18
Key Areas Supported by Traceability Capability

• Requirements Management
• Requirements-based activity assurance
• Change review and management
• Configuration Management
• Pre-Baselining Reviews
• Configuration Change Control
• Configuration Audits

19
Traceability Facilitates Other Practices
Concepts

• Verification and Validation
• Verification - doing the job right
• Validation - doing the right job
• May involve peer reviews, baseline audits, tests
• Criticality Analysis
• Resource Management - the limited time and
  personnel is focused on the most important areas
  in development and VV activities
• Quality Planning

20
Traceability Requirements Management
21
Distribution of Defects in the Engineering Life
Cycle
Source IBM/TRW/Mitre
22
What We Know About Requirements

• They will change
• They will change at any stage of the life cycle
• However
• The change needs to be controlled and managed
• Accepted and approved changes must be reflected
  in all product artifacts
• Accepted changes need to be re-baselined

23
Requirements Management Principles

• The requirements must be documented, accurate,
  current, controlled, and accessible
• The impact of changes must be assessed
• Responsibility to keep the requirements current
  must be assigned

24
Requirements Management Principles - 2

• All affected work products must be updated and
  kept consistent with the requirements and their
  changes
• Plans
• Requirements documents
• Design documents
• Code
• Test cases
• Test scripts
• Changes must be traced to final product

25
Requirements Management Principles - 3

• Changes that will impact commitments to clients
  and other external parties must be negotiated
• Changes impacting commitments within the
  organization must be negotiated, as well

26
Traceabilitys Impact

• Changes to requirements can be tracked through
  the work products to ensure they have been
  implemented correctly
• Allows every requirement change to be uniquely
  identified
• Will indicate through identifiers where the
  requirement is originated, specified, created,
  tested, and delivered
• Will indicate for each work product the reason
  for the change via comments
• Facilitates impact analysis and commitment
  negotiation

27
Requirements Traceability Configuration
Management
28
The Need for Configuration Management (CM)

• The most frustrating software problems are often
  caused by poor configuration management
• The latest version of source code cannot be found
• A difficult bug that was fixed at great expense
  suddenly reappears
• A developed and tested feature is mysteriously
  missing
• A fully tested program suddenly does not work
• The wrong version of the code was tested

29
Without Change Control

• Without change control, a software engineer could
  make an important change to a configuration item
  or its interfaces without a lot of extra work and
  red tape
• But no record would be kept for
• What the change was and why the change was
  requested
• Who wanted the change made
• Who approved the change
• Who made the change
• Who verified the change

30
Change Principles (revisited)

• As time passes all parties know more
• about what they need
• which approach would be best
• how to get it done and still make money
• The additional knowledge becomes the driving
  force behind most changes
• Many (if not most) change requests are justified!

31
Baselines

• The fundamental success of any development effort
  is dependent on well-defined reference points
  against which to specify requirements, formulate
  a design, and specify changes to these
  requirements and the resultant designs.
• The term baseline is normally used to denote such
  a reference point

32
Baselines - 2

• A baseline is an approved snapshot of the system
  at a given point in its evolution
• The items in the baseline form the basis for the
  work in the next phase of the software
  development cycle
• The items of the next baseline are measured and
  verified against previous baselines before they
  become baselines themselves

33
Changes to Baselines

• All changes made to the baselined software
  configuration items should be done according to a
  documented change control processes
• The change control processes should include
• Change Impact analysis to be performed using the
  traceability matrix to first isolate the overall
  effect of the requested change on the products
  components
• The procedure that will be followed to update all
  affected software life-cycle components to
  reflect the approved changes
• Update of the traceability matrix to reflect the
  revised baseline documents/components
  relationship

34
Traceability Implementation
35
Requirements Traceability Matrix

• Implemented using a word processor, spreadsheet,
  database or special tool
• For each requirement the work products or
  software work products created throughout the
  life cycle should be identified

36
What Should Be in the Matrix

• requirements
• architectural design
• detailed design
• source code/objects
• test plans/cases
• Project plans and documentation are important,
  but usually should reference the matrix and not
  be entries within it

37
Requirements Traceability Matrix Example
38
Roles and Responsibilities

• Project manager
• Ensures all required information is provided as
  needed
• Review the traceability matrix for completeness
• Requirements responsible role
• Update requirements traceability matrix as
  needed, support analysis as needed
• Test manager
• Provide mapping of requirements to test products
• Designer
• Provide mapping of requirements to design
  products

39
Roles and Responsibilities - 2

• Developer
• Provide mapping of requirements to development
  products
• Software Configuration Managment staff
• Provide baselined inputs to the matrix
• Baseline outputs and put notes in project archive
• QA staff
• Periodically participate in/audit Requirements
  Management and Configuration Management
  activities
• Generate Quality Audit Report if needed

40
A Sample Procedure

• Entry Criteria
• Creation of or changes to requirements, design,
  code or test products
• A numbering/naming convention has been defined
• An experienced, trained individual is designated
  as the responsible for tracing the requirements
• A team of trained personnel is designated to
  support this activity and sufficient resources
  are allocated

41
A Sample Procedure - 2

• Inputs
• Requirements Traceability Matrix (if it exists)
• Appropriate phase work products
• Approved change request

42
A Sample Procedure - 3

• Steps
• Initial Requirements
• 1. Determine traceability strategy and initiate
  matrix
• Change
• 1. Use matrix to help determine related
  requirements, design, code, tests, etc.
• 2. Perform impact analysis
• Update matrix with available information/new
  products created as a result of changes
• Review matrix

43
A Sample Procedure - 4

• Outputs
• New or updated Requirements Traceability Matrix
• Metrics
• None

44
A Sample Procedure - 5

• Exit criteria
• Products have been reviewed by team members (or
  qualified representatives)
• Products are baselined by the Configuration
  Control Board
• Products have passed Software Quality Assurance
  review
• Products (including the results of any SQA
  reviews/audits) have been reviewed by the
  software manager

45
Traceability Summary

• Change is practically inevitably on software
  projects
• Changes have impacts
• Those impacts must be analyzed
• Traceability makes it possible to evaluate
  changes to a system as it is being developed, and
  after it is deployed.