Gestión de las pruebas y el plan de implantación

Migración del plan de marketing y el entorno

INTEGRANTES:

DE LA CRUZ HERNANDEZ ZAIDA

HUANCAHUARI MENDOZA PAMELA

LLANOS CASTILLA RANDAL

MELGAR ESCATE FERNANDO

-

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 pue-

den empezar a darse desde el primer momento del proceso, en el que los objetivos pue-

den 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 de-

finidos tanto funcionales como no funcionales, así como cuanto de resistente es la aplica-

ció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 prue-

bas 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.

-

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) Problemas enfrentados en la gestión de procesos de pruebas ................................... 8

f) 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

-

4

1. GESTION DE LAS PRUEBAS Y EL PLAN DE IMPLANTACIÓN

a) Proceso Pruebas de SW en la Organización – EMPESA FINANCIERA

b) Experiencia en Proceso Pruebas de SW en la Organización

Resulta importante mencionar que ésta es una em-

presa cuya actividad principal está enfocada a sa-

tisfacer 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 con-

fiable y eficiente.

Ciertamente el proceso actual de pruebas de Soft-

ware en la empresa que represento aún se encuen-

tra en un nivel poco maduro, en relación con otras

empresas dedicadas al desarrollo de software, sin

embargo el área de calidad ha evolucionado cons-

tantemente, siempre tratando de minimizar los erro-

res 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 prue-

bas de software.

Los costos necesarios que se deben invertir en la calidad del software.

El “time to market”.

HERRAMIENTA DE SOFTWARE SERVICIOS

-

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 especi-

ficación.

Las pruebas pueden mostrar la pre-

sencia de errores.

Las pruebas pueden mostrar que los

intentos de hacer fallar el software

con respecto a su especificación fra-

casaron.

Las pruebas pueden mostrar que no

se pudo encontrar ninguna discon-

formidad con respecto a la especifi-

cació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, me-

nos errores se encuentran (paradoja

del pesticida).

-

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 activida-

des 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 do-

cumentos 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.

-

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 documenta-

das, 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 encuen-

tre 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 am-

biente de pruebas, el cual es similar

al ambiente de producción.

3. Este ambiente es previamente confi-

gurado y solicitado por el analista, a

un área dedicada a admi-

nistrar 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 erro-

res o deficiencias de la aplicación

que se está evaluando, se reporta al

analista programador y se documen-

ta para poder darle seguimiento a

los incidentes detectados.

7. El proyecto se devuelve a la etapa

de programación para que los de-

fectos sean corregidos.

-

8

8. Una vez que el analista corrige los

defectos identificados, debe ejecu-

tase nuevamente las pruebas cuyo

resultado no fue satisfactorio, en ca-

so de que sea requerido se repiten

otras pruebas adicionales para ga-

rantiza que las correcciones no afec-

taran la funcionalidad ya certificada

exitosamente.

9. Una vez finalizada la revisión y certifi-

cada la aplicación en conformidad

con los requerimientos y concepcio-

nes 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 Requerimien-

tos 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 aplica-

ciones 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.

-

9

f) Tipos de pruebas

Pruebas de caja negra

Las pruebas que realiza el departamento de Ges-

tión de Calidad son pruebas de caja negra. Las

pruebas de caja negra por su lado, son parte inte-

gral del proceso de Desarrollo que se lleva a cabo

en la empresa, por lo que ocupan un lugar prepon-

derante.

Dentro de esta categoría existen una serie de tipos de pruebas, entre las que se mencio-

nan:

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.

-

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 ase-

gurar 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 de-

fectos 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 almace-

naje.

Se utiliza la herramienta WebLoad para ejecutar éstas pruebas.

-

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

-

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 desa-

rrollo, 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 em-

presa 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 madu-

ro, 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 pro-

yecto o el entorno.

-

13

– Documento de plan de pruebas

Actividades necesarias para llevar a cabo unas pruebas eficaces + herramientas y en-

torno 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.

-

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 propie-

tario 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, principal-

mente porque no se encontrará ningún problema de compatibilidad hacia atrás. No obs-

tante, 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 planifi-

cació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 sub-

conjunto 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 ob-

jetivos 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.

-

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 sue-

le aplicar en sistemas de dimensiones reducidas, con pocos clientes y un único servidor,

por ejemplo en el caso de pequeñas empresas.

-

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 im-

plantació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 funciona-

les 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 necesi-

ta 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.

-

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 des-

cubrir 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 ob-

tienen 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 tecno-

logía, metodología y servicios. Esta solución está formada por una tecnología de integra-

ció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 posibi-

lidad de otorgar servicios de una manera más rápida y segura.