COSMIC 方法 - 需求评估度量策略阶段

为什么需要一个“策略”？
需要与度量发起者商定并记录度量的目的和其他各种参数，以便将来每个人都能理解度量的规模和如何
使用。
实际上，在组织中度量不同类型的软件时，只需要确定少数几个反复出现的参数“模式”。

需要确定的五个关键策略参数
• 度量目的。目的有助于确定以下所有参数。
• 待度量软件块的范围。一个项目可能需要交付多个软件块，或者要度量的功能可能在某种程度上受
到限制。功能中包含哪些，不包含哪些。
• 待度量软件块的分解层级。例如以下这些是不同的层级：“整个应用程序”（“层级 0”），或分布式系
统的主要部件 （“层级 1”），或 SOA 架构中的可重用组件（“层级 2”）。
• 待度量软件块的功能用户。这些人或“事物”（硬件设备或其他软件块）是预期的数据发送者或接收
者。你所要度量的是他们“看到”的功能。
• 在整个软件架构中软件所处的层。待度量的软件块必须仅限于同一层。
将每次度量用到的这些参数文档化，有助于确保将来这些数据只会在“类似的”基础上进行比较和使用。

软件层级
大多数度量策略参数易于理解。但是“层”这个术语在软件行业中有不同的用法。图 5.1 展示了支持业务
应用软件的一个典型计算机系统“分层体系结构”。

应用层可以细分为其他层，这取决于软件架构师的“视图”（显而易见，也依赖于
待度量软件的功能用户）

在开始度量前，还应该考虑哪些？
可以获取到哪些软件制品作为度量的 FUR，确定这一点是非常重要的。在实际应用中，可用的制品可能
无法满足任何一种 FSM 度量所需的精确度，所以度量人员通常在推导 FUR 时必须做一些假设。最好咨
询待度量软件的需求专家，有助于理解软件，并使度量尽可能准确。
可能遇到的一些典型问题的例子：
• 如果在项目的早期就需要进行规模度量，需求可能还没有文档化，从而无法进行精准的 COSMIC 度
量。针对这种情况，我们有一个指南[7]，介绍了 COSMIC 的缩放系数，用于近似规模估算；
• 有时，软件需求定义得较为概括（宏观），而后逐渐细化（微观），我们称之为颗粒度级别。为了
确保可比性，规模度量必须在标准的“功能处理”颗粒度级别进行（请参阅以下内容）。如有需要，
可使用近似规模度量的方法来对宏观的需求进行度量并缩放至标准的颗粒度级别；
• 有时，需要度量已安装在系统中的软件规模，这些软件已不存在需求。在这种情况下，度量人员需
要从可用的制品，如屏幕、用户文档、报告、用户界面等来进行“逆向工程”，确定 FUR。

最后，度量人员可能需要估算度量一个特定软件块所需的时间。使用 COSMIC 方法度量的平均速度与
其他标准 FSM 方法度量的速度相似。而实际速率可能与这一平均值相差很大。度量所需的工作量往往
会因下列原因而增加：
• 可供度量的制品的质量非常差；
• 度量发起人所要求度量的准确性和记录的详细度非常高；
• 度量人员度量此类软件的经验缺失和 COSMIC 方法经验不足。