INTEGRACIÓN DE MÓDULOS DE SOFTWARE

CFT CENCO
 ESTAMOS EN LÍNEA CON TU VIDA

UNIDAD 3: INTEGRACIÓN DE MÓDULOS DE SOFTWARE

INTRODUCCIÓN A LA UNIDAD

La diversidad del mercado en el que la empresa se ve involucrada. entendiendo por tal la disparidad
de criterios, intereses, concienciaciones, culturales, etc. de la sociedad en su conjunto en temas
relacionados con la calidad, la protección del medioambiente, la seguridad tanto laboral como de
los usuarios finales del producto, etc. ha obligado a las empresas a adoptar e implantar sistemas de
gestión integrados enfocados a la satisfacción de todas esas necesidades como respuesta a la
diversidad. El objeto del presente trabajo es obtener la información necesaria, para lograr la
integración exitosa de un sistema de información con diferentes módulos, según las tendencias
actuales, así como la necesidad y conveniencia de convertirlos en un único sistema integrado donde
se tenga en cuenta los diversos aspectos a considerar, y la necesidad del usuario final de la empresa.
Esto va a garantizarle que sus clientes se encuentren satisfechos por el servicio recibido y su
información segura. Así pues, toda empresa que quiera sobrevivir al actual mercado caracterizado
por la competitividad tiene que ser capaz de satisfacer las exigencias impuestas en las diversas
materias de Calidad, Seguridad, Medioambiente, etc.

ACTIVIDAD INICIAL

1. ¿Conoce ud. algo del contenido que trabajaremos en esta Unidad? ¿Qué sabe?
2. ¿Considera usted importante aprender sobre el uso de....... para su desarrollo laboral? ¿Por
qué?
3. ¿Cómo se relaciona este contenido con las demás asignaturas que está trabajando o ha
trabajado en la carrera?
4. ¿En qué contenido específico le gustaría profundizar? ¿Por qué?

Estimado estudiante, le invito a subir sus reflexión al foro de la Unidad para compartir con los
demás integrantes de esta actividad curricular.
 ESTAMOS EN LÍNEA CON TU VIDA

Estimado(a) estudiante:

A continuación, usted comenzará el estudio de la actividad curricular a través de la

Unidad (nombre la Unidad) y sus Sub-Unidades. Para que usted alcance los objetivos
proyectados y que su aprendizaje sea de calidad, le entregamos algunas
recomendaciones:

1. Tómese su tiempo para el estudio y acomódese en un lugar que le sea grato y sin
distractores.
2. Deténgase en aquellos contenidos que le sean más difíciles de entender. Vuelva
atrás toda vez que lo necesite.
3. Apóyese en el material complementario para el estudio, el cual le permitirá
profundizar y obtener mayor información sobre un tema en particular.
4. Si se le presenta alguna duda que no pueda despejar en este documento, diríjase al
Foro de la Unidad y plantéemela.

¡Bienvenido(a) al estudio!

TUTOR ACADÉMICO
 ESTAMOS EN LÍNEA CON TU VIDA

DESARROLLO DE LOS CONTENIDOS DE LA UNIDAD 3

1.1. Integración de módulos de Software

La integración de software se define en la ingeniería como el proceso de reunir a los subsistemas o

módulos en un solo sistema (una agregación de los subsistemas que cooperan para que el sistema
es capaz de ofrecer la funcionalidad global) y asegurar que los subsistemas funcionen juntos como
un sistema, y en tecnología de la información como el proceso de vincular diferentes sistemas
informáticos y aplicaciones de software física o funcionalmente, para actuar como un todo
coordinado.

Expresado de otra forma: La integración de sistemas es el proceso de conectar diferentes

subsistemas (componentes) en un único sistema más grande que funciona como uno. Con respecto
a las soluciones de software, la integración del sistema se define típicamente como el proceso de
vincular varios sistemas, servicios y / o software de TI para permitir que todos trabajen juntos de
manera funcional.

Llamamos integración de software a la combinación de sistemas existentes, a menudo dispares, lo

que ofrece a la empresa un aumento de valor a su organización, porque mejora la calidad y el
 ESTAMOS EN LÍNEA CON TU VIDA

rendimiento del producto que ofrece, reduce el aumento costos y mejorar el tiempo de respuesta
a sus clientes.

En el mundo moderno conectado por Internet, el papel de los ingenieros de integración de sistemas
es importante: cada vez más sistemas están diseñados para conectarse, tanto dentro del sistema en
construcción como a sistemas que ya están implementados.

El integrador de sistemas combina sistemas discretos que utilizan una gran variedad de técnicas,
tales como las redes de computadoras, integración de las aplicaciones de la empresa, gestión de
procesos empresariales y manual de programación.

1.1.2. Pruebas de Software

Las pruebas de software son una parte integral del ciclo de vida del desarrollo de software (SDLC).
Las pruebas son la forma en que puede estar seguro acerca de la funcionalidad, el rendimiento y la
experiencia del usuario. Ya sea que realice sus pruebas manualmente o a través de la
automatización, cuanto antes y más a menudo pueda llevar a cabo pruebas, más probable es que

identifique errores, no sólo ahorrándole a la empresa, sino también asegurándose de que su

aplicación de software haya sido revisada y auditada a fondo antes de que esté frente a sus usuarios.
Si los problemas se arrastran al entorno de producción, será los más costoso y lentos al momento
de solucionar.
 ESTAMOS EN LÍNEA CON TU VIDA

Las pruebas de software se pueden dividir en dos tipos diferentes: pruebas funcionales y no
funcionales. Diferentes aspectos de una aplicación de software requieren diferentes tipos de
pruebas, como pruebas de rendimiento, pruebas de escalabilidad, pruebas de integración, pruebas
unitarias y muchos más. Cada uno de estos tipos de pruebas de software ofrece una excelente
visibilidad de la aplicación, desde el código hasta la experiencia del usuario.

