4.3.1 ISO 9000 Family

As described on the ISO website, “The ISO 9000 family addresses various aspects of quality management and contains some of ISO's best known standards. The standards provide guidance and tools for companies and organizations who want to ensure that their products and services consistently meet customer's requirements, and that quality is consistently improved.” The ISO 9000 family includes the following four standards.

The ISO 9001 standard provides the basic concepts, principles and vocabulary of quality management systems (QMS) and is the basis for other standards for QMSs [ISO 15]. The “Quality Management Principles” (QMP) are a set of values, rules, standards, and fundamental convictions regarded as fair and that could be the basis for quality management. ISO 9001 proposes the following for each QMP:

• – A statement that describes the principle.
• – A foundation that explains why this principle is important for the organization.
• – The main benefits associated with this principle.
• – Possible actions to improve the performance of the organization by applying this principle.

The seven QMP of the ISO 9001, presented in order of priority, are [ISO 15]:

• – Principle 1: Customer focus

• Organizations depend on their customers and therefore should understand current and future customer needs, should meet customer requirements and strive to exceed customer expectations.

• – Principle 2: Leadership

• Leaders establish unity of purpose and direction of the organization. They should create and maintain the internal environment in which people can become fully involved in achieving the organization's objectives.

• – Principle 3: Involvement of people

• People at all levels are the essence of an organization and their full involvement enables their abilities to be used for the organization's benefit.

• – Principle 4: Process approach

• A desired result is achieved more efficiently when activities and related resources are managed as a process.

• – Principle 5: System approach to management

• Identifying, understanding, and managing interrelated processes as a system contributes to the organization's effectiveness and efficiency in achieving its objectives.

• – Principle 6: Factual approach to decision making

• Effective decisions are based on the analysis of data and information.

• – Principle 7: Mutually beneficial supplier relationships

• An organization and its suppliers are interdependent and a mutually beneficial relationship enhances the ability of both to create value.

As an example, the first principle of customer focus is described in detail [ISO 15]:

• – Statement

• The main objective of quality management is to satisfy customer requirements and strive to exceed their expectations.

• – Basis

• Sustainable performance is achieved when an organization obtains and retains the confidence of customers and of other interested parties. Every aspect of the interaction with customers provides an opportunity to create more value for the customer. Understanding the current and future needs of customers and other stakeholders contributes to the sustainable performance of the organization.

• – Benefits

• Increased customer value
• Increased customer satisfaction
• Improved customer loyalty
• Improved recurring business activity
• Improved corporate image
• Expanded customer base
• Increased sales and market share

• – Possible actions

• Identify direct and indirect customers for which the organization creates value.
• Understand the needs and expectations of current and future customers.
• Link the objectives of the organization to the needs and expectations of its clients.
• Communicate the needs and expectations of clients at all levels of the organization.
• Plan, design, develop, produce, deliver, and support products and services to meet the needs and expectations of customers.
• Measure and monitor customer satisfaction and take appropriate action.
• Identify the needs and expectations of interested parties that may affect customer satisfaction and take appropriate action.
• Actively manage relationships with customers to achieve sustainable performance.

The ISO 9001 standard [ISO 15] applies to all organizations regardless of size, complexity, or business model. ISO 9000 specifies requirements for a QMS, as defined in the following text box, for both internal groups and for external partners.

ISO 9001 [ISO 15] is used worldwide in a wide range of organizations. About a million certificates of conformity to ISO 9001 are issued annually in nearly 187 countries.

ISO 9001 uses the process approach, the Plan-Do-Check-Act (PDCA) approach, and a risk-based thinking approach [ISO 15]:

• – The process approach allows an organization to plan its processes and their interactions.
• – The PDCA cycle allows an organization to ensure that its processes are adequately resourced and appropriately managed and that opportunities for improvement are identified and implemented.
• – The risk-based thinking approach allows an organization to determine the factors that may cause deviation from its processes and its QMS in relation to expected results, to implement preventive measures in order to limit negative effects and exploit opportunities when they arise.

The ISO 9001 [ISO 15] standard indicates that an organization can use a complementary improvement approach to that of the continuous improvement approach such as a drastic change, an innovation or a reorganization.

Figure 4.4 shows the elements of a process and the interaction between these elements. Note that the figure shows the links between processes with “Input sources” (e.g., upstream process) and “Target outputs” (e.g., downstream processes) to illustrate that a process does not work in isolation in an organization. The organization must master not only the elements of a process, but also the interactions and interdependencies between them, in order to improve its overall performance, such as reduced rework as presented in the section on the cost of quality.

Also note that one of the output elements in Figure 4.4 is a service. ISO 9000 defines a service as follows: output of an organization with at least one activity necessarily performed between the organization and the customer. For example, in software development, the organization that developed software for its client could offer implementation services and maintenance of the software.

ISO 9001 describes the elements of the PDCA cycle as follows [ISO 15]:

• – Plan: establish the objectives of the system, processes and resources to deliver results in accordance with customer requirements and policies of the organization, identify and address risks and opportunities;
• – Do: implement what has been planned;
• – Check: monitor and measure (if applicable) processes and the products and services obtained against policies, objectives, requirements and planned activities, and report the results;
• – Act: take actions to improve performance, as needed.

