9.3 A COMMON FRAME OF REFERENCE

---

9.3 A COMMON FRAME OF REFERENCE

To help with our discussions over the next few chapters I have concocted a fictitious organizational structure and business model that we can use as a common frame of reference. There are a number of reasons for doing this.

One of the major stumbling blocks when discussing software development, and it seems metrics in particular, is the use of words, or terminology. I remember wasting a full day of fairly intensive effort because of a misunderstanding about the word "interface." More recently I had a very interesting discussion with a colleague concerning the use of compiler preprocessors. It was just a shame that we were both discussing different things, both called preprocessors! The models discussed below will provide a common terminology for use within this book. I am not trying to impose my terminology on your organization.

While touching on the area of terminology I will point out that I will use expressions like "software engineering," "product development" and "software development" interchangeably. In all cases I am referring to the work that is carried out to develop new systems, to support existing systems including corrective maintenance and to enhance such systems. The context of the expression should make the meaning clear.

When you get into the area of software development life cycles things tend to get even worse. What I call design, others may call requirements specification; what I call low-level design, others may call implementation and include the task with coding and compilation. I offer the "V" model-based development life cycle in Figure 9.3 simply as a common frame of reference for the purposes of this book. I do not see it replacing the Waterfall, Boehm (1) , or Spiral, Boehm et al (1) , models or even the newer Agile development environments if these are what you prefer. Figure 9.3 describes the software development life cycle model I shall use within this book. As usual, circles or bubbles indicate processes while the connecting arrows indicate deliverables or products of those processes. Please note that each process bubble marked with an "*" includes a review and rework cycle and that rework as a result of testing or proving activities have not been shown although, of course, they will be present.

Figure 9.3: Level 1 Engineering Process

If there are many representations of the software development lifecycle there are also many types of organizational structure and, again, terminology can be confusing. I will now suggest an organizational structure, not claiming that this is better than that employed by your own organization or even that it is a good structure, but simply to give us a common frame of reference. Let me stress that the organization I will depict is only used by me for the purpose of discussion and examples within this book.

Figure 9.4 shows an entity relationship model for our reference organization. This is simply a diagrammatic representation of various functions and their associations with each other within the organization. It shows Systems Development as a major function within the organization and that this function consists of two components, Product Development and Support Development both of which may consist of more than one established team.

Figure 9.4: Functional Linkage

Each Support Development team is responsible for producing a tool that will only be used internally within Systems Development. These are delivered to the Operational Support team who will then manage its use by a number of Product Development Teams.

Product Development is the revenue-earning arm of Systems Development. In this case, I will assume that this revenue is earned by selling software products to external customers although it is very possible that the organization itself may be the customer of its Systems Development Function. I will ignore the complication of bundling software and hardware together into a product that is then sold so as not to over complicate the model. From my experience, this does not have a major impact on the implementation of a Software Metrics Program although there are obviously ramifications to be borne in mind.

Notice that each Product Development team can be working on a number of revenue-earning projects at one time. This reflects reality where part of the team can be working on the implementation phase of the development lifecycle while another part of the team can be specifying requirements for another project. Please note also that I include enhancements to existing software products as revenue-earning projects in their own right. The maintenance of products currently in the field, which I have shown as also being the responsibility of the Product Development teams, I see as being the correction of faults that cannot be put of until a future, full product release, the operation of help desks, etc.

I have also separated out a test and integration team, who can provide this service for a number of revenue-earning projects. There may be more than one such team. Relating this back to the software development lifecycle in Figure 9.3, the Product Development teams are responsible for all of the left-hand portion of the "V" model through to unit test and integration, together with unit test specification. The Test and Integration team are responsible for link and system testing, system integration and the associated test specifications.

Figure 9.5 shows a traditional organization hierarchy for the model shown in Figure 9.4. We have a Systems Development manager operating at director level with three functional managers beneath. The Support Development manager is responsible for a number team leaders who will have line management responsibility for software engineers and a project management role. The Operational Support manager is responsible for a number of functions covering the development environment.

Figure 9.5: Traditional Organization Hierarchy

In this organization the Product Manager is responsible for the largest part of the Systems Development function. As this is the revenue-earning component within Systems Development this would seem to make sense! I use the term "Product Manager" because he or she is responsible for the development of new products, the enhancement of existing products and the maintenance of these. So, he or she has two managers reporting up, one responsible for Test and Integration the other responsible for Software Development including enhancement. Both are responsible for a number of team leaders who, again will have project management responsibilities.

I have also introduced two additional functions, R&D and Planning. The reasons for this will become obvious later.

The models in Figures 9.4 and 9.5 are simplistic. In reality, organizations tend to be complex beasts and the relationships between functions within the organization tend to reflect this complexity. Size alone may well add complexity as it can introduce an additional level, or multiple levels, to the organizational hierarchy. However, these two figures do give us a common frame of reference with sufficient complexity to illustrate some of the problems that will face a Software Metrics Implementation project.

Which brings us to the final component in our reference frame, the Software Metrics Project itself. As we have already discussed, such a project can come about for a number of reasons and can be actioned in a number of ways. It may be decided, as a result of the feasibility study described as stage one, that a pilot will be undertaken within one Product Development team and will be their responsibility; it may be that the program will be driven by a number of external consultants reporting directly to the Systems Development Director; or, it may come about as part of a Process Improvement Program and be the responsibility of a Software Engineering Process Group or manager.

All of these options, and the many others that exist as a result of the diversity between organizations have an impact on exactly how the Software Metrics Project is structured and operated. The purpose of this book is, among other things, to present a generic model for the implementation of Software Metrics within organizations that can be tailored and used to help real-life organizations with such an implementation.

So, I am going to make certain assumptions to set up a situation within our hypothetical organization and this will be used to illustrate such an implementation. I have chosen this model of a Software Metrics Project because I believe it to be a very common approach to metrics implementation and because it does lend itself to illustrating a range of problems that can occur as well as to possible solutions. Where I feel it necessary I will mention some of the situations that can arise in other styles of approach.

My first assumption is that the stage one feasibility study has been carried out by an individual within the R&D group. Remember what I have said about terminology: the actual name of this group does not matter but it is, typically, divorced from software development and its role within Systems Development is to improve the software engineering process. A presentation has been given to the Systems Development Director and his first-line managers resulting in approval to proceed with the development of a suitable Software Metrics Program. Notice that at this point we only have authority to develop the program, not to implement it. The reason for this is quite simple: in this hypothetical case the other first-line managers are not yet convinced that they will get a good return on the investment they see themselves having to make. Mind you the Operational Support Manager is on our side but that is to be understood because he or she is not really affected by this program, not yet anyway. Notice I am assuming that the scope of the program covers Product and Support Development only. In fact, such a program may well be confined to Product Development at first.

And who has responsibility for this new project? I will assume that the responsibility has been placed back on the R&D manager who, in turn, has given that responsibility to the person who did the feasibility study. Of course there is no reason why the project could not be placed under the Product Manager, the Support Manager or even the Planning Manager. Well there are reasons, not least given the scope of the project and the cross-functional problems that could arise. At least R&D may be seen as independent of the other functions within the organization and may be perceived as having less of an axe to grind.

There are also problems in placing the project within the R&D function. These arise from such things as a lack of credibility R&D staff can suffer from, the ivory tower syndrome and the "not invented here" reaction which can occur within software development functions. There is much that can be done to overcome these problems, but not yet! Having got our sanction to proceed the first thing to do is to make sure we know how to proceed. Planning is the next thing on the agenda.

To reiterate: we have authority to develop a Software Metrics Program that will be applied, subject to authorization, to both Product and Support Development. The high-level requirements on the project are that a Software Metrics Program provide information about the software development process and its products and that it improve that process in a cost effective way. If you can get a tighter initial requirement, so much the better but this rather vague description of what we need to do does enable us to discuss the various aspects of a Software Metrics Program within the context of implementing that program. Oh yes, we have also been given a time scale. It does not matter how long it is, it will not be long enough!

At this point, the Software Metrics team may have been expanded so that there are now more resources available than during the feasibility study. Equally, the "team" may only consist of one person working part time on the problem. I have already given some indications of my views on resourcing such a team. I will refer to those who have responsibility for the development and implementation of the metrics initiative as the "metrics team."

I said that we need a plan for the future work but I do not intend to describe that plan at all. As stated earlier, this stage of planning activity is seen as being common to all stages. Instead, I will describe the work that needs to be carried out during this and subsequent stages of metrics program development and implementation around which you can develop your own plan. Please remember that this is not a theoretical discussion. The approach described in this book is one that has been tried in practice and is one that has proved to be successful on more than one occasion and in different types of organization and industry.

Figure 9.6 summarizes the work, tasks and linkages within this stage.

Figure 9.6: Work, Task and Linkages Within the Requirements Specification Stage

---