Este documento presenta información sobre dos temas: 1) la gestión de pruebas de software y el plan de implantación en una empresa financiera, y 2) la migración de sistemas informáticos y el entorno. Describe el proceso de pruebas de la empresa, los tipos de pruebas utilizadas, y los problemas enfrentados. También explica la necesidad de migrar sistemas, las estrategias de migración y su impacto en la organización.

1. INTEGRANTES:




DE LA CRUZ HERNANDEZ ZAIDA
HUANCAHUARI MENDOZA PAMELA
LLANOS CASTILLA RANDAL
MELGAR ESCATE FERNANDO
Gestión de las pruebas y el plan de implantación
Migración del plan de marketing y el entorno

2. -
Implantación y Gestión
Del entorno
Introducción
El presente trabajo monográfico tiene como objetivo dar a conocer la importancia de dos
temas vinculados a la Implementación y Gestión de Entorno.
El desarrollo de sistemas de software implica una serie de actividades de producción en
las que las posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el primer momento del proceso, en el que los objetivos pueden estar especificados de forma errónea o imperfecta, así como en posteriores pasos de
diseño y desarrollo. Debido a la imposibilidad humana de trabajar y comunicarse de forma
perfecta, el desarrollo de software ha de ir acompañado de una actividad que garantice
la calidad.
Las pruebas del software, uno de los temas que trataremos, son un elemento crítico para
la garantía de calidad” en términos de cuanto se aproxima el software a los requisitos definidos tanto funcionales como no funcionales, así como cuanto de resistente es la aplicación ante usos inadecuados o no deseados.
La creciente percepción del software como un elemento del sistema y la importancia de
los «costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. No es raro que una organización de desarrollo de
software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las
pruebas.
El segundo tema que trataremos es acerca de la migración y entorno veremos qué tan
importante es la migración de sistemas informáticos en las organizaciones, las ventajas que
esta produce en la organización sobre las demás y las distintas estrategias que se aplican
para la migración.
2

3. -
Contenido
Introducción ......................................................................................................................................... 2
1.
GESTION DE LAS PRUEBAS Y EL PLAN DE IMPLANTACIÓN ....................................................... 4
a)
Proceso Pruebas de SW en la Organización – EMPESA FINANCIERA ............................ 4
b)
Experiencia en Proceso Pruebas de SW en la Organización ......................................... 4
c)
¿Para qué valen las pruebas? ............................................................................................ 5
d)
Proceso de Pruebas ............................................................................................................. 6
Plan de pruebas ........................................................................................................................... 6
Pruebas de aceptación .............................................................................................................. 7
e)
f)
Problemas enfrentados en la gestión de procesos de pruebas ................................... 8
Tipos de pruebas ...................................................................................................................... 9
Pruebas de caja negra ............................................................................................................... 9
Pruebas funcionales..................................................................................................................... 9
Pruebas de Regresión................................................................................................................ 10
Pruebas de Valores Límites ....................................................................................................... 10
Pruebas de Carga de Ambiente ............................................................................................. 10
Pruebas de Caja Blanca ........................................................................................................... 11
g)
Herramientas de Pruebas de software ............................................................................ 11
h)
Métricas del proceso de Pruebas de software ................................................................. 12
i)
Expectativas sobre el futuro de las pruebas de software ................................................ 12
Objetivos del Proceso ................................................................................................................ 12
Gestión de pruebas ....................................................................................................................... 12
2.
MIGRACIÓN EL PLAN DE IMPLANTACION Y EL ENTORNO..................................................... 14
a)
La necesidad de Migrar: ................................................................................................... 14
b)
Impacto que tiene la migración sobre la organización: .............................................. 14
c)
Tareas para la Migración:.................................................................................................. 15
d)
Estrategias de migración ................................................................................................... 15
i.
Migración en un único paso: ......................................................................................... 15
ii.
Migración piloto: ................................................................................................................. 16
iii.
Migración por grupos: ........................................................................................................ 16
iv.
Migración por usuarios:................................................................................................... 16
e)
CONCLUSIÓN ...................................................................................................................... 17
3

