Las dos preguntas anteriores son clásicas de cualquier “Agilista”, sobre todo ante la duda de usar unidades de dimensionamiento CFP en lugar de USP, sobre todo ante el titubeo de si COSMIC es compatible con los desarrollos ágiles.

Teóricamente un número expresado en USP se supone que es una medida del tamaño de una historia de usuario, sin embargo, un story point tiene distintas interpretaciones, puede referirse a tamaño, tamaño y complejidad, esfuerzo y hasta duración, por lo tanto es completamente subjetiva, ya que depende de lo que el sujeto interprete o quiera interpretar, de hecho es por esto que solo funciona para comparar con un mismo equipo dónde todos entiende lo mismo, aunque no sirve para realizar comparaciones con otros equipos o para dar información a los stakeholders, al no representar algo estandarizado.

Derivado de lo anterior, tienen aplicación cuándo se considere como una unidad, acordada por “cada equipo ágil” para sus propios fines de ayudar a estimar y controlar el progreso del proyecto; claro siempre y cuando el equipo permanezca invariable en todas las iteraciones de un proyecto o incluso para varios proyectos; bajo estos supuestos (no reales ya que hablamos de personas que producen variabilidad en los equipos) bien “puede” ser una medida muy poco consistente pero ampliamente utilizada, por no conocer mejores alternativas.

En otras palabras, un USP es la medida mediante la cual un equipo evalúa la complejidad, el tamaño, el nivel de incertidumbre y el riesgo de realizar una historia en base a las destrezas, conocimiento y la información actual que poseen los miembros que conforman ese equipo, entendiendo que esfuerzo no es igual a tiempo; y mucha atención tamaño y complejidad no son lo mismo.

Debido a la evaluación personal de estas dimensiones, una misma historia puede ser 1 punto para una persona y 8 para otra; un equipo experto trabajando mucho tiempo sobre el mismo módulo puede estimar una historia con un valor relativo menor que otro que nunca ha trabajado en ese módulo, y esto está bien; sin embargo, lo que nos deja concluir es que los USP NO permiten realizar comparaciones objetivas para establecer acuerdos sin importar el tiempo de resolución.

Lo anterior es fácil de explicar porque las USP NO se encuentran en una escala de medición objetiva y estandarizada, por lo tanto, cada equipo ágil tiende a tener su “propia escala de medición única” y por tanto las USP son inconsistentes porque no son ni básicas (estándares) ni transversales (servir a toda la cadena de valor dado que significan lo mismo para todos) ni trascendentes (porque permiten comparaciones no importando el tiempo en el que sucedan).

Usar USP es lo mismo que palmos (medida de longitud, que es aproximadamente la distancia que hay desde el extremo del pulgar de una mano abierta y extendida hasta la yema del dedo meñique) de personas distintas, para medir el perímetro de un terreno que se va a cercar; evidentemente tendremos inconsistencia porque el perímetro será diferente para cada persona porque sus manos son diferentes.

Por el contrario, el método COSMIC es una métrica básica estandarizada internacionalmente para medir un ‘tamaño funcional’) es decir, un tamaño basado solo en lo que se requiere que haga el software, en unidades de Puntos de Función COSMIC (CFP), es 100% objetivo y repetible. Por cierto, el tamaño funcional es la única medida estandarizada sobre una característica del software.

El uso del método COSMIC en proyectos ágiles dará como resultado medidas de tamaño de software que se pueden comparar entre proyectos en cualquier nivel en cualquier tiempo y por cualquier participante en la cadena de valor (transversal y trascendente), desde una sola historia de usuario y hasta el tamaño de todo el software entregado.

El método COSMIC también es extremadamente fácil de aplicar para medir una historia de usuario, que normalmente corresponde a uno o muy pocos “procesos funcionales”, en terminología COSMIC [1].

Los conceptos del método COSMIC encajan perfectamente con los de los métodos ágiles. Medir un tamaño en CFP no debería requerir más esfuerzo que en unidades de USP. Además, el proceso de medición proporciona un control de calidad de la historia del usuario al ayudar a detectar ambigüedades y omisiones.