The requirements of ISO 9001 are presented in the following 10 items:

1. Scope
2. Normative references
3. Terms and definitions
4. Context of the organization
5. Leadership
6. Planning
7. Support
8. Implementation of operational activities
9. Performance evaluation
10. Improvement

We have only briefly described the main articles of the standard. In regards to article 4, ISO 9001 [ISO 15] requires the organization to determine the pertinent external and internal issues. These issues, as for the needs and expectations of the interested parties, the QMS and its scope, have a great influence on the ability to achieve the expected results of its QMS. Article 5 of the standard explains that management must demonstrate leadership and commitment to the QMS and that the customer must ensure the establishment of the quality policy of the organization and must ensure that the responsibilities and authorities of roles have been assigned, communicated, and understood. Article 6 describes the actions to be implemented in regards to the risks and opportunities, the objectives of the QMS, the planning of actions to achieve these objectives, and the planning of changes to the QMS. Article 7 presents the requirements for resources for the establishment of the QMS, its implementation, updating, and the continuous improvement of the QMS: human resources, infrastructure, resources for monitoring, measurement, traceability, the knowledge and skills required of personnel, the needs of internal and external communication and documentation (e.g., creating, updating). Article 8 describes in detail the implementation of operational activities of the organization such as the process planning, the determination and review of the requirements of its products and services, design and development, products and services processes of its external suppliers, production and release of its product and services, and the identification of non-compliant output elements compared with requirements. Article 9 describes the requirements for performance evaluation, such as monitoring the extent of analysis and evaluation, customer satisfaction, internal audits, and management reviews of the QMS. Finally, article 10 provides the requirements for improvement such as improving customer satisfaction, non-compliance and corrective actions, and continuous improvement of the QMS.

The ISO 19011 standard [ISO 11g], which establishes guidelines for internal and external audits of QMSs, will be presented in the chapter on audits. ISO 9004 [ISO 09a], which shows how to increase the efficiency and effectiveness of a QMS, will be presented in the chapter concerning policies and processes.

4.3.2 ISO/IEC 90003 Standard

The ISO/IEC 90003 [ISO 14] standard provides guidelines for the application of the ISO 9001 standard to computer software. It provides organizations with instructions for acquiring, supplying, developing, using and maintaining software. The following text box is part of the introduction to the ISO 90003 standard.

An example, Section 7.3.5 of the ISO 9001 standard is provided below as it is presented in the ISO 90003 standard.

The explanatory text from the ISO 90003 standard for Section 7.3.5 is shown in the following text box.

The text of the ISO 90003 standard correctly explains what a software audit is for the organization wishing to set up a QMS as well as for the QMS auditor.

The next section discusses the ISO/IEC/IEEE 12207 [ISO 17] standard for software engineering, which describes all the software life cycle processes (from cradle to grave).

4.4.1 Limitations of the ISO 12207 Standard

The ISO 12207 standard describes the limitations to its use as follows (adapted from [ISO 17]):

• – It does not prescribe a specific system or software life cycle model, development methodology, method, model, or technique.

• The users of this document are responsible for selecting a life cycle model for the project and mapping the processes, activities, and tasks in this document into that model. The parties are also responsible for selecting and applying appropriate methodologies, methods, models, and techniques suitable for the project.

• – It does not establish a management system or require the use of any management system standard.

• It is intended to be compatible with the QMS specified by ISO 9001, the service management system specified by ISO/IEC 20000-1 [ISO 11h], and the information security management system (ISMS) specified by ISO/IEC 27000.

• – It does not detail information items in terms of name, format, explicit content, and recording media.

• ISO/IEC/IEEE 15289 addresses the content for life cycle process information items (documentation).

4.6.1 Activities and Tasks of SQA

IEEE 730 [IEE 14] describes what must be done by a project; it assumes that the organization has already implemented SQA processes before the start of a project. The activities and tasks of the IEEE 730 are presented next.

The standard includes a clause that describes what is meant by compliance. The following text box defines this term.

Compliance with all requirements of IEEE 730 [IEE 14] can be imposed by a client in an agreement (e.g., a contract) with the organization that will develop software. However, a given project may not need to use all the activities of the standard. The implementation of the standard implies the selection of a set of activities adapted to a project. For any activity or task that will not be performed, the standard requires that the SQAP describes them as not applicable and include a justification as to why the activity or task will not be performed. In order to improve, an organization can choose to gradually implement the activities and tasks of the IEEE 730.

Figure 4.6 shows the links between project requirements and artifacts produced during a project. The figure shows two categories of compliance: process assurance and product assurance. The figure also describes the transitive relationships for compliance: if process requirements are consistent with the contract and if the process and project plans meet the process requirements, then the project process and plans comply with the contract. This simplifies the work of the SQA as each artifact of the project does not have to be checked against the contract. Each artifact must be verified with respect to its immediate predecessor.

The IEEE 730 [IEE 14] does not require that the activities be performed by any unit of the organization (e.g., an SQA department); it requires that responsibilities are assigned to the SQA function with the resources needed to perform the SQA activities described by the standard.

A basic principle of the IEEE 730 is to first understand the risks of the software product to ensure that the SQA activities are appropriate for the risks of the product. This means that the extent and depth of SQA activities that will be defined in the SQAP are determined by the risk associated with the software product.

