Trabajo de Clase 1.Realice la lectura correspondiente 2.Define los siguientes parámetros: a.Lenguaje de trabajo b.Selección del IDE c.Selección de la metodología.

Presentación del tema: "Trabajo de Clase 1.Realice la lectura correspondiente 2.Define los siguientes parámetros: a.Lenguaje de trabajo b.Selección del IDE c.Selección de la metodología."— Transcripción de la presentación:

1 Trabajo de Clase 1.Realice la lectura correspondiente 2.Define los siguientes parámetros: a.Lenguaje de trabajo b.Selección del IDE c.Selección de la metodología d.Identificación del líder del equipo de trabajo e.Definición de las estrategias de comunicación f.Definición de repositorios y versionamiento g.Definición de curvas de aprendizaje Fuente: G. Myers

2 Calidad de Software Fuente: Imágenes Google

3 Calidad de Software Puntos de Vista: 1.Trascendental: Prevé la calidad como algo que puede ser reconocido pero es difícil de definir. 2.Del usuario: Se percibe la calidad como aptitud para el uso. De acuerdo con este punto de vista, mientras se evalúa la calidad de un producto, se debe preguntar: "¿El producto satisface las necesidades y expectativas de los usuarios?“ 3.Del Fabricante: la calidad se entiende como la conformidad con la especificación. El nivel de calidad de un producto se determina por el grado en que el producto cumple sus especificaciones. 4.Del Producto: la calidad se ve como conjunto de características intrínsecas del producto. Características inherentes de un producto, es decir, las cualidades internas, determinan sus cualidades externas. 5.Basado en Valor: depende de la cantidad que el cliente está dispuesto a pagar por ello.

4 Según Pressman (1998): “Concordancia del software producido con los requisitos funcionales y de rendimiento explícitamente establecido, con los estándares de desarrollo y con las características implícitas que se espera del software desarrollado profesionalmente” (IEEE Std. 610-1990) [IEEE, 1993]: Grado con el que un sistema, componente o proceso cumple: a.Los requisitos especificados b.Las necesidades o expectativas del cliente o usuario. Calidad del software

5 Los requisitos establecidos explícitamente se reflejan en el documento de especificación de requisitos del sistema (ERS): a.Requisitos funcionales: funciones a realizar por el software. b.Requisitos no funcionales o extendidos: requisitos de seguridad, rendimiento, interfaz... Los estándares y las normas de desarrollo permiten que se consiga una calidad técnica. Calidad del software

6 La calidad del SW debe tenerse en cuenta a dos niveles: a.A nivel de empresa: para conseguir software de calidad, las organizaciones deben tener una estructura organizativa apropiada para fomentar el trabajo por la calidad de todas las personas y departamentos de la empresa, además de fomentar procesos específicos para asegurar la calidad. b.A nivel de proyecto: se trata de llevar a la práctica en las actividades cotidianas las disposiciones fijadas en el sistema de calidad. Se aplica durante todo el proceso de ingeniería del software, es decir, en Análisis, Diseño, Codificación y Prueba. Calidad del software

7 Fuente: Google Imágenes Calidad del software

8 Serie de técnicas, métodos, modelos y guías de buenas prácticas que tienen como fin último garantizar la bondad de los resultados que se obtienen en los proyectos de desarrollo software. La búsqueda y aseguramiento de unos resultados de calidad en cualquier ingeniería, resulta necesaria y se debe contemplar de manera intrínseca en el desarrollo. Desarrollar un software de calidad va a requerir el seguimiento de una serie de estándares, de una serie de referentes en buenas prácticas y del uso de medidas objetivas que permitan observar, medir y controlar aspectos tanto cuantitativos como cualitativos de los resultados Fuente: INES Calidad del software

9 Conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza adecuada en que el producto (software) satisfará los requisitos dados de calidad. El Aseguramiento busca dar confianza en que el producto tiene calidad. Se enfoca en identificar y evaluar los defectos que puedan afectar al software. Si los errores se pueden identificar de forma temprana en el proceso de software, las características del diseño de software se pueden especificar de modo que eliminarán o controlarán los peligros potenciales, al corregir los errores mucho antes en cada etapa es decir durante el proceso, ahorrando esfuerzos, tiempo y recursos. Aseguramiento de Calidad de Software

10 Mientras el software que se está desarrollando reúne los requerimientos y se espera que su desempeño sea el esperado, es preciso que se supervisen las actividades de desarrollo del software y su rendimiento, en distintas oportunidades durante cada fase del ciclo de vida. Este es el papel del aseguramiento de la calidad del software. (Sridharan, 2000) Aseguramiento de Calidad de Software

11 1.La calidad no se puede probar, se construye. 2.El aseguramiento de la calidad del software no es una tarea que se realiza en una fase particular del ciclo de vida de desarrollo. 3.Las actividades asociadas con el aseguramiento de la calidad del software deben ser realizadas por personas que no estén directamente involucradas en el esfuerzo de desarrollo. (Wiegers, 1990)

12 Control de Calidad de Software Control de Calidad: Conjunto de actividades para evaluar la calidad de los productos desarrollados. Implica vigilar el proceso de desarrollo de software para asegurar que se siguen los procedimientos y los estándares de garantía de calidad, en el proceso de control de calidad se comprueba que las entregas cumplan con los estándares definidos. Consiste en revisar que al final el producto cumpla los requerimientos del cliente. Fuente: http://www.qualitrain.com.mx

13 El control de calidad del software abarca todo el proceso de desarrollo: supervisar y mejorar el proceso, asegurar que se siguen los procedimientos acordados, que se alcanza el nivel de calidad deseado y que se localizan y resuelven los problemas. Fuente: http://www.qualitrain.com.mx Control de Calidad de Software

14 a.Un factor de calidad representa una característica del comportamiento de un sistema. Algunos ejemplos de los factores de calidad de alto nivel son la exactitud, la fiabilidad, la eficiencia, la capacidad de prueba, mantenimiento y reutilización. b.Un criterio de calidad es un atributo de un factor de calidad que se relaciona con el desarrollo de software. Por ejemplo, la modularidad es un atributo de la arquitectura de un sistema de software McCall, Richards, y Walters fueron los primeros en estudiar el concepto de la calidad del software en términos de factores de calidad y criterios de calidad.

15 Las pruebas del software (software testing) son parte del proceso de control de calidad del software (SQA), donde especialistas en procesos de software y auditores están preocupados por el proceso de desarrollo de software en lugar de los artefactos, tales como documentación, código y sistemas. Ellos examinan y cambian el proceso de ingeniería del software en sí para reducir la cantidad de errores en el software entregado: denominada tasa de defectos. Lo que constituye una “Aceptable tasa de defectos” depende de la naturaleza del software. Fuente: Wiki Apache OpenOffice Pruebas de Software

16 Las pruebas de software son una tarea destinada a detectar los defectos en el software contrastando los resultados esperados de un programa informático con los resultados reales de un conjunto dado de entradas. Por el contrario, QA (control de calidad) es la implementación de las políticas y procedimientos destinados a prevenir los defectos que se produzcan en primer lugar. Fuente: Wiki Apache OpenOffice Pruebas de Software

17 PAPEL DE LA PRUEBA Las pruebas juegan un papel importante en el logro y la evaluación de la calidad de un producto de software. a.Se mejora la calidad de los productos, cuando se repite el ciclo probar – encontrar defectos – arreglar, durante el desarrollo. b.Se evalúa estado del sistema cuando se hacen pruebas de alto nivel, antes de liberar el productos de software. Las pruebas de software configuran un proceso de evaluación y mejora de la calidad de software.

18 Se pueden dividir en dos categorías generales : a.Análisis estático : se basa en el examen de una serie de documentos, denominados documentos de requerimientos, modelos de software, documentos de diseño y código fuente. El análisis estático tradicional incluye la revisión de código, la inspección walk-through, el análisis de algoritmos y prueba de la corrección. No se trata de la ejecución real del código en fase de desarrollo. En su lugar, se analiza el código y las razones de posibles comportamientos que puedan surgir durante la ejecución. Las optimizaciones del compilador son análisis estático estándar. b.Análisis dinámico : Consiste en la ejecución real del programa con el fin de exponer los posibles fallos del programa. También se observan las propiedades de comportamiento y rendimiento del programa. Los programas se ejecutan con tanto con entradas típicas como atípicas. Las actividades de evaluación de la calidad del software

