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 supone agregar al software la nueva funcionalidad que corresponda. Después de completar una tarea de desarrollo, debe pasar por los procesos de prueba unitaria, análisis de código e integración en la base de código existente.

En este tema

Estimación

Documentos de diseño

Revisión de diseño

Pruebas unitarias

Análisis de código

Proceso de revisión de código

Refactorizar

Integrar cambios

Estimación

Estimar el costo de las tareas de desarrollo ayuda a controlar el alcance de las características y a programar los trabajos de desarrollo. Deben completarse las estimaciones de costos de todas las tareas de desarrollo y solucionarse cualquier problema antes de la reunión de planeación de la iteración. Si el costo total de las tareas de desarrollo es superior al que se puede realizar en una iteración, se debe diferir o reasignar una tarea. Después de elegir una tarea de desarrollo, es responsabilidad del desarrollador calcular el costo de la tarea.

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

El formulario para elementos de trabajo de tarea almacena los datos en los campos y pestañas que aparecen en la siguiente ilustración:

Después de crear las tareas y realizar la estimación, 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

Los documentos de diseño deben incluir información suficiente para describir a un desarrollador cómo escribir 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 del equipo.

Considere la posibilidad de usar de patrones de diseño, diseño orientado a objetos, modelos estructurales, lenguajes de modelado, modelos de relación de entidades y otras técnicas en las directrices para el diseño que se determina para el equipo. También es buena idea documentar la razón de las decisiones clave que se tomaron. Por ejemplo, si hay un efecto significativo en el costo, la programación o el rendimiento técnico, documente lo que motivó las decisiones que causan esos efectos e incluya esa información en su diseño.

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

Revisión de diseño

Una revisión de diseño sirve 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 al principio, ya que identifican los problemas antes de que aparezcan en el código. Además, las decisiones de diseño proporcionan más ideas sobre el diseño de otros diseñadores.

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 que esté implicada o se ve afectada por el diseño debe participar en la revisión. Normalmente, podrían estar incluidos el jefe del proyecto, el jefe de desarrollo y el personal de pruebas del área de diseño. También deberían participar en la revisión los desarrolladores que pertenecen al equipo del desarrollador cuyo código se va a revisar.

Programe la reunión de revisión y distribuya los documentos de diseño con la suficiente antelación para que todos los revisores tengan tiempo para leerlos. Planee la duración de la reunión de acuerdo con la cantidad de detalles técnicos que deben revisarse.

Comprobar la calidad

Asegúrese de que el diseño es comprobable. ¿Genera código que no se puede comprobar o validar de manera razonable? Si es así, no es posible garantizar la calidad del código y el diseño debe rehacerse. Examine los documentos de diseño para detectar problemas que ocasionará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, como estándares de interfaz de operador, normas de seguridad, restricciones de producción, tolerancias del diseño o estándares de partes. Cree elementos de trabajo de error que describan los errores hallados en los documentos de diseño y asígnelos al desarrollador al cargo.

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

Se crea un elemento de trabajo de revisión para documentar los resultados de la revisión del diseño. El equipo de revisión debe decidir los siguientes pasos para el diseño, que dependen de la magnitud de los cambios necesarios. Si no es necesario realizar ningún cambio, establezca el estado del elemento de trabajo en Cerrado, establezca el motivo en Aceptado (como está) y señale en una nota que puede iniciarse la codificación del 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 se puede iniciar la codificación una vez implementados los cambios secundarios en el diseño. Si son necesarios cambios principales, establezca el estado del elemento de trabajo en Resuelto y establezca el motivo en Aceptado con cambios principales. El diseño debe rehacerse y se debe realizar otra revisión de diseño antes de que pueda iniciarse la codificación del 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 una corrección de errores. Para obtener más información, vea Haga una prueba unitaria de su código.

Análisis de código

El análisis de código comprueba el código con un conjunto de reglas que ayudan a aplicar las directrices de desarrollo. El objetivo del análisis de código es que no haya advertencias o infracciones de análisis de código. 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 bibliotecas, localización, seguridad y rendimiento.

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

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 reglas. En este caso, debe crear un conjunto básico de reglas críticas que debe pasar el código y, a continuación, ampliar el conjunto de reglas cuando se resuelvan los problemas más críticos. De este modo, el equipo puede avanzar con funcionalidad nueva al tiempo que mejora su base de código existente.

Para obtener más información, consulte 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 de código

El jefe de desarrollo debe organizar la revisión del código: identificar a los revisores, programar la revisión y enviar el código que se debe revisar a todos los revisores. Para prepararse para la revisión de código, siga estos pasos:

1. Cree un elemento de trabajo de revisión para realizar un seguimiento de las decisiones que se toman en la revisión. Si no es necesario realizar ningún cambio, establezca el estado del elemento de trabajo en Cerrado, establezca el motivo en Aceptado (como está) y señale en una nota que puede iniciarse la codificación del 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 que indica que se puede iniciar la codificación una vez implementados los cambios secundarios. Si son necesarios cambios principales, establezca el estado del elemento de trabajo en Resuelto y establezca el motivo en Aceptado con cambios principales. El diseño debe rehacerse y se debe realizar otra revisión de diseño antes de que pueda iniciarse la codificación del diseño.

2. Determine quién participará en la revisión de código. Normalmente, deben participar en la revisión, al menos, el jefe de desarrollo y el arquitecto responsable del área de código.

3. Programe una reunión de revisión con los revisores y deje tiempo suficiente para que los revisores lean y entiendan el código antes de la reunión. Planee la duración de la reunión de acuerdo con la cantidad de código que debe revisarse.

Revisión de código

Se utiliza una revisión del código para asegurarse de que el código nuevo o cambiado cumple un nivel de calidad establecido antes de integrarlo en la compilación diaria. 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 está revisando es relevante para la tarea para la que se escribió. No debe permitirse ningún cambio de código que no afecte a la funcionalidad que se implementa o corrige.
Comprobar la extensibilidad	El código está escrito de modo que se puede ampliar, si esa es la intención, o reutilizar en otras áreas del sistema. Las constantes de cadena que se utilizan en el código están correctamente colocadas en recursos que se pueden internacionalizar.
Comprobar que la complejidad del código es mínima	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	El número de rutas de acceso de ejecución está minimizado en el código que se revisa.
Comprobar la seguridad del código	Se comprueba en el código la protección de activos, los niveles de privilegios y el uso de datos en puntos de entrada.

Refactorizar código

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

Lea las notas de elemento de trabajo de revisión de código para determinar cómo va a refactorizar el código.

Aplique la refactorización incrementalmente, un cambio tras otro. Cambie el código y todas las referencias al área modificada que sean necesarias.

Realice pruebas unitarias para que el área permanezca semánticamente equivalente después de la refactorización. Corrija cualquier prueba unitaria que no funcione. Realice análisis de código y corrija las advertencias. Realice pruebas unitarias de nuevo si se realizan cambios en el código como resultado del análisis de código.

Integrar cambios

El paso final es integrar los cambios mediante su protección en el control de versiones. Antes de proteger el código, se deben realizar todas las pruebas que requiera el proceso. Para obtener más información sobre cómo comprobar los problemas del 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 con los cambios es un escenario o un requisito de calidad de servicio del que no es propietario, notifique al propietario que los cambios están completos. Establezca el elemento de trabajo de 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 con los cambios es un error, establezca el elemento de trabajo en Resuelto y asígnelo a la persona que lo creó originalmente.