目的
|
选择一组要在迭代期间考虑的用例或场景。
选择一组在迭代期间必须处理的非功能性需求。
|
指南迭代计划
|
迭代的范围受以下四个因素的驱动:
-
项目最大的几个风险
-
系统必需的功能
-
在项目计划中分配给迭代的时间
-
阶段及其特定目标(请参阅概念:阶段)
在迭代的初始计划中,选择足够的工作以填充已经为迭代计划的时间 -
尽管允许项目经理在制定迭代计划时有余地考虑资源约束和其他战术性注意事项。显然,为先前迭代计划的但未完成的工作(由于为了满足进度安排而缩减了先前的迭代范围)通常具有高的优先级。
工作的范围也不得不受到在迭代的持续时间内为了完成该迭代可以应用的最大人员配备水平的一个明智的方法的驱动。例如,通常不可能通过将迭代所用的人数加倍来将迭代中完成的工作加倍 -
即使您有这么多人。可以有效地使用的大致成员人数由软件总大小和体系结构决定,诸如 COCOMO II 之类的估算模型(请参阅 [BOE00])可提供这些信息。
然后通过限定时间管理迭代的执行 - 也就是,对范围和质量(以发现但未纠正的缺陷表示质量)进行积极管理,以满足截止日期。
关于定义精化阶段迭代的目标,有三个主要驱动因素:
定义迭代目标的主要驱动因素是风险。您需要尽早地缓解或消除风险。这是精化阶段中的主要情况,您的大部分风险应得到缓解,但这将继续是构造中的关键元素,因为一些风险仍然很高,或者发现了新的风险。但是由于精化阶段的目标是对体系结构设置基线,我们必须开始考虑其他一些注意事项,例如确保体系结构满足了要开发的软件的所有方面(覆盖范围)。这很重要,因为体系结构将用于进一步的计划:团队的组织、要开发的代码的估算,等等。
最后,尽管关注风险很重要,您还应牢记系统的主要任务;解决所有棘手的问题很好,但解决问题时不能损害核心功能:请确保的确包含了系统的关键功能或服务(关键程度),即使未察觉到与它们相关联的风险。
从风险列表中,为危害最大的风险,识别某个用例中的某个场景,它将迫使开发团队“直面”风险。
示例
-
如果存在集成风险,例如“数据库 D 可正常用于操作系统 Y”,请确保您包含了一个场景,该场景涉及到甚至是非常普通的数据库交互。
-
如果存在性能风险,例如“到了计算工件轨道的时间”,请确保您有一个包含该计算的场景,至少对最明显最频繁的用例要包含。
对于关键程度,请确保包含系统提供的最基础的功能或服务。 从用例中选择某个场景,该场景代表系统提供的服务或功能的最常见最频繁的形式。软件体系结构文档用于驱动此工作,它提供一组排列了优先级的用例或用例的子流,这些用例或用例的子流由软件设计人员选择以反映在体系结构方面重要的用例或场景。
示例
-
对于电话交换机,单纯的站到站呼叫很显然是早期迭代的必要条件。在错误处理子系统的操作员配置中获取正确的(而非费解的)故障方式要重要得多。
对于覆盖范围,在精化阶段快要结束时,请包含涉及到您知道需要进行开发的领域的场景,尽管它们既不关键也不具有风险性。
创建详细的、端到端的场景(这些场景同时针对多个问题)通常很经济。
危险通常是使得场景过于“密集”,也就是尝试包含太多不同的方面、变体和错误用例(请参阅迭代计划)
另外,在精化阶段,请牢记:一些风险可能更多地具有人类或程序的本质(团队文化、培训、工具的选择、新技术等等),而执行迭代就能够缓解这些风险。
示例
-
在客户端工作站上创建一条要存储在服务器上的数据库中的订户记录,包括用户对话框,但未包括所有字段,并假设未检测到错误。
组合某个关键功能,这会产生一些集成风险(数据库和通信软件)和集成问题(处理 2 种不同的平台)。还要求设计人员熟悉新的 GUI 设计工具。最终生成一个可以向用户演示以获取反馈的原型。
-
确保最多可创建 20,000 名订户,且访问一名订户的时间不超过 200 毫秒。
针对一些关键性能问题(容量或数据,以及响应时间),如果不满足会显著地影响体系结构。
-
撤消订户地址的更改。
一个简单特性,它迫使设计员考虑对所有“撤消”功能的设计。这随后又可能触发用户对以下问题的反思:哪些操作能以合理的成本撤消。
-
完成所有关于供应链管理的用例。
精化阶段的目标还在于完成需求捕获,可能也是逐个组地进行。
随着项目移至构造阶段,风险仍然是一个关键驱动因素,尤其是当发现新的未知的风险时。但是用例的完整性开始成为一个驱动因素。可以逐个地为各个功能计划迭代,尝试尽早完成一些最关键的迭代,以便它们可以在多个迭代期间进行彻底测试。
在构造阶段快结束时,全部用例的健壮性将是主要目标。
示例
-
实施呼叫转移的所有变体,包括错误的变体。
这是一组相关功能。其中一个可能已在精化阶段实施,并将为剩余的开发充当原型。
-
完成除夜间服务以外的所有电话操作员功能。
另一组功能。
-
在 2 台计算机配置上,达到每小时 5,000 次事务。
这可以提升必需的性能,性能的提升是相对于在前一个迭代中实际达到的性能(只有 2,357 次/小时)
-
集成新版本的地理信息系统。
这可能是中等的体系结构变更,由于较早发现的某个问题而必须这样做。
-
修订所有级别 1 和级别 2 的缺陷
修订在先前迭代的测试中发现的缺陷,这些缺陷当时未立刻修订而延迟到现在。
完成产品的生成是主要目标。在以下方面设置迭代的目标:修订了哪些错误,包含了 哪些性能或可用性方面的改进。如果以前不得不删除(或禁用)功能以及时地到达构造的结尾(IOC 里程碑或“beta”),则现在
就可以完成或打开它们(如果它们尚未危及目前已完成的目标的话)。
示例
-
修订所有在 beta 客户站点上发现的 1 级严重性问题。
质量方面的目标可与市场可信度相关。
-
消除由于数据不匹配而产生的所有启动崩溃。
另一个表现为质量形式的目标。
-
达到每分钟 2,000 次事务。
性能调整,涉及到一些优化:数据结构更改、高速缓存和更聪明的算法。
-
将不同的对话框数目减少 30%。
通过减少视觉混乱提高可用性
-
生成德语和日语版本。
只为英语客户生成了 beta 版,因为时间不够且要减少返工。
|