1.1.2.1 Pruebas funcionales

Las pruebas funcionales se llevan a cabo para comprobar las características críticas para el negocio,
la funcionalidad y la usabilidad. Las pruebas funcionales garantizan que las características y
funcionalidades del software se comportan según lo esperado sin ningún problema. Valida
principalmente toda la aplicación con respecto a las especificaciones. Los tipos de pruebas
funcionales incluyen pruebas unitarias, pruebas de interfaz, pruebas de regresión, además de
muchas.
• Las pruebas unitarias se centran en probar piezas/unidades individuales de una aplicación de
software al principio del SDLC. Cualquier función, procedimiento, método o módulo puede
ser una unidad que se someta a pruebas unitarias para determinar su corrección y
comportamiento esperado. Las pruebas unitarias son las primeras pruebas que los
desarrolladores realizan durante la fase de desarrollo.

• Las pruebas de integración implican probar diferentes módulos de una aplicación de software
como grupo. Una aplicación de software se compone de diferentes submódulos que trabajan
juntos para diferentes funcionalidades. El propósito de las pruebas de integración es validar
la integración de diferentes módulos juntos e identificar los errores y problemas relacionados
con ellos.

• La prueba de regresión consiste en volver a ejecutar un subconjunto de pruebas que se han

llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos
colaterales no deseados. La prueba de regresión es la actividad que ayuda a asegurar que los
cambios no introducen un comportamiento no deseado o errores adicionales. El conjunto de
pruebas de regresión contiene tres clases diferentes de casos de prueba:

- Una muestra representativa de pruebas que ejercite todas las funciones del software.

- Pruebas adicionales que se centran en las funciones del software que se van a ver
probablemente afectadas por el cambio.

- Pruebas que se centran en los componentes del software que han cambiado.
 ESTAMOS EN LÍNEA CON TU VIDA

1.1.2.2 Pruebas No Funcionales

Las pruebas no funcionales son como pruebas funcionales; sin embargo, la principal diferencia es
que esas funciones se prueban bajo carga para el rendimiento de los observadores, fiabilidad,
usabilidad, escalabilidad, etc. Las pruebas no funcionales, como las pruebas de carga y esfuerzo,
normalmente se llevan a cabo mediante herramientas y soluciones de automatización.

• Las pruebas de rendimiento son un tipo de pruebas no funcionales, realizadas para

determinar la velocidad, estabilidad y escalabilidad de una aplicación de software. Como su
nombre indica, el objetivo general de esta prueba es comprobar el rendimiento de una
aplicación con respecto a los diferentes puntos de referencia del sistema y de la red, como
la utilización de la CPU, la velocidad de carga de la página, el control de tráfico máximo, la
utilización de recursos del servidor, etc.

Como difieren entre si estos tipos de pruebas

Es posible que tenga alguna idea sobre los diferentes tipos de pruebas anteriores. Todas las pruebas
se centran en la fiabilidad y la preparación de aplicaciones de software, sin embargo, vamos a
entender mejor las diferencias entre ellos a través de algunos ejemplos. Supongamos que tiene un
sitio web/aplicación de comercio electrónico con funcionalidades estándar.

Estos son algunos ejemplos de pruebas de rendimiento, pruebas funcionales, pruebas de

integración y pruebas unitarias:

- Si desea comprobar cómo funcionará su sitio web cuando un alto número de usuarios
acudan a su sitio web, por ejemplo, durante la temporada de ventas, debe realizar pruebas
de carga, que entran dentro de la categoría de pruebas de rendimiento. Le ayudará a
detectar problemas de velocidad y estabilidad y eliminar posibles cuellos de botella de
rendimiento.

- Supongamos que desea validar la entrada y la salida para cada funcionalidad, como registro,
inicio de sesión, agregar al carrito, pago, procesamiento de pagos, entradas de base de
datos, etc., según casos de prueba escritos en el documento SRS. En ese caso, debe
realizar pruebas funcionales.

- Si desea validar la funcionalidad del carrito con la integración del módulo de pago y pago
para ver si el número de artículos agregados al carrito se compra correctamente con el pago
correcto, debe realizar pruebas de integración.
 ESTAMOS EN LÍNEA CON TU VIDA

- Si ha escrito un módulo para la carga del producto y desea comprobar si es correcto y los
productos se agregan correctamente sin ningún error o defecto, debe realizar pruebas
unitarias para el módulo de carga del producto.

En resumen, se realizan pruebas de rendimiento para comprobar el rendimiento y productividad del

sitio web. Las pruebas funcionales se realizan para validar todas las funcionalidades. Las pruebas de
integración se realizan para validar la interacción entre diferentes módulos, y se realizan pruebas
unitarias para comprobar si son correctos las piezas de código individuales.

Ventajas de estos tipos de prueba

Pruebas de Rendimiento
• Evalúa la velocidad y escalabilidad del sitio web/aplicación.
• Identifica los cuellos de botella para las mejoras de rendimiento.
• Detecta errores que se pasan por alto en las pruebas funcionales.
• Optimización del sistema y mejoras de características
• Garantiza la fiabilidad del sitio web bajo una gran carga.

Pruebas funcionales
• Se asegura de que el sitio web / aplicación está libre de defectos.
• Garantiza el comportamiento esperado de todas las funcionalidades.
• Garantiza que la arquitectura sea correcta con la seguridad necesaria.
• Mejora la calidad y las funcionalidades generales.
• Minimiza los riesgos empresariales asociados con el sitio web/aplicación.

Pruebas de integración
• Se asegura de que todos los módulos de aplicación estén bien integrados y funcionen
juntos según lo esperado.
• Detecta problemas y conflictos interconectados para resolverlos antes de crear un
gran problema.
 ESTAMOS EN LÍNEA CON TU VIDA

• Valida la funcionalidad, fiabilidad y estabilidad entre diferentes módulos.

• Detecta excepciones ignoradas para mejorar la calidad del código.
• Admite la canalización de CI/CD.

Pruebas unitarias
• Detección temprana de errores en las nuevas funcionalidades o características
desarrolladas.
• Minimiza los costos de las pruebas a medida que se detectan problemas desde el
principio.
• Mejora la calidad del código con una mejor refactorización del código.
• Apoya el proceso de desarrollo ágil.
• Simplifica la integración y permite una buena documentación.

Desventajas de estos tipos de pruebas

Como todos estos tipos de prueba mejoran las funcionalidades y mejoran la experiencia del usuario,
por lo que no hay desventajas en hacer esto. Lo único que puede considerar una desventaja, en
general, es el tiempo y el costo asociados con la prueba. Las pruebas requieren esfuerzos y recursos,
y existe un riesgo relacionado con resultados de pruebas inexactos. Sin embargo, no hacer pruebas
de sitio web / aplicación le pondrá en una posición comprometedora que puede obstaculizar su
negocio y reputación significativamente.

Técnicas de Prueba

Existen 2 tipos de técnicas de evaluación dinámica, estas pruebas proporcionan distintos criterios
para generar casos de prueba que provoquen fallos en los programas. Estas técnicas se agrupan en:

Técnicas de caja blanca o estructurales: esta técnica se basa en un minucioso examen de los detalles
procedimentales del código a evaluar, por lo que es necesario conocer la lógica del programa.
 ESTAMOS EN LÍNEA CON TU VIDA

Técnicas de caja negra o funcionales: consiste en realizar pruebas sobre la interfaz del programa a
probar, entendiendo por interfaz las entradas y salidas de dicho programa. No es necesario conocer
la lógica del programa, únicamente la funcionalidad que debe realizar.

En la figura anterior se representa gráficamente la filosofía de las pruebas de caja blanca y caja
negra. Como se puede observar las pruebas de caja blanca necesitan conocer los detalles
procedimentales del código, mientras que las de caja negra únicamente necesitan saber el objetivo
o funcionalidad que el código ha de proporcionar.

1.1.3. Pruebas Integrales o Pruebas de Integración de Software

La prueba de integración es una técnica para construir la estructura del programa mientras que, al
mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.

Una aplicación de software se compone de diferentes submódulos que trabajan juntos para
diferentes funcionalidades. Estas pruebas implican probar diferentes módulos de una aplicación de
software como grupo. El propósito de las pruebas de integración es validar la integración de
diferentes módulos juntos e identificar los errores y problemas relacionados con ellos.
 ESTAMOS EN LÍNEA CON TU VIDA

Las Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito
del desarrollo de software una vez que se han aprobado las pruebas unitarias.

Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funciona
junto.

Estas pruebas algunas veces llamadas integración y testeo I&t es la fase de la prueba de software
en la cual módulos individuales de software son combinados y probados como un grupo. Son las
pruebas posteriores a las pruebas unitarias y preceden a las pruebas del sistema.

Integración Descendente: Se integran los módulos moviéndose hacia abajo por la jerarquía de
control, comenzando por el módulo de control principal (programa principal). Los módulos
subordinados al módulo de control principal se van incorporando en la estructura, bien de forma
primero en profundidad, o bien de forma primero en anchura.

- Integración primero en profundidad: integra todos los módulos de un camino de control

principal de la estructura.

Por ejemplo, si se elige el camino de la izquierda se integrarán primero los módulos M1,
M2 y M5. A continuación, se integrará M8 o M6. A continuación se construyen los
caminos de control central y derecho.
 ESTAMOS EN LÍNEA CON TU VIDA

- Integración primero en anchura: incorpora todos los módulos directamente subordinados a

cada nivel, moviéndose por la estructura de forma horizontal.

Por ejemplo: Los primeros módulos que se integran son M2, M3 y M4. A continuación,
sigue el siguiente nivel de control, M5, M6, M7 y por último M8.

Existen 5 pasos para realizar el proceso de Integración

1. Se usa el módulo de control principal como controlador de la prueba, disponiendo

de resguardos para todos los módulos directamente subordinados al módulo de
control principal.

2. Dependiendo del enfoque de integración elegido se van sustituyendo uno a uno

los resguardos subordinados por los módulos reales.

3. Se llevan a cabo pruebas cada vez que se integra un nuevo módulo.

4. Tras terminar cada conjunto de prueba, se reemplaza otro resguardo con el

módulo real.

5. Se hace la prueba de regresión para asegurarse de que no se han introducido

errores nuevos.

El proceso continúa desde el paso dos hasta que se haya construido la estructura del programa
entero.

Integración Ascendente: Empieza la construcción y la prueba con los niveles más bajos de la
estructura del programa. Dado que los módulos se integran de abajo hacia arriba, el proceso
requerido de los módulos subordinados siempre está disponible y se elimina la necesidad de
resguardos.

Se puede implementar una estrategia de integración ascendente mediante los siguientes pasos:

1. Se combina los módulos de bajo nivel en grupos que realicen una subfunción específica
del software.

2. se describe un controlador (un programa de control de la prueba) para coordinar la

entrada y la salida de los casos de prueba.

3. Se prueba el grupo.

4. Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la
estructura del programa.

En el siguiente grafico se combinan los módulos para formar los grupos 1,2 y 3. Cada uno de los
grupos se somete a prueba mediante un controlador (mostrado como un bloque punteado). Los
módulos de los grupos 1 y 2 son subordinados Ma. Los controladores D1 y D2 se eliminan y los
grupos interaccionan directamente con Ma. De forma similar, se elimina el controlador D3 del grupo
 ESTAMOS EN LÍNEA CON TU VIDA

