软件系统开发与软件工程方法讲义.ppt

第七章软件系统开发与软件工程方法 一 软件危机二 软件工程 一 软件危机1 软件开发的发展历程 早期第二阶段第三阶段第四阶段 面向批处理 多用户 分布式系统 强大的桌面系统 有限的分布 实时 嵌入 智能 面向对象技术 自定义软件 数据库 低成本硬件 专家系统 开发者 使用者 软件产品 人工神经网络 并行计算 网络计算机 一 软件危机2 软件危机 1 案例思考1 FAA的失败项目20世纪80年代中期 更换空中交通控制系统已成为美国联邦航空管理局 FAA 非常优先的任务 1989年IBM公司获得更换该系统的合同 截止期为2001年 预计投入25亿美元 由于面临着极苛刻的需求 该软件项目是已进行的最复杂的项目之一 例如 交通控制系统必须具备全局完整性并且每周7天 每天24小时不能停止工作 甚至在升级时或正常维护时 也不允许有停顿时间 任何错误的数据都会引起重大伤亡 任何停机均会导致世界范围的出行延误或潜在的危险 该系统的反应时间不能超过2 3秒 此外 该系统设计时必须考虑到允许私人飞机驾驶员继续使用旧设备 并要求软件能在未来移植到更新的硬件设备上 当IBM获得该合同后 该系统的主要花费为软件开发 用于硬件的投入仅为8万美元 1993年 负责该项目的IBM子公司 IBM联邦系统公司被IBM卖给了Loral公司 到1994年 该系统已花费了23亿美元 但尚未提交系统的任何程序段 而此时估算整个系统的花费将增至50亿美元 1994年底 FAA不得不承认该项目失败并进行调查 作为调查的结果 FAA取消或修改了系统的四个主要部分 面临当前空中控制系统存在的隐患 FAA不得不订购了一套作为权宜之计的系统 由另一家公司开发 你认为该项目的失败反映了什么问题 失败的主要原因可能是什么 FAA为什么选择取消和修改的方式而不是增加资源和生产力的方式 FAA对此项目调查总结出的原因为以下几条 FAA并没有明确掌握某些系统功能的需求 制定了过于急躁的开发和实现计划 包括费用与进度的估计 在给定的软件复杂度下 没有考虑到开发商的生产力 尤其是早期阶段需要投入的资源 在 人月神话 一书中 Brooks将过去30年大型软件项目的开发比喻为史前陷入沥青坑的巨兽 恐龙 猛犸 剑齿虎等动物在焦油中挣扎 然而挣扎得越激烈 就陷得越快 最终都沉到了坑底 过去的大型软件项目中 大多数开发出了可运行的系统 不过只有极少数满足了目标 进度和预算的要求 表面上看起来没有任何一个单独的问题会导致困难 每个问题都能获得解决 但这些问题纠缠和积累在一起时 团队的行动就越来越慢 并且很难再看清问题的本质 1995年美国的商业软件失败统计 一 软件危机2 软件危机 案例思考2 遗传信息库建设在正在建设的遗传信息库如 假设你要开发一个管理软件 你并不是一个生物遗传方面的专家 甚至对此方面的知识一窍不通 你该如何入手 要使该项目成功 你认为应该有哪些保障条件 你的问题是什么 对遗传信息的管理 需要什么条件 了解遗传信息的表示和管理流程 如何实现 与遗传领域的专家交流 障碍是什么 难以沟通与交流 可能因误解产生错误的需求描述 一 软件危机2 软件危机 软件项目为什么会失败 软件项目失败的核心问题在哪里 答案只有一个 复杂性 软件要解决的问题本身是复杂的 开发人员一般不是该问题领域的专家 软件规模要求多人参与 而不同专业领域的人的交流是困难的 软件规模使得既要理解系统整体结构又要把握细节比较困难 例 Windows95有1000万行代码Windows2000有5000万行代码Exchange2000和Windows2000开发人员结构 一 软件危机2 软件危机 2 软件神话 1 管理神话神话 有关软件开发的理论和方法已经很丰富 有很多可用的标准与规范 因而可以保证软件开发的顺利进行 现实 理论与方法在大多数实践中并没有得到真正的应用 使用者并没有对这些理论与方法建立正确的认识 神话 已经有很多强大的开发工具和先进的计算机硬件 这些可以保证软件开发的质量与效率 现实 这些工具并没有得到合理的应用 神话 如果我们落后于进度 可以通过增加人手来赶上 现实 向一个已经延迟的项目增加人手 只会使延迟的项目更加落后 除非项目中不需要交流 生一个孩子10个月 无论有多少人 一 软件危机2 软件危机 2 软件神话 1 管理神话神话 通过把软件项目外包给实现强大的软件开发公司可以保证软件的成功 现实 再专业的软件公司 不了解客户的需求和业务流程 也不可能顺利完成软件开发项目 改正一个问题需付出的代价 需求分析 结构设计 详细设计 编码 集成测试 系统测试 现场 改正一个问题的估计费用 改正一个问题估计的工作量 20 200 2000 1000 5 0 2 5 0 05 0 5 美元 人天 一 软件危机2 软件危机 2 软件神话 2 客户神话神话 有了目标系统的一般性描述就可以写程序了 细节可以逐步完善 现实 糟糕的系统定义是项目失败的主要原因 关于问题域 功能 行为 性能 接口 设计约束以及确认标准的形式化的 详细的描述是必要的 这些内容只能通过客户与开发者之间的交流才能确定 神话 软件需求是经常变更的 而这些变更可以容易的被满足 因为软件是灵活的 现实 软件需求确实是容易变更的 但变更的代价将随软件开发的进度不同而有很大的差异 如果重新项目早期的问题定义 需求变化则很容易被调节 而项目后期需求变更的代价可能是致命的 一 软件危机2 软件危机 2 软件神话 3 实践者的神话神话 软件是艺术 软件开发是个人的舞台 现实 50年代可能是 现在不是 神话 一旦写完了程序并能正常运行 我们的工作就结束了 现实 越早开始写代码 软件开发花费的时间就越长 统计表明60 到80 的工作量是花在将软件第一次交付给客户以后发生的 神话 程序真正运行以前 没有办法评估其质量 现实 高质量的实现来自高质量的设计 从项目一开始就必须进行技术评审 神话 项目的成功来自于可运行程序的提交 软件开发过程中的文档是不必要的 延缓项目进度的东西 现实 软件项目的成果包含很多内容 文档是成功开发的基础 也是软件质量的保证 好的开发质量降低了重复劳动 从而提高了效率 导致更短的交付时间 一 软件危机2 软件危机 3 软件危机及主要表现 软件危机指在计算机软件开发和维护过程中所遇到的一系列严重问题 软件开发不能满足日益增长的需求 难以维护不断增长的已有软件 1 成本与进度的估计 2 用户需求与产品不一致 3 软件可靠性差 4 可维护性差 5 文档资料不完整 6 软件成本比例不断上升 7 开发生产率相对停滞 一 软件危机2 软件危机 3 软件项目成败的因素分析 1 失败项目的主要原因 1 用户需求不完整 被误解或经常变化 2 有限的用户参与 3 缺少行政支持 4 缺少技术支持 5 项目计划不充分 6 目标不明确 7 没有足够的资源 客户没有提供 开发者不具备相应生产力 2 成功项目的主要原因 1 大量的用户参与 2 上层管理人员的支持 3 完整 详细的项目计划 4 符合实际的工作进度与里程碑 5 开发人员的培训 交流 6 良好的工作环境 团队协作机制 一 软件危机2 软件危机 3 消除软件危机的思路 1 正确的观念 a 软件不是程序软件是逻辑产品而不是实物产品软件的功能依赖于硬件和软件的运行环境以及人们对它的操作软件特征 功能的多样性实现的多样性能见度低软件结构合理性差智力密集及知识产权保护b 软件开发不是个体劳动软件设计的复杂性 一 软件危机2 软件危机 3 消除软件危机的思路 2 正确的过程管理与控制 软件开发技术 软件开发方法软件开发过程软件工具和软件工程环境软件工程管理 软件管理软件经济软件心理 二 软件工程1 软件工程将工程管理思想引入软件开发过程 转变对软件的认识 上升程序系统转变思维定式 上升程序员系统工程师 系统分析员 工程化训练 二 软件工程1 软件工程将工程管理思想引入软件开发过程 用户 分析员 程序员 一个好的工业 应有一套良好的标准来配套 软件的工业化生产过程应具备的特点 明确的工作步骤详细具体的规范化文档明确的质量评价标准 软件产品的标准化 软件开发过程的标准化 强调规范化强调文档化 软件工程技术的两个明显特点 二 软件工程1 软件工程FritzBauer在NATO会议上给出的定义 软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而确立和使用的健全的工程原理 方法 二 软件工程1 软件工程IEEE IEE83 给出的软件工程定义 软件工程是开发 运行 维护和修复软件的系统方法 二 软件工程1 软件工程IEEE IEE93 给出了一个更加综合的定义 将系统化的 规范的 可度量的方法应用于软件的开发 运行和维护的过程 即将工程化应用于软件中 二 软件工程1 软件工程软件工程是应用计算机科学 数学及管理科学等原理开发软件的工程 它借鉴传统工程的原则 方法 以提高质量 降低成本为目的 软件工程所包含的内容不是一成不变的 而是随着人们对软件系统的研制开发和生产的理解不断发展变化 应该用发展的眼光看待 二 软件工程1 软件工程 软件工程是一种层次化的活动 a 质量 软件工程的根基与目标b 过程 建造一个高质量软件所需完成任务的框架c 方法 提供了如何建造软件的技术手段d 工具 为过程和方法提供自动或半自动化的支持 CASE 工具 方法 过程 质量焦点 二 软件工程2 软件工程一般视图 工程 对技术 或社会 实体的分析 设计 构造 验证和管理 首先要问题的问题 要解决什么问题 实体的什么特征能解决这个问题 如何设计该实体 如何构建该实体 如何控制和避免构建过程中的错误 如何在用户要求修改 适应和增强时长期地支持这些实体 定义阶段 做什么开发阶段 如何做支持阶段 应对变化 项目跟踪与控制技术评审质量保证软件配置管理 文档管理复用管理测试管理风险管理 支持活动 软件工程框架 可 用 性 性 性 确 正 合 算 选取适宜的开发模型 采用合适的设计方法 提供高质量的工程支持 重视软件工程的管理 基本过程 原则 目标 过 程 支持过程 组织过程 软件过程评估 软件能力成熟度CMM1 初始级 没有过程定义 个人能力 2 可重复级 基本项目管理过程 跟踪费用与进度 有必要的规范以重复类似项目的成功 3 定义级 过程管理文档化 标准化 集成化 使用统一的文档化的组织过程认可的方法开发和维护软件 4 管理级 对软件过程与产品质量进行详细地定量地收集与评估5 优化级 通过定量反馈不断进行过程优化与改进 二 软件工程3 软件开发过程 软件生命周期软件产品或软件系统从设计 投入使用到被淘汰的全过程 软件生存期的阶段划分 1 可行性研究与计划 2 需求分析 3 总体设计 4 详细设计 5 实现 6 集成测试 7 确认测试 8 使用和维护 二 软件工程3 软件开发过程 软件开发模型软件开发模型是软件开发全部过程 活动和任务的结构框架 它能直观表达软件开发全过程 明确规定要完成的主要活动 任务和开发策略 软件开发模型也常称为 软件过程模型软件生存期模型软件工程范型 二 软件工程2 软件开发过程 瀑布模型 可行性研究与计划 需求分析 设计 编码 运行维护 测试 定义阶段 开发阶段 维护阶段 按照传统瀑布模型开发软件的特点 1 阶段间具有顺序性和依赖性 2 推迟实现的观点 3 每个阶段必须完成规定的文档 每个阶段结束前完成文档审查 及早改正错误 二 软件工程2 软件开发过程 原型模型 建造 修改原型 用户测试运行原型 听取用户意见 采用原型模型的软件生存周期 分析定义系统需求 生成原型 系统设计 程序设计 编码 测试 运行和维护 原型化 含原型化的软件生存期 二 软件工程2 软件开发过程 增量模型先完成一个系统子集的开发 再按同样的开发步骤增加功能 系统子集 如此递增下去直至满足全部系统需求 系统的总体设计在初始子集设计阶段就应作出设想 分析 增量模型 设计 编码 测试 分析 设计 编码 测试 分析 设计 编码 测试 分析 设计 编码 测试 增量1 增量2 增量3 增量n 增量1交付客户 增量2交付客户 增量3交付客户 增量n交付客