Puntos SNAP

SNAP es el acrónimo de "Software Non-functional Assessment Process" (Proceso de evaluación no funcional del software), una medida del tamaño del software no funcional. El método de dimensionamiento SNAP complementa la norma ISO/IEC 20926:2009, que define un método para el dimensionamiento del software funcional. SNAP es un producto del International Function Point Users Group ( IFPUG ) y se dimensiona utilizando el "Software Non-functional Assessment Process (SNAP) Assessment Practices Manual" (APM), ahora en la versión 2.4. Referencia "IEEE 2430-2019-IEEE Trial-Use Standard for Non-Functional Sizing Measurements", publicado el 19 de octubre de 2019 (Consulte también la norma ISO «Ingeniería de software: estándar de uso de prueba para mediciones de dimensionamiento no funcionales de software» ( https://www.iso.org/standard/81913.html ), publicada en octubre de 2021. Para obtener más información sobre SNAP, busque «IFPUG SNAP» en YouTube , donde encontrará una serie de vídeos que explican la metodología SNAP.

Una aplicación de software puede proporcionar dos aspectos de valor a sus usuarios. En este contexto, el primer aspecto es "qué" hará el software, específicamente, "un subconjunto de los requisitos del usuario. Requisitos que describen lo que el software debe hacer, en términos de tareas y servicios." (definición ISO/IEC 14143-1). Esto se puede definir como su "funcionalidad". Una métrica utilizada para medir el tamaño de una unidad de este software funcional es el "punto de función". Al utilizar una métrica de dimensionamiento funcional (FSM) estándar ISO como la del "Manual de prácticas de conteo de puntos de función" de IFPUG, ^{[ 1 ]} (FSM ISO/IEC 20926:2009), ^{[ 2 ]} un especialista en conteo de puntos de función puede examinar la parte de los requisitos funcionales del usuario de la aplicación de software y medir su tamaño funcional en unidades de puntos de función.

Para obtener más detalles sobre la métrica de puntos de función y otras métricas de dimensionamiento de software funcional de otras organizaciones , consulte la bibliografía, el artículo de Wikipedia " punto de función " y numerosas referencias en la literatura.

Un requisito de usuario de software también puede especificar "cómo" lo hará el software, específicamente "Un requisito de software que describe no lo que hará el software sino cómo lo hará". (Definición ISO/IEC/IEEE 24765:2010) Este tipo de software es definido por IFPUG como "no funcional". El tamaño del software correspondiente se mide con SNAP. El APM de IFPUG ^{[ 3 ]} detalla cómo dimensionar el software no funcional de la aplicación. Los aspectos no funcionales se definen y clasifican en ISO/IEC 25010:2011, "Ingeniería de sistemas y software - Requisitos y evaluación de la calidad de sistemas y software (SQuaRE) - Modelos de calidad de sistemas y software". ^{[ 4 ]}

El tamaño funcional del software, junto con el tamaño no funcional, debe utilizarse para medir el tamaño total de los proyectos de software. Ambos tamaños deben emplearse para evaluar el rendimiento del proyecto, establecer parámetros de referencia y estimar el costo y la duración de los proyectos.

De forma similar a la cuantificación de puntos de función, una unidad de no funcionalidad es el "punto SNAP". El tamaño del software, derivado de la cuantificación de la parte no funcional de una aplicación, se puede medir mediante el procedimiento del APM. Al igual que con los puntos de función, mediante el APM de IFPUG, un especialista en conteo de puntos SNAP puede examinar la aplicación de software y medir el tamaño de su no funcionalidad en unidades de puntos SNAP. Asimismo, como ocurre con los puntos de función, el número de puntos SNAP en una aplicación se correlaciona con el esfuerzo de trabajo necesario para desarrollar la parte no funcional del software de dicha aplicación. La investigación original que detalla esta correlación se encuentra en CrossTalk The Journal of Defense Software Engineering , en el artículo "A New Software Metric to Complement Function Points The Software Non-functional Assessment Process (SNAP)". ^{[ 5 ]}

Cada aspecto del software (tanto el funcional como el no funcional) requiere un esfuerzo de trabajo para su desarrollo, que es proporcional a su tamaño. Las organizaciones de desarrollo de software pueden utilizar las correlaciones entre los puntos funcionales y su esfuerzo de trabajo, y entre los puntos SNAP y su esfuerzo de trabajo, para ayudar a pronosticar sus costos y cronogramas de desarrollo de software y para auditar proyectos para determinar qué tan bien se gastó el financiamiento y se gestionaron los cronogramas.

SNAP reconoce cuatro categorías y 14 subcategorías de requisitos de usuario no funcionales. Estas se muestran en la siguiente tabla de APM.

1. Operaciones de datos

1.1. Validaciones de entrada de datos       1.2. Operaciones lógicas y matemáticas       1.3. Formato de datos       1.4. Movimientos internos de datos       1.5. Generación de valor añadido para los usuarios mediante la configuración de datos.      

2. Diseño de interfaz

2.1. Interfaces de usuario       2.2. Métodos de ayuda       2.3. Métodos de entrada múltiples       2.4. Múltiples formatos de salida      

3. Entorno técnico

3.1. Plataforma múltiple       3.2. Tecnología de bases de datos       3.3. Procesos por lotes      

4. Arquitectura

4.1. Software basado en componentes       4.2. Múltiples interfaces de entrada/salida      

Por ejemplo, el desarrollo de software para modificar el tamaño de los campos de datos en una tabla no representa cambios en la funcionalidad según los métodos de IFPUG. Sin embargo, este desarrollo requiere esfuerzo. El formato de datos se considera no funcional y se contabiliza en la subcategoría 1.3 de SNAP.

Los métodos de ayuda (subcategoría 2.2) generalmente se consideran no funcionales. A diferencia del proceso de punto de función, que requiere que los datos atraviesen los límites de la aplicación y se almacenen en un archivo lógico interno, los datos de ayuda pueden codificarse para residir internamente como parte del desarrollo de la aplicación y ser accedidos por el usuario. Este acceso puede abarcar desde ayuda emergente sobre un icono en la pantalla hasta el acceso a parte de un manual de operaciones de la aplicación almacenado internamente. Dado que los datos no se procesan propiamente dicho, la ayuda generalmente se considera no funcional.

Los puntos de función y los puntos SNAP miden dos aspectos diferentes del dimensionamiento del software y, por lo tanto, no se suman. Por ejemplo, una aplicación de 500 puntos de función y 300 puntos SNAP no puede considerarse del tamaño 800 de alguna métrica; los puntos de función y los puntos SNAP están diseñados para ser ortogonales. Para obtener información más detallada sobre la relación entre funcionalidad y no funcionalidad, consulte el documento «Glosario de términos para requisitos no funcionales y requisitos de proyecto utilizados en la medición , evaluación comparativa y estimación del rendimiento de proyectos de software». ^{[ 6 ]}

SNAP ofrece a los usuarios y a los equipos de desarrollo de software muchas ventajas adicionales al simple uso de puntos de función. A continuación, se muestran seis de muchos ejemplos.

• Medir el tamaño del software no funcional mejora la estimación del esfuerzo de trabajo en el desarrollo de software basándose únicamente en el dimensionamiento de los requisitos funcionales del usuario.
• Mide el tamaño de los algoritmos, utilizando la subcategoría 1.2.
• Esta mejora en la estimación del esfuerzo laboral también debería conducir a mejores estimaciones de la planificación, la asignación de recursos y los riesgos.
• Incluir el tamaño de SNAP mejora la estimación del esfuerzo necesario para mantener el software después de su implementación.
• Los índices de productividad de los equipos de proyecto se pueden determinar con mayor precisión porque se incluyen más factores en la medición de su rendimiento laboral.
• Incluir tanto productos de trabajo funcionales como no funcionales demuestra mejor el valor entregado al usuario.

Además, algunos esfuerzos de desarrollo de software podrían considerarse con cero puntos de función. Por ejemplo, un sprint de mantenimiento de software ágil podría consistir únicamente en modificar la longitud de los campos de datos en las tablas. Esto se consideraría con cero puntos de función por ser una tarea no funcional; sin embargo, este trabajo se contabilizaría en SNAP. SNAP resuelve, al menos parcialmente, el problema de los "cero puntos de función".

La prueba beta de SNAP realizada en 2012 se llevó a cabo con 48 aplicaciones. Se espera que futuras investigaciones mejoren la calibración de los factores de ponderación de las subcategorías para obtener una correlación estadística aún más sólida. Se recomienda que los resultados de futuras investigaciones se presenten al Comité de Normas de Dimensionamiento No Funcional (NFSSC) de IFPUG para su revisión.

• IFPUG

Buglione, Luigi y Santillo, Luca, “NFR: L”Altra Meta Della Mela,” Newsletter, Gruppo Utenti Function Point Italia Italian Software Metrics Association, www.gufpi-isma.org, diciembre de 2011.

Grupo Internacional de Usuarios de Puntos de Función, “Cómo funcionan juntos los Puntos de Función y SNAP”, MetricViews, www.ifpug.org, Princeton Junction, NJ, 08550, EE. UU., agosto de 2015.

Jones, Capers, “Guía para la selección de medidas y métricas de software”, CRC Press, Boca Raton, FL, 33487, EE. UU., 2017.

Jones, Capers, “Cuantificación de las perspectivas globales y de la industria del software”, CRC Press, Boca Raton, FL, 33487, EE. UU. 2018.

• ifpug.org