软件生存期过程（1）

软件生存期过程（1）

　6 获取过程

获取过程包含需方的活动和任务。此过程从定义软件产品或服务的获取需求开始。接着就是准备并公布标书、选择供方和管理获取过程，直到系统的验收。有这种需求的机构可以叫做拥有者。该拥有者可以就任一项或全部获取活动与某机构签订合同，该机构将根据获取过程开展相应的活动。本章中的需方可以是拥有者或者是代理人。

此过程含有下述活动：a.开始和范围定义；b.招标的准备；c.合同的准备、谈判及修改； d.对供方的监督；e.验收和完成。

6.1 开始和范围定义 本项活动含有下述任务：

6. 1.1 需方将认定获取、开发或改进一个软件产品（该软件产品可能是一个系统的一部分）或服务的概念或需求，并依此开始该获取过程。

6.1.2 需方将详细地定义系统需求，此需求在已存在的限制条件下开发系统是可行的。

6.1.2.1 该系统需求定义最好包括与设计、测试和遵守标准及开发过程有关的关键性、安全性和保密性要求。

6.1.2.2 该系统需求将遵循开发过程（第8章）定义并形成文档。

6.1.3 如果需方不能定义系统需求，则将制订一个定义它们的计划。这个计划将指定提出这些需求的一个机构，最好包括一一些活动，如进行可行性研究、制作原型和模型。

6.1.4 系统需求一旦定义，需方将依据风险分析来考虑获取系统所能采用的方案。这些方案包括： a.购买能满足需求的现货产品；b.在内部开发产品或得到服务； c.通过合同开发产品或得到服务；d.上述a、b、c条的结合；e.提高现有的系统、产品或服务。

6.1.5 当要获得一个现货产品的时候，需方将保证能满足下述条件：a.该软件满足它的需求； b.有必须的文档； c.可满足所有权和使用权； d. 有未来的产品支持计划。

6.1.6 需方将制订一个获取计划。此计划要对系统需求作出定义，并定义对所计划的系统的使用、将执行的合同的类型、所涉及的机构的责任、将使用的支持的概念、所考虑到的风险以及管理这些风险的办法。并将该计划写成文档。

6.1.7 需方将定义系统的验收策略和准则，并将其写成文档。

6.2 招标的准备 此项活动含有下述任务：

6.2.1 需方将制作一份系统获取需求的文档（即标书），其内容视第6.1.4条中所选的获取选择方案而定。该系统获取文档最好包括：a.系统需求；b.工作描述；c.投标者须知； d.产品或服务清单； e.合同条款； f.子合同条款；g.技术限制（例如目标环境）。

6.2.2 需方将决定本标准的哪些过程、活动和任务适合它的项目并对其进行适当的剪裁。需方将特别指明可以使用的支持过程（第11章）和它们的执行机构，这样供方就可以在它们的建议中定义达到每个特定支持过程的方法。

6.2.3 系统的获取文档将定义合同的里程碑，以便作为对获取的监督（见第 11. 3条）的一部分将检验和审计供方的进度。

6.2.4 系统的获取需求最好交给实施获取活动任务的机构。

6.3 合同的准备、谈判和修改 此项活动由下述任务组成：

6.3.1 需方最好建立一个选择供方的规程，其中包括建议的评价准则和对需求的依从程度。

6.3.2 需方最好在对供方的建议、能力以及需要考虑的其它因素进行评价的基础上选择一个供方。

6.3.3 需方可以与其它各方一道为项目而剪裁本标准。但是，在需方与其它各方之间达成协议时，最后的剪裁决定将由需方做出。

6.3.4 然后，需方将准备就一项合同与供方进行谈判。谈判中提出系统的需求、成本、提*品或服务的日程。该合同将提及与可重复使用的现货产品有关的产权、使用权和所有权。

6.3.5 在合同的执行期内，需方将通过与供方（即控制合同变化的另一当事方）进行谈判来控制合同的变化。应当研究合同的变化对项目计划、成本、质量和日程的影响。

6.4 对供方的监督 此项活动由下述任务组成：

6.4.1 需方将按照合同所定范围监督和评价供方的技术和进度，其中包括质量和成本。所用的手段最好适合于获得的类型并包括下述活动，例如非正式的会面、合同所要求的评审、审计，以及（独立的）验证和确认。独立的验证和确认将分别根据第 11.3和11.4条进行。

6.4.2 需方最好与供方合作以便及时地提供全部必要的信息和解决尚未解决的问题。

6.5 验收和完成 此项活动含有下述任务：

6.5.1 需方将根据已定义的策略和准则为验收做好全部必要的准备。准备最好包括对测试用例、测试数据、测试过程和测试环境的准备。

6.5.2 需方将对交付的产品或服务进行验收评审和验收测试，当符合所有的验收条件之后，从供方处验收该产品或服务。验收过程应符合第6.1.6条中的规定。

6.5.3 在验收之后，需方最好按照第 11.2条采取交付产品的配置管理。

7 供应过程

此过程含有供方的活动和任务。

此过程的开始方法可以有两种，－是决定准备一项建议以应答需方的标书（RFP）；二是就提供一个含有软件的系统（或系统的一个部件、一个产品或一项服务）与需方签订合同或协议。接着就是规定为了管理和保证这个项目所需要的步骤和资源，其中包括制订项目计划和实施计划，直至向需方交付系统、产品或提供服务。 供方按照第5章来管理这个过程。

此过程含有下述活动：a. 开始； b.准备投标；c.签订协议；d.编制计划； e.实施和控制；f.评审和评价；g.交付和完成。

7.1 开始 此项活动含有下述任务：

7.1.1 供方评审标书（RFP）中的需求，与公司的方针及其它规则相对照。

7.1.2 供方最好对是否投标或是否接受合同作出决定。

7.2 准备投标 此项活动含有下述任务： 供方最好定义和准备一份投标书。

7.3 签订协议 此项活动含有下述任务：

7.3.1 供方应当与需方就提供系统、产品或服务进行谈判并签订合同。

7.3.2 作为修改控制机制的一部分，供方可以请求修改合同。

7.4 编制计划 此项活动含有下述任务：

7.4.1 为了保证交付的系统、产品或服务的质量，供方应当全面评审合同中的系统获取需求，以确定管理和保证项目的框架。

7.4.2 供方应当确定或选择与项目的范围、规模和复杂性相适合的软件生存周期模型。应当把从本标准中选出的过程、活动和任务影射到该生存周期模型中。该生存周期模型应当包括可使用的开发环境，其中包括标准、方法和工具等。

7.4.3 供方应当规定管理和保证此项目的计划需求。这种规定最好包括对资源的需求和需方的介入。

7.4.4 计划需求一旦规定，供方应当根据风险分析，为开发该产品或提供该服务选择方案。可供选择的方案有：a.利用内部资源开发产品或提供服务； b.用子合同方式开发产品或提供服务；c.从内部或外部来源获得现货产品；d.上述a、b二条结合。

7.4.5 供方应当以所计划的需求和第7.4.4条中规定的可选方案为基础制定项目管理计划，并将其写成文档。在这些计划中应当规定下述事项：a. 项目的组织机构，以及包括外部机构在内的每个机构的权利和责任；b.开发环境，包括测试环境。库、设备、仪器以及工程标准、步骤和工具；c.生存期过程和活动的工作细目的结构，其中包括可交付的产品，与任务有关的经费预算、人员。物理资源、软件的规模以及时间进度；d.系统的质量需求管理。如果需要，可以另外制订质量保证计划；e.系统安全和保密的关键需求管理。如果需要，另外制订安全和保密计划；f.分包商的管理，其中包括对分包商的选择。如果选择了分包商，还包括分包商一需方的介入； g.需方的介入，即按合同要求进行的评审和审计（见第11.3条）、非正式的会面、报告、修改和变更的实施、批准、验收、对设施的使用等；h.验证和确认（见第11.4条），规定中应包括与独立的验证和确认机构接触的方法；i.质量保证（见第 11.5条）；j.风险管理，此项管理包括对项目的潜在技术、成本和进度诸风险领域的管理； k.保密方针，即在每个项目组织层次上有关“需要知道”和“接触信息”的规则；l.规则所要求的批准、证书、专有权利等； m.制定计划、跟踪和报告的方法；n.人员培训（见第 11. 7条）。

