Módulo 4.

Disciplina de implementación y prueba

En este cuarto módulo comenzamos con el resultado del análisis y diseño y daremos inicio a la implementación y las pruebas y donde
conoceremos los artefactos que se construirán para ambas disciplinas, los responsables de su construcción, la forma de construirlos y
las actividades concernientes dentro de cada disciplina.

Video de inmersión

Unidad 4.1. Disciplina de implementación

Unidad 4.2. Disciplina de prueba

Video de habilidades

Cierre

Referencias

Descargá la lectura
Lección 1 de 7

Video de inmersión

You have been temporarily

blocked
Pardon the inconvenience, but our servers have detected a high
number of errors from your connection. To continue, please verify
that you are a human:

I'm not a robot

reCAPTCHA
Privacy - Terms
Lección 2 de 7

Unidad 4.1. Disciplina de implementación

4.1.1 Introducción a la implementación

Como su nombre lo indica, el propósito fundamental de esta es la implementación del sistema de información que hemos definido en la etapa de requisitos y
refinado en la etapa de diseño. Por eso, en esta etapa implementamos el resultado del diseño en términos de componentes de software, componentes
ejecutables, componentes basados en código fuente, script, etcétera.

Si bien la implementación comienza en la fase de elaboración, con la idea de crear una línea base ejecutable de la arquitectura, es en la etapa de
construcción donde se centrará la implementación en los ciclos de iteración de construcción, ya que el objetivo de dicha fase es tener un sistema desarrollado
y operativo para el usuario final.

Recordá que el sistema unificado es un proceso iterativo e incremental; cada incremento se irá añadiendo a nuestro sistema de información para aportarle
funcionalidad y liberar versiones estables y parciales del sistema de información.

Los objetivos de la implementación son: la distribución de los ejecutables a los nodos del sistema de información, la planificación del momento en el que se
realizará esa distribución y la verificación de las integraciones que son requeridas cuando se realiza una implementación, ya que una implementación podría
tener dependencia con algún componente de software.

4.1.2 Artefactos de la implementación

1 Interfaz

Los artefactos de interfaz son utilizados para especificar las operaciones que deben implementar los componentes. Las interfaces especifican qué hacer, pero
no implementan esa funcionalidad, sino que su funcionalidad será implementada en las clases que implementan dichas interfaces.

A continuación, podrás ver el siguiente video para obtener una explicación más clara acerca del concepto abordado.

Interfaces en Java (Programación orientada a objetos)

 2 Componente

Un componente es un empaquetado físico de elementos de un modelo. Ejemplifiquemos esto con el sistema de postulantes: en una iteración hemos
producido un incremento en el software. Seguramente el equipo de desarrollo ha agregado funcionalidad creando una tabla nueva en la base de datos, en las
clases del sistema se han agregado métodos nuevos a los existentes, se han añadido clases nuevas y librerías nuevas que nos han ayudado a extender
nuestra funcionalidad, etcétera. Todo este trabajo se empaqueta para su distribución e implementación. El empaquetado representa un componente y, al ser
un agregado de desarrollo, tienen fuerte dependencia entre sí.

3 Subsistema de implementación

Los subsistemas de implementación nos ayudan a organizar los artefactos del modelo de implementación en fragmentos más manipulables.

Un subsistema puede estar compuesto por componentes e interfaces. ¿Cuál sería un ejemplo de subsistema de implementación? Un proyecto en Python, un
paquete de Java, librerías, etcétera. Los subsistemas del diseño tienen relación con los subsistemas de implementación.

Figura 1. Ejemplo de trazabilidad entre el subsistema de diseño y el de implementación

Fuente: elaboración propia.

4 Modelo de implementación
El modelo de implementación representa la estructuración física de la implementación en términos de subsistemas y componentes. Este nos permite
visualizar cómo se relaciona con otros componentes y subsistemas y cómo se organizan estos.

5 Descripción de la arquitectura

La descripción de la arquitectura nos provee la visión arquitectónica del modelo de implementación. Resulta de interés describir el modelo de implementación
en términos de subsistemas, interfaces, relaciones entre ellos y con la trazabilidad a las clases del diseño.

6 Plan de integración

