软件应用早期的范围控制

网站制作包括设计、软件程序等，软件应用的规模很难预测，估计的结果也不是很准确。只有当需求出现时，我们才可以使用功能点度量来衡量应用程序的大小，但对于初始软件成本估算和进度计划来说已经太晚了。源代码的规模只能通过类似的应用程序来实现，如果此类应用程序确实存在的话。然而，在2008 年至2009 年间，出现了分析软件应用程序大小的新方法。如今，国际软件基准组织(ISBSG) 已经达到了一个临界质量，拥有超过5,000 个软件应用程序的历史数据，因此我们可以从ISBSG 获得类似软件应用程序规模的可靠数据。

由于许多应用程序与现有应用程序非常相似，因此从ISBSG 获取类似应用程序的比例数据已成为项目早期的标准活动。要获取的数据还包括进度和成本信息，这些信息甚至比应用程序的大小更有价值。但是，ISBSG 数据支持功能点度量而不是代码行度量。由于使用功能点度量是最佳实践，因此使用代码行数度量是不合适的。这当然不是一个糟糕的情况，但对于坚持使用代码行指标的公司来说，他们失去了使用ISBSG 指标的机会。

对于ISBSG 数据未代表的新型软件或应用程序，当前几种快速估计应用程序大小的方法可能是合适的。一种是基于模式匹配的新方法的规范，可以获取功能点、源代码的大概大小，甚至规范的页数等其他信息。在开发过程中，这种方法也可以预测需求的增长速度，但是预测需求的增长速度一直是软件项目的薄弱环节。其他估计大小的方法包括各种新的功能点近似或“轻量级”功能点分析，它们可以在短短几分钟内预测功能点大小，而不是按正常速度（每天大约400 个功能点）来预测。前期及时预估应用规模是准确预估的前提。这也是进行风险分析的前提。很多风险与应用的规模成正比，所以越早知道应用的规模，就越能得到更完整的风规模分析。

由于项目进度和成本与应用规模成正比，大型系统通常会将系统分成多个版本，几乎每12-19个月迭代一次。了解整个应用程序的大小，以及各个功能和特性的大小，我们可以指定一个有效的版本控制策略，可能涉及三个或四个连续发布。一旦了解了每次发布的大小，就可以轻松准确地估计项目的进度和成本。在获取需求之前，我们可以通过模式匹配获取应用的规模。该方法是获取软件应用的外部描述，然后根据描述匹配其他类似的应用。快速功能点法在时间上会有些出入。要准确估计应用程序的大小，至少需要获取应用程序的一些需求。