Gerald Weinberg, The Psychology of Computer Programming, Van Nostrand Reinhold, 1971.
The creation of an early working model of a system might still be useful as the creation of prototypes shows.
So far in this chapter we have looked at the steps a customer might take to ensure the quality of software produced by an outside supplier. We now need to look at what techniques a project team might wish to employ to help them improve their own software development processes. Three main themes emerge.
• Increasing visibility A landmark in this movement towards making the software development process more visible was the advocacy by the American software guru, Gerald Weinberg, of 'egoless programming'. Weinberg encouraged the simple practice of programmers looking at each other's code.
• Procedural structure At first programmers were more or less left to get on with writing the programs, although there might be some general guidelines. Over the years there has been the growth of methodologies where every process in the software development cycle has carefully laid down steps.
• Checking intermediate stages It seems inherent in human nature to push forward quickly with the development of any engineered object until a 'working' model, however imperfect, has been produced that can then be 'debugged'. One of the elements of the move towards quality practices has been to put emphasis on checking the correctness of work at its earlier, conceptual, stages.
We are now going to look at some specific techniques in more detail. The push towards more visibility has been dominated by the increasing use of walkthroughs, inspections and reviews. The movement towards more procedural structure inevitably leads to discussion of structured programming techniques and to its later manifestation in the ideas of 'clean-room' software development.
The interest in the dramatic improvements made by the Japanese in product quality has led to much discussion of the quality techniques they have adopted such as the use of quality circles and these will be looked at briefly. Some of these ideas are variations on the theme of inspection and clean-room development, but they are seen from a slightly different angle.
The principle of inspection can be extended to any document that is produced at any stage of the development process. For instance, test data needs to be reviewed - its production is usually not a high profile task even though errors can get through to operational running because of its poor quality.
The underlying procedure with inspections is that when a piece of work is completed, copies of the work are distributed to co-workers who then spend some time going through the work, noting any defects. A meeting is then held where the work is discussed and a list of defects requiring rework is produced. The work to be examined could be, for instance, a program listing that is free of compilation errors.
Our own experience of using this technique has been that:
• it is a very effective way of removing superficial errors from a piece of work;
• it motivates the programmer to produce a better structured and self-explanatory program because they know that other people will be criticizing it;
• it helps spread good programming practices because the participants discuss the advantages and disadvantages of specific pieces of code;
• it can enhance team spirit.
The item will usually be reviewed by colleagues who are involved in the same area of work, so that a programmer's work, for example, will be reviewed by fellow programmers. However, to reduce the problems of incorrect communication between different stages there will be representatives from the stages that precede and follow the one that produced the work under review.
IBM have put the review process on a much more structured and formal basis, and have produced statistics to show its effectiveness. A Fagan inspection (named after the IBM employee who pioneered the technique) is a much more formalized procedure which is led, not by the author of the work, but by a specially trained 'moderator'.
The general principles behind the Fagan method
• Inspections are carried out on all major deliverables.
The main problem is maintaining the commitment of participants to a thorough examination of the work they have been allocated after the novelty value of reviews has worn off a little.
See M. E. Fagan's article 'Design and code inspections to reduce errors in program development' in IBM Systems Journal 15(3).
• All types of defect are noted - not just logic or function errors.
• Inspections can be carried out by colleagues at all levels except the very top.
• Inspections are carried out using a predefined set of steps.
• Inspection meetings do not last for more than two hours.
• The inspection is lead by a moderator who has had specific training in the technique.
• The other participants have defined roles. For example, one person will act as a recorder and note all defects found and another will act as reader and take the other participants through the document under inspection.
• Checklists are used to assist the fault-finding process.
• Material is inspected at an optimal rate of about 100 lines an hour.
• Statistics are maintained so that the effectiveness of the inspection process can be monitored.
Exercise 12.10 This exercise needs to be done in groups. Select for review a small program that has been written by one of your colleagues.
Choose a moderator, a reader and a recorder for the group. Spend about 20 minutes examining listings of the program individually and then come together to review the code jointly.
In 1968 E. W. Dijkstra wrote a letter to a learned computing journal which was entitled 'Go To Statement Considered Harmful'. This unfortunately led to the common idea that structured programming was simply about not using GO TOs.
Structured programming and clean-room software development
One of the people most closely associated with the origins of structured programming is Dijkstra. In the late 1960s, software was seen to be getting more complex while the capacity of the human mind to hold detail remained limited. It was also realized that it was impossible to test any substantial piece of software completely - there were just too many possible combinations of inputs. The most that testing could do was prove the presence of errors, not their absence. It was suggested by Dijkstra and others that, because of this, the only way that we could reassure ourselves about the correctness of software was by actually looking at the code.
The way to deal with complex systems, it was contended, was to break them down into components that were of a size for the human mind to comprehend. For a large system there would be a hierarchy of components and sub-components. For this decomposition to work properly, each component would have to be self-contained with only one entry and exit point.
The ideas of structured programming have been further developed into the ideas of clean-room software development by people such as Harlan Mills of IBM. With this type of development there are three separate teams:
• a specification team, which obtains the user requirements and also a usage profile estimating the volume of use for each feature in the system;
• a development team, which develops the code but does no machine testing of the program code produced;
• a certification team, which carries out testing.
Any system is produced in increments, each of which should be capable of The incremental approach actual operation by the end user. The development team does no debugging; was discussed in instead, all software has to be verified by them using mathematical techniques. Chapter 4. The argument is that software that is constructed by throwing up a crude program that then has test data thrown at it and a series of hit-and-miss amendments made to it until it works is bound to be unreliable.
The certification team carry out the testing, which is continued until a statistical model shows that the failure intensity has been reduced to an acceptable level.
As noted in Chapter 4, the object-oriented (OO) approach has now largely superseded the structured programming approach. OO can be seen as a development from the structured approach to software development and shows many of its concerns such as those for reducing coupling (data flows between components) and encouraging cohesion (placing associated software processes in the same place).
In the section above on clean-room development, the use of mathematical verification techniques was mentioned. These techniques use unambiguous, mathematically-based, specification languages of which Z and VDM are examples. They are used to define pre-conditions and post-conditions for each procedure. Pre-conditions define the allowable states, before processing, of the various items of data that a procedure is to work upon. The post-conditions define the state of those data items after the procedure has been executed. Because the mathematical notation is precise, a specification expressed in this way should be unambiguous. It should also be possible to prove mathematically (in much the same way that at school you learnt to prove Pythagoras' theorem) that a particular algorithm will work on the data defined by the pre-conditions in such a way as to produce the post-conditions. It needs hardly be said that in many cases this will be more easily said than done. In fact structured programming can be seen as an attempt to analyse a program structure into small, self-contained, procedures that will be amenable to this formal verification approach.
Much interest has been shown in Japanese software quality practices. The aim of the 'Japanese' approach is to examine and modify the activities in the development process in order to reduce the number of errors that they have in their end products. Testing and Fagan inspections can assist the removal of errors - but the same types of error generally occur again and again in successive products created by a specific type of process. By uncovering the source of errors, this repetition can be eliminated. To do this needs the involvement of all the staff in identifying the causes of errors.
Staff are involved in the identification of sources of errors through the formation of quality circles. These can be set up in all departments of an organization including those producing software where they are known as software quality circles (SWQC).
A quality circle is a group of four to ten volunteers working in the same area who meet for, say, an hour a week to identify, analyse and solve their work-related problems. One of their number is the group leader and there is likely to be an outsider, a facilitator, who can advise on procedural matters. In order to make the quality circle work effectively training needs to be given.
Problem solving by quality circles
The steps that the circle go through in solving problems are:
(a) identify a list of problems;
(b) select one problem to solve;
(c) clarify the problem;
(d) identify and evaluate the causes;
(e) identify and evaluate the solutions; (0 decide on a solution;
(g) develop an implementation plan;
(h) present the plan to management;
(i) implement the plan; (j) monitor the plan;
(k) consider wider applicability of solution;
Exercise 12.11 What are the important differences between a quality circle and a review group?
People often feel inhibited from contributing ideas to a group and brainstorming can help to reduce this inhibition.
A number of specific techniques characterize quality circles, the most prominent of which is brainstorming. A subject or problem for which ideas are needed is nominated and the group then suggest as many ideas as possible. As ideas are suggested they are written down on a flip-chart. Other members of the group do not, at this stage, make any comments or criticisms of any suggestions made. At the end of the session the group go through the ideas listed and put similar ideas together and combine overlapping ideas. Typically this technique would be used to generate the initial list of problems or a list of possible solutions to a particular problem.
Also associated with quality circles is the compilation of most probable error lists. For example, at IOE, Amanda finds that the maintenance group accounts project is being delayed because of errors in the requirements specifications. The project team could be assembled and spend some time producing a list of the most common types of error that occur in requirements specifications. This is then used to identify measures that can reduce the occurrence of each type of error. They might suggest, for instance, that test cases should be produced at the same time as the requirements specification and that these test cases should be dry run at an inspection. Another result might be a checklist for use when conducting inspections of requirement specifications.
This exercise has to be carried out as a group. Select a particular area of common Exercise 12.12
experience where problems have arisen in the past. For example, if you are a group of students you could use the course or module you are undertaking, or a recent assignment that you have just completed. By means of a brainstorming session, identify all the problems that the participants have had. At the end of the brainstorming session, group together similar problems and combine overlapping ones.
For quality circles to work there must be full support for them at all levels of management. First-line management can feel threatened by them as they might appear to undermine their authority. After all, problem solving is one of their main tasks. The proponents of quality circles see them as a way of giving management more time for planning and development. Any manager will have to devote time to 'fire-fighting', dealing with ad hoc crises, and this can detract from longer term activities that will be able to improve the effectiveness of the organization.
Approaches to process improvement, such as the quality circles that have been just discussed, may be supported by quantitative measurement techniques. One of these is the GQM (Goal/Question/Metric) approach. This requires that the goal to be achieved is firstly identified. A goal might be to evaluate whether a new programming language allowed developers to be more productive. In order to achieve this goal, certain specific questions now need to be identified as needing answers. For example, in order to evaluate the productivity of a new programming language the following questions might need answering:
• how quickly were developers previously writing code?
• how quickly are developers writing code with the new programming language?
The problems needing crisis management are often technical in nature. Quality circles can encourage problem solving activity at lower levels of the organization and prevent crises occurring as their causes are tackled.
For further details of GQM see V. R. Basili and H-D. Rombach The TAME project. Towards improvement-oriented software environments' in Transactions on Software Engineering Volume 14(6) pp 758-773. Also GQM by van Solingen & Berghout, McGraw-Hill, 1999.
• how good was the quality the software previously?
• how good is the quality of the software produced using the new programming language?
A European initiative, ami ('application of metrics in industry') adopts a similar approach to GQM.
Was this article helpful?
Tap Directly Into Your Creative Mind... And Easily Access YOUR Million-Dollar Ideas Ideas are the lifeblood of success... and the best ideas originate with brainstorming. Brainstorming can help you successfully fix any problem, build any business, generate any plan, or develop any story. But the problem is that most people have no clue how to effectively brainstorm - either by themselves or with groups. You can waste a lot of time coming up with old, boring ideas that won't work... and the whole time you actually believe that you are brainstorming.