软件工程概述教学课件.ppt

4. 软件工程知识体系SWEBOK 2004年6月，美国IEEE-CS和ACM编制的《软件工程知识体系指南2004》(SWEBOK 2004)正式发布，为软件工程知识体系本身以及相关知识之间确立了明确的边界，是我们认识软件工程学科知识体系的很好参考。 整个知识体系分为11个知识领域（Knowledge Area，KA） 前五个知识领域是按软件开发的生命期阶段（按所谓瀑布模型）排列的 软件需求(又称软件分析) 软件设计 软件构造(即编码、实现) 软件测试 软件维护 后六个知识领域则是软件开发中的支撑性或者辅助性的方面，一般覆盖软件开发的多个阶段甚至所有阶段，包括：软件配置管理(SCM)、软件项目管理、软件工程过程、软件工程工具与方法、软件质量、相关学科知识领域 每个知识领域之下又分为多个子领域，子领域又由多个主题构成。 现代软件工程知识体系SWEBOK 软件工程知识体系指南 （SWEBOK2004） 软件需求 软件需求基础 需求过程 软件获取 需求分析 需求规格说明 需求确认 实际考虑 软件设计 软件设计基础 软件设计关键问题 体系结构 设计质量分析 设计符号 策略与方法 软件构造 软件构造基础 管理构造 实际考虑 软件测试 软件测试基础 测试级别 测试技术 需求分析 测试度量 测试过程 软件维护 软件维护基础 软件维护关键问题 维护过程 维护技术 现代软件工程知识体系SWEBOK 配置管理 过程管理 配置标识 配置控制 状态报告 配置审计 发布管理 项目管理 范围定义 项目计划 项目实施 评审评价 项目收尾 工程度量 软件过程 实施变更 过程定义 过程评定 过程度量 工具方法 软件工具 需求工具 软件工程方法 启发式方法 形式化方法 原型方法 软件质量 质量基础 质量过程 实际考虑 相关知识 计算机工程 计算机科学 管理 数学 项目管理 质量管理 人类工程学 系统工程 设计工具 构造工具 测试工具 维护工具 配置管理工具 质量管理工具 项目管理工具 其他工具问题 软件神话之管理神话 神话: 我们已经有了一本写满软件开发标准和规程的宝典。它无所不包，囊括了我们可能问到的任何问题。 事实: 这本宝典也许的确已经存在，但它是否在实际中采用了？我们的软件人员是否了解到它的存在呢？它是否反映了软件工程的现状？是否全面？是否可以适应不同的应用环境？它是否在缩短交付时间的同时还关注保证产品的质量？在很多情况下，问题的答案是否定的。 神话: 如果我们未能按时完成计划，我们可以通过增加程序员人数而赶上进度（人月神话）。 事实: 软件开发并不是像机器制造那样的机械过程。Brooks曾说过：“在软件工程中，为赶进度而增加人手，只能使进度更加延误”。 神话: 如果我将一个软件外包给另一家公司，则我可以完全放手不管。 事实: 如果一个组织对软件项目的内部组织和控制毫无了解，那无一例外地将在外包项目中遇到困难。 软件神话之用户神话 神话: 有了对项目目标的大概了解，便足以开始编写程序，我们可以在之后的项目开发过程中逐步了解细节。 事实: 虽然通常很难得到综合全面且固定不变的需求描述，但是对项目目标模糊不清的描述将为项目实施带来灾难。清晰的需求描述（经常是逐步变得清晰）要求顾客和开发人员之间不断保持有效的沟通。 神话: 虽然项目需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变更。 事实: 软件需求的确在随时变更，但随变更引入的时机不同，变更所造成的影响也不同。 变更的代价 软件神话之从业者神话 神话: 当我们完成程序并将其交付使用之后，我们的任务就完成了。 事实: 有人曾说过，对于编程来说，开始得越早，耗费的时间就越长。业界的一些数据显示，60%~80%的工作耗费在软件首次交付顾客使用之后。 神话: 直到程序开始运行，才能评估其质量。 事实: 最有小的软件质量保证机制之一——正式技术评审，可以从项目启动就开始实行。软件评审作为“质量过滤器”，已经证明可以比软件测试更能有效地发现多种类型的软件错误。 神话: 对于一个成功的软件项目，可执行程序是唯一可交付的成果。 事实: 软件配置包括很多内容，可执行程序只是其中之一。文档时软件工程的基础，更重要的是，为软件支持提供了指导。 神话: 软件工程将导致我们产生大量无用文档，并因此降低工作效率。 事实: 软件工程并非以创建文档为目的，而是为了保证软件开发的质量。好的质量可以减少返工，从而最终缩短开发时间。 软件所带来的挑战 How do we ensure the quality of the software that we produce? How do we meet growing demand and still maintain budget control?