Defect Analysis

The following are the Suggested Defect Analysis:

(1) Root Cause Analysis: Each defect shall be tagged with the root cause of the same. The root cause refers to the action which injected the anomaly into the system. The analysis shall be performed by collating such entered root causes against the defects. The output of this analysis shall be corrective actions or the corrective action plan that would prevent Defects arising out of such entered root causes, in the future.

(2) Defect Migration or Defect Propagation Analysis: Each defect shall be tagged with the the following data -

(i) Project Phase in which the Defect is injected

(ii) Project Phase in which the Defect is uncovered

The analysis shall be performed by collating such entered data against the defects. This analysis shall provide

(i) Number of defects injected Vs project phases

(ii) Number of defects uncovered Vs project phases

The output of the analysis shall be the corrective actions or the corrective action plan that would improvise the processes across project phases. Such an output shall be derived by analysing the root cause behind the collated data.

(3) Arrival-Closure Trend Analysis: This trend shows the actual number of defects open to actual number of defects closed at any point of time. The defect handling process that is being followed is capable of having Defect Fixing Rate greater than the Defect Identification Rate, if the arrival-closure lines would coincide sometime in the present/future and vice versa.

The output of the analysis shall be the corrective actions or the corrective action plan that would improvise the processes to have Defect Fixing Rate greater than the Defect Identification Rate. Such an output shall be derived by analysing the root cause behind the collated data.

(4) Defect Aging Analysis: Average Defect Age shall be calculated by taking into consideration of the Defect Age of each defect. 

The output of the analysis shall be the corrective actions or the corrective action plan that would improvise the processes to reduce the Average Defect Age. Such an output shall be derived by analysing the root cause behind the collated data.

V-Model

Introduction:
The V Model is probably the best known testing model it highlights the existence of several levels of testing and depicts the way each relates to a different development phase

Acceptance Testing:

Users perform UAT to confirm that the system does, in fact, meet their business requirements

System Testing:

It demonstrates that the system works end-to-end in a production-like environment to provide the business functions specified in the high-level design

Integration Testing:

It demonstrates that two or more units or other integrations work together properly, and tends to focus on the interfaces specified in low-level design. When all the units and their various integrations have been tested

Unit Testing:

It is code-based and performed primarily by developers to demonstrate that their smallest pieces of executable code function suitably

Bidirectional requirements traceability matrix

Requirement Traceability - Bidirectional traceability, What is Horizontal traceability; What is vertical traceability; Why is this required?..........


Following is the 'text' as is, on the terms 'Horizontal traceability' & 'Vertical traceability'from different sources.

(1) Source: http://www.sei.cmu.edu/cmmi/faq/new-faq.html

In the Requirements Management (REQM) process area, specific practice1.4 states, "Maintain bidirectional traceability among the requirements and the project plans and work products."

Bidirectional traceability primarily applies to vertical traceability and at a minimum needs to be implemented both forward and backward (i.e., from requirements to end products and from end product back to requirements).

Vertical traceability identifies the origin of items (e.g., customerneeds) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer.
When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.

Horizontal traceability is also important and is mentioned in subpractice 3, but it is not required to satisfy bidirectional traceability.
Horizontal traceability identifies the relationships among related items across work groups or product components for the purpose of avoiding potential conflicts.
It enables the project to anticipate potential problems (and mitigate or solve them) before integration testing. For example, horizontal traceability would follow related requirements across two work groups working on two associated components of a product.
The traceability across these two work groups enables the work groups to see when and how a change in a requirement for one of the components may affect the other component.Thus, horizontal traceability enables the project to anticipate potential problems (and mitigate or solve them) before integration testing.

--------------------------

(2) Source:Author: Tim KasseTitle: Practical Insight into CMMIPg 153-154

Vertical traceability: Traceability `from requirements through the associated life-cycle work products of architecture specifications, detailed designs, Code, unit test plans, integration test plans, system test plans, so forth and back"Horizontal traceability: refers to the traceability from the requirements to the associated plans such as the project plan, quality assurance plan, configuration management plan, risk management plan, and so forth

--------------------------------


(3) Source:Author: Shari Lawrence PfleegerTitle: Software Engineering - Theory & practicePages: 439-441

Vertical traceability expresses the relationship among parts of the workproduct. For example, vertical traceability of the requirements describes the interdependencies among the system requirements.

Horizontal traceability addresses the relationship of the components across collections of workproducts. For instance, each design component is traced code components that implements that part of the design