Predicting problems in a project

This is for many people, and I'm sorry to say so, including the senior management and many so called project managers, a wet dream.
  1. To know ahead what is going to happen in your projects, how many defects the programmer is going to produce, how many defects the QC will discover and how many defects they will never find!
  2. To know where the problems will occur and when and by whom!
All of those 'mystical' things can be predicted and this is the way how I can stay on top of the project and know before the actual things happen, what will happen, and guess what? It happens the way I 'predicted' ... or rather the way how I calculated.
Imaginary calculation[/caption] How do I do such thing? Well, using statistics. I hope you remember what I told you about my definition of a manager (administrator, teacher and leader).
  1. I write down how many defects a programmer produced and I write down how many defects were found in a certain module and/or program. In this way, I can calculate the accurate representation of the quality of a programmer. For example programmer X has a score of (an average of) 9 (defects per one thousand lines of code). The same I can say about a certain module, which has a score of 13 (defects per thousand or hundred lines of code).
  2. The same with a QC (software) tester. I count the number of defects and the number of defects per module and per developer, so I get an idea what the problems are when I'm going to compare them. Also, I can calculate how many defects such tester finds and I can use that number as a factor of prediction and I can see what the relationships are between developer and tester.
  3. If I want to know how many defects are being found and how many defects are not being found, I use statistics and cheating. I design defects on purpose and let the developer program them in the modules and then I let the QC software tester test it. I get an idea how many defects are found and how many are not found. I also can see where the software tester has problems with finding defects (i.e. defects in the database or logic or buttons or comparing requirements and functionality or execution logic, etc). I repeat this process multiple times, so my statistics are becoming more accurate and of course I do this with all the software testers.
  4. Taking all those numbers and calculate the health of a project. This number I always use to show senior management or the customer if the project is healthy or not. This is for me also the indicator if there is a problem somewhere.
  5. Calculating productivity. Productivity is an overloaded word, but I use this term here for exactly what the term stands for. I'm interested if my resources are indeed producing exactly that as I expect them to produce. This productivity factor is also calculated from many statistical values throughout the project. I can even calculate my own productivity and this number (and then I calculate it to a percentage) I present to the customer and/or senior management too.
I not only collect those numbers in every project, but I collect all numbers. For example how many lines of code a developer is producing, sub-classed by complexity, type of module and/or task, monitoring the times he or she takes a smoke-break, how many cups of coffee he or she drinks, how many times the person sits behind the computer for productivity and how much time on other things, how many emails are being sent and received, etc. All data, which are being collected and used for statistical analysis, so that the next time I create a project, I know how many defects, how many lines of code, how large the program is, what problems will occur, when and by whom, etc.
Related articles

No comments:

Post a Comment

Subscribe to: Posts (Atom)