19 Verificación Actividad centrada en la evaluación de un software mediante la determinación de si el producto de una fase de desarrollo dado satisface los requisitos establecidos antes del inicio de esa fase; ya sea un producto intermedio, como la especificación de requisitos, especificaciones de diseño, código, manual de usuario, o incluso el producto final. Validación Permiten confirmar que un producto cumple con su uso previsto. Tienen por objeto confirmar que un producto cumple con las expectativas de sus clientes. En otras palabras, se centran en el producto final, que está ampliamente probado desde el punto de vista del cliente. La Validación establece si el producto cumple con las expectativas generales de los usuarios. Las actividades de evaluación de la calidad del software

20 Verificación: Las actividades de verificación se realizan sobre los productos intermedios mediante la aplicación de técnicas de análisis estático en su mayoría, como la inspección paso a paso, y las revisiones, y el uso de normas y listas de verificación. Validación: La validación se realiza en todo el sistema, ejecutándolo en su entorno real y el uso de una variedad de pruebas.

21 Fracaso: El fracaso se dice que ocurre cada vez que el comportamiento externo de un sistema no se ajusta a lo prescrito en la especificación del sistema. Error: Un error es un estado del sistema. En ausencia de cualquier acción correctiva por parte del sistema, un estado de error podría dar lugar a un fallo que no se puede atribuir a ningún hecho posterior al error. Fallo: Una falla es la causa adjudicada a un error.

22 Fiabilidad del Software Probabilidad de funcionamiento libre de fallos, de un sistema de software por un tiempo determinado en un entorno determinado. El nivel de fiabilidad de un sistema depende de las entradas que causan las fallas que son observadas por los usuarios finales. La fiabilidad del software se puede estimar a través de las pruebas al azar. Dado que la noción de fiabilidad trata un "entorno especificada", los datos de prueba deben ser extraídas de la distribución de entradas de la futura utilización del sistema. Capturar el patrón de uso futuro de un sistema en un sentido general se describe como el perfil operativo.

23 OBJETIVOS DE LA PRUEBA Interesados: Persona o una organización que influye en los comportamientos de un sistema o que está afectado por ese sistema. Ej: programadores, los ingenieros de pruebas, los responsables del proyecto y los clientes. Las diferentes partes interesadas consideran un proceso de prueba desde diferentes perspectivas: No funciona: el programador puede querer comprobar si el producto funciona en condiciones normales. El programador pone mucha confianza en que el modulo funcione a satisfacción. Por la razón psicológica, el objetivo de la prueba es para mostrar que el sistema funciona, en lugar de lo que no funciona

24 No funciona Una vez que el programador (o el equipo de desarrollo ) esta seguro que una unidad (o el sistema ) funciona hasta cierto punto, se ejecutan pruebas con el objetivo de encontrar fallas en la unidad (o la de reducir el riesgo de fallo) La mayoría de los sistemas de software complejos contienen fallas, las cuales hacen que el sistema de fallar de vez en cuando. Este concepto de " defecto de vez en cuando “ da lugar a la noción de la tasa media de fracaso que se descubren y se fijaron en el desempeño de las fallas.

25 Reducir el costo de las pruebas: Los diferentes tipos de costos asociados a un proceso de pruebas son: a.el costo de diseñar, mantener, y ejecución de casos de prueba b.el coste de analizar el resultado de la ejecución de cada caso de prueba, c.el costo de la documentación de los casos de prueba, y d.el costo real de la ejecución del sistema y documentarla.

26 A menudo, el conjunto de entrada de un programa puede ser externadamente grande. Para consideraciones prácticas, un conjunto finito de entradas puede ser seleccionado. Por lo tanto, en las pruebas se observan algunos comportamientos representativos del programa y se obtiene conclusiones acerca de la calidad del sistema. La selección cuidadosa del conjunto finito de prueba es crucial para llegar a una conclusión fiable QUÉ ES UN CASO DE PRUEBA ?

27 Es una simple pareja de. Por ejemplo, si se prueba un programa para calcular la raíz cuadrada de números no negativos, se tendría:

28 Sistemas sin estado El resultado depende únicamente de la entrada actual. Los casos de prueba son Un compilador para el lenguaje de programación C es otro ejemplo de un sistema sin estado: para compilar un programa que no necesita saber acerca de los programas que compilan previamente.

29 Sistemas orientados por el Estado El resultado del programa depende tanto del estado actual del sistema como de la entrada de corriente. Un caso de prueba puede consistir secuencias de. Un sistema de conmutación telefónica y un cajero automático son ejemplos de sistemas orientados por el Estado. Para un cajero automático, se muestra un caso de prueba para probar la función de retirar:

30 En el caso de prueba TS1: a.Se supone que la cuenta de usuario tiene $ 500, y el usuario quiere retirar una cantidad de $ 200. b.En la tercera tupla, el dinero solicitado al cajero: "$ 200”. c.Después de la operación de retiro, el usuario se asegura de que el saldo restante es de $ 300.00. Para los sistemas orientados por el estado, la mayoría de los casos de prueba incluyen algún tipo de decisión en el suministro de entrada al sistema. Un caso de prueba puede incluir bucles y contadores de tiempo.

31 RESULTADO ESPERADO Un resultado esperado de la ejecución de un programa es una entidad compleja que puede incluir lo siguiente: a.Los valores producidos por el programa: Salidas de observación locales (entero, texto, audio, imagen) Salidas (mensajes) para el almacenamiento remoto, manipulación, o la observación b.Cambio de estado: Cambio de estado del programa El cambio de estado de la base de datos (debido a añadir, eliminar y operaciones de actualización) c.Una secuencia o conjunto de valores que deben ser interpretado juntos para constituir una salida valida

32 RESULTADO ESPERADO Un concepto importante en el diseño de la prueba es el concepto de un ORACLE, que es cualquier entidad de programa, proceso, experto humano, o cuerpo de datos, que muestra el resultado esperado de una prueba o conjunto de pruebas. Un caso de prueba sólo tiene sentido si es posible decidir sobre la aceptabilidad de los resultados producidos por el programa bajo prueba.

33 El resultado esperado de una prueba debe ser obtenido al diseñar el caso de prueba: El resultado de la prueba se calcula antes de que el programa se ejecuta con la entrada de prueba seleccionado. Se debe ser capaz de calcular el resultado esperado de una comprensión de los requisitos del programa. Esto eliminará cualquier sesgo de aplicación en caso de que el caso de prueba está diseñado por el desarrollador. En casos excepcionales, en los que es muy difícil calcular un único resultado esperado, se debe identificar los resultados esperados mediante el examen de los resultados reales de las pruebas, tal como se explica en el siguiente: a.Ejecutar el programa con la entrada seleccionada. b.Observe el resultado real de la ejecución del programa. c.Verifique que el resultado real es el resultado esperado. d.Utilice el resultado real verificado como el resultado que se espera en las siguientes ejecuciones del caso de prueba.

34 CONCEPTO DE PRUEBA COMPLETA He probado de forma exhaustiva el programa??? Para la mayoría de los sistemas, la prueba completa es casi imposible debido a las siguientes razones : a.El dominio de las posibles entradas de un programa es demasiado grande para ser utilizado por completo en la prueba de un sistema. b.Hay dos tipos de entradas: válidas y no válidas. c.El programa puede tener un gran número de estados. d.Puede haber limitaciones de tiempo en las entradas, es decir, una entrada puede ser válido en un momento determinado y no válido en otros momentos. e.Un valor de entrada válido que no es ingresado a tiempo se llama una entrada inoportuno. El dominio de entrada de un sistema puede ser muy grande para ser utilizado por completo en la prueba de un programa.

35 CONCEPTO DE PRUEBA COMPLETA Las características del diseño pueden ser demasiado complejas para completar la prueba. El diseño puede haber incluido las decisiones implícitas y suposiciones. Por ejemplo, un programador puede utilizar una variable global o una variable estática para controlar la ejecución del programa. Podría no ser posible crear todos los posibles entornos de ejecución del sistema. Esto cobra importante cuando el comportamiento del sistema de software depende de características del mundo real, tales como el clima, la temperatura, la altitud, la presión y así sucesivamente

36 Aspectos a Tener en Cuenta Dado que una prueba completa es una tarea casi imposible, la mejor opción es seleccionar un subconjunto del dominio de entrada para poner a prueba un programa.

37 Aspectos a Tener en Cuenta Sea D el dominio de entrada de un programa P. Supongamos que seleccionamos un subconjunto de D1 de D (D1 ⊂ D), para poner a prueba el programa P. Es posible que los datos D1 prueben sólo la parte P1 de P (P1 ⊂ P), por lo que falla con la otra parte P2, pasando desapercibidos sus comportamiento. Mediante la selección de un subconjunto del dominio de entrada D1, el ingeniero de pruebas intenta deducir las propiedades de un programa P mediante la observación del comportamiento de una parte P1, de todo el comportamiento de P, a través de las entradas seleccionadas D1. Por lo tanto, la selección del subconjunto del dominio de entrada debe hacerse de una manera sistemática y cuidadosa de manera que la deducción sea tan precisa y completa como sea posible.

