QualityMentors Blog

This blog is a membership based discussion forum on Project Management, Software Quality, CMMI® for development, ISMS and associated subjects. It provides a common platform for our training participants and others to share views and obtain expert opinion on issues related to above subjects. Also, it is used by QualityMentors training participants to upload their personal details in a secured manner in line to the guidelines laid down in ISO/IEC 17024:2003. This blog draws its strength from its members who are welcome to share professional and personal experiences, comments, articles and reference links to make it a preferred knowledge repository for their collective use. It encourages fact based decision making as an success enabler for projects in member organizations.

Monthly Archives: April 2011

Clarification on Configuration Management

This is the response to AKM Desai’s posting of March 31.

Since you say that this old project is nearing its completion, I presume that it must be having some level of control on its work products, and that practice has allowed it to reach its final stages. All the intermediate deliverables, software code, executable files and so on must have evolved in some manner and the project team must be having a system to establish and maintain its work in a defined, and planned fashion. If that is true, CM is being applied to this project. Generally speaking, project management should decide which work products should be subjected to CM and the extent of control on them.

Having said that, there may be a good reason for the project to use a suitable CM Tool for maintaining the integrity of its work products by using a CM Tool. The selected tool will mitigate the increasing risk of project loosing its work products in its final phase and increase the success rate by providing only the desired versions of intermediate work products for final product build. However, if I were the management, I would have left the decision to the Project Manager.

In any case, just bringing in the CM Tool for satisfying the appraisal team is not recommended. CMMI or other quality frameworks don’t impose the use of a CM Tool. Project Management has to take a call. If the PM is satisfied and has good reasons for not using a tool, it should be acceptable to the appraisal team. Anything important enough to maintain its integrity must be subjected to CM practices.

People feel Agile is some rocket science which does not need processes. Totally false. A formal CM in agile environment is much more important to support frequent changes the agile project undergoes. So if the project in question is an agile project, a CM Tool should have been  necessary for it.

QA Team Size

Let me try to respond to Rohit’s posting of March 31 regarding available benchmarks on QA Team size in software industry.

Famous benchmarking expert Capers Jones, in his presentation ‘SOFTWARE QUALITY IN 2002: A SURVEY OF THE STATE OF THE ART’ indicated that software organizations on an average need more than 5% of total manpower in quality for ‘Active QA’, less than 3% for ‘Passive QA’ and less than 1% for ‘Token QA’. This data is based on a survey of 600 organizations (150 Fortune 500 ones) and 30 Government or military groups. For smaller organizations, the percentages will be same or slightly higher.

With added process orientation based on CMMI, availability of best practices and latest benchmarks from ISBSG, SPINs and SEIR and availability of automated tools for project management, metrics based SPI and knowledge management, certain organizations may be able to bring down these percentages in case they peruse real quality and don’t run after certifications.

3 to 5% of engineering team size in QA is a good benchmarks in 2011.

I feel,  software industry still has plenty of  improvement opportunities in metrics based SPI. If implemented correctly and linked to business benefits (not certifications), this percentage may further come down.

Members may contribute their comments on this issue.

%d bloggers like this: