软件工程案例分析综述

《软件工程案例分析综述》由会员分享，可在线阅读，更多相关《软件工程案例分析综述（450页珍藏版）》请在金锄头文库上搜索。

1、软件工程案例分析 陈天洲 浙江大学计算机学院 软件特征（1） 最根本的：软件是一种逻辑元素而不是物理元 素 软件是开发出的，而不是用传统的方法制造出 来的 软件不会被用坏 时间 失败概率 一般产品的浴盆曲线 软件特征（2） 时间 失败 概率 软件失败概率 实际曲线 软件失败概 率理想曲线 软件特征（3） 工业界已经走向了标准化装配时代，然而 绝大多数软件还是定制出来的。 科学计算函数库（60年代） 重用数据结构 重用组件 成本结构发生了巨大的变化 一次性的制造成本 介质成本的可忽略性逻辑产品 不可回逆的投入 维护成本的增加 服务是质量要素中的重点 软件危机 “软件危机” 是1958年在NATO

2、会议上作 为一个正式的议题被提出来 软件项目不成功的例子比比即是： 1999 年 10 月，耗资 1.25 亿美元的 NASA 的火星气象卫星失踪（公英制转换） 软件危机 一些数据： 大约70的软件开发项目超出了估算的时 间，大型项目平均超出计划交付时间20到 50，90以上的软件项目开发费用超出预 算，并且项目越大，超出项目计划的程度越 高 美国政府审计局：只有不到2的合同定购 软件在发布时具有可用性98以上的项 目都失败了 软件危机 一种看法 “两难境地（Crunch Mode）”：处于两难境地的 项目面临无法达到最初目标的威胁（费用、进度表、 功能性等），而项目团队努力想跨越困境。 “我

3、们正处于两难境地，在半夜之前是不会回家” “死亡行军（Death March）”：用来描述其进度 表几乎不可能完成的项目。 “这是一个死亡行军项目，我希望自己不要参与进 去” 软件危机 更准确的说法：慢性痛苦（chronic affliction) Suggested by Prof. Daniel Tiechrow, University of Michigan 尽管忍受痛苦，但是软件依然在我们这个 世界起着越来越重要的作用，但是如果能 够医治痛苦，那么软件业将发展得更加健 康。 软件危机的主要特征 软件开发周期大大超过规定日期; 软件开发成本严重超标; 软件质量难于保证 软件成功的标准 s

4、用户在用 s用户可很容易做完要做的事 失败的根本原因： 开发人员写出的东西达不到 用户要求(人的问题.技术问题) 规模 复杂性 生产率 软件技术面临的问题 Exchange2000Windows2000 项目经理25人约250人 开发人员140人约1700人 测试人员350人约3200人 例:Windows95有1000万行代码 Windows2000有5000万行代码， 3000多个工程师，几百个小团队。 Exchange2000和 Windows2000开发人员结构 “软件工程案例分析”课程与其 它软件专业课的区别 (1) 立足于系统的整体。 (2) 系统分析、系统设计、 测试及维护的方法

5、实践。 (3) 构筑一个软件系统，实践 软件开发全过程。 用户分析员 程序员 系统分析员的地位 “一个好的工业，应有一套 良好的标准来配套” 软件工业化生产过程应具备的特 点 明确的工作步骤 详细具体的规范化文档 明确的质量评价标准 软件产品的标准化 软件开发过程的标准化 软件工程技术的两个明显特点 强调规范化 强调文档化 新世纪软件产业的趋势 网络化趋势：计算机与通信的融合趋 势 万维网智能网络 服务化趋势：“打包式”软件 “服务 式”软件 全球化趋势 中国软件产业发展主要问题 产业规模小、集中度低 产业竞争力弱，缺乏核心技术 市场秩序较为混乱，盗版严重 制约软件产业发展的因素 软件开发规范

6、与标准 知识产权环境 知识结构 公司体制 项目与项目管理 项目是什么 没有例行的任务 需要计划 特定的目标需要满足或者特定的产品需要生成 项目有一个预定义的时间范围 工作不仅仅是为自己，也是为他人 工作中有些特性 工作分为若干阶段 项目完成需要资源 项目是大型的或者复杂的 项目管理是什么 项目管理是在项目活动中应用知识，技能，工具和 技术来满足项目需求的过程，它通过初始化，计划，执 行，控制和结束等活动来完成。 软件项目与软件项目管理 软件项目的特征 不可见 复杂性（以每一单位货币来看） 灵活性：软件去适应人或组织而不是相反 一致性 软件项目管理 为了使软件项目能够按照预定的成本、进度、质 量

7、顺利完成，而对成本、人员、进度、质量、风险等 进行分析和管理的活动。 软件项目的活动 需求分析 描述 设计 编码 校验 安装 维护 支持 软件项目分类 按软件类别 信息系统：与组织接口 嵌入式系统：接口是机器 操作系统是一个信息系统还是嵌入式系统 ？ 有些项目是为了生成某一产品，而某些项 目的进行是为了达到某些目标。许多软件 项目分为两个阶段，第一阶段是目标驱动 ，第二阶段再生成真正的软件产品。 从系统的角度看软件项目 一个项目关注于生成一个系统和/或将一个旧系 统转换为一个新系统 系统，子系统和环境 开放和封闭系统 项目失败的一个原因是技术人员不能够开放系统 和立即接受外界的变化。 部分优化

8、 例如：可能很高效，但是难于修改 社会技术系统 软件项目属于此类 软件项目中的人员 项目影响者(stakeholders) 项目小组内部： 项目小组外部，但是在同一组织内： 项目小组和组织外部：如客户 不同的项目影响者有不同的目标，因而项 目领导者需要能够协调这些目标。Boehm 和Ross提出软件项目管理的“W理论”， 该理论关注于所有各方都能从项目种获益 因而对项目的成功都有兴趣。（W代表 Everyone a Winner） 软件开发面临的挑战 处理最终日期（deadlines）(85%) 处理资源约束（83） 与任务小组有效的沟通（80） 从小组成员处得到承诺（74） 建立可测量的mi

9、lestone（90） 处理变化（60） 得到团队公认的项目计划（57） 从管理层得到承诺（45） 处理冲突（42）管理销售商和子项目承包商 （38） 项目经理面临的挑战 估计和计划 缺少质量标准和度量 缺少组织决策的指南 缺少使进度可视化的技术 角色定义 不正确的成功准则 缺少标准 项目成员面临的挑战 工作的不正确的描述 IT的管理失误 缺少应用领域的知识 缺少及时的文档 前续任务没有及时完成包括设备没及时提供 用户与技术员之间缺乏交流 缺少质量控制 软件环境的改变 Deadline压力 软件项目常见错误 选自快速软件开发 产品相关的错误 需求镀金：项目具有比实际需求多得多的 性能 功能蔓延

10、：项目平均会有25%的需求变更（ Jones 1994） 开发人员的镀金：开发人员着迷于新技术 又推又拉的交易：经理在批准项目进度顺 延时又加入了新的功能 研究导向的开发 软件项目常见错误（续） 过程中的错误 缺乏计划 过于乐观的计划 在压力下放弃计划 缺乏足够的风险管理 承包人导致的失败 在模糊的项目前期浪 费时间 前期活动不合要求 过程中的错误 设计低劣 缺少质量保证措施 缺少管理控制 太早和过于频繁的集 成 项目估算时遗漏必要 的任务 追赶计划 鲁莽编码 软件项目常见错误（续） 技术相关的错误 银弹综合症: 过于相信以前没有采用过的 技术的宣传 过高估计了新技术或方法带来的节省量 项目中

