Chapter 10: Stage 3: Component Design

---

OVERVIEW

Key Points:

Three distinct streams of design effort

Metrics Definition

Introduction to the Goal, Question, Metric paradigm

Administration Design

Marketing and Business Planning

Let us recap on the situation. You now know a lot more about Software Metrics than you did when you started work on the program, you have obtained the authority to develop proposals for a metrics program, you have identified a set of requirements against the program linked to primary and secondary customers and you have some idea about what information the organization already collects.

You have also established a steering group, the Metrics Coordination Group. You may also have some ideas about how you intend to satisfy the various requirements you have identified. This is almost inevitable and is typical of the iteration and stage overlap that occurs in real life despite any lifecycle model that appears to impose sequential development. In fact this overlap can be very useful as it allows you to feed back as well as forward to later stages in the development process. Do take care to control feedback, otherwise you can find that you do work against a requirement only to have the requirement changed!

Control is really about baselining requirements with the agreement of your customer authority. This does not mean that a requirements change will never happen, but it does give visibility to those changes and allows their impact to be assessed. The very fact that change involves consultation and agreement to amend a baselined document often means that the need for the change is given more serious thought which, in turn, can limit the changes that occur. Like so many things, it is simply good practice and common sense.

I have called this stage "design" and I see it as consisting of four main streams or sets of activities that will eventually come together and result in a design proposal. The first stream is the definition of the metrics, tools and metrics based techniques that will form the core of our program. Let me stress again that it is only now, after the information requirements have been defined, that we start to think about the metrics! Next we have, what I call, the administration requirements. This covers elements of the program that are needed to use the metrics in a practical way. Another way of thinking of this is as designing the operational procedures and support mechanisms necessary for the implementation of a tactical approach. Examples of these elements include a metrics database and the data collection procedures that will be required.

The final two streams are, I believe, vital to the success of any metrics program yet they are more to do with the organization and the people in that organization than with technical issues. Any initiative that is intended to change the way people think, act and work must address the infrastructure that will enable change. I found a classic case where this was not addressed in one organization that was striving to motivate its staff and to draw on their recognized ability to make things better themselves. So far so good. A huge publicity exercise was undertaken linked to a very expensive set of training courses that, together, raised peoples expectancy in terms of their perception of the contribution they could make to their business. Again, so far so good. This program had a budget of some five million pounds sterling over one financial year so it was not a trivial exercise. And it worked! People became switched on to making the business more effective, to contributing to the business but there was a problem: one of the cornerstones of this initiative was that everyone in the business could and indeed should contribute to the business because the people best placed to improve things are often the ones who are already there. Unfortunately there was no infrastructure put in place to enable this to happen.

This was made painfully obvious to me when a secretary came to me with an idea that was beautiful in its simplicity and that could have saved a considerable amount of money, the problem was we had no idea how to take that idea forward within the change initiative. The infrastructure had not been addressed! We will discuss the infrastructure necessary for a metrics program.

Finally, we need to consider the way the program will be marketed and introduced to the business so we will look at how to develop a marketing and business plan. It is interesting to note how often Software Metrics programs become the responsibility of functional groups that are separate from the software development function. Effectively, the metrics team must act as internal consultants because they cannot, and indeed should not, impose their will on development teams. This implies that the metrics team must conduct themselves in the same way that a small business or external consultants have to conduct themselves, namely in a professional and businesslike way. I am afraid that you can have the best set of metrics ever devised, the most effective techniques for assisting development to produce high quality software and control mechanisms that would make the harshest project coordinator smile, but if you do not market them effectively within your organization they will never be taken up and used by the organization. This is a fact of life!

I will talk about the various streams in turn but do remember that the tasks they cover do have dependencies within the stream and on tasks within other streams. Figure 10.1 gives my interpretation of these dependencies.

Figure 10.1: Tasks and Links Within Design Stage (Showing Dependencies Between Streams)

However, before we talk about the four main streams there is one set of activities that should be addressed, pilot projects.

---