Decida qué productos de trabajo utilizar y cómo utilizar cada uno de ellos. En la tabla siguiente se describen los
productos de trabajo que debe tener y los que se utilizan en algunos casos. Para obtener información más detallada
sobre cómo personalizar cada producto de trabajo, y una discusión de las ventajas y desventajas de este producto de
trabajo específico, lea la sección titulada "Personalización" de cada producto de trabajo.
Para cada producto de trabajo, decida cómo debe utilizarse el producto de trabajo: Debe tener, Debería tener, Puede
tener o No tendrá. Para obtener más detalles, consulte el apartado Técnica: Clasificación de productos de trabajo.
Producto de trabajo
|
Objetivo
|
Personalización (Opcional, recomendada)
|
Modelo de implementación
(Subsistema de implementación, Elemento de implementación)
|
El modelo de implementación es el código fuente, los programas ejecutables y todos los demás
productos de trabajo que se necesitan para construir y gestionar el sistema en el entorno de tiempo
de ejecución.
Una implementación está compuesta de elementos de implementación, que incluyen código (fuente,
binarios y programas ejecutables) y archivos que contienen información (por ejemplo, un archivo de
arranque o un archivo ReadMe).
Un subsistema de implementación es una recopilación de elementos de implementación y otros
subsistemas de implementación; se utiliza para estructurar el modelo de implementación dividiéndolo
en componentes más pequeños.
|
Todos los proyectos de software tienen un modelo de implementación con elementos de implementación
incluidos como programas ejecutables y código fuente mínimo.
Algunos proyectos también incluyen subsistemas, bibliotecas y modelos visuales.
Los subsistemas son útiles cuando existe un gran número de elementos de implementación que
organizar.
|
Plan de compilación de integración
|
Define el orden en el que se deben implementar los componentes, qué construcciones se deben crear al
integrar el sistema y cómo se van a valorar.
|
Opcional.
Recomendada si se debe planificar la integración. Sólo se debe omitir cuando la integración es
trivial.
|
Personalice cada producto de trabajo para que se adecue a las necesidades del proyecto. Para consideraciones sobre
personalización, consulte el apartado de Personalización de la página de descripción de los productos de trabajo, o
bien, los pasos que se describen debajo de la cabecera "Personalizar productos de trabajo por disciplina" en Tarea: Desarrollar guión de desarrollo.
Decida hasta qué punto desea realizar las pruebas de unidad y el nivel de la cobertura de código, que tiene una
escala que va de la cobertura de código informal a la cobertura de código del 100 %. Esta escala se describe en
Plan de prueba.
Con frecuencia, el nivel de cobertura de la prueba de unidad se basa en las necesidades de la integración y en los
verificadores del sistema, a los que se ha entregado el código. Los verificadores del sistema dependen de la calidad
del código para su trabajo. Si el código tiene demasiados defectos, con demasiada frecuencia la integración y los
verificadores del sistema devuelven un código a los implementadores, señal de un proceso de desarrollo inadecuado, y es
posible que la solución requiera mayor trabajo por parte de los implementadores a través de las pruebas de unidad.
Por supuesto, no puede esperar que el código de unidades probadas esté completamente libre de defectos, si bien, debe
encontrar cierto equilibrio entre la prueba de unidad y la calidad.
El nivel de cobertura de la prueba de unidad también puede diferir entre distintas fases. Incluso un proyecto crítico
para la seguridad que requiera una cobertura de código del 100 % durante la construcción y la transición, por lo
general, no lo necesita durante la elaboración, puesto que en este nivel sólo se implementan de modo parcial varias
clases.
Decida el alcance que debe tener la revisión del código.
Las ventajas de las revisiones de código son las siguientes:
-
Reforzar y promover un estilo de codificación común en el proyecto. La revisión de código es un procedimiento
eficaz para que los miembros del proyecto sigan las Directrices de programación. Para garantizarlo, lo más
importante es revisar los resultados de todos los autores e implementadores, en lugar de revisar todos los archivos
de código fuente.
-
Localizar errores que las pruebas automatizadas no encuentran. Las revisiones de código capturan los errores que no
se encuentran en la prueba.
-
Compartir el conocimiento entre personas y transferirlo de las personas con más experiencia a las personas con
menos experiencia.
Las desventajas de las revisiones de código son las siguientes:
-
Requiere tiempo y recursos.
-
Si no se lleva a cabo adecuadamente, puede resultar ineficaz. Existe el riesgo de que la revisión de código se
realice "simplemente, porque hay que hacerlo", no como un complemento eficaz de la prueba automatizada.
Para obtener más información sobre la revisión de código, consulte también Tarea: Revisión de
código.
La revisión de código añade valor al proyecto. Todos los proyectos que empiezan por medir los niveles de error y
problemas de mantenimiento relacionados con las revisiones de código afirman que mejoran el rendimiento gracias a las
revisiones. Sin embargo, en muchas organizaciones resulta difícil hacerles "despegar" por diversos motivos:
-
No se han recopilado demasiados datos para verificar si la revisión de código funciona realmente.
-
Se han recopilado demasiados datos.
-
Los implementadores protegen mucho su código.
-
Los revisores se atascan en formalidades.
-
La administración de las revisiones requiere demasiado esfuerzo.
Para aprovechar al máximo posible las revisiones de código, recuerde lo siguiente:
-
Recopile sólo los datos adecuados.
-
Mida el rendimiento de las revisiones y visualice el resultado.
-
Utilice revisiones a modo de "apoyo".
|