软件生存期过程（2）

　　11．1．2 设计和开发

　　此项活动含有下述任务：

　　11.1. 2.1 应当根据可适用的文档标准设计每个指定的文档的格式、内容说明、页码编号、图／表的设 置、产权／保密标记、包装和其它条文。

　　11．1．2．2 应当保证文档的输入数据经过验证确定是否是原始数据并且适当。可以使用自动文档开发 工具。

　　11．1．2．3 应当对照着文档标准评审已准备好的文档的格式、技术内容和表现风格。

　　11．1．3 生产和发行

　　此项活动含有下述任务： 文档应当生产和包装，应当根据计划向预期的读者提供所需要的文档。可用纸、电子或其它媒体生 产和发行文档。主要资料的储存应当适当考虑项目的记录、保密、维护和备份。

　　11．1．4 维护

　　此项活动含有下述任务：当要修改一个现有的产品时应当执行这项任务（见第10章）。正处于配置管理、修改中的产品应当 依据第11．2条进行管理。

　　11．2 配置管理过程

　　配置管理是在系统的整个生存周期中实施管理和技术步骤的一个过程。它指明、定义一个系统的配 置项并指定基线；它控制对配置项的修改和公布；它记录和报告配置项的状态和修改请求；它保证各配 置项的完善和正确；它还控制配置项的储存、处理和交付。
　　此项活动含有下述任务：
　　a.过程建工；
　　b．配置标识；
　　c．配置控制；
　　d．配置状态计算；
　　e．配置审计；
　　f．储存、处理和交付。

　　11．2．1 过程建立

　　此项活动含有下述任务： 应当制订一个配置管理计划并将其写成文档。该计划应当指定：配置管理活动、执行这些活动的过 程，对执行配置管理和活动负责的机构和它们与其它机构（例如软件开发机构）的关系。该计划可以是系 统配置管理计划的一部分。

　　11．2．2 配置标识

　　此项活动含有下述任务： 应当为项目要控制的配置项和它们的版本的标识制定一个方案。应当为每个配置项和它们的版本 指出：建立该基线的文档、含有该文档的媒体、它们的参考版本和其它指定资料。一个版本可以是中间版 本也可以是最终版本。

　　11．2．3 配置控制

　　此项活动含有下述任务： 应当执行下面的任务：标识和记录修改请求；分析和评价修改；批准或拒绝批准请求；已修改项的实 现、验证和发行。应当对每个修改进行审计跟踪，可以跟踪修改的原因和对修改的授权。应当仲裁、控制 和审计对受控制项的使用，以保持关键功能的安全性或保密性。”

　　11．2．4 配置状态计帐

　　此项活动含有下述任务： 管理记录受控制项的现状和历史（包括将要准备的基线）的状态报告。状态报告最好包括项目改变的数量、配置项的最新版本，版本证书的版本号及各版本之间的对比。

　　11．2．5 配置审计

　　此项活动含有下述任务： 应当决定和保证：
　　a. 与需求相对照，配置项在功能上是完善的；
　　b．配置项在物理上是完善的（不管它的设计和代码是否反映了最新的技术）。配置审计可以作为 单独的活动进行，也可以作为合同所要求的审计程序（见第11．3．2条）的一部分。

　　11．2．6储存、处理和交付

　　此项活动含有下述任务： 应当正式控制软件和文档的储存、处理和交付。在系统生存期内应当保存代码和文档的主拷贝。特 别是含有安全和保密的关键功能的代码和文档，应当依据所涉及的机构的政策来储存、处理和交付。

　　11．3 合同要求的评审和审计过程

　　合同所要求的评审和审计过程为需方和供方之间的正式的、用合同建立的交流提供一个框架。

　　11．3．1 合同要求的评审过程

　　当进行合同要求的评审时，为了进行评价和批准，供方向需方提供生存周期活动的状态和产品或项 目的一个阶段的状态。合同要求的评审从管理或技术的两个方面、在整个合同期内进行。
　　此过程含有下述活动：
　　过程建立；
　　管理评审；
　　技术评审。

　　11.3.1.1 过程建立

　　此项活动含有下述任务： 合同要求的评审过程应当符合下面的一般要求：

　　a．应当按照项目计划中的规定在预定的里程碑进行定期评审。当需方或供方任何一方认为必要 时最好建议进行特别评审；

　　b．应当记录在评审中已经检测出的全部问题，并进入改正过程（第11．6条）；

　　c．进行评审所要求的全部资源应当经当事双方同意。这些资源包括人员、地点、设备、硬件、软件 和工具；

