核心三计划 范围计划 进度计划 成本计划 2017/4/7.

Presentation on theme: "核心三计划 范围计划 进度计划 成本计划 2017/4/7."— Presentation transcript:

0 范围计划 配置管 理计划 合同 计划 风险 沟通 质量 成本 时间 集成 范围 项目 结束 项目执 行控制 初始 人力 2017/4/7

1 核心三计划 范围计划 进度计划 成本计划 2017/4/7

2 第2章 软件项目范围计划 2017/4/7

3 项目管理是指对项目包括什么不包括什么的定义与控制过程
在项目管理中首先要定义项目的范围 项目范围是指开发产品包括的工作及产生这些产品所用的过程 2017/4/7

4 本章要点 一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的过程 五、案例分析 2017/4/7

5 软件需求 需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。 2017/4/7

6 软件需求的层次 业务需求反映了组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定，它们在项目视图和范围文档中予以说明。
用户需求描述用户通过使用本产品必须要完成的任务，一般是用户协助提供。用户需求可以在用例或场景说明中予以说明。 业务需求 用户需求 功能需求 软件需求规格 非功能性需求 质量特性 约束和假设 系统需求 功能需求定义开发人员必须实现的软件功能，使得用户通过使用此软件能完成他们的任务，从而满足业务需求。 2017/4/7

7 项目失败的原因分析 No. Top 10 Factors 平均值 1 Inadequate requirements specification 不充分的需求规范 4.5 2 Changes in requirements 需求的改变 4.3 3 Shortage of systems engineers 缺乏系统工程师 4.2 4 Shortage of software managers 缺乏了解软件特性的经理人 4.1 5 Shortage of qualified project managers 缺乏合格的 项目经理 6 Shortage of software engineers 缺乏软件工程师 3.9 7 Fixed - price contract 固定价合同 3.8 8 Inadequate communications for system integration 系统集成阶段 , 交流与沟通不充分 9 Insufficient experience as team 团队缺乏经验 3.6 10 Shortage of application domain experts 缺乏应用领域专家 Scale: 5 = Very Serious = Serious = No Serious Source: Carnegie-Mellon University, Software Engineering Institute 2017/4/7

8 软件需求管理的过程 是保证软件需求以一种形式描述一个产品应该具有的功能、性能等。
软件需求管理的过程 是保证软件需求以一种形式描述一个产品应该具有的功能、性能等。 软件需求工程的管理分为 需求开发和需求管理 2017/4/7

9 需求工程基本任务 需求获取 需求验证 需求工程 需求管理 需求开发 需求分析 需求规格说明 变更管理 2017/4/7

10 需求获取 用户要求 扩展需求 基线需求 软件需求 2017/4/7

11 需求分析定义 需求分析是开发人员对系统需要做什么的定义，也是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 2017/4/7

12 需求分析模型 2017/4/7

13 需求规格 需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书
需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。 2017/4/7

14 软件需求规格说明的原则 从现实中分离功能，即描述要“做什么”而不是“怎样实现” 采用一定的规格说明语言
如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中 规格说明应该包括系统运行环境 规格说明应该是一个认识模型 规格说明应该容许不完备性并允许扩充 2017/4/7

15 规格文档参考 引言 系统定义 应用环境 功能规格 性能需求 产品提交 实现约束 质量描述 其它 签字认证 2017/4/7

16 需求验证 需求是正确的吗？ 需求是一致的吗？ 需求是完全的吗？ 需求是实际可行的吗？ 需求是必要的吗？ 需求是可检验的吗？
需求是可跟踪的吗？ 最后的签字 2017/4/7

17 需求总在变化 2017/4/7

18 2017/4/7

19 需求变更管理 确定需求变更控制过程 建立变更控制委员会(SCCB) 进行需求变更影响分析 跟踪所有受需求变更影响的工作产品
建立需求基准版本和需求控制版本文档 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性 2017/4/7