7.5 执行和控制 此项活动包括下述任务：

7.5.1 供方应当实施和执行使第7.4条制订的项目计划。

7.5.2 供方应当分别根据开发过程（第8章）、操作过程（第9章）或维护过程（第10章）开发、操作或维护软件。

7.5.3 供方应当在合同所定的整个生存周期内监督和控制项目产品或服务的进展和质量。这应当是一个连续的、反复进行的任务，它应当提供： a.监督技术性能、成本和进度的进展情况，报告项目的状况；b.问题的识别、记录、分析和解决。

7.5.4 供方应当管理和控制分包商，向其传达全部必要的合同需求，以保证交给需方的所有的产品或服务都符合主合同的要求。

7.6 评审和评价 此项活动包括下述任务：

7.6.1 在适当的情况下，供方最好根据合同进行评审活动、与需方进行接触和通信。

7.6.2 供方应当进行或支持非正式的会面、验收评审和验收测试，按照合同和项目计划的规定与需方一起进行合同所要求的评审和正式的审计。审计应当按照第11。3条进行。

7.6.3 供方应当向需方提供关于评价、评审、审计、测试、改正工作和解决问题的报告。

7.6.4 为了按照合同和项目计划的规定评审产品或服务，供方应当让需方使用供方和分包商的设备。

7.6.5 供方应当按照合同和项目计划的规定，与独立的验证和确认机构或测试机构（见第11.4条）进行接触。

7.6.6 供方应当根据11.5条实施项目的质量保证。实施软件的质量保证时可以用ISO 9003—87或其它类似的指南。

7.7 交付和完成 此项活动包括下述任务：

7.7.1 供方应按照合同的规定交付系统。

7.7.2 供方应当对已交付的系统向需方提供支持。

7.7.3 供方应当考察需方对已交付的系统是否满意。

8 开发过程

开发过程包括开发者的活动和任务。此过程包括需求分析、设计、编码、集成、测试、软件安装和验收等活动。完成下面所列出的全部活动。按照合同，软件开发者的责任从软件需求分析开始，以软件鉴定测试终止。但是，通常软件是作为整个系统的一部分实现的。软件的需求分析与整个系统需求分析、系统设计有关，故软件开发者有可能要参加系统需求分析。系统设计，或从系统需求分析、系统设计中获取必要的信息。软件鉴定测试完成后，还要把软件集成到整个系统中去。所以，本过程列出了系统的开发过程所包含的所有活动。软件开发者按照合同的规定来确定此过程所包含的活动。开发者也可以完成需方所要求的其它活动。

此过程由下述活动组成： a.建立过程；b.系统需求分析；c.系统设计； d.软件需求分析； e.软件体系结构设计；f.软件的详细设计； g.软件编码；h.软件集成； i.软件鉴定测试；j.系统集成； k.系统鉴定测试； l.验收所需要的安装和支持。

8.1 建立过程 此项活动含有下述任务：

8.1.1 开发者应当将开发过程的活动映射到为软件项目所建立的生存周期模型中。如果没有建立一个生存周期模型，就应当建立一个。所选择的活动可以是重叠的或相互有关联的，而且也可以反复交替地一实施。

8.1.2 开发者应当实施第11章指定的支持过程，这些过程是按照第6.2.2条的决定支持开发活动所必须的。

8.1.3 如果在合同中没有约定，开发者应当选择、剪裁和使用适当的内部的标准、方法、步骤和计算机编程语言，这些是由开发者的组织为了实施开发活动和支持各种过程已用文档建立起来的。

8.1.4 开发者应当制订进行开发过程的活动计划。该计划应当包括与开发和鉴定的全部需求（包括安全和保密需求）有关的特定的标准、方法、行为和责任。如果需要，要分别制订计划。这些计划应当形成文档并得到实施。