3 antes de la integración con el módulo Mb. Tanto Ma como Mb se integrarán finalmente con el
módulo Mc y así sucesivamente.
 ESTAMOS EN LÍNEA CON TU VIDA

Prueba de Regresión: La prueba de regresión consiste en volver a ejecutar un subconjunto de

pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han
propagado efectos colaterales no deseados. La prueba de regresión es la actividad que ayuda
a asegurar que los cambios no introducen un comportamiento no deseado o errores
adicionales.

El conjunto de pruebas de regresión contiene tres clases diferentes de casos de prueba:

• Una muestra representativa de pruebas que ejercite todas las funciones del software.
• Pruebas adicionales que se centran en las funciones del software que se van a ver
probablemente afectadas por el cambio.
• Pruebas que se centran en los componentes del software que han cambiado.

Prueba de Humo: Esta prueba es utilizada cuando se ha desarrollado un producto software

“empaquetado”. Es diseñado como un mecanismo para proyectos críticos por tiempo,
permitiendo que el equipo de software valore su proyecto sobre una base sólida. La prueba de
humo comprende las siguientes actividades:

1. Los componentes software que han sido traducidos al código se integran en una
“construcción”. Una construcción incluye fichas de datos, librerías, módulos
reutilizables y componentes de ingeniería que se requieren para implementar una o
más funciones del producto.

2. Se diseña una serie de pruebas para descubrir errores que impiden a la construcción
realizar su función adecuadamente. El objetivo será descubrir errores “bloqueantes”
que tengan la mayor probabilidad de impedir al proyecto de software el cumplimiento
de su planificación.

3. Es habitual en la prueba de humo que la construcción se integre con otras construcciones

y que se aplica una prueba de humo al producto completo. La integración puede
hacerse bien de forma descendente o ascendente.

La prueba de humo facilita una serie de beneficios cuando se aplica sobre proyectos de
ingeniería de software complejos y críticos por su duración:

• Se minimiza los riesgos de integración.

• Se perfecciona la calidad del producto final.

• Se simplifican el diagnóstico y la corrección de errores.

• El progreso es fácil de observar.

 ESTAMOS EN LÍNEA CON TU VIDA

Prueba De Validación: La validación se consigue cuando el software funciona de acuerdo con las
expectativas razonables del cliente. La validación del software se consigue mediante una serie de
pruebas de caja negra que demuestran la conformidad con los requisitos.

En la validación se llevan a cabo dos pruebas:

PRUEBA DEL SISTEMA: Su propósito primordial es ejercitar profundamente el sistema, verificando

que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las
funciones apropiadas. Comprende las siguientes pruebas:

Prueba de Recuperación: Esta prueba fuerza el fallo del software de muchas formas y verifica
que la recuperación se lleva a cabo apropiadamente.

Prueba de Seguridad: Intenta verificar que los mecanismos de protección incorporadas en el

sistema lo protegerán, de hecho, de accesos impropios.

Prueba de Resistencia o prueba de stress: Ejecuta un sistema de forma que demande recursos
en cantidad, frecuencia o volúmenes anormales. Por ejemplo:

1. Diseñar pruebas especiales que generen 10 interrupciones por segundo, cuando las
normales son una o dos;

2. Incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de

comprobar cómo responden las funciones de entrada.

3. Ejecutar casos de prueba que requieran el máximo de memoria o de otros recursos.

4. Diseñar casos de prueba que puedan dar problemas en un sistema operativo virtual.

5. Diseñar casos de prueba que produzcan excesivas búsquedas de datos residentes en disco.

Esencialmente, el responsable de la prueba intenta romper el programa.

 ESTAMOS EN LÍNEA CON TU VIDA

Prueba de Rendimiento: Permite probar el rendimiento del software en tiempo de ejecución dentro
del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del
proceso de la prueba. Para llevar a cabo esta prueba, deben estar integrados completamente todos
elementos del sistema.

Depuración: La depuración ocurre como consecuencia de una prueba efectiva. Cuando un caso de
prueba descubre un error, la depuración es el proceso que provoca la eliminación del error.

El proceso de depuración comienza con la ejecución de un caso de prueba. Se evalúan los resultados
y aparece una falta de correspondencia entre los esperados y los encontrados realmente. El proceso
de depuración intenta hacer corresponder el sistema con una causa, llevando así a la corrección del
error.

El proceso de depuración siempre tiene uno de los dos resultados siguientes:

1. Se encuentra la causa, se corrige y se elimina.

2. No se encuentra la causa.

En este último caso, la persona que realiza la depuración debe sospechar la causa, diseñar un caso
de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrás a la corrección del
error de una forma interactiva.

Durante la depuración se encuentran errores que van desde lo ligeramente inesperado hasta lo
catastrófico.
 ESTAMOS EN LÍNEA CON TU VIDA

La depuración tiene el objetivo primordial de encontrar y corregir la causa de un error en el

software.

SÍNTESIS DEL TEMA

Estimados estudiantes, hasta aquí hemos tratado la integración de sistemas y sabemos que es como
armar un rompecabezas. Hay partes dispersas de los subsistemas de información de una organización
que deben encajar en una arquitectura coherente y bien coordinada o una malla de aplicación
integrada.
Es un proceso de construcción complejo que conecta las funciones de una organización desde
diferentes sistemas, racionalizando sistemas dispares, incluyendo hardware, software (personalizado
o listo para usar) y comunicaciones.
Las pruebas son imprescindibles en todos los entornos de desarrollo y producción para garantizar que
su sitio web o aplicación esté al día y pueda soportar la carga de usuario esperada. Para obtener un
excelente resultado en las pruebas de sistemas y de integración de sistemas es ideal usar las técnicas
que existen con la cual definiremos más rápido la eficacia del sistema, caja blanca caja negra. En las
pruebas de caja negra desconocemos la estructura interna del sistema. No sabemos cómo está
construido, con qué tecnología, con qué arquitectura, etc. Sin embargo, podemos diseñar las pruebas
a partir de la observación de las entradas y salidas del mismo que suelen estar descriptas en los
modelos funcionales. Este es el tipo de pruebas que generalmente hacemos los testers funcionales.
Por otro lado, cuando armamos los casos de prueba a partir de la estructura del programa, estamos
haciendo pruebas de caja blanca. Es decir que los casos de prueba los armamos a partir del código, el
flujo de datos o de control, la estructura de la base de datos, etc.

Por favor, revise el siguiente enlace para complementar su estudio:

Nombre del contenido del enlace: LOS SISTEMAS DE INFORMACIÓN Y LA INTEGRACIÓN DE SUS
SISTEMAS DE GESTIÓN

Enlace:

http://eprints.rclis.org/16116/1/INTEGRACI%C3%93N%20DE%20SISTEMAS%20DE%20GESTI%C3%
93N.pdf

http://www.lsi.us.es/docencia/get.php?id=361
 ESTAMOS EN LÍNEA CON TU VIDA

2.1. Tipos de errores comunes en los proyectos de integración de software

Las tareas relacionadas con los procesos de integración de sistemas no son sencillas. Muchos
proyectos de esta naturaleza han tenido recorridos complicados, momentos de tensión e incluso
que han terminado en el fracaso.

No es menos cierto que el mundo de la interoperabilidad ofrece la sensación en muchas ocasiones

de ser un entorno oscuro y hostil, donde las cosas se llevan a cabo en silencio, por detrás, y donde
es mejor no inmiscuirse.

Las organizaciones suelen confiar estos trabajos a sus proveedores de aplicaciones, participando en
menor medida que en otras tareas. Sin embargo, con un poco de tiempo, la dedicación adecuada y
no obviando ningún aspecto tradicional de otros proyectos, es fácil salgan adelante con éxito,
ofreciendo grandes beneficios a las organizaciones.

A continuación, repasamos algunos de los errores más comunes que suelen producirse en estos
proyectos, errores que debemos evitar siempre que sea posible.
 ESTAMOS EN LÍNEA CON TU VIDA

• Olvidar la coordinación del proyecto: La integración siempre se ha considerado como el trabajo

entre dos equipos, el emisor y el receptor de los mensajes. Uno tiene que enviar y otro que
recibir. Ni más ni menos. Y en esa situación es muy común derivar la gestión de todas las etapas
del proyecto en esos mismos proveedores, esperando que ellos se entiendan, se coordinen y
completen sus tareas. Únicamente se presta atención a los tiempos (cuándo podrá estar listo) y,
si surge, se resuelve algún conflicto (y a veces ni eso). Es un error bastante grave ya que se pierde
totalmente el control de la situación, y el grado de avance y, en última instancia, de
la visibilidad de cómo se están haciendo las cosas. Se penalizan de esta forma todas y cada una
de las etapas posteriores del proyecto y en especial del día a día cuando el sistema ya se
encuentre operativo.

• Ignorar la parte funcional de los procesos de integración: Dado el carácter fundamentalmente

técnico de los desarrollos de integración y, salvo raras excepciones, se ignoran sistemáticamente
las implicaciones funcionales que tienen dichos proyectos. Es un tema que sobre el que nunca
debemos dejar de incidir. Los proyectos de integración deben comenzar siempre con un
análisis en profundidad de los procesos operativos y de cómo afectará el intercambio de
información a los mismos, a los profesionales y a los usuarios. De otro modo nos encontraremos
que tenemos información que viaja sin un sentido claro y probablemente no será funcional. No
hay que perder de vista tampoco la gestión del cambio y los periodos de transición entre la total
integración de los sistemas y el comienzo, donde habrá datos que se podrán integrar y otros que
tendrán que seguir los circuitos tradicionales.

• No participar en las pruebas: Una vez establecidas las bases funcionales y técnicas del
intercambio de información y desarrollados los elementos técnicos implicados (aplicaciones,
sistemas o dispositivos) se debe realizar siempre un proceso exhaustivo de pruebas para
garantizar que todo se ha realizado correctamente. Es muy habitual que durante esta etapa
surjan problemas de indefinición, puntos que no se habían tenido en cuenta, desajustes de
procesos o de catálogos, etc. Es la etapa de pruebas (unitarias e integradas) la que mostrará si lo
que se ha diseñado es válido o no. Pero también es muy normal que la responsabilidad de
probar recaiga en su mayor parte en los propios proveedores de la mensajería, esperado que
ellos mismos validen lo que han realizado y participando las organizaciones únicamente de los
resultados finales. Las organizaciones deben participar activamente en los procesos de testing y
validación para garantizar y asegurar que todo se ha llevado a cabo conforme a lo diseñado y con
los estándares de calidad suficientes para una puesta en producción exitosa.

• No contar para nada con el usuario: El usuario nunca puede quedar al margen en ningún
proceso relacionado con sus herramientas y tampoco en los procesos de integración, sean más
o menos técnicos. El usuario debería participar en todo el proceso de integración, desde el diseño
hasta las pruebas. Pero si no es posible, al menos debería estar en todo momento informado de
lo que se está haciendo, con qué objetivo, de qué forma le va a afectar en el desarrollo de su
trabajo y de las consecuencias y procedimientos en caso de errores o problemas. No se puede
 ESTAMOS EN LÍNEA CON TU VIDA

