Evaluación comparativa de software

Puntos de referencia de software para la previsibilidad del proyecto

Quiere comparar su desempeño con el de otros, internamente o con equipos de otras organizaciones. Para realizar comparaciones entre equipos internos, puede establecer sus propios puntos de referencia internos, mientras que para comparar con otros en la industria del software, buscará puntos de referencia de software de la industria. Este artículo se centra en evaluación comparativa adecuada del trabajo de software para que puedas comparar el desempeño de tus equipos con el de otros. 

Nótese bien. Este artículo no trata sobre la evaluación comparativa del rendimiento (velocidad) del software.

La evaluación comparativa de software puede ayudar a las organizaciones a comprender qué tan bien lo están haciendo y dónde podrían mejorar. También con puntos de referencia, los gerentes pueden responder las preguntas vitales sobre un proyecto de software de "¿Cuánto tiempo tardará?" y "¿Cuánto va a costar?"   Los puntos de referencia también se pueden utilizar para ayudar a tomar decisiones comerciales valiosas sobre en qué software centrarse.

Fondo

El software se está convirtiendo en un diferenciador clave entre empresas exitosas y no exitosas en la mayoría de los sectores. La capacidad de producir capacidades de software innovadoras y diferenciadoras de alta calidad más rápido que los competidores es una de las claves para que una empresa supere a sus competidores. Con el tiempo, puede convertirse en un factor importante para la supervivencia corporativa, como ya lo es para las empresas de base tecnológica.

Saber cómo se está desempeñando su empresa frente a otras en su capacidad para ofrecer capacidades de software es cada vez más importante. Aquí es donde entra en juego la evaluación comparativa.

Evaluación comparativa de productividad del desarrollador

El foco tiende a estar en productividad del desarrollador, más bien por tres razones:

1. Variable. La productividad de los desarrolladores varía significativamente: los más capacitados son 100 veces más productivos que los menos capacitados.
2. Significativo. El costo del desarrollador suele ser el componente más importante del costo de la entrega de software.
3. Valioso. Las empresas dependen de la entrega de software para seguir siendo competitivas, por lo que la velocidad a la que se puede entregar es importante para una organización.

La medida básica de la producción es el tamaño funcional, pero no ignore la calidad.

La medida base más útil de la producción es la cantidad de funcionalidad reconocible por el usuario que puede ser entregado con alta calidad por un desarrollador o por un equipo de desarrollo. La mejor manera de determinar esto no es contando líneas de código, sino el tamaño funcional del software entregado. El tamaño funcional se mide utilizando el estándar ISO COSMIC Function Point (CFP). La CFP es la medida estándar más moderna y universal para el tamaño del software. Es una medida independiente de la tecnología del tamaño reconocible por el usuario. La productividad de los desarrolladores y los equipos de desarrollo se puede comparar en CFP promedio por mes o CFP promedio por sprint.

Puntos de referencia de productividad del desarrollador

Cada desarrollador o equipo puede ser evaluado en PPC por sprint.

Advertencia: Las métricas de productividad deben exigir que se verifique la calidad.

Se trata de valores observados por el autor en decenas de proyectos de tamaño modesto (250-1500 MPC). Debe establecer y mantener sus propios puntos de referencia. A menudo también se expresan como la inversa: PPC entregada por unidad de tiempo. P.ej. 20 CFP al mes.

Regla de oro: La regla general es entre 10 y 20 CFP por desarrollador al mes. El rango de productividad observado de los desarrolladores es de 2 a 200 CFP por desarrollador por mes, según las circunstancias, el dominio, las herramientas y la competencia.

Puntos de referencia de productividad del equipo

Una guía general es que en un equipo de siete, 4 desarrolladores, 2 evaluadores y un analista de negocios producirán en promedio a un ritmo de 4 horas por CFP, es decir. 80 CFP por sprint de 2 semanas. Esto puede reducirse si hay una acumulación de errores que deben corregirse de sprints anteriores.

Regla de oro: 70 CFP por sprint es una primera estimación razonable, pero debes establecer tus propios puntos de referencia.

La mayoría de los gerentes quieren saber cómo se compara su equipo y su empresa con otros en:

• Productividad del desarrollo de software
• Calidad del software
• Gasto en software
• Valor del software por dinero

La evaluación comparativa de software interno compara diferentes equipos o proyectos dentro de una organización. La evaluación comparativa de software externa o industrial compara estas características con normas externas.

Este artículo explora qué métricas de software se pueden comparar y qué métricas utilizar para no estimular consecuencias no deseadas.

Los valores de referencia reales presentados son sólo orientativos y no deben considerarse puntos de referencia definitivos. En todos los casos, lo mejor son los puntos de referencia internos, recopilados a partir de trabajos anteriores dentro de su organización.

No se utilizó IA para escribir esta publicación.

Puntos de referencia de recursos de software

Para la planificación de equipos, los líderes necesitan saber cuál es el cantidad ideal de trabajo que alguien puede manejar. El software es trabajo de conocimiento y las limitaciones cognitivas de los desarrolladores son tales que sólo pueden manejar razonablemente una cierta cantidad de funcionalidad. Nuestras observaciones son que esto ronda los 150 CFP. Lo que significa que, independientemente del tamaño de su proyecto, probablemente necesite más de un desarrollador si su alcance total es superior a 180 CFP. La siguiente tabla es una guía para la capacidad típica por función.

Por ejemplo, un proyecto de 1000 CFP necesitará 1 director de proyecto, 2 analistas de negocio, 3 evaluadores y 5 desarrolladores. Estos números dependen de la competencia y el conocimiento del dominio de los involucrados. Siempre que sea posible, es mejor esforzarse por formar equipos más pequeños de personas altamente competentes.

Tenga en cuenta que, para el trabajo de mantenimiento de software, un solo desarrollador normalmente puede manejar más de 180 CFP. Por lo general, requiere 1 desarrollador de tiempo completo por cada 1500-2500 CFP para mantenimiento.

Puntos de referencia de calidad del software

La calidad del software es una cuestión de ventaja comercial. La organización que constantemente ofrece software de calidad que sea útil para los clientes probablemente supere a sus rivales. Por lo tanto, la evaluación comparativa de las métricas de calidad del software se convierte en un importante comparador corporativo.

Potenciales de defectos

Se puede anticipar el número de defectos de un software. Los defectos se pueden predecir en función del tamaño del software. Es lógico que un software más grande tenga el potencial de tener más errores que un software pequeño. El potencial de defecto es el concepto de la cantidad de defectos que es probable que haya en una pieza de software antes de comenzar cualquier medida de detección/evitación/eliminación de defectos.

Los potenciales de defecto típicos son de 4 a 5 defectos por CFP. Estos defectos variarán en gravedad y en su origen. Normalmente de la siguiente manera:

Fuente: Capers Jones, La economía de la calidad del software, 2011.

Lo que esto significa es que es probable que haya cinco defectos por CFP a menos que llevemos a cabo medidas de mejora de la calidad para encontrar y corregir defectos en cada una de estas áreas.

El conocimiento del potencial de defecto ayuda a responder estas preguntas:

• ¿Cuántos defectos necesitamos encontrar para lograr una calidad razonable?
• ¿Cuántos defectos es probable que queden pendientes?
• ¿Cuántas pruebas más necesitamos realizar?
• ¿Estamos listos para empezar a vivir?

Eficiencia de eliminación de defectos

La calidad de un producto de software generalmente se observa como la cantidad de defectos expuestos en la producción. El número de defectos “nuevos” disminuye durante los primeros 3 meses, por lo que podemos decir que el La eficiencia de eliminación de defectos está determinada por la cantidad de defectos encontrados en los primeros 3 meses de uso como porcentaje de los defectos potenciales, que se basa en la cantidad de funcionalidad entregada.

