Gestion de pruebas y migraciones (0)

  • 268 views
Uploaded on

Gestion de pruebas y migraciones

Gestion de pruebas y migraciones

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
268
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
11
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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