permitir que los usuarios se enfrenten a la realidad de las integraciones en producción sin saber
nada de cómo están realizadas.

• No hacer un seguimiento de lo que sucede en el día a día: El trabajo nunca finaliza con las
aplicaciones o los procesos. En el caso de la integración, dado su carácter eminentemente
técnico, es muy habitual pensar que siempre funcionará y, tras los primeros días de ajuste,
olvidar que existe. Pero como siempre, llegará un momento en que habrá un problema y nos
acordaremos de esa integración que existe que ha fallado. Es muy importante entonces disponer
de procesos de monitorización y control para analizar y descubrir los motivos del fallo. Y más
importante aún es realizar un soporte proactivo, que analice día a día el flujo de información y
detecte potenciales problemas antes incluso de que lleguen al usuario. De este modo
la integración será más robusta y los profesionales tendrán más confianza en ella. Las
organizaciones sanitarias requieren procesos de integración, eso está claro. Pero en muchas
ocasiones se olvidan de que deben participar activamente en su diseño y desarrollo, confiando
esa labor a sus proveedores. Siguiendo unas mínimas pautas se pueden evitar errores y
problemas y obtener así sistemas robustos y fiables que obtengan de la integración todo su
potencial y beneficio.

SÍNTESIS DEL TEMA

Estimados estudiantes, hasta aquí hemos estudiado sobre los errores que se presentan al momento
de hacer la integración de módulos de un sistema, Estos errores son evitables. Sin embargo, también
son muy comunes. A medida que avanzamos con la tecnología de integración, tenemos que considerar
cómo las cosas pueden ir mal, así como qué tenemos que hacer para que funcionen bien, se debe tratar
de evitar estos errores y desde el principio de la integración incluir a la empresa en todo el proceso.

Por favor, revise el siguiente enlace para complementar su estudio:

Nombre del contenido del enlace: Diseño e Implementación de un Sistema de Integración

Enlace:
https://repositorio.usm.cl/bitstream/handle/11673/13750/3560900231347UTFSM.pdf?sequenc
e=1
 ESTAMOS EN LÍNEA CON TU VIDA

3.1. ESTRATEGIAS DE PRUEBAS

Una Estrategia de prueba de software integra las técnicas de diseño de casos de prueba en una serie
de pasos bien planificados que llevan a la construcción correcta del software. Es una parte
fundamental del proceso de validación y verificación del software. La verificación es una actividad
la cual nos aseguramos que las distintas partes del software cumple con la función para la cual
fueron diseñadas, en este sentido la verificación se encarga de revisar el funcionamiento de los
módulos del software, mientras que la validación se encarga de comprobar que los módulos
verificados cumplen con los requisitos que el cliente ha expresado.

3.1.2. Características de las estrategias de pruebas de Software

• La prueba comienza en el nivel de módulo y trabaja hacia afuera.

• En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.
• La prueba la realiza la persona que desarrolla el software y (para grandes proyectos)
un grupo de pruebas independiente.
• La prueba y la depuración son actividades diferentes.
• Una estrategia de prueba para el software debe constar de pruebas de bajo nivel,
así como de pruebas de alto nivel.

3.1.3 Objetivos de la estrategia de Pruebas

• Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad,
integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias
dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de
la iteración.

• Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar,
cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para
automatizar las pruebas.

• Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los
productos de desarrollo de software en los que se detectan defectos son probados de
nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma
que los defectos puedan ser arreglados.

Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes
etapas:
 ESTAMOS EN LÍNEA CON TU VIDA

• Planificación de las pruebas.

• Diseño de las pruebas.
• Implementación de las pruebas.
• Ejecución de las pruebas.
• Evaluación de las pruebas.
 ESTAMOS EN LÍNEA CON TU VIDA

SÍNTESIS DEL TEMA

Estimados estudiantes, hasta aquí hemos estudiado sobre las estrategias de pruebas, y ya sabemos
que, para lograr el éxito en las pruebas del sistema, es importante establecer primero una estrategia
de trabajo, ya que alcance de la prueba resume las características funcionales, de rendimiento y diseño
interno específicas a probar. Se limita el esfuerzo de prueba, se describen criterios de terminación de
cada fase de prueba y se documentan las limitaciones, integridad de interfase, validez funcional,
contenido de la información y rendimiento.

Por favor, revise el siguiente enlace para complementar su estudio:

Nombre del contenido del enlace: Estrategias de Pruebas

Enlace: http://fcqi.tij.uabc.mx/usuarios/luisgmo/data/8.3%20prb-cal-mant.pdf
 ESTAMOS EN LÍNEA CON TU VIDA

4.1. REGISTRO DE FALLAS

Los programas siempre deben presentar mejoras conforme avanza la tecnología esto es inevitable.
Aquellos programas que son más populares se actualizan constantemente. Pero no sólo son nuevas
funciones las que hacen necesario el uso de actualizaciones, sino también la resolución de
problemas en el sistema o aplicación. Sin importar que tantas pruebas se hayan realizado, es
probable que con el paso del tiempo se vayan encontrando fallas en el sistema y depende de los
equipos de desarrolladores solucionarlos.

Sin embargo, el punto de partida para todo equipo de desarrollo es el reporte sobre el problema.
Este reporte ayuda a los desarrolladores a determinar la causa del error y llegar a su pronta
resolución. Asimismo, gracias al reporte pueden definir la severidad del mismo y la prioridad de su
resolución.
 ESTAMOS EN LÍNEA CON TU VIDA

4.1.2 Datos esenciales en un reporte de fallas

Para el equipo de desarrollo es esencial tener ciertos datos iniciales sobre el problema, de lo
contrario no pueden comenzar a solucionar dichos errores. Para ello se hacen uso de los reportes
de fallas, que proveen a los desarrolladores a cargo de la información necesaria para entender el
problema e intentar llegar a su resolución.

