Understand the Task/Problem

Before starting with an implementation task, the implementer must be clear on the scope, as specified in work assignments and iteration plans. An implementation task can be focused on achieving some specific functionality (such as implementing a design use-case realization or fixing a defect) that involves implementing several design elements that contribute to that functionality. Alternatively, an implementation task can be focussed on a particular design element, such as a Design Subsystem or a Design Class, implementing it to the extent required for the current iteration.

Configure Development Environment

This task results in creating or updating one or more files (Implementation Elements). As part of preparing for implementation, the implementer must ensure that his or her development environment is correctly configured so that the right element versions are available, both the elements to be updated, and any other elements required for compilation and unit testing. The implementer must be aware of, and follow the project's configuration and change management procedures, which describe how changes are controlled and versioned, and how they are delivered for integration.

Analyze Existing Implementation

Before you implement a class from scratch, consider whether there is existing code that can be reused or adapted. Understanding where the implementation fits in to the architecture and design of the rest of the system can help the implementer identify such reuse opportunities, as well as ensuring that the implementation fits with the rest of the system.

Implement Incrementally

It is recommended that you implement incrementally; compile, link and run some regression tests a couple of times a day. It is important be aware that not all public operations, attributes and associations are defined during design.

When dealing with defects, ensure that you have fixed the problem, not the symptom; the focus should be on fixing the underlying problem in the code. Make one change at a time; because fixing faults is in itself an error-prone task, it is important to implement the fixes incrementally, to make it easy to locate where any new faults are occurring from.

The implementer must be aware of, and follow any project-specific implementation guidelines, including programming guidelines for the specific programming languages.

There are various techniques for transforming design to implementation. Here are some examples:

• Platform-specific visual models can be used to generate an initial code framework. This code framework can then be further elaborated with additional code not specified in the design.
  
• Models can be detailed, and used to generate executable prototypes. Both structure (class and package diagrams) and behavior diagrams (such as state and activity diagram) can be used to generate executable code. These prototypes can be further refined as needed.
  
• Models can also be detailed to the point where the model completely represents the implementation. In this case, rather than transform an abstract design to a code implementation, one takes the design and adds implementation details directly to the model.
  
• The design may be platform independent to varying degrees. Platform specific design models or even code can be generated via transformations that apply various rules to map high level abstractions platform specific elements. This is the focus of the Object Management Group (OMG) Model Driven Architecture (MDA) (http://www.omg.org) initiative.
  
• Standard patterns can also be applied to generate design and code elements from related design and implementation. For example, a standard transformation pattern can be applied to a data table to create java classes to access the data table. Another example is using an Eclipse Modeling Framework (http://www.eclipse.org/emf/) model to generate code for storing data that matches the model and to generate a user interface implementation for populating data.

In all cases, however, some design abstraction is detailed to become the implementation, either manually or through the application of some automated transformation.

As described in the previous step, transformation of design to implementation can result in varying degrees of completeness of implementation. It may be a complete and acceptable implementation. Typically, however, there is substantial effort to complete the implementation, for example:

• Tuning the results of transformation (for example, to improve performance, or to improve the user interface)
  
• Adding missing details, such as:
  • completing operations described in the design - choosing algorithms and writing the code.
  • adding additional supporting classes, operations, and data structure

This is where you verify that the implementation is fit for purpose.  In addition to testing (described in other tasks), some additional checks are often useful:

• Mentally read through the code. Consider keeping a checklist of common mistakes that you personally make in your implementations, and look for those mistakes.
• Use tools to check the code for errors. For example, a static code rule checker, or compiler set to detailed warning level.
• Use tools that can visualize the code. Code visualization can help an implementer identify patterns such as excessive coupling, circular dependencies, and so forth.

As designs are implemented and tested, inevitably errors are discovered, often errors that affect the design. If a design abstraction is maintained for future maintenance efforts, or for contractual or communication reasons, then the design has to be updated.

How this is done depends on the project's configuration and change management process. Generally, if the required change is small, and the same individual is designing and implementing the class, then there is no need for a formal change request. The individual can do the change in the design.

If the required change has a broad impact, for example a change in a public operation, then it may be necessary to submit a formal change request.