如何估算软件项目的工时？

起初…

在过去的美好时光里，软件开发的成本完全是基于投入的工时。这对许多技术人员来说是件好事，因为他们很多人都不清楚如何交付解决方案，而且涉及大量的试错。大多数软件开发人员通常被安排在所谓的研发部门:o)。这对软件行业来说很糟糕，因为它意味着即使是中等规模的项目成本也高得离谱，导致大多数投资者远离这类事业。没有人能质疑这种状况，因为没有人知道更好的方法（尤其是技术人员）。

然后，度量指标逐渐被引入开发流程，一切都改变了。现在，如果大多数程序员一天能编写 1000 行可接受的代码，那就算作标准产量。这对于 COBOL 等语言来说是可行的，因为代码的可重用性几乎不存在。人们会参考已编写的代码，并进行修改（说起来容易做起来难）。

然后，C 语言逐渐流行起来，很快，仅仅写代码行数已经不够了。C 语言有内置库，这削减了在代码行上瞎搞的乐趣。此外，程序员可以将代码行放入一个函数中，然后在其他函数中重用该函数。因此，重点就转向了开发了多少函数。所以，如果你能将代码分解成许多函数，那就意味着你的产量更高。非常酷。每当一个函数超过 20 行时，就有可能将其拆分并提高产量。

然后 C++ 出现了，它让估算工作变得更加复杂。现在我们有了组件、对象、类、库等等。系统设计变得至关重要，可以决定如何减少涉及的工时。良好的设计意味着可以将包含数百个函数、成千上万行代码的整个组件/子组件（这些函数位于几百个类中）进行重用。即使在组件内部，许多类和函数也可以被重用。即使这样也是可以接受的，前提是有一个完整、详细且已批准的设计。这样的设计将有助于确定所需的函数和代码行数。

那么，问题到底出在哪里？

如今，项目成本通常在设计完成之前就已经确定，有时甚至在设计开始之前。估算现在更多地变成了基于早期估算错误所积累的经验进行猜测。没有设计，很难知道需要多少行代码/函数/组件/对象。估算人员应依赖于开始设计之前可用的数据和文档，例如功能和非功能性需求、工作流程和用例。因此，需求收集和分析对于项目的估算（设计、开发和测试）至关重要。

利用这些文档，估算人员可以同时创建一个对象层次树。对象层次树可以帮助识别要创建的不同级别/类型的对象，这些对象预期会做什么，甚至是一些对象的属性。因此，在没有应用程序设计的情况下，可以确定工作范围，即所需的功能。

接下来，我们需要确定一个典型团队成员的产出。一些公司喜欢根据团队成员的角色、职位和薪资等级来区分团队成员。团队成员的产出应与其角色、职位和薪资成正比。团队成员的工作包括想法、建议、讨论、研究和编码。但他们的产出包括设计、文档、测试用例设计、编码、调试和测试。通常，架构师不会进行任何编码。测试人员和项目经理也不会。因此，这些不同角色的交付成果需要区别对待，如下所示：

角色	输出
程序员	编码的函数数量。
设计师	顺序图、类（含函数）设计、关联。
架构师	需求分析。设计的主要组件和层数。类和对象的批准。
测试员	系统功能测试。
业务分析师	需求、工作流程和用例。
项目经理	合同规定的交付成果、资源管理、危机处理。

还有其他角色，如部署经理、SQA、领域顾问等等。这里的问题在于，许多估算是在能够确定上述各角色涉及多少工时之前完成的。在本篇文章中，我假设所有团队成员在工作量和薪资方面都是平等的（极限编程的信徒会欣赏这一点）。

如何在没有设计的情况下估算应用程序成本？

每家公司都会确定其期望的团队成员产出。我们将团队成员每工时的平均产出称为单位产出（u.o.）。假设需要为一个应用程序交付端到端的登录模块功能。花在登录功能上的时间应包括收集需求、进行需求分析、架构输入、表单设计、对象/类设计、实现业务规则、数据验证和存储、框架（即登录模块常量、枚举、实用函数的代码）、测试、调试、部署直到用户验收等相应所需的时间。现在，估算人员必须考虑到所有这些因素，估算出完成登录模块需要多少工时。应考虑工作顺序和依赖关系，因为它们会导致完成延迟。例如，表单设计应首先完成（直到客户批准），然后是对象设计（直到架构师批准），然后是编码（用于业务规则、计算和数据验证）、单元测试和用户验收测试。明智的估算人员会始终寻求他人的支持，以了解完成某项任务的工作范围。

将旧项目的功能映射到新项目中

登录模块是大多数应用程序的常见功能，因此如果完成所有这些活动的总体工作量是 20 个工时，我们可以说得过去。现在，如果公司每小时成本为 700 卢比（针对程序员、工作站以及软硬件），那么开发登录屏幕的基本成本为 20（工时）x 700（卢比）= 14000.00（卢比）。哎哟！疼吗？会不会太多（时间/金钱）？还是太少了？最好多想想来证明这两者。

