9.- Flujo de Implementación Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

9.- Flujo de 9.- Flujo de ImplementaciónImplementación

Justo N. Hidalgo SanzJusto N. Hidalgo Sanz

DEPARTAMENTO DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICAINFORMÁTICA

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

Introducción

Los objetivos de la implementación son: Planificar las integraciones del sistema requeridas en cada

iteración. El enfoque adoptado consiste en realizarlo de manera incrementalincremental, de manera que el sistema se implementa como una sucesión de pasos de tamaño manejable.

Distribuir el sistema, mapeando componentes de ejecución en los nodos.

Implementar clases y subsistemas de diseño.

Integrar los componentes y realizar las primeras pruebas de unidad.


Pasos

El arquitecto delinea los principales componentes del modelo de implementación.

El integrador de sistemas planea las integraciones de sistemas requeridas en esta iteración como una secuencia de “builds”.

Para cada “build” describe las funcionalidades esperadas y qué partes del modelo de implementación se ven afectadas.

Entonces los ingenieros de componentes crean/actualizan los componentes/subsistemas necesarios.

Los componentes se prueban juntos y se pasan al integrador de sistemas que crea el nuevo “build” y se lo pasa al equipo de pruebas de integración.


Actividades de Implementación

Implementación desde el punto de vista de la arquitectura.

Integrar el sistema. Realizar las pruebas de unidad.


Actividad: Implementación

Objetivos: Identificar componentes significativos desde el punto de vista de la

arquitectura.

Mapear componentes a nodos.


Actividad: Integrar el Sistema

Objetivos: Crear un plan de “builds” describiendo los builds para cada

iteración y los requerimientos para cada build. El objetivo aquí es que cada build sea lo suficientemente pequeño para ser manejable.

Importante: no fraccionar casos de uso. Cada build debe tratar nuevos casos de uso enteros.

Las primeras builds deben centrarse en las capas más inferiores (se va de abajo a arriba).

Integrar cada build antes de que sea sometida a las pruebas de integración. Si se ha hecho bien el plan, esto debería ser inmediato.

Tras esto, entran en ejecución las actividades de implementación de subsistemas, y clases específicas.


Herramientas de Gestión de Versiones


Actividad: Realizar las pruebas de Unidad

Objetivo: Probar los componentes implementados como unidades

individuales.

Tipos de pruebas: Pruebas de especificación. Verifican el funcionamiento desde el

punto de vista externo. Caja negra.

Pruebas de estructura. Verifican la implementación interna de la unidad. Caja blanca. Probar todos los caminos.


Modo de trabajar

Implementar es la parte que más recursos lleva en un proyecto -aunque no sea realmente la más importante-.

Es necesario por tanto tener un control exhaustivo de QUÉ se está haciendo, y CÓMO.

Para ello debemos tener un MODO DE TRABAJAR.

A continuación mostramos las características más comunes.


Convenciones (I)

Se utilizarán convenciones de codificación y documentación del código. P.e. JAVA:

Código: Java Code Conventions de SUN

Documentación: Javadoc.


Convenciones (y II)

Guías de estilo de codificación: Cabeceras Comentarios Alineación de columnas Nombres de clases Nombres de atributos Nombres de función/método Espaciado entre los paréntesis Número de líneas de código de un módulo Situación de elementos dentro de un módulo Ausencia de números en el código


Builds (I)

Sucesión de builds en una iteración: En cada iteración, para el flujo de tareas de implementación se

hará un plan de builds que tendrá que ser aprobado por el jefe de proyecto.

Se proporcionan una serie de criterios de guía para establecer las builds del plan: Se dividen los casos de uso a tratar en la iteración en grupos más

o menos relacionados. Cada grupo irá a una build.

Las primeras builds deben ocuparse de las capas más inferiores.

Cada build debería tratar casos de uso enteros, y no partes de casos de uso.


Builds (y II)

Antes de pasar al repositorio su parte de una build, el desarrollador hará las pruebas de unidad.

Una vez finalizada una build, uno de los desarrolladores asume el rol de "integrador", que es el encargado de comprobar que la build es básicamente correcta.


Lista de Defectos

Aparte de la documentación del flujo de implementación, se debe mantener también una Lista de defectos: Incluye los defectos del software relevantes en el momento actual.

Esta lista no formará parte normalmente del documento de implementación, pero este documento deberá explicar como acceder a ella.

Para cada defecto de la lista se incluirán los siguientes campos (generalmente):

•Código del defecto

•Descripción

•Responsable de solucionar el defecto (si lo hay)

•Estado actual del defecto

•Caso de prueba que ha fallado (si lo hay)

•Fecha de alta en la lista

•Fecha de solución


Ejemplo

Plan de builds


Bibliografía

Enlaces: http://java.sun.com/docs/codeconv/html/

CodeConvTOC.doc.html: convenciones de nombrado para Java.

http://java.sun.com/j2se/javadoc/writingdoccomments/: javadoc

http://root.cern.ch/root/Conventions.html: convención de nombrado de C++ del CERN.

http://www.cvshome.org: CVS.

9.- Flujo de Implementación Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

Documents

Transcript of 9.- Flujo de Implementación Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA