软件工程案例分析
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
项目影响者(stakeholders) –项目小组内部： –项目小组外部，但是在同一组织内： –项目小组和组织外部：如客户 不同的项目影响者有不同的目标，因而项
目领导者需要能够协调这些目标。Boehm和 Ross提出软件项目管理的“W理论”，该理 论关注于所有各方都能从项目种获益因而 对项目的成功都有兴趣。（W代表 Everyone a Winner）
–美国政府审计局：只有不到2％的合同定购软 件在发布时具有可用性——98％以上的项目都 失败了
软件危机
一种看法
– “两难境地（Crunch Mode）”：处于两难境地的项目 面临无法达到最初目标的威胁（费用、进度表、功能
性等），而项目团队努力想跨越困境。
• “我们正处于两难境地，在半夜之前是不会回家”
软件开发面临的挑战
处理最终日期（deadlines）(85%) 处理资源约束（83％） 与任务小组有效的沟通（80％） 从小组成员处得到承诺（74％） 建立可测量的milestone（90％） 处理变化（60％） 得到团队公认的项目计划（57％） 从管理层得到承诺（45％） 处理冲突（ 42 ％）管理销售商和子项目承包商 （38％）
市场秩序较为混乱，盗版严重
制约软件产业发展的因素
软件开发规范与标准
知识产权环境 知识结构 公司体制
项目与项目管理
项目是什么 –没有例行的任务 –需要计划 –特定的目标需要满足或者特定的产品需要生成 –项目有一个预定义的时间范围 –工作不仅仅是为自己，也是为他人 –工作中有些特性 –工作分为若干阶段 –项目完成需要资源 –项目是大型的或者复杂的 项目管理是什么 – 项目管理是在项目活动中应用知识，技能，工具和技术 来满足项目需求的过程，它通过初始化，计划，执行， 控制和结束等活动来完成。
可能有可能没有的规范
发布（可能）
编码修正模型
好处： – 成本可能很低 – 只需要很少的专业知识，任何写过程序的人都 可以 – 对于一些非常小的、开发完后就会很快丢弃的 软件可以采用 对于规模稍大的项目，采用这种模型是很
危险的
B.瀑布模型（Waterfall Model)
所有过程模型的祖宗
软件项目常见错误（续）
– – – – – 缺乏有效的高层对项目的支持 缺乏各种角色的齐心协力 缺乏用户介入 政治高于物质 充满想像：“项目组没人真正相信他们能够按 给定的计划进度完成项目，但他们认为如果每 个人能够努力工作，并且不出现问题，他们可 能会很幸运地按时完成任务。
软件项目常见的错误
试分析以下故事中的项目所存在的错误：
过程中的错误 –缺乏计划 –过于乐观的计划 –在压力下放弃计划 –缺乏足够的风险管理 –承包人导致的失败 –在模糊的项目前期浪费 时间 –前期活动不合要求 过程中的错误 – 设计低劣 – 缺少质量保证措施 – 缺少管理控制 – 太早和过于频繁的集成 – 项目估算时遗漏必要的 任务 – 追赶计划 – 鲁莽编码
软件开发过程模型的选择
开发一个软件需要选择开发策略（包括过
程，方法和工具）以及通用阶段，这些策 略和阶段被称为过程模型 “过程”：相关联的活动 过程模型的选择基于项目和应用的特性， 使用的工具和方法，所需要的控制方法和 交付物。
软件生存周期
软件生存周期 (Software Life Cycle)
软件技术面临的问题
• 规模
• 复杂性 • 生产率
例:•Windows95有1000万行代码 •Windows2000有5000万行代码， 3000多个工程师，几百个小团队。
Exchange2000和 Windows2000开发人员结构 Exchange2000 项目经理 开发人员 测试人员 25人 140人 350人 Windows2000 约250人 约1700人 约3200人
– 软件产品或软件系统从设计、投入使用到被淘汰的全过程
软件生存期的阶段划分
–可行性研究与计划 –需求分析 –总体设计 –详细设计 –实现 –集成测试 –确认测试 –使用和维护
上游
下游
《计算机软件开发规范》
新的国际标准定义的软件生存过程 （1995 ISO/IEC 12207）
软件生存期过程 主要过程
软件项目不成功Baidu Nhomakorabea例子比比即是：
–1999 年 10 月，耗资 1.25 亿美元的 NASA 的火星气象卫星失踪（公英制转换）
软件危机
一些数据：
–大约70％的软件开发项目超出了估算的时间， 大型项目平均超出计划交付时间20％到50％， 90％以上的软件项目开发费用超出预算，并且 项目越大，超出项目计划的程度越高
一天，一位年青人被选来“写”一个用 在自动化制造设备上的程序。选择他的理 由很简单：他是技术小组中唯一参加过编 程培训的人。他懂得汇编语言和 Fortran语 言，但是他不知道软件工程，更不知道软 件计划和跟踪方面的知识。
软件开发过程模型选择
主要内容
项目实施的方法选择问题
识别项目中的高风险 软件开发过程模型的选择 – 可选择的模型 – 软件开发项目过程的选择 软件开发方法
软件项目常见错误（续）
技术相关的错误 –银弹综合症: 过于相信以前没有采用过的技术 的宣传 –过高估计了新技术或方法带来的节省量 –项目中间切换工具 –缺少自动的源代码控制手段
软件项目常见错误（续）
人员相关的错误 – 挫伤积极性 – 人员素质低 – 对有问题的员工失控 – 英雄主义 – 项目后期加入人员：“火上加油” – 办公环境差 – 开发人员与客户之间发生摩擦 – 不现实的预期
项目经理面临的挑战
估计和计划
缺少质量标准和度量 缺少组织决策的指南
缺少使进度可视化的技术
角色定义
不正确的成功准则
缺少标准
项目成员面临的挑战
工作的不正确的描述
IT的管理失误
缺少应用领域的知识 缺少及时的文档
前续任务没有及时完成——包括设备没及时提供
用户与技术员之间缺乏交流 缺少质量控制 软件环境的改变 Deadline压力
项目实施的方法选择
技术选择 – 技术选择将影响：
• • • • 开发人员的训练需要 人员招聘 开发环境——硬件和软件 系统维护安排
方法选择 – 方法选择将影响：
• 开发人员组合 • 实施的进度安排 • 开发策略选择
项目实施的方法选择
步骤：
• 分析目标驱动还是产品驱动 • 分析项目其他特征
– “死亡行军（Death March）”：用来描述其进度表几
乎不可能完成的项目。
• “这是一个死亡行军项目，我希望自己不要参与进去”
软件危机
更准确的说法：慢性痛苦（chronic affliction)
Suggested by Prof. Daniel Tiechrow, University of Michigan
绝大多数软件还是定制出来的。
–科学计算函数库（60年代） –重用数据结构 –重用组件
成本结构发生了巨大的变化
一次性的制造成本
介质成本的可忽略性－逻辑产品 不可回逆的投入
维护成本的增加
服务是质量要素中的重点
软件危机
―软件危机” 是1958年在NATO会议上作为一
个正式的议题被提出来
尽管忍受痛苦，但是软件依然在我们这个
世界起着越来越重要的作用，但是如果能 够医治痛苦，那么软件业将发展得更加健 康。
软件危机的主要特征
软件开发周期大大超过规定日期;
软件开发成本严重超标; 软件质量难于保证
软件成功的标准
用户在用 用户可很容易做完要做的事
失败的根本原因： 开发人员写出的东西达不到 用户要求(人的问题.技术问题)
获 取 过 程 供 应 过 程 开 发 过 程 运 行 过 程 维 护 过 程 文 档 编 制 过 程 配 置 管 理 过 程
支持过程
质 量 保 证 过 程 验 证 过 程 确 认 过 程 联 合 评 审 过 程 审 核 过 程 问 题 解 决 过 程
组织过程
管 理 过 程 基 础 设 施 过 程 改 进 过 程 培 训 过 程
软件项目与软件项目管理
软件项目的特征
– 不可见 – 复杂性（以每一单位货币来看） – 灵活性：软件去适应人或组织而不是相反
–一致性
软件项目管理 – 为了使软件项目能够按照预定的成本、进度、质量顺 利完成，而对成本、人员、进度、质量、风险等进行 分析和管理的活动。
软件项目的活动
需求分析
从系统的角度看软件项目
一个项目关注于生成一个系统和/或将一个旧系统
转换为一个新系统 系统，子系统和环境 开放和封闭系统
–项目失败的一个原因是技术人员不能够开放系统和立 即接受外界的变化。
部分优化 –例如：可能很高效，但是难于修改 社会技术系统 –软件项目属于此类
软件项目中的人员
描述
设计
编码
校验 安装 维护 支持
软件项目分类
按软件类别 –信息系统：与组织接口 –嵌入式系统：接口是机器 –操作系统是一个信息系统还是嵌入式系统？ 有些项目是为了生成某一产品，而某些项
目的进行是为了达到某些目标。许多软件 项目分为两个阶段，第一阶段是目标驱动， 第二阶段再生成真正的软件产品。
技术开发
方案集成
–实际问题并不能简单划为四个阶段，各个阶 段会在问题的不同层次上同时并存 –软件开发实际上是一个“混沌”（chaos）过 程
A.编码修正模型
Code and Fix
Code like Hell(鲁莽编码) 从一个大致的想法开始工作，然后经过非
正规的设计、编码、调试和测试方法，最 后完成工作
软件工作的范围
只考虑 编写程序
扩展到
涉及整个 软件生存 周期
软件开发模型
软件开发全部过程、活动和任务的结
构框架。 直观表达软件开发全过程 明确规定要完成的主要活动、任务和 开发策略 也称为：
–软件过程模型 –软件生存周期模型 –软件工程范型
问题求解的一般过程
问题定义
问题求解的一般过程 现状
“软件工程案例分析”课程与其它
软件专业课的区别
(1) 立足于系统的整体。 (2) 系统分析、系统设计、 测试及维护的方法实践。 (3) 构筑一个软件系统，实践 软件开发全过程。
系统分析员的地位
程序员
用户
分析员
“一个好的工业，应有一套 良好的标准来配套”
软件工业化生产过程应具备的特点 –明确的工作步骤 –详细具体的规范化文档 –明确的质量评价标准
软件产品的标准化
软件开发过程的标准化
软件工程技术的两个明显特点
•
强调规范化
• 强调文档化
新世纪软件产业的趋势
• 网络化趋势：计算机与通信的融合趋势
万维网智能网络
• 服务化趋势：“打包式”软件 “服务式”
软件
• 全球化趋势
中国软件产业发展主要问题
产业规模小、集中度低 产业竞争力弱，缺乏核心技术
软件工程案例分析
陈天洲 浙江大学计算机学院
软件特征（1）
最根本的：软件是一种逻辑元素而不是物理元素 软件是开发出的，而不是用传统的方法制造出来
的 软件不会被用坏
失败概率
一般产品的浴盆曲线
时间
软件特征（2）
失败 概率 软件失败概率 实际曲线
软件失败概 率理想曲线 时间
软件特征（3）
工业界已经走向了标准化装配时代，然而
软件项目常见错误
选自《快速软件开发》
产品相关的错误 –需求镀金：项目具有比实际需求多得多的性能 –功能蔓延：项目平均会有25%的需求变更 （Jones 1994） –开发人员的镀金：开发人员着迷于新技术 –又推又拉的交易：经理在批准项目进度顺延时 又加入了新的功能 –研究导向的开发
软件项目常见错误（续）
– – – – – 面向数据还是面向控制 通用还是专用 是否需要专用工具支持的专门技术 是否有特殊的安全性要求 对软硬件有何要求
识别项目中的高风险
产品不确定性：系统需求理解的准确性。用户在
开始时有可能对系统应该什么样都无法确定。在 某些环境中，精确而有效的需求描述可能迅速变 得过时。 过程不确定性：在项目开始时需要选择方法或过 程模型，或者一种新的工具，任何对原先采用的 开发方法的变化都将引入不确定性 资源不确定性：项目进行中资源的数量可能发生 变化
目领导者需要能够协调这些目标。Boehm和 Ross提出软件项目管理的“W理论”，该理 论关注于所有各方都能从项目种获益因而 对项目的成功都有兴趣。（W代表 Everyone a Winner）
–美国政府审计局：只有不到2％的合同定购软 件在发布时具有可用性——98％以上的项目都 失败了
软件危机
一种看法
– “两难境地（Crunch Mode）”：处于两难境地的项目 面临无法达到最初目标的威胁（费用、进度表、功能
性等），而项目团队努力想跨越困境。
• “我们正处于两难境地，在半夜之前是不会回家”
软件开发面临的挑战
处理最终日期（deadlines）(85%) 处理资源约束（83％） 与任务小组有效的沟通（80％） 从小组成员处得到承诺（74％） 建立可测量的milestone（90％） 处理变化（60％） 得到团队公认的项目计划（57％） 从管理层得到承诺（45％） 处理冲突（ 42 ％）管理销售商和子项目承包商 （38％）
市场秩序较为混乱，盗版严重
制约软件产业发展的因素
软件开发规范与标准
知识产权环境 知识结构 公司体制
项目与项目管理
项目是什么 –没有例行的任务 –需要计划 –特定的目标需要满足或者特定的产品需要生成 –项目有一个预定义的时间范围 –工作不仅仅是为自己，也是为他人 –工作中有些特性 –工作分为若干阶段 –项目完成需要资源 –项目是大型的或者复杂的 项目管理是什么 – 项目管理是在项目活动中应用知识，技能，工具和技术 来满足项目需求的过程，它通过初始化，计划，执行， 控制和结束等活动来完成。
可能有可能没有的规范
发布（可能）
编码修正模型
好处： – 成本可能很低 – 只需要很少的专业知识，任何写过程序的人都 可以 – 对于一些非常小的、开发完后就会很快丢弃的 软件可以采用 对于规模稍大的项目，采用这种模型是很
危险的
B.瀑布模型（Waterfall Model)
所有过程模型的祖宗
软件项目常见错误（续）
– – – – – 缺乏有效的高层对项目的支持 缺乏各种角色的齐心协力 缺乏用户介入 政治高于物质 充满想像：“项目组没人真正相信他们能够按 给定的计划进度完成项目，但他们认为如果每 个人能够努力工作，并且不出现问题，他们可 能会很幸运地按时完成任务。
软件项目常见的错误
试分析以下故事中的项目所存在的错误：
过程中的错误 –缺乏计划 –过于乐观的计划 –在压力下放弃计划 –缺乏足够的风险管理 –承包人导致的失败 –在模糊的项目前期浪费 时间 –前期活动不合要求 过程中的错误 – 设计低劣 – 缺少质量保证措施 – 缺少管理控制 – 太早和过于频繁的集成 – 项目估算时遗漏必要的 任务 – 追赶计划 – 鲁莽编码
软件开发过程模型的选择
开发一个软件需要选择开发策略（包括过
程，方法和工具）以及通用阶段，这些策 略和阶段被称为过程模型 “过程”：相关联的活动 过程模型的选择基于项目和应用的特性， 使用的工具和方法，所需要的控制方法和 交付物。
软件生存周期
软件生存周期 (Software Life Cycle)
软件技术面临的问题
• 规模
• 复杂性 • 生产率
例:•Windows95有1000万行代码 •Windows2000有5000万行代码， 3000多个工程师，几百个小团队。
Exchange2000和 Windows2000开发人员结构 Exchange2000 项目经理 开发人员 测试人员 25人 140人 350人 Windows2000 约250人 约1700人 约3200人
– 软件产品或软件系统从设计、投入使用到被淘汰的全过程
软件生存期的阶段划分
–可行性研究与计划 –需求分析 –总体设计 –详细设计 –实现 –集成测试 –确认测试 –使用和维护
上游
下游
《计算机软件开发规范》
新的国际标准定义的软件生存过程 （1995 ISO/IEC 12207）
软件生存期过程 主要过程
软件项目不成功Baidu Nhomakorabea例子比比即是：
–1999 年 10 月，耗资 1.25 亿美元的 NASA 的火星气象卫星失踪（公英制转换）
软件危机
一些数据：
–大约70％的软件开发项目超出了估算的时间， 大型项目平均超出计划交付时间20％到50％， 90％以上的软件项目开发费用超出预算，并且 项目越大，超出项目计划的程度越高
一天，一位年青人被选来“写”一个用 在自动化制造设备上的程序。选择他的理 由很简单：他是技术小组中唯一参加过编 程培训的人。他懂得汇编语言和 Fortran语 言，但是他不知道软件工程，更不知道软 件计划和跟踪方面的知识。
软件开发过程模型选择
主要内容
项目实施的方法选择问题
识别项目中的高风险 软件开发过程模型的选择 – 可选择的模型 – 软件开发项目过程的选择 软件开发方法
软件项目常见错误（续）
技术相关的错误 –银弹综合症: 过于相信以前没有采用过的技术 的宣传 –过高估计了新技术或方法带来的节省量 –项目中间切换工具 –缺少自动的源代码控制手段
软件项目常见错误（续）
人员相关的错误 – 挫伤积极性 – 人员素质低 – 对有问题的员工失控 – 英雄主义 – 项目后期加入人员：“火上加油” – 办公环境差 – 开发人员与客户之间发生摩擦 – 不现实的预期
项目经理面临的挑战
估计和计划
缺少质量标准和度量 缺少组织决策的指南
缺少使进度可视化的技术
角色定义
不正确的成功准则
缺少标准
项目成员面临的挑战
工作的不正确的描述
IT的管理失误
缺少应用领域的知识 缺少及时的文档
前续任务没有及时完成——包括设备没及时提供
用户与技术员之间缺乏交流 缺少质量控制 软件环境的改变 Deadline压力
项目实施的方法选择
技术选择 – 技术选择将影响：
• • • • 开发人员的训练需要 人员招聘 开发环境——硬件和软件 系统维护安排
方法选择 – 方法选择将影响：
• 开发人员组合 • 实施的进度安排 • 开发策略选择
项目实施的方法选择
步骤：
• 分析目标驱动还是产品驱动 • 分析项目其他特征
– “死亡行军（Death March）”：用来描述其进度表几
乎不可能完成的项目。
• “这是一个死亡行军项目，我希望自己不要参与进去”
软件危机
更准确的说法：慢性痛苦（chronic affliction)
Suggested by Prof. Daniel Tiechrow, University of Michigan
绝大多数软件还是定制出来的。
–科学计算函数库（60年代） –重用数据结构 –重用组件
成本结构发生了巨大的变化
一次性的制造成本
介质成本的可忽略性－逻辑产品 不可回逆的投入
维护成本的增加
服务是质量要素中的重点
软件危机
―软件危机” 是1958年在NATO会议上作为一
个正式的议题被提出来
尽管忍受痛苦，但是软件依然在我们这个
世界起着越来越重要的作用，但是如果能 够医治痛苦，那么软件业将发展得更加健 康。
软件危机的主要特征
软件开发周期大大超过规定日期;
软件开发成本严重超标; 软件质量难于保证
软件成功的标准
用户在用 用户可很容易做完要做的事
失败的根本原因： 开发人员写出的东西达不到 用户要求(人的问题.技术问题)
获 取 过 程 供 应 过 程 开 发 过 程 运 行 过 程 维 护 过 程 文 档 编 制 过 程 配 置 管 理 过 程
支持过程
质 量 保 证 过 程 验 证 过 程 确 认 过 程 联 合 评 审 过 程 审 核 过 程 问 题 解 决 过 程
组织过程
管 理 过 程 基 础 设 施 过 程 改 进 过 程 培 训 过 程
软件项目与软件项目管理
软件项目的特征
– 不可见 – 复杂性（以每一单位货币来看） – 灵活性：软件去适应人或组织而不是相反
–一致性
软件项目管理 – 为了使软件项目能够按照预定的成本、进度、质量顺 利完成，而对成本、人员、进度、质量、风险等进行 分析和管理的活动。
软件项目的活动
需求分析
从系统的角度看软件项目
一个项目关注于生成一个系统和/或将一个旧系统
转换为一个新系统 系统，子系统和环境 开放和封闭系统
–项目失败的一个原因是技术人员不能够开放系统和立 即接受外界的变化。
部分优化 –例如：可能很高效，但是难于修改 社会技术系统 –软件项目属于此类
软件项目中的人员
描述
设计
编码
校验 安装 维护 支持
软件项目分类
按软件类别 –信息系统：与组织接口 –嵌入式系统：接口是机器 –操作系统是一个信息系统还是嵌入式系统？ 有些项目是为了生成某一产品，而某些项
目的进行是为了达到某些目标。许多软件 项目分为两个阶段，第一阶段是目标驱动， 第二阶段再生成真正的软件产品。
技术开发
方案集成
–实际问题并不能简单划为四个阶段，各个阶 段会在问题的不同层次上同时并存 –软件开发实际上是一个“混沌”（chaos）过 程
A.编码修正模型
Code and Fix
Code like Hell(鲁莽编码) 从一个大致的想法开始工作，然后经过非
正规的设计、编码、调试和测试方法，最 后完成工作
软件工作的范围
只考虑 编写程序
扩展到
涉及整个 软件生存 周期
软件开发模型
软件开发全部过程、活动和任务的结
构框架。 直观表达软件开发全过程 明确规定要完成的主要活动、任务和 开发策略 也称为：
–软件过程模型 –软件生存周期模型 –软件工程范型
问题求解的一般过程
问题定义
问题求解的一般过程 现状
“软件工程案例分析”课程与其它
软件专业课的区别
(1) 立足于系统的整体。 (2) 系统分析、系统设计、 测试及维护的方法实践。 (3) 构筑一个软件系统，实践 软件开发全过程。
系统分析员的地位
程序员
用户
分析员
“一个好的工业，应有一套 良好的标准来配套”
软件工业化生产过程应具备的特点 –明确的工作步骤 –详细具体的规范化文档 –明确的质量评价标准
软件产品的标准化
软件开发过程的标准化
软件工程技术的两个明显特点
•
强调规范化
• 强调文档化
新世纪软件产业的趋势
• 网络化趋势：计算机与通信的融合趋势
万维网智能网络
• 服务化趋势：“打包式”软件 “服务式”
软件
• 全球化趋势
中国软件产业发展主要问题
产业规模小、集中度低 产业竞争力弱，缺乏核心技术
软件工程案例分析
陈天洲 浙江大学计算机学院
软件特征（1）
最根本的：软件是一种逻辑元素而不是物理元素 软件是开发出的，而不是用传统的方法制造出来
的 软件不会被用坏
失败概率
一般产品的浴盆曲线
时间
软件特征（2）
失败 概率 软件失败概率 实际曲线
软件失败概 率理想曲线 时间
软件特征（3）
工业界已经走向了标准化装配时代，然而
软件项目常见错误
选自《快速软件开发》
产品相关的错误 –需求镀金：项目具有比实际需求多得多的性能 –功能蔓延：项目平均会有25%的需求变更 （Jones 1994） –开发人员的镀金：开发人员着迷于新技术 –又推又拉的交易：经理在批准项目进度顺延时 又加入了新的功能 –研究导向的开发
软件项目常见错误（续）
– – – – – 面向数据还是面向控制 通用还是专用 是否需要专用工具支持的专门技术 是否有特殊的安全性要求 对软硬件有何要求
识别项目中的高风险
产品不确定性：系统需求理解的准确性。用户在
开始时有可能对系统应该什么样都无法确定。在 某些环境中，精确而有效的需求描述可能迅速变 得过时。 过程不确定性：在项目开始时需要选择方法或过 程模型，或者一种新的工具，任何对原先采用的 开发方法的变化都将引入不确定性 资源不确定性：项目进行中资源的数量可能发生 变化