SXU-软件项目管理-朱少民-第九章 项目监控与控制 第十章 项目收尾 附相关习题

admin管理员组

文章数量:1530020

考点：

38、进度可视化监控方法；
39、优先级控制、变更控制、合同履行控制；
40、验收需要做什么。

第九章 项目监控与控制

9.1 项目过程度量

1、软件项目的监督和控制工作须以一定基准来进行校对、核实。这些基准就被称为软件的度量。

2、软件过程度量：收集、分析和解释关于过程的定量信息，是软件过程评估和改进的基础。

3、只在一组基线度量建立后，才能评估过程及其产品改进的成效。

9.1.1 内容

1、软件过程度量贯穿整个软件生命周期，包括需求度量、设计度量、编程和测试度量、维护量

2、涵盖软件过程能力和软件过程性能两大方面，涉及控制过程、支持过程、管理过程、组织过程和服务过程。

3、软件过程能力度量：CMM/CMMI是对软件过程能力最好的诠释，软件过程能力通过CMM的18个关键过程域或24个过程域体现出来。

注意：对敏捷成熟度模型惠普提出从协作，自动化，流程三个方面的成熟度划分五个等级。

4、软件过程性能的度量分4部分：过程质量度量、过程效率度量、过程成本度量、过程稳定性度量

5、过程效率度量和质量度量的有机结合，获得过程性能的最优平衡。

1）衡量过程效率和工作量—工作量指标：软件过程生产率度量、测试效率评价、测试进度S曲线

2）从质量的角度表明测试的结果—结果指标：累计缺陷数量、峰值到达时间、缺陷平均增长速率

3）实际测试过程度量中定义了测试效率和缺陷数量的矩阵模型：将过程度量值和测试结果的缺陷度量一起研究

情形1：最好 软件有好的内在质量，错误量低，通过有效测试验证。
情形2：较好 潜伏较多的缺陷通过有效的测试被发现
情形3：不确定 低缺陷原因模糊
情形4：最坏 代码问题多，测试效率低，难及时发现

如果测试效率没有显著恶化，低缺陷率是一个好的征兆。

9.1.2 流程

1、软件过程度量：收集、分析、解释数据，对整个软件项目进行监督、控制、改进的过程。

粗箭头：流程主要流动方向（从确认过程问题→实施过程行动的全过程）

细实头：和过程强关联；

虚线：弱关联，相互参考。

需要按照已明确定义的度量流程实施使软件过程度量获得充足的数据（可控制性和可跟踪性，保证过程度量的准确性和有效性）

2、为说度量过程，以项目目标驱动的度量活动为例，度量过程被定义为5个阶段：识别目标和度量描述，定义度量过程，搜集数据，数据分析与反馈，过程改进。

9.1.3 方法

1、为项目过程度量的有效实施，先建立软件项目过程基线，后将获得的实际测量值与基线进行比

2、平均值反映组织的整体水平或程度，分布情况反映了组织的过程能力和执行的稳定性。

3、指定基限：上限和下限；平均期望值：均值(AV)

4、用σ来表示标准偏差 表示数据的分散程度，可度量待测量对象在总体上相对目标值偏离程度。Xi 为样本观测值；Xv为样本平均值；n为样本容量。

5、正态分布均值±1σ 只68.26%的覆盖程度，均值+2σ、+3σ 则可界定正态分布曲线中95.44%、99.73%的覆盖程度。6σ 说明样本观测值很集中，过程能力很强被用来表示高质量的生产水平。

6、S曲线模型用于度量项目测试进度

进度的跟踪是通过对计划中的进度、尝试的进度与实际的进度三者对比来实现的。数据用当前累计的测试用例或测试点的数量。

由于测试过程3个阶段中前后2个阶段(初始阶段和成熟阶段)所执行的测试数量(强度)远小于中间的阶段(紧张阶段)，即累计数据关于时间的曲线形状很像一个S形。

9.1.4 规则