El plan de integración describe, en cada construcción realizada en cada iteración, la funcionalidad que se espera implementar (listando los casos de uso) y las
partes del modelo afectadas (subsistema, componentes, etc.).

4.1.3 Roles en la implementación

Tabla 1. Artefactos por roles

Rol Artefacto por construir

Modelo de implementación
Arquitecto Modelo de despliegue
Descripción de la arquitectura

Integrador de sistemas Plan de integración

Componente
Ingeniero de componentes Interfaz
Subsistema de implementación

Fuente: elaboración propia.

El arquitecto es la persona responsable y

encargada del modelo de implementación en forma
Arquitecto
global e integral, el modelo de despliegue y la
descripción de la arquitectura.
 1 of 3

Ingeniero de sistemas Tiene como responsabilidad crear el plan de integración.

2 of 3

El ingeniero de componentes tiene como

responsabilidad la realización del código fuente, al
Ingeniero de componentes
igual que su mantenimiento y su integridad con
otros componentes o elementos de software.
 3 of 3

4.1.4 Flujo de trabajo en la implementación

Como primera actividad identificaremos componentes arquitectónicos importantes e iremos creando el modelo de implementación. Para eso, debemos crear el
plan de integración e implementar cada componente, subsistema, clase, etcétera y tenemos que realizar la prueba de unidad de componentes. Este tema lo
veremos en mayor profundidad en la disciplina de prueba.

¿Qué tipo de artefacto se utiliza para especificar las operaciones que se deben implementar?

Componente.

Interfaz.

Plan de integración.

SUBMIT

¿Quién es el encargado de realizar el artefacto denominado plan de integración?

Arquitecto.

Integrador de sistemas.

Ingeniero de componente.

SUBMIT
Lección 3 de 7

Unidad 4.2. Disciplina de prueba

4.2.1 Introducción a las pruebas

Independientemente del sistema de información que estemos construyendo, debemos someterlo a diferentes tipos de pruebas, ya que un mal funcionamiento
de nuestro software puede ocasionar inconvenientes, como perdida de dinero, desconfianza, daños, etcétera.

Con el afán de evitar estas situaciones desfavorables, el interés por la calidad en el proceso de desarrollo y en el producto se ha incrementado en forma
continua.

En esta disciplina se describen e implementan diferentes artefactos con el objetivo de brindar una orientación sobre cómo evaluar y valorar la calidad del
producto.

A continuación, ahondaremos abordando temas como pruebas, modelos, casos, procedimientos, evaluaciones y plan de pruebas, que nos ayudarán con
nuestro objetivo.

4.2.2 Artefactos de las pruebas

Plan de pruebas

El plan de pruebas de control de calidad está diseñado para describir el alcance, el enfoque y los recursos de todas las actividades de prueba. Este debe
identificar los ítems y las características que serán testeados, los tipos de pruebas que serán ejecutados, el personal responsable de las pruebas, los
recursos necesarios para completar las pruebas y los riesgos asociados al plan.

La idea general es explicar las tareas que llevará a cabo el equipo que realiza las pruebas y establecer los criterios de aceptación.

Daremos un ejemplo: supongamos que sos un integrante del equipo de testing y has encontrado un defecto. ¿En qué herramienta lo reportás? ¿Cómo
describís el error? ¿Cómo clasificás el defecto? ¿Qué información detallás? Todos estos puntos se establecen de antemano y se documentan para que,
cuando tengas una duda, puedas remitirte a ese documento.

¿Qué puntos o apartados debes incluir en un test plan?

Alcance testing: es la especificación de los requerimientos que serán probados, el ambiente de testing, la estrategia de testing, las
responsabilidades y los criterios de éxito.

Criterios de entrada: son los que se deben cumplir para poder iniciar la fase de testing. Por ejemplo:

Casos de prueba completos.

Test unitarios finalizados.

Ambiente disponible.
 Datos de testing disponibles.

Criterios de salida: se utilizan cuando damos por finalizado el testing. Se emplean, por ejemplo, en los siguientes casos:

Todos los escenarios han sido completados exitosamente.

Todos los defectos con prioridad alta han sido resueltos.

