Medición de software: una descripción general para los CIO

La medición del software es importante porque es difícil gestionar lo que no se mide. El trabajo de software es trabajo de conocimiento. Es uno de los esfuerzos más costosos emprendidos por la humanidad, con más de 50 millones de personas en todo el mundo trabajando en funciones de software altamente remuneradas y, para la mayoría de ellos, sus esfuerzos no se miden. Mucha gente no se da cuenta de que el tamaño del software se puede medir. La mayoría de las otras formas de trabajo humano tienen medidas estandarizadas de tamaño y productividad. Pero en el trabajo con software, aunque existen métricas adecuadas, rara vez se utilizan. Hasta ahora, los líderes de la industria, los educadores, los ejecutivos e incluso los gobiernos se han mostrado relajados ante este fenómeno, pero con la creciente importancia del software para la supervivencia corporativa, se necesita más transparencia y una medición adecuada del software. La introducción de la medición de software con el dimensionamiento COSMIC ayudará a los CIO a gestionar de forma más eficaz.

La medición de software ayuda a responder preguntas clave

Al tratar de responder las preguntas de cuanto esfuerzo es necesario para entregar un proyecto de software o cuando va a estar terminado, la mayoría de las organizaciones confían en las opiniones de expertos. Estas estimaciones de software tienden a ser poco científicas y propensas a la manipulación. Lo que necesitan es un medio consistente de medición del software. Constituyen una base poco sólida para tomar decisiones de gestión fiables y, a menudo, pueden conducir a comportamientos contraproducentes. Sin embargo, con estimaciones de software válidas y estandarizadas y métricas de software basadas en un dimensionamiento funcional estandarizado en puntos de función COSMIC (CFP), los CIO pueden mejorar significativamente la visibilidad, la capacidad de gestión, la productividad y la relación calidad-precio del trabajo de software en su organización. Las métricas del software basadas en CFP y las correspondientes métricas del proyecto también son apropiadas para la presentación de informes a nivel de junta directiva. Esta lectura de 15 minutos será suficiente para comenzar este viaje hacia niveles superiores de gestión de software.

La medición de software del tamaño importa.

Consideremos algunas características generales que son particulares del trabajo del software:

• El trabajo del software está impulsado casi en su totalidad por el esfuerzo humano.
• Hay muchos factores que determinan el esfuerzo que requerirá desarrollar algún software. El factor más significativo es tamaño funcional.
• Tamaño funcional puede estimarse y, en algunos casos, incluso medirse antes de que comience la codificación.
• Hay docenas de otros factores que afectan el esfuerzo que se necesitará para desarrollar software, entre ellos: la competencia del equipo, la complejidad y el apoyo ejecutivo, pero el tamaño es el más importante.
• Existe una gran variabilidad en la productividad entre desarrolladores. 10 veces o más entre el menos y el más productivo, y lo mismo para los equipos.
• El trabajo del software no escala. Existen deseconomías de escala, causadas principalmente por la alta proporción de tiempo dedicado a la comunicación entre los miembros del equipo. Un lenguaje común y el conocimiento del tamaño de un proyecto pueden ayudar a contener este problema.

Desde que el software se convirtió en una industria, el tamaño del software ha sido un tema de interminables debates entre desarrolladores y administradores. Dada la cantidad de personas involucradas en la industria del software, sorprende que los ejecutivos y las juntas directivas hayan permitido que esto suceda.

Si bien existen muchos factores que afectan el costo y la duración de un proyecto de software, el tamaño es el factor más importante. Si ha analizado los requisitos y determinado el tamaño funcional de las CFP, puede predecir, con una confianza razonable, cuánto tiempo llevará y cuánto debería costar. Éstas son preguntas vitales que los gerentes responsables deben responder para planificar de manera eficaz. Armarse con el conocimiento del tamaño funcional en las primeras etapas del ciclo de vida de un proyecto puede ayudar a mejorar la calidad de las decisiones que toman los gerentes y, por lo tanto, puede reducir el riesgo, el costo y la duración del proyecto. Hay puntos de referencia de la industria disponibles o las organizaciones pueden establecer sus propios puntos de referencia para la productividad en la PPC, con el fin de responder a la pregunta "¿cuándo terminaremos?" pregunta.