Evaluación comparativa de software: cronogramas

El cronograma o tiempo necesario para entregar el software es una consecuencia directa de la productividad del equipo que trabaja en el software. Hemos analizado la productividad de los desarrolladores en términos de producción del equipo por sprint en alrededor de 70 CFP por sprint de dos semanas, o 140 por mes. Esto nos da una guía clara para responder la pregunta. "¿Cuándo estará listo?"

Regla de oro: Para proyectos pequeños de menos de 1000 CFP: un equipo normalmente entregará 140 CFP por mes.

Regla de oro: Para proyectos grandes de más de 1000 CFP+, la productividad disminuye con el tamaño: el número de meses para entregar = CFP ^ 0,4

Tenga en cuenta que ofrecer una funcionalidad de mala calidad ralentizará el proyecto en general. Sólo con alta calidad se pueden lograr los cronogramas más rápidos.

Consejo: Si se entregó un CFP pero se descubre un defecto en un sprint posterior, no lo cuenta como entregado.

Evaluación comparativa del valor entregado

Si una empresa gasta $1000 en ofrecer 1 CFP de nueva funcionalidad. Se esperaría que el valor comercial general de esa funcionalidad supere el costo de $1000 a corto y largo plazo. El valor por CFP variará, pero las empresas deberían pensar en un retorno del valor de 1 a 3 años en términos de muchas veces el costo por CFP. El beneficio comercial a 3 años por CFP es una métrica útil para realizar un seguimiento y se puede comparar.

Costo total de la propiedad

Más allá del costo inicial de construcción $1000 de un CFP, las empresas deben tener en cuenta el costo total de propiedad durante la vida útil de ese software. Por ejemplo, en los primeros dos años después de la construcción inicial es probable que se realicen mejoras considerables, alrededor de 201 TP3T en el primer año y otras 151 TP3T en el segundo, en adelante, normalmente 81 TP3T por año. Puede establecer sus propios puntos de referencia internamente para el TCO de las aplicaciones de software de su cartera; estos datos le ayudarán a tomar decisiones sobre los planes de sustitución del sistema.

Regla de oro: el TCO total a 5 años suele ser entre 2 y 3 veces el coste inicial.

Cambio de alcance de evaluación comparativa

Durante un proyecto, surgirán o se harán evidentes nuevos requisitos. Si bien algo de esto se puede conocer desde el principio, otra parte no. Aquellas organizaciones que inviertan adecuadamente en el trabajo de requisitos (15% o más para desarrollo personalizado, más para implementaciones de paquetes como ERP) no solo lograrán cronogramas más cortos, sino que también experimentarán menos cambios de alcance durante el proyecto. Alcaparras Jones

Regla de oro: 1-2% cambio de alcance por mes durante un proyecto.

Regla de oro: 8% por año cambio de alcance después de la implementación.

 

Evaluación comparativa de la deuda técnica

La deuda técnica es la reelaboración que surge de requisitos emergentes que no se conocían cuando se escribió el código por primera vez. Para cuantificar y comparar la deuda técnica, primero se debe clasificar cuidadosamente el retrabajo causado por:

• Errores en el código (no deuda técnica)
• Atajos creados para un despliegue rápido (no es deuda técnica en el concepto original, pero comúnmente se piensa que así es)
• Retrabajo porque no se realizó un trabajo de requisitos insuficiente (incógnitas cognoscibles que surgen más adelante). Esta es una deuda técnica evitable.
• Reelaborar porque surgieron requisitos que antes no se podían conocer. (Ésta es la deuda técnica genuina e inevitable).

La mayoría de las organizaciones son inconsistentes con las clasificaciones anteriores y, por lo tanto, les resultará difícil realizar una evaluación comparativa de la deuda técnica.

 

Costo total de la propiedad

Más allá del costo inicial de construcción de $1000, las empresas deben tener en cuenta el costo total de propiedad durante la vida útil de ese software. En los primeros dos años después de la construcción inicial, es probable que se realicen mejoras considerables, alrededor de 201 TP3T en el primer año y otros 151 TP3T en el segundo y 81 TP3T por año a partir de entonces. Más allá de eso, está el mantenimiento del software anualmente, ya sea para que siga funcionando en una infraestructura en constante cambio o para corregir los errores que aparecen. Alcaparras Jones

Regla de oro: el costo de 5 años suele ser 3 veces el costo inicial.

Otros puntos de referencia para el trabajo de software

Ingenieros por cliente/usuario

Este número es citado a menudo por productos de consumo Saas como Facebook y Twitter. Con mayor frecuencia se expresa como miles de usuarios por ingeniero. Esta es una métrica útil para este tipo de organizaciones.

Ingresos por ingeniero de DevOps

En empresas con uso intensivo de software, donde el personal técnico es el costo principal del negocio, el seguimiento de los ingresos generales por ingeniero de DevOps es un indicador amplio de la eficiencia técnica.

Métricas de DORA

Frecuencia de implementación

Es una medida del número de veces que se lanza a producción código nuevo (de cualquier cantidad). Es un indicador útil y único de la repetibilidad del ciclo de desarrollo/prueba. La frecuencia de implementación debe medirse en horas o días, no en semanas.

Tiempo medio para restaurar

El tiempo medio de restauración rastrea el tiempo transcurrido que lleva restaurar el servicio después de una falla en la producción. Este es un indicador de la capacidad de un equipo para recuperarse de un error. Debe medirse en minutos u horas, no en días.

Plazo de entrega de cambios

Lead Time for Changes rastrea el tiempo que tarda el código en pasar de comprometido a ejecutarse exitosamente en producción. Esto no tiene en cuenta la magnitud, el valor ni la complejidad del cambio. Se trata más de la eficiencia de la implementación que de la eficiencia del desarrollo.

Tasa de errores de cambio

La tasa de errores de cambio es un indicador de la calidad del código implementado.

Ventajas de las métricas DORA

Son fáciles de rastrear

Se centran en actividades de DevOps.

Desventajas de las métricas DORA

Se centran en las tasas de cambio independientemente del tamaño o del valor para el cliente.

En su mayoría no son adecuados para la planificación, el dimensionamiento y el seguimiento de proyectos.

Solo son adecuados para realizar evaluaciones comparativas de actividades de DevOps o DevSecOps.

Puntos de referencia perjudiciales para el trabajo de software

Las organizaciones a menudo pueden capturar por error métricas que pueden tener consecuencias no deseadas; estas deben usarse con mucha precaución o evitarse por completo y, además, no deben usarse como base para realizar evaluaciones comparativas.

Líneas de códigos producidas por ingeniero

Esto puede hacer que los desarrolladores escriban código detallado, en lugar de código eficiente o reutilizado. En lugar de usar CFP producida por ingeniero

• Defectos producidos por mes por ingeniero
  • El número de defectos producidos debe considerarse en el contexto del resultado. Un desarrollador que produce 1 defecto por mes y sólo 1 CFP, es menos capaz que uno que produce 2 defectos por mes en 10 CFP. En lugar de usar defectos por CFP producido por ingeniero.
• Costo de detectar un defecto
  • Cuanto mayor sea la calidad del software, más costoso será encontrar un defecto. Un alto costo por descubrimiento de defectos puede significar que el software ya tiene un gran valor.

Consejos de evaluación comparativa interna

1. Divulgar los nombres de los proyectos en puntos de referencia comparativos internos.
2. Muestre las métricas de los componentes, no solo los valores generales.
3. Incluya actividades que no sean de codificación.
4. Incluye aspectos humanos.
5. Utilice métricas de tamaño funcional.
6. No utilice los datos para establecer objetivos abstractos.

Resumido de Capers Jones presentación sobre evaluación comparativa