　　d．对每次评审，当事双方最好对下述各项取得统一意见：会议的日程、要评审的产品（活动或阶段 结果）、评审的范围和步骤、进入和退出评审的准则；

　　e．在完成评审之后，供方应当立即将该评审写出文档，并将一式两份中的一份交给需方。需方将’ 把评审的执行情况（例如批准、不批准或以后批准）告诉供方；

　　f．当事双方应当对活动项的责任和终止准则达成协议。

　　11．3．1．2 管理评审

　　此项活动含有下述任务： 应当结合可使用的项目计划、时间表、标准和指南评价项目的状态。管理评审最好对下述各项提供 建议：
　　a．依据计划对过程、产品或服务的状态进行评价；
　　b. 通过充分地分配资源来保持对项目的全面控制；
　　c．改变项目的方向或确定改变计划的必要性。

　　11．3．1．3 技术评审
　　此项活动含有下述任务：

　　11．3．1．3．1 应当用技术评审评价特定的产品或服务并提供证据，证明：
　　a．产品和服务符合它们的规格说明；
　　b．软件产品的开发、操作和服务是根据项目的计划、进度、标准和指南进行的；
　　c．对软件产品的改变是适当的，这些改变只对配置管理过程（第11．2条）指出的系统领域有影响。

　　11．3．1.3.2 如果进行技术评审，则应当在满意地结束下述开发过程活动（第8章）之后进行。这些活动 是：系统需求分析和系统设计、软件需求分析、软件结构设计、软件的详细设计、软件集成、系统集成和系 统鉴定测试。应当按照进度评审产品符合使用标准和规范的情况。如果必要，这些评审可以结合进行或 重复进行。

　　11．3．2 合同要求的审计过程
　　在进行合同要求的审计时，需方评价供方的产品和活动，重点确认符合需求、规格说明、标准、过程 和计划的情况。 此过程含有下述活动：
　　a．建立过程；
　　b．功能性配置审计（FCA）；
　　c．物理配置审计（ PCA）；
　　d. 过程中的审计。

　　11．3．2．1 过程建立
　　此项活动含有下述任务：审计将由需方或需方指定的独立的代理人进行。供方应当与需方或代理人合作。审计人员对所审 计的产品或活动不应当负有直接的责任。合同要求的审计过程应当符合下面的一般要求：
　　a. 审计应当在项目计划中预先指定的里程碑进行；
　　b．审计所需要的全部资源需经过当事双方的同意；这些资源包括支持人员、地点、设备、硬件、软 件和工具；
　　c．对每项审计当事双方应当对下面各项取得一致：日程、要评审的产品（和一项活动或一个阶段 结果）、审计的范围和步骤、进人和退出审计的准则；
　　d．在完成审计之后，应当把审计结果写成文档交给供方；供方应当将在审计中发现的问题、为解 决这些问题所计划的改正活动告诉需方；
　　e．当事双方应当就改正活动项的责任和结束准则达成一致意见。

　　11．3．2．2 功能性配置审计（FCA）
　　此项活动含有下述任务： 为了对照SCI的规格说明评审它的实际性能，应当进行FCA。应当对SCI的可交付的版本实施 FCA。最好评审测试数据以决定它是否与规格说明相符。应当检查测试报告和用户手册是否完善和适当。

　　11．3．2．3 物理配置审计（ PCA）
　　此项活动含有下述任务： 为了对照SCI的设计文档评审它的已完成的版本，应当进行PCA。PCA最好包括对设计文档、代 码集、手册和质量记录的详细审计，以保证列编的配置已反映在文档中。应当确定文档中所描述的、用于 验收SCI的验收评审和测试需求是否恰当。
　　注：FCA活动和PCA活动可以结合进行。

　　11．3．2．4 过程中的审计
　　此项活动含有下述任务：

　　11．3．2．4.1 需方将指明过程中的审计及其范围。

　　11．3．2．4．2 为了保证活动和任务正在按照事先确定的准则进行，而且对过程的控制是有效的，应当对进行中的过程进行审计。

　　11．4 验证和确认过程
　　验证的目的是确定系统需求是否完善和正确，每个开发阶段的产品是否完成了前面的阶段对该阶段提出的需求和条件。
　　确认的目的是决定最终的、已完成的系统是否符合所规定的需求。对于成本和性能有效性的验证和确认（V&V）最好结合开发过程（或操作过程、维护过程）及早进行。V&V并不改变供方或开发者的评价责任，相反，V&V是这种责任的补充。 此过程可以由独立于供方的一个机构进行。在这种情况下，此过程叫做独立的验证和确认（ V&V）过程。
　　此过程含有下述活动：
　　a. 过程建工；
　　b．需求验证；
　　c．设计验证；
　　d．代码验证；
　　e．集成验证；
　　f．文档评审；
　　g．确认。

　　11．4．1 过程建立
　　此项活动含有下述任务：

　　11．4．1．1 应当决定正在考虑中的项目是否进行V&V，并决定在进行V&V时机构的独立程度。应当分析项目需求的关键性。
　　关键性可以用下述条件来衡量：
　　a．在一个系统或系统需求中导致死机、人员伤害、任务失败、财经上的或灾难性的设备损失或损坏的潜在的、未检测出的错误；
　　b．要使用的软件开发技术的成熟程度和有关的风险；
　　c．资金和资源的可获得性。

　　11．4．1．2 如果项目保证进行V&V，应当建立一个V&V过程以验证和评价该系统。

　　11．4．1．3 如果项目保证进行 IV＆V，应当选择进行 IV&V的机构。 IV&V的实施人员有足够的不受机构约束的自由度和权力来完成V&V活动。

　　11．4．1．4 在对上述范围、规模、复杂性和关键性进行分析的基础上，应当规定目标生存周期活动和需要V＆V的产品。应当为目标生存周期活动和产品选择V&V活动和任务（第11．4．2至11．4．7条），包括完成这些任务的方法、技术和工具。

　　11．4．1．5 应当以上面指出的 V&V任务为基础制订一个 V＆V计划，并将其写成文档。该计划应当涉及将进行V&V的生存周期活动和产品、每个生存周期活动或产品所需求的Vgu任务、有关的资源、责任和时间表。该计划应当涉及向需方和其它有关的机构提供V&V报告的步骤。

　　11．4．1．6 应当实施 V&V计划。通过 V&V检测出的问题和不符合之处应当进入改正过程（第 11．6 条）。全部问题和不符合之处都应当得到解决。应当将V＆V活动的结果告诉需方和其它有关的机构。

　　11．4．1．7 V&V机构应当收集、保存和使用质量成本数据。使用这些数据的目的是：改进产品或服务的质量；规定预先应付的成本和改正产品或服务中的缺点或不符合之处的成本；计算进行V&V的成本。

　　11．4．2 需求验证
　　此项活动含有下述任务。应当根据需求的范围、规模、复杂性和关键性，执行一项或多项任务。
　　任务表可补充如下：
　　a．参加需求评价、合同要求的评审和审计，以及建立基线的活动；
　　b．验证系统需求（包括接口和鉴定）的完善性、正确性、可行性和可测性；
　　c．验证为达到最佳设计，系统需求已适当地分配给HCI、SCI和人工操作；
　　d．验证软件需求（包括接口和鉴定）的完善性、正确性、可行性和可测性；证明它们准确地反映了系统需求；
　　e．用合适的严密的方法验证与关键性、安全性、保密性有关的软件需求；
　　f．验证项目的计划需求。

　　11．4．3 设计验证
　　此项活动含有下述任务。应当根据系统和软件设计的范围、规模和复杂性，执行一项或多项任务。任务表可以补充如下：
　　a. 参加设计评价；
　　b．分析设计方法是否与需求一致；
　　c．分析设计中的事件次序、输入、输出、接口、逻辑流程、计时分配和规模预算、出错定义、错误的 隔离和恢复；
　　d．验证根据需求所选择的设计；
　　e．用合适的严密的方法，验证实现关键性、安全性和保密性需求的设计。

　　11．4．4 代码验证
　　此项活动含有下述任务。应当根据代码的范围、规模和复杂性，执行一项或多项任务。任务表可以 补充如下：
　　a．评价程序员的文件；
　　b．为跟踪设计和需求、可测性和与需求的一致性及编码的标准而评审关键的代码；
　　c．为适当的事件序列、一致的接口、正确的数据和控制流、完整性、适当分配的计时和规模预算、 出错定义、隔离和恢复而分析代码；
　　d．对照设计和需求验证所选择的代码；
　　e．用合适的严密的方法验证实现关键性、安全性和保密性需求的代码。

　　11．4．5 集成验证
　　此项活动含有下述任务。应当根据集成的范围、规模和复杂性，执行一项或多项任务。
　　任务表可以补充如下：
　　a．验证SCI的每个部件和单元已经完全和正确地集成进一个SCI中去；
　　b．验证该系统的各个部件（HCI、SCI、人工操作部分）已经完全和正确地集成进该系统中去；
　　c．集成任务已经按照集成计划执行。