4.6.1.1 SQA Process Implementation Activities

These activities aim to develop a strategy for conducting SQA, planning, and executing the activities and producing and maintaining the evidence. The six SQA process implementation activities are [IEE 14]:

• – Establish the SQA processes to define and establish documented SQA processes that exist independently of the organization's projects.
• – Coordinate with related software processes to coordinate activities and SQA tasks with other software processes such as verification and validation, reviews, audits, and other processes of ISO 12207 [ISO 17] that are relevant to the achievement of project objectives.
• – Document SQA planning to document the activities, tasks, and results that are appropriate for the risks of a specific project. Planning SQA also includes adapting generic processes to the specific needs and risks of a project. The result of this planning is documented in the SQAP. Figure 4.7 shows the contents of the SQAP. There are 13 tasks associated to this activity, we have only listed the main tasks of this activity:

• Use this standard and appendix C to help prepare an SQAP that is appropriate for the project, which meets the needs of all stakeholders and which is appropriate for the risks of the product.
• Review and update the SQA level as the project evolves.
• Present information on the status of the project to management in the agreed manner.
• Estimate the resources of the SQA function (including effort, schedule, people, required skills, tools and equipment) needed to perform the SQA activities, tasks, and outcomes.
• Analyze product risks, standards, and assumptions that could impact quality and identify specific SQA activities, tasks, and specific outcomes that could help determine whether these risks are mitigated effectively.
• Analyze the project and adapt SQA activities accordingly so that they are commensurate with the risks.
• Define specific measures for the evaluation of projects, software quality, performance of SQA function compared with quality objectives of the project and those of the quality management of the organization.
• Identify and track changes to the project that require additional planning from SQA function including changes to the requirements, resources, schedule, project scope, priorities, and product risk.
• If process areas or activities are not adequately addressed by the quality management function of the organization, or if the organization does not have a quality management function, these process areas can be documented in the SQAP.

• – Execute the SQAP in coordination with the project manager, the project team, and organizational quality management.
• – Manage SQA records to create records of the activities, tasks and results of SQA; manage and control them and make them available to stakeholders.
• – Evaluate organizational independence and objectivity to determine if those responsible for SQA occupy a position in the organization that allows them to have direct communication with the organization's management.

We will not describe the remaining 10 activities of IEEE 730 listed below in detail here since they will be described in other chapters of this book.

4.7.1 Process Maturity Models of the SEI

The SEI developed several Capability Maturity Models (CMM^®). In this section, we will present the CMMI model used to develop products (e.g., software, system) and services.

The CMMI for Development (CMMI-DEV) covers a broader area than its predecessor by adding other practices, such as systems engineering, and the development of integrated processes and products. It was formed from the following model practices: version 2.0 of the SW-CMM, the “Systems Engineering Capability Model” of the Electronic Industries Alliance [EIA 98] and version 0.98 of the “Integrated Product Development CMM” model.

The CMMI model was developed as two versions: an initial staged version and a continuous version, which is the first CMM model for systems engineering (Systems Engineering CMM, SE-CMM). The CMMI is available in several languages: Germany, English, Traditional Chinese, French, Spanish, Japanese, and Portuguese.

Just like the SW-CMM model, the objective of this model is to encourage organizations to check and continuously improve their development project process and evaluate their level of maturity on a five-level scale as proposed by the staged CMMI model.

Two other CMMI models were developed based on architecture, namely the CMMI for Services (CMMI-SVC) [SEI 10b] and the CMMI for Acquisition (CMMI-ACQ) [SEI 10c]. The CMMI-SVC model provides guidelines for organizations that provide services either internally or externally, whereas the CMMI-ACQ model provides guidelines for organizations that purchase products or services. All three CMMI models use 16 common process areas.

For each level of maturity, a set of process areas are defined. Each area encompasses a set of requirements that must be met. These requirements define which elements must be produced rather than how they are produced, thereby allowing the organization implementing the process to choose its own life cycle model, its design methodologies, its development tools, its programming languages, and its documentation standard. This approach enables a wide range of companies to implement this model while having processes that are compatible with other standards.

Table 4.3 describes the maturity levels as well as the process areas for each maturity level in the CMMI-DEV model.

Figure 4.8 presents an overview of the CMMI model structure. Each process area has generic and specific goals, practices, and sub-practices. The specific goals, practices, and sub-practices are “specific” to a process area, such as Requirements Management, although the generic goals, practices, and sub-practices apply to all process areas for a given maturity level. Each process area also includes explanatory notes and references for other process areas. As indicated in the legend for Figure 4.8, model components are required, expected, or informative. The SEI defines these three components in the following way [CHR 08]:

• – Required components describe what an organization must achieve to satisfy a process area;
• – Expected components describe what an organization can implement to achieve a required component. Expected components guide those who implement improvements or perform evaluations;
• – Informative components provide details that help organizations initiate the process by specifying the way to understand required and expected components.

The concept of CMM model characteristics was transferred to the CMMI: these are generic goals and practices. For level 2 of the staged representation of the CMMI model, the 10 generic practices are [SEI 10a]:

1. Establish an organizational policy: establish and maintain an organizational policy for planning and performing the process.
2. Plan the process: establish and maintain the plan for performing the process.
3. Provide resources: provide adequate resources for performing the process, developing the work products, and providing the services of the process.
4. Assign responsibility: assign responsibility and authority for performing the process, developing the work products, and providing the services of the process.
5. Train people: train the people performing or supporting the process as needed.
6. Control work products: place selected work products of the process under appropriate levels of control.
7. Identify and involve relevant stakeholders: identify and involve the relevant stakeholders of the process as planned.
8. Monitor and control the process: monitor and control the process against the plan for performing the process and take appropriate corrective action.
9. Objectively evaluate adherence: objectively evaluate adherence of the process and selected work products against the process description, standards, and procedures, and address non-compliance.
10. Review status with higher level management: review the activities, status, and results of the process with higher level management and resolve issues.

Figure 4.9 presents the process areas associated with maturity levels in the staged version of the CMMI development model. The path flow through the CMMI model is carried out gradually. To meet the requirements for a process area, the organization must satisfy all the goals of the given process area. In the same way, in order to move up between maturity levels, all goals must be satisfied for the process areas in question, as well as for all the goals of the process areas of the lower levels of process maturity.

This section presented a maturity model that should help software development organizations: “Given that software maintenance is a specific field of software engineering, it is therefore necessary to focus on the processes and methodologies that take into account the specific characteristics of software maintenance” [BAS 96]. The next section introduces a maturity model designed to improve the software maintenance process.

4.7.2 Software Maintenance Maturity Model (S^3m)

The software maintenance maturity model S^3m (available at www.s3m.ca) proposes a structured approach to address a number of issues that arise in the context of the daily maintenance of software [APR 08]:

• – software maintenance is a discipline mainly derived from industrial practices;
• – a relatively large gap exists between the academic literature and the industrial practices;
• – validation of improvement proposals made by consultants;
• – many inconsistencies in terms that are often poorly defined with regard to the different proposals, approaches, presentations, and publications in maintenance;
• – scarcity and difficulty in acquiring/adapting a specific methodology for software maintenance;
• – there is no universal consensus;
• – publications that are often optimistic (i.e., proposing unproven theories and miracle tools);
• – problems that take on their full meaning when software and organizations reach a certain size.

Figure 4.10 illustrates the structure of the S^3m model.

Some authors have studied the differences and similarities between software development and maintenance activities. The maintenance organizational unit is structured to meet quite different challenges, such as randomly occurring daily events and requests from users, while providing continued service on the software for which it is responsible.

When we refer to software maintenance in the S^3m model, we are specifically considering the operational support activities, corrections and software evolution that occur daily. The characteristics that are specific to software maintenance are [ABR 93]:

• – Modification requests (MRs) come in on an irregular basis and cannot be accounted for individually in the annual budget planning process.
• – MRs are reviewed and prioritized by the developer, often at the operational level. Most do not require senior management involvement.
• – The maintenance workload is not managed using project management techniques but rather by using queue management techniques and sometimes supported by Helpdesk software.
• – The size and complexity of maintenance requests is such that it can usually be handled by one or two maintainers.
• – The maintenance workload is user-services oriented, for the short term, to ensure that the operating software is running smoothly on a daily basis.
• – Priorities can be shifted around at any time (sometimes hourly), and problem reports requiring that corrections be made immediately to the software in production take priority over any other work in progress.

Additionally, in many organizations, maintenance is often performed by different organizational groups than the software development groups.

The software maintenance maturity model:

• – relates to the daily software maintenance activities rather than large-scale activities that should be managed using proven techniques in project management—in these specific large maintenance projects, it is the CMMI model that should be used;
• – is based on the customers’ perspective;
• – is relevant for the maintenance of application software (a) developed and maintained internally, (b) configured and maintained internally or with a subcontractor's help, and (c) outsourced to an external supplier;
• – provides references and details for each exemplary practice;
• – offers an improvement approach based on road maps and maintenance categories;
• – covers the software maintenance life cycle standards described in ISO 12207;
• – covers most ISO 9001 characteristics and practices and relevant parts of the CMMI-DEV that apply to small maintenance;
• – integrates references to additional software maintenance practices documented in other software and quality improvement models like ITIL, that we will cover in the next section.

The previous sections described models for improving software development and maintenance processes. The next section considers the references and standards for improving processes for IT operations and infrastructure (also known as IT services).

4.7.3 ITIL Framework and ISO/IEC 20000

The ITIL framework was created in Great Britain based on good management practices for computer services. It consists of a set of five books providing advice and recommendations in order to offer quality service to IT service users. It should be pointed out that IT services are typically responsible for ensuring that the infrastructures are effective and running (backup copies, recovery, computer administration, telecommunications, and production data). The ITIL books systematically cover all aspects of the computer operations in a company while at the same time not claiming to have all the answers.

The list of guides illustrated in Figure 4.11 is:

• – strategy;
• – design;
• – transition;
• – operation;
• – continuous improvement.

Support processes described in the ITIL are focused on daily operations. Their main goals are to resolve the problems when they arise or to prevent them from happening when there is a change in the computer environment or in the way the organization does things.

ITIL describes the support center function and the following five processes:

• – Incident management
• – Problem management
• – Configuration management
• – Change management
• – Commissioning management

Service operation processes focus more on longer term management than support processes do. The main objective is to ensure that the IT infrastructure meets the business requirements of the organization. ITIL describes the following five processes for service operation:

