Surgimiento y Concepto de PSP

Después de la II Guerra mundial (1945), el enfoque en calidad de las organizaciones (incluidas las de desarrollo de software) estaba fundamentado en las pruebas. Fue hasta los 70’s y los 80’s que E. Deming y J.M. Juran convencieron a la industria de USA de enfocarse en la forma en que las personas realizan su trabajo. Sin embargo, la industria de software siguió fundamentando la calidad de las piezas de software en las pruebas.

El primer gran paso hacia el enfoque propuesto por Deming y Juran en el área de software se dio con las inspecciones de software propuestas por Michael Fangan (1976), otro gran paso se dio en 1987 con la introducción de Capability Maturity Model (CMM).

Es fundamental entender que el enfoque principal del CMM y hoy Capability Maturity Model Integration (CMMI) for Development es el sistema de administración, soporte y asistencia que se proporciona a los ingenieros de desarrollo de software [1], en otras palabras su enfoque es en mejorar la calidad de los desarrollos de software, a través de mejorar el desempeño de los procesos de una organización relacionados con la construcción de software. El SEI ha documentado efectos sustancialmente positivos por el uso de de CMM y CMMI.

En 1995 surge el Personal Software Process (PSP), que fue generado por Watts Humphrey y busca extender los beneficios de la mejora de procesos organizacionales a las personas que realizan el trabajo, el PSP se enfoca en las prácticas de trabajo individuales de los ingenieros de desarrollo de software (proceso personal), la estructura básica conceptual del PSP se muestra en la Figura 1.

Se inicia con un establecimiento de los requerimientos, después se realiza una planeación, posteriormente el diseño, la codificación, etc. ¿Qué es lo que lo hace diferente? Que durante todo el ciclo se generan “scripts de procesos” los cuales define los pasos para cada fase, también los “logs” y las formas de registro y almacenamiento de información, así como los estándares que deben de seguir los desarrolladores, es decir, son guías de lo que se debe de hacer en cada fase del ciclo definido (checklist).

Pero quizá lo más relevante de todo lo que se ha mencionado, y la fortaleza del PSP es el registro y almacenamiento de información ya que es lo que permite la mejora la productividad de las personas, mejora en los hábitos de programación, así como una detección temprana de defectos y riesgos.

Visto de otra manera lo que establece PSP es un “proceso de medición”, un proceso de medición es como lo que hace un área contable, cada día van identificando las facturas que se pagan, los pagos que se cobran, las pólizas, etc.

Si esto se hace cada mes, lo que algunas veces sucede, se acumulará más trabajo y la visibilidad de lo sucedido será con corte cada mes, por lo que si existiera algún riesgo durante el periodo, no se identificaría, hasta que se contabilizara todo.

Si esto lo extendemos a un año se acumula más trabajo y la posibilidad de poder tener visibilidad de lo sucedido cuando ya no se pueda hacer nada. Lo mismo sucede en el desarrollo de proyectos de software.

Estimación de Tamaño y Recursos con PSP (Método PROBE)

Dentro de la fase de planeación (Figura 2) se establece la estimación de tiempo y recursos, el método que propone PSP para realizar la estimación tanto de tamaño como de esfuerzo es el método PROBE (PROxy Based Estimating), el cual se basa en la utilización de objetos base -denominados proxys- para estimar el tamaño más probable de un producto.

Figura 1. Estructura Conceptual PSP

Como muchos mecanismos que utilizan elementos cuantitativos, establece que la precisión de los estimados depende del detalle de conocimiento sobre los requerimientos del trabajo a realizar, por eso incluye una etapa de diseño conceptual que se toma como base para estimar tanto el tamaño del producto como los recursos, considerando la siguiente suposición: “La correlación entre el tamaño del programa y el tiempo de desarrollo es ligeramente moderada entre equipos de ingenieros/desarrolladores y organizaciones. Sin embargo, de forma individual es generalmente alta”. [1]