8.1.5 在软件的开发或维护中可以使用不交付项。但是，应当保证：a.在可交付软件交给需方之后，它的操作和维护与这些不交付项无关；b.这些项变成可交付项。

8.2 系统需求分析 此项活动含有开发者应当执行或支持的下述任务：

8.2.1 如第6.1和6.2条所规定，应当对获取和系统的要求进行分析，以建立系统需求。系统需求应当说明：系统的功能和性能；安全、保密、人机工程、接口、操作和维护需求；设计限制和鉴定的要求。这些系统需求应当写成文档。

8.2.2 应当对这些系统需求进行评价，使其包括下述准则：可跟踪性；与获取及系统要求的一致性；可测试性；以及设计、操作和维护的可行性。

8.3 系统设计 此项活动含有开发者应当执行和支持的下述任务：

8.3.1 应当建立一个高层的系统体系结构。应当在系统的体系结构中体现系统的需求，该系统体系结构要表现出系统的内部结构以及硬件、软件和人工操作的配置。应当保证：系统需求已完全分配给硬件配置项（HCI）、软件配置项（SCI）和人工操作。分配给 HCI、 SCI和人工操作的系统体系结构和系统需求要写成文档。

8.3.2 应对HCI、SCI和人工操作的系统体系结构和需求进行评价，使其包括下述准则：可跟踪性、与系统需求的一致性、设计和所用标准恰当，以及操作和维护的可行性。

8.4 软件需求分析 对于每个SCI，此项活动含有开发者应当执行的下述任务：

8.4.1 开发者应当确定各种需求并将其写成文档，其中包括与第2.5条相一致的质量特性规格说明（可操作性、可靠性、可用性、有效性、可维护性和可移植性）。 该文档描述： a.功能和能力规格说明，其中包括性能、物理特性、运行软件的环境条件；b.用户文档；c.安全规格说明，其中包括与操作和维护的方法、环境影响和人员伤害有关的说明； d.保密规格说明，其中包括对敏感性信息或资料的危害有关的说明；e.人机工程和人一机规格说明，其中包括与人工操作、人机对话、对人员的限制有关的规格说明，以及那些对于人的错误和能力很敏感的、需要人集中注意力的领域的说明；f.处理器、存储设备或数据通道所用的硬件处理和资源储备的规格说明；g.数据定义和数据库的需求；h.已交付软件在操作和维护现场上的安装和验收的需要； i.用户操作和执行的需求； j.用户维护需求。

8.4.2 开发者应当确定SCI的外部接口的需求并将其写成文档。

8.4.3 开发者应当对SCI的鉴定要求写成文档。

8.4.4 开发者应当对需求作出评价，使其包括下面指出的准则： a.对系统需求和系统设计的可跟踪性； b.与系统需求的外部一致性；c.各种软件需求之间的内部一致性； d. 软件需求的可测性；e.软件需求的测试范围；f.软件设计、操作和维护的可行性。

8.4.5 开发者应当依据第11.3条进行合同所要求的评审，以决定软件需求的完善和恰当。当评审完成时，就应当建立SCI需求的基线。

8.5 软件体系结构设计 对于每个SCI，此项活动含有开发者应当执行的下述任务：

8.5.1 开发者应当把SCI的工程需求转变为一个体系结构，该体系结构应描述它的顶层结构和定义它的主要部分。它应当保证此项工程和SCI的鉴定要求已完全分配给了各个部分，并对其进行了细化以便进行详细设计。应当建立SCI体系结构的文档。

8.5.2 开发者应当为SCI外部接口的设计、SCI的各软件部分之间的设计建立一个顶层的设计文档。

8.5.3 开发者应当为数据库建立一个顶层的设计文档。

8.5.4 开发者应当评价SCI的体系结构、接口和数据库的设计，使其包括下面指出的各项：a. 对SCI需求的可跟踪性； b.与SCI需求的外部一致性； c.各部分需求之间的内部一致性；d.所使用的设计方法和标准是否恰当；e.详细设计、操作和维护的可行性。

