软件项目范围管理

1、第第2 2章章 软件项目范围管理软件项目范围管理 n2.1 软件项目范围管理的概述软件项目范围管理的概述n2.2 工作分解结构工作分解结构(WBS)(WBS)n2.3 项目范围控制项目范围控制n2.4 2.4 软件项目需求管理软件项目需求管理n2.5 2.5 软件项目计划管理软件项目计划管理2.1 2.1 软件项目范围管理的概述软件项目范围管理的概述2.1.1 软件项目的目标2.1.2 什么是项目范围管理2.1.3 项目范围规划2.1.4 项目范围定义 2.1.1 2.1.1 软件项目的目标软件项目的目标一、软件项目目标的概念一、软件项目目标的概念n 目标是预期的结果或最终的软件产品。n 项目

2、的目标必须是明确的、可行的、具体的和可度量的。n 软件项目目标具有多样性、层次性、可变性和优先性（各阶段目标优先性有差异）。二、确定软件项目目标的步骤二、确定软件项目目标的步骤主要分为两步：n 明确制定项目目标的主题。项目目标一般由项目发起人或者项目提议人来确定。n 描述项目目标。项目目标必须明确、具体，尽量定量描述，保证项目目标容易被沟通和理解，并使每个项目组成员结合项目目标确定个人的具体目标。三、目标确定目标应遵循的基本原则三、目标确定目标应遵循的基本原则n 定量化原则：确定项目目标时，尽可能定量描述，使得每个目标的范围、时间、成本、性能、责任等都是明确的，可以度量和监控的。n 个人化原则

3、：每个具体目标应当落实到项目组的每个成员，使得每个成员都明确自己的工作和职责。n 简单化原则：目标的描述应当是简单而直接的，使得每个参与人员都能明确而无二义性。n 现实性原则：确定的每个目标都是可以实现的，而不是追求理想化的结果。2.1.2 2.1.2 什么是项目范围管理什么是项目范围管理 做过项目的人可能都会有这样的经历：一个项目做了很久，感觉总是做不完，就像一个“无底洞”。用户总是有新的需求要项目开发方来做,就像用户在“漫天要价”，而开发方在“就地还钱”。实际上，这里涉及到一个“范围管理”的概念。项目中哪些该做，做到什么程度，哪些不该做，都是由“范围管理”来决定的。那么，到底什么是“范围管

4、理”。一一、项目范围管理的任务项目范围管理的任务n 项目范围的确定 (Project Scope)包括项目的最终产品或者服务，以及实现该产品或者服务所需要执行的全部工作。即：一是产品范围-软件二是项目范围-如文档等n 项目范围管理的任务是界定项目所必须包含且只需要包含的全部工作，并对其他的项目管理工作起指导作用，以确保项目顺利完成全部的过程。 二二、什么是、什么是项目范围管理项目范围管理n 对项目应包括什么和不应包括什么进行定义和控制，以确保项目管理者与干系人对作为项目结果的产品和服务以及完成产品和服务所经历的过程有一个共同的理解。三三、项目范围管理项目范围管理主要过程主要过程 项目管理知识体

5、系指南PMBOK（第3版）将项目范围管理的过程描述如下：n 启动（Initiation）-证实组织开始项目的下个阶段。n 范围计划编制（Scope Planning）-制定范围说明，作为未来项目决策的基础。n 范围定义（Scope Definition）-将主要的项目可交付成果分成小的、容易管理的部分。n 范围核实（Scope Verification）-正式接受项目范围。n 范围变更控制（Scope Change Control）-控制项目范围的变更。 2.1.3 2.1.3 范围计划编制n 项目范围计划就是确定项目范围并编写项目说明书的过程。项目范围的确定与管理影响到项目的整体成功。每个项

6、目都必须慎重考虑与权衡工具、数据来源、方法系、过程与程序，以及其他因素，确保为确定项目范围而付出的努力与项目的大小、复杂程度和重要性相称。一一、项目范围规划的项目范围规划的依据依据 项目和子项目都要编写项目范围说明书。一般来说，项目范围说明书要由项目班子来写，项目班子编写项目范围说明书时必须有以下的依据： 成果说明书成果说明书-产品描述 项目许可证项目许可证-项目章程 事业环境因素事业环境因素 组织过程资产组织过程资产 制约因素制约因素 假设前提假设前提-前提条件 二、项目范围规划的技术二、项目范围规划的技术（PP57） n 产品分析技术 n 成本效益分析技术 n 项目方案识别技术 n 专家评

