UNIVERSIDAD NACIONAL DE TRUJILLO FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS ESCUELA ACADÉMICO PROFESIONAL DE INFORMÁTICA CURSO : INGENIERÍA DE SOFTWARE II TRABAJO : USABILIDAD DEL SOFTWARE PROFESOR : RICARDO MANUEL GUEVARA RUÍZ INTEGRANTES : ● ABANTO LEÓN, KLEYDDER PATRICK ● BAMBERGER PLASENCIA, BRAGGI JAISON ● CORDOVA AGUILAR, NESTOR JESUS ● SANCHEZ IBAÑEZ, HANS JEFFERSON ● TORRES ORUNA CARLOS EDUARDO TRUJILLO - PERÚ 2022 LA USABILIDAD Según estudios de Suarez Torrente determina que el “Nacimiento de la usabilidad como disciplina tiene su origen en el trabajo desarrollado por Whiteside, Bennett y Holzblatt en 1988, denominado Usability, engineering: our experience and Evolution" desde su inicio tanto autores como grandes organizaciones han realizado su aporte respecto al tema y debido a esto se han dado diferentes factores los cuales permiten evaluarla según el enfoque que se le esté dando. En "Una metodología que integra la ingeniería del software, la interacción persona ordenador y la accesibilidad en el contexto de equipos de desarrollo multidisciplinares" se da definición a la organización responsable de la estandarización por lo que se propone dos definiciones del término usabilidad: ● El estándar ISO 9241 - 11 que forma parte de la serie ISO 9241°, define la usabilidad como "la medida en la que un producto se puede usar por determinados usuarios para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso especificado". ● Autores como Beltre Ferreras define a la ISO 9241 - 11 contiene en su norma una visión de la aceptación del producto de acuerdo a lo siguiente: ○ Eficacia ○ Eficiencia ○ Satisfacción ISO/IEC 9126-1 FDIS Este estándar define la usabilidad considerando la capacidad del producto software al ser usado y atractivo para el usuario en condiciones determinadas de uso como contribución a la calidad de software asociado al diseño y la evaluación de la interfaz del usuario, es por esto que no solo depende del producto sino también del usuario quien le confiere o no dichas capacidades. Esta definición hace énfasis en los atributos internos y externos del producto, los cuales contribuyen a su usabilidad, funcionalidad y eficiencia. Además dentro del estándar se define como "la capacidad del producto de software de permitir a usuarios específicos alcanzar metas específicas con efectividad, productividad, seguridad y satisfacción en un contexto de uso determinado", similar a la definición de la ISO 9241 - 11. Suarez Torrente analiza a la usabilidad en términos de compresibilidad, aprendizaje, operabilidad, atractividad y conformidad, explicado cada una de estas a continuación: ● Comprensibilidad: La capacidad del producto de software de permitir a usuarios específicos alcanzar metas específicas con efectividad, productividad, seguridad y satisfacción en un contexto de uso determinado. ● Aprendizaje: Capacidad del producto software de permitir a los usuarios aprender a utilizarlo de manera que no se le dificulte. ● Operabilidad: Capacidad del producto software de permitir que el usuario opere con él y logre el control de este. ● Atractividad: La capacidad del producto software para ser atractivo al usuario. Se refiere a los atributos del software, tales como el uso de color, forma y el diseño gráfico. ● Conformidad: Es la capacidad del producto para adherirse a estándares o guías de estilo relacionadas con la usabilidad del software. ¿Cómo aterriza la usabilidad en la implementación del software? La usabilidad para la implementación de software según Granollers (2004), se define considerando los siguientes atributos: ● Facilidad de aprendizaje: Minimizar el tiempo requerido para comprender el software desde un conocimiento nulo acerca de este hasta su uso productivo. ● Tiempo de respuesta: Capacidad del software para mostrar los estados que requiera el usuario. Generalmente depende más de las especificaciones técnicas del computador donde se esté usando el software. ● Flexibilidad: Formas de intercambio de información que existen entre usuario y software, lo cual implica un cierto nivel de productividad. ● Robustez: Es la capacidad de ayudar al usuario a cumplir con sus objetivos, el software tiene que dar el asesoramiento necesario. ● Recuperabilidad: Grado de facilidad con el cual se corrige una acción identificada previamente como error, la cual ha sido ingresada por el usuario. ● Sintetizabilidad: Factor que mide la percepción del cambio de operación o función del sistema por parte del usuario. ● Consistencia: Capacidad de usar los mecanismos del software de la misma manera sin importar el momento en el que se necesiten. ● Disminución de la carga cognitiva: Reducción de la necesidad de recordar lo que realizan ciertas partes del software por parte del usuario, lo cual implica un buen diseño y disposición de elementos interactivos que aparecerán en la interfaz. Algunos de estos atributos son medibles en torno a unas ciertas métricas según Ferreras (2008), los cuales se muestran en la siguiente tabla: Atributo Significado Forma de medir Facilidad de aprendizaje Implica que tan rápido y efectivo se puede realizar un trabajo usando el software por primera vez. Tiempo desde que el usuario novato utiliza el sistema por primera vez hasta que se vuelve un experto en este. Disminución de la carga cognitiva Capacidad de permitir el Tiempo empleado funcionamiento del software concluir la actividad. sin que el usuario tenga que estar recordándolo. para Flexibilidad Uso productivo del software y facilidad de intercambio de información entre usuario y sistema Número de tareas por unidad de tiempo en que el usuario es capaz de hacer uso del sistema. Recuperabilidad Identificación de errores y cuán fácil el usuario se recupera de estos, considerando tanto el número de errores como el tipo de errores. Número de errores que el usuario comete a la hora de realizar una tarea concreta y cómo se da la recuperación del error. Satisfacción Atributo adicional que Cuestionarios muestra la opinión subjetiva satisfacción. que tiene el usuario acerca del software usado. de Evaluación y medición de la usabilidad del software Para cumplir con los atributos establecidos es necesario realizar actividades de evaluación de usabilidad a lo largo de todo el desarrollo del software, las cuales tienen como objetivos: ● Proporcionar retroalimentación para mejorar el diseño. ● Valorar en qué medida se cumplen los objetivos marcados frente a los usuarios y a la propia organización. ● Monitorizar el uso a largo plazo de productos o sistemas. Métodos de evaluación de la usabilidad Existen varias propuestas de métodos para la evaluación de la usabilidad, los cuales utilizan determinados medios y técnicas que intentan medir diferentes aspectos relacionados con esta. La selección de un método u otro depende de múltiples factores, dado que algunos de estos métodos requieren de recursos más especializados y costosos según sea el caso. Podemos apreciar en la figura el mapa conceptual sobre la clasificación de los métodos de evaluación de la usabilidad, donde está descrito de manera general cómo se lleva a efecto un proceso de evaluación de usabilidad. Se muestran los distintos lugares donde se puede realizar, las posibles técnicas a utilizar y si existe o no participación de usuarios en esta. Tipos de técnicas Según el tipo de técnica de comprobación utilizada, se distinguen tres categorías: MÉTODOS DE INSPECCIÓN MÉTODOS DE INDAGACIÓN ● Heurística Pretende encontrar problemas de usabilidad en el diseño de la interfaz de usuario. Se revisa su conformidad respecto a una serie de reglas. ● Recorrido cognitivo Evalúa la facilidad de aprendizaje a través de prototipos del sistema. ● Recorrido de usabilidad Reunión de usuarios, desarrolladores y expertos en usabilidad, realizan una serie de tareas como usuarios, discuten sobre las soluciones y finalmente, los expertos dan su opinión. ● Inspección de estándares Verifica que la interfaz de usuario esté de acuerdo con los patrones dados por los estándares industriales. ● Observación de campo Pretende entender cómo los usuarios de los sistemas interactivos realizan sus tareas. ● Grupo de discusión Recogida de datos, donde se reúnen para discutir aspectos del sistema. ● Entrevista Permite conocer el grado de satisfacción que tiene el usuario con el sitio web y valoraciones. ● Cuestionario Permite conocer preferencias de los usuarios. ● Pensar en voz alta Se solicita a los usuarios que expresen libremente sus opiniones sobre cualquier aspecto. ● Ordenación de tarjetas ayuda a saber cómo será estructurada la información de la interfaz. TEST Métricas del Software Métrica se define como la medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado (IEEE, 1993). Métricas Simples de Código Fuente Las métricas simples de código fuente permiten medir las características internas de los componentes de software (González, 2010). Para el cálculo de estas métricas se dio formato al código, de manera que cada instrucción correspondiera con una línea del archivo del programa. Se aplicaron las siguientes métricas simples de código fuente: Total Líneas de Código (Lines of Code, LOC) se tomaron los valores recomendados para una clase o archivo entre [5, 1000] y Líneas de Comentarios de Código (Comment Lines of Code, CLOC) tomando el porcentaje recomendado para una clase o archivo entre 20% y 40%. Métrica para medir la Complejidad Las métricas de complejidad pueden emplearse para predecir información crítica sobre la fiabilidad y mantenimiento de software. Se aplicaron las siguientes métricas para medir la complejidad: Complejidad Ciclomática (Cyclomatic Complexity CC) (McCabe 1976 1994, Rosenberg 1997). Para llevar a cabo el cálculo de esta métrica se aplicó el mismo criterio de formato para el código fuente: una instrucción por línea de archivo. Se recorre de manera secuencial el archivo de código fuente detectando las bifurcaciones y condicionales presentes en el texto del programa. Es importante resaltar que el valor obtenido es una aproximación al número ciclomático. A. Características y métricas de legibilidad del código fuente Las características hacen referencia a los aspectos del código fuente que tienen mayor influencia con la percepción de legibilidad. Los autores de los estudios seleccionados evaluaron un grupo de características, y propusieron unas métricas para ellas que permitieran medir la legibilidad del código fuente. En la Tabla 3 se presenta el listado de algunas características encontradas que obtuvieron mejores resultados en relación al juicio de legibilidad. El nivel de relación de la característica con la legibilidad está representado por A (alto), M (medio) y B (bajo). Ese nivel de relación proviene de los resultados obtenidos por los autores en sus estudios, y refleja la importancia de la característica con la legibilidad del código. El listado de características se presenta en orden de relevancia. Tabla 3. Características del código fuente relacionadas con la legibilidad. Por otra parte, las métricas de legibilidad del software se clasificaron en dos tipos: las simples, que consisten en tomar la medida por un conteo de alguna de las características presentadas; y las compuestas, que requieren de una ecuación más elaborada. Las métricas simples encontradas son: número promedio y máximo de espacios en blanco (identación), número promedio de comentarios, longitud promedio y máxima de línea, número promedio de paréntesis, número promedio de operadores aritméticos, volumen del programa, número promedio de identificadores, número de líneas de comentarios dentro de un método (LCM), número máximo de ciclos anidados, longitud de los comentarios y número promedio de palabras clave. Las métricas compuestas más relevantes se presentan en la Tabla 4. Tabla 4 Métricas de legibilidad compuestas De acuerdo con la literatura, las métricas simples que mejores resultados han reportado para medir la legibilidad del código fuente han sido: la cantidad de espacios en blanco, la cantidad de comentarios, la longitud de la línea de código y la cantidad de paréntesis. Además, las métricas de tipo compuestas que mejores resultados han obtenido son: la métrica de Posnett, abreviada como PHD, la métrica WSCR para el código fuente en lenguaje WSDL (servicios web), y la legibilidad de los comentarios (CR) propuesta por Scalabrino et al [25]. B. Métodos utilizados para medir la legibilidad del código fuente En la Tabla 5 se presentan los métodos utilizados en las investigaciones para diferentes actividades relacionadas, directa o indirectamente, con los procesos que permiten evaluar la legibilidad en el código fuente. En la primera columna se describen los usos de estos métodos identificados en los estudios, en la segunda columna se encuentran los métodos que fueron hallados en los estudios seleccionados en la RSL. Tabla 5 Métodos utilizados para medir la legibilidad del código fuente El aprendizaje de máquina supervisado ha permitido obtener métodos para evaluar automáticamente la legibilidad del código fuente, que, a pesar de no ser métodos definitivos aún, han logrado una precisión por encima del 80%. Los investigadores interesados en continuar con los trabajos podrían usar las mismas técnicas utilizadas en la literatura, tales como random forest, redes neuronales o el aprendizaje profundo, aplicándolas de forma individual o combinadas. Se recomienda la exploración de modelos basados en redes neuronales profundas, teniendo en cuenta que el aprendizaje profundo permite el entrenamiento y clasificación sin que sea necesario seleccionar las características del código fuente de antemano. Los resultados recientes más prometedores apuntan en esta dirección. Por otro lado, si lo que se desea es continuar con la búsqueda de las características del código fuente que permiten medir su legibilidad, se pueden utilizar las técnicas de aprendizaje de máquina no supervisado, como el clustering (agrupación), o alguna de las técnicas de regresión para el análisis de la correlación entre la característica y la predicción de legibilidad. VERIFICACIÓN Se define las verificaciones como las actividades que se realizan para comprobar si las salidas en las diferentes etapas de desarrollo cumplen con los requisitos o condiciones establecidos por las etapas previas (Rodriguez Hernandez, 2011). Las verificaciones en la metodología son aquellas que determinan que el producto en cada etapa del proyecto es adecuado, completo y que es acorde a los requerimientos establecidos para el software es decir que con la verificación se logra asegurar que el producto cumple con los requisitos para las etapas del ciclo de vida del software en la que se persigue dos criterios fundamentales: ● El software debe realizar de forma correcta todas las funciones para las que ha sido concebido. ● El software no debe hacer ninguna función en sí misma o en combinación con otras, que pueda degradar el rendimiento de todo el sistema. Pruebas de verificación Los siguientes puntos a tomar están dados por Salazar Bermúdez, 2012: ❖ Participantes Equipo de revisión: Equipo de trabajo conformado por los estudiantes del curso, encargado de aplicar las revisiones a otro equipo para validar el cumplimiento del proceso de calidad definido para el curso. Representante del equipo revisado: Miembro que representa al equipo revisado encargado de evacuar las consultas de los revisores, no debe justificar o defender los defectos encontrados. ❖ Documentos utilizados ➢ Enunciado de objetivos de la revisión. ➢ Especificación del elemento del software que se evaluará. ➢ Elemento del software a revisar. ➢ Planes, estándares o guías que servirán para revisar el elemento del software. ➢ Listas de verificación o cotejo ❖ Procedimiento Las reuniones para realizar este tipo de revisión se llevan a cabo cuando así lo establezca el calendario del curso o cuando se determine adecuada la revisión del elemento del software por su disponibilidad. VALIDACIÓN La validación en la metodología propuesta se refiere a la comprobación que se da al final del ciclo de vida del desarrollo, de que el producto creado satisface correctamente las condiciones del producto y las expectativas que los clientes han depositado sobre este proyecto. Esta actividad se debe realizar en áreas del ambiente de operación, lo que llevaría a constituir las pruebas de aceptación, Pruebas piloto, por un especialista el cual registra los resultados y la participación del cliente (Rodriguez Hernandez, 2011). Pruebas de validación Los siguientes puntos a tomar están dados por Salazar Bermúdez, 2012: ❖ Participantes Líder de pruebas: responsable del proceso y especialmente de su planificación, pero también participa del diseño y ejecución de las pruebas pero en menor medida. Encargados de pruebas: son el resto de los miembros del equipo. ❖ Documentos utilizados ➢ Plan de pruebas ➢ Diseño de pruebas ➢ Casos de prueba ➢ Reporte de no conformidades ➢ Reporte de métricas ❖ Herramienta de pruebas Selenium: Es una suite de herramientas de código abierto que se distribuye bajo la licencia Apache License 2.0, la suite está compuesta por tres herramientas de funcionamiento independiente. NUnit: Es una herramienta de código abierto para la ejecución de pruebas de unidad, específicamente en aplicaciones desarrolladas en alguno de los lenguajes de programación del framework de Microsoft .NET ❖ Procedimiento ➢ Planificación ➢ Diseño de pruebas ➢ Desarrollo del ambiente de pruebas ➢ Ejecución de las pruebas ➢ Elaboración de reportes de las pruebas ➢ Evaluación de las pruebas PLANEACIÓN DE VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE ● La planificación de la verificación y validación del sistema empieza desde etapas tempranas. ● Los planes derivan de la especificación y diseño del sistema. ● La planeación de V&V: ❖ Asegura que los recursos V&V sean identificados y asignados de forma eficiente. ❖ Establece las metas y objetivos de la V&V. ❖ Debe ser observada a lo largo del proceso de desarrollo, para mantener acciones realistas que puedan ser establecidas y llevadas a cabo. ● Es parte del proceso V&V ❖ Definición de estándares y procedimientos para las inspecciones y pruebas del sistema. ❖ Listas de comprobación para conducir las inspecciones. ❖ Definición del plan de pruebas del software. ❖ Definición de recursos de hardware y software. ❖ Planes de contingencia (para solucionar desajustes en implementación y diseño). ● Regla general: Entre más crítico el sistema, dedicar mayor esfuerzo a la verificación estática. ● Los planes de verificación y validación: ❖ Ayudan a los gestores a asignar recursos. ❖ Estimar calendario de pruebas. ❖ Ayudan al personal técnico a obtener una panorámica general de las pruebas del sistema y ubicar su trabajo en este contexto. ● Principales componentes de un plan de verificación y validación para un sistema grande y complejo, según Somerville: ❖ El proceso de prueba: Una descripción de las principales fases del proceso de pruebas. ❖ Trazabilidad de requerimientos: Los usuarios son los más interesados en que el sistema satisfaga sus requerimientos y las pruebas deberían planificarse para que todos los requerimientos se prueban individualmente. ❖ Elementos probados: Deberían especificarse los elementos del software que tienen que ser probados. ❖ Calendario de pruebas: Un calendario de todas las pruebas y la asignación de recursos para este calendario se enlaza, con la agenda general del desarrollo del proyecto. ❖ Procedimientos de registro de pruebas: No es suficiente con ejecutar simplemente las pruebas; los resultados de las pruebas deben ser registrados sistemáticamente. Debe ser posible auditar el proceso de pruebas para comprobar que se ha llevado a cabo correctamente. ❖ Requerimientos de hardware y software: Esta sección debe determinar las herramientas software requeridas y la utilización estimada del hardware. ❖ Restricciones: En esta sección deberían anticiparse las restricciones que afectan el proceso de pruebas como la escasez de personal. ● Para sistemas pequeños puede utilizarse un plan de verificación y validación menos formal. Aun así, se requiere un documento formal que soporte el proceso de planificación. ● Datos extras: ❖ Para algunos procesos ágiles como la programación extrema, las pruebas son inseparables del desarrollo. ❖ Al igual que otras actividades de planificación, la planificación de las pruebas también es incremental. ❖ Los planes de pruebas no son estáticos. ❖ Los planes de pruebas cambian debido a retrasos en otras etapas del proceso de desarrollo. ACTIVIDADES GENERALES DE VERIFICACIÓN EN EL CICLO DE VIDA ● Inspección del software: La inspección del software según Drake (2009) consiste en aplicar revisiones sistemáticas a las partes del ciclo de vida de un software que se basen tanto en la documentación generada (por ejemplo en análisis, diseño en modelo cascada) como en los códigos fuentes con el único propósito de detectar fallos que no cumplan con las especificaciones requeridas para el software. ❖ La principal ventaja de esta actividad es que no se requiere de una ejecución para una correcta verificación, por lo que se puede llevar a cabo incluso antes de que el sistema esté totalmente implementado. ❖ De realizarse correctamente, permite detectar entre un 60 y 90% de los fallos que pudiesen haber a costes más bajos en comparación con las pruebas dinámicas del sistema. ❖ Permite encontrar múltiples defectos en una sola inspección, mientras que en las pruebas por lo general se identifica un solo error por ejecución. ❖ Permite utilizar el conocimiento y el dominio del lenguaje de programación a utilizar, el cual da pase a una solución a fallas principales que se suelen cometer en la implementación del software (construcción del código fuente). Si bien es cierto que en etapas tempranas del ciclo de vida del software como la especificación de requerimientos (análisis) o diseño de la arquitectura del software se realiza una exhaustiva revisión de la documentación para la localización y depuración efectiva de errores, en la codificación se deben tener en cuenta algunos aspectos utilizados por los programadores en los cuales se pueden generar errores, los cuales variarán según discusiones con personal con experiencia y el lenguaje de programación que se estén utilizando: ❖ Fallos de datos: Variables no inicializadas antes de la asignación, mala definición de límites superiores de los arrays, cadenas de caracteres no cuentan con delimitadores explícitos, posibilidad de que el buffer se desborde, etc. ❖ Fallos de control: Condición incorrecta para una cierta estructura condicional, existen bucles infinitos, no tomar en cuenta todos los casos en estructuras case, existe código no alcanzable (que nunca será ejecutado). ❖ Fallos de entrada/salida: No se utilizan todas las variables de entrada, no se asigna un valor a una cierta variable de salida, hay corrupción de datos con entradas inesperadas. ❖ Fallos en interfaz: Las llamadas a las funciones no tienen el número correcto de parámetros, los resultados de las funciones no son utilizados, existen funciones sin llamar en la interfaz. ❖ Fallos en gestión de excepciones: No se toman en cuenta todas las condiciones que pueden dar lugar a errores. ● Pruebas del software Las pruebas que se realizan al software según Drake (2009) consisten en contrastar las respuestas que genera un software ya ejecutado con series de datos de prueba. Dichas respuestas serán examinadas junto con el procedimiento que se da para llegar a los resultados para comprobar que el desempeño del software sea conforme a lo requerido. Se le considera una actividad de verificación dinámica, ya que requiere de un prototipo ejecutable del sistema a desarrollar. Drake considera que los sistemas a probar no se consideran como unidades monolíticas, sino que están construidos a partir de subsistemas que a su vez se componen de módulos, funciones o clases. Por tanto, las pruebas se dan de manera incremental, obteniéndose una división en cuatro etapas: ❖ Pruebas de unidades, donde se prueba cada método y/o clase utilizados de manera independiente. ❖ Prueba de integración o subsistema, donde se prueban agrupaciones de funciones o clases que estén relacionadas con otras. ❖ Prueba de sistema, donde se prueba el sistema como un todo. ❖ Prueba de validación o aceptación, donde la prueba del sistema se realiza en un entorno real con intervención del usuario final. Asimismo, se pueden clasificar las pruebas en dos tipos diferentes: ❖ Pruebas de defectos: Pretende buscar las inconsistencias existentes entre el programa y su especificación de requerimientos. Por lo general, estas se deben a fallos o defectos en el código fuente del programa y son diseñadas para exponer la presencia de errores en el sistema mas que para evaluar su capacidad operacional. ❖ Pruebas estadísticas: Usadas para mostrar el desempeño y fiabilidad del programa y mostrar cómo es que trabaja dadas ciertas condiciones operacionales. Son diseñadas para reflejar la carga de trabajo habitual que puede soportar en un contexto real y después que se lleven a cabo las pruebas se podrá hacer una estimación de cuán fiable es el sistema (por ejemplo cuántas veces se registra una caída del sistema) y una medición de su capacidad, es decir una medición del tiempo de ejecución y el tiempo de respuesta a la hora de procesar datos estadísticos a usarse en la prueba. PRINCIPALES TÉCNICAS DE VERIFICACIÓN La usabilidad de una aplicación puede entenderse como una forma de medir cuánto de fácil es entender una aplicación para un usuario inexperto, entendiendo que un usuario inexperto es aquel que usa la aplicación por primera vez. El servicio de Verificación y Validación de la Usabilidad se ocupará de certificar estos aspectos del aplicativo: ● Garantizar la usabilidad de la aplicación en base a ciertos criterios que verifican si se permite al usuario el uso sencillo e intuitivo de la aplicación desarrollada. ● Asegurar la correcta aplicación de las normas acerca de los formatos y uso de objetos gráficos (estructura ventanas, mensajes de error, iconografía, botones, colores…) que deben ser incorporados en el diseño de ventanas, acordados al inicio del proyecto. Según (Universidad de la república de Uruguay, 2008) existen tres tipos de técnicas para la verificación de la usabilidad del software: A. Técnicas Estáticas (Análisis) Estas técnicas analizan el producto para deducir su correcta operación. A continuación, se muestran las más importantes: ● Análisis de código fuente Se revisa el código en búsqueda de problemas en algoritmos y otras faltas, siguiendo algunos procesos como revisión de escritorio o recorridas e inspecciones, estas critican al producto, no a la persona, eliminando la idea de usarlos para evaluar a los programadores. Las ventajas son que permiten: 1. Unificar el estilo de programación 2. Igualar hacia arriba la forma de programar Recorridas: Se simula la ejecución de código para descubrir faltas, con un número reducido de personas. Los participantes reciben antes el código, con reuniones no mayores a dos horas. Los roles clave son: Autor: Presenta y explica el código Moderador: Organiza la discusión Secretario: Escribe el reporte de la reunión, este será entregado al autor Inspecciones: Se examina el código, buscando faltas comunes. Estas faltas están listadas y va a depender mucho del lenguaje de programación, por ejemplo, uso de variables no inicializadas o asignaciones de tipos no compatibles. Los roles clave son: Autor Moderador Secretario Lector Inspector Se aclara que todos son inspectores, por lo que es común que existan personas con más de un cargo. ● Análisis automatizado de código fuente Herramientas de software que recorren código fuente y detectan posibles anomalías y faltas, esta no requiere de la ejecución del código para analizarlo. Es un análisis sintáctico con instrucciones bien formadas e inferencias sobre el flujo de control. ● Análisis formal Este análisis busca demostrar que el programa es correcto a partir de una especificación formal. Se necesita desarrollar herramientas que tomen especificación formal y código del componente a verificar. También se necesita responder al usuario si el componente es correcto, de lo contrario se debe mostrar un contraejemplo donde se observe que la entrada no se transforma de manera adecuada en la salida. Este análisis trae problemas como: Demostración larga y compleja La demostración puede ser incorrecta Involucra demasiado el uso de la matemática No se consideran limitaciones de hardware B. Técnicas Dinámicas (Pruebas) Estas técnicas experimentan con el comportamiento de un producto para ver si este actúa como es esperado. A continuación, se explican dichas técnicas: ● Definiciones ● Caja blanca Lo que se hará es que, a partir del código, identificar los casos de prueba interesantes. Casos de prueba: Se necesita disponer del código Tiene en cuenta las características de la implementación Puede omitir algún requerimiento no implementado ● Caja negra El proceso es entrar a una caja negra de la que no se conoce el contenido y ver qué salida genera. Casos de prueba: No se precisa disponer del código Se parte de requerimientos y/o especificaciones Porciones enteras de código pueden quedan sin ejecutar C. Ejecución Simbólica (Híbrida) Los puntos observados a rescatar son los siguientes: El resultado es más genérico que las pruebas Es un proceso experimental Tiene problemas de escala No tiene en cuenta las interfaces gráficas Referencias bibliográficas: Granollers A. (2004). MPIu+a. Una metodología que integra la ingeniería del software, la interacción persona-ordenador y la accesibilidad en el contexto de equipos de desarrollo multidisciplinares [Tesis Doctoral]. Lleida: Universitat de Lleida. Ferreras, B. (2008). Aplicación de la usabilidad al proceso de desarrollo de páginas Web [Tesis de Máster]. Madrid: Universidad Politécnica de Madrid. Torrente, S. (2011). SIRIUS: Sistema de evaluación de la usabilidad Web orientado al usuario y basado en la determinación de tareas críticas [Tesis Doctoral]. Oviedo: Universidad de Oviedo; 2011. Perurena, L.; Moráguez, M. (2013). Usabilidad de los sitios Web, los métodos y las técnicas para la evaluación. Revista Cubana de Información en Ciencias de la Salud, 24(2), 176-194. Disponible en: https://www.redalyc.org/articulo.oa?id=377648460007 Sommerville, I. (2011). Ingeniería del software. México: Addison-Weasley, novena edición, traducción al español. Drake, J. (2009). Verificación y validación. España: Universidad de Cantabria, pp. 6, 7. Disponible en: https://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_Verifica cionValidacion-2011.pdf Rodriguez Hernandez, J. (2011, Enero 1). REVISIÓN, VERIFICACIÓN Y VALIDACIÓN EN UN PROCESO DE DESARROLLO DE SOFTWARE. Redalyc, XXXII(1), 10. https://www.redalyc.org/pdf/3604/360433575005.pdf Salazar Bermúdez, G. (2012, Julio 13). Metodología para enseñar a asegurar la calidad del software a través de técnicas de verificación y validación. LATIN AMERICAN CONGRESS, 7. https://citic.ucr.ac.cr/sites/default/files/recursos/metodologia_para_ensenar_a_asegura r_calidad_de_software1.pdf IEEE 830–1993 - IEEE Recommended Practice for Software Requirements Specifications. (1993, 2 diciembre). Recuperado 20 https://standards.ieee.org/standard/830-1993.html de enero de 2022, de González, Zulma, & Sanoja, Andrés, & Rivas, Sergio (2010). UTILIZACIÓN DE MÉTRICAS DE SOFTWARE PARA APOYAR LA SELECCIÓN DE FRAMEWORKS WEB PARA EL SISTEMA DE GESTIÓN DE DATOS ACADÉMICOS DE LA FACULTAD DE CIENCIAS UCV. SABER. Revista Multidisciplinaria del Consejo de Investigación de la Universidad de Oriente, 22(2),185-192.[fecha de Consulta 20 de Enero de 2022]. ISSN: 1315-0162. Disponible en: https://www.redalyc.org/articulo.oa?id=427739444011 León Perdomo, Yeniset, Enrique Góngora Rodríguez, Asnier, & Febles Estrada, Ailyn. (2013). Aplicando métricas de calidad a proyectos y procesos durante las pruebas exploratorias. Revista Cubana de Ciencias Informáticas, 7(2), 193-205. Recuperado en 20 de enero de 2022, de http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S2227-18992013000200008&l ng=es&tlng=es. Watson, A. H., Wallace, D. R., & McCabe, T. J. (1996). Structured testing: A testing methodology using the cyclomatic complexity metric (Vol. 500, No. 235). US Department of Commerce, Technology Administration, National Institute of Standards and Technology. Universidad de la República de Uruguay. (2008). Verificación y Validación. fing.edu.uy. https://www.fing.edu.uy/tecnoinf/maldonado/cursos/ingsoft/materiales/teorico/is09-Ve rificacion-Validacion.pdf
