En este primer artículo se describirá brevemente la historia de los métodos de medición de tamaño funcional para tener un contexto inicial.

Historia resumida de los Métodos de Medición de Tamaño Funcional del Software

La mayoría de las personas involucradas en el desarrollo de software ya sea de un área interna o una casa de software reconocen que medir en el software es fundamental, la frase “Si no lo puedes medir no lo puedes controlar” es dicha con mucha más frecuencia que lo que realmente se aplica.

Sin embargo, ¿qué es lo que se puede medir del software?, cada organización puede definir elementos a medir del software que realiza en función de sus prácticas y experiencias, sin embargo, esto no permite comparaciones con otras organizaciones o industrias, en virtud de que las unidades de medición son distintas.

En los años 70’s (30 años aproximadamente) Allan J. Albrecht’s desarrolló una forma de medición funcional del software independiente de la plataforma de desarrollo y que consideraba el punto de vista del usuario, actualmente llamada Function Points (IFPUG Method), ésta técnica de medición considera conceptos vigentes para aquel tiempo cómo archivos lógicos, además tiene un alcance solo para aplicaciones de tipo MIS (Management Information System), en la actualidad existe una gran variedad de aplicaciones no solo las MIS, como lo son en tiempo real, ERP, DWH, etc.

Más tarde a finales de los años 80’s (20 años aproximadamente) surgió un método llamado Mark II, este método estaba basado en transacciones lógicas y en el modelado de relaciones de entidades, populares en ese tiempo. Estos dos, y otros métodos como: 3D Function Points, Feature Points, FISMA, etc., son considerados de la primera generación de modelos de Medición de Tamaño Funcional (FSM: Functional Size Measurement).

Todos estos métodos se generan a partir de estudios estadísticos realizados en alguna empresa, el análisis de los proyectos expresa en sus resultados, la manera de operar de la empresa para los tipos de proyectos analizados, cuando se trata de utilizar en alguna otra empresa o con otro tipo de proyectos, usualmente los resultados no son buenos, la razón resulta obvia.

¿Por qué tamaño funcional del software?, solo hay un estándar internacional (ISO 14143) que proporciona los meta-estándares que describen el concepto y prácticas de FSM. Dicho de otra forma, si queremos medir algo del software y poder compararlo o compararnos debe de ser el tamaño funcional, ya que es el único estándar para medir una característica del software, claro con alguna de las técnicas o estándares internacionalmente aceptados para esto.

La segunda generación de métodos de FSM está representada por COSMIC (Common Software Measurement International Consortium), este estándar se generó considerando como base el estándar ISO 14143 y la experiencia de los métodos de la primera generación, lo que implica que resuelve la mayoría de los problemas presentados dichos modelos como el manejo de conceptos actualmente no vigentes, el alcance de aplicación de los métodos y una escala de medición más práctica y homogénea, aunado a lo anterior tiene un dominio de aplicación mayor, por lo que se puede utilizar para todo tipo de software vigente al día de hoy, teniendo consideraciones para aquel software de gran complejidad algorítmica, pero esto es igual para cualquier estándar de medición, en virtud de que al día de hoy no existe un estándar para determinar cuantitativamente la complejidad del software.

Figura 1. Historia de los métodos de medición de tamaño funcional

Email secured by Check Point

The post Historia Breve de los Métodos de Medición de Tamaño Funcional del Software first appeared on Spingere.

¿Qué pasaría si en los planos no vinieran medidas? Es muy probable que la construcción de la casa fuera un caos, por que las ventanas no serían del tamaño correcto, o la loza, o las puertas etc. Es fácil ver que no se podría construir una casa sin conocer las medidas del tamaño de cada uno de sus elementos. Más aún, en función de estas medidas se puede estimar la duración de la obra, el costo, se puede tener un control de las dimensiones de la casa, comparar contra otras construcciones, etc.

¿Se puede desarrollar el software sin tener medidas de tamaño? La respuesta es sí, en la mayoría de los casos así se hace, sin embargo, esto fomenta que el desarrollo de software sea un arte, y no un proceso ingenieril, con resultados nada prometedores (The Standish Group International, 2011)( Emam, 2008).

