| Author | Message | ||
     Qualitier |
I need help: How can I measure efficiency (NOT effectiveness) of Software Maintenance Process on the basis of ISO 9000:2000 definition? The steps of my thinking are: 1) ISO 9000:2000 says 3.2.15 efficiency relationship between the result achieved and the resources used 2) To measure SWM process efficiency I have to divide size of work by size of resources 3)No major problems to measure size of resources. In general this is actual effort (in pm or ph) 4) The problem is how to measure a size of SWM service? Maintained application size, Maintenance period, Users quantity could be considered. What else? I'll appreciate any idea. Thanks in advance. | ||
| Gene Fellner |
What I teach is to measure the number of full-time equivalents (FTEs) needed to maintain a 10,000FP portfolio. You can normalize it over any size you want but this usually will give you a integer you can use with no decimal places. Taking the measure once a year is usually all you need to do, but you could probably do it twice a year without losing statistical validity. In my opinion the problem is not how to measure maintenance productivity, but what to do with the metric once you have derived it. If you've found that a lot of factors can affect the delivery rate of development projects, then you can imagine the myriad that can impact maintenance. Age is the biggest factor. Hopefully everyone is aware of the fact that software is the only engineering artifact whose quality degrades with maintenance rather than improving or at least remaining constant. The number of years a system has been maintained, the number of different people who have left their fingerprints on it... eventually software has undergone so much "maintenance" that it stops working entirely.  How many end users are there? The more people use a system, the faster they discover defects. Is this a mission-critical system that has to be as defect-free as avionics, or a back office system whose users can live without a couple of reports? How many other systems interface with it? Does it have to comply with government regulations? You end up having to categorize your systems by the parameters that are most important to you. Then you can compare differences in maintenance productivity meaningfully. I have not seen a lot of work done with maintenance productivity. I'll be interested to read the comments of other members on this subject. | ||
| Qualitier |
Gene, thanks for Your answer. but what to do with the metric once you have derived it Yes, It's not my idea to measure efficiency of software maintenance process :/ The potential advantage of efficiency measurement is: - compare usage of resources in different projects; - estimate improvement of resources usage during defined time period. But why? The "easiest" way to estimate process maturity is to measure effectiveness and efficiency. No problem to measure effectiveness but there are problems with efficiency. Measuring efficiency requires: - investigation for new metrics; - effort for collection of metrics data. But what's the reason of this activities? I become think that no reason..... On the basis of quantity of posts in this topic I suppose measurement of efficiency is not impotant for practicioners.... This is an evidence of reason to measure (Message edited by Qualitier on January 30, 2006) | ||
| Gene Fellner |
"...compare usage of resources in different projects;" Maintenance efforts are not considered projects under our rules. Therefore it is not valid to perform Function Point counts on individual maintenance efforts. You can count the size of an application portfolio or libarary, and measure the maintenance work that is required to keep it working. The smallest unit of time for which this is statistically reasonable is, probably, six months for a fairly large library. As far as I know there hasn't been a lot of research into this issue. | ||
| Charley Tichenor |
You have listed several good reasons for metrics, but there is an other one – metrics help motivate performance. If my supervisor wants me to count, say, 15 applications this year, and my evaluation is based in part on the number of applications I count, you can be sure that I will count at least 15 applications. If a manager is given the target to derive a 12% spread between revenue and expenses, then that manager will be driven to achieve at least that 12%. So, implementing a (very) careful choice of tested metrics is important because it basically puts into place a powerful organizational performance motivation program, and good people will be self-motivated to achieve those goals. Also, this is one reason why many people resist metrics because they do not want to be motivated in this way. | ||
| Gene Fellner |
The reason being, of course, that in today's complex organizations people often have control over only a fraction of the factors that drive their accomplishments. No matter how motivated they are, they cannot always improve their performance because the rest of the organization won't cooperate. | ||
| Peter Hudson |
Hi Gene, Interesting information http://www.ifpug.org/webforum/discus/show.cgi?tpc=1780&post=8304#POST8304 Can you tell me where can I find a detailed definition of the indicator that you propose? And you mention that the size must be measured only once a year (max 2 times a year). But in today's fast changing environment, where many projects regularly deliver new/updated functionalities that are constantly transferred to application maintainance mode, what are the arguments to not re-establish the size baseline each time application changes? (for info: I support your idea of once a year, but I need to know why not each time the application evolves - to cater to colleagues who would want to know that). |