Medición de software e ingeniería de software

Todas las demás formas de ingeniería adoptan medidas de tamaño estandarizadas (ISO). La Ingeniería de Software es la única “disciplina” de Ingeniería que no lo ha logrado. La ingeniería de software debe adoptar medidas de tamaño estandarizadas.

Dimensionamiento de software estandarizado

Mucha gente piensa que la medición del tamaño del software sólo se puede realizar una vez finalizado el trabajo. Esto no es así. El software se puede medir ejecutado incluso antes de que haya comenzado la codificación.

La mayoría de las personas involucradas en la industria desconocen que la medición del tamaño del software es posible y fácil de realizar, incluso antes de que haya comenzado cualquier trabajo de codificación. El tamaño funcional se puede determinar simplemente examinando los requisitos del usuario.  

Puede contar líneas de código después de escribir el software, pero el recuento de líneas de código (LOC) tiene poco valor, excepto cuando se considera el trabajo de mantener lo que ya se ha escrito. Además, considere que dos desarrolladores escriben alguna funcionalidad, el desarrollador A puede escribirla en solo 4 líneas de código, mientras que el desarrollador B necesita 40 líneas para lograr la misma funcionalidad. ¿Cuál es más grande? ¿Cuál es más productivo? ¿Cuál es más propenso a errores? Esto nos muestra que no podemos utilizar LOC de manera confiable como un predictor de estimación de tamaño, esfuerzo o tiempo.

La medición del tamaño funcional del software conduce a decisiones basadas en datos sobre el software

Como sociedad, avanzamos rápidamente hacia la toma de decisiones basada en datos. Incluso para decisiones en casa, nos fijamos en reseñas y datos técnicos antes de tomar una decisión de compra. Para que este enfoque sea eficaz, debemos utilizar datos válidos, coherentes y fiables. Después de examinar las medidas básicas en el espacio del software durante muchos años, hemos llegado a la conclusión de que las métricas basadas en el tamaño de COSMIC son las más confiables.

• Tamaño o alcance (CFP),
• Métricas de productividad (CFP/tiempo),
• Métricas de calidad del software (Defectos/CFP) y
• Recursos (recurso/CFP).

Pasar a las buenas prácticas para dimensionar el software

El software de medición y estimación ha sido un desafío desde que comenzó la industria del software. Nos saltaremos la lección de historia y pasaremos directamente al estado actual del juego. La mayoría de los equipos de software ágil estiman el esfuerzo utilizando indicadores de “equivalente al esfuerzo” poco científicos e inconsistentes. puntos de la historia o Tallas de camiseta.  Puntos de la historia y Tallas de camiseta son conjeturas proxy poco confiables, no lineales y altamente jugables sobre cuánto tiempo llevará realizar una gran cantidad de trabajo. El número de puntos de la historia asignado por un estimador o equipo estará influenciado por los motivos de quien declara el tamaño. Los “puntos de la historia” son a menudo el único indicador que se les ofrece a los gerentes para ayudarlos a planificar y administrar el trabajo, por lo que estos indicadores se usan en exceso y se usan mal como algún tipo de métrica confiable, cuando están lejos de serlo. En algunos casos, el recuento de historias se utiliza como indicador de progreso y tamaño. Nuestros estudios de más de 250.000 historias de usuarios han mostrado una variación en el tamaño de las historias de 2 a 120 CFP, lo que demuestra que el tamaño de las historias es inconsistente y, por lo tanto, el recuento de historias no es confiable.

