《五项核心度量》笔记2-与UML有关的阐述

《五项核心度量》第三章节选。

第一阶段：初始
很好理解，在花费几百万美元之前，被提议的系统在技术上是可行的，并且有一个相关的业务实例。最初，你所拥有的只是一个大幅挥手的高级主管在说“不能将我们所有操作极好地结合到一个独立系统中去吗？”，你无法估计时间和努力。对于所需软件的规模，你没有足够的信息去做即使是粗略的估计。
首先你需要做三个准备工作：你必须将雄伟的想象分解成足够具体去研究的部分；你必须弄清楚什么是系统之内的，什么是系统之外的；你必须判断你的组织是否能生产出你粗略勾画过的系统。
在当前的技术条件下，系统在技术上可行吗？这个问题看起来发生在类似国防部、美国联邦航空局，以及其他善意的非技术型领导们做着产品速成梦的地方。这个问题也发生在新的领域，或称为“新生领域”，这些领域我们尚未完成过一个项目。在更多普通的领域里，许多应用软件的可行性是十分可靠的。只要认识到项目随后就能完成，或者开发者以前在这个应用领域工作过，那就已经足够了。那些经验让我们感到放心，因为这工作至少是切实可行的。
但是，即使一项提案在技术上是可行的，它也不一定适合此刻我们特定的组织者。我们可能缺乏这个项目必要的技能。我们的组织可能无法调动所需的资金。产品也许不能和我们公司的核心能力协调一致。我们将在第九章更深入地研究如此这类的问题。这里，图3-1说明了第一阶段在项目准备工作开始时的位置。
在第一阶段得出的几个关键结果可能会被放在可靠性度量的次要位置。即使是本阶段可能作出的对系统规模的粗略估计，也需要根据已有系统规模的相关信息做出。而据此得出的关于构造时间、努力和成本的极其粗略的估计，也包含了如何将规模度量转变成这种极其粗略的评估的知识。

第二阶段：细化
为了使标价合乎业务基础，你需要进一步增加对这个项目的了解。你需要相当精确地考虑你将要去做的事情。这就是细化阶段的目的。该阶段有三个目标：
 把需求扩展至能够设计出绝大多数架构的程度。
 设计出绝大多数架构。
 识别出风险，如果不能减轻，则确定其可能导致的额外成本。
在允许继续进行架构设计之前，你必须很好地掌握关键需求。你所建立架构的基础正是这些需求。你不必掌握在这个阶段所有的细节需求。在熟悉的领域，用它可能足以设计出一些大家知道的子系统。在不太熟悉的领域，你可能需要将架构转化为一个较低级别的结构。
对于架构的某些部分，是否会有因为理解不深刻，以致不能根据实施所需的时间和努力来估计它是否正向制定方向前进的情况呢？如果有，就必须对这些部分进行深入的探索。例如，为了保证其完成，你可能必须找到某种算法，或者甚至是亲自编写一个。为了完成项目的这一部分，你可能不得不通过完整的需求获取、分析、设计、实现、测试一个工作原型，来确定它不仅能够完成，而且能够在商业约束下完成。当然，商业约束也是某种类型的度量。
你的评估在什么时候可以算是足够好了呢？在第二阶段，你找出的关于将要实现系统的内容越多，你的规模评估将会越准确。你相应的时间和努力评估也会变得更精确。你为项目的架构、设计和风险缩减引入了两个标准：首先，它应该处于相关业务领域中通常的偏差范围之内；其次，它有成功完成的可能性。需要注意的是这两个标准都是基于度量法的。

