项目活动

为了最有效地使用 MSF for CMMI Process Improvement v5.0，您应当将您的项目组织为一系列迭代，这些迭代通常长达 4-8 个星期。 这有助于减少因要求变化而导致的项目风险，并降低实现成本。 迭代项目结构对符合 CMMI 的风险管理要求发挥着重要作用。

有关 CMMI 的更多信息，请参见 CMMI 背景信息。

项目开始

项目开始

项目开始时包括定义项目远景，以指出在项目发布其产品时用户将能执行的操作。

此外，还包括建立团队、基础结构及其他资源，并确定开发过程。

有关更多信息，请参见项目开始。

初始项目计划

项目计划包括以下活动：

• 详细分析要求，以便制定计划。 此分析可包括使用要求模型、演示图板及其他有助于设想工作系统的工具。

• 为系统设计整体设计或体系结构。 如果此活动涉及在团队成员不熟悉的平台上工作，必须留有一定的平台体验时间。 在前期迭代中，开发速度偏慢。

• 将要求强制转换为一组渐进式产品要求，可以大致估计这些产品要求的开发工作。 一般要求和产品要求的区别非常重要，因此这是一项非常重要的活动。 有关更多信息，请参见制定要求。

• 初步指派迭代的产品要求。

• 设置发布日期。

在整个项目中，将重新访问和完善计划和要求模型。 迭代开发的目的之一在于：在早期阶段改进由演示工作软件生成的要求。

初始项目计划是在迭代 0 中完成的。

有关更多信息，请参见规划项目 (CMMI)。

浏览现有产品

您的项目目标可能是更新现有产品。 此种情况下，如果团队对产品并不熟悉，迭代 0 的活动即为浏览代码。 后续迭代中的各项开发任务还将包括理解特定位置的代码和跟踪其更改结果。

有关更多信息，请参见可视化和了解代码。

项目期间

将在整个项目中对计划进行评审，并且计划可能会发生更改。

在整个项目中（通常在迭代接近尾声时），将定期执行与项目计划相关的若干活动。

验证

向您的客户或业务利益干系人演示已在迭代过程中开发的软件。 如有可能，请向他们发布该软件，使他们能够体验该软件或在实际环境中有限使用该软件。

在经过较长时间之后，请安排一次用户反馈评审会议。 这些反馈应当用于生成更改请求。

有关更多信息，请参见Validation。

风险管理

评审潜在负面事件的可能性和影响，以及为降低风险所采取的步骤。 有关更多信息，请参见管理风险。

变更管理

使用更改请求工作项可以记录对业务利益干系人指出的要求的更改。 这些更改可能由业务环境变更所致，但是也可能在演示和试用产品早期版本时产生。 这些更改应受到欢迎，这是因为它们可以根据产品的业务用途来改进产品的适用性。 此结果正是渐进式开发的目标之一。

某些项目团队在请求更改时调整产品要求工作项，而不会使用单独的工作项。 但是，更改请求工作项的优势在于：您可以在项目后期查看所做更改的数目和性质。 此信息可用于在将来改进过程或体系结构。

更改请求应用作产品计划评审的输入。

有关更多信息，请参见管理更改 (CMMI)。

产品计划评审

在计划各迭代之前进行产品计划评审。 产品计划将指派迭代的产品要求。

计划更改原因主要包括以下两个原因：

• 更改要求。

• 更改开发人员所做的估计。 随着项目的开展，开发团队可以对实现将来功能所需执行的工作进行更可靠的估计。 在某些情况下，可能已推迟早期迭代中的某些功能，这会为计划添加某个功能。

在后续迭代中，两种更改类型都会减少。

修改派生产品要求所依据的要求模型。

修改迭代的要求指派。 正如在初始计划活动中一样，业务利益干系人设定优先级，开发团队进行估计，并召开会议调整迭代之间的功能。

有关更多信息，请参见规划项目 (CMMI)。

产品主要发行版之前

产品部署过程中涉及的活动因类型而异，不会在此进行论述。

在软件开发的后续迭代过程中，请考虑以下几点：

• 拒绝对设计进行重大更改，以免可能出现不可预见的问题。

• 在会审会议中提高更改和 Bug 的门槛。 应拒绝建议的更改和 Bug 修复，除非它们对产品效用的可用性和适用性具有重大影响。

• 为扩大测试覆盖范围和执行手动测试投入相应资源。