ApuntesPrimerParcial.pdf Jesega Verificacion y Validacion del Software 3º Grado en Ingeniería Informática Escuela Superior de Ingeniería Universidad de Cádiz Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Autor: Jesega Contenido Tema 1: Introducción ........................................................................................................................................ 3 1. Relación entre la V&V y la Calidad de Software .................................................................................. 3 2. Definiciones ........................................................................................................................................... 3 3. Proceso de verificación y validación del Software ................................................................................ 3 Objetivos.................................................................................................................................................... 3 Actividades asociadas a la V&V ............................................................................................................... 3 Técnicas de V&V de Software .................................................................................................................. 3 Técnicas estáticas ...................................................................................................................................... 3 Técnicas dinámicas .................................................................................................................................... 4 4. Estándares .............................................................................................................................................. 4 Organizaciones internacionales de estandarización................................................................................... 4 Comités y grupos de trabajo ...................................................................................................................... 5 Estándares relacionados con V&V ............................................................................................................ 5 Otros esfuerzos de Estandarización ........................................................................................................... 6 Ejercicio 1...................................................................................................................................................... 6 Ejercicio 2 – Parte 1 ...................................................................................................................................... 6 Ejercicio 2 – Parte 2 ...................................................................................................................................... 7 Tema 2: Técnicas estáticas y dinámicas de verificación y validación ............................................................... 8 1. Técnicas V&V ....................................................................................................................................... 8 Introducción ............................................................................................................................................... 8 Técnicas de V&V ...................................................................................................................................... 8 Técnicas de análisis estático ...................................................................................................................... 8 Técnicas de análisis dinámico ................................................................................................................... 8 ¿Qué técnicas debemos elegir? .................................................................................................................. 8 Definiciones ............................................................................................................................................... 8 Conceptos .................................................................................................................................................. 9 Principios de la V&V ................................................................................................................................ 9 V&V en el ciclo de desarrollo ................................................................................................................... 9 Modelo en V .............................................................................................................................................. 9 Ejemplo de técnicas complementarias ..................................................................................................... 10 Ampliación y eliminación de defectos .................................................................................................... 10 2. El proceso de depuración..................................................................................................................... 10 Definición ................................................................................................................................................ 10 Características.......................................................................................................................................... 10 Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Apuntes Primer Parcial VVS a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Proceso .................................................................................................................................................... 11 3. Revisiones Software ............................................................................................................................ 11 Definición ................................................................................................................................................ 11 ¿Qué ocurre en la fabricación industrial? ................................................................................................ 11 Ventajas ................................................................................................................................................... 11 Inconvenientes ......................................................................................................................................... 11 4. Técnicas Estáticas ................................................................................................................................ 14 Técnicas estáticas básicas (en qué me baso para realizar las revisiones software) ................................. 14 5. Automatización.................................................................................................................................... 16 ¿Qué analizan?......................................................................................................................................... 16 Herramientas............................................................................................................................................ 16 6. Técnicas dinámicas .............................................................................................................................. 16 Tipos ........................................................................................................................................................ 16 Ahórrate 500 € si vienes de Wuolah - AMRO Residencias Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Tipos ........................................................................................................................................................ 12 a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Tema 1: Introducción 1. Relación entre la V&V y la Calidad de Software El SWEBOK V 3.0 214 divide la Ingeniería del Software en 15 áreas de conocimiento, entre las cuales está la calidad del software. Dentro de una de las ramas en las que se divide dicha área, concretamente la de Software Quality Management Processes, se encuentra la sección de Verificación y Validación. Los procesos de verificación y validación se encargan de la comprobación de que el software que se está desarrollando: - Se ajusta a su especificación (Verificación) Presenta la funcionalidad esperada por las personas que van a pagar por él (Validación) Según el Capability Maturity Model Integration (CMMI) tenemos las siguientes definiciones: - La verificación asegura que el producto está construido de acuerdo con los requisitos, especificaciones y estándares. La validación asegura que el producto se podrá utilizar en el mercado. Según el estándar IEEE Std 24765-2017, la definición de V&V es: - Es el proceso en el que se determina si los requisitos de un sistema o componente están completos y correctos, los productos de cada fase de desarrollo cumplen los requisitos o condiciones impuestos en la fase previa, y si el sistema final o componente satisface los requisitos especificados. Es importante saber que el proceso de V&V es aplicable en cualquier fase del proyecto, pero que cuanto antes mejor. 3. Proceso de verificación y validación del Software Objetivos Verificación: Comprobar que el software cumple con sus requisitos funcionales y no funcionales. Validación: Asegurar que el software cumple con las expectativas del cliente. Consistiría en demostrar que el software hace lo que el cliente espera que haga. El fin último de los procesos de verificación y validación es establecer la confianza de que el sistema software es adecuado, es decir, se ajusta bien a su propósito. Esto significa que el sistema debe ser lo suficientemente bueno para el uso que se le va a dar. Actividades asociadas a la V&V La verificación y la validación incluyen un amplio rango de actividades: Revisiones técnicas, Auditorías de calidad y configuración, Monitorización del rendimiento, Simulación, Estudio de factibilidad, Revisión de la documentación, Revisión de base de datos, Análisis de algoritmos, Pruebas de desarrollo, Pruebas de usabilidad, Pruebas de calificación, Pruebas de aceptación, Pruebas de instalación, etc. Técnicas de V&V de Software El proceso de V&V implica la utilización de técnicas estáticas y dinámicas: - Técnicas estáticas: no implican la ejecución del sistema a probar. Técnicas dinámicas: ejecutan el sistema a probar. Técnicas estáticas Se basan en el examen manual o automatizado de la documentación del proyecto, información relacionada con los requisitos y el diseño, el código, etc. Pueden emplearse a lo largo de todas las etapas del desarrollo y su uso temprano es muy aconsejable. Ahórrate 500 € si vienes de Wuolah - AMRO Residencias Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. 2. Definiciones a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Ejemplos de técnicas estáticas: - Inspección del software: Examen visual de los diferentes documentos producidos para detectar errores, violaciones de los estándares de desarrollo y otros problemas. Revisión del software: Diferentes aspectos del producto se presentan al personal que interviene en el proyecto: directores, usuarios, etc., para que realicen comentarios o para dar su aprobación. Lectura de código: Análisis del código producido para detectar errores de tecleo típicos que no violen la sintaxis. (Si violaran la sintaxis ya los detectaría el compilador). Análisis y traza de algoritmos: Permite determinar la complejidad de los algoritmos empleados, se analiza el peor caso, el caso promedio, etc. Los procesos implicados en las técnicas estáticas son altamente manuales, propensos a errores y costosos en tiempo. Para vencer estos problemas se han propuesto técnicas de análisis estático basadas en métodos formales que tienen como objetivo la automatización de la verificación de las propiedades de los requisitos y del diseño. Para su aplicación es necesario utilizar lenguajes formales para la especificación de requisitos y de la arquitectura del software. Estas técnicas de verificación formal se aplican especialmente a la verificación de sistemas críticos. Uno de los enfoques más utilizados para la verificación formal es la comprobación de modelos. Una herramienta de comprobación de modelos toma como entrada un modelo, es decir, una descripción de los requisitos funcionales del sistema o del diseño y una propiedad que debe satisfacer el sistema. Técnicas dinámicas Obtienen información de interés sobre el programa observando su comportamiento durante un número limitado de ejecuciones. Ejemplos: Perfilado (profiling) y prueba (testing) ▪ Perfilado Técnica de análisis dinámico de programas que permite investigar su comportamiento utilizando información generada en tiempo de ejecución. Permite medir diversos aspectos de un programa, como el número de accesos a memoria, la frecuencia y duración de llamadas a funciones, uso de instrucciones específicas, número de veces que se llama a un método, qué instrucciones consumen más tiempo, etc. La información que proporciona el perfilado se suele utilizar para analizar y mejorar el rendimiento de un programa. Son perfiladores clásicos: gprof y ATOM. ▪ Prueba Se trata de una técnica dinámica clásica, la cual constituye un campo muy amplio dentro de la Ingeniería del Software. De hecho, el SWEBOK la considera como una de las 15 áreas de conocimiento que define. Según el SWEBOK, la prueba de software es una actividad que se realiza para evaluar la calidad de un producto, y para mejorarla, mediante la identificación de defectos y problemas. 4. Estándares Un estándar es un documento establecido por una autoridad, costumbre o consentimiento general como un modelo o ejemplo. Los estándares proporcionan un cuerpo de conocimiento que sientan las bases para una disciplina profesional, en cuanto a comunicación (por la terminología común que proponen), cualificaciones profesionales, esquemas de certificación, referencias de buenas prácticas, interoperabilidad, consistencia, etc. Organizaciones internacionales de estandarización - ISO (International Organization for Standardization) IEEE (Institute of Electrical and Electronics Engineers) IEC (International Electrotechnical Commission) AENOR (Asociación Española de Normalización y Certificación) Ahórrate 500 € si vienes de Wuolah - AMRO Residencias Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. - a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Para la elaboración de estándares se crean: comités técnicos, subcomités y grupos de trabajo. JTC1: Comité Técnico de Tecnología de la Información SC7: Subcomité de Ingeniería de Software y Sistemas WG26: Grupo de trabajo para Pruebas de software Estándares relacionados con V&V ▪ ISO/IEC/IEEE Std 24765-2017 (Vocabulario) Systems and software engineering – Vocabulary Define términos relacionados con la Ingeniería del software y reemplaza al ISO/IEC/IEEE Std 24765-2010. ▪ ISO/IEC/IEEE Std 12207-2017 (Procesos del ciclo de vida del software) Systems and software enginering– Software life cycle processes Establece un marco de trabajo común para los procesos del ciclo de vida del software, con terminología bien definida y que puede ser referenciado por la industria del software. Contiene procesos, actividades y tareas que se van a aplicar durante la adquisición de un producto o servicio software y durante el suministro, desarrollo, operación y mantenimiento de productos software. ▪ ISO/IEC/IEEE Std 29119 (Pruebas) Software and systems engineering – Software testing Es una serie de 5 estándares internacionales para la prueba de software. Tiene como objetivo cubrir todo el ciclo de vida de las pruebas de sistemas software incluyendo los aspectos relativos a la organización, gestión, diseño y ejecución de las pruebas, para reemplazar varios estándares IEEE y BSI (British Standards Institution) sobre pruebas de software. Su estructura es: - ISO/IEC/IEEE 29119-1:2013 Software and systems engineering - Software testing - Part 1: Concepts and definitions ISO/IEC/IEEE 29119-2:2013 Software and systems engineering - Software testing - Part 2: Test processes ISO/IEC/IEEE 29119-3:2013 Software and systems engineering - Software testing - Part 3: Test documentation ISO/IEC/IEEE 29119-4:2015 Software and systems engineering - Software testing - Part 4: Test techniques ISO/IEC/IEEE 29119-5:2016 Software and systems engineering - Software testing - Part 5: Keyword-Driven Testing ▪ IEEE Std 1012 (Marco para la verificación y validación) IEEE Standard for System, Software, and Hardware Verification and Validation Define los procesos de V&V en términos de actividades específicas y tareas relacionadas. También define los contenidos del plan de V&V (VVP), incluyendo formatos de ejemplo. Los propósitos de este estándar son: - Establecer un marco de trabajo común para los procesos, actividades y tareas de V&V. Definir las tareas de V&V, las entradas y las salidas requeridas en cada proceso del ciclo de vida. Identificar las tareas de V&V mínimas correspondientes a un esquema de 4 niveles de integridad. Definir el contenido del Plan de V&V. Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Comités y grupos de trabajo a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Otros esfuerzos de Estandarización - MoProSoft (Modelo de Procesos para la Industria del Software) Méjico Brazilian Process Improvement Model Métrica v3 España Competisoft Ejercicio 1 ¿Cuál es el propósito que se persigue con las siguientes técnicas: Management Reviews, Technical Reviews, Inspections, Walkthroughs, Process Assurance y Product Assurance Audits ? Management Reviews El objetivo de la “Managements reviews” es monitorizar el progreso, determinar el estado de la planificación y evaluar la efectividad de las técnicas, los procesos y las herramientas de gestión. Los principales parámetros con los que trabaja son el coste, los tiempos, el alcance del proyecto y la calidad del producto. Se evalúan decisiones sobre tomar acciones correctivas, cambios en los recursos, en el alcance del proyecto, etc. Technical Reviews El objetivo de una revisión técnica es evaluar un producto software por un cierto personal cualificado para determinar su adecuación al uso que se le quiere dar e identificar discrepancias en las especificaciones y los estándares utilizados. Estas revisiones proveen a la gestión con evidencias para confirmar el estado técnico del Proyecto. Inspections El objetivo de la inspección es detectar e identificar anomalías en el producto software. Las inspecciones se basan en una serie de reglas que respetan los criterios especificados por la organización. - En las inspecciones no se comprueba todo el producto exhaustivamente, sino determinadas “muestras” del producto que se está comprobando. Los gestores del proyecto no deben participar en las inspecciones. Debe haber un líder encargado de liderar las inspecciones Las inspecciones implican reuniones en las que se reporten las anomalías detectadas. Walkthroughs El objetivo de esta técnica es evaluar un producto software. Un walktrough puede ser utilizado para educar a un determinado público para el uso de un producto software. En los walkthrougs, es el autor del producto quien presenta el producto. Process and Product Assurance Audits El objetivo de estas auditorías es ofrecer una evaluación independiente de la conformidad de los productos y procesos a las regulaciones, estándares y planes aplicables. Ejercicio 2 – Parte 1 El estándar IEEE Std 1012-2016 hace uso de los niveles de integridad. Consulte este estándar, que está disponible en el campus virtual de la asignatura, para dar respuesta a las siguientes preguntas: 1- Definición de nivel de integridad que proporciona el estándar. Nivel de integridad: establece la importancia del sistema para el usuario y cliente, basándose en la complejidad, riesgo, nivel de seguridad, actuación deseada, fiabilidad u otras características del sistema. ¿Ya conoces 'Forever Green'? ¡Haz click aquí! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Lea el capítulo 10 del SWEBOK V 3.0 Software Quality, y conteste: a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 2- ¿Para qué se utilizan los niveles de integridad en el estándar? Estos niveles de integridad se utilizan para determinar las pruebas y actividades de Verificación y Validación necesarias, así como la intensidad y el rigor de estas. 3- ¿Cuántos niveles de integridad considera? El estándar IEE Std 1012 2016 se ha desarrollado con 4 niveles de integridad. Cuanto mayor es el nivel de integridad del sistema, más intensas serán las comprobaciones que deberá pasar. Lea el artículo Software Process Improvement: The Competisoft Project disponible en el campus virtual y responda a las siguientes preguntas: 1- ¿Qué problemas plantean los estándares internacionales relacionados con la Ingeniería del Software para las pequeñas empresas? El principal problema que plantean los estándares internacionales es que no han sido concebidos pensando en pequeñas empresas, de menos de 25 empleados, y por ello, son difíciles de aplicar para este tipo de organizaciones. 2- ¿Qué es MoProSoft? MoProSoft (Modelo de Procesos para la Industria de Software) es el modelo que se utilizó en México para ayudar a las pequeñas empresas de la industria del software a que pudieran estandarizar sus prácticas. 3- ¿Qué relación existe entre Competisoft y MoProSoft? Competisoft es un modelo desarrollado por varias organizaciones y en el que participaron investigadores de diversas universidades, el cual constituye la evolución de MoProSoft. ¿Ya conoces 'Forever Green'? ¡Haz click aquí! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Ejercicio 2 – Parte 2 a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Tema 2: Técnicas estáticas y dinámicas de verificación y validación 1. Técnicas V&V Introducción Objetivo: entregar un software libre de errores y ajustado a las necesidades del cliente. - Se ajusta a su especificación Comprobar que el software cumple con sus requisitos funcionales y no funcionales Validación: ¿Estamos construyendo el producto correcto? - Presenta la funcionalidad esperada por el cliente Asegurar que el software cumple con las expectativas del cliente. Técnicas de V&V Análisis estático: Analizan la forma y estructura de un producto sin ejecutarlo. Análisis dinámico: Implican ejecución, o la simulación, de un producto de la actividad de desarrollo para detectar errores mediante el análisis de la respuesta de un producto a conjuntos de datos de entrada. Técnicas de análisis estático - Analizan directamente la forma y estructura de un producto sin ejecutarlo. Se basan en el examen manual o automatizado de la documentación, requisitos, diseño, código, etc. Analizan la documentación, especialmente en los casos de prueba, para verificar su trazabilidad con los requisitos, su adecuación para cumplir los requisitos, y su precisión. Pueden emplearse a lo largo de todas las etapas del desarrollo y su uso temprano es muy aconsejable. Comprueban la correspondencia entre un programa y su especificación (verificación). Tipos: Inspección del software, recorridos, auditorías, . . . Técnicas de análisis dinámico - Implican ejecución o la simulación de un producto de la actividad de desarrollo para detectar errores mediante el análisis de la respuesta de un producto a un conjunto de datos de entrada. Obtienen información de interés sobre el programa, observando su comportamiento durante un número limitado de ejecuciones. Se necesita conocer la salida para cada una de las entradas. Demuestra que el software es operacionalmente útil, su rendimiento y fiabilidad. Tipos: prueba del software, simulación, etc. ¿Qué técnicas debemos elegir? Lo que se busca es reducir errores, fallos, etc., en el sistema software. Cuanto antes detectemos los fallos, menos problemas tendremos para corregirlos, pero también es complicado reconocer los fallos en las fases tempranas. Es decir, cuánto más tiempo pase en el desarrollo del producto software, más fácil será reconocer el fallo pero también más costoso será corregirlo. Las pruebas de software pueden probar la presencia de errores pero no la ausencia de ellos. Estáticas Definiciones Error humano (mistake): Acción humana que produce un defecto. Defecto (fault): Una instrucción incorrecta o faltante. La ejecución del defecto puede producir un fallo. ¿Ya conoces 'Forever Green'? ¡Haz click aquí! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Verificación: ¿Estamos construyendo el producto correctamente? a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Error (error): Incapacidad de un sistema para realizar la función requerida dentro de los requisitos especificados, resultando una salida incorrecta o una terminación anormal o limitaciones de tiempo o espacio incumplidas. En resumidas cuentas, un error humano del programador se plasmará en un defecto en el software, lo cual dará lugar a un fallo en el sistema, que provoca el error, es decir, que el sistema no cumpla con su función. Conceptos Las actividades de V&V estáticas tratan de descubrir errores humanos y/o defectos, mientras que las dinámicas tratan de descubrir los fallos y/o errores, y por lo tanto, corregir los errores del código. Principios de la V&V 1- El objetivo principal es la PREVENCIÓN DE DEFECTOS y no la detección de los mismos 2- Encontrar los defectos ANTES POSIBLE y MINIMIZAR SUS IMPACTOS. 3- TODOS los defectos son importantes V&V en el ciclo de desarrollo - La V&V es un proceso más del ciclo del desarrollo software Se inicia con las revisiones de los requerimientos, continúa con las revisiones del diseño y las inspecciones del código y finaliza con la prueba del producto. Existen actividades de V&V en cada etapa del proceso de desarrollo del software. La V&V es un proceso caro, puesto que idealmente implica un equipo independiente al de desarrollo, por lo que requiere una planificación cuidadosa. La V&V debe iniciarse en etapas tempranas del proceso de desarrollo para no propagar los errores. Los planes de prueba deben derivarse a partir de la especificación y diseño del sistema. Modelo en V El propósito del proceso de V&V es ayudar a construir la calidad dentro del software a lo largo de todo el ciclo de vida. Aquí vemos la interrelación entre la verificación y la validación del sistema. Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Dinámicaas Fallo (failure): Estado inestable intermedio del sistema a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Las inspecciones de software analizan y comprueban las representaciones del sistema. Se trata de una técnica estática, que se puede emplear en todas las etapas del proceso de desarrollo, desde requisitos hasta el código fuente final. Las pruebas del software implican ejecutar una implementación del software con datos de prueba. Se trata de una técnica dinámica que solo se puede utilizar cuando disponemos de un prototipo o una versión ejecutable. Ampliación y eliminación de defectos Modelo de ampliación de defectos - Un recuadro representa un paso de desarrollo de software. Durante una fase de desarrollo, los errores se pueden generar de manera inadvertida. La revisión puede fallar en descubrir errores generados de manera reciente y errores de pasos anteriores, lo que resulta en que cierto número de errores se pasen por alto. En algunos casos, los errores que se pasan por alto de pasos anteriores, se amplifican con el trabajo actual. Podemos sacar como conclusión que si vamos aplicando la inspección de software en cada paso del desarrollo, el producto resultante acabará con menos defectos y la corrección de los que se hayan eliminado habrá sido menos costosa que si no hubiéramos aplicado inspección. 2. El proceso de depuración Definición Proceso que localiza y corrige los errores descubiertos durante la verificación y validación. Características - Es un proceso complicado pues no siempre los errores se detectan cerca del punto en que se generaron. ¿Ya conoces 'Forever Green'? ¡Haz click aquí! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Ejemplo de técnicas complementarias a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 - Se utilizan herramientas de depuración que facilitan el proceso. Después de reparar el error, hay que volver a probar el sistema (Pruebas de regresión), puesto que la solución del primer fallo puede dar lugar a nuevos fallos. 3. Revisiones Software Definición - Son parte del proceso de verificación del software Son un proceso de V&V estático en el que un sistema software se revisa para encontrar errores, omisiones y anomalías. Generalmente se centran en el código fuente, pero pueden aplicarse a cualquier producto del proceso de desarrollo. Las inspecciones son usadas para asegurar la calidad durante el proceso de desarrollo, no sólo en la fase de implementación, indicando cuándo un producto está listo para pasar a la siguiente fase de desarrollo. ¿Qué ocurre en la fabricación industrial? - - En los procesos de fabricación tradicional, las inspecciones por especialistas en aseguramiento de la calidad es una práctica aceptada y común. Estas inspecciones toman lugar en puntos específicos de la línea de ensamblaje y son usadas para asegurar que las partes y los ensamblajes están correctamente construidos acorde a las especificaciones. La forma más común de inspección sigue siendo una persona haciendo un juicio basado en su experiencia. Ventajas - Durante las pruebas, los errores pueden ocultar otros errores, pero al ser un proceso estático, no hay que preocuparse de las interacciones entre errores. Pueden inspeccionarse versiones incompletas de un sistema sin coste adicional. Pueden considerarse atributos de calidad como estándares, portabilidad, mantenibilidad, ineficiencias, algoritmos no adecuados, etc. Inconvenientes - Dificultad de introducirlo en las organizaciones de desarrollo de software. Dificultad para diferenciar el producto de la persona que lo crea, especialmente cuando un producto particular tiene muchos errores. Necesidad de establecer tiempos límites para su preparación (puede reducir lo que se inspecciona) y seguimiento (pueden mantenerse defectos que luego no sean descubiertos). No detectan fallos a nivel del sistema, sino defectos. Los fallos se detectan con pruebas. No son útiles para la detección de niveles de fiabilidad y evaluación de fallos no funcionales. ¿Ya conoces 'Forever Green'? ¡Haz click aquí! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Proceso a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 ▪ Auto-inspección - Es una revisión intensa de un producto del trabajo para asegurar que está correcto, completo, consistente y claro. - Es preferible que se realice por alguien que no esté involucrado en el desarrollo del producto. - Involucra distintas técnicas como revisión de sintaxis, examen de referencias cruzadas, incumplimiento de estándares, comparación con la especificación, lectura del código, análisis de diagramas de flujo de control, etc. ▪ Inspecciones Técnicas formales - Fue desarrollado por IBM en los años 70, y actualmente es una técnica muy utilizada en sistemas críticos. - Se realiza por un equipo que examina un producto determinado, siguiendo roles y un proceso bien definido. - El equipo normalmente se constituye de cuatro o cinco miembros, que pueden cambiar de roles entre las inspecciones. - Se han desarrollado variaciones del sistema original, todas basadas en un grupo con miembros con diferentes conocimientos. Equipo - Moderador: Se encarga de la planificación, informar del resultado de la inspección y hacer el seguimiento. Debe ser un programador competente, pero no necesita ser un técnico experto en el programa siendo inspeccionado. - Secretario: Registra los resultados de la reunión de inspección. - Lector: Presenta el código o documento en la reunión - Productor: Es el responsable de producir el programa o documento del mismo. Se encarga de reparar los defectos descubiertos durante la inspección. - Inspector: (es el único que puede sobrar) Encuentra errores, omisiones e inconsistencias, en los programas y documentos Procedimiento 1- Planificación: se crea el calendario de planificaciones de los distintos componentes del producto software a inspeccionar. 2- Visión de conjunto: se especifica el área que se inspeccionará con la documentación asociada (si es la segunda vez que se inspeccionan se incluyen las modificaciones realizadas) 3- Preparación individual: Cada miembro del equipo trata de entender el diseño, su intención y lógica, buscando áreas con mayor probabilidad de cometer errores, así como las listas de comprobación de errores necesarias. 4- Inspección: - La realiza todo el equipo - Cada sesión debe durar máximo 2 horas y/o analizar un máximo de 125 líneas de código. - Un lector, elegido por el moderador, describe cómo implementará el diseño. - Cada pieza de lógica es cubierta al menos una vez, y cada rama es tomada al menos una vez. - Una vez que se entendió el diseño, el objetivo es encontrar errores. - Hasta que un error se descubre, se realizan preguntas basadas en las listas de comprobación. - El moderador captura los errores, clasifica su tipo, e identifica su severidad (menor, mayor, etc.), y se continúa con la inspección. 5- Repetición del trabajo: Todos los errores o problemas detectados en la inspección son resueltos por el productor 6- Seguimiento: El moderador se asegura de que todo lo descubierto ha sido resuelto por el productor. Si se ha corregido más de un 5% de las líneas de código, se debe realizar una nueva revisión completa. En otro caso, el moderador indica ¿Ya conoces 'Forever Green'? ¡Haz click aquí! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Tipos a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 o - Listas de fallos de datos ¿Las variables se inicializan antes que de que se utilicen los valores? ¿Todas las constantes tienen nombre? ¿El límite superior de los vectores es igual al tamaño de los mismos? ¿Las cadenas de caracteres tienen delimitadores explícitos? ¿Existe posibilidad que el buffer se desborde? o - Listas de fallos de control Para cada instrucción condicional ¿Es correcta la condición? ¿Todos los ciclos terminan? ¿Los bloques están delimitados correctamente? En las instrucciones case ¿Se han tomado en cuenta todos los casos? Si se requiere un break ¿Se ha incluido? ¿Existe código no alcanzable? o - Listas de fallos de entrada/salida ¿Se utilizan todas las variables de entrada? Antes de que salgan ¿Se le han asignado valores a las variables de salida? ¿Provocan corrupción de los datos las entradas no esperadas? o - Lista de fallos de interfaz ¿Las llamadas a funciones y métodos tienen el número correcto de parámetros? ¿Concuerdan los tipos de los parámetros formales y reales? ¿Están los parámetros en el orden adecuado? ¿Se utilizan los resultados de las funciones? ¿Existen funciones o procedimientos no invocados? o - Listas de fallos de gestión de almacenamiento Si una estructura con punteros se modifica, ¿Se reasignan correctamente todos los punteros? Si se utiliza almacenamiento dinámico, ¿se asigna correctamente el espacio? ¿Se desasigna explícitamente la memoria después de que se libere? o - Listas de fallo de gestión de excepciones ¿Se tienen en cuenta todas las condiciones de errores posibles? ▪ Recorridos Características Se realiza informalmente por un equipo cuyo objetivo es el de detectar y documentar fallos. Un equipo típico para los recorridos es: - Coordinador Presentador Secretario Encargado de mantenimiento Encargado de estándares (verifica que se cumplan los estándares) Agente de acreditación (representa al usuario) Revisores adicionales Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Listas de comprobaciones - El proceso de inspección siempre se realiza utilizando una lista de los errores comunes de los programadores. - La lista de errores de ir en función del lenguaje de programación que se utilice (en Java no se suelen cometer los mismos errores que en C). - Cuanto menos tipado sea el lenguaje, más larga será la lista. (Una lista de comprobaciones para Python será mucho más larga que una de c++). Se pueden recoger muchos tipos de fallos: fallos de datos, fallos de control, fallos de entrada/salida, fallos de interfaz, fallos de gestión de almacenamiento, fallo de manejo de excepciones, etc. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 ▪ Revisiones - Se enfoca en evaluar un producto en base a guías, estándares y especificaciones de desarrollo y proveer a los administradores evidencia de que el proceso se está realizando acorde con los objetivos establecidos. - La revisión es similar en el proceso a las inspecciones y recorridos, con la excepción de que incluye a la administración. - No se enfoca tanto en aspectos técnicos como las inspecciones. Se enfoca más en la parte administrativa. ▪ Auditoría Características - Las auditorías son iguales que una revisión pero la diferencia es que deben realizarse por un equipo externo - Es una técnica de verificación realizada durante el proceso de desarrollo de un nuevo producto o durante el mantenimiento. - Consiste en que asegurar que tanto un producto se ajusta a los planes, políticas, procedimientos y estándares establecidos. - Se realizan a través de reuniones, observaciones y examinando los productos y procedimientos. Objetivo No trata de descubrir errores en el código, sino en el proceso que se lleva a cabo en el desarrollo del software. ▪ Inspecciones, revisiones y recorridos Diferencias - Las inspecciones son un proceso formal de cinco pasos que emplea una lista de comprobación para descubrir errores. - Un recorrido es menos formal, tiene menos pasos, y no usa una lista de comprobación para realizar el trabajo del equipo. - Las inspecciones y recorridos se enfocan en asegurar la corrección. - Las revisiones se enfocan más en deficiencias en el diseño, o desviaciones de los modelos conceptuales o los requerimientos, que en los intrincados detalles de cada línea de la implementación. - El enfoque de las revisiones no es en fallos técnicos, sino en asegurar que el diseño y el desarrollo concuerdan con las necesidades de la aplicación. 4. Técnicas Estáticas Las técnicas estáticas se realizan en las fases de análisis de requisitos, diseño del sistema y codificación. Las técnicas dinámicas se realizan en las fases de pruebas unitarias, de integración y del sistema. Técnicas estáticas básicas (en qué me baso para realizar las revisiones software) ▪ Tipos Slicing - Técnica de descomposición de un programa empleada para rastrear todas las instrucciones del código que participan en el cálculo de una variable de salida. Lectura del código fuente - Lectura por otro programador del código para detectar posibles errores antes de la compilación. - Un objetivo es eliminar las malas prácticas de programación. - Intenta detectar uso incorrecto de variables, funciones omitidas, comprobación de parámetros, redundancia. ¿Ya conoces 'Forever Green'? ¡Haz click aquí! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Proceso El presentador indica el fragmento a recorrer, y el resto del equipo hace preguntas y comentarios sobre técnicas, estilo, e identifica errores, así como incumplimiento de estándares. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Análisis de control de flujo - Consiste en transformar el código/texto que describe los requisitos en un flujo gráfico. - Permite comprobar la jerarquía de rutinas principales y subfunciones. - Detecta el código inalcanzable o incorrecto. - Determina valores límites de pruebas, las ramas y caminos posibles, la interrelación jerárquica de unidades, etc. Análisis de la base de datos - Asegura que los métodos de la estructura de la base de datos y su acceso son compatibles con el diseño lógico. - Asegura la integridad de los datos, evitando las sobreescrituras de variables accidentalmente. - Comprueba los tipos de datos y su consistencia en todo el software. Análisis de utilización de datos - Se comprueba si las variables se leen antes de escribirlas, se escriben y no se leen nunca, o se escriben más de una vez sin ser leídas. - Determina si hay variables no usadas, las referencias son correctas, existe interdependencia entre variables, etc. Análisis del árbol de eventos - Mediante un enfoque descendente modela los efectos de un evento. - El evento inicial es la raíz, a partir del cuál se trazan dos líneas, la consecuencia positiva y la negativa de dicho evento, y así sucesivamente. - Permite determinar la seguridad del sistema, sus amenazas, etc. Análisis de interfaces - Sirve para demostrar que las interfaces de los distintos subprogramas no contienen errores. - Permite detectar que las interfaces detectan valores incorrectos de los parámetros. Análisis de requisitos - Consiste en asegurar que cada requisito se define sin ambigüedad por un conjunto completo de atributos (por ejemplo, el iniciador de una acción, la fuente de la acción, la acción, el objeto de la acción, las limitaciones). Análisis de sensibilidad - Predicción de la probabilidad de las zonas del programa donde habrá más fallos de un determinado tipo. - Evalúa cuáles son las regiones de código más propensas a ser afectadas durante el mantenimiento (requieren de modificaciones). Comprobación de la información - Consiste en examinar la información de diseño o código por un experto que no es su autor para la determinación de los errores más evidente. - Se buscan errores evidentes, pudiendo analizar los comentarios del código, cumplimiento de estándares de programación, comparación de comentarios del código con lo indicado en los requisitos, etc. - Ejemplo: mirar que el comentario del código concuerde con el código que comenta - ¿Ya conoces 'Forever Green'? ¡Haz click aquí! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Análisis de algoritmos - Examina la lógica y la exactitud del algoritmo a los requisitos especificados. - Se comprueba que son correctos, adecuados y estables. - Se determina la eficiencia de los mismos, analizando el peor caso, caso promedio, etc. con objeto de predecir el rendimiento del sistema. - Implica determinar la precisión numérica de almacenamiento y de los datos utilizados para evitar la propagación de errores motivadas por el redondeo numérico. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Verificación formal - Emplea modelos teóricos y matemáticos para demostrar la exactitud de un programa sin ejecutarlo. - Automatizan la verificación de las propiedades de requisitos y del diseño - Utilizan lenguajes formales para la especificación de requisitos y de la arquitectura del software. - Se aplican especialmente a sistemas críticos. - Uno de los enfoques más utilizados es la comprobación de modelos. Una herramienta de comprobación de modelos toma como entrada un modelo, es decir, una descripción de los requisitos funcionales del sistema o del diseño y una propiedad que debe satisfacer el sistema. - Otros enfoques son redes de Petri, las máquinas de estados finitos, así como la ejecución simbólica. 5. Automatización Los analizadores estáticos de programas son herramientas de software que rastrean el texto fuente de un programa, en busca de errores no detectados por el compilador. En algunos lenguajes de programación no son muy útiles pues el compilador ofrece una gran información acerca de posibles errores (incluso en ejecución). Cuanto menos tipado sea el lenguaje más importante es el analizador estático. Debe utilizarse siempre junto a inspecciones directas del código, pues existen errores que no pueden detectar, por ejemplo la inicialización de una variable a un valor incorrecto ¿Qué analizan? ▪ Análisis de flujo de control Identifica y señala los bucles con múltiples puntos de salida y las secciones de código no alcanzable. ▪ Análisis de utilización de datos Señala como se utilizan las variables del programa: Variables sin utilización previa, que se declaran dos veces, declaradas y nunca utilizadas, condiciones lógicas con valor invariante, etc. ▪ Análisis de interfaces Verifica la declaración de las operaciones y su invocación. Esto es inútil en lenguajes con tipado fuerte (Java, Ada) pero si en los restantes (C no comprueba los parámetros de una operación). ▪ Análisis de control de flujo Identifica todas las posibles trayectorias del programa y presenta las sentencias ejecutadas en cada trayectoria. Herramientas Ejemplos: PMD, Checkstyles, Cppcheck, Findbugs, FxCoop, Stylecop, Code Analysis, PHP Analyzer, La herramienta tiene que ser una ayuda para el desarrollo correcto del proyecto, debe aportar VALOR a la entrega al cliente (favorecer la relación con el cliente, Disminuir el coste de implementación, curva de aprendizaje sencilla, restricciones tecnológicas, etc.) 6. Técnicas dinámicas Al fin y al cabo, se basan en la ejecución. Tipos ▪ Pruebas back-to-back - Detecta fallos de las pruebas mediante la comparación de salidas del programa en diversas versiones para ver si se han producido anomalías al realizar un cambio de versión ¿Ya conoces 'Forever Green'? ¡Haz click aquí! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Toma de decisiones - Permite ver las combinaciones lógicas que dispone el sistema y sus relaciones. - Determina posibles errores lógicos en las decisiones existentes en el programa. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-3873392 Pruebas de valores límites - Cubre los errores que se producen en los límites de los parámetros. - Se debe usar el valor cero especialmente en divisiones, entradas de tablas, etc. - Se debe forzar la salida de los valores límites. ▪ Análisis de cobertura - Mide la cantidad del sistema que ha sido ejercitada por un conjunto de prueba. - Se puede establecer cobertura de sentencias, de ramas, etc. ▪ Pruebas funcionales - Ejecutan parte o la totalidad del sistema para asegurar que se cumplen los requisitos del usuario. ▪ Pruebas de interfaces - Se construyen casos de prueba para probar las interfaces. - Se prueba las posiciones de las variables, los valores extremos, los dominios de las variables, etc. ▪ Pruebas de mutaciones - Se producen variantes del programa original, denominadas mutantes. - Se compara la salida del programa original con la del mutante. - Se debe obtener que las salidas son distintas, en otro caso, el programa no ha sido suficientemente probado. ▪ Pruebas de rendimiento - Mide cómo el sistema se ejecuta de acuerdo a los tiempos de respuestas requeridos, el uso de CPU, consumo de memoria, etc. ▪ Pruebas de dimensionamiento y análisis de tiempo - Determina si el par hardware-software es el adecuado. - Se realiza mediante el desarrollo del código, determinándose los valores de tiempo de ejecución y comprobando si éstos se desvían de los requisitos de rendimiento previstos inicialmente, considerando el hardware final. ▪ Simulación - Emplea un modelo de simulación ejecutable para determinar el comportamiento del sistema. - Permite evaluar la interacción de un sistema con usuarios y otros sistemas. ▪ Pruebas de tensión - Mide la respuesta del sistema a condiciones extremas para identificar puntos vulnerables, con objeto de determinar que es capaz de soportar cargas de trabajo normales. ▪ Pruebas estructurales - Examinan la lógica de las unidades ▪ Pruebas de certificación - Aseguran que los resultados de las pruebas son el resultado real. - Permite garantizar que el software entregado es el mismo que el que se sometió a verificación y validación. Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. ▪
