Google
 

Friday, March 28, 2008

Rework effort in SELC

Rework is an ongoing problem in software development. As per SEI (Software Engineering Institute) report it has been indicated that 60-80% of the cost of software development is rework effort. This effort is used to correct defects associated with base-lined work-products. Unfortunately, the reason is a gap between the state of the art and the state of the practice of software engineering.

In SELC (Software Engineering Life Cycle) all out put is treated as work-product. E.g. Project Plan Document, Requirement Specification Document, Source Code, Test Specification, Test Report, Release Note etc. And when a work-product is approved or validated by the relevant stakeholders for using next level users than it called base-lining.

Common causes of re-works in SELC:

  1. Requirement Analysis Gap (main root case of rework)
  2. Wrong Software design (e.g. performance issue not considered in the design)
  3. Poor Code development (e.g. features not developed as is software design)
  4. Inadequate Test Case development (e.g. insufficient test cases for each requirement)

Despite successes in reducing rework, it is generally accepted that rework cannot be eliminated entirely. However, rework effort can be reduced by taking process improvement. For example:

  • Introduce or improve the formal review process in requirement, design and coding phases. [If formal review is implemented then defect will be identified from the earlier stage of SELC, it will reduce rework significantly.]
  • Integrate test cases with requirements [if each test case is mapped with requirements then it will be easier to measure that sufficient test cases is developed/not to test that requirement]
  • Conduct Inspection [periodical inspection on work-products and processes implementation helps to identify defects as well as increase the consciousness of project team members to develop quality work-products and follow the processes]

Therefore, to reduce the rework effort it is required the use of disciplined engineering practices by skilled software engineers.

Thursday, March 27, 2008

CSQA Examination Overview

The four and a half hour examination consists of four written parts, including multiple-choice and essay questions. A typical CSQA examination is comprised of two parts for Quality Assurance Theory and two parts for Quality Assurance Practice:

Quality Assurance Theory
Part 1 Approximately 50 multiple-choice questions Complete within 45 minutes
Part 2 Approximately 10 essay questions Complete within 1 hour, 15 minutes

Quality assurance theory evaluates your understanding of quality principles, practices, vocabulary and concepts. In other words, do you have a solid foundation in quality basics? For example, can you differentiate between quality assurance and quality control?

Quality Assurance Practice
Part 3 Approximately 50 multiple-choice questions Complete within 45 minutes
Part 4 Approximately 10 essay questions Complete within 1 hour, 15 minutes

Quality assurance practice evaluates whether you can apply quality basics to real-world situations. For example, a question may be: “What methods of quality control would you use to reduce defects for a software system under development? During which phase of development would you use those methods?”


This certification requires candidates to demonstrate skills in the following Categories:

  1. Quality Principles and Concepts

  2. Quality Leadership

  3. Quality Baselines (Assessments and Models

  4. Quality Assurance

  5. Quality Planning

  6. Define, Build, Implement and Improve Work Processes

  7. Quality Control Practices

  8. Metrics and Measurement

  9. Internal Control and Security

  10. Outsourcing, COTS and Contracting Quality

For a detailed explanation of each category, please click here