面向需求的项目度量

1          引言

作为软件开发项目经理的你，是否真正了解项目当前的状态？作为软件外包项目的甲方，你是否真正了解项目的实际规模？是否了解项目的进度情况？要正确的回答以上问题，并不是一件容易的事情。一般情况下，这些对项目的评估往往是来自于项目经理的判断，缺乏客观依据。而比较合理的做法是应用一套科学的方法，对软件开发各个阶段的数据进行有效的度量和监控。软件（项目）的度量可以说不是一个很新的话题，但是在实际开发项目中，却鲜见应用成功的案例。在这里，我们就结合自身的经验，和汉星天公司所倡导的“面向需求的项目管理”，谈谈如何建立以需求为中心的软件开发项目度量体系；简要介绍一些针对软件规模、工作量、软件质量的常用度量方式，以及如何对软件项目进行有效的监控。

 

2          度量的重要意义

建立一套科学的、可视化的软件生产度量和监控体系，对于软件开发组织具有十分重要的意义。想象一下，在一个软件外包项目中，发包方和接包方是如何就开发工作量达成一致的？如果没有客观的方法，进行科学的度量，双方很可能就工作量问题无法达成一致协议，最终导致项目失败。

再举一例，面对即将发布的软件产品，是什么能够使得项目经理认为产品质量满足发布的要求？这绝对不能是项目经理和测试经理拍脑门来决定的，而需要有量化的指标支持。比如：需求测试的覆盖率是否达到了100%，系统的缺陷密度是否满足发布的要求？

综上所述，软件项目的度量和监控对于开发组织具有重要的意义，归纳如下：

l        对于软件项目的状态、进度具有客观的评估和了解；

l        在和客户进行交流的过程中，就软件开发工作量达成一致；

l        对于软件质量具有科学合理的认识；

l        对于项目的成本和开发进度具有合理的认识。

 

3          需求驱动的项目度量和监控

国内现有的软件开发项目管理，主要是面向任务、计划的，所采用的度量和监控方式一般就是甘特图（这也和国内的开发现状基本相符，目前国内的开发团队一般都是赶任务，被要求按时交付产品）。但是这种单纯面向任务的管理方式，仅能展现项目的进度视图，不能提供项目其它维度的信息（需求、测试用例等）。所造成的结果就是，软件可以按时交付，但是埋藏了很多的Bug在里面，然后再去投入大量人力去改Bug。这事一种非常不科学的开发方式。

在汉星天公司所遵循的理论架构和开发的产品中，强调以需求为驱动的软件项目开发，因为实现需求是一个软件项目的开发目标，需求也是软件产品存在的原因和项目的起点，总结一句话：需求是软件项目的核心。从需求的角度进行项目的管理和度量，不仅可以轻松掌控项目进度，保证产品质量，还可以做到和项目利益相关者（Stakeholder）的有效沟通。所以在这里，我们也是紧紧围绕着软件需求来建立我们的度量体系。在汉星天公司的协同开发管理工具和软件生命周期管理（ALM）工具中，主要包含以下几方面的度量内容：

l        需求的量化

l        以需求为视角的项目进度视图

l        以需求为视角的生产率视图

l        面向需求的软件质量视图

 

4          度量的方式

4.1         需求的量化

需求的量化不仅对软件外包行业中的发包方和接包方具有重要的意义，使得双方对于软件的规模有一个客观的估算。在一般的开发组织中，也可以用它来做为绩效考核和工作量估算的重要参考指标。传统的需求量化方法是代码行（LOC：Line of Code）,该方法简单易用，但是客观约束不强。该方法是在事后进行估算，或是根据以往的经验值进行估算。往往会受到开发语言，开发人员安排等等的影响。

目前，国际上比较流行的软件规模度量方法是“功能点分析法（Function Point Analysis）”。该方法基于IFPUG（国际功能点用户组）提供的计算方法。这种计算方法通过计算对用户有用的功能，能够在项目需求阶段就完成规模估算，并且以量化的方法衡量软件规模，而且避免了SLOC方法受到实现技术、平台、人员素质影响的问题，具有较强的客观性，从而在世界范围内被越来越多的开发组织所接受。

该方法主要是从系统的规模和技术复杂度两个方面来衡量需求的规模。在衡量系统规模时，需要鉴定需求的五种不同功能类型的复杂度（五种功能类型分别是：内部逻辑文件－ILF、外部接口文件－EIF、外部查询－EQ、外部输入－EI、外部输出－EO），并与相应的权值相乘，从而得到“未调整功能点数（UFP：Unadjusted Function Points）”。之后，对整个软件系统的14个系统特征值（GSC）进行评估，将各个评估值相加，得到总的影响度（TDI）。之后，依照以下公式计算功能点：

 

