Software standards Software Engineering 9th ed (intro txt) I. Sommerville (Pearson, 2011)

658 Chapter 24 ■ Quality management processes have to be defined to monitor the use of the standards and check that they have been followed. Software standards are important for three reasons: 1. Standards capture wisdom that is of value to the organization. They are based on knowledge about the best or most appropriate practice for the company. This knowledge is often only acquired after a great deal of trial and error. Building it into a standard helps the company reuse this experience and avoid previous mistakes. 2. Standards provide a framework for defining what ‘quality’ means in a particular setting. As I have discussed, software quality is subjective, and by using stan- dards you establish a basis for deciding if a required level of quality has been achieved. Of course, this depends on setting standards that reflect user expecta- tions for software dependability, usability, and performance. 3. Standards assist continuity when work carried out by one person is taken up and continued by another. Standards ensure that all engineers within an organization adopt the same practices. Consequently, the learning effort required when start- ing new work is reduced. There are two related types of software engineering standard that may be defined and used in software quality management: 1. Product standards These apply to the software product being developed. They include document standards, such as the structure of requirements documents, documentation standards, such as a standard comment header for an object class definition, and coding standards, which define how a programming language should be used. 2. Process standards These define the processes that should be followed during software development. They should encapsulate good development practice. Process standards may include definitions of specification, design and valida- tion processes, process support tools, and a description of the documents that should be written during these processes. Documentation standards Project documents are a tangible way of describing the different representations of a software system requirements, UML, code, etc. and its production process. Documentation standards define the organization of different types of documents as well as the document format. They are important because they make it easier to check that important material has not been omitted from documents and ensure that project documents have a common ‘look and feel’. Standards may be developed for the process of writing documents, for the documents themselves, and for document exchange. http:www.SoftwareEngineering-9.comWebQualityMandocstandards.html 24.2 ■ Software standards 659 Standards have to deliver value, in the form of increased product quality. There is no point in defining standards that are expensive in terms of time and effort to apply that only lead to marginal improvements in quality. Product standards have to be designed so that they can be applied and checked in a cost-effective way, and process standards should include the definition of processes that check that product stan- dards have been followed. The development of international software engineering standards is usually a prolonged process where those interested in the standard meet, produce drafts for comment, and finally agree on the standard. National and international bodies such as the U.S. DoD, ANSI, BSI, NATO, and the IEEE support the production of stan- dards. These are general standards that can be applied across a range of projects. Bodies such as NATO and other defense organizations may require that their own standards be used in the development contracts that they place with software companies. National and international standards have been developed covering software engineering terminology, programming languages such as Java and C++, notations such as charting symbols, procedures for deriving and writing software require- ments, quality assurance procedures, and software verification and validation processes IEEE, 2003. More specialized standards, such as IEC 61508 IEC, 1998, have been developed for safety and security-critical systems. Quality management teams that are developing standards for a company should normally base these company standards on national and international standards. Using international standards as a starting point, the quality assurance team should draw up a standards ‘handbook’. This should define the standards that are needed by their organization. Examples of standards that could be included in such a handbook are shown in Figure 24.4. Software engineers sometimes consider standards to be overprescriptive and not really relevant to the technical activity of software development. This is particularly likely when project standards require tedious documentation and work recording. Although they usually agree about the general need for standards, engineers often find good reasons why standards are not necessarily appropriate to their particular Product standards Process standards Design review form Design review conduct Requirements document structure Submission of new code for system building Method header format Version release process Java programming style Project plan approval process Project plan format Change control process Change request form Test recording process Figure 24.4 Product and process standards 660 Chapter 24 ■ Quality management project. To minimize dissatisfaction and to encourage buy-in to standards, quality managers who set the standards should therefore take the following steps: 1. Involve software engineers in the selection of product standards If developers understand why standards have been selected, they are more likely to be com- mitted to these standards. Ideally, the standards document should not just set out the standard to be followed, but should also include commentary explaining why standardization decisions have been made. 2. Review and modify standards regularly to reflect changing technologies Standards are expensive to develop and they tend to be enshrined in a company standards handbook. Because of the costs and discussion required, there is often a reluctance to change them. A standards handbook is essential but it should evolve to reflect changing circumstances and technology. 3. Provide software tools to support standards Developers often find standards to be a bugbear when conformance to them involves tedious manual work that could be done by a software tool. If tool support is available, very little effort is required to follow the software development standards. For example, document standards can be implemented using word processor styles. Different types of software need different development processes so standards have to be adaptable. There is no point in prescribing a particular way of working if it is inappropriate for a project or project team. Each project manager should have the authority to modify process standards according to individual circumstances. However, when changes are made, it is important to ensure that these changes do not lead to a loss of product quality. This will affect an organization’s relationship with its customers and will probably lead to increased project costs. The project manager and the quality manager can avoid the problems of inappro- priate standards by careful quality planning early in the project. They should decide which of the organizational standards should be used without change, which should be modified, and which should be ignored. New standards may have to be created in response to customer or project requirements. For example, standards for formal specifications may be required if these have not been used in previous projects. 24.2.1 The ISO 9001 standards framework There is an international set of standards that can be used in the development of qual- ity management systems in all industries, called ISO 9000. ISO 9000 standards can be applied to a range of organizations from manufacturing through to service indus- tries. ISO 9001, the most general of these standards, applies to organizations that design, develop, and maintain products, including software. The ISO 9001 standard was originally developed in 1987, with its most recent revision in 2008. The ISO 9001 standard is not itself a standard for software development but is a framework for developing software standards. It sets out general quality principles, 24.2 ■ Software standards 661 describes quality processes in general, and lays out the organizational standards and procedures that should be defined. These should be documented in an organizational quality manual. The major revision of the ISO 9001 standard in 2000 reoriented the standard around nine core processes Figure 24.5. If an organization is to be ISO 9001 con- formant, it must document how its processes relate to these core processes. It must also define and maintain records that demonstrate that the defined organizational processes have been followed. The company quality manual should describe the relevant processes and the process data that has to be collected and maintained. The ISO 9001 standard does not define or prescribe the specific quality processes that should be used in a company. To be conformant with ISO 9001, a company must have defined the types of process shown in Figure 24.5 and have procedures in place that demonstrate that its quality processes are being followed. This allows flexibility across industrial sectors and company sizes. Quality standards can be defined that are appropriate for the type of software being developed. Small companies can have unbureaucratic processes and still be ISO 9001 compliant. However, this flexibility means that you cannot make assumptions about the similarities or differences between the processes in different ISO 9001–compliant companies. Some compa- nies may have very rigid quality processes that keep detailed records, whereas others may be much less formal, with minimal additional documentation. The relationships between ISO 9001, organizational quality manuals, and indi- vidual project quality plans are shown in Figure 24.6. This diagram has been derived from a model given by Ince 1994, who explains how the general ISO 9001 standard can be used as a basis for software quality management processes. Bamford and Dielbler 2003 explain how the later ISO 9001: 2000 standard can be applied in software companies. Business Acquisition Design and Development Test Production and Delivery Service and Support Business Management Supplier Management Inventory Management Configuration Management Product Delivery Processes Supporting Processes Figure 24.5 ISO 9001 core processes 662 Chapter 24 ■ Quality management Some software customers demand that their suppliers should be ISO 9001 certi- fied. The customers can then be confident that the software development company has an approved quality management system in place. Independent accreditation authorities examine the quality management processes and process documentation and decide if these processes cover all of the areas specified in ISO 9001. If so, they certify that a company’s quality processes, as defined in the quality manual, conform to the ISO 9001 standard. Some people think that ISO 9001 certification means that the quality of the software produced by certified companies will be better than that from uncertified companies. This is not necessarily true. The ISO 9001 standard focuses on ensur- ing that the organization has quality management procedures in place and it follows these procedures. There is no guarantee that ISO 9001 certified companies use the best software development practices or that their processes lead to high-quality software. For example, a company could define test coverage standards specifying that all methods in objects must be called at least once. Unfortunately, this standard can be met by incomplete software testing, which does not run tests with differ- ent method parameters. So long as the defined testing procedures were followed and records kept of the testing carried out, the company could be ISO 9001 cer- tified. The ISO 9001 certification defines quality to be the conformance to stan- dards, and takes no account of the quality as experienced by users of the software. Agile methods, which avoid documentation and focus on the code being developed, have little in common with the formal quality processes that are discussed in ISO 9001. There has been some work done on reconciling these approaches Stalhane and Hanssen, 2008, but the agile development community is fundamentally opposed to what they see as the bureaucratic overhead of standards conformance. For this reason, is used to develop instantiated as instantiated as documents Supports Project 1 Quality Plan Project 2 Quality Plan Project 3 QualityPlan Project Quality Management Organization Quality Manual ISO 9001 Quality Models Organization Quality Process Figure 24.6 ISO 9001 and quality management 24.3 ■ Reviews and inspections 663 companies that use agile development methods are rarely concerned with ISO 9001 certification.