过程度量使一个组织能从战略级洞悉一个软件过程的功效，使得管理者能够以实时的式改进项目的工作流程及技术方法。遵循一定规则并合理利用才能收到好的成效，结合其他度量规则总结如下:

1、度量参数时应尽可能考虑组织的受用性和通用性。

2、度量的目标是改进软件开发过程提高质量和效率，不要用度量片面地评价个人。

3、避免度量指标太多或者太少如只设定了唯一的度量指标。

4、利用专门的系统或者用专人进行统计度量工作，以确保数据的一致性和准确性。

5、为收集数据和制定度量标准的个人及小组提供定期的反馈。

6、对于新的度量参数要增加试运行环节保证正式应用时确保度量参数的合理性。

7、在度量方面要遵循灵活性原则。

8、不定期地进行度量数据的分析和预测。

9.2 数据收集

对项目进行监督和控制的有效性取决于进度数据收集得是否真实可靠,是否完善

9.2.1 数据收集方式

数据收集的主要方式有两种：被动接收和主动收集

1、被动接收
1）被动接收是指项目成员按规定/要求发出项目的相关数据信息，由项目经理或者项目组长进行整理和分析。如日报、周报、月报。项目成员在每天每周每月对自己的相关项目自我总结发给项目经理及项目组主要成员。

2）报告内容包括：任务状态，任务完成情况，已经解决的问题及其解决方法，需要解决的问题，潜在的风险，人员的工作分配情况，共用的开发和测试环境信息，相关的缺陷报告代码审查等一些可供参考的信息。

2、主动收集

被动地收集信息是不足够的有些问题可能会被隐藏，需主动收集信息随时掌握项目状况，对项目的监控有帮助。项目组长/负责人/经理应该通过各种手段主动地进行数据的收集。

1）即时地和项目成员进行沟通，掌握项目情况

2）建立例会制度，定期主动收集和掌握各方信息。

3）查看跟踪系统中记录的相关信息。

4）不定期召开项目研讨会根据项目进展情况召集相关人员进行讨论。

注意：想得到足够的、完整的数据信息，必须要主动＋被动并定期对收集的数据整理存档

9.2.2 数据质量

要在数据采集过程中，确保数据的质量注意以下几点：

数据的真实性、及时性、有效性；

9.3 可视化管理

可视化管理使管理任务“化繁为简”，监控起来“一目了然”

9.3.1 全程可视化

1、项目前期调查时期

没有最终确定是否要做故关注的是可行性分析的结果，对于技术上无把握和复杂用户界面，最好用原型设计法。通过可行性原型或者一些模拟技术实现可视化。

2、项目启动时期

确定组织结构是可视化的首要任务。下面是某软件项目组织结构图和某软件项目敏捷 Scrum 模型的组织结构图。

3、项目计划时期

工作任务分解及任务间相互关系的可视化很必要。尤其活动之间相互的依赖关系，表格/图形有助于提高项目计划的可视性，如 WBS图表就是经常使用的可视化的计划图表。

人员的职责可视化：角色责任矩阵

A(Accountability)责任，对项目成败负责和进行协调管理。
P(Participate)参与，参与项目的具体任务。
C(Consulted)咨询，提供意见，帮助决策。
I(Infomed)通报，知晓进度。

4、项目执行时期

最重要的信息：项目进度如何，计划完成多少工作，实际完成了多工作，项目是否可以按计划保质保量地完成。

项目经理在项目执行的过程中：1）会不断收集项目的进度、质量、风险、资源。2）根据不同的情况选择适合的可视化方法呈现项目进展信息。
展示进度信息（甘特图、时间线）

展示代码质量（码审查结果、缺陷分析图表）

展示缺陷的可视化信息（缺陷日增长率分析图，缺陷仪表板）

展示风险可视化（项目初期就建立十大风险清单要动态的维护）

针对资源信息的可视化，可以利用资源利用率分析图表