7、定 三、项目范围规划的输出三、项目范围规划的输出n项目范围说明书 通过对项目范围规划后应当形成包括项目范围说明书在内的项目范围管理计划成果： 项目的合理性说明 项目成果的简要描述 项目可交付成果 项目目标的实现程度 辅助性细节 2.1.4 2.1.4 项目范围定义项目范围定义一一、项目范围定义的任务项目范围定义的任务n 范围定义就是把项目的主要可交付成果划分为较小的、更易管理的单元。n 项目范围的定义要以其组成的所有产品的范围定义为基础，这也是一个由一般到具体、层层深入的过程。 二二、项目范围定义的依据与工具项目范围定义的依据与工具n 范围说明书 n 制约因素 n 前提条件 n 其他计划结果

8、n 历史资料 使用工具：工作分解结构模板 三、项目范围定义的内容三、项目范围定义的内容 项目范围的定义是项目需求，主要从项目需求的识别和项目需求的表达两个方面来阐述。n 项目需求的识别 项目范围的定义来源于项目的需求，不能全面、正确地理解一个需求和其内在含义，或者不能正确地阐述表达它，项目管理必将迷失方向，就像那艘无舵的航船。把项目需求从开始的不确定，到逐步进化出一个清晰的框架，直至最终获得正确的理解，是项目管理一个至关重要的环节。三、项目范围定义的内容三、项目范围定义的内容项目需求的表达n 让提出需求的人把他们的感觉尽可能清楚地表达出来；n 针对需求的真实性、可行性、重要性和影响向客户提出问

9、 题，以从不同的角度理解需求；n 从技术和方法的角度对项目作一些必要的研究，更好地处理需求；n 根据以上三步得出的结论，尽可能清楚地描述项目需求；n 客户尽最大努力确认项目管理人员的需求认识是否反映了项目真实需求，根据客户意见作适当修改。2.2 2.2 工作分解结构工作分解结构(WBS)(WBS)n2.2.1 工作分解结构的含义与作用n2.2.2 工作分解的原则与步骤n2.2.3 WBS的设计方法n2.2.4 项目责任分配矩阵n2.2.5 实施项目工作分解应注意的问题 2.2.1 2.2.1 工作分解结构的含义与作用工作分解结构的含义与作用一一、工作分解结构的含义工作分解结构的含义 工作分解结

10、构是一个以产品或服务为中心的项目组成部分的“家族树”，规定了项目的全部范围，是项目范围定义的主体。 项目的工作分解以项目的范围说明书为直接前提、依据，在明确的项目范围基础上进行项目分解，确定实现项目目标所必须做的各项工作、确定各项工作的内在结构或实施过程的顺序并以一定的形式将其表达出来这就是工作分解结构图。二、工作分解的作用二、工作分解的作用n 进行工作分解之后，可以根据细分后的工作包之间的逻辑关系来实施项目。n 通过工作分解，项目组成员就会明确各自的职责，也有了可以共同遵守的明确规范，这样就可以减少繁琐的协调工作量，有利于工作的沟通。n 把项目细分为具体的工作任务后，每个项目组成员就能更清晰

11、地理解任务的性质和各自的具体目标。n 通过工作分解，可以比较准确地把握项目所需要的技术、人力、资金等信息，以及面临的风险，从而可以为项目计划的制定提供基线。 2.2.2 2.2.2 工作分解的原则与步骤工作分解的原则与步骤一一、工作分解的原则工作分解的原则n 在同一个工作任务中，最好只包含相关的工作元素。例如，对软件开发项目而言，“编码”和“测试”不应该在同一个工作任务中，因为在项目中，“编码”和“测试”的工作性质明显不同，也发生在不同的阶段。n 在同一个工作任务中，所有工作活动应该是平行的或者连续发生的，其间不应该插入不相关的工作活动。n 在同一个工作任务中，尽量使用相同的项目组成员，便于彼

12、此沟通和交流。二二、工作分解的步骤工作分解的步骤n 先明确并识别出项目的各主要组成部分，即明确项目的主要可交付成果。 n 确定每个可交付成果的详细程度是否已经达到了足以编制恰当的成本估算和历时估算的要求。 n 确定可交付成果的组成元素(工作包)。 n 核实分解的正确性。 2.2.3 WBS 2.2.3 WBS的设计方法的设计方法一一、WBS的设计方法的设计方法（分层分层）项目可交付的成果可交付的子成果最底层的可交付子成果工作任务图5.1 工作分解结构的层次产品或者服务包含的工作总和主要可交付的产品或者服务可交付的子产品或服务最底层的可交付子产品或服务可识别的工作活动一二三四五二、二、 WBSW

13、BS的的编制编制方法方法n 类比分解法 n 自上而下分解法 n 自下而上汇集法 案例：某项目工作分解结构图项目阶段1可交付成果2.1可交付成果2.2可交付成果2.3阶段2阶段3阶段n工作细目2.2.1工作细目2.2.2工作细目2.2.3子细目2.2.2.1子细目2.2.2.2子细目2.2.2.3 100 电力局信息化系统建设130 系统调试120 软件开发110 总体方案确定150 系统试用140 工程实施160 系统验收交付112 总体规划111 指导思想113 需求分析114 环境分析115 财务分析121 网络系统设计122 呼叫中心设计123 数据库设计124 ERP管理系统设计125

14、 CSS客服系统设计126 系统集成技术131 分系统测试132 系统集成测试142 基础数据输入141 硬件平台构建151 应用数据录入161 基础数据完善162 系统联合测试163 文件资料整理软件开发项目的软件开发项目的WBSWBS（列表法）（列表法）q1.1.项目启动阶段项目启动阶段n1.1 售前阶段n1.1.1 提供技术白皮书和现场的技术介绍，了解项目需求n1.1.2 提交项目可行性研究报告n1.1.2 提交项目开发计划n1.1.4 提交项目风险管理计划n1.1.5 通过公司的立项评审n1.1.6 进行项目前期开发（制作需求模板、功能演示系统、关键技 术分析和实验等）n1.1.7 向

15、用户提交系统建设建议书n1.2 招标和合同签订阶段n1.2.1 制作标书，参加投标和答标活动n1.2.2 中标后，根据商务谈判的结果，制作合同副本n1.2.3 合同签订n1.3 项目前期准备阶段n1.3.1 指定项目经理、子项目经理或技术经理，成立项目组。n1.3.2 完成工作任务分解（WBS）n1.3.3 划分接口人员责任n1.3.4 提交项目进度计划、项目成本预算、风险控制计划n1.3.5其他专项计划：对本项目开发中需制订的各个专题计划（如 分合同计划、开发人员培训计划、测试计划、安全保密计划、质量控制计划、配置管理计划、用户培训计划、系统安装计划等），分别进行制订。n1.3.6 以上项目

16、计划提交公司评审，并形成项目任务责任书并下达。q2 2 需求分析阶段需求分析阶段n2.1 分析用户需求n2.1.1 与用户一起分析需求并形成用自然语言表述的需求说明书，由用户确认n2.1.2 将用户确认的需求说明书，转化为用计算机术语描述的系统需求规范书n2.1.3 提交系统需求规范书，进行评审n2.2 形成集成测试计划，提交公司评审3.3.系统设计阶段系统设计阶段n3.1 系统总体设计n3.1.1 运行环境设计n3.1.2 基本业务处理流程描述n3.1.3 系统结构设计n3.1.4 模块关系设计n3.1.5 人工处理过程n3.1.6 尚未解决的问题n3.2 接口设计n用户接口、外部接口、内部

17、接口n3.3 运行设计n3.3.1运行模块组合：对系统施加不同的外界运行控制时所引起的各种不同运行模块组合、每种运行所历经的内部模块和支持软件。n3.3.2 运行控制:说明每一种外界的运行控制的方式方法和操作步骤n3.3.3运行时间:说明每种运行模块组合将占用各种资源的时间。n3.4 系统数据结构设计n3.4.1逻辑结构设计要点n3.4.2物理结构设计要点n3.4.3数据结构与程序的关系（后备、降效、恢复及再启动技术）WBSWISDOM软件开发需求分析总体设计A模块设计集成测试B模块设计S模块设计B概要设计B详细设计B编码B单元测试A概要设计A详细设计A编码A单元测试S概要设计S详细设计S编码