11、间切换工具 缺少自动的源代码控制手段 软件项目常见错误（续） 人员相关的错误 挫伤积极性 人员素质低 对有问题的员工失控 英雄主义 项目后期加入人员：“火上加油” 办公环境差 开发人员与客户之间发生摩擦 不现实的预期 软件项目常见错误（续） 缺乏有效的高层对项目的支持 缺乏各种角色的齐心协力 缺乏用户介入 政治高于物质 充满想像：“项目组没人真正相信他们能够 按给定的计划进度完成项目，但他们认为如 果每个人能够努力工作，并且不出现问题， 他们可能会很幸运地按时完成任务。 软件项目常见的错误 试分析以下故事中的项目所存在的错误： 一天，一位年青人被选来“写”一个 用在自动化制造设备上的程序。选择

12、他的 理由很简单：他是技术小组中唯一参加过 编程培训的人。他懂得汇编语言和 Fortran语言，但是他不知道软件工程， 更不知道软件计划和跟踪方面的知识。 软件开发过程模型选择 主要内容 项目实施的方法选择问题 识别项目中的高风险 软件开发过程模型的选择 可选择的模型 软件开发项目过程的选择 软件开发方法 项目实施的方法选择 技术选择 技术选择将影响： 开发人员的训练需要 人员招聘 开发环境硬件和软件 系统维护安排 方法选择 方法选择将影响： 开发人员组合 实施的进度安排 开发策略选择 项目实施的方法选择 p 步骤： 分析目标驱动还是产品驱动 分析项目其他特征 面向数据还是面向控制 通用还是专

13、用 是否需要专用工具支持的专门技术 是否有特殊的安全性要求 对软硬件有何要求 识别项目中的高风险 产品不确定性：系统需求理解的准确性。用户 在开始时有可能对系统应该什么样都无法确定 。在某些环境中，精确而有效的需求描述可能 迅速变得过时。 过程不确定性：在项目开始时需要选择方法或 过程模型，或者一种新的工具，任何对原先采 用的开发方法的变化都将引入不确定性 资源不确定性：项目进行中资源的数量可能发 生变化 软件开发过程模型的选择 开发一个软件需要选择开发策略（包括过 程，方法和工具）以及通用阶段，这些策 略和阶段被称为过程模型 “过程”：相关联的活动 过程模型的选择基于项目和应用的特性， 使用

14、的工具和方法，所需要的控制方法和 交付物。 软件生存周期 (Software Life Cycle) 软件产品或软件系统从设计、投入使用到被淘汰的全过程 软件生存期的阶段划分 可行性研究与计划 需求分析 总体设计 详细设计 实现 集成测试 确认测试 使用和维护 软件生存周期 计算机软件开发规范 上游 下游 新的国际标准定义的软件生存过程 （1995 ISO/IEC 12207） 软件生存期过程 支持过程组织过程主要过程 获 取 过 程 供 应 过 程 开 发 过 程 运 行 过 程 维 护 过 程 文 档 编 制 过 程 配 置 管 理 过 程 质 量 保 证 过 程 验 证 过 程 确 认

15、过 程 联 合 评 审 过 程 审 核 过 程 问 题 解 决 过 程 管 理 过 程 基 础 设 施 过 程 改 进 过 程 培 训 过 程 只考虑 编写程序 涉及整个 软件生存 周期 扩展到 软件工作的范围 软件开发全部过程、活动和任务的结 构框架。 直观表达软件开发全过程 明确规定要完成的主要活动、任务和 开发策略 也称为： 软件过程模型 软件生存周期模型 软件工程范型 软件开发模型 问题求解的一般过程 问题求解的一般过程 实际问题并不能简单划为四个阶段，各 个阶段会在问题的不同层次上同时并存 软件开发实际上是一个“混沌”（chaos ）过程 问题定义 方案集成 技术开发现状 A.编码修正模型 Code and Fix Code like Hell(鲁莽编码) 从一个大致的想法开始工作，然后经过非 正规的设计、编码、调试和测试方法，最 后完成工作 可能有可能没有的规范 发布（可能） 编码修正模型 好处： 成本可能很低 只需要很少的专业知识，任何写过程序的 人都可以 对于一些非常小的、开发完后就会很快丢 弃的软件可以采用 对于规模稍大的项目，采用这种模型是很 危险的