5、项目收尾总结时期

对上面的信息分析完后用表格、图形、Powenpoint 文件等可视化形式呈现总结。

6、项目后期维护时期

针对维护过程遇到的问题进行汇总和分析将汇总的数据转换成图形或表格之类的可视化结果。

进度问题是项目冲突的主要原因，尤其在项目后期。

9.3.2 进度可视化监控方法

考点 进度可视化监控方法：甘特图、延迟图、时间线、计划与实际对比图、燃尽图（其他方法：预警提示、代码审查可视化分析、缺陷分析、即时战报）。

1、甘特图：不仅制定进度计划的工具，也是进度监控可视化的好帮手。

2、延迟图：由甘特图演变而来，注重强调每个活动的相对进度情况。对于未按计划完成进度的活动，提供了更加醒目的可视化显示。

3、时间线：想简单、清楚地展示项目整体进度(客户和有些利益相关人只关心项目整体进展)

4、计划与实际对比图：软件项目的监督和控制过程中，会将收集到的项目实际进展信息与进度基准计划做比较，判断项目是否偏离正常的轨道。

5、燃尽图：项目完成前对需要完成的工作的一种可视化表示。

1）有一个Y轴(工作)和x轴(时间)；该图有一个 45 度向下的直线，理想状况是：剩余工作量会沿着这条直线“烧尽”至零。现实情况会因项目而异。

2）提供工作进展的一个公共视图，可以根据每天的进展来及时控制项目的偏离度。常常用于敏捷编程。

下图1这个项目前期工作量预估过少，中后期进度有些滞后，迭代的最后一天有的用户故事没有完成。图 2是完美项目的燃尽图，剩余工作逐步燃尽，分批接受用户故事最后全部完成

6、其他进度可视化方法：非正规、非主流的

1）预警提示；2）代码审查可视化分析：代码审查可确保代码质量，利用代码审查工具提高效

3）缺陷分析；4）及时战报；是可视化方法的综合体现，适用涉及人员众多和相互关系复杂的项目

9.4 数据分析

9.4.1 设定不同阶段

数据分析要经过一个观察探索、模型选定、推断和改进分析结果的过程。

1、观察探索性分析；2、模型选定分析；3、推断分析；4、改进分析

9.4.2 分析方法

数据分析是将收集的数据通过加工和整理，使其转化为可利用的信息，常用的方法有以下几种：

老七种工具：排列图、因果图、分层法、调査表、散步图、直方图、控制图；

新七种工具：关联图、系统图、矩阵图、KJ法、计划评审技术、PDPC 法、矩阵数据图。

1、排列图法：为找主要问题或影响质量的主要原因所使用的图。又称帕累托(Pareto)图。排列图分析适用于控制和提高软件质量。

大量缺陷集中存在于少数质量差的模块或部件中，80%以上的缺陷是由20%那部分主要原因造成。

2、关联图法：众多因素交织在一起就使用关联图法来分析。根据事物之间横向因果逻辑关系找出主要问题的最合适的方法。纵向关系用因果分析法分析，但对横向因果关系考虑不充分故不用。

3、KJ法：又称A型图解法、亲和图法。将未知的未曾接触过的领域的问题的相关事实、意见或设想之类语言文字资料收集起来利用其内在的相互关系做成归类合并图，从复杂的现象中理出思路。

K法所用的工具是A型图解或亲和图。亲和图是一种数据精简的图示方法识别各种观点潜在的相似性(亲近关系、亲和性)来分类，把大量的定性输入转化为少量的关键因素、结构或是类别。亲和图有利于分析质量问题。

KJ法的实施步骤：1、准备4~7人；2、头脑风暴会议；3、制作卡片；4、合并为小组；5、合并为中组；6、合并为大组；7、编排卡片；8、确定方案

4、PDPC 法：过程决策程序图，是建立在故障模式、风险分析、故障树分析基础上的综合性的分析方法。顺向思维和逆向思维的不同模式来构造决策程序。

5. Lean Coffee 法：是一种 Agile 讨论会，所有被讨论的议题都是参与者现场提出并投票选出的保证了参与者的积极性和讨论的有效性

9.5 优先级控制

区分事情的重要性和紧急性

(1)重要的、紧急的是第一优先级。
(2)重要的、不紧急的是第二优先级。
(3)紧急的、不重要的是第三优先级。
(4)不重要、不紧急的是第四优先级。

9.5.1优先级设定与处理

管理软件开发的过程，遇到3个不同的层面的优先级处理问题

1.多项目并行优先级处理

领导层站在全局的角度处理项目的优先级，管理的重点是评估好项目的优先级，协调各个并行项目之间的资源，获得最大收益或最佳投入产出比。

2、任务和问题优先级处理

常见的几种高优先级的任务：核心功能或核心模块的任务，关键路径上的任务，有相互依赖关系的前导任务，没有任何缓冲期的任务，依赖外界因素，优先级高，影响范围大，阻碍进度的问题，严重影响项目质量的问题，客户发现的严重问题，。Scrum 模式项目负责人接收完成用户故事时发现的严重问题

3、协调工作优先级处理

一项基本原则：在同样的时间紧迫程度下，他人的问题需要优先解决，因为你的协助是解决他人问题的前提，如同前导任务有依赖关系。自己的问题自己可以随时解决，没有什么依赖条件。

9.5.2 缺陷优先级和严重性

1、缺陷的严重性一般被定义为5个级别：

A类：致命错误，如死循环，导致数据库发生死锁，严重的数值计算错误。
B类：严重错误，如功能不符，程序接口错误。
C类：一般性错误，如界面错误，打印内容、格式错误。
D类：较小错误，如显示格式不规范，长时间操作未给用户进度提示。
E类：建议性问题(非缺陷)。
优先级是指表示处理和修正软件缺陷的先后顺序的指标，哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

2、缺陷的优先级一般被分为4个级别：

1）最高优先级：立即修复否则阻碍进一步测试。例软件的主要功能错误或者造成软崩溃，数据丢失的缺陷。

2）较高优先级：在产品发布之前必须修复。例形响软件功能和性能的一般缺陷。

3）一般优先级：时问允许就修复。例本地化软件的某些字符没有翻译或者翻译不确的缺陷。

4）低优先级：可能会修复，但是不影响正常发布。例对软件的质量影响非常轻微或出现几率很低的缺陷。

严重性程度高的软件缺陷具有较高的优先级，但并不是严重性高的缺陷优先级就一定高。

3、正确区分缺陷的优先级和重要性除根据其定义和级别外有2个必不可少的原则

1）从客户的角度考虑：软件最终是为客户服务的，客户是上帝，对于缺陷同样。评估缺陷优先级的考虑这个缺陷是否对客户造成负面影响。负面影响大，优先级就高。

2）遵照二八原则：帕累托提出，任何一组事物中最重要的只占其中约 20%，其余的80%虽然是多数，但是却是次要的。抓住重要的部分来处理很重要，只有先抓住了重要的关键缺陷，测试效率和测试质量才提高，产生高效益。

3）四象限原则：把缺陷按轻重缓急进行分类，优先处理重要和紧急的缺陷。会很快清楚哪些缺陷是必须马上完成，哪些可以暂时缓。

优先级控制、变更控制、合同履行控制。考点

9.6 变更控制

对于大多数软件开发来说，发生变更的环节比较多。

1、需求变更：软件开发项目中大多数变更都是来源于需求变更。“需求变更”也是业界公认的项目管理重大挑战，尤其是项目后期产生的需求变更，对项目的影响是非常大的。

2、设计变更：这一方面来源于需求的变更，另一方面来源于初始的设计缺陷。

3、代码变更：原因需求、设计的变更，功能缺陷需要解决，代码不符合设计。

