CMMI Implementation - Few Queries

I got struck with the following questions during the implementation of CMMI in our current organization. I would like to get these questions clarified ASAP. If anyone have the answers or references for them, please give them as your comments here:

• How much time does it take for a medium sized organisation (of people varying from 100 to 500) to set up the initial set of processes & what are the steps followed? (e.g., studying of existing projects to make the processes apt for the projects)

• Under what SDLC model does many of the projects fall? I am referring to many of those projects where the requirements cannot be freezed at the project start or clients themselves are not sure of the exact functionalities (e.g., when they come up with a concept rather than with the complete set of functional requireemnts)

• Now a days managements of the organisations are in a great hurry that they want to be at CMMI Level-5 within 1 year after the process initiation (I'm again referring to the medium sized organisations). How feasible it is and what is the average time for these mid-sized orgaisations to achieve L-5 (assuming there is 100% commitment from all parties) ?

Role of QA Executives in building better Organization through Process Compliance Measurement

While searching for calculation of Process Compliance Index, I came across this very good article on Composite model for QA mainly directed for the small and medium sized organisations. Here, the role of QA executives in providing a clear vision to the development process was clearly emphasized. Go through this article - worth calling it a must go through for any QA professional.

According to my experience & what I have seen until now, not many organisations emphasize on Process Compliance as one of the key metrics. This paper gives why it is important and how it gives a clear vision at the right moment inorder to avoid pitfalls.

A Composite Model on for Software Quality Assurance by S. Balan

By the way, I could not get the right answer for the calculation of Process Compliane Index (not Process Capability Index - general term used in Six Sigma). If anyone knows or comes across it, please update me. Thanks.

Is it true that QA Professionals earn less?

One person whom I met in a recent training session asked me why I opted for QA myself being an Engineer. His reservations is about the low salaries that QA professionals earn compared to Software Developers (I cant call them as "Software Engineers" because this term is very generalized. This has been emphasized by Roger Pressman in his book Software Engineering).

Keeping apart others' arguments, I would like to say that it is not true. I have an experience of only one year after my Engineering, that too completely in Quality Assurance (a very rare incidence, according to many). Now I am getting offers with around 75% more than my current pay. The myth that QA Professionals more precisely, QA Engineers earn less may be because of the fact that they are confined to do more Audit or Inspection processes most of the time and hence, it is in a way, not giving new reaps to the management/employer.

Now a days, the role as well as the designation of QA Engineer is being changed to Process Engineer or Process Consultant. This is giving more scope for assuring quality with the optimized processes while making sure that the innovation of the project teams is not lost ! This started getting more respect to Quality Assurance than ever before. And ofcourse, with innovations in optimized process implementations, the ROI would surely be high for the employer and higher the remunerations for QA Professionals :)

Experienced folks can correct me if I am wrong!!

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 :(

http://dilbert.com/comics/dilbert/archive/images/dilbert2005071744002.gif

Thanks Sanjay for giving me a lighter moment.

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:
http://www.asq.org/pub/qualityprogress/past/0501/qp0501defeo.pdf

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.
http://www.asq.org/ed/conferences/aqc/public_proceedings/57_2003/19384.pdf

CSQA blog

I've started another blog CSQA.blogspot.com 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!!

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 http://www.swebok.org

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: http://www.sei.cmu.edu/cmmi/faq/new-faq.html

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

Courtesy: Y! Group - CMMI_PROCESS_IMPROVEMENT