Chapter 15: The Home Stretch | Software Metrics: Best Practices for Successful IT Management

< Day Day Up >

OVERVIEW

In this chapter I want to take a personal view of where we are with Software Metrics and where we might be going. Obviously, this is influenced by the time of writing.

The first edition of this book was originally published in 1993. Since then I have worked in the fields of Software Metrics and process improvement, generally within the IT industry, and during that time I have carried out many assignments for a diverse range of organizations. Sometimes I have acted as a consultant advising internal resources; sometimes I have been "in the line" as a manager, albeit on fixed-term contracts. This has all been valuable experience for me and, I believe, of value to my clients. I have learned much more than I knew when I originally wrote the first edition of this book, but everything that I have learned has reinforced for me the value of measurement within IT organizations.

As I approached the formal research for this second edition, I believed that those lessons and the work carried out by the many individuals, both within the industry and within academia, would mean that much would change. I genuinely felt that there would be many new things to say and that the older references would need to be updated with more recent material. All of us internalize the lessons we learn from life and we apply those to the way we act, we may modify our behaviors or adopt slightly different ways in our approaches to work. As anyone who has ever taught, presented or written a report or a book knows, a key stage is the formalization of those experiences and lessons such that they can be expressed and communicated to others.

While I still believe that I have learned many, many things over the intervening years I also now believe that most of those lessons have been to do with the psychology of the interaction between people and functions within organizations. I have to be honest and say that, at a technical level, what was true in Software Metrics then, and the techniques that worked, is still true Consequently, not many changes were necessary to the contents of Section 1 of this book. Of course there has been progress. Function Point Analysis has been refined but primarily this refinement has been to clarify meanings. There is now an international standard for Functional Sizing Metrics. But it has been the further institutionalization of metrics within the IT industry where progress has been most evident, rather than in radical changes to the techniques that we, as professional IT managers and consultants, use.

I was extremely fortunate to enter the field in which I work at a time of "newness" and, to some extent dynamism. When I started working in Software Metrics, what we were doing was not even generally recognized under that title, which incidentally I did not coin. As my brother once said to me "does that mean you measure how many centimeters of software there are?" At that time, within the IT industry, management was often "by the seat of your pants." Even if experience showed otherwise for a few metrics, many of the measurement techniques developed in the eighties and early nineties are as relevant today as they were then.

But our industry that was large and important back then has also experienced incredible growth. New applications for software are increasingly being explored and, of course, the Internet opens up a completely new world. Although I would prefer that it were otherwise, the number of organizations that have well-established measurement programs in place that are being used on a daily basis to inform management decisions are still few.

As an industry we face a similar problem to a ship's captain of an oil tanker. You cannot stop such a ship or change direction quickly. It takes time. This is one reason why the old joke about power always giving way to sail is inaccurate. Ask any small boat skipper if he expects that oil tanker to avoid him or if he has to avoid it — the answer will be unequivocal. As an industry, our situation with respect to management based on quantitative information is not that different to what it was when I first put pen to paper for the earlier edition of this work over a decade ago. Depressing isn't it?

So, one lesson that I have, I hope, learned is that the process of change is slow. Not only does our industry equate to the oil tanker but it is an oil tanker that is growing longer and more massive even as we progress through the water. And we have no captain! This is fundamental to change. Someone, or some group, has to be responsible for the change if it is to occur. It is perhaps no coincidence that India, the country currently with the highest proportion of high-maturity-level organizations as assessed by one particular approach, is also one of the countries whose government has made a firm commitment, and devoted resources, to developing their IT industry through the production of high-quality software. Of course, lower labor costs are always quoted as a contributing factor but no organization would sacrifice the quality of its second-most important resource (their people being the first) on the basis of cost alone.

If we are to accelerate the rate of change, governments and significant government organizations must take some responsibility to ensure professional management in our IT industries. The good news is that more of them are doing so.

There are also other factors that give rise to the hope that the rate of change may increase. Although the proportion of organizations with established measurement programs may not be much greater than it was years ago, in terms of absolute numbers there are many more. This means more experience within the industry and less opportunity for other organizations, and individual managers within those organizations, to deny the benefits of measurement to support management.

In this section I would like to move away from the problem of developing and implementing a metrics initiative or program and close the book by discussing various topics that fall within the area of interest of anyone involved in Software Metrics. I hope to do this not from the implementation standpoint of the previous sections but more by introducing and discussing certain areas that you may find of interest.

This material comes from many sources in both the academic and industrial environments so specific credits will not be given unless I believe it necessary for someone who wishes to follow up the ideas presented here.

I intend to start by looking at two areas that originated in the United States but are also being implemented in organizations all over the world. These are the Goal, Question, Metric (GQM) paradigm from Basili and Rombach when they were at the Software Engineering Laboratory or SEL and the Process Maturity Model from the Software Engineering Institute and fully described in Watts Humphries' book, "Managing the Software Process."

I have already discussed the Goal, Question, Metric paradigm in other parts of this book but I have included it here to emphasize the fact that it is a technique that is extremely robust and, in my view, should be included as a tool within any serious measurement initiative. A great deal of credit must go to Vic Basili and Dieter Rombach for expressing, so elegantly, a process-based solution to an issue that has caused many individuals a great deal of pain.

I would also like to stress that there is a great deal more to this paradigm than is often presented at conferences and seminars. It is certainly more than setting a goal, asking a few questions and, hey look, we got ourselves a metric. The model is rich and before you think you understand it I suggest you read material such as Rombach (1) .

I believe that you will hear more and more about the GQM approach to metrication over the next few years. You will also hear more and more about the Software Engineering Institute's (SEI, www.sei.cmu.edu) Process Maturity Model. Like GQM, you should also realize that the Process Maturity Model has more to it than may first be obvious.

This model forms part of a technique that can be used to assess the effectiveness of a process for software development. Immediately you can think of two applications for such a technique. If I own such a process, perhaps as the manager of an IT function, then I would like to assess that process. Such information can perhaps help me to decide the best management initiatives; if the scoring mechanism is widely accepted then a good score will do me no harm at all and could do me a great deal of good; even a bad score is not a disaster if I can show improvement over time.

The other application has a very different emphasis. If such a technique gives me an objective mechanism by which I can assess a software development process then I, as a purchaser of software systems, can use that process to assess potential suppliers.

These two applications have been recognized by the SEI who have established two processes, the SEI Assessment and the closely related Software Capability Evaluation. The main differences are that an organization carries out an SEI assessment for its own benefit, that same organization may have a Software Capability Evaluation carried out on it, especially if it is your intention to supply a U.S. government department or agency.

< Day Day Up >