4、进度、费用、合同时间、测试计划等的变更

9.6.1 流程

变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。

1、变更提交

在提交阶段，要对变更请求进行记录。根据请求起源和收集信息类型的不同，可以分为新功能、功能增强、缺陷修正等不同类型的请求

1）一般来自客户、市场产品部门或者客户支持部门，但功能增强是在原有功能的基础上对功能进行改善。

2）大多数的缺陷是在软件项目开发内部测试过程中被发现的，不需要经过严格的变更控制流程，缺陷跟踪系统或者缺陷管理流程会记录、控制，直到解决。

2、变更接收

项目必须建立变更请求的接收和跟踪机制有指定接收人和处理变更请求的负责人，确认变更请求。

3、变更评估

首先浏览所有新提交的变更请求，详细了解每个请求的特征，确定变更的优先级、影响范围和所需的工作量，为下一步决策提供是够的数报信息。不同的请求类型，其评估方法和流程是有区别。

4、变更决策

根据评估结果(如工作量估计数据、资源需求、紧迫程度)来做出决策，即决定批准请求还是拒绝请求，或者决定在当前版本还是推迟到将来某个版本上实现请求。

5、变更实施与验证

在变更请求批准后，就开始实施和验证。对新功能、功能增强等请求的实施，往往需要与其他变更结合起来一起控制，如设计的相应变更、费用的相应变更、进度的相应变更等

9.6.2 策略

1、变更预防：事后控制不如事中控制，事中控制不如事前控制。开始之前，调查和研究历史项目的变更信息，找出变更的集中区域，做好相关准备；请经验丰富的专家评估；预留一些缓冲时间

2、变更控制委员会：起着决策和管理的作用。一个有效率的 CCB会定期地考虑、讨论每个变更请求，由于集体决定做出正确的决策。

3、变更执行管理：对于批准的变更建立一个变更任务列表对待其他常规任务一样管理和监控。

4、变更适应--敏捷开发：使软件开发更适应需求变化，使开发团队能力提高，反应越敏捷就越能适应变化。

相关理念：1）构件/组件化：最大限度的软件复用；2）配置化设计理念：让软件开发更敏捷；3）持续集成：自动构建、自动部署、自动测试；4）设计和开发充分考虑扩展性和复用性，避免后期大量重复代码和代码的重构；5）测试驱动开发(TDD),先写测试程序，后再编码使其通过测试。

5、变更经验收集与总结

在管理和跟踪变更的同时，应该把各种变更的原因、方法和经验教训都记录下来形成某软件项目审批通过的需求变更记录单。

9.7 合同履行控制

通过下面几种措施来减少甚至避免合同履行控制相关问题的发生：

1、制定科学完整的合同管理制度

2、制定合理完善的合同履行控制系统

3、加强合同变更的管理

4、强化企业法律顾问的职责

5、组织企业职工的法律培训

补充：

1）在对项目进行任务计划时，会直接考虑到人员和其他资源的划分情况。责任到人是软件开发管理的核心

2）时间是项目计划中灵活性最小的因素

第十章 项目收尾 

与项目的其他阶段不同的是,收尾阶段没有系统有序的工作过程，而往往是非常零碎、繁琐、费时费力的工作。项目收尾是一项复杂的工作，项目经理是其中的关键人物，需要与用户、客户、企业管理层、团队成员进行良好的沟通和交流。

整个收尾工作大体上可以分成项目验收和项目总结两个过程。

10.1 验收

对于公司内部的项目，项目验收过程就相对简单。项目完成由项目负责人组织相关的专家和领导进行项目成果的检查和验收。验收标准：根据当初立面的目标和项目负责人对其作出的相关承诺

10.1.1 验收前提

不管大小项目，项目承包方在正式验收之前应该做到以下几点：

1、完成合同要求的全部内容。即软件开发已经完成，并全部解决了已知的软件缺陷。

2、完成软件系统测试，包括单元测试、集成测试、功能测试和性能测试出具相关的测试报告。