4. -
1. GESTION DE LAS PRUEBAS Y EL PLAN DE IMPLANTACIÓN
a) Proceso Pruebas de SW en la Organización – EMPESA FINANCIERA
HERRAMIENTA DE SOFTWARE
SERVICIOS
b) Experiencia en Proceso Pruebas de SW en la Organización
Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a
través de productos y servicios bancarios, utilizado
las herramientas de software como un medio para
brindar estos productos y servicios de manera confiable y eficiente.
Ciertamente el proceso actual de pruebas de Software en la empresa que represento aún se encuentra en un nivel poco maduro, en relación con otras
empresas dedicadas al desarrollo de software, sin
embargo el área de calidad ha evolucionado constantemente, siempre tratando deminimizar los errores en producción y en pro de garantizar la continuidad del negocio.
Siendo las pruebas parte fundamental en la cadena de valor del desarrollo de software
para minimizar el riesgo de errores o fallas antes de que los sistemas sean utilizados por los
usuarios o clientes finales, convirtiéndose éste en el propósito y alcance de dicho proceso
en el ciclo de vida de un proyecto de software.
Verificar la calidad y funcionamiento de los desarrollos y mantenimientos de
los sistemas y encontrar las deficiencias y fallas de los mismos antes de su liberación a
producción son los objetivos primordiales del proceso.
Han existido en la empresa factores que han contribuido a minimizar el protagonismo del
proceso de calidad de software:
 La falta de cultura entre muchos desarrolladores sobre la importancia de las pruebas de software.
 Los costos necesarios que se deben invertir en la calidad del software.
 El “time to market”.
4

5. -
c) ¿Para qué valen las pruebas?
Las pruebas exitosas son las que encuentran errores
 Las pruebas no pueden demostrar
que el software no tiene Fallos.
 Las pruebas no pueden demostrar
que el software se ajusta a su especificación.
 Las pruebas pueden mostrar la presencia de errores.
 Las pruebas pueden mostrar que los
intentos de hacer fallar el software
con respecto a su especificación fracasaron.
 Las pruebas pueden mostrar que no
se pudo encontrar ninguna disconformidad con respecto a la especificación.
 No se puede probar un programa por
completo
 No siempre se pueden arreglar todos
los errores que se encuentran.
 A veces, cuantas más pruebas, menos errores se encuentran (paradoja
del pesticida).
5

6. -
d) Proceso de Pruebas
Las actividades que se desarrollan dentro
del Departamento de Gestión de Calidad
son las siguientes:
 Revisión de Documentación.
 Ejecución Pruebas de Aceptación.
Plan de pruebas
Documento en el que se diseñan casos de
pruebas, éstos a su vez están conformados
por escenarios de pruebas, los cuales será
ejecutado, en una etapa posterior.
Este es el único documento que se revisa de manera formal, como parte de las actividades del área de Gestión de Calidad, sin embargo al llevar a cabo la revisión del plan de
pruebas, debe revisarse indirectamente los documentos:
 Especificación de Requerimientos de Sistema.
 Especificación de Requerimientos de Software (Diagrama de Casos de Uso, Casos
de Uso en Modelo Extendido).
Objetivo de revisión
En la revisión se amplia y se mejora el plan de pruebas tomando como referencia los documentos mencionados.
Lo que se busca en ésta revisión es que se estén cubriendo todos los posibles escenarios a
probar, se define las prioridades de los escenarios y se asegura que el documento cumpla
con los estándares tanto de forma como de fondo, definidos por la empresa.
Además de acuerdo a la cantidad de escenarios que conformen el plan de pruebas, se
realiza la estimación del tiempo que se requiere para posteriormente ejecutar las pruebas.
6

7. -
Pruebas de aceptación
La estrategia para ejecutar las pruebas, constituye en la ejecución de los casos de prueba
diseñados en el plan de pruebas y algunas otras pruebas que no hayan sido documentadas, pero que partiendo de la experiencia pueden aportar valor.
Las pruebas se realizan prácticamente en la etapa final del desarrollo, antes de salir a
producción.
1. Una vez que el proyecto se encuentre en
ésta etapa, se realiza la
coordinación con el analista y el líder
de negocio para la ejecución de las
pruebas.
2. Las pruebas se ejecutan en un ambiente de pruebas, el cual es similar
al ambiente de producción.
3. Este ambiente es previamente configurado y solicitado por el analista, a
un área dedicada a administrar las versiones de ambientes
y servidores de prueba.
4. En paralelo con ésta actividad el
analista debe preparar los datos de
pruebas que se requieren para la
ejecución de las pruebas.
5. La ejecución de las pruebas se lleva
a cabo en conjunto con el analista
programador y el líder de negocio
que valida que la aplicación cumpla
con lo definido y acordado en los
requerimientos en la etapa de diseño.
6. En caso de que se identifiquen errores o deficiencias de la aplicación
que se está evaluando, se reporta al
analista programador y se documenta para poder darle seguimiento a
los incidentes detectados.
7. El proyecto se devuelve a la etapa
de programación para que los defectos sean corregidos.
7

8. 8. Una vez que el analista corrige los
defectos identificados, debe ejecutase nuevamente las pruebas cuyo
resultado no fue satisfactorio, en caso de que sea requerido se repiten
otras pruebas adicionales para garantiza que las correcciones no afectaran la funcionalidad ya certificada
exitosamente.
9. Una vez finalizada la revisión y certificada la aplicación en conformidad
con los requerimientos y concepciones reales del diseño, se procede a
dar el visto bueno para seguir el flujo
de desarrollo y finalmente que el
proyecto salga a producción.
e) Problemas enfrentados en la gestión de procesos de pruebas
1. No existe un proceso de pruebas definido y publicado para la organización.
2. Resistencia al proceso de pruebas, calidad versus tiempo de entrega.
3. Documentos de Requerimientos de Sistema y Documento de Requerimientos de Software mal diseñados.
4. No hay repositorios eficaces para la documentación de los casos de prueba que
permitan la reutilización de los mismos.
5. Ambientes de prueba limitados e insuficientes.
6. Problemas con la conectividad con terceros y disponibilidad de ambientes de
prueba de terceros.
7. No existen estándares visuales documentados para la interfaz de las aplicaciones con los usuarios.
8. El proceso de pruebas se ejecuta en las etapas finales del proyecto.
9. Datos de prueba difíciles de recolectar
10. Falta de administración de defectos.
11. Disponibilidad de recursos (Gestores de Calidad).
12. Baja calidad del software.
13. No hay seguimiento de las mejoras recomendadas en el proceso de pruebas para
futuros proyectos.
14. No se cuenta con herramientas automatizadas para la ejecución de pruebas.
15. El proceso de pruebas se ejecuta en las etapas finales del proyecto.
8

9. -
f) Tipos de pruebas
Pruebas de caja negra
Las pruebas que realiza el departamento de Gestión de Calidad son pruebas de caja negra. Las
pruebas de caja negra por su lado, son parte integral del proceso de Desarrollo que se lleva a cabo
en la empresa, por lo que ocupan un lugar preponderante.
Dentro de esta categoría existen una serie de tipos de pruebas, entre las que se mencionan:




Pruebas Funcionales.
Pruebas de Regresión.
Pruebas de Valores Límite.
Pruebas de Integración.
Pruebas funcionales
Evalúan el conjunto de características y capacidades de los componentes del sistema.
Aseguran el trabajo apropiado de los requisitos funcionales, incluyendo la navegación,
entrada de datos, procesamiento y obtención de resultados. Se verifica lo siguiente:
 Que se aplique apropiadamente cada regla de negocio.
 Que los resultados esperados ocurran cuando se usen datos válidos.
 Que sean desplegados los mensajes apropiados de error y precaución cuando se
usan datos inválidos.
9

10. -
Pruebas de Regresión
Son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente
se vuelven a realizar, esta vez, sobre en una nueva versión modificada del producto de
software.
Estas pruebas buscan asegurar la calidad después de añadir la nueva funcionalidad a un
componente que se había evaluado anteriormente. El propósito de estas pruebas es asegurar que:
 Los defectos identificados en la ejecución anterior de la prueba se ha corregido.
 Los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores.
Pruebas de Valores Límites
Pruebas diseñadas para evaluar el manejo de error con valores
límites o valores extremos.
Si una condición de entrada está en un rango de valores entre A y
B, se deben diseñar pruebas para los límites A y B, así como para
los valores dentro de los límites y por encima de estos.
Pruebas de Carga de Ambiente
Estas pruebas son ejecutadas por los analistas programadores,
no por el área de Gestión de Calidad.
Las pruebas de carga estudian el programa o componente de
software en condiciones limitadas de volumen, estrés y almacenaje.
Se utiliza la herramienta WebLoad para ejecutar éstas pruebas.
10

11. Pruebas de Caja Blanca
Son llamadas también caminatas de código.
Estas pruebas no son ejecutadas por los Gestores de Calidad, sino son implementadas por
los Líderes Técnicos, con ellas se valida la lógica de implementación en el código fuente
programado o modificado por sus subalternos.
La prueba de caja blanca, denominada a veces prueba de caja de cristal es un método
de diseño de casos de prueba que usa la estructura de control del diseño procedimental
para obtener los casos de prueba. Mediante los métodos de prueba de caja blanca, el
ingeniero del software puede obtener casos de prueba que:
(1) Garanticen que se ejercita por lo menos una vez todos los caminos independientes
de cada módulo.
(2) Ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa.
(3) Ejecuten todos los bucles en sus límites y con sus límites operacionales.
(4) Ejerciten las estructuras internas de datos para asegurar su validez.
g) Herramientas de Pruebas de software
Actualmente en la ejecución de pruebas, no se están utilizando herramientas
automatizadas, sin embargo se está evaluando la necesidad de las mismas y analizando
las siguientes:
 ARCAD Software
o VERIFIER
o EXTRACT
 RATIONAL
o IBM Rational Robot
 ORIGINAL SOFTWARE
o Qualify
o Test-bench
o Test-drive
11

12. -
h) Métricas del proceso de Pruebas de software
Tal y como participa actualmente el área de Gestión de Calidad en el proceso de desarrollo, las métricas se obtienen tomado como referencia lo siguiente:
 Satisfacción del Cliente (mediante una encuesta sobre el servicio recibido).
 Existe un SLA (Service Level Agreement) de tiempo definido para la atención de los
servicios de Gestión de Calidad.
Dado que el software es uno de los activos más importantes para la operativa de la empresa y con el debe garantizarse la continuidad del negocio, esto ha propiciado un mayor
apoyo de las otras gerencias al área de Calidad de Software.
Por esta razón se realizó un análisis exhaustivo sobre las necesidades de la empresa en
relación a la calidad del software y el nivel de madurez en éste campo.
Como resultado de éste análisis se propuso un nuevo proceso de Calidad de Software,
siguiendo el esquema de Centro de Excelencia (CoE), este es un proceso robusto y maduro, el cual se ajusta a las necesidades de cada área de desarrollo.
i) Expectativas sobre el futuro de las pruebas de software
Objetivos del Proceso
 Lograr que los productos se entreguen con niveles consistentes de calidad.
 Que la funcionalidad de los productos cumpla con las expectativas de los clientes.
 Verificar que los requerimientos tengan un nivel de cumplimiento con los objetivos
definidos por el cliente.
 Validar la funcionalidad de los módulos, sistemas e interfaces definidas dentro del
alcance del proyecto.
Gestión de pruebas
Para cada proyecto software, debe definirse una estrategia de prueba
– Visión global de la tarea
– Dirección, prioridades
– Documento de estrategia: Situación hoy + top 10 problemas + posibles soluciones,
cómo abordarlos
– Revisión cada 6 meses o cuando haya el entorno cambios significativos en el proyecto o el entorno.
12

13. -
– Documento de plan de pruebas
Actividades necesarias para llevar a cabo unas pruebas eficaces + herramientas y entorno de pruebas + planificación. Para cada unidad, debe mantenerse un documento de
monitorización de pruebas:
– Casos de prueba esperados y reales
– Cobertura de funcionalidades
– Prioridad de funcionalidades
– Bugs esperados y encontrados
– Bugs por funcionalidad.
Especificación de diseño de pruebas
Qué se prueba, técnica, entorno, criterios de aceptación/rechazo.
Especificación de casos de prueba
Objetivo, especificación, entradas/salidas, dependencias, nº de bugs esperados.
Especificación del proceso de prueba
Release/configuración, pasos para ejecución/medición, procedimiento en caso de error,
criterios de inicio/parada.
Especificación de diseño de pruebas
Qué se prueba, técnica, entorno, criterios de aceptación/rechazo.
Especificación de casos de prueba
Objetivo, especificación, entradas/salidas, dependencias, nº de bugs esperados.
Especificación del proceso de prueba
Release/configuración, pasos para ejecución/medición, procedimiento en caso de error,
criterios de inicio/parada.
13

14. -
2. MIGRACIÓN EL PLAN DE IMPLANTACION Y EL ENTORNO
La mayoría de los proyectos de implantación son también proyectos de Migración, ya que
parten de un escenario en el cual hay un sistema informático basado en software propietario que se encuentra ya en producción.
Los casos de implantación desde cero se dan en organizaciones de nueva creación que
para la puesta en marcha de su primer sistema se orientan hacia una solución basada en
software libre, o bien en organizaciones que hasta ahora no disponían de ningún sistema
informático, lo cual pasa muy pocas veces..
La implantación desde cero es siempre mucho más sencilla que la migración, principalmente porque no se encontrará ningún problema de compatibilidad hacia atrás. No obstante, hay que tener en cuenta que los usuarios del nuevo sistema normalmente estarán
familiarizados con sistemas operativos y aplicaciones de propiedad, por lo que la planificación de la formación es tan importante como en un proyecto de migración.
Proyectos de migración, porque son los que presentan una mayor dificultad y también
porque los proyectos de implementación desde cero se pueden considerar como un subconjunto de los proyectos de migración, con la particularidad que en este caso se tiene
más libertad para decidir el escenario final.
a) La necesidad de Migrar:
•
•
•
•
•
•
Mayor cantidad de servicios informáticos
Nuevas características que cubran las constantes necesidades comerciales.
Mejor Disponibilidad
Mejor Confiabilidad
Mejor Escalabilidad
Mejor Seguridad
b) Impacto que tiene la migración sobre la organización:
•
•
•
•
•
•
La tecnología es una herramienta fundamental para el desarrollo de los negocios
Cuando se migran o actualizan versiones, los objetivos deben de ir acorde a los objetivos del negocio
Sistemas debe participar de las decisiones de negocio
Tanto la dirección como los técnicos deben comunicarse en el mismo idioma
Los cambios en tecnología afectan a toda la organización, incluso a la forma de
hacer negocios
Se debe de buscar el objetivo común de desarrollo Coordinación y establecimiento
de objetivos comunes.
14

15. c) Tareas para la Migración:
•
•
•
•
•
•
•
Desarrollar un plan de implantación
Diseñar una estrategia de migración
Preparar el entorno a migrar
Probar la migración
Realizar una migración piloto
Implantar la migración
Mantener las aplicaciones y servicios de red disponibles
d) Estrategias de migración
Como en todo proyecto, una planificación correcta es una condición imprescindible para
asegurar el éxito de la migración a un sistema .Sin embargo, según la planificación de la
migración, se pueden extrapolar cuatro grandes estrategias de migración:
i.
Migración en un único paso:
Implica llevar a cabo todo el proceso de migración en un corto espacio de tiempo, si
puede ser en un solo día, o en días de fiesta. Esta estrategia es la más económica y se suele aplicar en sistemas de dimensiones reducidas, con pocos clientes y un único servidor,
por ejemplo en el caso de pequeñas empresas.
15

16. ii.
Migración piloto:
Implica llevar a cabo, en primer lugar, la migración de una pequeña parte del sistema,
con la cual se practicará y evaluará el éxito de la migración, antes de proceder a la implantación en el resto del sistema. El sistema piloto consiste en unos cuantos servidores y
máquinas cliente, incluso podría tratarse de un solo servidor y una sola máquina cliente. Si
bien una planificación correcta es muy importante, esta estrategia permite una mayor
flexibilidad para modificar el planteamiento de la migración y corregir posibles problemas.
iii.
Migración por grupos:
Implica definir grupos de usuarios
según sus características funcionales y llevar a cabo la migración
gradualmente con cada uno de
estos grupos. Una de las principales
ventajas de esta estrategia es que
permite minimizar los riesgos e ir
aprendiendo en cada una de las
migraciones.
iv.
Migración por usuarios:
Es similar a la migración por grupos, con la particularidad que sólo se
migra un usuario cada vez. En consecuencia, esta estrategia necesita muy pocos recursos pero es inviable en organizaciones grandes y
medianas, en las cuales el elevado número de usuarios prolongaría
durante demasiado tiempo la migración.
16

17. -
e) CONCLUSIÓN
A partir de lo planteado podemos concluir que el principal objetivo del diseño de casos
de prueba es obtener un conjunto de pruebas que tengan la mayor probabilidad de descubrir los defectos del software. Para llevar a cabo este objetivo, se usan dos categorías
diferentes de técnicas de diseño de casos de prueba: prueba de caja blanca y prueba
de caja negra.
Las pruebas de caja blanca se centran en la estructura de control del programa. Se obtienen casos de prueba que aseguren que durante la prueba se han ejecutado, por lo
menos una vez, todas las sentencias del programa y que se ejercitan todas las condiciones
lógicas
Las pruebas de caja negra son diseñadas para validar los requisitos funcionales sin fijarse
en el funcionamiento interno de un programa. Las técnicas de prueba de caja negra se
centran en el ámbito de información de un programa, de forma que se proporcione una
cobertura completa de prueba.
A la vez llegamos a concluir que la solución de Informática para la migración de datos
automatiza y agiliza los procesos de migración de datos con una combinación de tecnología, metodología y servicios. Esta solución está formada por una tecnología de integración de datos integral, abierta y unificada que permite la migración de los datos. Incluye
una metodología de migración de datos probada, que se basa en las mejores prácticas,
así como ofertas de servicios de migración de datos dando a las organizaciones la posibilidad de otorgar servicios de una manera más rápida y segura.
17