La solución a este problema ha estado disponible desde hace bastantes años: es la medición estándar ISO del tamaño funcional del software conocida como COSMIC Function Point (CFP). El dimensionamiento COSMIC es una metodología gratuita que es un estándar internacional estable, regido por una organización sin fines de lucro.  https://www.cosmic-sizing.org/. El estándar COSMIC es una adaptación del concepto original de tamaño funcional inventado por Alan Albrecht, de IBM, en 1974.

El punto de función COSMIC (CFP) es una unidad de medida de tamaño funcional que se puede aplicar a CUALQUIER proyecto de software, trabajo de DevOps, mantenimiento de software o implementación de paquetes. Es una medida de tamaño consistente y universal que se puede utilizar independientemente de los métodos de codificación o idiomas utilizados. Poco a poco se está reconociendo como el estándar líder para el dimensionamiento y se imparte en un número creciente de cursos de ingeniería informática en todo el mundo.

El tamaño de COSMIC le permite estimar o medir el tamaño funcional (el número de CFP) dentro de una porción de software. Representa una visión del tamaño desde la perspectiva del usuario, no desde una perspectiva técnica. (Tenga en cuenta que un “usuario” puede ser otro actor del sistema, por lo que esta metodología también se puede utilizar para sistemas integrados). Es independiente de la tecnología o arquitectura utilizada para entregar el software y, por lo tanto, se puede utilizar en toda una cartera de software y trabajos de mantenimiento.  Como CIO, puede medir cada uno de sus proyectos de software y actividades de mantenimiento de software. Se beneficiará de métricas de software válidas y consistentes sobre las cuales tomar decisiones bien informadas.  Incluso puede medir proyectos anteriores para proporcionar puntos de referencia de productividad.

Queremos saber cuando estará terminado.

Este es un desafío común al que se enfrentan los CIO. Y normalmente nos resulta muy difícil responder. Pero cuando se utilizan las CFP como métrica de tamaño estándar y se realiza un seguimiento de la producción de los equipos de desarrollo en CFP por mes o CFP por sprint, la fecha de finalización se vuelve predecible. Medir el tamaño del software es la piedra angular de las métricas de software válidas y responder a la pregunta crucial de cuánto tiempo llevará.

Tamaño de la PPC y su relación con el esfuerzo

El tamaño de la PPC resulta ser un excelente predictor del esfuerzo y, por tanto, del coste. Estudios independientes han demostrado que la CFP es un predictor de costos más consistente que la estimación del propio equipo en puntos de historia (consulte los cuadros a continuación). Las tasas de productividad varían de un equipo a otro, pero cualquier equipo determinado, en igualdad de condiciones, es probable que entregue una cantidad constante de CFP por sprint o por mes. De este modo, podrá determinar rápidamente el coste por CFP.

Adecuado para contratos

Dado que la CFP es una medida coherente e independiente, también se puede utilizar en contratos de software. En lugar de verse obligados a firmar un contrato de “tiempo y materiales” con un proveedor de desarrollo, los CIO pueden solicitar contratos basados en el costo por CFP. Esto puede lograr una mayor certeza del costo, incluso si aún no conoce todos los requisitos. Es probable que los contratos de software subcontratados basados en puntos de la historia le cuesten 10% más y tomen alrededor de 10% más que aquellos basados en un precio fijo firme por CFP. En dichos contratos también deberían incluir objetivos de productividad (por ejemplo, CFP/mes) y calidad (límites de defectos/CFP encontrados en las pruebas de aceptación, por criticidad).

Aprender a medir el tamaño

La técnica de dimensionar la funcionalidad del software en CFP requiere aproximadamente un día para aprender los conceptos básicos y aproximadamente tres semanas para adquirir competencia y certificación. Con experiencia, podrá determinar el tamaño equivalente de un año-personal de trabajo de desarrollo en menos de un día de dimensionamiento. Si elige utilizar nuestra herramienta de dimensionamiento automatizada, ScopeMaster, el dimensionamiento de CFP se puede realizar aún más rápido y con poco esfuerzo.

Dimensionamiento del software estandarizado en su organización