3、各项文档、代码和报告的审查全部完成。

4、准备好相关的开发文档和产品文档。

5、验收测试计划准备好，并通过评审和批准。

6、准备好其他验收资料，如变更记录控制文档、验收审核表等。

7、软件问题处理流程已经就绪。

8、准备好软件安装和验收测试环境。

9、与客户确认验收流程。

10、完成合同或合同附件规定的其他验收内容。

10.1.2 验收测试

验收测试或用户验收测试UAT是软件开发结束后，相关的用户和或独立测试人员根据验收测法计划对软仟产品投人实际应用以前进行的最后一次质量检验活动。

1、功能检测：客户依据项目合同内容、验收标准和相关的需求功能说明书,对所要求达到的成果进行验证确保功能和接口与需求说明的一致性。

2、质量鉴定：质量鉴定是依据合同中的质量条款、质量计划中的指标要求，遵循相关的质量检测标准，对项目进行质量评定。

3、资料评审：项目资料是验收的重要依据，也是项目交接、维护、后期总结和存档的凭证。

10.1.3 验收流程

考点 验收流程：1、准备验收材料同时提交验收申请；2、初审；3、成立验收委员会；4、复审（验收测试）；5、验收合格，项目移交工作；

10.1.4 验收报告

1、项目验收委员会应该根据验收的实际情况出具验收报告，因为验收委员会是由来自客户方、投资方、承包方、信息技术专家等组成的团队。验收报告代表项目全局的视角。

2、验收报告内容要细致、全面、客观、真实，验收报告一方面是出具验收结果，另一方面是给项目组成员提供验收的详细信息。尤其针对项目验收中的问题处理和建议，应该尽可能给出明确和详尽的信息。

10.2 项目总结和改进

结果固然重要，但经验的总结和积累更重要。

10.2.1 总结目的和意义

敏捷迭代模式,建议每个迭代做总结，项目总结至少应包括以下几个目的：

1、分享经验；2、避免犯相同的错误；3、提出合理性建议；4、提升项目流程的改进；5、激励项目团队成员；6、最佳实践的积累

10.2.2 总结会议

内容写成一个报告，提交给上一级部门。在项目管理领域通常把会称作Postmortem meeting或者 Retrospective Meeting

1、项目回顾：对所做的工作或过程作扼要的概述和评价；

2、软件度量结果分析：以在项目结束的时候，要对过程度量的结果进行适当的分析和总结，以便更好地改进软件项目的质量和效率。软件项目的度量一般都是围绕质量、成本、进度、规模、缺陷和代码等来进行的。

偏差(%)的指标当然越小越好；回归缺陷率和无用缺陷率一般用来评价开发和测试的工作质量，回归缺陷率低，表明开发在修理缺陷的时候考虑周全未引起回归缺陷；千行代码缺陷率：其值表面上看是越低越好，客观地是要结合软件规模和生产率的指标来综合分析。如果软件规模大，生产率高，千行代码缺陷率相对低

3、经验、体会分享

4、改进和建议方案讨论

5、嘉奖和庆祝

10.2.3 总结报告

1、总结包括下面几方面的内容:
(1)项目整体信息回顾、度量结果分析
(2)做得好的方面
(3)做得差的方面
(4)改进方案和建议，包括要采取的措施和责任人
(5)寻求帮助信息

2、要注意以下几个问题：

(1)一定要实事求是，成绩不能夸大缺点也不能缩小，更不能弄虚作假

(2)分析问题着眼点要准确，分析要深人，不要回避、隐瞒问题和矛盾

(3)条理要清楚，有主次之。

(4)最好可以剪裁得体，图文并茂，去芜存精。

总结：

1、流程或日常操作一般永久或长期，服务于一个产品系列长期开发过程或一个服务的长期运作。

2、项目总结不包括在项目验收过程中

本文标签： 项目收尾第九章第十章项目管理