There is no "typical" as it depends on the nature of the software project as well as the maturity level of the delivery organization. I do recall SEI publishing defect density data years ago as part of CMM/CMMI for companies operating at different levels but that would not take into account the context of different types of software projects.
Are you interested in the volume of defects and changes to be expected in software development? There is no one "typical" answer because it's highly dependent on the business domain, the type of product or service and the operating model.
Software tends to get modified over most of its lifecycle so the effort taken to get to "version 1" is frequently much, much less than the total effort expended on later increments of that software. Some software teams will do releases for every few days of development. As a very general rule, smaller and more frequent releases tend to reduce waste and improve product quality more quickly. Going for long periods without releasing changes will very likely generate more waste in the long run. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Hi Pravin.
There was a lot of research and data available in the 1990s, I have not followed up with recent work on that, if any.
Capers Jones and Steve McConnell published books on SW metrics including bugs per line of code (LOC) or function point (FP).
McConnell said industry average was 10-50 bugs in delivered SW per 1000 LOCs and also quoted specific techniques (cleanroom development), that brought it down to 0,1 bugs / 1000 LOC.
Any company can gather the data and create own statistics in their OPA, which will then reflect their types of projects, way of working and risk attitudes. Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Pravin,
In my 40 years in the IT industry, I have found most published ratios relate to “bugs.” However, your question was related to “Rework,” so I thought I would provide some definitions:
- Rework: Redoing a process or activity (e.g., a component of code) that was improperly implemented. It occurs most often when developers work from requirements that contain ambiguity.
- Refactoring: Restructring a body of code without changing its exposed behaviors. It occurs most often under iterative and incremental development methods when behavioral changes are requested, and there is little tolerance for “replication of code.”
- Bug: A flaw in code that causes an exception or invalid output.
So, the question of “Rework” primarily relates to the adequacy of knowledge that gets transferred to your development organization. Therefore, your development philosophy/approach and maturity (as Kiron mentioned) play the primary role in affecting this ratio.
...
1 reply by Pravin Kumar Shrivastava
Dec 20, 2021 11:47 PM
Pravin Kumar Shrivastava
...
Thanks for your reply.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
No rework. My recommendation is going to IEEE standards and CMU SEI papers to find everything related to maintenance of products (software in this case). The answer to your question is there. Is a matter of quality and maintenance discipline specifically. You do not need to reinvent the wheel because everything is there, mainly in IEEE standards on maintenance.
...
1 reply by Pravin Kumar Shrivastava
Dec 20, 2021 11:46 PM
Pravin Kumar Shrivastava
...
Thanks for your reply. Would you please share any links. Thanks
No rework. My recommendation is going to IEEE standards and CMU SEI papers to find everything related to maintenance of products (software in this case). The answer to your question is there. Is a matter of quality and maintenance discipline specifically. You do not need to reinvent the wheel because everything is there, mainly in IEEE standards on maintenance.
Thanks for your reply. Would you please share any links. Thanks Saving Changes...
In my 40 years in the IT industry, I have found most published ratios relate to “bugs.” However, your question was related to “Rework,” so I thought I would provide some definitions:
- Rework: Redoing a process or activity (e.g., a component of code) that was improperly implemented. It occurs most often when developers work from requirements that contain ambiguity.
- Refactoring: Restructring a body of code without changing its exposed behaviors. It occurs most often under iterative and incremental development methods when behavioral changes are requested, and there is little tolerance for “replication of code.”
- Bug: A flaw in code that causes an exception or invalid output.
So, the question of “Rework” primarily relates to the adequacy of knowledge that gets transferred to your development organization. Therefore, your development philosophy/approach and maturity (as Kiron mentioned) play the primary role in affecting this ratio.
