《软件工程》第2课软件生存周期与软件过程

1、第软件生存周期与软件过程知识回顾 软件工程学的范畴过程、方法、工具 软件工程的发展三种编程范式三代软件工程前馈及作业总结 作业电子版、笔记都可以，电子版随每次前馈一起提交，笔记定期检查。 自学情况、需要精讲要填选，必须提出问题，要每个人都有，提出1-2个好问题。 名称：第X小组软件工程课程前馈表，每个小组集成到一个文件中。用QQ发离线文件交给我。问题解答 如果我们自己研究一个项目，怎么确定使用哪个模型进行研发，每个如果我们自己研究一个项目，怎么确定使用哪个模型进行研发，每个模型各有特点，优缺点，是否可以根据需求在软件开发的阶段选择最模型各有特点，优缺点，是否可以根据需求在软件开发的阶段选择最合

2、适的模型进行研发？马振兴合适的模型进行研发？马振兴 在软件风险中，有一项是编程人员离职，毕竟编程人员每个人的编码在软件风险中，有一项是编程人员离职，毕竟编程人员每个人的编码风格不同，怎么能降低这一情况产生时对项目的负面影响？史孟然风格不同，怎么能降低这一情况产生时对项目的负面影响？史孟然 螺旋模型从表面上看是采用了之前各个模型的优点建立的（保证了质螺旋模型从表面上看是采用了之前各个模型的优点建立的（保证了质量），但是螺旋模型的每一个小部分都使用瀑布模型和原型岂不是增量），但是螺旋模型的每一个小部分都使用瀑布模型和原型岂不是增加了开发成本和时间？陈万敏加了开发成本和时间？陈万敏前馈检查 把生存周

3、期划分为阶段的目的是什么？ 传统的瀑布模型把生存周期分为哪些阶段？ 可行性研究包含哪些内容？ 为什么要进行风险分析？讲授内容 生存周期与软件过程的关系 传统的软件过程 瀑布模型、快速原型模型 软件演化模型 增量模型、螺旋模型 、构件集成模型 统一过程和敏捷过程 软件可行性研究 可行性研究的内容与步骤 软件风险分析第二章 软件生存周期与软件过程p软件生存周期软件生存周期p传统的软件过程传统的软件过程p软件演化模型软件演化模型p统一过程和敏捷过程统一过程和敏捷过程p软件可行性研究软件可行性研究1. 软件生存周期 软件生存周期软件生存周期（Software Life Cycle）：一个软件项目从问）

4、：一个软件项目从问题提出开始，直到软件产品最终退役（废弃不用）为止。题提出开始，直到软件产品最终退役（废弃不用）为止。 软件生存周期分为三个时期：软件生存周期分为三个时期：计划、开发和维护计划、开发和维护 整个软件生存周期划分为多个相对独立的较小整个软件生存周期划分为多个相对独立的较小阶段阶段，给每，给每个阶段赋予确定而有限的任务，从而降低了整个软件工程个阶段赋予确定而有限的任务，从而降低了整个软件工程的难度，提高了软件开发生产率的难度，提高了软件开发生产率典型的软件生存周期需求分析软件分析软件设计编码（测试）交付测试使用维护典型的软件生存周期软件生存周期的主要活动 需求分析明确需要解决的问题

5、（从用户的视角）建立需求模型：功能、性能、约束、接口等 软件分析从开发人员的视角对软件进行分析建立分析模型：软件的逻辑模型 软件设计确定软件的总体结构和各部件的数据结构和操作建立软件设计模型：考虑实现技术和平台 编码用程序设计语言将设计文档翻译成源程序建立软件实现模型：包含现有软件构件包 软件测试发现程序中的错误、提高软件质量单元测试、集成测试、确认测试、系统测试 运行维护软件过程与软件生存周期 软件过程软件过程 围绕软件开发所进行的一系列活动，早期也叫围绕软件开发所进行的一系列活动，早期也叫“软件开软件开发模型发模型”。 软件过程模型软件过程模型 把软件生存周期中软件开发活动的有序流程用一个

6、合理把软件生存周期中软件开发活动的有序流程用一个合理的框架来规范描述。的框架来规范描述。 软件过程模型是一种软件过程的抽象表示法，它从一个软件过程模型是一种软件过程的抽象表示法，它从一个特定的角度表现一个开发过程。特定的角度表现一个开发过程。 软件生存周期中的阶段和软件过程中的活动是基本软件生存周期中的阶段和软件过程中的活动是基本一致的。一致的。2.传统的软件过程 传统的过程模型瀑布模型（waterfall model）基于软件生存周期的线性开发模型。 快速原型模型（rapid prototype model） 基于原型的迭代化开发模型。瀑布模型图2.2 瀑布模型的阶段与文档需求分析需求规格说