Registrando el esfuerzo en unidades de horas de trabajo (vistas como tiempo) y estableciendo “velocidad” en unidades de CFP / hora de trabajo (en lugar de que USP / iteración), todas las prácticas ágiles habituales se pueden realizar sin ningún problema usando unidades CFP.

En conclusión, COSMIC no solo es compatible con metodologías ágiles, sino que aporta un enorme valor al ser una métrica básica, transversal y trascendente que dará seguridad, consistencia y repetibilidad a las mediciones de los proyectos ágiles, sin requerir ningún tiempo adicional y por tanto siguiendo la filosofía de los desarrollos ágiles.

La plataforma tecnológica MENSURA® desarrollada por SPINGERE; permite tanto la medición como la aproximación de las historias de usuario generadas en las metodologías ágiles, siendo de esta manera una herramienta que le proporciona a los desarrollos ágiles una agilidad++. Para más información consultar https://mensura.com.mx/.

[1] COSMIC Functional Size Measurement Method, “Guideline for the use of COSMIC FSM to manage Agile projects”. Version 1.0, September 2011.

The post Por qué COSMIC es totalmente compatible con Metodologías Ágiles y mucho mejor que usar “User Story Points” first appeared on Spingere.

Las anteriores son interrogantes que están presentes siempre en cualquier proyecto de desarrollo de software ya que necesariamente un proyecto de desarrollo tiene requisitos funcionales de usuario (FUR) y requisitos no funcionales (NFR); la proporción varía dependiendo del tipo de proyecto; sin embargo, lo que es claro al inicio del proyecto, es que necesitamos estimar un proyecto de desarrollo de software de manera integral, considerando ambos tipos de requisitos.

Primero expondremos como se definen formalmente los FUR y los NFR:

Los requisitos funcionales del usuario (FUR) pueden definirse como “lo que debe hacer el software” y afectan claramente al tamaño del software, lo que a su vez afecta el esfuerzo y/o costo del proyecto. Estos se pueden medir con estándares de medición de tamaño funcional como COSMIC.

Los requisitos no funcionales (NFR) que a veces se definen como “¿cómo debe hacerlo el software?”, no está claro de inmediato si el NFR afecta o no al tamaño del software; lo que es cierto inminentemente es que afectan el esfuerzo y/o costo del proyecto.

Normalmente para la parte de los FUR tenemos más claro como estimarlos a partir de su dimensionamiento del tamaño funcional usando COSMIC y posteriormente ingresando este tamaño a un modelo de estimación que nos permita estimar esfuerzo y/o costo (consultar la entrada de blog titulada “Modelos de estimación de esfuerzo usando el tamaño funcional COSMIC”).

Sin embargo, para el tema de los NFR, sabemos que no se pueden medir con COSMIC porque son requisitos que no tienen funcionalidad; sin embargo, sabemos que impactan el esfuerzo y/o costo de cualquier proyecto de desarrollo de software. Ejemplos de este tipo de NFR son: el uso de un lenguaje de programación en particular por políticas del cliente, la necesidad de un tiempo de respuesta específico por parte del sistema, cierta calidad del software desarrollado, requisitos técnicos como la arquitectura, etc.

Es importante entender sobre un requisito que se establece inicialmente como un requisito No funcional (NFR) que “puede” evolucionar “total” o “parcialmente” a medida que un proyecto avanza hacia ser un FUR para software, el tamaño de esta funcionalidad “adicional” puede potencialmente medirse utilizando el método COSMIC en de la misma manera que cualquier otro requisito que siempre fue un requisito funcional para el software desde que se estableció por primera vez. Un ejemplo de este requisito que inicialmente podría ser NFR, sería el cumplir con cifrado en algunos datos antes de guardar en la base de datos, a medida que evoluciona el proyecto puede derivar en la necesidad de un algoritmo de encriptación específico lo cual lo transforma en un FUR.