• – Service level management
• – Financial management of IT services
• – Capacity management
• – IT service continuity management
• – Availability management

ITIL is therefore a compendium of good practices and a compilation of descriptions of business processes that allow us to benefit from the experience of many organizations. It does not contain any implementation guidelines. ITIL is based on the sharing of operational experiences in IT.

Given the major recognition of ITIL worldwide, an international standard based on ITIL came into being: ISO/IEC 20000-1 [ISO 11h]. The principles of ITIL were successfully conveyed to many companies of all sizes and from all sectors of activity. The three main objectives are:

• – to align computer services with the current and future needs of the company and its clients;
• – to improve the quality of computer services provided;
• – to reduce the long-term cost of service provision.

Just like the CMMI and S^3m references, ITIL is a process-based approach founded on the principle of continuous improvement of the Deming Cycle: PDCA.

In the 1980s, the British government wanted to improve efficacy and reduce IT costs in public companies. Initially this meant developing a universal method that could be applied to all public organizations. The project, which was initiated in 1986, really took off in 1988. The conclusions of the study quickly led to the definition of general principles and the development of best practices. These results were also applicable to the private sector. Work groups were struck, bringing together operational managers, independent experts, consultants, and trainers from public organizations and from the private sector. Private companies that participated and accepted to have their work methods studied by competing companies ensured the objectivity of the conclusions drawn, and at the same time, prevented any risk of being influenced by proprietary technologies or systems. ITIL places service at the center of information systems management. This principle was highly innovative in 1980 and promoted the notion of the client of information systems management. In 1989, 10 books were published in a first version of ITIL. The areas covered by this version were the processes of Service Support and Service Delivery. Over 30 books have been produced since, but an update between 2000 and 2011 has reduced the number to five books today.

4.7.3.2 ISO/IEC 20000 Standard

The ISO/IEC 20000 standard is the first ISO standard dedicated to managing IT services. Inspired by the former British standard BSI 15000, which is based on ITIL, it was initially published on November 10, 2005, by the ISO. The main contribution of ISO 20000 is an international consensus on ITIL content.

As we show in Figure 4.12, this standard has two parts. The first part, ISO 20000-1 [ISO 11h] represents the certifiable part of the standard. It defines the IT service management requirements. These requirements are:

• – specifications for service management;
• – planning and implementing service management;
• – planning and implementation of new services;
• – service delivery process;
• – relationship management;
• – resolution management;
• – control management;
• – production management.

The next section introduces the reference for exemplary practices in IT governance. This guide is used by internal auditors specialized in IT in order to evaluate the quality of controls set up in an organization.

4.7.4 CobiT Process

CobiT [COB 12] is a repository of best practices for IT governance established by ISACA (IT auditors). Oriented on auditing and governance assessment information systems, CobiT provides risk analysis and assessment of the effectiveness of internal controls. This repository of best practices tries to cover several concepts such as the analysis of business processes, technical aspects of IT, control needs in information technology, and risk management.

The CobiT process ensures that technological resources are well aligned with the company's fundamental objectives. It helps to achieve the right level of control to exercise on IT. This process is harmonized with the ITIL reference, the PMBOK^® Guide from the Project Management Institute [PMI 13] as well as the ISO 27001 and ISO 27002 standards.

CobiT version 5 covers 34 generic guidance processes and 318 control objectives divided into four process domains:

• – planning and organization;
• – acquisition and implementation;
• – distribution and support;
• – monitoring and surveillance.

The framework consists of checklists covering the four process domains, with 34 general control objectives and 302 detailed control objectives. The “planning and organization” domain has eleven goals covering everything related to strategy and tactics. These objectives identify means for IT to contribute most effectively to the achievement of the business goals of the company. The “acquisition and implementation” domain covers six goals for the achievement of the IT strategy: the identification, acquisition, development and implementation of IT solutions and their integration into business processes. The “distribution and support” domain considers thirteen goals, grouping the delivery of IT services required, that is, the operation, security, emergency plans, and training. The “monitoring and surveillance” domain has four objectives that allow management to assess the quality and compliance of process control requirements. The implementation tools include a presentation of cases where companies have implemented processes quickly and successfully using the CobiT methodology. These examples are therefore closely linked to business objectives while focusing particular attention on IT. This will reassure management, standardize work processes, and guarantee the security and controls of IT services.

The CobiT management section of the guide focuses on several aspects: the performance measurement and control of the IT profile and awareness of technological risks. This document provides the key indicator objectives, the key performance indicators, key success factors, and the maturity model. The maturity model evaluates the achievement of one or more general objectives of the process on a scale of 0–5:

• – 0: non-existent;
• – 1: existing but unorganized (initialized on an ad hoc basis);
• – 2: renewable;
• – 3: defined;
• – 4: managed;
• – 5: optimized.

The audit guideline allows an organization to evaluate and justify the risks and shortcomings of general and detailed objectives. Then, once this step is completed, corrective actions can be implemented. This audit guideline respects four principles: developing an in-depth understanding, evaluating controls, verifying compliance, and justifying the risk of not attaining the control objectives.

The next section presents information security standards.

4.7.5 ISO/IEC 27000 Family of Standards for Information Security