“According to testimony by the Government Accountability Office last September, if were established more realistic baselines of requirements, cost, schedule and risk during project’s planning phases, nearly half of canceled or over budget IT programs could be avoided. That would save $5.5 billion annually, according to a study made by Price Systems LLC, a software and consulting company in Mount Laurel, N.J., USA. The study consider 104 Government IT executives” (PMI, 2007)

Muchas personas involucradas en la industria del software tienen una idea errónea acerca de la medición del software, consideran que no se puede medir ya que es algo intangible, que es algo intelectual por lo que medirlo sería muy complejo, etc. Esto no es cierto, por ejemplo la velocidad de la luz la medimos, y no precisamente de manera física, se mide con un modelo adecuado y generalmente aceptado.

Entonces ¿Se puede medir el software? Sí, de hecho hoy en día la única medición estándar del software es el tamaño funcional (Functional Size Measurement, FSM, ISO/IEC 14143). Si cada organización midiera el software de manera distinta (por módulos, LOC, CU, etc.) no se podrían hacer comparaciones. Esto sería el equivalente a que las medidas utilizadas en cada plano fueran diferentes ¿Serviría?, por supuesto que no.

El FSM entonces, es muy importante, ya que es el único estándar de medición de software existente, es generalmente aceptado y nos habilita para realizar la parte ingenieril del desarrollo de software. A continuación vamos a mencionar algunos de los usos más importantes que se le pueden dar a una medición de tamaño funcional adecuada.

Estimación de proyectos

La estimación de proyectos es my importante para poder tener una buena administración de recursos a lo largo del proyecto.

Hay que recordar que en cualquier proceso de producción de algo (en este caso el software) existe una relación entre la cantidad producida y el costo/esfuerzo requerido para hacerlo.

Si se tiene una buena medición de tamaño funcional es posible generar modelos de estimación algorítmicos que permitan hacer estimaciones del esfuerzo o costo de los proyectos. Si las mediciones funcionales NO son confiables, los modelos de estimación NO son confiables.

Medición del desempeño del proyecto

En cualquier industria la habilidad para medir desempeño es crítica para poder mejorarlo. Por ejemplo cuántas veces hemos escuchado en el software temas relacionados a la productividad.

La productividad en el software cómo en cualquier otra industria es muy importante, todos quisiéramos que las organizaciones fueran más productivas, que las áreas de software fueran más productivas, es más que los programadores o desarrolladores fueran más productivos. Pero ¿qué significa esto?, bueno la productividad está definida por la cantidad de producto terminado dividida entre el esfuerzo necesitado para producirla (o algún otro recurso). El elemento clave es el tamaño, que para el software es tamaño funcional.

Hay otras mediciones que se pueden obtener de un proyecto como son velocidad de entrega que se puede medir dividiendo el tamaño del software en un tiempo determinado. La densidad de defectos que se obtiene de dividir el número de defectos entre el tamaño de software.

Un tema importante es que teniendo un estándar de medición confiable, el desempeño de las organizaciones y/o áreas puede ser comparado gracias a la estandarización de las mediciones de tamaño funcional, que como hemos visto para el desempeño del desarrollo de software son una parte fundamental.

Control del alcance de los proyectos

El alcance de los proyectos muchas veces es definido de manera subjetiva, si se mide el alcance del proyecto utilizando un método de medición de tamaño funcional cada modificación o cambio puede ser medido de igual manera lo que permite determinar la diferencia entre el alcance original o tamaño original y el nuevo tamaño, “scope creep”.

Se pueden definir umbrales de modificación de alcance por ejemplo 20%, lo que implicaría dividir el tamaño funcional del nuevo requerimiento o modificación entre el tamaño original, si excede el umbral no se aceptaría porque podría repercutir en el tiempo de entrega o en costos.