Todos los defectos han sido documentados con severidad y prioridad.

Se ha llevado a cabo la reunión para determinar la salida a producción.

Ambiente no disponible.

Estrategia: a partir de los métodos de prueba existentes, hay que seleccionar los más adecuados para ofrecer la mejor calidad. Por
ejemplo:Sanity test: es una prueba básica para determinar rápidamente el acceso del producto de software después de un nuevo
despliegue o algún cambio en el entorno por testear.

Sanity test: es una prueba básica para determinar rápidamente el acceso del producto de software después
de un nuevo despliegue o algún cambio en el entorno por testear.

Ambiente: es la definición de los distintos tipos de entornos que participan en el proceso de desarrollo y su propósito. Por ejemplo:

Ambiente de test: este entorno debe ser tan idéntico al entorno de producción como sea posible. El entorno
de test también puede funcionar como un entorno de demostración o formación. Los defectos que han sido
cerrados por parte de los desarrolladores serán probados por el equipo de testing en este ambiente y, una
vez que hayan sido validados, será desplegada esta versión a producción.

Administración del defecto: por ejemplo, los defectos serán reportados y trakeados en la herramienta de seguimiento TestLink. Todos
los defectos deben contener en su creación los siguientes puntos:

Resumen.

Prioridad.

Asignación.

Entorno afectado.

Pasos para reproducir.

Comportamiento esperado.

Actual comportamiento.

Versión de producto.

Screenshot o video.

Riesgo y mitigaciones: contemplamos los imprevistos que podemos tener y la forma de mitigarlos. Por ejemplo:

Retraso en los despliegues en los ambientes que vamos a testear. ¿Qué acción debemos tomar? Solicitar al
personal la realización de horas extras.

Problemas en conectividad de VPN (del inglés, red privada virtual) o red. ¿Qué acción debemos tomar?
Llamar al área de sistemas; si el inconveniente no se soluciona luego de dos horas, se suspende el testing.

El entorno del test no cumple con las especificaciones de producción. ¿Qué acción debemos tomar? Se
suspende el testing.
Casos de prueba

Es uno de los elementos más importantes dentro del proceso de prueba; consiste en un conjunto de valores de entrada, precondiciones, pasos de ejecución y
resultados esperados, que se desarrollan para validar el comportamiento de un objeto particular de condición de prueba.

Existen diferentes formatos de casos de prueba, adaptados a las necesidades de cada proyecto. Pero, según las normas y certificaciones internacionales,
hay campos mínimos que se deben contemplar en todos los casos. A continuación, los desarrollaremos.

Identificador: valor numérico o alfanumérico único que permite diferenciar los casos de prueba.

Nombre del caso de prueba: describe el caso de prueba. Aunque no es obligatorio, se aconseja definir una nomenclatura para poder
diferenciar rápidamente los casos de prueba. Por ejemplo, suponiendo que se trata de un caso de prueba de la pantalla de inicio de un
sistema, podríamos proponer la siguiente nomenclatura: id_caso_prueba_módulo_perfil_descripción.

Descripción u objetivo: se detalla una breve descripción de lo que se probará en el caso de prueba, es decir, la acción que se va a
ejecutar y el resultado que se espera obtener.

Precondiciones: describe todo lo necesario para poder ejecutar el caso de prueba. Por ejemplo, que este depende de haber ejecutado
previamente otro caso de prueba, que se debe disponer de usuarios de prueba, archivos y un conjunto de datos necesarios para las
pruebas, entre otras.

Pasos: aunque no existe una normativa para la escritura de los pasos o los scripts de pruebas, se considera una regla fundamental que
estos se encuentren escritos de manera clara y entendible para que cualquier persona pueda reproducirlos sin problemas.

Resultado esperado: dentro del caso de prueba, este es uno de los puntos más importantes, ya que determina si los pasos ejecutados
condicen con lo esperado. Debe tener su respaldo en la documentación del sistema.

Datos de prueba: para poder ejecutar algunos casos de prueba es necesario contar con datos de prueba, por ejemplo, usuarios,
password, entre otros.

A continuación, ejemplificamos con un caso de prueba de inicio de sesión a nuestro sistema de postulantes. Para esto, debemos recordar la prototipación
realizada anteriormente.

