Implementar tareas de desarrollo

Una tarea de desarrollo es una pequeña parte del trabajo de desarrollo que proviene de un requisito. Implementar una tarea de desarrollo implica agregar la nueva funcionalidad adecuada al software. Después de completar una tarea de desarrollo, se debería revisar, realizar una prueba unitaria, analizar su código e integrarla en la base de código existente.

En este tema

Estimación

Documentos de diseño

Revisión del diseño

Pruebas unitarias

Análisis de código

Proceso de revisión del código

Refactorizar

Integrar los cambios

Estimación

Estimar el costo de las tareas de desarrollo, ayuda a controlar el ámbito de las características y a programar el trabajo de desarrollo. Se deben realizar estimaciones de costo de todas las tareas de desarrollo y se debería resolver cualquier problema antes de la reunión de planeación de la iteración. Si el costo total de las tareas de desarrollo es mayor del que se puede gastar en una iteración, una tarea se debe diferir o reasignar. Una vez elegida una tarea de desarrollo, es responsabilidad del desarrollador calcular el costo de la tarea.

Cree un elemento de trabajo de tarea para cada tarea de desarrollo elegida y vincúlelo al requisito a partir del que se creó. Esto se realiza en la pestaña Implementación en la tarea o el elemento de trabajo del requisito. Base sus estimaciones en el tiempo necesario para completar tareas similares, y asegúrese de factorizar en el costo de escribir las pruebas unitarias. Para cada tarea, especifique la estimación en el campo Estimación original del elemento de trabajo de la tarea.

El formulario de los elementos de trabajo de tarea almacena los datos en los campos y pestañas que se muestran en las ilustraciones siguientes:

Una vez creadas y estimadas las tareas, utilice la consulta Desglose del trabajo para ver el desglose de todos sus requisitos y tareas. Para obtener más información, vea Consultas compartidas (CMMI).

Documentos de diseño

Sus documentos de diseño deberían incluir suficiente información para describir a un desarrollador cómo escribir el código para implementar el requisito en el producto.

Los documentos de diseño pueden ser una colección de especificaciones, elementos de trabajo de requisito y otros documentos, dependiendo del proceso de equipo.

Considere el uso de modelos de diseño, diseño orientado a objetos, modelos estructurales, lenguajes de modelado, modelos de relación entre entidades y otras técnicas en las instrucciones del diseño que se determina para el equipo. También es una buena idea documentar la razón de las decisiones clave que se tomaron. Por ejemplo, si tiene un efecto significativo sobre el costo, programación o rendimiento técnico, documente el motivo de las decisiones que produjeron estos efectos e incluya dicha información en el diseño.

Después de crear los documentos de diseño necesarios, almacénelos donde los miembros del equipo puedan compartirlos. Para obtener más información, vea Administrar documentos y bibliotecas de documentos.

Revisión del diseño

Una revisión del diseño se utiliza para asegurarse de que el diseño nuevo o revisado es técnicamente preciso, completo, comprobable y de alta calidad, y de que implementa el requisito correctamente. Las revisiones del diseño son un método clave para garantizar la calidad de antemano, identificando los problemas antes de aparezcan en el código. Las revisiones del diseño también proporcionan una visión adicional sobre el diseño de otros desarrolladores.

El desarrollador responsable de crear el diseño debería organizar la revisión del diseño identificando los revisores, programando la revisión y distribuyendo el diseño a todos los revisores.

Cualquier parte interesada que esté implicada o se vea afectada por el diseño debería participar en la revisión. Normalmente, esto podría incluir al jefe de proyecto, el jefe de desarrollo y el evaluador del área de diseño. Todos los desarrolladores que pertenezcan al mismo equipo que el desarrollador cuyo código se revisa también deberían participar en la revisión.

Programe la reunión de revisión y distribuya los documentos de diseño con suficiente antelación para que cada revisor tenga tiempo de leerlos. Planee la duración de la reunión de revisión para que se corresponda a la cantidad de detalles técnicos que se deben revisar.

Comprobar la calidad

Asegúrese de que el diseño es comprobable. ¿Compila código que no se puede comprobar o validar de manera razonable? En ese caso, no puede asegurar la calidad del código y se debería rehacer el diseño. Examine los documentos de diseño para identificar los problemas que provocarán errores de código. Busque descripciones de interfaz incorrectas, errores de diseño o nomenclatura confusa. Compare los documentos de diseño con los criterios existentes, por ejemplo las normas de la interfaz del operador, normas de seguridad, restricciones de producción, tolerancias del diseño o normas de los elementos. Cree elementos de trabajo de error que describan cualquier defecto que se encuentre en los documentos de diseño, y asígnelos al desarrollador pertinente.

Crear un elemento de trabajo de revisión para el diseño

Un elemento de trabajo de revisión se crea para documentar los resultados de la revisión del diseño. El equipo de revisión debe decidir los siguientes pasos del diseño, lo cual depende de la magnitud de los cambios necesarios. Si no es necesario ningún cambio, establezca el Estado del elemento de trabajo en Cerrado, establezca el Motivo en Aceptado (como está), y tenga en cuenta que la codificación puede empezar en el diseño. Si son necesarios cambios leves, establezca el Estado del elemento de trabajo en Resuelto y establezca el Motivo en Aceptado con cambios secundarios. Esto indica que la codificación se puede iniciar una vez implementados en el diseño los cambios secundarios. Si son necesarios cambios sustanciales, establezca el Estado del elemento de trabajo en Resuelto y establezca el Motivo en Aceptado con cambios principales. El diseño debe rehacerse y pasar otra revisión antes de iniciar la codificación en el diseño.

Pruebas unitarias