Como ocurre con todo, el uso de pesos y medidas estandarizados conduce a un mercado más justo y transparente. El dimensionamiento estandarizado del software hará lo mismo en el mercado de servicios de software: es sólo cuestión de tiempo. Hasta entonces, hay ganadores y perdedores. Sólo Estados Unidos gasta $500 mil millones al año en software empresarial. Estimamos que más de 30% de esto podrían ahorrarse con la adopción de una medición de tamaño de software estandarizada.

Si quieres saber por qué los humanos hacen lo que hacen, siempre vale la pena seguir el rastro del dinero. Hay instituciones multimillonarias que están prosperando gracias a contratos de “tiempo y materiales” y cuyos intereses comerciales se verán amenazados por la introducción de tamaños estandarizados. Hoy en día, la mayor parte del trabajo de software se encarga en función del tiempo y los materiales, con poco riesgo comercial para el proveedor. Una vez que las organizaciones compradoras empiezan a insistir en pagar producción en lugar de esfuerzo En el trabajo de software, el equilibrio del riesgo comercial variará ligeramente del proveedor al comprador.

Además, muchos consultores, entrenadores ágiles, proveedores de marcos e incluso desarrolladores se benefician de la falta de transparencia que surge al no dimensionar formalmente el software.

Al utilizar el tamaño de CFP, los compradores podrán adquirir servicios de software, incluidos desarrolladores, evaluadores, entrenadores ágiles, arquitectos e incluso consultores, con un costo por CFP. A su debido tiempo, la adopción generalizada del dimensionamiento de CFP es inevitable porque quienes compren los servicios de software descubrirán que no sólo es más transparente y mensurable, sino que con el dimensionamiento adecuado se puede entregar más software y más rápido. Con el tiempo, esto conducirá a la mercantilización del trabajo del software.

La capacidad de entregar proyectos de cambio de software más rápido y mejor que los competidores se está convirtiendo en un determinante clave de la supervivencia corporativa. Al utilizar mediciones válidas, puede determinar qué equipos, proveedores y proyectos son realmente exitosos frente a aquellos que simplemente pretenden serlo. Por ejemplo, si el equipo A entrega 1000 CFP en 12 meses por $1m de dólares, mientras que el equipo B entrega 700 CFP en 20 meses por $2m, se puede ver claramente quién está haciendo un mejor trabajo. Esto no es posible sin el dimensionamiento de la CFP.

Habrá resistencia a la adopción de un dimensionamiento transparente del trabajo de software. La transparencia y la mensurabilidad pueden resultar amenazadoras para quienes se benefician de su ausencia. Debería esperar rechazo de sus proveedores de desarrollo, e incluso de sus propios equipos de desarrollo internos, quienes actualmente disfrutan de un grado de libertad que proviene de no ser medidos.

Escuchará respuestas como "no tenemos tiempo para hacer eso". Para una historia de usuario refinada típica, se necesitarán hasta 2 horas de personal de conversación agregada para darle forma, analizar y estimar los puntos de la historia. Mientras que la PPC se puede determinar en tan solo unos minutos.

Otra reacción que encontrará es "ya tenemos muchas métricas". En respuesta a esto, deberá cuestionar a sus equipos sobre la validez de las "métricas" que proporcionan actualmente. A continuación se muestran algunas de las llamadas métricas de uso común y sus fallas frente a sus equivalentes basados en CFP. Estos son indicadores de uso común, pueden ser útiles pero NO son métricas válidas basadas en un sistema métrico.