Pero un reporte de falla no sólo debe contener algunos datos mandatorios sino también ser los más
descriptivos posibles. Mientras más detalles se incluyan, será de mayor utilidad para el desarrollador
pues tendrá un gran punto de partida desde donde comenzar a realizar pruebas para entender por
qué se dio el error en primer lugar.

También se puede incluir en el reporte de fallas capturas de pantalla con el mensaje de error o el
tipo de error que se presenta. Es particularmente útil, si en la pantalla del programa se presenta
alguna información adicional o el error afecta el entorno del programa.
 ESTAMOS EN LÍNEA CON TU VIDA

Para un desarrollador, es sencillo tener en mente todos los datos esenciales que se deben incluir en
un reporte de falla. Particularmente porque entiendes sobre temas técnicos y sabes lo importante
que es para el equipo de soporte contar con esta información. Sin embargo, es probable que un
usuario sin conocimientos técnicos simplemente no tenga la paciencia para realizar todos estos
pasos. Después de todo, la principal razón por la que usan cierto sistema o aplicación es para ahorrar
tiempo, y escribir un reporte detallado lo pueden considerar como una pérdida de tiempo. Por este
motivo lo ideal sería capacitar a un usuario e indicarlas las pautas a seguir para documentar su
experiencia en el uso del software, esto permitirá dar la información que necesita el desarrollador
para solucionar las fallas que se estén presentando.

SÍNTESIS DEL TEMA

Estimados estudiantes, hasta aquí hemos tratado los registros de fallas de sistemas y podemos decir
que Cuando se trata de reportar incidencias o errores en el software implementado, cuantos más
detalles, mejor. Ningún software es perfecto. Por innumerables razones, el comportamiento real de
un producto de software se desvía de los comportamientos establecidos o esperados. La forma en que
abordamos estos problemas marca la diferencia entre los problemas persistentes de calidad del
software y un producto confiable.
Las desviaciones del resultado esperado son defectos, y van desde un simple descuadre en alguno de
los formatos en un menú, hasta fallas significativas como errores de excepción y pérdida de datos etc.
Confiamos en los informes de incidencias o reportes de errores de software cuando evalúan y corrigen
estos problemas, no olvide que el equipo responsable, dispone de archivos de prueba de productos que
presentan la mayoría de los informes de errores de software, ya que es allí donde se busca la gama
más amplia de problemas y se resuelven. Sin embargo, los usuarios finales también pueden
comunicarse con el desarrollador de software para informar problemas, que son producto de uso
cotidiano y posibilidades no analizadas en los bancos de prueba.

Por lo tanto, se necesita documentación clara y bien respaldada (comúnmente elaborada por el
usuario que usa el software) para clasificar, investigar y solucionar las fallas.
 ESTAMOS EN LÍNEA CON TU VIDA

Por favor, revise el siguiente enlace para complementar su estudio:

Nombre del contenido del enlace: Fundamentos de Ingeniería del Software

Enlace: http://www.cua.uam.mx/pdfs/conoce/libroselec/Fundamentos_Ing_SW-VF.pdf

1.1. PROTOCOLO DE ELABORACIÓN DE REPORTES DE FALLAS

Para la elaboración de un buen reporte de fallas se debe seguir un protocolo, que consiste en,
brindar la información mas completa posible al programador del sistema quien será el encargado
de corregir la falla existente, cabe destacar que el responsable del sistema, se debe apoyar en la
opinión del usuario final, ya que es este el que hará uso del software por lo tanto tendrá la
experiencia diaria y notará mas las fallas que se puedan presentar

Ningún software es perfecto. Por innumerables razones, el comportamiento real de un producto de

software se desvía de los comportamientos establecidos o esperados. La forma en que un equipo
aborda estos problemas marca la diferencia entre los problemas persistentes de calidad del
software y un producto confiable.

Las desviaciones del resultado esperado son defectos, y van desde una simple falta de ortografía en
un menú, hasta fallas significativas como errores de excepción y pérdida de datos. Los
desarrolladores confían en los informes de errores de software cuando evalúan y corrigen estos
problemas. Sin embargo, los usuarios finales también pueden comunicarse con los desarrolladores
para informar problemas.

Los desarrolladores necesitan documentación clara y bien respaldada para clasificar, investigar y
remediar defectos.

5.1.2. Protocolo básico a seguir para realizar un reporte de falla eficientemente

Los puntos básicos que debe poseer un reporte de fallas son:

• Usuario: persona que lo reportó. Esto facilitará la comunicación entre el que lo reportó y el
que lo va a solucionar.
• Versión: Indica la versión de la aplicación en que se detectó la falla.
• Ambiente: Indica sobre qué ambiente de pruebas ocurrió la falla.
• Componente: Indica sobre que componente/módulo/submódulo/pantalla se detectó la falla.
 ESTAMOS EN LÍNEA CON TU VIDA

• Plataforma y Sistema Operativo: Indica sobre las características de hardware y sistema

operativo de la maquina en donde se detectó la falla.
• Navegador: Indica el navegador que se estaba utilizando cuando se detectó la falla.
• Prioridad: Se indica “cuando” debe arreglarse la falla. Este parámetro nos ayuda a indicarle al
desarrollador con que urgencia necesitamos la corrección.
• Severidad: Indica el impacto de la falla sobre la aplicación.
• Resumen: Descripción corta que describe la falla en forma simple y concreta.
• Descripción: Detalle de los pasos realizados para poder reproducir la falla, junto con los datos
utilizados y la generación del escenario para que ocurra el error.
• Falla: Descripción que indica cual es el error exactamente.
• Esperado: Descripción de que debería ocurrir en lugar de la falla.
• Adjuntos: Cualquier material complementario que sirva para ayudar al desarrollador a
solucionar la falla (capturas de pantalla, registros, documentos, etc…)
• Estado: En qué situación se encuentra la falla para indicar si ya puede ser tomada por el
desarrollador, si ya fue solucionada o si todavía no puede revisarla.