7、明软件分析与总体设计软件结构图模块说明系统测试确认测试综合测试程序清单详细设计编 码用户要求单元测试nW.Royce于1970年提出n线性开发模型n强调软件文档每一个阶段必须完成规定的文档每一个阶段都要复审完成的文档瀑布模型特点阶段的顺序性（前一阶段完成后才能开始下一阶段）和依赖性（前一阶段输出文档是下一阶段输入文档）。推迟实现的观点（不要过早编码）。质量保证的观点（必须完成文档并进行复审）。存在问题不适合需求模糊的系统。开发初始阶段很难彻底弄清软件需求。快速原型模型需求原型开发最终系统设计原型评价最终系统实现用户反馈快速原型模型 特点 “逼真”的原型可以使用户迅速作出反馈。循环回溯和迭代：非

8、线性模型。使用快速开发工具。 种类渐进型：对原型补充和修改获得最终系统。抛弃型：原型废弃不用。 应防止的偏向舍不得抛弃，从而影响软件质量。3.软件演化模型 演化开发模型，遵循迭代的思想方法，使所开发的软件在迭代中逐步完善。增量模型（incremental model）。螺旋模型（spiral model）。 构件集成模型（component integration model）。增量模型把软件看作一系列相互联系的增量，每次迭代完成一个增量把软件看作一系列相互联系的增量，每次迭代完成一个增量构件1：需求设计实现和集成交付客户构件2：需求设计实现和集成交付客户构件3：需求设计实现和集成交付客户构件

9、n：需求设计实现和集成交付客户规格说明组设计组实现和集成组增量模型 增量小而可用的软件。第一个增量通常是软件的核心。 特点在前面增量的基础上开发后面的增量。每个增量的开发可用瀑布或快速原型模型。每个增量开发的顺序性和总体的迭代性相结合。螺旋模型螺旋模型 特点瀑布模型（顺序性、边开发边复审）+快速原型（迭代性）。适用大型软件开发。风险分析，发现、控制风险。 一个螺旋式周期 计划：确定目标，选择方案，选定完成目标的策略。 风险分析：从风险角度分析该策略。 开发：启动一个开发活动。 评审：评价前一步的结果，计划下一轮的工作。 构件集成模型 面向对象的基本概念对象（Object）类（Class）继承（

10、Inheritance）消息（Message ）面向对象对象+类+继承+消息通信 面向对象开发模型均可借用面向过程开发模型。构件集成模型主要适用于面向对象的软件开发。构件集成模型 构件在某个领域内具有通用性，可以复用的软件部件。将可以复用的构件存储起来，形成构件库构件库。 特点面向对象。基于构件库。 融合螺旋模型特征。 支持软件开发的迭代方法 。软件复用。构件集成模型4.形式化方法模型 形式化方法模型，基于程序变换和验证技术的软件开发。 转换模型（transformational model）。 净室模型（cleanroommodel）。转换模型 开发过程确定形式化需求规格说明书。进行自动的程

11、序变换。针对形式化开发记录进行测试。 常用技术 基于模型的需求规格说明书及变换技术。 基于代数的需求规格说明书及变换技术。 基于时序逻辑的需求规格说明书和验证技术。 基于可视形式化的技术。 转换模型形式化规格说明与 需 求比 较 后修正变换2变换1变换n测试形式化开发记录系统需求目标系统净室模型 净室思想在分析和设计阶段消除错误。在“洁净”状态下实现软件制作。 增量模型把软件看成一系列的增量。 形式化每一个增量用形式化表示盒，表示分析和设计。正确性验证。净室模型需求收集盒结构规约形式化设计统计性使用测试正确性证明代码生成与检查测试计划认证需求收集盒结构规约形式化设计统计性使用测试正确性证明代码

12、生成与检查测试计划认证需求收集盒结构规约形式化设计统计性使用测试正确性证明代码生成与检查测试计划认证增量1增量2增量n软件过程模型的特点汇总开发模型开发模型特特 点点适用场合适用场合瀑布模型线性模型，每一阶段必须完成规定的文档需求明确的中小型软件开发快速原型模型用户介入早，通过迭代完善用户需求，原型废弃不用需求模糊的小型软件开发增量模型每次迭代完成一个增量，可用于OO开发容易分块的大型软件开发螺旋模型典型迭代模型，重视风险分析，可用于OO开发具有不确定性大型软件开发构件集成模型软件开发与构件开发平行进行领域工程、行业的中型软件开发转换模型形式化的规格说明，自动的程序变换系统理想化模型，尚无成熟

13、工具支持净室模型形式化的增量开发模型，在洁净状态下实现软件制作开发团队熟悉形式化方法，中小型软件开发课堂互动 快速原型快速原型的的快速表现在哪里？实现快速原快速表现在哪里？实现快速原型法的最终系统可以有几种方法？请说明型法的最终系统可以有几种方法？请说明并加以比较。并加以比较。5. 统一过程和敏捷过程 统一过程Rational Unified Process（RUP）描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动。 敏捷过程Agile Development是一种以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程”。RUPR