Con estos elementos se puede ayudar a determinar si procede un cambio o requerimiento nuevo, pero también ayuda a saber al final del proyecto cuánto creció en alcance de manera cuantitativa y no solamente de forma subjetiva. Actualmente esto es muy complicado de saber.

Control de contratos de software

Actualmente para la definición de contratos de desarrollo de software se hace un requerimiento, el proveedor del desarrollo pone el precio en base a su experiencia, con una negociación se determina el precio final.

Si se tuviera una medición del tamaño de software solamente basta con multiplicar el número de unidades de tamaño a desarrollar por su costo y ya está. Esto podría apoyar a la industria ya que se debería tender a una estabilización de los costos por unidad de tamaño de software.

Si se requiriera un cambio de alcance o modificación del software, ya se sabe el costo por unidad de tamaño funcional, no se reuinicia una negociación para determinar el costo del cambio que muchas veces suele sobrestimarse.

Conclusión

La medición de tamaño funcional del software es muy importante, al ser hoy en día el único estándar cuantitativo para determinar el valor de una característica del software, y si se utiliza adecuadamente puede ser el habilitador para que los proyectos de desarrollo de software sean exitosos, ya que ayuda entre otras cosas a : la estimación de proyectos, medición del desempeño del proyectos, control del alcance de los proyectos, y control de contratos de software.

Special Interest Group on COSMIC / México

The post Importancia de la Medición de Tamaño Funcional del Software 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.

Cuando se inició a desarrollar el software cada persona lo hacía como podía, y se empezaron a presentar algunos problemas, como, por ejemplo, que pasa si una persona se va de la empresa y alguien más debe de continuar su trabajo, cómo entiende lo que quiso hacer o hizo, o si hay alguien que hace desarrollos de software y frecuentemente lo hace bien ¿por qué no los demás pueden seguir los mismos pasos? O ¿qué pasa si alguien tiene que dar un mantenimiento a un software después de mucho tiempo? O ¿cómo definimos los requerimientos que debe cumplir el software?, en fina muchas preguntas se fueron haciendo y respondiendo conforme se avanzó en el entendimiento y la necesidad de generar software más complejo y de mayor calidad, naciendo así la Ingeniería de software.

Se entendió entonces que, así como en otras industrias, para ser más productivos era necesario automatizar, pero ¿qué puedes automatizar cuando los que transformas los insumos son personas?, bueno se automatizan las prácticas, es decir se generan procesos repetibles y susceptibles de mejorarse de manera continua.

Hay que notar que en ningún momento se elimina a las personas, de hecho, son parte fundamental ya que tienen que transformar los insumos para poder producir el software, es decir, cada persona hace algunas actividades utilizando su conocimiento y habilidades. Entonces  ¿para qué definir un proceso si cada uno lo va a realizar como quiera? Esta es la clave del tema, los procesos son definidos para garantizar que se hacen las mismas actividades y se generan los mismos productos en cada una de ellas, no significa necesariamente que se harán exactamente igual, ya que depende de cada persona, lo que garantizan es que a la salida vas a tener lo mismo.