估算人员还应尝试将旧项目与新项目进行比较。这将使他们对所花费时间有一个更宏观的了解，然后他们可以尝试将工时分配到应用程序的模块和阶段。

将复杂的东西转化为简单的东西

开发一个简单的注册功能（端到端）所需的小时数，大多数估算人员都能做到。简单的注册表单将包括用户名、密码和电子邮件 ID。在我看来，这与登录页面差不多，所以我们再次设定为 20 小时。一个更复杂的表单，包含大约 20 个 GUI 元素，具有多个业务规则和数据验证，可能需要更多的时间。在这种情况下，尝试将 GUI 元素和功能分组，使每个部分看起来与简单的注册表单范围相似。然后，将从复杂表单派生的简单注册表单的数量加起来，乘以每个简单注册表单的工时，就可以了，你就得到了开发复杂注册表单所需的工时。

这个概念同样适用于功能复杂的业务对象。对象应被简化为简单的对象，以便更容易确定其工作量。在开发应用程序的通用事件处理组件时，首先尝试将其分解为更容易理解的“部分”。假设事件处理组件将涉及记录某些类型的事件，但不包括表示层和数据层上发生的事件。记录应作为一个单独的组件来开发，因为它可能还涉及异常记录、安全记录、性能记录、磁盘使用情况记录、CPU 记录等。因此，在估算事件对象时，请排除日志组件的开发（它只使用日志组件）。现在，事件对象将涉及定义要处理的事件、事件可能传递的数据以及为这些事件开发事件处理程序。慢慢地，你会发现它更容易确定开发此组件所需的工作量。

尝试使用对象层次树

这是一个易于创建的应用程序图形化视图，可以更轻松地理解应用程序的范围。在对象层次树中记录所有细节，如对象的目的、角色和位置。可以使用用例、活动图、业务需求和工作流程等其他文档来证明树中对象的存在。这个树不能替代一个完整的、已批准的设计。它只是有助于在项目早期启动工作，并且可以作为完整设计的先驱。应创建单独的对象层次树来识别业务对象、框架对象和表示层对象（表单对象）。

不要忘记风险。

估算中需要考虑的另一个因素是风险。风险因素应根据项目范围、需求、设计和策略、技术、流程（用于开发、支付、变更管理、风险管理和项目收尾）以及项目条款/条件来确定。当所有利益相关者（包括客户和开发公司）都理解并对整个项目感到满意时，风险因素就很低。否则，风险因素会成倍增加。始终尝试确定并接受风险，包括可能的风险，至少在核心团队内部。如果每个人为了看起来自信和积极而一直描绘一幅美好的图景，那么项目可能会糟糕收场。识别风险并确定如何解决它们，不要回避它们。每个阶段、步骤、组件都应根据其风险因素进行分类。如果风险因素过高，即有太多问题需要解决，那么可以肯定项目将糟糕收场，所以最好不要参与，除非你出于任何原因需要（痛苦的）经验。

风险必须由开发公司根据自身的经验和优先级进行分类。以下是一些评定风险的方法：

当大多数利益相关者有疑虑时，风险因素被评为高。即使项目的一个重要功能似乎难以执行，风险也很高。例如，可接受的 Bug 类型和用户验收的 Bug 数量、项目收尾条款、付款不清晰或被误解等问题，都会使项目风险很高。

当非常少数的利益相关者有一些疑虑时，风险被评为中等。例如，开发团队可能对技术没有非常深入的了解，但可以提供一些解决方案。另一种情况是，客户方人员无法确定一些不重要的工作流程。

当表单格式未最终确定但功能已充分理解且解决方案已批准等问题时，风险为低。

迭代开发可能总是存在中度到高度的风险，因为对现有模块的更改是很常见的。除非利益相关者已明确规定解决变更需求的指导方针和良好的变更管理流程，否则这里的风险通常非常高。

瀑布模型过于僵化，但风险因素较低。在这里，功能更改通常意味着客户要付出额外成本，而无法按合同交付功能则意味着开发公司要承担更高的罚款。但是，这里的优点是，在做出任何承诺之前，需求就已经固定了。

这仍然很奇怪 machacha

软件估算是一个非常笼统的主题，很难向非行内人士解释。但总得有人去做。通过估算简单的模块来练习，使用本文中提供的建议。从登录或简单的注册表单开始，然后逐渐转向更复杂的表单。并记录你为某项任务估算工时ntz的原因。迟早，你将跨越门槛，成为一个物有所值的估算师。

在读者的建议下，我可能会为本文增加更多价值。

软件项目样例文档摘要