Las pruebas unitarias comprueban la implementación correcta de una unidad de código. Escribir y realizar pruebas unitarias identifica los errores antes de que se inicien las pruebas y, por consiguiente, ayuda a reducir el costo del control de calidad. Los desarrolladores deben escribir pruebas unitarias para todo el código que se escribirá como parte de la implementación de una tarea de desarrollo o de corregir un error. Para obtener más información, vea Comprobar código utilizando pruebas unitarias.

Análisis de código

El análisis de código comprueba el código respecto a un conjunto de reglas que ayudan a aplicar las instrucciones de desarrollo. El objetivo del análisis de código es que no se produzca ninguna infracción del análisis de código o advertencia. El análisis de código puede inspeccionar el código buscando más de 200 posibles problemas en convenciones de nomenclatura, diseño de la biblioteca, localización, seguridad y rendimiento.

Si empieza a ejecutar el análisis de código al principio del ciclo de desarrollo, puede minimizar las infracciones y advertencias de forma continuada.

Sin embargo, si ejecuta el análisis de código en código existente que no se ha comprobado antes, puede tener muchas infracciones de las reglas. Si este es el caso, puede que desee crear un conjunto de línea base de reglas críticas que el código debe pasar y, a continuación, expandir el conjunto de reglas cuando se resuelvan los problemas más críticos. De este modo, un equipo puede avanzar en nueva funcionalidad cuando mejore la base de código existente.

Para obtener más información, vea Analizar la calidad de la aplicación mediante herramientas de análisis del código y Mejorar la calidad del código con directivas de protección de equipo.

Proceso de revisión del código

El jefe de desarrollo debería organizar la revisión del código identificando los revisores, programando la revisión del código y enviando el código para su revisión a todos los revisores. Para prepararse para la revisión del código, siga estos pasos:

1. Cree un elemento de trabajo de revisión para realizar el seguimiento de las decisiones que se toman en la revisión. Si no es necesario ningún cambio, establezca el Estado del elemento de trabajo en Cerrado, establezca el Motivo en Aceptado (como está), y tenga en cuenta que la codificación puede empezar en el diseño. Si son necesarios cambios leves, establezca el Estado del elemento de trabajo en Resuelto y establezca el Motivo en Aceptado con cambios secundarios, lo cual indica que se puede iniciar la codificación una vez implementados los cambios secundarios. Si son necesarios cambios sustanciales, establezca el Estado del elemento de trabajo en Resuelto y establezca el Motivo en Aceptado con cambios principales. El diseño debe rehacerse y pasar otra revisión antes de iniciar la codificación en el diseño.

2. Determine quién participará en la revisión del código. Normalmente, por lo menos el jefe de desarrollo y el arquitecto responsable del área de código deberían participar en la revisión.

3. Programe una reunión de revisión con los revisores, y conceda tiempo suficiente para que cada revisor lea y entienda el código antes de la reunión. Planee la duración de la reunión de revisión para que se corresponda a la cantidad de código que se debe revisar.

Revisión del código

Una revisión del código se utiliza para asegurarse de que el código nuevo o cambiado cumple un nivel de calidad establecido antes de integrarse en la compilación cotidiana. Las consideraciones de calidad son normas de codificación, conformidad con la arquitectura y el diseño, rendimiento, legibilidad y seguridad. Las revisiones del código también proporcionan la visión adicional de otros desarrolladores sobre cómo se debería escribir el código.

Comprobar la relevancia del código	El código que se revisa es relevante para la tarea para la que se escribe el código. No se debería permitir ningún cambio de código que no esté relacionado con la funcionalidad que se implementa o corrige.
Comprobar la extensibilidad	El código se escribe para que se pueda extender, si esa es la intención, o reutilizar en otras áreas del sistema. Las constantes de cadena que se utilizan en el código se colocan correctamente en los recursos que se pueden internacionalizar.
Comprobar la complejidad del código mínimo	El código repetido se puede simplificar en funciones comunes. La funcionalidad similar se coloca en un procedimiento o función común.
Comprobar la complejidad algorítmica	Se minimiza el número de rutas de acceso de ejecución en el código que se revisa.
Comprobar la seguridad del código	En el código se comprueba la protección de activos, los niveles de privilegio y el uso de datos en los puntos de entrada.

Refactorizar el código

El código se refactoriza cuando una revisión del código ha determinado que se deben realizar cambios para mejorar la calidad, rendimiento o arquitectura del código.

Lea las notas del elemento de trabajo de revisión del código para determinar cómo se refactorizará el código.

Aplique la refactorización incrementalmente, un cambio cada vez. Cambie el código y todas las referencias al área modificada como sea necesario.

Realice las pruebas unitarias para que el área siga siendo equivalente semánticamente después de la refactorización. Corrija cualquier prueba unitaria que no funcione. Realice el análisis de código y solucione cualquier advertencia. Efectúe las pruebas unitarias de nuevo si los cambios del código se realizan como resultado del análisis de código.

Integrar los cambios

El paso final es integrar los cambios protegiéndolos en el control de versiones. Antes de proteger el código, se debería realizar cualquier prueba necesaria para el proceso. Para obtener más información sobre cómo comprobar si existen problemas en el código antes de protegerlo, vea Mejorar la calidad del código con directivas de protección de equipo.

Si el elemento de trabajo que está asociado a los cambios es un escenario o un requisito de calidad del servicio del que no es propietario, notifique al propietario que se han completado los cambios. Establezca el elemento de trabajo de la tarea en Resuelto y asígnelo a uno de los evaluadores que crearon los casos de prueba para el elemento de trabajo.

Si el elemento de trabajo que está asociado a los cambios es un error, establezca el elemento de trabajo del error en Resuelto y asígnelo al rol original que lo creó.