Consideremos como proceso mínimo, las actividades que se deben de realizar para desarrollar un software independientemente de cualquier metodología, las cuáles se basan en los principios definidos en el SWEBOK (https://www.computer.org/education/bodies-of-knowledge/software-engineering), podemos mencionar que dichas actividades son: definir requisitos del software, analizar y diseñar la solución, codificación, y probar el software.

Si se define una funcionalidad a ser desarrollada por 3 equipos distintos, donde cada uno de ellos realizará de manera independiente las actividades antes mencionadas, al final del día tendremos la funcionalidad propuesta, unos terminarán antes y otros después, las soluciones no serán las mismas, los artefactos generados, diagramas y algoritmos no son iguales, pero la funcionalidad debería de ser la misma.

Justo así funciona la medición de software, de hecho, lo que se puede medir es la funcionalidad, hasta el momento no puedes interpretar como una persona piensa y desarrolla un algoritmo, o un diagrama entidad relación, pero lo que si puedes medir es que un cierto tamaño de funcionalidad conlleva más o menos esfuerzo para hacer el diseño, o la codificación en función de la plataforma o de la metodología o de la persona que lo hace.

No podemos medir lo que pasa en el cerebro, y está bien, eso es lo que hace que se tenga software mediocre y también excelente o innovador. Pero lo que es necesario es medir y principalmente la funcionalidad porque existe una relación que, a mayor funcionalidad, mayor esfuerzo es necesario para desarrollarla.

Por otro lado, el software hoy en día está completamente involucrado en la industria, es decir, los negocios, por ejemplo, bancos, aseguradoras, farmacéuticas, empresas de retail, etc., desarrollan o contratan software para implementar sus proyectos de transformación, y es fundamental para ellos estimar costos, hacer casos de negocio, priorizar algunas iniciativas sobre otras y en general obtener una rentabilidad de cada proyecto de software, si no se mide el software, esto no se puede llevar a cabo de una forma profesional, se va a hacer de manera subjetiva generando que los proyectos fracasen y sean más costosos, hay una estadística que indica que prácticamente todas las empresas han tenido en un año al menos un proyecto de software que fracasó.

SPINGERE es una empresa enfocada en dar servicios de medición y estimación profesional de software desde hace más de 14 años, incrementando la rentabilidad de los proyectos en más de 200%, aumentando la velocidad en que se hacen las estimaciones y la precisión de estas, si quieres obtener resultados diferentes, haz cosas diferentes, visita los testimonios de distintos clientes que ya han obtenido resultados tangibles. https://spingere.com.mx/testimonios

Dr. Francisco Valés Souto

Fundador de SPINGERE y la Asociación Mexicana de Métricas de Software (AMMS)

“La realidad de tus proyectos de software en métricas”

The post ¿El software se puede medir en realidad? ¿Qué no es un proceso intelectual? 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.

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

Ahora extrapólenlo a nivel industria, estas en una situación en la que cuentas con capacidad de desarrollo de software, pero como decides ¿Cómo decides entre hacerlo o que lo desarrolle alguien más?, estamos en una industria que está cuidado el dinero, pero que tomas como referencia para determinar que te conviene, igual y hasta terminas subcontratarlo porque que se “cree que es más barato”, el tema es que no se tienen una referencia clara, cuantas veces se ha comprado algo en lo que se termina aplicando el refrán “lo barato, sale caro”… COSMIC, puede ayudarte a con muchas de esas respuestas, podrías comprar la productividad de tu gente con la industria, cual es la probabilidad de que terminan con la productividad que te están ofreciendo para ese proyecto, y entonces si tomas una decisión con elementos cuantificables.

Recordemos que eso aplica para todo, pongamos otro ejemplo: quieres implementar COSMIC para tener referencias estandarizadas, que te permitan estimar, vender, comparar, subcontratar, y se llega a la primer pregunta: ¿lo hacemos o nos apoyamos de alguien?, si decides apoyarte de alguien de verdad que sea con gente que tiene un soporte especializado, porque no es una buena referencia irte únicamente por el precio, seguramente a la larga vas a poder obtener todos los beneficios que estabas esperando, pero que pasa si eliges al que no tiene el soporte especializado por ser más barato, ¿sabes cuantas buenas prácticas se mueren porque son mal implementadas?, al menos me ha tocado ver 4 malos intentos de implementaciones de COSMIC en el gobierno federal que terminan diciendo “no sirve” porque no pudieron obtener los beneficios que se suponía tendrían, y peor aún, tendrán que volver a invertir para hacerlo bien,  pero también he visto el otro lado de la moneda donde en el gobierno federal y en la iniciativa privada han explotado los beneficios de las buenas prácticas, para generar información valiosa para la toma de decisiones.

Si quieres implementar correctamente COSMIC y superar los resultados esperados, busca a los expertos, la única empresa autorizada por COSMIC para hacer servicios de consultoría en México desde hace más de 10 años www.spingere.com.mx

The post ¿Lo hacemos? o ¿lo compramos? 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.