　　11．4．6 文档评审
　　此项活动含有下述任务。应当根据文档的范围、规模和复杂性，执行一项或多项任务。
　　任务表可以补充如下：
　　a．评审所选的文档是否恰当、完善和具有一致性；
　　b．评价文档准备工作的及时性；
　　c．评价对文档的配置管理。

　　11．4．7 确认
　　此项活动含有下述任务。应当根据系统或软件的范围、规模、复杂性和关键性，执行一项或多项任务。
　　任务表可以补充如下：
　　a．就合同所要求的评审、审计及鉴定测试向需方提供咨询；
　　b．评价所选的测试需求、测试用例、测试规格说明、测试步骤、进行测试的顺序和分析测试结果的步骤；
　　c．参加合同要求的评审和审计；
　　d．参加对测试准备的评审；
　　e．监督鉴定测试；
　　f．准备所选的测试需求、测试用例、测试规格说明、测试过程，进行测试的步骤和分析测试结果的步骤；
　　g.进行所选择的单元测试、集成测试或鉴定测试；
　　h．用输入重点值、边界值和异常输入值来完成所选择的测试；
　　i．测试软件隔离错误和把错误的影响降到最小的能力，即使失败逐级缩小的能力，在重要的、临界的和在异常的条件下要求操作员干预的程度；
　　j．用一个合适的严密的方法确认该软件正确地实现了关键性、安全性和保密要求。

　　11．5 软件质量保证过程
　　软件质量保证过程（SQA）由方针、标准、过程和活动等组成，其目的是恰当保证：此项目生存周期中的过程、产品和服务符合已建立的、预期的需求,并符合已制订的计划。而且，SQA促进能提高质量的环境的形成。为了不产生偏见，SQA机构需要对开发产品或提供服务的直接责任人有相对自由和相应的权力。 ISO 9 0 0 3— 8 7标准提供了实施软件质量保证的指南。
　　此过程含有下述活动：
　　a. 过程建立；
　　b．产品保证；
　　c．过程保证；
　　d．质量改进。

　　11．5．1 过程建立
　　此项活动含有下述任务：

　　11．5．1．1 应当建立适合此项目的一个软件质量保证过程。该 SQA的目标应当是保证和改进交付软件产品和服务的质量，保证和改进为提供这些产品和服务所采用的软件生存期过程的质量。

　　11．5．1．2 应当为此项目的生存期制订进行 SQA活动的计划，将其写成文档、执行它、维护它。
　　该计划应当包括下述各项：
　　a．质量的目标，包括验证、确认、测试、审计和质量测量活动；
　　b．执行SQA活动的质量标准、方法、步骤和工具（或引用机构的正式文件中的有关内容）；
　　c．合同规定的评审和协调的步骤；
　　d．标识、收集、编写文档、维护和处置质量记录的步骤；
　　e．执行SQA活动的资源、时间表和责任。

　　10．5．1．3 负责确认是否与合同要求相符的人员应当不受机构的约束，他们具有对目标进行评价以及启动、影响、解决和验证改正活动的资源和权力。

　　11．5．1．4 应当按计划评价开发产品和提供服务所使用的软件生存期过程中产生的产品，并进行过程中的评价。当评审出问题和与合同要求不相符之处时，应当把它们写成文档，并将其作为改正过程（第 11．6条）的输入。应当编写出评价记录，并保存该记录。

　　11．5.1．5 应当按照合同中的规定将评价记录交给需方一份。

　　11．5．2 产品保证
　　此项活动含有下述任务：

　　11．5．2．1 应当保证把合同所要求的全部计划写成文档，这些计划要符合合同、互不矛盾，并在按照要求执行。

　　11．5．2．2 应当保证软件和有关的文档符合合同、遵守计划。

　　11．5．2．3 在准备交付产品或完成服务的过程中，应当保证产品或服务完全满足合同的要求，且是需方可以接受的。

　　11．5．3 过程保证
　　此项活动含有下述任务：

　　11．5．3．1 应当保证已为此项目采用的软件生存期过程（供应、开发、操作、维护和支持，其中包括、 SQA）符合合同、遵守计划。

　　11．5．3．2 应当保证内部的软件工程实践、开发环境、测试环境和库是恰当的，并符合合同。

　　11．5．3．3 应当保证所适用的主合同的要求已交给予合同的当事人，该当事人的产品和服务符合主合 同的要求。

　　11．5．3．4 应当保证需方和其它各方依照合同、谈判和计划得到了所要求的支持和协作。

　　11．5．3．5 最好保证依照已建立的标准和步骤完满地完成了产品和过程测试。

