ISO 9001: Moving from requirement to

Transcription

1 ISO 9001: Moving from requirement to reality J. Hemington of ABSTRACT Quality Systems work. Given the right design, implementation and support a Quality System can make an important contribution to improving the efficiency and effectiveness of software production and maintenance. Metrics are being used increasingly to support increased visibility and improved control of processes. Managing the 'people factor' is critical for the success of the Quality System. INTRODUCTION This paper describes the Quality System (QS) implementation within one of the three development groups of IT, the Information Technology Business of the Post Office. The Post Office is a large consumer of IT services, and IT is a major supplier of such services, ranking in the top 10 systems houses in the UK. The development group's activity is focused largely but not exclusively on the provision of office systems to support the business of Post Office Counters Ltd, which operates a retail network of over 20,000 post offices. Recently it has undertaken the development of Healthcare systems as part of it's entry into the marketplace for hospital systems. The group employs about 220 of it's 1100 staff. Development of the QS started in late 1988 and since then it has matured into a capable system which was successfully certified to ISO 9001 in March The organisation has always been content to regard certification as a secondary objective, the prime goal being to improve the quality of the systems and services delivered by the group. As a consequence, we applied for certification at a later stage than most organisations. Decisions on priorities have been

2 4 Software Quality Management guided throughout the implementation of the QS by our judgement as to where we could achieve maximum leverage to improve the group's performance against timescale, cost and technical quality so as to meet customer requirements and maximise customer satisfaction. PRINCIPLES The QS embodies some key principles. These are: - planning of work so as to build in quality from the outset - personal responsibility for work products so that we can 'get it right first time' or come close - exposure of work products to scrutiny so that we can detect and remove errors at the earliest possible stage - application of standardised processes so that we can be more efficient and effective - timely feedback on performance at project, process and individual level - continuous improvement so that performance improvement can follow. DOCUMENTATION STRUCTURE The QS has been designed to meet the requirements of ISO 9001 [1], which has for some time been regarded as the most comprehensive definition of the requirements for a quality management system for software development (see for example the Logica Report [2]). The QS documentation structure is in three tiers (see Figure 1): - Quality Manual, which serves as an overview of the system and which follows the TickIT structure [3] so that it can be more meaningful to IT professionals - standards and procedures, which are the core of the system, defining the requirements of work products and processes - checklists and guidelines, which provide supporting material to help users in meeting the requirements of the standards and procedures.

3 Software Quality Management 5 Standards and Procedures Checklists and Guidelines Figure 1. Quality System documentation structure To date there are about 50 documents in each of the bottom two tiers. All documents are subject to review by a review body comprising representatives of the departments in the group. The less formal nature of the guidance material is taken into account for the control approach, with the result that the guidelines and checklists are freely available to all staff in the same way as forms, without copy control. Copy control is however applied to the standards and procedures. IMPLEMENTATION The QS was developed and implemented in a staged manner to provide, in sequence: - documentation control and review processes - project management and control processes - lifecycle standards and procedures - support functions. Each of these stages comprised development activity (involving document production, walkthroughs and reviews) followed by introduction (involving QM support for project staff) and then compliance checking (involving audits).

4 6 Software Quality Management METRICS To provide a context for the metrics considerations which follow, Figure 2 presents a model for the development process, whereby a project's Plans specify the precise mix of QS Documents which will be applied to the Process to create the System required by the Customer. The Audit process is applied to the project to establish the extent to which the Plans are implemented; the number of audits is a function of the duration and significance of the project. While the project is underway it is exposed to Risks, which must be managed. QS Documents Figure 2. Project model

5 Software Quality Management 7 Metrics are applied in support of QS activity. As a consequence of the processes which are operated, a great volume of raw data is produced; our task is to produce the most meaning and timely information from this in order to support management decision-making processes. Examples follow in three areas, where metrics serve to raise visibility and enhance control. Plan Scoring Plan scoring is performed by assessing sections of plans for completeness and adequacy in meeting the requirements of the corresponding planning standards. Figure 3 shows the scores out of 100 assigned for a particular project to the three sections of the Project Plan and two sections of the Quality Plan. This approach is being used in support of walkthrough and review of plans so that areas of weakness can be identified and addressed at the earliest opportunity. 100 _* Management Schedule Quality Standards & Definition Data Overview Procedures Figure 3. Plan scoring (DUP Project)

6 8 Software Quality Management Ris'k Management The group operates a risk management process which encourages a proactive management style in order to improve the probability of projects meeting their objectives. The process embraces risk elements described by other authors (see for example Boehm [4] and Charette [5]), and may be tailored to meet the needs of individual projects. The project manager is required to identify risks, describe and size them, and then perform analysis and define actions to control them. Risk details are maintained and reviewed as part of planning reviews, milestone reviews and certain management reviews. The set of individual risk sizes is processed using a formula to established a normalised risk size for the project. The normalised risk size is then plotted (see Figure 4) to support the review and monitoring of risk status and trends, and to provide a means of comparison across projects Mar I I I I 24 Apr 8 May 10 Apr 22 May 5 Jun 19 Jun 3 Jul 17 Jul 31 Jul Figure 4. Normalised risk (DUP Project)

