Contenido

4) Flujo de trabajo Implementación .......................................................................................... 1

4.1 Definir y diseñar las actividades y participantes (PUDS) .................................................. 1
4.1.1 Participantes ................................................................................................................ 1
4.1.2 Actividades ................................................................................................................... 4
4.2 UML .................................................................................................................................... 8
4.2.1 Diagramas de componentes ......................................................................................... 8
4.2.2 Diagramas despliegue................................................................................................... 9
5) Flujo de trabajo Prueba ....................................................................................................... 12
5.1 Definir y especificar los participantes y actividades del flujo de trabajo prueba. ............ 12
5.1.1 Participantes .............................................................................................................. 12
5.1.2 Actividades ................................................................................................................. 13

4) Flujo de trabajo Implementación

4.1 Definir y diseñar las actividades y participantes (PUDS)

4.1.1 Participantes
a) Arquitecto
El arquitecto es responsable de la integridad del modelo de implementación y asegura
que el modelo como un todo es correcto, completo y legible. Como en el análisis y el
diseño, para sistemas grandes y complejos puede introducirse un trabajador adicional
para asumir la responsabilidad del subsistema de nivel más alto del modelo de
implementación.
El modelo es correcto cuando implementa las funcionalidades descritas en el modelo de
diseño y en los requisitos adicionales.
Es también responsable de la arquitectura del modelo de implementación, es decir, de la
existencia de sus partes significativas arquitectónicamente como se representó en la
vista de la arquitectura del sistema.
No es responsable del desarrollo en marcha ni del mantenimiento de los diversos
artefactos en el modelo de implementación.
b) Integrador de sistemas
La integración del sistema está más allá del ámbito de cada ingeniero de componentes
individual. Por lo contrario, esta es responsabilidad del integrador de sistemas. Entre sus
responsabilidades se incluye el planificar la secuencia de construcciones necesarias en
cada iteración.
c) Ingeniero de componentes

Define y mantiene el código fuente de uno o varios componentes garantizando que cada
componente implementa la funcionalidad correcta.
También mantiene la integridad de uno o varios subsistemas de implementación. Ya
que los subsistemas de implementación siguen la traza uno a uno a los subsistemas de
diseño.
El ingeniero de componentes necesita garantizar que los componentes de los
subsistemas de implementación son correctos, que sus dependencias con otros
subsistemas o interfaces son correctas.

4.1.2 Actividades
a) Implementación de arquitectura
 La identificación de los componentes significativos arquitectónicamente, tales
como componentes ejecutables.

A menudo resulta práctico identificar pronto en el ciclo de vida del software los
componentes significativos arquitectónicamente, para iniciar así el trabajo de
implementación.
Para identificar los componentes ejecutables que puedan ser desplegados sobre los
nodos, consideramos las clases activas encontradas durante el diseño y asignamos un
componente ejecutable para cada clase activa, denotando así un proceso pesado.

 La asignación de componentes a los nodos en las configuraciones de redes

relevantes.
La asignación de componentes a nodo es muy importante para la arquitectura del
sistema, y debería ser representada en una vista de la arquitectura del modelo de
despliegue.
b) Integrar el sistema
Los objetivos son:
 Crear un plan de integración de construcciones que describa las construcciones
necesarias en una iteración y los requisitos de cada construcción.
 Integrar cada construcción antes de que sea sometida a pruebas de integración.

c) Implementar un subsistema
El propósito es el asegurar que un subsistema cumple su papel en cada construcción, tal
y como se especifica en el plan de integración de la construcción.
Esto quiere decir que se asegura que los requisitos implementados en la construcción y
aquellos que afectan al subsistema son implementados correctamente por componentes
o por otros subsistemas (recursivamente) dentro del subsistema.
 Cada clase en el correspondiente subsistema de diseño que es necesaria en la
construcción actual debería ser implementada mediante componentes en el
subsistema de implementación.

Ejemplo de un subsistema que proporciona una interfaz

El subsistema Gestión de facturas de comprador necesita proporcionar la interfaz
Factura en la construcción actual. El ingeniero de componentes responsable del
subsistema decide entonces dejar que el componente Procesamiento de facturas
implemente dicha interfaz.
Dada esta situación, los ingenieros de componentes pueden empezar a implementar lo
que es requerido por los componentes dentro del subsistema, El sistema resultante se
pasa entonces al integrador de sistemas para su integración.
d) Implementar una clase
El propósito es implementar una clase de diseño en su componente fichero.

 Esbozo de un componente fichero que contendrá el código fuente.

 Generación de código fuente a partir de la clase diseño y de las mismas
relaciones en que participa.
 Comprobación de que el componente proporciona las mismas interfaces que la
clase de diseño.
e) Realizar prueba de unidad
El propósito de realizar prueba de unidad es probar los componentes implementados
como unidades individuales.
 La prueba de especificación o “Prueba de caja negra’, que verifica el
comportamiento de la unidad observable externamente.
 La prueba de estructura o “Prueba de caja blanca”, que verifica la
implementación interna de la unidad.
4.2 UML
4.2.1 Diagramas de componentes
Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de
Modelado.
Un diagrama de componentes representa cómo un sistema de software es dividido en
componentes y muestra las dependencias entre estos componentes. Los componentes
físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o
paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de
software pero pueden ser usados para modelar y documentar cualquier arquitectura de
sistema.
Debido a que los diagramas de componentes son más parecidos a los diagramas de
casos de usos, éstos son utilizados para modelar la vista estática y dinámica de un
sistema. Muestra la organización y las dependencias entre un conjunto de componentes.
No es necesario que un diagrama incluya todos los componentes del sistema,
normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte
del sistema.
Uno de los usos principales es que puede servir para ver qué componentes pueden
compartirse entre sistemas o entre diferentes partes de un sistema.
4.2.2 Diagramas despliegue
Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un
sistema. Esto muestra la configuración de los elementos de hardware (nodos) y muestra
cómo los elementos y artefactos del software se trazan en esos nodos.
 Nodo
