The 'W' SDLC Model

The Test activities first start after the implementation. The connection between various test stages and the basis for the test is not clear.

The tight link between Test, Debug and Change tasks during the test phase is not clear.

W-model—further clarifies the priority of the tasks and the dependence between the development and testing activities. Though as simple as the V-model, the W-model makes the importance of testing and the ordering of the individual testing activities clear. It also clarifies that testing and debugging are not the same thing.

They usually appears an unattractive task to be carried out after coding. In order to place testing on an equal footing, a second 'V' dedicated to testing is integrated into the model. Both 'V's put together give the 'W' of the 'W-Model'

Defect Management Process......

Software defects are expensive. Moreover,cost of finding and correcting defects represents one of the most expensive software development activities.While defects may be inevitable, we can minimize their number and impact on our projects. To do this development teams need to implement a defect management process that focuses on preventing defects, catching defects as early in the process as possible, and minimizing the impact of defects.

With the help of this defect management model, we can reduce the defect and their Impact.

The defect management process is based on the following general principles:

The primary goal is to prevent defects as quickly as possible and minimize the impact of the defect.

The defect management process should be risk driven -- i.e., strategies, priorities, and resources should be based on the extent to which risk can be reduced.








This model contains two main sections. The first one, Defect Management Process, lays out the Defect Management model and The second section, Implementing the process, gives tips on how to take the model and use it within your company.

The arrows on either side of these links, are another way to navigate around. Up arrows take you back to the parent of the page you are on. Down arrows allow you to delve into greater detail about a topic. For example, the down arrow below takes you to the Defect Management Process. Left and right arrows allow you to move to the next or previous logical page.


Defect Prevention -- Implementation of techniques, methodology and standard processes to reduce the risk of defects.

Deliverable Baseline -- Deliverables will be considered complete and ready for further development work. When a deliverable is baseline, any further changes are controlled. Errors in a deliverable are not considered defects until after the deliverable is baseline.

Defect Discovery -- Identify and report of defects for development team. A defect is only termed discovered when it has been documented as a valid defect by the development team member(s) responsible for the component(s) in error.

Defect Resolution -- Development team member responsibility to fix a defect,This also includes notification back to the tester to ensure that the resolution is verified.

Process Improvement -- Identification and analysis of the process in which a defect originated to identify ways to improve the process to prevent future occurrences of similar defects. Also the validation process that should have identified the defect earlier is analyzed to determine ways to strengthen that process.

Management Reporting -- Analysis and reporting of defect information to assist management with risk management, process improvement and project management.

Difference Between Quality Assurance, Quality Control, And Testing.

Most of the people and organizations are confused about the difference between quality assurance (Q.A.), quality control (Q.C.), and Testing. They are closely related, but they are different concepts. Since all three are necessary to effectively manage the risks of developing and maintaining software.They are defined below:

* Quality Assurance: A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.
* QA is Prevent the issue and correct it.
* QA is the responsibility of entire team.

* Quality Control: A set of activities designed to evaluate a developed work product.
* QC is detect the issue and resolve it.
*QC is the responsibility of team member.
* Testing: The process of executing a system with the intent of finding defects. (Note that the "process of executing a system" includes test planning prior to the execution of the test cases.)

QA activities ensure that the process is defined and appropriate. Methodology and standards development are examples of QA activities. A QA review would focus on the process elements of a project - e.g., are requirements being defined at the proper level of detail. In contrast,

QC activities focus on finding defects in specific deliverables - e.g., are the defined requirements the right requirements. Testing is one example of a QC activity, but there are others such as inspections.

Controversy can arise around who should be responsible for QA and QC activities -- i.e., whether a group external to the project management structure should have responsibility for either QA or QC. The correct answer will vary depending on the situation,
Both QA and QC activities are generally required for successful software development.

* While line management should have the primary responsibility for implementing the appropriate QA, QC and testing activities on a project, an external QA function can provide valuable expertise and perspective.