软件工程1-3.过程模型.ppt

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
1968 年正式提出“软件工程”这一术语之后,软件工程围绕计算机科学、工程和管理三个方面,做了很多研究,建立了早期关于软件工程管理的一些基本准则,从中,我们可以看出早期软件工程的一些思路与出发点。 其中最著名的是著名软件工程专家B.W.Boehm 在1983 年的一篇论文中,提出的软件工程7 条基本原理,反映了作为软件工程应该关注和考虑的若干本质问题: (1)用分阶段的生命周期计划严格管理 经统计表明,不成功的软件项目中有一半左右是由于计划不周造成的。 Boehm认为,在软件的整个生命周期中应制定并严格执行六类计划:项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。 (2)坚持进行阶段评审 大部分错误是在编码之前造成的 错误发现与改正得越晚,所需付出的代价越高。 因此,在每个阶段都进行严格的评审,以便尽早发现在软件开发过程的错误 (3)实行严格的产品控制 在软件开发过程中不要随意改变需求,因为改变某项需求往往需要付出较高的代价,但在实践中用户往往会提出需求变更,因此需要采取科学的产品控制技术。 目前主要实行基准配置管理:基准配置是指经过阶段评审后的软件配置成分,如各个阶段产生的文档或程序代码。 对涉及基准配置的修改,必须经过严格的评审,通过后才能实施修改。 (4) 采用现代程序设计技术 实践表明:采用先进的技术既可提高软件开发的效率,又可提高软件维护的效率。 80年代及之前:结构化分析、设计技术 90年代:面向对象分析、设计技术 (5) 结果应能清楚地审查 软件产品是看不见、摸不着的逻辑产品,开发过程难以评价和管理。 根据软件开发项目的总目标及完成期限,规定开发组织的责任和产品标准,使所得的结果能够清楚地审查 (6) 开发小组的人员应该少而精 开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。 开发小组人员数目的增加,使相互交流复杂、费用增加。 (7)承认不断改进软件工程实践的必要性 遵循前6条基本原理,就能够按照当代软件工程基本原理实现软件的工程化生产,但不能保证赶上时代前进的步伐。 积极主动采纳新的软件技术,且不断总结经验。 惯例过程模型通常称为“传统的”过程模型 回顾通用过程框架(包含哪些框架活动?) 下面我们要讨论一些惯例过程模型 模型应用背景:在可以相当清楚地了解问题的需求,从沟通到部署,工作可按线性的方式进行。 在对一个已有系统进行明确的调整或增强时(如税法修改了起征点,财务软件需要进行相应修改); 需求能准确定义并且相对稳定的新项目(如老师布置的大作业)。 3.2 瀑布模型 基于通用过程框架的瀑布模型 The Waterfall Model 3.2 瀑布模型 瀑布模型的另一个图示 传统的生命周期模型 70年由Royce提出 典型瀑布模型具有顺序性和依赖性 3.2 瀑布模型 瀑布模型的特征 从上一项活动中接受该项活动的工作成果(工作产品),作为输入。 利用这一输入实施该项活动应完成的内容 给出该项活动的工作成果,作为输出传给下一项活动 对该项活动实施的工作进行评审。若其工作得到确认,则继续下一项活动。 3.2 瀑布模型 瀑布模型的优点: 1.强调开发的阶段性; 2.强调早期计划及需求调查; 3.强调产品测试。 3.2 瀑布模型 瀑布模型的缺点: 从认识论角度看,人的认识是一个多次反复循环的过程,不可能一次完成。但瀑布模型中划分的几个阶段,没有反映出这种认识过程的反复性。 特别是瀑布模型过于依赖早期进行的唯一一次需求调查,不能适应需求的变化; 软件开发是一个知识密集型的开发活动,需要相互合作完成,但瀑布模型没有体现这一点。特别是由于瀑布模型是单一流程,开发中的经验教训不能反馈应用于本产品的过程。 3.2 瀑布模型 思考: 1、我们的日常生活中,有哪些活动是符合瀑布模型的? 2、为什么有时候我们的小型开发团队连瀑布模型都不能坚持做到?客观因素是什么? 3、瀑布模型的实用之地在哪里? 3.3 增量过程模型 模型应用背景:在许多情况下,初始的软件需求有明确的定义,但整个开发过程却不宜单纯运用线性模型。同时,可能迫切需要为用户迅速提供一套功能有限的软件产品,然后在后续版本中再细化和扩展功能。 两种增量过程模型:增量模型、RAD模型 3.3.1 增量模型 增量模型以迭代的方式运用瀑布模型。随着时间的推移,增量模型在每个阶段运用线性序列。每个线性序列生产出一个软件的可交付增量。增量模型又称产品改进模型(Incremental Model) 当使用增量模型时,第一个增量往往是核心的产品,即实现了基本的需求,但很多补充的特性(其中一些是已知的,另外一些是未知的)还没有发布。核心产品交用户使用(或进行更详细的复审),使用和/或评估的结果是下一个增量的开发计划。该

文档评论(0)

youyang99 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档