Some standard content:
GB/T8566--2001
This standard is equivalent to the international standard ISO/IEC12207:1995 "Information Technology Software Life Cycle Process". This standard is the second revision of GB/T8566. The main difference between this standard and GB/T8566-1995 is that the structure has been adjusted, all processes of the software life cycle are summarized as basic processes, support processes and organizational processes, and some terminology names have been modified. Appendix A of this standard is the standard appendix, and Appendix B to Appendix D are prompt appendices. This standard replaces GB/T8566-1995 from the date of implementation. This standard is proposed by the Ministry of Information Industry of the People's Republic of China. This standard is under the jurisdiction of the China Electronics Technology Standardization Institute. This standard is drafted by the China Electronics Technology Standardization Institute and Shanghai Software Technology Development Center. The main drafters of this standard are: Feng Hui, Zhou Mingde, Yang Qishan, Liu Guanglong, Wang Baoai. This standard was first issued in 1988 and revised for the first time in 1995. 85
GB/T8566-2001
ISO/IEC Foreword
ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) are specialized organizations for standardization worldwide. National member bodies (which are members of ISO or IEC) participate in the development of international standards for specific technical specifications through technical committees established by international organizations. ISO and IEC technical committees cooperate in areas of common interest. Other official and non-official international organizations in contact with ISO and IEC may also participate in the development of international standards. For information technology, ISO and IEC have established a joint technical committee, ISO/IECJTC1. Draft international standards proposed by the joint technical committee are circulated to national member bodies for voting. At least 75% of the votes of the national member bodies participating in the voting are required to publish an international standard.
International Standard ISO/IEC12207:1995 was developed by SC7, Software Engineering, Joint Technical Committee of ISO/IECJTC1 Information Technology.
Appendix A is an integral part of this standard. Appendix B, Appendix C and Appendix D are for reference only. 86
GB/T8566--2001
Software is an integral part of information technology and traditional systems, such as transportation, military, medical and financial systems. In order to develop and manage software, standards, procedures, methods, tools and environments have proliferated rapidly, which has caused difficulties in software management and engineering, especially in integrated products and services. The software discipline needs to move from this proliferative state to a common framework. This framework enables software practitioners to have a common language when producing and managing software. This standard provides such a framework. This framework includes the following software life cycle: from concept formation to retirement, and consists of various processes for acquiring and supplying software products and services. In addition, this framework can be used to control and improve these processes. The processes in this standard form a relatively complete set, and an organization can choose a suitable subset to achieve its goals according to its goals. Therefore, this standard is designed to allow specific organizations, projects or applications to be tailored. This standard can be used when the software is an independent entity, an embedded system or a component of the entire system. 1 Scope
1.1 Purpose
National Standard of the People's Republic of China
Information technology-Software life cycle processes
Information technology-Software life cycle processes GB/T 8566-2001
idtISO/IEC12207:1995
Replaces GB/T8566-1995
This standard establishes a common framework for software life cycle processes for reference by the software industry. It includes processes, activities and tasks to be applied during the acquisition of systems, stand-alone software products and software services containing software, and during the supply, development, operation and maintenance of software products. Software includes the software portion of firmware. This standard also provides a process that can be used to determine, control and improve software life cycle processes. 1.2 Scope of application
This standard applies to the acquisition of systems and software products and services, and also to the supply, development, operation and maintenance of the software portion of software products and firmware, and can be implemented inside or outside an organization. It shall include the definition of the systems needed to provide the environment for software products and services.
NOTE: The processes used during the software life cycle need to be consistent with the processes used during the system life cycle. This standard applies to both parties and is equally applicable if the parties are from the same organization. It covers everything from an informal agreement to a legally binding contract. This standard may be adopted by a single party as a self-improvement effort. This standard is not intended for use with off-the-shelf software products unless they are included in a deliverable. This standard is written for acquirers of systems and software products and services, and for suppliers, developers, operators, maintainers, managers, quality assurance managers, and users of software products. 1.3 Tailoring of this standard
This standard contains a set of processes, activities, and tasks that can be tailored to the circumstances of a software project. The tailoring process is to remove the processes, activities, and tasks that are not applicable.
NOTE: Unique or specialized processes, activities, and tasks may be added as required by the contract. 1.4 Compliance
Compliance with this standard is the implementation of all processes, activities, and tasks selected from this standard for a software project as per the tailoring process (Appendix A). When the required tasks are performed in accordance with the pre-defined criteria and contractual requirements, a process is performed or an activity is completed. Any organization (e.g., a government agency, an industry association, a company) that adopts this standard as a condition of trade is responsible for specifying the minimum processes, activities, and tasks necessary for software suppliers to comply with this standard. 1.5 Limitations
This standard describes the architecture of the software life cycle processes, but does not specify the details of how the activities and tasks contained in each process are to be implemented or completed.
This standard does not intend to describe the names, formats, or content of the documents that must be produced. This standard may require the preparation of documents of similar levels or types, such as various plans. However, this standard does not imply that such documents must be prepared or packaged separately or combined in a certain style. This standard does not specify a specific life cycle model or software development method. The parties adopting this standard are responsible for selecting a life cycle model for the software project and mapping the processes, activities, and tasks described in this standard to that model. The parties involved are also responsible for selecting and applying the software development method and performing the activities and tasks appropriate to the software project. Approved by the General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China on November 2, 200188
Implementation on June 1, 2002
GB/T 8566-2001
This standard does not intend to conflict with any existing policies, standards or procedures of any organization. However, any conflicts must be resolved and any exceeding conditions and conditions must be listed in writing as exceptions to the application of this standard. There are several task lists in this standard, none of which is complete, they are just some examples. 2 Reference standards
The provisions contained in the following standards constitute the provisions of this standard through reference in this standard. All versions are valid when this standard is released. All standards will be revised, and parties using this standard should explore the possibility of using the latest version of the following standards. GB/T5271.1--2000 Information technology vocabulary Part 1: Basic terms (idtISO/IEC2382-1:1993) GB/T5271.20--1994 Information technology vocabulary Part 20: System development (idtISO/IEC2382-20:1990) GB/T6583-1994 Quality management and quality assurance terms (idtISO8402:1994) GB/T16260-1996 Information technology software product evaluation quality characteristics and their use guidelines (idtISO/IEC 9126:1991)
Quality system design, development, production, installation and service quality assurance model (idtISO9001:GB/T 19001--1994
ISO/AFNOR: 1989 Dictionary of Computer Science 3 Definitions
This standard adopts the definitions specified in GB/T6583, GB/T5271.1 and GB/T5271.20 and the following definitions. Note: When appropriate, product can be interpreted as part of the system. 3.1 acquirer
An organization that obtains or purchases a system, software product or software service from a supplier. Note: The acquirer can be a buyer, customer, owner, user or purchaser. 3.2 acquisition
The process of acquiring a system, software product or software service. 3.3 agreement
The determination of the terms and conditions of the working relationship to be established. 3.4 audit
The independent assessment of software products and processes by authorized personnel to assess conformity with requirements. 3.5 baseline
A formally designed and fixed and approved version of a configuration item at a specific moment in its life cycle, regardless of the media.
3.6 configuration item
An entity in a configuration that satisfies an end-use function and can be uniquely identified at a given reference point. 3.7 contract
An agreement between the parties, or a similar internal agreement within an organization, that guarantees the provision of a software service, or the supply, development, production, operation or maintenance of a software product, by legally binding the parties. 3.8 Developer developer
An organization that performs development activities (including requirements analysis, design, testing and acceptance) during the software life cycle. 3.9 Evaluation evaluation
The systematic determination of the extent to which a physical item meets its specified criteria. 3.10 Firmware firmware
A combination of computer instructions or computer data in a hardware device and read-only software residing in the hardware device, whose software cannot be easily modified under program control.
3.11 Life cycle model lifecyclemodel GB/T 8566--2001
A framework that contains the processes, activities and tasks to be implemented in the development, operation and maintenance of a software product throughout the life cycle of a system from the determination of requirements to the termination of use.
3.12 Maintainer maintainer
An organization that performs maintenance activities.
3.13 Monitoring monitoring
An inspection of the status of the supplier's activities and their results by the purchaser or a third party. 3.14 non-deliverable item hardware or software product that is not required to be delivered according to the contract but can be used in the development of the software product. 3.15 off-the shelf product a product that has already been developed, is available, is usable, is ready-made, or needs to be modified. 3.16 operator an organization that operates a system.
3.17 process a set of related activities that transforms inputs into outputs. NOTE The term "activity" includes the use of resources. [See GB/T 6583, 1.2] 3.18 qualification a process that verifies whether an entity is capable of meeting specified requirements. [See GB/T 6583, 2.13] 3.19 qualification requirement a set of criteria or conditions that, when met, determine that a software product meets the specification and can be used in its intended environment.
3.20 Qualification testing Testing performed by the developer and witnessed by the acquirer (if appropriate) to demonstrate that the software product conforms to its specifications and can be used in the target environment.
3.21 Quality assurance All planned and systematic activities implemented in a quality system and verified as needed to provide sufficient confidence that the entity can meet quality requirements.
1 Quality assurance has two purposes: internal and external. a) Internal quality assurance: within the organization, quality assurance provides confidence to management. b) External quality assurance: in contractual or other situations, quality assurance provides confidence to customers or other parties. 2 Certain activities of quality control and quality assurance are interrelated. 3 Quality assurance can only provide sufficient confidence if the quality requirements fully reflect the user's requirements. [GB/T 6583,3. 5]
3.22 Release
A specific version of a configuration item that is ready for a specific purpose (such as test release). 3.23 Request for propasal (tender) A document used by the acquirer to indicate to potential bidders its intention to acquire a particular system, software product or software service. 3.24. Retirement
The withdrawal of existing support by an operating and maintenance organization, partial or complete replacement by a new system or installation of an upgraded system. 3.25 Security
The protection of information and data so that unauthorized persons or systems cannot read or modify them and authorized persons or systems cannot be denied access to them.
3.26 Software product software product90
GB/T 8566—2001
A set of computer programs, procedures and possibly related documentation and data. 3.27 Software service software service The implementation of activities, work or obligations related to a software product, such as software development, maintenance and operation. 3.28 Software unit software unit
A separately compilable piece of code.
3.29 statement of work a document used by the acquirer to describe and specify the tasks to be performed under the contract. 3.30 supplier supplier an organization that enters into a contract with the acquirer and provides systems, software products or software services under the contract. NOTES
1 The term "supplier" is synonymous with contractor, manufacturer, seller or supplier. 2 The acquirer may designate a part of its organization as a supplier. 3.31 system system a collection of one or more processes, hardware, software, facilities and personnel that provide the capability to meet specified requirements or objectives. 3.32 test coverage the degree to which test cases test the requirements of a system or software product. 3.33 testability the degree to which the test objectives and feasibility are achieved in order to determine whether a requirement is met. 3.34 user user an individual or organization that uses a running system to perform a specific function. NOTE: Users may play other roles, such as acquirer, developer or maintainer. 3.35 Validation validation Acknowledgement, by examination and provision of objective evidence, that requirements for a specific intended use have been met. NOTE NOTE In design and development, validation involves the process of examining whether a product meets the needs of the user. 1 Validation is usually carried out on the final product under specified conditions of use. This may also be necessary at an earlier stage. 3 The term "validated" is used to indicate the corresponding status. 4 If there are several different intended uses, multiple validations may be performed. [GB/T 6583, 2.18] Validation validation Acknowledgement, by examination and provision of objective evidence, that specified requirements have been met. NOTE NOTE 1 In design and development, validation is the process of checking the results of a specified activity to determine whether the activity meets specified requirements. 2 The term "validated" is used to indicate the corresponding status. [GB/T 6583,2.17]
3.37 Version
An identified instance of a configuration item. Note: A modification of a version of a software product produces a new version, but requires configuration management activities. 4 Application of this standard
This chapter describes the processes of the software life cycle used to acquire, supply, develop, operate and maintain software. The purpose is to provide a framework for users of this standard so that users can adjust their own processes according to this standard and apply this standard reasonably. 4.1 Structure of this standard
4.1.1 Life cycle processes
GB/T 8566—2001
This standard divides the activities that can be carried out in the software life cycle into 5 basic processes, 8 supporting processes and 4 organizational processes. Each life cycle process is divided into a group of activities, and each activity is further divided into a group of tasks. The number xX of the sub-clause represents a process, xxx represents an activity, and xxxx represents a task. These life cycle processes are introduced below and depicted in Figure 1. 5 Basic life cycle processes
5.1 Acquire
5.2 Supply
5.3 Develop
5.4 Operation
5.5 Maintenance
7 Life cycle organizational processes
7.1 Management
7.3 Improvement
6 Life cycle support processes
6.1 Documentation
6.2 Configuration management
6.3 Quality assurance
6.4 Verification
6.5 Validation
6.6 Joint review
6.7 Audit
6.8 Problem solving
7.2 Infrastructure
7.4 Training
Figure 1 Structure of this standard
4.1.1.1 Life cycle basic processes
The life cycle basic processes (Chapter 5) include five processes used by the major parties during the software life cycle. The major parties are the organizations involved in or responsible for the development, operation, or maintenance of the software product. These major parties are the demanders, suppliers, developers, operators and maintainers of the software product. The basic processes are: a) Acquisition process (5.1) - Identify the activities of the demanders and the organization that acquires the system, software product or software service. b) Supply process (5.2) - Identify the activities of the supplier and the organization that provides the system, software product or software service to the demander. c) Development process (5.3) - Identify the activities of the developer and the organization that defines and develops the software product. d) Operation process (5.4) - Identify the activities of the operator and the organization that provides the service of running the computer system to its users in the specified environment.
e) Maintenance process (5.5) - Identify the activities of the maintainer and the organization that provides the service of maintaining the software product. That is, manage the modification of the software to keep it in a suitable operating state. This process includes the migration and retirement of the software product. 4.1.1.2 Life cycle support process
The life cycle support process (Chapter 6) includes 8 processes. The support process supports other processes as an integral part of the whole with a clear purpose. It contributes to the success of the software project and improves the quality. Support processes are adopted and executed as needed by other processes. Support processes include:
GB/T 8566-2001
a) Documentation process (6.1) - Identify the activities required to record the information generated by the life cycle processes. b) Configuration management process (6.2) - Identify the configuration management activities. c) Quality assurance process (6.3) - Identify the activities required to objectively ensure that the software product and process conform to the specified requirements and the established plan. Joint review, audit, verification and validation can be used as quality assurance techniques. d) Verification process (6.4) - Identify the activities required to verify the software product at different depths (for the purchaser, supplier or an independent party) based on the software project requirements.
e) Validation process (6.5) - Identify the activities required to validate the software product of the software project (for the purchaser, supplier or an independent party). f) Joint review process (6.6) - Identify the activities required to evaluate the status and product of an activity. This process may be used by any two parties where one party (the reviewer) reviews the other party (the reviewee) in a joint discussion. g) Audit process (6.7) - Identifies the activities needed to determine conformity to requirements, plans, and contracts. This process may be used by any two parties where one party (the reviewer) reviews the software products or activities of the other party (the reviewee). h) Problem solving process (6.8) - Identifies a process to analyze and resolve problems (including nonconformities), regardless of their nature or source, that arise during the performance of development, operations, maintenance, or other processes. 4.1.1.3 Life cycle organizational processes
The life cycle organizational processes (Chapter 7) consist of four processes. These processes can be used by an organization to establish and implement an infrastructure of related life cycle processes and people and to continually improve this infrastructure and processes. Their use is usually beyond the scope of a specific project or contract. However, lessons learned from these specific projects and contracts can help improve the organization. The organizational processes are: a) Management processes (7.1) - Identifies the basic management activities of the life cycle processes, including project management. b) Infrastructure processes (7.2) - Identify the basic activities to establish the life cycle process infrastructure c) Improvement processes (7.3) - Identify the basic activities that an organization (i.e., acquirer, supplier, developer, operator, maintainer, or manager of another process) needs to perform to establish, measure, control, and improve its life cycle processes. d) Training processes (7.4) -
- Identify the activities required to provide appropriately trained personnel. 4.1.2 Tailoring processes
Appendix A (Standard Annex) identifies the basic activities required to tailor this standard. Appendix B (Informative Annex) provides a brief description of the tailoring requirements of this standard, listing some key factors that can be used to make tailoring decisions.
4.1.3 Relationship between processes and organizations
This standard contains processes that apply to the entire software life cycle, which can be used by different organizations depending on their needs and goals. To facilitate understanding, Appendix C describes the relationship between the life cycle processes and the parties involved. 5. Basic life cycle processes
The basic life cycle processes defined in this clause are as follows: a) acquisition process;
b) supply process;
c) development process;
d) operation process;
e) maintenance process.
The activities and tasks in the basic processes are the responsibilities of the organization that initiates and implements these processes. Such an organization must ensure that the processes exist and function.
5.1 Acquisition process
The acquisition process includes the activities and tasks of the acquirer. This process starts with determining the system, software product or software service to be acquired, followed by the preparation and issuance of bids, the selection of suppliers and the management of the acquisition process until the acceptance of the system, software product or software service. 93
GB/T 8566--2001
The organization with such needs can be called the owner. The owner can contract with an agency for one or all acquisition activities, and the agency will carry out these activities according to the acquisition process. The acquirer in this clause can be the owner or the agency. The acquirer manages the acquisition process specified in this clause at the project level using the management process (7.1); establishes the infrastructure for this process using the infrastructure process (7.2); tailors this process to specific projects using the tailoring process (Appendix A); and manages this process at the organizational level using the improvement process (7.3) and the training process (7.4).
Activity List: This process includes the following activities: a) Initiation;
b) Preparation for bidding;
c) Preparation and modification of contracts;
d) Supervision of suppliers;
e) Acceptance and completion.
5.1.1 Initiation
This activity includes the following tasks:
5.1.1.1 The acquirer begins the acquisition process by describing the concept or need to acquire, develop, or enhance a system, software product, or software service. 5.1.1.2 The acquirer shall define and analyze the system requirements. System requirements include business, organization and users, as well as security, confidentiality, and other key requirements related to design and testing, and the standards and procedures to be followed. 5.1.1.3 If the purchaser entrusts the supplier to perform system requirements analysis, the purchaser shall approve the analyzed requirements. 5.1.1.4 The purchaser may define and analyze software requirements by itself, or entrust the supplier to complete this task. 5.1.1.5 The development process (5.3) should be used to complete the tasks in 5.1.1.2 and 5.1.1.4. 5.1.1.6 The acquirer shall analyze each of the following options based on the criteria of risk, cost and benefit and consider the acquisition options, which include:
a) purchasing off-the-shelf software products that meet the requirements;
b) developing software products or obtaining software services internally;
c) developing software products or obtaining software services through contracts;
d) a combination of the above a), b) and c);
e) improving existing software products or services
5.1.7.7 When acquiring off-the-shelf software products, the supplier shall ensure that the following conditions are met: a) meet the requirements for the software product;
b) have valid documentation;
c) meet the patent rights, usage rights, ownership rights, warranty rights and licensing rights;
d) have future support plans for the software product. 5.1.1.8 The acquirer should prepare, compile and implement an acquisition plan that should include the following: a) requirements for the system;
b) planned system configuration;
c) type of contract to be adopted;
d) responsibilities of the organizations involved;
e) support concepts to be adopted;
f) considerations of risk and risk management methods. 5.1.1.9 The acquirer should determine and document the acceptance strategy and conditions (criteria). 5.1.2 Preparation for bidding
This activity includes the following tasks:
5.1.2.1 The acquirer should prepare an acquisition requirements document (e.g. a request for proposal), the content of which will depend on the acquisition approach selected in 5.1.1.6. The acquisition document should include, as appropriate:
a) system requirements;
b) scope statement;
c) instructions to bidders;
d) software product list;
e) terms and conditions;
f) control of subcontracts;
g) technical constraints (e.g. target environment). GB/T 8566-2001
5.1.2.2 The acquirer should determine the processes, activities and tasks of this International Standard that are appropriate for the project and should tailor them appropriately. In particular, the acquirer should specify the applicable support processes (Clause 6) and the organizations that perform them, and if not the supplier, their responsibilities. This will allow suppliers to identify the approach for each applicable support process in their bids. The acquirer should determine the scope of those tasks that are referenced in the contract. 5.1.2.3 The acquisition document should also identify contract milestones at which supplier progress should be reviewed and audited as part of monitoring acquisition (see 6.6 and 6.7).
5.1.2.4 The acquisition requirements should be submitted to the organization selected to perform the acquisition activities. 5.1.3 Contract Preparation and Modification
This activity includes the following tasks:
5.1.3.1 The acquirer should establish procedures for selecting suppliers, including criteria for evaluating bids and their conformance to requirements. 5.1.3.2 The acquirer should select a supplier based on an evaluation of the supplier's bids, capabilities, and other considerations. 5.1.3.3 The acquirer may work with other parties, including potential suppliers, to tailor this standard before the contract is signed; however, the acquirer should make the final decision on tailoring. The acquirer should include or list the tailored standard in the contract. 5.1.3.4 The acquirer shall prepare and negotiate a contract with the supplier that addresses the requirements, including the cost and schedule of the software product or service to be delivered. The contract may also address patents, usage rights, title, warranty, and licensing rights associated with reusable off-the-shelf software products. 5.1.3.5 Once a contract is executed, the acquirer shall control changes to the contract through negotiation with the supplier as part of the change control mechanism. Changes to the contract shall investigate the impact on the project schedule, cost, benefits, quality, and schedule. NOTE The acquirer determines whether the term "contract" or "agreement" is used in the application of this standard. 5.1.4 Monitoring of Suppliers
This activity includes the following tasks:
5.1.4.1 The acquirer shall monitor the activities of the supplier in accordance with the joint review process (6.6) and the audit process (6.7). The acquirer should supplement monitoring with the verification process (6.4) and validation process (6.5) as needed. 5.1.4.2 The acquirer shall cooperate with the supplier to provide all necessary information in a timely manner and resolve all outstanding issues. 5.1.5 Acceptance and Completion
This activity includes the following tasks:
5.1.5.1 The acquirer should prepare for acceptance according to the determined acceptance strategy and criteria, which should include the preparation of test cases, test data, test procedures and test environment. The extent of supplier involvement should be determined. 5.1.5.2 The acquirer shall conduct acceptance review and acceptance testing of the deliverable software product or service and accept it from the supplier when all acceptance conditions are met. The acceptance procedure should be in accordance with 5.1.1.9. 5.1.5.3 After acceptance, the acquirer should assume responsibility for configuration management of the delivered software product (see 6.2). NOTE: The acquirer may install the software product or perform the software service according to the specifications provided by the supplier. 5.2 Provisioning Process
The provisioning process includes the activities and tasks of the supplier. This process may be initiated by preparing a bid in response to a request for proposal from the acquirer or by signing a contract with the acquirer to provide the system, software product, or software service. It then determines the procedures and resources needed to manage and assure the project, including preparing the project plan, implementing the plan, and delivering the system, software product, or software service to the acquirer. The supplier manages the supply process specified in this clause at the project level in accordance with the management process (7.1). The infrastructure for this process is established in accordance with the infrastructure process (7.2). This process is tailored to the project in accordance with the tailoring process (Appendix A). This process is managed at the organizational level in accordance with the improvement process (7.3) and the training process (7.4).
Activity List: This process includes the following activities: a) Initiation; b) Preparation of bid; c) Contract signing; d) Preparation of plan; e) Implementation and control; f) Review and evaluation; f) Delivery and completion.
5.2.1 Initiation
This activity includes the following tasks:
GB/T8566—2001
5.2.1.1 The supplier reviews the requirements in the tender, taking into account the organization's policies and other regulations. 5.2.1.2 The supplier should make a decision to bid or accept the contract. 5.2.2 Prepare the bid
This activity includes the following tasks:
5.2.2.1 The supplier should identify and prepare a bid in response to the tender, including suggestions for tailoring of this standard. 5.2.3 Contract signing
This activity includes the following tasks:
5.2.3.1 The supplier should negotiate and sign a contract with the purchaser's organization to provide the software product or service. 5.2.3.2 As part of the change control mechanism, the supplier may request a modification to the contract. 5.2.4 Prepare a plan
This activity includes the following tasks:
5.2.4.1 The supplier shall review the acquisition requirements to determine a framework to manage and assure the project and to ensure the quality of the deliverable software product or service.
5.2.4.2 If not specified in the contract, the supplier shall determine or select a software life cycle model that is appropriate to the scope, size and complexity of the project. The processes, activities and tasks should be selected from this International Standard and reflected in the life cycle model. 5.2.4.3 The supplier shall establish planning requirements to manage and assure the project and to ensure the quality of the deliverable software product or service. Planning requirements should include the resources required and the involvement of the acquirer. 5.2.4.4 Once planning requirements have been established, the supplier shall consider options for developing the software product or providing the software service based on an analysis of the risks associated with each option. The options include: a) developing software products or providing software services using internal resources; b) developing software products or providing software services through subcontracting; c) obtaining ready-made software products from internal or external resources; d) a combination of a), b) and c) above.
5.2.4.5 The supplier shall develop a project management plan based on the planned requirements and the option selection in accordance with 5.2.4.4, and document it. Items considered in the plan include, but are not limited to, the following: a) Project organizational structure, responsibilities and authorities for each organizational unit, including external organizations; b) Engineering environment (for development, operation or maintenance, as applicable), including test environment, program libraries, equipment, facilities, standards, procedures and tools; c) Work breakdown structure of life cycle processes and activities including software products, software services and non-deliverables to be completed, together with budget, personnel, physical resources, software size and related task schedules; d) Management of quality characteristics of software products or services, for which independent quality plans may be prepared; e) Management of security, confidentiality and other critical requirements of software products or services, for which independent safety, confidentiality and security plans may be prepared;2 The purchaser should select a supplier based on the supplier's bid, capability evaluation, and other factors to be considered. 5.1.3.3 The purchaser may work with other parties, including potential suppliers, to tailor this standard before the contract is signed; however, the purchaser shall make the final decision on the tailoring. The purchaser shall include or list the tailored standards in the contract. 5.1.3.4 The purchaser shall prepare and negotiate a contract with the supplier that addresses the requirements, including the cost and schedule of the software product or service to be delivered. The contract also addresses patents, usage rights, ownership, warranty rights, and licensing rights associated with reusable off-the-shelf software products. 5.1.3.5 Once the contract is executed, the purchaser shall control changes to the contract through negotiation with the supplier as part of the change control mechanism. Changes to the contract shall investigate the impact on the project plan, cost, benefits, quality, and schedule. NOTE: The purchaser determines whether the term "contract" or "agreement" is used in the application of this standard. 5.1.4 Oversight of Suppliers
This activity includes the following tasks:
5.1.4.1 The purchaser shall monitor the activities of the supplier in accordance with the joint review process (6.6) and the audit process (6.7). The purchaser should supplement oversight with the verification process (6.4) and validation process (6.5) as needed. 5.1.4.2 The purchaser shall cooperate with the supplier to provide all necessary information in a timely manner and resolve all outstanding issues. 5.1.5 Acceptance and Completion
This activity includes the following tasks:
5.1.5.1 The purchaser should prepare for acceptance according to the defined acceptance strategy and criteria, which should include the preparation of test cases, test data, test procedures, and test environment. The extent of supplier involvement should be determined. 5.1.5.2 The purchaser shall conduct acceptance review and acceptance testing of the deliverable software product or service and accept it from the supplier when all acceptance criteria are met. The acceptance procedure should be in accordance with 5.1.1.9. 5.1.5.3 After acceptance, the acquirer should assume responsibility for configuration management of the delivered software product (see 6.2). NOTE The acquirer may install the software product or perform the software service in accordance with the specifications provided by the supplier. 5.2 Supply Process
The supply process includes the activities and tasks of the supplier. This process may be initiated by preparing a bid in response to the acquirer's request for tender or by entering into a contract with the acquirer to provide the system, software product, or software service. It then determines the procedures and resources required to manage and assure the project, including preparing a project plan and implementing the plan until the system, software product, or software service is delivered to the acquirer. The supplier manages the supply process specified in this clause at the project level in accordance with the management process (7.1). The infrastructure for this process is established in accordance with the infrastructure process (7.2). This process is tailored to the project in accordance with the tailoring process (Annex A). This process is managed at the organizational level in accordance with the improvement process (7.3) and the training process (7.4).
Activity List: This process includes the following activities: a) Initiation;
b) Preparation of bids;
c) Contract signing;
d) Preparation of plans;
e) Implementation and control;
f) Review and evaluation;
delivery and completion.
5.2.1 Initiation
This activity includes the following tasks:
GB/T8566—2001
5.2.1.1 The supplier reviews the requirements in the tender, taking into account the organization's policies and other regulations. 5.2.1.2 The supplier should make a decision to bid or accept the contract. 5.2.2 Preparation of bids
This activity includes the following tasks:
5.2.2.1 The supplier should identify and prepare a bid in response to the tender, including any tailoring recommendations for this standard. 5.2.3 Contract Signing
This activity includes the following tasks:
5.2.3.1 The supplier should negotiate and sign a contract with the acquirer to provide the software product or service. 5.2.3.2 The supplier may request modifications to the contract as part of the change control mechanism. 5.2.4 Plan
This activity includes the following tasks:
5.2.4.1 The supplier shall review the acquisition requirements to determine a framework to manage and assure the project and to ensure the quality of the deliverable software product or service.
5.2.4.2 If not specified in the contract, the supplier shall determine or select a software life cycle model that is appropriate to the scope, size, and complexity of the project. The processes, activities, and tasks should be selected from this International Standard and reflected in the life cycle model. 5.2.4.3 The supplier shall establish planning requirements to manage and assure the project and to assure the quality of the deliverable software product or service. Planning requirements should include the required resources and involvement of the acquirer. 5.2.4.4 Once the planned requirements are established, the supplier shall consider the options for developing the software product or providing the software service based on the risk analysis of each option. The options include: a) developing the software product or providing the software service using internal resources; b) developing the software product or providing the software service through a subcontract; c) obtaining a ready-made software product from internal or external resources; d) a combination of a), b), and c) above.
5.2.4.5 The supplier shall develop and document the project management plan based on the planned requirements and the options selected in accordance with 5.2.4.4. Items considered in the plan include, but are not limited to, the following: a) Project organizational structure, responsibilities and authorities for each organizational unit, including external organizations; b) Engineering environment (for development, operation or maintenance, as applicable), including test environment, program libraries, equipment, facilities, standards, procedures and tools; c) Work breakdown structure of life cycle processes and activities including software products, software services and non-deliverables to be completed, together with budget, personnel, physical resources, software size and related task schedules; d) Management of quality characteristics of software products or services, for which independent quality plans may be prepared; e) Management of security, confidentiality and other critical requirements of software products or services, for which independent safety, confidentiality and security plans may be prepared;2 The purchaser should select a supplier based on the supplier's bid, capability evaluation, and other factors to be considered. 5.1.3.3 The purchaser may work with other parties, including potential suppliers, to tailor this standard before the contract is signed; however, the purchaser shall make the final decision on the tailoring. The purchaser shall include or list the tailored standards in the contract. 5.1.3.4 The purchaser shall prepare and negotiate a contract with the supplier that addresses the requirements, including the cost and schedule of the software product or service to be delivered. The contract also addresses patents, usage rights, ownership, warranty rights, and licensing rights associated with reusable off-the-shelf software products. 5.1.3.5 Once the contract is executed, the purchaser shall control changes to the contract through negotiation with the supplier as part of the change control mechanism. Changes to the contract shall investigate the impact on the project plan, cost, benefits, quality, and schedule. NOTE: The purchaser determines whether the term "contract" or "agreement" is used in the application of this standard. 5.1.4 Oversight of Suppliers
This activity includes the following tasks:
5.1.4.1 The purchaser shall monitor the supplier's activities in accordance with the joint review process (6.6) and the audit process (6.7). The purchaser should supplement oversight with the verification process (6.4) and validation process (6.5) as needed. 5.1.4.2 The purchaser shall cooperate with the supplier to provide all necessary information in a timely manner and resolve all outstanding issues. 5.1.5 Acceptance and Completion
This activity includes the following tasks:
5.1.5.1 The purchaser should prepare for acceptance according to the defined acceptance strategy and criteria, which should include the preparation of test cases, test data, test procedures, and test environment. The extent of supplier involvement should be determined. 5.1.5.2 The purchaser shall conduct acceptance review and acceptance testing of the deliverable software product or service and accept it from the supplier when all acceptance criteria are met. The acceptance procedure should be in accordance with 5.1.1.9. 5.1.5.3 After acceptance, the acquirer should assume responsibility for configuration management of the delivered software product (see 6.2). NOTE The acquirer may install the software product or perform the software service in accordance with the specifications provided by the supplier. 5.2 Supply Process
The supply process includes the activities and tasks of the supplier. This process may be initiated by preparing a bid in response to the acquirer's request for tender or by entering into a contract with the acquirer to provide the system, software product, or software service. It then determines the procedures and resources required to manage and assure the project, including preparing a project plan and implementing the plan until the system, software product, or software service is delivered to the acquirer. The supplier manages the supply process specified in this clause at the project level in accordance with the management process (7.1). The infrastructure for this process is established in accordance with the infrastructure process (7.2). This process is tailored to the project in accordance with the tailoring process (Annex A). This process is managed at the organizational level in accordance with the improvement process (7.3) and the training process (7.4).
Activity List: This process includes the following activities: a) Initiation;
b) Preparation of bids;
c) Contract signing;
d) Preparation of plans;
e) Implementation and control;
f) Review and evaluation;
delivery and completion.
5.2.1 Initiation
This activity includes the following tasks:
GB/T8566—2001
5.2.1.1 The supplier reviews the requirements in the tender, taking into account the organization's policies and other regulations. 5.2.1.2 The supplier should make a decision to bid or accept the contract. 5.2.2 Preparation of bids
This activity includes the following tasks:
5.2.2.1 The supplier should identify and prepare a bid in response to the tender, including any tailoring recommendations for this standard. 5.2.3 Contract Signing
This activity includes the following tasks:wwW.bzxz.Net
5.2.3.1 The supplier should negotiate and sign a contract with the acquirer to provide the software product or service. 5.2.3.2 The supplier may request modifications to the contract as part of the change control mechanism. 5.2.4 Plan
This activity includes the following tasks:
5.2.4.1 The supplier shall review the acquisition requirements to determine a framework to manage and assure the project and to ensure the quality of the deliverable software product or service.
5.2.4.2 If not specified in the contract, the supplier shall determine or select a software life cycle model that is appropriate to the scope, size, and complexity of the project. The processes, activities, and tasks should be selected from this International Standard and reflected in the life cycle model. 5.2.4.3 The supplier shall establish planning requirements to manage and assure the project and to assure the quality of the deliverable software product or service. Planning requirements should include the required resources and involvement of the acquirer. 5.2.4.4 Once the planned requirements are established, the supplier shall consider the options for developing the software product or providing the software service based on the risk analysis of each option. The options include: a) developing the software product or providing the software service using internal resources; b) developing the software product or providing the software service through a subcontract; c) obtaining a ready-made software product from internal or external resources; d) a combination of a), b), and c) above.
5.2.4.5 The supplier shall develop and document the project management plan based on the planned requirements and the options selected in accordance with 5.2.4.4. Items considered in the plan include, but are not limited to, the following: a) Project organizational structure, responsibilities and authorities for each organizational unit, including external organizations; b) Engineering environment (for development, operation or maintenance, as applicable), including test environment, program libraries, equipment, facilities, standards, procedures and tools; c) Work breakdown structure of life cycle processes and activities including software products, software services and non-deliverables to be completed, together with budget, personnel, physical resources, software size and related task schedules; d) Management of quality characteristics of software products or services, for which independent quality plans may be prepared; e) Management of security, confidentiality and other critical requirements of software products or services, for which independent safety, confidentiality and security plans may be prepared;4) Manage this process at the organizational level.
Activity List: This process includes the following activities: a) Initiation;
b) Preparation of bids;
c) Contract signing;
d) Preparation of plans;
e) Implementation and control;
f) Review and evaluation;
delivery and completion.
5.2.1 Initiation
This activity includes the following tasks:
GB/T8566—2001
5.2.1.1 The supplier reviews the requirements in the tender, taking into account the organization's policies and other regulations. 5.2.1.2 The supplier should make a decision to bid or accept the contract. 5.2.2 Preparation of bids
This activity includes the following tasks:
5.2.2.1 The supplier should identify and prepare a tender in response to the tender, including any tailoring recommendations for this standard. 5.2.3 Contract Signing
This activity includes the following tasks:
5.2.3.1 The supplier should negotiate and sign a contract with the acquirer to provide the software product or service. 5.2.3.2 The supplier may request modifications to the contract as part of the change control mechanism. 5.2.4 Plan
This activity includes the following tasks:
5.2.4.1 The supplier shall review the acquisition requirements to determine a framework to manage and assure the project and to ensure the quality of the deliverable software product or service.
5.2.4.2 If not specified in the contract, the supplier shall determine or select a software life cycle model that is appropriate to the scope, size, and complexity of the project. The processes, activities, and tasks should be selected from this International Standard and reflected in the life cycle model. 5.2.4.3 The supplier shall establish planning requirements to manage and assure the project and to assure the quality of the deliverable software product or service. Planning requirements should include the required resources and involvement of the acquirer. 5.2.4.4 Once the planned requirements are established, the supplier shall consider the options for developing the software product or providing the software service based on the risk analysis of each option. The options include: a) developing the software product or providing the software service using internal resources; b) developing the software product or providing the software service through a subcontract; c) obtaining a ready-made software product from internal or external resources; d) a combination of a), b), and c) above.
5.2.4.5 The supplier shall develop and document the project management plan based on the planned requirements and the options selected in accordance with 5.2.4.4. Items considered in the plan include, but are not limited to, the following: a) Project organizational structure, responsibilities and authorities for each organizational unit, including external organizations; b) Engineering environment (for development, operation or maintenance, as applicable), including test environment, program libraries, equipment, facilities, standards, procedures and tools; c) Work breakdown structure of life cycle processes and activities including software products, software services and non-deliverables to be completed, together with budget, personnel, physical resources, software size and related task schedules; d) Management of quality characteristics of software products or services, for which independent quality plans may be prepared; e) Management of security, confidentiality and other critical requirements of software products or services, for which independent safety, confidentiality and security plans may be prepared;4) Manage this process at the organizational level.
Activity List: This process includes the following activities: a) Initiation;
b) Preparation of bids;
c) Contract signing;
d) Preparation of plans;
e) Implementation and control;
f) Review and evaluation;
delivery and completion.
5.2.1 Initiation
This activity includes the following tasks:
GB/T8566—2001
5.2.1.1 The supplier reviews the requirements in the tender, taking into account the organization's policies and other regulations. 5.2.1.2 The supplier should make a decision to bid or accept the contract. 5.2.2 Preparation of bids
This activity includes the following tasks:
5.2.2.1 The supplier should identify and prepare a tender in response to the tender, including any tailoring recommendations for this standard. 5.2.3 Contract Signing
This activity includes the following tasks:
5.2.3.1 The supplier should negotiate and sign a contract with the acquirer to provide the software product or service. 5.2.3.2 The supplier may request modifications to the contract as part of the change control mechanism. 5.2.4 Plan
This activity includes the following tasks:
5.2.4.1 The supplier shall review the acquisition requirements to determine a framework to manage and assure the project and to ensure the quality of the deliverable software product or service.
5.2.4.2 If not specified in the contract, the supplier shall determine or select a software life cycle model that is appropriate to the scope, size, and complexity of the project. The processes, activities, and tasks should be selected from this International Standard and reflected in the life cycle model. 5.2.4.3 The supplier shall establish planning requirements to manage and assure the project and to assure the quality of the deliverable software product or service. Planning requirements should include the required resources and involvement of the acquirer. 5.2.4.4 Once the planned requirements are established, the supplier shall consider the options for developing the software product or providing the software service based on the risk analysis of each option. The options include: a) developing the software product or providing the software service using internal resources; b) developing the software product or providing the software service through a subcontract; c) obtaining a ready-made software product from internal or external resources; d) a combination of a), b), and c) above.
5.2.4.5 The supplier shall develop and document the project management plan based on the planned requirements and the options selected in accordance with 5.2.4.4. Items considered in the plan include, but are not limited to, the following: a) Project organizational structure, responsibilities and authorities for each organizational unit, including external organizations; b) Engineering environment (for development, operation or maintenance, as applicable), including test environment, program libraries, equipment, facilities, standards, procedures and tools; c) Work breakdown structure of life cycle processes and activities including software products, software services and non-deliverables to be completed, together with budget, personnel, physical resources, software size and related task schedules; d) Management of quality characteristics of software products or services, for which independent quality plans may be prepared; e) Management of security, confidentiality and other critical requirements of software products or services, for which independent safety, confidentiality and security plans may be prepared;
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.