Scoping、分析和估算

引言

目标

我们所有人在工作中都会在某个时候做这件事。事实上，我们在生活中时时刻刻都在做。试图弄清楚我们需要多少资源（例如时间、金钱、精力）才能实现我们的目标。这可能是一次计算预期支出，或将一张纸屑扔进几英尺外的垃圾桶，或编写代码所需的时间，或任何需要时间的事情。

为了更好地了解完成一项工作所涉及的内容，我们需要进行估算。估算本身取决于我们对工作范围的分析。如果工作范围没有得到清晰的解释，分析就无法正确进行。理解、解释和记录工作范围是相当困难的。这通常是由于领域知识不足、业务复杂性、每个客户的特定需求以及工作流程和流程展示不佳。本文从开发人员的视角而非分析师的视角，着重于范围界定、分析和估算，同时牢记上述不足。

提案

在本文中，我将尝试解释如何创建一个资源管理工具。我将使用 **对象层次结构树** 来识别我应用程序中的业务对象，创建一些简单的流程来理解需要做什么，并识别应用程序的用户。

1.1 愿景

“开发一个易于使用、通用、资源管理工具。”

1.2 用例

• **请求** 资源：授权人员向相关部门发出资源请求。
• **识别** 资源：资源经理然后搜索是否有任何匹配资源的可用性。
• **评估** 资源：授权人员对资源进行评估。
• **分配** 资源：资源被分配给个人或部门。

1.3 每个工作流程的需求

1.3.1 资源请求

• 提供资源的 **名称**。
• 提供资源的 **类型**。
• 提供资源的 **描述**。
• 提供想要资源的 **原因**。
• 提供请求的 **日期**。
• 提供预计资源可用 **日期**。
• 提供预计资源的近似 **成本** 范围。
• 提供资源的 **重要性**。

1.3.3 识别资源

• **搜索** 所需资源。
• **显示** 搜索结果。
• **查看** 可用资源的详细信息。

1.3.4 评估资源

1.3.5 分配资源

1.4 识别业务实体。

现在到了我喜欢的部分。利用上述有限的文档，我们可以通过一点思考涵盖很多内容。我们首先尽可能地识别业务对象，然后创建一个对象层次结构树来更好地理解它们。

首先，让我们从一个代表我们正在开发的工具的通用对象开始。我称之为“Rap”。然后，通过阅读提供的文档，我识别了可能的业务对象，并将其字体更改为粗斜体橙色。

除了业务实体之外，还有一些实用对象，例如数据访问对象、自定义异常处理、日志记录、数据格式化程序、安全、常量和外部接口。同时也要注意常规对象，如用户、表单、错误和其他消息文本。

因此，通过结合经验和现有文档，我得出了以下对象树。现在这还不是最终版本，根据我们进一步的理解，我们可以修改对象树。

对象树让我对开发应用程序所涉及的内容有了更好的认识，并且比数千行的文档更容易理解。虽然这不是一个面向对象的继承树，但它确实涉及类似的思考方式。因此，当我们进行范围界定和分析时，这个树会不断扩展，最终我们会得到许多对象。

1.5 将对象映射到工作流程

范围界定和分析的这一部分更多地用于可追溯性。它帮助我们理解对象是如何与提供的工作流程相关联的，并证明它们存在的合理性。这与 UML 中使用的活动图有相似之处。对象是“流”，工作流程的节点是“活动”。

我们可以争论具体哪个工作流程节点属于哪个对象。这正是提高我们对应用程序理解所需要的。我们越努力地将事物纳入对象树和工作流程图，我们就越能识别出为了满足需求我们还需要做什么。我们越努力地将事物纳入对象树和工作流程图，我们就越能理解需求是否还有差距或是否不言自明。它有助于我们认识到我们是否正确理解了客户的需求。例如，直到我试图完成映射，我才识别出“数据”对象。而且我仍然不确定“填写请求表单”工作流程节点应该放在“请求”对象还是“表单”对象。但我仍然觉得上面的映射让我对这里涉及的内容有了更清晰的认识。

