Quality management and quality assurance standards-Part 3:Guidelines for the application of GB/T 19001-ISO 9001 to the development supply and maintenance of software
Some standard content:
[ISO (International Organization for Standardization) is a worldwide federation composed of national standardization bodies (ISO member bodies). The work of formulating international standards is usually completed by ISO's technical committees. If each member body is interested in a standard project established by a technical committee, it has the right to participate in the work of the committee. International organizations (official or unofficial) that maintain contact with ISO may also participate in the relevant work. In the field of electrotechnical standardization, ISO maintains a close cooperative relationship with the International Electrotechnical Commission (IEC). The draft international standard formally adopted by the technical committee is submitted to the member bodies for voting. The international standard must be approved by at least 75% of the member bodies participating in the vote before it can be formally passed. The international standard ISO9000-3 was formulated by the ISO/TC176 Quality Management and Quality Assurance Technical Committee. [S09000's general title is: Quality Management and Quality Assurance Standards, which consists of the following parts: Section. Part 1: Guide to selection and use
Part 2: Guide to the use of ISO9001, IS09002 and ISO9003 Part 3: Guide to the use of ISO9001 in software development, supply and maintenance Part 1 is the revised version of ISO9000, and Part 2 is yet to be published. Appendices A and 3 of this standard are for reference only.
With the development of information technology, the number of software products is increasing, and software product quality management has become an indispensable and important factor. Proposing a software quality assurance guide is one of the methods to establish a quality management system. The general requirements for the quality system applicable to the contractual environment between the supplier and the buyer have been published, that is, GB/T19001-1S09001 Quality System-Quality Assurance Model for Design/Development, Production, Installation and Service. However, the development and maintenance process of software is different from that of most other industrial products. Due to the rapid development of this technical field, it is necessary to provide supplementary guidelines for the quality system involving software products, taking into account its current status. The characteristics of software development are: some activities are related to specific stages in the development process, while others may apply to the entire process. The structure of this standard reflects this difference. For this reason, this standard does not correspond directly to GB/T19001 in terms of format, but only gives the relationship between the two standards through a comparison table (Appendix A and Appendix B). Contracts for the development of software products may take different forms. In some contracts, this standard is not applicable even after "tailoring". Therefore, it is important to determine the extent to which this standard is applicable to specific contracts. The situation covered by this standard is mainly the development of specific software in accordance with the requirements specifications of the purchaser in the contract. However, the concepts involved may be equally valuable in other situations. Note: 1. The use of the masculine gender in this standard does not exclude the feminine. Similarly, the use of the singular does not exclude the use of the plural where the meaning permits (and vice versa).
2. Parts of this standard that do not provide further guidance on use and directly adopt the corresponding paragraphs of GB/T19001 are indicated in square brackets. 3. Some lists are given in this standard, none of which may be exhaustive and are only examples. National Standard of the People's Republic of China
Quality management and quality assurance standards
Part 3: GB/T 19001ISO 9001
Guidelines for the application of GB/T 19001-ISO 900°to the development ,supply and maintenance of softwareGB/T 19000.3-1994
1$0 9000-3—1993
This standard is equivalent to the international standard ISO9000-3 "Quality management and quality assurance standards Part 3: Guidelines for the application of ISO9001 to the development ,supply and maintenance of software". 1 Scope
This standard provides guidance for the application of GB/T 19001ISO 9001 to organizations responsible for software development, supply and maintenance. This standard can be used when the contract requires the supplier to demonstrate its ability to develop, supply and maintain software products. This standard aims to describe the control means and methods recommended for producing software that meets the requirements of the purchaser. This is mainly achieved by preventing non-conformities in all stages from development to maintenance. This standard applies to the following contract environments for software products: a. The contract has specific requirements for design work, and the performance requirements of the product have been basically described or are yet to be determined. b. By confirming the supplier's ability to develop, supply and maintain software products, confidence in the product is established. 2 Referenced standards
This standard references the clauses of the following standards. At the time of publication of this standard, these referenced standards are all valid versions. All standards are subject to revision, therefore, parties to agreements based on this standard are encouraged to adopt the latest versions of the following standards as much as possible. IEC and ISO members hold currently valid international standards.
ISO 2382-1 Data processing - Terminology Part 01; Basic terminology GH/T 6583 Quality - Terminology
GB/T19001 Quality system - Quality assurance model for design/development production, installation and service GB/T19001 Quality system audit guide - Part 1: Audit 3 Definitions
This standard uses the definitions given in IS0 2382-1 and GB/T 6583 and the following definitions. 3.1 Software: An intellectual creation that includes programs, procedures, rules and related documents related to the operation of a data processing system. [IS() 2382-101.04. 04]
Note 4, software is independent of its carrier.
3.2 Software product! A complete set of specified computer programs, procedures and related documents and data delivered to the user. 3.3 Software item: Any identifiable part of a software product in the intermediate or final stages of development. 3.4 Concurrency: All activities that create a software product. Approved by the State Administration of Technical Supervision on May 4, 1994, implemented on December 1, 1994
3.5 Phase; specified part of work.
GB/T 19000. 3--1994
Ting 5, a certain stage does not mean the use of a specific production cycle model, nor does it refer to a period of time in the development of a software product. 3.6 Software verification: The process of evaluating the product of a certain stage to ensure the correctness of the product of that stage and its consistency with the requirements (product and standard) specified by the input of that stage. 3.7 Software confirmation: The process of evaluating to ensure that the software meets the specified requirements. 4 Quality system - Framework
4.1 Management responsibilities
4.1.1 Management responsibilities of suppliers
4.1.1.1 Quality policy
The supplier manager shall define the quality policy and quality standards, make a commitment to quality and write it down. The supplier shall ensure that personnel at all levels understand the quality policy and can adhere to its implementation.
[GB/T 19001 4. 1. 1-
4.1.1.2 Organization
4.1.1.2.1 Responsibilities and authorities
All personnel who affect the management, realization and verification of quality, especially those who need to independently exercise the following authority, should have their responsibilities and authorities defined:
: Take measures to prevent non-conforming products; b. Identify and record product quality problems
e. Propose, adopt or recommend solutions through the specified channels: Verify the implementation effect of the solutions:
Take necessary control measures for the further processing, delivery or installation of non-conforming products until the defects or unsatisfactory situations are corrected GB/T 19001
4.1. 1.2. 2 Verification means and personnel
The supplier shall determine the internal verification requirements and provide appropriate means to assign trained personnel to carry out verification. Verification activities include inspection, testing and monitoring of the design, production, installation and service processes and/or products. The review of design, quality system, process and (or) product audits shall be conducted by personnel who have no direct responsibility for the work. [GB/T 19001 4-1. 2.2]
4. 1. 1.2. 3 Management representative
The supplier shall designate a dedicated representative and clarify his/her responsibilities and authority to ensure that the requirements of this standard are implemented. GB/T190014.1.2.3J
4. 1.1.3 Management Review
The supplier's management shall regularly review the quality system established in accordance with the requirements of this standard to ensure that the quality system continues to be effective. The review records shall be kept.
Note 6: Management review usually includes the evaluation of the results of internal quality audits and shall be conducted in person or on behalf of the supplier's management who is directly responsible for the quality system.
GB/T 19001 4-1.3]
4.1.2 Buyer's Management Responsibilities
The buyer shall cooperate with the supplier to provide all necessary information in a timely manner and resolve outstanding issues. The buyer shall designate a designated representative to be responsible for negotiating contractual matters with the supplier. This representative shall have sufficient authority to handle the following matters related to the contract (but not limited to):
Make requests to the supplier
Answer questions raised by the supplier;
Approve the supplier's proposals,
d. Sign an agreement with the supplier,
GB/T 19000. 3—1994
Ensure that the purchaser complies with the agreement signed with the supplier: e.
f. Specify acceptance criteria and procedures;
Handle software items provided by the purchaser that are not suitable for use. g
4.1.3 Joint review
The supplier and purchaser should conduct joint reviews regularly on the following aspects as needed: b. Whether the software meets the agreed requirements specifications; b. Verification results;
e. Acceptance test results. The review results should be agreed upon by both parties and written into documents. 4.2 Quality system
4.2.1 General
The supplier shall establish and maintain a quality system specified by documents. This quality system should be an integrated process throughout the entire life cycle so that quality can be guaranteed during the development process rather than discovering quality problems at the end of the process. Emphasis should be placed on preventing problems from occurring, rather than relying on corrective measures to solve them after they occur. The supplier should ensure that this is effectively implemented through a documented quality system. 4.2.2 Quality System Documentation
All quality system requirements, requirements and preventive measures should be clearly documented in a systematic and orderly manner. 4.2.3 Quality Plan
The supplier should formulate and document a quality activity plan for each software development based on the quality system to ensure that the relevant organizations can correctly understand and follow it.
4.3 Internal Quality System Audit
Internal Quality Review
The supplier should establish a comprehensive internal quality audit system to verify whether quality activities are in line with the planned arrangements and determine the effectiveness of the quality-based system.
The order of audits should be arranged according to the actual situation and importance of the project activities. The audit and subsequent measures should be carried out in accordance with written procedures, and the audit results should be written into a written report and notified to the person in charge of the audited department. For problems found during the audit, the responsible management personnel should take corrective measures in a timely manner.
[GB/T1900]4.17]
See GB/T 19021.
4.4 Corrective Action
The supplier shall formulate a written procedure for taking corrective actions and implement it. The contents include: a: Investigate the causes of nonconforming products and study the corrective measures required to prevent recurrence; b. Analyze all process operations, concessions, quality records, service reports and customer complaints to identify and eliminate the potential causes of nonconforming products;
C. Take appropriate preventive measures according to the degree of risk; d. Control the effective implementation of corrective measures; e. "Implement and record the changes to procedures caused by corrective actions. [GB/T 19001. 14]
5 Quality System--Contemporaneous Activities
5.1 General
GB/T 19000,3—1994
Software development projects shall be organized according to a life cycle model. Quality-related activities shall be planned and implemented according to the characteristics of the adopted life cycle model.
This standard is applicable to any life cycle model. If different conclusions are drawn from any description, criteria, requirements or structure, this is not intended and should not be interpreted as limiting this standard to only a specific life cycle model. 5.2 Contract Review
5.2.1 General
The supplier shall establish and follow procedures for contract review and coordination of these activities. The supplier shall review each contract to ensure that:
The specified contract Write the same scope and requirements into the document: Identify possible accidents or risks
Appropriately protect relevant patent information:
Solve all requirements that are different from the bidding: e. The supplier is capable of meeting the contract requirements:
Specify the supplier's responsibilities for the work of the sub-supplier! Unify the understanding of the terms between the two parties
h. The buyer is capable of fulfilling the contractual obligations.
Contract evaluation records should be properly preserved.
5.2.2 Quality clauses in the contract
In addition to other clauses, the quality clauses in the contract are: a.
Acceptance time:
During the development process d.
The handling of changes to requirements; handling of problems that arise after acceptance, including quality-related claims and complaints from the purchaser; d.
The activities performed by the purchaser: in particular, the purchaser's role in requirements specification, installation and acceptance; e.
The facilities, equipment and software items provided by the purchaser: f.
The standards and procedures used!
Reproduction requirements (see 5.9).
5.3 Purchaser's Requirements Specifications
5.311 General
For software development, the supplier shall have a complete set of functional requirements, which shall include all the requirements of the purchaser. These requirements shall include all the requirements of the purchaser. The requirements may include the following (but not limited to): performance, safety, reliability, confidentiality and specificity. These requirements should be precise enough to serve as the basis for product acceptance confirmation, and the supplier's requirement specification should record these requirements. Sometimes, this document is provided by the purchaser. If not, the supplier should determine these requirements in cooperation with the purchaser's plan and obtain the purchaser's approval before entering the development stage. The requirement specification should be part of the development document. In the purchaser's requirement specification, all interfaces between the software product and other software or hardware products should be fully specified in a direct or referenced manner.
5. 3.2 Supply and demand cooperation
When formulating the purchaser's requirement specification, special attention should be paid to the following matters: b. The company and the supplier shall designate personnel to be responsible for compiling the requirement specification; b. The method of requirement approval and change approval; GB/T 19000. 3-1994
. Try to prevent misunderstandings, such as term definitions and background descriptions of requirements; d. Record and review the results of discussions between the two parties.
5.4 Development Planning
5. 4. 1 General
The development plan shall include the following:
Project definition, including the statement of project objectives and reference to relevant projects of the demander or supplier! a.
b. Organization and management of project resources, including the composition and responsibilities of the project team, the role of the sub-supplier and the resources used, and the development phases (as defined in 5. 4.2. 1 c. Project schedule, including the tasks to be performed, the resources and time required for each task, and the relationship between the tasks:
Determine relevant plans, such as:
-Quality plan;
Configuration management plan;
-Integration plan;
Test plan.
The development plan shall be updated in a timely manner as the development progresses. Before starting a certain phase of work, the work plan for that phase shall be determined in accordance with Section 5.4.2.1. It shall be implemented after review and approval. 5.4.2 Development Plan
5.4.2.1 Phases
The development plan should strictly define the process or method for converting the acquirer's requirement specifications into software products. This may include dividing the work into several phases and determining the following: the development phases to be performed
the inputs to each phase;
c, the outputs to be produced by each phase;
d, the verification steps to be performed in each phase,
analyzing potential problems related to achieving the specified requirements at each development phase. e.
5. 4.2.2 Management
The development plan shall specify how the project is carried out, including determining the following: a. Development, implementation and delivery time arrangements b. Schedule control
c. Organizational responsibilities, resource and work allocations d. Organizational coordination and technical interfaces between different work groups 5. 4.2.3 Development methods and tools
The development plan shall determine the methods to ensure that all activities are carried out correctly, which may include the following: a. Development planning, practices and conventions;
h. Development tools and techniques;
c. Configuration management.
5.4.3 Progress Control
A progress review plan should be developed, documented and implemented to ensure that outstanding resource allocation issues are resolved and the entire development plan is implemented.
5.4.4 Inputs to Development Phases
The inputs required for each development phase should be specified and documented. Each requirement should be clearly defined so that its completion can be verified. Incomplete, ambiguous or contradictory requirements should be resolved during the drafting process. 5.4.5 Outputs from Development Phases
GB/T 19000. 3—1994
The outputs required for each development phase should be specified and documented. The output of each development phase should be verified and the following points should be met: b. meet the corresponding requirements; c. include or reference the acceptance criteria for entering the subsequent work phase; b. regardless of whether it has been specified in the input information, the output should comply with the relevant development practices and agreements, and identify the product characteristics that are critical to product safety and normal operation; d. meet the requirements of relevant regulations. 5.4.6 Verification of each phase The supplier shall develop a plan to verify the output of each phase at the end of each development phase, and shall verify that the output of the development phase meets the requirements of the input by adopting the following development control measures: a. Conduct a development review at the appropriate time of the development phase; b. Compare the new design with a similar design that has been proven to be correct when possible; e. Conduct testing and demonstration. Verification results and further measures required to ensure that the given requirements are met should be recorded and checked after the measures are completed. Only verified development outputs can be submitted to configuration management and accepted for use in subsequent phases. 5.5 Quality Strategy
5.5.1 General
The supplier shall develop a quality plan as part of the development planning. The quality plan shall be updated as the development progresses, and the software items related to each phase shall be fully determined at the beginning of that phase. The quality plan shall be formally reviewed and agreed by all organizations involved in the implementation of the plan. The document describing the quality plan (see 5.5.2) may be: a stand-alone document (called the quality plan\), or part of other documents, or may consist of multiple documents, including the development plan. 5.5.2 Contents of the quality plan
The quality plan shall specify or reference the following terms: b. Quality standards, given in quantitative form as far as possible; define the input and output criteria for each development phase; c.
Determine the type of testing, verification and validation activities to be performed; c.
Detailed test, verification and validation activity plan to be performed, including time schedule, resources and approval authority; d.
Specific responsibilities for quality activities. Such as:
Review and test:
Configuration management and reengineering;
…Control of defects and corrective actions.
5.6 Design and Implementation
5. 6. 1 General
Design and implementation activities refer to the process of transforming requirement specifications into software products. Due to the complexity of software products, these activities must be carried out in a strictly defined manner to produce products according to specifications, rather than relying on testing and verification activities to ensure quality. Note: Since the design and implementation process often exceeds the supplier's patent, the two parties should reach an agreement on the extent of information provided to the purchaser. 5.6.2 Design Evaluation
In addition to the common requirements for all development stages, the following factors should be considered for design activities: a. Determine the design basis - in addition to the input and output specifications, the design rules and internal interface definitions should also be checked: b. Design method - a systematic design method suitable for the type of software product being developed should be used; learn from past design experience - the supplier should learn from the experience and lessons of past designs to avoid the same or similar problems recurring, t.
GB/T 19000. 3—1994
d. Consideration of subsequent work - the product design should be easy to test, maintain and use. 5.6.3 Implementation
In addition to the common requirements for all development activities, the following factors should be considered in each implementation activity: a. Rules - programming rules, programming languages, naming conventions, coding and comment rules, etc. should be specified and followed: b. Implementation method - the supplier should use appropriate implementation methods and tools to meet the requirements. 5.6.4 Review
The supplier shall conduct a review to ensure that the screening requirements are met and the above methods are used correctly. Only after the effects of all defects found have been eliminated, or the effects of the defects have not been eliminated, but the risk of further development with defects has been eliminated, can the next step of design or implementation be carried out.
Records of these reviews shall be kept.
5.7 Testing and Validation
5.7.1 General
Different levels of testing may be required from a single software item to a complete software product, and there are some different testing and integration methods.
In some cases, confirmation, field testing and acceptance testing can be combined into one activity. The document describing the test plan can be a separate document, part of other documents, or composed of several documents. 5.7.2 Test Planning
The supplier shall prepare and review the test plan, specifications and procedures before launching the test. The following contents shall be considered: software item test plan, integration test plan, system test plan and acceptance test plan: test cases, test data and expected results; b.
Type of test to be conducted: such as functional test, boundary test, performance test, usability test; c.
Test environment, tools and test software;
Criteria for judging whether the test is complete:
User documentation
Required personnel and corresponding training requirements.
5. 7. 3 Testing
Pay special attention to the following aspects of testing: Test results should be recorded according to the relevant specifications: a.
Problems found should be recorded, indicating their possible impact on other parts of the software, and notified to the responsible personnel so that b.
problems can be tracked directly to the problem solution: c. The parts affected by the change should be determined and tested accordingly: The appropriateness and suitability of the test should be evaluated:
Software and hardware configurations should be considered and included in the documentation. e.
5.7.4 Confirmation ||tt ||Before product delivery and acceptance by the customer, the supplier shall confirm the operation of the entire product in an environment similar to the use environment specified in the contract as much as possible.
5.7.5 On-site testing
Where on-site testing is required, the following items shall be specified: Characteristics to be tested in the on-site environment: a.
Specific responsibilities of the supplier and the customer in conducting the benefit evaluation test; b.
Restore the user environment (after testing).
5.8 Acceptance
5.8.1 General
GB/T 19000. 3—1994
When the supplier is ready to deliver the confirmed product, the purchaser shall determine whether the product is ready for acceptance according to the criteria and methods specified in the contract.
The handling methods and treatment of problems found during the acceptance process shall be agreed upon by the purchaser and the supplier and included in the document. 5.8.2 Develop an acceptance test plan
Before conducting acceptance activities, the supplier shall assist the purchaser in determining the following: a. Time schedule;
b. Evaluation procedures:
c. Software/hardware environment and resources,
d. Acceptance rules.
|5.9 Copying, Delivery and Installation
5.9.1 Copying
Copying is a step that should be implemented before delivery. The following should be considered during the copying process: a.
Number of copies of each software item to be delivered; b.
The type of media for each software item that is human-readable, including format and version; c.
Terms of the documents to be delivered (manuals, user guides, etc.): Agreed copyright and license agreements: d.
Warranty of primary and backup copies when necessary, including recovery plans for catastrophic failures: The supplier's liability period for providing copies.
5.9.2 Delivery
Measures for verifying the correctness and completeness of the delivered software product should be specified. 5.9.3 Installation
The roles, responsibilities and obligations of the supplier and the purchaser should be clearly defined in terms of the following aspects. a
Time schedule, including non-normal working hours and weekends: h.
Provide the convenience of the purchaser (security steel, pass or password, protective equipment, etc.) t
Provide skilled personnel,
Use the purchaser's systems and equipment:
Confirmation requirements for each installation should be specified in the contract! e
f. Formal procedures for confirming the completion of each installation. 5.10 Maintenance
5. 10.1 General
When the purchaser requires the supplier to be responsible for maintenance after the initial delivery and installation of the software product, this should be specified in the contract. The supplier should establish and follow procedures for implementing maintenance activities and verifying that they meet specific maintenance requirements. Maintenance activities for software products are generally divided into: a. Problem solving; b. Interface adjustment; c. Function expansion or performance improvement.
Maintenance items and maintenance periods should be specified in the contract, such as: a. Programs,
Data and their structures;
Specifications!
Documents provided to the purchaser or user;
Documents provided for the supplier's use.
5. 10.2 Maintenance plan
GB/T 190Q0- 3—1994
All maintenance activities should be carried out and managed according to the maintenance plan agreed upon in advance by the supplier and the purchaser. The plan should include the following aspects: a. Scope of maintenance; b. Identification of the initial state of the product; c. Support organization; d. Maintenance activities; e. Maintenance records and reports. 5.10.3 Identification of the initial state of the product The initial state of the product to be maintained should be specified, included in the document, and agreed upon by both the supplier and the buyer. 5.10.4 Support organization In order to support maintenance activities, it may be necessary to establish an organization composed of representatives from both suppliers. Since the activities in the maintenance phase cannot always be carried out according to the scheduled arrangements, this organization should be flexible to deal with unexpected problems. The facilities and resources used for maintenance activities may also be determined by it. 5.10.5 Types of maintenance activities All changes to the software during maintenance (to solve problems, adjust interfaces, expand functions or improve performance) should be carried out as much as possible in accordance with the procedures used during the development of the software product. All these changes should also be included in the document in accordance with the document control and configuration management procedures. a. Problem Solving
Problem Solving includes detecting, analyzing and correcting software faults that cause operational problems. When solving problems, temporary adjustments can be made to reduce downtime, and permanent changes can be made later. b. Adjusting interfaces
When expanding and changing hardware systems or components controlled by software, interfaces may need to be adjusted. C. Expanding functions or improving performance
During the maintenance phase, the purchaser may request expansion and improvement of existing functions and performance. 5.10.6 Maintenance records and reports
All maintenance activities should be recorded and saved in the format specified in advance of the item, and the supplier and purchaser should agree on the submission rules for maintenance reports. For each software item being maintained, the maintenance record should include the following items: a list of maintenance applications or problem reports received and their status as of the previous month 8.
The organization responsible for accepting maintenance applications or implementing appropriate corrective actions, b.
The order of arrangement of corrective actions:
The results of corrective actions
Statistical data on failure occurrence and maintenance activities. e.
Records of maintenance activities can be used to evaluate and improve the software product and to complete the quality system. 5.10.7 Release procedures
To maintain performance, the supplier and the purchaser shall agree on and document procedures for incorporating changes into the software product. These procedures shall include:
. Basic principles for determining where local "patches" can be made or where a completely updated copy of the software product must be released, b. Description of release types (or categories) based on the frequency of releases and/or the impact on the purchaser's use and the ability to implement the changes in a timely manner,
Methods for notifying the purchaser of current or planned changes, and c. Methods for confirming that the changes implemented will not cause other problems. For multiple versions of the software and multiple operating environment sites, records are required to indicate what changes were made and where. e
6 Quality system—support activities (not related to phase) 6.1 Configuration management
6.1.1 General
GH/T 19000. 3—1994
Configuration management should provide a mechanism to identify, control and track the official version of each software item. In many cases, the earlier versions still in use must also be maintained and controlled. The configuration management system should:
a. Uniquely identify the official version of each software item; Identify the versions of each software item that constitute a specific version of the complete product; h.
Identify the status of software products in development, delivery and installation! d.
Control updates to the same software by more than one programmer, e.
Coordinate updates to one or more parts of multiple products; Identify and track all actions and changes caused by a change request, including the entire process from inception to release. f.
6.1.2 Configuration Management Plan
The supplier shall develop and implement a configuration management plan, including the following: a.
Related organizations and their responsibilities;
Configuration management activities;
Tools, techniques and methods used:
The corresponding phases at which each configuration item shall be placed under configuration control. d.
6.1.3 Configuration Management Activities
6.1.3.1 Configuration Identification and Tracking
The supplier shall establish and maintain procedures for identifying software items at all stages from specification preparation to development, replication and delivery. If required by the contract, these procedures may also be used after product delivery. Each software item shall have a unique identifier. These procedures shall ensure that each version of the software item is identified with the following: a. functional and technical specifications; b. all development tools that impact the functional and technical specifications; c. all interfaces with other software items and hardware; and c. all documentation and computer files related to the software item. The identification of the software item shall indicate the relationship of the software item to the contractual requirements. For released products, procedures shall be established to facilitate tracking of software items or products. 6.1.3.2 Change Control For software items under configuration management, the provider shall establish procedures for the identification, recording, review and approval of changes. All changes to software items shall be implemented in accordance with these procedures. Before accepting a change, its validity shall be confirmed and its impact on other software items shall be determined and checked. Methods shall be provided to notify relevant parties of the changes and to explain the tracking of the changes to the affected parts of the software item. 6.1.3.3 Configuration Status Reporting
The Supplier shall establish and follow procedures for recording, managing and reporting the status of the Software Item, the implementation of changes requested and approved changes.
6.2 Document Control
6.2.1 General
The Supplier shall establish and follow procedures for controlling all documents related to this specification, including: a. Identification of documents subject to the document control procedures; b. Approval and release procedures;
, change procedures, including the withdrawal of documents and, if required, release. 6.2.2 Document Types
The document control procedures apply to the following documents:5 Types of maintenance activities
All changes made to the software during maintenance (to resolve issues, adjust interfaces, expand functionality or improve performance) should be made as closely as possible to the procedures used during the development of the software product. All such changes should also be documented in accordance with document control and configuration management procedures. a. Problem Solving
Problem Solving includes detecting, analyzing and correcting software faults that cause operational problems. When solving problems, temporary adjustments can be made to reduce downtime before permanent changes are made. b. Adjusting Interfaces
When expanding and changing hardware systems or components controlled by the software, adjustments to the interfaces may be required. C. Expanding Functions or Improving Performance
During the maintenance phase, the purchaser may request expansion and improvement of existing functions and performance. 5.10.6 Maintenance Records and Reports
All maintenance activities should be recorded and stored in the format specified in advance, and the supplier and purchaser should agree on the rules for submitting maintenance reports. For each software item being maintained, the maintenance record shall include the following items: a. List of maintenance requests or problem reports received and their status as of the previous month; b. Organization responsible for receiving maintenance requests or implementing appropriate corrective actions; c. Order of corrective actions; e. Statistics of failure occurrences and maintenance activities. e. Records of maintenance activities may be used to evaluate and improve the software product and to complete the quality system. 5.10.7 Release procedures
In order to maintain performance, the supplier and the purchaser shall agree on and document procedures for incorporating changes into the software product. These procedures shall include:
Basic principles for determining where local "patches" can be made or where a completely updated copy of the software product must be released; b. Description of release types (or categories) based on the frequency of releases and/or the impact on the purchaser's use and the ability to implement the changes in a timely manner;
Methods for notifying the purchaser of current or planned changes; c. Methods to confirm that the implemented changes will not cause other problems For multiple versions of software and multiple operating environment sites, records are required to indicate what changes were made where. e
6 Quality system-support activities (not related to the phase) 6.1 Configuration management
6.1.1 General
GH/T 19000. 3—1994
Configuration management now provides a mechanism to identify, control and track the official version of each software item. In many cases, the earlier versions still in use must also be maintained and controlled. The configuration management system should:
a. Uniquely identify the official version of each software item; Identify the versions of each software item that constitute a specific version of the complete product; h.
Identify the status of software products in development, delivery and installation! d.
Control updates to the same software by more than one programmer. e.
Coordinate updates to one or more parts of multiple products; Identify and track all actions and changes resulting from a change request, from inception to release. f.
6.1.2 Configuration Management Plan
The supplier shall develop and implement a configuration management plan, including the following: a.
Related organizations and their responsibilities;
Configuration management activities;
Tools, techniques and methods used:
The corresponding stages at which each configuration item shall be placed under configuration control. d.
6.1.3 Configuration Management Activities
6.1.3.1 Configuration Identification and Tracking
The supplier shall establish and maintain procedures for identifying software items at all stages from specification preparation to development, replication and delivery. If required by the contract, these procedures may also be used after product delivery. Each software item shall be uniquely identified. These procedures shall ensure that each version of the software item is identified with the following: a. functional and technical specifications; b. all development tools that impact the functional and technical specifications; c. all interfaces with other software items and hardware; and d. all documentation and computer files related to the software item. The identification of the software item shall indicate the relationship of the software item to the contractual requirements. For released products, procedures shall be established to facilitate tracking of software items or products. 6.1.3.2 Change Control For software items under configuration management, the provider shall establish procedures for the identification, recording, review and approval of changes. All changes to software items shall be implemented in accordance with these procedures. Before accepting a change, its validity shall be confirmed and its impact on other software items shall be determined and checked. Methods shall be provided to notify relevant parties of the changes and to explain the tracking of the changes to the affected parts of the software item. 6.1.3.3 Configuration Status Reporting
The Supplier shall establish and follow procedures for recording, managing and reporting the status of the Software Item, the implementation of changes requested and approved changes.
6.2 Document Control
6.2.1 General
The Supplier shall establish and follow procedures for controlling all documents related to this specification, including: a. Identification of documents subject to the document control procedures; b. Approval and release procedures;
, change procedures, including the withdrawal of documents and, if required, release. 6.2.2 Document Types
The document control procedures apply to the following documents:5 Types of maintenance activities
All changes made to the software during maintenance (to resolve issues, adjust interfaces, expand functionality or improve performance) should be made as closely as possible to the procedures used during the development of the software product. All such changes should also be documented in accordance with document control and configuration management procedures. a. Problem Solving
Problem Solving includes detecting, analyzing and correcting software faults that cause operational problems. When solving problems, temporary adjustments can be made to reduce downtime before permanent changes are made. b. Adjusting Interfaces
When expanding and changing hardware systems or components controlled by the software, adjustments to the interfaces may be required. C. Expanding Functions or Improving Performancewww.bzxz.net
During the maintenance phase, the purchaser may request expansion and improvement of existing functions and performance. 5.10.6 Maintenance Records and Reports
All maintenance activities should be recorded and stored in the format specified in advance, and the supplier and purchaser should agree on the rules for submitting maintenance reports. For each software item being maintained, the maintenance record shall include the following items: a. List of maintenance requests or problem reports received and their status as of the previous month; b. Organization responsible for receiving maintenance requests or implementing appropriate corrective actions; c. Order of corrective actions; e. Statistics of failure occurrences and maintenance activities. e. Records of maintenance activities may be used to evaluate and improve the software product and to complete the quality system. 5.10.7 Release procedures
In order to maintain performance, the supplier and the purchaser shall agree on and document procedures for incorporating changes into the software product. These procedures shall include:
Basic principles for determining where local "patches" can be made or where a completely updated copy of the software product must be released; b. Description of release types (or categories) based on the frequency of releases and/or the impact on the purchaser's use and the ability to implement the changes in a timely manner;
Methods for notifying the purchaser of current or planned changes; c. Methods to confirm that the implemented changes will not cause other problems For multiple versions of software and multiple operating environment sites, records are required to indicate what changes were made where. e
6 Quality system-support activities (not related to the phase) 6.1 Configuration management
6.1.1 General
GH/T 19000. 3—1994
Configuration management now provides a mechanism to identify, control and track the official version of each software item. In many cases, the earlier versions still in use must also be maintained and controlled. The configuration management system should:
a. Uniquely identify the official version of each software item; Identify the versions of each software item that constitute a specific version of the complete product; h.
Identify the status of software products in development, delivery and installation! d.
Control updates to the same software by more than one programmer. e.
Coordinate updates to one or more parts of multiple products; Identify and track all actions and changes resulting from a change request, from inception to release. f.
6.1.2 Configuration Management Plan
The supplier shall develop and implement a configuration management plan, including the following: a.
Related organizations and their responsibilities;
Configuration management activities;
Tools, techniques and methods used:
The corresponding stages at which each configuration item shall be placed under configuration control. d.
6.1.3 Configuration Management Activities
6.1.3.1 Configuration Identification and Tracking
The supplier shall establish and maintain procedures for identifying software items at all stages from specification preparation to development, replication and delivery. If required by the contract, these procedures may also be used after product delivery. Each software item shall be uniquely identified. These procedures shall ensure that each version of the software item is identified with the following: a. functional and technical specifications; b. all development tools that impact the functional and technical specifications; c. all interfaces with other software items and hardware; and d. all documentation and computer files related to the software item. The identification of the software item shall indicate the relationship of the software item to the contractual requirements. For released products, procedures shall be established to facilitate tracking of software items or products. 6.1.3.2 Change Control For software items under configuration management, the provider shall establish procedures for the identification, recording, review and approval of changes. All changes to software items shall be implemented in accordance with these procedures. Before accepting a change, its validity shall be confirmed and its impact on other software items shall be determined and checked. Methods shall be provided to notify relevant parties of the changes and to explain the tracking of the changes to the affected parts of the software item. 6.1.3.3 Configuration Status Reporting
The Supplier shall establish and follow procedures for recording, managing and reporting the status of the Software Item, the implementation of changes requested and approved changes.
6.2 Document Control
6.2.1 General
The Supplier shall establish and follow procedures for controlling all documents related to this specification, including: a. Identification of documents subject to the document control procedures; b. Approval and release procedures;
, change procedures, including the withdrawal of documents and, if required, release. 6.2.2 Document Types
The document control procedures apply to the following documents:1. Identification and tracing of software items
The supplier shall establish and maintain procedures for identifying software items at all stages from specification preparation to development, reproduction and delivery. These procedures may also be used after product delivery if required by the contract. Each software item shall be uniquely identified. These procedures shall ensure that the following are identified for each version of the software item:
A. All development tools that affect the functional and technical specifications;
C. All interfaces with other software items and hardware;
A. All documents and computer files related to the software item. The identification of software items shall indicate the relationship of the software item to the contract requirements, and procedures shall be established for the released products to facilitate the tracing of software items or products. 6.1.3.2 Change Control
For software items under configuration management, the supplier shall establish procedures for the identification, recording, review and approval of changes. All changes to software items shall be implemented in accordance with these procedures.
Before accepting a change, its validity shall be confirmed and the impact of the change on other software items shall be determined and checked. Methods shall be provided to notify relevant parties of the changes and to explain the traceability of the changes to the managed parts of the software item. 6.1.3.3 Configuration Status Reporting
The supplier shall establish and follow procedures for recording, managing and reporting the status of software items, changes in progress and the implementation of approved changes.
6.2 Document Control
6.2.1 General
The supplier shall establish and implement control procedures for all documents related to this standard, including: a. Determination of documents that should be subject to the document control procedures; b. Approval and release of procedures;
, change procedures, including the withdrawal of documents and, if necessary, release. 6.2.2 Document Types
The document control procedures apply to the following documents:1. Identification and tracing of software items
The supplier shall establish and maintain procedures for identifying software items at all stages from specification preparation to development, reproduction and delivery. These procedures may also be used after product delivery if required by the contract. Each software item shall be uniquely identified. These procedures shall ensure that the following are identified for each version of the software item:
A. All development tools that affect the functional and technical specifications;
C. All interfaces with other software items and hardware;
A. All documents and computer files related to the software item. The identification of software items shall indicate the relationship of the software item to the contract requirements, and procedures shall be established for the released products to facilitate the tracing of software items or products. 6.1.3.2 Change Control
For software items under configuration management, the supplier shall establish procedures for the identification, recording, review and approval of changes. All changes to software items shall be implemented in accordance with these procedures.
Before accepting a change, its validity shall be confirmed and the impact of the change on other software items shall be determined and checked. Methods shall be provided to notify relevant parties of the changes and to explain the traceability of the changes to the managed parts of the software item. 6.1.3.3 Configuration Status Reporting
The supplier shall establish and follow procedures for recording, managing and reporting the status of software items, changes in progress and the implementation of approved changes.
6.2 Document Control
6.2.1 General
The supplier shall establish and implement control procedures for all documents related to this standard, including: a. Determination of documents that should be subject to the document control procedures; b. Approval and release of procedures;
, change procedures, including the withdrawal of documents and, if necessary, release. 6.2.2 Document Types
The document control procedures apply to the following documents:
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.