1、第第2章章 软件生存周期及开发模型软件生存周期及开发模型 软件生存周期软件生存周期 问题定义问题定义 软件定义软件定义 可行性研究可行性研究 需求分析需求分析 总体设计总体设计 详细设计详细设计软件生命周期软件生命周期 软件开发软件开发 编码编码 单元测试单元测试 综合测试综合测试 运行维护运行维护 持续满足用户需求持续满足用户需求软件过程软件过程 软件过程是为了获得高质量软件所需要软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完完成的一系列任务的框架，它规定了完成各项任务的工作步骤。成各项任务的工作步骤。工作任务里程碑、交付物SQA点 过程定义了运用方过程定义了运用方法的
2、顺序、应该交法的顺序、应该交付的文档资料、为付的文档资料、为保证软件质量和协保证软件质量和协调变化所需要采取调变化所需要采取的管理措施，以及的管理措施，以及标志软件开发各个标志软件开发各个阶段任务完成的里阶段任务完成的里程碑。程碑。公共过程框架公共过程框架辅助活动辅助活动框架活动框架活动任务集合任务集合软件开发模型软件开发模型 软件软件开发开发模型模型是软件开发全部过程、是软件开发全部过程、活动和任务的活动和任务的结构框架结构框架。它能直观。它能直观表达软件开发全过程，明确规定要表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。完成的主要活动、任务和开发策略。软件软件开发开发模型也
3、常称为模型也常称为：软件软件过程过程模型模型 软件生存软件生存周周期模型期模型 软件工程范型软件工程范型1.1.瀑布模型瀑布模型 (Waterfall ModelWaterfall Model)传统的瀑布模型传统的瀑布模型需求分析需求分析验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护定义时期定义时期开发时期开发时期维护时期维护时期传统瀑布模型开发软件的特点传统瀑布模型开发软件的特点1.1.阶段间具有顺序性和依赖性。阶段间具有顺序性和依赖性。2.2.推迟实现的观点。推迟实现的观点。3.3.每个阶段必须完成规定的文档每个阶段必须完成规定的文档;每个阶段结束
4、前完成文档审查每个阶段结束前完成文档审查,及早改正错误及早改正错误。传统瀑布模型存在什么问题？传统瀑布模型存在什么问题？传统的瀑布模型过于理想化。事实上，人在工传统的瀑布模型过于理想化。事实上，人在工作过程中不可能不犯错误。作过程中不可能不犯错误。在设计阶段可能发生规格说明文档中的错误。在设计阶段可能发生规格说明文档中的错误。而设计上的缺陷或错误可能在实现过程中显现而设计上的缺陷或错误可能在实现过程中显现出来。出来。在综合测试阶段将发现需求分析、设计或编码在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。阶段的许多错误。实际的瀑布模型实际的瀑布模型 瀑布模型瀑布模型的优缺点的优缺点 瀑布
5、模型有许多优点：可强迫开发人员采用规范的方瀑布模型有许多优点：可强迫开发人员采用规范的方法（例如，结构化技术）；法（例如，结构化技术）；严格地规定了每个阶段必严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。瀑布模型的成功在很经过质量保证小组的仔细验证。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。大程度上是由于它基本上是一种文档驱动的模型。“瀑布模型是由文档驱动的瀑布模型是由文档驱动的”这个事实也是它的一个这个事实也是它的一个主要缺点。主要缺点。实际项目很少按照该模型给出的顺序进行；实
6、际项目很少按照该模型给出的顺序进行；用户常常难以清楚地给出所有需求；用户常常难以清楚地给出所有需求；用户必须有耐心，等到系统开发完成；用户必须有耐心，等到系统开发完成；开发者常常被不必要地耽搁。开发者常常被不必要地耽搁。2.原型模型-快速快速原原型模型型模型 （Rapid Prototype ModelRapid Prototype Model）快速建立起来的可以在计算机上快速建立起来的可以在计算机上 运行的程序，他所能完成的功能运行的程序，他所能完成的功能 往往是最终产品能完成的功能的往往是最终产品能完成的功能的 一个子集。一个子集。快速快速原原型模型型模型工作过程工作过程 原型模型从需求收
7、集开始。开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。原型由用户评估，并进一步精化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解，这个过程是迭代的。按线性模型构建软件系统 听取用听取用 户意见户意见建造建造/修改修改原型原型用户测试用户测试运行原型运行原型快速原型快速原型验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护维护变化的需求变化的需求验证验证维护过程维护过程开发过程开发过程原型模型原型
8、模型 适用情况适用情况 用户定义了一组一般性目标，但不能标用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；识出详细的输入、处理及输出需求；开发者可能不能确定算法的有效性、操开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；作系统的适应性或人机交互的形式；原型模型可能是最好的选择原型模型可能是最好的选择 原型模型存在的问题 用户似乎看到的是软件的工作版本，其实 开发者常常需要实现上的折衷，以使原型能够尽快工作。3.3.增量模型（渐增模型）增量模型（渐增模型）(Incremental Model)(Incremental Model)先完成一个系统子集的开发，再按
9、同样的开发先完成一个系统子集的开发，再按同样的开发步骤增加功能步骤增加功能 (系统子集系统子集),),如此递增下去直至满如此递增下去直至满足全部系统需求。足全部系统需求。系统的总体设计在初始子集设计阶段就应作出系统的总体设计在初始子集设计阶段就应作出设想。设想。增量模型增量模型需求分析需求分析验证验证规格说明规格说明验证验证设计设计验证验证维护维护针对每个构件完成针对每个构件完成详细设计、编码和详细设计、编码和集成，经测试后交集成，经测试后交付给用户付给用户分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2 增量3增量4 交付交付交付交付增量模型的优点增量模型的优点1
10、.1.在较短时间内向用户提交可完成部分工作的产品，在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。交付之日起，用户就能做一些有用的工作。2.2.整个软件产品被分解成许多个增量构件，开发人整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。员可以一个构件一个构件地逐步开发。3.3.逐步增加产品功能可以使用户有较充裕的时间学逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能习和适应新产品，从而减少一个全新的软件可能给客户组织
11、带来的冲击。给客户组织带来的冲击。4.4.采用增量模型比采用瀑布模型和快速原型模型需采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。在维护阶段获得回报。使用增量模型的困难使用增量模型的困难1.1.在把每个新的增量构件集成到现有软件体系在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入于按这种方式进行扩充，向现有产品中加入新
12、构件的过程必须简单、方便，也就是说，新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。软件体系结构必须是开放的。2.2.开发人员既要把软件系统看作整体。又要看开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。成可独立的构件，相互矛盾。3.3.多个构件并行开发，具有无法集成的风险。多个构件并行开发，具有无法集成的风险。4.螺旋模型螺旋模型(Spiral Model)产品交付给用户后用户可能不满意；产品交付给用户后用户可能不满意；到了预定的交付日期软件可能还未开发到了预定的交付日期软件可能还未开发出来；出来；实际的开发成本可能超过预算；实际的开发成本可能超过预算；产品完
13、成前一些关键的开发人员产品完成前一些关键的开发人员 “跳槽跳槽”了；了；产品投入市场之前竞争对手发布产品投入市场之前竞争对手发布 了一个功能相近、价格更低的软了一个功能相近、价格更低的软 件等。件等。软件风险是任何软件开发项目中都普遍存在的软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。例如：目所冒的风险也越大。例如：螺旋模型的基本思想 使用原型及其他方法来尽使用原型及其他方法来尽量降低风险。量降低风险。快速原型快速原型验证验证规格说明规格说明验证验证设计设计验证验证编码编码测试测试综合测试综合测试维护
14、维护变化的需求变化的需求验证验证风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析风险分析可看作在每个可看作在每个阶段之前都增阶段之前都增加了风险分析加了风险分析过程的快速原过程的快速原型模型。型模型。简化的螺旋模型简化的螺旋模型图图1.8 完整的螺旋模型完整的螺旋模型 螺旋模型风险风险分析分析工程工程实施实施用户通信用户通信用户用户评估评估产品维护项目产品维护项目产品增强项目产品增强项目新产品开发项目新产品开发项目概念开发项目概念开发项目计划计划建造及发布建造及发布螺旋模型 优点优点 对可选方案和约束条件的强调有利于已有软件对可选方案和约束条件的强调有利
15、于已有软件的重用，也有助于把软件质量作为软件开发的的重用，也有助于把软件质量作为软件开发的一个重要目标；一个重要目标；减少了过多测试或测试不足；减少了过多测试或测试不足；维护和开发之间并没有本质区别。维护和开发之间并没有本质区别。特点特点 风险驱动风险驱动 主要适用于内部开发的大规模软件项目主要适用于内部开发的大规模软件项目 要有具有丰富风险评估专门知识的开发人员，否要有具有丰富风险评估专门知识的开发人员，否则风险更大。则风险更大。5.面向对象模型喷泉模型喷泉模型 (Fountain Model)可重用部件组装模型可重用部件组装模型 (构件集成模型）构件集成模型）（Component Inte
16、gration Model)5.5.面向对象面向对象模型模型喷泉模型喷泉模型(Fountain Model)可重用部件组装模型可重用部件组装模型 (构件集成模型构件集成模型)(Component Integration Model)喷泉模型分析分析设计设计实现实现测试测试集成集成演化演化喷泉模型特点 主要用于支持面向对象开发过主要用于支持面向对象开发过程体现了软件创建所固有的迭代和程体现了软件创建所固有的迭代和无间隙的特征无间隙的特征可重用部件组装模型可重用部件组装模型(构件集成模型构件集成模型)使用重用技术的软件工程模型使用重用技术的软件工程模型构件构件(Components)：可重用的软件
17、成可重用的软件成份份可复用性可复用性（Reusability）集成化软件开发环境集成化软件开发环境（ISEE-Integrated Software Engineering Environment）可重用部件组装模型可重用部件组装模型用户用户通信通信计划计划产品开发及发布产品开发及发布用户用户评估评估风险风险分析分析标志候标志候选构件选构件查找查找构件构件若存在则若存在则提取构件提取构件若不存在则若不存在则构造构件构造构件进行下进行下一次迭代一次迭代将新构件将新构件存入库中存入库中基于构件的软件工程基于构件的软件工程(CBSE)(CBSE)过程模型过程模型 构构 件件 开开 发发分析分析 设计
18、设计 编程编程 测试测试领域分析领域分析系统系统测试测试构件提交构件提交领域专家经验领域专家经验现有系统资料现有系统资料领域构领域构件需求件需求构件构件/构架库构架库领域构架领域构架领领域域构构件件系统系统开发开发系统专用构件系统专用构件应用应用系统系统构件生产线构件生产线领域构架领域构架领域构件领域构件问题域问题域用户需求用户需求系统生产线系统生产线 系系 统统 组组 装装 分析分析 设计设计 编程编程构架细化构架细化专专 用用 构构 件件 开开 发发分析分析 设计设计 编程编程 测试测试 软软 件件 生生 产产 线线应用构件应用构件提取车间提取车间构件生构件生产车间产车间标准规范标准规范
19、与与 质量保证质量保证1 1基础构件，基础构件，2 2功能构件功能构件 3 3接口构件，接口构件，4 4用户界面构件用户界面构件 应用应用构件库构件库 构件库构件库组装组装车间车间领域领域 1 1领域领域 2 2应用应用系统系统 .1 12 23 34 46.6.形式化方法形式化方法模型模型转换转换模型模型(Transformational ModelTransformational Model)净室模型净室模型(Cleanroom(Cleanroom Model)Model)形式化规格语言及其变换技术形式化规格语言及其变换技术 基于模型的规格说明及其变换技术基于模型的规格说明及其变换技术 基
20、于代数结构及其变换技术基于代数结构及其变换技术 基于时序逻辑的规格说明和验证技术基于时序逻辑的规格说明和验证技术 基于可视形式化技术基于可视形式化技术转换转换模型模型形式化形式化规格说明规格说明与需求比与需求比较后修正较后修正形式化开发记录形式化开发记录变换变换n变换变换2变换变换1测试测试系统需求系统需求目标系统目标系统 净室净室模型模型(形式化的增量开发模型形式化的增量开发模型)基于思想基于思想：力求在分析和设计阶段就消除错误，力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或确保正确，然后在无缺陷或“洁净洁净”的状态的状态下实现软件的制作。下实现软件的制作。三个关键技术三个关键技术
21、：置于统计过程控制之下的增量开发置于统计过程控制之下的增量开发 基于函数的规范、设计、验证基于函数的规范、设计、验证 统计测试和软件认证统计测试和软件认证 净净 室室 模模 型型盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量#1盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计性使用测使用测试试验证验证增量#2盒结构盒结构规约规约需求需求收集收集形式化形式化设计设计正确性正确性验证验证代码代码检查检查测试计划测试计划统计性统计
22、性使用测使用测试试验证验证增量#1.Rational 统一过程 Rational统一过程（Rational Unified Process,RUP）是由Rational软件公司推出的一种完整而且完美的软件过程。RUP总结了经过多年商业化验证的6条最有效的软件开发经验，这些经验被称为“最佳实践”。最佳实践迭代式开发管理需求使用基于构件的体系结构可视化建模验证软件质量控制软件变更RUP软件开发生命周期敏捷过程与极限编程 敏捷软件开发宣言由下述4个简单的价值观组成。（1）个体和交互胜过过程和工具（2）可以工作的软件胜过面面俱到的文档（3）客户合作胜过合同谈判（4）响应变化胜过遵循计划极限编程 极限编
23、程（eXtreme Programming,XP）是敏捷过程中最富盛名的一个，其名称中“极限”二字的含义是指把好的开发实践运用到极致。目前，极限编程已经成为一个典型的开发方法，广泛应用于需求模糊且经常改变的场合。极限编程的有效实践 客户作为开发团队的成员 使用用户素材 短交付周期 验收测试 结对编程 测试驱动开发 集体所有 持续集成 可持续的开发速度 开放的工作空间 及时调整计划 简单的设计 重构 使用隐喻极限编程的整体开发过程极限编程的迭代过程 综上所述，以极限编程为杰出代表的敏捷过程，具有对变化和不确定性的更快速、更敏捷的反应特性，而且在快速的同时仍然能够保持可持续的开发速度。上述这些特点使得敏捷过程能够较好地适应商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束。微软过程 微软过程基本准则 项目计划应该兼顾未来的不确定因素 用有效的风险管理来减少不确定因素的影响 经常生成并快速地测试软件的过渡版本，从而提高产品的稳定性和可预测性 采用快速循环、递进的开发过程 用创造性的工作来平衡产品特性和产品成本 项目进度表应该具有较高稳定性和权威性 使用小型项目组并发地完成开发工作 在项目早期把软件配置项基线化，项目后期则冻结产品 使用原型验证概念，对项目进行早期论证 把零缺陷作为追求的目标 里程碑评审会的目的是改进工作，切记相互指责微软软件生命周期微软过程模型