Para realizar la estimación de tiempo, un desarrollador determina los tipos de objeto requeridos para desarrollar una pieza de software, con base en datos históricos de objetos similares – el método PROBE establece que se requieren datos de al menos tres proyectos- se determina el tamaño (LOC) más probable del tipo de objeto de acuerdo a distintos rangos, con los tamaños estimados de los objetos a desarrollar y utilizando una regresión lineal, se determina la cantidad de código que se planea desarrollar.

Reflexión: Hasta aquí todo suena bien, sin embargo, en la documentación PSP [1] se menciona una suposición que si bien cuando se creó PSP pudo hacer sentido, hoy podemos considerarla errónea: “como el tamaño de un objeto es función del estilo de programación, el método PROBE enseña a los ingenieros cómo utilizar los datos generados por ellos mismos para generar rangos de uso personal”.

Porqué se considera errónea, la suposición se basa en el supuesto de que se estima el tamaño del software a producir con base a líneas de código (LOC), sin embargo después de mucho avance de la disciplina Ingeniería de Software, se reconoce que esta no es una medida adecuada del tamaño de una sistema, en virtud de que no es estándar y depende de la tecnología, por lo que no puede ser utilizada como parámetro de comparación.

Aunado a lo anterior, hoy sabemos que solamente existe un estándar cuantitativo para determinar el tamaño de la funcionalidad del software, se denomina tamaño funcional (ISO/IEC 14143) y se determina a través de distintos métodos estándares, entre los que se encuentra COSMIC como el único método de segunda generación (referencia blog).

En lo que se refiere a la estimación de recursos, el método PROBE recomienda utilizar una regresión lineal considerando el tamaño (la cantidad de código) estimado y el esfuerzo real (en alguna unidad de tiempo como meses, días u horas-persona) de acuerdo a los datos históricos personales, también recomienda al menos tres proyectos siempre y cuando se demuestre una correlación razonable entre los datos.

Una vez estimado el tiempo total del proyecto, se establece con base en los datos históricos el esfuerzo por fases, y se detalla por mes, semana o día, para proyectos grandes PSP introduce también el uso del método de Earn Value.

Aquí cabe mencionar que uno de los problemas más grandes para la realización de estimados es el contar con datos históricos, Morgenshtern [2] menciona que los modelos algorítmicos necesitan datos históricos, y muchas organizaciones no cuentan con esta información. Adicionalmente, recolectar estos datos implica un costo muy alto en dinero y tiempo.

Figura 2. Fase DE planeación en PSP

Mejorando PSP

Si bien la técnica PSP utiliza las LOC como unidad principal de medida, también indica que “cualquier unidad de medida puede ser utilizada, siempre y cuando proporcione una correlación razonable entre el tiempo y el tamaño del producto” [1].

«Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.» – Bill Gates.

P. Bourque [3] menciona que los requerimientos definen el alcance o tamaño del producto, el tamaño determina el esfuerzo y éste influye en la duración; también menciona que la relación entre esfuerzo y tiempo no es lineal.

Aunado a lo anterior resulta lógico pensar que es mejor utilizar un estándar generalmente aceptado para determinar una unidad de medida y poder realizar comparaciones.

Por estas razones, se considera que los resultados que se obtienen con PSP pueden ser visiblemente mejorados si se utiliza un mecanismo estandarizado de dimensionamiento de tamaño de software, que para este caso se puede recomendar el único estándar de segunda generación de tamaño funcional; método COSMIC (ISO/IEC 19761), como se muestra a continuación.

Figura 3. Método PROBE utilizando COSMIC

Conclusión

PSP en un proceso que se enfoca en mejorar las prácticas de trabajo individuales, a través de la definición y utilización de un “proceso de medición” basado en LOC.

Sin embargo, existen estudios que demuestran que la correlación entre LOC y esfuerzo no es muy adecuada, en virtud de que las LOC son dependientes de las distintas tecnologías, así como de la experiencia de programación de los desarrolladores, además de no ser un estándar.

Por lo anterior, se considera que los resultados de PSP pueden ser mejorados si se utiliza un mecanismo estándar de medición como el método COSMIC, en virtud de ser un método que determina unidades de tamaño estándares generalmente aceptados, y en particular COSMIC por ser el único estándar para medición de tamaño funcional de segunda generación, el cual presenta algunas ventajas sobre los métodos de la primera generación.