Figura 2. Pantalla de inicio

Fuente: captura de pantalla del software IntelliJ IDEA 2018.2.2 (Community Edition, 2012).

Un caso de prueba para probar esta funcionalidad podría ser la siguiente:

Característica: Inicio de sesión.

 01_inicio_sesión_acceso_administrador_password_correcta.

Como administrador del sistema pruebo el inicio de sesión de la aplicación, entonces verifico que funcione
correctamente.

Escenario: Validar acceso de usuario administrador.

Dado que estoy en la página de inicio del sistema, cuando ingreso Nombre de Usuario "Administrador" e
ingreso password "Password" y selecciono el botón "Aceptar", entonces debería ver el mensaje
"Bienvenido".

Id_Caso_De_Prueba

01_inicio_sesión_acceso_administrador_password_correcta.

Descripción u objetivo

Como administrador del sistema pruebo el inicio de sesión de la aplicación entonces verifico que funcione
correctamente.

Precondición

Estar posicionado en la página de Iniciar sesión.

Datos de Prueba

Nombre y password de usuario válido para el perfil administrador.

Pasos de ejecución

Dado que estoy en la página de inicio del sistema, c uando ingreso Nombre de Usuario "Administrador", ingreso
password "Password" y selecciono el botón "Aceptar".

Resultado esperado

Entonces debo ver el mensaje "Bienvenido".

Procedimientos de prueba 

Detallan la secuencia de acciones para la ejecución del test case, es decir, describen cómo el tester ejecutará físicamente la prueba y los pasos necesarios.

Por ejemplo, nuestro sistema de postulantes será una aplicación web y vamos a ejecutar un caso de prueba que hemos realizado anteriormente, como el de
inicio de sesión. Para eso, vamos a abrir el browser para ejecutar el caso de prueba y nos preguntaremos ¿dónde informamos que ejecute el caso de prueba
y su resultado? ¿Qué pasa si no podemos conectarnos a la aplicación? ¿Necesitaremos algún requisito extra de conexión?

Es aquí donde el procedimiento nos da información:

Log
–
En qué sistema guardaremos los datos concernientes a la ejecución de las pruebas incluyendo su resultado.

Con gurar
–
Nuestro sistema podría utilizar un plug-in propio del browser y necesitaremos instalarlo antes de ejecutar las pruebas.

Iniciar
–
Podríamos tener que iniciar sesión en el servidor para ver si necesitamos observar información extra.

Proceder
–
Ejecutar primero casos de prueba sin dependencia.

Reiniciar
–
Si se necesita reiniciar, hay que hacerlo en el cliente y en el servidor.

Defecto
–
Primero diferenciaremos error, defecto y fallo, porque suele ser común confundir estos términos.

Cuando hablamos de error, hacemos referencia a una acción humana que produce como consecuencia un resultado incorrecto. Generalmente, esto sucede en el código del
software. Ejemplos comunes de estos errores son:

División por cero.

Ciclo infinito.

Exceder el tamaño de un vector.

Si esa funcionalidad desarrollada es implementada y posteriormente es ejecutada en una etapa de testing, seguramente producirá un fallo, por lo que habremos descubierto un
defecto en el código. Este es una imperfección en un componente de software que, si es ejecutado bajo ciertas condiciones, puede producir un fallo.
Con el siguiente video vas a terminar de entender las diferencias entre los conceptos de error, defecto y fallo.

Conceptos básicos - Error, defecto y fallo

Evaluación de pruebas

Una vez que hayamos ejecutado los casos de prueba debemos presentar un informe sobre los resultados de las pruebas y un análisis de estos para su
revisión.

Tabla 2. Reporte de ejecución de prueba

Fuente: captura de pantalla del software IntelliJ IDEA 2018.2.2 (Community Edition, 2012).

Componente de pruebas
Cuando el desarrollador trabaja para poder incrementar la funcionalidad del sistema de información, realiza un desarrollo de software. Si trabaja con un
lenguaje orientado a objetos, se valdrá de clases y métodos; estos son los componentes de la programación.