软件项目估算
摘要
序号	项目	单位	数量	角色/技能	人天	费率（印度卢比）	金额（印度卢比）	备注
1	愿景文档	个	1	不适用	2	4,000 .00	8,000.00
2	工作流程/子工作流程	个	55	不适用	55	4,000 .00	220,000.00
3	用例	个	50	不适用	250	3,200 .00	800,000.00
4	对象在层次树中	个	210	不适用	262.5	3,200 .00	840,000.00
5	技术栈	个	10	不适用	5	4,700 .00	23,500.00	收集+分析
6	非功能性需求文档	个	1	不适用	2	4,000 .00	8,000.00
7	层	个	4	不适用	2	5,000 .00	10,000.00
8	活动图	个	100	不适用	1050	3,047 .62	3,200,000.00
9	流程图/流程	个	100	不适用	800	3,000 .00	2,400, 000.00
10	Components	个	7	不适用	98	4,000 .00	392,000.00
11	对象在框架树中	个	150	不适用	300	3,500 .00	1,050, 000.00
12	部署	个	2	不适用	22	3,181 .82	70,000.00
13	测试用例设计	个	400	不适用	500	3,200 .00	1,600,000.00
14	工具需求	个	6	不适用	3	5,000 .00	15,000.00
15	用户验收测试	个	1	不适用	900	3,000 .00	2,700,000.00
	总计				4252	3,136 .89	13,336, 500.00	$296,366.67
	添加风险因子	个	3			1.00	40,009, 500.00	$889,100.00
需求收集
序号	项目	单位	数量	角色/技能	人天/单位	速率	金额	备注
1	愿景文档	个	1	BA	2	4,000 .00	8,000.00
2	工作流程/子工作流程	个	55	BA	1	4,000 .00	220,000.00
3	用例（主要）	个	50	BA	1	4,000 .00	200,000.00	用户界面，用户流程组件
4	对象在层次树中	个	210	设计器	0.25	4,000 .00	210,000.00	业务组件
5	技术栈	个	3	BA	0.5	4,000 .00	6,000.00	IE，asp.net，sqlserver
6	非功能性需求文档	个	1	BA	2	4,000 .00	8,000.00
	总计		320				652,000.00
需求分析
序号	项目	单位	数量	角色/技能	人天/单位	速率	金额	备注
1	层	个	4	Architect	0.5	5,000 .00	10,000.00	表示层、业务层、数据格式、数据存储
2	活动图	个	100	设计器	0.5	4,000 .00	200,000.00
3	流程图/流程	个	100	高级开发/开发	1	3,000 .00	300,000.00	流程组件
4	Components	个	7	架构师/设计师	7	5,000 .00	245,000.00	接口、控制器、数据实体
5	对象在框架树中	个	150	设计器	1	4,000 .00	600,000.00	服务接口、数据访问、外部接口、安全
6	技术栈	个	7	Architect	0.5	5,000 .00	17,500.00	html，xml，jscript，c#，asp.net，sql，com+，
7	部署	个	2	Architect	1	5,000 .00	10,000.00	设计
8	测试用例设计	个	400	测试主管	0.25	4,000 .00	400,000.00
9	工具需求	个	6	Architect	0.5	5,000 .00	15,000.00	vs.net，load runner，win runner，nunit，vss，xml spy
	总计		776		12.25		1,797,500.00
上述项目的开发和测试实体
序号	项目	单位	数量	角色/技能	人天/单位	速率	金额	备注
1	流程图/流程	个	100	高级开发/开发	7	3,000 .00	2,100,000.00	工作流程组件的开发
2	活动图	个	100	高级开发/开发	10	3,000 .00	3,000,000.00	除流程图开发出的工作流程组件外的其他工作流程组件的开发
3	测试用例设计	个	400	测试主管	1	3,000 .00	1,200,000.00	测试
4	对象在层次树中	个	210	高级开发/开发	1	3,000 .00	630,000.00	业务组件的开发
5	对象在框架树中	个	150	高级开发/开发	1	3,000 .00	450,000.00	服务接口、数据访问、外部接口、安全、日志记录、事件处理、常量、枚举、国际化、本地化的开发
6	用例	个	200	高级开发/开发	1	3,000 .00	600,000.00	用户界面，用户流程组件
7	部署	个	20	高级开发/开发	1	3,000 .00	60,000.00	sql、dll 和 exe 的部署脚本/文件
8	Components	个	7	高级开发/开发	7	3,000 .00	147,000.00	接口、控制器、数据实体
9	用户验收测试	个	1	开发团队	900	3,000 .00	2,700,000.00	接口、控制器、数据实体
	总计		1188				7,980,000.00
实体	这些是创建的对象以及/或在需求收集与分析中识别的项目。图包括对象层次树（框架、业务对象、表单）、工作流程、流程图、活动图、用例、组件和部署。

历史

这是第二稿。