24.3 Reviews and inspections

Reviews and inspections are QA activities that check the quality of project deliver- ables. This involves examining the software, its documentation and records of the process to discover errors and omissions and to see if quality standards have been followed. As I discussed in Chapters 8 and 15, reviews and inspections are used alongside program testing as part of the general process of software verification and validation. During a review, a group of people examine the software and its associated documentation, looking for potential problems and non-conformance with stan- dards. The review team makes informed judgments about the level of quality of a system or project deliverable. Project managers may then use these assess- ments to make planning decisions and allocate resources to the development process. Quality reviews are based on documents that have been produced during the soft- ware development process. As well as software specifications, designs, or code, process models, test plans, configuration management procedures, process stan- dards, and user manuals may all be reviewed. The review should check the consis- tency and completeness of the documents or code under review and make sure that quality standards have been followed. However, reviews are not just about checking conformance to standards. They are also used to help discover problems and omissions in the software or project docu- mentation. The conclusions of the review should be formally recorded as part of the quality management process. If problems have been discovered, the reviewers’ com- ments should be passed to the author of the software or whoever is responsible for correcting errors or omissions. The purpose of reviews and inspections is to improve software quality, not to assess the performance of people in the development team. Reviewing is a public process of error detection, compared with the more private component-testing process. Inevitably, mistakes that are made by individuals are revealed to the whole programming team. To ensure that all developers engage constructively with the review process, project man- agers have to be sensitive to individual concerns. They must develop a working culture that provides support without blame when errors are discovered. Although a quality review provides information for management about the soft- ware being developed, quality reviews are not the same as management progress reviews. As I discussed in Chapter 23, progress reviews compare the actual progress in a software project against the planned progress. Their prime concern is whether or not the project will deliver useful software on time and on budget. Progress reviews take external factors into account, and changed circumstances may mean that soft- ware under development is no longer required or has to be radically changed. 664 Chapter 24 ■ Quality management Projects that have developed high-quality software may have to be canceled because of changes to the business or its operating environment. 24.3.1 The review process Although there are many variations in the details of reviews, the review process Figure 24.7 is normally structured into three phases: 1. Pre-review activities These are preparatory activities that are essential for the review to be effective. Typically, pre-review activities are concerned with review planning and review preparation. Review planning involves setting up a review team, arranging a time and place for the review, and distributing the documents to be reviewed. During review preparation, the team may meet to get an overview of the software to be reviewed. Individual review team members read and understand the software or documents and relevant standards. They work independently to find errors, omissions, and departures from standards. Reviewers may supply written comments on the software if they cannot attend the review meeting. 2. The review meeting During the review meeting, an author of the document or program being reviewed should ‘walk through’ the document with the review team. The review itself should be relatively short—two hours at most. One team member should chair the review and another should formally record all review decisions and actions to be taken. During the review, the chair is responsible for ensuring that all written comments are considered. The review chair should sign a record of comments and actions agreed during the review. 3. Post-review activities After a review meeting has finished, the issues and prob- lems raised during the review must be addressed. This may involve fixing soft- ware bugs, refactoring software so that it conforms to quality standards, or rewriting documents. Sometimes, the problems discovered in a quality review are such that a management review is also necessary to decide if more resources should be made available to correct them. After changes have been made, the review chair may check that the review comments have all been taken into account. Sometimes, a further review will be required to check that the changes made cover all of the previous review comments. Post-Review Activities Post-Review Activities Review Meeting Individual Preparation Group Preparation Planning Follow-Up Checks Improvement Error Correction Figure 24.7 The software review process