Pero qué pasa con aquellos requisitos que si se mantienen como NFR; ante la necesidad de estimar estos NFR, normalmente las fábricas de software o los clientes que solicitan desarrollos se ven forzados a recurrir al juicio de experto ya sea para estimar o para validad una estimación de esfuerzo y/o costo referente a los NFR; sin embargo, esta forma de hacerlo trae todas las desventajas de imprecisión e inexactitud inherentes a dicha técnica.

En consecuencia, surge la pregunta si es posible estimar el esfuerzo y/o costo de los NFR de manera formal usando modelos matemáticos consistentes; la respuesta es afirmativa ya que por un lado se dispone de estándares que hacen una adecuada clasificación de los NFR como por ejemplo el “ISO/IEC 25010:2011 System/Software Product Quality model” [1], que agrupa en 9 categorías la forma en que se compone la calidad del producto de software. Para temas relacionados con requisitos del entorno del sistema, requisitos técnicos se pueden considerar los cuestionarios de ISBSG [2].

Existen otros estándares y manuales como: IEEE Std 830-1998: Software Requirements Specifications; IFPUG Software Non-functional Assessment Process (SNAP) Asse Release 2.2ssment Practices Manual; COSMIC Guideline on Non-Functional & Project Requirements. Version 1.0; European standard ECSS-E-ST-40C – Software general requirements, etc.

Los estándares y manuales citados anteriormente nos permiten disponer de un listado y una clasificación bastante bien definido de NFR que son comunes en los desarrollos de software; sin embargo, no son ni métodos ni modelos para estimar NFR. En particular SNAP está en proceso de ser aceptado como estándar ISO, sin embargo, está completamente mal, y presenta serios problemas en su fundamentación.

Sin embargo, existe un modelo denominado EPCU [3], que nos permite usando el formalismo de la lógica difusa, construir modelos de estimación a partir de la definición de un contexto que defina las variables consideradas para la estimación (entradas) y la variable de salida (variable estimada); de forma tal que se pueden construir modelos para evaluar y estimar de manera formal los NFR utilizando los estándares existentes como referencia.

Hoy en día los NFR NO se pueden medir (no existe una unidad de medida para ellos), pero se pueden evaluar, una manera de evaluarlos con un modelo que sea matemáticamente válido es aplicando EPCU, lo que permite generar una misma regla para evaluar y comparar resultados bajo circunstancias iguales.

La plataforma tecnológica MENSURA® desarrollada por SPINGERE; permite la habilitación de cualquier modelo EPCU (contexto) para poder estimar cualquier tipo de NFR; para más información consultar https://mensura.com.mx/.

[1] ISO/IEC 25010:2011, Systems and software engineering – Systems and software Quality Requirements and Evaluation (SquaRE) – System and software quality models.

[2] International Software Benchmarking Standards Group, ‘Data Collection Questionnaire’ 3.08, 2012.

[3] Design of A Fuzzy Logic Estimation Process for Software Projects: Estimation of Projects in a Context of Uncertainty EPCU Model by Francisco Valdés Souto (Aug 23, 2012), ISBN: 978-3-659-19774-1, Lap Lambert Pub.

Jorge Valeriano Assem y Francisco Valdés Souto.

The post Cómo estimar requisitos no funcionales (NFR) first appeared on Spingere.

¿Qué consideraciones se deben tener en cuenta para poder hacerlo?

¿Existen ecuaciones de convertibilidad que permitan hacer estas conversiones de manera rápida, confiable y precisa?

Las anteriores son interrogantes que seguramente nos hemos hecho quienes ya trabajamos con métricas estándares y entendemos los beneficios de utilizarlas, sin embargo por eta misma razón si disponemos de datos históricos de proyectos que hemos medidos en algún estándar y deseamos, por ejemplo, movernos de un estándar de medición de primera generación a un estándar de medición de segunda generación como COSMIC, seguramente deseamos conservar toda esta base de conocimiento pero en la nueva unidad, por lo cual nos hemos preguntado si es posible hacer estas conversiones de manera fácil y rápida sin tener que volver a medir todas las piezas de software con los inherentes costos de esfuerzo y dinero que eso representa.