8.5.5 开发者应当依据第11.3条进行合同所要求的评审，以决定分配给各部分的需求和 SCI体系结构设计方法的完善和恰当。

8.6 软件的详细设计 对于每个SCI，此项活动含有开发者应当执行的下述任务：

8.6.1 开发者应当详细设计SCI的每个软部件。应当尽量地将各个软部件详细划分为含有软件单元的较低的层次，以便进行编码、编译和测试。应当保证该软件的需求已完全分配给从软部件到软件单元的整个软件。应当把该详细设计写成文档。

8.6.2 开发者应当写出与SCI的外部接口、各软部件之间和各软件单元之间的详细设计文档。接口的详细设计应当足够详细以便于编码。

8.6.3 开发者应当写出数据库的详细设计文档。

8.6.4 开发者最好写出软件用户手册的最初版本。

8.6.5 开发者应当为测试软件单元规定测试要求和时间进度，并将其写成文档。测试要求中最好包括在软件需求限定上的重点软件单元。

8.6.6 开发者应当为软件的集成规定测试要求和时间进度，并将其写成文档。

8.6.7 开发者应当评价软件的详细设计和测试要求，使其包括下面的准则：a. 对SCI需求的可跟踪性； b.与体系结构设计的外部一致性； c.各部件和单元的需求之间的内部一致性； d.所使用的设计方法和标准是否恰当； e.测试、操作和维护的可行性。 8.6.8 开发者应当依据第11.3条进行合同所要求的评审，以决定分配给各个部分和单元的需求以及 SCI详细设计方法是否完善和恰当。

8.7 软件编码 对于每个SCI，此项活动含有开发者应当执行的下述任务：

8.7.1 开发者应当进行下述开发并建立文档： a.开发每个软件单元和数据库；b.为测试每个软件单元和数据库而开发的测试过程和数据； c.为进行软件集成而开发的测试过程和数据。

8.7.2 开发者应当测试每个软件单元和数据库，以保证它们符合需求。测试结果应当写成文档。

8.7.3 必要时，开发者应当更新软件的用户手册。

8.7.4 开发者应当评价软件的代码和测试结果，使其包括下面的准则：a. 对SCI需求和设计的可跟踪性； b.与 SCI需求和设计的外部一致性；c.各单元需求之间的内部一致性； d.各单元的测试范围； e.使用的编码方法和标准是否恰当；f.集成、操作和维护的可行性。

8.8 软件集成 对于每个SCI，此项活动含有开发者应当执行的下述任务：

8.8.1 开发者应当制订计划把各个软件单元和软部件集成为SCI。该计划应当包括测试要求、步骤、数 据、责任和时间表。该集成计划应当写成文档。

8.8.2 在依据集成计划开发集合体时，开发者应当集成软件的单元、部件和进行测试。应当保证每个集 合体都能满足SCI的需求，并且在集成活动结束时形成完全集成的SCI。集成和测试的结果应当写成文 档。

8.8.3 必要时，开发者应当更新用户手册。

8.8.4 为了进行软件的鉴定测试，开发者应当为每个SCI开发写出一个完整的测试集、测试用例（输 入、输出、测试准则）和测试步骤。开发者应当保证集成后的SCI可以进行软件鉴定测试。

8.8.5 开发者应当对集成计划、设计、代码、测试、测试结果和用户手册进行评价，使其包括下面的准 则：a. 对 SCI需求的可跟踪性；b.与 SCI需求的外部一致性； c.内部一致性；d.SCI需求的测试范围；e.使用的测试方法和标准是否恰当； f.是否符合预期的结果；g.鉴定测试、操作和维护的可行性。

8.8.6 开发者应当依据第11.3条进行合同所要求的评审，以确定测试过程的完善和适当，并确定已经 做好软件鉴定测试的准备。

8.9 软件鉴定测试 对于每个SCI，此项活动含有开发者应当执行的下述任务：

8.9.1 开发者应当依据为 SCI确定的鉴定要求进行鉴定测试。应当保证对每项要求进行符合测试。应将鉴定测试结果写成文档。

8.9.2 必要时，开发者应当更新用户手册。

