基于软件设计和开发人员测试，确定实现解决方案的策略。其基础选项是：

1. 应用已有、可重用的资产
2. 模型化设计细节并生成源代码（通过模型转换）
3. 编写源代码
4. 以上的任意组合

识别可在实现中重用的已有代码或其它实现元素。对整体设计的全面理解非常有用，因为当你对建议的解决方案有一个全面的理解时能够最好的利用可重用机会。

如果使用精细的建模工具，你可以从模型中生成部分所需的源代码。注意，在设计模型生成代码后，通常仍需要编程完成整个实现。

即使没有工具，通常仍有某些代码可以通过检查设计和开发人员测试来编写。

编写代码以使实现符合设计和预期的行为。你应该在任何可能的地方尽可能的重用和/或生成代码，但是仍需要进行某些编程工作。为此，考虑：

• 检查技术需求。因为某些需求信息不能直接转换到设计中，应该检查这些需求以保证它们被完整的实现。
• 重构代码以改善设计。重构是一项技术，通过小的、安全的变更来改善代码质量。
• 通过改善性能、用户接口、安全性以及其它非功能领域来调优已有实现的结果
• 添加遗失的细节，如完成操作的逻辑或增加支持类和数据结构
• 处理边界条件
• 处理异常情况或错误状态
• 约束行为（防止用户或客户端代码执行非法路径、场景或选项的组合）
• 为多线程或可重入代码添加关键区

尽管上面列出了许多不同的考虑，但仍有一个明确的方式判断编码何时结束。当解决方案通过了开发人员测试，则完成了其实现。一旦代码完成并验证正确后，其它任何考虑可以通过代码重构来处理。

验证实现符合其目的。检查代码是否匹配了其预期的功能。这是在测试之外的质量保证步骤。考虑以下策略：

• Pair programming. By pairing to implement the code in the first place, you effectively evaluate the code as its being written.
• 结对编程。首先通过结对来实现代码，你可以在编写时高效的评估代码。
• 通读代码寻找常见错误。考虑保留一个常犯错误的检查单，作为提示参考。
• 使用工具检查实现的错误以及不合适的代码。例如，使用静态代码规则检查工具或者设置编译器显示最详细的告警级别。
• 使用工具可视化代码。代码可视化，如在Eclipse IDE中的UML可视化，帮助开发人员识别问题，如过度耦合或循环依赖。
• 执行非正式的、有针对性的代码检视。请求同事Review小规模的关键代码。避免Review大量的代码。
• 使用测试人员来保证实现是可测试和可理解的测试资源

基于这些评估的结果改进实现。

沟通意想不到的变化对设计和需求的影响。

在实现系统时，必须和团队沟通你发现的问题和约束。在实现中发现的问题影响必须合并到未来的决策中。如果合适，使用变更管理过程来反映在实现中识别和解决的歧义，这样可以测试它们，并恰当的管理利益相关人期望。类似的，利用设计过程来更新设计以反映实现中新的约束和发现的问题，从而保证和其他开发人员沟通这些新的信息。

通常，对于小的以及由同一个人进行设计和实现的代码不需要提交变更申请，他能够直接变更设计。如果变更有着广泛的影响，需要同其他团队成员沟通此变更时，变更申请可能是必需的。