• Puntos de la historia – son subjetivos, jugables, poco científicos e inconsistentes dentro y entre equipos. Los puntos de la historia son esencialmente una aproximación a una estimación de horas de esfuerzo. En su lugar, utilice CFP.
• Tallas de camiseta– también son indicadores de esfuerzo subjetivos, jugables, poco científicos e inconsistentes.
• La historia cuenta – las historias varían en tamaño absoluto, típicamente oscilando entre 2 y 120 CFP, con una mediana de 6 CFP, por lo que contar historias de tamaño desigual es un indicador poco confiable de progreso.
• Velocidad ágil – citado en historias o puntos de la historia a lo largo del tiempo. Ver Puntos de la historia, esto debe considerarse un indicador de productividad. En su lugar utilice: CFP por sprint o mes`
• Burndown de sprint o quemado semanal– basado en puntos de la historia o recuentos de historias. En lugar de usar PPC entregada.

Nótese bien. Tiempo de ciclo, tiempo de entrega, tasa de reparación de defectos, complejidad del código, tasa de descubrimiento de defectos, y cobertura de prueba son ejemplos de métricas válidas que fomentamos.

Uso de la CFP como métrica básica para controlar proyectos

Además de utilizar CFP para dimensionar su cartera de software y sus proyectos, puede utilizar métricas basadas en CFP como base para controlar el progreso del proyecto:

• productividad (PPC/mes),
• calidad (defectos encontrados/CFP)*
• programacion de recursos humanos como la asignación de trabajo (en PPC) por individuo.
• alcance (CFP), cambio de alcance y volatilidad del alcance

*Esto se puede desglosar aún más en defectos por criticidad y defectos por fuente, todo según CFP.

Todas estas son medidas vitales para controlar eficazmente los proyectos de software. Rápidamente comenzarás a ver qué proyectos van bien y cuáles necesitan ayuda.

PPC y calidad

Echemos un vistazo a la relación entre la calidad del software y el dimensionamiento o conocimiento del tamaño (en CFP).

El proceso de dimensionamiento ayuda con la calidad.

El proceso de dimensionamiento nos anima a pensar profundamente en los requisitos funcionales necesarios para ofrecer una capacidad empresarial valiosa. Esta forma de pensar ayuda a eliminar pronto posibles malentendidos. De lo contrario, estos malentendidos se manifestarían como defectos. Por lo tanto, el proceso de dimensionamiento de la CFP es, en efecto, “lo último en pruebas de desplazamiento a la izquierda”.

El conocimiento del tamaño ayuda a mejorar la calidad.

Conocer el tamaño puede ayudarnos (al utilizar puntos de referencia) a predecir la cantidad de defectos que podríamos esperar encontrar en una pieza de software. Esta previsión, a su vez, nos ayudará a determinar ¿Cuántas pruebas se necesitan?   Al trabajar con defectos por CFP, nuestra apreciación de la calidad mejora.

El análisis automatizado también ayuda a mejorar la calidad

Al optar por utilizar ScopeMaster® para analizar y probar los requisitos, descubrirá inmediatamente alrededor de 50% de los problemas de requisitos latentes que podrá resolver de forma rápida y temprana. Esto representa alrededor de 8% de todos los defectos de un proyecto, y aún más en los más grandes.

Gestión de calidad de proveedores con CFP

Cuando utiliza un contrato que insiste en un nivel máximo de defectos aceptables según CFP, puede alentar a los proveedores a garantizar la calidad. Algo que en los contratos de T&M pueden estar menos motivados para hacer.

Limitaciones de la medición del tamaño funcional con CFP

Los CFP son una medida del tamaño funcional desde la perspectiva del usuario. Miden los movimientos de datos de un sistema de software. no pueden medir tamaño computacional de una transacción de software, ni pueden usarse para medir “no funcional”Aspectos del trabajo del software, como rendimiento, mantenibilidad, usabilidad (y otras funciones). Esto no es sólo una deficiencia de la PPC sino un fracaso de toda la industria; nadie ha ideado todavía medidas válidas y consistentes de estas dos dimensiones (tamaño computacional, y NFR) de software.

Incluso con esas limitaciones, la correlación de la CFP con el esfuerzo necesario para realizar el trabajo es excepcional, lo que significa que conocer el tamaño de la CFP le dará un indicador muy sólido de cuánto esfuerzo se necesita y, por lo tanto, de los costos y plazos: las dos partes del proceso. Conocimientos de planificación que los gerentes de proyectos y de desarrollo necesitan para tomar decisiones acertadas.

¿Cuándo se puede estimar o medir el tamaño?

La estimación de la CFP se puede realizar en cualquier momento del ciclo de vida del desarrollo de software, incluso desde el principio, tan pronto como comienzan a surgir los requisitos comerciales. Las primeras estimaciones pueden volverse más refinadas y precisas a medida que aumenta su conocimiento de la funcionalidad del usuario. A medida que los requisitos evolucionan, la certeza de las estimaciones aumenta y, finalmente, las estimaciones pueden convertirse en una medición precisa. Para realizar una medición precisa, solo necesita conocer todos los movimientos de datos asociados con cada requisito funcional (o historia de usuario funcional). Con CFP puede dimensionar cualquier conjunto de requisitos determinado, no necesita conocer todos los requisitos de antemano ni conocer el diseño para determinar el tamaño de CFP. A más tardar, debes medir el tamaño de la CFP de una historia de usuario justo antes de que se acepte en un sprint. Incluso puede estimar o medir proyectos anteriores para crear datos de referencia para puntos de referencia internos de productividad.

Las desventajas de adoptar la PPC

Hay muchas personas en el mundo del software cuyo sustento se beneficia de la ausencia de una medición consistente del tamaño. Entre los mayores beneficiarios se encuentran aquellas organizaciones que venden servicios de desarrollo de software en función del tiempo y los materiales. Esto incluye algunas organizaciones muy grandes e influyentes. Además, muchos consultores, entrenadores ágiles, proveedores de marcos e incluso desarrolladores se benefician de la falta de transparencia que surge al no dimensionar formalmente el software. Los errores pueden ocultarse, la productividad es difícil de evaluar y esto puede adaptarse a sus intereses. Por otro lado, para cualquiera responsable de comprar o administrar el trabajo de software, realmente no hay ningún inconveniente en medir con CFP. Se necesita una cantidad insignificante de esfuerzo para realizar la medición. Tanto el conocimiento del tamaño como el acto de dimensionar el CFP pueden ayudar a reducir problemas de alcance, mejorar la calidad y mejorar la productividad en cualquier proyecto de software.

CFP es perfecto para ágil y ágil escalado

Rara vez se conocen todos los requisitos de un proyecto de software desde el principio. El flujo de trabajo ágil le permite manejar esta incertidumbre temprana. Los proyectos ágiles se caracterizan por una conciencia cambiante de los requisitos. Afortunadamente, la PPC poder medirse con precisión incluso antes de que se conozcan todos los requisitos de un sistema. Simplemente mides lo que sabes. También es posible estimar lo que aún no se sabe con seguridad. Con experiencia, incluso puedes estimar con anticipación cuando solo se conocen las capacidades generales o las epopeyas. A medida que avanza un proyecto, las epopeyas se dividen en historias de usuarios funcionales y esas estimaciones iniciales se convierten en medidas más precisas de la PPC con un margen de error decreciente. Piense en la certeza de los requisitos como un espectro que va desde "lo sabemos todo" hasta "sabemos muy poco". Aunque es más fácil dimensionar un proyecto si se conocen todos los requisitos, es sorprendente cuánto se puede saber desde el principio. En general, simplemente no trabajamos lo suficiente desde el principio para descubrir lo que es cognoscible.

En organizaciones con múltiples equipos de software, los altos directivos necesitan conocer la productividad de los diferentes equipos para ayudar a mejorar los equipos de bajo rendimiento y aprender de los altamente productivos. CFP resuelve el problema de la falta de tamaño consistente entre equipos. Al adoptar CFP en todos los equipos, se pueden comparar las tasas de productividad. Las tasas de productividad también se pueden comparar entre equipos internos y externos. Esto ayuda a proporcionar a los ejecutivos de software los datos que necesitan para tomar mejores decisiones. Nunca se deben comparar equipos con puntos de historia.

Es hora de controlar el tamaño del software

Después de 70 años de conjeturas y enfoques no científicos, ha llegado el momento de que los CIO y líderes de software responsables insistan en la adopción de métricas de ingeniería adecuadas para el tamaño. Al introducir e insistir en la adopción de CFP, disfrutará de una mejor visibilidad y previsibilidad de su actividad de software. Habrá detractores en su organización y entre los proveedores, por lo que deberá estar preparado para animarlos a ver las ventajas de una medición de tamaño válida. La medición del tamaño del software es una buena práctica. Conduce a una mejor mensurabilidad y, en última instancia, a una gestión más eficaz. A su debido tiempo, podrá compartir las métricas de CFP entregadas y CFP mantenidas como parte de sus métricas a nivel de junta directiva. Los CIO con visión de futuro que quieran mejorar el rendimiento mediante la medición se beneficiarán significativamente de la adopción de CFP.

La automatización está aquí para ayudar

Nuestro trabajo innovador en ScopeMaster proporciona un dimensionamiento automatizado, consistente y válido de historias de usuarios funcionales o requisitos de usuarios funcionales escritos sin esfuerzo. ScopeMaster estimará la cantidad de CFP en una historia de usuario analizando el idioma de la historia. La mayoría de los proyectos ágiles contienen menos de 500 historias de usuarios. Estos se pueden dimensionar automáticamente en una hora utilizando ScopeMaster. Luego, las historias de usuario se pueden refinar (mejorar en calidad) y la estimación se convertirá en una medición; esto normalmente lleva una décima parte del tiempo con ScopeMaster® que sin él.

Próximos pasos.

Si desea saber más sobre cómo medir su cartera de software, conocer las métricas de software válidas y medir su productividad de desarrollo para brindar mayor certeza a sus proyectos de software, aquí se sugieren algunos pasos siguientes:

1. Anime a su equipo directivo a descubrir el tamaño COSMIC en CFP, le recomendamos el Guía para la medición de software
2. Anime a su PMO a introducir el tamaño de la CFP como métrica en la gestión de carteras.
3. Solicite a sus proveedores que informen sobre la CFP entregada por sprint o por mes.
4. Solicite a sus gerentes de calidad que consideren la posibilidad de informar sobre los defectos encontrados según el CFP.
5. Pídale a su equipo de contratos que investigue los contratos de precio fijo por CFP y solicite a sus proveedores que coticen el costo por CFP.
6. Anticipe el rechazo dentro de su organización y de los proveedores, prepárese para contrarrestarlo con su propia necesidad de mejoras en la transparencia del tamaño, la productividad, la relación calidad-precio y la medición de la calidad.

Comuníquese con nosotros en ScopeMaster para explorar nuestra herramienta de dimensionamiento automatizada y orientación sobre la adopción de CFP en su organización.

Acerca de Colin Hammond

Colin Hammond es un experto en dimensionamiento de software, garantía de proyectos y análisis automatizado de requisitos de software. Habla regularmente en conferencias sobre gestión de proyectos, pruebas de software, análisis de negocios y análisis de costos. Colin es el fundador y director ejecutivo de ScopeMaster, que proporciona la galardonada herramienta de dimensionamiento funcional automatizado. AlcanceMaster y servicios profesionales sobre cómo adoptar y utilizar el dimensionamiento funcional.

Gracias a

Estoy muy agradecido a kirk bride (Agile Coach) y Lonnie Franks (Software Project Assurance Expert) por su valioso aporte editorial a este artículo.

Referencias

McConnell, Steve. “Estimación de software, desmitificando el arte negro”

Boehm, Barry et al 2000. “Estimación de costos de software con COCOMO II”

Garmus, David y Herron, David. "Análisis de puntos de función: prácticas de medición para proyectos de software exitosos".

Jones, Alcaparras. “Medición de software aplicada: asegurando la productividad y la calidad”

Symons, Carlos “Una guía para la medición del tamaño del software"