8.9.3 开发者应当对设计、代码、测试、测试结果和用户手册进行评价，使其包括下面的准则：a. 对SCI和系统需求的可跟踪性；b.与 SCI和系统需求的外部一致性；c.内部一致性；d.SCI和系统需求的测试范围；e.是否符合预期结果； f.操作和维护的可行性。

8.9. 4 开发者应当依据第 11. 3条支持对 SCI的功能性配置审计（FCA）和物理配置审计（PCA）。在 FCA时，应当保证SCI的测试成功并符合需求，而且用户手册中充分描述SCI的操作和支持。在PC：A 时，应当保证SCI的设计和源码完整并正确，反映了SCI的新技术。FCA和PCA的结果应当写成文档。如果同时开发硬件和软件，FCA和PCA可以推迟到系统鉴定测试时进行。

8.9.5 在FCA和PCA成功地完成之后，开发者应当：a.为系统集成、系统鉴定测试或适当时的安装和验收，更新和准备可交付的软件；b.为SCI的设计和编码建立一个基线。

8.10 系统集成 此项活动含有开发者应当执行或支持的下述任务：

8.10.1 SCI应当与 HCI、人工操作和其它必要的系统一起集成到系统中去。当开发该集合体时，应当对照它们的需求进行测试。应当将集成和测试的结果写成文档。

8.10.2 应当为系统的每项已确定的需求进行系统鉴定测试开发一个完整的测试集、测试用例（输入。输出、测试准则）和测试步骤，并将其写成文档。开发者应当保证集成的系统已做好系统鉴定测试的准备。 8.10.3应当对集成的系统进行评价以使其包括下述准则：系统需求的测试范围。、所使用的测试方法和标准是否恰当；是否符合预期结果；鉴定测试、操作和维护的可行性。

8.11 系统鉴定测试 此项活动含有开发者应当执行或支持的下述任务：

8.11.1 应当依据为系统建立的鉴定要求进行系统鉴定测试。应当保证每项系统需求都进行符合性测试，而且系统已做好交付准备。应当把鉴定测试的结果写成文档。

8.11.2 应当对系统进行评价以使其包括下述准则：系统需求的测试范围；是否符合预期的结果；操作与维护的可行性。

8.11.3 本项需求不适用于已经进行过 FCA、PCA的 SCI。 SCI的 FCA和 PCA应当依据第 11.3条进行。在成功地完成FCA和PCA后， a. 可交付的SCI应当更新并做好验收安装和支持的准备； b.应当为每个SCI的设计和代码建立基线。

8.12 验收所需要的安装和支持 此项活动含有下述开发者应当执行的任务：

8.12.1 开发者应当制定一个合同中指明的、在目标环境中安装软件的计划。应当指出与软件的安装有关的必要的资源和信息并保证提供。开发者应当以适当的方式帮助需方得到与系统建立活动有关的信息。当所安装的软件替代了现有的系统时，开发者应当支持合同所要求的并行运行的活动。应当将安装情况写成文档。

8.12.2 开发者应当依据安装计划安装软件。应当保证该软件和数据库能按照合同的规定初始化、执行和终止。应当把安装情况及其结果写成文档。

8.12.3 开发者应当支持需方对软件（或系统）的验收评审和测试。验收评审和测试应当考虑 FCA、 PCA、软件鉴定测试和系统鉴定测试（如果进行系统鉴定测试）的结果。应当把验收评审和测试的结果写成文档。

8.12.4 开发者应当按照合同的规定完成文档和编码并交付给需方。

8.12.5 开发者应当按照合同的规定向需方提供初始的和继续的培训和支持。

12 过程的建立、评价和改进

本章含有要建立、评价、测量、控制和改进软件生存期过程的活动。此项过程含有下述活动：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 机构所采用的方针 指出机构所采用的方针。例如关于计算机语言、安全和保密、硬件储存需求、风险管理等等。 应当保留本标准中与机构的方针有关的章条。

B4.2 获取策略 指出项目的获取策略。例如合同的类型、多项合同、分包商和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月首次公布。