1.6 估算工作量。

我写过两篇关于我的估算方法的文章。它们是 如何估算软件项目 和 如何按人时估算软件项目。

在估算时，请考虑以下一般要点

• 识别所需的体系结构、窗体、类、组件和支持文档。
• 定义所有项目的结构和目的。
• 编写测试用例。
• 编码、代码优化、单元测试和集成测试。
• 回归测试、性能测试。
• 部署问题和验收测试。
• Beta 测试和保修。

我将重点关注本文中识别的两个对象如下

1.6.1 表单

从对象和工作流程图，我们现在可以进一步分解细节，几乎达到 GUI 级别。图中的表单对象/工作流程将是请求和原因表单。请求的详细信息在第 1.3.1 节中提供。使用这些，我们可以得出每个表单所需的控件类型。

例如，

• 提供资源的名称 -> 标签和文本框。
• 提供资源的类型 -> 标签和下拉列表。
• 提供资源的描述 -> 标签和多行文本框。
• 提供想要资源的理由 -> 标签和多行文本框。
• 提供请求的日期 -> 标签和日历控件。
• 提供预计资源可用的日期 -> 标签和日历控件。
• 提供预计资源的近似成本范围 -> 两个标签和两个文本框。
• 提供资源的 গুরুত্ব -> 标签和下拉列表。

大多数表单都放在一个模板内，该模板由顶部、左侧、右侧、底部和中央部分组成。这些部分中的每一个都可能包含需要单独估算的内容。再次，描述表单、控件和内容位置的文档、人体工程学投入、获得各个利益相关者批准表单所需的时间和精力，都属于估算的一部分。

根据我的经验，从概念到客户批准，这个表单需要至少两天的人工。

1.6.2 验证器

验证器通常实现数据完整性规则和业务规则。数据完整性意味着数据包含可接受的字符。一个简单的例子是数值数据通常不包含非数值字符。业务规则将是验证在过程计算的值或限制规则，例如“用户每次请求不能选择超过一个资源”。因此，我定义了两个特定的验证对象来执行特定类型的验证，“业务规则”对象和“有效数据类型”对象。现在，验证可能分布在应用程序的不同层中。例如，在部署在 LAN 上的 Windows 窗体应用程序中，数据类型验证可能只发生在客户端。但业务规则通常会发生在数据库层和业务层（如果有的话）。因此，在估算“验证器”对象的投入时，请记住它可能被不同的层使用。根据表单或一组表单，可能需要开发更具体的验证器类。

我认为对于上述需求，（有效的）验证包括，

• 资源名称是必填项。
• 请求者姓名是必填项。
• 接受或拒绝资源的评估理由是必填项。
• 文本框值的长度限制。
• 日期格式和范围要正确。
• 资源类型应匹配预定义值。

根据我的经验，提供这些验证（再次）需要至少两天的人工（包括设计、编码、测试和客户批准）。

对于 1.6.1 和 1.6.2，我们已经确定了一些在开发过程中可能需要完成的工作，而我们甚至还没有完成范围界定和分析。因此，发现还有多少工作要做的情况会越来越多，而且是在更容易判断所需工作量的一个非常低的层面上。这是一种简单且不那么粗糙的估算工作量的方法。

1.7 谁可以被认为是初学者？

对于任何估算、范围界定或分析，对所有开发阶段的实际知识都起着重要作用。并且，如果一个人具有开发、设计和测试的经验，以及完成过几个端到端项目的经验，那么本文提到的步骤会更容易理解。这种方法的优势在于，即使您不知道任何行业公认的估算方法（如功能点分析），您也可以估算应用程序和模块。*而且您可以获得一石三鸟的效果，即估算、范围界定和分析可以同时进行*。将此视为成为分析师、架构师甚至项目经理的中间阶段。