1、,第二章、软件生存周期过程,概念：当开发产品或构建系统时，遵循一系列可预测的步骤（路线图）是非常重要的，它有助于及时交付高质量的产品。软件开发中所遵循的路线图就是“软件过程”。,人员：软件工程师及其管理人员根据需要调整开发过程，并遵循该过程。除此以外，软件的需求方也需要参与过程的定义、建立和测试。,重要性：软件过程提高了软件工程活动的稳定性、可控性和有组织性，如果没有过程约束，软件活动将失控并变得混乱。但是，现代软件工程方法必须是“灵活”的，也就是要求软件工程活动、控制以及文档的编制适合于项目团队和要开发的产品。,2.1 相关基本概念软件生存周期（Software life cycle）:软件
2、产品或软件系统从产生、投入使用到被淘汰的全过程。通常将软件生存周期分为5个阶段，即需求、设计、实现（编码）、测试和维护。 张效祥主编.计算机科学技术百科全书(第2版),北京：清华大学出版社,2005年11月.软件生存周期模型（有时称为软件开发模型）：它是整个软件生存周期内的系统开发、运行和维护所实施的全部过程、活动和任务的框架。 郑人杰.软件工程.北京：清华大学出版社,1999.,3,软件开发模型是软件开发全部过程、活动和任务的结构框架。 张效祥主编.计算机科学技术百科全书(第2版),北京：清华大学出版社,2005年11月. 王立福，麻志毅、张世琨.软件工程(第2版).北京大学出版社,2002
3、年3月.,软件开发模型表达的是软件生存周期内各种活动如何组织，以及各个阶段应该如何衔接。,2.2 软件过程 为了细化软件生存周期这一概念，国际标准化组织于1995年发布了一个国际标准，即ISO/IEC软件生存周期过程 12207-1995。这一标准是软件工程标准中一个基础性文件，系统化地给出了软件开发所需要的任务。 软件过程：软件生存周期中的一系列相关过程。又称为软件生存周期过程。过程是活动的集合，活动是任务的集合，任务是将输入加工成输出的操作。,随着ISO/IEC软件生存周期过程 12207-1995的不断应用，以及软件复用技术的发展，并结合CMM（能力成熟度模型）和ISO/IEC/TR15
4、504的推进，国际标准化组织于2002年给出了ISO/IEC 12207-1995的补篇1，主要：增加了一些新的软件过程，例如测量过程、资产管理过程、复用程序管理过程以及领域软件工程过程等；增加了一些有关增进该标准应用效果的内容，例如给出了每一过程的目标以及成功实现过程的基本判定准则等。于2004年给出了ISO/IEC 12207-1995的补篇2，主要对补篇1的内容做了一些修改。该标准按照不同人员的工作内容来分，将软件生存周期过程分为三类：基本过程、支持过程和组织过程。在该标准的附录中，给出了剪裁过程以及相关的指导，以便当把软件过程运用到相关组织，运用到具体应用领域或具体项目时，可以根据特定
5、情况，对各种过程和活动进行剪裁，形成特定项目所需要的软件生存周期过程。,软件过程：系统化地给出了软件开发所需要的任务；软件开发模型：如何根据软件项目特点、环境因素等，选择并组织这些开发任务。,软件过程和软件开发模型的区别？,2.3 基本过程 基本过程是指那些与软件生产直接相关的过程。 包括5个过程：获取过程、供应过程、开发过程、 运行过程、维护过程 2.3.1 获取过程 获取过程是获取者所从事的活动和任务。 目的：获得满足客户所表达的那些要求的产品和/或服务。该过程以定义客户要求开始，以接受客户所要求的产品和/或服务结束。 该过程包括5个基本活动：a)启动； b)招标标书准备；c)合同编制和更
6、新； d)对供方的监督；e)验收和完成。 其中每一基本活动又包含一组特定的任务。,其中的活动：启动主要任务： 1）描述获取、开发或增强一个系统、软件产品或软件服务的概念或要求，以此开始这一活动。 2）定义并分析该系统需求。系统需求一般应包括业务、组织和用户的需求，还应包括与设计、测试有关的安全性、保密性和其他关键性需求以及应遵循的标准和规程。 3）需方可以自己定义并分析软件需求，也可委托供方进行这项任务。 4）如果需方委托供方进行系统需求分析，那么需方就要审核并批准所分析的需求。 5）为了执行任务2）和4），应使用开发过程（见2.3.3）。,6）依据对有关风险、费用和效益等方面的适当分析，选择
7、获取方案。方案包括：a)是否购买满足需求的现货软件产品；b)是否在自己组织内部进行软件产品的开发或获得软件服务；c)是否通过合同来开发软件产品或获得软件服务；d)是否采用上述a、b、c的一个组合；e)是否增强现有的软件产品或服务。 7）当要去获得一个现成软件产品时，应确保满足以下条件：a)满足该软件产品的需求；b)文档是可用的；c)满足专利权、使用权、拥有权、担保权和许可权；d)规划对该软件产品的未来支持。,8）制定一个获取计划并执行之，该计划应包括下述内容：a)对该系统的需求；b)为该系统所规划的使用；c)准备使用的合同类型；d)有关组织的职责；e)准备使用的支持（例如验证、质量保证等）；f
8、)风险以及管理这些风险的方法。 9）定义验收策略和条件（准则），并形成文档。 在补篇1中，对获取过程增加了以下活动：a) 合同终结处理；b) 获取方针；c) 供应方关系管理；d) 用户关系管理；e) 财政管理。关于该过程的其它活动，可参见有关的标准。,成功实现获取过程的结果是：1）定义了获取要求、目标、产品/或服务验收准则以及获取策略；2）制定了能明确表达顾客和供方的期望、职责和义务的协定；3）获得了满足顾客要求的产品和/或服务；4）按规定的约束，例如要满足的成本、进度和质量等，对该获取过程进行了监督；5）验收了供方的可交付产品。6）对每一接受的交付项，均有一个由客户和供方达成的满意性结论。,
9、2.3.2 供应过程 供应过程是供方为了向客户提供满足需求的软件产品或服务所从事的一系列活动和任务。 该过程的启动，或通过为应答需方的招标书而开始编制投标书的决定，或通过与需方签订一项提供系统、软件产品或软件服务的合同。继之，确定为管理和保证项目所需的规程和资源，包括编制项目计划，执行计划，一直到将系统、软件产品或软件服务交付给需方为止。 目的：是向客户提供一个满足已达成需求的产品或服务。 该过程包括的基本活动为： a)启动； b)准备投标； c)签订合同； d)规划； e)执行和控制； f)复审和评估； g)交付和完成。,成功实现供应过程的结果是： a)对顾客请求产生了一个响应； b)在顾客
10、与供方之间建立了一个关于开发、维护、运行、包装、交付和安装产品和/或服务的协定； c)供方开发了一个符合协定需求的产品和/或服务； d)根据协定的需求，向顾客交付了该产品和/或服务； e)根据协定的需求，安装了该产品。,2.3.3 开发过程 开发过程是软件开发者所从事的一系列活动。 目的：将一组需求转换为一个软件产品或系统。 包括13个活动： 过程实现 系统需求分析 系统结构设计 软件需求分析 软件体系结构设计 软件详细设计 软件编码和测试 软件集成 软件合格测试 系统集成 系统合格测试 软件安装 软件验收支持,其中的活动：过程实现主要任务： （1） 如果合同中没有规定采用什么软件生存周期模型
11、，那么开发者就应规定或选择适合于项目范围、规模和复杂度的软件生存周期模型。并应选择该开发过程中的活动和任务，将其映射到生存周期模型。其中，依据采用的软件生存周期模型，所选择的活动和任务可以是重叠的或相互作用的，并可以是重复的或循环的。 （2）开发者应： a)按照文档编制过程，对任务（1）的输出建立相应的文档； b)将这一输出置于配置管理过程之下，并按照配置管理的要求进行变更控制； c)按照问题解决过程，对在软件产品和任务中所发现的问题之解决建立相应的文档；d)实施合同中规定的支持过程。,（3） 开发者应适当地选择、剪裁、使用那些由组织为实施开发过程和支持过程所建立的标准、方法、工具和计算机编程
12、语言（如果合同没有规定），并建立相应的文档。 （4） 开发者应为实施开发过程的活动制定一些计划。这些计划应包括与所有需求（包括安全保密性）的开发和限定条件相关联的特定标准、方法、工具、措施和职责。如果必要的话，这些计划可以分别制订之。这些计划均应形成文档并执行之。 （5） 在软件产品的开发或维护中，可以使用一些非交付的软件项。但应确保对那些已交付获取方的软件产品的操作和维护，要独立于这些非交付项，否则它们就应被认为是可交付的。,其中的活动：软件需求分析 目的：确定软件需求及质量特性需求。 主要任务： 编制软件需求规格说明书 检查软件需求： 是否能够跟踪系统需求、结构； 从外部上，是否与系统需求
13、保持一致； 需求内部的一致性； 是否具有可测性； 测试覆盖是否可达到要求； 操作（设计和实现），维护的可行性等,其内容包含：功能和性能需求； 外界与软件的接口合格需求； 安全需求；保密需求； 人机界面需求；数据定义和数据库需求； 用户文档；用户操作和运行需求； 用户维护需求,成功实现开发过程的结果是： a)收集了软件开发需求并达成协定； b)开发了软件产品或基于软件的系统； c)开发了证明最终产品是基于需求的中间工作产品； d)在开发过程的产品之间，建立了一致性； e)根据系统需求，优化了系统质量因素，例如，速度、开发成本、易用性等； f)提供了证明最终产品满足需求的证据（例如，测试证据）；
14、g)根据协定的需求，安装了最终产品。,2.3.4 运行过程 运行过程是系统操作者所从事的一系列活动和任务。其目标是在软件产品预期的环境中运行该产品，并为该软件产品的维护提供支持。 运行过程包括下述活动：a) 过程实现；b) 运行测试；c) 系统运行；d) 用户支持。,成功实施运行过程的结果是： a)对该软件在其预定的环境中正常运行的条件，进行了标识和评估； b)在其预定的环境中，运行了该软件； c)按照协定，为软件产品的顾客提供了帮助和咨询。,2.3.5 维护过程 维护过程是维护者所从事的一系列的活动和任务。 目的：对交付后的系统或软件产品，或为了纠正其错误，改进其性能或其它属性，而对其进行修
15、改；或因环境变更，而对其进行调整。当软件产品由于某一问题或由于改进、更新的需要而对编码和相关文档进行修改时，就要启动这一过程。该过程随着软件产品的退役而结束。 维护过程包括下述活动： a)过程实现； b)问题和修改分析； c)修改实现； d)维护评审/验收； e)迁移； f)软件退役。,2.4 支持过程 支持过程是有关各方按他们的支持目标所从事的一系列相关活动集。支持过程有助于提高系统或软件产品的质量。支持过程可由使用它们的组织来实施；或作为一种服务，由一个独立的组织来实施；也可作为项目的一项规定内容，由客户来实施。 包括8个过程：文档过程、配置管理过程、质量保证、验证过程、确认过程、联合评审
16、、审计过程、问题解决等。2.4.1 文档过程 文档过程是一个记录由某一过程或活动所产生信息的过程。 包括4个活动：a)过程实现； b)设计和开发； c)制作； d)维护。,成功实施文档过程的结果是： a)制定了标识软件产品或服务的生存周期中所要产生的文档之策略； b)标识了编制软件文档的标准； c)标识了由过程或项目产生的文档； d)对全部文档的内容和目的进行了规定、评审和批准； e)根据已标识的标准，制作了可用的文档； f)按定义的准则维护了文档。,2.4.2 配置管理过程 配置管理过程是应用管理上的和技术上的规程来支持整个软件生存周期的过程，主要涉及：标识、定义系统中的软件项；控制软件项的
17、修改和发布；记录和报告软件项的状态和修改请求；保证软件项的完备性、一致性和正确性；以及控制软件项的贮存、处理和交付。可见该过程的目的是建立并维护一个过程或一个项目的所有工作产品的完整性，使它们对相关团体而言均是可用的。注：当该过程用于其他软件产品或实体时，应对所提及的“软件项”要作相应的解释。 该过程包括以下活动： a)过程实现； b)配置标识； c)配置控制； d)配置状态统计； e)配置评价； f)发布管理和交付。,成功实施该过程的结果是： a)制定了配置管理策略； b)标识并定义了由过程或项目所产生的全部工作产品/项，并形成基线； c)对工作产品/项的修改和发布，进行了控制； d)为对各
18、相关方均是可用的，做了必要的修改和发布； e)记录并报告了工作产品/项的状况和修改请求； f)确保了每一软件项的完备性和一致性； g)对每一软件项的存储、处置和交付进行了控制。,2.4.3 质量保证过程 质量保证过程是为项目生存周期内的软件过程和软件产品提供适当保障的过程，目的是使它们符合所规定的需求，并遵循已建立计划。为了避免产生偏见，实施质量保证的人员不能是直接负责软件产品开发的人员，并应在组织上给予独立的权限。质量保证可以使用其他支持过程（如验证、确认、联合评审、审核和问题解决等过程）的结果。 质量保证过程包括以下活动： a)过程实现； b)产品保证； c)过程保证； d)质量体系保证。
19、,引子扁鹊论医,病情越早被发现，治疗就越容易，病人受到的损害也就小。,魏文王问名医扁鹊说：“你们家兄弟三人，都精于医术，到底哪一位最好呢？” 扁鹊答说：“长兄最好，中兄次之，我最差。” 文王再问：“那么为什么你最出名呢？” 扁鹊答说：“我长兄治病，是治病于病情发作之前。由于一般人不知道他事先能铲除病因，所以他的名气无法传出去，只有我们家的人才知道。我中兄治病，是治病于病情初起之时。一般人以为他只能治轻微的小病，所以他的名气只及于本乡里。而我扁鹊治病，是治病于病情严重之时。一般人都看到我在经脉上穿针管来放血、在皮肤上敷药等大手术，所以以为我的医术高明，名气因此响遍全国。” 文王说：“你说得好极了
20、。”,从TQM （全面质量管理）开始，过程成为提高产品质量的另一重要手段技术并非提高质量的唯一出路TQM的思想好的过程导致好的产品缺陷越早发现、越早修改，就越经济,制定并实施 好的过程，预防缺陷的产生，尽早的排除缺陷,一九五零年美国统计学家爱德华兹.戴1111111111明出席东京的一个晚宴，并发表了关于如何解决日本战后的经济问题的演讲。他指出，质量管理并不是从生产流程末端的产品瑕疵检查才开始的，而是贯穿于整个生产过程的各个环节，需要从供应商到最普通的车间工人等所有人的积极合作。并且郑重承诺，如果日本公司采用他的建议，那么他们的产品在五年内达到世界级水准。,成功实施该过程的结果是： a)制定了
21、实施质量保证的策略； b)产生并维护了质量保证的证据； c)标识并记录了问题和/或与协定需求不符合的内容； d)验证了产品、过程和活动与适用的标准、规程和需求的依从性。,2.4.4 验证过程 验证过程是一个确定某项活动的软件产品是否满足在以前的活动中施加于它们的需求和条件的过程。 该过程的目的是：证实一个过程和/或项目的每一软件工作产品和/或服务恰当地反映了已规定的需求。验证过程可应用于供应、开发、运行或维护等过程。该过程可以由来自同一组织一个人或多个人来实施，也可以由来自另一组织的人员来实施。在由一个独立于供方、开发者、操作者或维护者的组织来执行该过程的情况下，该验证过程就称为独立的验证过程
22、。 该过程包括以下活动： a)过程实现； b)验证。,其中活动：验证 包括以下任务：（1）合同验证。其中应考虑下面列出的准则：供方具有满足需求的能力；需求一致并覆盖了用户的需要；规定了可处理需求变更和处理问题蔓延的规程；规定了各方之间进行接口和合作的规程及其范围，包括所有权、许可权、版权和保密性；规定了符合需求的验收准则和规程。 注：该活动可用于合同评审。（2）过程验证。其中应考虑下面列出的准则：项目规划的需求是足够的、及时的；为项目所选择的过程是可行的、已实现的，是按计划执行的，并是符合合同的；用于项目过程的标准、规程和环境是满意的；根据合同要求，为项目配备了经过培训的人员。,（3）需求验证
23、。其中应考虑下面列出的准则：系统需求是一致的、可行的且是可测试的；根据设计准则，系统需求被适当地分配给了硬件项、软件项和手工操作；软件需求是一致的、可行的且是可测试的，并准确地体现了系统需求；通过适当严格的方法表明，有关安全保密性和关键性的软件需求是正确的。(4) 设计验证。其中应考虑下面列出的准则：设计是正确的、与需求一致并可追踪到需求；设计实现了适当的事件序列、输入、输出、接口、逻辑流，实现了按时和规模预算的分配以及错误定义、问题隔离及恢复；可以依据需求导出所选择的设计；通过适当严格的方法表明，设计正确地实现了安全保密性以及其他关键性的需求。,（5）编码验证。其中应根据下面列出的准则：编码
24、可追踪到设计和需求，是可测试的和正确的，并且符合需求和编码标准；编码实现了适当的事件顺序、一致的接口、正确的数据和控制流、完备性、恰当的按间和规模预算的分配、错误定义、问题隔离和恢复；可以由设计或需求导出所选择的编码；通过适当严格的方法表明，编码正确地实现了安全保密和其他关键性的需求。（6）集成验证。其中应考虑下面列出的准则： 每个软件项的软件构件和软件单元已被完整的且正确的集成到该软件项中； 系统的硬件项、软件项和手工操作已被完整的且正确的集成到该系统中； 已根据集成计划执行了相应的集成任务。,（7）文档验证。其中应考虑下面列出的准则： a) 文档是充分的、完备的和一致的； b) 文档制订是
25、及时的； c) 文档的配置管理遵循了规定的规程。成功实施验证过程的结果是：制定并实现了验证策略；标识了验证所有要求的软件工作产品的准则；执行了所要求的验证活动；标识并记录了缺陷；给出了对顾客和其他相关方可用的验证活动的结果。,2.4.5 确认过程 确认过程是一个确定需求和最终的、已建成的系统或软件产品是否满足特定预期用途的过程。 该过程的目的是：证实对软件工作产品特定预期使用的需求已予实现。该过程可以作为开发过程中软件验收支持活动的一个部分来执行。该过程可以由来自同一组织一个人或多个人来实施，也可以由来自另一组织的人员来实施。在由一个独立于供方、开发者、操作者或维护者的组织来执行该过程的情况下
26、，该确认过程就称为独立的确认过程。 该过程包括以下活动： a)过程实施；b)确认。,其中活动：确认 包括以下任务： （1）为了对测试结果进行分析，准备所选择的测试需求、测试用例和测试规格说明。 （2）确保这些测试需求、测试用例和测试规格说明体现了特定预期用途的特殊需求。 （3）进行（1）、（2）中确定的测试，一般包括： a)强度、边界和异常输入的测试；软件产品隔离错误影响测试以及使错误影响最小化能力的测试，即：在失效时，测试该软件产品是否能得体降级； b)在过载、边界和异常条件下，测试该软件产品是否能向操作者提出协助请求； c)代表用户使用该软件产品成功完成其预期任务的测试。 （4）确认软件产
27、品满足它的预期用途。 （5）在目标环境的选定区域中，适当地对该软件产品进行测试。,注：确认可使用除了测试之外的其他方法，例如，分析、建模、模拟等。成功实施确认过程的结果是：a)制定并实现了确认策略；b)标识了确认所有要求的工作产品的准则；c)执行了要求的确认活动；d)标识并记录了问题；e)提供了所开发的软件工作产品适合于其预期用途的证据；f)给出了对顾客和其他相关方可用的确认活动的结果。 关于其他支持过程，例如联合评审过程、审计过程、问题解决过程等，可参阅相关标准。,2.4.6 联合评审过程 联合评审过程是评价项目的某个活动或阶段的执行情况和产品是否合适的过程。它可以由任意两个合作伙伴所使用，
28、由其中一方评审另一方。2.4.7 审计过程 审计过程的目的是确定遵照需求、计划合同的程度。审计可由任何两个合作伙伴使用，由其中一方审计另一方的软件产品或活动。2.4.8 问题解决过程 问题解决过程是一个用于分析和排除在开发、运行、维护和其他过程中发现问题或不一致的过程。其目的是提供一种适时的、可信赖的并编成文档的手段，以保证分析和排除所有的问题并指明各种倾向。,2.5 组织过程 是指那些与软件生产组织有关的过程。 包括7个过程：a) 管理过程； b) 基础设施过程； c) 改进过程； d) 人力资源过程； f) 资产管理过程； g) 复用程序管理过程 h) 领域软件工程过程。2.5.1 管理过
29、程 管理过程是软件生存周期过程中管理者所从事的一系列活动。管理人员负责产品管理、项目管理和过程（例如，获取、供应、开发、运作、维护或支持过程）任务的管理。 管理过程包含以下活动: 1）启动与范围定义； 2）规划； 3）测量； 4）执行和控制； 5）评审和评估 6）结束处理。,成功实施管理过程的结果是： a)定义了那些要管理的过程和活动的范围； b)标识了为达到这些过程目的必须执行的活动和任务； c)对达到过程目标以及可用的资源和限制条件的可行性，进行了评估； d)建立了执行已标识那些活动和任务所需要的资源和基础设施； e)标识了活动并实施了任务； f)对定义的那些活动和任务的执行，进行了监督；
30、 g)对过程活动所产生的工作产品进行了评审，并对相应的结果进行了分析和评估； h)在过程的执行偏离已标识的活动和任务，或未能达到其目标时，采取了修改过程执行的措施； i)有证据地阐明了该过程已成功地达到了它的目的。,2.5.2 改进过程 改进过程是管理人员从事的一组活动和任务，其目的是：建立、评价、测量、控制和改进软件生存周期过程。主要活动：a) 过程建立；b) 过程评价；c) 过程改进。成功实施该过程的结果是：为组织开发了一组可用的过程资产；为了确定在达到组织目标中过程实施有效性的程度，定期地对组织的过程能力进行了评价， 在已有的基础上，为了达到该组织的业务目标，改进了过程的有效性和效率。,
31、2.5.3 基础设施过程 （基础设施包括：硬件、软件、工具；技术、标准以及开发所需的其他设施） 是建立、维护任何其他过程所需的基础设施的过程。 主要活动： a) 过程实现； b) 建立基础设施； c) 维护基础设施。成功实施该过程的结果是：为支持组织单元内的过程，定义了基础设施需求；标识并规约了基础设施要素；获取了基础设施要素；实现了基础设施要素；维护了稳定的和可靠的基础设施。,2.5.4 人力资源过程 人力资源过程是为组织和项目提供具有技能和知识人员的过程，其目的是：提供适当的人力资源，并不断使他们具有与业务要求相一致的技能水平，使这些人员能有效地履行其角色并能紧密、协调地工作。 该过程包括
32、以下活动：a)过程实施；b)定义培训需求；c)补充合格的员工；d)评价员工业绩；e)建立项目团队需求；f)知识管理。,成功实施人力资源过程的结果是：通过及时地对组织需求和项目需求的评审，为组织和项目的运作标识了所需要的角色和技能；为组织和项目提供了人力资源；基于组织和项目的需要，标识并提供一组组织内的公共培训；给出了该组织可用的智能方面的资产，并可通过已建立的机制来利用之。关于组织过程中的其它内容，例如资产管理过程、复用管理过程以及领域软件过程过程等，可参见相应的标准。 关于组织过程中的其它内容，例如资产管理过程、复用管理过程以及领域软件过程过程等，可参见相应的标准。,审计,2.6 软件过程之
33、间的关系,获取过程,获取过程,供应过程,管理过程,运行过程,开发过程,维护过程,获取者供应者,管理者,操作者用 户,开发者维护者,支持过程的应用者,组织过程：管理、改进.,支持过程：文档、质量保证、 配置管理 .,合同,应用,合同视角,管理视角,运行视角,工程视角,支持视角,应用,应用,应用,按着合同视角，涉及的角色有需方和供方，在谈判并签订合同的基础上，分别应用获取过程和供应过程。其中，获取过程用于需方，供应过程用于供方。,按着管理视角，涉及的角色有需方、供方、开发者、操作者、维护者或其他参与方，它们应用管理过程对相关的过程进行管理。,按着运行视角，涉及的角色有操作者和用户，涉及的过程是运行
34、过程，由一些活动组成。其中用户运行软件，而操作者为用户提供软件运行服务。,按着工程视角，涉及的角色有开发者或维护者完成其相应的工程任务，以生产或修改软件产品。有生存周期两个过程：开发过程和维护过程。开发工程师应用开发过程来生产软件产品；维护工程师应用维护过程来修改软件，使其对当前是有效的。,按着支持视角，涉及的角色是提供过程支持的服务人员，例如配置管理、质理保证人员，他们为其他人员提供服务，以完成特定的任务。其中从质量管理的角度，涉及5个生存周期过程：质量保证过程；验证过程；确认过程；联合评审过程；审核过程。,2.6 剪裁过程： 在国际标准ISO/IEC 12207-1995 软件生存周期过程
35、的附录A中，给出了相应的剪裁过程。 目的：针对特定领域的软件工程，为了有效地实施软件过程，提供一种选定过程模型和标准的机制，以便形成该工程的各个软件过程和活动。 剪裁过程作为一类软件过程，是对软件过程和活动实施剪裁的过程。 主要活动： a) 标识项目环境； b) 请求输入； c) 选择过程、活动和任务；d) 将剪裁决定和理由形成文档。 如：标识项目环境 标识影响剪裁工作的项目环境特征。例如使用的过程模型和方法，系统和软件需求，机构的政策和策略，参与工程的人员素质、数量等。,就目前的认识来说，在应用剪裁过程中，主要应考虑以下一些关键的项目特征：a) 组织方针 确定与项目相关的、可用的组织方针，比
36、如，有关计算机语言、安全保密性和硬件保存等方面的需求和风险管理。这样，就应保留那些与这些方针有关的过程、活动和任务。b) 获取策略 确定与项目相关的、可用的获取策略，比如，合同类型，承包方，涉及的分包方，参与验证和确认的机构，需方参与承包方的程度，以及对承包方的能力评估。这样，这样，就应保留那些与这些获取策略有关的过程、活动和任务。c) 支持概念 确定与项目相关的、可用的支持概念，比如，预期的支持期限、变更程度以及需方或供方是否将予以支持等。如果软件产品将有较长的支持生存期，或者预期将发生重大变更，就应该考虑所有文档编制需求，并建议自动生成文档。,d) 生存周期模型 确定与项目相关的、可用的生
37、存周期模型，比如，瀑布模型、演化模型、构造模型、预先规划的产品改进模型以及螺旋模型等。所有这些模型都描述一些确定过程和活动，这些过程和活动可以以顺序、重复和组合的方式执行。在此基础上，应把本标准的生存周期活动映射到所选择的模型中。对于演化模型、构造模型和预先规划的产品改进模型，是将一个项目活动的输出作为下一项活动的输入，因此，在这种情况下，文档编制应当在一项活动或任务结束时完成。e) 参与方 确定或标识项目中的参与方；比如，需方、供方、开发者、分包方、验证机构、确认机构、维护者和人员数量。要考虑与两个参与方（例如，需方与开发者，供方与验证或确认机构）之间的组织接口有关的所有需求。涉及许多（几十
38、或几百）人的大型项目需要大量的管理监督和控制。对于大型项目，内部的和独立的评估、评审、审核和审查以及数据收集都是重要的工具。对于小型项目，这些控制可能是多余的。,f) 系统生存周期活动 确定与项目相关的、可用的当前系统生存周期活动，比如，需方的项目启动，供方的开发和维护。某些场景：需方正在启动或确定系统需求。可能进行了需求和设计的可行性研究和原型制作，可能开发了原型的软件代码，这些代码在今后按合同进行软件产品开发时可能使用，也可能用不到。可能编制了系统需求和初步的软件需求。在这些情况下，在应用剪裁过程中，就不应把标准中的开发过程作为需求（但可以一个作指南），可能不需要严格的评估，也可能不需要联
39、合评审和审核。开发者正在按合同生产软件产品。在这种情况下，在应用剪裁过程中，就应该考虑是否需要所有的开发过程。维护者正在修改软件产品。要考虑维护过程。可能将开发过程的某些部分作为子过程使用。g) 系统层特性 确定相关的、可用的系统层特性，比如，子系统和配置项的数量。如果系统有许多子系统或配置项，就应该针对每个子系统和配置项仔细地剪裁开发过程，应该考虑所有接口和集成的需求。,h) 软件层特性 确定相关的、可用的软件层特性，比如，软件项的数量，软件产品的类型、规模和关键性以及技术风险。如果软件产品有许多软件项、构件和软件单元，就应该针对每一软件项仔细剪裁开发过程，应该考虑所有接口和集成的需求。确定
40、所涉及的软件产品类型，因为不同类型的软件产品可能要求不同的剪裁决策，例如：新的开发。在应用剪裁过程中，应考虑所有软件过程，特别是开发过程；使用现成的软件产品。在这种情况下，开发过程就可能是多余的，而应对该软件产品的性能、文档、专利、用途、所有权、担保、许可权和未来的支持等进行评估；修改现成的软件产品。在这种情况下，可能就不使用文档过程，而应根据关键性和预期的未来变更，伴随维护过程来使用开发过程；应对该软件产品有关的性能、文档、专利、所有权、用途、担保、许可权和未来的支持等进行评估。,嵌入或集成到一个系统中的软件或固件。由于这样的软件产品是一个系统的一部分，因此就应该考虑开发过程中那些与该系统有
41、关的活动，例如系统体系结构设计等，其中仅需选择一些具有动词“执行”或“支持”的活动。如果软件或固件产品在未来不可能进行修改，那么就应该仔细检查文档需要的范围； 独立的软件产品。由于这种软件产品不是系统的组成部分，因此就不需要考虑开发过程（2.3.3 ）中那些与系统有关的活动，例如系统体系结构设计等，而应仔细检查文档需要，特别是文档的维护；非交付的软件产品。由于这样的项不涉及获取、供应甚至开发，因此只需考虑开发过程中的活动1之任务5。然而，如果需方决定为了将来的运行和维护而需要这一软件产品的话，那么就应该按上述b）或c）来处理之。,其他因素 系统越是依赖软件产品正确工作和及时完成，那么就越要通过测试、评审、审核、验证、确认等手段来加强管理上的控制。反之，对非关键的或小型的软件产品进行过多的管理上的控制，可能就需要更大的成本。 软件产品的开发可能有技术风险。如果应用的软件技术不成熟，所开发的软件产品是前所未有的或是复杂的，或软件产品包含安全保密或其他关键需求，那么可能需要严格的规格说明、设计、测试和评估，并且独立的验证和确认可能就是重要的。,
