9.10 ESTABLISH INITIAL DEFINITIONS

< Day Day Up >

You may wonder why you will have to spend time deriving a set of initial definitions for use within the metrics program. After all, you probably have development standards that address these very points. The answer is twofold. First, standards, almost by definition, are documents that sit on shelves and that are very seldom read. Second, even if they are read, they seldom define basic terms in such a way that interpretation and modification do not occur. This means that when you use terms like "fault," "defect," "size" and even "project" other people will often put their own meanings on things. Time and again, I have found terminology to be one of the biggest barriers to understanding.

Let me try to illustrate this by example. Consider the term "defect." Does this mean a perceived difficulty as reported by the user, does it mean a problem with a delivered product even if the defect has not yet been detected or does it mean an identified problem with a product detected, verified and located? Any of these definitions are possible but what you mean by the term "defect" can have serious ramifications when you try to measure the things.

It gets even worse when you consider a term like "fault." Is a fault the same as a defect? Is there a relationship between faults and defects? Can you have multiple defects causing one fault, or multiple faults causing one defect? Confusing, isn't it?

A dictionary is not much help either. Collins English dictionary defines the noun "fault" as, "something that mars; flaw; defect." A defect is defined as, "lack of something necessary for completeness" or "an imperfection; blemish." Now we seem to be approaching another key problem as these defect definitions take on a similarity to definitions of quality.

If you would like to spend a fruitless but entertaining half hour, gather together three or four individuals who are connected with software development. Ask them to define what is meant by "software quality," sit back and watch the fun! At the end of half an hour, or the day if you have that much time to waste, you will not have an agreement but you will be very aware of the problems terminology can cause. One word of warning, do not let yourself get drawn into the argument or you may well be surprised at the strength with which you will defend your own corner. Defining quality is like politics and religion, such discussions are best suited to late nights with good wine and trusted friends.

Just to round off this section of despair, what about the term "project?" We all work on projects, projects have become our master in the past, we have meetings and reviews of the project. I will bet that even this term in your organization is not clearly defined.

So, what is the answer? Remember the first principle I discussed in Chapter 1, that of pragmatism and compromise. You will need to be able to define certain basic terms within your metrics initiative simply because you will be talking to many different people and you will be using these terms. It is important that you identify the terms that cause your organization problems and this is one reason why I have left this activity until now within the SMP development model. By talking to your users you will have identified the terms that you need to define. It is also important that you define them in a meaningful way, in a way that is acceptable to the organization and not as theoretical, abstract concepts. How can you obtain the necessary agreement to your definitions? I suggest that you present them to your Metrics Coordination Group and have that group ratify them.

I suppose I should practice what I preach and define some basic terms myself for use within this book. In one sense, these definitions have to be slightly theoretical because the actual definitions you used can depend upon your organizations culture and current practice. Let us return to a previous example. There is a great deal of discussion about the meaning of the terms "fault" and "defect." People tend to view one as the manifestation of an error as perceived by the user of a product, the other is viewed as a flaw in the product that has caused the perceived problem. Obviously, one perceived problem can be related to a number of flaws and vice versa. The question is, which is the defect and which the fault? My answer is very pragmatic, it depends on the organization! If your user reports problems through a defect report, the defect is the perceived problem, the fault is the flaw! If the user reports through a fault report it works the other way round.

But what if your user does not use fault or defect reports? One organization I know of uses "incident reports." In this case, I would suggest that you start to use one term for the flaw that causes the incident report to be raised and stick to it. If other people use the other term then try to educate them, gently and slowly, to use the chosen terms as agreed with the Metrics Coordination Group.

For our purposes, I will use the term defect as the perceived problem, so our users raise "Defect Reports." A fault will be the flaw that causes a defect.

Regarding size, I will use two definitions of size:

Product size is defined as the quantity of the product currently in use and requiring support;
Project size is defined as the functionality that is added, changed or deleted as the result of a software development or enhancement project.

Notice that I am not yet assigning units to our size measures. This will be done later when we select the metrics we will be using.

Now, what about the project itself? I define a project as "a consolidated unit of work managed as a single entity." A project has a recognized start date and end date and has associated with it a project plan. The project starts when the first component of the unit is identified; it ends when the last component is delivered to the product recipient. Note that, depending on your own development lifecycle, this product recipient may be a testing team or the end user or some integration group.

This definition of a project is somewhat cumbersome but it does allow for the case when work starts to be booked against a small work element which then has additional elements added to it over time, during which the project team ramps up to full strength.

What about quality? At a conceptual level I prefer the idea that quality is the satisfaction of user requirements. For practical purposes I view quality as a collection of characteristics that are addressed individually. Remember that the particular set of quality characteristics that you may have to address may be a subset of the totality of quality and may not be clearly specified by your users. As an example of the second point, many users do not specify requirements for maintainability when a system is being developed but they can get very upset if a product is later found to be difficult to maintain. Appendix B contains two sets of quality attribute definitions. The first comes from the ISO/IEC standard IS9126; the second is one that I used before that standard was available. The main difference, mentioned earlier, is the different view taken of maintainability and enhanceability.

Finally, remember to adopt or derive a high level development lifecycle model for your organization.

< Day Day Up >