Skip to product information
1 of 11

PayPal, credit cards. Download editable-PDF and invoice in 1 second!

GB/T 20918-2007 English PDF (GBT20918-2007)

GB/T 20918-2007 English PDF (GBT20918-2007)

Regular price $245.00 USD
Regular price Sale price $245.00 USD
Sale Sold out
Shipping calculated at checkout.
Quotation: In 1-minute, 24-hr self-service. Click here GB/T 20918-2007 to get it for Purchase Approval, Bank TT...

GB/T 20918-2007: Information technology -- Software life cycle processes -- Risk management

This standard describes a process for the management of risk during software acquisition, supply, development, operations, and maintenance. It is intended that both technical and managerial personnel throughout an organization apply this standard.
GB/T 20918-2007
NATIONAL STANDARD OF THE
PEOPLE REPUBLIC OF CHINA
ICS 35.080
L 77
Information technology ?€? Software life cycle
processes ?€? Risk management
ISSUED ON: APRIL 30, 2007
IMPLEMENTED ON: JULY 1, 2007
Issued by: General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China;
Standardization Administration of the People's Republic of
China.
Table of Contents
Foreword ... 3
Introduction ... 4
1 Scope ... 6
2 Normative references ... 7
3 Terms and definitions ... 8
4 Application of this standard ... 12
5 Risk management in the software life cycle ... 13
Annex A (Informative) Risk management plan ... 25
Annex B (Informative) Risk action request ... 28
Annex C (Informative) Risk treatment plan ... 30
Bibliography ... 32
Foreword
Annexes A, B and C of this Standard are informative.
This Standard was proposed by the Ministry of Information Technology.
This Standard shall be under the jurisdiction of National Technical Committee on Information Technology of Standardization Administration of China.
The drafting organization of this Standard: China Electronics Standardization Institute. The main drafters of this Standard: Chen Jing, Han Hongqiang, Wang Wei, Yang Genxing.
Introduction
Software risk management is a key discipline for making effective decisions and communicating the results within software organizations. The purpose of risk management is to identify potential managerial and technical problems before they occur so that actions can be taken that reduce or eliminate the likelihood and/or impact of these problems should they occur. It is a critical tool for continuously determining the feasibility of project plans, for improving the search for and identification of potential problems that can affect software life cycle activities and the quality and performance of software products, and for improving the active management of software projects. By successfully implementing this risk management standard:
- Potential problems will be identified;
- The likelihood and consequences of these risks will be understood;
- The priority order in which risks should be addressed will be established; - Treatment alternatives appropriate for each potential problem above its risk threshold will be recommended;
- Appropriate treatments will be selected for risks above their thresholds; - The effectiveness of each treatment will be monitored;
- Information will be captured to improve risk management policies;
- The risk management process and procedures will be regularly evaluated and improved.
This software risk management standard supports the acquisition, supply, development, operation, and maintenance of software products and services. This standard is written for those parties who are responsible in their organization for defining, planning, implementing, or supporting software risk management. The specific characteristics of use-domain, the stage and organization of software life-cycle of software project or product will influence how the standard is applied in practice. This standard defines a continuous software risk management process applicable to all software-related engineering and management disciplines. The risk management process itself is made up of several activities and tasks that function in an iterative manner. The process defines the minimum activities of a risk management process, the risk management information required and captured, and its use in managing risk. The risk management process defined in this standard can be adapted for use at an organization level or project level, for different types and sizes of projects, for projects in different life cycle phases, and to support diverse stakeholder perspectives. It is intended that the standard will be adapted by individual organizations and projects to meet their specific situations and needs. For this reason, this standard does not specify the use of any specific risk management techniques or associated organizational structures for implementing risk management. The users of this Standard can refer to the guides of IEC Std 60812:1985, IEC Std 60025:1990 or IEC Guide 60300-3-9:1995, to choose and use different risk analysis techniques and methods. The standard implicitly supports, however, the use of tools and techniques that can make risk management a continuous process. Capturing and communicating risk-related information in electronic form to all parties involved in a project is encouraged. This Standard may be applied independently or with GB/T 8566.
When applied independently, the standard provides a complete and self-contained description of a software risk management process that may be applied throughout the software life cycle.
When applied with GB/T 8566, this risk management standard adds a process for managing risk to the existing set of software life cycle processes defined by GB/T 8566. This means the standard assumes that the activities involved in the treatment of risk follow standard GB/T 8566 management practices. Therefore, the treatment of risk will typically follow the same management actions as used.
This standard is written from the viewpoint that software risk management is an integral part of software engineering technical and managerial processes and is not performed by a separate organizational element. If for some reason the treatment of risk is required to be performed by a separate organizational element, e.g., because of the size or nature of the software project, the magnitude or number of the risks involved, or GB/T 8566 is not being followed, this standard can continue to be applied. To facilitate use with GB/T 8566, the standard is written using the vocabulary and style of GB/T 8566.
Information technology ?€? Software life cycle
processes ?€? Risk management
1 Scope
1.1 Purpose
This standard describes a process for the management of risk during software acquisition, supply, development, operations, and maintenance. It is intended that both technical and managerial personnel throughout an organization apply this standard. The purpose of this standard is to provide software suppliers, acquirers, developers, and managers with a single set of process requirements suitable for the management of a broad variety of risks. This standard does not provide detailed risk management techniques, but instead focuses on defining a process for risk management in which any of several techniques may be applied.
1.2 Field of application
This standard defines a process for the management of risk throughout the software life cycle. It is suitable for adoption by an organization for application to all appropriate projects or for use in an individual project. Although the standard is written for the management of risk in software projects, it may also be useful for the management of both system-level and organization-level risks.
This standard is written so that it may be applied in conjunction with GB/T 8566 or applied independently.
1.2.1 Application with GB/T 8566
GB/T 8566 describe standard processes for the acquisition, supply, development, operations, and maintenance of software. The standard recognizes that actively managing risk is a key success factor in the management of a software project. GB/T 8566 mentions risk and risk management in several places, but does not provide a process for risk management. This risk management standard provides that process. This standard may be used for managing organizational-level risk or project-level risk, in any domain or life cycle phase, to support the perspectives of managers, participants, and other stakeholders.
In the life cycle process framework provided by GB/T 8566, risk management is an ?€?organizational life cycle process.?€? The activities and tasks in an organizational process are the responsibility of the organization using that process. The organization therefore ensures that the process exists and functions.
When used with GB/T 8566, this standard assumes that the other management and technical processes of GB/T 8566 perform the treatment of risk. Appropriate relationships to those processes are described.
1.2.2 Application independently
This standard may be used independently of any particular software life cycle process standard. When used in this manner, the standard applies additional provisions for the treatment of risk.
1.3 Conformance
An organization or project may claim conformance to this standard by implementing a process, demonstrating through plans and performance all of the requirements (specified as mandatory by the word shall) in the activities and tasks described in Clause 5.
In those instances where this standard is applied independently of GB/T 8566, an additional set of requirements for risk treatment is provided in 5.1.4.2. 1.4 Disclaimer
This standard establishes minimum requirements for a software risk management process, activities and tasks. Implementing these requirements or the preparation of software risk management plans or software risk action requests according to this standard does not ensure an absence of software related or other risks. Conformance with this standard does not absolve any party from any social, moral, financial, or legal obligation.
2 Normative references
The provisions in following documents become the provisions of this Standard through reference in this Standard. For dated references, the subsequent amendments (excluding corrigendum) or revisions do not apply to this Standard, however, parties who reach an agreement based on this Standard are encouraged to study if the latest versions of these documents are applicable. For undated references, the latest edition of the referenced document applies.
GB/T 8566, Information technology ?€? Software life cycle processes (GB/T 8566- 2007, ISO/IEC 12207:1995, ISO/IEC 12207/Amd. 1:2002, ISO/IEC 12207/Amd. 2:2004, IDT)
GB/T 18492-2001, Information technology ?€? System and software integrity levels (idt ISO/IEC 15026:1998)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply. 3.1
consequence
An outcome of an event.
NOTE 1: There can be more than one consequence from one event.
NOTE 2: Consequences can range from positive to negative. However, consequences are always negative for safety aspects.
NOTE 3: Consequences can be expressed qualitatively or quantitatively.
3.2
event
The occurrence of a particular set of circumstances.
NOTE 1: The event can be certain or uncertain.
NOTE 2: The event can be a single occurrence or a series of occurrences. NOTE 3: The probability associated with the event can be estimated for a given period of time. 3.3
interested party
An individual or a group who is interested in the performance or success of the project or product. For example: customers, owners, members in an organization, suppliers, bankers, cooperative partners and clubs.
NOTE: A group may include an organization, a part of an organization or multiple organizations. 3.4
probability
The extent to which an event is likely to occur
NOTE 1: ISO 3534-1:1993, definition 1.1, gives the mathematical definition of probability as ?€?a real number in the scale 0 to 1 attached to a random event. It can be related to a long-run relative frequency of occurrence or to a degree of belief that an event will occur. For a high degree of belief, the probability is near 1.?€?
NOTE 2: Frequency rather than probability may be used in describing risk. NOTE 3: Degrees of belief about probability can be chosen as classes or ranks, such as - rare/unlikely/moderate/likely/almost certain, or
- incredible/improbable/remote/occasional/probable/frequent.
3.5
project risk profile
A project's current and historical risk-related information; a compendium or aggregate of all of the individual risk profiles in a project.
NOTE: The project risk profile information includes the risk management context, along with the chronological record of risks and their individual risk profiles, priority ordering, risk-related measures, treatment status, contingency plans, and risk action requests. A project risk profile consists of a collection of the risk profiles of all the individual risks, which in turn includes the current and historical risk states. See risk profile and risk state.
3.6
risk
The combination of the probability of an event and its consequence.
NOTE 1: The term ?€?risk?€? is generally used only when there is at least the possibility of negative consequences.
NOTE 2: In some situations, risk arises from the possibility of deviation from the expected outcome or event.
NOTE 3: See ISO/IEC Guide 51 for issues related to safety.
3.7
risk acceptance
The decision to accept a risk.
NOTE: Risk acceptance depends on risk criteria.
3.8
risk action request
The recommended treatment alternatives and supporting information for one or more risks determined to be above a risk threshold.
3.9
risk category
A class or type of risk (e.g., technical, legal, organizational, safety, economic, engineering, cost, schedule).
3.10
risk criteria
The terms of reference by which the significance of risk is assessed.
NOTE: Risk criteria can include associated cost and benefits, legal and statutory requirements, socio-economic and environmental aspects, the concerns of stakeholders, priorities and other inputs to the assessment.
3.11
risk exposure
The potential loss presented to an individual, project, or organization by a risk; a function of the probability that the risk will occur and the magnitude of the consequences of its occurrence.
NOTE: Risk exposure is commonly defined as the product of a probability and the magnitude of a consequence, i.e., an expected value. This risk management standard takes a broader view that includes qualitative expressions of risk exposure.
3.12
risk management plan
A description of how the elements and resources of the risk management process will be implemented within an organization or project.
3.13
risk management process
A continuous process for systematically identifying, analyzing, treating, and monitoring risk throughout the life cycle of a product or service.
3.14
risk management system
Set of elements of an organization's management system concerned with managing risk.
NOTE 1: Management system elements can include strategic planning, decision making, and other processes for dealing with risk.
NOTE 2: The culture of an organization is reflected in its risk management system. 3.15
risk profile
A chronological record of a risk?€?s current and historical risk state information. 3.16
risk state
The current project risk information relating to an individual risk.
NOTE: The information concerning an individual risk may include the current description, causes, probability, consequences, estimation scales, confidence of the estimates, treatment, threshold, and an estimate of when the risk will reach its threshold.
3.17
risk threshold
A condition that triggers some stakeholder action.
NOTE: Different risk thresholds may be defined for each risk, risk category or combination of risks based upon differing risk criteria.
3.18
risk treatment
The process of selection and implementation of measures to modify risk. NOTE 1: The term ?€?risk treatment?€? is sometimes used for the measures themselves. NOTE 2: Risk treatment measures can include avoiding, optimizing, transferring or retaining risk.
3.19
source
An item or activity having a potential for a consequence.
NOTE: In the context of safety, source is a hazard (refer to ISO/IEC Guide 51:1999). 3.20
stakeholder
Any individual, group or organization that can affect, be affected by, or perceive itself to be affected by, a risk.
NOTE 1: The decision-maker is also a stakeholder.
NOTE 2: The term ?€?stakeholder?€? includes but has a broader meaning than interested party (which is defined in ISO 9000:2000).
4 Application of this standard
To facilitate use with GB/T 8566, this standard is written using many of the same conventions for process descriptions of GB/T 8566. The risk management life cycle process discussed herein is divided into a set of activities; and the requirements of each activity are specified in a set of tasks. Second-level subclauses (x.x) denote processes, third-level subclauses (x.x.x) denote activities, and fourth-level subclauses (x.x.x.x) denote tasks.
In the life cycle process framework provided by GB/T 8566, risk management is an ?€?organizational life cycle process.?€? The activities and tasks in an organizational life cycle process are the responsibility of the organization using that process. The organization ensures that the process exists and functions.
This software risk management standard supports the acquisition, supply, development, operation, and maintenance of software products and services. Application of this standard does not require any particular software life cycle process model.
Software risk management is most effective when used along with organizational risk management processes. The processes, activities, and tasks of this risk management standard should be integrated with other organization risk management practices and systems. If the organizational risk management processes do not exist, this standard may be useful as a guide for building them.
Further, while application of the standard focuses on software risks, the process should be integrated and coordinated with an organization?€?s problem management approaches, e.g., in the event that a contingency plan must be implemented. The risk treatment activity should be managed in the same manner as other project management activities.
5 Risk management in the software life cycle
5.0 Purpose of risk management
The purpose of the risk management is to identify and mitigate the risks continuously. As a result of successful implementation of risk management:
a) The scope of risk management to be performed will be determined.
b) Appropriate risk management strategies will be defined and implemented. c) Risks will be identified in a strategy and as they develop during the conduct of the project.
d) The risks will be analyzed, and the priority in which to apply resources to monitor these risks will be determined.
e) Risk measures will be defined, applied, and assessed to determine changes in the status of risk and the progress of the monitoring activities.
f) Appropriate action will be taken to reduce or avoid the impact of risk. 5.1 Risk management process
The risk management process is a continuous process for systematically addressing risk throughout the life cycle of a product or service.
This process consists of the following activities:
a) Plan and implement risk management;
b) Manage the project risk profile;
c) Perform risk analysis;
d) Perform risk monitoring;
e) Perform risk treatment;
f) Evaluate the risk management process.
The risk management process is illustrated in Figure 1. Note that the performance of risk treatment is assumed to be part of general technical and managerial processes. Figure 1 ?€? Risk management process model
The numbers in the discussion below refer to the appropriate box in Figure 1. Managerial and technical processes involving the stakeholders define the information requirements (i.e., th...

View full details