UNIVERSIDAD DE COSTA RICA
SISTEMA DE ESTUDIOS DE POSGRADO
DESARROLLO DE UN PROTOTIPO DE HERRAMIENTA PARA AUTOMATIZAR EL CONTEO
DE PUNTOS SNAP DE LA INTERFAZ GRÁFICA EN PROYECTOS REALIZADOS CON
DRUPAL
Trabajo Final de Investigación Aplicada sometido a la consideración de la
Comisión del Programa de Estudios de Posgrado en Computación e
Informática para optar al grado y título de Maestría Profesional en
Computación e Informática
MERLIN SÁNCHEZ VALVERDE
Ciudad Universitaria Rodrigo Facio, Costa Rica
2021
DEDICATORIA
A Dios, a mi madre, padre, familia, novia, profesores del postgrado y amigos que me
apoyaron he inspiraron a continuar y salir adelante.
AGRADECIMIENTOS
A mis profesores asesores Dr. Marcelo Jenkins Coronas, Dra. Alexandra Martínez
Porras y Dr. Christian Quesada López por su guía, dedicación y esfuerzo en la
realización de este trabajo. A la empresa ParallelDevs por su colaboración en todo
mi proceso de la maestría.
ii
iii
TABLA DE CONTENIDO
Dedicatoria .................................................................................................................... ii
Agradecimientos ........................................................................................................... ii
Hoja de aprobación ...................................................................................................... iii
Tabla de Contenido ...................................................................................................... iv
Resumen ...................................................................................................................... vi
Lista de Tablas ............................................................................................................ vii
Lista de Figuras .......................................................................................................... viii
Lista de Abreviaturas ................................................................................................... ix
1. Introducción .............................................................................................................. 1
1.1 Objetivo general ................................................................................................. 3
1.2 Objetivos específicos ......................................................................................... 4
2. Marco Teórico ........................................................................................................... 6
2.1 Medición del tamaño del software.................................................................... 6
2.2 Tipos de métricas de tamaño ............................................................................ 6
2.3 SNAP ................................................................................................................... 9
2.4 COSMIC ............................................................................................................ 16
2.5 Tecnologías web .............................................................................................. 16
2.6 Extensión ......................................................................................................... 18
2.7 JIRA ................................................................................................................... 18
2.8 Drupal desacoplado ........................................................................................ 18
3. Trabajo Relacionado.............................................................................................. 20
4. Metodología ........................................................................................................... 23
5. Reglas de Mapeo ................................................................................................... 28
6. Conteo Manual Subcategoría Interfaz de Usuario 2.1........................................ 30
7. Diseño e Implementación ..................................................................................... 34
7.1 Arquitectura del prototipo de herramienta .................................................... 34
7.2 Delimitación ..................................................................................................... 36
7.3 Diseño del prototipo de herramienta ............................................................. 38
7.4 Desarrollo del prototipo de herramienta ....................................................... 40
7.5 Validación de la herramienta ......................................................................... 44
7.5.1 Proyectos web usados en la validación...................................................... 45
7.6 Ejecución de la herramienta prototipo .......................................................... 46
7.7 Amenazas a la validez .................................................................................... 47
8. Análisis de Resultados .......................................................................................... 48
8.1 Resultados ....................................................................................................... 48
8.2 Discusión ......................................................................................................... 51
9. Conclusiones .......................................................................................................... 54
9.1 Trabajo futuro .................................................................................................. 55
10. Bibliografía ........................................................................................................... 56
11. Anexos .................................................................................................................. 59
iv
Anexo 1: Requerimientos no funcionales de los cuatro proyectos web ............ 59
Anexo 2: Tabla conteo de puntos snap manual .................................................. 60
Anexo 3: Tabla comparativa conteo manual y automático ................................. 61
v
RESUMEN
El principal objetivo de medir el proceso de desarrollo de software es apoyar la toma
de decisiones gerenciales. Estimar el tamaño, esfuerzo y tiempo que se necesita
para producir un software es una tarea importante dentro de todo proceso de
medición. Las estimaciones incorrectas pueden causar pérdidas económicas
importantes a las empresas que desarrollen software [1]. Un enfoque automático de
medición de tamaño del software no funcional podría apoyar el proceso de
estimación generando datos históricos en un menor tiempo, mejorando
eventualmente la calidad de las estimaciones.
En este trabajo se presentan los resultados de la creación y evaluación de un
prototipo de herramienta de software que, calcula automáticamente el tamaño de
los requisitos no funcionales (NFR por sus siglas en inglés) de la subcategoría de
Interfaz de Usuario 2.1 del método SNAP (Software Non-functional Assessment
Process). Para su desarrollo e implementación se utilizó la metodología Ciencias del
Diseño basándose en el Modelo del Ciclo de Diseño [28], se seleccionó un conjunto
de proyectos web, de los cuales se obtuvieron los requerimientos no funcionales.
Posteriormente se realizó un conteo manual de dichos requerimientos y se evaluó la
exactitud de la herramienta en comparación con el conteo manual.
Los resultados presentan un nivel de exactitud del 100% en el conteo de puntos
SNAP para la categoría 2.1 interfaz gráfica. Sin embargo, hay ciertas diferencias en
la detección correcta de propiedades de la interfaz de usuario que, aunque no
afectaron a la exactitud final de la estimación, sí son incorrectas.
Este trabajo aporta evidencia de la viabilidad del uso de un prototipo de
herramienta de software que, por medio de reglas de mapeo aplicadas en el código
ya desarrollado en HTML y CSS, puede automatizar el conteo de puntos SNAP para
la subcategoría 2.1 interfaz gráfica.
vi
LISTA DE TABLAS
Tabla 1: Lista de categorías y subcategorías de SNAP (adaptada de [5]). ................ 10
Tabla 2: Tamaño de SNAP para interfaces de usuario. Adaptada de [5]. ................. 14
Tabla 3: Detalle del resultado del conteo manual. ..................................................... 33
Tabla 4: Comparación de los resultados (exactitud) entre el conteo manual y el
prototipo de herramienta. ..................................................................................... 49
Tabla 5: Detalles del resultado del conteo manual y conteo con el prototipo de
herramienta. ........................................................................................................... 50
vii
LISTA DE FIGURAS
Figura 1: Pasos y procesos de la metodología. ........................................................... 23
Figura 2: Ciclo de Diseño por Vaishnavi and Kuechler 2011 (adaptada de [28]). ... 26
Figura 3: Inspeccionado las propiedades UI del botón para el formulario contacto del
sitio ADNCuba. ....................................................................................................... 31
Figura 4: Arquitectura de la herramienta prototipo (tomado de [30]). ...................... 35
Figura 5: Diseño funcional del prototipo de herramienta ........................................... 39
Figura 6: Wireframe del diseño de la interfaz gráfica del prototipo de herramienta. 40
Figura 7: Interfaz gráfica de la extensión prototipo de herramienta.......................... 41
Figura 8: Resultado del conteo de la herramienta prototipo. ..................................... 43
Figura 9: Comparación en el conteo de SP a nivel del número de propiedades. ..... 51
Figura 10: Formulario custom en Drupal para evaluar el prototipo de herramienta.52
viii
LISTA DE ABREVIATURAS
▪ COSMIC: Common Software Metrics International Consortium.
▪ CSS: Cascade Stylesheets.
▪ DOM: Document Object Model
▪ FiSMA: Finnish Software Measurement Association.
▪ IFPUG: International Function Point Users Group
▪ JS: JavaScript.
▪ JSON: JavaScript Object Notation
▪ NFR: Non-functional requirement
▪ NESMA: Netherlands Software Metrics Association.
▪ SCUs: SNAP Counting Units.
▪ SNAP: Software Non-functional Assessment Process
▪ UML: Unified Modeling Language
ix
1
1. INTRODUCCIÓN
La medición de software es un área que cubre una amplia variedad de actividades
en la ingeniería de software. Definir los datos que se necesitan e implementar
herramientas y procedimientos para recopilarlos y analizarlos son algunas de las
tareas que componen la medición de software [1].
La medición de tamaño funcional es un enfoque estandarizado para evaluar el
tamaño del software que es independiente del lenguaje de programación, dado que
se basa en una evaluación de los requisitos funcionales del usuario que se
implementarán en el software [2].
Por otro lado, la medición del tamaño no funcional es el proceso que permite medir
el tamaño del software derivado de la cuantificación de los requisitos no funcionales
(NFR), definidos por un conjunto de reglas [3]. El tamaño no funcional se puede
usar junto con el tamaño funcional para proporcionar una vista general del proyecto
o aplicación [3].
Para lograr una estimación de proyectos de desarrollo de software con una mayor
exactitud, se precisa del uso de métodos que midan el tamaño de los proyectos a
estimar. Existen diversos métodos que se pueden utilizar para realizar esta
estimación, tales como “IFPUG FPA, MkII FPA, NESMA FPA, COSMIC FFP, FiSMA FSM
entre otros [4].
Con el propósito de calcular el tamaño de los requerimientos no funcionales (NFR),
la International Function Point Users Group (IFPUG) desarrolló en el 2009 el método
llamado Proceso de Evaluación de Software no Funcional (SNAP por sus siglas en
inglés). Posteriormente, se aplicaron revisiones por parte de la Junta de IFPUG, el
Comité de Nuevos Entornos de IFPUG y el Comité de Prácticas de conteo de IFPUG,
resultando una versión borrador (octubre de 2009) del Manual de Prácticas de
Evaluación SNAP. Después de que se realizaron las correcciones pertinentes al
manual, se lanzó la versión beta de SNAP en noviembre del 2010 [5]. Dicho método
2
definió cuatro categorías y catorce subcategorías para medir los requisitos no
funcionales de un software [6].
El principal objetivo de medir el proceso de desarrollo de software es apoyar la toma
de decisiones gerenciales [1], ya que producir software de calidad que se entregue
a los clientes a tiempo es una tarea desafiante y predecir el esfuerzo que se
necesita para producir el software lo es aún más [1]. Las estimaciones incorrectas
de la calidad del código o del ciclo de vida del desarrollo pueden causar pérdidas
económicas importantes a las empresas que desarrollen software. [1]
El presente trabajo está contextualizado en una empresa pequeña de desarrollo de
software costarricense en la cual labora el investigador y utiliza Drupal como
tecnología principal para el desarrollo de aplicaciones web.
Dicha compañía necesita poder medir y estimar el tamaño de las tareas que
componen un proyecto común de forma automática y rápida evitando el uso del
juicio de experto que usualmente incide en una estimación de esfuerzo imprecisa
de los proyectos.
La mayor parte del desarrollo de los proyectos con la herramienta Drupal se centran
en implementar los requerimientos no funcionales, especialmente el desarrollo de
la interfaz gráfica ya sea agregando o modificando los estilos dentro de la misma.
Drupal posee varios módulos (código que se puede integrar y trabajar con Drupal)
que extienden su funcionalidad de manera que no es necesario el desarrollo
funcional de la aplicación. Por ejemplo, el módulo Webform [7] nos permite crear
formularios y encuestas desde una interfaz gráfica sin necesidad de programar
funcionalidades relacionadas al nuevo formulario, dejando pendiente solo la
implementación de los estilos por medio de CSS, esto quiere decir que en los
proyectos web desarrollados con Drupal la mayoría del esfuerzo de desarrollo se
basa en la implementación de los NFR tales como la estilización del sitio web
(interfaz gráfica).
3
La carencia de métodos para calcular el tamaño de proyectos web desarrollados
con Drupal es una realidad actual en la empresa costarricense bajo estudio que se
dedica al desarrollo de soluciones web utilizando Drupal. El método SNAP es viable
para realizar esta estimación.
En una revisión exploratoria de literatura realizada sobre las bases de datos
Springer Link, IEEE Xplore Digital Library, ACM Digital Library, ScienceDirect Digital
Library y Google Scholar, no se encontró documentación de experiencias sobre
estimación de tamaño de proyectos web desarrollados con Drupal usando SNAP.
Sin embargo, SNAP ha sido utilizado en varios trabajos de investigación los cuales
se describen en la sección 3 Trabajo Relacionado.
1.1 OBJETIVO GENERAL
Desarrollar un prototipo de herramienta de software que calcule automáticamente
el tamaño de los requerimientos no funcionales de la subcategoría de interfaz de
usuario 2.1 del método SNAP, para proyectos de software desarrollados con Drupal,
en el contexto de una empresa de desarrollo web en Costa Rica.
4
1.2 OBJETIVOS ESPECÍFICOS
Los objetivos específicos del proyecto son los siguientes:
1. Identificar los requerimientos no funcionales de un conjunto de
proyectos web implementados con Drupal en la empresa bajo estudio.
2. Implementar el prototipo de herramienta para calcular el tamaño de los
requerimientos no funcionales de la subcategoría 2.1 interfaz de usuario
(UI) de SNAP.
3. Evaluar la exactitud de los resultados obtenidos con el prototipo de
herramienta con respecto a la aplicación manual del método SNAP, en
un conjunto de proyectos web desarrollados con Drupal.
Los proyectos para esta investigación se obtendrán de dicha empresa de desarrollo
de software. Dado este escenario, este TFIA propone el uso del método SNAP para
estimar el tamaño de los proyectos (Interfaces de usuario (UI)) desarrollados con
Drupal.
Es importante señalar que, según la experiencia del investigador, el proceso de
contar puntos SNAP de forma manual puede ser lento y tedioso. Además, Mansoor y
Ochodek reportaron que es difícil lograr transparencia en el seguimiento de qué
elementos de la interfaz de usuario se configuraron para cumplir con ciertos
requisitos no funcionales [8]. Por esta razón, como parte de este trabajo, se
desarrolló e implementó un prototipo de herramienta de software que automatiza el
conteo de puntos SNAP para la subcategoría 2.1 interfaz de usuario (UI) en
proyectos desarrollados con Drupal.
Actualmente, la mala estimación de los proyectos existentes en la empresa bajo
estudio podría afectar negativamente su imagen; por ello, es de vital importancia
utilizar un método de estimación de proyectos y generar datos históricos, tanto en
tamaño como en esfuerzos, que funcionen como insumos para realizar
estimaciones por medio de métodos estadísticos tales como la regresión lineal, por
5
mencionar un ejemplo. Sin esta base de datos históricos, la exactitud de la
estimación de tamaño y esfuerzo de los proyectos podría disminuir. El desarrollo de
un prototipo de herramienta podría ayudar a la creación de dicha base de datos de
tamaños de los proyectos y eventualmente poder crear estimaciones sin utilizar
juicio de experto y con ello potencialmente mejorar las estimaciones del esfuerzo
requerido para el desarrollo de nuevos proyectos web implementados con Drupal.
Este documento está organizado de la siguiente manera: en la sección 2 se
desarrolla el marco teórico. La sección 3 explica el trabajo relacionado, la sección 4
describe la metodología de trabajo. La sección 5 presenta el conteo manual de
puntos SNAP para la subcategoría 2.1, la sección 6 envuelve el diseño e
implementación del prototipo de la herramienta, en la sección 7 se analiza los
resultados obtenidos; por último, en la sección 8 se presentan las conclusiones
extraídas y el trabajo futuro propuesto para este TFIA.
6
2. MARCO TEÓRICO
2.1 MEDICIÓN DEL TAMAÑO DEL SOFTWARE
Una de las preguntas clave que los administradores de proyectos deben responder
es "¿qué tan grande será mi proyecto de software?" La clave para responder a esta
pregunta es el tamaño del software. El tamaño del software es el principal
determinante del volumen del proyecto y se usa comúnmente como un proxy del
tamaño del proyecto. El tamaño del software es una base para las actividades
esenciales de gestión de proyectos, como la planificación, el seguimiento y el
control del alcance y la productividad del proyecto [9].
El tamaño es un factor determinante en el esfuerzo requerido para el desarrollo y/o
mantenimiento de los proyectos de software. La medición efectiva del tamaño del
software es, por lo tanto, un elemento clave para una estimación exitosa del
esfuerzo. Medir el tamaño del software de manera errónea suele ser el principal
contribuyente a las estimaciones de esfuerzo fallidas y, en consecuencia, a los
proyectos fallidos [9].
2.2 TIPOS DE MÉTRICAS DE TAMAÑO
Briand y Wieczorek en el 2002 [9] agrupan los métodos de medición del software
en dos tipos: orientados a problemas y orientados a soluciones. Las métricas
orientadas a problemas representan el tamaño del problema que resolverá el futuro
producto de software, es decir, la funcionalidad objetivo del sistema. Ya que estas
métricas generalmente se enfocan en medir elementos de la funcionalidad del
software, también se les conoce comúnmente como métricas de tamaño funcional.
Las métricas orientadas a soluciones representan el tamaño de los resultados del
desarrollo de software, como las especificaciones, el diseño o la implementación del
sistema de software. Al centrarse normalmente en medir las propiedades
estructurales de los productos de software, también se les conoce como métricas
de tamaño estructural. En otras palabras, podríamos decir que mientras los
métodos de medición orientados a problemas representan la perspectiva del
7
cliente, los métodos orientados a soluciones representan la perspectiva del
desarrollador [9].
Métodos para estimar el tamaño funcional del software
• Puntos de función: Introducido por Albrecht, el método de punto de función
mide el tamaño relativo de las funciones de software en función de la
cantidad de diferentes tipos de datos procesados por una función de
software. El enfoque de Albrecht evolucionó hacia diversas variantes de
métodos de medición de tamaño funcional tales como: IFPUG, NESMA,
FiSMA, COSMIC y Mk II [9].
• Puntos de características: Introducido por Jones, el "Método de punto de
características SPR" amplió el método de punto de función de Albrecht al
contar adicionalmente algoritmos y multiplicar este recuento por la
complejidad relativa de un algoritmo [9].
• Puntos de casos de uso: introducidos por Karner, los puntos de casos de uso
(UCP) están inspirados en el análisis de puntos de función basados en su
filosofía. Las entradas para UCP son especificaciones de casos de uso [9].
• Puntos de historia: introducido por Cohn, con el propósito de estimar el
tamaño de los proyectos de software ágil. El punto de historia es una unidad
abstracta del tamaño del software que representa una mezcla intuitiva de
esfuerzo de desarrollo y complejidad [9].
• Puntos de objeto: se han propuesto varias métricas de puntos de objeto
diferentes para medir el tamaño del software. Dos ejemplos de métodos de
medición son [9]:
o Puntos de objeto (OP): introducido por Banker, los puntos de objeto
miden el tamaño del software contando los widgets visuales de los
lenguajes de cuarta generación en entornos CASE integrados.
o Puntos de objeto predictivo (POP): introducido por Minkiewicz, los POP
se basan en recuentos de clases y métodos ponderados por clase,
con ajustes para la profundidad promedio del árbol de herencia y el
número promedio de elementos hijos de dicho árbol por clase.
8
• Objetos Web: introducido por Reifer, el método de Objetos Web extiende el
conocido Análisis de Puntos de Función (FPA) en el que, además de los cinco
elementos ya considerados en FPA, se cuenta cuatro elementos específicos
de la aplicación web: archivos multimedia, bloques web, scripts y enlaces [9].
Métodos para estimar el tamaño estructural del software
• Líneas de código: el método de líneas de código (LOC) mide el tamaño del
software contando el número de líneas en el texto del código fuente del
programa. Hay muchas variaciones de la métrica LOC. Se diferencian
principalmente en la manera en que se considera lo que es una línea de
código [9].
• La ciencia de Halstead: introducida por Halstead (1977), la medida científica
comprende varias métricas del tamaño del código del software y la
complejidad. Entre ellas se encuentran la longitud de Halstead y el volumen
de Halstead. Las métricas científicas de Halstead rara vez se han utilizado en
la práctica [9].
• Métricas de conteo primitivo: estos métodos comprenden el recuento simple
de elementos estructurales de un artefacto de software. Ejemplos de
encarnaciones de este enfoque incluyen medir el número de archivos dentro
del código fuente del software, el número de requisitos en la especificación
de requisitos o el número de actividades en las especificaciones del software
UML [9].
Adicionalmente, se dispone de métodos para estimar el tamaño no funcional del
software entre ellos: NFR método de medición de tamaño (NFSM) [3] que es más un
prototipo preliminar y IFPUG SNAP que es en sí un marco de trabajo consolidado y
probado en la industria [5].
NFSM, como solución propuesta, muestra la manera en que la medición del tamaño
funcional de los NFR se integra en el marco de trabajo de los NFR. Se considera el
marco de trabajo de NFR como el vehículo para obtener, documentar y poner en
9
funcionamiento los NFR. Adicionalmente, se propone la aplicación de COSMIC-FFP
para obtener los datos de tamaño funcional NFR. Posteriormente, estos datos se
proporcionan a las partes interesadas pertinentes para ayudarles en su proceso de
toma de decisiones [10]. Respecto a SNAP, se describe en detalle en el siguiente
párrafo.
2.3 SNAP
SNAP (Software Non-functional Assessment Process – Proceso de evaluación no
funcional del software) es un marco de evaluación para determinar el tamaño no
funcional del software. Sus objetivos son medir el tamaño no funcional del software
que el usuario solicita y recibe, y medir el desarrollo de software y su mantenimiento
basado en los requisitos no funcionales [5].
En el año 2009 se lanzó la primera versión borrador del Manual de Practicas de
Evaluación SNAP del Grupo Internacional de Usuarios de Puntos de Función (IFPUG).
La primera versión BETA 0.1 fue liberada en el año 2010 con el propósito de que la
industria del software la revisara en forma general. Para el 2011 se lanzó al público
la versión 1.0 de SNAP APM donde se definió los conceptos, procesos y reglas para
evaluar los requisitos de software no funcionales [5].
SNAP se compone de cuatro categorías y catorce subcategorías para medir los
requisitos no funcionales, tal y como se muestra en la Tabla 1. El proceso permite
medir los NFR mediante una serie de preguntas y medidas agrupas en
subcategorías. Cada subcategoría tiene un tamaño y el tamaño de un requerimiento
es la suma de los tamaños de sus subcategorías [5].
El procedimiento de medición de SNAP consta de 7 pasos [5]:
1. Reunir la documentación disponible
2. Determinar el propósito, el alcance, el límite y la partición de la evaluación
3. Identificar los requerimientos no funcionales
4. Asociar requerimientos no funcionales con subcategorías e identificar la SCU
5. Determinar el tamaño de SNAP para cada subcategoría
10
6. Calcular el tamaño no funcional (Puntos SNAP).
7. Documentar y reportar.
Tabla 1: Lista de categorías y subcategorías de SNAP (adaptada de [5]).
1. OPERACIONES CON DATOS 3. ENTORNO TÉCNICO
1.1. Validación de la Entrada de Datos 3.1. Múltiples plataformas
1.2. Operaciones Lógicas y Matemáticas 3.2. Tecnología de la base de datos
1.3. Formateo de Datos 3.3. Procesos Batch
1.4. Movimientos internos de datos
1.5. Aportando valor añadido a los usuarios
a través de parametrización
2. DISEÑO DE INTERFAZ 4. ARQUITECTURA
2.1. Interfaces de Usuario 4.1. Software basado en componentes
2.2. Métodos de Ayuda 4.2. Múltiples interfaces de
2.3. Múltiples métodos de entrada entrada/salida
2.4. Múltiples métodos de salida
El primer paso consiste en la recolección de la documentación para respaldar el
proceso de evaluación; estos documentos deben describir los requerimientos no
funcionales que forman parte del software que se está midiendo. Se debe obtener
documentación suficiente para realizar la evaluación o tener acceso a expertos en
la materia que puedan proporcionar información adicional para abordar cualquier
punto que faltante en la documentación. Los requisitos no funcionales pueden ser
implícitos o explícitos. Cuando no se especifican explícitamente, se debe asegurar
que las expectativas o acuerdos se comprendan y documenten [5].
El segundo paso se debe identificar el propósito de la evaluación que se define
como el tipo y motivo de la valoración; por ejemplo, estimar el esfuerzo de NFR y
mostrar el tamaño no funcional entregado por una mejora. En el alcance se
especifica el conjunto de NFR incluidos en la valoración. Se continua con el límite, el
cual se describe como una interfaz conceptual entre el software bajo estudio y sus
usuarios [5].
Entonces, el límite detalla lo que es externo a la aplicación, actúa como una
“membrana” a través de la cual los datos se procesan por transacciones,
11
introduciéndolos o sacándolos de la aplicación, es dependiente de la visión de
negocio externa de los usuarios de la aplicación y es independiente de
consideraciones no funcionales y/o de implementación [5].
Por último, se identifica la partición, una partición es un conjunto de funciones
dentro del límite de una aplicación que comparten criterios y datos de valoración
homogéneos. Una partición requiere tener asociado un esfuerzo de desarrollo, que
puede no ser reflejado cuando se mide el aspecto funcional de un proyecto o
producto de software, utilizando FPA [5].
Es importante asegurarse de capturar todos los requerimientos no funcionales tanto
implícitos como explícitos y reconocer cuáles de ellos no forman parte de la
documentación del proyecto. Un requerimiento puede contener aspectos tanto
funcionales como no funcionales; por lo tanto, el requisito tendrá un tamaño un
tamaño funcional, medido en Puntos de Función, y un tamaño SNAP, medido en
Puntos SNAP [5].
Para el cuarto la asociación de los requerimientos no funcionales con categorías y
subcategorías se desarrolla de la siguiente manera: Se identifica el requerimiento
no funcional bajo el alcance (por ejemplo, requisitos para la seguridad de los datos;
requisitos para mejorar el desempeño) Se analiza el diseño y se identifica qué
subcategorías se utilizan para cumplir con el requisito. Cada subcategoría tiene su
propia definición de SCU, se debe mapear y definir el SCU según la naturaleza de la
subcategoría que se analice [5].
En el quinto paso se determina los puntos SNAP (SNAP Points o SP por sus siglas en
inglés) de cada SCU, se evalúa la complejidad de la SCU utilizando los parámetros
de complejidad definidos para la subcategoría; y posteriormente, se determina los
SP de cada SCU; los SP son la suma del tamaño de todas las SCU identificadas en
cada subcategoría. Una vez que se han evaluado todos los parámetros de
complejidad, se calcula el tamaño de cada SCU y se suman los SP de todas las SCU
para obtener los puntos SNAP calculados para la subcategoría.
12
En el sexto paso se calcula el tamaño no funcional. Los SP son el tamaño final no
funcional obtenido al combinar o sumar todos los valores de las categorías. Cuando
se identifica más de una subcategoría, el tamaño general no funcional se obtendrá
sumando el tamaño de cada subcategoría dentro del límite de la aplicación del
producto de software que se está evaluando [5].
Por último, en el séptimo paso los resultados de la evaluación se documentan de la
siguiente manera: El propósito y tipo de conteo, el alcance de conteo y el límite de la
solicitud, la fecha del recuento, una lista de todas las SCU incluido su tipo y
complejidad y el número de puntos SNAP asignados, el resultado del recuento y
cualquier suposición hecha y problemas resueltos.
La documentación también puede incluir la identificación de la documentación
fuente en la que se basó el recuento, la identificación de los participantes, sus roles
y calificaciones para cada SCU y el número de puntos SNAP por cada subcategoría
[5].
La categoría 2 Diseño del Interfaz de SNAP se refiere a la experiencia del usuario
final. En esta categoría se evalúa el diseño de los procesos de Interfaz de Usuario y
los métodos que permiten al usuario interactuar con la interfaz de la aplicación [5].
La subcategoría 2.1 interfaces de usuario hace referencia a los elementos gráficos
independientes, añadidos o configurados en la interfaz de usuario que no modifican
la funcionalidad del sistema y que son identificables por el usuario. Esto a su vez
afectan a las características no funcionales como la usabilidad, facilidad de
aprendizaje, atractivo y accesibilidad [5].
El Elemento UI (User Interface – Interfaz de Usuario) es un elemento estructural
único identificable por el usuario que forma parte de la interfaz de usuario.
Compuesto por elementos como ventanas (que puede ser contenedor hijo de texto
o de mensajes), menús, iconos, controles (cursos del ratón, cajas de texto, botón,
13
hipervínculo, lista desplegable, lista, combo, casilla de verificación, botones de tipo
radios, botón de ciclo, cuadrícula de datos), pestañas, elementos de interacción
como un cursor y, por último, las etiquetas [5].
Cada elemento UI está asociado a ciertas propiedades que definen su
comportamiento y apariencia dentro de la interfaz de usuario. Por ejemplo, un botón
puede tener propiedades como ButttonHighligth, BackgroundColor entre otros. En el
enlace (www.w3.org/TR/CSS2/ui.html) se presenta una lista de las posibles
propiedades que puede tener un elemento [5].
Un Proceso Elemental es la unidad de actividad más pequeña y significativa para el
o los usuarios. El proceso elemental debe ser una transacción completa y debe
dejar el negocio de la aplicación que se está midiendo en un estado consistente [5].
SCU (SNAP Counting Units – Unidades de conteo SNAP) es un componente o una
actividad sobre la que se evalúa la complejidad y el tamaño a medir. Los SCU son
únicos para cada subcategoría y están determinadas por la naturaleza de la
subcategoría, por ejemplo, un SCU puede ser un componente, un proceso o una
actividad identificada. El conteo se realiza por separado para cada SCU. En la
categoría 2.1 de SNAP, los SCU son un conjunto de pantallas definidas por el
proceso elemental [5].
14
Cálculo de puntos SNAP subcategoría 2.1. Interfaces de Usuario
Los parámetros de complejidad de la subcategoría 2.1 Interfaces de Usuario se
componen por la suma del número de propiedades únicas configuradas para cada
elemento y el número de Elementos UI únicos impactados. Para realizar el cálculo
de los puntos SNAP, se identifica la complejidad en función del número de
propiedades del conjunto de elementos UI y se calcula el tamaño como el producto
del factor constante entre el número de elementos de IU únicos [5], tal y como se
muestra en la Tabla 2.
Tabla 2: Tamaño de SNAP para interfaces de usuario. Adaptada de [5].
Tipo de Complejidad UI
Baja Media Alta
# de propiedades
agregadas o <10 10-15 16+
configuradas
SP = 2 * # elementos UI 3 * # elementos UI 4 * # elementos UI
únicos únicos únicos
Esta subcategoría presenta dos reglas, la primera regla consiste en si el proceso
para agregar o cambiar la UI fue contada usando FP, entonces no duplica el conteo
en la evaluación contando el mismo proceso con SNAP. Cambiar el contenido y la
apariencia de un elemento de la GUI debe evaluarse como no funcional. Cabe
mencionar que los cambios estéticos en la pantalla de la interfaz de usuario, las
páginas de la interfaz de usuario estática o dinámica, la reorganización de la
pantalla y los informes impresos deben evaluarse en la subcategoría Interfaces de
Usuario [5].
La segunda regla establece que los conjuntos de pantallas dentro de un proceso se
contarán como SCU [5].
15
Los elementos UI agregados pueden ser texto, sonido, imagen, logotipos, color,
teclas, controles, navegación, animación o habilitación/deshabilitación (cuando
esta no es funcional) [5].
La siguiente descripción ejemplifica el uso de la medición de tamaño.
Algunos textos en las pantallas de usuarios están codificados de tal manera que no
pueden ser alterados sin modificar el código. Por ejemplo, debido a una nueva
política de la empresa, se requiere remplazar la palabra “cliente” por las palabras
“socio comercial”. En el análisis se encontró que la palabra "cliente" debe
reemplazarse en los elementos de la IU que se mencionan a continuación; no
obstante, se debe tomar en cuenta que SNAP cuenta el número de elementos de IU
únicos, no es necesario que se estime el número de apariciones de cada elemento
de IU único [5].
• SCU 1: Adquirir un nuevo socio comercial:
Encabezado, etiquetas, botón de opción, lista desplegable
• SCU 2: Modifique los detalles de un socio comercial:
Encabezado, etiquetas
• SCU 3: Enviar mensaje a un socio comercial:
Encabezado, etiquetas
• SCU 4: Cesar los servicios a un socio comercial:
Encabezado, etiquetas
Cambiar el texto en estos Elementos UI se considera una propiedad, por lo que la
complejidad del tipo de interfaz de usuario es baja.
SP = 2*# Elementos UI únicos por cada SCU:
SP = 2*(4 + 2 + 2 + 2) = 20
16
2.4 COSMIC
El método COSMIC es el resultado de la búsqueda del grupo internacional de
expertos en medición de tamaño funcional de software y el Consorcio Internacional
de Medición de Software Común (COSMIC). En conjunto desarrollaron una unidad
de medición capaz de aplicarse en el mayor número posible de dominios de
software, en especial con los tipos de proyectos donde el método IFPUG era
bastante difícil de aplicar como en aplicaciones en tiempo real [11].
El método COSMIC define los principios, reglas y el proceso para medir un tamaño
funcional estándar de una pieza de software. El tamaño de COSMIC generalmente
se determina a partir de los requisitos, pero también se puede contar a partir de
otros artefactos de software como diseños o sistemas instalados, entre otros [12].
2.5 TECNOLOGÍAS WEB
Para la realización de este trabajo se implementó varias tecnologías web para el
desarrollo de la herramienta prototipo y los sitios web bajo estudio. Se detallan a
continuación:
Se ha utilizado JavaScript que es un lenguaje de programación interpretado y
orientado a objetos. Es conocido como un lenguaje de scripting para páginas web.
Sin embargo, se utiliza en entornos no relacionados con el navegador como Apache
CouchDB, Adobe Acrobat y Node.js, entre otros [13].
17
Además, se implementó Jquery, la cual es una librería pequeña de JavaScript
utilizada para la manipulación de documentos HTML, manejo de eventos,
animaciones y Ajax que funciona en una multitud de navegadores [14].
Para la creación de la interfaz gráfica de usuario del prototipo de herramienta se
usó HTML (un lenguaje de marcado), esto quiere decir que funciona complemente a
través del uso de etiquetas. Cada etiqueta se utiliza para definir diferentes partes
del documento HTML, así como estilos, enlaces, imágenes, elementos incrustados,
formularios, entre otros [15].
Con el fin de estilizar la interfaz gráfica del prototipo de herramienta, se aplicó los
estilos mediante las hojas de estilo en cascada (CSS por sus siglas en inglés). CSS
es un lenguaje declarativo utilizado para definir la presentación o estética de
documentos estructurados como HTML. Mediante el uso de reglas de estilo un
desarrollador web define la presentación de los elementos de la interfaz gráfica de
usuario por ejemplo hipervínculos HTML. Cada regla de estilo incluye un selector
CSS que define qué elementos poseen estilo, por ejemplo “a” selecciona todos los
hipervínculos HTML. Del mismo modo, al definir declaraciones de estilo como borde-
color: red en la regla de estilo se logra establecer la presentación deseada. Cada
declaración de estilo asigna valores de estilo (red) a una propiedad de estilo (borde-
color) [16].
Los proyectos web que se midieron con la subcategoría 2.1 de SNAP se
desarrollaron con Drupal. Drupal es un CMS (Sistema Gestor de Contenido, por sus
siglas en inglés) gratuito y de código abierto escrito en PHP y distribuido bajo la
Licencia Pública General de GNU. Drupal fue diseñado para ser mejorado con
nuevas características y comportamientos personalizados al descargar y habilitar
módulos complementarios (conocidos como módulos contribuidos o "contrib").
Dichos módulos amplían la funcionalidad del núcleo de Drupal, cubriendo un amplio
espectro de capacidades, incluido el comercio electrónico, las redes sociales, la
integración con aplicaciones de terceros, multimedia, entre otros [17].
18
Drupal utiliza el concepto de temas compuestos por elementos destinados a
presentar la información al usuario final. La capa de tema es responsable por la
creación del HTML o JSON, XML etc, que el navegador web va a recibir. Drupal
permite varias formas de personalizar y anular la apariencia de su sitio web. La
forma más sencilla es utilizar una hoja de estilo en cascada (CSS) para anular las
clases e IDs integradas de Drupal [18].
2.6 EXTENSIÓN
Las extensiones son pequeños programas de software que se usan para
personalizar la experiencia de navegación. Esto permite a los usuarios adaptar el
comportamiento y funcionalidad del navegador web a las necesidades individuales.
Se desarrollan usando tecnologías web como HTML, JavaScript y CSS. Una sola
extensión puede incluir múltiples componentes y una gama de funcionalidades,
siempre y cuando todo contribuya a un propósito común [19]. La herramienta
prototipo se desarrolló como una extensión para el navegador Google Chrome.
2.7 JIRA
JIRA es una herramienta en línea para la administración de tareas de proyectos de
software, en donde se aplican procesos de planificación, supervisión, informes y
lanzamientos de proyectos administrados utilizando metodologías agiles [20].
Desde este sistema se obtuvo la información de los requerimientos no funcionales
de cada proyecto web bajo estudio.
2.8 DRUPAL DESACOPLADO
Esto quiere decir qué Drupal usa otra tecnología aparte de las contenidas en sí
mismo por defecto para el desarrollo de la parte frontend o capa de presentación
(interfaz de usuario). Por ejemplo, la librería React se puede usar para crear un
tema o plantilla web que consuma los datos desde servicios expuestos por Drupal
[21].
19
Hay diferentes formas de desacoplar Drupal, entre ellas se encuentran “Drupal
progresivamente desacoplado”, “Drupal completamente desacoplado” y “sitios
estáticos totalmente desacoplados”.
Con “Drupal progresivamente desacoplado” JavaScript puede ser responsable nada
más de la renderización de un solo bloque o componente en una página o podría
encargarse de la renderización de todo lo existente dentro del cuerpo de la página
[21].
“Drupal completamente desacoplado” consiste en una separación total de entre la
capa de presentación y todos los demás aspectos del CMS. En este escenario el
CMS se convierte en un proveedor de datos y una aplicación JavaScript se hace
responsable de todo el renderizado y markup, comunicándose con Drupal a través
de servicios web [21].
Finalmente, los “sitios estáticos totalmente desacoplados” funcionan igual que la
arquitectura completamente desacoplada, con la diferencia que se centra en el
desarrollo de sitios estáticos por razones de rendimiento [21].
20
3. TRABAJO RELACIONADO
Aguiar y Buglione [22] mencionan que los modelos o herramientas para estimar
esfuerzo en el desarrollo de software disponibles en la industria, tales como
COCOMO II, SEER, SLIM y otros, tienen formas particulares y diferentes de tratar los
NFR. Esto muestra la falta de estándares para contar los NFR; y debido a esto, fue
que la IFPUG impulsó el desarrollo del método SNAP. A pesar de que dichos
modelos y herramientas manejan de algún modo los NFR, no se menciona si son
capaces de automatizar el proceso de conteo del tamaño NFR específicamente para
el desarrollo de la interfaz gráfica de usuario.
Ochodek y B. Ozgok [23] midieron el tamaño no funcional usando SNAP junto con
FPA para estimar el tamaño funcional de tres proyectos de software. Por medio de
un caso de estudio, se demostró que SNAP podría ayudar a mitigar algunas
deficiencias bien conocidas del método FPA. El estudio anteriormente mencionado
se enfocó en la aplicación de SNAP en un contexto específico. Es por esto, que para
este TFIA se desarrolló un prototipo de herramienta para ayudar a contar los puntos
SNAP para la subcategoría 2.1 interfaz de usuario (UI). En la sección del marco
teórico, se detalla en qué consisten las subcategorías de SNAP.
Hira y Boehm [24] evaluaron el uso de SNAP individualmente y en conjunto con FP
para medir las mejoras en el sistema UCC (Unified Code Count), el cual es una
herramienta de software mantenida por la Universidad del Sur de California. Se
determinó que SNAP condujo a estimaciones aceptables en proyectos que
modifican las funciones existentes. Sin embargo, SNAP no es una medida de
tamaño efectiva para proyectos que agregan nuevas funciones. El uso de FP y SNAP
mejoró las estimaciones de esfuerzo para los proyectos que agregaron nuevas
funciones, pero no mejoró ni empeoró las estimaciones para los proyectos que
modificaron las funciones existentes.
Según este estudio, SNAP puede mejorar las estimaciones de esfuerzo en
desarrollos de nuevas funciones. El estudio anterior, evidencia la mejora en las
21
estimaciones de los proyectos de software en los que se aplicó SNAP, lo que motiva
el desarrollo de un prototipo de herramienta que permita automatizar y facilitar el
conteo de la interfaz gráfica y; eventualmente, generar datos históricos de la
medida no funcional de los proyectos en puntos SNAP que ayudaran a calibrar las
futuras estimaciones.
Hira y Boehm [25] en su artículo COSMIC Function Points Evaluation for Software
Maintenance, el Consorcio Internacional de Medición de Software Común (COSMIC)
reconoció que el método COSMIC no dimensiona explícitamente el tamaño de
manipulaciones de datos (como operaciones matemáticas). Por su lado, IFPUG
también presenta este problema y para solventarlo creó el método SNAP.
La literatura refleja que se ha realizado un análisis que considera utilizar SNAP en
conjunto con el método COSMIC. En conclusión, a pesar de que SNAP no mejoró las
estimaciones de esfuerzo para los proyectos que agregaron nuevas funciones en su
estudio, el uso conjunto de puntos de función COSMIC (CFP) y SNAP condujo a
estimaciones de esfuerzo aceptables para proyectos que modifican la funcionalidad
existente. Además, en este estudio no es evidente el uso de alguna herramienta
que automatice el proceso de conteo de puntos SNAP.
Rao y Ben-Cnaan [26] mencionan las pautas a seguir para seleccionar y evaluar un
NFSM (método de tamaño no funcional), basado en las características funcionales
definidas por ISO/IEC 14143. Además, se evalúa el cumplimento de SNAP con
respecto a los requisitos de NFSM. Los autores del documento aseguran que optar
por el uso de SNAP es una buena práctica para medir los NFR. Considerando lo
anterior, el prototipo de herramienta podría ayudar a semiautomatizar el proceso de
conteo de NFR facilitando la implementación de un método que sigue las mejores
prácticas.
Mansoor y Ochodek [8] en búsqueda de la semiautomatización del conteo de
puntos SNAP, crearon una herramienta prototipo para medir el tamaño de los
22
requerimientos no funcionales relacionados con las interfaces de usuario de las
aplicaciones web. Para este estudio de investigación, se utilizó previamente la
herramienta prototipo desarrollada por Mansoor y Ochodek; sin embargo, no se
logró que funcionara correctamente. En el proceso de instalación se encontró varios
errores en el código, los cuales fueron reparados, pero aun así el prototipo no
retornó los valores esperados. Tomando todo esto en consideración, se descartó el
uso de su herramienta y se propuso desarrollar un nuevo prototipo para este TFIA
que sí funcione con las aplicaciones web seleccionadas y; por ende, pueda ser
evaluado.
Abran [27] propuso en su trabajo la siguiente pregunta ¿El diseño de la solución
propuesta como los puntos SNAP (SP) cumple con los criterios generalmente
aceptados para una medición cuantitativa sólida? Para responder a esta pregunta,
el artículo presenta un análisis de los fundamentos numéricos de IEEE 2430 y
muestra que tiene fallas desde una perspectiva de medición y no proporciona una
solución de ingeniería sólida para el problema del dimensionamiento NFR. Dado
esto, este artículo recomienda el retiro de IEEE 2430 y propone un enfoque
alternativo para el tamaño de los NFR (una medición del tamaño NFR alternativo
con propiedades numéricas sólidas, proporcionado por COSMIC Group). Sin
embargo, el desarrollo e implementación de la propuesta del prototipo de
herramienta no se ve afectado dado que aun puede brindar valor en lo que respecta
a la automatización del conteo de puntos SNAP.
23
4. METODOLOGÍA
Para lograr los objetivos propuestos se siguió una serie de pasos que se explican a
continuación (Ver Figura 1).
Figura 1: Pasos y procesos de la metodología.
Se seleccionó un conjunto de proyectos web desarrollados con Drupal y hospedados
en la plataforma Pantheon (WebOps platform), pertenecientes a la empresa de
desarrollo de software costarricense en estudio. Para la selección de los proyectos
se consideró que cada uno estuviera implementado en la versión 8 de Drupal, sin
ser una implementación desacoplada (esto quiere decir que el tema debe ser
creado de la forma Drupal, y no ser un tema o interfaz separada de Drupal que
puede ser desarrollada con otra tecnología frontend como React, por ejemplo).
24
Se creó una lista de requerimientos no funcionales de la interfaz de usuario de los
proyectos, basándose en las tareas creadas en el sistema JIRA (herramienta en
línea para la gestión operativa de proyectos) de la empresa para cada proyecto web
seleccionado; la lista está disponible en el Anexo 1.
Se logró identificar las tareas y se encontró que muchas de ellas carecían de
documentación exhaustiva. Este es un problema interno conocido en la empresa
relacionado al manejo de los proyectos, ya que por lo general las tareas carecen de
explicación, como mínimo se agrega una breve descripción en el título de dichas
tareas y se trata de aclarar las dudas durante una sesión inicial con el equipo de
desarrollo, en donde se hace una presentación del diseño que se desea
implementar en el sitio web, para los proyectos que se inician desde cero. Por esta
razón, los requerimientos no funcionales se obtuvieron de forma implícita, lo que
requirió la revisión de los archivos de diseño y algunas pequeñas llamadas con los
desarrolladores que trabajaron en dichos proyectos para confirmar que la
interpretación de tales requerimientos fuera la más correcta posible. Ver Anexo 1.
Se realizó un conteo manual de puntos SNAP para la categoría 2.1 interfaz gráfica
de usuario en cada proyecto web seleccionado (3 páginas por cada sitio web), con
el fin de obtener un conteo hecho por un experto de cada proyecto. Posteriormente,
se utilizó este valor para validar la exactitud del conteo realizado por el prototipo de
la herramienta.
Para la implementación y desarrollo del prototipo de herramienta, se siguió la
metodología Ciencias del Diseño basándose en el Modelo del Ciclo de Diseño
propuesto por Vaishnavi y Kuechler en el 2011 [28], tal y como se muestra en
Figura 2. Los puntos del modelo del ciclo de diseño que se siguieron son los
siguientes:
• “Conciencia del problema”: se desarrolló durante el primer paso de la
metodología de este trabajo y se consolidó el conocimiento base para
entender el problema actual.
25
• “Sugerir”: en este punto se propone una posible solución la cual es la
construcción de un prototipo de herramienta para automatizar el conteo de
puntos SNAP para la categoría 2.1 Interfaz Gráfica. Se procedió con el diseño
del prototipo, el cual consistió en conceptualizar los elementos necesarios
para poder contar de manera correcta los elementos de la interfaz gráfica
que el método SNAP toma en cuenta.
• “Desarrollo”: se implementó el prototipo de herramienta de forma iterativa
entre este punto y el siguiente “Evaluación” usando el lenguaje de
programación JavaScript, el cual es uno de los de mayor dominio por parte
del investigador. El código se trabajó con Git que es un software de control
de versiones. Durante este paso se implementaban las reglas de mapeo las
cuales se mejoraban o creaban nuevas en el proceso de “Evaluación”, estas
reglas se documentaron en un archivo de texto y una vez se afinaban en la
detección del o los elementos UI se agregaron al documento del presente
trabajo.
• “Evaluación”: se ejecutó la herramienta usando un SCU previamente contado
manualmente de un sitio de prueba, se validaba su exactitud y si se
detectaba algún error, se procedía al punto “Desarrollo” para su corrección.
En el paso anteriormente descrito, se dio la evaluación de las reglas de
mapeo; si era necesario modificar o idear una nueva regla de mapeo esta se
realizaba en este paso y se procedía nuevamente al paso de “Desarrollo”.
Los resultados del conteo se registraron en un documento de Excel en donde
se comparaba el conteo manual con el conteo realizado con el prototipo en
cada mejora o iteración; este documento se utilizó como un tipo de bitácora
que ayudo en el proceso de ajuste de las reglas de mapeo. Luego de que la
herramienta tuviera un comportamiento esperado (donde los resultados
fueran exactos comparando el conteo manual de prueba), se evaluaba en los
sitios seleccionados y se repetía el ciclo entre “Evaluación” y “Desarrollo”.
• “Conclusión”: cuando se terminó de afinar el prototipo de herramienta se
cuentan los sitios bajo estudio con dicho prototipo y se documentan e
26
interpretan los resultados generando el conocimiento tanto el conteo manual
y con el prototipo de herramienta como las reglas de mapeo.
Figura 2: Ciclo de Diseño por Vaishnavi and Kuechler 2011 (adaptada de [28]).
Seguidamente, se evaluó la exactitud de las estimaciones de puntos SNAP hechas
por la herramienta prototipo sobre el conjunto de proyectos web seleccionados,
midiendo tres páginas por cada proyecto web, para un total de 12 páginas
analizadas. Cada página fue seleccionada debido a que en la lista de
requerimientos no funcionales obtenidos en el segundo paso, están presentes los
NFR que corresponden a elementos presentes en dichas páginas, tales como
formularios, barras laterales, encabezados y pies de páginas que están
relacionados con el desarrollo de la interfaz gráfica. La misma puede ser contada
con la subcategoría 2.1 de SNAP. En la sección 7.5 Validación de la herramienta, se
profundiza las razones del por qué esta selección de páginas.
27
Se registró los resultados por medio de una hoja de cálculo en Excel, se tabularon
los resultados obtenidos (puntos SNAP) con el prototipo de herramienta y se
compararon con el conteo manual previamente realizado por cada página
seleccionada de cada proyecto web seleccionado.
La exactitud de los resultados se calculó utilizando la siguiente fórmula para
obtener el error relativo [29]:
?̅? − 𝑥𝑡
𝐸𝑟 = × 100%
𝑥𝑡
Donde ?̅? es el valor calculado o el promedio de los valores calculados medidos con
el prototipo de herramienta (puntos SNAP), y 𝑥𝑡 es el valor real (valor medido
manualmente en puntos SNAP). Un error relativo 𝐸𝑟 más próximo a 0 significa una
mayor exactitud, siendo el valor 0 una exactitud del 100% de la herramienta
prototipo comparado con el conteo manual del experto.
Los resultados obtenidos se interpretaron y documentaron. Adicionalmente, se
propusieron algunas mejoras y limitaciones.
28
5. REGLAS DE MAPEO
Se desarrolló un conjunto de reglas de conteo que mapean la metodología SNAP
para la interfaz gráfica con el fin de definir un método automatizado para contar
puntos SNAP. A continuación, se muestran los puntos a considerar de la
metodología SNAP y cómo estos se adaptaron en el prototipo de herramienta.
Lo primero a considerar es que SNAP define algunos elementos (UI) de la interfaz de
usuario, tales como ventanas, menús, iconos y otros incluidos en el manual de
SNAP. Por lo que, para el desarrollo del prototipo, se tuvo que identificar y
estandarizar cómo las etiquetas HTML representan estos elementos en un sitio
web. Como parte de este mapeo, se creó las siguientes reglas de conteo:
• R-1. La etiqueta HTML “X” que represente un elemento UI “Y” se contará
como un elemento UI de SNAP.
Esto quiere decir que, si existe una etiqueta HTML la misma se contará e
identificará como un elemento UI de Hipervínculo establecido en la metodología
SNAP.
• R-2. Las etiquetas HTML en su atributo type o role con el valor “X” se
contará como un elemento UI “Y” de SNAP que represente su función y
apariencia.
La regla anterior se aplica cuando en el código HTML hay elementos de tipo input.
En este caso no basta solo con identificar la etiqueta, también hay que validar el
tipo. Por ejemplo, la etiqueta se contará y representará como
un Botón según los elementos UI de SNAP.
• R-3. No se contará las etiquetas HTML input de tipo hidden, ni las etiquetas
HTML que no tengan texto ni los elementos que tenga como parte de la
29
clase la palabra “hidden”, ya que no es un elemento UI visible para el
usuario.
• R-4. Se contará como propiedades UI los estilos CSS que pertenezcan a cada
elemento “X” del DOM.
• R-5. Los atributos del elemento “X” en el DOM (type, name, class, id, href,
data, value, method, action y accept-charset) no se contarán como
propiedades UI, los demás se contarán por defecto.
• R-6. Si un elemento “X” de tipo imagen en el DOM tiene su atributo alt =
“logo” o su elemento padre tiene el atributo class = “logo”, se contará como
un elemento UI de tipo logo de SNAP.
• R7. El conjunto de etiquetas HTML