38 Con el fin de probar un programa, un ingeniero de pruebas debe realizar una serie de actividades de prueba, como las siguientes: a.Identificar un objetivo para ser evaluado: La primera actividad consiste en identificar un objetivo para ser probado. El objetivo define la intención o la finalidad de diseñar uno o más casos de prueba para asegurar que el programa es compatible con el objetivo. Un objetivo claro debe estar asociado a cada caso de prueba. ACTIVIDADES DE PRUEBA

39 b.Seleccione las entradas: Esta selección se puede basar en la especificación de requisitos, el código fuente o nuestras expectativas. Las entradas de prueba se seleccionan manteniendo el objetivo de la prueba en mente. c.Calcular el resultado esperado: En la mayoría de los casos, esto se puede hacer a partir de la comprensión de alto nivel del objetivo de la prueba y la especificación del programa bajo prueba. d.Configurar el entorno de ejecución del programa: preparar el entorno de ejecución del programa. Todos los supuestos externos al programa deben cumplirse, por ejemplo: Inicializar el sistema local, externo al programa. Esto puede incluir la realización de una conexión de red disponible, haciendo que el sistema de base de datos este disponible. Inicializar cualquier sistema remoto desde el exterior ( por ejemplo, el proceso de remoto en una aplicación distribuida). ACTIVIDADES DE PRUEBA

40 Ejecutar el programa El ingeniero de pruebas ejecuta el programa con las entradas seleccionadas y observa el resultado real del programa. Las entradas pueden ser proporcionados al programa en diferentes ubicaciones físicas en diferentes momentos. El concepto de coordinación prueba se utiliza en la sincronización de diferentes componentes de un caso de prueba. Analizar el resultado de la prueba La tarea principal es comparar el resultado real de la ejecución del programa, con el resultado esperado. La complejidad de la comparación depende de la complejidad de los datos que deben ser observadas. El tipo de datos observada puede ser tan simple como un entero o una cadena de caracteres o tan complejo como una imagen, un vídeo o un clip de audio. ACTIVIDADES DE PRUEBA

41 Al final de la etapa de análisis, se identifica un resultado de la prueba, el cual puede ser: a.El programa produce el resultado esperado y el propósito del caso de prueba se cumple, entonces se le asigna “Paso”. b.El programa no produce el resultado esperado, a continuación, se le asigna un veredicto “Fallo”. c.Sin embargo, en algunos casos puede no ser posible asignar resultado. Por ejemplo, si un tiempo de espera se produce durante la ejecución de un caso de prueba en una aplicación distribuida, es posible que no estén en condiciones de asignar un resultado. En esos casos, se le asigna un resultado “No concluyente”. Este resultado define que se deben hacer mas pruebas para “Pasar” o “Fallar” en la prueba. Informe del resultados : su objetivo es identificar los fallos que deben ser arreglados. Contiene los siguientes elementos: I.Explique cómo reproducir el fallo. II.Analizar la falla. III.Descripción del resultado real y el caso de prueba, con las respectivas entradas y el entorno de ejecución ACTIVIDADES DE PRUEBA

42 Niveles de Pruebas

43 FUENTES DE INFORMACIÓN PARA LA SELECCIÓN DE CASO DE PRUEBA Con el fin de generar pruebas eficaces a un costo menor, diseñadores de pruebas analizan las siguientes fuentes de información: a.Requisitos y especificaciones funcionales: la naturaleza y la cantidad de necesidades de usuario identificadas. b.El código fuente: describe el comportamiento actual del sistema. c.dominios de entrada y salida: algunos dominios de entrada tiene significado especiales d.Perfil Operacional: caracterización cuantitativa de cómo el sistema será usado. e.Modelo de Falla: Las fallas conocidas se clasifican en diferentes categorías, tales como fallas de inicialización, fallos lógicos y fallos de la interfaz, y se almacenan en un repositorio

44 Trabajo En – Extraclase Lectura de Teoría de las pruebas de Software