活动:
|
用途
|
|
角色: 实施者 | |
频率:在每个迭代过程中重复(不需要建立原型的先启迭代可能是个例外情况) | |
步骤 | |
输入的工件: | 生成的工件: |
工具向导: | |
更多信息: |
工作流程明细: |
在开始实施活动之前,实施者必须明确范围,如在工作分配和迭代计划中指定的。实施任务可侧重于实现某个特定功能(如实施设计用例实现或修正缺陷),该功能涉及实施几个设计元素,这些元素促成了该功能。或者,实施任务也可以侧重于特定的设计元素(如设计子系统或设计类),将它实施至当前迭代所需的程度。
此项活动的结果是创建或更新一个或多个文件(实施元素)。作为准备实施工作的一部分,实施者必须确保他或她的开发环境配置正确,这样就有合适的元素版本可用。对于要更新的元素以及编译和单元测试所需的任何其它元素,都必须实现这一要求。实施者必须了解并遵循项目的配置和变更管理过程。这些过程描述了如何控制变更并确定变更批次,以及如何交付变更以进行集成。
在实施某个类之前,请考虑是否可复用或改写现有的代码。如果实施者了解实施在哪些方面适合系统其余部分的体系结构和设计,将有助于实施者识别此类复用机会。这还可以确保实施适合系统的其余部分。
建议您以渐进的方式实施,每天对一些回归测试进行数次编译、链接,并运行数次。了解在设计期间并不定义所有的公共操作、属性和关联是很重要的。
处理缺陷时,请确保已修正了问题,而不是症状。应侧重于修正代码中的底层问题。请每次只做一项更改,因为修正错误本身就是一项容易出错的操作。以渐进方式实施修正是很重要的,因为这样就容易找出任何新错误的根源。
实施者必须了解并遵循任何特定于项目的实施指南,包括特定编程语言的编程指南。
可用于将设计转换到实施的技术有多种。下面是一些示例:
然而,在所有情况下,某种设计抽象概念都会手工或通过应用某种自动转换而细化,并成为实施。
如上一步中所述,从设计转换到实施可能会产生不同完成程度的实施结果。它有可能是完整的、可接受的实施。然而,通常需要通过大量的工作才能完成实施。例如:
在这种情况下您将验证实施是否符合目标。除了测试以外(在其它活动中描述),一些附加检查通常是很有用的:
实施和测试设计时,将不可避免地发现那些影响设计的错误。如果设计抽象概念因为将来的维护工作或因为合同或沟通因素而保留下来,则必须更新设计。
具体如何做要依据项目的配置和变更管理流程。通常,如果所需变更很小,并且是同一个人在设计并实施类,则不需要正式的变更请求。此人可以在设计中进行变更。
如果所需的变更有广泛的影响(例如公共业务的变更),则可能有必要提交正式的变更请求。
Rational Unified Process
|