En relación a las preguntas planteadas originalmente respecto si el método COSMIC se puede utilizar con el método PROBE de PSP, la respuesta es SI, de hecho se complementan.

Respecto de la pregunta de ¿porqué no usar PSP en lugar de COSMIC?, la respuesta es porque no son excluyentes, PSP es un proceso y COSMIC es estándar de medición de tamaño de la funcionalidad del software.

Referencias

[1] Watts S. Humphrey (2000), “The Personal Software Process SM (PSPSM), Technical report CMU/SEI-2000-TR-022, ESC-TR-2000-022, November 2000.

[2] Morgenshtern, O., T. Raz, and D Dovir (2007), “Factors affecting duration and effort estimation errors in software development projects,” Information and Software Technology, vol. 49, no. 8, August 2007, pp. 827-837.

[3] Bourque, Pierre, S. Oligny, A. Abran, B. Fourrnier. 2007. « Developing Project Duration Models in Software Engineering ». Journal of Computer Science and Technology, vol. 22, p. 348-357.

The post Mejorando el Personal Software Process (PSP) con el Método COSMIC first appeared on Spingere.

Como no tiene tiempo ni interés en aprender todo el tema contable (Leyes, Normas, Boletines, etc.), usualmente lo que hace es contratar a un contador que realiza la contabilidad, de manera simplificada solo consideraremos 2 escenarios, uno en el que el ingeniero de desarrollo contrata al contador solamente para hacer la declaración anual (escenario 1) y otro cuando lo contrata a un contador durante todo el año (escenario 2) para realizar las declaraciones mensuales y para hacer la declaración anual.

Escenario 1

En este escenario es claro ver que si se contrata a un contador solo para hacer la declaración anual, el resultado es tácito, solamente indicará si se tiene un saldo a pagar o un saldo a favor con base en los comprobantes que se juntaron en el año, no se puede hacer mucho al respecto.

Escenario 2

Por otro lado si se contrata al contador durante todo el año, y hace las declaraciones informativas con base en los comprobantes que se juntan en el mes e informa cada corte al ingeniero de desarrollo, es posible poder definir y ejecutar un estrategia fiscal, que permita o disminuir la cantidad a pagar o incluso tener saldo a favor.

Análisis

De esta forma tenemos que el proceso contable al ser repetitivo, requerir un alto grado de especialidad o capacidades específicas dado el amplio cuerpo de conocimiento existente, adicionalmente a que esta fuera de las funciones principales del ingeniero, con las que genera valor, por tal motivo es recomendable hacerlo vía outsourcing y durante todo el ciclo (escenario 2) generando así un mayor valor.

Hoy en día es común esta práctica tanto como personas físicas como en cualquier empresa de cualquier tipo, lo que genera que las personas como las empresas se enfoquen en lo que realmente es su fuerte y utilicen a su favor la información ( y asesoría fiscal) que se genera a través de los especialistas.

Analogía con el desarrollo de software

Ahora bien, en el ámbito de los proyectos de software, la mayoría de las personas y empresas (fábricas de software) que se dedican al desarrollo tienen como objetivo principal el desarrollar aplicativos o piezas de software, durante mucho tiempo han invertido sus esfuerzos en capacitarse y prepararse en administración de proyectos, en procesos y técnicas de desarrollo como CMMI y metodologías ágiles, herramientas de desarrollo, etc. Sin embargo, muy pocas empresas/personas han tenido capacitación formal en el dimensionamiento y estimación de proyectos, que son la base para poder hacer una adecuada administración de proyectos, sobre todo con un enfoque ingenieril.

Qué sucede entonces cuándo en una empresa se requiere estimar la duración, esfuerzo o costo de un proyecto, o determinar el número de errores promedio o su factor de productividad, el número de recursos requeridos para terminar el proyecto en tiempo, etc., bueno … pues no se tienen datos históricos derivado de que no se han hecho mediciones, por lo que las estimaciones para determinar costos y planeación de esfuerzos se realizan con base en juicio de experto alineado a las prácticas del PMI, pero que pasaría si la información que tuviera la PMO fuera cuantitativa? Bueno pues las decisiones serían más objetivas, y se podría hacer una mejor planeación, monitoreo desempeño de proyectos y control de estos.

