sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible
Soy el cliente de la aplicación que deseo Eres el jefe de proyecto de la aplicación Soy un miembro del equipo directivos de tu empresa

  • ¿Sabrías qué y cómo preguntarme, en qué orden y hasta qué nivel de detalle y cuándo?

  • ¿Cuál sería el formato adecuado del resultado de las reuniones?

  • ¿Cómo repartirías las tareas de requisitos entre las personas del equipo de desarrollo? ¿Con cuántas personas empezarías?

  • ¿Por qué parte comenzarías, continuarías y terminarias la producción de código?

  • ¿Qué medidas aplicarías para obtener la calidad del software adecuada para facilitar la depuración de errores, la mantenibilidad corrective, perfective o adaptativa?

  • ¿Cómo repartirías las tareas de producción entre las personas del equipo de desarrollo?

  • ¿Cuánta gente incorporarías?

  • ¿Sabrías justificarme mes a mes qué tiempo se tardará en terminar el proyecto con el personal asignado en distintos momentos de proyecto?

  • ¿Sabrías justificarme el grado de satisfacción del cliente durante el transcurso del proyecto?

  • ¿Sabrías justificarme cuántas personas añadir al proyecto para reducir el tiempo de desarrollo?

¿Qué?

  • Flujo de trabajo (realización de un caso de uso que incluye trabajadores, actividades y diagramas) cuyo principal propósito es comprobar el resultado de la implementación probando cada construcción, incluyendo construcciones de versiones intermedias y final que se entregará

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad necesaria

davidProyectoImplantacionDiseño

arbolMantenible

Encontrar y documentar errores en el producto de software: defectos, problemas.

Asesorar a la dirección sobre la calidad del software percibida

Evaluar las suposiciones hechas en las especificaciones de diseño y de requisitos a través de una demostración concreta

Validar que el producto de software funciona como se diseño

Validar que los requisitos son implementados apropiadamente

¿Cómo?

Actividades

Tests

Introduccion

Planificar Pruebas

Plan Tests

PlanificarPruebas
Describir una estrategia de prueba para la iteración Estimar los requisitos para el esfuerzo de prueba Planificación del esfuerzo de prueba

  • Qué sujeto bajo prueba, SUT, ejecutar, cómo ejecutarlos, cuándo ejecutarlos y cómo determinar que el esfuerzo de prueba es exitoso

  • Como los recursos del sistema y humanos necesarios

    • El principio general es desarrollar casos de prueba y procedimientos con una superposición mínima para probar los casos de uso más importantes y para probar los requisitos que están asociados con el mayor riesgo

Diseñar Pruebas

designTest

DiseñarPruebas
Diseño de casos de prueba de integración. Diseño de casos de prueba de sistemas.

  • Encontrar un conjunto de casos de prueba con una superposición mínima, cada uno de los cuales prueba una ruta o escenario interesante a través de la realización de un caso de uso.

    • Considerar los diagramas de interacción de las realizaciones de casos de uso como entrada

    • Buscan una combinación de entrada, salida y estado de inicio del sistema del actor que conducen a escenarios interesantes que emplean clases que participan en los diagramas.

    • Capturan las interacciones reales de los objetos dentro del sistema.

    • Luego, comparan esas interacciones reales con el diagrama de interacción.

    • Deberían ser iguales; de lo contrario, se detecta un defecto

  • Prueba principalmente combinaciones de casos de uso instanciados en diferentes condiciones, incluidas diferentes configuraciones de hardware, diferentes niveles de cargas del sistema, varios números de actores y diferentes tamaños de la base de datos.

  • Los diseñadores de pruebas deben priorizar las combinaciones de casos de uso que:

    • Se requieren para funcionar en paralelo.

    • Es probable que se realicen en paralelo

    • Es probable que se influyan entre sí si se realizan en paralelo

    • Involucrar múltiples procesos

    • Utilizar con frecuencia los recursos del sistema, como procesos, procesadores, bases de datos y software de comunicación, quizás de formas complejas e impredecibles.
Diseño de casos de prueba de regresión. Identificación y estructuración de procedimientos de prueba.

  • Algunos casos de prueba de construcciones anteriores pueden usarse para pruebas de regresión en construcciones posteriores, pero no todos los casos de prueba son adecuados para pruebas de regresión.

  • Intentamos reutilizar los procedimientos de prueba existentes tanto como sea posible, lo que significa que es posible que tengamos que modificarlos para que se utilicen para especificar cómo realizar un caso de prueba nuevo y/o modificado

Implementar Pruebas

implementTest

ImplementarPruebas
Automatizar los procedimientos creando componentes de prueba

  • Cuando utilizamos una herramienta de automatización de pruebas, realizamos o especificamos las acciones descritas en los procedimientos de prueba.

    • Estas acciones luego se registran, dando como resultado un componente de prueba

  • Al programar el componente de prueba de forma explícita, utilizamos los procedimientos de prueba como las especificaciones principales del esfuerzo de programación

  • Los componentes de la prueba a menudo usan grandes cantidades de datos de entrada para ser probados y procesan grandes cantidades de datos de salida como resultados de la prueba.

    • Es útil poder visualizar estos datos de forma clara e intuitiva para que se puedan especificar correctamente y se puedan interpretar los resultados de las pruebas.

    • Usamos aplicaciones de hojas de cálculo y bases de datos para este propósito.

Realizar Pruebas de Integración

performIntegrationTests

Realizarpruebas
Pruebas de integración necesarias para cada construcción creada dentro de una iteración

  • Realice las pruebas de integración relevantes para la construcción realizando manualmente los procedimientos de prueba para cada caso de prueba o ejecutando cualquier componente de prueba automatizando los procedimientos de prueba

  • Compare los resultados de la prueba con los resultados esperados e investigue los resultados de la prueba que se desvíen de lo esperado

  • Informe los defectos al ingeniero de componentes que es responsable de los componentes que probablemente contengan la falla

  • Informar los defectos a los diseñadores de pruebas, quienes luego utilizan los defectos para evaluar los resultados generales del esfuerzo de prueba.

Realizar Pruebas de Sistemas

performSystemTest

RealizarPruebas2

  • Las pruebas del sistema pueden comenzar cuando las pruebas de integración indican que el sistema cumple con los objetivos de calidad de integración establecidos en el plan de prueba para la iteración actual

    • Es decir, el 95% de los casos de prueba de integración se ejecutan con un resultado esperado

  • Las pruebas del sistema se realizan de forma análoga a las pruebas de integración

Evaluar Pruebas

evaluateResult

EvaluarPruebas

  • Los diseñadores de prueba evalúan los resultados del esfuerzo de prueba comparando los resultados con los objetivos descritos en el plan de prueba.

    • Preparan métricas que les permiten determinar el nivel de calidad del software y determinar cuántas pruebas más se deben realizar:

  • Integridad, que se deriva de la cobertura de casos de prueba y la cobertura de los componentes probados.

    • Esto indica qué porcentaje de los casos de prueba se han ejecutado y el porcentaje del código que se ha probado

  • Fiabilidad, que se basa en análisis de tendencias en los defectos descubiertos y en tendencias en las pruebas que se ejecutan con un resultado esperado.

  • No parchear, reescribirlo

  • A menudo, puede ser mucho más barato y menos doloroso tirar un fragmento de código que tiene un montón de errores y reescribirlo desde cero

Síntesis

sintesis

Eres el jefe de proyecto de la aplicación:

  • ¿Sabrías justificarme mes a mes qué tiempo se tardará en terminar el proyecto con el personal asignado en distintos momentos de proyecto?

  • ¿Sabrías justificarme el grado de satisfacción del cliente durante el transcurso del proyecto?

  • ¿Sabrías justificarme cuántas personas añadir al proyecto para reducir el tiempo de desarrollo?

  • Proyectando las estimaciones de las actividades pasadas sobre el futuro en las actividades pendientes

  • Curva de Porcentajes de Casos de Uso completados frente a los planificados iteración a iteración

  • Estimando cada actividad, entre 2 y 20 horas, y

  • Repartiendo cohesivamente entre el equipo de desarrollo incorporado

  • …​ con trazabilidad de todo!

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada

  • Unified Software Development Process

    • Grady Booch, Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (1999)

height32

  • Rational Unified Process Made Easy, The: A Practitioner’s Guide to the RUP

    • Grady Booch, , Ivar Jacobson y James Rumbaugh

    • Addison-Wesley; (2003)

height32

  • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

    • Craig Larman

    • Pearson; (2004)

height32

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Benjamin Cummings; (1995)

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Addison-Wesley; (2011)

height32

  • The Unified Modeling Language User Guide

    • Grady Booch

    • Pearson; (2005)

height32

  • UML Distilled. A Brief Guide to the Standard Object Modeling Language

    • Martin Fowler,Kendall Scott

    • Addison-Wesley; (2003)

height32

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM