You need to determine a strategy, based on the Design of the work item being worked on, for how you're going to implement it. Your fundamental options are:

1. Apply existing, reusable assets.
2. Model the design in detail and generate the source code (by model transformation).
3. Write the source code.
4. Any combination thereof.

Complete the implementation by reusing code at every opportunity.

Identify existing code or other implementation elements that you can reuse in the portion of the Implementation that you are creating or changing. A comprehensive understanding of the overall design is helpful, because it is best to leverage reuse opportunities when you have a thorough understanding of the proposed solution.

If you are using sophisticated modeling tools, you should be able to generate a portion of the required source code from the model. Note that programming is often required to complete the implementation after the design model has been transformed into code.

You should strive to reuse and/or generate code wherever possible, but you will often need to still need to do some programming. To do so, consider the following:

• Examine the requirements. Because some requirements information does not translate directly into your design you should examine the requirement(s) (potentially including both the Use Case(s) and Supporting Requirements) to ensure that they are fully realized in the implementation.
• Refactor your code to improve its design. Refactoring is a technique where you improve the quality of your code via small changes.
• Tuning the results of the existing implementation by improving performance, the user interface, security, and other nonfunctional areas.
• Adding missing details, such as completing the logic of operations or adding supporting classes and data structures
• Handling boundary conditions.
• Dealing with unusual circumstances or error states.
• Restricting behavior (preventing users from executing illegal flows, scenarios, or combinations of options).
• Adding critical sections for multi-threaded or re-entrant code.
  

Create a new Build. This might involve simply running an existing build script and/or updating an existing build script.

Verify that the implementation is fit for its purpose. Examine the code for its suitability to perform its intended function. This is a quality assurance step that you perform in addition to testing, and it is described in other tasks. Consider these strategies:

• Pair programming. By pairing to implement the code in the first place, you effectively evaluate the code as its being written.
• Read through the code for common mistakes. Consider keeping a checklist of common mistakes that you make, as a reminder reference.
• Use tools to check for implementation errors and inappropriate code. For example, use a static code rule checker or set the compiler to the most detailed warning level.
• Use tools that can visualize the code. Code visualization, such as the UML visualizations in the Eclipse IDE, help developers identify issues such as excessive coupling or circular dependencies.
• Perform informal, targeted code inspections. Ask colleagues to review small critical sections of code and code with significant churn. Avoid reviewing large sections of code.
• Use the Tester to assure the implementation is testable and understandable to testing resources.

Improve the implementation based on the results of these evaluations.

Communicate the impact of unexpected changes to the design and requirements.

The issues and constraints that you uncover when you implement the system must be communicated to the team. The impact of issues discovered during implementation must be incorporated into future decisions. If appropriate, update use cases and supporting requirements to reflect ambiguities that you identified and resolved in the implementation so they can be tested and you can manage the Stakeholder expectations appropriately. Similarly, update the design to reflect new constraints and issues uncovered during implementation to be sure that the new information is communicated to other developers.

Usually, there is no need for a change request if the required change is small and the same person is designing and implementing the class. That individual can make the design change directly. If the required change has a broad impact, such as a change in a public operation, it may be necessary to communicate that change to the other team members through a change request.