18、S单元测试测试计划方案拟定集成测试测试报告07/0107/1010天07/1107/3121天08/0108/2727天08/0109/0334天08/0109/1041天09/1110/2040天08/0108/0708/0808/1508/1608/2208/2308/2708/0108/0808/0908/1808/1908/2708/2809/0308/0108/1108/1208/2008/2108/3109/0109/1009/1109/1509/1609/2609/2710/1510/1510/20风险预留时间10/2111/10 20天详细讨论后的WBS图案例案例5 5：软件研

19、发项目时间管理计划：软件研发项目时间管理计划-WBS -WBS 2.2.4 2.2.4 项目责任分配矩阵项目责任分配矩阵（PP62） 2.2.5 2.2.5 实施项目工作分解应注意的问题实施项目工作分解应注意的问题n 确定项目的分解结构就是将项目的产品或服务、组织、过程 n 对于项目最底层的工作要非常具体 n 对于最底层的工作块，一般要有全面、详细和明确的文字说明并汇集编制成项目工作分解结构词典 n 并非工作分解结构中所有的分支都必须分解到同一水平，各分支中的组织原则可能会不同 2.3 2.3 项目范围控制项目范围控制n 2.3.1 范围审核n 2.3.2 范围变更控制2.3.1 2.3.1

20、范围审核范围审核n 验收的可交付成果n 请求的变更n 推荐的纠正措施2.3.2 范围变更控制一一、什么是、什么是范围变更控制范围变更控制n 在项目的生命周期中，存在着各种因素不断干扰着项目的进行，项目总是处于一个变化的环境之中。项目管理得再好，采用的管理方法再科学，项目也避免不了会发生变化，根据项目管理的哲学思想，这种变化是绝对的。对项目管理者来说，关键的问题是能够有效地预测可能发生的变化，以便采取预防措施，以实现项目的目标。n 项目范围变更控制是指为使项目向着有利于项目目标实现的方向发展而变动和调整某些方面因素而引起项目范围发生变化的过程。n 项目范围变更是不可避免的，通常对发生的变更，需要

21、识别是否在既定的项目范围之内。如果是在项目范围之内，那么就需要评估变更所造成的影响，以及如何应对的措施，受影响的各方都应该清楚明了自己所受的影响；如果变更是在项目范围之外，那么就需要商务人员与用户方进行谈判，看是否增加费用，还是放弃变更。因此，项目范围变更及控制不是孤立的。二二、项目范围变更管理的一般流程项目范围变更管理的一般流程 在收集到已完成活动的实际范围和项目变更带来的影响的有关数据，并据此更新项目范围后，对范围进行分析并与原范围计划进行比较，找出要采取纠正的地方。 对需要采取措施的地方确定应采取的具体措施。 估计所采取的纠正措施的效果，如果所采取的纠正措施仍无法获得满意的范围调整，则重

22、复以上步骤。识别需要变更的内容对变更因素进行分析提出变更申请进行变更通知相关部门/人员CCB审查确实需要变更不同意变更同意变更否是图 项目范围变更管理的一般流程三、范围变更控制实施的基础与三、范围变更控制实施的基础与技术技术n 进行工作任务分解 n 提供项目实施进展报告 n 提出变更要求 n 项目管理计划，项目管理计划应对变更控制提出明确要求和有关规定，以使变更控制做到有章可循n 范围变更控制系统 n 偏差分析n 补充规划n 配置管理系统四、项目范围变更控制的作用四、项目范围变更控制的作用n 合理调整项目范围 n 纠偏行动n 总结经验教训五、五、项目变更申请书（为了避免冲突而强调）项目变更申请

23、书（为了避免冲突而强调）优先级若不变更，那么若不变更，负责人批复意见申请人评估对其他工作包的影响及所需资源变更理由变更内容申 请 人申请日期需求变更内容的关键词归属WBS的编码负责人评估编号执行人结束时间负责人负责人签发日期2.4 2.4 软件项目需求管理软件项目需求管理2.4.1 软件需求的概念2.4.2 软件需求的类型2.4.3 软件需求度量2.4.4 软件需求工程2.4.5 软件需求管理的必要性2.4.6 软件需求管理的活动2.4.7 软件需求变更管理 2.4.1 2.4.1 软件需求的概念软件需求的概念一一、什么是软件需求、什么是软件需求 用户为解决某一问题或达到某一目标所需的软件属性

