ARTÍCULO ORIGINAL
ALMEIDA, Hugo Leonardo Nascimento [1], CORREIA, Walter Franklin Marques [2], ALMEIDA FILHO, Adiel Teixeira de [3]
ALMEIDA, Hugo Leonardo Nascimento. CORREIA, Walter Franklin Marques. ALMEIDA FILHO, Adiel Teixeira de. Análisis exploratorio y de correlación sobre el impacto de las pruebas de accesibilidad en proyectos de desarrollo de software para PC. Revista Científica Multidisciplinar Núcleo do Conhecimento. Año. 08, Ed. 03, Vol. 03, págs. 45-62. Marzo 2023. ISSN: 2448-0959, Enlace de acceso: https://www.nucleodoconhecimento.com.br/ciencias-de-la-computacion/desarrollo-de-software, DOI: 10.32749/nucleodoconhecimento.com.br/ciencias-de-la-computacion/desarrollo-de-software
RESUMEN
El trabajo consiste en una introducción teórica que conceptualiza la ingeniería de software, el desarrollo de software, las pruebas, los defectos escapados, la experiencia del usuario, la usabilidad y la accesibilidad. Para realizar una investigación en el área de pruebas centradas en la accesibilidad, se propuso un análisis de proyectos reales. Se realizaron entrevistas con gerentes de proyectos de software que ya están en el mercado, extracción de datos de los mismos proyectos, análisis exploratorio de los datos, pruebas de correlación y estructuración de los resultados encontrados. Al final de la investigación, se observó la relevancia de algunos datos y la importancia de la relación entre ellos. A partir de los resultados obtenidos, se concluye la relevancia de la construcción de casos de prueba para la accesibilidad, así como los factores que contribuyen a que los equipos presten la debida atención a las pruebas de accesibilidad, como la composición del equipo y las colaboraciones externas.
Palabras clave: Pruebas de software, Accesibilidad, Proyecto de desarrollo.
1. INTRODUCCIÓN
Hay una discusión sobre el concepto de ingeniería de software. Algunos asocian la ingeniería de software con la ciencia, otros con la ingeniería. Esta pregunta pone de relieve el carácter dual del software, en general. Mientras que la ingeniería de software considera el proceso de software, que se configura en un proceso de creación de productos, las características de producción son explícitas, es decir, las características de ingeniería en sí mismas. Pero, desde otro punto de vista, el carácter competitivo y comercial, que exponen la necesidad de mejoras continuas y secuenciales en la calidad del proceso de software y del producto, revelan el contexto científico en el que se presenta la ingeniería de software (TRAVASSOS; GUROV; AMARAL, 2002).
En el área de la ingeniería de software, existen metodologías específicas que sientan las bases para la ingeniería y la ciencia. Hay cuatro métodos importantes que ayudan en la realización de experimentos en ingeniería de software, que son: el método científico, el analítico, el método de ingeniería y el método experimental (WOHLIN et al., 2000).
Con el fin de desarrollar una base de evidencia para el conocimiento y la intervención científica en el proceso de desarrollo de software, la ingeniería de software tiene la experimentación como una forma de validar el proceso (TRAVASSOS et al., 2008). En un análisis en el área de ingeniería de software experimental (SJOBERG, DYBA; JORGENSEN, 2007), se señalaron algunos desafíos a enfrentar en la década siguiente, apuntando así a la importancia de la experimentación en el contexto del software.
En medio de los desafíos más específicos, existe una preocupación de los investigadores sobre la necesidad de planificar estudios experimentales de manera más rígida, especialmente en la consideración amplia de los detalles de diseño de las estrategias de estudio, también llamados métodos experimentales aplicables.
Se consideran diferentes cuestiones de disposición debido a la realización de estrategias de estudio, haciendo que todas las preguntas sean específicas para el tipo de estrategia elegida. La validez del estudio puede verse amenazada por la falta de observación de los principales detalles de diseño pertinentes a la estrategia seleccionada. La resolución de este tipo de desafíos requiere un conocimiento explícito sobre las diferentes estrategias de estudio existentes y una adecuada disponibilidad de conocimiento para el investigador, de modo que pueda ser asistido en la toma de decisiones comunes en esta etapa de validación (SJOBERG, DYBA; JORGENSEN, 2007).
Dentro de la ingeniería de software, el desarrollo de software es un tema que implica mucha competitividad con respecto al mercado. Cuanta más calidad presente un sistema, más espacio tendrán en el mercado las empresas que lo desarrollen. Por lo tanto, las empresas, en general, están invirtiendo mucho para garantizar la calidad de sus productos y la satisfacción del cliente. Los procesos de ingeniería de software, como RUP (Rational Unified Process®) (KRUCHTEN, 1998), se utilizan durante el desarrollo del producto, con el propósito de garantizar la calidad, la organización y una mayor productividad. Una parte de la ingeniería de software que ya ha sido señalada como de importancia esencial es la disciplina de las pruebas (PATTON, 2005; PAN, 1999), que será el principal objeto de estudio en el presente trabajo.
El enfoque de las pruebas de software es encontrar defectos en el producto, de modo que la corrección se realice de manera oportuna, para que el producto llegue al cliente. Las pruebas tienen en cuenta la especificación y, a través de la elaboración de los casos de prueba, es posible revelar errores aún no identificados. Los proyectos estudiados en esta publicación son programas para PCs fabricados por una gran multinacional, que contienen las etapas de prueba en el ciclo de desarrollo. Sabiendo que los defectos expuestos a los clientes son algo muy costoso, la búsqueda de soluciones preventivas se realiza a través de pruebas, y su objetivo es descubrir tantos errores como sea posible. En este contexto, surge el concepto de escaped defects (VANDERMARK, 2003). El escaped defect es un defecto que, por varias razones, no fue encontrado por el equipo de prueba durante alguna etapa del proceso. Este trabajo propone precisamente la realización de un análisis de los datos de los proyectos para PC, teniendo en cuenta el trabajo de los times de pruebas, con el fin de mitigar en la medida de lo posible el número de defectos escapados en los proyectos.
En medio del conjunto de pruebas del equipo de calidad, hay pruebas específicas que abordan la usabilidad y accesibilidad de las aplicaciones desarrolladas. La usabilidad y la accesibilidad, cuando están bien implementadas, resultan en proyectos más eficientes y efectivos, que generan una mayor satisfacción del cliente y un mayor alcance de una audiencia que percibe, opera y entiende los sistemas interactivos, independientemente de la capacidad de las personas insertas en este público y del grado de discapacidad que puedan tener.
El camino hacia el éxito de un sistema interactivo se puede facilitar de acuerdo con las prácticas sobre usabilidad, accesibilidad y experiencia del usuario. El conjunto de estos factores puede ser organizado y evaluado a través de intervenciones y estudios.
La plena comprensión de que la usabilidad puede ser específicamente un elemento de mayor eficacia, eficiencia y satisfacción del usuario, y que la accesibilidad tiene un vínculo directo con la capacidad de las personas con diversos grados de discapacidad para percibir, operar y comprender sistemas interactivos, implicará la profundización adecuada del trabajo propuesto.
Las disciplinas de design, accesibilidad, usabilidad y experiencia de usuario proporcionan importantes subvenciones para que se puedan aplicar nuevas técnicas y herramientas con el objetivo de aumentar y mejorar los sistemas interactivos. El estudio de estas técnicas y herramientas permitirá a profesionales como desarrolladores, diseñadores, diseñadores, entre otros, evaluar sistemas interactivos con criterios a mano.
La experiencia del usuario despierta un creciente interés por parte de la comunidad de Interacción Humano-Computadora (IHC). Aunque IHC parece aceptar que solo las funcionalidades o los principios de usabilidad ya no son suficientes, no existe una comprensión coherente de lo que realmente es la experiencia del usuario (HASSENZAHL, 2003). ISO 9241-210 propone definir la experiencia del usuario como todos los aspectos de la experiencia del usuario al interactuar con un producto, servicio, entorno o instalación.
Según ISO 9241-11, la usabilidad se puede definir como la capacidad de un producto para ser utilizado por usuarios específicos para lograr objetivos específicos de manera efectiva, eficiente y satisfactoria en un contexto específico de uso. Siguiendo este concepto, la usabilidad tiene tres principios que la definen. El primer principio es la eficacia. Un sistema es efectivo cuando permite a los usuarios alcanzar sus objetivos. El segundo principio es la eficiencia, que es el esfuerzo realizado para realizar una tarea en el sistema. El tercer principio se refiere a la satisfacción del usuario (DIAS, 2003).
La accesibilidad se define como una posibilidad y condiciones de alcance para el uso seguro y autónomo de los espacios urbanos, mobiliario y equipo, edificios, transporte y sistemas y medios de comunicación por parte de las personas con discapacidad o movilidad reducida. La accesibilidad es parte del concepto de ciudadanía, en el que los individuos tienen derechos garantizados por la ley que deben ser respetados (LAMÔNICA et al., 2008).
La comprensión de los conceptos enumerados y el estudio de las técnicas y métodos de evaluación de las áreas presentadas deben tenerse en cuenta para la formulación de nuevos métodos de evaluación. Los métodos de evaluación de la interfaz difieren entre sí en varios aspectos. Es necesario comprender las diferentes características de cada método, para definir cuál es el más apropiado para evaluar la interfaz de un software en un contexto dado. Las principales diferencias entre los métodos son la etapa del ciclo de diseño de software en la que deben o pueden aplicarse (durante el ciclo de desarrollo o después de tener el producto listo), la técnica utilizada para recopilar los datos (desde entrevistas hasta experimentos en laboratorios), los tipos de datos recopilados (cuantitativos o cualitativos) y, sin embargo, el tipo de análisis realizado (el evaluador puede predecir problemas potenciales o interpretar los datos obtenidos) (PREECE et al., 1994).
Por lo tanto, se pretende, en este trabajo, utilizar técnicas experimentales de ingeniería de software para estudiar y extraer datos de proyectos reales de software comercializados , centrándose en las pruebas de accesibilidad que se encuentran en la base de datos de los proyectos y en todas las actividades y recursos que impregnan la actividad de prueba, a través de entrevistas, análisis exploratorios y pruebas estadísticas.
2. MATERIALES Y MÉTODOS
En esta sección, se describirán todos los pasos descritos y ejecutados durante la investigación, detallando cada paso tal como se realizó.
La línea de investigación en la que se inserta este trabajo se centra en la accesibilidad de los productos digitales. En la búsqueda de proporcionar un modelo heurístico evaluativo para apoyar las decisiones en accesibilidad de productos de software, considerando esto una fase inicial del trabajo, se buscó documentar hallazgos cualitativos y cuantitativos de proyectos reales para poder demostrar la importancia de la atención de la accesibilidad y poder sostener hipótesis que relacionen cantidades de casos de prueba, errores y tareas abiertas dentro de los proyectos.
En la metodología de investigación, fue seguido por la aplicación de pruebas paramétricas y no paramétricas, correlacionando los datos cuantitativos con los datos cualitativos extraídos de entrevistas con los gerentes de los proyectos analizados. Después de eso, se realizó un análisis de los resultados y una síntesis de conclusiones. Se solicitó la evaluación y autorización de la presentación de los resultados por parte de las empresas participantes.
El foco de la investigación fueron los proyectos para CP, a partir de los cuales se presentará la extracción y adaptación de los datos, una encuesta de preguntas de investigación, ubicada en la sección 2.1 de este artículo, y las entrevistas con los gerentes. Se mantuvo la confidencialidad del nombre de los proyectos analizados, describiendo la base de datos con el debido cuidado y haciendo un análisis exploratorio de los datos de manera cuantitativa. No hay interés en exponer los proyectos. Por lo tanto, se obtuvo la autorización para tener acceso a las actividades abiertas de todos los proyectos de PC desarrollados por las empresas analizadas, lo que aseguró la continuación de esta investigación.
2.1 ENTREVISTAS CON EL DIRECTOR DEL PROYECTO
Con la idea de que los proyectos de software, en general, tienen más calidad y alcance cuando tienen elementos de accesibilidad, fue necesario hacer entrevistas con los gerentes de los proyectos de software de una empresa real. Todos los proyectos de la empresa que ya habían sido lanzados al mercado fueron elegidos, por razones de secreto y a petición de la empresa, que no quiso exponer proyectos aún en desarrollo. Además de las entrevistas, fue posible observar desde dentro de uno de los equipos uno de los productos analizados para comprender el pensamiento de los stakeholders cuando se trata de accesibilidad.
En la etapa de observación, se hicieron notas de contexto, que terminaron siendo corroboradas con lo dicho en las entrevistas. En la etapa de entrevista, fue necesario contactar a las personas que gestionaban los equipos que trabajaban directamente con los productos. Una diferencia observada entre las observaciones y la entrevista es que, al observar, las notas están relacionadas con todo el contexto del equipo, sobre el enfoque utilizado por el propio equipo en relación con los artefactos del producto. En la entrevista específicamente con los gerentes, el contexto puede parecer un poco diferente, ya que es la visión única y exclusiva del gerente como agente en ese entorno.
En esta entrevista, se preguntó a los gerentes sobre el número de cada tipo de profesional en el proyecto, la dinámica del equipo, las reuniones, los cambios durante el desarrollo del producto, el proceso de desarrollo en sí y los patrones de diseño utilizados. Se entrevistó a los gerentes de 5 proyectos.
Hubo una preocupación por estructurar la entrevista para que las respuestas estuvieran bien dirigidas a lo que el entrevistador propuso. En base a esto, se creó una guía para la interacción con los gerentes.
Debido a las limitaciones de información que se pueden dar y la confidencialidad de las empresas involucradas, sólo se considerará la ubicación de las empresas, para fines de citación (Pernambuco – PE y São Paulo – SP). Ambas compañías trabajan con el desarrollo de soluciones de PC de alta tecnología en un entorno de desarrollo distribuido.
Las preguntas de la entrevista fueron:
1 – ¿Cuántas personas hay en el equipo del proyecto?
2 – ¿Cuántos desarrolladores tienen? ¿Cuántos son de la empresa en PE y cuántos son de la empresa en SP?
3 – ¿Cuántos testers? ¿Cuántos son de EP y cuántos son de SP?
4 – ¿Cuántos diseñadores? ¿Cuántos son de EP y cuántos son de SP?
5 – ¿Cuáles son los otros participantes/partes interesadas del proyecto? ¿Cuántos son de EP y cuántos son de SP?
6 – ¿Cómo funciona la dinámica del equipo? ¿Sigues algún tipo de heurística?
7 – ¿Cuántas y cuáles son las reuniones del proyecto?
8 – ¿Cuántos pasantes tiene el proyecto? ¿Cuántos son de EP y cuántos son de SP?
9 – ¿Cuántos becarios tiene el proyecto? ¿Cuántos son de EP y cuántos son de SP?
10 – ¿Cuántos residentes tiene el proyecto? ¿Cuántos son de EP y cuántos son de SP?
11 – ¿Qué cambios ocurrieron dentro del equipo a lo largo del proyecto?
12 – ¿Cómo es el proceso de desarrollo? ¿Cuáles son las fases?
13- ¿Hay algún patrón de diseño incorporado?
2.2 DESCRIPCIÓN DE LA BASE DE DATOS UTILIZADA
Para un análisis cuantitativo y cualitativo del impacto de las pruebas de accesibilidad en proyectos de desarrollo de software para PC, se recolectaron datos de una gran empresa de desarrollo de software de todos los proyectos con estas características y que tenían una atención institucionalizada a la accesibilidad durante el desarrollo.
En total, 5 proyectos de la empresa investigada fueron considerados incluidos en las características antes mencionadas. En la tabla 1 infra se considera la información pertinente recopilada durante la recogida de datos, que se realizó manualmente a partir de la autorización que se le otorgó.
Tabla 1 – Datos de los proyectos seleccionados
| Project | Issues | Bugs | Contain “accessibility” bugs | Stories | Contain “accessibility” stories | Test cases | Contain “accessibility” test cases |
| p | 2386 | 827 | 63 | 21 | 8 | 502 | 65 |
| W | 1361 | 376 | 17 | 17 | 2 | 377 | 0 |
| M | 2287 | 893 | 39 | 117 | 10 | 887 | 1 |
| S | 5848 | 1688 | 51 | 135 | 24 | 1049 | 0 |
| G | 4653 | 1943 | 44 | 107 | 20 | 1021 | 0 |
Fuente: elaboración propia.
Para mantener el secreto de los proyectos analizados, se está considerando una carta aleatoria para identificar y diferenciar los datos. La información relevante extraída es: actividades registradas en la herramienta de gestión de proyectos, errores registrados por el equipo, errores que contienen la identificación de accesibilidad dentro de sí mismo, funcionalidades a desarrollar (historias de usuario), funcionalidades que contienen la identificación de accesibilidad dentro de sí mismo, casos de prueba y casos de prueba dirigidos a la accesibilidad.
Las actividades registradas se refieren a cualquier tipo de esfuerzo localizado y registrado relacionado con el proyecto analizado, que puede ser una actividad de desarrollo de software, pruebas, DevOps, diseño, etc. Los errores registrados por el equipo son defectos encontrados durante la implementación y validación de tareas. Los errores que se identificaron como errores de accesibilidad se registraron con una etiqueta que así lo identificó. Son bichos que implican en la percepción, funcionamiento y comprensión de personas con diversos grados de discapacidad a la hora de tener contacto con el producto. Las funcionalidades son todas las acciones posibles dentro del programa desarrollado, por lo tanto, las funcionalidades identificadas con la etiqueta de accesibilidad se refieren a opciones para monitorear a personas con discapacidades en el contexto del software. Los casos de prueba son las actividades de los evaluadores en el proyecto, por lo que cada prueba de accesibilidad es una prueba relacionada con estas características de accesibilidad.
La Tabla 2 a continuación describe la información recopilada en las entrevistas con los gerentes de proyecto, para respaldar la información cuantitativa extraída en la herramienta de gestión de proyectos y para establecer relaciones en el cruce entre todos los datos. En esta tabla se está considerando información más orientada al equipo (composición, dinámica, comentarios).
Tabla 2 – Características de los equipos de los proyectos analizados
| Project | Team people | Developers | Testers | Designers | Others | Extern Team | Input/Output people | Design Patterns | Comments |
| p | 20 | 60% | 20% | 5% | 15% | 45% | aumentó 9 | ||
| W | 13 | 46,15% | 15,38% | 15,38% | 23,07% | 38,46% | 7 | Sharing sessions | |
| M | 11 | 54,54% | 18,18% | 9,09% | 18,18% | 45,45% | -2 | ||
| S | 29 | 55,17% | 27,58% | 6,89% | 3,44% | 34,48% | 5 | ||
| G | 40 | 60% | 25% | 2,5% | 22,5% | 40% | 6 | 4 |
Fuente: elaboración propia.
2.3 ANÁLISIS EXPLORATORIO DE DATOS
En el análisis exploratorio de los datos obtenidos de los proyectos, se realizaron algunas observaciones relevantes, que se comparten aquí. Para una mejor observación de los análisis, los datos que se consideraron un punto clave para los comentarios se destacaron por color en la Figura 1. La Figura 1 consiste en la unión de los datos presentados en las tablas anteriores con la adición de columnas que ilustran el porcentaje de valores de error en relación con el total de problemas, errores de accesibilidad en relación con todos los errores, historias de usuario dirigidas a la accesibilidad en relación con el total de historias y casos de prueba de accesibilidad en relación con el total de casos de prueba creados por los equipos.
Figura 1 – Incorporación de los datos recopilados por proyecto
El proyecto (P) que tiene, proporcionalmente, más funcionalidad y pruebas enfocadas a la accesibilidad es el proyecto que registra la mayor tasa de errores de accesibilidad. Es decir, cuanto más se preocupe por la accesibilidad, más oportunidades de correcciones se identificarán. Aquí es posible discutir la importancia de la atención a las pruebas de accesibilidad, porque sin ellas, el número de defectos que pueden pasar por el equipo sin ser identificados y, en consecuencia, corregidos tiende a aumentar. Curiosamente, este fue el proyecto que tuvo el mayor aumento de colaboradores en el equipo durante el desarrollo (coloración verde).
El equipo (W) que contiene menos desarrolladores y testers, proporcionalmente, es el equipo que registra menos actividad en general, pero aún así abre errores orientados a la accesibilidad a un ritmo mayor que el promedio de los proyectos analizados, mostrando que no hay una consecuencia directa entre el número de desarrolladores, probadores o personal técnico y la tasa de errores de accesibilidad encontrados. Este fue el único equipo que mencionó la celebración de sesiones de intercambio entre los empleados (color azul).
Los dos equipos con más colaboración externa (P y M) son los únicos que tienen pruebas de accesibilidad. Esta información nos lleva a creer que existe una influencia externa positiva en el cuidado de la accesibilidad para esta empresa que participó en la investigación (coloración dorada).
Los dos proyectos (S y G) que contienen la mayor cantidad de contribuyentes son los únicos que han citado el uso de estándares de diseño, pero tienen proporcionalmente menos errores de accesibilidad registrados. Aquí se observa que el conocimiento técnico y el enfoque de las técnicas de programación y la arquitectura de software que se utilizaron no tienen relación directa con la accesibilidad (coloración naranja).
2.4 PRUEBAS PARAMÉTRICAS
En continuidad con el análisis de los datos, se propuso realizar pruebas estadísticas para la extracción de correlaciones entre los datos de los proyectos. La prueba elegida para medir la relación estadística entre las variables fue el coeficiente de correlación de Pearson.
En estadística descriptiva, el coeficiente de correlación de Pearson, también conocido como coeficiente de correlación del momento del producto de Pearson, se denota con la letra ρ , para un parámetro de población, y con r, para un estadístico de muestra. Se utiliza cuando ambas variables estudiadas están normalmente distribuidas. Este coeficiente se ve afectado por valores extremos, que pueden ampliar o amortiguar la fuerza de la relación (MUKAKA, 2012). La fórmula para calcular el coeficiente de correlación de la muestra de Pearson se muestra en la Figura 2.
Figura 2 – Fórmula del coeficiente de correlación de la muestra de Pearson
Se hicieron asociaciones entre errores, historias de usuario y casos de prueba vinculados a la accesibilidad y el porcentaje de desarrolladores, probadores y diseñadores en los proyectos estudiados. De las observaciones realizadas, la principal es la correlación entre errores y casos de prueba y entre historias de usuario y casos de prueba, lo que indica que los casos de prueba constituyen un factor central en relación con el número de actividades que involucran accesibilidad. Otro punto interesante son las correlaciones con los diseñadores, que destacan estadísticamente, mostrando más relevancia en los equipos en relación a los otros grupos de colaboradores.
En un intento de complementar las pruebas con otro tipo de prueba, esta vez una prueba de hipótesis no paramétrica, no se encontraron resultados significativos. Sin embargo, el análisis cualitativo trajo resultados más expresivos, que pueden ser corroborados y complementados con las correlaciones estadísticas presentadas.
A continuación en la Figura 3 está el resultado de las correlaciones a través de la prueba de relación de Pearson, representada por la matriz de dispersión de los valores asociados. Los valores resaltados con %1, %2 y %3 representan los valores de las columnas del mismo nombre en las columnas de la figura 1. Estos son los porcentajes de errores de accesibilidad, historias de usuario de accesibilidad y casos de prueba de accesibilidad, respectivamente.
Figura 3 – Matriz de dispersión de valores asociados
3. PREGUNTAS PLANTEADAS SOBRE LOS PROYECTOS
Con el fin de proporcionar un modelo heurístico evaluativo para apoyar las decisiones sobre la accesibilidad de los productos de software, fue necesario documentar los hallazgos cuantitativos de proyectos reales. El foco se delimitó en proyectos para PC, de los cuales se presentó el modelado, la adaptación de datos y el proceso de decisión. Esto llevó a la compilación de una serie de preguntas de investigación para guiar el análisis de los resultados, para poder demostrar la importancia de la atención con accesibilidad y para sostener hipótesis que relacionan cantidades de casos de prueba, errores y tareas abiertas dentro de los proyectos.
Estas preguntas de investigación, que no se clasifican según su importancia, se presentan enumeradas a continuación:
1 – ¿Qué características de los equipos influyen en la cantidad de errores abiertos ?
2 – ¿Qué técnicas utilizadas para minimizar los errores tuvieron los mejores resultados?
3 – ¿Es significativo el impacto de las pruebas de accesibilidad?
4 – ¿Es posible predecir el bugging para la accesibilidad en relación con el número de casos de prueba de accesibilidad del proyecto?
5 – ¿Existe una relación entre el número de desarrolladores, probadores o personal técnico y la tasa de errores de accesibilidad encontrados?
6 – ¿Hay influencia en la atención de accesibilidad en proyectos que reciben más colaboración externa?
7 – ¿El conocimiento técnico y el enfoque de las técnicas de programación y la arquitectura de software están directamente relacionados con el conocimiento en accesibilidad?
Las preguntas fueron formuladas con el propósito de buscar comprender la correlación entre los resultados de los datos cuantitativos y la información recogida de los gestores.
4. ANÁLISIS DE RESULTADOS
Esta investigación presentó el análisis de los resultados obtenidos de las entrevistas con los gestores de los proyectos seleccionados; extracción manual de información relevante de los proyectos, directamente de la herramienta de gestión institucional y apoyo de los equipos participantes; explotación de los datos para realizar observaciones cualitativas de la información; y aplicación de prueba paramétrica a los datos recogidos. En total, se catalogaron 16535 actividades de desarrollo de software dentro de 5 proyectos reales de programas desarrollados para PC, involucrando a 113 profesionales. Con base en la presentación de los resultados, se verificó el conjunto de preguntas de investigación.
La característica de los equipos que influye en la cantidad de errores abiertos es: el número proporcional de desarrolladores y probadores, es decir, un mayor porcentaje de presencia de diseñadores en el proyecto indica un menor registro de actividades y, en consecuencia, errores abiertos.
No hay indicación de técnicas utilizadas para minimizar los errores, por el contrario, el proyecto que proporcionalmente presenta más funcionalidades y pruebas enfocadas a la accesibilidad es el proyecto que registra la mayor tasa de errores de accesibilidad. La investigación muestra que cuanta más atención se presta a la accesibilidad, más defectos son identificados y corregidos por el equipo antes de salir al mercado. Otro resultado relevante es la indicación de que un aumento en el equipo genera un mayor compromiso para registrar más errores y actividades en general.
El impacto de las pruebas de accesibilidad es significativo, considerando que cuanto mayor es el número de pruebas centradas en la accesibilidad, mayor es el número de defectos de accesibilidad encontrados y, en consecuencia, corregidos en el proyecto. Este factor fue encontrado a través del análisis exploratorio, y es posible percibirlo en la prueba paramétrica.
Sobre la base de los resultados, es posible predecir la apertura de errores de accesibilidad en relación con el número de casos de prueba de accesibilidad registrados para el proyecto, debido a esta relación proporcional.
Según los resultados, se percibe que no hay una consecuencia directa entre el número de desarrolladores, probadores o personal técnico y la tasa de errores de accesibilidad encontrados, porque el equipo contiene menos desarrolladores y pruebas. Proporcionalmente, es el equipo que registra menos actividades en general, pero aún así abre errores dirigidos a la accesibilidad a un ritmo superior a la media de los proyectos analizados.
Para responder a una pregunta de investigación más planteada, solo tenga en cuenta que los equipos con más colaboración externa son los únicos que tienen pruebas de accesibilidad. Esta información denota que existe una influencia externa positiva con respecto a la atención de accesibilidad para esta empresa que participó en la investigación.
El conocimiento técnico y el enfoque de las técnicas de programación y la arquitectura de software que se utilizaron no tienen relación directa con la accesibilidad, porque los gerentes que citaron el uso de patrones de diseño administran los proyectos que registraron menos errores de accesibilidad proporcionalmente.
5. CONCLUSIONES
A través de la investigación realizada, es posible inferir cualitativamente algunas conclusiones. Una primera conclusión se refiere a la composición de los equipos de desarrollo de software: el número de errores registrados tiende a disminuir ya que los equipos tienen, proporcionalmente, menos desarrolladores y evaluadores.
Una segunda conclusión es la creciente ola de oportunidades de remediación que se pueden identificar a partir de una mayor atención a las pruebas de accesibilidad. De esta manera se reduce la tasa de defectos escapados.
En general, se piensa que cuanto mayor sea el número de empleados en el equipo durante el desarrollo, mayor será el esfuerzo en la creación de las pruebas y en la contención de defectos escapados, sin embargo, no hay una consecuencia directa entre el número de personas y la tasa de errores de accesibilidad encontrados. Al mismo tiempo, otra conclusión es que el conocimiento técnico y el enfoque de las técnicas de programación y la arquitectura de software no tienen relación directa con la accesibilidad.
Esta investigación retrata una influencia externa positiva en el cuidado de la accesibilidad para los proyectos analizados.
Finalmente, se percibe que la creación de pruebas de accesibilidad es beneficiosa y efectiva, y que cuanto mayor sea la cantidad de pruebas centradas en la accesibilidad, mayor será la cantidad de correcciones registradas internamente a realizar y menor será la cantidad de defectos de accesibilidad escapados.
Para futuros trabajos, se sugiere una muestra más amplia, con proyectos que ya están en el mercado y proyectos aún no lanzados, en proceso de desarrollo, además de extraer datos de diferentes empresas para poder comparar y analizar las posibles similitudes y divergencias y reflexionar sobre la influencia de la cultura organizacional en el desarrollo de pruebas de accesibilidad.
REFERENCIAS
DIAS, Sérgio Roberto (coord.). Gestão de marketing. São Paulo: Saraiva, 2003.
HASSENZAHL, Marc. The Thing and I: understanding the relationship between user and product. In: BLYTHE, Mark A. et al. Funology: from usability to enjoyment. Dordrecht: Kluwer Academic Publisher 2003.
KRUCHTEN, Philippe. The Rational Unified Process. Boston: Addison-Wesley, 1998.
LAMÔNICA, Dionísia Aparecida Cusin et al. Acessibilidade em ambiente universitário: identificação de barreiras arquitetônicas no campus da USP de Bauru. Revista Brasileira de Educação Especial, v. 14, p. 177-188, 2008.
MUKAKA, Mavuto M. A guide to appropriate use of correlation coefficient in medical research. Malawi Medical Journal, v. 24, n. 3, p. 69-71, 2012.
PAN, Jiantao. Software Testing. 1999. Disponível em: http://users.ece.cmu.edu/~koopman/des_s99/sw_testing/. Acesso em: 15 mar. 2023.
PATTON, Ron. Software testing. 2nd ed. United States: Pearson Education, 2005.
PREECE, Jenny et al. Human-computer interaction. England: Addison-Wesley, 1994.
SJOBERG, Dag I. K.; DYBA, Tore; JORGENSEN, Magne. The future of empirical methods in software engineering research. In: International Conference on Software Engineering (ICSE), Minneapolis, p. 123-156, 2007.
TRAVASSOS, Guilherme Horta et al. An environment to support large scale experimentation in software engineering. In: 13th IEEE International Conference on Engineering of Complex Computer Systems, 2008.
TRAVASSOS, Guilherme Horta; GUROV, Dmytro; AMARAL, E. A. G. G. Introdução à engenharia de software experimental. Rio de Janeiro: COPPE/UFRJ, 2002.
VANDERMARK, Mary Ann. Defect escape analysis: test process improvement. In: Proceedings of the Software Testing Analysis and Review Conference, 2003.
WOHLIN, Claes et al. Experimentation in software engineering: an introduction. USA: Kluwer Academic Publishers, 2000.
[1] Maestro. ORCID: 0000-0003-4467-0113. CURRÍCULUM DE LATTES: http://lattes.cnpq.br/9433837114578364.
[2] Doctor. ORCID: 0000-0002-6491-9783. CURRÍCULUM DE LATTES: http://lattes.cnpq.br/3252289006108114.
[3] Consejero. Doctor. ORCID: 0000-0001-6069-3601. PLAN DE ESTUDIOS DE LATTES: http://lattes.cnpq.br/9944976090960730.
Enviado: 26 de enero, 2023.
Aprobado: 03 de marzo de 2023.
