GB/T 20918-2007 PDF English
US$245.00 · In stock · Download in 9 secondsGB/T 20918-2007: Information technology - Software life cycle processes - Risk management Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See step-by-step procedureStatus: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivery | Name of Chinese Standard | Status |
| GB/T 20918-2007 | English | 245 |
Add to Cart
|
0-9 seconds. Auto-delivery
|
Information technology - Software life cycle processes - Risk management
| Valid |
Excerpted PDFs (Download full copy in 9 seconds upon purchase)PDF Preview: GB/T 20918-2007
GB/T 20918-2007: Information technology - Software life cycle processes - Risk management---This is an excerpt. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.), auto-downloaded/delivered in 9 seconds, can be purchased online: https://www.ChineseStandard.net/PDF.aspx/GBT20918-2007
NATIONAL STANDARD OF THE
PEOPLE’S 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., the information the stakeholders require to make informed decisions
involving risks) the risk management process must support. These information
requirements are passed to both the “plan and implement risk management” and the
“manage the project risk profile” activities. In the “plan and implement risk management”
activity , the policies regarding the general guidelines under which risk management
will be conducted, the procedures to be used, the specific techniques to be applied,
and so forth, are defined.
In the “manage the project risk profile” activity , the current and historical risk
management context and risk state information are captured. The project risk profile
includes the sum total of all the individual risk profiles (i.e., the current and historical
risk information concerning an individual risk), which, in turn, includes all the risk states.
Management decisions
Feedback Technical and management
processes
Perform risk
treatment Project risk profile and risk action requests
Perform risk
analysis
Manage the
project risk
profile
Plan and
implement risk
management
Perform risk
monitoring
Evaluate the risk
management process
Project risk profile
Improvement actions
The project risk profile information is continually updated and maintained through the
“perform risk analysis” activity , which identifies the risks, determines their likelihood
and consequences, determines their risk exposures, and prepares risk action requests
recommending treatment for risks determined to be above their risk threshold(s).
Treatment recommendations, along with the status of other risks and their treatment
status, are sent to management for review . Management decides what risk
treatment is implemented for any risk found to be unacceptable. Risk treatment plans
are created for risks that require treatment. These plans are coordinated with other
management plans and other ongoing activities.
All risks are continually monitored until they no longer need to be tracked during the
“perform risk monitoring” activity . In addition, new risks and sources are sought out.
Periodic evaluation of the risk management process is required to ensure its
effectiveness. During the “evaluate the risk management process” activity ,
information, including user and other feedback, is captured for improving the process
or for improving the organization’s or project’s ability to manage risk. Improvements
defined as a result of evaluation are implemented in the “plan and implement risk
management” activity .
The software risk management process is applied continuously throughout the product
life cycle. However, activities and tasks of the risk management process interact with
the individual risks in an iterative manner once the risk management process begins.
For example, in the perform risk analysis activity , a risk may be re-estimated several
times during the performance of risk evaluation due to an increase in knowledge about
the risk gained during the evaluation task itself. The risk management process is not a
“waterfall” process.
5.1.1 Plan and implement risk management
The purpose of the “plan and implement risk management” activity is to establish a
software risk management process. Where an organizational risk management
process exists, the software risk management process should be aligned to it. This
activity shall establish who is to perform risk management, define the specific risk
management process to be used, assign the resources required to implement the
process, and define how risks and their treatment are to be communicated and
coordinated among stakeholders.
This activity should be performed at the beginning of the project. Information created
during this activity shall be documented in a risk management plan such as that found
in Annex A.
NOTE: IEEE Std 1058-1998 requires the documentation of a risk management plan in the
software project management plan.
This activity consists of the tasks listed in 5.1.1.1 ~ 5.1.1.5.
5.1.1.1 Establish risk management policies
Risk management policies describing the guidelines under which risk management is
to be performed shall be explicitly defined. The policies shall support gathering risk
related information needed by the stakeholders. The policies should discuss how
a) Risk management is to be implemented, administered, and supported by
management and staff;
b) Ongoing commitment to risk management by stakeholders is to be obtained and
maintained;
c) The risk management process is to be coordinated among stakeholders;
d) Orientation and training of personnel in the risk management process is to be
accomplished;
e) Risk information, e.g., the project risk profile, is to be communicated and
reviewed by stakeholders and how often;
f) Resources are to be made available to treat risks.
The policies should align with existing organizational risk management policies
whenever feasible. A documented organizational risk management policy that defines
the above may be referenced and only the specifics for a project need to be
documented.
5.1.1.2 Establish the risk management process
A description of the risk management process to be implemented shall be documented
and promulgated. The description of the procedures that implement the risk
management process should include:
a) The frequency at which risks are to be reanalyzed and monitored;
b) The type of risk analysis required (quantitative and/or qualitative);
c) The scales to be used to estimate risk likelihood and consequences and their
descriptive and measurement uncertainty;
d) The types of risk thresholds to be used;
e) The types of measures used to track and monitor the state of the risks;
f) How risks are to be prioritized for treatment;
g) Which stakeholder(s) perspectives the risk management process supports;
h) The risk categories to be considered.
During this task, risk management process, specific procedures, and techniques
should be selected to match the project situation.
NOTE: IEC Guide 60300-3-9:1995 provides guidelines for the selection and utilization of
commonly used risk analysis techniques. IEC Std 61508-7:2000 provides useful material
related to measures and techniques related to safety.
The risk management process should align to existing organizational risk management
processes whenever feasible. A documented organizational risk management process
that defines the previous list may be referenced and only the specifics for a project
need to be documented.
5.1.1.3 Establish responsibility
The parties responsible for performing risk management and their roles and
responsibilities shall be explicitly identified. Parties shall be assigned responsibility for
the risk management process within the organizational unit.
5.1.1.4 Assign resources
The responsible parties shall be provided with adequate resources to perform the risk
management process.
5.1.1.5 Establish the risk management process evaluation
A description of the process for evaluating and improving the risk management process,
along with how information will be captured for lessons learned, shall be provided. Any
relevant lessons from prior use of the process should be incorporated into this
implementation of the process.
5.1.2 Manage the project risk profile
The purpose of the “manage the project risk profile” activity is to create a consistent
current and historical view of the risks pres...
......
Source: Above contents are excerpted from the full-copy PDF -- translated/reviewed by: www.ChineseStandard.net / Wayne Zheng et al.
Tips & Frequently Asked QuestionsQuestion 1: How long will the true-PDF of English version of GB/T 20918-2007 be delivered?Answer: The full copy PDF of English version of GB/T 20918-2007 can be downloaded in 9 seconds, and it will also be emailed to you in 9 seconds (double mechanisms to ensure the delivery reliably), with PDF-invoice. Question 2: Can I share the purchased PDF of GB/T 20918-2007_English with my colleagues?Answer: Yes. The purchased PDF of GB/T 20918-2007_English will be deemed to be sold to your employer/organization who actually paid for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. www.ChineseStandard.us -- GB/T 20918-2007 -- Click this link and select your country/currency to pay, the exact amount in your currency will be printed on the invoice. Full PDF will also be downloaded/emailed in 9 seconds. How to buy and download a true PDF of English version of GB/T 20918-2007?A step-by-step guide to download PDF of GB/T 20918-2007_EnglishStep 1: Visit website https://www.ChineseStandard.net (Pay in USD), or https://www.ChineseStandard.us (Pay in any currencies such as Euro, KRW, JPY, AUD).
Step 2: Search keyword "GB/T 20918-2007".
Step 3: Click "Add to Cart". If multiple PDFs are required, repeat steps 2 and 3 to add up to 12 PDFs to cart.
Step 4: Select payment option (Via payment agents Stripe or PayPal).
Step 5: Customize Tax Invoice -- Fill up your email etc.
Step 6: Click "Checkout".
Step 7: Make payment by credit card, PayPal, Google Pay etc. After the payment is completed and in 9 seconds, you will receive 2 emails attached with the purchased PDFs and PDF-invoice, respectively.
Step 8: Optional -- Go to download PDF.
Step 9: Optional -- Click Open/Download PDF to download PDFs and invoice.
See screenshots for above steps: Steps 1~3 Steps 4~6 Step 7 Step 8 Step 9 |