20 变更申请 需求方 开发方 忽略 选择变更方式 SCCB评估 项目经理自行决定 根据评估结果 拒绝 接受本次修改 下个版本再修改
修改合同相关信息 修改相关需求 修改相应的项目计划 2017/4/7

21 RCR-PM-01.doc, RCR-PM-02.doc, 变更简述如下
软件基线产品修改提交单 申请人 韩万江 申请日期 2002。10．11 项目名称 项目管理系统 阶段名称 系统设计 文件名称 RCR-PM-01.doc, RCR-PM-02.doc, 变更简述如下 修改内容 1）修改测试流程控制：将2个角色，3个渠道流，改为3个角色，4个渠道流，详见RCR-PM-01.doc 2）增加开发人员技能信息库管理，详见RCR-PM-02.doc 验证意见 同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推迟到下一个版本实施 验证人 杨炎泰 验证日期 2002．10．11 SCCB 韩万江，姜岳尊，孙泉 填表人 表4-3 需求变更提交单 2017/4/7

22 本章要点 一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的方法 五、案例分析 2017/4/7

23 WBS (Work Breakdown Structure)
任务分解的过程 将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。 任务分解的结果 WBS（任务分解结构）。 WBS 面向可交付成果的。 Work packages（工作包） WBS的最低层次的可交付成果 2017/4/7

24 WBS实例 系 统 子 系 统 模块 2017/4/7

25 本章要点 一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的方法 五、案例分析 2017/4/7

26 类型 清单 图表 2017/4/7

27 清单类型 1. 变化计数器 1.1 比较两个版本的程序 1.2 找出修改后的程序中增加和删除的代码行
 1.         变化计数器 1.1          比较两个版本的程序 1.1.1     预处理 1.1.2     文件比较 1.1.3     结果处理 1.2          找出修改后的程序中增加和删除的代码行 1.2.1     找出增加的代码行 1.2.2     找出删除的代码行 1.3          统计修改后的程序中增加和删除的代码行数 1.3.1     统计增加代码行数 1.3.2     统计删除代码行数 1.4          统计总的代码行数 1.5          设定标记以指示修改的次数 1.6          在程序的头部增加修改纪录 2017/4/7

28 图表类型 “变化计数器”系统 文件比较 预处理 增加 代码 结果处理 统计总行 标记修改 记录 修改 版本 比较 找出 增删行 统计
删除代码 行数 删除 2017/4/7

29 本章要点 一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的方法 五、案例分析 2017/4/7

30 任务分解过程 输入 分解 WBS 2017/4/7

31 分解方法 模版参照 类比方法 自上而下 自下而上 2017/4/7

32 WBS模板举例 2017/4/7

33 选择一些类似的项目作为参考进行开发ＷＢＳ
类比方法　 选择一些类似的项目作为参考进行开发ＷＢＳ　 2017/4/7

34 分解方法-自上而下 预处理 文件比较 增加 代码 结果处理 统计总行 标记修改 记录 修改 删除代码 行数 删除 版本 比较 找出 增删行
“变化计数器”系统 文件比较 预处理 增加 代码 结果处理 统计总行 标记修改 记录 修改 版本 比较 找出 增删行 统计 删除代码 行数 删除 2017/4/7

35 分解方法-自下而上 预处理 文件比较 增加 代码 结果处理 统计总行 标记修改 记录 修改 删除代码 行数 删除 版本 比较 找出 增删行
“变化计数器”系统 文件比较 预处理 增加 代码 结果处理 统计总行 标记修改 记录 修改 版本 比较 找出 增删行 统计 删除代码 行数 删除 2017/4/7

36 任务结构分解(WBS)步骤 确认并分解项目的组成要素 确定分解标准 确定分解是否详细 确定项目交付成果 验证分解的正确性(建立编号)
2017/4/7

37 WBS编号系统 功能1:11 软件产品:1 功能2:12 功能3:13 功能2-子功能2:122 功能2-子功能1:121
功能2-子功能3:123 2017/4/7

