第07章节 软件工程与软件过程管理-2.ppt

第7章 软件工程与软件过程管理 7.1软件工程概述 软件危机的出现——20世纪60年代末70年代初 “软件工程”的概念——1968年 Fritz Bauer首先提出：软件应当由专业人员制作，以系统的、工程的方法开发，并提供全方位的售后服务管理 系统的方法——任何产品都有创意、开发、生成、调试、使用、维护、退役的全过程，而不是只考虑其中一部分 工程方法——有工程规范和工程管理。工程规范要求再给定的时间、经费和技术条件下达到符合规范要求的最佳；工程管理要考虑可行性、计划性、投入/产出、费用/效益 软件工程以系统工程的方法制作软件产品，包括 软件的系统（生存期）模型 与此模型对应的各种规范和标准 为达到这些规范、标准的方法和工具 软件生产、交付、使用、维护的全面管理 软件＝程序＋文档 软件方法学——一组规范的方法，执行后可以达到较理想的结果，将其标准化就是软件开发标准 IEEE的软件工程定义——以系统的、规范的、定量的方法应用于软件的开发、运营和维护，以及对这些方法的研究 7.2 软件工程过程 7.2.1软件过程活动 软件过程和软件质量 造成软件工程延误的原因 人员组织缺陷 人员不胜任 需求变动频繁 工具配套不齐 信息不足 管理漏洞 决策缺陷 问题估计不足 标准规范不当 过程模型不当 对质量产生影响的原因 过程模型不当，管理太死 模型正确，活动安排不当（评审、讨论不当） 工期临近，加班突击，缺乏测试、质检 多次返工，临时小决策太多，没有再次的总评审，总体结构不好 过程模型与实例过程 将辅助、支持过程插入主过程，建立过程模型 根据过程模型，列出项目计划和各种管理措施。落实了项目计划和管理措施就刻画了实施项目的实例过程，包括各种活动的强度、完成日期和约束 7.2.2 软件过程模型 主过程或称关键活动域的模型 1、瀑布模型 2、原型模型 3、螺旋模型 4、构件组装模型 5、快速应用开发模型 1、瀑布模型 瀑布模型也称软件生存周期模型，由W.Royce于1970年首先提出 规定：一个阶段（子过程）完了之后必须作正式技术评审；评审后的文档必须结果正式手续才能改动；做完一个阶段才能开始下一个阶段 优点：错误发现及时 缺点：在软件开发初期确定系统的全部需求是困难的 得到最初的版本要等相当长的时间 2、原型模型 基本思想：尽早拿出反映业务过程核心技术的样板让用户试用一些，修改和补充了需求再接着开发 基本上按瀑布模型划分阶段：分析 — 设计 — 编码 — 测试 —交付，设计注重上层，找一个或几个最有代表性的子系统快速编码测试，所以也叫快速原型(rapid prototyping) 三种形式： 扔掉原型——展示产品的逻辑性、可行性 增量原型——前面的工作为最终产品，随后细化编码测试 演进原型——先给出完整的抽象系统，逐步细化至完成 原型增加了开发的工作量，增加了管理上的困难。特别是原型过程步骤事先难于计划，不知道应反复几次，从哪里开始反复，预算进度均难于控制。但它具有切合实际，成功率较高的优点，故至今仍在使用 3、螺旋模型 软件过程描述为：用户通信－计划－风险分析－做工程－构造与发布－用户评审 周而复始的六种活动 4、构件组装模型 面向对象和基于构件包的软件要重用大量构件，这些构件是适用于某个领域的(例如，建筑，财经、商场，电信等)。它将以前开发并使用良好的构件规范化之后放入项目库 这类软件的开发过程也采用螺旋模型，只是把做工程和构造及发布合成一个步骤。风险分析后，转入客户评价。步骤如下： (1)先标识本项目需要什么构件； (2)库中查找构件或相似的构件； (3)如果可用转[4] 否则自行开发或修改，确认后入库； (4)构造为新系统； (5)测试、确认。 5、快速应用开发模型(RAD) RAD有以下步骤: (1)业务模型：以什么信息驱动业务过程运作? 要生成什么信息? 谁生成它? 信息流的去向? 由谁处理? 可以辅之以数据流图 (2)数据模型:为支持业务过程的数据流，找数据对象集合,定义数据对象属性,与其它数据对象的关系构成数据模型，可辅之以E-R图。 (3)做处理模型:如何使数据对象在信息流中完成各业务功能。描述数据对象的增加、修改、删除、查找。即细化数据流图中的处理框。 7.2.3 一个实用的应用开发过程模型 微软解决方案框架（MSF Microsoft solution framework）综合了瀑布模型和螺旋模型的优点 开发过程与螺旋模型相似，简化为四个子过程的反复，以一次发布为终结，即： 创意 计