任务:计划阶段和迭代
此任务描述了如何计划项目阶段和迭代:目标是什么,持续时间为多长,有多少迭代等。
用途

此任务的目的是:

  • 估算项目总范围、总工时和总成本。
  • 制定粗略的项目计划,其重点在于产品生命周期中主要的里程碑和关键的可交付件。
  • 在项目阶段中定义一组迭代并确定每个迭代的目标。
  • 制定项目的进度安排和预算。
  • 制定项目的资源计划。
  • 定义任务以有序地完成项目。
关系
角色主要: 其他: 辅助:
输入必需: 可选:
外部:
输出
步骤
估算项目
目的 估算交付项目所需的工作量。
选择满足项目约束的最佳进度安排。 

先启阶段中,您应该为估算项目中建议的工作做准备(关于软件项目估算的一般讨论,请参阅 [BOE81]、[PUT92] 和 [MCO96])。 由于软件项目估算基于某些复杂的数学,所以在此不讨论详细的技术背景。估算遵循一个含四个步骤的流程:

  1. 估算产品大小。
  2. 估算项目的总工时和总成本
  3. 应用约束和优先级(例如,员工数目、交付日期、预算)
  4. 选择最佳的进度安排、工时和成本估算

估算产品大小

这是估算流程的关键输入。若无法估算要完成的工作量,那么制定的任何项目进度安排可能完全不符合实际。在项目早期可使用两种方法来估算软件产品大小:通过类推估算大小与通过分析估算大小。当然,项目后期(精化阶段中),您可基于更详细的项目工作分解结构为更精确的自下而上的估算做准备。

通过类推估算大小

使用“通过类推估算大小”的方法来估算项目范围时,将要开发的新产品与上一项目中开发的产品(已知大小)进行比较。应比较新旧产品的各种属性,例如业务用例的数目、参与者数目、数据库大小/复杂性以及可能的在线和批处理程序数目。

通过比较这些属性,可估算出新产品与旧产品相比的相对大小,然后使用已知的旧产品的大小来计算新产品的估算大小。记住:比较具有类似复杂性、用类似方法开发的产品是很重要的,因为诸如用例描述中的详细程度之类的因素的差异可使您的比较无效。

通过分析估算大小

在“先启”阶段后期,可能您已经收集到足够的新产品信息,因而可使用分析技术来估算产品大小。这些技术依赖于可用的软件产品的功能描述(例如,软件需求规范、软件体系结构文档),并运用标准计算规则从这些描述中确定出大小度量值。虽然已开发许多度量标准,其中包括“特性点”(对“功能点”的修改,用于实时系统应用程序)和“预测对象点”(用于面向对象系统的度量标准,基于对类复杂性和层次结构的分析),然而这些技术中最有名的可能是“功能点计算”。 

还有一些白皮书,可从 IBM Web 站点获取,它们描述基于用例的大小估算的方法。使用这些白皮书时,您应注意:要进行基于用例的初始大小估算,由于组织之间甚至组织内部的各个用例在抽象程度和表达方式上可能有很大不同,所以您必须调整用例以符合组织的用例样式。一旦进行了调整,保持使用选定的标准样式来编写用例是非常重要的,否则大小的估算值可能发生很大的错误。

估算项目的总工时和总成本

可使用确定的科学模型,从产品大小的估算值中计算出项目的总人员工时和进度安排。现今使用的两个著名模型是由 Barry Boehm 提出的“结构型成本估算模型”(COCOMO)和 Larry Putnam 的 Putnam 方法。两种模型均通过行业数据进行了验证。关于 COCOMO 的最新版本的更多信息,请参阅 COCOMOII web 站点

除大小输入之外,另一关键输入是团队生产力的度量值。该值将决定整个项目工时。整个项目的进度安排与总工时之间是非线性相关的。可惜模型在数学上是很复杂的,因此最好使用软件工具来帮助计算。

应用约束和优先级

差不多每个项目都将受到某些约束(例如,必须在某个特定日期装运,或成本不得超过 850,000 美元)或优先级(例如,需要尽快提供产品)的限制。在产品大小固定的情况下,这些约束将受到团队规模调整的影响。研究表明:团队规模和进度安排之间的关系不是线性的,因此您需要使用科学模型基于变化的团队规模,生成若干场景。自动化的估算软件在此实践中非常有用。

选择最佳的进度安排、工时和成本估算

现在,在一系列的项目场景中复审并选择最适合您的项目需求的场景。这将使您初步了解建议的项目总工期,并指示必要的团队规模和预算。

定义项目阶段里程碑
目的 定义正式评估项目进度的里程碑。
将估算的工时和成本分配给每个阶段。 