38 标识项 功能名 F1.1 获取网络资源数据 F1.2 将资源数据存入数据库 F1.3 获取网络资源信息 F1.4 观察网络资源 F1.4.1 依类型分类观察网络资源 F1.4.2 依状态分类观察网络资源 F1.5 观察逻辑网 F1.6 观察资源状态 F1.7 修改网络资源的状态 F1.8 依条件检验网络使用情况 F1.9 显示拓扑图 F1.10 建立通道 2017/4/7

39 WBS与OBS（组织分解结构） 2017/4/7

40 分解标准 生存期 功能组成 2017/4/7

41 分解标准应统一 学生管理 按照生存期分解 按照产品组成分解 规划 需求 设计 编码 测试 提交 1.1 招生管理 1.2 分班管理
1.1        招生管理 1.2         分班管理 1.3         学生档案管理 1.4         学生成绩管理 2017/4/7

42 分解标准应统一（续） 不能同时使用两种标准进行分解 招生管理 分班管理 学生档案管理 学生成绩管理 规划 需求 设计 编码 测试 提交
 分班管理  学生档案管理 学生成绩管理 规划 需求 设计 编码 测试 提交 2017/4/7

43 检验分解结果的标准 最底层的要素是否是实现目标的充分必要条件 最底层要素是否有重复的 每个要素是否清晰完整定义
最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排 2017/4/7

44 WBS的指南(1) WBS分解的规模和数量因项目而异、因项目经理而异 收集与项目相关的所有信息 参看一下类似的项目的WBS,与相关人员讨论
可以参照模板 最低层是可控的和可管理的，但是避免不必要的过细，最好不要超过7层， 软件项目推荐分解到40小时的任务 注：80/8规则 2017/4/7

45 WBS的指南（2） 每个Work package必须有一个提交物 定义任务完成的标准 每个WBS必须有利于责任分配 可以准备WBS的字典
最后与相关人员进行评审 2017/4/7

46 WBS字典内容 WBS表示号 名称 主题目标 描述 完成的任务 责任者 完成的标识 备注 1.           2017/4/7

47 WBS意义 提供了项目范围基线,是范围变更的重要输入 为评估和分配任务提供具体的工作包 进行估算和编制项目进度的基础
对整个项目成功的集成和控制起到非常重要的作用 2017/4/7

48 清单式任务分解实例 1.0建办公楼 1.1基础 1.1.1挖沟 1.1.2混凝土 1.1.3回填 1.2墙 1.2.1砌砖 1.2.2装窗
1.2.3装门 1.2.4抹灰 1.3屋顶 1.3.1安梁 1.3.2装懔 1.3.3上瓦 1.4照明 1.4.1配线 1.4.2装照明灯 1.4.3配电盘 2017/4/7

49 网管系统（图表）分解实例 F F1 配置管理 F2 故障管理 F3 安全管理 F4 性能管理 F3.2 F3.3 F3.1 F3.4
2017/4/7

50 网管系统（图表）分解实例 F1 F1.1 F1.2 F1.3 F1.4 F1.5 F1.6 F1.7 F1.8 F1.9 F1.10
2017/4/7

51 网管系统（图表）分解实例 F2 F2.1 F2.2 F2.3 F2.4 F2.5 F2.6 F2.7 F2.8 F2.9 F2.6.1
2017/4/7

52 标识项 功能名 F1.1 获取网络资源数据 F1.2 将资源数据存入数据库 F1.3 获取网络资源信息 F1.4 观察网络资源 F1.4.1 依类型分类观察网络资源 F1.4.2 依状态分类观察网络资源 F1.5 观察逻辑网 F1.6 观察资源状态 F1.7 修改网络资源的状态 F1.8 依条件检验网络使用情况 F1.9 显示拓扑图 F1.10 建立通道 2017/4/7

53 WBS实例 George and Martha’s picnic 2017/4/7