　　11．5．3．6 应当保证培训提供了满足项目需求所需要的技术和知识。

　　11．5．4 质量改进
　　此项活动含有下述任务：

　　11．5．4．1 管理应当保证机构中的全部项目人员了解项目的 SQA需求，执行并维护这些需求。

　　11．5．4．2 为了了解项目所采用的过程的长处和弱点，最好收集和分析历史数据、技术数据和评价数 据。这些分析最好作为反馈信息用来改进这些过程，为该项目及以后的项目提出改进建议和指出技术改 进要求。

　　11．5．4．3 作为质量保证活动的管理部分，应当收集、维护和使用质量成本数据。这些数据应当说明预 定成本以及改正产品或服务中的缺点或不符合之处的成本。

　　11．6 改正过程
　　改正活动是分析和清除在软件开发、操作或维护中发现的问题（包括不符合之处）的过程，不管它们 的性质和来源。其目的是提供一个及时的、负责的、已有文档记载的方法，以保证所发现的全部问题被分 析和清除并指出趋向。
　　此项过程含有下述活动：
　　a. 过程建工；
　　b．采取改正活动。

　　11．6．1 过程建立
　　此项活动含有下述任务： 为了处理在产品、活动和服务中检测到的全部问题（包括不符合之处），应当建立一个改正过程。

　　此过程应当符合下述要求：
　　a．此过程应当是闭环式的，保证及时报告所检测到的全部问题，并进入改正过程。改正活动自此 开始，问题要得到解决，状态得到跟踪和报告。在合同期内保存问题的记录；
　　b．此过程最好含有对问题进行分类和划分优先权的方案。为了进行趋向分析和解决问题，最好 用分类法和优先级对每个问题分类；
　　c．应在问题报告中完成趋向分析；
　　d．应当对改正活动进行评价，以便： ——证明问题已经解决，不利的趋势已扭转，已在适当的过程、产品和服务中正确地实施了改变； ——确定是否又引起了另外的问题。

　　11．6．2 采取改正活动
　　此项活动含有下述任务： 当在一个产品、一项活动或服务中检测到问题（包括不符合之处）时，应当写出问题／修改报告，讲明 所检测到的每个问题。该问题／修改报告应当描述所需要的改正活动和为解决问题已采取的活动。这些 报告应当作为改正过程的输入用来改正缺点、缺点的起因以及扭转不利的趋势。

　　1．7 培训过程
　　软件的获取、开发、操作或维护主要取决于具有知识和熟练技术的人员。
　　例如：取得人员必须具有获取、安装、操作和维护该软件的知识；开发者必须在软件管理和软件工程方面受过基本训l练。因此，作出人员培训计划并及早实施是绝对必要的。这样，当获取、开发、操作和维护软件时就有了经过培训的人员。
　　此过程含有下述活动：
　　a．过程建工；
　　b．培训资料的开发；
　　c．培训计划的实施。

　　11．7．1 过程建立
　　此项活动含有下述任务： 应当对项目需求进行完整的评审，以便确定和及时地制订获取或开发管理人员和技术人员所需要 的资源和技巧的条款。应当指明培训的种类和水平，需要培训的人员的分类。最好制订一个培训计划， 该计划说明实施的进程、资源需求和培训需求，最好把该计划写成文档。

　　11．7．2 培训资料的开发
　　此项活动含有下述任务： 编写培训手册，包括提供在培训；时所需要的资料。

　　11.7．3 培训计划的实施
　　此项活动含有下述任务：

　　11．7．3．1 实施培训计划应当是为了提供人员培训。最好保存培训记录。

　　11．7．3．2 最好保证及时地为所计划的活动和任务提供正确搭配的和不同种类的受训人员。

　　11．8 环境建立过程
　　为所涉及到的过程建立所需要的环境。
　　此过程含有下述活动：
　　a. 过程建工；
　　b．环境的建立；
　　c．环境的维护。

　　11．8．1 过程建立
　　此项活动含有下述任务：

　　11.8.1.1 最好定义环境并将该环境写成文档，以满足所涉及到的过程、所考虑的将要使用的步骤、标 准、工具和技术的需求。

　　11.8.1.2 对该环境的建立最好作出计划并写出文档。

　　11．8．2 环境的建立
　　此项活动含有下述任务：

　　11．8．2．1 最好对环境的配置作出计划并将其写成文档。功能、性能、安全、保密、可用性、面积需求、设备、成本、时间限制最好都考虑到。

　　11．8．2．2 应当及时安装该环境以便执行相关的过程。

　　11．8．3 环境的维护
　　此项活动含有下述任务：
　　环境应当得到维护。