很多朋友对过程所中科院，过程所还不了解，今天小绿就为大家解答一下。
软件生命周期过程(1) 6采购过程采购过程包括买方的活动和任务。这个过程从定义软件产品或服务的获取需求开始。然后是准备和发布标书，选择供应商，管理采购流程，直到系统验收。有这种需求的机构可以称为业主。业主可以与某机构签订合同进行任何或所有的收购活动，该机构将根据收购流程进行相应的活动。本章中的买方可以是业主，也可以是代理人。这个过程包括以下活动：a .开始和范围定义；b .投标的准备；c .合同的准备、谈判和修改；d .对供应商的监督；e .验收和竣工。6.1开始和范围定义本活动包括以下任务：6 .1.1买方将确定购买、开发或改进软件产品(可能是系统的一部分)或服务的概念或需求，并相应地启动购买流程。6.1.2买方将详细定义系统要求，在现有约束条件下开发系统是可行的。6.1.2.1系统需求定义最好包括与设计、测试和符合标准及开发流程相关的关键、安全和保密需求。将根据开发流程(第8章)定义和记录6.1.2.2系统需求。6.1.3如果需求方不能确定系统要求，将制定计划来确定。这个计划会指定一个提出这些要求的机构，最好包括一些活动，比如进行可行性研究，制作原型和模型。6.1.4一旦确定了系统要求，买方将根据风险分析考虑可采用的方案来获得系统。这些方案包括：a .购买能满足需求的现货产品；b .在内部开发产品或获得服务；c .通过合同开发产品或获得服务；d .上述A、B和C条的组合；e .改进现有系统、产品或服务。6.1.5在获得现货产品时，买方将确保满足以下条件：a .软件满足其要求；b .有必要的文件；c .能满足所有权和使用权；有一个未来的产品支持计划。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然后，买方将准备与供应商就合同进行谈判。在negoti
合同中会提到与可重复使用的现成产品相关的产权、使用权和所有权。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 .项目的组织结构，以及每个组织的权利和责任，包括
图书馆、设备、仪器和工程标准、程序和工具；生命周期过程和活动的工作分解结构，包括可交付成果、与任务相关的预算和人员。物理资源、软件规模和时间进度；系统的质量要求管理。如有必要，可制定另一份质量保证计划；e .管理系统安全和保密的关键要求。如有必要，制定另一个安全和保密计划；分包商的管理，包括分包商的选择。如果选择了分包商，还包括分包商需求方的介入；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条进行。执行三个项目。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 .软件集成；一、软件合格测试；j .系统集成；k .系统识别测试；验收所需的安装和支撑。8.1建立过程该活动包括以下任务：8.1.1开发人员应将开发过程的活动映射到为软件项目建立的生命周期模型中。如果没有建立生命周期模型，应该建立一个。所选择的活动可以重叠或相互关联，也可以反复交替实施。8.1.2开发商应实施第11章中规定的支持流程，这些流程是根据第6.2.2条中的决定支持开发活动所必需的。8.1.3如果合同中没有约定，开发方应选择、删减和使用适当的内部标准、方法、程序和计算机编程语言，这些标准、方法、程序和语言是由开发方的组织以文件形式建立的，以便实施开发活动和支持各种过程。8.1.4开发方应制定开发过程的活动计划。该计划应包括与开发和评估的所有要求(包括安全和保密要求)相关的具体标准、方法、行为和责任。如果有必要，单独制定计划。这些计划应该记录在案并得到实施。8.1.5不可交付物可用于软件开发或维护。但应保证：a .可交付的软件交付给买方后，其运行和维护与这些不可交付的项目无关；这些项目成为可交付成果。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 .安装和验收交付软件的需求
8.4.2开发方应确定SCI的外部接口要求并形成文件。8.4.3开发者应记录SCI的识别要求。8.4.4开发人员应评估要求，包括以下标准：a .系统要求和系统设计的可追溯性；b .与系统要求的外部一致性；c .各种软件需求之间的内部一致性；d .软件需求的可测试性；e .软件需求的测试范围；软件设计、操作和维护的可行性。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 .使用的设计方法和标准是否适当；详细设计、操作和维护的可行性。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 .使用的设计方法和标准是否适当；测试、操作和维护的可行性。8.6.8发包人应根据第11.3条进行合同要求的审查，以确定分配给每个部分和单位的要求，以及SCI详细设计方法是否完善和适当。8.7软件编码对于每个SCI，该活动包括开发人员应执行的以下任务：8.7.1开发人员应开发并建立如下文档：a .开发每个软件单元和数据库；b .为测试每个软件单元和数据库而开发的测试过程和数据；为软件集成开发的测试过程和数据。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 . 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 . d . SCI的测试范围和系统要求；e .是否达到预期效果；操作和维护的可行性。8.9.4开发者应根据第11条支持SCI的功能配置审计(FCA)和物理配置审计(PCA)。3.在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后，应更新可交付的SCI，并准备接受、安装和支持；应该为每个SCI的设计和代码建立一个基线。8.12验收所需的安装和支持该活动包括开发人员应执行的以下任务：8.12.1开发人员应制定在合同规定的目标环境中安装软件的计划。应指出并保证提供与软件安装相关的必要资源和信息。开发人员应以适当的方式帮助需求者获取与系统建立活动相关的信息。当安装的软件替换现有系统时，开发人员应支持合同要求的并行运行活动。应该记录安装过程。8.12.2开发方应根据安装计划安装软件。确保软件和数据库能够按照合同的规定进行初始化、执行和终止。应记录安装情况及其结果。8.12.3开发方应支持买方对软件(或系统)的验收审查和测试。审查和测试中应考虑FCA、PCA、软件鉴定测试和系统鉴定测试(如果进行了系统鉴定测试)的结果。验收审查和测试的结果应记录在案。8.12.4开发方应根据合同规定完成文件和编码，并交付给买方。8.12.5开发方应根据合同规定向买方提供初始和继续的培训和支持。12过程建立、评估和改进本章包含建立、评估、测量、控制和改进软件生命周期过程的活动。这个过程包括以下活动：a .流程构建；b .过程评价；c .流程改进。2.1流程建立这一活动包括以下任务：由于组织在经营活动中要具有获取、供应、开发、运行和维护的职能，因此组织要为这些活动建立一套流程。这些过程及其在特殊情况下的应用应形成文件并写入公司出版物。在适当的情况下，最好建立一个过程控制机制来开发、监督、控制和改进这些过程。2.2过程评估这项活动包括以下任务：最好制定一个过程评估步骤，并将其记录下来，然后使用。最好保留和维护评估记录。12.3过程改进该活动包括以下任务：最好利用过程评价的结果来改进组织的过程。最好更新过程的文档，以反映组织过程中的改进。附录A切割过程(补充)本附录定义了一个软件项目切割本标准所需的基本活动和步骤。附录B切割指南(参考)是对本标准切割要求的简要说明。该剪辑过程包括以下活动：-指定项目的环境；—输入请求；—选择标准单位；—记录切割决定和原因。指定AI项目的环境。这项活动包括以下任务：你应该指出将影响剪辑的项目环境的特征。可能的特征有：生命周期模型；当前系统生命周期阶段；和系统软件要求；组织采用的政策、过程和战略；以及系统软件的规模、类型和关键程度；涉及人数和当事人等。A2该活动的输入请求包括以下任务：应征求和输入将受削减影响的组织的请求。用户、支持人员、合同签署官员
选择A3标准的单位本次活动包括以下任务：A3.1根据在AI和A2中收集的数据，并参考本标准的每一章，我们要决定实施本标准的流程、活动和任务，制定哪些文档，由谁负责等。A3.2在本标准中，要求用包含“应该”、“应当”、“将”和“将”的句子表示。最好认真考虑是否将这些要求纳入特殊项目。需要考虑的因素有(但不限于):风险、成本、时间进度、性能、规模、关键程度和人机界面。A4记录切割决定和原因该活动包括以下任务：所有切割决定和做出这些决定的原因都应记录在案。附录B切割指南(参考)相同的项目不存在。在众多因素中，组织采取的政策和步骤、获取方法和策略、项目的规模和复杂程度、系统需求和开发方法等。影响系统的获取、开发、操作和维护方式。本标准是为一般项目编写的，以尽可能适应各种变化。因此，为了降低成本和提高质量，最好为具体项目量身定制此标准。参与项目的各方最好都参与剪裁。B1通用剪裁指南本章提供了与本标准相关的剪裁指南，但并未详细说明。该图显示了剪辑过程。本章可用于完成本标准对一个项目的一级剪裁。这一章是基于区域使用来实现裁剪的。B2开发过程的剪裁应该特别注意开发过程(第八章)，因为这个过程可以被不同的机构用于不同的目的。作为该流程中的第一级裁剪，建议进行以下活动。对于包含在或集成到系统中的软件：a .最好考虑这个过程中的所有12个活动；b .最好区分开发者是想完成还是支持系统的活动。独立且不属于系统一部分的软件可能不需要第8.2、8.3、8.10和8条。第1条中的活动用于系统，但最好考虑其他活动。与评估相关的活动的B3剪裁任何与项目或过程的生命周期的某个阶段相关的人都应该评估他们自己的或其他人的产品或服务。该标准将这些评估分为以下五类。前四种类型的评估与项目有关，第五种类型的评估与过程有关。最好是根据项目或流程的范围、规模、复杂性和关键程度来适当选择和定制这些评估活动。将这些评估中产生的问题、不符合项和改进报告反馈到纠正过程(第11.6条)。a .过程中的评价(第5、6、7、8、9和10章中的评价任务)。它是由在这个过程中执行指定任务的人在日常活动中执行的。b .合同要求的审查和审计(第11.3条)。由买方和供应商根据事先商定的时间表正式实施。(独立)核查和确认(第11.4条)。由买方、供应商或独立第三方根据项目对产品或服务进行不同程度的评价。这种评价不是对其他种类评价的替代，而是对其他评价的补充。d .软件质量保证(第11.5条)。独立的质量保证是由直接负责开发产品或实施服务的人以外的人提供的。独立担保的目的是使产品或服务符合合同的要求，并坚持既定的计划。e .过程建立、评估和改进(第12章)。这些活动由组织实施，以有效地管理和改进过程。该评估活动与合同要求无关。B4剪裁的注意事项。本章中的段落指出了针对项目的这一关键特性进行剪裁时需要考虑的各种因素。这里不详述这些考虑和特征，只陈述一些当前的想法。B4.1本组织采用的政策是指本组织采用的政策。如计算机语言、安全保密、硬件存储要求、风险管理等。本标准中与组织方针相关的章节应
比如合同的类型，多重合同，分包商和vv机构的参与程度，买方作为合同方的参与程度，合同方能力的评价等等。应保留本标准中与这些策略相关的章节。B4.3支持的概念表示支持的概念。比如买方或合同双方期望支持的时间，变化的程度等。如果软件将有很长的支持寿命或者预计会有很大的变化，那么最好考虑所有的文档需求。建议自动生成文档。B4.4生命周期模型是指项目的生命周期模型。比如瀑布型、互动瀑布型、渐进型、积木型、预期产品改进等。所有这些模型都描述了一些可以顺序、重复或组合完成的过程和活动。在这些模型中，本标准中的生命周期活动最好映射到所选模型。对于渐进的、积木式的和预期的产品改进模型，项目一个阶段的输出就是下一个阶段的输入。在这种情况下，最好在每项活动结束时提交文档。B4.5参与方指参与本项目的各方。比如采购商、供应商、开发商、分包商、vv机构、维修工、人员的数量。与双方相关的所有要求(如买方-开发商、供应商-vv组织等)。)应该考虑。许多涉及几十人或几百人的大型项目需要大量的管理监督和控制。对于一个大型项目，内部的、合同的和独立的评估、审查、审计和测试、数据收集等等都是非常重要的工具。对于小型项目，这些控制可能是多余的。B4.6生命周期阶段表示系统生命周期的当前阶段。比如买方的项目启动，供应商的开发维护等。例如，在以下情况下：当买方提出或定义系统需求时，可能需要对需求和设计进行可行性研究和原型制作，也可能需要编写原始软件代码，根据合同，这些代码在未来的软件开发中可能会用到，也可能不会用到；可能是开发系统需求和初始软件需求，这种情况下第八章的开发过程可以作为开发指南，而不是需求；可能不需要严格的鉴定和评估；可能不需要合同要求的审查和审计。当开发者按照合同生产软件时，裁剪时最好考虑整个开发过程(第八章)的需求。维护人员需要修改软件和文档。当考虑维护过程(第10章)时，开发过程(第8章)的每个部分都可以作为一个子过程。B4.7系统的层次特征是指系统的层次特征，如子系统和配置项的数量。如果系统有许多子系统或配置项，最好为每个子系统和配置项精心定制开发过程(第8章)。最好考虑所有的接口和集成需求。B4.8软件的层次特征是指软件的层次特征，如软件配置项(SCI)的数量、软件的类型、规模和关键程度、技术风险等。如果软件有许多SCI、组件或单元，最好为每个SCI精心定制开发过程(第8章)。最好考虑所有的接口和集成需求。决定包括哪种类型的软件，因为不同类型的软件可能需要不同的裁剪决定。比如：a .新开发的软件。考虑所有需求，尤其是开发过程(第8章)。b .按原样使用现成的软件。开发过程(第8章)可能是多余的。最好对软件相关的性能、文档、产权和未来支持进行评估。修改现有的软件。你可以没有文件。根据关键程度和预期的未来变化，最好使用开发过程(第8章)到维护过程(第10章)。最好对软件相关的性能、文档、产权和未来支持进行评估。d .系统中包含或集成的软件或固件。由于这类软件是一个大系统的一部分，所以最好在开发过程中考虑与这个系统相关的活动(第8章)。在行动中
如果以后无法修改软件或固件，最好仔细审核文档要求的范围。e .独立软件。由于这类软件不是系统的一部分，所以在开发过程中不需要考虑与系统相关的活动(第8章)。最好仔细审核文档需求，尤其是维护文档的需求。f .不要交付软件。由于它们都没有被获得、供应或开发，所以最好不要考虑开发过程的第八部分。第1.5条以外的条款。但是，如果买方决定收购这些软件中的一个用于将来的运行和维护，那么最好按照B条或c条中的软件来对待该软件. B4.9其他考虑因素：系统越依赖于软件的正确运行和及时完成，就越需要通过测试、评审、审计、VV等来加强管理控制。但加强对非关键软件或小软件的管理，并不会降低成本。软件的开发可能存在技术风险。如果采用的软件技术不成熟，正在开发的软件是前所未有的或复杂的，或者软件包含重要的安全和保密要求，那么可能需要严格的规范、设计、测试和评估。独立VV可能很重要。注：本标准由中华人民共和国电子工业部提出。本标准由电子工业部标准化研究所归口。本标准由cosix起草。本标准主要起草人：贾、本标准于1988年7月首次发布。
以上问题已解答完毕，如果想要了解更多内容，请关注本站