54 George and Martha一次野餐会
George and Martha计划与家人和朋友举行一次特殊的野餐活动,以庆祝Martha的升职和他们35周年的结婚纪念. Martha是工程师, George是会计.他们有两个非常活泼的确孩子,Mary 13岁,Thomas 17岁.经过过去几年的发展,家里不断壮大,无论是时间和金钱上的需要都在增加,所以他们已经逐渐成为非常好的计划能手,最近他们又通过了PMP的认证考试,所以他们非常清楚对于这样野餐活动也需要开发一个WBS. 2017/4/7

55 野餐准备活动任务分解 序号 任务 持续时间 工作人员 1 开始 2 做冰茶 15 George 3 准备三明治 10 Martha 4
2 做冰茶 15 George 3 准备三明治 10 Martha 4 准备水果 5 准备篮子 6 收拾毛毯 7 收拾运动服 8 装车 9 加油 开车去野餐营地 20 11 结束 2017/4/7

56 本章要点 一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的方法 五、案例分析 2017/4/7

57 案例分析 “校务通系统”项目任务分解 需求确认 需求变更控制 WBS结果 2017/4/7

58 校务通WBS F 校务通管理平台信息系统 F1 通用功能 F2 日常业务管理功能 F1.1 电子课表 F1.2 会议通知和公告 F1.3
个人日记 F1.4 通讯录 F1.5 教师答疑 F1.6作业布置和批改 F2.1 招生管理 F2.2 学生日常管理 F2.3 教务管理 F2.4教师 备课系统 F2.5 资源库系统 F2.3.1 教师 日常管理 F2.3.2 年级 班级设置 F2.3.3 学科设置 F2.3.4 课程设计 F2.3.5 排课表 F2.2.1 学生档案管理 F2.2.2 学生考勤管理 F2.2.3 学生奖惩 F2.2.4 学生变动 2017/4/7

59 小结 WBS的分解类型 WBS的分解步骤 范围基准的形成 2017/4/7

60 课堂练习 1.需求分析是回答系统必须（ ）的问题 A. 做什么 B. 怎么做 C. 何时做 D. 为谁做
2. WBS（工作分解结构）非常重要，因为下列原因，除了（　） A. 帮助组织工作 B. 防止遗漏工作 C. 为项目估算提供依据 D. 确定团队成员责任 3. 项目范围（　 ） A. 只在项目开始时重要 B. 在授权项目的合同或者其他文件得以批准后就不再重要了 C. 从项目概念阶段到收尾阶段都应该加以管理和控制 D. 是在项目执行阶段通过变更控制步骤进行处理的问题 2017/4/7

61 课堂练习 4. 为了有效地管理项目，应该将工作分解为更小的部分，以下各项中，哪一项不能说明任务应该分解到什么程度？（　　 ） A. 可以在80小时内完成 B. 不能再进一步进行逻辑细分了 C. 可由一个人完成 D. 可以进行实际估算 5. 范围变更是指（　　） A. 修改技术规格 B. 对范围陈述进行修订 C. 对批准后的WBS进行修改 D. 以上都不是 6. 下面哪个不是需求管理的过程（　　） A. 需求设计 B. 需求获取 C. 需求分析 D. 需求变更 2017/4/7

62 课堂练习 7. 下面那个不是创建WBS的方法（　　） A. 自顶向下 B. 自底向上 C. 控制方法 D. 模版指导 8. 任务分解可以(　　　)，它是范围变更的一项重要输入 A. 提供项目成本估算结果 B. 提供项目范围基线 C. 规定项目采用的过程 D. 提供项目的关键路径 9. 范围基线由（　　）组成 A. 项目章程、批准的详细的项目范围说明书和WBS B. 批准的详细项目范围说明书、WBS和WBS字典 C. 项目章程、项目工作说明书和WBS D. WBS 2017/4/7

63 课堂练习 二、判断题 1. 需求分析过程是确定项目如何实现的过程，并确定项目的技术方案（ ）
1. 需求分析过程是确定项目如何实现的过程，并确定项目的技术方案（ ） 2. 对于一个重来没有做过的项目，开发WBS时，可以采用用自底向上的方法（ ） 2017/4/7