软件开发计划首先定义了主要里程碑的日期和性质(请参阅阶段)。这部分的软件开发计划用作项目的全面“指南”,在项目开始时(先启阶段)进行创建。

要计划初始开发周期中的项目阶段,您可能必须基于以下因素对里程碑做出有根据的推测:

  • 具有性质和领域相似的项目的经验。
  • 新颖程度。
  • 特定的环境约束,例如响应时间、分发和安全。
  • 组织的成熟度。

基于您对性质类似的其他项目的经验来使用估算值,通过将估算的总工时和总成本按适当比例分配到项目的每个阶段,来创建初始项目预算。

关于如何定义迭代长度和数目的更多信息,请参阅 指南:软件开发计划

定义里程碑目标
目的 定义评估各阶段的标准。 

每个里程碑都着重于一个特定的可交付件;且每个里程碑都提供了进入下一阶段的定义良好的移交点。

阶段
里程碑
目的
先启阶段  生命周期目标里程碑 向项目提交资源
精化阶段  生命周期体系结构里程碑 稳定产品的体系结构
构造阶段  初始操作能力里程碑 完成产品开发
产品发行版里程碑产品 成功部署产品

每个里程碑都代表项目必须清除的关键障碍,项目在每个里程碑都将面临一个进行/不进行的决策。

定义阶段中迭代的数目、长度和目标
目的 确定要为每个项目阶段计划的迭代数目。
确定迭代间工作的相对分配。
确定每个迭代的目标。 

一旦确定了项目阶段的长度,就需要确定迭代的数目和长度。 关于如何定义迭代长度和数目的更多信息,请参阅 指南:软件开发计划。根据项目类型、问题域和问题域的新颖程度,可应用多种迭代模式(另请参阅概念:迭代)。

每个迭代都生产一个可交付件,该发行版是用于评估进度和质量的可执行的产品。由于每个迭代的着重点不同,迭代可交付件的功能和完整性也将有所变化。迭代目标必须足够具体,以评估迭代结束时是否实施了迭代目标。在早期迭代中,通常用缓解的风险来表达目标;在后期迭代中,则依据对功能完成情况和质量的度量来表达目标。

改进里程碑日期和范围
目的 基于先启阶段结束时可用的信息,改进估算值

先启阶段结束时,可通过考虑以下因素来更准确地对各阶段作出计划:

  • 已确定的用例数目。
  • 已研究得出的用例的复杂性。
  • 已识别的技术风险和业务风险。
  • 功能点或用例度量值。
  • 任何原型的结果。

在精化阶段更新这个非常粗略的计划。它将作为构造剩余的项目计划的基础。

确定项目资源需求
目的 定义该项目所需资源(按阶段/迭代进行分配)的数目和类型。 

基于工时估算值和由此而得出的项目进度安排,您现在可定义执行项目所需的资源。对每个阶段/迭代,确定需要涉及哪些角色以及各角色的数目是多少。

制定项目收尾计划
目的 制定用于有序地终止项目的计划。 

项目收尾计划记录在软件开发计划的第 5.6 节 收尾计划中。项目收尾是为使项目有序结束而执行的一系列任务,目的是确保捕获了所有度量值和所得的经验教训,以供未来参考。

当满足以下条件时,收尾流程就开始了:

  • 在配置控制下,已完成并存储所有项目可交付件
  • 已完成验收测试,且客户已正式接受产品
  • 已将产品正式交付给客户

定义收尾任务

首先,在计划中列出在项目收尾期间要执行的任务。通常包含以下活动:

  • 项目事后会议
  • 项目事后报告的制定
  • 项目人员复审的结束
  • 项目工作产品的归档
  • 项目人员的重新分配
  • 向组织历史度量值数据库中添加项目度量值,以用于未来项目的估算。

确定收尾任务的参与者

接下来,在计划中确定每个收尾任务中涉及的个人。

定义收尾任务的进度安排

然后,定义收尾任务的进度安排。通常在项目结束时,向软件开发计划中添加该详细信息。



属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
关键注意事项

在项目规划中,项目经理实例化项目的特定交付流程(随后管理该流程的执行)(请参阅工作产品:开发流程)。这通常被称为流程制定。

“实例化”流程是可规定的项目/迭代/活动计划(它包含实际活动和实际项目的工作产品)。交付流程可以通过从 Rational Method Composer交付流程导入到 Rational Portfolio Manager(RPM)进行实例化,然后通过复制设置为 isRepeatable 或 hasMultipleOccurences 的活动和任务、创建实际的工作产品、将实际资源分配给角色等操作来进行实例化工作。

更多信息