过程进展到第二阶段，规模估计应该足以用于给出一个标价，但问题还没有完成。在管理者、客户和市场的压力下，这一阶段通常在进展到可以给出一个报价之后，就被过早地结束了。当然，对于那些在度量法方面的背景知识很少的组织，其所作的估价和由于系统知识的缺乏而做出的估价没有太大的不同。总之，他们仅仅是在猜想。对于那些使用度量法的组织，经过这一阶段的中途规模评估之后，还有一个很大的误差幅度。在这点上的时间和努力评估，还存在着相对较大的不确定性。评价这些数字导致了我们在第三阶段常见的所有问题，即在构造阶段时，时间和努力超出限度、质量低劣、甚至是取消项目。
相比于度量法而言，如果标价建立在决策者直觉的基础上，那么第二阶段无论在哪里结束都大同小异。对于那些使用了更好的评估技术和了解怎样去得出更精确的度量的组织，更重要的是在第二阶段进展到能够进行正确的规模评估。
你也许会觉得这听起来有点道理。然后，进一步你会问，“谁将为这提前的预备工作提供经费呢？”商业单位有时希望考虑将成本转移给一些其他的商业单位。在公司之间，请求报价的一方会认为它需要承担的成本应该转移给软件承包方。同样地，在一个公司内部，需要软件的部门有时会试图将规划软件的成本转移给软件开发者。如果这些微乎其微的“成就”带来了对第二阶段的忽视，最后遭受劣质软件苦果的将是使用软件的公司或部门。因此，无论谁为第二阶段提供了资金，使用软件的组织需要确保资金，以能够达到成功完成第三阶段——构造时所需时间和努力的资金需求的目的。
为了达到上述目标而对第二阶段的延长，有可能会推迟构造的开始。从心理学角度来说，这种延期很难被接受。我们都希望看到构造在进行中。人们希望计算完成的代码行。然而，当构造过早开始时，开发者将可能在不充分的估价下开展工作，也就意味着是在不充分的人员配置下的过短的时间内开展工作。那样无论在商业立场还是技术立场来说都是不好的。在构造中途，开发者意识到架构不能完全满足需求，这一十足的风险扰乱了时间进度，同时，所需的修改将会比正常情况下花费更多的费用。
降低这类问题的一个方法是保持项目边界范围的长度。不要试图提出一个五年或十年计划就能永远解决你的所有问题。太多的因素，如需求、环境、可复用的组件、硬件以及操作系统平台等，在跨越这么长的时期内必然会改变。相反，试着去建立一个你可以在其中设立很多短期计划的灵活的架构。你也许可以控制在两年时间范围内的大多数计划。其诀窍是在设计架构时，考虑其扩展性能够达到后续的发布和产品生产。
在第二阶段细化中，度量系统甚至比第一阶段更加严格。在这个阶段，根据定义，需要议定一个商业标价。标价是指导项目通过构造和迁移的最重要的度量。但标价不能就象宙斯头顶的闪电那样凭空而降。更正确地说，它通过更少的度量，比如规模、生产力水平和可靠性来建立。

第三阶段：构造
就如我们在本章开始时提到的那样，人们解决问题；而不是度量法在解决问题。然而，度量法能够帮助人解决问题。随着时间的过去，必然会有足够多的人，以及一个通过人时或人月来衡量的被称为努力的度量。必然会有足够长的时间，也就是另一个度量——时间进度，用周、月、年来衡量。此外，软件用户通常要求人们充分地解决问题——或许我们可以用一个不正式的名称“质量”来称呼这种要求。质量有很多方面，有些不能很容易地简化为一个数字。而可靠性是可以计量的，也反映了质量的其他方面的范围。可靠性以缺陷比例（或者它的倒数，指缺陷的次数）的表现方式成为第三个关键度量。
因此，商业投标暗含的时间和努力度量，提供给问题解决人员在第三阶段所需要的用来构造可接受的可靠性和质量的时间和努力。于是，度量是第三阶段成功的重要关键。
另外，度量在构造阶段扮演了第二个角色——控制。这是一个不那么讨人喜欢的词，因为没有人喜欢被控制。我们大家都愿意无拘无束的！但是记住，我们生活在一个资源有限的世界上，而控制是使我们在这些制约下安全生存的保证。
确定最初的关于努力（人月）、时间进度、以及第二阶段结束时的缺陷的评估度量，我们可以预测在构造阶段中需要消耗的努力比例和被发现缺陷的比例。我们也可以预测功能——比如代码行即将完成的比例。除了预测这些度量发生的平均比例之外，我们还可以预测超出或低于平均的波动范围。
我们现在已经设立了构造阶段关键变量的“统计控制”的标准。统计控制的意思是我们将职员的实际数量、实际生产的代码行数和每周发现的缺陷的实际数量加起来，看这些实际数字是否符合统计控制的范围。如果是，项目正在照计划执行；如果实际数超出了控制范围，它也就失去了控制，没有按计划执行，这可能是因为出了什么差错，它是寻找问题的一个信号。
在统计控制之下，每周我们都能在问题发生时发现它们。它们是最新的问题。涉及到的人还在附近。传统方式在系统测试中发现这类问题。在那个时候，项目进度只剩下很少的时间。一些人员已经离开，而其他人不再清晰地记得他们所做的，因为可能过去几个月之后才发现结果出了错。
构造阶段是软件开发的大部分工作完成的地方，也是费用最大的阶段。在这个阶段度量的重要性有两个理由：为任务提供足够的资源和时间，以及确保资源按计划利用。
不妨遐想一下空中飞行，在云层中，你的直觉是靠不住的。飞行教员教导我们“依靠你的仪器，而不是你的直觉。”我们也可以类似地说：“依靠度量法，而不是你的希望和担心。”

第四阶段：迁移
构造阶段在内部系统测试管理中结束，获得了一个被称为初始运行性能的系统状态。然而，系统还不能在使用者或客户的环境下运行。那是迁移阶段的事。这一阶段指导产品在用户的环境下运行，那可能会与内部环境有细微的差别。
从广义上讲，有两种类型的产品：一种是简易包装的产品，定位在大多数客户。开始时，卖主会选择有用户代表进行Beta测试（通常是在构造阶段的结束）。另一种产品是针对一位客户，经常是安装在一个确定的位置，有时是几个位置。客户通常会在自己的环境下进行一个验收测试。
在通常条件下，会有两种类型的反馈从用户环境中产生：
 缺陷出现，既可能是由于新的环境也可能因为在内部测试中未能发现。软件组织不得不将其纠正。在有些情况下，它们有可能会保持到下一次发布。
 软件有可能未能满足用户现在验收的要求。再次，软件组织也许能够更改系统使之适应这些要求，至少那些它能够在当前架构中迅速地添加的。在其他情况下，更改将加到第二次发布的考虑列表中。
迁移阶段需要的努力和时间总量取决于用户遇到的新需求和缺陷的程度。如果需求在早先阶段谨慎获取，如果在分析和设计期间就找用户商议，如果用户严格使用操作原型，如果他们在构造阶段早期检查工作的增量，并且如果这种导致最初的需求改变以适应要求的早期反馈能在中途发现，那么会有较少的需求在迁移阶段发生。最多的是，不管怎样，软件组织发现去评估从用户那里反馈回来的修改数量是困难的。保留在项目初期发生的记录可以作为一种建议。
如果一个项目伴有良好的审查和测试实践，系统能够达到最初的运行水平，遗留很少缺陷。无论如何，现在已有了一些评估缺陷数量的度量方法。然后，当用户在自己的环境中运行系统时，他们会逐渐地发现缺陷。用户或是系统实施人员，纠正缺陷并且修正仍然保留的评估数据。运用这个办法，就有可能在缺陷发现过程中做出一个对预期修复工作总量的粗略估计。
总而言之，不管怎样，核心度量——规模、努力、时间、生产力和缺陷率——在迁移阶段的应用要少于前面的几个阶段。以往的项目在这一阶段的经验是最好的指南。在这个基础上，软件组织能够定量地分配时间和努力量。这就能够在如此的预算下做出修正或缺陷修复，而在下一次发布或维护预算中更严格修改就能争取更多的时间。