14、ational Unified Process 将软件开发分为四个阶段：初始初始 定义整个项目的范围，是否可行。细化细化 制定项目计划、描述功能、建立体系架构框架。构造构造 构造软件产品。迁移迁移 将软件产品移交到最终用户手中。敏捷过程把一个大项目分为多个相互联系但也可独立运行的小项目，并分别完成，在此过程中软件处于可用状态。敏捷开发的价值观 个人和交互胜过过程和工具。 可以运行的软件胜过面面俱到的文档。 客户合作胜过合同谈判。 响应变化胜过遵循计划。敏捷过程敏捷开发的12条原则 尽早、不断地提交有价值的软件 允许改变需求，利用变化来为客户创造优势 尽快、不断地提交可运行的软件 在业务人员和开

15、发人员必须天天都在一起工作 以积极向上的员工为中心建立项目组，提供环境和支持，并信任他们的工作 在团队内部重视面对面的交流 依据可运行软件来评估项目的进展 提倡可持续的开发 时刻关注技术上的精益求精和好的设计，以增强敏捷能力 简单是最根本的 最好的构架、需求和设计出于自组织团队 每隔一定时间，要反省如何才能更有效地工作，然后作相应调整 极限编程 eXtreme Programming是一种轻量级的、敏捷的软件开发方法。 4个价值观交流、简单、反馈、勇气 4个方面改善加强交流、从简单做起、寻求反馈、勇于实事就是。 12个核心实践完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、

16、持续集成、代码共有、编码标准、系统比喻、可持续的速度。6.软件可行性研究 目的研究项目是否可能实现和值得进行。 研究的内容经济可行性技术可行性运行可行性法律可行性可行性研究的步骤 对当前系统进行调查和研究弄清当前系统导出新系统逻辑模型 导出新系统的解决方案设计不同的解决方案 提出推荐的方案本项目的开发价值推荐这个方案的理由 编写可行性论证报告系统概述可行性分析结论意见软件风险分析 软件开发存在风险。 风险识别项目风险（进度、人力、资源、客户）技术风险（设计、实现、接口、维护）商业风险（市场、策略、推销） 建立风险项目检测表产品规模商业影响客户关系人员技术例：人员配备风险检测表(1) 开发人员的

17、水平如何。(2) 开发人员在技术上是否配套。(3) 开发人员的数量如何。(4) 开发人员是否能够自始至终地参加软件开发工作。(5) 开发人员是否能够集中全部精力投入到软件开发工作。(6) 开发人员对自己的工作是否有正确的期望。(7) 开发人员是否接受过必要的培训。(8) 开发人员的流动是否能够保证工作的连续性。 上述问题可以选用0,1,2,3,4,5来回答。完全肯定取值为0，反之为5，中间情况分别取值1,2,3,4值越大表示风险越大。 人员配备风险检测表反映了人的因素给软件项目带来的风险。风险估算 软件项目管理人员可以从影响风险的因素和风险发生后的损失两方面来度量风险。风险评价和管理三元组 r

18、i，li，xi i =1,2,3l 风险序号 其中：ri表示风险，li表示风险发生的概率 xi表示风险产生的影响。 由于项目超支、进度拖延和软件性能下降都会导致软件项目的终止，对大多数软件项目，分析应都需要给出成本、进度和性能的风险参考值，当某一风险或风险组合值超过参考值时项目被迫停止。风险评价和管理三元组ri，li，xi是风险管理的基础 设高级职员流动给项目带来风险ri, 根据历史的经验或直观感觉，高级职员离开课题组的概率li = 70%, 这一风险导致事件xi发生 项目开发时间延长 15%，成本增加 20%项目负责人采取的风险管理措施(1)项目开始前控制产生风险的原因。项目开工后应设法减轻

19、风险的影响。(2)了解项目开发人员变动的原因，在项目开发期间应控制上述原因，尽量减少人员的流动。(3)在工作方法和技术上采取适当措施，防止因人员流动给工作带来损失。(4)项目在开发过程中应及时公布并交流项目开发的信息。(5)建立组织机构，确定文档标准、并及时生成文档。(6)对工作进行集体复审，使多数人都能了解工作的细节，跟上工作进度。(7)为关键技术准备后备人员。风险缓解、监控和管理计划 风险缓解、监控和管理计划 Risk Mitigation,Monitoring,and Management Plan 将风险分析工作文档化，成为项目的一部分。 执行RMMM计划需要成本 当软件项目比较大时，可能标出30至40种风险，如果为每种风险定义3至7种风险管理步骤，则风险管理本身就是一个项目。项目实施计划 软件