Aquí comentaremos bajo que consideraciones es posible hacer estás conversiones y qué caminos documentados en la literatura existen en la actualidad.

Los métodos de medición de tamaño funcional (FSM) de “primera generación”, como los métodos IFPUG, MkII y Nesma, y el método COSMIC de “segunda generación”, todos expresan sus tamaños en una variedad de “puntos de función”. Sin embargo, las mediciones no son directamente comparables ya que cada método tiene sus propias reglas y procesos de medición y, por lo tanto, diferentes escalas de medición; es decir las unidades de “puntos de función” no son equivalentes entre sí, por lo tanto, una unidad (1 punto de función) representa diferente tamaño de funcionalidad entre los diferentes estándares.

Para que esto sea completamente claro pensemos en la unidad de medida “kilómetro” (km) en el sistema internacional de unidades y en la unidad de medida “milla” (mi) en el sistema anglosajón de unidades; si comparamos la longitud física de ambas unidades nos damos cuenta de que representan una longitud diferente, por lo tanto, no son equivalentes uno a uno, es decir 1 km ≠ 1 mi. Lo mismo sucede en el dimensionamiento del software, un punto de función en el estándar IFPUG es diferente a un punto de función en el estándar COSMIC, es decir 1 FP ≠ 1 CFP.

Afortunadamente, así como existen ecuaciones de conversión para pasar medidas en millas a medidas en kilómetros y viceversa; también es posible disponer de ecuaciones de conversión para pasar el tamaño funcional de un software medido por ejemplo en FP de IFPUG a CFP de COSMIC; sin embargo mientras que la ecuación de conversión de millas a kilómetros es única y completamente precisa para convertir de manera uno a uno cualquier dimensión en millas a kilómetros; en el caso del dimensionamiento del software las ecuaciones ni son únicas ni son 100% precisas.

Entender porque sucede esto es muy sencillo; en el caso de las unidades de medida kilómetro y milla el método para medir una longitud ya sea en millas o en kilómetros es el mismo, consistente en encontrar cuantas veces cabe la unidad de medida en lo que queremos medir; sin embargo, en el software los diferentes métodos de medición tienen reglas y procedimientos diferentes, es decir, cada uno mide cosas distintas.

Generalmente nos referiremos a los métodos IFPUG/Nesma, MkII y COSMIC en su forma estándar, es decir “Puntos de función no ajustados”, para que pueda ser comparable, ya que los “factores de ajuste de valor” de IFPUG y MkII no son reconocidos por los métodos Nesma o COSMIC.

Prácticamente todos los métodos son equivalentes en muchos de sus conceptos como el propósito de lo que se cuenta, el concepto de lo que es una aplicación, el alcance de lo que se cuenta, la frontera o los límites del software que se mide, los usuarios del software; sin embargo en lo que no son equivalentes es en la forma en que modelan y cuentan los datos que almacena y manipula el software; de ahí que no existan funciones de conversión precisas, una de esta diferencias fuertes es por ejemplo que IFPUG/Nesma si catalogan la complejidad de la funcionalidad y el peso que tiene en la contribución del tamaño; mientras que MkII y COSMIC no lo consideran debido a las desventajas que implican,  para darle solidez y consistencia al método de medición.

Tomando en cuenta las consideraciones anteriores, si bien no es posible la conversión de cualquier tamaño funcional en cualquier método de primera generación a tamaños funcionales en COSMIC, si se puede obtener una relación entre los tamaños medidos, por lo tanto, cuando hablamos de conversiones nos referimos a la correlación que existe entre las distintas unidades.

El objetivo principal por los que queríamos hacer estas conversiones es para determinar una fórmula de conversión de tamaños calculados con métodos de primera generación a tamaños COSMIC, considerando que disponemos de una base de datos histórica abundante en un estándar de primera generación y deseamos movernos a COSMIC sin perder la información histórica y disponiendo de elementos para recalibrar por ejemplo todos los métodos o herramientas de estimación que tengamos.

Bajo la consideración anterior lo que necesitamos es identificar una fórmula local para convertir las mediciones existentes de toda la base de datos histórica, en la literatura hay varios de estos estudios con sus respectivas fórmulas encontradas como se pueden consultar en los apéndices de la guía COSMIC sobre como convertir puntos de función de primera generación a tamaños COSMIC [1].

Un método general para poder derivar estas formulas locales sería el siguiente [1]:

1. Seleccionar grupos de proyectos con características similares, cada grupo debe ser tratado por separado ya que tendrá su propia ecuación de conversión, los pasos siguientes se aplican por separado para cada grupo
2. Seleccionar del grupo una muestra representativa de proyectos que estén medidos en ambos estándares (sino lo están se deberán medir), de manera que cada proyecto de la muestra disponga de su tamaño en los dos estándares
3. Calcular el coeficiente de determinación R² y verificar si es bueno, es decir que sea alto lo más cercano a “1”. Si la R² no es buena, entonces identificar puntos atípicos (outliers) y regresar al paso (a). Si la R² es buena seguir al paso (d)
4. Validar el nivel de precisión de la conversión respecto del tamaño real. Si el nivel de precisión no es adecuado no se puede usar la función de conversión.
5. Convertir los tamaños funcionales del resto de los proyectos que no formaron parte de la muestra, con lo cual tendremos todo el conjunto histórico de proyectos del conjunto identificado convertidos a unidades del estándar seleccionado.

Como es claro de las explicaciones anteriores es importante señalar, que las ecuaciones de conversión son diversas dependiendo de la muestra y de las características de los proyectos; por lo cual todas las ecuaciones de conversión deben ser calculadas localmente. Cabe señalar que, si se utiliza una ecuación de alguien más, es decir, no calibrada localmente, no se puede garantizar que funcione correctamente.

La plataforma tecnológica MENSURA® desarrollada por SPINGERE; liberará próximamente funcionalidades para poder hacer este tipo de conversiones entre los diferentes estándares de medición; para más información consultar https://mensura.com.mx/.

[1] COSMIC Functional Size Measurement Method, “Guideline on how to convert ‘First Generation’ Function Point sizes to COSMIC sizes”. Version 1.0, November 2016.

[2] Common Software Measurement International Consortium (COSMIC), Measurementt Manual for ISO 19761, Part 1, Part 2, Part 3. Version 5.0, May 2020.

The post Conversión de unidades de Tamaño Funcional entre los diferentes estándares first appeared on Spingere.

¿Cómo funciona el método de aproximación: “Aproximación mediante lógica difusa – el modelo EPCU”?  

¿Qué consideraciones se deben tener en cuenta si se decide emplear este método de aproximación?

¿Por qué es el ÚNICO método que NO necesita ser calibrado localmente?

La aproximación de tamaño funcional “Aproximación mediante lógica difusa – el modelo EPCU” fue introducida por primera vez en 2012, basada en una técnica utilizando un modelo de lógica difusa, denominado Estimación de Proyectos en un Contexto de Incertidumbre (modelo EPCU) para crear una técnica de dimensionamiento aproximado sin necesidad de utilizar datos históricos locales [1], ya que utiliza un mecanismo de inferencia basado en conceptos matemáticos de lógica difusa.

La lógica difusa es una rama de la inteligencia artificial que le permite a una computadora analizar información del mundo real en una escala entre lo falso y lo verdadero, manipula conceptos vagos, como «poco» o «mucho», y permite a los ingenieros construir dispositivos que juzgan la información difícil de definir.

El modelo general EPCU considera los siguientes pasos y mostrados gráficamente en la Figura 1:

1. Identificación de las variables de entrada
2. Especificación de la variable de salida
3. Generación de las reglas de inferencia
4. Fuzzificación
5. Evaluación de reglas de inferencia
6. Desfuzzificación

Específicamente el modelo EPCU ha sido aplicado para el problema específico de aproximar el tamaño funcional COSMIC de cualquier pieza de software en las primeras fases de un proyecto de desarrollo de software, donde la mayoría de los requisitos reales están escritos en lenguaje natural con alto entorno de incertidumbre, debido a que los requisitos no se conocen del todo en las etapas iniciales del proyecto.