Para contar con una base de datos se necesita empezar a medir, si nunca se empieza nunca se va a conseguir!, alguien dijo: ”la caminata más larga inicia con el primer paso”

En este sentido se crea el concepto de SAO® (Software Accountability Office), esta oficina ofrece un servicio similar al outsourcing de contabilidad (por eso su nombre), se enfoca en dimensionar, estimar y registrar los datos derivado de que la gente que la integra es especializada en esto, lo que hace que el personal de la fábrica de software no requiere tener una especialización en dimensionamiento y estimación, por el contrario va a poder utilizar las capacidades actuales en desarrollo de software y administración de proyectos, solo que contando con información cuantitativa.

El objetivo de la SAO® no es administrar los proyectos, es recabar de manera formal y continua información proporcionándola para la toma de decisiones objetiva, la SAO® solo se dedica a medir, estimar y registrar la información, tiene funciones muy acotadas que se puede integrar directamente a la PMO®, y es independiente de el proceso de desarrollo de software que utilicen las entidades. El esquema de una SAO® conceptualizado por SPINGERE se muestra a continuación.

Este esquema habilita la toma de decisiones objetivas por parte de las oficinas de proyectos de las distintas entidades, además de permitir la canalización de los esfuerzos en lo que realmente les interesa, logrando así eficiencia en costos dado que permite plantear esquemas eficientes de control de contratos y proyectos de software.

The post Concepto de Software Accountability Office (SAO) first appeared on Spingere.

Esta carrera tecnológica, ha existido siempre desde el inicio de la computación, siempre habrá cosas nuevas que en poco tiempo serán remplazadas, como se estableció en la Ley de Moore. Sin embargo, si observamos la realidad de los proyectos de software que también inició con la carrera tecnológica, el éxito de los proyectos de software es muy bajo desde siempre (actualmente < a 30% según Standish Group) con independencia de metodologías de desarrollo, lenguajes de programación o bases de datos más novedosas. ¿Por qué sucede esto?

Recientemente en una clase de Maestría, con la finalidad de que vieran, desde mi punto de vista la razón, les pedí un análisis a los alumnos sobre los procesos del Project Management Body of Knowledge, el famoso PMBoK, que se compone de 10 Knowledge Areas (áreas de conocimiento) y que contiene 47 Procesos, cada uno de los cuales tiene un conjunto de entradas, un conjunto de herramientas y técnicas que son utilizadas para transformar las entradas en un conjunto de salidas.

Comparto los resultados aquí:

Considerando la totalidad de los procesos la Herramienta que más es promovida a utilizarse por el cuerpo de conocimiento de la administración de proyectos es el famosísimo “Juicio de Experto” con 59.57% de apariciones, y el segundo lugar “Reuniones” con el 36.7%

Sin duda esto nos puede dar una idea de porque los proyectos de software fallan, seguimos haciendo artesanía, con muy buenos lenguajes y tecnología, pero no se puede considerar como un proceso ingenieril, ya que aún se depende de las personas que lo programaron porque no hay documentación adecuada, ni elementos cuantitativos o procesos ingenieriles que permitan darle continuidad, todo son opiniones de “expertos”.

Hace unos día vi una película “Moneyball 2011”, en esa película, un equipo de beisbol que pierde la serie mundial y su jugador estrella es comprado por otro equipo, por lo tanto el equipo tiene que hacer una reconstrucción, para lo cual el General Manager (Brad Pit) hace una reunión (justo como en el PMBoK) para preguntarle a los expertos (señores de edad avanzada con años de experiencia en el beisbol) ¿a quiénes contratarían?, este equipo de expertos esgrimiendo argumentos “subjetivos” abordan a varios jugadores hablando de cualidades no cuantificables y completamente subjetivas, aunque válidas desde su propia perspectiva. Hasta que el General Manager les hace un gesto de cansancio y desesperación. (ver escena1)

Al ver esta escena automáticamente me remonté a las reuniones de seguimiento de proyectos que he visto donde se menciona que el proyecto va retrasado porque ha habido cambios de alcance, porque es complejo un requerimiento, etc., o reuniones técnicas de equipos de desarrollo, donde se menciona que quizá es el manejador de base de datos, o que el lenguaje no permite hacer ciertas cosas, pero que un lenguaje nuevo “x” ya lo resolvió, o que el requerimiento no estaba claro, etc. Al parecer lo que importa es quien hace los comentarios más sobresalientes en términos de la moda de lenguajes o metodologías, quién puede demostrar que sabe más “subjetivamente” aunque nunca lo haya implementado, quien tiene una buena idea, o al menos quién convenza a los otros (usualmente el de mayor jerarquía), pero en realidad “NADIE PROPORCIONA DATOS” estandarizados que el encargado CIO, Project Manager, Líder de proyecto o Scrum Master, puedan usar de manera comparativa para la toma de decisiones.

En la trama de la película, el General Manager en la búsqueda de talento, va a negociar con un equipo el traspaso de algunos jugadores en una reunión de varias personas, recibe varias negativas, pero se da cuenta que las respuestas finales son consultadas con una persona al fondo de la reunión que es una persona joven de edad, contrastando con la situación que el tenía en su equipo.

Al salir de la reunión lo va a buscar y lo cuestiona de que hacía o cómo lo hacía. Este personaje le comenta que hay una falla epidemiológica en el juego, que hace que la gente de grandes ligas administre mal a sus equipos, se enfocan en comprar jugadores y no en comprar victorias (igual que en el software, muchas veces los CIO’s tratan de comprar lo más nuevo para solucionar las cosas, cuando los problemas son mucho más de fondo), para comprar victorias necesitan comprar carreras, y para esto se necesita tener los datos de qué jugadores generan más carreras, no quienes son mejores o más famosos a la vista de los “expertos”, los datos son crudos. (ver escena2)

Finalmente, este personaje se va a trabajar con el General Manager y a partir de los datos que genera hace una ecuación de predicción que identifica cuántas carreras deberían de permitir y generar, así como cuantos juegos deberían de ganar para llegar a la postemporada, con este objetivo y con la información de los jugadores de cuántas carreras generan o cuanto batean, etc., pudo armar un equipo con pocos recursos que le permitió llegar a la postemporada (ver escena3), finalmente no la ganó pero cambió la forma de ver el beisbol.

En el desarrollo de software lo que hemos estado proponiendo desde hace ya 14 años con el uso de métricas formales de software, es este cambio de paradigma, donde se pueda estimar los proyectos correctamente, hacer un seguimiento cuantitativo real de costo tiempo, alcance, que se pueda conocer la productividad, evaluar la calidad, la capacidad de planta de una fábrica de software, el nivel de producción de software en un momento dado, etc.

Sin embargo, muchas empresas y CIO’s solo lo ven como una moda u otra metodología más, que sin duda es más costosa de llevar a cabo correctamente, especialmente comparando con una metodología que puedes leer en una revista o libros de Sanborns y como todo es subjetivo puedes hacerte experto y/o promulgarte como experto, porque no hay forma de medirlo, en el caso de las métricas necesitas tener un enfoque ingenieril, conocer de matemáticas estadística y manejo de unidades, implica si o si utilizar medidas, alguien dijo “El nivel de madurez de una disciplina depende de la calidad de sus métricas”.

Si quieres cambiar la forma de tomar las decisiones de tus proyectos, e incrementar el éxito de estos, cambia la forma de hacer las cosas. www.spingere.com.mx

The post ¿Por qué son realmente importantes las métricas en el software? first appeared on Spingere.

The post GASTOS NO REALIZADOS Y NO COMPROMETIDOS EN EL DESARROLLO DE SOFTWARE first appeared on Spingere.

The post ¿ÁGILES O CASCADA CON COSMIC? first appeared on Spingere.

The post ¿QUIERES TENER TODA LA BASE DE CONOCIMIENTO DE COSMIC EN TUS MANOS? first appeared on Spingere.

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.

¿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.