Method Statement
方法声明
Both members of the consortium, HEAD Aerospace and CRESDA, hold an ISO 9001 certification. This section describes the quality system procedures as inspired by the standards, applicable to project management, components procurement and software development, as the most relevant tasks in the proposal.
该联盟的双方成员，HEAD 航天和 CRESDA，均持有 ISO 9001 认证。本节描述了受标准启发、适用于项目管理、组件采购和软件开发的质量体系程序，因为这些是提案中最相关的任务。
Project Management Plan
项目管理计划
Managerial Objectives and Priorities
管理目标和优先事项
The objectives of the Project Management are to:
项目管理目标包括：
Ensure that all technical requirements are met within schedule and cost budget
确保所有技术要求在时间和成本预算内得到满足
Establish and implement a project planning and control system compliant with the requirements.
建立并实施符合要求的工程项目规划与控制系统。
Exercise schedule and financial control and monitoring of the tasks.
锻炼时间表以及任务财务控制和监控。
Risk Management
风险管理
The work plan proposed in this proposal is based on the statement of work (SoW). It has been drawn in such a manner as to represent a correct implementation of the project. However, in order to guarantee that problems do not compromise the success of the project, a risk management system will be implemented to respond effectively to potential risk and extraordinary events.
本提案中提出的行动计划基于工作说明书（SoW）。它被绘制成这种方式，以表示项目的正确实施。然而，为了保证问题不会影响项目的成功，将实施一个风险管理系统，以有效应对潜在风险和突发事件。
The Project Manager will, on a periodic basis, undertake risk management jointly with the project key persons. The different steps on risk management are:
项目经理将定期与项目关键人员共同进行风险管理。风险管理的不同步骤是：
Risk identification, which involves determining which risks might affect the project, and documenting their characteristics. The PM will carry out regular meetings for that purpose and will record the potential risks on the Risk Record Database.
风险识别，涉及确定可能影响项目的风险，并记录其特征。项目经理将为此目的定期举行会议，并将潜在风险记录在风险记录数据库中。
The risks will be recorded in a form that includes the following information:
风险将以包含以下信息的表格形式记录：
Risk number
风险编号
Identified by (name or project team)
被（姓名或项目团队）识别
Identified when (date)
已识别日期（日期）
Description
描述
Impact on: COST, SCHEDULE, SCOPE, QUALITY (Very low, Low, Moderate, High, Very High, for each one)
影响：成本、进度、范围、质量（每个都非常低、低、中等、高、非常高）
Probability of occurrence (Very low, Low, Moderate, High, Very High)
发生概率（非常低、低、中等、高、非常高）
Range (WBS element identification)
范围（WBS 元素标识）
Status (Identified, monitored, controlled, disappeared)
状态（已识别、监控、控制、消失）
Risk Analysis. In this phase of risk management the impact and likelihood of identified risks are evaluated. The PM, with the assistance of the project members who can best contribute to the evaluation, assess the impact of the risk on cost, schedule, scope and quality, the probability of its occurrence and where, in the project structure, it might show up. This process prioritizes risk according to their potential effect on project objectives.
风险评估。在这个风险管理阶段，评估已识别风险的影響和可能性。项目经理在项目成员的帮助下，这些成员最能贡献于评估，评估风险对成本、进度、范围和质量的影响，其发生的概率以及可能在项目结构中的哪些地方出现。此过程根据风险对项目目标的潜在影响优先排序。
At the end of this process the Risk Record Database will be updated.
此过程结束后，风险记录数据库将得到更新。
Risk Response Planning, which is the process of determining actions or decisions that will reduce the probability or the impact of each risk event. The PM will propose such actions/decisions which will be included in the AIL (Action Item List) when approved.
风险应对计划，即确定降低每个风险事件发生概率或影响的行为或决策的过程。项目经理将在批准后提出此类行为/决策，并将其纳入行动项目清单（AIL）。
Identification of Critical Areas and Risks
识别关键区域和风险
The table below identify all the programmatic and management risks for the development of the Operational Service to the user, as well as indicate a proposed mitigation factors
下表列出了为用户提供运营服务开发的所有程序和管理风险，以及提出的缓解因素.
Table: Identified risks
表格：已识别的风险
Risk
风险 | Probability
概率 | Impact
影响 | Mitigation Measures
缓解措施 |
Alignment of expectations of the service to the provided with the user needs
服务期望与用户需求的对齐 | Low
低 | Medium
中等 | HEAD CRESDA CONSORTIUM will be in regular contact with the users, in order to ensure that the service provided will be fully according to the user needs.
HEAD CRESDA CONSORTIUM 将与用户保持定期联系，以确保提供的服务完全符合用户需求。 |
Difficulties for the Service Provision
服务提供困难 | Low
低 | Medium
中等 | HEAD CRESDA CONSORTIUM staff has a large experience in the provision of operational imagery services. HEAD CRESDA CONSORTIUM shall make use of this large experience in the development of the service and in its provision.
HEAD CRESDA CONSORTIUM 员工在提供操作图像服务方面拥有丰富的经验。HEAD CRESDA CONSORTIUM 将利用这一丰富经验来开发服务和提供服务。 |
Replacement of any of the members of the proposed team
任何拟议团队成员的替换 | Low
低 | Medium
中等 | HEAD CRESDA CONSORTIUM ensures the availability of the proposed team, and their allocation to the development of the project.
HEAD CRESDA CONSORTIUM 确保拟议团队的可用性，并分配他们参与项目开发。 In any case of an unlikely replacement of one person of the proposed team be necessary (e.g. long sickness), HEAD CRESDA CONSORTIUM shall make use of its pool of highly experienced engineers with similar experience to the replaced one.
在任何情况下，如果需要替换提议团队中的一员（例如长期生病），HEAD CRESDA CONSORTIUM 将利用其经验丰富的工程师库，以替换者的相似经验为标准。 |
Risk Mitigation Factors
风险缓解因素
Experience and Know-how
经验和专业知识
The strength of HEAD CRESDA CONSORTIUM lies in the proven experience and know-how of the entire workforce, many of whom have a large experience in Earth Observation activities.
HEAD CRESDA 协会的优势在于整个工作团队的丰富经验和专业知识，其中许多人拥有丰富的地球观测活动经验。
Effective Project Organisation
有效的项目管理
The risk of schedule overrun is addressed by the planning, which allows certain tasks to run in parallel, thereby making optimum use of resources in the time available. Furthermore, HEAD CRESDA CONSORTIUM is able and willing to make additional resources available to the project if a schedule slip is detected and supplementing the team is deemed necessary to recover the schedule.
项目超时的风险通过规划得到解决，规划允许某些任务并行运行，从而在可用时间内最大限度地利用资源。此外，HEAD CRESDA CONSORTIUM 能够并且愿意在发现进度延误并且认为补充团队以恢复进度是必要的时，为项目提供额外资源。
Schedule Risk Mitigation
日程风险管理
In the event that a potential schedule delay is detected by the Project Manager, he will call for additional resources from the pool of highly experienced engineers at HEAD CRESDA CONSORTIUM.
如果在项目经理发现潜在的时间延误，他将从 HEAD CRESDA CONSORTIUM 经验丰富的工程师池中调用额外资源。
It is important to emphasize that at HEAD CRESDA CONSORTIUM, the customer comes first. HEAD CRESDA CONSORTIUM will do everything within its power to ensure that schedule delays are minimized or avoided altogether.
在 HEAD CRESDA CONSORTIUM，强调客户至上至关重要。HEAD CRESDA CONSORTIUM 将尽其所能确保最小化或完全避免进度延误。
Monitoring and Controlling Mechanisms
监控和控制机制
The Project Management Plan (PMP) defines the baseline for the project plans and schedule. The actual progress of the project will be monitored with respect to the schedule defined in the PMP.
项目管理工作计划（PMP）定义了项目计划和进度的基准。项目的实际进度将根据 PMP 中定义的进度进行监控。
HEAD CRESDA CONSORTIUM Project Manager will be responsible for monitoring and controlling the status of the project.
项目经理将负责监控和控制项目的状态。
Schedule Control
日程控制
Microsoft Project from Windows was used for preparing the baseline schedule, and will be used throughout the course of the project, updating the plans with the actual progress and estimated effort-to-finish for each task. This will help to detect critical paths, or tasks that have slipped and might not be possible to finish on time, allowing the Project Manager to take remedial steps, such as re-planning the tasks or redistributing/increasing the level of resources assigned to tasks.
Microsoft Project 从 Windows 中用于准备基线进度计划，并将在整个项目过程中使用，通过更新每个任务的实际情况和预计完成努力来更新计划。这将有助于检测关键路径，或已经延误且可能无法按时完成的任务，使项目经理能够采取补救措施，例如重新规划任务或重新分配/增加分配给任务的资源水平。
Action Items and Open Points
行动事项和开放问题
HEAD CRESDA CONSORTIUM Project Manager will track the progress and status of the action items raised at the progress and review meetings. Microsoft Excel spreadsheets will be used to keep a record of the action items, and for producing action item status reports for inclusion in the monthly progress reports.
HEAD CRESDA CONSORTIUM 项目经理将跟踪进度和审查会议中提出的行动事项的进展和状态。将使用 Microsoft Excel 电子表格来记录行动事项，并为包括在月度进度报告中制作行动事项状态报告。
Cost Control
成本控制
HEAD CRESDA CONSORTIUM financial department will collect data on project expenditures, using the monthly timesheets and expense claims submitted by the staff, and this will be passed to the Project Manager, who will cross-check it with the data that himself has recorded. The actual expenditures will be compared with the planned expenditures in order to assure that the project is in a healthy financial state.
HEAD CRESDA CONSORTIUM 财务部门将收集项目支出数据，使用员工提交的月度工时表和费用报销单，并将其转交给项目经理，项目经理将核对与他自己记录的数据。实际支出将与计划支出进行比较，以确保项目处于健康的财务状态。
HEAD CRESDA CONSORTIUM Project Manager, supported by the Contract Officer will prepare the invoices associated with the successful completion of a payment milestone. HEAD CRESDA CONSORTIUM Contract Officer will be responsible for tracking the status of the invoices that have been submitted.
HEAD CRESDA CONSORTIUM 项目经理，在合同官员的支持下，将准备与支付里程碑成功完成相关的发票。HEAD CRESDA CONSORTIUM 合同官员将负责跟踪已提交的发票状态。
Project Reviews, Meetings, and Reports
项目评审、会议和报告
Reporting to customer shall be implemented by means of periodic reports, supported by progress, review, management and technical meetings.
向客户汇报应通过定期报告实施，并辅以进度、审查、管理和技术会议。
Reporting
报告
Monthly Progress Reports concerning the previous reporting period shall be prepared and transmitted via e-mail to customer by HEAD CRESDA CONSORTIUM Project Manager within the first 5 working days of a reporting period.
关于上一个报告期的月度进度报告应由 HEAD CRESDA CONSORTIUM 项目经理在报告期前 5 个工作日内准备并通过电子邮件发送给客户。
Progress reports will provide a summary of the progress of the project over the last month of activities. They shall be written in a clear and concise style, presenting a realistic assessment of the actual project status, identifying any problem potentially affecting agreed performances, schedule or cost baselines and providing an evaluation of its criticality, as well as proposing corrective actions aimed at keeping to the planned targets.
项目进度报告将对过去一个月活动的项目进展进行总结。报告应采用清晰简洁的风格，对实际项目状况进行现实评估，识别可能影响既定性能、进度或成本基线的任何问题，并提供对其重要性的评估，同时提出旨在保持计划目标的纠正措施。
The progress report shall contain at least the following information:
进度报告应至少包含以下信息：
Management: concise descriptions of all important problem areas, their criticality and their anticipated impact.
管理：对所有重要问题领域的简洁描述，其关键性和预期影响。
Schedule: overall project charts showing the duration and progress of main phase interface events and milestones.
日程安排：展示主要阶段界面事件和里程碑的持续时间及进度的整体项目图表。
Technical: the status of technical problem issues shall be summarised. All technical issues that may have an impact on the schedule, cost or the documentation baseline shall be raised.
技术：应总结技术问题状态。所有可能影响进度、成本或文档基线的技术问题都应提出。
Action Items List: a listing of action items from all previous meetings shall be included showing the status.
行动项目清单：应包括所有以前会议的行动项目列表，并显示状态。
Progress reports shall be prepared using Microsoft Word for Windows, and will be submitted in PDF format. Project status information shall be generated using Microsoft Project and then inserted into the progress report in graphical or tabular form as appropriate.
进度报告应使用 Microsoft Word for Windows 编制，并以 PDF 格式提交。项目状态信息应使用 Microsoft Project 生成，然后根据适当情况以图形或表格形式插入到进度报告中。
Special Situation Schedule Reports
特殊情况时间表报告
Special Situation Schedule Reports shall be prepared and transmitted via e-mail to CUSTOMER by the project manager within 48 hours of him becoming aware of any special situation potentially affecting agreed performances, schedule and/or costs.
特殊情况进度报告应由项目经理在意识到可能影响约定性能、进度和/或成本的任何特殊情况后的 48 小时内，通过电子邮件发送给客户。
Meetings and Reviews
会议和审查
Meeting Schedule
会议日程
Meetings associated to project kick-off, progress and final presentation will be held in accordance to the project schedule.
项目启动、进度和最终展示相关的会议将按照项目进度表进行。
Progress Meetings
进展会议
A monthly Progress Meeting is foreseen throughout the course of the project. The meeting will be held at the level of customer’s Technical Officer, HEAD CRESDA CONSORTIUM Project Manager and End Users, assisted by those technical staff concerned with the specific purpose of the meeting.
项目过程中将安排每月进度会议。会议将在客户技术官员、HEAD CRESDA CONSORTIUM 项目经理和最终用户层面举行，由关注会议特定目的的技术人员协助。
Communication Interface with CUSTOMER
通信接口与客户
The focal point of contact for the managerial, contract and service matters between ESSTI and HEAD CRESDA CONSORTIUM project team is the Project Manager.
ESSTI 与 HEAD CRESDA CONSORTIUM 项目团队在管理、合同和服务事项上的联系焦点是项目经理。
Technical Process
技术流程
Methods, Tools, Techniques
方法、工具、技术
The project planning will be performed using the Microsoft Project planning tool, which implements Gantt Charts, Resource Levelling and Profiling, Production of Reports, Monitoring of Progress, Work Packages, etc.
项目规划将使用微软项目规划工具进行，该工具实现了甘特图、资源平衡和配置、报告生成、进度监控、工作包等。
Documentation will be produced using Microsoft Word for Windows.
文档将使用 Windows 版本的 Microsoft Word 制作。
Databases of action items, SPRs/NCRs, RIDs, ECR/ECP/CCNs, document identifier, etc, shall be managed using Microsoft Excel and/or Microsoft Access.
行动项目数据库、SPR/NCR、RID、ECR/ECP/CCN、文档标识符等应使用 Microsoft Excel 和/或 Microsoft Access 进行管理。
Software Documentation
软件文档
Documentation will be produced using MS-Word for Windows and delivered in Word or PDF format.
文档将使用 Windows 版本的 MS-Word 制作，并以 Word 或 PDF 格式交付。
Management of Subcontractors
分包商管理
The standard rules from HEAD CRESDA CONSORTIUM, for the management of the subcontractors shall be applied for the development of the project. These rules are presented below.
HEAD CRESDA CONSORTIUM 的标准规则应适用于项目分包商的管理。以下为这些规则。
Management and Review of Subcontractor Work Package Outputs
管理与审查分包工作包输出
The outputs of the Work Packages allocated to the Subcontractor will be received and reviewed by HEAD CRESDA CONSORTIUM with the objective of ensuring that they are produced on time and with the required content and level of technical quality.
工作包分配给分包商的输出将由 HEAD CRESDA CONSORZIO 接收并审查，目的是确保它们按时完成，并包含所需的内容和技术质量水平。
In addition to the schedule of deliveries to ESSTI, HEAD CRESDA CONSORTIUM will prepare and maintain an internal plan for delivery to HEAD CRESDA CONSORTIUM of draft versions of project outputs and contributions from the Subcontractor, so that HEAD CRESDA CONSORTIUM can review them with the aim of overseeing the production of the outputs, and ensuring that they are in line with the overall requirements and the philosophy applied to the entire project.
除向 ESSTI 交付的日程安排外，HEAD CRESDA CONSORTIUM 还将准备并维护一份内部计划，用于向 HEAD CRESDA CONSORTIUM 交付项目输出草稿版本和分包商的贡献，以便 HEAD CRESDA CONSORTIUM 能够审查它们，目的是监督输出的生产，并确保它们符合整体要求和应用于整个项目的哲学。
Monitoring of Subcontractors’ Progress
监控分包商进度
The HEAD CRESDA CONSORTIUM Project Manager will receive contributions to the monthly progress reports from the Subcontractors. In this particular case, he will keep a continuous regular personal contact with the Subcontractor thanks to the close location of both companies.
HEAD CRESDA 协会项目经理将从分包商那里收到月度进度报告的贡献。在这种情况下，由于两家公司地理位置接近，他将与分包商保持持续的定期个人联系。
Project Reviews – Coordination between HEAD CRESDA CONSORTIUM and Subcontractor
项目评审 - HEAD CRESDA 协会与分包商之间的协调
The travels plan allows the Subcontractor to attend all the formal review and working meetings in person, so that they are directly involved in those reviews. The HEAD CRESDA CONSORTIUM Project Manager will organise regular and continuous personal meetings with the Subcontractors, in order to coordinate the presentation of the project deliverables by the entire team, and to discuss and agree on the answers to RIDs before arriving at the review meetings with CUSTOMER.
旅行计划允许分包商亲自参加所有正式审查和工作会议，以便他们直接参与这些审查。HEAD CRESDA CONSORTIUM 项目经理将定期与分包商进行持续的个人会议，以便协调整个团队的项目成果展示，并在与客户进行审查会议之前讨论和同意对 RIDs 的回答。
Management of Subcontractor’ Invoices and Payments
管理分包商的发票和付款
HEAD CRESDA CONSORTIUM and its Subcontractor have already reached agreement on individual payment plans for each Subcontractor. In this particular case, the payment plan of HEAD CRESDA CONSORTIUM and its subcontractor HEAD CRESDA CONSORTIUM Imaging, coincides in the same milestones.
HEAD CRESDA CONSORTIUM 及其分包商已就每个分包商的单独付款计划达成一致。在这种情况下，HEAD CRESDA CONSORTIUM 及其分包商 HEAD CRESDA CONSORTIUM Imaging 的付款计划在相同的里程碑上相一致。
Subcontractor’ invoices will be transmitted to HEAD CRESDA CONSORTIUM for approval, before being sent to CUSTOMER.
分包商的发票将在发送给客户之前，提交给 HEAD CRESDA CONSORTIUM 进行审批。
Quality Assurance & Configuration Management
质量保证与配置管理
Quality Assurance
质量保证
The project will have a Software Quality Assurance Manager (SQA), with the responsibility of verifying that procedures are being followed and quality activities defined in the Software Quality Assurance Plan (SQAP) are correctly done.
该项目将配备一名软件质量保证经理（SQA），负责核实是否遵循了程序，并确保软件质量保证计划（SQAP）中定义的质量活动得到正确执行。
The SQA is part of the projects team, therefore is not seen as an outsider, with the purpose of control, but as a team member whose goal is to help the project achieving the best results. The SQA has an interface to the Quality Department, delivering metrics and important information to enable continuous improvement of the existent procedures.
SQA 是项目团队的一部分，因此被视为内部人士，其目的是控制，而不是作为目标是为了帮助项目取得最佳成果的团队成员。SQA 与质量部门有接口，提供指标和重要信息，以促进现有程序的持续改进。
The QA activities encompass all project stakeholders with focus on project members such as Quality Manager and Project Manager and Software Quality Assurance. The responsibilities for each relevant role in the QA process are the following:
QA 活动涵盖所有项目利益相关者，重点关注项目成员，如质量管理员和项目经理以及软件质量保证。每个相关角色在 QA 过程中的职责如下：
Software Quality Assurance Engineer (SQA) is responsible to implement the QA activities in the project according to what is defined in the project’s SQAP. The SQA is appointed and managed by the QM and periodically reports to the PM and QM. For the INNOVALIMA project the QM will be itself the SQA for the project.
软件质量保证工程师（SQA）负责根据项目 SQAP 中定义的内容在项目中实施 QA 活动。SQA 由 QM 任命和管理，并定期向 PM 和 QM 汇报。对于 INNOVALIMA 项目，QM 将亲自担任项目的 SQA。
Project Manager (PM) is responsible to provide to the SQA the necessary support and commitment to implement the QA activities in the project.
项目经理（PM）负责向 SQA 提供实施项目质量保证活动的必要支持和承诺。
Quality Manager (QM) provides guidance to the SQA in the implementation of the QA activities. The QM shall analyse the SQA reports and it shall act in conformance to what is stated in the report. The QM is responsible to define and organize the audits according the defined procedure.
质量管理员（QM）为 SQA 实施 QA 活动提供指导。QM 应分析 SQA 报告，并应按照报告中的内容采取行动。QM 负责根据既定程序定义和组织审计。
The SQA shall conduct detailed quality assessments in order to report the results obtained and corrective actions implemented. Typically, this report is performed at project reviews, and describes the totality of activities, standards, controls and procedures in the lifetime of a software product which establish confidence that the delivered software product, or software affecting the quality of the delivered product, will conform adequately to customer requirements.
SQA 应进行详细的质量评估，以报告获得的结果和实施的纠正措施。通常，此报告在项目评审时进行，并描述软件产品在其生命周期内所有活动、标准、控制和程序的整体情况，从而建立信心，即交付的软件产品或影响交付产品质量的软件将充分符合客户要求。
Below it is included a very draft version of the Quality Assurance Plan.
以下包含了一份非常初稿的质量保证计划。
Quality Assurance Plan (QAP) – Draft
质量保证计划（QAP）- 草稿
Purpose and Scope
目的和范围
The overall purpose of the PA Plan is to lay the foundations for the PA activities that will assure that the characteristics and delivery times of the different products of the project satisfy the requirements, in particular (but not only) with regard to quality levels, of ESSTI.
PA 计划的整体目的是为 PA 活动奠定基础，确保项目不同产品的特性和交付时间满足要求，特别是在（但不仅限于）质量水平方面，符合 ESSTI 的要求。
This Product Assurance Plan covers the activities, within the scope of the project, to be conducted concerning Quality Assurance, Configuration Management and Control, Non-Conformance Management and Control, participation in the preparation of Review Data Packages.
本产品保证计划涵盖了项目范围内有关质量保证、配置管理和控制、不符合项管理和控制的活动，以及参与准备审查数据包的工作。
Management
管理
The designated Quality Assurance Manager will be the responsible for all PA matters within the project. In his role as PA Manager, he will be responsible throughout the duration of the project for the following general activities:
指定质量保证经理将负责项目内所有 PA 事务。在他担任 PA 经理的职责下，他将负责在整个项目期间以下一般活动：
reviewing all products with regard to the required quality standards, such as documentation standards, coding standards, etc.;
审查所有产品是否符合所需的质量标准，例如文档标准、编码标准等；
assuring the completeness of all products, in particular making sure that Review Data Packages are complete and correctly placed under configuration control;
确保所有产品的完整性，特别是确保审查数据包完整且正确地置于配置控制之下；
assure that the project team adhere to the applicable standards and practices, and implementing quick, effective corrective actions if and when any deviations are detected;
确保项目团队遵守适用的标准和实践，并在发现任何偏差时迅速采取有效的纠正措施；
keeping CUSTOMER duly informed as to the current status of the project with regard to PA matters;
确保客户及时了解项目在 PA 事项方面的当前状态
overseeing the reception and control of CFIs, assuring that they are received in the appropriate conditions and placed under effective configuration control;
监督 CFI 的接收和控制，确保它们在适当的条件下接收并置于有效的配置控制之下；
authorising the delivery of products to CUSTOMER
授权向客户交付产品
Documentation
文档
The PA Manager is responsible for producing the following documentation:
PA 经理负责生成以下文档：
PA Plan (as part of the PMP)
PA 计划（作为 PMP 的一部分）
CM Plan (as part of the PMP)
CM 计划（作为 PMP 的一部分）
SPRs/NCRs as and when appropriate
SPR/NCRs 如有必要
PA Report (part of the monthly progress reports)
PA 报告（月度进度报告的一部分）
Configuration Item data Lists
配置项数据列表
Standards, Practices, Conventions and Metrics
标准、实践、惯例和指标
Documentation Standards
文档标准
Documentation standards will assure the following:
文档标准将确保以下内容：
Clarity and completeness of the document information given in the front cover, document change record, identity, table of contents, purpose and scope.
文档封面、文档变更记录、身份、目录、目的和范围所提供的信息的清晰度和完整性。
Consistency of style throughout all documentation.
文档风格的一致性。
Completeness of the documentation with respect to the applicable Document Requirements Definitions (DRDs).
文档针对适用文档要求定义（DRDs）的完整性。
Coding Standards
编码规范
Coding standards will assure the following:
编码标准将确保以下内容：
Clarity and consistency with regard to:
清晰和一致性方面：
Naming of code source files
代码源文件命名
Information provided in the header commentary part at the beginning of each file
文件开头注释部分提供的信息
Naming of code items such as constants, variables, sub-programmes, etc.
代码项（如常量、变量、子程序等）的命名
Avoidance of non-standard features of the chosen implementation language.
避免所选实现语言的非标准特性。
Commentary Standards
评论标准
Comment blocks within each compilation unit will have a standard appearance so that they are easily identified, and avoiding any confusion as to which part of the code the comment is referring.
belongs to the category of code comments, which is a form of programming language syntax used to document the code. It is generally used to explain the purpose, functionality, or usage of a particular section of code. In the context of this article, the translation of the input text into Simplified Chinese is as follows:
每个编译单元内的注释块将具有标准外观，以便易于识别，避免对注释所引用的代码部分产生混淆。
Testing Standards and Practices
测试标准和实践
Testing will follow a formal life-cycle approach consisting of the sequential execution of the following activities:
测试将遵循正式的生命周期方法，包括以下活动的顺序执行：
Analysis of the problem domain, leading to the generation of Test Designs.
问题域分析，导致测试设计生成。
Analysis of the specific requirements belonging to the units under test, leading to the generation of Test Case Specifications conformant with the overall test designs.
分析属于测试单元的具体要求，从而生成符合整体测试设计的测试用例规范。
Analysis of the test execution environments, leading to Test Procedures that permit the execution of the test case specifications.
测试执行环境分析，导致允许执行测试用例规范的测试程序。
Execution of the test procedures on the test execution environments.
执行测试环境中的测试程序。
Evaluation and reporting of the results of the test executions.
测试执行结果的评价和报告。
Generation of SPRs as and when a test result reveals an error in the unit under test.
根据测试结果，在检测到被测单元出现错误时即时生成 SPR。
Regression testing on receipt of a software change to correct an error reported in an SPR.
回归测试，以纠正 SPR 中报告的错误而进行的软件更改接收。
Note that steps 4 to 7 may be performed in parallel, for example, SPRs will be raised as soon as an error is found, without waiting until all tests have been executed once. Similarly, regression testing will be conducted as soon as it is considered convenient, not necessarily when all SPRs have been processed.
请注意，步骤 4 至 7 可以并行执行，例如，一旦发现错误，就会立即提出 SPR，而不必等到所有测试都执行过一次。同样，回归测试将在认为方便的时候进行，不一定是在所有 SPR 处理完毕后。
Test results will be provided in Test Report forms, which will be signed-off by the tester, the Project Manager and the PA Manager.
测试结果将以测试报告表的形式提供，将由测试员、项目经理和 PA 经理签字确认。
Similarly, SPRs will be signed and authorised by the Project Manager and PA Manager before being sent to the CUSTOMER for further processing.
同样，SPRs 将在发送给客户进一步处理之前由项目经理和 PA 经理签署和授权。
Reviews and Audits
评论和审核
The PA Manager will be a required participant in the review of all Review Data Packages before they are delivered to CUSTOMER.
PA 经理将在所有审查数据包交付给客户之前，必须参与审查。
The PA Manager will conduct monthly audits of the Project team´s practices and procedures, and of the status of the configuration management system, reporting the results in a PA Report to be included in the monthly Progress Reports.
PA 经理将对项目团队的实践和程序以及配置管理系统的状态进行每月审计，并在每月进度报告中包含的 PA 报告中报告结果。
Test
测试
A traceability matrix will be maintained in order to trace from SoW Requirements through Test Designs, Test Case Definitions/Specifications to Test Results and SPRs, in order to assure complete test coverage of the subject requirements.
将维护一个可追溯性矩阵，以便从 SOW 需求追踪到测试设计、测试用例定义/规范，直至测试结果和 SPR，以确保对主题需求的全面测试覆盖。
Problem Reporting and Corrective Actions
问题报告和纠正措施
Problem Reporting shall be done raising the corresponding SPRs. Non Conformance and RFW/RFD Procedure.
问题报告应通过提出相应的 SPR 进行。不符合和 RFW/RFD 程序。
Risk Management
风险管理
With regard to PA matters, risks will be minimized through daily monitoring of the project’s activities, participation in all formal reviews, etc.
关于 PA 事项，将通过每日监控项目活动、参与所有正式审查等方式将风险降至最低。
It is to be noted that in the event of a deviation from the schedule, the industrial consortium has at its disposal additional human resources that it is able and willing to provide to the project in a timely manner to mitigate the impact of the deviation and bring the work back on schedule. If the cause of the deviation is external, and beyond the control of the consortium, the provision of additional resources might have to be linked to a CCN.
应注意的是，如果出现偏离计划的情况，工业财团拥有额外的人力资源，能够并及时提供这些资源给项目，以减轻偏差的影响，使工作恢复到计划进度。如果偏差的原因是外部的，且超出了财团的控制范围，提供额外资源可能需要与 CCN 挂钩。
Configuration Management
配置管理
The consortium will use a centralized repository for source code and documentation. A Software Configuration Management Plan will be produced describing all configuration procedures.
联盟将使用集中式存储库来存储源代码和文档。将制定一份软件配置管理计划，描述所有配置流程。
The project will use Concurrent Version System (CVS) as the support tool for configuration identification and version control purposes. The CVS tool supports automated CIDL production and baseline identification for control and report purposes, tagging for review data package and release management support among other features.
该项目将使用并发版本系统（CVS）作为配置识别和版本控制的支撑工具。CVS 工具支持自动化 CIDL 生成、基准识别以供控制和报告之用，以及为审查数据包和发布管理提供标签等功能。
Personnel allocated by the consortium to this project have received training in quality management, configuration management and version control.
该联盟分配给此项目的员工已接受质量管理、配置管理和版本控制方面的培训。
Documentation Management and Control
文档管理与控制
All documentation produced is uniquely numbered and controlled through a documentation database system.
所有生成的文档都是唯一编号并通过文档数据库系统进行控制的。
Documentation Database
文档数据库
An in-house tool will be used to manage the project documentation. The project team and especially the configuration manager will be able to perform the following tasks:
内部工具将被用于管理项目文档。项目团队特别是配置经理将能够执行以下任务：
To generate document codes compliant with the HEAD CRESDA CONSORTIUM document coding standard
生成符合 HEAD CRESDA CONSORTIUM 文档编码标准的文档代码
To keep track of all the documents generated in the frame of the project
为了跟踪项目框架内生成的所有文档
To keep track of all the applicable and reference documents, which will be saved with the incoming code and a project code. This last code defines the use of the document within the frame of the project (i.e. Statement of Work, Reference Document…).
为了跟踪所有适用的和参考文件，这些文件将与传入的代码和项目代码一起保存。最后一个代码定义了文件在项目框架内的用途（即工作说明书、参考文件等）。
To manage versions of all documents and maintain the Documents Reference Line of the project
管理所有文档的版本并维护项目的文档参考线
To search all documents matching some conditions by means of the Search Tool
通过搜索工具搜索所有符合某些条件的文档
To generate reports containing the Reference Line, data on all documents or print all documents within a type. These reports can be saved in access, excel or HTML format
生成包含参考线的报告，包含所有文档的数据或打印同一类型的所有文档。这些报告可以保存为 Access、Excel 或 HTML 格式。
The tool is embedded within a global documentation tool used within the company, which keeps track of all documents that are contained in the Reference Line of all projects. This task is performed by a routine process for all open projects. When a project is closed, all documents of that project are saved permanently in a different database.
该工具嵌入在公司使用的全球文档工具中，该工具跟踪所有包含在所有项目参考线中的文档。此任务对所有开放项目通过常规流程执行。当一个项目关闭时，该项目的所有文档将永久保存在不同的数据库中。
Software Project Management Plan
软件项目管理计划
This section describes the standard procedures for the development of a complete software project based on customer specifications. It will be used accordingly to the software development and integration needs during the contract execution.
本节描述了基于客户规格的完整软件项目开发的标准程序。它将在合同执行期间的软件开发和集成需求中得到相应应用。
Software Development Life Cycle
软件开发生命周期
The project will be developed and evolved, where needed, following a waterfall approach, where the corresponding engineering disciplines are arranged sequentially in different phases to facilitate its implementation and control. This is applicable to the software major components to be addressed on the project. The identified phases are as follows:
该项目将根据需要开发和演进，采用瀑布式方法，将相应的工程学科按顺序安排在不同的阶段，以促进其实施和控制。这适用于项目要解决的主要软件组件。确定阶段如下：
Requirements Definition Phase, with the objective to specify the system requirements and to define the external and internal interfaces of the whole system. The System Requirements Specification and the Interface Control Document shall be the major deliverables, part of the Technical Specification folder. A System Requirements Review (SRR) shall take pace in order to review the produced documents in order to consolidate the system requirements and interfaces for the future phases of the project.
需求定义阶段，旨在明确系统需求并定义整个系统的外部和内部接口。系统需求规范和接口控制文档应为主要交付成果，属于技术规范文件夹的一部分。应进行系统需求审查（SRR），以审查产生的文档，以便巩固项目未来阶段的需求和接口。
Design Definition Phase, aiming at to define the architecture of system With regard to the testing activities, this phase shall deal with the definition of the verification and validation test plans as well as the specification of the Unit and Integration tests, as this phase end with the holding of the Preliminary Design Review (PDR)
设计定义阶段，旨在定义系统的架构。关于测试活动，此阶段应处理验证和验证测试计划的定义以及单元和集成测试的规范，因为此阶段以初步设计评审（PDR）的举行结束.
Implementation Phase, which comprises the coding and unit testing of the three software deliveries to be produced. The validation campaign shall be take place at developer’s premises, where the system tests applicable to each version shall be executed, with the objective to ensure that the software meets the requirements specifically allocated to each software version.
实施阶段，包括即将生产的三个软件交付的编码和单元测试。验证活动将在开发者的场所进行，在那里将执行适用于每个版本的系统测试，目的是确保软件满足分配给每个软件版本的具体要求。
Qualification phase. This phase represents a formal qualification of the first official version of the software. Prior to holding the Qualification Review (QR), a clean-up period shall take place in order to perform all corrections detected during the CDR and to generate the first official version of the system components.
资格阶段。此阶段代表软件第一个官方版本的正式资格认定。在举行资格评审（QR）之前，应进行清理期，以便执行在 CDR 期间发现的全部纠正措施，并生成系统组件的第一个官方版本。
The QR is a formal milestone that shall review the status of the software and documentation. Upon a successful review (or at its close-out), the software will be handled to the customer, and the provider shall start carrying out maintenance activities upon the software and documentation.
二维码是一个正式的里程碑，将审查软件和文档的状态。在审查成功（或结束）后，软件将被交付给客户，提供商应开始对软件和文档执行维护活动。
Acceptance phase. A formal acceptance of the software shall take place after the QR, where the software may had suffered alterations, as a result of the correction of SPR raised by the user community during the maintenance phase. As a consequence a second official version of the software shall be subject to testing. The Acceptance Review (AR) shall serve to verify that all SPR are closed and shall establish the future project activities to be performed up to the end of contract (EoC).
验收阶段。在 QR 之后，软件可能因用户社区在维护阶段提出的 SPR 修正而遭受更改，应正式验收该软件。因此，软件的第二个官方版本应接受测试。验收评审（AR）应用于验证所有 SPR 均已关闭，并应确定直至合同结束（EoC）应执行的未来项目活动。
Maintenance and software evolutions: During this phase, the developer shall perform analysis, troubleshooting and correction of software and configuration problems reported by users. It may also cover small SW evolutions that need to be activated on a case-to-case basis, with authorisation of the customer. The developers shall analyse the implications of the software evolution and prepare a proposal containing the technical aspects as well as the financial costs.
维护和软件演进：在此阶段，开发者应执行用户报告的软件和配置问题的分析、故障排除和纠正。也可能包括需要根据具体情况激活的小型软件演进，需得到客户的授权。开发者应分析软件演进的影响，并准备一份包含技术方面以及财务成本的提案。
Verification and Validation Approach
验证与验证方法
The objective of the V&V programme is to control that the system is built according to the design and that it meets its requirements.
V&V 项目目标是确保系统按照设计构建，并满足其要求。
Activities are classified into unit tests (UT), integration tests (IT) and system tests (ST).
活动被分为单元测试（UT）、集成测试（IT）和系统测试（ST）。
Unit tests verify the correct implementation of the software modules identified in the Detailed Design Documents, in isolation w.r.t. the other modules.
单元测试验证详细设计文档中确定的软件模块的正确实现，与其他模块相对独立。
Integration tests verify the correct implementation of the architectural modules, understood as aggregations of the smaller modules previously verified.
集成测试验证架构模块的正确实现，这些模块被视为之前已验证的较小模块的聚合。
System tests validate the software application as a whole, and fundamentally consist of end-to-end test cases simulating realistic use-case scenarios checking that the software complies to the applicable requirements.
系统测试验证整个软件应用，本质上包括模拟现实使用场景的端到端测试用例，以检查软件是否符合适用的要求。
Additionally, acceptance tests (AT) will be agreed with the customer as a given subset of the system tests.
此外，将同意与客户作为系统测试的一个子集的验收测试（AT）。
In this section, we shall refer to verification as the process and activities devoted to confirm that the system has been build according to the design (ADD, DDD). Its objective is to prove that the system is “built right”.
在本节中，我们将验证过程和活动称为确认系统是否按照设计（ADD、DDD）构建的过程。其目标是证明系统是“正确构建的”。
Verification activities cover:
验证活动包括：
The unit testing.
单元测试。
The integration testing, aimed to check the software integration.
集成测试，旨在检查软件集成。
On the other hand, validation is the process to confirm that the requirements baseline functions and performances are correctly and completely implemented in the final product. In other words, the validation checks that the product is compliant with the user and the technical requirements (URD). Its objective is to prove that the system built is the “right one”.
另一方面，验证是确认需求基线功能与性能在最终产品中得到正确和完整实现的过程。换句话说，验证检查产品是否符合用户和技术要求（URD）。其目标是证明所构建的系统是“正确的”。
The validation covers:
验证范围包括：
The review of the design against the specification.
设计符合规格的审查。
The system inspections and tests.
系统检查和测试。
The factory qualification.
工厂资格
The on-site acceptance activities.
现场验收活动。
Unit tests
单元测试
Purpose
目的
The aim of the Unit Testing (UT) is to check the conformance of each software module with its detailed design, i.e. to test that each individual software module behaves according to what it is expected from its detailed specification.
单元测试（UT）的目的是检查每个软件模块与其详细设计的符合性，即测试每个单独的软件模块是否按照其详细规格所期望的行为。
Unit testing tasks can be summarised as follows:
单元测试任务可以概括如下：
Test design and test cases specification.
测试设计和测试用例规范。
Review for suitability of test cases for their intended purpose.
审查测试用例是否符合预期目的的适用性。
Set up necessary files needed for test execution (e.g. test drivers, scripts, makefiles ...)
设置测试执行所需的必要文件（例如测试驱动程序、脚本、makefile 等）
Test execution (compile needed components, link to an executable file, examine results ...).
测试执行（编译所需组件，链接到可执行文件，检查结果...）。
Updates in source/test files due to test results.
源/测试文件因测试结果而更新。
Execute non-regression test cases after software updates.
执行软件更新后的非回归测试用例。
Review of test results.
测试结果综述
Approach
方法
Unit tests shall be executed at the development platform, and shall be executed using a simple test driver and stubs for those operations that are not implemented or that are too complex to be used directly. Sometimes, test execution will be made under the control of the debugger.
单元测试应在开发平台上执行，并应使用简单的测试驱动程序和存根来执行那些未实现或过于复杂而无法直接使用的操作。有时，测试执行将在调试器的控制下进行。
Unit tests will be considered as non-regression tests and will be automated.
单元测试将被视为非回归测试并实现自动化。
The technique for test case specification will be black-box testing, based in class partitioning of the input and output domains. White box testing techniques will be used when necessary for testing features highly related to the operation internals or for providing the required test coverage (if not achievable using black-box only).
测试用例指定的技术将是黑盒测试，基于输入和输出域的类划分。在测试与操作内部高度相关的功能或提供所需的测试覆盖率（如果仅使用黑盒测试无法实现）时，将使用白盒测试技术。
Unit testing detailed information (test designs and test cases) will be included in the test driver. Test results will be first validated by visual inspections, and thereafter these first results will be used to search for differences in the actual results (non-regression testing).
单元测试的详细信息（测试设计和测试用例）将包含在测试驱动程序中。测试结果将首先通过视觉检查进行验证，然后这些初步结果将用于搜索实际结果中的差异（非回归测试）。
Integration tests
.
集成测试
Purpose
目的
The objective of integration testing is to build the whole components from its constituent software modules and demonstrate that the implementation matches the architectural design, especially focusing on the interface between modules.
集成测试的目标是从构成软件模块中构建整个组件，并证明其实施与架构设计相符，特别是关注模块之间的接口。
To start the integration tests, each individual component module has to be successfully tested at unit level. Then drivers and stubs, emulating other system components, used during the unit tests shall be replaced by the actual modules.
为了启动集成测试，每个单独的组件模块必须在单元级别成功测试。然后，在单元测试期间使用的模拟其他系统组件的驱动程序和存根应被实际模块所取代。
Software integration tests shall be performed and executed at the development environment, and no integration tests shall be executed at the target one.
软件集成测试应在开发环境中进行和执行，且不得在目标环境中执行集成测试。
The items submitted to integration testing will be all individual source code modules. Integration testing is basically concerned with software interface features, including:
提交给集成测试的项目将是所有单个源代码模块。集成测试基本上关注软件接口功能，包括：
Design hierarchy with reference to architecture of the system.
设计系统架构参考的层次结构。
Information flow between separate software components.
信息流在独立的软件组件之间。
Provision of functions which are built up by different modules working together.
提供由不同模块协同工作构建的功能。
Checking that a component provides what is expected by other components.
检查组件是否提供其他组件所期望的功能。
Detection of inter-module undesired interactions
检测模块间不期望的交互
Approach
方法
Integration tests shall be executed at the development platform, similarly to the unit tests but using the real modules instead of stubs.
集成测试应在开发平台上执行，类似于单元测试，但使用真实模块而不是存根。
System/Acceptance tests
系统/验收测试
Purpose
目的
The objective of system (or validation) testing is to verify that the deliverable software is compliant with the system specifications.
系统（或验证）测试的目标是验证交付的软件是否符合系统规格。
Software validation will be based on:
软件验证将基于：
System tests successfully passed.
系统测试成功通过。
Requirements not validated by Test, have been validated using other techniques such as review of design, inspection of code or analysis.
测试未验证的要求已通过其他技术进行验证，例如设计审查、代码检查或分析。
The objective of acceptance testing is to verify that the deliverable software is compliant with the requirements specification. It is proposed to conduct the acceptance testing with a subset of the system test cases and procedures used during the validation of the software.
验收测试的目的是验证交付的软件是否符合需求规范。建议使用在软件验证期间使用的系统测试用例和程序的一部分来进行验收测试。
Approach
方法
The system tests will verify the system requirements. For this, the development team shall identify the system test cases and define the corresponding system test procedures that shall be documented System Test Specification (STS).
系统测试将验证系统需求。为此，开发团队应确定系统测试用例并定义相应的系统测试程序，这些程序应记录在系统测试规范（STS）中。
The STS document therefore defines the complete set of test cases that fully validates all the software requirements. According to the test cases, in addition the test data necessary for their execution has also been identified. The test data will be produced before the execution of the system test campaign.
因此，STS 文档定义了完整的一组测试用例，这些测试用例全面验证了所有软件需求。根据测试用例，还确定了执行它们所需的测试数据。在系统测试活动执行之前将生成测试数据。
Resources
资源
The V&V Manager is responsible for the planning and execution of all the V&V activities throughout the life of the project. During the V&V campaigns, additional human resources will be allocated to ensure that the planned activities are executed in due time.
V&V 经理负责在整个项目生命周期内规划并执行所有 V&V 活动。在 V&V 活动中，将分配额外的人力资源以确保计划活动按时执行。
The QA Manager will ensure that the staff assigned to the system test activities has the necessary experience, knowledge and skills to be able to carry out their assigned roles effectively and efficiently. This assurance may include identifying the need for specific training, which may be met by attendance to internal and/or external courses.
QA 经理将确保分配给系统测试活动的员工具备必要的经验、知识和技能，能够有效地执行其分配的角色。这种保证可能包括识别对特定培训的需求，这可能通过参加内部和/或外部课程来满足。
It is to be noted that in the event of a deviation from the schedule, the developer has at its disposal additional human resources that it is able and willing to provide to the project in a timely manner to mitigate the impact of the deviation and bring the work back on schedule. If the cause of the deviation is external, and beyond the control of the developer, the provision of additional resources might have to be linked to a CCN.
应注意，如果出现偏离计划的情况，开发商拥有额外的人力资源，能够并及时提供这些资源以减轻偏差的影响，使工作恢复到计划进度。如果偏差的原因是外部因素，且超出开发商的控制范围，提供额外资源可能需要与变更控制通知（CCN）相关联。
Additional test tools may be required for other functionalities related to system interfaces. For instance: shell scripts to perform different tasks on the input / output files as counting, filename checking, content filtering, etc…
可能需要额外的测试工具来处理与系统接口相关的其他功能。例如：用于在输入/输出文件上执行不同任务的 shell 脚本，如计数、检查文件名、内容过滤等……
Execution and Control of the Validation Activities
执行和控制验证活动
Each major validation review is preceded by a Test Readiness Review (TRR). During this review, the resources necessary for the validation event are inspected to ensure that they are available and that the campaign can start with confidence that it will succeed. In particular, the following points shall be reviewed:
每次主要验证审查之前都有一项测试就绪审查（TRR）。在此审查期间，将检查验证活动所需的资源，以确保它们可用，并确保活动能够有信心开始，预期将成功。特别是，以下要点应予以审查：
The hardware necessary for the execution of the tests is available.
测试执行所需的硬件已备齐。
The software is defined, properly configured and stable, and no outstanding NCRs or SPRs exist that can prevent the success of the campaign.
该软件定义得当，配置正确且稳定，不存在任何可能妨碍活动成功的未解决 NCR 或 SPR。
The detailed test procedures are available.
详细测试流程可供查阅。
The necessary verification & validation tools described in the V&V plan are available.
必要的验证与验证工具在 V&V 计划中已描述，并可使用。
The necessary input data sets described in the V&V plan are available.
必要输入数据集在 V&V 计划中已描述，并可获取。
The human resources necessary for the execution, supervision and documentation of the tests are available.
测试的执行、监督和文档编制所需的人力资源可用。
The actual execution of the validation activities will be performed according to the following process:
实际执行验证活动将按照以下流程进行：
Execution of the test procedures on the test execution environments.
执行测试环境中的测试程序。
Evaluation and reporting of the results of the test executions.
测试执行结果的评价和报告。
Generation of SPRs as and when a test result reveals an error in the unit under test.
根据测试结果，在检测到被测单元出现错误时即时生成 SPR。
Regression testing on receipt of a software change to correct an error reported in an SPR.
回归测试，以纠正 SPR 中报告的错误而进行的软件更改接收。
Note that these steps may be performed in parallel; for example, SPRs will be raised as soon as an error is found, without waiting until all tests have been executed once. Similarly, regression testing will be conducted as soon as it is considered convenient, not necessarily when all SPRs have been processed.
请注意，这些步骤可以并行执行；例如，一旦发现错误，就会立即提出 SPR，而不必等到所有测试都执行过一次。同样，回归测试将在认为方便的时候进行，不一定是在所有 SPR 都处理完毕后。
The V&V Manager is responsible for the execution of the validation activities during major milestones. The PA Manager is responsible for the supervision of this execution to document that it is performed according to the procedures established in this plan and the applicable documents. The following considerations will be taken into account during this phase:
V&V 经理负责在主要里程碑期间执行验证活动。PA 经理负责监督这一执行过程，以记录其是否按照本计划和相关文件中规定的程序执行。在此阶段将考虑以下因素：
Tests will be run sequentially and every test execution will be documented in a separate test report.
测试将依次进行，每个测试执行都将单独记录在一份测试报告中。
For problem reporting and corrective actions, the standard procedure will be followed, making use of SPRs, NCRs, SW Modification Reports, etc.
对于问题报告和纠正措施，将遵循标准程序，利用 SPR、NCR、SW 修改报告等。
When a test fails, an appropriate problem report will be generated and sent to the appropriate parties for actioning.
当测试失败时，将生成适当的错误报告并发送给相关方进行处理。
If a given test is affected by an open SPR, the execution of that test will be suspended pending a correction to the SPR. It will be resumed when an appropriate correction is made, at which time the test will be repeated. If the SPR identifies other tests that may be affected by the problem, they too will be repeated (regression testing).
如果给定的测试受到开放 SPR 的影响，该测试的执行将被暂停，直到对 SPR 进行修正。一旦做出适当的修正，测试将恢复，此时将重新进行测试。如果 SPR 识别出其他可能受到该问题影响的测试，它们也将被重新进行（回归测试）。
Overall testing may be suspended if a serious error or deficiency is discovered in the test environment or one that affects the whole or a large part of the integrated software under test.
如果测试环境中发现严重错误或缺陷，或者影响整个或大部分待测集成软件的错误，则整体测试可能被暂停。
The result of the validation activities is the Software Validation Report (SVR) and the Test Execution Records (TERs). One TER is issued for each test execution, and it shall contain a detailed log of the activity and a result, namely if the test is PASSED, PASSED with OBSERVATIONS (something not affecting compliance shall be noted) or FAILED. The results of the TERs are synthesized in the SVR, including an analysis of coverage, problems, etc. Test Execution Records, will be signed-off by the tester, the Project Manager and the QA Manager.
验证活动的结果是软件验证报告（SVR）和测试执行记录（TERs）。每个测试执行都会颁发一个 TER，它应包含活动的详细日志和结果，即测试是否通过、通过但有观察结果（不影响合规性的内容应予以注明）或未通过。TERs 的结果将在 SVR 中综合，包括覆盖率、问题等分析。测试执行记录将由测试员、项目经理和 QA 经理签署。
After the test activities have been completed and the documentation generated, a Test Review Board (TRB) with Customer participation is convened. The test review board will:
测试活动完成后，生成文档后，将召开一个包含客户参与的测试评审委员会（TRB）。测试评审委员会将：
Review the test reports.
审查测试报告。
State on the results (e.g. compliance vs. expectation).
关于结果说明（例如，合规性 vs. 预期）。
Issue NCRs, if any.
如需，则发出 NCR。
If the conclusion is that the validation is not successful: set-up an action plan.
如果结论是验证不成功：制定行动计划。
If the conclusion is that the validation is successful: issue a final approval
如果结论是验证成功：发出最终批准
The V&V process will be considered completed when the Customer and the supplier mutually agree that the identified requirements have been validated and that the associated V&V objectives have been fully achieved.
V&V 过程将在客户和供应商双方同意已验证所识别的需求，并且相关 V&V 目标已完全实现时视为完成。