FPC ＝ UFP × （0.65 + 0.01×TDI）

                                          公式1: 功能点计算公式

 

得到系统的功能点总数之后，也就相当于知道了系统的规模。再根据开发团队的工作效率（单位是：功能点/人月，该值为一经验值）就可以估算出软件项目开发需要的时间。参见公式2。

项目用时 ＝ 总功能点数 / 开发团队工作效率

公式2: 项目时间估算

 

4.2         以需求为视角的项目进度视图

以往的项目进度监控方式是面向任务的。但是单从任务角度来了解项目的进度是不够的。因为任务有难有易，单从任务这个角度，还很难反映出项目进行的真实情况。那么应该从哪个方面来有效的衡量项目的进度呢？因为软件的规模可以量化成为功能点，是一个量化指标，所以我们认为除了任务以外，更应该从功能点或是需求这个角度来衡量项目的进度。

a)        面向功能点的项目进度监控

项目进度 ＝ 已完成需求的FP总合/项目所有需求的FP总合 × 100%

                                               公式3: 用功能点监控项目进度

 

当项目经理需要了解需求完成率细节时，还应该可以了解每个需求的功能点完成情况。

图1: 从功能点监控项目进度

 

b)        如果开发组织内还没有采用功能点这种软件规模度量方式，可以仅从需求方面来进行度量。具体做法是可以衡量不同状态的需求在总需求中所占的比例。

图2: 从需求度量项目状态

 

4.3         以需求为视角的生产率视图

评估项目或团队的生产率，需要以项目的规模作为基础。为了衡量软件团队或是程序员的工作效率，我们可以衡量单位时间内团队或个人所完成的功能点数量。由于功能点的计算是考虑了功能需求的难易程度，同时使用科学的量化方法，所以使用功能点的方法更客观、更具有可比性。计算出团队的生产率后，还可以作为一个积极的反馈，为将来的项目计划制定提供可靠的数据。

 

4.4         面向需求的软件质量视图

衡量软件质量有很多不同的方法，例如：软件产品的Bug总数、千行代码（KLOC）的Bug数等等。这里我们主要讨论面向需求的软件质量度量。

a)        测试案例的需求覆盖率

为了保证所有系统需求都要被执行测试，从而保证整个软件的质量，需要统计需求的测试覆盖率。在这个度量中需要统计所有用户需求、功能需求、非功能需求所关联的测试用例的个数。项目经理可以立即发现那些没有测试用例的需求。

b)        缺陷密度

缺陷密度是一个反映软件质量的重要指标。传统的缺陷密度度量指标是千行代码的Bug数目。在这里，我们推荐使用面向需求的缺陷密度度量方法。具体方法是通过计算每规模单位中所包含的缺陷数量，来反映项目的质量状况，规模单位可以使用功能点或者是需求。

使用功能点作单位时，因为是使用统一的方法量化项目的规模，所以可以很好的在不同的项目之间、不同的开发团队、个人之间建立有效的比较。

当使用需求作为衡量单位时，可以很快的发现是哪些需求为系统引入了较多的Bug，进而分析是程序开发存在问题还是需求描述出了问题，或是这个需求本身就不是十分合理，应该对其进行裁减。

c)        需求变更的冲击分析

需求的变更往往为正在进行中的项目带来较大的影响。如何评估这种改动所造成的影响成为确保软件质量的重要任务。所谓冲击分析，是在项目的需求和其它组件（程序设计、程序编码、测试用例、项目文档等）之间建立一定的关联关系，当需求发生变更时，系统向相关人员发出警告，提示系统需求已经发生变更，请检查相应组件是否需要更改。进行有效冲击分析的前提是建立需求相关矩阵，同时需要具有规范的需求变更流程控制，当你的软件开发管理工具同时支持这两种功能时，就会为你所负责的软件项目质量提供很大的保障。

 

5          小结

建立度量体系对于增加开发组织决策的科学性、减少项目的风险、提高项目的质量、增加开发过程改进的针对性，有着很大的帮助。从确立组织管理目标出发，建立起与开发过程/工具紧密结合的度量体系和数据收集过程，分析利用度量数据改进度量和软件开发过程，形成一个良性循环，从而充分发挥出度量对开发组织的重要作用。

不同于以往的面向任务，面向源代码行数（LOC）的度量过程，本文着重推荐了面向需求的一些项目度量方法，所有的度量方法都是紧紧围绕在项目需求的周围，从需求的视角来衡量项目的规模、项目的进度、生产率、和项目的质量。把这套理论体系应用到开发团队的日常开发环境中，不仅可以大大提高项目的可视性，规避风险；还可以有效的避免项目管理中的黑洞，提高软件质量。