本章含有要建立、评价、测量、控制和改进软件生存期过程的活动。
此项过程含有下述活动：
a. 过程建工；
b. 过程评价；
c. 过程改进。
12．1 过程建立
此项活动含有下述任务： 因为在业务活动中机构要具有获取、供应、开发、操作、维护功能，所以，机构应当为这些活动建立一套过程。应当将这些过程以及它们在特殊情况下的应用写成文档，并写进公司的出版物中。在适当的情况下，最好建立一个过程控制机制以开发、监督、控制和改进这些过程。
12．2 过程评价
此项活动含有下述任务： 最好制订一个过程评价步骤，将它写成文档并使用它。最好能保存并维护评价记录。
12．3 过程改进
此项活动含有下述任务： 最好用过程评价的结果来改进机构的过程。最好能更新过程的文档，使其反映机构过程中的改进。
附录A 剪裁过程（补充件）
本附录定义为一个软件项目剪裁本标准时所需要的基本活动和步骤。附录B剪裁指南（参考件）是对剪裁本标准的要求的简要说明。
本剪裁过程含有下述活动：
—指定项目的环境；
—输入请求；
—选择标准的单元；
—把剪裁决定和理由写成文档。
AI 指定项目的环境
此项活动含有下述任务：
应当指出将影响剪裁的项目环境的特性。可能的特性是：生存周期模型；当前的系统生存周期阶段； 系统和软件的需求；机构所采用的方针、过程和策略；系统和软件的规模、类型和关键性；所涉及的人数 和当事各方等。
A2 输人请求
此项活动含有下述任务：
应当征求将要受剪裁影响的机构的请求并输入。用户、支持人员、签订合同的官员和潜在的投标人 最好参与剪裁。
A3 选择标准的单元
此项活动含有下述任务：
A3.1 应当根据在AI和 A2中收集的数据，对照本标准的每一章，决定要执行本标准的哪些过程、活动和任务，要开发什么文档，谁将负责等。
A3.2 本标准中，要求是用含有“应”、“应当”和“将”“将要”的句子来指明的。最好认真考虑在特殊项目 中是否把这些要求包括进去。要考虑的因素有（但不仅仅限于这些）：风险、成本、时间进度、性能、规模、 关键性和人机界面。
A4 把剪裁决定和理由写成文档
此项活动含有下述任务：
应当把全部剪裁决定及做这些决定的理由写成文档。
附录B 剪裁指南 （参考件）
同样的项目是不存在的。在诸多的因素中，机构所采用的方针和步骤、获取方法和策略、项目的规模和复杂性、系统需求和开发方法等因素影响着一个系统的获取、开发、操作和维护的方式。本标准是为通用项目编写的，以尽可能地适应各种变化。因此，为了降低成本和改进质量，最好针对具体项目剪裁本标准。项目的有关各方最好参与剪裁。
B1 通用的剪裁指南
本章提供与本标准有关的剪裁指南，但不详述。图BI示出剪裁过程。本章可用来为一个项目完成” 对本标准的第一级剪裁。本章是根据地区的用途实现剪裁。
B2 开发过程的剪裁
要特别注意开发过程（第8章），因为此过程可以为具有不同目的的不同机构所使用。作为此过程的第一级剪裁，建议进行以下活动。对于包含在系统内或集成到系统中的软件：
a. 此过程中的全部12个活动最好都考虑；
b．最好区分开发者是否要完成或支持系统的活动。 独立的、不是系统一部分的软件可能不需要第8．2、8.3、8．10和8。11条中的用于系统的活动，但最好考虑其它的活动。
B3 与评价有关的活动的剪裁
与一个项目或一个过程的生存周期的某个阶段有关的任何人都要对自己的或他人的产品或服务进行评价。该标准把这些评价分为下述五类。前四类评价与项目有关，第五类评价与过程有关。最好根据项目或过程的范围、规模、复杂性和关键性适当地选择和剪裁这些评价活动。把从这些评价中产生的问题、不符合之处和改进的报告反馈给改正过程（第11．6条）。
a. 过程内的评价（第5、6、7、8、、9和10章的评价任务）。由在此过程中执行指定任务的人员在他们的日常活动中进行。
b．合同要求的评审和审计（第11．3条）。由需方和供方按照事先同意的时间表正式进行。
c．（独立的）验证和确认（第11．4条）。由需方、供方或独立的第三方进行，根据项目对产品或服务进行不同程度的评价。此项评价并不代替其它种类的评价，只是其它评价的补充。
d．软件质量保证（第11．5条）。由对开发该产品或实施该服务的直接责任人之外的人员进行独立的质量保证。进行独立的保证的目的是使产品或服务与合同的要求相符，并坚持已制订的计划。
e．过程建立、评价和改进（第12章）。这些活动由一机构实施，以对过程进行有效的管理和自我改进。这种评价活动与合同的要求无关。
B4 剪裁的考虑因素
本章中的各段指出了为此项目的关键特性在剪裁时要考虑的广泛的因素。此处对这些考虑因素和特性不作详述，只陈述目前的一些想法。
B4．1 机构所采用的方针
指出机构所采用的方针。例如关于计算机语言、安全和保密、硬件储存需求、风险管理等等。 应当保留本标准中与机构的方针有关的章条。
指出项目的获取策略。例如合同的类型、多项合同、分包商和v&v构的介入、需方作为合同当事人介入的程度、对合同当事人能力的评价等等。 应当保留本标准中与这些策略有关的章条。 B4．3 支持的概念
指出支持的概念。例如需方或合同当事人预期应当支持的时间、变化的程度等。 如果软件将有较长的支持寿命或预期有较大的改变，最好考虑全部的文档需求。建议自动生成文档。 B4．4生存周期模型
指出项目的生存周期模型。例如瀑布式、交互瀑布式、渐进式、积木式、预期的产品改进等。 所有的这些模型描述了可以有顺序地、重复地或组合地完成的一些过程和活动。在这些模型中，本标准中的生存周期活动最好映射到所选择的模型中。对于渐进式的、积木式的和预期的产品改进模型，项目的一个阶段的输出就是下一个阶段的输入。在这些情况下，最好在每项活动完成时提交文档。 B4．5 所涉及的各方
指出此项目所涉及的当事各方。例如需方、供方、开发者、分包商、v&v机构、维护者和人员的数量。 与当事双方之间（例如需方一开发者，供方一v&v机构等）有关的全部需求都要考虑。 涉及许多（几十或几百）人的大项目需要大量的管理性监督和控制。对于一个大项目，内部的、合同需求的和独立的评价、评审、审计和检测、数据收集等都是很重要的工具。对于小项目，这些控制可以是 多余的。 B4．6 生存周期的阶段
指出系统的生存周期当前阶段。例如需方的项目起动，供方的开发、维护等，例如下述情况： 需 方在提出或定义系统需求时，可能要对需求和设计进行可行性研究和原型制作，也可能要编写原 型的软件代码，这些代码在以后按照合同开发软件时可能用到，也可能用不到；可能是开发系统需求和 最初的软件需求，在这种情况下，第8章的开发过程可以作为开发指南使用，而不是作为需求使用；可能 不需要严格的鉴定和评价；合同所要求的评审和审计也可能不需要。 开发者在按照合同生产软件的情况下，剪裁时最好考虑全部的开发过程（第8章）需求。 维护者要修改软件和文档，在考虑维护过程（第10章）时，开发过程（第8章）的各部分可以作为子 过程使用。 B4．7 系统的层次特性
指出系统的层次特性，例如子系统的数量和配置项等。 如果系统有许多子系统或配置项，最好谨慎地为每个子系统和配置项剪裁开发过程（第8章）。最好 考虑全部的接口和集成需求。 B4．8 软件的层次特性
指出软件的层次特性，例如软件配置项（SCI）的数量，软件的类型、规模和关键性，技术风险等。 如果软件有许多SCI、部件或单元，最好谨慎地为每个SCI剪裁开发过程（第8章）。最好考虑全部 的接口和集成需求。
决定何种类型的软件包括在内，因为不同类型的软件可以需要不同的剪裁决定。例如：
a. 新开发的软件。考虑全部的需求，特别是开发过程（第8章）。
b．照原样使用现成的软件。开发过程（第8章）可能是多余的。最好评价与该软件有关的性能、文 档、产权和未来的支持。
c．修改现有的软件。可以没有文档。最好依据关键性和所预期的未来的改变，通过维护过程（第 10章）来使用开发过程（第8章）。最好评价与该软件有关的性能、文档、产权和未来的支持。
d．包含在一个系统中的或集成进一个系统的软件或固件。既然这种软件是一个大系统的一部分，最好考虑开发过程（第8章）中与该系统有关的活动。在与系统有关的活动中，只需要选择词汇“执行”或是“选择”。 如果在未来不可能修改该软件或固件，最好仔细审计文档需要的范围。
e．独立的软件。既然该种软件不是一个系统的一部分，就不必考虑开发过程（第8章）中与系统有关的活动。最好仔细审查文档需求，尤其是维护文档的需求。
f．不交付软件。既然没有任何一项被获取、供应或开发，最好不考虑除开发过程的第8。1．5条之外的其它章条。但是，如果需方决定获取这种软件中的一个软件用于未来的操作和维护，那么，这个软件最好按照b条或c条中的软件对待。 B4．9 其它考虑因素：
系统越是依赖于软件的正确操作和及时完成，就越是要通过测试、评审、审计、V&V等来加强管理控制。但是，对非关键性的软件或小软件加强管理反而不会降低成本。 软件的开发可能有技术风险。如果采用的软件技术是不成熟的，正在开发的软件是前所未有的或是复杂的，或者，软件含有安全和保密的重要需求，那么，就可能需要严格的规范、设计、测试和评价。独立的V&V就可能是很重要的。 附加说明： 本标准由中华人民共和国电子工业部提出。
本标准由电子工业部标准化研究所归口。
本标准由中国计算机软件与技术服务总公司负责起草。
本标准主要起草人周明德、贾耀良、王桂兰。
本标准于 1988年 7月首次公布。
文章来源于领测软件测试网 https://www.ltesting.net/
