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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Actividades de Implementación
Implementación desde el punto de vista de la arquitectura.
Integrar el sistema. Realizar las pruebas de unidad.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Actividad: Implementación
Objetivos: Identificar componentes significativos desde el punto de vista de la
arquitectura.
Mapear componentes a nodos.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Herramientas de Gestión de Versiones
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Ejemplo
Plan de builds
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Top Related