La aplicación del modelo EPCU para aproximar el tamaño funcional COSMIC considera las siguientes dos variables lingüísticas de entrada para hacer el dimensionamiento:

1. Variable 1: el tamaño del proceso funcional (pequeño, promedio, grande, muy grande), y
2. Variable 2: el nivel de presencia de objetos de interés sobre los que los procesos funcionales mueven los datos (pocos, promedio, muchos).

Las dos variables lingüísticas de entrada citadas anteriormente clasifican primeramente los procesos funcionales y/o casos de uso y posteriormente hacen una asignación de valor, que es usada por el modelo EPCU para calcular el tamaño funcional aproximado.

La variable de salida está definida como un rango continuo de valores posibles con un límite superior o corte en 16.4 CFP para la aproximación por proceso funcional, límite fundamentado en la técnica de bandas de igual tamaño definida por Vogelezang [2]. En 2015, Valdés [3] implementa un modelo EPCU para Casos de Uso con un límite superior o corte en 44 CFP.

La investigación sobre la técnica de aproximación usando el modelo EPCU se ha centrado en dos niveles de documentación de la descripción de los requisitos funcionales del usuario:

1. Proceso funcional, y
2. Casos de uso.

Teniendo en cuenta los resultados de las investigaciones [4,5], se han identificado dos contextos distintos para cada nivel de documentación.

En la Tabla 1 y Tabla 2 se muestra un ejemplo de cómo ponderar requerimientos funcionales tanto por “Proceso funcional” como por “Caso de uso”, considerando las variables de entrada que usa el método, así como las asignaciones de valor correspondientes; de forma tal que para cada “caso de uso” o “proceso funcional” se hace una clasificación lingüística del tamaño que puede ser “pequeño”, “promedio”, “grande”, “muy grande” y en seguida asignar un valor numérico en el intervalo 0 a 5, con el cual se maneja la ambigüedad del requerimiento; como segundo paso se asigna a la siguiente variables la clasificación lingüística del nivel de presencia de los objetos de interés que puede ser “pocos”, “promedio”, “muchos” y en seguida se asigna de la misma manera un valor numérico en el intervalo 0 a 5.

Las ponderaciones anteriores representan las entradas necesarias para que el modelo EPCU realice la aproximación del tamaño funcional COSMIC de la pieza de software.

The post Método de aproximación COSMIC: “Aproximación mediante lógica difusa – el modelo EPCU” first appeared on Spingere.

Video realizado por Lee Fischman, clic aquí para seguirlo en Linkedin

El uso del método COSMIC en proyectos ágiles dará como resultado medidas de tamaño de software que se pueden comparar entre proyectos en cualquier nivel en cualquier tiempo y por cualquier participante en la cadena de valor (transversal y trascendente), desde una sola historia de usuario y hasta el tamaño de todo el software entregado.

El método COSMIC también es extremadamente fácil de aplicar para medir una historia de usuario, que normalmente corresponde a uno o muy pocos “procesos funcionales”, en terminología COSMIC.

Los conceptos del método COSMIC encajan perfectamente con los de los métodos ágiles. Medir un tamaño en CFP no debería requerir más esfuerzo que en unidades de USP. Además, el proceso de medición proporciona un control de calidad de la historia del usuario al ayudar a detectar ambigüedades y omisiones.

Registrando el esfuerzo en unidades de horas de trabajo (vistas como tiempo) y estableciendo “velocidad” en unidades de CFP / hora de trabajo (en lugar de que USP / iteración), todas las prácticas ágiles habituales se pueden realizar sin ningún problema usando unidades CFP.

En conclusión, COSMIC no solo es compatible con metodologías ágiles, sino que aporta un enorme valor al ser una métrica básica, transversal y trascendente que dará seguridad, consistencia y repetibilidad a las mediciones de los proyectos ágiles, sin requerir ningún tiempo adicional y por tanto siguiendo la filosofía de los desarrollos ágiles.

The post Introducción al Tamaño del Software COSMIC en Metodologías Ágiles first appeared on Spingere.