Un Nodo es un elemento de hardware o software. Esto se muestra con la forma de una
caja en tres dimensiones, como a continuación.

 Instancia de Nodo
Una instancia de nodo se puede mostrar en un diagrama. Una instancia se puede
distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos
puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre antes de
los dos puntos. El siguiente diagrama muestra una instancia nombrada de una
computadora.

 Estereotipo de Nodo
Un número de estereotipos estándar se proveen para los nodos, nombrados «cdrom»,
«cd-rom», «computer», «disk array», «pc», «pc client», «pc server», «secure», «server»,
«storage», «unix server», «user pc». Estos mostrarán un icono apropiado en la esquina
derecha arriba del símbolo nodo.
  Artefacto
Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los
modelos del proceso (e.g. modelos de Casos de Uso, modelos de Diseño, etc.), archivos
fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de
usuario y más.
Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el
estereotipo «artifact» y un icono de documento, como a continuación.

 Asociación
En el contexto del diagrama de despliegue, una asociación representa una ruta de
comunicación entre los nodos. El siguiente diagrama muestra un diagrama de
despliegue para una red, mostrando los protocolos de red como estereotipos y también
mostrando multiplicidades en los extremos de la asociación.
  Nodo como contenedor
Un nodo puede contener otros elementos, como componentes o artefactos. El siguiente
diagrama muestra un diagrama de despliegue para una parte del sistema embebido y
muestra un artefacto ejecutable como contenido por el nodo madre (motherboard).
5) Flujo de trabajo Prueba
5.1 Definir y especificar los participantes y actividades del flujo de trabajo
prueba.

5.1.1 Participantes
a) Ingeniero de pruebas
Es responsable de la integridad del modelo de pruebas, asegurando que el modelo
cumple con su propósito. Los diseñadores de pruebas también planean las pruebas, lo
que significa que deciden los objetivos de prueba apropiados y la planificación de las
pruebas.

b) Ingeniero de pruebas de integración

Son los responsables de realizar las pruebas de integración que se necesitan para cada
construcción producida por el flujo de trabajo de la implementación. Las pruebas de
integración se realizan se realizan para verificar que los componentes integrados de una
construcción funcionan correctamente juntos.
c) Ingeniero de pruebas de sistema
Un ingeniero de pruebas de sistema es responsable de realizar las pruebas de sistemas
necesarias sobre una construcción que muestra el ejecutable de una iteración completa.
Se encarga de documentar los defectos en los resultados de pruebas de sistema.
d) Ingeniero de componentes
Son responsables de los componentes de pruebas que automatizan algunos de los
procedimientos de prueba. Esto es así por que la creación de dichos componentes puede
necesitar de substanciales habilidades como programador.

5.1.2 Actividades
a) Planificar prueba
 Describir una estrategia de prueba.
 Estimando los requisitos para el esfuerzo de la prueba ejemplo: los recursos
humanos y sistemas necesarios.
 Planificando el esfuerzo de la prueba.
b) Diseñar prueba
Propósitos:
 Identificar y describir los casos de prueba para cada construcción.
 Identificar y estructurar los procedimientos de prueba especificando como
realizar los casos de prueba.

c) Implementar prueba
Su propósito es automatizar los procedimientos de prueba creando componentes de
prueba si esto es posible, pues no todos los procedimientos de prueba pueden ser
automatizados.
d) Realizar prueba de integración
Pasos:
1. Realizar las pruebas de integración relevantes a la construcción realizando los
procedimientos manualmente para cada caso de prueba o ejecutando cualquier
componente de prueba que automatice los procedimientos de prueba.
2. Comparar los resultados de las pruebas con los resultados esperados e investigar
los resultados de las pruebas que no coinciden con los esperados.
3. Informar de los defectos a los ingenieros de componentes responsables de los
componentes que se encuentran los fallos.
4. Informar los defectos a los diseñadores de prueba, quienes usaran los defectos
para evaluar los resultados del esfuerzo de prueba.
e) Realizar prueba de sistema
Pueden empezar cuando las pruebas de integración indican que el sistema satisface los
objetivos de calidad de integración fijados en el plan de prueba de la iteración actual.
La prueba de sistema se realiza de forma análoga a la forma en que se realiza la prueba
de integración.

f) Evaluar prueba
Se observan dos métricas por parte del ingeniero de pruebas.
 Compleción de la prueba, obtenida a partir de la cobertura de los casos de
prueba y de la cobertura de los componentes probados. Esta métrica indica el
porcentaje de casos de prueba que han sido ejecutados y el porcentaje de código
que ha sido probado.
 Fiabilidad, la cual se basa en el análisis de las tendencias en los defectos
detectados y en las tendencias en las pruebas que se ejecutan con el resultado
esperado.
5.1.3 Caso prueba
Especifica una forma de probar el sistema, incluyendo la entrada o resultado con lo que
se ha de probar y las condiciones bajo las que ha de probarse.

5.1.4 Procedimiento de prueba

Especifica cómo realizar uno a varios casos de pruebas o partes de estos. Ejemplo un
procedimiento de prueba puede ser una instrucción para un individuo sobre cómo ha de
realizar una caso de prueba manualmente, o puede ser una especificación de como
interaccionar manualmente con una herramienta de automatización de pruebas para
crear componentes ejecutables de prueba.