Thursday, June 30, 2005

COQ Curve-Optimal Situation

In my previous post (COQ-The Quality Iceberg), COQ curves in Total Quality View created doubts to few as the X-axis was looking as if it is labelled "Defects" there. In factthe axis is the Degree of perfection achieved towards the individual curves like Appraisal, Prevention etc. The label "Defects" there is showing that as the Degree of perfection is increasing the Defects are reaching 0%. In few instances, this axis is also taken with increasing Quality of Design.

The minimum total cost,for example is shown below as being achieved at 98% perfection. This percentage is also known as best practice. That is, the cost of achieving an improvement outweighs the benefits of that improvement. This optimized percentage may vary depending on the Organisation processes.

IT Chaos - LoL!!

Well, this link is not working now. But let me to explain this cartoon in brief here.

This cartoon from dilbert was showing a developer asking the Process consultant "What documented procedure did you follow to come up with this new document for us?"
One of my peers (Sanjay) has recently sent me this one and I could not stop myself from laughing at it! These are common in any QA Professionals day at work. A QA Professional's life is not so easy :(

Thanks Sanjay for giving me a lighter moment.

Monday, June 27, 2005

Cost of Quality - The Quality Iceberg

Just came across this S/W Quality Icerberg - showing the importance of internal Quality maintenance which is invisible to the external agent. Looking at this iceberg, the amount by which the Orgnanisation spends towards reducing the Cost of Poor Quality should idealy be more compared to the cost incurred in meeting the external defects identified.

Read more on this Quality Icerberg here:

The Total Quality View is given in the figure below. Realize from the figure that as the emphasis on Prevention & Appraisal Cost is increasing, the failure cost is reducing at a linear slope. Also see the slope of the Prevention & Appraisal Cost is less than that of the Cost of Failure which clearly indicates the cost reduction because of the difference in slope gives you the net profit. Also shown below is the ideal divisions among the different Costs of Quality.

Interested ones can go to this to find out why more organisations cannot use it effectively.

CSQA blog

I've started another blog to put whatever information I can on CSQA.
My vision is that all the CSQA aspirants should find this a one time resource for whatever on CSQA (Certified Software Quality Analyst). CSQA aspirants, enjoy the bliss!!

Wednesday, June 15, 2005

IEEE's SW Engg Body of Knowledge

It's nice to see that the importance of QA and Process Management has been on a rise since a while. The latest incidence which I came across is the SWEBOK-Software Engineering Body of Knowledge, A project of the IEEE Computer Society Professional Practices Committee. Earlier the areas of Software Development used to be only the phases which were derived from the typical Software Development Life Cycle, which used to be the 5 Ds i.e., Discover, Design, Develop, Deploy & Deliver or a similar model.

The list of SWEBOK Knowledge Areas (KAs) which were mentioned by the SWEBOK are mentioned below which emphasises on the importance of all aspects of Quality Assurance which is clearly visible in defining the last 5 KAs after SW testing & Maintenance.

  1. Software requirements
  2. Software design
  3. Software construction
  4. Software testing
  5. Software maintenance
  6. Software configuration management
  7. Software engineering management
  8. Software engineering process
  9. Software engineering tools and methods
  10. Software quality

Look out for more reviews on SWEBOK here.
I am expecting more comments from those who have reviewed/reviewing this BOK.
You can download this BOK from

Tuesday, June 14, 2005

Find the FAQs on QA

I found myself drowning in this world of Software Engineering, when QA showed me some answers. The more I am trying to explore, the more deeper I am getting into. But that is where we find the treasures of knowledge.

Here after, I would like to share the FAQs that I wanted to be readily available. Just to make everyone clear, these FAQs are related completely to Quality Assurance i.e., Process Engineering and is not related to the Quality Control at all. Since I am working with CMMI, many FAQs may be related to CMMI.

I dont want to repeat the FAQs which are already available @ SEI's FAQs :

In Organizational Process Performance (OPP), why are process performance baselines and process performance models important?
What is meant by SP 3.2, Perform Configuration Audits, in the Configuration Management process area?
When does Validation (VAL) occur in a life cycle?
What is the difference between Verification and Validation?
What is bidirectional traceability?

Enjoy the bliss of knowledge!!

Bidirectional Traceability of Software Requirements

Requirement Traceability - Bidirectional traceability, What is Horizontal traceability; What is vertical traceability; Why is this required?.......... Similar questions are gallore for any QA Executive. See if this clarifies these doubts:

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

(1) Source:

In the Requirements Management (REQM) process area, specific practice
1.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., customer
needs) 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 Kasse
Title: Practical Insight into CMMI
Pg 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 Pfleeger
Title: Software Engineering - Theory & practice
Pages: 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