如何估算软件项目

引言

我们先弄清楚一件事。我之前做过的唯一估算是在我的工程时代，那时我为建筑工程计算数量和费率。当时最大的优势是，*估算开始前大部分设计和规范都已最终确定*。如果不是这样，你可以报一个模糊的数字，叫做“公认的市场价”，然后（如果你有能力的话 ;)）随着设计和规范的最终确定而不断修改这个数字。

对于像我一样背景的人来说，根据与客户和利益相关者的一些讨论来估算软件项目是荒谬的。估算软件项目就像在不知道要发明什么的情况下，估算发明它需要花费多少。功能点分析和COCOMO（？）是给极客用的。软件估算常常大错特错，最终结果就是一些极客被解雇。

因此，我做了一件明智的事情。我远远避开了软件项目估算。但情况在变化，回避这项愚蠢的任务越来越困难。无法估算项目、资源、风险等，也意味着无法获得好处，拓宽视野，并在极客阶梯上攀升。同时，需要养家糊口的人越来越多，财务承诺越来越多，需要处理的税也越来越多。而且，一直做低级编码也没有意义。一个人应该努力达到一个可以真正搞砸事情的水平。

要点

好了，抱怨够了。抱怨没用。而且我的上级比我更擅长抱怨。我的目标是找到一种方法，使估算一个常规软件项目类似于估算一个常规工程项目。典型的工程项目估算包含以下几个部分：

• 识别工作项目。
• 为每个工作项目确定单位。
• 计算工作量。
• 计算每个工作项目的费率。
• 微调最终成本。

费率是每单位工作涉及的资源成本。资源通常是：

• 工时。
• 材料。
• 工具和设备。
• 管理费用。
• 利润率。

管理费用包括：

• 场所费用。
• 工具和设备的折旧。
• 利息等。
• 许可证、许可、税费。

同样的理念可以应用于软件项目估算。我们首先识别和描述工作项目，然后确定项目单位、工作量，依此类推。从技术角度来看，由于其冗长的性质，描述工作项目可能会非常令人烦恼。费率部分应该看起来比较正常。通常，管理费用和利润率（仅由授权人员决定 ;)）按百分比计算。到目前为止，许多人可能会嘲笑或谴责这种方法。这种方法的主要论据是，大多数工程项目需要持续多年，项目周期从几个月到几年不等，并且有许多非技术人员认为他们比工程师更了解情况（在某些情况下，这是真的）。许多工程项目都有批评者，包括政治家、记者、律师、社会工作者、市民、白痴，甚至工程师。工程项目包括埃及金字塔、太空探索或制造回形针。那么，为什么不能将工程技术应用于软件开发——一个包括软件、硬件、计算机和网络工程师的领域，并且需要可靠性、健壮性和可扩展性呢？

识别工作项目

好的，现在是第一部分。什么是工作项目？在业务应用程序中，这可能是一个工作流、子工作流，或组件或子组件的开发。我们还需要对工作项目进行分类（即识别工作类型）。

在下面的例子中，我将创建一些软件项目的工作类别。典型的分类树如下图所示：

我们可以继续细分更多的类别和子类别，但现在，我们将尝试在上面显示的类别内进行估算。硬件类别及其子类别下的所有项目都更容易估算，因为我们可以从其购买/市场价值中获得成本。操作系统、运行时软件和工具也是如此。工作站的成本包括办公空间、电力、水、空调等场所费用。还需要根据适用情况添加获取每项物品的其他成本，如租金、许可证、工作许可和税费。一些管理费用和隐藏成本未在此树中反映。这些通常作为固定成本或总成本的百分比进行估算并添加。

实际的软件开发成本从“应用程序”类别开始。大多数业务应用程序都有几个模块。模块是应用程序中的一个功能。现在，我们开始为每个类别的每个工作项目进行识别。

“框架”类别提供了骨架，应用程序中的所有其他组件都链接或依赖它来执行常见任务。

框架开发可能包括以下工作项目：

• 数据访问组件
• 异常处理
• 日志记录
• 电子邮件/传真
• 打印
• 数据导出
• 服务（Web服务、远程处理、DCOM、COM+、应用程序服务器等）
• 安全性（授权、认证、代码访问、加密）
• 资源文件
• 部署
• 杂项（实用程序、常量、枚举）

“表示”类别可能包括以下工作项目：

• GUI（窗体和控件）
• 自定义控件
• 验证
• 动画和图形

“业务”类别可能包括以下工作项目：

• 编码（针对工作流和业务需求）
• 验证数据
• 公式和计算
• 数据操作
• 实现业务规则

“数据格式化程序”类别用于在发送数据之前和接收数据之后将其转换为可接受的格式。格式可以是XML、值对象（用于在层之间传递数据的对象）和加密。

“数据存储”类别可以包含以下工作项目：

• 数据库设计
• 编写SQL、存储过程、触发器
• 索引
• 性能调优
• 平面文件（包括文本、XML、图形、多媒体等）

应用程序本身也是一个类别。在应用程序类别中，工作项是工作流。工作流本身可能包含其他工作流和流程。确定工作项费率时最常见的因素是预期的工作量（GUI对象、代码行数、非私有方法等）和预期的复杂性。这取决于投标公司的经验、使用的技术以及可用的支持。工作量随着工作流的大小而增加。如果工作流有很多规则、分支、子工作流和流程，这表明其复杂性。*复杂的子工作流应分解为更简单的子工作流。*因此，估算的基础是尽可能多地开发工作流，并在工作流中加入最多的细节。如果无法开发所有工作流（通常情况是这样），那么（业务分析师应该能够）将预期的工作流与现有工作流进行匹配，以便更准确地进行估算。除非是静态网页，否则在不进行工作流开发的情况下尝试估算项目几乎是不可能的。

