Introducing Quality Control After The HorseHas Bolted
G. Saltmarsh · WIT transactions on information and communication technologies · 1970
Quality personnel are often brought into Software Development Projects only when the lack of adequate controls has become apparent. Common causes of this are discussed, and basic steps that can be taken to regain control over a software development project are detailed. Two alternative approaches and problems that have been encountered with these are also considered. INTRODUCTION It is not an unusual experience as a Quality Analyst/Manager to be called in to a project that is perceived in some way to be out of control, and to be expected to work a piece of 'Quality' magic on it. The difficulty of this task is not usually appreciated by those who request the help, and results are usually expected by yesterday. In such a situation, what priorities should we set, what should we tackle first and what pitfalls should we seek to avoid? Each situation is different. There is usually a maze of politics to trap the unwary, and success is hard to achieve. Nevertheless, after being involved in a number of these situations and having experienced the results of differing approaches, I believe there are guidelines that can be given. SYMPTOMS The very fact that help is being called in some time after the project has begun means that there must be visible symptoms of a lack of control. As often as not there will be several such symptoms, probably drawn from the following list. 1. Confusion arising from people working from different versions of Transactions on Information and Communications Technologies vol 4, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517 44 Software Quality Management documents, all thinking theirs is the current one. 2. Plans proving worthless because the work done on a product after it has been 'finished' appears to be greater than that needed to 'finish' it in the first place. 3. Specification documents being unusable because of internal or external inconsistencies. 4. Constantly moving goal posts creating eternal rework, e.g. the database structure on which a team is trying to build its product keeps changing. 5. Seriously missed milestones (or complete lack of milestones). 6. Teams working with different and conflicting assumptions, either because their efforts to have them clarified have been unsuccessful, or because they have never asked. The problems have often come to light because some fresh mind has asked a 'simple' question, and finds no-one can answer it. The underlying causes of these symptoms will be the failure of one or more functional processes, and it is these functions that need to be put right. Below are listed functions whose failure may be responsible for each symptom. Symptom 1 Configuration Control; Version Control; Library. Symptom 2 Planning; Quality Control; Reviewing; Sign Off. Symptom 3 Quality Control; Reviewing; Product Breakdown Structure; Dependencies. Symptom 4 Change Management; Planning; Business, System or Technical Architecture. Symptom 5 Planning; Tracking. Symptom 6 Issue Management. It is most likely that the difficulties stem from failures in several of these functions. They are substantially interrelated, and a lack of awareness of the importance of any one is likely to be associated with a similar lack of awareness of the importance of the others. Alternatively it may be that it was not the lack of awareness of the importance of these Transactions on Information and Communications Technologies vol 4, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517 Software Quality Management 45 functions that was the root cause, so much as a lack of awareness that the required formality of such functions is size critical. What will be adequate for a small project may be quite unable to control a larger one. In this case also one would expect several of the functions to be at fault at once. STRATEGIES The solution on the face of it is simple. Put in place adequate procedures in all of these areas and we can quickly regain control. Oh, that it were so easy! Every business will have its own standards and procedures, its own list of approved hardware and software packages, and its own culture. This will be true of the situation into which we have been brought. In some way the existing procedures will be known to have failed and thus be discredited, so we will be very lucky if we don't meet resistance to the introduction of new procedures. We all recognise the need to introduce a solid, comprehensive, consistent set of standards. We also know this cannot be done over one weekend. In fact we know that we are going to need several weeks or longer to get a comprehensive set of standards in place, even if we start with a set taken off the shelf. Prior to the introduction of a wide range of new standards, there will be demands for them to be reviewed, approved and authorised, and this can easily turn into a very long process. So do we go ahead nevertheless and make the introduction of these our top priority? I suggest that before we manage to get approved and established such a comprehensive Quality Management system (which I am using as an umbrella description of the standards and procedures of these many and varied functions), we will have lost our credibility since the confusion we were brought in to fix will have continued to worsen. All we will be perceived to have done is to divert time from 'real tasks' to 'quality matters', and brought no visible benefit. So do we delay the establishment of a sound set of standards and procedures and set out on an ad hoc basis to identify errors and correct them? Do we concentrate on removing the inconsistencies from the Requirements Definition, revalidating the Scope and Objectives and establishing traceability from Requirements to Logical Design to Physical Design, making the removal of errors from the products created so far the top priority. At first sight this course also has much to recommend it, but unfortunately, as we clear existing errors, we will find that the same lack of control as brought problems before will allow fresh errors to reappear Transactions on Information and Communications Technologies vol 4, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517 46 Software Quality Management elsewhere unchecked. The world does not stop while a software development takes place, and there is always the need for changes to be introduced. Without adequate control, this will quickly undo all the good work that has been done. Somewhere between these two approaches a compromise has to be found. Of the two approaches described above, dare I say that it is the second which I believe is closer to the best way forward. I put it like that because it must surely be heresy in any Software Quality Management Specialist Group to accept anything less than a comprehensive set of standards. I don't believe it is heresy. The issue is not about what we aim for, but rather how we get there. If things are known to be wrong we cannot afford to let this continue to worsen if our credibility is to be maintained. Rework is one of the ultimate demotivators. To be told that, as result of other people's errors your last five week's work must be scrapped and a fresh start made does not make one happy. I have experienced leading a team who were on their third set of system test plans, having over the previous six months produced and sent to the shredder the previous two sets. Saying that they must have become quite practised at the task by then, was not the way to make friends and influence people! The circumstances that had given rise to this were similar to those we are considering. When the project began to run into problems around the Functional Specification stage, a 'Quality Group' was formed. The approach taken by this group was influenced by the politics of the situation and this resulted in much time being spent generating and introducing new control procedures. By the time these were introduced disillusion was widespread. It is vital to phase in controls so that, from the first moment, there is clear and effective action which can be seen to be bringing order out of chaos.