The ISO 17799 standard [ISO 05d] initially published in December 2000 by ISO introduces a code of good practices for information security management. The second edition of this standard was published in June 2005, and then obtained a new reference number in July 2007. This standard is now known as ISO/IEC 27002 [ISO 05c].

The ISO 27002 standard comprises 133 practical steps to be used by anyone in charge of implementing or maintaining an ISMS. Information security is defined within the standard as the “preservation of confidentiality, integrity and availability of information.”

This standard is not mandatory for companies. However, it may be required under a contract: a service provider could then agree to respect the standardized practices with a client.

The ISO 27002 standard is made up of 11 main sections, which cover security management as well as its strategic and operational aspects. Each section makes up a chapter of the standard:

• – security policy;
• – information security organization;
• – asset management;
• – security related to human resources;
• – physical and environmental security;
• – communications and operations management;
• – access control;
• – acquisition, development, and maintenance of information systems;
• – incident management related to information security;
• – activity continuity management;
• – legal and regulatory compliance.

The chapters in the standard specify the objectives to reach and list practices that allow for the fulfillment of these objectives. The standard does not provide detailed practices, since each organization is supposed to carry out an evaluation of its own risks in order to determine its needs before choosing the practices that are appropriate in each of the possible cases.

This standard is based on the ISO 27000 family of standards as shown in the Figure 4.13.

Note that the ISO 20000 standard, based on ITIL, connects directly to the ISO 27001 guideline concerning information security.

The next section presents the ISO/IEC 29110 standard and guides that have been developed specifically for small organizations that develop software or systems.

4.7.6 ISO/IEC 29110 Standards and Guides for Very Small Entities

Worldwide there are numerous very small entities (VSEs), namely enterprises, organizations (e.g., public organizations and not-for profit organizations), departments or projects with up to 25 people. For example, in Europe more than 92.2% of companies have between 1 and 9 employees and only 6.5% of firms have between 10 and 49 employees [MOL 13]. In the US, about 95% of companies have 10 employees or less [USC 16]. In Canada, nearly 80% of software companies in the Montreal region have 25 or fewer employees, and 50% of companies have 10 employees or less [GAU 04]. In Brazil, small businesses represent approximately 70% of the total number of companies [ANA 04]. Lastly, in Northern Ireland [MCF 03], a survey showed that 66% of organizations employ fewer than 20 people.

Unfortunately, according to surveys and studies carried out, it is clear that the ISO standards were not developed for VSEs, that they do not meet their needs, and therefore they are difficult to apply in such contexts. In order to help VSEs, an international standardization project developed a set of ISO/IEC 29110 standards and guides [ISO 16f]. ISO 29110 standards were developed by taking relevant information for VSEs from existing standards, such as ISO 12207 and ISO 15289. This “assemblage” is called a profile. We will briefly introduce ISO 15289 at the end of this chapter.

In 2005, Professor Laporte was appointed as project editor of the ISO 29110 standards and guides. Since 2005, the working group has developed a set of ISO 29110 standards and guides to help VSEs that develop software, systems involving hardware and software or who provide maintenance services to their clients. The interest of several countries was such that several ISO 29110 documents have been translated into Czech, French, German, Japanese, Portuguese, Spanish. Some countries, such as Brazil, Japan and Peru, have adopted ISO 29110 as a national standard.

4.7.6.2 ISO 29110 Software Basic Profile

The software basic profile is made up of two processes: the project management process and the software implementation process. The goal of the project management process is to establish a systematic way to carry out the tasks of implementing the software project which will meet the project objectives with regard to quality, schedule, and cost. The purpose of the software implementation process is the systematic performance of the analysis, design, construction, integration, and tests for new or modified software products according to the specified requirements.

Figure 4.14 shows the project management process and the software implementation process and their activities. Activities consist of tasks. The input to the project management process is a document entitled “Statement of Work (SOW),” the output of the implementation process is the set of deliverables (e.g., documentation, code) that are defined early in the project and called software configuration.

The management and engineering guide of the ISO 29110 software Basic profile is presented next. Remember that a standard describes “what to do”, while management and engineering guides describe “how to do it”.

4.7.6.2.2 Management Processes for the Software Basic Profile

The goal of the project management process is to establish a systematic way to carry out the tasks of implementing the software project which will meet the project objectives with regard to quality, schedule and cost.

The management process, as illustrated in Figure 4.15, uses the SOW to develop the project plan. Assessment and control tasks for this process will use the project plan to assess project progress. Steps are taken, if necessary, either to eliminate gaps with the project plan or to incorporate changes into the plan. Project closure activities provide the deliverables that are produced during the implementation process to the client for their approval so as to officially close the project. A project repository is established to save work products and control their versions during the project.

The project management process includes four activities that are broken down into 26 tasks.

Software Implementation Process for the Basic Profile

The purpose of the software implementation process is the systematic performance of the analysis, design, construction, integration, and tests for new or modified software products according to the specified requirements. Carrying out the implementation process, as illustrated in Figure 4.16, is controlled by the project plan. The project plan guides the analysis of software requirements, detailed architecture and design, construction and integration of software, tests and delivery activities for the deliverables. To eliminate the defects in a product, verification and validation activities as well as test tasks are included in this process's activities. The client provides a SOW as input to the project management process and receives the set of deliverables initially identified in the project plan as the result of the implementation process.