Los desarrolladores implementan test sobre pequeñas porciones de código, como por ejemplo, clases y métodos. Estas pruebas son llamadas pruebas de
componentes o test unitarios.

Modelo de pruebas

El modelo de pruebas es el que contiene la recopilación de los casos, procedimientos y componentes de prueba.

4.2.3 Roles en las pruebas

Tabla 3. Artefacto por rol

Rol Artefacto por construir

Modelo de pruebas
Casos de prueba
Diseñador de pruebas Procedimientos de prueba
Evaluación de pruebas
Plan de pruebas

Ingeniero de componentes Componente de pruebas

Ingeniero de pruebas de integración Defecto

Ingeniero de pruebas de sistema Defecto

Fuente: elaboración propia.

Diseñador de pruebas

El diseñador de pruebas, en este punto, es el que se lleva la mayor parte de las responsabilidades, ya que de él depende la realización de muchos de los
artefactos que se construirán para esta disciplina. Es el responsable de la integridad del modelo de prueba y el que selecciona y aprueba los casos de prueba
que se van a implementar.

Ingeniero de componentes

Es el responsable de crear los componentes que probarán en forma automatizada una unidad de código.

Para mayor detalle, te recomendamos ver el siguiente video.

Diseño de pruebas - Niveles de prueba - Test unitario

Ingeniero de pruebas de integración

Tiene como responsabilidad realizar las pruebas de integración para cada incremento realizado en cada iteración del proceso y es el responsable de
documentar los defectos encontrados.

Te sugerimos este video para profundizar en el tema.

Diseño de pruebas - Niveles de prueba - Test de Integración

Ingeniero de pruebas de sistema

Es el encargo de realizar las pruebas en el nivel del sistema, una vez que las pruebas de integración han finalizado, para corroborar que el sistema completo
funciona correctamente. También se encarga de documentar los defectos encontrados.

Como hemos mencionado anteriormente, estos son roles que definen responsabilidad, pero, dado un sistema de información de pequeñas dimensiones, estos
roles pueden ser cumplidos por una sola persona.
Te sugerimos que veas el siguiente video para obtener mayor información.

Diseño de pruebas - Niveles de prueba - Test de Sistema

4.2.4 Flujo de trabajo en las pruebas

Diseñamos el test plan que nos permitirá de antemano determinar el alcance, la estrategia y las responsabilidades de las actividades de prueba, que nos
servirán de guía.

A medida que se va agregando funcionalidad mediante el desarrollo, se van planificando los casos de prueba. Generalmente, las estimaciones las manejamos
en términos de requisitos, recursos humanos para realizar la prueba y el esfuerzo que estos demandarán, expresado en tiempo.

Diseñamos las pruebas creando los casos de prueba y los procedimientos de prueba, que nos ayudan a especificar cómo ejecutar los primeros.

Luego del diseño, implementamos la prueba y creamos los componentes de prueba. Entonces, nos disponemos a realizar las pruebas de integración, que es
cuando integramos el módulo que se ha desarrollado con el sistema de información. Para esto, ejecutamos los casos de prueba creados para este módulo o
funcionalidad, con ayuda de los procedimientos creados para tal fin, e informamos los defectos encontrados.

Posteriormente, ejecutamos la prueba del sistema, que es aquella que ejecuta todos los casos de pruebas anteriores para constatar que el sistema funciona
bien como un todo. También se ejecutan los procedimientos de los casos de prueba y se informan los defectos encontrados.

Como tarea final evaluamos las pruebas y presentamos un informe de resultados, para lo cual nos valdremos de métricas.

Criterios de entrada
Casos de prueba completos. Ambiente disponible.

Datos de testing disponibles. Test unitarios nalizados.

Criterios de salida

Todos los escenarios han sido

Ambiente no disponible.
completados exitosamente.
Lección 4 de 7

Video de habilidades

You have been temporarily

blocked
Pardon the inconvenience, but our servers have detected a high
number of errors from your connection. To continue, please verify
that you are a human:

I'm not a robot

reCAPTCHA
Privacy - Terms

Un caso de prueba es un conjunto de valores de entrada, precondiciones de ejecución, resultados esperados y postcondiciones de

ejecución, desarrollados para un objetivo particular de condición de prueba.