既然我们已经识别了一些工作项目，我们需要详细解释它们。确定确切要提供什么（以及可能不提供什么）、相应的规范、人力、硬件、文档和其他可交付成果的成本，直到完成（或交付）的开销。在软件中，这还应包括测试、质量保证、用户验收测试和保修的成本。

描述完工作项目后，为每个项目确定单位。对于窗体开发，单位可以是数量（个）。请注意，窗体可以根据其复杂性和内容进一步细分为类别。因此，除非所有窗体都相似，否则不要将所有窗体归为一项工作。在“业务”类别中，我们应该识别主要的业务对象、组件或功能，并根据内容和复杂性进行分类。同样，业务类别工作的单位可以是数量。

数据库可以根据预期的数据库对象数量，以及表、视图、SQL、存储过程、范式化以及所需的数据完整性级别来估算。

完成一个工作流后，应仔细研究以识别涉及的工作项。以下是一组用于请求和提供资源的子工作流。

分类

让我们研究一下不同类别的资源分配子工作流。

数据存储类别

这需要存储资源详细信息，以便轻松存储和检索资源。这涉及到关系数据库管理系统。数据库应包含表，根据某些特征（例如人力资源、物品和文档）存储资源。为了更快地检索它们，可以进一步对其进行分类，并关联关键词。所有这些类别本身都将存储在另一个表（或多个表）中，并映射到其父类别。

资源请求应与找到的资源匹配。因此，所有请求都存储在一个表中，并可以根据优先级、影响、请求人/部门以及资源可用性进行分类。

最后，应记录接受或拒绝资源的各种标准，以及接受或拒绝资源的部门/人员，并附带解释。接受/拒绝资源的标准可以存储在另一个表中，也可以进行分类。

放置请求、搜索和分配资源需要编写SQL。通过查看屏幕功能（如果有原型）以及工作流本身，可以大致了解要开发的SQL的复杂性。

因此，我们立即对数据存储方面的需求有了一个初步了解。

表示类别

负责资源分配的人员需要查看资源请求。他们还应该能够根据请求状态、请求日期、优先级、影响、部门、成本等对资源进行排序。这将帮助他们决定如何处理每个请求。负责资源的人员应该能够根据类别和子类别、关键词、状态、位置等搜索资源。最后，资源应映射到请求。应开发屏幕来显示请求详细信息、资源详细信息、资源和请求映射、搜索请求和资源等。显示可以在WinForms、浏览器或控制台中。

业务类别

业务类别通常包含接口和业务对象。业务对象可能执行计算（例如，可以从提供的日期计算时间段），实现业务规则（例如，特定部门是否可以获得特定资源），调用业务方法的顺序，以及与数据层的交互。

在资源分配工作流中，我们可以有请求者、资源经理、资源和搜索引擎等业务对象。在估算工作流成本时，可以考虑每个对象。

数据格式化程序类别

数据格式化程序确保数据格式正确。如果某个数据是浮点型，那么数据格式化程序将在数据传递给它时将其转换为浮点型。否则，它根本不允许分配数据。如果是XML，它将确保XML文档按照某些预定义的格式构建。数据格式化程序也可以是框架的一部分。数据格式化程序也可以被认为是用于在不同层之间传递数据的对象。

框架类别

资源分配工作流所需的框架组件可能包括层间通信、安全功能、自定义组件、库、资源文件、数据层访问、错误处理，以及可能的日志记录、电子邮件、传真和第三方交互。这些组件的开发程度应在查看整个应用程序后进行考虑。但对于我们的工作项，我们应该考虑一部分框架开发成本。这是因为框架是开发需求而不是业务需求。所以，只考虑流程所需的框架功能，并为其费率添加近似成本。

工作项

我们将工作项称为“资源分配”。既然我们已经从不同类别的角度审视了工作项，描述起来会更容易。关键方面是开发工作流所涉及的劳动力或工时。大多数公司都有自己的指标，根据以往项目的投入来计算开发成本。根据以往项目的指标，他们计算工时数。

现在我们将工作项放入估算表中，如下所示：

序号。	项目 代码	描述	速率 （人民币）	单位	数量	金额
1	wf_res_01	开发和部署工作流资源分配，包括子工作流、组件、显示屏幕的代码编写，插入、修改、删除和检索数据，在客户端系统、服务器、数据库和外部服务之间传递数据，验证和格式化数据，实现业务规则，包括数据库设计、应用程序设计、质量保证、单元/集成/黑盒/负载/用户验收测试、硬件/软件工具/操作系统/编译器/人工/许可证/许可/运输/可交付成果。	60000.00	件	1.00	60000.00

对于没有经验的估算师来说，很难确定表中所示工作项的成本。最好的方法是尽可能详细地描述工作项，然后尝试得出每个细节的成本。寻求有经验的人（架构师、经理、开发人员、测试人员、技术文档作者等）的帮助，以识别更多细节（包括硬件、软件、工时、管理费用）及其相应的成本。然后只需将其相加，并将最终数字与之前类似工作的成本进行比较。

结束语

与许多工作项目是重复的、更容易计算机器或人员平均产量的工程项目不同，软件项目通常有更宽泛的波动。风险因素、影响因素、变更，甚至沟通失误都更多，并极大地影响成本。所有这些问题都必须与预期的利润率一起计入成本。

J