The implementation process, as shown in Figure 4.16, includes six activities that are broken down into 41 tasks. To illustrate how management and engineering guides facilitate the implementation of ISO 29110 in a VSE, Table 4.6 provides an example of the requirements analysis task (SI.2.4-Validate and obtain approval of the requirements specification). The left column lists the roles involved in this task: the Analyst (AN) and the Customer (CUS). A second column describes the task as well as some additional information to help execute the task and a third column describes the input work product required for task execution as well as its status (e.g., verified). The last column shows the output work products and their status resulting from the execution of the task.

Roles	Tasks	Input workproducts	Output workproducts
CUSAN	SI.2.4 Validate and obtain approval of the Requirements Specifications Validate that requirements specification satisfies needs and agreed upon expectations, including the user interface usability. The results found are documented in a validation results and corrections are made until the document is approved by the CUS.	Requirements Specification [verified]	Validation Results Requirements Specification [validated]

Table 4.7 shows an example of a document, a change request, and the content proposed by the ISO 29110 management and engineering guide. Note that the guide does not impose specific content by stating that a document “may,” not “shall,” include the following items, but provides information items that can be grouped. The right-hand column shows the source who requested the document. In this example, a change request is drafted by the client, the development team or by project management. We also note at the end of the description, the applicable status of this document.

Name	Description	Source
Change request	Identifies a Software, or documentation problem or desired improvement, and requests modifications. It may have the following characteristics: – Identifies purpose of change – Identifies request status – Identifies requester contact information – Impacted system(s) – Impact to operations of existing system(s) defined – Impact to associated documentation defined – Criticality of the request, date needed  The applicable statuses are: initiated, evaluated, and accepted.	Customer Project management Software implementation

4.7.6.3 The Development of Deployment Packages

Although the ISO working group created a management and engineering guide, many VSEs do not have the resources to readily use the two processes described. Therefore, Professor Laporte, as the ISO 29110 project editor, recommended to the delegates for Working Group 24 during a meeting in Moscow in 2007, the development of material that can be used “as is” by VSEs [LAP 08a]. He coordinated the development of a set of documents called the Deployment Package (DP), based on the management and engineering guides.

A DP is a set of artifacts that facilitate and accelerate the implementation of the ISO 29110 standard in VSEs by providing them with ready-to-use processes. The table of contents for the package is described in Table 4.8. Note that the tasks from the management and engineering guides were broken down into steps to help the VSE concretely implement the standard.

Technical description Purpose of this document Why is this topic important? Relationships with ISO/IEC 29110 Definitions Overview of processes, activities, tasks, roles, and products Description of processes, activities, tasks, steps, roles, and products Role description Product description Artifact description Template(s) Example(s) Checklist(s) Tool(s) References to other standards and models (e.g., ISO 9001, ISO/IEC 12207, CMMI) References Evaluation form

Figure 4.17 shows the DPs that have been developed for the software Basic profile.

These DPs are available for free in English, French, and Spanish on the Web (www.sqabook.org). This site also provides access to templates, checklists, and examples of the implementation of ISO 29110, such as the example provided below.

4.7.7 ISO/IEC 29110 Standards for VSEs Developing Systems

Since a large number of VSEs develop systems that include hardware and software, members of the SC7 countries mandated Working Group 24 to develop a set of documents similar to those already created for the development of software: a roadmap consisting of a set of four profiles (Entry, Basic, Intermediate, and Advanced). The system development and software development profiles are similar since the strategy was to develop the system profiles using, as the foundation, the software profiles already published.

Figure 4.18 shows the processes and activities for the systems engineering Basic profile. Since this is based on the software Basic profile, there are similarities with the software Basic profile presented above:

• – a client, called acquirer, presents a SOW for a VSE;
• – a project management process that includes similar activities as the project management process of the software Basic profile. Some tasks were added to the profile for systems engineering such as the management of the purchase of hardware components.
• – a technical process, referred to as System Definition and Realization process, has activities that are similar to the software implementation process. Several tasks were added to the systems engineering profile. It is during the execution of the activity entitled “Construction of the system” that the hardware components are purchased or manufactured by the VSE. It is also at this point that software components are developed. Next, during the system integration activity, software and hardware components are integrated, the system is verified and validated. The ISO 29110 systems engineering guide suggests that a VSE uses the software Basic profile for the development of the software components of the system.

The system and software management and engineering guides are freely available from ISO in French and English. A version in German is also available on the Web.

4.8.1 DO-178 and ED-12 Guidance for Airborne Systems

The development of DO-178 “Software Considerations in Airborne Systems and Equipment Certification,” was initiated in 1980 by the Radio Technical Commission for Aeronautics (RTCA). At the same time, the European Organisation for Civil Aviation (EUROCAE) had also developed a similar document. Later, the two organizations decided to develop a common guidance. In 1982, EUROCAE published ED-12 with technical content identical to DO-178. As stated in DO-178C, since 1992, the aviation industry and certification authorities around the world have used the considerations in DO-178B/ED-12B as an acceptable means of compliance for software approval in the certification of airborne systems and equipment. The latest version of these two documents was published in 2011 [EUR 11, RTC 11].

Their purpose is to provide guidance for the production of software for airborne systems and equipment. These systems must provide a high level of safety that complies with airworthiness requirements.

The reader may wonder why this document is called guidance and not a standard. This is the explanation extracted from DO-178 [RTC 11]: “This document recognizes that the guidance herein is not mandated by law, but represents a consensus of the aviation community. It also recognizes that alternative methods to the methods described herein may be available to the applicant. For these reasons, the use of words such as ‘shall’ and ‘must’ is avoided.”

However, DO-178 provides some text that transforms this guidance to a de facto standard for that industry [RTC 11]: “If an applicant adopts this document as a means of compliance, the applicant should satisfy all applicable objectives. This document should apply to the applicant and any of its suppliers, who are involved with any of the software life cycle processes or the outputs of those processes described herein. The applicant is responsible for oversight of all of its suppliers.”

The purpose of this guidance includes [RTC 11]:

• – objectives for software life cycle processes;
• – activities that provide a means for satisfying those objectives;
• – descriptions of evidence in the form of life cycle data that indicate that the objectives have been satisfied.

A system safety assessment determines the software level of the software components of a system. The software level may even be specified in the system requirements. The DO-178 divides software into five levels [RTC 11]:

1. Level A: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a catastrophic failure condition for the aircraft.
2. Level B: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a hazardous failure condition for the aircraft.
3. Level C: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a major failure condition for the aircraft.
4. Level D: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a minor failure condition for the aircraft.
5. Level E: Software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function with no effect on aircraft operational capability or pilot workload. If a software component is determined to be Level E and this is confirmed by the certification authority, no further guidance contained in this document applies.

4.8.2 EN 50128 Standard for Railway Applications

The EN 50128 standard describes the application domain in the following way [CEN 01]: by specifying the procedures and technical requirements applicable to the development of programmable electronic systems used in railway control and protection applications. It is meant to be used in any field having safety implications. It applies to all software used in developing and implementing railway control and protection systems, including application programming, operating systems, support tools, and micro-programming. It also focuses on the requirements applicable to the systems configured using application data.

The standard was developed for the following reasons [CEN 01]:

• – To define a process for the specification and demonstration of dependability requirements for the railway industry;
• – To foster an understanding and common approach to managing dependability;
• – To provide the railway authorities and industry with a process that allows for a coherent management of reliability, availability, maintainability, and dependability.

The EN 50128 standard introduces five software safety integrity levels (SWSIL) where each level is associated with a degree of risk when using a software system. Level 0 is assigned to software that is non-safety-related, whereas level 4 means a very high risk. A special feature of this standard is that it imposes an organizational structure on organizations that develop risky software, that is, software with safety issues. Figure 4.19 illustrates the different organizational structures based on the SWSIL.

The standard describes the sharing of roles and responsibilities of stakeholders. For level 0, there is no constraint, the designer/implementer, verifier, and validator can all be the same person.

For SWSIL levels 1 and 2, the verifier and validator can be the same person, but they cannot be the designer/implementer. However, the designer/implementer, verifier, and validator can all report through the project manager. At SWSIL levels 3 and 4, there are two acceptable arrangements:

• – The verifier and the validator can be one and the same person, but they must not also be the designer/implementer. In addition, the verifier and validator cannot report to the project manager, as the designer/implementer does, and they must have the authority to prevent a product from being released.
• – The designer/implementer, verifier and validator must all be different people. The designer/implementer and verifier can report to the project manager, whereas the validator cannot. The validator must have the authority to prevent a product from being released.

Moreover, in this standard, there are requirements about using or not using certain development techniques. The classification table has five levels, from mandatory to not recommended and appears in Table 4.9.

Table 4.10 illustrates the classification of static analysis techniques for SWSIL from 0 to 4. Here, we see the requirement for performing design reviews is “HR” for all levels of criticality.

In Table 4.11, we list requirements made as to whether or not to use certain programming languages, such as C or C++ (without restriction), for the five criticality levels.

4.8.3 ISO 13485 Standard for Medical Devices

The ISO 13485 standard focuses on QA of products, customer requirements, and various items related to the management of quality systems [ISO 16d]. This standard specifies the requirements of a QMS that can be used by an organization for design and development, production, installation, and related services for medical devices, as well as the design, development, and supply of related services. The following definition of medical device illustrates the wide spectrum of devices that could be impacted by poor quality software.

Although this standard is independent of ISO 9001, it is based upon it. Given that certain requirements of ISO 9001 were excluded from ISO 13485, organizations whose QMS comply with ISO 13485 can claim compliance with the ISO 9001 standard only if their QMSs comply with all the requirements of the ISO 9001standard. Appendix B of ISO 13485 provides correspondence between these two standards.

4.11 Further Reading

1. GLAZER H., DALTON J., ANDERSON D., KONRAD M., and SHRUM S. CMMI or Agile: Why Not Embrace Both!. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, USA, 2008, 41 p.
2. MOORE J. The Road Map to Software Engineering: A Standards-Based Guide. Wiley-IEEE Computer Society Press, Hoboken, New Jersey, USA, 2006, 440 p.
3. PFLEEGER S.L., FENTON N.E., and PAGE P. Evaluating software engineering standards. IEEE Computer, vol. 27, issue 9, 1994, pp. 71–79.