Verdadero.

Falso.

SUBMIT

¿Cuál de las siguientes opciones es una precondición de un caso de prueba?

Hace referencia a lo que se debe tener listo para la ejecución del caso de prueba.

Determina si la ejecución del caso va siendo exitosa por cada paso.

 Pueden ser la ejecución de otros casos de pruebas.

Identifica el caso de prueba.

La creación de un dato.

SUBMIT

¿Cuál de las siguientes opciones es una postcondición de un caso de prueba?

Datos de prueba.

Propósito.

Resultado esperado.

Procedimiento de prueba.

Condición de prueba.

SUBMIT

Indique cuál de las siguientes opciones no es una técnica de diseño de prueba de caja negra.

Tabla de decisión.

Transición de estados.

Análisis de valores límites.

Participación de equivalencia.

Decisión y cobertura.
 SUBMIT

¿Cuál de las siguientes opciones corresponde a un elemento del diagrama de transición de estado?

Evento.

Decisión.

Dato.

Acción.

Condición.

SUBMIT
Lección 5 de 7

Cierre

Introducción a la implementación
–
El propósito fundamental de esta es la implementación del sistema de información que hemos definido en la etapa de requisitos y refinado en la etapa de diseño. Por eso, en
esta etapa implementamos el resultado del diseño en términos de componentes de software, componentes ejecutables, componentes basados en código fuente, script,
etcétera.

Interfaz
–
Los artefactos de interfaz son utilizados para especificar las operaciones que deben implementar los componentes. Las interfaces especifican qué hacer, pero no implementan
esa funcionalidad, sino que su funcionalidad será implementada en las clases que implementan dichas interfaces.

Componente
–
Un componente es un empaquetado físico de elementos de un modelo. Ejemplifiquemos esto con el sistema de postulantes: en una iteración hemos producido un incremento
en el software. Seguramente el equipo de desarrollo ha agregado funcionalidad creando una tabla nueva en la base de datos, en las clases del sistema se han agregado
métodos nuevos a los existentes, se han añadido clases nuevas y librerías nuevas que nos han ayudado a extender nuestra funcionalidad, etcétera. Todo este trabajo se
empaqueta para su distribución e implementación. El empaquetado representa un componente y, al ser un agregado de desarrollo, tienen fuerte dependencia entre sí.

Plan de integración
–
El plan de integración describe, en cada construcción realizada en cada iteración, la funcionalidad que se espera implementar (listando los casos de uso) y las partes del
modelo afectadas (subsistema, componentes, etc.).

Introducción a las pruebas

–
Independientemente del sistema de información que estemos construyendo, debemos someterlo a diferentes tipos de pruebas, ya que un mal funcionamiento de nuestro
software puede ocasionar inconvenientes, como perdida de dinero, desconfianza, daños, etcétera.

Con el afán de evitar estas situaciones desfavorables, el interés por la calidad en el proceso de desarrollo y en el producto se ha incrementado en forma continua.

Plan de pruebas
–
El plan de pruebas de control de calidad está diseñado para describir el alcance, el enfoque y los recursos de todas las actividades de prueba. Este debe identificar los ítems
y las características que serán testeados, los tipos de pruebas que serán ejecutados, el personal responsable de las pruebas, los recursos necesarios para completar las
pruebas y los riesgos asociados al plan.

Casos de prueba
–
Es uno de los elementos más importantes dentro del proceso de prueba; consiste en un conjunto de valores de entrada, precondiciones, pasos de ejecución y resultados
esperados, que se desarrollan para validar el comportamiento de un objeto particular de condición de prueba.
Lección 6 de 7

Referencias

Oviedo, J. (2011). Habilitación profesional. Empresa: Cedi Consulting & Training. Actividad: consultoría, desarrollo de software, training y venta de
licencia de productos informáticos. Producto: selección de personal (Trabajo final inédito). Universidad Tecnológica Nacional, Córdoba, Argentina.
Lección 7 de 7

Descargá la lectura

Módulo 4. Disciplina de implementación y prueba.pdf

431.9 KB

Diseño de Sistemas de Información - Móoulo 4.mp3

8.8 MB