24、。 为了满足合同、规约、标准或其它正式文档要求所需的软件属性。什么是软件需求(1/4)n什么是软件需求？n待开发软件产品的目标用户对该软件产品的功能、性能、设计约束和其它方面的期望和要求n说明n目标用户n实际操作该软件的用户(图书管理员)n用户方的负责人n用户代表(市场经理)，n必须是用户所需的n例如，网上图书借阅(想法很好，用户不需要，也不现实)什么是软件需求(2/4)n关于软件需求的注意事项n软件需求关注用户的期望、要求和需要，不是解决方案n要区分what和Hown例如，要采用什么算法，不是用户需求n并不是所有方面的要求都是软件需求n功能、性能、设计约束、时间进度等n例如，重量、软件大小等

25、不是用户需求n并不是所有用户的期望和要求都是软件需求n用户需求必须中肯，有意义n例如，记录图书的厚度等不是用户需求什么是软件需求(3/4)n软件需求的表现形式n功能需求n性能需求n易用性、质量、性能、安全性，移植性、可重用性等n设计约束n运行环境n开发环境n其它要求：如开发周期什么是软件需求(4/4)n软件需求例子图书馆管理系统n功能需求n办理读者借书证, n借阅图书，n性能需求n查询操作延迟时间不超过1秒钟, n设计约束n前台运行在windows OS下，n其它要求n开发时间6个月, 二二、软件需求在软件项目中的作用、软件需求在软件项目中的作用 软件需求与其他软件过程的关系 2.4.2 2.

26、4.2 软件需求的类型软件需求的类型一一、软件需求、软件需求抽象层次抽象层次 所以软件需求类别有：用户需求 和系统需求 业务需求二二、系统需求的描述语言系统需求的描述语言 名称说明优点缺点结构化语言是对自然语言格式化，依赖于定义标准格式或模板来表达需求描述表现能力强易于理解一致性约束控制结构图形化显示仍然有一定程度的二义性；细致程度欠缺PDL伪代码 源于像Java或Ada这样的程序设计语言，包含附加的、更抽象的构造来提高其表达能力可通过软件工具进行语法和语义检查表达系统功能的能力不足使用的符号只有具有程序设计背景的人才能理解三三、系统需求的分类系统需求的分类 非功能需求产品需求可用性需求效率需

27、求性能需求空间需求可靠性需求可移植性需求机构需求交付需求实现需求标准需求外部需求互操作需求道德需求立法需求隐私需求安全性需求功能需求和非功能需求 2.4.3 2.4.3 软件需求度量软件需求度量n 正确性n 无歧义n 完备性n 一致性n 根据重要性和稳定性分级n 可验证性n 可修改性n 可跟踪性n 可理解性 2.4.4 2.4.4 软件需求工程软件需求工程一、需求工程研究内容一、需求工程研究内容 二二、需求开发和管理的界限需求开发和管理的界限 2.4.5 2.4.5 软件需求管理的必要性软件需求管理的必要性n 需求供求双方固有的矛盾n 需求具有易变性和难以表述性n 需求错误出现的高频性和修复的

28、高昂成本Capers Jones于1994年对软件缺陷的研究总结 缺陷来源潜在缺陷剩余缺陷排除效率（% %）需求0.20.04677设计0.250.037585编码0.350.017595建档0.120.02480修复0.080.02470合计10.14985.1软件缺陷修复的成本 2.4.6 2.4.6 软件需求管理的活动软件需求管理的活动需求管理活动活动的任务变更控制建议需求变更并分析其影响，做出是否变更的决策版本控制确定单个需求和SRS的版本需求跟踪定义对于其他需求及系统元素的联系链需求状态定义并跟踪需求的状态 2.4.7 2.4.7 软件需求变更管理软件需求变更管理 需求变更控制流程 需求变更管理过程 2.5 2.5 软件项目计划管理软件项目计划管理2.5.1 2.5.1 软件项目计划管