7 Software Quality Management 9 Audit Scoring Whenever an audit is performed, one or more non-conformities are identified. These non-conformities are assessed for severity, and the resulting scores are processed through a formula to arrive at a compliance score for the project or maintenance service. Figure 5 illustrates compliance levels for the last three years, revealing a positive trend, but also illustrating instances of poor compliance. It is hoped that this technique can be exploited to promote higher compliance of projects with their plans and referenced QS documents and to foster a healthy competitiveness between project managers. 100 « Audits 1990 / 1992 Figure 5. Project and service compliance

8 10 Software Quality Management PROBLEMS We have encountered problems at every level, from difficulties in applying a standard where it is impractical for some reason through to disregard by project managers for their own authorised plans. The walkthrough programme and subsequent review to which each new standard and procedure is subjected has generally resolved most problems before they reached the user. A greater problem has been where the project manager has looked upon project planning as a one-off exercise to be performed when time permits; such an attitude has given rise to late planning and unmaintained plans. Similarly, risk management has also sometimes been handled once only, whereupon it has been viewed as peripheral to the project management activity. Fortunately there has been increasing acceptance of the significance of the planning and risk management processes, and corresponding improvements in management attention to both areas has been recorded with subsequent tighter control of project activity and improved performance levels. Figure 5 shows that there is still scope for improvement in the extent to which projects implement their plans. Communication problems have also been experienced whereby instructions have not been communicated to staff or documented plans have been overridden verbally. Further instances are where staff have been unfamiliar with the applicable standard or procedure, and have consequently failed to implement it properly. This type of problem is now rarely encountered. The single most significant challenge facing the QS relates to our need for our Customer to improve his own processes. As our own processes have improved, we have attempted to bring our Customer along the improvement path. It would be most helpful if the sound advice contained in the Purchasers' guide within the TickIT guide [6] were put into practice, but I fear that our efforts as a supplier to exercise influence on our Customer will not suffice to bring about the required change. Since shortcomings in procurement processes are certainly not limited to the Post Office, it seems that wider publicity on this aspect of TickIT perhaps leading to a future ISO standard, coupled with Government measures to apply the identified Purchaser activities, would bring potentially huge benefits to the marketplace in terms of quality improvement.

9 Software Quality Management 11 SUCCESS FACTORS The success of the QS may be ascribed to: - the participative approach for producing QS documents - the staged implementation - management commitment - Quality Management (QM) support - staff perception. Production Approach Most QS documents were produced by the software managers, developers and testers who would be subsequent users; the remainder were written by QM staff. Also, all new QS documents are subjected to a thorough walkthrough and review process which serves not only to improve the resulting standard or procedure, but also spreads information and awareness, invites contribution and builds confidence and commitment. Implementation Approach The QS implementation has followed a gradual, staged approach from general processes to more specific processes, and from a small user base to an increasingly larger base. This has generally allowed time to 'debug' standards and procedures before they were widely used, and has eased the task of training users. Management Commitment Our experience has been that it takes a substantial investment of time and effort to move from an initial declaration of management commitment to the point where real management understanding of the QS is achieved. This has been a positive development within the group with the result that today the management understanding of the QS, its operation and its benefits, rests on a much more solid foundation than before. Quality Management Support QM support has been important in guiding the evolution of the QS, assisting its application, and testing staff compliance with it. The audits which are performed serve to identify both the strengths and weaknesses in the QS and the way it is applied. Audit recommendations are agreed with management and provide a means of strengthening the QS in response to the performance feedback provided by the audit observations and subsequent analysis. Staff Perception The general perception of the QS held by staff is positive. From the outset the QS has benefitted from good grass-roots support, which has grown with familiarity, the maturing of the system itself, and the growing realisation of the benefits the system brings.

10 12 Software Quality Management BENEFITS The Quality System benefits include: - greater consistency in project management, which has led to: - improved project visibility - improved definition and effectiveness of Customer participation in project processes - fewer surprises for our project managers, senior management and Customer - more predictable achievement levels as a consequence of improved control - improved performance against timescale and cost objectives in particular - improved Customer satisfaction. The QS is underpinned by a number of improvement processes for influencing project and individual performance in a positive way. The intention has been to create a QS which will become a repository for the collective wisdom of the organisation. Our experience is that the QS is enjoying increasing support and improvement, with over 200 change requests processed to date and requets being raised currently at the rate of two per week. The QS is equated with the professional way of working and is thereby a source of support and strength for the success of the organisation. Our task now is to continue to build upon and improve the QS and to make it increasingly effective. REFERENCES 1. ISO , Quality systems - Model for quality assurance in design/development, production, installation and servicing 2. Logica Report, Quality Management Standards for Software, UK Department of Trade and Industry, ISO , Guidelines for the application of ISO 9001 to the development, supply and maintenance of software, B. W. Boehm, Software Risk Management: Principles and Practices, IEEE Software, January R. N. Charette, Software Engineering Risk Analysis and Management, McGraw-Hill, TickIT Guide, Guide to Software Quality Management System Construction and Certification using EN29001, UK Department of Trade and Industry, 1990