El primer paso a realizar involucra la revisión de la documentación relacionada con los componentes a construir, esto puede incluir:

• El diseño relacionado a los componentes a construir
• Los requerimientos o casos de uso relacionados a los componentes a construir

En caso de dudas, se puede contactar al analista o a los interesados del proyecto que puedan evacuar dudas sobre la especificación de los requerimientos o los escenarios de negocio. También se puede contactar al arquitecto en caso de dudas con el diseño.

Determinar la estrategia de cómo se realizará la construcción de los componentes basada en el diseño y las pruebas.

Algunas opciones son:

• Reutilizar algún componente o código existente (y adaptarlo/configurarlo en caso de ser necesario).
• Modelar el diseño en detalle (utilizando alguna tecnología en particular) y generar el código fuente a partir del modelo (transformación del modelo). Ejemplo de tecnologías de este tipo puede ser GeneXus.
• Escribir el código fuente en algún lenguaje de programación en particular.
• Cualquier combinación de las opciones anteriores.

Para el caso de que se estén utilizando herramientas de modelado sofisticadas (como GeneXus por ejemplo), una parte del código fuente podrá ser generado a partir del modelo. Dependiendo de la herramienta de modelado, puede pasar que para completar la implementación sea necesario escribir algo de código luego de la transformación del modelo.

Para el caso en que se tenga que escribir código fuente, éste se deberá ajustar al diseño y al comportamiento esperado. Se debe intentar reutilizar y/o generar código automáticamente siempre que sea posible. Sin embargo, para completar la implementación generalmente va a ser necesario escribir algo de código. En tal caso, considerar los siguientes puntos:

• Revisar los requerimientos relacionados. Debido a que la información de algunos requerimientos no se traduce directamente al diseño, se deben revisar los requerimientos para asegurarse de que los mismos se satisfagan en la implementación.
• Refactorizar el código para mejorar su diseño interno. La refactorización es una técnica en la que se mejora la calidad del código mediante pequeños cambios seguros. Estos cambios no cambian el comportamiento o funcionalidad del componente, pero facilitan su comprensión y futura evolución/mantenimiento.
• Mejorar los resultados de la implementación existentes como ser el rendimiento, la interfaz de usuario, la seguridad y otros aspectos no funcionales.
• Agregar detalles faltantes, como ser: completar la lógica de operaciones/métodos, agregar clases de soporte y estructuras de datos.
• Manejar las condiciones de borde (ya sea casos de éxito o de error).
• Mejorar el tratamiento de circunstancias inusuales o estados de error.
• Restringir el comportamiento (evitando que los usuarios o el código del cliente ejecuten flujos, escenarios o combinaciones de opciones no permitidas).
• Agregare secciones críticas para código multihilo o reentrante.

Aunque los puntos anteriores enumeran muchas consideraciones diferentes, hay una manera clara de saber cuándo se el código fuente está terminado: la implementación está completa cuando pasa las pruebas de desarrollo. Cualquier otra consideración puede ser tenida en cuenta en una instancia de refactorización sobre el código para mejorarlo posteriormente a estar completo y correcto. Sin embargo, el costo de mejorar y refactorizar el código una vez que ya forma parte de la solución es mucho mayor que al momento de escribirlo por primera vez.

Verificar que la implementación realizada se adecue a su propósito.

Revisar el código para determinar la idoneidad con la cual realiza su función prevista. Este es un paso de aseguramiento de la calidad que realiza adicionalmente al de las pruebas de desarrollo.

Considerar las siguientes estrategias:

• Programación por pares. Al implementar el código en conjunto con otro desarrollador, el código se evalúa efectivamente a medida que se escribe.
• Revisar el código buscando errores comunes. Se puede utilizar una lista de verificación (checklist) con los errores más comunes que el desarrollador comete como referencia.
• Usar herramientas para verificar errores de implementación y código inapropiado. Por ejemplo, un analizador de código estático o configurar el compilador al nivel de advertencia (warning) más detallado.
• Usar herramientas que puedan visualizar el código. Por ejemplo, las visualizaciones UML en el IDE de Eclipse, ayuda a los desarrolladores a identificar problemas de alto acoplamiento o dependencias circulares.
• Realizar inspecciones de código informales y específicas. Una buena práctica es pedir a sus compañeros de equipo que revisen pequeñas partes críticas del código o código "entreverado". Evitar revisar grandes partes de código.
• Trabajar en conjunto con los probadores de software (testers) para asegurarse de que la implementación sea comprobable y comprensible para los recursos de prueba.
• Mejorar la implementación en función de los resultados de estas evaluaciones.

Comunicar el impacto que pudieran tener cambios inesperados en el diseño o en los requerimientos.

Los problemas y limitaciones que se descubran al momento de implementar los componentes deben ser comunicados al equipo. El impacto de los problemas descubiertos durante la implementación debe ser incorporado en las decisiones futuras.

Actualizar los requerimientos (en caso de que corresponda) para reflejar las ambigüedades que se hayan identificado y resuelto en la implementación para que puedan probarse correctamente y se puedan gestionar las expectativas de las partes interesadas adecuadamente. De la misma forma, actualizar el diseño para reflejar las nuevas restricciones y problemas descubiertos durante la implementación para asegurarse de que la nueva información se comunique a otros desarrolladores.

Por lo general, no es necesario realizar una solicitud de cambio si el cambio requerido es menor y es la misma persona quien está diseñando e implementando el/los componente(s) de código. Si el cambio requerido tiene un impacto no despreciable, puede ser necesario comunicar ese cambio al resto de los miembros del equipo a través de una solicitud de cambio.