Al momento de reportar una falla debemos tener en cuenta las siguientes consideraciones:

• Los errores o fallas deben tener identificadores únicos: Si bien muchas herramientas de
bugtracking (seguimiento de errores) asignan automáticamente un ID (identificación) único a
la falla, muchas veces se reportan fallas por medio de mails, saltando la registración en la
herramienta y dejando la falla perdida, lo que hara muy difícil hacer referencia o realizar un
seguimiento. Entonces, siempre hay que registrar los fallas con un ID único (ya sea mediante
una herramienta para bugtracking o solo una planilla en txt o excel).

• Una falla debe ser reproducible para reportarla: Si la falla no es reproducible, no es una falla.
Para fallas que ocurren en forma aislada, podemos realizar una nota personal para investigar
luego y determinar qué condiciones deben ser dadas para que el mismo se produzca, pero
reportar una falla que nosotros mismos no podemos reproducir no es muy productivo ya que
solo cargaremos la herramienta de falla con fallas que serán devueltas como no reproducibles,
ese será su único destino, generando una pérdida de tiempo por parte del usuario en reportarlo
y por parte del desarrollador en revisarlo y probar variantes para reproducirlo.

• Debe reportarse cada paso realizado para reproducirlo: Toda la información que podamos
darle al desarrollador para que pueda reproducir la falla siempre será bienvenida, no debemos
obviar ningún paso que sea relevante para llegar al error en cuestión. Una buena práctica es
reproducir el error una o más veces siguiendo solo los pasos que escribimos, como si no lo
conociéramos, esto nos ayudara a detectar información de más (o faltante) y si la falla es
reproducible con la información que se detalla.
 ESTAMOS EN LÍNEA CON TU VIDA

• Ser especifico: No se debe escribir suposiciones o ideas sobre lo que está ocurriendo u otra
cosa que no sea la información relevante para poder reproducir la falla.

• Describir la falla de forma simple y corta en el resumen del mismo: Es importante que el
desarrollador puede hacerse una idea del error con solo leer el resumen del mismo, para que
al entrar a leer la descripción del mismo ya tenga una idea de hacía donde apunta el camino.

• Investigar el patrón con el que ocurre el error: Hay que tener en cuenta que las fallas siguen
siempre un determinado patrón para ocurrir, ya que los mismos son fallas en el código.
Debemos esforzarnos para encontrar el patrón que hace que se pase siempre por la sección de
código donde está la falla.

SÍNTESIS DEL TEMA

Estimados estudiantes, hasta aquí hemos tratado los protocolos que se deben seguir para hacer
efectivo el reporte de una falla debemos tomar muy en serio al momento de reportarla, ya que es la
base para que el programador o responsable del sistema le de una rápida y eficiente solución a la falla
reportada debemos tomar muy en cuenta los protocolos que se debe seguir para este reporte, evitar
omitir detalles y especificar la falla presentada es lo que principalmente ayudara al especialista

Por favor, revise el siguiente enlace para complementar su estudio:

Nombre del contenido del enlace: PROCEDIMIENTO PARA EL REPORTE DE FALLAS Y

MANTENIMIENTO PREVENTIVO.

Enlace:
http://www.fonaturconstructora.gob.mx/LFTAIPG/fraccionXIV/Procedimientoinformatica.pdf
 ESTAMOS EN LÍNEA CON TU VIDA

SÍNTESIS DEL TEMA

Es indiscutible el grado de importancia que los sistemas de información juegan en la actualidad, La

diversidad de aplicaciones es tan amplia que resulta poco probable encontrar áreas del quehacer
humano donde no haya intervenido una computadora y por lo tanto, el software es parte
fundamental del día a día, a esto la integración de sistemas ha llevado a que en los últimos años
hayan surgido nuevas prácticas y herramientas que tienden a satisfacer esta necesidad en el marco
de la mejora continua del proceso de desarrollo de software.
La integración es una práctica que comienza con la organización de los proyectos en una estructura
de directorios adecuada para establecer el orden de ejecución de los componentes de un proyecto
(incluyendo casos de prueba), y de esta manera facilitar la construcción correcta del software final
cuando se ejecuta el proceso de integración, logrando que el mismo sea transparente para el equipo
de desarrollo. La integración del Software es como armar un rompecabezas. Hay partes dispersas
de los subsistemas de información de una organización que deben encajar en una arquitectura
coherente y bien coordinada o una malla de aplicación integrada. Es un proceso de construcción
complejo que conecta las funciones de una organización desde diferentes sistemas, racionalizando
sistemas dispares, incluyendo hardware, software y comunicaciones.
Las pruebas son imprescindibles en todos los entornos de desarrollo y producción para garantizar
que su sitio web o aplicación esté al día y pueda soportar la carga de usuario esperada. Para obtener
un excelente resultado en las pruebas de sistemas y de integración de sistemas es ideal usar las
técnicas que existen con la cual definiremos más rápido la eficacia del sistema.
Toda prueba debe ser documentada, para que el programador o responsable del sistema se
encargue de ofrecerla la más pronta solución a esta, y para eso disponemos de los reportes de fallas
que deben poseer la más amplia y precisa información ya que será la herramienta que le ayudara al
profesional a encontrar y solucionar las fallas.

Por favor, revise el siguiente enlace para complementar su estudio:

Nombre del contenido del enlace: Ingeniería del Software

Enlace: http://www.cua.uam.mx/pdfs/conoce/libroselec/Fundamentos_Ing_SW-VF.pdf